(57)【要約】【課題】サーバを用いないネットワークにおいて、端末間で情報を送受信する場合、各端末が他の端末に自端末の情報を公開することなく、自身の欲する情報を保持する端末を探すことが困難である。【解決手段】自身の欲する情報をクエリとして端末間で伝播させる。前記クエリを伝播させるルーティングの決定に、クエリの分類や過去に回答を得るのにかかった時間やホップ数などの情報を用いることで、他端末の情報を直接知ることなく、効率の良いルーティングを実現する。【選択図】図２
2007323255.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに接続し、外部からクエリや前記クエリに対する回答を受信し、受信したクエリや回答を他のノードに転送する端末であって、
外部からクエリや回答を受信する、クエリ・回答受信部と、
前記受信したクエリや回答を解析する、クエリ・回答解析部と、
前記受信したクエリの情報を保持する、クエリ情報保持部と、
前記受信した回答の送信元である他ノードの情報と前記受信した回答に対応するクエリの情報を保持する、ノード情報保持部と、
クエリや回答を受信した際に、前記クエリ情報保持部とノード情報保持部に保持されている情報を元に、前記クエリや回答の送信先となる他ノードである送信先ノードを決定する、送信先ノード決定部と、
前記受信したクエリや回答を、前記送信先ノードに送信するクエリ・回答送信部と、
を具備することを特徴とする情報伝達装置。
【請求項２】
請求項１記載の端末であって、
前記クエリ情報保持部は、受信したクエリに関する情報と、前記クエリの送信元であるノードの情報を保持し、
前記ノード情報保持部は、前記クエリの分類、および前記クエリの送信先ノード毎に、前記クエリを送信してから前記クエリに対する回答を受信するまでにかかった経過時間を保持し、
前記送信先ノード決定部は、クエリ受信の際には、前記受信したクエリの分類に合致する前記ノード情報のうち、前記経過時間が最短のノードを優先的に送信先ノードと決定し、回答受信の際には、前記クエリ情報保持部に保持されている前記受信した回答に対応するクエリの送信元であるノードを送信先ノードと決定する
ことを特徴とする情報伝達装置。
【請求項３】
請求項１記載の端末であって、
前記クエリ情報保持部は、受信したクエリに関する情報と、前記クエリの送信元であるノードの情報を保持し、
前記ノード情報保持部は、前記クエリの分類、および前記クエリの送信先ノード毎に、前記回答に記載されている前記クエリの回答を得るまでに経たノード数を表す値であるホップ数を保持し、
前記送信先ノード決定部は、クエリ受信の際には、前記受信したクエリの分類に合致する前記ノード情報のうち、前記ホップ数が最小のノードを優先的に送信先ノードとして決定し、回答受信の際には、前記クエリ情報保持部に保持されている前記受信した回答に対応するクエリの送信元であるノードを送信先ノードと決定する
ことを特徴とする情報伝達装置。
【請求項４】
請求項３記載の端末であって、更に、
外部から回答を入力するためのインタフェースを持つ回答入力部と、
前記回答入力部から入力された回答に、ホップ数情報を付与するホップ数設定部と、
を具備することを特徴とする情報伝達装置。
【請求項５】
請求項３記載の端末であって、更に、
外部からクエリを入力するためのインタフェースを保持するクエリ入力部と、
を具備することを特徴とする情報伝達装置。
【請求項６】
請求項３記載の端末であって、更に、
外部からクエリや回答を入力するためのインタフェースを持つクエリ・回答入力部と、
前記クエリ・回答入力部に入力された回答にホップ数情報を付与するホップ数設定部とを具備し、
前記クエリ・回答送信部は、前記クエリ・回答受信部で受信した回答を送信する際に、前記受信した回答に付与されているホップ数に１以上の特定の値を加算して送信すること、
を特徴とする情報伝達装置。
【請求項７】
請求項６記載の端末であって、
ホップ数設定部が設定するホップ数情報は、一定の範囲内のランダムな正の整数値である、
ことを特徴とする、情報伝達装置。
【請求項８】
請求項７記載の端末であって、
ホップ数設定部が設定するホップ数情報は、一定の確率で前記一定の範囲内のランダムな正の整数値であり、前記一定の確率以外の場合においては、他の一定の範囲内のランダムな正の整数値であり、
前記他の一定の範囲に含まれるいずれの値も、前記一定の範囲に含まれるいずれの値よりも大きい、
ことを特徴とする情報伝達装置。
【請求項９】
請求項７記載の端末であって、
前記送信先ノード決定部は、一定の確率で送信先ノードをランダムに決定し、前記一定の確率以外の場合においては、ホップ数が特定の正の整数であるｎ番目に小さなノードを送信先ノードとして決定する、
ことを特徴とする情報伝達装置。
【請求項１０】
請求項７記載の端末であって、
前記クエリ・回答送信部は、前記クエリ・回答受信部で受信した回答を送信する際に、一定の確率で前記受信した回答に付与されているホップ数に特定の整数であるｎを加算して送信し、前記一定の確率以外の場合には、前記受信した回答に付与されているホップ数に１以上の前記ｎとは異なる特定の正の整数値を加算して送信する、
ことを特徴とする情報伝達装置。
【請求項１１】
請求項８、請求項９または請求項１０記載の端末であって、
前記一定の確率、および特定の整数ｎは、前記端末が前記受信したクエリと同等の分類に属するクエリを、過去に回答および／または転送した、頻度および／または回数に応じて変化する、
ことを特徴とする情報伝達装置。
【請求項１２】
請求項７記載の端末であって、更に、
公開鍵と前記公開鍵に対応する秘密鍵を生成する鍵生成部と、
前記クエリ・回答入力部から入力されたクエリに公開鍵を付与し、公開鍵を用いて回答の内容を暗号化し、および秘密鍵を用いて暗号化された前記回答の内容を復号化する、暗号処理部と、を具備し、
前記鍵生成部は、前記クエリ・回答入力部からクエリが入力された際に、前記公開鍵と前記秘密鍵を生成し、
前記クエリ情報保持部には、前記クエリが入力された際に、前記クエリに関連付けて前記秘密鍵が記録され、
前記暗号処理部は、前記クエリが入力された際には、前記クエリに公開鍵を付与し、前記クエリ・回答受信部でクエリを受信したのに対して、前記クエリに対する回答がクエリ・回答入力部から入力され、または回答を生成する際には、前記回答の回答内容を前記クエリに付与されている公開鍵を用いて暗号化し、回答内容が暗号化された自端末から発信したクエリに対する回答を受信した際には、前記クエリ情報保持部に記録されている秘密鍵を用いて前記暗号化された回答内容を復号化する、
ことを特徴とする情報伝達装置。
【請求項１３】
請求項７記載の端末であって、更に、
外部とのインタフェースを持ち、他のノードに対して通知する情報であるメッセージを入力するメッセージ入力部と、
前記メッセージを受信するメッセージ受信部と、
前記メッセージを送信するメッセージ送信部と、
前記メッセージの情報を解析するメッセージ解析部と、を具備し、
前記メッセージは、往路メッセージと復路メッセージの２つに分類され、特定のクエリに関連付けられており、
前記クエリ情報保持部には、受信したクエリ毎に、前記クエリを受信したノードのである受信ノードと、前記クエリを送信したノードである送信ノードの情報を保持し、
前記送信先ノード決定部は、前記メッセージを受信すると、前記メッセージが往路メッセージである場合は、前記クエリ情報保持部に保持されている送信ノードを前記メッセージの送信先ノードと決定し、前記メッセージが復路メッセージである場合は、前記クエリ情報保持部に保持されている受信ノードを前記メッセージの送信先ノードと決定する、
ことを特徴とする情報伝達装置。
【請求項１４】
請求項１２記載の端末であって、更に、
外部とのインタフェースを持ち、他のノードに対して通知する情報であるメッセージを入力するメッセージ入力部と、
前記メッセージを受信するメッセージ受信部と、
前記メッセージを送信するメッセージ送信部と、
前記メッセージの内容を解析するメッセージ解析部と、を具備し、
前記メッセージは、往路メッセージと復路メッセージの２つに分類され、特定のクエリに関連付けられており、
前記クエリ情報保持部には、受信したクエリ毎に、前記クエリを受信したノードのである受信ノードと、前記クエリを送信したノードである送信ノードの情報を保持し、
前記送信先ノード決定部は、前記メッセージを受信すると、前記メッセージが往路メッセージである場合は、前記クエリ情報保持部に保持されている送信ノードを前記メッセージの送信先ノードと決定し、前記メッセージが復路メッセージである場合は、前記クエリ情報保持部に保持されている受信ノードを前記メッセージの送信先ノードと決定し、
前記鍵生成部は、前記クエリ・回答入力部から回答が入力される、または回答を生成する際に、公開鍵と前記公開鍵に対応する秘密鍵を生成し、前記クエリ情報保持部の前記特定のクエリに対応する情報として前記秘密鍵を保持し、
前記暗号処理部は、前記メッセージの入力または生成の際に、前記特定のクエリに付与されていた公開鍵でメッセージの内容を暗号化し、前記メッセージを受信した際に、前記クエリ情報保持部に前記特定のクエリに対応して保持されている秘密鍵を用いて、前記メッセージの内容を復号化する、
ことを特徴とする情報伝達装置。
【請求項１５】
ネットワークに接続し、他のノードからクエリや前記クエリに対応する回答を受信し、受信したクエリや回答を他のノードに転送する方法であって、
ユーザがクエリを入力するクエリ入力ステップ、または、他のノードからクエリを受信するクエリ受信ステップと、
前記クエリを解析する、クエリ解析ステップと、
前記クエリの情報を保持する、クエリ情報保持ステップと、
前記クエリの送信先となる送信先ノードを決定する、送信先ノード決定ステップと、
前記クエリを、前記送信先ノードに送信するクエリ送信ステップと、
ユーザが回答を入力する回答入力ステップと、前記回答にホップ数情報を付与するホップ数設定ステップ、または、他のノードから回答を受信する回答受信ステップ、前記受信した回答を解析する回答解析ステップ、および前記回答の送信元ノードの情報を保持するノード情報保持ステップと、
前記回答の送信先となる他ノードを決定する、送信先ノード決定ステップと、
前記回答を、前記送信先ノードに送信する回答送信ステップとからなり、
前記クエリ情報保持ステップでは、前記クエリに関する情報と前記クエリを受信したノードの識別子を保持し、
前記ノード情報保持ステップでは、前記クエリの回答を得るまでに経たノード数を表す値であり、前記回答に記載されている情報であるホップ数を、前記クエリの分類および送信先ノードに関連させて保持し、
前記回答送信ステップでは、回答を送信する前に、回答に付与されているホップ数に１以上の特定の値を加算して送信し、
前記送信先ノード決定ステップでは、クエリの送信先を決定する際には、前記クエリの分類に合致する前記ノード情報のうち、前記ホップ数が最小のノードを優先的に送信先ノードとして決定し、回答の送信先を決定する場合には、前記クエリ情報保持部に保持されている前記回答に対応するクエリを受信したノードを送信先ノードと決定する、
ことを特徴とする情報伝達方法。
【請求項１６】
ネットワークに接続し、他のノードからクエリや前記クエリに対応する回答を受信し、受信したクエリや回答を他のノードに転送するプログラムであって、
ユーザがクエリを入力するクエリ入力ステップ、または、他のノードからクエリを受信するクエリ受信ステップと、
前記クエリを解析する、クエリ解析ステップと、
前記クエリの情報を保持する、クエリ情報保持ステップと、
前記クエリの送信先となる送信先ノードを決定する、送信先ノード決定ステップと、
前記クエリを、前記送信先ノードに送信するクエリ送信ステップと、
ユーザが回答を入力する回答入力ステップと、前記回答にホップ数情報を付与するホップ数設定ステップ、または、他のノードから回答を受信する回答受信ステップ、前記受信した回答を解析する回答解析ステップ、および前記回答の送信元ノードの情報を保持するノード情報保持ステップと、
前記回答の送信先となる他ノードを決定する、送信先ノード決定ステップと、
前記回答を、前記送信先ノードに送信する回答送信ステップとからなり、
前記クエリ情報保持ステップでは、前記クエリに関する情報と前記クエリを受信したノードの識別子を保持し、
前記ノード情報保持ステップでは、前記クエリの回答を得るまでに経たノード数を表す値であり、前記回答に記載されている情報であるホップ数を、前記クエリの分類および送信先ノードに関連させて保持し、
前記回答送信ステップでは、回答を送信する前に、回答に付与されているホップ数に１以上の特定の値を加算して送信し、
前記送信先ノード決定ステップでは、クエリの送信先を決定する際には、前記クエリの分類に合致する前記ノード情報のうち、前記ホップ数が最小のノードを優先的に送信先ノードとして決定し、回答の送信先を決定する場合には、前記クエリ情報保持部に保持されている前記回答に対応するクエリを受信したノードを送信先ノードと決定する、
ことを特徴とする情報伝達プログラム。
【請求項１７】
請求項１６記載のプログラムを記録した記録媒体。
【請求項１８】
ネットワークに接続し、他のノードからクエリや前記クエリに対応する回答を受信し、受信したクエリや回答を他のノードに転送するＬＳＩであって、
外部からクエリや回答を受信する、クエリ・回答受信部と、
前記受信したクエリや回答を解析する、クエリ・回答解析部と、
前記受信したクエリに関する情報と、前記クエリの送信元であるノードの情報とを保持する、クエリ情報保持部と、
前記クエリの分類、および前記回答の送信元ノード毎に、前記回答に記載されている前記クエリの回答を得るまでに経たノード数を表す値であるホップ数を保持するノード情報保持部と、
クエリ受信の際には、前記受信したクエリの分類に合致する前記ノード情報のうち、前記ホップ数が最小のノードを優先的に送信先ノードとして決定し、回答受信の際には、前記クエリ情報保持部に保持されている前記受信した回答に対応するクエリの送信元であるノードを送信先ノードと決定する、送信先ノード決定部と、
前記受信したクエリや回答を、前記送信先ノードに送信し、更に前記クエリ・回答受信部で受信した回答を送信する際には、前記受信した回答に付与されているホップ数に１以上の特定の値を加算するクエリ・回答送信部と、
外部からクエリや回答を入力するためのインタフェースを持つクエリ・回答入力部と、
前記クエリ・回答入力部に入力された回答にホップ数情報を付与するホップ数設定部と、
を具備する情報伝達装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は複数の端末で構成される通信ネットワークにおいて、サーバを介することなく端末間で情報伝達を行う際の、ルーティングの決定に関するものである。
【背景技術】
【０００２】
近年、通信ネットワーク網の発達に伴い、ネットワークに接続された端末同士でサーバを介さずに情報の交換を行う、Ｐ２Ｐネットワーク、オーバーレイネットワーク等と呼ばれる、ソフトウェアで実現した仮想的なネットワークの上での情報交換が広く普及している。端末数の増大や通信ネットワーク網の更なる発達によるサーバ負荷の増大等を考えると、今後もＰ２Ｐネットワークを利用した端末間での情報交換は益々普及すると考えられる。更に、無線通信技術を用いた通信ネットワーク網の発達により、ユーザは携帯電話やＰＤＡ、ノートパソコン等のネットワーク接続機能を具備する持ち運び可能な端末（以下「携帯端末等」という）を用いることで、外出先や交通機関乗車中等においてもネットワークに接続して通信を行うことができるようになった。現在では、携帯端末等による通信は、ユーザが携帯端末等で無線ネットワークに自発的に接続操作をすることで実現されるものが大半を占めるが、今後は、携帯端末等が無線ネットワークに常時接続し、ユーザが自発的に接続操作をすることなく、常に通信可能な状態となることが考えられる。これらの事情を鑑みるに、今後は、携帯端末等を用いて様々な場所でＰ２Ｐネットワークを利用した情報交換が普及すると考えられる。これらのＰ２Ｐを使った情報交換の新しい利用方法としては、「現在の○○ラーメン屋の混み具合を知りたい」、「東京−ニューヨーク線の新機材のビジネスクラスの座り心地を知りたい」などユーザが質問を行い、それに対して別のユーザが回答する、といったことも可能となる。
【０００３】
Ｐ２Ｐによる情報交換は、端末を管理するサーバが存在しないため、自端末の所望する情報を他のどの端末が所持しているかを発見することが困難である、という課題がある。これを解決するために、ＧｕｎｕｔｅｌｌａやＷｉｎｎｙなどのＰ２Ｐファイル交換ソフトウェアでは、自端末の保持するコンテンツをＰ２Ｐネットワークに参加している端末に流通させ、または、他端末に対して所望するコンテンツをクエリとして通知し、クエリを端末間で伝播することで最終的に所望するコンテンツの所在に達している。また、検索の効率化のために類似のクエリを発行した端末をＰ２Ｐネットワーク上で近い位置に配置するといった工夫も行っている。
【０００４】
しかし、前記Ｐ２Ｐファイル交換ソフトウェアの方法では、端末が既に保持しているコンテンツをタイトルやファイル名等で一意に識別できる必要がある。このため、必要とする情報がコンテンツのように識別することができないような場合、例えば必要とする情報が、「現在の○○ラーメン屋の混み具合」、「東京−ニューヨーク線の新機材のビジネスクラスの座り心地」などの場合、事前に端末が前記必要とする情報を保持していることを表現するのは非常に困難であり、また前記類の情報をＰ２Ｐネットワーク上に流通させることは、ネットワーク帯域の浪費にもつながる。更に、前記類の情報をＰ２Ｐネットワーク上に流通させることは、端末の持ち主であるユーザの個人情報を拡散することに他ならず、ユーザのプライバシーを考慮すると、前記類の情報をＰ２Ｐネットワーク上に流通させることは忌避すべき行為であると言わざるを得ない。
【０００５】
特許文献１に記載のシステムは、フィールド情報と呼ばれる各端末が所望するコンテンツのリストを流通させることで、匿名性を確保しつつコンテンツを配信する方法が開示されている。
【特許文献１】特開２００５−１０８０１６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、特許文献１では、フィールド情報の伝播範囲が限られるためフィールド情報の伝播範囲外に所望のコンテンツが存在する場合には、前記所望のコンテンツを取得することができないという課題があった。このため、特許文献１では、フィールド情報の伝播範囲を大きくすることで、前記所望のコンテンツを取得できる範囲を広げることが可能であるが、フィールド情報の伝播範囲を大きくしてしまうと、不必要に多くのコンテンツがネットワーク上を流れ、使用する帯域幅が増大してしまうという課題が発生してしまう。
【０００７】
更に、特許文献１では、Ｐ２Ｐソフトウェアと同様に、必要とする情報を一意に識別する識別子を与えられない場合、前記フィールド情報に記載すべき事項を特定できず、よって所望の情報を取得することができないという課題があった。
【課題を解決するための手段】
【０００８】
前記従来の課題を解決するために、本発明の端末間情報伝達装置（以下「ノード」という）は、ユーザ操作等に応じて所望の情報を表すクエリや、クエリで表される情報の実体である回答を入力するクエリ・回答入力部と、他ノードから通信で送信されるクエリや回答を受信するクエリ・回答受信部と、入力されたまたは受信したクエリや回答の内容を解析するクエリ・回答解析部と、クエリ・回答解析部の解析に従って入力されたまたは受信したクエリを保持するクエリ情報保持部と、受信したクエリの送信元であるノードの情報を保持するノード情報保持部と、クエリ・回答解析部の解析結果とノード情報保持部が保持しているノード情報に基づいて、受信したクエリを次に送信すべきノードを決定する送信先ノード決定部と、クエリ・回答受信部が受信したクエリを送信先ノード決定部が決定したノードへ送信するクエリ・回答送信部と、クエリ・回答送信部が回答を送信する場合に回答を得るまでに要したホップ数を設定するホップ数設定部と、を備える。
【０００９】
前記クエリ情報保持部は、前記クエリ・回答解析部が受信したクエリを解析した結果であるクエリ情報のうち、少なくとも前記受信したクエリを識別するためのクエリＩＤと、前記受信したクエリの分類と、前記受信したクエリを送信したノードの識別子である送信元ノードＩＤと、前記受信したクエリを他ノードに送信した場合には前記送信先のノードの識別子である送信先ノードＩＤを保持する。また、前記ノード情報保持部は、受信したクエリを送信した送信先ノードごとに、前記受信したクエリの分類と、前記受信したクエリに対する回答が前記送信先ノードから送信された場合には、前記回答を受信するまでに必要となったホップ数を保持し、前記送信先ノード決定部は前記ノード情報保持部に保持されている情報と受信したクエリの分類に基づいて送信先ノードを決定する。更に、ホップ数設定部は、クエリ・回答送信部が回答を送信する際に回答を得るのに要したホップ数として、回答を自ノードで生成した場合には一定値以下のランダムな値を、他ノードから受信した回答を中継する場合には受信したホップ数に特定の値を加えた値を設定する。
【００１０】
これによれば、各ノードのユーザ情報を公開することなく、更に各ノードがどのようなクエリを発したか、または各ノードがどのようなクエリに対する回答を発したかを公開することなく、効率的にクエリを伝達し回答を得ることが可能な論理ネットワークを構成することが可能となる。
【発明の効果】
【００１１】
本発明によれば、匿名性を保ちつつ、効率的にクエリを伝達し回答を伝達できる論理ネットワークを構成することが可能となる。
【発明を実施するための最良の形態】
【００１２】
以下本発明の実施の形態について、図面を参照しながら説明する。
【００１３】
（実施の形態１）
図１は本発明におけるシステム構成の一例である。
【００１４】
図１において、ノード２００ａ〜２００ｄは、ネットワーク１００に接続されていて互いに通信可能な端末であり、各ノードにはそれぞれのノードを識別するためのノードＩＤが割り振られている。また、ネットワーク１００は有線ネットワーク、もしくは無線ネットワークのいずれか、または両方から構成される。
【００１５】
図２は本発明における、ノード２００の構成図である。ノード２００は、クエリ・回答入力部２０１、クエリ・回答受信部２０２、クエリ・回答解析部２０３、クエリ情報保持部２０４、ノード情報保持部２０５、送信先ノード決定部２０６、クエリ・回答送信部２０７、ホップ数設定部２０８から構成される。以下に各構成要素の動作について説明する。
【００１６】
クエリ・回答入力部２０１は、ユーザとのインタフェースを持ち、ユーザからのクエリや回答の入力を受け付ける。なお、クエリ・回答入力部２０１のユーザに対するインタフェースは、ディスプレイなどの表示装置を具備せずとも、例えばＬＥＤとボタンや音声入力装置など、ユーザがクエリや回答をノード２００へ伝達できる機能があれば良いということは言うまでも無い。更には、ユーザとのインタフェースを持たずとも、他の機器からクエリや回答を受信するためのインタフェースを持っているとしても良い。
【００１７】
ユーザからのクエリや回答の入力を受信したクエリ・回答入力部２０１は、前記受信したクエリや回答をクエリ・回答解析部２０３やクエリ・回答送信部２０７へ通知する。
【００１８】
クエリ・回答受信部２０２は、通信ネットワークを通じて他のノードからのクエリや回答を受信し、受信したクエリや回答を、クエリ・回答解析部２０３やクエリ・回答送信部２０７へ通知する。
【００１９】
クエリ・回答解析部２０３は、クエリ・回答入力部２０１やクエリ・回答受信部２０２からクエリや回答を受信すると、クエリや回答の内容を解析し、解析した結果をクエリ情報保持部２０４や送信先ノード決定部２０６に通知する。クエリ・回答解析部２０３が解析する具体的な内容については後述する。
【００２０】
クエリ情報保持部２０４は、クエリ・回答解析部２０３から受信したクエリの解析結果を、クエリ情報として保持する。クエリ情報保持部２０４が保持するクエリ情報の具体的な内容については後述する。
【００２１】
ノード情報保持部２０５は、クエリ・回答解析部２０３のクエリや回答の解析結果を元に、どのノードに対してどのような種類のクエリを送信した場合に、回答が返ってくるまでに要したホップ数の情報を保持する。ノード情報保持部２０５が保持する情報の詳細については後述する。
【００２２】
送信先ノード決定部２０６は、クエリ・回答解析部２０３から受信したクエリの分類や、ノード情報保持部２０５に保持されているノードの情報を元に、前記受信したクエリの送信先ノードを決定したり、決定した送信先ノードの情報をクエリ情報保持部２０４に通知する。
【００２３】
クエリ・回答送信部２０７は、クエリ・回答入力部２０１に入力された、またはクエリ・回答受信部２０２が受信したクエリや回答を、送信先ノード決定部２０６が決定した送信先ノードに対して、ネットワークを通じて送信する。
【００２４】
ホップ数設定部２０８は、クエリ・回答送信部２０７が他ノードに対して回答を送信する際に、回答に要したホップ数を設定する。ホップ数の設定の詳細な説明に関しては後述する。
【００２５】
図３は、本実施の形態における、クエリ情報保持部２０４の保持するクエリ情報の例を示す図である。
【００２６】
クエリＩＤ３０１は、各ノード２００がクエリを発する際に付与するクエリを一意に決定できる識別子である。異なるノード２００が生成したクエリＩＤ３０１が重複しないようにする必要がある。複数のノード２００でクエリＩＤ３０１を重複しないように生成するための方法としてはＭＡＣアドレスを使用したＧＵＩＤ（Ｇｌｏｂａｌ  Ｕｎｉｑｕｅ  ＩＤｅｎｔｉｆｉｅｒ）などが考えられる。本発明においては、匿名性が重要となるため、前記ＧＵＩＤに対してハッシュ関数を適用した値をクエリＩＤ３０１とすることで匿名性の向上を図ることができる。
【００２７】
大分類３０２からその他クエリ情報３０６までの情報は、クエリの分類に使用する情報である。図３の例では５つの項目で分類をすることとしているが、これらを大分類、中分類、小分類の３項目としたり、対象年齢などでクエリを分類したり、というようにクエリの分類自体についてはどのような分類を用いても良い。また、これらの分類は、クエリを発行するノード自身が付与して流通されたものをそのまま利用しても良いし、各ノードのクエリ・回答解析部２０３がクエリを解析して、ノード毎に閉じて異なる分類を行っても良い。
【００２８】
Ｆｒｏｍ３０７は、該クエリをどのノードから受信したものであるかを表すためのものであり、受信元ノードのノードＩＤを値として持つ。図３ではクエリＩＤ＝１００のクエリは、ノードＩＤ＝２０１のノードとノードＩＤ＝３０６のノードから受信し、クエリＩＤ＝３０２のクエリは、ノードＩＤ＝４０３のノードから受信したことを表している。クエリＩＤ＝４２３のクエリはＦｒｏｍ３０７の値がＬｏｃａｌとなっている。Ｆｒｏｍ３０７の値がＬｏｃａｌである場合自ノードから発したクエリであることを表す。もちろん、自ノードを特別扱いせずに、Ｆｒｏｍ３０７の値として自ノードのノードＩＤを記憶していても良いことは言うまでもない。
【００２９】
Ｔｏ３０８は、該クエリを送信した先のノードを識別するためのものであり、送信先ノードのノードＩＤを値として持つ。図３ではクエリＩＤ＝１００のクエリは、ノードＩＤ＝５０１のノードとノードＩＤ＝２７５４のノードへ送信し、クエリＩＤ＝４２３のクエリは、ノードＩＤ＝７７７のノードへ送信したことを表している。またクエリＩＤ＝３０２のクエリは、Ｔｏ３０８の値がＬｏｃａｌとなっている。Ｔｏ３０８の値がＬｏｃａｌである場合、まだどのノードにもクエリを送信していない状態を表す。もちろん、自ノードを特別扱いせずに、Ｔｏ３０８の値として自ノードのノードＩＤを記憶していても良いことは言うまでもない。なお、自ノードが回答をした場合、該クエリに関するクエリ情報は削除することとするが、後述の実施の形態において削除せずに保持する場合もあり得る。
【００３０】
受信時刻３０９は、該クエリを受信した時刻を表す。図３ではクエリＩＤ＝１００のクエリは１月２３日１０：００に受信した旨が記述されている。図３においては、クエリＩＤ＝１００のクエリは２つのノード（ノードＩＤ＝２０１とノードＩＤ＝３０６のノード）から受信しているが、受信時刻は先にクエリＩＤ＝１００のクエリを受信した時刻を格納する。もちろん、各ノードからの受信時刻を個別に管理してもよいのは言うまでも無い。また、クエリＩＤ＝４２３のクエリに関しては、Ｆｒｏｍ３０７がＬｏｃａｌとなっているため自ノードが発したクエリであるため、他ノードからクエリを受信した時刻である受信時刻３０９は記録されていない。なお、図３においては時刻に関しては、月日時分のみしか記述していないが、年月日時分秒ミリ秒のような単位で記述してもよいのは言うまでもない。このことは、他の時刻の記述に関する事項についても同様である。
【００３１】
送信時刻３１０は、該クエリを他ノードに送信した時刻を表す。ここでいう送信とは、該クエリを自ノードで生成して送信した場合と、該クエリを他ノードから受信して自ノードで回答を生成せずに他ノードへ送信した場合の両方の場合を含む。図３ではクエリＩＤ＝１００のクエリの送信時刻３１０は６月２３日１０：０５である旨が記述されている。図３においては、クエリＩＤ＝１００のクエリは２つのノード（ノードＩＤ＝５０１とノードＩＤ＝２７５４のノード）へ送信しているが、送信時刻は先にクエリＩＤ＝１００のクエリを送信した時刻を格納する。もちろん、各ノードへの送信時刻を個別に管理してもよいのは言うまでも無い。また、クエリＩＤ＝３０２のクエリに関しては、Ｔｏ３０８がＬｏｃａｌとなっているため、自ノードからまだ前記クエリを送信していないため、送信時刻３１０は記録されていない。
【００３２】
有効期限３１１は、該クエリの有効期限を表す。クエリＩＤ＝１００のクエリの有効期限は６月２５日００：００であることが記録されているため、該クエリの情報は前記有効期限を過ぎると無効となる。無効となったクエリに関しては、クエリ情報を削除しても良い。また、該クエリに対する回答が来た場合にはその回答は破棄しても良い。有効期限の情報は、クエリの中に絶対時刻として記述されている値を利用しても良いし、相対時刻で記述されている値を利用しても良いし、ノードがクエリの受信時刻や分類などを元に決定しても良い。有効期限の決定方法について、クエリＩＤ＝１００の有効期限を例に挙げると、クエリ内に絶対時刻で６月２５日００：００までと記述されている場合、クエリ内に絶対時刻で受信時刻から３８時間後と記述されている場合、前記クエリを受信したノードがクエリの分類などに応じて３８時間後を有効期限と決定する場合などに、有効期限３１１の値は６月２５日００：００に決定される。なお、有効期限３１１の決定方法に関してここで示した３通りの方法以外の方法を用いたとしても、有効期限３１１自体を設定しなかったとしても、本発明の本質に何ら影響を与えないことは言うまでもない。
【００３３】
図４は、本実施の形態における、ノード情報保持部２０５の保持するノード情報の例を示す図である。
【００３４】
ノードＩＤ４０１は情報を記録する対象ノードの識別子を表し、クエリ情報保持部２０４におけるＦｒｏｍ３０７やＴｏ３０８に記録するノードＩＤと同一のものを指す。大分類４０２から場所４０５は該ノードに対して送信したクエリの分類を表し、図３における大分類３０２から場所３０５の分類に相当する。従って、このクエリの分類方法については図４の記述だけでなく様々な分類をなし得ることは言うまでもない。
【００３５】
経過時間４０６は、ノードＩＤ４０１のノードに対して大分類４０２から場所４０５に該当するクエリを送信したときに、回答が返ってくるまでにかかった時間を表す。図４では、ノードＩＤ＝５０１のノードに対してレストラン、焼き鳥屋、紹介、○○駅、に分類されるクエリを送信した場合、ノードＩＤ＝５０１のノードから回答が送信されてくるまでに１５分間かかったことを表している。同様にノードＩＤ＝５０１のノードに対して、遊園地、ディズニーランド、現状紹介、幕張、に分類されるクエリを送信した場合、ノードＩＤ＝５０１のノードからの回答がその時点ではまだ送信されてきていないことを表す。また、ノードＩＤ＝２７５４のノードに対して、遊園地、ディズニーランド、現状紹介、幕張、に分類されるクエリを送信した場合、ノードＩＤ＝２７５４のノードからの回答が無かったことを表す。ここでは、「未回答」はクエリを送信したがまだ回答を受信していない場合を表し、「無回答」は過去にクエリを発信して有効期限を過ぎても回答を得られなかったことを表す。なお、有効期限を過ぎても回答を受信できた場合には、その経過時間を記録しても良い。
【００３６】
ホップ数４０７は、ノードＩＤ４０１のノードに対して大分類４０２から場所４０５に該当するクエリを送信したときに、回答が返ってくるまでにかかったホップ数を表す。ホップ数とは、回答を生成したノードからいくつのノードを経由して自ノードにその回答が至ったかを表す情報であるが、本実施の形態においては正確な経由ノード数ではなく、大体の経由ノード数を指す値となる。ホップ数の詳細については後述する。図４では、ノードＩＤ＝５０１のノードに対してレストラン、焼き鳥屋、紹介、○○駅、に分類されるクエリを送信した場合、ノードＩＤ＝５０１のノードから回答が送信されてくるまでに１６ホップかかったことを表している。同様にノードＩＤ＝５０１のノードに対して、遊園地、ディズニーランド、現状紹介、幕張、に分類されるクエリを送信した場合、ノードＩＤ＝５０１のノードからの回答がその時点ではまだ送信されてきていないことを表す。また、ノードＩＤ＝２７５４のノードに対して、遊園地、ディズニーランド、現状紹介、幕張、に分類されるクエリを送信した場合、ノードＩＤ＝２７５４のノードからの回答が無かったことを表す。経過時間４０６と同様に、「未回答」はクエリを送信したがまだ回答を受信していない場合を表し、「無回答」は過去にクエリを発信して有効期限を過ぎても回答を得られなかったことを表す。なお、有効期限を過ぎても回答を受信できた場合には、そのホップ数を記録しても良い。
【００３７】
図５はクエリと回答が伝播する例を表す図である。以下に、図５を用いてクエリと回答の伝播について説明する。
【００３８】
最初にノードＩＤ＝２０１のノード（以下「ノード［２０１］」という。ノードＩＤが他の値のノードも同様とする）によりクエリＩＤ＝１０８のクエリ（以下「クエリ［１０８］」という。クエリＩＤが他の値のクエリも同様とする）が生成される。具体的には、図２のクエリ・回答入力部２０１の持つユーザインタフェースを使用して、ユーザがクエリの内容を入力することでクエリが生成される。
【００３９】
図６は、前記生成されたクエリ［１０８］の内容の例を表す図である。クエリＩＤ６０１は、ノード［２０１］がクエリ生成の際に同時に生成する。具体的な生成方法は問わないが、他のノードが生成したクエリＩＤと重ならないようにＧＵＩＤを使ったり、ＧＵＩＤから求めたハッシュ値を使ったりする必要がある。図６の例では生成したクエリのクエリＩＤは１０８であることが記されている。
【００４０】
質問内容６０２には、ユーザが図２のクエリ・回答入力部２０１から入力したクエリの内容そのものが記述されている。クエリ分類６０３にはクエリの分類が記述されている。前記クエリ分類６０３は、クエリ・回答入力部２０１に入力されたクエリ内容がクエリ・回答解析部２０３へ通知され、クエリ・回答解析部２０３でクエリ内容が解析され、分類が付与される。クエリ・回答解析部２０３によるクエリ分類の付与は、自然言語解析によって分類しても良いし、クエリ・回答入力部２０１から入力されるクエリを定型化しておいても良いし、ユーザに分類を入力させても良い。クエリ分類の方法をどのようにしたとしても、本発明の本質には影響を与えないものである。更に、クエリ分類６０３に示す分類は、クエリの生成時にクエリを生成した端末が生成してクエリに付与しても良いし、クエリを受信した端末がそれぞれ独自の方法で分類して内部で扱っても良い。有効期限６０４には、そのクエリの有効期限を記述されている。図６の例では６月２５日００：００までと記述されているため、各ノードは６月２５日の０時になるとクエリ［１０８］を破棄しても良いことを表している。なお、有効期限としては、絶対時刻のみでなく受信してからの期間など別の表現方法も可能である。
【００４１】
ノード［２０１］はクエリ［１０８］を生成すると、生成したクエリ［１０８］の情報をクエリ情報保持部２０４に記録する。図７はクエリ［１０８］に関するクエリ情報保持部２０４に蓄積されているクエリ情報を表す図である。記録されている項目の意味は図３に示した通りである。この時点では、ノード［２０１］はクエリ［１０８］を生成したばかりであるため、Ｔｏ３０８と送信時刻３１０についてはまだ何も記録されていない。
【００４２】
クエリ情報保持部２０４にクエリ［１０８］のクエリ情報を記録すると、送信先ノード決定部２０６が該クエリをどのノードに送信すべきかを決定する処理を実行する。以下、図を用いてクエリを送信する先のノードを決定する際の処理について説明する。
【００４３】
図１０は送信先ノード決定部２０６が、クエリに対して送信先ノードを決定する際の処理フローを表す図であり、図１１はノード［２０１］がクエリ［１０８］の送信先ノードを決定しようとした際のノード情報保持部２０５に保持されているノード情報の例を表す図である。
【００４４】
クエリ［１０８］を生成しクエリ情報保持部２０４に記録したノード［２０１］は、クエリ［１０８］を送信する送信先ノードを決定する処理を、送信先ノード決定部２０６にて開始する。まず、クエリ［１０８］のクエリ内容とノード情報保持部２０５の保持するノード情報を比較する（ステップＳ８０１）。図７に示すクエリ情報と図１１のノード情報の例では、前記クエリ情報はノード情報９０１とノード情報９０４に合致することが分かり、合致するノードはノード［１０００］とノード［２７５４］であることが分かる。合致するノードが存在するため（ステップＳ８０２・ｙｅｓ）、ステップＳ８０３へ遷移し、合致したノードからホップ数が最小のノードを選択する。図１１の場合、ノード情報９０１のホップ数が１２であるのに対して、ノード情報９０４のホップ数は無回答であるため、ノード情報９０１に対応するノードであるノード［１０００］が選択される。
【００４５】
ステップＳ８０３でノードを選択すると、ステップＳ８０４へ遷移して、選択ノードのホップ数とＨを比較する。ここでＨは、任意の値を取ることが可能であり、ネットワークの規模（ネットワークに参加するノード数）や、回答ノードが最初にホップ数を決定する際のランダム値（回答ノードのホップ数の決定方法に関しては後述する）の設定などによって適当な値が選択されている。本実施の形態では、Ｈには２０が選択されていることとする。ステップＳ８０４における比較の結果、ｙｅｓとなりステップＳ８０６へ遷移する。
【００４６】
ステップＳ８０６において、ノード［２０１］の送信先ノード決定部２０６は、送信先ノードをノード［１０００］に決定して、クエリの送信先ノードの決定処理を終了する。
【００４７】
上述した送信先ノード決定処理により、送信先ノードとしてノード［１０００］が決定されたため、ノード［２０１］のクエリ・回答送信部２０７は、送信先ノードであるノード［１０００］に対して、前記クエリ［１０８］を送信する（図５ステップＳ５０１）。この処理の結果、送信先ノードや送信時刻が決定され、ノード［２０１］のクエリ情報保持部２０４のクエリ情報は図８に示すように、Ｔｏ３０８と送信時刻３１０の値が記録される。
【００４８】
次に、クエリ［１０８］を受信したノード［１０００］の動作について説明する。
【００４９】
図１３はクエリを受信した際のノードの処理を表すフローチャートである。各ノードはクエリを受信すると、受信したクエリの内容を、クエリ・回答解析部２０３で解析する（ステップＳ１００１）。前記解析では、クエリのクエリＩＤ、クエリの分類、クエリ送信元のノードＩＤ、等を得る。クエリの解析結果より、まず受信したクエリと同一のクエリＩＤを持つクエリを過去に受信したことがあるかを判断する（ステップＳ１００２）。
【００５０】
ステップＳ１００２において前記受信したクエリを既に受信済みの場合、すなわちクエリ情報に当該クエリに関する情報が記録されていた場合には、ステップＳ１００６へ進み、同一クエリを受信済みの旨を送信元のノードに対して通知して、処理を終了する。
【００５１】
ステップＳ１００２において、前記受信したクエリをそれまでに受信したことがなかった場合、ステップＳ１００３へ遷移して自端末のユーザ情報等と前記受信したクエリの内容を比較して、前記受信したクエリが回答可能かどうかを判断する。この際の判断方法は、ノードが持つユーザの趣味等の情報と前記受信したクエリの分類がどの程度一致するかを測定し、その一致度合いが任意に設定した閾値を超えた場合等の方法が考えられる。なお、クエリ情報とユーザ情報等を比較して、回答可能かどうかを判断する方法として、どのような方法を用いても、本発明の本質には影響しないため、ステップＳ１００３の判断は、どのような方法を用いても良いものとする。
【００５２】
ステップＳ１００３において、回答不可能と判断した場合、ステップＳ１００４へ遷移し、前記受信したクエリを次にどのノードへ送信するかを決定する。なお、ステップＳ１００４における具体的な処理は、図１０に示したフローチャートを前述の説明通りに実行することで実現可能である。クエリ送信先ノードを決定したら、前記受信したクエリを前記送信先ノードに送信し、クエリ情報保持部２０４に前記受信したクエリ情報や送信先ノードの情報などを記録する。また、ノード情報保持部２０５に、前記送信先ノードに関して前記受信したクエリ分類に相当する情報を記録されていない場合、ノード情報保持部２０５に、前記送信先ノードに関して前記受信したクエリ分類に相当する情報を記録する。前記ノード情報の記録の際には、経過時間４０６やホップ数４０７については未回答を記録する。
【００５３】
ステップＳ１００３で、自端末で回答可能と判断した場合、ステップＳ１００７へ遷移し、ユーザへクエリを提示して回答の入力を促す。その結果、ユーザがクエリに対する回答を作成し、クエリ・回答入力部２０１を通じてノードへ回答を入力すると、ステップＳ１００８へ遷移する。図１３には明記していないが、ステップＳ１００７にてユーザが回答を入力しない／できない場合には、ステップＳ１００７を実行せずに、ステップＳ１００４へ遷移して処理を継続する。
【００５４】
なお、ステップＳ１００７において、ユーザに回答の入力を要請すると記述しているが、ユーザからの入力を受けずに、ノード自身で回答を作成してステップＳ１００８へ遷移しても良い。例えば、ノードがセンサ機能を具備しており外部の気温や湿度などの情報を取得でき、かつＧＰＳなどの機能を具備しており現在位置を取得できて○○地域に位置すると認識できている場合、クエリが「現在の○○地域の気温を教えてください」であった場合、ノード自身が自動で回答を作成できるため、ユーザに回答を促すことなく、自身で作成した回答を送信することが可能である。ノードで自動的に回答する場合は、回答用のフォーマットを予め用意しておいても良い。回答用のフォーマットとして例えば、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）などを利用することが可能である。なお、自動で回答する旨の許可をユーザに事前／回答時に確認した場合に限り、回答するとしても良い。
【００５５】
ステップＳ１００７の処理を終えると、ノードは作成した回答を前記受信したクエリの送信元ノードに送信する。この際に送信する回答の内容の例を図１４に示す。回答ＩＤ１１０１は、回答を識別するための識別子で、クエリＩＤと同様の方法または別の方法でノード間で重複しないように生成されるものであり、回答を識別するために利用する。
【００５６】
対象クエリＩＤ１１０２は、その回答がどのクエリに対する回答であるかを表すものであり、回答対象となるクエリのクエリＩＤが代入される。回答内容１１０３は該クエリに対する回答の内容であり、この内容が最初にクエリを生成した端末のユーザに対して提供される。前記回答内容１１０３はユーザの入力をそのまま伝えても良いし、ノード間でＸＭＬなどを用いてフォーマットをあらかじめ取り決めておき、前記あらかじめ取り決められたフォーマットを用いて記述しても良いし、その他最終的に回答内容をユーザに提示できるに足る情報を含んでおり、各ノードが解釈できる情報であればどのようなものでも良い。
【００５７】
ホップ数１１０４は、前述のように送信先ノード決定部２０６の送信先ノード決定処理において、受信したクエリの送信先を決定する際に利用される情報である。ステップＳ１００８においては、回答を生成するノードがランダムに小さな値を設定する。例えば、5〜１０の間でランダムに値を選択した結果７になった場合、図１４に示すようにホップ数として７が記述された回答が生成される。なお、ノードのユーザが自身が回答したことを他ノードに知られても良いという場合には、ホップ数としてランダム値を選択するのではなく１を選択しても良い。
【００５８】
なお、回答に含める情報としては、図１４に示す情報（回答ＩＤ、対象クエリＩＤ、回答内容、ホップ数）以外の情報を含めても良いことはいうまでも無い。他に利用したりユーザに提示したり出来る情報があれば、それを追加した回答を送信することで、別の効果を得ることも可能となる。例えば、回答期限という情報を加えることで、途中でノードが離脱していた場合にいつまでも回答をキャッシュしておくことを避けられるようになる。前記回答期限は、クエリの有効期限を利用したり、クエリの有効期限を元に計算して生成したり、回答を生成した時間を元に計算して生成したり、さまざまな生成方法があるが、どのような方法を用いても良い。
【００５９】
前述のようにして図５ステップＳ５０１において、ノード［２０１］からノード［１０００］へクエリ［１０８］が送信され、ノード［１０００］が図１３、および図１０に示すフローチャートに従って動作した結果、送信先ノードをノード［５０１］としてクエリ［１０８］をノード［５０１］へ送信する（ステップＳ５０２）。図５では、その後、同様に、ノード［５０１］、ノード［３７２］、ノード［２８５］が図１０、および図８に示すフローチャートに従って動作した結果、クエリ［１０８］を送信し（ステップＳ５０２、ステップＳ５０３、ステップＳ５０４、ステップＳ５０５）、最終的にノード［５３１］がノード［３３５］へクエリ［１０８］を送信し（ステップＳ５０６）、ノード［３３５］が回答を生成し、ノード［５３１］へ前記生成した回答を送信（ステップＳ５０７）する様子を表している。
【００６０】
図１５は、ノード２００が回答を受信した際の処理を表すフローチャートである。ノード２００のクエリ・回答受信部２０２は、回答を受信すると、クエリ・回答解析部２０３へ回答を通知し、クエリ・回答解析部２０３が受信した回答を解析する（ステップＳ１２０１）。その後、ステップＳ１２０１における解析結果を元に、ノード情報保持部２０５に記録されているノード情報に対して、受信元ノードに該当するノード情報について、前記受信した回答に対応するクエリ（以下「対応クエリ」という）に関する情報を記録し（ステップＳ１２０２）ステップＳ１２０３へ遷移する。
【００６１】
ステップＳ１２０３では、クエリ情報保持部２０４に記録されているクエリ情報のうち、対応クエリに該当する情報のＴｏ３０８に記録されているノードを送信先ノードとし、受信した回答のホップ数の値に１を加えて新たに生成した回答を、送信先ノードに送信する（ステップＳ１２０４）。その後、ステップＳ１２０５において、クエリ情報保持部から前記対応クエリ情報の記録を削除する。なお、ステップＳ１２０３において、前記クエリ情報のＴｏ３０８に記録されているノードがＬｏｃａｌであった場合、前記受信した回答は、自ノードが生成したクエリに対する回答であると判断できるため、回答をユーザに対して提示したり、ユーザの指示に応じて提示できるようにメモリ上に記録したり、ユーザに回答を受信できたことを通知したりする。この際の、ユーザへの提示／通知方法についてはどのような方法を使っても良い。なお、自ノードが生成したクエリに対する回答を受信した際に、即座にユーザへ提示するか、一旦記録するか、回答を受信したことを通知するか等、どの処理を実行するかを事前にユーザが設定しておき、それに従った動作をしても良い。なお、自ノードがクエリを生成したノードでない場合でも、クエリ内容とノードのユーザ属性（ユーザの嗜好などを表す、ユーザが設定した情報またはユーザの利用履歴から得られる情報）を比較して、該当クエリがユーザの興味の対象であると判断した場合、前記回答をユーザへ提示等しても良い。なお、ステップＳ１２０４で加算する値は１とは限らない。ホップ数が単純増加すれば１でない特定の値を加算することとしても、本発明の本質とは何の関係もない。
【００６２】
以下、図５における、ノード［３３５］からの回答を受信したノード［５３１］の動作を例に用いて、図１５のフローチャートの動作例を説明する。なお、ノード［５３１］は前記回答を受信した際に、クエリ情報保持部２０４に図９に示すクエリ［１０８］に関する情報を保持しているものとする。ノード［３３５］から回答（図１４に示すものとする）をノード［５３１］が受信すると、ステップＳ１２０１においてクエリ・回答解析部２０３で回答の内容を解析する。その結果、対象クエリＩＤ＝１０８であるため、前記回答がクエリ［１０８］に対する回答であることが分かる（ステップＳ１２０１）。
【００６３】
ステップＳ１２０２において、ノード情報保持部２０５のノード［３３５］に対応する情報として、クエリ［１０８］に関する項目を生成し記録する。図１２は、前記記録されるクエリ［１０８］に関する項目である。ノードＩＤ４０１には、クエリ［１０８］の送信先であるノード［３３５］のノードＩＤを記録し、大分類４０２から場所４０５には、クエリ分類に関する情報を記録する。経過時間４０６には、クエリ［１０８］を送信してから回答を受信するまでにかかった時間を記録し、ホップ数には、回答に記載されているホップ数を記録する。
【００６４】
前記ステップＳ１２０２の処理においては、ノードＩＤ４０１の情報は図９におけるＴｏ３０８に記録されているノードＩＤから、大分類４０２から場所４０５の情報は図９における大分類３０２から場所３０５から、経過時間４０６は図９における送信時刻３１０と前記回答を受信した時刻の差から、ホップ数４０７は図１４におけるホップ数１１０４から、それぞれ求められる。
【００６５】
なお、ステップＳ１２０２の処理を実行する際に、既に同一ノードＩＤで同一クエリ分類に属するクエリに関する情報が記録済みであった場合、既に記録済みのホップ数を回答に記載されているホップ数で上書きしても良いし、記録済みのホップ数と回答に記載されているホップ数の平均値で上書きしても良いし、記録済みのホップ数か回答に記載されているホップ数のどちらかに加重をおいた加重平均値で上書きしても良いし、記録済みのホップ数と回答に記載されているホップ数の両方の値を記録しても良い。このように、既に該当する情報が記録済みであった場合に、ホップ数を常に最新のものを保つのか、それまでの情報に最新の情報を加味して計算した値にするのかについては、どちらの方法も考えられる。
【００６６】
次に、ステップＳ１２０３において、図９に示すクエリ情報保持部２０４に保持されているクエリ［１０８］に関する情報を参照し、Ｆｒｏｍ３０７に記録されているノード［２８５］を送信先ノードとして決定し、ステップＳ１２０４でノード［２８５］に対して前記受信した回答を転送する。この際に、図示はしないが図１４におけるホップ数１１０４を、受信した値に１を加えた値、すなわち８に変更した回答を、ノード［２８５］に送信した後、ステップＳ１２０５に遷移し、図９に示すクエリ［１０８］に関する情報を削除する。
【００６７】
このようにして、各ノードは受信した回答のホップ数に１を加えながら、クエリ情報保持部２０４の情報を元に、クエリ［１０８］の送信元ノードへ転送する。図５においては、ノード［２８５］から更に、ノード［３７２］、ノード［５０１］、ノード［１０００］と経由して（ステップＳ５０９、ステップＳ５１０、ステップＳ５１１、ステップＳ５１２）、ノード［２０１］へ回答が伝播する。回答を受信したノード［２０１］は、自身が生成したクエリ［１０８］の回答として、ユーザへ提示等する。
【００６８】
このように動作することで、各ノードは、他ノードに関しては、自ノードに対する送信元ノードと送信先ノードの情報のみしか取り扱わず、回答を生成するノードはホップ数としてランダムな小さな値を付与するため、どのノードがどのようなクエリに対する回答を行ったかについても関知することができない。また、クエリを受信すると、前記受信したクエリに対してホップ数の小さなノードに送信するため、クエリが流通すればするほどネットワーク全体として経路が最適化される。このため、他ノードに自ノードの個人情報や回答したクエリ内容を知られることなく、かつ効率的なクエリのルーティングが可能となる。
【００６９】
（実施の形態２）
図１６は、本実施の形態におけるノード１３００の構成を表す図である。実施の形態１に示した図２の構成図と同じ機能を持つ部位については同じ番号を割り当てており、実施の形態１と異なる部分には異なる番号を割り当てている。ノード２００とノード１３００では、ノード１３００に鍵生成部１０３１と暗号処理部１３０２が追加されている点で異なる。以下、実施の形態１と違う点を中心に、本実施の形態について説明する。
【００７０】
図１７は、クエリ・回答入力部２０１を通じてユーザがクエリを入力した際の処理を表すフローチャートである。本実施の形態におけるノード１３００は、クエリ・回答入力部２０１からクエリが入力される（ステップＳ１４０１）と、鍵生成部１３０１が前記入力されたクエリのために一時的に利用する秘密鍵、公開鍵のペアを生成する（ステップＳ１４０２）。秘密鍵、公開鍵の生成や利用に関しては、ＰＫＩ（Ｐｕｂｌｉｃ  Ｋｅｙ  Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ）などで一般的に利用されている技術であるため、本実施の形態では特に明示しない。
【００７１】
ステップＳ１４０２で秘密鍵、公開鍵を生成した後、暗号化部は、クエリに対して公開鍵を付与した上でクエリ・回答受信部２０２へクエリを通知する（ステップＳ１４０３）。図１８は、ステップＳ１４０３にてクエリ・回答受信部２０２へ通知されるクエリの例を示す図である。図１８に示すクエリは、図６に示すクエリと比較して、公開鍵１５０１が追加されている点で異なっている。
【００７２】
前記クエリを受信したクエリ・回答受信部２０２は、図１３に示すフローチャートに従って動作するが、ステップＳ１００５においてクエリ情報保持部２０４に送信したクエリに関する情報を保持する際に、送信したクエリ情報として、前記鍵生成部１３０１が生成した秘密鍵を関連付けて保持する点で異なる。図１９は、前記秘密鍵を含めたクエリ情報の例である。クエリＩＤ３０１から有効期限３１１までは、図３と同様であり、秘密鍵１６０１がクエリ［１０８］に関連付けて記録されている点で異なっている。
【００７３】
本実施の形態において、他に実施の形態１と異なる点は、クエリを受信したノードが回答を生成する際の処理である。前記処理は、図１３における、ステップＳ１００７の部分に該当する。本実施の形態では、ステップＳ１００７で、受信したクエリに対する回答を生成した後、暗号処理部１３０２で、生成した回答の内容を受信したクエリに記述されている公開鍵１５０１を利用して暗号化し、それを回答とする。図２０は、本実施の形態におけるクエリ［１０８］に対する回答の例である。回答内容１７０１の部分が、受信したクエリに記述されている公開鍵１５０１で暗号化されていることを表現している。暗号化された回答内容１７０１を復号するためには、前記公開鍵に対応する秘密鍵が必要となるため、最初にクエリを生成したノード以外は、回答内容１７０１を参照することができなくなり、クエリに対してどのような回答をしたかを途中で経由するノードに見られることがなくなるため、より安心して回答を生成できるようになる。
【００７４】
（実施の形態３）
本実施の形態では、実施の形態１と比べて、送信先ノード決定部２０６、クエリ・回答送信部２０７、ホップ数設定部２０８の動作が異なっている。本実施の形態では、実施の形態１と異なる点を中心に述べる。
【００７５】
本実施の形態は、あるクエリ分類に属するクエリのルーティングが最適化されることで、特定のクエリ分類のクエリは、特定の経路を通って特定のノードに達する可能性が高くなってしまうことを防ぎ、特定のクエリ分類に属するクエリが、複数の経路に分散し回答するノードが集中しないようにするためのものである。
【００７６】
以下に、送信先ノード決定部２０６の動作について説明する。図２１は、本実施の形態における、送信先ノード決定部２０６の動作を表すフローチャートである。図２１において、図１０で示す実施の形態と同じ動作を表すステップについては、図１０と同じ符号を付与している。本実施の形態においては、クエリの送信先ノードを決定する際に、まず０＜ｒ≦１を満たす乱数を生成し（ステップＳ１８０１）、ステップＳ１８０２においてｒの値が０≦ｐ≦１を満たす任意の値ｐ以下であるかどうかを判定する。ステップＳ１８０２の判定の結果、ｒがｐよりも大きな値であった場合、ステップＳ８０５へ遷移し、以降の動作を図１０と同様に継続する。
【００７７】
一方、ステップＳ１８０２において、ｒの値がｐよりも小さな値であった場合、ステップＳ８０１へ遷移し、合致ノードが存在すればステップＳ１８０３へ遷移する。ステップＳ１８０３において、図１０のステップＳ８０３では合致ノードのうちホップ数が最小のノードを選択したが、本実施の形態においてはホップ数がｎ番目に小さなノードを選択する。
【００７８】
なお、ステップＳ１８０１およびステップＳ１８０２において、乱数ｒとｐを用いてステップＳ８０１に遷移するか、ステップＳ８０５へ遷移するかを決定しているが、この処理はある確率ｐでステップＳ８０１へ遷移し、確率（１−ｐ）でステップＳ８０５へ遷移するような分岐処理が実現できれば、どのような処理を行ってもかまわない。なお、ステップＳ１８０２におけるｐの値を１とすれば常にステップＳ８０１へ遷移し、ｐの値を０とすれば常にステップＳ８０５へ遷移するようにできる。ｐの値を大きくするほど、ステップＳ８０１へ遷移する確率が高くなり、ネットワーク全体としての経路の効率化が図れるため、クエリを発してから回答を得られるまでのホップ数の平均は小さくなるが、ある分野のクエリが特定のノードに集中する可能性が高くなる。一方ｐの値を小さくするほど、ステップＳ８０５へ遷移する確率が高くなり、クエリを発してから回答を得られるまでのホップ数の平均は大きくなってしまうが、クエリの経路が分散するため、特定のノードにある分野のクエリが集中する可能性は低くなる。
【００７９】
なお、ステップＳ１８０３におけるｎの値は任意の自然数を事前に決定しておいても良いし、ステップＳ１８０３を実行する時点である程度小さな自然数ｎをランダムに決定しても良い。また、ホップ数がｎ番目に該当するノードが記録されていなかった場合にはステップＳ８０４における判定はｎｏと判断するものとする。
【００８０】
次に、クエリ・回答送信部２０７における実施の形態１と動作の異なる点を説明する。本実施の形態では、図１５のフローチャートに示す回答を受信した際の動作として、ステップＳ１２０４で示す処理が実施の形態１と異なる。実施の形態１ではステップＳ１２０４において、受信した回答に記載されているホップ数に１を加算して送信先ノードに送信しているが、本実施の形態においては、常に１を加算せずに１以外の値を加算する場合がある。
【００８１】
本実施の形態では、ステップＳ１２０４で加算する値は、それまでに対応クエリの分類に属するクエリをどの程度の頻度で伝達したかに応じて変化させる方法をとる。例えば、過去１日間で前記分類に属するクエリを５回以上伝達していた場合にはｎを加算する、といった具合である。この際のｎの値としては、マイナスの自然数やゼロもとることが出来るものとする。ｎの値をマイナスにすることで、当該分類に属するクエリを更に自経路に集中させることが可能となり、ｎの値を大きな値にすることで、当該分類に属するクエリを他の経路に分散させることが可能となる。ただし、ｎの値をマイナスにしたことによって、ホップ数が一定値以下にならないような調整を行う必要があることは考慮しなくてはならない。なお、前記ｎの値の決定方法は、過去の当該分類に属するクエリの伝達頻度だけでなく、前記対応クエリのＦｒｏｍ３０７やＴｏ３０８などに基づいて決定しても良いし、特定の確率（正規分布など）でｎの値が分散するようにしても良い。
【００８２】
前述のように、ステップＳ１２０４で加算する値を制御することで、特定の経路にクエリが集中する確率を上げたり、逆に特定の経路にクエリが集中しないように分散させたり、というように動的な経路調整が可能となる。
【００８３】
最後に、ホップ数設定部２０８の処理において実施の形態１と異なる処理を行う部分について説明する。実施の形態１では、ステップＳ１００８で生成するホップ数はランダムに小さな値を生成するが、本実施の形態では、それまでに対応クエリの分類に属するクエリをどの程度の頻度で回答したかに応じて変化させる方法をとる。
【００８４】
例えば、過去１日間で前記分類に属するクエリを５回以上伝達していた場合には小さな値ではなくある程度の大きな値を生成する、といった具合である。前記生成するホップ数の値を大きな値とすることで、当該分類に属するクエリが自ノードに集中することを防ぐことが可能となる。なお、ノードで自動的に回答できるクエリやユーザが回答を入力するのに苦痛を感じない場合などは、大きな値を生成しないようにすることで、ネットワーク全体としてのクエリ送信から回答受信までのホップ数を小さくすることが可能である。
【００８５】
なお、本実施の形態では、前述の通り、送信先ノード決定部２０６、クエリ・回答送信部２０７、ホップ数設定部２０８の３つの部位における処理が実施の形態１と異なるとしているが、これらの３つの部位全てで処理が異なる必要は無く、どれか１つの部位、もしくはどれか２つの部位においてのみ処理を変えても良い。
【００８６】
以上の処理により、ある分類に属するクエリが特定の経路・特定のノードに集中することを防いだり、逆に特定のノードにある分類に属するクエリを集中させたりすることが可能となり、より柔軟なルーティング決定が可能となる。
【００８７】
（実施の形態４）
図２３は、本実施の形態におけるノード２０００の構成を表す図である。実施の形態１に示した図２の構成図と同じ機能を持つ部位については同じ番号を割り当てており、実施の形態１と異なる部分には異なる番号を割り当てている。ノード２００とノード２０００では、クエリ・回答入力部２０１がクエリ・回答・メッセージ入力部２００１に、クエリ・回答受信部２０２がクエリ・回答・メッセージ受信部２００２に、クエリ・回答解析部２０３がクエリ・回答・メッセージ解析部２００３に、クエリ・回答送信部２０７がクエリ・回答・メッセージ送信部２００７に、それぞれ置き換わってメッセージを扱える点において異なっている。
【００８８】
本実施の形態におけるメッセージとは、クエリを発したノードと回答を生成したノードの間で、コミュニケーションをとるために送受信するデータである。図２４はメッセージの例を表す図である。メッセージは、メッセージ種別２１０１、対象クエリＩＤ２１０２、メッセージ内容２１０３を含む。メッセージ種別２１０１は、該メッセージが往路（クエリ発信者から回答生成者へのメッセージ）か、復路（回答生成者からクエリ発信者へのメッセージ）かを表す情報である。対象クエリＩＤ２１０２は、該メッセージがどのクエリに対応するメッセージであるかを表す情報である。メッセージ内容２１０３は、クエリ発信者から回答生成者、または回答生成者からクエリ発信者へのメッセージの内容を表す。
【００８９】
図２５はメッセージを受信した時の、ノード２０００の動作を表すフローチャートである。ノード２０００はメッセージを受信すると、クエリ・回答・メッセージ解析部２００１で受信したメッセージを解析する（ステップＳ２２０１）。前記解析により、受信メッセージが往路か復路かという情報と、前記受信メッセージが対応するクエリ（以下「メッセージ対応クエリ」という）を認識する。その後、ステップＳ２２０２に遷移し、前記受信メッセージが往路であった場合、メッセージ対応クエリのクエリ情報におけるＴｏ３０８を送信先ノードとし（ステップＳ２２０３）、前記受信メッセージが復路であった場合、メッセージ対応クエリのクエリ情報におけるＦｒｏｍ３０７を送信先ノードとする（ステップＳ２２０４）。
【００９０】
送信先ノードを決定すると、ステップＳ２２０５へ遷移し、クエリ・回答・メッセージ送信部２００７がメッセージを送信先ノードへ送信する。なお、クエリ発信ノード、または回答生成ノードが前記メッセージを受信した場合には、送信先ノードに前記受信したメッセージを送信するのではなく、前記受信したメッセージをユーザへ提示、またはメッセージを受信したことを通知、または受信したメッセージを記録しておき後でユーザへ提示できるようにすることは言うまでもない。
【００９１】
なお、図２４に示すメッセージ種別２１０１は、前記メッセージを受信した元のノードと、クエリ情報保持部に保持されている対象クエリに関するＦｒｏｍ３０７、Ｔｏ３０８を比較することで判別することが可能であるため、必ずしも必要とは限らない。例えば、前記メッセージを受信した元のノードがＦｒｏｍ３０７に等しかった場合、前記メッセージは往路メッセージであり、Ｔｏ３０８に等しかった場合復路メッセージであることが分かる。
【００９２】
なお、前述のように、メッセージを送受信するためには、回答の送信後にもクエリ情報を保持しておく必要がある。このため、図２２に示すように、クエリ情報として保持期限１９０１を設けて、保持期限１９０１になるまでは、該クエリに対する回答を送信しても該クエリ情報を破棄しないようにすることで、回答送信後にもクエリ情報を保持し続けることが可能となる。もちろん、回答を送信してもクエリ情報を破棄しないのであれば、保持期限１９０１を設ける必要はないことは言うまでもない。
【００９３】
なお、クエリ発生ノードと回答生成ノードの間でメッセージを通信する際に、常に前述の経路をとらなくてはならないという訳ではないのは言うまでもない。メッセージの通信が開始できれば、その後は前記両ノード間で調整して直接通信を行うことは、既存の技術で実現可能である。
【００９４】
（その他の実施の形態）
なお、前述の各実施の形態においては、送信先ノード決定部２０６はホップ数を元に送信先ノードを決定しているが、別の情報を用いても良い。例えば、図４における経過時間４０６の短いノードを送信先ノードとしても良い。その場合、図１０におけるステップＳ８０３では合致ノードのうち経過時間４０６が最短のノードを選択し、ステップＳ８０４の判定は選択ノードの経過時間４０６の値が任意に設定した時間Ｔよりも小さいかどうかという判定となる。もちろん、ホップ数や経過時間以外の、クエリを送信してから回答を受信するまでにかかる定量的数値をカウントまたはノード間で伝達し、ノード情報に記録しておき、その値が小さいものを送信先ノードとして選択するようなアルゴリズムとしても、本発明の本質には影響を与えないことは言うまでもない。なお、前記送信先決定の際に、ノード間の物理的な距離（経由ルータ数、通信にかかる時間など）を考慮しても良いのは言うまでもない。
【００９５】
なお、前述の各実施の形態においては、クエリを受信したノードが回答を生成し、回答内容自体を送信しているが、生成した回答をネットワーク上に配置し、その位置情報（例えば、ｈｔｔｐ：／／○○．××．ｊｐ／ａｎｓｗｅｒ等）のみを、ノードを経由しながら通知しクエリを発したノードが該当する回答の位置情報を得ると、前記位置情報へアクセスして回答内容を取得することも可能である。もちろん、回答内容を暗号化しない場合は、途中でクエリを経由したノードも前記位置情報を参照し回答を得ることが可能である。
【００９６】
なお、前述の各実施の形態においては、クエリを転送したノードが途中でＰ２Ｐネットワークから離脱した場合に備えて、回答の経路を冗長化しても良い。例えば、クエリを送信先ノードに送信する際に、Ｆｒｏｍ３０７のノードの情報を付与して通知しても良いし、複数の端末にクエリを送信しそれらをＦｒｏｍ３０７のノードと擬制して付与して通知しても良い。前述のように、送信先ノードにクエリを送信する際に、Ｆｒｏｍ３０７のノードの情報を付与する場合には、クエリを発したノードの匿名性を向上するためにＦｒｏｍ３０７のノード情報を付与するかしないかをランダムに決定したり、自ノードがＰ２Ｐネットワークから離脱する可能性が高い場合に限りＦｒｏｍ３０７の情報を付与するようにしたり等、必ずＦｒｏｍ３０７のノード情報が付与されないようにしても良い。更に、他のＰ２Ｐネットワークにおけるルーティングの冗長化に関する既存技術を利用しても良いのはいうまでもない。
【００９７】
なお、前述の各実施の形態においては、送信先ノード決定部２０６における送信先ノード決定処理の際に、ノード情報保持部２０５に当該クエリ分類に相当するノード情報が存在しなかった場合には、ランダムで送信先ノードを決定するが、ランダムに決定するのではなくＤＨＴ（Ｄｉｓｔｒｉｂｕｔｅｄ  Ｈａｓｈ  Ｔａｂｌｅ）等の技術を利用することで、クエリ分類から送信先ノードを決定することも可能である。
【００９８】
なお、前述の各実施の形態は、それらを組み合わせて実施することが可能なのはいうまでもない。例えば、実施の形態２と実施の形態４を組み合わせることで、回答生成ノードも回答に回答生成ノードの公開鍵を記載しておくことで、クエリ発信ノードがメッセージを回答生成ノードに通知する際には、前記回答生成ノードの公開鍵を用いてメッセージを暗号化することで、途中のノードがメッセージを盗み見ることが出来なくなるため、メッセージの安全性を増すことが出来る。
【００９９】
なお、前述の各実施の形態において、新規にノードがネットワークに参加した時には、任意の他ノードからノード情報を取得して利用することも可能である。新規にネットワークに参加したノードは、最初はノード情報を保持していないため、効率的にクエリの送信先を決定することが出来ないが、他ノードからノード情報を取得することで、新規にネットワークに参加した場合でも、前記ノード情報を利用することで効率的にクエリの送信先を決定することが可能となる。なお、ノード情報の取得を要求されたノードは、例えばランダムにノード情報を全体の２０％分だけ選択して、要求元に通知しても良い。ノード情報を全て通知しないことにより、回答生成ノードの匿名性がより確保することが可能となる。なお、各ノードは、ノード情報を定期的にサーバにアップするようにすることで、新規にネットワークに参加したノードは、最初にノード情報をサーバから取得することで前記ノード情報を利用することが可能となり、効率的にクエリの送信先を決定することが可能となる。なお、前記サーバは、ノードからノード情報を要求された時に全てのノード情報を返さなくても良いのは言うまでもない。
【０１００】
なお、前述の各実施の形態において、ノード間を伝達されるクエリの情報として、該クエリの回答を通知する際にショートカットが可能となる戻り先ノードＩＤを付与することも可能である。ノードはクエリを受信すると、ある確率で戻り先ノードＩＤをクエリに付与することとする。回答を受信したノードは、受信した回答をＦｒｏｍのノードに送信すると共に戻り先ノードＩＤに送信することで、回答の伝達において途中の経路をスキップすることが可能となる。なお、前記戻り先ノードＩＤは、別のノードが上書きしても良いし、複数の戻り先ノードＩＤをクエリに追記していっても良い。複数の戻り先ノードＩＤを記載することで、経路情報としての冗長性が増し、途中ノードが離脱した場合の耐性が増す。なお、戻り先ノードＩＤを記載する場合、同じ回答ＩＤの回答を正しく破棄する処理が必要なことは言うまでもない。なお、ショートカットして回答が得られた場合（自ノードが戻り先ＩＤを付与してクエリを送信した場合で、Ｔｏ以外のノードから回答が送信されてきた場合）には、前記回答を得られたノードをＴｏとしてノード情報に記録しても良い。
【０１０１】
なお、前述の各実施の形態において、送信先ノードを決定する際のホップ数の閾値であるＨや経過時間の閾値であるＴの値は、ネットワークのサイズ、クエリに回答可能なノード数の予想値、過去に得られたノード情報のホップ数や経過時間等に応じて動的に変化させても良い。
【０１０２】
なお、前述の各実施の形態に置いて、送信先ノード決定部が送信先のノードを決定する際に、受信したクエリの分類に合致するノード情報がなかった場合、ランダムに送信先ノードを決定するとしているが、受信したクエリ分類が階層的になっている場合、例えば図４に示すように大分類と小分類等の分類がある場合には、小分類まで完全に合致するクエリ分類が記録されていなかった場合でも、大分類が合致しているクエリ分類に相当するノード情報が存在する場合、それを合致するノード情報として扱っても良い。例えば、図４に示すノード情報を保持している場合、大分類＝レストラン、小分類＝すし屋に関連するクエリを受信した時に送信先ノードを決定する処理においては、小分類＝すし屋までは合致せずとも、大分類＝レストランまで合致しているノードがあるため、それらに合致するノードを送信先ノードの候補とすることができる。なお、大分類、小分類の２階層の場合だけでなく、大分類、中分類、小分類の３階層や大分類、中分類、小分類、詳細分類の４階層など、任意の階層の分類が考えられる。その場合においても、より詳細な分類まで完全に合致するノード情報が無い場合、次に詳細な分類で合致するノード情報があるかを検索し、それでもなければその次に上位の分類で合致するノード情報があるかを検索する、といったように階層的に順番に合致するノード情報を検索することが可能なのは言うまでもない。なお、ノード分類が階層的でなかったとしても、例えば図４におけるクエリ内容と場所、のように階層化されていない場合でも、完全に合致するノード情報が存在しなかったとしても、そのうちいくつかの項目について分類が一致していた場合、一致する項目が多いノードを送信先ノードの候補とすることも可能である。更に、分類の項目によって優先度や重みを付けることで合致度を評価し、前記合致度の評価の高いノードが閾値を超えていた場合には、前記合致度の高いノードを送信先ノードとして決定しても良いことは言うまでもない。
【０１０３】
なお、前述の各実施の形態において、回答を取得したいノード数を指定してクエリを送信しても良い。例えば、クエリ発信ノードが全体で５つのノードから回答を取得したい場合、クエリには５ノードから回答を取得したい旨を記載して他ノードに送信する。前記クエリを受信したノードがクエリを転送する場合、例えば２ノードから回答を取得したい旨を記載したクエリと、３ノードから回答を取得したい旨を記載したクエリの２つに分けて、２つのノードに送信することが可能となるし、前記ノードが回答をする場合、４ノードから回答を取得したい旨を記載したクエリを他ノードに送信し、かつ自ノードで生成した回答を前記クエリを受信したノードに送信することが可能である。もちろん、クエリ発信ノードが、１ノードから回答を取得したい旨を記載した同一クエリＩＤのクエリを５つのノードに対して送信することも可能なことは言うまでもない。
【０１０４】
なお、前述の各実施の形態は、いずれもユーザとのインタフェースとして、クエリや回答や実施の形態によってはメッセージ（以下「クエリ等」という）の入出力が可能であるように記述しているが、クエリ等の入出力機能を持たずに、クエリ等を転送する機能のみを持つ装置であっても良い。また、クエリの入力機能と回答の出力機能のみを持っていたり、クエリの出力機能と回答の入力機能のみを持っていたり、クエリの入力機能と回答の出力機能とメッセージの入出力機能のみを持っていたり、クエリの出力機能と回答の入力機能とメッセージの入出力機能のみを持っていたり、というように入出力機能に関しては、一部の機能を持たなくても良い。
【０１０５】
なお、前述の各実施の形態は、記憶装置（ＲＯＭ、ＲＡＭ、ハードディスク等）に格納された上述した処理手順を実行可能な所定のプログラムデータが、ＣＰＵによって解釈実行されることで実現される。この場合、プログラムデータは、記録媒体を介して記憶装置内に導入されてもよいし、記録媒体上から直接実行されてもよい。なお、記録媒体は、ＲＯＭ、ＲＡＭ、フラッシュメモリ等の半導体メモリ、フレキシブルディスクやハードディスク等の磁気ディスクメモリ、ＣＤ−ＲＯＭやＤＶＤ、ＢＤ等の光ディスク、メモリカード等の記録媒体をいう。また、記録媒体は、電話回線や搬送路等の通信媒体も含む概念である。
【０１０６】
なお、図２に示すクエリ・回答入力部２０１、クエリ・回答受信部２０２、クエリ・回答解析部２０３等の各機能ブロックやその他の構成図に示す各機能ブロックは、典型的には集積回路であるＬＳＩとして実現されても良い。これらは個別に１チップ化されても良いし、一部又は全てを含むように１チップ化されても良い。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。
【０１０７】
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサーを利用しても良い。
【０１０８】
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適応等が可能性としてありえる。
【産業上の利用可能性】
【０１０９】
本発明にかかる情報伝達装置は、Ｐ２Ｐネットワークなどのサーバを介さずに端末間で情報を授受するシステムにおいて、嗜好などの個人属性を外部に公開することなく、クエリを回答可能なノードを効率的に探索できる機能を有し、携帯電話、ＰＤＡ、ポータブルゲーム機器、テレビ、ホームサーバ、バソコンなど無線または有線でネットワークに接続され、相互にデータを交換する機器の機能として有用である。特に、不特定多数の間でコミュニケーションを要するようなサービスにおいて、様々な応用が可能である。
【図面の簡単な説明】
【０１１０】
【図１】本発明のシステム構成を表す図
【図２】本発明のノードの構成を表す図
【図３】クエリ情報の例を示す図
【図４】ノード情報の例を示す図
【図５】クエリおよび回答の伝播の様子を表す図
【図６】クエリの例を示す図
【図７】クエリを発信するノードにおける、クエリ送信前のクエリ情報の例を示す図
【図８】クエリを発信するノードにおける、クエリ送信後のクエリ情報の例を示す図
【図９】クエリを転送するノードにおける、クエリ送信後のクエリ情報の例を示す図
【図１０】クエリの送信先ノードを決定する処理を表すフローチャート
【図１１】ノード情報の例を示す図
【図１２】ノード情報の例を示す図
【図１３】クエリ受信時の処理を表すフローチャート
【図１４】回答の例を示す図
【図１５】回答受信時の処理を表すフローチャート
【図１６】本発明の実施の形態２におけるノードの構成を表す図
【図１７】本発明の実施の形態２におけるクエリ生成時の処理を表すフローチャート
【図１８】本発明の実施の形態２におけるクエリの例を示す図
【図１９】本発明の実施の形態２におけるクエリ情報の例を示す図
【図２０】本発明の実施の形態２における回答の例を示す図
【図２１】本発明の実施の形態３における送信先ノード決定処理を表すフローチャート
【図２２】本発明の実施の形態４におけるクエリ情報の例を示す図
【図２３】本発明の実施の形態４におけるノードの構成を表す図
【図２４】本発明の実施の形態４におけるメッセージの例を示す図
【図２５】本発明の実施の形態４におけるメッセージ受信時の処理を表すフローチャート
【符号の説明】
【０１１１】
２００    ノード
２０１    クエリ・回答入力部
２０２    クエリ・回答受信部
２０３    クエリ・回答解析部
２０４    クエリ情報保持部
２０５    ノード情報保持部
２０６    送信先ノード決定部
２０７    クエリ・回答送信部
２０８    ホップ数設定部
【図１】
2007323255.tif 000003
【図２】
2007323255.tif 000004
【図３】
2007323255.tif 000005
【図４】
2007323255.tif 000006
【図５】
2007323255.tif 000007
【図６】
2007323255.tif 000008
【図７】
2007323255.tif 000009
【図８】
2007323255.tif 000010
【図９】
2007323255.tif 000011
【図１０】
2007323255.tif 000012
【図１１】
2007323255.tif 000013
【図１２】
2007323255.tif 000014
【図１３】
2007323255.tif 000015
【図１４】
2007323255.tif 000016
【図１５】
2007323255.tif 000017
【図１６】
2007323255.tif 000018
【図１７】
2007323255.tif 000019
【図１８】
2007323255.tif 000020
【図１９】
2007323255.tif 000021
【図２０】
2007323255.tif 000022
【図２１】
2007323255.tif 000023
【図２２】
2007323255.tif 000024
【図２３】
2007323255.tif 000025
【図２４】
2007323255.tif 000026
【図２５】
2007323255.tif 000027