(57)【要約】ホームネットワークにおけるブリッジは、装置の第１および第２クラスタを結合する。クラスタは異なるソフトエア・アーキテクチャを有する。ブリッジはインターネットにおけるサーバに結合される。このサーバはいくつかの規格群を探索するサービスを提供し、ブリッジが適切な変換モジュールを発見しダウンロードすることを可能にし、第１クラスタにおける装置が第２クラスタと相互作用することを可能にする。
2004505499.tif 000002
【特許請求の範囲】
【請求項１】
ホーム・ネットワークのユーザにサービスを提供する方法であって：
当該方法は、ネットワークの第１クラスタの要素が前記ホーム・ネットワークの第２クラスタと相互作用することを可能にし、
前記第１クラスタは第１ソフトウエア・アーキテクチャを有し、
前記第２クラスタは前記第１クラスタとは異なる第２ソフトウエア・アーキテクチャを有し、
前記第１および第２クラスタがブリッジを通じて結合され、
当該方法は：
前記各クラスタの外部のサーバが、前記第１クラスタの第１ソフトウエア表現による要素のリファレンスを受信することを可能にし、
前記ブリッジに前記リファレンスに関連する変換モジュールを提供し、前記ブリッジにインストールされたモジュールにおいて前記第２クラスタの前記要素を少なくとも部分的に表現する
ことを特徴とする方法。
【請求項２】
前記サーバが前記ブリッジからの前記リファレンスを受信することを特徴とする請求項１記載の方法。
【請求項３】
前記ブリッジがインターネットを介して前記サーバに結合されることを特徴とする請求項１記載の方法。
【請求項４】
前記第１クラスタがＨＡＶｉクラスタより成ることを特徴とする請求項１記載の方法。
【請求項５】
前記第１クラスタがＵＰｎＰクラスタより成ることを特徴とする請求項１記載の方法。
【請求項６】
第１および第２クラスタに結合するブリッジおけるインターネットを通じてダウンロードされたモジュールにおいて、第１ソフトウエア・アーキテクチャの第１ホーム・ネットワーク・クラスタの要素が、第２ソフトウエア・アーキテクチャの第２ホーム・ネットワーク・クラスタと相互作用することを可能にする少なくとも１つの変換モジュールより成ることを特徴とするデータ・ベース。
【発明の詳細な説明】
【０００１】
本願は、６／２５／９９に出願されたＹｅｖｇｅｎｉｙ Ｅｕｇｅｎｅ Ｓｈｔｅｙｎによる “ＢＲＩＤＧＩＮＧ ＭＵＬＴＩＰＬＥ ＨＯＭＥ ＮＥＴＷＯＲＫ ＳＯＦＴＷＡＲＥ ＡＲＣＨＩＴＥＣＴＵＲＥＳ”と題する米国特許出願０９／３４０，２７２の一部継続出願（代理人管理番号ＰＨＡ２３，６３４）に関連する。
【０００２】
本発明は、異なるソフトウエア・アーキテクチャに基づく複数のネットワークの橋渡し又はブリッジ（ｂｒｉｄｇｉｎｇ）に関連する。
【０００３】
家庭における各々の装置について、単一の一般的に適用可能なネットワーク規格（スタンダード）が登場する傾向は今のところないようである。ソフトウエアに関する複数の規格が並存し、新たなものも誕生するであろう。新規のスタンダード・インターフェースは新たな形式の装置に関して設計され、そのような規格に特に照準を合わせられたものである。ホーム・アプリケーションは、総ての装置の有効な利用（ｉｎｔｅｌｌｉｇｅｎｔ ｕｓｅ）を家庭内で利用可能にするように設計されるが、現在または将来利用可能なネットワーク規格の各々又は全部を取り扱うことができない。同様に、装置自身も既存のホーム・ネットワーク規格全体をサポートすることはできないであろう。これらの理由により、異なるサブ・ネットワークまたはクラスタ（ｃｌｕｓｔｅｒ）の間で橋渡し（ブリッジ）が必要とされ、各自の１つが特定の関連する規格に従うようにする必要がある。ブリッジは、第１形式のネットワーク・クラスタにおける第１規格に従って、第２形式のネットワーク・クラスタにおける第２規格に従う装置として、装置を透明に（ｔｒａｎｓｐａｒｅｎｔｌｙ）表現することを支援する。その結果、第１規格に関して記述されたソフトウエア・アプリケーション更には第２規格に関して記述されたものに利用可能なホーム・ネットワークの単独の一体的な視野（ｓｉｎｇｌｅ ｕｎｉｆｉｅｄ ｖｉｅｗ）となる。
【０００４】
一般に、ネットワークにおける装置は、装置のインターフェースに従うメッセージ群を通じて制御される。装置及びソフトウエアの間の共同利用性は、固有の身元確認に関する規格インターフェースに依存する。アプリケーションが装置固有の身元確認情報を知ると、装置のインターフェースがわかり、それにメッセージを送信することによってその装置を制御し得る。アプリケーションにとって、標準的なメッセージを直接的に装置自身に送信するのか、これらのメッセージを異なるメッセージ群に翻訳するソフトウエア要素を通じて間接的に行うのかは問題ではなく、（最終的に）制御される装置において所望の影響または状態変化を達成する。したがって、複数の異なる規格のネットワーク間のブリッジは、マルチ・スタンダード装置と考えられる。すなわち、ブリッジはこれら複数のスタンダードの各々およびホスト・ソフトウエア要素に従い、これは装置インターフェースを第１から第２規格へおよびその逆に変換する。例えば、ブリッジは、規格Ａに従う５つの装置のクラスタと、Ａとは異なる規格Ｂに従う３つの装置との間で使用される。ブリッジは、ＡからＢへの変換を行う３つの変換モジュールと、ＢからＡへの変換を行う５つの変換モジュールとを取り扱う。したがって、規格Ａのみと相互作用することの可能なソフトウエア・アプリケーションは、８つ総ての装置を制御することが可能になる。
【０００５】
６／２５／９９に出願されたＹｅｖｇｅｎｉｙ Ｅｕｇｅｎｅ Ｓｈｔｅｙｎによる “ＢＲＩＤＧＩＮＧ ＭＵＬＴＩＰＬＥ ＨＯＭＥ ＮＥＴＷＯＲＫ ＳＯＦＴＷＡＲＥ ＡＲＣＨＩＴＥＣＴＵＲＥＳ”と題する米国特許出願０９／３４０，２７２（代理人管理番号ＰＨＡ２３，６３４）は、本願の参考文献に組み入れられ、これは、異なるソフトウエア・アーキテクチャのホーム・ネットワークのブリッジに関するものである。ネットワークの第１のものに関する装置及びサービスのソフトウエア表現に対するリファレンスが、自動的に作成される。このリファレンスは、ネットワークの第２のものに関する少なくとも一部が機能的に等価なソフトウエア表現の自動生成を可能にする程度に充分に意味付けられており、第１ネットワークの装置およびサービスが第２ネットワークからアクセス可能にする。また、この文献は、ＨＡＶｉ，ホームＡＰＩおよびジニ（Ｊｉｎｉ）ソフトウエア・アーキテクチャを意図している。
【０００６】
以下において、「変換モジュール」なる用語は、「ソフトウエア表現」の概念も含み、すなわち、物理的装置又はネットワーク若しくはその部分のサービスのソフトウエアにおける表現の概念を含み、装置又はサービスが適切なメッセージ処理または制御処理のソフトウエアにアクセス可能にさせるようにする。
【０００７】
好適には、ブリッジは以下の機能を実行する：ブリッジされたネットワークの何れかにおける装置の追加を検出すること；追加された装置形式の識別を行うこと；装置が他のネットワークに関心があるようならば、識別された装置形式に関する変換モジュールを見出すこと；およびそのネットワークで使用される規格で必要な手順に従って、他のネットワークにおける変換モジュールをインストールすること、である。
【０００８】
生き残った（ｓｕｃｃｅｓｓｆｕｌ）スタンダードは、それらの規格に適切と思われる領域で新たに開発された装置に関する規格インターフェースを定め続けるであろう。これは変換モジュールと共に開発することを必要とし、新たな装置が異なる規格に基づいてネットワーク内で表現され得るようにする必要がある。したがって、ブリッジは、将来的に利用可能な総ての各々の装置について総てを包含した変換モジュールを組み込むことができない。
【０００９】
したがって、本発明は、ブリッジが例えばインターネットのようなサーバに結合されている解決手段を提供する。このサーバは、いくつかのスタンダード群を探索するサービスを提供し、ブリッジが、ホーム・ネットワークで使用する適切な変換モジュールを見出し、ダウンロードすることを可能にする。
【００１０】
より具体的には、本発明は、ホーム・ネットワークのユーザにサービスを提供する方法に関する。その方法は、ネットワークの第１クラスタの要素が前記ホーム・ネットワークの第２クラスタと相互作用することを可能にする。第１クラスタは第１ソフトウエア・アーキテクチャを有し、第２クラスタは前記第１クラスタとは異なる第２ソフトウエア・アーキテクチャを有する。第１および第２クラスタはブリッジを通じて結合される。当該方法は、例えばインターネットにおける前記各クラスタ外部のサーバが、第１クラスタの第１ソフトウエア表現による要素のリファレンスを受信することを可能にする。ブリッジはこのリファレンスを提供し得る。本方法は更に、ブリッジに前記リファレンスに関連する変換モジュールを提供し、前記ブリッジにインストールされたモジュールにおいて前記第２クラスタの前記要素を少なくとも部分的に表現する。
【００１１】
サービス・プロバイダは、ホーム・ネットワークで使用される任意の複数の規格に関する変換モジュールのデータを維持及び更新することが可能である。機能の分担および代行は、以下に説明するように多くの利点を与える。
【００１２】
本発明は、ブリッジを非常に「軽量（ｌｉｇｈｔ−ｗｅｉｇｈｔ）」または低価格にするが、これは、ホーム内に接続され得る総ての規格の総ての装置に関する組み込まれた変換モジュールを設けることを要しないためである。格納および計算能力は、実際にブリッジされる（橋渡しされる）装置にのみ必要とされ（すなわち、潜在的にブリッジされるものについては格納の必要がない。）、且つそれらがブリッジされる場合にのみ必要とされる（例えば、「ちょうど時間通りに（ｊｕｓｔ−ｉｎ−ｔｉｍｅ）」ブリッジを行う、すなわち、新たな装置をネットワークに接続する際である。）。
【００１３】
さらに、本発明は、ホーム・ネットワークを全体として拡張化能におよび将来的に耐え得るものにする。新たな装置が発明され、その記述が様々な規格の仕様の一部となっている場合に、それらの記述は、例えば装置製造者または第三者によって、ブリッジ・サーバに対して変換され更新され、既存のホーム・ネットワークにおけるブリッジ内でそれらを利用可能にする。このプロセスは、ホーム・ネットワーク自身における要素の機構を何ら更新することを要しない。
【００１４】
更なる利益は、ブリッジ・サーバ・オペレータが個々のユーザのホーム・ネットワークの構成についての情報を取得し得ることである。この情報を利用すると、ユーザ、製造者およびサービス・プロバイダの全員にとって改善効果を得られる。これについては、例えば、９／２５／１９９８に出願され、“ＣＵＳＴＯＭＩＺＥＤ ＵＰＧＲＡＤＩＮＧ ＯＦ ＩＮＴＥＲＮＥＴ−ＥＮＡＢＬＥＤ ＤＥＶＩＣＥＳ ＢＡＳＥＤ ＯＮ ＵＳＥＲ−ＰＲＯＦＩＬＥ”　と題する米国特許出願０９／１６０，４９０があり、本願の参考文献に含まれる。この文献はサーバ・システムに関連し、ネットワーク利用可能な消費者電子装置の特定のエンド・ユーザのユーザ属性と、たとえばホーム・ネットワークのような装置のこの形式に関する新たな技術のデータ・ベースを維持するものである。ユーザ属性と新たな技術要素の間に一致が生じ、ユーザが更新又は販売申込（ｓａｌｅｓ ｏｆｆｅｒ）に関する情報を受信することを示すならば、ユーザは選択的なネットワークを通じてその要素を取得するよう通知される。これについては、例えば、１１／１０／９８に出願され、Ｙｅｖｇｅｎｉｙ Ｓｈｔｅｙｎによる“ＵＰＧＲＡＤＩＮＧ ＯＦ ＳＹＮＥＲＧＥＴＩＣ ＡＳＰＥＣＴＳ ＯＦ ＨＯＭＥ ＮＥＴＷＯＲＫＳ”と題する米国特許出願があり、参考文献に含まれる。この文献は、サーバを有するシステムに関し、装置のリストと、ユーザのホーム・ネットワークにおける機能とを利用することが可能である。このリスト（ｉｎｖｅｎｔｏｒｙ）は、例えば、ＨＡＶｉ，ＪｉｎｉおよびホームＡＰＩアーキテクチャによって提供されるような探索サービスである。また、このサーバは、ネットワークの要素に関する情報を有するデータベースを利用することができる。サーバは、ユーザのネットワークに存在する装置との共同（ｓｙｎｅｒｇｙ）が、目録のリストおよびユーザの属性に基づいて強化され得るか否かを判定する。その共同に適切な特徴要素が存在するならば、これらの基準に基づいて、ユーザは通知される。この意味において、米国特許出願０９／１８９，５３５は「アプリケーション示唆装置」の概念のものに関する。
【００１５】
本発明の更なる利点は、サーバ・オペレータが、特定の規格にブリッジされる特定の装置に対する市場要請を測定可能にすることである。装置製造者または他の適切な第三者は、要請が生じていることを通知されることが可能である。新たな変換モジュールがサーバで利用可能になると、ブリッジはアップグレードの通知を受けることが可能であり、そのブリッジは、サーバが従うことのできない過去の変換モジュールに関する要求を送信する。
【００１６】
ブリッジは、他のクラスタに対するブリッジを提供するために、ホーム・ネットワークにおける特定のクラスタの装置内でソフトウエア要素として実現可能である。例えば、ＨＡＶｉセット・トップ・ボックスは、ＨＡＶｉクラスタを例えばネットワーク上のＵＰｎＰクラスタにブリッジするソフトウエア要素を有することが可能である。同様に、ＵＰｎＰクラスタを制御するＰＣは、ホーム・ネットワークのＵＰｎＰクラスタをＨＡＶｉクラスタにブリッジすることを支援するソフトウエア要素を有することが可能である。
【００１７】
以下、添付図面を参照しながら、実施例を利用して本発明を詳細に説明する。
【００１８】
図面を通じて同一の参照番号は同様な又は対応する要素を示す。
【００１９】
上述したように、本発明の一形態は、例えばインターネットにおけるサーバにブリッジを接続することに関連する。サーバはいくつかの規格群に関する探索サービスを提供し、ブリッジが、ホーム・ネットワークで適切な変換モジュールを見出しダウンロードすることを可能にし、最終的には、第１アーキテクチャにおけるサブ・ネットワーク上の装置が、第２アーキテクチャのサブ・ネットワークにおける装置と共に動作するようにする。
【００２０】
図１は、ホーム・ネットワーク・システム１００の概略図であり、装置１０４，１０６，１０８の第１クラスタ１０２を有し、これは、以後規格Ａと呼ぶ第１ソフトウエア・アーキテクチャに従う。システム１００は、装置１１２，１１４，１１６の第２クラスタ１１０を有し、これは、以後規格Ｂと呼ぶ第１ソフトウエア・アーキテクチャに従う。クラスタ１０２，１１０はブリッジ１１８を通じて相互接続される。一方の規格Ａのクラスタ１０２と他方の規格Ｂのクラスタ１１０の間で有意義なネットワーク相互作用を行うため、変換モジュールが導入される。これらのモジュールは、クラスタ１０２および１１０の両者に参加する必要がある。モジュールは一般に、その参加を可能にするために、低レベルの通信ソフトウエアのようなクラスタ近辺の（ｌｏｃａｌ）要素を必要とする。自身の通信ソフトウエアを有する各変換モジュールを有するのではなく、ブリッジ１１８のプラットフォーム要素１２０としてそのソフトウエアを提供することがより効率的である。
【００２１】
本発明の手順は、Ｂ装置１１６がシステム１００に追加されようとする例に関して説明される。
【００２２】
第１ステップは、Ｂ装置１１６をＢクラスタ１１０または「ブーティング（ｂｏｏｔｉｎｇ）」Ｂ装置１１６に物理的に接続する。
【００２３】
次のステップにおいて、ブリッジ１１８はＢ装置１１６を新たな追加として検出する。なぜなら、ブリッジ１１８はＢクラスタ１１９を走査するか、又はその登録／ディレクトリ（ｄｉｒｅｃｔｏｒｙ）／探索のサービス（図示せず）を周期的に行うからであり、またはＢクラスタ１１０が積極的にブリッジ１１８に通知するからである。ブリッジ１１８は、インストレーション・マネジャと呼ばれるソフトウエア要素１２２より成り、これは、システム１００にＢ装置１１６を統合するのに必要な更なるソフトウエア要素のインストールを取り扱う。その形態は、例えば、米国特許出願０９／３４０，２７２（代理人管理番号ＰＨＡ２３，６３４）に説明されている。その文献では、ソフトウエア要素はリファレンス・ファクトリと呼ばれ、登録された装置の任意のソフトウエア表現から情報を抽出することが可能である。このリファレンス・ファクトリは、サービスのリストを問い合わせることが可能であり、適切なソフトウエア・アーキテクチャの手法に従って新たなソフトウエア表現の通知を取得可能である。同様に、インストレーション・マネジャ１２２は、新たに追加されたＢ装置１１６の情報記述を受信又は抽出する。インターネット１２６を通じてブリッジ・サーバ１２４に送信される前に、この情報記述は、再フォーマット化され得る。さらに、ブリッジ１１８は、ホーム・ネットワーク１００の局所的な実行環境についての情報を提供することが好ましい。この情報は、サーバ１２４がブリッジ１１８にダウンロードするソフトウエア要素に適切なものである。環境に関する適切な情報は、ここではＡ規格クラスタ１０２およびＢ規格クラスタ１１０において、存在するソフトウエア・アーキテクチャに関連するものである。その情報は、ブリッジ１１８における、利用可能なメモリ、使用されるオペレーティング・システムの形式、存在する仮想的な機構、プラットフォーム・ライブラリ等にも関連する。この情報に基づいて、サーバ１２４は適切な変換モジュール、またはシステム１００のネットワーク環境に適する又は最適なモジュールを選択することが可能になる。
【００２４】
記述及び環境情報の受信の際に、サーバ１２４は探索サービスを利用し、これは、Ａクラスタ１０２におけるＢ装置１１６の表現に関する変換モジュールを利用して、Ｂ装置１１６の情報，記述の合致を必要とする。一般に、サーバ１２４は利用可能な複数の探索サービスを有する：１つは各々の順序付けられた対（Ｘ，Ｙ）であり、ＸおよびＹはサーバ１２４でサポートされる規格である。規格Ｘのクラスタと規格Ｙの他のクラスタとの間の双方向ブリッジをサポートするため、２つの探索サービスが必要とされ、それらは：（Ｘ，Ｙ）および（Ｙ，Ｘ）である。すべて異なる規格Ｐ，Ｑ，Ｒの３つのクラスタの間の双方向ブリッジをサポートするには、６つの探索サービスが必要であり、それらは：（Ｐ，Ｑ）；（Ｑ，Ｐ）；（Ｐ，Ｒ）；（Ｒ，Ｐ）；（Ｑ，Ｒ），（Ｒ，Ｑ）である。当然ながら、サーバ１２４は単方向ブリッジのみをサポートすることも可能である。
【００２５】
装置１０４−１０８および１１２−１１６のような装置は、しばしば複合的な対象（オブジェクト）である。たとえば、ＴＶセットは一般にディスプレイ、増幅器、チューナ要素より成る。サーバ１２４は先ず複合対象物全体を、同等な機能を有する新たな複合装置に変換することを試みる。これが成功しなかったならば、サーバ１２４は副次的な要素を１つずつ変換する。これは部分的な結果になるが、依然として有効なマッピング（ｍａｐｐｉｎｇ）である。例えば、Ａクラスタ１０２がチューナに関する規則を利用できないならば、Ｂ形式ＴＶは、モニタのような表示／増幅装置としてＡクラスタ１０２を依然としてブリッジすることができる。規格Ａおよび規格Ｂ内の特定の副次的要素の間で１つずつの関係が存在しないならば、１対多または多対多のマッピングが使用される。例えば、規格Ａがボリューム制御およびイコライザ制御を単独の副次的要素として定め得るが、規格Ｂはそれらを区別して別々の副次的要素とする場合である。この場合、ボリューム制御要素を有するがイコライザ要素は有しないＢクラスタ１１０の装置は、Ａクラスタ１０２にブリッジされ得ない。他方、単独の増幅要素（ボリューム制御に加えてイコライザも）を有するＡクラスタ１０２の装置は、副次的要素の１対多マッピングを適用してネットワークＢにブリッジされ得る。ほとんどの場合において、Ａクラスタ１０２の副次的要素の特定の集合は、多対多のマッピングの下でＢクラスタの副次的要素の他の集合に合致させることが可能である。
【００２６】
次に、合致変換モジュール１２８が、規格Ａのプロトコルに従って、ブリッジにダウンロードされ、プラットフォーム１２０にインストールされ、登録されたことを発見したと仮定する。これは、クラスタＡ１０２の他のアプリケーションおよび装置がモジュール１２８を通じて装置１１６を発見または使用することを可能にする。ブリッジ１１８の実行環境で実行されるまで、モジュール１２８のインストールおよび登録は延期される。
【００２７】
以下、図２，３を参照して、Ｈａｖｉおよびユニバーサル・プラグ・アンド・プレイ（ＵＰｎＰ）ホーム・ネットワークのブリッジの例を利用して、本発明を説明する。ホーム・ネットワーク分野におけるソフトウエア・アーキテクチャに関するＨＡＶｉおよびホームＡＰＩおよびＪｉｎｉ規格は、上述した参考文献の米国特許出願０９／３４０，２７２（代理人管理番号ＰＨＡ２３，６３４）にいくらか詳細に説明されている。ＨＡＶｉにおいて、ＤＣＭ（デバイス制御モジュール）は、ＨＡＶｉネットワークにおける単独の装置または機能を表現するソフトウエア要素である。ＤＣＭはその装置に関してＡＰＩ規定されたＨＡＶｉを明らかにする。ＤＣＭは動的な性質を有する：装置がネットワークにインストールされ、または削除されると、その装置に関するＤＣＭはネットワークにおいてそれぞれインストール又は削除される必要がある。ＤＣＭはＨＡＶｉ概念の主要部であり、ＨＡＶｉネットワークに新たな装置および機能を収容する場合における柔軟性の拠り所である。
【００２８】
ユニバーサル・プラグ・アンド・プレイ（ＵＰｎＰ： Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ）は、開放ネットワーク・アーキテクチャであり、複数の利用者からの分散した装置およびソフトウエア・アプリケーションの中での簡潔な特殊通信を可能にするよう設計される。ＵＰｎＰは、インターネット技術にてこ入れし（ｌｅｖｅｒａｇｅ）、管理されていないホーム・ネットワークにおける使用に拡張する。ＵＰｎＰは、ホーム・オートメーション、音響／映像、プリンタ、高機能な電話等を包含する家庭機器を制御することを意図する。ＵＰｎＰは、制御点（ＣＰ）と制御装置（ＣＤ）とを区別する。ＣＰは例えばＰＣ上で走るブラウザ、無線パッド等より成り、制御される装置によって提供される機能にユーザがアクセスすることを可能にする。
【００２９】
ＵＰｎＰはＣＰによる装置の探索および制御のためのプロトコルを定める。ＵＰｎＰは、音響／映像装置により使用されるストリーム機構を定めない。探索および制御プロトコルのいくつかはＵＰｎＰ仕様の一部であるが、他はＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｋｓ Ｆｏｒｃｅ）によって別々に規格化される。ＣＰおよび装置間の相互作用は、インターネット・プロトコル（ＩＰ）に基づく。しかしながら、ＵＰｎＰは、ＩＰ装置でないものが、ＩＰに従う装置上で走るソフトウエア要素によって代行されることを可能にする。そのような要素は、制御装置（ＣＤ）プロキシと呼ばれ、代行される装置へのＵＰｎＰ相互作用の変換および転送を取り扱う。
【００３０】
ＵＰｎＰ装置は、最低レベルのサービスに関する副次的装置の階層を有する。装置及びサービスの両者は標準かされた形式を有する。装置形式は副次的装置または包含することが許容されるサービスを判定する。サービス形式は、サービスが包含することを許容する動作及び状態変数を定める。状態変数は装置の状態を模り（ｍｏｄｅｌ）、その状態を変化させるために動作はＣＰによって包含されることが可能である。状態変数および動作の記述は、ＳＣＰ（サービス制御プロトコル）と呼ばれる。ＵＰｎＰ装置は、ＸＭＬ書類の形式でそれ自身の記述を提供する。この書類は、特に、それがサポートするサービス形式を含む。選択的に、装置はＣＰによる直接ＵＩ制御のための提示サーバを有することが可能である。
【００３１】
ＵＰｎＰは自動ＩＰを前提とし、これは、ＤＨＣＰサーバが欠如している場合に、固有のアドレスを取得するためのＩＰ装置用の手段を提供する。ＵＰｎＰは、ＳＳＤＰ（単独サービス探索プロトコル）と呼ばれるＵＤＰマルチキャストに基づく探索プロトコルを規定する。ＳＳＤＰは、それらが提供するサービスを周期的にマルチキャストで通知する装置に基づく。その通知はＵＲＬを含み、制御装置からそこにサービス・アクションが送信される。これに加えて、ＣＰはＵＰｎＰネットワークに装置またはサービスの形式または事実を問い合わせる。
【００３２】
ＵＰｎＰはＧＥＮＡ（一般イベント通知アーキテクチャ）を前提とし、状態変数予約（ｓｕｂｓｃｒｉｐｔｉｏｎ）およびＴＣＰに基づく変更通知機構を定める。
【００３３】
ＣＰが使用することを希望するサービスを検出した後に（ＳＳＤＰを通じて）、ＳＣＰアクションを制御サーバＵＲＬに送信することによって、又は状態変数に関する問い合わせをすることによって、サービスを制御する。これらのメッセージの本体はＳＯＡＰ（シンプル・オブジェクト・アクセス制御）規格によって定められる。ＳＯＡＰはＸＭＬに基づく遠隔手順呼出機構を定める。
【００３４】
ＵＰｎＰ装置におけるＨＡＶｉ装置の変換モジュール又はソフトウエア表現は、制御装置（ＣＤ）プロキシと呼ばれ、ＨＡＶｉにおけるＵＰｎＰ装置のソフトウエア表現は装置制御モジュール（ＤＣＭ）と呼ばれる。
【００３５】
ＨＡＶｉからＵＰｎＰへのブリッジ
図２は、ＨＡＶｉからＵＰｎＰへのブリッジを示すホーム・ネットワーク・システム２００のブロック図であり、太い矢印は、ここではディジタル・カメラであるＨＡＶｉ装置からＵＰｎＰへブリッジするためのステップ順序を示す。
【００３６】
システム２００は、装置２０２，２０４，２０６によって形成されるＵＰｎＰクラスタを有する。装置２０２は、ライト、ＭＰ３プレイヤより成る装置２０４およびプリンタより成る装置２０６を有する。システム２００は、ＴＶ２０８およびディジタル映像レコーダ２１０によって形成されるＨＡＶｉネットワーク・クラスタを有する。クラスタはブリッジ１１８を通じて接続される。
【００３７】
ステップ２１２において、ＨＡＶｉカメラ２１４は、ＨＡＶｉの１３９４ネットワークに物理的に挿入され、カメラ装置２１４をアクティブなＨＡＶｉノードにする。
【００３８】
ステップ２１６において、この装置の追加が、プラットフォーム要素グループ２１８にあるＨＡＶｉイベント管理部によって発見される。ＨＡＶｉプラットフォームはＨＡＶｉ新規ソフトウエア要素イベントに対して監視および応答し、またはＨＡＶｉネットワーク・リセット・イベントを監視して新規装置としてカメラ２１４を発見する。
【００３９】
ステップ２２０において、カメラ２１４およびそのＦＣＭ要素のＤＣＭの登録属性が、プラットフォーム２１８のＨＡＶｉ登録部から抽出され、ブリッジ・サーバ２２２によって理解される何らかのフォーマット、例えばＸＭＬにエンコードされ、ＨＴＴＰポスト（ＰＯＳＴ）を利用してブリッジ・サーバ２２２に送信される。ブリッジ１１８は、ＨＡＶｉウェブプロキシＦＣＭを利用してこれを実行する。
【００４０】
ステップ２２４において、探索要素は、ＨＡＶｉ装置記述をＤＣＭ／ＦＣＭ登録増区正の形式で、その装置に関するＵＰｎＰＣＤプロキシ２２６にマッピングする。ＵＰｎＰＣＤプロキシおよびＨＡＶｉＤＣＭは複合対象物なので、上述したように、位置付けプロセスが副次的装置（要素）のレベルで実行される。ＨＡＶｉにおいて、装置（ソフトウエア表現はＤＣＭ）は、多数の機能要素より成る（ソフトウエア表現はＦＣＭ）。どのＦＣＭがＤＣＭブリッジ１１８の部分であるかを見出すことは、ＤＣＭ：：ＧｅｔＦｃｍＳｅｉｄＬｉｓｔ　およびＦＭＣ：：ＧｅｔＦｃｍＴｙｐｅ　方法を利用して行うことが可能であり、またはＧＵＩＤおよび目標ＩＤ属性のｎ１フィールドに対して同一の値を有する登録エントリを見出す。ＵＰｎＰにおいて、装置は、最低レベルのサービスに関する副次的装置の階層構造を有する。ＦＣＭは同一目的をサービスとして提供する。ＨＡＶｉ装置をＵＰｎＰＣＤプロキシ２２６にマッピングすることは、完全なＤＣＭから完全なＣＤプロキシへ、または部分的にＦＣＭからプロキシ・サーバへのものであり得る。ＦＣＭのサービスへのマッピングは１対１、１対多または多対多であり得る。
【００４１】
ステップ２２８では、ダウンロードされたＣＤプロキシ２２６がブリッジ１１８の実行環境で走る。これは、ＣＤプロキシ２２６の固有のＵＲＬに関するｈｔｔｐサーバをインストールすることを含む。
【００４２】
ステップ２３０では、ＣＤプロキシ２２６が周期的な通知メッセージを伝送し、発見メッセージに応答する。これは、他のＵＰｎＰアプリケーションおよび装置が、ＣＤプロキシ２２６を通じて、ＨＡＶｉカメラ２１４を探索および使用することを可能にする。
【００４３】
ＵＰｎＰからＨＡＶｉへのブリッジ
図３は、システム２００において、ここではプリンタ２０６であるＵＰｎＰ装置から、ＨＡＶｉクラスタ２０８，２１０，２１４へのブリッジのステップを示す。
【００４４】
ステップ３０２において、ＵＰｎＰプリンタ２０６はＵＰｎＰネットワークに物理的に挿入され、ＵＰｎＰ装置に「電源投入」する。
【００４５】
次のステップ３０４は、ＵＰｎＰ装置の通知メッセージを監視および応答することを含む。
【００４６】
ステップ３０６において、プリンタ２２６の装置記述書類は、通知メッセージに含まれるＵＲＬから抽出され、その書類はＨＴＴＰポストを利用してブリッジ・サーバ２２２に送信される。
【００４７】
ステップ３０８は探索要素を含み、これはＵＰｎＰ装置記述を、（ＸＭＬにおける）記述書類の形式で、ここではプリンタ２２６である装置のためのＨＡＶｉＤＣＭにマッピングする。ＵＰｎＰＣＤプロキシおよびＨＡＶｉＤＣＭは複合対象物であるので、上述したように、位置付けプロセスが副次的装置（要素）レベルで実行される。ＨＡＶｉ装置（ソフトウエア表現はＤＣＭ）は多数の機能要素（ソフトウエア表現はＦＣＭ）より成る。ＵＰｎＰにおいて、装置は、最低レベルにおいてサービスに関する副次的装置の階層構造を有する。ＵＰｎＰ装置の一部であるサービスは、装置記述書類において見出され得る。ＦＣＭは同一目的をサービスとして提供する。ＨＡＶｉ装置をＵＰｎＰＣＤプロキシにマッピングすることは、完全なＤＣＭから完全なＣＤプロキシへ、または部分的にＦＣＭからサービスへのものであり得る。ＦＣＭのサービスへのマッピングは１対１、１対多または多対多であり得る。
【００４８】
ステップ３１０は、ブリッジ１１８の実行環境においてダウンロードされたプリンタＤＣＭ３１２を実行させることを含む。これは、ＤＣＭのインストール方法を呼び出すことを含む。
【００４９】
ステップ３１４は、ＤＣＭ３１２およびそのＦＣＭを含み、ＨＡＶｉソフトウエア要素を作成し、それらを利用して、ＨＡＶｉ登録要素（これは、ブリッジ１１８で利用可能なプラットフォーム２１８の一部である）に関する登録を行う。
【００５０】
ステップ３１６では、ＨＡＶｉ登録部がグローバル新規ソフトウエア要素イベントを、ＤＣＭおよびその一部である総てのＦＣＭに関して宣言する。これは、他のＨＡＶｉアプリケーションおよび装置が、プリンタＤＣＭ３１２を通じてＵＰｎＰプリンタ２０６を発見及び使用することを可能にする。
【図面の簡単な説明】
【図１】
図１は、本発明による２つのネットワーク間のブリッジの原理を説明するブロック図である。
【図２】
図２は、ＨＡＶｉからＵＰｎＰへブリッジする様子を表わしたブロック図である。
【図３】
図３は、ＵＰｎＰからＨＡＶｉへブリッジする様子を表わしたブロック図である。
【図１】
2004505499.tif 000003
【図２】
2004505499.tif 000004
【図３】
2004505499.tif 000005
【国際公開パンフレット】
2004505499.tif 000006
2004505499.tif 000007
2004505499.tif 000008
2004505499.tif 000009
2004505499.tif 000010
2004505499.tif 000011
2004505499.tif 000012
2004505499.tif 000013
2004505499.tif 000014
2004505499.tif 000015
2004505499.tif 000016
2004505499.tif 000017
2004505499.tif 000018
2004505499.tif 000019
2004505499.tif 000020
【国際公開パンフレット（コレクトバージョン）】
2004505499.tif 000021
【国際調査報告】
2004505499.tif 000022
2004505499.tif 000023
2004505499.tif 000024