複数のスマート環境間をつなぐトンネルとしてのＰ２Ｐネットワーク
【課題】 多種多様なスマート環境を相互に接続し、スマート環境間の差異を乗り越えて、セキュアな相互接続・サービス連携を可能にする。
【解決手段】 単一のサービスアーキテクチャに対応するスマートピアをそれぞれ含む複数のスマート環境の間において、前記スマート環境ごとに異なる通信又はサービスの差異を吸収し、前記スマート環境の境界を越えてサービスを連携可能にするためのP2P ネットワークであって、通信又はサービスの差異を識別するとともに、特定のプロトコルの翻訳機能を持つピアであって、外部と通信する手段を持つ複数のセマンティックピアを含み、前記セマンティックピア は、設定情報として翻訳可能なプロトコルのリストを予め持ち、これらの設定情報が前記P2P ネットワークで共有されている。
【解決手段】 単一のサービスアーキテクチャに対応するスマートピアをそれぞれ含む複数のスマート環境の間において、前記スマート環境ごとに異なる通信又はサービスの差異を吸収し、前記スマート環境の境界を越えてサービスを連携可能にするためのP2P ネットワークであって、通信又はサービスの差異を識別するとともに、特定のプロトコルの翻訳機能を持つピアであって、外部と通信する手段を持つ複数のセマンティックピアを含み、前記セマンティックピア は、設定情報として翻訳可能なプロトコルのリストを予め持ち、これらの設定情報が前記P2P ネットワークで共有されている。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、異種の複数のスマート環境間をつなぐトンネルとして機能するP2Pネットワークに関する。
【背景技術】
【０００２】
将来のユビキタス社会では、多数のセンサや情報機器、各種ネットワークによって構築される環境、スマート環境が遍在すると考えられる。
【０００３】
そのようなユビキタス社会では、ユーザは一つのスマート環境にいるのではなく、様々なスマート環境、例えば、家、駅、オフィス、店舗、学校、ホテルなどを利用する。このとき、移動先の空間と普段の生活空間を接続することができれば、各スマート環境にあるコンテンツやサービスを、その使用が許可されたユーザが快適に利用することが可能になる。例えば、出張先のホテルや飛行場で、自宅の電話やインターホンからの呼び出しを受け取ることも可能になろう。このように、複数のスマート環境が相互に接続することで、ユーザに最適なサービスが提供できるようになると考えられる。
【０００４】
近年、スマート環境の研究は盛んに行われているが、既存研究は単一のスマート環境内に閉じた研究が多く、複数のサービスアーキテクチャ/スマート環境間を接続し、相互に利用可能にする、という研究は少ない。異種スマート環境の相互接続の実例として、2002 年の慶應義塾大学徳田研究室のSmart Space Lab と東京大学青山・森川研究室のSTONE Room をインターネット上で相互接続した例が挙げられる。しかし、これは特定の異種スマート環境における相互接続であった。
【０００５】
我々はこれまで、スマート環境で稼動させるサービスアーキテクチャとして、United Spaces （非特許文献１参照）、cogma （非特許文献２、非特許文献３参照）を研究してきた。特にUnited Spaces では、分散したスマート環境間でセキュアにサービスの連携を行なう機構を実装している。しかし、現状では同じサービスアーキテクチャのスマート環境の接続にとどまっている。同様に、同じサービスアーキテクチャによるスマート環境の接続を行っている研究として、Instant Matchmaking （非特許文献４参照）がある。
【０００６】
【非特許文献１】Yu Enokibori, Nobuhiko Nishio "A Secure Extension for Realizing Multi-Institutional Ubiquitous Service System", UCS2004 (2004)
【非特許文献２】河口 信夫，春原 雅志，“Web Codget : Web サーバに移動して動作する組込み機器向け移動ソフトウェア” 情報処理学会ユビキタスコンピューティング研究会/映像情報メディア学会技術報告,2005-UBI-2(8) (2005)
【非特許文献３】Nobuo Kawaguchi "VPcogma: A Light-Weight Cooperative Middleware for Ubiquitous Embedded Devices" International Workshop on Software Architectures for Self-Organization with Pervasive2005 (2005)
【非特許文献４】Diana Smetters, Dirk Balfanz, Glenn Durfee, Trevor Smith, Kyung Hee Lee "Instant Matchmaking: Simple, Secure Virtual Extensionsto Ubiquitous Computing Environments" Ubi-Comp2006 (2006)
【非特許文献５】中野悦史，河口信夫，西尾信彦 “IPv6 Everywhere: IPv6 接続のための適応的トンネル構成機構” IC2006 (2006)
【非特許文献６】Jin Nakazawa, Hideyuki Tokuda, W. Keith Edwards, Umakishore Ramachandran "A Bridging Framework for Universal Interoperability in Pervasive Systems" ICDCS'06 (2006)
【非特許文献７】Jacob Woltersdorf, Nobuhiko Nishio "A Peer-to-Peer Overlay Network for Cooperating, Distributed Smart Environments" (2006)
【非特許文献８】伊藤誠悟, 河口信夫, “Locky.jp：無線 LAN を用いた位置情報・測位ポータル”, 情報処理学会研究会報告(第34回モバイルコンピューティングとユビキタス通信研究会), 2005-MBL-034, pp.24-31(2005)
【非特許文献９】William Adjie-Winoto, Elliot Schwartz, Hari Balakrishnan, Jeremy Lilley "The Design and Implementation of an Intentional Naming System (INS)" SOSP 1999 (1999)
【非特許文献１０】永田 智大, 西尾 信彦, 徳田 英幸 “ASAMA: 適応的なサービス利用管理機構” 情報処理学会 論文誌, Vol.42 (6) 2001年6月pp.1557-1569 (2001)
【非特許文献１１】D. A. Bryan and C. Jennings, "A P2P Approach to SIP Registration and Resource Location", Internet-Draft draft-bryan-sipping-p2p-01 (2005)
【非特許文献１２】Skype http://skype.com/
【非特許文献１３】Place Lab http://www.placelab.org/
【０００７】
本件発明者により「Secure Semantic Tunneling によるスマート環境接続の提案」が発表されている。
【非特許文献１４】http://spa.jssst.or.jp/spa10/
【発明の開示】
【発明が解決しようとする課題】
【０００８】
多種多様なスマート環境を相互に接続し、サービスを連携させるためには、数多くの問題がある。スマート環境は、通信方法、サービスアーキテクチャ、アプリケーション等の様々なレイヤで異なっていることが考えられる。また、外部との接続を考慮されていないスマート環境も多い。更に、外部からスマート環境がコントロールできるようになっても、ただ接続・連携させるだけでは、それは重大なセキュリティホールになり得る。スマート環境はセキュアに接続されなければならない。
【０００９】
上記の問題を解決し、異種のスマート環境を接続・連携するため、本明細書ではSecure Semantic Tunnelingというモデルを提案する。Secure Semantic Tunnelingは、異種スマート環境を接続するトンネルを構築する(tunneling)。このトンネルは、スマート環境間の違いを適応的に判断して、容易につなぐことを可能にする(semantic)。また、許可されたユーザ・スマート環境・サービスだけが通ることができる、という安全性を持つ(secure)。
【課題を解決するための手段】
【００１０】
この発明は、単一のサービスアーキテクチャに対応するスマートピアをそれぞれ含む複数のスマート環境の間において、前記スマート環境ごとに異なる通信又はサービスの差異を吸収し、前記スマート環境の境界を越えてサービスを連携可能にするためのP2P ネットワークであって、
通信又はサービスの差異を識別するとともに、特定のプロトコルの翻訳機能を持つピアであって、外部と通信する手段を持つ複数のセマンティックピアを含み、
前記セマンティックピア は、設定情報として翻訳可能なプロトコルのリストを予め持ち、これらの設定情報が前記P2P ネットワークで共有され、
前記複数のセマンティックピア を組み合わせることにより、異種のスマート環境をつなぐトンネルとして構成されている、ものである。
【００１１】
前記スマート環境とは、多数のセンサや情報機器、各種ネットワークによって構築される環境である。
前記サービスとは、スマート環境における情報機器、また、情報システムを総称したものである。本明細書では、ソフトウェアによる制御・情報取得が可能であるものを意味する。
前記サービスアーキテクチャとは、上記サービスに対して、統一的に制御するための規格・仕様を指す。例えば、ネットワーク接続されたAV機器の制御の標準規格にDLNAがある。
【００１２】
前記P2P ネットワークは、予め定められた処理（例えば、下記（Ａ）又は（Ｂ）の処理）を実行することで、異種スマート環境のサービスを連携させるにあたって、必要なプロトコル変換を適応的に選択するものである。
（Ａ）IPv4 で構成されたスマート環境にあるサービスが、IPv6 で構成されたスマート環境にあるサービスと通信する場合、IPv4 とIPv6 の変換が必要であると判断され、IPv4/IPv6 変換機能を持ったセマンティックピア が変換を行う。
（Ｂ）TCPによる通信を行うTV 会議システムと、UDP による通信を行うTV 会議システムをつなげる場合、セマンティックピア は互いのTV 会議システムが送受信するデータを、TCP 側にはTCP として、UDP 側にはUDP として返す。
【００１３】
前記スマート環境の前記スマートピアから受けた情報に基づき、前記スマート環境のローカルのサービスを発見し、
発見した前記サービスを登録し、
前記スマート環境のうち接続すべきものを決定するために、前記スマートピアからユーザ、場所、サービスを含むオブジェクトを検索するサービス検索クエリを受け、
前記スマートピアへ、前記検索クエリの応答として前記オブジェクトを一意に特定する識別子を送る、ものである。
【００１４】
外部と通信可能なゲートウェイ（GW） ノードを含み、
前記GW ノードは、受け取ったパケットを接続先の前記GW ノードに転送することにより、前記スマート環境内の前記スマートピアを異種の前記スマート環境の前記スマートピアと通信可能とする、ものである。
【００１５】
前記セマンティックピアは、サービスを操作するためのプロトコルにあたるコントロール用のプロトコル及びサービス同士でやりとりされるデータの記述形式にあたるデータ用のプロトコルの変換を行うものである。
【発明を実施するための最良の形態】
【００１６】
以下の説明において、まず、（２）で異種スマート環境の連携における問題を整理する。次に（３）でその問題を解決するための、Secure Semantic Tunneling モデルを提案する。続いてSecure Semantic Tunneling モデルを実現するための設計を、4つの章に分けて述べる。（４）では、スマート環境間の通信を確立する方法について、（５）では、外部からスマート環境内のオブジェクトを検索するシステムについて、（６）では、異種サービスアーキテクチャのプロトコル変換について述べる。（４）から（６）で、異種スマート環境を相互接続・連携するための設計を述べた上で、（７）で適応的な異種スマート環境の連携について述べる。
【００１７】
（２）異種スマート環境の連携における問題
異種スマート環境の連携については、大きく二つの問題がある。
一つは、スマート環境で利用されるサービスアーキテクチャの違いである。異なるサービスアーキテクチャ同士では、サービスの発見・実行の通信プロトコルが異なる上、サービスの記述形式、やり取りされるデータのデータフォーマットが異なる。
【００１８】
次に、スマート環境間の通信に関する接続性の問題がある。スマート環境は、グローバルネットワークからのアクセスを考慮されたものは少ない。そのため、スマート環境を接続させるには、VPN の設定や、グローバルアドレスとNAT の設定が必要になる。これでは、必要に応じて任意のスマート環境を接続させることは難しい。また、IPv6 でスマート環境のネットワークを構築することで、スマート環境外部から接続することも可能だが、IPv6 のネットワークインフラはまだ十分ではない。
【００１９】
このように、異種スマート環境にあるノードが相互に接続してサービスを行うとき、それらのノードは、通信、サービスアーキテクチャ、データフォーマット等の違いを乗り越えなくてはならない。
【００２０】
上記の問題に加え、スマート環境の相互接続と、セキュリティを両立させる必要がある。
【００２１】
（３）Secure Semantic Tunneling モデル
（３．１）Secure Semantic Tunneling のコンセプト
（２）で述べた問題を解決するため、ここでSecure Semantic Tunneling モデルを提案する。
【００２２】
Secure Semantic Tunneling が構築するトンネルは、異種スマート環境をつなげるトンネルであり、どのような通信・サービスの差異(IPv4/v6 、NAT 、サービスアーキテクチャなど)も吸収することができる。このトンネルを通すことで、異種のスマート環境間を越えて、自由かつセキュアにサービスを連携させることができる。
【００２３】
通信の差異を吸収するアプリケーションフレームワークとしては、Skype （非特許文献１２参照）が挙げられるが、Skypeは通信環境の差異のみを吸収するだけである。また、Skype API を利用したSkype アプリケーションにしか対応できない。Secure Semantic Tunnel は、通信とサービスの両方のレイヤを対象として、通信の差異、サービスの差異を吸収する。Secure Semantic Tunnelは、スマート環境を構成するサービスアーキテクチャだけでなく、既存の一般的なネットワークアプリケーションも通ることができる。
【００２４】
（３．２）Secure Semantic Tunneling の設計
本節では、Secure Semantic Tunneling の設計について述べる。
まず、異種スマート環境の接続のパターンについて検討する。異なるサービスアーキテクチャの機器を接続するためには、以下の4 つの観点で設計の選択肢がある（非特許文献６参照）。
【００２５】
1．Translation Model (Direct or Mediated)
2．Semantic Distribution (Scattered or Aggregated)
3．Intermediary Semantics Granularity (Coarse-grained or Fine-grained)
4．Location of Interoperability Layer (At-the-Edge or Infrastructure)
【００２６】
本明細書では、多種多様なスマート環境の相互接続を優先すべき要件とする。そのため、翻訳すべきサービスアーキテクチャの種類が不特定かつ多数であることを想定する。よって我々も、個々の機器・サービスに翻訳機能を実装して様々なサービスアーキテクチャに対応するのではなく、異種の機器・サービスの間に仲介者をおく(Mediated 、Infrastructure)パターンを選択する。スマート環境の間に仲介者を置いたパターン(centralize)を図1 に示す。
【００２７】
図1 では、スマート環境のサービスアーキテクチャの違いを、サービスを表す図形の違いで表している。これは以降の図でも同様である。
【００２８】
この構成(centralize)では、スマート環境は多数存在することを想定すると、仲介者がボトルネックとなりスケールしない。そのため仲介者は、各スマート環境の中で、他のスマート環境とつながるエンドポイントに存在するべきである(gateway)。この構成を図2に示す。
【００２９】
また、異種スマート環境を仲介するために翻訳を行うレイヤは、物理層からアプリケーション層まで多岐にわたり、また、それぞれのレイヤで翻訳を行うプロトコルの種類も、Ethernet とBluetooth 、IPv4 とIPv6 、United Spaces とcogma とUPnP 、と様々である、と考えられる。これを図3 に示す。
【００３０】
（３．３）Semantic P2P Network
このように、仲介者が行う翻訳は、物理層からアプリケーション層まで、多くのレイヤにわたる。また、各レイヤでも、多くのプロトコルの違いがある。そのため、エンドポイントにある仲介者だけに、上記に述べたようなすべての翻訳機能を実装することは困難である。また、新しいアーキテクチャで実装されたスマート環境と接続する場合に、仲介者に新しい翻訳機能をインストールする必要がある。
【００３１】
上記の問題を解決するため、本明細書では、仲介者の機能を分散化したP2P ネットワークを構成し、P2Pネットワーク全体で仲介の機能を実現する、という設計を提案する。この設計を図4 に示す。
【００３２】
まず、スマート環境を構成するピアを、Smart Peer（スマートピア）と呼ぶ。Smart Peer は特に他のスマート環境と通信・連携する手段は持たず、単一のサービスアーキテクチャに対応する。
【００３３】
P2P ネットワークを構成するピアは、通信・サービスの差異を理解し、翻訳するため、Semantic Peer（セマンティックピア）と呼ぶ。Semantic Peer は、スマート環境を構成するSmart Peer の一つだが、外部と通信する手段(グローバルアドレス、IPv6 、など)を持つ。
【００３４】
Semantic Peer が構成するP2P ネットワークは、Semantic P2P Network と呼ぶ。Semantic P2P Networkは、特定のプロトコルの翻訳機能を持つ複数のSemantic Peer を組み合わせて、異種のスマート環境をつなぐトンネルを構成する。このトンネルをSemantic Tunnel と呼ぶ。
【００３５】
仲介者の機能をP2P ネットワークで実現することで、Semantic Tunnel にはスケーラブル・冗長化といった特徴も持たせることができる。また、新しい翻訳機能を持ったSemantic Peer がSemantic P2P Networkに参加すると、Semantic P2P Network に参加している全てのスマート環境で、新しい翻訳機能を利用することができる。
【００３６】
但し、この設計においてはセキュリティを考慮しない。セキュアに仲介者を構成するには、図2 で示したように、接続するスマート環境を特定して、エンドポイントに仲介者を配置する。
【００３７】
Semantic Peer には、設定情報として、翻訳可能なプロトコルのリストを持たせる。設定情報は、例えばIPv4 とIPv6 の変換が可能、Jini とUPnP の変換が可能、といった情報である。これらの設定情報はSemantic P2P Network で共有される。これによりSemanticP2P Network は、必要に応じて最適なSemantic Peerを経由するSemantic Tunnel を構築し、通信・サービスの変換を実現する。
【００３８】
（３．４）Secure Semantic Tunneling で実現する適応性
Secure Semantic Tunneling におけるSemantic とは、異種スマート環境のサービスを連携させるにあたって、必要なプロトコル変換を適応的に選択することを表す。例えば、IPv4 で構成されたスマート環境にあるサービスが、IPv6 で構成されたスマート環境にあるサービスと通信する場合、IPv4 とIPv6 の変換が必要であると判断され、IPv4/IPv6 変換機能を持ったSemantic Peer が変換を行う。また別の例では、TCPによる通信を行うTV 会議システムと、UDP による通信を行うTV 会議システムをつなげる場合、Semantic Peer は互いのTV 会議システムが送受信するデータを、TCP 側にはTCP として、UDP 側にはUDP として返す。
【００３９】
また、Semantic Tunnel はSmart Peer に対して、トンネルの接続先のスマート環境を、同じネットワークのように見せることができる。連携する2 つのスマート環境のサービスアーキテクチャが同じであれば、同一ネットワークに見せることで通信は確立できる。この場合、Semantic Tunnel は、サービスを操作するパケットだけでなく、サービスの発見パケットもトンネリングすればよい。このように、プロトコル変換がない場合には、同一のネットワークに見せる単純なトンネルとなり、そうでない場合はプロトコルを変換するトランスレータになる。接続方式を適応的に選択することもSecure Semantic Tunneling の特徴である。
【００４０】
（３．５）実現方法
本章では、Secure Semantic Tunneling モデルについて述べた。以降の章では、Secure Semantic Tunnelingを実現するための設計について述べる。
【００４１】
Secure Semantic Tunneling モデルではスマート環境を連携させるため、以下のシーケンスを想定する。また、各項に対応する章を示す。
【００４２】
1．連携するサービスを検索し、検索結果としてサービスが属すスマート環境を特定する(（５）)
2．接続先のスマート環境とのトンネルを作る(（４）)
3．適切なプロトコルの変換を行い、サービスとの連携を行う(（６）)
【００４３】
（４）スマート環境間の通信
本章では、異種スマート環境の連携において、特に通信の接続性について述べる。具体的には、スマート環境において外部ネットワークとの接続性を持たせるためのシステムを設計する。ここでこの機能をSemantic Peer に実装する。
【００４４】
（４．１）要件
スマート環境は、プライベートネットワークに構築されることが多く、他のスマート環境とインターネットを越えて接続されることは、あまり考慮されていない。そのため、同種のスマート環境を接続する場合でも、VPN を用いて接続先のスマート環境を同じネットワークにあるように見せる、スマート環境にグローバルアドレスを与えてNAT の設定を行い、クライアントからアクセス可能とする、スマート環境をIPv6のネットワークで構築する、などの、事前の設定が必要となる。
【００４５】
これでは、必要に応じて任意のスマート環境と相互接続することは難しい。これらの問題を解決してスマート環境を相互接続するため、ここで次の要件を設定した。
【００４６】
1．プライベートネットワークに構築されたスマート環境であっても通信可能である
2．1 の状況のスマート環境を通信可能にするにあたって、ネットワーク機器に特殊な設定を行わない
3．スマート環境を構成するホストに特殊なプログラム(VPN クライアントプログラムなど)をインストールしない
【００４７】
1 は、異なるプライベートネットワークにあるスマート環境同士を、どのように通信可能とするか、という要件である。更に2 で、Ad-hoc にスマート環境を通信可能とすることを目指す。スマート環境間を通信可能とするにあたり、VPN の設定や、NAT の設定を行うことは、問題で挙げた事前準備にあたる。また3 は、スマート環境を構成するホストが、プリンターやネットワークメディアプレイヤーなどのPC ではないデバイスであっても、他のスマート環境と通信可能とすることを想定している。
【００４８】
（４．２）概要
上記の要件を満たすため、ここでSecure Semantic Tunneling の設計においてゲートウェイノード(以下、GW ノード)を導入する。GW ノードは、Semantic Peer と同一であるが、ここではSemantic Peer の持つ機能のうち、特に通信の機能についてのみ論じるため、あえてGW ノードと呼ぶ。
【００４９】
GW ノードは、スマート環境において、外部と通信可能なノードである。GW ノードが他のスマート環境との通信を経由することで、外部との通信手段を持たないノードも、他のスマート環境と通信することが可能となる。Skype では、Skype をインストールしたホストしか他のネットワークのノードと通信することができない。この例で言えば、GW ノードは、Skype をインストールしていないノードでも他のSkype クライアントと通信させる機構である。
【００５０】
（４．３）GW ノード
外部と通信させたいノードは、デフォルトゲートウェイをGW ノードに設定する。GW ノードは受け取ったパケットを、接続先のGW ノードに転送する。内部のノード(Smart Peer)から見て、GW ノードはデフォルトゲートウェイのプロキシとなる。これによりスマート環境内のノードは、異なるネットワークにあるスマート環境のノードと通信することができる。この構成を図5 に示す。
【００５１】
この構成では、GW ノードがスマート環境間を透過的に見せるときに、2 つのネットワークのアドレス体系を考慮する必要がない。つまり、接続先のスマート環境のホストに、ローカルのホストと重複したアドレスがあったとしても、多対多のアドレス変換を行うことで、アドレスの重複を解決する。
【００５２】
また、GW ノード間の通信は、適応的に選択される。グローバルアドレスを持たないスマート環境では、GW ノードはNAT 越えを行い、グローバルアドレスを持つ場合は、直接の通信を行う。また、接続するGW ノード同士がIPv6 で通信可能な場合、両者はIPv6 にて通信を行う。
【００５３】
（４．４）名前解決
また、GW ノードには、DNS Proxy の機能を持たせる。これにより、DNS クエリの情報を利用することができるようになり、動的にGW ノードがトンネルの接続先を決定したり、GW ノードに動的にアドレス変換のテーブルにノードを登録する、ということが可能になる。
【００５４】
また、DNS による名前解決を拡張することができる。DNS(ホスト名)は既存のネットワークアプリケーションでも利用するため、（５）で述べるオブジェクトの検索システムをGW ノードに実装することで、既存のネットワークアプリケーションでも異種スマート環境内のホストの名前解決を行うことができる。
【００５５】
但し、実装にあたっては、OS のDNS をキャッシュする機構が、本設計に影響することが考えられる。
【００５６】
（４．５）セキュリティ
GW ノードは、スマート環境間のすべての通信を仲介するため、セキュリティに関する設定はGW ノードに対して行うだけでよい。特に、（５）で述べる、スマート環境内のオブジェクトの指定を利用することで、特定のオブジェクトに対する詳細なアクセス権限の設定が可能である。
【００５７】
（４．６）スマート環境以外からの接続
外部からスマート環境に接続するシナリオとして、ユーザが外出先のホテルから、携帯端末を用いて家のスマート環境に繋げ、家のファイルサーバのコンテンツを、ホテルにあるネットワークメディアプレーヤーで再生する、というシナリオが考えられる。このシナリオでは、ホテルには予めGW ノードはなく、また、ホテルのネットワーク構成を変更することができない。
【００５８】
この場合、携帯端末がGW ノードになることで、家のネットワークと繋げることができる。ただし、これは携帯端末が繋がるだけである。
【００５９】
ホテルのネットワークにあるネットワークメディアプレーヤーなどのサービスを利用したい場合では、ネットワークメディアプレーヤーのデフォルトゲートウェイは変えられない。この場合は、ネットワークメディアプレーヤーからみて、携帯端末が一対多のアドレス変換を行う。また、DNS Proxy も利用できないため、GW ノードのIP アドレスを通信相手として指定するか(NAT)、サービスの発見を行うサービスアーキテクチャの場合、発見のパケットをGW ノードが経由することで解決できると考えられる。
【００６０】
また、上記の問題は、ホテルのネットワークがIPv6で構成される場合、複数のデフォルトゲートウェイを設定できるため、解決することができる。
【００６１】
今後は、GW ノードによる構成を実装した上で、現状の構成だけでは対応しづらいネットワーク環境について検討する。
【００６２】
（４．７）状況検知
（４．６）で述べたように、ユーザは携帯端末を持ってスマート環境を移動することが考えられる。
【００６３】
本明細書では、このような状況において、現在そのホストがどのようなネットワーク・状態にあるかを検出する機構を開発する。この機構は、ホストに常時稼動させておき、例えば、自宅からオフィスに移動したとき、ネットワークが変わったことを自動的に検知させる。この機構には次の二つの目的がある。
【００６４】
第一の目的は、ユーザのいる場所を自動的に判断させることである。ユーザが携帯端末を持ってある場所に行った際、携帯端末の状況と場所名を対応付けて登録しておく。これには、無線LAN のSSID （非特許文献８参照）（非特許文献１３参照）やデフォルトゲートウェイのMAC アドレスが利用できる。こうすることで、次回ユーザが同じ場所に来たときに、そこがどのような場所だったかを自動で判断することができる。
【００６５】
これを発展させることで、ネットワークの情報から場所名という抽象的な情報を導き出すことができ、Semantic P2P Network で異なる表現の場所名を共有することで、セマンティックな場所の検索が行えるようにする。
【００６６】
第二の目的は、トンネルの接続先や最適な接続方法を決定することにある。Skype は、自身が実行されているホストが、どのようなネットワーク・状態なのかを検知する。この状況検知を利用して、（４．３）で述べた、GW ノードによる適応的なトンネル構成を行う。
【００６７】
（５）スマート環境のオブジェクトの検索システム
本章では、外部から、スマート環境内部のユーザ、サービスを、どのように検索・指定するかについて述べる。本章で検討する検索機構は、Semantic P2P Network の構成と、そこでやりとりするデータとして実装される。
【００６８】
（５．１）要件
本明細書では、スマート環境は要求に応じてAd-hocに相互接続されることを想定している。そのため、（４）で述べたスマート環境間のトンネルは、常時接続されているわけではない。そのため、どのスマート環境と接続すればよいかを決定するために、事前にユーザ、場所、サービス(以下、オブジェクト)を検索する必要がある。本システムの概要を図6 に示す。
【００６９】
検索の結果として、オブジェクトを一意にする識別子を受け取る。この識別子は他のスマート環境にあるオブジェクトを識別できなくてはならない。Ad-hocに他のスマート環境に接続するため、この識別子にIPアドレスは利用できない。よって、少なくともホスト名のような方法でオブジェクトを指定する必要がある。
【００７０】
更に、ユーザが多くのスマート環境・サービスを扱うことを考えると、明確にホスト名がわからない状況でも、オブジェクトを特定できることが望ましい。
【００７１】
オブジェクトの検索を行う場合、ユーザ、場所、サービスは、それぞれ異なる特徴を持つ。まず、ユーザは移動し、様々なスマート環境に存在し得る。サービスは、様々なサービスアーキテクチャ、アプリケーションで定義されるため、その記述形式が異なる。場所(スマート環境)はユーザ・サービスを含み、場所が決まれば、ユーザ・サービスが見つけられるようにしたい。これにより、例えばユーザがいる場所にあるサービスを発見する、というクエリを実行することができる。本章で検討する要件を整理し、以下に示す。
【００７２】
1．ユーザ、場所、サービスを検索するためのシステムを、GW ノード（Semantic Peer ）同士のネットワーク(Semantic P2P Network)で実現する
2．一般的な名前解決(DNS 、SIP など)との親和性を持たせ、これらを利用したサービスアーキテクチャ、アプリケーションが動作できるようにする
3．ユーザ、場所、サービスの関係を定義する。検索結果として、ユーザが居る場所のサービスが見つかるようにする
4．ユーザ、場所、サービスを抽象的なクエリで検索できる
5．ユーザは移動したり、サービスは追加されることがあるため、存在通知の仕組みを持たせる
【００７３】
（５．２）アプリケーション
本章で検討する検索システムにより、次のようなアプリケーションを実現することができる。
【００７４】
一般的なTV 会議システムは、接続先のIP アドレスを指定してTV 会議を開始する。本検索システムでは、ユーザを検索することで、そのユーザが現在いるスマート環境が特定できる。TV 会議システムがユーザのラップトップPC ではなく、スマート環境にあるTV 会議システムであっても、ユーザのいる場所のサービスが分かることで、TV 会議を行うことができる。これにより、ユーザがラップトップPC を持ち歩く必要がなく、複数のスマート環境を移動しても、そのときに居る場所のTV 会議システムに接続される。また、ユーザの近くにいる人のPC にTV 会議システムがインストールされていれば、そのPC とTV 会議を行うことも可能である。
【００７５】
このように、接続先にどのようなシステムがあり、ネットワーク環境やIP アドレスがどうなっているかを気にすることなく、ユーザを指定してサービスを実行することが可能になる。
【００７６】
（５．３）検索システム
オブジェクトの検索システムは、Semantic P2P Network で実現する。
Semantic Peer はスマート環境におけるSmart Peerでもある。そのため、Smart Peer が実装しているサービスアーキテクチャによって、スマート環境にどのようなサービスがあるかを知ることができる（非特許文献７参照）。また、スマート環境の場所情報は、Semantic Peer にのみ設定すればよい。
【００７７】
Semantic P2P Network では、DHT を利用して、ユーザ、場所、サービスの情報を共有するとともに、検索の機構を提供する（非特許文献７参照）。
【００７８】
（５．４）クエリ
ユーザ、場所、サービスの関係を考慮したクエリには、Intentional Naming System （非特許文献９参照）やASAMA （非特許文献１０参照）のような属性ベースの検索技術を利用することができる。
【００７９】
本明細書では、これに加えて、検索対象がスマート環境であること、ユーザとサービスが動的であることを考慮する。動的とは、ユーザの場合、ユーザがスマート環境を移動することを指す。サービスの場合、多くのサービスアーキテクチャでは、IP アドレスに依存せず、サービス自身が存在通知を行うことを指す。また、ユーザ、場所、サービスを抽象的なクエリで検索できるように、オントロジーによる検索を検討する。
【００８０】
（５．５）オブジェクトの識別子
クエリの結果は、場所(スマート環境)を表す識別子と、ユーザ、サービスを特定できる識別子になる。
【００８１】
場所の識別子は、Semantic Peer がトンネルを接続しなければならない場所(スマート環境)を表す。
【００８２】
Semantic Peer がトンネルを構築すれば、ユーザやサービスを表す識別子は、サービスやアプリケーションのクライアントにわたされる。そのため、これらの識別子は、一般的に利用されている表現形式が望ましい。但し、特殊なアプリケーションやサービスアーキテクチャでは、独自のユーザアカウントやサービス記述を利用するため、この限りではない。
【００８３】
よってSecure Semantic Tunneling では、ユーザの識別にSIP 、サービスの識別にURL を使用する。URL はスキーム、ホスト名、ポート、パスで構成されることから、サービスを指定するのに最低限の情報を持っていると言える。
【００８４】
また、（４．４）で述べたように、DNS Proxy を利用することで、ホスト名を利用して適応的なトンネルを構築することも可能になると考えられる。一方で、ホスト名はOS のキャッシュの問題があるが、ユーザやサービスのIP アドレスが頻繁に変わらない状況であれば問題がないと考えられる。
【００８５】
（５．６）ユーザの特定
ユーザの識別子に関しては、P2P SIP （非特許文献１１参照）が研究されており、SIP の機構をSemantic P2P Network へ導入することが可能であると判断できる。P2P SIP では、DHT をSIP のLocation Service に利用する。これは仲介機能を分散化させたSemantic P2P Networkのモデルと親和性が高い。
【００８６】
一方、Semantic P2P Network では、ユーザが移動すること、ユーザは場所及び近くのサービスとの関連を持つことから、P2P SIP を拡張する必要があると考えている。また、P2P SIP ではユーザ名の認証の問題があり、これについてはSemantic P2P Network でも解決する必要がある。
【００８７】
（６）異種サービスアーキテクチャの連携
本章では、異種のサービスアーキテクチャを連携させるためのプロトコル変換、及び最適な連携方式について述べる。ここで実現される機構は、Semantic Peerの翻訳機能に実装される。
【００８８】
（６．１）プロトコル変換
ここで、異種のサービスアーキテクチャを翻訳するにあたって、そのプロトコルはコントロール用とデータ用に大別できると考えている。
【００８９】
コントロール用のプロトコルは、サービスを操作するためのプロトコルにあたる。コントロール用のプロトコルは、United Spaces 、cogma 、UPnP 、Jini 、SOAP など多種であるが、一方で多くのサービスアーキテクチャでは、RPC の形式をとる。つまり定型的なプロトコル群であり、そのため、異種のプロトコル間での変換は比較的容易であると考えられる。
【００９０】
データ用のプロトコルは、サービス同士でやりとりされるデータの記述形式にあたる。データの記述形式には、RPC の引数や戻り値で利用されるようなプリミティブ型や、複雑なデータを表現するための構造体、動画や音声などのマルチメディアデータに大別できる。ここで、前者二つは、コントロール用のプロトコルと同じく定型的であり、変換可能であると考えられる。一方、マルチメディアデータに関しては、標準規格を利用することが多く、プロトコル変換を行うことは少ない、と考えられる。
【００９１】
同じデータフォーマットを利用しているが、操作方法だけが違うアプリケーションが多くある、と予想している。
【００９２】
また、多くのサービスアーキテクチャでは、イベントがサポートされている。スマート環境では、イベントの通知は重要な機能である。本件発明を、イベントの記述形式の変換や、スマート環境の外へのイベント通知について適用するようにしてもよい。
【００９３】
本件発明の実装においては、中間言語を用意するのではなく、互いの言語に翻訳し合うことをポイントにおく。
【００９４】
（６．２）サービスアーキテクチャの仲介方式
コントロール用のプロトコルでは、RPC 以外の部分で、サービスアーキテクチャが持つ特徴が問題となる場合がある。サービスアーキテクチャは、それぞれ異なる特徴を持ち、そのため、単純なプロトコルの変換を行うだけではうまく連携することができない場合が考えられる。
【００９５】
例えば、ステートフルな通信を行うサービスアーキテクチャを、ステートレスなサービスアーキテクチャから実行するとき、単純なプロトコル変換だけでは、連携は難しい。United Spaces のようなセキュリティを考慮したサービスアーキテクチャや、cogma のようにソフトウェア移送を行うサービスアーキテクチャを、ごくシンプルなサービスアーキテクチャから実行するときも同様である。
【００９６】
このようなサービスアーキテクチャを連携させるためには、トランスレータ方式ではなく、プロキシ方式が適している、と考えている。プロキシは、サービスアーキテクチャのクライアント実装であり、より特化した実装が可能で、特殊なサービスアーキテクチャのプロトコルを隠蔽することができる。
【００９７】
このように、異種のサービスアーキテクチャを連携させる場合には、仲介する機能として、トランスレータ方式と、プロキシ方式の2 つの方法がある。似通ったサービスアーキテクチャを連携させる場合にはトランスレータ方式、異質なサービスアーキテクチャを連携させる場合にはプロキシ方式が適している。
【００９８】
例えば、スマート環境を相互接続して、Bluetoothマイクとサービスを連携する場合を考える。あるBluetooth 機器に接続させるBluetooth マイクを検索する、という場合であれば、Bluetooth のプロトコルは同じであるため、Bluetooth プロトコルをIP に変換してトンネルの中を通せば、Bluetooth マイクを発見・接続できる。一方、あるサービス(United Spaces やcogma 、UPnP など)に接続したいマイクを検索して、Bluetooth マイクが見つかった、という場合は、より上位のレイヤで処理すべきであり、Bluetooth へのプロキシがあるほうが望ましい。
【００９９】
異種のサービスアーキテクチャの仲介を行うには、上記の2 つの方式が考えられ、それらはサービスアーキテクチャの差異によって、適応的に選択されるべきである。
【０１００】
（７）適応的な異種スマート環境の連携
本章では、異種スマート環境を、動的かつ効率的に連携させる、つまり適応的な、連携手法について述べる。（４）から（６）では、異種スマート環境を接続・連携させることを主目的としていた。本章では、それに加えて、動的に連携させること、異種スマート環境の接続をスケールさせること、に注目する。
【０１０１】
（７．１）適応的な仲介方法の選択
異なるスマート環境に属するSmart Peer 同士を連携させる方法はケースバイケースであるが、（４）から（６）の実装を行うことで、あるケースではどのような仲介が最適であるかを把握している。
【０１０２】
ここで、各レイヤの差異を一つずつ順番に解決していく方法はシンプルではなく、オーバーヘッドが大きくなると予測している。
【０１０３】
同種のサービスアーキテクチャを連携させる場合には、トンネルを構築して同じネットワークにいるように見せることが、最もシンプルである。異種のサービスアーキテクチャを連携させる場合には、6。2 で述べたように、トランスレータ方式とプロキシ方式が選択可能である。また、このようにそれぞれのスマート環境と、サービスアーキテクチャの違いを判別することで、翻訳を行うべきレイヤを選択することができる。
【０１０４】
今後は、Smart Peer がどのような連携をしようとしているかを判断し、最適な仲介方法を選択するためのシステムを検討する。
【０１０５】
（７．２）Semantic P2P Network
スマート環境が多数存在し、それらが相互に連携する場合でも、仲介者は仲介機能を果たさなくてはならない。（３）で述べたように、仲介機能をSemantic P2P Network で実現する手法を検討する。具体的には、（４）から（６）で実装する、仲介の機能を分散化させる。
【０１０６】
（５）では、ユーザ、場所、サービスの検索システムの分散化を達成する。スマート環境の通信の接続性(（４）)とP2P ネットワークによる検索システム(（５）)を連結することで、オブジェクトの検索結果を受けてから、通信のトンネルを確立する、シーケンスが実現できる。
【０１０７】
（６）では、プロトコル変換と翻訳の方式について述べた。これらの翻訳機能をモジュール化し、Semantic P2P Network に配置する。Semantic Peer には翻訳可能なプロトコルを設定し、（５）の検索システムに登録することで、各Semantic Peer の持つ翻訳モジュールを、Semantic P2P Network で利用可能にする。
【０１０８】
（８）まとめ
以上、異種スマート環境の連携を行うための、Secure Semantic Tunneling のコンセプトについて述べ、それを実現するための設計としてP2P ネットワークを採用することの利点について述べた。また、Secure Semantic Tunneling を実現するための設計について、問題を分割して述べた。
【０１０９】
上記のSecure Semantic Tunnelingモデルによって、異種スマート環境間の差異を乗り越えてセキュアな相互接続・サービス連携を可能にする基盤技術が開発できるものと考えられる。
【０１１０】
本発明は、以上の実施の形態に限定されることなく、特許請求の範囲に記載された発明の範囲内で、種々の変更が可能であり、それらも本発明の範囲内に包含されるものであることは言うまでもない。
【図面の簡単な説明】
【０１１１】
【図１】異種スマート環境を連携させるための構成例（シンプルな仲介者の構成(centralize)）の説明図である。
【図２】異種スマート環境を連携させるための構成例（シンプルな仲介者の構成(gateway)）の説明図である。
【図３】異種スマート環境を連携させるための構成例（多層的な仲介機能）の説明図である。
【図４】発明の実施の形態に係るＰ２Ｐネットワーク(Semantic P2P Network)の説明図である。
【図５】発明の実施の形態に係るＧＷノードによるスマート環境の接続の説明図である。
【図６】発明の実施の形態に係るスマート環境のオブジェクトの検索システムの説明図である。
【符号の説明】
【０１１２】
ＧＷ ゲートウエイ
Ｌ 通信のレイヤ
ＭＩ 仲介者
Ｐ２Ｐ Ｐ２Ｐネットワーク
ＳＥＰ セマンティックピア
ＳＰ スマートピア
【技術分野】
【０００１】
この発明は、異種の複数のスマート環境間をつなぐトンネルとして機能するP2Pネットワークに関する。
【背景技術】
【０００２】
将来のユビキタス社会では、多数のセンサや情報機器、各種ネットワークによって構築される環境、スマート環境が遍在すると考えられる。
【０００３】
そのようなユビキタス社会では、ユーザは一つのスマート環境にいるのではなく、様々なスマート環境、例えば、家、駅、オフィス、店舗、学校、ホテルなどを利用する。このとき、移動先の空間と普段の生活空間を接続することができれば、各スマート環境にあるコンテンツやサービスを、その使用が許可されたユーザが快適に利用することが可能になる。例えば、出張先のホテルや飛行場で、自宅の電話やインターホンからの呼び出しを受け取ることも可能になろう。このように、複数のスマート環境が相互に接続することで、ユーザに最適なサービスが提供できるようになると考えられる。
【０００４】
近年、スマート環境の研究は盛んに行われているが、既存研究は単一のスマート環境内に閉じた研究が多く、複数のサービスアーキテクチャ/スマート環境間を接続し、相互に利用可能にする、という研究は少ない。異種スマート環境の相互接続の実例として、2002 年の慶應義塾大学徳田研究室のSmart Space Lab と東京大学青山・森川研究室のSTONE Room をインターネット上で相互接続した例が挙げられる。しかし、これは特定の異種スマート環境における相互接続であった。
【０００５】
我々はこれまで、スマート環境で稼動させるサービスアーキテクチャとして、United Spaces （非特許文献１参照）、cogma （非特許文献２、非特許文献３参照）を研究してきた。特にUnited Spaces では、分散したスマート環境間でセキュアにサービスの連携を行なう機構を実装している。しかし、現状では同じサービスアーキテクチャのスマート環境の接続にとどまっている。同様に、同じサービスアーキテクチャによるスマート環境の接続を行っている研究として、Instant Matchmaking （非特許文献４参照）がある。
【０００６】
【非特許文献１】Yu Enokibori, Nobuhiko Nishio "A Secure Extension for Realizing Multi-Institutional Ubiquitous Service System", UCS2004 (2004)
【非特許文献２】河口 信夫，春原 雅志，“Web Codget : Web サーバに移動して動作する組込み機器向け移動ソフトウェア” 情報処理学会ユビキタスコンピューティング研究会/映像情報メディア学会技術報告,2005-UBI-2(8) (2005)
【非特許文献３】Nobuo Kawaguchi "VPcogma: A Light-Weight Cooperative Middleware for Ubiquitous Embedded Devices" International Workshop on Software Architectures for Self-Organization with Pervasive2005 (2005)
【非特許文献４】Diana Smetters, Dirk Balfanz, Glenn Durfee, Trevor Smith, Kyung Hee Lee "Instant Matchmaking: Simple, Secure Virtual Extensionsto Ubiquitous Computing Environments" Ubi-Comp2006 (2006)
【非特許文献５】中野悦史，河口信夫，西尾信彦 “IPv6 Everywhere: IPv6 接続のための適応的トンネル構成機構” IC2006 (2006)
【非特許文献６】Jin Nakazawa, Hideyuki Tokuda, W. Keith Edwards, Umakishore Ramachandran "A Bridging Framework for Universal Interoperability in Pervasive Systems" ICDCS'06 (2006)
【非特許文献７】Jacob Woltersdorf, Nobuhiko Nishio "A Peer-to-Peer Overlay Network for Cooperating, Distributed Smart Environments" (2006)
【非特許文献８】伊藤誠悟, 河口信夫, “Locky.jp：無線 LAN を用いた位置情報・測位ポータル”, 情報処理学会研究会報告(第34回モバイルコンピューティングとユビキタス通信研究会), 2005-MBL-034, pp.24-31(2005)
【非特許文献９】William Adjie-Winoto, Elliot Schwartz, Hari Balakrishnan, Jeremy Lilley "The Design and Implementation of an Intentional Naming System (INS)" SOSP 1999 (1999)
【非特許文献１０】永田 智大, 西尾 信彦, 徳田 英幸 “ASAMA: 適応的なサービス利用管理機構” 情報処理学会 論文誌, Vol.42 (6) 2001年6月pp.1557-1569 (2001)
【非特許文献１１】D. A. Bryan and C. Jennings, "A P2P Approach to SIP Registration and Resource Location", Internet-Draft draft-bryan-sipping-p2p-01 (2005)
【非特許文献１２】Skype http://skype.com/
【非特許文献１３】Place Lab http://www.placelab.org/
【０００７】
本件発明者により「Secure Semantic Tunneling によるスマート環境接続の提案」が発表されている。
【非特許文献１４】http://spa.jssst.or.jp/spa10/
【発明の開示】
【発明が解決しようとする課題】
【０００８】
多種多様なスマート環境を相互に接続し、サービスを連携させるためには、数多くの問題がある。スマート環境は、通信方法、サービスアーキテクチャ、アプリケーション等の様々なレイヤで異なっていることが考えられる。また、外部との接続を考慮されていないスマート環境も多い。更に、外部からスマート環境がコントロールできるようになっても、ただ接続・連携させるだけでは、それは重大なセキュリティホールになり得る。スマート環境はセキュアに接続されなければならない。
【０００９】
上記の問題を解決し、異種のスマート環境を接続・連携するため、本明細書ではSecure Semantic Tunnelingというモデルを提案する。Secure Semantic Tunnelingは、異種スマート環境を接続するトンネルを構築する(tunneling)。このトンネルは、スマート環境間の違いを適応的に判断して、容易につなぐことを可能にする(semantic)。また、許可されたユーザ・スマート環境・サービスだけが通ることができる、という安全性を持つ(secure)。
【課題を解決するための手段】
【００１０】
この発明は、単一のサービスアーキテクチャに対応するスマートピアをそれぞれ含む複数のスマート環境の間において、前記スマート環境ごとに異なる通信又はサービスの差異を吸収し、前記スマート環境の境界を越えてサービスを連携可能にするためのP2P ネットワークであって、
通信又はサービスの差異を識別するとともに、特定のプロトコルの翻訳機能を持つピアであって、外部と通信する手段を持つ複数のセマンティックピアを含み、
前記セマンティックピア は、設定情報として翻訳可能なプロトコルのリストを予め持ち、これらの設定情報が前記P2P ネットワークで共有され、
前記複数のセマンティックピア を組み合わせることにより、異種のスマート環境をつなぐトンネルとして構成されている、ものである。
【００１１】
前記スマート環境とは、多数のセンサや情報機器、各種ネットワークによって構築される環境である。
前記サービスとは、スマート環境における情報機器、また、情報システムを総称したものである。本明細書では、ソフトウェアによる制御・情報取得が可能であるものを意味する。
前記サービスアーキテクチャとは、上記サービスに対して、統一的に制御するための規格・仕様を指す。例えば、ネットワーク接続されたAV機器の制御の標準規格にDLNAがある。
【００１２】
前記P2P ネットワークは、予め定められた処理（例えば、下記（Ａ）又は（Ｂ）の処理）を実行することで、異種スマート環境のサービスを連携させるにあたって、必要なプロトコル変換を適応的に選択するものである。
（Ａ）IPv4 で構成されたスマート環境にあるサービスが、IPv6 で構成されたスマート環境にあるサービスと通信する場合、IPv4 とIPv6 の変換が必要であると判断され、IPv4/IPv6 変換機能を持ったセマンティックピア が変換を行う。
（Ｂ）TCPによる通信を行うTV 会議システムと、UDP による通信を行うTV 会議システムをつなげる場合、セマンティックピア は互いのTV 会議システムが送受信するデータを、TCP 側にはTCP として、UDP 側にはUDP として返す。
【００１３】
前記スマート環境の前記スマートピアから受けた情報に基づき、前記スマート環境のローカルのサービスを発見し、
発見した前記サービスを登録し、
前記スマート環境のうち接続すべきものを決定するために、前記スマートピアからユーザ、場所、サービスを含むオブジェクトを検索するサービス検索クエリを受け、
前記スマートピアへ、前記検索クエリの応答として前記オブジェクトを一意に特定する識別子を送る、ものである。
【００１４】
外部と通信可能なゲートウェイ（GW） ノードを含み、
前記GW ノードは、受け取ったパケットを接続先の前記GW ノードに転送することにより、前記スマート環境内の前記スマートピアを異種の前記スマート環境の前記スマートピアと通信可能とする、ものである。
【００１５】
前記セマンティックピアは、サービスを操作するためのプロトコルにあたるコントロール用のプロトコル及びサービス同士でやりとりされるデータの記述形式にあたるデータ用のプロトコルの変換を行うものである。
【発明を実施するための最良の形態】
【００１６】
以下の説明において、まず、（２）で異種スマート環境の連携における問題を整理する。次に（３）でその問題を解決するための、Secure Semantic Tunneling モデルを提案する。続いてSecure Semantic Tunneling モデルを実現するための設計を、4つの章に分けて述べる。（４）では、スマート環境間の通信を確立する方法について、（５）では、外部からスマート環境内のオブジェクトを検索するシステムについて、（６）では、異種サービスアーキテクチャのプロトコル変換について述べる。（４）から（６）で、異種スマート環境を相互接続・連携するための設計を述べた上で、（７）で適応的な異種スマート環境の連携について述べる。
【００１７】
（２）異種スマート環境の連携における問題
異種スマート環境の連携については、大きく二つの問題がある。
一つは、スマート環境で利用されるサービスアーキテクチャの違いである。異なるサービスアーキテクチャ同士では、サービスの発見・実行の通信プロトコルが異なる上、サービスの記述形式、やり取りされるデータのデータフォーマットが異なる。
【００１８】
次に、スマート環境間の通信に関する接続性の問題がある。スマート環境は、グローバルネットワークからのアクセスを考慮されたものは少ない。そのため、スマート環境を接続させるには、VPN の設定や、グローバルアドレスとNAT の設定が必要になる。これでは、必要に応じて任意のスマート環境を接続させることは難しい。また、IPv6 でスマート環境のネットワークを構築することで、スマート環境外部から接続することも可能だが、IPv6 のネットワークインフラはまだ十分ではない。
【００１９】
このように、異種スマート環境にあるノードが相互に接続してサービスを行うとき、それらのノードは、通信、サービスアーキテクチャ、データフォーマット等の違いを乗り越えなくてはならない。
【００２０】
上記の問題に加え、スマート環境の相互接続と、セキュリティを両立させる必要がある。
【００２１】
（３）Secure Semantic Tunneling モデル
（３．１）Secure Semantic Tunneling のコンセプト
（２）で述べた問題を解決するため、ここでSecure Semantic Tunneling モデルを提案する。
【００２２】
Secure Semantic Tunneling が構築するトンネルは、異種スマート環境をつなげるトンネルであり、どのような通信・サービスの差異(IPv4/v6 、NAT 、サービスアーキテクチャなど)も吸収することができる。このトンネルを通すことで、異種のスマート環境間を越えて、自由かつセキュアにサービスを連携させることができる。
【００２３】
通信の差異を吸収するアプリケーションフレームワークとしては、Skype （非特許文献１２参照）が挙げられるが、Skypeは通信環境の差異のみを吸収するだけである。また、Skype API を利用したSkype アプリケーションにしか対応できない。Secure Semantic Tunnel は、通信とサービスの両方のレイヤを対象として、通信の差異、サービスの差異を吸収する。Secure Semantic Tunnelは、スマート環境を構成するサービスアーキテクチャだけでなく、既存の一般的なネットワークアプリケーションも通ることができる。
【００２４】
（３．２）Secure Semantic Tunneling の設計
本節では、Secure Semantic Tunneling の設計について述べる。
まず、異種スマート環境の接続のパターンについて検討する。異なるサービスアーキテクチャの機器を接続するためには、以下の4 つの観点で設計の選択肢がある（非特許文献６参照）。
【００２５】
1．Translation Model (Direct or Mediated)
2．Semantic Distribution (Scattered or Aggregated)
3．Intermediary Semantics Granularity (Coarse-grained or Fine-grained)
4．Location of Interoperability Layer (At-the-Edge or Infrastructure)
【００２６】
本明細書では、多種多様なスマート環境の相互接続を優先すべき要件とする。そのため、翻訳すべきサービスアーキテクチャの種類が不特定かつ多数であることを想定する。よって我々も、個々の機器・サービスに翻訳機能を実装して様々なサービスアーキテクチャに対応するのではなく、異種の機器・サービスの間に仲介者をおく(Mediated 、Infrastructure)パターンを選択する。スマート環境の間に仲介者を置いたパターン(centralize)を図1 に示す。
【００２７】
図1 では、スマート環境のサービスアーキテクチャの違いを、サービスを表す図形の違いで表している。これは以降の図でも同様である。
【００２８】
この構成(centralize)では、スマート環境は多数存在することを想定すると、仲介者がボトルネックとなりスケールしない。そのため仲介者は、各スマート環境の中で、他のスマート環境とつながるエンドポイントに存在するべきである(gateway)。この構成を図2に示す。
【００２９】
また、異種スマート環境を仲介するために翻訳を行うレイヤは、物理層からアプリケーション層まで多岐にわたり、また、それぞれのレイヤで翻訳を行うプロトコルの種類も、Ethernet とBluetooth 、IPv4 とIPv6 、United Spaces とcogma とUPnP 、と様々である、と考えられる。これを図3 に示す。
【００３０】
（３．３）Semantic P2P Network
このように、仲介者が行う翻訳は、物理層からアプリケーション層まで、多くのレイヤにわたる。また、各レイヤでも、多くのプロトコルの違いがある。そのため、エンドポイントにある仲介者だけに、上記に述べたようなすべての翻訳機能を実装することは困難である。また、新しいアーキテクチャで実装されたスマート環境と接続する場合に、仲介者に新しい翻訳機能をインストールする必要がある。
【００３１】
上記の問題を解決するため、本明細書では、仲介者の機能を分散化したP2P ネットワークを構成し、P2Pネットワーク全体で仲介の機能を実現する、という設計を提案する。この設計を図4 に示す。
【００３２】
まず、スマート環境を構成するピアを、Smart Peer（スマートピア）と呼ぶ。Smart Peer は特に他のスマート環境と通信・連携する手段は持たず、単一のサービスアーキテクチャに対応する。
【００３３】
P2P ネットワークを構成するピアは、通信・サービスの差異を理解し、翻訳するため、Semantic Peer（セマンティックピア）と呼ぶ。Semantic Peer は、スマート環境を構成するSmart Peer の一つだが、外部と通信する手段(グローバルアドレス、IPv6 、など)を持つ。
【００３４】
Semantic Peer が構成するP2P ネットワークは、Semantic P2P Network と呼ぶ。Semantic P2P Networkは、特定のプロトコルの翻訳機能を持つ複数のSemantic Peer を組み合わせて、異種のスマート環境をつなぐトンネルを構成する。このトンネルをSemantic Tunnel と呼ぶ。
【００３５】
仲介者の機能をP2P ネットワークで実現することで、Semantic Tunnel にはスケーラブル・冗長化といった特徴も持たせることができる。また、新しい翻訳機能を持ったSemantic Peer がSemantic P2P Networkに参加すると、Semantic P2P Network に参加している全てのスマート環境で、新しい翻訳機能を利用することができる。
【００３６】
但し、この設計においてはセキュリティを考慮しない。セキュアに仲介者を構成するには、図2 で示したように、接続するスマート環境を特定して、エンドポイントに仲介者を配置する。
【００３７】
Semantic Peer には、設定情報として、翻訳可能なプロトコルのリストを持たせる。設定情報は、例えばIPv4 とIPv6 の変換が可能、Jini とUPnP の変換が可能、といった情報である。これらの設定情報はSemantic P2P Network で共有される。これによりSemanticP2P Network は、必要に応じて最適なSemantic Peerを経由するSemantic Tunnel を構築し、通信・サービスの変換を実現する。
【００３８】
（３．４）Secure Semantic Tunneling で実現する適応性
Secure Semantic Tunneling におけるSemantic とは、異種スマート環境のサービスを連携させるにあたって、必要なプロトコル変換を適応的に選択することを表す。例えば、IPv4 で構成されたスマート環境にあるサービスが、IPv6 で構成されたスマート環境にあるサービスと通信する場合、IPv4 とIPv6 の変換が必要であると判断され、IPv4/IPv6 変換機能を持ったSemantic Peer が変換を行う。また別の例では、TCPによる通信を行うTV 会議システムと、UDP による通信を行うTV 会議システムをつなげる場合、Semantic Peer は互いのTV 会議システムが送受信するデータを、TCP 側にはTCP として、UDP 側にはUDP として返す。
【００３９】
また、Semantic Tunnel はSmart Peer に対して、トンネルの接続先のスマート環境を、同じネットワークのように見せることができる。連携する2 つのスマート環境のサービスアーキテクチャが同じであれば、同一ネットワークに見せることで通信は確立できる。この場合、Semantic Tunnel は、サービスを操作するパケットだけでなく、サービスの発見パケットもトンネリングすればよい。このように、プロトコル変換がない場合には、同一のネットワークに見せる単純なトンネルとなり、そうでない場合はプロトコルを変換するトランスレータになる。接続方式を適応的に選択することもSecure Semantic Tunneling の特徴である。
【００４０】
（３．５）実現方法
本章では、Secure Semantic Tunneling モデルについて述べた。以降の章では、Secure Semantic Tunnelingを実現するための設計について述べる。
【００４１】
Secure Semantic Tunneling モデルではスマート環境を連携させるため、以下のシーケンスを想定する。また、各項に対応する章を示す。
【００４２】
1．連携するサービスを検索し、検索結果としてサービスが属すスマート環境を特定する(（５）)
2．接続先のスマート環境とのトンネルを作る(（４）)
3．適切なプロトコルの変換を行い、サービスとの連携を行う(（６）)
【００４３】
（４）スマート環境間の通信
本章では、異種スマート環境の連携において、特に通信の接続性について述べる。具体的には、スマート環境において外部ネットワークとの接続性を持たせるためのシステムを設計する。ここでこの機能をSemantic Peer に実装する。
【００４４】
（４．１）要件
スマート環境は、プライベートネットワークに構築されることが多く、他のスマート環境とインターネットを越えて接続されることは、あまり考慮されていない。そのため、同種のスマート環境を接続する場合でも、VPN を用いて接続先のスマート環境を同じネットワークにあるように見せる、スマート環境にグローバルアドレスを与えてNAT の設定を行い、クライアントからアクセス可能とする、スマート環境をIPv6のネットワークで構築する、などの、事前の設定が必要となる。
【００４５】
これでは、必要に応じて任意のスマート環境と相互接続することは難しい。これらの問題を解決してスマート環境を相互接続するため、ここで次の要件を設定した。
【００４６】
1．プライベートネットワークに構築されたスマート環境であっても通信可能である
2．1 の状況のスマート環境を通信可能にするにあたって、ネットワーク機器に特殊な設定を行わない
3．スマート環境を構成するホストに特殊なプログラム(VPN クライアントプログラムなど)をインストールしない
【００４７】
1 は、異なるプライベートネットワークにあるスマート環境同士を、どのように通信可能とするか、という要件である。更に2 で、Ad-hoc にスマート環境を通信可能とすることを目指す。スマート環境間を通信可能とするにあたり、VPN の設定や、NAT の設定を行うことは、問題で挙げた事前準備にあたる。また3 は、スマート環境を構成するホストが、プリンターやネットワークメディアプレイヤーなどのPC ではないデバイスであっても、他のスマート環境と通信可能とすることを想定している。
【００４８】
（４．２）概要
上記の要件を満たすため、ここでSecure Semantic Tunneling の設計においてゲートウェイノード(以下、GW ノード)を導入する。GW ノードは、Semantic Peer と同一であるが、ここではSemantic Peer の持つ機能のうち、特に通信の機能についてのみ論じるため、あえてGW ノードと呼ぶ。
【００４９】
GW ノードは、スマート環境において、外部と通信可能なノードである。GW ノードが他のスマート環境との通信を経由することで、外部との通信手段を持たないノードも、他のスマート環境と通信することが可能となる。Skype では、Skype をインストールしたホストしか他のネットワークのノードと通信することができない。この例で言えば、GW ノードは、Skype をインストールしていないノードでも他のSkype クライアントと通信させる機構である。
【００５０】
（４．３）GW ノード
外部と通信させたいノードは、デフォルトゲートウェイをGW ノードに設定する。GW ノードは受け取ったパケットを、接続先のGW ノードに転送する。内部のノード(Smart Peer)から見て、GW ノードはデフォルトゲートウェイのプロキシとなる。これによりスマート環境内のノードは、異なるネットワークにあるスマート環境のノードと通信することができる。この構成を図5 に示す。
【００５１】
この構成では、GW ノードがスマート環境間を透過的に見せるときに、2 つのネットワークのアドレス体系を考慮する必要がない。つまり、接続先のスマート環境のホストに、ローカルのホストと重複したアドレスがあったとしても、多対多のアドレス変換を行うことで、アドレスの重複を解決する。
【００５２】
また、GW ノード間の通信は、適応的に選択される。グローバルアドレスを持たないスマート環境では、GW ノードはNAT 越えを行い、グローバルアドレスを持つ場合は、直接の通信を行う。また、接続するGW ノード同士がIPv6 で通信可能な場合、両者はIPv6 にて通信を行う。
【００５３】
（４．４）名前解決
また、GW ノードには、DNS Proxy の機能を持たせる。これにより、DNS クエリの情報を利用することができるようになり、動的にGW ノードがトンネルの接続先を決定したり、GW ノードに動的にアドレス変換のテーブルにノードを登録する、ということが可能になる。
【００５４】
また、DNS による名前解決を拡張することができる。DNS(ホスト名)は既存のネットワークアプリケーションでも利用するため、（５）で述べるオブジェクトの検索システムをGW ノードに実装することで、既存のネットワークアプリケーションでも異種スマート環境内のホストの名前解決を行うことができる。
【００５５】
但し、実装にあたっては、OS のDNS をキャッシュする機構が、本設計に影響することが考えられる。
【００５６】
（４．５）セキュリティ
GW ノードは、スマート環境間のすべての通信を仲介するため、セキュリティに関する設定はGW ノードに対して行うだけでよい。特に、（５）で述べる、スマート環境内のオブジェクトの指定を利用することで、特定のオブジェクトに対する詳細なアクセス権限の設定が可能である。
【００５７】
（４．６）スマート環境以外からの接続
外部からスマート環境に接続するシナリオとして、ユーザが外出先のホテルから、携帯端末を用いて家のスマート環境に繋げ、家のファイルサーバのコンテンツを、ホテルにあるネットワークメディアプレーヤーで再生する、というシナリオが考えられる。このシナリオでは、ホテルには予めGW ノードはなく、また、ホテルのネットワーク構成を変更することができない。
【００５８】
この場合、携帯端末がGW ノードになることで、家のネットワークと繋げることができる。ただし、これは携帯端末が繋がるだけである。
【００５９】
ホテルのネットワークにあるネットワークメディアプレーヤーなどのサービスを利用したい場合では、ネットワークメディアプレーヤーのデフォルトゲートウェイは変えられない。この場合は、ネットワークメディアプレーヤーからみて、携帯端末が一対多のアドレス変換を行う。また、DNS Proxy も利用できないため、GW ノードのIP アドレスを通信相手として指定するか(NAT)、サービスの発見を行うサービスアーキテクチャの場合、発見のパケットをGW ノードが経由することで解決できると考えられる。
【００６０】
また、上記の問題は、ホテルのネットワークがIPv6で構成される場合、複数のデフォルトゲートウェイを設定できるため、解決することができる。
【００６１】
今後は、GW ノードによる構成を実装した上で、現状の構成だけでは対応しづらいネットワーク環境について検討する。
【００６２】
（４．７）状況検知
（４．６）で述べたように、ユーザは携帯端末を持ってスマート環境を移動することが考えられる。
【００６３】
本明細書では、このような状況において、現在そのホストがどのようなネットワーク・状態にあるかを検出する機構を開発する。この機構は、ホストに常時稼動させておき、例えば、自宅からオフィスに移動したとき、ネットワークが変わったことを自動的に検知させる。この機構には次の二つの目的がある。
【００６４】
第一の目的は、ユーザのいる場所を自動的に判断させることである。ユーザが携帯端末を持ってある場所に行った際、携帯端末の状況と場所名を対応付けて登録しておく。これには、無線LAN のSSID （非特許文献８参照）（非特許文献１３参照）やデフォルトゲートウェイのMAC アドレスが利用できる。こうすることで、次回ユーザが同じ場所に来たときに、そこがどのような場所だったかを自動で判断することができる。
【００６５】
これを発展させることで、ネットワークの情報から場所名という抽象的な情報を導き出すことができ、Semantic P2P Network で異なる表現の場所名を共有することで、セマンティックな場所の検索が行えるようにする。
【００６６】
第二の目的は、トンネルの接続先や最適な接続方法を決定することにある。Skype は、自身が実行されているホストが、どのようなネットワーク・状態なのかを検知する。この状況検知を利用して、（４．３）で述べた、GW ノードによる適応的なトンネル構成を行う。
【００６７】
（５）スマート環境のオブジェクトの検索システム
本章では、外部から、スマート環境内部のユーザ、サービスを、どのように検索・指定するかについて述べる。本章で検討する検索機構は、Semantic P2P Network の構成と、そこでやりとりするデータとして実装される。
【００６８】
（５．１）要件
本明細書では、スマート環境は要求に応じてAd-hocに相互接続されることを想定している。そのため、（４）で述べたスマート環境間のトンネルは、常時接続されているわけではない。そのため、どのスマート環境と接続すればよいかを決定するために、事前にユーザ、場所、サービス(以下、オブジェクト)を検索する必要がある。本システムの概要を図6 に示す。
【００６９】
検索の結果として、オブジェクトを一意にする識別子を受け取る。この識別子は他のスマート環境にあるオブジェクトを識別できなくてはならない。Ad-hocに他のスマート環境に接続するため、この識別子にIPアドレスは利用できない。よって、少なくともホスト名のような方法でオブジェクトを指定する必要がある。
【００７０】
更に、ユーザが多くのスマート環境・サービスを扱うことを考えると、明確にホスト名がわからない状況でも、オブジェクトを特定できることが望ましい。
【００７１】
オブジェクトの検索を行う場合、ユーザ、場所、サービスは、それぞれ異なる特徴を持つ。まず、ユーザは移動し、様々なスマート環境に存在し得る。サービスは、様々なサービスアーキテクチャ、アプリケーションで定義されるため、その記述形式が異なる。場所(スマート環境)はユーザ・サービスを含み、場所が決まれば、ユーザ・サービスが見つけられるようにしたい。これにより、例えばユーザがいる場所にあるサービスを発見する、というクエリを実行することができる。本章で検討する要件を整理し、以下に示す。
【００７２】
1．ユーザ、場所、サービスを検索するためのシステムを、GW ノード（Semantic Peer ）同士のネットワーク(Semantic P2P Network)で実現する
2．一般的な名前解決(DNS 、SIP など)との親和性を持たせ、これらを利用したサービスアーキテクチャ、アプリケーションが動作できるようにする
3．ユーザ、場所、サービスの関係を定義する。検索結果として、ユーザが居る場所のサービスが見つかるようにする
4．ユーザ、場所、サービスを抽象的なクエリで検索できる
5．ユーザは移動したり、サービスは追加されることがあるため、存在通知の仕組みを持たせる
【００７３】
（５．２）アプリケーション
本章で検討する検索システムにより、次のようなアプリケーションを実現することができる。
【００７４】
一般的なTV 会議システムは、接続先のIP アドレスを指定してTV 会議を開始する。本検索システムでは、ユーザを検索することで、そのユーザが現在いるスマート環境が特定できる。TV 会議システムがユーザのラップトップPC ではなく、スマート環境にあるTV 会議システムであっても、ユーザのいる場所のサービスが分かることで、TV 会議を行うことができる。これにより、ユーザがラップトップPC を持ち歩く必要がなく、複数のスマート環境を移動しても、そのときに居る場所のTV 会議システムに接続される。また、ユーザの近くにいる人のPC にTV 会議システムがインストールされていれば、そのPC とTV 会議を行うことも可能である。
【００７５】
このように、接続先にどのようなシステムがあり、ネットワーク環境やIP アドレスがどうなっているかを気にすることなく、ユーザを指定してサービスを実行することが可能になる。
【００７６】
（５．３）検索システム
オブジェクトの検索システムは、Semantic P2P Network で実現する。
Semantic Peer はスマート環境におけるSmart Peerでもある。そのため、Smart Peer が実装しているサービスアーキテクチャによって、スマート環境にどのようなサービスがあるかを知ることができる（非特許文献７参照）。また、スマート環境の場所情報は、Semantic Peer にのみ設定すればよい。
【００７７】
Semantic P2P Network では、DHT を利用して、ユーザ、場所、サービスの情報を共有するとともに、検索の機構を提供する（非特許文献７参照）。
【００７８】
（５．４）クエリ
ユーザ、場所、サービスの関係を考慮したクエリには、Intentional Naming System （非特許文献９参照）やASAMA （非特許文献１０参照）のような属性ベースの検索技術を利用することができる。
【００７９】
本明細書では、これに加えて、検索対象がスマート環境であること、ユーザとサービスが動的であることを考慮する。動的とは、ユーザの場合、ユーザがスマート環境を移動することを指す。サービスの場合、多くのサービスアーキテクチャでは、IP アドレスに依存せず、サービス自身が存在通知を行うことを指す。また、ユーザ、場所、サービスを抽象的なクエリで検索できるように、オントロジーによる検索を検討する。
【００８０】
（５．５）オブジェクトの識別子
クエリの結果は、場所(スマート環境)を表す識別子と、ユーザ、サービスを特定できる識別子になる。
【００８１】
場所の識別子は、Semantic Peer がトンネルを接続しなければならない場所(スマート環境)を表す。
【００８２】
Semantic Peer がトンネルを構築すれば、ユーザやサービスを表す識別子は、サービスやアプリケーションのクライアントにわたされる。そのため、これらの識別子は、一般的に利用されている表現形式が望ましい。但し、特殊なアプリケーションやサービスアーキテクチャでは、独自のユーザアカウントやサービス記述を利用するため、この限りではない。
【００８３】
よってSecure Semantic Tunneling では、ユーザの識別にSIP 、サービスの識別にURL を使用する。URL はスキーム、ホスト名、ポート、パスで構成されることから、サービスを指定するのに最低限の情報を持っていると言える。
【００８４】
また、（４．４）で述べたように、DNS Proxy を利用することで、ホスト名を利用して適応的なトンネルを構築することも可能になると考えられる。一方で、ホスト名はOS のキャッシュの問題があるが、ユーザやサービスのIP アドレスが頻繁に変わらない状況であれば問題がないと考えられる。
【００８５】
（５．６）ユーザの特定
ユーザの識別子に関しては、P2P SIP （非特許文献１１参照）が研究されており、SIP の機構をSemantic P2P Network へ導入することが可能であると判断できる。P2P SIP では、DHT をSIP のLocation Service に利用する。これは仲介機能を分散化させたSemantic P2P Networkのモデルと親和性が高い。
【００８６】
一方、Semantic P2P Network では、ユーザが移動すること、ユーザは場所及び近くのサービスとの関連を持つことから、P2P SIP を拡張する必要があると考えている。また、P2P SIP ではユーザ名の認証の問題があり、これについてはSemantic P2P Network でも解決する必要がある。
【００８７】
（６）異種サービスアーキテクチャの連携
本章では、異種のサービスアーキテクチャを連携させるためのプロトコル変換、及び最適な連携方式について述べる。ここで実現される機構は、Semantic Peerの翻訳機能に実装される。
【００８８】
（６．１）プロトコル変換
ここで、異種のサービスアーキテクチャを翻訳するにあたって、そのプロトコルはコントロール用とデータ用に大別できると考えている。
【００８９】
コントロール用のプロトコルは、サービスを操作するためのプロトコルにあたる。コントロール用のプロトコルは、United Spaces 、cogma 、UPnP 、Jini 、SOAP など多種であるが、一方で多くのサービスアーキテクチャでは、RPC の形式をとる。つまり定型的なプロトコル群であり、そのため、異種のプロトコル間での変換は比較的容易であると考えられる。
【００９０】
データ用のプロトコルは、サービス同士でやりとりされるデータの記述形式にあたる。データの記述形式には、RPC の引数や戻り値で利用されるようなプリミティブ型や、複雑なデータを表現するための構造体、動画や音声などのマルチメディアデータに大別できる。ここで、前者二つは、コントロール用のプロトコルと同じく定型的であり、変換可能であると考えられる。一方、マルチメディアデータに関しては、標準規格を利用することが多く、プロトコル変換を行うことは少ない、と考えられる。
【００９１】
同じデータフォーマットを利用しているが、操作方法だけが違うアプリケーションが多くある、と予想している。
【００９２】
また、多くのサービスアーキテクチャでは、イベントがサポートされている。スマート環境では、イベントの通知は重要な機能である。本件発明を、イベントの記述形式の変換や、スマート環境の外へのイベント通知について適用するようにしてもよい。
【００９３】
本件発明の実装においては、中間言語を用意するのではなく、互いの言語に翻訳し合うことをポイントにおく。
【００９４】
（６．２）サービスアーキテクチャの仲介方式
コントロール用のプロトコルでは、RPC 以外の部分で、サービスアーキテクチャが持つ特徴が問題となる場合がある。サービスアーキテクチャは、それぞれ異なる特徴を持ち、そのため、単純なプロトコルの変換を行うだけではうまく連携することができない場合が考えられる。
【００９５】
例えば、ステートフルな通信を行うサービスアーキテクチャを、ステートレスなサービスアーキテクチャから実行するとき、単純なプロトコル変換だけでは、連携は難しい。United Spaces のようなセキュリティを考慮したサービスアーキテクチャや、cogma のようにソフトウェア移送を行うサービスアーキテクチャを、ごくシンプルなサービスアーキテクチャから実行するときも同様である。
【００９６】
このようなサービスアーキテクチャを連携させるためには、トランスレータ方式ではなく、プロキシ方式が適している、と考えている。プロキシは、サービスアーキテクチャのクライアント実装であり、より特化した実装が可能で、特殊なサービスアーキテクチャのプロトコルを隠蔽することができる。
【００９７】
このように、異種のサービスアーキテクチャを連携させる場合には、仲介する機能として、トランスレータ方式と、プロキシ方式の2 つの方法がある。似通ったサービスアーキテクチャを連携させる場合にはトランスレータ方式、異質なサービスアーキテクチャを連携させる場合にはプロキシ方式が適している。
【００９８】
例えば、スマート環境を相互接続して、Bluetoothマイクとサービスを連携する場合を考える。あるBluetooth 機器に接続させるBluetooth マイクを検索する、という場合であれば、Bluetooth のプロトコルは同じであるため、Bluetooth プロトコルをIP に変換してトンネルの中を通せば、Bluetooth マイクを発見・接続できる。一方、あるサービス(United Spaces やcogma 、UPnP など)に接続したいマイクを検索して、Bluetooth マイクが見つかった、という場合は、より上位のレイヤで処理すべきであり、Bluetooth へのプロキシがあるほうが望ましい。
【００９９】
異種のサービスアーキテクチャの仲介を行うには、上記の2 つの方式が考えられ、それらはサービスアーキテクチャの差異によって、適応的に選択されるべきである。
【０１００】
（７）適応的な異種スマート環境の連携
本章では、異種スマート環境を、動的かつ効率的に連携させる、つまり適応的な、連携手法について述べる。（４）から（６）では、異種スマート環境を接続・連携させることを主目的としていた。本章では、それに加えて、動的に連携させること、異種スマート環境の接続をスケールさせること、に注目する。
【０１０１】
（７．１）適応的な仲介方法の選択
異なるスマート環境に属するSmart Peer 同士を連携させる方法はケースバイケースであるが、（４）から（６）の実装を行うことで、あるケースではどのような仲介が最適であるかを把握している。
【０１０２】
ここで、各レイヤの差異を一つずつ順番に解決していく方法はシンプルではなく、オーバーヘッドが大きくなると予測している。
【０１０３】
同種のサービスアーキテクチャを連携させる場合には、トンネルを構築して同じネットワークにいるように見せることが、最もシンプルである。異種のサービスアーキテクチャを連携させる場合には、6。2 で述べたように、トランスレータ方式とプロキシ方式が選択可能である。また、このようにそれぞれのスマート環境と、サービスアーキテクチャの違いを判別することで、翻訳を行うべきレイヤを選択することができる。
【０１０４】
今後は、Smart Peer がどのような連携をしようとしているかを判断し、最適な仲介方法を選択するためのシステムを検討する。
【０１０５】
（７．２）Semantic P2P Network
スマート環境が多数存在し、それらが相互に連携する場合でも、仲介者は仲介機能を果たさなくてはならない。（３）で述べたように、仲介機能をSemantic P2P Network で実現する手法を検討する。具体的には、（４）から（６）で実装する、仲介の機能を分散化させる。
【０１０６】
（５）では、ユーザ、場所、サービスの検索システムの分散化を達成する。スマート環境の通信の接続性(（４）)とP2P ネットワークによる検索システム(（５）)を連結することで、オブジェクトの検索結果を受けてから、通信のトンネルを確立する、シーケンスが実現できる。
【０１０７】
（６）では、プロトコル変換と翻訳の方式について述べた。これらの翻訳機能をモジュール化し、Semantic P2P Network に配置する。Semantic Peer には翻訳可能なプロトコルを設定し、（５）の検索システムに登録することで、各Semantic Peer の持つ翻訳モジュールを、Semantic P2P Network で利用可能にする。
【０１０８】
（８）まとめ
以上、異種スマート環境の連携を行うための、Secure Semantic Tunneling のコンセプトについて述べ、それを実現するための設計としてP2P ネットワークを採用することの利点について述べた。また、Secure Semantic Tunneling を実現するための設計について、問題を分割して述べた。
【０１０９】
上記のSecure Semantic Tunnelingモデルによって、異種スマート環境間の差異を乗り越えてセキュアな相互接続・サービス連携を可能にする基盤技術が開発できるものと考えられる。
【０１１０】
本発明は、以上の実施の形態に限定されることなく、特許請求の範囲に記載された発明の範囲内で、種々の変更が可能であり、それらも本発明の範囲内に包含されるものであることは言うまでもない。
【図面の簡単な説明】
【０１１１】
【図１】異種スマート環境を連携させるための構成例（シンプルな仲介者の構成(centralize)）の説明図である。
【図２】異種スマート環境を連携させるための構成例（シンプルな仲介者の構成(gateway)）の説明図である。
【図３】異種スマート環境を連携させるための構成例（多層的な仲介機能）の説明図である。
【図４】発明の実施の形態に係るＰ２Ｐネットワーク(Semantic P2P Network)の説明図である。
【図５】発明の実施の形態に係るＧＷノードによるスマート環境の接続の説明図である。
【図６】発明の実施の形態に係るスマート環境のオブジェクトの検索システムの説明図である。
【符号の説明】
【０１１２】
ＧＷ ゲートウエイ
Ｌ 通信のレイヤ
ＭＩ 仲介者
Ｐ２Ｐ Ｐ２Ｐネットワーク
ＳＥＰ セマンティックピア
ＳＰ スマートピア
【特許請求の範囲】
【請求項１】
単一のサービスアーキテクチャに対応するスマートピアをそれぞれ含む複数のスマート環境の間において、前記スマート環境ごとに異なる通信又はサービスの差異を吸収し、前記スマート環境の境界を越えてサービスを連携可能にするためのP2P ネットワークであって、
通信又はサービスの差異を識別するとともに、特定のプロトコルの翻訳機能を持つピアであって、外部と通信する手段を持つ複数のセマンティックピアを含み、
前記セマンティックピア は、設定情報として翻訳可能なプロトコルのリストを予め持ち、これらの設定情報が前記P2P ネットワークで共有され、
前記複数のセマンティックピア を組み合わせることにより、異種のスマート環境をつなぐトンネルとして構成されていることを特徴とするP2P ネットワーク。
【請求項２】
前記P2P ネットワークは、予め定められた処理を実行することで、異種スマート環境のサービスを連携させるにあたって、必要なプロトコル変換を適応的に選択することを特徴とする請求項１記載のP2P ネットワーク。
【請求項３】
前記スマート環境の前記スマートピアから受けた情報に基づき、前記スマート環境のローカルのサービスを発見し、
発見した前記サービスを登録し、
前記スマート環境のうち接続すべきものを決定するために、前記スマートピアからユーザ、場所、サービスを含むオブジェクトを検索するサービス検索クエリを受け、
前記スマートピアへ、前記検索クエリの応答として前記オブジェクトを一意に特定する識別子を送る、ことを特徴とする請求項１記載のP2P ネットワーク。
【請求項４】
外部と通信可能なゲートウェイ（GW） ノードを含み、
前記GW ノードは、受け取ったパケットを接続先の前記GW ノードに転送することにより、前記スマート環境内の前記スマートピアを異種の前記スマート環境の前記スマートピアと通信可能とする、ことを特徴とする請求項１記載のP2P ネットワーク。
【請求項５】
前記セマンティックピアは、サービスを操作するためのプロトコルにあたるコントロール用のプロトコル及びサービス同士でやりとりされるデータの記述形式にあたるデータ用のプロトコルの変換を行うことを特徴とする請求項１記載のP2P ネットワーク。
【請求項１】
単一のサービスアーキテクチャに対応するスマートピアをそれぞれ含む複数のスマート環境の間において、前記スマート環境ごとに異なる通信又はサービスの差異を吸収し、前記スマート環境の境界を越えてサービスを連携可能にするためのP2P ネットワークであって、
通信又はサービスの差異を識別するとともに、特定のプロトコルの翻訳機能を持つピアであって、外部と通信する手段を持つ複数のセマンティックピアを含み、
前記セマンティックピア は、設定情報として翻訳可能なプロトコルのリストを予め持ち、これらの設定情報が前記P2P ネットワークで共有され、
前記複数のセマンティックピア を組み合わせることにより、異種のスマート環境をつなぐトンネルとして構成されていることを特徴とするP2P ネットワーク。
【請求項２】
前記P2P ネットワークは、予め定められた処理を実行することで、異種スマート環境のサービスを連携させるにあたって、必要なプロトコル変換を適応的に選択することを特徴とする請求項１記載のP2P ネットワーク。
【請求項３】
前記スマート環境の前記スマートピアから受けた情報に基づき、前記スマート環境のローカルのサービスを発見し、
発見した前記サービスを登録し、
前記スマート環境のうち接続すべきものを決定するために、前記スマートピアからユーザ、場所、サービスを含むオブジェクトを検索するサービス検索クエリを受け、
前記スマートピアへ、前記検索クエリの応答として前記オブジェクトを一意に特定する識別子を送る、ことを特徴とする請求項１記載のP2P ネットワーク。
【請求項４】
外部と通信可能なゲートウェイ（GW） ノードを含み、
前記GW ノードは、受け取ったパケットを接続先の前記GW ノードに転送することにより、前記スマート環境内の前記スマートピアを異種の前記スマート環境の前記スマートピアと通信可能とする、ことを特徴とする請求項１記載のP2P ネットワーク。
【請求項５】
前記セマンティックピアは、サービスを操作するためのプロトコルにあたるコントロール用のプロトコル及びサービス同士でやりとりされるデータの記述形式にあたるデータ用のプロトコルの変換を行うことを特徴とする請求項１記載のP2P ネットワーク。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２００８−２８２０８０（Ｐ２００８−２８２０８０Ａ）
【公開日】平成２０年１１月２０日（２００８．１１．２０）
【国際特許分類】
【出願番号】特願２００７−１２３３７２（Ｐ２００７−１２３３７２）
【出願日】平成１９年５月８日（２００７．５．８）
【新規性喪失の例外の表示】特許法第３０条第１項適用申請有り 平成１８年１１月９日発行 社団法人情報処理学会研究報告 情処研報 Ｖｏｌ．２００６，Ｎｏ．１１６ ｐ．１３−ｐ．２０
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＥＴＨＥＲＮＥＴ
２．Ｂｌｕｅｔｏｏｔｈ
【出願人】（０００１５２２２８）株式会社内田洋行 (105)
【出願人】（５９３００６６３０）学校法人立命館 (359)
【出願人】（５０４１３９６６２）国立大学法人名古屋大学 (996)
【Ｆターム（参考）】
【公開日】平成２０年１１月２０日（２００８．１１．２０）
【国際特許分類】
【出願日】平成１９年５月８日（２００７．５．８）
【新規性喪失の例外の表示】特許法第３０条第１項適用申請有り 平成１８年１１月９日発行 社団法人情報処理学会研究報告 情処研報 Ｖｏｌ．２００６，Ｎｏ．１１６ ｐ．１３−ｐ．２０
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＥＴＨＥＲＮＥＴ
２．Ｂｌｕｅｔｏｏｔｈ
【出願人】（０００１５２２２８）株式会社内田洋行 (105)
【出願人】（５９３００６６３０）学校法人立命館 (359)
【出願人】（５０４１３９６６２）国立大学法人名古屋大学 (996)
【Ｆターム（参考）】
[ Back to top ]