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

Abstract

(57)【要約】 【課題】 ウェブ・サーバを有する家庭用の機器を修正
することなく、ネットワーク上で各機器の統合を図る。 【解決手段】 HTTPプロトコルに基づくネットワークで
各機器２を統合するのに必要な機能を、自動構成管理手
段と、ディレクトリ・サービスに相当する機器アクセス
手段としてゲートウェイ・サーバ４に内蔵させる。これ
により、ウェブ・サーバを有する家庭用の機器２を修正
することなく、複雑なホーム・コンピューティング環境
を構築できる。

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（非同期転送モード）ネットワーク，IEEE139
4，携帯情報機器向けの無線通信技術として知られるブ
ルートゥース（登録商標），そしてVIAの様な種々のネ
ットワーク・システムが、種々の機器を接続するために
開発されてきた。また、研究団体に於いて、PEN，ネッ
トワークド・サーフェスそしてCLANは、将来の進歩した
機器を接続するために提案されてきた。

【００１１】しかしながら、これらの基本的なプロトコ
ルとネットワークのもつ種々の有益な特性は、IP層がネ
ットワークに挿入されるならば、アプリケーションから
隠されてしまう。例えば、ブルートゥースにより提供さ
れるプラグ・アンド・プレイ機能とATMにより提供され
るネットワークバンド幅保存機能は、通常IP層（注：QO
S保証するIPプロトコルを拡張する幾つかの提案がなさ
れているが、この提案によって提供されるアブストラク
ションは、ATMのバンド幅保存能力の全部は提供しない)
の最上層で通常利用できない。また、ある機器のなかに
は、他の機器やサービスに接続するためのIP層を支援
（サポート）しないものもある。更に、各機器は、互い
に通信する為に異なる制御プロトコルやデータ・フォー
マットを想定するかもしれない。それ故、新しい手法
が、将来の家庭用機器のために、ネットワーク支援を実
現する必要がある。

【００１２】過去にインターネットに関する種々の問題
を解決するために、ヴァーチャル・オーバーレイ・ネッ
トワークが利用されてきたが、ネットワーク化された家
庭用機器の統合の為にヴァーチャル・オーバーレイ・ネ
ットワークを適用する考えには及んでいない。すなわ
ち、組織的な手法で、インターネット規模のユビキタス
・コンピューティング環境を得るために、カスタマイズ
されたヴァーチャル・オーバーレイ・ネットワークを構
築する必要がある。

【００１３】そこで本発明は、ウェブ・サーバを有する
家庭用の機器を修正することなく、複雑なホーム・コン
ピューティング環境を作るのに必要なディレクトリサー
ビスや自動構成管理（Automatic Configuration Manage
ment）と同様の機能を持つことができる機器統合のため
のネットワーク構築装置を提供することをその目的とす
る。

【００１４】

【課題を解決するための手段】本発明の請求項１におけ
る機器統合のためのネットワーク構築装置は、利用者が
保有する端末と、ウエッブサーバーを内蔵した制御対象
となる機器とを接続したネットワーク網にゲートウェイ
・サーバを接続し、このゲートウェイ・サーバは、現在
利用可能な機器の情報を自動的に収集して、その内容を
前記端末に提示する自動構成管理手段と、前記端末から
目標となる機器を制御するコマンドが発信されると、こ
のコマンドに含まれるURLを翻訳して目標となる機器にU
RLでアクセスする機器アクセス手段とを備えて構成され
る。

【００１５】この場合、HTTPプロトコルに基づくネット
ワークで各機器を統合するのに必要な機能が、自動構成
管理手段と、ディレクトリ・サービスに相当する機器ア
クセス手段としてゲートウェイ・サーバに備えてあるの
で、ウェブ・サーバを有する家庭用の機器を修正するこ
となく、複雑なホーム・コンピューティング環境を構築
することが可能になる。

【００１６】また、本発明の請求項２における機器統合
のためのネットワーク構築装置は、HTTPプロトコルを使
用して前記機器の制御を可能にし、その動作を利用者の
状況に応じて変化させる状況認知機器制御手段を前記ゲ
ートウェイ・サーバに備えたものである。

【００１７】このようにすると、HTTPプロトコルに基づ
いたユビキタス・コンピューティング環境の構築を達成
できる。

【００１８】

【発明の実施形態】以下、添付図面を参照しながら、本
発明における好適な各実施例を順に説明する。図１〜図
３は、本発明の第１実施例を示す機器統合のためのネッ
トワーク構築装置である。

【００１９】先ず詳細な構成を説明する前に、本システ
ムの設計で最も重要な基本的概念とは、ウエッブ・サー
バを有する家庭用機器を修正せず使用することにある。
ウエッブ・サーバを有する汎用の家庭用機器は、自身が
保有するウエッブ・サーバの修正ができないのである
が、かといって新しいプロトコルを標準化するのは非常
に難しい。しかし、通常の人々はホームネットワークが
どのようにして形成されるのかを知らないので、ホーム
コンピューティング環境を構築するには、JiniやUpnPに
見出される自動構成（コンフィギュレーション）管理が
サポートされなければならない。

【００２０】従来のウェッブに基づく環境では、利用者
はアクセス前に、各機器のURLを知る必要があった。し
かし、利用者がアクセスしたい機器のURLを見付けるデ
ィレクトリ・サービスが何も存在しないので、そのURL
を知ることは容易ではない。また、このディレクトリ・
サービス内における各機器に対するURLを登録するのに
自動構成管理を必要とする。

【００２１】図１は、各家庭用機器を統合することが可
能なネーミング（命名）管理を提案するシステム全体の
構成で、１はインターネットを実現するための通信手
段、２はこの通信手段に接続する複数の家庭用機器であ
る。また３は、HTTPプロトコルの下で利用されるHTTPク
ライアントで、具体的には家庭でインターネットを利用
する際のパソコン（パーソナルコンピュータ）などがこ
れに相当する。

【００２２】ここでのシステムは、二個の構成要素から
成っている。第一の構成要素は、ウェブベース環境内に
組み込まれる機器２である。この機器２は、ウェッブ・
サーバを備えており、IEEE802.11b, ブルートゥース，I
EEE1394或いはイーサーネットなどの標準ネットワーク
を通じて、インターネットネットワークを構築する通信
手段１に接続されている。ここに提案するシステムは、
各機器２におけるウェッブ・サーバの拡張を想定してい
ない。したがって、ウェッブ・サーバを含む汎用製品の
どれでも通信手段１に接続して使用できる。

【００２３】第二の構成要素は、家庭用の機器２を管理
するために設けられゲートウェイ・サーバ４である。こ
のゲートウェイ・サーバ４は、目標となる機器２へのア
クセス方法を提供するディレクトリ・サービスの役割を
演じるもので、さらに現在利用できる機器２を維持管理
する自動構成管理としての機能も備えている。

【００２４】図１に示すホームネット利用者が、部屋の
中にある家庭用の機器２にアクセスしたい時は、先ずHT
TPクライアント３を利用してゲートウェイ・サーバ４と
接触する。ゲートウェイ・サーバ４は、部屋の中にある
利用可能な機器２に関する情報を利用者に提供する。利
用者の観点からすると、その利用者はゲートウェイ・サ
ーバ４のIPアドレスを含むURL（Uniform Resource Loca
tor：インターネットにおける情報の「住所」）を使っ
て、機器１を制御するための要求を発するので、利用者
にとって如何なる家庭機器もゲートウェイ・サーバ４に
直接接続されているように見える。ゲートウェイ・サー
バ４は、機器２のウェッブ・サーバから集められる情報
に従って、適正な機器２に向かってその要求を転送す
る。

【００２５】次に、各機器２を制御するためにどのよう
にしてURLを特定するのかについて説明する。ここでの
最終目標は、任意のアプリケーションやデバイスに対し
URLに基づくインターフェースを提供することである。
ウェッブ・ブラウザーは一般的に、標準のHTTP GET機構
を使って問合せ要求を提示することにより、URI（Unifo
rm Resource Identifiers ：インターネット上に存在す
る情報資源の場所を指し示す記述方式で、URLはURIの機
能の一部を具体的に仕様化したもの）に一致するリモー
トホストにアクセスして、そのURIからの応答を受け取
るか、または、標準のHTTP POST機構を使ってHTML形式
を通じてURIにデータを提示し、同じくHTTP内のURIから
応答を受け取る。利用者によって通過されるURLは、以
下に示すように翻訳され、その要求は目標の機器２に転
送される。

【００２６】図１に示すシステムにおいて、利用者はHT
TPに基づくプロキシ・サーバとして与えられたゲートウ
ェイ・サーバ４を通して、一つまたはそれ以上の機器２
にアクセスできる。しかしながら、ゲートウェイ・アド
レスが判っているときでさえも、利用者が機器２の中か
ら最適の機器２の一つを確認することは難しい。そこ
で、機器２を特定し制御するためのURLに基づいたネー
ミングの取り決めをここで行なう。この取り決めは、標
準のURL内で定義するが、URL形式のパス・エレメント
は、図２に示す如く、BNF（バッカス記法）に似た構文
に従って、幾つかの追加情報を含むことができる。

【００２７】ここで、＜path＞::=の次にある文字
「ε」は、文字列の存在しないempty string を意味
し、＜string＞は一連のアルファベットに対応する。＜
search＞::=の次にある文字「？」の属性は、問い合わ
せ式を表し、フィールドが（場所或いは所有者と云っ
た）問い合わせの性質を記述する場合には、一組のフィ
ールド値であり、一個の値は文字列または整数である。
「！」の属性は、フィールドがコマンドの性質を記述す
る場合はそのコマンドを特定すると共に、その値は文字
列または整数である。

【００２８】上記取り決めによれば、例えば"http://so
me.where.com.8080/CEIL-LIGHT/!power=ON"なるURLの記
述として表わせる。このURLの記述では、事前の同意に
よりポート番号8080で聞いているsome.where.com. と命
名されたゲートウェイが呼び出される。その次の"CELL-
LIGHT"の要素は、ゲートウェイの下で制御される電灯を
特定するものである。"！power=ON"の要素は、ゲートウ
ェイに対し信号を送ると共に、機器２別にON値を備え
た"power"と命名される特別の機能を指名する。このURL
は、"CELL-LIGHT"として命名された電灯をオンするため
の要求である。

【００２９】もう一つの例として、"http://some.wher
e.com/?location=room1&?function=light/!power=ON"を
示す。

【００３０】この例の中で、"?location=room1"の要素
は、ゲートウェイ・サーバ４の下で制御されるビルまた
はフロア−の"room1"と呼ばれる場所を特定している。
また「?function=light」の要素は、room1の場所で機能
的に命名された"light"をサポートする最適な機器２の
一つを特定している。そして、このURLも、"light"とし
て命名された電灯をオンするための要求である。

【００３１】この様な最適な機器２をダイナミック（動
的）に特定するために、ここで取り決めたURLは、"＄(v
ariable)"の形式を含むことができる。なお"variable"
は、その値が文字列である可変名を示す。これらの変数
は、ゲートウェイ・サーバ４上で実行するシェルプログ
ラム或いはオぺレーティングシステム（OS）により提供
される環境変数と関連付けられる。URLに基づく表記法
に対する変数の概念は、G.Voelker氏およびB.Bershad氏
による「モビザイク：モバイル無線コンピューティング
環境用の情報システム（モバイルコンピューティングシ
ステムおよびアプリケーションにおけるワークショップ
議事，1994年IEEEコンピュータ学会）」において手法さ
れたダイナミックURLに基づく手法により、もとは示唆
されたものである。ダイナミックURLの変数は、利用者
側のコンピュータ（HTTPクライアント３)上で実行する
シェルプログラムまたはオぺレーティングシステム（O
S）によって、提供される環境変数と常に関連をもたな
ければならないが、ここで提案される変数は、ゲートウ
ェイ・サーバ４でダイナミックに解釈される。

【００３２】例えば、"http://some.where.com/$(LIGH
T)/!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=1
0/"というURLについて考える。このURLは、「私は、私
の家のテレビチャンネルを10にセットしたい」ことを意
味している。ゲートウェイ・サーバ４は、自身の保有す
るデータベースの検索により、家の中にあるそのテレビ
のIPアドレスが123.5.10.10であることから、URLを"htt
p://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://ww
w.myhome.net/TV/!power=on/"というGETコマンドを発信
する。URLは、"http://tv.myhome.net.tokyo.jp/!power
=on/"（論文参照）と翻訳し、テレヴィジョン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のブラウザ上で表示すること
ができる。家の中で複数のゲートウェイ・サーバ４を使
用することにより、利用者の行動を自分の場所に従がっ
て適応させることが可能になる。

【００４７】ここでのシステムは、周囲の表示或いは"C
alm 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-awar
e"）機器制御手段を、ゲートウェイ・サーバ４に備える
のが好ましい。このようにすると、HTTPプロトコルに基
づいたユビキタス・コンピューティング環境の構築を達
成できる。

【００５４】次に、本発明の第２実施例を図４〜図６に
基づき説明する。ここでは、バーチャルオーバーレイネ
ットワークへの展開を例にした実施例を詳述する。

【００５５】実施例の説明に入る前に、ここでいうオー
バーレイ・ネットワークとは、その中に含まれる基本ネ
ットワークがいくつかの上位ネットワークを支援する為
に使用される構成として定義でき、ヴァーチャル・オー
バーレイ・ネットワークを実現するための基本特性の十
分なセットを提供する。ヴァーチャル・オーバーレイ・
ネットワークは、新しいアブストラクト特性を提供する
為のソフトウェア層を加えることにより、オーバーレイ
・ネットワークの基本特性を拡張する。利用者に代わっ
てその特性を実行することは、各アプリケーションに対
してカスタマイズされる。この考え方は、D.Tennenhous
e氏などが1997年に"IEEE CommunicationMagazine Vol.3
5, 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 stream
ing Media Broadcasts"では、映像や音響の様なマルチ
キャスト連続メディア・データ用のヴァーチャル・オー
バーレイ・ネットワークが提案されてきた。また、J.Ja
nnotti, D.K.Gifford, K.L.Johnson, M.F.Kaashoek, J.
W.O'Toole Jr.氏による"Overcast: Reliable Multicast
ing 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氏による"Hera
ld: Achieving a Global Event Notification Service"
（2001年オぺレーティングシステムのホットトピックス
にある第８回ワークショップ会報）においては、地球規
模のイヴェント・サービスに対するヴァーチャル・オー
バーレイ・ネットワークが提案されてきた。さらに、K.
P.Birman,氏による"Technology Challenges for Virtua
l Overlay Networks"（2000年情報確約および保証にお
ける2000IEEEワークショップ会報）においては、それぞ
れのヴァーチャル・オーバーレイ・ネットワーク用の資
源を分轄する為に使用されるルータパーテーション機構
が提案されてきた。この解決法は、インターネットの総
ての要求を包括的に満足するものではないが、各ドメイ
ンの問題を解決するのには十分である。

【００５９】従来のネットワークに於いて、ヴァーチャ
ル・オーバーレイ・ネットワークの概念は、部分的に採
用されていた。例えばネットワーク上でデータの一斉配
信を効率よく行なうための技術であるマルチキャスト
を、インターネット上で利用できるようにするために構
築された実験ネットワークの一つであるMboneや、現在
のインターネット上におけるマルチキャスト能力のある
IPネットワークが構築され、また6Boneは、現在のイン
ターネット上のIPｖ6ネットワークを発展させるために
利用されてきた。さらに、ドメイン・ネーミング・シス
テムやウェッブ・キャッシング・システムもまた、ヴァ
ーチャル・オーバーレイ・ネットワークと考えられてお
り、アプリケーション特有の方法で、種々の問題を解決
した。

【００６０】こうした既知の提案は、ヴァーチャル・オ
ーバーレイ・ネットワークの概念を採用することによ
り、拡張性を大いに増大したが、これらの提案は、従来
の基礎的データ・リンク・ネットワークは直接使用せ
ず、プロトコルやメッセージの翻訳も明らかに使用して
いない。その点で本実施例におけるシステムは、ヴァー
チャル・オーバーレイ・ネットワークの概念を十分に利
用する努力をしている。

【００６１】システマティックな方法で各アプリケーシ
ョン向けにカスタマイズされたヴァーチャル・オーバー
レイ・ネットワークを開発することは、最も重要な目的
の一つである。しかしながら、この目標の達成は、それ
までの多くの経験から断定できる。ここでは、ネットワ
ーク化された家庭用の機器を統合する為のヴァーチャル
・オーバーレイ・ネットワークの構築について説明す
る。例えば、Jini，UpnP，HAViそしてSOAP（Simple Obj
ect Access Protocol ：他のコンピュータにあるデータ
やサービスを呼び出すためのプロトコル）は、種々の家
庭用機器を制御する為に提供される。クライアント機器
は、もしこれらのプロトコルの総てを支援していなけれ
ば、家庭用の機器を制御することはできない。しかしな
がら、多くのプロトコルを支援することは、大きな記憶
容量を必要とするので非現実的である。また、新しいプ
ロトコルが将来の家庭用機器に提案されたとすれば、新
しいソフトウェアがクライアント機器の中に追加されな
くてはならない。

【００６２】ここでのヴァーチャル・オーバーレイ・ネ
ットワーク22は、クライアント機器によって支援される
プロトコルを家庭用の機器によって支援されるプロトコ
ルに転換することにより、この問題を解決する。この転
換は、機器とネットワークの特性に従がって、各アプリ
ケーション・レベルのゲートウェイ23によって実行され
る。

【００６３】次に、ネットワーク化された家庭用機器を
統合するヴァーチャル・オーバーレイ・ネットワークの
効果を詳細に説明する。ヴァーチャル・オーバーレイ・
ネットワークの設計を動機付ける最終的な目標は、IEEE
1394や、ブルートゥースや、インターネットのような異
質のネットワーク上に置かれた各家庭用機器に対し、ア
プリケーション特有のアブストラクションを提供するこ
とである。ここでは、現行プロトタイプのヴァーチャル
・オーバーレイ・ネットワークの設計とその利用に就い
て説明する。最初に設計の問題点と我々のシステムの概
観を提示し、次にこれまで利用した幾つかの構成要素を
提示する。最後に、現行プロトタイプシステムについて
の幾つかの問題点を説明する。

【００６４】エンドツーエンドの議論は、インターネッ
トに対するシステム設計の原理である。すなわち、複雑
なネットワーク機能は、ネットワークの端末に押し進め
られるものと思われる。しかし現在のインターネットの
全端部は、複雑な計算機ではない。何故ならば、例え
ば、家庭用機器，内蔵コンピュータそして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から応答を受け取る。ゲートウェイ2
3が機器24への通信を終了した時に、終了データはブラ
ウザへ戻される。

【００６９】なお、具体的なURLの記述に関しては、第
１実施例と同様であるのでその説明を省略する。

【００７０】ヴァーチャル・オーバーレイ・ネットワー
ク22の骨組みは、３個の要素、すなわちアプリケーショ
ン・レベルのゲートウェイ23と、端末である制御器と、
そして機器／サービスから成る。機器／サービスは、ア
プリケーション特有のものであるので、ここでは議論し
ない。これ以降は、アプリケーション・レベルのゲート
ウェイ23と制御器を説明する。

【００７１】アプリケーション・レベルのゲートウェイ
23は、図５に示す様に、機器特有のネットワーク（ホー
ムネットワーク）とインターネット間のゲートウェイと
して動作する。アプリケーション・レベルのゲートウェ
イ23は、前述したようにHTTPに基づく制御方法と種々の
ミドルウェア制御方法との間の橋渡しを行なう。

【００７２】アプリケーション・レベルのゲートウェイ
23は、４つの構成要素から成る。第一の構成要素は、HA
Vi,Jini或いはUPnPのようなホーム・ネットワーク・プロ
トコルを実行するもので、これはホーム・ネットワーク
装置として動作する。例えば、もしその構成要素がJini
プロトコルを実行するならば、構成要素はJini装置とし
て動作する。第二の構成要素はHTTPプロトコルを実行す
るもので、この構成要素はウェッブ・サーバとして動作
する。

【００７３】第三の構成要素はプロトコルの翻訳を実行
するもので、この翻訳手段は、前述のようなHTTP処理と
特殊なホーム・ネットワーク・プロトコル間の変換を行
なう。例えば、HAVi翻訳手段は、HTTPプロトコルからHA
Viプロトコルへのまたその逆の変換を行なう。さらに現
行プロトタイプの実行にて、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"，"h
ttp://my.home.net"，"http://foo.bar.net"というURL
を有し、アプリケーション特有のプロトコル、すなわち
UpnP，HAViそしてJiniを使用している。

【００７９】一つの例として、HAViネットワーク22Ａ上
にあるVCR装置31を、PDA32からUPnPネットワーク22Ｃへ
制御したい場合を想定して見よう。HAViネットワーク22
Ａ中で、VCR装置31は“VCR”として登録されており、そ
のアプリケーション・レベルのゲートウェイ23Ａ（HAV
i,ApGW）は、HAViの照会サービスにおいて“apgw”とし
て登録されている。また、UPnPネットワーク22Ｃにある
PDA32は、"PDA”として登録されており、そのアプリケ
ーション・レベルのゲートウェイ23Ｃ(UPnP,ApGW)は、U
pnPの照会サービスにおいて“apgw”として登録されて
いる。

【００８０】そして最初に、UPnPネットワーク22Ｃにあ
るPDA32からHAViネットワーク22Ａ上にあるVCR装置31を
制御する為に、UpnPネットワーク22Ｃ中にHAViネットワ
ーク22Ａ上にあるVCR装置31を登録する必要がある。PDA
32によって、利用者はPDA32上で展開するウェッブ・ブ
ラウザから、UPnPアプリケーション・レベルのゲートウ
ェイ23Ｃ内に、”http://my.home.net/VCR"としてVCR装
置31を登録する。これは、http://any.where.net/!regi
ster="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/V
CR"のホスト名部分に従がって、HAViアプリケーション
・レベルのゲートウェイ23Ａにその要求を転送する。HA
Viアプリケーション・レベルのゲートウェイ23Ａは、変
換されたHTTP要求を受け取り、HAVi照会サービスを通じ
てURLのファイル名の中で指定された”VCR”によって、
実際のVCR装置31を発見する。最後に、コマンドはHAVi
コマンドに変換され、目標のVCR装置31へ配達される。

【００８２】ヴァーチャル・オーバーレイ・ネットワー
クの骨組みを現在使用している中で、各アプリケーショ
ン・レベルのゲートウェイ23は、スタンドアロン処理と
して実行するJava（登録商標）・アプリケーションとし
て利用されると共に、家庭用機器に対するHTTP基礎のイ
ンターフェイスと、管理機器用のサービスディスカバリ
ーシステムとを提供する。各アプリケーション・レベル
のゲートウェイ23は、その受信したURLを含む属性を解
釈する簡単な記憶データベースを有する。更に、Jiniと
UPnPのようなその基本サービスディスカバリーシステム
と協同して、未知の属性を処理することもできる。

【００８３】続いて、ゲートウェイへ送り出すコマンド
と同様に、利用者の好みや個人的な認証や環境情報等の
ような追加情報の送り出しを可能にする制御器の拡張に
ついて説明する。HTTP基礎の制御コマンドを自分自身に
より発生可能な制御器が、種々の量の情報を送る為に使
用されることで、制御器とゲートウェイ間の協力的関係
が向上する。その様な情報の例は、利用者用にカスタマ
イズされた設定と環境変数を含む。ここでの制御器は、
上記提案したようなコマンドを発生することのできる拡
張されたウェッブ・ブラウザである。拡張されたウェッ
ブ・ブラウザは、それが送るHTTP基礎のコマンドに内蔵
させることにより、環境変数をゲートウェイに送ること
が出来る。環境変数が内蔵される前のHTTP基礎のコマン
ドは、例えば、"http://%(HOME)/?OWNER=%(USER)&?loca
tion=%(LOC)&?function=tv/!power=on"として表わせ
る。このコマンドは、所有者が“利用者”であり、位置
が“HOME”内の"LOC”にあるTVセットの電源をオンせ
よ、という意味する。制御器がそれ自身について有する
環境情報を想定しよう。その利用者は、例えば"USER=fo
o"，"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 Interoperabilit
y)は、デジタル音響、映像の消費者用機器を、シームレ
スに接続するためのホーム・ネットワーク標準を提供す
る。HAViはまた、そのプログラム内からの各機器への制
御を可能にするAV機器制御用Java APIをもまた提供す
る。HAViは、十分な帯域幅を持ちデジタル音響、映像の
多数の信号流を伝送できるIEEE1394ネットワーク・イン
ターフェーイスを各機器が有することを仮定している。
しかしながら、こうした要求は、種々の型の機器でHAVi
が広く使用されることを阻害している。

【００８８】将来の家庭用機器において、それらの製造
業者の方針による各種異なる標準を、支援することが期
待されている。しかしながら、これらの標準は、多様な
ホーム・ネットワークをサポートするものではない。こ
こで提案したヴァーチャル・オーバーレイ・ネットワー
クは、総ての家庭用機器が互いに接続され制御すること
を可能にする。

【００８９】OSGi(The Open Services Gateway specifi
cation)は、Javaに基礎を置くアプリケーション層の骨
組みであり、サービス提供者、装置メーカーそして機器
製造業者に、業者には中立のアプリケーションと装置層
APIと機能を提供する。この戦略は、事実上、出現する
総てのホーム・ネットワーク基盤、プロトコルそしてサ
ービスを、現存する住宅電話線、ケーブルTV或いは電線
を使って、バックエンド・サービスとのシームレスな相
互作用を可能にする。この技術は、基盤から独立してい
る必要があり、その結果、種々の計算機環境、通信環
境、消費者向けエレクトロニクスそして家庭用製品と基
盤上での使用が可能となる。オープン・サービス・ゲー
トウェイ仕様は、オープン・システム層とサービス・ゲ
ートウェイ向けのゲートウェイ・インターフェイスの提
供に専門的に焦点を当てるので、現在のネットワーク標
準と企業心を補足し向上させる。これらの内幾つかは、
Jini,ブルートゥース,CAL,CEBus,HAVi,Home API,HOME-P
AN,HomePnP,HomeRFそしてVESAを含んでいる。

【００９０】オープン・サービス・ゲートウェイ仕様は
また、将来の高機能家庭用装置における消費者の投資を
維持する。例えば、今日において、消費者がホームセキ
ュリティプロバイダを別のプロバイダに切り替える時、
内部ネットワークの総てを入れ替えなければならない。
オープン・サービス・ゲートウェイ仕様と互換性のある
装置を選択することにより、消費者は、事実上如何なる
ネットワーク基盤を入れ替える必要無しに、種々の業者
の商品間で、どれにでも切り替えできる。

【００９１】OSGiの利点は、拡張性のあるホーム・ゲー
トウェイを構築する為の骨組みを提供することにある。
拡張性のあるアプリケーション・レベル・ホーム・ゲー
トウェイを履行する為に、この標準が採用される。

【００９２】上記実施例では、ネットワークされた家庭
機器を統合するヴァーチャル・オーバーレイ・ネットワ
ークを提案してきた。ヴァーチャル・オーバーレイ・ネ
ットワークは、メッセージの伝達ルートを決定し、ネッ
トワークと機器の特性に従がってプロトコルとメッセー
ジを変換する。ヴァーチャル・オーバーレイ・ネットワ
ークは、インターネット規模のユビキタス・コンピュー
ティングの実行に非常に有益である。

【００９３】またIP層は、ヴァーチャル・オーバーレイ
・ネットワークの構築に必要な機能性を提供すべきであ
って、複雑な通信を必要とするそれぞれの機器に対し
て、ヴァーチャル・オーバーレイ・ネットワークがカス
タマイズされる。この機能性の大部分は、IP層の上位で
実行されるべきで、さらにそれぞれの機器に対してカス
タマイズされるべきである。したがって、IP層における
機能のサポート（支援）は最小化されるべきで、広域な
方法でIP層に幾つかの進歩した機能を与えることは避け
るべきである、何故ならば、IP層で実行される機能は、
余りにも広範囲過ぎ、実際の進歩したアプリケーション
を構築するには力不足だからである。

【００９４】なお、本発明は上記実施例に限定されるこ
となく、本発明の範囲内で種々の変形実施が可能であ
る。

【００９５】

【発明の効果】本発明の請求項１の構成によれば、ウェ
ブ・サーバを有する家庭用の機器を修正することなく、
複雑なホーム・コンピューティング環境を作るのに必要
なディレクトリサービスや自動構成管理と同様の機能を
持つことが可能になる。

【００９６】本発明の請求項２の構成によれば、HTTPプ
ロトコルに基づいたユビキタス・コンピューティング環
境の構築を達成できる。

【図面の簡単な説明】

【図１】本発明の第１実施例を示すネットワーク構築装
置の全体構成をあらわした概略説明図である。

【図２】同上機器を特定し制御するためのURL記述の一
例を示す図である。

【図３】同上図１におけるネットワーク構築装置を発展
させた例を示す概略説明図である。

【図４】本発明の第２実施例を示すネットワーク構築装
置の概略説明図である。

【図５】同上インターネットとホームネットワークを繋
ぐゲートウェイの機能構成を示す概略説明図である。

【図６】同上ホームネットワークの接続形態を示す概略
説明図である。

【符号の説明】

１ 通信手段（ネットワーク網） ２ 機器 ３ HTTPクライアント（端末） ４ ゲートウェイ・サーバ 11 PDA装置（端末）

───────────────────────────────────────────────────── フロントページの続き Ｆターム(参考） 5B085 AC03 BC00 5B089 GA31 GB01 HB05 JA33 JA35 JA36 KA10 KA11 KB04 5K033 BA01 CB14 DA06 DB18 EC00

Claims (2)

【特許請求の範囲】
1. 【請求項１】 利用者が保有する端末と、ウエッブサー
   バーを内蔵した制御対象となる機器とを接続したネット
   ワーク網にゲートウェイ・サーバを接続し、このゲート
   ウェイ・サーバは、現在利用可能な機器の情報を自動的
   に収集して、その内容を前記端末に提示する自動構成管
   理手段と、前記端末から目標となる機器を制御するコマ
   ンドが発信されると、このコマンドに含まれるURLを翻
   訳して目標となる機器にURLでアクセスする機器アクセ
   ス手段とを備えたことを特徴とする機器統合のためのネ
   ットワーク構築装置。
2. 【請求項２】 HTTPプロトコルを使用して前記機器の制
   御を可能にし、その動作を利用者の状況に応じて変化さ
   せる状況認知機器制御手段を前記ゲートウェイ・サーバ
   に備えたことを特徴とする請求項１記載の機器統合のた
   めのネットワーク構築装置。