JP2001257707A

JP2001257707A - マルチ再生システム、サーバ装置、端末装置

Info

Publication number: JP2001257707A
Application number: JP2000071036A
Authority: JP
Inventors: Koushiyaku Yana; 弘錫梁
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 2000-03-09
Filing date: 2000-03-09
Publication date: 2001-09-21

Abstract

(57)【要約】【課題】データの有効利用及び使用性の向上。【解決手段】例えば家庭内の各部屋などに端末装置を
配し、各端末装置からサーバ装置に対してリクエスト信
号で再生データの転送を要求することで、各端末装置に
おいて、サーバ装置に蓄積されているデータを利用、つ
まり再生出力できるようにする。サーバ装置は複数のリ
クエスト信号に同時に対応できるようにすることで、端
末装置の利用は他の端末装置の要求状況に関わらず、時
間的かつデータ的に自由に所望の再生を実現可能とす
る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、サーバ装置と複数
の端末装置、及びそれらから成るマルチ再生システムに
関するものである。

【０００２】

【従来の技術】ユーザーの所有するオーディオビジュア
ル機器として各種のものが普及しており、音楽ソフトや
映像ソフトを個人で楽しむことが一般化している。音楽
ソフト、映像ソフトとして提供されるメディアも近年多
様化しており、例えばＣＤ（コンパクトディスク）、Ｃ
Ｄ−ＲＯＭ、ＭＤ（ミニディスク）、ＤＶＤなどのディ
スクメディアや、テープメディア、メモリカードなどの
固体メモリメディアなどが提供されている。また通信シ
ステムの発達に応じて、音楽等の配信も実施されてお
り、記録媒体を伴わない音楽データ等の提供も実現され
ている。

【０００３】

【発明が解決しようとする課題】このような状況下にお
いて、例えば家庭内などでは音楽データ、映像データな
どの多数かつ多様なデータを一元的に管理できることが
好適であるほか、例えばそのデータを各個人が任意に利
用、つまり再生できるようにすることが求められてい
る。

【０００４】

【課題を解決するための手段】本発明はこのような状況
に鑑みて、家庭内などでサーバ装置と複数の端末装置に
よるマルチ再生システムを構築できるようにし、サーバ
装置に蓄積されたデータを、端末装置側の各個人が任意
に利用でき、また同時的であっても利用できるようなシ
ステムを実現する。

【０００５】このため本発明では、サーバ装置と複数の
端末装置が通信可能に接続されて成るマルチ再生システ
ムを提供する。上記サーバ装置は、複数のデータを蓄積
する蓄積手段と、上記蓄積手段からデータを再生して送
信することのできる再生送信手段と、上記端末装置から
のリクエスト信号に応じて、要求されたデータを上記再
生送信手段により上記蓄積手段から再生させ、そのリク
エスト信号を発した端末装置に対して送信させるリクエ
スト対応制御を実行するとともに、このリクエスト対応
制御を複数のリクエスト信号に同時に対応して実行でき
るようにされた制御手段と、を備えるようにする。また
上記各端末装置は、操作手段と、上記操作手段の操作に
応じて上記サーバ装置に対してリクエスト信号を送信す
る送信手段と、上記サーバ装置から送信されてきたデー
タを出力する出力手段と、を備えるようにする。そして
上記サーバ装置と上記各端末装置は、同期通信及び非同
期通信が可能な通信方式、例えばＩＥＥＥ１３９４方式
で接続されているようにする。また上記各端末装置は、
上記サーバ装置を起点としてデイジーチェイン接続され
るようにする。また上記サーバ装置は、外部装置から通
信により供給されたデータ、又は記録媒体から再生され
たデータを、上記蓄積手段に蓄積できるようにする。ま
た、上記サーバ装置は、上記各端末装置のそれぞれに対
応して、送信するデータのバッファリングをおこなうこ
とができるバッファリング手段をさらに備える。また上
記端末装置は、上記サーバ装置から送信されてきたデー
タのバッファリングをおこなうことができるバッファリ
ング手段をさらに備えるようにする。

【０００６】即ち本発明では、例えば家庭内の各部屋な
どに端末装置を配し、各端末装置からサーバ装置に対し
てリクエスト信号で再生データの転送を要求する。これ
により端末装置において、サーバ装置に蓄積されている
データを利用できるようにする。またサーバ装置はリク
エスト対応制御を複数のリクエスト信号に同時に対応し
て実行できることで、各端末装置側からは時間的かつデ
ータ的に自由に、つまり他の端末装置の要求状況に関わ
らず、所望の再生を実現させることが可能となる。

【０００７】

【発明の実施の形態】以下、本発明の実施の形態として
の、本発明のサーバ装置に相当するデータサーバ１０、
本発明の端末装置に相当するターミナル５０、及びこれ
らから成るマルチ再生システムについて、次の順序で説
明していく。なお、この例ではデータサーバ１０及び複
数のターミナル５０の間はＩＥＥＥ１３９４方式の通信
が行われるものとし、このため実施の形態の構成及び動
作に先立って、ＩＥＥＥ１３９４について説明する。１．ＩＥＥＥ１３９４によるデータ通信１−１．概要１−２．スタックモデル１−３．信号伝送形態１−４．機器間のバス接続１−５．パケット１−６．トランザクションルール１−７．アドレッシング１−８．ＣＩＰ(Common Isochronos Packet) １−９．コネクションマネージメント１−１０．ＦＣＰにおけるコマンド及びレスポンス１−１１．ＡＶ／Ｃコマンドパケット１−１２．プラグ１−１３．Asynchronous Connection送信手順２．マルチ再生システムの概要３．データサーバの構成４．ターミナルの構成５．通信／再生動作６．変形例

【０００８】１．ＩＥＥＥ１３９４によるデータ通信１−１．概要以降、本実施の形態としてのＩＥＥＥ１３９４規格に従
ったデータ通信について説明する。ＩＥＥＥ(The Insti
tute of Electrical and Electronics Engineers)１３
９４は、シリアルデータ通信の規格の１つとされる。近
年、デジタルデータインターフェイスとして、このＩＥ
ＥＥ１３９４データインターフェイスが広く利用される
状況にある。ＩＥＥＥ１３９４によるデータ伝送方式と
しては、周期的に通信を行うＩｓｏｃｈｒｏｎｏｕｓ通
信方式と、この周期と関係なく非同期で通信するＡｓｙ
ｎｃｈｒｏｎｏｕｓ通信方式が存在する。一般に、Ｉｓ
ｏｃｈｒｏｎｏｕｓ通信方式はデータの送受信に用いら
れ、Ａｓｙｎｃｈｒｏｎｏｕｓ通信方式は各種制御コマ
ンドの送受信に用いられる。そして、１本のケーブルを
使用して、これら２種類の通信方式によって送受信を行
うことが出来るようにされている。

【０００９】そしてＩＥＥＥ１３９４データインターフ
ェイスは、例えばＳＣＳＩなどよりもデータ転送レート
が高速であり、また、所要のデータサイズを周期的に送
受信することが保証されるＩｓｏｃｈｒｏｎｏｕｓ通信
が可能とされるため、ＡＶ(Audio/Video)などのストリ
ームデータをリアルタイムで転送するのに有利とされて
いる。

【００１０】１−２．スタックモデル図８はＩＥＥＥ１３９４のスタックモデルを示してい
る。ＩＥＥＥ１３９４フォーマットにおいては、Ａｓｙ
ｎｃｈｒｏｎｏｕｓ系（４００）とＩｓｏｃｈｒｏｎｏ
ｕｓ系（５００）とに大別される。ここで、Ａｓｙｎｃ
ｈｒｏｎｏｕｓ系（４００）とＩｓｏｃｈｒｏｎｏｕｓ
系（５００）に共通な層として、最下位にＰｈｙｓｉｃ
ａｌＬａｙｅｒ（３０１）（物理層）が設けられ、そ
の上位にＬｉｎｋＬａｙｅｒ（３０２）（リンク層）
が設けられる。ＰｈｙｓｉｃａｌＬａｙｅｒ（３０
１）はハードウェア的な信号伝送を司るためのレイヤで
あり、ＬｉｎｋＬａｙｅｒ（３０２）はＩＥＥＥ１３
９４バスを例えば、機器毎に規定された内部バスに変換
するための機能を有する層とされる。

【００１１】ＰｈｙｓｉｃａｌＬａｙｅｒ（３０
１）、ＬｉｎｋＬａｙｅｒ（３０２）、及び次に説明
するＴｒａｎｓａｃｔｉｏｎＬａｙｅｒ（４０１）
は、Ｅｖｅｎｔ／Ｃｏｎｔｒｏｌ／Ｃｏｎｆｉｇｕｒａ
ｔｉｏｎのラインによってＳｅｒｉａｌＢｕｓＭａ
ｎａｇｅｍｅｎｔ３０３とリンクされる。また、ＡＶ
Ｃａｂｌｅ／Ｃｏｎｎｅｃｔｏｒ３０４は、ＡＶデータ
伝送のための物理的なコネクタ、ケーブルを示してい
る。

【００１２】Ａｓｙｎｃｈｒｏｎｏｕｓ系（４００）に
おける上記ＬｉｎｋＬａｙｅｒ（３０２）の上位に
は、ＴｒａｎｓａｃｔｉｏｎＬａｙｅｒ（４０１）が
設けられる。ＴｒａｎｓａｃｔｉｏｎＬａｙｅｒ（４
０１）は、ＩＥＥＥ１３９４としてのデータ伝送プロト
コルを規定する層とされ、基本的なＡｓｙｎｃｈｒｏｎ
ｏｕｓＴｒａｎｓａｃｔｉｏｎとしては、後述するよ
うにして、ＷｒｉｔｅＴｒａｎｓａｃｔｉｏｎ，Ｒｅａ
ｄＴｒａｎｓａｃｔｉｏｎ，ＬｏｃｋＴｒａｎｓａ
ｃｔｉｏｎが規定される。

【００１３】そして、ＴｒａｎｓａｃｔｉｏｎＬａｙ
ｅｒ（４０１）の上層に対してＦＣＰ(Function Contro
l Protocol)（４０２）が規定される。ＦＣＰ（４０
２）は、ＡＶ／ＣＣｏｍｍａｎｄ(AV/C Digital Inte
rface Command Set)（４０３）として規定された制御コ
マンドを利用することで、各種ＡＶ機器に対するコマン
ド制御を実行することが出来るようになっている。

【００１４】また、ＴｒａｎｓａｃｔｉｏｎＬａｙｅ
ｒ（４０１）の上層に対しては、Ｃｏｎｎｅｃｔｉｏｎ
ＭａｎａｇｅｍｅｎｔＰｒｏｃｅｄｕｒｅｓ（５０
５）を利用して、後述するＰｌｕｇ（ＩＥＥＥ１３９４
における論理的な機器接続関係）を設定するためのＰｌ
ｕｇＣｏｎｔｒｏｌｌＲｅｇｉｓｔｅｒｓ（４０
４）が規定される。

【００１５】Ｉｓｏｃｈｒｏｎｏｕｓ系（５００）にお
けるＬｉｎｋＬａｙｅｒ（３０２）の上位には、ＣＩ
ＰＨｅａｄｅｒＦｏｒｍａｔ（５０１）が規定さ
れ、このＣＩＰＨｅａｄｅｒＦｏｒｍａｔ（５０
１）に管理される形態で、ＳＤ−ＤＶＣＲＲｅａｌｔ
ｉｍｅＴｒａｎｓｍｉｓｓｉｏｎ（５０２），ＨＤ−
ＤＶＣＲＲｅａｌｔｉｍｅＴｒａｎｓｍｉｓｓｉｏ
ｎ（５０３），ＳＤＬ−ＤＶＣＲＲｅａｌｔｉｍｅ
Ｔｒａｎｓｍｉｓｓｉｏｎ（５０４），ＭＰＥＧ２−Ｔ
ＳＲｅａｌｔｉｍｅＴｒａｎｓｍｉｓｓｉｏｎ（５
０５），ＡｕｄｉｏａｎｄＭｕｓｉｃＲｅａｌｔｉ
ｍｅＴｒａｎｓｍｉｓｓｉｏｎ（５０６）等の伝送プ
ロトコルが規定されている。

【００１６】ＳＤ−ＤＶＣＲＲｅａｌｔｉｍｅＴｒ
ａｎｓｍｉｓｓｉｏｎ（５０２），ＨＤ−ＤＶＣＲＲ
ｅａｌｔｉｍｅＴｒａｎｓｍｉｓｓｉｏｎ（５０
３），ＳＤＬ−ＤＶＣＲＲｅａｌｔｉｍｅＴｒａｎ
ｓｍｉｓｓｉｏｎ（５０４）は、それぞれ、デジタルＶ
ＴＲ(Video Tape Recorder)に対応するデータ伝送プロ
トコルである。ＳＤ−ＤＶＣＲＲｅａｌｔｉｍｅＴ
ｒａｎｓｍｉｓｓｉｏｎ（５０２）が扱うデータは、Ｓ
Ｄ−ＤＶＣＲｒｅｃｏｒｄｉｎｇｆｏｒｍａｔ（５
０８）の規定に従って得られたデータシーケンス（ＳＤ
−ＤＶＣＲｄａｔａｓｅｑｕｅｎｃｅ（５０７））
とされる。また、ＨＤ−ＤＶＣＲＲｅａｌｔｉｍｅ
Ｔｒａｎｓｍｉｓｓｉｏｎ（５０３）が扱うデータは、
ＨＤ−ＤＶＣＲｒｅｃｏｒｄｉｎｇｆｏｒｍａｔ
（５１０）の規定に従って得られたデータシーケンス
（ＳＤ−ＤＶＣＲｄａｔａｓｅｑｕｅｎｃｅ（５０
９））とされる。ＳＤＬ−ＤＶＣＲＲｅａｌｔｉｍｅ
Ｔｒａｎｓｍｉｓｓｉｏｎ（５０４）が扱うデータ
は、ＳＤＬ−ＤＶＣＲｒｅｃｏｒｄｉｎｇｆｏｒｍ
ａｔ（５１２）の規定に従って得られるデータシーケン
ス（ＳＤ−ＤＶＣＲｄａｔａｓｅｑｕｅｎｃｅ（５
１１））となる。

【００１７】ＭＰＥＧ２−ＴＳＲｅａｌｔｉｍｅＴ
ｒａｎｓｍｉｓｓｉｏｎ（５０５）は、例えばデジタル
衛星放送に対応するチューナ等に対応する伝送プロトコ
ルで、これが扱うデータは、ＤＶＢｒｅｃｏｒｄｉｎ
ｇｆｏｒｍａｔ（５１４）或いはＡＴＶｒｅｃｏｒ
ｄｉｎｇｆｏｒｍａｔ（５１５）の規定に従って得ら
れるデータシーケンス（ＭＰＥＧ２−ＴＳｄａｔａ
ｓｅｑｕｅｎｃｅ（５１３））とされる。

【００１８】また、ＡｕｄｉｏａｎｄＭｕｓｉｃ
ＲｅａｌｔｉｍｅＴｒａｎｓｍｉｓｓｉｏｎ（５０
６）は、デジタルオーディオ機器全般に対応する伝送プ
ロトコルであり、これが扱うデータは、Ａｕｄｉｏａ
ｎｄＭｕｓｉｃｒｅｃｏｒｄｉｎｇｆｏｒｍａｔ
（５１７）の規定に従って得られるデータシーケンス
（ＡｕｄｉｏａｎｄＭｕｓｉｃｄａｔａｓｅｑ
ｕｅｎｃｅ）とされる。

【００１９】１−３．信号伝送形態図９は、ＩＥＥＥ１３９４バスとして実際に用いられる
ケーブルの構造例を示している。この図においては、コ
ネクタ６００Ａと６００Ｂがケーブル６０１を介して接
続されていると共に、ここでは、コネクタ６００Ａと６
００Ｂのピン端子として、ピン番号１〜６の６ピンが使
用される場合を示している。コネクタ６００Ａ，６００
Ｂに設けられる各ピン端子については、ピン番号１は電
源（ＶＰ）、ピン番号２はグランド（ＶＧ）、ピン番号
３はＴＰＢ１、ピン番号４はＴＰＢ２、ピン番号５はＴ
ＰＡ１、ピン番号５はＴＰＡ２とされている。そして、
コネクタ６００Ａ−６００Ｂ間の各ピンの接続形態は、ピン番号１（ＶＰ）−ピン番号１（ＶＰ）ピン番号２（ＶＧ）−ピン番号２（ＶＧ）ピン番号３（ＴＰＢ１）−ピン番号５（ＴＰＡ１）ピン番号４（ＴＰＢ２）−ピン番号６（ＴＰＡ２）ピン番号５（ＴＰＡ１）−ピン番号３（ＴＰＢ１）ピン番号６（ＴＰＡ２）−ピン番号３（ＴＰＢ２）のようになっている。そして、上記ピン接続の組のう
ち、ピン番号３（ＴＰＢ１）−ピン番号５（ＴＰＡ１）ピン番号４（ＴＰＢ２）−ピン番号６（ＴＰＡ２）の２本のツイスト線の組により、差動で信号を相互伝送
する信号線６０１Ａを形成し、ピン番号５（ＴＰＡ１）−ピン番号３（ＴＰＢ１）ピン番号６（ＴＰＡ２）−ピン番号３（ＴＰＢ２）の２本のツイスト線の組により、差動で信号を相互伝送
する信号線６０１Ｂを形成している。

【００２０】上記２組の信号線６０１Ａ及び信号線６０
１Ｂにより伝送される信号は、図１０（ａ）に示すデー
タ信号（Ｄａｔａ）と、図１０（ｂ）に示すストローブ
信号（Ｓｔｒｏｂｅ）である。図１０（ａ）に示すデー
タ信号は、信号線６０１Ａ又は信号線６０１Ｂの一方を
使用してＴＰＢ１，２から出力され、ＴＰＡ１，２に入
力される。また、図１０（ｂ）に示すストローブ信号
は、データ信号と、このデータ信号に同期する伝送クロ
ックとについて所定の論理演算を行うことによって得ら
れる信号であり、実際の伝送クロックよりは低い周波数
を有する。このストローブ信号は、信号線６０１Ａ又は
信号線６０１Ｂのうち、データ信号伝送に使用していな
い他方の信号線を使用して、ＴＰＡ１，２から出力さ
れ、ＴＰＢ１，２に入力される。

【００２１】例えば、図１０（ａ），図１０（ｂ）に示
すデータ信号及びストローブ信号が、或るＩＥＥＥ１３
９４対応の機器に対して入力されたとすると、この機器
においては、入力されたデータ信号とストローブ信号と
について所定の論理演算を行って、図１０（ｃ）に示す
ような伝送クロック（Ｃｌｏｃｋ）を生成し、所要の入
力データ信号処理に利用する。ＩＥＥＥ１３９４フォー
マットでは、このようなハードウェア的データ伝送形態
を採ることで、高速な周期の伝送クロックをケーブルに
よって機器間で伝送する必要をなくし、信号伝送の信頼
性を高めるようにしている。なお、上記説明では６ピン
の仕様について説明したが、ＩＥＥＥ１３９４フォーマ
ットでは電源（ＶＰ）とグランド（ＶＧ）を省略して、
２組のツイスト線である信号線６０１Ａ及び信号線６０
１Ｂのみからなる４ピンの仕様も存在する。例えばオー
ディオ機器などで、この４ピン仕様のケーブルを用いる
ことで、ユーザにとってより簡易なシステムを提供でき
るように配慮している。

【００２２】１−４．機器間のバス接続図１１は、ＩＥＥＥ１３９４バスによる機器間接続の形
態例を模式的に示している。この図では、機器Ａ，Ｂ，
Ｃ，Ｄ，Ｅの５台の機器（Ｎｏｄｅ）がＩＥＥＥ１３９
４バス（即ちケーブルである）によって相互通信可能に
接続されている場合が示されている。ＩＥＥＥ１３９４
インターフェイスでは、機器Ａ，Ｂ，ＣのようにしてＩ
ＥＥＥ１３９４バスにより直列的に接続するいわゆる
「ディージチェーン接続」が可能とされる。また、図１
１の場合であれば、機器Ａと、機器Ｂ，Ｄ，Ｅ間の接続
形態に示すように、或る機器と複数機器とが並列的に接
続されるいわゆる「ブランチ接続」も可能とされる。シ
ステム全体としては、このブランチ接続と上記ディージ
チェーン接続とを併用して最大６３台の機器（Ｎｏｄ
ｅ）を接続可能とされる。但し、ディージチェーン接続
によっては、最大で１６台（１６ポップ）までの接続が
可能とされている。また、ＳＣＳＩで必要とされるター
ミネータはＩＥＥＥ１３９４インターフェイスでは不要
である。そしてＩＥＥＥ１３９４インターフェイスで
は、上記のようにしてディージチェーン接続又はブラン
チ接続により接続された機器間で相互通信を行うことが
可能とされている。つまり、図１１の場合であれば、機
器Ａ，Ｂ，Ｃ，Ｄ，Ｅ間の任意の複数機器間での相互通
信が可能とされる。

【００２３】また、ＩＥＥＥ１３９４バスにより複数の
機器接続を行ったシステム（以降はＩＥＥＥ１３９４シ
ステムともいう）内では、機器ごとに割与えられるＮｏ
ｄｅＩＤを設定する処理が実際には行われる。この処理
を、図１２により模式的に示す。ここで、図１２（ａ）
に示す接続形態によるＩＥＥＥ１３９４システムにおい
て、ケーブルの抜き差し、システムにおける或る機器の
電源のオン／オフ、ＰＨＹ(Physical Layer Protocol)
での自発発生処理等が有ったとすると、ＩＥＥＥ１３９
４システム内においてはバスリセットが発生する。これ
により、各機器Ａ，Ｂ，Ｃ，Ｄ，Ｅ間においてＩＥＥＥ
１３９４バスを介して全ての機器にバスリセット通知を
行う処理が実行される。

【００２４】このバスリセット通知の結果、図１２
（ｂ）に示すようにして、通信（Child−Notify）を行
うことで隣接する機器端子間で親子関係が定義される。
つまり、ＩＥＥＥ１３９４システム内における機器間の
Ｔｒｅｅ構造を構築する。そして、このＴｒｅｅ構造の
構築結果に従って、ルートとしての機器が定義される。
ルートとは、全ての端子が子(Ｃｈ；Child)として定義
された機器であり、図１２（ｂ）の場合であれば、機器
Ｂがルートとして定義されていることになる。逆に言え
ば、例えばこのルートとしての機器Ｂと接続される機器
Ａの端子は親(Ｐ；Parent)として定義されているもので
ある。

【００２５】上記のようにしてＩＥＥＥ１３９４システ
ム内のＴｒｅｅ構造及びルートが定義されると、続いて
は、図１２（ｃ）に示すようにして、各機器から、自己
のＮｏｄｅ−ＩＤの宣言としてＳｅｌｆ−ＩＤパケット
が出力される。そしてルートがこのＮｏｄｅ−ＩＤに対
して順次承認（grant）を行っていくことにより、ＩＥ
ＥＥ１３９４システム内における各機器のアドレス、つ
まりＮｏｄｅ−ＩＤが決定される。

【００２６】１−５．パケットＩＥＥＥ１３９４フォーマットでは、図１３に示すよう
にしてＩｓｏｃｈｒｏｎｏｕｓｃｙｃｌｅ（ｎｏｍｉ
ｎａｌｃｙｃｌｅ）の周期を繰り返すことによって送
信を行う。この場合、１Ｉｓｏｃｈｒｏｎｏｕｓｃｙ
ｃｌｅは、１２５μｓｅｃとされ、帯域としては１００
ＭＨｚに相当する。なお、Ｉｓｏｃｈｒｏｎｏｕｓｃ
ｙｃｌｅの周期としては１２５μｓｅｃ以外とされても
良いことが規定されている。そして、このＩｓｏｃｈｒ
ｏｎｏｕｓｃｙｃｌｅごとに、データをパケット化し
て送信する。

【００２７】この図に示すように、Ｉｓｏｃｈｒｏｎｏ
ｕｓｃｙｃｌｅの先頭には、１Ｉｓｏｃｈｒｏｎｏｕ
ｓｃｙｃｌｅの開始を示すＣｙｃｌｅＳｔａｒｔ
Ｐａｃｋｅｔが配置される。このＣｙｃｌｅＳｔａｒ
ｔＰａｃｋｅｔは、ここでの詳しい説明は省略する
が、ＣｙｃｌｅＭａｓｔｅｒとして定義されたＩＥＥ
Ｅ１３９４システム内の特定の１機器によってその発生
タイミングが指示される。ＣｙｃｌｅＳｔａｒｔＰ
ａｃｋｅｔに続いては、ＩｓｏｃｈｒｏｎｏｕｓＰａｃ
ｋｅｔが優先的に配置される。Ｉｓｏｃｈｒｏｎｏｕｓ
Ｐａｃｋｅｔは、図のように、チャンネルごとにパケ
ット化されたうえで時分割的に配列されて転送される
（Ｉｓｏｃｈｒｏｎｏｕｓｓｕｂａｃｔｉｏｎｓ）。
また、Ｉｓｏｃｈｒｏｎｏｕｓｓｕｂａｃｔｉｏｎｓ
内においてパケット毎の区切りには、Ｉｓｏｃｈｒｏｎ
ｏｕｓｇａｐといわれる休止区間（例えば０．０５μ
ｓｅｃ）が設けられる。このように、ＩＥＥＥ１３９４
システムでは、１つの伝送線路によってＩｓｏｃｈｒｏ
ｎｏｕｓデータをマルチチャンネルで送受信することが
可能とされている。

【００２８】ここで、例えば各種ＡＶ機器で圧縮オーデ
ィオデータとして採用されているＡＴＲＡＣデータをＩ
ｓｏｃｈｒｏｎｏｕｓ方式により送信することを考えた
場合、ＡＴＲＡＣデータが１倍速の転送レート１．４Ｍ
ｂｐｓであるとすると、１２５μｓｅｃである１Ｉｓｏ
ｃｈｒｏｎｏｕｓｃｙｃｌｅ周期ごとに、少なくとも
ほぼ２０数ＭバイトのＡＴＲＡＣデータをＩｓｏｃｈｒ
ｏｎｏｕｓＰａｃｋｅｔとして伝送すれば、時系列的
な連続性（リアルタイム性）が確保されることになる。
例えば、或る機器がＡＴＲＡＣデータを送信する際に
は、ここでの詳しい説明は省略するが、ＩＥＥＥ１３９
４システム内のＩＲＭ(Isochronous Resource Manager)
に対して、ＡＴＲＡＣデータのリアルタイム送信が確保
できるだけの、Ｉｓｏｃｈｒｏｎｏｕｓパケットのサ
イズを要求する。ＩＲＭでは、現在のデータ伝送状況を
監視して許可／不許可を与え、許可が与えられれば、指
定されたチャンネルによって、ＡＴＲＡＣデータをＩｓ
ｏｃｈｒｏｎｏｕｓＰａｃｋｅｔにパケット化して送
信することが出来る。これがＩＥＥＥ１３９４インター
フェイスにおける帯域予約といわれるものである。

【００２９】Ｉｓｏｃｈｒｏｎｏｕｓｃｙｃｌｅの帯
域内においてＩｓｏｃｈｒｏｎｏｕｓｓｕｂａｃｔｉ
ｏｎｓが使用していない残る帯域を用いて、Ａｓｙｎｃ
ｈｒｏｎｏｕｓｓｕｂａｃｔｉｏｎｓ、即ちＡｓｙｎ
ｃｈｒｏｎｏｕｓのパケット送信が行われる。図１３で
は、ＰａｃｋｅｔＡ，ＰａｃｋｅｔＢの２つのＡｓ
ｙｎｃｈｒｏｎｏｕｓＰａｃｋｅｔが送信されている
例が示されている。ＡｓｙｎｃｈｒｏｎｏｕｓＰａｃ
ｋｅｔの後には、ａｃｋｇａｐ（０．０５μｓｅｃ）
の休止期間を挟んで、ＡＣＫ（Acknowledge)といわれる
信号が付随する。ＡＣＫは、後述するようにして、Ａｓ
ｙｎｃｈｒｏｎｏｕｓＴｒａｎｓａｃｔｉｏｎの過程
において、何らかのＡｓｙｎｃｈｒｏｎｏｕｓデータの
受信が有ったことを送信側（Ｃｏｎｔｒｏｌｌｅｒ）に
知らせるためにハードウェア的に受信側（Ｔａｒｇｅ
ｔ）から出力される信号である。また、Ａｓｙｎｃｈｒ
ｏｎｏｕｓＰａｃｋｅｔ及びこれに続くＡＣＫからな
るデータ伝送単位の前後には、１０μｓｅｃ程度のｓｕ
ｂａｃｔｉｏｎｇａｐといわれる休止期間が設けられ
る。

【００３０】１−６．トランザクションルール図１４（ａ）の処理遷移図には、Ａｓｙｎｃｈｒｏｎｏ
ｕｓ通信における基本的な通信規則（トランザクション
ルール）が示されている。このトランザクションルール
は、ＦＣＰによって規定される。図１４（ａ）に示すよ
うに、先ずステップＳ１１により、Ｒｅｑｕｅｓｔｅｒ
（送信側）は、Ｒｅｓｐｏｎｄｅｒ（受信側）に対して
Ｒｅｑｕｅｓｔを送信する。Ｒｅｓｐｏｎｄｅｒでは、
このＲｅｑｕｅｓｔを受信する（ステップＳ１２）と、
先ずＡｃｋｎｏｗｌｅｄｇｅをＲｅｑｕｅｓｔｅｒに返
送する（ステップＳ１３）。送信側では、Ａｃｋｎｏｗ
ｌｅｄｇｅを受信することで、Ｒｅｑｕｅｓｔが受信側
にて受信されたことを認知する（ステップＳ１４）。こ
の後、Ｒｅｓｐｏｎｄｅｒは先のステップＳ１２にて受
信したＲｅｑｕｅｓｔに対する応答として、Ｒｅｓｐｏ
ｎｓｅをＲｅｑｕｅｓｔｅｒに送信する（ステップＳ１
５）。Ｒｅｑｕｅｓｔｅｒでは、Ｒｅｓｐｏｎｓｅを受
信し（ステップＳ１６）、これに応答してＲｅｓｐｏｎ
ｄｅｒに対してＡｃｋｎｏｗｌｅｄｇｅを送信する（ス
テップＳ１７）。ＲｅｓｐｏｎｄｅｒではＡｃｋｎｏｗ
ｌｅｄｇｅを受信することで、Ｒｅｓｐｏｎｓｅが送信
側にて受信されたことを認知する。

【００３１】上記図１４（ａ）により送信されるＲｅｑ
ｕｅｓｔＴｒａｎｓａｃｔｉｏｎとしては、図１４
（ｂ）の左側に示すように、ＷｒｉｔｅＲｅｑｕｅｓ
ｔ、ＲｅａｄＲｅｑｕｅｓｔ、ＬｏｃｋＲｅｑｕｅ
ｓｔの３種類に大別して定義されている。Ｗｒｉｔｅ
Ｒｅｑｕｅｓｔは、データ書き込みを要求するコマンド
であり、ＲｅａｄＲｅｑｕｅｓｔはデータの読み出し
を要求するコマンドである。ＬｏｃｋＲｅｑｕｅｓｔ
はここでは詳しい説明は省略するが、ｓｗａｐｃｏｍ
ｐａｒｅ、マスクなどのためのコマンドである。

【００３２】また、ＷｒｉｔｅＲｅｑｕｅｓｔは、後
に図示して説明するＡｓｙｎｃｈｒｏｎｏｕｓＰａｃ
ｋｅｔ（ＡＶ／ＣＣｏｍｍａｎｄＰａｃｋｅｔ）に
格納するコマンド（ｏｐｅｒａｎｄ）のデータサイズに
応じてさらに３種類が定義される。ＷｒｉｔｅＲｅｑ
ｕｅｓｔ（ｄａｔａｑｕａｄｌｅｔ）は、Ａｓｙｎｃ
ｈｒｏｎｏｕｓＰａｃｋｅｔのヘッダサイズのみによ
りコマンドを送信する。ＷｒｉｔｅＲｅｑｕｅｓｔ
（ｄａｔａｂｌｏｃｋ：ｄａｔａｌｅｎｇｔｈ＝４
ｂｙｔｅ）、ＷｒｉｔｅＲｅｑｕｅｓｔ（ｄａｔａ
ｂｌｏｃｋ：ｄａｔａｌｅｎｇｔｈ≠４ｂｙｔｅ）
は、ＡｓｙｎｃｈｒｏｎｏｕｓＰａｃｋｅｔとしてヘ
ッダに対してｄａｔａｂｌｏｃｋを付加してコマンド
送信を行うもので、両者は、ｄａｔａｂｌｏｃｋに格
納されるｏｐｅｒａｎｄのデータサイズが４バイトであ
るかそれ以上であるのかが異なる。

【００３３】ＲｅａｄＲｅｑｕｅｓｔも同様にして、
ＡｓｙｎｃｈｒｏｎｏｕｓＰａｃｋｅｔに格納するｏ
ｐｅｒａｎｄのデータサイズに応じて、ＲｅａｄＲｅ
ｑｕｅｓｔ（ｄａｔａｑｕａｄｌｅｔ）、Ｒｅａｄ
Ｒｅｑｕｅｓｔ（ｄａｔａｂｌｏｃｋ：ｄａｔａｌｅ
ｎｇｔｈ＝４ｂｙｔｅ）、ＲｅａｄＲｅｑｕｅｓｔ
（ｄａｔａｂｌｏｃｋ：ｄａｔａｌｅｎｇｔｈ≠４
ｂｙｔｅ）の３種類が定義されている。

【００３４】また、ＲｅｓｐｏｎｓｅＴｒａｎｓａｃ
ｔｉｏｎとしては、図１４（ｂ）の右側に示されてい
る。上述した３種のＷｒｉｔｅＲｅｑｕｅｓｔに対し
ては、ＷｒｉｔｅＲｅｓｐｏｎｓｅ或いはＮｏＲｅ
ｓｐｏｎｓｅが定義される。また、ＲｅａｄＲｅｑｕ
ｅｓｔ（ｄａｔａｑｕａｄｌｅｔ）に対してはＲｅａ
ｄＲｅｓｐｏｎｓｅ（ｄａｔａｑｕａｄｌｅｔ）が
定義され、ＲｅａｄＲｅｑｕｅｓｔ（ｄａｔａｂｌｏ
ｃｋ：ｄａｔａｌｅｎｇｔｈ＝４ｂｙｔｅ）、又はＲ
ｅａｄＲｅｑｕｅｓｔ（ｄａｔａｂｌｏｃｋ：ｄａ
ｔａｌｅｎｇｔｈ≠４ｂｙｔｅ）に対しては、Ｒｅａ
ｄＲｅｓｐｏｎｓｅ（ｄａｔａｂｌｏｃｋ）が定義さ
れる。

【００３５】ＬｏｃｋＲｅｑｕｅｓｔに対しては、Ｌ
ｏｃｋＲｅｓｐｏｎｓｅが定義される。

【００３６】１−７．アドレッシング図１５は、ＩＥＥＥ１３９４バスのアドレッシングの構
造を示している。図１５（ａ）に示すように、ＩＥＥＥ
１３９４フォーマットでは、バスアドレスのレジスタ
（アドレス空間）として６４ビットが用意される。この
レジスタの上位１０ビットの領域は、ＩＥＥＥ１３９４
バスを識別するためのバスＩＤを示し、図１５（ｂ）に
示すようにしてバスＩＤとしてｂｕｓ＃０〜＃１０２２
の計１０２３のバスＩＤを設定可能としている。ｂｕｓ
＃１０２３はｌｏｃａｌｂｕｓとして定義されてい
る。

【００３７】図１５（ａ）においてバスアドレスに続く
６ビットの領域は、上記バスＩＤにより示されるＩＥＥ
Ｅ１３９４バスごとに接続されている機器のＮｏｄｅ
ＩＤを示す。ＮｏｄｅＩＤは、図１５（ｃ）に示すよ
うにして、Ｎｏｄｅ＃０〜＃６２までの６３のＮｏｄ
ｅＩＤを識別可能としている。上記バスＩＤ及びＮｏ
ｄｅＩＤを示す計１６ビットの領域は、後述するＡＶ
／ＣＣｏｍｍａｎｄＰａｃｋｅｔのヘッダにおける
ｄｅｓｔｉｎａｔｉｏｎＩＤに相当するもので、このバ
スＩＤ及びＮｏｄｅＩＤによって、或るバスに接続さ
れた機器がＩＥＥＥ１３９４システム上で特定される。

【００３８】図１５（ａ）においてＮｏｄｅＩＤに続
く２０ビットの領域は、ｒｅｇｉｓｔｅｒｓｐａｃｅ
であり、このｒｅｇｉｓｔｅｒｓｐａｃｅに続く２８
ビットの領域は、ｒｅｇｉｓｔｅｒａｄｄｒｅｓｓで
ある。ｒｅｇｉｓｔｅｒｓｐａｃｅの値は最大で［Ｆ
ＦＦＦＦｈ］とされて、図１５（ｄ）に示すｒｅｇ
ｉｓｔｅｒを示し、このｒｅｇｉｓｔｅｒの内容が、図
１５（ｅ）に示すようにして定義される。ｒｅｇｉｓｔ
ｅｒａｄｄｒｅｓｓは、図１５（ｅ）に示すレジスタ
のアドレスを指定している。

【００３９】簡単に説明すると、図１５（ｅ）のレジス
タにおいて、例えばアドレス５１２［００００２
００ｈ］から始まるＳｅｒｉａｌＢｕｓ−ｄｅｐｅｎ
ｄｅｎｔＲｅｇｉｓｔｅｒｓを参照することで、Ｉｓ
ｏｃｈｒｏｎｏｕｓｃｙｃｌｅのサイクルタイムや、
空きチャンネルの情報が得られる。また、アドレス１０
２４［００００４００ｈ］から始まるＣｏｎｆｉ
ｇｕｒａｔｉｏｎＲＯＭには、ＮｏｄｅＵｎｉｑｕ
ｅＩＤ、及びｓｕｂｕｎｉｔＩＤ等のＮｏｄｅに関
する所要の情報が格納される。これらＮｏｄｅＵｎｉ
ｑｕｅＩＤ、及びｓｕｂｕｎｉｔＩＤは、実際にそ
のデバイスがＩＥＥＥ１３９４バスに接続されたとき
に、その接続関係を確立する際などに必要となるもので
ある。

【００４０】ＮｏｄｅＵｎｉｑｕｅＩＤは、デバイ
スごとに固有とされ、８バイトによって表現されるデバ
イス情報であり、たとえ同一機種間であっても、同じＮ
ｏｄｅＵｎｉｑｕｅＩＤを有している他の機器は無
いものとされる。

【００４１】また、ｓｕｂｕｎｉｔＩＤとしては、そ
のＮｏｄｅとしての機器の製造メーカ名を示すＶｅｎｄ
ｅｒＮａｍｅ（module_vender_ID）や、Ｎｏｄｅとし
ての機器の機種名を示すＭｏｄｅｌＮａｍｅ（model_
ID）等の情報を有して形成される。

【００４２】ＮｏｄｅＵｎｉｑｕｅＩＤは、デバイ
スごとに固有とされ、８バイトによって表現されるデバ
イス識別情報であり、たとえ同一機種間であっても、同
じＮｏｄｅＵｎｉｑｕｅＩＤを有している機器は無
いものとされる。また、ＶｅｎｄｅｒＮａｍｅは、そ
のＮｏｄｅの製造メーカ名を示す情報であり、Ｍｏｄｅ
ｌＮａｍｅは、そのＮｏｄｅの機種を示す情報であ
る。従って、これらＶｅｎｄｅｒＮａｍｅ及びＭｏｄ
ｅｌＮａｍｅを共通に有する機器は存在することにな
る。従って、ＣｏｎｆｉｇｕｒａｔｉｏｎＲＯＭの内
容を参照することで、その機種に付されているＮｏｄｅ
ＵｎｉｑｕｅＩＤを識別することができ、また、ｓ
ｕｂｕｎｉｔＩＤの内容からは、そのＮｏｄｅの製造
メーカ、及び機種等を識別することが可能になる。な
お、ＮｏｄｅＵｎｉｑｕｅＩＤは必須であるのに対
して、ＶｅｎｄｅｒＮａｍｅ，ＭｏｄｅｌＮａｍｅ
はオプションであり、必ずしも機器に対してセットして
おく必要は無いものとされている。

【００４３】１−８．ＣＩＰ図１６は、ＣＩＰ(Common Isochronos Packet)の構造を
示している。つまり、図１３に示したＩｓｏｃｈｒｏｎ
ｏｕｓＰａｃｋｅｔのデータ構造である。前に述べた
ように、例えばＡＴＲＡＣデータ（オーディオデータ）
は、ＩＥＥＥ１３９４通信においては、Ｉｓｏｃｈｒｏ
ｎｏｕｓ通信によりデータの送受信が行われる。つま
り、リアルタイム性が維持されるだけのデータ量をこの
ＩｓｏｃｈｒｏｎｏｕｓＰａｃｋｅｔに格納して、１
Ｉｓｏｃｈｒｏｎｏｕｓｃｙｃｌｅ毎に順次送信する
ものである。

【００４４】ＣＩＰの先頭３２ビット（１ｑｕａｄｌｅ
ｔ）は、１３９４パケットヘッダとされている。１３９
４パケットヘッダにおいて上位から順に１６ビットの領
域は、ｄａｔａ＿Ｌｅｎｇｔｈ、続く２ビットの領域は
ｔａｇ、続く６ビットの領域はｃｈａｎｎｅｌ、続く４
ビットはｔｃｏｄｅ、続く４ビットは、ｓｙとされてい
る。そして、１３９４パケットヘッダに続く１ｑｕａｄ
ｌｅｔの領域はｈｅａｄｅｒ＿ＣＲＣが格納される。

【００４５】ｈｅａｄｅｒ＿ＣＲＣに続く２ｑｕａｄｌ
ｅｔの領域がＣＩＰヘッダとなる。ＣＩＰヘッダの上位
ｑｕａｄｌｅｔの上位２バイトには、それぞれ‘０’
‘０’が格納され、続く６ビットの領域はＳＩＤ（送信
ノード番号）を示す。ＳＩＤに続く８ビットの領域はＤ
ＢＳ（データブロックサイズ）であり、データブロック
のサイズ（パケット化の単位データ量）が示される。続
いては、ＦＮ（２ビット）、ＱＰＣ（３ビット）の領域
が設定されており、ＦＮにはパケット化する際に分割し
た数が示され、ＱＰＣには分割するために追加したｑｕ
ａｄｌｅｔ数が示される。ＳＰＨ（１ビット）にはソー
スパケットのヘッダのフラグが示され、ＤＢＣにはパケ
ットの欠落を検出するカウンタの値が格納される。

【００４６】ＣＩＰヘッダの下位ｑｕａｄｌｅｔの上位
２バイトにはそれぞれ‘０’‘０’が格納される。そし
て、これに続いてＦＭＴ（６ビット）、ＦＤＦ（２４ビ
ット）の領域が設けられる。ＦＭＴには信号フォーマッ
ト（伝送フォーマット）が示され、ここに示される値に
よって、当該ＣＩＰに格納されるデータ種類（データフ
ォーマット）が識別可能となる。具体的には、ＭＰＥＧ
ストリームデータ、Ａｕｄｉｏストリームデータ、デジ
タルビデオカメラ（ＤＶ）ストリームデータ等の識別が
可能になる。このＦＭＴにより示されるデータフォーマ
ットは、例えば図８に示した、ＣＩＰＨｅａｄｅｒ
Ｆｏｒｍａｔ（４０１）に管理される、ＳＤ−ＤＶＣＲ
ＲｅａｌｔｉｍｅＴｒａｎｓｍｉｓｓｉｏｎ（５０
２），ＨＤ−ＤＶＣＲＲｅａｌｔｉｍｅＴｒａｎｓ
ｍｉｓｓｉｏｎ（５０３），ＳＤＬ−ＤＶＣＲＲｅａ
ｌｔｉｍｅＴｒａｎｓｍｉｓｓｉｏｎ（５０４），Ｍ
ＰＥＧ２−ＴＳＲｅａｌｔｉｍｅＴｒａｎｓｍｉｓ
ｓｉｏｎ（５０５），ＡｕｄｉｏａｎｄＭｕｓｉｃ
ＲｅａｌｔｉｍｅＴｒａｎｓｍｉｓｓｉｏｎ（５０
６）等の伝送プロトコルに対応する。ＦＤＦは、フォー
マット依存フィールドであり、上記ＦＭＴにより分類さ
れたデータフォーマットについて更に細分化した分類を
示す領域とされる。オーディオに関するデータで有れ
ば、例えばリニアオーディオデータであるのか、ＭＩＤ
Ｉデータであるのかといった識別が可能になる。例えば
ＡＴＲＡＣデータであれば、先ずＦＭＴによりＡｕｄｉ
ｏストリームデータの範疇にあるデータであることが示
され、ＦＤＦに規定に従った特定の値が格納されること
で、そのＡｕｄｉｏストリームデータはＡＴＲＡＣデー
タであることが示される。

【００４７】ここで、例えばＦＭＴによりＭＰＥＧであ
ることが示されている場合、ＦＤＦにはＴＳＦ（タイム
シフトフラグ）といわれる同期制御情報が格納される。
また、ＦＭＴによりＤＶＣＲ（デジタルビデオカメラ）
であることが示されている場合、ＦＤＦは、図１６の下
に示すように定義される。ここでは、上位から順に、５
０／６０（１ビット）により１秒間のフィールド数を規
定し、ＳＴＹＰＥ（５ビット）によりビデオのフォーマ
ットがＳＤとＨＤの何れとされてるのかが示され、ＳＹ
Ｔによりフレーム同期用のタイムスタンプが示される。

【００４８】上記ＣＩＰヘッダに続けては、ＦＭＴ，Ｆ
ＤＦによって示されるデータが、ｎ個のデータブロック
のシーケンスによって格納される。ＦＭＴ，ＦＤＦによ
りＡＴＲＡＣデータであることが示される場合には、こ
のデータブロックとしての領域にＡＴＲＡＣデータが格
納される。そして、データブロックに続けては、最後に
ｄａｔａ＿ＣＲＣが配置される。

【００４９】１−９．コネクションマネージメントＩＥＥＥ１３９４フォーマットにおいては、「プラグ」
といわれる論理的接続概念によって、ＩＥＥＥ１３９４
バスによって接続された機器間の接続関係が規定され
る。図１７は、プラグにより規定された接続関係例を示
しており、この場合には、ＩＥＥＥ１３９４バスを介し
て、ＶＴＲ１、ＶＴＲ２、セットトップボックス（ＳＴ
Ｂ；デジタル衛星放送チューナ）、モニタ装置（Ｍｏｎ
ｉｔｏｒ）、及びデジタルスチルカメラ（Ｃａｍｅｒ
ａ）が接続されているシステム形態が示されている。

【００５０】ここで、ＩＥＥＥ１３９４のプラグによる
接続形態としては、ｐｏｉｎｔｔｏｐｏｉｎｔ−ｃ
ｏｎｎｅｃｔｉｏｎと、ｂｒｏａｄｃａｓｔｃｏｎｎ
ｅｃｔｉｏｎとの２つの形態が存在する。ｐｏｉｎｔ
ｔｏｐｏｉｎｔ−ｃｏｎｎｅｃｔｉｏｎは、送信機器
と受信機器との関係が特定され、かつ、特定のチャンネ
ルを使用して送信機器と受信機器との間でデータ伝送が
行われる接続形態である。これに対して、ｂｒｏａｄｃ
ａｓｔｃｏｎｎｅｃｔｉｏｎは、送信機器において
は、特に受信機器及び使用チャンネルを特定せずに送信
を行うものである。受信機側では、特に送信機器を識別
することなく受信を行い、必要が有れば、送信されたデ
ータの内容に応じた所要の処理を行う。図１７の場合で
あれば、ｐｏｉｎｔｔｏｐｏｉｎｔ−ｃｏｎｎｅｃ
ｔｉｏｎとして、ＳＴＢが送信、ＶＴＲ１が受信とされ
てチャンネル＃１を使用してデータの伝送が行われるよ
うに設定されている状態と、デジタルスチルカメラが送
信、ＶＴＲ２が受信とされてチャンネル＃２を使用して
データの伝送が行われるように設定されている状態とが
示されている。また、デジタルスチルカメラからは、ｂ
ｒｏａｄｃａｓｔｃｏｎｎｅｃｔｉｏｎによってもデ
ータ送信を行うように設定されている状態が示されてお
り、ここでは、このｂｒｏａｄｃａｓｔｃｏｎｎｅｃ
ｔｉｏｎによって送信したデータを、モニタ装置が受信
して所要の応答処理を行う場合が示される。

【００５１】上記のような接続形態（プラグ）は、各機
器におけるアドレス空間に設けられるＰＣＲ(Plug Cont
orol Register)によって確立される。図１８（ａ）は、
ｏＰＣＲ［ｎ］（出力用プラグコントロールレジスタ）
の構造を示し、図１８（ｂ）は、ｉＰＣＲ［ｎ］（入力
用プラグコントロールレジスタ）の構造を示している。
これらｏＰＣＲ［ｎ］、ｉＰＣＲ［ｎ］のサイズは共に
３２ビットとされている。図１８（ａ）のｏＰＣＲにお
いては、例えば上位１ビットのｏｎ−ｌｉｎｅに対して
‘１’が格納されていると、ｂｒｏａｄｃａｓｔｃｏ
ｎｎｅｃｔｉｏｎによる送信であることが示され、
‘０’が格納されていると、上位１１ビット目から６ビ
ットの領域のｃｈａｎｎｅｌｎｕｍｂｅｒで示される
チャンネルにより、ｐｏｉｎｔｔｏｐｏｉｎｔｃ
ｏｎｎｅｃｔｉｏｎで送信することが示される。また、
図１８（ｂ）のｉＰＣＲにおいても、例えば上位１ビッ
トのｏｎ−ｌｉｎｅに対して‘１’が格納されていれ
ば、ｂｒｏａｄｃａｓｔｃｏｎｎｅｃｔｉｏｎによる
受信であることが示され、‘０’が格納されていると、
上位１１ビット目から６ビットの領域のｃｈａｎｎｅｌ
ｎｕｍｂｅｒで示されるチャンネルにより送信された
データをｐｏｉｎｔｔｏｐｏｉｎｔｃｏｎｎｅｃ
ｔｉｏｎで送信することが示される。

【００５２】そして、図１８（ａ）のｏＰＣＲ、及び図
１８（ｂ）のｉＰＣＲにおけるｂｒｏａｄｃａｓｔｃ
ｏｎｎｅｃｔｉｏｎｃｏｕｎｔｅｒには、ｂｒｏａｄ
ｃａｓｔｃｏｎｎｅｃｔｉｏｎによる送信／受信とさ
れる場合において、ｂｒｏａｄｃａｓｔｃｏｎｎｅｃ
ｔｉｏｎを張っているノード数が格納される。また、図
１８（ａ）のｏＰＣＲ、及び図１８（ｂ）のｉＰＣＲに
おけるｐｏｉｎｔｔｏｐｏｉｎｔｃｏｎｎｅｃｔ
ｉｏｎｃｏｕｎｔｅｒには、ｐｏｉｎｔｔｏｐｏ
ｉｎｔｃｏｎｎｅｃｔｉｏｎによる送信／受信とされ
る場合において、ｐｏｉｎｔｔｏｐｏｉｎｔを張っ
ているノード数が示される。

【００５３】１−１０．ＦＣＰにおけるコマンド及びレ
スポンスＡｓｙｎｃｈｒｏｎｏｕｓ通信によるデータの伝送は、
図８に示したＦＣＰ（４０２）によって規定されること
になる。そこで、ここでは、ＦＣＰにより規定されるト
ランザクションについて説明する。

【００５４】ＦＣＰとしては、Ａｓｙｎｃｈｒｏｎｏｕ
ｓ通信において規定されるＷｒｉｔｅＴｒａｎｓａｃ
ｔｉｏｎ（図１４参照）を使用する。ＦＣＰをサポート
する機器は、Ｃｏｍｍａｎｄ／Ｒｅｓｐｏｎｃｅレジス
タを備え、次に図１９により説明するようにしてＣｏｍ
ｍａｎｄ／Ｒｅｓｐｏｎｃｅレジスタに対してＭｅｓｓ
ａｇｅを書き込むことでトランザクションを実現する。

【００５５】図１９の処理遷移図においては、先ずＣＯ
ＭＭＡＮＤ送信のための処理として、ステップＳ２１と
して示すように、ＣｏｎｔｒｏｌｌｅｒがＴｒａｎｓａ
ｃｔｉｏｎＲｅｑｕｅｓｔを発生して、Ｗｒｉｔｅ
ＲｅｑｕｅｓｔＰａｃｋｅｔをＴａｒｇｅｔに対して
送信する処理を実行する。Ｔａｒｇｅｔでは、ステップ
Ｓ２２として、このＷｒｉｔｅＲｅｑｕｅｓｔＰａ
ｃｋｅｔを受信して、Ｃｏｍｍａｎｄ／Ｒｅｓｐｏｎｃ
ｅレジスタに対してデータの書き込みを行う。また、こ
の際、ＴａｒｇｅｔからはＣｏｎｔｒｏｌｌｅｒに対し
てＡｃｋｎｏｗｌｅｄｇを送信し、Ｃｏｎｔｒｏｌｌｅ
ｒでは、このＡｃｋｎｏｗｌｅｄｇを受信する（Ｓ２３
→Ｓ２４）。ここまでの一連の処理が、ＣＯＭＭＡＮＤ
の送信に対応する処理となる。

【００５６】続いては、ＣＯＭＭＡＮＤに応答した、Ｒ
ＥＳＰＯＮＳＥのための処理として、Ｔａｒｇｅｔから
ＷｒｉｔｅＲｅｑｕｅｓｔＰａｃｋｅｔが送信され
る（Ｓ２５）。Ｃｏｎｔｒｏｌｌｅｒではこれを受信し
て、Ｃｏｍｍａｎｄ／Ｒｅｓｐｏｎｃｅレジスタに対し
てデータの書き込みを行う（Ｓ２６）。また、Ｃｏｎｔ
ｒｏｌｌｅｒでは、ＷｒｉｔｅＲｅｑｕｅｓｔＰａ
ｃｋｅｔの受信に応じて、Ｔａｒｇｅｔに対してＡｃｋ
ｎｏｗｌｅｄｇを送信する（Ｓ２７）。Ｔａｒｇｅｔで
は、このＡｃｋｎｏｗｌｅｄｇを受信することで、Ｗｒ
ｉｔｅＲｅｑｕｅｓｔＰａｃｋｅｔがＣｏｎｔｒｏ
ｌｌｅｒにて受信されたことを知る（Ｓ２８）。つま
り、ＣｏｎｔｒｏｌｌｅｒからＴａｒｇｅｔ対するＣＯ
ＭＭＡＮＤ伝送処理と、これに応答したＴａｒｇｅｔか
らＣｏｎｔｒｏｌｌｅｒに対するＲＥＳＰＯＮＳＥ伝送
処理が、ＦＣＰによるデータ伝送（Ｔｒａｎｓａｃｔｉ
ｏｎ）の基本となる。

【００５７】１−１１．ＡＶ／Ｃコマンドパケット図８により説明したように、Ａｓｙｎｃｈｒｏｎｏｕｓ
通信において、ＦＣＰは、ＡＶ／Ｃコマンドを用いて各
種ＡＶ機器に対する通信を行うことができるようにされ
ている。Ａｓｙｎｃｈｒｏｎｏｕｓ通信では、Ｗｒｉｔ
ｅ，Ｒｅａｄ，Ｌｏｃｋの３種のトランザクションが規
定されているのは、図１４にて説明した通りであり、実
際には各トランザクションに応じたＷｒｉｔｅＲｅｑ
ｕｅｓｔ／ＲｅｓｐｏｎｃｅＰａｃｋｅｔ，Ｒｅａｄ
Ｒｅｑｕｅｓｔ／ＲｅｓｐｏｎｃｅＰａｃｋｅｔ，
ＬｏｃｋＲｅｑｕｅｓｔ／ＲｅｓｐｏｎｃｅＰａｃ
ｋｅｔが用いられる。そして、ＦＣＰでは、上述したよ
うにＷｒｉｔｅＴｒａｎｓａｃｔｉｏｎを使用するも
のである。そこで図２０に、ＷｒｉｔｅＲｅｑｕｅｓ
ｔＰａｃｋｅｔ（AsynchronousPacket（Write Reques
t for Data Block)）のフォーマットを示す。

【００５８】このＷｒｉｔｅＲｅｑｕｅｓｔＰａｃ
ｋｅｔにおける上位５ｑｕａｄｌｅｔ（第１〜第５ｑｕ
ａｄｌｅｔ）は、ｐａｃｋｅｔｈｅａｄｅｒとされ
る。ｐａｃｋｅｔｈｅａｄｅｒの第１ｑｕａｄｌｅｔ
における上位１６ビットの領域はｄｅｓｔｉｎａｔｉｏ
ｎ＿ＩＤで、データの転送先（宛先）のＮｏｄｅＩＤを
示す。続く６ビットの領域はｔｌ(transact label)であ
り、パケット番号を示す。続く２ビットはｒｔ(retry c
ode)であり、当該パケットが初めて伝送されたパケット
であるか、再送されたパケット示す。続く４ビットの領
域はｔｃｏｄｅ(transaction code)は、指令コードを示
している。そして、続く４ビットの領域はｐｒｉ(prior
ity)であり、パケットの優先順位を示す。

【００５９】第２ｑｕａｄｌｅｔにおける上位１６ビッ
トの領域はｓｏｕｒｃｅ＿ＩＤであり、データの転送元
のＮｏｄｅ＿ＩＤが示される。また、第２ｑｕａｄｌ
ｅｔにおける下位１６ビットと第３ｑｕａｄｌｅｔ全体
の計４８ビットはｄｅｓｔｉｎａｔｉｏｎ＿ｏｆｆｓｅ
ｔとされ、ＣＯＭＭＡＮＤレジスタ（ＦＣＰ＿ＣＯＭＭ
ＡＮＤｒｅｇｉｓｔｅｒ）とＲＥＳＰＯＮＳＥレジス
タ（ＦＣＰ＿ＲＥＳＰＯＮＳＥｒｅｇｉｓｔｅｒ）の
アドレスが示されれる。上記ｄｅｓｔｉｎａｔｉｏｎ＿
ＩＤ及びｄｅｓｔｉｎａｔｉｏｎ＿ｏｆｆｓｅｔが、Ｉ
ＥＥＥ１３９４フォーマットにおいて規定される６４ビ
ットのアドレス空間に相当する。

【００６０】第４ｑｕａｄｌｅｔの上位１６ビットの領
域は、ｄａｔａ＿ｌｅｎｇｔｈとされ、後述するｄａｔ
ａｆｉｅｌｄ（図２０において太線により囲まれる領
域）のデータサイズが示される。続く下位１６ビットの
領域は、ｅｘｔｅｎｄｅｄ＿ｔｃｏｄｅの領域とされ、
ｔｃｏｄｅを拡張する場合に使用される領域である。

【００６１】第５ｑｕａｄｌｅｔとしての３２ビットの
領域は、ｈｅａｄｅｒ＿ＣＲＣであり、Ｐａｃｋｅｔ
ｈｅａｄｅｒのチェックサムを行うＣＲＣ計算値が格納
される。

【００６２】Ｐａｃｋｅｔｈｅａｄｅｒに続く第６ｑ
ｕａｄｌｅｔからｄａｔａｂｌｏｃｋが配置され、こ
のｄａｔａｂｌｏｃｋ内の先頭に対してｄａｔａｆｉ
ｅｌｄが形成される。ｄａｔａｆｉｅｌｄとして先頭と
なる第６ｑｕａｄｌｅｔの上位４バイトには、ＣＴＳ(C
ommand and Transaction Set)が記述される。これは、
当該ＷｒｉｔｅＲｅｑｕｅｓｔＰａｃｋｅｔのコマ
ンドセットのＩＤを示すもので、例えば、このＣＴＳの
値について、図のように［００００］と設定すれば、ｄ
ａｔａｆｉｅｌｄに記述されている内容がＡＶ／Ｃコマ
ンドであると定義されることになる。つまり、このＷｒ
ｉｔｅＲｅｑｕｅｓｔＰａｃｋｅｔは、ＡＶ／Ｃコ
マンドパケットであることが示されるものである。

【００６３】ＣＴＳに続く４ビットの領域は、ｃｔｙｐ
ｅ(Command type；コマンドの機能分類)、又はコマンド
に応じた処理結果(レスポンス)を示すｒｅｓｐｏｎｓｅ
が記述される。

【００６４】図２１に、上記ｃｔｙｐｅ及びｒｅｓｐｏ
ｎｓｅの定義内容を示す。ｃｔｙｐｅ（Ｃｏｍｍａｎ
ｄ）としては、［００００］〜［０１１１］を使用でき
るものとしており、［００００］はＣＯＮＴＲＯＬ、
［０００１］はＳＴＡＴＵＳ、［００１０］はＩＮＱＵ
ＩＲＹ、［００１１］はＮＯＴＩＦＹとして定義され、
［０１００］〜０１１１は、現状、未定義（ｒｅｓｅｒ
ｖｅｄ）とされている。ＣＯＮＴＲＯＬは機能を外部か
ら制御するコマンドであり、ＳＴＡＴＵＳは外部から状
態を間い合わせるコマンド、ＩＮＱＵＩＲＹは、制御コ
マンドのサポートの有無を外部から問い合わせるコマン
ド、ＮＯＴＩＦＹは状態の変化を外部に知らせることを
要求するコマンドである。また、ｒｅｓｐｏｎｓｅとし
ては、［１０００］〜［１１１１］を使用するものとし
ており、［１０００］はＮＯＴＩＭＰＬＥＭＥＮＴＥ
Ｄ、［１００１］はＡＣＣＥＰＴＥＤ、［１０１０］は
ＲＥＪＥＣＴＥＤ、［１０１１］はＩＮＴＲＡＮＳＩＴ
ＩＯＮ、［１１００］はＩＭＰＬＥＭＥＮＴＥＤ／ＳＴ
ＡＢＬＥ、［１１０１］はＣＨＡＮＧＥＤ、［１１１
０］はｒｅｓｅｒｖｅｄ、［１１１１］はＩＮＴＥＲＩ
Ｍとしてそれぞれ定義されている。これらのｒｅｓｐｏ
ｎｓｅは、コマンドの種類に応じて使い分けられる。例
えば、ＣＯＮＴＯＲＯＬのコマンドに対応するｒｅｓｐ
ｏｎｓｅとしては、ＮＯＴＩＭＰＬＥＭＥＮＴＥＤ、Ａ
ＣＣＥＰＴＥＤ、ＲＥＪＥＣＴＥＤ、或いはＩＮＴＥＲ
ＩＭの4つのうちの何れかがＲｅｓｐｏｎｄｅｒ側の状
況等に応じて使い分けられる。

【００６５】図２０において、ｃｔｙｐｅ／ｒｅｓｐｏ
ｎｓｅに続く５ビットの領域には、ｓｕｂｕｎｉｔ−ｔ
ｙｐｅが格納される。は、ｓｕｂｕｎｉｔ−ｔｙｐｅ
は、ＣＯＭＭＡＮＤの宛先またはＲＥＳＰＯＮＳＥの送
信元のｓｕｂｕｎｉｔが何であるのか（機器）を示す。
ＩＥＥＥ１３９４フォーマットでは、機器そのものをｕ
ｎｉｔと称し、そのｕｎｉｔ（機器）内において備えら
れる機能的機器単位の種類をｓｕｂｕｎｉｔと称する。
例えば一般のＶＴＲを例に採れば、ＶＴＲとしてのｕｎ
ｉｔは、地上波や衛星放送を受信するチューナと、ビデ
オカセットレコーダ／プレーヤとの、２つのｓｕｂｕｎ
ｉｔを備える。ｓｕｂｕｎｉｔ−ｔｙｐｅとしては、例
えば図２２（ａ）に示すように定義されている。つま
り、［０００００］はＭｏｎｉｔｏｒ、［００００１］
〜［０００１０］はｒｅｓｅｒｖｅｄ、［０００１１］
はＤｉｓｃｒｅｃｏｒｄｅｒ／ｐｌａｙｅｒ、［００
１００］はＶＣＲ、［００１０１］はＴｕｎｅｒ、［０
０１１１］はＣａｍｅｒａ、［０１０００］〜［１１１
１０］はｒｅｓｅｒｖｅｄ、［１１１１１］は、ｓｕｂ
ｕｎｉｔが存在しない場合に用いられるｕｎｉｔとして
定義されている。

【００６６】図２０において、上記ｓｕｂｕｎｉｔ−ｔ
ｙｐｅに続く３ビットには、同―種類のｓｕｂｕｎｉｔ
が複数存在する場合に、各ｓｕｂｕｎｉｔを特定するた
めのｉｄ（Ｎｏｄｅ＿ＩＤ）が格納される。

【００６７】上記ｉｄ（Ｎｏｄｅ＿ＩＤ）に続く８ビッ
トの領域には、ｏｐｃｏｄｅが格納され、続く８ビット
の領域には、ｏｐｅｒａｎｄが格納される。ｏｐｃｏｄ
ｅとは、オぺレーションコード(Operation Code)のこと
であって、ｏｐｅｒａｎｄには、ｏｐｃｏｄｅが必要と
する情報（パラメータ）が格納される。これらｏｐｃｏ
ｄｅはｓｕｂｕｎｉｔごとに定義され、ｓｕｂｕｎｉｔ
ごとに固有のｏｐｃｏｄｅのリストのテーブルを有す
る。例えば、ｓｕｂｕｎｉｔがＶＣＲであれば、ｏｐｃ
ｏｄｅとしては、例えば図２２（ｂ）に示すようにし
て、ＰＬＡＹ（再生），ＲＥＣＯＲＤ（記録）などをは
じめとする各種コマンドが定義されている。ｏｐｅｒａ
ｎｄは、ｏｐｃｏｄｅ毎に定義される。

【００６８】図２０におけるｄａｔａｆｉｅｌｄとして
は、上記第６ｑｕａｄｌｅｔの３２ビットが必須とされ
るが、必要が有れば、これに続けて、ｏｐｅｒａｎｄを
追加することが出来る（Ａｄｄｉｔｉｏｎａｌｏｐｅ
ｒａｎｄｓ）。ｄａｔａｆｉｅｌｄに続けては、ｄａｔ
ａ＿ＣＲＣが配置される。なお、必要が有れば、ｄａｔ
ａ＿ＣＲＣの前にｐａｄｄｉｎｇを配置することが可能
である。

【００６９】１−１２．プラグここで、ＩＥＥＥ１３９４フォーマットにおけるプラグ
について概略的に説明する。ここでいうプラグとは、先
に図１８によっても説明したように、ＩＥＥＥ１３９４
フォーマットにおける機器間の論理的接続関係をいうも
のである。

【００７０】図２３に示すように、Ａｓｙｎｃｈｒｏｎ
ｏｕｓ通信において有効とされるコマンド等のデータ
（ｒｅｑｕｅｓｔ）は、ｐｒｏｄｕｃｅｒからｃｏｎｓ
ｕｍｅｒに対して伝送される。ここでいうｐｒｏｄｕｃ
ｅｒ及びｃｏｎｓｕｍｅｒは、それぞれＩＥＥＥ１３９
４インターフェイス上で送信機器、受信機器として機能
する機器をいうものである。そして、ｃｏｎｓｕｍｅｒ
においては、図に斜線で示すように、ｐｒｏｄｕｃｅｒ
によりデータ書き込みが行われるセグメントバッファ
（Segment Buffer）を備える。また、ＩＥＥＥ１３９４
システムにおいて、特定の機器をｐｒｏｄｕｃｅｒ、ｃ
ｏｎｓｕｍｅｒとして規定するための情報（Connection
Management Information）は、図に網線で示すプラグ
アドレス内の所定位置に格納されている。セグメントバ
ッファは、プラグアドレスに続いて配置される。ｃｏｎ
ｓｕｍｅｒのセグメントバッファに対して書き込み可能
なアドレス範囲（データ量）は、後述するようにしてｃ
ｏｎｓｕｍｅｒ側で管理するｌｉｍｉｔＣｏｕｎｔｒ
ｅｇｉｓｔｅｒによって規定される。

【００７１】図２４は、Ａｓｙｎｃｈｒｏｎｏｕｓ通信
におけるプラグのアドレス空間の構造を示している。６
４ビットから成るプラグのアドレス空間は、図２４
（ａ）に示すようにして、２の１６乗（６４Ｋ）のＮｏ
ｄｅに分割される。そして、プラグは、図２４（ｂ）に
示すようにして、各Ｎｏｄｅのアドレス空間内に在るよ
うにされる。そして、各プラグは、図２４（ｃ）に示す
ように、網線の領域により示すレジスタ（ｒｅｇｉｓｔ
ｅｒ）と、斜線の領域により示すセグメントバッファ(S
egment Buffer)とを含んで形成される。レジスタには、
次に説明するようにして、送信側（ｐｒｏｄｕｃｅｒ）
と受信側（ｃｏｎｓｕｍｅｒ）との間におけるデータの
授受管理に必要な情報（例えば、送信データサイズ及び
受信可能データサイズ）が格納される。セグメントバッ
ファは、ｐｒｏｄｕｃｅｒからｃｏｎｓｕｍｅｒに対し
て送信されたデータが書き込まれるべき領域であり、例
えば最小で６４バイトであることが規定されている。

【００７２】図２５（ａ）にはプラグアドレスが示され
ている。つまり、上記図２４（ｃ）と同一内容が示され
ている。この図に示すように、レジスタはプラグアドレ
スの先頭に対して配置され、これに続けてセグメントバ
ッファが配置される。そして、レジスタ内の構造として
は、図２５（ｂ）に示すようにして、先頭に対して、例
えば３２ビットのｐｒｏｄｕｃｅｒＣｏｕｎｔｒｅ
ｇｉｓｔｅｒが配置され、続けて、各３２ビットのｌｉ
ｍｉｔＣｏｕｎｔｒｅｇｉｓｔｅｒ［１］〜［１
４］が配置される。つまり、１つのｐｒｏｄｕｃｅｒ
Ｃｏｕｎｔｒｅｇｉｓｔｅｒと１４のｌｉｍｉｔＣ
ｏｕｎｔｒｅｇｉｓｔｅｒが設けられる。なお、ここ
では、ｌｉｍｉｔＣｏｕｎｔｒｅｇｉｓｔｅｒ［１
４］の後ろに未使用（ｕｎｕｓｅｄ）の領域が設けられ
ている。

【００７３】上記図２５（ａ）（ｂ）に示すプラグ構造
は、図２５（ｃ）に示すようにして、オフセットアドレ
ス(Address Offset)によって指定される。つまり、オフ
セットアドレス０は、ｃｏｎｓｕｍｅｒｐｏｒｔ（ｐ
ｒｏｄｕｃｅｒＣｏｕｎｔｒｅｇｉｓｔｅｒ）を指
定し、オフセットアドレス４，８，１２・・・５６，６
０は、それぞれｐｒｏｄｕｃｅｒｐｏｒｔ［１］〜
［１４］を指定する。オフセットアドレス６０はｒｅｓ
ｅｒｖｅｄとして定義されることで、未使用（ｕｎｕｓ
ｅｄ）の領域を示し、オフセットアドレス６４によりセ
グメントバッファを示す。

【００７４】図２６には、ｐｒｏｄｕｃｅｒ側とｃｏｎ
ｓｕｍｅｒ側との両者のプラグ構造が示されている。Ａ
ｓｙｎｃｈｒｏｎｏｕｓ通信のプラグ構造においては、
ｐｒｏｄｕｃｅｒＣｏｕｎｔｒｅｇｉｓｔｅｒへの書
き込み、ｌｉｍｉｔＣｏｕｎｔｒｅｇｉｓｔｅｒへ
の書き込み、及びセグメントバッファへの書き込みを後
述する送受信手順に従って行うことで、Ａｓｙｎｃｈｒ
ｏｎｏｕｓ通信を実現する。これらの書き込みは、先に
説明したＷｒｉｔｅＴｒａｎｓａｃｔｉｏｎとしての
処理である。

【００７５】ｐｒｏｄｕｃｅｒＣｏｕｎｔｒｅｇｉ
ｓｔｅｒは、ｐｒｏｄｕｃｅｒによってｃｏｎｓｕｍｅ
ｒに対して書き込みが行われる。ｐｒｏｄｕｃｅｒは、
自身のアドレスに在るｐｒｏｄｕｃｅｒＣｏｕｎｔｒ
ｅｇｉｓｔｅｒにｐｒｏｄｕｃｅｒ側のデータ伝送に関
する情報を書き込んだ上で、このｐｒｏｄｕｃｅｒＣ
ｏｕｎｔｒｅｇｉｓｔｅｒの内容を、ｃｏｎｓｕｍｅ
ｒのｐｒｏｄｕｃｅｒＣｏｕｎｔｒｅｇｉｓｔｅｒ
に対して書き込む。ｐｒｏｄｕｃｅｒＣｏｕｎｔｒ
ｅｇｉｓｔｅｒは、ｐｒｏｄｕｃｅｒがｃｏｎｓｕｍｅ
ｒのセグメントバッファに対して書き込むデータサイズ
として、１回の書き込み処理によって書き込むデータサ
イズの情報とされる。つまり、ｐｒｏｄｕｃｅｒが、ｐ
ｒｏｄｕｃｅｒＣｏｕｎｔｒｅｇｉｓｔｅｒの書き
込みを行うことによって、ｃｏｎｓｕｍｅｒのセグメン
トバッファに書き込むデータサイズを知らせる処理が行
われる。

【００７６】これに対して、ｌｉｍｉｔＣｏｕｎｔ
ｒｅｇｉｓｔｅｒは、ｃｏｎｓｕｍｅｒによってｐｒｏ
ｄｕｃｅｒに対して書き込みが行われる。ｃｏｎｓｕｍ
ｅｒ側では、自身のｌｉｍｉｔＣｏｕｎｔｒｅｇｉ
ｓｔｅｒ［１］〜［１４］のうち、ｐｒｏｄｕｃｅｒに
対応して指定された１つのｌｉｍｉｔＣｏｕｎｔｒ
ｅｇｉｓｔｅｒ［ｎ］に対して、自身のセグメントバッ
ファの容量（サイズ）を書き込み、このｌｉｍｉｔＣ
ｏｕｎｔｒｅｇｉｓｔｅｒ［ｎ］の内容を、ｌｉｍｉ
ｔＣｏｕｎｔｒｅｇｉｓｔｅｒ［ｎ］に対して書き
込む。

【００７７】ｐｒｏｄｕｃｅｒ側では、上記のようにし
てｌｉｍｉｔＣｏｕｎｔｒｅｇｉｓｔｅｒ［ｎ］に
書き込まれた内容に応じて、１回あたりの書き込みデー
タ量を決定して、例えば自身のセグメントバッファに対
して書き込みを行う。そして、このセグメントバッファ
に書き込んだ内容を、ｃｏｎｓｕｍｅｒに対して書き込
むようにされる。このセグメントバッファへの書き込み
が、Ａｓｙｎｃｈｒｏｎｏｕｓ通信におけるデータ送信
に相当する。

【００７８】１−１３．Asynchronous Connection送信
手順続いて、上記図２６により説明したプラグ（ｐｒｏｄｕ
ｃｅｒ−ｃｏｎｓｕｍｅｒ）間の構造を前提として、図
２７の処理遷移図により、Ａｓｙｎｃｈｒｏｎｏｕｓ
ｃｏｎｎｅｃｔｉｏｎの基本的な送受信手順について説
明する。図２７に示す送受信処理の手順は、Ａｓｙｎｃ
ｈｒｏｎｏｕｓ通信として、ＦＣＰによって規定された
環境のもとで、ＡＶ／Ｃコマンドを使用して行われる。
なお、Ａｓｙｎｃｈｒｏｎｏｕｓｃｏｎｎｅｃｔｉｏ
ｎの実際においては、コマンド送信に応じて、図１９に
示したように、Ａｃｋｎｏｗｌｅｄｇの送受信が実行さ
れるのであるが、図２７においてはＡｃｋｎｏｗｌｅｄ
ｇについての送受信処理の図示は省略している。

【００７９】また、ＩＥＥＥ１３９４インターフェイス
では、プラグ（機器）間の接続関係として、上記したｐ
ｒｏｄｕｃｅｒ−ｃｏｎｓｕｍｅｒの関係の他に、ｃｏ
ｎｔｒｏｌｌｅｒ−ｔａｒｇｅｔとして規定される関係
が存在する。ＩＥＥＥ１３９４システム上においては、
ｐｒｏｄｕｃｅｒ−ｃｏｎｓｕｍｅｒの関係が規定され
た機器と、ｃｏｎｔｒｏｌｌｅｒ−ｔａｒｇｅｔの関係
が機器とが必ずしも一致するものではない。つまり、ｐ
ｒｏｄｕｃｅｒとして規定された機器の他に、ｃｏｎｔ
ｒｏｌｌｅｒの機能を有するものとして規定された機器
が存在する場合がある。但し、ここでは、ｐｒｏｄｕｃ
ｅｒ−ｃｏｎｓｕｍｅｒとしての関係と、ｃｏｎｔｒｏ
ｌｌｅｒ−ｔａｒｇｅｔとしての関係が一致している場
合を例に説明する。

【００８０】図２７に示す送信手順としては、先ず、ス
テップＳ１０１として示すように、ｐｒｏｄｕｃｅｒか
らｃｏｎｓｕｍｅｒに対して、Ｃｏｎｎｅｃｔ要求を送
信する。このＣｏｎｎｅｃｔ要求は、ｐｒｏｄｕｃｅｒ
がｃｏｎｓｕｍｅｒに対して、接続要求を行うためのコ
マンドで、ｐｒｏｄｕｃｅｒのレジスタのアドレスをｃ
ｏｎｓｕｍｅｒに対して伝える。このＣｏｎｎｅｃｔ要
求は、ステップＳ１０２の処理としてｃｏｎｓｕｍｅｒ
が受信することで、ｃｏｎｓｕｍｅｒ側では、ｐｒｏｄ
ｕｃｅｒのレジスタのアドレスを認識する。そして、ス
テップＳ１０３により、ｒｅｓｐｏｎｃｅとして、ｃｏ
ｎｓｕｍｅｒは、ｐｒｏｄｕｃｅｒに対してＣｏｎｎｅ
ｃｔ受付を送信する。そして、ステップＳ１０４におい
て、ｐｒｏｄｕｃｅｒがこれを受信することで、以降の
データ送受信のためのｐｒｏｄｕｃｅｒ−ｃｏｎｓｕｍ
ｅｒ間の接続（ｃｏｎｎｅｃｔｉｏｎ）が確立される。

【００８１】上記のようにしてｃｏｎｎｅｃｔｉｏｎが
確立されると、ステップＳ１０５により、ｃｏｎｓｕｍ
ｅｒは、ｐｒｏｄｕｃｅｒに対してｌｉｍｉｔＣｏｕ
ｎｔｒｅｇｉｓｔｅｒ（（以降、単に「ｌｉｍｉｔＣ
ｏｕｎｔ」と略す））の書込要求を行う。ステップＳ１
０６によりこれを受信したｐｒｏｄｕｃｅｒは、続くス
テップＳ１０７の処理によって、ｌｉｍｉｔＣｏｕｎ
ｔ書込受付を、ｃｏｎｓｕｍｅｒに対して送信する。そ
して、ステップＳ１０８の処理として、ｃｏｎｓｕｍｅ
ｒがｌｉｍｉｔＣｏｕｎｔ書込受付を受信する。この
ｌｉｍｉｔＣｏｕｎｔ書込要求／書込受付の一連の処理
によって、以降における、セグメントバッファへのデー
タ書き込みサイズ（セグメントバッファ容量）が決定さ
れる。

【００８２】続くステップＳ１０９においては、ｐｒｏ
ｄｕｃｅｒからｃｏｎｓｕｍｅｒに対して、セグメント
バッファ書込要求を送信する。そして、ステップＳ１１
０によってセグメントバッファ書込要求が受信され、こ
れに応答して、ステップＳ１１１の処理として、ｃｏｎ
ｓｕｍｅｒからｐｒｏｄｕｃｅｒに対して、セグメント
バッファ書込受付を送信する。ｐｒｏｄｕｃｅｒは、ス
テップＳ１１２により、セグメントバッファ書込受付を
受信する。このステップＳ１０９〜Ｓ１１２までの処理
が実行されることで、１回のｐｒｏｄｕｃｅｒのセグメ
ントバッファからｃｏｎｓｕｍｅｒのセグメントバッフ
ァに対してデータへの書き込み処理が完了する。ここ
で、上記ステップＳ１０９〜Ｓ１１２の処理によって書
き込まれるデータは、図１３に示したＡｓｙｎｃｈｒｏ
ｎｏｕｓＰａｃｋｅｔによる１回の送信により書き込
まれる。従って、ＡｓｙｎｃｈｒｏｎｏｕｓＰａｃｋ
ｅｔにより転送されるデータサイズが、上記ｌｉｍｉｔ
Ｃｏｕｎｔによって指定されたデータサイズよりも小
さく、かつ、１回のＡｓｙｎｃｈｒｏｎｏｕｓＰａｃ
ｋｅｔによる送信によっては、必要なデータ送信が完了
しない場合には、セグメントバッファの容量がフルとな
る範囲で、ステップＳ１０９〜Ｓ１１２の処理が繰り返
されるようになっている。

【００８３】そして、上記したステップＳ１０９〜Ｓ１
１２に示すセグメントバッファへの書き込み処理が完了
すると、ステップＳ１１３の処理として示すように、ｐ
ｒｏｄｕｃｅｒからｃｏｎｓｕｍｅｒに対して、ｐｒｏ
ｄｕｃｅｒＣｏｕｎｔｒｅｇｉｓｔｅｒ（以降、単
にｐｒｏｄｕｃｅｒＣｏｕｎｔと略す）書込要求を送
信する。そしてｃｏｎｓｕｍｅｒでは、ステップＳ１１
４の処理として、ｐｒｏｄｕｃｅｒＣｏｕｎｔを受信
して、自身のｐｒｏｄｕｃｅｒＣｏｕｎｔｒｅｇｉｓ
ｔｅｒに書き込みを行い、続くステップＳ１１５の処理
として、ｐｒｏｄｕｃｅｒＣｏｕｎｔ書込受付をｐｒ
ｏｄｕｃｅｒに対して送信する。ｐｒｏｄｕｃｅｒはス
テップＳ１１６により、このｐｒｏｄｕｃｅｒＣｏｕ
ｎｔ書込受付を受信する。この処理によって、先のステ
ップＳ１０９〜Ｓ１１２の処理として、ｐｒｏｄｕｃｅ
ｒからｃｏｎｓｕｍｅｒのセグメントバッファに対して
転送したデータサイズがｃｏｎｓｕｍｅｒに対して知ら
されることになる。

【００８４】続くステップＳ１１７の処理としては、上
記ステップＳ１１３〜Ｓ１１６に示したｐｒｏｄｕｃｅ
ｒＣｏｕｎｔ書き込み処理に応答しての、ｌｉｍｉｔ
Ｃｏｕｎｔ書き込みのための一連の処理が実行され
る。つまり、ステップＳ１１７〜Ｓ１２０に示すように
して、ｃｏｎｓｕｍｅｒからｐｒｏｄｕｃｅｒへのｌｉ
ｍｉｔＣｏｕｎｔ書込要求の送信と、この送信に応答
してのｐｒｏｄｕｃｅｒからｃｏｎｓｕｍｅｒへのｌｉ
ｍｉｔＣｏｕｎｔ書込受付の送信が行われる。

【００８５】上記ステップＳ１０９〜Ｓ１２０までの処
理が、ＡｓｙｎｃｈｒｏｎｏｕｓＣｏｎｎｅｃｔｉｏｎ
におけるデータ伝送処理としての１セットの手順を成
す。ここで、例えば送信すべきデータサイズが、セグメ
ントバッファ容量よりも大きく、１回のステップＳ１０
９〜Ｓ１２０までの処理によっては、データの転送が完
了していないとされる場合には、このステップＳ１０９
〜Ｓ１２０までの処理を、データの転送が完了するまで
繰り返し実行することが出来るようになっている。

【００８６】そして、データの転送が完了したら、ステ
ップＳ１２１に示すようにして、ｐｒｏｄｕｃｅｒはｃ
ｏｎｓｕｍｅｒに対して、Ｄｉｓｃｏｎｎｅｃｔ要求を
送信する。ｃｏｎｓｕｍｅｒはステップＳ１２２におい
て、このＤｉｓｃｏｎｎｅｃｔ要求を受信し、続くステ
ップＳ１２３によりＤｉｓｃｏｎｎｅｃｔ受付を送信す
る。ステップＳ１２４において、ｐｒｏｄｕｃｅｒがＤ
ｉｓｃｏｎｎｅｃｔ受付を受信することで、Ａｓｙｎｃ
ｈｒｏｎｏｕｓＣｏｎｎｅｃｔｉｏｎによるデータ送
受信が完結する。

【００８７】２．マルチ再生システムの概要以上説明してきたＩＥＥＥ１３９４を利用して構築され
る本実施の形態のマルチ再生システムについて、以下説
明していく。

【００８８】図１は例えば家庭内などに構築される本例
のマルチ再生システムとともに、そのマルチ再生システ
ムにデータを提供できる情報配信システムも概要的に示
したものである。情報配信システムは、基本的には、一
般ユーザーの家庭２などで形成されているマルチ再生シ
ステムと、情報サービス組織としての情報センタ１とか
ら構成される。

【００８９】例えば家庭２内のシステムとされる、マル
チ再生システムは具体的には、例えば１つのデータサー
バ１０と、複数のターミナル５０（５０−１、５０−
２、５０−３，５０−４）から構成される。データサー
バ１０は、複数のデータ、例えば音楽データや映像デー
タを蓄積しており、各ターミナル５０からの要求に応じ
て、各ターミナル５０に対して音楽データや映像データ
を送信し、各ターミナル５０において再生出力させるこ
とができる。ターミナル５０は、例えば音声出力端末と
されたり、映像出力端末とされる端末装置となる。

【００９０】このようなマルチ再生システムに対して情
報配信を行うことのできる情報配信システムが形成され
る。この情報配信システムでは情報センタ１とデータサ
ーバ１０が、通信回線などの伝送路３を用いて各種情報
の通信が可能とされる。伝送路３は例えばＩＳＤＮ回線
などの公衆回線網としてもよいし、当該システムのため
の専用回線網などを構築してもよく、その回線の形態は
特に限定されない。また通信衛星４や各家庭２に設置し
たパラボラアンテナ５などを利用した衛星通信回線を構
成し、情報センタ１とデータサーバ１０との情報通信が
可能とされるようにしてもよい。

【００９１】一般ユーザーが使用する家庭内機器として
のデータサーバ１０は、詳しくは後述するが、内部に大
容量のデータファイル格納部（例えば図３のハードディ
スクドライブ１５）を備えるとともに、ＣＤ、ＭＤなど
のパッケージメディアのドライブ機能や、他の機器から
のデータ入力機能、伝送路３を介したデータ入力機能な
どを備えており、ＣＤ、ＣＤ−ＲＯＭ、ＭＤなどのユー
ザーが購入したメディアから再生されるオーディオデー
タ、ビデオデータ、その他の各種データや、他の機器や
伝送路３から入力される各種データを、それぞれファイ
ルとして格納していくことができる。

【００９２】そして格納されたファイル（例えば音楽等
を１曲単位で１つのファイルとして格納している）につ
いては、ユーザーが任意に再生させることなどが可能と
なる。従って、例えば多数のＣＤを有するユーザーが、
全ＣＤの全楽曲をそれぞれ１つのファイルとしてデータ
サーバ１０内に格納しておけば、わざわざＣＤ等を選び
出して装填しなくても、所望の楽曲等の再生を実行させ
ることができる。

【００９３】このようなデータサーバ１０に対して、情
報センタ１は有料又は無料で各種の情報を提供すること
ができる。例えばデータサーバ１０に格納されている楽
曲等のファイルデータを提供できる。つまり情報センタ
１はオーディオデータ自体、即ち楽曲等をデータサーバ
１０に送信し、ファイルとして格納させることで、いわ
ゆるパッケージメディアとしてのＣＤ等とは異なった楽
曲等の販売システムを構築することも可能である。ま
た、情報センタ１は、楽曲等のファイルデータに関連す
る情報として、曲名、アーティスト名、歌詞などのテキ
ストデータ、楽曲イメージやアーティストの画像などの
画像データ、アーティストのインターネットホームペー
ジのアドレス（ＵＲＬ：Uniform Resource Locator）、
著作権に関する情報、関係者名（作詞者、作曲者、制作
者等）・・・・などの情報を提供することができる。例
えばデータサーバ１０ではこれら情報センタから提供さ
れた情報を曲のファイルと対応させて格納しておき、表
示出力に利用するなど各種動作を行うことができる。

【００９４】また本例ではユーザーが使用する装置とし
て、データサーバ１０に対してターミナル５０が接続さ
れる。本例ではデータサーバ１０と各ターミナル５０−
１、５０−２、５０−３は、ＩＥＥＥ１３９４バス４０
によりデイジーチェイン接続されているものとする。な
お、ターミナル５０−４は無線方式でデータサーバ１０
と通信可能なモバイルターミナルとされた例を示してい
る。

【００９５】ターミナル５０についての種別や構成につ
いては後述するが、各ターミナル５０は、例えばそれぞ
れの部屋において、各ユーザがデータサーバ１０に対し
てリクエストを行い、それに応じて転送されてきたデー
タの出力を行うことができる装置である。つまりユーザ
ーはターミナル５０が配された各部屋から、データサー
バ１０における再生、データ転送の指示を出し、その転
送されたデータによる出力を見聞きできることになる。
しかも例えば複数のターミナル５０−１、５０−２から
データサーバ１０に同時に異なるリクエストを発した場
合や、同一の音楽データを多少の時間ずれを持ってリク
エストしたよううな場合でも、それに対応してターミナ
ル５０−１、５０−２では、それぞれ音声出力を行うこ
とができる。即ち各ターミナル５０は、データサーバ１
０を占有することなしに、占有と同等の状態で音楽、映
像の出力を実行できるものである。

【００９６】３．データサーバの構成データサーバ１０の外観例について図２に示す。なお、
ここで説明するのはあくまでも一例であり、外観やユー
ザーインターフェース構成（操作や表示のための構成）
などは他にも各種の例が考えられる。

【００９７】図２に示すようにデータサーバ１０は例え
ばユーザーの家庭での使用に適するように、いわゆるラ
ジカセ型の機器とされている。もちろんコンポーネント
タイプ或いはパーソナルコンピュータ的な外観のもので
もよい。このデータサーバ１０には、ユーザーが各種操
作を行うための各種の操作子Ｋａとして、操作キーや操
作つまみ、ジョグダイヤルと呼ばれる回動プッシュ式の
キーなどが、機器前面パネルなどに設けられている。ま
たユーザーに対する出力部位として、再生音声等を出力
するスピーカ３５や、各種情報を表示出力する表示部２
４が設けられる。表示部２４は例えば液晶パネルなどで
形成される。

【００９８】また、ユーザーが所有するＣＤ方式のディ
スク（オーディオＣＤ、ＣＤ−ＲＯＭ、ＣＤテキストな
ど）をデータサーバ１０で再生させたり、後述する内部
のハードディスクにデータダビング等を行うために、Ｃ
Ｄ方式のディスクを挿入するＣＤ挿入部１７ａが設けら
れる。同様に、ユーザーが所有するＭＤ方式のディスク
（オーディオＭＤ、ＭＤデータなど）をデータサーバ１
０で再生／再生させたり、内部のハードディスクにデー
タダビング等を行うために、ＭＤ方式のディスクを挿入
するＭＤ挿入部１８ａが設けられる。

【００９９】また、他の機器との接続を行うための各種
の端子ｔａが用意される。これらは、マイクロホン、ヘ
ッドホンの接続に用いられる部位とされたり、他のオー
ディオビジュアル機器やパーソナルコンピュータ等と接
続できるライン接続端子、光デジタル接続端子、インタ
ーフェースコネクタ等とされている。

【０１００】また、ユーザーの操作入力の手段として
は、上記操作子Ｋａ以外に、キーボード９０やリモート
コマンダー９１を用いることができる。キーボード９０
は端子ｔａとしてのキーボード用コネクタを介して接続
して用いるようにしたり、或いは赤外線送信部をキーボ
ード９０に搭載した場合は、キーボード９０からの操作
情報を赤外線無線方式で出力し、受光部２１からデータ
サーバ１０に入力させることもできる。リモートコマン
ダー９１は例えば赤外線方式で操作情報を出力する。そ
してその赤外線信号による操作情報は受光部２１からデ
ータサーバ１０に入力される。なお、キーボード９０を
無線方式とする場合の操作情報の出力や、リモートコマ
ンダー９１からの操作情報の出力は、赤外線ではなく電
波を用いるようにしてもよい。

【０１０１】またデータサーバ１０にはＰＣＭＣＩＡス
ロット３９が形成され、ＰＣＭＣＩＡカードを装着して
のデータのやりとりが可能とされている。

【０１０２】続いてデータサーバ１０の内部構成例を図
３で説明する。このデータサーバ１０には、パネル操作
部２０としてプッシュ式や回動式の操作子が設けられて
いる。ここでいう操作子とは、図２に示した各種操作子
Ｋａに相当する。つまり機器筐体上に形成される各種操
作子である。なお、図２では説明していなかったが、表
示部２４に操作キー表示を行うとともに表示部２４上で
のタッチ検出機構を設けることで、タッチパネル操作子
を形成してもよく、その場合のタッチパネル操作子も図
３でいうパネル操作部２０に含まれるものとなる。この
パネル操作部２０が操作されることにより、データサー
バ１０の各種動作を実行させるための操作信号が送出さ
れ、データサーバ１０はこの操作信号に応じて動作され
る。

【０１０３】また、例えば記録される音楽データ、映像
データに対応する曲名、アーティスト名等の入力を容易
にするために、上記したようにキーボード９０やリモー
トコマンダー９１を利用することができるが、ＵＳＢ(u
niversal serial bus)端子ｔａ６にキーボード９０を接
続することで、キーボード９０による入力が可能とな
る。即ちキーボード９０からの入力信号（操作信号）は
ＵＳＢ端子ｔａ６を介してＵＳＢドライバに供給される
ことで、データサーバ１０の内部に取り込むことができ
る。なお、図３における各種の端子ｔａ１〜ｔａ７は、
それぞれ図２に示した端子ｔａのうちの１つに相当す
る。

【０１０４】またリモートコマンダー９１からの赤外線
による操作信号（及びキーボード９０が赤外線出力を行
う場合の操作信号）は、その赤外線操作信号は受光部２
１で光電変換され、赤外線インターフェースドライバ２
２に供給されることで、データサーバ１０の内部に取り
込むことができるようにされている。

【０１０５】なお、赤外線インターフェースドライバ２
２、或いはＵＳＢドライバ２３を介してデータ転送出力
を行うように構成してもよい。

【０１０６】このデータサーバ１０には通常のパーソナ
ルコンピュータの構成であるＲＡＭ１３、ＲＯＭ１２、
フラッシュメモリ１４が設けられており、ＣＰＵ１１に
よりデータサーバ１０の全体の動作制御が行われる。ま
た各ブロック間でのファイルデータや制御データの授受
はバスＢ１を介して行われる。

【０１０７】ＲＯＭ１２にはパネル操作部２０が操作さ
れることにより入力される入力信号（もしくはキーボー
ド９０やリモートコマンダー９１からの入力信号）に応
じてデータサーバ１０の動作を制御するプログラム等が
記憶されている。またＲＡＭ１３、フラッシュメモリ１
４にはプログラムを実行する上でのデータ領域、タスク
領域が一時的に確保される。または、ＲＯＭ１２にはプ
ログラムローダーが記憶されており、そのプログラムロ
ーダーによりフラッシュメモリ１４にプログラム自体が
ロードされることも可能である。

【０１０８】ＣＤ−ＲＯＭドライブ１７にはＣＤ方式の
光ディスク（オーディオＣＤ、ＣＤ−ＲＯＭ、ＣＤテキ
スト等）が、上記ＣＤ挿入部１７ａから装着されると共
に、１倍速或いはより高速、例えば１６倍速、３２倍速
で光学ピックアップにより光ディスクに記憶される情報
が読み出される。またＭＤドライブ１８にはＭＤ方式の
光ディスク又は光磁気ディスク（オーディオＭＤ、ＭＤ
データ等）が上記ＭＤ挿入部１８ａから装着されると共
に、光学ピックアップによりディスクに記憶される情報
が読み出される。もしくは装填されたディスクに対して
情報の記録を行うことができる。なお、本例ではＣＤ−
ＲＯＭドライブ１７、ＭＤドライブ１８を設けた例をあ
げているが、このいづれか一方のみを設けたり、もしく
は情報が記憶されているメディアとして他のメディア
（例えばＭＯディスクと呼ばれる光磁気ディスクや他の
方式の光ディスク、磁気ディスク、メモリカード等）に
対応するドライブが設けられてもかまわない。

【０１０９】このデータサーバ１０の内部の大容量の格
納手段としては、ハードディスクに対して情報の記録再
生を行うハードディスクドライブ（hard disk drive ：
以下ＨＤＤという）１５が設けられている。例えばＣＤ
−ＲＯＭドライブ１７やＭＤドライブ１８から読み出さ
れる音楽データなどを、ＨＤＤ１５においてファイル単
位（例えば１曲が１ファイル）で格納できる。

【０１１０】また、オーディオデータに関してＡＴＲＡ
Ｃ２方式（Adaptive Transform Acoustic Coding 2）の
圧縮エンコードを行うエンコーダ２８、及びオーディオ
データに関してＡＴＲＡＣ２方式の圧縮に対するデコー
ドを行うデコード２９が設けられる。エンコーダ２８、
デコーダ２９はＣＰＵ１１の制御に応じて、供給された
オーディオデータに関するエンコード、デコードを行
う。また処理対象となっているオーディオデータを一時
的に格納するためのバッファメモリ１６が設けられる。
バッファメモリ１６はＣＰＵ１１の制御によりデータの
書込／読出が行われる。

【０１１１】例えばＣＤ−ＲＯＭドライブ１７でディス
クから読み出されたオーディオデータをＨＤＤ１５に格
納する場合、ＨＤＤ１５にオーディオデータを記憶する
前処理として、バッファメモリ１６にディスクから読み
出されたオーディオデータが一時記憶されると共に、そ
のオーディオデータがエンコーダ２８に供給されてＡＴ
ＲＡＣ２方式のエンコードが行われる。さらにエンコー
ダ２８でエンコードされたデータがバッファメモリ１６
に再び一時記憶され、最終的にＨＤＤ１５にエンコード
されたオーディオ情報が蓄積されることになる。

【０１１２】なお本例では、エンコーダ２８によりＡＴ
ＲＡＣ２方式でエンコードされたオーティオデータがＨ
ＤＤ１５に蓄積されるようにしているが、例えばＣＤ−
ＲＯＭドライブ１７から読み出されるデータがそのまま
ＨＤＤ１５に蓄積されるようにしてもかまわない。

【０１１３】エンコーダ２８では、ＣＤ−ＲＯＭドライ
ブ１７に装着されるメディアから読み出されたデータが
エンコードされるだけではなく、マイクロホンが接続さ
れたマイク端子ｔａ３からアンプ３２を介して入力され
るオーディオ信号、或いは他のＣＤプレーヤ等の機器が
接続されたライン入力端子ｔａ２から入力されるオーデ
ィオ信号が、Ａ／Ｄ変換器３１を介して入力されるよう
に構成されており、これらの入力された音楽データもエ
ンコーダ２８によりエンコードすることができる。更
に、光デジタル端子ｔａ４に接続された外部機器（例え
ばＣＤプレーヤ等）から入力されたデータがＩＥＣ９５
８(International Electrotechnical Commission 958)
エンコーダ３０を介してエンコーダ２８に入力されるよ
うに構成され、このように光デジタル方式で入力された
データもエンコーダ２８によりエンコードできる。

【０１１４】そして、これらのように外部機器から入力
されたデータをエンコーダ２８でエンコードした後に、
そのエンコードされたデータをＨＤＤ１５にファイル単
位で格納できるようにされている。

【０１１５】なおエンコーダ２８のエンコードアルゴリ
ズムとしてはＡＴＲＡＣ２（商標）を用いたが、情報圧
縮されるエンコードアルゴリズムであればよく、ＡＴＲ
ＡＣ又はＡＴＲＡＣ３（商標）、ＭＰＥＧ(moving pict
ure coding experts group)、ＰＡＳＣ(precision adap
tive sub-band coding)、ＴｗｉｎＶＱ（商標）、Ｒｅ
ａｌＡｕｄｉｏ（商標）、ＬｉｑｕｉｄＡｕｄｉｏ（商
標）等であってもかまわない。

【０１１６】またデータサーバ１０には、伝送路３とし
て通信端子ｔａ５に接続される、外部ネットワークであ
るインターネット、ＴＥＬネットワーク、ケーブルＴ
Ｖ、ワイヤレスネットワーク等に接続可能なインターフ
ェースであるモデム１９が備えられている。これによ
り、伝送路３で通信可能な外部ネットワークのサーバと
の間で各種の情報のダウンロード、アップロードなどが
可能となる。例えば曲や曲集としての音楽データや、映
画、テレビ番組等の映像データの配信を受けたり、これ
らの音楽や映像の付加情報、例えばタイトル、アーティ
スト名、作曲家、作詞家、歌詞、ジャケットイメージ等
の提供を受けたり、あるいは逆にユーザー側から情報を
提供することなどができる。

【０１１７】ＨＤＤ１５に蓄積された音楽データ等は、
デコーダ２９によりデコードされ、Ｄ／Ａ変換器３３、
アンプ３４を介してスピーカ３５により再生出力するこ
とができる。もしくはヘッドホン端子ｔａ１にヘッドホ
ンを接続することで、ヘッドホンより再生出力させるこ
とができる。ここではデコーダ２９はＡＴＲＡＣ２方式
のデコードを行うものとしているが、エンコーダ２８の
エンコードアルゴリズムに対応するデコードアルゴリズ
ムであればよい。また、ここでエンコード及びデコード
はハードウェアを持たず、ＣＰＵ１１によるソフトウェ
ア処理であってもよい。

【０１１８】更に、ＨＤＤ１５に蓄積される音楽データ
等のファイルをユーザが管理、制御するためのインター
フェースとして、図２にも示したように表示部２４が設
けられているが、表示部２４は表示ドライバ２５によっ
て表示駆動される。表示部２４ではＣＰＵ１１の制御に
基づいて所要の文字、記号、アイコン等が表示される。
また表示部２４には各種ファイルに対応するフォルダ、
或いはジャケットイメージが表示され、マウス、ペン、
ユーザの指で触れる等の、パネル操作部２０に該当する
ことになるポインティングデバイスによる操作が可能と
される。例えば表示上でユーザーが指示したファイルが
再生されるような動作が可能となる。なお、ファイルと
は、楽曲等の音楽データや各種の管理情報としてのデー
タファイルのことである。

【０１１９】また表示部２４での表示を用いて、選択さ
れたファイルの消去や、外部機器、例えばターミナル５
０への複写、移動等も制御可能である。或いは、表示部
２４は、ＣＤ−ＲＯＭドライブ１７に装着されるメディ
アのＴＯＣ(table of contents) 情報を基にインターネ
ット上のＷＷＷ(world wide web)サイトから検索された
関連情報としてのｈｔｍｌ(hyper text markup laguag
e) 文書がグラフィック表示されるように構成され、更
に通常のインターネットブラウザとしても使用可能とな
っている。

【０１２０】またデータサーバ１０では、ＩＥＥＥ１３
９４インターフェース３７を介して端子ｔａ７に接続さ
れたＩＥＥＥ１３９４バス４０により、複数のターミナ
ル５０と通信可能に接続される。

【０１２１】更なる付加機能としてＰＣＭＣＩＡ(Perso
nal Computer Memory Card International Associatio
n) スロット３９がＰＣＭＣＩＡドライバ３８を介して
設けられ、ＰＣＭＣＩＡカードが装着可能となってお
り、外部記憶装置、その他のメディアドライブ、モデ
ム、ターミナルアダプタ、キャプチャボード等様々な周
辺機器の拡張が容易である。

【０１２２】４．ターミナルの構成続いてターミナル５０の外観例及び内部構成例を説明す
る。ターミナル５０は、例えば家庭内でデータサーバ１
０とは異なる部屋などに配置され、上述したようにＩＥ
ＥＥ１３９４バス４０により接続される。図４（ａ）は
音声出力を目的としたターミナル５０（以下、スピーカ
ターミナル５０ｓ）の外観例を示し、また図４（ｂ）は
主に映像出力を目的としたターミナル５０（以下、ディ
スプレイターミナル５０ｄ）の外観例を示している。タ
ーミナル５０としては、この図４（ａ）（ｂ）のよう
に、各種の形態が考えられる。もちろんこれらの例のみ
に限定されるものではない。

【０１２３】図４（ａ）のスピーカターミナル５０ｓに
は、ユーザーが各種操作を行うための操作部５１が形成
される。操作部５１における操作子としては、例えば電
源オン／オフを行う電源キー５１ａ、データサーバ１０
に蓄積された音楽データの選択操作を行うための選択キ
ー５１ｂ、出力音量調節（アップ／ダウン）を行うため
のボリュームキー５１ｃ、再生／一時停止を指示する再
生キー５１ｄ、出力音声の早送りを行う早送りキー５１
ｅ、出力音声の早戻しを行う早戻しキー５１ｆなどが形
成されている。これらの操作子の数、種別、形態は一例
であり、さらに必要な各種操作のための操作キーが設け
られてもよい。またキーではなく、ジョグダイヤルなど
の形態の操作子を設けてもよい。

【０１２４】またユーザーに対する出力部位として、再
生音声を出力するスピーカ５３や、各種情報を表示出力
する表示部５２Ｓが設けられる。表示部５２Ｓは例えば
液晶パネルなどの小型画面で形成される。

【０１２５】このようなスピーカターミナル５０ｓが配
置された部屋においては、ユーザーは、選択キー５１ｂ
の操作によりデータサーバ１０に格納されている曲を選
択して、その選択された曲の送信をリクエストできる。
例えば選択時には選択キー５１ｂの操作に応じて選択候
補の曲名又はアルバム名などが表示部５２Ｓに表示され
る。なお、曲名などの情報は、選択操作に応じてデータ
サーバ１０から送信されてくるものである。そして望み
の曲等が表示された状態で、再生キー５１ｄを操作する
ことで、その再生指示がデータサーバ１０に送信され
る。これは選択決定及びその選択された音楽データのリ
クエスト信号として機能する。するとデータサーバ１０
では、リクエスト信号に応じて選択された音楽データの
再生及びこのスピーカターミナル５０ｓへの送信を実行
する。それによってスピーカターミナル５０ｓでは送信
されてきた音楽データについてスピーカ５３から再生音
を出力できることになる。

【０１２６】図４（ｂ）のディスプレイターミナル５０
ｄの場合も、ユーザーが各種操作を行うための各種操作
子を備えた操作部５１が形成される。またユーザーに対
する出力部位として、再生音声を出力するスピーカ５３
や、各種情報を表示出力する表示部５２Ｌが設けられ
る。表示部５２Ｌは例えば動画映像、静止画映像などの
表示を主たる目的として搭載され、従って、ＣＲＴもし
くは液晶パネルなどにより、比較的大きな画面として形
成される。

【０１２７】このようなディスプレイターミナル５０ｄ
が配置された部屋においては、ユーザーは、選択キー５
１ｂの操作によりデータサーバ１０に格納されている映
像データを選択して、その選択された映像データの送信
をリクエストできる。即ち上記スピーカターミナル５０
ｓの場合と同様に、例えば選択時には選択キー５１ｂの
操作に応じて選択候補の映像タイトルなどがデータサー
バ１０から送信され、表示部５２Ｌに表示される。そし
て望みの映像データ名等が表示された状態で、再生キー
５１ｄを操作することで、その再生指示がデータサーバ
１０に送信される。つまり選択決定及びその選択された
映像データのリクエスト信号として送信される。すると
データサーバ１０では、リクエスト信号に応じて選択さ
れた映像データの再生及びこのディスプレイターミナル
５０ｄへの送信を実行する。それによってディスプレイ
ターミナル５０ｄでは送信されてきた映像データ（音声
データを含む）について表示部５２Ｌに表示出力すると
ともに、音声をスピーカ５３から出力できることにな
る。

【０１２８】スピーカターミナル５０ｓの構成を図５に
示す。スピーカターミナル５０ｓは端子５４にＩＥＥＥ
１３９４バス４０が接続されることで、ＩＥＥＥ１３９
４インターフェース５５を介して、データサーバ１０又
は他のターミナル５０に対して通信可能に接続される。
コントローラ５６は、スピーカターミナル５０ｓ内にお
ける出力動作、通信動作の制御を行う。即ち操作部５１
の操作に基づいてデータサーバ１０へ選択信号やリクエ
スト信号の送信動作の実行、音楽データの受信、各種通
信におけるアクナレッジの送信／受信など、上述したＩ
ＥＥＥ１３９４方式にのっとって、データサーバ１０と
の間の通信動作を実行する。

【０１２９】また送信されてきた音楽データをバッファ
リングするデータバッファ５７が設けられる。コントロ
ーラ５６は、データバッファ５７に対する音楽データの
書込、読み出しの制御も行う。さらにコントローラ５６
は、データサーバ１０から送信されてきた曲名その他の
表示データを表示ドライブ６３に供給し、表示部５２Ｓ
における表示を実行させる。

【０１３０】データサーバ１０から送信されてきた音楽
データ（ストリームデータ）は、データバッファ５７に
一時的に記憶された後、音楽等としての出力タイミング
に合わせたレートでデータバッファ５７から読み出さ
れ、オーディオデコーダ６０に供給される。オーディオ
デコーダ６０では音楽データについて必要なオーディオ
処理を行う。例えば音楽データがＡＴＲＡＣデータとし
て送信されてきた場合は、ＡＴＲＡＣ方式の圧縮に対す
る解凍処理を行なう。そしてデコードされたデータはＤ
／Ａ変換器６１でアナログオーディオ信号とされた後、
アンプ６２で増幅され、スピーカ５３から出力される。
なおコントローラ５６は操作部５１の操作に応じて、出
力ボリューム調整のためのアンプ６２におけるゲイン制
御も行う。

【０１３１】ディスプレイターミナル５０ｄの構成を図
６に示す。ディスプレイターミナル５０ｄも、端子５４
にＩＥＥＥ１３９４バス４０が接続されることで、ＩＥ
ＥＥ１３９４インターフェース５５を介して、データサ
ーバ１０又は他のターミナル５０に対して通信可能に接
続される。スピーカターミナル５０ｓの場合と同様に、
コントローラ５６は、ディスプレイターミナル５０ｄ内
における出力動作、通信動作の制御を行う。

【０１３２】また送信されてきた映像データをバッファ
リングするデータバッファ５７が設けられる。コントロ
ーラ５６は、データバッファ５７に対する映像データの
書込、読み出しの制御も行う。さらにコントローラ５６
は、データサーバ１０から送信されてきたデータ名その
他の表示データを表示ドライブ６３に供給し、表示部５
２Ｓにおける表示を実行させる。

【０１３３】データサーバ１０から送信されてきた映像
データ（ストリームデータ）は、データバッファ５７に
一時的に記憶された後、映像出力タイミングに合わせた
レートでデータバッファ５７から読み出され、ビデオデ
コーダ６３に供給される。ビデオデコーダ６３では映像
データについて必要なデコード処理を行う。例えば映像
データがＭＰＥＧＣデータとして送信されてきた場合
は、ＭＰＥＧデコードを行なうなどである。さらに、デ
コードした映像データを、表示部５２Ｌとしてのデバイ
スの種別に応じた映像ドライブ信号に変換し、表示ドラ
イブ６３に供給する。例えばＲ、Ｇ、Ｂの画像信号、水
平同期信号、垂直同期信号として供給する。そして表示
ドライブ６４が表示部５２Ｌを駆動することで、映像表
示が実行される。

【０１３４】映像データに付随するオーディオデータは
オーディオデコーダ６０に供給される。例えばＭＰＥＧ
オーディオのデコード処理が行われる。そしてデコード
されたデータはＤ／Ａ変換器６１でアナログオーディオ
信号とされた後、アンプ６２で増幅され、スピーカ５３
から出力される。なおコントローラ５６は操作部５１の
操作に応じて、出力ボリューム調整のためのアンプ６２
におけるゲイン調整を行う。

【０１３５】以上のターミナル５０の構成例は一例であ
り、出力態様として、２チャンネル、３チャンネル以上
のマルチスピーカ出力とされたり、ヘッドホンが接続さ
れたり、或いは他のＡＶ機器、コンピュータ機器との間
の接続が可能とされたりしてもよい。

【０１３６】５．通信／再生動作以上のようなデータサーバ１０及び複数のターミナル５
０によるマルチ再生システムでは、以下のような動作が
実現される。なお、データサーバ１０と各ターミナル５
０の間の通信は、具体的にはＩＥＥＥ１３９４の説明に
おいて詳述した方式及び手順で行われることになる。そ
して例えばデータ（音響データ、映像データ）の通信
は、Ｉｓｏｃｈｒｏｎｏｕｓ通信とされ、リクエスト信
号やその他のコマンド、制御データ（ターミナル５０に
おける曲名等の表示データを含む）についてはＡｓｙｎ
ｃｈｒｏｎｏｕｓ通信により行われる。

【０１３７】各ターミナル５０を操作するユーザーは、
それぞれ任意にデータサーバ１０に対してデータ（音楽
データや映像データなど）を要求し、その出力を楽しむ
ことができる。例えばスピーカターミナル５０ｓが設置
された部屋からは、上述のように音楽データの選択操作
を行うことで、リクエスト信号がデータサーバ１０に対
して送信される。そしてそれに応じてデータサーバ１０
がリクエストされたデータをＨＤＤ１５から読み出し、
ＩＥＥＥ１３９４バス４０により送信してくる。これに
よりスピーカターミナル５０ｓでは、送信されてきたデ
ータを出力できる。またデータサーバ１０が音楽データ
に付随する表示データを送信してくることで、表示部５
２Ｓにおいて曲名等の表示出力も可能である。ディスプ
レイターミナル５０ｄの場合も同様であり、任意の映像
データ、音楽データの出力が可能となる。

【０１３８】また、このような各ターミナル５０からの
要求は、時間的に重なってもかまわない。即ちデータサ
ーバ１０が各リクエストに対して時分割的処理によりデ
ータの再生及び送信を行うようにすればよい。図７に
は、例えば２つのターミナル５０ｘ、５０ｙ（５０ｘ、
５０ｙはスピーカターミナルの例とする）において、時
間的に重複してデータ出力を実行する場合の処理の様子
を模式的に示している。なお図７はあくまで概略的に示
したもので、各通信の細かい手順は前述したＩＥＥＥ１
３９４方式にのっとったものとなる。

【０１３９】例えばｔ０時点でターミナル５０ｘがデー
タサーバ１０に対して音楽データＭ１の再生及び送信の
リクエスト信号を発したとする。データサーバ１０は、
このリクエスト信号を受信すると、続いてｔ１時点から
音楽データＭ１のＨＤＤ１５からの再生動作を開始する
とともに、その再生された音楽データＭ１についてＩＥ
ＥＥ１３９４インターフェース３７を介した送信動作を
開始する。

【０１４０】このときターミナル５０ｘでは、送信され
てきた音楽データＭ１をデータバッファ５７にバッファ
リングしていくと共に、バッファリングしたデータにつ
いて先頭のデータからの所定レートでの読み出し、及び
オーディオデコーダ６０でのデコードを開始し、つまり
スピーカ５３からの出力を開始する。このとき曲名等の
表示データもデータサーバ１０から送信されてくるた
め、表示部５２Ｓにおける表示も行う。

【０１４１】このようにしてターミナル５０ｘにおいて
音楽データＭ１の再生出力が継続されている途中である
ｔ２時点において、他のターミナル５０ｙが、データサ
ーバ１０に対して音楽データＭ２の再生及び送信のリク
エスト信号を発したとする。データサーバ１０は、この
リクエスト信号を受信すると、一旦ターミナル５０ｘに
対する音楽データＭ１の再生／送信を中断し、ｔ３時点
から音楽データＭ２のＨＤＤ１５からの再生動作を開始
するとともに、その再生された音楽データＭ２について
ターミナル５０ｙに対するＩＥＥＥ１３９４インターフ
ェース３７を介した送信動作を開始する。このときター
ミナル５０ｙでは、送信されてきた音楽データＭ２をデ
ータバッファ５７にバッファリングしていくと共に、バ
ッファリングしたデータについて先頭のデータからの所
定レートでの読み出し、及びオーディオデコーダ６０で
のデコードを開始し、つまりスピーカ５３からの出力や
表示部５２Ｓ（５２Ｌ）での曲名等の付随データの表示
を開始する。

【０１４２】ここでｔ２〜ｔ４期間は、ターミナル５０
ｘに対する音楽データＭ１の送信が行われていないが、
ターミナル５０ｘにおいてはｔ２時点までにバッファリ
ングしたデータによる出力が継続される。ただし例えば
ｔ４時点以降においてバッファリングデータについての
すべての出力が終了してしまうとすると、データサーバ
１０はｔ４時点において、ターミナル５０ｙに対する音
楽データＭ２の再生／送信を中断し、ターミナル５０ｘ
に対する音楽データＭ２の再生／送信を再開する。従っ
てターミナル５０ｘでは再びバッファリングを行い、ま
たデータ出力を継続できることになる。以降は、同様
に、各ターミナル５０ｘ、５０ｙにおいてデータ出力が
継続できるように（つまり出力されている音楽がとぎれ
ないように）、データサーバ１０はｔ５〜ｔ６期間はタ
ーミナル５０ｙに対する音楽データＭ２の再生／送信を
行い、ｔ６〜ｔ７期間はターミナル５０ｘに対する音楽
データＭ１の再生／送信を行なう。ここでｔ７時点で、
ターミナル５０ｘに対する音楽データＭ１の再生／送信
が完了したとする。ターミナル５０ｘでは、そのｔ７時
点までにバッファリングされたデータの出力を完了する
時点ｔ８で、音楽データＭ１の出力が完了することにな
る。従ってｔ７時点以降は、データサーバ１０はターミ
ナル５０ｙに対する音楽データＭ２の再生／送信を継続
できる。そしてｔ９時点で、ターミナル５０ｙに対する
音楽データＭ２の再生／送信が完了したとすると、ター
ミナル５０ｙでは、そのｔ９時点までにバッファリング
されたデータの出力を完了する時点ｔ１０で、音楽デー
タＭ２の出力が完了することになる。

【０１４３】例えば以上のように各ターミナルからの要
求に対してデータサーバ１０が時分割処理で対応するこ
とで、複数のターミナル５０に対応してデータ送信を行
うことができる。もちろん、ＨＤＤ１５からの再生動作
についても時分割で対応することで、異なるデータであ
ろうと、同一のデータであろうと、複数のターミナル５
０の各リクエストに対応して送信できるものである。即
ち各ターミナル５０において、異なる時間でのデータ利
用はもちろん、同一時間帯に同一又は異なるデータを利
用することが可能となる。そしてこれによってデータの
有効利用や各個人での都合に応じた再生出力が実現され
るものとなる。またこのようなマルチ再生システムによ
れば、音楽データ、映像データのソースはデータサーバ
１０内の記録媒体、例えばＨＤＤ１５のような記録媒体
や、データサーバ１０で再生可能なリムーバブルメディ
ア、例えばＣＤ、ＭＤ、メモリカードなどとなり、さら
に、図１のように情報センタから配信されたデータも利
用できる。つまり非常に幅広い範囲で多量かつ多様なデ
ータを利用でき、しかも各ターミナルにはそれらのデー
タ（メディア）の再生機能を備える必要はないものとな
る。従ってデータサーバ１０によりユーザーが利用可能
なデータが多種多様となり、かつターミナル５０は簡易
な構成で安価なものを提供できるため、ユーザーの負担
も小さい。そしてターミナル５０を複数配することで上
述のように任意にデータを利用できるため、ユーザーに
とって非常に有用なシステムとできることになる。

【０１４４】６．変形例図２８にマルチ再生システムの変形例を示す。この変形
例では、データサーバ１０に対して各ターミナル５０−
１、５０−２，５０−３がＩＥＥＥ１３９４バス４０に
よりブランチ接続されている。なおデータサーバ１０の
構成は基本的に図３と同様となり、図２８では変形例と
しての要部のみを示している。

【０１４５】上述した例では、各ターミナル５０におい
てデータバッファ５７を備えるようにしたが、この変形
例では、データサーバ１０に、各ターミナル５０−１、
５０−２，５０−３に対応するデータバッファ１６ａ、
１６ｂ、１６ｃを備えるようにしたものである。そして
複数のターミナル５０から同時間帯にリクエストが発生
した場合は、ＣＰＵ１１は時分割処理でＨＤＤ１５から
のデータ再生とデータバッファ１６ａ、１６ｂ、１６ｃ
へのバッファリングを行っていくようにする。そしてデ
ータバッファ１６ａ、１６ｂ、１６ｃへバッファリング
された各データは、それぞれ連続的に各ターミナル５０
−１、５０−２，５０−３に送信される。従って各ター
ミナル５０−１、５０−２，５０−３は、単にリクエス
ト操作機能と、送信されてきたデータについての出力機
能のみが設けられればよく、これによって各ターミナル
５０の構成の簡易化やコストダウンをはかることができ
る。

【０１４６】以上、実施の形態としてのシステム構成や
動作例を説明してきたが、本発明はこれらの例に限定さ
れることなく、データサーバやターミナルの構成や処理
機能などは各種多様に考えられる。またもちろん本発明
のマルチ再生システムは家庭内にとどまらず、職場、学
校、サービス施設など、多様な場所で利用できるもので
ある。

【０１４７】

【発明の効果】以上の説明からわかるように本発明によ
れば、例えば家庭内の各部屋などに端末装置を配し、各
端末装置からサーバ装置に対してリクエスト信号で再生
データの転送を要求することで、各端末装置において、
サーバ装置に蓄積されているデータを利用、つまり再生
出力できる。しかもその利用は他の端末装置の要求状況
に関わらず、時間的かつデータ的に自由に所望の再生を
実現させることが可能となる。例えば各端末装置におい
て異なる時間でのデータ利用はもちろん、同一時間帯に
同一又は異なるデータを利用することなども可能とな
る。そしてこれによってデータの有効利用や各個人での
都合に応じた再生出力が実現される。さらにこのような
システムはＩＥＥＥ１３９４方式で接続することや、デ
イジーチェイン接続によるものとすることで容易に構築
できる。またサーバ装置には、外部装置から通信により
供給されたデータ、又は記録媒体から再生されたデータ
を、上記蓄積手段に蓄積できるようにすることで、利用
できるデータの蓄積は容易となり、かつ多様なデータを
蓄積できる。

【図面の簡単な説明】

【図１】本発明の実施の形態のマルチ再生システムを含
む情報配信システムの説明図である。

【図２】実施の形態のデータサーバの説明図である。

【図３】実施の形態のデータサーバのブロック図であ
る。

【図４】実施の形態のターミナルの説明図である。

【図５】実施の形態のスピーカターミナルのブロック図
である。

【図６】実施の形態のディスプレイターミナルのブロッ
ク図である。

【図７】実施の形態の通信／再生動作の説明図である。

【図８】ＩＥＥＥ１３９４のスタックモデルを示す説明
図である。

【図９】ＩＥＥＥ１３９４に使用されるケーブル構造を
示す説明図である。

【図１０】ＩＥＥＥ１３９４における信号伝送形態を示
す説明図である。

【図１１】ＩＥＥＥ１３９４におけるバス接続規定を説
明するための説明図である。

【図１２】ＩＥＥＥ１３９４システム上でのＮｏｄｅ
ＩＤ設定手順の概念を示す説明図である。

【図１３】ＩＥＥＥ１３９４におけるＰａｃｋｅｔ送信
の概要を示す説明図である。

【図１４】Ａｓｙｎｃｈｒｏｎｏｕｓ通信における基本
的な通信規則（トランザクションルール）を示す処理遷
移図である。

【図１５】ＩＥＥＥ１３９４バスのアドレッシング構造
を示す説明図である。

【図１６】ＣＩＰの構造図である。

【図１７】プラグにより規定された接続関係例を示す説
明図である。

【図１８】プラグコントロールレジスタを示す説明図で
ある。

【図１９】Ａｓｙｎｃｈｒｏｎｏｕｓ通信において規定
されるＷｒｉｔｅＴｒａｎｓａｃｔｉｏｎを示す処理
遷移図である。

【図２０】ＡｓｙｎｃｈｒｏｎｏｕｓＰａｃｋｅｔ
（ＡＶ／Ｃコマンドパケット）の構造図である。

【図２１】ＡｓｙｎｃｈｒｏｎｏｕｓＰａｃｋｅｔに
おける、ｃｔｙｐｅ／ｒｅｓｐｏｎｃｅの定義内容を示
す説明図である。

【図２２】ＡｓｙｎｃｈｒｏｎｏｕｓＰａｃｋｅｔに
おける、ｓｕｂｕｎｉｔ＿ｔｙｐｅと、ｏｐｃｏｄｅの
定義内容例を示す説明図である。

【図２３】Ａｓｙｎｃｈｒｏｎｏｕｓ通信におけるプラ
グ構造を示す説明図である。

【図２４】Ａｓｙｎｃｈｒｏｎｏｕｓ通信におけるプラ
グアドレス構造を示す説明図である。

【図２５】Ａｓｙｎｃｈｒｏｎｏｕｓ通信におけるプラ
グアドレス構造を示す説明図である。

【図２６】Ａｓｙｎｃｈｒｏｎｏｕｓ通信におけるプラ
グ間での処理を示す説明図である。

【図２７】ＡｓｙｎｃｈｒｏｎｏｕｓＣｏｎｎｅｃｔ
ｉｏｎとしての送信手順を示す説明図である。

【図２８】本発明の変形例の説明図である。

【符号の説明】

１情報センタ、３伝送路、１０データサーバ、１
１ＣＰＵ、１２ＲＯＭ、１３ＲＡＭ、１４フラ
ッシュメモリ、１５ＨＤＤ、１６バッファメモリ、
１７ＣＤ−ＲＯＭドライブ、１８ＭＤドライブ、１
９モデム、２０パネル操作部、２２赤外線インタ
ーフェースドライバ、２３ＵＳＢドライバ、２４表
示部、２５表示ドライバ、２８エンコーダ、２９
デコーダ、３０ＩＥＣ９５８エンコーダ、３１Ａ／
Ｄ変換器、３２マイクアンプ、３３Ｄ／Ａ変換器、
３４アンプ、３５スピーカ、３７ＩＥＥＥ１３９
４インターフェース、３８ＰＣＭＣＩＡドライバ、３
９ＰＣＭＣＩＡスロット、５０ターミナル、５０ｓ
スピーカターミナル、５０ｄディスプレイターミナ
ル、５１操作部、５２Ｓ,５２Ｌ表示部、５３ス
ピーカ、５５ＩＥＥＥ１３９４インターフェース、５
６コントローラ、５７データバッファ

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号ＦＩテーマコート゛(参考）Ｈ０４Ｍ 11/08 Ｈ０４Ｌ 11/00 ３１０Ｃ５Ｋ０３３Ｈ０４Ｎ 5/92 Ｈ０４Ｎ 5/92 Ｈ５Ｋ１０１ 5/93 5/93 Ｅ 7/173 ６２０Ｆターム(参考） 5B014 GA46 GC02 5B077 BB05 DD02 FF12 FF13 MM02 NN02 5C053 FA22 FA28 FA29 GA11 GB11 GB38 JA01 JA30 KA01 KA24 LA06 LA07 LA11 LA14 5C064 BA02 BA07 BB05 BC06 BC14 BC18 BC20 BC27 BD02 BD08 BD09 BD16 5K015 AA12 AB01 AB02 5K033 AA09 BA01 BA13 BA15 CB01 CC01 DA01 DA05 DA13 DB12 DB14 5K101 KK18 LL05

Claims

【特許請求の範囲】

【請求項１】サーバ装置と複数の端末装置が通信可能
に接続されて成るとともに、上記サーバ装置は、複数のデータを蓄積する蓄積手段と、上記蓄積手段からデータを再生して送信することのでき
る再生送信手段と、上記端末装置からのリクエスト信号に応じて、要求され
たデータを上記再生送信手段により上記蓄積手段から再
生させ、そのリクエスト信号を発した端末装置に対して
送信させるリクエスト対応制御を実行するとともに、こ
のリクエスト対応制御を複数のリクエスト信号に同時に
対応して実行できるようにされた制御手段と、を備え、上記各端末装置は、操作手段と、上記操作手段の操作に応じて上記サーバ装置に対してリ
クエスト信号を送信する送信手段と、上記サーバ装置から送信されてきたデータを出力する出
力手段と、を備え、上記サーバ装置と上記各端末装置は、同期通信及び非同
期通信が可能な通信方式で接続されていることを特徴と
するマルチ再生システム。
【請求項２】上記通信方式はＩＥＥＥ１３９４である
ことを特徴とする請求項１に記載のマルチ再生システ
ム。
【請求項３】上記各端末装置は、上記サーバ装置を起
点としてデイジーチェイン接続されることを特徴とする
請求項１に記載のマルチ再生システム。
【請求項４】上記サーバ装置は、外部装置から通信に
より供給されたデータ、又は記録媒体から再生されたデ
ータを、上記蓄積手段に蓄積できることを特徴とする請
求項１に記載のマルチ再生システム。
【請求項５】上記サーバ装置は、上記各端末装置のそれぞれに対応して、送信するデータ
のバッファリングをおこなうことができるバッファリン
グ手段をさらに備えたことを特徴とする請求項１に記載
のマルチ再生システム。
【請求項６】上記端末装置は、上記サーバ装置から送
信されてきたデータのバッファリングをおこなうことが
できるバッファリング手段をさらに備えたことを特徴と
する請求項１に記載のマルチ再生シテム。
【請求項７】同期通信及び非同期通信が可能な通信方
式で、複数の端末装置と通信可能に接続する接続手段
と、複数のデータを蓄積する蓄積手段と、上記蓄積手段からデータを再生して送信することのでき
る再生送信手段と、上記端末装置からのリクエスト信号に応じて、要求され
たデータを上記再生送信手段により上記蓄積手段から再
生させ、そのリクエスト信号を発した端末装置に対して
送信させるリクエスト対応制御を実行するとともに、こ
のリクエスト対応制御を複数のリクエスト信号に同時に
対応して実行できるようにされた制御手段と、を備えたことを特徴とするサーバ装置。
【請求項８】上記接続手段における上記通信方式はＩ
ＥＥＥ１３９４であることを特徴とする請求項７に記載
のサーバ装置。
【請求項９】外部装置から通信により供給されたデー
タ、又は記録媒体から再生されたデータを、上記蓄積手
段に蓄積できることを特徴とする請求項７に記載のサー
バ装置。
【請求項１０】上記各端末装置のそれぞれに対応し
て、送信するデータのバッファリングをおこなうことが
できるバッファリング手段をさらに備えたことを特徴と
する請求項７に記載のサーバ装置。
【請求項１１】同期通信及び非同期通信が可能な通信
方式でサーバ装置と通信可能とされるとともに、他の端
末装置とともに上記サーバ装置を起点としたデイジーチ
ェイン接続により接続されるようにした接続手段と、操作手段と、上記操作手段の操作に応じて上記サーバ装置に対してリ
クエスト信号を送信する送信手段と、上記サーバ装置から送信されてきたデータを出力する出
力手段と、を備えることを特徴とする端末装置。
【請求項１２】上記接続手段における上記通信方式は
ＩＥＥＥ１３９４であることを特徴とする請求項１１に
記載の端末装置。
【請求項１３】上記サーバ装置から送信されてきたデ
ータのバッファリングをおこなうことができるバッファ
リング手段をさらに備えたことを特徴とする請求項１１
に記載の端末装置。