(57)【特許請求の範囲】
【請求項１】
第１ソフトウェアアーキテクチャの第１ホームネットワークが第２ソフトウェアアーキテクチャの第２ホームネットワークと対話することを可能にする方法であって、
−前記第１ホームネットワークのルックアップサービスにおいて、前記第１ネットワークにおける装置又はサービスの第１ソフトウェアオブジェクトを検出可能にし、
−検出された前記第１ソフトウェアオブジェクトと少なくとも部分的に機能的に同じである第２ソフトウェアオブジェクトを前記第２ネットワークにおいて作成するために必要な情報を有するリファレンスを形成可能にし、及び
−前記第２ネットワークからアクセス可能であるように、形成された前記リファレンスに基づいて前記第２ソフトウェアオブジェクトを前記第２ネットワークにおいて作成可能にする、
ことを有する方法。
【請求項２】
前記第１及び第２ネットワークが異なるソフトウェアアーキテクチャを持つ請求項１に記載の方法。
【請求項３】
−前記第１及び第２ネットワークの一方がＪＩＮＩアーキテクチャに基づき、及び
−前記第１及び第２ネットワークの他方がＨＡＶｉアーキテクチャに基づく、
請求項２に記載の方法。
【請求項４】
−前記第１及び第２ネットワークの一方がＪＩＮＩアーキテクチャに基づき、及び
−前記第１及び第２ネットワークの他方がＵＰｎＰアーキテクチャに基づく、
請求項２に記載の方法。
【請求項５】
−前記第１及び第２ネットワークの一方がＵＰｎＰアーキテクチャに基づき、及び
−他方のネットワークがＨＡＶｉアーキテクチャに基づく、
請求項２に記載の方法。
【請求項６】
−前記第１ネットワークは、当該第１ネットワークに記録された装置及び／又はサービスの一覧を持ち、
−前記検出可能にすることは、前記一覧をクエリーすることを有し、
−前記形成可能にすることは、前記第２ネットワークに関連する前記第１ソフトウェアオブジェクトに関する情報を抽出可能にすることを有し、
−前記作成可能にすることは、抽出された前記情報に基づいて前記第２ソフトウェアオブジェクトを供給することを有する、
請求項１に記載の方法。
【請求項７】
−第１ソフトウェアアーキテクチャの第１ホームネットワーク、及び
−前記第１ソフトウェアアーキテクチャとは異なる第２ソフトウェアアーキテクチャの第２ホームネットワーク、
を有する情報処理システムであって、
−前記第１ネットワークは、前記第１ネットワークにおける第１装置又は第１サービスの第１ソフトウェアオブジェクトを検出可能にするルックアップサービスを持ち、
−前記システムは、前記ルックアップサービスとの対話を介して、前記第１ソフトウェアオブジェクトと少なくとも部分的に機能的に同じである第２ソフトウェアオブジェクトを前記第２ネットワークにおいて作成するために必要な情報を有するリファレンスを作成するリファレンス生成器を持ち、
−前記システムは、前記第２ネットワークからアクセス可能であるように、前記リファレンスに基づいて前記第２ソフトウェアオブジェクトを作成可能にするソフトウェア要素生成器を持つ、
情報処理システム。
【請求項８】
ホーム環境システムに使用するソフトウェアコンポーネントであって、
−前記システムは、第１ソフトウェアアーキテクチャの第１ホームネットワーク、及び前記第１ソフトウェアアーキテクチャとは異なる第２ソフトウェアアーキテクチャの第２ホームネットワークを有し、
−前記第１ネットワークは、前記第１ネットワークにおける第１装置又は第１サービスの第１ソフトウェアオブジェクトを検出可能にするルックアップサービスを持ち、
−前記コンポーネントは、前記ルックアップサービスとの対話を介して、前記第１ソフトウェアオブジェクトと少なくとも部分的に機能的に同じである第２ソフトウェアオブジェクトを前記第２ネットワークにおいて作成するために必要な情報を有するリファレンスを作成するリファレンス生成器を前記第１ネットワーク中に持ち、及び
−前記コンポーネントは前記リファレンスを記憶するコンテナを持つ
ソフトウェアコンポーネント。
【請求項９】
−前記第２ネットワークからアクセス可能であるように、前記リファレンスに基づいて前記第２ソフトウェアオブジェクトを作成可能にするソフトウェア要素生成器を前記第２ネットワーク中に有する請求項８に記載のコンポーネント。
【請求項１０】
ホーム環境システムに使用するソフトウェアコンポーネントであって、
−前記システムは、第１ソフトウェアアーキテクチャの第１ホームネットワーク、及び前記第１ソフトウェアアーキテクチャとは異なる第２ソフトウェアアーキテクチャの第２ホームネットワークを有し、
−前記第１ネットワークは、前記第１ネットワークにおける第１装置又は第１サービスの第１ソフトウェアオブジェクトを検出可能にするルックアップサービスを持ち、
−前記第１ネットワークは、前記第１ソフトウェアオブジェクトと少なくとも部分的に機能的に同じである第２ソフトウェアオブジェクトを前記第２ネットワークにおいて作成するために必要な情報を有するリファレンスを持ち、及び
−前記コンポーネントは、前記第２ネットワークからアクセス可能であり、前記リファレンスに基づいて前記第２ソフトウェアオブジェクトを作成可能にするソフトウェア要素生成器を持つ、
ソフトウェアコンポーネント。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、例えばＨＡＶｉホームネットワーク及びホームＡＰＩベース又はＪＩＮＩベースのホームネットワークのような、おそらく別々のソフトウェアアーキテクチャのネットワークを可能にするシステム及び方法に関する。
【０００２】
【背景技術】
ホームネットワーク及び関連するソフトウェアアーキテクチャ、例えばSun Microsystems, Inc.のＪＩＮＩ(http://www.sun.com/jini)、ＨＡＶｉ(http: //www.havu.org)、ホームＡＰＩ(http://www.homeapi.org) 及びMicrosoftのユニバーサルプラグアンドプレイ（ＵＰｎＰ）(http://upnp.org)がアプリケーション開発者、装置製造者及びサービスプロバイダに利用可能である。
【０００３】
ＨＡＶｉソフトウェアアーキテクチャ
ＨＡＶｉは、オーディオ／ビデオ電子機器及びマルチメディア産業に基準を与えるために、ホームネットワークにおけるディジタル民生電子機器用のＡＰＩ(Application Programing Interfaces)のコアに関係する。ＡＰＩは、オペレーティングシステム又はアプリケーションプログラムに要求するのに必要な方法を指定する。このホームネットワークは、配布されたコンピューティングプラットホームを考慮する。ＨＡＶｉ(Home Audio/Video interoperability) と呼ばれる標準化アーキテクチャの一次目標は、異なる製造業者の製品が共に利用できる、すなわち、アプリケーションタスクを実行するために共働することを保証することである。最新の民生電子機器(CE device)、例えば家庭用娯楽装置（ＤＶＤプレーヤ、ＤＶカムコーダ、ディジタルＴＶセット等）は、ディジタル処理及びディジタル記憶システムである。ネットワークにおいてこれら装置と接続することは、処理及び記憶リソースの共有を可能にする。これは、例えばユーザの対話を簡単にするために、幾つかのＣＥ機器の制御を同時に調整可能である。例えば、第１装置は、第３装置のＥＰＧ(Electric Program Guide)にアクセスする間、第２装置へ記録することを例示としてあげてもよい。このホームネットワークは、ＣＥ装置を接続する構造(fabric)を供給する。接続された装置が制御（ある装置が他の装置に命令を送る）及びＡＶ(Audio/Video)データ（ある装置が他の装置に音声又はビデオストリームを送る）の両方を交換可能にする。ネットワークは、これら全てを達成するために、幾つかの条件を満たさなければならない。高いデータ速度のＡＶストリームの転送を適時にサポートしなければならない。このネットワークは、自己構成、自己管理及び新しいプラグアンドプレイをサポートしなければならない。それは、低コストのケーブル設置及びインタフェースを必要としなければならない。
【０００４】
ＨＡＶｉのソフトウェアアーキテクチャは、プラットホーム独立であり、Ｊａｖａに基づいている。ＨＡＶｉは、ネットワークに接続される装置間の制御及び内容を転送するＩＥＥＥ１３９４の高性能シリアルバスプロトコルを使用する。ＩＥＥＥ１３９４標準は、動的に構成可能な、低コストのディジタルネットワークである。ＩＥＥＥ１３９４は、バックプレーン(backplane)物理層及びポイントトゥポイント(point-to-point)ケーブル接続される仮想バス実装の両方を規定する。バックプレーンのバージョンは、１２．５，２５又は５０Ｍｂｉｔｓ／ｓｅｃで動作する。ケーブルのバージョンは、１００，２００及び４００Ｍｂｉｔｓ／ｓｅｃのデータ速度をサポートする。この標準は、メディア、トポロジー及びプロトコルを指定する。ＩＥＥＥ１３９４転送プロトコルは、それが高いデータ速度性能であるから、オーディオ及びビデオ通信プロトコルをサポートするのに特に利用される。
【０００５】
ＨＡＶｉアーキテクチャは、ＣＥ装置の抽象表現を通してネットワークにおけるこのＣＥ装置を制御する。この抽象表現は、コントローラによって処理され、関連する実際のＣＥ装置の特異性を隠してしまう。これにより、抽象表現は、より高いレベルのソフトウェアに一様のインタフェースを供給する。この抽象表現は、表現される装置の制御プロパティを反映する制御プロパティを記録する。抽象表現は、これらの相互運用性(interoperability)ＡＰＩをアプリケーションに向け、ホームネットワーク上に携帯可能で配布されたアプリケーションを構築するサービスの組を集合的に構成する。
【０００６】
アーキテクチャは、装置がホームネットワークの他の装置に命令又は制御情報を送ることを可能にする。ＨＡＶｉ準拠装置は、ユーザインタフェース（例えばＧＵＩ）及び制御性能に関するデータ（装置制御モデル又はＤＣＭと呼ばれる上記抽象表現、下記も参照）を含む。このデータは、例えば、ネットワーク上の他の装置によりアップロード及び実行可能なＨＡＶｉバイトコード（Ｊａｖａ）を含む。ＨＡＶｉ準拠装置は、このシステムの他の装置と通信するのに十分な機能を最低限有する。対話中に、装置はピアトゥピア(peer-to-peer)方式で制御及びデータを交換する。これは、通信レベルにおいて、装置がこのシステムのマスタ又はコントローラとして働く必要がないことを保証する。他方、論理的マスタ又はコントローラが制御構造を基礎的なピアトゥピア通信モデルに加えることを可能にする。ＨＡＶｉは、以下に説明されるように、コントローラと制御される装置とを識別する。コントローラは、制御される装置に対するホストとして働く装置である。コントローラは、制御される装置に対する抽象表現のホストとなる。制御インタフェースは、抽象表現のＡＰＩを介して向けられる。このＡＰＩは、装置を制御するアプリケーションのためのアクセスポイントである。
【０００７】
ＨＡＶｉ準拠ＣＥ装置は、フルＡＶ装置（ＦＡＶ）、中間ＡＶ装置（ＩＡＶ）及びベースＡＶ装置（ＢＡＶ）に分類される装置である。
【０００８】
ＦＡＶは、ＨＡＶｉソフトウェアアーキテクチャのソフトウェアコンポーネントの完全な組を含む（以下参照）。ＦＡＶは、例えばＨＡＶｉバイトコード用のランタイム環境を有することを特徴とする。これは、ＦＡＶが、例えば、これらの制御に対し高い性能を供給する他の装置からバイトコードをアップロードすることを可能にする。ＦＡＶは、例えば、ＨＡＶｉ準拠セットトップボックス、ＨＡＶｉ準拠ディジタルＴＶ受像機及び家庭用ＰＣによって形成されてもよい。例えば、高機能ＴＶ受像機は、ネットワークに接続された他の装置のＨＡＶｉコントローラとすることが可能である。この受像機は、この装置に対するＧＵＩを作成し、この装置の外部制御を供給する他の装置からアップロードされるバイトコードを得る。この装置を示すアイコンがＴＶスクリーン上に現れるようにして、このアイコンとのユーザの対話が、事前に指定された方法で制御プログラムの要素が表示される装置を駆動させてもよい。
【０００９】
ＩＡＶは、ＨＡＶｉバイトコードに対するランタイム環境を供給しないが、ホームネットワークの指定する装置の制御に対するネイティブサポート(native support)を供給する。ＩＡＶは、この指定する装置の一般的機能を制御するインタフェースを供給する埋め込まれたソフトウェア要素を有する。これらソフトウェア要素は、ＨＡＶｉバイトコードにする必要はなく、他の装置にアクセスするためのネイティブインタフェースを使用するＩＡＶのネイティブアプリケーションとして実施されてもよい。
【００１０】
ＢＡＶは、アップロード可能なＨＡＶｉバイトコードを供給するが、ＨＡＶｉアーキテクチャのソフトウェア要素の何れもホストとして働かない。ＢＡＶは、バイトコードをアップロードした前者によりＦＡＶを介して制御可能となる。一方はＦＡＶ又はＩＡＶと他方はＢＡＶとの間の通信は、ＨＡＶｉバイトコードがＢＡＶにより使用される命令プロトコルへ及びこのプロトコルから変換されることを必要とする。
【００１１】
ＨＡＶｉアーキテクチャのコアな明細書に含まれるメインソフトウェア要素は、以下に列挙されるものである。これら要素の詳細な説明に関しては、ここではリファレンスにより含まれるＨＡＶｉの仕様書を参照されたい。
１）１３９４通信媒体マネージャ（ＣＭＭ）
これは、他のソフトウェア要素とＩＥＥＥ１３９４との間のインタフェースとして働く。
２）イベントマネージャ（ＥＭ）
これは、機器（装置）がネットワークに加えられる又は取り外されるときに起こるネットワーク構成に関する変化のような、ネットワークにおけるイベントを様々なソフトウェア要素に知らせる。
３）レジストリ
これは、ネットワークに接続される機器及びこれら機器が提供する機能に関する情報を保持する。アプリケーションは、レジストリからこの情報を得ることができる。
４）メッセージングシステム（ＭＳ）
これは、ネットワーク上の様々な機器のソフトウェア要素間の通信を容易にするＡＰＩとして役立つ。このメッセージングシステムは、ＨＡＶｉソフトウェア要素に通信施設を提供する。これはネットワーク及びトランスポート層から独立している。メッセージングシステムは、ＦＡＶ及びＩＡＶの何れかに埋め込まれている。このメッセージングシステムは、ＦＡＶ又はＩＡＶでの抽象表現用の識別子を配置することを管理している。これら識別子は、最初にＦＡＶ又はＩＡＶで記録する抽象表現によって使用される。次に、これら識別子は、ホームネットワーク内で互いに識別する抽象表現によって使用される。最初の抽象表現がメッセージを他の抽象表現に送りたいとき、メッセージングＡＰＩをコールしている間は、後者の識別子を使用しなければならない。
５）装置制御モジュール（ＤＣＭ）
これは、ネットワーク上の機器を示す。アプリケーションプログラムは、ＤＣＭと直接対話する。これは、プログラムを各個別の機器の特異性から保護する。
６）ＤＣＭマネージャ
これは、ＤＣＭをインストールする。新規機器に新規ＤＣＭをインストールすることによりネットワークにおける変化に対し自動的に反応する。
７）データ駆動相互作用（ＤＤＩ）
これは、ＨＡＶｉソフトウェア要素に代わって機器の表示上にＧＵＩ(Graphical User Interface)を与える。それは図表示からテキストのみのものまでに及ぶ幅広い範囲の表示をサポートする。ＤＣＭはユーザインタフェース（ＵＩ）を提供してもよい。ＤＣＭは、表示器を持つネットワーク上に１つ以上のＵＩ装置が存在可能である。これを達成する１つの機構は、ＤＤＩ(Data Driven Interaction)と呼ばれる。この機構を用いる場合、ＤＣＭは、そのＵＩのＤＤＩ記述を提供する。この記述は、表示器を具備するどんなＨＡＶｉ準拠装置によっても検索できる。ユーザは、ローカル表示器を介してＵＩと対話可能である。ユーザの対話は、ＤＣＭにより示される物理的装置の制御をする関連するＤＣＭに送られるメッセージとなる。
８）ストリームマネージャ（ＳＭＧＲ）
これは、ネットワーク上にある２つ以上の機器の間において、接続を確立し、リアルタイムＡＶストリームの経路を定める。
【００１２】
ＨＡＶｉアーキテクチャは、レベル１及びレベル２と呼ばれる少なくとも２つの相互運用性のレベルを特定する。
【００１３】
レベル１の相互運用性は、存在する装置が基本レベルの機能で通信を可能にする一般的必要性をアドレス指定する。これを達成するために、レベル１の相互運用性は、ある装置と他の装置との通信を可能にする制御メッセージ（命令）の総称の組及びそれのクラスを与える装置（ＴＶ、ＶＣＲ、ＤＶＤ再生装置等）を適度に期待すべきイベントメッセージの組を規定し、使用する。このアプローチをサポートするために、機構の基本的な組は、装置の発見、通信及びＨＡＶｉメッセージの組を必要とする。
【００１４】
装置の発見については、ホームネットワークにおける各装置が、この装置の能力を他の装置へ知らせることを可能にする定義の明確な方法を必要とする。ＨＡＶｉアプローチは、いわゆるＳＤＤデータ、つまり自己記述データを利用することである。ＳＤＤデータはネットワークにおける全ての装置に必要とされる。ＳＤＤデータは他の装置によってアクセス可能な装置に関する情報を含んでいる。ＳＤＤデータは、いわゆる埋め込まれた装置制御モジュール（埋込ＤＣＭ）の例示を可能にするのに十分な情報を最小限含んでいる。埋込ＤＣＭは、プラットホーム依存コードにおける制御ＩＡＶ又はＦＡＶに事前にインストールされるコードの一部であり、ＩＡＶ又はＦＡＶリソースにアクセスするネイティブインタフェースを使用する。上述されたように、装置用のＤＣＭは、この装置の一般的機能の制御をインタフェースに提供するソフトウェア要素である。埋込ＤＣＭの例示は、レジストリを具備する装置性能の記録となる。このレジストリは、ディレクトリサービスを提供し、ネットワーク上の如何なるオブジェクトがネットワーク上の他のオブジェクトに配置可能にする。記録することは、アプリケーションがネットワーク上の特定装置に送信可能な命令メッセージの基本の組を推論可能にすることである。
【００１５】
通信においては、アプリケーションは、装置の性能を一度決定し、このアプリケーションは、これらの性能にアクセス可能にする必要がある。これは、アプリケーションが装置へリクエストを発することを可能にする一般の通信施設を必要とする。このサービスは、ＨＡＶｉメッセージングシステム及びＤＣＳによって提供される。このアプリケーションは、ＨＡＶｉメッセージをＤＣＭへ送り、次にＤＣＭは、装置と独自の通信に取りかかる。
【００１６】
ＨＡＶｉメッセージの組において、レベル１の相互運用性をサポートするために、定義の明確なメッセージの組が特定な公知のクラス（例えば、ＴＶ受像機のクラス、ＶＣＲのクラス、ＤＶＤプレーヤのクラス等）の全ての装置によってサポートされなければならないことを必要とする。これは、製造者には関係なく、装置が現在の装置及び将来の装置で動作することを保証する。
【００１７】
これら３つの基本的な必要条件は、相互運用性のある最小限のレベルをサポートする。どんな装置もレジストリを介して他の装置の性能をクエリー可能なので、どんな装置も他の装置によってサポートされるメッセージの組を決定することができる。アプリケーションがメッセージングシステムにアクセスするので、どんな装置も他の装置と対話することができる。
【００１８】
レベル１の相互運用性は、装置が基本レベルの機能で相互運用可能なことを保証する。しかしながら、さらに拡張された機構は、ＦＡＶ上の埋込型ＤＣＭには存在しない追加の機能を具備する他の装置と装置とが通信することも可能にする必要がある。例えば、埋込ＤＣＭは、現在の製品の全ての特徴をサポートせず、将来の製品分類の全て新しい製品をサポートするとは考えにくい。レベル２の相互運用性はこの機構を提供する。これを達成するために、ＨＡＶｉアーキテクチャは、上述の埋込ＤＣＭの代わりとしてアップロード可能なＤＣＭを許容する。このアップロードされたＤＣＭは、現在のＤＣＭをＦＡＶ上に置き換える。アップロード可能なＤＣＭは、如何なる適切なソースにより供給されてもよいが、同様な技術は、ＢＡＶ装置のＨＡＶｉＳＤＤデータにおいてアップロード可能なＤＣＭを置き換え、ＢＡＶがホームネットワークに接続されるとき、ＢＡＶからＦＡＶ装置へアップロードすることである。ＨＡＶｉアーキテクチャはベンダーニュートラル(Vender Neutral)であるから、アップロードされたＤＣＭは、潜在的に異なるハードウェアのアーキテクチャを具備するＦＡＶ装置の変化の全てにおいて動作する必要がある。これを達成するために、アップロードされるＤＣＭは、ＨＡＶｉ（Ｊａｖａ）バイトコードで実施される。ＦＡＶ装置上のＨＡＶｉバイトコードのランタイム環境は、アップロードされたＤＣＭの例示及び実行をサポートする。ＦＡＶ装置内で一度作成され、実行すると、ＤＣＭは上述と同じやり方でＢＡＶ装置と通信する。
【００１９】
レベル２の相互運用性の効率は、特定装置の機能へのアクセスを必要とするリソースを考慮するときに明白になる。レベル２は、装置がこの装置により提供される性能の全てを示すアップロードされたＤＣＭを介して制御されることを可能にする一方、レベル１において同様の機能を達成するために、このＤＣＭは、ネットワークのどこかに埋め込まれなければならない。例えば、新規装置がネットワークに加えられるとき、レベル１は、少なくとも１つの他の装置が新規装置と互換性を持つ埋込ＤＣＭを有することを必要とする。比べて、レベル２は、ある装置が新規装置から得られるアップロードされたＤＣＭにランタイム環境を供給することを要求するだけである。
【００２０】
バイトコードをアップローディング及び実行する概念は、装置制御アプリケーションと呼ばれる装置の特定アプリケーションに対する可能性も提供する。これらのアプリケーションを通じて、装置製造業者は、ＨＡＶｉにおける特徴全てを標準化する必要なく、装置の特別な特徴を制御するやり方をユーザに提供可能にする。アプリケーションは、ＨＡＶｉバイトコードにおけるＤＣＭにより供給され、ネットワーク上の各ＦＡＶ装置によってアップロードされ、インストールされる。
【００２１】
更なる情報に関しては、パブリックドメインで利用可能なＨＡＶｉの仕様書及びＩＥＥＥ１３９４の仕様書を参照されたい。ＨＡＶｉのコアの仕様書は、例えば、http://www.sv.philips.com/news/pressのウェブで利用可能であり、ここでは参照することで含まれる。
【００２２】
ホームＡＰＩアーキテクチャ
ホームＡＰＩシステムは、ＰＣ上で実行しているソフトウェアアプリケーションがこのシステムに記録された制御可能な装置を発見及びこれら装置と対話することを可能にするソフトウェアサービス及びアプリケーションプログラミングインタフェースを有する。このホーム環境は、例えば、ＴＶ、ＶＣＲ、セットトップボックス、ホームセキュリティシステム、ライト等の装置に含まれる。ホームＡＰＩは、プロトコル独立であり、基礎をなすネットワーク及びソフトウェアアプリケーションからトランスペアレント(transparent)な装置間の通信プロトコルにおける差異を隠す。アプリケーションが装置にアクセスするやり方は一様であり、装置との通信に使用される基礎をなすプロトコルとは無関係である。
【００２３】
ソフトウェアアプリケーションは、装置を示すために作成されるソフトウェアオブジェクトの特性を調整又は得ることでこれら装置と対話する。アプリケーションは、オブジェクトプロパティの変化を知らせるために、これら変化を含むイベントに申し込むことも可能である。
【００２４】
ホームＡＰＩアーキテクチャは、サービスプロバイダと呼ばれるコンポーネントを有する。これらコンポーネントは、基礎をなす装置及びネットワークの専用となり、ソフトウェアオブジェクトプロパティに関する高いレベルの操作をネットワークにアクセスする関連する装置に送られる命令に変換するのに役立つ。これらサービスプロバイダは、ホームＡＰＩソフトウェアオブジェクトを実施する。サービスプロバイダのコンポーネントは、このサービスプロバイダに関連するオブジェクトに対するプロパティ変化イベントを生成することを担当している。
【００２５】
より詳細には、ホームＡＰＩは、マイクロソフト社のＣＯＭ／ＤＣＯＭ技術(Component Object Model technology)に基づくコンピューティングモデルを使用する。更なる情報に関しては、例えば、ここでは参照によって含まれるマイクロソフト社により供給されるＣＯＭ仕様書ver. 0.9 October 1995を参照されたい。ＣＯＭは、オブジェクト指向である。オブジェクトは、ソフトウェアアプリケーションに向けられるような関連する電子装置の制御機能を表すプロパティを有する。外部からのイベントによるオブジェクトの状態変化は、ソフトウェアアプリケーションに送られる。このアプリケーションは、オブジェクトのプロパティを変化又は調節することでオブジェクトを処理する。アプリケーションは、ある物理的な装置と関連するオブジェクトのプロパティを変更するとき、命令が当該関連する装置に送られる。
【００２６】
ＣＯＭは、アプリケーションが一貫したやり方で通信を可能にする総称機構であり、プログラムコンポーネントオブジェクトを開発し、サポートするフレームワークである。ＣＯＲＢＡ(Common Object Request Broker Architecture)に規定される性能と同様の性能がネットワークにおいて配布されたオブジェクトの相互運用のフレームワークを供給する。ＯＬＥ(Object Linking and Embedding)は、ユーザがその表示器に見る合成ドキュメントにサービスを提供し、ＣＯＭは、（他のオブジェクトに発生したイベントの結果としてあるオブジェクトをサービスに入れる）インタフェースネゴシエーションの基礎をなすサービス及びイベントサービスを提供する。この実行時に、クライアントは制御及びイベントを信号状態変化に向けるためのプロパティを使用するＯＬＥ自動化オブジェクト（抽象表現）としてモデル化される。ＯＬＥ自動化は、サーバへクライアントのスクリプト処理(scripting)及び遅れたバインディング処理(binding)を可能にするＣＯＭ技術である。ＯＬＥ自動化は、プログラムが外部用途に利用可能にする特徴（命令及びクエリー）へのコールを通じて他のプログラムと通信することを提供する。オブジェクトを使用する前に、クライアントのアプリケーションは、始めにオブジェクトインタフェースポインタを得なければならない。このインタフェースポインタは、オブジェクト名をビンディングする又は装置を列挙することでネットワークディレクトリを介して得られる。署名ビンディングする標準のＣＯＭ  ＡＰＩが使用可能である。オブジェクトのリファレンスは、所望のdevice名又はＩＤを指定するストリングでGetObject又はCoGetObjectをコールすることで得られる。アプリケーションは、適切なプロパティにコールするAset propertyを介してそれのプロパティを調節又は検索することでオブジェクトを処理できる。アプリケーションが装置に対応するオブジェクトのプロパティを調節又は変更するとき、プロパティ調節操作又は変更操作は、ネットワークを介し適切な装置に送られる命令に変換される。これらオブジェクトは、実施において異なってもよいが、同様のプロパティベースのモデルをコントローラで実行するクライアントのアプリケーション、例えばWindowsベースのオペレーティングシステムを持つＰＣに向けられる。
【００２７】
ＪＩＮＩアーキテクチャ
ＪＩＮＩは、ネットワーク上の装置を相互接続及び共有することを簡素化する。従来のシステムにおいて、装置をＰＣ又はネットワークに加えることは、インストール及び起動を必要とする。ＪＩＮＩにおいて、装置はそれの存在を宣言し、それの機能に関する情報を提供する。その上、装置はネットワーク上の他のリソースへアクセス可能にする。この技術は、分散型コンピューティングを可能にする、つまり、ネットワークのリソース間に機能を共有する。
【００２８】
ＪＩＮＩは、装置をネットワークに加えるプロセス及びこの装置に関する情報を他の機械に送信するプロセスに焦点をおく。このように、ＪＩＮＩは、他の機械上のアプリケーションが新規に加えられた装置を使用可能にする”ルックアップ”サービスを提供する。ＪＩＮＩのアプローチは、ネットワーク及びオペレーティングシステムが既に構成されているので、各コンピュータは既に他のコンピュータに関し分かっていると仮定する。ＪＩＮＩの機能は、ネットワーク上のレイヤ(layer)で発生する。それは、例えば、接続、切断又は再接続時にネットワークを自動的に構成する問題を解決していない。ネットワークがＪＩＮＩと関係無く、立ち上がっている又はダウンしていると仮定する。ＪＩＮＩは、それのサービスを実行するために、ネットワークによって供給されるサービスを活用する。
【００２９】
特に、ＪＩＮＩネットワークのインフラ(infrastructure)は、Ｊａｖａプログラム言語オブジェクトを実行するリソース、これらオブジェクト間の通信施設及びネットワーク上のサービスを見つけ、活用する能力を供給する。ＪａｖａＲＭＩＴＭ(Remote Method invocation)を用いることで、ＪＩＮＩは、装置の境界を越えたオブジェクト間の通信を提供し、これにより、これらオブジェクトが一緒に動作可能となる。ＲＭＩは、オブジェクトのアクチベーション及びマルチキャストの使用がＪＩＮＩフレームワークにおいて容易に実施すべき高い利用性及び高い信頼性のオブジェクトを供給する複製オブジェクトに接触することを可能にする。ＲＭＩは、従来のリモートプロシージャコール(remote procedure call)機構の拡張部分である。ＲＭＩは、ネットワーク周辺のオブジェクト毎に通過すべきデータだけでなく、コードを含む完全なオブジェクトも許容する。このＪＩＮＩシステムの簡易性の大部分は、オブジェクトとして含まれた形式でコードがネットワーク周辺を移動する能力に基づいている。ＪＩＮＩは、分かっている通信インフラによって接続されるサービスを可能にするルックアップサービスを提供する。ＪＩＮＩは更に、適切なルックアップサービスを発見し、全体のシステムに結合可能なＪＩＮＩ用のDiscovery/Join可能な装置（例えば、ディスク装置、プリンター及びコンピュータ）と呼ばれる機構を提供する。装置がＪＩＮＩベースのシステムを結合するとき、それのサービスはこのルックアップサービスに加えられる。同様に、ＪＩＮＩ可能な装置が、例えば取り外される又は信頼できなくなることで、このシステムから外れるとき、そのサービスはルックアップサービスから消去される。
【００３０】
ホームネットワーク、特にＣＯＭ技術並びにＯＬＥ自動化オブジェクト及びホームＡＰＩを使用するＨＡＶｉ及びＪＩＮＩにおける他の情報に関し、ここでは参照として含まれる以下のドキュメントに参照される。ＨＡＶｉアーキテクチャの一般に利用可能な仕様書（例えばver. 0.86）、コンポーネントオブジェクトモデル仕様書（例えばver. 0.9）、（Ｊａｖａリモートコール仕様書、Ｊａｖａオブジェクトシリアル化仕様書、Javaspace仕様書等を含む）ホームＡＰＩワーキンググループにより提供された１９９９年３月のホームＡＰＩホワイトペーパー、Sun Microsystems, Inc.のＪＩＮＩアーキテクチャの概要である。
【００３１】
特定のＨＡＶｉ、ホームＡＰＩ、ＪＩＮＩ等の各々１つは、ソフトウェアアーキテクチャがそれ自身の利点及び欠点を有する。
【００３２】
例えば、ＪＩＮＩは、あるネットワークプラットホーム環境から局部的に実行する他の環境に転送するＪａｖａオブジェクトを考慮する。マイナス面では、プラットホームの特定機能を常時活用しない。更に、ＪＩＮＩがＪａｖａベースであり、Ｊａｖａがインタプリタ型言語であるから、それは実施不可能であり、ネイティブコードに応じない。
【００３３】
ＨＡＶｉは、広帯域幅のＩＥＥＥ１３９４のオーディオ−ビデオ機器を扱うのに設計される。装置からダウンロード可能なソフトウェアコンポーネント（ＤＤＩ、Ｊａｖａ等）を介して、拡張性及び他の利用可能な機能を提供する。他方では、ＩＥＥＥ１３９４接続又はインタフェースを持たない装置は、ＨＡＶｉアプリケーションにより容易に制御することができない。
【００３４】
ホームＡＰＩはWindows COM/DCOMソフトウェアアーキテクチャ及びサービスを活用するが、例えばＵＮＩＸ、ＬＩＮＵＸ、ＡｐｐｌｅのＭａｃＯＳ等の他のオペレーティングシステムにはまだ広く利用可能とはならない。
【００３５】
例えば、ＰＣ、セットトップボックス、ディジタルＴＶ、ＶＣＲ、Ｘ１０モジュール等のようなコンピュータ又は制御装置は、消費者によって異なる目的のための別々の時間で取得されるので、ホームネットワーク及びアーキテクチャをブリッジングする解法を開発することが重要となる。このようなソフトウェアの解法は、例えばＰＣ、セットトップボックス、ビデオゲーム機器等のような比較的高価なコンピューティングプラットホームに多くは見られる。このコンテキスト内において、１０００ドル又はそれより少ない費用のＰＣは、１９９８から１９９９年にかけてＰＣの小売業者を支配し続け、６００ドルを下回る価格の部門における最大の成長となる。ＰＣ製造業者、Emachines、Packard-Bell及びNECは、１９９９年現在、この市場部門に対し主要な供給元である。例えばEmachinesは、インテルプロセッサ４００ＭＨｚ、３２ＭＢのＲＡＭの速さでＤＶＤドライブのようなハイエンドな特徴を持つ６００ドル以下のＰＣを供給する。同じ傾向がビデオゲーム部門に起こり、セガ及び他社が６４ビットゲームマシンのリリースを予定している。これら新規装置のほとんどは、これらがネットワークの一部となれるように、モデム又は他の接続オプションに付いている。
【００３６】
上述された公知のソフトウェアアーキテクチャの各々は、ほぼ類似のやり方で抽象的観点からネットワークの装置又はサービスを発見することを可能にするサービスを提供する。発見する過程の最終結果として、装置又はサービスのソフトウェア表現は、ルックアップ（レジストリ又はディレクトリ）サービスに配される。ＨＡＶｉアーキテクチャは、レジストリにおける発見された装置又はサービスを記録し、ＪＩＮＩアーキテクチャは、それらをルックアップサービスに記録し、ホームＡＰＩはこのサービスをディレクトリと呼ぶ。その上、記録された装置又はサービスは、ホスト上で実行するソフトウェアアプリケーションで利用可能にする。アプリケーションは、ソフトウェア表現又はオブジェクトを配し、インタフェース及び特有のソフトウェアアーキテクチャの予約手順へのアクセスに従って使用する。
【００３７】
本発明の目的
制御装置が１つ以上のネットワーク環境をホストするときに問題が生じる。例えば、ＩＥＥＥ１３９４接続を具備するＰＣは、ＨＡＶｉ及びホームＡＰＩ環境の一部とすることができる。従って、ホームＡＰＩアプリケーションによってアクセス可能なＨＡＶｉのオーディオ−ビデオ装置及び反対にＨＡＶｉアプリケーションによって制御可能なホームＡＰＩ制御装置等の可能性がある。この可能性が実際に実現された場合、ユーザは、これら２つのホームネットワーク環境を１つと理解し、ユーザの安心が増し、アクセスし易さのオプションが高められる。今まで可能だったよりも広域な範囲の制御装置を持つアプリケーションを作成することをソフトウェア開発者にも可能にする。
【００３８】
更に、このようなハイブリッド機能の魅力は、現在の及びこれから現れるホームネットワーク及びアプリケーションに適応するのに必要である。
【００３９】
従って、本発明の目的は、異なるホームネットワーク環境間にブリッジを可能にする方法、及びこれにより全体としてネットワークの機能を増大可能にする方法を提供することである。
【００４０】
本発明の要約
本発明の方法は、ネットワーク環境にソフトウェアコンポーネント（Reference Factory）を使用する。このコンポーネントは、このネットワーク環境の第１ネットワークにおいて利用可能な装置又はサービスのソフトウェア表現を検出する。これは、ホームＡＰＩディレクトリ、ＨＡＶｉレジストリ、ＪＩＮＩレジストリ又は第１ネットワーク上の機能的に同じであるサービスに関する一覧を列挙及び／又はモニタリングすることを介して行われる。新規ソフトウェア表現をリファレンスファクトリによって検出する時、後者は、第１ネットワーク上に検出されたソフトウェア表現と関連すべきリファレンスを作成する。このようなリファレンスは、前記装置又は前記サービスの少なくとも一部の機能表現を他のネットワークソフトウェア環境内において作成するために必要な情報（例えば、クラスＩＤ、ＵＲＬ、オブジェクト特有識別子、ＸＭＬ又はＤＤＩ記述子等）を有する。
【００４１】
リファレンス情報は、それを他のネットワークに利用可能にする上記ソフトウェア表現（オブジェクト）を作成可能にする他のソフトウェアコンポーネント（オブジェクト  ファクトリ）によりアクセスされる。このオブジェクトファクトリは、必要ならオブジェクトを作成し、そのＵＲＬに与えられたウェブサイトから事前に製造されたオブジェクトを検索し、又はそれと対話するネットワーク環境の規則及び／又は基本設定に沿ってリファレンスを通る。これら基本設定は、例えば一般のアーキテクチャガイドライン又は特定ユーザの興味を反映している。例えば、ある型式の装置（ライト）のみが、ユーザの興味である。他の実施例は、ＤＤＩ表現が容認可能な、ネットワーク構成に基づくＨＡＶｉ環境である。
【００４２】
多重リファレンスファクトリは、特定のネットワークソフトウェアアーキテクチャに存在することも可能である。これらファクトリの各々は、例えば、他のネットワークソフトウェア環境（ＪＩＮＩ、ＨＡＶｉ、ホームＡＰＩ、ＵＰｎＰ）又は上記ネットワーク（ＨＡＶｉ、ＪａｖａＤＣＭ、ＤＤＩデータ又はネイティブＤＣＭ用）の他のオブジェクト表現、又は装置／サービス（データ記憶、ホームオートメーション、Ａ／Ｖ命令セット等）のクラスのようなリファレンスのある型式を担当する。
【００４３】
本発明は、２つのプロセスを切り離す洞察に基づいている。つまり、一方はネットワークソフトウェア構成の分析であり、他方は制御及び／又は対話に必要なソフトウェア表現（オブジェクト）の作成である。オブジェクト作成のファクトリ方法は、従来公知である。Erich Gamma、Ralph Johnson及びJohn Vlissides著、Design Pattern”Elements of Reusable Object-Oriented Software, Addison-Wesley Professional Computing, Addison-Wesley Pub Co, ISBN: 0201633612、特に81-116頁を参照されたい。
【００４４】
特に、本発明は、第１ソフトウェアアーキテクチャの第１ネットワークが第２ソフトウェアアーキテクチャの第２ネットワークと対話することを可能にする方法に関する。この方法は、第１ネットワークの装置又はサービスの第１ソフトウェア表現を検出可能にするステップ、検出された第１ソフトウェア表現に対するリファレンスを形成可能にするステップ、及び作成されたリファレンスに基づき、第２ネットワークからアクセス可能な少なくとも一部は機能的に同じである第２ソフトウェア表現を作成可能にするステップを有する。第１及び第２ネットワークは、例えば両方ともＨＡＶｉに基づくような同一のソフトウェアアーキテクチャを持ってもよく又は第１及び第２ネットワークが、例えば第１及び第２ソフトウェアアーキテクチャの一方がＨＡＶｉアーキテクチャに基づき、他方がホームＡＰＩアーキテクチャに基づいたり、第１及び第２ソフトウェアアーキテクチャの一方がＨＡＶｉアーキテクチャに基づき、他方がＪＩＮＩアーキテクチャに基づく、第１及び第２ソフトウェアアーキテクチャの一方がＨＡＶｉアーキテクチャに基づき、他方がＵＰｎＰアーキテクチャに基づいたり、第１及び第２ソフトウェアアーキテクチャの一方がＪＩＮＩアーキテクチャに基づき、他方がホームＡＰＩアーキテクチャに基づいたり、第１及び第２ソフトウェアアーキテクチャの一方がＪＩＮＩアーキテクチャに基づき、他方がＵＰｎＰアーキテクチャに基づいたり、第１及び第２ソフトウェアアーキテクチャの一方がＵＰｎＰアーキテクチャに基づき、他方がホームＡＰＩアーキテクチャに基づく等の異なるソフトウェアアーキテクチャを持ってもよい。
【００４５】
上述のソフトウェアアーキテクチャの実施例の各々は、適切なネットワークに記録される装置及び／又はサービスの一覧を作成可能にする発見サービスを持つ。本発明の方法は、この一覧をクエリー(query)（問い合わせ）することで利用可能になるものを検出することを可能にするため、このディスカバリサービス及びレジストリ／ディレクトリ／ルックアップ機能を使用する。次に、形成可能とは、それの機能に関連する第１ソフトウェア表現に関する情報を第２ネットワークの見地から抽出可能であることを含み、作成可能とは、抽出された情報に基づく第２ソフトウェア表現を構築することを含む。
【００４６】
以下の特許文献は参照としてここに含まれる。
【００４７】
発明者Yevgeniy Shteyn、１９９８年９月２日出願、米国特許出願シリアル番号第09/146,020号（出願人整理番号PHA23,492）、発明の名称Low Data-Rate Network Represented on High Data-Rate HAVi-Network。この文献は、ホーム自動ネットワークにおける装置を制御する、例えばホームＡＰＩにおける低データ速度転送レイヤ及びＣＯＭベースのソフトウェアコンポーネントを使用するＰＣベースのホーム自動システムに関する。ＨＡＶｉネットワークは、ホーム娯楽システムのオーディオ／ビデオ機器を制御する。ホーム自動サービス及び装置は、ＨＡＶｉ準拠要素としてＨＡＶｉネットワークＦＡＶ又はＩＡＶ制御器に記録される。ホーム自動リソース（装置及びサービス）は、ＨＡＶｉネットワークからホーム自動システムの制御を可能にするために、ＣＯＭ  ＯＬＥ自動インタフェース及びＨＡＶｉ準拠インタフェースの両方を持つ。
【００４８】
発明者Yevgeniy Shteyn及びGregory Gewickey、１９９８年６月３０日出願、米国特許出願シリアル番号第09/107,525号（出願人整理番号PHA23,438）、発明の名称Dynamic De-registering of Devices in System with Multiple Communication Protocols。この文献は、第１及び第２電子サブシステムを有する情報処理システムとこれらサブシステムを制御する制御手段とに関する。少なくとも、第１サブシステムは、制御手段に記録されたソフトウェア表現を持つ。この制御手段は、ソフトウェア表現と対話することで第１サブシステムの状態を変化させる。これら第１及び第２サブシステムは、制御手段を含まず、互いに直接対話することも可能にする。衝突を避けるために、少なくとも第１サブシステムは、制御手段においてソフトウェア表現を機能的に不能にするために制御手段を抹消することができる。
【００４９】
発明者Paul Chambers及びSaurabh Srivastava、１９９６年１０月１５日出願、米国特許出願シリアル番号第08/731,624号（出願人整理番号PHA23,169）、発明の名称Task-Driven Distributed Multimedia Consumer System。この文献は、多数の民生電子装置を備える制御システム及びこれら装置間の対話を制御する装置に結合されたタスク駆動制御手段に関する。この制御手段は、民生装置の個々の装置のそれぞれのソフトウェア表現に働く。ソフトウェア表現内のタスクの変わりやすい複雑さを含むことで、能力を共通レベルまで持ってくるのに必要とされるのと同じくらい簡単又は精巧にすることができる。インタフェースのレベルが装置と共通であるから、アプリケーションは、非常に異なる精巧さのレベルを具体化する装置を一様に操作可能にする。
【００５０】
発明者Paul Chambers及びSteven Curry、１９９８年１２月２９日出願、米国特許出願シリアル番号第09/222,402号（出願人整理番号PHA23,405）、発明の名称Verification of Active Nodes in Open Networks。この文献は、共にリンクされるノードの論理リング又は線形シーケンスとしてネットワークを扱うネットワークポーリングプロトコル(Network Polling Protocol)に関する。ポーリング要求は、アクティブノードの完全な一覧が達成されるまで、１つのノードを一度にネットワークの下又は周辺を伝搬する。プロトコルは、リンクプロトコルにおける破損を治療又は修復し、新規ノードをこのリンクプロトコルに加える手順も含む。このリンクプロトコルは、頂上レベルの階層が不変数のリンクされたネットワークへのアドレスを含み、最底レベルの階層が所与のリンクされたネットワークである階層リンクされるネットワークを確立するのにも使用される。
【００５１】
発明者Lawrence Freeman、１９９８年８月１３日出願、米国特許出願シリアル番号第09/133,622号（出願人整理番号PHA23,488）、発明の名称Home-Network Autoconfiguration。この文献は、個々のＰＣに記録されたリソースを共有するために、ネットワークにおける２つのＰＣを自動設定することに関する。あるＰＣに対しローカルであるサービス及びリソースが、他のＰＣに記録、又はその反対で記録される。このレジストリは、サービス又はリソースがリモート又はローカルであるかを隠してしまう。ネットワークの操作用途において、あるＰＣに対しローカルであるサービス又はリソースは、それがローカルであるかのように、リモートのＰＣからアドレス指定可能である。ＰＣのホームネットワークは、このやり方で自動的に設定される。
【００５２】
発明者Yevgeniy Shteyn、１９９８年１０月２日出願、米国特許出願シリアル番号第09/165,683号（出願人整理番号PHA23,483）、発明の名称Calls Identify Scenario for Control of Software Objects via Property Routes。この文献は、特にしかし排他的ではない、ホームＡＰＩに関し、第１及び第２ソフトウェアオブジェクトにより表される第１及び第２物理コンポーネントを具備する情報処理システムに関する。両方のオブジェクトは、オブジェクトへのコールによって変化可能なプロパティを持つ。このシステムは、第１オブジェクトの第１プロパティを第２オブジェクトの第２プロパティにリンクするプロパティルートを記録可能であるから、第１プロパティにおける変化は、このプロパティルートを呼び出すときに第２オブジェクトに発せられる第２コールを引き起こす。第１オブジェクトへの入力コールは、前記ルートを条件付きで呼び出すことを可能にする識別子を有する。このやり方で、異なるシナリオに属するルートが独立を保つので、本システムはシナリオ識別子を持たないより信頼性のあるシステムを操作する。
【００５３】
発明者Yevgeniy Shteyn、１９９８年１０月２日出願、米国特許出願シリアル番号第09/165,682号（出願人整理番号PHA23,484）、発明の名称Control Property is Mapped onto Modally Compatible GUI Element。この文献は、特にしかし排他的ではない、ホームＡＰＩに関し、装置の機能を制御する電子装置及び制御器を有する情報処理システムに関する。この機能の抽象表現は、制御器に提供される。この抽象表現は、この機能を制御する様式に向けられる。この制御器は、抽象表現との対話を通じて機能を制御可能にする。この様式は、機能の制御を制御器の様式互換可能な制御性能に関連づけることを制御する。向けられる様式は、例えば、Aboolean、Afloat、Ainteger arrayも可能である。
【００５４】
発明者Dorren Cheng、１９９８年１０月２１日出願、米国特許出願シリアル番号第09/716,171号（出願人整理番号PHA23,503）、発明の名称Distributed  Software Controlled Theft Detection。この文献は、フレームワークをプロパティ専用であるセキュリティシステムに供給することに関する。このフレームワークは、個々のプロパティ装置の状態を監視及び評価するセキュリティシステムを制御する分散型ソフトウェアを有する。アラーム及びこのアラームに応じ行われる行動の活性化は、安全なプロパティ装置の状態及び各状態に関連する状態の組合せの規則によって決定される。好ましい実施例において、このシステムのコンポーネント間のメッセージの伝達は、ＨＡＶｉ又ホームＡＰＩ標準に従い、これにより様々な製造業者のコンポーネント間に相互運用性を許容する。
【００５５】
発明者Adrian Turner他、１９９８年９月２５日出願、米国特許出願シリアル番号第09/160,490号（出願人整理番号PHA23,500）、発明の名称Customized Based on User-Profile。この文献は、装置をネットワークに使用可能にする民生電子機器の特定のエンドユーザのユーザープロファイル及び例えばホームネットワークのようなこの種類の装置の新しい技術特性のデータベースを維持するサーバシステムに関する。ユーザプロファイルと新しい技術特性との間に整合があり、ユーザがアップデート又はセールスオファー(sales offer)に関する情報を受け取ったと知らせる場合、ユーザは前記特性を得るために、オプションのネットワークを介して通知される。
【００５６】
発明者Yevgeniy Shteyn、１９９８年１１月１０日出願、米国特許出願シリアル番号第09/189,535号（出願人整理番号PHA23,527）、発明の名称Upgrading of Synergetic Aspects of Home Network。この文献は、ユーザのホームネットワーク上にある装置の一覧及び性能にアクセスしたサーバを備えるシステムに関する。この一覧は、例えば、ＨＡＶｉ、ＪＩＮＩ及びホームＡＰＩアーキテクチャにより供給されるようなルックアップサービスである。サーバは、ネットワークに関する特性の情報を持つデータベースにアクセスもする。サーバは、ユーザネットワーク上に存在する装置の共働が前記一覧のリスト及びユーザのプロファイルに基づいて高められるかどうか決定する。これら基準に基づく共働に関連する特性がある場合、ユーザは通知を受ける。
【００５７】
発明者Yevgeniy Shteyn、１９９８年１１月１０日出願、米国特許出願シリアル番号第09/189,534号（出願人整理番号PHA23,528）、発明の名称Content Supplied as Software Objects for Copyright Protection。この文献は、例えば映像、音声ファイル又はエンドユーザへのテキストメッセージのような内容情報の供給に関する。この内容情報は、ランタイム環境においてエンドユーザがこの内容情報をアクセスする含まれた手順を持つソフトウェアオブジェクトに構成される。このオブジェクトは、このオブジェクトに対する時間フレームと内容情報がアクセスされるべき方法とを明確にすることができる。この手順は、内容データと一緒にオブジェクトに含められ、順番に並べられた後、インターネットを介してオブジェクトの搬送が行われるので、適度の安全性が認証されない実行又はコピーに対し供給される。
【００５８】
出願人Yevgeniy Shteyn、１９９８年１２月１７日出願、米国特許出願シリアル番号第09/213,527号（出願人整理番号PHA23,529）、発明の名称Synchronizing Property Changes to Enable Multiple Control Options。この文献は、特にしかし排他的ではない、ホームＡＰＩに関し、例えばホームネットワークのような情報処理システムを扱う。ネットワーク上のコンポーネントは、このプロパティが機能コール（上述のＣＯＭ参照）を通じて変化可能なソフトウェアオブジェクトにより表される。オブジェクトのプロパティを調節することは、関連するコンポーネントを制御することである。プロパティは、実行するクライアントのアプリケーションを必要とせず、伝搬状態がこのシステムの至る所で変化するルートを介して接続される。２通りのプロパティルートは、無限ループとなる危険が無く、制御されたオブジェクト及び多数の制御オブジェクト間に一貫性を保つのに使用される。これを達成するために、これら２通りのルートは、他のプロパティの状態の変化がルート自体以外の影響によって起こる場合、特定なプロパティの状態の変化を他のプロパティの状態の変化時に実行する。この機構は、多数の制御入力部から自動的にコンポーネントを同期可能にする。
【００５９】
本発明は、上述の発明者Adrian Turner他、１９９８年９月２５日出願、米国特許出願シリアル番号第09/160,490号（出願人整理番号PHA23,500）及び発明者Yevgeniy Eugene Shteyn、１９９８年１１月１０日出願（出願人整理番号PHA23,527）、発明の名称Upgrading of Synergetic Aspects of Home Networkに論じられるようなネットワーク個人別アプリケーションにおいて今までは可能であった制御可能な装置のより広い範囲を持つアプリケーションを作成することをこのソフトウェア製造業者にも可能にする。個人別にするために、サービスも、ここでは参照として含まれる発明者Yevgeniy Eugene Shteyn、１９９９年４月１日出願、発明の名称Time-and Location-Driven Personalized TV、米国特許出願シリアル番号第09/283,545号を参照する。この文献は、加入者が記録するための特定の放送番組と記録された番組を再生するための特定の場所及び時間フレームを選択可能にするサーバシステム及び方法に関する。
【００６０】
【発明の実施の形態】
本発明は、異なるソフトウェアアーキテクチャからなるホームネットワークを互いに結合することを可能にする。これらネットワークの最初のネットワーク上の装置及びサービスのソフトウェア表現へのリファレンスが自動的に作成される。これらリファレンスは、第１ネットワークの装置及びサービスが第２ネットワークからアクセス可能にするために、前記ネットワークの第２ネットワークに対し少なくとも一部は機能的に同じであるソフトウェア表現を自動作成可能することが意味あるように十分に述べられている。
【００６１】
ブロック図の概念
図１は、本発明を説明するためのシステム１００のブロック図である。システム１００は、異なるソフトウェアアーキテクチャを持つ第１及び第２ネットワーク１０２及び１０４を有する。例えばネットワーク１０２がＨＡＶｉベースのアーキテクチャを持ち、ネットワーク１０４がホームＡＰＩベースのアーキテクチャを持つか、又はネットワーク１０２がＪＩＮＩベースのアーキテクチャを持ち、ネットワーク１０４がＨＡＶｉアーキテクチャを持つ等である。
【００６２】
第１ネットワーク１０２は、ネットワーク１０２に記録されたリソース（装置及びサービス）のソフトウェア表現１０８，１１０…１１２をクエリー可能であるサービス１０６を持つ。このクエリーは、表現１０８−１１２の属性を走査する。サービス１０６は、制御及び対話可能なリソースの記録、記録消去及びクエリーを可能にする。リソースを記録することは、表現に対する属性の組及びリファレンスを必要とする。記録消去は、同じリファレンスを供給し、ソフトウェアアプリケーション又は他のソフトウェアオブジェクトによってこのリファレンスにアクセス不可能にすることを必要とする。クエリーは、記録されたエントリーと整合する属性の完全な又は部分的な組を供給することを含む。同様に、ネットワーク１０４は、それに記録されたソフトウェア表現１１６，１１８，１２０を持つリソースを発見及び制御することが可能なサービス１１４を持つ。
【００６３】
システム１００は、ネットワーク１０２及び１０４をブリッジし、ネットワーク１０４に記録された１つ以上のリソースに関する制御をネットワーク１０２に供給するのに役立つ手段１２２を持つ。
【００６４】
手段１２２は、リファレンスファクトリと呼ばれるソフトウェアモジュール（オブジェクト又はアプリケーション）１２４を有する。このリファレンスファクトリ１２４は、ネットワーク１０４にインストールされ、サービス１１４を介しソフトウェア表現１１６−１２０の何れかにアクセスする。リファレンスファクトリ１２４は、ネットワーク１０４のソフトウェアアーキテクチャの方法に従い、サービス１１４の一覧をクエリーする又は新規ソフトウェア表現を通知することが可能である。この意味において、ファクトリ１２４はネットワーク１０４に特有なものである。リファレンスファクトリ１２４が興味のあるオブジェクト、例えばソフトウェア表現１１６だと分かったとき、ファクトリ１２４は表現１１６へのリファレンス又はリファレンスの組を作成する。
【００６５】
手段１２２は、リファレンスをネットワーク１０４の全てのクライアントに利用可能とするために、ファクトリ１２２により作成される前記リファレンスの集積所に対するソフトウェア表現である共同コンテナ１２６を更に持つ。
【００６６】
手段１２２は更に、ネットーワーク１０２にインストールされるソフトウェア要素ファクトリ１２８も持つ。ファクトリ１２８は、コンテナ１２６からリファレンスを選択し、選択されたリファレンスに収容される情報に基づき、例えばネットワーク１０２のソフトウェアアーキテクチャにより規定される規則に従ってサービス１０６を置くか記録することでネットワーク１０２にインストールするのに適する、事前に作成されたソフトウェア表現を作成又は検索する。サービス１０６に記録するとき、ネットワーク１０４のリソースは、ネットワーク１０２からアクセス及び制御可能となる。
【００６７】
ファクトリ１２４は、サービス１１４にアクセスし、リファレンスを作成する情報を抽出するために、ネットワーク１０４のソフトウェアアーキテクチャの規則を使用できる。ファクトリ１２８は、集積所１２６におけるリファレンスに基づく新規に作成されるソフトウェア表現を記録するサービス１０６にアクセスするために、ネットワーク１０２のソフトウェアアーキテクチャの規則を使用することができる。ファクトリ１２４及びファクトリ１２８は、集積所１２６を介してインタフェースされる。集積所１２６は、これにより、ファクトリ１２８により作成されるリファレンスの情報内容をファクトリ１２８に伝達可能にすべきである。これを達成するための可能な機構は、ファクトリ１２４及び１２８が同じ言語、例えばＸＭＬに基づく集積所１２６へインタフェースを向けさせることである。つまり、ファクトリ１２４によって出力として供給されるリファレンスは、ファクトリ１２８への入力として直に使用可能である。他の機構は、ファクトリ１２６がファクトリ１２４から入力された情報を転換プロトコルを使用するファクトリ１２８への適切にフォーマットされた出力に変換又は転換可能にすることである。このコンテキスト内において、マッピングプロトコルの総称種類を説明する上述の米国特許出願シリアル番号第09/165,682号（出願人整理番号PHA23,484）を参照する。代わりに、一方は集積所１２６と他方はネットワーク１０２及び１０４との間に特定の変換段階が挿入される。
【００６８】
準用して、ネットワーク１０２上のリソースをネットワーク１０４から制御可能にさせるため、リファレンスファクトリ１３２，コンテナ１３４及びソフトウェア要素ファクトリ１３６を有する同様の手段１３０が加えられてもよい。
【００６９】
多数のリファレンスファクトリは、例えば、ネットワーク１０２からの制御と同様に、ネットワーク１０４に記録される１つ以上の機能を制御することを更に他のソフトウェアアーキテクチャの第３ネットワーク（図示せず）が可能となるように、特定のリファレンス情報を供給する他のリファレンスファクトリ１３６をネットワーク１０４にインストールしてもよい。これら多数のリファレンスファクトリの各々は、例えば、他のソフトウェア環境（ＨＡＶｉ、ＪＩＮＩ、ホームＡＰＩ）又は上記ネットワーク（ＦＡＶ用Ｊａｖａ、ＧＵＩ用ＤＤＩ、ＩＡＶ用ネイティブＤＣＭ）内にある他のオブジェクト表示のような一定の型式のリファレンス、又は例えばデータ記憶装置、ホームオートメーション、Ａ／Ｖコマンドセット等のリソース（装置／サービス）の種類を担当する。
【００７０】
集積所１２６は、第４ネットワークに対する他のソフトウェア要素ファクトリ１３８にアクセス可能であり、この他のファクトリはこの集積所１２６のリファレンスを直接又は間接的に扱うことができる。
【００７１】
ＨＡＶｉホームＡＰＩを構成するハードウェアのブロック図
図２は、ＨＡＶｉベースのネットワーク２０２とホームＡＰＩに基づくネットワーク２０４とを有する統合ホームネットワークシステム２００の物理的構造を説明する。
【００７２】
ネットワーク２０２は、ＦＡＶ機能を具備するＨＡＶｉセットトップボックス２０６と、ＢＡＶとして役立つＨＡＶｉ準拠ＴＶ２０８（上述のＨＡＶｉ参照）と、ＢＡＶとしても役立つＨＡＶｉ準拠Ｄ−ＶＣＲ２１０とを有する。装置２０６，２０８及び２１０は、セットトップボックス２０６がＴＶ２０８及びＤ−ＶＣＲ２１０を制御可能なようにＩＥＥＥ１３９４バスを介して相互接続される。
【００７３】
ネットワーク２０４は、Ｘ−１０接続を介してライト２１４、ＩＲ接続を介して芝生のスプリンクラー２１６及び関連する接続を介して他の機器（図示せず）を制御するように構成される。
【００７４】
セットトップボックス２０６及びＰＣ２１２は、ＩＥＥＥ１３９４バスを介して相互接続されている。ＩＥＥＥ１３９４接続は、ＰＣ２１２がＩＥＥＥ１３９４準拠装置にアクセスすることを可能にする。この機能を利用するために、ＨＡＶｉ用のホームＡＰＩサービスプロバイダ２１８（下記のABackground Art又は、特にホームＡＰＩを参照）がＰＣ２０４にインストールされている。ＨＡＶｉ専用のサービスプロバイダ２１８は、ＰＣベースのＨＡＶｉ−ＦＡＶアプリケーション又はＰＣベースのＨＡＶｉ−ＩＡＶアプリケーション環境にアクセスすることができる。どちらも利用できない場合、ＦＡＶ又はＩＡＶ環境自身を実行又はインストールしてもよい。サービスプロバイダ２１８は、ＨＡＶｉ装置、例えば装置２０６−２１０を示すＣＯＭオブジェクトを具備するホームＡＰＩディレクトリの中に場所を占める。これはＰＣ２１２上のホームＡＰＩアプリケーションがＨＡＶｉ装置２０６−２１０を制御することを可能にする。
【００７５】
しかしながら、この構成は、ＦＡＶ２０６上のＨＡＶｉベースのアプリケーションが、例えば、ライト２１４、芝生のスプリンクラー２１６用のオブジェクト及びディレクトリ２２０に記録される他の装置に対するオブジェクトのようなホームＡＰＩソフトウェアオブジェクトにアクセスすることを可能にしない。ＨＡＶｉネットワーク２０２からの制御を達成するために、ＨＡＶｉ準拠ソフトウェア要素（例えばＤＣＭ、ＦＣＭ）の組は、ＨＡＶｉ記録２２２にインストールされる必要がある。本発明は、図１を参照し述べられたようなこのインストールを可能にするために、リファレンスファクトリ及びソフトウェア要素ファクトリの概念を導入することを目的とする。この制御機能は、ユーザが彼又は彼女のセットトップボックス２０６を介してライト２１４をターンオン／オフしたり、興味のある映画等を鑑賞している間の雑音を避けるためにスプリンクラー２１６を停止又は予定変更することを可能にする。
【００７６】
ＨＡＶｉホームＡＰＩを構成するソフトウェアを作成するブロック図
図３は、ＨＡＶｉ−ホームＡＰＩブリッジのソフトウェア構成３００を説明する第１ブロック図である。構成３００は、ホームＡＰＩ制御環境３０４及びＨＡＶｉ  ＩＡＶ／ＦＡＶソフトウェア実行３０６を具備するＰＣ３０２を有する。構成３００は、ＨＡＶｉネットワーク３０８及びホームＡＰＩネットワーク３１０も有する。ホームＡＰＩ環境３０４と対話するＨＡＶｉ専用ソフトウェア要素がネットワーク３１０の装置又はサービスを可能にして、これらは、ＨＡＶｉネットワーク３０８から制御すべきホームＡＰＩ環境３０４に記録されている。
【００７７】
上述されるように、本発明は、異なるホームネットワーキング環境間、ここではＨＡＶｉネットワーク３０８とホームＡＰＩネットワーク３１０との間にブリッジを可能にする方法を提供する。このために、ホームＡＰＩ環境３０４は、アプリケーション又はソフトウェアオブジェクトであり、リファレンスファクトリと呼ばれるソフトウェアコンポーネント３１２を有し、これはホームＡＰＩ環境３４０において利用可能な装置及びサービスのソフトウェア表示、例えばオブジェクト３１４を検出する。この検出は、ホームＡＰＩディレクトリ３１６の列挙(enumeration)及び／又はモニタリング若しくはホームＡＰＩルート又は他のコンテナへのアクセスを介して行われる。リファレンスファクトリ３１２の機能及び／又はユーザの選択に基づいて、検出される装置又はサービスのソフトウェア表現と関連するリファレンス又はリファレンスの組が作成される。上記リファレンスは、ソフトウェア表現に関する情報、例えばオブジェクト型式、プロパティ記述子、クラスＩＤ、ＵＲＬ、オブジェクト特有の識別子、ＸＭＬタグ、ＤＤＩ記述子等を有し、これは同じ装置又はサービスと同等のソフトウェア表現の作成に必要だが、他のネットワーク、ここではＨＡＶｉ環境３０４及びネットワーク３１０内で使用する必要がある。ファクトリ３１２は、環境３０４に加えられるソフトウェアオブジェクトを検出するために、ホームＡＰＩ通知型、例えばイベントサブスクリプション(Event Subscription)又はプロパティルート(Property Route)を使用する。ソフトウェアオブジェクトがホームＡＰＩ環境３０４に加えられるとき、リファレンスファクトリ３１２が通知され、必要なら、リファレンスが作成され、加えられたオブジェクトに関連するリファレンスコンテナ３１８に配される。
【００７８】
この実施例において、コンテナ３１８は、前記リファレンスを全てのホームＡＰＩクライアントに利用可能にさせる。例えば、リファレンスファクトリ３１２は、ホームＡＰＩディレクトリ３１６を介して、例えばユーザにより指定されるような、興味のあるオブジェクトにアクセスする。例えば、ユーザは、彼／彼女がオブジェクトAlight２１４に興味があると指定する。ユーザの選択は、設定アプリケーション／ガイドによって得ることができる。このアプリケーション又はガイドは、例えば、ネットワーク環境において利用可能な全ての利用可能な装置又は装置の型式をリストにする。これらの内の装置が他のネットワークを介してアクセス可能であることに関するユーザ入力を収集する。リファレンスファクトリ３１２は、ディレクトリ３１０において興味のあるソフトウェアオブジェクトを特定し、ＨＡＶｉソフトウェア要素、例えば、それに制限しないが、ＤＤＩデータ、ＪａｖａＤＣＭリファレンス又はネイティブ（バイナリ）ＤＣＭを有するリファレンスの組を作成する。これらリファレンスは、Alights２１４に対するリファレンスコンテナ３１８に配される。リファレンスファクトリ３１２がインストールされた後、例えばホームＡＰＩイベント機構を介してホームＡＰＩルートに加入される。このインストーラは、リビングルームのライトのみを制御可能とするために、例えばALiving RoomのようなホームＡＰＩディレクトリ３１６の特定のコンテナ又は一部にファクトリ３１２を加入する。新規のライトオブジェクトがネットワーク３１０に加えられるとき、ファクトリ３１２は、新規のリファレンス、例えば、新規のライトを示すＪａｖａパッケージに対するＤＤＩ記述子及びＵＲＬを作成する。これらリファレンスは、この新規のライトのコンテナ３１８に加えられる。
【００７９】
ＨＡＶｉソフトウェア要素ファクトリ３２０は、興味のあるホームＡＰＩオブジェクトにアクセスすることを担当するソフトウェアコンポーネントである。この実施例において、オブジェクトALightsに対するコンテナ３１８から適切なリファレンスを選択する。ファクトリ３２０は、内部又は外部（例えばインターネット）リソースを使用し、検索されるリファレンスに基づくＨＡＶｉソフトウェア要素を作成する。例えば、上述の米国特許出願シリアル番号第09/160,490号（出願人整理番号PHA23,500）及び米国特許出願シリアル番号第09/189,535号（出願人整理番号PHA23,527）において述べられたインフラ(infrastructure)を参照されたい。ＰＣ３０２は、このＰＣ３０２上に実装するＨＡＶｉ  ＩＡＶ／ＦＡＶの一部としてＤＣＭマネージャ３２２及びレジストリ３２４を持つ。ファクトリ３２０は、ＨＡＶｉアーキテクチャ規則及び／又は要素ファクト選択に従い、ＨＡＶｉ  ＤＣＭマネージャ３２２及びＨＡＶｉレジストリ３２４と対話する。例えば、ファクトリ３２０は、ホームＡＰＩオブジェクトALightsの機能をＨＡＶｉネットワーク３０８がホストとなる表示器及びＨＡＶｉアプリケーションを介しアクセス可能させるために、ＤＤＩデータを作成する。代わり又は補助的に、ファクトリ３２０は、（ＵＲＬを介し）インターネットからＪａｖａＤＣＭを作成又は検索し、ＨＡＶｉアプリケーション又は他のＤＣＭにALights２１４のソフトウェア表現と対話することを可能にするようにレジストリ３２４にそれを記録する。
【００８０】
リファレンスファクトリ３０２のインストールに関し、これはネットワークへ装置をインストールする間に、例えば装置の製造業者により可能となる。例えば、フィリップスのライトは、ＨＡＶｉへのアクセスを可能にするリファレンスファクトリソフトウェアオブジェクト３０２を有するＰＣソフトウェアとパッケージされる。このインストールは、サービスプロバイダ、ユーザ自身又は第三者によって、ＰＣソフトウェア機能のアップグレードの一部として処理される。
【００８１】
ソフトウェア要素ファクトリ３２０のインストールに関し、これは、現在の要素ファクトリをアップグレードするために、ユーザ自身又はサービスプロバイダをＨＡＶｉサービスプロバイダ又は第三者によってインストールされてもよい。
【００８２】
図４は、ＨＡＶｉホームＡＰＩブリッジのソフトウェア構造４００を説明する第２ブロック図である。構成４００は、ホームＡＰＩ制御環境３０４を具備するＰＣ３０２及びホームＡＰＩネットワーク３１０を有する。構造４００は、ＨＡＶｉ  ＦＡＶ４０２を含むＨＡＶｉネットワーク３０８も有する。ここでＰＣ３０２は、ＨＡＶｉネットワーク３０８にホームＡＰＩ制御環境３０４を示すソフトウェアモジュール４０４を持つ。モジュール４０４は、ソフトウェア要素ファクトリ３２０を有するＨＡＶｉ  ＢＡＶであり、これは、ＨＡＶｉネットワーク３０８にＤＣＭ４０６（又はＦＣＭ）としてホームＡＰＩオブジェクト３１４を示すために、他のＢＡＶソフトウェアコンポーネントと対話する。ＨＡＶｉ  ＦＡＶ又はＩＡＶ装置上のＤＣＭマネージャ（図示せず）は、ＤＣＭ４０６を介し、ネットワーク３０８上でホームＡＰＩオブジェクト３１４を利用可能にするためにＢＡＶソフトウェア４０４と対話する。
【００８３】
この構成に関し、上記にリストにされた米国特許出願シリアル番号第09/146,020号（出願人整理番号PHA23,492）も参照されたい。
【００８４】
インストールしたソフトウェア要素のコンテキスト内において、上述した発明者Adrian Turner他、発明の名称Customized Upgrading of Internet-Enabled Device Based in User-Profileの１９９８年９月２５日出願の米国特許出願シリアル番号第09/160,490（出願人整理番号PHA23,500）及び上述した発明者Yevgeniy Eugene Shteyn、発明の名称Upgradeing of Synergetic Aspects of Home Networksの１９９８年１１月１０日出願の米国特許出願シリアル番号第09/189,535号（出願人整理番号PHA23,527）を参照されたい。
【００８５】
他の実施例のように、ＨＡＶｉ−ＵＰｎＰブリッジは、ＨＡＶｉソフトウェア要素をＵＰｎＰネットワークに向ける、又はその反対で構築される。ＸＭＬは、ＵＰｎＰにおける装置の表現に関する基礎である。ＵＰｎＰネットワークに参加させるために、ＨＡＶｉソフトウェア要素は、これら要素に関連するＸＭＬ表現を持つ必要がある。上記表現は、”実行中”(on the fly)、即ち接続／列挙要求毎、又は好ましくは一度作成され、ソフトウェア要素の属性又は特定のソフトウェア要素ＩＤにより最初のものと関連する分離したソフトウェア要素としてレジストリに配される。特有のＨＡＶｉソフトウェア要素のＸＭＬへの直接変換が機能的に不可能である（例えば、ソフトウェア要素が第三者のＪａｖａオブジェクト等により示される）場合、汎用のＸＭＬ表現が作成可能である。このソフトウェア要素（ＤＣＭ、ＦＣＭ）の製造業者は、ＵＰｎＰネットワークに参加する場合、コンポーネントの好ましいＸＭＬ表現を提供する。同様に、ＨＡＶｉ  ＤＤＩインタフェースは、発表されたＤＤＩユーザインタフェース要素（例えば、詳細するＨＡＶｉ仕様書の第４節参照）に基づいて、ＸＭＬに変換される。このＪａｖａ反射機構は、特定のＪａｖａオブジェクトのインタフェースをクエリーするのに使用され、同等のＸＭＬモデルは、このインタフェースが公知だと分かった場合に作成可能である。
【図面の簡単な説明】
【図１】  図１は、本発明を説明するシステムのブロックである。
【図２】  図２は、ＨＡＶｉ／ホームＡＰＩハードウェア構成のブロックである。
【図３】  図３は、ＨＡＶｉ−ホームＡＰＩシステムに対するソフトウェア構成を説明するブロックである。
【図４】  図４は、ＨＡＶｉ−ホームＡＰＩシステムに対するソフトウェア構成を説明するブロックである。
【符号の説明】
１００  システム
１０２  第１ネットワーク
１０４  第２ネットワーク
１０６、１０４  サービス
１０８、１１０、１１２、１１６、１１８、１２０  ソフトウェア表現
１２２、１３０  手段
１２４  リファレンスファクトリ
１２６  共同コンテナ
１２８、１３６  ソフトウェア要素ファクトリ
１３２  リファレンスシステム
１３４  コンテナ
【図１】
0004721600.tif 000002
【図２】
0004721600.tif 000003
【図３】
0004721600.tif 000004
【図４】
0004721600.tif 000005