(57)【要約】ホームネットワークは、ＵＰｎＰクラスタ及びＨＡＶｉクラスタを備えている。ＵＰｎＰは、デバイス間で送出された標準化メッセージに基づいたプログラマチックデバイスインタフェースを使用する。ＨＡＶｉは、プログラマチックインタフェースを使用するが、適切なデバイスタイプ及びＦＣＭを前もって知る必要がある。加えて、現在のＵＰｎＰ及びＨＡＶｉ標準は、意味的な差のために、互いに容易にマッピングすることができるデバイスを定義しない。この問題を解決するために、ＨＡＶｉクラスタのＵＰｎＰデバイスを表すことにより、クラスタはブリッジされる。ここでは、ＵＰｎＰデバイス記述ドキュメントが使用されてＨＡＶｉ ＤＤＩターゲットを生成し、ＨＡＶｉ ＵＩを通してＵＰｎＰデバイスのＵＩベースの制御が可能となる。【特許請求の範囲】
【請求項１】
第１の機能の第１のクラスタをブリッジすることを可能にして、第２の機能の第２のクラスタをブリッジすることを可能にする方法であって、
前記第１のクラスタは、プログラマチックインタフェースを通して前記第１の機能の制御を提供する第１のソフトウェアアーキテクチャを有し、前記第２のクラスタは、ＵＩベースのインタフェースを通して前記第２の機能の制御を提供する第２のソフトウェアアーキテクチャを有し、
前記プログラマチックインタフェースの前記ＵＩベースのインタフェースへの変換を提供するステップを備える、方法。
【請求項２】
前記第１のソフトウェアアーキテクチャはＵＰｎＰに対応し、前記第２のソフトウェアアーキテクチャはＨＡＶｉに対応する、
請求項１記載の方法。
【請求項３】
前記提供するステップは、ＵＰｎＰのデバイス記述ドキュメントからＨＡＶｉ ＤＤＩターゲットソフトウェアコンポーネントを生成するステップを含む、
請求項２記載の方法。
【請求項４】
第１の機能の第１のクラスタと、
第２の機能の第２のクラスタとを備え、
前記第１のクラスタは、プログラマチックインタフェースを通して前記第１の機能の制御を提供する第１のソフトウェアアーキテクチャを有し、前記第２のクラスタは、ＵＩベースのインタフェースを通して前記第２の機能の制御を提供する第２のソフトウェアアーキテクチャを有し、
前記プログラマチックインタフェースからＵＩベースのインタフェースに変換するための前記第１のクラスタと前記第２のクラスタの間にブリッジを有する、ホームネットワーク。
【請求項５】
前記第１のソフトウェアアーキテクチャはＵＰｎＰに対応し、前記第２のソフトウェアアーキテクチャはＨＡＶｉに対応する、
請求項４記載のネットワーク。
【請求項６】
前記提供するステップは、ＵＰｎＰのデバイス記述ドキュメントからＨＡＶｉ ＤＤＩターゲットソフトウェアコンポーネントを生成するためのジェネレータを含む、
請求項５記載のネットワーク。
【請求項７】
第１の機能の第１のクラスタ及び第２の機能の第２のクラスタを含むホームネットワークでの使用向けのブリッジングソフトウェアであって、
前記第１のクラスタは、プログラマチックインタフェースを通して前記第１の機能の制御を提供する第１のソフトウェアアーキテクチャを有し、前記第２のクラスタは、ＵＩベースのインタフェースを通して前記第２の機能の制御を提供する第２のソフトウェアアーキテクチャを有し、
前記プログラマチックインタフェースを前記ＵＩベースのインタフェースに変換することに基づいて、前記第１のソフトウェアと前記第２のソフトウェアとを結合するように作用する、
ブリッジングソフトウェア。
【請求項８】
ＵＰｎＰに対応する前記第１のソフトウェアアーキテクチャと、ＨＡＶｉに対応する前記第２のソフトウェアアーキテクチャとを結合するための、請求項７記載のブリッジングソフトウェア。
【請求項９】
ＵＰｎＰのデバイス記述ドキュメントからＨＡＶｉ ＤＤＩターゲットソフトウェアコンポーネントを生成するためのジェネレータを含む、請求項８記載のブリッジングソフトウェア。
【発明の詳細な説明】
【０００１】
［発明の分野］
本発明は、ホームネットワークに関し、特に、異なるソフトウェアアーキテクチャによるクラスタを有するブリッジングネットワークに関する。
【０００２】
［発明の背景］
家庭におけるそれぞれの装置について、単一の一般性のある適用可能なネットワーク標準が存在する可能性はなさそうである。ソフトウェアアーキテクチャについての複数の標準が共存しており、新たな標準が出現することになる。新たな標準的なインタフェースは、それら標準により特に狙いとされる新しい装置のタイプについて発展される。
【０００３】
ホームアプリケーションが設計され、家庭において利用可能な全ての装置の知的な使用をなしている。しかし、ホームアプリケーションは、使用においてネットワーク標準のそれぞれについて扱うことができず、将来的にも利用可能になるものでもない。
【０００４】
同様に、装置自身は、それぞれ実在するホームネットワーク標準をサポートすることができない。これらの理由のために、異なるサブネットワーク又はクラスタ間にブリッジが必要とされており、それぞれのブリッジは、特定のそれぞれの標準に対応している。
【０００５】
ブリッジは、第１のタイプのネットワーククラスタにおける第１の標準に対応し、第２のタイプのネットワーククラスタにおける第２の標準に対応する装置をトランスペアレントに表す役割を果たす。結果として、第２の標準について書かれたソフトウェアアプリケーションと同様に、第１の標準について書かれたソフトウェアアプリケーションを利用可能な１つに統合されたホームネットワークの外観をとなる。
【０００６】
ホームネットワーキング標準は、下位レベルのプロトコルスタック（トランスポートレベルまで、たとえば、ＨｏｍｅＰＮＡ、ＨｏｍｅＲＦ）、又は上位レベルのプロトコルスタック（トランスポートレベルからアプリケーションレベルまで）のいずれかに一般的に向けられている。
【０００７】
この記載の残りでは、第２のタイプのホームネットワーク標準に対して一般的に参照される。これら標準の例は、ＨＡＶｉ、ＵＰｎＰ及びＪｉｎｉである。典型的に、ホームネットワーク標準は、アプリケーション（すなわちクライアント）について２つの方法であるプログラマチック制御とＵＩ（ｕｓｅｒ−ｉｎｔｅｒｆａｃｅ）ベースの制御のうちの１つを制御装置（すなわちサーバ）に提供する。
【０００８】
プログラマチック制御とは、標準化されたメッセージを装置に送出することに基づく制御、すなわち、標準化ＡＰＩを呼んで結果的にメッセージが装置に送出されることに基づく制御を言及する。この種の制御は、要求される直接のユーザインタラクションなしに装置を制御するアプリケーションについて有効である。この場合、コントローラ及び制御可能な装置の両者は、交換可能な所定のメッセージのセットを使用している。すなわち、コントローラは、制御可能な装置のタイプを前もって知らなければならない。
【０００９】
ＵＩベースの制御とは、制御装置から制御可能な装置へのユーザインタラクションを送出することを使用した制御を言及する。ここで、ユーザは、ＵＩクライアント、すなわちブラウザと対話して、ユーザのアクションにより、制御可能な装置のＵＩサーバにメッセージが送出される。
【００１０】
メッセージは、特定のＵＩプロトコルを使用して交換され、該プロトコルの例としては、（ＵＰｎＰで使用される）ＨＴＭＬ、及び（ＨＡＶｉで使用される）ＤＤＩである。頭字語“ＤＤＩ”は、Ｄａｔａ Ｄｒｉｖｅｎ Ｉｎｔｅｒａｃｔｉｏｎを表し、ユーザインタフェースが表示される必要があるアプリケーション又はＤＣＭと、表示装置との間で実行されるプロトコルを言及する。
【００１１】
ＤＤＩターゲットは、装置のＤＣＭの一部である。頭字語“ＤＣＭ”は、Ｄｅｖｉｃｅ Ｃｏｎｔｒｏｌ Ｍｏｄｕｌｅを表す。ＤＣＭは、ソフトウェア要素であり、ＨＡＶｉネットワーク上の単一装置又は機能を表している。ＤＣＭは、その装置について、ＨＡＶｉ定義されたＡＰＩを見えるようにする。
【００１２】
ＤＣＭは、本来ダイナミックである。装置が挿入又はネットワークから除かれた場合、その装置についてのＤＣＭは、ネットワークにおいて取り付けられ、又は取り除かれる必要がある。ＤＣＭは、新たな装置及び特徴をＨＡＶｉネットワークに収容することにおいて、ＨＡＶｉコンセプト及び柔軟性のソースの中心にある。ＤＤＩは、機器によりユーザインタラクションをサポートする。
【００１３】
本質的なことは、ＵＩプロトコルは、該プロトコルにより伝達される情報又は制御の種を定義せず、ユーザのアクションをどのように包含するか、また、クライアントからサーバに該ユーザのアクションをどのように送出するかを定義するのみである。
【００１４】
さらに、ＵＩプロトコルは、ユーザインタフェース要素（又は、小型機器“Ｗｉｄｇｅｔｓ”と呼ぶ）がどのように記述され、表示目的でどのようにサーバからクライアントに送り返されるかを定義する。これは、コントローラのアプリケーションが制御可能な装置のタイプを知らなくても、ＵＩベースの制御が可能であることを意味している。
【００１５】
コントローラ及び制御可能な装置が、同じＵＩプロトコルを使用して通信し、更にユーザが存在する限り、制御可能な装置を制御することができる。さらに、ＵＩプロトコルにより、装置は標準化装置のタイプの能力を超える機能を与えることができる。言い換えれば、ＵＩプロトコルにより、標準化装置は、競合から該装置自身を区別することができる。
【００１６】
［発明の概要］
ブリッジングがホームネットワーク標準の間で制御するとき、本発明のアプローチは、標準Ａの第１のソフトウェアアーキテクチャにおける装置タイプのプログラマチックインタフェースから、該標準Ａとは異なる標準Ｂの第２のソフトウェアアーキテクチャにおける装置タイプのプログラマチックインタフェースに変換し、逆に、標準Ｂの第２のソフトウェアアーキテクチャにおける装置タイプのプログラマチックインタフェースから、該標準Ｂとは異なる標準Ａの第１のソフトウェアアーキテクチャにおける装置タイプのプログラマチックインタフェースに変換することである。
【００１７】
同様に、本発明のアプローチは、標準Ａにおける装置のタイプのＵＩインタフェースを標準Ｂにおける装置のタイプのＵＩインタフェースに変換し、逆に、標準Ｂにおける装置のタイプのＵＩインタフェースを、標準Ａにおける装置のタイプのＵＩインタフェースに変換することである。本願発明者は、ある問題がこのアプローチに関連しており、打開策を提供するように、ブリッジングを更に詳細に分析している。
【００１８】
図１は、これらのオプション以上のものが存在することを明確にする概念図である。図１の概念図は、標準Ａに準拠したソフトウェアアーキテクチャによるクラスタ１０２と、標準Ｂに準拠したソフトウェアアーキテクチャによるクラスタ１０４とを有するホームネットワーク１００の一部を示している。
【００１９】
ネットワーク１００は、クラスタ１０２におけるネットワーク１００に存在するあるタイプＸのデバイス１０６を有している。クラスタ１０２及び１０４は、デバイス１０６がソフトウェア表現（タイプＸのブリッジされるデバイス）１０８を通してクラスタ１０４から制御することができるように、ブリッジされることになる。
【００２０】
デバイス１０６及びクラスタ１０４におけるその表現１０８が、原理的にＵＩベースの制御インタフェース１１０及び１１２のそれぞれ、及びプログラマチック制御インタフェース１１４及び１１６のそれぞれを有することができるものと仮定する。概念図では、４つのブリッジングのオプション１１８，１２０，１２２及び１２４が挙げられている。
【００２１】
ブリッジ１１８は、ＵＩインタフェース（ＵＩ）１１０からプログラマチックインタフェース（ＰＲＯＧＲ）１１６への変換を提供する。上述したように、ＵＩインタフェースは、プログラマチックインタフェースよりも柔軟である（又は標準化されていない）。
【００２２】
したがって、ＵＩインタフェースからプログラマチックインタフェースへの変換が非常に難しく、ＨＡＶｉ及びＵＰｎＰのような既存のホームネットワーク標準について該変換は不可能である。これには、他の３つのオプションが残される。
【００２３】
ブリッジ１２０は、標準ＡにおけるＵＩインタフェース１１０から標準ＢにおけるＵＩインタフェース１１２に変換するためのものである。この変換が実施可能であるか否かは、標準Ａ及びＢの類似性に依存する。
【００２４】
たとえば、ＵＰｎＰがデバイスＵＩにおけるいずれかの種類のスクリプトをＨＴＭＬに加えることが可能であるために、ＵＰｎＰデバイスのＵＩをＨＡＶｉデバイスのＵＩに変換することは、非常に困難である。ＨＡＶｉは、デバイスＵＩについてＤＤＩプロトコルを使用し、ＨＴＭＬは、ＤＤＩに変換可能であり、スクリプトを加えたＨＴＭＬを変換することが実施不可能である。
【００２５】
ブリッジ１２２は、標準Ａにおけるプログラマチックインタフェース１１４を標準Ｂにおけるプログラマチックインタフェース１１６に変換するためのものである。この変換が可能であるか否かは、標準Ａ及びＢによりカバーされるドメインに大きく依存する。
【００２６】
たとえば、ＵＰｎＰがライトバルブのプログラマチックインタフェースを定義し、ＨＡＶｉがライトバルブの「意味的に等価な」プログラマチックインタフェースを定義しない場合、このデバイスのタイプは、プログラマチックな方法でブリッジすることはできない。
【００２７】
ブリッジ１２４は、標準Ａにおけるプログラマチックインタフェース１１４から標準ＢにおけるＵＩインタフェース１１２に変換するためのものである。このタイプの変換は、標準Ａにおけるデバイスのプログラマチックナインタフェースが、変換を目的とするデータとしてランタイムで利用可能であることを必要としている。これは、「ホワイトボックス」デバイス記述メカニズムを要求し、アプリケーションは、デバイスのインタフェースについて全ての情報をランタイムで回復することができる。
【００２８】
言い換えれば、アプリケーションは、デバイスのタイプのインタフェースについて組込まれた知識に関して信頼する必要がなく、この知識をランタイムで回復することができる。このタイプの変換は、プログラマチックインタフェースで使用されるデータタイプが「形式上互換性のある」ＧＵＩ要素としてマッピングされることをさらに必要としている。
【００２９】
この文脈では、Ｅｕｇｅｎｅ Ｓｈｔｅｙｎにより１９９８／２／１に出願された係属中の米国特許出願シリアル番号０９／１６５，６８２（代理人整理番号ＰＨＡ２３，４８４）“ＣＯＮＴＲＯＬ ＰＲＯＰＥＲＴＹ ＩＳ ＭＡＰＰＥＤ ＯＮＴＯ ＭＯＤＡＬＹ ＣＯＭＰＡＴＩＢＬＥ ＧＵＩ ＥＬＥＭＥＮＴ”を参照されたい。
【００３０】
標準Ａにおけるプログラマチックインタフェースから標準ＢにおけるＵＩへの変換は、形式上互換性のあるＧＵＩ要素のセットが標準ＢのＵＩメカニズムによりサポートされることをさらに必要とする。また、プログラマチックインタフェースの抽象レベルが、ユーザレベルインタラクションについて適していることをさらに必要とする。
【００３１】
上記変換の全ては、ブリッジ実現において共存する場合がある。実際に、ブリッジは、ブリッジの他の側のアプリケーション／ユーザについて、どのインタフェースが最も適しているかを知らないため、できるだけ多くのやり方において他のネットワークにおけるデバイスを表すべきである。
【００３２】
本発明は、標準Ａにおけるプログラマチックインタフェースから標準ＢにおけるＵＩへの変換をブリッジとして使用することができるという洞察に基づいている。以下では、このブリッジングが機能するために含まれる両標準に関して必要条件が議論される。実施の形態は、ＵＰｎＰプログラマチックインタフェースからＨＡＶｉデバイスのＵＩ（ＤＤＩターゲット）への変化スキームの形式で、ブリッジオプションが以下に与えられる。
【００３３】
本発明は、第１の機能の第１のクラスタと第２の機能の第２のクラスタとのブリッジを可能にする方法に関する。第１のクラスタは、プログラマチックインタフェースを通して第１の機能の制御を提供する第１のソフトウェアアーキテクチャを有している。ＵＰｎＰは、かかるアーキテクチャの例である。第２のクラスタは、ＵＩベースのインタフェースを通して第２の機能の制御を提供する第２のソフトウェアアーキテクチャを有している。ＨＡＶｉは、後者のアーキテクチャの例である。本発明における方法は、プログラマチックインタフェースかをＵＩベースのインタフェースに変換することを提供することを備えている。ＵＰｎＰ−ＨＡＶｉの例では、本方法は、ＵＰｎＰデバイス記述ドキュメントから、ＨＡＶｉ ＤＤＩターゲットソフトウェア要素を生成することを備えている。
【００３４】
本発明の方法は、サービスプロバイダにより実現することができる。ユーザは、新たなデバイスが彼／彼女のネットワークに追加されたことをサービスプロバイダに通知し、これに応じて、プロバイダは、ブリッジの一部としてユーザのネットワークにインストールされる変換モジュールを生成することができる。
【００３５】
また、本発明は、異なるソフトウェアアーキテクチャを使用したこれらクラスタを有するホームネットワークに関連している。第１のクラスタは、プログラマチックインタフェースを通して第１の機能の制御を提供する第１のソフトウェアアーキテクチャを有しており、第２のクラスタは、ＵＩベースのインタフェースを通して第２の機能の制御を提供する第２のソフトウェアアーキテクチャを有している。ネットワークは、プログラマチックインタフェースをＵＩベースのインタフェースに変換するために、第１のクラスタと第２のクラスタの間にブリッジを有している。ネットワークは、ＵＰｎＰデバイス記述ドキュメントからのＨＡＶｉ ＤＤＩターゲットを生成するためのジェネレータを備えていることが好ましい。
【００３６】
本発明の１態様は、ホームネットワークでの使用向けのブリッジングソフトウェアにある。ブリッジングネットワークは、第１の機能の第１のクラスタと第２の機能の第２のクラスタを備えている。第１のクラスタは、プログラマチックインタフェースを通して第１の機能の制御を提供する第１のソフトウェアアーキテクチャを有しており、第２のクラスタは、ＵＩベースのインタフェースを通して第２の機能の制御を提供する第２のソフトウェアアーキテクチャを備えている。ブリッジングソフトウェアは、プログラマチックインタフェースをＵＩベースのインタフェースに変換することに基づいて、第１のクラスタと第２のクラスタとを結合するために作用する。ソフトウェアは、ＵＰｎＰ−ＨＡＶｉネットワークにおけるＵＰｎＰデバイス記述ドキュメントからＨＡＶｉ ＤＤＩターゲットを生成するためのジェネレータを備えている。
【００３７】
［発明の実施の形態］
本発明は、添付図面を参照して、例示を通して詳細に説明される。図面を通して、同じ参照符号は、同じ又は対応する機能を示している。
ＵＰｎＰ標準は、「記述ドキュメント“ｄｅｓｃｒｉｐｔｉｏｎ ｄｏｃｕｍｅｎｔ”」と呼ばれるＸＭＬドキュメントを通してデバイスのプログラマチックインタフェースを定義する。アプリケーションは、ＨＴＴＰを通して、ランタイムで、このドキュメントを検索することができ、したがって、ＵＰｎＰは、「ホワイトボックス」基準を満足する。
【００３８】
ＨＡＶｉは、ＩＤＬで表現されるＡＰＩの発生を通して、デバイスのプログラマチックインタフェースを定義する。ＡＰＩの定義は、ＦＣＭタイプと呼ばれるユニークな識別子に結び付けられる。頭字語“ＦＣＭ”は、Ｆｕｎｃｔｉｏｎａｌ Ｃｏｍｐｏｎｅｎｔ Ｍｏｄｕｌｅを表す。ＤＣＭ（上記参照）は、表現されるデバイス内のそれぞれの制御可能な機能についてＦＣＭを含んでいる。
【００３９】
現在、ＨＡＶｉは、チューナ、ＶＣＲ、ＨＤＤベースの記憶装置、ＡＶディスプレイ、カメラ及びモデムのような機能について、ＦＣＭ及び対応するＡＰＩを定義している。ランタイムでは、ＨＡＶｉアプリケーションは、制御可能なデバイスからこのＦＣＭタイプを検索することができ、また、ＦＣＭタイプにリンクされるインタフェースに関する組込まれた情報にプログム的に基づくデバイスを制御することができる。ＨＡＶｉアプリケーションは、ＦＣＭタイプにリンクされるインタフェースを前もって知る必要があるので、ＨＡＶｉは「ホワイトボックス」基準を満足しない。
【００４０】
Ｊｉｎｉでは、アプリケーションは、デバイスのＪａｖａ（Ｒ）オブジェクト表現を参照してリモート（ＲＭＩ）を送り返すルックアップサービスを使用することにより、デバイスのプログラマチックインタフェースを検索する。Ｊａｖａ（Ｒ） ＲＭＩ（Ｒｅｍｏｔｅ Ｍｅｔｈｏｄ Ｉｎｖｏｃａｔｉｏｎ）が使用され、制御されるデバイスに制御コマンドを発生する。Ｊａｖａ（Ｒ）は、「反射」のための機能を有するので、ランタイムで、リモートオブジェクト（デバイス）参照の（Ｊａｖａ（Ｒ）メンバの変数及び方法の観点における）インタフェースを決定することができる。したがって、Ｊａｖａ（Ｒ）は、「ホワイトボックス」基準を満足する。
【００４１】
ＵＰｎＰデバイスのプログラマチックインタフェースは、以下のタイプのいずれかを使用している。ブール代数（Ｂｏｏｌｅａｎ）、整数（ｉ４と呼ばれる）、浮動小数点（ｒ８と呼ばれる）、ストリング、日付時間（データ及び時間情報）又はＨＥＸ符号化バイナリデータ（ｂｉｎ．ｈｅｘ又はｂｉｎ．ｂｉｎ６４と呼ばれる）。
【００４２】
これらのタイプは、簡単なやり方で、ＤＤＩ（ＨＡＶｉで使用される）及びＨＴＭＬ（ＵＰｎＰで使用される）を含めて殆どのＵＩプロトコルに見られる共通のＧＵＩ要素にマッピングすることができる。図２Ａ及び図２Ｂを参照されたい。Ｊｉｎｉは、特定のデバイスのＵＩプロトコルを定義しない。
【００４３】
Ｊｉｎｉデバイスのプログラマチックインタフェースは、いずれかのＪａｖａ（Ｒ）オブジェクトを使用する場合がある。ＨＡＶｉデバイスのプログラマチックインタフェースは、いずれかのＩＤＬタイプを使用する場合がある。したがって、ＨＡＶｉ及びＪｉｎｉデバイスのインタフェースは、一般に、ＵＩに容易にマッピングすることはできない。
【００４４】
勿論、ＩＤＬ又はＪａｖａ（Ｒ）といったリッチデータタイプのサブセットを使用する特定のデバイスタイプについて、ＵＩマッピングが可能であることを想像することができる。たとえば、基本的なＪａｖａ（Ｒ）タイプ（Ｊａｖａ（Ｒ）オブジェクトのない）のみを使用したＪｉｎｉインタフェースについて、ＵＩマッピングは実施可能である。要するに、ＵＰｎＰデバイスのプログラマチックインタフェースからＨＡＶｉにおけるＤＤＩ ＵＩへの広義の変換を定義することは、最も価値のあるように思われる。
【００４５】
［ＵＰｎＰプログラマチックインタフェースをＨＡＶｉ ＤＤＩ ＵＩに変換］　ＵＰｎＰデバイスのプログラマチックインタフェースは、記述ドキュメントに記述されている。このドキュメントは、０台以上の（サブ）デバイスを有するルートデバイスを特定する。それぞれのデバイスは、サブデバイス等の別のリストを有している。いずれかのサブデバイスを有さないデバイス（ツリーにおける「葉」）は、１つのサービスを含んでいる。
【００４６】
サービスは、状態変数（Ｓｔａｔｅ Ｖａｒｉａｂｌｅ、図２参照）のリスト、及びアクション（Ａｃｔｉｏｎ）のリストから構成される。サービスは、サブサービスを有さない。状態変数は、「名前“ｎａｍｅ”」フィールド、「タイプ“ｔｙｐｅ”」フィールド、及びタイプの範囲を制限するオプションフィールドを有している。アクションは、「名前」フィールド及びパラメータのリストを有している。
【００４７】
それぞれのパラメータは、「名前」フィールド、及び「関連状態変数“ｒｅｌａｔｅｄ Ｓｔａｔｅ Ｖａｒｉａｂｌｅ”」と呼ばれるフィールドにより記述される。このフィールドは、状態変数名を言及しなければならず、間接的にアクションパラメータのタイプを定義する。本発明の態様は、ＵＰｎＰデバイス記述ドキュメントからのＨＡＶｉ ＤＤＩターゲットを生成することにある。変換は、ＤＤＩターゲットの動的な態様に加えて、静的な態様の両者に関する。
【００４８】
静的な態様に関して、ＤＤＩ要素（ＤＤＩ ＥＬＥＭＥＮＴ、図２参照）又はｗｉｄｇｅｔｓは、ＵＰｎＰデータタイプ（ＵＰｎＰ ＤＡＴＡ ＴＹＰＥ）について定義される必要がある。ＵＰｎＰサービスに対応する全てのＤＤＩ要素の編成は、定義される必要がある。ＵＰｎＰデバイスに対応する全てのＤＤＩ要素の編成は、定義される必要がある。
【００４９】
動的な態様に関して、デバイスとサービス間のＤＤＩナビゲーションは、定義される必要がある。アプリケーションとデバイス間の「セッション」の開始及び終了が定義される必要がある。制御されるＵＰｎＰデバイスでの非同期の変化の作用は、定義される必要があり、生成されたＤＤＩターゲットに送られるユーザアクションの作用は、定義される必要がある。これらの態様は、以下に詳細に記載される。
【００５０】
［静的：ＵＰｎＰデータタイプをＨＡＶｉ ＤＤＩ要素に変換］
ＵＰｎＰデータタイプは、サービス記述における２つの方法において生じる。言い換えれば、直接的には、状態変数のタイプであり、間接的には、アクションパラメータについて＜関連状態変数＞の参照を通してである。
【００５１】
ＤＤＩ要素には、「インタラクティブ」なものがある。ユーザは、それらＤＤＩと対話することができる。たとえば、ボタンは対話型であり、テキストラベルは対話型ではない。文脈に依存して、対話型のＤＤＩ要素には、「一時的に」非対話型、すなわちディスエーブルとなる場合がある。これを表現するために、対話型のＤＤＩは、「インタラクティビティ」フィールドを有している。
【００５２】
ＵＰｎＰにより、アクションを通してのみ状態変化が可能であるので、アクションパラメータを表しているＤＤＩ要素は、このフィールドをイネーブル（ＥＮＡＢＬＥＤ）に設定する。しかし、デバイスの状態変数の現在の値を表しているＤＤＩ要素は、このフィールドをディスエーブル（ＤＩＳＡＢＬＥＤ）に設定する。
【００５３】
ＵＰｎＰデータタイプには、保持する値の範囲に関して特定の制限を示す追加の指定子（ＡＤＤ．ＳＰＥＣＩＦＩＥＲＳ、図２参照）を有している場合がある。この追加の指定子は、より適切なＤＤＩ要素をあるケースにおいて生成するために使用することができる。
【００５４】
［静的：ＵＰｎＰサービスをＤＤＩ構造に変換］
サービスは、状態変数のリスト、及びアクションのリストから構成される。状態変数は、「名前」フィールド、「タイプ」フィールド、及びタイプの範囲を制限するためのオプションフィールドを有している。アクションは、「名前」フィールド、及びパラメータリストを有している。それぞれのパラメータは、「名前」フィールド及び「関係状態変数」と呼ばれるフィールドにより記述される。このフィールドは、状態変数名を言及しなければならず、アクションパラメータのタイプを間接的に定義する。
【００５５】
ＤＤＩでは、ＤＤＩ表示エンジン（Ｄｄｉコントローラと呼ばれる）へのある種の結合を示唆するために、要素はグループに編成される。この結合は、スクリーン上で要素の編成を決定するために使用されるか、ナビゲーションを決定するために使用される場合がある。
【００５６】
ＵＰｎＰサービスは、以下のＤＤＩ構造に変換することができる。
サービスの＜ｓｅｒｖｉｃｅＴｙｐｅ＞フィールドに設定されるＰａｎｅｌＮａｍｅを有するＤｄｉＰａｎｅｌ要素。ＤｄｉＰａｎｅｌは、２つのＤｄｉＧｒｏｕｐ要素及びＤｄｉＰａｎｅｌＬｉｎｋ要素を含んでいる。「状態変数“Ｓｔａｔｅ Ｖａｒｉａｂｌｅ”」に設定されるｇｒｏｕｐＮａｍｅを有するＤｄｉＧｒｏｕｐ要素。このグループの「要素」フィールドは、上述したタイプマッピングに従う全てのＵＰｎＰの状態変数を変換することから得られたＤＤＩ要素を含んでいるべきである。これらＤｄｉ要素の全ては、ＤＩＳＡＢＬＥＤに設定される対話的な属性を有しているべきである。
「アクション」に設定されるｇｒｏｕｐＮａｍｅを有するＤｄｉＧｒｏｕｐ要素。このグループの「要素」フィールドは、それぞれ個々のＵＰｎＰアクションについて、ＤｄｉＧｒｏｕｐ要素を含んでいる。
【００５７】
これらＤｄｉＧｒｏｕｐ要素のそれぞれは、以下を含んでいる。
「プレスラベル“ｐｒｅｓｓｅｄＬａｂｅｌ”」及び「リリースラベル“ｒｅｌｅａｓｅｄＬａｂｅｌ”」フィールドの両者がアクションの＜名前＞フィールドに設定されるＤｄｉＢｕｔｔｏｎ要素。この要素は、ＵＰｎＰデバイスのアクションを始動することを表す。
アクションパラメータの＜関係状態変数＞に適用されるタイプマッピングに従う、アクションのそれぞれの入力パラメータについてのＤｄｉ要素。これら全てのＤｄｉ要素の全ては、ＤＩＳＡＢＬＥＤに設定される対話的な属性を有するべきである。
アクションパラメータの＜関係状態変数＞に適用されるタイプマッピングに従う、アクションのそれぞれの出力パラメータについてのＤｄｉ要素。これらのＤｄｉ要素の全ては、ＥＮＡＢＬＥＤに設定される対話的な属性を有するべきである。
ＤｄｉＰａｎｅｌＬｉｎｋ要素は、「親“ｐａｒｅｎｔ”」デバイスが、親デバイスの＜ｄｅｖｉｃｅＴｙｐｅ＞又は＜ｆｒｉｅｎｄｌｙＮａｍｅ＞フィールドに設定されるそのＬｉｎｋＮａｍｅフィールドであることを表している。オプション的に、親デバイスの記載における利用可能でありＨＡＶｉ互換性のある＜ｉｃｏｎ＞値のうちの１つに設定されるｌｉｎｋＢｉｔＭａｐフィールドを有することもできる。
【００５８】
［静的：ＵＰｎＰデバイスをＤＤＩ構造に変換］
ＵＰｎＰ使用におけるデバイス記述ドキュメントは、ゼロ以上の（サブ）デバイスを有するルートデバイスを規定している。それぞれのデバイスは、サブデバイスの別のリスト等を有している場合がある。加えて、それぞれのデバイスは、ある種のフィールドを有しており、このフィールドは、デバイスアイコン、製造者名等のような該フィールドに関連している。
【００５９】
（ルート又はサブ）デバイスは、以下のようにＤＤＩ構造に変換される。
デバイスの＜ｄｅｖｉｃｅＴｙｐｅ＞又は＜ｆｒｉｅｎｄｌｙＮａｍｅ＞フィールドに設定されるｐａｎｅｌＮａｍｅを有するＤｄｉＰａｎｅｌ。ＤｄｉＰａｎｅｌは、ＤｄｉＰａｎｅｌＬｉｎｋ要素、ＤｄｉＰａｎｅｌが含むそれぞれのサブデバイス又はサービスのそれぞれについて１つを含んでいる。
サブデバイスを表すＤｄｉＰａｎｅｌＬｉｎｋ要素は、サブデバイスの＜ｄｅｖｉｃｅＴｙｐｅ＞又は＜ｆｒｉｅｎｄｌｙＮａｍｅ＞フィールドに設定されるそのｌｉｎｋＮａｍｅフィールドを有するべきである。オプション的に、デバイス記述における利用可能でＨＡＶｉ互換性がある＜ｉｃｏｎ＞値のうちの１つに設定されるｌｉｎｋＢｉｔＭａｐフィールドを有することもできる。
サービスを表すＤｄｉＰａｎｅｌＬｉｎｋ要素は、サービスの＜ｓｅｒｖｉｃｅＴｙｐｅ＞フィールドに設定されるｌｉｎｋＮａｍｅフィールドを有するべきである。
【００６０】
それぞれの非ルートサブデバイスは、以下を有するべきである。
「親」デバイスを表すＤｄｉＰａｎｅｌＬｉｎｋ要素は、親デバイスの＜ｄｅｖｉｃｅＴｙｐｅ＞又は＜ｆｒｉｅｎｄｌｙＮａｍｅ＞フィールドに設定されるそのｌｉｎｋＮａｍｅフィールドである。オプション的に、デバイス記述における利用可能で互換性のある＜ｉｃｏｎ＞のうちの１つに設定されるｌｉｎｋＢｉｔＭａｐフィールドを有することができる。
全てのＤｄｉＰａｎｅｌＬｉｎｋは、ＥＮＡＢＬＥＤに設定されるインタラクティビティフィールドを有するべきである。オプション的に、パネルは、ＤｄｉＴｅｘｔ要素を含むことができ、インタラクティビティフィールドは、ＤＩＳＡＢＬＥＤに設定され、ｔｅｘｔＣｏｎｔｅｎｔフィールドは、以下のＵＰｎＰデバイス記述フィールドのいずれかについて、ストリング値を保持する。
＜ｄｅｖｉｃｅＴｙｐｅ＞；
＜ｆｒｉｅｎｄｌｙＮａｍｅ＞；
＜ｍｏｄｅｌＤｅｓｃｒｉｐｔｉｏｎ＞；
＜ｍｏｄｅｌＮａｍｅ＞；
＜ｍｏｄｅｌＮｕｍｂｅｒ＞；
＜ｍｏｄｅｌＵＲＬ＞；
＜ｍａｎｕｆａｃｔｕｒｅｒ＞；
＜ｍａｎｕｆａｃｔｕｒｅｒＵＲＬ＞；
＜ｓｅｒｉａｌＮｕｍｂｅｒ＞；
＜ＵＤＮ＞；
最後に、パネルは、デバイス記述における利用可能で互換性のある＜ｉｃｏｎ＞値のうちの１つに設定されるＤｄｉＩｃｏｎ要素を有することができる。
【００６１】
図３には、このように構築されるＤＤＩターゲットからＤＤＩコントローラにより提供される例示のＵＩが示されている。
図３は、ホームネットワーク１００の一部３００を示す図である。ネットワーク１００は、ＴＶ／ＶＣＲコンボ及び２つのサブデバイスであるルートデバイス３０２、ＴＶ３０４及びＶＣＲ３０６を有している。ＴＶ３０４は、オーディオサービス（ＡＵＤＩＯ）３０８、ビデオサービス（ＶＩＤＥＯ）３１０及びチューナサービス（ＴＵＮＥＲ）３１２の３つのサービスを有している。ＶＣＲ３０６もまた、クロックサービス（ＣＬＯＣＫ）３１４、チューナサービス（ＴＵＮＥＲ）３１６及びテープサービス（ＴＡＰＥ）３１８の３つのサービスを有している。
【００６２】
この例では、＜ｆｒｉｅｎｄｌｙＮａｍｅ＞フィールドには“Ｍｙ ＢｅｄＲｏｏｍ Ｆｕｎ”が示されており、＜ｍａｎｕｆａｃｔｕｒｅｒ（製造者）＞フィールドには“ＰＨＩＬＩＰＳ”が示されている。また、＜ｍｏｄｅｌＮａｍｅ（モデル名）＞フィールドには“ＡＺ１０１０”が示されており、＜ｍｏｄｅｌＤｅｓｃｒｉｐｔｉｏｎ（モデル記述）＞フィールドには“１９ ＴＶ／ＶＣＲ ＣＯＭＢＯ”及び＜ｉｃｏｎ＞フィールドにはＴＶの絵が示されている。
【００６３】
テープサービス３１８は、＜ＡｌｌｏｗｅｄＶａｌｕｅＬｉｓｔ＞指定子｛「再生“ｐｌａｙｉｎｇ” 」、「停止 “ｓｔｏｐｐｅｄ”」、「記録“ｒｅｃｏｒｄｉｎｇ”」｝により“Ｔｒａｎｓｐｏｒｔ”と名付けられたストリング状態変数３２０を示している。さらに、「再生“Ｐｌａｙ”」、「停止“Ｓｔｏｐ”」及び「記録“Ｒｅｃ”」の３つのアクション“ＡＣＴＩＯＮＳ”が示されており、“Ｒｅｃ”アクションは、＜ＡｌｌｏｗｅｄＶａｌｕｅＬｉｓｔ＞指定子｛「標準“ｓｔａｎｄａｒｄ”」、「長時間“ｌｏｎｇ”」、「延長“ｅｘｔｅｎｄｅｄ”」｝による状態変数（図示せず）に関連した１つのストリングパラメータを有している。
【００６４】
［動的：デバイスＵＩの操作］
上述したように、それぞれの（ルート又はサブ）デバイス及びそれぞれのサービスは、個別のＤｄｉＰａｎｅｌ要素にマッピングされる。ＤｄｉＰａｎｅｌＬｉｎｋ要素は、０以上の中間サブデバイスを通して、ルートデバイスからサービスに通過するために使用される。
【００６５】
加えて、ルートデバイスレベルを除くそれぞれのレベルに関して、ＤｄｉＰａｎｅｌＬｉｎｋ要素は、デバイス階層において移動するために使用される。ＤＤＩコントローラデバイスのユーザがパネルをクリックしたとき、タイプＡＣＴ＿ＳＥＬＥＣＴＥＤは、ＤＤＩターゲットに送出される。
【００６６】
ＤＤＩターゲットは、（階層の下方向に操作する場合に）サブデバイス／サービス、又は（階層の上方向に操作する場合に）親デバイスを表しているｔａｒｇｅｔＰａｎｅｌを送り返すことにより、タイプＡＣＴ＿ＳＥＬＥＣＴＥＤに応答する筈である。ＤＤＩターゲットは、該ターゲットが表すＵＰｎＰとの通信を必要としない。
【００６７】
［動的：セッションの始動／終了］
図４には、ＤＤＩコントローラと汎用のＤＤＩターゲットの間のセッションが示されている。ステップ４０２でＤＤＩターゲットがＤＤＩ加入を受信した後、ステップ４０４では、ＤＤＩターゲットは、ＵＰｎＰ記述ドキュメントを検索する。記述ドキュメントに基づいて、ステップ４０６では、ＤＤＩターゲットは、該ターゲットが含む全てのＤｄｉＥｌｅｍｅｎｔと同様に、ＤｄｉＰａｎｅｌ構造を構築することができる。
【００６８】
さらに、ステップ４０８では、ＤＤＩターゲットは、ＧＥＮＡメカニズムを使用して、ＵＰｎＰデバイスの状態変化に加入する。“ＧＥＮＡ”は、Ｇｅｎｅｒｉｃ Ｅｖｅｎｔｉｎｇ Ｎｏｔｉｆｉｃａｔｉｏｎ ｗｉｔｈｉｎ ＵＰｎＰ ｃｏｎｔｅｘｔを表している。事象（Ｅｖｅｎｔｉｎｇ）は、ソースデバイスからの事象を受けようとする１つ以上の他のデバイスに対して、任意に接続を始動するためのソースデバイスの能力である。
【００６９】
事象は、複数のデバイスの間での同期を確立するために使用される。ＵＰｎＰ内では、事象は、状態変化の非同期の通知のために主に使用される。ＴＣＰ／ＩＰは、事象情報を伝達するための接続のサポートを提供する。ＧＥＮＡは、関心のあるデバイスと事象メッセージの伝達を可能にするためのアドレス指定スキームとの間の関係を確立するための規約を加える。ＧＥＮＡは、ＨＴＴＰ指定アドレス指定及び暗号化を使用する。ステップ４１０における個別の加入は、それぞれのサービスについて必要とされる。
【００７０】
ＧＥＮＡ ＳＵＢＳＣＲＩＢＥ（ＧＥＮＡ加入）は、全ての状態変数の現在の値を送り返すので、ＤＤＩターゲットは、ＵＰｎＰデバイスと同期され、ＤＤＩコントローラが全てのＤＤＩ要素の正しい値を要求したときに、該正しい値を送り返すことができる。記述ドキュメントが（上記）検索された直後、又はちょうど間に合うようなやり方で、ＤＤＩコントローラが状態変数値を含むパネルを要求した直後に、ＤＤＩターゲットは状態変化に加入する。
ステップ４１２では、ＤＤＩターゲットがＤＤＩ非加入を受けた後、ステップ４１４では、ＤＤＩターゲットは、状態変数の変化からそれ自身を非加入する。
【００７１】
［動的：ＵＰｎＰデバイスでの非同期変化］
ＤＤＩコントローラとＤＤＩターゲットの間でセッションが確立されているとき、他の制御を通して非同期的なやり方でデバイス状態を変化させることが可能である。これは、別のＨＡＶｉ又はＵＰｎＰアプリケーション、或いは物理的なデバイスの手動の制御パネルの物理的なボタンをユーザが押すことである場合がある。このシナリオは、図５に概略的に示されている。
【００７２】
［動的：ＤＤＩコントローラでのユーザアクション］
図６は、ＤＤＩコントローラをランしているデバイスの表示を通して、ユーザがＵＰｎＰデバイスと対話したときに生じるメッセージを示している。動作モードは、ユーザがアクションパラメータに対応するｗｉｄｇｅｔｓをはじめに変更し、ユーザが変更したときに、デバイスのアクションを起動するボタンを押す。
【００７３】
アクションの結果は、出力パラメータを含んでおり、「ディスエーブル」すなわち「非インタラクティブモード」になるｗｉｄｇｅｔｓを使用して示されている。これらは、ＤＤＩターゲットに送出される“ＵｓｅｒＡｃｔｉｏｎ”メッセージとなる。このターゲットは、これらのインタラクションをｗｉｄｇｅｔｓにより表されるパラメータ値をローカルに更新するために使用するよりはむしろ、ＵＰｎＰデバイスに転送する。ユーザが転送したとき、彼／彼女は、デバイスのアクションを表すボタンを押す。
【００７４】
ＤｄｉＢｕｔｔｏｎのリリース“ＲＥＬＥＡＳＥ”事象に関して、ＤＤＩターゲットは、現在のパラメータ値を使用して、ＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）要求を構築し、該要求をＵＰｎＰデバイスに送出する。ＳＯＡＰアクションは、動的に実行され、アクションが首尾よく実行されたときに、ＤＤＩターゲットは、もしあれば、出力パラメータｗｉｄｇｅｔｓについてＤＤＩ“ｃｈａｎｇｅ ｒｅｐｏｔ”を送り返すことにより、ユーザアクションを完了する。
【００７５】
ＳＯＡＰに関して、これは多くの産業パートナーからの寄与により作成されたプロトコルであり、ＳＯＡＰにより、アプリケーションは、たとえば、Ｗｅｂサイトとアプリケーションとを接続してＷｅｂサービスを創作するための骨組みを提供するインターネットを介して、互いに通信することができる。Ｗｅｂサービスは、サイトとアプリケーションとを互いにリンクして、個々の要素のみでは実行不可能な機能を実行する。
【００７６】
典型的に、制御されるデバイスで起動されるアクションは、デバイスの状態も変え、全ての変化した状態変数について新たな値を示すＤＤＩターゲットにＧＥＮＡ ＮＯＴＩＦＩＣＡＴＩＯＮメッセージが送出される。これは、上述したようなＮｏｔｉｆｙＤｄｉＣｈａｎｇｅメッセージを順次生じさせ、最終的に、ＤＤＩコントローラデバイスの表示に関するある視覚的な変化を生じさせる。
【００７７】
図６は、エラーが存在しない状態を示しており、すなわち、ＵＰｎＰデバイスにより最終的に発生されるＳＯＡＰ応答がリターンコードＯＫを有している状態である。エラーの場合では、ＤｄｉＴａｒｇｅｔは、ＤＤＩにおけるＡｌｅｒｔＰａｎｅｌ機能を使用して、ユーザに失敗を示すことができる。“ａｌｅｒｔ ｐａｎｅｌ”は、ＳＯＡＰ応答＜ｆａｕｌｔＳｔｒｉｎｇ＞フィールドを保持するＤｄｉＴｅｘｔ要素を含むことができる。これは、図７に示されている。
【００７８】
米国特許出願シリアル番号０９／１６５，６８２号（代理人整理番号ＰＨＡ２３，４８４）において、Ｅｕｇｅｎｅ Ｓｈｔｅｙｎにより１９９８年２月１０日に出願された“ＣＯＮＴＲＯＬ ＰＲＯＰＥＲＴＹ ＩＳ ＭＡＰＰＥＤ ＯＮＴＯ ＭＯＤＡＬＬＹ ＣＯＭＰＡＴＩＢＬＥ ＧＵＩ ＥＬＥＭＥＮＴ”は、電子デバイス及び該デバイスに結合されたコントローラを備えるホームネットワークシステムに関する。デバイスは、その機能の抽象的表現をコントローラに見えるようにしている。コントローラは、抽象的表現とのインタラクションを通して、デバイスの機能性を制御することを可能にしている。抽象的表現は、機能性の制御の様式を規定している。規定される様式の制御下では、システムは、コントローラの形式上の互換性のある制御能力に機能性の制御を関連付けている。見られる様式は、たとえば、「ブール代数“Ｂｏｏｌｅａｎ”」、「浮動小数点“Ｆｌｏａｔ”」、「整数配列“ｉｎｔｅｇｅｒ ａｒｒａｙ”」とすることができる。
【００７９】
用語“様式”は、機能性の制御の特徴を示す属性を言及する。本発明では、機能性の様式は、デバイスのどの機能が全てかを知る必要なしに、コントローラの形式上互換性のある能力にマッピングされる。たとえば、様式が意味論的にブール代数であるとする。ブール代数的な制御特性は、ブール代数特性を有し、「オン／オフ」スイッチ又は「ハイ／ロウ」レバーのような２つの状態のうちの１つを仮定するＵＩ要素にマッピングすることができる。
【００８０】
ユーザがこの要素と対話するとき、この要素にマッピングされる機能性は、２つの状態のうちの１つを実行する。ＨＡＶｉシステムでは、抽象的な表現が、好ましくはＵＩ（たとえば、音声制御）又はＧＵＩを含んでアップロードされ、ユーザは、文脈を受けてＵＩとの彼／彼女のインタラクションの結果を判定する。
【００８１】
様式が離散値のセットである場合、制御の特性は、デバイスのチャネル選択についてのダイアル、複数のデバイス間の選択についてのダイアルのような３以上の離散状態のうちの１つを仮定することができるＧＵＩ要素にマッピングすることができる。特定の様式が意味的に浮動点値の範囲である場合、たとえば、ディスプレイの画像の輝度又は音量といった連続的な可変制御の特徴に関して、マッピングは実施可能である。
【００８２】
別の例では、規定された様式は、意味的な配列である。配列は、１つ以上のコンポーネントを備えている。たとえば、ブール代数の配列は、ＧＵＩ要素のクラスタにマッピングされ、たとえば、異なるデバイス間のメニュー選択又はチェックボックスリストを実現することができる。
【００８３】
浮動点様式の配列は、たとえば、ホームネットワークを介して制御されるホームセキュリティシステムにおけるカメラ角度及びカメラのズーム要素を調整するためのスライダを表すＧＵＩ要素にマッピングすることができる。なお、コントローラは、制御されているデバイスの機能性についての手がかりを有する必要はない。コントローラが必要とするのは、その様式の意味に基づいて、機能性を制御アプリケーションに従属させることである。
【００８４】
米国特許出願シリアル番号０９／３４０，２７２（代理人整理番号ＰＨＡ２３，６３４）において、Ｅｕｇｅｎｅ Ｓｔｈｅｙｎにより１９９９年６月２５日に出願された“ＢＲＩＤＧＩＮＧ ＭＵＬＴＩＰＬＥ ＨＯＭＥ ＮＥＴＷＯＲＫ ＳＯＦＴＷＡＲＥ ＡＲＣＨＩＴＥＣＴＵＲＥ”は、異なるソフトウェアアーキテクチャのホームネットワークのブリッジングに関する。
第１のネットワークに関して、デバイス及びサービスのソフトウェア表現の参照は自動的に作成される。参照は、第２のネットワークのソフトウェア表現と等価な機能の少なくとも１部分の自動的な作成を可能にするには意味的に十分であり、第１のネットワークのデバイス及びサービスを第２のネットワークからのアクセス可能にする。このドキュメントは、ＨＡＶｉ、ホームＡＰＩ及びＪｉｎｉソフトウェアアーキテクチャのアドレスを指定する。
【００８５】
米国特許出願シリアル番号０９／１６０，４９０（代理人整理番号ＰＨＡ２３，５００）において、Ａｄｒｉａｎ Ｔｕｒｎｅｒにより１９９８年９月２５日に出願された“ＣＵＳＴＯＭＩＺＥＤ ＵＰＧＲＡＤＩＮＧ ＯＦ ＩＮＴＥＲＮＥＴ−ＥＮＡＢＬＥＤ ＤＥＶＩＣＥＳ ＢＡＳＥＤ ＯＮ ＵＳＥＲ−ＰＲＯＦＩＬＥ”は、消費者電子機器ネットワーク可能な装置（ｃｏｎｓｕｍｅｒ ｅｌｅｃｔｒｏｎｉｃｓ ｎｅｔｗｏｒｋ−ｅｎａｂｌｅｄ ｅｑｕｉｐｍｅｎｔ）及びこのタイプの装置のための新たな技術的な特徴のデータベースからなる特定のエンドユーザのユーザプロファイルを保持するサーバシステムに関する。
ユーザプロファイルと新たな技術的機能との間に整合がある場合、ユーザは、更新又は販売提供についての情報を受けることを示し、ユーザは、ネットワークを介して、該機能を得るためのオプションを通知される。
【００８６】
米国特許出願シリアル番号０９／１８９，５３５（ＰＨＡ２３，５２７）において、Ｅｕｇｅｎｅ Ｓｈｔｅｙにより、１９９８年１１月１０日に出願された“ＵＰＧＲＡＤＩＮＧ ＯＦ ＳＹＮＥＲＧＥＴＩＣ ＡＳＰＥＣＴＳ ＯＦ ＨＯＭＥ ＮＥＴＷＯＲＫＳ”は、デバイスの在庫へのアクセス、及びユーザのホームネットワークに関する能力を有するサーバに関する。
在庫とは、たとえば、ＨＡＶｉ又はＪｉｎｉアーキテクチャにより提供されるようなルックアップサービスである。また、サーバは、ネットワークのための機能の情報を有するデータベースへのアクセスを有している。サーバは、ユーザのネットワークに存在する装置の共同作用が在庫のリスト及びユーザのプロファイルに基づいて拡張可能であるかを判定する。共同作用に関連する機能が存在する場合、これら基準に基づいてユーザは通知される。
【００８７】
米国特許第５，９５９，５３６号（代理人整理番号ＰＨＡ２３，１６９）において、Ｐａｕｌ Ｃｈａｍｂｅｒｓ及びＳａｕｒａｂｈ Ｓｒｉｖａｓｔａｖａ等により、１９９８年１１月１０日に出願された“ＴＡＳＫ−ＤＲＩＶＥＮ ＤＩＳＴＲＩＢＵＴＥＤ ＭＵＬＴＩＭＥＤＩＡ ＣＯＮＳＵＭＥＲ ＳＹＳＴＥＭ”は、複数の消費者電子デバイス、及びデバイス間のインタラクションを制御するためのデバイスに接続されるタスク駆動制御手段を備える制御システムに関する。
制御手段は、消費者デバイスのそれぞれ１つのそれぞれのソフトウェア表現に作用する。ソフトウェア表現内のタスクの可変複雑性を暗号化することにより、共通レベルまで能力を向上することが必要とされるように、該可変複雑性を簡易に、又は洗練することができる。インタフェースのレベルは、デバイスに共通であるので、アプリケーションは、非常に異なるレベルの洗練さを具現するデバイスを一様に操作することができる。
【図面の簡単な説明】
【図１】
ブリッジングのためのオプションを例示するブロック図である。
【図２Ａ】
本発明の実施の形態を通して参照されるＵＰｎＰ及びＨＡＶｉ情報項目によるテーブルを例示する図である。
【図２Ｂ】
本発明の実施の形態を通して参照されるＵＰｎＰ及びＨＡＶｉ情報項目によるテーブルを例示する図である。
【図３】
ホームネットワークの一部による図である。
【図４】
ホームネットワークにおけるＵＰｎＰクラスタとＨＡＶｉクラスタの間のインタラクションを例示する図である。
【図５】
ホームネットワークにおけるＵＰｎＰクラスタとＨＡＶｉクラスタの間のインタラクションを例示する図である。
【図６】
ホームネットワークにおけるＵＰｎＰクラスタとＨＡＶｉクラスタの間のインタラクションを例示する図である。
【図７】
【図１】
2004505360.tif 000002
【図４】
2004505360.tif 000003
【図５】
2004505360.tif 000004
【図６】
2004505360.tif 000005
【図７】
2004505360.tif 000006
【国際公開パンフレット】
2004505360.tif 000007
2004505360.tif 000008
2004505360.tif 000009
2004505360.tif 000010
2004505360.tif 000011
2004505360.tif 000012
2004505360.tif 000013
2004505360.tif 000014
2004505360.tif 000015
2004505360.tif 000016
2004505360.tif 000017
2004505360.tif 000018
2004505360.tif 000019
2004505360.tif 000020
2004505360.tif 000021
2004505360.tif 000022
2004505360.tif 000023
2004505360.tif 000024
2004505360.tif 000025
2004505360.tif 000026
2004505360.tif 000027
2004505360.tif 000028
2004505360.tif 000029
2004505360.tif 000030
【国際公開パンフレット（コレクトバージョン）】
2004505360.tif 000031
【国際調査報告】
2004505360.tif 000032
2004505360.tif 000033
2004505360.tif 000034