(57)【要約】非ＩＰ（インターネットプロトコル―Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ―）ネットワークが、ＵＰｎＰ（ユニバーサルプラグおよびプレイ―Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ―）プロクシ活性化および接続化論理に提供されている。ＵＰｎＰ活性化論理は、１つまたはそれ以上の非ＩＰネットワークにおける複数デバイスのそれぞれのためのＵＰｎＰアドレッシング、発見および記述プロセスを結果として生じさせることを要求されたモジュールを提供している。非ＩＰネットワークのそれぞれは、例えば、ＵＳＢ、ブルートゥース（Ｂｌｕｅｔｏｏｔｈ）、ＩＥＥＥ１３９４、ホームＡＰＩ、ホームＲＦ、ファイアフライ（Ｆｉｒｅｆｌｙ ―ホタル―）、Ｘ−１０などの同一のまたは異なるネットワーク技術を用いても良い。ＵＰｎＰ制御およびイベント位相（ｐｈａｓｅｓ）の間に、このシステムは、ＵＰｎＰ制御オブジェクトから受信されたＵＰｎＰ制御コマンドに応答して、ネットワーク内の非ＵＰｎＰ互換性デバイスのそれぞれに対してコマンドを通信するため、および、非ＵＰｎＰ互換性デバイスとＵＰｎＰ制御オブジェクトとの間でのイベント状態メッセージを通信するための、適切な制御の送信とイベント・プロクシー・プロセスとを提供する。
2004516711.tif 000002
【特許請求の範囲】
【請求項１】
１またはそれ以上の異なるネットワーク技術を含む１またはそれ以上のスレーブネットワークにおける少なくとも１つの非ＵＰｎＰデバイスのＵＰｎＰ制御を容易にするためのシステムであって、
−ＵＰｎＰプロトコルに従ってＵＰｎＰコマンドを出力するように構成された少なくとも１つのＵＰｎＰコントローラ用のＵＰｎＰインターフェースと、
−前記ＵＰｎＰコマンドを受信し、
前記ＵＰｎＰコマンドをデバイスコマンドに変換し、
前記デバイスコマンドを、前記スレーブネットワークにおける少なくとも１つの非ＵＰｎＰデバイスのターゲット（目標）デバイスに通信し、
前記ＵＰｎＰインターフェースを介して、前記少なくとも１つのＵＰｎＰコントローラに対して、前記ＵＰｎＰコマンドのＵＰｎＰアクノリッジメントを通信するように構成されたＵＰｎＰプロクシーイネーブラ（代理権付与部）と、
を備えるシステム。
【請求項２】
前記１つまたはそれ以上の異なるネットワーク技術は、ＵＳＢネットワーク、ブルートゥースネットワーク、ＨＡＶｉコンパーチブルネットワーク、ＩＥＥＥ１３９４ネットワーク、ホームＡＰＩネットワーク、ホームＲＦネットワーク、ファイアフライ（ホタル）ネットワーク、電力線（ｐｏｗｅｒ ｌｉｎｅ）ネットワーク、Ｘ−１０ネットワーク、Ｊｉｎｉ（ジニ）コンパーチブル（互換性）ネットワークのうちの少なくとも１つである請求項１に記載のシステム。
【請求項３】
−前記ＵＰｎＰコントローラはさらに、前記ＵＰｎＰプロトコルに従ってＵＰｎＰリクエストを出力するように構成され、
−前記ＵＰｎＰリクエストは、記述（ｄｅｓｃｒｉｐｔｉｏｎ）リクエスト、プレゼンテーション（ｐｒｅｓｅｎｔａｔｉｏｎ―発表―）リクエスト、予約（ｓｕｂｓｃｒｉｐｔｉｏｎ）リクエストおよび質問（ｑｕｅｒｙ）のうちの１つを含み、
−前記ＵＰｎＰプロクシーイネーブラは、前記ＵＰｎＰリクエストに応答してデバイス記述、サービス記述、発表ページ、イベント（出来事）および変数の値のうちの少なくとも１つを提供するように構成されている、
請求項１に記載のシステム。
【請求項４】
前記ＵＰｎＰプロクシーイネーブラは、
−少なくとも１つの非ＵＰｎＰデバイスの広告を前記ＵＰｎＰコントローラに提供するように構成された発見（ｄｉｓｃｏｖｅｒｙ）モジュールと、
前記ＵＰｎＰコントローラからの要求に応答して、このＵＰｎＰコントローラに対して前記少なくとも１つの非ＵＰｎＰデバイスの機能の記述を提供するように構成された記述（ディスクリプション）モジュールと、
ユーザによる前記少なくとも１つの非ＵＰｎＰデバイスの制御を容易にする発表ページを提供するように構成された発表モジュールと、
のうちの少なくとも１つを備える請求項１に記載のシステム。
【請求項５】
前記発見モジュール、前記記述モジュール、前記発表モジュールのうちの少なくとも１つは、前記スレーブネットワークの前記少なくとも１つの非ＵＰｎＰデバイスに向けて、前記広告、前記記述、前記発表ページをそれぞれ提供するように構成されている請求項４に記載のシステム。
【請求項６】
前記ＵＰｎＰプロクシーイネーブラは、
−前記ターゲット（目標）デバイスに対してコマンドを通信するデバイス制御モジュールと、
前記ターゲットデバイスの状態の１つまたはそれ以上の変化を通知されるように前記少なくとも１つのＵＰｎＰコントローラからの要求を受信するイベント予約モジュールと、
前記ターゲットデバイスの状態の１つまたはそれ以上の変化を前記少なくとも１つのＵＰｎＰコントローラへ通知するイベントソースモジュールと、
のうちの少なくとも１つを備える請求項１に記載のシステム。
【請求項７】
前記デバイス制御モジュールは、前記ターゲットデバイスの前記状態を反映するサービス状態テーブルを保持すると共に、
前記イベントソースモジュールは、前記サービス状態テーブルに基づいて前記ターゲットデバイスの状態の１つまたはそれ以上の変化を、前記少なくとも１つのＵＰｎＰコントローラに通知する、
請求項６に記載のシステム。
【請求項８】
前記ＵＰｎＰプロクシーイネーブラは、前記スレーブネットワークの前記少なくとも１つの非ＵＰｎＰデバイスへの通信に効果のあるスレッド（ｔｈｒｅａｄ）に結びつけられたデータ構造を変更することにより、前記デバイスコマンドを前記ターゲットデバイスに通信する請求項１に記載のシステム。
【請求項９】
前記ＵＰｎＰプロクシーイネーブラはさらに、
−前記少なくとも１つの非ＵＰｎＰデバイスの接続および非接続を検出し、
−結果的に前記スレーブネットワークに結びつけられた１つまたはそれ以上のデータ構造を更新する、
ようにさらに構成されている請求項１に記載のシステム。
【請求項１０】
前記ＵＰｎＰプロクシーイネーブラは、前記少なくとも１つの非ＵＰｎＰデバイスのそれぞれの接続および非接続に基づいて、スレッドを開始させて終了させるようにさらに構成されている請求項９に記載のシステム。
【請求項１１】
非ＩＰスレーブネットワークにおける少なくとも１つの非ＵＰｎＰデバイスのＵＰｎＰ制御を容易にするための方法であって、
−ＵＰｎＰコントローラからのＵＰｎＰプロトコルに従ってＵＰｎＰコマンドを受信し、
−前記ＵＰｎＰコマンドをデバイスコマンドへ通信し、
−前記デバイスコマンドを前記非ＩＰスレーブネットワークにおける前記少なくとも１つの非ＵＰｎＰデバイスのターゲットデバイスに通信し、
−前記ＵＰｎＰコマンドのＵＰｎＰアクノリッジメントを前記ＵＰｎＰコントローラへ通信する、
を備える方法。
【請求項１２】
前記非ＩＰスレーブネットワークは、ＵＳＢネットワーク、ブルートゥースネットワーク、ＨＡＶｉコンパーチブルネットワーク、ＩＥＥＥ１３９４ネットワーク、ホームＡＰＩネットワーク、ホームＲＦネットワーク、ファイアフライ（ホタル）ネットワーク、電力線（ｐｏｗｅｒ ｌｉｎｅ）ネットワーク、Ｘ−１０ネットワーク、Ｊｉｎｉ（ジニ）コンパーチブルネットワークのうちの少なくとも１つである請求項１１に記載の方法。
【請求項１３】
−前記ＵＰｎＰプロトコルに従って、記述リクエスト、発表リクエスト、予約リクエストおよび質問のうちの１つを含むＵＰｎＰリクエストを受信し、
前記ＵＰｎＰリクエストに応答して、デバイス記述、発表ページ、イベントおよび変数の値のうちの少なくとも１つを提供する、
をさらに含む請求項１１に記載の方法。
【請求項１４】
−前記ＵＰｎＰコントローラに対して、少なくとも１つの非ＵＰｎＰデバイスの広告を提供する、
−前記ＵＰｎＰコントローラからのリクエストに応答して、前記少なくとも１つの非ＵＰｎＰデバイスの機能の記述をＵＰｎＰコントローラに提供する、
−ユーザによる前記少なくとも１つの非ＵＰｎＰデバイスの制御を容易にする発表ページを提供する、
のうちの少なくとも１つをさらに含む請求項１１に記載の方法。
【請求項１５】
前記広告、前記記述、および発表ページのうちの少なくとも１つは、非ＩＰスレーブネットワーク内のそれぞれの非ＵＰｎＰデバイス用の広告、記述、および発表ページを提供するように構成された非ＩＰスレーブネットワーク用の共通ＵＰｎＰプロクシーイネーブラにより提供される請求項１４に記載の方法。
【請求項１６】
−前記少なくとも１つの非ＵＰｎＰデバイスの状態の１つまたはそれ以上の変化を通知されるべきＵＰｎＰコントローラからのリクエストを受信する、
−前記少なくとも１つのＵｐｎＰデバイスの状態の１つまたはそれ以上の変化を前記ＵＰｎＰコントローラに通知する、
をさらに含む請求項１１に記載の方法。
【請求項１７】
−前記ターゲットデバイスの状態を反映させるサービス状態テーブルを保持する、および
−前記サービス状態テーブルに基づいて、前記少なくとも１つの非ＵＰｎＰデバイスの状態の前記１つまたはそれ以上の変化を前記ＵＰｎＰコントローラに通知する、
をさらに備える請求項１６に記載の方法。
【請求項１８】
−前記スレーブネットワークの前記少なくとも１つの非ＵＰｎＰデバイスに結びつけられたスレッドを生成する、および
−前記スレッドに結びつけられたデータ構造を変更する、をさらに備え、
−前記スレッドは、前記データ構造の前記変更に基づいて、前記スレーブネットワークの前記少なくとも１つの非ＵＰｎＰデバイスへの前記デバイスコマンドの通信を成立差させるように構成されている、
請求項１１に記載の方法。
【請求項１９】
−ＩＰサブネットワークと、
−非ＩＰサブネットワークと、
−前記ＩＰサブネットワークと前記非ＩＰサブネットワークとの間の通信および制御を容易にするＵＰｎＰプロクシーイネーブラと、
を備えるネットワーク。
【請求項２０】
前記ＵＰｎＰプロクシーイネーブラは、
−前記ＩＰサブネットワークにおけるＵＰｎＰコントローラからのＵＰｎＰコマンドを受信し、
−前記ＵＰｎＰコマンドをデバイスコマンドに変換し、
−前記非ＩＰサブネットワークにおけるデバイスに前記デバイスコマンドを通信する、
ように構成されている請求項１９に記載の方法。
【請求項２１】
前記ＵＰｎＰプロクシーイネーブラは、前記ＩＰサブネットワークにおける前記ＵＰｎＰコントローラからのＵＰｎＰリクエストに応答して、前記非ＩＰネットワークにおける前記デバイスに対応させて、デバイス記述、サービス記述、発表ページ、イベント、および変数の値のうちの少なくとも１つを提供するようにさらに構成された請求項１９に記載のネットワーク。
【請求項２２】
前記ＵＰｎＰプロキシーイネーブラは、非ブロッキング通信を提供するスレッドの使用を介して、前記ＩＰサブネットワークと前記非ＩＰサブネットワークとの間の通信および制御を容易にする請求項１９に記載のネットワーク。
【発明の詳細な説明】
【０００１】
この発明は、制御システムの分野に係り、さらに詳しくは、ユニバーザル・プラグおよびプレイ（以下、ＵＰｎＰ―Ｕｎｉｖｅｒｓａｌ Ｐｌｕｇ ａｎｄ Ｐｌａｙ―）オブジェクトまたはアプリケーションを介して、非ＵＰｎＰ追従スレーブデバイスの制御に関するものである。
【０００２】
“ユニバーサル・プラグおよびプレイ（ＵＰｎＰ）”は、全ての形状因子の知的電気製品、無線装置、およびＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）との相互接続性を有する広範囲なピーツーピーネットワーク用のアーキテクチャである。これは、家庭用であろうと、小ビジネスであろうと、公共の空間であろうと、または、インターネットに所属されているものであろうと、特別のまたは管理されていないネットワークへの、使い易く、融通性があって、標準（規格）に基づく接続性を持たらすように設計されている。ユニバーサル・プラグおよびプレイは、分散されて開放されたネットワーキング・アーキテクチャであり、このアーキテクチャはこの明細書中に参考文献として組み込まれる、１９９９−２０００年マイクロソフト社（登録商標）の２０００年６月８日の第１０版に開示された、例えば“ユニバーサル・プラグおよびプレイ装置アーキテクチャ”における“家庭、オフィス、および公共の空間におけるネットワーク化されたデバイス”間の制御およびデータ転送に加えて、継ぎ目がなくて近似的なネットワーキングを可能にするために、ＴＣＰ／ＩＰおよびウェブ技術を活用している。
【０００３】
他のネットワーキング・ソリューション（問題解決法）はまた、家庭、オフィス、および公共の空間におけるネットワーク化されたデバイス間の制御やデータ転送に有用である。標準は発展され続けて、デバイスに対してタイプを変化させたり共通のコントローラにより制御されるべき製品の供給元を変化させたりすることを許容している。それぞれがフィリップ電子（登録商標）や、サンマイクロシステムズ（登録商標）株式会社のＯＳＧＩ／Ｊｉｎｉ技術およびその他からの実質的な貢献を含むＨＡＶｉアーキテクチャ、ホームＡＰＩイニシアチブ、ユニバーサルシリアルバス（ＵＳＢ）、ホームＲＦライトおよびブルートゥース標準規格は、ネットワークにおける多数のデバイスの相互運用性を向上させるために開発されている。
【０００４】
有用なネットワークソリューションのそれぞれは、個別の長所と短所とを有している。例えば、ＵＳＢインターフェースは、相対的に安価であり、それゆえに例えばキーボードやマウスポインティングデバイスなどのようなたくさんのコンピュータ周辺装置内に組み込まれている。このＵＳＢはまた、この低コストで相当に高速度の相互接続性を提供しており、例えばビデオカメラからのビデオ情報転送のための標準的なインターフェースとして適用されている。しかしながら、このＵＳＢは、３０メートル以下に制限されたケーブル長の仕様を有しており、幾つかのアプリケーションでは５メートル以下である。これにひきかえ、ＵＰｎＰネットワーキングアーキテクチャは、例えばワールド・ワイド・ウェッブのような世界的な広がりの通信ネットワーク用に現在のところ用いられている、ＴＣＰ／ＩＰを使用している。しかしながら、このＴＣＰ／ＩＰは、より多くの能力があり、そのためより複雑で高価なプロトコルであり、一般的には高速のイーサネット（登録商標）接続を介して実施されている。ＴＣＰ／ＩＰがたとえコンピュータ、高速プリンタ、サーバなどのための実行可能なネットワークソリューションであるとはいえ、その本来備えている複雑性は、例えばカメラや、ＤＶＤプレーヤやレコーダなどのような消費者用のデバイスでのその使用を奨励することはない。同様に、ブルートゥース標準規格は、ネットワーク化された環境における無線のデバイスの使用を助けているが、例えばＵＰｎＰ標準規格により提供される、ＴＣＰ／ＩＰに基づく通信および制御には適していない。
【０００５】
各々のネットワーキングソリューションは、一般的な家庭またはオフィス環境に設けられている種々のネットワークを結果し易いものとなる。一般的な緩衝におけるたくさんのデバイスの存在と共に、このような異種のネットワークの間における橋渡しを提供するデバイスやシステム用にそれぞれの必要性が増加している。
【０００６】
この発明の目的は、ＩＰネットワークおよび非ＩＰネットワーク間の橋渡しをする、アーキテクチャ、方法およびシステムを提供することにある。この発明の更なる目的は、ＵＰｎＰに準拠する例えばアプリケーションプログラムのようなオブジェクトに対して非ＩＰネットワークに接続されたスレーブデバイスを制御させるアーキテクチャ、方法およびシステムを提供することにある。この発明の更なる目的は、スレーブデバイスに変更を加えることなく、非ＵＰｎＰに準拠するスレーブデバイスの制御を可能にすることにある。
【０００７】
これらおよびその他の目的は、ＵＰｎＰプロクシーイネーブリング論理およびインターフェース論理を有する非ＩＰネットワークを提供することによって達成される。ＵＰｎＰイネーブリング論理は、１つまたはそれ以上の非ＩＰネットワークにおけるデバイスのそれぞれのための、ＵＰｎＰアドレッシング、発見および記述プロセスを結果するように求められたモジュールを提供している。非ＩＰネットワークのそれぞれは、同一または異なるネットワーク技術を用いていても良い。ＵＰｎＰ制御およびイベント位相（ｐｈａｓｅ ）の間に、ＵＰｎＰプロクシーイネーブル論理およびインタフェース論理は、ＵＰｎＰ制御オブジェクトより受信したＵＰｎＰ制御コマンドに従って、ネットワーク内の非ＵＰｎＰに準拠するデバイスの各々にコマンドを通信すると共に、ＵＰｎＰ準拠のデバイスおよびＵＰｎＰ準拠の制御オブジェクトに対しておよびこれらからイベント状態メッセージを通信するための、適切な制御変換とイベントプロクシープロセスとを提供している。全てのコマンドおよびイベントが通信されるものと仮定すれば、多数の同時に発生するスレッド（ｔｈｒｅａｄ ―糸・細いもの―）またはプロセスがブロッキングを避けるために用いられる。多数の同時に発生するプロセスを用いることはまた、システムが多数のホストの間に分散されることを許容している。同様に、適切なメモリロッキングが共有のメモリ環境の中での一貫性とデータの信頼性とを確実にすることを要求されるものとして達成されている。ホストの可能性のプログラミングを容易にするために、命名規則が独特（ユニーク）で意味のあるプロセスと変数名を提供するために用いられており、データベースアーキテクチャは、ＵＰｎＰのために要求された可能性、記述、発表パラメータを容易に格納するために提供されている。
【０００８】
【発明の実施の形態】
この発明は、添付図面を用いて具体例の方法によって、以下、さらに詳細に説明される。
【０００９】
図面全体を通して、同一の参照符号は同一または相当する特徴または機能を示している。
【００１０】
図１は、多数で異種のネットワーク１７０，１８０におけるデバイス１７１，１８１に相互に接続するＩＰネットワークにおけるＵＰｎＰコントローラ１６１を備える本発明の一実施例に係るシステム１００を示すブロック図である。この発明はＵＰｎＰの互換性のある制御構成要素の何れの形式にも適用可能ではあるが、参照を容易にするために、以下、ＵＰｎＰコントローラ１６１は、このようなコントローラ用の技術用語として共通して用いられるものに合致させて、ユーザ制御点（ＵＣＰｓ）として引用される。
【００１１】
この発明によれば、ホストシステム１１０内のＵＰｎＰイネーブリング論理１２０は、スレーブネットワークインターフェース１４０，１５０をそれぞれ介して、制御される、またはスレーブ、デバイス１７１，１８１に相互に接続している。単一のホストシステム１１０が示されているが、この技術分野の通常の知識を有する者は、ホストシステム１１０が種々のデバイスの中で分散されているであろうことを認識するであろう。たとえこの発明の原理が、ＨＡＶｉ互換性ネットワーク、例えばＩＥＥＥ１３９４ネットワーク、ホームＡＰＩネットワーク、ホームＲＦネットワーク、ファイアフライネットワーク、例えばＸ−１０ネットワーク電力線ネットワーク、そしてＪｉｎｉ互換性ネットワークを含むネットワーク上のデバイスの制御を容易にする実質的には何れのネットワークに対しても適用可能であるとはいえ、例えばＵＳＢネットワーク１７０とブルートゥースＲＦネットワーク１８０が示されている。
【００１２】
ホストシステム１１０内のＵＰｎＰイネーブル論理１２０は、ＵＰｎＰユーザ制御点１６１とスレーブデバイス１７１，１８１との間のコマンドおよびメッセージの変換および調整を結果として行なっている。参照を容易にするために、ＩＰネットワーク１６０上のＵＰｎＰに準拠するオブジェクトは、ＵＰｎＰオブジェクトとして引用され、非ＩＰネットワーク１７０，１８０上のデバイスは、非ＵＰｎＰデバイスとして引用されている。
【００１３】
図２は、例えばＵＳＢネットワークのような非ＩＰネットワークを、ＵＰｎＰユーザ制御点１６１に橋渡しするためのホストシステム１１０の一実施形態に係るブロック図を示している。図示されているように、ＵＰｎＰイネーブリング論理１２０は、後で詳細に説明するＴＣＰ／ＩＰおよびＵＤＰ／ＩＰ２３２より優位に立つＨＴＴＰ２３１を含むＵＰｎＰスタック１３０を介して、ＩＰネットワーク１６０上のＵＣＰｓに相互に接続している。ＵＰｎＰイネーブリング論理１２０はまた、スレーブネットワークインターフェース１４０に相互に接続されてスレーブデバイス１７１への制御とメッセージの伝達とを結果として行なっている。この実施例においては、ＵＳＢ標準規格の存在に合致させて、ＵＳＢネットワークインターフェース１４０は、デバイスドライバ２４１，クラスドライバ２４２，ＵＳＢスタック２４３，およびＵＳＢホストコントローラ２４４を備えている。後の部分でさらに説明するように、スレーブネットワークインターフェース１４０は、ネットワーク１７０の各デバイス１７１についての情報を伴うＵＰｎＰイネーブリング論理１２０、各デバイス１７１の現在の状態（接続されている／接続されていない／スタンバイ等）、各デバイス１７１の現在の能力、などを提供している。
【００１４】
ＵＰｎＰデバイスアーキテクチャは、ユーザ制御点（ＵＣＰｓ）とデバイスとの間の通信用プロトコルを定義している。図３は、ＵＰｎＰネットワーク管理の発見、記述、制御、イベントの発生、および発表フェーズのために用いられる、ＵＰｎＰプロトコルスタックを示している。最も高いレイヤ３１０では、メッセージはそれらのデバイスのＵＰｎＰのベンダー（製造供給元）を特定する情報のみを含んでいる。スタック（積層）を下へと移動して、ベンダーコンテント（内容）３１０は、ＵＰｎＰ評議会（Ｆｏｒｕｍ）運営委員会により定義された情報３２０によって補われる。上記レイヤ３１０，３２０からのメッセージは、ＵＰｎＰアーキテクチャにより定義された、ＵＰｎＰ特定プロトコル３３０内に受け入れられる。これらプロトコル３３０は、単純なサービス発見プロトコル（ＳＳＤＰ―Ｓｉｍｐｌｅ Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ Ｐｒｏｔｏｃｏｌ―）、一般的イベント通知アーキテクチャ（ＧＥＮＡ―Ｇｅｎｅｒａｌ Ｅｖｅｎｔ Ｎｏｔｉｆｉｃａｔｉｏｎ Ａｒｃｈｉｔｅｃｔｕｒｅ―）、単純なオブジェクトアクセスプロトコル（ＳＯＡＰ―Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ―）を用いてフォーマットされて、ＨＴＴＰを介してレベル３４０で搬送される。このＨＴＴＰ３４０は、ＵＤＰ３５２からあふれ出してくるマルチキャスト３４２またはユニキャスト３４４の何れか、または、ＴＣＰ３５４をあふれ出してくる標準的なＨＴＴＰ３４６，３４８である。ＵＤＰ３５２またはＴＣＰ３５４のメッセージのそれぞれは、ＩＰ３６０を介して、プロトコルレベル３５０で搬送されている。
【００１５】
図４は、ＵＰｎＰコントローラ（ＵＣＰｓ）および制御されるデバイスのネットワークを確立して保持するためのＵＰｎＰプロセスの一例を示している。ＵＰｎＰネットワーキングのための基礎は、ＩＰアドレッシングである。それぞれのデバイスは、ネットワークを管理している動的ホスト構成プロトコル（ＤＨＣＰ―Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ ―）による割り当てを介するか、または、もしもネットワークが管理されていないのならば、自動ＩＰアドレス生成機能を介するかによって、ステップ４１０で独特のアドレスを割り当てられる。デバイスはまた、各々のデバイスに対する事後の参照を容易にするために、デバイス名を割り当てられても良い。
【００１６】
ＩＰアドレスを考えると、ＵＰｎＰプロセスの次のステップは、要求されるように、各々のデバイスが、そのデバイスまたはそのサービスについての幾つかの本質的な細目や、より詳細な情報についてのポインタを、ネットワークに供給する発見ステップ４２０である。ＵＣＰｓはまた、特別な利害関係を有するデバイスを調査するための発見プロセスを用いている。このデバイスは、ＵＣＰによるそれらの特徴を調査するのに応答するだけでなく、それらが最初にネットワークに入ったときに、それらの本質的な特徴を宣伝している。ネットワークが最新のものにされ続けることを確実にするため、デバイスは、発見プロセス４２０を介してそれらの広告宣伝を周期的にリフレッシュすることが求められている。デバイスは、それらがログオフメッセージを通信するとき、または、それらがその広告宣伝をリフレッシュし損なったときに、ネットワークをログオフされる。
【００１７】
ＵＰｎＰプロセスの次のステップは、記述４３０であり、ここでは、宣伝されたデバイスに関心を持たれたＵＣＰｓがデバイス広告に含まれているＵＲＬ（ユニバーサル・リソース・ローケータ―Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ―）アドレスから追加の情報に関する要求を発信している。具体的には、この装置およびサービスに関する追加の情報は、デバイスに位置付けられるが、これはまた、デバイスの製造供給元により保持される、例えばインターネットサイトのように、遠隔の位置に配置されていても良い。
【００１８】
ＵＣＰがデバイスの能力を学習するとき、ステップ４４０で、動作要求または価値問い合わせを介して、デバイスを制御および／またはモニタすることができる。動作要求に応答して、デバイスは動作を起こし、その結果を報告する。一般的には、この結果は要求された動作が起こされたという承認（アクノリッジメント）であるが、現在のデバイスの状態、および／または、このデバイスに関連する１つまたはそれ以上の変数の状態を報告する、より詳細なメッセージであっても良い。価値問い合わせに応答して、このデバイスはこの価値問い合わせにおいて識別された１つまたはそれ以上の変数の状態を報告する。
【００１９】
ＵＣＰはまた、イベントが発生するときにはいつでも、イベントを行なうプロセス４５０を介して、通知を要求するようにしても良い。ＵＣＰは、デバイスでの状態の何れかの変化が通知されることを「承認し」、この通知のプロセスから個々の変数の値の変化のような、特定の状態の変化を排除しても良い。デバイスが状態を変化させるときにはいつでも、デバイスはそれらの承認から特定の状態の変化を排除されていた承認を除く、イベントの全ての承認へ通知する。
【００２０】
ＵＣＰは、プロセス４６０で、デバイスにより供給された発表ページに基づいて、デバイスに関連された能力や制御を提供している。ＵＣＰは、デバイスの記述により与えられたＵＲＬから発表ページを要求する。ステップ４３０のデバイス記述と同様に、ＵＲＬはデバイスをアドレスしても良いし、または、例えば製造供給元のインターネットサイト、または、第３者のサービスプロバイダのサイトのような遠隔のサイトをアドレスするようにしても良い。
【００２１】
図５は、この発明による非ＩＰネットワークにインターフェース１４０を含ませるようにしたホストシステム１１０におけるＵＰｎＰ・ＵＣＰインターフェース１３０およびＵＰｎＰイネーブリング論理１２０の一例のブロック図を示している。
【００２２】
ＵＰｎＰ・ＵＣＰインターフェース１３０は、ＩＰネットワークモジュール２３２にアクセスし、ネットワーク通信を生成して管理することを含み、適切なＩＰメッセージをフォーマットし、メッセージを受信したり送信したりするためのネットワークサービスレイヤ５０１を備えている。従来の実施と一致させて、ネットワークサービスレイヤ５０１は、信頼性を向上させるためにマルチキャストＵＤＰメッセージを多数回にわたって送信する。
【００２３】
ＵＰｎＰ・ＨＴＴＰサーバ２３１は、図３のＨＴＴＰプロトコルレイヤ３４０に関連して上記で述べたように、ＵＰｎＰ・ＵＣＰｓ１６１と制御されたデバイス（図１の１７１，１８１）との間の通信に用いられるハイパー・テキスト・トランスファー・プロトコル（ＨＴＴＰ―Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ―）を支援するサーバプロセスである。好適な実施形態において、ＨＴＴＰサーバ２３１は、多数のＵＣＰｓ１６１と多数のデバイスとの間の相互接続を取り扱い、非ブロッキング転送を提供するように構成されている。この非ブロッキング転送は、以下に詳述するように、要求の異なるタイプを取り扱うスレッドの使用を介して容易に達成される。この好適な実施形態におけるＨＴＴＰサーバ２３１により提供される機能は：
−デバイスの接続と切断を取り扱うと共に、デバイスの能力、記述および発表用のＵＰｎＰの定義された問い合わせを取り扱うスレッドを生成して管理し；
−各ネットワークのトラックおよびこのネットワーク用に生成されたスレッドのタイプを保持すると共に、各スレッド用の通信データ構造を記録するネットワークテーブル５０２を生成して保持し；
−ＨＴＴＰメッセージを受信してこれらをこのメッセージを担うための対応するモジュールへ通過させるために、予め定義されたＴＣＰ／ＩＰサーバと予め定義されたマルチキャストＵＤＰポートとをモニタし；
−応答とＧＥＮＡ通知を適正なＨＴＴＰメッセージへと変換すると共に、ネットワークサービス５０１にメッセージを送出させるためのアプリケーション・プログラム・インターフェース（ＡＰＩ―Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍ Ｉｎｔｅｒｆａｃｅ ―）を提供するものである。
【００２４】
ＵＰｎＰ・ＨＴＴＰサーバ２３１はネットワークテーブル５０２を用いると共に、例えばＨＴＴＰなどのＨＴＴＰリクエストラインの値はＧＥＴ，ＰＯＳＴ，Ｍ−ＰＯＳＴ，Ｍ−ＳＥＡＲＣＨ，ＳＵＢＳＣＲＩＢＥおよびＵＮＳＵＢＳＣＲＩＢＥを発送のために要求している。例えば、ＨＴＴＰ・Ｍ−ＳＥＡＲＣＨリクエストの受信に基づいて、これは、ＵＰｎＰイネーブル論理１２０内の各ネットワークに対応する発見サーバモジュール５１０に対してメッセージを発送して要求されたサーチを達成する。
【００２５】
好適な実施形態におけるＵＰｎＰプロクシ・イネーブリング論理１２０は、２つの部分を備えている。第１の部分１２０ａは、それぞれのスレーブネットワークまたはそれぞれのデバイスのために実施された構成要素を含み、第２の部分１２０ｂは、それぞれのスレーブネットワークにおけるそれぞれのスレーブデバイスにより提供されるそれぞれのサービスのために実施された構成要素を含んでいる。例えば、ＶＣＲ装置は、クロックサービス、チューナサービス、テープ搬送サービスを含む各種のサービスを具体的に提供している。
【００２６】
ネットワークレベルＵＰｎＰイネーブリング論理１２０ａは、スレーブネットワークにおけるそれぞれのデバイスに関連するコマンドやメッセージを発効させたり調整したりするデバイス管理モジュール５４０と同様に、ＵＰｎＰ発見、発表、および記述位相をそれぞれ発効させたり調整したりするために求められたモジュール５１０，５２０を備えている。デバイス接続／切断ハンドラ５５０は、ネットワークにおけるデバイスの存在とそれらの能力に関するＵＰｎＰリクエストに応答するためにモジュール５１０，５２０，５３０が用いている適切なデータベース５１５，５２５，５３５に対して情報を供給している。活性化されたときに、デバイス接続／切断ハンドラ５５０は、その関連するネットワークにおけるそれぞれのデバイスに関する情報を決定するために、スレーブ・ネットワーク・インターフェース１４０を用いている。この情報を用いることにより、情報はデータベース５１５，５２５，５３５でそれぞれ発見、発表、および記述情報を満たしている。好適な実施形態において、それぞれのスレーブネットワーク用の１つのデバイス接続／切断ハンドラ５５０を生成して開始させた後に、ＨＴＴＰサーバ２３１は、ハンドラのうちの少なくとも１つが対応するデータベースへの要求された情報を付加することを終了するまで、初期化の間に、待ち状態に置かれることになる。初期化の後に、ハンドラ５５０は接続および切断についてそれぞれのデバイスをモニターしてデバイス情報を適切に付加しまたは削除することによりそれぞれのデータベース５１５，５２５，５３５を更新している。ハンドラ５５０はまた、１つまたはそれ以上のＧＥＮＡ通知メッセージを形成し、ＨＴＴＰサーバ２３１のＡＰＩに対してこのような付加や削除を同報で通信させている。ハンドラ５５０はまた、ＳＳＤＰ「活動状態の（アライブ―ａｌｉｖｅ―）」メッセージを周期的に形成して、ＨＴＴＰサーバ２３１のＡＰＩに対してこのメッセージを放送させて、これによりＩＰネットワークにおけるそれぞれのデバイスの活性化状態をリフレッシュさせている。
【００２７】
発見サーバモジュール５１０およびこれに対応するデバイス能力データベース５１５は、ＵＰｎＰ発見サーバの仕様を実行している。上記で注目したように、好適な実施形態においては、発見モジュール５１０は、それぞれのデバイスのためにその対応するネットワークの範囲内でＵＰｎＰ発見機能を提供する責任がある。好適な実施形態における発見モジュール５１０の機能は：
−デバイスの特徴に関してネットワークまたはデバイスに問い合わせるためのＡＰＩを提供する；
−“ｓｓｄｐ：ｄｉｓｃｏｖｅｒ”のようなメッセージヘッダを伴った、例えば、Ｍ−ＳＥＡＲＣＨメッセージのような、ＵＰｎＰサーチメッセージを処理する；
−ＳＳＤＰの問い合わせに基づいて、デバイス能力データベース５１５をサーチし、応答を形成し、上述したＨＴＴＰサーバ２３１に対して要求のなされたところへ応答を返すためにＡＰＩを発行する（機能）を備えている。
【００２８】
デバイス能力データベース５１５は、上述したように、記述および／または発表が配置されている対応する遠隔ＵＲＬアドレスを有していないデバイスのために、ＵＰｎＰ記述サーバ仕様を実行している。まず始めに、非ＩＰネットワークにおけるデバイスが遠隔ＵＲＬアドレスで関連するＵＰｎＰ記述を有しないであろうこと、したがって、ＵＰｎＰイネーブリング論理１２０がデバイス記述データベース５３５を介して記述を提供することが必要となるであろうこと、が期待されている。しかしながら、この発明がありふれたものとなるので、製造供給元や第３者開発会社が非ＵＰｎＰデバイス用のＵＰｎＰ記述を開発しそうであり、したがって、デバイス記述データベース５３５に格納されることを求められる情報の量は実質的に減少するであろう。記述サーバモジュール５３０の機能は：
−デバイスの記述を問い合わせるためのＡＰＩを提供する；
−その応答性に基づいてスレーブネットワークにおけるデバイス用の記述の発表を管理するローカル記述サーバにアドレスされたＨＴＴＰ／ＧＥＴメッセージを処理する；
−ＨＴＴＰ／ＧＥＴメッセージに応答してデバイス記述データベース５３５をサーチすると共に、ＨＴＴＰサーバ２３１でのＡＰＩにこの応答に対して回答させる、を含んでいる。
【００２９】
発表モジュール５２０は、ＵＰｎＰ発表サーバの仕様を実行すると共に、要求されたようにデバイス発表データベース５２５を用いて、ネットワーク上のデバイス用の責任を有するローカル発表サーバにアドレスされたＨＴＴＰ／ＧＥＴメッセージに応答するように記述サーバモジュール５３０と同じように構成されている。
【００３０】
デバイス管理モジュール５４０は、例えばＨＴＴＰ・ＰＯＳＴやＭ−ＰＯＳＴメッセージのようなデバイスアクセスや制御リクエストに応答して、たくさんのＵＣＰに対してその応答性の下でスレーブネットワーク内のたくさんデバイスを同時に制御させることを可能にしている。デバイス管理モジュールの機能は：
−以下に説明するように、デバイス制御リクエストへの道順を決めて処理するためのスレッドを生成して管理する；
−デバイスの接続および切断イベントの通知を提供するデバイス接続／切断ハンドラ用のインターフェースを提供する、を備えている。
【００３１】
デバイステーブル５４５は、（例えば、デバイスＵＵＩＤおよびサービス名のような）サービスの識別符号と、サービス制御サーバ５７０とイベント予約サーバ５６０にデータを通信するのに用いられるデータ構造との間のマッピングを格納している。
【００３２】
サービスレベルＵＰｎＰイネーブリング論理１２０ｂは、イベントモジュール予約サーバ５６０，サービス制御サーバモジュール５７０，およびイベントソースモジュール５８０を備えている。具体的には、デバイスは１つまたはそれ以上のサービスを提供している。好ましくは、デバイスによって提供されるそれぞれのサービスに関連する、１つのイベント予約サーバモジュール５６０，１つのサービス制御サーバモジュール５７０，および１つのイベントソースモジュール５８０がある。したがって、それぞれのサービスに関連する、１つのイベント予約データベース５６５および１つのサービス状態テーブル５８５である。
【００３３】
デバイス制御サーバモジュール５７０は、その関連するサービスを指示する制御コマンドを結果として生じさせる責任を負っている。好適な実施形態におけるサービス制御サーバモジュール５７０の機能は：
−ＳＯＡＰコマンドを解析し、適切なドライバインターフェースに各コマンドを結果として出力させ、ＨＴＴＰサーバ２３１でのＡＰＩからリクエストしてきたものに対して承認または失敗メッセージを出力させる、
−もしもサービスの状態が変化したならば、成功したコマンドの実行に基づいて、サービス状態テーブル５８５を更新する、
−スレーブデバイスにより提供されたイベントをモニターして、もしもサービスの状態が変化したならば、サービス状態テーブル５８５を更新する、
−イベントソースモジュール５８０に対してサービス状態テーブル５８５のそれぞれの更新を行なわせる、を備えている。
【００３４】
好適な実施形態において、全てのスレーブデバイスドライバが駆動されているデバイスの全ての状態を報告するように構成されていないので、デバイス状態テーブル５８５が、（電力、レジスタ値などの）サービス状態の現在の値を記録するために用いられる。テーブル５８５は、デバイスがＵＰｎＰ制御ネットワークに入ったときに初期化されて、状態変化コマンドが首尾良く実行されるごとに状態を更新することによりサービスの状態に一致し続ける。
【００３５】
イベント予約サーバモジュール５６０は、それぞれのサービスに関するデバイスイベントについてＵＣＰｓの利害関係を表現することを許容させる責任を負っている。好適な実施形態におけるイベント予約サーバモジュールの機能は：
−ＧＥＮＡイベント予約メッセージを解析し、予約するＵＣＰｓ識別と予約されるイベントとをイベント予約データベース５６５内に入力し、ＨＴＴＰサーバ２３１のＡＰＩに予約用ＵＣＰへのアクノリッジを送出する、
−イベントソースモジュール５８０に初回予約部（サブスクライバ）ＵＣＰへの現在のサービス状態を通過させる、を備えている。
【００３６】
イベントソースモジュール５８０は、イベントを予約した全てのＵＣＰｓに対してサービスのイベントを送り出す責任がある。好適な実施形態におけるイベントソースモジュール５８０の機能は：
−サービス制御サーバモジュール５７０用のインターフェースに、サービス状態テーブル５８５へのサービス状態における変化に関する通知を通過させる、
−イベント予約データベースを検査し、ＧＥＮＡ通知メッセージを形成することにより予約されたイベント変化を予約用ＵＣＰｓに通知し、ＨＴＴＰサーバ２３１のＡＩＰにＧＥＮＡメッセージを送らせる、
−ＨＴＴＰサーバ２３１のＡＰＩを介して、また、ＧＥＮＡ通知メッセージの形成と送信を介して、サービスの状態のそれぞれの初回予約部の通知を結果させるためのイベント予約サーバモジュール５６０用のインターフェースを提供するを備えている。
【００３７】
図６は、この発明に係る、ＵＰｎＰ・ＵＣＰｓとスレーブデバイスとの間の通信のために非ブロッキングアーキテクチャを提供するためのスレッド生成の流れ図を示している。理解を便利にし容易にするために、この流れ図に示された原理は他の構造やシステム構成にもまた適用可能なものではあるとはいえ、参照符号は従前の図面における構成要素に付されたものを用いている。各参照符号の第１の桁は、参照された構成要素が導入された最初の図面に対応している。
【００３８】
プロセス６１０で、ＨＴＴＰサーバ２３１は、各スレーブネットワーク用の、ネットワークテーブル５０２，デバイス能力データベース５１５，デバイス記述データベース５３５，およびデバイス発表データベース５２５のためのメモリスペースを割り当てて初期化している。ＨＴＴＰサーバ２３１はまた、それ自身とスレーブネットワークのデバイス接続／切断ハンドラ５５０のそれぞれとの間の通信と同期のためのスペースを割り当てて初期化している。プロセス６１５で、ＨＴＴＰサーバ２３１は、各ネットワーク用のデバイス接続／切断ハンドラスレッドを生成し、少なくとも１つのデバイス接続／切断ハンドラ５５０がデバイス能力データベース５１５，デバイス記述データベース５３５，デバイス発表データベース５２５を首尾良く初期化してしまうまで待機している。デバイス接続／切断ハンドラ５５０がデータベース５１５，５２５，５３５を初期化してしまったという通知をＨＴＴＰサーバ２３１が受け取ったときに、ＨＴＴＰサーバ２３１は、プロセス６２０で生成されるであろう各作業スレッド用のデータ構造を割り当てて初期化する。これらのデータ構造は、スレッドとの間で通信するために用いられている。各ネットワークデバイス接続／切断ハンドラ５５０がネットワークのデータベース５１５，５２５，５３５の成功した初期化を報告するので、ＨＴＴＰサーバ２３１は、各々のネットワークのためプロセス６１５〜６２０を繰り返している。プロセス６３０で、ＨＴＴＰサーバ２３１は複数の作業スレッドを生成し、あるものはデバイスの発見を取り扱うと共に、あるものはデバイスの発表を取り扱っている。各スレッドは、対応するモジュールを動作させて、それが用いるであろうデータベース５１５，５３５，５２５へのポインタを受け入れる。プロセス６３５においては、ＨＴＴＰサーバ２３１は、ネットワークテーブル５０２に、各スレッド用の、各ネットワークタイプ、各スレッドタイプ、各通信データ構造を記録する。その後、ＨＴＴＰサーバ２３１は、各デバイスマネジャ５４０に対して、ネットワーク内の対応するデバイスのためのスレッドを取り扱うサービスをセットアップするように指示し、この対応するデバイスについてはこのマネジャが責任を負うべきである。マネジャ５４０は、ＨＴＴＰサーバ２３１の状況の中で実行する。
【００３９】
プロセス６５０において、各デバイスマネジャ５４０は、それが責任を負うべきためのネットワーク内のデバイスのリストを得るために、発見サービスモジュール５１０にまず問い合わせをする。各デバイスについて、マネジャはさらに、デバイスにより提供されるサービスのリストを得るために、記述サーバモジュールに問い合わせをする。次に、マネジャは、各デバイスにより提供される各サービスのためのサービス取り扱いスレッドと、各スレッドに通信するための対応するデータ構造とを生成する。プロセス６５５においては、デバイスマネジャ５４０がデバイステーブル５４５内のデバイスによって提供される各サービスに対して各スレッドのマッピングを記録する。
【００４０】
プロセス６７０で、各サービスハンドラスレッドは、イベント予約データベース５６５およびその関連するサービスのためのサービス状態テーブル５８５を割り当てて初期化する。プロセス６７５で、各サービスハンドラスレッドは、サービスに関連する、サービス制御５７０，イベント予約５６０，およびイベントソース５８０のそれぞれを動作させる。
【００４１】
図示されていないが、デバイスがネットワークに追加されたとき、デバイスマネジャ５４０は、ブロック６５０〜６５５のように、デバイスによって提供された各サービス用のサービスハンドラスレッドを生成して記録している。新たに生成されたサービスハンドラスレッドは、上記ブロック６７０〜６７５のように、サービス特定データベース５６５およびテーブル５８５を生成して初期化し、モジュール５６０，５７０，５８０を動作させる。
【００４２】
プロセス６９０では、ブロック６３０および６５０内で生成された全てのスレッドが、各スレッドに関連するデータ構造を介して、保留中の作業を通知するまで待機する。ＨＴＴＰサーバ２３１が個別の作業スレッドのための入来するリクエストを識別するときに、サーバ２３１はこのリクエストをスレッドに対応するデータ構造の中に配置して、その後次のリクエストの取り扱いに戻る。このようにして、ＨＴＴＰサーバ２３１は、リクエストの処理に対して実質的に少しの時間を当てるだけとなり；各リクエストの実際の処理が、リクエストの単一の配置を介して、適切なデータ構造の中へ結果として生じることになる。好適な実施形態において、各スレッドは、そのデータ構造の内容を周期的にチェックする。１つまたはそれ以上のデータ構造の項目が変わるときに、スレッドはこの変化に応じて取られる適切な動作を決定して、その結果として反応する。作業が完了した後、スレッドは、ＨＴＴＰサーバ２３１でＡＰＩに、入来したリクエストを送信したＵＣＰへ、アクノリッジメント（もしもリクエストが実現されていなかったならば、代わりに失敗通知）を通信させる。入来する制御コマンドの場合、このコマンドは目標となるサービスのサービス取り扱いスレッドの通信データ構造内に配置される。サービス取り扱いスレッドがそのデータ構造の中にこのコマンドを検出したとき、このスレッドはコマンドのタイプを決定する。もしもコマンドがイベントの予約であるならば、これはイベント記述サーバモジュール５６０へとこのコマンドを通過させる。もしもこのコマンドがサービス制御コマンドであるならば、このコマンドはデバイス制御サーバモジュール５７０へと通過させられる。
【００４３】
他に取り得るスレッドの開始および制御スキームは、この技術分野の通常の知識を有する者にとって容易に明白となるであろう。例えば、個別のサービスについてのリクエストが最初に到着したとき、スレッドが生成される。このスキームにおいては、例えば、デバイスマネジャ５４０は、記述がＵＣＰによってリクエストされたときに、通知を通過させるために、デバイス記述サーバモジュール５３０用のインターフェースを提供している。この通知を受信することに基づいてデバイスマネジャ５４０は、もしもサービス取り扱いスレッドが既にデバイスのために存在しているならば、それを決定するためにデバイステーブル５４５をチェックする；もしも存在していないならば、スレッドはデバイスによって提供される各サービスのために生成される。このようにして、サービス取り扱いスレッドは、少なくとも１つのＵＣＰが興味があることを示されたデバイスに関して生成されるのみである。これとは選択的に、スレッドは効率的な実行を提供することを期待されているかもしれないとはいえ、スレッドの代わりに権限を付与された論理を実行するためにプロセスを用いることができる。このようなプロセスは共有のメモリを介して、またはスレッドの場合にはメッセージの通過を介して、何れかにより通信するであろう。プロセスの通信のためにメッセージの通過が選択されたとき、これらのプロセスは、単一のプロセッサまたはコンピュータ、または多数のプロセッサまたはコンピュータで実行可能である。
【００４４】
上述されたように、この発明の実施形態は、ＵＰｎＰコントローラを介して非ＵＰｎＰデバイスの制御を容易にする手段を提供している。この技術分野で通常の知識を有する者にとって明かとなるであろうように、提供された具体例のように、もしも共有のメモリが通信および同期のために用いられているのならば、この技術分野では通常、適切な鍵掛け機構が適正な動作を確実にするために用いられるべきである。例えば、デバイス能力データベース５１５，デバイス記述データベース５３５，デバイス発表データベース５２５，デバイステーブル５４５のためには一貫性のあることが重要であり、それ故に、各データベースの更新のための原子動作が実行されるべきである。例えば、読出し動作によりリフレッシュデータが提供されることを確実にするために、具体的には読出し動作よりもデータベースまたはテーブルへの書込動作が優先するであろう。データの一貫性を保持するためのこれらおよび他の手段は、この技術分野に共通している。
【００４５】
この発明の好適な実施形態では、一貫性のある名前の付いた慣例となったスキームが設計を簡略化するために用いられている。例えば各サーバ用に用いられるＵＲＬの局部的な部分はプレフィックス（電話局番・名称の前につける接頭辞）：例えば“ｕｓｂ／ｄｅｓｃｒｉｐｔｉｏｎＳｅｒｖｅｒ”または“ｂｌｕｅｔｏｏｔｈ／ｐｒｅｓｅｎｔａｔｉｏｎＳｅｒｖｅｒ”のようなネットワーク＿タイプ／サーバ＿タイプを有している。デバイス接続／切断ハンドラ５５０によりデバイスファイルの位置決めを容易にするために、各ファイル名は、例えば“ｌａｓｅｒ＿ｐｒｉｎｔｅｒ．ｄｅｓｃｒｉｐｔｉｏｎ”または“ｓｃａｎｎｅｒ．ｃａｐａｂｉｌｉｔｙ”のようなデバイスの識別子やファイルの内容を含んでいる。これらの名称は、例えばデバイスの製造元や型の表示を含むことによって、より具体的にされても良い。もしもデバイスの機能がライブラリー（標準プログラムの収集）機能を介して提供されるのならば、この機能名は、デバイスを独特に識別し、これにより機能名の衝突を避けることのできるプレフィックスを含んでいる。
【００４６】
上述の説明は、単にこの発明の原理を明かにするのみである。したがって、この技術分野の通常の知識を有する者は、この明細書に明白に説明または図示されていなくとも、この発明の原理を実施化し、この発明の精神や権利範囲の範囲内である種々の構成を考え出すことができるであろうことは正しく認識されるであろう。例えば、デバイスのデータベース内の情報を管理するために、異なる技術を用いることができる。１つの実施形態においては、何れかのデバイス用に知られている全てのデータが固定記憶装置内に記憶されており、対応するデバイスが現在ネットワークに接続されているか切断されているかの信号を出力するために設定されるそれぞれのデータと共にフラッグが保持されている。他の実施形態においては、それぞれのデバイスがネットワークから接続されたり切断されたりするので、データのセットがデータベースに加えられたり除去されたりしている。第１実施形態は、ネットワークから通常は離れて再び参入するデバイスのための“ログイン（ｌｏｇ−ｉｎ）”時間を減少させているが、追加的なメモリを必要とするためコストを必要としている。第２実施形態は、メモリの使用を最適化しているが、デバイスに関連するデータベースについてこのデバイスがネットワークに再び参入するたびごとに生成されて初期化されることを要求している。図面に示されている個々の機能的な区分は、描写目的のために示されていること、および、ハードウェア的およびソフトウェア的な実行の種々の組み合わせがこの発明を実施するために用いられても良いこともまた注目される。これらおよび他のシステムの構成および最適化の特徴は、この明細書の開示に鑑みてこの技術分野の通常の知識を有する者にとって明白であろうし、上述された請求項の範囲内に含まれるであろう。
【図面の簡単な説明】
【図１】
本発明の一実施例による多数で異種のネットワークに相互に接続するＵＰｎＰユーザ制御点（ＵＣＰｓ―Ｕｓｅｒ Ｃｏｎｔｒｏｌ Ｐｏｉｎｔｓ ―）を備えるシステムを示すブロック図である。
【図２】
この発明の一実施形態に係るＵＰｎＰユーザ制御点を備える非ＩＰネットワークを橋渡しするためのシステムを示すブロック図である。
【図３】
先行技術の一例によるＵＰｎＰプロトコルスタック（積層）を示す説明図である。
【図４】
先行技術の一例によるＵＰｎＰプロセスを示す説明図である。
【図５】
この発明の一実施形態に係る非ＩＰネットワークへのインターフェースを含むシステムにおけるＵＰｎＰ・ＵＣＰインターフェースおよびＵＰｎＰイネーブリング論理を示すブロック図である。
【図６】
この発明の一実施形態に係るＵＰｎＰ・ＵＣＰｓと非ＵＰｎＰデバイスとの間の通信用の非ブロッキングアーキテクチャを提供するためのスレッドの生成を示す流れ図である。
【符号の説明】
１２０  ＵＰｎＰプロクシーイネーブラ
１３０  ＵＰｎＰインターフェース
１６１  ＵＰｎＰコントローラ
１７０  スレーブネットワーク
１７１  非ＵＰｎＰデバイス
１８０  スレーブネットワーク
１８１  非ＵＰｎＰデバイス
５１０  発見モジュール
５２０  発表モジュール
５３０  記述モジュール
５３５  データ構造
５４０  デバイス制御モジュール（データ構造）
５６０  イベント予約モジュール
５８０  イベントソースモジュール
５８５  サービス状態テーブル
【図１】
2004516711.tif 000003
【図２】
2004516711.tif 000004
【図３】
2004516711.tif 000005
【図４】
2004516711.tif 000006
【図５】
2004516711.tif 000007
【図６】
2004516711.tif 000008
【国際公開パンフレット】
2004516711.tif 000009
2004516711.tif 000010
2004516711.tif 000011
2004516711.tif 000012
2004516711.tif 000013
2004516711.tif 000014
2004516711.tif 000015
2004516711.tif 000016
2004516711.tif 000017
2004516711.tif 000018
2004516711.tif 000019
2004516711.tif 000020
2004516711.tif 000021
2004516711.tif 000022
2004516711.tif 000023
2004516711.tif 000024
2004516711.tif 000025
2004516711.tif 000026
2004516711.tif 000027
2004516711.tif 000028
2004516711.tif 000029
2004516711.tif 000030
2004516711.tif 000031
2004516711.tif 000032
2004516711.tif 000033
【国際公開パンフレット（コレクトバージョン）】
2004516711.tif 000034
【国際調査報告】
2004516711.tif 000035
2004516711.tif 000036
2004516711.tif 000037