JP4260366B2

JP4260366B2 - ネットワークにおける機器のアップグレード及び拡張方法

Info

Publication number: JP4260366B2
Application number: JP2000528034A
Authority: JP
Inventors: リー、ロジャー、ジェイ
Original assignee: ソニーエレクトロニクスインク
Priority date: 1998-01-06
Filing date: 1998-12-17
Publication date: 2009-04-30
Anticipated expiration: 2018-12-17
Also published as: KR20010033877A; ATE223634T1; US6052750A; DE69807750D1; TW406509B; EP1044536B1; WO1999035770A2; DE69807750T2; AU1922899A; JP2002501239A; WO1999035770A3; EP1044536A2

Description

【０００１】
【技術分野】
本発明の分野はオーディオビデオシステムに関する。特に、本発明は、多数の電子機器（electric device）をネットワークで接続する（networking）ことにより１つのオーディオビデオシステムを形成することに関する。本発明の一実施例では、更新可能なデバイス制御モジュール（device control module）を有するホームオーディオ／ビデオネットワーク（home audio/video network）を開示する。
【０００２】
【背景技術】
一般的なホームオーディオビジュアル機器のセット（home audiovisual equipment set up）には多数のコンポーネント（component）が含まれている。例えば、ラジオ受信機、ＣＤプレーヤ、スピーカ、テレビジョン受像機、ＶＴＲ、テープデッキ等がある。これらの各コンポーネントは、各種の接続線（wire）を介して互いに接続されている。通常、あるコンポーネントがホームオーディオビジュアルシステムの中心コンポーネントとなる。これは通常、ラジオ受信機又はチューナである。チューナは、他のコンポーネントを接続するための多数の特別な入力端子（specific input）を備えている。また、チューナは、これらのコンポーネントを限定的（limited degree）に制御（controllability）し、また相互運用（interoperability）させるための、対応した数の制御ボタン又は制御スイッチを備えている。制御ボタン及び制御スイッチは、通常、チューナの前面に配設されている。多くの場合、これらの制御ボタン及び制御スイッチの幾つか又は全ては、手に持てるサイズのリモートコントローラ（hand held remote control unit）にも設けられている。ユーザは、チューナの前面の制御ボタン及び制御スイッチを操作して、あるいは手に持てるサイズのリモートコントローラのボタンを操作して、ホームオーディオビジュアルシステムを制御する。
【０００３】
この従来のホームオーディオビジュアルシステムのパラダイム（paradigm）は、非常に普及している。民生用電子機器（consumer electric device）がより高性能で複雑になるにつれて、最新の、より高性能の機器の需要が高まる。新たな機器が現れて普及すると、消費者は、その機器を購入して、ホームオーディオビジュアルシステムに接続する。通常、これらの機器のうちの最新で高性能なもの（例えばデジタルオーディオテープレコーダ、ＤＶＤプレーヤ、デジタルビデオカメラ等）は、非常に高価である。消費者は、新たな機器を購入すると、多くの場合、その新たな機器を既存の古い機器（例えばカセットテープデッキ、ＣＤプレーヤ等）とともにシステムに接続するだけである。新たな機器は、チューナの背面の空いている入力端子、又はチューナに接続された他の機器に接続される。消費者（例えばユーザ）は、チューナの制御ボタンによって、あるいは新たな機器自体の前面にある制御ボタン及び制御スイッチによって、あるいは新たな機器の全く新しい独立した個別のリモートコントローラによって、その新たな機器を制御する。
【０００４】
ホームオーディオビジュアルシステムのための数多くの新たな民生用電子機器が開発され、これらの機器がますます高性能で高機能になるのに伴い、従来のパラダイムに関して多くの問題が生じている。このような問題の１つは、ホームオーディオビジュアルシステムの機器間の非互換性である。ある製造業者の民生用電子機器は、多くの場合、他の製造業者の同じような機器とは、オーディオビジュアルシステムへの接続方法が異なる。例えば、ある製造業者が製造したチューナを、他の製造業者が製造したテレビジョン受像機に適切に接続できないことがある。
【０００５】
また、ある機器が他の機器よりも新しい場合、別の非互換性の問題が生じることがある。例えば、ある新しい機器には、より高度な遠隔操作機能を可能とするハードウェア（例えば特別の入力及び出力）が組み込まれている。このハードウェアは、システム内の古い機器では使用することができないことがある。また、例えば、古いチューナは、幾つかの新しい機器（例えばミニディスクプレーヤ、ＶＴＲ等）に適した入力端子を備えていないことがあり、またシステムの全ての機器のための十分な入力端子を備えていないこともある。
【０００６】
もう一つの問題は、オーディオビジュアルシステム内の異なる機器に対する機能的サポートがないことである。例えば、テレビジョン受像機は高度なサウンドフォーマット（例えばサラウンドサウンド、ステレオ等）をサポートするが、古くて性能の低いチューナがこのような機能をサポートしないときには、高度なサウンドフォーマットの恩恵が失われることになる。
【０００７】
もう一つの問題は、ホームオーディオビジュアルシステム内における新たな及び異なる機器に対する制御方法が増えていることである。例えば、異なる製造業者の同様の機器が、同様のタスク（例えばＶＴＲの時計の設定、後の番組を録画するようにＶＴＲをプログラムする等）を行うのに、それぞれ異なる制御ボタン及び制御スイッチの形式を有している。さらに、オーディオビジュアルシステムに接続された新たな機器には、それぞれ専用のリモートコントローラが添付されていることが多く、ユーザは、操作の情報を得て、操作方法を学ばなければならない。
【０００８】
ネットワーク（networking）及びインタフェースの技術の出現（例えばＩＥＥＥ１３９４シリアル通信バス及びデジタルシステムが広く採用されていること）により、これらの問題は解決される見込みがあるが、高機能で（intelligent）、自己設定ができ（self configuring）、容易に拡張可能な（extensible）機器又はＡＶシステムを提供できる首尾一貫し（coherent）、オープンな（open）、拡張可能なアーキテクチャ（architecture）は未だ存在しない。様々な解決方法の１つとして、例えばＩＥＥＥ１３９４シリアル通信バスをＡＶシステムの基礎（basis）として使用する方法があるが、機能及び性能が未知の新しい機器が加えられても、ＡＶシステムの寿命（life time）に亘ってその拡張性が得られるような解決法はない。これらのシステムでは、いずれも、ユーザが全ての機器に対して対話し、制御し、楽しむことができるといった保証がない。
【０００９】
【発明が解決しようとする課題】
したがって、従来のシステムの相互運用性（interoperability）及び機能性の問題を解決するホームオーディオビジュアルシステムの新たなアーキテクチャが必要である。また、ホームネットワークにおける機器のためのオープンで相互に動作する（inter-operating）オーディオビジュアルシステムの新たなアーキテクチャが必要である。また、何れの製造業者の機器でもホームオーディオビジュアルシステムとシームレス（seamless）に機能することができるようにするアーキテクチャが必要である。さらに、拡張性があり、市場の要求及び技術の変化に伴い、容易に変更及び発展することができるアーキテクチャが必要である。
【００１０】
【課題を解決するための手段】
本発明に係る機器拡張方法は、ホームオーディオ／ビデオネットワークに接続された第１及び第２の機器をアップグレード及び拡張する機器拡張方法において、上記第１の機器と上記第２の機器との間で所定の最低限の相互運用性を提供するように構成された該第１の機器用のデフォルト制御モジュールを、該第２の機器において準備するステップと、上記第１の機器用のデフォルト制御モジュールを用いて上記第２の機器からのデフォルトコマンドセットに応答することを含む、該第２の機器から該デフォルト制御モジュールを介して該第１の機器にアクセスするステップと、上記第１の機器において、更新制御モジュールを受信するステップと、上記第２の機器において、上記デフォルト制御モジュールのリンクを外すとともに、上記更新制御モジュールをリンクすることにより、該デフォルト制御モジュールを該更新制御モジュールで置換するステップと、上記第２の機器からの更新コマンドセットに上記第１の機器の更新制御モジュールを用いて応答することを含む、該第２の機器から該更新制御モジュールを介して該第１の機器にアクセスするステップとを有する。
【００１１】
また、本発明に係る機器拡張方法は、ネットワークにおける機器を拡張する機器拡張方法において、上記ネットワークに接続された機器用のデフォルト制御モジュールであり、該機器と該ネットワークに接続されている他の複数の機器との間で所定の最低限の相互運用性を提供するように構成された該デフォルト制御モジュールを該他の複数の機器の１つにおいて準備するステップと、デフォルトコマンドセットに上記接続された機器用のデフォルト制御モジュールを用いて、応答することを含む、上記他の複数の機器の１つから該デフォルト制御モジュールを介して該接続された機器にアクセスするステップと、上記接続された機器において、更新制御モジュールを受信するステップと、上記他の複数の機器の１つにおいて、上記デフォルト制御モジュールのリンクを外すとともに、上記更新制御モジュールをリンクすることにより、該デフォルト制御モジュールを該更新制御モジュールで置換するステップと、上記接続された機器の更新制御モジュールを用いて他の複数の機器の１つからの更新コマンドセットに応答することを含む、該他の複数の機器の１つから該更新制御モジュールを介して該機器にアクセスするステップとを有する。
【００１２】
本発明に係る機器拡張方法は、ホームオーディオ／ビデオネットワークに接続された第１及び第２の機器をアップグレード及び拡張する機器拡張方法において、上記第１の機器と上記第２の機器との間で汎用レベルの通信を提供するように構成された該第１の機器用のデフォルト制御ソフトウェアモジュールを該第２の機器において準備するステップと、上記第１の機器用のデフォルト制御ソフトウェアモジュールを用いて上記第２の機器からのデフォルトコマンドセットに応答することを含む、該第２の機器から該デフォルト制御ソフトウェアモジュールを介して該第１の機器にアクセスするステップと、上記第１の機器において、更新制御ソフトウェアモジュールを受信するステップと、上記第２の機器において、上記デフォルト制御ソフトウェアモジュールのリンクを外すとともに、上記更新制御ソフトウェアモジュールをリンクすることにより、該デフォルト制御ソフトウェアモジュールを該更新制御ソフトウェアモジュールで置換して、上記ホームオーディオ／ビデオネットワークの複数の機器から上記更新制御ソフトウェアモジュールによって受信されるコマンドによって、上記第１の機器を制御できるようにするステップと、上記第１の機器の更新ソフトウェア制御モジュールを用いて上記第２の機器からの更新コマンドセットに応答することを含む、該第２の機器から該更新制御ソフトウェアモジュールを介して該第１の機器にアクセスするステップとを有する。
【００１３】
本発明に係る機器拡張システムは、ホームオーディオ／ビデオネットワークに接続された第１及び第２の機器をアップグレード及び拡張する機器拡張システムにおいて、上記第１の機器と上記第２の機器との間で所定の最低限の相互運用性を提供し、該第２の機器からのデフォルトコマンドセットに応答することを含む、該第２の機器から該デフォルト制御モジュールを介して該第１の機器にアクセスするように構成された第１の機器用のデフォルト制御モジュールを備え、上記デフォルト制御モジュールは、上記第１の機器において更新制御モジュールを受信すると、該デフォルト制御モジュールのリンクを外すとともに、該更新制御モジュールをリンクすることにより、該更新制御モジュールに置換され、上記第１の機器は、上記第２の機器からの更新コマンドセットに応答することを含む、該第２の機器から上記更新制御モジュールを介してアクセスされることを特徴とする。
【００１４】
本発明は、ホームネットワークにおいて相互に動作する民生用電子（ＣＥ）機器のオープンアーキテクチャを定義するホームオーディオビジュアル（ＡＶ）システムを提供する。本発明の相互運用性の特徴は、何れの製造業者のＣＥ機器であっても、ユーザのホームＡＶシステムにおいて相互に動作し、シームレスに機能することができるようにするアーキテクチャモデルを定義する。本発明のシステムでは、新たな機能及び新たなＣＥ機器がホームＡＶネットワークに配置された際に、汎用デバイス制御（generic device control）の基本セット（base set）と、基本制御プロトコル（base control protocol）を拡張する方法とを組み合わせる。この際、本発明のアーキテクチャは、拡張可能であり、市場の要求及び技術の変化に伴い、容易に変更及び発展することができる。
【００１５】
上述の特徴を実現するために、本発明は、新たに接続された機器に対して問合せ（query）を行うことができるアーキテクチャを有する。問合せの結果を用いて、その機器のソフトウェアベースのアブストラクト（software based abstraction）が生成され、ネットワーク内の他の構成要素に対して利用可能とされる。ソフトウェアアブストラクトは、デバイス制御モジュールと称される。デバイス制御モジュールは、機器のための所定の標準化された相互運用性、機能性、制御インタフェースのセットを提供する。ＣＥ機器は、デバイス制御モジュールを介してホームＡＶネットワークに接続され、通信を行う。ホームＡＶシステムにおける各ＣＥ機器は、対応するデバイス制御モジュール（device control module：ＤＣＭ）を有している。また、本発明のＤＣＭは、他のアプリケーションが、新たに接続された何れのＣＥ機器に対してもアクセスや操作を行うことができるようにするアプリケーションプログラミングインタフェース（application programming interface：ＡＰＩ）を提供する。
【００１６】
ＡＶシステムの寿命に亘って、機能及び性能が他の機器にとって未知のあるいは部分的にしかわからない新たな機器が加えられても、本発明のＤＣＭを介して、基本的な最低レベルで全ての機器に対して通信を行うことができるとともに、制御することができることを保証するメカニズム（mechanism）が提供され、可能であれば、機器についての情報が得られるので、新たな機器のより優れたアブストラクトが生成される。
【００１７】
具体的には、一実施例において、本発明は、機器の制御及び操作のためのソフトウェアアブストラクト、すなわちＤＣＭが、機器の寿命に亘って、ユーザが操作しなくても、発展できるようにする非常に柔軟性がある（flexible）システムを提供する。ホームＡＶネットワークシステム及びそれに接続された機器の寿命に亘って、機器は、そのために利用可能とされる新たな情報を得ることができる。例えば、外部ソースによって、特定の機器のＤＣＭのためのソフトウェアが更新される。本発明のアーキテクチャでは、レベル１ＤＣＭをその寿命に亘って何時でも更新することができるようにすることによって、これらのイベントを利用することができる。レベル１ＤＣＭの更新は、レベル１ＤＣＭを専用化又はパラメータ化する情報によって汎用レベル１ＤＣＭが生成された直後に、行われる。あるいは、この情報を後で利用可能にしてもよい。この場合、システムは、ユーザが操作しなくても、あるいは最低限の操作でレベル１の汎用ＤＣＭを動的に更新することができる。
【００１８】
さらに、この間に、何らかの外部ソースから新たなレベル２ＤＣＭを機器に対して利用可能とすることもできる。このアーキテクチャでは、機器の寿命に亘って何れの時点でも、レベル１ＤＣＭをレベル２ＤＣＭに置き換えることができる。これを達成するために、このアーキテクチャは、ＤＣＭマネージャインタフェースコール（DCM manager interface call）によって、システムからＤＣＭのリンクを外し、新たなレベル２ＤＣＭを動的にリンクすることができる。この新たなＤＣＭは、レジストリ又はネームサービス（registry or name service）によってホームＡＶネットワークにその存在を登録するので、ネットワークにおける他の構成要素に対して利用可能となる。この際、本発明は、機器の制御及び操作のためのソフトウェアアブストラクト、すなわちＤＣＭが、ユーザが操作しなくても、機器の寿命に亘って発展できるようにする非常に柔軟性があるメカニズムを提供する。
【００１９】
【発明を実施するための最良の形態】
本発明の実施例について、図面を参照して詳細に説明する。本発明を好ましい実施例を用いて説明するが、本発明はこれらの実施例に限定されるものではない。むしろ、本発明は、特許の請求の範囲により定義される発明の範囲内である代替、変更及び等価なものを含むものとする。さらに、以下の本発明の詳細な説明では、本発明の完全に理解できるように多数の具体的詳細事項を記載する。しかしながら、本発明をこれらの具体的詳細事項を用いずに実施することができることは、当業者にとって明らかである。また、本発明の特徴を不必要に曖昧にしないために、周知の方法、手続、部品、回路については詳細な説明を省略する。
【００２０】
本発明は、ホームネットワークにおいて相互に動作するＣＥ機器のためのオープンアーキテクチャを定義するホームＡＶネットワークを提供する。本発明の相互運用性の特徴は、何れの製造業者のＣＥ機器であっても、ユーザのホームＡＶシステム内において相互に動作し、シームレスに機能することができるようにするアーキテクチャモデルを定義する。本発明のシステムでは、新たな機能及び新たなＣＥ機器がホームＡＶネットワーク内に配置された際に、汎用デバイス制御の基本セットと、基本制御プロトコルを拡張する方法とを組み合わせる。この際、本発明のアーキテクチャは、拡張可能であり、市場の要求及び技術の変化に伴い、容易に変更及び発展することができる。本発明及びその利点について以下に詳細に説明する。
【００２１】
記号及び術語
以下の詳細な説明のうちの幾つかの部分は、手続（procedure）、ステップ（step）、論理ブロック（logic block）、処理（processing）、その他のコンピュータメモリ内のデータビットの操作に対する記号的表現（symbolic representation）として表される（ＦＩＧ．２参照）。これらの説明及び記号は、データ処理技術分野の当業者が他の当業者に技術内容を最も効率的に伝達するのに用いる手法である。手続、コンピュータにより実行されるステップ、論理ブロック、処理等は、ここでも一般的にも、所望の結果を導く首尾一貫したステップ又はインストラクションのシーケンスであると考えられる。これらのステップは、物理量の物理的操作を必要とするステップである。通常、必ずしもそうではないが、これらの物理量は、コンピュータシステムにおいて記憶、転送、組合せ、比較、その他の操作を行うことができる電気又は磁気信号の形態を有する。場合によっては、主に一般的な用法上の理由で、これらの信号をビット（bit）、値（value）、要素（element）、記号（symbol）、文字（character）、用語（term）、数字（number）等として表すことが便利である。
【００２２】
なお、これらの用語及び類似の用語は、適切な物理量に関連つけられたものであり、単に、それらの物理量に対する便宜上のラベルに過ぎない。特に言及しない限り、さもなければ以下の説明から明らかなように、本発明では、例えば「処理（processing）」、「演算（computing）」、「変換（translating）」、「具現化（instantiating）」、「判定（determining）」、「表示（display）」、「認識（recognizing）」等の用語を用いた説明は、コンピュータシステム又は同様の電子計算装置の動作及び処理を言及するものであり、このようなコンピュータシステムは、そのコンピュータシステムのレジスタ又はメモリ内に物理（電子）量として表されるデータを操作して、同様にコンピュータシステムのレジスタ又はメモリ、あるいは他の情報記憶装置、伝送装置又は表示装置内に物理量として表される他のデータに変換する。
【００２３】
アーキテクチャの概要
本発明のアーキテクチャは、ホームＡＶネットワークにおける新たな機器のシームレスなサポート及び機器の問題のない相互運用性が得られるホームＡＶシステムを構築することができるようにするものである。本発明に係るシステムの最も基本的な構成要素は、ホームＡＶ相互運用アーキテクチャと、一連のホームＡＶ相互運用インタフェースと、ホームＡＶネットワークとである。ホームＡＶ相互運用アーキテクチャは、物理的ネットワークを含み、プログラミングインタフェースを制御するという広く、全体を包含する用語である。相互運用インタフェースは、ＨＡＶＩアーキテクチャの構成要素間のインタラクション（interaction）及びインタフェースを記述するのに使用される用語である。相互運用インタフェースは、コモンコマンドセット（common command set）を提供するのに加えて、新たな機器をネットワークに統合することができるようにするソフトウェアアーキテクチャを提供するとともに、そのサービスをシームレスに提供する。ホームＡＶネットワークは、物理的ネットワークとそのトポロジー（topology）を記述するのに用いられる用語である。
【００２４】
なお、本発明のホームＡＶ相互運用（ＨＡＶＩ）アーキテクチャは、民生用電子機器の製造業者及び生産者が相互動作可能な機器を提供できるようにするオープンで、プラットホームに依存しない、アーキテクチャ的に中立なネットワークである。これは、異なるハードウェア／ソフトウェアプラットホーム上で実現することができ、いずれかのプラットホームに特有である特徴を全く有していない。ＨＡＶＩアーキテクチャの相互運用インタフェースは、拡張可能であり、市場の要求及び技術の変化に伴い、容易に変更及び発展することができる。これらは、アイソクロナス及び時間依存の（isochronous and time-sensitive）データ（例えばオーディオ及びビデオコンテンツ）のルーティング及び処理を制御する基礎構造（infrastructure）を提供する。
【００２５】
具体的には、ＨＡＶＩアーキテクチャは、機器（appliance）の視覚的表示（visual representation）及び制御をサポートする実行環境（execution environment）と、アプリケーション及びシステムのサービスと、プラグアンドプレイ（plug and play）又は他の方法によって環境を動的に拡大する通信メカニズム（communication mechanism）を提供する。
【００２６】
なお、ＨＡＶＩアーキテクチャは、従来の機器（例えば既存の及びユーザが利用できる機器）をサポートする。より高機能（intelligent）なネットワーク機器への移行は遅くなりつつあるので、これは重要なことである。殆どの製造業者は、突然「高機能な」機器のみを生産するわけではなく、また、大部分の消費者も、既存の機器の全てを直ちに交換し始めるわけでもない。
【００２７】
本発明では、従来の機器には２つのクラスある。第１のクラスは、「一方向（one-way）」、すなわち未応答制御機器（unacknowledged control appliance）からなる。第２のクラスは、制御可能な「両方向（two-way）」機器からなる。一方向機器の具体例としては、手に持てるサイズのリモートコントローラの赤外線コマンドにより制御されるオーディオ／ビデオコンポーネントがある。両方向機器は、コマンドの実行確認、状態及びエラー報告を行う。両方向機器の具体例としては、既知のＩＥＥＥ１３９４により可能とされ、最近導入されたデジタルカメラがある。
【００２８】
なお、本発明のホームＡＶネットワーク（以下、ＨＡＶＩネットワークともいう。）は、ライトワンス型で何れの機器でも動作する共通言語（common language）によって、将来的な機器及びプロトコルに対応するためのサポートを行う。本発明では、各機器は、ユーザインタフェース、及び外部コントローラにより使用することができるデバイス制御に関する自己記述情報（self-describing information）を内部に備えている。この情報は共通言語のプログラムとして記述される。
【００２９】
以下に説明するが、このようなネットワークの根底にある構造（underlying structure）は、機器が相互に接続されたクラスタ（cluster）のセットからなる。典型的には、家庭には幾つかのクラスタがあり、各階又は各部屋毎に１つクラスタがある。各クラスタは、サービスのセットをユーザに提供する相互に接続された機器のセットとして動作する。ある１つの機器が、多くの場合、他の機器のセットのコントローラとして動作する。しかしながら、このアーキテクチャは、十分に柔軟性があり、家庭にマスタコントローラを持たない単一クラスタがあるようにすることもできる。
【００３０】
例えば、本発明の一実施例では、ユーザの家庭の居間における高機能テレビジョン受像機が、相互に接続された多数の機器のコントローラとして機能する。制御される各機器は、自己記述データ（self describing data）を有し、幾つかの関連する制御コードを有することもある。これらの機器が最初に接続されると、コントローラは、その機器のユーザインタフェース及び制御プログラムを獲得する。そして、機器を表すアイコンがテレビジョン受像機の画面に表示され、アイコンを操作することにより、制御プログラムの要素が表示された１つ又は複数の機器を規定された方法で起動する。このモデルの例外は、自己記述データも制御コードも有さない従来の機器である。自己記述データに関する説明及び関連した技術については、１９９７年７月３１日出願、発明者ラッドキー等（Ludtke, et al.,）、出願番号６０／０５４，３２７の「機器内に自己記述情報を含む方法及び機器（A METHOD AND APPARATUS FOR INCLUDING SELF-DESCRIBING INFORMATION WITHIN DEVICES）」に記載されており、これを引用することによって、本願に援用する。
【００３１】
なお、本発明のＨＡＶＩネットワークは、民生用機器を容易にインストールできる「プラグアンドプレイ」をサポートし、物理的にケーブルを接続する以外、ユーザの操作を何も必要とせず、消費者に機器の大部分の機能を提供する。これは、機器の大部分の機能を使えるように設定（configuration）することが必要な既存の機器とは異なる点である。本発明の目的は、「活線（hot）」プラグアンドプレイ（ユーザが機器の電源を切る必要がない）を提供することであり、この接続方法により、機器が問題なく且つ確実にサポートされる。
【００３２】
本発明では、機器は、それ自身を設定し、ユーザが操作しなくても、システム全体に亘る「ルックアンドフィール（look and fill）」のユーザインタフェースに統合する。下位レベルの通信サービスは、新たな機器がＡＶネットワークにおいて識別されると、通知を行う。ユーザが自分の好みに合うように設定を変更できることが多いが、この機器では、基本機能を提供するためにユーザが変更を行う必要はない。
【００３３】
また、本発明のＨＡＶＩネットワークは、柔軟性があり、ユーザの要求と製造業者のブランド差別化の要求の両方に適合する多数のユーザインタフェースをサポートする。ＨＡＶＩネットワークでは、プロトコルは、非常にリソースが豊富な高機能ＰＣ等の機器から「少額の（dump）」、すなわちリソースに乏しい機器（例えばコーヒーメーカやサーモスタット）までを幅広く基準化する。これを達成するために、ＨＡＶＩアーキテクチャは、低価格帯（low-end）の機器がより高機能な機器のリソースを明確に定義された方法（well-defined way）で使用することを可能にする。同様に、ＨＡＶＩアーキテクチャは、アブストラクト機器が幾つかの下位レベルの機器の論理集合から形成されるような集合機器の規定（specification of aggregate appliances）を可能にする。
【００３４】
さらに、本発明のＨＡＶＩネットワークは、既存の規格（existing standard）をサポートする。ＨＡＶＩネットワークは、ＣＥＢｕｓ、ホームプラグアンドプレイ（Home Plug and Play）、ＥＨＳＩ、ＶＥＳＡ、ホームネットワーク（Home Network）、ＤＡＶＩＣ、ＣｏＭＭｅＮＤ、Ｌｏｎｗｏｒｋｓ、ＵＳＢ、ＩＥＥＥ１３９４等の幾つかの既存のよく知られた工業規格や技術に対して相補的である。したがって、本発明の目的の一つは、既存の機器が当てはまる基礎構造を提供することである。
【００３５】
ＨＡＶＩアーキテクチャのシステムモデル
ＦＩＧ．１Ａを参照して、本発明を適用したＨＡＶＩネットワーク１０ａを説明する。上述のように、ＨＡＶＩアーキテクチャは、共通のメッセージングシステム（common messaging system）を介して通信を行う、例えば、セットトップボックス（set top box）３０１等の高機能レシーバ／デコーダ（ＩＲＤ）、デジタルビデオテープレコーダ（ＤＶＴＲ）、ビデオテープレコーダ（ＶＴＲ）、パーソナルコンピュータ（ＰＣ）、デジタルビデオディスクプレーヤ（ＤＶＤ）等を含む広範囲の機器をサポートする。ＦＩＧ．１Ａは、ＨＡＶＩネットワーク１０ａの物理的なポート同士の接続構成を示す図である。ＣＥ機器（「機器」）１２〜２４は、バスセグメント（bus segment）３０ａ〜３０ｆにより互いに接続されているように図示してある。ＨＡＶＩネットワーク１０ａの具体例では、共通のメッセージングシステムを提供するプラットホームとして、ＩＥＥＥ１３９４シリアル通信バス規格を使用している。
【００３６】
ＦＩＧ．１Ｂは、ＦＩＧ．１ＡのＨＡＶＩネットワークの論理バス構成１０ｂを示す図である。ＦＩＧ．１Ｂに示すように、ＨＡＶＩネットワークの機器１２〜２４の全ては、共通のＩＥＥＥ１３９４シリアル通信バス３２に論理的に接続されているとして示される。この論理バス構成１０ｂにおいては、ピアツーピア（peer to peer）の機器の通信がサポートされる。例えば、ＦＩＧ．１Ｃに示すように、いずれかの（適切な性能を有する）機器、例えば機器１２は、ＨＡＶＩネットワーク１０ａ内の他の何れの機器に対しても通信パケットの送受信することができる。ＦＩＧ．１Ｂの具体例では、セットトップボックス３０１（以下、「機器１２」ともいう。）（例えばＩＲＤ）は、ＨＡＶＩネットワーク１０ａの他の機器１４〜２４のいずれからもメッセージを受信することができ、また、いずれに対してもメッセージを送信することができる。
【００３７】
ＦＩＧ．１Ａ及びＦＩＧ．１Ｂにおいて、上述のように、ＨＡＶＩにおける相互運用モデル（interoperability model）により、１）既存の機器に対するサポート、２）デフォルト制御モデル、３）新たな機器又は機能が市場に現れたときにデフォルト制御モデルを拡張する手段、４）機器を表示するための共通手段（例えばグラフィックユーザインタフェース）が得られる。これを達成するために、ＨＡＶＩアーキテクチャは、３つの種類のノード、すなわちフルＡＶノード（full AV node：ＦＡＶ）、中間ＡＶノード（intermediate AV node：ＩＡＶ）、ベースＡＶノード（base AV node：ＢＡＶ）という、ホームネットワークにおけるノードを定義する。
【００３８】
フルＡＶノードは、ＡＶソフトウェアモデル（以下に説明する）の完全なインスタンス（complete instance）を含む機器である。この種類のノードは、一般的に豊富なリソースセットを有し、構成の複雑なソフトウェア環境をサポートすることができる。ＦＡＶの主な特徴は、複雑ではない機器に対する制御機能を有し、通常その複雑ではない機器からの制御モジュールをロードして、局部的に実行することにより制御を行う。このようなノードの具体例としては、セットトップボックス（例えばセットトップボックス３０１）、スマートＴＶ（smart TV）、家庭用汎用制御機器（general purpose home control device）、又は家庭用ＰＣがある。
【００３９】
中間ＡＶノードは、一般的に、リソースが限定された低コストの機器である。中間ＡＶノードは、制御モジュールの実行環境を備えていないので、ホームネットワークにおけるマスタコントローラとして動作することはできない。中間ＡＶノードは、リソースが限定されているので、欠如している機能を備える他のＩＡＶ機器とともに動作して、あるいはそれらを制御する制御モジュールをサポートするＦＡＶノードを用いて、離れたリソースにアクセスすることができる。この第２の動作モードでは、中間ＡＶノードは、表示装置、汎用コンピュータリソース、全体的な制御の枠組として機能するフルＡＶノードに依存することになる。これにより、フルＡＶ機器は、種々の中間ＡＶ機器をまとめて、ユーザにサービスやアブストラクトを提供することができる。
【００４０】
ベースノードは、ＦＡＶノードでもＩＡＶノードでもないノードである。ベースノードには、２つの汎用タイプ、すなわち従来のベースノード（legacy base node）と他のベースノード（other base node）がある。従来のベースノードは、ＨＡＶＩアーキテクチャの出現前に製造された機器である。これらの機器は、その制御のために独自のプロトコル（proprietary protocol）を使用することが多く、単純で明確な制御のみのプロトコルを有することが多い。このような機器は、ＨＡＶＩネットワーク１０ａ内で動作することができるが、フルＡＶノードがゲートウェイ（gateway）として動作することが必要である。フル又は中間ＡＶノードと従来の機器との通信は、ＨＡＶＩアーキテクチャで用いられるホームＡＶコマンドと従来のコマンドプロトコルとが互いに変換されなければならない。他のベースノードは、ビジネスやリソースの理由で、アップロード可能な制御ソフトウェアを用いて後のプルーフ動作（proof behavior）を実行することを選択し、ＨＡＶＩアーキテクチャ又はメッセージ通信システムのいずれも備えていない機器である。これらの機器は、ＦＡＶノードとＢＡＶノード間のプライベートコマンドプロトコル（private command protocol）を有するＦＡＶノードによって、制御される。
【００４１】
従来のノードの例外として、各ノードは、システム内の他のノードと通信することができる最小限の十分な機能を有している。インタラクションの過程で、各ノードは、制御及びデータ情報を交換し、機器の相互運用をピアツーピアで可能にする。これにより、通信レベルにおいて、何れの機器もシステムのマスタ又はコントローラとして動作する必要がなくなる。しかし、これにより、論理マスタ又はコントローラは、基本的なピアツーピアの通信モデルに対して制御構造（control structure）を課すことができる。ＨＡＶＩネットワーク１０ａにおけるサービスは、互いに通信を行ってユーザ又はアプリケーションにサービスを配信する１つ以上のノードによって提供される。ノードがユーザとインタラクトする必要がある場合、そのノードは他のノードと交渉して表示装置にアクセスし、使用する。
【００４２】
また、論理ノードと物理ノードは区別されている。この区別の良い例が通常のテレビジョン受像機に見られる。テレビジョン受像機は、一般的に１つの物理的なボックスであるが、チューナ、オーディオ出力等の幾つかの機能コンポーネントを有している。システムの観点からは、物理ノードは、システム内のアドレス可能なピアノードである。テレビジョン受像機の個々の機能コンポーネントがそれぞれアドレス可能であるようにテレビジョン受像機が構成されている場合、それは論理的には１つのノードであるが、物理的には幾つかのノードである。これに対して、テレビジョン受像機が１つのアドレス可能なエンティティ（entity）を有するように構成されている場合、それは単一の論理ノードであるとともに単一の物理ノードである。
【００４３】
汎用メッセージ通知システムを用いてホームネットワーク内でメッセージを送ることにより、ＩＡＶ機器とＦＡＶ機器は通信を行う。新たな機器がホームネットワークに加わると、それらは認識され、グローバルネームデータベース（レジストリ）に追加される。レジストリは、それらの特徴についての情報を保持し、その機器のためのハンドラ（handler）に基準（reference）を供給する。他の機器及びサービスは、ある機器の位置を検出（locate）するためにレジストリに対して問合せをすることができ、その後、ハンドラを用いて、その機器とインタラクトすることができる。本発明の通信及び識別プロセスに関する説明や関連技術については、１９９８年１月６日出願の米国特許出願、オギノ等（Ogino, et al.,）の「ホームオーディオ／ビデオネットワークにおける機器識別メカニズムを提供する方法及びシステム（METHOD AND SYSTEM FOR PROVIDING A DEVICE IDENTIFICATION MECHANISM WITHIN A CONSUMER AUDIO/VIDEO NETWORK）」に記載されており、本明細書ではこれを参照する。
【００４４】
ホームネットワークにある機器が初めて加えられると、システムは、その機器の特徴及び機能を確認するために問合せを行う。機器の特徴がわかると、このアーキテクチャは、それを制御するための２つの方法を提供する。第１の方法であるレベル１相互運用性は、所定のメッセージセットを使用する。全てのＩＡＶ及びＦＡＶノードがこのコマンドセットを用いて他の機器にアクセスし、制御することができる（ＢＡＶノードは、このアーキテクチャが定義される前に設けられているので、従来のプロトコルを用いて制御される）。これはデフォルトレベルの制御を行う。ＦＡＶノードは、制御ノードとして動作し、機器に制御コマンドを送るのに使用されるＡＰＩを提供するデバイス制御モジュール（ＤＣＭ）として知られるＩＡＶノードの局所表現を生成する。
【００４５】
ＨＡＶＩ内のレベル２相互運用性は、さらに進んでおり、将来追加される機能や新たな機器をサポートする。これを達成するために、ある特定の機器は、ＩＡＶ機器からＦＡＶ機器にアップロードされるオーバライドＤＣＭ（override DCM）をそのＲＯＭ内に記憶し、このオーバライドＤＣＭによって、特定の機器用のデフォルトＤＣＭは置換される。このオーバライドＤＣＭは、特定の機器の基本的なレベル１コマンドセットを含むだけでなく、機器の改良された特徴を制御するためのベンダ固有コマンド（vender specific command）も含んでいる。このモデルにより、ＩＡＶ機器は、その特別の機能を他の機器に知らせることができる。オーバライドＤＣＭは、どのベンダのＦＡＶにもロードすることができるので、ＤＣＭのフォーマットは、アーキテクチャに対して中立的である。
【００４６】
ある機器が他の機器の機能を知り、その機器に対してどのコマンドセットを使用したらよいかを判定することができるようにするために、自己記述データ（self describing data：ＳＤＤ）と呼ばれる標準機器記述構造（standard device description structure）が設けられている。ＳＤＤデータ構造は拡張することができる。ＳＤＤデータ構造は、例えばテレビジョン受像機やＶＴＲ等の機器の種類を記述する少数のバイトである。また、ＳＤＤデータ構造は、オーバライドＤＣＭ及び機器のグラフィック表現を定義するより複雑な構造であってもよい。ＳＤＤデータ構造におけるグラフィック表現により、ＦＡＶノードは、ユーザに対してホームネットワーク内の各機器を画像表示することができる。グラフィック表現を汎用的な方法で定義することにより、機器のＳＤＤグラフィックデータは、その機器のためのユーザインタフェースを表示するどのベンダの製品においても、使用することができる。これにより、高いレベルのベンダ相互運用性が得られるとともに、ベンダは、製品を、表示装置の一般的なルックアンドフィール内に保持しながら、区別することができる。これにより、制御機器（ＦＡＶノード）は、種類やベンダの違いに関係なく、ホームネットワーク内の全ての機器のための一般的な制御ユーザインタフェースを提供することができる。
【００４７】
上述のように、従来の機器は、ＨＡＶＩアーキテクチャの前に製造された機器、あるいはＨＡＶＩを使用しない機器である。ＨＡＶＩは、従来の機器のためのプロトコル変換を行う従来のＤＣＭを設けることにより、従来の機器をサポートする。これらの従来のＤＣＭは、既存の一方向又は両方向制御プロトコルをサポートするのに十分な知識を有し、ＨＡＶＩに適合した機器に対する特定の制御インタフェースを提供することができる。従来のＤＣＭは、従来の機器とＨＡＶＩ機器とのブリッジ（bridge）として動作する。この手法により、ＨＡＶＩは、例えば家庭のエネルギ管理や安全管理に使用されるプロトコル等のいかなる将来的なデバイス制御プロトコルに対してもインタラクトすることができる。
【００４８】
なお、ＨＡＶＩアーキテクチャにより使用される通信ハードウェア及びプロトコルは、固有のものではない。ＨＡＶＩアーキテクチャは、幾つかの通信媒体のうちのいずれかに組み込んで使用することに適しており、その唯一の条件は、その媒体がＨＡＶＩインタフェースをサポートする汎用通信メカニズムを備えていることである。想定される基本モデルは、論理通信バックプレーン（例えばＩＥＥＥ１３９４）のモデルである。全てのＡＶ機器は、このバックプレーンに接続されることが想定されており、ＦＩＧ．１Ｂに示すように、他の全てのＡＶ機器の位置を検出して、通信を行うことができる。物理的設定においては、この論理バックプレーンは２つ以上の物理的通信媒体からなると考えられる。さらに、異なる物理的媒体上において、多数のプロトコルが使用されることが想定される。ホームＨＡＶＩアーキテクチャは、この全てを抽象化し、通信ノードの汎用モデルを提供する。これは、ネットワークの透過性（transparency）を確実にする（機能的にはソケット等の）トランスポートレイヤ（transport layer）より上のメカニズムを提供する。このメカニズムは、全てのフラグメンテーション（fragmentation and re-assembly）及び再アセンブリを行う「信頼性のある、順序づけられたデータグラムサービス（reliable, ordered datagram service）」として記述することができる。
【００４９】
したがって、本発明の目的は、各物理的バスを同様にサポートして、アプリケーションがどの物理的トランスポートを使用するかを考える必要がないようにすることである。しかし、電子業界において、ＩＥＥＥ１３９４はよく知られているので、ＩＥＥＥ１３９４を用いた機能の観点から、本発明の特徴を説明する。ＣＥＢｕｓやＵＳＢ等の他のバスは、全く同じ特徴を必要とするものではない。
【００５０】
ＦＩＧ．２を参照して、本発明を適用したピアツーピアの２つのＩＡＶノードからなるＨＡＶＩネットワーク２００を説明する。ＨＡＶＩネットワーク２００は、第２のＩＡＶ２０２（例えば受信機）に接続された第１のＩＡＶ２０１（例えばテレビジョン受像機）を備えている。第１のＩＡＶ２０１と第２のＩＡＶ２０２は、ピアツーピアで動作し、互いに必要なリソースを調停する。これらは、ＢＡＶ又はＬＡＶ機器の追加をサポートするリソースを有していないが、そのコンテキスト内で意味のある動作を行うことができる。標準ＵＩ性能を得るためにはＩＡＶは必要ではない。ＨＡＶＩアーキテクチャには、「上位相互運用性（forward compatibility）」又は新たな機能を検出のための規定はない（例えば、第１のＩＡＶ２０１は、第２のＩＡＶ２０２が接続されたときに提供されたＳＤＤに基づいて第２のＩＡＶ２０２がサポートする機能しか知らない。）。しかし、本発明では、「特別な（ad-hoc）」特徴を検出するのに、ＳＤＤの特徴を容易に利用することができる。
【００５１】
ＦＩＧ．３は、本発明を適用した１つのＦＡＶクラスタからなるＨＡＶＩネットワーク３００を示す図である。ＨＡＶＩネットワーク３００は、第１のＬＡＶ３０２（例えばテレビジョン受像機）、第２のＬＡＶ３０３（例えばＶＴＲ）、ＢＡＶ３０４（例えばデジタルカメラ）にそれぞれ接続されたＦＡＶ３０１（例えばセットトップボックス）を備えている。ＨＡＶＩネットワーク３００では、ＦＡＶ３０１が、従来及びベースＡＶ機器（例えば機器３０２〜３０４）を制御し、クラスタに亘るサービスを提供する。
【００５２】
ＦＩＧ．４は、ＩＡＶピアツーピアからなるＨＡＶＩネットワーク４００に統合されたＦＡＶクラスタを示す図である。本発明では、ＨＡＶＩネットワーク４００の構成により、従来の機器３０２，３０３のためのサポートが得られるとともに、２つのＩＡＶ４０１，４０２のリソースがＦＡＶ３０１によって使用されていないときに、それらのＩＡＶ４０１，４０２内でリソースを独立して制御することができる。ＩＡＶ４０１，４０２は、ＦＡＶ３０１に対してピアとして動作する。効率上、ＦＡＶ機器からＦＡＶ機器へのリソース要求とＦＡＶ機器からＩＡＶ機器へのリソース要求のいずれについても、リソースコンフリクトポリシー（resource conflict policy）を実行することができる。ＩＡＶ４０１，４０２は、ＦＡＶ３０１内で動作するＤＣＭを介してＦＡＶ３０１により制御される。
【００５３】
ＦＩＧ．５は、多数のＦＡＶを有する具体的なＨＡＶＩネットワーク５００を示す図である。ＨＡＶＩネットワーク５００は、さらにＦＡＶ５０１（例えば衛星受信機）を備えている。この構成では、上述のＨＡＶＩネットワーク４００と同様に動作する。この構成では、ＦＡＶ３０１，５０１がピアとして動作する。
【００５４】
コンピュータシステムプラットホーム
ＦＩＧ．６を参照して、本発明を適用したセットトップボックス３０１を説明する。上述のように、何れの民生用電子機器もＦＡＶになりうるので、ＨＡＶＩソフトウェアのためのコンピュータシステムプラットホームが得られる。例えば、この具体例のＨＡＶＩネットワークのセットトップボックス３０１の機器は、以下に説明するＨＡＶＩアーキテクチャのソフトウェアコンポーネントのためのオペレーションプラットホームを提供する特殊なコンポーネントを有している。具体的には、本発明の特徴について、コンピュータシステムで実行されるステップを用いて以下に説明する（例えばＦＩＧ．１３〜１７Ａに示すプロセス）。本発明では種々のコンピュータシステムを使用することができるが、ＦＩＧ．６のセットトップボックス３０１には、例示的な汎用コンピュータシステムを示す。
【００５５】
ＦＩＧ．６のセットトップボックス３０１は、ビデオ／オーディオレシーバ（デコーダ）ユニット６０６と、ＭＰＥＧユニット６０７を備えるとともに、情報を通信するアドレス／データバス６００と、バスに接続され、情報及びインストラクションを処理する１つ以上の中央プロセッサ６０１と、バス６００に接続され、中央プロセッサ６０１の情報及びインストラクションを記憶する揮発性メモリ６０２（例えばランダムアクセスメモリ：ＲＡＭ）と、バス６００に接続され、中央プロセッサ６０１の静的情報及びインストラクションを記憶する不揮発性メモリ６０３（例えばリードオンリーメモリ：ＲＯＭ）とを備えている。また、セットトップボックス３０１は、バス６００に接続され、情報及びインストラクションを記憶するための磁気又は光ディスク及びディスクドライブ等のデータストレージ装置６０４（「ディスクサブシステム」）を追加的に備えることもできる。また、セットトップボックス３０１は、ローカルバス３０（例えばＩＥＥＥ１３９４シリアル通信バス）とインタフェースするバスインタフェースユニット６０８も備える。セットトップボックス３０１は、種々のオペレーティングシステム（例えばウィンドウズオペレーティングシステム、ＤＯＳオペレーティングシステム、マッキントッシュＯ／Ｓ）の下に動作することができるが、この実施例では、アペリオスオペレーティングシステムを使用する。
【００５６】
ＨＡＶＩソフトウェアモデル
本発明では、ＨＡＶＩアーキテクチャの演算ユニット（例えばＤＣＭ）は、オブジェクトとしてモデル化されている。各オブジェクトは、自己包含エンティティ（self contained entity）であり、明確に定義されたインタフェースを介してアクセス可能であり、明確に定義されたソフトウェア実行環境内で実行するものである。ソフトウェア実行環境（例えばＦＩＧ．６のセットトップボックス３０１）も、オブジェクトとしてモデル化され、明確に定義されたインタフェースを介して通信基礎構造を用いてアクセスすることができる明確に定義されたサービス（ローカル又はリモート）のセットを提供する。
【００５７】
各オブジェクトは独自にネーミングされる。システムサービスを構築するのに用いられるオブジェクトと、アプリケーションサービスのために用いられるオブジェクトの区別は行わない。オブジェクトは全て、レジストリを介して知られるようにする。システム内のオブジェクトは、特定のサービス又は機器を見つけるためにレジストリに問い合わせることができ、その問合せの結果を用いて、そのサービス又は機器にメッセージを送ることができる。オブジェクトに割り当てられた識別子はオブジェクトを登録するときに生成される。この識別子は、必要に応じてならば、オブジェクトの寿命に亘って持続することが保証され、ホームネットワークが完全にリブートした場合でも持続される。
【００５８】
本発明では、オブジェクトはメッセージ通知モデルを用いて通信を行う。他のオブジェクトのサービスを利用したいオブジェクトは、目的のオブジェクトにサービス要求を送る汎用メッセージ通知メカニズムを用いる。目的のオブジェクトは上述の独自のオブジェクト識別子を用いて特定される。この具体例ではメッセージ通知メカニズムがＩＥＥＥ１３９４を用いて機能するが、１３９４バスによりメッセージを送るか制御Ａ１リンクによりメッセージを送るかは区別しない。同様に、同一ノードにおけるオブジェクトとリモートノードにおけるオブジェクトの区別は行わない。実際のメッセージ通知基礎構造はシステムやネットワーク環境によって異なり、ノード毎にもベンダ間でも異なる。しかしながら、メッセージの実際のフォーマットは相互運用性が確保されるように共通でなければならない。
【００５９】
なお、オブジェクトモデル及びメッセージングシステムの一般的な目的は、種々のソフトウェアシステム及び言語による多数の実行方法を可能にする十分柔軟性があり、完全な汎用ソフトウェアモデルを提供することである。メッセージとこれらを取り扱うコードを結びつける際の詳細は、システムインプリメンタにより決定される。
【００６０】
ソフトウェアアーキテクチャの概要
ＨＡＶＩソフトウェアアーキテクチャは、ソフトウェアモデルがＨＡＶＩアーキテクチャをサポートするのに使用される方法を定義する。特に、これは、ＨＡＶＩアーキテクチャ内で機器を抽象化して、管理する方法を定義する。また、これは、相互運用性が確保される方法を定義するとともに、将来的な機器やサービスをこのアーキテクチャに統合することができる方法を定義する。
【００６１】
ソフトウェアマネージャとしてのフルＡＶノード：本発明では、フルＡＶノード（ＦＡＶ）は中間ノード（ＩＡＶ）やベースノード（ＢＡＶ）のマネージャとして動作し、ＨＡＶＩアーキテクチャをサポートするサービスのためのプラットホームを与える。これを達成するために、ＦＡＶノードは、オブジェクトがサービスや機器に対する制御及び通信を行うことを可能にする実行環境を与える。機器がホームＡＶネットワーク内でアクセス可能であることを確保するために、ＦＡＶノードは、ある機器が他の機器に提供するサービスのソフトウェアアブストラクトをサポートする。上述のように、このアブストラクトはデバイス制御モジュール（ＤＣＭ）と呼ばれる。ＤＣＭはソフトウェアアーキテクチャにおけるオブジェクトとしてモデル化されるが、以下では、区別するために単にＤＣＭと呼ぶことにする。ＤＣＭがシステムの他の部分に対して設けるインタフェースにより、その機器へのアクセス及び制御を行う手段が得られる。一般的な場合、ＦＡＶノードは、それが管理するホームネットワーク又はＩＡＶネットワークの一部における各ＩＡＶノード及びベースノード毎に１つのＤＣＭという形で、ＤＣＭのセットを管理する。したがって、相互運用性の観点から、ＦＡＶノードの主たる役割は本発明のＤＣＭを管理し、ＤＣＭのための実行環境として動作することである。
【００６２】
コントローラ及び表示装置としてのフルＡＶノード：本発明では、多くの場合、ＦＡＶはＡＶコンテンツやユーザインタフェース（ＵＩ）マテリアルを表示するために使用する関連した表示装置を有する。しかし、ＨＡＶＩソフトウェアアーキテクチャはこれに対して命令しないので、ＦＡＶノードは管理されていないことになる。この場合、ＦＡＶノードはコンテンツやＵＩ情報を表示するために他のノードと共同して動作する（以下に説明する）。しかし、ＦＡＶ機器は、ホームネットワーク全体のルックアンドフィールを与える高レベルのＵＩＡＰＩをサポートしなければならない。下位レベルのグラフィック操作ＡＰＩは、一般的にグラフィック表示装置自体に近接して配置され、ＦＡＶの高レベルＡＰＩにより操作される。
【００６３】
フルＡＶノード間のピアツーピアアーキテクチャ：本発明に係るホームＡＶネットワークでは、２つ以上のＦＡＶが存在してもよい。この場合、各ＦＡＶは他のＦＡＶと共同して、サービスがユーザに提供されることを保証する。これによりＦＡＶノードは共同してリソースを共用することができる。例えば、表示装置に直接アクセスできないＦＡＶノードが、離れたＦＡＶノードを用いて、ＤＣＭユーザインタフェースを表示してもよい。また、あるＦＡＶノードが、離れたノードに存在するデータ変換モジュールのサービスに対して、２つのＡＶ機器間のデータルートの設定を可能にするように要求してもよい。
【００６４】
レベル１及びレベル２の相互運用性
本発明では、本発明のＨＡＶＩアーキテクチャの主たる目的の一つは、機器間の相互運用性をサポートすることである。これには既存の機器も将来的な機器も含まれる。相互運用性を達成するために、本発明のＨＡＶＩアーキテクチャは２つのレベルの相互運用性を可能にする一般（general）モデルをサポートする。これらのレベルをレベル１、レベル２と呼ぶ。
【００６５】
レベル１相互運用性：本発明のレベル１相互運用性は、既存の機器の通信を可能にする一般的な要求についてである。これを達成するために、本発明のレベル１相互運用性は、１つの機器が他の機器に通信を行うことを可能にする制御メッセージ（コマンド）の汎用セットと、その機器から正当に予測するイベントメッセージのセットを定義し、使用する。このアプローチをサポートするには、基本的なプロセスセットが必要である。これらのプロセスには、機器の検出、通信、汎用メッセージのセットが含まれる。
【００６６】
本発明の機器の検出プロセスは、ホームＡＶネットワークにおける各機器が、その特徴を他の機器に宣伝することを可能にする明確に定義された方法を必要とすることに対するものである。ここで採用してきたアプローチは、その機器について情報を有するとともに他の機器によりアクセスでき、全てのＦＡＶ及びＩＡＶ機器に必要なデータ構造を特定することである。このデータ構造を自己記述データ構造（ＳＤＤ）と呼ぶ。ＳＤＤは、少なくとも、他の機器がその機器の基本性能を検出することを可能にするのに十分な情報を有するので、その機器に送ることができる基本的なコマンドメッセージのセットや、その機器から正当に受け取ることを期待するイベントを示すものである。
【００６７】
本発明の通信プロセスによれば、ある機器が他の機器の機能を判定すると、これらの機能にアクセスすることを可能にする必要がある。これを達成するには、ある機器がコマンド要求を含むメッセージを他の機器に送ることを可能にする一般的な通信手段が必要である。本発明の一般的なメッセージサービスプロセスについては既に説明した。
【００６８】
汎用メッセージセットは、レベル１相互運用性をサポートするのに必要なプロセスに関する。これには、特定クラスの全ての機器によりサポートされなければならない明確に定義されたメッセージセットが含まれている。これにより、全ての機器が汎用コマンドの共通セットに合致しているので、製造業者に関わりなく、１つの機器が他の機器とともに動作することができる。上述のように、本発明のＨＡＶＩソフトウェアアーキテクチャでは、これらのコマンドがシステムの他の部分に対するＤＣＭとして設けられている。
【００６９】
本発明のこれら３つの基本プロセスは、少なくとも最低レベルの相互運用性をサポートする。多くの場合、何れの機器もＳＤＤを介して他の機器の機能を問合せすることができるので、何れの機器も他の機器によりサポートされるコマンドセットを判定することができる。各機器は汎用メッセージングシステムへのアクセスがあるので、何れの機器も他の機器とインタラクトすることができる。
【００７０】
しかし、本発明に係るレベル１相互運用性では、各機器が最低レベル又は低下したレベルの機能で相互に動作することができるのみである。各機器クラス毎の汎用メッセージセットは、最小限で共通のコマンドセットである。ＳＤＤ手段では、ある機器のＵＩやそのインタラクションモデルの幾つかの特徴についての情報を提供することにより、その機器のある程度のカスタマイゼーションを行う手段が得られる。他のＩＡＶ機器は、その機器に対するインタフェースを示す、この情報を利用することができる。また、何れのＦＡＶ機器も、その機器用に生成した汎用ＤＣＭをカスタマイズするための、この情報を利用することができる。しかし、ある機器が有する新たな機能を他の機器に対して通信することを可能にするために、さらに拡張可能なメカニズムが必要である。本発明のレベル２相互運用性により、このメカニズムが得られる。レベル１及びレベル２の相互運用性については、以下に詳細に説明する。
【００７１】
レベル１及びレベル２ＤＣＭ
上述のように、本発明のＤＣＭは、ある機器に対するアクセス、制御、インタラクションを行うことにより機能する。ＤＣＭは、典型的にはホームＨＡＶＩアーキテクチャにおけるＦＡＶのリソース上で示される（例えば実行される）。本発明のＤＣＭは、ある機器に対するインタフェースを提供し、その機器がユーザに提示したいＵＩを管理する。
【００７２】
本発明では、レベル１相互運用性の場合、各機器用に生成されたＤＣＭは汎用的である。これらＤＣＭは、機器の汎用的制御を可能にする最小限のコマンドセットをサポートする。機器特有の特徴をサポートするには、ＤＣＭがこのような機器特有の特徴にアクセスし、ＵＩを介してユーザに機器特有の特徴を提示することが可能でなければならない。
【００７３】
これを達成するために、レベル２相互運用性が使用される。本発明では、ホームＨＡＶＩアーキテクチャは、ある機器がその機器用に通常生成される汎用ＤＣＭに対して、「オーバライドＤＣＭ」を設けることができるようにする。オーバライドＤＣＭ（例えばレベル２ＤＣＭ）は、ＦＡＶのデフォルトＤＣＭ（例えばレベル１ＤＣＭ）を置換することができる。なお、レベル２ＤＣＭは種々のソースから検索することができる。このようなソースの１つとして、機器のＳＤＤ自体がある。この場合、レベル２ＤＣＭが機器のＳＤＤからフェッチ、受信、あるいはその他の方法で獲得され、機器がシステム内に設置されるときにＦＡＶノードにて示される。ホームＨＡＶＩアーキテクチャはベンダに対して中立的なので、レベル２ＤＣＭは、それぞれ異なるハードウェアアーキテクチャを有するかもしれない種々のＦＡＶノードにおいて動作することが必要である。これを達成するために、本発明のレベル１及びレベル２ＤＣＭの両方のフォーマットがアーキテクチャに対して中立的であり、ＦＡＶノードの種々のソフトウェア実行環境がレベル１及びレベル２ＤＣＭを示し動作させることができるようにする。
【００７４】
なお、本発明では、ＦＡＶノードにおいて生成され動作する場合、本発明のＤＣＭは、基本メッセージングシステムを用いて上述と同様にＩＡＶ及びＢＡＶノードとの通信を行う。
【００７５】
上述のように、所定のＨＡＶＩネットワークにおいて可能なＦＡＶ、ＩＡＶ、ＢＡＶノードの組み合わせは多数ある。これらの組み合わせは、概して２種類に分類される。すなわち、ＦＡＶ機器をサポートするＨＡＶＩネットワーク構成と、サポートしないＨＡＶＩネットワーク構成である。この違いは、本質的に、ＨＡＶＩネットワークがピアツーピア構成を使用するか（例えばＦＩＧ．２に示すように、ＦＡＶが存在しない場合）、又は何らかの制御階層を設けるか（例えばＦＩＧ．３に示すようなＦＡＶクラスタ）を定義する。
【００７６】
本発明の一実施例によれば、ＦＡＶが存在しない場合、レベル１相互運用性のみが使用可能であり、各機器は、他のＩＡＶ性能の検出、それらの性能の提示、機器の制御を行うのにＳＤＤ情報を使用しなければならない。ＦＡＶが存在する場合、ＤＣＭが示され使用される。これらがレベル１（例えば汎用）ＤＣＭである場合、各機器はレベル１相互運用性で動作する。レベル２ＤＣＭが少なくとも１つあれば、幾つかの機器はレベル２相互運用性で動作する。
【００７７】
本発明では、機器のうちのクラスタがＦＡＶノードの制御下で相互に動作し、他の機器がピアツーピアで相互に動作する混成動作モードが可能である。このようにして、本発明の柔軟性により、ベンダは、各機器がＨＡＶＩネットワークにおける他の機器とシームレスに相互に動作することを確保するとともに、コスト／性能スペクトルの何れのポイントにおいても機器の設計及び構築の自由を得ることができる。
【００７８】
次に、ＦＩＧ．７を参照して、ＨＡＶＩアーキテクチャの一実施例の論理ブロック７００を説明する。ＦＩＧ．７は、本発明に係るＨＡＶＩアーキテクチャの全体を示す図である。論理ブロック７００におけるコンポーネントは以下の通りである。
【００７９】
デバイスマネージャ７６１：デバイスマネージャ７６１は、ＦＡＶ機器により管理される機器を表すＤＣＭの生成及び管理を行う。
【００８０】
デバイスモジュール７２０：これらは個々の機器のためのＤＣＭである。上述のように、各ＤＣＭは機器の制御ポイントとして機能し、ＵＩコンポーネント及び制御コンポーネントを提供する。ＤＣＭ（例えばデバイスモジュール７２０）は、他のアプリケーションによる機器へのアクセス及び操作を可能にするＡＰＩを提供する。
【００８１】
サービスモジュール７３０：これらのモジュールはソフトウェアモジュールとして考えることができる。これらは、ホームネットワークにおける他の機器又はコンポーネントに対する一般的なサービスを提供するソフトウェアコンポーネント（ハードウェア機器とは異なる）用のＤＣＭである。
【００８２】
通信媒体マネージャ７４０：このコンポーネントは基礎となる物理的通信プロセスの管理を行う。これは、コードモジュールが通信媒体（例えばＩＥＥＥ１３９４）の特徴とインタラクトすることを可能にするＡＰＩを提供する。
【００８３】
レジストリ７０６：これはサービスデータベースである。物理的機器及びソフトウェアサービスのための全てのＤＣＭがレジストリ７０６への登録を行い、全てのモジュール（例えばデバイスモジュール７２０）が、他の機器又はモジュールにアクセスを得るためにレジストリに対して問合せすることができる。
【００８４】
通信マネージャ７５０：このコンポーネントは通信媒体の低レベルのアブストラクトである。
【００８５】
メッセージング７０２：このコンポーネントは、機器（ハードウェア）とデバイスモジュール７２０及びサービスモジュール７３０の両方が、互いに通信を行うことができるようにする基本メッセージ通知手段を与える。
【００８６】
イベントマネージャ７０３：このモジュールは汎用イベントサービスを提供する。これはＨＡＶＩネットワークにおける通知を可能にする他一対多数の通信サービスである。
【００８７】
初期設定マネージャ７０１：このコンポーネントは機器のブートストラッププロセスの一部として使用される。
【００８８】
データルーティング７６２：データルーティングコンポーネント７６２は、機器とデバイスモジュールとの間にサービスがルートを設定するに役立つ。これは、特定ルートを介したデータの転送のコストや、データフォーマット変換の要件等を考慮する。このコンポーネントは基本アーキテクチャには必要とされない。
【００８９】
ＡＶ動作／マクロ７６３：このコンポーネントは、低レベルのコマンドの集合である高レベルのＡＶ動作のマネージャである。すなわち、マクロサービスを提供する。このコンポーネントは基本アーキテクチャには必要とされない。
【００９０】
高レベルＵＩライブラリ７０４：このコンポーネントは、デバイスモジュール７２０がそれに対応する機器のためのＵＩを構築するために使用する高レベルＵＩコンポーネントのセットを提供する。このコンポーネントは基本アーキテクチャには必要とされない。
【００９１】
アプリケーション（及びユーザ）インタフェース７０５：このコンポーネントは、ローカル又はリモートのＨＡＶＩ準拠機器及びアプリケーションの共通の民生用電子機器プラットホーム（common consumer electrics platform：ＣＣＥＰ）ＡＰＩ間のリンクを与える。このコンポーネントは基本アーキテクチャには必要とされない。
【００９２】
なお、ＦＩＧ．７に示す上述のコンポーネントは機能のアブストラクトである。これらは、ＨＡＶＩ準拠機器のためのアーキテクチャにどんな機能が含まれるのかを明確にするように設計されている。本発明を不必要に曖昧にしてしまうことを避けるために、コンポーネント７０１〜７６３の関係やそれらの間のメッセージフローについては、図示を省略する。
【００９３】
ＤＣＭ構成及び機能
概要
本発明の一実施例では、ＦＡＶノードが利用可能なＨＡＶＩネットワーク構成において、そのＦＡＶノードがＨＡＶＩネットワーク内の各物理的機器毎にＤＣＭが存在する。ＤＣＭは機器に対するインタフェースを与え、それをアーキテクチャ内のオブジェクトとして提示する。他のＤＣＭ、システムサービス、アプリケーションサービスは、利用可能な機器を見つけるために、また、ＤＣＭを介して機器とインタラクトすることを可能にする識別子を得るために、ローカルレジストリに問い合わせる。
【００９４】
デバイス制御モジュールは、ソフトウェアアーキテクチャとインタラクトして、ユーザに対するデバイスユーザインタフェース（ＵＩ）を提示する。そして、ユーザからの入力がＤＣＭに入力され、ＤＣＭがその入力を使用して実際の機器を制御する。
【００９５】
上述のように、ＤＣＭはレベル１及びレベル２相互運用性をサポートする。レベル１ＤＣＭは、通常ＦＡＶノードが供給される汎用ＤＣＭであり、所定のメッセージセットを用いて機器クラスの基本的な所定の特徴セットを管理することができる。初期設定の間、ＤＣＭはデバイスマネージャ７６１と共同して、管理される機器の実際の特徴を見つけるとともに、その機器を制御するように自己形成を行う。したがって、汎用ＶＴＲコントローラは、１３９４ＡＶ／Ｃメッセージを用いて、又は制御Ａ１を介して、標準のＶＴＲを制御する。
【００９６】
レベル２相互運用性の場合、その機器のために設けられたＤＣＭは、例えば機器自体等の外部ソースからロードされたオーバライドＤＣＭとなる。これらオーバライドＤＣＭは、ＤＣＭ用の共通言語フォーマットで書かれている。オーバライドＤＣＭの機能は汎用ＤＣＭの機能と異なるわけではないが、与えられたＡＰＩがより包括的なものであることが考えられる。
【００９７】
ＤＣＭが設けられると、ＤＣＭは機器のための制御インタフェースのみならず、機器に関連したＳＤＤデータへのアクセスをも与える。ＤＣＭは機器のイベントマネージャ７０３として動作し、機器特有のイベントを受け取るとともにそれらをイベントシステムに知らせる（以下参照）。また、ＤＣＭは機器のＵＩマネージャとして動作し、ＵＩ管理システムとインタラクトして、何らかの表示装置を介してユーザインタフェースを与える。さらに、ＤＣＭは機器のリソースマネージャとして動作し、機器アクセス及びサービスの要求を調停する。
【００９８】
一般的なＤＣＭの用語
以下の説明で用いる本発明の用語で、各ＤＣＭがホームネットワークにおける機器のモデルを示す。使用する基本的な用語は以下の通りである。
１）機器：この用語は機器全体を表す。
２）サブデバイス：この用語は、デバイス（機器）を構成する多数のコンポーネントのうちの１つを表す。技術によってはサブデバイスを区別する機能がない場合もある。
３）内部接続：この用語は、内部サブデバイス間の論理的又は物理的接続を表す。
４）外部接続：この用語は、ある機器の外側の物理的コネクタと、その機器の外部の送信先機器との接続を表す。ユニットシリアルバスや、ＡＶ／Ｃの外部入出力プラグと同じである。
５）プロトコル：この用語は、サブデバイス又はデバイス（例えばＡＶ／Ｃ、制御Ａ１等）により扱われる制御プロトコルを表す。なお、デバイスは、異なるプロトコルを扱うサブデバイスを有してもよい。
６）インタフェース：この用語は物理的バス接続インタフェース（１３９４、ＵＳＢ等）を表す。
７）機器クラス：この用語は、所定の機器の集合の基本的機能を記述する一方法である。例えば、ＤＶＴＲのクラスは、テープ媒体にデータを記録することができる。同様に、オーディオが入力され、何らかの特殊効果の実行、修正したオーディオストリームを出力することができる多数の機器がある。これらは全て、オーディオプロセッサ等のクラスに属する。この概念の有用性については後述の説明で、より明らかになる。
８）機器モデル：この用語は、標準又はカスタムデバイスの定義を構成するサブデバイス及び接続の集合を表す。物理的に別々のデバイスにおいてアクセス可能な個々のサブデバイスを組み合わせて、機器モデルを用いた論理的又は仮想機器を形成することができる。
９）標準機器：この用語は標準モデルの定義を表す（例えば、ＤＶＴＲは、少なくともチューナサブデバイスとＶＴＲ（トランスポート）サブデバイスからなり、それらの間にプラグを有する）。
１０）特殊機器：この用語は、標準サブデバイス、又は標準サブデバイスとベンダ固有のサブデバイスとの組み合わせにより構成されるベンダ固有機器モデルを表す。例えば、デュアルデッキＤＶＴＲは、標準機器であるが標準構成はない２つのＶＴＲサブユニットを有する。
１１）集合機器：この用語は、種々のコンポーネントから組み合わせることができる論理エンティティを表す。物理的デバイス及びサブデバイスは個々にアクセス可能なハードウェアピースである。各デバイスがアクセス可能なサブデバイスを有する場合、このモデルは拡張されて集合機器をサポートする。集合機器の具体例としては、別々の物理的機器からの又は単一機器内のサブデバイスや、デバイス機器及びサブデバイスと同様のサービス又は性能を提供するソフトウェアコーデック等のソフトウェアモジュールがある。これらのモジュールは、全てＡＶネットワークにおける同一ノードに存在することもでき、又は多数のノードに分散されることもできる。
【００９９】
機器の分類
各機器が行う動作の種類に基づいて、又は各機器が対応する媒体の種類に基づいて機器を分類することにより、将来製造される機器のための動作する汎用化された制御ＡＰＩの生成が可能になる。その目的は、機器の種類や機器の製造業者に関わらず、基本的機能が常に高い割合でアクセス可能であるようにすることである。
【０１００】
制御可能であるが、汎用化された制御ＡＰＩから外れるような製造業者固有の又は機器固有の機能については、ＳＤＤ情報及びＤＣＭを拡張する他の技術を介してのみアクセス可能となる。
【０１０１】
一般的には、デバイス又はサブデバイスの分類については、その主な機能により説明することができる。１３９４規格のＡＶ／Ｃ制御プロトコルでは、以下に説明する従来の機器分類方法を用いる。デバイス又はサブデバイスを分類するのに使用される第１のセットの要素を以下に示す。
１）特定の機器がトランスポートメカニズムを有しているか否か。
２）このサブデバイスの有用性が、主に、信号がここで終わっているという事実により決まるか否か（信号が変更されずに伝達されるという事実とは無関係に）。
３）特定のサブデバイスが信号ソースであるか否か（例えば信号出力を有するか）。
４）特定の機器がデータが入力され、ある種の処理を行い、変更したデータを出力するか否か。
５）いかなる種類の信号入力又は出力も存在しないか否か（例えば、機器が、衛星アンテナを位置決めするためのメカニズム等、ある種のユーティリティであるか）。
【０１０２】
本発明では、第２レベルの分類にて、トランスポートメカニズムを有する機器を検討することができる。この場合、一般的な問合せとして、「この機器は取り外し可能な媒体に対応するか」を問うことになる。対応する場合、Play()、Stop()、Search()等の基本的な制御セットが適用される。媒体を有する機器については、媒体上の情報の構成を判定するために、その記録機能を問い合わせることができる（トラックベースか、テープのように連続的か、どのように測定されるか−ＳＭＰＴＥタイムコード、ある位置からのタイムオフセット等）。
【０１０３】
この具体例では、受けることができる信号の種類や結果として生成することができる種類により、信号処理機器を説明することができる。これは、何れのクライアントでも探しているサービスの種類を説明する方法やそのサービスにアクセスする方法を知ることができるように、信号タイプを説明するための共通の定義やサービスへのアクセス方法の確立が必要である。
【０１０４】
ある種のデータが入力されるとともに、異なる種類の接続でそのデータを伝送する機能を有する機器（例えば、デジタルビデオを入力として、そのデータを送り返すことができる標準アナログビデオＲＣＡジャックを有する機器）は、いずれも、データコンバータクラスとして動作することができる。これらの機器のためのＤＣＭは、システムレジストリにおけるデータコンバータとして登録されるので、クライアントは必要に応じてそれらを見つけて使用することができる。
【０１０５】
機器のアクセス及び制御
本発明では、基本的な機器分類がなされると、その機器のために設けられた汎用ＤＣＭは、その機器に制御メッセージが送られるようにするＡＰＩを与える。特定クラスの機器に送られる又は（イベント場合は）受信される基本的な制御メッセージセットは、標準化されている。この具体例では、これらのメッセージはＤＣＭにより与えられた基本ＡＰＩを表す。
【０１０６】
機器管理
本発明では、ＤＣＭのＡＰＩは、より複雑な機器管理を可能にする高レベルサービスのセットも与える。この具体例としては、機器の予約やイベント管理が含まれる。機器の予約の場合、ある機器に対する要求がその機器への既存の要求により拒否されることがある。あるいは、機器要求がタイムベースマクロのその後の予約に関するものであってもよい。これらの場合、ＤＣＭは、アプリケーション又はサービスがＤＣＭに対して要求をキューに登録（queue）すること、すなわち機器の予約を可能にする、又は機器が利用可能となったときに通知を受けることを可能にするインタフェースを与える。
【０１０７】
接続管理
また、本発明のＤＣＭは、他のオブジェクトが機器間の接続状態を問い合わせて、それらの接続を操作することを可能にする高レベルＡＰＩを与える。このＡＰＩは主としてルートマネージャにより使用されるが、システム内の何れのオブジェクトに対しても使用可能である。接続管理により、内部的にはサブデバイスユニット間で、また、外部的にはデバイス間で接続を確立することができる。接続状態を問い合わせることができるとともに、接続機能（信号フォーマット）を問い合わせることもできる。
【０１０８】
ＳＤＤ管理
また、本発明のＤＣＭは、ＳＤＤ管理に対する汎用化されたインタフェースを与える。これにより、機器内のＳＤＤデータの問合せ及び使用が可能になる。ＡＰＩは２つの部分に分割され、第１の部分は、デバイスイメージ、その名称、オーバライドＤＣＭ又は機器のＵＩを表す際に使用される他のアイコンの位置のＵＲＬ（利用可能ならば）を含むＳＤＤデータから周知の情報を得るためのＡＰＩを与える。ＳＤＤのＡＰＩの第２の部分は、機器の機能的特徴へのより詳細なアクセスを与えるように設計されている。
【０１０９】
機器の表示及びユーザインタフェース（ＵＩ）
本発明では、ＤＣＭは機器のＵＩ特徴にも関わっている。レベル１相互運用性の場合、ユーザとのインタフェースを行うのに汎用ＵＩが使用される。これは、ＵＩアイコン等の特徴が汎用ＤＣＭにより特定されアクセスされるようにする基本的ＳＤＤデータにより増加してもよい。本発明を不必要に曖昧にすることを避けるために、どのようにＤＣＭがＵＩ管理システムとインタラクトして機器固有のＵＩを与えるのかについては、詳細な説明を省略する。しかし、この具体例において、基本モデルは、ＤＣＭ内の内部管理コードがＵＩ管理システムと共同して機器用のＵＩを与えるものである。ＵＩ管理システムによりユーザ入力がＤＣＭに送られ、ＤＣＭがそれを機器固有のコマンドに変換する。これらのコマンドは、基本メッセージングシステムを用いて機器に送られる。応答が受信された場合、これらはＤＣＭを介してＵＩに送られる。さらに、機器のいかなる状態変化、例えば、オン／オフについても、イベントシステムを介してＤＣＭに送られ、ＤＣＭはそれらを用いてＵＩを更新する。
【０１１０】
サービスモジュール
サービスモジュール（例えばサービスモジュール７３０）は、概念的にはデバイス制御モジュールと同じである。これらは、通常ソフトウェアのみによって提供されるサービスへのインタフェースを与える。この具体例において、サービスモジュールは、システムサービスとアプリケーションサービスの２種類がある。システムサービスは、ＨＡＶＩソフトウェアアーキテクチャの一部として与えられる周知のサービスである。このタイプのサービスの具体例としては、データフォーマット変換器、プロトコル変換器、グラフィックサービスがある。これらのサービスは、ＨＡＶＩアーキテクチャの一部として定義される周知のＡＰＩを有している。アプリケーションサービスは、他のサービスオブジェクトによりそのために生成されたオブジェクトである。これらのオブジェクトは明確に定義されたＡＰＩを与えるが、そのＡＰＩは周知のものではない。この具体例では、アプリケーションオブジェクトを使用したいアプリケーション又は他のオブジェクトはいずれも、そのＡＰＩとコーリングセマンティクスを知る必要がある。必要ではないが、一般的に、システムサービスは、システムの寿命に亘って存在する。アプリケーションサービスは、アプリケーションの寿命に亘って存在し、非常に短命である。
【０１１１】
システムサービス
本発明では、ＨＡＶＩアーキテクチャにより提供されるサービスの多くはサービスモジュールとして提供され、これらはサービスをシステムレジストリに登録し、メッセージングを用いてアクセスすることができる。このようなサービスの具体例としては、機器がＵＩをユーザに与えることを可能にするメカニズムを与えるＵＩサービスモジュールや、種々のフォーマット間のＡＶデータを変換するデータフォーマットサービスがある。
【０１１２】
ＤＣＭマネージャ
概要
本発明では、ＤＣＭマネージャは、ＦＡＶノードにあるＤＣＭの集合を扱う全ての特徴に関するものである。これには、所定システムに利用可能である全てのデバイス制御モジュール候補の検出（discovering）、具現化（instantiating）、破棄（disposing）が含まれる。機器リソース管理は、一般的に個々のＤＣＭによって行われるが、多数の機器又はサービスがインタラクトしている場合、又はＤＣＭのうちの幾つかが異なるＦＡＶノードに配置されている場合、より高いレベルの管理が必要となる。したがって、ＤＣＭマネージャは、離れたノードにおける他のＤＣＭマネージャと通信を行って、ネットワーク全体のデバイス及びサブデバイスリソースの割り当て及び管理のために調停を行う。ＤＣＭマネージャの機能については以下に説明する。
【０１１３】
物理的機器の検出及び列挙（enumeration）
本発明では、ＤＣＭマネージャは、基礎となるＯＳサービスと共同して、利用可能な機器の元リスト（raw list）を得る。なお、基礎となるバス技術によっては、これらＤＣＭが動的になることもある。この具体例では、例えば、物理的機器が１３９４バスを介して移動するので、ＤＣＭもそれとともに移動する。同様に、サービス及び集合機器ＤＣＭも動的であり、ＦＡＶノードにおけるイベントに応じて生成や破壊が行われる。
【０１１４】
このタスクには、ＨＡＶＩアーキテクチャの構成要素とのインタラクションと、ＦＡＶホストＯＳ、ノードハードウェア、通信ハードウェアの構成要素とのインタラクションの両方が必要である。これにより、機器検出に必要な適切なプロセスはシステム環境によって異なる。しかし、ＤＣＭの箇所で説明したように、機器とその特徴を検出するために有するＳＤＤデータを問い合わせるというアプローチが一般的である。この具体例では、システムが初期化される毎に、又はシステムが変更される（例えばバスがリセットされる）毎に、ＤＣＭマネージャが所定の順序で規則のセットに従う必要がある。
【０１１５】
汎用ＤＣＭの生成
本発明では、各ノード毎に、ＤＣＭマネージャが、ＤＣＭを生成すべきであることを決定するのに十分な作業を行う。この作業はＦＡＶノードにより管理される全ての媒体関連機器について行われる。この具体例では、異なる管理技術による機器、例えば、ＵＳＢベースの機器が、ＵＳＢ通信をサポートするノードにおけるＤＣＭとして、又は遠隔管理システムのための代理として動作する特殊ＤＣＭとして、アーキテクチャ内に設けられてもよい。しかし、ハードディスク等、幾つかのＵＳＢベースの機器は、実際は単にランダムアクセス媒体記録又は再生機器とされていることもある。この場合、これらは他の「実際の」媒体機器として扱われる。この具体例では、各媒体間連エンティティ毎に、ＤＣＭマネージャが汎用又はレベル１ＤＣＭを生成する。各ＤＣＭは、可能であれば、より機器固有ものとなるための機能を後で持つことになる。これについて以下に説明する。
【０１１６】
オーバライド（例えばレベル２）ＤＣＭが利用可能でアクセス可能である場合、ＤＣＭマネージャは、そのＤＣＭをフェッチしてＦＡＶノードにインストールすることになっている。この具体例では、オーバライドＤＣＭと汎用ＤＣＭがどのようにインタラクトするかについての詳細は、ＤＣＭディベロッパーによって異なる。例えば、デフォルトＤＣＭを完全に置換する場合もあれば、デフォルトＤＣＭと共同して機能を高める場合もある。
【０１１７】
本発明では、製造業者が提供するレベル２ＤＣＭは種々のソースから得られるものである。各機器は、それらをＲＯＭ内、ディスク又はテープのヘッダ等の記憶メカニズムに保持してもよい。それらは、ＦＡＶにとってアクセス可能ならばウェブサイト又はｆｔｐサイトからダウンロードしてもよく、又はディスクやその他の記憶媒体からのインストールにより典型的なコンピュータ業界のやり方で提供することもできる。製造業者が提供するオーバライドＤＣＭの機能を可能にするには、ＤＣＭの生成及びインストールのモデルが必要である。この具体例では、レベル２ＤＣＭがインストールされると、レベル１ＤＣＭと同じベースインタフェースをクライアントに供給するとともに、新たなインタフェースを提供するか、又は機能の変更に応じる。
【０１１８】
ＤＣＭの破棄
本発明では、ＤＣＭマネージャは適切な時点でＤＣＭを破棄し、ＤＣＭが除去されたことをクライアントに通知することになっている。この具体例では、ＤＣＭを破棄するときの規則や、ＤＣＭとＤＣＭマネージャとの間のクリーンアップの責任の分担は、特定のＨＡＶＩネットワークの特定要件に合わせて調整することができる。
【０１１９】
多数のＤＣＭ間での調整
多数のＤＣＭ間の幾つかの複雑なサービス、例えば、複雑な動作のコマンドキュー等の場合、ＤＣＭマネージャは多数のＤＣＭと調整して、これらの動作を行う必要がある。これは、クライアントに供給された「コマンドモデル」により影響を受ける。例えば、クライアントがＨＨ：ＭＭ：ＳＳ：ＦＦタイムコードに基づく動作を特定することができるようにする上位のＡＰＩを定義する場合、このタイムモデルと、ハードウェア又は基礎となるサポートモジュールが対応するものとの変換を行う必要がある。なお、メカニズムの遅延等により影響される複雑なタイムベースの動作について説明しなければならない。このタイプの調整には、ネットワークにおける実時間動作の概念が必要であり、ある程度の保証を与える物理的及びソフトウェア的基礎構造によって異なる。
【０１２０】
次にＦＩＧ．８を参照して、本発明に係るＨＡＶＩアーキテクチャのレイヤ論理図８００を説明する。論理図８００に示すコンポーネントは論理図７００に示すコンポーネントと同じであるが、論理図８００の場合は、低レベルプロセスが下に配置されている（例えば１３９４モジュール８３０）のに対し、高レベルプロセスが上に配置されている（例えばアプリケーション８０１）。また、論理図８００は、他のサービス８１０、トランスポート適応モジュール８１５、他のモジュール８４０も示す図である。
【０１２１】
上述のように、ＨＡＶＩアーキテクチャ全体を、通信コンポーネントとサービスコンポーネントとして示すことができる。このアーキテクチャ内の最上位レベルにあるアプリケーション８０１は、サービスと通信コンポーネント（例えばＤＣＭ７２０、サービスモジュール７３０等）を使用する。そして、多数のサービスコンポーネント（例えばサービスモジュール７３０、ＤＣＭ７２０等）は、基礎となる通信コンポーネント（例えばメッセージング７０２、トランスポート適応モジュール８１５等）を使用する。例えば、アプリケーション８０１のうちの１つが、レジストリ７０６を介してＤＶＴＲ（デジタルビデオテープレコーダ）機器のハンドルを要求し、その機器に再生コマンドを送る場合である。上述のように、ＨＡＶＩアーキテクチャにおけるコンポーネントは、基礎となるメッセージングシステムを用いて通信を行う。すなわち、モジュールがメッセージ通知を使用する。
【０１２２】
ＦＩＧ．９は、一実施例のＨＡＶＩアーキテクチャにおけるローカル及びリモートメッセージングの図９００を示す図である。メッセージングコンポーネント７０２はローカルメッセージング及びリモートメッセージングの両方を扱うものとして示されている。したがって、メッセージングコンポーネント７０２は図９００のベースに示されている。ローカルメッセージは、種々のアプリケーション９０１〜９０４に対する矢印９０２ａ，９０３ａ，９０４ａとして示されている。リモートメッセージは矢印９０１ｂで示されている。説明を明確にするために、図９００及び以下の説明では、メッセージングシステムを介したローカル通信については省略し、ローカルメッセージング（例えば矢印９０１ａ〜９０４ａ）がコンポーネント間の直接機能コールに基づいているものとして示す。
【０１２３】
ＦＩＧ．１０は、一実施例のＨＡＶＩアーキテクチャにおけるＩＥＥＥ１３９４を介して送られるメッセージの図１０００を示す図である。図１０００において、メッセージ１（例えば矢印８２０ａ）は、ＤＶＴＲ機器のハンドルを求める（問合せＡＰＩを介した）レジストリ７０６に対するアプリケーション８０１の１つからの要求である。レジストリ７０６は、メッセージ２（例えば矢印８２０ｂ）にてＤＶＴＲＤＣＭのためのハンドルを送り返す。このハンドルはメッセージングシステムに使用されるメッセージアドレスである。
【０１２４】
本発明では、アプリケーションはハンドルを使用して、メッセージ３（例えば８２０ｃ）によりＤＶＴＲのＤＣＭを起動する。ＤＣＭは再生コールのアプリケーション起動を内部コマンドに変換し、これがメッセージ４（例えば矢印８２０ｄ）としてメッセージコンポーネントに送られる。この内部コマンドはレベル１に設定された明確に定義されたコマンドの一部である。すなわち、ＨＡＶＩコマンドである。メッセージングコンポーネント７０２はハンドル情報を内部的に使用して、この機器がどのバス上にあるのかを判定する。機器がＩＥＥＥ１３９４バス上にあることがわかると、メッセージコンポーネント７０２はＩＥＥＥ１３９４トランスポート適応モジュール（ＴＡＭ）８３０を使用して、メッセージをメッセージ５（例えば８２０ｅ）としてＩＥＥＥ１３９４パケットに変換し、これがＦＣＰパケットのデータ部に配置される。ＴＡＭは、メッセージ６（例えば８２０ｆ）としてＩＥＥＥ１３９４デバイスドライバを呼び出し、１３９４を介してメッセージを送る。
【０１２５】
受信側では（図示せず）、メッセージがＩＥＥＥ１３９４デバイスドライバに供給された後、１３９４ＴＡＭを介してメッセージングコンポーネントに送られる。メッセージングコンポーネントは、ＨＡＶＩメッセージパケットを受け取り、メッセージキュー又はコールバック機能を介して直接受信コードに供給する。この具体例では、受信機がＩＡＶ機器である場合、ＣＣＥＰアーキテクチャの通信コンポーネントとレジストリのみを有する。ＩＡＶ機器が有する他の機能はいずれも機器固有のものである。
【０１２６】
なお、ＦＩＧ．１０の具体例では、メッセージングシステムと機器の制御に使用するコマンドセットとのＨＡＶＩアーキテクチャの違いを示している。本発明では、メッセージングシステムは、メッセージングシステムにとって完全に不明瞭な内容のデータ部を有するメッセージパケットを供給する汎用メッセージングメカニズムである。例えば、メッセージングシステムは、アプリケーションコマンド、ＡＶＣ−ＣＴＳコマンド、ＣＡＬコマンド、その他のコマンドに対するプライベートアプリケーションを送ることができる。ＤＣＭはリモート機器と通信を行うエンティティであり、メッセージングシステムを使用して、その機器に固有のコマンドを送る。レベル１ＨＡＶＩ準拠機器の場合、メッセージングシステムにより送られるコマンドセットはＣＣＥＰアーキテクチャの一部として定義される。ＤＣＭとそれが制御する機器との間でメッセージングシステムにより送られるメッセージには、これらの明確に定義されたコマンドが含まれる。レベル２機器の場合、拡張コマンドセットが定義されておらず、これらは純粋なＡＶ／Ｃ−ＣＴＳ、ＣＡＬ、その他のコマンドであってもよい。
【０１２７】
ＦＩＧ．１１を参照して、ＨＡＶＩアーキテクチャの一実施例における他のアプリケーションを起動するアプリケーションの図１１００を説明する。図１１００は、メッセージングシステム７０２ａ，７０２ｂを介して、別の機器１１０２で動作するアプリケーション８０１ｂにメッセージ１１０５を送る、機器１１０１で動作するアプリケーション８０１ａを示す図である。上述のように、ＨＡＶＩネットワークにおいて動作するアプリケーションはいずれも、他のアプリケーションのためのメッセージハンドルを有しているときは、そのアプリケーションにアクセスすることができる。メッセージハンドルを得るには、リモートＩＡＶ機器（例えば上述のＦＩＧ．１０で説明したような）と同じプロセスが用いられる。メッセージハンドルが使用可能となると、ソースアプリケーション８０１ａは目的アプリケーション８０１ｂにメッセージ１１０５を送ることができる。上述のように、これらのメッセージのフォーマットはアプリケーションによって全く異なり、ＣＣＥＰアーキテクチャとは関係がない。これは、アプリケーション間で受信メッセージを送るための通信メカニズムを提供するだけである。
【０１２８】
なお、上述の具体例では、アプリケーション８０１ａ，８０１ｂが異なるＡＶ機器１１０１，１１０２に存在することを想定している。しかし、上述のように、これらのアプリケーション８０１ａ，８０１ｂが同じＡＶ機器に存在し、メッセージングシステムが、ＩＥＥＥ１３９４を使用してメッセージを送るコールではなく、純粋にローカルな通信コールを行うこともできる。
【０１２９】
ソフトウェアサービスの起動
ソフトウェアサービスは、上述の汎用アプリケーションの場合の特殊なケースである。本発明では、ソフトウェアサービスは、単にシステム基礎構造の一部をなすアプリケーションである。この場合、モジュールは、例えばＵＩコンポーネント等のシステムサービスを起動したいとき、メッセージングコンポーネントを使用してこれを行う。ＵＩコンポーネントがローカルである場合、コールは完全に１つのＡＶ機器内に含まれている。しかし、ＵＩコンポーネントがリモートである場合、コールは１３９４ネットワークを介してリモートＡＶ機器に供給され、そこでメッセージシステムがＵＩシステムサービスに対してコールを送る。
【０１３０】
ＨＡＶＩネットワークへの新たな機器の追加
ＨＡＶＩネットワークに新たな機器を追加する際、以下の３つの一般的な状況がある。すなわち、非ＩＥＥＥ１３９４ネットワークを介して送られる従来のプロトコルを用いる従来の機器を扱う場合と、ＩＥＥＥ１３９４ネットワークを介した非ＨＡＶＩプロトコルを用いるベース機器を扱う場合と、ＨＡＶＩ準拠の新たなＩＡＶ機器を扱う場合である。
【０１３１】
従来の機器を追加する場合、この具体例では、従来の機器はＦＡＶノードによって直接制御することしかできない。上述のように、各従来の機器毎に従来ＤＣＭが生成されなければならない。ＩＥＥＥ１３９４ポートとイーサネットポートとを有するＦＡＶを想定する。ＣＭＭモジュールはＩＥＥＥ１３９４とイーサネットの両方を管理するように構成される。従来の機器がＦＡＶに知らされるときは、まずＣＭＭモジュールにて知られる。なお、これを達成するのに使用するメカニズムはＣＣＥＰアーキテクチャの範囲内ではない。これは通信媒体に固有のものである。ＣＭＭが新たな機器を認識すると、機器の種類を判定するために使用する媒体固有メカニズムを通る。これもＣＣＥＰアーキテクチャを構成するものではない。そして、ＤＭに対してこの機器のための従来ＤＣＭを設けるように要求する。ＦＡＶノードは、予めこのＤＣＭを有して構成されているものとみなされる。
【０１３２】
この具体例では、ＤＣＭは、生成されると、標準ＤＣＭと同じように登録される。しかし、このＤＣＭと他のＤＣＭとの重要な差異は、通信モデルと従来の機器を制御するのに使用するコマンドセットとがＣＣＥＰアーキテクチャにとって完全に未知のものであるという点である。例えば、この機器がプリンタサービスを行うＩＰ機器であることも可能である。この場合、ＤＣＭはプリント、状態等のコマンドセットを供給する。アプリケーションがプリント要求によりＤＣＭＡＰＩを呼び出すと、ＤＣＭによりプリントコマンドがＩＰスタックを介してプリンタ装置に送られる。これがどのように行われるかについての詳細は、実行手段によりそれぞれ固有ものである。
【０１３３】
本発明では、一つの可能性として、従来ＤＣＭがＤＣＭ内のＩＰスタックの完全な実行手段を有し、イーサネットデバイスドライバに接続する方法を知っていることが考えられる。また、他の可能性として、ＦＡＶ機器がＩＰスタック及びソケット等の高レベルＡＰＩを提供することが考えられる。これらは、ＦＡＶの実行手段の詳細であり、ＣＣＥＰアーキテクチャを構成するものではない。しかし、従来ＤＣＭは「代理」ＤＣＭとして動作している。従来ＤＣＭがレジストリに登録されると、ホームネットワークにおける他の全てのモジュールにとって認識できるようになる。これらは全て、従来ＤＣＭのＡＰＩを起動することができ、従来ＤＣＭはイーサネットＩＰプリンタのプライベートコマンド言語への必要な変換を行う。
【０１３４】
ベースＡＶ機器を追加する場合、この具体例では、ＣＭＭが新たな機器について通知を受けると、それがＣＣＥＰノードではないことを認識するが、ＤＣＭがこの機器にとって利用可能であることも検出する。この場合、ＣＭＭが、ＤＣＭをアップロードするとともにこのＤＣＭを生成するようにＤＭに要求することを可能にするメカニズムを実行することになっている。しかし、ＤＣＭが設けられると、純粋にプライベートな通信メカニズムを使用して機器に対するアクセス及び制御を行う。上述のように、この具体例では、ベースＡＶ機器は、１３９４を使用しオーバライドＤＣＭを実行するが、ＣＣＥＰアーキテクチャの実行は行わず、また、レベル１ＨＡＶＩコマンドの実行も行わない機器である。この機器の具体例としては、オーバライドＤＣＭを有するがＣＣＥＰ通信基礎構造をサポートしない機器が考えられる。
【０１３５】
ＩＡＶ機器を追加する場合、上述の具体例では、アプリケーションが通信を行いたい機器のメッセージハンドルを得るためにレジストリに対して問合せを行った。ＦＡＶ機器については、送り返されたハンドルが常にＤＣＭにアクセスするために使用される。メッセージを直接機器に送ることは不可能である。ネットワークに追加された機器がレジストリを介してどのように利用可能になるかを理解するために、以下の具体例を用いる。
【０１３６】
例えば、新たな機器（例えばビデオカメラ）がＨＡＶＩネットワーク（例えば１３９４ベースのもの）に接続されたとする。これによりバスリセットが生じる。バスリセットはＩＲＤにおける通信媒体マネージャ（ＣＭＭ）により扱われる。ＣＭＭは、ビデオカメラのＳＤＤデータを問い合わせて、その機能を見いだすことになっている。機器がレベル１機器である場合、すなわち、機器がアップロード可能なＤＣＭを有していない場合、ＣＭＭは新たな機器が設置されたことをそのデバイスマネージャに通知する。デバイスマネージャは、このタイプの機器のための新たなＤＣＭを生成し、ＤＣＭをレジストリに登録する。ＤＣＭは、初期設定されると、自由に機器に対して問合せを行って機器に関するさらなる情報を直接求めることができ、また、必要な場合に特殊化、例えば、ＵＩ情報が機器内に存在する場合はＵＩ情報へのアクセスを行うことができる。ＤＣＭがレジストリに登録されると、他の何れのモジュールもレジストリに問合せを行って、その機器のためのハンドルを得るとともにＤＣＭと通信を行い、機器に対するアクセスや制御、及び、ユーザへのＵＩの提示を行うことができる。
【０１３７】
例えば、ＦＩＧ．１２Ａ及び１２Ｂは、このような機器（例えばビデオカメラ）の例示的なＵＩ表示（例えばテレビジョン受像機の画面上の）を示す図である。ＦＩＧ．１２Ａは、制御名や制御値を用いて変更することができる種々の制御がユーザに提示されるテキストメニュー表示を示す図である。ボタンについて、ユーザが選択することができる（ボタンを押すこと）。ＦＩＧ．１２Ｂは、ビデオカメラの「次レベル」のＵＩ表示を示す図である。ここでは、ユーザがＦＩＧ．１２Ａのメニューからメインパネルを選択し、表示はグループ分け情報に基づく制御を示す。この具体例では、グループ名がラベル付きインタフェース上で使用されることにより、ユーザが、選択したパネル内のグループ間でナビゲーションを行うことができる。
【０１３８】
次にＦＩＧ．１３を参照して、本発明を適用したプロセス１３００のフローチャートを説明する。プロセス１３００は、各機器に記憶されたＳＤＤ情報を用いることにより、ＨＡＶＩネットワークにおける複数の機器のシームレスな相互運用性及び統合を行う方法の各ステップを示す。プロセス１３００はステップ１３０１から開始するが、ステップ１３０１において、新たな機器がＨＡＶＩネットワークに接続される。ステップ１３０２において、その機器によりサポートされるレベル１機能の記述（例えばＳＤＤ）を得るために、機器に対して問合せが行われる。ステップＳ１３０３において、その機器のために、レベル１機能を実行するレベル１ＤＣＭがＳＤＤに基づいて生成される。ステップ１３０４において、新たな機器がレベル２ＤＣＭのソフトウェアを有しているか否かをデバイスマネージャが判定する。
【０１３９】
ＦＩＧ．１３のステップ１３０５において、新たな機器がレベル２機能を実行するためのソフトウェアを有している場合、そのソフトウェアが機器から検索され、ステップ１３０６において、そのソフトウェアを用いてレベル２機能を実行するレベル２ＤＣＭが生成される。ステップ１３０７及び１３０８において、レベル２ＤＣＭを介して機器が連続的にアクセスされる。ステップ１３０９及び１３１０において、新たな機器がレベル２ＤＣＭのソフトウェアを有していない場合、レベル１ＤＣＭを介してその新たな機器が連続的にアクセスされる。このように、本発明は、レベル１ＤＣＭとレベル２ＤＣＭの組み合わせにより、ネットワーク内の複数の機器との新たな機器のシームレスな相互運用性及び統合を行うことができる。
【０１４０】
ＦＩＧ．１４は、本発明を適用したプロセス１４００のフローチャートを示す図である。プロセス１４００は、ＨＡＶＩネットワーク内の複数の機器間で基本コマンド機能と拡張コマンド機能を行う方法の各ステップを示す。ステップ１４０１において、ＦＡＶ機器を含むＨＡＶＩネットワークに、ある機器が接続される。ステップ１４０２において、その機器用の汎用レベル１ＤＣＭがＦＡＶ機器により生成される。上述のように、汎用レベル１ＤＣＭは機器の機能の基本アブストラクトである。汎用レベル１ＤＣＭによって、機器は、ＦＡＶ機器からの基本コマンドセットに応答することが可能になる。ステップ１４０３及び１４０４において、ＦＡＶ機器が汎用ＤＣＭを使用して機器に問合せを行い、機器が記述情報（例えばＳＤＤ）を有しているか否かを判定する。上述のように、記述情報は機器の機能を記述する。ステップ１４０５において、機器が記述情報を有している場合、ＦＡＶ機器は記述情報に基づいて汎用ＤＣＭを変更することにより、その機器用のパラメータ化したＤＣＭを生成する。ステップ１４０６及び１４０７において、パラメータ化したレベル１ＤＣＭを用いて機器が連続的に制御される。ステップ１４０８及び１４０９において、機器が記述情報を有していない場合、ＦＡＶ機器は汎用レベル１ＤＣＭを介して連続的に制御される。
【０１４１】
次にＦＩＧ．１５を参照して、本発明を適用したプロセス１５００のフローチャートについて説明する。プロセス１５００は、ＨＡＶＩネットワーク内の機器の将来的なアップグレード性及び拡張性を確保する方法の各ステップを示す。ステップ１５０１において、ネットワークに接続されたある機器用のデフォルトのレベル１ＤＣＭが生成される。上述のように、デフォルトレベル１ＤＣＭは、ＨＡＶＩネットワークにおける、この機器と他の機器との間で少なくとも最小限の相互運用性を確保するように構成されている。ステップ１５０２において、この機器がデフォルトレベル１ＤＣＭを介して他の機器によりアクセスされる。上述のように、デフォルトＤＣＭにより、第１の機器はＨＡＶＩネットワーク内の他の機器からのデフォルトコマンドセットに応答することが可能になる。ステップ１５０３において、この機器用の更新されたレベル１ＤＣＭが受け取られるか否かが判定される。ステップ１５０４において、この機器用の更新されたレベル２ＤＣＭが受け取られるか否かが判定される。上述のように、更新により機器の機能及び性能が発展することが可能となる（例えば新たな、より効率的なソフトウェアが利用可能となる）。
【０１４２】
ステップ１５０９及び１５０８において、更新されたレベル１ＤＣＭが受け取られた場合、その更新レベル１ＤＣＭが組み込まれ（例えば、これは単に現レベル１ＤＣＭを変更するのみのこともある）、次の更新が利用可能となるまで、このＤＣＭを介して機器が連続的にアクセスされる。ステップ１５０５において、更新レベル２ＤＣＭが受け取られた場合、ホストＦＡＶ機器上のＤＣＭマネージャが現ＤＣＭのリンクを外し、ステップ１５０６及び１５０７において、更新レベル２ＤＣＭがリンクされるとともにレジストリが更新されて、ＨＡＶＩネットワーク内の他の機器が更新レベル２ＤＣＭにアクセスすることが可能になる。このＤＣＭは、次の更新レベル２ＤＣＭが受け取られるまで、機器にアクセスするのに連続的に使用される。ステップ１５１０において、更新レベル１ＤＣＭも更新レベル２ＤＣＭも受け取られない場合、プロセス１５００は、現ＤＣＭ（例えば最後にインストールされたＤＣＭ）を用いて動作を継続する。
【０１４３】
ＦＩＧ．１６は、本発明を適用したプロセス１６００のフローチャートを示す図である。プロセス１６００は、ＨＡＶＩネットワークにおけるＨＡＶＩ準拠機器に対する従来の機器のシームレスな相互運用性及び統合を行う方法の各ステップを示す。プロセス１６００はステップ１６０１から開始するが、ステップ１６０１において、従来の機器がＨＡＶＩネットワークに接続される。ステップ１６０２において、専用プロトコルを介して従来の機器に問合せが行われ、従来の機器の基本性能セットを判定する。上述のように、ＨＡＶＩ準拠機器はＨＡＶＩにより定められた共通プロトコルを使用する。従来の機器は、典型的には専用プロトコルを用いて外部機器（もし、あれば）と通信を行う。ステップ１６０３において、プロセス１６００が共通プロトコルからの基本コマンドセットを、従来の機器の基本性能セットにマッピングする。ステップ１６０４において、従来の機器用のレベル１ＤＣＭが生成される。上述のように、ＤＣＭは基本コマンドセットに基づくものである。ステップ１６０５及び１６０６において、レベル１ＤＣＭを介して従来の機器が連続的にアクセスされ、他のＨＡＶＩ機器が従来の機器の基本性能セットにアクセスすることが可能となる。
【０１４４】
ＦＩＧ．１７Ａは、本発明を適用したプロセス１７００のフローチャートを示す図である。プロセス１７００は、外部サービスプロバイダからのアプリケーションプログラムを用いてホームオーディオ／ビデオネットワーク内の機器を制御する方法の各ステップを示す。ステップ１７０２において、サービスプロバイダによりアプリケーションプログラムが生成される（例えばケーブルテレビジョン、インターネットウェブサイト等を介して）。ステップ１７０３において、サービスプロバイダが、論理チャンネルを介してサービスプロバイダからＨＡＶＩネットワークの高機能レシーバ／デコーダ機器にアプリケーションプログラムを送る。そして、アプリケーションは高機能レシーバ／デコーダ機器のコンピュータで読取り可能なメモリユニットに設けられる。
【０１４５】
ＦＩＧ．１７Ａのステップ１７０４において、アプリケーションプログラムが機器（例えばＦＡＶ機器）のＨＡＶＩレジストリに問合せを行ってネットワーク上のＤＣＭの位置を検出するとともに、レジストリからの各ＤＣＭを選択する。ステップ１７０５において、ダウンロードされたアプリケーションが、選択されたＤＣＭからの通信ポイント情報を判定する。ステップ１７０６において、アプリケーションが、通信ポイント情報を用いて各機器と通信を行うことにより、ＨＡＶＩネットワークの各機器を制御する。ステップ１７０７において、アプリケーションが別の機器を制御する必要がある場合、ステップ１７０４〜１７０６を繰り返す。アプリケーションが別の機器を制御する必要がない場合、プロセス１７００はステップ１７０８において終了する。
【０１４６】
ＦＩＧ．１７Ｂは、ＦＩＧ．１７Ａのプロセス１７００に基づいたサービスプロバイダ１７２０を有するＨＡＶＩネットワーク１７５０を示す図である。上述のように、アプリケーションプログラムはサービスプロバイダ１７２０からＨＡＶＩネットワーク１７５０にダウンロードされる。アプリケーションは、高機能機器（例えばセットトップボックス３０１）のプロセッサ６０１及び揮発性メモリ６０２に設けられる。また、ＨＡＶＩネットワーク１７５０は、機器０〜機器３（例えばテレビジョン受像機、ＤＶＴＲ等）の４つのＨＡＶＩ機器を備えている。
【０１４７】
ＤＣＭ管理ＡＰＩ
本発明を適用したＤＣＭ管理ＡＰＩの具体例を以下に示す。この具体例では、共通ＤＣＭコマンドが、接続管理、機器及びそのプラグに関する情報及び状態の問合せ等のエリアを含む。ＤＣＭにより表される機器の種類に関わらず、このようなメッセージセットをサポートする必要がある。
【０１４８】
以下、この具体例において全てのＤＣＭがＨＡＶＩアーキテクチャのためにサポートする必要があるＤＣＭ管理メッセージのリストを示す。
ChannelUsage(plug);//returns the 1394 isoch. channel used by the specified unit plug（特定ユニットプラグにより使用される１３９４アイソクロナスチャンネルをリターン）
PlugUsage(channel);//returns the plug associated with the specified channel（特定チャンネルに関連するプラグをリターン）
GetDevicePlugCount(count);//returns the number of unit plugs on the device（機器のユニットプラグ数をリターン）
EstablishInternalConnection(sourcePlug, destPlug);
EstablishExternalConnection(sourcePlug, destPlug)
StartDataFlow(plug);
StopDataFlow(plug);
GetSourceConnection(in dest, out source);//given a destination plug, return the source to which it is connected (return the source plug of the transmitting device which shares the same isoch. channel)（デスティネーションプラグが与えられたら、それが関連するソースをリターン（同じアイソクロナスチャンネルを共用する送信機器のソースプラグをリターン））
GetDestinationConnection(in source, out);
GetAllConnection();
NotifyOnConnectionChange();
GetDynamicConnectionCapability();//report whether the target device supports dynamic connection changes or not （目的の機器が動的な接続変更をサポートするか否かを報告）（例えば非１３９４機器）
LockConnection(plug);
UnlockConnection(plug);
GetConnectionStatus(plug);//status = busy, data transmission format, channel, bandwidth usage, etc.
BreakInternalConection(plug);
BreakExternalConnection(plug);
GetInputSignalFormat(plug);
SetInputSignalFormat(plug);
NotifyInputSignalFormat(plug);//send a notification if the signal format is changed（信号フォーマットが変更されたら通知を送る）
GetSupportedInputSignalFormats(plug);//repeat the above for output signals（出力信号について上記を繰り返す）
GetFunctionInfo();//return information about the functional modules within the device （機器内の機能モジュールについての情報をリターン）（例えばＡＶ／Ｃサブユニット）
GetDeviceType();
GetVendorName();
GetVendorLogo();
SetDevicePowerState(powerstate);
GetDevicePowerState(powerstate);
GetSupportedPowerState(list);
NotifyPowerState(powerstate);
ReserveDevice();
GetDeviceReservationStatus();
NotifyDeviceReservationStatus();
VendorDependentCommand(command parameters);//pass thru a vendor-specific command in the native protocol（ネイティブプロトコルにおけるベンダ固有のコマンドを送る）。
【０１４９】
機能制御モジュール（ＦＣＭ）メッセージ
機能固有メッセージは、機器内のＶＴＲ機能のＰＬＡＹ、ＳＴＯＰ、ＲＥＷＩＮＤ等の一般的なネイティブコマンドに対応する。これらのメッセージを機器内の明確に定義された位置に宛てる必要があるので、ＦＣＭ（機能制御モジュール）を使用して、これらのメッセージのターゲットを表す。ＤＣＭと同様、ＦＣＭの管理に対応しなければならないメッセージもある。これらのメッセージは、特定ドメインに関わらず、全てのＤＣＭによりサポートされる。これらのメッセージを以下に示す。
GetFunctionType();II ＶＴＲ, tuner, disc, etc.
GetFunctionInfo();//more detailed information about the function, such as the particular kind of disc player (DVD, CD, etc.)（特定種類のディスクプレーヤ（ＤＶＤ、ＣＤ等）等の機能についてのより詳細な情報）
GetNumberOfPlugs(inputPlugs outputPlugs);//returns the number of source and destination plugs for the functional module（機能モジュールのためのソース及びデスティネーションプラグの数をリターン）
GetFunctionStatus();//current status of the functional module, including the status of source and destination plugs (input and output)（ソース及びデスティネーションプラグ（入力及び出力）を含む機能モジュールの現状態）
GetPowerState(powerState);//functional modules may have individually controllable power states（機能モジュールはそれぞれ制御可能なパワー状態を有してもよい）
SetPowerState(powerState);
GetSupportedPowerStates(list);
GetSupportedDataFormats(list);//returns the data formats supported by this functional module（機能モジュールによりサポートされるデータフォーマットをリターン）
NativeCommand(params);//send the functional module a command in its native command protocol（機能モジュールにネイティブプロトコルにおけるコマンドを送る）
機能ドメインメッセージは、機能のタイプ（ＶＴＲ、チューナ等）に基づいている。これらは予想されるような一般的なＰＬＡＹ、ＳＴＯＰ、ＲＥＷＩＮＤコマンドである。
【０１５０】
レベル１相互運用性には、機器対機器と人間対機器の両インタラクションが含まれている。ＰＬＡＹ、ＳＴＯＰ、ＲＥＷＩＮＤ等の機能メッセージセットは、機器対機器のインタラクションに使用される。この具体例として、いかなるタイプのＶＴＲも制御したいビデオ編集ソフトウェアパッケージがある。そのプログラムは、全てのＶＴＲに適用される非常に特定のユーザインタフェース制御セットにより設計されている。ユーザがアプリケーションとインタラクトすると、アプリケーションの方はＰＬＡＹやＳＴＯＰ等のドメイン固有のコマンドを目的の機器に送ってくる。
【０１５１】
ＨＡＶＩアーキテクチャでは、アプリケーションがこれらのメッセージをＤＣＭに送り、ＤＣＭがそれらを目的のＢＡＶ機器のネイティブ言語に変換する。目的の機器がＨＡＶＩメッセージングアーキテクチャをサポートするものである場合、これらのコマンドは変換される必要がない。これらは単にＨＡＶＩメッセージとしてＨＡＶＩターゲットに送られる。
【０１５２】
ビデオカメラは、本質的にＶＴＲと同じである。ビデオカメラのさらなる機能は、ビデオカメラ効果（camcorder effect）、場面転換（transition）等である。これらは以下の通りである。
stop()
play()
rewind()
record()
volume(setvalue)
changeStatus(newMode)//newMode of: VTR, CAMERA, STANDBY
cameraControl(controlType)//controlTYPE defines control Type and subType structures eg zoom, zoomValue, or Effect, transition5 etc.（controlTYPEは、ズーム、ズーム値、効果、場面転換等の制御タイプ及びサブタイプ構造を定義する。）。
【０１５３】
ミニディスクはランダムアクセスストレージのカテゴリーである。これらはＰＬＡＹ、ＦＯＲＷＡＲＤ等を制御する基本コマンドセット及びランダムアクセス媒体に固有のコマンドセットをサポートする。コマンドは以下の通りである。
stop()
play()
rewind()
forward()
record()
volume(setValue)
changeStatus(newMode)//newMode of: STANDBY
seek(track)
seekstart()
seekEnd()
getDiskInfo()
mdControl(controlType)//controlTYPE defines control Type and subType structures eg intro mode, random play.（controlTYPEは、イントロモード、ランダム再生等の制御タイプ及びサブタイプ構造を定義する。）。
【０１５４】
ハードディスクはランダムアクセスストレージのカテゴリーである。これらはＰＬＡＹ、ＦＯＲＷＡＲＤ等を制御する基本コマンドセット及びランダムアクセス媒体に固有のコマンドセットをサポートする。コマンドは以下の通りである。
stop()
play()
rewind()
forward()
record(type)//type structure passes info to allow intelligent devices to optimise storage policy（タイプ構造は、高機能機器がストレージポリシーを最適化することを可能にする情報を送る）
changeStatus(newMode)//newMode of: STANDBY
seek(track)
seek(block)
seekStart()
seekEnd()
HDDControl(controlType)//controlTYPE defines control Type and subType structures eg layout commands for block-structures（controlTYPEは、ブロック構造のためのレイアウトコマンド等の制御タイプ及びサブタイプ構造を定義する）。
【０１５５】
ユーザインタフェースについて、汎用的で単純なＵＩとしてはＦＩＧ．１２Ａに示すようにテキストベースのものであってもよい。ＤＣＭ特殊化に基づく、より複雑なユーザインタフェースとしては、ＦＩＧ．１２Ｂに示すようなものであってもよい。ＳＤＤに保持されるグラフィック情報は、汎用ＤＣＭを特殊化するために使用される。
【０１５６】
したがって、本発明は、ホームネットワークにおいて相互に動作するＣＥ（民生用電子）機器のためのオープンアーキテクチャを定義するホームオーディオビジュアル（ＡＶ）ネットワークを提供する。本発明の相互運用性の特徴は、何れの製造業者のＣＥ機器であっても、ユーザのホームＡＶシステム内でシームレスに相互に動作するとともに、機能するとができるようにするアーキテクチャモデルを定義する。本発明のシステムでは、新たな機能及び新たなＣＥ機器がホームＡＶネットワーク内に配置されるので、汎用デバイス制御の基本セットと、基本制御プロトコルを拡張する方法とを組み合わせる。この際、本発明のアーキテクチャは拡張可能であり、市場の要求及び技術の変化に伴い、容易に変更及び発展することができる。
【０１５７】
上述の本発明の実施例は例示及び説明を目的とするものである。これら実施例は、本発明を開示された形式通りに限定するものではなく、上述の教示を考慮して種々の変更が可能である。実施例については、本発明の原理及びその実施形態を最適に説明することにより、他の当業者が本発明及び特定用途に合うように種々の変更を加えた種々の実施例を用いることができるようにするために、選択及び説明を行った。本発明の範囲は、特許請求の範囲及びそれに相当するものにより定義されるものとする。
【図面の簡単な説明】
【図１】ＦＩＧ．１Ａは、本発明を適用したＨＡＶＩネットワークの具体例を示す図である。
【図２】ＦＩＧ．１Ｂは、ＦＩＧ．１ＡのＨＡＶＩネットワークの論理バス構成を示す図である。
【図３】ＦＩＧ．２は、本発明を適用したピアツーピア２ＩＡＶ（中間オーディオビデオ）ノードネットワークの具体例を示す図である。
【図４】ＦＩＧ．３は、本発明を適用した単一ＦＡＶ（フルオーディオビデオ）クラスタＨＡＶＩネットワークの具体例を示す図である。
【図５】ＦＩＧ．４は、ＩＡＶピアツーピアＨＡＶＩネットワークと統合したＦＡＶクラスタを示す図である。
【図６】ＦＩＧ．５は、多数のＦＡＶを有するＨＡＶＩネットワークの具体例を示す図である。
【図７】ＦＩＧ．６は、本発明を適用したセットトップボックスの具体例を示す図である。
【図８】ＦＩＧ．７は、本発明を適用したＨＡＶＩアーキテクチャの具体的な論理ブロック図である。
【図９】ＦＩＧ．８は、本発明を適用したＨＡＶＩアーキテクチャの具体的なレイヤ論理図である。
【図１０】ＦＩＧ．９は、具体的なＨＡＶＩアーキテクチャにおけるローカル及びリモートメッセージングを示す図である。
【図１１】ＦＩＧ．１０は、具体的なＨＡＶＩアーキテクチャにおける１３９４を介して送られるメッセージを示す図である。
【図１２】ＦＩＧ．１１は、具体的なＨＡＶＩアーキテクチャにおける他のアプリケーションを呼び出すアプリケーションを示す図である。
【図１３】ＦＩＧ．１２Ａは、機器（例えばビデオカメラ）のためのＵＩ表示（例えばテレビジョン受像機の画面）の第１の具体例を示す図である。
【図１４】ＦＩＧ．１２Ｂは、機器（例えばビデオカメラ）のためのＵＩ表示（例えばテレビジョン受像機の画面）の第２の具体例を示す図である。
【図１５】ＦＩＧ．１３は、本発明を適用した各機器に記憶されたＳＤＤ情報を用いて、ＨＡＶＩネットワークにおける複数の機器のシームレスな相互運用性及び統合を与える処理を示すフローチャートである。
【図１６】ＦＩＧ．１４は、本発明を適用したＨＡＶＩネットワークにおける複数の機器間の基本コマンド機能及び拡張コマンド機能を与える処理を示すフローチャートである。
【図１７】ＦＩＧ．１５は、本発明を適用したＨＡＶＩネットワークにおける機器の将来的なアップグレード性及び拡張性を確保する処理を示すフローチャートである。
【図１８】ＦＩＧ．１６は、本発明を適用したＨＡＶＩネットワークにおける従来の機器とＨＡＶＩ準拠機器とのシームレスな相互運用性及び統合を与える処理を示すフローチャートである。
【図１９】ＦＩＧ．１７Ａは、本発明を適用した外部サービスプロバイダからのアプリケーションプログラムを用いて、ホームオーディオ／ビデオネットワークにおける機器を制御する処理を示すフローチャートである。
【図２０】ＦＩＧ．１７Ｂは、ＦＩＧ．１７Ａの処理プロセスに基づいたサービスプロバイダを有するＨＡＶＩネットワークを示す図である。

Claims

ホームオーディオ／ビデオネットワークに接続された第１及び第２の機器をアップグレード及び拡張する機器拡張方法において、
上記第１の機器を制御するためのデフォルト制御モジュールを準備するステップであって、上記デフォルト制御モジュールは、上記第１の機器と上記第２の機器との間で所定の最低限の相互運用性を提供するように構成され、上記第２の機器上で提供される、上記デフォルト制御モジュールを準備するステップと、
上記第２の機器を介して上記ホームオーディオ／ビデオネットワーク上の第３の機器によって上記第１の機器の機能にアクセスするステップであって、上記第２の機器から上記第１の機器に送られたデフォルトコマンドセットを用いることを含み、上記デフォルト制御モジュールは上記デフォルトコマンドセットを備える、上記第１の機器の機能にアクセスするステップと、
上記第２の機器において、上記第１の機器を制御するための更新制御モジュールを受信するステップと、
上記第２の機器において、上記デフォルト制御モジュールのリンクを外すとともに、上記更新制御モジュールをリンクすることにより、上記デフォルト制御モジュールを上記更新制御モジュールで置換するステップと、
上記更新制御モジュールを使用する上記第２の機器を介して上記ホームオーディオ／ビデオネットワーク上の上記第３の機器を用いて上記第１の機器にアクセスするステップであって、上記第２の機器から上記第１の機器に送られた更新コマンドセットを用いることを含み、上記更新制御モジュールは上記更新コマンドセットを備える、上記第１機器にアクセスするステップとを有する機器拡張方法。
上記デフォルト制御モジュールを準備するステップ及びデフォルト制御モジュールを置換するステップは、上記第２の機器に設けられたデバイスマネージャによって行われることを特徴とする請求項１記載の機器拡張方法。
上記デフォルト制御モジュールと上記更新制御モジュールの両方は、上記第２の機器による上記第１の機器の制御を可能にする該第１の機器用の制御インタフェースセットを提供することを特徴とする請求項１記載の機器拡張方法。
ネットワークにおける機器を拡張する機器拡張方法において、
上記ネットワークに接続された第１の機器を制御するためのデフォルト制御モジュールを準備するステップであって、上記デフォルト制御モジュールは、上記第１の機器と上記ネットワークに接続されている他の複数の機器との間で所定の最低限の相互運用性を提供するように構成され、第２の機器上で提供される、上記デフォルト制御モジュールを準備するステップと、
上記第２の機器を介して上記ネットワークに接続された第３の機器によって上記第１の機器の機能にアクセスするステップであって、上記第２の機器から上記第１の機器に送られるデフォルトコマンドセットを用いることを含み、上記デフォルト制御モジュールは上記デフォルトコマンドセットを備える、上記第１の機器の機能にアクセスするステップと、
上記第２の機器において、上記第１の機器を制御するための更新制御モジュールを受信するステップと、
上記第２の機器において、上記デフォルト制御モジュールのリンクを外すとともに、上記更新制御モジュールをリンクすることにより、上記デフォルト制御モジュールを上記更新制御モジュールで置換するステップと、
上記更新制御モジュールを使用する上記第２の機器を介して上記ネットワーク上の上記第３の機器を用いて上記第１の機器の機能にアクセスするステップであって、上記第２の機器から上記第１の機器に送られる更新コマンドセットを用いることを含み、上記更新制御モジュールは上記更新コマンドセットを備える、上記第１の機器の機能にアクセスするステップとを有する機器拡張方法。
上記接続された機器は、コンピュータで読取り可能なメモリに接続されたプロセッサを有するホストデバイスであり、該メモリは、該プロセッサにおいて実行されたときに上記他の複数の機器をアップグレード及び拡張する処理を実行するコンピュータで読取り可能なインストラクションを格納していることを特徴とする請求項４記載の機器拡張方法。
上記ホストデバイスにおいて、外部ソースから更新制御モジュールを受信するステップをさらに有する請求項５記載の機器拡張方法。
上記準備するステップ、受信するステップ及び置換するステップは、上記ホストデバイス上で実行されるデバイスマネージャによって行われることを特徴とする請求項５記載の機器拡張方法。
上記更新制御モジュールが自動的にレジストリを介してその存在を上記デバイスマネージャに通知するステップをさらに有する請求項７記載の機器拡張方法。
上記デフォルト制御モジュールと上記更新制御モジュールの両方は、上記他の複数の機器の１つによる上記接続された機器の制御を可能にする該機器用の制御インタフェースセットを提供することを特徴とする請求項４又は５記載の機器拡張方法。
ホームオーディオ／ビデオネットワークのバスに接続された複数の機器を含むシステムにより実行され、
上記複数の機器のうちの１つがコンピュータで読取り可能なメモリに接続されたプロセッサを有するホストデバイスであり、該メモリは、該プロセッサにおいて実行されたときに該複数の機器を拡張する処理を実行するコンピュータで読取り可能なインストラクションを格納しており、
上記デフォルト制御モジュールのリンクを外すとともに更新制御モジュールをリンクすることにより、デフォルト制御モジュールを更新制御モジュールで置換するステップは、レジストリを用いて行われることを特徴とする請求項４記載の機器拡張方法。
上記置換するステップは、上記ホームオーディオ／ビデオネットワークの複数の機器から上記更新制御モジュールによって受信されるコマンドによって、上記第１の機器が制御できるように、行われることを特徴とする請求項１又は５記載の機器拡張方法。
ホームオーディオ／ビデオネットワークに接続された第１及び第２の機器をアップグレード及び拡張する機器拡張方法において、
上記第１の機器を制御するためのデフォルト制御ソフトウェアモジュールを準備するステップであって、上記デフォルト制御ソフトウェアモジュールは、上記第１の機器と上記第２の機器との間で汎用レベルの通信を提供するように構成され、上記第２の機器上で提供される、上記デフォルト制御ソフトウェアモジュールを準備するステップと、
上記第２の機器を介して上記ホームオーディオ／ビデオネットワーク上の第３の機器によって上記第１の機器の機能にアクセスするステップであって、上記第２の機器から上記第１の機器に送られたデフォルトコマンドセットを用いることを含み、上記デフォルト制御ソフトウェアモジュールは上記デフォルトコマンドセットを備える、上記第１の機器の機能にアクセスするステップと、
上記第２の機器において、上記第１の機器を制御するための更新制御ソフトウェアモジュールを受信するステップと、
上記第２の機器において、上記デフォルト制御ソフトウェアモジュールのリンクを外すとともに、上記更新制御ソフトウェアモジュールをリンクすることにより、上記デフォルト制御ソフトウェアモジュールを上記更新制御ソフトウェアモジュールで置換して、上記ホームオーディオ／ビデオネットワークの複数の機器から上記更新制御ソフトウェアモジュールによって受信されるコマンドによって、上記第１の機器を制御できるようにするステップと、
上記更新制御ソフトウェアモジュールを使用する上記第２の機器を介して上記ホームオーディオ／ビデオネットワーク上の上記第３の機器を用いて上記第１の機器の機能にアクセスするステップであって、上記第２の機器から上記第１の機器に送られた更新コマンドセットを用いることを含み、上記更新制御ソフトウェアモジュールは上記更新コマンドセットを備える、上記第１の機器の機能にアクセスするステップとを有する機器拡張方法。
上記準備するステップ、上記受信するステップ及び上記置換するステップは、上記第２の機器に設けられたデバイスマネージャによって行われることを特徴とする請求項１２記載の機器拡張方法。
上記第１の機器において、外部ソースから上記更新制御モジュール又は上記更新制御ソフトウェアモジュールを受信するステップをさらに有する請求項２又は１３記載の機器拡張方法。
上記第２の機器において、ユーザが直接操作しなくても、自動的に、上記デフォルト制御モジュールのリンクを動的に外すとともに、上記更新制御モジュールを動的にリンクするステップをさらに有する請求項２、４、５、１０又は１３記載の機器拡張方法。
上記第２の機器において、上記更新制御モジュール及び機器の機能を拡張するために、上記複数の制御モジュールの更新をある期間に亘って自動的に行うステップをさらに有する請求項４、５又は１５記載の機器拡張方法。
上記ホームオーディオ／ビデオネットワークのバスは、ＩＥＥＥ１３９４規格のバスであり、上記デフォルト制御モジュール及び上記更新制御モジュールは、該ＩＥＥＥ１３９４により又はＩＥＥＥ１３９４プロトコルに従って機能するように構成されていることを特徴とする請求項４、５又は１５記載の機器拡張方法。
上記デフォルト制御モジュールは、レベル１制御モジュールであり、上記更新制御モジュールは、該レベル１制御モジュールに対して向上した機能を有するレベル２制御モジュールであることを特徴とする請求項１５記載の機器拡張方法。
上記更新制御モジュールは、その存在をレジストリを介して上記第２の機器に自動的に通知するステップをさらに有する請求項２又は１３記載の機器拡張方法。
上記更新制御モジュール及び上記第１の機器の機能を拡張するために、上記第２の機器において、上記複数の制御モジュールの更新をある期間に自動的に行うステップをさらに有する請求項２又は１３記載の機器拡張方法。
上記ホームオーディオ／ビデオネットワークは、ＩＥＥＥ１３９４規格の通信バスを有し、上記デフォルト制御モジュール及び上記更新制御モジュールは、該ＩＥＥＥ１３９４規格に準拠して機能するように構成されていることを特徴とする請求項１又は１２記載の機器拡張方法。
上記デフォルト制御ソフトウェアモジュールと上記更新制御ソフトウェアモジュールの両方は、上記第２の機器による上記第１の機器のシームレスな相互運用性及び制御を可能にする該第１の機器用の相互運用性、機能性及び制御インタフェースの所定のセットを提供することを特徴とする請求項１２記載の機器拡張方法。
ホームオーディオ／ビデオネットワークに接続された第１及び第２の機器をアップグレード及び拡張する機器拡張システムにおいて、
上記第１の機器を制御するためのデフォルト制御モジュールであって、上記第１の機器と上記第２の機器との間で所定の最低限の相互運用性を提供ように構成され、上記第２の機器上で提供される上記デフォルト制御モジュールを備えており、
上記第２の機器は、上記ホームオーディオ／ビデオネットワークに接続された第３の機器によって上記第１の機器の機能にアクセス可能とするように構成され、該アクセスは、上記第２の機器から上記第１の機器に送られたデフォルトコマンドセットを用いることを含み、上記デフォルト制御モジュールは上記デフォルトコマンドセットを備え、
上記第２の機器は、上記第１の機器を制御するための更新制御モジュールを受信すると、上記デフォルト制御モジュールのリンクを外すとともに、上記更新制御モジュールをリンクすることにより、上記第１の機器の上記デフォルト制御モジュールを上記更新制御モジュールに置換するよう構成されている、
さらに、上記第１の機器の機能は、上記更新制御モジュールを使用する上記第２の機器を介して上記ホームオーディオ／ビデオネットワークに接続された上記第３の機器によってアクセスされ、該アクセスは、上記第２の機器から上記第１の機器に送られる更新コマンドセットを用いることを含み、上記更新制御モジュールは上記更新コマンドセットを備えることを特徴とする機器拡張システム。