TOP > 国内特許検索 > 機器統合のためのネットワーク構築装置 > 明細書

明細書 :機器統合のためのネットワーク構築装置

発行国 日本国特許庁(JP)
公報種別 特許公報(B2)
特許番号 特許第4118566号 (P4118566)
公開番号 特開2003-208366 (P2003-208366A)
登録日 平成20年5月2日(2008.5.2)
発行日 平成20年7月16日(2008.7.16)
公開日 平成15年7月25日(2003.7.25)
発明の名称または考案の名称 機器統合のためのネットワーク構築装置
国際特許分類 G06F  13/00        (2006.01)
G06F  15/00        (2006.01)
H04L  12/28        (2006.01)
H04L  12/46        (2006.01)
FI G06F 13/00 358A
G06F 15/00 310C
H04L 12/28 100H
H04L 12/28 200M
H04L 12/46 100C
請求項の数または発明の数 1
全頁数 21
出願番号 特願2002-008358 (P2002-008358)
出願日 平成14年1月17日(2002.1.17)
審査請求日 平成17年1月13日(2005.1.13)
特許権者または実用新案権者 【識別番号】899000068
【氏名又は名称】学校法人早稲田大学
発明者または考案者 【氏名】中島 達夫
【氏名】佐藤 一郎
個別代理人の代理人 【識別番号】100080089、【弁理士】、【氏名又は名称】牛木 護
【識別番号】100081260、【弁理士】、【氏名又は名称】染川 利吉
【識別番号】100119334、【弁理士】、【氏名又は名称】外山 邦昭
審査官 【審査官】石井 茂和
参考文献・文献 特開平11-187061(JP,A)
特開平10-191463(JP,A)
特開2000-250838(JP,A)
特開2001-067313(JP,A)
特開2001-282648(JP,A)
特開平05-250413(JP,A)
特開2001-331398(JP,A)
特開2001-331394(JP,A)
特開平09-312646(JP,A)
特表平11-510978(JP,A)
デジタル情報家電の接続を考慮した家庭ネットワークアーキテクチャ,電子情報通信学会技術研究報告,1997年11月 6日,Vol.97 No.368
佐藤豊,多目的プロキシ・サーバDeleGateの機能詳細,インターフェース,日本,CQ出版株式会社,1995年 9月 1日,第21巻 第9号,p130-146
リカルド・ディ・ジョルジオ,URIによるデバイス・アクセス仕組み,Java WORLD,日本,株式会社IDGコミュニケーションズ,1999年11月 1日,第3巻 第11号,p76-83
調査した分野 G06F 13/00
G06F 15/00
H04L 12/28
H04L 12/46
WPI(DIALOG)
JCHEM(JDreamII)
特許請求の範囲 【請求項1】
利用者が保有する端末と、
ウエッブサーバーを内蔵した制御対象となる機器とを接続したネットワーク網にゲートウェイ・サーバを接続し、
このゲートウェイ・サーバは、現在利用可能な機器の情報を自動的に収集して、その内容を前記端末に提示する自動構成管理手段と、
前記端末から目標となる機器を制御するコマンドが発信されると、このコマンドに含まれるURLを翻訳して目標となる機器を制御するためにURLでアクセスする機器アクセス手段と、
前記ネットワーク網上の接続可能な全アドレスに対して周期的にHTTPプロトコルによる問合わせメッセージを送る検索手段とを備え、
前記機器は与えられた有効期限内で前記検索手段からの前記問合わせメッセージを受取ると、自身の前記有効期限と、前記URLに基づく形式で形成された利用可能な前記コマンドとからなる情報を前記検索手段へ返送し、
前記検索手段は前記情報をデータベースへ登録するか、或いは前記データベースを更新して、前記情報内で特定された前記有効期限内に前記機器に対して前記問合わせメッセージを送り、
前記端末からの発見要望を受けた場合、前記検索手段はフルテキスト検索技術を使って前記データベースから現在利用可能な機器を選び出す
ことを特徴とする機器統合のためのネットワーク構築装置。
発明の詳細な説明 【0001】
【発明の属する技術分野】
本発明は、種々の家庭用機器や個人用機器をURLアドレスで統合管理する機器統合のためのネットワーク構築装置に関する。
【0002】
【発明が解決しようとする課題】
将来の生活において、周囲には益々多くのプロセッサが内蔵されることが予測され、具体的にはアナログ無線回路や種々のセンサが、プロセッサと一体化されるだろうし、種々のコンピューティング機能が周囲環境に内蔵されるであろう。とりわけ、コンピュータが「コンピュータ」という特殊な箱として1箇所に存在するのではなく、人間の生活環境の至るところに分散して存在するユビキタス(Ubiquitous:どこにでもある)・コンピューティング環境が、ハードウェアの観点から、まもなく実現され得るであろう。
【0003】
ユビキタス・コンピューティング環境は、実世界で活動する人間を無意識に支援するもので、その人間のおかれている環境を認識する必要があるが、こうしたユビキタス・コンピューティング環境において、家庭内では種々の内蔵プロセッサが増加すると考えられる。これにより、種々の家庭機器の制御が可能となり、種々の情報を検索して、我々の嗜好や周囲情報に従って機器を動作させることが可能になる。例えば、テレヴィジョンの様な音響映像機器が、IEEE1394のような標準の高速ネットワークにより接続されるであろう。また、部屋の中にある照明やエアー・コンディションは、無線ネットワークを通じて、携帯電話やPDA機器により制御されるであろうし、家具にプロセッサが内蔵されるかもしれない。最終的には、これらのネットワークがホーム・ゲートウェイにより一体化されるであろう。
【0004】
しかしながら、ソフトウェアの観点から見ると、生活の向上を図るために種々の家庭機器を一体化するには、ミドルウェアの構成要素が必要である。ミドルウェアとは、いわゆるOS(Operating System)上で動作し、アプリケーションソフトに対してOSよりも高度で具体的な機能を提供するソフトウェアのことで、OSとアプリケーションソフトの中間的な性格を持っているが、現在、広範囲に利用されるであろうミドルウェア構成要素を構築するのは簡単なことではない。例えば、ネットワークを通じて各種機器を接続し、相互に機能を提供しあうための技術仕様であるJini(登録商標)や、同じように家庭内のパソコンや周辺機器、AV機器、電話、家電製品などの機器をネットワークを通じて接続し、相互に機能を提供しあうための技術仕様であるUPnP(ユニヴァーサル・プラグアンド・プレイ)は、ミドルウェアとして良く知られているが、これらのミドルウェアを採用している機器は少ない。一方、HTTPプロトコルは、近い将来に種々の機器に広く組み込まれるものと思われ、現在のプロセッサにおけるインターネット・プロトコルを実行するには費用が極めて安い。それ故に、将来の殆どの機器は、HTTPサーバを内蔵して、インターネット上の如何なる場所からでも機器をアクセスできるようになるであろう。
【0005】
具体的には、近い将来において、プロセッサはインターネット・プロトコルを実行するハードウェア・アクセラレーターを包含し、非常に低価格でウェッブ・サーバを導入するであろう。ウェッブ・サーバは、種々の機器に内蔵され、周囲にある実物対象は、情報を実物対象に結びつけるためのURLを包含する。これらのシステムは実物対象を増加させ、或いは実世界と仮想世界とを統合する。また、エミット・テクノロジーの様なウェッブ・テクノロジーを採用した商品も出ている。このように、近い将来ウェッブ・サーバを内蔵した機器が出現するものと思われる。
【0006】
ホーム・コンピューティング環境としては、ウェッブ・サーバ内蔵のテレヴィジョン,ヴィデオ・カセット・レコーダ,照明及び電子レンジのような種々の機器を含むと考えられる。これらの機器は、どのウェッブ・ブラウザーからでも、或いはHTTPプロトコルを使用するアプリケーション・プログラムから制御できる。例えば、ウェッブ・サーバを内蔵したテレヴィジョンは、ウェッブ・サーバからの診断を業者が行なうことができる。故に、遠隔で家庭機器を容易に管理することができる。また、ウェッブ・ブラウザーから室内の照明が制御可能である。こうした状況は、安価なホームオートメーションシステムを構築させることになる。
【0007】
しかしながら、現在のHTTPプロトコルは複雑なホーム・コンピューティング環境を作るのに必要なディレクトリサービス(ネットワーク上の資源とその属性とを記憶し、検索できるようにしたシステム)や自動構成管理(Automatic Configuration Management)のような必要な機能を提供できないという問題がある。
【0008】
TV(テレヴィジョン)やVCR(デジタルビデオカメラ)の様な種々の家庭用機器はホーム・ネットワークに接続され、総てのホーム・ネットワークは、種々の情報を交換し他の機器から別の機器を制御するために、インターネットにより統合することができる。将来のネットワークは、極めて膨大な数の機器を接続可能であるので、これらの機器は利用者の観点からすると、一個の機器として統合されるべきである。この種の統合は、膨大な量の機器が、インターネットに接続されることを期待されているので、近い将来に非常に重要になる可能性がある。
【0009】
こうした種々の機器が相互に接続されているコンピューティング環境は、前述のユビキタス・コンピューティング環境と呼ばれる。しかしながら、ユビキタス・コンピューティング環境の従来の考え方は、インターネットに比較した場合少々規模が限定されており、インターネット規模のユビキタス・コンピューティング環境を設計しようとする場合には、更にある問題を考慮する必要がある。
【0010】
種々のネットワークとプロトコルが、各アプリケーションのドメイン用に提案されてきた。例えば、前述のJiniやUPnP(ユニヴァーサル・プラグアンド・プレイ)の様な種々のプロトコルは、使用前の構成無しに、種々の機器を接続するために提案されてきた。また、別なプロトコルであるHAViは種々の家庭用音響映像機器に特化して、その接続のために提案されてきた。一方、ATM(非同期転送モード)ネットワーク,IEEE1394,携帯情報機器向けの無線通信技術として知られるブルートゥース(登録商標),そしてVIAの様な種々のネットワーク・システムが、種々の機器を接続するために開発されてきた。また、研究団体に於いて、PEN,ネットワークド・サーフェスそしてCLANは、将来の進歩した機器を接続するために提案されてきた。
【0011】
しかしながら、これらの基本的なプロトコルとネットワークのもつ種々の有益な特性は、IP層がネットワークに挿入されるならば、アプリケーションから隠されてしまう。例えば、ブルートゥースにより提供されるプラグ・アンド・プレイ機能とATMにより提供されるネットワークバンド幅保存機能は、通常IP層(注:QOS保証するIPプロトコルを拡張する幾つかの提案がなされているが、この提案によって提供されるアブストラクションは、ATMのバンド幅保存能力の全部は提供しない)の最上層で通常利用できない。また、ある機器のなかには、他の機器やサービスに接続するためのIP層を支援(サポート)しないものもある。更に、各機器は、互いに通信する為に異なる制御プロトコルやデータ・フォーマットを想定するかもしれない。それ故、新しい手法が、将来の家庭用機器のために、ネットワーク支援を実現する必要がある。
【0012】
過去にインターネットに関する種々の問題を解決するために、ヴァーチャル・オーバーレイ・ネットワークが利用されてきたが、ネットワーク化された家庭用機器の統合の為にヴァーチャル・オーバーレイ・ネットワークを適用する考えには及んでいない。すなわち、組織的な手法で、インターネット規模のユビキタス・コンピューティング環境を得るために、カスタマイズされたヴァーチャル・オーバーレイ・ネットワークを構築する必要がある。
【0013】
そこで本発明は、ウェブ・サーバを有する家庭用の機器を修正することなく、複雑なホーム・コンピューティング環境を作るのに必要なディレクトリサービスや自動構成管理(Automatic Configuration Management)と同様の機能を持つことができる機器統合のためのネットワーク構築装置を提供することをその目的とする。
【0014】
【課題を解決するための手段】
本発明の請求項1における機器統合のためのネットワーク構築装置は、利用者が保有する端末と、ウエッブサーバーを内蔵した制御対象となる機器とを接続したネットワーク網にゲートウェイ・サーバを接続し、このゲートウェイ・サーバは、現在利用可能な機器の情報を自動的に収集して、その内容を前記端末に提示する自動構成管理手段と、前記端末から目標となる機器を制御するコマンドが発信されると、このコマンドに含まれるURLを翻訳して目標となる機器にURLでアクセスする機器アクセス手段と、前記ネットワーク網へ周期的にHTTPプロトコルによる問合わせメッセージを送る検索手段とを備え、前記機器は与えられた有効期限内で前記検索手段からの前記問合わせメッセージを受取ると、自身の情報を前記検索手段へ返送し、前記検索手段は前記情報をデータベースへ登録するか、或いは前記データベースを更新して、前記情報内で特定された前記有効期限内に前記機器に対して前記問合わせメッセージを送り、前記端末からの発見要望を受けた場合、前記検索手段はフルテキスト検索技術を使って前記データベースから現在利用可能な機器を選び出す構成とされる。
【0015】
この場合、HTTPプロトコルに基づくネットワークで各機器を統合するのに必要な機能が、自動構成管理手段と、ディレクトリ・サービスに相当する機器アクセス手段としてゲートウェイ・サーバに備えてあるので、ウェブ・サーバを有する家庭用の機器を修正することなく、複雑なホーム・コンピューティング環境を構築することが可能になる。
【0016】
また、機器統合のためのネットワーク構築装置は、HTTPプロトコルを使用して前記機器の制御を可能にし、その動作を利用者の状況に応じて変化させる状況認知機器制御手段を前記ゲートウェイ・サーバに備えたものである。
【0017】
このようにすると、HTTPプロトコルに基づいたユビキタス・コンピューティング環境の構築を達成できる。
【0018】
【発明の実施形態】
以下、添付図面を参照しながら、本発明における好適な各実施例を順に説明する。図1~図3は、本発明の第1実施例を示す機器統合のためのネットワーク構築装置である。
【0019】
先ず詳細な構成を説明する前に、本システムの設計で最も重要な基本的概念とは、ウエッブ・サーバを有する家庭用機器を修正せず使用することにある。ウエッブ・サーバを有する汎用の家庭用機器は、自身が保有するウエッブ・サーバの修正ができないのであるが、かといって新しいプロトコルを標準化するのは非常に難しい。しかし、通常の人々はホームネットワークがどのようにして形成されるのかを知らないので、ホームコンピューティング環境を構築するには、JiniやUpnPに見出される自動構成(コンフィギュレーション)管理がサポートされなければならない。
【0020】
従来のウェッブに基づく環境では、利用者はアクセス前に、各機器のURLを知る必要があった。しかし、利用者がアクセスしたい機器のURLを見付けるディレクトリ・サービスが何も存在しないので、そのURLを知ることは容易ではない。また、このディレクトリ・サービス内における各機器に対するURLを登録するのに自動構成管理を必要とする。
【0021】
図1は、各家庭用機器を統合することが可能なネーミング(命名)管理を提案するシステム全体の構成で、1はインターネットを実現するための通信手段、2はこの通信手段に接続する複数の家庭用機器である。また3は、HTTPプロトコルの下で利用されるHTTPクライアントで、具体的には家庭でインターネットを利用する際のパソコン(パーソナルコンピュータ)などがこれに相当する。
【0022】
ここでのシステムは、二個の構成要素から成っている。第一の構成要素は、ウェブベース環境内に組み込まれる機器2である。この機器2は、ウェッブ・サーバを備えており、IEEE802.11b, ブルートゥース,IEEE1394或いはイーサーネットなどの標準ネットワークを通じて、インターネットネットワークを構築する通信手段1に接続されている。ここに提案するシステムは、各機器2におけるウェッブ・サーバの拡張を想定していない。したがって、ウェッブ・サーバを含む汎用製品のどれでも通信手段1に接続して使用できる。
【0023】
第二の構成要素は、家庭用の機器2を管理するために設けられゲートウェイ・サーバ4である。このゲートウェイ・サーバ4は、目標となる機器2へのアクセス方法を提供するディレクトリ・サービスの役割を演じるもので、さらに現在利用できる機器2を維持管理する自動構成管理としての機能も備えている。
【0024】
図1に示すホームネット利用者が、部屋の中にある家庭用の機器2にアクセスしたい時は、先ずHTTPクライアント3を利用してゲートウェイ・サーバ4と接触する。ゲートウェイ・サーバ4は、部屋の中にある利用可能な機器2に関する情報を利用者に提供する。利用者の観点からすると、その利用者はゲートウェイ・サーバ4のIPアドレスを含むURL(Uniform Resource Locator:インターネットにおける情報の「住所」)を使って、機器1を制御するための要求を発するので、利用者にとって如何なる家庭機器もゲートウェイ・サーバ4に直接接続されているように見える。ゲートウェイ・サーバ4は、機器2のウェッブ・サーバから集められる情報に従って、適正な機器2に向かってその要求を転送する。
【0025】
次に、各機器2を制御するためにどのようにしてURLを特定するのかについて説明する。ここでの最終目標は、任意のアプリケーションやデバイスに対しURLに基づくインターフェースを提供することである。ウェッブ・ブラウザーは一般的に、標準のHTTP GET機構を使って問合せ要求を提示することにより、URI(Uniform Resource Identifiers :インターネット上に存在する情報資源の場所を指し示す記述方式で、URLはURIの機能の一部を具体的に仕様化したもの)に一致するリモートホストにアクセスして、そのURIからの応答を受け取るか、または、標準のHTTP POST機構を使ってHTML形式を通じてURIにデータを提示し、同じくHTTP内のURIから応答を受け取る。利用者によって通過されるURLは、以下に示すように翻訳され、その要求は目標の機器2に転送される。
【0026】
図1に示すシステムにおいて、利用者はHTTPに基づくプロキシ・サーバとして与えられたゲートウェイ・サーバ4を通して、一つまたはそれ以上の機器2にアクセスできる。しかしながら、ゲートウェイ・アドレスが判っているときでさえも、利用者が機器2の中から最適の機器2の一つを確認することは難しい。そこで、機器2を特定し制御するためのURLに基づいたネーミングの取り決めをここで行なう。この取り決めは、標準のURL内で定義するが、URL形式のパス・エレメントは、図2に示す如く、BNF(バッカス記法)に似た構文に従って、幾つかの追加情報を含むことができる。
【0027】
ここで、<path>::=の次にある文字「ε」は、文字列の存在しないempty string を意味し、<string>は一連のアルファベットに対応する。<search>::=の次にある文字「?」の属性は、問い合わせ式を表し、フィールドが(場所或いは所有者と云った)問い合わせの性質を記述する場合には、一組のフィールド値であり、一個の値は文字列または整数である。「!」の属性は、フィールドがコマンドの性質を記述する場合はそのコマンドを特定すると共に、その値は文字列または整数である。
【0028】
上記取り決めによれば、例えば"http://some.where.com.8080/CEIL-LIGHT/!power=ON"なるURLの記述として表わせる。このURLの記述では、事前の同意によりポート番号8080で聞いているsome.where.com. と命名されたゲートウェイが呼び出される。その次の"CELL-LIGHT"の要素は、ゲートウェイの下で制御される電灯を特定するものである。"!power=ON"の要素は、ゲートウェイに対し信号を送ると共に、機器2別にON値を備えた"power"と命名される特別の機能を指名する。このURLは、"CELL-LIGHT"として命名された電灯をオンするための要求である。
【0029】
もう一つの例として、"http://some.where.com/?location=room1&?function=light/!power=ON"を示す。
【0030】
この例の中で、"?location=room1"の要素は、ゲートウェイ・サーバ4の下で制御されるビルまたはフロア-の"room1"と呼ばれる場所を特定している。また「?function=light」の要素は、room1の場所で機能的に命名された"light"をサポートする最適な機器2の一つを特定している。そして、このURLも、"light"として命名された電灯をオンするための要求である。
【0031】
この様な最適な機器2をダイナミック(動的)に特定するために、ここで取り決めたURLは、"$(variable)"の形式を含むことができる。なお"variable"は、その値が文字列である可変名を示す。これらの変数は、ゲートウェイ・サーバ4上で実行するシェルプログラム或いはオぺレーティングシステム(OS)により提供される環境変数と関連付けられる。URLに基づく表記法に対する変数の概念は、G.Voelker氏およびB.Bershad氏による「モビザイク:モバイル無線コンピューティング環境用の情報システム(モバイルコンピューティングシステムおよびアプリケーションにおけるワークショップ議事,1994年IEEEコンピュータ学会)」において手法されたダイナミックURLに基づく手法により、もとは示唆されたものである。ダイナミックURLの変数は、利用者側のコンピュータ(HTTPクライアント3)上で実行するシェルプログラムまたはオぺレーティングシステム(OS)によって、提供される環境変数と常に関連をもたなければならないが、ここで提案される変数は、ゲートウェイ・サーバ4でダイナミックに解釈される。
【0032】
例えば、"http://some.where.com/$(LIGHT)/!power=ON"と記述された上記変数を含む拡張したURLを考える。
【0033】
ここで、"$(LIGHT)"なる要素は、電灯を特定する一つの変数である。ゲートウェイ・サーバ4内に維持管理される前記"LIGHT"の変数が、天井に取り付けられた電灯を特定するCELL-LIGHTである時、上述のURLは"http://some.where.com/CEIL-LIGHT/!power=ON"として解釈される。新しい電灯が部屋に取り付けられる場合、オぺレーティングシステム(OS)は"LIGHT"環境変数の値を更新してもよく、その値が現状の環境で最適な物の一つとして見なされる。従がって、物の移動は、現状の環境に対しダイナミックに適合することが可能である。
【0034】
次に、機器2にアクセスする機構、すなわちディレクトリ・サービスについて説明する。本実施例におけるディレクトリ・サービスは、通信手段1に接続した現在利用可能な家庭用の機器2に関する情報を提供することである。また、機器へのアクセス方法をも提供する。ウェッブ基礎のホーム・コンピューティングにおける重大な問題の一つは、利用者が制御したい機器2のURLを如何にして知るかということである。その際、ゲートウェイ・サーバ4は、利用者がHTTPクライアント3にて保有するブラウザに対して、機器2を制御する為のURLを含むHTMLページを返してもよい。しかしながら、利用者のHTTPクライアント3にて保有するプログラムから機器2にアクセスすることは容易ではないので、この手法は望ましいものではない。それ故に、本実施例のシステムでは、機器2が利用者から直接ゲートウェイ・サーバ4に接続されている様に見せる機構を提供する。これは、利用者側のHTTPクライアント3がゲートウェイ・サーバ4のホスト名と機器2の名前を知る必要があることを意味する。
【0035】
本システムによるこの手法は、各機器2のIPアドレスを知らなくても、通信手段1を介したインターネット上の如何なる場所からでも、利用者自身の家庭内の機器2を制御可能である。それ故に、利用者がIPアドレス或いは予め各機器2のホスト名を知っていることを仮定する必要はない。また、ここでは最新のダイナミックDNS(Domain Name System :インターネット上のホスト名とIPアドレスを対応させるシステム)の使用を考えなくても良い。DNSの更新は、総ての家にDNSサーバを導入する必要があるが、このことは、DNSの設置がインターネットに関する多くの知識を必要とするため実際的ではない。更に、ここでのシステムの手法は、利用者のHTTPクライアント3が直接機器2にアクセスする必要はない。このように、ゲートウェイ・サーバ4は、あらゆる要求の確認を照合することができる。それゆえに、我々の手法はまた従来のウェッブ基礎のホーム・コンピューティングのセキュリティ性を向上するものである。
【0036】
ゲートウェイ・サーバ4は、後述するウェッブ・ロボット(機器2に備えたウェッブ・サーバを自動的に巡回してデータを収集する)により構築された地図データベースを保存するデータベース記憶部を備えている。要求を受け取ると、URLのファイル部が調べられ、コマンド部が取去られる。それから、URLの残りのフィールドによってデータベースが検索される。データベースが新しいURLを返し、前段階で除去されたコマンド部が連結される。それから、目標の機器2がそのURLを使用してアクセスされる。
【0037】
こうした技法は、URL書き換えと呼ぶ。例えば、"http://www.gw.tatsuo.tokyo.jp/TV/!channel=10/"というURLについて考える。このURLは、「私は、私の家のテレビチャンネルを10にセットしたい」ことを意味している。ゲートウェイ・サーバ4は、自身の保有するデータベースの検索により、家の中にあるそのテレビのIPアドレスが123.5.10.10であることから、URLを"http://123.5.10.10/!channel=10/"に翻訳して書き換える。このことは、ゲートウェイ・サーバ4内に家庭内の機器2とIPアドレスとを関連付ける情報があれば、利用者は実際のIPアドレスを知る必要の無いことを意味する。
【0038】
総ての機器2は、それらの処理能力、記憶容量、バンド幅そして電力に限界があるため、複雑化して能動的になるものと予期されてはいなかった。それ故、各機器2に内蔵されているソフトウェアは、極力小さく単純化されなければならない。しかしながら、例えばUpnPやJiniのような機器2に対する現存の管理技術は、記憶容量と計算能力の必要性の点から極めて重量が重く、大部分の機器では使用できない。したがってここでは、能力の低い機器を発見できる軽量の機構を必要とする。この手法は、そうした機構のような検索手段すなわちウェッブ検索エンジン(インターネットで公開されている情報をキーワードなどを使って検索できるWebサイト)をゲートウェイ・サーバ4に導入する。このエンジンは、各機器2から集められた情報のデータベースを維持管理し、利用者がウェッブ検索技術によって必要とする関係の機器を発見することができる。
【0039】
各ウェッブ検索エンジンは、機器2の固有識別子と動作時間を記録し、自身のインデックスを更新化するために、特定の間隔でサブネットワーク上の可能な全アドレスに対しHTTP GET要求を周期的に送る。ゲートウェイ・サーバ4からの要求を受け取ったとき、機器2は、それ自身の2個のプロファイル、有効期限そしてここで詳述したURLに基づく形式で形成された利用可能なコマンド名を返答する。もし、ゲートウェイ・サーバ4のエンジンが動作中に機器2から何らかの応答を受けた場合、エンジンはデータベースから応答の無いの機器の登録を抹消する。更にこの手法は、一個以上のエンジンがネットワーク上で動作することを可能にする。いわゆるピアツーピアの手法で、 エンジンは互いに接続しあうことができる。各エンジンは、集められた情報に対し索引付けされた問合せインターフェイスを提供すると共に、他のエンジンから情報を回収したり、自身のインデックスの更新を増やすことができる。
【0040】
この機構は、JiniやUpnPの様にプラグ・アンド・プレイ方式で自動的に機器2を組み込むことができる。新規にネットワークに接続される機器2におけるインストール、若しくは再動作される登録済み機器2における再インストールの作業を考えると、各エンジンは、それがカバーするネットワークへ周期的にHTTP基礎の問合わせメッセージを沢山送るので、その機器2は与えられた間隔内でエンジンからのメッセージを受取り、自身の情報をエンジンへ返送する。次に、エンジンはその情報を自身のデータベースへ登録するか、或いはデータベースを更新して、次にその情報内で特定された有効期限で機器2に問合わせメッセージを送る。利用者または他のホストからの発見要望を受けた場合、そのエンジンは、現状のウェッブ検索エンジンで使用されているフルテキスト検索技術を使ってデータ・ベースから適当な機器を選び出す。故に、この機構は、容易にかつ自然にHTTP内での動作が可能である。各エンジンは、機器2の管理および発見に対し信頼をおけるので、機器2は無籍(Stateless)なHTTPとして扱うことができる。
【0041】
現行アーキテクチャ(基本設計概念)における問題点の一つは、各機器2のURLを如何にして知るかということである。利用者がHTTPクライアント3から目標の機器2を制御したい場合、URLの構文を知らねばならない。将来のコンピューティング環境において、機器2をいかに制御すべきかという情報を含む電気的タグを添付することが可能である。例えば、照明を点けることを意味するバーコードを付ける事が出来る。そのバーコードは、パーソナル機器により照明をオンすると読み込まれる。URLは、そのURLを含んだビーコンを受け取ることによってアプリケーションから検索されてもよいし、またRFID(Radio Frequency ldentification :無線周波による非接触自動識別器)がバーコードの代わりに使われても良い。
【0042】
ここでの解決法は、URLを発見するパーソナル機器の使用である。このパーソナル機器は、URLを含むバーコードを読み込んだり、ビーコンを受取ることができる。パーソナル機器がバーコードを読む場合、そのIDがゲートウェイ・サーバ4の中にあるバーコード管理手段すなわちバーコード・マネージャーへ転送される。バーコード・マネージャーは、受け取ったIDを実際のURLに変換し、目標の機器2へコマンドを送る。また、パーソナル機器がビーコンを受信した場合は、ビーコン中のURLは、ゲートウェイ・サーバ4に転送される。この手法によって、システムを使用する場合に、種々の機器2の制御を容易に行なうことができる。
【0043】
次に、図1における装置構成を発展させた例を図3に基づき説明する。ここでは、システムが如何に動作するかを一つのシナリオで示している。シナリオの中では、利用者は機器2の遠隔制御手段としてのPDA装置(Personal Digital Assistance:個人用携帯情報端末)11を保有していて、家の中には3個の機器2、すなわちここでは映像音響機器に相当するテレヴィジョン12と、家電機器に相当する電子レンジ13と、照明手段としてのライト13が、ホームネットワークを構築する通信手段1に接続される。これらの機器2の総ては、ウェッブ・サーバを内蔵していて、ゲートウェイ・サーバ4は上述したようなウェッブ・ロボット手段を実行するプログラムを使って、現在利用可能な機器2に関する情報を集める。例えば、テレヴィジョン12はウェッブ・サーバにアクセスする為のURLを持つ情報を返信し、ゲートウェイ・サーバ4は、自身のデータ・ベース中にその情報を保存する。
【0044】
PDA装置11がWebページ閲覧手段であるウェッブ・ブラウザを起動して開くとき、最初のHTTP GETの要求がゲートウェイ・ウェッブ・サーバ4によって探し当てられる。PDA装置11のウェッブ・ブラウザは、家の中で現在利用可能な機器2のリストを含むHTMLページを、インターネット上でワイヤレスアクセスポイント15を介して返信する。そのHTMLページは、ウェッブ・ロボット手段を実行するプログラムによって集められた情報を利用して、ゲートウェイ・サーバ4により自動的に生成される。
【0045】
利用者が、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"と翻訳される。このことは、利用者が、自分の家にあるゲートウェイ・サーバ4のIPアドレス或いはホスト名を知らずに、自分の家のテレヴィジョン12にアクセスできることを意味する。しかもこのアドレスは、本システムによって自動的に検索される。また、“http:// www.tatsuo.tokyo.jp/TV/"は、"http://tv.tatsuo.tokyo.jp/"と翻訳される。このことは、利用者は、自分のテレヴィジョン12における実際のIPアドレスやホスト名を知る必要が無いことを意味する。最後に、テレヴィジョン12のウェッブ・サーバがそのコマンドを受けると、ウェッブ・サーバはテレヴィジョン12の電源スイッチをオンにする。
【0046】
ここでの手法は、以下に説明するように、位置認識された機器2の制御を可能にする。利用者がインターネットに自分の装置(例えばPDA装置11)を接続する場合に、全てのパケットは、最寄りのルーターに向けて転送されるであろう。ゲートウェイ・サーバ4はルーター上で動作し、如何なるHTTP要求もゲートウェイ・サーバ4によって検索される。最初のHTTPが検索された時に、ゲートウェイ・サーバ4がPDA装置11のブラウザ上でページを返信してもよい。最も近くにあるゲートウェイ・サーバ4がそのページを返信するので、返信したページはゲートウェイ・サーバ4の位置に従ってカスタマイズされる。このことは、利用者が、自身の近くで現在利用できる機器2を知っていることを意味する。例えば、前記説明したシナリオではが、利用者に身近な利用可能な機器2をPDA装置11のブラウザ上で表示することができる。家の中で複数のゲートウェイ・サーバ4を使用することにより、利用者の行動を自分の場所に従がって適応させることが可能になる。
【0047】
ここでのシステムは、周囲の表示或いは"Calm Technology"を実現する基盤として望まれる。例えば、前記テレヴィジョン12を制御するURLがクリックされたと仮定しよう。利用者が、テレヴィジョン12を制御するHTTP POST要求をゲートウェイ・サーバ4に送る場合、ゲートウェイ・サーバ4は、別のライト14を点灯せよというURLを含むIMGタグを含むページを返信しても良い。かくして、IMGタグ内のURLによって、ライト14が自動的に点灯する。これが周囲表示の例であり、本実施例におけるシステムは、ユビキタス・コンピューティング研究の実験的基盤として、非常に魅力的なものとなる。
【0048】
また将来的にこのシステムは、VCNサーバ(Visitor And Community Network System:利用者単位のサービス割当、インターネット・ベースの課金システム、セキュリティ/認証サービスを簡単に行えるソフトウェアを含むサーバ)にアクセスするための書き換え計画に対し考慮されている。利用者は、ゲートウェイ・サーバ4上のプロキシVCNサーバにアクセスする。プロキシVCNサーバは、あるコンピュータ上で実行される目標のVCNサーバに向けて総てのパケットを転送する。この手法により、ユビキタス・コンピューティング環境における情報を提供する柔軟な方法を提供できる。
【0049】
さらに本システムは、バーチャル・オーバーレイ・ネットワークを使用して、Jini, UpnPやHAViを接続するミドルウェア・コンポーネントにも考慮されている。本システムは、これらのミドルウェア・コンポーネントを接続するためのHTTPプロトコルに基づいているので、ミドルウェアを修正せずにJini, UPnPやHAViに本システムを接続するために、このコンポーネントを使うことができる。
【0050】
このように、本実施例ではホーム・コンピューティングの新しい構成について説明した。この構成は、ウェッブ・システムに基礎を置いており、種々の家庭用の機器2が柔軟な方法で統合される。この手法の利点は、JiniやUPnPのようなディレクトリ管理や、自動構成管理の提供を可能にしつつも、機器2に内蔵されるウェッブ・サーバが修正されることを前提としないことである。かくして、近い将来に非常に大衆的になるウェッブ・サーバを内蔵した汎用家庭機器を、本実施例のシステムは統合することができる。それ故に、Jini, UPnPやHAViの様な他の技術に比べて、ここでの構成はより円滑に利用できる。
【0051】
以上のように本実施例では、利用者が保有する端末(HTTPクライアント3またはPDA装置11)と、ウエッブサーバーを内蔵した制御対象となる機器2とを接続したネットワーク網を構築する通信手段1にゲートウェイ・サーバ4を接続し、このゲートウェイ・サーバ4は、現在利用可能な機器2の情報を自動的に収集して、その内容を該端末に提示する自動構成管理手段と、前記端末から目標となる機器2を制御するコマンドが発信されると、このコマンドに含まれるURLを翻訳して前記目標となる機器2にURLでアクセスするディレクトリ・サービスとしての機器アクセス手段とを備えている。
【0052】
このようにすると、HTTPプロトコルに基づくネットワークで各機器2を統合するのに必要な機能が、自動構成管理手段と、ディレクトリ・サービスに相当する機器アクセス手段としてゲートウェイ・サーバ4に備えてあるので、ウェブ・サーバを有する家庭用の機器2を修正することなく、複雑なホーム・コンピューティング環境を構築することが可能になる。
【0053】
さらに本実施例では、HTTPプロトコルを使用して前記機器2の制御を可能にし、その動作を利用者の状況に応じて変化させる状況認知("context-aware")機器制御手段を、ゲートウェイ・サーバ4に備えるのが好ましい。このようにすると、HTTPプロトコルに基づいたユビキタス・コンピューティング環境の構築を達成できる。
【0054】
次に、本発明の第2実施例を図4~図6に基づき説明する。ここでは、バーチャルオーバーレイネットワークへの展開を例にした実施例を詳述する。
【0055】
実施例の説明に入る前に、ここでいうオーバーレイ・ネットワークとは、その中に含まれる基本ネットワークがいくつかの上位ネットワークを支援する為に使用される構成として定義でき、ヴァーチャル・オーバーレイ・ネットワークを実現するための基本特性の十分なセットを提供する。ヴァーチャル・オーバーレイ・ネットワークは、新しいアブストラクト特性を提供する為のソフトウェア層を加えることにより、オーバーレイ・ネットワークの基本特性を拡張する。利用者に代わってその特性を実行することは、各アプリケーションに対してカスタマイズされる。この考え方は、D.Tennenhouse氏などが1997年に"IEEE Communication Magazine Vol.35, No.1で提案した"A Survey Of Active Network"におけるアクティヴ・ネットワークに似ている。アクティヴ・ネットワークは、既存のネットワークのカスタマイズを可能にするので、アプリケーション特有のコードは、ネットワークによって提供される現存の特性を修正することなく注入することが可能である。一方、ヴァーチャル・オーバーレイ・ネットワークは、各アプリケーションに適した新しいアブストラクト特性を追加し、既存のネットワークは拡張しない。ヴァーチャル・オーバーレイ・ネットワークは、既存のネットワーク・インフラの修正を必要としない故に、より実際的であり、各アプリケーションに対し容易にカスタマイズされる。
【0056】
ここでは図4に示す様に、インターネットのような既存のネットワーク21上に構築されるネットワークとして、ヴァーチャル・オーバーレイ・ネットワーク22を定義する。ヴァーチャル・オーバーレイ・ネットワーク22においては、多くのアプリケーションレベルのゲートウェイ23が、ネットワーク22に設置され、IPプロトコルのような或るネットワーク・プロトコルによって接続される。アプリケーションレベルのゲートウェイ23の役割は、目的地にメッセージを通すことにある。また、環境と利用者によって提示される種々の要求に従がって、各メッセージとプロトコルを翻訳してもよい。アプリケーション・レベルのゲートウェイ23は、ヴァーチャル・オーバーレイ・ネットワーク22のルーター装置として考えることができる。このゲートウェイ23は、通常インターネットにより接続されるが、基礎にあるデータリンク・ネットワークは、もしもアプリケーション・レベルのゲートウェイ23間で特別なQOS要求を満足する必要があれば、直接使用することができる。
【0057】
ヴァーチャル・オーバーレイ・ネットワーク22は、現在インターネットが持つ広範囲にわたる問題を、解決するであろう。例えば、現存するインターネットは、FQDN(十分に資格を与えられたドメイン名)やIPアドレスを採用しているが、メッセージのルーティング(最適な径路選択)を採用するために、アプリケーション特有の命名(ネーミング)を取り入れることができる。また、アプリケーション・レベルのゲートウェイ23間の接続は、元々あるネットワーク21を直接使用するか、或いはアプリケーション・レベルのゲートウェイ23におけるコンフィギュレーション
(構成)を慎重に選択することにより、ゲートウェイ23間の各QOS要求に従がって適合するように作られる。一方、インターネットにおける端末間のQOS保証を実現することは非常に難しい。アプリケーション・レベルのゲートウェイ23の機能を選択することによって、それぞれのアプリケーションに対しヴァーチャル・オーバーレイ・ネットワーク22をカスタマイズすることができる。移動支援の構築における実験からすると、高レベルの機能を実現する為の解決法は、それぞれのアプリケーションに対しカスタマイズされるべきと考えられる。
【0058】
ヴァーチャル・オーバーレイ・ネットワーク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年オぺレーティングシステムデザインおよびインプレメンションの第4シンポジウム会報)や、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年オぺレーティングシステムのホットトピックスにある第8回ワークショップ会報)においては、地球規模のイヴェント・サービスに対するヴァーチャル・オーバーレイ・ネットワークが提案されてきた。さらに、K.P.Birman,氏による"Technology Challenges for Virtual Overlay Networks"(2000年情報確約および保証における2000IEEEワークショップ会報)においては、それぞれのヴァーチャル・オーバーレイ・ネットワーク用の資源を分轄する為に使用されるルータパーテーション機構が提案されてきた。この解決法は、インターネットの総ての要求を包括的に満足するものではないが、各ドメインの問題を解決するのには十分である。
【0059】
従来のネットワークに於いて、ヴァーチャル・オーバーレイ・ネットワークの概念は、部分的に採用されていた。例えばネットワーク上でデータの一斉配信を効率よく行なうための技術であるマルチキャストを、インターネット上で利用できるようにするために構築された実験ネットワークの一つであるMboneや、現在のインターネット上におけるマルチキャスト能力のあるIPネットワークが構築され、また6Boneは、現在のインターネット上のIPv6ネットワークを発展させるために利用されてきた。さらに、ドメイン・ネーミング・システムやウェッブ・キャッシング・システムもまた、ヴァーチャル・オーバーレイ・ネットワークと考えられており、アプリケーション特有の方法で、種々の問題を解決した。
【0060】
こうした既知の提案は、ヴァーチャル・オーバーレイ・ネットワークの概念を採用することにより、拡張性を大いに増大したが、これらの提案は、従来の基礎的データ・リンク・ネットワークは直接使用せず、プロトコルやメッセージの翻訳も明らかに使用していない。その点で本実施例におけるシステムは、ヴァーチャル・オーバーレイ・ネットワークの概念を十分に利用する努力をしている。
【0061】
システマティックな方法で各アプリケーション向けにカスタマイズされたヴァーチャル・オーバーレイ・ネットワークを開発することは、最も重要な目的の一つである。しかしながら、この目標の達成は、それまでの多くの経験から断定できる。ここでは、ネットワーク化された家庭用の機器を統合する為のヴァーチャル・オーバーレイ・ネットワークの構築について説明する。例えば、Jini,UpnP,HAViそしてSOAP(Simple Object Access Protocol :他のコンピュータにあるデータやサービスを呼び出すためのプロトコル)は、種々の家庭用機器を制御する為に提供される。クライアント機器は、もしこれらのプロトコルの総てを支援していなければ、家庭用の機器を制御することはできない。しかしながら、多くのプロトコルを支援することは、大きな記憶容量を必要とするので非現実的である。また、新しいプロトコルが将来の家庭用機器に提案されたとすれば、新しいソフトウェアがクライアント機器の中に追加されなくてはならない。
【0062】
ここでのヴァーチャル・オーバーレイ・ネットワーク22は、クライアント機器によって支援されるプロトコルを家庭用の機器によって支援されるプロトコルに転換することにより、この問題を解決する。この転換は、機器とネットワークの特性に従がって、各アプリケーション・レベルのゲートウェイ23によって実行される。
【0063】
次に、ネットワーク化された家庭用機器を統合するヴァーチャル・オーバーレイ・ネットワークの効果を詳細に説明する。ヴァーチャル・オーバーレイ・ネットワークの設計を動機付ける最終的な目標は、IEEE1394や、ブルートゥースや、インターネットのような異質のネットワーク上に置かれた各家庭用機器に対し、アプリケーション特有のアブストラクションを提供することである。ここでは、現行プロトタイプのヴァーチャル・オーバーレイ・ネットワークの設計とその利用に就いて説明する。最初に設計の問題点と我々のシステムの概観を提示し、次にこれまで利用した幾つかの構成要素を提示する。最後に、現行プロトタイプシステムについての幾つかの問題点を説明する。
【0064】
エンドツーエンドの議論は、インターネットに対するシステム設計の原理である。すなわち、複雑なネットワーク機能は、ネットワークの端末に押し進められるものと思われる。しかし現在のインターネットの全端部は、複雑な計算機ではない。何故ならば、例えば、家庭用機器,内蔵コンピュータそしてPDA装置のように、それらの内のいくつかはそれら自身の特別な目的だけのために設計されているからで、それらはインターネットの標準プロトコルは処理できない。したがって、そうした複雑でない端末よりも、機能豊かなネットワークが、ネットワーク内部に於いて支援され向上されるべきであり、端末のあるものとサブ・ネットワークがインターネット向けに用意されていなくても、全端末とサブ・ネットワークに対して継ぎ目の無い状況を提供すべきである。ここでのヴァーチャル・オーバーレイ・ネットワークの骨組みは、次のような機能追加を支援する。
(1)ヴァーチャル・オーバーレイ・ネットワークの骨組みは、新しい命名システムを中心に構築される。ホストネームをアドレスにハードコーディングするような属性に従うというよりもむしろ、機能的かつ物理的位置のような意図した情報に従がって、機器が調べられるべきと考える。実際、TCP/IPを支援しない機器の中には、インターネット内で利用可能な独自のアドレスを持つことが出来ず、その機器に直接接続することができる他のサーバにより包含され、かつ他のサーバを介して確認される必要がある。
(2)ウェッブ基礎のコンピューティングは、HTTPを通じて行なわれ、現在のインターネット内で広く使用される。HTTPはワールド・ワイド・ウェッブ(www)を支えるプロトコルであり、定義によってあらゆるウェッブ・ブラウザはHTTPを使って通信可能である。この通信は、定められた命名規約に適合したURLを使うブラウザによって発生する。ここでヴァーチャル・オーバーレイ・ネットワークは、ウェッブ・ブラウザからの容易なアクセスと種々の家庭用機器の制御を可能にするのみならず、機器が互いに通信し協力動作を行なうことを可能にする。
(3)家庭用機器の中には、JiniやUPnPのような装置(デバイス)とサービスを管理する既存のサービスディスカバリーシステムの下でしばしば管理されるものがある。こうしたシステムは、最小の管理と人間の干渉で装置/サービス内の動的な協動を容易にするために提案されたものである。この臨時的な共同を支援するためには、ネットワークに対してその存在を公表する手段を備えるべきで、これにより近くに在るサービスを発見して、そのサービスにアクセスすることができる。ヴァーチャル・オーバーレイ・ネットワークの骨組みは、各機器に対してのみならず、各機器を管理する現存のに対しても、統一された考え方を提供する。
(4)ヴァーチャル・オーバーレイ・ネットワークの骨組みは、ネットワーク中のデータの変換を行なうために、トランスコーディングを広範囲に使用すべきである。これは、家庭用機器の中にはプロセッサや入出力装置のような計算機資源にしばしば重大な限界が在るためである。ある家庭用機器においては、外部システムからのデータをトランスコーディングするためのあらゆる助けがなければ、ネットワークから受け取りネットワークへ送り出す多量のデータを、直接処理できないものもあるかもしれない。
【0065】
本実施例におけるヴァーチャル・オーバーレイ・ネットワーク22の骨組みは、家庭用の機器/サービス24、そしてアプリケーション・レベルのゲートウェイ23から構成されるが、家庭用機器24の幾つかは、まさにアプリケーション特有の装置であって、TCP/IPをサポートしていないものもある。したがって、アプリケーション・レベルのゲートウェイ23は、機器24特有のプロトコルからHTTPへの(或いはこの逆)プロトコル翻訳変換手段を機能的に備える必要がある。ここでは、各アプリケーション・レベルのゲートウェイ23は、HTTP基礎のプロキシ・サーバとして受け入れられる。それは、HTTPに基づく家庭用の機器24の制御プロトコルを受け入れ、機器24特有のプロトコルに翻訳する。さらには、機器24特有のプロトコルからインターネットへのアクセス点として、ゲートウェイ23の使用を提案する。ゲートウェイ23は、HTTPから目標となる機器24に対応するコマンドへの翻訳サービス手段を備える。またゲートウェイ23は、インターネットから、若しくはインターネットへの種々の機器の広範囲なセッション・インターフェースをエクスポートする。
【0066】
アプリケーション・レベルのゲートウェイ23は、例えば、命名や、トランスコーディングやパケット転送などのアプリケーション特有のサービスを、種々の機器に対してサポートすべきであり、そのためにゲートウェイ23に対しては拡張性を持たせる手段を導入する。アプリケーション・レベルのゲートウェイ23は、2層から成る。上層はHTTP要求や種々のモジュールを満たすための機能から成り、種々のモジュールは確証や機器制御などのウェッブ基礎のタスクを実行する論理を提供する。このモジュラーアプローチ手段は、ゲートウェイ23としての機能を拡張する為に、追加モジュールを組み入れることが可能である。下位の層は、実際の機器にアクセスすると共に、各サービスをサポートするための骨組みを使用する。
【0067】
ここで考慮すべきもう一つの点は、機器24の制御器である。この制御器は、HTTPに基づいた機器24の制御要求を、ゲートウェイ23に送る。制御器用には従来のウェッブ・ブラウザを使用するが、ブラウザに対するいくらかの修正を行なうことで、新たな機能を提供することができる。
【0068】
次に、2つのシナリオを使って上記構成を具体化した例を説明する。最初のシナリオは、ウェッブ・ブラウザから家庭用機器にアクセスすることであり、二番目の例は、異なるプロトコルを使用する二つのホーム・ネットワークを繋げることである。そして最終の目的は、URL基礎のインターフェースを任意のアプリケーションやデバイスに提供することであるが、目下のところ総てのネットワーク機器をHTTPサービスに転換することはできない。その代わり、各アプリケーション・レベルのゲートウェイは、URLに基づく表現から機器用に設計された対応するコマンドへの翻訳サービスにより、それらの特別のネットワークを通じて、一個以上の機器を制御する。一般的には、ウェッブ・ブラウザは、標準のHTTP GET機構を使って問合せ要求を提示することにより、URIに一致するリモートホストにアクセスして、そのURIからの応答を受け取るか、または標準のHTTP POST機構を使ってHTML形式を通じてURIにデータを提示し、同じくHTTP内のURIから応答を受け取る。ゲートウェイ23が機器24への通信を終了した時に、終了データはブラウザへ戻される。
【0069】
なお、具体的なURLの記述に関しては、第1実施例と同様であるのでその説明を省略する。
【0070】
ヴァーチャル・オーバーレイ・ネットワーク22の骨組みは、3個の要素、すなわちアプリケーション・レベルのゲートウェイ23と、端末である制御器と、そして機器/サービスから成る。機器/サービスは、アプリケーション特有のものであるので、ここでは議論しない。これ以降は、アプリケーション・レベルのゲートウェイ23と制御器を説明する。
【0071】
アプリケーション・レベルのゲートウェイ23は、図5に示す様に、機器特有のネットワーク(ホームネットワーク)とインターネット間のゲートウェイとして動作する。アプリケーション・レベルのゲートウェイ23は、前述したようにHTTPに基づく制御方法と種々のミドルウェア制御方法との間の橋渡しを行なう。
【0072】
アプリケーション・レベルのゲートウェイ23は、4つの構成要素から成る。第一の構成要素は、HAVi,Jini或いはUPnPのようなホーム・ネットワーク・プロトコルを実行するもので、これはホーム・ネットワーク装置として動作する。例えば、もしその構成要素がJiniプロトコルを実行するならば、構成要素はJini装置として動作する。第二の構成要素はHTTPプロトコルを実行するもので、この構成要素はウェッブ・サーバとして動作する。
【0073】
第三の構成要素はプロトコルの翻訳を実行するもので、この翻訳手段は、前述のようなHTTP処理と特殊なホーム・ネットワーク・プロトコル間の変換を行なう。例えば、HAVi翻訳手段は、HTTPプロトコルからHAViプロトコルへのまたその逆の変換を行なう。さらに現行プロトタイプの実行にて、Jiniの翻訳とUpnPの翻訳も実行される。
【0074】
最後の構成要素は登録管理手段である。この登録管理手段は、ウェッブ・ブラウザからのHTTPプロトコル、またはプロトコルを利用している機器からのホーム・ネットワーク・プロトコルによってアクセスすることができる。もし、ホーム・ネットワーク22上にある機器24が、ホーム・ネットワーク22外からアクセスを受けたならば、機器24の名前がアプリケーション・レベルのゲートウェイ23に登録されるべきである。その名前は、HTTPプロトコルか、またはホーム・ネットワーク・プロトコルかを経由して登録される。登録後、擬似的なホーム・ネットワークデバイスが、アプリケーション・レベルのゲートウェイ23内に作成される。擬似デバイスは、自動照合サービス内に、その名前を登録する。擬似デバイスの役目は、ホーム・ネットワーク22上で送られる制御コマンドをHTTPプロトコルに変換することである。
【0075】
次に、スタートアップ手順を説明する。アプリケーション・レベルのゲートウェイ23がスタートアップ(行動開始)する時、周囲のネットワークに参入しようとする。このネットワークで使用されるプロトコル特有のミドルウェアにより提供される方法を使って、どの装置(デバイス)若しくはどのサービスが利用可能かを調査する。例えばJiniネットワークにおいては、ゲートウェイ23は、Jiniの照合サービスを使用するであろう。この調査によって蓄積される結果は、ホーム・ネットワーク・プロトコルによって使用される属性と、HTTPに基づく方法で使用される対応コマンドとを記録するデータベースに蓄積される。
【0076】
もし、アプリケーション・レベルのゲートウェイ23が、インターネット21からのHTTP基礎のコマンドを受け取ると、その内部にあるデータベースを参照することにより、そのコマンドを解析し、どのコマンドがどのコマンドに送られるべきかを決定した後、必要なプロトコルの翻訳を適用し、ミドルウェア特有の対応するコマンドを送り出す。一方、登録管理手段によりゲートウェイ23で作られる擬似デバイスは、機器24に特有のネットワーク装置として動作する。このことにより、アプリケーション特有のネットワーク22側にある装置が、ゲートウェイ23のインターネット21側にある装置の制御を可能にする。この様にして、ゲートウェイ23が、ホーム・ネットワーク22内にある装置に対して、あたかもインターネット21側の装置によって実際に提供される機能或いはサービスを提供するように見えることになる。
【0077】
アプリケーション・レベルのゲートウェイ23は、HTTPサーバとして制御インターフェースを提供し、如何なるアプリケーション特有のネットワーク装置も、HTTP基礎の制御プロトコルを使っての制御が可能となる。それ故、現存のウェッブ・ブラウザを制御器25に使用することを受け入れる。近年、ウェッブ・ブラウザは、パソコンは言うまでもなく、PDA装置,携帯電話そしてデジタルTVセットに内蔵されるようになった。これらの装置は総て、アプリケーション・レベルのゲートウェイ23により、他の装置を制御する為に使用することができる。広域のブラウザが、上述の如く制御器25として使用される時、ゲートウェイ23は、自身が受け入れるであろう各コマンドにリンクしたコマンド・ボタンを含むウェッブ・ページを生成しなけばならない。一方、もし制御器25が、自身で独特のHTTP基礎のコマンドを生成するように構築されるならば、ホーム・ネットワーク環境に対するカスタマイズ性或いは適応性という点で、広範囲なブラウザ上で確実な長所を持つであろう。
【0078】
次に、上記ヴァーチャル・オーバーレイ・ネットワークを使用して、異なるホーム・ネットワーク・プロトコルを提供する幾つかのホーム・ネットワークをどのようにして接続するのかを説明する。図5に示すように、ここでは各アプリケーション・レベルのゲートウェイ23を通じてインターネット21に接続される3つのホーム・ネットワーク22(22A~22C)を想定する。各ホーム・ネットワーク22は、それらのゲートウェイ23(23A~23C)がそれぞれ"http://any.where.net","http://my.home.net","http://foo.bar.net"というURLを有し、アプリケーション特有のプロトコル、すなわちUpnP,HAViそしてJiniを使用している。
【0079】
一つの例として、HAViネットワーク22A上にあるVCR装置31を、PDA32からUPnPネットワーク22Cへ制御したい場合を想定して見よう。HAViネットワーク22A中で、VCR装置31は“VCR”として登録されており、そのアプリケーション・レベルのゲートウェイ23A(HAVi,ApGW)は、HAViの照会サービスにおいて“apgw”として登録されている。また、UPnPネットワーク22CにあるPDA32は、"PDA”として登録されており、そのアプリケーション・レベルのゲートウェイ23C(UPnP,ApGW)は、UpnPの照会サービスにおいて“apgw”として登録されている。
【0080】
そして最初に、UPnPネットワーク22CにあるPDA32からHAViネットワーク22A上にあるVCR装置31を制御する為に、UpnPネットワーク22C中にHAViネットワーク22A上にあるVCR装置31を登録する必要がある。PDA32によって、利用者はPDA32上で展開するウェッブ・ブラウザから、UPnPアプリケーション・レベルのゲートウェイ23C内に、”http://my.home.net/VCR"としてVCR装置31を登録する。これは、http://any.where.net/!register="http://my.home.net/VCR"と記述される「登録」コマンドを使用する。
【0081】
もし、UPnPアプリケーション・レベルのゲートウェイ23Cが、この登録要求を受け取ると、VCR装置31に関する情報を要求する為に、HTTP基礎のプロトコルを使用してHAViアプリケーション・レベルのゲートウェイ23Aに問合せを送る。HAViアプリケーション・レベルのゲートウェイ23Aは、URLにより指示されたVCR装置31に関する情報を返送する。UPnPアプリケーション・レベルのゲートウェイ23C上で、VCR装置31の擬似UpnPデバイスが、HAViアプリケーション・レベルのゲートウェイ23Aから戻ってくる情報を利用して作成される。擬似デバイスは、"VCR”という名前を持ってUpnPの通信部に結合する。PDA装置32がVCR装置31を制御したい場合は、PDA装置32は、UPnPのサービスディスカバリー機構を介してVCR装置31を発見しようとする。サービスディスカバリー機構は、UPnPアプリケーション・レベルのゲートウェイ23C上で作成された擬似デバイスに対し照会を返信する。すると制御コマンドが、UPnPプロトコルを通じて擬似デバイスに配達される。擬似デバイスは、UPnPの要求をHTTPプロトコルへ変換し、http://my.home.net/VCR"のホスト名部分に従がって、HAViアプリケーション・レベルのゲートウェイ23Aにその要求を転送する。HAViアプリケーション・レベルのゲートウェイ23Aは、変換されたHTTP要求を受け取り、HAVi照会サービスを通じてURLのファイル名の中で指定された”VCR”によって、実際のVCR装置31を発見する。最後に、コマンドはHAViコマンドに変換され、目標のVCR装置31へ配達される。
【0082】
ヴァーチャル・オーバーレイ・ネットワークの骨組みを現在使用している中で、各アプリケーション・レベルのゲートウェイ23は、スタンドアロン処理として実行するJava(登録商標)・アプリケーションとして利用されると共に、家庭用機器に対するHTTP基礎のインターフェイスと、管理機器用のサービスディスカバリーシステムとを提供する。各アプリケーション・レベルのゲートウェイ23は、その受信したURLを含む属性を解釈する簡単な記憶データベースを有する。更に、JiniとUPnPのようなその基本サービスディスカバリーシステムと協同して、未知の属性を処理することもできる。
【0083】
続いて、ゲートウェイへ送り出すコマンドと同様に、利用者の好みや個人的な認証や環境情報等のような追加情報の送り出しを可能にする制御器の拡張について説明する。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"ような情報を有するものとする。
【0084】
制御器は、環境変数の始まりとして”%(“を取扱う。”%(“と”)“との間に囲まれる文字列は、環境変数の名前である。”%()”の部分は、対応する環境変数の値と置き換えられる。この場合送られるコマンドは、"http://my.home.net/?=OWNER=foo&location=living-room&function=tv/!power=on"となる。
【0085】
制御器が持つ環境情報は、制御器そのものの位置や、制御器を現在使用している利用者や、他の環境パラメータに従って更新される。もしも、同じ制御器の同じボタンを押したとしても、ボタンが押された状況次第で、発信されるコマンドは異なっても良い。家庭用機器の制御に影響を与える為に使用できる環境情報の他の例は、天気情報、利用者の感情等であっても良い。
【0086】
大部分の標準はオブジェクトモデルに基礎を置いているが、各標準間には多くの差がある。Jiniは、リモートサービスと各機器を統合するJavaに基づいた基盤(インフラ)である。Jiniシステムは、分散システムに於ける、サービス構築、照合そして通信の各機構を提供する。しかしながら、Jiniは多くをJava言語に頼っており、そのランタイム・システムは、大量の計算機資源を必要とし、この様な資源は家庭用では通常極度に限定される。UPnP(ユニバーサル・プラグ・アンド・プレイ)は、パソコンと機器間のピアー・ツー・ピアー・ネットワーク接続を供給する構成である。UPnPは、装置をダイナミックにネットワークに参加させ、自身にIPアドレスを割り当て、自身存在と要求に応じる能力を有する。UPnPは、TCP/IPとウェッブ技術に基礎を置き、家庭や事務所に於いてネットワーク化された装置間での制御とデータ伝送に加えて、シームレスな近接ネットワークを可能にする。しかしながら、UPnPはXMLファイルにおける各機器の特徴と能力を発揮するように図られている。XMLに基礎を置いたプロファイルは、Jiniの簡単なサービス属性に反して、機器能力の複雑な手間の掛かる説明が必要であるので、家庭用の機器がXMLファイルを解釈するのは困難である。
【0087】
HAVi(Home Audio Video Interoperability)は、デジタル音響、映像の消費者用機器を、シームレスに接続するためのホーム・ネットワーク標準を提供する。HAViはまた、そのプログラム内からの各機器への制御を可能にするAV機器制御用Java APIをもまた提供する。HAViは、十分な帯域幅を持ちデジタル音響、映像の多数の信号流を伝送できるIEEE1394ネットワーク・インターフェーイスを各機器が有することを仮定している。しかしながら、こうした要求は、種々の型の機器でHAViが広く使用されることを阻害している。
【0088】
将来の家庭用機器において、それらの製造業者の方針による各種異なる標準を、支援することが期待されている。しかしながら、これらの標準は、多様なホーム・ネットワークをサポートするものではない。ここで提案したヴァーチャル・オーバーレイ・ネットワークは、総ての家庭用機器が互いに接続され制御することを可能にする。
【0089】
OSGi(The Open Services Gateway specification)は、Javaに基礎を置くアプリケーション層の骨組みであり、サービス提供者、装置メーカーそして機器製造業者に、業者には中立のアプリケーションと装置層APIと機能を提供する。この戦略は、事実上、出現する総てのホーム・ネットワーク基盤、プロトコルそしてサービスを、現存する住宅電話線、ケーブルTV或いは電線を使って、バックエンド・サービスとのシームレスな相互作用を可能にする。この技術は、基盤から独立している必要があり、その結果、種々の計算機環境、通信環境、消費者向けエレクトロニクスそして家庭用製品と基盤上での使用が可能となる。オープン・サービス・ゲートウェイ仕様は、オープン・システム層とサービス・ゲートウェイ向けのゲートウェイ・インターフェイスの提供に専門的に焦点を当てるので、現在のネットワーク標準と企業心を補足し向上させる。これらの内幾つかは、Jini,ブルートゥース,CAL,CEBus,HAVi,Home API,HOME-PAN,HomePnP,HomeRFそしてVESAを含んでいる。
【0090】
オープン・サービス・ゲートウェイ仕様はまた、将来の高機能家庭用装置における消費者の投資を維持する。例えば、今日において、消費者がホームセキュリティプロバイダを別のプロバイダに切り替える時、内部ネットワークの総てを入れ替えなければならない。オープン・サービス・ゲートウェイ仕様と互換性のある装置を選択することにより、消費者は、事実上如何なるネットワーク基盤を入れ替える必要無しに、種々の業者の商品間で、どれにでも切り替えできる。
【0091】
OSGiの利点は、拡張性のあるホーム・ゲートウェイを構築する為の骨組みを提供することにある。拡張性のあるアプリケーション・レベル・ホーム・ゲートウェイを履行する為に、この標準が採用される。
【0092】
上記実施例では、ネットワークされた家庭機器を統合するヴァーチャル・オーバーレイ・ネットワークを提案してきた。ヴァーチャル・オーバーレイ・ネットワークは、メッセージの伝達ルートを決定し、ネットワークと機器の特性に従がってプロトコルとメッセージを変換する。ヴァーチャル・オーバーレイ・ネットワークは、インターネット規模のユビキタス・コンピューティングの実行に非常に有益である。
【0093】
またIP層は、ヴァーチャル・オーバーレイ・ネットワークの構築に必要な機能性を提供すべきであって、複雑な通信を必要とするそれぞれの機器に対して、ヴァーチャル・オーバーレイ・ネットワークがカスタマイズされる。この機能性の大部分は、IP層の上位で実行されるべきで、さらにそれぞれの機器に対してカスタマイズされるべきである。したがって、IP層における機能のサポート(支援)は最小化されるべきで、広域な方法でIP層に幾つかの進歩した機能を与えることは避けるべきである、何故ならば、IP層で実行される機能は、余りにも広範囲過ぎ、実際の進歩したアプリケーションを構築するには力不足だからである。
【0094】
なお、本発明は上記実施例に限定されることなく、本発明の範囲内で種々の変形実施が可能である。
【0095】
【発明の効果】
本発明の請求項1の構成によれば、ウェブ・サーバを有する家庭用の機器を修正することなく、複雑なホーム・コンピューティング環境を作るのに必要なディレクトリサービスや自動構成管理と同様の機能を持つことが可能になる。
【0096】
また、機器統合のためのネットワーク構築装置によれば、HTTPプロトコルに基づいたユビキタス・コンピューティング環境の構築を達成できる。
【図面の簡単な説明】
【図1】本発明の第1実施例を示すネットワーク構築装置の全体構成をあらわした概略説明図である。
【図2】同上機器を特定し制御するためのURL記述の一例を示す図である。
【図3】同上図1におけるネットワーク構築装置を発展させた例を示す概略説明図である。
【図4】本発明の第2実施例を示すネットワーク構築装置の概略説明図である。
【図5】同上インターネットとホームネットワークを繋ぐゲートウェイの機能構成を示す概略説明図である。
【図6】同上ホームネットワークの接続形態を示す概略説明図である。
【符号の説明】
1 通信手段(ネットワーク網)
2 機器
3 HTTPクライアント(端末)
4 ゲートウェイ・サーバ
11 PDA装置(端末)
図面
【図1】
0
【図2】
1
【図3】
2
【図4】
3
【図5】
4
【図6】
5