JP4403331B2 - 電子機器システム、情報処理機器 - Google Patents
電子機器システム、情報処理機器 Download PDFInfo
- Publication number
- JP4403331B2 JP4403331B2 JP2000050515A JP2000050515A JP4403331B2 JP 4403331 B2 JP4403331 B2 JP 4403331B2 JP 2000050515 A JP2000050515 A JP 2000050515A JP 2000050515 A JP2000050515 A JP 2000050515A JP 4403331 B2 JP4403331 B2 JP 4403331B2
- Authority
- JP
- Japan
- Prior art keywords
- data
- information processing
- power supply
- str
- source output
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B31/00—Arrangements for the associated working of recording or reproducing apparatus with related apparatus
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04B—TRANSMISSION
- H04B1/00—Details of transmission systems, not covered by a single one of groups H04B3/00 - H04B13/00; Details of transmission systems not characterised by the medium used for transmission
- H04B1/06—Receivers
- H04B1/16—Circuits
- H04B1/20—Circuits for coupling gramophone pick-up, recorder output, or microphone to receiver
- H04B1/205—Circuits for coupling gramophone pick-up, recorder output, or microphone to receiver with control bus for exchanging commands between units
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Signal Processing For Digital Recording And Reproducing (AREA)
- Selective Calling Equipment (AREA)
- Power Sources (AREA)
- Information Transfer Systems (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、所定のデータ通信フォーマットに依るデータインターフェイスを介してデータの送受信を行うようにされる電子機器システム、及びこのような電子機器システムを構成する情報処理機器に関するものである。
【０００２】
【従来の技術】
近年、デジタルデータインターフェイスとして、ＩＥＥＥ(Institute of Electrical Engineers)１３９４データインターフェイスが知られてきている。ＩＥＥＥ１３９４データインターフェイスは、例えばＳＣＳＩなどよりもデータ転送レートが高速であり、周知のように、所要のデータサイズを周期的に送受信することが保証されるＩｓｏｃｈｒｏｎｏｕｓ通信が可能とされる。このため、ＩＥＥＥ１３９４データインターフェイスは、ＡＶ(Audio/Video)などのストリームデータをリアルタイムで転送するのに有利とされている。
【０００３】
このような技術を背景として、各種デジタルＡＶ機器やパーソナルコンピュータ装置等の電子機器を、例えばＩＥＥＥ１３９４等のデータインターフェイス規格に従ったデータバスを介して相互に接続することで、機器間でＡＶデータを送受信できるようにしたＡＶシステムが提案されてきている。
【０００４】
【発明が解決しようとする課題】
ここで、これまでのＡＶシステムにおける電源オン／オフの連動について考えてみる。
これまでに広く普及している、いわゆるシステムコンポーネントといわれるＡＶシステムでは、システムを構成する各ソースの記録再生機器部やアンプなどを統合的に組むことによって、全体としては１つのオーディオ機器として認識されるように構成されている。このため、そのシステムコンポーネントのメイン電源に対してオン／オフを行えば、例えばローカルな内部バスを利用して制御を行うことで、システムコンポーネントを構成している各機器部の電源のオン／オフを連動的に行うことが可能とされている。
また、例えばアンプなどに対して設けられている連動タイプの電源コンセントに対して他のＡＶ機器の電源を接続しておくようにすることで、各機器間の電源のオン／オフが連動するようにされたシステムコンポーネントも古くから知られているものである。
【０００５】
これに対して、ＩＥＥＥ１３９４等のデータインターフェイスにおいては、ＩＥＥＥ１３９４インターフェイス機能を有している機器であれば、原則として機種やメーカを問わずに相互通信可能に接続することが可能とされる。このため、ＩＥＥＥ１３９４等のデータインターフェイスにより接続されるシステムにおいては、このシステムを構成する各機器は、データバス上ではそれぞれ独立した機器として認識される。
また、電源についても、例えば各機器ごとに独立して商用交流電源から入力可能にされており、例えば、あえて連動タイプの電力源を使用しての電源オン／オフの連動を考慮したシステムが構築されるとは限らない。
【０００６】
即ち、現状としては、例えばＩＥＥＥ１３９４などのデータインターフェイスを利用して構成されるＡＶシステムなどにおいて、例えば同一シリーズの機種や同一メーカ機器などの或る特定の機種の機器間でシステムコンポーネント的な機能を有する構成を与えようとした場合には、これらの機器がデータバス上で独立した機器として認識される以上、そのままでは上記したような電源オン／オフの連動は行うことができないことになるものである。しかし、ＡＶシステムとしての使い勝手を考慮した場合には、当然のこととして、電源のオン／オフの連動が可能とされることが好ましいことになり、利便性も向上されることになる。
【０００７】
また、これまでのシステムコンポーネントにおいては、例えばシステムの中心となるアンプ機器などの電源オン／オフに応じて他の機器の電源オン／オフを連動させるという機能を有しているものであり、例えば逆に、メインとなる機器が、他の機器の電源オン／オフ状態にあわせて自機の電源状態をコントロールする機能は実現されていない。
特にＩＥＥＥ１３９４データバスを利用してのシステムでは、物理的なケーブルの接続形態によって信号の流れは決まってくるものではなく、データバス上に存在する各機器は基本的に相互通信が可能である。従って、各オーディオ機器の利用形態も多様となることから、上記したような、メインとなる機器が他の機器に従うようにして自機の電源をコントロールする機能が付加されても、これは有効に活用されるものである。
【０００８】
【課題を解決するための手段】
そこで本発明は上記した課題を考慮して、先ず電子機器システムとして次のように構成する。
つまり、それぞれ電源を独立して入力可能とされ、所定の通信フォーマットによるデータバスを介してソース情報を送信出力するソース出力機器を含む電子機器と、上記ソース出力機器から送信されてきた上記ソース情報を入力する情報処理機器とを備えて成る電子機器システムにおいて、上記情報処理機器は、上記情報処理機器が自身の電源をオフとすることが可能な所定の条件を満たした状態にあるか否かについて自動で判別する条件判別手段と、上記条件判別手段により上記所定の条件を満たした状態にあると判別されたことに応じて、上記ソース出力機器のうち特定の１以上のソース出力機器ごとに対して、上記データバスを介して、電源状態がオフであるか否かについての通知を要求する要求コマンドを送信する要求コマンド送信手段と、上記要求コマンドを受信したことに応じてソース出力機器から送信された、このソース出力機器の電源状態がオフであるか否かについての通知内容を有する応答コマンドを受信する受信手段と、上記受信手段により受信した応答コマンドの通知内容として、電源状態がオフであることを示しているか否かについて判別する電源状態判別手段と、上記電源状態判別手段により電源状態がオフであることを示していると判別された場合に、自機の電源をオンからオフに切り換えるように制御する制御手段とを備えることとした。
【０００９】
また、情報処理機器としては次のように構成する。
つまり、それぞれの電子機器が独立して電源を入力可能とされ、所定の通信フォーマットによるデータバスを介して他の電子機器と接続されることで情報の送受信が可能なように形成される電子機器システムにおける情報処理機器として、上記他の電子機器のうちのソース出力機器としての電子機器から送信出力されるソース情報を入力するソース情報入力手段と、本情報処理機器が自身の電源をオフとすることのできる所定の条件を満たした状態にあるか否かについて自動で判別する条件判別手段と、上記条件判別手段により上記所定の条件を満たした状態にあると判別されたことに応じて、上記ソース出力機器のうち特定の１以上の電子機器に対して、上記データバスを介して、このソース出力機器の電源状態がオフであるか否かについての通知を要求する要求コマンドを送信する要求コマンド送信手段と、上記要求コマンドを受信したことに応じてソース出力機器から送信された、電源状態がオフであるか否かについての通知内容を有する応答コマンドを受信する受信手段と、上記受信手段により受信した応答コマンドの通知内容として、電源状態がオフであることを示しているか否かについて判別する電源状態判別手段と、上記電源状態判別手段により電源状態がオフであることを示していると判別された場合に、自機の電源をオンからオフに切り換えるように制御する制御手段とを備えて構成することとした。
【００１１】
上記各構成によれば、ソース情報の出力を行うソース出力機器としての電子機器と、ソース情報を入力する情報処理機器とされる電子機器をデータバスを介して接続することでシステムを構築した場合において、情報処理機器では、ソース出力機器の電源状態がオフにあることを検出すると、自機の電源もオフとするように動作することになる。つまり、本発明では、各電子機器がデータバス上で独立した存在であると認識されている場合であっても、電源を連動してコントロールすることが可能とされると共に、例えばシステム内において中心として機能し得る情報処理機器が、他の機器の電源状態に応じて自身の電源のコントロールを行うという動作を得ることができる。
【００１２】
【発明の実施の形態】
以下、本発明の実施の形態について説明する。
なお、以降の説明は次の順序で行う。
１．ＡＶシステム
１−１．全体構成
１−２．ＳＴＲ（フロントパネル）
１−３．ＣＤ機（フロントパネル）
１−４．ＭＤ機（フロントパネル）
１−５．ＳＴＲ（内部）
１−６．ＣＤ機（内部）
１−７．ＭＤ機（内部）
２．ＩＥＥＥ１３９４による本実施の形態のデータ通信
２−１．概要
２−２．スタックモデル
２−３．信号伝送形態
２−４．機器間のバス接続
２−５．パケット
２−６．トランザクションルール
２−７．アドレッシング
２−８．ＣＩＰ(Common Isochronos Packet)
２−９．コネクションマネージメント
２−１０．ＦＣＰにおけるコマンド及びレスポンス
２−１１．ＡＶ／Ｃコマンドパケット
２−１２．プラグ
２−１３．Asynchronous Connection送信手順
４．ノード分類処理
５．ＳＴＲの電源オフ連動機能
５−１．概要
５−２．ＰＯＷＥＲ ＳＴＡＴＵＳ ｃｏｍｍｍａｎｄ
５−３．処理動作
【００１３】
１．ＡＶシステム
１−１．全体構成
図１は本発明の実施の形態の電子機器システムの構成例を示している。
本実施の形態としての電子機器システムは、複数のＡＶ機器等をＩＥＥＥ１３９４インターフェイスのデータバスにより相互通信可能に接続することで構築される。
【００１４】
図１においては、ＡＶシステムを構成する機器として、ＳＴＲ(Stereo Tuner Receiver)６０と、２台のＳＴＲ対応ＣＤ機３０，３０、ＳＴＲ対応ＭＤ機１、同一メーカ機種１００、他社メーカ機種１１０が示される。
【００１５】
ＳＴＲ６０は、図１に示すＡＶシステムの中心として機能するもので、主としてチューナ機能、外部ソース入力選択機能、及びアンプ機能を備えており、例えば図のようにしてステレオ音声に対応する左右チャンネルのスピーカＳＰ（Ｌ）（Ｒ）を接続することができるようになっている。
詳しい構成は後述するが、ＳＴＲ６０では、内部のチューナ部で受信した放送信号と、アナログオーディオ信号入力と、さらにＩＥＥＥ１３９４バス１１６を介して外部から入力される複数のオーディオソースについて選択を行い、最終的には、これを音声としてスピーカＳＰ（Ｌ）（Ｒ）から出力させることができるように構成されている。
【００１６】
また、この図には、ＳＴＲ６０に対する操作を行うためのリモートコントローラＲＭも示されている。ＳＴＲ６０は、このリモートコントローラＲＭに対して行われた操作に応じて送信されてくる操作コマンド信号を受信し、その操作コマンド信号の内容に応じた所要の動作を実行する。なお、この図では、ＳＴＲ６０に対応するリモートコントローラＲＭのみが示されているが、実際としては、他の機器についてもリモートコントローラによる操作が可能とされていてよいものである。
【００１７】
また、上記ＳＴＲ６０と共に接続することで利便性の高い各種のシステム機能を実現することのできる機種として、ここではＳＴＲ対応ＣＤ機３０とＳＴＲ対応ＭＤ機１とが示されている。ＳＴＲ対応ＣＤ機３０とＳＴＲ対応ＭＤ機１は、例えばＳＴＲ６０と同一メーカ品とされる。
【００１８】
ＳＴＲ対応ＣＤ機３０は、ＣＤ(Compact Disc)プレーヤとしての機能を有しており、装填されたＣＤについての再生を行う。そして、ＣＤから再生して得られるオーディオデータを、ＩＥＥＥ１３９４バス１１６を介して送信出力することが可能とされる。
また、ＳＴＲ対応ＭＤ機１は、ＭＤ(Mini Disc)といわれるオーディオデータを書き換え可能な光磁気ディスクに対応して記録再生を行うことのできるＭＤレコーダ／プレーヤとされる。そしてこのＳＴＲ対応ＭＤ機１においては、ＩＥＥＥ１３９４バス１１６を介して送信されてくるオーディオデータを受信してＭＤに対して記録することが可能とされている。また、ＭＤに記録されているオーディオデータを再生して、ＩＥＥＥ１３９４バス１１６を介して送信出力することが可能とされる。
【００１９】
上記ＳＴＲ６０、ＳＴＲ対応ＣＤ機３０、及びＳＴＲ対応ＭＤ機１の３台によって得られる代表的なシステム動作としては次のようなものが挙げられる。
例えば、ＳＴＲ対応ＣＤ機３０にて再生しているＣＤのオーディオデータをＳＴＲ対応ＭＤ機１に対して送信することで、ＳＴＲ対応ＭＤ機１においては、このＣＤのオーディオデータをＭＤに記録することができる。つまり、いわゆるダビングを行うことが可能となるものである。また、このときにＳＴＲ対応ＣＤ機３０にて再生しているＣＤのオーディオデータ、または一旦ＳＴＲ対応ＭＤ機１にて受信されたＣＤのオーディオデータをＳＴＲ６０に対しても送信すれば、ＳＴＲ６０ではこのＣＤのオーディオデータをモニタ音声としてスピーカＳＰ（Ｌ）（Ｒ）から出力させることが可能とされる。
【００２０】
また、ここでの詳しい説明は省略するが、ＳＴＲ対応ＣＤ機３０とＳＴＲ対応ＭＤ機１は、ＳＴＲ６０を中心としたいわゆるオーディオ・コンポーネントシステム的な各種機能が特化して与えられるべきものとして構成されている。例えば、ＳＴＲ対応ＣＤ機３０からＳＴＲ対応ＭＤ機１へのダビングを例に挙げれば、倍速ダビング動作や、ＣＤの再生開始／終了タイミングに同期させて、ＳＴＲ対応ＭＤ機１における記録開始／終了タイミングを制御する、いわゆるシンクロ・ダビング動作なども容易に実行可能とされている。
【００２１】
同一メーカ機器１００は、ＳＴＲ６０、ＳＴＲ対応ＣＤ機３０、及びＳＴＲ対応ＭＤ機１と同一メーカとされて、ＩＥＥＥ１３９４インターフェイスに対応した通信機能を有するデジタルＡＶ機器である。ここでの同一メーカ機器１００の実際としては、特に言及しないが、例えばＣＤプレーヤ、ＭＤレコーダ／プレーヤや、デジタルＶＴＲなどとされればよいものである。
この同一メーカ機器１００としては、例えばＳＴＲ対応ＣＤ機３０、及びＳＴＲ対応ＭＤ機１などと比較した場合には、特にＳＴＲ６０を中心とするシステムコンポーネント機能が与えられるようには構成されていない点が異なる。
ただし、メーカ内のみで有効となるコマンド（Vender Dependent Commnandといわれる)の送受信によっては、ＳＴＲ６０、ＳＴＲ対応ＣＤ機３０、ＳＴＲ対応ＭＤ機１と共に、そのメーカで規定した特定の機能を有するように動作することが可能とされるものである。
また、例えばＳＴＲ６０に対して、この同一メーカ機器１００から送信されてくるオーディオソースとしてのデータを選択して受信入力するようにマニュアル操作を行えば、これを音声としてモニタすることが可能である。また、ＳＴＲ対応ＭＤ機１において入力ソースとして、同一メーカ機器１００から送信されるオーディオデータが選択されるようにマニュアル操作を行えば、これをＭＤに記録することも可能とされる。この点については、次に説明する他社メーカ機器１１０も同様である。
【００２２】
他社メーカ機器１１０もまたＩＥＥＥ１３９４インターフェイスに対応した通信機能を有する何らかのデジタルＡＶ機器であるが、ＳＴＲ６０、ＳＴＲ対応ＣＤ機３０及びＳＴＲ対応ＭＤ機１とは製造メーカが異なる。ここでの他社メーカ機器１１０の実際としても、ＣＤプレーヤ、ＭＤレコーダ／プレーヤや、デジタルＶＴＲなどとされればよいものである。また、この他社メーカ機器１１０の場合には、原則として上記したＳＴＲ６０のメーカで規定するVender Dependent Commnandには対応不可となる。
【００２３】
なお、ここでは図示していないが、例えばこの図１に示す各ＡＶ機器としては、それぞれが商用交流電源から電力を入力するための電源コンセントが備えられる。もしくは、バッテリ駆動可能な構成であればバッテリを収納可能とされている。つまりは、各機器がそれぞれ独立して電力を得ることが可能とされているものである。
【００２４】
１−２．ＳＴＲ（フロントパネル）
続いて、上記図１に示したシステムを構成する上で主となる、ＳＴＲ６０と、このＳＴＲ６０とコンポーネント的システムを組むＳＴＲ対応ＣＤ機３０及びＳＴＲ対応ＭＤ機１の外観構成として、各々のフロントパネル部位について説明しておく。
【００２５】
図２はＳＴＲ６０本体のフロントパネル部位の様子を示している。
フロントパネル左下側には、電源キー１２０が設けられている。この電源キー１２０を操作することで、ＳＴＲ６０は、電源のオン／オフが切り換わるようにされている。なお、ここでいう電源がオフの状態とは、スタンバイ電源は動作しているいわゆるスタンバイ状態を指しているもので、例えば商用交流電源（又はバッテリ）の供給が絶たれている状態とは異なる。この点では、以降説明する、ＳＴＲ対応ＣＤ機３０とＳＴＲ対応ＭＤ機１についても同様とされる。
また、ここでの詳しい説明は省略するが、ＳＴＲ６０では、スリープ状態とするためのスリープモードも用意されていることで、省電力化が考慮されている。
【００２６】
また、電源キー１２０の左側にはヘッドフォンジャック２７ｊが設けられている。
【００２７】
フロントパネルのほぼ中央部には、表示部７５が配置されている。
この場合の表示部７５としては、主として文字表示を行うためのＦＬ管表示部７５Ａが設けられており、ここでは、１行１４文字分の表示が行われるようにされている。そして、その周囲にはセグメント表示部７５Ｂが設けられており、図示してはいないが所定の決められた内容がセグメントによって表示される。
【００２８】
表示部７５の左側にはディスプレイキー１２７が設けられ、さらにその左にはディマーキー１２８が設けられる。
ディスプレイキー１２７は、基本的には表示部７５における表示内容を変更するためのものとされる。ディマーキー１２８は、表示部７５、及びフロントパネルに実際に設けられるとされる装飾用ＬＥＤの輝度を調節するためのものである。
【００２９】
また、ＦＬ管表示部７５Ａの右側には、ジョグダイヤル１２５と、その上側にバンドキー１２１、チューナモードキー１２２、ジョグ選択キー１２３、エンターキー１２４が示される。
バンドキー１２１、チューナモードキー１２２は、ＳＴＲ６０のチューナ機能に関連するキーであり、それぞれ、受信バンド、チューナモードの切り換えを行うときに使用する。
また、ジョグ選択キー１２３は、メニュー選択を行うためのキーとされ、エンターキー１２４は決定操作を行うときに使用される。
そして、ジョグダイヤル１２５は、所定の操作手順のもとで上記各キーと共に併用されるもので、これによりユーザは実際の各種操作を行うことができる。
【００３０】
一例として、ジョグ選択キー１２３を１回押圧操作するごとに、ＦＬ管表示部７５Ａの表示内容は、FUNCTION→SOUND→SETUPのようにしてトグルで変化する。
そして例えば、ＦＬ管表示部７５ＡにFUNCTIONと表示させた状態でジョグダイヤル１２５を回転操作すると、ＳＴＲ６０が入力してモニタ音声として出力するソースの選択を変更していくことができるようになっている。このときのＦＬ管表示部７５Ａには、ジョグダイヤル１２５の回転操作に応じて現在選択されている入力ソース名が表示されるようになっている。この操作によっては、例えばチューナ音声、アナログ入力、及びＩＥＥＥ１３９４バスを介して入力される各ソース（機器）を所定順序に従って順次選択していくことが可能とされる。
なお、例えばバンドキー１２１、チューナモードキー１２２、ジョグ選択キー１２３、エンターキー１２４などのキーは、その背面側に装飾用のＬＥＤが設けられており、動作状態等に応じて点灯、点滅などするようにもされている。
【００３１】
ボリュームジョグ１２６は、ＳＴＲ６０から出力される音声信号レベル、つまり、例えばスピーカＳＰ（Ｌ）（Ｒ）から出力される音量を調整するためのダイヤルキーとして備えられる。
【００３２】
１−３．ＣＤ機（フロントパネル）
図３は、ＳＴＲ対応ＣＤ機３０のフロントパネル部位を示している。
先ず、このＳＴＲ対応ＣＤ機３０のフロントパネル左下側においても、電源オン／オフ（スタンバイ）のための電源キー１５０が設けられている。
【００３３】
また、このＳＴＲ対応ＣＤ機３０のフロントパネルの中央上部には、ＣＤを挿入／排出するためのディスク挿脱部１５９が設けられている。例えばディスク挿脱部１５９内に収納されて装填されている状態にあるＣＤを排出させるためには、このディスク挿脱部１５９の右側に配置されるイジェクトキー１５１を操作する。
【００３４】
上記ディスク挿脱部１５９の下側には、例えば１行１４文字分の表示が可能なＦＬ管表示部４７Ａと、セグメント表示部４７Ｂとから成る表示部４７が設けられている。この場合、ＦＬ管表示部４７Ａに対しては、例えば現在装填されているＣＤにて再生されるトラックのトラックナンバ、再生時間等の再生状況を示す情報や、ＣＤのサブコード内に挿入されているＣＤテキストデータなどが文字等として表示される。また、セグメント表示部４７Ｂには再生モードなどが示される。
ＦＬ管表示部４７Ａにおける表示内容の切り換えは、表示部４７の左側に配置されるディスプレイキー１５６を操作することによって行うことができる。また、輝度調整のためにはディマーキー１５７を操作する。
【００３５】
また、フロントパネル上の右側には、ＣＤの再生に関するキーとして、再生／一時停止キー１５２、停止キー１５３，頭出し・早送り／早戻しキー１５４，１５５が設けられている。
【００３６】
１−４．ＭＤ機（フロントパネル）
図４に、ＳＴＲ対応ＭＤ機１のフロントパネル部位を示す。
ここでも、ＳＴＲ対応ＭＤ機１のフロントパネル左下側においては電源キー１３０が設けられている。
【００３７】
そしてフロントパネルの中央上部には、ＭＤを挿入／排出するためのディスク挿脱部１４５が設けられており、この場合にも、その右側にはＭＤを排出させるためのイジェクトキー１３１が配置される。
【００３８】
またここでも、上記ディスク挿脱部１４５の下側には、例えば１行１４文字表示が可能なＦＬ管表示部２４Ａとセグメント表示部２４Ｂとから成る表示部２４が設けられている。この場合、ＦＬ管表示部２４Ａに対しては、例えば現在装填されているＭＤに対して記録又は再生されるトラックのトラックナンバ、記録又は再生時間等の記録再生状況を示す情報が表示される。さらには、ＭＤのディスクタイトルやトラックネームなども表示される。また、この場合にもセグメント表示部２４Ｂには再生モードなどが示される。
さらに、このＳＴＲ対応ＭＤ機１においても表示内容を切り換えるためのディスプレイキー１５６、及び輝度調整のためのディマーキー１５７が設けられる。
【００３９】
また、フロントパネルの右側に配置される記録再生に関するキーとして、この場合には、再生／一時停止キー１３２、停止キー１３３，頭出し・早送り／早戻しキー１３４，１３５、録音キー１３６、高速ダビングキー１３７、シンクロ録音キー１３８が設けられる。
また、入力選択キー１３９は、録音ソースとしての入力を選択するために設けられている。この入力選択キー１３９の操作に応じて、例えばＦＬ管表示部２４Ａにおいては、現在選択されている録音ソース名が表示されるようになっている。
【００４０】
ここで、上記図２〜図４に示すフロントパネルの様子からも分かるように、ＳＴＲ６０、ＳＴＲ対応ＣＤ機３０、及びＳＴＲ対応ＭＤ機１は、それぞれが、自機のための表示部７５，４７，２４を有している。換言すれば、例えばＳＴＲ及びＳＴＲ対応機器から成るシステムを、１つのオーディオコンポーネントシステムとして考えた場合、このコンポーネントシステムとして統合された表示部位というものは設けられてはいないことになる。これは、例えばＩＥＥＥ１３９４を介して接続される機器としては、本来、個々に独立した存在であることに対応している。
【００４１】
１−５．ＳＴＲ（内部）
続いて、ＳＴＲ６０、ＳＴＲ対応ＣＤ機３０、及びＳＴＲ対応ＭＤ機１の各内部構成について説明を行っていくこととする。
【００４２】
先ず、図５のブロック図にはＳＴＲ６０の内部構成例が示されている。
ＳＴＲ６０においては、オーディオソースとして、ＩＥＥＥ１３９４バス１１６を介して送信されてくるオーディオ信号と、自身が備えるチューナのオーディオ信号と、アナログ入力端子７８から入力される外部アナログオーディオ信号との３種を入力可能とされる。
【００４３】
ＩＥＥＥ１３９４インターフェイス６１は、ＩＥＥＥ１３９４バス１１６を介して他の外部機器とデータの送受信を行うために設けられる。これにより、ＳＴＲ６０としては、外部とのＡＶデータの送受信、及び各種コマンドの送受信が可能に構成されることとなる。
ＩＥＥＥ１３９４インターフェイス６１では、ＩＥＥＥ１３９４バス１１６を介して受信したパケットを復調し、復調したパケットに含まれるデータを抽出する。そしてこの抽出したデータを内部データ通信に適合するフォーマットのデータに変換して出力する。
例えばＩＥＥＥ１３９４バス１１６を介して他のＡＶ機器からオーディオデータが送信されてくるとする。ＩＥＥＥ１３９４インターフェイス６１では、この送信されてきたオーディオデータを受信して、上記パケットに対する復調処理を行い、この場合には例えばＩＥＣ９５８といわれるデジタルオーディオデータインターフェイスのデータフォーマットに変換して復調処理部６３に対して出力する。
【００４４】
復調処理部６３においては、入力されたオーディオデータについて、例えばＩＥＣ９５８フォーマットに従った所要の復調処理を施してデジタルフィルタ６４に出力する。
【００４５】
デジタルフィルタ６４は、主としては、例えば入力されたオーディオデータについてのジッター除去を行う機能を有している。また、復調処理部６３から出力されるデータとしては、送信元の機器等の相違に応じて、異なるサンプリング周波数を有しているものであるが、このデジタルフィルタ６４においては、これらの異なるサンプリングレートを有するオーディオデータについて、４４．１ＫＨｚのサンプリング周波数に変換して出力することも行っている。
このようにして４４．１ＫＨｚのサンプリング周波数による信号フォーマットに変換されたオーディオデータは、ＤＳＰ(Digital Signal Processor)６５に対して入力される。
なお、例えば送信元から４４．１ＫＨｚのサンプリング周波数による信号フォーマットによるオーディオデータが送信されてくる場合には、上記復調処理部６３、デジタルフィルタ６４を介することなく、ＩＥＥＥ１３９４インターフェイス６１から直接的にＤＳＰ６５に対してオーディオデータを送信するようにもされる。
【００４６】
ＤＳＰ６５においては、オーディオデータに対して各種所要の信号処理を施す。例えば、イコライザ設定に従ったイコライジング処理等もここで実行される。そして信号処理が施されたオーディオデータをＡ／Ｄ・Ｄ／Ａ部６６のデジタルフィルタ６９に対して出力する。
【００４７】
Ａ／Ｄ・Ｄ／Ａ部６６は、オーディオ信号についてのアナログ−デジタル変換処理、及びデジタル−アナログ変換処理を行うための回路部位である。
このＡ／Ｄ・Ｄ／Ａ部６６のデジタルフィルタ６９に入力されたオーディオデータは、Ｄ／Ａコンバータ６８に入力されることで電圧パルス列としての信号に変換される。そして、Ｉ−ＤＡＣコンバータ８１に対して入力される。
Ｉ−ＤＡＣコンバータ８１では、入力された電圧パルス列を電流に変換する。
ここで、図示は省略しているが、基準となるレベルが別系統で与えられており、その基準レベルを操作することで、出力電流を可変することが可能とされており、これを例えば４０ｄＢ以下のレベル範囲でのボリューム調整に利用することもできるようになっている。
【００４８】
アンプ８２では、Ｉ−ＤＡＣコンバータ８１の出力について増幅を行ってスピーカ出力端子８３に対して出力する。そして、このスピーカ出力端子８３にスピーカＳＰ（Ｌ）（Ｒ）が接続されていれば、ステレオ音声としての出力が行われることになる。
【００４９】
チューナ部７７は、ＳＴＲ６０内に備えられており、アンテナ７６にて受信されたラジオ放送の電波について、選局及び復調処理等を行って例えばアナログ音声信号としてセレクタ７９に出力する。
また、アナログオーディオ信号入力端子７８を介して入力されるアナログ音声信号もまたセレクタ７９に対して入力される。
【００５０】
セレクタ７９では、例えばシステムコントローラ７０の制御に応じて、チューナ部７７とアナログオーディオ信号入力端子７８の何れかを入力ソースとして選択して、選択したアナログオーディオ信号をＡ／Ｄ・Ｄ／Ａ部６６のＡ／Ｄコンバータ６７に対して供給する。Ａ／Ｄコンバータ６７では入力されてきたアナログオーディオ信号をデジタルオーディオデータに変換する。
【００５１】
ここで、Ａ／Ｄコンバータ６７にて得られたデジタルオーディオデータをモニタ音声として出力する場合には、先に述べた、Ｄ／Ａコンバータ６８→Ｉ−ＤＡＣコンバータ８１→アンプ８２の処理を経てスピーカＳＰ（Ｌ）（Ｒ）に対して出力するようにされる。
また、例えば録音などのために、Ａ／Ｄコンバータ６７にて得られたデジタルオーディオデータをＩＥＥＥ１３９４バス１１６を介して他のＡＶ機器に送信出力する必要のある場合には、このデジタルオーディオデータを変調処理部８０に対して出力する。
変調処理部８０では、例えばＩＥＣ９５８などのデジタルオーディオデータインターフェイスのフォーマットに適合する変調処理を施してＩＥＥＥ１３９４インターフェイス６１に対して出力する。ＩＥＥＥ１３９４インターフェイス６１では、例えばＲＡＭ６２を利用して、パケット化をはじめとする所要の処理を施して、ＩＥＥＥ１３９４フォーマットに適合するフォーマットに変換する。そして、ＩＥＥＥ１３９４バス１１６を介して、目的の機器に対して送信出力を行う。
【００５２】
システムコントローラ７０は、例えばＣＰＵ(Central Processing Unit)、ＲＯＭ７１、ＲＡＭ７２などを備えて構成され、ＳＴＲ６０についての各種動作制御を実行する。
【００５３】
また、システムコントローラ７０に対しては、受信部７３及び操作部７４からの情報が入力されるようになっている。例えば受信部７３においては、リモートコントローラＲＭから送信されてきた無線のコマンド信号を受信し、この受信したコマンド信号をシステムコントローラ７０に対して出力する。
操作部７４は、例えばフロントパネルに設けられている各種キーより成るものとされ、この操作部７４に対して行われた操作に応じた操作情報がシステムコントローラ７０に対して出力される。
システムコントローラ７０では、上記のようにして入力されてくるコマンド信号及び操作情報に応答した所要の動作が得られるように、各種制御処理を実行する。
また、システムコントローラ７５は、例えば上記したコマンド信号及び操作情報や、現在の動作状況等に応じた所要の内容の表示が行われるように、表示部７５に対する表示制御も実行する。この表示部７５は、前述もしたように、例えばＦＬ管表示部とセグメント表示部とを備えている。
【００５４】
１−６．ＣＤ機（内部）
次にＳＴＲ対応ＣＤ機３０の内部構成について図６のブロック図を参照して説明する。
周知のように再生専用のディスクメディアであるＣＤ９１は、前述した本体フロントパネルのディスク挿脱部１５９から挿入されることで、再生可能位置に装填される。
再生可能位置に装填されたＣＤ９１は、ＣＤ再生動作時においてスピンドルモータ３１によって一定線速度（ＣＬＶ）で回転駆動される。そして光学ヘッド３２によってＣＤ９１にピット形態で記録されているデータが読み出され、ＲＦアンプ３５に供給される。光学ヘッド３２において対物レンズ３２ａは２軸機構３３によって保持され、トラッキング及びフォーカス方向に変位可能とされる。
また光学ヘッド３２はスレッド機構３４によってＣＤ９１の半径方向に移動可能とされる。
【００５５】
ＲＦアンプ３５では再生ＲＦ信号のほか、フォーカスエラー信号、トラッキングエラー信号を生成し、これらのエラー信号はサーボ回路３６に供給される。
サーボ回路３６はフォーカスエラー信号、トラッキングエラー信号から、フォーカス駆動信号、トラッキング駆動信号、スレッド駆動信号等の各種駆動信号を生成し、２軸機構３３、及びスレッド機構３４の動作を制御する。つまり、フォーカスサーボ制御及びトラッキングサーボ制御を実行する。
また、ＲＦアンプ３５において二値化された再生ＲＦ信号は、タイミングジェネレータ４２に対しても出力されており、タイミングジェネレータ４２においては、この再生ＲＦ信号の波形タイミングに基づいて、タイミング信号を生成してＣＬＶプロセッサ４３に対して出力する。ＣＬＶプロセッサ４３では、入力されたタイミング信号に基づいて、スピンドルモータ３１を所要のＣＬＶ速度により回転制御するための駆動信号を生成してスピンドルモータに供給する。これにより、ＣＤ９１をＣＬＶにより回転駆動するためのスピンドルサーボ制御が実行される。
【００５６】
再生ＲＦ信号はデコーダ３７に供給される。デコーダ３７では先ず入力された再生ＲＦ信号について二値化を行ってＥＦＭ信号を得る。そして、このＥＦＭ信号についてＥＦＭ復調，ＣＩＲＣデコード等を行なってＣＤ９１から読み取られた情報を１６ビット量子化、44.1KHz サンプリングのフォーマットのオーディオデータにデコードする。
【００５７】
またデコーダ３７ではサブコード等の制御データも抽出可能な構成を採っている。サブコードとしてのデータ部分は、サブコードプロセッサ４４に供給され、ここでサブコードとしての適正なデータに整えられる。また、特にＣＤのリードインエリアに記録されているサブコードのサブＱデータとして記録されているＴＯＣ(Table Of Contents)情報を抽出することも行われる。これらのサブコードデータ、ＴＯＣはシステムコントローラ５０に供給されることで、例えば各種制御に用いられる。システムコントローラ５０は、このＣＤ機としての所要の各種動作が実行されるように各種制御処理を実行する。
【００５８】
また、ＲＦアンプ３５にて二値化された再生ＲＦ信号は、ＰＬＬ回路３９に対しても供給される。
ＰＬＬ回路３９は、入力されたＥＦＭ信号のチャンネルビットに同期したクロックを出力する。このクロックの周波数としては、定常の１倍速では４．３２１８ＭＨｚとされる。そして、このクロックは、例えばデコーダ３７以降の信号処理回路系のクロックとして利用される。
【００５９】
この場合、デコーダ３７から出力されるオーディオデータは、Ｄ／Ａコンバータ３８及びＩＥＥＥ１３９４インターフェイス４９に対して分岐して出力される。
Ｄ／Ａコンバータ３８に入力されたオーディオデータはアナログオーディオ信号に変換され、アンプ４０を介して外部アナログオーディオ出力端子４１に対して出力されるようになっている。
また、デコーダ３７からＩＥＥＥ１３９４インターフェイス４９に入力されるオーディオデータは、ＩＥＥＥ１３９４のフォーマットに適合するデータに変換され、ＩＥＥＥ１３９４バス１１６を介して外部機器に対して送信出力される。
また、ＩＥＥＥ１３９４インターフェイス４９では、外部から送信されてくるコマンド等のデータを受信することも行う。そして、例えばシステムコントローラ５０は、この受信されたコマンドの内容に応じて適宜所要の処理を実行する。
【００６０】
ＣＤ９１の再生時には、ＣＤ９１に記録されている管理情報、即ちＴＯＣを読み出す必要がある。システムコントローラ５０はこの管理情報に応じてＣＤ９１に収録されたトラック数、各トラックのアドレスなどを判別し、再生動作制御を行うことになる。このためシステムコントローラ５０はＣＤ９１が装填された際にＴＯＣが記録されたディスクの最内周側（リードインエリア）の再生動作を実行させることによって読み出し、前述のようにしてＴＯＣ情報を抽出する。そして、このＴＯＣを例えばワークＲＡＭ５２に記憶させておき、以後そのＣＤ９１に対する再生動作の際に参照できるようにしている。
【００６１】
システムコントローラ５０は、ＣＰＵ、内部インターフェース部等を備えたマイクロコンピュータとされ、上述してきた各種動作の制御を行う。
また、プログラムＲＯＭ２８には、このＳＴＲ対応ＣＤ機３０における各種動作を実現するためのプログラム等が格納され、ワークＲＡＭ２９には、システムコントローラ１１が各種処理を実行するのに必要なデータやプログラム等が適宜保持される。
【００６２】
ところで周知のように、ＣＤの規格として、サブコードにはテキストデータを挿入することが可能とされ、例えばディスクタイトルやトラックネームなどに利用することができるようにされている。
そして、本実施の形態のＳＴＲ対応ＣＤ機３０は、このＣＤのテキストデータに対応している。つまり、ＣＤのサブコード内のテキストデータに基づいての文字表示を表示部４７に対して行うことができる。
このために、本実施の形態のＳＴＲ対応ＣＤ機３０にはＣＤテキストデコーダ４５及びＣＤテキストメモリ４６が備えられる。
例えばサブコードプロセッサ４４にて得られたサブコードデータは、ＣＤテキストデコーダ４５に対して入力されるようにもなっている。そして、ＣＤテキストデコーダ４５においては、入力されたサブコードデータにＣＤテキストデータが挿入されているのであればデコード処理を施してテキストデータを得るようにされる。このようにして得られたテキストデータは、システムコントローラ５０の制御によってＣＤテキストメモリ４６に対して記憶される。
以降、システムコントローラ５０は、必要に応じてＣＤテキストメモリ４６からテキストデータの読み出しを行い、表示部４７のＦＬ管表示部にて、そのテキストデータが文字として表示されるように制御処理を実行する。
【００６３】
操作部４８は、本体フロントパネルに設けられている各種キーより成るものとされる。なお、ここでは図示していないが、操作部４８としては、例えば赤外線リモートコマンダーによる遠隔操作機能が付加されてもよい。
【００６４】
また表示部４７ではＣＤ９１の再生時などに所要の表示動作が行なわれる。例えば総演奏時間、再生や録音時の進行時間などの時間情報や、トラックナンバ、ＣＤのディスクネームやトラックネームなどのネーム情報、動作状態、動作モードなどの各種の表示がシステムコントローラ５０の制御に基づいて行なわれる。
この表示部４７も、前述したように、ＦＬ管表示部とセグメント表示部とを備える。
【００６５】
１−７．ＭＤ機（内部）
図７のブロック図は、ＭＤレコーダ／プレーヤであるＳＴＲ対応ＭＤ機１の内部構成を示している。
オーディオデータが記録再生される光磁気ディスク（ミニディスク）９０は、スピンドルモータ２により回転駆動される。そして光磁気ディスク９０に対しては記録／再生時に光学ヘッド３によってレーザ光が照射される。
【００６６】
光学ヘッド３は、記録時には記録トラックをキュリー温度まで加熱するための高レベルのレーザ出力を行ない、また再生時には磁気カー効果により反射光からデータを検出するための比較的低レベルのレーザ出力を行なう。
このため、光学ヘッド３にはレーザ出力手段としてのレーザダイオード、偏光ビームスプリッタや対物レンズ等からなる光学系、及び反射光を検出するためのディテクタ等が搭載されている。対物レンズ３ａは２軸機構４によってディスク半径方向及びディスクに接離する方向に変位可能に保持されている。
【００６７】
また、ディスク９０を挟んで光学ヘッド３と対向する位置に磁気ヘッド６ａが配置されている。磁気ヘッド６ａは供給されたデータによって変調された磁界を光磁気ディスク９０に印加する動作を行なう。
光学ヘッド３全体及び磁気ヘッド６ａは、スレッド機構５によりディスク半径方向に移動可能とされている。
【００６８】
再生動作によって、光学ヘッド３によりディスク９０から検出された情報はＲＦアンプ７に供給される。ＲＦアンプ７は供給された情報の演算処理により、再生ＲＦ信号、トラッキングエラー信号ＴＥ、フォーカスエラー信号ＦＥ、グルーブ情報（光磁気ディスク９０にプリグルーブ（ウォブリンググルーブ）として記録されている絶対位置情報）ＧＦＭ等を抽出する。
抽出された再生ＲＦ信号はエンコーダ／デコーダ部８に供給される。また、トラッキングエラー信号ＴＥ、フォーカスエラー信号ＦＥはサーボ回路９に供給され、グルーブ情報ＧＦＭはアドレスデコーダ１０に供給される。
【００６９】
サーボ回路９は供給されたトラッキングエラー信号ＴＥ、フォーカスエラー信号ＦＥや、マイクロコンピュータにより構成されるシステムコントローラ１１からのトラックジャンプ指令、アクセス指令、スピンドルモータ２の回転速度検出情報等により各種サーボ駆動信号を発生させ、２軸機構４及びスレッド機構５を制御してフォーカス及びトラッキング制御を行ない、またスピンドルモータ２を一定線速度（ＣＬＶ）に制御する。
【００７０】
アドレスデコーダ１０は供給されたグルーブ情報ＧＦＭをデコードしてアドレス情報を抽出する。このアドレス情報はシステムコントローラ１１に供給され、各種の制御動作に用いられる。
また再生ＲＦ信号についてはエンコーダ／デコーダ部８においてＥＦＭ復調、ＣＩＲＣ等のデコード処理が行なわれるが、このときアドレス、サブコードデータなども抽出され、システムコントローラ１１に供給される。
【００７１】
エンコーダ／デコーダ部８でＥＦＭ復調、ＣＩＲＣ等のデコード処理されたオーディオデータ（セクターデータ）は、メモリコントローラ１２によって一旦バッファメモリ１３に書き込まれる。なお、光学ヘッド３によるディスク９０からのデータの読み取り及び光学ヘッド３からバッファメモリ１３までの系における再生データの転送は1.41Mbit/secで、しかも通常は間欠的に行なわれる。
【００７２】
バッファメモリ１３に書き込まれたデータは、再生データの転送が0.3Mbit/sec となるタイミングで読み出され、エンコーダ／デコーダ部１４に供給される。そして、音声圧縮処理に対するデコード処理等の再生信号処理を施され、４４．１ＫＨZ サンプリング、１６ビット量子化のデジタルオーディオ信号とされる。このデジタルオーディオ信号はＤ／Ａ変換器１５によってアナログ信号とされ、出力処理部１６でレベル調整、インピーダンス調整等が行われてライン出力端子１７からアナログオーディオ信号Ａｏｕｔとして外部機器に対して出力される。またヘッドホン出力ＨＰｏｕｔとしてヘッドホン出力端子２７に供給され、接続されるヘッドホンに出力される。
【００７３】
また、エンコーダ／デコーダ部１４でデコードされた状態のデジタルオーディオ信号は、デジタルインターフェース部２２に供給されることで、デジタル出力端子２１からデジタルオーディオデータＤｏｕｔとして外部機器に出力することもできる。例えば光ケーブルによる伝送形態で外部機器に出力される。
【００７４】
光磁気ディスク９０に対して記録動作が実行される際には、ライン入力端子１８に供給されるアナログオーディオ信号Ａｉｎは、Ａ／Ｄ変換器１９によってデジタルオーディオデータに変換された後、エンコーダ／デコーダ部１４に供給され、音声圧縮エンコード処理を施される。
または外部機器からデジタル入力端子２０にデジタルオーディオデータＤｉｎが供給された場合は、デジタルインターフェース部２２で制御コード等の抽出が行われるとともに、そのデジタルオーディオデータがエンコーダ／デコーダ部１４に供給され、音声圧縮エンコード処理を施される。
なお図示していないがマイクロホン入力端子を設け、マイクロホン入力を記録信号として用いることも当然可能である。
【００７５】
エンコーダ／デコーダ部１４によって圧縮された記録データはメモリコントローラ１２によって一旦バッファメモリ１３に書き込まれて蓄積されていった後、所定量のデータ単位毎に読み出されてエンコーダ／デコーダ部８に送られる。そしてエンコーダ／デコーダ部８でＣＩＲＣエンコード、ＥＦＭ変調等のエンコード処理された後、磁気ヘッド駆動回路６に供給される。
【００７６】
磁気ヘッド駆動回路６はエンコード処理された記録データに応じて、磁気ヘッド６ａに磁気ヘッド駆動信号を供給する。つまり、光磁気ディスク９０に対して磁気ヘッド６ａによるＮ又はＳの磁界印加を実行させる。また、このときシステムコントローラ１１は光学ヘッドに対して、記録レベルのレーザ光を出力するように制御信号を供給する。
【００７７】
この操作部２３もまた、例えば本体フロントパネルに設けられた各種キーより成るものとされる。この操作部２３に対して行われた操作により出力される操作情報はシステムコントローラ１１に入力され、システムコントローラ１１は操作情報に応じた動作制御を実行することになる。
【００７８】
なお、周知のようにＭＤに対応する記録再生装置では、トラック（プログラム）分割、トラック連結、トラック消去、トラックネーム入力、ディスクネーム入力などのプログラム編集を行うことができるようになっているが、これらの操作は比較的煩雑でもあるため、例えば図示しないリモートコントローラから送信される操作コマンド信号を受信可能な構成を設けるようにすることが実際としては好ましく、このようにすれば、上記したような各種プログラム編集に関する操作をリモートコントローラに設けられているキーに対する操作によって行うようにすることが可能になる。
【００７９】
表示部２４の表示動作はシステムコントローラ１１によって制御される。
即ちシステムコントローラ１１は表示動作を実行させる際に表示すべきデータを表示部２４内の表示ドライバに送信する。表示ドライバは供給されたデータに基づいて液晶パネルなどによるディスプレイの表示動作を駆動し、所要の数字、文字、記号などの表示を実行させる。
表示部２４においては、記録／再生しているディスクの動作モード状態、トラックナンバ、記録時間／再生時間、編集動作状態等が示される。
またディスク９０には主データたるプログラムに付随して管理される文字情報（トラックネーム等）が記録できるが、その文字情報の入力の際の入力文字の表示や、ディスクから読み出した文字情報の表示などが実行される。
さらに本実施の形態の場合、ディスク９０には、プログラムとしての楽曲等のデータとは独立したデータファイルとなる副データ（ＡＵＸデータ）を記録することも可能とされる。
ＡＵＸデータとしてのデータファイルは、文字、静止画などの情報となるが、これらの文字や静止画は表示部２４により表示出力可能とされる。
【００８０】
本実施の形態では、ＡＵＸデータである静止画及び文字を表示部２４に表示させるための構成として、ＪＰＥＧデコーダ２６が備えられる。
即ち、本実施の形態においては、ＡＵＸデータとしてのデータファイルである静止画データは、ＪＰＥＧ(Joint Photographic Coding Experts Group)方式により圧縮されたファイル形式で記録される。ＪＰＥＧデコーダ２６では、ディスク９０にて再生されて例えばバッファメモリ１３に蓄積された静止画データのファイルをメモリコントローラ１２を介して入力し、ＪＰＥＧ方式に従った伸張処理を施して表示部２４に出力する。これにより、ＡＵＸデータである静止画データが表示部２４にて表示されることになる。
なお、この場合の表示部２４としても、先に述べたように、ＦＬ管表示部とセグメント表示部を備えて成るものである。
【００８１】
システムコントローラ１１は、ＣＰＵ、内部インターフェース部等を備えたマイクロコンピュータとされ、上述してきた各種動作の制御を行う。
また、プログラムＲＯＭ２８には、当該記録再生装置における各種動作を実現するためのプログラム等が格納され、ワークＲＡＭ２９には、システムコントローラ１１が各種処理を実行するのに必要なデータやプログラム等が適宜保持される。
【００８２】
ところで、ディスク９０に対して記録／再生動作を行なう際には、ディスク９０に記録されている管理情報、即ちＰ−ＴＯＣ（プリマスタードＴＯＣ）、Ｕ−ＴＯＣ（ユーザーＴＯＣ）を読み出す必要がある。システムコントローラ１１はこれらの管理情報に応じてディスク９０上の記録すべきエリアのアドレスや、再生すべきエリアのアドレスを判別することとなる。
この管理情報はバッファメモリ１３に保持される。
そして、システムコントローラ１１はこれらの管理情報を、ディスク９０が装填された際に管理情報の記録されたディスクの最内周側の再生動作を実行させることによって読み出し、バッファメモリ１３に記憶しておき、以後そのディスク９０に対するプログラムの記録／再生／編集動作の際に参照できるようにしている。
【００８３】
また、Ｕ−ＴＯＣはプログラムデータの記録や各種編集処理に応じて書き換えられるものであるが、システムコントローラ１１は記録／編集動作のたびに、Ｕ−ＴＯＣ更新処理をバッファメモリ１３に記憶されたＵ−ＴＯＣ情報に対して行ない、その書換動作に応じて所定のタイミングでディスク９０のＵ−ＴＯＣエリアについても書き換えるようにしている。
【００８４】
またディスク９０にはプログラムとは別にＡＵＸデータファイルが記録されるが、そのＡＵＸデータファイルの管理のためにディスク９０上にはＡＵＸ−ＴＯＣが形成される。
システムコントローラ１１はＵ−ＴＯＣの読出の際にＡＵＸ−ＴＯＣの読出も行い、バッファメモリ１３に格納して必要時にＡＵＸデータの管理状態を参照できるようにしている。
またシステムコントローラ１１は必要に応じて所定タイミングで（もしくはＡＵＸ−ＴＯＣの読出の際に同時に）ＡＵＸデータファイルを読み込み、バッファメモリ１３に格納する。そしてＡＵＸ−ＴＯＣで管理される出力タイミングに応じて表示部２４や、ＩＥＥＥ１３９４インターフェイス２５を介した外部機器における文字や画像の出力動作を実行させる。
【００８５】
ＩＥＥＥ１３９４インターフェイス２５によっては、オーディオデータの送受信が可能とされている。つまり、本実施の形態のＭＤレコーダ／プレーヤにあっては、ＩＥＥＥ１３９４バス１１６を介して送信されてきたオーディオデータをＩＥＥＥ１３９４インターフェイス２５により受信し、この受信したオーディオデータをディスク９０に対して記録することができるようになっている。
ここで、送信されてきたオーディオデータが例えば、サンプリング周波数４４．１ＫＨｚ、量子化ビット１６ビットのフォーマットであれば、システムコントローラ１１を介するようにして、エンコーダ／デコーダ部１４に転送して、データ圧縮処理を施すようにされる。
これに対して、送信されてきたオーディオデータが、当該ＭＤレコーダ／プレーヤに適合した方式によって圧縮処理された圧縮オーディオデータであるとすれば、システムコントローラ１１を介するようにして、メモリコントローラ１２に転送するようにされる。なお、当然のこととして、このＩＥＥＥ１３９４インターフェイス２５によってもコマンドの送受信が可能とされ、例えばシステムコントローラ１１は、受信したコマンドの内容に応じて所要の処理を実行する。
【００８６】
２．ＩＥＥＥ１３９４による本実施の形態のデータ通信
２−１．概要
以降、本実施の形態としてのＩＥＥＥ１３９４規格に従ったデータ通信について説明する。
【００８７】
ＩＥＥＥ１３９４は、シリアルデータ通信の規格の１つとされる。
このＩＥＥＥ１３９４によるデータ伝送方式としては、周期的に通信を行うＩｓｏｃｈｒｏｎｏｕｓ通信方式と、この周期と関係なく非同期で通信するＡｓｙｎｃｈｒｏｎｏｕｓ通信方式が存在する。一般に、Ｉｓｏｃｈｒｏｎｏｕｓ通信方式はデータの送受信に用いられ、Ａｓｙｎｃｈｒｏｎｏｕｓ通信方式は各種制御コマンドの送受信に用いられる。そして、１本のケーブルを使用して、これら２種類の通信方式によって送受信を行うことが出来るようにされている。
そこで以降、上記したＩＥＥＥ１３９４規格による本実施の形態の送信形態を前提として、本実施の形態としての説明を行っていくこととする。
【００８８】
２−２．スタックモデル
図８は、本実施の形態が対応するＩＥＥＥ１３９４のスタックモデルを示している。
ＩＥＥＥ１３９４フォーマットにおいては、Ａｓｙｎｃｈｒｏｎｏｕｓ系（４００）とＩｓｏｃｈｒｏｎｏｕｓ系（５００）とに大別される。
ここで、Ａｓｙｎｃｈｒｏｎｏｕｓ系（４００）とＩｓｏｃｈｒｏｎｏｕｓ系（５００）に共通な層として、最下位にＰｈｙｓｉｃａｌ Ｌａｙｅｒ（３０１）（物理層）が設けられ、その上位にＬｉｎｋ Ｌａｙｅｒ（３０２）（リンク層）が設けられる。Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ（３０１）はハードウェア的な信号伝送を司るためのレイヤであり、Ｌｉｎｋ Ｌａｙｅｒ（３０２）はＩＥＥＥ１３９４バスを例えば、機器毎に規定された内部バスに変換するための機能を有する層とされる。
【００８９】
Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ（３０１）、Ｌｉｎｋ Ｌａｙｅｒ（３０２）、及び次に説明するＴｒａｎｓａｃｔｉｏｎ Ｌａｙｅｒ（４０１）は、Ｅｖｅｎｔ／Ｃｏｎｔｒｏｌ／ＣｏｎｆｉｇｕｒａｔｉｏｎのラインによってＳｅｒｉａｌ Ｂｕｓ Ｍａｎａｇｅｍｅｎｔ３０３とリンクされる。
また、ＡＶ Ｃａｂｌｅ／Ｃｏｎｎｅｃｔｏｒ３０４は、ＡＶデータ伝送のための物理的なコネクタ、ケーブルを示している。
【００９０】
Ａｓｙｎｃｈｒｏｎｏｕｓ系（４００）における上記Ｌｉｎｋ Ｌａｙｅｒ（３０２）の上位には、Ｔｒａｎｓａｃｔｉｏｎ Ｌａｙｅｒ（４０１）が設けられる。Ｔｒａｎｓａｃｔｉｏｎ Ｌａｙｅｒ（４０１）は、ＩＥＥＥ１３９４としてのデータ伝送プロトコルを規定する層とされ、基本的なＡｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓａｃｔｉｏｎとしては、後述するようにして、Ｗｒｉｔｅ Ｔｒａｎｓａｃｔｉｏｎ，Ｒｅａｄ Ｔｒａｎｓａｃｔｉｏｎ，Ｌｏｃｋ Ｔｒａｎｓａｃｔｉｏｎが規定される。
【００９１】
そして、Ｔｒａｎｓａｃｔｉｏｎ Ｌａｙｅｒ（４０１）の上層に対してＦＣＰ(Function Control Protocol)（４０２）が規定される。ＦＣＰ（４０２）は、ＡＶ／Ｃ Ｃｏｍｍａｎｄ(AV/C Digital Interface 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 Contorol Register)によって確立される。
図１８（ａ）は、ｏＰＣＲ［ｎ］（出力用プラグコントロールレジスタ）の構造を示し、図１８（ｂ）は、ｉＰＣＲ［ｎ］（入力用プラグコントロールレジスタ）の構造を示している。これらｏＰＣＲ［ｎ］、ｉＰＣＲ［ｎ］のサイズは共に３２ビットとされている。
図１８（ａ）のｏＰＣＲにおいては、例えば上位１ビットのｏｎ−ｌｉｎｅに対して‘１’が格納されていると、ｂｒｏａｄｃａｓｔ ｃｏｎｎｅｃｔｉｏｎによる送信であることが示され、‘０’が格納されていると、上位１１ビット目から６ビットの領域のｃｈａｎｎｅｌ ｎｕｍｂｅｒで示されるチャンネルにより、ｐｏｉｎｔ ｔｏ ｐｏｉｎｔ ｃｏｎｎｅｃｔｉｏｎで送信することが示される。
また、図１８（ｂ）のｉＰＣＲにおいても、例えば上位１ビットのｏｎ−ｌｉｎｅに対して‘１’が格納されていれば、ｂｒｏａｄｃａｓｔ ｃｏｎｎｅｃｔｉｏｎによる受信であることが示され、‘０’が格納されていると、上位１１ビット目から６ビットの領域のｃｈａｎｎｅｌ ｎｕｍｂｅｒで示されるチャンネルにより送信されたデータをｐｏｉｎｔ ｔｏ ｐｏｉｎｔ ｃｏｎｎｅｃｔｉｏｎで送信することが示される。
【０１３０】
そして、図１８（ａ）のｏＰＣＲ、及び図１８（ｂ）のｉＰＣＲにおけるｂｒｏａｄｃａｓｔ ｃｏｎｎｅｃｔｉｏｎ ｃｏｕｎｔｅｒには、ｂｒｏａｄｃａｓｔ ｃｏｎｎｅｃｔｉｏｎによる送信／受信とされる場合において、ｂｒｏａｄｃａｓｔ ｃｏｎｎｅｃｔｉｏｎを張っているノード数が格納される。
また、図１８（ａ）のｏＰＣＲ、及び図１８（ｂ）のｉＰＣＲにおけるｐｏｉｎｔ ｔｏ ｐｏｉｎｔ ｃｏｎｎｅｃｔｉｏｎ ｃｏｕｎｔｅｒには、ｐｏｉｎｔ ｔｏ ｐｏｉｎｔ ｃｏｎｎｅｃｔｉｏｎによる送信／受信とされる場合において、ｐｏｉｎｔ ｔｏ ｐｏｉｎｔを張っているノード数が示される。
【０１３１】
２−１０．ＦＣＰにおけるコマンド及びレスポンス
Ａｓｙｎｃｈｒｏｎｏｕｓ通信によるデータの伝送は、図８に示したＦＣＰ（４０２）によって規定されることになる。そこで、ここでは、ＦＣＰにより規定されるトランザクションについて説明する。
【０１３２】
ＦＣＰとしては、Ａｓｙｎｃｈｒｏｎｏｕｓ通信において規定されるＷｒｉｔｅ Ｔｒａｎｓａｃｔｉｏｎ（図１４参照）を使用する。従って、本実施の形態におけるＡＵＸデータの伝送も、このＦＣＰにより、Ａｓｙｎｃｈｒｏｎｏｕｓ通信の中のＷｒｉｔｅ Ｔｒａｎｓａｃｔｉｏｎを使用することで行われるものである。
ＦＣＰをサポートする機器は、Ｃｏｍｍａｎｄ／Ｒｅｓｐｏｎｃｅレジスタを備え、次に図１９により説明するようにしてＣｏｍｍａｎｄ／Ｒｅｓｐｏｎｃｅレジスタに対してＭｅｓｓａｇｅを書き込むことでトランザクションを実現する。
【０１３３】
図１９の処理遷移図においては、先ずＣＯＭＭＡＮＤ送信のための処理として、ステップＳ２１として示すように、ＣｏｎｔｒｏｌｌｅｒがＴｒａｎｓａｃｔｉｏｎ Ｒｅｑｕｅｓｔを発生して、Ｗｒｉｔｅ Ｒｅｑｕｅｓｔ ＰａｃｋｅｔをＴａｒｇｅｔに対して送信する処理を実行する。Ｔａｒｇｅｔでは、ステップＳ２２として、このＷｒｉｔｅ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔを受信して、Ｃｏｍｍａｎｄ／Ｒｅｓｐｏｎｃｅレジスタに対してデータの書き込みを行う。また、この際、ＴａｒｇｅｔからはＣｏｎｔｒｏｌｌｅｒに対してＡｃｋｎｏｗｌｅｄｇを送信し、Ｃｏｎｔｒｏｌｌｅｒでは、このＡｃｋｎｏｗｌｅｄｇを受信する（Ｓ２３→Ｓ２４）。ここまでの一連の処理が、ＣＯＭＭＡＮＤの送信に対応する処理となる。
【０１３４】
続いては、ＣＯＭＭＡＮＤに応答した、ＲＥＳＰＯＮＳＥのための処理として、ＴａｒｇｅｔからＷｒｉｔｅ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔが送信される（Ｓ２５）。Ｃｏｎｔｒｏｌｌｅｒではこれを受信して、Ｃｏｍｍａｎｄ／Ｒｅｓｐｏｎｃｅレジスタに対してデータの書き込みを行う（Ｓ２６）。また、Ｃｏｎｔｒｏｌｌｅｒでは、Ｗｒｉｔｅ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔの受信に応じて、Ｔａｒｇｅｔに対してＡｃｋｎｏｗｌｅｄｇを送信する（Ｓ２７）。Ｔａｒｇｅｔでは、このＡｃｋｎｏｗｌｅｄｇを受信することで、Ｗｒｉｔｅ Ｒｅｑｕｅｓｔ ＰａｃｋｅｔがＣｏｎｔｒｏｌｌｅｒにて受信されたことを知る（Ｓ２８）。
つまり、ＣｏｎｔｒｏｌｌｅｒからＴａｒｇｅｔ対するＣＯＭＭＡＮＤ伝送処理と、これに応答したＴａｒｇｅｔからＣｏｎｔｒｏｌｌｅｒに対するＲＥＳＰＯＮＳＥ伝送処理が、ＦＣＰによるデータ伝送（Ｔｒａｎｓａｃｔｉｏｎ）の基本となる。
【０１３５】
２−１１．ＡＶ／Ｃコマンドパケット
図８により説明したように、Ａｓｙｎｃｈｒｏｎｏｕｓ通信において、ＦＣＰは、ＡＶ／Ｃコマンドを用いて各種ＡＶ機器に対する通信を行うことができるようにされている。
Ａｓｙｎｃｈｒｏｎｏｕｓ通信では、Ｗｒｉｔｅ，Ｒｅａｄ，Ｌｏｃｋの３種のトランザクションが規定されているのは、図１４にて説明した通りであり、実際には各トランザクションに応じたＷｒｉｔｅ Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｃｅ Ｐａｃｋｅｔ，Ｒｅａｄ Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｃｅ Ｐａｃｋｅｔ，Ｌｏｃｋ Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｃｅ Ｐａｃｋｅｔが用いられる。そして、ＦＣＰでは、上述したようにＷｒｉｔｅ Ｔｒａｎｓａｃｔｉｏｎを使用するものである。
そこで図２０に、Ｗｒｉｔｅ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔ（Asynchronous Packet（Write Request for Data Block)）のフォーマットを示す。本実施の形態では、このＷｒｉｔｅ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔが即ち、ＡＶ／Ｃコマンドパケットして使用される。
【０１３６】
このＷｒｉｔｅ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔにおける上位５ｑｕａｄｌｅｔ（第１〜第５ｑｕａｄｌｅｔ）は、ｐａｃｋｅｔ ｈｅａｄｅｒとされる。
ｐａｃｋｅｔ ｈｅａｄｅｒの第１ｑｕａｄｌｅｔにおける上位１６ビットの領域はｄｅｓｔｉｎａｔｉｏｎ＿ＩＤで、データの転送先（宛先）のＮｏｄｅ ＩＤを示す。続く６ビットの領域はｔｌ(transact label)であり、パケット番号を示す。続く２ビットはｒｔ(retry code)であり、当該パケットが初めて伝送されたパケットであるか、再送されたパケット示す。続く４ビットの領域はｔｃｏｄｅ(transaction code)は、指令コードを示している。そして、続く４ビットの領域はｐｒｉ(priority)であり、パケットの優先順位を示す。
【０１３７】
第２ｑｕａｄｌｅｔにおける上位１６ビットの領域はｓｏｕｒｃｅ＿ＩＤであり、データの転送元のＮｏｄｅ＿ＩＤ が示される。
また、第２ｑｕａｄｌｅｔにおける下位１６ビットと第３ｑｕａｄｌｅｔ全体の計４８ビットはｄｅｓｔｉｎａｔｉｏｎ＿ｏｆｆｓｅｔとされ、ＣＯＭＭＡＮＤレジスタ（ＦＣＰ＿ＣＯＭＭＡＮＤ ｒｅｇｉｓｔｅｒ）とＲＥＳＰＯＮＳＥレジスタ（ＦＣＰ＿ＲＥＳＰＯＮＳＥ ｒｅｇｉｓｔｅｒ）のアドレスが示されれる。
上記ｄｅｓｔｉｎａｔｉｏｎ＿ＩＤ及びｄｅｓｔｉｎａｔｉｏｎ＿ｏｆｆｓｅｔが、ＩＥＥＥ１３９４フォーマットにおいて規定される６４ビットのアドレス空間に相当する。
【０１３８】
第４ｑｕａｄｌｅｔの上位１６ビットの領域は、ｄａｔａ＿ｌｅｎｇｔｈとされ、後述するｄａｔａｆｉｅｌｄ（図２０において太線により囲まれる領域）のデータサイズが示される。
続く下位１６ビットの領域は、ｅｘｔｅｎｄｅｄ＿ｔｃｏｄｅの領域とされ、ｔｃｏｄｅを拡張する場合に使用される領域である。
【０１３９】
第５ｑｕａｄｌｅｔとしての３２ビットの領域は、ｈｅａｄｅｒ＿ＣＲＣであり、Ｐａｃｋｅｔ ｈｅａｄｅｒのチェックサムを行うＣＲＣ計算値が格納される。
【０１４０】
Ｐａｃｋｅｔ ｈｅａｄｅｒに続く第６ｑｕａｄｌｅｔからｄａｔａ ｂｌｏｃｋが配置され、このｄａｔａ ｂｌｏｃｋ内の先頭に対してｄａｔａｆｉｅｌｄが形成される。
ｄａｔａｆｉｅｌｄとして先頭となる第６ｑｕａｄｌｅｔの上位４バイトには、ＣＴＳ(Command and Transaction Set)が記述される。これは、当該Ｗｒｉｔｅ Ｒｅｑｕｅｓｔ ＰａｃｋｅｔのコマンドセットのＩＤを示すもので、例えば、このＣＴＳの値について、図のように［００００］と設定すれば、ｄａｔａｆｉｅｌｄに記述されている内容がＡＶ／Ｃコマンドであると定義されることになる。つまり、このＷｒｉｔｅ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔは、ＡＶ／Ｃコマンドパケットであることが示されるものである。従って、本実施の形態においては、ＦＣＰがＡＶ／Ｃコマンドを使用するため、このＣＴＳには［００００］が記述されることになる。
【０１４１】
ＣＴＳに続く４ビットの領域は、ｃｔｙｐｅ(Command type；コマンドの機能分類)、又はコマンドに応じた処理結果(レスポンス)を示すｒｅｓｐｏｎｓｅが記述される。
【０１４２】
図２１に、上記ｃｔｙｐｅ及びｒｅｓｐｏｎｓｅの定義内容を示す。
ｃｔｙｐｅ（Ｃｏｍｍａｎｄ）としては、［００００］〜［０１１１］を使用できるものとしており、［００００］はＣＯＮＴＲＯＬ、［０００１］はＳＴＡＴＵＳ、［００１０］はＩＮＱＵＩＲＹ、［００１１］はＮＯＴＩＦＹとして定義され、［０１００］〜０１１１は、現状、未定義（ｒｅｓｅｒｖｅｄ）とされている。
ＣＯＮＴＲＯＬは機能を外部から制御するコマンドであり、ＳＴＡＴＵＳは外部から状態を間い合わせるコマンド、ＩＮＱＵＩＲＹは、制御コマンドのサポートの有無を外部から問い合わせるコマンド、ＮＯＴＩＦＹは状態の変化を外部に知らせることを要求するコマンドである。
また、ｒｅｓｐｏｎｓｅとしては、［１０００］〜［１１１１］を使用するものとしており、［１０００］はＮＯＴ ＩＭＰＬＥＭＥＮＴＥＤ、［１００１］はＡＣＣＥＰＴＥＤ、［１０１０］はＲＥＪＥＣＴＥＤ、［１０１１］はＩＮ ＴＲＡＮＳＩＴＩＯＮ、［１１００］はＩＭＰＬＥＭＥＮＴＥＤ／ＳＴＡＢＬＥ、［１１０１］はＣＨＡＮＧＥＤ、［１１１０］はｒｅｓｅｒｖｅｄ、［１１１１］はＩＮＴＥＲＩＭとしてそれぞれ定義されている。
これらのｒｅｓｐｏｎｓｅは、コマンドの種類に応じて使い分けられる。例えば、ＣＯＮＴＯＲＯＬのコマンドに対応するｒｅｓｐｏｎｓｅとしては、ＮＯＴＩＭＰＬＥＭＥＮＴＥＤ、ＡＣＣＥＰＴＥＤ、ＲＥＪＥＣＴＥＤ、或いはＩＮＴＥＲＩＭの4つのうちの何れかがＲｅｓｐｏｎｄｅｒ側の状況等に応じて使い分けられる。
【０１４３】
図２０において、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅに続く５ビットの領域には、ｓｕｂｕｎｉｔ−ｔｙｐｅが格納される。は、ｓｕｂｕｎｉｔ−ｔｙｐｅは、ＣＯＭＭＭＡＮＤの宛先またはＲＥＳＰＯＮＳＥの送信元のｓｕｂｕｎｉｔが何であるのか（機器）を示す。ＩＥＥＥ１３９４フォーマットでは、機器そのものをｕｎｉｔと称し、そのｕｎｉｔ（機器）内において備えられる機能的機器単位の種類をｓｕｂｕｎｉｔと称する。例えば一般のＶＴＲを例に採れば、ＶＴＲとしてのｕｎｉｔは、地上波や衛星放送を受信するチューナと、ビデオカセットレコーダ／プレーヤとの、２つのｓｕｂｕｎｉｔを備える。
ｓｕｂｕｎｉｔ−ｔｙｐｅとしては、例えば図２２（ａ）に示すように定義されている。つまり、［０００００］はＭｏｎｉｔｏｒ、［００００１］〜［０００１０］はｒｅｓｅｒｖｅｄ、［０００１１］はＤｉｓｃ ｒｅｃｏｒｄｅｒ／ｐｌａｙｅｒ、［００１００］はＶＣＲ、［００１０１］はＴｕｎｅｒ、［００１１１］はＣａｍｅｒａ、［０１０００］〜［１１１１０］はｒｅｓｅｒｖｅｄ、［１１１１１］は、ｓｕｂｕｎｉｔが存在しない場合に用いられるｕｎｉｔとして定義されている。
【０１４４】
図２０において、上記ｓｕｂｕｎｉｔ−ｔｙｐｅに続く３ビットには、同―種類のｓｕｂｕｎｉｔが複数存在する場合に、各ｓｕｂｕｎｉｔを特定するためのｉｄ（Ｎｏｄｅ＿ＩＤ）が格納される。
【０１４５】
上記ｉｄ（Ｎｏｄｅ＿ＩＤ）に続く８ビットの領域には、ｏｐｃｏｄｅが格納され、続く８ビットの領域には、ｏｐｅｒａｎｄが格納される。
ｏｐｃｏｄｅとは、オぺレーションコード(Operation Code)のことであって、ｏｐｅｒａｎｄには、ｏｐｃｏｄｅが必要とする情報（パラメータ）が格納される。これらｏｐｃｏｄｅはｓｕｂｕｎｉｔごとに定義され、ｓｕｂｕｎｉｔごとに固有のｏｐｃｏｄｅのリストのテーブルを有する。例えば、ｓｕｂｕｎｉｔがＶＣＲであれば、ｏｐｃｏｄｅとしては、例えば図２２（ｂ）に示すようにして、ＰＬＡＹ（再生），ＲＥＣＯＲＤ（記録）などをはじめとする各種コマンドが定義されている。ｏｐｅｒａｎｄは、ｏｐｃｏｄｅ毎に定義される。
【０１４６】
図２０におけるｄａｔａｆｉｅｌｄとしては、上記第６ｑｕａｄｌｅｔの３２ビットが必須とされるが、必要が有れば、これに続けて、ｏｐｅｒａｎｄを追加することが出来る（Ａｄｄｉｔｉｏｎａｌ ｏｐｅｒａｎｄｓ）。
ｄａｔａｆｉｅｌｄに続けては、ｄａｔａ＿ＣＲＣが配置される。なお、必要が有れば、ｄａｔａ＿ＣＲＣの前にｐａｄｄｉｎｇを配置することが可能である。
【０１４７】
２−１２．プラグ
ここで、ＩＥＥＥ１３９４フォーマットにおけるプラグについて概略的に説明する。ここでいうプラグとは、先に図１８によっても説明したように、ＩＥＥＥ１３９４フォーマットにおける機器間の論理的接続関係をいうものである。
【０１４８】
図２３に示すように、Ａｓｙｎｃｈｒｏｎｏｕｓ通信において有効とされるコマンド等のデータ（ｒｅｑｕｅｓｔ）は、ｐｒｏｄｕｃｅｒからｃｏｎｓｕｍｅｒに対して伝送される。ここでいうｐｒｏｄｕｃｅｒ及びｃｏｎｓｕｍｅｒは、それぞれＩＥＥＥ１３９４インターフェイス上で送信機器、受信機器として機能する機器をいうものである。そして、ｃｏｎｓｕｍｅｒにおいては、図に斜線で示すように、ｐｒｏｄｕｃｅｒによりデータ書き込みが行われるセグメントバッファ（Segment Buffer）を備える。
また、ＩＥＥＥ１３９４システムにおいて、特定の機器をｐｒｏｄｕｃｅｒ、ｃｏｎｓｕｍｅｒとして規定するための情報（Connection Management Information）は、図に網線で示すプラグアドレス内の所定位置に格納されている。セグメントバッファは、プラグアドレスに続いて配置される。
ｃｏｎｓｕｍｅｒのセグメントバッファに対して書き込み可能なアドレス範囲（データ量）は、後述するようにしてｃｏｎｓｕｍｅｒ側で管理するｌｉｍｉｔＣｏｕｎｔ ｒｅｇｉｓｔｅｒによって規定される。
【０１４９】
図２４は、Ａｓｙｎｃｈｒｏｎｏｕｓ通信におけるプラグのアドレス空間の構造を示している。
６４ビットから成るプラグのアドレス空間は、図２４（ａ）に示すようにして、２の１６乗（６４Ｋ）のＮｏｄｅに分割される。そして、プラグは、図２４（ｂ）に示すようにして、各Ｎｏｄｅのアドレス空間内に在るようにされる。そして、各プラグは、図２４（ｃ）に示すように、網線の領域により示すレジスタ（ｒｅｇｉｓｔｅｒ）と、斜線の領域により示すセグメントバッファ(Segment Buffer)とを含んで形成される。レジスタには、次に説明するようにして、送信側（ｐｒｏｄｕｃｅｒ）と受信側（ｃｏｎｓｕｍｅｒ）との間におけるデータの授受管理に必要な情報（例えば、送信データサイズ及び受信可能データサイズ）が格納される。セグメントバッファは、ｐｒｏｄｕｃｅｒからｃｏｎｓｕｍｅｒに対して送信されたデータが書き込まれるべき領域であり、例えば最小で６４バイトであることが規定されている。
【０１５０】
図２５（ａ）にはプラグアドレスが示されている。つまり、上記図２４（ｃ）と同一内容が示されている。
この図に示すように、レジスタはプラグアドレスの先頭に対して配置され、これに続けてセグメントバッファが配置される。
そして、レジスタ内の構造としては、図２５（ｂ）に示すようにして、先頭に対して、例えば３２ビットのｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒが配置され、続けて、各３２ビットのｌｉｍｉｔ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒ［１］〜［１４］が配置される。つまり、１つのｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒと１４のｌｉｍｉｔ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒが設けられる。なお、ここでは、ｌｉｍｉｔ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒ［１４］の後ろに未使用（ｕｎｕｓｅｄ）の領域が設けられている。
【０１５１】
上記図２５（ａ）（ｂ）に示すプラグ構造は、図２５（ｃ）に示すようにして、オフセットアドレス(Address Offset)によって指定される。
つまり、オフセットアドレス０は、ｃｏｎｓｕｍｅｒ ｐｏｒｔ（ｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒ）を指定し、オフセットアドレス４，８，１２・・・５６，６０は、それぞれｐｒｏｄｕｃｅｒ ｐｏｒｔ［１］〜［１４］を指定する。オフセットアドレス６０はｒｅｓｅｒｖｅｄとして定義されることで、未使用（ｕｎｕｓｅｄ）の領域を示し、オフセットアドレス６４によりセグメントバッファを示す。
【０１５２】
図２６には、ｐｒｏｄｕｃｅｒ側とｃｏｎｓｕｍｅｒ側との両者のプラグ構造が示されている。
Ａｓｙｎｃｈｒｏｎｏｕｓ通信のプラグ構造においては、ｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒへの書き込み、ｌｉｍｉｔ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒへの書き込み、及びセグメントバッファへの書き込みを後述する送受信手順に従って行うことで、Ａｓｙｎｃｈｒｏｎｏｕｓ通信を実現する。これらの書き込みは、先に説明したＷｒｉｔｅ Ｔｒａｎｓａｃｔｉｏｎとしての処理である。
【０１５３】
ｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒは、ｐｒｏｄｕｃｅｒによってｃｏｎｓｕｍｅｒに対して書き込みが行われる。
ｐｒｏｄｕｃｅｒは、自身のアドレスに在るｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒにｐｒｏｄｕｃｅｒ側のデータ伝送に関する情報を書き込んだ上で、このｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒの内容を、ｃｏｎｓｕｍｅｒのｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒに対して書き込む。
ｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒは、ｐｒｏｄｕｃｅｒがｃｏｎｓｕｍｅｒのセグメントバッファに対して書き込むデータサイズとして、１回の書き込み処理によって書き込むデータサイズの情報とされる。つまり、ｐｒｏｄｕｃｅｒが、ｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒの書き込みを行うことによって、ｃｏｎｓｕｍｅｒのセグメントバッファに書き込むデータサイズを知らせる処理が行われる。
【０１５４】
これに対して、ｌｉｍｉｔ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒは、ｃｏｎｓｕｍｅｒによってｐｒｏｄｕｃｅｒに対して書き込みが行われる。
ｃｏｎｓｕｍｅｒ側では、自身のｌｉｍｉｔ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒ［１］〜［１４］のうち、ｐｒｏｄｕｃｅｒに対応して指定された１つのｌｉｍｉｔ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒ［ｎ］に対して、自身のセグメントバッファの容量（サイズ）を書き込み、このｌｉｍｉｔ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒ［ｎ］の内容を、ｌｉｍｉｔ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒ［ｎ］に対して書き込む。
【０１５５】
ｐｒｏｄｕｃｅｒ側では、上記のようにしてｌｉｍｉｔ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒ［ｎ］に書き込まれた内容に応じて、１回あたりの書き込みデータ量を決定して、例えば自身のセグメントバッファに対して書き込みを行う。そして、このセグメントバッファに書き込んだ内容を、ｃｏｎｓｕｍｅｒに対して書き込むようにされる。このセグメントバッファへの書き込みが、Ａｓｙｎｃｈｒｏｎｏｕｓ通信におけるデータ送信に相当する。
【０１５６】
２−１３．Asynchronous Connection送信手順
続いて、上記図２６により説明したプラグ（ｐｒｏｄｕｃｅｒ−ｃｏｎｓｕｍｅｒ）間の構造を前提として、図２７の処理遷移図により、Ａｓｙｎｃｈｒｏｎｏｕｓ ｃｏｎｎｅｃｔｉｏｎの基本的な送受信手順について説明する。
図２７に示す送受信処理の手順は、Ａｓｙｎｃｈｒｏｎｏｕｓ通信として、ＦＣＰによって規定された環境のもとで、ＡＶ／Ｃコマンド（Ｗｒｉｔｅ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔ）を使用して行われる。そして、本実施の形態において扱われるＡＵＸデータも、この送受信手順を使用してＩＥＥＥ１３９４システム内において送受信が行われる。但し、図２６に示す処理は、あくまでもＡｓｙｎｃｈｒｏｎｏｕｓ ｃｏｎｎｅｃｔｉｏｎとしての通信動作を示すもので、ＡＵＸデータの記録再生に対応する通信処理については後述する。
なお、Ａｓｙｎｃｈｒｏｎｏｕｓ ｃｏｎｎｅｃｔｉｏｎの実際においては、コマンド送信に応じて、図１９に示したように、Ａｃｋｎｏｗｌｅｄｇの送受信が実行されるのであるが、図２７においてはＡｃｋｎｏｗｌｅｄｇについての送受信処理の図示は省略している。
【０１５７】
また、ＩＥＥＥ１３９４インターフェイスでは、プラグ（機器）間の接続関係として、上記したｐｒｏｄｕｃｅｒ−ｃｏｎｓｕｍｅｒの関係の他に、ｃｏｎｔｒｏｌｌｅｒ−ｔａｒｇｅｔとして規定される関係が存在する。ＩＥＥＥ１３９４システム上においては、ｐｒｏｄｕｃｅｒ−ｃｏｎｓｕｍｅｒの関係が規定された機器と、ｃｏｎｔｒｏｌｌｅｒ−ｔａｒｇｅｔの関係が機器とが必ずしも一致するものではない。つまり、ｐｒｏｄｕｃｅｒとして規定された機器の他に、ｃｏｎｔｒｏｌｌｅｒの機能を有するものとして規定された機器が存在する場合がある。但し、ここでは、ｐｒｏｄｕｃｅｒ−ｃｏｎｓｕｍｅｒとしての関係と、ｃｏｎｔｒｏｌｌｅｒ−ｔａｒｇｅｔとしての関係が一致している場合を例に説明する。
【０１５８】
図２７に示す送信手順としては、先ず、ステップＳ１０１として示すように、ｐｒｏｄｕｃｅｒからｃｏｎｓｕｍｅｒに対して、Ｃｏｎｎｅｃｔ要求を送信する。このＣｏｎｎｅｃｔ要求は、ｐｒｏｄｕｃｅｒがｃｏｎｓｕｍｅｒに対して、接続要求を行うためのコマンドで、ｐｒｏｄｕｃｅｒのレジスタのアドレスをｃｏｎｓｕｍｅｒに対して伝える。
このＣｏｎｎｅｃｔ要求は、ステップＳ１０２の処理としてｃｏｎｓｕｍｅｒが受信することで、ｃｏｎｓｕｍｅｒ側では、ｐｒｏｄｕｃｅｒのレジスタのアドレスを認識する。そして、ステップＳ１０３により、ｒｅｓｐｏｎｃｅとして、ｃｏｎｓｕｍｅｒは、ｐｒｏｄｕｃｅｒに対してＣｏｎｎｅｃｔ受付を送信する。そして、ステップＳ１０４において、ｐｒｏｄｕｃｅｒがこれを受信することで、以降のデータ送受信のためのｐｒｏｄｕｃｅｒ−ｃｏｎｓｕｍｅｒ間の接続（ｃｏｎｎｅｃｔｉｏｎ）が確立される。
【０１５９】
上記のようにしてｃｏｎｎｅｃｔｉｏｎが確立されると、ステップＳ１０５により、ｃｏｎｓｕｍｅｒは、ｐｒｏｄｕｃｅｒに対してｌｉｍｉｔ Ｃｏｕｎｔｒｅｇｉｓｔｅｒ（（以降、単に「ｌｉｍｉｔ Ｃｏｕｎｔ」と略す））の書込要求を行う。ステップＳ１０６によりこれを受信したｐｒｏｄｕｃｅｒは、続くステップＳ１０７の処理によって、ｌｉｍｉｔ Ｃｏｕｎｔ書込受付を、ｃｏｎｓｕｍｅｒに対して送信する。そして、ステップＳ１０８の処理として、ｃｏｎｓｕｍｅｒがｌｉｍｉｔ Ｃｏｕｎｔ書込受付を受信する。このｌｉｍｉｔ Ｃｏｕｎｔ書込要求／書込受付の一連の処理によって、以降における、セグメントバッファへのデータ書き込みサイズ（セグメントバッファ容量）が決定される。
【０１６０】
続くステップＳ１０９においては、ｐｒｏｄｕｃｅｒからｃｏｎｓｕｍｅｒに対して、セグメントバッファ書込要求を送信する。そして、ステップＳ１１０によってセグメントバッファ書込要求が受信され、これに応答して、ステップＳ１１１の処理として、ｃｏｎｓｕｍｅｒからｐｒｏｄｕｃｅｒに対して、セグメントバッファ書込受付を送信する。ｐｒｏｄｕｃｅｒは、ステップＳ１１２により、セグメントバッファ書込受付を受信する。
このステップＳ１０９〜Ｓ１１２までの処理が実行されることで、１回のｐｒｏｄｕｃｅｒのセグメントバッファからｃｏｎｓｕｍｅｒのセグメントバッファに対してデータへの書き込み処理が完了する。
ここで、上記ステップＳ１０９〜Ｓ１１２の処理によって書き込まれるデータは、図１３に示したＡｓｙｎｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔによる１回の送信により書き込まれる。従って、Ａｓｙｎｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔにより転送されるデータサイズが、上記ｌｉｍｉｔ Ｃｏｕｎｔによって指定されたデータサイズよりも小さく、かつ、１回のＡｓｙｎｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔによる送信によっては、必要なデータ送信が完了しない場合には、セグメントバッファの容量がフルとなる範囲で、ステップＳ１０９〜Ｓ１１２の処理が繰り返されるようになっている。
【０１６１】
そして、上記したステップＳ１０９〜Ｓ１１２に示すセグメントバッファへの書き込み処理が完了すると、ステップＳ１１３の処理として示すように、ｐｒｏｄｕｃｅｒからｃｏｎｓｕｍｅｒに対して、ｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒ（以降、単にｐｒｏｄｕｃｅｒ Ｃｏｕｎｔと略す）書込要求を送信する。そしてｃｏｎｓｕｍｅｒでは、ステップＳ１１４の処理として、ｐｒｏｄｕｃｅｒ Ｃｏｕｎｔを受信して、自身のｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒに書き込みを行い、続くステップＳ１１５の処理として、ｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ書込受付をｐｒｏｄｕｃｅｒに対して送信する。ｐｒｏｄｕｃｅｒはステップＳ１１６により、このｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ書込受付を受信する。
この処理によって、先のステップＳ１０９〜Ｓ１１２の処理として、ｐｒｏｄｕｃｅｒからｃｏｎｓｕｍｅｒのセグメントバッファに対して転送したデータサイズがｃｏｎｓｕｍｅｒに対して知らされることになる。
【０１６２】
続くステップＳ１１７の処理としては、上記ステップＳ１１３〜Ｓ１１６に示したｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ書き込み処理に応答しての、ｌｉｍｉｔ Ｃｏｕｎｔ書き込みのための一連の処理が実行される。つまり、ステップＳ１１７〜Ｓ１２０に示すようにして、ｃｏｎｓｕｍｅｒからｐｒｏｄｕｃｅｒへのｌｉｍｉｔ Ｃｏｕｎｔ書込要求の送信と、この送信に応答してのｐｒｏｄｕｃｅｒからｃｏｎｓｕｍｅｒへのｌｉｍｉｔ Ｃｏｕｎｔ書込受付の送信が行われる。
【０１６３】
上記ステップＳ１０９〜Ｓ１２０までの処理が、Ａｓｙｎｃｈｒｏｎｏｕｓ Ｃｏｎｎｅｃｔｉｏｎにおけるデータ伝送処理としての１セットの手順を成す。ここで、例えば送信すべきデータサイズが、セグメントバッファ容量よりも大きく、１回のステップＳ１０９〜Ｓ１２０までの処理によっては、データの転送が完了していないとされる場合には、このステップＳ１０９〜Ｓ１２０までの処理を、データの転送が完了するまで繰り返し実行することが出来るようになっている。
【０１６４】
そして、データの転送が完了したら、ステップＳ１２１に示すようにして、ｐｒｏｄｕｃｅｒはｃｏｎｓｕｍｅｒに対して、Ｄｉｓｃｏｎｎｅｃｔ要求を送信する。ｃｏｎｓｕｍｅｒはステップＳ１２２において、このＤｉｓｃｏｎｎｅｃｔ要求を受信し、続くステップＳ１２３によりＤｉｓｃｏｎｎｅｃｔ受付を送信する。ステップＳ１２４において、ｐｒｏｄｕｃｅｒがＤｉｓｃｏｎｎｅｃｔ受付を受信することで、Ａｓｙｎｃｈｒｏｎｏｕｓ Ｃｏｎｎｅｃｔｉｏｎによるデータ送受信が完結する。
【０１６５】
４．ノード分類処理
前述したように、本実施の形態のＳＴＲ６０は、ＳＴＲ対応ＣＤ機３０，ＳＴＲ対応ＭＤ機１などの他のＳＴＲ対応機器ＳＴＲ対応機器と共に、コンポーネント的なシステムを組むことができるように構成されている。
このために、ＳＴＲ６０、もしくはＳＴＲ対応機器は、現在ＩＥＥＥ１３９４バス上に存在する各Ｎｏｄｅを探索してそのメーカや機種を識別することで、予め定められた規則によってグループ化を行う。つまり、ＩＥＥＥ１３９４バス上に存在するすべてのノードについての分類を行うようにされる。そして、後述するるようにして、ＳＴＲ６０が他の機器の電源状態に応じて自機の電源コントロールを行う際も、このノード分類によって作成されるテーブルを利用して、電源状態を監視すべき機器としてのノードを選択するように構成することが可能とされる。
そこで以下、本実施の形態としてのノード分類処理について説明する。
【０１６６】
先ず、本実施の形態においては、ノードは以下のようにして８つのグループに分類するものとして規定されているものとする。ここでは便宜上、分類される各グループごとに分類番号＃１〜＃８を付している。
＃１：ＳＴＲ対応ＣＤ機
＃２：ＳＴＲ対応ＭＤ機
＃３：同一メーカＣＤ機
＃４：同一メーカＭＤ機
＃５：他社メーカＣＤ機、ＭＤ機
＃６：ＣＤ機、ＭＤ機以外の同一メーカ機器（Subunitを複数有するものを含む）
＃７：ＣＤ機、ＭＤ機以外の他社メーカ機器で、SubunitがDisc,Tuner,VCRの何れかのもの
＃８：その他のもの
なお、上記分類は、現状として、Subunit＝Disc(正確にはDisc recorder/player)とされるＳＴＲ６０と同一メーカの機器としては、ＣＤとＭＤのみが接続されることを前提としており、例えばＤＶＤなどの他のディスクメディアに対応する機器は前提とされていないものとされる。従ってＳＴＲ６０と同一メーカの機器は、分類番号＃１，＃２，＃３，＃４，＃６の何れかに分類される。
【０１６７】
そして、このノード分類処理は、ＩＥＥＥ１３９４バス上でのノード管理に変更があるとされるバスリセット発生時に対応して、ＳＴＲ６０が実行するものとされる。このノード分類処理としての処理動作を図２８及び図２９のフローチャートに示す。この図に示す処理は、ここでは説明の便宜上、ＳＴＲ６０内のシステムコントローラ７０が、ＩＥＥＥ１３９４インターフェイス６１との情報の授受を行いながら実行していくものとする。
【０１６８】
ノード分類処理は図２８に示すステップＳ２０１から開始される。ステップＳ２０１においてはＩＥＥＥ１３９４バス上でバスリセットが発生するのを待機しており、バスリセットが発生したことが検出されるとステップＳ２０２以降のノード分類処理に移行する。
【０１６９】
ステップＳ２０２においては、Ｎｏｄｅ ＩＤについて［０］を設定する。また、続くステップＳ２０３としても示すように、現在種別判定対象として選択されているＮｏｄｅ（以降、「現Ｎｏｄｅ」ともいう）のＮｏｄｅ ＩＤに対応する変数ｉ（ここではｉ≧０とされる）について［０］に設定すると共に、バスリセット後とされる現在において、ＩＥＥＥ１３９４バス上に存在する自分以外のノード数＝ｎ、とするように設定を行う。つまり、ステップＳ２０２→Ｓ２０３の処理によってはノード分類処理開始時に対応しての初期化処理が実行される。
【０１７０】
次のステップＳ２０４においては、現在の変数ｉと自分以外のノード数ｎとについて、ｉ＜ｎが成立するか否かについて判別する。つまり、ＩＥＥＥ１３９４バス上に存在する自分以外の全ノードについて、以降説明することとなるノード分類のための処理が完了しているか否かについて判別するものである。
ここで、ｉ＜ｎが成立していないと判別された場合にはステップＳ２０５に進む。
【０１７１】
ステップＳ２０５においては、現在の変数ｉにより示されるＮｏｄｅ ＩＤをカウントする。例えば最初にステップＳ２０５に至った段階では、Ｎｏｄｅ ＩＤ＝０とカウントされ、このＮｏｄｅ ＩＤ＝０を有するノードが種別判定の対象となる。
そして次のステップＳ２０６においては、上記ステップＳ２０５により現ノードとして選択されたＮｏｄｅについての、Node Unique IDを識別する。このNode Unique IDは、そのノードのConfiguration ROM（図１５（ｅ））を参照しにいくことで識別可能である。このために、例えばシステムコントローラ７０では、そのＮｏｄｅのアドレスにアクセスしてConfiguration ROMの読み込みを行うようにされる。
【０１７２】
続いてはステップＳ２０７において、バスリセット前にセットされていたノードテーブルから、ステップＳ２０６にて識別されたのと同じNode Unique IDを有するＮｏｄｅ（機器）について調べることを行う。
ここでいうノードテーブルとは、ＩＥＥＥ１３９４バス上に存在する各機器（Ｎｏｄｅ）についてのノード分類結果が格納されるテーブルとされ、バスリセットが発生するごとに新規な内容を有するものが作成される。
【０１７３】
次のステップＳ２０８においては、上記ステップＳ２０７の処理結果として、同じNode Unique IDが発見されたか否かについて判別を行う。そして、肯定結果が得られた場合にはステップＳ２０９に進む。
ステップＳ２０９においては、バスリセット前のノードテーブルから、発見されたNode Unique IDを有するノードについての情報を読み出して、新たに今回作成するノードテーブルにセットすることを行う。つまり、バスリセット前にもＩＥＥＥ１３９４バス上に存在していたノードについては、後述する種別判定を行うことなく、前回のノードテーブルに格納されている情報をそのまま流用するようにされる。
そして、次のステップＳ２１０において変数ｉについてｉ←ｉ＋１とインクリメントした後にステップＳ２０４に戻るようにされる。変数ｉをインクリメントする処理は、種別判定対象となる現ノードを、Ｎｏｄｅ ＩＤとしてのナンバの昇順に従って変更する処理となる。
【０１７４】
一方、ステップＳ２０８において否定結果が得られた場合にはステップＳ２１１の種別判定処理を実行することになる。この種別判定処理は、その機器（Ｎｏｄｅ）についてノード分類するための判断材料となる種別を判定するための処理であり、また、この判定結果に基づいて、先に示した８つのグループのうちの何れかに分類することも最終的には行うようにされる。
【０１７５】
このステップＳ２１１の種別判定処理は、図２９に示される。
図２９においては、先ずステップＳ３０１において、Configuration ROMの内容を調べることが行われる。そして続くステップＳ３０２において、このConfiguration ROM内のsubunit IDとして格納されるmodel_IDを識別する。 model_IDによっては、そのノードの機種を識別することが可能になるのであるが、次のステップＳ３０７においては、model_IDの内容から、このノードがＳＴＲ対応機種であるか否かについて判別を行う。そして肯定結果が得られた場合には、ステップＳ３０４の処理に進む。
【０１７６】
本実施の形態としては、少なくともＳＴＲ対応機種にあっては、model_IDの内容からＳＴＲ対応機種であることと、また、その機器がＣＤ、ＭＤ、ＳＴＲの何れであるのかについても識別することが可能とされる。そこで、ステップＳ３０４においては、ＳＴＲ対応機種として、ＣＤ機であるのかＭＤ機であるのかを判別するようにされる。そしてＣＤ機であることを判別した場合には、ステップＳ３０５に進んで現ノードを分類番号＃１に分類する。
また、ＭＤ機であることを判別した場合には、ステップＳ３０６に進んで、分類番号＃２として分類する。ステップＳ３０５又はＳ３０６の処理が終了すると、図２８のステップＳ２１２に進む。
【０１７７】
また、ステップＳ３０３において否定結果が得られた場合にはステップＳ３０７に進んで、Configuration ROM内のsubunit IDとして格納されるmodule_vender_IDを識別することが行われる。module_vender_IDによっては製造メーカ名を識別することが可能となるのであるが、次のステップＳ３０８においては、現ノードがＳＴＲ６０と同一メーカ機種であるか否かについて判別を行う。ここで、否定結果が得られた場合にはそのままステップＳ３１０に進むのであるが、肯定結果が得られた場合には、ステップＳ３０９に進んで同一メーカフラグｆについてｆ←１と設定してからステップＳ３１０に進む。同一メーカフラグｆは、ｆ＝０であれば同一メーカではないことを示し、ｆ＝１であれば同一メーカであることを示す。
【０１７８】
ステップＳ３１０においては、先ず現ノードに対してSUBUNIT_INFOコマンド（STATUS)の送信を行う。SUBUNIT_INFOコマンドは、ＡＶ／ＣコマンドにおいてSubunit_typeが何であるのかの通知を行うために規定されているコマンドである。そして、SUBUNIT_INFOコマンド（STATUS)の送信に応答して、現ノードからはRESPONCEが返送されてくるのであるが、このRESPONCEの内容から、Subunit_typeについての識別を行う。
このSubunit_typeについての識別結果に基づき、次のステップＳ３１１においては、現ノードが、Subunit_type＝Disc（Disc recorder／Player）で、かつ、１つのみのSubunit_typeを有するものであるか否かについて判別する。そして、肯定結果が得られればステップＳ３１２以降の処理に進む。
【０１７９】
ステップＳ３１２においては、Subunit Identifier Descriptorを要求する内容のDescriptor_Accessコマンド（OPEN DESCRIPTORコマンド、READ DESCRIPTORコマンド）を現ノードに対して送信し、これに応答して現ノードから返送されるRESPONCEの内容から、現ノードのmedia_typeを識別することが行われる。
Descriptor_AccessコマンドとしてのOPEN DESCRIPTORコマンド及びREAD DESCRIPTORコマンドも、ＡＶ／Ｃコマンドの１つとされ、そのノードのDescriptorを読み込むために用いられるコマンドとされる。また、Subunit Identifier Descriptorは、ＡＶ／Ｃプロトコルに適合する形式により、そのノードが対応するディスクメディアについての管理情報（ＴＯＣ）が記述されたもので、このデータ構造内の所定位置に対してmedia_typeの情報が格納される。media_typeは、Subunit_type＝Discとされる場合に、そのディスクの種別を示すものであり、例えばこのmedia_typeによって、ＣＤであるのかＭＤであるのか、さらには他の種別のディスクメディアであるのかが示される。
【０１８０】
このDescriptor_Accessコマンドが送信されると、受信側のノードにおいては、RESPONCEとして、そのノードが保持しているSubunit Identifier Descriptorの一部、あるいはすべてを格納して送信する。そして上記ステップＳ３１２におけるREAD DESCRIPTORコマンド送信後の処理としては、現ノードから送信されるRESPONCEを受信して、このRESPONCEとしてのSubunit Identifier Descriptor内に記述されるmedia_typeの内容を識別するものである。
【０１８１】
そして、次のステップＳ３１３においては、識別したmedia_typeの内容が何であるのかについて判別を行う。そして、media_type＝ＣＤであると判別したのであればステップＳ３１４に進む。また、media_type＝ＭＤであると判別したのであればステップＳ３１７に進み、media_typeがＣＤ、ＭＤ以外であると判別したのであればステップＳ３１９に進む。
【０１８２】
ステップＳ３１４では、同一メーカフラグｆ＝１であるか否かについて判別しており、ｆ＝１である場合には、機種の種別としては、ＳＴＲ６０と同一メーカのＣＤ機であると判定されることになる。そして、この場合にはステップＳ３１５に進むことで、分類番号＃３として分類する。これに対して、ステップＳ３１４においてｆ＝１ではないと判別された場合には、他メーカのＣＤ機であると種別判定を行い、ステップＳ３１６により分類番号＃５に分類する。
【０１８３】
また、ステップＳ３１７においても、同一メーカフラグｆ＝１であるか否かについて判別を行うようにしており、肯定結果が得られた場合には、同一メーカのＭＤ機であると種別判定を行って、ステップＳ３１８により分類番号＃４に分類する。これに対してステップＳ３１７において否定結果が得られた場合には、他社メーカのＭＤ機」であると種別判定したことになり、ステップＳ３１６により分類番号＃５に分類する。
【０１８４】
また、ステップＳ３１９においても同一メーカフラグｆ＝１であるか否かについて判別するようにされ、先ず否定結果が得られた場合にはステップＳ３２０に進んで分類番号＃７に分類する。つまり、この場合には、他社メーカ機器でSubunit_type＝Discと種別判定されるため、「分類番号＃７：ＣＤ機、ＭＤ機以外の他社メーカ機器で、SubunitがDisc,Tuner,VCRの何れかのもの」に含められるものである。
一方、ステップＳ３１９において肯定結果が得られたのであれば、Subunit_type＝Discではあるが、「ＣＤ機、ＭＤ機以外の同一メーカ機器」として判定されるため、ステップＳ３２２において分類番号＃６に分類する。
【０１８５】
また、先のステップＳ３１１において否定結果が得られた場合にはステップＳ３２１に進む。ステップＳ３１１において否定結果が得られる場合とは、現ノードのSubunit_type＝Disc以外で１つのSubunit_typeを有する場合、もしくは、現ノードが複数のSubunit_typeを有する場合である。複数のSubunit_typeを有するノードとしては、例えばＣＤプレーヤ、ＭＤレコーダ／プレーヤ、チューナなどの２以上のソース出力を行う装置部が一体化された複合機器がこれにあたる。
【０１８６】
ステップＳ３２１においても、同一メーカフラグｆ＝１であるか否かについて判別を行う。そして、肯定結果が得られた場合には、「ＣＤ機、ＭＤ機以外の同一メーカ機器」であると判定してステップＳ３２２に進む。
一方、ステップＳ３２１において否定結果が得られた場合には、ステップＳ３２３に進む。ステップＳ３２３においては、Subunit_type＝TUNER、Subunit_type＝VCRの何れかであるか否かが判別される。つまり、SubunitとしてTUNERのみを有する機器であるか、又はVCRのみを有する機器であるのかが判別される。そして、このうちの何れかに該当するとして肯定結果が得られた場合には、ステップＳ３２４に進む。この場合には、他社メーカのTUNERのみ,又はVCRのみの機器であるとして種別判定が行われるが、これは「分類番号＃７：ＣＤ機、ＭＤ機以外の他社メーカ機器で、SubunitがDisc,Tuner,VCRの何れかのもの」に含められるものであり、従って分類番号＃７として分類される。
これに対して、ステップＳ３２３において否定結果が得られた場合には、分類番号＃１〜＃７の何れにも該当しないものであると種別判定を行って、ステップＳ３２５に進んで分類番号＃８に分類する。
【０１８７】
上記ステップＳ３１５，Ｓ３１６，Ｓ３１８，Ｓ３２０，Ｓ３２２，Ｓ３２４，Ｓ３２５の各分類処理を実行した後は、図２８のステップＳ２１２に進む。
【０１８８】
図２８のステップＳ２１２においては、上記ステップＳ３１５，Ｓ３１６，Ｓ３１８，Ｓ３２０，Ｓ３２２，Ｓ３２４，Ｓ３２５の各処理によって分類された結果を含めて形成した現ノードについてのノード情報を、今回のバスリセットに対応して作成されるノードテーブルにセットする。そして、次のステップＳ２１３においては、変数ｉについてｉ←ｉ＋１とインクリメントし、また、同一メーカフラグｆについてｆ＝１とされているのであれば、これをｆ←０にリセットしてステップＳ２０４に戻るようにされる。
【０１８９】
そしてステップＳ２０４にて否定結果が得られるまで、これまで説明したステップＳ２０５〜２１３の処理が実行されることで、バスリセット後においてＩＥＥＥ１３９４バス上に存在するノードごとのノード分類、つまり、ノードテーブルへのノード情報のセットが行われていく。
そして、全ノードについてのノード分類が完了してステップＳ２０４において否定結果が得られたとすると、ステップＳ２１４に進むことになる。ステップＳ２１４においては、これまでの処理により作成されたとされるノードテーブルが例えばＲＡＭにおいて記憶保持されるように処理を実行する。以降は、例えばこのノードテーブルに格納されたノード分類結果を利用して所要のシステム動作を実行するようにされる。
【０１９０】
５．ＳＴＲの電源オフ連動機能
５−１．概要
例えば先に図１に示したシステムにおいては、ＳＴＲ６０がその中心的役割を果たす。つまり、ＳＴＲ６０は、他の機器から送信されてくるオーディオソースとしてのデータを選択的に入力して音声として出力することが可能とされ、また、他の機器に対してシステム的な動作が得られるように所要のコマンドを送信することも行うことができるようにされている。
【０１９１】
ここで、図１に示したシステムがユーザにより使用されていない場合として、例えばＳＴＲ６０の電源はオンとなっているが、ＳＴＲ６０以外の或る機器の電源がオフ（スタンバイ）となっている場合を考えてみる。
このような場合には、例えば電力消費をできるだけ抑えることなどを考慮して、例えば少なくともＳＴＲ６０の電源もオフとすることが好ましい。そこで、本実施の形態においては、上記のようにしてＳＴＲ６０以外の或る特定の機器の電源がオフの状態にあるときには、これに応じて、ＳＴＲ６０の電源もオフとするように構成される。これにより、他の機器がオフ状態にあれば、これに連動して、ＳＴＲ６０も自動的にオフ状態にすることができ、電源の切り忘れによる無駄な電力消費はなくなり、また、ユーザが手動操作で電源をオフにする手間も省けることになる。
【０１９２】
５−２．ＰＯＷＥＲ ＳＴＡＴＵＳ ｃｏｍｍｍａｎｄ
そして、ＳＴＲ６０が上記のようにして他機器の電源状態に応じて自身の電源コントロールを行うのには、他機器の現在の電源状態を知ることが必要となるのであるが、このためにＳＴＲ６０は、ＡＶ／Ｃコマンドの１つであるＰＯＷＥＲＳＴＡＴＵＳ ｃｏｍｍｍａｎｄを使用して他の機器との通信を行うようにされる。ＰＯＷＥＲ ＳＴＡＴＵＳ ｃｏｍｍｍａｎｄは、Ｃｏｎｔｒｏｌｌｅｒ（この場合にはＳＴＲ６０）がＴａｒｇｅｔ（他の機器）に対して、電源状態の通知を要求するためのコマンドとして定義されている。
【０１９３】
図３０はＰＯＷＥＲ ＳＴＡＴＵＳ ｃｏｍｍｍａｎｄのデータ構造を示している。なお、この図においては、図２０に示したＷｒｉｔｅ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔ（ＡＶ／Ｃコマンドパケット）における、ｄａｔａｆｉｅｌｄ内の構造が示される。また、図２０において説明した内容については、ここでの説明は省略する。
【０１９４】
図３０に示すように、ＰＯＷＥＲ ＳＴＡＴＵＳ ｃｏｍｍｍａｎｄとしては、ＣＴＳの４ビットの領域に対して「０ｈ」を格納し、ｃｔｙｐｅの４ビットの領域に対しては「１ｈ」を格納することで、ＡＶ／Ｃ ＳＴＡＴＵＳ ｃｏｍｍｍａｎｄであることが示される。そして、ｏｐｃｏｄｅの８ビットの領域に対しては、ＰＯＷＥＲ ｃｏｍｍｍａｎｄであることを示す「Ｂ２ｈ」を格納する。このようにして上記各値が格納されることで、このＡＶ／ＣコマンドパケットがＰＯＷＥＲ ＳＴＡＴＵＳ ｃｏｍｍｍａｎｄであることが示される。
【０１９５】
そして、ｏｐｃｏｄｅに続くｏｐｅｒａｎｄ［０］としての８ビットの領域に、電源状態を示すpower_stateの値を格納するものとされる。ＰＯＷＥＲ ＳＴＡＴＵＳ ｃｏｍｍｍａｎｄの場合には、ここに「７Ｆｈ」を格納しておくものとされ、Ｔａｒｇｅｔから、ＲＥＳＰＯＮＳＥとしてコマンドを返送する際に、このＴａｒｇｅｔとしての機器の現在の電源状態に対応する値に置き換えが行われる。
【０１９６】
そして、上記ＰＯＷＥＲ ＳＴＡＴＵＳ ｃｏｍｍｍａｎｄを受信したＴａｒｇｅｔにおいては、これに応答して図３１に示すＲＥＳＰＯＮＳＥを、Ｃｏｎｔｒｏｌｌｅｒに対して返送する。
このＲＥＳＰＯＮＳＥとしては、図示するように、power_stateの領域に対して、「７０ｈ」又は「６０ｈ」の値を格納する。このpower_stateの値が「７０ｈ」であれば、Ｔａｒｇｅｔとしての機器の現在の電源状態がオンであることを示し、「６０ｈ」であればオフであることを示す。Ｃｏｎｔｒｏｌｌｅｒでは、このＲＥＳＰＯＮＳＥにおけるpower_stateの値を参照することで、Ｔａｒｇｅｔとしての他の機器の電源状態がオンであるのかオフであるのかを知ることができる。
【０１９７】
５−３．処理動作
図３２のフローチャートは、ＳＴＲ６０における電源連動制御のための処理動作を示している。なお、この処理はシステムコントローラ７０が実行する。
また、この処理は、ＣｏｎｔｒｏｌｌｅｒがＴａｒｇｅｔに対して実行するものとされ、この場合、ＣｏｎｔｒｏｌｌｅｒはＳＴＲ６０となる。また、Ｔａｒｇｅｔは、ＳＴＲ６０がその電源状態を監視する対象として選択した特定の他機器とされる。これは、例えばファクトリープリセットとして予め設定されていてもよいし、また、例えばバスリセットごとの機器の接続状況やユーザの操作によって予め設定できるようにしてもよい。
また、この電源状態の監視対象の機器選択にあたっては、前述したノード分類により分類されたグループを基準とすることも考えられる。この場合の機器選択の仕方としては各種考えられるのであるが、一例としては、ノード分類番号＃１として含まれるＳＴＲ対応ＣＤ機３０を対象としたり、ノード分類番号＃２として含まれるＳＴＲ対応ＭＤ機１とすることなども考えられる。
【０１９８】
先ず、図３２に示す処理にあっては、ステップＳ４０１において、ＳＴＲ６０自身としての機器の状態が所定の一定の条件を満たしているか否かについて判別を行っている。
ここで判別される条件としては、例えば次のようになる
１．メイン電源がオン状態にあること
２．予め決められた一定時間以上操作されていないこと
３．電源連動設定がオン（有効）に設定されていること
４．タイマ機能及びスリープ機能が現在有効となっていないこと
本実施の形態としては、例えば上記した各条件をすべて満たした場合にのみ、以降の電源連動制御のための処理を実行するようにされる。これはつまり、現在の機器の状態や、ユーザ操作による設定状況などとして、電源を自動オフさせることが適切ではないような場合にも電源オフ連動動作が働いてしまって、かえって使い勝手が悪くなるようなことが無いように配慮しているものである。
【０１９９】
上記ステップＳ４０１において否定結果が得られたときには、そのまま待機することになるが、肯定結果が得られた場合にはステップＳ４０２の処理に進む。ステップＳ４０２においては、上述したようにして、電源状態の監視対象機器として設定されている機器をＴａｒｇｅｔとして、このＴａｒｇｅｔに対して、ＰＯＷＥＲ ＳＴＡＴＵＳ ｃｏｍｍｍａｎｄを送信し、次のステップ４０３においてＲＥＳＰＯＮＳＥを受信する。
【０２００】
次のステップＳ４０４においては、ＲＥＳＰＯＮＳＥにおけるpower_stateの値を参照することで、現在Ｔａｒｇｅｔのメイン電源がオフ状態にあるか否かについて判別する。
ここで否定結果が得られた場合にはステップＳ４０６に進む。ステップＳ４０６においては、或る決められた一定時間待機してステップＳ４０１の処理に戻る。つまり、ＳＴＲ６０の機器としての状態が一定の条件を満たしているとされた場合において、Ｔａｒｇｅｔの電源がオン状態にあるとされるうちは、ステップＳ４０２→Ｓ４０３によるＰＯＷＥＲ ＳＴＡＴＵＳ ｃｏｍｍｍａｎｄの送信及びＲＥＳＰＯＮＳＥの受信を一定時間ごとに繰り返し行う。このようにして、Ｔａｒｇｅｔの電源状態をみにいくための処理を一定時間ごとに繰り返し実行することで、本実施の形態では、Ｔａｒｇｅｔの電源状態がオフとなったときには、これに応じて、できるだけ早期にＳＴＲの電源がオフに切り換えられるように制御するものである。
また、上記したように一定時間ごとにコマンドの授受を行うようにした場合には、このコマンド送信のために比較的頻繁にバス帯域を使用することになるので、例えば実状としては、データ転送速度が低速なバスでは負担が重くなる可能性が或る。しかし、本実施の形態では、これまでのデータインターフェイスよりもデータ転送速度が高速とされるＩＥＥＥ１３９４データインターフェイスを採用していることから、バスの負担も軽く、例えば同時に行われる他帯域のデータの送受信の安定も維持できる。
なお、ステップＳ４０６において待機すべき時間としては、上記したことを考慮して適切であるとされる時間長が任意に設定されればよいのであるが、一例としては、500ms程度とされる。また、各機器のシステムコントローラの処理能力によっては、10ms程度にまで短縮することも可能とされる。
【０２０１】
一方、ステップＳ４０４において、Ｔａｒｇｅｔがオフ状態にあることが判別された場合にはステップＳ４０５に進んで、自身のメイン電源をオフとしてスタンバイ状態とするように制御を実行する。これにより、他の機器の電源状態がオフであるのに連動して、ＳＴＲ６０自身もメイン電源をオフとする動作が得られる。
【０２０２】
ところで、ＳＴＲ６０が電源監視対象とするＴａｒｇｅｔとしての機器について、例えば一定時間以上停止状態であったり、また一定時間以上ユーザによる操作が行われないなどの条件が満たされる場合には、その機器自身がメイン電源をオフとする機能を与えたとする。
例えばこのような機器がＳＴＲ対応ＣＤ機３０であるとすれば、このＳＴＲ対応ＣＤ機３０が一定時間以上再生動作を行っておらず、また一定時間以上ユーザによる操作が行われないなどしたときには、自機のメイン電源をオフとすることになる。
そして、このようなＴａｒｇｅｔ側の機能と、上述したＳＴＲ６０の電源連動オフ機能とを併用すれば、先ず、Ｔａｒｇｅｔとしての機器がメイン電源を自動的にオフとすると、これに連動してＣｏｎｔｒｏｌｌｅｒであるＳＴＲ６０もメイン電源を自動的にオフにするという動作が得られる。つまりＣｏｎｔｒｏｌｌｅｒとＴａｒｇｅｔの関係にある少なくとも２台の機器のメイン電源を、すべて自動的にオフにするというシステム動作を得ることができ、ＳＴＲ６０の電源連動オフ機能はさらに有効に活用されることにもなる。
【０２０３】
なお、実際にＳＴＲ６０が電源状態を監視すべき機器としては、ＳＴＲ６０とオーディオコンポーネントシステム的機能を有するようにされるＳＴＲ対応ＣＤ機３０、ＳＴＲ対応ＭＤ機１などを対象にすることが先ず考えられるのであるが、ＰＯＷＥＲ ｃｏｍｍａｎｄは、ＡＶ／ＣコマンドとしてＧｅｎｅｒａｌの範疇で規定されているものであることから、ＳＴＲ対応機器以外の同一メーカ機器はもちろんのこと、さらには、ＩＥＥＥ１３９４バス上に存在する他メーカの機器を対象とすることも可能とされる。
【０２０４】
また、電源連動オフ機能のための処理動作についても先にフローチャートにより示した処理に限定されるものではなく、例えばそのプログラムの実際などは適宜変更されて構わないものである。
これについては、例えば先に説明したノード分類処理としても同様であり、ノード分類処理としては、最終的にＩＥＥＥ１３９４バス上に接続される各機器についての分類が行われてその結果を反映したノードテーブルが作成されればよい。
また、ここではＳＴＲ６０を中心としたシステムが組まれていることで、ＳＴＲ６０が電源連動オフ機能を有するものとして説明しているが、ＩＥＥＥ１３９４バスを使用したシステム構成としても各種考えられるもので、電源オフ連動機能を有する機種についても本発明としては限定されるものではない。
また、ＩＥＥＥ１３９４の規格以外のデジタルデータインターフェイスに対しても適用が可能である。
【０２０５】
【発明の効果】
以上説明したように本発明では、例えばデータバスを利用して組まれるＡＶシステムにおいて、その中心となるＳＴＲ（情報処理機器）が、他の機器とＰＯＷＥＲ ｃｏｍｍａｎｄの授受を行うことによって、この他の機器の電源がオフであれば自身も電源をオフとするように動作する。
これによって、例えば、システムにおける各機器がそれぞれデータバス上で独立的に存在するものと認識され、また、連動機能を有する電源コンセント等と接続されていない場合であっても、システムとしての電源コントロール機能を与えることが可能となるものである。また、本発明では、システム内において中心となるＳＴＲが、他の機器の電源状態に従って自機の電源状態をコントロールするために、例えば、ＳＴＲよりも先に他の機器の電源がオフにされたような場合に、これに応じてＳＴＲが自動的に電源をオフにするという、これまでのシステムにはない動作が得られる。これにより、システムの電源の連動コントロールとしてはより充実したものとなる。そしてこれはＳＴＲにおける消費電力量を抑えることにもつながる。
【０２０６】
また、本発明では、ＳＴＲ自身が一定の条件を満たす状態となったときに、上記した他機器との電源オフ連動を行うようにされるのであるが、これは換言すれば、例えばＳＴＲの電源をオンのままにしておくことが適切であるような状況の場合には、電源オフ連動動作を行わないようにしているものであり、利便性がさらに向上される。
【０２０７】
また、他の機器の電源状態のチェックを一定時間ごとに繰り返すようにすれば、できるだけ早期にＳＴＲの電源をオフさせる動作が得られることになり、上記した省電力化を促進させることができる。また、電源オフ連動機能もより高められる。
【０２０８】
そして、例えばＳＴＲと他の機器の通信フォーマットとして、これまでのデータインターフェイスのなかでは、高速とされるＩＥＥＥ１３９４インターフェイスを採用することで、他の機器の電源状態をチェックするためのコマンドの送受信を例えば比較的頻繁に行うようにしたとしても、データバスへの負担は軽く、例えばオーディオデータ等をはじめとするソース情報の送受信の安定を確保することができる。そして、本発明としての技術を容易に実現することも可能となるものである。
【図面の簡単な説明】
【図１】本発明の実施の形態としてのＡＶシステムの構成例を示す斜視図である。
【図２】ＳＴＲのフロントパネルの様子を示す正面図である。
【図３】ＳＴＲ対応ＣＤ機のフロントパネルの様子を示す正面図である。
【図４】ＳＴＲ対応ＭＤ機のフロントパネルの様子を示す正面図である。
【図５】ＳＴＲの内部構成例を示すブロック図である。
【図６】ＳＴＲ対応ＣＤ機の内部構成例を示すブロック図である。
【図７】ＳＴＲ対応ＭＤ機の内部構成例を示すブロック図である。
【図８】本実施の形態に対応するＩＥＥＥ１３９４のスタックモデルを示す説明図である。
【図９】ＩＥＥＥ１３９４に使用されるケーブル構造を示す説明図である。
【図１０】ＩＥＥＥ１３９４における信号伝送形態を示す説明図である。
【図１１】ＩＥＥＥ１３９４におけるバス接続規定を説明するための説明図である。
【図１２】ＩＥＥＥ１３９４システム上でのＮｏｄｅ ＩＤ設定手順の概念を示す説明図である。
【図１３】ＩＥＥＥ１３９４におけるＰａｃｋｅｔ送信の概要を示す説明図である。
【図１４】Ａｓｙｎｃｈｒｏｎｏｕｓ通信における基本的な通信規則（トランザクションルール）を示す処理遷移図である。
【図１５】ＩＥＥＥ１３９４バスのアドレッシング構造を示す説明図である。
【図１６】ＣＩＰの構造図である。
【図１７】プラグにより規定された接続関係例を示す説明図である。
【図１８】プラグコントロールレジスタを示す説明図である。
【図１９】Ａｓｙｎｃｈｒｏｎｏｕｓ通信において規定されるＷｒｉｔｅ Ｔｒａｎｓａｃｔｉｏｎを示す処理遷移図である。
【図２０】Ａｓｙｎｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔ（ＡＶ／Ｃコマンドパケット）の構造図である。
【図２１】Ａｓｙｎｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔにおける、ｃｔｙｐｅ／ｒｅｓｐｏｎｃｅの定義内容を示す説明図である。
【図２２】Ａｓｙｎｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔにおける、ｓｕｂｕｎｉｔ＿ｔｙｐｅと、ｏｐｃｏｄｅの定義内容例を示す説明図である。
【図２３】Ａｓｙｎｃｈｒｏｎｏｕｓ通信におけるプラグ構造を示す説明図である。
【図２４】Ａｓｙｎｃｈｒｏｎｏｕｓ通信におけるプラグアドレス構造を示す説明図である。
【図２５】Ａｓｙｎｃｈｒｏｎｏｕｓ通信におけるプラグアドレス構造を示す説明図である。
【図２６】Ａｓｙｎｃｈｒｏｎｏｕｓ通信におけるプラグ間での処理を示す説明図である。
【図２７】Ａｓｙｎｃｈｒｏｎｏｕｓ Ｃｏｎｎｅｃｔｉｏｎとしての送信手順を示す説明図である。
【図２８】ノード分類処理を示すフローチャートである。
【図２９】ノード分類処理における種別判定処理を示すフローチャートである。
【図３０】 POWER STATUS commandのデータ構造を示す説明図である。
【図３１】 POWER STATUS commandのRESPONSEのデータ構造を示す説明図である。
【図３２】ＳＴＲにおいて実行される電源オフ連動のための処理を示すフローチャートである。
【符号の説明】
１ ＳＴＲ対応ＭＤ機器、３０ ＳＴＲ対応ＣＤ機 ６０ ＳＴＲ、１２０，１３０，１５０ 電源キー、６１，４９，２５ ＩＥＥＥ１３９４インターフェイス、７５，４７，２４ 表示部、１２７，１５６，１４０ ディスプレイキー
【発明の属する技術分野】
本発明は、所定のデータ通信フォーマットに依るデータインターフェイスを介してデータの送受信を行うようにされる電子機器システム、及びこのような電子機器システムを構成する情報処理機器に関するものである。
【０００２】
【従来の技術】
近年、デジタルデータインターフェイスとして、ＩＥＥＥ(Institute of Electrical Engineers)１３９４データインターフェイスが知られてきている。ＩＥＥＥ１３９４データインターフェイスは、例えばＳＣＳＩなどよりもデータ転送レートが高速であり、周知のように、所要のデータサイズを周期的に送受信することが保証されるＩｓｏｃｈｒｏｎｏｕｓ通信が可能とされる。このため、ＩＥＥＥ１３９４データインターフェイスは、ＡＶ(Audio/Video)などのストリームデータをリアルタイムで転送するのに有利とされている。
【０００３】
このような技術を背景として、各種デジタルＡＶ機器やパーソナルコンピュータ装置等の電子機器を、例えばＩＥＥＥ１３９４等のデータインターフェイス規格に従ったデータバスを介して相互に接続することで、機器間でＡＶデータを送受信できるようにしたＡＶシステムが提案されてきている。
【０００４】
【発明が解決しようとする課題】
ここで、これまでのＡＶシステムにおける電源オン／オフの連動について考えてみる。
これまでに広く普及している、いわゆるシステムコンポーネントといわれるＡＶシステムでは、システムを構成する各ソースの記録再生機器部やアンプなどを統合的に組むことによって、全体としては１つのオーディオ機器として認識されるように構成されている。このため、そのシステムコンポーネントのメイン電源に対してオン／オフを行えば、例えばローカルな内部バスを利用して制御を行うことで、システムコンポーネントを構成している各機器部の電源のオン／オフを連動的に行うことが可能とされている。
また、例えばアンプなどに対して設けられている連動タイプの電源コンセントに対して他のＡＶ機器の電源を接続しておくようにすることで、各機器間の電源のオン／オフが連動するようにされたシステムコンポーネントも古くから知られているものである。
【０００５】
これに対して、ＩＥＥＥ１３９４等のデータインターフェイスにおいては、ＩＥＥＥ１３９４インターフェイス機能を有している機器であれば、原則として機種やメーカを問わずに相互通信可能に接続することが可能とされる。このため、ＩＥＥＥ１３９４等のデータインターフェイスにより接続されるシステムにおいては、このシステムを構成する各機器は、データバス上ではそれぞれ独立した機器として認識される。
また、電源についても、例えば各機器ごとに独立して商用交流電源から入力可能にされており、例えば、あえて連動タイプの電力源を使用しての電源オン／オフの連動を考慮したシステムが構築されるとは限らない。
【０００６】
即ち、現状としては、例えばＩＥＥＥ１３９４などのデータインターフェイスを利用して構成されるＡＶシステムなどにおいて、例えば同一シリーズの機種や同一メーカ機器などの或る特定の機種の機器間でシステムコンポーネント的な機能を有する構成を与えようとした場合には、これらの機器がデータバス上で独立した機器として認識される以上、そのままでは上記したような電源オン／オフの連動は行うことができないことになるものである。しかし、ＡＶシステムとしての使い勝手を考慮した場合には、当然のこととして、電源のオン／オフの連動が可能とされることが好ましいことになり、利便性も向上されることになる。
【０００７】
また、これまでのシステムコンポーネントにおいては、例えばシステムの中心となるアンプ機器などの電源オン／オフに応じて他の機器の電源オン／オフを連動させるという機能を有しているものであり、例えば逆に、メインとなる機器が、他の機器の電源オン／オフ状態にあわせて自機の電源状態をコントロールする機能は実現されていない。
特にＩＥＥＥ１３９４データバスを利用してのシステムでは、物理的なケーブルの接続形態によって信号の流れは決まってくるものではなく、データバス上に存在する各機器は基本的に相互通信が可能である。従って、各オーディオ機器の利用形態も多様となることから、上記したような、メインとなる機器が他の機器に従うようにして自機の電源をコントロールする機能が付加されても、これは有効に活用されるものである。
【０００８】
【課題を解決するための手段】
そこで本発明は上記した課題を考慮して、先ず電子機器システムとして次のように構成する。
つまり、それぞれ電源を独立して入力可能とされ、所定の通信フォーマットによるデータバスを介してソース情報を送信出力するソース出力機器を含む電子機器と、上記ソース出力機器から送信されてきた上記ソース情報を入力する情報処理機器とを備えて成る電子機器システムにおいて、上記情報処理機器は、上記情報処理機器が自身の電源をオフとすることが可能な所定の条件を満たした状態にあるか否かについて自動で判別する条件判別手段と、上記条件判別手段により上記所定の条件を満たした状態にあると判別されたことに応じて、上記ソース出力機器のうち特定の１以上のソース出力機器ごとに対して、上記データバスを介して、電源状態がオフであるか否かについての通知を要求する要求コマンドを送信する要求コマンド送信手段と、上記要求コマンドを受信したことに応じてソース出力機器から送信された、このソース出力機器の電源状態がオフであるか否かについての通知内容を有する応答コマンドを受信する受信手段と、上記受信手段により受信した応答コマンドの通知内容として、電源状態がオフであることを示しているか否かについて判別する電源状態判別手段と、上記電源状態判別手段により電源状態がオフであることを示していると判別された場合に、自機の電源をオンからオフに切り換えるように制御する制御手段とを備えることとした。
【０００９】
また、情報処理機器としては次のように構成する。
つまり、それぞれの電子機器が独立して電源を入力可能とされ、所定の通信フォーマットによるデータバスを介して他の電子機器と接続されることで情報の送受信が可能なように形成される電子機器システムにおける情報処理機器として、上記他の電子機器のうちのソース出力機器としての電子機器から送信出力されるソース情報を入力するソース情報入力手段と、本情報処理機器が自身の電源をオフとすることのできる所定の条件を満たした状態にあるか否かについて自動で判別する条件判別手段と、上記条件判別手段により上記所定の条件を満たした状態にあると判別されたことに応じて、上記ソース出力機器のうち特定の１以上の電子機器に対して、上記データバスを介して、このソース出力機器の電源状態がオフであるか否かについての通知を要求する要求コマンドを送信する要求コマンド送信手段と、上記要求コマンドを受信したことに応じてソース出力機器から送信された、電源状態がオフであるか否かについての通知内容を有する応答コマンドを受信する受信手段と、上記受信手段により受信した応答コマンドの通知内容として、電源状態がオフであることを示しているか否かについて判別する電源状態判別手段と、上記電源状態判別手段により電源状態がオフであることを示していると判別された場合に、自機の電源をオンからオフに切り換えるように制御する制御手段とを備えて構成することとした。
【００１１】
上記各構成によれば、ソース情報の出力を行うソース出力機器としての電子機器と、ソース情報を入力する情報処理機器とされる電子機器をデータバスを介して接続することでシステムを構築した場合において、情報処理機器では、ソース出力機器の電源状態がオフにあることを検出すると、自機の電源もオフとするように動作することになる。つまり、本発明では、各電子機器がデータバス上で独立した存在であると認識されている場合であっても、電源を連動してコントロールすることが可能とされると共に、例えばシステム内において中心として機能し得る情報処理機器が、他の機器の電源状態に応じて自身の電源のコントロールを行うという動作を得ることができる。
【００１２】
【発明の実施の形態】
以下、本発明の実施の形態について説明する。
なお、以降の説明は次の順序で行う。
１．ＡＶシステム
１−１．全体構成
１−２．ＳＴＲ（フロントパネル）
１−３．ＣＤ機（フロントパネル）
１−４．ＭＤ機（フロントパネル）
１−５．ＳＴＲ（内部）
１−６．ＣＤ機（内部）
１−７．ＭＤ機（内部）
２．ＩＥＥＥ１３９４による本実施の形態のデータ通信
２−１．概要
２−２．スタックモデル
２−３．信号伝送形態
２−４．機器間のバス接続
２−５．パケット
２−６．トランザクションルール
２−７．アドレッシング
２−８．ＣＩＰ(Common Isochronos Packet)
２−９．コネクションマネージメント
２−１０．ＦＣＰにおけるコマンド及びレスポンス
２−１１．ＡＶ／Ｃコマンドパケット
２−１２．プラグ
２−１３．Asynchronous Connection送信手順
４．ノード分類処理
５．ＳＴＲの電源オフ連動機能
５−１．概要
５−２．ＰＯＷＥＲ ＳＴＡＴＵＳ ｃｏｍｍｍａｎｄ
５−３．処理動作
【００１３】
１．ＡＶシステム
１−１．全体構成
図１は本発明の実施の形態の電子機器システムの構成例を示している。
本実施の形態としての電子機器システムは、複数のＡＶ機器等をＩＥＥＥ１３９４インターフェイスのデータバスにより相互通信可能に接続することで構築される。
【００１４】
図１においては、ＡＶシステムを構成する機器として、ＳＴＲ(Stereo Tuner Receiver)６０と、２台のＳＴＲ対応ＣＤ機３０，３０、ＳＴＲ対応ＭＤ機１、同一メーカ機種１００、他社メーカ機種１１０が示される。
【００１５】
ＳＴＲ６０は、図１に示すＡＶシステムの中心として機能するもので、主としてチューナ機能、外部ソース入力選択機能、及びアンプ機能を備えており、例えば図のようにしてステレオ音声に対応する左右チャンネルのスピーカＳＰ（Ｌ）（Ｒ）を接続することができるようになっている。
詳しい構成は後述するが、ＳＴＲ６０では、内部のチューナ部で受信した放送信号と、アナログオーディオ信号入力と、さらにＩＥＥＥ１３９４バス１１６を介して外部から入力される複数のオーディオソースについて選択を行い、最終的には、これを音声としてスピーカＳＰ（Ｌ）（Ｒ）から出力させることができるように構成されている。
【００１６】
また、この図には、ＳＴＲ６０に対する操作を行うためのリモートコントローラＲＭも示されている。ＳＴＲ６０は、このリモートコントローラＲＭに対して行われた操作に応じて送信されてくる操作コマンド信号を受信し、その操作コマンド信号の内容に応じた所要の動作を実行する。なお、この図では、ＳＴＲ６０に対応するリモートコントローラＲＭのみが示されているが、実際としては、他の機器についてもリモートコントローラによる操作が可能とされていてよいものである。
【００１７】
また、上記ＳＴＲ６０と共に接続することで利便性の高い各種のシステム機能を実現することのできる機種として、ここではＳＴＲ対応ＣＤ機３０とＳＴＲ対応ＭＤ機１とが示されている。ＳＴＲ対応ＣＤ機３０とＳＴＲ対応ＭＤ機１は、例えばＳＴＲ６０と同一メーカ品とされる。
【００１８】
ＳＴＲ対応ＣＤ機３０は、ＣＤ(Compact Disc)プレーヤとしての機能を有しており、装填されたＣＤについての再生を行う。そして、ＣＤから再生して得られるオーディオデータを、ＩＥＥＥ１３９４バス１１６を介して送信出力することが可能とされる。
また、ＳＴＲ対応ＭＤ機１は、ＭＤ(Mini Disc)といわれるオーディオデータを書き換え可能な光磁気ディスクに対応して記録再生を行うことのできるＭＤレコーダ／プレーヤとされる。そしてこのＳＴＲ対応ＭＤ機１においては、ＩＥＥＥ１３９４バス１１６を介して送信されてくるオーディオデータを受信してＭＤに対して記録することが可能とされている。また、ＭＤに記録されているオーディオデータを再生して、ＩＥＥＥ１３９４バス１１６を介して送信出力することが可能とされる。
【００１９】
上記ＳＴＲ６０、ＳＴＲ対応ＣＤ機３０、及びＳＴＲ対応ＭＤ機１の３台によって得られる代表的なシステム動作としては次のようなものが挙げられる。
例えば、ＳＴＲ対応ＣＤ機３０にて再生しているＣＤのオーディオデータをＳＴＲ対応ＭＤ機１に対して送信することで、ＳＴＲ対応ＭＤ機１においては、このＣＤのオーディオデータをＭＤに記録することができる。つまり、いわゆるダビングを行うことが可能となるものである。また、このときにＳＴＲ対応ＣＤ機３０にて再生しているＣＤのオーディオデータ、または一旦ＳＴＲ対応ＭＤ機１にて受信されたＣＤのオーディオデータをＳＴＲ６０に対しても送信すれば、ＳＴＲ６０ではこのＣＤのオーディオデータをモニタ音声としてスピーカＳＰ（Ｌ）（Ｒ）から出力させることが可能とされる。
【００２０】
また、ここでの詳しい説明は省略するが、ＳＴＲ対応ＣＤ機３０とＳＴＲ対応ＭＤ機１は、ＳＴＲ６０を中心としたいわゆるオーディオ・コンポーネントシステム的な各種機能が特化して与えられるべきものとして構成されている。例えば、ＳＴＲ対応ＣＤ機３０からＳＴＲ対応ＭＤ機１へのダビングを例に挙げれば、倍速ダビング動作や、ＣＤの再生開始／終了タイミングに同期させて、ＳＴＲ対応ＭＤ機１における記録開始／終了タイミングを制御する、いわゆるシンクロ・ダビング動作なども容易に実行可能とされている。
【００２１】
同一メーカ機器１００は、ＳＴＲ６０、ＳＴＲ対応ＣＤ機３０、及びＳＴＲ対応ＭＤ機１と同一メーカとされて、ＩＥＥＥ１３９４インターフェイスに対応した通信機能を有するデジタルＡＶ機器である。ここでの同一メーカ機器１００の実際としては、特に言及しないが、例えばＣＤプレーヤ、ＭＤレコーダ／プレーヤや、デジタルＶＴＲなどとされればよいものである。
この同一メーカ機器１００としては、例えばＳＴＲ対応ＣＤ機３０、及びＳＴＲ対応ＭＤ機１などと比較した場合には、特にＳＴＲ６０を中心とするシステムコンポーネント機能が与えられるようには構成されていない点が異なる。
ただし、メーカ内のみで有効となるコマンド（Vender Dependent Commnandといわれる)の送受信によっては、ＳＴＲ６０、ＳＴＲ対応ＣＤ機３０、ＳＴＲ対応ＭＤ機１と共に、そのメーカで規定した特定の機能を有するように動作することが可能とされるものである。
また、例えばＳＴＲ６０に対して、この同一メーカ機器１００から送信されてくるオーディオソースとしてのデータを選択して受信入力するようにマニュアル操作を行えば、これを音声としてモニタすることが可能である。また、ＳＴＲ対応ＭＤ機１において入力ソースとして、同一メーカ機器１００から送信されるオーディオデータが選択されるようにマニュアル操作を行えば、これをＭＤに記録することも可能とされる。この点については、次に説明する他社メーカ機器１１０も同様である。
【００２２】
他社メーカ機器１１０もまたＩＥＥＥ１３９４インターフェイスに対応した通信機能を有する何らかのデジタルＡＶ機器であるが、ＳＴＲ６０、ＳＴＲ対応ＣＤ機３０及びＳＴＲ対応ＭＤ機１とは製造メーカが異なる。ここでの他社メーカ機器１１０の実際としても、ＣＤプレーヤ、ＭＤレコーダ／プレーヤや、デジタルＶＴＲなどとされればよいものである。また、この他社メーカ機器１１０の場合には、原則として上記したＳＴＲ６０のメーカで規定するVender Dependent Commnandには対応不可となる。
【００２３】
なお、ここでは図示していないが、例えばこの図１に示す各ＡＶ機器としては、それぞれが商用交流電源から電力を入力するための電源コンセントが備えられる。もしくは、バッテリ駆動可能な構成であればバッテリを収納可能とされている。つまりは、各機器がそれぞれ独立して電力を得ることが可能とされているものである。
【００２４】
１−２．ＳＴＲ（フロントパネル）
続いて、上記図１に示したシステムを構成する上で主となる、ＳＴＲ６０と、このＳＴＲ６０とコンポーネント的システムを組むＳＴＲ対応ＣＤ機３０及びＳＴＲ対応ＭＤ機１の外観構成として、各々のフロントパネル部位について説明しておく。
【００２５】
図２はＳＴＲ６０本体のフロントパネル部位の様子を示している。
フロントパネル左下側には、電源キー１２０が設けられている。この電源キー１２０を操作することで、ＳＴＲ６０は、電源のオン／オフが切り換わるようにされている。なお、ここでいう電源がオフの状態とは、スタンバイ電源は動作しているいわゆるスタンバイ状態を指しているもので、例えば商用交流電源（又はバッテリ）の供給が絶たれている状態とは異なる。この点では、以降説明する、ＳＴＲ対応ＣＤ機３０とＳＴＲ対応ＭＤ機１についても同様とされる。
また、ここでの詳しい説明は省略するが、ＳＴＲ６０では、スリープ状態とするためのスリープモードも用意されていることで、省電力化が考慮されている。
【００２６】
また、電源キー１２０の左側にはヘッドフォンジャック２７ｊが設けられている。
【００２７】
フロントパネルのほぼ中央部には、表示部７５が配置されている。
この場合の表示部７５としては、主として文字表示を行うためのＦＬ管表示部７５Ａが設けられており、ここでは、１行１４文字分の表示が行われるようにされている。そして、その周囲にはセグメント表示部７５Ｂが設けられており、図示してはいないが所定の決められた内容がセグメントによって表示される。
【００２８】
表示部７５の左側にはディスプレイキー１２７が設けられ、さらにその左にはディマーキー１２８が設けられる。
ディスプレイキー１２７は、基本的には表示部７５における表示内容を変更するためのものとされる。ディマーキー１２８は、表示部７５、及びフロントパネルに実際に設けられるとされる装飾用ＬＥＤの輝度を調節するためのものである。
【００２９】
また、ＦＬ管表示部７５Ａの右側には、ジョグダイヤル１２５と、その上側にバンドキー１２１、チューナモードキー１２２、ジョグ選択キー１２３、エンターキー１２４が示される。
バンドキー１２１、チューナモードキー１２２は、ＳＴＲ６０のチューナ機能に関連するキーであり、それぞれ、受信バンド、チューナモードの切り換えを行うときに使用する。
また、ジョグ選択キー１２３は、メニュー選択を行うためのキーとされ、エンターキー１２４は決定操作を行うときに使用される。
そして、ジョグダイヤル１２５は、所定の操作手順のもとで上記各キーと共に併用されるもので、これによりユーザは実際の各種操作を行うことができる。
【００３０】
一例として、ジョグ選択キー１２３を１回押圧操作するごとに、ＦＬ管表示部７５Ａの表示内容は、FUNCTION→SOUND→SETUPのようにしてトグルで変化する。
そして例えば、ＦＬ管表示部７５ＡにFUNCTIONと表示させた状態でジョグダイヤル１２５を回転操作すると、ＳＴＲ６０が入力してモニタ音声として出力するソースの選択を変更していくことができるようになっている。このときのＦＬ管表示部７５Ａには、ジョグダイヤル１２５の回転操作に応じて現在選択されている入力ソース名が表示されるようになっている。この操作によっては、例えばチューナ音声、アナログ入力、及びＩＥＥＥ１３９４バスを介して入力される各ソース（機器）を所定順序に従って順次選択していくことが可能とされる。
なお、例えばバンドキー１２１、チューナモードキー１２２、ジョグ選択キー１２３、エンターキー１２４などのキーは、その背面側に装飾用のＬＥＤが設けられており、動作状態等に応じて点灯、点滅などするようにもされている。
【００３１】
ボリュームジョグ１２６は、ＳＴＲ６０から出力される音声信号レベル、つまり、例えばスピーカＳＰ（Ｌ）（Ｒ）から出力される音量を調整するためのダイヤルキーとして備えられる。
【００３２】
１−３．ＣＤ機（フロントパネル）
図３は、ＳＴＲ対応ＣＤ機３０のフロントパネル部位を示している。
先ず、このＳＴＲ対応ＣＤ機３０のフロントパネル左下側においても、電源オン／オフ（スタンバイ）のための電源キー１５０が設けられている。
【００３３】
また、このＳＴＲ対応ＣＤ機３０のフロントパネルの中央上部には、ＣＤを挿入／排出するためのディスク挿脱部１５９が設けられている。例えばディスク挿脱部１５９内に収納されて装填されている状態にあるＣＤを排出させるためには、このディスク挿脱部１５９の右側に配置されるイジェクトキー１５１を操作する。
【００３４】
上記ディスク挿脱部１５９の下側には、例えば１行１４文字分の表示が可能なＦＬ管表示部４７Ａと、セグメント表示部４７Ｂとから成る表示部４７が設けられている。この場合、ＦＬ管表示部４７Ａに対しては、例えば現在装填されているＣＤにて再生されるトラックのトラックナンバ、再生時間等の再生状況を示す情報や、ＣＤのサブコード内に挿入されているＣＤテキストデータなどが文字等として表示される。また、セグメント表示部４７Ｂには再生モードなどが示される。
ＦＬ管表示部４７Ａにおける表示内容の切り換えは、表示部４７の左側に配置されるディスプレイキー１５６を操作することによって行うことができる。また、輝度調整のためにはディマーキー１５７を操作する。
【００３５】
また、フロントパネル上の右側には、ＣＤの再生に関するキーとして、再生／一時停止キー１５２、停止キー１５３，頭出し・早送り／早戻しキー１５４，１５５が設けられている。
【００３６】
１−４．ＭＤ機（フロントパネル）
図４に、ＳＴＲ対応ＭＤ機１のフロントパネル部位を示す。
ここでも、ＳＴＲ対応ＭＤ機１のフロントパネル左下側においては電源キー１３０が設けられている。
【００３７】
そしてフロントパネルの中央上部には、ＭＤを挿入／排出するためのディスク挿脱部１４５が設けられており、この場合にも、その右側にはＭＤを排出させるためのイジェクトキー１３１が配置される。
【００３８】
またここでも、上記ディスク挿脱部１４５の下側には、例えば１行１４文字表示が可能なＦＬ管表示部２４Ａとセグメント表示部２４Ｂとから成る表示部２４が設けられている。この場合、ＦＬ管表示部２４Ａに対しては、例えば現在装填されているＭＤに対して記録又は再生されるトラックのトラックナンバ、記録又は再生時間等の記録再生状況を示す情報が表示される。さらには、ＭＤのディスクタイトルやトラックネームなども表示される。また、この場合にもセグメント表示部２４Ｂには再生モードなどが示される。
さらに、このＳＴＲ対応ＭＤ機１においても表示内容を切り換えるためのディスプレイキー１５６、及び輝度調整のためのディマーキー１５７が設けられる。
【００３９】
また、フロントパネルの右側に配置される記録再生に関するキーとして、この場合には、再生／一時停止キー１３２、停止キー１３３，頭出し・早送り／早戻しキー１３４，１３５、録音キー１３６、高速ダビングキー１３７、シンクロ録音キー１３８が設けられる。
また、入力選択キー１３９は、録音ソースとしての入力を選択するために設けられている。この入力選択キー１３９の操作に応じて、例えばＦＬ管表示部２４Ａにおいては、現在選択されている録音ソース名が表示されるようになっている。
【００４０】
ここで、上記図２〜図４に示すフロントパネルの様子からも分かるように、ＳＴＲ６０、ＳＴＲ対応ＣＤ機３０、及びＳＴＲ対応ＭＤ機１は、それぞれが、自機のための表示部７５，４７，２４を有している。換言すれば、例えばＳＴＲ及びＳＴＲ対応機器から成るシステムを、１つのオーディオコンポーネントシステムとして考えた場合、このコンポーネントシステムとして統合された表示部位というものは設けられてはいないことになる。これは、例えばＩＥＥＥ１３９４を介して接続される機器としては、本来、個々に独立した存在であることに対応している。
【００４１】
１−５．ＳＴＲ（内部）
続いて、ＳＴＲ６０、ＳＴＲ対応ＣＤ機３０、及びＳＴＲ対応ＭＤ機１の各内部構成について説明を行っていくこととする。
【００４２】
先ず、図５のブロック図にはＳＴＲ６０の内部構成例が示されている。
ＳＴＲ６０においては、オーディオソースとして、ＩＥＥＥ１３９４バス１１６を介して送信されてくるオーディオ信号と、自身が備えるチューナのオーディオ信号と、アナログ入力端子７８から入力される外部アナログオーディオ信号との３種を入力可能とされる。
【００４３】
ＩＥＥＥ１３９４インターフェイス６１は、ＩＥＥＥ１３９４バス１１６を介して他の外部機器とデータの送受信を行うために設けられる。これにより、ＳＴＲ６０としては、外部とのＡＶデータの送受信、及び各種コマンドの送受信が可能に構成されることとなる。
ＩＥＥＥ１３９４インターフェイス６１では、ＩＥＥＥ１３９４バス１１６を介して受信したパケットを復調し、復調したパケットに含まれるデータを抽出する。そしてこの抽出したデータを内部データ通信に適合するフォーマットのデータに変換して出力する。
例えばＩＥＥＥ１３９４バス１１６を介して他のＡＶ機器からオーディオデータが送信されてくるとする。ＩＥＥＥ１３９４インターフェイス６１では、この送信されてきたオーディオデータを受信して、上記パケットに対する復調処理を行い、この場合には例えばＩＥＣ９５８といわれるデジタルオーディオデータインターフェイスのデータフォーマットに変換して復調処理部６３に対して出力する。
【００４４】
復調処理部６３においては、入力されたオーディオデータについて、例えばＩＥＣ９５８フォーマットに従った所要の復調処理を施してデジタルフィルタ６４に出力する。
【００４５】
デジタルフィルタ６４は、主としては、例えば入力されたオーディオデータについてのジッター除去を行う機能を有している。また、復調処理部６３から出力されるデータとしては、送信元の機器等の相違に応じて、異なるサンプリング周波数を有しているものであるが、このデジタルフィルタ６４においては、これらの異なるサンプリングレートを有するオーディオデータについて、４４．１ＫＨｚのサンプリング周波数に変換して出力することも行っている。
このようにして４４．１ＫＨｚのサンプリング周波数による信号フォーマットに変換されたオーディオデータは、ＤＳＰ(Digital Signal Processor)６５に対して入力される。
なお、例えば送信元から４４．１ＫＨｚのサンプリング周波数による信号フォーマットによるオーディオデータが送信されてくる場合には、上記復調処理部６３、デジタルフィルタ６４を介することなく、ＩＥＥＥ１３９４インターフェイス６１から直接的にＤＳＰ６５に対してオーディオデータを送信するようにもされる。
【００４６】
ＤＳＰ６５においては、オーディオデータに対して各種所要の信号処理を施す。例えば、イコライザ設定に従ったイコライジング処理等もここで実行される。そして信号処理が施されたオーディオデータをＡ／Ｄ・Ｄ／Ａ部６６のデジタルフィルタ６９に対して出力する。
【００４７】
Ａ／Ｄ・Ｄ／Ａ部６６は、オーディオ信号についてのアナログ−デジタル変換処理、及びデジタル−アナログ変換処理を行うための回路部位である。
このＡ／Ｄ・Ｄ／Ａ部６６のデジタルフィルタ６９に入力されたオーディオデータは、Ｄ／Ａコンバータ６８に入力されることで電圧パルス列としての信号に変換される。そして、Ｉ−ＤＡＣコンバータ８１に対して入力される。
Ｉ−ＤＡＣコンバータ８１では、入力された電圧パルス列を電流に変換する。
ここで、図示は省略しているが、基準となるレベルが別系統で与えられており、その基準レベルを操作することで、出力電流を可変することが可能とされており、これを例えば４０ｄＢ以下のレベル範囲でのボリューム調整に利用することもできるようになっている。
【００４８】
アンプ８２では、Ｉ−ＤＡＣコンバータ８１の出力について増幅を行ってスピーカ出力端子８３に対して出力する。そして、このスピーカ出力端子８３にスピーカＳＰ（Ｌ）（Ｒ）が接続されていれば、ステレオ音声としての出力が行われることになる。
【００４９】
チューナ部７７は、ＳＴＲ６０内に備えられており、アンテナ７６にて受信されたラジオ放送の電波について、選局及び復調処理等を行って例えばアナログ音声信号としてセレクタ７９に出力する。
また、アナログオーディオ信号入力端子７８を介して入力されるアナログ音声信号もまたセレクタ７９に対して入力される。
【００５０】
セレクタ７９では、例えばシステムコントローラ７０の制御に応じて、チューナ部７７とアナログオーディオ信号入力端子７８の何れかを入力ソースとして選択して、選択したアナログオーディオ信号をＡ／Ｄ・Ｄ／Ａ部６６のＡ／Ｄコンバータ６７に対して供給する。Ａ／Ｄコンバータ６７では入力されてきたアナログオーディオ信号をデジタルオーディオデータに変換する。
【００５１】
ここで、Ａ／Ｄコンバータ６７にて得られたデジタルオーディオデータをモニタ音声として出力する場合には、先に述べた、Ｄ／Ａコンバータ６８→Ｉ−ＤＡＣコンバータ８１→アンプ８２の処理を経てスピーカＳＰ（Ｌ）（Ｒ）に対して出力するようにされる。
また、例えば録音などのために、Ａ／Ｄコンバータ６７にて得られたデジタルオーディオデータをＩＥＥＥ１３９４バス１１６を介して他のＡＶ機器に送信出力する必要のある場合には、このデジタルオーディオデータを変調処理部８０に対して出力する。
変調処理部８０では、例えばＩＥＣ９５８などのデジタルオーディオデータインターフェイスのフォーマットに適合する変調処理を施してＩＥＥＥ１３９４インターフェイス６１に対して出力する。ＩＥＥＥ１３９４インターフェイス６１では、例えばＲＡＭ６２を利用して、パケット化をはじめとする所要の処理を施して、ＩＥＥＥ１３９４フォーマットに適合するフォーマットに変換する。そして、ＩＥＥＥ１３９４バス１１６を介して、目的の機器に対して送信出力を行う。
【００５２】
システムコントローラ７０は、例えばＣＰＵ(Central Processing Unit)、ＲＯＭ７１、ＲＡＭ７２などを備えて構成され、ＳＴＲ６０についての各種動作制御を実行する。
【００５３】
また、システムコントローラ７０に対しては、受信部７３及び操作部７４からの情報が入力されるようになっている。例えば受信部７３においては、リモートコントローラＲＭから送信されてきた無線のコマンド信号を受信し、この受信したコマンド信号をシステムコントローラ７０に対して出力する。
操作部７４は、例えばフロントパネルに設けられている各種キーより成るものとされ、この操作部７４に対して行われた操作に応じた操作情報がシステムコントローラ７０に対して出力される。
システムコントローラ７０では、上記のようにして入力されてくるコマンド信号及び操作情報に応答した所要の動作が得られるように、各種制御処理を実行する。
また、システムコントローラ７５は、例えば上記したコマンド信号及び操作情報や、現在の動作状況等に応じた所要の内容の表示が行われるように、表示部７５に対する表示制御も実行する。この表示部７５は、前述もしたように、例えばＦＬ管表示部とセグメント表示部とを備えている。
【００５４】
１−６．ＣＤ機（内部）
次にＳＴＲ対応ＣＤ機３０の内部構成について図６のブロック図を参照して説明する。
周知のように再生専用のディスクメディアであるＣＤ９１は、前述した本体フロントパネルのディスク挿脱部１５９から挿入されることで、再生可能位置に装填される。
再生可能位置に装填されたＣＤ９１は、ＣＤ再生動作時においてスピンドルモータ３１によって一定線速度（ＣＬＶ）で回転駆動される。そして光学ヘッド３２によってＣＤ９１にピット形態で記録されているデータが読み出され、ＲＦアンプ３５に供給される。光学ヘッド３２において対物レンズ３２ａは２軸機構３３によって保持され、トラッキング及びフォーカス方向に変位可能とされる。
また光学ヘッド３２はスレッド機構３４によってＣＤ９１の半径方向に移動可能とされる。
【００５５】
ＲＦアンプ３５では再生ＲＦ信号のほか、フォーカスエラー信号、トラッキングエラー信号を生成し、これらのエラー信号はサーボ回路３６に供給される。
サーボ回路３６はフォーカスエラー信号、トラッキングエラー信号から、フォーカス駆動信号、トラッキング駆動信号、スレッド駆動信号等の各種駆動信号を生成し、２軸機構３３、及びスレッド機構３４の動作を制御する。つまり、フォーカスサーボ制御及びトラッキングサーボ制御を実行する。
また、ＲＦアンプ３５において二値化された再生ＲＦ信号は、タイミングジェネレータ４２に対しても出力されており、タイミングジェネレータ４２においては、この再生ＲＦ信号の波形タイミングに基づいて、タイミング信号を生成してＣＬＶプロセッサ４３に対して出力する。ＣＬＶプロセッサ４３では、入力されたタイミング信号に基づいて、スピンドルモータ３１を所要のＣＬＶ速度により回転制御するための駆動信号を生成してスピンドルモータに供給する。これにより、ＣＤ９１をＣＬＶにより回転駆動するためのスピンドルサーボ制御が実行される。
【００５６】
再生ＲＦ信号はデコーダ３７に供給される。デコーダ３７では先ず入力された再生ＲＦ信号について二値化を行ってＥＦＭ信号を得る。そして、このＥＦＭ信号についてＥＦＭ復調，ＣＩＲＣデコード等を行なってＣＤ９１から読み取られた情報を１６ビット量子化、44.1KHz サンプリングのフォーマットのオーディオデータにデコードする。
【００５７】
またデコーダ３７ではサブコード等の制御データも抽出可能な構成を採っている。サブコードとしてのデータ部分は、サブコードプロセッサ４４に供給され、ここでサブコードとしての適正なデータに整えられる。また、特にＣＤのリードインエリアに記録されているサブコードのサブＱデータとして記録されているＴＯＣ(Table Of Contents)情報を抽出することも行われる。これらのサブコードデータ、ＴＯＣはシステムコントローラ５０に供給されることで、例えば各種制御に用いられる。システムコントローラ５０は、このＣＤ機としての所要の各種動作が実行されるように各種制御処理を実行する。
【００５８】
また、ＲＦアンプ３５にて二値化された再生ＲＦ信号は、ＰＬＬ回路３９に対しても供給される。
ＰＬＬ回路３９は、入力されたＥＦＭ信号のチャンネルビットに同期したクロックを出力する。このクロックの周波数としては、定常の１倍速では４．３２１８ＭＨｚとされる。そして、このクロックは、例えばデコーダ３７以降の信号処理回路系のクロックとして利用される。
【００５９】
この場合、デコーダ３７から出力されるオーディオデータは、Ｄ／Ａコンバータ３８及びＩＥＥＥ１３９４インターフェイス４９に対して分岐して出力される。
Ｄ／Ａコンバータ３８に入力されたオーディオデータはアナログオーディオ信号に変換され、アンプ４０を介して外部アナログオーディオ出力端子４１に対して出力されるようになっている。
また、デコーダ３７からＩＥＥＥ１３９４インターフェイス４９に入力されるオーディオデータは、ＩＥＥＥ１３９４のフォーマットに適合するデータに変換され、ＩＥＥＥ１３９４バス１１６を介して外部機器に対して送信出力される。
また、ＩＥＥＥ１３９４インターフェイス４９では、外部から送信されてくるコマンド等のデータを受信することも行う。そして、例えばシステムコントローラ５０は、この受信されたコマンドの内容に応じて適宜所要の処理を実行する。
【００６０】
ＣＤ９１の再生時には、ＣＤ９１に記録されている管理情報、即ちＴＯＣを読み出す必要がある。システムコントローラ５０はこの管理情報に応じてＣＤ９１に収録されたトラック数、各トラックのアドレスなどを判別し、再生動作制御を行うことになる。このためシステムコントローラ５０はＣＤ９１が装填された際にＴＯＣが記録されたディスクの最内周側（リードインエリア）の再生動作を実行させることによって読み出し、前述のようにしてＴＯＣ情報を抽出する。そして、このＴＯＣを例えばワークＲＡＭ５２に記憶させておき、以後そのＣＤ９１に対する再生動作の際に参照できるようにしている。
【００６１】
システムコントローラ５０は、ＣＰＵ、内部インターフェース部等を備えたマイクロコンピュータとされ、上述してきた各種動作の制御を行う。
また、プログラムＲＯＭ２８には、このＳＴＲ対応ＣＤ機３０における各種動作を実現するためのプログラム等が格納され、ワークＲＡＭ２９には、システムコントローラ１１が各種処理を実行するのに必要なデータやプログラム等が適宜保持される。
【００６２】
ところで周知のように、ＣＤの規格として、サブコードにはテキストデータを挿入することが可能とされ、例えばディスクタイトルやトラックネームなどに利用することができるようにされている。
そして、本実施の形態のＳＴＲ対応ＣＤ機３０は、このＣＤのテキストデータに対応している。つまり、ＣＤのサブコード内のテキストデータに基づいての文字表示を表示部４７に対して行うことができる。
このために、本実施の形態のＳＴＲ対応ＣＤ機３０にはＣＤテキストデコーダ４５及びＣＤテキストメモリ４６が備えられる。
例えばサブコードプロセッサ４４にて得られたサブコードデータは、ＣＤテキストデコーダ４５に対して入力されるようにもなっている。そして、ＣＤテキストデコーダ４５においては、入力されたサブコードデータにＣＤテキストデータが挿入されているのであればデコード処理を施してテキストデータを得るようにされる。このようにして得られたテキストデータは、システムコントローラ５０の制御によってＣＤテキストメモリ４６に対して記憶される。
以降、システムコントローラ５０は、必要に応じてＣＤテキストメモリ４６からテキストデータの読み出しを行い、表示部４７のＦＬ管表示部にて、そのテキストデータが文字として表示されるように制御処理を実行する。
【００６３】
操作部４８は、本体フロントパネルに設けられている各種キーより成るものとされる。なお、ここでは図示していないが、操作部４８としては、例えば赤外線リモートコマンダーによる遠隔操作機能が付加されてもよい。
【００６４】
また表示部４７ではＣＤ９１の再生時などに所要の表示動作が行なわれる。例えば総演奏時間、再生や録音時の進行時間などの時間情報や、トラックナンバ、ＣＤのディスクネームやトラックネームなどのネーム情報、動作状態、動作モードなどの各種の表示がシステムコントローラ５０の制御に基づいて行なわれる。
この表示部４７も、前述したように、ＦＬ管表示部とセグメント表示部とを備える。
【００６５】
１−７．ＭＤ機（内部）
図７のブロック図は、ＭＤレコーダ／プレーヤであるＳＴＲ対応ＭＤ機１の内部構成を示している。
オーディオデータが記録再生される光磁気ディスク（ミニディスク）９０は、スピンドルモータ２により回転駆動される。そして光磁気ディスク９０に対しては記録／再生時に光学ヘッド３によってレーザ光が照射される。
【００６６】
光学ヘッド３は、記録時には記録トラックをキュリー温度まで加熱するための高レベルのレーザ出力を行ない、また再生時には磁気カー効果により反射光からデータを検出するための比較的低レベルのレーザ出力を行なう。
このため、光学ヘッド３にはレーザ出力手段としてのレーザダイオード、偏光ビームスプリッタや対物レンズ等からなる光学系、及び反射光を検出するためのディテクタ等が搭載されている。対物レンズ３ａは２軸機構４によってディスク半径方向及びディスクに接離する方向に変位可能に保持されている。
【００６７】
また、ディスク９０を挟んで光学ヘッド３と対向する位置に磁気ヘッド６ａが配置されている。磁気ヘッド６ａは供給されたデータによって変調された磁界を光磁気ディスク９０に印加する動作を行なう。
光学ヘッド３全体及び磁気ヘッド６ａは、スレッド機構５によりディスク半径方向に移動可能とされている。
【００６８】
再生動作によって、光学ヘッド３によりディスク９０から検出された情報はＲＦアンプ７に供給される。ＲＦアンプ７は供給された情報の演算処理により、再生ＲＦ信号、トラッキングエラー信号ＴＥ、フォーカスエラー信号ＦＥ、グルーブ情報（光磁気ディスク９０にプリグルーブ（ウォブリンググルーブ）として記録されている絶対位置情報）ＧＦＭ等を抽出する。
抽出された再生ＲＦ信号はエンコーダ／デコーダ部８に供給される。また、トラッキングエラー信号ＴＥ、フォーカスエラー信号ＦＥはサーボ回路９に供給され、グルーブ情報ＧＦＭはアドレスデコーダ１０に供給される。
【００６９】
サーボ回路９は供給されたトラッキングエラー信号ＴＥ、フォーカスエラー信号ＦＥや、マイクロコンピュータにより構成されるシステムコントローラ１１からのトラックジャンプ指令、アクセス指令、スピンドルモータ２の回転速度検出情報等により各種サーボ駆動信号を発生させ、２軸機構４及びスレッド機構５を制御してフォーカス及びトラッキング制御を行ない、またスピンドルモータ２を一定線速度（ＣＬＶ）に制御する。
【００７０】
アドレスデコーダ１０は供給されたグルーブ情報ＧＦＭをデコードしてアドレス情報を抽出する。このアドレス情報はシステムコントローラ１１に供給され、各種の制御動作に用いられる。
また再生ＲＦ信号についてはエンコーダ／デコーダ部８においてＥＦＭ復調、ＣＩＲＣ等のデコード処理が行なわれるが、このときアドレス、サブコードデータなども抽出され、システムコントローラ１１に供給される。
【００７１】
エンコーダ／デコーダ部８でＥＦＭ復調、ＣＩＲＣ等のデコード処理されたオーディオデータ（セクターデータ）は、メモリコントローラ１２によって一旦バッファメモリ１３に書き込まれる。なお、光学ヘッド３によるディスク９０からのデータの読み取り及び光学ヘッド３からバッファメモリ１３までの系における再生データの転送は1.41Mbit/secで、しかも通常は間欠的に行なわれる。
【００７２】
バッファメモリ１３に書き込まれたデータは、再生データの転送が0.3Mbit/sec となるタイミングで読み出され、エンコーダ／デコーダ部１４に供給される。そして、音声圧縮処理に対するデコード処理等の再生信号処理を施され、４４．１ＫＨZ サンプリング、１６ビット量子化のデジタルオーディオ信号とされる。このデジタルオーディオ信号はＤ／Ａ変換器１５によってアナログ信号とされ、出力処理部１６でレベル調整、インピーダンス調整等が行われてライン出力端子１７からアナログオーディオ信号Ａｏｕｔとして外部機器に対して出力される。またヘッドホン出力ＨＰｏｕｔとしてヘッドホン出力端子２７に供給され、接続されるヘッドホンに出力される。
【００７３】
また、エンコーダ／デコーダ部１４でデコードされた状態のデジタルオーディオ信号は、デジタルインターフェース部２２に供給されることで、デジタル出力端子２１からデジタルオーディオデータＤｏｕｔとして外部機器に出力することもできる。例えば光ケーブルによる伝送形態で外部機器に出力される。
【００７４】
光磁気ディスク９０に対して記録動作が実行される際には、ライン入力端子１８に供給されるアナログオーディオ信号Ａｉｎは、Ａ／Ｄ変換器１９によってデジタルオーディオデータに変換された後、エンコーダ／デコーダ部１４に供給され、音声圧縮エンコード処理を施される。
または外部機器からデジタル入力端子２０にデジタルオーディオデータＤｉｎが供給された場合は、デジタルインターフェース部２２で制御コード等の抽出が行われるとともに、そのデジタルオーディオデータがエンコーダ／デコーダ部１４に供給され、音声圧縮エンコード処理を施される。
なお図示していないがマイクロホン入力端子を設け、マイクロホン入力を記録信号として用いることも当然可能である。
【００７５】
エンコーダ／デコーダ部１４によって圧縮された記録データはメモリコントローラ１２によって一旦バッファメモリ１３に書き込まれて蓄積されていった後、所定量のデータ単位毎に読み出されてエンコーダ／デコーダ部８に送られる。そしてエンコーダ／デコーダ部８でＣＩＲＣエンコード、ＥＦＭ変調等のエンコード処理された後、磁気ヘッド駆動回路６に供給される。
【００７６】
磁気ヘッド駆動回路６はエンコード処理された記録データに応じて、磁気ヘッド６ａに磁気ヘッド駆動信号を供給する。つまり、光磁気ディスク９０に対して磁気ヘッド６ａによるＮ又はＳの磁界印加を実行させる。また、このときシステムコントローラ１１は光学ヘッドに対して、記録レベルのレーザ光を出力するように制御信号を供給する。
【００７７】
この操作部２３もまた、例えば本体フロントパネルに設けられた各種キーより成るものとされる。この操作部２３に対して行われた操作により出力される操作情報はシステムコントローラ１１に入力され、システムコントローラ１１は操作情報に応じた動作制御を実行することになる。
【００７８】
なお、周知のようにＭＤに対応する記録再生装置では、トラック（プログラム）分割、トラック連結、トラック消去、トラックネーム入力、ディスクネーム入力などのプログラム編集を行うことができるようになっているが、これらの操作は比較的煩雑でもあるため、例えば図示しないリモートコントローラから送信される操作コマンド信号を受信可能な構成を設けるようにすることが実際としては好ましく、このようにすれば、上記したような各種プログラム編集に関する操作をリモートコントローラに設けられているキーに対する操作によって行うようにすることが可能になる。
【００７９】
表示部２４の表示動作はシステムコントローラ１１によって制御される。
即ちシステムコントローラ１１は表示動作を実行させる際に表示すべきデータを表示部２４内の表示ドライバに送信する。表示ドライバは供給されたデータに基づいて液晶パネルなどによるディスプレイの表示動作を駆動し、所要の数字、文字、記号などの表示を実行させる。
表示部２４においては、記録／再生しているディスクの動作モード状態、トラックナンバ、記録時間／再生時間、編集動作状態等が示される。
またディスク９０には主データたるプログラムに付随して管理される文字情報（トラックネーム等）が記録できるが、その文字情報の入力の際の入力文字の表示や、ディスクから読み出した文字情報の表示などが実行される。
さらに本実施の形態の場合、ディスク９０には、プログラムとしての楽曲等のデータとは独立したデータファイルとなる副データ（ＡＵＸデータ）を記録することも可能とされる。
ＡＵＸデータとしてのデータファイルは、文字、静止画などの情報となるが、これらの文字や静止画は表示部２４により表示出力可能とされる。
【００８０】
本実施の形態では、ＡＵＸデータである静止画及び文字を表示部２４に表示させるための構成として、ＪＰＥＧデコーダ２６が備えられる。
即ち、本実施の形態においては、ＡＵＸデータとしてのデータファイルである静止画データは、ＪＰＥＧ(Joint Photographic Coding Experts Group)方式により圧縮されたファイル形式で記録される。ＪＰＥＧデコーダ２６では、ディスク９０にて再生されて例えばバッファメモリ１３に蓄積された静止画データのファイルをメモリコントローラ１２を介して入力し、ＪＰＥＧ方式に従った伸張処理を施して表示部２４に出力する。これにより、ＡＵＸデータである静止画データが表示部２４にて表示されることになる。
なお、この場合の表示部２４としても、先に述べたように、ＦＬ管表示部とセグメント表示部を備えて成るものである。
【００８１】
システムコントローラ１１は、ＣＰＵ、内部インターフェース部等を備えたマイクロコンピュータとされ、上述してきた各種動作の制御を行う。
また、プログラムＲＯＭ２８には、当該記録再生装置における各種動作を実現するためのプログラム等が格納され、ワークＲＡＭ２９には、システムコントローラ１１が各種処理を実行するのに必要なデータやプログラム等が適宜保持される。
【００８２】
ところで、ディスク９０に対して記録／再生動作を行なう際には、ディスク９０に記録されている管理情報、即ちＰ−ＴＯＣ（プリマスタードＴＯＣ）、Ｕ−ＴＯＣ（ユーザーＴＯＣ）を読み出す必要がある。システムコントローラ１１はこれらの管理情報に応じてディスク９０上の記録すべきエリアのアドレスや、再生すべきエリアのアドレスを判別することとなる。
この管理情報はバッファメモリ１３に保持される。
そして、システムコントローラ１１はこれらの管理情報を、ディスク９０が装填された際に管理情報の記録されたディスクの最内周側の再生動作を実行させることによって読み出し、バッファメモリ１３に記憶しておき、以後そのディスク９０に対するプログラムの記録／再生／編集動作の際に参照できるようにしている。
【００８３】
また、Ｕ−ＴＯＣはプログラムデータの記録や各種編集処理に応じて書き換えられるものであるが、システムコントローラ１１は記録／編集動作のたびに、Ｕ−ＴＯＣ更新処理をバッファメモリ１３に記憶されたＵ−ＴＯＣ情報に対して行ない、その書換動作に応じて所定のタイミングでディスク９０のＵ−ＴＯＣエリアについても書き換えるようにしている。
【００８４】
またディスク９０にはプログラムとは別にＡＵＸデータファイルが記録されるが、そのＡＵＸデータファイルの管理のためにディスク９０上にはＡＵＸ−ＴＯＣが形成される。
システムコントローラ１１はＵ−ＴＯＣの読出の際にＡＵＸ−ＴＯＣの読出も行い、バッファメモリ１３に格納して必要時にＡＵＸデータの管理状態を参照できるようにしている。
またシステムコントローラ１１は必要に応じて所定タイミングで（もしくはＡＵＸ−ＴＯＣの読出の際に同時に）ＡＵＸデータファイルを読み込み、バッファメモリ１３に格納する。そしてＡＵＸ−ＴＯＣで管理される出力タイミングに応じて表示部２４や、ＩＥＥＥ１３９４インターフェイス２５を介した外部機器における文字や画像の出力動作を実行させる。
【００８５】
ＩＥＥＥ１３９４インターフェイス２５によっては、オーディオデータの送受信が可能とされている。つまり、本実施の形態のＭＤレコーダ／プレーヤにあっては、ＩＥＥＥ１３９４バス１１６を介して送信されてきたオーディオデータをＩＥＥＥ１３９４インターフェイス２５により受信し、この受信したオーディオデータをディスク９０に対して記録することができるようになっている。
ここで、送信されてきたオーディオデータが例えば、サンプリング周波数４４．１ＫＨｚ、量子化ビット１６ビットのフォーマットであれば、システムコントローラ１１を介するようにして、エンコーダ／デコーダ部１４に転送して、データ圧縮処理を施すようにされる。
これに対して、送信されてきたオーディオデータが、当該ＭＤレコーダ／プレーヤに適合した方式によって圧縮処理された圧縮オーディオデータであるとすれば、システムコントローラ１１を介するようにして、メモリコントローラ１２に転送するようにされる。なお、当然のこととして、このＩＥＥＥ１３９４インターフェイス２５によってもコマンドの送受信が可能とされ、例えばシステムコントローラ１１は、受信したコマンドの内容に応じて所要の処理を実行する。
【００８６】
２．ＩＥＥＥ１３９４による本実施の形態のデータ通信
２−１．概要
以降、本実施の形態としてのＩＥＥＥ１３９４規格に従ったデータ通信について説明する。
【００８７】
ＩＥＥＥ１３９４は、シリアルデータ通信の規格の１つとされる。
このＩＥＥＥ１３９４によるデータ伝送方式としては、周期的に通信を行うＩｓｏｃｈｒｏｎｏｕｓ通信方式と、この周期と関係なく非同期で通信するＡｓｙｎｃｈｒｏｎｏｕｓ通信方式が存在する。一般に、Ｉｓｏｃｈｒｏｎｏｕｓ通信方式はデータの送受信に用いられ、Ａｓｙｎｃｈｒｏｎｏｕｓ通信方式は各種制御コマンドの送受信に用いられる。そして、１本のケーブルを使用して、これら２種類の通信方式によって送受信を行うことが出来るようにされている。
そこで以降、上記したＩＥＥＥ１３９４規格による本実施の形態の送信形態を前提として、本実施の形態としての説明を行っていくこととする。
【００８８】
２−２．スタックモデル
図８は、本実施の形態が対応するＩＥＥＥ１３９４のスタックモデルを示している。
ＩＥＥＥ１３９４フォーマットにおいては、Ａｓｙｎｃｈｒｏｎｏｕｓ系（４００）とＩｓｏｃｈｒｏｎｏｕｓ系（５００）とに大別される。
ここで、Ａｓｙｎｃｈｒｏｎｏｕｓ系（４００）とＩｓｏｃｈｒｏｎｏｕｓ系（５００）に共通な層として、最下位にＰｈｙｓｉｃａｌ Ｌａｙｅｒ（３０１）（物理層）が設けられ、その上位にＬｉｎｋ Ｌａｙｅｒ（３０２）（リンク層）が設けられる。Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ（３０１）はハードウェア的な信号伝送を司るためのレイヤであり、Ｌｉｎｋ Ｌａｙｅｒ（３０２）はＩＥＥＥ１３９４バスを例えば、機器毎に規定された内部バスに変換するための機能を有する層とされる。
【００８９】
Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ（３０１）、Ｌｉｎｋ Ｌａｙｅｒ（３０２）、及び次に説明するＴｒａｎｓａｃｔｉｏｎ Ｌａｙｅｒ（４０１）は、Ｅｖｅｎｔ／Ｃｏｎｔｒｏｌ／ＣｏｎｆｉｇｕｒａｔｉｏｎのラインによってＳｅｒｉａｌ Ｂｕｓ Ｍａｎａｇｅｍｅｎｔ３０３とリンクされる。
また、ＡＶ Ｃａｂｌｅ／Ｃｏｎｎｅｃｔｏｒ３０４は、ＡＶデータ伝送のための物理的なコネクタ、ケーブルを示している。
【００９０】
Ａｓｙｎｃｈｒｏｎｏｕｓ系（４００）における上記Ｌｉｎｋ Ｌａｙｅｒ（３０２）の上位には、Ｔｒａｎｓａｃｔｉｏｎ Ｌａｙｅｒ（４０１）が設けられる。Ｔｒａｎｓａｃｔｉｏｎ Ｌａｙｅｒ（４０１）は、ＩＥＥＥ１３９４としてのデータ伝送プロトコルを規定する層とされ、基本的なＡｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓａｃｔｉｏｎとしては、後述するようにして、Ｗｒｉｔｅ Ｔｒａｎｓａｃｔｉｏｎ，Ｒｅａｄ Ｔｒａｎｓａｃｔｉｏｎ，Ｌｏｃｋ Ｔｒａｎｓａｃｔｉｏｎが規定される。
【００９１】
そして、Ｔｒａｎｓａｃｔｉｏｎ Ｌａｙｅｒ（４０１）の上層に対してＦＣＰ(Function Control Protocol)（４０２）が規定される。ＦＣＰ（４０２）は、ＡＶ／Ｃ Ｃｏｍｍａｎｄ(AV/C Digital Interface 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 Contorol Register)によって確立される。
図１８（ａ）は、ｏＰＣＲ［ｎ］（出力用プラグコントロールレジスタ）の構造を示し、図１８（ｂ）は、ｉＰＣＲ［ｎ］（入力用プラグコントロールレジスタ）の構造を示している。これらｏＰＣＲ［ｎ］、ｉＰＣＲ［ｎ］のサイズは共に３２ビットとされている。
図１８（ａ）のｏＰＣＲにおいては、例えば上位１ビットのｏｎ−ｌｉｎｅに対して‘１’が格納されていると、ｂｒｏａｄｃａｓｔ ｃｏｎｎｅｃｔｉｏｎによる送信であることが示され、‘０’が格納されていると、上位１１ビット目から６ビットの領域のｃｈａｎｎｅｌ ｎｕｍｂｅｒで示されるチャンネルにより、ｐｏｉｎｔ ｔｏ ｐｏｉｎｔ ｃｏｎｎｅｃｔｉｏｎで送信することが示される。
また、図１８（ｂ）のｉＰＣＲにおいても、例えば上位１ビットのｏｎ−ｌｉｎｅに対して‘１’が格納されていれば、ｂｒｏａｄｃａｓｔ ｃｏｎｎｅｃｔｉｏｎによる受信であることが示され、‘０’が格納されていると、上位１１ビット目から６ビットの領域のｃｈａｎｎｅｌ ｎｕｍｂｅｒで示されるチャンネルにより送信されたデータをｐｏｉｎｔ ｔｏ ｐｏｉｎｔ ｃｏｎｎｅｃｔｉｏｎで送信することが示される。
【０１３０】
そして、図１８（ａ）のｏＰＣＲ、及び図１８（ｂ）のｉＰＣＲにおけるｂｒｏａｄｃａｓｔ ｃｏｎｎｅｃｔｉｏｎ ｃｏｕｎｔｅｒには、ｂｒｏａｄｃａｓｔ ｃｏｎｎｅｃｔｉｏｎによる送信／受信とされる場合において、ｂｒｏａｄｃａｓｔ ｃｏｎｎｅｃｔｉｏｎを張っているノード数が格納される。
また、図１８（ａ）のｏＰＣＲ、及び図１８（ｂ）のｉＰＣＲにおけるｐｏｉｎｔ ｔｏ ｐｏｉｎｔ ｃｏｎｎｅｃｔｉｏｎ ｃｏｕｎｔｅｒには、ｐｏｉｎｔ ｔｏ ｐｏｉｎｔ ｃｏｎｎｅｃｔｉｏｎによる送信／受信とされる場合において、ｐｏｉｎｔ ｔｏ ｐｏｉｎｔを張っているノード数が示される。
【０１３１】
２−１０．ＦＣＰにおけるコマンド及びレスポンス
Ａｓｙｎｃｈｒｏｎｏｕｓ通信によるデータの伝送は、図８に示したＦＣＰ（４０２）によって規定されることになる。そこで、ここでは、ＦＣＰにより規定されるトランザクションについて説明する。
【０１３２】
ＦＣＰとしては、Ａｓｙｎｃｈｒｏｎｏｕｓ通信において規定されるＷｒｉｔｅ Ｔｒａｎｓａｃｔｉｏｎ（図１４参照）を使用する。従って、本実施の形態におけるＡＵＸデータの伝送も、このＦＣＰにより、Ａｓｙｎｃｈｒｏｎｏｕｓ通信の中のＷｒｉｔｅ Ｔｒａｎｓａｃｔｉｏｎを使用することで行われるものである。
ＦＣＰをサポートする機器は、Ｃｏｍｍａｎｄ／Ｒｅｓｐｏｎｃｅレジスタを備え、次に図１９により説明するようにしてＣｏｍｍａｎｄ／Ｒｅｓｐｏｎｃｅレジスタに対してＭｅｓｓａｇｅを書き込むことでトランザクションを実現する。
【０１３３】
図１９の処理遷移図においては、先ずＣＯＭＭＡＮＤ送信のための処理として、ステップＳ２１として示すように、ＣｏｎｔｒｏｌｌｅｒがＴｒａｎｓａｃｔｉｏｎ Ｒｅｑｕｅｓｔを発生して、Ｗｒｉｔｅ Ｒｅｑｕｅｓｔ ＰａｃｋｅｔをＴａｒｇｅｔに対して送信する処理を実行する。Ｔａｒｇｅｔでは、ステップＳ２２として、このＷｒｉｔｅ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔを受信して、Ｃｏｍｍａｎｄ／Ｒｅｓｐｏｎｃｅレジスタに対してデータの書き込みを行う。また、この際、ＴａｒｇｅｔからはＣｏｎｔｒｏｌｌｅｒに対してＡｃｋｎｏｗｌｅｄｇを送信し、Ｃｏｎｔｒｏｌｌｅｒでは、このＡｃｋｎｏｗｌｅｄｇを受信する（Ｓ２３→Ｓ２４）。ここまでの一連の処理が、ＣＯＭＭＡＮＤの送信に対応する処理となる。
【０１３４】
続いては、ＣＯＭＭＡＮＤに応答した、ＲＥＳＰＯＮＳＥのための処理として、ＴａｒｇｅｔからＷｒｉｔｅ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔが送信される（Ｓ２５）。Ｃｏｎｔｒｏｌｌｅｒではこれを受信して、Ｃｏｍｍａｎｄ／Ｒｅｓｐｏｎｃｅレジスタに対してデータの書き込みを行う（Ｓ２６）。また、Ｃｏｎｔｒｏｌｌｅｒでは、Ｗｒｉｔｅ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔの受信に応じて、Ｔａｒｇｅｔに対してＡｃｋｎｏｗｌｅｄｇを送信する（Ｓ２７）。Ｔａｒｇｅｔでは、このＡｃｋｎｏｗｌｅｄｇを受信することで、Ｗｒｉｔｅ Ｒｅｑｕｅｓｔ ＰａｃｋｅｔがＣｏｎｔｒｏｌｌｅｒにて受信されたことを知る（Ｓ２８）。
つまり、ＣｏｎｔｒｏｌｌｅｒからＴａｒｇｅｔ対するＣＯＭＭＡＮＤ伝送処理と、これに応答したＴａｒｇｅｔからＣｏｎｔｒｏｌｌｅｒに対するＲＥＳＰＯＮＳＥ伝送処理が、ＦＣＰによるデータ伝送（Ｔｒａｎｓａｃｔｉｏｎ）の基本となる。
【０１３５】
２−１１．ＡＶ／Ｃコマンドパケット
図８により説明したように、Ａｓｙｎｃｈｒｏｎｏｕｓ通信において、ＦＣＰは、ＡＶ／Ｃコマンドを用いて各種ＡＶ機器に対する通信を行うことができるようにされている。
Ａｓｙｎｃｈｒｏｎｏｕｓ通信では、Ｗｒｉｔｅ，Ｒｅａｄ，Ｌｏｃｋの３種のトランザクションが規定されているのは、図１４にて説明した通りであり、実際には各トランザクションに応じたＷｒｉｔｅ Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｃｅ Ｐａｃｋｅｔ，Ｒｅａｄ Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｃｅ Ｐａｃｋｅｔ，Ｌｏｃｋ Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｃｅ Ｐａｃｋｅｔが用いられる。そして、ＦＣＰでは、上述したようにＷｒｉｔｅ Ｔｒａｎｓａｃｔｉｏｎを使用するものである。
そこで図２０に、Ｗｒｉｔｅ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔ（Asynchronous Packet（Write Request for Data Block)）のフォーマットを示す。本実施の形態では、このＷｒｉｔｅ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔが即ち、ＡＶ／Ｃコマンドパケットして使用される。
【０１３６】
このＷｒｉｔｅ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔにおける上位５ｑｕａｄｌｅｔ（第１〜第５ｑｕａｄｌｅｔ）は、ｐａｃｋｅｔ ｈｅａｄｅｒとされる。
ｐａｃｋｅｔ ｈｅａｄｅｒの第１ｑｕａｄｌｅｔにおける上位１６ビットの領域はｄｅｓｔｉｎａｔｉｏｎ＿ＩＤで、データの転送先（宛先）のＮｏｄｅ ＩＤを示す。続く６ビットの領域はｔｌ(transact label)であり、パケット番号を示す。続く２ビットはｒｔ(retry code)であり、当該パケットが初めて伝送されたパケットであるか、再送されたパケット示す。続く４ビットの領域はｔｃｏｄｅ(transaction code)は、指令コードを示している。そして、続く４ビットの領域はｐｒｉ(priority)であり、パケットの優先順位を示す。
【０１３７】
第２ｑｕａｄｌｅｔにおける上位１６ビットの領域はｓｏｕｒｃｅ＿ＩＤであり、データの転送元のＮｏｄｅ＿ＩＤ が示される。
また、第２ｑｕａｄｌｅｔにおける下位１６ビットと第３ｑｕａｄｌｅｔ全体の計４８ビットはｄｅｓｔｉｎａｔｉｏｎ＿ｏｆｆｓｅｔとされ、ＣＯＭＭＡＮＤレジスタ（ＦＣＰ＿ＣＯＭＭＡＮＤ ｒｅｇｉｓｔｅｒ）とＲＥＳＰＯＮＳＥレジスタ（ＦＣＰ＿ＲＥＳＰＯＮＳＥ ｒｅｇｉｓｔｅｒ）のアドレスが示されれる。
上記ｄｅｓｔｉｎａｔｉｏｎ＿ＩＤ及びｄｅｓｔｉｎａｔｉｏｎ＿ｏｆｆｓｅｔが、ＩＥＥＥ１３９４フォーマットにおいて規定される６４ビットのアドレス空間に相当する。
【０１３８】
第４ｑｕａｄｌｅｔの上位１６ビットの領域は、ｄａｔａ＿ｌｅｎｇｔｈとされ、後述するｄａｔａｆｉｅｌｄ（図２０において太線により囲まれる領域）のデータサイズが示される。
続く下位１６ビットの領域は、ｅｘｔｅｎｄｅｄ＿ｔｃｏｄｅの領域とされ、ｔｃｏｄｅを拡張する場合に使用される領域である。
【０１３９】
第５ｑｕａｄｌｅｔとしての３２ビットの領域は、ｈｅａｄｅｒ＿ＣＲＣであり、Ｐａｃｋｅｔ ｈｅａｄｅｒのチェックサムを行うＣＲＣ計算値が格納される。
【０１４０】
Ｐａｃｋｅｔ ｈｅａｄｅｒに続く第６ｑｕａｄｌｅｔからｄａｔａ ｂｌｏｃｋが配置され、このｄａｔａ ｂｌｏｃｋ内の先頭に対してｄａｔａｆｉｅｌｄが形成される。
ｄａｔａｆｉｅｌｄとして先頭となる第６ｑｕａｄｌｅｔの上位４バイトには、ＣＴＳ(Command and Transaction Set)が記述される。これは、当該Ｗｒｉｔｅ Ｒｅｑｕｅｓｔ ＰａｃｋｅｔのコマンドセットのＩＤを示すもので、例えば、このＣＴＳの値について、図のように［００００］と設定すれば、ｄａｔａｆｉｅｌｄに記述されている内容がＡＶ／Ｃコマンドであると定義されることになる。つまり、このＷｒｉｔｅ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔは、ＡＶ／Ｃコマンドパケットであることが示されるものである。従って、本実施の形態においては、ＦＣＰがＡＶ／Ｃコマンドを使用するため、このＣＴＳには［００００］が記述されることになる。
【０１４１】
ＣＴＳに続く４ビットの領域は、ｃｔｙｐｅ(Command type；コマンドの機能分類)、又はコマンドに応じた処理結果(レスポンス)を示すｒｅｓｐｏｎｓｅが記述される。
【０１４２】
図２１に、上記ｃｔｙｐｅ及びｒｅｓｐｏｎｓｅの定義内容を示す。
ｃｔｙｐｅ（Ｃｏｍｍａｎｄ）としては、［００００］〜［０１１１］を使用できるものとしており、［００００］はＣＯＮＴＲＯＬ、［０００１］はＳＴＡＴＵＳ、［００１０］はＩＮＱＵＩＲＹ、［００１１］はＮＯＴＩＦＹとして定義され、［０１００］〜０１１１は、現状、未定義（ｒｅｓｅｒｖｅｄ）とされている。
ＣＯＮＴＲＯＬは機能を外部から制御するコマンドであり、ＳＴＡＴＵＳは外部から状態を間い合わせるコマンド、ＩＮＱＵＩＲＹは、制御コマンドのサポートの有無を外部から問い合わせるコマンド、ＮＯＴＩＦＹは状態の変化を外部に知らせることを要求するコマンドである。
また、ｒｅｓｐｏｎｓｅとしては、［１０００］〜［１１１１］を使用するものとしており、［１０００］はＮＯＴ ＩＭＰＬＥＭＥＮＴＥＤ、［１００１］はＡＣＣＥＰＴＥＤ、［１０１０］はＲＥＪＥＣＴＥＤ、［１０１１］はＩＮ ＴＲＡＮＳＩＴＩＯＮ、［１１００］はＩＭＰＬＥＭＥＮＴＥＤ／ＳＴＡＢＬＥ、［１１０１］はＣＨＡＮＧＥＤ、［１１１０］はｒｅｓｅｒｖｅｄ、［１１１１］はＩＮＴＥＲＩＭとしてそれぞれ定義されている。
これらのｒｅｓｐｏｎｓｅは、コマンドの種類に応じて使い分けられる。例えば、ＣＯＮＴＯＲＯＬのコマンドに対応するｒｅｓｐｏｎｓｅとしては、ＮＯＴＩＭＰＬＥＭＥＮＴＥＤ、ＡＣＣＥＰＴＥＤ、ＲＥＪＥＣＴＥＤ、或いはＩＮＴＥＲＩＭの4つのうちの何れかがＲｅｓｐｏｎｄｅｒ側の状況等に応じて使い分けられる。
【０１４３】
図２０において、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅに続く５ビットの領域には、ｓｕｂｕｎｉｔ−ｔｙｐｅが格納される。は、ｓｕｂｕｎｉｔ−ｔｙｐｅは、ＣＯＭＭＭＡＮＤの宛先またはＲＥＳＰＯＮＳＥの送信元のｓｕｂｕｎｉｔが何であるのか（機器）を示す。ＩＥＥＥ１３９４フォーマットでは、機器そのものをｕｎｉｔと称し、そのｕｎｉｔ（機器）内において備えられる機能的機器単位の種類をｓｕｂｕｎｉｔと称する。例えば一般のＶＴＲを例に採れば、ＶＴＲとしてのｕｎｉｔは、地上波や衛星放送を受信するチューナと、ビデオカセットレコーダ／プレーヤとの、２つのｓｕｂｕｎｉｔを備える。
ｓｕｂｕｎｉｔ−ｔｙｐｅとしては、例えば図２２（ａ）に示すように定義されている。つまり、［０００００］はＭｏｎｉｔｏｒ、［００００１］〜［０００１０］はｒｅｓｅｒｖｅｄ、［０００１１］はＤｉｓｃ ｒｅｃｏｒｄｅｒ／ｐｌａｙｅｒ、［００１００］はＶＣＲ、［００１０１］はＴｕｎｅｒ、［００１１１］はＣａｍｅｒａ、［０１０００］〜［１１１１０］はｒｅｓｅｒｖｅｄ、［１１１１１］は、ｓｕｂｕｎｉｔが存在しない場合に用いられるｕｎｉｔとして定義されている。
【０１４４】
図２０において、上記ｓｕｂｕｎｉｔ−ｔｙｐｅに続く３ビットには、同―種類のｓｕｂｕｎｉｔが複数存在する場合に、各ｓｕｂｕｎｉｔを特定するためのｉｄ（Ｎｏｄｅ＿ＩＤ）が格納される。
【０１４５】
上記ｉｄ（Ｎｏｄｅ＿ＩＤ）に続く８ビットの領域には、ｏｐｃｏｄｅが格納され、続く８ビットの領域には、ｏｐｅｒａｎｄが格納される。
ｏｐｃｏｄｅとは、オぺレーションコード(Operation Code)のことであって、ｏｐｅｒａｎｄには、ｏｐｃｏｄｅが必要とする情報（パラメータ）が格納される。これらｏｐｃｏｄｅはｓｕｂｕｎｉｔごとに定義され、ｓｕｂｕｎｉｔごとに固有のｏｐｃｏｄｅのリストのテーブルを有する。例えば、ｓｕｂｕｎｉｔがＶＣＲであれば、ｏｐｃｏｄｅとしては、例えば図２２（ｂ）に示すようにして、ＰＬＡＹ（再生），ＲＥＣＯＲＤ（記録）などをはじめとする各種コマンドが定義されている。ｏｐｅｒａｎｄは、ｏｐｃｏｄｅ毎に定義される。
【０１４６】
図２０におけるｄａｔａｆｉｅｌｄとしては、上記第６ｑｕａｄｌｅｔの３２ビットが必須とされるが、必要が有れば、これに続けて、ｏｐｅｒａｎｄを追加することが出来る（Ａｄｄｉｔｉｏｎａｌ ｏｐｅｒａｎｄｓ）。
ｄａｔａｆｉｅｌｄに続けては、ｄａｔａ＿ＣＲＣが配置される。なお、必要が有れば、ｄａｔａ＿ＣＲＣの前にｐａｄｄｉｎｇを配置することが可能である。
【０１４７】
２−１２．プラグ
ここで、ＩＥＥＥ１３９４フォーマットにおけるプラグについて概略的に説明する。ここでいうプラグとは、先に図１８によっても説明したように、ＩＥＥＥ１３９４フォーマットにおける機器間の論理的接続関係をいうものである。
【０１４８】
図２３に示すように、Ａｓｙｎｃｈｒｏｎｏｕｓ通信において有効とされるコマンド等のデータ（ｒｅｑｕｅｓｔ）は、ｐｒｏｄｕｃｅｒからｃｏｎｓｕｍｅｒに対して伝送される。ここでいうｐｒｏｄｕｃｅｒ及びｃｏｎｓｕｍｅｒは、それぞれＩＥＥＥ１３９４インターフェイス上で送信機器、受信機器として機能する機器をいうものである。そして、ｃｏｎｓｕｍｅｒにおいては、図に斜線で示すように、ｐｒｏｄｕｃｅｒによりデータ書き込みが行われるセグメントバッファ（Segment Buffer）を備える。
また、ＩＥＥＥ１３９４システムにおいて、特定の機器をｐｒｏｄｕｃｅｒ、ｃｏｎｓｕｍｅｒとして規定するための情報（Connection Management Information）は、図に網線で示すプラグアドレス内の所定位置に格納されている。セグメントバッファは、プラグアドレスに続いて配置される。
ｃｏｎｓｕｍｅｒのセグメントバッファに対して書き込み可能なアドレス範囲（データ量）は、後述するようにしてｃｏｎｓｕｍｅｒ側で管理するｌｉｍｉｔＣｏｕｎｔ ｒｅｇｉｓｔｅｒによって規定される。
【０１４９】
図２４は、Ａｓｙｎｃｈｒｏｎｏｕｓ通信におけるプラグのアドレス空間の構造を示している。
６４ビットから成るプラグのアドレス空間は、図２４（ａ）に示すようにして、２の１６乗（６４Ｋ）のＮｏｄｅに分割される。そして、プラグは、図２４（ｂ）に示すようにして、各Ｎｏｄｅのアドレス空間内に在るようにされる。そして、各プラグは、図２４（ｃ）に示すように、網線の領域により示すレジスタ（ｒｅｇｉｓｔｅｒ）と、斜線の領域により示すセグメントバッファ(Segment Buffer)とを含んで形成される。レジスタには、次に説明するようにして、送信側（ｐｒｏｄｕｃｅｒ）と受信側（ｃｏｎｓｕｍｅｒ）との間におけるデータの授受管理に必要な情報（例えば、送信データサイズ及び受信可能データサイズ）が格納される。セグメントバッファは、ｐｒｏｄｕｃｅｒからｃｏｎｓｕｍｅｒに対して送信されたデータが書き込まれるべき領域であり、例えば最小で６４バイトであることが規定されている。
【０１５０】
図２５（ａ）にはプラグアドレスが示されている。つまり、上記図２４（ｃ）と同一内容が示されている。
この図に示すように、レジスタはプラグアドレスの先頭に対して配置され、これに続けてセグメントバッファが配置される。
そして、レジスタ内の構造としては、図２５（ｂ）に示すようにして、先頭に対して、例えば３２ビットのｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒが配置され、続けて、各３２ビットのｌｉｍｉｔ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒ［１］〜［１４］が配置される。つまり、１つのｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒと１４のｌｉｍｉｔ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒが設けられる。なお、ここでは、ｌｉｍｉｔ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒ［１４］の後ろに未使用（ｕｎｕｓｅｄ）の領域が設けられている。
【０１５１】
上記図２５（ａ）（ｂ）に示すプラグ構造は、図２５（ｃ）に示すようにして、オフセットアドレス(Address Offset)によって指定される。
つまり、オフセットアドレス０は、ｃｏｎｓｕｍｅｒ ｐｏｒｔ（ｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒ）を指定し、オフセットアドレス４，８，１２・・・５６，６０は、それぞれｐｒｏｄｕｃｅｒ ｐｏｒｔ［１］〜［１４］を指定する。オフセットアドレス６０はｒｅｓｅｒｖｅｄとして定義されることで、未使用（ｕｎｕｓｅｄ）の領域を示し、オフセットアドレス６４によりセグメントバッファを示す。
【０１５２】
図２６には、ｐｒｏｄｕｃｅｒ側とｃｏｎｓｕｍｅｒ側との両者のプラグ構造が示されている。
Ａｓｙｎｃｈｒｏｎｏｕｓ通信のプラグ構造においては、ｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒへの書き込み、ｌｉｍｉｔ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒへの書き込み、及びセグメントバッファへの書き込みを後述する送受信手順に従って行うことで、Ａｓｙｎｃｈｒｏｎｏｕｓ通信を実現する。これらの書き込みは、先に説明したＷｒｉｔｅ Ｔｒａｎｓａｃｔｉｏｎとしての処理である。
【０１５３】
ｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒは、ｐｒｏｄｕｃｅｒによってｃｏｎｓｕｍｅｒに対して書き込みが行われる。
ｐｒｏｄｕｃｅｒは、自身のアドレスに在るｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒにｐｒｏｄｕｃｅｒ側のデータ伝送に関する情報を書き込んだ上で、このｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒの内容を、ｃｏｎｓｕｍｅｒのｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒに対して書き込む。
ｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒは、ｐｒｏｄｕｃｅｒがｃｏｎｓｕｍｅｒのセグメントバッファに対して書き込むデータサイズとして、１回の書き込み処理によって書き込むデータサイズの情報とされる。つまり、ｐｒｏｄｕｃｅｒが、ｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒの書き込みを行うことによって、ｃｏｎｓｕｍｅｒのセグメントバッファに書き込むデータサイズを知らせる処理が行われる。
【０１５４】
これに対して、ｌｉｍｉｔ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒは、ｃｏｎｓｕｍｅｒによってｐｒｏｄｕｃｅｒに対して書き込みが行われる。
ｃｏｎｓｕｍｅｒ側では、自身のｌｉｍｉｔ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒ［１］〜［１４］のうち、ｐｒｏｄｕｃｅｒに対応して指定された１つのｌｉｍｉｔ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒ［ｎ］に対して、自身のセグメントバッファの容量（サイズ）を書き込み、このｌｉｍｉｔ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒ［ｎ］の内容を、ｌｉｍｉｔ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒ［ｎ］に対して書き込む。
【０１５５】
ｐｒｏｄｕｃｅｒ側では、上記のようにしてｌｉｍｉｔ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒ［ｎ］に書き込まれた内容に応じて、１回あたりの書き込みデータ量を決定して、例えば自身のセグメントバッファに対して書き込みを行う。そして、このセグメントバッファに書き込んだ内容を、ｃｏｎｓｕｍｅｒに対して書き込むようにされる。このセグメントバッファへの書き込みが、Ａｓｙｎｃｈｒｏｎｏｕｓ通信におけるデータ送信に相当する。
【０１５６】
２−１３．Asynchronous Connection送信手順
続いて、上記図２６により説明したプラグ（ｐｒｏｄｕｃｅｒ−ｃｏｎｓｕｍｅｒ）間の構造を前提として、図２７の処理遷移図により、Ａｓｙｎｃｈｒｏｎｏｕｓ ｃｏｎｎｅｃｔｉｏｎの基本的な送受信手順について説明する。
図２７に示す送受信処理の手順は、Ａｓｙｎｃｈｒｏｎｏｕｓ通信として、ＦＣＰによって規定された環境のもとで、ＡＶ／Ｃコマンド（Ｗｒｉｔｅ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔ）を使用して行われる。そして、本実施の形態において扱われるＡＵＸデータも、この送受信手順を使用してＩＥＥＥ１３９４システム内において送受信が行われる。但し、図２６に示す処理は、あくまでもＡｓｙｎｃｈｒｏｎｏｕｓ ｃｏｎｎｅｃｔｉｏｎとしての通信動作を示すもので、ＡＵＸデータの記録再生に対応する通信処理については後述する。
なお、Ａｓｙｎｃｈｒｏｎｏｕｓ ｃｏｎｎｅｃｔｉｏｎの実際においては、コマンド送信に応じて、図１９に示したように、Ａｃｋｎｏｗｌｅｄｇの送受信が実行されるのであるが、図２７においてはＡｃｋｎｏｗｌｅｄｇについての送受信処理の図示は省略している。
【０１５７】
また、ＩＥＥＥ１３９４インターフェイスでは、プラグ（機器）間の接続関係として、上記したｐｒｏｄｕｃｅｒ−ｃｏｎｓｕｍｅｒの関係の他に、ｃｏｎｔｒｏｌｌｅｒ−ｔａｒｇｅｔとして規定される関係が存在する。ＩＥＥＥ１３９４システム上においては、ｐｒｏｄｕｃｅｒ−ｃｏｎｓｕｍｅｒの関係が規定された機器と、ｃｏｎｔｒｏｌｌｅｒ−ｔａｒｇｅｔの関係が機器とが必ずしも一致するものではない。つまり、ｐｒｏｄｕｃｅｒとして規定された機器の他に、ｃｏｎｔｒｏｌｌｅｒの機能を有するものとして規定された機器が存在する場合がある。但し、ここでは、ｐｒｏｄｕｃｅｒ−ｃｏｎｓｕｍｅｒとしての関係と、ｃｏｎｔｒｏｌｌｅｒ−ｔａｒｇｅｔとしての関係が一致している場合を例に説明する。
【０１５８】
図２７に示す送信手順としては、先ず、ステップＳ１０１として示すように、ｐｒｏｄｕｃｅｒからｃｏｎｓｕｍｅｒに対して、Ｃｏｎｎｅｃｔ要求を送信する。このＣｏｎｎｅｃｔ要求は、ｐｒｏｄｕｃｅｒがｃｏｎｓｕｍｅｒに対して、接続要求を行うためのコマンドで、ｐｒｏｄｕｃｅｒのレジスタのアドレスをｃｏｎｓｕｍｅｒに対して伝える。
このＣｏｎｎｅｃｔ要求は、ステップＳ１０２の処理としてｃｏｎｓｕｍｅｒが受信することで、ｃｏｎｓｕｍｅｒ側では、ｐｒｏｄｕｃｅｒのレジスタのアドレスを認識する。そして、ステップＳ１０３により、ｒｅｓｐｏｎｃｅとして、ｃｏｎｓｕｍｅｒは、ｐｒｏｄｕｃｅｒに対してＣｏｎｎｅｃｔ受付を送信する。そして、ステップＳ１０４において、ｐｒｏｄｕｃｅｒがこれを受信することで、以降のデータ送受信のためのｐｒｏｄｕｃｅｒ−ｃｏｎｓｕｍｅｒ間の接続（ｃｏｎｎｅｃｔｉｏｎ）が確立される。
【０１５９】
上記のようにしてｃｏｎｎｅｃｔｉｏｎが確立されると、ステップＳ１０５により、ｃｏｎｓｕｍｅｒは、ｐｒｏｄｕｃｅｒに対してｌｉｍｉｔ Ｃｏｕｎｔｒｅｇｉｓｔｅｒ（（以降、単に「ｌｉｍｉｔ Ｃｏｕｎｔ」と略す））の書込要求を行う。ステップＳ１０６によりこれを受信したｐｒｏｄｕｃｅｒは、続くステップＳ１０７の処理によって、ｌｉｍｉｔ Ｃｏｕｎｔ書込受付を、ｃｏｎｓｕｍｅｒに対して送信する。そして、ステップＳ１０８の処理として、ｃｏｎｓｕｍｅｒがｌｉｍｉｔ Ｃｏｕｎｔ書込受付を受信する。このｌｉｍｉｔ Ｃｏｕｎｔ書込要求／書込受付の一連の処理によって、以降における、セグメントバッファへのデータ書き込みサイズ（セグメントバッファ容量）が決定される。
【０１６０】
続くステップＳ１０９においては、ｐｒｏｄｕｃｅｒからｃｏｎｓｕｍｅｒに対して、セグメントバッファ書込要求を送信する。そして、ステップＳ１１０によってセグメントバッファ書込要求が受信され、これに応答して、ステップＳ１１１の処理として、ｃｏｎｓｕｍｅｒからｐｒｏｄｕｃｅｒに対して、セグメントバッファ書込受付を送信する。ｐｒｏｄｕｃｅｒは、ステップＳ１１２により、セグメントバッファ書込受付を受信する。
このステップＳ１０９〜Ｓ１１２までの処理が実行されることで、１回のｐｒｏｄｕｃｅｒのセグメントバッファからｃｏｎｓｕｍｅｒのセグメントバッファに対してデータへの書き込み処理が完了する。
ここで、上記ステップＳ１０９〜Ｓ１１２の処理によって書き込まれるデータは、図１３に示したＡｓｙｎｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔによる１回の送信により書き込まれる。従って、Ａｓｙｎｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔにより転送されるデータサイズが、上記ｌｉｍｉｔ Ｃｏｕｎｔによって指定されたデータサイズよりも小さく、かつ、１回のＡｓｙｎｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔによる送信によっては、必要なデータ送信が完了しない場合には、セグメントバッファの容量がフルとなる範囲で、ステップＳ１０９〜Ｓ１１２の処理が繰り返されるようになっている。
【０１６１】
そして、上記したステップＳ１０９〜Ｓ１１２に示すセグメントバッファへの書き込み処理が完了すると、ステップＳ１１３の処理として示すように、ｐｒｏｄｕｃｅｒからｃｏｎｓｕｍｅｒに対して、ｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒ（以降、単にｐｒｏｄｕｃｅｒ Ｃｏｕｎｔと略す）書込要求を送信する。そしてｃｏｎｓｕｍｅｒでは、ステップＳ１１４の処理として、ｐｒｏｄｕｃｅｒ Ｃｏｕｎｔを受信して、自身のｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒに書き込みを行い、続くステップＳ１１５の処理として、ｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ書込受付をｐｒｏｄｕｃｅｒに対して送信する。ｐｒｏｄｕｃｅｒはステップＳ１１６により、このｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ書込受付を受信する。
この処理によって、先のステップＳ１０９〜Ｓ１１２の処理として、ｐｒｏｄｕｃｅｒからｃｏｎｓｕｍｅｒのセグメントバッファに対して転送したデータサイズがｃｏｎｓｕｍｅｒに対して知らされることになる。
【０１６２】
続くステップＳ１１７の処理としては、上記ステップＳ１１３〜Ｓ１１６に示したｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ書き込み処理に応答しての、ｌｉｍｉｔ Ｃｏｕｎｔ書き込みのための一連の処理が実行される。つまり、ステップＳ１１７〜Ｓ１２０に示すようにして、ｃｏｎｓｕｍｅｒからｐｒｏｄｕｃｅｒへのｌｉｍｉｔ Ｃｏｕｎｔ書込要求の送信と、この送信に応答してのｐｒｏｄｕｃｅｒからｃｏｎｓｕｍｅｒへのｌｉｍｉｔ Ｃｏｕｎｔ書込受付の送信が行われる。
【０１６３】
上記ステップＳ１０９〜Ｓ１２０までの処理が、Ａｓｙｎｃｈｒｏｎｏｕｓ Ｃｏｎｎｅｃｔｉｏｎにおけるデータ伝送処理としての１セットの手順を成す。ここで、例えば送信すべきデータサイズが、セグメントバッファ容量よりも大きく、１回のステップＳ１０９〜Ｓ１２０までの処理によっては、データの転送が完了していないとされる場合には、このステップＳ１０９〜Ｓ１２０までの処理を、データの転送が完了するまで繰り返し実行することが出来るようになっている。
【０１６４】
そして、データの転送が完了したら、ステップＳ１２１に示すようにして、ｐｒｏｄｕｃｅｒはｃｏｎｓｕｍｅｒに対して、Ｄｉｓｃｏｎｎｅｃｔ要求を送信する。ｃｏｎｓｕｍｅｒはステップＳ１２２において、このＤｉｓｃｏｎｎｅｃｔ要求を受信し、続くステップＳ１２３によりＤｉｓｃｏｎｎｅｃｔ受付を送信する。ステップＳ１２４において、ｐｒｏｄｕｃｅｒがＤｉｓｃｏｎｎｅｃｔ受付を受信することで、Ａｓｙｎｃｈｒｏｎｏｕｓ Ｃｏｎｎｅｃｔｉｏｎによるデータ送受信が完結する。
【０１６５】
４．ノード分類処理
前述したように、本実施の形態のＳＴＲ６０は、ＳＴＲ対応ＣＤ機３０，ＳＴＲ対応ＭＤ機１などの他のＳＴＲ対応機器ＳＴＲ対応機器と共に、コンポーネント的なシステムを組むことができるように構成されている。
このために、ＳＴＲ６０、もしくはＳＴＲ対応機器は、現在ＩＥＥＥ１３９４バス上に存在する各Ｎｏｄｅを探索してそのメーカや機種を識別することで、予め定められた規則によってグループ化を行う。つまり、ＩＥＥＥ１３９４バス上に存在するすべてのノードについての分類を行うようにされる。そして、後述するるようにして、ＳＴＲ６０が他の機器の電源状態に応じて自機の電源コントロールを行う際も、このノード分類によって作成されるテーブルを利用して、電源状態を監視すべき機器としてのノードを選択するように構成することが可能とされる。
そこで以下、本実施の形態としてのノード分類処理について説明する。
【０１６６】
先ず、本実施の形態においては、ノードは以下のようにして８つのグループに分類するものとして規定されているものとする。ここでは便宜上、分類される各グループごとに分類番号＃１〜＃８を付している。
＃１：ＳＴＲ対応ＣＤ機
＃２：ＳＴＲ対応ＭＤ機
＃３：同一メーカＣＤ機
＃４：同一メーカＭＤ機
＃５：他社メーカＣＤ機、ＭＤ機
＃６：ＣＤ機、ＭＤ機以外の同一メーカ機器（Subunitを複数有するものを含む）
＃７：ＣＤ機、ＭＤ機以外の他社メーカ機器で、SubunitがDisc,Tuner,VCRの何れかのもの
＃８：その他のもの
なお、上記分類は、現状として、Subunit＝Disc(正確にはDisc recorder/player)とされるＳＴＲ６０と同一メーカの機器としては、ＣＤとＭＤのみが接続されることを前提としており、例えばＤＶＤなどの他のディスクメディアに対応する機器は前提とされていないものとされる。従ってＳＴＲ６０と同一メーカの機器は、分類番号＃１，＃２，＃３，＃４，＃６の何れかに分類される。
【０１６７】
そして、このノード分類処理は、ＩＥＥＥ１３９４バス上でのノード管理に変更があるとされるバスリセット発生時に対応して、ＳＴＲ６０が実行するものとされる。このノード分類処理としての処理動作を図２８及び図２９のフローチャートに示す。この図に示す処理は、ここでは説明の便宜上、ＳＴＲ６０内のシステムコントローラ７０が、ＩＥＥＥ１３９４インターフェイス６１との情報の授受を行いながら実行していくものとする。
【０１６８】
ノード分類処理は図２８に示すステップＳ２０１から開始される。ステップＳ２０１においてはＩＥＥＥ１３９４バス上でバスリセットが発生するのを待機しており、バスリセットが発生したことが検出されるとステップＳ２０２以降のノード分類処理に移行する。
【０１６９】
ステップＳ２０２においては、Ｎｏｄｅ ＩＤについて［０］を設定する。また、続くステップＳ２０３としても示すように、現在種別判定対象として選択されているＮｏｄｅ（以降、「現Ｎｏｄｅ」ともいう）のＮｏｄｅ ＩＤに対応する変数ｉ（ここではｉ≧０とされる）について［０］に設定すると共に、バスリセット後とされる現在において、ＩＥＥＥ１３９４バス上に存在する自分以外のノード数＝ｎ、とするように設定を行う。つまり、ステップＳ２０２→Ｓ２０３の処理によってはノード分類処理開始時に対応しての初期化処理が実行される。
【０１７０】
次のステップＳ２０４においては、現在の変数ｉと自分以外のノード数ｎとについて、ｉ＜ｎが成立するか否かについて判別する。つまり、ＩＥＥＥ１３９４バス上に存在する自分以外の全ノードについて、以降説明することとなるノード分類のための処理が完了しているか否かについて判別するものである。
ここで、ｉ＜ｎが成立していないと判別された場合にはステップＳ２０５に進む。
【０１７１】
ステップＳ２０５においては、現在の変数ｉにより示されるＮｏｄｅ ＩＤをカウントする。例えば最初にステップＳ２０５に至った段階では、Ｎｏｄｅ ＩＤ＝０とカウントされ、このＮｏｄｅ ＩＤ＝０を有するノードが種別判定の対象となる。
そして次のステップＳ２０６においては、上記ステップＳ２０５により現ノードとして選択されたＮｏｄｅについての、Node Unique IDを識別する。このNode Unique IDは、そのノードのConfiguration ROM（図１５（ｅ））を参照しにいくことで識別可能である。このために、例えばシステムコントローラ７０では、そのＮｏｄｅのアドレスにアクセスしてConfiguration ROMの読み込みを行うようにされる。
【０１７２】
続いてはステップＳ２０７において、バスリセット前にセットされていたノードテーブルから、ステップＳ２０６にて識別されたのと同じNode Unique IDを有するＮｏｄｅ（機器）について調べることを行う。
ここでいうノードテーブルとは、ＩＥＥＥ１３９４バス上に存在する各機器（Ｎｏｄｅ）についてのノード分類結果が格納されるテーブルとされ、バスリセットが発生するごとに新規な内容を有するものが作成される。
【０１７３】
次のステップＳ２０８においては、上記ステップＳ２０７の処理結果として、同じNode Unique IDが発見されたか否かについて判別を行う。そして、肯定結果が得られた場合にはステップＳ２０９に進む。
ステップＳ２０９においては、バスリセット前のノードテーブルから、発見されたNode Unique IDを有するノードについての情報を読み出して、新たに今回作成するノードテーブルにセットすることを行う。つまり、バスリセット前にもＩＥＥＥ１３９４バス上に存在していたノードについては、後述する種別判定を行うことなく、前回のノードテーブルに格納されている情報をそのまま流用するようにされる。
そして、次のステップＳ２１０において変数ｉについてｉ←ｉ＋１とインクリメントした後にステップＳ２０４に戻るようにされる。変数ｉをインクリメントする処理は、種別判定対象となる現ノードを、Ｎｏｄｅ ＩＤとしてのナンバの昇順に従って変更する処理となる。
【０１７４】
一方、ステップＳ２０８において否定結果が得られた場合にはステップＳ２１１の種別判定処理を実行することになる。この種別判定処理は、その機器（Ｎｏｄｅ）についてノード分類するための判断材料となる種別を判定するための処理であり、また、この判定結果に基づいて、先に示した８つのグループのうちの何れかに分類することも最終的には行うようにされる。
【０１７５】
このステップＳ２１１の種別判定処理は、図２９に示される。
図２９においては、先ずステップＳ３０１において、Configuration ROMの内容を調べることが行われる。そして続くステップＳ３０２において、このConfiguration ROM内のsubunit IDとして格納されるmodel_IDを識別する。 model_IDによっては、そのノードの機種を識別することが可能になるのであるが、次のステップＳ３０７においては、model_IDの内容から、このノードがＳＴＲ対応機種であるか否かについて判別を行う。そして肯定結果が得られた場合には、ステップＳ３０４の処理に進む。
【０１７６】
本実施の形態としては、少なくともＳＴＲ対応機種にあっては、model_IDの内容からＳＴＲ対応機種であることと、また、その機器がＣＤ、ＭＤ、ＳＴＲの何れであるのかについても識別することが可能とされる。そこで、ステップＳ３０４においては、ＳＴＲ対応機種として、ＣＤ機であるのかＭＤ機であるのかを判別するようにされる。そしてＣＤ機であることを判別した場合には、ステップＳ３０５に進んで現ノードを分類番号＃１に分類する。
また、ＭＤ機であることを判別した場合には、ステップＳ３０６に進んで、分類番号＃２として分類する。ステップＳ３０５又はＳ３０６の処理が終了すると、図２８のステップＳ２１２に進む。
【０１７７】
また、ステップＳ３０３において否定結果が得られた場合にはステップＳ３０７に進んで、Configuration ROM内のsubunit IDとして格納されるmodule_vender_IDを識別することが行われる。module_vender_IDによっては製造メーカ名を識別することが可能となるのであるが、次のステップＳ３０８においては、現ノードがＳＴＲ６０と同一メーカ機種であるか否かについて判別を行う。ここで、否定結果が得られた場合にはそのままステップＳ３１０に進むのであるが、肯定結果が得られた場合には、ステップＳ３０９に進んで同一メーカフラグｆについてｆ←１と設定してからステップＳ３１０に進む。同一メーカフラグｆは、ｆ＝０であれば同一メーカではないことを示し、ｆ＝１であれば同一メーカであることを示す。
【０１７８】
ステップＳ３１０においては、先ず現ノードに対してSUBUNIT_INFOコマンド（STATUS)の送信を行う。SUBUNIT_INFOコマンドは、ＡＶ／ＣコマンドにおいてSubunit_typeが何であるのかの通知を行うために規定されているコマンドである。そして、SUBUNIT_INFOコマンド（STATUS)の送信に応答して、現ノードからはRESPONCEが返送されてくるのであるが、このRESPONCEの内容から、Subunit_typeについての識別を行う。
このSubunit_typeについての識別結果に基づき、次のステップＳ３１１においては、現ノードが、Subunit_type＝Disc（Disc recorder／Player）で、かつ、１つのみのSubunit_typeを有するものであるか否かについて判別する。そして、肯定結果が得られればステップＳ３１２以降の処理に進む。
【０１７９】
ステップＳ３１２においては、Subunit Identifier Descriptorを要求する内容のDescriptor_Accessコマンド（OPEN DESCRIPTORコマンド、READ DESCRIPTORコマンド）を現ノードに対して送信し、これに応答して現ノードから返送されるRESPONCEの内容から、現ノードのmedia_typeを識別することが行われる。
Descriptor_AccessコマンドとしてのOPEN DESCRIPTORコマンド及びREAD DESCRIPTORコマンドも、ＡＶ／Ｃコマンドの１つとされ、そのノードのDescriptorを読み込むために用いられるコマンドとされる。また、Subunit Identifier Descriptorは、ＡＶ／Ｃプロトコルに適合する形式により、そのノードが対応するディスクメディアについての管理情報（ＴＯＣ）が記述されたもので、このデータ構造内の所定位置に対してmedia_typeの情報が格納される。media_typeは、Subunit_type＝Discとされる場合に、そのディスクの種別を示すものであり、例えばこのmedia_typeによって、ＣＤであるのかＭＤであるのか、さらには他の種別のディスクメディアであるのかが示される。
【０１８０】
このDescriptor_Accessコマンドが送信されると、受信側のノードにおいては、RESPONCEとして、そのノードが保持しているSubunit Identifier Descriptorの一部、あるいはすべてを格納して送信する。そして上記ステップＳ３１２におけるREAD DESCRIPTORコマンド送信後の処理としては、現ノードから送信されるRESPONCEを受信して、このRESPONCEとしてのSubunit Identifier Descriptor内に記述されるmedia_typeの内容を識別するものである。
【０１８１】
そして、次のステップＳ３１３においては、識別したmedia_typeの内容が何であるのかについて判別を行う。そして、media_type＝ＣＤであると判別したのであればステップＳ３１４に進む。また、media_type＝ＭＤであると判別したのであればステップＳ３１７に進み、media_typeがＣＤ、ＭＤ以外であると判別したのであればステップＳ３１９に進む。
【０１８２】
ステップＳ３１４では、同一メーカフラグｆ＝１であるか否かについて判別しており、ｆ＝１である場合には、機種の種別としては、ＳＴＲ６０と同一メーカのＣＤ機であると判定されることになる。そして、この場合にはステップＳ３１５に進むことで、分類番号＃３として分類する。これに対して、ステップＳ３１４においてｆ＝１ではないと判別された場合には、他メーカのＣＤ機であると種別判定を行い、ステップＳ３１６により分類番号＃５に分類する。
【０１８３】
また、ステップＳ３１７においても、同一メーカフラグｆ＝１であるか否かについて判別を行うようにしており、肯定結果が得られた場合には、同一メーカのＭＤ機であると種別判定を行って、ステップＳ３１８により分類番号＃４に分類する。これに対してステップＳ３１７において否定結果が得られた場合には、他社メーカのＭＤ機」であると種別判定したことになり、ステップＳ３１６により分類番号＃５に分類する。
【０１８４】
また、ステップＳ３１９においても同一メーカフラグｆ＝１であるか否かについて判別するようにされ、先ず否定結果が得られた場合にはステップＳ３２０に進んで分類番号＃７に分類する。つまり、この場合には、他社メーカ機器でSubunit_type＝Discと種別判定されるため、「分類番号＃７：ＣＤ機、ＭＤ機以外の他社メーカ機器で、SubunitがDisc,Tuner,VCRの何れかのもの」に含められるものである。
一方、ステップＳ３１９において肯定結果が得られたのであれば、Subunit_type＝Discではあるが、「ＣＤ機、ＭＤ機以外の同一メーカ機器」として判定されるため、ステップＳ３２２において分類番号＃６に分類する。
【０１８５】
また、先のステップＳ３１１において否定結果が得られた場合にはステップＳ３２１に進む。ステップＳ３１１において否定結果が得られる場合とは、現ノードのSubunit_type＝Disc以外で１つのSubunit_typeを有する場合、もしくは、現ノードが複数のSubunit_typeを有する場合である。複数のSubunit_typeを有するノードとしては、例えばＣＤプレーヤ、ＭＤレコーダ／プレーヤ、チューナなどの２以上のソース出力を行う装置部が一体化された複合機器がこれにあたる。
【０１８６】
ステップＳ３２１においても、同一メーカフラグｆ＝１であるか否かについて判別を行う。そして、肯定結果が得られた場合には、「ＣＤ機、ＭＤ機以外の同一メーカ機器」であると判定してステップＳ３２２に進む。
一方、ステップＳ３２１において否定結果が得られた場合には、ステップＳ３２３に進む。ステップＳ３２３においては、Subunit_type＝TUNER、Subunit_type＝VCRの何れかであるか否かが判別される。つまり、SubunitとしてTUNERのみを有する機器であるか、又はVCRのみを有する機器であるのかが判別される。そして、このうちの何れかに該当するとして肯定結果が得られた場合には、ステップＳ３２４に進む。この場合には、他社メーカのTUNERのみ,又はVCRのみの機器であるとして種別判定が行われるが、これは「分類番号＃７：ＣＤ機、ＭＤ機以外の他社メーカ機器で、SubunitがDisc,Tuner,VCRの何れかのもの」に含められるものであり、従って分類番号＃７として分類される。
これに対して、ステップＳ３２３において否定結果が得られた場合には、分類番号＃１〜＃７の何れにも該当しないものであると種別判定を行って、ステップＳ３２５に進んで分類番号＃８に分類する。
【０１８７】
上記ステップＳ３１５，Ｓ３１６，Ｓ３１８，Ｓ３２０，Ｓ３２２，Ｓ３２４，Ｓ３２５の各分類処理を実行した後は、図２８のステップＳ２１２に進む。
【０１８８】
図２８のステップＳ２１２においては、上記ステップＳ３１５，Ｓ３１６，Ｓ３１８，Ｓ３２０，Ｓ３２２，Ｓ３２４，Ｓ３２５の各処理によって分類された結果を含めて形成した現ノードについてのノード情報を、今回のバスリセットに対応して作成されるノードテーブルにセットする。そして、次のステップＳ２１３においては、変数ｉについてｉ←ｉ＋１とインクリメントし、また、同一メーカフラグｆについてｆ＝１とされているのであれば、これをｆ←０にリセットしてステップＳ２０４に戻るようにされる。
【０１８９】
そしてステップＳ２０４にて否定結果が得られるまで、これまで説明したステップＳ２０５〜２１３の処理が実行されることで、バスリセット後においてＩＥＥＥ１３９４バス上に存在するノードごとのノード分類、つまり、ノードテーブルへのノード情報のセットが行われていく。
そして、全ノードについてのノード分類が完了してステップＳ２０４において否定結果が得られたとすると、ステップＳ２１４に進むことになる。ステップＳ２１４においては、これまでの処理により作成されたとされるノードテーブルが例えばＲＡＭにおいて記憶保持されるように処理を実行する。以降は、例えばこのノードテーブルに格納されたノード分類結果を利用して所要のシステム動作を実行するようにされる。
【０１９０】
５．ＳＴＲの電源オフ連動機能
５−１．概要
例えば先に図１に示したシステムにおいては、ＳＴＲ６０がその中心的役割を果たす。つまり、ＳＴＲ６０は、他の機器から送信されてくるオーディオソースとしてのデータを選択的に入力して音声として出力することが可能とされ、また、他の機器に対してシステム的な動作が得られるように所要のコマンドを送信することも行うことができるようにされている。
【０１９１】
ここで、図１に示したシステムがユーザにより使用されていない場合として、例えばＳＴＲ６０の電源はオンとなっているが、ＳＴＲ６０以外の或る機器の電源がオフ（スタンバイ）となっている場合を考えてみる。
このような場合には、例えば電力消費をできるだけ抑えることなどを考慮して、例えば少なくともＳＴＲ６０の電源もオフとすることが好ましい。そこで、本実施の形態においては、上記のようにしてＳＴＲ６０以外の或る特定の機器の電源がオフの状態にあるときには、これに応じて、ＳＴＲ６０の電源もオフとするように構成される。これにより、他の機器がオフ状態にあれば、これに連動して、ＳＴＲ６０も自動的にオフ状態にすることができ、電源の切り忘れによる無駄な電力消費はなくなり、また、ユーザが手動操作で電源をオフにする手間も省けることになる。
【０１９２】
５−２．ＰＯＷＥＲ ＳＴＡＴＵＳ ｃｏｍｍｍａｎｄ
そして、ＳＴＲ６０が上記のようにして他機器の電源状態に応じて自身の電源コントロールを行うのには、他機器の現在の電源状態を知ることが必要となるのであるが、このためにＳＴＲ６０は、ＡＶ／Ｃコマンドの１つであるＰＯＷＥＲＳＴＡＴＵＳ ｃｏｍｍｍａｎｄを使用して他の機器との通信を行うようにされる。ＰＯＷＥＲ ＳＴＡＴＵＳ ｃｏｍｍｍａｎｄは、Ｃｏｎｔｒｏｌｌｅｒ（この場合にはＳＴＲ６０）がＴａｒｇｅｔ（他の機器）に対して、電源状態の通知を要求するためのコマンドとして定義されている。
【０１９３】
図３０はＰＯＷＥＲ ＳＴＡＴＵＳ ｃｏｍｍｍａｎｄのデータ構造を示している。なお、この図においては、図２０に示したＷｒｉｔｅ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔ（ＡＶ／Ｃコマンドパケット）における、ｄａｔａｆｉｅｌｄ内の構造が示される。また、図２０において説明した内容については、ここでの説明は省略する。
【０１９４】
図３０に示すように、ＰＯＷＥＲ ＳＴＡＴＵＳ ｃｏｍｍｍａｎｄとしては、ＣＴＳの４ビットの領域に対して「０ｈ」を格納し、ｃｔｙｐｅの４ビットの領域に対しては「１ｈ」を格納することで、ＡＶ／Ｃ ＳＴＡＴＵＳ ｃｏｍｍｍａｎｄであることが示される。そして、ｏｐｃｏｄｅの８ビットの領域に対しては、ＰＯＷＥＲ ｃｏｍｍｍａｎｄであることを示す「Ｂ２ｈ」を格納する。このようにして上記各値が格納されることで、このＡＶ／ＣコマンドパケットがＰＯＷＥＲ ＳＴＡＴＵＳ ｃｏｍｍｍａｎｄであることが示される。
【０１９５】
そして、ｏｐｃｏｄｅに続くｏｐｅｒａｎｄ［０］としての８ビットの領域に、電源状態を示すpower_stateの値を格納するものとされる。ＰＯＷＥＲ ＳＴＡＴＵＳ ｃｏｍｍｍａｎｄの場合には、ここに「７Ｆｈ」を格納しておくものとされ、Ｔａｒｇｅｔから、ＲＥＳＰＯＮＳＥとしてコマンドを返送する際に、このＴａｒｇｅｔとしての機器の現在の電源状態に対応する値に置き換えが行われる。
【０１９６】
そして、上記ＰＯＷＥＲ ＳＴＡＴＵＳ ｃｏｍｍｍａｎｄを受信したＴａｒｇｅｔにおいては、これに応答して図３１に示すＲＥＳＰＯＮＳＥを、Ｃｏｎｔｒｏｌｌｅｒに対して返送する。
このＲＥＳＰＯＮＳＥとしては、図示するように、power_stateの領域に対して、「７０ｈ」又は「６０ｈ」の値を格納する。このpower_stateの値が「７０ｈ」であれば、Ｔａｒｇｅｔとしての機器の現在の電源状態がオンであることを示し、「６０ｈ」であればオフであることを示す。Ｃｏｎｔｒｏｌｌｅｒでは、このＲＥＳＰＯＮＳＥにおけるpower_stateの値を参照することで、Ｔａｒｇｅｔとしての他の機器の電源状態がオンであるのかオフであるのかを知ることができる。
【０１９７】
５−３．処理動作
図３２のフローチャートは、ＳＴＲ６０における電源連動制御のための処理動作を示している。なお、この処理はシステムコントローラ７０が実行する。
また、この処理は、ＣｏｎｔｒｏｌｌｅｒがＴａｒｇｅｔに対して実行するものとされ、この場合、ＣｏｎｔｒｏｌｌｅｒはＳＴＲ６０となる。また、Ｔａｒｇｅｔは、ＳＴＲ６０がその電源状態を監視する対象として選択した特定の他機器とされる。これは、例えばファクトリープリセットとして予め設定されていてもよいし、また、例えばバスリセットごとの機器の接続状況やユーザの操作によって予め設定できるようにしてもよい。
また、この電源状態の監視対象の機器選択にあたっては、前述したノード分類により分類されたグループを基準とすることも考えられる。この場合の機器選択の仕方としては各種考えられるのであるが、一例としては、ノード分類番号＃１として含まれるＳＴＲ対応ＣＤ機３０を対象としたり、ノード分類番号＃２として含まれるＳＴＲ対応ＭＤ機１とすることなども考えられる。
【０１９８】
先ず、図３２に示す処理にあっては、ステップＳ４０１において、ＳＴＲ６０自身としての機器の状態が所定の一定の条件を満たしているか否かについて判別を行っている。
ここで判別される条件としては、例えば次のようになる
１．メイン電源がオン状態にあること
２．予め決められた一定時間以上操作されていないこと
３．電源連動設定がオン（有効）に設定されていること
４．タイマ機能及びスリープ機能が現在有効となっていないこと
本実施の形態としては、例えば上記した各条件をすべて満たした場合にのみ、以降の電源連動制御のための処理を実行するようにされる。これはつまり、現在の機器の状態や、ユーザ操作による設定状況などとして、電源を自動オフさせることが適切ではないような場合にも電源オフ連動動作が働いてしまって、かえって使い勝手が悪くなるようなことが無いように配慮しているものである。
【０１９９】
上記ステップＳ４０１において否定結果が得られたときには、そのまま待機することになるが、肯定結果が得られた場合にはステップＳ４０２の処理に進む。ステップＳ４０２においては、上述したようにして、電源状態の監視対象機器として設定されている機器をＴａｒｇｅｔとして、このＴａｒｇｅｔに対して、ＰＯＷＥＲ ＳＴＡＴＵＳ ｃｏｍｍｍａｎｄを送信し、次のステップ４０３においてＲＥＳＰＯＮＳＥを受信する。
【０２００】
次のステップＳ４０４においては、ＲＥＳＰＯＮＳＥにおけるpower_stateの値を参照することで、現在Ｔａｒｇｅｔのメイン電源がオフ状態にあるか否かについて判別する。
ここで否定結果が得られた場合にはステップＳ４０６に進む。ステップＳ４０６においては、或る決められた一定時間待機してステップＳ４０１の処理に戻る。つまり、ＳＴＲ６０の機器としての状態が一定の条件を満たしているとされた場合において、Ｔａｒｇｅｔの電源がオン状態にあるとされるうちは、ステップＳ４０２→Ｓ４０３によるＰＯＷＥＲ ＳＴＡＴＵＳ ｃｏｍｍｍａｎｄの送信及びＲＥＳＰＯＮＳＥの受信を一定時間ごとに繰り返し行う。このようにして、Ｔａｒｇｅｔの電源状態をみにいくための処理を一定時間ごとに繰り返し実行することで、本実施の形態では、Ｔａｒｇｅｔの電源状態がオフとなったときには、これに応じて、できるだけ早期にＳＴＲの電源がオフに切り換えられるように制御するものである。
また、上記したように一定時間ごとにコマンドの授受を行うようにした場合には、このコマンド送信のために比較的頻繁にバス帯域を使用することになるので、例えば実状としては、データ転送速度が低速なバスでは負担が重くなる可能性が或る。しかし、本実施の形態では、これまでのデータインターフェイスよりもデータ転送速度が高速とされるＩＥＥＥ１３９４データインターフェイスを採用していることから、バスの負担も軽く、例えば同時に行われる他帯域のデータの送受信の安定も維持できる。
なお、ステップＳ４０６において待機すべき時間としては、上記したことを考慮して適切であるとされる時間長が任意に設定されればよいのであるが、一例としては、500ms程度とされる。また、各機器のシステムコントローラの処理能力によっては、10ms程度にまで短縮することも可能とされる。
【０２０１】
一方、ステップＳ４０４において、Ｔａｒｇｅｔがオフ状態にあることが判別された場合にはステップＳ４０５に進んで、自身のメイン電源をオフとしてスタンバイ状態とするように制御を実行する。これにより、他の機器の電源状態がオフであるのに連動して、ＳＴＲ６０自身もメイン電源をオフとする動作が得られる。
【０２０２】
ところで、ＳＴＲ６０が電源監視対象とするＴａｒｇｅｔとしての機器について、例えば一定時間以上停止状態であったり、また一定時間以上ユーザによる操作が行われないなどの条件が満たされる場合には、その機器自身がメイン電源をオフとする機能を与えたとする。
例えばこのような機器がＳＴＲ対応ＣＤ機３０であるとすれば、このＳＴＲ対応ＣＤ機３０が一定時間以上再生動作を行っておらず、また一定時間以上ユーザによる操作が行われないなどしたときには、自機のメイン電源をオフとすることになる。
そして、このようなＴａｒｇｅｔ側の機能と、上述したＳＴＲ６０の電源連動オフ機能とを併用すれば、先ず、Ｔａｒｇｅｔとしての機器がメイン電源を自動的にオフとすると、これに連動してＣｏｎｔｒｏｌｌｅｒであるＳＴＲ６０もメイン電源を自動的にオフにするという動作が得られる。つまりＣｏｎｔｒｏｌｌｅｒとＴａｒｇｅｔの関係にある少なくとも２台の機器のメイン電源を、すべて自動的にオフにするというシステム動作を得ることができ、ＳＴＲ６０の電源連動オフ機能はさらに有効に活用されることにもなる。
【０２０３】
なお、実際にＳＴＲ６０が電源状態を監視すべき機器としては、ＳＴＲ６０とオーディオコンポーネントシステム的機能を有するようにされるＳＴＲ対応ＣＤ機３０、ＳＴＲ対応ＭＤ機１などを対象にすることが先ず考えられるのであるが、ＰＯＷＥＲ ｃｏｍｍａｎｄは、ＡＶ／ＣコマンドとしてＧｅｎｅｒａｌの範疇で規定されているものであることから、ＳＴＲ対応機器以外の同一メーカ機器はもちろんのこと、さらには、ＩＥＥＥ１３９４バス上に存在する他メーカの機器を対象とすることも可能とされる。
【０２０４】
また、電源連動オフ機能のための処理動作についても先にフローチャートにより示した処理に限定されるものではなく、例えばそのプログラムの実際などは適宜変更されて構わないものである。
これについては、例えば先に説明したノード分類処理としても同様であり、ノード分類処理としては、最終的にＩＥＥＥ１３９４バス上に接続される各機器についての分類が行われてその結果を反映したノードテーブルが作成されればよい。
また、ここではＳＴＲ６０を中心としたシステムが組まれていることで、ＳＴＲ６０が電源連動オフ機能を有するものとして説明しているが、ＩＥＥＥ１３９４バスを使用したシステム構成としても各種考えられるもので、電源オフ連動機能を有する機種についても本発明としては限定されるものではない。
また、ＩＥＥＥ１３９４の規格以外のデジタルデータインターフェイスに対しても適用が可能である。
【０２０５】
【発明の効果】
以上説明したように本発明では、例えばデータバスを利用して組まれるＡＶシステムにおいて、その中心となるＳＴＲ（情報処理機器）が、他の機器とＰＯＷＥＲ ｃｏｍｍａｎｄの授受を行うことによって、この他の機器の電源がオフであれば自身も電源をオフとするように動作する。
これによって、例えば、システムにおける各機器がそれぞれデータバス上で独立的に存在するものと認識され、また、連動機能を有する電源コンセント等と接続されていない場合であっても、システムとしての電源コントロール機能を与えることが可能となるものである。また、本発明では、システム内において中心となるＳＴＲが、他の機器の電源状態に従って自機の電源状態をコントロールするために、例えば、ＳＴＲよりも先に他の機器の電源がオフにされたような場合に、これに応じてＳＴＲが自動的に電源をオフにするという、これまでのシステムにはない動作が得られる。これにより、システムの電源の連動コントロールとしてはより充実したものとなる。そしてこれはＳＴＲにおける消費電力量を抑えることにもつながる。
【０２０６】
また、本発明では、ＳＴＲ自身が一定の条件を満たす状態となったときに、上記した他機器との電源オフ連動を行うようにされるのであるが、これは換言すれば、例えばＳＴＲの電源をオンのままにしておくことが適切であるような状況の場合には、電源オフ連動動作を行わないようにしているものであり、利便性がさらに向上される。
【０２０７】
また、他の機器の電源状態のチェックを一定時間ごとに繰り返すようにすれば、できるだけ早期にＳＴＲの電源をオフさせる動作が得られることになり、上記した省電力化を促進させることができる。また、電源オフ連動機能もより高められる。
【０２０８】
そして、例えばＳＴＲと他の機器の通信フォーマットとして、これまでのデータインターフェイスのなかでは、高速とされるＩＥＥＥ１３９４インターフェイスを採用することで、他の機器の電源状態をチェックするためのコマンドの送受信を例えば比較的頻繁に行うようにしたとしても、データバスへの負担は軽く、例えばオーディオデータ等をはじめとするソース情報の送受信の安定を確保することができる。そして、本発明としての技術を容易に実現することも可能となるものである。
【図面の簡単な説明】
【図１】本発明の実施の形態としてのＡＶシステムの構成例を示す斜視図である。
【図２】ＳＴＲのフロントパネルの様子を示す正面図である。
【図３】ＳＴＲ対応ＣＤ機のフロントパネルの様子を示す正面図である。
【図４】ＳＴＲ対応ＭＤ機のフロントパネルの様子を示す正面図である。
【図５】ＳＴＲの内部構成例を示すブロック図である。
【図６】ＳＴＲ対応ＣＤ機の内部構成例を示すブロック図である。
【図７】ＳＴＲ対応ＭＤ機の内部構成例を示すブロック図である。
【図８】本実施の形態に対応するＩＥＥＥ１３９４のスタックモデルを示す説明図である。
【図９】ＩＥＥＥ１３９４に使用されるケーブル構造を示す説明図である。
【図１０】ＩＥＥＥ１３９４における信号伝送形態を示す説明図である。
【図１１】ＩＥＥＥ１３９４におけるバス接続規定を説明するための説明図である。
【図１２】ＩＥＥＥ１３９４システム上でのＮｏｄｅ ＩＤ設定手順の概念を示す説明図である。
【図１３】ＩＥＥＥ１３９４におけるＰａｃｋｅｔ送信の概要を示す説明図である。
【図１４】Ａｓｙｎｃｈｒｏｎｏｕｓ通信における基本的な通信規則（トランザクションルール）を示す処理遷移図である。
【図１５】ＩＥＥＥ１３９４バスのアドレッシング構造を示す説明図である。
【図１６】ＣＩＰの構造図である。
【図１７】プラグにより規定された接続関係例を示す説明図である。
【図１８】プラグコントロールレジスタを示す説明図である。
【図１９】Ａｓｙｎｃｈｒｏｎｏｕｓ通信において規定されるＷｒｉｔｅ Ｔｒａｎｓａｃｔｉｏｎを示す処理遷移図である。
【図２０】Ａｓｙｎｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔ（ＡＶ／Ｃコマンドパケット）の構造図である。
【図２１】Ａｓｙｎｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔにおける、ｃｔｙｐｅ／ｒｅｓｐｏｎｃｅの定義内容を示す説明図である。
【図２２】Ａｓｙｎｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔにおける、ｓｕｂｕｎｉｔ＿ｔｙｐｅと、ｏｐｃｏｄｅの定義内容例を示す説明図である。
【図２３】Ａｓｙｎｃｈｒｏｎｏｕｓ通信におけるプラグ構造を示す説明図である。
【図２４】Ａｓｙｎｃｈｒｏｎｏｕｓ通信におけるプラグアドレス構造を示す説明図である。
【図２５】Ａｓｙｎｃｈｒｏｎｏｕｓ通信におけるプラグアドレス構造を示す説明図である。
【図２６】Ａｓｙｎｃｈｒｏｎｏｕｓ通信におけるプラグ間での処理を示す説明図である。
【図２７】Ａｓｙｎｃｈｒｏｎｏｕｓ Ｃｏｎｎｅｃｔｉｏｎとしての送信手順を示す説明図である。
【図２８】ノード分類処理を示すフローチャートである。
【図２９】ノード分類処理における種別判定処理を示すフローチャートである。
【図３０】 POWER STATUS commandのデータ構造を示す説明図である。
【図３１】 POWER STATUS commandのRESPONSEのデータ構造を示す説明図である。
【図３２】ＳＴＲにおいて実行される電源オフ連動のための処理を示すフローチャートである。
【符号の説明】
１ ＳＴＲ対応ＭＤ機器、３０ ＳＴＲ対応ＣＤ機 ６０ ＳＴＲ、１２０，１３０，１５０ 電源キー、６１，４９，２５ ＩＥＥＥ１３９４インターフェイス、７５，４７，２４ 表示部、１２７，１５６，１４０ ディスプレイキー
Claims (17)
- それぞれ電源を独立して入力可能とされ、所定の通信フォーマットによるデータバスを介してソース情報を送信出力するソース出力機器を含む電子機器と、上記ソース出力機器から送信されてきた上記ソース情報を入力する情報処理機器とを備えて成る電子機器システムにおいて、
上記情報処理機器は、
本情報処理機器について所定の条件を満たした状態にあるか否かについて自動で判別する条件判別手段と、
上記条件判別手段により上記所定の条件を満たした状態にあると判別されたことに応じて、上記ソース出力機器のうち特定の１以上のソース出力機器ごとに対して、上記データバスを介して、電源状態がオフであるか否かについての通知を要求する要求コマンドを送信する要求コマンド送信手段と、
上記要求コマンドを受信したことに応じてソース出力機器から送信された、このソース出力機器の電源状態がオフであるか否かについての通知内容を有する応答コマンドを受信する受信手段と、
上記受信手段により受信した応答コマンドの通知内容として、電源状態がオフであることを示しているか否かについて判別する電源状態判別手段と、
上記電源状態判別手段により電源状態がオフであることを示していると判別された場合に、自機の電源をオンからオフに切り換えるように制御する制御手段とを備える、
電子機器システム。 - 上記要求コマンド送信手段は、
上記要求コマンドを送信する対象となる送信対象のソース出力機器として複数を設定している場合には、これらの複数のソース出力機器のそれぞれに対して上記要求コマンドを送信する、
請求項１に記載の電子機器システム。 - 上記条件判別手段は、
上記情報処理機器自身の電源状態がオンであるときに上記所定の条件を満たしていると判別する、
請求項１又は請求項２に記載の電子機器システム。 - 上記条件判別手段は、
上記情報処理機器が予め定められた一定時間以上操作されていない状態であるときに上記所定の条件を満たしていると判別する、
請求項１乃至請求項３の何れかに記載の電子機器システム。 - 上記条件判別手段は、
上記情報処理機器に対して電源連動が有効に設定されている場合に上記所定の条件を満たしていると判別する、
請求項１乃至請求項４の何れかに記載の電子機器システム。 - 上記条件判別手段は、
上記情報処理機器に対してタイマ機能及びスリープ機能が有効に設定されている場合に上記所定の条件を満たしていると判別する、
請求項１乃至請求項５の何れかに記載の電子機器システム。 - 上記要求コマンド送信手段は、
上記電源状態判別手段により、ソース出力機器の電源状態がオフであると判別されるまで、そのソース出力機器に対して、一定時間ごとに上記要求コマンドを送信する、
請求項１乃至請求項６の何れかに記載の電子機器システム。 - 上記ソース出力機器は、
一定時間以上にわたって停止状態にある、又は、一定時間以上にわたって操作が行われなかった場合には、電源状態をオンからオフとする、ソース出力機器側制御手段を備える、
請求項１乃至請求項７の何れかに記載の電子機器システム。 - 上記通信フォーマットは、ＩＥＥＥ１３９４データインターフェイスである、
請求項１乃至請求項８の何れかに記載の電子機器システム。 - それぞれの電子機器が独立して電源を入力可能とされ、所定の通信フォーマットによるデータバスを介して他の電子機器と接続されることで情報の送受信が可能なように形成される電子機器システムにおける情報処理機器として、
上記他の電子機器のうちのソース出力機器としての電子機器から送信出力されるソース情報を入力するソース情報入力手段と、
本情報処理機器について所定の条件を満たした状態にあるか否かについて自動で判別する条件判別手段と、
上記条件判別手段により上記所定の条件を満たした状態にあると判別されたことに応じて、上記ソース出力機器のうち特定の１以上の電子機器に対して、上記データバスを介して、このソース出力機器の電源状態がオフであるか否かについての通知を要求する要求コマンドを送信する要求コマンド送信手段と、
上記要求コマンドを受信したことに応じてソース出力機器から送信された、電源状態がオフであるか否かについての通知内容を有する応答コマンドを受信する受信手段と、
上記受信手段により受信した応答コマンドの通知内容として、電源状態がオフであることを示しているか否かについて判別する電源状態判別手段と、
上記電源状態判別手段により電源状態がオフであることを示していると判別された場合に、自機の電源をオンからオフに切り換えるように制御する制御手段と、
を備える情報処理機器。 - 上記要求コマンド送信手段は、
上記要求コマンドを送信する対象となる送信対象のソース出力機器として複数を設定している場合には、これらの複数のソース出力機器のそれぞれに対して上記要求コマンドを送信する、
請求項１０に記載の情報処理機器。 - 上記条件判別手段は、
上記情報処理機器自身の電源状態がオンであるときに上記所定の条件を満たしていると判別する、
請求項１０又は請求項１１に記載の情報処理機器。 - 上記条件判別手段は、
上記情報処理機器が予め定められた一定時間以上操作されていない状態であるときに上記所定の条件を満たしていると判別する、
請求項１０乃至請求項１２の何れかに記載の情報処理機器。 - 上記条件判別手段は、
上記情報処理機器に対して電源連動が有効に設定されている場合に上記所定の条件を満たしていると判別する、
請求項１０乃至請求項１３の何れかに記載の情報処理機器。 - 上記条件判別手段は、
上記情報処理機器に対してタイマ機能及びスリープ機能が有効に設定されている場合に上記所定の条件を満たしていると判別する、
請求項１０乃至請求項１４の何れかに記載の情報処理機器。 - 上記要求コマンド送信手段は、
上記電源状態判別手段により、ソース出力機器の電源状態がオフであると判別されるまで、そのソース出力機器に対して、一定時間ごとに上記要求コマンドを送信する、
請求項１０乃至請求項１５の何れかに記載の情報処理機器。 - 上記通信フォーマットは、ＩＥＥＥ１３９４データインターフェイスである、
請求項１０乃至請求項１６の何れかに記載の情報処理機器。
Priority Applications (6)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000050515A JP4403331B2 (ja) | 2000-02-22 | 2000-02-22 | 電子機器システム、情報処理機器 |
| KR1020010008158A KR100674169B1 (ko) | 2000-02-22 | 2001-02-19 | 전자기기 시스템, 제어기기와 동기화된 전원 제어방법 |
| DE60122403T DE60122403T2 (de) | 2000-02-22 | 2001-02-20 | Verfahren zur Steuerung und Synchronisierung der Stromversorgung in einem System elektronischer Geräte |
| EP01104032A EP1128561B1 (en) | 2000-02-22 | 2001-02-20 | Method for controlling and synchronizing power supply in a system of electronic devices |
| US09/788,637 US6772354B2 (en) | 2000-02-22 | 2001-02-21 | System and method for managing the power state of a controlling device according to an indication of the power state of a source output device |
| CNB011165618A CN100409359C (zh) | 2000-02-22 | 2001-02-22 | 电子设备系统、控制设备以及同步电源控制方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2000050515A JP4403331B2 (ja) | 2000-02-22 | 2000-02-22 | 電子機器システム、情報処理機器 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2001236149A JP2001236149A (ja) | 2001-08-31 |
| JP4403331B2 true JP4403331B2 (ja) | 2010-01-27 |
Family
ID=18572285
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000050515A Expired - Fee Related JP4403331B2 (ja) | 2000-02-22 | 2000-02-22 | 電子機器システム、情報処理機器 |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US6772354B2 (ja) |
| EP (1) | EP1128561B1 (ja) |
| JP (1) | JP4403331B2 (ja) |
| KR (1) | KR100674169B1 (ja) |
| CN (1) | CN100409359C (ja) |
| DE (1) | DE60122403T2 (ja) |
Families Citing this family (27)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| IES20010399A2 (en) * | 2000-05-16 | 2002-02-06 | Richmount Computers Ltd | A protocol for a power supply unit controller |
| US6985979B2 (en) * | 2001-12-17 | 2006-01-10 | Matsushita Electric Industrial Co., Ltd. | Digital data processing device, bus controlling method, bus controlling program and recording medium |
| JP3685151B2 (ja) * | 2002-04-26 | 2005-08-17 | セイコーエプソン株式会社 | クロック制御回路、データ転送制御装置及び電子機器 |
| JP3685150B2 (ja) * | 2002-04-26 | 2005-08-17 | セイコーエプソン株式会社 | クロック制御回路、データ転送制御装置及び電子機器 |
| US7304689B2 (en) * | 2002-06-06 | 2007-12-04 | Microtune (Texas), L.P. | Single chip tuner for multi receiver applications |
| JP3730599B2 (ja) * | 2002-06-27 | 2006-01-05 | 株式会社東芝 | サーバ装置および状態制御方法 |
| CN1666285A (zh) * | 2002-06-28 | 2005-09-07 | 皇家飞利浦电子股份有限公司 | 带有遥控设备的重放系统 |
| US7069457B2 (en) * | 2002-06-28 | 2006-06-27 | Intel Corporation | Automatic mobile device scalable synchronization based on battery state |
| JP2004056376A (ja) * | 2002-07-18 | 2004-02-19 | Fujitsu Ltd | 半導体装置及びデータ転送制御方法 |
| KR100626677B1 (ko) * | 2002-07-29 | 2006-09-22 | 삼성전자주식회사 | 통신 프로토콜을 이용하여 동작을 제어하는 제어장치 및 이를 적용한 ａ／ｖ 복합장치 |
| ES2569853T3 (es) | 2003-06-25 | 2016-05-12 | Biedermann Technologies Gmbh & Co. Kg | Diseño de integración tisular para la fijación de implantes sin soldadura |
| CN1293442C (zh) * | 2003-07-14 | 2007-01-03 | 明基电通股份有限公司 | 具有免开机播放功能的计算机系统及其转接器 |
| JP4484204B2 (ja) * | 2004-03-09 | 2010-06-16 | 株式会社ティラド | 排熱回収用熱交換器 |
| US7346788B2 (en) * | 2004-06-04 | 2008-03-18 | Broadcom Corporation | Method and system for monitoring module power information in a communication device |
| KR100662867B1 (ko) * | 2004-11-09 | 2007-01-02 | 삼성전자주식회사 | 아날로그 오디오의 디지털 변환장치 |
| JP2007036318A (ja) * | 2005-07-22 | 2007-02-08 | Fuji Xerox Co Ltd | 画像処理システム |
| JP2007110430A (ja) * | 2005-10-13 | 2007-04-26 | Sharp Corp | 音声処理装置およびそれを備えた表示装置 |
| JP2007323137A (ja) | 2006-05-30 | 2007-12-13 | Funai Electric Co Ltd | 電子機器システム及びコントローラ |
| JP2009141720A (ja) * | 2007-12-07 | 2009-06-25 | Hitachi Ltd | 映像表示装置、表示パネル及び映像処理装置 |
| JP2009151685A (ja) * | 2007-12-21 | 2009-07-09 | Fujitsu Ltd | ディスクアレイ装置管理システム、ディスクアレイ装置、ディスクアレイ装置の制御方法および管理サーバ |
| JPWO2009101804A1 (ja) * | 2008-02-13 | 2011-06-09 | パナソニック株式会社 | 省電力システム |
| CN102412716B (zh) * | 2010-09-25 | 2016-06-15 | Ge医疗系统环球技术有限公司 | 用于升级包的电源管理装置和升级包 |
| CN102572063B (zh) * | 2010-12-15 | 2014-11-05 | 联想(北京)有限公司 | 系统状态控制方法及便携终端 |
| CN103064488A (zh) * | 2011-10-21 | 2013-04-24 | 鸿富锦精密工业（深圳）有限公司 | 电源控制电路 |
| EP2629543A1 (en) * | 2012-02-20 | 2013-08-21 | Thomson Licensing | Method and controller for device power state control |
| JP6214897B2 (ja) * | 2013-03-29 | 2017-10-18 | 富士通株式会社 | 表示装置、表示システムおよび電源状態制御方法 |
| CN103543359B (zh) * | 2013-10-28 | 2016-04-13 | 中国电子科技集团公司第四十一研究所 | 一种微波测量仪器中自定义测试功能序列的实现方法 |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4386416A (en) * | 1980-06-02 | 1983-05-31 | Mostek Corporation | Data compression, encryption, and in-line transmission system |
| US4677566A (en) * | 1984-10-18 | 1987-06-30 | Burroughs Corporation | Power control network for multiple digital modules |
| JPH04100134A (ja) * | 1990-08-18 | 1992-04-02 | Fujitsu Ltd | サーバシステムの電源制御方式 |
| JPH05158585A (ja) * | 1991-12-04 | 1993-06-25 | Mitsubishi Electric Corp | ワークステーションの電源制御方式 |
| US5689244A (en) * | 1994-06-24 | 1997-11-18 | Sony Corporation | Communication system and electronic apparatus |
| JP3862400B2 (ja) * | 1998-02-18 | 2006-12-27 | キヤノン株式会社 | 通信装置 |
| JPH11145993A (ja) * | 1997-11-06 | 1999-05-28 | Canon Inc | 通信システム、装置及び方法 |
| JP2907198B1 (ja) * | 1997-12-19 | 1999-06-21 | 日本電気株式会社 | プライベートｌａｎを利用した無停電電源装置における電源制御方式 |
| JP2000030423A (ja) * | 1998-07-16 | 2000-01-28 | Sony Corp | 遠隔制御装置及び遠隔制御方法 |
-
2000
- 2000-02-22 JP JP2000050515A patent/JP4403331B2/ja not_active Expired - Fee Related
-
2001
- 2001-02-19 KR KR1020010008158A patent/KR100674169B1/ko not_active IP Right Cessation
- 2001-02-20 EP EP01104032A patent/EP1128561B1/en not_active Expired - Lifetime
- 2001-02-20 DE DE60122403T patent/DE60122403T2/de not_active Expired - Lifetime
- 2001-02-21 US US09/788,637 patent/US6772354B2/en not_active Expired - Fee Related
- 2001-02-22 CN CNB011165618A patent/CN100409359C/zh not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US6772354B2 (en) | 2004-08-03 |
| DE60122403D1 (de) | 2006-10-05 |
| EP1128561A2 (en) | 2001-08-29 |
| KR100674169B1 (ko) | 2007-01-24 |
| CN1321984A (zh) | 2001-11-14 |
| CN100409359C (zh) | 2008-08-06 |
| EP1128561A3 (en) | 2004-08-04 |
| EP1128561B1 (en) | 2006-08-23 |
| KR20010083178A (ko) | 2001-08-31 |
| DE60122403T2 (de) | 2007-10-11 |
| US20010029587A1 (en) | 2001-10-11 |
| JP2001236149A (ja) | 2001-08-31 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4449141B2 (ja) | 電源制御装置、電源制御システム | |
| JP4403331B2 (ja) | 電子機器システム、情報処理機器 | |
| US20050165981A1 (en) | Controlling method for transmitting reserve commands from a controller to target devices | |
| EP1014364B1 (en) | Reception method over a chain of interconnected AV apparatus | |
| JP4281201B2 (ja) | 制御装置、及び制御方法 | |
| KR101088102B1 (ko) | 전자기기와 인증 사용정보 갱신방법 | |
| EP1061708A2 (en) | An external device control apparatus and an external device control method | |
| KR101165316B1 (ko) | 수신장치 및 수신방법 | |
| JP2003289304A (ja) | 信号処理装置、信号処理方法 | |
| JP2002033751A (ja) | 電子機器、電子機器管理方法 | |
| JP2000357386A (ja) | 編集装置及び操作装置 | |
| JP2001236772A (ja) | 電子機器システム、電子機器 | |
| JP2001250370A (ja) | 電子機器システム、及び電子機器 | |
| JP2000209617A (ja) | 通信動作検査方法及び通信動作検査装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20061218 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20090410 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090414 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090610 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20091006 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20091019 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121113 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20121113 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131113 Year of fee payment: 4 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |