(57)【要約】【課題】複数の装置間の通信用のデジタルネットワークが、開示される。【解決手段】ネットワーク装置が、ネットワーク上のデータを送信するためのソースとネットワークからデータを受信するためのシンクとを有する。階層化優先度マネージャが、ソースとシンクとの間の接続を管理する。接続を設定する前に、それらは、他のマネージャと交渉して、接続を設定するための権利を獲得するために、最初にネゴシエーションアドミニストレータに問い合わせる。より上位の優先度を有する全ての他のマネージャもまた、接続を許可した場合、マネージャはソースとシンクとを接続する。【選択図】図１
2008532375.tif 000002
【特許請求の範囲】
【請求項１】
複数の装置間の通信のためのデジタルネットワークであって、
−  前記ネットワーク上でデータを送信するためのソースを有する少なくとも１つの装置と、
−  前記ネットワークからデータを受信するためのシンクを有する少なくとも１つの装置と、
−  その他の装置あるいはアプリケーションと通信しておよび／またはそれらを制御するアプリケーションを有する少なくとも１つの装置と、を備えるとともに、
データが、ソースとシンクとの間の接続によってソースからシンクにだけ伝達されるデジタルネットワークにおいて、
装置の管理のためのマネージャを有する少なくとも１つのアプリケーションが、
−  接続されるべき少なくとも１つのソースと少なくとも１つのシンクを選択し、
−  少なくとも１つの選ばれたソースを少なくとも１つの選ばれたシンクに接続するように構成され、
全てのマネージャが割り当てられた優先度を有し、かつ、少なくとも１つのマネージャが、
−  より上位の優先度を有する他のマネージャと交渉し、かつ選ばれたソースとシンクを特に接続する権利を要求するように、かつ、
−  ソースとシンクの選択を、特にそれらのソースとシンクに限定する、ように構成され、そのために、少なくとも１つの選ばれたソースを少なくとも１つの選ばれたシンクに接続し、あるいは制御する前に、接続が他のマネージャによって許可されることを特徴とするデジタルネットワーク。
【請求項２】
前記マネージャの優先度が、各々のマネージャに固有であることを特徴とする請求項１に記載のデジタルネットワーク。
【請求項３】
少なくとも１つのマネージャが、
−  前記ネットワーク上の利用可能なソースとシンクに対して問い合わせ、
−  選ばれた装置からステータス情報を取り出す、ように構成される
ことを特徴とする請求項１または２に記載のデジタルネットワーク。
【請求項４】
少なくとも１つのマネージャが、少なくとも１つの他のマネージャによってネットワーク帯域幅の限定された許可に従ってその選択を更に限定するように構成されることを特徴とする請求項１〜３のいずれか１項に記載のデジタルネットワーク。
【請求項５】
少なくとも１つのマネージャが、好ましくはより上位の優先度を有する全ての他のマネージャと交渉するように構成されることを特徴とする請求項１〜４のいずれか１項に記載のデジタルネットワーク。
【請求項６】
少なくとも１つのマネージャが、
−  最下位優先順位を有する前記マネージャを識別するための手段と、
−  最上位優先度を有する前記マネージャを識別するための手段と、
−  前記最上位および／または最下位優先度および／または指定されたマネージャの優先度、から始まるそれらの優先度に従って連鎖内の全てのマネージャに問い合わせるための手段と、
−  これらのシンクあるいはソースに対するアクセスを許可するためのより上位の優先度を有する全てのマネージャに問い合わせた後にだけ、シンクあるいはソースにアクセスするための手段と、を有することを特徴とする請求項１〜５のいずれか１項に記載のデジタルネットワーク。
【請求項７】
少なくとも１つのネゴシエーションアドミニストレータが、選ばれたマネージャに対して選ばれたソースを選ばれたシンクに接続するための権利を割り当てるよう設けられ、かつ、少なくとも１つのマネージャが、少なくとも１つの選ばれたソースを少なくとも１つの選ばれたシンクに接続し、あるいは制御する前に、前記少なくとも１つのネゴシエーションアドミニストレータから、ソースとシンクを接続する権利を要求するように構成されており、かつ、このマネージャが更に、ソースとシンクを前記少なくとも１つのネゴシエーションアドミニストレータに接続する権利を解放するように構成されることを特徴とする請求項１〜６のいずれか１項に記載のデジタルネットワーク。
【請求項８】
少なくとも１つのマネージャが、好ましくは、それが前記ネットワーク内の最上位優先度を割り当てた時に、ネゴシエーションアドミニストレータの役割を引き継ぐように構成されることを特徴とする請求項６に記載のデジタルネットワーク。
【請求項９】
少なくとも１つのマネージャが、少なくとも１つのシンクおよび／またはソースを追加し、かつ／または少なくとも１つの他のマネージャから受信される情報で少なくとも１つの追加の装置に連結するように構成されることを特徴とする請求項1〜８のいずれか１項に記載のデジタルネットワーク。
【請求項１０】
少なくとも１つのマネージャが、接続の許可を受信した後に、あるいは少なくとも１つのソースと少なくとも１つのシンクを接続した後に、より下位の優先度マネージャに対する確立された接続を公開するように構成されることを特徴とする請求項１〜９のいずれか１項に記載のデジタルネットワーク。
【請求項１１】
仮想ソースおよび／または仮想シンクが、他の装置によって接続されるソースあるいはシンクを有しない装置を提供されることを特徴とする請求項１〜１０のいずれか１項に記載のデジタルネットワーク。
【請求項１２】
少なくとも１つのマネージャが、
−  前記最上位優先度マネージャに解除要求を送信し、そこからそれは低下する優先度を有する他のマネージャまで渡され、かつそこで各々のデバイスマネージャがなお必要なソースとシンクを指定し、
−  指定されてないソースとシンクの割当てを全て解除する、ことによって接続を解除するように構成されることを特徴とする請求項１〜１１のいずれか１項に記載のデジタルネットワーク。
【請求項１３】
少なくとも１つの装置が、前もって規定されたプロファイルに従って前記要求を適応させるプロファイラを有することを特徴とする請求項１〜１２のいずれか１項に記載のデジタルネットワーク。
【請求項１４】
少なくとも１つのガーベジコレクションマネージャが、未使用の接続を解除するように設けられ、かつ、前記ガーベジコレクションマネージャは、好ましくは前記ネットワークにおいて最下位優先度を有し、かつ、好ましくは全ての接続されたリソースに接続解除要求を送信することを特徴とする請求項１〜１３のいずれか１項に記載のデジタルネットワーク。
【請求項１５】
少なくとも１つのＨＭＩが、記述子ベースのアクセスを備えていることを特徴とする請求項１〜１４のいずれか１項に記載のデジタルネットワーク。
【請求項１６】
代替ネットワークソースと代替ネットワークシンクの機能ブロックを含んで設けられる異なるネットワーク種類のフレームをトンネルするための少なくとも１つの手段からなることを特徴とする請求項１〜１５のいずれか１項に記載のデジタルネットワーク。
【請求項１７】
少なくとも１つのマネージャであって、
−  空いていると推定されるグループアドレスを生成し、
−  このアドレスを上昇する優先度を有する他のマネージャに要求し、
−  最上位優先度を有する前記マネージャが前記アドレスを確認したあと、前記グループアドレスをソースとシンクに割り当て、
−  別のグループアドレスを生成し、かつ、これを他のマネージャから要求すると共に、再び始めるか、あるいは、任意のマネージャが前記要求を拒否した場合に中断する、ことによって、グループキャストのための空いているグループアドレスを見いだすように構成されている、少なくとも１つのマネージャとからなることを特徴とする請求項１〜１６のいずれか１項に記載のデジタルネットワーク。
【請求項１８】
請求項１〜１７のいずれか１項に記載のネットワークにおいてネットワークリソースを解放するための方法において、
−  前記最下位優先順位を有する前記マネージャに、要求マネージャによって解放要求を送信し、前記解放要求が、それらが全部の要求をカバーすることができない場合、いかなるリソースも解放しないようにマネージャに告げるフラグを含む工程と、
−  マネージャが前記全部の要求をカバーすることができる場合、それは前記要求されたリソースを解放して、前記要求マネージャに利用可能性を確認する工程と、
−マネージャが前記全部の要求をカバーすることができず、かつ、「一部の解放禁止」フラグが設定される場合、マネージャは、それが前記解放要求においてこのために確保されているフィールドに寄与することができる分量を追加する。この「拡散リソース発見」フィールドが１００％に到達する場合、前記「一部の解放禁止」フラグは除去され、および、前記要求は、前記最下位優先度を有する前記マネージャへ戻される工程と、
−  前記要求が前記要求マネージャに戻る場合、前記下位のマネージャは解放する前記リソースの前記要求された分量を有しない。したがって、前記マネージャは、接続するのを中止しなければならない工程と、
−  マネージャが設定されない前記「一部の解放禁止」フラグを伴わずに前記解放要求を受けとる場合、それは、前記「拡散リソース発見」フィールドマイナスその自身の部分が１００％以上かどうか調べる。もしそうならば、それは、何も解放することなく、上方向へ、より上位の優先度を有するマネージャに、前記要求を渡す工程と、
−  さもなければ、それはその割り当てられたリソースを解放して、前記要求量から前記解放された部分を除去して、それが完全に満たされない場合、上方向へ前記要求を渡す工程とからなることを特徴とする方法。
【請求項１９】
複数の装置間の通信用のデジタルネットワークのためのマネージャにおいて、
前記マネージャが、優先度を割り当て、かつ、
−  利用可能な、前記ネットワーク上でデータを送信するためのソースと、前記ネットワーク上で前記ネットワークからのデータを受信するために引き込むシンクと、を問い合わせ、
−  選ばれた装置からステータス情報を取り出し、
−  接続されるべき、少なくとも１つのソースと少なくとも１つのシンクとを選択し、
−  より上位の優先度を有する他のマネージャと交渉し、かつ、選ばれたソースとシンクを特に接続する権利を要求し、かつ、
−  前記ソースとシンクの選択を、接続が前記他のマネージャによって許可されたそれらのソースとシンクに特に限定し、
−  少なくとも１つの選ばれたソースを少なくとも１つの選ばれたシンクに接続するように構成されることを特徴とするマネージャ。
【請求項２０】
複数の装置間の通信のためにネットワーク内のネットワーク装置を管理するための方法において、
−  全てのマネージャに優先度を割り当てる工程であって、割り当てられる前記優先度が好ましくは各々のマネージャに固有である工程と、
−  少なくとも１つのマネージャによって、利用可能な、前記ネットワーク上でデータを送信するためのソースと、前記ネットワーク上で前記ネットワークからのデータを受信するために引き込むシンクとを問い合わせる工程と、
−  前記少なくとも１つのマネージャによって選ばれた装置からステータス情報を取り出す工程と、
−  前記少なくとも１つのマネージャによって接続されるべき少なくとも１つのソースと少なくとも１つのシンクとを選択する工程と、
−  少なくとも１つの選ばれたソースを少なくとも１つの選ばれたシンクに接続する工程と、
−  より上位の優先度を有する他のマネージャと交渉し、
前記少なくとも１つのマネージャによって、選ばれたソースとシンクを特に接続する権利を要求する工程と、
−  前記少なくとも１つのマネージャによって、前記ソースとシンクの選択を、接続が前記少なくとも１つのネゴシエーションアドミニストレータによって許可された、それらのソースとシンクに特に限定する工程と、
−  前記少なくとも１つのマネージャによって、少なくとも１つの選ばれたソースを少なくとも１つの選ばれたシンクに接続する工程とからなることを特徴とする方法。
【請求項２１】
−  他のマネージャと交渉する前に、少なくとも１つのネゴシエーションアドミニストレータから他のマネージャと交渉する権利を要求する工程を更に含むことを特徴とする請求項２０に記載の方法。
【請求項２２】
少なくとも１つのガーベジコレクションマネージャによって未使用の接続を解除する工程であって、前記ガーベジコレクションマネージャは、好ましくは前記ネットワークにおいて最下位優先度を有する工程を更に含むことを特徴とする請求項２０または２１に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、共通ネットワークによって住宅内の幅広い種類の電子装置を接続する分散形ネットワークシステムに関するものである。
【背景技術】
【０００２】
家庭用の最新のマルチメディアネットワークにおいて、いくつかの装置が、共に接続される。この種の装置は、テレビセットあるいはＤＶＤプレーヤの類の複合マルチメディア装置であることができる。それらは、また、温度調節器の類のより複雑でない装置、あるいはブラインドアクチュエータあるいは照明スイッチの類のさらに非常に単純な装置でさえあることができる。全てのこれらの装置は、共通ネットワークによって共に接続される。
【０００３】
マルチメディアネットワーク用の一般的な規格は、ＨＡＶＩ規格である。この規格に基づくホームネットワークが、特許文献１において開示されている。この規格は、単純な「ベースノード」から複雑な「完全ノード」まで異なる能力を有する異なるノードを記述する。１つの欠点は、相対的に単純な「ベースノード」でさえ、他のノードと通信するために複雑で高価なインタフェースハードウェアを必要とすることである。さらに、以下のシナリオに記載されているように、リソース競合の解決のための満足な機構が、全くない：第１の家庭居住者が、浴室でなにかの音楽を聞いている。キッチンにいる別の人が、浴室を呼び出すためにインターコムを使用する。この会話中に電話の呼出しが着く。その時、浴室のスピーカにアクセスを必要とする３つのアプリケーション（音楽、インターコムおよび電話）がある。その時、アプリケーションは互いに影響する。アプリケーションの音楽は、アプリケーションのインターコムによって影響される。両方とも、アプリケーションの電話によってさらにまた影響される。
【０００４】
リソースの競合は、マスターコントローラ、例えば中央リソースマネージャとして働くことができる「完全ＡＶノード」によってだけ解決されることができる。したがって、非常に複雑な中央コントローラが、必要とされる。
【０００５】
例証の家庭において、我々はインターコムがＤＶＤプレーヤとは異なるメーカからのものであろうと予想しなければならない。さらに、ＤＶＤプレーヤは、ネットワークの設置の後で、もっと後の時にネットワークに追加されたかもしれない。これは、それらが構築時に互いに知られていなかった場合、アプリケーションは意味がある方法でどのように互いに影響することができるかという問題に至る。また特許文献１において、更新されたソフトウェアを取り出すことによって、システムを更新するための高機能な更新方法を用いる解決策が、提供されている。しばしば、ソフトウェアのインポートは、信頼性および安定性理由のために、あるいは単にいくつかの装置が更新可能でないので、受け入れられることができない。さらに、高機能な更新処理機構は、少なくとも１つの複雑な「完全ノード」を必要とする。
【特許文献１】ＥＰ  １  ０４４  ５３６  Ａ１
【発明の開示】
【発明が解決しようとする課題】
【０００６】
本発明は、幅広い種類の異なる電子装置を接続することができ、完全プラグアンドプレイ機能を提供し、中央ユニットなしで動作し、かつ装置内に容易に導入されることができ、したがって、低いメモリ容量およびＣＰＵパワーだけを必要とする、ネットワークシステムを提供するという課題に基づいている。さらに、それはＭＯＳＴ規格に互換とするべきである。
【０００７】
この課題に対する１つの発明の解決策が、独立請求項に規定される。本発明の改良点は、従属請求項の主題である。
【課題を解決するための手段】
【０００８】
本発明は、階層化リソース管理のためのコンポーネント、したがって、装置マネージャ、およびネットワーク内のリソースを管理するための手続きを備えるネットワークに関する。
【０００９】
本発明は、分散ネットワークの概念に基づく。発明のディジタルマルチメディアネットワーク（電話、インターコムなど）の大部分のアプリケーションは、ソフトウェアを備える。アプリケーションは、以下を実行する：
−  利用可能なソースとシンクに対して問い合わせる。したがって、ネットワークはスキャンされる必要がある。各々の装置から、特定の機能およびステータス情報が、取り出される必要がある。
−  ソースをシンクに接続する（例えば、チューナを増幅器に接続する）。
−  ソースおよびシンクを制御する（例えば、チューナで無線局を変更する、増幅器でボリュームを調整する、など）。
【００１０】
スキャンおよび制御のために、アプリケーションは各々のソースと各々のシンクに対する制御チャンネルを必要とする（図３）。
【００１１】
ソースとシンクを接続するアプリケーションの部分は、マネージャと呼ばれている。好ましくは、マネージャはアプリケーションに対して規格化されたインタフェースを提供する。各々のマネージャは、自分自身の接続に対して責任を負う。マネージャは、例えば、シンクにストリームを消費させることなく、ソースのストリーミングを始めてはならない。また、もし接続されたシンクがまだあるならば、マネージャはソースのストリーミングを止めてはならない。さらに、接続はマネージャによってだけ確立されることができる。これは、ソースが、ストリーミングを決して単独で始めず、これは、常にマネージャによって起動され、かつシンクはデータを決して単独で消費し始めず、これもまた、常にマネージャによって起動される、ことを意味する。
【００１２】
ソース、シンクおよびマネージャは、異なる装置にわたって分散されることができるが、それらはまた、いくつかの装置に、あるいは１つの装置にさえ統合されることができる。
【００１３】
システムのモデルへのマネージャの導入は、アプリケーションを互いに視認できるようにする第１の工程である。一旦それらが互いをアドレスすることができると、それらは共用リソースに対するアクセスを交渉することが可能である。
【００１４】
加えて、少なくとも１つのプロファイラが、提供されることができる。さらに、少なくとも１つであるが、好ましくは正確に１つのネゴシエーションアドミニストレータが、設けられることができる（図７）。ネットワークがまた、これらの装置なしでも機能するにもかかわらず、これら全てが、ネットワーク機能を強化する。これら全ては、それらが、例えばＪａｖａ（登録商標）コンソール上に実装され、あるいは、また、パーソナルコンピュータ上のソフトウェアとして実装されることができる、従来技術と比べてあまり多くのメモリあるいは多くの計算能力を必要としないので、任意の装置に、同じく単純なマイクロコントローラに実装されることができる。
【００１５】
別の実施例において、競合する状態の解決のために、優先度レベルがマネージャに割り当てられる。好ましくは、最上位優先度はネゴシエーションアドミニストレータが所有しており、それが全ての他のマネージャにアクセス権を割り当てる。ネゴシエーションアドミニストレータは、任意のマネージャあるいはアプリケーションの一部とすることができる。好ましくは、最上位優先度を有するマネージャが、ネゴシエーションアドミニストレータとして選択される。下位の優先度レベルは、アプリケーションの重要性に従ってマネージャに割り当てられる。アプリケーションの異なるインスタンスのマネージャさえ、異なる優先度を有するべきである。最下位優先度レベルは、装置に割り当てられる。全てのマネージャは、同じ優先度を有することができる（図８）。
【００１６】
一般に、任意の装置および任意のマネージャに対して、ネゴシエーションアドミニストレータおよびプロファイラに対してさえ、任意の優先度レベルが、割り当てられることができる。これは、ネットワークのふるまいの非常に詳細な調整を可能にする。例えば、火災警報は前述のようにネゴシエーションアドミニストレータの上に設定されるだろう。これは、高位優先度の火災警報が、全てのリソースに対する即時アクセスを有することを可能にする。
【００１７】
この階層モデルはいくつかの利点を有する。もしあるマネージャがシステムから取り出されるならば、残りのマネージャの序列は変化しない。さらに、優先度レベルは動的に変更されることができる。したがって、浴室のユーザーは、次の時間の間、音楽が電話より重要であると選択することができる。最後に、不正なセットアップは、可能でない。これは、そのマネージャが任意の優先度レベルを設定させた装置が接続されるであろう、プラグアンドプレイシステムにとって非常に重要になる。
【００１８】
同じ優先度を有するマネージャによって引き起こされる潜在的競合は、装置のノード位置に従って優先度を割り当てることによって解決されるだろう。もしいくつかのアプリケーションが１つのノード内にあるならば、インスタンスＩＤあるいはその他の物理アドレスあるいは論理アドレスを使用することができる。この機構は、基本優先度序列を変更するべきでないが、互いに対して同じ優先度をすでに有するマネージャの優先度を調整するべきである。
【００１９】
調整のために、設定はユーザーによって変更されることができる。各々のマネージャに固有の優先度を割り当てたあと、優先度連鎖が得られる。
【００２０】
シンクをソースに接続するために、マネージャは特定のプロトコルに従わなければならない。もし１つのシステム内に複数のマネージャがあるならば、ソースをシンクに直接接続することは許可されない。好ましい接続手順は、以下の基本工程を備える：
１．ソースアクセスとシンクアクセスを交渉する権利を獲得する。
２．より上位の優先度マネージャから所望のセットの接続を要求する。
３．全てのマネージャに許可された接続を公開する。
４．必要なネットワーク帯域幅を獲得する。
５．接続を確立する。
６．ソースアクセスとシンクアクセスを交渉する権利を解放する。
【００２１】
以下、これらの基本工程の詳細について説明する。
【００２２】
１．ソースアクセスとシンクアクセスを交渉する権利を獲得する。
【００２３】
より大きいネットワークにおいて、２つのアプリケーションが、ソースとシンクとの間の新しい接続を同時に計画し始める可能性がある。ユーザーがＤＶＤプレーヤの再生ボタンを押すのと同じ瞬間に電話呼出しが到着するという、典型的な場合があるだろう。その時、両方のアプリケーションのマネージャが、平行してもう一方の利用可能なアプリケーションと、必要なリソースに対するアクセスについて交渉し始めると、２つのマネージャが互いを混同する可能性があるので、結果は容易に予測不可能になることがありえる。したがって、本発明によれば、必要とされたリソースに対するアクセスについて交渉する権利は、直列化される。大きなシステムにおいてさえ、同時性がめったに生じないこと、そして、ソースとシンクに対するアクセスについて交渉することは、通常数ミリ秒かかるだけである、という前提条件の下で、これは、実際的な制約ではない。
【００２４】
同時に本発明の別の実施例において、１つのマネージャだけが、ソースとシンクに対するアクセスについて交渉することを可能にされる。
【００２５】
別の実施例において、もしあるアプリケーションのマネージャがいくつかのソースとシンクに対するアクセスについて交渉する権利を獲得するならば、それは、そのマネージャがすでにソースとシンクにアクセスするための権利を獲得していることを意味しない。それは、マネージャが、これらのソースとシンクをそれら自身で使用することを望むであろう、その他の設置されたマネージャとアクセスについて交渉することができることだけを意味する。
【００２６】
本発明に従う実際的なプラグアンドプレイシステムにおいて、好ましくは定義上中心点がない（図１１）。したがって、１つのネゴシエーションアドミニストレータが、全てのマネージャから選択される。それで、各々のマネージャは、選択された場合、ネゴシエーションアドミニストレータの役割を引き継ぐための機能を有するべきである。
【００２７】
別の実施例において、ネットワークのマネージャの１つが、この役目を実行するのに選択されなければならない。本発明によれば、これは最上位優先度レベルを有するマネージャである。始動中に、どのマネージャが最上位優先度レベルを有するものであるかを見いだすために、各々のマネージャがネットワークをスキャンする。このマネージャが、次にネゴシエーションアドミニストレータの機能を実行する。もしこのマネージャが実行時間中にプラグを抜かれるならば、次のより上位のマネージャが引き継ぐ、などとする。
【００２８】
代替実施例において、ネゴシエーションアドミニストレータは、別々の物理ユニットあるいは論理ユニットとすることができる。
【００２９】
マネージャが交渉し始める前に、それは、最上位優先度レベルを有するマネージャである、ネゴシエーションアドミニストレータから交渉する権利を要求する。もしこのマネージャがすでに別のマネージャに権利を許可していたならば、それは、要求を拒否する。この要求マネージャは、所定の時間、好ましくは２０ｍｓあるいはランダムにあるいは動的に割り当てられた時間を待って、次いで再試行する。もし他のいかなるマネージャも交渉する権利を保持していないならば、要求マネージャがこの権利を獲得する。
【００３０】
マネージャが交渉したあと、それはネゴシエーションアドミニストレータに権利を戻す。もし要求されたならば、これは次いで別のマネージャにそれを渡すことができる。
【００３１】
２．より上位の優先度マネージャから所望のセットの接続を要求する。
【００３２】
別の実施例において、あるアプリケーションのマネージャがその計画されたセットの接続について交渉する権利を獲得したあと、それはより上位の優先度マネージャからこれらの接続を要求しなければならない。したがって、それは次のより上位の優先度レベルを有するマネージャに、接続要求を渡す。もしこのマネージャがこの接続要求を拒否しないならば、このマネージャは次のより上位の優先度レベルを有するマネージャに、再びそれを渡し、そして以下同様である。接続要求が渡されることができるマネージャが上にないならば、この要求は、要求マネージャへ戻され、それが、最後にシンクとソースに対するアクセスを獲得して、そして次に、接続を確立する（図１２）。この手続きは、マネージャの種類から独立している。それらが次のより上位の優先度を有しながら、最初に問い合わせられるマネージャが、あるかもしれない。利用可能であれば、それがより上位の優先度を有するように、プロファイラが後で問い合わせられることができる。
【００３３】
次のより上位の優先度レベルを有するマネージャに要求を渡す、あるいは要求マネージャへ戻す前に、任意のマネージャが、要求を変更することができる。それは、リソースを追加し、あるいは除去してもよく、あるいはパラメータを変更してもよい。こうすることによって、より上位の優先度アプリケーションによって使用されるリソースに対するアクセスは、制限されることができ、あるいは拒否されさえすることができる（図１２）。
【００３４】
別の実施例において、ソースは追加のアプリケーションを通じて送られてもよい。これは、オーディオイコライザのような補助装置に連結するために使用されてもよい。こうするために、ソースはオーディオイコライザのシンクに接続され、および、オーディオイコライザのソースは最終的シンクに接続される。
別の実施例において、フラグが要求内に設けられることができ、要求の変更を防ぐことができる。このフラグは、要求マネージャによって設定されることができる。もし要求が変更なしで許可されることができないならば、それはその時拒絶される。
【００３５】
更なる実施例において、プロファイルに従う要求に適応する、少なくとも１つのプロファイラが設けられる。この種のプロファイルは、ユーザーによってあらかじめ決められることができ、かつ／または設定されることができ、あるいは、ネットワークの構成変更の際に、あるいはネットワーク装置のパラメータに依存して、動的に割り当てられることができる。プロファイラは、また、マネージャによって表される。一般的に、プロファイラのマネージャは、高位優先度を有する（図１３）。
【００３６】
本発明の別の実施例において、仮想ソースおよび／または仮想シンクとしての少なくとも１つの仮想装置が、設けられる。これらの仮想装置は、他の実際の装置あるいは仮想装置との接続を可能にするためのソフトウェアによって生成される（図１４および１５）。
【００３７】
３．全てのマネージャに許可された接続を公開する。
【００３８】
下位優先度のマネージャによって所有されるすでに既存の接続との競合を回避するために、各々の許可された接続が下位優先度のマネージャに公開される。これは、最下位優先度を有するマネージャに対する接続を含有するリストを送信する、要求マネージャによって実行される。そこから、それは優先度連鎖を上方向へ渡される。ソースあるいはシンクがリスト上で次のより上位のマネージャに渡す前に多重接続を受け入れない限り、リストされたソースあるいはシンクを使用して、セットアップ接続を有するマネージャが、これらの接続を解放する。一度最上位優先度マネージャが公開電報を受信すると、それは公開が終わったことを要求マネージャに告げる（図１６、１７）。
【００３９】
４．必要なネットワーク帯域幅を獲得する。
【００４０】
他の好ましい実施例において、ネットワークリソースを解放するための手段が、要求された接続に対してデータを搬送することが可能なチャンネルでネットワーク帯域幅を割り当てるために備えられる。接続を構築するために、アプリケーションのマネージャが必要なネットワークリソースを獲得することができないならば、それらの使用されたネットワークリソースを解放することをより下位の優先度マネージャから要求することができる。システムの最下位優先度マネージャにそのリソースを解放させるために、この要求は、優先度連鎖における最下位マネージャに送信される。もしこのマネージャがこれらのリソースを割り当てるならば、それはそれらを解放して、要求マネージャに、リソース利用可能性を確認する（図２４、２５）。
もしネットワークリソースを解放するよう要求された装置マネージャが要求されたリソースの一部だけを保持するならば、それは、できる限り多くの要求されたリソースを解放して、そして次に、次のマネージャに残りの要求を転送する。拡散リソースを、可能な最下位優先度を有するマネージャから解放する改良された方法は、以下の諸工程を備える：
【００４１】
１．要求マネージャは、最下位優先順位を有するマネージャに解放要求を送信する。解放要求は、もしそれらが全部の要求をカバーすることができないならば、リソースを解放しないようにマネージャに告げる、フラグを含む。
２．もしマネージャが全部の要求をカバーすることができるならば、それは要求されたリソースを解放して、要求マネージャに利用可能性を確認する。
３．もしマネージャが全部の要求をカバーすることができず、かつ「一部の解放禁止」フラグが設定されているならば、マネージャは、それが解放要求のこのために確保されたフィールドに寄与することができる分量を追加する。もしこの「拡散リソース発見」フィールドが１００％に達するならば、「一部の解放禁止」フラグは除去され、そして、要求は最下位優先順位を有するマネージャへ渡される。
４．もし要求が要求マネージャへ戻るならば、下位のマネージャは解放するリソースの要求された分量を有しない。したがって、このマネージャは接続を中止しなければならない。
５．もしマネージャが、設定されない「一部の解放禁止」フラグを伴わない解放要求を受けとるならば、それは、「拡散リソース発見」フィールドマイナスそれ自体の部分が１００％以上であるかどうかを調べる。もしそうならば、それは何も解放せずに上方へ要求を渡す。
６．さもなければ、それはその割り当てられたリソースを解放して、要求分量から解放された部分を除去し、そして、もしそれが完全に満たされないならば、上方向へ要求を渡す。
解放要求は、以下の情報フィールドを備える：
−  解放されるべき要求されたリソースの種類
−  解放されるべきリソースの分量
−  「一部の解放禁止」フラグ
−  「拡散リソース発見」フィールド
−  「拡散リソース解放」フィールド
【００４２】
５．接続を確立する。
【００４３】
本発明によれば、アプリケーションデータは接続経由でだけ送信される。例えばＭＯＳＴ規格で規定されるようなアプリケーションメッセージサービスおよびパケットデータ転送経由の非同期アプリケーションデータの類の基本ネットワーク転送モードは、直接使用されることができない。接続を設定するために、ソース、シンクおよびネットワーク帯域幅が、必要とされる。これは、非同期あるいは同期したチャンネル経由でのような転送の種類から独立している固有の機構である。例えばＭＯＳＴネットワークでは、機能ブロックは、異なる種類の非同期アプリケーションデータとして規定される。接続は、リソースの種類から独立して、もっぱらリソースマネージャによって確立される。
【００４４】
更なる実施例において、異なるネットワーク種類のトンネリングフレーム用の手段が設けられる。この場合に対して、本発明のネットワークはＭＯＳＴ規格に基づいており、イーサネット（登録商標）あるいはその他の類の代替フレームはＭＯＳＴネットワーク中をトンネルされることができる。このために、代替ネットワーク種類のソースとシンク機能ブロックが指定されなければならない。可能な代替ネットワークブリッジデバイスは、両方の機能ブロックを含むだろう。これに加えて、この装置は代替ネットワークアプリケーションを含むだろう。代替ネットワークアプリケーションのマネージャは、代替シンクとソースに対して本発明のネットワークをスキャンし、その局所的ソースを代替シンクに、および局所的シンクを代替ソースに接続しようと試みるだろう。これは、入って来る代替フレームをただブロードキャストするより多くの労力ではあるが、それはいくつかの利点を提供し、複数の、分離されかつ独立した代替ネットワークが、単一の発明のネットワーク上に構築されることができる。さらに、権利管理が、各々の代替ネットワークノードに対する代替ネットワークトンネリングを制御する、システムに追加されることができる。
【００４５】
別の実施例において、ネットワークは少なくとも１セットの並列接続を有するように構成される。
【００４６】
本発明の別の実施例において、ユニキャスト、ブロードキャストおよびグループキャスト接続型の少なくとも１つが、サポートされる。単一のソースから単一のシンクへのメッセージによるアプリケーションデータの送信は、ユニキャストと呼ばれる。もしソースがＮフレームで同じデータをＮシンクに送信するならば、これがＮユニキャストである。Ｎノードがユニキャストによって互いに接続されるネットワークにおいて、Ｃ２Ｎユニキャスト接続が必要とされ、ここで、Ｃ２Ｎ＝Ｎ！／２（Ｎ−２）！である。この数は、増加するＮとともにはなはだ増加する。１００台のＰＣは、すでに４９５０の接続を必要とするだろう。もしユニキャストが接続を実現させるために使用されるならば、システムはすぐに帯域幅制約に陥るだろう。ブロードキャストの場合には、ソースは一度だけフレームを送信する。フレームは、次いで全ての接続されたシンクによって受信される。マネージャからマネージャに渡される接続要求は、シンクとしてブロードキャストアドレスを含むことができる。
グループキャストは、一群の装置に対するブロードキャストである。これがＴＣＰ／ＩＰのマルチキャストにおいてなされるように、もしグループが動的に構築されることができるならば、それは大きい利点となることができる。もし我々が単一の発明のネットワークを推測するならば、我々が獲得するこの利点の良い具体例は、２つの別々のイーサネット（登録商標）をトンネルすることである。この場合、各々のイーサネット（登録商標）は、送信側／受信側の自身のグループを構築することができる。全てのイーサネット（登録商標）装置を与えるために、同じグループアドレスは、十分でないだろう。２つの異なるグループアドレスが、２つのグループのイーサネット（登録商標）装置を構築するのに必要とされる。
【００４７】
別の実施例は、グループアドレスを得るための手続きを備える。ソースとシンクに対するグループアドレスの割当てが、アプリケーションのマネージャによって実行される。したがって、マネージャはどのように自由な未使用のグループアドレスを見いだすことができるかの方策が必要とされる。管理のための中心的インスタンスが存在していないので、マネージャはそれ自身グループアドレスについて交渉しなければならない。したがって、自由なグループアドレスを必要とするマネージャは優先度連鎖内の最下位マネージャにグループアドレス要求を送信する。要求は、要求マネージャによって自由であると推定されるグループアドレスを含む。すでにそのグループアドレスを使用するマネージャに達するまで、この要求は優先度連鎖を上方向へ通される。このマネージャは、要求マネージャにその要求が拒否されることを知らせる。もしどのマネージャもグループアドレス要求を拒否しないならば、優先度連鎖において最上位マネージャが要求を確認する。次に、グループアドレスは要求マネージャによって、ソースとシンクに割り当てられることができる（図２３）。
【００４８】
６．ソースアクセスとシンクアクセスを交渉する権利を解放する。
【００４９】
本発明のネットワークの別の実施例は、接続を解放するための手段を備える。もし既存の接続が解放されるならば、これは、形成されなければならない判断の行を生じさせてもよい。もしユーザーが、例えば、電話呼出しが入る前に音楽を聞いていたならば、一旦電話が終わったならば、音楽は再び聴取可能になるべきである。ソースをシンクから切り離すことに向けての要求は、以下の通りである：
−  もしシンクからソースへの最後の接続が解放されるならば、ソースはストリーミングを止めるべきである。さもなければ、たとえどのユーザーもそれらのストリームを消費しないとしても、リソースはソースによって占められる。
−  もしソースとシンクとの間の複数の接続の１つが解放されるならば、他の接続はとどまるべきである。
−  一度接続がマネージャから解放されると、他のマネージャは交渉することが可能であることを知らせられるべきで、そのマネージャが次にこれらのリソースに対するアクセスを獲得する。
【００５０】
他の実施例では、接続を解放するために、マネージャは最上位優先度マネージャに接続解放要求を送信する。そこから、それは装置マネージャから優先度連鎖の下のマネージャに渡される。もしマネージャがこの接続からシンクあるいはソースを占有するつもりであるならば、それは、接続解放要求にこれを指定する。一度指定されると、より下位の優先度マネージャは、それがリソースに対するアクセスを獲得しないことを知る。もしリストされた接続が別のアプリケーションによってなお使用されているならば、そのマネージャが同様にそれを指定する。最下位優先度を有するマネージャは、要求側へ接続解放要求を戻す。更なる使用のために指定されていない全てのリソースは、マネージャによって割当てを解除される。
【００５１】
更なる実施例において、アプリケーションを止めるための手段が、設けられる。全てのオーディオシンクが音楽を再生するのを止めることを、ユーザーが望むシナリオがあるだろう。ソースを増幅器に接続した、異なる部屋にわたって広げられるいくつかのオーディオ選択マネージャがあってもよい。ユーザー、マネージャあるいはその他のプロセスあるいは装置が、アプリケーションを切ることができるようにするために、システムが起動されたあと、それを通じて、アプリケーションが有した状態へ戻るように告げられることができるインタフェースを露出させる、少なくとも１つのマネージャが設けられる。これによって、それ自体がアプリケーションのグループを制御するアプリケーションが構築されることができる。このインタフェースの上にまた、どの種類のアプリケーションが始動状態へ戻るべきかを記述する、引数も渡されるべきである。アプリケーション種類に対する具体例は、以下の通りである：
−  マルチメディア（増幅器及びスピーカ、ＴＶ、ＤＶＤ、ＣＤ、ＳＴＰなど）
−  通信（電話、インターコム、ＬＡＮ、インターネットなど）
−  住宅技術（ヒータ、照明など）
−  警報システム
【００５２】
更なる実施例において、ガーベジコレクションのための手段が、設けられる。アプリケーションが未使用のリソースの割当てを解除しないことが起こるかもしれない。理由は、ソフトウェアバグ、あるいは、使用されたリソースを解放する機会を有することなく、装置が突然プラグを抜かれたこと、である可能性がある。より小さいシステムでは、一旦リソースが使用されて、次いで別のアプリケーションによって解放されるならば、リソースリークは解消されるので、ユーザーはおそらくそれを認識しないだろう。したがって、より小さいシステムではガーベジコレクションは全く実行される必要がない。
多くのリソースを有する大きいシステムでは、数多くのリソースリークは、帯域幅制約につながる可能性がある。したがって、ガーベジコレクタが全体のシステム安定性を向上するために設けられる。それは、ガーベジ収集アプリケーションを備える。このガーベジ収集アプリケーションのマネージャは、好ましくは可能な最下位優先度を有する。それは時々、最上位優先度マネージャに対して全ての接続されたリソースを含む、接続解放要求を送信する。もしリソースを使用するアプリケーションがなおあるならば、そのマネージャは、接続解放要求内に「なお使用中」として、それを指定する。もしリソースがこれ以上使用されないならば、ガーベジコレクションマネージャは安全にリソースを解放することができる。
【００５３】
別の実施例において、マネージャに対するデフォルト優先度レベルが、標準装置相互依存性を管理するために、規定されたアプリケーションに対して装置メーカによって割り当てられる。好ましくは、全てのメーカが、同じグループのアプリケーションに、それらのマネージャに対して同じ優先度を割り当てるだろう。それで、全てのＤＶＤプレーヤが、同じ優先度を有するだろう。例示的な優先度は、以下の通りであるだろう
火災警報システム                    ９９
ネゴシエーションアドミニストレータ  ９０
プロファイラ                        ７０
電話                                ６０
インターコム                        ５０
Ａ／Ｖ  選択                        ２０
【００５４】
もしこの種の優先度レベルが割り当てられるならば、小さなホームネットワークは通常いかなる手動構成も必要としないだろう。大規模ネットワークが、設置中に、および実行時に専門家によって構成されることができる一方、中型システムは、ＨＭＩによって構成されることができる。もし１つ以上のマネージャが同じ優先度レベルを有するならば、それらはそれらのノード位置によってソートされる。１つの装置でもし複数のマネージャが同じ優先度レベルで存在するならば、それらはそれらのインスタンスＩＤによってソートされる（図９）。
【００５５】
本発明の概念に従うネットワークは、非常に単純であることができる。それは、ＴＶ、ＤＶＤプレーヤあるいは照明スイッチおよび照明アクチュエータ（リレー、電子スイッチ）のようにほんの少しの装置だけから成ることができる。これは、非常に小さな初期費用でネットワークを設置することを可能にする。後で、このネットワークは、住宅内の全ての装置を接続する非常に複雑なネットワークにアップグレードされることができる。さらに、発明のネットワークは、事務所、プラント設備、病院、自動車、航空機、船およびその任意の組合せで使用されることができる。それは、住宅のネットワークと共に車からのネットワークのように異なるネットワークを共に接続することを可能にしさえする。
【００５６】
更なる実施例において、少なくとも１つのマンマシンインタフェース（ＨＭＩ）が、設けられる。装置内に配信されるアプリケーションによって、ＨＭＩはアクセスされる。
【００５７】
別の実施例において、ＨＭＩは少なくとも１つのディスプレイを備える。この種のディスプレイは、シンクとみなされることができる。スピーカと比較して、それはグラフィックデータを消費する。他のシンクとして、ディスプレイは特別なロジックを必要としない。それはただ、配信されたデータを渡すことを可能にするインタフェースあるいは機能ブロックを提供しなければならない。
【００５８】
現在公知の多数のマルチメディアアプリケーションによれば、アプリケーションに依存して、グラフィックデータは非常に異なるフォーマットで渡される：
・  ＭＰＥＧ１／２／４、ウィンドウズ（登録商標）ＷＭＶ、などのビデオストリーム。
・  ＢＭＰ、ＧＩＦ、ＪＰＥＧ、ＰＮＧ、などの画像。
・  ＨＴＭＬ、Ｊａｖａ（登録商標）、Ｍａｃｒｏｍｅｄｉａ  Ｆｌａｓｈ、などの類のスクリプトベースのデータ。
・  コマンドベースのデータ（例えば、円を描画する、色で円を塗り潰す、など）。
【００５９】
フォーマットのミックスさえ、予知されなければならない。デバイスモデルは、新しいグラフィックフォーマットに向けた不変量である。
【００６０】
これらのフォーマットに関して、異なるフォーマットが異なる配信経路を必要とすることは明白である。例えば、グラフィックデータは、ＨＴＭＬの様に、一度だけ配信されることができる。この種のグラフィックデータは、ネットワークの非同期チャンネルを通じて送信される。それと比較して、ビデオストリームは連続的に配信されなければならない。したがって、同期したあるいは、等時チャンネルが、最適配信経路である。
【００６１】
更なる実施例において、ＨＭＩは少なくとも１つの対話制御部を備える。対話制御部は、ユーザーがネットワーク上の装置と対話することを可能にする。それらは、ボタン、ホイール、ホイールノブ、リボンコントローラ、マウス、キーボード、タッチパネル、リモートコントロール、音声入力のうちの少なくとも１つを備えることができる。放熱器サーモスタット、オーディオシャトルのボタン、などの増分／減分ボタンの様に、これらの対話制御のいくつかは、特定の機能に連結されるであろう。ディスプレイのコンテンツに従って、グラフィックディスプレイのボタンの様な他のものは、それらの意味を変更する。
【００６２】
基本的に、対話制御部は、３つのグループに分けられることができる：
１．ＤＶＤプレーヤのイジェクトボタンの類の、ハードウェア関連。これらの対話制御部の意味は、不変である。たとえそれらがシステムの変更をもたらすことができるとしても、それは、通知によって１個またはそれ以上のディスプレイの変更につながる可能性があり、それらは、本発明のネットワーク経由でアドレス可能でない。したがって、それらは更なる考察に対して無視されることができる。
２．機能関連。例えば、増分／減分ボタンだけからなる小さい装置が、住宅の至る所に分散される可能性がある。放熱器のわきに温度を制御するために、照明のスイッチのわきに明るさを制御するために、など。ボタンの１つが押されるたびに、同じ機能が要求される。それは、一度構成されて、長い期間にわたって変化しない。音声コマンドは、別の良い具体例である。それは、一度構成されて、長い期間の間状態を保つ。もし住宅の所有者が変わるならば、それは変えられるだろうが、それ以後、それがかなりの間安定したままである。
３．コンテクスト関連。対話制御部の意味は、時間にわたってすばやく変化している。それは、例えば従ったディスプレイの現在のコンテクストに依存している。ボタンが全く動作を起こさない場合が、あるだろう。
これらの装置のモデルは、対話制御部の種類および数から独立していなければならない。ＨＭＩは、ディスプレイおよび対話制御部の様々な組合せを有することができる。具体例は、以下の通りである
−  対話制御部だけを有するＨＭＩ
−  ただディスプレイであるＨＭＩ
−  ディスプレイおよび１セットの対話制御部から成るＨＭＩ
【００６３】
ＨＭＩは、視認できるようになるために異なるアプリケーションによって使用される。その使用の間、ＨＭＩはアプリケーションを表示している。ＨＭＩは、下記のようにアプリケーションを表すことができる：
【００６４】
装置ベース−これは、それらのディスプレイおよび制御部をネットワーク内に見いだされる他のアプリケーションと共有しない装置で使用される。一例は、ネットワーク無線装置とすることができる。単純なディスプレイ上で、オーディオソースが選択されることができる。これは、例えばメディアサーバのコンテンツからのファイル。ＨＭＩは、装置のアプリケーションに完全に結び付けられる。他のどのアプリケーションも、ユーザーと対話するＨＭＩに接続することができない。ディスプレイを使用するアプリケーションは、それによって使用されることができる、利用可能リソースに対してネットワークをスキャンする。
【００６５】
別の例は、装置ネットワーク無線と正確に同じものを実行する、ＰＣ上で実行するアプリケーションである。この場合、ネットワークにおいて見いだされる他のアプリケーションとこれらのリソースを共有することなく、アプリケーションはＰＣのディスプレイおよび対話制御部を使用する。
【００６６】
装置ベースのＨＭＩはネットワークに見えないので、それらはシステムのプラグ＆プレイ動作に対して関連しない。したがって、それらは更なる考察に対して無視されることができる。この種の装置ベースのＨＭＩは、それらのＨＭＩに対する機能ブロックを含まない。
【００６７】
コマンドベース−コマンドベースの方策内で、表されることを望むアプリケーションはコマンドを使用する。これらのコマンドは、主にアプリケーションからＨＭＩまで送信されるが、また、反対にも送信される。コマンドは、
−  ディスプレイ機能（そのグラフィック、解像度、カラー階調、ファンクションキーの数、など）を問い合わせる、
−  グラフィック操作（テキストを描画する、円を描画する、直線を描画する、など）を実行するディスプレイを要求する、
−  対話結果（ユーザーがファンクションボタンを押した、ユーザーがある位置でクリックした、など）を獲得する、ために使用される。
ＧＤＩ、ＸＷｉｎｄｏｗｓあるいはＭＯＳＴの自動車機能ブロック「グラフィックディスプレイ」は、典型的なコマンドベースの表現である。
【００６８】
記述子ベース−この方策内で、アプリケーションは記述子をＨＭＩに配信する。この記述子はアプリケーションのメニューおよび、特定の範囲内で変更されることができる、状態変数に関する情報を含む。記述子は、ディスプレイにおけるグラフィック表現はどのように見えなければならないか、のような具体的な情報を与えない。それは必要なコンポーネントを告げるだけであり、ユーザーは意味がある方法でアプリケーションを制御する必要がある。
【００６９】
例えばオーディオソースを選択して、ボリュームを制御することを可能にするアプリケーションに対する記述子は、このように見えるはずである：
｛
ｖａｒ  ｅｎｕｍ  Ｓｏｕｒｃｅ
ｒａｎｇｅ  ｛  ｎｏｎｅ，  ＣＤ，  Ｔｕｎｅｒ，  ｉＰｏｄ  ｝
ｖａｌｕｅ  ｛  Ｔｕｎｅｒ  ｝
ｖａｒ  ｕｉｎｔ  Ｖｏｌｕｍｅ
ｒａｎｇｅ  ｛  ０，２５５  ｝
ｓｔｅｐｓ  ｛  １  ｝
ｖａｌｕｅ  ｛  ８０  ｝
｝
【００７０】
記述子の視認できる表現は、ＨＭＩによって完全に実行される。典型的なディスプレイは、図２９、３０および３１に示される。図３１のＨＭＩさえ、例証スクリプトを表すのに十分である。
【００７１】
ブラウザベース−ブラウザベースの方策は、コマンドベースの方策と記述子ベースの方策との混合の種類である。記述子を配信する代わりに、表されたアプリケーションがＨＴＭＬ、ＪＡＶＡ（登録商標）、などのコードを配信する。このコードは、グラフィック表現はどのように見えなければならないというコマンドを含む。このＨＭＩは、コードを解釈して、最適にそれを描画しようと試みる、ブラウザである。対話は、また、コードによって制御される。もしＨＴＭＬが、例えばＨＭＩで押されるボタンを含むならば、これはＨＭＩから表されたアプリケーションに、ＨＴＴＰ要求を生じさせる。この方策を使用する規格に対する具体例は、ＵＰｎＰおよびＭＨＰである。ＨＴＭＬ、ＪＡＶＡ（登録商標）およびＨＴＴＰの代わりに、他の機構が使用されることができる。
以下の表は、先の説明された方策を比較する。
【００７２】
【表１】
2008532375.tif 000003
【００７３】
別の実施例において、各々のネットワーク使用可能なＨＭＩは、少なくとも１つの機能ブロックを記述子ベースの表現に対して設ける。上記のように、異なる機能を提供する、多くの異なるＨＭＩ装置が、あるであろう。グラフィックＨＭＩに加えてまた、ディスプレイのないＨＭＩおよび英数字ＨＭＩがサポートされるべきという要件を保ち、かつ、コマンドベースの表現が単純な装置にとってあまりに複雑であることを考慮に入れて、記述子ベースの表現が、各々のＨＭＩでサポートされるべきである。これは全てのＨＭＩの間で一致の最小に至り、および、アプリケーションは各々のＨＭＩで表されるようになることができる。他の側面では、各々のマネージャはＨＭＩの対話イベントを受信するために、その機能ブロック内に対応する機能を必要とする（図３２）。
【００７４】
ＨＭＩが関係する使用ケースは、アクチュエータによって分類して、
ＨＭＩでのユーザー
−  アプリケーションを選択する
−  アプリケーションメニューをウォークスルーする
−  アプリケーションのパラメータ／特性を変更する
−  アプリケーションの方法を呼び出す
アプリケーション
−  イベント（例えば、電話／インターコム呼出しが着信）によって起こされる１つ以上のディスプレイでのポップアップ
−  １つ以上のディスプレイに描画する
【００７５】
上記にリストされた大部分の項目は、ＨＭＩに対するアクセスに関する。すでに述べられたように、ＨＭＩはソースが接続されることができるいくつかのシンクを有するだろう。ＤＶＤプレーヤは、この種のソースであることができる。これに加えて、もしユーザーにアプリケーションを制御するための対話の可能性を提供することを望むならば、ネットワーク内の各々のアプリケーションは、可能なソースである。したがって、また、アプリケーションはソースでもある必要がある（図３４）。
【００７６】
何かを表示するために、いくつかのアプリケーション間の競合があるであろう。ウィンドウをサポートしない単純なディスプレイの場合には、１つのアプリケーションがディスプレイに接続すると、別のアプリケーションは切り離されなければならない。この競合をオーガナイズするために、その他のシンクに対するものと同じ機構が使用される（図３５）。
【００７７】
もう１つの実施例では、システムが複雑なプロファイリングおよび権利管理をサポートすることを可能にするために、別のマネージャからＨＭＩに対する接続要求を受けとるマネージャは、接続要求あるいは記述子のどちらかを変更することができる。これらの変更は、特定の境界内にとどまらなければならない。一例として、それは削減されることができ、値の範囲は縮小されることができ、あるいは、変数は除去されることができる（図３６）。
【００７８】
別の実施例において、ＨＭＩは専用のアプリケーションを設ける。通常ＨＭＩ装置は、ユーザーに全ての利用可能なアプリケーションをリストするメニューを提供する、ディスプレイを有する。ユーザーは、それで対話のためにそれらの１つを選択することができる。我々の用語において、ＨＭＩはグラフィックデータおよび対話のための１個又はそれ以上のシンクから成る。定義上、それは自身のアプリケーションのマネージャを有する必要はない。したがって、我々はどのアプリケーションのマネージャもＨＭＩに接続することを望まない状況を推測することができる。この状態をカバーするために、ＨＭＩ装置はその自身のマネージャを持って来るべきである。もし他のマネージャがＨＭＩに接続されないならば、それは接続し、かつユーザーに例えば全ての利用可能なアプリケーションのマネージャにわたるメニューを提供する。もしユーザーが１つを選択するならば、ＨＭＩのマネージャは選択されたマネージャにＨＭＩに接続することを勧める（図３７、３８）。
【００７９】
更なる実施例において、ビデオ、グラフィクスなどを描画することが可能な少なくとも１つのＨＭＩが、機能ブロックの他に、表現記述子を受け入れる追加の機能ブロックを設ける。もしアプリケーションがビデオを描画することを望むならば、それは対応するデコーダ機能ブロックを有するＨＭＩに対してネットワークをスキャンする。それがソースをそのシンクに接続することを見いだした場合。同じ手続きが、他のフォーマットに対して実行される。この方策は、発明のネットワークを将来のフォーマットのために開放したままにしておく（図３９）。
【００８０】
ＨＭＩが対話コントローラを有する場合において、開催しているイベント、ユーザーの入力は、目下ＨＭＩに接続されているアプリケーションに通知されなければならない。ＨＭＩのシンクと接続されたアプリケーションとの間のこの通信がどのように詳細に見えるかは、シンクのフォーマットに、あるいは、換言すれば機能ブロックの種類に、非常に依存する。典型的なビデオシンクは、おそらく全く対話を有しない。コマンドベースのシンクは、「マウス移動」、「マウスクリック」、などのようにイベントを送信するであろう。これらの詳細は、それらの機能ブロックの目標仕様において、全て明らかにされる。記述子ベースの表現は、全てのＨＭＩおよび全てのアプリケーションによってサポートされるべきである。
【００８１】
下記の例証スクリプトにおいて、アプリケーションは２つの変数、「ソース」および「ボリューム」を提供する。ＨＭＩは、その境界においてそれらの変数が変更されることができるスクリプトから読みとることができる。
｛
ｖａｒ  ｅｎｕｍ  Ｓｏｕｒｃｅ
ｒａｎｇｅ  ｛  ｎｏｎｅ，  ＣＤ，  Ｔｕｎｅｒ，  ｉＰｏｄ  ｝
ｖａｌｕｅ  ｛  Ｔｕｎｅｒ  ｝
ｖａｒ  ｕｉｎｔ  Ｖｏｌｕｍｅ
ｒａｎｇｅ  ｛  ０，２５５  ｝
ｓｔｅｐｓ  ｛  １  ｝  ｖａｌｕｅ  ｛  ８０  ｝
｝
【００８２】
ユーザーとの対話処理がどのように行われるかは、ここで、ＨＭＩ装置によって完全になされる。ボタン、ホイール、音声検出、などがあることができる。一度ユーザーが変数を変更すると、ＨＭＩは接続されたアプリケーションを呼び出して、変数およびその新しい値を告げる。
【００８３】
更なる改良点は、各々のネットワークインターフェース制御装置チップ内にＭＡＣアドレスを有することである。
【００８４】
この文書において、用語「ネットワーク」および「バス」は、等価物として使用される。
【００８５】
用語「装置」は、ＴＶ、ＤＶＤプレーヤ、照明スイッチあるいは照明アクチュエータのようにネットワークに接続された任意の種類の電子装置を指す。オブジェクト指向のモデルにおいて、用語装置は、また、装置の機能ブロックあるいはそのソースあるいはシンクに対しても使用される。これは、いくつかの機能ブロックが単一の装置に含まれることができるからである。
【００８６】
用語「アプリケーション」は、装置に導入されるソフトウェアを意味する。アプリケーションは、その他の装置あるいはアプリケーションと通信するかつ／または制御することができる。
【００８７】
用語ＭＯＳＴは、ＭＯＳＴコーポレーションによる、０５／２００５付けの「ＭＯＳＴ仕様」改訂２．４内に規定されるように、ＭＯＳＴ（登録商標）−規格を指し、それは、ここにて含まれる。
【００８８】
「機能ブロック」は、装置内のアプリケーションレベル上の機能エンティティである。無線装置は、機能ブロックのチューナ、増幅器およびＣＤプレーヤを含むことができる。ネットワーク接続性あるいは診断の類の特殊目的のための更なる機能ブロックが、あることができる。各々の機能ブロックは、複数の単一機能を含む。例えば、ＣＤプレーヤは再生、停止、取り出しおよび再生時間の類の機能を有する。機能を外部からアクセス可能にするために、機能ブロックは、機能ブロック内の機能と別の機能ブロック内のその使用との間のインタフェースを表す、機能インタフェースを設ける。
【００８９】
用語「ソース」は、データ、好ましくは同期式データの供給源に関し、通常は機能ブロックによって表される。
【００９０】
用語「シンク」は、データ、好ましくは同期式データの受け手に関し、通常は機能ブロックによって表される。
【００９１】
用語「リソース」は、ネットワークの理論的な記述を指す。それは、ソース、シンクおよびネットワーク帯域幅を備える。
【００９２】
意図的に空白のままにされるページ
【発明を実施するための最良の形態】
【００９３】
図１は、本発明に従うネットワークの代表的アプリケーションを例示する。住宅４００はいくつかの部屋を備え、各々が少なくともスピーカ４１１およびマイクロフォン４１０を備えている。
ガレージ４０１において、車４１２との通信のためのＭＯＳＴ用の無線ブリッジ４１３の類の更なる手段が設けられている。したがって、この住宅のネットワークはＭＯＳＴのように好ましくは車のネットワークシステムと互換である。
ヒータ部屋４０２において、ヒータ４１５および空調４１４システムの装置コントローラが、ネットワークに接続されている。この住宅にわたって分布するディスプレイにおいて、現在の温度、エネルギー消費量、油タンクはまだどれくらい持つか、などのような情報が取り出されることができる。装置は、また、遠隔で制御されることもできる。それらは、スイッチを入り切りされることができ、温度は設定されることができ、などできる。
サーバ部屋４０３に設置されたＰＣがあり、この住宅のサーバ４１６として働く。それは、インターネット（ＷＷＷ）に対する、および、電話網（ＩＳＤＮ）に対する接続を有する。部屋のマイクロフォンおよびスピーカと組み合わせて電話呼出しは、この住宅の中で至る所でなされることができる。一般的な電話帳は、同様にサーバによって管理される。
当然、この住宅の全ての他のＰＣおよびラップトップはサーバ経由でインターネットのサーフィンをすることができる。サーバは、オーディオファイル収集品を保持して、このネットワーク内のオーディオプレーヤとして働く。それは、また、車のオーディオシステムにオーディオファイルの精選品を配信する。夜の間に、サーバはハードウェアタイマーによってスイッチを切られると想定される。本発明に従うネットワークが中央ＰＣを必要としないので、残りの装置は適切に動作し続ける。
正面玄関４２２に、ネットワークインターコムが、設置される。それは、カメラ４２１、マイクロフォン、スピーカ、および、押しボタンから成る。
キッチン４０５で働く間に、オーディオストリームがＭＯＳＴオーディオシャトル４２０を用いて聴かれることができる。もちろん、我々はまた、電話呼出しをする、他の部屋の人と話をする、などすることもできる。
居間４０４には、我々は一般的なＴＶ  ４１７を見いだす。それはＴＶボックスへのネットワークＨＭＩに接続され、リモートコントロールによって配信される。ＴＶへのネットワークＨＭＩは、一般のＴＶを完全ネットワークＨＭＩにする。快適なメニュー経由で全部のネットワークシステムを制御すると共に、全ての利用可能なビデオストリームが、見られることができる。オーディオを含むソースが選択されると、増幅器が、ＴＶのスピーカの代わりに使用される。
グラフィックネットワークＨＭＩは、ＴＶスクリーン経由で任意のグラフィックコンテンツを視覚化することができる。ビデオは、フルスクリーンであるいはウィンドウ内に表示されることができる。ラップトップ４１８は、ネットワークＷＬＡＮブリッジ４１９経由でネットワークに接続される。それは、また、ネットワークＨＭＩとして働くこともできる。それは、もちろんサーバ経由でインターネットに接続される。
寝室４０７は、ＴＶ４２４を備えている。それは、直接ネットワークリングに接続されることができて、全ての利用可能なビデオストリームを復号化することができる。それはまた、ネットワークＨＭＩとして働いて、例えば、朝に、ユーザーを起こすアラームを設定することを可能にさせるメニューを提供する。
浴室４０６は一般のインターコム装置のマイクロフォンおよびスピーカに加えて、壁に埋め込まれた防水フラットパネルディスプレイ４２３を有する。寝室のＴＶの様に、これはネットワークＨＭＩであり、全体の機能に対する最適の接続を与えるが、それは異なるメーカによって構築された。リモートコントロールの代わりに、このディスプレイは、タッチパネルによって制御される。
子供部屋４０８は古いＴＶ４２５およびＴＶへのネットワークＨＭＩを有し、特別な時間の間、いくつかの提供されたテレビ局へのアクセスを有する。他局は、見られることができない。ゲーム機（ＰＳ２）が、ＴＶへのネットワークＨＭＩに接続される。また、カメラ４２６が設けられる。
趣味部屋４０９には、キーボード（ピアノ）４２８、サンプラおよびいくつかのシンセサイザ（モーグ）がある。全てのそれらの装置は、ネットワークオーディオ／ＭＩＤＩブリッジ経由で接続される。この部屋のＰＣ４２７は、マルチトラックレコーダ、オーディオミキサおよびシーケンサとして働く。それは、ネットワークＰＣＩボード経由で接続される。レガシー音楽機器は、ネットワークインターフェースを提供するオーディオミキサ経由で接続される。他の音楽家は、自分自身の機器を持って来ることができて、それらをネットワークに接続することができる。したがって、装置の数は、動的に変化する。完全プラグアンドプレイ機能が、必要とされる。
【００９４】
図２は、本発明と共に使用されることができる典型的ないくつかのネットワークトポロジを例示するが、本発明はこれらのトポロジに限定されない。円滑な稼動システムを得るために、好ましくは、サブリングあるいはサブネットが、各々の部屋に設けられる。その時、接続／引抜によって引き起こされる歪は、これがなされる部屋の中だけで聞こえる。他の部屋は、影響を受けない。
リングトポロジ（左）において、ノード（斜線）からなるいくつかのサブリングＳＲが、リピータ経由で中央リングに接続される。スタートポロジ（中央）において、サブリングは、中央ハブに接続される。リングトポロジとスタートポロジは、ほぼ同じものである。スタートポロジにおいて、リングトポロジのリピータは、単一の装置、ハブに共に全て結ばれる。デージーチェーン（右）において、各々のノードＮは２つの入力／出力対を有する。終端するチェーンの最初と最後のノードは、それぞれリングを閉じる。全てのトポロジは、局所ニーズに従って統合されることができる。ネットワーク性能およびサイズを増強するために、サブリングあるいはサブネットが、スイッチによって相互接続されることができる。
【００９５】
図３は、方向付けられたオブジェクトモデルの中でネットワークをスキャンするマネージャ（管理ロジック）１５０を示す。それは、Ｎソースの各々のソース１０１、１０２、１０３およびＭシンクの各々のシンク１１０、１１１、１１２と接触して、複数の情報を取り出す。この情報のベースで、マネージャは、どのソースとシンクが更なる作業に関連するかを決定する。アプリケーションは、例えば、起動時間に一度、ネットワークのノードの数が変化するたびに、あるいは通常間隔あるいはランダム間隔で、スキャンをすることができる。いずれにせよ、マネージャは許される限りいつでも、ソースあるいはシンクからの情報を問い合わせる。
【００９６】
図４は、ネットワークのソース＿２  １０２、シンク＿１  １１０およびシンク＿２  １１１に制御メッセージを送信するマネージャ１５０を示し、それは、これらのソースとシンクの状態変更に至る。
【００９７】
図５は、シンク＿１  １１０およびシンク＿２  １１１に接続されたソース＿２  １０２を示す。少なくとも１つのシンクが少なくとも１つのソースに接続される場合、データが送信されることができる。これは、オーディオあるいはビデオストリームの様に、同期式データだけでなく、その他の種類のデータとすることもできる。非同期式データ伝送に対する良い例は、２つのＰＣ間のイーサネット（登録商標）接続であることができる。特にＭＯＳＴ接続は、他の接続、例えばＴＣＰ接続と、全く異なる。例えば、ＭＯＳＴ上で、送信は、コネクションレスであり、それは、ネットワーク層上で、もしシンクが見えなくなるならば、ソースが認識しない、そして、その逆も同じ、ことを意味する。したがって、各々のマネージャは、自身の接続に対して責任を負う。マネージャは、ストリームを消費するシンクを有することなくソースストリーミングを始めてはならない。また、もし接続されたシンクがまだあるならば、マネージャはソースストリーミングを止めてはならない。もしソースもシンクもない場合は、何のデータもネットワークを通じて送信されない。
【００９８】
図６は、オーディオシャトルの例を示す。オーディオシャトルのボタン経由で、ユーザーは、２つのアプリケーションを制御する：１．音楽を聞くためにソースを選択する、２．インターコムを使用する。両方のアプリケーションの各々に対して、マネージャが設けられる。マネージャのオーディオソース選択１６０およびインターコム１６２が、利用可能なソースのマイクロ＿イン（マイクロフォン）１２０およびＡｕｘ＿イン（補助入力）１２２とシンクのスピーカ１３０およびＡｕｘ＿アウト  １３２とを制御する。ユーザーの選択に従って、ソースとシンクが、接続される。図において、マネージャはそれらの名前の前に接頭辞『Ｍ』を有する。
【００９９】
図７は、スピーカ１３０、マイクロフォン１２０、Ａｕｘｉｎ１２２（補助ソース入力）、カメラ１２４、ＨＭＩ１３９（マンマシンインタフェース）、チューナ１２５のようなソースとシンクを有する異なる装置１００を備えるより複雑なネットワークを図式的に示す。中間に、一群のマネージャ１５０が、これらのソースとシンクを制御している。これらのマネージャは、オーディオソース選択１６０、インターコム１６２、電話１６５、ホームオートメーション１６６およびＡＶソース選択１６４に対するマネージャを備える。さらに、プロファイラ１７１およびネゴシエーションアドミニストレータ１７０が、設けられる。
【０１００】
図８は、割り当てられた優先度を有する以前のもののような、類似したモデルを示す。ストリームの切り替えを制御する第１の工程は、優先度の導入である。もしストリームがシンクで消費され、かつ別のストリームがより上位の優先度とともに到着するならば、ストリームは切替えられ、あるいは混合される。もし優先度がより下位ならば、到着するストリームは無視される。もし例えば、浴室の人がこれ以上じゃまをされるのを好まないならば、彼はアプリケーションの音楽に対して最上位優先度を選択することができる。
優先度は、また、もし例えば電話呼出しを伝送するなどのために充分な帯域幅がない場合に、リソースの欠如から生じる競合を処理することができる。
もし住宅内の各々のマネージャが他のマネージャに知らせることなくシンクとソースを接続するならば、それは混乱状態になるだろう。一方では、高水準の自動化が、必要とされる。それで、もし新しいＣＤがＣＤプレーヤの中に挿入されるならば、音楽が自動的に再生し始めることができる。他方では、この自動化は、競合に至る可能性がある。それで、もしＣＤが変更されたならば、電話呼出しが消えるかもしれない。これを防ぐために、ソースとシンクに対する構造化されたアクセスが、必要とされる。これは、優先度を割り当てることによってなされる。インターコム１６２および電話１６５に対するマネージャは、全てのマネージャの中で最上位優先度を有する。オーディオソース選択マネージャ１６０は、下にある。ＨＭＩマネージャ１６７は、これの下にある。スピーカ１３０、マイクロフォン１２０、Ａｕｘｉｎ１２２、カメラ１２４、ＨＭＩ１３９およびグラフィックディスプレイ１３９のような全ての装置は、それ自体、これらのマネージャの更に下で一般の優先度レベルにある。これらのマネージャの上に、ネゴシエーションアドミニストレータ１７０が、およびこれの下にプロファイラ１７１がある。
【０１０１】
図９は、２台のおそらく競合するオーディオシャトルを有する構成を示す。マネージャのインターコム＿１  １６２およびマネージャのインターコム＿２  １６３がマネージャのオーディオ＿ソース＿選択＿１  １６０およびオーディオ＿ソース＿選択＿２  １６１の上に同じレベルにある。このモデルの唯一の不明確さは、同じ優先度レベルを有するマネージャの存在が許されることから来る。これは、追加のルールによって修正されることができ、もし１つ以上のマネージャが同じ優先度レベルを有するならば、それらはそれらのノード位置によってソートされる。もし１つのノードで複数のマネージャが同じ優先度レベルで存在するならば、それらはそれらのインスタンスＩＤによってソートされる。
【０１０２】
図１０は、２台のオーディオシャトルを有する構成および以前の構成に由来する固有の優先度を示す。調整は、マネージャの優先度レベル１８０を、インターコム＿１  １６２をインターコム＿２  １６３より上に、および、オーディオ＿選択＿１  １６０（オーディオ選択は、オーディオソース選択に等しい）をオーディオ＿選択＿２  １６１より上に設定し、インターコムの基本序列をオーディオ選択より上に保つことによってなされる。ここで、以前のピラミッド構造が、優先度の線形連鎖に変換された。
【０１０３】
図１１は、ソースアクセスとシンクアクセスについて交渉するための権利を獲得するプロセスを示す。マネージャは、優先度の増加と共に左から右に配置されることを示す。最初の工程では、マネージャ＿２  １５１は、マネージャ＿４  １５４、最上位優先度を有するマネージャ、に含まれるネゴシエーションアドミニストレータから交渉する権利を要求する（１８１）。これは、次いでネゴシエーションアドミニストレータ、マネージャ＿４  １５４によって確認される（１８２）。
【０１０４】
図１２は、住宅内の２台のオーディオシャトルを有する以前の例の接続要求手続きを示す。もしアプリケーションのマネージャのオーディオ＿選択＿１  １６０がＡｕｘ＿イン＿２  １２３とスピーカ＿１  １３０との間の接続を確立することを望むならば、要求１８１が、マネージャのインターコム＿２  １６３になされ、そこから、要求１８１がマネージャのインターコム＿１  １６２になされ、そして、そこから、確認がマネージャのオーディオ＿選択＿１  １６０へ返信される。もしオープンのインターコム接続があるならば、マネージャのインターコム＿１あるいはインターコム＿２は入って来る接続要求を拒否することができる。したがって、インターコム接続は、常にオーディオソース選択マネージャから邪魔されない状態を保つ。上の例において、どのインターコム接続もオープンでなく、そして、要求は要求マネージャへ明確に戻される。次に、マネージャは、Ａｕｘ＿イン＿２ソース１２３に、帯域幅を割り当てて、ストリーミングを始めさせることができる。一旦それがなされるならば、スピーカはストリームを消費するよう要求される。
【０１０５】
図１３は、プロファイラによって変更される要求を示す。マネージャからマネージャまで接続要求を渡すことによって、より高いレベルのマネージャが、要求を変更する可能性を有する。ここで、マネージャのオーディオソース選択１６０はプロファイラ１７１に接続要求１８１を送信する。ここで、スピーカ左へのＣＤの接続１８３、スピーカ右へのＣＤの接続１８４、サブウーファへのＣＤの接続１８５が要求される。もしプロファイラが晩の時間の間にサブウーファの使用を禁じることを望むならば、それは単に入って来る接続要求からサブウーファを除去する。他のスピーカの接続が処理される部分は、そのままの状態を保つ。それは、したがって、スピーカ左へのＣＤの接続１８６、スピーカ右へのＣＤの接続１８７、を許可する確認メッセージ１８２を戻す。この特徴はまた、シンクにそれを渡す前に、追加のアプリケーションの上にソースを送るために、使用されることができる。オーディオイコライザが、例えば連結されることができる。
【０１０６】
図１４は、音声認識のためのソフトウェアパッケージを実行するＰＣが接続されたシステムのモデルを示す。音声認識は、部屋内のマイクロフォンを使用する。何のシンクもシステム内にないので、音声認識マネージャ１６８はマイクロフォン１２０を何にも接続することができない。この問題は、システム、シンクの典型的な機能ブロックに、機能ブロックの増幅器をエクスポートすることによって音声認識ソフトウェア１７９によって解決される。この仮想増幅器１３７は、次に図１５に示すようにマイクロフォンに接続されることができる。もし音声認識マネージャとは別のアプリケーションのマネージャが装置を何かに接続しようと試みるならば、それはこの要求を拒否することができる。それで、この仮想デバイスは、他のアプリケーションと干渉することができない。同じ方法によって、仮想ソースが生成されることができる。
【０１０７】
図１６は、単一のシンクにだけ接続されることができるソース１０１を有するシナリオを示す。このソース１０１は、未知のマネージャによって過去に動作中のシンク＿１  １１０に接続されていた。次に、もし、図１７に示すように、別のマネージャ１５０がこのソースを別のシンク（ここでシンク＿２  １１１）に接続するならば、まだ動作状態にある一次シンク＿１  １１０は、ソース１０１からこれ以上の（有効な）データを獲得しない。それがそのアプリケーションの一部ではないので、マネージャ１５０はシンク＿１について知らない。したがって、シンク＿２への接続が実現する前に、シンク＿１はソースからデータを消費するのを止めることを知らせられない。もしシンク＿１が増幅器であるならば、ランダムノイズが聞こえる可能性がある。この種の影響は、もしソースあるいはシンクがすでに使用中で、かつこのソースあるいはシンクが複式接続をサポートしない場合にのみ生じる可能性があるだけである。この場合、それが接続を確立する前に、マネージャは全ての他のマネージャに知らせなければならない。次いで、この重要な接続を所有するマネージャにはそれを切り離すための機会がある。後で、マネージャが知らせられる場合、リソースが再び解放され、それは、接続要求を送信することによって、再び接続しようと試みるだろう。
【０１０８】
図１８−２１は、同期式トランスポートのために使用されることができるソース（複数のソース）とシンク（複数のシンク）との間の異なる種類の接続を示す。図１８に、同期式チャンネル、およびストリームを消費するシンク＿１  １１１に接続されたそのチャンネル上のストリーム、を割り当てたソース＿１  １０１との接続、が示される。複数の同期接続が、図１９に示すように同じソースを有することができる。この場合、シンク＿１  １１０からｍ番目のシンク＿Ｍ  １１２までの全てのシンクが、ソースから供給される同じストリームを消費する。もし住宅内の複数のＴＶが同じビデオチャンネルを表示するならば、これがその場合であることができる。最後に、ここでシンク＿１  １１０として示される、１つのシンクが、２つの入って来るオーディオストリームを聴取可能な１つに混合する増幅器の様に、ソース＿１  １０１からｎ番目のソース＿Ｎ  １０３までいくつかのデータストリームを消費するだろう。類似した種類の接続が、非同期トランスポートのために使用されることができる。加えて、Ｎ対Ｍ接続が図２１に示すように使用されることができる。ここで、ｎソースのいくつかが、Ｍシンクのいくつかに接続される。ソースとシンクの１対１の関係を必要とするピアツーピアプロトコルを使用するアプリケーションの様に、例外がある場合がある。
【０１０９】
図２２において、チューナ１２５とスピーカ１３０の間の並列接続が示される。例示的な寝室内に、アプリケーションの目覚まし時計およびアプリケーションのオーディオセレクタがある。朝、目覚まし時計マネージャ１６９が、設定されたアラーム時刻にスピーカ１３０とチューナソース１２５を接続する。典型的な場合は、ユーザーがアラーム起動の前に目がさめて、オーディオセレクタを使用してラジオを選択する、場合である。数分後に、アラームが起動しようと試みる。それは、より上位の優先度マネージャまで接続要求を送信する。もしいずれもが強く要求しないならば、接続は許可される。チューナは、同期式チャンネルを割り当てて、ストリーミングを始めることを要求される。スピーカは、ストリームを消費することを要求される。論理的観点から、目下、２つの並列接続（直線）が、チューナとスピーカの間にある。点線は、接続を設定してあるいは解除するためのマネージャとソースおよびシンクとの間の通信を象徴する。いずれにせよ、目覚まし時計がチューナにストリーミングを始めることを要求する時は、それはすでにそうしている、ということを戻すべきである。同じことが、スピーカにあてはまる。目覚まし時計の場合には、ユーザーを起こすその任務がそれによってなされることを、マネージャが決めることができる。他の場合には、接続がちょうど切替えられた場合のように、それはこの論理的接続に対処するマネージャにとって有用だろう。これはアプリケーション自体に最終的に依存するので、並列接続がサポートされるべきである。並列接続が１対ＮおよびＮ対１接続と組み合わせられる場合、非常に複雑な接続シナリオが生じる可能性がある。
【０１１０】
図２３は、グループキャストのためのグループアドレスがどのように得られるかについて示す。マネージャ＿３は、優先度連鎖の最下位優先度マネージャ、マネージャ＿１から始まる自由なグループアドレスを要求する（１９０）。マネージャのいずれもが要求を拒否しないので、それが、優先度連鎖の最上位マネージャであるマネージャ＿４によって、マネージャ＿３に確認される（１８９）。偽アドレス指定を防ぐために、装置は始動の後でいかなるグループアドレスも割り当てるべきでなかった。もしマネージャが接続を閉じるならば、関連する装置は対応するグループから除去されるべきである。もし装置が複数のグループのメンバであることができるならば、上記のアルゴリズムもまた、機能する。図２３ないし２７において、マネージャの優先度は、左から右に増加している。
【０１１１】
図２４は、リソースがどのように解放されることができるかについて示す。この例では、マネージャ＿３はマネージャ＿１にリソースを解放することを要求する（１９１）。マネージャ＿１がこれらのリソースを割り当てるので、それはそれらを解放して、マネージャ＿１へ利用可能性を確認し（１８９）、次に計画された接続を確立することができる。もしネットワークリソースを解放するよう要求されたマネージャがそれらのリソースを割り当てないならば、それは、単に優先度連鎖を更に上方向へ要求を渡す（図２５）。この例では、マネージャ＿１はマネージャ＿２に解放要求を転送する（１９２）。マネージャ＿２は解放し、そして、マネージャ＿３に確認する（１８９）。
【０１１２】
図２６は、拡散リソースを解放するための第１の方策を示す。マネージャ＿３  １５３は、ネットワークリソースを解放することを要求する。マネージャ＿１  １５１は、要求されたリソースの２０％を割り当てて、それを解放する。残りの要求は、マネージャ＿２に転送される（１９２）。マネージャ＿２がこのリソースの何も割り当てないので、それは要求を上方向へ転送する（１９２）。要求されたネットワークリソースがまだ充分でないので、マネージャ＿３は、そのアプリケーションを始めることができない。したがって、マネージャ＿１は不必要に割り当てられたリソースを解放した。
【０１１３】
図２７は、拡散リソースを解放するための改良された方策を示す。マネージャ＿３は、マネージャ＿１からネットワークリソースを要求する。マネージャ＿１は、このリソースの２０％だけを保持し、かつその接続を解除することによって、それを解放する。残りの８０％は、変更された解放要求を転送する（１９２）ことによって、それがマネージャ＿２から要求する。マネージャ（２）は、要求されたリソースの１００％を有するだろう。残りの８０％を獲得するために、それは全てのその接続を解除しなければならない。次いで、それはマネージャ＿３に確認する。ベストケースにおいて、もしマネージャ＿２がマネージャ＿３にそのリソースを与えていたならば、それが十分であったであろうという理由から、マネージャ＿１は、邪魔されないままだっただろう。
【０１１４】
図２８は、異なる経路を経てグラフィックデータを受信するディスプレイを示す。ネットワークから受信される例示的なデータフレーム１９３は、ディスプレイのための２つの種類の情報を含む：
−  円１８８を描画するグラフィックコマンド１９６。グラフィックコマンドは、パケット１９４で一度だけ送信される。したがって、グラフィックコマンドは、通常ネットワーク上のほんの少しのバイトだけを消費する。
−  ビデオデータは、ＭＰＥＧ２のような圧縮されたストリーム１９７で送信される。同期式チャンネルが、送信のために使用される。各々のデータフレーム１９５について、ストリームの一部が、受信される。ストリームは、ディスプレイのビデオデコーダによって復号化されて、従ったビデオポートに描画される。埋め込みソリューションの場合には、デコーダはチップとすることができる。もしＰＣがディスプレイとして使用されるならば、ソフトウェアデコーダが使用されることができる。
【０１１５】
図２９は、ディスプレイ内のデータの英数字表現を示す。英数字ＨＭＩは、記述子から、テキストおよび数字の形の単純なメニューおよび値を示す、文字数字表現を形成することができる。対話処理はいくつかのボタンを使用してなされることができ、ＨＭＩのディスプレイの下に位置する。この例において、ユーザーはソースから何も選択することができず、それは、何のソース、ＣＤプレーヤ、チューナおよびｉＰｏｄも、接続されないことを意味する。加えて、ボリュームは２桁の数字の形で設定されることができる。
【０１１６】
図３０は、ディスプレイ内のデータのグラフィック表現を示す。グラフィックディスプレイは、より複雑な表現を形成することができ、ここではボリュームあるいは他のパラメータがスライダ制御部によって変更されることができる。この場合、対話処理はマウスあるいはタッチパネルによってなされることができる。
【０１１７】
図３１は、ディスプレイのない単純なＨＭＩを示す。このＨＭＩは、各々上向き矢印および下向き矢印を有する２つのボタンと、１つが『＋』記号およびもう一方が『−』記号を有する、２つの他のボタンと、だけを有する。いくつかのボタンだけを備える、ディスプレイのないＨＭＩさえ、オーディオソースを選択し、およびボリュームを設定するのになお十分である。
【０１１８】
図３２は、異なって装備されたＨＭＩの例を示す。各々のＨＭＩが、少なくとも記述子２００を有する。リモートコントロール、英数字ＨＭＩあるいは検出装置の類のいくつかの非常に単純なＨＭＩ２２０は、この種の記述子だけを必要とする。テレビジョン受信機（ＴＶ）あるいはセットトップボックス（ＳＴＢ）の類の他のＨＭＩ２２１は、追加のビデオシンク２０１を有するだろう。携帯電話あるいはＰＤＡは、それらの記述子に加えて追加のスクリプトシンク２０２および画像シンク２０３を有するだろう。ＰＣ、ハイエンドＳＴＢあるいはゲーム機２２３は、追加のビデオシンク／ソース２０１およびコマンドシンク／ソース２０４を有することができる。
【０１１９】
図３３は、マネージャと記述子ベースのＨＭＩとの間のデータの流れを示す。マネージャ１５０は、記述子ベースのＨＭＩ２０５に接続することができる（２０６）。この接続は、ＨＭＩによって確認される（２０７）。次いで、マネージャは記述子２０８をＨＭＩに配信する。ＨＭＩが記述子を表すことを始め、かつ、ＨＭＩあるいはユーザーが対話する場合、従ったイベント２０９がマネージャに送信される。
【０１２０】
図３４は、ＨＭＩ１３９にアクセスするマネージャ１５０を示す。もし、ユーザーに、マネージャのアプリケーションを制御するための対話処理の可能性を提供することを望むならば、デバイスマネージャもまた、可能なソースである。
【０１２１】
図３５は、ＨＭＩに対する競合の２つのマネージャを示す。マネージャ＿１  １５１は、マネージャ＿２  １５２より下位の優先度レベルを有する。マネージャ＿１が、ＨＭＩ１３９に接続することを要求する場合、それは、マネージャ＿２に接続要求１９２をしなければならない（図３５ａ）。一度要求が確認される（２０６）と、マネージャ＿１は接続する（図３５ｂ）。この接続手続きは、もし、目下何のより重要なアプリケーションもこのＨＭＩを必要としないならば、下位の優先度レベルを有するアプリケーションだけがディスプレイに対するアクセスを獲得する、ことを確実にする。
【０１２２】
もしマネージャが機能関連ＨＭＩを有するならば、それはシステム起動中にそれらに接続する。どのＨＭＩが関連するかは、マネージャの構成の一部である。この構成は、据付け調整時になされなければならない。
【０１２３】
図３６は、ＨＭＩへの接続を要求する間の、記述子の変化を示す。住宅の所有者が、子供に、増幅器の最大出力の８０％より大きい音量で音楽を聞くことを望まない場合を想定する。したがって、彼は自分のサーバ上で実行する自分のプロファイラアプリケーションを構成する。子供の部屋のＡＶセレクタ１６４がＨＭＩを接続するときはいつでも、プロファイラ１７１が、ＡＶセレクタの記述子を
｛
ｖａｒ  ｅｎｕｍ  Ｓｏｕｒｃｅ
ｒａｎｇｅ  ｛  ｎｏｎｅ，  ＣＤ，  Ｔｕｎｅｒ，  ｉＰｏｄ  ｝
ｖａｌｕｅ  ｛  Ｔｕｎｅｒ  ｝
ｖａｒ  ｕｉｎｔ  Ｖｏｌｕｍｅ
ｒａｎｇｅ  ｛  ０，２５５  ｝
ｓｔｅｐｓ  ｛  １  ｝
ｖａｌｕｅ  ｛  ８０  ｝
｝
から、
｛
ｖａｒ  ｅｎｕｍ  Ｓｏｕｒｃｅ
ｒａｎｇｅ  ｛  ｎｏｎｅ，  ＣＤ，  Ｔｕｎｅｒ，  ｉＰｏｄ  ｝
ｖａｌｕｅ  ｛  Ｔｕｎｅｒ  ｝
ｖａｒ  ｕｉｎｔ  Ｖｏｌｕｍｅ
ｒａｎｇｅ  ｛  ０，２０４  ｝
ｓｔｅｐｓ  ｛  １  ｝
ｖａｌｕｅ  ｛  ８０  ｝
｝
に変更する。
その時、子供のＨＭＩで選択されることができる最大量は本当に可能な最大値の８０％である。
【０１２４】
図３７は、対話処理のためにインターコム１６２を選択するＨＭＩ１３９のアプリケーション１６７を示す。これは、２つの状態の最初のものである。まず、ＨＭＩ１６７がＨＭＩのシンクあるいはソース１４１に接続される（２１３）。それはメニューを提供し、そこから、ユーザーがインターコムを選択した。それで、ＨＭＩのマネージャは、ＨＭＩに接続するインターコムのマネージャに知らせる。
【０１２５】
図３８は第２の状態を示し、ここでインターコムのマネージャはＨＭＩのシンクあるいはソース１４１に接続される（２１３）。
【０１２６】
図３９は、ＳＴＢ１２６内に複数シンクを有するＨＭＩを示す。記述子＿ベース＿ＨＭＩ  ２０５は、表現記述子を受け入れ（２１３）、もう一方、ビデオ＿シンク１４０は、ビデオストリーム型データ２１６を受け入れる。この例において、ＡＶソース１２７を選択するためのアプリケーションのＡＶ＿選択１６４が、目下表示シンクに接続される。ストリーミングを始めるために、それは、ビデオソースとビデオシンクを接続する（２１４、２１５）。
【０１２７】
図４０は、増幅器２５５および受動スピーカ２５０を有するネットワークを示す。このネットワークは、本発明の概念を実証するシナリオの一部である。それは、ハイエンドオーディオシステムが設置された家庭を備える。他のいかなるネットワーク装置もまだ設置されていないが、もちろん、システムは将来に拡張可能であるべきである。３室の異なって装備された部屋、単一のスピーカ（モノラル）だけを有する１部屋２５２、２つのスピーカ（ステレオ）を有する１部屋２５３および５つのスピーカ（サラウンド）を有する１部屋２５４がある。我々は、エンコーディング、チャンネルの数、サンプル幅、サンプルレート、などに関して異なるオーディオストリームを供給するであろう多数のオーディオソース２５１を想定する。
当然、多数の可能な設定が、この種のシステムを実現させるためにある。最も重要なものが、示されている。
第１の設定において、増幅器２５５が各々の部屋にある。増幅器に、受動スピーカが、銅線（直線）経由で接続される。スピーカの位置決めは、それらを増幅器に接続する間に、最後になされる。増幅器２５５を制御するＨＭＩ２５６が、装置の一部である。我々の対話処理モデルにおいてしたがって、ＨＭＩは装置ベースである。次に、各々の増幅器は、動作中のオーディオストリームに対するネットワーク（破線部分）をスキャンし、それは復号化されることができる。この問合せの結果は、専用のＨＭＩを通してユーザーに提供される。一旦ユーザーがそれらのストリームの１つを選択するならば、増幅器はそれを再生する。
【０１２８】
図４１は、前の図から増幅器および受動スピーカを有するネットワークのモデルを示す。３台の増幅器、増幅器＿１  ２７１ないし増幅器＿３  ２７３がある。各々の増幅器のＨＭＩは、それが装置ベースであるので、ネットワークに見えないままである。増幅器につき２つの機能ブロックだけが、エクスポートされる。機能ブロックのオーディオ選択（オーディオ選択＿１、オーディオ選択＿２、オーディオ選択＿３）は、アプリケーションのマネージャである。それは、局所シンクに接続されることができる全ての適切なソースに対するネットワークをスキャンする。シンクは、機能ブロックの増幅器（増幅器＿１  ２７１、増幅器＿２  ２７２、増幅器＿３  ２７３）によって、ネットワークにエクスポートされる。より上位の優先度レベルを有する、他のいかなるマネージャもシステム内にない限り、オーディオ選択マネージャは更なる考察を伴わずにいかなる利用可能なソースを接続することもできる。
【０１２９】
図４２は、増幅器２５５、受動スピーカ２５０およびＨＭＩ１３９を有するネットワークを示す。これは前の設定であるが、各々の部屋に対して１つの中央インターコム装置２５７および１つのマイクロフォンプラスＨＭＩによって強化されている。我々は、ＨＭＩがただボタンであると想定する。押された場合、他の全ての部屋がページングされる。
【０１３０】
図４３は、前の図から増幅器、受動スピーカおよびＨＭＩを有するネットワークのモデルを示す。各々の部屋のマイクロフォンに対して、機能ブロックのマイクロフォン（マイクロ＿１  ２６８、マイクロ＿２  ２６９、マイクロ＿３  ２７０）、および、機能ブロックのＨＭＩ（ＨＭＩ＿１  ２６０、ＨＭＩ＿２  ２６１、ＨＭＩ＿３  ２６２）がある。インターコムの設置中に構成が設定される。３つの部屋が区画され、そして、従った装置が集められる。各々のインターコムグループは、増幅器、マイクロフォンおよび機能関連のＨＭＩから成る。システムが起動するときはいつでも、インターコムは自動的にそれ自体を各々のＨＭＩに接続する。
【０１３１】
ユーザーが、その時１つ以上の部屋の中で音楽を聞いており、そして、誰かが１つの別の部屋のインターコムボタンを押し、ＨＭＩが従った通知メッセージを送信する、場合を想定する。インターコムのマネージャは、次いでページングを行われた部屋の増幅器を送信者のマイクロフォンに接続しようと試みる。より上位の優先度レベルを有するマネージャは存在しないため、これは直ちになされることができる。ページングを行われた部屋の１つの中のユーザーが、インターコムが空いている間に、増幅器のハードウェア関連のＨＭＩを使用する場合、増幅器のオーディオ選択マネージャは、増幅器をより上位の優先度レベルのインターコムマネージャの選ばれたソースに接続することを要求する。インターコムマネージャは、空いたインターコム接続があることを知っており、それは要求を拒否する。したがって、インターコムは邪魔されない状態を保ち、そして、それがまさに我々が望んだことである。
【０１３２】
図４４は、前の設定に基づくが、異なるハードウェアコンポーネントを有する、能動スピーカを有するネットワークを示す。その時、能動スピーカ２５０が使用される。それらは、ネットワーク（点線）に直接接続される。アナログオーディオのための銅配線は必要でない。ＨＭＩとして、独立した装置１３９が、各々の部屋にある。それは、英数字ディスプレイおよび少しのボタンから成る。
【０１３３】
図４５は、前の図に従う能動スピーカを有するネットワークのモデルを示す。装置は、また、オーディオ選択をするための見えないソフトウェアを含む。設置中に局所化が各々のＨＭＩ装置でなされる。オーディオ選択のために、関連するスピーカおよびそれらの位置が、通知される。
全ての装置がその時ネットワーク装置であるので、より多くの機能ブロックがシステムのモデル内にある。オーディオソース用の機能ブロックに加えて、各々のスピーカに対して１台の機能ブロック増幅器がある。各々のＨＭＩ装置は、２つの機能ブロック、ＨＭＩ用の１つおよびオーディオ選択用の１つをエクスポートする。
再び、各々のオーディオ選択マネージャは、利用可能な装置に対してネットワークをスキャンして、そのＨＭＩを通して結果を提供する。スピーカの機能に従い、それはまた、バランスを設定する、イコライゼーションをするなどの、メニュー項目を提供する。
すべてのオーディオ選択マネージャはその装置のＨＭＩに接続しようと試みるだけであるので、シンクとしてＨＭＩを得るための競合はない。
【０１３４】
図４６は、前の設定に基づくが、各々の部屋に追加されたマイクロフォンを有するネットワークを示す。一旦インターコム装置が設置されるならば、設定ユーティリティはすでに設置されたディスプレイで視認できるようになる。これは、次の通りに起こる：デフォルトで、インターコムの優先度レベルは、オーディオ選択より高い。したがって、インターコムは、望む時はいつでもディスプレイを接続することができる。インターコムの設定中に、ユーザーはインターコム部屋に対する装置をグループ化している。
【０１３５】
図４７は、前の図のネットワークのモデルを示す。各々の部屋は、追加の機能ブロックマイクロフォンを得た。これに加えて、インターコムのための１つのマネージャが、追加された。ソースとシンクの接続は、前の例のようになされる。インターコムがより上位の優先度レベルを有するので、それは常にそれが望むものは何でも接続することができる。オーディオ選択マネージャは、次に、接続する前にインターコムマネージャで接続要求をしなければならない。ＨＭＩがまた、小さなディスプレイを提供するので、部屋対部屋接続、部屋の聴取（乳児電話）の様に、ずっと多いインターコム動作が可能である。
【図面の簡単な説明】
【０１３６】
【図１】本発明に従うネットワークの代表的アプリケーションを例示する図である。
【図２】典型的ないくつかのネットワークトポロジを例示する図である。
【図３】ネットワークをスキャンするマネージャ（管理ロジック）を示す図である。
【図４】ネットワークのソースとシンクのいくつかに制御メッセージを送信するマネージャを示す図である。
【図５】接続されたソースとシンクを示す図である。
【図６】オーディオシャトルの一例を示す図である。
【図７】一群のマネージャがいくつかのソースとシンクを制御する、より複雑なネットワークを示す図である。
【図８】割り当てられた優先度を有する以前のモデルを示す図である。
【図９】２台のおそらく競合するオーディオシャトルを有する構成を示す図である。
【図１０】２台のオーディオシャトルおよび固有の優先度を有する構成を示す図である。
【図１１】ソースアクセスとシンクアクセスについて交渉するための権利を獲得するプロセスを示す図である。
【図１２】例示的な接続要求手続きを示す図である。
【図１３】プロファイラによって変更される要求を示す図である。
【図１４】音声認識ソフトウェアおよびマイクロフォンを有するシステムのモデルを示す図である。
【図１５】仮想シンクと共に図１４のモデルを示す図である。
【図１６】単一のシンクにだけ接続されることができるソースを有するシナリオを示す図である。
【図１７】新しいリンクを有する図１６のシナリオを示す図である。
【図１８】２点間接続を示す
【図１９】１点対多点接続を示す図である。
【図２０】多点対１点接続を示す図である。
【図２１】Ｎ対Ｍ接続を示す図である。
【図２２】チューナとスピーカ間の並列接続を示す図である。
【図２３】グループキャストに対するグループアドレスがどのように得られるかについて示す図である。
【図２４】リソースの解放を示す図である。
【図２５】代わりのリソースの解放を示す図である。
【図２６】拡散リソースを解放することに対する第１の方策を示す図である。
【図２７】拡散リソースを解放することに対する改良された方策を示す図である。
【図２８】異なる経路経由でグラフィックデータを受信するディスプレイを示す図である。
【図２９】ディスプレイのデータの英数字表現を示す図である。
【図３０】ディスプレイのデータのグラフィック表現を示す図である。
【図３１】ディスプレイのない単純なＨＭＩを示す図である。
【図３２】異なって備えられたＨＭＩの具体例を示す図である。
【図３３】マネージャと記述子ベースのＨＭＩとの間のデータの流れを示す図である。
【図３４】ＨＭＩにアクセスするマネージャを示す図である。
【図３５】ＨＭＩに対する競合のマネージャを示す図である。
【図３６】ＨＭＩに接続を要求する間の記述子の変化を示す図である。
【図３７】対話処理のためにインターコムのマネージャを選択するＨＭＩのマネージャを示す図である。
【図３８】ＨＭＩに接続されたインターコムのマネージャを図である。
【図３９】複数シンクを有するＨＭＩを示す図である。
【図４０】増幅器および受動スピーカを有するネットワークを示す図である。
【図４１】増幅器および受動スピーカを有するネットワークのモデルを示す図である。
【図４２】増幅器、受動スピーカおよびＨＭＩを有するネットワークを示す図である。
【図４３】増幅器、受動スピーカおよびＨＭＩを有するネットワークのモデルを示す図である。
【図４４】能動スピーカを有するネットワークを示す図である。
【図４５】能動スピーカを有するネットワークのモデルを示す図である。
【図４６】追加されたマイクロフォンを有するネットワークを示す図である。
【図４７】追加されたマイクロフォンを有するネットワークのモデルを示す図である。
【図４７】装置の挿入がどのように装置間の関係を変更することができるかについて示す図である。
【符号の説明】
【０１３７】
１００    装置：（一般）
１０１    装置：ソース＿１
１０２    装置：ソース＿２
１０３    装置：ソース＿Ｎ
１１０    装置：シンク＿１
１１１    装置：シンク＿２
１１２    装置：シンク＿Ｍ
１２０    装置：マイクロフォン＿イン＿１
１２１    装置：マイクロフォン＿イン＿２
１２２    装置：Ａｕｘ＿イン＿１
１２３    装置：Ａｕｘ＿イン＿２
１２４    装置：カメラ
１２５    装置：チューナ
１２６    装置；セットトップボックス（ＳＴＰ）
１２７    装置：ビデオソース
１３０    装置：スピーカ＿１
１３１    装置：スピーカ＿２
１３２    装置：Ａｕｘ  アウト＿１
１３３    装置：Ａｕｘ  アウト＿２
１３４    装置：増幅器＿１
１３５    装置：増幅器＿２
１３６    装置：増幅器＿３
１３７    装置：仮想＿増幅器
１３８    装置：グラフィック＿ディスプレイ
１３９    装置：ＨＭＩ
１４０    装置：ビデオシンク
１４１    装置：ＨＭＩ  シンク／ソース
１５０    マネージャ（一般）
１５１    マネージャ＿１
１５２    マネージャ＿２
１５３    マネージャ＿３
１５４    マネージャ＿４
１６０    マネージャ：オーディオ＿ソース＿選択＿１
１６１    マネージャ：オーディオ＿ソース＿選択＿２
１６２    マネージャ：インターコム＿１
１６３    マネージャ：インターコム＿２
１６４    マネージャ：ＡＶ＿ソース＿選択
１６５    マネージャ：電話
１６６    マネージャ：ホーム＿オートメーション
１６７    マネージャ：ＨＭＩ
１６８    マネージャ：音声＿認識
１６９    マネージャ：目覚まし時計
１７０    ネゴシエーションアドミニストレータ
１７１    プロファイラ
１７９    音声認識ソフトウェア
１８０    優先度レベル
１８１    交渉する権利を要求する
１８２    交渉する権利を確認する
１８３    左側のスピーカにＣＤを要求する
１８４    右側のスピーカにＣＤを要求する
１８５    サブウーファにＣＤを要求する
１８６    左側のスピーカにＣＤを許可する
１８７    右側のスピーカにＣＤを許可する
１８８    円の図式表示
１８９    利用可能性を確認する
１９０    グループアドレスを要求する
１９１    ネットワークリソースを解放する
１９２    転送要求
１９３    データフレーム
１９４    パケットデータ
１９５    ストリーム型データ
１９６    円を描画する
１９７    ビデオストリーム
１９８    表示領域
１９９    ビデオストリームのイメージ
２００    記述子（一般）
２０１    記述子ビデオ
２０２    記述子スクリプト
２０３    記述子画像
２０４    記述子コマンド
２０５    記述子ベースのＨＭＩ
２０６    接続する
２０７    接続を確認する
２０８    記述子を渡す
２０９    対話処理イベント
２１０    記述子を転送する
２１１    記述子を確認する
２１２    マネージャ−マネージャ対話
２１３    マネージャ−装置＿１対話
２１４    マネージャ−装置＿２対話
２１５    マネージャ−装置＿３対話
２１６    装置−装置対話
２２０    装置タイプ１
２２１    装置タイプ２
２２２    装置タイプ３
２２３    装置タイプ４
２５０    スピーカ
２５１    オーディオソース
２５２    モノラル音声を有する部屋
２５３    ステレオ音声を有する部屋
２５４    サラウンドサウンドを有する部屋
２５５    装置増幅器（ネットワーク）
２５６    マネージャ：ＨＭＩ
２５７    マネージャ：相互接続
２６０    記述子ベースのＨＭＩ＿１
２６１    記述子ベースのＨＭＩ＿２
２６２    記述子ベースのＨＭＩ＿３
２６３    マネージャ：オーディオ選択＿１
２６４    マネージャ：オーディオ選択＿２
２６５    マネージャ：オーディオ選択＿３
２６６    マネージャ：インターコム
２６７    装置：外部ソース
２６８    装置：マイクロフォン＿１
２６９    装置：マイクロフォン＿２
２７０    装置：マイクロフォン＿３
２７１    装置：増幅器＿１
２７２    装置：増幅器＿２
２７３    装置：増幅器＿３
２７４    装置：増幅器＿４
２７５    装置：増幅器＿５
２７６    装置：増幅器＿６
２７７    装置：増幅器＿７
２７８    装置：増幅器＿８
３６２    アプリケーション：インターコム
３６４    アプリケーション：ＡＶ＿選択
３６５    アプリケーション：電話
３６７    アプリケーション：ＨＭＩ
４００    住宅
４０１    ガレージ
４０２    ヒータ部屋
４０３    サーバ部屋
４０４    居間
４０５    キッチン
４０６    浴室
４０７    寝室
４０８    子供部屋
４０９    趣味部屋
４１０    マイクロフォン
４１１    スピーカ
４１２    車
４１３    無線ブリッジ
４１４    空気調節装置
４１５    ヒータ
４１６    サーバ
４１７    ＴＶ
４１８    ラップトップ
４１９    ＷＬＡＮブリッジ
４２０    オーディオシャトル
４２１    カメラ
４２２    正面玄関
４２３    フラットパネルディスプレイ
４２４    ＴＶ
４２５    ＴＶ
４２６    カメラ
４２７    ＰＣ
４２８    キーボード
【図１】
2008532375.tif 000004
【図２】
2008532375.tif 000005
【図３】
2008532375.tif 000006
【図４】
2008532375.tif 000007
【図５】
2008532375.tif 000008
【図６】
2008532375.tif 000009
【図７】
2008532375.tif 000010
【図８】
2008532375.tif 000011
【図９】
2008532375.tif 000012
【図１０】
2008532375.tif 000013
【図１１】
2008532375.tif 000014
【図１２】
2008532375.tif 000015
【図１３】
2008532375.tif 000016
【図１４】
2008532375.tif 000017
【図１５】
2008532375.tif 000018
【図１６】
2008532375.tif 000019
【図１７】
2008532375.tif 000020
【図１８】
2008532375.tif 000021
【図１９】
2008532375.tif 000022
【図２０】
2008532375.tif 000023
【図２１】
2008532375.tif 000024
【図２２】
2008532375.tif 000025
【図２３】
2008532375.tif 000026
【図２４】
2008532375.tif 000027
【図２５】
2008532375.tif 000028
【図２６】
2008532375.tif 000029
【図２７】
2008532375.tif 000030
【図２８】
2008532375.tif 000031
【図２９】
2008532375.tif 000032
【図３０】
2008532375.tif 000033
【図３１】
2008532375.tif 000034
【図３２】
2008532375.tif 000035
【図３３】
2008532375.tif 000036
【図３４】
2008532375.tif 000037
【図３５】
2008532375.tif 000038
【図３６】
2008532375.tif 000039
【図３７】
2008532375.tif 000040
【図３８】
2008532375.tif 000041
【図３９】
2008532375.tif 000042
【図４０】
2008532375.tif 000043
【図４１】
2008532375.tif 000044
【図４２】
2008532375.tif 000045
【図４３】
2008532375.tif 000046
【図４４】
2008532375.tif 000047
【図４５】
2008532375.tif 000048
【図４６】
2008532375.tif 000049
【図４７】
2008532375.tif 000050
【国際調査報告】
2008532375.tif 000051
2008532375.tif 000052
2008532375.tif 000053