JP2002501238A

JP2002501238A - オーディオ／ビデオネットワークに関する方法及びシステム

Info

Publication number: JP2002501238A
Application number: JP2000528021A
Authority: JP
Inventors: リー、ロジャー、ジェイ
Original assignee: ソニーエレクトロニクスインク
Priority date: 1998-01-06
Filing date: 1998-12-24
Publication date: 2002-01-15
Also published as: WO1999035753A9; AU2097599A; ATE290281T1; WO1999035753A2; DE69829219T2; KR20010033879A; EP1046259B1; WO1999035753A3; DE69829219D1; EP1046259A2

Abstract

(57)【要約】ホームオーディオ／ビデオネットワークにおける機器を制御するアプリケーションをダウンロードするための方法及びシステム。例えば、テレビジョン、ＶＣＲ、チューナ、セットトップボックス（例えば、インテリジェントレシーバ／デコーダ、ＩＲＤ）、ＤＶＴＲ、ＰＣ、ＤＶＤプレーヤ（デジタルビデオディスク）等、幾つかの民生用電子製品は、標準バス（例えば、ＩＥＥＥ１３９４シリアル通信バス）を介して互いに通信を行うようにネットワーク内で接続することができる。一実施例において、ＨＡＶＩネットワークは、その構造が既存のコンピュータシステムネットワークの利点の多くをホームネットワークに与えるので、民生用電子製品ベンダに独自の利点を与える。すなわち、相互接続された機器は、リソースを共有することができる共に、第三者のディベロッパーにとって容易な開発を可能にするオープンで明確なＡＰＩを供給することができる。機器は、ＤＣＭと呼ばれる機器又はサービスのソフトウェアアブストラクトを用いて制御される。本発明は、例えば、プログラム可能なインテリジェントデバイス（例えば、セットトップボックス）を介してアプリケーションをダウンロードすることができると共にアプリケーションがネットワーク内で特徴及びサービスを提供するメカニズムを提供する。これらのアプリケーションは、サービスプロバイダから得られ、論理チャネル（例えば、インターネット／ＴＶケーブル、衛星放送）を介して民生用機器に転送され、ネットワーク内のインテリジェントデバイスに設けられる。アプリケーションは、ＤＣＭのレジストリに質問を行って、その機能を判定することができると共に、使用可能なＤＣＭを用いてネットワークの機器を最終的に制御することができる。

Description

【発明の詳細な説明】

【０００１】発明の分野本発明は通信システムの分野に関する。特に、本発明は家庭用オーディオ／ビ
デオ電子機器のための機器に関する。本発明の一実施例は、ホームオーディオ／
ビデオネットワークにおける機器を制御するためのアプリケーションをダウンロ
ードする方法及びシステムである。

【０００２】発明の背景一般的な家庭用オーディオビジュアル機器のセット（home audiovisual equip
ment set up）には多数のコンポーネント（component）が含まれている。例えば
、ラジオ受信機、ＣＤプレーヤ、スピーカ、テレビジョン受像機、ＶＴＲ、テー
プデッキ等がある。これらの各コンポーネントは、一組の接続線（wire）を介し
て互いに接続されている。通常、あるコンポーネントが家庭用オーディオビジュ
アルシステムの中心コンポーネントとなる。これは通常、ラジオ受信機又はチュ
ーナである。チューナは、他のコンポーネントを接続するための多数の特別な入
力（specific input）を備えている。また、チューナは、これらのコンポーネン
トを限定的（limited degree）に制御（controllability）し、また相互運用（i
nteroperability、インタオペラビリティ）させるための、対応した数の制御ボタン又は制御スイッチを備えている。制御ボタン及び制御スイッチは、通常、チ
ューナの前面に配設されている。多くの場合、これらのボタン及びスイッチの幾
つか又は全ては、携帯遠隔制御装置（hand held remote control unit）にも設けられている。ユーザは、チューナの前面のボタン及びスイッチを操作して、あ
るいは携帯遠隔制御装置のボタンを操作して、家庭用オーディオビジュアルシス
テムを制御する。

【０００３】民生用電子機器がより高性能で複雑になるにつれて、最新の、より高性能の機
器が求められる。新たな機器が現れて普及すると、消費者がその機器を購入し、
家庭用オーディオビジュアルシステムに接続する。その新たな機器は既存の古い
機器（例えば、カセットテープデッキ、ＣＤプレーヤ等）と共にシステムに接続
されるだけである。新たな機器は、チューナの裏側の空いている入力、又は、チ
ューナに接続された他の機器に接続される。消費者（例えば、ユーザ）は、新た
な機器自体のコントロールスイッチを介して、あるいは、新たな機器のための別
個のリモートコントロールユニットを介して、その新たな機器を制御する。

【０００４】家庭用オーディオビジュアルシステムのための多数の新たな家庭用電子機器が
開発され、これらの機器がますます複雑で高性能になるのに伴い、従来のパラダ
イムに関して多くの問題が生じている。このような問題の一つは、家庭用オーデ
ィオビジュアルシステムにおける機器間の互換性のなさである。また、ある機器
が他の機器よりも新しい場合、さらに互換性がなくなることがある。例えば、あ
る新しい機器が、より複雑なリモートコントロール機能を可能にするハードウェ
ア（例えば、特定入力及び出力）を組み込んでいる。このハードウェアは、シス
テム内の古い機器には使用できないことがある。もう一つの問題は、オーディオ
ビジュアルシステム内の種々の機器に対する機能的サポートがないことである。
例えば、テレビジョンは高度な音声フォーマット（例えば、サラウンド音声、ス
テレオ等）をサポートするかもしれないが、古くて性能の低いチューナがこのよ
うな機能をサポートしない場合、高度な音声フォーマットの利点が失われること
がある。もう一つの問題は、家庭用オーディオビジュアルシステムにおける新た
な機器及び種々の機器のためのコントロールの拡散である。オーディオビジュア
ルシステムに接続された新たな機器は、それぞれ、専用のリモートコントロール
ユニットを伴うことが多く、ユーザはそれに従って操作方法を学ばなければなら
ない。

【０００５】従来のオーディオビジュアルシステムは、セットトップボックスを備えること
もできる。従来技術のセットトップボックスは、一般にサービスプロバイダから
テレビジョンにオーディオ／ビデオ信号を供給するのに使用されるインテリジェ
ントレシーバ（デコーダ）である。セットトップボックスは、一般に多数のデス
クランブル又はデコード機能を行う。非常に単純な特徴やサービスを消費者に提
供するためにセットトップボックス内で実行される非常に基本的なコマンドを、
サービスプロバイダからダウンロードすることが可能である。この一般的なアプ
リケーションとしては、要求された場合にビデオニュースクリップにかぶせるこ
とができるエキストラのテキスト及び／又はグラフィック情報により、テレビジ
ョンに表示されるビデオニュースクリップを向上させるコマンドセットがある。
また、消費者が単純なインジケータを用いて商品サービスの選択及び購入を行う
ことを可能にするホームショッピングサービスも利用可能である。しかし、これ
らのアプリケーションは、単に、セットトップボックスに直接接続されたテレビ
ジョン（又はデータ入力機器）に存在して、インタラクションを行うのであり、
家庭用オーディオビジュアルシステムの他の機器の制御を可能にするものではな
い。

【０００６】発明の概要従って、本発明は、家庭用システムの家庭用オーディオビジュアル電子製品に
おいてインタオペラビリティの改善を可能にするシステムを提供する。また、本
発明は、セットトップボックスアプリケーションのための拡張機能を可能にする
家庭用オーディオビジュアルネットワークにおけるシステム及び方法を提供する
。具体的には、本発明は、ホームオーディオ／ビデオネットワークの機器が、サ
ービスプロバイダから得られる１以上のダウンロードされたアプリケーションプ
ログラムにより制御されるのを可能にする方法及びシステムを提供する。

【０００７】ホームオーディオ／ビデオネットワークにおける機器を制御するアプリケーシ
ョンをダウンロードするための方法及びシステムが記載される。例えば、テレビ
ジョン、ＶＣＲ、チューナ、セットトップボックス（例えば、インテリジェント
レシーバ／デコーダ、ＩＲＤ）、ＤＶＴＲ、ＰＣ、ＤＶＤ（デジタルビデオディ
スク）プレーヤ等、幾つかの民生用電子製品は、標準バス（例えば、ＩＥＥＥ１
３９４シリアル通信バス）を介して互いに通信を行うようにネットワーク内で接
続することができる。これにより、ネットワークの機器は互いに制御することが
でき、互いの情報を得ることができる。一実施例において、使用される通信構造
は家庭用オーディオ／ビジュアルイニシアチブ（ＨＡＶＩ）フォーマットである
。ＨＡＶＩネットワークは、その構造が既存のコンピュータシステムネットワー
クの利点の多くをホームネットワークに与えるので、独自の利点を与える。すな
わち、相互接続された機器は、リソースを共有することができる共に、第三者の
ディベロッパーにとって容易な開発を可能にするオープンで明確なＡＰＩを供給
することができる。ＨＡＶＩは拡張インタオペラビリティを与える。

【０００８】家庭の使用環境では、民生用電子機器の１つの要件として、消費者による機器
のセットアップの容易性が挙げられる。これには、消費者が機器をホームネット
ワークに接続し、新たな機器のアクセス及び使用を確保するようにホームネット
ワークと機器の自動的な構成を可能にすることが必要である。これを確実にする
ため、本発明は、いかなる新たな機器に対しても質問が可能となる家庭使用環境
ソフトウェア構造を有する。そして、その機器用のソフトウェアアブストラクト
が作成され、ネットワークにおける他の構成要素に利用可能となる。システムの
寿命の間、他の機器にとって能力や特徴が未知の、あるいは、部分的にしかわか
らない、新たな機器が追加されることが考えられるので、本発明は、ある基本レ
ベルで全ての機器の通信及び制御が可能になることを保証するメカニズムを提供
する。その後、可能であれば、例えば、機器についてより多くの情報が得られる
場合、本発明によって新たな機器のより良好なアブストラクトが作成される。

【０００９】ＤＣＭ（デバイスコントロールモジュール）は、ホームオーディオ／ビデオネ
ットワークにおける機器を制御するため、本発明により使用されるソフトウェア
アブストラクトである。ＤＣＭは機器又はサービスのソフトウェアアブストラク
トであり、その機器に対するインターフェースを供給する。ＤＣＭは、ホームオ
ーディオ／ビデオネットワークのインテリジェントノードにより保持される。
セットトップボックス（インテリジェントレシーバ／デコーダ）やデジタルテレ
ビジョン等、幾つかの機器は、他の機器と通信を行うホームネットワークにおけ
る機器として、また、家庭外の外部サービスプロバイダ（例えば、インターネッ
ト、デジタルＴＶプロバイダ、ケーブルプロバイダ等）へのゲートウェイとして
動作する。

【００１０】本発明のセットトップボックスでは、このセットトップボックスで動作する、
サービスプロバイダからの１以上のアプリケーションプログラムをダウンロード
することが可能である。アプリケーションプログラムは、一般に、ホームネット
ワークに幾つかの特徴又はサービスを提供するものである。本発明のホームネッ
トワークにおける機器として、セットトップボックスはホームネットワークにお
ける他の機器へのアクセスを有する。従って、本発明により、サービスプロバイ
ダ（例えば、ケーブルテレビジョンプロバイダ、インターネットウェブサイト、
電話等の地上ラインユーティリティ、衛星放送サービス等）から家庭用機器に伝
送され、セットトップボックスに設けられるダウンロード可能なアプリケーショ
ンの作成が可能になる。この場合、アプリケーションプログラムはホームネット
ワーク内でインタラクトすることができる。

【００１１】この機能を容易化することで、本発明は、ネットワークに存在するサービスや
機器を使用可能にする一般的方法を提供する。本発明は、ホームネットワークに
おける機器のＤＣＭをレジストリ又はネームサーバに登録する。本発明のホーム
ネットワークは、ダウンロードされた新たなアプリケーションがこのレジストリ
に対して質問を行い、ＤＣＭの通信エンドポイントを受け取ることを可能にする
メカニズムを提供する。ダウンロードされたアプリケーションには、ホームネッ
トワークの実際の機器に対するインタラクション及び制御に使用されるＤＣＭに
要求を送るメカニズムが設けられる。

【００１２】発明の詳細な説明本発明の実施例について、添付の図面を参照して詳細に説明する。本発明を好
ましい実施例を用いて説明するが、本発明はこれらの実施例に限定されるもので
はない。むしろ、本発明は、添付の請求の範囲により定義される発明の範囲内で
ある代替手段、変更、相当手段を含むものとする。さらに、以下の本発明の詳細
な説明では、本発明の完全に理解できるように多数の具体的詳細事項を記載する
。しかし、本発明をこれらの具体的詳細事項を用いずに実施することができるこ
とは、当該分野の通常の技術者にとって明らかであろう。また、本発明の特徴を
不必要に曖昧にしないために、既知の方法、手続、コンポーネント、回路につい
ては詳細な説明を省略する。

【００１３】本発明は、ホームネットワークにおけるインタオペレーションを行うＣＥ機器
のためのオープンアーキテクチャを定義するホームＡＶネットワークを提供する
。本発明のインタオペラビリティは、いずれのメーカのＣＥ機器であっても、ユ
ーザの家庭用ＡＶシステムにおいてインタオペレーションを行いシームレスに機
能することができるようにするアーキテクチャモデルを定義する。本発明のシス
テムでは、新たな特徴及び新たなＣＥ機器がホームＡＶネットワークに展開され
た際に、汎用デバイス制御の基本セットと、基本制御プロトコルを拡張する方法
とを組み合わせる。この際、本発明のアーキテクチャは、拡張可能であり、市場
のニーズと技術の変化に伴って容易に変更や改良を行うことができる。本発明及
びその利点について以下に詳細に説明する。

【００１４】表記及び術語以下の詳細な説明のうちの幾つかの部分は、コンピュータメモリ内のデータビ
ットに対する手続（procedure）、ステップ（step）、論理ブロック（logic blo
ck）、処理（processing）、その他の動作の記号的表記（symbolic representat
ion）として表される（ＦＩＧ．２参照）。これらの説明及び表記は、データ処理技術分野の技術者が当該分野の他の技術者に技術内容を最も効率的に伝達する
のに用いる手法である。手続、コンピュータにより実行されるステップ、論理ブ
ロック、処理等は、ここでも一般的にも、所望の結果を導く一貫したステップ又
はインストラクションのシーケンスであると考えられる。これらのステップは、
物理量の物理的操作を必要とするステップである。通常、必ずしもそうではない
が、これらの物理量は、コンピュータシステムにおいて記憶、転送、組合せ、比
較、その他の操作を行うことができる電気又は磁気信号の形態を有する。場合に
よっては、主として共通した使用のため、これらの信号をビット（bit）、値（v
alue）、エレメント（element）、記号（symbol）、文字（character）、用語（
term）、数字（number）等として表すことが好都合である。

【００１５】なお、これらの用語及び同様の用語はすべて、適切な物理量に関連するもので
あり、単に、これらの物理量に付された便宜的なラベルにすぎない。以下の説明
から明らかなように具体的に記述がない限り、本発明では、「処理（processing
）」、「演算（computing）」、「変換（translating）」、「具現化（instanti
ating）」、「判定（determining）」、「表示（display）」、「認識（recogni
zing）」等の用語を用いた説明は、コンピュータシステム又は同様の電子計算装
置の動作やプロセスについてであり、このようなコンピュータシステムは、その
コンピュータシステムのレジスタ又はメモリ内に物理（電子）量として表される
データを操作して、同様にコンピュータシステムのレジスタ又はメモリ、あるい
は他の情報記憶装置、伝送装置又は表示装置内に物理量として表される他のデー
タに変換する。

【００１６】アーキテクチャの概要本発明のアーキテクチャは、ホームＡＶネットワークにおける新たな機器のシ
ームレスなサポート及び機器の問題のないインタオペラビリティが得られる家庭
用ＡＶシステムを構築することができるようにするものである。本発明に係るシ
ステムの最も基本的なコンポーネントは、家庭用ＡＶインタオペラビリティアー
キテクチャと、一連の家庭用ＡＶインタオペラビリティインターフェースと、ホ
ームＡＶネットワークとである。家庭用ＡＶインタオペラビリティアーキテクチ
ャは、物理的ネットワークと制御プログラミングインターフェースとを含む広い
用語である。インタオペラビリティインターフェースは、ＡＶアーキテクチャの
コンポーネントのインタラクション及びインターフェースを記述するのに使用さ
れる用語である。インタオペラビリティインターフェースは、共通コマンドセッ
トを提供するのに加えて、新たな機器をネットワークに統合することができるよ
うにするソフトウェアアーキテクチャを提供するとともに、そのサービスをシー
ムレスに提供する。ホームＡＶネットワークは、物理的ネットワークとそのトポ
ロジー（topology）を記述するのに用いられる用語である。

【００１７】なお、本発明の家庭用ＡＶインタオペラビリティ（ＨＡＶＩ）アーキテクチャ
は、オープンで、民生用電子機器のメーカがインタオペラブルな機器を提供でき
るようにする、プラットホームに無関係（platform-independent）の、アーキテ
クチャ上中立（architecturally-neutral）であるネットワークである。これは、異なるハードウェア／ソフトウェアプラットホーム上で実現することができ、
いずれかのプラットホームに特有である特徴を全く有していない。ＨＡＶＩアー
キテクチャのインタオペラビリティインターフェースは、拡張可能であり、市場
のニーズと技術の変化に伴って追加、変更、改良を行うことができる。これらは
、等時性の及び時間的に厳密な（isochronous and time-sensitive）データ（例
えばオーディオ及びビデオコンテンツ）のルーティングや処理を制御する基礎構
造（infrastructure）を提供する。

【００１８】具体的には、ＨＡＶＩアーキテクチャは、機器（appliance）の視覚的表示（v
isual representation）及び制御をサポートする実行環境（execution environm
ent）と、アプリケーション及びシステムサービスと、プラグアンドプレイ（plu
g and play）を介して又は他の方法で動的に環境を拡張するための通信メカニズ
ム（communication mechanism）を提供する。

【００１９】なお、ＨＡＶＩアーキテクチャは、従来の機器（例えば既存のものでユーザに
とって利用可能な機器）をサポートする。よりインテリジェント（intelligent ）なネットワーク機器への移行速度が緩やかになりつつあるので、これは重要な
ことである。殆どのメーカは、突然「インテリジェントな」機器のみを生産する
わけではなく、また、消費者も、既存の機器の全てを急に交換し始めるわけでも
ない。

【００２０】本発明では、従来の機器には２つのクラスある。第１のクラスは、「一方向（
one-way）」、すなわち未応答制御機器（unacknowledged control appliance）からなる。第２のクラスは、制御可能な「両方向（two-way）」機器からなる。一方向機器の具体例としては、携帯遠隔制御装置の赤外線コマンドにより制御さ
れるオーディオ／ビデオコンポーネントがある。両方向機器は、コマンドの実行
確認、状態及びエラー報告を行う。両方向機器の具体例としては、既知のＩＥＥ
Ｅ１３９４により可能とされ、最近導入されたデジタルカメラがある。

【００２１】なお、本発明のホームＡＶネットワーク（以下、ＨＡＶＩネットワークともい
う。）は、ライトワンス型でいずれの機器でも動作する共通言語（common langu
age）を介して、将来的な機器やプロトコルを受け入れるためのサポートを行う。本発明では、各機器は、ユーザインターフェース、及び外部コントローラによ
り使用することができるデバイス制御に関する自己記述情報（self-describing
information）を内部に備えている。この情報は共通言語のプログラムとして記述される。

【００２２】以下に説明するが、このようなネットワークの基礎構造（underlying structu
re）は、機器の相互接続されたクラスタ（cluster）のセットからなる。典型的には、家庭には幾つかのクラスタがあり、各階又は各部屋毎に１つクラスタがあ
る。各クラスタは、サービスのセットをユーザに提供するための相互接続された
機器のセットとして動作する。ある１つの機器が他の機器のセットのコントロー
ラとして動作することが多い。しかし、このアーキテクチャは、非常に柔軟性が
あり、家庭にマスタコントローラを持たない単一クラスタがあるようにすること
もできる。

【００２３】例えば、本発明の一実施例では、ユーザの家庭の居間におけるインテリジェン
トテレビジョン受像機が、多数の相互接続された機器のためのコントローラとし
て機能する。制御される各機器は、自己記述データ（self describing data）を
有し、幾つかの関連する制御コードを有することもある。これらの機器が最初に
接続されると、コントローラはユーザインターフェースと機器のための制御プロ
グラムとを得る。そして、機器を示すアイコンがテレビジョン受像機の画面に表
示され、アイコンを操作することにより、制御プログラムの要素が表示された機
器を規定された方法で作動させる。このモデルの例外は、自己記述データも制御
コードも有さない従来の機器である。自己記述データに関する説明や関連技術に
ついては、１９９７年７月３１日出願、出願番号６０／０５４，３２７の「機器
内に自己記述情報を含む方法及び機器（Ludtke, et al., A METHOD AND APPARAT
US 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）、ＥＨＳＩ、ＶＥＳＡ、ホームネットワーク（Ho
me Network）、ＤＡＶＩＣ、ＣｏＭＭｅＮＤ、Ｌｏｎｗｏｒｋｓ、ＵＳＢ、ＩＥ
ＥＥ１３９４等の幾つかの既存のよく知られた工業規格や技術に対して相補的で
ある。したがって、本発明の目的の一つは、既存の機器が当てはまる基礎構造を
提供することである。

【００２８】ＨＡＶＩアーキテクチャのシステムモデルＦＩＧ．１Ａを参照して、本発明を適用したＨＡＶＩネットワーク１０ａを説
明する。上述のように、ＨＡＶＩアーキテクチャは、共通のメッセージングシス
テム（common messaging system）を介して通信を行う、例えば、セットトップボックス（set top box）３０１等のインテリジェントレシーバ／デコーダ（ＩＲＤ）、デジタルビデオテープレコーダ（ＤＶＴＲ）、ビデオテープレコーダ（
ＶＴＲ）、パーソナルコンピュータ（ＰＣ）、デジタルビデオディスクプレーヤ
（ＤＶＤ）等を含む広範囲の機器をサポートする。ＦＩＧ．１Ａは、ＨＡＶＩネ
ットワークの物理的なポート同士の接続構成１０ａを示す図である。ＣＥ機器（
「機器」）１２〜２４は、バスセグメント（bus segment）３０ａ〜３０ｆにより互いに接続されているように図示してある。ＨＡＶＩの具体例では、共通のメ
ッセージングシステムを提供するプラットホームとして、ＩＥＥＥ１３９４シリ
アル通信バス規格を使用している。

【００２９】ＦＩＧ．１Ｂは、ＦＩＧ．１ＡのＨＡＶＩネットワークの論理バス構成１０ｂ
を示す図である。ＦＩＧ．１Ｂに示すように、ＨＡＶＩネットワークの機器１２
〜２４の全ては、共通のＩＥＥＥ１３９４シリアル通信バス３０に論理的に接続
されているとして示される。このバス構成１０ｂにおいては、ピアツーピア（pe
er 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 IDENTIF
ICATION MECHANISM WITHIN A CONSUMER AUDIO/VIDEO NETWORK）」に記載されており、本明細書ではこれを参照する。

【００３７】ホームネットワークにある機器が初めて加えられると、システムは、その機器
の特徴及び能力を確認するために問合せを行う。機器の特徴がわかると、このア
ーキテクチャは、それを制御するための２つの方法を提供する。第１の方法であ
るレベル１インタオペラビリティは、所定のメッセージセットを使用する。全て
のＩＡＶ及びＦＡＶノードがこのコマンドセットを用いて他の機器にアクセスし
、制御することができる（ＢＡＶノードは、このアーキテクチャが定義される前
に設けられているので、従来のプロトコルを用いて制御される）。これはデフォ
ルトレベルの制御を行う。ＦＡＶノードは、制御ノードとして動作し、機器に制
御コマンドを送るのに使用されるＡＰＩを提供するデバイス制御モジュール（Ｄ
ＣＭ）として知られるＩＡＶノードの局所表現を生成する。

【００３８】ＨＡＶＩ内のレベル２インタオペラビリティは、さらに進んでおり、将来追加
される機能や新たな機器をサポートする。これを達成するために、ある特定の機
器は、ＩＡＶ機器からＦＡＶ機器にアップロードされるオーバライドＤＣＭ（ov
erride DCM）をそのＲＯＭ内に記憶し、このオーバライドＤＣＭによって、特定
の機器のデフォルトＤＣＭは置換される。このオーバライドＤＣＭは、特定の機
器の基本的なレベル１コマンドセットを含むだけでなく、機器の改良された特徴
を制御するためのベンダ固有コマンド（vender specific command）も含んでいる。このモデルにより、機器は、その特別の機能を他の機器に知らせることがで
きる。オーバライドＤＣＭは、どのベンダのＦＡＶにもロードすることができる
ので、ＤＣＭのフォーマットは、アーキテクチャに対して中立的である。

【００３９】ある機器が他の機器の能力を知り、その機器に対してどのコマンドセットを使
用したらよいかを判定するできるようにするため、自己記述データ（self descr
ibing data：ＳＤＤ）と呼ばれる標準機器記述構造（standard device descript
ion structure）が設けられている。ＳＤＤデータ構造は拡張することができる。ＳＤＤデータ構造は、例えばテレビジョン受像機やＶＴＲ等の機器の種類を記
述する少数のバイトである。また、ＳＤＤデータ構造は、オーバライドＤＣＭ及
び機器のグラフィック表現を定義するより複雑な構造であってもよい。ＳＤＤデ
ータ構造におけるグラフィック表現により、ＦＡＶノードは、ユーザに対してホ
ームネットワーク内の各機器を画像表示することができる。グラフィック表現を
汎用的な方法で定義することにより、機器のＳＤＤグラフィックデータは、その
機器のためのユーザインターフェースを表示するどのベンダの製品においても、
使用することができる。これにより、高いレベルのベンダインタオペラビリティ
が得られるとともに、ベンダは、製品を、表示装置の一般的なルックアンドフィ
ール内に保持しながら、区別することができる。これにより、制御機器（ＦＡＶ
ノード）は、種類やベンダの違いに関係なく、ホームネットワーク内の全ての機
器のための一般的な制御ユーザインターフェースを提供することができる。

【００４０】上述のように、従来の機器は、ＨＡＶＩアーキテクチャの前に製造された機器
、あるいはＨＡＶＩを使用しない機器である。ＨＡＶＩは、従来の機器のための
プロトコル変換を行う従来のＤＣＭを設けることにより、従来の機器をサポート
する。これらの従来のＤＣＭは、既存の一方向又は両方向制御プロトコルをサポ
ートするのに十分な知識を有し、ＨＡＶＩに適合した機器に対する特定の制御イ
ンターフェースを提供することができる。従来のＤＣＭは、従来の機器とＨＡＶ
Ｉ機器とのブリッジ（bridge）として動作する。この手法により、ＨＡＶＩは、
例えば家庭のエネルギ管理や安全管理に使用されるプロトコル等のいかなる将来
的なデバイス制御プロトコルに対してもインタラクトすることができる。

【００４１】なお、ＨＡＶＩアーキテクチャにより使用される通信ハードウェア及びプロト
コルは、固有のものではない。ＨＡＶＩアーキテクチャは、幾つかの通信媒体の
うちのいずれかに組み込んで使用することに適しており、その唯一の条件は、そ
の媒体がＨＡＶＩインターフェースをサポートする汎用通信メカニズムを備えて
いることである。想定される基本モデルは、論理通信バックプレーン（例えばＩ
ＥＥＥ１３９４）のモデルである。全てのＡＶ機器は、このバックプレーンに接
続されることが想定され、ＦＩＧ．１Ｂに示すように、他の全てのＡＶ機器の位
置を検出して、通信を行うことができる。物理的設定においては、この論理バッ
クプレーンは２つ以上の物理的通信媒体からなると考えられる。さらに、異なる
物理的媒体上において、多数のプロトコルが使用されることが想定される。家庭
用ＡＶアーキテクチャは、この全てを抽象化し、通信ノードの汎用モデルを提供
する。これは、ネットワークの透過性（transparency）を確実にする（機能的に
はソケット等の）トランスポートレイヤ（transport layer）より上のメカニズムを提供する。このメカニズムは、全てのフラグメンテーション（fragmentatio
n and re-assembly）及び再アセンブリを行う「信頼性のある、順序づけられたデータグラムサービス（reliable, ordered datagram service）」として記述す
ることができる。

【００４２】したがって、本発明の目的は、各物理的バスを同様にサポートして、アプリケ
ーションがどの物理的トランスポートを使用するかを考える必要がないようにす
ることである。しかし、電子業界において、ＩＥＥＥ１３９４はよく知られてい
るので、ＩＥＥＥ１３９４を用いた機能の観点から、本発明の特徴を説明する。
ＣＥＢｕｓやＵＳＢ等の他のバスは、全く同じ特徴を必要とするものではない。

【００４３】ＦＩＧ．２を参照して、本発明を適用したピアツーピアの２ＩＡＶノードＨＡ
ＶＩネットワーク２００を説明する。ＨＡＶＩネットワーク２００は、第２のＩ
ＡＶ２０２（例えば受信機）に接続された第１のＩＡＶ２０１（例えばテレビジ
ョン受像機）を備えている。ＩＡＶ２０１とＩＡＶ２０２は、ピアツーピアで動
作し、互いに必要なリソースを調停する。これらは、ＢＡＶ又はＬＡＶ機器の追
加をサポートするリソースを有していないが、そのコンテキスト内で意味のある
動作を行うことができる。標準ＵＩ性能を得るためにはＩＡＶは必要ではない。
ＡＶアーキテクチャには、「上位コンパチビリティ（forward compatibility）」又は新たな機能を検出のための規定はない（例えば、ＩＡＶ２０１は、ＩＡＶ
２が接続されたときに提供されたＳＤＤに基づいてＩＡＶ２０２がサポートする
機能しか知らない。）。しかし、本発明では、「特別な（ad-hoc）」特徴を検出
するのに、ＳＤＤの特徴を容易に利用することができる。

【００４４】ＦＩＧ．３は、本発明を適用した単一ＦＡＶクラスタのＨＡＶＩネットワーク
３００を示す図である。ＨＡＶＩネットワーク３００は、第１のＬＡＶ３０２（
例えばテレビジョン受像機）、第２のＬＡＶ３０３（例えばＶＴＲ）、ＢＡＶ３
０４（例えばデジタルカメラ）にそれぞれ接続されたＦＡＶ３０１（例えばセッ
トトップボックス）を備えている。ＨＡＶＩネットワーク３００では、ＦＡＶ３
０１が、クラスタに亘るサービスを提供する従来及びベースＡＶ機器（例えば機
器３０２〜３０４）を制御する。

【００４５】ＦＩＧ．４は、ＩＡＶピアツーピアＨＡＶＩネットワーク４００に統合された
ＦＡＶクラスタを示す図である。本発明では、ＨＡＶＩネットワーク４００の構
成により、従来の機器３０２，３０３のためのサポートが得られるとともに、２
つのＩＡＶ機器４０１，４０２のリソースがＦＡＶ機器３０１によって使用され
ていないときに、それらのＩＡＶ機器内で独立制御を可能にする。ＩＡＶ機器４
０１，４０２は、ＦＡＶ機器３０１に対するピアとして動作する。効率上、ＦＡ
ＶからＦＡＶへのリソース要求とＦＡＶからＩＡＶへのリソース要求のいずれに
ついても、リソースコンフリクトポリシー（resource conflict policy）を実行
することができる。ＩＡＶは、ＦＡＶ３０１内で動作するＤＣＭを介してＦＡＶ
により制御される。

【００４６】ＦＩＧ．５は、多数のＦＡＶを有する具体的なＨＡＶＩネットワーク５００を
示す図である。ＨＡＶＩネットワーク５００は、さらにＦＡＶ５０１（例えば衛
星受信機）を備えている。この構成では、上述のＨＡＶＩネットワーク４００と
同様に動作する。この構成では、ＦＡＶ機器３０１，５０１がピアとして動作す
る。

【００４７】コンピュータシステムプラットホームＦＩＧ．６を参照して、本発明を適用したセットトップボックス３０１を説明
する。上述のように、いずれの民生用電子機器もＦＡＶになりうるので、ＨＡＶ
Ｉソフトウェアのためのコンピュータシステムプラットホームが得られる。例え
ば、この具体例のＨＡＶＩネットワークのセットトップボックス３０１の機器は
、以下に説明するＨＡＶＩアーキテクチャのソフトウェアコンポーネントのため
のオペレーションプラットホームを提供する特殊なコンポーネントを有している
。具体的には、本発明の特徴について、コンピュータシステムで実行されるステ
ップを用いて以下に説明する（例えばＦＩＧ．１３〜１７Ａに示すプロセス）。
本発明では種々のコンピュータシステムを使用することができるが、ＦＩＧ．６
のセットトップボックスには、例示的な汎用コンピュータシステムを示す。

【００４８】ＦＩＧ．６のセットトップボックス３０１は、ビデオ／オーディオレシーバ（
デコーダ）ユニット６０６と、ＭＰＥＧユニット６０７を備えるとともに、情報
を通信するアドレス／データバス６００と、バスに接続され、情報及びインスト
ラクションを処理する１つ以上の中央プロセッサ６０１と、バス６００に接続さ
れ、中央プロセッサ６０１の情報及びインストラクションを記憶する揮発性メモ
リ６０２（例えばランダムアクセスメモリ：ＲＡＭ）と、バス６００に接続され
、中央プロセッサ６０１の静的情報及びインストラクションを記憶する不揮発性
メモリ６０３（例えばリードオンリーメモリ：ＲＯＭ）とを備えている。また、
セットトップボックス３０１は、バス６００に接続され、情報及びインストラク
ションを記憶するための磁気又は光ディスク及びディスクドライブ等のデータス
トレージ装置６０４（「ディスクサブシステム」）を追加的に備えることもでき
る。また、セットトップボックス３０１は、ローカルバス３０（例えばＩＥＥＥ
１３９４シリアル通信バス）とインターフェースするバスインターフェースユニ
ット６０８も備える。セットトップボックス３０１は、種々のオペレーティング
システム（例えばウィンドウズオペレーティングシステム、ＤＯＳオペレーティ
ングシステム、マッキントッシュＯ／Ｓ）の下に動作することができるが、この
実施例では、アペリオスオペレーティングシステムを使用する。

【００４９】ＨＡＶＩソフトウェアモデル本発明では、ＨＡＶＩアーキテクチャの演算ユニット（例えばＤＣＭ）は、オ
ブジェクトとしてモデル化されている。各オブジェクトは、自己包含エンティテ
ィ（self contained entity）であり、明確に定義されたインターフェースを介してアクセス可能であり、明確に定義されたソフトウェア実行環境内で実行する
ものである。ソフトウェア実行環境（例えばＦＩＧ．６のセットトップボックス
３０１）も、オブジェクトとしてモデル化され、明確に定義されたインターフェ
ースを介して通信基礎構造を用いてアクセスすることができる明確に定義された
サービス（ローカル又はリモート）のセットを提供する。

【００５０】各オブジェクトは独自にネーミングされる。システムサービスを構築するのに
用いられるオブジェクトと、アプリケーションサービスのために用いられるオブ
ジェクトの区別は行わない。オブジェクトはすべて、レジストリを介して知られ
るようにする。システム内のオブジェクトは、特定のサービス又は機器を見つけ
るためにレジストリに問い合わせることができ、その問合せの結果を用いて、そ
のサービス又は機器にメッセージを送ることができる。オブジェクトに割り当て
られた識別子はオブジェクトを登録するときに生成される。このアイデンティテ
ィは、必要ならば、オブジェクトの寿命の間持続することが保証され、ホームネ
ットワークが完全にリブートした場合でも持続する。

【００５１】本発明では、オブジェクトはメッセージ通知モデルを用いて通信を行う。他の
オブジェクトのサービスを利用したいオブジェクトは、目的のオブジェクトにサ
ービス要求を送る汎用メッセージ通知メカニズムを用いる。目的のオブジェクト
は上述の独自のオブジェクト識別子を用いて特定される。この具体例ではメッセ
ージ通知メカニズムがＩＥＥＥ１３９４を用いて機能するが、１３９４バスによ
りメッセージを送るか制御Ａ１リンクによりメッセージを送るかは区別しない。
同様に、同一ノードにおけるオブジェクトとリモートノードにおけるオブジェク
トの区別は行わない。実際のメッセージ通知基礎構造はシステムやネットワーキ
ング環境によって異なり、ノード毎にもベンダ間でも異なる。しかし、メッセー
ジの実際のフォーマットはインタオペラビリティが確保されるように共通でなけ
ればならない。

【００５２】なお、オブジェクトモデル及びメッセージングシステムの一般的な目的は、種
々のソフトウェアシステム及び言語による多数の実行方法を可能にする十分柔軟
性があり、完全な汎用ソフトウェアモデルを提供することである。メッセージと
これらを取り扱うコードを結びつける際の詳細は、システムインプリメンタによ
り決定される。

【００５３】ソフトウェアアーキテクチャの概要ＨＡＶＩソフトウェアアーキテクチャは、ソフトウェアモデルがＨＡＶＩアー
キテクチャをサポートするのに使用される方法を定義する。特に、これは、ＡＶ
アーキテクチャ内で機器を抽象化して、管理する方法を定義する。また、これは
、インタオペラビリティが確保される方法を定義するとともに、将来的な機器や
サービスをこのアーキテクチャに統合することができる方法を定義する。

【００５４】ソフトウェアマネージャとしてのフルＡＶノード：本発明では、フルＡＶノー
ド（ＦＡＶ）は中間ノード（ＩＡＶ）やベースノード（ＢＡＶ）のマネージャと
して動作し、ＨＡＶＩアーキテクチャをサポートするサービスのためのプラット
ホームを与える。これを達成するため、ＦＡＶは、オブジェクトがサービスや機
器に対する制御及び通信を行うことを可能にする実行環境を与える。機器がホー
ムＡＶネットワーク内でアクセス可能であることを確保するため、ＦＡＶノード
は、ある機器が他の機器に提供するサービスのソフトウェアアブストラクトをサ
ポートする。上述のように、このアブストラクトはデバイス制御モジュール（Ｄ
ＣＭ）と呼ばれる。ＤＣＭはソフトウェアアーキテクチャにおけるオブジェクト
としてモデル化されるが、以下では、区別するために単にＤＣＭと呼ぶことにす
る。ＤＣＭがシステムの他の部分に対して設けるインターフェースにより、その
機器へのアクセス及び制御を行う手段が得られる。一般的な場合、ＦＡＶは、そ
れが管理するホームネットワーク又はＩＡＶネットワークの一部における各ＩＡ
Ｖノード及びベースノード毎に１つのＤＣＭという形で、ＤＣＭのセットを管理
する。したがって、インタオペラビリティの観点から、ＦＡＶノードの主たる役
割は本発明のＤＣＭを管理し、ＤＣＭのための実行環境として動作することであ
る。

【００５５】コントローラ及び表示装置としてのフルＡＶノード：本発明では、多くの場合
、ＦＡＶはＡＶコンテンツやユーザインターフェース（ＵＩ）マテリアルを表示
するために使用する関連した表示装置を有する。しかし、ＨＡＶＩソフトウェア
アーキテクチャはこれに対して命令しないので、ＦＡＶノードは管理されていな
いことになる。この場合、ＦＡＶはコンテンツやＵＩ情報を表示するために他の
ノードと共同して動作する（以下に説明する）。しかし、ＦＡＶ機器は、ホーム
ネットワーク全体のルックアンドフィールを与える高レベルのＵＩＡＰＩをサ
ポートしなければならない。下位レベルのグラフィック操作ＡＰＩは、一般的に
グラフィック表示装置自体に近接して配置され、ＦＡＶの高レベルＡＰＩにより
操作される。

【００５６】フルＡＶノード間のピアツーピアアーキテクチャ：本発明に係るホームＡＶネ
ットワークでは、２つ以上のＦＡＶが存在してもよい。この場合、各ＦＡＶは他
のＦＡＶと共同して、サービスがユーザに提供されることを確実にする。これに
よりＦＡＶノードは共同してリソースを共用することができる。例えば、表示装
置に直接アクセスできないＦＡＶノードが、離れたＦＡＶノードを用いてＤＣＭ
ユーザインターフェースを表示してもよい。また、あるＦＡＶノードが、離れた
ノードに存在するデータ変換モジュールのサービスに対して、２つのＡＶ機器間
のデータルートの設定を可能にするように要求してもよい。

【００５７】レベル１及びレベル２インタオペラビリティ本発明では、本発明のＨＡＶＩアーキテクチャの主たる目的の一つは、機器間
のインタオペラビリティをサポートすることである。これには既存の機器も将来
的な機器も含まれる。インタオペラビリティを達成するため、本発明のＨＡＶＩ
アーキテクチャは２つのレベルのインタオペラビリティを可能にする一般（gene
ral）モデルをサポートする。これらのレベルをレベル１、レベル２と呼ぶ。

【００５８】レベル１インタオペラビリティ：本発明のレベル１インタオペラビリティは、
既存の機器の通信を可能にする一般的なニーズについてである。これを達成する
ため、本発明のレベル１インタオペラビリティは、１つの機器が他の機器に通信
を行うことを可能にする制御メッセージ（コマンド）の汎用セットと、その機器
から正当に予測すべきイベントメッセージのセットを定義し、使用する。このア
プローチをサポートするには、基本的なプロセスセットが必要である。これらの
プロセスには、機器の検出、通信、汎用メッセージセットが含まれる。

【００５９】本発明の機器の検出プロセスは、ホームＡＶネットワークにおける各機器が、
その特徴を他の機器に宣伝することを可能にする明確に定義された方法を必要と
することに対するものである。ここで採用してきたアプローチは、その機器につ
いて情報を有するとともに他の機器によりアクセスでき、全てのＦＡＶ及びＩＡ
Ｖ機器に必要なデータ構造を特定することである。このデータ構造を自己記述デ
ータ構造（ＳＤＤ）と呼ぶ。ＳＤＤは、少なくとも、他の機器がその機器の基本
性能を検出することを可能にするのに十分な情報を有するので、その機器に送る
ことができる基本的なコマンドメッセージのセットや、その機器から正当に受け
取ることを期待すべきイベントを示すものである。

【００６０】本発明の通信プロセスによれば、ある機器が他の機器の能力を判定すると、こ
れらの能力にアクセスすることを可能にする必要がある。これを達成するには、
ある機器がコマンド要求を含むメッセージを他の機器に送ることを可能にする一
般的な通信手段が必要である。本発明の一般的なメッセージサービスプロセスに
ついては既に説明した。

【００６１】汎用メッセージセットは、レベル１インタオペラビリティをサポートするのに
必要なプロセスに関する。これには、特定クラスの全ての機器によりサポートさ
れなければならない明確に定義されたメッセージセットが含まれている。これに
より、全ての機器が汎用コマンドの共通セットに合致しているので、メーカに関
わりなく、１つの機器が他の機器とともに動作することができる。上述のように
、本発明のＨＡＶＩソフトウェアアーキテクチャでは、これらのコマンドがシス
テムの他の部分に対するＤＣＭとして設けられている。

【００６２】本発明のこれら３つの基本プロセスは、少なくとも最低レベルのインタオペラ
ビリティをサポートする。多くの場合、いずれの機器もＳＤＤを介して他の機器
の能力を問合せすることができるので、いずれの機器も他の機器によりサポート
されるコマンドセットを判定することができる。各機器は汎用メッセージングシ
ステムへのアクセスがあるので、いずれの機器も他の機器とインタラクトするこ
とができる。

【００６３】しかし、本発明に係るレベル１コンパチビリティでは、各機器が最低レベル又
は低下したレベルの機能でインタオペレーションを行うことができるのみである
。各機器クラス毎の汎用メッセージセットは、最小限で共通のコマンドセットで
ある。ＳＤＤ手段では、ある機器のＵＩやそのインタラクションモデルの幾つか
の特徴についての情報を提供することにより、その機器のある程度のカスタマイ
ゼーションを行う手段が得られる。他のＩＡＶ機器は、その機器に対するインタ
ーフェースを示す、この情報を利用することができる。また、いずれのＦＡＶ機
器も、その機器用に生成した汎用ＤＣＭをカスタマイズするための、この情報を
利用することができる。しかし、ある機器が有する新たな機能を他の機器に対し
て通信することを可能にするため、さらに拡張可能なメカニズムが必要である。
本発明のレベル２インタオペラビリティにより、このメカニズムが得られる。レ
ベル１及びレベル２インタオペラビリティについては、以下に詳細に説明する。

【００６４】レベル１及びレベル２ＤＣＭ上述のように、本発明のＤＣＭは、ある機器に対するアクセス、制御、インタ
ラクションを行うことにより機能する。ＤＣＭは、典型的には家庭用ＡＶアーキ
テクチャにおけるＦＡＶのリソース上で示される（例えば実行される）。本発明
のＤＣＭは、ある機器に対するインターフェースを提供し、その機器がユーザに
提示したいＵＩを管理する。

【００６５】本発明では、レベル１インタオペラビリティの場合、各機器用に生成されたＤ
ＣＭは汎用的である。これらＤＣＭは、機器の汎用的制御を可能にする最小限の
コマンドセットをサポートする。機器特有の特徴をサポートするには、ＤＣＭが
このような機器特有の特徴にアクセスし、ＵＩを介してユーザに機器特有の特徴
を提示することが可能でなければならない。

【００６６】これを達成するため、レベル２インタオペラビリティが使用される。本発明で
は、家庭用ＡＶアーキテクチャは、ある機器がその機器用に通常生成される汎用
ＤＣＭに対して、「オーバライドＤＣＭ」を設けることができるようにする。オ
ーバライドＤＣＭ（例えばレベル２ＤＣＭ）は、ＦＡＶのデフォルトＤＣＭ（例
えばレベル１ＤＣＭ）を置換することができる。なお、レベル２ＤＣＭは種々の
ソースから検索することができる。このようなソースの一つとして、機器のＳＤ
Ｄ自体がある。この場合、レベル２ＤＣＭが機器のＳＤＤからフェッチ、受信、
あるいはその他の方法で獲得され、機器がシステム内に設置されるときにＦＡＶ
ノードにて示される。家庭用ＡＶアーキテクチャはベンダに対して中立的なので
、レベル２ＤＣＭは、それぞれ異なるハードウェアアーキテクチャを有するかも
しれない種々のＦＡＶノードにおいて動作することが必要である。これを達成す
るため、本発明のレベル１及びレベル２ＤＣＭの両方のフォーマットがアーキテ
クチャに対して中立的であり、ＦＡＶノードの種々のソフトウェア実行環境がレ
ベル１及びレベル２ＤＣＭを示し動作させることができるようにする。

【００６７】なお、本発明では、ＦＡＶノードにおいて生成され動作する場合、本発明のＤ
ＣＭは、基本メッセージングシステムを用いて上述と同様にＩＡＶ及びＢＡＶノ
ードとの通信を行う。

【００６８】上述のように、所定のＨＡＶＩネットワークにおいて可能なＦＡＶ、ＩＡＶ、
ＢＡＶノードの組み合わせは多数ある。これらの組み合わせは、概して２種類に
分類される。すなわち、ＦＡＶ機器をサポートするＨＡＶＩネットワーク構成と
、サポートしないＨＡＶＩネットワーク構成である。この違いは、本質的に、Ｈ
ＡＶＩネットワークがピアツーピア構成を使用するか（例えばＦＩＧ．２に示す
ように、ＦＡＶが存在しない場合）、又は何らかの制御階層を設けるか（例えば
ＦＩＧ．３に示すようなＦＡＶクラスタ）を定義する。

【００６９】本発明の一実施例によれば、ＦＡＶが存在しない場合、レベル１インタオペラ
ビリティのみが使用可能であり、各機器は、他のＩＡＶ性能の検出、それらの性
能の提示、機器の制御を行うのにＳＤＤ情報を使用しなければならない。ＦＡＶ
が存在する場合、ＤＣＭが示され使用される。これらがレベル１（例えば汎用）
ＤＣＭである場合、各機器はレベル１インタオペラビリティで動作する。レベル
２ＤＣＭが少なくとも１つあれば、幾つかの機器はレベル２インタオペラビリテ
ィで動作する。

【００７０】本発明では、機器のうちのクラスタがＦＡＶノードの制御下でインタオペレー
ションを行い、他の機器がピアツーピアでインタオペレーションを行う混合動作
モードが可能である。このようにして、本発明の柔軟性により、ベンダは、各機
器がＨＡＶＩネットワークにおける他の機器とシームレスにインタオペレーショ
ンを行うことを確保するとともに、コスト／性能スペクトルのいずれのポイント
においても機器の設計及び構築の自由を得ることができる。

【００７１】次に、ＦＩＧ．７を参照して、ＨＡＶＩアーキテクチャの一実施例の論理ブロ
ック図７００を説明する。ＦＩＧ．７は、本発明に係るＨＡＶＩアーキテクチャ
の全体を示す図である。論理ブロック７００におけるコンポーネントは以下の通
りである。

【００７２】デバイスマネージャ７６１：デバイスマネージャ７６１は、ＦＡＶ機器により
管理される機器を表すＤＣＭの生成及び管理を行う。

【００７３】デバイスモジュール７２０：これらは個々の機器のためのＤＣＭである。上述
のように、各ＤＣＭは機器の制御ポイントとして機能し、ＵＩコンポーネント及
び制御コンポーネントを提供する。ＤＣＭ（例えば機器モジュール７２０）は、
他のアプリケーションによる機器へのアクセス及び操作を可能にするＡＰＩを提
供する。

【００７４】サービスモジュール７３０：これらのモジュールはソフトウェアモジュールと
して考えることができる。これらは、ホームネットワークにおける他の機器又は
コンポーネントに対する一般的なサービスを提供するソフトウェアコンポーネン
ト（ハードウェア機器とは異なる）用のＤＣＭである。

【００７５】通信媒体マネージャ７４０：このコンポーネントは基礎となる物理的通信プロ
セスの管理を行う。これは、コードモジュールが通信媒体（例えばＩＥＥＥ１３
９４）の特徴とインタラクトすることを可能にするＡＰＩを提供する。

【００７６】レジストリ７０６：これはサービスデータベースである。物理的機器及びソフ
トウェアサービスのための全てのＤＣＭがレジストリ７０６への登録を行い、全
てのモジュール（例えばデバイスモジュール７２０）が、他の機器又はモジュー
ルにアクセスを得るためにレジストリに対して問合せすることができる。

【００７７】通信マネージャ７５０：このコンポーネントは通信媒体の低レベルのアブスト
ラクトである。

【００７８】メッセージング７０２：このコンポーネントは、機器（ハードウェア）とデバ
イスモジュール７２０及びサービスモジュール７３０の両方が、互いに通信を行
うことができるようにする基本メッセージ通知手段を与える。

【００７９】イベントマネージャ７０３：このモジュールは汎用イベントサービスを提供す
る。これはＨＡＶＩネットワークにおける通知を可能にする他一対多数の通信サ
ービスである。

【００８０】初期設定マネージャ７０１：このコンポーネントは機器のブートストラッププ
ロセスの一部として使用される。

【００８１】データルーティング７６２：データルーティングコンポーネント７６２は、機
器とデバイスモジュールとの間にサービスがルートを設定するに役立つ。これは
、特定ルートを介したデータの転送のコストや、データフォーマット変換の要件
等を考慮する。このコンポーネントは基本アーキテクチャには必要とされない。

【００８２】ＡＶ動作／マクロ７６３：このコンポーネントは、低レベルのコマンドの集合
である高レベルのＡＶ動作のマネージャである。すなわち、マクロサービスを提
供する。このコンポーネントは基本アーキテクチャには必要とされない。

【００８３】高レベルＵＩライブラリ７０４：このコンポーネントは、機器モジュール７２
０がそれに対応する機器のためのＵＩを構築するために使用する高レベルＵＩコ
ンポーネントのセットを提供する。このコンポーネントは基本アーキテクチャに
は必要とされない。

【００８４】アプリケーション（及びユーザ）インターフェース７０５：このコンポーネン
トは、ローカル又はリモートのＨＡＶＩ準拠機器及びアプリケーションの共通の
民生用電子機器プラットホーム（common consumer electrics platform：ＣＣＥ
Ｐ）ＡＰＩ間のリンクを与える。このコンポーネントは基本アーキテクチャには
必要とされない。

【００８５】なお、ＦＩＧ．７に示す上述のコンポーネントは機能のアブストラクトである
。これらは、ＨＡＶＩ準拠機器のためのアーキテクチャにどんな機能が含まれる
のかを明確にするように設計されている。本発明を不必要に曖昧にしてしまうこ
とを避けるため、コンポーネント７０１〜７６３の関係やそれらの間のメッセー
ジフローについては、図示を省略する。

【００８６】ＤＣＭ構成及び機能概要本発明の一実施例では、ＦＡＶノードが利用可能なＨＡＶＩネットワーク構成
において、そのＦＡＶノードがＨＡＶＩネットワーク内の各物理的機器毎にＤＣ
Ｍが存在する。ＤＣＭは機器に対するインターフェースを与え、それをアーキテ
クチャ内のオブジェクトとして提示する。他のＤＣＭ、システムサービス、アプ
リケーションサービスは、利用可能な機器を見つけるため、また、ＤＣＭを介し
て機器とインタラクトすることを可能にする識別子を得るため、ローカルレジス
トリに問い合わせる。

【００８７】デバイス制御モジュールは、ソフトウェアアーキテクチャとインタラクトして
、ユーザに対するデバイスユーザインターフェース（ＵＩ）を提示する。そして
、ユーザからの入力がＤＣＭに入り、ＤＣＭがその入力を使用して実際の機器を
制御する。

【００８８】上述のように、ＤＣＭはレベル１及びレベル２インタオペラビリティをサポー
トする。レベル１ＤＣＭは、通常ＦＡＶノードが供給される汎用ＤＣＭであり、
所定のメッセージセットを用いて機器クラスの基本的な所定の特徴セットを管理
することができる。初期設定の間、ＤＣＭはデバイスマネージャと共同して、管
理される機器の実際の特徴を見つけるとともに、その機器を制御するように自己
形成を行う。したがって、汎用ＶＴＲコントローラは、１３９４ＡＶ／Ｃメッセ
ージを用いて、又は制御Ａ１を介して、標準のＶＴＲを制御する。

【００８９】レベル２インタオペラビリティの場合、その機器のために設けられたＤＣＭは
、例えば機器自体等の外部ソースからロードされたオーバライドＤＣＭとなる。
これらオーバライドＤＣＭは、ＤＣＭ用の共通言語フォーマットで書かれている
。オーバライドＤＣＭの機能は汎用ＤＣＭの機能と異なるわけではないが、与え
られたＡＰＩがより包括的なものであることが考えられる。

【００９０】ＤＣＭが設けられると、ＤＣＭは機器のための制御インターフェースのみなら
ず、機器に関連したＳＤＤデータへのアクセスをも与える。ＤＣＭは機器のイベ
ントマネージャとして動作し、機器特有のイベントを受け取るとともにそれらを
イベントシステムに知らせる（以下参照）。また、ＤＣＭは機器のＵＩマネージ
ャとして動作し、ＵＩ管理システムとインタラクトして、何らかの表示装置を介
してユーザインターフェースを与える。さらに、ＤＣＭは機器のリソースマネー
ジャとして動作し、機器アクセス及びサービスの要求を調停する。

【００９１】一般的なＤＣＭの術語以下の説明で用いる本発明の術語で、各ＤＣＭがホームネットワークにおける
機器のモデルを示す。使用する基本的な術語は以下の通りである。１）機器：この用語は機器全体を表す。２）サブデバイス：この用語は、デバイス（機器）を構成する多数のコンポーネ
ントのうちの１つを表す。技術によってはサブデバイスを区別する能力がない場
合もある。３）内部接続：この用語は、内部サブデバイス間の論理的又は物理的接続を表す
。４）外部接続：この用語は、ある機器の外側の物理的コネクタと、その機器の外
部の送信先機器との接続を表す。ユニットシリアルバスや、ＡＶ／Ｃの外部入出
力プラグと同じである。５）プロトコル：この用語は、サブデバイス又はデバイス（例えばＡＶ／Ｃ、制
御Ａ１等）により扱われる制御プロトコルを表す。なお、デバイスは、異なるプ
ロトコルを扱うサブデバイスを有してもよい。６）インターフェース：この用語は物理的バス接続インターフェース（１３９４
、ＵＳＢ等）を表す。７）機器クラス：この用語は、所定の機器の集合の基本的機能を記述する一方法
である。例えば、ＤＶＴＲのクラスは、テープ媒体にデータを記録することがで
きる。同様に、オーディオが入力され、何らかの特殊効果の実行、修正したオー
ディオストリームを出力することができる多数の機器がある。これらは全て、オ
ーディオプロセッサ等のクラスに属する。この概念の有用性については後述の説
明で、より明らかになる。８）機器モデル：この用語は、標準又はカスタムデバイスの定義を構成するサブ
デバイス及び接続の集合を表す。物理的に別々のデバイスにおいてアクセス可能
な個々のサブデバイスを組み合わせて、機器モデルを用いた論理的又は仮想機器
を形成することができる。９）標準機器：この用語は標準モデルの定義を表す（例えば、ＤＶＴＲは、少な
くともチューナサブデバイスとＶＴＲ（トランスポート）サブデバイスからなり
、それらの間にプラグを有する）。１０）特殊機器：この用語は、標準サブデバイス、又は標準サブデバイスとベン
ダ固有のサブデバイスとの組み合わせにより構成されるベンダ固有機器モデルを
表す。例えば、デュアルデッキＤＶＴＲは、標準機器であるが標準構成はない２
つのＶＴＲサブユニットを有する。１１）集合機器：この用語は、種々のコンポーネントから組み合わせることがで
きる論理エンティティを表す。物理的デバイス及びサブデバイスは個々にアクセ
ス可能なハードウェアピースである。各デバイスがアクセス可能なサブデバイス
を有する場合、このモデルは拡張されて集合機器をサポートする。集合機器の具
体例としては、別々の物理的機器からの又は単一機器内のサブデバイスや、デバ
イス機器及びサブデバイスと同様のサービス又は性能を提供するソフトウェアコ
ーデック等のソフトウェアモジュールがある。これらのモジュールは、全てＡＶ
ネットワークにおける同一ノードに存在することもでき、又は多数のノードに分
散されることもできる。

【００９２】機器の分類各機器が行う動作の種類に基づいて、又は各機器が対応する媒体の種類に基づ
いて機器を分類することにより、将来製造される機器のための動作する汎用化さ
れた制御ＡＰＩの生成が可能になる。その目的は、機器の種類や機器のメーカに
関わらず、基本的機能が常に高い割合でアクセス可能であるようにすることであ
る。

【００９３】制御可能であるが、汎用化された制御ＡＰＩから外れるようなメーカ固有の又
は機器固有の機能については、ＳＤＤ情報及びＤＣＭを拡張する他の技術を介し
てのみアクセス可能となる。

【００９４】一般的には、デバイス又はサブデバイスの分類については、その主な機能によ
り説明することができる。１３９４規格のＡＶ／Ｃ制御プロトコルでは、以下に
説明する従来の機器分類方法を用いる。デバイス又はサブデバイスを分類するの
に使用される第１セットの要素を以下に示す。１）特定の機器がトランスポートメカニズムを有しているか否か。２）このサブデバイスの有用性が、主に、信号がここで終わっているという事実
により決まるか否か（信号が変更されずに伝達されるという事実とは無関係に）
。３）特定のサブデバイスが信号ソースであるか否か（例えば信号出力を有するか
）。４）特定の機器がデータが入力され、ある種の処理を行い、変更したデータを出
力するか否か。５）いかなる種類の信号入力又は出力も存在しないか否か（例えば、機器が、衛
星アンテナを位置決めするためのメカニズム等、ある種のユーティリティである
か）。

【００９５】本発明では、第２レベルの分類にて、トランスポートメカニズムを有する機器
を検討することができる。この場合、一般的な問合せとして、「この機器は取り
外し可能な媒体に対応するか」を問うことになる。対応する場合、Play()、Stop
()、Search()等の基本的な制御セットが適用される。媒体を有する機器について
は、媒体上の情報の構成を判定するために、その記録能力を問い合わせることが
できる（トラックベースか、テープのように連続的か、どのように測定されるか
−ＳＭＰＴＥタイムコード、ある位置からのタイムオフセット等）。

【００９６】この具体例では、受けることができる信号の種類や結果として生成することが
できる種類により、信号処理機器を説明することができる。これは、いずれのク
ライアントでも探しているサービスの種類を説明する方法やそのサービスにアク
セスする方法を知ることができるように、信号タイプを説明するための共通の定
義やサービスへのアクセス方法の確立が必要である。

【００９７】ある種のデータが入力されるとともに、異なる種類の接続でそのデータを伝送
する能力を有する機器（例えば、デジタルビデオを入力として、そのデータを送
り返すことができる標準アナログビデオＲＣＡジャックを有する機器）は、いず
れも、データコンバータクラスとして動作することができる。これらの機器のた
めのＤＣＭは、システムレジストリにおけるデータコンバータとして登録される
ので、クライアントは必要に応じてそれらを見つけて使用することができる。

【００９８】機器のアクセス及び制御本発明では、基本的な機器分類がなされると、その機器のために設けられた汎
用ＤＣＭは、その機器に制御メッセージが送られるようにするＡＰＩを与える。
特定クラスの機器に送られる又は（イベント場合は）受信される基本的な制御メ
ッセージセットは、標準化されており、付表に詳述されている（本明細書にはな
い）。この具体例では、これらのメッセージはＤＣＭにより与えられた基本ＡＰ
Ｉを表す。

【００９９】機器管理本発明では、ＤＣＭのＡＰＩは、より複雑な機器管理を可能にする高レベルサ
ービスのセットも与える。この具体例としては、機器の予約やイベント管理が含
まれる。機器の予約の場合、ある機器に対する要求がその機器への既存の要求に
より拒否されることがある。あるいは、機器要求がタイムベースマクロのその後
の予約に関するものであってもよい。これらの場合、ＤＣＭは、アプリケーショ
ン又はサービスがＤＣＭに対して要求をキューに登録（queue）すること、すなわち機器の予約を可能にする、又は機器が利用可能となったときに通知を受ける
ことを可能にするインターフェースを与える。

【０１００】接続管理また、本発明のＤＣＭは、他のオブジェクトが機器間の接続状態を問い合わせ
て、それらの接続を操作することを可能にする高レベルＡＰＩを与える。このＡ
ＰＩは主としてルートマネージャにより使用されるが、システム内のいずれのオ
ブジェクトに対しても使用可能である。接続管理により、内部的にはサブデバイ
スユニット間で、また、外部的にはデバイス間で接続を確立することができる。
接続状態を問い合わせることができるとともに、接続能力（信号フォーマット）
を問い合わせることもできる。

【０１０１】ＳＤＤ管理また、本発明のＤＣＭは、ＳＤＤ管理に対する汎用化されたインターフェース
を与える。これにより、機器内のＳＤＤデータの問合せ及び使用が可能になる。
ＡＰＩは２つの部分に分割され、第１の部分は、デバイスイメージ、その名称、
オーバライドＤＣＭ又は機器のＵＩを表す際に使用される他のアイコンの位置の
ＵＲＬ（利用可能ならば）を含むＳＤＤデータから既知の情報を得るためのＡＰ
Ｉを与える。ＳＤＤのＡＰＩの第２の部分は、機器の機能的特徴へのより詳細な
アクセスを与えるように設計されている。

【０１０２】機器の表示及びユーザインターフェース（ＵＩ）本発明では、ＤＣＭは機器のＵＩ特徴にも関わっている。レベル１インタオペ
ラビリティの場合、ユーザとのインターフェースを行うのに汎用ＵＩが使用され
る。これは、ＵＩアイコン等の特徴が汎用ＤＣＭにより特定されアクセスされる
ようにする基本的ＳＤＤデータにより増加してもよい。本発明を不必要に曖昧に
することを避けるため、どのようにＤＣＭがＵＩ管理システムとインタラクトし
て機器固有のＵＩを与えるのかについては、詳細な説明を省略する。しかし、こ
の具体例において、基本モデルは、ＤＣＭ内の内部管理コードがＵＩ管理システ
ムと共同して機器用のＵＩを与えるものである。ＵＩ管理システムによりユーザ
入力がＤＣＭに送られ、ＤＣＭがそれを機器固有のコマンドに変換する。これら
のコマンドは、基本メッセージングシステムを用いて機器に送られる。応答が受
信された場合、これらはＤＣＭを介してＵＩに送られる。さらに、機器のいかな
る状態変化、例えば、オン／オフについても、イベントシステムを介してＤＣＭ
に送られ、ＤＣＭはそれらを用いてＵＩを更新する。

【０１０３】サービスモジュールサービスモジュール（例えばサービスモジュール７３０）は、概念的にはデバ
イス制御モジュールと同じである。これらは、通常ソフトウェアのみによって提
供されるサービスへのインターフェースを与える。この具体例において、サービ
スモジュールは、システムサービスとアプリケーションサービスの２種類がある
。システムサービスは、ＨＡＶＩソフトウェアアーキテクチャの一部として与え
られる既知のサービスである。このタイプのサービスの具体例としては、データ
フォーマット変換器、プロトコル変換器、グラフィックサービスがある。これら
のサービスは、ＨＡＶＩアーキテクチャの一部として定義される既知のＡＰＩを
有している。アプリケーションサービスは、他のサービスオブジェクトによりそ
のために生成されたオブジェクトである。これらのオブジェクトは明確に定義さ
れたＡＰＩを与えるが、そのＡＰＩは既知のものではない。この具体例では、ア
プリケーションオブジェクトを使用したいアプリケーション又は他のオブジェク
トはいずれも、そのＡＰＩとコーリングセマンティクスを知る必要がある。必要
ではないが、一般的に、システムサービスは、システムの寿命の間存在する。ア
プリケーションサービスは、アプリケーションの寿命の間存在し、非常に短命で
ある。

【０１０４】システムサービス本発明では、ＡＶアーキテクチャにより提供されるサービスの多くはサービス
モジュールとして提供され、これらはサービスをシステムレジストリに登録し、
メッセージングを用いてアクセスすることができる。このようなサービスの具体
例としては、機器がＵＩをユーザに与えることを可能にするメカニズムを与える
ＵＩサービスモジュールや、種々のフォーマット間のＡＶデータを変換するデー
タフォーマットサービスがある。

【０１０５】ＤＣＭマネージャ概要本発明では、ＤＣＭマネージャは、ＦＡＶノードにあるＤＣＭの集合を扱う全
ての特徴に関するものである。これには、所定システムに利用可能である全ての
デバイス制御モジュール候補の検出（discovering）、具現化（instantiating）
、破棄（disposing）が含まれる。機器リソース管理は、一般的に個々のＤＣＭにより行われるが、多数の機器又はサービスがインタラクトしている場合、又は
ＤＣＭのうちの幾つかが異なるＦＡＶノードに配置されている場合、より高いレ
ベルの管理が必要となる。したがって、ＤＣＭマネージャは、離れたノードにお
ける他のＤＣＭマネージャと通信を行って、ネットワーク全体のデバイス及びサ
ブデバイスリソースの割り当て及び管理のために調停を行う。ＤＣＭマネージャ
の能力については以下に説明する。

【０１０６】物理的機器の検出及び列挙（enumeration）本発明では、ＤＣＭマネージャ基礎となるＯＳサービスと共同して、利用可能
な機器の元リスト（raw list）を得る。なお、基礎となるバス技術によっては、
これらＤＣＭが動的になることもある。この具体例では、例えば、物理的機器が
１３９４バスを介して移動するので、ＤＣＭもそれとともに移動する。同様に、
サービス及び集合機器ＤＣＭも動的であり、ＦＡＶノードにおけるイベントに応
じて生成や破壊が行われる。

【０１０７】このタスクには、ＡＶアーキテクチャの構成要素とのインタラクションと、Ｆ
ＡＶホストＯＳ、ノードハードウェア、通信ハードウェアの構成要素とのインタ
ラクションの両方が必要である。これにより、機器検出に必要な的確なプロセス
はシステム環境によって異なる。しかし、ＤＣＭの箇所で説明したように、機器
とその特徴を検出するために有するＳＤＤデータを問い合わせるというアプロー
チが一般的である。この具体例では、システムが初期化される毎に、又はシステ
ムが変更される（例えばバスがリセットされる）毎に、ＤＣＭマネージャが所定
順序で規則のセットに従う必要がある。

【０１０８】汎用ＤＣＭの生成本発明では、各ノード毎に、ＤＣＭマネージャが、ＤＣＭを生成すべきである
ことを決定するのに十分な作業を行う。この作業はＦＡＶノードにより管理され
る全ての媒体関連機器について行われる。この具体例では、異なる管理技術によ
る機器、例えば、ＵＳＢベースの機器が、ＵＳＢ通信をサポートするノードにお
けるＤＣＭとして、又は遠隔管理システムのための代理として動作する特殊ＤＣ
Ｍとして、アーキテクチャ内に設けられてもよい。しかし、ハードディスク等、
幾つかのＵＳＢベースの機器は、実際は単にランダムアクセス媒体記録又は再生
機器とされていることもある。この場合、これらは他の「実際の」媒体機器とし
て扱われる。この具体例では、各媒体間連エンティティ毎に、ＤＣＭマネージャ
が汎用又はレベル１ＤＣＭを生成する。各ＤＣＭは、可能であれば、より機器固
有ものとなるための能力を後で持つことになる。これについて以下に説明する。

【０１０９】オーバライド（例えばレベル２）ＤＣＭが利用可能でアクセス可能である場合
、ＤＣＭマネージャは、そのＤＣＭをフェッチしてＦＡＶノードにインストール
することになっている。この具体例では、オーバライドＤＣＭと汎用ＤＣＭがど
のようにインタラクトするかについての詳細は、ＤＣＭディベロッパーによって
異なる。例えば、デフォルトＤＣＭを完全に置換する場合もあれば、デフォルト
ＤＣＭと共同して能力を高める場合もある。

【０１１０】本発明では、メーカが提供するレベル２ＤＣＭは種々のソースから得られるも
のである。各機器は、それらをＲＯＭ内、ディスク又はテープのヘッダ等の記憶
メカニズムに保持してもよい。それらは、ＦＡＶにとってアクセス可能ならばウ
ェブサイト又はｆｔｐサイトからダウンロードしてもよく、又はディスクやその
他の記憶媒体からのインストールにより典型的なコンピュータ業界のやり方で提
供することもできる。メーカが提供するオーバライドＤＣＭの能力を可能にする
には、ＤＣＭの生成及びインストールのモデルが必要である。この具体例では、
レベル２ＤＣＭがインストールされると、レベル１ＤＣＭと同じベースインター
フェースをクライアントに供給するとともに、新たなインターフェースを供給す
るか、又は機能の変更に応じる。

【０１１１】ＤＣＭの破棄本発明では、ＤＣＭマネージャは適切な時点でＤＣＭを破棄し、ＤＣＭが除去
されたことをクライアントに通知することになっている。この具体例では、ＤＣ
Ｍを破棄するときの規則や、ＤＣＭとＤＣＭマネージャとの間のクリーンアップ
の責任の分担は、特定のＨＡＶＩネットワークの特定要件に合わせて調整するこ
とができる。

【０１１２】多数のＤＣＭ間での調整多数のＤＣＭ間の幾つかの複雑なサービス、例えば、複雑な動作のコマンドキ
ュー等の場合、ＤＣＭマネージャは多数のＤＣＭと調整して、これらの動作を行
う必要がある。これは、クライアントに供給された「コマンドモデル」により影
響を受ける。例えば、クライアントがＨＨ：ＭＭ：ＳＳ：ＦＦタイムコードに基
づく動作を特定することができるようにする上位のＡＰＩを定義する場合、この
タイムモデルと、ハードウェア又は基礎となるサポートモジュールが対応するも
のとの変換を行う必要がある。なお、メカニズムの遅延等により影響される複雑
なタイムベースの動作について説明しなければならない。このタイプの調整には
、ネットワークにおける実時間動作の概念が必要であり、ある程度の保証を与え
る物理的及びソフトウェア的基礎構造によって異なる。

【０１１３】次にＦＩＧ．８を参照して、本発明に係るＨＡＶＩアーキテクチャのレイヤ論
理図８００を説明する。論理図８００に示すコンポーネントは論理図７００に示
すコンポーネントと同じであるが、論理図８００の場合は、低レベルプロセスが
下に配置されている（例えば１３９４モジュール８３０）のに対し、高レベルプ
ロセスが上に配置されている（例えばアプリケーション８０１）。また、論理図
８００は、他のサービス８１０、トランスポート適応モジュール８１５、他のモ
ジュール８４０も示す図である。

【０１１４】上述のように、ＨＡＶＩアーキテクチャ全体を、通信コンポーネントとサービ
スコンポーネントとして示すことができる。このアーキテクチャ内の最上位レベ
ルにあるアプリケーション８０１は、サービスと通信コンポーネント（例えばＤ
ＣＭ７２０、サービスモジュール７３０等）を使用する。そして、多数のサービ
スコンポーネント（例えばサービスモジュール７３０、ＤＣＭ７２０等）は、基
礎となる通信コンポーネント（例えばメッセージング７０２、トランスポート適
応モジュール８１５等）を使用する。例えば、アプリケーション８０１のうちの
１つが、レジストリ７０６を介してＤＶＴＲ（デジタルビデオテープレコーダ）
機器のハンドルを要求し、その機器に再生コマンドを送る場合である。上述のよ
うに、ＨＡＶＩアーキテクチャにおけるコンポーネントは、基礎となるメッセー
ジングシステムを用いて通信を行う。すなわち、モジュールがメッセージ通知を
使用する。

【０１１５】ＦＩＧ．９は、一実施例のＨＡＶＩアーキテクチャにおけるローカル及びリモ
ートメッセージングの図９００を示す図である。メッセージングコンポーネント
７０２はローカルメッセージング及びリモートメッセージングの両方を扱うもの
として示されている。したがって、メッセージングコンポーネント７０２は図９
００のベースに示されている。ローカルメッセージは、種々のアプリケーション
９０１〜９０４に対する矢印９０２ａ，９０３ａ，９０４ａとして示されている
。リモートメッセージは矢印９０１ｂで示されている。説明を明確にするため、
図９００及び以下の説明では、メッセージングシステムを介したローカル通信に
ついては省略し、ローカルメッセージング（例えば矢印９０１ａ〜９０４ａ）が
コンポーネント間の直接機能コールに基づいているものとして示す。

【０１１６】ＦＩＧ．１０は、一実施例のＨＡＶＩアーキテクチャにおける１３９４を介し
て送られるメッセージの図１０００を示す図である。図１０００において、メッ
セージ１（例えば矢印８２０ａ）は、ＤＶＴＲ機器のハンドルを求める（問合せ
ＡＰＩを介した）レジストリ７０６に対するアプリケーション８０１の一つから
の要求である。レジストリ７０６は、メッセージ２（例えば矢印８２０ｂ）にて
ＤＶＴＲＤＣＭのためのハンドルを送り返す。このハンドルはメッセージング
システムに使用されるメッセージアドレスである。

【０１１７】本発明では、アプリケーションはハンドルを使用して、メッセージ３（例えば
８２０ｃ）によりＤＶＴＲのＤＣＭを起動する。ＤＣＭは再生コールのアプリケ
ーション起動を内部コマンドに変換し、これがメッセージ４（例えば矢印８２０
ｄ）としてメッセージコンポーネントに送られる。この内部コマンドはレベル１
に設定された明確に定義されたコマンドの一部である。すなわち、ＨＡＶＩコマ
ンドである。メッセージングコンポーネント７０２はハンドル情報を内部的に使
用して、この機器がどのバス上にあるのかを判定する。機器がＩＥＥＥ１３９４
バス上にあることがわかると、メッセージコンポーネント７０２はＩＥＥＥ１３
９４トランスポート適応モジュール（ＴＡＭ）８３０を使用して、メッセージを
メッセージ５（例えば８２０ｅ）として１３９４パケットに変換し、これがＦＣ
Ｐパケットのデータ部に配置される。ＴＡＭは、メッセージ６（例えば８２０ｆ
）として１３９４デバイスドライバを呼び出し、１３９４を介してメッセージを
送る。

【０１１８】受信側では（図示せず）、メッセージが１３９４デバイスドライバに供給され
た後、１３９４ＴＡＭを介してメッセージングコンポーネントに送られる。メッ
セージングコンポーネントは、ＨＡＶＩメッセージパケットを受け取り、メッセ
ージキュー又はコールバック機能を介して直接受信コードに供給する。この具体
例では、受信機がＩＡＶ機器である場合、ＣＣＥＰアーキテクチャの通信コンポ
ーネントとレジストリのみを有する。ＩＡＶ機器が有する他の機能はいずれも機
器固有のものである。

【０１１９】なお、ＦＩＧ．１０の具体例では、メッセージングシステムと機器の制御に使
用するコマンドセットとのＨＡＶＩアーキテクチャの違いを示している。本発明
では、メッセージングシステムは、メッセージングシステムにとって完全に不明
瞭な内容のデータ部を有するメッセージパケットを供給する汎用メッセージング
メカニズムである。例えば、メッセージングシステムは、アプリケーションコマ
ンド、ＡＶＣ−ＣＴＳコマンド、ＣＡＬコマンド、その他のコマンドに対するプ
ライベートアプリケーションを送ることができる。ＤＣＭはリモート機器と通信
を行うエンティティであり、メッセージングシステムを使用して、その機器に固
有のコマンドを送る。レベル１ＨＡＶＩ準拠機器の場合、メッセージングシステ
ムにより送られるコマンドセットはＣＣＥＰアーキテクチャの一部として定義さ
れる。ＤＣＭとそれが制御する機器との間でメッセージングシステムにより送ら
れるメッセージには、これらの明確に定義されたコマンドが含まれる。レベル２
機器の場合、拡張コマンドセットが定義されておらず、これらは純粋なＡＶ／Ｃ
−ＣＴＳ、ＣＡＬ、その他のコマンドであってもよい。

【０１２０】ＦＩＧ．１１を参照して、ＨＡＶＩアーキテクチャの一実施例における他のア
プリケーションを起動するアプリケーションの図１１００を説明する。図１１０
０は、メッセージングシステム７０２ａ，７０２ｂを介して、別の機器１１０２
で動作するアプリケーション８０１ｂにメッセージ１１０５を送る、機器１１０
１で動作するアプリケーション８０１ａを示す図である。上述のように、ＨＡＶ
Ｉネットワークにおいて動作するアプリケーションはいずれも、他のアプリケー
ションのためのメッセージハンドルを有しているときは、そのアプリケーション
にアクセスすることができる。メッセージハンドルを得るには、リモートＩＡＶ
機器（例えば上述のＦＩＧ．１０で説明したような）と同じプロセスが用いられ
る。メッセージハンドルが使用可能となると、ソースアプリケーション８０１ａ
は目的アプリケーション８０１ｂにメッセージ１１０５を送ることができる。上
述のように、これらのメッセージのフォーマットはアプリケーションによって全
く異なり、ＣＣＥＰアーキテクチャとは関係がない。これは、アプリケーション
間で受信メッセージを送るための通信メカニズムを提供するだけである。

【０１２１】なお、上述の具体例では、アプリケーション８０１ａ，８０１ｂが異なるＡＶ
機器１１０１，１１０２に存在することを想定している。しかし、上述のように
、これらのアプリケーション８０１ａ，８０１ｂが同じＡＶ機器に存在し、メッ
セージングシステムが、１３９４を使用してメッセージを送るコールではなく、
純粋にローカルな通信コールを行うこともできる。

【０１２２】ソフトウェアサービスの起動ソフトウェアサービスは、上述の汎用アプリケーションの場合の特殊なケース
である。本発明では、ソフトウェアサービスは、単にシステム基礎構造の一部を
なすアプリケーションである。この場合、モジュールは、例えばＵＩコンポーネ
ント等のシステムサービスを起動したいとき、メッセージングコンポーネントを
使用してこれを行う。ＵＩコンポーネントがローカルである場合、コールは完全
に１つのＡＶ機器内に含まれている。しかし、ＵＩコンポーネントがリモートで
ある場合、コールは１３９４ネットワークを介してリモートＡＶ機器に供給され
、そこでメッセージシステムがＵＩシステムサービスに対してコールを送る。

【０１２３】ＨＡＶＩネットワークへの新たな機器の追加ＨＡＶＩネットワークに新たな機器を追加する際、以下の３つの一般的な状況
がある。すなわち、非１３９４ネットワークを介して送られる従来のプロトコル
を用いる従来の機器を扱う場合と、１３９４ネットワークを介した非ＨＡＶＩプ
ロトコルを用いるベース機器を扱う場合と、ＨＡＶＩ準拠の新たなＩＡＶ機器を
扱う場合である。

【０１２４】従来の機器を追加する場合、この具体例では、従来の機器はＦＡＶノードによ
って直接制御することしかできない。上述のように、各従来の機器毎に従来ＤＣ
Ｍが生成されなければならない。１３９４ポートとイーサネットポートとを有す
るＦＡＶを想定する。ＣＭＭモジュールは１３９４とイーサネットの両方を管理
するように構成される。従来の機器がＦＡＶに知られるときは、まずＣＭＭモジ
ュールにて知られる。なお、これを達成するのに使用するメカニズムはＣＣＥＰ
アーキテクチャの範囲内ではない。これは通信媒体に固有のものである。ＣＭＭ
が新たな機器を認識すると、機器の種類を判定するために使用する媒体固有メカ
ニズムを通る。これもＣＣＥＰアーキテクチャを構成するものではない。そして
、ＤＭに対してこの機器のための従来ＤＣＭを設けるように要求する。ＦＡＶノ
ードは、予めこのＤＣＭを有して構成されているものとみなされる。

【０１２５】この具体例では、ＤＣＭは、生成されると、標準ＤＣＭと同じように登録され
る。しかし、このＤＣＭと他のＤＣＭとの重要な差異は、通信モデルと従来の機
器を制御するのに使用するコマンドセットとがＣＣＥＰアーキテクチャにとって
完全に未知のものであるという点である。例えば、この機器がプリンタサービス
を行うＩＰ機器であることも可能である。この場合、ＤＣＭはプリント、状態等
のコマンドセットを供給する。アプリケーションがプリント要求によりＤＣＭ
ＡＰＩを呼び出すと、ＤＣＭによりプリントコマンドがＩＰスタックを介してプ
リンタ装置に送られる。これがどのように行われるかについての詳細は、実行手
段によりそれぞれ固有ものである。

【０１２６】本発明では、一つの可能性として、従来ＤＣＭがＤＣＭ内のＩＰスタックの完
全な実行手段を有し、イーサネットデバイスドライバに接続する方法を知ってい
ることが考えられる。また、他の可能性として、ＦＡＶ機器がＩＰスタック及び
ソケット等の高レベルＡＰＩを供給することが考えられる。これらは、ＦＡＶの
実行手段の詳細であり、ＣＣＥＰアーキテクチャを構成するものではない。しか
し、従来ＤＣＭは「代理」ＤＣＭとして動作している。従来ＤＣＭがレジストリ
に登録されると、ホームネットワークにおける他の全てのモジュールにとって認
識できるようになる。これらは全て、従来ＤＣＭのＡＰＩを起動することができ
、従来ＤＣＭはイーサネットＩＰプリンタのプライベートコマンド言語への必要
な変換を行う。

【０１２７】ベースＡＶ機器を追加する場合、この具体例では、ＣＭＭが新たな機器につい
て通知を受けると、それがＣＣＥＰノードではないことを認識するが、ＤＣＭが
この機器にとって利用可能であることも検出する。この場合、ＣＭＭが、ＤＣＭ
をアップロードするとともにこのＤＣＭを生成するようにＤＭに要求することを
可能にするメカニズムを実行することになっている。しかし、ＤＣＭが設けられ
ると、純粋にプライベートな通信メカニズムを使用して機器に対するアクセス及
び制御を行う。上述のように、この具体例では、ベースＡＶ機器は、１３９４を
使用しオーバライドＤＣＭを実行するが、ＣＣＥＰアーキテクチャの実行は行わ
ず、また、レベル１ＨＡＶＩコマンドの実行も行わない機器である。この機器の
具体例としては、オーバライドＤＣＭを有するがＣＣＥＰ通信基礎構造をサポー
トしない機器が考えられる。

【０１２８】ＩＡＶ機器を追加する場合、上述の具体例では、アプリケーションが通信を行
いたい機器のメッセージハンドルを得るためにレジストリに対して問合せを行っ
た。ＦＡＶ機器については、送り返されたハンドルが常にＤＣＭにアクセスする
ために使用される。メッセージを直接機器に送ることは不可能である。ネットワ
ークに追加された機器がレジストリを介してどのように利用可能になるかを理解
するため、以下の具体例を用いる。

【０１２９】例えば、新たな機器（例えばカムコーダ）がＨＡＶＩネットワーク（例えば１
３９４ベースのもの）に接続されたとする。これによりバスリセットが生じる。
バスリセットはＩＲＤにおける通信媒体マネージャ（ＣＭＭ）により扱われる。
ＣＭＭは、カムコーダのＳＤＤデータを問い合わせて、その能力を見いだすこと
になっている。機器がレベル１機器である場合、すなわち、機器がアップロード
可能なＤＣＭを有していない場合、ＣＭＭは新たな機器が設置されたことをその
デバイスマネージャに通知する。デバイスマネージャは、このタイプの機器のた
めの新たなＤＣＭを生成し、ＤＣＭをレジストリに登録する。ＤＣＭは、初期設
定されると、自由に機器に対して問合せを行って機器に関するさらなる情報を直
接求めることができ、また、必要な場合に特殊化、例えば、ＵＩ情報が機器内に
存在する場合はＵＩ情報へのアクセスを行うことができる。ＤＣＭがレジストリ
に登録されると、他のいずれのモジュールもレジストリに問合せを行って、その
機器のためのハンドルを得るとともにＤＣＭを通信を行い、機器に対するアクセ
スや制御、及び、ユーザへのＵＩの提示を行うことができる。

【０１３０】例えば、ＦＩＧ．１２Ａ及び１２Ｂは、このような機器（例えばカムコーダ）
の例示的なＵＩ表示（例えばテレビジョン受像機の画面上の）を示す図である。
ＦＩＧ．１２Ａは、制御名や制御値を用いて変更することができる種々の制御が
ユーザに提示されるテキストメニュー表示を示す図である。ボタンについて、ユ
ーザが選択することができる（ボタンを押すこと）。ＦＩＧ．１２Ｂは、カムコ
ーダの「次レベル」のＵＩ表示を示す図である。ここでは、ユーザがＦＩＧ．１
２Ａのメニューからメインパネルを選択し、表示はグループ分け情報に基づく制
御を示す。この具体例では、グループ名がラベル付きインターフェース上で使用
されることにより、ユーザが、選択したパネル内のグループ間でナビゲーション
を行うことができる。

【０１３１】次にＦＩＧ．１３を参照して、本発明を適用したプロセス１３００のフローチ
ャートを説明する。プロセス１３００は、各機器に記憶されたＳＤＤ情報を用い
ることにより、ＨＡＶＩネットワークにおける複数の機器のシームレスなインタ
オペラビリティ及び統合を行う方法の各ステップを示す。プロセス１３００はス
テップ１３０１から開始するが、ステップ１３０１において、新たな機器がＨＡ
ＶＩネットワークに接続される。ステップ１３０２において、その機器によりサ
ポートされるレベル１機能の記述（例えばＳＤＤ）を得るため、機器に対して問
合せが行われる。ステップＳ１３０３において、その機器のために、レベル１機
能を実行するレベル１ＤＣＭがＳＤＤに基づいて生成される。ステップ１３０４
において、新たな機器がレベル２ＤＣＭのソフトウェアを有しているか否かをデ
バイスマネージャが判定する。

【０１３２】ＦＩＧ．１３のステップ１３０５において、新たな機器がレベル２機能を実行
するためのソフトウェアを有している場合、そのソフトウェアが機器から検索さ
れ、ステップ１３０６において、そのソフトウェアを用いてレベル２機能を実行
するレベル２ＤＣＭが生成される。ステップ１３０７及び１３０８において、レ
ベル２ＤＣＭを介して機器が連続的にアクセスされる。ステップ１３０９及び１
３１０において、新たな機器がレベル２ＤＣＭのソフトウェアを有していない場
合、レベル１ＤＣＭを介してその新たな機器が連続的にアクセスされる。このよ
うに、本発明は、レベル１ＤＣＭとレベル２ＤＣＭの組み合わせにより、ネット
ワーク内の複数の機器との新たな機器のシームレスなインタオペラビリティ及び
統合を行うことができる。

【０１３３】ＦＩＧ．１４は、本発明を適用したプロセス１４００のフローチャートを示す
図である。プロセス１４００は、ＨＡＶＩネットワーク内の複数機器間で基本コ
マンド機能と拡張コマンド機能を行う方法の各ステップを示す。ステップ１４０
１において、ＦＡＶ機器を含むＨＡＶＩネットワークに、ある機器が接続される
。ステップ１４０２において、その機器用の汎用レベル１ＤＣＭがＦＡＶ機器に
より生成される。上述のように、汎用レベル１ＤＣＭは機器の能力の基本アブス
トラクトである。汎用レベル１ＤＣＭによって、機器は、ＦＡＶ機器からの基本
コマンドセットに応答することが可能になる。ステップ１４０３及び１４０４に
おいて、ＦＡＶ機器が汎用ＤＣＭを使用して機器に問合せを行い、機器が記述情
報（例えばＳＤＤ）を有しているか否かを判定する。上述のように、記述情報は
機器の能力を記述する。ステップ１４０５において、機器が記述情報を有してい
る場合、ＦＡＶ機器は記述情報に基づいて汎用ＤＣＭを変更することにより、そ
の機器用のパラメータ化したＤＣＭを生成する。ステップ１４０６及び１４０７
において、パラメータ化したレベル１ＤＣＭを用いて機器が連続的に制御される
。ステップ１４０８及び１４０９において、機器が記述情報を有していない場合
、ＦＡＶ機器は汎用レベル１ＤＣＭを介して連続的に制御される。

【０１３４】次にＦＩＧ．１５を参照して、本発明を適用したプロセス１５００のフローチ
ャートを示す説明する。プロセス１５００は、ＨＡＶＩネットワーク内の機器の
将来的なグレードアップ性及び拡張性を確保する方法の各ステップを示す。ステ
ップ１５０１において、ネットワークに接続されたある機器用のデフォルトのレ
ベル１ＤＣＭが生成される。上述のように、デフォルトレベル１ＤＣＭは、ＨＡ
ＶＩネットワークにおける、この機器と他の機器との間で少なくとも最小限のイ
ンタオペラビリティを確保するように構成されている。ステップ１５０２におい
て、この機器がデフォルトレベル１ＤＣＭを介して他の機器によりアクセスされ
る。上述のように、デフォルトＤＣＭにより、第１の機器はＨＡＶＩネットワー
ク内の他の機器からのデフォルトコマンドセットに応答することが可能になる。
ステップ１５０３において、この機器用の更新されたレベル１ＤＣＭが受け取ら
れるか否かが判定される。ステップ１５０４において、この機器用の更新された
レベル２ＤＣＭが受け取られるか否かが判定される。上述のように、更新により
機器の能力及び機能が発展することが可能となる（例えば新たな、より効率的な
ソフトウェアが利用可能となる）。

【０１３５】ステップ１５０９及び１５０８において、更新されたレベル１ＤＣＭが受け取
られた場合、その更新レベル１ＤＣＭが組み込まれ（例えば、これは単に現レベ
ル１ＤＣＭを変更するのみのこともある）、次の更新が利用可能となるまで、こ
のＤＣＭを介して機器が連続的にアクセスされる。ステップ１５０５において、
更新レベル２ＤＣＭが受け取られた場合、ホストＦＡＶ機器におけるＤＣＭマネ
ージャが現ＤＣＭのリンクを外し、ステップ１５０６及び１５０７において、更
新レベル２ＤＣＭがリンクされるとともにレジストリが更新されて、ＨＡＶＩネ
ットワーク内の他の機器が更新レベル２ＤＣＭにアクセスすることが可能になる
。このＤＣＭは、次の更新レベル２ＤＣＭが受け取られるまで、機器にアクセス
するのに連続的に使用される。ステップ１５１０において、更新レベル１ＤＣＭ
も更新レベル２ＤＣＭも受け取られない場合、プロセス１５００は、現ＤＣＭ（
例えば最後にインストールされたＤＣＭ）を用いて動作を継続する。

【０１３６】ＦＩＧ．１６は、本発明を適用したプロセス１６００のフローチャートを示す
図である。プロセス１６００は、ＨＡＶＩネットワークにおけるＨＡＶＩ準拠機
器に対する従来の機器のシームレスなインタオペラビリティ及び統合を行う方法
の各ステップを示す。プロセス１６００はステップ１６０１から開始するが、ス
テップ１６０１において、従来の機器がＨＡＶＩネットワークに接続される。ス
テップ１６０２において、専用プロトコルを介して従来の機器に問合せが行われ
、従来の機器の基本性能セットを判定する。上述のように、ＨＡＶＩ準拠機器は
ＨＡＶＩにより定められた共通プロトコルを使用する。従来の機器は、典型的に
は専用プロトコルを用いて外部機器（もし、あれば）と通信を行う。ステップ１
６０３において、プロセス１６００が共通プロトコルからの基本コマンドセット
を、従来の機器の基本性能セットにマップする。ステップ１６０４において、従
来の機器用のレベル１ＤＣＭが生成される。上述のように、ＤＣＭは基本コマン
ドセットに基づくものである。ステップ１６０５及び１６０６において、レベル
１ＤＣＭを介して従来の機器が連続的にアクセスされ、他のＨＡＶＩ機器が従来
の機器の基本性能セットにアクセスすることが可能となる。

【０１３７】ＦＩＧ．１７Ａは、本発明を適用したプロセス１７００のフローチャートを示
す図である。プロセス１７００は、外部サービスプロバイダからのアプリケーシ
ョンプログラムを用いてホームオーディオ／ビデオネットワーク内の機器を制御
する方法の各ステップを示す。ステップ１７０２において、サービスプロバイダ
によりアプリケーションプログラムが生成される（例えばケーブルテレビジョン
、インターネットウェブサイト等を介して）。ステップ１７０３において、サー
ビスプロバイダが、論理チャンネルを介してサービスプロバイダからＨＡＶＩネ
ットワークのインテリジェントレシーバ／デコーダ機器にアプリケーションプロ
グラムを送る。そして、アプリケーションはインテリジェントレシーバ／デコー
ダ機器のコンピュータ読み取り可能メモリユニットに設けられる。

【０１３８】ＦＩＧ．１７Ａのステップ１７０４において、アプリケーションプログラムが
機器（例えばＦＡＶ機器）のＨＡＶＩレジストリに問合せを行ってネットワーク
上のＤＣＭの位置を検出するとともに、レジストリからの各ＤＣＭを選択する。
ステップ１７０５において、ダウンロードされたアプリケーションが、選択され
たＤＣＭからの通信ポイント情報を判定する。ステップ１７０６において、アプ
リケーションが、通信ポイント情報を用いて各機器と通信を行うことにより、Ｈ
ＡＶＩネットワークの各機器を制御する。ステップ１７０７において、アプリケ
ーションが別の機器を制御する必要がある場合、ステップ１７０４〜１７０６を
繰り返す。アプリケーションが別の機器を制御する必要がない場合、プロセス１
７００はステップ１７０８において終了する。

【０１３９】ＦＩＧ．１７Ｂは、ＦＩＧ．１７Ａのプロセス１７００に基づいたサービスプ
ロバイダ１７２０を有するＨＡＶＩネットワーク１７５０を示す図である。上述
のように、アプリケーションプログラムはサービスプロバイダ１７２０からＨＡ
ＶＩネットワーク１７５０にダウンロードされる。アプリケーションは、インテ
リジェント機器（例えばセットトップボックス３０１）のプロセッサ６０１及び
メモリ６０２に設けられる。また、ＨＡＶＩネットワーク１７５０は、機器０〜
機器３（例えばテレビジョン受像機、ＤＶＴＲ等）の４つのＨＡＶＩ機器を備え
ている。

【０１４０】ＤＣＭ管理ＡＰＩ本発明を適用したＤＣＭ管理ＡＰＩの具体例を以下に示す。この具体例では、
共通ＤＣＭコマンドが、接続管理、機器及びそのプラグに関する情報及び状態の
問合せ等のエリアを含む。ＤＣＭにより表される機器の種類に関わらず、このよ
うなメッセージセットをサポートする必要がある。

【０１４１】以下、この具体例において全てのＤＣＭがＨＡＶＩアーキテクチャのためにサ
ポートする必要があるＤＣＭ管理メッセージのリストを示す。 ChannelUsage(plug);//returns the 1394 isoch. channel used by the specifi
ed unit plug（特定ユニットプラグにより使用される１３９４アイソクロノスチ
ャンネルをリターン） PlugUsage(channel);//returns the plug associated with the specified chan
nel（特定チャンネルに関連するプラグをリターン） GetDevicePlugCount(count);//returns the number of unit plugs on the devi
ce（機器のユニットプラグ数をリターン） EstablishInternalConnection(sourcePlug, destPlug); EstablishExternalConnection(sourcePlug, destPlug) StartDataFlow(plug); StopDataFlow(plug); GetSourceConnection(in dest, out source);//given a destination plug, ret
urn the source to which it is connected (return the source plug of the t
ransmitting device which shares the same isoch. channel)（デスティネーシ
ョンプラグが与えられたら、それが関連するソースをリターン（同じアイソクロ
ノスチャンネルを共用する送信機器のソースプラグをリターン）） GetDestinationConnection(in source, out); GetAllConnection(); NotifyOnConnectionChange(); GetDynamicConnectionCapability();//report whether the target device supp
orts dynamic connection changes or not （目的の機器が動的な接続変更をサポートするか否かを報告）（例えば非１３９４機器） LockConnection(plug); UnlockConnection(plug); GetConnectionStatus(plug);//status = busy, data transmission format, cha
nnel, 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 signa
ls（出力信号について上記を繰り返す） GetFunctionInfo();//return information about the functional modules with
in 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 a
s 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 con
trollable power states（機能モジュールはそれぞれ制御可能なパワー状態を有
してもよい） SetPowerState(powerState); GetSupportedPowerStates(list); GetSupportedDataFormats(list);//returns the data formats supported by th
is functional module（機能モジュールによりサポートされるデータフォーマッ
トをリターン） NativeCommand(params);//send the functional module a command in its nati
ve 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 str
uctures 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 st
ructures eg layout commands for block-structures（controlTYPEは、ブロック構造のためのレイアウトコマンド等の制御タイプ及びサブタイプ構造を定義す
る）

【０１４８】ユーザインターフェースについて、汎用的で単純なＵＩとしてはＦＩＧ．１２
Ａに示すようにテキストベースのものであってもよい。ＤＣＭ特殊化に基づく、
より複雑なユーザインターフェースとしては、ＦＩＧ．１２Ｂに示すようなもの
であってもよい。ＳＤＤに保持されるグラフィック情報は、汎用ＤＣＭを特殊化
するために使用される。

【０１４９】したがって、本発明は、ホームネットワークにおけるインタオペレーションを
行うＣＥ（民生用電子）機器のためのオープンアーキテクチャを定義するホーム
オーディオビジュアル（ＡＶ）ネットワークを提供する。本発明のインタオペラ
ビリティは、いずれのメーカのＣＥ機器であっても、ユーザの家庭用ＡＶシステ
ム内でシームレスにインタオペレーション及び機能を行うことができるようにす
るアーキテクチャモデルを定義する。本発明のシステムでは、新たな特徴と新た
なＣＥ機器がホームＡＶネットワーク内に配置されるので、汎用デバイス制御の
基本セットと、基本制御プロトコルを拡張する方法とを組み合わせる。この際、
本発明のアーキテクチャは拡張可能であり、市場のニーズと技術の変化に伴って
容易に変更や改良を行うことができる。

【０１５０】上述の本発明の実施例は例示及び説明を目的とするものである。これら実施例
は、本発明を開示された形式通りに限定するものではなく、上述の教示を考慮し
て種々の変更が可能である。実施例については、本発明の原理及びその実施形態
を最適に説明することにより、当該分野の他の技術者が本発明及び特定用途に合
うように種々の変更を加えた種々の実施例を用いることができるようにするため
に、選択及び説明を行った。本発明の範囲は、添付の請求の範囲及びそれに相当
するものにより定義されるものとする。

【図面の簡単な説明】

本発明について、添付の図面において限定するのではなく、具体例を用いて説
明するが、図中、同様の構成要素には同様の参照番号を付してある。

【図１】ＦＩＧ．１Ａは、本発明を適用したホームＡＶネットワークの具体例を示す図
である。

【図２】ＦＩＧ．１Ｂは、ＦＩＧ．１ＡのＨＡＶＩネットワークの論理バス構成を示す
図である。

【図３】ＦＩＧ．２は、本発明を適用したピアツーピア２ＩＡＶ（中間オーディオビデ
オ）ノードネットワークの具体例を示す図である。

【図４】ＦＩＧ．３は、本発明を適用した単一ＦＡＶ（フルオーディオビデオ）クラス
タＨＡＶＩネットワークの具体例を示す図である。

【図５】ＦＩＧ．４は、ＩＡＶピアツーピアＨＡＶＩネットワークと統合したＦＡＶク
ラスタを示す図である。

【図６】ＦＩＧ．５は、多数のＦＡＶを有するＨＡＶＩネットワークの具体例を示す図
である。

【図７】ＦＩＧ．６は、本発明を適用したセットトップボックスの具体例を示す図であ
る。

【図８】ＦＩＧ．７は、本発明を適用したＨＡＶＩアーキテクチャの具体的な論理ブロ
ック図である。

【図９】ＦＩＧ．８は、本発明を適用したＨＡＶＩアーキテクチャの具体的なレイヤ論
理図である。

【図１０】ＦＩＧ．９は、具体的なＨＡＶＩアーキテクチャにおけるローカル及びリモー
トメッセージングを示す図である。

【図１１】ＦＩＧ．１０は、具体的なＨＡＶＩアーキテクチャにおける１３９４を介して
送られるメッセージを示す図である。

【図１２】ＦＩＧ．１１は、具体的なＨＡＶＩアーキテクチャにおける他のアプリケーシ
ョンを呼び出すアプリケーションを示す図である。

【図１３】ＦＩＧ．１２Ａは、機器（例えばカムコーダ）のためのＵＩ表示（例えばテレ
ビジョン受像機の画面）の第１の具体例を示す図である。

【図１４】ＦＩＧ．１２Ｂは、機器（例えばカムコーダ）のためのＵＩ表示（例えばテレ
ビジョン受像機の画面）の第２の具体例を示す図である。

【図１５】ＦＩＧ．１３は、本発明を適用した各機器に記憶されたＳＤＤ情報を用いて、
ＨＡＶＩネットワークにおける複数の機器のシームレスなインタオペラビリティ
及び統合を与える処理を示すフローチャートである。

【図１６】ＦＩＧ．１４は、本発明を適用したＨＡＶＩネットワークにおける複数の機器
間の基本コマンド機能及び拡張コマンド機能を与える処理を示すフローチャート
である。

【図１７】ＦＩＧ．１５は、本発明を適用したＨＡＶＩネットワークにおける機器の将来
的なグレードアップ性及び拡張性を確保する処理を示すフローチャートである。

【図１８】ＦＩＧ．１６は、本発明を適用したＨＡＶＩネットワークにおける従来の機器
とＨＡＶＩ準拠機器とのシームレスなインタオペラビリティ及び統合を与える処
理を示すフローチャートである。

【図１９】ＦＩＧ．１７Ａは、本発明を適用した外部サービスプロバイダからのアプリケ
ーションプログラムを用いて、ホームオーディオ／ビデオネットワークにおける
機器を制御する処理を示すフローチャートである。

【図２０】ＦＩＧ．１７Ｂは、ＦＩＧ．１７Ａの処理プロセスに基づいたサービスプロバ
イダを有するＨＡＶＩネットワークを示す図である。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号ＦＩテーマコート゛(参考）Ｈ０４Ｑ 9/00 ３２１Ｈ０４Ｎ 5/91 Ｌ (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ) ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ，ＹＵ，ＺＷＦターム(参考） 5B076 BB06 EB02 5B089 GA23 GB01 GB03 HA18 JA07 JB07 KA09 KA10 KB06 5C053 FA21 FA23 GB11 LA01 LA06 LA11 LA14 LA15 5K048 BA02 DA05 DC04 5K061 AA03 BB06 BB07 BB19 FF01 FF11 GG09 JJ06 JJ07 【要約の続き】ボックス）を介してアプリケーションをダウンロードすることができると共にアプリケーションがネットワーク内で特徴及びサービスを提供するメカニズムを提供する。これらのアプリケーションは、サービスプロバイダから得られ、論理チャネル（例えば、インターネット／ＴＶケーブル、衛星放送）を介して民生用機器に転送され、ネットワーク内のインテリジェントデバイスに設けられる。アプリケーションは、ＤＣＭのレジストリに質問を行って、その機能を判定することができると共に、使用可能なＤＣＭを用いてネットワークの機器を最終的に制御することができる。

Claims

【特許請求の範囲】

【請求項１】ホームオーディオ／ビデオネットワークにおける機器の制御方
法であって、ａ）サービスプロバイダにてアプリケーションプログラムを作成する工程と、ｂ）上記サービスプロバイダからの上記アプリケーションプログラムを上記ホ
ームオーディオ／ビデオネットワークのインテリジェントデバイスに通信する工
程と、ｃ）上記アプリケーションプログラムを上記インテリジェントデバイスのコン
ピュータ読み取り可能メモリユニットに配置する工程と、ｄ）上記アプリケーションプログラムが、上記ホームオーディオ／ビデオネッ
トワークにおいてサポートされる複数のデバイスコントロールモジュールのリス
トを有するネームレジストリに対して質問を行い、各デバイスコントロールモジ
ュールについての通信ポイントを得る工程と、ｅ）上記アプリケーションプログラムが、上記ホームオーディオ／ビデオネッ
トワークの各機器が関連付けられた各デバイスコントロールモジュールに対して
コマンドを送ることにより、上記各機器を制御する工程とを有することを特徴と
する方法。
【請求項２】上記インテリジェントデバイスはインテリジェントレシーバ／
デコーダであり、工程ｅ）にて、上記アプリケーションプログラムが、上記ホー
ムオーディオ／ビデオネットワークの複数機器の各機器を制御することを特徴と
する請求項１記載の方法。
【請求項３】上記各機器はローカルバスを介して上記インテリジェントデバ
イスに接続されることを特徴とする請求項１又は請求項２記載の方法。
【請求項４】上記インテリジェントデバイスはセットトップボックスである
ことを特徴とする請求項１又は２記載の方法。
【請求項５】上記ホームオーディオ／ビデオネットワークは、ローカルバス
に接続された複数の民生用電子機器を有し、上記方法は、上記ホームオーディオ
／ビデオネットワークにおける上記機器を制御する方法であり、工程ｄ）及びｅ
）にて、上記各機器は、上記アプリケーションプログラムがネームレジストリに
質問を行って上記第１のデバイスコントロールモジュールの通信ポイントを得る
ような第１の機器であり、上記ネームレジストリは、上記ホームオーディオ／ビ
デオネットワークにおける上記機器をサポートする複数のデバイスコントロール
モジュールのリストを有し、上記アプリケーションプログラムは、上記ホームオ
ーディオ／ビデオネットワークの上記第１の機器が関連付けられた上記第１のデ
バイスコントロールモジュールに対してコマンドを送ることにより、上記第１の
機器を制御することを特徴とする請求項１記載の方法。
【請求項６】上記アプリケーションプログラムが、上記ネームレジストリに
対して質問を行い、第２のデバイスコントロールモジュールについての通信ポイ
ントを得る工程と、上記アプリケーションプログラムが、上記ホームオーディオ
／ビデオネットワークの第２の機器が関連付けられた第２のデバイスコントロー
ルモジュールに対してコマンドを送ることにより、上記第２の機器を制御する工
程とを、さらに有することを特徴とする請求項５記載の方法。
【請求項７】上記ホームオーディオ／ビデオネットワークは、家庭用オーデ
ィオ／ビジュアルイニシアチブ（ＨＡＶＩ）アーキテクチャのネットワークであ
ることを特徴とする請求項１、２又は５記載の方法。
【請求項８】上記ローカルバスはＩＥＥＥ１３９４標準のものであることを
特徴とする請求項３又は７記載の方法。
【請求項９】上記インテリジェントデバイスはインテリジェントレシーバ／
デコーダ（ＩＲＤ）機器であることを特徴とする請求項５項記載の方法。
【請求項１０】上記インテリジェントデバイスはデジタルテレビジョンである
ことを特徴とする請求項５記載の方法。
【請求項１１】上記サービスプロバイダはケーブルテレビジョンプロバイダで
あることを特徴とする請求項５記載の方法。
【請求項１２】上記サービスプロバイダは衛星放送プロバイダであることを特
徴とする請求項５記載の方法。
【請求項１３】ローカルバスアーキテクチャと、上記ローカルバスアーキテクチャに接続された複数の機器であって、上記複数
の機器のうちの１つのが、プロセッサと、バスと、コンピュータ読み取り可能メ
モリユニットとを有するインテリジェントデバイスである機器とを有し、上記インテリジェントデバイスが、サービスプロバイダから得られるアプリケ
ーションプログラムを受け取り、上記インテリジェントデバイスの上記コンピュ
ータ読み取り可能メモリユニットに上記アプリケーションプログラムを配置し、上記アプリケーションプログラムが、上記ローカルバスアーキテクチャに接続
された上記複数の機器をサポートする複数のデバイスコントロールモジュールの
リストを有するネームレジストリに対して質問を行い、第１のデバイスコントロ
ールモジュールについての通信ポイントを得て、上記アプリケーションプログラムが、さらに、上記複数の機器のうちの第１の
機器が関連付けられた上記第１のデバイスコントロールモジュールに対してコマ
ンドを送ることにより、上記第１の機器を制御することを特徴とするホームオー
ディオ／ビデオネットワーク。
【請求項１４】上記アプリケーションプログラムが、上記ネームレジストリ
に対して質問を行い、第２のデバイスコントロールモジュールについての通信ポ
イントを得ると共に、上記アプリケーションプログラムが、上記複数の機器のう
ちの第２の機器が関連付けられた第２のデバイスコントロールモジュールに対し
てコマンドを送ることにより、上記第２の機器を制御することを特徴とする請求
項１２記載のホームオーディオ／ビデオネットワーク。
【請求項１５】上記ローカルバスアーキテクチャはＩＥＥＥ１３９４標準の
ものであることを特徴とする請求項１３記載のホームオーディオ／ビデオネット
ワーク。
【請求項１６】上記インテリジェントデバイスはインテリジェントレシーバ
／デコーダ（ＩＲＤ）機器であることを特徴とする請求項１３記載のホームオー
ディオ／ビデオネットワーク。
【請求項１７】上記インテリジェントデバイスはデジタルテレビジョンであ
ることを特徴とする請求項１３記載のホームオーディオ／ビデオネットワーク。
【請求項１８】上記サービスプロバイダはインターネットウェブサイトであ
り、上記サービスプロバイダと上記インテリジェントデバイスがインターネット
を介して接続されることを特徴とする請求項１３記載のホームオーディオ／ビデ
オネットワーク。
【請求項１９】上記サービスプロバイダはケーブルテレビジョンプロバイダ
であることを特徴とする請求項１３記載のホームオーディオ／ビデオネットワー
ク。