(57)【特許請求の範囲】
【請求項１】
少なくとも１つのノードが、分散ハッシュテーブル技術によりハッシュ空間上に割り当てられて構成されるオーバレイネットワークにおいて、前記オーバレイネットワーク上で共有される少なくとも１つのリソースを検索の対象とした検索サービスを提供する、検索サービス提供システムであって、
前記ノードは、
前記リソースを収集する情報収集部と、
前記情報収集部が収集したリソースを蓄積するリソースデータベースと、
前記オーバレイネットワーク上で共有されるリソースに関する検索要求を自ノード以外の他ノードから受け付けた場合に、前記リソースデータベースに蓄積されたリソースの内容を対象として検索を行い、前記検索の結果を前記検索要求元のノードに出力する検索サービス提供部とを備えた
検索サービス提供システム。
【請求項２】
請求項１記載の検索サービス提供システムにおいて、
前記検索サービス提供部は、前記自ノード以外の他のノードより、前記リソースを構成する特定の要素を用いた検索要求を受け付けた場合には、前記特定された要素を有するリソースを前記リソースデータベースから抽出して前記検索要求元ノードに出力する
検索サービス提供システム。
【請求項３】
請求項２記載の検索サービス提供システムにおいて、
前記検索サービス提供部は、前記自ノード以外の他のノードより、前記リソースを構成する特定の要素を用いた検索要求を受け付けた場合には、前記特定された要素を有するリソースのうち、前記特定された要素に対応する所定の箇所の情報のみを前記リソースデータベースより抽出して、前記検索要求元ノードに出力する
検索サービス提供システム。
【請求項４】
請求項３記載の検索サービス提供システムにおいて、
前記リソースを保有するノードは、前記リソースをハッシュ化したリソースキーと、前記リソースの種類を示すリソースタイプ情報とが記述されたリソーステーブルを有する
検索サービス提供システム。
【請求項５】
請求項４記載の検索サービス提供システムにおいて、
前記検索サービス提供部は、前記自ノード以外の他のノードより、前記リソースの種類を特定した検索要求を受け付けた場合には、前記リソーステーブルに記載されたリソースタイプの情報に基づいて、前記特定された種類のリソースを前記リソースデータベースより抽出して、前記検索要求元のノードに出力する
検索サービス提供システム。
【請求項６】
請求項３記載の検索サービス提供システムにおいて、
前記検索サービス、又はその他のサービスを提供するノードでは、前記サービス実体へのアクセス方法及び前記サービスの名称を記載したサービスプロファイルを生成する
検索サービス提供システム。
【請求項７】
請求項６記載の検索サービス提供システムにおいて、
前記情報収集部は、前記サービスプロファイルを収集し、
前記検索サービス提供部は、前記オーバレイネットワーク上で提供されるサービスに関する検索要求を受け付けて、前記サービスに関する情報を前記検索要求元のノードに出力する
検索サービス提供システム。
【請求項８】
少なくとも１つのノードが、分散ハッシュテーブル技術によりハッシュ空間上に割り当てられて構成されるオーバレイネットワークにおいて、前記オーバレイネットワーク上で共有される少なくとも１つのリソースを検索の対象とした検索サービスを提供する、検索サービス提供方法であって、
前記リソースを収集するステップと、
前記リソースを収集するステップで収集したリソースを蓄積するステップと、
前記オーバレイネットワーク上で共有されるリソースに関する検索要求を自ノード以外の他ノードから受け付けた場合に、前記蓄積されたリソースの内容を対象として検索を行い、前記検索の結果を前記検索要求元のノードに出力するステップとを有する
検索サービス提供方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、検索サービス提供システム及び検索サービス提供方法に関し、特に、オーバレイネットワーク上で構築される検索サービス提供システム及び、その提供方法に関する。
【背景技術】
【０００２】
近年、クライアント・サーバ型の接続形態に代わって、ネットワークに接続されたすべてのノード（ピアノード）が互いにアクセス可能となる、ピア・ツー・ピア（以降Ｐ２Ｐと称する）と呼ばれる接続形態が注目を集めている。クライアント・サーバ型のシステムにおいて、サーバが一括して保有していた文書ファイルや電話帳リスト等のリソースは、Ｐ２Ｐを用いたシステムにおいては各ノードに分散して保存される。従って、リソースの保存場所の情報も、各ノード同士が互いに協力して伝送し合う仕組みとなっている。
【０００３】
リソースの保存場所の検索技術としては、例えば分散ハッシュテーブル（以下、ＤＨＴ:Distributed Hash Tableと称する）が知られている。ＤＨＴでは、ノードのＩＤやネットワーク上に保存されるデータ（リソース）は、それらをハッシュ化して得られるハッシュ値で管理される。ハッシュ値は、ハッシュ関数をかける元のデータが同じで、使用するハッシュ関数が同じであれば、常に同一の値になり、元のデータが少しでも異なれば、全く違う値となる。このためＤＨＴでは、データを一意に識別するための識別子として、ハッシュ値を使用している。
【０００４】
ＤＨＴにおいて、リソースがネットワーク上に保存されるときには、まずリソースのハッシュ値が計算される。そして、算出されたハッシュ値と一番近いハッシュ値を持つノードに、リソースから生成されたハッシュ値と、リソースの実体（又はリソースがこのノードの記憶装置における保存場所（ローカルファイルパス）との組が、テーブル（ハッシュテーブル）として登録される。このため、保存するデータの内容が異なれば、データが保存される場所もネットワーク上に分散されるようになる。
【０００５】
リソースの検索を行う場合には、検索したいリソースのハッシュ値を算出して、そのハッシュ値をキーに検索を行う。ＤＨＴにおいては、ネットワークを構成するすべてのノードが、近傍のノードへのルートが記されたルーティングテーブルを予め備えており、ルーティングテーブルに基づいて検索が実施される。
【０００６】
ネットワーク上のいずれかのノードに登録されたリソースを検索したい場合は、まずそのリソースのハッシュ値を求め、自ノード内のルーティングテーブルの中で、リソースのハッシュ値と最も近いハッシュ値を持つノードに対して、検索要求を投げかける。検索要求を受け取ったノードが当該リソースを所持していない場合は、今度は検索要求を受け取ったノードが、自ノード内のルーティングテーブルの中における、リソースのハッシュ値と最も近いハッシュ値を持つノードに対して、検索要求を投げかける。
【０００７】
このような動作が繰り返されることにより検索範囲が縮まっていき、最終的に、取得したいリソースの保存場所にたどり着くことが可能となる。検索したいリソースの保存場所情報が分かれば、その情報を基に実際のリソースを取得することができる。つまり、ＤＨＴの技術を利用して構築されたオーバレイネットワーク上では、リソースの実体がどこにあるかを意識することなく、リソース実体にアクセスすることが可能となる。
【０００８】
特許文献１には、分散ハッシュテーブル技術を利用して構築されたオーバレイネットワークについて記載されている。
【特許文献１】特開２００７−５３６６２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
ところで、ＤＨＴ技術を用いて構築されたオーバレイネットワークにおいて、あるリソースを検索する場合には、上述したように、そのリソースをハッシュ化して得られるハッシュ値をキーに検索が行われる。
【００１０】
図１３には、ＤＨＴ技術を用いて構築されたオーバレイネットワークの例を示してある。図１３に示したオーバレイネットワークは、ノードＮ１１〜Ｎ１６の６つのノードで構成されており、オーバレイネットワーク上には、リソースとして文書ファイルが保管されているものとする。
【００１１】
例えば、ノードＮ１４のユーザが、「ＲＮ１」というファイル名の文書ファイルＳ１をオーバレイネットワーク上に保存する場合は、まず「ＲＮ１」をハッシュ化してハッシュ値を求める処理が行われる。そして次に、求められたハッシュ値「ＲＫ１」と近いハッシュ値を有するノードに、文書ファイルＳ１が保存される。図１３では、「ＲＮ１」のハッシュ値である「ＲＫ１」と一番近いハッシュ値を持つノードは、ノードＮ１１であると想定している。従って、「ＲＮ１」というファイル名を持つ文書ファイルＳ１は、ノードＮ１１に保存される。
【００１２】
このようにして保存された文書ファイルＳ１を、ファイルの保存場所を知らないノードＮ１３のユーザが検索する場合は、まず、文書ファイルＳ１のファイル名「ＲＮ１」のハッシュ値を算出する処理が行われる。「ＲＮ１」のハッシュ値は「ＲＫ１」であるため、次に「ＲＫ１」と一番近いハッシュ値を持つノードＮ１１に対して、文書ファイルＳ１の取得要求が伝送される。そして、ノードＮ１１からノードＮ１３に対して、文書ファイルＳ１が送信される。
【００１３】
ところが、このような仕組みでは、検索したいリソース（図１３においては文書ファイル）の名前を事前に把握していないと、リソースの保存先を探すことができない。また、ファイル名の一部だけが分かっていたとしても、リソースの保存先を探すためのキーであるハッシュ値「ＲＫ１」を導き出すことができないため、そのような情報を把握していてもリソースを取得することはできない。
【００１４】
つまり、ＤＨＴで構築されたオーバレイネットワークにおいては、ハッシュ値が生成される元のリソースの値（図１３においては、文書ファイルのファイル名）の一部や、リソース自体に含まれるキーワードなどを用いた“部分一致検索”を行うことができない、という問題があった。
【００１５】
本発明はかかる点に鑑みてなされたものであり、ＤＨＴで構築されたオーバレイネットワークにおける、部分一致検索を実現することを目的とする。
【課題を解決するための手段】
【００１６】
本発明は、少なくとも１つのノードが、分散ハッシュテーブル技術によりハッシュ空間上に割り当てられて構成されるオーバレイネットワークにおいて、オーバレイネットワーク上で共有される少なくとも１つのリソースを検索の対象とした検索サービスを提供する、検索サービス提供システムであって、ノードにおいて、リソースを収集する情報収集部と、情報収集部が収集したリソースを蓄積するリソースデータベースとを備えた。また、オーバレイネットワーク上で共有されるリソースに関する検索要求を自ノード以外の他ノードから受け付けた場合に、リソースデータベースに蓄積されたリソースの内容を対象として検索を行い、検索の結果を検索要求元のノードに出力する検索サービス提供部とを備えるようにしたものである。
【００１７】
このようにしたことで、リソースデータベースに蓄積されたリソースの情報を用いて、検索サービス提供部によって、検索要求と合致するリソースが抽出されるようになる。
【発明の効果】
【００１８】
本発明によると、リソースデータベースに蓄積されたリソースの情報を用いて、検索サービス提供部によって、検索要求と合致するリソースが抽出されるため、リソースの名称の一部やリソースを構成するデータの一部分等を用いた部分一致検索が行えるようになる。
【発明を実施するための最良の形態】
【００１９】
以下、本発明の一実施の形態を、添付図面を参照して説明する。本実施の形態では、本発明の検索サービス提供システムを、複数台の情報端末より構成されるオーバレイネットワークに適用してある。オーバレイネットワークは、本例においては、ピアノードのみで構成されるピュアＰ２Ｐ（Peer To Peer）の形態で構築している。
【００２０】
オーバレイネットワークの構築にはＤＨＴを用いてあり、そのアルゴリズムとしてはＣｈｏｒｄを使用している。なお、ＤＨＴのアルゴリズムはＣｈｏｒｄに限定されるものではなく、ＣＡＮやＰａｓｔｒｙ、Ｔａｐｅｓｔｒｙ等の他のアルゴリズムを用いるようにしてもよい。
【００２１】
検索サービス提供システムで提供するサービスとしては、本例では電話帳検索サービスを例に挙げている。そして電話帳検索サービスを、オーバレイネットワーク上で提供されるグローバルサービス（以下、単にサービスとも称する）の１つと位置づけている。グローバルサービスとは、オーバレイネットワークを構成するすべてのノードにおいて利用可能なサービスであり、オーバレイネットワークが存在する間は、常に利用可能であることが求められるサービスである。
【００２２】
グローバルサービスにアクセスするために必要な情報は、各ノードにおいて、グローバルサービステーブルと呼ばれるテーブルに記述されており、各ノードでは、グローバルサービステーブルに記述された情報を基に、所望のグローバルサービスにアクセスし、グローバルサービスを利用する。グローバルサービス及びグローバルサービステーブルの詳細については後述する。
【００２３】
図１は、検索サービス提供システムの構成例を示したものであり、情報端末としての複数台のＰＣ（Personal Computer）１００が、ネットワーク１を介して互いに接続された様子が示されている。図１に示された各ＰＣ１００は、オーバレイネットワークを構成するノードでもある。このため、図１では、ネットワーク１に接続された６台のＰＣ１００を、それぞれノードＮ１〜Ｎ６とも表示してある。以降の説明においても、ＰＣ１００のノードとしての機能を説明する際には、ＰＣ１００をノードＮｎ（ｎは整数）と称する。図１において、ノードＮ４は、検索サービスを提供する側のノードであり、ノードＮ１〜Ｎ３、Ｎ５〜Ｎ６は、検索サービスを利用する側のノードである。
【００２４】
図１において、各ＰＣ１００は、通信Ｉ／Ｆ部１０、操作部１１、表示部１２、制御部１３、メモリ１４、記憶部１５とを有する。
【００２５】
通信Ｉ／Ｆ部１０は、ネットワーク１とのインターフェース部分であり、ネットワーク１上の他のＰＣ１００とのデータのやりとりを制御する。操作部１１はキーボードやマウス等で構成され、ユーザからの操作入力を受け付けて、操作入力内容に応じた操作信号を制御部１３に出力する。例えばユーザによって検索サービスが利用されている時には、操作部１１は、ユーザにより入力された検索用のキーワード等を制御部１３に出力する。
【００２６】
表示部１２は、ＬＣＤ（Liquid Crystal Display）等で構成されるディスプレイであり、検索サービスにおいて使用されるＧＵＩ（Graphical User Interface）等が表示される。制御部１３は、ＣＰＵ（Central Processing Unit）等で構成され、ＰＣ１００の各部の制御を行う。制御部１３には、ＲＯＭ（Read Only Memory）やＲＡＭ（Random Access Memory）等で構成されたメモリ１４を接続してあり、メモリ１４に、制御に必要なプログラム等を記憶させてある。制御部１３は、メモリ１４に記憶されたプログラムを読み出して実行する。
【００２７】
記憶部１５は、メモリカードやハードディスク等で構成され、ＰＣ１００のユーザが使用する電話帳データＰ１（以下、単に電話帳Ｐ１とも称する）と、ＤＨＴネットワーク上で保存されたリソースのうち、このノードに保存された分のリソースに関する情報（リソース名、リソースキー、リソース実体、リソースタイプなど）を示したリソーステーブルＴ３等が記憶される。リソーステーブルＴ３の構成の詳細については後述する。また、記憶部１５には、予めルーティングテーブルＴ１と、グローバルサービステーブルＴ２とを記憶させてある。
【００２８】
ルーティングテーブルＴ１とは、近傍のノードへのアクセスルートが記されたテーブルであり、例えばｍ行で構成される。ｍ行のテーブルのうちのｉ行目には、自ノードから時計回りの方向に２＾（ｉ−１）番目に位置するノードの情報が記載される。
【００２９】
例えばルーティングテーブルＴ１の１行目には、自ノードから“２＾（１−１）＝１”番目、つまり、時計回りの方向で１番目に位置する（隣接する）ノードの情報が記載される。すなわち、オーバレイネットワークを構成するすべてのノードにおいて、少なくとも自ノードの右隣のノードの情報は、把握されていることになる。ｍを例えば４に設定した場合には、ルーティングテーブルＴ１の中には、自ノードから１、２、４、８個先の４つのノードの情報が記載される。
【００３０】
各ノードが、このようなルーティングテーブルＴ１を所有していることで、例えばそれぞれのノードにおいては自分の１，２，４，８先のノードの情報しか保持していなくても、各ノードのルーティングテーブルＴ１の情報を基に、検索要求がノード間を次々と転送される。これにより検索範囲が徐々に絞られていき、最終的には目的とするデータにたどり着くことができる。
【００３１】
グローバルサービステーブルＴ２とは、オーバレイネットワーク上で提供されるすべてのグローバルサービスに関する情報を記述したテーブルである。
【００３２】
図１に示したノードＮ４は検索サービスを提供するノードであり、ノードＮ４においては、上述した各部に加えて、各ＰＣ１００が保持している電話帳データＰ１を取得する情報収集部１６と、情報収集部１６が収集した電話帳データＰ１を用いて、電話帳データベースＤ１を構築又は更新するデータベース更新処理部１７（以下、ＤＢ更新処理部１７と称する）と、検索サービス利用ノードに対して検索サービス用のインターフェースを提供する検索サービス提供部１８とを備える。
【００３３】
リソースデータベースとしての電話帳データベースＤ１（以下、電話帳ＤＢＤ１とも称する）は、ローカルファイルとして記憶部１５に記憶される他、後述するサービス記録データファイルとして、オーバレイネットワーク上にも保存される。
【００３４】
次に、本例の検索サービス提供システム実現の前提となる、グローバルサービスの詳細ついて説明する。まずは図２を参照してグローバルサービステーブルＴ２の構成について説明し、次に図３と図４を参照して、グローバルサービス提供時の処理フローとグローバルサービス利用時の処理フローについて説明する。その後に、本例の検索サービス提供システムについての説明を行う。
【００３５】
本発明では、グローバルサービスを、以下の４つの要素を備えるものとして定義している。
・サービス名
・サービス実体
・サービスプロファイル
・サービス記録データファイル
サービス名とは、オーバレイネットワーク上で提供されるサービスの名前であり、所定のネーミングスキームに基づいて、ＵＲＩ（Uniform Resource Identifier）等で表現してある。例えば、本例における電話帳検索サービスであればurn:abcdabcd:dht:product:service:global:search_service、のように表現される。
【００３６】
サービス実体は、実行可能なプログラムのことであり、サービスの開始又は停止を動的に設定可能な状態としてある。
【００３７】
サービスプロファイルとは、サービスにアクセスするためのエンドポイント情報（ＩＰアドレスやＵＲＬ等）や、ＡＰＩ（Application Programming Interface）が記述された、ファイル形式のコンテンツである。各ノードが自分の環境に合わせてコンフィギュレーション可能なファイルであり、各ノードによって中身が異なる。
【００３８】
例えば、サービスプロファイルのフォーマットが、Service-EndPoint=http://host[:port]/path/serviceのようなものである場合は、同じ電話帳検索サービスに対するサービスプロファイルであったとしても、ＩＰアドレスが192.168.0.1のノードＮ１においては http://192.168.0.1/cgi-bin/service1.cgi、ＩＰアドレスが192.168.1.1のノードＮ２においては、http://192.168.1.1:8080/service/service1.cgiのように、それぞれ異なる記述となる。サービスプロファイル及びサービス実体は、各ノードの記憶部１５（図１参照）に格納される。
【００３９】
サービス記録データファイルとは、サービスの実施に伴って生じる、記録・保存すべきデータが記述されるファイルである。本例においては、電話帳ＤＢＤ１がこれに該当する。サービス記録データファイルは、サービス実体によって動的に生成（export）又は取り込み（import）されるものである。
【００４０】
図２には、グローバルサービステーブルＴ２の構成例を示してある。グローバルサービステーブルＴ２は、インデックス、サービス名、サービスキー、サービスプロファイル名、サービスプロファイルキー、サービスプロファイル、サービス実体、サービス記録データファイル名、サービス記録データファイルキー、サービス記録データファイルで構成される。
【００４１】
インデックスとは、グローバルサービステーブルの行方向の項目数に対応して付与されるものであり、１〜ｎの数値が入る。グローバルサービステーブルの行方向の項目数は、グローバルサービスの数に応じて増減する。サービス名については、上述したとおりであるため説明を省略する。サービスキーとは、サービス名をハッシュ化して得られるハッシュ値であり、hash(サービス名)で求められる。図２においては、サービス名は“urn:abcd:dht:service:global:search_service”であるため、サービスキーは“hash(urn:abcd:dht:service:global:search_service)となる。
【００４２】
サービスプロファイル名は、サービス名と同名としてある。サービスプロファイルキーは、サービスプロファイル名をハッシュ化して得られるハッシュ値であるが、サービスプロファイル名とサービス名を同名としてあるため、サービスプロファイルキーとサービスキーとは同じ値となる。
【００４３】
サービスプロファイルには、上述したサービスプロファイルの実体へのパスが記載される。サービスプロファイルは記憶部１５（図１参照）に記憶させてあるため、記憶部１５におけるパスが記される。図２に示した例では“/dht/service_profile/service_profile1.xml”のように記述してある。サービス実体にも、上述したサービス実体へのパスが記載される。図２に示した例では、“www/cgi-bin/service1.cgi”のように記述してある。
【００４４】
サービス記録データファイル名は、上述したサービス記録データファイルの名前であり、サービス名と同様に、ＵＲＩ等の文字列で構成される。図２に示した例では、“urn:abcd:dht:service:global:servicedata1”と記述してある。サービス記録データファイルキーは、サービス記録データファイル名をハッシュ化したハッシュ値であるため、hash(urn:abcd:dht:service:global:servicedata1)となる。サービス記録データファイルには、サービス記録データファイルの実体へのパスが記載されている。
【００４５】
なお、サービスキー、サービスプロファイルキー、サービス記録データファイルキーは、サービス名、サービスプロファイル名、サービス記録データファイル名を基に算出が可能であるため、予めグローバルサービステーブル上に項目として備えておかずに、都度計算して求めるような構成としてもよい。
【００４６】
オーバレイネットワークを構成するすべてのノードＮ１〜Ｎ６は、皆等しく同じグローバルサービステーブルＴ２を保持しているが、サービスの提供は、特定のノードにのみ行わせるようにしてある。特定のノードとは、ノードＩＤと、サービスキーとの距離が一番近いノードのことであり、本例では、そのノードをサービスの提供者としている。図１においてはノードＮ４が該当する。そしてサービス提供者は、以下の条件を満たしているものとする。
・サービス実体を持っており、それを実行している
・サービスプロファイルの提供する
・サービス記録データファイルに必要なデータを作成・更新し、最新のものをオーバレイネットワーク上にアップロードする
【００４７】
つまり、オーバレイネットワーク上のすべてのノードがサービス実体を備えているが、それを実行するのはサービス提供者となったノードのみとなる。このため、実行中のサービスへのアクセス方法を記したサービスプロファイルとしては、サービス提供者の保持するサービスプロファイルのみが有効となる。
【００４８】
図３は、サービス提供者に割り当てられたノードが行う、サービス提供処理の例を示したフローチャートである。サービス提供者に割り当てられたノードは、まず自ノード内でサービスプロファイルを用意し（ステップＳ１）、記憶部１５に記憶されたサービス実体（プログラム）を起動してサービスの提供を開始する（ステップＳ２）。そして、自ノード内でサービス記録データファイルを生成する（ステップＳ３）。サービス記録データファイルを生成した後は、サービス記録データファイルをアップロードする対象ノードを割り出し、それらのノードに、サービス記録データファイルを保存する（ステップＳ４）。なお、サービス記録データファイルのアップロードは、アップロード対象ノードだけでなく、その近傍のノードに対しても同時に行うようにしてもよい。
【００４９】
ステップＳ４のアップロード対象ノードの割り出し及び対象ノードへのファイルの保存は、例えばput(key, content)の式を用いて行う。つまり、put(サービス記録データファイルキー，サービス記録データファイル)の式を実行することにより、サービス記録データファイルキーにマッピングされるノードが割り出され、対象のノードにサービス記録データファイルが保存される。
【００５０】
サービス記録データファイルを保存した後は、自ノード内のサービス記録データファイルが更新されたか否かの判断を行う（ステップＳ５）。更新が行われない場合は何も処理を行わず、更新が行われた場合にはステップＳ４に戻って、更新したファイルをアップデート対象ノードに保存する。なお、自ノード内のサービス記録データファイルを、アップデート対象ノードに保存する処理は、自ノード内のサービス記録データファイルが更新されるたびに行うものとする。
【００５１】
サービス名とサービス記録データファイル名とでは異なる名前を付与してあり、異なる名前（データ）から生成されたハッシュ値は必ず異なる値となるため、このような処理を行うことで、サービスの提供者ノードとサービス記録データファイルの保存先ノードが、オーバレイネットワーク上に分散して保管されるようになる。
【００５２】
次に、サービスを利用する側のノードにおいて行う処理の例について、図４のフローチャートを参照して説明する。サービスを利用したいノードでは、まず、自ノードのグローバルサービステーブルＴ２に記載されたサービスプロファイルキーを用いて、サービス提供者ノードを検索する（ステップＳ１１）。サービス提供者ノードの検索は、例えばNode=lookup(key)の式を用いて行う。keyの部分にサービスプロファイルキーを代入することにより、サービスプロファイルキーにマッピングされたノードを求めることができる。
【００５３】
サービス提供者ノードを割り出せた後は、自ノードのルーティングテーブルＴ１を基にサービス提供者ノードにアクセスし、サービス提供者ノードの所有するサービスプロファイルを入手する（ステップＳ１２）。そしてサービスプロファイルを解析し（ステップＳ１３）、サービスプロファイルに記述された方法でサービスにアクセスして、サービスを利用する（ステップＳ１４）。
【００５４】
次に、本実施の形態による、部分一致検索が可能な検索サービス提供システムの具体的構成及び処理の例について説明する。
【００５５】
図５は、図１に示したノードＮ１〜Ｎ６が、ハッシュ空間上に配置された状態を示したものである。本例ではＣｈｏｒｄアルゴリズムを用いた場合を例に挙げているため、ハッシュ空間を円状で表現してあり、各ノードＮ１〜Ｎ６を、時計回りの方向に進むにつれてノードＩＤが大きくなるように配置してある。
【００５６】
図５において、ノードＮ２にはユーザＵ１としてＢｏｂがログインしており、ノードＮ４にはユーザＵ２としてＡｌｉｃｅがログインしており、ノードＮ５にはユーザＵ３としてＡｂｅがログインしている様子が示されている。それぞれのノードにおいては、電話帳Ｐ１とリソーステーブルＴ３とが記憶部１５（図１参照）等に記憶されており、電話帳Ｐ１は、オーバレイネットワーク上にも保管されている。
【００５７】
具体的には、Ｂｏｂ（ユーザＵ１）の電話帳Ｐ１ａはノードＮ４に保管され、Ａｌｉｃｅ（ユーザＵ２）の電話帳Ｐ１ｂはノードＮ１に保管され、Ａｂｅ（ユーザＵ３）の電話帳Ｐ１ｃはノードＮ６に保管されている。電話帳Ｐ１は、例えば図６（ａ）〜（ｃ）に示したようなリストとして構成されているものとする。図６（ａ）はＡｌｉｃｅの電話帳Ｐ１ａの例を示したものであり、図６（ｂ）はＢｏｂの電話帳Ｐ１ｂ、図６（ｃ）はＡｂｅの電話帳Ｐ１ｃの例を示したものである。
【００５８】
図６（ａ）〜（ｃ）において、各電話帳Ｐ１ａ〜Ｐ１ｃは、「名前」と「電話番号」と「所在地」の項目で構成される。「名前」の欄には、“Ａｌｉｃｅ”や“Ｔａｎａｋａ”等のユーザ名が記載され、「電話番号」の欄には電話番号が記載され、「所在地」の欄には、電話帳に記載された各ユーザが所在する都市の名称が、“Ｋａｎａｇａｗａ”や“Ｔｏｋｙｏ”のように記載されている。各電話帳Ｐ１ａ〜Ｐ１ｃの先頭行には、自分自身の電話番号と所在地の情報が記載されるものとする。
【００５９】
図６（ａ）に示したＡｌｉｃｅの電話帳Ｐ１ａには、Ａｌｉｃｅ自身の電話番号及び所在地情報の他に、東京（“Ｔｏｋｙｏ”）に所在するＴａｎａｋａの電話番号と、北京（“Ｂｅｉｊｉｎｇ”）に所在するＷａｎｇの電話番号とが記載されている。Ａｌｉｃｅの電話帳Ｐ１ａに記載されている他のユーザの情報は、図６（ａ）においては図示を省略している。以下、図６（ｂ）と図６（ｃ）においても、電話帳Ｐ１に記録された情報のうち、一部のユーザの情報のみを図示してある。
【００６０】
図６（ｂ）に示したＢｏｂの電話帳Ｐ１ａには、Ｂｏｂ自身の電話番号及び所在地情報の他に、東京に所在するＳｕｚｕｋｉの電話番号が記載されている。また図６（ｃ）に示したＡｂｅの電話帳Ｐ１ｃには、Ａｂｅ自身の電話番号及び所在地情報の他に、神奈川に所在するＡｌｉｃｅの電話番号と、ニューヨーク（“Ｎｅｗｙｏｒｋ”）に所在するＣａｒｏｌの電話番号とが記載されている。
【００６１】
また、各電話帳Ｐ１ａ〜Ｐ１ｃには、電話帳を識別するためのリソース名が付与されている。図６（ａ）に示したＡｌｉｃｅの電話帳Ｐ１ａのリソース名は“urn:dht:abcd:addressbook:alice”であり、図６（ｂ）に示したＢｏｂの電話帳Ｐ１ｂのリソース名は“urn:dht:abcd:addressbook:bob”であり、図６（ｃ）に示したＡｂｅの電話帳Ｐ１ｃのリソース名は“urn:dht:abcd:addressbook:abe”である。
【００６２】
このように構成された電話帳Ｐ１がオーバレイネットワーク上にも保管されていることにより、ノードＮ１〜Ｎ６の各ユーザは、他のユーザが作成した電話帳の情報を取得することができる。例えばＢｏｂがＡｌｉｃｅの電話帳データＰ１ａを取得したい場合には、Ａｌｉｃｅの電話帳のリソース名をハッシュ化したリソースキー（＝hash（urn:dht:abcd:addressbook:alice））を算出し、リソースキーを用いて、dht_get（リソースキー）のコマンドを実行することにより、電話帳Ｐ１ａを取得できる。
【００６３】
ところが、この方法では、Ａｌｉｃｅの保有するリソースのリソース名、もしくはリソースキーを事前に把握しておかなければならず、それらを把握していない場合には、所望の電話帳データを取得することができない。また、リソース名をハッシュ化したリソースキーを用いて電話帳の検索を行っているため、検索結果としてヒットした電話帳Ｐ１を丸ごと取得することはできても、電話帳Ｐ１に含まれるデータに対して、部分的な検索を行うことはできない。
【００６４】
例えば、“Ｔｏｋｙｏ”に所在しているユーザの電話番号、といった切り口での検索は行うことができない。また、“Ａ”で始まるユーザ（本例ではＡｌｉｃｅとＡｂｅが該当）が所有する電話帳Ｐ１を検索したい、といった要求にも応えることができない。
【００６５】
このため本例では、検索サービス提供ノードＮ４において、各ノードＮの電話帳データＰ１を取得して電話帳データベースＤ１を構築し、電話帳データベースＤ１の情報を用いて、各ノードに検索サービスを提供するようにしている。検索サービスを利用する各ノードＮにおいては、検索サービス提供ノードＮ４による電話帳データ取得要求に対応するためのインターフェースとして、電話帳Ｐ１のリソース名やリソースキー等を記したリソーステーブルＴ３を備えさせてある。
【００６６】
図７に、リソーステーブルＴ３の構成例を示してある。図７（ａ）はノードＮ１におけるリソーステーブルＴ３ａを、図７（ｂ）にはノードＮ４におけるＴ３ｂを、図７（ｃ）にはノードＮ６におけるＴ３ｃを示している。各リソーステーブルＴ３には、電話帳Ｄ１の情報だけでなく、オーバレイネットワーク上で共有されているすべてのリソースに関する情報が記載されているものとする。図７（ａ）〜図７（ｃ）に示した各リソーステーブルＴ３は、それぞれ「リソースキー」と「リソース名」と「リソース実体」と「リソースタイプ」の項目で構成される。
【００６７】
「リソース実体」の欄には、リソースが電話帳Ｐ１である場合には、電話帳Ｐ１の保存場所情報へのパスが記載される。具体的には、電話帳Ｐ１が保存されているノードの記憶装置へのパスが記載される。「リソースタイプ」の欄には、リソースがアプリケーションの場合には「電話帳」や「認証サービス」等のアプリケーションのタイプが記載され、静止画像や動画像等のデータである場合には、データの種類や拡張子がリソースタイプとして記載される。
【００６８】
図７（ａ）には、ノードＮ１で保有されているリソーステーブルＴ３ａの構成例を示してある。その最初の行には、リソースキーの欄に、Ａｌｉｃｅの電話帳Ｐ１ａのリソース名である“urn:dht:abcd:addressbook:alice”をハッシュ化した値が記載され、リソース名の欄にはリソース名が記載され、リソース実体の欄には、電話帳Ｐ１ａを閲覧するソフトの保存場所へのパスが“/resources/urn_dht_abcd_addressbook_alice.dat”のように記載され、リソースタイプの欄には、リソースが電話帳Ｐ１であることを示す“application/x-abcd-addressbook”の記載がされている。
【００６９】
その下の行（２行目）には、ノードＮ１に保存されている他のリソースの情報が記載されている。このリソースは仕様書であると想定しているため、「リソースキー」の欄には、リソース名“urn:dht:abcd:specification:chord”をハッシュ化したハッシュキーが、「リソース名」の欄にはリソース名が、「リソース実体」の欄にはリソース実体の保存場所情報（“/resources/urn_dht_abcd_specification_chord.pdf”）が、リソースタイプには、リソースが仕様書であり、その拡張子はｐｄｆであることを示す“application/pdf”が記載されている。
【００７０】
図７（ｂ）には、ノードＮ４で保有されているリソーステーブルＴ３ｂの構成例を示してある。リソーステーブルＴ３ｂには、１行目にＢｏｂの電話帳Ｐ１ｂの情報が記載され、２行目には、拡張子がｊｐｅｇである静止画像ファイルの情報が記載されている。
【００７１】
つまり、１行目には、「リソースキー」の欄に、Ｂｏｂの電話帳Ｐ１ｂのリソース名“urn:dht:abcd:addressbook:bob”をハッシュ化したハッシュキーが、「リソース名」の欄にはリソース名が、「リソース実体」の欄にはリソース実体の保存場所情報（“/resources/urn_dht_abcd_addressbook_bob.dat”）が、リソースタイプには、“application/x-abcd-addressbook”の記載がされている。２行目には、リソース名“urn:dht:abcd:photos:tokyo001”をハッシュ化したハッシュキーが、「リソース名」の欄にはリソース名が、「リソース実体」の欄にはリソース実体の保存場所情報（“/resources/urn_dht_abcd_photos_tokyo001.jpg”）が、リソースタイプには、“image/jpeg”の記載がされている。
【００７２】
図７（ｃ）には、ノードＮ６で保有されているリソーステーブルＴ３ａの構成例を示してある。リソースキーの欄には、Ａｂｅの電話帳Ｐ１ｃのリソース名である“urn:dht:abcd:addressbook:abe”をハッシュ化した値が記載され、リソース名の欄にはリソース名が記載され、リソース実体の欄には、リソース実体の保存場所情報（“/resources/urn_dht_abcd_addressbook_abe.dat”）が、リソースタイプの欄には、リソースが電話帳Ｐ１であることを示す“application/x-abcd-addressbook”の記載がされている。
【００７３】
検索サービス提供ノードＮ４では、このように構成されたリソーステーブルＴ３の情報を基に、各ノードＮに保存された電話帳Ｐ１を取得する。検索サービス提供ノードＮ４の検索サービス提供部１８では、このような処理に先立って、まず図３に示したサービス提供ノードにおけるフローを実施する。つまり、まず、検索サービスへアクセスするためのエンドポイント情報や、検索インターフェース（関数やパラメータ等）をサービスプロファイルに記述し（ステップＳ１）、次に検索サービスを開始する（ステップＳ２）。
【００７４】
そして、自ノード内で、サービス記録データファイルを生成する（ステップＳ３）。ここでサービス記録データファイルとして生成されるのは、電話帳ＤＢＤ１（図１参照）となる。サービス記録データファイルを、アップロード対象ノードにアップロードすると（ステップＳ４）、次に自ノード内のサービス記録ファイルの内容が更新されたか否かを判断する（ステップＳ５）。自ノード内のサービス記録ファイルの内容が更新されるのは、情報収集部１６によって情報が収集され、ＤＢ更新部１７によって電話帳ＤＢＤ１に書き込まれたタイミングとなる。
【００７５】
検索サービス提供部１８は、自ノード内のサービス記録ファイルの内容が更新されていない場合には、何も処理を行わず、更新されている場合には、ステップＳ４に戻って処理を行う。検索サービス提供部１８では、この他にも検索サービスを提供するための処理を行うが、この処理の内容については後述する。
【００７６】
次に、図８のフローチャートを参照して、検索サービス提供ノードＮ４の情報収集部１６（図１参照）の処理の例について説明する。
【００７７】
図８において、情報収集部１６はまず、前回情報収集時から所定の時間が経過したか否かの判断を行う（ステップＳ２１）。情報収集部１６による情報収集は、所定の時間おきに行うようにしてあるため、所定の時間が経過するまでの間は、ステップＳ２１の判断が繰り返される。前回情報収集時から所定の時間が経過していた場合には、情報収集先としての始点ノードを訪問する（ステップＳ２２）。
【００７８】
ここでいう始点ノードとは、自ノードのことである。従って情報収集部１６は、自ノードＮ４に対して情報の開示を要求する（ステップＳ２３）。この場合の開示要求は、どのような方法で行ってもよく、例えばＨＴＴＰ（HyperText Transfer Protocol）のＧＥＴメソッド等を使用するものとする。最初に開示を要求するのは、リソーステーブルＴ３の情報であり、情報収集部１６は、リソーステーブルＴ３に記載の情報を基に所望のリソース（本例においては電話帳Ｐ１）を取得する。
【００７９】
情報収集部１６は、例えばget_resource（リソースタイプ）のコマンドを用いて、電話帳Ｐ１を取得する（ステップＳ２４）。ノードＮ４のリソーステーブルＴ３ｂにおいては、図７（ｂ）に示されるように、電話帳のリソースタイプは“application/x-abcd-addressbook”と記載されている。このため情報収集部１６は、get_resource（application/x-abcd-addressbook）のコマンドを用いて、ノードＮ４における電話帳Ｐ１ｂを取得する。
【００８０】
次に、このようにして取得したリソース（電話帳Ｐ１）を、ＤＢ更新処理部１７に出力し（ステップＳ２５）、訪問先ノード（この場合は自ノード）の次のノードが、自ノードであるか否かの判断を行う（ステップＳ２６）。訪問先ノードの次のノードが自ノードであるか否かは、訪問先ノードが保持するルーティングテーブルＴ１を参照することで判断できる。
【００８１】
ルーティングテーブルＴ１の１行目に記述されているのは、ハッシュ空間上でそのノードと時計回りの方向において隣接するノードである。つまり、このノードが訪問先ノードを起点とした場合の「次ノード」となる。図５に示したオーバレイネットワークの構成例によれば、自ノードであるノードＮ４の次のノードは、左側に隣接するノードＮ５となり、ノードＮ４とは異なる。よって情報収集部１６は、次のノードであるノードＮ５を訪問する（ステップＳ２７）。そして、ステップＳ２３以降の処理を行う。
【００８２】
このような処理を繰り返し、自ノード以外のすべてのノードにおける電話帳Ｐ１を取得した段階においては、ステップＳ２６では、訪問先ノードの次のノードは自ノードであるという判断がされる。訪問先ノードの次のノードは自ノードであると判断した場合には、そこで処理は終了される。
【００８３】
情報収集部１６は、取得した電話帳Ｐ１をＤＢ更新処理部１７に出力する。ＤＢ更新処理部１７は、情報収集部１６から出力された電話帳Ｐ１を、電話帳ＤＢＤ１に書き込む処理を行う。図９に、電話帳ＤＢＤ１の構成例を示してある。図９に示した電話帳ＤＢＤ１は、「電話帳名」と「電話帳」の項目で構成され、「電話帳」の項目は、さらに「名前」、「電話番号」、「所在地」の項目で構成される。本例においては、各ノードＮで保持されていた電話帳Ｐ１のフォーマットをそのまま踏襲しているが、電話帳ＤＢＤ１に記録する項目を必要に応じて取捨選択するようにしてもよい。
【００８４】
「電話帳名」の欄には、各ノードＮにおける電話帳のリソース名が記載されており、図９においては、Ａｌｉｃｅの電話帳Ｐ１ａのリソース名である“urn:dht:abcd:addressbook:alice”と、Ｂｏｂの電話帳Ｐ１ｂのリソース名である“urn:dht:abcd:addressbook:bob”と、Ａｂｅの電話帳Ｐ１ｃのリソース名である“urn:dht:abcd:addressbook:abe”とが記載されている。
【００８５】
そして、「電話帳名」が“urn:dht:abcd:addressbook:alice”である場合の「電話帳」の項目には、Ａｌｉｃｅの電話帳Ｐ１ａに記載された、“Ａｌｉｃｅ”と“Ｔａｎａｋａ”と“Ｗａｎｇ”の電話番号情報及び所在地情報が記載されている。同様に、「電話帳名」が“urn:dht:abcd:addressbook:bob”である場合の「電話帳」の項目には、Ｂｏｂの電話帳Ｐ１ｂに記載された、“Ｂｏｂ”と“Ｓｕｚｕｋｉ”の電話番号情報及び所在地情報が記載され、「電話帳名」が“urn:dht:abcd:addressbook:abe”である場合の「電話帳」の項目には、Ａｂｅの電話帳Ｐ１ｃに記載された、“Ａｂｅ”と“Ａｌｉｃｅ”と“Ｃａｒｏｌ”の電話番号情報及び所在地情報が記載されている。
【００８６】
このようにして生成された電話帳ＤＢＤ１を用いて、検索サービス提供部１８は検索サービスの提供を行う。図１０のフローチャートに、検索サービス提供部１８の処理の例を示してある。
【００８７】
図１０において、検索サービス提供部１８はまず、検索サービスを利用する側のノードＮから、検索要求を受け付けたか否かの判断を行う（ステップＳ３１）。検索要求を受けていない間は何も処理を行わず、検索要求を受けた場合には、検索要求に応じて、検索要求中で指定されたキーワードやリソースのカテゴリ等をキーとして電話帳ＤＢＤ１の検索を行う。そして、該当するリストをから読み出す処理を行う（ステップＳ３２）。読み出したリストは、検索要求ノードに対して送信する（ステップＳ３３）。
【００８８】
図１１と図１２に、検索サービス提供部１８が検索結果として出力するリストの例を示してある。図１１には、「名前が“Ａ”で始まる人が所有する電話帳」という検索要求が来た場合の検索結果が示されている。検索対象のデータベースは、図９に示した電話帳ＤＢＤ１であるため、この中から、名前が“Ａ”で始まる“Ａｌｉｃｅ”と“Ａｂｅ”の電話帳が抽出される。従って、図１１に示したリストには、“Ａｌｉｃｅ”の電話帳の情報と、“Ａｂｅ”の電話帳の情報が記載されている。
【００８９】
つまり、「電話帳名」が“urn:dht:abcd:addressbook:alice”の情報としては、電話帳の所有者であるＡｌｉｃｅ自身の電話番号情報及び所在地情報とともに、東京に所在する“Ｔａｎａｋａ”の電話番号情報と、北京に所在する“Ｗａｎｇ”の電話番号情報とが記載されている。「電話帳名」が“urn:dht:abcd:addressbook:abe”の情報としては、電話帳Ｐ１ｃの所有者であるＡｂｅ自身の電話番号情報及び所在地情報とともに、神奈川に所在する“Ａｌｉｃｅ”の電話番号情報と、ニューヨークに所在する“Ｃａｒｏｌ”の電話番号情報とが記載されている。
【００９０】
図１２には、「所在地がＴｏｋｙｏである人の電話番号情報」という検索要求が来た場合の検索結果が示されている。従って、図１２に示したリストおいては、Ａｌｉｃｅの電話帳内に記録されている、東京に所在する“Ｔａｎａｋａ”の電話番号情報と、“Ｂｏｂ”の電話帳内に記録されている、東京に所在する“Ｂｏｂ”自身及び“Ｓｕｚｕｋｉ”の電話番号情報と、“Ａｂｅ”の電話帳内に記録されている、東京に所在する“Ａｂｅ”自身の電話番号情報とが抽出されている。
【００９１】
上述した実施の形態によれば、各ノードにおける電話帳Ｐ１の情報が蓄積された電話帳ＤＢＤ１に対して、検索要求が投げかけられるため、電話帳ＤＢＤ１に含まれる情報であれば、どんな要素でも検索キーワードになり得る。つまり、取得したいリソースのリソース名や、リソース名をハッシュ化したリソースキー等の情報を事前に把握していない場合でも、電話帳Ｐ１に含まれる情報のどれかを用いて、所望の電話帳Ｐ１を取得することができるようになる。すなわち、各ノードが所有する電話帳Ｐ１の全文検索を行うことができるようになる。
【００９２】
また、電話帳Ｐ１の所有者の名前や、電話帳Ｐ１に含まれる「所在地」の情報をキーとして検索を行うことができるため、検索要求に合致する情報のみを抽出することができる。すなわち、特定のノードに保管されているリソースを丸ごと取得するだけでなく、そのリソースを構成するデータのうち、ユーザが指定した要素を含むデータのみを抽出して、取得することができるようになる。
【００９３】
また、情報収集部１６によって、オーバレイネットワーク上の情報を定期的に収集しているため、その情報が蓄積された電話帳ＤＢＤ１の内容は、常に最新の内容となる。これにより、ユーザは最新の情報に対して検索を行うことができる。
【００９４】
また、上述した実施の形態では、検索サービスが取り扱うリソースの種類が、電話帳Ｐ１である場合例に挙げたが、検索サービスが扱うリソースはこれに限定されるものではなく、オーバレイネットワーク上で共有されているリソースであれば、どのようなリソースに適用してもよい。例えば、静止画像や動画像、文書ファイル等のファイル情報や、オーバレイネットワークを構成する各ノードのユーザや組織に関する情報等を、検索サービスの対象リソースとしてもよい。
【００９５】
この場合、ユーザによってリソースの種類を特定されると、リソーステーブルＴ３内の「リソースタイプ」の種類が絞り込まれ、ユーザによって指定された種類のリソース情報のみが抽出される。すなわち、ユーザは、オーバレイネットワーク上で共有されている様々なリソースのうち、特定のカテゴリに属するリソースのみを取得することができるようになる。
【００９６】
またこの場合、ユーザは、リソースのカテゴリを特に指定せず、単に取得したいリソースに関連する特定のキーワードを入力することで、オーバレイネットワーク上で共有されているすべてのリソースの情報を検索することができるようになる。
【００９７】
さらにこの場合、情報収集部１６が、各ノードＮが所有しているサービスプロファイルを収集して、サービスプロファイルのデータベースを生成すれば、ユーザに対して、オーバレイネットワーク上で提供されているサービスを検索可能なインターフェースを提供することができる。つまり、本例における検索サービスを用いて、Ｗｅｂサービス検索システムである、いわゆるＵＤＤＩ（Universal Description, Discovery and Integration）のようなシステムを実現することができる。
【００９８】
また、上述した実施の形態では、検索システムを、ピュアＰ２Ｐで構築されたオーバレイネットワークに適用した例を挙げたが、リソースの所在を一括管理するサーバを備えたハイブリッド型Ｐ２Ｐや、処理能力の高い特定のノードが自発的にリソースの所在を管理スーパーノード型Ｐ２Ｐの形態に適用してもよい。
【００９９】
スーパーノード型Ｐ２Ｐで構成されたオーバレイネットワークに適用した場合には、スーパーノードが２４時間３６５日稼働し続け、検索サービス等のグローバルサービスを提供するようになる。従って、情報収集部１６によって収集された情報が蓄積されるデータベースを、サービス記録データファイルとしてオーバレイネットワークに保管する必要がなくなる。つまり、リソースの情報が記録されたデータベースは、サービス提供ノードであるスーパーノードのみが保持していればよいことになる。
【０１００】
また、ここまで説明した実施の形態では、オーバレイネットワークを構成する各ノードがＰＣである場合を例に挙げたが、テレビ会議システムで使用される端末や、携帯型の情報端末等、他の装置に適用してもよい。
【図面の簡単な説明】
【０１０１】
【図１】本発明の一実施の形態による検索サービス提供システムの構成例を示す説明図である。
【図２】本発明の一実施の形態によるグローバルサービステーブルの構成例を示す説明図である。
【図３】本発明の一実施の形態によるサービス提供ノードにおける処理の例を示すフローチャートである。
【図４】本発明の一実施の形態によるサービス利用ノードにおける処理の例を示すフローチャートである。
【図５】本発明の一実施の形態によるオーバレイネットワークの構成例を示す説明図である。
【図６】本発明の一実施の形態による電話帳の構成例を示す説明図であり、（ａ）はＡｌｉｃｅの電話帳の例を示しており、（ｂ）はＢｏｂの電話帳の例を示しており、（ｃ）はＡｂｅの電話帳の例を示している。
【図７】本発明の一実施の形態によるリソーステーブルの構成例を示す説明図であり、（ａ）はＡｌｉｃｅのリソーステーブルの例を示しており、（ｂ）はＢｏｂのリソーステーブルの例を示しており、（ｃ）はＡｂｅのリソーステーブルの例を示している。
【図８】本発明の一実施の形態による情報収集部の処理の例を示すフローチャートである。
【図９】本発明の一実施の形態による電話帳データベースの構成例を示す説明図である。
【図１０】本発明の一実施の形態による検索サービス提供部の処理の例を示すフローチャートである。
【図１１】本発明の一実施の形態による検索サービス提供部による検索結果の例を示す説明図である。
【図１２】本発明の一実施の形態による検索サービス提供部による検索結果の例を示す説明図である。
【図１３】従来のオーバレイネットワークの構築例を示す説明図である。
【符号の説明】
【０１０２】
１０…通信部、１１…操作部、１２…表示部、１３…制御部、１４…メモリ、１５…記憶部、１６…情報収集部、１７…データベース更新処理部、１８…検索サービス提供部、Ｔ１…ルーティングテーブル、Ｔ２…グローバルサービステーブル、Ｔ３…リソーステーブル、Ｐ１…電話帳データ、Ｄ１…電話帳データベース、１００…ＰＣ
【図１】
0005151511.tif 000002
【図２】
0005151511.tif 000003
【図３】
0005151511.tif 000004
【図４】
0005151511.tif 000005
【図５】
0005151511.tif 000006
【図６】
0005151511.tif 000007
【図７】
0005151511.tif 000008
【図８】
0005151511.tif 000009
【図９】
0005151511.tif 000010
【図１０】
0005151511.tif 000011
【図１１】
0005151511.tif 000012
【図１２】
0005151511.tif 000013
【図１３】
0005151511.tif 000014