(57)【要約】【課題】動的に発見した資源群の中で、サービス提供に有効な資源群のみで柔軟に資源を共有し、要求された条件を満たすサービス授受環境を提供する。【解決手段】サービス形成処理232は、要求サービス条件214を発信して、各機器のサービスリスト212に記載された資源や、各機器の計算資源を探索し、有効なサービスのレベルを判定する。このとき、資源公開ポリシ217に従って探索範囲を制限することができる。各機器のサービス形成処理232では他機器へ公開するデータを制限する。サービスセッション管理処理233は、モード管理テーブル215に格納された各資源の公開モードを用いて、各資源を、提供するサービスに応じて公開する。【選択図】  図２
2004199300.tif 000002
【特許請求の範囲】
【請求項１】
データ処理を行う処理部と、他の装置との間の通信を行う通信部とを備えた機器が複数接続され、それぞれが連携して処理を行う分散システムにおいて、
前記分散システムは、
要求されたサービスに必要な資源を前記複数の機器から検出する手段と、
検出された資源が、資源公開ポリシを満たすか否かを判定する手段と、
前記資源公開ポリシを満たす資源を連携させれサービスを提供する手段と
を備えたことを特徴とする分散システム。
【請求項２】
前記資源は前記機器に格納された処理プログラム、データ、計算資源、外部入出力装置のいずれかである請求項１の分散システム。
【請求項３】
前記資源公開ポリシは前記資源の秘匿性能または処理性能のいずれかの保証能力である請求項１の分散システム。
【請求項４】
前記機器は、自機器から資源を提供するときにサービス提供のために連携された資源を有する機器であることを確認した後に自機器の資源を提供する手段を備えた請求項１の分散システム。
【請求項５】
前記機器は、前記資源の提供条件を当該資源と対応つけて保持する手段と、該提供条件に応じて資源の提供を行う手段とを備えた請求項１の分散システム。
【請求項６】
サービス要求を受け付けた機器が自機器に当該サービスの提供に必要な資源の全部又は一部を有さないと判定したときに、当該サービスを識別する識別子をつけて他の機器へサービス要求を転送することを特徴とする請求項１の分散システム。
【請求項７】
前記機器は、他の機器とデータの共有を行う際に、前記資源の提供条件の内容により提供するデータの内容を変更することを特徴とする請求項５の分散システム。
【請求項８】
資源の管理処理を行う処理プログラムをサービス要求機器からサービス提供機器に配布することを特徴とする請求項１の分散システム。
【請求項９】
前記資源公開ポリシを満たすサービスに必要な資源がそろわないときに、前記資源公開ポリシを変更し、変更後の公開ポリシを満たすか否かを判定することを特徴とする分散システム。
【請求項１０】
データ処理を行う処理部と、他の装置との間の通信を行う通信部とを備えた機器が複数接続され、それぞれが連携して処理を行う分散システムにおけるサービス授受環境形成方法において、
要求されたサービスに必要な資源を前記複数の機器から検出するステップと、
検出された資源が、要求者の資源公開ポリシを満たすか否かを判定するステップと、
前記資源公開ポリシを満たす資源を連携させれサービスを提供するステップとを、
当該分散システムで実行することを特徴とするサービス授受環境形成方法。
を備えたことを特徴とする分散システム。
【請求項１１】
前記資源は前記機器に格納された処理プログラム、データ、計算資源、外部入出力装置のいずれかである請求項１０のサービス授受環境生成方法。
【請求項１２】
前記資源公開ポリシは前記資源の秘匿性能または処理性能のいずれかの保証能力である請求項１０のサービス授受環境生成方法。
【請求項１３】
前記機器は、自機器から資源を提供するときにサービス提供のために連携された資源を有する機器であることを確認した後に自機器の資源を提供する請求項１０のサービス授受環境生成方法。
【請求項１４】
前記機器は、前記資源の提供条件を当該資源と対応つけて保持するステップと、該提供条件に応じて資源の提供を行うステップとを更に備えた請求項１０のサービス授受環境生成方法。
【請求項１５】
サービス要求を受け付けた機器が自機器に当該サービスの提供に必要な資源の全部又は一部を有さないと判定したときに、当該サービスを識別する識別子をつけて他の機器へサービス要求を転送することを特徴とする請求項１０のサービス授受環境生成方法。
【請求項１６】
前記機器は、他の機器とデータの共有を行う際に、前記資源の提供条件の内容により提供するデータの内容を変更することを特徴とする請求項１４のサービス授受環境生成方法。
【請求項１７】
資源の管理処理を行う処理プログラムをサービス要求機器からサービス提供機器に配布することを特徴とする請求項１０のサービス授受環境生成方法。
【請求項１８】
前記資源公開ポリシを満たすサービスに必要な資源がそろわないときに、前記資源公開ポリシを変更し、変更後の公開ポリシを満たすか否かを判定することを特徴とする請求項１０のサービス授受環境生成方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、データ処理を行う処理部と他の装置との間の通信を行う通信部とを備えた機器が複数接続され、それぞれが連携して処理を行う分散システムに関する。特にサービスを提供するために、各機器が提供する計算機資源やプログラム、データ等の資源を、受けるサービスに応じて適切な連携を構築する技術に関する。ビル・ホームオートメーションシステム、プラント制御や製造、物流などの社会システム、交通システムなどの制御システム、などにおいて好適に適合しうる。
【０００２】
【従来の技術】
社会基盤の設備や機器に浸透した計算機資源を、物理環境や時間、サービスの利用者や周囲の人を含むユーザ状態、可用な計算機、ネットワークなどの状況に応じて柔軟に活用して連携させ、サービスを提供することが可能となりつつある。これは例えば、ビルや街などの公共スペースにおいて、利用者の近くにある任意の情報端末を情報サービス出力先として用いたり、音響設備を組み合わせてマルチメディアコンテンツを出力したりするものである。または、プラント制御設備の持つデータや、該設備から発信されるイベントに応じて保守員端末や作業員端末へデータを配信したり、設備の稼動状態を制御したりするものである。こうしたシステムでは、特定のサービスを提供するために、計算機や該計算機に接続した入出力装置、ソフトウェアやデータなどの資源から、サービスの提供に有効となる適切な資源を選択し、連携させることが必要となる。ここで、状況は変化していくため、サービスを提供する時点にならないと適切な資源は解からない。このため、動的な資源の発見と資源間での連携が必要となる。また、こうした資源の発見や資源間の連携には、サービスを提供するために各資源の提供する機能に加えて、セキュリティや性能などの条件も考慮する必要がある。
【０００３】
こうした動的な資源の発見を行う手段として、動的な資源構成を検出する手段に、プラグアンドプレイと呼ばれる方法がある。これは、例えば非特許文献１に記載される。ここでは、機器の提供可能な機能をサービスとして記述し、ネットワーク接続時に他の機器へブロードキャストする。サービスを利用する機器は、該メッセージを受信するか、利用するサービスを指定して他の機器を探索するメッセージをブロードキャストし、これに応答した機器の情報から、サービス提供に必要な機器を検索する。ブロードキャストする範囲は、ネットワークの接続した範囲であり、ホップ数で制限される。
【０００４】
また、特定の条件に基づいてこうした保証を行う手段として、ポリシを用いた制御方法がある。これは、セキュリティやQoSなどの非機能的要求に関して宣言的に制約を記述し、実行制御を行うものである。サービスに応じた個人情報の公開範囲を制御する方法として、例えばWorld Wide Web Consortium（W3C）で制定されているＰ３Ｐ(Platform for Privacy Preferences)がある。これは、サービス提供側サイトで利用する個人情報の種類と該個人情報を公開する他サーバを提示し、公開する個人情報と照合してサービスを受けるか否かを決めるものである。他資源に対する各資源のアクセスを制限する方法として、例えば “The Ponder Policy Specification Language”がある。これは、特定の資源へのアクセス許可や、公開するデータ、アクセス時の制約を、タイミングの切り替え条件を、特定の資源に対して記述するものである。アクセスを許可される特定資源は、グループとして登録することも可能となっている。
【０００５】
【非特許文献１】
UPnP Forum Introduction to Universal Plug and Play [on line] [平成１４年１２月１２日検索]、インターネット＜URL：http://www.upnp.org/download/Compressed-UPnP_Forum_Mktg_Presentation.zip＞
【非特許文献２】
The Platform for Privacy Preferences 1.0 (P3P1.0) Specification W3C Candidate Recommendation 15 December 2000  [on line] [平成１４年１２月１２日検索]、インターネット＜URL：http://www.w3.org/TR/2000/CR-P3P-20001215＞
【非特許文献３】
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] [平成１４年１２月１２日検索]、インターネット＜URL：http://www.doc.ic.ac.uk/~mss/Papers/Ponder-Policy01V5.pdf＞
【０００６】
【発明が解決しようとする課題】
上述したプラグアンドプレイ技術では、サービスを探索する範囲がネットワークの接続性のみに限定されており、可用なサービスを探索するために個人情報が漏洩するといった問題があった。また、前述のように利用者やサービスに応じて利用する資源が変化するため、サービスと利用する資源をポリシとして記述し、利用者がサービスを受けるか否かを判断する従来の方式では、サービスを提供する資源を柔軟に利用することに限界があった。
【０００７】
また、サービスを提供するために連携する機器は、公共に使えるKiosk端末のようなものから、特定の利用者しか制御できない入退室制御機器、サービスを監視・管理して課金するサーバのように、セキュリティ設定が多様なものに跨る。また、こうした機器にはセキュリティ管理機能などを持つ高仕様のものから、こうした機能を持たない低仕様のものまである。データを持つ資源とアクセス元の資源、性能保証を行う資源の組合せは様々であり、全ての資源が、指定されたポリシを実行できるとは限らない。あるいは、性能やアクセス時のセキュリティを確保できるか否かを事前に調べることが困難であることも多く、全ての組合せをポリシとして記述しておくことは困難である。
【０００８】
本発明は上記課題を鑑みてなされたもので、動的に発見した資源群の中で、サービス提供に有効な資源群のみで柔軟に資源を共有し、要求された条件を満たすサービス授受環境を提供することを目的とする。
【０００９】
【課題を解決するための手段】
上記目的のために、本発明では、データ処理を行う処理部と、他の装置との間の通信を行う通信部とを備えた機器が複数接続され、それぞれが連携して処理を行う分散システムに、要求されたサービスに必要な資源を前記複数の機器から検出する手段と、検出された資源が、資源公開ポリシを満たすか否かを判定する手段と、資源公開ポリシを満たす資源を連携させれサービスを提供する手段とを備えた。
【００１０】
資源公開ポリシを前記資源の秘匿性能または処理性能のいずれかの保証能力とすることで不正使用によるデータ等の漏洩の防止が行えたり、サービスの提供スピードを確保したりすることができる。
【００１１】
本発明の一つの側面として、分散システムにセキュリティなどの資源の保証能力に応じて、公開する資源の範囲、すなわち資源へのアクセス権を与える範囲を限定するステップと、サービスを、利用可能な資源に応じたレベルで提示するステップと、上記サービスと資源を照合して、サービス提供に用いる資源を選択するステップと、を持たせて、サービスと公開する個人情報に応じて適切な資源を活用してサービス授受を行えるようにした。
【００１２】
別の側面として、各資源を公開する目的であるサービスに対応するモードを資源と対応付けて保持させておき、サービスを識別して資源へのアクセスを行うステップと、資源提供側は該要求とモードに応じて公開資源を制限するステップと、を実行することで、所望のサービスを提供するのに有効な資源以外にデータ公開せず、要求された品質を保って必要なサービスを形成できるようにした。
【００１３】
更に別の側面として、サービスを他のサービスを用いて階層的に構成する際に情報を共有するために、あるサービスを構成する他サービスとの間の関係を管理し、あるサービスを構成する部分サービスへ、他サービスの資源公開条件を委譲し、全ての資源の組合せに対して資源利用可否を記述せずともサービスを形成できるようにした。
【００１４】
事前にモード管理機能を有していない機器に対しては、各機器へ特定のソフトウェアを配信するステップと、各機器では該ソフトウェアを介してアプリケーション間のデータ送受信や実行管理を行うことで、サービス提供に有効なモードを管理することが出来るようにした。
【００１５】
公開範囲を限定して提供可能なサービスを判定するステップと、公開範囲を段階的に拡張して提供するサービスを決定するステップとを実行し、各資源のアクセス権を公開しなければサービスが提供可能か判断できない場合でも、サービス提供に有効な資源群を段階的に判定することを可能とした。
【００１６】
【発明の実施の形態】
以下に、本発明の実施の形態を図面を用いて詳細に説明する。
以下の実施例において、
（１）アクセス権を公開する資源の範囲に応じて、提供可能なサービスのレベルを判定する方法。
（２）資源群の可用性が事前に記述困難な場合、すなわちアクセス権を公開してみないと可用資源が判定できない場合の方法として、試行により可用資源を発見・選択するために、公開範囲を限定して提供可能なサービスを判定し、公開範囲を段階的に拡張して提供するサービスを決定する方法。
（３）各資源がサービスに対応したモードを持ち、公開する資源の範囲を制限してサービス提供に用いる情報を共有する方法。
（４）サービスが階層化されている場合に、各サービスに対応するモードの機器間での情報の転送を許可する場合。
（５）機器がモード管理を行う機能を持たない場合の方法として、ソフトウェアを配信し、該ソフトウェアにより機器のモード管理を行う方法。
を詳細に説明する。
【００１７】
図１は本発明を適用したシステムの一実施例の構成例を示す。本実施例のサービスシステムは、ゲートウェイ111、フロアサーバ112〜113、装置121〜124からなる。装置121〜124は、例えばKiosk端末のような表示装置を備えた情報処理装置や、スピーカのような音声出力装置、または自動ドアや空調装置といった実環境を制御する設備等、情報提供や実環境を制御する等のサービスを提供するのに必要となる装置である。ゲートウェイ111とフロアサーバ112、113、装置122は通信媒体131を介して接続されている。フロアサーバ112と装置121、フロアサーバ113と装置124、装置124と装置123は、それぞれ無線通信媒体132、133、134を介して接続されている。通信媒体は、イーサネット（登録商標）やツイストペアケーブルのような有線でよく、省電力無線や赤外線のような無線であってよい。
【００１８】
サービス利用者が利用する機器141、142は、サービス利用者の移動に伴って、これらのフロアサーバや装置と連携して動作する。サービス利用者機器141は無線通信媒体132を介してフロアサーバ112、装置121と、サービス利用者機器142は無線通信媒体133を介してフロアサーバ113、装置124とそれぞれ接続されている。ここで、サービス利用者の個人情報はサービス利用者機器141、142、または、ゲートウェイ111に格納される。こうしたゲートウェイやフロアサーバ、装置、利用者機器を総称して、ここでは機器とよぶ。
【００１９】
図２は本発明を適用した機器が２つ接続したシステムの詳細構成を示す。サービス要求側機器201は、外部との通信インタフェースと、各機器での処理を行うためのソフトウェアや各種データを格納する記憶部、記憶部からプログラムを読み出して処理を行う処理部とから構成され、各部が内部バスで接続される。機器201の処理を行うソフトウェアとして、通信処理231、サービス形成処理232、処理プログラム236を有する。各処理で使用するデータとして、ユーザコンテキストテーブル211、システム構成管理テーブル216、要求サービス条件214、資源公開ポリシ217を有する。
【００２０】
通信処理231は、通信インタフェースを介して他の機器との間のデータの交換を行う処理であり、機器間の通信の暗号化等を行う。サービス形成処理232は、自機器のユーザContextテーブル211に格納された個人情報を公開するとともに、システム構成管理テーブル216、資源公開ポリシ217を用いて、他の機器の探索とサービス提供機器の決定を行う。処理プログラム236は、他の機器と連携してサービス提供処理を行う。
【００２１】
ユーザContextテーブル211には個人情報が格納される。個人情報は何らかのアプリケーションプログラムによって生成してもよく、キーボードのような外部入出力部243を介してサービス利用者に入力させてもよい。あるいは、位置情報センサを外部入出力部243に用いて取得してもよい。または、通信処理231を介して他の機器より取得してもよい。
【００２２】
要求サービス条件214には要求サービス及びその条件が格納される。要求するサービス及びその条件は外部入出力部243を介してサービス利用者から入力させてもよく、通信処理231を介してダウンロードしても良い。
【００２３】
外部入出力部243は、例えばセンサやアクチュエータ、カメラなどの処理プログラム236から制御されるデバイスであったり、液晶パネルやキーボード、タッチパネル等のマンマシンインタフェ−スを介して機器上で実行される処理プログラム236の制御や出力値参照を行ったりする機能を有するものである。ただしこれは必須ではなく、外部入出力部を持たない機器もある。
【００２４】
なお、サービス要求側機器201は、サービス利用者機器141〜142であってもよく、サービス利用者が入力を行う装置であってもよく、コンテンツを提供するゲートウェイであってもよい。
【００２５】
サービス提供者側機器202は、処理プログラム235を稼動させてサービスを提供する機器である。機器202は、サービス要求側機器201と同様に、外部との通信インタフェースと、各機器での処理を行うためのソフトウェアや各種データを格納する記憶部、記憶部からプログラムを読み出して処理を行う処理部とから構成され、各部が内部バスで接続される。機器201の処理を行うソフトウェアとして、通信処理231、サービス形成処理232、サービスセッション管理処理233、処理プログラム235を有する。各処理で使用するデータとして、ユーザコンテキストテーブル211、サービスリスト212、機器群管理テーブル213モード管理テーブル215を有する。
【００２６】
サービス形成処理232は、サービス要求側機器201またはサービス提供機器202から提供された個人情報を用いて、自機器、または他機器のサービスリスト212を探索し、サービス提供可能な機器とそのインタフェースを提示する。
【００２７】
サービスセッション管理処理233は、サービス要求側機器201より指定された機器間で連携し、モード管理テーブル215に記載された資源公開モードを用いて、機器間で公開するデータや計算資源、処理プログラムなどの資源を制限する。
【００２８】
処理プログラム235は、サービスを提供するために稼動するアプリケーションプログラムであり、外部入出力部242を介して人間や環境との情報交換を行ったり、外部記憶241を用いてデータの格納や引出しを行ったりする。
【００２９】
機器管理テーブル213には、サービス提供に用いられている機器群に関する管理情報が格納される。サービスリスト212には、処理プログラム235が他処理プログラムへ公開するインタフェースの情報が格納される。
【００３０】
外部入出力部242は、サービス利用側機器の外部入出力部243にて説明したものと同様のものである。
【００３１】
なお、ここではサービス提供機器を１つのみ記載したが、これらは複数存在し、互いに１つまたは複数の通信媒体を介して接続されている。
【００３２】
図３は、ユーザContextテーブル211の構成例を示す。ファイル301は、レコード311〜314で構成される。レコード311は実社会での所在情報を示す項目であり、ここでは住所を示す「Address」が「千代田区千代田1」、所在位置を示す「Location」が「area1」であることが格納される。レコード312はネットワーク上での個人情報を示しており、ここでは、電子メールアドレス「E-Mail Address」が「anon@sdl.hitachi.co.jp」であることが記録される。同様にレコード313は所属団体を示すもので、宗教や所属組合などを格納する。レコード314はユーザの識別子を格納するフィールドであり、たとえば計算機を利用するためのログインIDや、ユーザ自身を示す電子署名などを格納する。
【００３３】
図４は、要求サービス条件214の構成例を示す。（a）は要求サービス条件214全体の構成要素を示す。サービスエントリ651、機能条件652、データ条件653、計算条件654で構成される。
【００３４】
機能条件652は、（b）図に示すように、ソフト資源数612、資源識別子と利用インタフェース613〜614で構成される。ソフト資源数612はサービスエントリ651に示す識別子で表すサービスが利用するソフト資源数を格納する。資源数は項目613〜614の数と同じ数である。資源識別子と利用インタフェース613〜614は、ソフト資源のインデックス、該サービスの利用する処理プログラムの識別子及び利用するインタフェースが格納される。ここで、資源識別子は指定しても、指定せずともよい。項目613の例では、処理プログラムは「*」すなわち任意の処理プログラムで、インタフェース「InfoOut(Map)」で示す処理プログラムを利用することが示されている。インタフェースの識別は、例えば「Inside CORBA−CORBAとそのシステム開発への応用」(ISBN4-7561-2015-6)にあるようにIDL(Interface Definition Language)を用いて記述され、インタフェースリポジトリに格納されるインタフェース名を用いて識別する。または、WSDL(Web Service DescriptionLanguage)に定義されているように一連の呼出手順や処理プログラムからの呼出処理のインタフェースを記述してもよい。
【００３５】
データ条件653は、（ｃ）に示すようにデータ資源数615、データ資源616〜617で構成される。データ資源数615は、サービスエントリ651に示す識別子で表すサービスが利用するデータ資源数を格納する。資源数は項目616〜617の数である。データ資源616〜617は、該サービスの利用するデータの識別子及びアクセス条件を格納する。項目616では、データUserContextの項目「Online」が、項目617ではデータ「Map」が指定されている。データ資源の識別には、ファイル名を用いてもよいし、資源ごとに一意の識別子を用いて識別してもよい。
【００３６】
計算条件654は、（ｄ）に示すように計算資源数618、計算資源619で構成される。計算資源数618は、サービスエントリ651に示す識別子で表すサービスが利用する計算資源数を格納し、項目619の数となる。計算資源619は、ソフト資源で指定された処理プログラムの存在する機器において、該サービスの利用する計算資源と量を格納する。例えば、項目619では、ソフト資源のインデックス１で示される機器で、スレッドを２つ必要とすることが示されている。
【００３７】
図５は、サービスリスト212の構成例を示す。サービスリスト212は、サービスエントリ511、処理プログラム512、インタフェース513、機器識別子514で構成される。サービスエントリ511はサービスの種類を示す識別子を格納するフィールドである。処理プログラム512は、該サービスを提供するために稼動する処理プログラムの識別子を格納するフィールドである。インタフェース513は、該処理プログラムの提供するインタフェースの種類の識別子を格納するフィールドである。インタフェース513は、図４の利用インタフェース同様に、処理プログラムの呼出関数でなく、例えばWSDL(Web Service Description Language)にて定義されているように一連の呼出手順や処理プログラムからの呼出処理のインタフェースも含む。また、処理プログラムは複数連携してサービスを提供する場合がある。
【００３８】
機器識別子514は、各レコードで示される処理プログラムが格納された機器の識別子を格納するフィールドである。自機器に格納した処理プログラムの場合は自機器の識別子を格納する。サービスエントリ511を実現するために他機器の処理プログラムを利用する場合は、該処理プログラム512を格納している機器の識別子を格納する。あるサービスを複数の機器に存在する処理プログラムが連携して提供する場合には、事前にその関係が構築されている場合は、こうした形式でサービスリスト212が構築されている場合もある。
【００３９】
サービスリスト212のレコードは、データ資源の登録があってもよい。この場合、処理プログラムのフィールドにデータ識別子を格納する。レコード523は、この例を示している。
【００４０】
図４、図５で説明したように要求サービス条件及びサービスリストを記述し、後に示すようにこれを照合することで、サービス提供に有効な資源を判断する。なお、本実施例ではソフト資源、データ資源、計算資源の例で説明したが、入出力装置の資源や他の資源を明示的に記述し、管理しても良い。また、資源間のデータの流れを記述し、これを有効な資源の判断に用いてもよい。
【００４１】
図６は、機器群管理テーブル213構成例を示す。機器群管理テーブル213は、フィールド711〜715で構成される。サービスセッション711は、提供中のサービスの実体の識別子を格納するフィールドであり、サービス形成処理232によって生成され、サービスセッション管理処理233によって利用される。ここで、同一のサービス識別子を持つサービスも、実体は複数存在する。例えば、サービス識別子「Navi」で示されるナビゲーションサービスを、機器AAを用いてユーザAに提供している実体と、機器BBを用いてユーザBのために提供している実体が存在する。このように、サービスの識別子が同一でも利用している機器や処理プログラム、ユーザが異なる場合に異なるサービスセッションで識別される。構成メンバ712は該セッションの構成メンバ機器を格納するフィールドである。機器状態713は、該レコードで示す機器の状態を格納するフィールドであり、タスク状態714は、該レコードで示す機器の、該サービスを実行する処理プログラムの状態を格納するフィールドである。フィールド713、714は、例えば特願平１１−３２２１１５にあるような方法を用いることで更新することができる。更新時刻715は、該レコードで示す機器及び処理プログラムの状態を検出した最新時刻を格納する。
【００４２】
図７は、システム構成管理テーブル216の例を示す図である。（a）は、システム構成の論理表現図である。計算機1901〜1907が、通信路1951〜1956でそれぞれ接続されている。（ｂ）は、構成管理テーブルの一部であり、各構成要素の能力を保持する。通信路1911は機器間の通信路の分類を格納するフィールドである。評価尺度1912、保証レベル1913は、各レコードで示される通信路の評価尺度と保証レベルがそれぞれ格納される。レコード1921は、通信路「Ｃ１」すなわち1951〜1953が、評価尺度「Confidential」すなわち通信路の秘匿性に関し、保証レベル「２」であることが示されている。ここで、保証レベルはシステム毎に任意に決められる。例えば、以下のようなレベルで決めることができる。
保証レベル１：機器間での個別の暗号通信
保証レベル２：複数機器間で共有する暗号通信
保証レベル３：メッセージをトレースできるレベル
機器1931は機器の識別子を格納するフィールドである。評価尺度1932、保証レベル1933は、それぞれ通信路と同様に評価尺度と保証レベルを格納するフィールドである。
【００４３】
図７において説明した情報は、図９で説明するサービス形成処理の中で取得してもよい。あるいは、何らかの手段で取得し、格納してもよい。
【００４４】
図８は、資源公開ポリシ217の構成例を示す。フィールド2011は公開する資源の識別子を格納するフィールドである。評価尺度2012、及び保証レベル2013は、それぞれ図７にて説明したシステム構成管理テーブルの場合と同様に、各資源を、公開する際に許容可能な評価尺度と保証レベルが格納される。例えば、レコード2021には、資源「UserContext:Online」は、評価尺度「Confidential」に対して、保証レベル「２」の範囲まで公開することを許す。図７の例では、資源「UserContext:Online」が機器1901に格納されている場合、通信路Ｃ１、Ｃ２では公開されるが、Ｃ３では公開されないことを示している。なお、本例では評価尺度に秘匿性を用いたが、性能などの評価尺度を用いることもできる。
【００４５】
図９は、サービス形成処理232の処理の流れを示す。
【００４６】
サービス要求側機器では、サービス提供側機器にサービスを要求するのに先立ち、資源公開ポリシ217に、アクセス権を公開する資源と評価尺度、保証レベルを設定し、保証レベルを満たす範囲にサービス提供機器探索メッセージの送信範囲を設定しておく（ステップ2111）。送信範囲は、例えばシステム構成管理テーブル216にあるシステム構成と資源公開ポリシ217を照合し、保証レベルを満たす機器のみを指定する。
【００４７】
サービス要求側機器は、要求サービス条件214から要求するサービスの条件を取得し、一意の要求識別子を生成し、署名を作成し、サービス提供機器探索メッセージを送信する（ステップ811）。要求識別子は、例えば自機器の識別子と時刻などを用いて一意となるよう作成する。本メッセージは、「Understanding Universal Plug and Play White Paper」にあるような方法を用いて検索した、提供可能なサービスリストを保持したサーバに対して発行してもよく、またはネットワークセグメントへブロードキャストしてもよい。
【００４８】
本メッセージを受け取ったサービス提供側機器では、本メッセージに記載された条件に合致する資源が自機器にあるかどうかを、サービスリスト212を検索して見つけ出し、それが公開できるか否かを判断する。
【００４９】
ソフト資源やデータ資源の場合はサービスリストに登録されているかで判断する。計算資源の場合は、該指定された資源を確保する。検出したサービスリストのレコード、または確保した計算資源は、モード管理テーブル215にレコードを追加して登録する。ここで、検出された資源が、既に他のサービスのために確保されている場合には、排他制御を行って公開できないと判断してもよい。また、アクセス制御を行ってもよい。
【００５０】
公開できる場合は、サービス要求側機器へ、合致する資源の情報と、要求メッセージにあった署名を付加して返信する。合致する資源が全てまたは一部ない場合は、他のサービス提供側機器へ探索メッセージを転送する（ステップ812）。合致する資源の一部がない場合とは例えばあるサービスリストに記載されたあるサービスを提供する要素の一部である処理プログラムが合致する場合がある。
【００５１】
ここでの他のサービス提供機器への探索メッセージの転送を、例えば「InsideCORBA−CORBAとそのシステム開発への応用」(ISBN4-7561-2015-6)のTraderサービスの方法を用いて、転送回数を制限してもよい。
【００５２】
サービス要求側機器では、ステップ812で発行された応答メッセージを受信し、メッセージに付加された要求識別子と、ステップ811で作成した要求識別子の照合を行って自機器への応答かどうかを確認する。また、該応答メッセージに載せられた資源情報を取得する（ステップ813）。
【００５３】
応答を受信した後、システム構成管理テーブル216、及び資源公開ポリシ217を照合し、サービス提供に有効な資源と、該資源を用いたサービス提供形態の組合せを抽出する。ここで、資源間のデータの流れを要求サービス条件214に記述しておき、これも含めて判断してもよい。その後、所定の判断基準でサービス提供機器として利用する機器を選定する（ステップ814）。
【００５４】
ここで判定したサービスが有効であるかを所定の評価尺度で判定する（ステップ2113）。所定の評価尺度は、ここでは、要求サービス条件に記載したサービスを提供する資源が全てアクセス可能か否かであるとする。判定が有効である場合には、選定された機器へ、アクセス権を示すセッション識別子情報と、資源の割当てを送信し（ステップ815）、サービスを受ける。
【００５５】
ステップ2113の判定で、有効でない場合は、資源公開ポリシ217を更新し（ステップ2115）、ステップ811に戻る。資源公開ポリシの更新は、例えば保証レベル2003の条件を緩くする、あるいは、公開する資源を追加する、のどの処理とする。これらを、要求サービス条件214と探索できた資源の差異から選定してもよい。
【００５６】
サービス提供機器の選定は、本実施例では省略しているが、例えば資源の属性などをサービスリスト212に登録しておき、これを資源情報と共に返信することで用いることもできる。またサービス提供機器探索メッセージに付加されたデータを用いて、サービス要求側機器の認証やアクセス制御を行ってもよい。更に、特定のサービスを提供するためのサービス提供機器の指定に、本実施例ではメッセージにセッション識別子を付加して配布する方法を示したが、特願２００２−４４１１３号に示すようにサービス毎に機器間でデータ共有のためのセッションを確立し、これを用いて特定のサービスを識別してもよい。また、本実施例では、サービス提供機器探索メッセージに要求サービス条件を付加し、サービス提供機器で提供可能な資源を探索する例を示したが、提供可能な資源のみを探索し、サービス要求側機器で要求サービス条件と照合してもよい。
【００５７】
なお、上記の処理フローは、資源の可用性が事前に記述困難な場合、すなわちアクセス権を公開してみないとサービスの有効性が判定できない場合の例（例えば、特定の人を指定した個人情報が要求サービス条件に含まれており、不特定のサービス提供機器に送信したくない場合）として、「公開範囲を限定して提供可能なサービスを判定し、公開範囲を段階的に拡張して提供するサービスを決定する方法」を含めた処理フローで説明したが、上記の場合の処理を行わなくてもよい状況であれば、この処理(ステップ2111, 2113, 2115)を省略してもよい。
【００５８】
図１０は、各機器間で交換されるメッセージ構成例を示す。（a）図は、サービス提供機器の探索メッセージの構成例を示す図である。これは、図９にて説明したサービス形成処理232のメッセージ（１）で発行されるものである。本メッセージは、メッセージヘッダ911、メッセージ種別912、要求サービス条件913、要求元署名914、要求識別子915、データ916で構成される。メッセージヘッダ911は通信処理231で用いるもので、機器間でのデータ交換を行うために必要な情報が格納される。メッセージの暗号化や、送信元の匿名化などもここで行う。メッセージ種別912は、該メッセージの種類を識別する情報を格納し、例えばサービス提供機器探索メッセージや、これへの応答メッセージなどの情報が格納される。要求サービス条件913は、サービス提供機器探索の条件で、図４にて説明した要求サービス条件214の情報が格納される。要求元署名914は、該サービス提供機器探索メッセージを発行したサービス利用側機器での、該メッセージ発行時の署名を格納する。要求識別子915は、該サービス提供機器探索メッセージを一意に識別する情報である。データ916は、その他の付加データを格納するフィールドである。
（b）図は、（a）図にて説明したサービス提供機器探索メッセージへの応答メッセージの構成例を示す図である。これは、図９にて説明したサービス形成処理232のメッセージ（２）で発行されるものである。メッセージヘッダは（a）図同様であり、メッセージ種別912には、サービス提供機器応答メッセージであることが格納される。要求元署名914、要求識別子915には、該応答を送信するトリガとして受け取ったサービス提供機器探索メッセージに格納されていた、要求元署名914、要求識別子915がそれぞれ格納される。提供サービス921には、サービスリスト212から取得された該応答メッセージの送信元機器で提供される資源、またはサービスの識別子と関連情報が格納される。
（c）図は、サービス提供機器を決定し指定するメッセージの構成例を示す図である。これは、図９にて説明したサービス形成処理232のメッセージ（３）で発行されるものである。メッセージヘッダ911、メッセージ種別912、要求元署名914、セッション識別子932、は（a）図において説明したサービス提供機器探索メッセージ同様である。ここで、セッション識別子932は、ステップ815にて生成した、該サービス提供のために資源を利用する鍵となる一意の識別子が格納される。割り当てデータ931には、該サービスを提供するために稼動する資源識別子の列が格納される。（ｃ）図では、ソフト資源の例として、ソフト資源識別子と利用インタフェースを、フィールド941〜942に格納している例を示している。ここで、割り当てデータ931を構成する資源の数は任意の個数をとりうる。
【００５９】
なお、本実施例においてはサービス要求側機器201に資源公開ポリシ217が存在する例を示したが、他の機器に存在する場合でも、該資源公開ポリシ217を取得することで容易に実施することができる。
本実施例で説明した方法により、アクセス権を公開する資源の範囲に応じて、提供可能なサービスのレベルを判定し、適切なサービスを形成することができる。
【００６０】
図１１は、モード管理テーブル215の構成例を示す。モード管理テーブル215は、資源識別子411、公開モード412、公開目的サービス413から構成される。資源識別子411は、該機器内の資源の識別子であり、処理プログラムやデータ、計算機資源などの識別子が格納される。公開モード412は、各レコードで指定された資源の公開モードを格納する項目であり、例えば以下のような指定を行う。
・Public：任意の要求に対して公開する状態
・Private：特定のサービス提供の目的のみに公開する状態
・Protected：特定のサービス提供に、実際に使用されている状態
公開目的サービス413は、各レコードで指定された資源を公開する目的となるサービスの識別子を指定する。例えばレコード422は、資源「地図データ」が、識別子「Navi」で指定されるサービスのために他資源に公開することが示されている。レコード424は、資源「<Thread>」で示されるオペレーティングシステムのスレッドが、サービス「Navi」のうち、本発明の第1の実施例に示した方法によって特定の資源が選択され、セッション識別子「1」が割当てられたもののために使用可能であることを示している。
【００６１】
図１５は、サービス1111としてユーザA用の「ビデオ鑑賞サービス」を、サービス1112として、ユーザB用のサービス（空調温度制御）を提供しているサービス構成例を示す。サービス1111は、資源「スピーカ」を用いる共に、他のサービス1121「映像再生」を用いてサービスを提供している。サービス「映像再生」は、資源「VCR」及び資源「スピーカ」を用いてサービスを提供する。ここで、サービス1111とサービス1112のユーザは別であり、これらの間ではデータを公開しない。サービス1111とサービス1121は同一のユーザA向けのサービスであり、サービスを提供するためにデータが共有される。
【００６２】
図１２は、例えば図１５で示すようなサービス提供時のサービスセッション管理処理233の処理の流れを示す。ここで、サービス提供側機器xはユーザContextテーブル1121を持つ機器1101を、サービス提供側機器ｙは、サービスを提供するアプリケーションプログラムを持つ機器101を示している。ここで、機器ｘと機器ｙが連携することは、前述したサービス形成処理232によって指定される。
【００６３】
サービス提供側機器ｙより位置情報を要求を発行し（ステップ1011）、サービス提供側機器ｙではこれを受信し（ステップ1012）、該要求メッセージにあるサービスセッション識別子を確認する（ステップ1013）。
【００６４】
この後、サービス間の階層関係を探索する（ステップ1211）。資源が確保できた合は、要求サービスの指定メンバであるかを確認する。サービス形成処理232によって形成されたサービスである場合、すなわち機器群管理テーブルに登録されたサービスセッションと機器の組である場合は要求データを返信する（ステップ1016）。資源が確保できない場合及び要求サービスの指定メンバでない場合要求を拒絶する（ステップ1015）。
【００６５】
ここで、サービスの階層の記述は、サービスリスト212に形成されたサービスを登録することで形成される。また、機器群管理テーブル213のタスク状態714に構成要素となるサービスを登録することで、他のサービスとの関係や状態を管理することができる。
【００６６】
サービス間でのデータの共有は、モード管理テーブル215に、構成要素となるサービスの識別子を資源識別子として登録することで制御できる。これを用いて、以下のような用途に応じて制御することができる。
・データの公開範囲制限：ユーザの位置データを特定機器間で共有する際に、これらの機器間でデータ共有するサービスを独立に設定する。該サービスと他の機器を連携させるサービスを設定し、他の機器へは特定位置に来たトリガや、ユーザ位置付近のコンテンツなどの処理結果のみを提供する。
・資源の公開制限：あるサービスの構成要素となることで、他のサービスへは資源を直接公開しないようにする。例えば、ビデオ出力をTVへ出力する映像再生サービスを提供している間は、TVの番組設定や電源設定などのインタフェースを持つ処理プログラムへのアクセスを抑止する。
【００６７】
この方法では、全ての資源の組合せに対して資源利用可否を記述せずともサービスを形成できる。
【００６８】
本実施例では、アプリケーションプログラムの存在するサービス提供側機器ｙからデータを要求する例を示したが、ユーザContextテーブルを持つサービス提供側機器ｘより、管理しているサービスセッション識別子に応じたデータを、自発的に送信してもよい。このとき、サービス提供機器yでは、該サービスセッション識別子で指定されたサービスを提供する資源のみにデータを渡し、それ以外の資源へはデータを渡さないよう制御する。また、サービスセッション識別子を該公開データの暗号化の鍵として利用し、公開側で暗号化、利用側で複合化を行ってもよい。
【００６９】
本実施例のサービスセッション管理により、特定のサービス提供に有効な資源以外に、資源のアクセス権を公開せず、要求された品質を保って必要なサービスを形成することができる。
【００７０】
なお、サービスが階層化されていても、各サービスに対応するモードの機器間での情報の転送制御を行わなくてよい場合は、ステップ1211及びその次の判定ステップを省略できる。
【００７１】
次に、機器がモード管理を行う機能を持たない場合に、ソフトウェアを配信し、該ソフトウェアにより機器のモード管理を行う実施例について説明する。
【００７２】
図１３は、サービス形成処理の、ソフトウェア配信処理の流れを示す図である。サービス利用側機器とサービス提供側機器の間で、例えば「Understanding Universal Plug and Play  White Paper」に記載されている公知の方法を用いてサービス提供機器群を探索し（ステップ1311）、サービス提供に有効な機能を持つ機器群を選択し、該提供するサービスに必要な資源管理機能を選択し（ステップ1312）、該選択された資源管理機能を持つソフトウェアを選択された機器へ配信する（ステップ1313）。配信された機器では、これを受信し、該機器で既に稼動しているソフトウェアと連携させる（ステップ1314）。
【００７３】
図１４は、配信ソフトと既存プログラムの結合例を示す図である。本実施例においては、例えば「Understanding Universal Plug and Play  White Paper」に記載されている方法を実装している場合の例を説明する。このとき、機器にはサービスリスト212が存在し、通信処理1711を介して処理プログラム235とデータの送受信を行うことができる。処理プログラム215は、外部入出力部242や、外部記憶241へアクセスしてデータ処理を行う。配信されたソフトウェア1712は、通信処理1711を介して処理プログラム235と連携する。このとき、処理プログラムと他機器の処理プログラムを直接連携させず、配信されたソフトウェア1712を介して他機器と連携するようにして、1712でモードの管理を行う。また、該機器内のソフトウェア構成は、通信処理を介してサービスリスト212を取得し、配信されたソフトウェア1712を介してのみ他機器へ公開することとする。
【００７４】
本実施例においては、サービス利用側機器からソフトウェアを配信する例を示したが、他の機器から行ってもよい。また、本実施例において配信するソフトウェアとして、データや処理プログラムの公開、計算資源の確保を行うソフトウェアの他、機器間のデータ送受信を監視するためのソフトウェアを配信してもよい。
【００７５】
本実施例で説明した方法により、事前にモード管理機能を有していない機器でも、サービス提供に有効なモードを管理することが出来るようになる。
【００７６】
以上述べた実施例によれば、動的に発見した資源群の中で、サービスに応じて該サービス提供に有効な資源群のみで柔軟に資源を連携できる。特にアクセス権を公開する資源の範囲に応じて、提供可能なサービスのレベルを判定し、適切なサービスを形成することができる。
【００７７】
また、各資源が特定のサービス提供に有効であるかどうかを識別するモードを持ち、これを用いて公開資源を制御することで、所望のサービスを提供するのに有効な資源以外にデータ公開せず、要求された品質を保って必要なサービスを形成できる。
【００７８】
更に、サービス間の階層的な関係を管理し、これに応じて資源公開することで、全ての資源の組合せに対して資源利用可否を記述せずともサービスを形成できる。
【００７９】
更に、各機器へ資源管理ソフトウェアを配信し、各機器では該ソフトウェアを介してアプリケーション間のデータ送受信や実行管理を行うことで、事前にモード管理機能を有していない機器でも、サービス提供に有効なモードを管理することが出来る。
また、不特定の機器に資源を公開せずとも、公開範囲を限定して提供可能なサービスを判定し、公開範囲を段階的に拡張して提供するサービスを判定することができる。
【００８０】
【発明の効果】
本発明によれば、動的に発見した資源群の中で、サービスに応じて該サービス提供に有効な資源群のみで柔軟に資源を連携できる。
【図面の簡単な説明】
【図１】本発明の一実施例のシステム全体構成を示す図。
【図２】システム構成の詳細ブロックを示す図。
【図３】ユーザContextテーブル211の構成例を示す図。
【図４】要求サービス条件214の構成例を示す図。
【図５】サービスリスト212の構成例を示す図。
【図６】機器群管理テーブル213の構成例を示す図。
【図７】システム構成管理テーブル216の構成例を示す図。
【図８】資源公開ポリシ217の構成例を示す図。
【図９】サービス形成処理232の処理の流れを示す図。
【図１０】メッセージ構成例を示す図。
【図１１】モード管理テーブル215の構成例を示す図。
【図１２】サービスセッション管理処理233の処理の流れを示す図。
【図１３】サービス形成処理がソフトウェア配信する実施例の処理の流れを示す図。
【図１４】配信ソフトと既存プログラムの結合例を示す図である。
【図１５】特定サービスを実現している状況のシステム構成を示す図。
【符号の説明】
通信処理231、サービス形成処理232、サービスセッション管理処理233、機器構成管理234、処理プログラム235、236、ユーザContextテーブル211、要求サービス条件214、サービスリスト212、機器群管理テーブル213、モード管理テーブル215、システム構成管理テーブル216、資源公開ポリシ217、外部記憶241、外部入出力部242、243。
【図１】
2004199300.tif 000003
【図２】
2004199300.tif 000004
【図３】
2004199300.tif 000005
【図４】
2004199300.tif 000006
【図５】
2004199300.tif 000007
【図６】
2004199300.tif 000008
【図７】
2004199300.tif 000009
【図８】
2004199300.tif 000010
【図９】
2004199300.tif 000011
【図１０】
2004199300.tif 000012
【図１１】
2004199300.tif 000013
【図１２】
2004199300.tif 000014
【図１３】
2004199300.tif 000015
【図１４】
2004199300.tif 000016
【図１５】
2004199300.tif 000017