Traitement en cours

Veuillez attendre...

Paramétrages

Paramétrages

Aller à Demande

1. WO2004055687 - SYSTEME DE DISTRIBUTION ET PROCEDE DE FORMATION D'UN ENVIRONNEMENT D'EMISSION/RECEPTION DE SERVICES

Note: Texte fondé sur des processus automatiques de reconnaissance optique de caractères. Seule la version PDF a une valeur juridique

[ JA ]
明細書

分散システムおよびサービス授受環境形成方法

技術分野

本発明は、データ処理を行なう処理部と他の装置との間の通信を行な う通信部とを備えた機器が複数接続され、それぞれが連携して処理を行 なう分散システムに関する。特にサ一ビスを提供するために、各機器が 提供する計算機資源やプログラム、データ等の資源を、受けるサービス に応じて適切な連携を構築する技術に関する。ビル · ホームォ一トメ一 シヨンシステム、プラン卜制御や製造、物流などの社会システム、交通 システムなどの制御システム、などにおいて好適に適合しうる。

背景技術

社会基盤の設備や機器に浸透した計算機資源を、物理環境や時間、サ —ビスの利用者や周囲の人を含むユーザ状態、可用な計算機、ネットヮ —クなどの状況に応じて柔軟に活用して連携させ、サービスを提供する ことが可能となりつつある。これは例えば、ビルや街などの公共スぺー スにおいて、利用者の近くにある任意の情報端末を情報サービス出力先 として用いたり、音響設備を組み合わせてマルチメディァコンテンツを 出力したりするものである。または、プラント制御設備の持つデ一夕や、 該設備から発信されるィベントに応じて保守員端末や作業員端末へデー 夕を配信したり、設備の稼動状態を制御したりするものである。こうし たシステムでは、特定のサービスを提供するために、計算機ゃ該計算機 に接続した入出力装置、ソフトウェアやデータなどの資源から、サービ スの提供に有効となる適切な資源を選択し、連携させることが必要とな る。ここで、状況は変化していくため、サービスを提供する時点になら ないと適切な資源は解からない。このため、動的な資源の発見と資源間 での連携が必要となる。また、こうした資源の発見や資源間の連携には、 サービスを提供するために各資源の提供する機能に加えて、セキユリテ ィや性能などの条件も考慮する必要がある。

こうした動的な資源の発見を行なう手段として、動的な資源構成を検 出する手段に、プラグアンドプレイと呼ばれる方法がある。これは、例 えば非特許文献 1に記載される。ここでは、機器の提供可能な機能をサ 一ビスとして記述し、ネットワーク接続時に他の機器ヘプロードキャス トする。サービスを利用する機器は、該メッセージを受信するか、利用 するサービスを指定して他の機器を探索するメッセージをブロードキヤ ストし、これに応答した機器の情報から、 'サービス提供に必要な機器を 検索する。ブロードキャストする範囲は、ネットワークの接続した範囲 であり、ホップ数で制限される。

また、特定の条件に基づいてこうした保証を行なう手段として、ポリ シを用いた制御方法がある。これは、セキュリティや QoSなどの非機能 的要求に関して宣言的に制約を記述し、実行制御を行なうものである。 -サービスに応じた個人情報の公開範囲を制御する方法として、例えば World Wide Web Consortium (W3C) で制定されている P 3 P (Platform for Privacy Preferences)がある(例えば、非特許文献 2)。これは、サービ ス提供側サイトで利用する個人情報の種類と該個人情報を公開する他サ ーパを提示し、公開する個人情報と照合してサービスを受けるか否かを 決めるものである。他資源に対する各資源のアクセスを制限する方法と して、例えば "The Ponder Policy Specification Language" 力 Sある (例 えば、非特許文献 3)。これは、特定の資源へのアクセス許可や、公開す るデータ、アクセス時の制約を、タイミングの切り替え条件を、特定の 資源に対して記述するものである。アクセスを許可される特定資源は、 グループとして登録することも可能となっている。

非特許文献 1 :

UPnP Forum Introduction to Universal Plug and Play Lo line] [平成 1 4年 1 2月 1 2 日検索]、ィンターネット <URL:

http: //www. upnp. org/download/Compressea-UPnP„Forum_Mktg_Presenta tion. zip >

非特許文献 2 :

The Platform for Privacy Preferences 1.0 (P3P1.0) Specification W3C Candidate Recommendation 15 December 2000 [on line] [平成 1 4年 1 2月 1 2 日検索]、インターネットく URL :

http://爾. w3. org/TR/2000/CR-P3P-20001215>

非特許文献 3 :

The Ponder Policy Specification Language N. Damianou, N. Dulay, E. Lupu, M Sloman, : The Ponder Specification Language Workshop on Policies for Distributed Systems and Networks (Policy2001) , HP Labs Bristol, 29-31 Jan 2001. [on line] [平成 1 4年 1 2月 1 2 日検索]、 インターネット < URL:

http: / /www. doc. ic. ac. uk/ mss/Papers/Ponder— Po丄 icy0lV5. pdf

上述したプラグアンドプレイ技術では、サービスを探索する範囲がネ ットワークの接続性のみに限定されており、可用なサービスを探索する ために個人情報が漏洩するといつた問題があった。また、前述のように 利用者やサービスに応じて利用する資源が変化するため、サービスと利 用する資源をポリシとして記述し、利用者がサービスを受けるか否かを 判断する従来の方式では、サービスを提供する資源を柔軟に利用するこ とに限界があった。

また、サービスを提供するために連携する機器は、公共に使える Kiosk 端末のようなもめから、特定の利用者しか制御できない入退室制御機器、 サービスを監視 · 管理して課金するサーバのように、セキユリティ設定 が多様なものに跨る。また、こうした機器にはセキュリティ管理機能な どを持つ高仕様のものから、こうした機能を持たない低仕様のものまで ある。データを持つ資源とアクセス元の資源、性能保証を行なう資源の 組合せは様々であり、全ての資源が、指定されたポリシを実行できると は限らない。あるいは、性能やアクセス時のセキュリティを確保できる

か否かを事前に調べることが困難であることも多く、全ての組合せをポ リシとして記述しておくことは困難である。

発明の開示 - 本発明は上記課題を鑑みてなされたもので、動的に発見した資源群の 中で、サービス提供に有効な資源群のみで柔軟に資源を共有し、要求さ れた条件を満たすサービス授受環境を提供する。

本発明では、データ処理を行なう処理部と、他の装置との間の通信を 行なう通信部とを備えた機器が複数接続され、それぞれが連携して処理 を行なう分散システムに、要求されたサービスに必要な資源を前記複数 の機器から検出する手段と、検出された資源が、資源公開ポリシを満た すか否かを判定する手段と、資源公開ポリシを満たす資源を連携させて サービスを提供する手段とを備えた。

資源公開ポリシを前記資源の秘匿性能または処理性能のいずれかの保 証能力とすることで不正使用によ'るデータ等の漏洩の防止が行なえたり、 サービスの提供スピードを確保したりすることができる。

本発明の一つの側面として、分散システムにセキュリティなどの資源 の保証能力に応じて、公開する資源の範囲、すなわち資源へのアクセス 権を与える範囲を限定するステップと、サービスを、利用可能な資源に 応じたレベルで提示するステップと、上記サービスと資^を照合して、 サービス提供に用いる資源を選択するステップと、を持たせて、サービ スと公開する個人情報に応じて適切な資源を活用してサービス授受を行 なえるようにした。 .

一別の側面として、各資源を公開する目的であるサービスに対応するモ ドを資源と対応付けて保持させておき、サービスを識別して資源への アクセスを行なうステップと、資源提供側は該要求とモードに応じて公 開資源を制限するステップと、を実行することで、所望のサービスを提 供するのに有効な資源以外にデータ公開せず、要求された品質を保って 必要なサービスを形成できるようにした。

吏に別の側面として、サービスを他のサービスを用いて階層的に構成 する際に情報を共有するために、あるサービスを構成する他サービスと の間の関係を管理し、あるサービスを構成する部分サービスへ、他サー ビスの資源公開条件を委譲し、全ての資源の組合せに対して資源利用可 否を記述せずともサービスを形成できるようにした。

事前にモード管理機能を有していない機器に対しては、各機器へ特定 のソフトウェアを配信するステップと、各機器では該ソフトウエアを介 してアプリケーション間のデータ送受信や実行管理を行なうことで、サ 一ビス提供に有効なモードを管理することが出来るようにした。

公開範囲を限定して提供可能なサービスを判定するステップと、公開 範囲を段階的に拡張して提供するサービスを決定するステップとを実行 し、各資源のアクセス権を公開レなければサービスが提供可能か判断で きない場合でも、サービス提供に有効な資源群を段階的に判定すること を可能とした。

図面の簡単な説明

図 1は本発明の一実施例のシステム全体構成を示す図である。

図 2はシステム構成の詳細プロックを示す図である。

図 3はユーザ C o n t e x tテープル 2 1 1の構成例を示す図である。 図 4は要求サービス条件 2 1 4の構成例を示す図である。

図 5はサービスリスト 2 1 2の構成例を示す図である。

図 6は機器群管理テーブル 2 1 3の構成例を示す図である。

図 7はシステム構成管理テーブル 2 1 6の構成例を示す図である。 図 8は資源公開ポリシ 2 1 7の構成例を示す図である。

図 9はサービス形成処理 2 3 2の処理の流れを示す図である。

図 1 0はメッセージ構成例を示す図である。

図 1 1はモード管理テーブル 2 1 5の構成例を示す図である。

図 1 2はサービスセッション管理処理 2 3 3の処理の流れを示す図で ある。 .

図 1 3はサービス形成処理がソフトウェア配信する実施例の処理の流 れを示す図である。

図 1 .4は配信ソフトと既存プログラムの結合例を示す図である。

図 1 5は特定サービスを実現している状況のシステム構成を例示する 図である'。

発明を実施するための最良の形態

以下に、本発明の実施の形態を図面を用いて詳細に説明する。以下の 実施例において、

( 1 ) アクセス権を公開する資源の範囲に応じて、提供可能なサービス のレベルを判定する方法。

( 2 ) 資源群の可用性が事前に記述困難な場合、すなわちアクセス権を 公開してみないと可用資源が判定できない場合の方法として、試行によ り可用資'源を発見 ·選択するために、公開範囲を限定して提供可能なサ 一ビスを判定し、公開範囲を段階的に拡張して提供するサービスを決定 する方法。

( 3 ) 各資源がサービスに対応したモードを持ち、公開する資源の範囲 を制限してサービス提供に用いる情報を共有する方法。

( 4 ) サービスが階層化されている舉合に、各サービスに対応するモー ドの機器間での情報の転送を許可する場合。

( 5 ) 機器がモード管理を行なう機能を持たない場合の方法として、ソ フ トウェアを配信し、該ソフトウェアにより機器のモード管理を行なう 方法。

のそれぞれについて詳細に説明する。

図 1は本発明を適用したシステムの一実施例の構成例を示す。本実施 例のサービスシステムは、ゲートウェイ 1 1 1、フロアサーバ 1 1 2, 1 1 3、装置 1 2 1〜 1 2 4からなる。装置 1 2 1 ~ 1 2 4は、例えば K i o s k端末のような表示装置を備えた情報処理装置や、スピー力の ような音声出力装置、または自動ドアゃ空赒装置といった実環境を制御 する設備等、情報提供や実環境を制御ずる等のサービスを提供するのに 必要となる装置である。ゲートウエイ 1 1 1 とフロアサーバ 1 1 2, 1 1 3、装置 1 2 2は通信媒体 1 3 1 を介して接続されてい.る。フロアサ ーパ 1 1 2 と装置 1 2 1、フロアサーバ 1 1 3 と装置 1 2 4、装置 1 2 4 と装置 1 2 3は、それぞれ無線通信媒体 1 3 2、 1 3 3、 1 3 4を介 して接続されている。通信媒体は、イーサネット(登録商標)ゃッイス トペアケーブルのような有線でよく、省電力無線や赤外線のような無線 であってよい。

サービス利用者が利用する機器 1 4 1、 1 4· 2は、サービス利用者の 移動に伴って、これらのフロアサーバや装置と連携して動作する。サー ビス利用者機器 1 4 1は無線通信媒体 1 3 2を介してフロアサーバ 1 1 2、 装置 1 2 1 と、サービス利用者機器 1 4 2は無線通信媒体 1 3 3を 介してフロアサーバ 1 1 3、装置 1 2 4 とそれぞれ接続されている。こ こで、サービス利用者の個人情報はサービス利用者機器 1 4 1 , 1 4 2、 または、ゲートウヱイ 1 1 1に格納される。こうしたゲートウエイゃフ ロアサーバ、装置、利用者機器を総称して、ここでは機器とよぶ。

図 2は本発明を適用した機器が 2つ接続したシステムの詳細構成を示 す。

サービス要求側機器 2 0 1は、外部との通信ィンタフェースと、各機 器での処理を行なうためのソ'フトウェアや各種データを格納する記憶部、 記憶部からプログラムを読み出して処理を行なう処理部とから構成され、 各部が内部パスで接続される。機器 2 0 1の処理を行なうソフトウェア として、通信処理 2 3 1、サービス形成処理 2 3 2、処理プログラム 2 3 6を有する。各処理で使用するデータとして、ユーザコンテキストテ 一プル 2 1 1、システム構成管理テーブル 2 1 6、要求サービス条件 2 1 4、資源公開ポリシ 2 1 7を有する。

通信処理 2 3 1は、通信ィンタフェースを介して他の機器との間のデ ータの交換を行なう処理であり、機器間の通信の暗号化等を行なう。サ 一ビス形成処理 2 3 2は、自機器のユーザ C o n t e X tテーブル 2 1 1に格納された個人情報を公開するとともに、システム構成管理テープ ル 2 1 6、資源公開ポリシ 2 1 7を用いて、他の機器の探索とサービス 提供機器の決定を行なう。処理プログラム 2 3 6は、他の機器と連携し てサービス提供処理を行なう。

ユーザ C o n t e X tテーブル 2 1 1には個人情報が格納される。個 人情報は何らかのアプリケーシヨンプログラムによって生成してもよく、 キーポードのような外部入出力部 2 4 3を介してサービス利用者に入力 させてもよい。あるいは、位置情報センサを外部入出力部 2 4 3に用い て取得してもよい。または、通信処理 2 3 1を介して他の機器より取得 してもよい。

要求サービス条件 2 1 4には要求サービス及びその条件が格納される。 要求するサービス及ぴその条件は外部入出力部 2 4 3を介してサービス 利用者から入力させてもよく、通信処理 2 3 1を介してダウンロードし ても良い。 - 外部入出力部 2 4 3は、例えばセンサゃァクチユエータ、カメラなど の処理プログラム 2 3 6から制御されるデバイスであったり、液晶パネ ノレやキーボード、タツチパネ/レ等のマンマシンインタフェースを介して 機器上で実行される処理プログラム 2 3 6の制御や出力値参照を行った りする機能を有するものである。ただしこれは必須ではなく、外部入出 力部を持たない機器もある。

なお、サービス要求側機器 2 0 1は、サービス利用者機器 1 4 1, 1 4 2であってもよく、. サービス利用者が入力を行なう装置であってもよ く、コンテンツを提供するゲートウェイであってもよい。

サービス提供者側機器 2 0 2は、処理プログラム 2 3 5を稼動させて サービスを提供する機器である。機器 2 0 2は、サービス要求側機器 2 0 1 と同様に、外部との通信ィンタフエースと、各機器での処理を行な - うためのソフトウェアや各種データを格納する記憶部、記憶部からプロ グラムを読み出レて処理を行なう処理部とから構成され、各部が内部パ スで接続される。機器 2 0 1の処理を行なうソフトウェアとして、通信 処理 2 3 1、サービス形成処理 2 3 2、サービスセッション管理処理 2 3 3、処理プログラム 2 3 5を有する。各処理で使用するデータとして、 ユーザコンテキストテープル 2 1 1、サーピ、スリスト 2 1 2、機器群管 理テーブル 2 1 3モード管理テーブル 2 1 5を有する。

サービス形成処理 2 3 2は、サービス要求側機器 2 0 1またはサービ ス提供機器 2 0 2から提供された個人情報を用いて、自機器、または他 機器のサービスリスト 2 1 2を探索し、サービス提供可能な機器とその インタフェースを提示する。 ―

サービスセッション管理処理 2 3 3は、サービス要求側機器 2 0 1 よ り指定された機器間で連携し、モード管理テーブル 2 1 5に記載された 資源公開モードを用いて、機器間で公開するデータや計算資源、処理プ 口グラムなどの資源を制限する。

処理プログラム 2 3 5は、サービスを提供するために稼動するアプリ ケーシヨンプログラムであり、外部入出力部 2 4 2を介して人間や環境 との情報交換を行ったり、外部記憶 2 4 1 を用いてデータの格納や引出 しを行ったりする。

- 機器管理テーブル 2 1 3には、サービス提供に用いられている機器群 に関する管理情報が格納される。サービスリスト 2 1 2には、処理プロ グラム 2 3 Sが他処理プログラムへ公開するィンタフェースの情報が格 納される。

外部入出力部 2 4 2は、サービス利用側機器の外部入出力部 2 4 3に て説明したものと同様のものである。

なお、ここではサービス提供機器を 1つのみ記載したが、これらは複

数存在し、互いに 1つまたは複数の通信媒体を介レて接続されている。 図 3は、ユーザ C o n t e x tテーブル 2 1 1 の構成例を示す。ファ ィル 3 0 1は、レコード 3 1 1〜 3 1 4で構成される。レコード 3 1 1 は実社会での所在情報を示す項目であり、ここでは住所を示す「Address」 が 「千代田区千代田 1」、所在位置を示す「Location」が「areal」である ことが格納される。レコード 312はネットワーク上での個人情報を示して お り、ここでは、電子メールアドレス「 E-Mail Address」が 「anon@sdl.hitachi. co. jp」であることが記録される。同様にレコード 3 1 3は所属団体を示すもので、宗教や所属組合などを格納する。レコ ード 3 1 4はユーザの識別子を格納するフィールドであり、たとえば計 算機を利用するための口グィン I Dや、ユーザ自身を示す電子署名など を格納する。

図 4は、要求サービス条件 2 1 4の構成例を示す。( a ) は要求サービ ス条件 2 1 4全体の構成要素を示す。サービスエントリ 6 5 1、機能条 件 6 5 2、データ条件 6 5 3、計算条件 6 5 4で構成される。

機能条件 6 5 2は、( b ) 図に示すように、ソフト資源数 6 1 2、資源 識別子と利用ィンタフェース 6 1 3〜6 1 4で構成される。ソフト資源 数 6 1 2はサービスエントリ 6 5 1 に示す識別子で表すサービスが利用 するソフト資源数を格納する。資源数は項目 6 1 3, 6 1 4の数と同じ 数である。資源識別子と利用インタフェース 6 1 3, 6 1 4は、ソフト 資源のィンデックス、該サービスの利用する処理プログラムの識別子及 び利用するインタフェースが格納される。ここで、資源識別子'は指定し ても、指定せずともよい。項目 6 1 3の例では、処理プログラムは「*」 すなわち任意の処理プログラムで、インタフェース「 I n f o O u t (M a p ) j で示す処理プログラムを利用することが示されている。インタフ エースの識別は、例えば「 I n s i d e C O R B A— C O R B Aとそ のシステム開発への応用」(ISBN4- 7561- 2015- 6) にあるように I D L (Interface Definition Language)を用いて記述され、ィンタフェースリ ポジトリに格納されるインタフェース名を用いて識別する。または、 W S D L (Web Service Description Language)に定義されて V、るよう ίこ一 連の呼出手順や処理プログラムからの呼出処理のィンタフェースを記述 してもよい。

データ条件 6 5 3は、( c ) に示すようにデータ資源数 6 1 5、データ 資源 6 1 6, 6 1 7で構成される。データ資源数 6 1 5は、サービスェ ントリ 6 5 1に示す識別子で表すサービスが利用するデータ資源数を格 納する。資源数は項目 6 1 6, 6 1 7の数である。データ資源 6 1 6, 6, 1 7は、該サービスの利用するデータの識別子及ぴアクセス条件を格 納する。項目 6 1 6では、データ U s e r C o n t e x tの項目「O n 1 i n e」力 S、項目 6 1 7ではデータ「M a p」が指定されている。デ ータ資源の識別には、ファイル名を用いてもよいし、資源ごとに一意の 識別子を用いて識別してもよい。

計算条件 6 5 4は、( d) に示すように計算資源数 6 1 8、計算資源 6 1 9で構成される。計算資源数 6 1 8は、サービスェントリ 6 5 1に示 す識別子で表すサービスが利用する計算資源数を格納し、項目 6 1 9の 数となる。計算資源 6 1 9は、ソフト資源で指定された処理プログラム の存在する機器において、該サービスの利用する計算資源と量を格納す る。例えば、項目 6 1 9では、ソフト資源のインデックス 1で示される 機器で、スレッドを 2つ必要とすることが示されている。

図 5は、サービスリスト 2 1 2の構成例を示す。サービスリスト 2 1 2は、 サービスエントリ 5 1 1、処理プログラム 5 1 2、インタフエ一 ス 5 1 3、機器識別子 5 1 4で構成される。

サービスェントリ 5 1 1はサービスの種類を示す識別子を格納するフ ィーノレドである。

処理プログラム '5 1 2は、該サービスを提供するために稼動する処理 プログラムの識別子を格納するフィールドである。

インタフェ^ "ス 5 1 3は、該処理プログラムの提供するィンタフエー

スの種類の識別子を格納するフィールドである。インタフェース 5 1 3 は、図 4の利用インタフェース同様に、処理ログラムの呼出関数でな く、例えば W S D L (Web Serv ic e Des cript i on Language) にて定義され ているように一連の.呼出手順や処理プログラムからの呼出処¾のィンタ フェースも含む。また、処理プログラムは複数連携してサービスを提供 する場合がある。

機器識別子 5 1 4は、各レコードで示される処理プログラムが格納さ れた機器の識別子を格納するフィールドである。自機器に格納した処理 プログラムの場合は自機器の識別子を格納する。サービスェントリ 5 1 1を実現するために他機器の処理プロダラ を利用する場合は、該処理 プログラム 5 1 2を格納している機器の識別子を格納する。あるサービ スを複数の機器に存在する処理プログラムが連携して提供する場合には、 事前にその関係が構築されてい δ場合は、こうした形式でサービスリス ト 2 1 2が構築されている場合もある。

サービスリスト 2 1 2のレコードは、データ資源の登録があってもよ い。この場合、処理プログラムのフィールドにデータ識別子を格納する。 レコード 5 2 3は、 ^の例を示している。

図 4、図 5で説明したように要求サービス条件及ぴサービスリストを 記述し、後に示すようにこれを照合することで、サービス提供に有効な 資源を判断する。なお、本実施例ではソフト資源、データ資源、計算資 源の例で説明したが、入出力装置の資源や他の資源を明的に記述し、 管理しても良い。また、資源間のデータの流れを記述し、これを有効な 資源の判断に用いてもよい。

図 6は、機器群管理テーブル 2 1 3の構成例を示す。機器群管理テー プル 2 1 3は、フィールド 7 1 1〜 7 1 5で構成される。

サービスセッション 7 1 1は、提供中のサービスの実体の識別子を格 納するフィールドであり、サービス形成処理 2 3 2によって生成され、 サービスセッション管理処理 2 3 3によって利用される。ここで、同一

のサービス識別子を持つサービスも、実体は複数存在る。例えば、サ 一ビス識別子 「N a v i」で示され-るナビゲーシヨンサービスを、機器 A Aを用いてユーザ Aに提供している実体と、機器 B Bを用いてユーザ Bのために提供している実体が存在する。このように、サービスの識別 子が同一でも利用している機器や処理プログラム、ユーザが異なる場合 に異なるサービスセッションで識別される。 .

構成メンパ 7 1 2は該セッションの構成メンバ機器を格納するフィ一' ルドである。

機器状態 7 1 3は、該レコ一ドで示す機器の状態を格納するフィール ドであり、タスク状態 7 1 4は、該レコードで示す機器の、該サービス を実行する処理プログラムの状態を格納するフィールドである。フィー ルド 7 1 3、 7 1 4は、例えば特開 2 0 0 1 — 1 4 5 1 7 4号公報にあ るような方法を用いることで更新することができる。更新時刻 7 1 5は、 該レコ一ドで示す機器及び処理プログラムの状態を検出した最新時刻を 格納する。

図 7は、システム構成管理テーブル 2 1 6の例を示す図である。( a ) は、本発明が適用されるシステム構成の一例を論理表現した図である。 図に示された機能を果たすための計算機 1 9 0 1 ~ 1 9 0 6が、通信路 1 9 5 1〜 1 9 5 7でそれぞれ接続されている。(b ) は、構成管理テー プルの一部であり、各通信路の保持している保証能力を表示する。通信 路 1 9 1 1は機器間の通信路の分類を格納するフィールドである。評価 尺度 1 9 1 2、保証レベル 1 9 1 3は、各レコードで示される通信路の 評価尺度と保証レベルがそれぞれ格納される。レコード 1 9 2 1は、通 信路 「C 1」すなわち 1 9 5 1〜 1 9 5 3力 S、評価尺度「 C o n f i d e n t i a 1」すなわち通信路の秘匿性に関し、保証レベル「 2」であ ることが示されている。ここで、保証レベルはシステム毎に任意に決め られる。例えば、以下のようなレベルで決めることができる。

保証レベル 1 :機器間での個別の暗号通信

保証レベル 2 :複数機器間で共有する暗号通信

保証レべノレ 3 :メッセージをトレースできるレべノレ

一方、( c ) は、構成管理テーブルの一部であり、各機器の保持してい る保証能力を表示する。機器 1 9 3 1は機器の識別子を格納するフィー ルドである。評価尺度 1 9 3 2、保証レベル 1 9 3 3は、それぞれ通信 路と同様に評価尺度と保証レベルを格納するフィールドである。保証レ ベルは上述したものと同じとすれば良い。

図 7において説明した情報は、図 9で説明するサービス形成処理の中 で取得してもよい。あるいは、何らかの手段で取得し、格納してもよい。 図 8は、資源公開ポリシ 2 1 7の構成例を示す。フィールド 2 0 1 1 は公開する資源の識別子を格納するフィ.ールドである。評価尺度 2 0 1 2、 及び保証レベル 2 0 1 3は、それぞれ図 7にて説明レたシステム構 成管理テーブルの場合と同様に、各資源を、公開する際に許容可能な評 価尺度と保証レベルが格納される。例えば、レコード 2 0 2 1には、資 源 「U s e r C o n t e X t : O ή 1 i n e」は、評価尺度「 C o n f i d e n t i a 1 」に対して、保証レベル「 2」の範囲まで公開するこ とを許す。図 7の例では、資源「U s- e r C o n t e x t : O n 1 i n e」 が機器 1 9 0 1 に格納されている場合、通信路 C 1、 C 2では公開 されるが、 C 3では公開されないことを示している。なお、本例では評 価尺度に秘匿性を用いたが、性能などの評価尺度を用いることもできる。 図 9は、サービス ^成処理 2 3 2の処理の流れを示す。

サービス要求側機器 2 0 1 では、サービス提供側機器 X, Yにサービ スを'要求するのに先立ち、資源公開ポリシ 2 1 7に、アクセス権を公開 する資源と評価尺度、保証レベルを設定し、保証レベルを満たす範囲に サービス提供機器探索メッセージの送信範囲を設定しておく(ステップ 2 1 1 1 )。送信範囲は、例えばシステム構成管理テーブル 2 1 6にある システム構成と資源公開ポリシ 2 1 7を照合し、保証レベルを満たす機 器のみを指定する。

サービス要求側機器 2 0 1は、要求サービス条件 2 1 4から要求する サービスの条件を取得し、一意の要求識別子を生成し、署名を作成し、 サービス提供機器探索メッセージを送言する(ステップ 8 1 1 )。要求識 別子は、例えば自機器の識別子と時刻などを用いて一意となるよう作成 する。本メッセージは、「Understanding Universal Plug and Pl ay Whi t e Paper にあるような方法を用いて検索した、提供可能なサービスリスト を保持したサーバに対して発行してもよく、またはネットワークセグメ ントヘプロードキャストしてもよい。

本メッセージを受け取ったサービス提供側機器 X, Yでは、本メッセ —ジに記載された条件に合致する資源が自機器にあるかどうかを、サー ビスリスト 2 1 2を検索して見つけ出し、それが公開できるか否かを判 断する。

ソフト資源やデータ資源の場合はサービスリストに登録されているか 否かで判断する。計算資源の場合は、該指定された資源を確保する。検 出したサービスリストのレコード、または確保した計算資源は、モード 管理テーブル 2 1 5にレコードを追加して登録する。ここで、検出され た資源が、既に他のサービスのために確保されている場合には、排他制 御を行って公開できないと判断してもよい。また、アクセス制御を行つ てもよい。

公開できる場合は、サービス要求側機器 2 0 1へ、合致する資源の情 報と、要求メッセージにあった署名.を付加して返信する。合致する資源 が全てまたは一部ない場合は、他のサービス提供側機器へ探索メッセー ジを転送する(ステップ 8 1 2 )。合致する資源の一部がない場合とは例 えばあるサービスリストに記載されたあるサービスを提供する要素の一 部である処理プログラムが合致するものが無い場合である。

ここでの他のサービス提供機器への探索メッセージの転送を、例えば 「 I n s i d e C O R B A— C O R B Aとそのシステム開発への応 用」(ISBN4- 7561- 2015-6) の T r a d e rサービスの方法を用いて、転

送回数を制限してもよい。

サービス要求側機器 2 0 1では、ステップ 8 1 2で発行された応答メ ッセージを受信し、メッセージに付加された要求識別子と、ステップ 8 1 1で作成した要求識別""子の照合を行って自機器への応答かどうかを確 認する。また、該応答メッセージに載せられた資源情報を取得する(ス テツプ 8 1 3 )。

応答を受信した後、システム構成管理テーブル 2 1 6、及び資源公開 ポリシ 2 1 7を照合し、サービス提供に有効な資源と、該資源を用いた サービス提供形態の組合せを抽出する。ここで、資源間のデータの流れ を要求サービス条件 2 1 4に記述しておき、これも含めて判断してもよ レ、。その後、所定の判断基準でサービス提供機器として利用する機器を 選定する (ステップ 8 1 4 )。

ここで判定したサービスが有効であるかを所定の評価尺度で判定する (ステップ 2 1 1 3 )。所定の評価尺度は、ここでは、要求サービス条件 に記載したサービスを提供する資源が全てアクセス可能か否かであると する。判定が有効である場合には、選定された機器へ、アクセス権を示 すセッション識別子情報と、資源の割当てを送信し(ステップ 8 1 5 )、 サービスを受ける。 - ステップ 2 1 1 3の判定で、有効でない場合は、資源公開ポリシ 2 1 7を更新し (ステップ 2 1 1 5 )、ステップ 8 1 1に戻る。資源公開ポリ シの更新は、例えば保証レベル 2 0 0 3の条件を緩くする、あるいは、 公開する資源を追加する、などの処理とする。これらを、要求サービス 条件 2 1 4と探索できた資源の差異から選定してもよい。 .

サービス提供機器の選定は、本実施例では省略しているが、例えば資 源の属性などをサービスリスト 2 1 2に登録しておき、これを資源情報 と共に返信することで用いることもできる。またサービス提供機器探索 メッセージに付加されたデータを用いて、サービス要求側機器 2 0 1 の 認証やアクセス制御を行ってもよい。更に、特定のサービスを提供する

ためのサービス提供機器の指定に、本実施例ではメッセージにセッショ ン識別子を付加して配布する方法を示したが、特願 2 0 0 2— 4 4 1 1 3号に示すようにサービス毎に機器間でデータ共有のためのセッシヨン を確立し、これを用いて特定のサービスを識別してもよい。また、本実 施例では、サービス提供機器探索メッセージに要求サービス条件を付加 し、サービス提供機器で提供可能な資源を探索する例を示したが、提供 可能な資源のみを探索し、サービス要求側機器 2 0 1で要求サービス条 件と照合してもよい。

なお、上記の処理フローは、資源の可用性が事前に記述困難な場合、 すなわちアクセス権を公開してみないとサービスの有効性が判定できな い場合の例 (例えば、特定の人を指定した個人情報が要求サービス条件 に含まれており、不特定のサービス提供機器に送信したくない場合)と して、「公開範囲を限定して提供可能なサービスを判定し、公開範囲を段 階的に拡張して提供するサービスを決定する方法」を含めた処理フロ一 で説明したが、上記の場合の処理を行わなくてもよい状況であれば、こ の処理 (ステップ 2 1 1 1, 2 1 1 3, 2 1 1 5) を省略してもよい。 図 1 0は、各機器間で交換されるメッセージ構成例を示す。

( a ) は、サービス提供機器の採索メッセージの構成例を示す図であ る。これは;図 9にて説明したサービス形成処理 2 3 2のメッセージ( 1 ) で発行されるものである。本メッセージは、メッセージヘッダ 9 1 1、 メッセージ種別 9 1 2、要求サービス条件 9 1 3、要求元署名 9 1 4、 要求識別子 9 1 5、データ 9 1 6で構成される。メッセージへッダ 9 1 1は通信処理 2 3 1で用いるもので、機器間でのデータ交換を行なうた めに必要な情報が格納される。メッセージの暗号化や、送信元の匿名化 などもここで行なう。メッセージ種別 9 1 2は、該メッセージの種類を 識別する情報を格納し、例えばサービス提供機器探索メッセージや、こ れへの応答メッセージなどの情報が格納される。要求サービス条件 9 1 3は、 サービス提供機器探索の条件で、図 4にて説明した要求サービス 条件 2 1 4の情報が格納される。要求元署名 9 1 4は、該サービス提供 機器探索メッセージを発行したサービス利用側機器での、該メッセージ 発行時の署名を格納する。要求識別子 9 1 5は、該サービス提供機器探 索メッセージを一意に識別する情報である。データ 9 1 6は、その他の 付加データを格納するフ.ィールドである。

(b ) は、( a ) にて説明したサービス提供機器探索メッセージへの応 答メッセージの構成例を示す図である'。これは、図 9にて説明したサー ビス形成処理 2 3 2のメッセージ( 2 ) で発行されるものである。メッ セージヘッダは ( a ) 同様であり、メッセージ種別 9. 1 2には、サービ ス提供機器応答メッセージであることが格納される。要求元署名 9 1 4、 要求識別子 9 1 5には、該応答を送信するトリガとして受け取ったサー ビス提供機器探索メッセージに格納されていた、要求元署名 9 1 4、要 求識別子 9 1 5がそれぞれ格納される。提供サービス 9 2 1には、サー ビスリスト 2 1 2から取得された該応答メッセージの送信元機器で提供 される資源、またはサービスの識別子と関連情報が格納される。

( c ) は、サービス提供機器を決定し指定するメッセージの構成例を 示す図である。これは、図 9にて説明したサービス形成処理 2 3 2のメ ッセージ ( 3 ) で発行されるものである。メッセージヘッダ 9 1 1 、メ ッセージ種別 9 1 2、要求元署名 9 1 4、セッション識別子 9 3 2、は ( a ) において説明したサービス提供機器探索メッセージ同様である。 ここで、セッション識別子 9 3 2は、ステップ 8 1 5 にて生成した、該 サービス提供のために資源を利用する鍵となる一意の識別子が格納され る。割り当てデータ 9 3 1には、該サービスを提供するために稼動する 資源識別子の列が格納される。( c ) では、ソフト資源の例として、ソフ ト資源識別子と利用インタフェースを、フィールド 9 4 1〜 9 4 2に格 納している例を示している。ここで、割り当てデータ 9 3 1を構成する 資源の数は任意の個数をとりうる。

なお、本実施例においてはサービス要求側機器 2 0 1に資源公開ポリ

シ 2 1 7が存在する例を示したが、他の機器に存在する場合でも、該資 源公開ポリシ 2 1 7を取得することで容易に実施することができる。本 実施例で説明じた方法により、アクセス権を公開する資源の範囲に応じ て、提供可能なサービスのレベルを判定し、適切なサービスを形成する ことができる。

一図 1 1は、モード管理テーブル 2 1 5の構成例を示す。モード管理テ ブル 2 1 5は、資源識別子 4 1 1、公開モード 4 1 2、公開目的サー ビス 4 1 3から構成される。資源識別子 4 1 1は、該機器内の資源の識 別子であり、処理プログラムやデータ、計算機資源などの識別子が格納 される。公開モード' 4 1 2は.、各レコードで指定された資源の公開モー ドを格納する項目であり、例えば以下のような指定を行なう。

• P u b l i c : 任意の要求に対して公開する状態。

• P r i v a t e : 特定のサービス提供の目的のみに公開する状態。 • P r o t e c t e d : 特定のサービス提供に、実際に使用されている 状態。

公開目的サービス 4 1 3は、各レコードで指定された資源を公開する 目的となるサービスの識別子を指定する。例えばレコード 4 2 2は、資 ' 源「地図データ」が、識別子「N a v i」で指定されるサービスのため に他資源に公開することが示されている。レコード 4 2 4は、資源「く T h r e a d >」で示されるオペレーティングシステムのスレツドが、 サービス 「N a v i」のうち、本実施例に示した方法によって特定の資 源が選択され、セッション識別子「 1」が割当てられたもののために使 用可能であることを示している。

図 1 5は、サービス 1 1 1 1 としてユーザ A用の「ビデオ鑑賞サービ ス」を、サービス 1 1 1 2として、ユーザ B用のサービス(空調温度制 御)を提供しているサービス構成例を示す。サービス 1 1 1 1は、資源 「スピーカ」を用いる共に、他のサービス 1 1 2 1 「映像再生」を用い てサービスを提供している。サービス「映像再生」は、資源「V C R」 及び資源 「スピーカ」を用いてサービスを提供する。ここで、サービス 1 1 1 1 とサービス 1 1 1 2のユーザは別であり、これらの聞ではデー タを公開しない。サービス 1 1 1 1 とサ.一ビス 1 1 2 1は同一のユーザ A向けのサービスであり、サービスを提供するためにデータが共有され る。 ·

図 1 2は、例えば図 1 5で示すようなサービス提供時のサービスセッ シヨン管理処理 2 3 3の処理の流れを示す。ここで、サービス提供側機 器 Xはユーザ C o n t e x tテーブル 1 1 2 1を持つ機器 1 1 0 1 を、 サ ビス提供側機器 Yは、サービスを提供するァプリケーションプログ ラムを持つ機器 1、0 1を示している。ここで、機器 Xと機器 Yが連携す ることは、前述したサービス形成処理 2 3 2によって指定される。

サービス提供側機器 Yより位置情報要求を発行し(ステップ 1 0 1 1 )、 サービス提供側機器 Υ·ではこれを受信し(ステップ 1 0 1 2 )、該要求メ ッセージにあるサービスセッション識別子を確認する(ステップ 1 0 1 3 )。

この後、サービス間の階層関係を探索する(ステップ 1 2 1 1 )。資源 が確保できた場合 (ステップ 1 0 1 7 ) は、要求サービスの指定メンバ であるか否かを確認する(ステップ 1 0 1 4)。サービス形成処理 2 3 2 によって形成されたサービスである場合、すなわち機器群管理テープル に登録されたサービスセッションと機器の組である場合は要求データを 返信する(ステップ 1 0 1 6 )。資源が確保できない場合(ステップ 1 0 1 7 ) 及び要求サービスの指定メンパでない場合(ステップ 1 0 1 4) 要求を拒絶する (ステップ 1 0 1 5 )。

ここで、サービスの階層の記述は、サービスリスト 2 1 2に形成され たサービスを登録することで形成される。また、機器群管理テーブル 2 1 3のタスク状態 7 1 4に構成要素となるサービスを登録することで、 他のサービスとの関係や状態を管理することができる。

サービス間でのデータの共有は、モード管理テーブル 2 1 5に、構成 要素となるサービスの識別子を資源識別子として登録することで制御で きる。これを用いて、以下のような用途に応じて制御することができる。 •データの公開範囲制限:ユーザの位置データを特定機器間で共有する 際に、これらの機器間でデータ共有するサービスを独立に設定する。該 サービスと他の機器を連携させるサービスを設定し、他の機器へは特定 位置に来たトリガや、ユーザ位置付近のコンテンツなどの処理結果のみ を提供する。

•資源の公開制限:あるサービスの構成要素となることで、他のサービ スへは資源を直接公開しないようにする。例えば、ビデオ出力を T Vへ 出力する映像再生サービスを提供している間は、 T Vの番組設定や電源 設定などのインタフェースを持つ処理プログラムへのアクセスを抑止す る。

この方法では、全ての資源の組合せに対して資源利用可否を記述せず ともサービスを形成できる。

本実施例では、アプリケーションプログラムの存在するサービス提供 側機器 Yからデータを要求する例を示したが、ユーザ C o n t e X tテ 一プルを持つサービス提供側機器 Xより、管理しているサービスセッシ ヨン識別子に応じたデータを、自発的に送信してもよい。このとき、サ 一ビス提供機器 Yでは、該サービスセッション識別子で指定されたサー ビスを提供する資源のみにデータを渡し、それ以外の資源へはデータを 渡さないよう制御する。また、サービスセッション識別子を該公開デー タの暗号化の鍵として利用し、公開側で暗号化、利用側で復合化を行つ てもよい。

本実施例のサービスセッション管理により、特定のサービス提供に有 効な資源以外に、資源のアクセス権を公開せず、要求された品質を保つ て必要なサービスを形成することができる。

なお、サービスが階層化されていても、各サービスに対応するモード の機器間での情報の転送制御を行なわなくてよい場合は、ステップ 1 2 1 1及ぴその次の判定ステップを省略できる。

次に、機器がモード管理を行なう機能を持たない場合に、ソフトゥェ ァを配信し、該ソフトウェアにより機器のモード管理を行なう実施例に ついて説明する。

図 1 3は、サービス形成処理の、ソフトウェア配信処理の流れを示す 図である。サービス要求側機器 2 0 1 とサービス提供側機器 Xの間で、 例えま 「Unae:rstanding Universal Plug and Play White PaperJ ίこ gti载 されている公知の方法を用いてサービス提供機器群を探索し(ステップ 1 3 1 1 )、サービス提供に有効な機能を持つ機器群を選択し、該提供す るサービスに必要な資源、管理機能を選択し(ステップ 1 3 1 2 )、該選択 された資源管理機能を持つソフトウェアを選択された機器へ配信する (ステップ 1 3 1 3 )。配信されたサービス提供側機器 Xでは、これを受 信し、該機器で既に稼動しているソフトウェアと連携させる(ステップ 1 3 1 4)。

図 1 4は、配信ソフトと既存プログラムの結合例を示す図である。本 実施■(列 ίこおヽて ίま、 \ X. }ΐ 「 Understanding Universal Plug and Play White PaperJ に記載されている方法を実装している場合の例を説明する。 このとき、機器にはサービスリスト 2 1 2が存在し、,通信処理 1 7 1 1 を介して処理プログラム 2 3 5 とデータの送受信を行なうことができる。 処理プログラム 2 3 5は、外部入出力部 2 4 2や、外部記憶 2 4 1ヘア クセスしてデータ処理を行なう。配信されたソフトウエア 1 7 1 2は、 通信処理 1 7 1 1 を介して処理プログラム 2 3 5 と連携する。このとき、 処理プログラムと他機器の処理プログラムを直接連携ざせず、配信され たソフトウェア 1 7 1 2を介して他機器と連携するようにして、 1 7 1 2でモー ドの管理を行なう。また、該機器内のソフトウェア構成は、通 信処理 1 7 1 1を介してサービスリスト 2 1 2を取得し、配信さ'れたソ フトウェア 1 7 1 2を介してのみ他機器へ公開することとする。

本実施例においては、サービス要求側機器からソフトウェアを配信す

る例を示したが、他の機器から行ってもよい。また、本実施例において 配信するソフトウェアとして、データや処理プログラムの公開、計算資 源の確保を行なうソフトウェアの他、機器間のデータ送受信を監視する ためのソフトウェアを配信してもよい。

本実施例で説明した方法により、事前にモード管理機能を有していな い機器でも、サービス提供に有効なモード管理することが出来るよう になる。

以上述べた実施例によれば、動的に発見した資源群の中で、サービス に応じて該サービス提供に有効な資源群のみで柔軟に資源を連携できる。 特にアクセス権を公開する資源の範囲に応じて、提供可能なサービスの レベルを判定し、適切なサービスを形成することができる。

また、各資源が特定のサービス提供に有効であるかどうかを識別する モードを持ち、これを用いて公開資源を制御することで、所望のサービ スを提供するのに有効な資源以外にデータ公開せず、要求された品質を 保って必要なサービスを形成できる。

更に、サ—ビス間の階層的な関係を管理し、これに応じて資源公開す ることで、全ての資源の組合せに対して資源利用可否を記述せずともサ 一ビスを形成できる。

更に、各機器へ資源管理ソフトウェアを配信し、各機器では該ソフト ウェアを介してアプリケーション間のデータ送受信や実行管理を行なう ことで、事前にモード管理機能を有していない機器でも、サービス提供 に有効なモードを管理することが出来る。また、不特定の機器に資源を 公開せずとも、公開範囲を限定して提供可能なサービスを判定し、公開 範囲を段階的に拡張して提供するサービスを判定することができる。

産業上の利用可能性

本発明によれば、動的に発見した資源群の中で、サービスに応じて該 サービス提供に有効な資源群のみで柔軟に資源を連携できる。