JP3977596B2 - ネットワーク環境内の自律媒体装置を制御し、自律媒体装置間のデータフロー及びデータフォーマットを管理する媒体管理装置 - Google Patents

Description

【０００１】
発明の分野
本発明はネットワーク環境内のアプリケーション及び装置を管理する分野に関する。詳しくは、本発明は、ネットワーク環境内の装置の動作及び装置間の通信を管理する分野に関する。
【０００２】
発明の背景
ＩＥＥＥ１３９４規格（１９９５年版）、すなわち「高性能シリアルバスに対するＩＥＥＥ１３９４規格（１９９５年版）」は、非同期フォーマットのデータ転送とアイソクロノスフォーマットのデータ転送（asynchronous and isochronous format data transfer）の両方をサポートする安価な高速のシリアルバスアーキテクチャを実現する国際規格である。アイソクロノスデータ転送は、リアルタイム転送であり、送信アプリケーションと受信のアプリケーションの両方における重要なインスタンス（significant instance）間の時間間隔（time interval）が同じ継続時間（duration）を有する。アイソクロノス的に転送されるデータの各パケットは、それ自身が有する周期（period）で転送される。データのアイソクロノス的な転送の理想的なアプリケーションの具体例としては、ビデオレコーダからテレビジョン受信機へのデータ転送がある。ビデオレコーダは、映像及び音声を記録するとともに、データを離散的な固まり（chunk）、すなわちパケットとして保存する。そして、ビデオレコーダは、記録された映像及び音声を表す各パケットを、テレビジョン受信機での表示によって制限される周期で転送する。ＩＥＥＥ１３９４標準バスアーキテクチャ（１９９５年版）は、アプリケーション間のアイソクロノスデータ転送のために多重チャネル（multiple channel）を提供する。適切なアプリケーションによって確実に受信されるように、６ビットのチャネル番号が、データとともに報知される。これによって、複数のアプリケーションは、アイソクロノスデータをバス構造を介して同時に転送することができる。非同期転送は、伝統的なデータ転送動作であり、転送元から転送先に大量のデータを、できるだけ速く転送するものである。
【０００３】
ＩＥＥＥ１３９４規格（１９９５年版）は、ディジタル機器を相互接続する高速シリアルバスを提供するとともに、汎用のＩ／Ｏ接続を提供する。ＩＥＥＥ１３９４規格（１９９５年版）は、アプリケーションのディジタルインターフェースを定義するものであり、これによって、アプリケーションは、ディジタルデータをバスを介して転送する前に、アナログデータに変換する必要がない。同様に、受信アプリケーションは、バスからアナログデータでなく、ディジタルデータを受信するので、アナログデータをディジタルデータに変換する必要なない。ＩＥＥＥ１３９４規格（１９９５年版）によって規定されるケーブルは、そのような機器を接続するために用いられている他の嵩張ったケーブルと比較して、サイズが非常に細い。ＩＥＥＥ１３９４規格（１９９５年版）のバスが活線状態においても、機器を取り付けたり、取り外したりすることができる。機器が取り付けられたり、取り外されたりすると、バスは、それ自体を自動的に再構成し、既存のノード間でデータを転送する。ノードは、バス構造上の固有のアドレスを有する論理構成体（logical entity）とみなされる。各ノードは、認識ロム（identification ROM）、標準化された制御レジスタ（control register）とそれ自身のアドレス空間（address space）のセットを有する。
【０００４】
媒体装置（media device）は、ネットワークインターフェイスを備えており、媒体装置は、このネットワークインターフェイスを介して、例えばＩＥＥＥ１３９４規格（１９９５年版）シリアルバスネットワークに接続される。このような自律的媒体装置を備える家庭用オーディオ／ビデオネットワークにおいては、１又は複数の媒体装置をネットワーク内のパーソナルコンピュータ、セットトップボックス、又はマイクロプロセッサを備えるその他の装置に接続することができる。このようなネットワーク環境内において、自律的装置間の相互動作及び処理を効率的に管理するためのインターフェイス及びアプリケーションは未だ提案されていない。すなわち、ネットワーク環境内の制御装置により、ネットワークにおける装置間の通信及び装置の動作を効率的に制御するためのインターフェイスの実現が望まれている。さらに、ネットワーク環境内の制御装置により、ネットワークにおける各装置の処理能力を最大限に活用してタスク及び処理を実行するためのインターフェイスの実現が望まれている。
【０００５】
発明の開示
媒体管理装置は、ネットワーク内で相互に接続された装置間のデータフローを管理し、及び装置内のクライアントアプリケーションのためのその他のサービスを提供する。好ましくは、これら装置は、ＩＥＥＥ１３９４規格（１９９５年版）シリアルバスネットワークにより接続される。使用可能な各装置に対応して生成された装置制御モジュールは、その装置用の適切な制御プロトコル、物理的接続、接続能力等を含むその装置の全ての能力及び要求の抽象化（abstraction）を提供する。媒体管理装置は、ネットワーク上の装置間のデータフロー及びデータのフォーマットを管理する。インターフェイスを介して、ユーザは媒体管理装置にアクセスし、ネットワークに接続されている装置により実行される機能を制御する。適切な装置が使用可能な場合、媒体管理装置は、要求されたタスクの遂行を制御及び管理する。適切な装置が存在せず、複数の装置に亘る複数の下位装置が必要な場合、媒体管理装置は、複数の装置に亘る複数の下位装置から仮想装置を構築し、仮想装置は、これにより要求された所定の機能を実現するタスクを実行する。適切な装置及び下位装置をタスクに割り当てた後、媒体管理装置は、伝送すべきデータのフォーマットを他のフォーマットに変換する必要があるか否かを判定する。媒体管理装置は、必要に応じて、データ伝送処理におけるデータ変換処理を制御する。媒体管理装置は、ネットワーク列挙及びレジストリ検索機能を有し、これによりクライアントアプリケーションは、使用可能なサービス、物理的装置及び仮想装置を検出することができる。
【０００６】
発明の好適な実施の形態の詳細な説明
本発明を適用した媒体マネージャは、ネットワーク内の物理的装置におけるデータフローの管理及びその他のサービスを提供する。物理的装置とは、製造業者から単独の製品として販売されているような製品を指す。物理装置の例としては、テレビジョン受像器、ビデオテープレコーダ、パーソナルコンピュータ、ビデオカメラ、ＣＤ−ＲＯＭプレーヤがある。この他にも、多くの物理的装置が知られており、販売されている。各物理的装置は、下位装置（subdevice）を備える。例えば、市販されているビデオカメラは、カメラ及びビデオプレーヤ等、異なる機能を有する複数の下位装置を備えている。
【０００７】
これらの物理的装置は、好ましくは、ＩＥＥＥ１３９４規格（１９９５年版）シリアルバスネットワークを介して相互接続される。各装置及び下位装置を制御するためのデバイス制御モジュール（device control module：以下、ＤＣＭという。）が設けられている。各ＤＣＭは、適切な制御プロトコル、物理的接続端子及び接続能力等を含むの各物理的装置の性能及び要求に関する抽象化情報（abstraction）を提供する。媒体マネージャは、ネットワーク内の物理的装置間のデータ転送処理におけるフロー及びフォーマットを管理する。この処理には、例えば、データ伝送処理時にデータを他のフォーマットに変換する処理等が含まれる。
【０００８】
ユーザは、インターフェイスを介して、媒体マネージャにアクセスし、ネットワーク内の物理的装置を用いて遂行される機能及びタスクを実行する。適切な物理的装置が存在し、他には使用されていない場合、媒体マネージャは要求されたタスクを制御及び管理する。一方、適切な物理的装置が存在しない場合、媒体マネージャは、存在する下位装置又は装置内のコンポーネントから仮想装置（virtual device）を構築し、要求されたタスクを遂行する。適切な物理的装置及び／又は下位装置がタスクに割り当てられると、媒体マネージャは、伝送すべきデータのフォーマットについて、送信側の装置のフォーマットから受信側の装置のフォーマットに変換する必要があるか否かを判定する。変換処理が必要な場合、媒体マネージャは、データ伝送処理とともに、この変換処理も制御する。
【０００９】
図１は、ネットワークの具体例を示す図であり、このネットワークは、ＩＥＥＥ１３９４規格（１９９５年版）ケーブル１５，１６，１８を介して相互接続されたビデオカメラ１０と、ビデオテープレコーダ１２と、コンピュータ１４と、セットトップボックス１３と、テレビジョン受像機１１とを備える。ＩＥＥＥ１３９４規格（１９９５年版）ケーブル１６は、ビデオカメラ１０をビデオテープレコーダ１２に接続し、これによりビデオカメラ１０は、ビデオテープレコーダ１２に供給し、記録させることができる。ＩＥＥＥ１３９４規格（１９９５年版）ケーブル１８は、ビデオテープレコーダ１２をコンピュータ１４に接続し、これによりビデオテープレコーダ１２は、コンピュータ１４に供給して表示させることができる。ＩＥＥＥ１３９４規格（１９９５年版）ケーブル１５は、セットトップボックス１３をコンピュータ１４に接続している。また、セットトップボックス１３は、ケーブル１７を介してテレビジョン受像機１１にも接続されている。
【００１０】
図１に示す構成は、単に例示的なものである。オーディオ／ビデオネットワークは、多数の物理的構成要素を組み合わせて様々に構成できることは明らかである。このようなＩＥＥＥ１３９４規格（１９９５年版）ネットワーク内の物理的装置は、自律的装置であり、すなわち、図１に示すようなＩＥＥＥ１３９４規格（１９９５年版）ネットワークにおいて、コンピュータ１４は、複数の装置のうちの１つに過ぎず、コンピュータ１４と他の装置との間に真の意味での「マスタ−スレーブ」の関係はない。多くのＩＥＥＥ１３９４規格（１９９５年版）ネットワークにおいては、コンピュータは接続すらされていない。このような環境でも、ネットワーク内の装置は、それぞれ一対一の関係で相互動作（インタラクト）することができる。
【００１１】
本発明を適用した媒体マネージャを実現する管理装置のハードウェア構成を図２に示す。図２に示す管理装置は、ユーザインターフェイス３０に接続されたプリント管理基板２０を備える。プリント回路基板２０は、中央演算処理装置（central processing unit：以下、ＣＰＵという。）２２を備え、ＣＰＵ２２は、システムバス２８を介して、システムメモリ２４及びＩ／Ｏバスインターフェイス２６に接続されている。ここでは、「ＣＰＵ」という語を用いるが、これは、このシステムが汎用演算回路でなくてはならいことを意味するものではない。すなわち、この回路は、汎用コントローラであってもよく、専用コントローラであってもよい。システムバス２８は、ユーザインターフェイス３０にも接続されている。ユーザインターフェイス３０は、サブシステム毎に異なるものであるが、好ましくは少なくとも赤外線遠隔制御装置及び表示装置を備えているとよい。また、ユーザインターフェイス３０は、このサブシステムのユーザと通信するためのその他の入出力装置を備えていてもよい。
【００１２】
本発明の好適な実施の形態においては、媒体マネージャは、ユーザとの円滑なインタラクションを実現するために、テレビジョン又はディスプレイを備えるコンピュータ内に設けられる。しかしながら、本発明を適用した媒体マネージャは、ユーザへのインターフェイスを提供するために必要な構成要素を備えるその他のいかなる装置内に設けてもよい。本発明に基づく媒体マネージャを実現するために、媒体マネージャを実装するコンポーネントは、それぞれ図２に示すようなハードウェア構成を備えている。このような装置内に設けられたＣＰＵ２２は、アプリケーションプログラムの実行のために用いられる。本発明に基づく媒体マネージャは、ネットワーク内の通信及び処理の管理に使用される。ユーザは、制御装置に設けられたインターフェイスを介して、媒体マネージャにアクセスする。このインターフェイスにより、ユーザは、ネットワーク及びネットワーク内の装置の動作及び状態を監視することができる。さらに、ユーザは、このインターフェイスを介して、装置を制御し、所定の機能を実現するためのタスクを要求して遂行させることができる。このようなタスクの例としては、ビデオテープレコーダ１２内のビデオテープの再生や、ビデオテープレコーダ１２からテレビジョン受像機１１にデータを供給させて映像を表示させる処理等がある。本発明に基づく媒体マネージャは、各装置におけるデータの伝送処理及び要求されたタスクを管理する。
【００１３】
図３は、本発明に基づく媒体マネージャプラットフォームのアーキテクチャを示す図である。このアーキテクチャは、いわゆる上位部（upper portion）３２と、下位部（lower portion）３４とに分割される。下位部３４は、好ましくは、ＩＥＥＥ１３９４規格（１９９５年版）バスインターフェイスと、もっとも広く普及している民生用のオペレーティングシステムをサポートする機能とを有している。上位部３２は、下位にあるＩＥＥＥ１３９４規格（１９９５年版）バスサポート及びアドインの特徴及び機能をクライアントアプリケーションに、したがってユーザに提供するためのコンポーネントを備える。上位部３２は、ブロック４６及びブロック４８を有し、ブロック４６は、より高度なＩＥＥＥ１３９４規格（１９９５年版）バスサポートのための設計及び実装を提供し、ブロック４８は、様々なクライアントアプリケーションへのインターフェイスを司る。下位部３４は、ブロック４０，４２，４４を有し、これらはそれぞれ広く普及しているオペレーティングシステムであるウィンドウズ９５（商標）、マッキントッシュＯＳ（商標）、アペリオス（商標）に対するサポートを提供する。また、ＯＳ９等のいかなる汎用オペレーティングシステムをサポートするようにしてもよい。さらに、下位部３４は、ＩＥＥＥ１３９４規格（１９９５年版）サポートの共通層（common layer）を提供するブロック３８及び制御装置に接続された他の装置への実際の物理的なＩＥＥＥ１３９４規格（１９９５年版）バスインターフェイスとして機能するブロック３６とを備える。
【００１４】
この媒体マネージャプラットフォームは、オープンで柔軟性の高いアーキテクチャを提供し、これによりネットワーク内においてパーソナルコンピュータとその他の自律的装置とを効率的に一体化し、これら装置間のデータ伝送を効果的に管理する。この媒体マネージャプラットフォームの下位部３４は、最下層における基盤的な技術をサポートするように設計されており、この下位部３４により、上位のレベルは、より汎用性の高いモジュール及び機能記述（functional description）をサポートすることができる。
【００１５】
図４は、本発明に基づく媒体マネージャプラットフォームのアーキテクチャをより詳細に示す図である。マルチメディア又はユーザレベルアプリケーション４８は、このアーキテクチャの最上位に位置し、媒体マネージャにより提供されるサービスを利用する。マルチメディアアプリケーション４８は、本発明に基づく媒体マネージャプラットフォームのアプリケーション又は他のクライアントである。媒体マネージャ内の構成コンポーネントは、プロトコルの詳細を管理し、同様のプログラミングインターフェイスをアプリケーション４８に提供する。タイミング、バッファ管理、バス管理、通信プロトコル等は、これらの単純な機能インターフェイスの背後に隠されている。アプリケーション４８は、このアーキテクチャにおける下位の層に対するアクセスを有し、さらに、当然のことながら、ハードウェア適応層（hardware adaptation layer：ＨＡＬ）及びホストオペレーティングシステム５８と直接通信を行うことができる。ホストオペレーティングシステム５８は、カメラ１０、ビデオテープレコーダ１２、セットトップボックス１３等のネットワーク内の他の装置に接続されている。この具体例においては、例示的に、本発明に基づく媒体マネージャの環境は、図１に示すコンピュータ１４内で実現されているものとする。
【００１６】
アプリケーションインターフェイスオブジェクト５０は、媒体マネージャ環境内において、クライアントアプリケーション４８の代理（proxy）として機能する。アプリケーションプログラミングインターフェイスにより、クライアントアプリケーション４８は、媒体マネージャの基本サービスにアクセスすることができる。任意のプログラミングインターフェイスにより提供されるより詳細な、又は特定の機能へのアクセスは、アプリケーションインターフェイスオブジェクト５０により実現され、すなわち、アプリケーションインターフェイスオブジェクト５０は、アプリケーション４８にローカルメッセンジャ５２へのアクセスを提供する。
【００１７】
ローカルメッセンジャ５２は、媒体マネージャに一体化されたメッセージングシステムのコンポーネントの一つである。好ましくは、このメッセージングシステムは、ＡＶメッセンジャシステム（AV Messenger system）とする。ローカルメッセンジャ５２は、与えられたノード上のオブジェクトが異なる実行スペース内に存在する場合に、これら全てのオブジェクト間の通信における中央ハブとして機能する。本質的には、ローカルメッセンジャ５２は、ホストオペレーティングシステム５８により提供されるアプリケーション間通信モデルである。ローカルメッセンジャ５２は、全てのソフトウェアモジュールがここを通過するボトルネックである。記録性（スクリプタビリティ（scriptability））を実現するために、ローカルメッセンジャ５２は、通過する全てのメッセージのログをとり、全てのメッセージ及びメッセージに関連するデータ、例えば転送先のアドレス、パラメータ、応答側のアドレス、または任意項目として時間に基づく記録（time-based scripting）のためのタイムスタンプ等のデータが登録されるデータベースを維持管理する。
【００１８】
サービスレジストリ５９は、媒体マネージャ７１内の全てのアドレス指定可能なエンティティへの参照情報を有している。また、サービスレジストリ５９は、デバイス制御モジュール（device control module：以下、ＤＣＭという。）５６、ＤＣＭマネージャ５４、データフローマネージャ６４、トランザクションマネージャ６６、バスマネージャ７０、グラフィックマネージャ７２のそれぞれへの参照情報を有している。さらに、サービスレジストリ５９は、後述する、任意の数のサービスモジュールを有している。さらに、サービスレジストリ５９は、そのノードにとってローカルである全てのオブジェクトへの参照情報と、リモートオブジェクトへの特定時刻参照情報とが格納されたサービスレジストリデータベースを有している。データベース内の各エントリは、アドレス指定可能なモジュールを参照し、添付された属性を含む。この属性の一部は、全てのエントリに共通のものであり、その他の属性はモジュールの種類に固有のものである。共通の属性とは、モジュールの名称及びローカルＩＤ等である。モジュールに固有の属性とは、モジュールの種類によって異なる属性である。サービスレジストリデータベースにエントリが登録されると、エントリに任意の数の属性を付加することができる。クライアントアプリケーションがデータベースを検索する場合、アプリケーションは一致すべき属性の組を特定し、サービスレジストリ５９は、データベースを検索して、アプリケーションが特定した条件に適合する全てのエントリを検出してアプリケーションに返す。この検索において、複数の候補が検出された場合、サービスレジストリ５９は、クライアントアプリケーション４８に参照情報のリストを提供する。クライアントアプリケーションは、リスト内の候補項目のそれぞれを調査し、どの項目が最も望ましいものであるかを判定する。
【００１９】
クライアントアプリケーション４８は、それぞれが異なる検索条件による検索の結果に基づく複数の未決定検索リスト（outstanding search list）を有する。使用可能な装置を変更するためのバスリセット等のイベントの発生に応じて、クライアントアプリケーション４８が検索リストを更新する必要がある場合、クライアントアプリケーション４８は、検索処理を呼び出す際に、サービスレジストリ５９にリスト参照情報を返す。これによりサービスレジストリ５９は、リストオブジェクトを削除して新たなリストオブジェクトを再割り当てするのではなく、現在のオブジェクトリストを更新することができる。
【００２０】
サービスモジュール６０を呼び出すことにより、一組のサービスを実行することができる。このサービスモジュール６０は、クライアントアプリケーションのために、例えばデータのフォーマット処理、転送処理、制御プロトコルの変換処理等の様々なサービスを実行する。
【００２１】
ＤＣＭマネージャ５４は、そのノード上の、又は制御装置ネットワーク内の装置用のＤＣＭ５６のグループを管理する。この管理には、与えられたシステムにおいて使用可能な全てのＤＣＭ候補の逆変換処理（disconverting）、インストール処理、削除処理等の処理を含む。さらに、ＤＣＭマネージャ５４は、必要に応じて、リモートのノード上の他のＤＣＭマネージャと通信を行い、ネットワーク全体の装置及び下位装置のリソースの割り当て及び管理の調停（arbitrate）を行う。
【００２２】
ＤＣＭマネージャ５４は、基盤となるオペレーティングシステムサービスと共に機能し、使用可能な装置ノードハンドル（device node handles）のそのままのリストを入手する。さらにＤＣＭマネージャ５４は、クライアントアプリケーション４８にアプリケーションプログラミングインターフェイスを提供し、これによりクライアントアプリケーション４８は、ネットワーク上の装置において、ＤＣＭ５６により示されているどの下位装置又はどのサービスが使用可能であるかを知ることができる。ＤＣＭ５６により、物理的装置、又は異なる複数の物理的装置の下位装置から構成される仮想装置を表すことができる。この他の使用可能なサービスは、後述する仮想ＤＣＭ５６により表すことができる。使用可能なＤＣＭ５６は、ＩＥＥＥ１３９４規格（１９９５年版）シリアルバス上で使用可能な物理的装置の変化に応じて、動的に変化する。
【００２３】
各ノードにおいて、ＤＣＭマネージャ５４は、ＤＣＭ５６を生成すべきか否かを判断するための十分な機能を有する。この判断は、媒体に関連する全ての装置に対して行われ、これら装置は本発明に基づく媒体マネージャにより管理される。媒体に関連する各エンティティに対し、ＤＣＭマネージャ５４は、汎用のＤＣＭ５６を生成する。各ＤＣＭ５６は、後述するように、さらに装置に応じて特化される。
【００２４】
製造業者により提供された装置固有のＤＣＭもＤＣＭ５６に追加することができる。装置固有のＤＣＭは、装置内の読出専用メモリ（ＲＯＭ）、又はディスク状又はテープ状記録媒体のヘッダ等のその他のデータ記録機構により実現される様々なソースから提供される。装置固有のＤＣＭは、媒体マネージャが適切な機能を有する場合、インターネットのサイトから、又はモデム接続を介して直接ダウンロードしてもよく、ディスク状記録媒体又は他の媒体から読み出してもよい。このような変形例は、１９９８年６月４日に出願された米国特許出願番号０９／０９２，７０３号、「自己記述情報を装置内に含ませるための方法及び装置（A METHOD AND APPARATUS FOR INCLUDING SELF-DESCRIBING INFORMATION WITHIN DEVICES）」に開示されており、この出願は参照により本願に含まれるものとする。
【００２５】
ＤＣＭマネージャ５４は、適切な時刻において、ＤＣＭ５６を追加及び削除し、及びクライアントに対してＤＣＭ５６が追加され、又は削除されたことを通知する機能を有する。さらにＤＣＭマネージャ５４は、複数のＤＣＭ５６間で行われる複雑なサービスを整理する（coordinating）機能を有する。例えば複雑な処理のコマンドのキュー等の複雑なサービスは、ＤＣＭマネージャ５４により処理順序を整理した後に、複数のＤＣＭ５６によりこれらの処理を実行させる必要がある。
【００２６】
ＤＣＭ５６は、装置制御のための標準化されたインターフェイスをクライアントアプリケーション４８に供給することにより、装置のモデリング及び制御プロトコルの抽象化（abstraction）サービスを提供する。ＤＣＭ５６により提供される装置制御のためのプログラミングインターフェイスは、共通Ａ／Ｖ制御と、装置固有Ａ／Ｖ制御とに分割される。共通Ａ／Ｖ制御コマンドは、オーディオ−ビジュアル機能を有する殆ど全ての装置に共通のコマンドである。例えば、再生、停止、早送り、巻き戻し等の基本的な制御コマンドは、この共通Ａ／Ｖ制御コマンドに含まれる。装置固有Ａ／Ｖ制御コマンドは、例えば記録機能を有する装置における録音（録画）機能等の与えられたＡ／Ｖ装置のカテゴリに共通するコマンド、及び特定のモデル又は装置のグループに特有のコマンドである。装置固有の機能に関する情報は、上述した自己記述データ情報を用いて、装置自身の内部に実装される装置固有ＤＣＭ内に構築してもよく、インターネットからソフトウェアアップグレードとしてダウンロードしてもよい。
【００２７】
本発明に基づく媒体マネージャは、プロトコルの抽象化（protocol abstraction）を行い、これは、使用されている装置及び制御プロトコルの種類にかかわらず、モジュールとアプリケーション間のプログラミングインターフェイスが同じであることを意味する。したがって、アプリケーションは、同じソースコード及びメッセージを使用し、これにより、ＩＥＥＥ１３９４規格（１９９５年版）に準拠するビデオカセットレコーダは、ビデオシステム制御アーキテクチャ（Video System Control Architecture：ＶＩＳＣＡ）規格のビデオカセットレコーダと同様の録画処理を行うことができる。これは、共通Ａ／Ｖ制御コマンド及びカテゴリに固有のＡ／Ｖ制御コマンドについても同様であり、特定の装置に特有の特徴は固有のプログラミングインターフェイスを有する。
【００２８】
ＤＣＭ５６は、装置の自己記述データをダウンロードし、ユーザに提示する機能を有する。この処理のために、ＤＣＭ５６は、モジュールをダウンロード及び統合することにより自己記述データを分析し、ホストアプリケーションを介してこの情報をユーザに提示する。これにより、ユーザは、媒体マネージャインターフェイスを介して、ネットワーク内の装置の周知の及び装置特有の機能を環境設定（configure）及び制御することができる。ユーザインターフェイスデータ及び装置のカスタマイズされた機能へのアクセスの好適な実現例は、１９９７年７月３０日出願の米国特許出願番号６０／０５４，１９９号、「ヒューマンインターフェイスの特徴及びＡＶ／Ｃを用いる装置の機能を記述する方法（METHOD FOR DESCRIBING THE HUMAN INTERFACE FEATURES AND FUNCTIONALITY OF AV/C-BASED DEVICES）」に開示されており、この出願は参照により本願に組み込まれるものとする。
【００２９】
ＤＣＭマネージャ５４及びＤＣＭ５６は、連携して、実行すべきＡＶコマンドのコマンドキューを行い、これによりＤＣＭ５６は、例えば装置の機械的な待ち時間として考慮すべきプレロール（pre-roll）の実行の必要性等、全ての装置の特性を取り扱うことができる。ＤＣＭマネージャ５４とＤＣＭ５６は、媒体マネージャの他の部分と連携して、特定の時刻に実行され、特定の状態を生じる装置制御動作を特定することができる。
【００３０】
ＤＣＭ５６は、本発明に基づく媒体マネージャの全アーキテクチャにおける大きな部分を占める。ＤＣＭ５６は、例えば制御プロトコル、物理的接続及び接続能力等、オーディオ−ビジュアル装置を構成する様々な技術の抽象化を提供する。ＤＣＭ５６は、物理的装置を表現するためではなく、特定のＡＶ処理を実行するための機能又はサービスの集合体からなる仮想装置を表現するために生成することもできる。
【００３１】
物理的装置及び下位装置は、それぞれ個別にアクセス可能なハードウェアである。本発明に基づく媒体マネージャは、アクセス可能な下位装置により、仮想装置をサポートし、装置のネットワークの性能を向上させる。仮想装置は、複数の使用可能なコンポーネントを組み合わせて形成された論理的エンティティである。好ましくは、仮想装置は、要求されたタスクの遂行に必要な場合に、自動的に生成される。これに代えて、ＤＣＭマネージャ５４からサービスを要求することにより、仮想装置を動的に生成するようにしてもよい。
【００３２】
「テレビジョンの視聴」、「映画の録画」又はＤＣＭ５６を用いた装置の操作を含むユーザにより定義されたあらゆる動作の組等の予め定義された動作をＡＶ動作（AV action）と呼ぶ。ＡＶ動作は、ユーザが後に再使用するために記録することができる。ＡＶ動作プログラミングインターフェイスにより、記録された番組を視聴したり、放送されている番組を視聴したり、記録テープに録音したり、コンパクトディスクを再生したりといった、ＡＶネットワーク内の装置により実行される共通動作をモデリングすることができる。例えば、ユーザの家の２階のベッドルームにビデオテープレコーダがあり、このビデオテープレコーダが現在、チューナからある放送を受信し、このベッドルーム内のテレビジョン受像機にその放送を表示させている場合、ビデオテープレコーダ内の転送機能は使用されていない。このとき、ユーザが録画された番組を１階で視聴したいと望んだ場合、本発明に基づく媒体マネージャは、このベッドルーム内のビデオカセットレコーダにビデオテープを挿入し、このビデオテープに録画されている番組を１階に設置してあるテレビジョン受像機で視聴することができる。録画された番組を表すデータは、２階のビデオテープレコーダからＩＥＥＥ１３９４規格（１９９５年版）シリアルバスを介して、１階のテレビジョン受像機に伝送される。このデータ伝送処理は、制御装置内の媒体マネージャにより制御される。チューナ、デマルチプレクサ、転送機構（transport）、プロセッサ及び他のコンポーネント及び下位装置により、仮想装置が構築され、同様の動作が実現される。したがって、ユーザは、媒体マネージャを用いてネットワーク内の装置の動作を制御することにより、これら装置の機能及び性能を最大化して活用することができる。
【００３３】
ＤＣＭマネージャ５４は、どの物理的装置及び下位装置が現在使用されているかを監視するのみではなく、現在使用可能なコンポーネント及び下位装置からどのような仮想装置が生成可能であるかを監視する。ＤＣＭマネージャ５４は、ローカルで管理している全ての装置及び現在実行しているホストプラットフォーム上で使用可能なソフトウェアサービスの全てについて、上述の処理を行う。ＤＣＭマネージャ５４は、クライアントアプリケーション４８にプログラミングインターフェイスを提供し、現在実行可能なＡＶ動作及びネットワーク上で使用可能なリソースに基づいて生成可能な仮想装置に関する問い合わせを行う。ＤＣＭマネージャ５４は、仮想装置がサービスレジストリ５９に適切なタイミングで追加されるようサービスレジストリ５９を管理する。
【００３４】
ＤＣＭ５６に提供されるアプリケーションプログラミングインターフェイスにより、クライアントアプリケーション４８は、ネットワーク上の装置において使用可能な特徴及び機能を検出し、必要に応じてこれら機能と連携して動作する。このプログラミングインターフェイスは、装置制御、装置管理、接続管理、自己記述装置の実現の管理等を含む。各ＤＣＭ５６は、管理している装置の種類を判定することにより、汎用ＤＣＭから装置又はプロトコル特有のＤＣＭへの変換を行う。この処理のために、ＤＣＭ５６は、存在する場合、装置における自己記述装置データを調査し、使用可能な他の情報を分析する。ＤＣＭ５６は、装置画像、製品名、他の装置及びコンポーネントへの機能記述子等、現在管理されている装置の自己記述装置情報データへのアクセスを提供する。ＤＣＭ５６は、例えばコマンドのキュー等の複雑なサービスを含む装置制御のための一貫したインターフェイスを提供する。これらのコマンドを実行するためには、プロトコル固有のコマンドのパッケージング、送信、処理及びプロトコルドライバを介する応答を含む装置制御プロトコルの使用のためのホストオペレーティングシステム５８及び他のオペレーシングシステムに提供されるサポート機構との連携が必要である。
【００３５】
さらに、各ＤＣＭ５６は、自らが制御している装置を監視し、必要なコンポーネント及びアプリケーションに拡張通知サービス（extended notification service）を提供する。装置により生成される全ての通常のイベントは、適切な装置のＤＣＭ５６を介して、イベントマネージャ６２及び全ての関係するクライアントアプリケーション４８に供給される。与えられた装置又は他の制御プロトコルでは、ＡＶ／Ｃ装置通知イベントに加えて、ＡＶ／Ｃプロトコルを明確にサポートしていない場合も多い。装置の性能及びその制御プロトコル及び通信プロトコルに応じて、実際のイベントメッセージをトリガしないようなイベントのための拡張的サポートを提供することもできる。ＤＣＭ５６は、この種の処理のために装置を監視し、イベントマネージャ６２にイベントを供給する。
【００３６】
各ＤＣＭ５６は、ＤＣＭ５６の制御の下で装置からのデータを利用する外部のエンティティ及びＤＣＭ５６を制御しているエンティティに関して自らを管理する。この管理には、共有しているリソース及びキューに存在するリソースのサポートを含む。リソースのキューにより、エンティティは、現在使用中のＤＣＭ５６を自ら使用するために予約することができる。ＤＣＭ５６が使用可能になると、そのことが直ちにエンティティに通知される。
【００３７】
ＤＣＭ５６は、環境の変化を管理し、これによりＤＣＭ５６及びクライアントは、オンライン状態及びオフライン状態の両方をサポートする。これにより、ＤＣＭ５６は、装置が再びオンライン状態になったときに、サービスを直ちに再確立（re-establish）することができる。
【００３８】
本発明に基づくメディアマネージャ内において、ＤＣＭ５６は、使用可能な装置及び下位装置を制御する。ＤＣＭ５６は、装置の汎用機能及び装置に固有の機能の両方へのアクセスを提供する。本発明に基づく変形例においては、各装置には、自己記述データの一部として、ＤＣＭが組み込まれ、これにより装置がどこに設置されるかに関わらず、そのソフトウェアが常に使用可能になる。さらなる変形例として、特定の装置用のＤＣＭは、その装置の製造業者又はサードパーティからインターネット又はフレキシブルディスク等の媒体装置を介して提供されるようにしてもよい。上述の各具体例において、ＤＣＭ５６は、ダウンロードされた後、様々な場所に保存される。ＤＣＭ５６は、好ましくは、そのＤＣＭ５６が制御する装置内に保存される。しかしながら、ＤＣＭ５６は、適切ないかなる場所に保存してもよい。本発明の変形例においては、ＤＣＭ５６は、ホストプラットフォームによりサポートされる、例えばジャバ（Java）又はジャバスクリプト（Java Script）等の共通バイト又は共通スクリプトコードフォーマットにより記述される。ＤＣＭ５６は、ホスト装置にアップロードされ、ホスト装置により実行される。
【００３９】
イベントマネージャ６２は、ネットワーク内の関係する全てのパーティにイベント通知（event notification）を同報送信する。イベントマネージャ６２は、そのノード内の全てのモジュールに対する中心のモジュールとして動作し、そのノードでイベントが発生したとき、通知を登録する。イベントマネージャ６２は、イベント通知リストデータ構造体を維持管理する。イベント通知リストは、定義されたイベントの種類及び各種類のイベントの通知を登録された全ての装置の転送先の識別子に関するリストである。各装置は、イベントマネージャ６２に対し、各装置が関心のあるイベントの種類に関するクライアントの識別子及びイベントメッセージが同報通信されたときに戻されるべきトークンの値を登録する。イベントとは、なんらかの動作の実際の発生及び複数の転送先にアドレス指定された装置からのメッセージである。
【００４０】
イベントマネージャ６２は、通常、イベントを生成せず、他のコンポーネントから媒体マネージャに供給されたイベントを受け取り、及び同報通信する。リモートノード内のクライアントアプリケーション４８にイベントを同報通信する場合、イベントマネージャ６２は、同報通信マネージャ７４を使用する。イベントマネージャ６２は、ユーザとの相互動作（インタラクション）に基づいて、適切な装置に情報を通知する。イベントマネージャ６２は、制御ソフトウェアレベルにおいて、インターフェイスを介してどのようなユーザ入力が発生したかをＤＣＭ５６に通知し、これによりＤＣＭ５６は、物理的装置を適切に制御する。装置をリモート位置から制御するＤＣＭ５６は、ユーザが何をしているかを示すメッセージを受け取る必要があり、及びその装置に適切なメッセージを送信する必要がある。イベントマネージャ６２は、メッセージングシステム及び周知のイベントメッセージを用いてリモートのＤＣＭ５６の処理実行をサポートする。定義されているイベントメッセージには、例えばネットワークに装置が追加された時に生成されるnew_deviceメッセージ等の装置管理（device administration）メッセージ及びユーザインタラクションメッセージが含まれる。ユーザインタラクションメッセージは、１９９７年７月３０日出願の米国特許出願番号６０／０５４，１９９号、「ヒューマンインターフェイスの特徴及びＡＶ／Ｃを用いる装置の機能を記述する方法（METHOD FOR DESCRIBING THE HUMAN INTERFACE FEATURES AND FUNCTIONALITY OF AV/C-BASED DEVICES）」に開示されている好ましいグラフィカルユーザインターフェイスモデルをサポートする。この出願は参照により本願に組み込まれるものとする。既に定義されているイベントメッセージに加えて、２つのＤＣＭ又はソフトウェアモジュールは、カスタムメッセージ及びプライベートメッセージを定義することができる。
【００４１】
グラフィックスマネージャ７２は、リモート装置の制御処理の制御アプリケーションへの組み込みを管理し、ＤＣＭ５６による自己記述データ情報の遠隔表現をサポートする。グラフィックマネージャ７２は、プログラミングインターフェイスを提供し、このプログラミングインターフェイスにより、ＤＣＭ５６は、画面領域の調停を行うことができ、共有されたグラフィック環境内で機能することができる。これにより装置は、制御ソフトウェアのインターフェイスを介してユーザに提示され、アクセス可能となる。
【００４２】
データフォーマットマネージャ６８は、装置間で送受されるデータのフォーマットを管理する。データフォーマットマネージャ６８は、装置内の媒体マネージャにプラグインすることができ、これによりバッファ管理及びデータフォーマット処理の一部としてデータフォーマットの変換を行う。データフォーマット処理の多くは、クライアントアプリケーションに代わって、データの転送元及び転送先に関する知識に基づいて、透過性を有する手法で実行される。この他のデータ変換処理は、クライアントアプリケーションがフォーマット変換処理をセットアップして行う。データ変換処理は、データの伝送中にオンラインで実行することが好ましい。これに代えて、フォーマット変換処理をデータ伝送処理の前段階のタスク又は後段階のタスクにより実行してもよい。与えられたプラットフォームにおいて使用できるデータ変換サービスは、サービスレジストリ５９に登録されている。このサービスレジストリ５９を用いたサービスの検出に加えて、データフォーマットマネージャ６８は、サービスモジュールをインスタント化（instantiating）し、これらサービスモジュールをサービスレジストリ５９に登録する。
【００４３】
データフローマネージャ６４は、バスマネージャ７０と連携して、転送元から転送先へのデータのルーティングを補助するサービスを提供する。転送元と転送先の間には多くのノードが存在していることがある。転送元の装置と転送先の装置とが異なるデータ種類を取り扱う場合、又は両者が障壁（barrier）により隔離されている場合、データフローマネージャ６４は、データフォーマットマネージャ６８及びサービスレジストリ５９と連携して、自動的な又は要求された変換サービスを同様に取り扱う。アイソクロノスデータの伝送中に、データフローマネージャ６４は、バッファの割り当て及び管理サービスを提供する。バッファ管理には、クライアントアプリケーションに対し、データが処理可能になったことを知らせる一貫性を有する通知メカニズム（consistent notification mechanism）の提供も含まれる。アイソクロノスデータがクライアントアプリケーション４８に供給される間、多くのメモリバッファがデータで満たされる。データフローマネージャ６４は、クライアントアプリケーション４８に、どのメモリバッファが満たされたかを知らせ、これによりクライアントアプリケーション４８は、そのメモリバッファからデータの読出処理を行うことができる。さらに、バッファ管理により、捕捉されるデータが最適化されるように、適切なサービスモジュールをメモリ内で分割でき、クライアントアプリケーションを単純化することができる。この処理は、割り当てられたメモリをビデオデータのストリームを走査線及びフレームサイズのセグメントに分割する処理及び生のオーディオデータ及びＭＩＤＩデータを最適なセグメントサイズに分割する処理を含む。
【００４４】
本発明に基づくメディアマネージャを用いて２つの装置間のデータ伝送をセットアップするための処理手順を図５に示す。この処理はステップ１００において開始される。クライアントアプリケーション４８は、ステップ１０２において、データ伝送のために２つの装置間の接続を確立するため、２つの装置を表す２つのＤＣＭ５６のいずれか一方のEstablishExternalConnection()メソッドを呼び出し、他方のＤＣＭ５６のモジュールＩＤ値をパラメータとして渡す。呼び出されたＤＣＭ５６は、ステップ１０４において、接続の確立を補助するためにデータフローマネージャ６４を呼び出し、転送元のＤＣＭのモジュールＩＤ及び転送先のＤＣＭのモジュールＩＤをパラメータとして渡す。データフローマネージャ６４は、ステップ１０６において、転送元のＩＤと転送先のＩＤとを分析し、これらが異なるノードに存在するか否かを判定する。データフローマネージャ６４は、ステップ１０８において、転送元のノードのバスマネージャ７からネットワークのトポロジマップを入手する。データフローマネージャ６４は、ステップ１１０において、このトポロジマップを分析して、転送先ノードを検索し、このノードがトポロジマップ上に存在するか否かを判定する。転送先のノードがトポロジマップ上に存在する場合、データフローマネージャは、ステップ１１８に移行して、データ伝送のための最適なルートを判定する。一方、転送先ノードがトポロジマップ上に存在しない場合、データフローマネージャは、ステップ１１２に移行し、サービスレジストリ５９から転送先ＤＣＭを入手し、そのノードの伝送プロトコルを判定する。データフローマネージャ６４は、ステップ１１４において、適切な伝送プロトコルサービスモジュールを検出し、適切な変換処理をセットアップする。そして、ステップ１１６において、複数の伝送処理をブリッジする必要が否かが判定される。ここで、複数の伝送処理をブリッジする必要があると判定されて場合、データフローマネージャ６４は、ステップ１１４に戻り、さらなる伝送変換モジュールを入手する。一方、伝送処理をブリッジする必要がない場合、データフローマネージャ６４は、ステップ１１８において、接続経路を分析し、データフローのための最良のルートを判定する。データフローマネージャ６４は、ステップ１２０において、転送元ノードと転送先ノードの入力データフォーマットを分析し、変換処理が必要か否かを判定する。変換処理が必要な場合、データフローマネージャ６４は、ステップ１２２において、入力フォーマット及び出力フォーマットに基づいて、サービスレジストリ５９から適切なフォーマットコンバータを入手し、変換処理をセットアップする。一方、変換処理が不要な場合、ステップ１２２において、データフロールートは完了し、２つの装置間のデータ伝送処理が開始される。
【００４５】
バスマネージャ７０は、基盤となる装置相互接続メカニズム（device interconnection mechanism）を抽象化し、バスアーキテクチャの能力（capability）を記述するための一組のプログラミングインターフェイスを提供する。本発明の好ましい具体例においては、装置はＩＥＥＥ１３９４規格（１９９５年版）シリアルバスにより接続されている。ＩＥＥＥ１３９４規格（１９９５年版）シリアルバスネットワークにおいて、バスマネージャ７０は、ホストオペレーティングシステム５８により実現されるＩＥＥＥ１３９４規格（１９９５年版）ＨＡＬ層の最上位に設けられ。バスマネージャ７０は、バス管理動作を汎化させて、本発明に基づく媒体マネージャとして機能させる働きを有する。バスマネージャ７０は、バスリセットの発生時に、イベントマネージャ６２を介して、クライアントアプリケーション４８にバスリセット通知を送信し、環境がどのように変化したかに関する完全な情報を提供する。この情報を受け取ったクライアントアプリケーションは、削除された装置及びバスリセット後に使用可能になった装置に関する情報を有することとなる。
【００４６】
バスマネージャ７０は、クライアントアプリケーション４８に、トポロジマップ、スピードマップ、及びその他の環境記述子を提供する。トポロジマップからの情報は、ユーザに対し、装置の接続状況及びどのような機能が使用可能であるかを理解させる手助けとなるユーザインターフェイスの構築に使用される。また、この情報は、データフローマネージャ６４に関して上述した自動データルーティングにも使用される。スピードマップは、現在の接続スキームを分析し、装置の接続状態を変更することによりネットワーク上の装置の性能を向上させるための、ユーザに対する提案の手助けとなる。バスマネージャ７０は、さらに、２つのノード又はノード内のソフトウェアモジュール間において、好ましいフォーマット又はプロトコルでバイトを送信するための、アトムレベル（atomic-level）データ通信サービスを提供する。このプロトコルは、これらアトム的な通信機能の最上位に設けられる。
【００４７】
バスリセット又はバス変更通知の後、バスマネージャ７０は、これにより追加された全ての装置に新たなＩＤ値を割り当てるとともに、どの装置が削除されたかを判定する。バスマネージャ７０は、ＤＣＭマネージャ５４を呼び出し、新たに追加された装置用の新たなＤＣＭ５６を生成し、バス変更通知をイベントマネージャ６２に供給する。イベントマネージャ６２は、登録されている全てのクライアントにバスリセットを通知する。この通知により、クライアントアプリケーション４８がバス上でどの装置が変更されたかを判定するために十分な情報が提供される。
【００４８】
伝送適合モジュール（transport adptation module）７８は、パッケージングメッセージデータ（packaging message data）が転送先装置への実際の伝送用のＨＡＬ上に渡される前に、このパッケージングメッセージデータを処理する。ＨＡＬは、本発明に基づくメディアマネージャにおける最下位の層である。この層は、上位のクライアントに対し、例えばＤＣＭ５６等の共通プログラミングインターフェイスを提供するとともに、クライアントとの通信に必要なあらゆるエンティティを提供する。伝送適合モジュール７８は、上述したバスマネージャ７０のアトム的メッセージ機能を使用する。
【００４９】
上述のとおり、ＤＣＭ５６は、装置制御のための標準化されたインターフェイスを上位のマルチメディアアプリケーション４８に供給することにより、プロトコル抽象化サービスを提供する。これらのコンポーネントにより提供されるプログラミングインターフェイスは、共通Ａ／Ｖ制御レベル及び装置固有制御レベルに分類される。共通Ａ／Ｖ制御レベルは、例えば再生、停止、早送り及び巻き戻しコマンド等の基本的な伝送制御機能を含む共通のコマンドのためのインターフェイスを提供する。装置固有の制御レベルは、例えば記録機能を有する装置における録音（録画）機能等の与えられた装置のカテゴリに共通するコマンド、及び特定のモデル又は装置のグループに固有のコマンドのためのインターフェイスを提供する。ＤＣＭ５６により提供されるプロトコル抽象化処理により、モジュールとアプリケーション４８との間のプログラミングインターフェイスは、装置の種類及び使用されている制御プロトコルの種類にかかわらず、常に同じものとすることができる。この機能により、アプリケーション及びユーザに対する大きな柔軟性が実現される。ＤＣＭ５６は、ユーザ入力イベント抽象化モデル（user input event abstraction model）を提供する。これにより、クライアントアプリケーションは、上述した米国特許出願番号６０／０５４，１９９号に開示されているように、グラフィカルユーザインターフェイス要素を表示し、グラフィカルユーザインターフェイス要素に対するユーザの操作に基づいて、標準化されたユーザイベントメッセージをＤＣＭ５６に供給する。
【００５０】
本発明に基づく媒体マネージャは、データフローの管理及び他のサービスを提供する。媒体マネージャは、ホストオペレーティングシステム５８の拡張機能として動作し、クライアントアプリケーション４８のみならず、媒体マネージャプラットフォーム上の他のコンポーネントへの様々なサービスを提供する。媒体マネージャは、ＤＣＭ５６を管理及び組織化する。媒体マネージャは、存在するアプリケーションに適切なＤＣＭ５６を検出及び初期化するとともに、不必要なＤＣＭ５６を削除する。媒体マネージャは、システムがブートされる毎に、あるいはＩＥＥＥ１３９４規格（１９９５年版）バスがリセットされる等してシステムが変更された可能性がある場合、特定のシーケンスを実行する。媒体マネージャは、ホストオペレーティングシステム５８で使用される特定のダイナミックリンクされたライブラリソリューションを取り巻くラッパ（wrapper）を提供する。これにより、外部のアプリケーションに対して一貫したインターフェイスを保ちながら、与えられたオペレーティングシステム上にモジュールを実現するために最良のダイナミックリンクされたライブラリが使用される。
【００５１】
媒体マネージャは、ネットワーク上の装置間のデータ伝送のフロー及びフォーマットを管理する。データフローを管理する際、媒体マネージャは、使用されているオペレーティングシステムから独立した手法で、適切なバッファを割り当て、及び管理する。
【００５２】
媒体マネージャは、ＩＥＥＥ１３９４規格（１９９５年版）バス環境の高レベルプロトコル管理を提供する。ユーザレベルのホットプラギング（hot plugging）等、動的な装置動作を完全にサポートするために、アプリケーション及び装置は、ＩＥＥＥ１３９４規格（１９９５年版）バス環境の変化を知る必要がある。媒体マネージャは、バスマネージャ７０及びイベントマネージャを介して、アプリケーション及び装置に対し、バスリセット通知を送信し、環境がどのように変化したかに関する完全な情報を提供することにより、ＩＥＥＥ１３９４規格（１９９５年版）バスにおいてバスリセットが発生したことを通知する。媒体マネージャは、バスマネージャ７０を介してアプリケーション及び装置にトポロジマップ及び他の環境記述子を提供する。トポロジマップは、ＩＥＥＥ１３９４規格（１９９５年版）ネットワーク内の装置間の接続状態を示すものである。トポロジマップに基づく情報は、ユーザインターフェイスの構築に使用され、これによりユーザは、装置がどのように接続されており、どのような機能が使用可能な状態であるかを知ることができる。
【００５３】
アプリケーションサービスモジュール６０は、ホストオペレーティングシステム５８とアプリケーション４８との間のレベルのサービスを提供し、これによりアプリケーション４８に、使用されているオペレーティングシステムから独立した基本的機能を提供する。この機能は、メモリの割り当て、ルーチンの削除などであり、これらの機能は、多くのオペレーティングシステムにおいて使用可能な基本的機能よりもより強固なものであり、これにより、装置環境及び自己内包された（self-contained）制御モジュール、全てのユーザインターフェイスを実現するための独立型の（stand-alone）モジュール、及び呼び出しによる相互動作管理が提供される。
【００５４】
伝送適合モジュール７８は、共通プログラミングインターフェイスを装置制御モジュール５０及びアプリケーション４８に提供し、これによりプロトコル性能をホストオペレーティングシステム５８に引き上げる。システムレベルインターフェイスブロック５０の内部設計及び具現化には、使用されている特定のホストオペレーティングシステムアーキテクチャを利用し、これによりＩＥＥＥ１３９４規格（１９９５年版）機能をアプリケーション４６により使用できるようにする。
【００５５】
本発明に基づく媒体マネージャプラットフォームは、ＤＣＭ５６、アプリケーションサービスモジュール６０、及び伝送適合モジュール７８により提供されるＩＥＥＥ１３９４規格（１９９５年版）バスプロトコル用のシステムレベルインターフェイスとを含む。通常の動作においては、アプリケーション４８はこれらコンポーネントの全てと通信を行う。ＤＣＭ５６と通信を行う場合、アプリケーション４８は、単一のプログラミングインターフェイスを使用する。また、アプリケーションサービスモジュール６０と通信を行う場合も、アプリケーション４８は、単一のプログラミングインターフェイスを使用する。
【００５６】
図３及び図４に示す上述のクライアントアプリケーション４８は、本発明に基づく媒体マネージャのアーキテクチャに関する他の全てのコンポーネントより上位に位置するエンティティである。要求されたタスクの大部分を遂行するために、アプリケーション４８は、ローカルメッセンジャを介して提供されるＤＣＭ５６及びアプリケーションサービスモジュール６０と通信を行う。必要に応じて、アプリケーション４８は、ホストオペレーティングシステム５８を介して、アーキテクチャのより低いレベルにアクセスする。
【００５７】
クライアントアプリケーション４８の起動に応じて、クライアントアプリケーション４８は、媒体マネージャのレジスタを初期化しなくてはならない。クライアントアプリケーション４８は、媒体マネージャが立ち上がり、実行されてクライアントアプリケーション４８にサービスを提供できる状態となるように媒体マネージャを初期化する。クライアントアプリケーション４８は、媒体マネージャを登録し、媒体マネージャに対し、クライアントアプリケーション４８と相互動作するために必要な全ての情報を供給し、クライアントアプリケーション４８自身をメッセージングシステムに登録する。通常、クライアントアプリケーション４８は、起動時に、ホストオペレーティングシステムが初期化されていることと、最小レベルのサービスが使用可能であることと、実行のために必要なメモリ容量が確保されていることとを確認する必要がある。これらの処理は、クライアントアプリケーション４８が媒体マネージャを初期化した後に、媒体マネージャがクライアントアプリケーション４８のために実行する。
【００５８】
クライアントアプリケーション４８は、起動時に、図６のフローチャートに示す処理を実行する。まず、ステップ１４０において、クライアントアプリケーション４８は、起動処理を開始する。起動処理開始の後、クライアントアプリケーション４８は、ステップ１４２において、媒体マネージャを初期化する。本発明の好適な具体例においては、アプリケーションは、以下に示す呼び出し（call）により媒体マネージャを初期化する。
err=SMM_Initialize
媒体マネージャは、初期化されると、必要なメモリ及びシステムサービスをアプリケーション４８のサポート用に割り当てる。
【００５９】
媒体マネージャの初期化が完了すると、アプリケーション４８は、ステップ１４４において、媒体マネージャ１４４の登録を行う。この登録処理により、アプリケーション４８は、媒体マネージャに対し、アプリケーション４８を適切にサポートするために必要な特定の情報を供給する。例えば、アプリケーション４８は、ＩＥＥＥ１３９４規格（１９９５年版）バスリセット、非同期トランザクションの完了、メモリバッファが一定量のアイソクロノスデータにより満たされたときに発生されるトリガ等の環境に関連する有意のイベントを通知するためのコールバックルーチンのアドレスを提供する。登録処理は、以下の命令により遂行される。
SonyErrorResultType SMM_ResisterClient (SMMClientIdentifierType* the ClientID.
SMMBusEventNotificationUpp clientBusEventNotificationCallback, void*
clientBusEventCallbackData)
パラメータClientIDは、媒体マネージャにより生成されたアプリケーションのための固有の識別子である。これ以降の媒体マネージャとの通信処理において、例えばアプリケーション４８の終了や媒体マネージャの登録解除等の処理において、アプリケーション４８は、この識別子を返す必要がある。パラメータclientBusEventNotificationCallbackは、アプリケーション４８により実現されるコールバック関数への適切にフォーマットされた参照値である。アプリケーションがネットワーク環境において発生する動的な変化を知る必要がない場合、アプリケーション４８は、このようなコールバック関数を必要としない。アプリケーション４８がこのようなコールバック関数を実装していない場合、アプリケーションはこのパラメータにNIL値を渡す。
【００６０】
パラメータclientBusEventCallbackDataは、アプリケーション４８がコールバックルーチンにおいてアクセスする必要があるいかなる値を有していてもよい。通常、この値は、メモリのブロックへのポインタであり、媒体マネージャがコールバック関数を呼び出したとき、クライアントアプリケーション４８にはこの値が返され、これによりアプリケーション４８は、記録媒体全体又は適切なデータにアクセスすることができる。
【００６１】
媒体マネージャの登録処理を遂行するためには、アプリケーション４８は、以下のインターフェイスを用いて、通知コールバック関数を実現しなくてはならない。
pascal void (*SMMBusEventNotificationProcPtr)(void*clientData, SMMBusEventType busEventIndcator,
SMMBusEventRecPtr busEventInfo):
パラメータclientDataは、登録関数（resistration function）に渡されたパラメータclientBusEventCallbackDataである。パラメータbusEventIndcatorは、アプリケーションに通知されているイベントがどのようなものであるかを示す列挙されたデータ種類を表す。特定されるイベントには、装置がネットワークに接続され又は切り離されたとき、非同期データトランザクションが完了したとき、特定されたバッファがアイソクロノスデータ伝送処理中に一杯になったとき等に生じるバスリセットが含まれる。パラメータbusEventInfoは、特定のイベントに関連する情報を含むデータ構造体を提供する。
【００６２】
媒体マネージャの登録処理を完了すると、アプリケーション４８は、ステップ１４６において、使用可能なＤＣＭ５６を入手する。ＤＣＭ５６を入手することにより、アプリケーション４８は、ネットワーク内で接続されている他の種類の装置を知ることができる。このステップは一連のサブステップにより構成される。アプリケーション４８へデータを伝送するためのデータ伝送の手法として、繰り返しコールバックモデル（iterative callback model）を用いる。クライアントアプリケーション４８は、まず、媒体マネージャにコールバック関数のアドレスを供給する。アプリケーション４８は、ループ処理に入り、残りのＤＣＭがなくなるまで、媒体マネージャに対し、次のモジュールに関する情報を繰り返し要求する。媒体マネージャは、必要な情報と共にデータ構造体を準備し、このデータ構造体をコールバック関数を介してアプリケーション４８に供給する。特定のＤＣＭ５６に関する情報が供給されると、アプリケーション４８は、必要な情報を複写する。この処理は、使用できる全てのＤＣＭがアプリケーション４８に供給されるまで繰り返される。本発明の変形例においては、クライアントアプリケーションは、システムレジストリの問い合わせを行い、使用可能なＤＣＭ５６それぞれのハンドルを要求する。
【００６３】
使用可能なＤＣＭ５６を入手するためにアプリケーション４８が実現するコールバック関数は以下のように定義される
void DeviceInfoCallbackRoutine(void *userData, SMMDeviceIndexType deviceIndex, SonyAvDeviceRecPtr deviceInfo)
コールバック関数のパラメータuserDataは、媒体マネージャとアプリケーション４８との間のデータ伝送に使用される。アプリケーション４８は、自身のデータ構造体を定義し、これら構造体の１つにメモリを割り当て、構造体のアドレスを媒体マネージャに渡す。このアドレスは、コールバック関数に戻され、これによりアプリケーション４８は、情報の複写を目的として、データ構造体にアクセスすることができる。
【００６４】
コールバック関数のパラメータdeviceIndexは、アプリケーション４８が使用可能なＤＣＭ５６に関する情報を入手するために入るループのインデックス値となるパラメータである。このループは、使用可能なＤＣＭ５６の数だけ繰り返される。このパラメータは、コールバック関数からアプリケーション４８に返され、これによりアプリケーション４８は、コールバック関数に渡した他の情報とともに、このパラメータを保存することができる。このインデックス値は、特定のＤＣＭ５６に関する問い合わせを行うための、アプリケーション４８による媒体マネージャへの他の呼び出しの際に使用できる。さらに、このインデックス値は、アプリケーション４８に、装置がネットワークから切り離され、すなわち接続解除されて、ネットワークから削除されたことを通知する際に使用される。アプリケーション４８は、自らが所有するデータ構造体の専用フィールドにこのインデックス値を格納する。
【００６５】
コールバック関数のパラメータdeviceInfoは、SonyAvDeviceRecのラベルが付されたデータ構造体へのポインタであり、このデータ構造体には、媒体マネージャがアプリケーション４８により検索されるＤＣＭ５６を格納する。このデータ構造体のフォーマットは、アプリケーション４８及び媒体マネージャの両方にとって既知である。ＤＣＭ５６がこのデータ構造体に格納されると、アプリケーション４８は、このデータ構造体から、自らが所有するデータ構造体に適切な情報を複写する。データ構造体SonyAvDeviceRecの定義を表１に示す。
【００６６】
【表１】

【００６７】
パラメータdeviceIDは、ＤＣＭ５６及びそれに対応する装置の識別子である。この識別子は、アプリケーション４８がＤＣＭ５６と通信を行おうとする際、及びアプリケーション４８が媒体マネージャから特定の装置に関するサービスを要求する際に常に使用する。
【００６８】
パラメータbusGenerationは、バスリセットが発生する度に変更される値を示す。装置が追加又は削除されてバスリセットが発生すると、バス及び接続されている装置に関するある情報が変更される。ＩＥＥＥ１３９４規格（１９９５年版）バスリセットが発生する度に、パラメータbusGenerationの値は更新される。
【００６９】
パラメータcontrolModuleReferenceは、特定の装置に関連するＤＣＭ５６への参照値を示す。この参照値は、アプリケーション４８がモジュールとのトランザクションを自らに代わって媒体マネージャに行わせることを要求する際に使用する。
【００７０】
アプリケーション４８は、以下の関数呼び出しにより、媒体マネージャに、使用可能なＤＣＭ５６及びモジュールの数のリストを生成させる要求を行う。
SonyErrorResultType SMM_FindDeviceControlModules (SMMDeviceListRefType* theDeviceList, usigned long deviceAttributes, short* numAVDevices)
パラメータtheDeviceListは、使用可能なＤＣＭ５６が格納され、媒体マネージャにより生成され、戻されるリストのアドレスを示す。アプリケーションは、この種類のローカル変数を宣言し、その変数のアドレスをこの関数に渡す。
【００７１】
パラメータdeviceAttributesは、アプリケーション４８が返されるべきＤＣＭ５６の種類を特定するために使用するビットによるフラグのセットを含む。例えば、アプリケーション４８は、ネットワークに接続されてアクティブな状態にある装置に関する情報のみを求める場合がある。特定のフラグ値が設定されている場合、媒体マネージャはこのリストをフィルタリングして、この条件を満たす装置のみを残して、アプリケーション４８にリストを返すことができる。アプリケーション４８は、これにより、起動され実行されている装置のみ、接続されているが電源がオフにされている装置のみ、又はスリープモードの状態にある装置のみ等の条件に適合する全ての装置が含まれたリストを特定することができる。
【００７２】
パラメータnumAVDevicesは、アプリケーション４８に返されるリスト内のＤＣＭ５６の数を示すパラメータである。アプリケーション４８は、この数値を用いて、ＤＣＭ５６を入手するための繰り返し処理の繰り返し回数を決定する。
【００７３】
アプリケーション４８は、コールバック関数のアドレスを準備し、ループ処理に入り、リスト内の全てのＤＣＭ５６に関する情報が入手されるまで、繰り返し媒体マネージャを呼び出す。ループを一度繰り返す度に、アプリケーション４８は、以下の関数を呼び出す。
pascal SonyErrorResultType SMM_GetDeviceControlMouleInfo
(SMMDeviceListRefType theDeviceList, SMMDeviceType whichDevice,
unsinged long reserved, SMMDeviceControlModuleIteratorUPP
theDveiceListCallbackFunction, void *userData)
パラメータtheDeviceListは、関数呼び出しFindAllControlModules()から返されたリスト参照値を示すパラメータである。パラメータwhichDeviceは、アプリケーション４８が情報を要求しているＤＣＭ５６はどれであるかを示すパラメータである。パラメータtheDveiceListCallbackFunctionは、準備されているコールバック関数のアドレスを示すパラメータである。パラメータuserDataは、アプリケーションにより定義されたデータ構造体への参照値を示すパラメータである。この参照値は、コールバックルーチン内でアプリケーション４８に返され、アプリケーション４８は、媒体マネージャからこのデータ構造体に必要な全ての情報を読み込む。
【００７４】
使用可能なＤＣＭ５６を入手するための処理シーケンスの好ましい具体例を以下の表２に示す。
【００７５】
【表２】

【００７６】
アプリケーション４８が使用可能なＤＣＭ５６を入手した後は、アプリケーション４８は、ステップ１４８において、装置固有の情報を入手する。媒体マネージャから返されるＤＣＭ情報は、各装置の固有の識別子を含むシステムレベルの情報と、ＩＥＥＥ１３９４規格（１９９５年版）に準拠する装置用のバスの生成等のプロトコル固有の情報である。装置の状態、記述的名称文字列、装置の画像等の装置固有の情報を入手するためには、アプリケーション４８は、適切なＤＣＭ５６と通信を行う必要がある。図６に示し、上述した処理を完了することにより、アプリケーション４８は、スタートアップルーチンを完了し、動作できる状態になる。
【００７７】
アプリケーション４８が動作している間、アプリケーション４８は、ユーザレベル及びシステムレベルのイベントと、制御入力信号の受信を含むメッセージと、ホストオペレーティングシステム及び媒体マネージャの処理による外部からのメッセージとを処理する。
【００７８】
本発明の構造及び動作の原理を明瞭に説明するために、本発明を詳細事項と共に特定の実施の形態に沿って説明した。本発明の実施の形態における言及及び詳細事項は、添付の請求の範囲を限定するためのものではない。本発明の思想及び趣旨から逸脱することなく、ここに例示した実施の形態を様々に修正できることは、当業者にとって明らかである。特に、本発明の好適な実施の形態においては、ＩＥＥＥ１３９４規格（１９９５年版）シリアルバスに接続された装置を管理する具体例を示したが、本発明は他のバス構造体に対しても同様に適用できることは、当業者にとって明らかである。
【図面の簡単な説明】
【図１】 ビデオカメラ、ビデオテープレコーダ、コンピュータ、テレビジョン受像機、セットトップボックスを備えるＩＥＥＥ１３９４規格（１９９５年版）シリアルバスネットワークを示す図である。
【図２】 本発明を適用した媒体マネージャを実装する各装置内に設けられるハードウェア構成を示す図である。
【図３】 本発明を適用した媒体マネージャプラットフォームのアーキテクチャを示す図である。
【図４】 本発明を適用した媒体マネージャプラットフォームのアーキテクチャを詳細に示す図である。
【図５】 本発明を適用した媒体マネージャを用いたセットアップ処理及び２つの装置間のデータ伝送処理の手順を示すフローチャートである。
【図６】 クライアントアプリケーションのスタートアップ後の処理手順を示すフローチャートである。

Claims (30)

1. 所定の機能を実現するタスクを遂行するための、ネットワークに接続された物理的装置の動作及び物理的装置間のタスクを遂行するための命令及びデータの送受を行うための通信処理を管理する管理方法において、
   ａ．上記タスクを遂行するために必要な使用可能な物理的装置及び物理的装置の下位装置を判定し、該タスクの遂行のために使用できる物理的装置が存在しない場合には、使用可能な下位装置から仮想装置を構築するステップと、
   ｂ．上記使用可能な物理的装置及び上記仮想装置を構築する下位装置に上記タスクを遂行するための命令を行うステップとを有する管理方法。
2. 上記ネットワーク内の各物理的装置用の制御モジュールを維持管理するステップを有し、
   上記制御モジュールは、上記物理的装置及び該物理的装置内の下位装置の機能に関する情報を有し、該物理的装置を制御することを特徴とする請求項１記載の管理方法。
3. 上記使用可能な物理的装置及び下位装置間のデータフローを制御するステップを有する請求項２記載の管理方法。
4. ａ．上記ネットワーク内の装置のトポロジマップを入手するステップと、 ｂ．上記トポロジマップを分析して最良のルートを判定するステップとを有する請求項３記載の管理方法。
5. 上記使用可能な物理的装置及び下位装置で送受されるデータのフォーマットを必要に応じて適切なフォーマットに変換するステップを有する請求項４記載の管理方法。
6. 遂行されるべきタスクを要求するためのインターフェイスをユーザに提供するステップを有する請求項５記載の管理方法。
7. 上記制御モジュールは、アプリケーションにユーザインタフェイスデータを提供し、該アプリケーションを介して行われるユーザイベントに応答することを特徴とする請求項６記載の管理方法。
8. 上記ネットワークはＩＥＥＥ１３９４シリアルバスネットワークであることを特徴とする請求項７記載の管理方法。
9. 上記制御モジュールはリモート装置内に配設され、ホスト装置にダウンロードされて実行されることを特徴とする請求項７記載の管理方法。
10. 上記制御モジュールは、ローカル装置内に配設され、該ローカル装置内の生来的な環境により実行されることを特徴とする請求項７記載の管理方法。
11. 上記制御モジュールは、ローカル装置内に配設され、ホスト装置にアップロードされて実行されることを特徴とする請求項７記載の管理方法。
12. ネットワークに接続された物理的装置の動作及び物理的装置間の所定の機能を実現するタスクを遂行するための命令及びデータの送受を行うための通信処理を制御する制御装置において、
    ａ．上記ネットワーク内の物理的装置と通信を行うためのインターフェイス回路と、
    ｂ．上記インターフェイス回路に接続され、タスクを遂行するために必要な物理的装置及び物理的装置の下位装置を判定し、該タスクの遂行のために使用できる物理的装置が存在しない場合には、使用可能な下位装置から仮想装置を構築し、下位装置に上記タスクを遂行するための命令を行う制御回路とを備える制御装置。
13. 上記ネットワーク内の各物理的装置を表し、上記物理的装置及び該物理的装置内の下位装置の機能に関する情報を有し、該物理的装置を制御する複数の制御モジュールを備える請求項１２記載の制御装置。
14. 上記制御回路及び上記インターフェイス回路に接続され、上記ネットワーク内の物理的装置のトポロジマップを入手し、該トポロジマップを分析して最良のルートを判定するバス管理回路を備える請求項１３記載の制御装置。
15. 上記制御回路は、上記使用可能な物理的装置及び下位装置で送受されるデータのフォーマットを必要に応じて適切なフォーマットに変換することを特徴とする請求項１４記載の制御装置。
16. 上記ネットワークはＩＥＥＥ１３９４シリアルバスネットワークであることを特徴とする請求項１５記載の制御装置。
17. ネットワークに接続された物理的装置の動作及び物理的装置間の所定の機能を実現するタスクを遂行するための命令及びデータの送受を行うための通信処理を管理する管理方法において、
    ａ．上記ネットワーク内の各物理的装置に対応し、該物理的装置の機能及び該物理的装置内の全ての下位装置に関する情報を有し、該物理的装置を制御する制御モジュールを維持管理するステップと、
    ｂ．ユーザが遂行すべきタスクを要求するためのインターフェイスを準備するステップと、
    ｃ．上記制御モジュールを検索して、上記タスク遂行のために必要な物理的装置及び下位装置を判定し、該タスク遂行のための物理的装置が使用可能な状態にない場合に、使用可能な下位装置から仮想装置を構築するステップと、
    ｄ．使用可能な制御モジュールにより上記使用可能な物理的装置及び上記仮想装置を構築する下位装置に命令を供給させて上記タスクを遂行するステップとを有する管理方法。
18. ａ．上記タスクの遂行のための上記物理的装置及び下位装置が現在使用可能であるか否かを判定するステップと、
    ｂ．上記物理的装置及び下位装置が使用可能な状態にない場合、上記ネットワーク内の物理的装置の使用可能な下位装置から仮想装置を構築するステップを有する請求項１７記載の管理方法。
19. 上記使用可能な物理的装置及び下位装置間のデータフローを制御するステップを有する請求項１８記載の管理方法。
20. ａ．上記ネットワーク内の物理的装置のトポロジマップを入手するステップと、
    ｂ．上記トポロジマップを分析して最良のルートを判定するステップとを有する請求項１９記載の管理方法。
21. ａ．上記使用可能な物理的装置及び下位装置で送受されるデータのフォーマットを変換する必要があるか否かを判定するステップと、
    ｂ．上記データのフォーマットの変換が必要な場合に、該データのフォーマットを変換するステップとを有する請求項２０記載の管理方法。
22. 上記ネットワークはＩＥＥＥ１３９４シリアルバスネットワークであることを特徴とする請求項２１記載の管理方法。
23. ネットワークに接続された物理的装置の動作及び物理的装置間の所定の機能を実現するタスクを遂行するための命令及びデータの送受を行うための通信処理を制御する制御装置において、
    ａ．上記ネットワーク内の各物理的装置に対応し、該物理的装置の機能及び該物理的装置内の全ての下位装置に関する情報を有し、該物理的装置を制御する制御モジュールと、
    ｂ．ユーザと通信を行い、遂行されるべきタスクをユーザが要求するためのインターフェイスと、
    ｃ．上記複数の制御モジュールと、ネットワークと、表示装置とに接続され、制御モジュールを検索することにより、上記タスクを遂行するために必要な使用可能な物理的装置及び下位装置を判定し、適切な制御モジュールにより上記使用可能な物理的装置及び下位装置に命令を供給させて上記タスクを遂行させる制御回路とを備え、
    上記制御回路は、上記タスク遂行に必要な物理的装置及び下位装置が使用可能な状態にあるかを判定し、該タスク遂行に物理的装置及び下位装置が使用可能な状態にない場合に、使用可能な下位装置から仮想装置を構築し、上記タスクを遂行させることを特徴とする制御装置。
24. 上記制御回路は、上記タスクの遂行のための上記物理的装置及び下位装置が現在使用可能であるか否かを判定し、上記物理的装置及び下位装置が使用可能な状態にない場合、上記ネットワーク内の物理的装置の使用可能な下位装置から仮想装置を構築することを特徴とする請求項２３記載の制御装置。
25. 上記制御回路は、上記ネットワーク内の装置間のデータフローを制御することを特徴とする請求項２４記載の制御装置。
26. 上記制御回路に接続され、上記ネットワーク内の装置のトポロジマップを入手し、該トポロジマップを分析して最良のルートを判定するバス管理回路を備える請求項２５記載の制御装置。
27. 上記制御回路は、上記使用可能な物理的装置及び下位装置で送受されるデータのフォーマットを必要に応じて適切なフォーマットに変換することを特徴とする請求項２６記載の制御装置。
28. 上記制御回路は、上記ネットワーク内の物理的装置の基本的機能へのユーザのアクセスを可能にする予め定義された動作を実現することを特徴とする請求項２７記載の制御装置。
29. 上記制御回路は、ユーザの行動を監視及び記録し、カスタム化されたユーザに関して定義された動作を生成することを特徴とする請求項２８記載の制御装置。
30. 上記ネットワークはＩＥＥＥ１３９４シリアルバスネットワークであることを特徴とする請求項２７記載の制御装置。

Images