JPWO2003034776A1 - アドホックなネットワークにおけるコンポーネントを統合したサービス提供システムに使用する装置 - Google Patents

Abstract

ユーザがサービスの提供の要求送信に使用するＩｎｉｔｉａｔｏｒと、ＣＤプレーヤーなどの複数のコンポーネントなどからなるアドホックネットワークにおいて、Ｉｎｉｔｉａｔｏｒは、サービスの提供を受ける前に、各コンポーネントからそれぞれが提供できるサービスなどを記述した目録を収集し、目録の情報を照らし合わせて、利用可能なサービスを列挙する。そして、ユーザにサービスを選択させ、所定のコンポーネントを無線あるいは有線接続した装置によって、ユーザに好みのサービスの提供を受ける。

Description

技術分野
本発明は、通信が可能な端末とアドホックなネットワークを構成できる通信可能なデバイスのサービス提供システムに関する。
背景技術
従来のインターネット技術では、ＵＲＩ（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）あるいはＵＲＬ（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）などを使用したＷｏｒｌｄ Ｗｉｄｅ Ｗｅｂ（ＷＷＷ）はＦｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＦＴＰ）といった、予めリソースの位置やサービス（機能やデータ提供などの総称を以下サービスと定義する）が固定されたアクセス方法が主であった。そのため、端末同士が直接通する事によってローカルなネットワークを形成し、個々の端末の機能を統合してユーザに所定のサービスを提供するアドホックなネットワークでは、場所場所によって、異なる端末がおかれているため、ユーザが物理的にどのような端末の近くにいるのかがサーバからは分からないことが起こり、ユーザにどのようなサービスが利用可能か分からない状況では、提供可能なサービスを特定することが難しかった。
そして、アドホックなネットワークにおいては、基本的に無線通信が可能な携帯型端末を使用するために、使用できるリソースが限られている。そのようなリソースが限られた携帯型端末では１つの携帯型端末が全てのサービスを持つことが不可能であるため、デバイス自体は単機能を持ち、それらを複数組み合わせて統合的なサービスを提供することが要求されている。
従来の通信（特に無線通信）が可能な端末をアドホックなネットワークに接続するときには、ユーザや各デバイスは、ユーザにどのようなサービスが提供できるのか分からなかった。サービスの発見手法にはＩＰ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）でのＳＬＰ（Ｓｅｒｖｉｃｅ Ｌｏｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）やＢｌｕｅｔｏｏｔｈのＳＤＰ（Ｓｅｒｖｉｃｅ Ｄｉｓｃｏｖｅｒｙ Ｐｒｏｔｏｃｏｌ）がある。しかし、ＳＬＰは、ＵＲＩあるいはＵＲＬという位置情報を基に、リソースの発見を行うため、アドホックなネットワークには適用できにくい。また、ＳＤＰは、その機能を表す大まかなクラス（プロファイル）を検出することを目的としているため、リソース単体単位での細かいサービスの提供ができない。そして、複数の機能を組み合わせて、１つの大きなサービスを提供するためには、リソース単体単位での細かいサービス提供が必要になる。この場合、リソース単体単位での細かい小さなサービス（機能）を組み合わせることで、１つの大きなサービスを提供することが必要となる。
発明の開示
本発明の課題は、各端末が有する各サービスを組み合わせて、ユーザに一定の統合されたサービスを提供可能とする装置を提供することである。
本発明のシステムに使用する情報端末は、有線あるは無線でネットワークを構成する１以上のデバイスが提供する機能を統合して所定のサービスを受けるために使用される、該１以上のデバイスに有線あるいは無線で接続された情報端末であって、該１以上のデバイスが有する、所定の機能を実行するコンポーネントの提供可能サービスに関する情報を、各デバイスから受け取る情報収集手段と、該収集された情報から、該１以上のデバイスを組み合わせて受けることのできるサービスを検出するサービス検出手段と、該検出されたサービスに基づいて、該サービスの提供に含まれるデバイスにサービスの実行を指示する手段とを備えることを特徴とする。
本発明によれば、サービスの指示手段であるＩｎｉｔｉａｔｏｒからユーザが指示を出すことによって、場所場所によって異なる構成をなすアドホックなネットワークについても所望のサービスを容易に受けることができる。これは、Ｉｎｉｔｉａｔｏｒが、当該ユーザの居る場所にあるデバイスのコンポーネントと通信し、コンポーネントから提供可能サービスについての情報である目録を取得し、これに基づいて、利用可能なサービスを検出することによる。
発明を実施するための最良の形態
図１は、本実施形態のシステム構成の概念図である。また、図２は、本実施形態のシステムを構成する端末の概念構成を示す図である。
本実施形態では、図１に示すように通信機能（特に無線通信機能）を持つ複数のデバイスがアドホックなネットワークを形成している。それぞれのデバイスは図２のように小さなサービス（機能）をコンポーネントとして提供する。単一のコンポーネントだけでは十分なサービスを提供できないため、複数のコンポーネントを組み合わせることにより、１つのサービスを提供する。
デバイスの中には、ユーザが管理を行うＩｎｉｔｉａｔｏｒというデバイスが存在する。そのＩｎｉｔｉａｔｏｒは、ユーザとのユーザインターフェースの役割をする。しかし、Ｉｎｉｔｉａｔｏｒは必ずしもユーザインターフェースを持つ必要はなく、アドホックネットワーク内にユーザインターフェースとなるデバイス（表示デバイスとユーザ入力デバイス）が存在すればよい。しかし、通常はＩｎｉｔｉａｔｏｒがユーザインターフェースを持つ。そこで、以降Ｉｎｉｔｉａｔｏｒがユーザインターフェースを持つと仮定する。Ｉｎｉｔｉａｔｏｒはユーザからの要求を受け取って、個々のコンポーネントに機能提供を要求し、個々のコンポーネントの機能を連結したサービスをユーザに提供する。そして、サービスの変更が必要なとき、サービスが完了するとき等にはユーザに通知を行う。そのため、Ｉｎｉｔｉａｔｏｒはアドホックネットワークの中で、必ず必要なデバイスとなる。したがって、Ｉｎｉｔｉａｔｏｒは複数のコンポーネントをどのように組み合わせるかの判断を行ったり、各コンポーネントに要求を送ったりする中心的な役割を果たす。
Ｉｎｉｔｉａｔｏｒの持つ機能は、以下の通りである。
・ユーザインターフェースを提供する機能
・コンポーネントから機能を発見する機能
・機能を組み合わせるために機能間連係のグラフを生成する機能
・コンポーネントに要求を送信する機能
・コンポーネントからイベントを受け取る機能
コンポーネントはデバイス中に複数存在する。コンポーネントが持っている機能は下記の通りである。
・コンポーネントが持っている機能を提示する機能
・Ｉｎｉｔｉａｔｏｒからの指令を受ける機能、Ｉｎｉｔｉａｔｏｒにイベントを通知する機能
・他のコンポーネントからのデータを受信する機能
・他のコンポーネントにデータを送信する機能
・ステータスを送受信する機能を持つ。
ここで、ステータスとは、コンポーネントがサービスを行うために必要な状態をオブジェクトにまとめたもとのである。
図３及び図４は、アドホックネットワークの具体例を示した図である。
図３では、家庭内や喫茶店などにおいて、家電相当の製品を操作する場合を示している。Ｉｎｉｔｉａｔｏｒとしては、ユーザの有する携帯電話が設定され、ビデオカメラ、ＣＤプレーヤー、テレビ、スピーカなどのコンポーネントを操作して、例えば、お気に入りの音楽をかけたり、お気に入りの番組をテレビに映し出させたりする。スピーカは、ＣＤプレーヤーやテレビなどと協同して、音声を出力する。また、ビデオカメラは、テレビとスピーカと協同して、ビデオカメラで撮影した画像と音声をそれぞれテレビ及びスピーカに出力させるように使用することが可能である。
図４は、携帯電話同士での情報のやりとりを示した図である。
図４に示されるように、携帯電話同士は、基地局を介すことなく、互いに通信し、その中の１つがＩｎｉｔｉａｔｏｒとなる。いずれの携帯電話も、後述する機能を有していれば、Ｉｎｉｔｉａｔｏｒとなることができる。また、Ｉｎｉｔｉａｔｏｒ以外の携帯電話は、個々のサービスを提供するコンポーネントとなる。なお、携帯電話のユーザの中には、アドホックネットワークに自分の携帯電話が取り込まれるのを嫌う人が居るので、携帯電話は、Ｉｎｉｔｉａｔｏｒからのサービス要求に対してサービスの提供を拒否することができるように構成することが好ましい。
「サービスの発見」
図５は、Ｉｎｉｔｉａｔｏｒが使用可能なサービスを調べる様子を概念的に示した図である。
アドホックネットワーク内での統合したサービスを行うために、図５のように、Ｉｎｉｔｉａｔｏｒは、各コンポーネントからそのコンポーネントが提供できる機能を記述した目録を受け取る。Ｉｎｉｔｉａｔｏｒは、アドホックネットワーク内の全てのコンポーネントから、その目録を受け取る。
図６は、目録の収録情報を示す図である。
図６のように目録には、下記の情報が記述されている。
・そのコンポーネントが提供できる機能のクラス（コンポーネントが持つ機能の属するクラス）
・受信可能なデータのクラス（コンポーネントが入力するデータストリームのクラス）
・そのコンポーネントが加工した送信可能なデータのクラス（コンポーネントが出力するデータストリームのクラス）
・そのコンポーネントが他のコンポーネントにステータスを渡したり、他のコンポーネントからステータスを受け取ったりするためのポート（ステータスを送受信するポート）
図７は、コンポーネント間の接続と、目録の記載内容との関係を説明する図である。
Ｉｎｉｔｉａｔｏｒは、図７のように、コンポーネントＡの送信可能なデータのクラス（＝αとする）とコンポーネントＢの受信可能なデータのクラス（＝βとする）が一致またはβのクラス階層をさかのぼることでαと一致する場合には、接続可能であるとして、Ｉｎｉｔｉａｔｏｒ内のコンポーネントを識別する情報に印を付ける。このように、全てのデバイスのコンポーネントに対して、同様の処理をすることによって、各コンポーネント間の接続可能な組を抽出し、接続可能なブランチ（コンポーネント間の接続関係）を作成することで、図８のようなグラフを作成する。このとき、コンポーネントの存在の仕方によっては、グラフにループができる。そこで、図９のようにブランチを作成するときに同一ブランチを通るようなループが見つかると、そのブランチを削除してループが生じないようにする。
図８及び図９は、Ｉｎｉｔｉａｔｏｒが検出するコンポーネント間の接続関係を概念的に示すグラフを説明する図である。
例えば、図８において、コンポーネント１で再生される音声をコンポーネント４で出力する場合を考える。まず、Ｉｎｉｔｉａｔｏｒは、目録に含まれているコンポーネント１とコンポーネント２のサービスのクラスを調べた結果、コンポーネント１とコンポーネント２が共に、ＰＣＭで音声を通信可能であることが分かると、コンポーネント１と２をＰＣＭのフォーマットで通信することに決定する。同様に、コンポーネント１と３は、ＭＰ３での通信が可能なので、ＭＰ３での通信を決定する。また、コンポーネント３とコンポーネント２との間は、ＰＣＭで通信することを決定する。このとき、コンポーネント３は、ＭＰ３音源をＰＣＭ音源に変換する機能を有しているものとする。そして、コンポーネント２とコンポーネント４がＭＤのフォーマットで音声を通信することを決定する。
これにより、例えば、ＣＤプレーヤーなどであるコンポーネント１から、スピーカなどであるコンポーネント４までの経路が検出され、ＣＤの再生が可能であることがＩｎｉｔｉａｔｏｒのユーザに通知される。なお、コンポーネント１からコンポーネント２と３のどちらの経路を使うかは、後述する経路選択の優先順位に基づいて決定される。
図９は、経路検出のときにループ上になってしまう経路を検出、削除する処理の概念を説明する図である。
図９においては、コンポーネント１から、コンポーネント２、３と経路を辿ると、コンポーネント３において、可能な経路が２つ出てくる。すなわち、コンポーネント３からコンポーネント４と５に進む経路である。コンポーネント５に進む経路は、例えば、音声再生におけるスピーカのような経路が終了するコンポーネントに至っているので問題はないが、コンポーネント４の場合、この接続先を探すと、コンポーネント２となってしまう。従って、コンポーネント２、３、４によって、不要な経路のループが生じてしまう。従って、コンポーネント４の接続先として、既にブランチを持っているコンポーネント２のようなコンポーネントに至る場合には、そのブランチは生成せず、また、コンポーネント３から４へのブランチも削除するようにする。
図１０は、Ｉｎｉｔｉａｔｏｒが行う、コンポーネントとコンポーネントとの間にブランチを形成する場合の処理を説明する図である。
コンポーネントＡの目録には、サービスとして、音声が設定されており、音声クラスの下の階層には、ＰＣＭ音声サービスが設定されているとする。また、コンポーネントＢの目録には、音声クラス、その下位にＰＣＭ音声、更にその下位にＭＰ３音声がサービスとして設定されているとする。
まず、Ｉｎｉｔｉａｔｏｒは、コンポーネントＡの目録から「出力するデータストリームのクラス（α）」を取り出す。ここで、クラス情報にはクラス階層の情報も含まれている。また、コンポーネントＢの目録から「入力するデータストリームのクラス（β）」を取り出す。ここでも、クラス情報には、クラス階層の情報も含まれている。
次に、βのクラス階層（例えば、ＭＰ３音声＞ＰＣＭ音声＞音声）を階層の深い順からαのクラス階層（例えば、ＰＣＭ音声＞音声）に一致するかを試みる。すると、図１０の例では、βの最初のクラス（ＭＰ３音声）とαのクラス階層（ＰＣＭ音声）を比較するが、一致しないことが分かる。次に、βの次のクラス階層（ＰＣＭ音声）とαのクラス階層（ＰＣＭ音声）を比較する。ここで、一致が見られる。そこで、クラス階層が一致した時点でブランチ（コンポーネントＡとコンポーネントＢの接続関係）を作成する。
図１１は、Ｉｎｉｔｉａｔｏｒによるグラフの作成フローチャートである。
まず、ステップＳ１において、入力クラスのないコンポーネントを列挙する。すなわち、アドホックネットワークにおいて、受け入れるべき入力データの形式がないコンポーネントを列挙する。次に、そのコンポーネントの出力クラスに対応する入力クラスを持ったコンポーネントを検索する。このとき、複数のコンポーネントが対応する場合には、複数のコンポーネントの識別情報にマークを付ける。そして、ステップＳ３において、スタック形式で、ブランチを形成する。ステップＳ４では、ブランチの接続先のコンポーネントが出力クラスのないコンポーネントであるか否かを判断する。すなわち、アドホックネットワークの通信データを他のコンポーネントに出力することのできないコンポーネントであるか否かを判断する。
ステップＳ４の判断がＹＥＳの場合には、ステップＳ８において、ブランチの作成が終了したとして、ステップＳ６に進む。ステップＳ４の判断がＮＯの場合には、ステップＳ５において、ブランチが既に検索したコンポーネントに接続しているか否かを判断する。
ステップＳ５の判断がＮＯの場合には、ステップＳ９において、処理対象を今ブランチ接続先となっているコンポーネントに移動し、次のブランチを作成するために、ステップＳ２に進む。ステップＳ５の判断がＹＥＳの場合には、ステップＳ６において、ステップＳ２において、マークを付けたコンポーネントまでスタック上に存在するブランチを削除し、ステップＳ７において、マークが付いたコンポーネントに他へのブランチの候補があるか否かを判断する。ステップＳ７の判断がＹＥＳの場合には、ステップＳ１０に進んで、最初のコンポーネントに戻ったか否かを判断する。ステップＳ１０の判断がＮＯの場合には、今まで削除した経路では、別の経路が見つからないので、ステップＳ６に戻って、ブランチを更にさかのぼって削除し、マークの付いたコンポーネントまで戻る。ステップＳ１０の判断がＹＥＳの場合には、ステップＳ１１に進んで、次の入力クラスのないコンポーネントへ移動し、ステップＳ２に戻る。ステップＳ７の判断がＮＯの場合にも、ステップＳ２に戻って、処理を繰り返す。
図１２及び図１３は、ブランチ作成の様子を図示した図である。
図１２に示す場合を想定する。ここでは、コンポーネントを数字の１〜５で表し、入出力クラスの関係をアルファベットＡ〜Ｃで表す。このときのスタックの様子が図１３である。
まず、最初の入力クラスのないコンポーネントをスタックに追加する。次に、コンポーネント１に接続するコンポーネント２をスタックに追加する。更に、コンポーネント２に接続するコンポーネント３を追加する。コンポーネント３は複数の出力先を持つので、マークをする。更に、コンポーネント３に接続するコンポーネント４を追加する。更に、コンポーネント４に接続するコンポーネント２を追加する。しかし、コンポーネント２は、既にパス上（スタック）に存在するので、マークのあるコンポーネント３まで削除する。そして、コンポーネント３は、別の出力先候補であるコンポーネント５に接続するので、コンポーネント５をスタックに追加する。最後に、コンポーネント５は、出力クラスを持っていないので、ここでパスの生成が完了する。
図１４は、複数のパス（ブランチのつながりであり、図１３のスタック）が検出された場合に、優先順位を付けて、経路（パス）を選択する処理を説明する図である。
図１４においては、丸の中の数字はコンポーネントの階層の深さを示し、矢印の数字は、ブランチの階層の深さをそれぞれ示す。
まず、全ての経路（パス）について以下を計算する。
コンポーネントのクラス階層の深さをｎ_ｉ、ブランチのクラス階層の深さをｂ_ｉとした場合、
αΣ１／ｂ_ｉ＋βΣ１／ｎ_ｉ ・・・（１）
そして、（１）式の計算結果の小さいものから優先順位を高く設定する。なお、過去に既に類似のパスが選択されていた場合には、その優先順位を高くする。
例えば、図１４の例の場合、α＝１、β＝１とすると、上を通る経路の場合、（１／３＋１／２＋１／４＋１／１）＋（１／２＋１／１＋１／２）＝４．０８、
一方、下を通る経路の場合、（１／３＋１／１＋１／３＋１／１）＋（１／１＋１／３＋１／２）＝４．５
となり、上のパスの値のほうが小さいので、上のパスの優先順位を高くする。
「サービスの提供」
図１５は、サービス一覧の表示例である。
Ｉｎｉｔｉａｔｏｒは、図１４で説明したように、生成したグラフから、コンポーネントのクラス及び入出力データクラスの重みが大きいもの（クラス階層が深い、継承しているクラスが多い）から、そして、全パス長が短いものから、高い優先順位を付け、図１５のようにパスをユーザに提供可能なサービスとして提示する。
また、一般にアドホックネットワークであっても、ユーザが個人的に使用する場合には同一なサービスを選択する可能性が高い。そこで、過去に似たようなサービス（パス）を選択していれば、そのサービスをユーザに提示する時に優先順位を高くする。こうすることで、ユーザの利便性が向上する。
ユーザは、Ｉｎｉｔｉａｔｏｒが提示したサービスから自分の欲するサービスを選択し、Ｉｎｉｔｉａｔｏｒに伝達する。Ｉｎｉｔｉａｔｏｒは、選択されたパスにどのコンポーネントが存在するのかを知っているので、選択されたサービスに基づいて、そのパス上に存在するコンポーネントにＩｎｉｔｉａｔｏｒから要求を送信する。
図１６は、サービス提供に当たってのコンポーネントの動作を概略説明する図である。
Ｉｎｉｔｉａｔｏｒから要求を受けたコンポーネントは、図１６のように自分が持っている機能を使用して入力データを入力し、データを加工して新しく出力データとして出力する。
図１７は、前述のパスの検索処理に先立って、各コンポーネントからＩｎｉｔｉａｔｏｒが受け取る目録の例を示した図である。
目録の内容は、コンポーネントの種類によって異なる。例えば、ＣＤプレーヤーの場合が図１７に示されている。コンポーネントのクラスとしては、音声出力の下位に、音楽演奏、その下位に、ＣＤプレーヤーがもたれている。入力クラスはない。出力のクラスは、音声の下位に、ＰＣＭ音声が設定されている。すなわち、アドホックネットワークにおいて、このＣＤプレーヤーは、ＰＣＭ音声によって再生した音楽を送信することになる。また、後述するステータスとしては、曲情報や演奏時間などがもたれる。
図１８は、コンポーネントがＩｎｉｔｉａｔｏｒへ目録を送信する場合の処理フローを示す図である。
まず、ステップＳ１５において、Ｉｎｉｔｉａｔｏｒから目録要求を受け付ける。そして、ステップＳ１６において、予めコンポーネント内に設けられている情報を目録としてＩｎｉｔｉａｔｏｒに送付する。
図１９は、サービス開始の処理を示すフロー図である。
まず、ステップＳ２０において、Ｉｎｉｔｉａｔｏｒからサービス開始要求を受け取る。このとき、Ｉｎｉｔｉａｔｏｒからは、上流及び下流のコンポーネントの情報も含めて受け取る。そして、ステップＳ２１において、当該コンポーネントより上流にあるコンポーネントのデータを受け入れる。そして、ステップＳ２２において、当該コンポーネントより下流にあるコンポーネントにデータを送信する。
図２０は、Ｉｎｉｔｉａｔｏｒが持つ、グラフのデータフォーマットの例を示す図である。
前述したように、Ｉｎｉｔｉａｔｏｒは、サービスを提供するために、各コンポーネントを接続するグラフを作成するが、これは、図２０のように、コンポーネント名、機能クラス、入力クラス、出力クラスを登録するテーブルによって保持される。図２０の場合、ＣＤプレーヤーが音声をＰＣＭ音声で送信し、スピーカがＰＣＭ音声を受け取って、出力する構成となっていることが分かる。
「サービスの遷移」
アドホックネットワークは、デバイスが自由に結合したり分離したりすることができることが特徴である。そのため、サービスを提供していたデバイスが分離したり、新たにサービスを提供可能なデバイスが結合したりする。
図２１〜図２３は、コンポーネントがアドホックネットワークから分離・合流した場合の動作の概念を示す図である。
図２１のようにサービスを提供していたコンポーネントを持つデバイスがアドホックネットワークから分離するとき、そのサービスを代替できるコンポーネントがアドホックネットワーク内に存在すれば、そのデバイスが持っていたコンポーネントは、ステータスというオブジェクトを、代替するコンポーネントに渡す。ステータスとは、そのサービスを遂行するために必要な情報を持つオブジェクトのことである。そうすることで、代替コンポーネントを使用したサービスの継続が可能となる。
そのような代替コンポーネントが存在しない場合には、コンポーネントは分離することをＩｎｉｔｉａｔｏｒに通知することによって、ユーザに代替サービスを選択するように通知することができる。
ステータスをコンポーネント間で直接伝達することも可能であるが、アドホックネットワークでは分離するコンポーネントはそのような通知ができないことが多い。そこで、図２２のように各コンポーネントは定期的にＩｎｉｔｉａｔｏｒにステータスを渡す。そうすることで、分離するコンポーネントがそのステータスを他のコンポーネントに渡すことができない条件でも、Ｉｎｉｔｉａｔｏｒが代理としてステータスを渡すことで、サービスの復旧が可能になる。このときも、ユーザが代替サービスを選択するように通知することができる。
また、新しいデバイスが入ってきたときには、そのデバイスのコンポーネントはＩｎｉｔｉａｔｏｒに新しくアドホックネットワークに入ってきたことを通知する。Ｉｎｉｔｉａｔｏｒは、現在のサービスを継続したまま、グラフの再構成をする。もし、現在のデバイスよりも優先順位の高いサービスが提供できる場合には、ユーザにサービスの変更ができることを通知する。ユーザが新しいサービスを選択した場合には、そのサービスに切り替える。このとき、切り替えた先のコンポーネントが切り替える前のコンポーネントのステータスを受け取ることが可能ならば、図２３にように切替え前のコンポーネントは切替え後のコンポーネントにステータスを渡す。ユーザは新しいサービスが利用できる場合であっても、必ずしも新しいサービスを選択する必要はない。
図２４は、ステータスの受け渡し処理を説明する図である。
まず、Ｉｎｉｔｉａｔｏｒがステータスを受け取るコンポーネントにステータスを受け取るように指示を出す（１）。次に、ステータスを受け取るコンポーネントはステータスを受け入れるように待機する（２）。Ｉｎｉｔｉａｔｏｒがステータスを出すコンポーネントにステータスを受け取るコンポーネントのアドレスとともにステータスを出すように指示を出す（３）。ステータスを出すコンポーネントは、ステータスを受け取るコンポーネントのアドレスに対してステータスを送信する（４）。そして、ステータスを受け取るコンポーネントは、ステータスを受け取ると自分の状態をステータスに合わせて変更する（５）。
図２５は、ステータスの移動処理のフロー図である。
まず、ステップＳ２５において、ステータス移動の要求を受ける。ステップＳ２６においては、ステータス受け入れ通知を受け取ったか否かを判断する。ステップＳ２６の判断がＹＥＳの場合には、ステップＳ２９において、ステータスを受け入れる準備をする。そして、ステップＳ３０において、ステータスを受信して、コンポーネントの状態を変更する。ステップＳ２６の判断がＮＯの場合には、ステップＳ２７において、ステータスを送信する準備をする。そして、ステップＳ２８において、自分の状態をステータスとして表現し、新しいコンポーネントにステータスを送付する。
ステータスの情報としては、コンポーネントの種類によって異なるが、例えば、ＣＤプレーヤー等の音楽発信コンポーネントの場合、以下の情報を持つ。
・曲名（曲のＩＤ）
・経過時間
このようにアドホックネットワークのコンポーネント統合システムを用いることにより下記の利点が生じる。
・いつでもどこでも、同じサービスを利用したいという要求がある。例えば、どこでも音楽鑑賞をしたいと言うとき、在宅時には、ＣＤプレーヤーとスピーカを使用して音楽を聴き、外出時にはポータブルＭＤプレーヤーまたは携帯電話音楽配信システムとヘッドフォンを使用して聴くということが考えられる。本実施形態を利用すると、在宅時にはＣＤプレーヤーとスピーカとそれを操作するリモコンや携帯電話など（Ｉｎｉｔｉａｔｏｒ）がアドホックネットワークを構成し、サービスを提供し、外出するときにＣＤプレーヤーはＭＤプレーヤーまたは携帯電話音楽配信システムに曲名と経過時間と言ったステータスを渡し、スピーカはヘッドフォンに音量というステータスを渡すことで、継続した音楽鑑賞が可能となる。このときには、ＭＤプレーヤー、携帯電話音楽配信システム、ヘッドフォン、携帯電話などでアドホックネットワークを構成しており、その中で継続したサービスを提供することになる。
アドホックネットワークは、動的に構成されるネットワークであるため、有線・無線の区別無く適用できる。しかし、ここでは簡略化のためにアドホックネットワークを構成するデバイスは、基本的に無線通信機能を備えていると仮定する。無線通信機能を持たない場合は、別の無線通信機能を持ったデバイスに接続されており、無線通信機能を持たないデバイスへの指示は接続された無線通信機能を持ったデバイス経由で通知される。
Ｉｎｉｔｉａｔｏｒも情報管理できればよいと言う規定だけ備えていればよいが、ここでは、ユーザインターフェースを備えた携帯電話、ＰＤＡ、ノートＰＣなどがＩｎｉｔｉａｔｏｒになるとする。ユーザの操作を他のデバイスのコンポーネントに要求する機能、ユーザにイベントを知らせる機能が必要となる。
以下、携帯電話をＩｎｉｔｉａｔｏｒの代表として扱う。
Ｉｎｉｔｉａｔｏｒである携帯電話は、その近隣に存在するデバイスとＩＥＥＥ８０２．１１（無線ＬＡＮ）やＢｌｕｅｔｏｏｔｈといった無線リンクを通じてアドホックネットワークを構成する。アドホックネットワークを構成したデバイスとＩｎｉｔｉａｔｏｒは互いに情報交換が可能となる。
図２６は、Ｉｎｉｔｉａｔｏｒと各コンポーネントとの間の目録のやりとりを示すシーケンス図である。また、図２７は、Ｉｎｉｔｉａｔｏｒが目録を受け取ってから経路（パス）の決定及びサービスの実行を行う処理を示すフロー図である。
図２６のように、Ｉｎｉｔｉａｔｏｒは各デバイスに存在するコンポーネントに対して、「コンポーネントサービス要求」を送信する。「コンポーネントサービス要求」を受け取ったコンポーネントは自分の機能クラス、入出力データクラスを記述した「コンポーネントサービス応答」という「目録」をＩｎｉｔｉａｔｏｒに返す。アドホックネットワークを構成する全てのデバイスから、「コンポーネントサービス返答」を受け取ったＩｎｉｔｉａｔｏｒは、その目録に記された入出力データクラスを用いる。
そして、図２７のように、ステップＳ４０において、２つのコンポーネントに接続しているブランチを比較し、ステップＳ４１において、Ｉｎｉｔｉａｔｏｒ内では出力データクラスと入力データクラスの関係が図７のように一致すれば、サービスクラスのブランチを張る（ステップＳ４２）。なお、一致しない場合には、ブランチを張らずに、つぎのブランチを探す。そして、全てのコンポーネント間にブランチを張り終えると（ステップＳ４３）、この中でブランチを構成する入出力クラスのクラス階層の重み付けが大きいもの、パス長が短いものを持つグラフのパスの優先順位を高くすることで、ユーザにどのサービスが利用可能か優先順位を付けて示す（ステップＳ４４）。そして、ユーザが指定したサービスのパスを決定し（ステップＳ４５）、そのパス上に存在するコンポーネント全てに「コンポーネントサービス開始」を通知する（ステップＳ４６）。
図２８は、本実施形態の動作をより具体的に示した図である。
図２８のように「ＣＤプレーヤー」コンポーネントクラスが「ＰＣＭ音声」データ出力を行い、「スピーカ」コンポーネントクラスが「ＰＣＭ音声」データ入力を行うという情報が有れば、同じ「ＰＣＭ音声」データの入出力を持つ「ＣＤプレーヤー」コンポーネントと「スピーカ」コンポーネントをブランチでつないだサービスグラフを作成する。
このように、アドホックネットワーク内に存在する全てのコンポーネントをブランチで接続したサービスグラフを作成する。例えば、この場合「ＣＤプレーヤーが音楽を再生して、スピーカで音声出力をする」というサービスを構成できる。ユーザがサービスを選択すると、Ｉｎｉｔｉａｔｏｒは選択したパス上に存在するコンポーネントに「コンポーネントサービス開始」要求を出す。これによって、この例の場合は、「ＣＤプレーヤーが音楽を再生」し、「スピーカが音声出力」をする。
図２９〜図３１は、アドホックネットワークの構成が変更になった場合の動作を示す図である。
そして、アドホックネットワークの構成が変更になったときには、図２９のようにアドホックネットワークに結合または分離したコンポーネントがＩｎｉｔｉａｔｏｒに「コンポーネント加入通知」または「コンポーネント脱退通知」を送信することで、Ｉｎｉｔｉａｔｏｒはアドホックネットワークが変更になったことを知る。そして、その通知を受け取ったＩｎｉｔｉａｔｏｒはサービスが継続できるならば、今までサービスをしていたコンポーネントに「ステータス移動通知」を出す。それ以外にも、図３０のようにステータス情報を送信していたコンポーネントが一定時間ステータスを送信してこなければ、タイムアウトとみなして、そのコンポーネントはアドホックネットワーク外に出たと想定する。この場合も、サービスが継続できる場合には、Ｉｎｉｔｉａｔｏｒが新しいコンポーネントに「ステータス受け入れ通知」を出す。そして、Ｉｎｉｔｉａｔｏｒがステータスを新しいコンポーネントに渡す。サービスを提供していたパスのうち、新しくパスに入るコンポーネントには、「コンポーネントサービス開始」を出し、今までと同じコンポーネントには「経路変更通知」を出す。また、アドホックネットワークからデバイスが突然脱退することも考え得るため、コンポーネントは定期的にＩｎｉｔｉａｔｏｒにステータスを渡す。デバイスが突然脱退したときにサービスが継続可能なコンポーネントが存在すれば、Ｉｎｉｔｉａｔｏｒはそのコンポーネントに「ステータス受け入れ通知」を出して、ステータスを渡す。例えば、図３１のように「ＰＣＭ音声」データ出力を持つデバイスとして、「ＣＤプレーヤー」コンポーネントと「ポータブルＭＤプレーヤー」コンポーネントと「ＭＰ３−ＰＣＭ音声データ変換アダプタ」コンポーネントが存在し、「ＭＰ３音声」データ出力を持つ「携帯電話音楽配信サーバ」コンポーネントが存在する。そして、「ＰＣＭ音声」データ入力を持つデバイスとして「スピーカ」コンポーネントと「ヘッドフォン」コンポーネントが存在する場合を考える。優先順位の高かった「ＣＤプレーヤー」コンポーネントから「スピーカ」コンポーネントへのパスがなくなる場合を考える。例えば、在宅状態から外出状態に移行する場合である。この場合、「ＣＤプレーヤー」コンポーネントと「スピーカ」コンポーネントはアドホックネットワークから分離することになり、Ｉｎｉｔｉａｔｏｒは両方から「コンポーネント脱退通知」を受け取る。このとき、コンポーネントが同じクラスから派生している場合は、ステータス情報が移動できる。「ＣＤプレーヤー」コンポーネントから「携帯電話音楽配信サーバ」コンポーネントへ「曲情報（曲名、曲ＩＤなど）」と「経過時間」というステータス情報を送信することができる。
また、同様に「スピーカ」コンポーネントから「ヘッドフォン」コンポーネントへ「音量情報」というステータス情報を送信できる。これにより、図３１のように「ＣＤプレーヤー」→「スピーカ」というパスで構成されていたサービスが、「携帯電話音楽配信サーバ」→「ＭＰ３−ＰＣＭ音声データ変換アダプタ」→「ヘッドフォン」というパスで構成されたサービスへサービスを継続したまま移行できる。
図３２〜図４５は、図２８及び図３１の場合の具体的動作を説明する図である。
図３２に示すように、アドホックネットワークが、コンポーネントとしてのＣＤプレーヤー、ポータブルＭＤプレーヤー、携帯電話音楽配信サーバ、ＭＰ３−ＰＣＭ音声データ変換アダプタ、スピーカ、ヘッドフォンと、Ｉｎｉｔｉａｔｏｒからなるとする。
図３３に示すように、Ｉｎｉｔｉａｔｏｒは、最初サービスの提供を受ける前、各コンポーネントに目録を要求する。図３４〜図３９は、それぞれＣＤプレーヤー、ポータブルＭＤプレーヤー、携帯電話音楽配信サーバ、ＭＰ３−ＰＣＭ音声データ変換アダプタ、スピーカ、ヘッドフォンの目録の例である。
そして、Ｉｎｉｔｉａｔｏｒは、図４０のようなグラフを目録を基に作成する。ここで、例えば、ＣＤプレーヤーは入力クラスのないコンポーネントなので、そこから探索を開始する。次のＭＰ３−ＰＣＭ音声データ変換アダプタに対しては、例えば、ＣＤプレーヤーの出力クラスであるＰＣＭ音声のクラスにさかのぼっても、ＭＰ３音声のクラスに対応しないので、ＣＤプレーヤーからＭＰ３−ＰＣＭ音声データ変換アダプタには、ブランチを作成できない。次のスピーカは出力クラスのないコンポーネントなので、そこで完結し、１つのパスが生成できる。
ここで、各パスについて優先順位を決める。ここでは、前述の（１）式において、α＝１、β＝２とする。なお、クラス階層の深さは、図１０で示されている通りとする。
ＣＤプレーヤー→スピーカ
優先付け重み＝１×（１／３＋１／２）＋２×（１／２）＝１．８３
ＣＤプレーヤー→ヘッドフォン
優先付け重み＝１×（１／３＋１／２）＋２×（１／２）＝１．８３
ＭＤプレーヤー→スピーカ
優先付け重み＝１×（１／３＋１／２）＋２×（１／２）＝１．８３
ＭＤプレーヤー→ヘッドフォン
優先付け重み＝１×（１／３＋１／２）＋２×（１／２）＝１．８３
携帯電話音楽配信サービス→ＭＰ３−ＰＣＭ音声データ変換アダプタ→スピーカ
優先付け重み＝１×（１／３＋１／２＋１／２）＋２×（１／３＋１／２）＝３．００
携帯電話音楽配信サービス→ＭＰ３−ＰＣＭ音声データ変換アダプタ→ヘッドフォン
優先付け重み＝１×（１／３＋１／２＋１／２）＋２×（１／３＋１／２）＝３．００
となる。過去に選択したことのあるパス（ＣＤプレーヤー→スピーカ、携帯電話音楽配信サービス→ＭＰ３−ＰＣＭ音声データ変換アダプタ→ヘッドフォン）に関しては優先付けの重み付けを−１とすると、全部の優先付け重みは以下の用になる。
ＣＤプレーヤー→スピーカ
優先付け重み＝０．８３
ＣＤプレーヤー→ヘッドフォン
優先付け重み＝１．８３
ＭＤプレーヤー→スピーカ
優先付け重み＝１．８３
ＭＤプレーヤー→ヘッドフォン
優先付け重み＝１．８３
携帯電話音楽配信サービス→ＭＰ３−ＰＣＭ音声データ変換アダプタ→スピーカ
優先付け重み＝３．００
携帯電話音楽配信サービス→ＭＰ３−ＰＣＭ音声データ変換アダプタ→ヘッドフォン
優先付け重み＝２．００
優先付け重みの小さいものの優先順位を高くすると、図４１のようなサービス一覧が得られる。
図４１において、ユーザが＜０１＞ＣＤプレーヤ→スピーカを選択すると、Ｉｎｉｔｉａｔｏｒは、ＣＤプレーヤーとスピーカに「コンポーネントサービス開始」を通知することによって、サービスを開始させる。
図４２〜図４５は、図３１のステータス移動について説明する図である。
ここでは、ＣＤプレーヤー、ポータブルＭＤプレーヤー、スピーカがアドホックネットワークから脱退する情報を考える。
Ｉｎｉｔｉａｔｏｒは、ＣＤプレーヤー、ポータブルＭＤプレーヤー、スピーカからコンポーネント脱退通知を受け取る（図４２参照）。
このとき、Ｉｎｉｔｉａｔｏｒは、ＣＤプレーヤーとスピーカが現在サービスを提供しているパス上に存在することを知っているので、新しくパスを生成し直す必要がある。今度は、コンポーネントが３つしかないので、以前取得した目録から、クラス階層を比較して、携帯電話音楽配信サーバはＭＰ３音声により、ＭＰ３−ＰＣＭ音声データ変換アダプタにしかつなげず、ＭＰ３−ＰＣＭ音声データ変換アダプタはＰＣＭ音声によりヘッドフォンにしかつなげないことが分かる（図４３参照）。このとき、サービス一覧は図４４のようになる。
なお、ＣＤプレーヤーと同じクラスから派生している携帯電話音楽配信サーバへＣＤプレーヤーからステータス（曲情報、経過時間）を渡すことができる。同様に、スピーカと同じクラスから派生しているヘッドフォンへスピーカからステータス（音量）を渡すことができる。この手順はＩｎｉｔｉａｔｏｒが指定する（図４５参照）。
以上のように、本実施形態によれば、音楽演奏においては、図２８のように単体の機能を持ったコンポーネントを組み合わせることで１つのサービスを提供することを可能にする。また、図３１のようにステータス情報を移行させることで、サービスを連続的に利用できる。
図４６は、本実施形態をＰＩＭ情報管理システムに適用した例である。
近年、１つのデバイスが複数の機能を持つようになった。例えば、携帯電話、ＰＤＡ、ノートＰＣといったデバイスがＰＩＭ（Ｐｅｒｓｏｎａｌ Ｉｎｆｏｒｍａｔｉｏｎ Ｍａｎａｇｅｒ）といった住所録やスケジュール帳を持つようになった。しかし、これは重複した機能であり、互いに同期させる必要があった。そのため、手動で何度も書き換えたり、自動的に同期するための同期機構を複数持ったりする必要があった。本実施形態を使用すると、ＰＩＭのコンポーネントは１つでよくなり、ＰＩＭのコンポーネントを使用するコンポーネントは、ＰＩＭを読み書きするインターフェースを持つだけで良くなる。
ＰＩＭ情報を持つコンポーネントを１つ持っておくことにより、重複したデータ管理をしなくても済む。図４６のように、ＰＩＭ情報を扱うコンポーネントが複数存在していても、１つの「ＰＩＭ情報管理」コンポーネントがデータの一貫性を保持することができる。ＰＤＡの「電子メール」コンポーネントは宛て先を「ＰＩＭ情報管理」コンポーネントに問い合わせる。
また、携帯電話の「電話帳」コンポーネントは相手先電話番号を「ＰＩＭ情報管理」コンポーネントに問い合わせる。ノートＰＣの「スケジュール帳」コンポーネントは、スケジュール上誰かに会う必要がある時に、会う場所や会う人の情報を「位置情報変換アダプタ」や「人物情報変換アダプタ」を経由して、「ＰＩＭ情報管理」コンポーネントに問い合わせる。これにより、情報管理を一元化可能となり、従来の複数の情報を管理する煩雑さから解放される。
図４７は、本実施形態のＩｎｉｔｉａｔｏｒやコンポーネントを有するデバイスの機能をプログラムで実現しようとした場合に要求されるハードウェア環境を説明する図である。
バス１０に接続されたＣＰＵ１１は、ハードディスクなどの記憶装置１７あるいは、フロッピーディスク、ＣＤ−ＲＯＭ、ＤＶＤ、ＭＯなどからなる可搬記録媒体１９に格納された当該プログラムをバス１０を介して、（可搬記録媒体１９の場合には、読み取り装置１８とバス１０を介して）ＲＡＭ１３にコピーし、実行する。
ＲＯＭ１２は、ＢＩＯＳなどの基本プログラムが格納され、ＣＰＵ１１が、キーボード、マウス、テンプレート、ディスプレイなどからなる入出力装置２０からのユーザからの指示を入力可能にしたり、演算結果を出力可能とする。また、読み取り装置１８や、記憶装置１７などの制御も可能にする。また、当該プログラムをＲＯＭ１２に記憶して、図４７の情報装置を本実施形態のＩｎｉｔｉａｔｏｒやコンポーネントを有するデバイス専用機として使用しても良い。
通信インターフェース１４は、ネットワーク１５を介して、情報提供者１６と通信し、当該プログラムをダウンロードして、ＣＰＵ１１が実行可能な状態とする、あるいは、ネットワーク環境下で当該プログラムを実行することを可能とするものである。
産業上の利用可能性
本発明を利用すれば、重複した多数の機能を持ったデバイスを複数持つ必要がなくなり、単一の機能を持ったコンポーネントを組み合わせることで複雑なサービスを提供できる。また、ステータス情報を移動できるためユーザに対して連続したサービスを提供可能となる。
【図面の簡単な説明】
図１は、本実施形態のシステム構成の概念図である。
図２は、本実施形態のシステムを構成する端末の概念構成を示す図である。
図３は、アドホックネットワークの具体例を示した図（その１）である。
図４は、アドホックネットワークの具体例を示した図（その２）である。
図５は、Ｉｎｉｔｉａｔｏｒが使用可能なサービスを調べる様子を概念的に示した図である。
図６は、目録の収録情報を示す図である。
図７は、コンポーネント間の接続と、目録の記載内容との関係を説明する図である。
図８は、Ｉｎｉｔｉａｔｏｒが検出するコンポーネント間の接続関係を概念的に示すグラフを説明する図（その１）である。
図９は、Ｉｎｉｔｉａｔｏｒが検出するコンポーネント間の接続関係を概念的に示すグラフを説明する図（その２）である。
図１０は、Ｉｎｉｔｉａｔｏｒが行う、コンポーネントとコンポーネントとの間にブランチを形成する場合の処理を説明する図である。
図１１は、Ｉｎｉｔｉａｔｏｒによるグラフの作成フローチャートである。
図１２は、ブランチ作成の様子を図示した図（その１）である。
図１３は、ブランチ作成の様子を図示した図（その２）である。
図１４は、複数のパス（ブランチのつながりであり、図１３のスタック）が検出された場合に、優先順位を付けて、経路（パス）を選択する処理を説明する図である。
図１５は、サービス一覧の表示例である。
図１６は、サービス提供に当たってのコンポーネントの動作を概略説明する図である。
図１７は、前述のパスの検索処理に先立って、各コンポーネントからＩｎｉｔｉａｔｏｒが受け取る目録の例を示した図である。
図１８は、コンポーネントがＩｎｉｔｉａｔｏｒへ目録を送信する場合の処理フローを示す図である。
図１９は、サービス開始の処理を示すフロー図である。
図２０は、Ｉｎｉｔｉａｔｏｒが持つ、グラフのデータフォーマットの例を示す図である。
図２１は、コンポーネントがアドホックネットワークから分離・合流した場合の動作の概念を示す図（その１）である。
図２２は、コンポーネントがアドホックネットワークから分離・合流した場合の動作の概念を示す図（その２）である。
図２３は、コンポーネントがアドホックネットワークから分離・合流した場合の動作の概念を示す図（その３）である。
図２４は、ステータスの受け渡し処理を説明する図である。
図２５は、ステータスの移動処理のフロー図である。
図２６は、Ｉｎｉｔｉａｔｏｒと各コンポーネントとの間の目録のやりとりを示すシーケンス図である。
図２７は、Ｉｎｉｔｉａｔｏｒが目録を受け取ってから経路（パス）の決定及びサービスの実行を行う処理を示すフロー図である。
図２８は、本実施形態の動作をより具体的に示した図である。
図２９は、アドホックネットワークの構成が変更になった場合の動作を示す図（その１）である。
図３０は、アドホックネットワークの構成が変更になった場合の動作を示す図（その２）である。
図３１は、アドホックネットワークの構成が変更になった場合の動作を示す図（その３）である。
図３２は、図２８及び図３１の場合の具体的動作を説明する図（その１）である。
図３３は、図２８及び図３１の場合の具体的動作を説明する図（その２）である。
図３４は、図２８及び図３１の場合の具体的動作を説明する図（その３）である。
図３５は、図２８及び図３１の場合の具体的動作を説明する図（その４）である。
図３６は、図２８及び図３１の場合の具体的動作を説明する図（その５）である。
図３７は、図２８及び図３１の場合の具体的動作を説明する図（その６）である。
図３８は、図２８及び図３１の場合の具体的動作を説明する図（その７）である。
図３９は、図２８及び図３１の場合の具体的動作を説明する図（その８）である。
図４０は、図２８及び図３１の場合の具体的動作を説明する図（その９）である。
図４１は、図２８及び図３１の場合の具体的動作を説明する図（その１０）である。
図４２は、図２８及び図３１の場合の具体的動作を説明する図（その１１）である。
図４３は、図２８及び図３１の場合の具体的動作を説明する図（その１２）である。
図４４は、図２８及び図３１の場合の具体的動作を説明する図（その１３）である。
図４５は、図２８及び図３１の場合の具体的動作を説明する図（その１４）である。
図４６は、本実施形態をＰＩＭ情報管理システムに適用した例である。
図４７は、本実施形態のＩｎｉｔｉａｔｏｒやコンポーネントを有するデバイスの機能をプログラムで実現しようとした場合に要求されるハードウェア環境を説明する図である。

Claims (17)

1. 有線あるは無線でネットワークを構成する１以上のデバイスが提供する機能を統合して所定のサービスを受けるために使用される、該１以上のデバイスに有線あるいは無線で接続された情報端末であって、
   該１以上のデバイスが有する、所定の機能を実行するコンポーネントの提供可能サービスに関する情報を、各デバイスから受け取る情報収集手段と、
   該収集された情報から、該１以上のデバイスを組み合わせて受けることのできるサービスを検出するサービス検出手段と、
   該検出されたサービスに基づいて、該サービスの提供に含まれるデバイスにサービスの実行を指示するサービス指示手段と、
   を備えることを特徴とする情報端末。
2. 前記収集される情報は、各デバイスの機能を実現するコンポーネントの入出力仕様をクラスとして定義したものであることを特徴とする請求項１に記載の情報端末。
3. 前記サービス検出手段が検出した、提供可能なサービスに含まれるデバイス間を接続する複数の経路について、前記クラスの階層の深さに基づいて、優先順位を付けることを特徴とする請求項２に記載の情報端末。
4. 前記サービス検出手段が検出した、提供可能なサービスに含まれるデバイス間を接続する複数の経路について、過去に使用したサービスの経路の優先順位を高く設定することを特徴とする請求項２に記載の情報装置。
5. 前記ネットワークからデバイスが離脱する場合、該デバイスと同等の機能を提供可能な別のデバイスを代わりに用いて、サービスの提供を継続することを特徴とする請求項１に記載の情報装置。
6. 前記ネットワークにデバイスが合流する場合、該デバイスが提供可能なサービスを検出し、同等なサービスを提供可能なデバイスの組み合わせが複数有る場合には、１つを選択してサービスを提供することを特徴とする請求項１に記載の情報装置。
7. 前記デバイスの離脱、合流に際しては、現在提供しているサービスにおいて、該デバイスがサービスを継続するために必要な情報をステータス情報として該デバイスあるいは、該デバイスの代わりをするデバイスに通知することを特徴とする請求項５あるいは６に記載の情報装置。
8. 前記１以上のデバイスは、サービスの提供時において、前記情報装置に自身の動作状態を示すステータス情報を定期的に送信することを特徴とする請求項１に記載の情報装置。
9. 該ステータス情報は、前記ネットワークへデバイスが合流／離脱する場合にも、継続してサービスを提供可能とするための情報として使用されることを特徴とする請求項８に記載の情報装置。
10. 前記サービスは音楽再生サービスであることを特徴とする請求項１に記載の情報装置。
11. 前記デバイスには、ＰＩＭ等のアドレスやスケジュールデータを管理するデバイスが含まれ、前記サービスは、アドレスやスケジュールの管理を行うことを特徴とする請求項１に記載の情報装置。
12. 複数のデバイスがネットワークによって接続され、所定のサービスを提供するネットワークに使用されるデバイスであって、
    他のデバイスと通信する通信手段と、
    要求に応じて、自デバイスの機能を記述した目録を送信する手段と、
    指示に従って、所定の機能を提供する機能提供手段と、
    を備えることを特徴とするデバイス。
13. 前記機能提供手段は、データフォーマットの変換を行うことを特徴とする請求項１２に記載のデバイス。
14. サービスの提供中の自身の状態を他のデバイスに送信可能であることを特徴とする請求項１２に記載のデバイス。
15. 有線あるは無線でネットワークを構成する１以上のデバイスが提供する機能を統合して所定のサービスを受けるために行う処理方法であって、
    該１以上のデバイスが有する、所定の機能を実行するコンポーネントの提供可能サービスに関する情報を、各デバイスから受け取る情報収集ステップと、
    該収集された情報から、該１以上のデバイスを組み合わせて受けることのできるサービスを検出するサービス検出ステップと、
    該検出されたサービスに基づいて、該サービスの提供に含まれるデバイスにサービスの実行を指示するサービス指示ステップと、
    を備えることを特徴とする処理方法。
16. 有線あるは無線でネットワークを構成する１以上のデバイスが提供する機能を統合して所定のサービスを受けるために行う処理方法であって、
    該１以上のデバイスが有する、所定の機能を実行するコンポーネントの提供可能サービスに関する情報を、各デバイスから受け取る情報収集ステップと、
    該収集された情報から、該１以上のデバイスを組み合わせて受けることのできるサービスを検出するサービス検出ステップと、
    該検出されたサービスに基づいて、該サービスの提供に含まれるデバイスにサービスの実行を指示するサービス指示ステップと、
    を備えることを特徴とする処理方法を情報装置に実現させるプログラムを格納した、情報装置読み取り可能な記録媒体。
17. 有線あるは無線でネットワークを構成する１以上のデバイスが提供する機能を統合して所定のサービスを受けるために行う処理方法であって、
    該１以上のデバイスが有する、所定の機能を実行するコンポーネントの提供可能サービスに関する情報を、各デバイスから受け取る情報収集ステップと、
    該収集された情報から、該１以上のデバイスを組み合わせて受けることのできるサービスを検出するサービス検出ステップと、
    該検出されたサービスに基づいて、該サービスの提供に含まれるデバイスにサービスの実行を指示するサービス指示ステップと、
    を備えることを特徴とする処理方法を情報装置に実現させるプログラム。

Images