JP4118566B2 - 機器統合のためのネットワーク構築装置 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、種々の家庭用機器や個人用機器をURLアドレスで統合管理する機器統合のためのネットワーク構築装置に関する。
【０００２】
【発明が解決しようとする課題】
将来の生活において、周囲には益々多くのプロセッサが内蔵されることが予測され、具体的にはアナログ無線回路や種々のセンサが、プロセッサと一体化されるだろうし、種々のコンピューティング機能が周囲環境に内蔵されるであろう。とりわけ、コンピュータが「コンピュータ」という特殊な箱として１箇所に存在するのではなく、人間の生活環境の至るところに分散して存在するユビキタス（Ubiquitous：どこにでもある）・コンピューティング環境が、ハードウェアの観点から、まもなく実現され得るであろう。
【０００３】
ユビキタス・コンピューティング環境は、実世界で活動する人間を無意識に支援するもので、その人間のおかれている環境を認識する必要があるが、こうしたユビキタス・コンピューティング環境において、家庭内では種々の内蔵プロセッサが増加すると考えられる。これにより、種々の家庭機器の制御が可能となり、種々の情報を検索して、我々の嗜好や周囲情報に従って機器を動作させることが可能になる。例えば、テレヴィジョンの様な音響映像機器が、IEEE1394のような標準の高速ネットワークにより接続されるであろう。また、部屋の中にある照明やエアー・コンディションは、無線ネットワークを通じて、携帯電話やPDA機器により制御されるであろうし、家具にプロセッサが内蔵されるかもしれない。最終的には、これらのネットワークがホーム・ゲートウェイにより一体化されるであろう。
【０００４】
しかしながら、ソフトウェアの観点から見ると、生活の向上を図るために種々の家庭機器を一体化するには、ミドルウェアの構成要素が必要である。ミドルウェアとは、いわゆるOS（Operating System）上で動作し、アプリケーションソフトに対してOSよりも高度で具体的な機能を提供するソフトウェアのことで、OSとアプリケーションソフトの中間的な性格を持っているが、現在、広範囲に利用されるであろうミドルウェア構成要素を構築するのは簡単なことではない。例えば、ネットワークを通じて各種機器を接続し、相互に機能を提供しあうための技術仕様であるJini（登録商標）や、同じように家庭内のパソコンや周辺機器、AV機器、電話、家電製品などの機器をネットワークを通じて接続し、相互に機能を提供しあうための技術仕様であるUPnP（ユニヴァーサル・プラグアンド・プレイ）は、ミドルウェアとして良く知られているが、これらのミドルウェアを採用している機器は少ない。一方、HTTPプロトコルは、近い将来に種々の機器に広く組み込まれるものと思われ、現在のプロセッサにおけるインターネット・プロトコルを実行するには費用が極めて安い。それ故に、将来の殆どの機器は、HTTPサーバを内蔵して、インターネット上の如何なる場所からでも機器をアクセスできるようになるであろう。
【０００５】
具体的には、近い将来において、プロセッサはインターネット・プロトコルを実行するハードウェア・アクセラレーターを包含し、非常に低価格でウェッブ・サーバを導入するであろう。ウェッブ・サーバは、種々の機器に内蔵され、周囲にある実物対象は、情報を実物対象に結びつけるためのURLを包含する。これらのシステムは実物対象を増加させ、或いは実世界と仮想世界とを統合する。また、エミット・テクノロジーの様なウェッブ・テクノロジーを採用した商品も出ている。このように、近い将来ウェッブ・サーバを内蔵した機器が出現するものと思われる。
【０００６】
ホーム・コンピューティング環境としては、ウェッブ・サーバ内蔵のテレヴィジョン，ヴィデオ・カセット・レコーダ，照明及び電子レンジのような種々の機器を含むと考えられる。これらの機器は、どのウェッブ・ブラウザーからでも、或いはHTTPプロトコルを使用するアプリケーション・プログラムから制御できる。例えば、ウェッブ・サーバを内蔵したテレヴィジョンは、ウェッブ・サーバからの診断を業者が行なうことができる。故に、遠隔で家庭機器を容易に管理することができる。また、ウェッブ・ブラウザーから室内の照明が制御可能である。こうした状況は、安価なホームオートメーションシステムを構築させることになる。
【０００７】
しかしながら、現在のHTTPプロトコルは複雑なホーム・コンピューティング環境を作るのに必要なディレクトリサービス（ネットワーク上の資源とその属性とを記憶し、検索できるようにしたシステム）や自動構成管理（Automatic Configuration Management）のような必要な機能を提供できないという問題がある。
【０００８】
TV（テレヴィジョン）やVCR（デジタルビデオカメラ）の様な種々の家庭用機器はホーム・ネットワークに接続され、総てのホーム・ネットワークは、種々の情報を交換し他の機器から別の機器を制御するために、インターネットにより統合することができる。将来のネットワークは、極めて膨大な数の機器を接続可能であるので、これらの機器は利用者の観点からすると、一個の機器として統合されるべきである。この種の統合は、膨大な量の機器が、インターネットに接続されることを期待されているので、近い将来に非常に重要になる可能性がある。
【０００９】
こうした種々の機器が相互に接続されているコンピューティング環境は、前述のユビキタス・コンピューティング環境と呼ばれる。しかしながら、ユビキタス・コンピューティング環境の従来の考え方は、インターネットに比較した場合少々規模が限定されており、インターネット規模のユビキタス・コンピューティング環境を設計しようとする場合には、更にある問題を考慮する必要がある。
【００１０】
種々のネットワークとプロトコルが、各アプリケーションのドメイン用に提案されてきた。例えば、前述のJiniやUPnP（ユニヴァーサル・プラグアンド・プレイ）の様な種々のプロトコルは、使用前の構成無しに、種々の機器を接続するために提案されてきた。また、別なプロトコルであるHAViは種々の家庭用音響映像機器に特化して、その接続のために提案されてきた。一方、ATM（非同期転送モード）ネットワーク，IEEE1394，携帯情報機器向けの無線通信技術として知られるブルートゥース（登録商標），そしてVIAの様な種々のネットワーク・システムが、種々の機器を接続するために開発されてきた。また、研究団体に於いて、PEN，ネットワークド・サーフェスそしてCLANは、将来の進歩した機器を接続するために提案されてきた。
【００１１】
しかしながら、これらの基本的なプロトコルとネットワークのもつ種々の有益な特性は、IP層がネットワークに挿入されるならば、アプリケーションから隠されてしまう。例えば、ブルートゥースにより提供されるプラグ・アンド・プレイ機能とATMにより提供されるネットワークバンド幅保存機能は、通常IP層（注：QOS保証するIPプロトコルを拡張する幾つかの提案がなされているが、この提案によって提供されるアブストラクションは、ATMのバンド幅保存能力の全部は提供しない)の最上層で通常利用できない。また、ある機器のなかには、他の機器やサービスに接続するためのIP層を支援（サポート）しないものもある。更に、各機器は、互いに通信する為に異なる制御プロトコルやデータ・フォーマットを想定するかもしれない。それ故、新しい手法が、将来の家庭用機器のために、ネットワーク支援を実現する必要がある。
【００１２】
過去にインターネットに関する種々の問題を解決するために、ヴァーチャル・オーバーレイ・ネットワークが利用されてきたが、ネットワーク化された家庭用機器の統合の為にヴァーチャル・オーバーレイ・ネットワークを適用する考えには及んでいない。すなわち、組織的な手法で、インターネット規模のユビキタス・コンピューティング環境を得るために、カスタマイズされたヴァーチャル・オーバーレイ・ネットワークを構築する必要がある。
【００１３】
そこで本発明は、ウェブ・サーバを有する家庭用の機器を修正することなく、複雑なホーム・コンピューティング環境を作るのに必要なディレクトリサービスや自動構成管理（Automatic Configuration Management）と同様の機能を持つことができる機器統合のためのネットワーク構築装置を提供することをその目的とする。
【００１４】
【課題を解決するための手段】
本発明の請求項１における機器統合のためのネットワーク構築装置は、利用者が保有する端末と、ウエッブサーバーを内蔵した制御対象となる機器とを接続したネットワーク網にゲートウェイ・サーバを接続し、このゲートウェイ・サーバは、現在利用可能な機器の情報を自動的に収集して、その内容を前記端末に提示する自動構成管理手段と、前記端末から目標となる機器を制御するコマンドが発信されると、このコマンドに含まれるURLを翻訳して目標となる機器にURLでアクセスする機器アクセス手段と、前記ネットワーク網へ周期的にHTTPプロトコルによる問合わせメッセージを送る検索手段とを備え、前記機器は与えられた有効期限内で前記検索手段からの前記問合わせメッセージを受取ると、自身の情報を前記検索手段へ返送し、前記検索手段は前記情報をデータベースへ登録するか、或いは前記データベースを更新して、前記情報内で特定された前記有効期限内に前記機器に対して前記問合わせメッセージを送り、前記端末からの発見要望を受けた場合、前記検索手段はフルテキスト検索技術を使って前記データベースから現在利用可能な機器を選び出す構成とされる。
【００１５】
この場合、HTTPプロトコルに基づくネットワークで各機器を統合するのに必要な機能が、自動構成管理手段と、ディレクトリ・サービスに相当する機器アクセス手段としてゲートウェイ・サーバに備えてあるので、ウェブ・サーバを有する家庭用の機器を修正することなく、複雑なホーム・コンピューティング環境を構築することが可能になる。
【００１６】
また、機器統合のためのネットワーク構築装置は、HTTPプロトコルを使用して前記機器の制御を可能にし、その動作を利用者の状況に応じて変化させる状況認知機器制御手段を前記ゲートウェイ・サーバに備えたものである。
【００１７】
このようにすると、HTTPプロトコルに基づいたユビキタス・コンピューティング環境の構築を達成できる。
【００１８】
【発明の実施形態】
以下、添付図面を参照しながら、本発明における好適な各実施例を順に説明する。図１〜図３は、本発明の第１実施例を示す機器統合のためのネットワーク構築装置である。
【００１９】
先ず詳細な構成を説明する前に、本システムの設計で最も重要な基本的概念とは、ウエッブ・サーバを有する家庭用機器を修正せず使用することにある。ウエッブ・サーバを有する汎用の家庭用機器は、自身が保有するウエッブ・サーバの修正ができないのであるが、かといって新しいプロトコルを標準化するのは非常に難しい。しかし、通常の人々はホームネットワークがどのようにして形成されるのかを知らないので、ホームコンピューティング環境を構築するには、JiniやUpnPに見出される自動構成（コンフィギュレーション）管理がサポートされなければならない。
【００２０】
従来のウェッブに基づく環境では、利用者はアクセス前に、各機器のURLを知る必要があった。しかし、利用者がアクセスしたい機器のURLを見付けるディレクトリ・サービスが何も存在しないので、そのURLを知ることは容易ではない。また、このディレクトリ・サービス内における各機器に対するURLを登録するのに自動構成管理を必要とする。
【００２１】
図１は、各家庭用機器を統合することが可能なネーミング（命名）管理を提案するシステム全体の構成で、１はインターネットを実現するための通信手段、２はこの通信手段に接続する複数の家庭用機器である。また３は、HTTPプロトコルの下で利用されるHTTPクライアントで、具体的には家庭でインターネットを利用する際のパソコン（パーソナルコンピュータ）などがこれに相当する。
【００２２】
ここでのシステムは、二個の構成要素から成っている。第一の構成要素は、ウェブベース環境内に組み込まれる機器２である。この機器２は、ウェッブ・サーバを備えており、IEEE802.11b, ブルートゥース，IEEE1394或いはイーサーネットなどの標準ネットワークを通じて、インターネットネットワークを構築する通信手段１に接続されている。ここに提案するシステムは、各機器２におけるウェッブ・サーバの拡張を想定していない。したがって、ウェッブ・サーバを含む汎用製品のどれでも通信手段１に接続して使用できる。
【００２３】
第二の構成要素は、家庭用の機器２を管理するために設けられゲートウェイ・サーバ４である。このゲートウェイ・サーバ４は、目標となる機器２へのアクセス方法を提供するディレクトリ・サービスの役割を演じるもので、さらに現在利用できる機器２を維持管理する自動構成管理としての機能も備えている。
【００２４】
図１に示すホームネット利用者が、部屋の中にある家庭用の機器２にアクセスしたい時は、先ずHTTPクライアント３を利用してゲートウェイ・サーバ４と接触する。ゲートウェイ・サーバ４は、部屋の中にある利用可能な機器２に関する情報を利用者に提供する。利用者の観点からすると、その利用者はゲートウェイ・サーバ４のIPアドレスを含むURL（Uniform Resource Locator：インターネットにおける情報の「住所」）を使って、機器１を制御するための要求を発するので、利用者にとって如何なる家庭機器もゲートウェイ・サーバ４に直接接続されているように見える。ゲートウェイ・サーバ４は、機器２のウェッブ・サーバから集められる情報に従って、適正な機器２に向かってその要求を転送する。
【００２５】
次に、各機器２を制御するためにどのようにしてURLを特定するのかについて説明する。ここでの最終目標は、任意のアプリケーションやデバイスに対しURLに基づくインターフェースを提供することである。ウェッブ・ブラウザーは一般的に、標準のHTTP GET機構を使って問合せ要求を提示することにより、URI（Uniform Resource Identifiers ：インターネット上に存在する情報資源の場所を指し示す記述方式で、URLはURIの機能の一部を具体的に仕様化したもの）に一致するリモートホストにアクセスして、そのURIからの応答を受け取るか、または、標準のHTTP POST機構を使ってHTML形式を通じてURIにデータを提示し、同じくHTTP内のURIから応答を受け取る。利用者によって通過されるURLは、以下に示すように翻訳され、その要求は目標の機器２に転送される。
【００２６】
図１に示すシステムにおいて、利用者はHTTPに基づくプロキシ・サーバとして与えられたゲートウェイ・サーバ４を通して、一つまたはそれ以上の機器２にアクセスできる。しかしながら、ゲートウェイ・アドレスが判っているときでさえも、利用者が機器２の中から最適の機器２の一つを確認することは難しい。そこで、機器２を特定し制御するためのURLに基づいたネーミングの取り決めをここで行なう。この取り決めは、標準のURL内で定義するが、URL形式のパス・エレメントは、図２に示す如く、BNF（バッカス記法）に似た構文に従って、幾つかの追加情報を含むことができる。
【００２７】
ここで、＜path＞::=の次にある文字「ε」は、文字列の存在しないempty string を意味し、＜string＞は一連のアルファベットに対応する。＜search＞::=の次にある文字「？」の属性は、問い合わせ式を表し、フィールドが（場所或いは所有者と云った）問い合わせの性質を記述する場合には、一組のフィールド値であり、一個の値は文字列または整数である。「！」の属性は、フィールドがコマンドの性質を記述する場合はそのコマンドを特定すると共に、その値は文字列または整数である。
【００２８】
上記取り決めによれば、例えば"http://some.where.com.8080/CEIL-LIGHT/!power=ON"なるURLの記述として表わせる。このURLの記述では、事前の同意によりポート番号8080で聞いているsome.where.com. と命名されたゲートウェイが呼び出される。その次の"CELL-LIGHT"の要素は、ゲートウェイの下で制御される電灯を特定するものである。"！power=ON"の要素は、ゲートウェイに対し信号を送ると共に、機器２別にON値を備えた"power"と命名される特別の機能を指名する。このURLは、"CELL-LIGHT"として命名された電灯をオンするための要求である。
【００２９】
もう一つの例として、"http://some.where.com/?location=room1&?function=light/!power=ON"を示す。
【００３０】
この例の中で、"?location=room1"の要素は、ゲートウェイ・サーバ４の下で制御されるビルまたはフロア−の"room1"と呼ばれる場所を特定している。また「?function=light」の要素は、room1の場所で機能的に命名された"light"をサポートする最適な機器２の一つを特定している。そして、このURLも、"light"として命名された電灯をオンするための要求である。
【００３１】
この様な最適な機器２をダイナミック（動的）に特定するために、ここで取り決めたURLは、"＄(variable)"の形式を含むことができる。なお"variable"は、その値が文字列である可変名を示す。これらの変数は、ゲートウェイ・サーバ４上で実行するシェルプログラム或いはオぺレーティングシステム（OS）により提供される環境変数と関連付けられる。URLに基づく表記法に対する変数の概念は、G.Voelker氏およびB.Bershad氏による「モビザイク：モバイル無線コンピューティング環境用の情報システム（モバイルコンピューティングシステムおよびアプリケーションにおけるワークショップ議事，1994年IEEEコンピュータ学会）」において手法されたダイナミックURLに基づく手法により、もとは示唆されたものである。ダイナミックURLの変数は、利用者側のコンピュータ（HTTPクライアント３)上で実行するシェルプログラムまたはオぺレーティングシステム（OS）によって、提供される環境変数と常に関連をもたなければならないが、ここで提案される変数は、ゲートウェイ・サーバ４でダイナミックに解釈される。
【００３２】
例えば、"http://some.where.com/$(LIGHT)/!power=ON"と記述された上記変数を含む拡張したURLを考える。
【００３３】
ここで、"$(LIGHT)"なる要素は、電灯を特定する一つの変数である。ゲートウェイ・サーバ４内に維持管理される前記"LIGHT"の変数が、天井に取り付けられた電灯を特定するCELL-LIGHTである時、上述のURLは"http://some.where.com/CEIL-LIGHT/!power=ON"として解釈される。新しい電灯が部屋に取り付けられる場合、オぺレーティングシステム（OS）は"LIGHT"環境変数の値を更新してもよく、その値が現状の環境で最適な物の一つとして見なされる。従がって、物の移動は、現状の環境に対しダイナミックに適合することが可能である。
【００３４】
次に、機器２にアクセスする機構、すなわちディレクトリ・サービスについて説明する。本実施例におけるディレクトリ・サービスは、通信手段１に接続した現在利用可能な家庭用の機器２に関する情報を提供することである。また、機器へのアクセス方法をも提供する。ウェッブ基礎のホーム・コンピューティングにおける重大な問題の一つは、利用者が制御したい機器２のURLを如何にして知るかということである。その際、ゲートウェイ・サーバ４は、利用者がHTTPクライアント３にて保有するブラウザに対して、機器２を制御する為のURLを含むHTMLページを返してもよい。しかしながら、利用者のHTTPクライアント３にて保有するプログラムから機器２にアクセスすることは容易ではないので、この手法は望ましいものではない。それ故に、本実施例のシステムでは、機器２が利用者から直接ゲートウェイ・サーバ４に接続されている様に見せる機構を提供する。これは、利用者側のHTTPクライアント３がゲートウェイ・サーバ４のホスト名と機器２の名前を知る必要があることを意味する。
【００３５】
本システムによるこの手法は、各機器２のIPアドレスを知らなくても、通信手段１を介したインターネット上の如何なる場所からでも、利用者自身の家庭内の機器２を制御可能である。それ故に、利用者がIPアドレス或いは予め各機器２のホスト名を知っていることを仮定する必要はない。また、ここでは最新のダイナミックDNS（Domain Name System ：インターネット上のホスト名とIPアドレスを対応させるシステム）の使用を考えなくても良い。DNSの更新は、総ての家にDNSサーバを導入する必要があるが、このことは、DNSの設置がインターネットに関する多くの知識を必要とするため実際的ではない。更に、ここでのシステムの手法は、利用者のHTTPクライアント３が直接機器２にアクセスする必要はない。このように、ゲートウェイ・サーバ４は、あらゆる要求の確認を照合することができる。それゆえに、我々の手法はまた従来のウェッブ基礎のホーム・コンピューティングのセキュリティ性を向上するものである。
【００３６】
ゲートウェイ・サーバ４は、後述するウェッブ・ロボット（機器２に備えたウェッブ・サーバを自動的に巡回してデータを収集する）により構築された地図データベースを保存するデータベース記憶部を備えている。要求を受け取ると、URLのファイル部が調べられ、コマンド部が取去られる。それから、URLの残りのフィールドによってデータベースが検索される。データベースが新しいURLを返し、前段階で除去されたコマンド部が連結される。それから、目標の機器２がそのURLを使用してアクセスされる。
【００３７】
こうした技法は、URL書き換えと呼ぶ。例えば、"http://www.gw.tatsuo.tokyo.jp/TV/!channel=10/"というURLについて考える。このURLは、「私は、私の家のテレビチャンネルを10にセットしたい」ことを意味している。ゲートウェイ・サーバ４は、自身の保有するデータベースの検索により、家の中にあるそのテレビのIPアドレスが123.5.10.10であることから、URLを"http://123.5.10.10/!channel=10/"に翻訳して書き換える。このことは、ゲートウェイ・サーバ４内に家庭内の機器２とIPアドレスとを関連付ける情報があれば、利用者は実際のIPアドレスを知る必要の無いことを意味する。
【００３８】
総ての機器２は、それらの処理能力、記憶容量、バンド幅そして電力に限界があるため、複雑化して能動的になるものと予期されてはいなかった。それ故、各機器２に内蔵されているソフトウェアは、極力小さく単純化されなければならない。しかしながら、例えばUpnPやJiniのような機器２に対する現存の管理技術は、記憶容量と計算能力の必要性の点から極めて重量が重く、大部分の機器では使用できない。したがってここでは、能力の低い機器を発見できる軽量の機構を必要とする。この手法は、そうした機構のような検索手段すなわちウェッブ検索エンジン（インターネットで公開されている情報をキーワードなどを使って検索できるWebサイト）をゲートウェイ・サーバ４に導入する。このエンジンは、各機器２から集められた情報のデータベースを維持管理し、利用者がウェッブ検索技術によって必要とする関係の機器を発見することができる。
【００３９】
各ウェッブ検索エンジンは、機器２の固有識別子と動作時間を記録し、自身のインデックスを更新化するために、特定の間隔でサブネットワーク上の可能な全アドレスに対しHTTP GET要求を周期的に送る。ゲートウェイ・サーバ４からの要求を受け取ったとき、機器２は、それ自身の２個のプロファイル、有効期限そしてここで詳述したURLに基づく形式で形成された利用可能なコマンド名を返答する。もし、ゲートウェイ・サーバ４のエンジンが動作中に機器２から何らかの応答を受けた場合、エンジンはデータベースから応答の無いの機器の登録を抹消する。更にこの手法は、一個以上のエンジンがネットワーク上で動作することを可能にする。いわゆるピアツーピアの手法で、 エンジンは互いに接続しあうことができる。各エンジンは、集められた情報に対し索引付けされた問合せインターフェイスを提供すると共に、他のエンジンから情報を回収したり、自身のインデックスの更新を増やすことができる。
【００４０】
この機構は、JiniやUpnPの様にプラグ・アンド・プレイ方式で自動的に機器２を組み込むことができる。新規にネットワークに接続される機器２におけるインストール、若しくは再動作される登録済み機器２における再インストールの作業を考えると、各エンジンは、それがカバーするネットワークへ周期的にHTTP基礎の問合わせメッセージを沢山送るので、その機器２は与えられた間隔内でエンジンからのメッセージを受取り、自身の情報をエンジンへ返送する。次に、エンジンはその情報を自身のデータベースへ登録するか、或いはデータベースを更新して、次にその情報内で特定された有効期限で機器２に問合わせメッセージを送る。利用者または他のホストからの発見要望を受けた場合、そのエンジンは、現状のウェッブ検索エンジンで使用されているフルテキスト検索技術を使ってデータ・ベースから適当な機器を選び出す。故に、この機構は、容易にかつ自然にHTTP内での動作が可能である。各エンジンは、機器２の管理および発見に対し信頼をおけるので、機器２は無籍（Stateless）なHTTPとして扱うことができる。
【００４１】
現行アーキテクチャ（基本設計概念）における問題点の一つは、各機器２のURLを如何にして知るかということである。利用者がHTTPクライアント３から目標の機器２を制御したい場合、URLの構文を知らねばならない。将来のコンピューティング環境において、機器２をいかに制御すべきかという情報を含む電気的タグを添付することが可能である。例えば、照明を点けることを意味するバーコードを付ける事が出来る。そのバーコードは、パーソナル機器により照明をオンすると読み込まれる。URLは、そのURLを含んだビーコンを受け取ることによってアプリケーションから検索されてもよいし、またRFID（Radio Frequency ldentification ：無線周波による非接触自動識別器）がバーコードの代わりに使われても良い。
【００４２】
ここでの解決法は、URLを発見するパーソナル機器の使用である。このパーソナル機器は、URLを含むバーコードを読み込んだり、ビーコンを受取ることができる。パーソナル機器がバーコードを読む場合、そのIDがゲートウェイ・サーバ４の中にあるバーコード管理手段すなわちバーコード・マネージャーへ転送される。バーコード・マネージャーは、受け取ったIDを実際のURLに変換し、目標の機器２へコマンドを送る。また、パーソナル機器がビーコンを受信した場合は、ビーコン中のURLは、ゲートウェイ・サーバ４に転送される。この手法によって、システムを使用する場合に、種々の機器２の制御を容易に行なうことができる。
【００４３】
次に、図１における装置構成を発展させた例を図３に基づき説明する。ここでは、システムが如何に動作するかを一つのシナリオで示している。シナリオの中では、利用者は機器２の遠隔制御手段としてのPDA装置（Personal Digital Assistance：個人用携帯情報端末）11を保有していて、家の中には３個の機器２、すなわちここでは映像音響機器に相当するテレヴィジョン12と、家電機器に相当する電子レンジ13と、照明手段としてのライト13が、ホームネットワークを構築する通信手段１に接続される。これらの機器２の総ては、ウェッブ・サーバを内蔵していて、ゲートウェイ・サーバ４は上述したようなウェッブ・ロボット手段を実行するプログラムを使って、現在利用可能な機器２に関する情報を集める。例えば、テレヴィジョン12はウェッブ・サーバにアクセスする為のURLを持つ情報を返信し、ゲートウェイ・サーバ４は、自身のデータ・ベース中にその情報を保存する。
【００４４】
PDA装置11がWebページ閲覧手段であるウェッブ・ブラウザを起動して開くとき、最初のHTTP GETの要求がゲートウェイ・ウェッブ・サーバ４によって探し当てられる。PDA装置11のウェッブ・ブラウザは、家の中で現在利用可能な機器２のリストを含むHTMLページを、インターネット上でワイヤレスアクセスポイント15を介して返信する。そのHTMLページは、ウェッブ・ロボット手段を実行するプログラムによって集められた情報を利用して、ゲートウェイ・サーバ４により自動的に生成される。
【００４５】
利用者が、TVすなわちテレヴィジョン12のスイッチを入れなさいと云うコマンドを発信したと仮定する。PDA装置11のウェッブ・ブラウザは、" http://www.myhome.net/TV/!power=on/"というGETコマンドを発信する。URLは、"http://tv.myhome.net.tokyo.jp/!power=on/"（G.Voelker氏およびB.Bershad氏による「モビザイク：モバイル無線コンピューティング環境用の情報システム（モバイルコンピューティングシステムおよびアプリケーションにおけるワークショップ議事，1994年IEEEコンピュータ学会）」参照）と翻訳し、テレヴィジョン12のウェッブ・サーバへそのコマンドを転送する。この例で、” www.myhome.net"は、利用者のコンテキスト情報に従って、”www.tatsuo.tokyo.jp"と翻訳される。このことは、利用者が、自分の家にあるゲートウェイ・サーバ４のIPアドレス或いはホスト名を知らずに、自分の家のテレヴィジョン12にアクセスできることを意味する。しかもこのアドレスは、本システムによって自動的に検索される。また、“http:// www.tatsuo.tokyo.jp/TV/"は、"http://tv.tatsuo.tokyo.jp/"と翻訳される。このことは、利用者は、自分のテレヴィジョン12における実際のＩＰアドレスやホスト名を知る必要が無いことを意味する。最後に、テレヴィジョン12のウェッブ・サーバがそのコマンドを受けると、ウェッブ・サーバはテレヴィジョン12の電源スイッチをオンにする。
【００４６】
ここでの手法は、以下に説明するように、位置認識された機器２の制御を可能にする。利用者がインターネットに自分の装置（例えばPDA装置11）を接続する場合に、全てのパケットは、最寄りのルーターに向けて転送されるであろう。ゲートウェイ・サーバ４はルーター上で動作し、如何なるHTTP要求もゲートウェイ・サーバ４によって検索される。最初のHTTPが検索された時に、ゲートウェイ・サーバ４がPDA装置11のブラウザ上でページを返信してもよい。最も近くにあるゲートウェイ・サーバ４がそのページを返信するので、返信したページはゲートウェイ・サーバ４の位置に従ってカスタマイズされる。このことは、利用者が、自身の近くで現在利用できる機器２を知っていることを意味する。例えば、前記説明したシナリオではが、利用者に身近な利用可能な機器２をPDA装置11のブラウザ上で表示することができる。家の中で複数のゲートウェイ・サーバ４を使用することにより、利用者の行動を自分の場所に従がって適応させることが可能になる。
【００４７】
ここでのシステムは、周囲の表示或いは"Calm Technology"を実現する基盤として望まれる。例えば、前記テレヴィジョン12を制御するURLがクリックされたと仮定しよう。利用者が、テレヴィジョン12を制御するHTTP POST要求をゲートウェイ・サーバ４に送る場合、ゲートウェイ・サーバ４は、別のライト14を点灯せよというURLを含むIMGタグを含むページを返信しても良い。かくして、IMGタグ内のURLによって、ライト14が自動的に点灯する。これが周囲表示の例であり、本実施例におけるシステムは、ユビキタス・コンピューティング研究の実験的基盤として、非常に魅力的なものとなる。
【００４８】
また将来的にこのシステムは、VCNサーバ（Visitor And Community Network System：利用者単位のサービス割当、インターネット・ベースの課金システム、セキュリティ/認証サービスを簡単に行えるソフトウェアを含むサーバ）にアクセスするための書き換え計画に対し考慮されている。利用者は、ゲートウェイ・サーバ４上のプロキシVCNサーバにアクセスする。プロキシVCNサーバは、あるコンピュータ上で実行される目標のVCNサーバに向けて総てのパケットを転送する。この手法により、ユビキタス・コンピューティング環境における情報を提供する柔軟な方法を提供できる。
【００４９】
さらに本システムは、バーチャル・オーバーレイ・ネットワークを使用して、Jini, UpnPやHAViを接続するミドルウェア・コンポーネントにも考慮されている。本システムは、これらのミドルウェア・コンポーネントを接続するためのHTTPプロトコルに基づいているので、ミドルウェアを修正せずにJini, UPnPやHAViに本システムを接続するために、このコンポーネントを使うことができる。
【００５０】
このように、本実施例ではホーム・コンピューティングの新しい構成について説明した。この構成は、ウェッブ・システムに基礎を置いており、種々の家庭用の機器２が柔軟な方法で統合される。この手法の利点は、JiniやUPnPのようなディレクトリ管理や、自動構成管理の提供を可能にしつつも、機器２に内蔵されるウェッブ・サーバが修正されることを前提としないことである。かくして、近い将来に非常に大衆的になるウェッブ・サーバを内蔵した汎用家庭機器を、本実施例のシステムは統合することができる。それ故に、Jini, UPnPやHAViの様な他の技術に比べて、ここでの構成はより円滑に利用できる。
【００５１】
以上のように本実施例では、利用者が保有する端末（HTTPクライアント３またはPDA装置11）と、ウエッブサーバーを内蔵した制御対象となる機器２とを接続したネットワーク網を構築する通信手段１にゲートウェイ・サーバ４を接続し、このゲートウェイ・サーバ４は、現在利用可能な機器２の情報を自動的に収集して、その内容を該端末に提示する自動構成管理手段と、前記端末から目標となる機器２を制御するコマンドが発信されると、このコマンドに含まれるURLを翻訳して前記目標となる機器２にURLでアクセスするディレクトリ・サービスとしての機器アクセス手段とを備えている。
【００５２】
このようにすると、HTTPプロトコルに基づくネットワークで各機器２を統合するのに必要な機能が、自動構成管理手段と、ディレクトリ・サービスに相当する機器アクセス手段としてゲートウェイ・サーバ４に備えてあるので、ウェブ・サーバを有する家庭用の機器２を修正することなく、複雑なホーム・コンピューティング環境を構築することが可能になる。
【００５３】
さらに本実施例では、HTTPプロトコルを使用して前記機器２の制御を可能にし、その動作を利用者の状況に応じて変化させる状況認知（"context-aware"）機器制御手段を、ゲートウェイ・サーバ４に備えるのが好ましい。このようにすると、HTTPプロトコルに基づいたユビキタス・コンピューティング環境の構築を達成できる。
【００５４】
次に、本発明の第２実施例を図４〜図６に基づき説明する。ここでは、バーチャルオーバーレイネットワークへの展開を例にした実施例を詳述する。
【００５５】
実施例の説明に入る前に、ここでいうオーバーレイ・ネットワークとは、その中に含まれる基本ネットワークがいくつかの上位ネットワークを支援する為に使用される構成として定義でき、ヴァーチャル・オーバーレイ・ネットワークを実現するための基本特性の十分なセットを提供する。ヴァーチャル・オーバーレイ・ネットワークは、新しいアブストラクト特性を提供する為のソフトウェア層を加えることにより、オーバーレイ・ネットワークの基本特性を拡張する。利用者に代わってその特性を実行することは、各アプリケーションに対してカスタマイズされる。この考え方は、D.Tennenhouse氏などが1997年に"IEEE Communication Magazine Vol.35, No.1で提案した"A Survey Of Active Network"におけるアクティヴ・ネットワークに似ている。アクティヴ・ネットワークは、既存のネットワークのカスタマイズを可能にするので、アプリケーション特有のコードは、ネットワークによって提供される現存の特性を修正することなく注入することが可能である。一方、ヴァーチャル・オーバーレイ・ネットワークは、各アプリケーションに適した新しいアブストラクト特性を追加し、既存のネットワークは拡張しない。ヴァーチャル・オーバーレイ・ネットワークは、既存のネットワーク・インフラの修正を必要としない故に、より実際的であり、各アプリケーションに対し容易にカスタマイズされる。
【００５６】
ここでは図４に示す様に、インターネットのような既存のネットワーク21上に構築されるネットワークとして、ヴァーチャル・オーバーレイ・ネットワーク22を定義する。ヴァーチャル・オーバーレイ・ネットワーク22においては、多くのアプリケーションレベルのゲートウェイ23が、ネットワーク22に設置され、IPプロトコルのような或るネットワーク・プロトコルによって接続される。アプリケーションレベルのゲートウェイ23の役割は、目的地にメッセージを通すことにある。また、環境と利用者によって提示される種々の要求に従がって、各メッセージとプロトコルを翻訳してもよい。アプリケーション・レベルのゲートウェイ23は、ヴァーチャル・オーバーレイ・ネットワーク22のルーター装置として考えることができる。このゲートウェイ23は、通常インターネットにより接続されるが、基礎にあるデータリンク・ネットワークは、もしもアプリケーション・レベルのゲートウェイ23間で特別なQOS要求を満足する必要があれば、直接使用することができる。
【００５７】
ヴァーチャル・オーバーレイ・ネットワーク22は、現在インターネットが持つ広範囲にわたる問題を、解決するであろう。例えば、現存するインターネットは、FQDN(十分に資格を与えられたドメイン名)やIPアドレスを採用しているが、メッセージのルーティング（最適な径路選択）を採用するために、アプリケーション特有の命名（ネーミング）を取り入れることができる。また、アプリケーション・レベルのゲートウェイ23間の接続は、元々あるネットワーク21を直接使用するか、或いはアプリケーション・レベルのゲートウェイ23におけるコンフィギュレーション
（構成）を慎重に選択することにより、ゲートウェイ23間の各QOS要求に従がって適合するように作られる。一方、インターネットにおける端末間のQOS保証を実現することは非常に難しい。アプリケーション・レベルのゲートウェイ23の機能を選択することによって、それぞれのアプリケーションに対しヴァーチャル・オーバーレイ・ネットワーク22をカスタマイズすることができる。移動支援の構築における実験からすると、高レベルの機能を実現する為の解決法は、それぞれのアプリケーションに対しカスタマイズされるべきと考えられる。
【００５８】
ヴァーチャル・オーバーレイ・ネットワーク22の概念は、新しいものではない。それぞれのアプリケーションに対して、ヴァーチャル・オーバーレイ・ネットワーク22の構築に関する提案が従来より幾つか知られている。例えば、Inktomi社の2000年テクニカルレポートにある"The Inktomi Overlay Solution for streaming Media Broadcasts"では、映像や音響の様なマルチキャスト連続メディア・データ用のヴァーチャル・オーバーレイ・ネットワークが提案されてきた。また、J.Jannotti, D.K.Gifford, K.L.Johnson, M.F.Kaashoek, J.W.O'Toole Jr.氏による"Overcast: Reliable Multicasting with an Overlay Network"（2000年オぺレーティングシステムデザインおよびインプレメンションの第４シンポジウム会報）や、A.Jones, A.Hopper氏による"The Prototype Embedded Network(PEN)"（AT＆T研究所，ケンブリッジ，テクニカルレポート，2000年第15号）には、信頼性のあるマルチキャスティングに対するヴァーチャル・オーバーレイ・ネットワークが提案されてきた。L.F.Cabrera, M.B.Jones, M.Theimer氏による"Herald: Achieving a Global Event Notification Service"（2001年オぺレーティングシステムのホットトピックスにある第８回ワークショップ会報）においては、地球規模のイヴェント・サービスに対するヴァーチャル・オーバーレイ・ネットワークが提案されてきた。さらに、K.P.Birman,氏による"Technology Challenges for Virtual Overlay Networks"（2000年情報確約および保証における2000IEEEワークショップ会報）においては、それぞれのヴァーチャル・オーバーレイ・ネットワーク用の資源を分轄する為に使用されるルータパーテーション機構が提案されてきた。この解決法は、インターネットの総ての要求を包括的に満足するものではないが、各ドメインの問題を解決するのには十分である。
【００５９】
従来のネットワークに於いて、ヴァーチャル・オーバーレイ・ネットワークの概念は、部分的に採用されていた。例えばネットワーク上でデータの一斉配信を効率よく行なうための技術であるマルチキャストを、インターネット上で利用できるようにするために構築された実験ネットワークの一つであるMboneや、現在のインターネット上におけるマルチキャスト能力のあるIPネットワークが構築され、また6Boneは、現在のインターネット上のIPｖ6ネットワークを発展させるために利用されてきた。さらに、ドメイン・ネーミング・システムやウェッブ・キャッシング・システムもまた、ヴァーチャル・オーバーレイ・ネットワークと考えられており、アプリケーション特有の方法で、種々の問題を解決した。
【００６０】
こうした既知の提案は、ヴァーチャル・オーバーレイ・ネットワークの概念を採用することにより、拡張性を大いに増大したが、これらの提案は、従来の基礎的データ・リンク・ネットワークは直接使用せず、プロトコルやメッセージの翻訳も明らかに使用していない。その点で本実施例におけるシステムは、ヴァーチャル・オーバーレイ・ネットワークの概念を十分に利用する努力をしている。
【００６１】
システマティックな方法で各アプリケーション向けにカスタマイズされたヴァーチャル・オーバーレイ・ネットワークを開発することは、最も重要な目的の一つである。しかしながら、この目標の達成は、それまでの多くの経験から断定できる。ここでは、ネットワーク化された家庭用の機器を統合する為のヴァーチャル・オーバーレイ・ネットワークの構築について説明する。例えば、Jini，UpnP，HAViそしてSOAP（Simple Object Access Protocol ：他のコンピュータにあるデータやサービスを呼び出すためのプロトコル）は、種々の家庭用機器を制御する為に提供される。クライアント機器は、もしこれらのプロトコルの総てを支援していなければ、家庭用の機器を制御することはできない。しかしながら、多くのプロトコルを支援することは、大きな記憶容量を必要とするので非現実的である。また、新しいプロトコルが将来の家庭用機器に提案されたとすれば、新しいソフトウェアがクライアント機器の中に追加されなくてはならない。
【００６２】
ここでのヴァーチャル・オーバーレイ・ネットワーク22は、クライアント機器によって支援されるプロトコルを家庭用の機器によって支援されるプロトコルに転換することにより、この問題を解決する。この転換は、機器とネットワークの特性に従がって、各アプリケーション・レベルのゲートウェイ23によって実行される。
【００６３】
次に、ネットワーク化された家庭用機器を統合するヴァーチャル・オーバーレイ・ネットワークの効果を詳細に説明する。ヴァーチャル・オーバーレイ・ネットワークの設計を動機付ける最終的な目標は、IEEE1394や、ブルートゥースや、インターネットのような異質のネットワーク上に置かれた各家庭用機器に対し、アプリケーション特有のアブストラクションを提供することである。ここでは、現行プロトタイプのヴァーチャル・オーバーレイ・ネットワークの設計とその利用に就いて説明する。最初に設計の問題点と我々のシステムの概観を提示し、次にこれまで利用した幾つかの構成要素を提示する。最後に、現行プロトタイプシステムについての幾つかの問題点を説明する。
【００６４】
エンドツーエンドの議論は、インターネットに対するシステム設計の原理である。すなわち、複雑なネットワーク機能は、ネットワークの端末に押し進められるものと思われる。しかし現在のインターネットの全端部は、複雑な計算機ではない。何故ならば、例えば、家庭用機器，内蔵コンピュータそしてPDA装置のように、それらの内のいくつかはそれら自身の特別な目的だけのために設計されているからで、それらはインターネットの標準プロトコルは処理できない。したがって、そうした複雑でない端末よりも、機能豊かなネットワークが、ネットワーク内部に於いて支援され向上されるべきであり、端末のあるものとサブ・ネットワークがインターネット向けに用意されていなくても、全端末とサブ・ネットワークに対して継ぎ目の無い状況を提供すべきである。ここでのヴァーチャル・オーバーレイ・ネットワークの骨組みは、次のような機能追加を支援する。
（１）ヴァーチャル・オーバーレイ・ネットワークの骨組みは、新しい命名システムを中心に構築される。ホストネームをアドレスにハードコーディングするような属性に従うというよりもむしろ、機能的かつ物理的位置のような意図した情報に従がって、機器が調べられるべきと考える。実際、TCP／IPを支援しない機器の中には、インターネット内で利用可能な独自のアドレスを持つことが出来ず、その機器に直接接続することができる他のサーバにより包含され、かつ他のサーバを介して確認される必要がある。
（２）ウェッブ基礎のコンピューティングは、HTTPを通じて行なわれ、現在のインターネット内で広く使用される。HTTPはワールド・ワイド・ウェッブ（www）を支えるプロトコルであり、定義によってあらゆるウェッブ・ブラウザはHTTPを使って通信可能である。この通信は、定められた命名規約に適合したURLを使うブラウザによって発生する。ここでヴァーチャル・オーバーレイ・ネットワークは、ウェッブ・ブラウザからの容易なアクセスと種々の家庭用機器の制御を可能にするのみならず、機器が互いに通信し協力動作を行なうことを可能にする。
（３）家庭用機器の中には、JiniやUPnPのような装置（デバイス）とサービスを管理する既存のサービスディスカバリーシステムの下でしばしば管理されるものがある。こうしたシステムは、最小の管理と人間の干渉で装置／サービス内の動的な協動を容易にするために提案されたものである。この臨時的な共同を支援するためには、ネットワークに対してその存在を公表する手段を備えるべきで、これにより近くに在るサービスを発見して、そのサービスにアクセスすることができる。ヴァーチャル・オーバーレイ・ネットワークの骨組みは、各機器に対してのみならず、各機器を管理する現存のに対しても、統一された考え方を提供する。
（４）ヴァーチャル・オーバーレイ・ネットワークの骨組みは、ネットワーク中のデータの変換を行なうために、トランスコーディングを広範囲に使用すべきである。これは、家庭用機器の中にはプロセッサや入出力装置のような計算機資源にしばしば重大な限界が在るためである。ある家庭用機器においては、外部システムからのデータをトランスコーディングするためのあらゆる助けがなければ、ネットワークから受け取りネットワークへ送り出す多量のデータを、直接処理できないものもあるかもしれない。
【００６５】
本実施例におけるヴァーチャル・オーバーレイ・ネットワーク22の骨組みは、家庭用の機器／サービス24、そしてアプリケーション・レベルのゲートウェイ23から構成されるが、家庭用機器24の幾つかは、まさにアプリケーション特有の装置であって、TCP/IPをサポートしていないものもある。したがって、アプリケーション・レベルのゲートウェイ23は、機器24特有のプロトコルからHTTPへの（或いはこの逆）プロトコル翻訳変換手段を機能的に備える必要がある。ここでは、各アプリケーション・レベルのゲートウェイ23は、HTTP基礎のプロキシ・サーバとして受け入れられる。それは、HTTPに基づく家庭用の機器24の制御プロトコルを受け入れ、機器24特有のプロトコルに翻訳する。さらには、機器24特有のプロトコルからインターネットへのアクセス点として、ゲートウェイ23の使用を提案する。ゲートウェイ23は、HTTPから目標となる機器24に対応するコマンドへの翻訳サービス手段を備える。またゲートウェイ23は、インターネットから、若しくはインターネットへの種々の機器の広範囲なセッション・インターフェースをエクスポートする。
【００６６】
アプリケーション・レベルのゲートウェイ23は、例えば、命名や、トランスコーディングやパケット転送などのアプリケーション特有のサービスを、種々の機器に対してサポートすべきであり、そのためにゲートウェイ23に対しては拡張性を持たせる手段を導入する。アプリケーション・レベルのゲートウェイ23は、２層から成る。上層はHTTP要求や種々のモジュールを満たすための機能から成り、種々のモジュールは確証や機器制御などのウェッブ基礎のタスクを実行する論理を提供する。このモジュラーアプローチ手段は、ゲートウェイ23としての機能を拡張する為に、追加モジュールを組み入れることが可能である。下位の層は、実際の機器にアクセスすると共に、各サービスをサポートするための骨組みを使用する。
【００６７】
ここで考慮すべきもう一つの点は、機器24の制御器である。この制御器は、HTTPに基づいた機器24の制御要求を、ゲートウェイ23に送る。制御器用には従来のウェッブ・ブラウザを使用するが、ブラウザに対するいくらかの修正を行なうことで、新たな機能を提供することができる。
【００６８】
次に、２つのシナリオを使って上記構成を具体化した例を説明する。最初のシナリオは、ウェッブ・ブラウザから家庭用機器にアクセスすることであり、二番目の例は、異なるプロトコルを使用する二つのホーム・ネットワークを繋げることである。そして最終の目的は、URL基礎のインターフェースを任意のアプリケーションやデバイスに提供することであるが、目下のところ総てのネットワーク機器をHTTPサービスに転換することはできない。その代わり、各アプリケーション・レベルのゲートウェイは、URLに基づく表現から機器用に設計された対応するコマンドへの翻訳サービスにより、それらの特別のネットワークを通じて、一個以上の機器を制御する。一般的には、ウェッブ・ブラウザは、標準のHTTP GET機構を使って問合せ要求を提示することにより、URIに一致するリモートホストにアクセスして、そのURIからの応答を受け取るか、または標準のHTTP POST機構を使ってHTML形式を通じてURIにデータを提示し、同じくHTTP内のURIから応答を受け取る。ゲートウェイ23が機器24への通信を終了した時に、終了データはブラウザへ戻される。
【００６９】
なお、具体的なURLの記述に関しては、第１実施例と同様であるのでその説明を省略する。
【００７０】
ヴァーチャル・オーバーレイ・ネットワーク22の骨組みは、３個の要素、すなわちアプリケーション・レベルのゲートウェイ23と、端末である制御器と、そして機器／サービスから成る。機器／サービスは、アプリケーション特有のものであるので、ここでは議論しない。これ以降は、アプリケーション・レベルのゲートウェイ23と制御器を説明する。
【００７１】
アプリケーション・レベルのゲートウェイ23は、図５に示す様に、機器特有のネットワーク（ホームネットワーク）とインターネット間のゲートウェイとして動作する。アプリケーション・レベルのゲートウェイ23は、前述したようにHTTPに基づく制御方法と種々のミドルウェア制御方法との間の橋渡しを行なう。
【００７２】
アプリケーション・レベルのゲートウェイ23は、４つの構成要素から成る。第一の構成要素は、HAVi,Jini或いはUPnPのようなホーム・ネットワーク・プロトコルを実行するもので、これはホーム・ネットワーク装置として動作する。例えば、もしその構成要素がJiniプロトコルを実行するならば、構成要素はJini装置として動作する。第二の構成要素はHTTPプロトコルを実行するもので、この構成要素はウェッブ・サーバとして動作する。
【００７３】
第三の構成要素はプロトコルの翻訳を実行するもので、この翻訳手段は、前述のようなHTTP処理と特殊なホーム・ネットワーク・プロトコル間の変換を行なう。例えば、HAVi翻訳手段は、HTTPプロトコルからHAViプロトコルへのまたその逆の変換を行なう。さらに現行プロトタイプの実行にて、Jiniの翻訳とUpnPの翻訳も実行される。
【００７４】
最後の構成要素は登録管理手段である。この登録管理手段は、ウェッブ・ブラウザからのHTTPプロトコル、またはプロトコルを利用している機器からのホーム・ネットワーク・プロトコルによってアクセスすることができる。もし、ホーム・ネットワーク22上にある機器24が、ホーム・ネットワーク22外からアクセスを受けたならば、機器24の名前がアプリケーション・レベルのゲートウェイ23に登録されるべきである。その名前は、HTTPプロトコルか、またはホーム・ネットワーク・プロトコルかを経由して登録される。登録後、擬似的なホーム・ネットワークデバイスが、アプリケーション・レベルのゲートウェイ23内に作成される。擬似デバイスは、自動照合サービス内に、その名前を登録する。擬似デバイスの役目は、ホーム・ネットワーク22上で送られる制御コマンドをHTTPプロトコルに変換することである。
【００７５】
次に、スタートアップ手順を説明する。アプリケーション・レベルのゲートウェイ23がスタートアップ（行動開始）する時、周囲のネットワークに参入しようとする。このネットワークで使用されるプロトコル特有のミドルウェアにより提供される方法を使って、どの装置（デバイス）若しくはどのサービスが利用可能かを調査する。例えばJiniネットワークにおいては、ゲートウェイ23は、Jiniの照合サービスを使用するであろう。この調査によって蓄積される結果は、ホーム・ネットワーク・プロトコルによって使用される属性と、HTTPに基づく方法で使用される対応コマンドとを記録するデータベースに蓄積される。
【００７６】
もし、アプリケーション・レベルのゲートウェイ23が、インターネット21からのHTTP基礎のコマンドを受け取ると、その内部にあるデータベースを参照することにより、そのコマンドを解析し、どのコマンドがどのコマンドに送られるべきかを決定した後、必要なプロトコルの翻訳を適用し、ミドルウェア特有の対応するコマンドを送り出す。一方、登録管理手段によりゲートウェイ23で作られる擬似デバイスは、機器24に特有のネットワーク装置として動作する。このことにより、アプリケーション特有のネットワーク22側にある装置が、ゲートウェイ23のインターネット21側にある装置の制御を可能にする。この様にして、ゲートウェイ23が、ホーム・ネットワーク22内にある装置に対して、あたかもインターネット21側の装置によって実際に提供される機能或いはサービスを提供するように見えることになる。
【００７７】
アプリケーション・レベルのゲートウェイ23は、HTTPサーバとして制御インターフェースを提供し、如何なるアプリケーション特有のネットワーク装置も、HTTP基礎の制御プロトコルを使っての制御が可能となる。それ故、現存のウェッブ・ブラウザを制御器25に使用することを受け入れる。近年、ウェッブ・ブラウザは、パソコンは言うまでもなく、PDA装置，携帯電話そしてデジタルTVセットに内蔵されるようになった。これらの装置は総て、アプリケーション・レベルのゲートウェイ23により、他の装置を制御する為に使用することができる。広域のブラウザが、上述の如く制御器25として使用される時、ゲートウェイ23は、自身が受け入れるであろう各コマンドにリンクしたコマンド・ボタンを含むウェッブ・ページを生成しなけばならない。一方、もし制御器25が、自身で独特のHTTP基礎のコマンドを生成するように構築されるならば、ホーム・ネットワーク環境に対するカスタマイズ性或いは適応性という点で、広範囲なブラウザ上で確実な長所を持つであろう。
【００７８】
次に、上記ヴァーチャル・オーバーレイ・ネットワークを使用して、異なるホーム・ネットワーク・プロトコルを提供する幾つかのホーム・ネットワークをどのようにして接続するのかを説明する。図５に示すように、ここでは各アプリケーション・レベルのゲートウェイ23を通じてインターネット21に接続される３つのホーム・ネットワーク22（22Ａ〜22Ｃ）を想定する。各ホーム・ネットワーク22は、それらのゲートウェイ23（23Ａ〜23Ｃ）がそれぞれ"http://any.where.net"，"http://my.home.net"，"http://foo.bar.net"というURLを有し、アプリケーション特有のプロトコル、すなわちUpnP，HAViそしてJiniを使用している。
【００７９】
一つの例として、HAViネットワーク22Ａ上にあるVCR装置31を、PDA32からUPnPネットワーク22Ｃへ制御したい場合を想定して見よう。HAViネットワーク22Ａ中で、VCR装置31は“VCR”として登録されており、そのアプリケーション・レベルのゲートウェイ23Ａ（HAVi,ApGW）は、HAViの照会サービスにおいて“apgw”として登録されている。また、UPnPネットワーク22ＣにあるPDA32は、"PDA”として登録されており、そのアプリケーション・レベルのゲートウェイ23Ｃ(UPnP,ApGW)は、UpnPの照会サービスにおいて“apgw”として登録されている。
【００８０】
そして最初に、UPnPネットワーク22ＣにあるPDA32からHAViネットワーク22Ａ上にあるVCR装置31を制御する為に、UpnPネットワーク22Ｃ中にHAViネットワーク22Ａ上にあるVCR装置31を登録する必要がある。PDA32によって、利用者はPDA32上で展開するウェッブ・ブラウザから、UPnPアプリケーション・レベルのゲートウェイ23Ｃ内に、”http://my.home.net/VCR"としてVCR装置31を登録する。これは、http://any.where.net/!register="http://my.home.net/VCR"と記述される「登録」コマンドを使用する。
【００８１】
もし、UPnPアプリケーション・レベルのゲートウェイ23Ｃが、この登録要求を受け取ると、VCR装置31に関する情報を要求する為に、HTTP基礎のプロトコルを使用してHAViアプリケーション・レベルのゲートウェイ23Ａに問合せを送る。HAViアプリケーション・レベルのゲートウェイ23Ａは、URLにより指示されたVCR装置31に関する情報を返送する。UPnPアプリケーション・レベルのゲートウェイ23Ｃ上で、VCR装置31の擬似UpnPデバイスが、HAViアプリケーション・レベルのゲートウェイ23Ａから戻ってくる情報を利用して作成される。擬似デバイスは、"VCR”という名前を持ってUpnPの通信部に結合する。PDA装置32がVCR装置31を制御したい場合は、PDA装置32は、UPnPのサービスディスカバリー機構を介してVCR装置31を発見しようとする。サービスディスカバリー機構は、UPnPアプリケーション・レベルのゲートウェイ23Ｃ上で作成された擬似デバイスに対し照会を返信する。すると制御コマンドが、UPnPプロトコルを通じて擬似デバイスに配達される。擬似デバイスは、UPnPの要求をHTTPプロトコルへ変換し、http://my.home.net/VCR"のホスト名部分に従がって、HAViアプリケーション・レベルのゲートウェイ23Ａにその要求を転送する。HAViアプリケーション・レベルのゲートウェイ23Ａは、変換されたHTTP要求を受け取り、HAVi照会サービスを通じてURLのファイル名の中で指定された”VCR”によって、実際のVCR装置31を発見する。最後に、コマンドはHAViコマンドに変換され、目標のVCR装置31へ配達される。
【００８２】
ヴァーチャル・オーバーレイ・ネットワークの骨組みを現在使用している中で、各アプリケーション・レベルのゲートウェイ23は、スタンドアロン処理として実行するJava（登録商標）・アプリケーションとして利用されると共に、家庭用機器に対するHTTP基礎のインターフェイスと、管理機器用のサービスディスカバリーシステムとを提供する。各アプリケーション・レベルのゲートウェイ23は、その受信したURLを含む属性を解釈する簡単な記憶データベースを有する。更に、JiniとUPnPのようなその基本サービスディスカバリーシステムと協同して、未知の属性を処理することもできる。
【００８３】
続いて、ゲートウェイへ送り出すコマンドと同様に、利用者の好みや個人的な認証や環境情報等のような追加情報の送り出しを可能にする制御器の拡張について説明する。HTTP基礎の制御コマンドを自分自身により発生可能な制御器が、種々の量の情報を送る為に使用されることで、制御器とゲートウェイ間の協力的関係が向上する。その様な情報の例は、利用者用にカスタマイズされた設定と環境変数を含む。ここでの制御器は、上記提案したようなコマンドを発生することのできる拡張されたウェッブ・ブラウザである。拡張されたウェッブ・ブラウザは、それが送るHTTP基礎のコマンドに内蔵させることにより、環境変数をゲートウェイに送ることが出来る。環境変数が内蔵される前のHTTP基礎のコマンドは、例えば、"http://%(HOME)/?OWNER=%(USER)&?location=%(LOC)&?function=tv/!power=on"として表わせる。このコマンドは、所有者が“利用者”であり、位置が“HOME”内の"LOC”にあるTVセットの電源をオンせよ、という意味する。制御器がそれ自身について有する環境情報を想定しよう。その利用者は、例えば"USER=foo"，"HOME=http://my.home.net/"，"LOC=living-room"ような情報を有するものとする。
【００８４】
制御器は、環境変数の始まりとして”%(“を取扱う。”%(“と”)“との間に囲まれる文字列は、環境変数の名前である。”%()”の部分は、対応する環境変数の値と置き換えられる。この場合送られるコマンドは、"http://my.home.net/?=OWNER=foo&location=living-room&function=tv/!power=on"となる。
【００８５】
制御器が持つ環境情報は、制御器そのものの位置や、制御器を現在使用している利用者や、他の環境パラメータに従って更新される。もしも、同じ制御器の同じボタンを押したとしても、ボタンが押された状況次第で、発信されるコマンドは異なっても良い。家庭用機器の制御に影響を与える為に使用できる環境情報の他の例は、天気情報、利用者の感情等であっても良い。
【００８６】
大部分の標準はオブジェクトモデルに基礎を置いているが、各標準間には多くの差がある。Jiniは、リモートサービスと各機器を統合するJavaに基づいた基盤（インフラ）である。Jiniシステムは、分散システムに於ける、サービス構築、照合そして通信の各機構を提供する。しかしながら、Jiniは多くをJava言語に頼っており、そのランタイム・システムは、大量の計算機資源を必要とし、この様な資源は家庭用では通常極度に限定される。UPnP(ユニバーサル・プラグ・アンド・プレイ)は、パソコンと機器間のピアー・ツー・ピアー・ネットワーク接続を供給する構成である。UPnPは、装置をダイナミックにネットワークに参加させ、自身にIPアドレスを割り当て、自身存在と要求に応じる能力を有する。UPnPは、TCP/IPとウェッブ技術に基礎を置き、家庭や事務所に於いてネットワーク化された装置間での制御とデータ伝送に加えて、シームレスな近接ネットワークを可能にする。しかしながら、UPnPはXMLファイルにおける各機器の特徴と能力を発揮するように図られている。XMLに基礎を置いたプロファイルは、Jiniの簡単なサービス属性に反して、機器能力の複雑な手間の掛かる説明が必要であるので、家庭用の機器がXMLファイルを解釈するのは困難である。
【００８７】
HAVi(Home Audio Video Interoperability)は、デジタル音響、映像の消費者用機器を、シームレスに接続するためのホーム・ネットワーク標準を提供する。HAViはまた、そのプログラム内からの各機器への制御を可能にするAV機器制御用Java APIをもまた提供する。HAViは、十分な帯域幅を持ちデジタル音響、映像の多数の信号流を伝送できるIEEE1394ネットワーク・インターフェーイスを各機器が有することを仮定している。しかしながら、こうした要求は、種々の型の機器でHAViが広く使用されることを阻害している。
【００８８】
将来の家庭用機器において、それらの製造業者の方針による各種異なる標準を、支援することが期待されている。しかしながら、これらの標準は、多様なホーム・ネットワークをサポートするものではない。ここで提案したヴァーチャル・オーバーレイ・ネットワークは、総ての家庭用機器が互いに接続され制御することを可能にする。
【００８９】
OSGi(The Open Services Gateway specification)は、Javaに基礎を置くアプリケーション層の骨組みであり、サービス提供者、装置メーカーそして機器製造業者に、業者には中立のアプリケーションと装置層APIと機能を提供する。この戦略は、事実上、出現する総てのホーム・ネットワーク基盤、プロトコルそしてサービスを、現存する住宅電話線、ケーブルTV或いは電線を使って、バックエンド・サービスとのシームレスな相互作用を可能にする。この技術は、基盤から独立している必要があり、その結果、種々の計算機環境、通信環境、消費者向けエレクトロニクスそして家庭用製品と基盤上での使用が可能となる。オープン・サービス・ゲートウェイ仕様は、オープン・システム層とサービス・ゲートウェイ向けのゲートウェイ・インターフェイスの提供に専門的に焦点を当てるので、現在のネットワーク標準と企業心を補足し向上させる。これらの内幾つかは、Jini,ブルートゥース,CAL,CEBus,HAVi,Home API,HOME-PAN,HomePnP,HomeRFそしてVESAを含んでいる。
【００９０】
オープン・サービス・ゲートウェイ仕様はまた、将来の高機能家庭用装置における消費者の投資を維持する。例えば、今日において、消費者がホームセキュリティプロバイダを別のプロバイダに切り替える時、内部ネットワークの総てを入れ替えなければならない。オープン・サービス・ゲートウェイ仕様と互換性のある装置を選択することにより、消費者は、事実上如何なるネットワーク基盤を入れ替える必要無しに、種々の業者の商品間で、どれにでも切り替えできる。
【００９１】
OSGiの利点は、拡張性のあるホーム・ゲートウェイを構築する為の骨組みを提供することにある。拡張性のあるアプリケーション・レベル・ホーム・ゲートウェイを履行する為に、この標準が採用される。
【００９２】
上記実施例では、ネットワークされた家庭機器を統合するヴァーチャル・オーバーレイ・ネットワークを提案してきた。ヴァーチャル・オーバーレイ・ネットワークは、メッセージの伝達ルートを決定し、ネットワークと機器の特性に従がってプロトコルとメッセージを変換する。ヴァーチャル・オーバーレイ・ネットワークは、インターネット規模のユビキタス・コンピューティングの実行に非常に有益である。
【００９３】
またIP層は、ヴァーチャル・オーバーレイ・ネットワークの構築に必要な機能性を提供すべきであって、複雑な通信を必要とするそれぞれの機器に対して、ヴァーチャル・オーバーレイ・ネットワークがカスタマイズされる。この機能性の大部分は、IP層の上位で実行されるべきで、さらにそれぞれの機器に対してカスタマイズされるべきである。したがって、IP層における機能のサポート（支援）は最小化されるべきで、広域な方法でIP層に幾つかの進歩した機能を与えることは避けるべきである、何故ならば、IP層で実行される機能は、余りにも広範囲過ぎ、実際の進歩したアプリケーションを構築するには力不足だからである。
【００９４】
なお、本発明は上記実施例に限定されることなく、本発明の範囲内で種々の変形実施が可能である。
【００９５】
【発明の効果】
本発明の請求項１の構成によれば、ウェブ・サーバを有する家庭用の機器を修正することなく、複雑なホーム・コンピューティング環境を作るのに必要なディレクトリサービスや自動構成管理と同様の機能を持つことが可能になる。
【００９６】
また、機器統合のためのネットワーク構築装置によれば、HTTPプロトコルに基づいたユビキタス・コンピューティング環境の構築を達成できる。
【図面の簡単な説明】
【図１】本発明の第１実施例を示すネットワーク構築装置の全体構成をあらわした概略説明図である。
【図２】同上機器を特定し制御するためのURL記述の一例を示す図である。
【図３】同上図１におけるネットワーク構築装置を発展させた例を示す概略説明図である。
【図４】本発明の第２実施例を示すネットワーク構築装置の概略説明図である。
【図５】同上インターネットとホームネットワークを繋ぐゲートウェイの機能構成を示す概略説明図である。
【図６】同上ホームネットワークの接続形態を示す概略説明図である。
【符号の説明】
１ 通信手段（ネットワーク網）
２ 機器
３ HTTPクライアント（端末）
４ ゲートウェイ・サーバ
11 PDA装置（端末）

Claims (1)

1. 利用者が保有する端末と、
   ウエッブサーバーを内蔵した制御対象となる機器とを接続したネットワーク網にゲートウェイ・サーバを接続し、
   このゲートウェイ・サーバは、現在利用可能な機器の情報を自動的に収集して、その内容を前記端末に提示する自動構成管理手段と、
   前記端末から目標となる機器を制御するコマンドが発信されると、このコマンドに含まれるURLを翻訳して目標となる機器を制御するためにURLでアクセスする機器アクセス手段と、
   前記ネットワーク網上の接続可能な全アドレスに対して周期的にHTTPプロトコルによる問合わせメッセージを送る検索手段とを備え、
   前記機器は与えられた有効期限内で前記検索手段からの前記問合わせメッセージを受取ると、自身の前記有効期限と、前記 URL に基づく形式で形成された利用可能な前記コマンドとからなる情報を前記検索手段へ返送し、
   前記検索手段は前記情報をデータベースへ登録するか、或いは前記データベースを更新して、前記情報内で特定された前記有効期限内に前記機器に対して前記問合わせメッセージを送り、
   前記端末からの発見要望を受けた場合、前記検索手段はフルテキスト検索技術を使って前記データベースから現在利用可能な機器を選び出す
   ことを特徴とする機器統合のためのネットワーク構築装置。

Images