JP2000358037A - 情報処理装置、及び情報処理装置の管理方法 - Google Patents

Abstract

(57)【要約】 【課題】 データバス上に存在するデバイスを視覚的に
把握するという点でのデータインターフェイスシステム
の利便性を向上させる。 【解決手段】 データバスに接続されるデバイスごとに
対応して、任意にユーザネームを入力して登録可能とさ
れる。そして、このユーザネームによってデバイスを認
識可能なように表示を行うようにされる。また、ユーザ
ネームは登録対象となったデバイスに固有のＮｏｄｅ
Ｕｎｉｑｕｅ ＩＤと対応付けされてユーザネームリス
トファイルとして記憶されることになるため、例えばバ
スリセットなどが発生した後にあっても、各デバイスの
Ｎｏｄｅ Ｕｎｉｑｕｅ ＩＤを取得して、ユーザネー
ムリストファイルに対して検索を行えば、バスリセット
後に確立された接続に対応して各デバイスに登録された
ユーザネームを適正に表示させるようにされる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、所定のデータ通信
フォーマットに依るデータインターフェイスを介してデ
ータの送受信を行う情報処理装置、及び情報処理装置の
管理方法に関するものである。

【０００２】

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

【０００３】このような技術を背景として、各種デジタ
ルＡＶ機器やパーソナルコンピュータ装置等の電子機器
を、例えばＩＥＥＥ(Institute of Electrical Enginee
rs)１３９４等のデジタルデータインターフェイス規格
に従ったデータバスを介して相互に接続することで、機
器間でデータを送受信できるようにしたデータ伝送シス
テムが提案されてきている。

【０００４】このようなＡＶシステムでは、いわゆるリ
モート制御も可能となる。例えば、データバスを介して
ディスク記録再生装置とパーソナルコンピュータが接続
されているとして、ディスク記録再生装置に対する記録
再生、更には記録ソースの編集などに関する操作をパー
ソナルコンピュータ装置側での操作によって行うといっ
たことも可能となる。

【０００５】

【発明が解決しようとする課題】ところで、上記のよう
にしてパーソナルコンピュータによって、ＩＥＥＥ１３
９４バスに接続されている機器をコントロールすること
を考えた場合、パーソナルコンピュータのディスプレイ
画面上のＧＵＩ(Graphical User Interface)としては、
ＩＥＥＥ１３９４バスに接続されている機器について表
示を行う必要のある場合が生じてくる。そして、この際
には、表示されている機器について、ＩＥＥＥ１３９４
バスに接続されている機器のうちの何れであるのかが、
ユーザにとって認識できるように配慮する必要がある。

【０００６】このようなＧＵＩ上での機器の識別のため
には、１つとして、機器のメーカ名と、機種名（モデル
ネーム）を文字として表示することが行われている。Ｉ
ＥＥＥ１３９４インターフェイスに対応する機器には、
例えば機器に関するＩＤとして、その機器を製造したメ
ーカ名と、機種名としての情報等を含む識別情報が予め
ＲＯＭなどに格納されて出荷される。そこで、パーソナ
ルコンピュータ側では各機器からメーカ名や機種名の情
報を通知してもらい、これらのメーカ名や機種名を文字
として表示することで、ＧＵＩ画面上において、ほぼ機
器を視覚的に識別することが可能になる。但し、ユーザ
が、同一メーカで同一の機種を複数接続して使用してい
る場合には、複数の機器が同一のメーカ名、機種名によ
って表示されることになるため、万全であるとは言えな
い。

【０００７】そこで、機器ごとのＮｏｄｅ Ｕｎｉｑｕ
ｅ ＩＤを文字として表示することも行われている。Ｎ
ｏｄｅ Ｕｎｉｑｕｅ ＩＤとは、ＩＥＥＥ１３９４イ
ンターフェイスに対応する機器に与えられているＩＤで
あり、機器ごとに固有とされている。つまりＮｏｄｅ
Ｕｎｉｑｕｅ ＩＤは複数機器間で同一の値を有するこ
とがないように規定されているものである。従って、こ
のＮｏｄｅ Ｕｎｉｑｕｅ ＩＤを文字として表示すれ
ば、機器ごとに必ず異なる文字パターンを割り当てられ
るために、ＧＵＩ画面上での視覚的な機器の特定、識別
は可能になるものでる。

【０００８】但し、Ｎｏｄｅ Ｕｎｉｑｕｅ ＩＤは、
８バイトの情報であるために、これを文字として表示し
た場合には、例えば単に多くの英数字が羅列されるよう
な表示と成らざるを得ない。従って、実際に、Ｎｏｄｅ
Ｕｎｉｑｕｅ ＩＤを文字として表示したとしても、
ユーザにとっては、即座には機器を判断しにくい。この
ような問題は、ＩＥＥＥ１３９４バスに接続される機器
が多くなるほど顕著となる。

【０００９】

【課題を解決するための手段】そこで、本発明は上記し
た課題を考慮して次のような構成を採る。先ず、所定の
通信フォーマットによるデータバスを介して接続される
他の情報処理装置と情報の送受信を行うことのできる情
報処理装置として次のように構成する。つまり、データ
バス上に存在するとされる情報処理装置ごとに対応する
ようにして文字情報を入力することのできる文字情報入
力手段と、情報処理装置ごとに固有となるようにして与
えられた機器識別情報をデータバス上に存在するとされ
る情報処理装置の各々から取得することのできる機器識
別情報取得手段と、文字情報と、この文字情報が対応す
る情報処理装置の機器識別情報とを対応付けた対応情報
を生成して所定の記憶手段に記憶させる対応情報管理手
段と、現在データバス上に存在するとされる情報処理装
置の機器識別情報に対応付けされた文字情報を対応情報
から検索し、この検索された文字情報が現在データバス
上に存在するとされる各情報処理装置を特定するための
情報として表示出力されるように表示制御を実行する表
示制御手段とを備える。

【００１０】また、所定の通信フォーマットによるデー
タバスを介して接続されることで情報の送受信を行う情
報処理装置の管理方法としては次のように構成する。つ
まり、上記データバス上に存在するとされる情報処理装
置ごとに対応するようにして文字情報を入力する文字情
報入力処理と、情報処理装置ごとに固有となるようにし
て与えられた機器識別情報をデータバス上に存在すると
される情報処理装置の各々から取得することのできる機
器識別情報取得処理と、文字情報と、この文字情報が対
応する情報処理装置の機器識別情報とを対応付けた対応
情報を生成して所定の記憶領域に記憶させる対応情報管
理処理と、現在データバス上に存在するとされる情報処
理装置の機器識別情報に対応付けされた文字情報を対応
情報から検索し、この検索された文字情報が現在データ
バス上に存在するとされる各情報処理装置を特定するた
めの情報として表示出力されるように表示制御を実行す
る表示制御処理とを実行するように構成する。

【００１１】上記各構成によれば、データバスに接続さ
れる情報処理装置ごとに対応して、任意に文字情報を入
力して設定することができる。この文字情報は、情報処
理装置に固有の機器識別情報と対応付けされて対応情報
として記憶されることになる。ここで、文字情報が機器
識別情報と対応付けされるということは、文字情報は機
器ごとに固有となる情報として管理されることを意味す
る。そして、現在データバスに接続されている情報処理
装置の機器識別情報に対応付けされた文字情報が対応情
報にあることが検索されれば、この検索された文字情報
によって、個々の機器を特定する情報（例えば機器の名
称）として表示させることができる。

【００１２】

【発明の実施の形態】以下、本発明の実施の形態につい
て説明する。なお、以降の説明は次の順序で行う。 １．ＩＥＥＥ１３９４フォーマット １−１．概要 １−２．スタックモデル １−３．信号伝送形態 １−４．機器間のバス接続 １−５．パケット １−６．トランザクションルール １−７．アドレッシング １−８．ＣＩＰ(Common Isochronos Packet) １−９．コネクションマネージメント １−１０．ＦＣＰにおけるコマンド及びレスポンス １−１１．ＡＶ／Ｃコマンドパケット １−１２．プラグ １−１３．Asynchronous Connection送信手順 ２．本実施の形態のシステム構成例 ３．パーソナルコンピュータでの表示形態例 ４．処理動作

【００１３】１．ＩＥＥＥ１３９４による本実施の形態
のデータ通信 １−１．概要 本発明の実施の形態としては、ＩＥＥＥ１３９４バスに
よりデータの送受信を行うＡＶシステムを例に挙げるこ
ととする。このＡＶシステムとしては、パーソナルコン
ピュータと各種オーディオ機器を備えることで、少なく
とも、パーソナルコンピュータによりオーディオ機器を
コントロール（リモート制御）可能とされる。そこで先
ず、本実施の形態としてのＩＥＥＥ１３９４規格に従っ
たデータ通信について説明する。

【００１４】ＩＥＥＥ１３９４は、シリアルデータ通信
の規格の１つとされる。このＩＥＥＥ１３９４によるデ
ータ伝送方式としては、周期的に通信を行うＩｓｏｃｈ
ｒｏｎｏｕｓ通信方式と、この周期と関係なく非同期で
通信するＡｓｙｎｃｈｒｏｎｏｕｓ通信方式が存在す
る。一般に、Ｉｓｏｃｈｒｏｎｏｕｓ通信方式はデータ
の送受信に用いられ、Ａｓｙｎｃｈｒｏｎｏｕｓ通信方
式は各種制御コマンドの送受信に用いられる。そして、
１本のケーブルを使用して、これら２種類の通信方式に
よって送受信を行うことが出来るようにされている。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【００４４】簡単に説明すると、図８（ｅ）のレジスタ
において、例えばアドレス５１２［０ ００ ０２ ０
０ｈ］から始まるＳｅｒｉａｌ Ｂｕｓ−ｄｅｐａｎｄ
ｅｎｔ Ｒｅｇｉｓｔｅｒｓを参照することで、Ｉｓｏ
ｃｈｒｏｎｏｕｓ ｃｙｃｌｅのサイクルタイムや、空
きチャンネルの情報が得られる。また、アドレス１０２
４［０ ００ ０４ ００ｈ］から始まるＣｏｎｆｉｇ
ｕｒａｔｉｏｎ ＲＯＭの内容を参照すれば、Ｎｏｄｅ
の機種から、その機種に付されているＮｏｄｅ Ｕｎｉ
ｑｕｅ ＩＤなども識別することができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

【００５８】１−１１．ＡＶ／Ｃコマンドパケット 図１により説明したように、Ａｓｙｎｃｈｒｏｎｏｕｓ
通信において、ＦＣＰは、ＡＶ／Ｃコマンドを用いて各
種ＡＶ機器に対する通信を行うことができるようにされ
ている。Ａｓｙｎｃｈｒｏｎｏｕｓ通信では、Ｗｒｉｔ
ｅ，Ｒｅａｄ，Ｌｏｃｋの３種のトランザクションが規
定されているのは、図７にて説明した通りであり、実際
には各トランザクションに応じたＷｒｉｔｅ Ｒｅｑｕ
ｅｓｔ／Ｒｅｓｐｏｎｃｅ Ｐａｃｋｅｔ，Ｒｅａｄ
Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｃｅ Ｐａｃｋｅｔ，Ｌ
ｏｃｋ Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｃｅ Ｐａｃｋ
ｅｔが用いられる。そして、ＦＣＰでは、上述したよう
にＷｒｉｔｅ Ｔｒａｎｓａｃｔｉｏｎを使用するもの
である。そこで図１３に、Ｗｒｉｔｅ Ｒｅｑｕｅｓｔ
Ｐａｃｋｅｔ（AsynchronousPacket（Write Request
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送信
手順 続いて、上記図１９により説明したプラグ（ｐｒｏｄｕ
ｃｅｒ−ｃｏｎｓｕｍｅｒ）間の構造を前提として、図
２０の処理遷移図により、Ａｓｙｎｃｈｒｏｎｏｕｓ
ｃｏｎｎｅｃｔｉｏｎの基本的な送受信手順について説
明する。図２０に示す送受信処理の手順は、Ａｓｙｎｃ
ｈｒｏｎｏｕｓ通信として、ＦＣＰによって規定された
環境のもとで、ＡＶ／Ｃコマンド（Ｗｒｉｔｅ Ｒｅｑ
ｕｅｓｔ Ｐａｃｋｅｔ）を使用して行われる。そし
て、本実施の形態において扱われるＡＵＸデータも、こ
の送受信手順を使用してＩＥＥＥ１３９４システム内に
おいて送受信が行われる。但し、図１９に示す処理は、
あくまでもＡｓｙｎｃｈｒｏｎｏｕｓ ｃｏｎｎｅｃｔ
ｉｏｎとしての通信動作を示すもので、ＡＵＸデータの
記録再生に対応する通信処理については後述する。な
お、Ａｓｙｎｃｈｒｏｎｏｕｓ ｃｏｎｎｅｃｔｉｏｎ
の実際においては、コマンド送信に応じて、図１２に示
したように、Ａｃｋｎｏｗｌｅｄｇの送受信が実行され
るのであるが、図２０においてはＡｃｋｎｏｗｌｅｄｇ
についての送受信処理の図示は省略している。

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

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

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

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

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

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

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

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

【００８８】２．本実施の形態のシステム構成例 図２１は、これまで説明を行ったＩＥＥＥ１３９４イン
ターフェイスを介して構築される、本実施の形態として
のＡＶシステムの構成例を示している。ここでは、ＡＶ
システムは、パーソナルコンピュータ１１３と、デバイ
ス＃１，デバイス＃２，デバイス＃３として示される３
つのオーディオ機器をＩＥＥＥ１３９４バス１１６を介
して相互通信可能に接続することによって構築される。
なお、実際のケーブルによる各機器間の接続関係は、先
に図４により説明したバス接続の規則に従っていさえす
れば良いものである。

【００８９】デバイス＃１，デバイス＃２，デバイス＃
３としての機器の種類は特に限定されるものではない
が、ここでは、デバイス＃１はＭＤレコーダ／プレー
ヤ，デバイス＃２はＣＤプレーヤ，デバイス＃３もまた
ＭＤレコーダ／プレーヤであるとする。周知のように、
ＭＤレコーダ／プレーヤは、いわゆるミニディスク（Ｍ
Ｄ）といわれる光磁気ディスクに対応してオーディオデ
ータの記録再生を行うことのできる記録再生装置であ
る。また、ＣＤプレーヤは、コンパクトディスク（Ｃ
Ｄ）に対応してデジタルオーディオデータの再生を行う
ことのできる再生装置である。

【００９０】そして、この場合にはＣＤプレーヤは、Ｃ
Ｄから再生したオーディオデータをＩＥＥＥ１３９４バ
ス１１６を介して送信出力することができるようになっ
ている。また、ＭＤレコーダ／プレーヤは、ＭＤから再
生復調したオーディオデータをＩＥＥＥ１３９４バス１
１６を介して送信出力可能とされていると共に、ＩＥＥ
Ｅ１３９４バス１１６を介して外部から送信されてきた
オーディオデータを受信して、この受信したオーディオ
データをＭＤに記録可能とされている。また、先に本出
願人により、オーディオデータに付随するテキストや静
止画などのデータファイル（ＡＵＸデータ）もオーディ
オデータと共に記録可能としたＭＤレコーダ／プレーヤ
も提案されているが、このようなＭＤレコーダ／プレー
ヤであれば、ＭＤから再生したＡＵＸデータを送信出力
することと、外部から送信されたＡＵＸデータを受信し
てＭＤに記録することも可能とされる。

【００９１】そして、上述のようにしてＡＶシステムと
して、ＣＤプレーヤとＭＤレコーダ／プレーヤを備えて
いる場合には、ＣＤプレーヤにて再生されたデジタルオ
ーディオデータをＩＥＥＥ１３９４を介してＭＤレコー
ダ／プレーヤに送信してＭＤレコーダ／プレーヤ側にて
記録を行う、いわゆるデジタルダビングを行うことがで
きる。

【００９２】この場合、パーソナルコンピュータ１１３
は、ＩＥＥＥ１３９４バスにより接続されるデバイス
（機器）をコントロール（リモート制御）し、また、各
機器から送信されるオーディオデータ等のユーザデータ
を受信して保存し、各種編集、加工などを行うことがで
きる。また、パーソナルコンピュータ１１３から送信し
た各種のユーザデータを他のデバイスに送信することも
可能とされている。例えば、図２１に示すＡＶシステム
の構成例であれば、先に述べたＣＤプレーヤからＭＤレ
コーダ／プレーヤへのデジタルダビング動作を、パーソ
ナルコンピュータ１１３がリモート制御してコントロー
ルすることも可能とされる。上記したパーソナルコンピ
ュータ１１３の機能は、例えば、その機能のために特化
されたアプリケーションソフトウェアとしてのプログラ
ムに基づいて、内部ＣＰＵが処理を実行することで実現
される。

【００９３】ところで、ＩＥＥＥ１３９４データインタ
ーフェイスに対応するデバイスでは、Ｎｏｄｅ Ｕｎｉ
ｑｕｅ ＩＤ、及びｓｕｂｕｎｉｔ ＩＤとしてＶｅｎ
ｄｅｒ Ｎａｍｅ，Ｍｏｄｅｌ Ｎａｍｅを例えば内部
ＲＯＭに予めセットしておくように規定されている。こ
れらＮｏｄｅ Ｕｎｉｑｕｅ ＩＤ、及びｓｕｂｕｎｉ
ｔ ＩＤは、実際にそのデバイスがＩＥＥＥ１３９４バ
スに接続されたときに、その接続関係を確立する際など
に必要となるものである。

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

【００９５】また、Ｖｅｎｄｅｒ Ｎａｍｅは、その機
器の製造メーカ名を示す情報であり、Ｍｏｄｅｌ Ｎａ
ｍｅは、その機器の機種を示す情報である。従って、こ
れらＶｅｎｄｅｒ Ｎａｍｅ及びＭｏｄｅｌ Ｎａｍｅ
を共通に有する機器は存在することになる。なお、Ｎｏ
ｄｅ Ｕｎｉｑｕｅ ＩＤは必須であるのに対して、Ｖ
ｅｎｄｅｒＮａｍｅ，Ｍｏｄｅｌ Ｎａｍｅはオプショ
ンであり、必ず機器に対してセットしておく必要は無い
ものとされている。

【００９６】ここで、図２１に示すシステムにおいて、
デバイス＃１のＭＤレコーダ／プレーヤは、図のよう
に、 Ｎｏｄｅ Ｕｎｉｑｕｅ ＩＤ＝“Ｘ”Ｖｅｎｄｅｒ
Ｎａｍｅ＝“ＡＡＡ” Ｍｏｄｅｌ Ｎａｍｅ＝“ＢＢＢ” を有しているものとする。また、デバイス＃２のＣＤプ
レーヤは、 Ｎｏｄｅ Ｕｎｉｑｕｅ ＩＤ＝“Ｙ” Ｖｅｎｄｅｒ Ｎａｍｅ＝“−−−” Ｍｏｄｅｌ Ｎａｍｅ＝“−−−” とされ、Ｖｅｎｄｅｒ Ｎａｍｅ，Ｍｏｄｅｌ Ｎａｍ
ｅについては、セットされていないものとされる。ま
た、デバイス＃３のＭＤレコーダ／プレーヤは、 Ｎｏｄｅ Ｕｎｉｑｕｅ ＩＤ＝“Ｚ” Ｖｅｎｄｅｒ Ｎａｍｅ＝“ＡＡＡ” Ｍｏｄｅｌ Ｎａｍｅ＝“ＢＢＢ” を有しているものとする。ここで、デバイス＃１とデバ
イス＃３のＭＤレコーダ／プレーヤのＶｅｎｄｅｒ Ｎ
ａｍｅ，Ｍｏｄｅｌ Ｎａｍｅが同一であることから、
デバイス＃１とデバイス＃３のＭＤレコーダ／プレーヤ
は、共に同一メーカの同一機種であることが分かる。
なお、上記“ ”内に示す文字は実値ではなく、あくま
でも便宜上の表記である。

【００９７】ここで、図２２にパーソナルコンピュータ
１１３の構成例を示す。この図に示すパーソナルコンピ
ュータ１１３は、外部とデータの授受を行うためのイン
ターフェイスとしてＩＥＥＥ１３９４インターフェイス
２０９を備えている。ＩＥＥＥ１３９４インターフェイ
ス２０９は、外部データバスとしてのＩＥＥＥ１３９４
バス１１６と接続されることで外部機器と相互通信が可
能とされる。ＩＥＥＥ１３９４インターフェイス２０９
は、ＩＥＥＥ１３９４バス１１６を介して受信したパケ
ットを復調し、復調したパケットに含まれるデータを抽
出し、この抽出データを内部データ通信に適合するデー
タフォーマットにより変換を行って、内部バス２１０を
介してＣＰＵ２０１に出力する。また、ＣＰＵ２０１の
制御によって出力されたデータを入力し、パケット化等
のＩＥＥＥ１３９４フォーマットに従った変調処理を施
して、ＩＥＥＥ１３９４バス１１６を介して外部に送信
出力する。

【００９８】ＣＰＵ２０１は、例えばＲＯＭ２０２に保
持されているプログラムに従って各種の処理を実行す
る。本実施の形態では、ＩＥＥＥ１３９４の規格に従っ
て各種データの送受信を可能とするために、上記ＲＯＭ
２０２に対してＩＥＥＥ１３９４インターフェイス２０
９を制御するためのプログラムも格納されることにな
る。つまり、パーソナルコンピュータ１１３において
は、ＩＥＥＥ１３９４によるデータ送受信に可能なセッ
ト（ハードウェア及びソフトウェア）が備えられるもの
である。また、ＲＡＭ２０３にはＣＰＵ２０１が各種処
理を実行するのに必要なデータやプログラム等が適宜保
持される。

【００９９】入出カインターフェイス２０４は、キーボ
ード２０５とマウス２０６が接続されており、これらか
ら供給された操作信号をＣＰＵ２０１に出カするように
されている。また、入出カインタフェイス２０４には、
記憶媒体としてハードディスクを備えたハードディスク
ドライブ２０７が接続されている。ＣＰＵ２０１は、入
出カインタフェイス２０４を介して、ハードディスクド
ライブ２０７のハードディスクに対してデータやプログ
ラム等の記録又は読み出しを行うことができるようにさ
れている。この場合、入出カインタフェース２０４に
は、さらに、画像表示のためのディスプレイモニタ２０
８が接続されている。内部バス２１０は、例えば、ＰＣ
Ｉ(Peripheral Component Interconnect)又はローカル
バス等により構成され、内部における各機能回路部間を
相互に接続している。

【０１００】なお、図２１に示したＭＤレコーダ／プレ
ーヤ、ＣＤプレーヤとしても、ＩＥＥＥ１３９４インタ
ーフェイス機能については、上記したパーソナルコンピ
ュータ１１３と基本的には同様の構成を採る。つまり、
ＭＤレコーダ／プレーヤ、ＣＤプレーヤにあっても、Ｉ
ＥＥＥ１３９４インターフェイスを備えると共に、内部
ＲＯＭに対して、内部ＣＰＵがＩＥＥＥ１３９４インタ
ーフェイスの制御を可能とするためのプログラムが搭載
されるものである。

【０１０１】なお、本実施の形態に適用される、ＩＥＥ
Ｅ１３９４バスラインによって相互に接続されたシステ
ムの構築例は、これまで説明した形態に限定されるもの
ではなく、あくまでも一例であり、例えば、ＡＶシステ
ムとしては、例えばＩＲＤといわれるデジタル衛星放送
受信装置や、デジタルＶＴＲ（Ｖｉｄｅｏ Ｔａｐｅ
Ｒｅｃｏｒｄｅｒ）などを備えても構わないものであ
り、特に図２１に示したＭＤレコーダ／プレーヤとＣＤ
プレーヤである必然性はない。このため、ＭＤレコーダ
／プレーヤ及びＣＤプレーヤの内部構成例についての図
示及びその説明は、ここでは省略する。

【０１０２】３．パーソナルコンピュータでの表示形態
例 ここで、例えば図２１に示した構成によるＡＶシステム
において、パーソナルコンピュータ１１３が、ＩＥＥＥ
１３９４バスに接続されているデバイスを一括して管理
／コントロール可能な機能（アプリケーションソフトウ
ェア）を有しているとする。そして、このような管理／
コントロール機能の１つとして、現在ＩＥＥＥ１３９４
バスに接続されているデバイスを提示するための表示機
能を有しているものとする。

【０１０３】図２３は、上記のようにしてＩＥＥＥ１３
９４バス上に存在するデバイスのリストが表示されるデ
バイスリストウィンドウＷＤ１の表示形態例を示してい
る。このデバイスリストウィンドウＷＤ１は、例えばデ
ィスプレイモニタ２０８に対して表示される。

【０１０４】この図では、デバイス＃１、デバイス＃
２、デバイス＃３、及びパーソナルコンピュータ１１３
がそれぞれ箱形形状の枠によるデバイスアイコンＩｃｎ
によって表示されており、また、これらのデバイスアイ
コンＩｃｎがラインによって相互に接続されている状態
を表示することで、デバイス＃１〜＃３及びパーソナル
コンピュータ１１３の４台の機器が、ＩＥＥＥ１３９４
バスにより相互通信可能に接続されている様子が示され
ている。つまり、図２１により説明したバス接続関係
が、グラフィカルに示されているものである。

【０１０５】ここで、その入力設定操作は後述するが、
本実施の形態では、パーソナルコンピュータ１１３が実
行する処理として、ＩＥＥＥ１３９４バスに接続される
デバイスごとに対応して、ユーザが文字情報を入力する
ことで、デバイスの名称を任意に登録することができる
ものとされている。なお、以降においては、このように
してユーザがデバイスごとに登録した名称については、
「ユーザネーム」ということにする。

【０１０６】そしてデバイスに対して既にこのユーザネ
ームが登録されている場合には、そのデバイスに対応す
るデバイスアイコンＩｃｎ内に対して、ユーザネームを
表示するようにされている。例えば図２３の場合であれ
ば、デバイス＃１のＭＤレコーダ／プレーヤとデバイス
＃２のＣＤプレーヤに対してユーザネームが登録されて
おり、デバイス＃１のデバイスアイコンＩｃｎ内には、
「兄のＭＤ」というユーザネームが表示されている。ま
た、デバイス＃２のデバイスアイコンＩｃｎ内には、
「皆のＣＤ」というユーザネームが表示されている。

【０１０７】また、ここではデバイス＃３のＭＤレコー
ダ／プレーヤについてはユーザネームが未登録の状態に
あるものとされる。このような場合のデバイスアイコン
Ｉｃｎ内の表示内容としては、各種考えられるのである
が、ここでは、そのデバイスのＶｅｎｄｅｒ Ｎａｍ
ｅ，Ｍｏｄｅｌ Ｎａｍｅを例えば英数文字等により提
示して表示させることで、とりあえず、その機器が何な
のであるのかをユーザが把握できるようにしている。例
えばＶｅｎｄｅｒ Ｎａｍｅ，Ｍｏｄｅｌ Ｎａｍｅの
代わりに、Ｎｏｄｅ Ｕｎｉｑｕｅ ＩＤを表示させて
もよし、また、Ｖｅｎｄｅｒ Ｎａｍｅ，Ｍｏｄｅｌ
Ｎａｍｅその他のＩＤ情報から特定される機種名（例え
ばＭＤレコーダ／プレーヤであるとかＣＤプレーヤであ
るとか）などを文字、シンボル等により表示させること
も考えられる。また、パーソナルコンピュータ１１３に
対応するデバイスアイコンＩｃｎには、この場合には、
ＩＥＥＥ１３９４データインターフェイスシステム上で
のコントローラとして機能することを示す「Ｃｏｎｔｒ
ｏｌｌｅｒ」という文字が表示されている状態が示され
ている。但し、パーソナルコンピュータ１１３自身につ
いても、ユーザネームを登録できるようにして、パーソ
ナルコンピュータ１１３内のデバイスアイコンＩｃｎに
対してユーザが任意に設定したユーザネームを表示させ
るようにしてもよい。

【０１０８】ここで、例えばユーザが図２３に示す表示
を見て、未だユーザネームが未登録となっているデバイ
ス＃３に対応するデバイスアイコンＩｃｎに対してユー
ザネームを登録したいと思ったとする。この場合ユーザ
は、例えば、デバイスリストウィンドウＷＤ１に対して
マウスなどによる操作を行って、デバイス＃３に対応す
るデバイスアイコンＩｃｎを選択した状態とする。そし
て、いわゆるウィンドウメニューからユーザネーム登録
のメニューを呼び出すようにされる。ユーザネーム登録
のメニューが呼び出されると、ここでは図示しないが、
例えば、ユーザネームを登録するためにダイアログウィ
ンドウが表示されるので、ユーザは、キーボード等を操
作して文字入力を行いユーザネームを入力する。そし
て、登録操作を行えば、デバイス＃３に対応するユーザ
ネームが登録されたことになる。そして、この登録後に
おいては、デバイスリストウィンドウＷＤ１は図２４に
示すようにして表示が変更される。つまりデバイス＃３
に対応するデバイスアイコンＩｃｎ内に対して先にユー
ザが登録したユーザネームが表示されるものである。こ
こでは、デバイス＃３に対応するデバイスアイコンＩｃ
ｎ内には「弟のＭＤ」というユーザネームが表示された
状態が示されている。つまり、ユーザは、ユーザネーム
の登録時において「弟のＭＤ」という文字入力を行った
ものである。なお、上記と同様の操作手順によって既に
登録されたユーザネームの更新を行うことも可能であ
る。

【０１０９】ここで、本実施の形態のパーソナルコンピ
ュータ１１３において、上記したような操作手順によっ
て登録されたユーザネームは、次のようにして管理され
る。例えば、上記のようにして或るデバイスに対応した
ユーザネームを登録するための操作が行われたとする
と、ＣＰＵ１１では、例えば図２６に示すようなユーザ
ネームリストファイルを作成する。図２６に示すユーザ
ネームリストファイルは、図２４に示した表示に対応し
た内容を有している。

【０１１０】ユーザネームリストファイルにあっては、
登録すべきユーザネームが、各デバイスのＮｏｄｅ Ｕ
ｎｉｑｕｅ ＩＤと対応付けられて格納される。図２６
では、デバイス＃１のＮｏｄｅ Ｕｎｉｑｕｅ ＩＤ＝
“Ｘ”と、デバイス＃１に対して登録したユーザネーム
「兄のＭＤ」という文字情報がセットとして格納されて
いる。また、デバイス＃２のＮｏｄｅ Ｕｎｉｑｕｅ
ＩＤ＝“Ｙ”と、デバイス＃２に対して登録したユーザ
ネーム「皆のＣＤ」という文字情報がセットとして格納
されている。また、デバイス＃３のＮｏｄｅ Ｕｎｉｑ
ｕｅ ＩＤ＝“Ｚ”と、デバイス＃３に対して登録した
ユーザネーム「弟のＭＤ」という文字情報がセットとし
て格納されている。そして、このようにして作成された
ユーザネームリストファイルは、例えば１つのファイル
として管理されて、ハードディスクドライブ２０７に対
して書き込まれて保存されるものである。

【０１１１】上記のようなユーザネームリストファイル
の構造から分かるように、ユーザネームはＮｏｄｅ Ｕ
ｎｉｑｕｅ ＩＤと対応付けされるために、デバイスご
とに固有の情報として管理されることになる。換言すれ
ば、本実施の形態において登録されるユーザネームは、
一時的に有効とされるものではなく、ハードディスクに
保存されているユーザネームリストファイルを参照する
ことで、これまでに既に登録されたユーザネームであれ
ば、常時、デバイスとの対応を特定することが可能とさ
れるものである。

【０１１２】そこで、本実施の形態としては、例えば、
ＩＥＥＥ１３９４バス上でデバイスの抜き差しが行われ
てバスリセットが発生した場合でも、常に適正に、現在
ＩＥＥＥ１３９４バス上に存在するデバイスに対応した
ユーザネームを表示させることが可能となる。このよう
な例として、例えば、図２４のデバイスリストウィンド
ウＷＤ１に表示されているようにして、デバイス＃１，
＃２，＃３、及びパーソナルコンピュータ１１３が接続
されている状態から、デバイス＃３のケーブルが抜かれ
たことで、ＩＥＥＥ１３９４バスにより接続される機器
が、デバイス＃１，＃２、パーソナルコンピュータ１１
３の３台になったとする。このようにして、ケーブルの
抜き差しが行われると、ＩＥＥＥ１３９４システムとし
てはバスリセットが発生する。

【０１１３】そして例えば、パーソナルコンピュータ１
１３がバスリセット発生後において接続されている各デ
バイスからＮｏｄｅ Ｕｎｉｑｕｅ ＩＤを取得すれ
ば、この取得したＮｏｄｅ Ｕｎｉｑｕｅ ＩＤと、ユ
ーザネームリストファイルとを参照することで、バスリ
セットによって新規に接続関係が確立された後にあって
も、現在ＩＥＥＥ１３９４バスに接続されている機器の
ユーザネームを認識することができる。そして、例えば
バスリセット後においてデバイスリストウィンドウＷＤ
１を表示させたとすれば、その表示としては図２４に示
す表示から図２５に示す表示に切り替わるものである。

【０１１４】図２５にあっては、デバイス＃３の表示は
消えており、デバイス＃１，＃２及びパーソナルコンピ
ュータ１１３の各デバイスアイコンＩｃｎが表示され
て、これらの各デバイスアイコンＩｃｎがラインによっ
て接続されている状態が表示されている。

【０１１５】そして、デバイス＃１，＃２の各デバイス
アイコンＩｃｎ内には、それぞれ、「兄のＭＤ」「皆の
ＣＤ」という、バスリセット以前と同様のユーザネーム
が適正に表示されるものである。

【０１１６】また、例えば、図２５のデバイスリストウ
ィンドウＷＤ１に示す接続関係の状態から、再度、デバ
イス＃３としてのＭＤレコーダ／プレーヤのケーブルを
接続して、バスリセットが発生したときには、バスリセ
ット後においては、やはり、現在ＩＥＥＥ１３９４バス
上に存在するデバイスのＮｏｄｅ Ｕｎｉｑｕｅ ＩＤ
とユーザネームリストファイルと参照を行うことで、各
デバイスのユーザネームを特定することができる。そし
て、再度、図２４に示すデバイスリストウィンドウＷＤ
１を表示させることが可能となる。デバイスリストウィ
ンドウＷＤ１としてのデバイスの表示形態は他にも各種
考えられるものであり、これら図２３〜図２５に示すも
のには限定されない。

【０１１７】４．処理動作 続いて、上述したユーザネームの登録と、バスリセット
発生時のデバイスリストウィンドウＷＤ１の表示を実現
するための処理動作について説明する。

【０１１８】先ず、図２７のフローチャートにより、ユ
ーザネーム登録のための処理動作について説明する。な
お、この図に示す処理はパーソナルコンピュータ１１３
のＣＰＵ２０１が実行する。この図に示す処理にあって
は、先ずステップＳ２０１においてデバイスリストウィ
ンドウＷＤ１を表示させるための表示制御処理が実行さ
れている。そして次のステップＳ２０２において、ユー
ザが行った、デバイスリストウィンドウＷＤ１上でのデ
バイスの選択操作に応じて、ユーザネームの登録対象と
なるデバイスを選択設定することが行われる。そして、
次のステップＳ２０３においては、ユーザによるユーザ
ネーム登録メニューを開くための所定操作に応じて、ユ
ーザネーム登録メニューを開始させる。この際には、例
えば先にも述べたように、ユーザネーム登録ウィンドウ
が表示される。上記のようにして、ユーザネーム登録ダ
イアログウィンドウが表示されると、次はステップＳ２
０４の処理として、ユーザのユーザネームの入力操作に
応じてユーザネームを入力（若しくは既に登録されたユ
ーザネームの更新）を行う。そして、ステップＳ２０５
において、ユーザによる決定操作が行われたか否かを判
別する。ここで、ユーザによる決定操作が無く、例えば
ユーザネーム登録メニューのキャンセルが行われたよう
な場合には、ステップ２０１に戻ることで、再度、デバ
イスリストウィンドウＷＤ１が表示されている状態か
ら、ユーザネームの登録が行えるようにされる。

【０１１９】また、ステップＳ２０５において、ユーザ
による決定操作が行われたことが判別されたのであれ
ば、ステップＳ２０６に進む。ステップＳ２０６におい
ては、ユーザネームの登録対象となったデバイスのＮｏ
ｄｅ Ｕｎｉｑｕｅ ＩＤとユーザネームとを対応付け
てユーザネームリストファイルに書き込み（ユーザネー
ムの更新の場合は、ユーザネームの登録対象となったデ
バイスのＮｏｄｅ Ｕｎｉｑｕｅ ＩＤに対応するユー
ザネームの内容を書き換える）を行い、ハードディスク
（ハードディスクドライブ２０７）に保存する。

【０１２０】続いて、図２８のフローチャートを参照し
て、バスリセット発生時におけるデバイスリストウィン
ドウＷＤ１の表示（ユーザネームの表示）のための処理
について説明する。なお、この図に示す処理もパーソナ
ルコンピュータ１１３のＣＰＵ２０３が実行する。この
図に示す処理にあっては、先ずステップＳ３０１におい
てバスリセットの発生を待機しており、バスリセットが
発生したことが判別されると、ステップＳ３０２に進む
ようにされる。

【０１２１】ステップＳ３０２においてはＩＥＥＥ１３
９４バス上に存在するデバイスのＮｏｄｅ Ｕｎｉｑｕ
ｅ ＩＤを取得する。このために、例えば実際には、Ｃ
ＰＵ２０１が、ＡＶ／Ｃコマンドを用いて、現在ＩＥＥ
Ｅ１３９４バスに接続されている各機器に対してＮｏｄ
ｅ Ｕｎｉｑｕｅ ＩＤの通知を要求するためのコマン
ドを送信するようにされる。そして、このコマンドに応
答して、各機器から送信されてくるＮｏｄｅ Ｕｎｉｑ
ｕｅ ＩＤの通知情報を受信することで、Ｎｏｄｅ Ｕ
ｎｉｑｕｅ ＩＤを取得できるものである。

【０１２２】次のステップＳ３０３においては、上記ス
テップＳ３０２にて取得した各Ｎｏｄｅ Ｕｎｉｑｕｅ
ＩＤに対応付けられているユーザネームを、ユーザネ
ームリストファイルから検索する。そして次のステップ
Ｓ３０４において、検索されたユーザネームを利用し
て、例えば図２３〜図２５に示したようなデバイスリス
トウィンドウＷＤ１の表示のための表示制御を実行す
る。つまり、デバイスアイコンＩｃｎ内に、各デバイス
のユーザネームを表示させるものである。なお、この際
において、ユーザネームリストファイルに存在しないＮ
ｏｄｅＵｎｉｑｕｅ ＩＤがあった場合には、このＮｏ
ｄｅ Ｕｎｉｑｕｅ ＩＤを有するデバイスのデバイス
アイコンＩｃｎとしては、例えば図２３のデバイス＃３
に対応するデバイスアイコンＩｃｎのようにして表示を
行うことになる。

【０１２３】なお、上記説明にあっては、ユーザネーム
の表示はデバイスリストウィンドウＷＤ１が開いている
状態で行われるものとされているが、これはあくまでも
説明の便宜上、そうしたものである。例えば実際のアプ
リケーション上でのＧＵＩとしては、デバイスを提示す
るのにユーザネームを表示させることが好ましい状況と
いうのは多様に考えられるものであり、デバイスのユー
ザネームが表示される機会としては、本発明では限定さ
れるべきではない。従って、ユーザネームを登録するた
めの操作手順も、先に説明した以外の手順、及びユーザ
インターフェイスが採用されて構わないものである。ま
た、ここではパーソナルコンピュータ１１３が、ユーザ
ネームの登録と、ユーザネームを提示した表示を行う機
能を有するものとして説明しているが、このような機能
を有する装置としては、特にパーソナルコンピュータに
限定されるものではなく、例えばＩＥＥＥ１３９４対応
のＡＶアンプなどの他、他の機器に対してこの機能を有
させることが可能である。また、本発明としての情報処
理装置と通信システムを組む機器（デバイス）として
は、特に、ＡＶ機器に限定されるものでもない。

【０１２４】また、本発明としては、ＩＥＥＥ１３９４
の規格以外のデジタルデータインターフェイスに対して
も適用が可能である。

【０１２５】

【発明の効果】以上説明したように本発明は、データバ
スに接続されるデバイス（情報処理装置）ごとに対応し
て、任意にユーザネーム（文字情報）を入力して登録可
能とされる。そして、このユーザネームによってデバイ
スを認識可能なように表示を行うようにされる。これに
よって、例えば各デバイスが有しているＩＤなどの情報
により表示を行う場合よりも、ユーザはデバイスを認識
することが容易となる。

【０１２６】また、本発明では、登録されたユーザネー
ムは一過性のものではない。つまり、ユーザネームは登
録対象となったデバイスに固有のＮｏｄｅ Ｕｎｉｑｕ
ｅＩＤ（機器識別情報）と対応付けされてユーザネーム
リストファイル（対応情報）として記憶されることにな
るため、例えばバスリセットなどが発生した後にあって
も、各デバイスのＮｏｄｅ Ｕｎｉｑｕｅ ＩＤを取得
して、ユーザネームリストファイルに対して検索を行え
ば、バスリセット後に確立された接続に対応して各デバ
イスに登録されたユーザネームを適正に表示させること
ができるものである。このように本発明は、データバス
上に存在するデバイスを視覚的に把握するという点での
データインターフェイスシステムの利便性を向上するも
のである。

【図面の簡単な説明】

【図１】本実施の形態に対応するＩＥＥＥ１３９４のス
タックモデルを示す説明図である。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

【図２１】本実施の形態のＩＥＥＥ１３９４データイン
ターフェイスシステムの構成例を示すブロック図であ
る。

【図２２】パーソナルコンピュータの構成を示すブロッ
ク図である。

【図２３】デバイスリストウィンドウの表示形態例を示
す説明図である。

【図２４】デバイスリストウィンドウの表示形態例を示
す説明図である。

【図２５】デバイスリストウィンドウの表示形態例を示
す説明図である。

【図２６】ユーザネームリストファイルの構造を示す説
明図である。

【図２７】ユーザネーム登録のための処理動作を示すフ
ローチャートである。

【図２８】バスリセット発生時におけるデバイスリスト
ウィンドウの表示制御処理を示すフローチャートであ
る。

【符号の説明】

１１３ パーソナルコンピュータ、１１６ データバ
ス、２０１ ＣＰＵ、２０２ ＲＯＭ、２０３ ＲＡ
Ｍ、２０４ 入出力インターフェイス、２０５ キーボ
ード、２０６ マウス、２０８ ディスプレイモニタ、
２０９ ＩＥＥＥ１３９４インターフェイス、２１０
内部バス

───────────────────────────────────────────────────── フロントページの続き (72)発明者 山口 博士 長野県南安曇郡豊科町大字豊科5432番地 ソニーデジタルプロダクツ株式会社内 (72)発明者 後藤 隆志 東京都品川区北品川６丁目７番35号 ソニ ー株式会社内 Ｆターム(参考） 5B077 MM02 NN02 5E501 AA02 AC15 AC23 AC25 AC33 AC35 BA03 CA02 EB05 FA05 FA13 FA14 5K032 BA01 BA16 CD01 5K033 BA01 BA15 CC01

Claims (2)

【特許請求の範囲】
1. 【請求項１】 所定の通信フォーマットによるデータバ
   スを介して接続される他の情報処理装置と情報の送受信
   を行うことのできる情報処理装置として、 上記データバス上に存在するとされる情報処理装置ごと
   に対応するようにして文字情報を入力することのできる
   文字情報入力手段と、 上記情報処理装置ごとに固有となるようにして与えられ
   た機器識別情報を、上記データバス上に存在するとされ
   る情報処理装置の各々から取得することのできる機器識
   別情報取得手段と、 上記文字情報と、この文字情報が対応する情報処理装置
   の上記機器識別情報とを対応付けた対応情報を生成して
   所定の記憶手段に記憶させる対応情報管理手段と、 現在データバス上に存在するとされる情報処理装置の機
   器識別情報に対応付けされた上記文字情報を上記対応情
   報から検索し、この検索された文字情報が現在データバ
   ス上に存在するとされる各情報処理装置を特定するため
   の情報として表示出力されるように表示制御を実行する
   表示制御手段と、 を備えていることを特徴とする情報処理装置。
2. 【請求項２】 所定の通信フォーマットによるデータバ
   スを介して接続されることで情報の送受信を行う情報処
   理装置の管理方法であって、 上記データバス上に存在するとされる情報処理装置ごと
   に対応するようにして文字情報を入力する文字情報入力
   処理と、 上記情報処理装置ごとに固有となるようにして与えられ
   た機器識別情報を、上記データバス上に存在するとされ
   る情報処理装置の各々から取得することのできる機器識
   別情報取得処理と、 上記文字情報と、この文字情報が対応する情報処理装置
   の上記機器識別情報とを対応付けた対応情報を生成して
   所定の記憶領域に記憶させる対応情報管理処理と、 現在データバス上に存在するとされる情報処理装置の機
   器識別情報に対応付けされた上記文字情報を上記対応情
   報から検索し、この検索された文字情報が現在データバ
   ス上に存在するとされる各情報処理装置を特定するため
   の情報として表示出力されるように表示制御を実行する
   表示制御処理と、 を実行するように構成されていることを特徴とする情報
   処理装置の管理方法。