(57)【特許請求の範囲】
【請求項１】
家庭内機器の家庭内通信ネットワーク中の複数のリソースの動作をプログラムする方法であって、
上記動作を定義する一組のパラメータ及び上記動作を実現するのに関係する上記ネットワークに接続された複数のリソースのリストを含む要求であり、クライアントアプリケーションによって送信された上記動作をプログラムする要求を上記ネットワークの機器の予めプログラムされた動作マネージャによって受信する段階と、
上記動作を実現するのに関係する上記リストされたリソースの利用可能性を上記動作マネージャによって確認する段階と、
上記確認段階の結果に依存して上記予めプログラムされた動作マネージャの側における上記動作の承認又は拒否のメッセージを上記クライアントアプリケーションに送信する段階と、
上記動作が承認できる場合、上記動作に関係する上記複数のリソースのそれぞれを予約し、上記動作に関して上記動作に関係する上記複数のリソースのそれぞれに自己の予定表を記憶させ、上記動作を実現するのに関係する上記複数のリソース間でコネクションを確立する段階とを有することを特徴とする方法。
【請求項２】
上記クライアントアプリケーションは、上記クライアントアプリケーション以外の機器にある予めプログラムされた動作マネージャを選択することを特徴とする請求項１記載の方法。
【請求項３】
上記確認段階は、上記関係するリソース夫々の上記予定表を通じて上記リソースの利用可能性を確認するために上記予めプログラムされた動作マネージャが上記各関係するリソースに要求することを有する請求項１記載の方法。
【請求項４】
上記動作の始動時において、上記予めプログラムされた動作マネージャは、
上記関係するリソースの予約、及び、
上記関係するリソースでの実施されるべきコマンドの開始
のタスクを実施することを特徴とする請求項１記載の方法。
【請求項５】
上記動作を定義するパラメータは、動作開始時間、動作終了時間、上記動作の周期性のパラメータのうち１つ以上を有することを特徴とする請求項１乃至４のうちいずれか一項記載の方法。
【請求項６】
上記動作を定義するパラメータは、上記動作を始める前に確立されるべきコネクションのリストを有することを特徴とする請求項１記載の方法。
【請求項７】
上記利用可能性の確認段階は、上記動作の開始時間と終了時間との間の上記関係するリソースの利用可能性を上記関係するリソースに問い合わせる段階を有することを特徴とする請求項１記載の方法。
【請求項８】
ホームネットワークにおける機器であって、
動作を定義する一組のパラメータ及び上記動作を実現するのに関係する複数のリソースのリストを含む要求であり、クライアントアプリケーションによって送信された動作をプログラムする要求を受信する予めプログラムされた動作マネージャを有し、
上記予めプログラムされた動作マネージャは、上記動作を実現するのに関係する上記リストされたリソースの利用可能性を検査し、上記動作の承認又は拒否のメッセージを上記クライアントアプリケーションに送信し、上記動作が承認できる場合、上記動作に関係する上記複数のリソースのそれぞれを予約し、上記動作に関して上記動作に関係する上記複数のリソースのそれぞれに各リソースの自己の予定表を記憶させ、上記動作を実現するのに関係する上記複数のリソース間でコネクションを確立するように適合される機器。
【請求項９】
上記パラメータは、上記動作の開始時間及び終了時間を有し、
上記利用可能性の検査は、上記開始時間と上記終了時間との間での上記関係するリソースの利用可能性の検査を有することを特徴とする請求項８記載の機器。
【発明の詳細な説明】
【０００１】
本発明は、家庭内通信ネットワーク、特に、ＩＥＥＥ１３９４−１９９５シリアルバスを含むネットワーク中のリソースつまり、機器のファシリティの動作をプログラムするプロセスに関わる。
【０００２】
オーディオ／ビデオ機器又は「ノード」が連結される家庭内通信ネットワークにおいて、ユーザは、ディスプレイを有する全ての機器のうちの一つの機器によって実施されるべき動作をプログラムする可能性を有するべきである。例によって、全てのテレビジョンセット又はネットワークに連結される他の表示手段から送信される情報を全てのレコーディング機器、例えば、ビデオレコーディング器によってレコーディングすることをプログラムすることが可能となるべきである。
【０００３】
本発明は、家庭内機器のネットワーク中のリソースの動作をプログラムするプロセスに関わり、このプロセスは、動作を定義する一組のパラメータ及び動作を実現するのに関係するリソースのリストを含み、クライアントアプリケーションによる動作をプログラムする要求をネットワークの機器の予めプログラムされた動作マネージャに送る段階と、この動作を実現するのに関係するリソースの利用可能性を上記動作マネージャによって確認する段階と、上記確認段階の結果に依存して予めプログラムされた動作マネージャの側における動作の承認又は拒否のメッセージをクライアントアプリケーションに対して送信する段階とを有することを特徴とする。
【０００４】
特定の実施例によると、クライアントアプリケーションは、クライアントアプリケーション以外の機器中におかれる予めプログラムされた動作マネージャを選択する。
【０００５】
特定の実施例によると、プロセスは、動作に関する関連する各リソースの予定表を関連する各リソースによって記憶する段階を含む。
【０００６】
特定の実施例によると、確認段階は、関係するリソース夫々の予定表を通じてこのリソースの利用可能性を確認することを目的とし各関係するリソースから予めプログラムされた動作マネージャを要求することを含む。
【０００７】
特定の実施例によると、動作の始動時、予めプログラムされた動作マネージャは、関係するリソースの予約、関係するリソース間の要求されたコネクションの確立、及び、関係するリソースとのコマンドの開始といったタスクを実施する。
【０００８】
本発明の他の特徴及び利点は、添付図面によって例示される２つの非制限的な実施例の説明を通じて明らかになる。
【０００９】
本説明は、ＩＥＥＥ１３９４−１９９５に従うシリアルバス、並びに、ソニー株式会社、株式会社日立製作所、株式会社東芝、フィリップスエレクトロニックスＮ．Ｖ．、及び、シャープ株式会社のインターネットサイト上で１９９８年５月１５日に公表された、１９９８年５月１１日仕様書「The  ‘HAVi’Architecture−Specification  of  the  Home  Audio/Video  interoperability  Architecture」のバージョン０．８中で説明される「ＨＡＶｉ」アーキテクチャとして称されるアーキテクチャに基づく家庭内ネットワークに関わる。HAVi仕様書の新しいバージョン（バージョン１．０β＋）は、本特許出願の優先日と出願日の間に公表されている。
【００１０】
本出願と同名下で出願された２つ特許出願は、ネットワークのアーキテクチャのある面をより詳細に説明する。これらは、
【００１１】
【外１】
0004647097.tif 000002
［Process  for  managing  objects  in  a  communication  network  and  device  for  implementing  same］なる名称の１９９８年４月２８日の仏特許出願第９８０５１１０号、及び、本出願の優先日と同日に出願され、
【００１２】
【外２】
0004647097.tif 000003
［Process  for  managing  priorities  of  access  to  resources  in  a  domestic  network  and  device  for  implementing  same］なる名称の仏特許出願である。この２つ目の特許出願は、ＦＲ９８０７１８６の番号を有する。第１の特許出願は、オブジェクトのレジストリー、又は、ネットワークに接続された機器中のリソースの実行に関わり、このときこのレジストリーは、リソース或いは機器中のローカルレベルで利用できるソフトウェアモジュールの最新のリストを保持する一方で第２の特許出願は、局部的に利用できるリソースのためのリソースに対する予約を管理しこれらリソースに対するアクセス又はこれらのリソースの予約の衝突を解決することに関与する。
【００１３】
送信されるサービスのレコーディングのような動作を実行するために、アプリケーションは、パブリック・リソースに対するアクセスを要求してもよい。パブリック・リソースといった表現は、本文脈中では、アプリケーションが実行される機器以外であるがこのアプリケーションによって潜在的にアクセス可能な機器のファシリティを意味すると理解される。アプリケーションによって局部的にアクセス可能なリソース及び帯域幅もパブリック・リソースの一部を形成する。アプリケーションは、それ自体でリソースとなり得る。上述のレジストリーは、利用できるパブリック・リソースの最新リストを保持し、アプリケーションは、そのローカルレベルで要求を放つことでこれらリソースのうちどのリソースがこの要求を他のレジストリーに伝搬し得るかを決定し得る。
【００１４】
名称「ソフトウェア・モジュール」（HAVi仕様書の用語を使用）は、機器のアプリケーション、リソース、及び、サービスを示す。
【００１５】
２つの実施例を提供する。第１の実施例によると、予めプログラムされた動作の実行に関連するある機能は、以降「メインソース」として称されるものによって実施される一方で、第２の実施例によると、これらの機能は、予めプログラムされた動作、即ち、予めプログラムされた動作マネージャ（「ＰＡＭ」）において関係するリソースとは無関係にオブジェクトによって要求を満たされる。
【００１６】
例１
第１の実施例による予めプログラムされた動作の実行は、
−クライアントアプリケーションと、
−「ターゲットリソース」又は単に「ターゲット」として称されるメインリソースと、
−予めプログラムされた動作を実行するのに要求される「関係するリソース」として称される適当な１つ以上の他のパブリック・リソースとを含む。
【００１７】
レコーディング要求の枠内において、ターゲットは、例えば、ディジタルレコーディング機器（ディジタルビデオレコーダ、ＤＶＤ等）のレコーディングファシリティである一方で関係するリソースはチューナである。他のリソース、例えば、データのフォーマットをレコーディング機器のフォーマットの変換するのに要求されるトランスコーダ、及び、プログラムを得るためにアクセスを認可するアクセス制御サービス等が要求されてもよい。
【００１８】
動作がプログラムされる表示機器が不活性とされた場合（例えば、プログラミングに関してユーザにビデオレコーダの機能を提供したテレビジョンセットをユーザがオフにした場合）でさえも、通常通り動作させるよう予めプログラムされた動作を実行するプロセスのための要求が考慮される。機器は、関係するリソース（関係するリソースの一部を形成するメインリソース）を全く有しないと仮定する。
【００１９】
ターゲットは、アプリケーションによって要求される動作を承認又は承認しない。この動作をプログラムするとき、ターゲットは、動作の実現に要求されるリソースを識別し、これらのリソースを必要な期間予約しなくてはならない。動作が実際に実行されるとき、ターゲット及び関係するリソースは、互いに同期しなくてはならない。この結果として、予めプログラムされた動作に関する情報は、ネットワーク中に記憶されなくてはならない。第１の実施例によると、ターゲットがこの情報を記憶し動作を実行する一方で、第２の実施例によると、別のモジュールがこれらの機能の役目を担う。予めプログラムされた動作は、情報の決まった数のアイテムによって定義され得、これらアイテムは、動作をプログラムするアプリケーションによって提供される特定のデータ構造中で集められ、ターゲットリソースによって記憶される。
【００２０】
−動作のタイプ
−動作（各関連するリソースに関して実施されるべきコマンド、動作を開始する前に確立されるべきコネクションのリスト）に関連するパラメータ
−日付
−開始時間
−終了時間
−動作の周期性
−ターゲットリソースの識別子
−関係するリソースの識別子
−ユーザデータ
動作のタイプは、ターゲットの性質に依存する。例によって、動作は、大量メモリファシリティを有するリソースのために「RECORD」又は「READ」され得、又は、ディジタル・テレビジョン・デマルチプレクサのために「SELECT_SERVICE」され得る。
【００２１】
実施されるべき動作に依存するパラメータは、各リソースのレベルにおいてより特定的な方法で動作を定義する機能を担う。パラメータは、DVBディジタル・ビデオ放送規格の意味内でイベント又はサービスとなり得る。この場合、パラメータは、パラメータのタイプの識別子を有し、後続してパラメータの値を有する。
【００２２】
ネットワクーのある機器は、このレベルでサービスを提供する処理手段を含まなくてもよい。例えば、レコーディング機器は、「RECORD」コマンド自体チューナを制御することができないため、「RECORD」コマンドの後にパラメータを受け入れなくてもよい一方でチューナを制御する可能性を有するより複雑な機器が「RECORD  service  X」タイプのコマンドを受け入れることができる。
【００２３】
動作の日付、開始時間、終了時間、及び、周期性は、従来の情報である。
【００２４】
ターゲットリソースの識別子は、既にプログラムされた動作をアプリケーションが変更し得るために必要である。このフィールドは、ターゲットリソースが予めプログラムされた動作を直接記憶する場合（即ち、このリソース自体がプログラムされた動作のメインリソースである場合）必要でない。
【００２５】
例えば、どのプログラムされた動作が所与のリソースと関連するかをアプリケーションが確認にすることを望む場合、このアプリケーションは、このリソースに対してこのリソースが関連する各プログラムされた動作の識別子を請求する。アプリケーションは、選択したプログラムされた動作のデータ構造に問い合わし、変更することができる（このアプリケーションは、例えば、変更される動作をプログラムしたユーザ以外のユーザによって可能であれば制御されるユーザインタフェースのアプリケーションでもよい）。
【００２６】
第１の実施例によると、関係するリソースの識別子がターゲットによって使用される。リストは、例えば、レジストリー又は関係するリソースに直接メッセージを送信することで関係するリソースに関する情報を要求することをターゲットに可能にさせる。
【００２７】
ユーザデータは、例えば、プレーンテキストで動作の動機を含み、これは、前にプログラムされた動作との衝突の場合に重要となり得る。この場合、衝突がユーザ、典型的には最近の動作をプログラムしたユーザ、によって解決されなくてはならないとき、これらのデータは、動作の重要性に関する標識を提供してもよい。
【００２８】
ターゲットリソースによって接触される関係するリソース自体、上記データ構造のコンテンツのうち幾つか、例えば、時間に関する情報或いは可能であれば動作のタイプ、パラメータ、及び、ユーザデータを記憶しなくてはならない。
【００２９】
第１の実施例は、図１に示す。この図によって示されるネットワーク部分は、５つの機器を有する。機器１は、台所におかれアプリケーション２（例えば、ネットワークの全ての機器のプログラミングを可能にするユーザインタフェース）を有するテレビジョンセットである。機器３もテレビジョンセットであるが、このテレビジョンセットは、寝室におかれアプリケーション２に類似するアプリケーション４を具備する。機器５は、チューナリソース６とリソースマネージャ７とを有するディジタル衛星テレビジョンデコーダである一方でこれに関して、機器８は、レコーディングリソース９とリソースマネージャ１０とを有するＤＶＤ型ディジタルレコーディング機器である。最後に、機器１１は、例えば、（デコーダ５の）第１のフォーマットに従って符号化されたオーディオ／ビデオデータを（レコーディング機器８の）第２のフォーマットにトランスコードするファシリティを有する。結果として、機器１１は、トランスコーディングリソース１２とリソースマネージャ１３とを有する。例示する以外のソフトウェアモジュールを有し得る様々な機器は、シリアルバス１４、例えば、ＩＥＥＥ１３９４−１９９５バスによって連結される。
【００３０】
第１の実施例によると、本発明の場合において機器８のレコーディング機能であるターゲットリソース自体は、レコーディング動作を管理することができるアプリケーションを組み込む。
【００３１】
ユーザが１９９９年１２月１２日の２０：３０にサービスＸ上で送信されるサービスを２時間にわたってレコーディングすることを望むと仮定する。図１の例では、チューナタイプの単一のリソース及びトランスコーディングタイプの単一のリソースがネットワーク中に存在するが、ユーザは、同じタイプのリソースが複数共存するネットワークにおいてネットワークの同じタイプの複数のリソースの中から動作を実行するのに関与させることを好むものを選択し得る。
【００３２】
ターゲットリソース９がアプリケーション２からプログラムされた動作を受信するとき、ターゲットリソース９は、本開示の最初に述べた第２の特許出願中で説明する方法で進行させることによってローカルリソースマネージャ１０と自動予約を実施する。更に、ターゲットリソース９は、関係するリソース（チューナ６、トランスコーダ１２）、の予約をリモートリソースマネージャ（夫々マネージャ７、１３）と実施する。各リソースマネージャは、それに関係するリソース（つまり、このリソースマネージャと同じ実行プラットホームを有するリソース）の予約に関するデータを記憶する。
【００３３】
一旦予約がなされると、ターゲットは、動作が元々生じたアプリケーション２に確認メッセージを送信する。
【００３４】
予約が衝突する場合、例えば、別の動作をプログラムするアプリケーションによって与えられた動作のために既に予約されたリソースに対するオーバーライド又は交渉の場合、リソースマネージャは、第１の動作をプログラムしたターゲットに対して適当なメッセージで忠告する。実際に、この目的のために、各リソースマネージャは、予約を行ったソフトウェアモジュールの識別子又はアドレスを記憶する。
【００３５】
この際、機器１のプラグが抜かれたとしても動作に関する情報が全てターゲットのレベルで記憶されているため予めプログラムされた動作は実行される。
【００３６】
ユーザは、アプリケーション４のような別のアプリケーションから予めプログラムされた動作を変更又は削除し得る。アプリケーション４が（アプリケーションのローカルレジストリーによって見つけられる）所与のリソースに関する全てのプログラムされた動作をアクセスすることを望む場合、アプリケーションによって接触されるリソースは、関連する各プログラムされた動作のメインリソースの識別子を提供し得る。プログラムされた動作を説明するデータ構造全体は、その後、各メインリソースに直接接触することで引き出され得る。
【００３７】
動作が始動されると、ターゲットは、コネクションマネージャ（又は、HAVi仕様書の用語によると「Stream  Manager」を表わす「SM」）として称されるローカルソフトウェアモジュールによって様々なリソースを連結させる。
【００３８】
リソースは、機能コンポーネントマネージャ（HAVi用語によると「FCM」）といった用語の下で明示され得る。アーキテクチャは、図３によって表わされ得、ここではアプリケーションは、ターゲットの一部を形成するアプリケーションプログラミングインタフェースに動作プログラミングを送信する。
【００３９】
より一般的には、FCM以外のリソースがHAViの枠内に存在する。例えば、「Device  Control  Manager」を意味する「DCM」又は選択的に機器を制御するマネージャとして称される別のタイプのリソースが存在する。FCMは、機器の機能のソフトウェア表示であり、DCMは、機器のソフトウェア表示でありこれに関して複数のFCMを組み込み得る。このときDCMは、予約を行うメインアプリケーションとDCM中に含まれる１つ以上のFCMの間の中間媒介物である。
【００４０】
例２
第２の実施例は、図２に示す。第１の実施例におけるようにリソースが予めプログラムされた動作を管理することができるアプリケーションを組み込まないと仮定する。この場合を一般的に「受動リソース」と称する。しかしながら、この受動リソースは、第１の実施例に示すようにこれらのデータのうち幾つか（例えば、実施しなくてはならない動作の時間表並びに可能であればパラメータ及びユーザデータ）を記憶してもよい。
【００４１】
動作プログラミングを始動するクライアントアプリケーション１５は、第１の例におけるようにテレビジョンセット１６中に配置されたインタフェースである。レコーディング機器１７は、ディジタルレコーディングリソース１８と、別のリソース１９と、リソースマネージャ２０とを有する。機器５は、図１の機器５と同一である。
【００４２】
本実施例によると、機器１７は、予めプログラムされた動作マネージャ２１（「PAM」）を有する。この動作マネージャ２１は、HAVi仕様書の意味内のサービスであり、動作の実現に要求される全ての予約を行う。予めプログラムされた動作マネージャとリソースマネージャの間で機能的な差は一つだけある。予めプログラムされた動作マネージャは、予めプログラムされた動作を管理し、リソースマネージャは、動作に対応する予約及び結果として起こってもよい全ての衝突を管理する。これら２つの機能は、図２に示すように一つの同じソフトウェアオブジェクト中に組み込まれ得る。PAM及びRMの別々の表示は、単に第１の実施例と一致するように使用され、第１の実施例ではこれらの機能は別個のオブジェクトによって実行されている。
【００４３】
動作マネージャ２１は、機器１７及び機器５の受動リソースを管理する。
【００４４】
第２の実施例による予めプログラムされた動作の実行は、
−クライアントアプリケーションと、
−予めプログラムされたマネージャ（「PAM」）と、
−予めプログラムされた動作を実行するのに要求される「関係するリソース」と称される一つ以上のパブリックリソースとを含む。
【００４５】
レコーディング要求の枠内において、関係するリソースは、例えば、ディジタルレコーディング機器（ディジタルビデオレコーダ、ＤＶＤ等）のレコーディングファシリティであるチューナである。
【００４６】
他のリソース、例えば、データのフォーマットをレコーディング機器のフォーマットに変換するのに要求されるトランスコーダ、プログラムを得るためにアクセスを認可するアクセス制御サービス等が要求されてもよい。
【００４７】
動作がプログラムされる表示機器が不活性とされた場合（例えば、プログラミングに関してユーザにビデオレコーダの機能を提供したテレビジョンセットをユーザがオフにした場合）でさえも、通常通り動作させるよう予めプログラムされた動作を実行するプロセスのための要求が考慮される。結果として、この機器は、関係するリソースを含まないことが好ましい。
【００４８】
予めプログラムされた動作マネージャは、クライアントアプリケーションによって要求される動作を承認する又は承認しない。クライアントアプリケーションは、動作の実現に必要なリソース、動作の始動時間に実施されるべきコマンド、及び、動作の始動時間前に確立されるべき必要がある異なるリソース間で要求されるコネクションを前に識別した。
【００４９】
PAMは、動作のこれら全てのデータを記憶し、クライアントアプリケーションに対して動作の識別子を返す。更に、各関係するリソースは、実施されるべき動作について夫々の予定表を記憶する。この予定表は、特に、予約の時間表を含むが動作に関連するコマンド及びコネクションを含まない。これは、非常に大きいメモリの空きを必要とする。この予定表により、各リソースは、動作を開始する他のPAMに対してこれらの動作に対するその利用可能性及び利用不可能性を通知し得る。
【００５０】
動作に対する要求を承認又は拒否する前に、PAMは、動作の始動時間と終了時間の間で利用できるか否かを確認にするために各リソースを問い合わせる。動作の始動時間において、全てのリソースが存在する場合、PAMは、リソースを予約し（ここでは、前にプログラムされた簡単な予定表表示と比較して予約プロパーを必然的に伴い）、必要なコネクションを確立し、コマンドを開始する。コネクションの確立は、コネクションマネージャ（又は、HAVi仕様書の用語によると「Stream  Manager」を表わす「SM」）として称されるローカルソフトウェアモジュールによって要求される。
【００５１】
予めプログラムされた動作に関係するリソースの一つが動作の始動時間前になくなる場合、動作は、リソースがネットワーク上で再び利用できるようになるまでサスペンドされる。予めプログラムされた動作の始動時間の後でもなくなったリソースが現われた場合、時間的にはずれるが動作は実行される。
【００５２】
予めプログラムされた動作は、幾つかの情報アイテムによって定義され得、これらアイテムは、動作をプログラムするアプリケーションによって提供される特定のデータ構造中で集められ、第２の実施例により予めプログラムされた動作マネージャによって記憶される。
【００５３】
−動作のタイプ
−動作（各関係するリソースに関して実施されるべきコマンド、動作を開始する前に確立されるべきコネクションのリスト）に関連するパラメータ
−日付
−開始時間
−終了時間
−動作の周期性
−関係するリソースの識別子
−ユーザデータ
様々な要素は、第１の実施例に従って説明されたと同じ意味を有する。
【００５４】
どの予めプログラムされた動作が所与のリソースと関連するかを確認することをアプリケーションが望む場合、アプリケーションは、PAMにレコーディングされた全てのプログラムされた動作を問い合わすし得る。アプリケーションは、リソースからこのリソースが関連する各予めプログラムされた動作の識別子を要求し得る。従って、アプリケーションは、所与の予めプログラムされた動作のデータを保持するPAMの識別子を引き出し得る。
【００５５】
アプリケーションは、この動作を担当するＰＡＭにおいて予めプログラムされた動作をキャンセル、又は、このような動作を変更する可能性を有する。
【００５６】
関係するリソースの識別子は、第２の実施例によってＰＡＭに使用される。リストは、例えば、レジストリーを通じて、又は、関係するリソースに直接メッセージを送信することによって関係するリソースに関する情報をＰＡＭが要求することを可能にする。
【００５７】
ＰＡＭは、各リソースに要求される全てのパラメータを含み関係するリソースの機器制御マネージャ（ＤＣＭ−以下参照）に予めプログラムされた動作を分配する。各リソース（又は夫々のＤＣＭ）は、要求されるコネクション及び認識されるコマンドが認識された時間に実施されるか否かを決定しなくてはならない。
【００５８】
リソースが要求を尊重することができる場合、リソースは、これをPAMに対して忠告し、PAMは、動作が受け入れられたことをシグナリングするために動作の識別子をクライアントアプリケーションに返す。
【００５９】
リソースが要求を尊重することができない場合、又は、要求されたリソースの一つがネットワーク上に存在しない場合、或いは、さもなければ、別の動作の枠内での関連し既に予約されたリソースのオーバーライドが可能でない場合、PAMは、予めプログラムされた動作を拒否し、適当なメッセージをクライアントアプリケーションに送信する。
【００６０】
予約の衝突の場合、例えば、利用できないリソースのオーバーライド又は交渉の場合、PAMは、動作をプログラムしたクライアントアプリケーションに適当なメッセージで忠告する。実際に、この目的のために各PAMは、予約を行ったアプリケーションの識別子又はアドレスを記憶する。
【００６１】
リソースは、機能コンポーネントマネージャ（HAVi用語によると「FCM」）といった用語の下で明示され得る。アーキテクチャは、図３によって表わされ得、このとき、アプリケーションは、ターゲットの一部を形成するアプリケーションプログラミングインタフェースに動作プログラミングを送信する。
【００６２】
より一般的には、FCM以外のリソースがHAVi枠内に存在する。「Device  Control  Manager」を表わす「DCM」又は選択的に機器制御マネージャとして称される別のタイプのリソースが同様に存在する。FCMは、機器の機能のソフトウェア表示であり、DCMは、機器のソフトウェア表示でありこれに関して複数のFCMを組み込み得る。このときDCMは、予約をするメインアプリケーションとDCM中に含まれる１つ以上のFCMの間の中間媒介物である。
【００６３】
図４は、第２の実施例の原理の簡略化された図である。要約するに、動作をプログラムするためにアプリケーションは、ターゲットリソースを有する機器中で必然的に存在する予めプログラムされた動作マネージャにアプリケーション自身をアドレス指定する。アプリケーションは、動作マネージャのプログラミングインタフェースを通じて動作し、この動作マネージャは、反対に、ターゲットのプログラミングインタフェースを通じて動作する。マネージャ及びターゲットを有する機器は、完全なファシリティ（「FAV」）を含む機器、又は、中間のファシリティ（「IAV」）を含む機器のいずれか一方である。
【図面の簡単な説明】
【図１】  第１の実施例による動作方法を表わす家庭内ネットワークの部分を示す図である。
【図２】  第２の実施例による動作方法を表わす家庭内ネットワークの部分を示す図である。
【図３】  第１の実施例によるデータ交換を示す図である。
【図４】  第２の実施例によるデータ交換を示す図である。
【図１】
0004647097.tif 000004
【図２】
0004647097.tif 000005
【図３】
0004647097.tif 000006
【図４】
0004647097.tif 000007