(57)【特許請求の範囲】
【請求項１】
ネットワ- ク上に複数の検索装置が接続され、該複数の検索装置はそれぞれ情報資源の位置情報を含む情報である広告情報を記憶する手段と, 利用者からの検索依頼を受け付けて自検索装置および前記ネットワーク上にある他の検索装置が有する広告情報記憶手段を検索する手段と, 該広告情報を前記広告情報記憶手段に登録する依頼を受け付ける手段と、該登録依頼された広告情報を前記ネットワーク上にある他の検索装置に転送する手段とを有して構成される分散検索システムであって、
前記広告情報に付与されるコスト情報に応じて、ネットワーク上で該広告情報が転送される範囲を決定することを特徴とする分散検索システム。
【請求項２】
前記ネットワークに接続された他の検索装置からの検索結果である広告情報を依頼元の検索装置に返送する際に、検索依頼を中継した検索装置を逆に辿りながら、返送経路上の各検索装置に記憶された広告情報を更新することを特徴とする請求項１に記載の分散検索システム。
【請求項３】
情報検索者が検索して得られた広告情報に対応する情報資源に対して付与する評価値を、前記ネットワーク上の各検索装置上に記憶された広告情報に対応づけて記憶することを特徴とする請求項１に記載の分散検索システム。
【請求項４】
前記検索結果の中から評価値の良い広告情報および/ または該広告情報に対応する情報資源を選択して情報検索者に提示することを特徴とする請求項３に記載の分散検索システム。
【請求項５】
情報資源提供者に対して、自分が広告した情報資源の評価値を知らせることを特徴とする請求項３に記載の分散検索システム。
【請求項６】
前記広告情報に付与された評価値に基づいて、前記ネットワーク上の各検索装置上に記憶された広告情報を記憶する期間の変更および/ または削除を行うことを特徴とする請求項３に記載の分散検索システム。
【請求項７】
ネットワ- ク上に接続され、少なくとも情報資源の位置情報を含む情報である広告情報を記憶する手段と有し、利用者からの検索依頼を受け付けて前記広告情報記憶手段の検索を行って抽出された広告情報および／または該広告情報に対応する情報資源の提示を行う検索装置であって、
前記広告情報の登録を受け付ける広告処理部と、
前記広告処理手段が受け付けた広告情報を前記広告情報記憶手段に記録すると共に前記ネットワークに接続された他の検索装置に該広告情報を転送する処理と、前記ネットワーク上に接続された他の検索装置から転送された広告情報を前記記憶手段に記録すると共に前記広告情報に含まれるコスト情報を基に当該広告情報を他の検索装置に転送するか否かを決定し、転送すると決定した場合に前記転送元の他の検索装置を除く前記ネットワーク上に接続された他の検索装置に該広告情報を転送する処理とを実行する制御部とを備えることを特徴とする分散検索システムにおける検索装置。
【請求項８】
前記制御部は前記広告情報に含まれるコスト情報を計算して、当該広告情報のコスト情報を書き換えて転送を行うことを特徴とする請求項７に記載の分散検索システムにおける検索装置。
【請求項９】
前記広告処理部は前記広告情報に付与された評価値を取得して、当該広告情報の提供者に該評価値を提示することを特徴とする請求項７に記載の分散検索システムにおける検索装置。
【請求項１０】
ネットワ- ク上に接続され、少なくとも情報資源の位置情報を含む情報である広告情報を記憶する手段と有し、利用者からの検索依頼を受け付けて前記広告情報記憶手段の検索を行って抽出された広告情報および／または該広告情報に対応する情報資源の提示を行う検索装置であって、
前記広告情報の登録を受け付ける広告処理部と、
前記広告処理手段が受け付けた広告情報を前記広告情報記憶手段に記録すると共に前記ネットワークに接続された他の検索装置に該広告情報を転送する処理と、前記ネットワーク上に接続された他の検索装置から転送された広告情報を前記記憶手段に記録すると共に前記広告情報に含まれるコスト情報を基に当該広告情報を他の検索装置に転送するか否かを決定し、転送すると決定した場合に前記転送元の他の検索装置を除く前記ネットワーク上に接続された他の検索装置に該広告情報を転送する処理とを実行する制御部と、
該検索装置が受信した広告情報、検索依頼、検索結果の各情報のうち少なくともいずれかの一つの種類の情報について、該情報の転送元および／又は転送経路の情報を含めて履歴として記録する履歴データベースとを備えることを特徴とする分散検索システムにおける検索装置。
【請求項１１】
前記履歴データベースは少なくとも蓄積した情報に関するキーワードと該情報の転送元および／又は転送経路の情報とを対応づけて記録することを特徴とする請求項１０に記載の分散検索システムにおける検索装置。
【請求項１２】
広告情報を蓄積する広告情報スプールを設けると共に、
前記制御部は、受信した広告情報に対応する検索要求を前記履歴データベースより検索し、該検索結果に基づいて前記受信した広告情報の優先度を決定し、該優先度に基づいて前記受信した広告情報の転送の時期を決定し、ただちに転送されない広告情報については前記広告情報スプールに蓄積することを特徴とする請求項１０に記載の分散検索システムにおける検索装置。
【請求項１３】
前記制御部は検索依頼に含まれるキーワードを基に前記履歴データベースを検索し、該キーワードが含まれる広告情報の転送元および／又は転送経路に基づいて前記検索依頼の転送先を決定することを特徴とする請求項１１に記載の分散検索システムにおける検索装置。
【請求項１４】
前記制御部は広告依頼に含まれるキーワードを基に前記履歴データベースを検索し、該キーワードが含まれる検索依頼の転送元および／又は転送経路に基づいて前記広告依頼の転送先を決定することを特徴とする請求項１１に記載の分散検索システムにおける検索装置。
【請求項１５】
情報を他の検索装置に転送する際に要したレスポンス時間を前記他の検索装置毎に記録するエージェントステイトテーブルを設け、
前記制御部は、他の検索装置のうちの一つの検索装置に対する情報の転送に失敗したときに、前記履歴データベースを検索して該履歴データベースに含まれる転送経路の情報から前記転送に失敗した検索装置に対して論理的に近隣にある他の検索装置を求め、求められた前記他の検索装置のうち最も応答が早い検索装置を前記エージェントステイトテーブルより求め、該求められた他の検索装置を選択して前記転送に失敗した情報の転送を行うことを特徴とする請求項１０に記載の分散検索システムにおける検索装置。
【請求項１６】
情報を他の検索装置に転送する際に要する応答時間を予め設定した時間帯毎に求めて前記他の検索装置毎に記録するエージェントステイトテーブルと、
前記エージェントステイトテーブルを参照して前記他の検索装置毎に時間帯毎の負荷の高さを推定し、該推定した負荷の高さと転送すべき広告情報の優先度とに基づいて前記広告スプールに蓄積された広告情報を転送する時間帯を転送先の検索装置毎に決定する広告スケジューラを備えたことを特徴とする請求項１３に記載の分散検索システムにおける検索装置。
【請求項１７】
受け付けた情報に含まれるコスト情報と、前記履歴データベースに記録された該受け付けた情報に対応する情報の経路情報とに基づいて、転送先の他の検索装置毎に新たなコスト情報を算出して前記受け付けた情報に含まれるコスト情報を該算出したコスト情報に書き換え、前記他の検索装置に情報の転送を行うコストマネージャを設けたことを特徴とする請求項１０に記載の分散検索システムにおける検索装置。
【請求項１８】
前記コスト情報は前記広告情報が前記ネットワーク上で経由する検索装置の台数が設定されるものであり、各検索装置は広告情報に付与された検索範囲情報に含まれる検索装置の台数を減算する演算を行うことを特徴とする請求項１に記載の情報検索方法
【請求項１９】
前記コスト情報は前記広告情報が前記ネットワーク上で経由する検索装置の台数が設定されるものであり、前記制御部によるコスト情報の計算は該検索装置の台数を減算するものであることを特徴とする請求項８に記載の情報検索方法
【請求項２０】
前記ネットワーク上に接続された他の検索装置に広告依頼を転送する処理は、ネットワーク上での論理的な位置情報を認識している他の検索装置に対して実施されることを特徴とする請求項７に記載の検索装置。
【発明の詳細な説明】
【産業上の利用分野】
本発明は、大規模ネットワークに接続された膨大な数の計算機が、それぞれ何らかの情報資源を有し、それを利用者に提供する検索装置環境において、利用者が希望する情報資源を有する計算機を探し出すための機能に関する。
【従来の技術】
計算機が提供する情報やサービスは、情報産業のもとになる無形の物資という意味で、これらを総称して「情報資源」と呼ぶことにする。
今日のように、ネットワークが発達し、ネットワークに接続されている計算機の数が莫大になり、様々なサービスが行われるようになるにつれて、それぞれの計算機がどのような情報資源を有しているのかを知ることが非常に困難になってきた。
また、たとえそのような情報が得られたとしても、計算機やネットワークのメンテナンスや故障などによって、ネットワーク環境は刻一刻と変化するため、以前に利用できた情報資源が、再び利用できるとは限らない。そのため、利用者は情報資源を実際に利用しようとする時点における最新の情報をもとに、希望する情報資源を提供する計算機を知る必要がある。
また、同じ情報資源を有する計算機は一般に多数存在しており、そのそれぞれは、計算機の管理者の運営方針により、情報の新しさ、正確さ、抽象度などの情報資源の質が、計算機ごとに異なるのが当然である。したがって、利用者としては、多くの計算機群の中から、より良い情報資源を有する計算機を見つけ出せることが望ましい。しかし、その情報資源の善し悪しは、実際に利用し、他の情報資源も使い比べてみなければ分からず、利用者がそれを行うのは、無闇に手間を必要とし、有意義とは言えない。また、情報資源に関する知識の乏しい初心者にとっては、そのようなことを見極めることすら、困難なことである。そこで、多くの利用者から比較的良いと認知されている情報資源を推薦する機能も有益である。
近年、ネットワーク上の多くの情報資源が  ＷＷＷ  （Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ）  によってサービスされるようになってきた。ＷＷＷ  においては、情報資源の位置情報はＵＲＬ  （Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）によって表現され、ユーザがある情報資源を利用しようとする場合には、その情報資源の位置情報を示す  ＵＲＬ  を知る必要がある。しかし、個人が独力で知り得る  ＵＲＬ  は、ネットワーク上の全情報資源に遥かに及ばない。そこで、情報資源に対応する  ＵＲＬ  を検索する方法として、サーチエンジンと呼ばれる検索サービスが、ＷＷＷ  上で提供されている。これらの行っている手法は、基本的に、ネットワークを通じて利用可能な情報資源に関する情報を収集するステップと、収集した情報を管理し、利用者に提供するステップに分けることができる。情報収集の方法は、次の２  通りに大別できる。
・ディレクトリサービス
情報資源を提供する側が、サーチエンジンのサービス（  ディレクトリサービス）  を行っている管理者（  一種の情報資源の仲介業者）  にディレクトリリストへの登録を依頼する方式で、Ｙａｈｏｏ  （  ｈｔｔｐ：／／ｗｗｗ．ｙａｈｏｏ．ｃｏｍ／  ）  や  ＡｌｔａＶｉｓｔａ（  ｈｔｔｐ：／／ａｌｔａｖｉｓｔａ．ｄｉｇｉｔａｌ．ｃｏｍ／  ）  など多数のサーチエンジンが該当する。この方式では、情報資源提供者が、ある程度自信を持って登録依頼を出すので、情報の
質が良い反面、登録作業が管理者の手作業によってなされる場合が多く、管理者の負担が大きいという短所を持つ。また、その結果として、情報の更新が速やかかつ正確に行われない恐れもある。
・ロボット
ロボットと呼ばれるプログラムを使用して、ＨＴＭＬ（Ｈｙｐｅｒ−Ｔｅｘｔ  Ｍａｒｋ−ｕｐ  Ｌａｎｇｕａｇｅ。ＷＷＷ  で提供する情報を記述する標準的な言語）  文書内のリンク（  アンカー）  を順に辿って、世界中に存在する  ＵＲＬを自動的に探索して回り、ＵＲＬ  のデータベースを構築する方式である。ＷＷＷ  Ｗｏｒｍ（  コロラド大、Ｏ．Ａ．ＭｃＢｒｙａｎ）や  ＲＢＳ  Ｅ  Ｓｐｉｄｅｒ  （  ヒューストン大、Ｄ．Ｅｉｃｈｉｍａｎｎ）などがそうである。この方式の利点は、情報資源提供者側が何もしなくてもよいことである。しかし、厳密には、誰かに情報資源を提供する旨を知らせて、リンクを張って貰わない限り、ロボットが発見することは不可能である。また、情報資源提供者の知らない内に情報資源が参照されてしまうために、情報資源やサービスを更新したことを誰に伝えればよいのかが分からない点は問題である。更に、機械的に情報資源を漁るので、役に立たない情報資源を拾いやすく、ネットワークや計算機の無用な負荷を生むことになる。
次に、集めた情報資源に関する位置情報を管理し、利用者に提供する方法は、次のように分類することができる。
・集中管理
一箇所のサーバで全てのデータを提供する方式で、Ｙａｈｏｏ  やＡｌｔａＶｉｓｔａ  を含め、多くのサーチエンジンが該当する。この方式は、管理の対象が一箇所なのでメンテナンスは容易であるという利点があるが、その反面、利用者のアクセスが一箇所のサーバに集中するので、サーバの負荷が非常に大きくなりやすい。また、ある利用者はサーバへの通信コストが高くなってしまうのは必須で、すべての利用者が快適に利用できるとは限らない上に、一台のサーバがダウンすると、もはや利用できなくなってしまうという短所を持ちあわせている。
・分散管理
互いに異なる幾つかのサーバで分担してデータを管理・提供する方式であるが、分担の仕方に応じて次のように分類できる。
各利用者がアクセスしやすいサーバを選んで使用することで、負荷分散を図る。ミラーリングはこれに該当する。この方式の利点は同じ機能を持つサーバがいくつもあるので、あるサーバがダウンしてもサービスが続けられるという点である。しかし、利用者にとっては、同じサービスを行う代替サーバの位置情報を把握しておかなければ、この利点を亨受することはできない。また、すべてのサーバで常に同じデータを保持しなければならないので、データの管理に要するコストが大きいという問題点を含んでいる。
・サービスの分散
サービスをいくつかのカテゴリに分類し、各々のカテゴリをいくつかのサーバに担当させる。計算機の名前からその  ＩＰ  アドレスを参照する  ＤＮＳ  （Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｅｒｖｉｃｅ）は、これに該当する。また、大規模分散データベース  ＷＡＩＳ  （Ｗｉｄｅ  Ａｒｅａ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｓｅｒｖｅｒ）も、この範疇に入れることが可能である。また、アクセスの分散とも両立する場合がある。この方式では、サービスの種類によって、管理するサーバが違うので、メンテナンスは容易である。しかし、サービスの種類や範囲を限定すると、結局は集中管理と見なせるので、集中管理の短所が見えてくる。
利用者は、自分の希望するサービスに応じてサーバを使い分けなければならず、サービスからそれを提供するサーバを知る手段がないと利用者側は不便を感じる（ＤＮＳ  では、ドメインの階層を利用して、自動的に捜し出せるので、このような問題はない。ＷＡＩＳ  は  ｄｉｒｅｃｔｏｒｙ−ｏｆ−ｓｅｒｖｅｒｓ  という名前のデータベースで、それを行う）  。
一方、情報資源の推薦機能としては、ソーシャルフィルタリングあるいは共助（ｃｏｌｌａｂｏｒａｔｉｖｅ）  フィルタリングと呼ばれる、他者の推薦や評価値、同じ嗜好を持つ他者の行動を基にして、利用者にとって好ましいものを推薦する技術が開発されている。例えば、Ｔａｐｅｓｔｒｙ  （Ｘｅｒｏｘ  Ｐａｌｏ  Ａｌｔｏ  Ｒｅｓｅａｒｃｈ  Ｃｅｎｔｅｒ  、Ｄ．Ｇｏｌｄｂｅｒｇ、  Ｄ．Ｔｅｒｒｙ）  は、ネットニュースやメーリングリストの記事を対象にし、大量の記事の中から、ある人が積極的に推薦してくれる記事を選択して読むことを支援するシステムである。これに対して、過去の記事に対する評価値の付け方が似ている（  価値観の似ている）  他の利用者が、高い評価値を付けたものを推薦するシステムとしては、ネットニュースの推薦を行うＧｒｏｕｐＬｅｎｓ（Ｐ．Ｒｅｓｎｉｃｋ）、音楽アルバムの推薦を行うＲｉｎｇｏ  （ＭＩＴ、Ｐ．Ｍａｅｓ、Ｕ．Ｓｈａｒｄａｎａｎｄ）  などが挙げられる。
ところが、ある分野の嗜好が類似しているからといって、その他の分野に関する嗜好が同じである保証は得られないので、必ずしも特定の個人の行動や推薦に従うのが良いとは限らないことがある。また、嗜好に関する情報は集中管理されているため、嗜好データの管理に関して、サーチエンジンの情報の集中管理で述べたような問題点が浮き彫りになる。
【発明が解決しようとする課題】
前節で述べたように、既存の方法における問題点は、次のように整理することができる。
・ディレクトリサービスにおいては、登録作業が管理者の手作業によることが多く、そのため管理者の負担が大きい。また、管理者の手違いにより、検索がうまく行われなくなる可能性がある。
・ロボットプログラムが  ＨＴＭＬ  文書の内容をよく吟味しないため、役に立たない  ＨＴＭＬ  文書を転送する可能性が大で、それによるトラフィックやサーバへの負荷が増大しがちであった。
・トラフィックを低く抑えるためには、ロボットプログラムを起動する頻度を少なくする必用があり、そうすると収集された情報は古くなりがちで、入手した情報が既に無効になっている可能性が大きくなる。
・ロボットによる情報収集は、情報資源提供者側で、提供するサービス内容の変更知らせるべき相手が分からなかったり、たとえ変更を伝えることができたとしても、その内容が即座に検索結果に反映されない可能性がある。
・情報資源のデータベースが巨大になると、検索に対して膨大な結果が出力されるために、利用者はどれが最も適切な情報資源なのかを判断しにくくなる。特に、利用者が、対象としている情報に関する十分な知識を持っていない場合に顕著である。
・特定の嗜好が類似しているからと言って、すべての嗜好が類似しているとは保証できないので、ある特定の個人が推薦したものに、常に満足できるとは限らない。
更に、上記のような分散検索方式においては、エージェントがどのように配置され、どのように結合されているかが、検索のパーフォーマンスを左右する．このため、エージェントの管理者は、全体の効率を上げるためには、エージェントネットワークをどのように構築するかをよく検討する必要がある。
従来の分散検索方式においては、エージェントの近隣関係は、エージェントの管理者があらかじめ決定し、チューニングは管理者が手作業で行う必要があり、エージェントのネットワーク環境の変化に対して柔軟に対処することが困難であった。
ところが、ネットワーク環境は絶えず変化するものであり、あるエージェント間の通信路が障害の為に通信できなくなったり，一時的にエージェントの負荷がくなってしまい、速やかに検索結果を得ることが困難である状況に出喰わすこ  とがある。また、検索要求を受け取ったエージェントすべてからの結果が得られないのであれば、十分に望ましい検索結果を得られないということにも継がる。
一方、検索結果の返送によって、資源情報を得るエージェントは、自分の最寄りの利用者が全然参照しない、無駄な資源情報を無意味に保持する状況も想定される。このような状況は、無用な情報の管理コストを削減するためには、避けたい状況である。
本発明は、情報資源に関する情報の管理を自動化し、情報資源提供者による情報資源の広告と利用者による問い合わせを仲介し、検索結果を利用者に返送する際に、情報資源の広告も同時に行うことにより、情報の陳腐化を防ぎ、多くの情報資源から一般的に良いと認知されているものを選択するようにすることで、上記の問題点を解決した情報資源の発見を目的とする。
更に本発明は、各エージェントが、受け取った資源情報の広告、検索要求、あるいは検索結果の履歴として、頻度、発生元、他のエージェントの応答時間などの情報を記録し、それらのデータを利用し、情報の転送のスケジューリングを行ったり、情報配送のコストの配分を行ったり、転送先として適切なエージェントを選択することによって、効率良く資源情報を伝播させ、検索することを目的とする。
【課題を解決するための手段】
本発明は、複数のエージェントのネットワークからなり、図１は、各エージェント（検索装置）単体の原理説明図である。図中（１）  は広告処理部であり、情報資源提供者からの情報資源に関する広告を受け付け、必要に応じて情報資源提供者に通知を行うものであり、問い合わせ処理部（２）  は、利用者からの検索依頼を受け付け、結果を利用者に返送する部分である。エージェントインターフェース（３）  は、他のエージェントと、広告や問い合わせとその結果をやり取りする部分である。情報資源データベース（４）  は、広告処理部（１）  から送付された広告や、エージェントインターフェース（３）  から受け取った広告を保持するものである。情報資源データ制御部（５）  は、広告処理部（１）  やエージェントインターフェース（３）  から受け取った広告に対して、情報資源データベース（４）  に保管したり、広告に要したコストを計算し、それに応じて、エージェントインターフェース（３）  を通じて、他のエージェントに送付するなどの処理を指示し、問い合わせ処理部（２）  やエージェントインターフェース（３）  からの問い合わせに対しては、情報資源データベース（４）  を検索したり、検索要求の伝達に要したコストの計算を行い、エージェントインターフェース（３）  を通じて他のエージェントへ問い合わせを回送するなどの処理を行うものである。システム全体における、このような広告・問い合わせなどのデータの授受を模式的に表したものが図２である。図中○がエージェントを表し、そのそれぞれがここで述べた動作を行う。また、図中のエージェント間の実線は、通信可能であるという関係を表している。
本発明では、図２のように、前節で述べた構成を持つ複数のエージェントが、相互に連結したインフラを構成し、情報資源提供者が自分の提供できるサービスに関する情報を、広告という形式で、最寄りのエージェントに知らせる。広告を受け取ったエージェントは、その広告に記載されている内容を情報資源データベースに蓄え、あるコスト内で伝達できる範囲のエージェントにも同様の広告を行う。こうして、広告を受け取ったエージェントは、その広告をある一定期間（  生存期間と呼ぶ）  保持し、それを過ぎた時点で消去するようにし、古い情報がいつまでもエージェントの情報資源データベースに留まらないようにしている。
一方、利用者からの問い合わせが発生した場合は、広告と同様に、あるコスト内で伝達できる範囲のエージェントにも問い合わせを送付し、該当するデータを持つエージェントに問い合わせが到達した時点で、そのエージェントは結果を利用者に返送する。結果を返送する際には、問い合わせが経由してきたエージェントを逆に辿り、各エージェントにその結果を蓄えさせるようにして、最初に情報資源提供者が広告した範囲外にも、広告が伝播されるようにする（  図３）  。検索に成功した利用者は、その情報資源を利用し満足のいく結果が得られた場合、図４のように評価をフィードバックさせ、情報資源提供者が行った広告と同じように伝播させる。情報資源に関して良い評価を受け取ったエージェントは、その情報資源に関する情報の生存期間を延長するようにし、利用者を満足させる情報資源に関する広告が長く情報資源データベースに留まるようにしている。逆に、否定的な評価を受け取ったエージェントは、その情報の生存期間を短縮し、検索によって見つけられにくくする。
従って、各エージェントは、近隣のエージェントとの通信だけで済み、更に広告や検索依頼によって特定される情報のみを伝達する為、通信コストを低く押さえることが可能となる。また、利用者の使用実績をデータベース内の生き残り時間という形で反映し、頻繁に利用され好評を博する情報資源に関する広告は、そうでないものよりも長時間データベースに存在し、また広範囲のエージェントに伝播される為、別の利用者が検索する際に発見されやすくなる。
更に本発明の変更態様として、図１にて説明した構成に加えて図２３に示すように履歴データベース（５）  を設ける構成を考案した。この履歴データベース（５）は、広告処理部（１）  、問い合わせ処理部（２）  およびエージェントインターフェース（３）  を通じて、転送されてきた広告情報、検索要求および検索結果が、いつ、どこから（  どこを通って）  転送されてきたか、どのような内容を含んでいるかを記録するデータベースである。
情報資源データ制御部（６）  は、広告処理部（１）  やエージェントインターフェース（３）  から受け取った広告に対して、情報資源データベース（４）  に保管、履歴データベース（５）  を更新したり、履歴の内容に応じて、エージェントインターフェース（３）  を通じて、他のエージェントに送付するなどの処理を指示する。また、問い合わせ処理部（２）  やエージェントインターフェース（３）  からの問い合わせに対しては、情報資源データベース（４）  を検索し、履歴データベース（５）  を更新し、その内容に応じて、エージェントインターフェース（３）  を通じて他のエージェントへ問い合わせを回送するなどの処理を行うものである。エージェントインターフェース（３）  を通じて得られる検索結果を基に、資源情報データベース（４）  を更新するのも、情報資源データ制御部（６）  の指示によって行われる。その際に、履歴データベース（５）  を更新するのも、広告・検索要求の場合と同様である。
システム全体における、このような広告・検索要求・検索結果のデータの授受を模式的に表したものが、それぞれ図２４、図２５、図２６である。図中の○がエージェントを表し、そのそれぞれが図２３の構成を有して、上述した動作を行う。また、図中のエージェント間の実線は、互いのエージェントが近隣関係にあることを表している。ここで言う「エージェントが近隣関係にある」ということは論理的に近隣関係にあるということで、エージェントが互いの位置情報を知り、直接に通信を行うことができることを意味している。従って必ずしも、地理的あるいはハードウェア的な（物理的な）近さを反映するものではない。また、近隣関係がないからといって、通信ができないことを意味するのではない。
この構成においては、図２４のように、前節で述べた構成を持つ複数のエージェントが、相互に連結したインフラを構成し、情報資源提供者が自分の提供できるサービスに関する情報を、広告という形式で、最寄りのエージェントに知らせる。広告を受け取ったエージェントは、その広告に記載されている内容を情報資源データベースに蓄え、近隣のエージェントにも同様の広告を行う。こうして、資源情報がエージェントに徐々に伝達されていく。
一方、利用者からの問い合わせが発生した場合は、広告と同様に、近隣のエージェントに検索要求を伝達していき（  図２５）  、該当するデータを持つエージェントに問い合わせが到達した時点で、そのエージェントは結果を利用者に返送する。結果を返送する際には、問い合わせが経由してきたエージェントを逆に辿り、各エージェントにその結果を蓄えさせるようにして、最初に情報資源提供者が広告した範囲外にも、広告が伝播されるようにする（  第２６）  。
情報資源の広告情報、検索要求および検索結果の転送先のエージェントは、システム導入時に、エージェントの管理者が設定するのであるが、ある程度運用
を続けていくと、広告情報、検索要求および検索結果の履歴が蓄積されてくる。
その情報から、「エージェントＡから来る広告情報は、Ｆという分野に関するものが多い」、「エージェントＢからの検索要求は、Ｆという分野に関するものが多い」、あるいは「エージェントＣからの検索結果は、Ｆという分野に関するものが多い」といったエージェントの扱っている資源情報の傾向が見て取れるようになる。
このような情報を利用し、あるエージェントからＦという分野に関する情報の検索要求が来た場合には、優先的にエージェントＡまたはＣに近い近隣エージェントに検索要求を送付したり、あるいは直接エージェントＡまたはＣに送付することにより、求める情報資源が発見しやすくなることが期待できる。
逆に、Ｆという分野に関する広告が来た場合には、Ｆに対する需要の高いエージェントに近い方へと、広告情報を伝達しておけば、その地域の利用者は、Ｆに関する情報を発見しやすくなることが期待できる。同時に、広告情報の配布に関しては、需要の高いものを即時に伝達し、そうでないものを、ネットワークトラフィックの少ない時間帯に伝達を行うようにすることで、ネットワークトラフィックの集中やエージェントの過負荷を防ぐことが可能である。
また、履歴情報として、エージェントのレスポンス時間に関する情報も記録することにすると、ごく最近に、ネットワークの不通やエージェントのダウンという状況があったなら、それに該当するエージェントへの情報伝達を、一時的にストップさせ、他のエージェントに送るようにすることで、エージェントネットワークの障害が一部にあったとしても、全体として、情報探索機能を滞りなく提供することが可能となる。
【発明の実施の形態】
［第一の実施形態］
図５は本発明の一実施例構成図であり、情報資源情報の分散管理と検索機能を持つ情報資源発見装置を示している。図中、図１で示したものには同一の番号を付与してある（  図１１および図１３中の番号は、データフローの順番を表すもので、それとは無関係である）  。
通常の動作は、情報資源提供者（  プロデューサ）  が、あらかじめ、プロデューサインターフェース（６）  を通して、自分の提供するサービスに関する情報を最寄りのエージェントに広告という形で伝える（  広告依頼）  。広告の具体的な形式は、図６のように、次のような項目とそれに対応する情報の組からなるものとすればよい（＊を付けた項目は、広告処理部（１）  が自動的に付与する情報であり、情報資源提供者が指定しなくてもよい）  。
ＩＤ（＊）：  広告を識別する記号。
Ｆｒｏｍ（＊）：  広告の発送者を特定する情報。例えば、メールアドレス。情報の利用者からの問い合わせに利用したり、広告内容の改竄を防止するための認照用のデータとして利用。
Ｓｕｂｊｅｃｔ：  提供する情報資源の名称。
Ｋｅｙｗｏｒｄｓ：  提供する情報あるいはサービスに関係するキーワード。
ＵＲＬ：  提供する情報の位置情報。位置情報を検索するので、このようなフィールドを設けているが、他の検索対象にしたい情報を記述するフィールドとしてもよい。
Ｍａｉｎｔａｉｎｅｒ：  情報資源の管理者を特定する情報。広告の発送者と同じでも構わない。
Ｃｏｓｔ：  広告範囲を限定するパラメータ。経由するエージェントの最大数、あるいは広告に費やす時間など。通信や計算機の使用に関して課金システムが導入されているのなら、その金額でもよい。
Ｄａｔｅ（＊）：  エージェントが広告を受け取った日時。
Ｐａｔｈ（＊）：  広告が中継されたエージェントのＩＤの列。ひとつの広告が同じエージェントに何度も伝達されるのを防ぐのが目的である。
プロデューサインターフェース（６）  は、その広告を、エージェントの広告処理部（１）  に伝える。そして、広告の内容を解析し、上記の＊  を付けたフィールドを補足し、広告内容を情報資源データ制御部（５）  に渡す。ここで、広告の生存期間を決定し、広告の内容は情報資源データベース（４）  に蓄えられる。情報資源データ制御部（５）  はクロック（８）  を参照しており、既に生存期間を過ぎた広告を情報資源データベース（４）  から削除する。また、情報資源データ制御部（５）  では、広告に要したコストの計算も行い、使用可能コストにまだ余裕のある時には、エージェントインターフェース（３）  を通じて他のエージェントに広告の伝達を行う。
コストとしては、広告を依頼してから広告を終了するまでの時間や、通信費用やデータベースを利用するために必要な費用などを挙げることができる。
特に、コストを無制限にすることによって、広告範囲を限定しない従来のブロードキャストを実現することも可能である。この一連の処理フローが図７である。図中の（６ａ）はプロデューサインターフェース（６）  、（１ａ）は広告処理部（１）  、（５ａ）から（５ｃ）は情報資源データ制御部（５）  、（３ｃ）はエージェントインターフェース（３）  の動作に、それぞれ対応する。
一方、情報検索者（  サーチャ）  は、サーチャインターフェース（７）  を通じて、問い合わせ処理部（２）  へと検索要求を出す（  検索依頼）  。検索要求の具体的な形式は、図８のように、広告の形式と同様の形式からなり、各項目のうち、既に分かっている項目を適当に埋め、検索によって知りたい項目を空けておいたものとすればよい（＊の付けられた項目の取り扱いに関しては、広告と同様に、検索者が付けるのではなく、問い合わせ処理部（２）  が自動的に補う）  。これにより行われる検索として、例えば、次のような検索の仕方が考えられる。
１．Ｋｅｙｗｏｒｄｓをいくつか指定し、それ以外の項目を空けておき、指定したキーワードに関連を持つ情報資源の名称や  ＵＲＬ  を検索する。
２．実際にサービスが行われているか否か、あるいは、サービスの内容を調べるために、ＵＲＬ  を指定し、その他の項目を空けておき、Ｓｕｂｊｅｃｔ  やＫｅｙｗｏｒｄｓを検索する。
３．同じ資源を提供している者同士での連携を図るために、Ｓｕｂｊｅｃｔ  やＫｅｙｗｏｒｄｓを指定し、Ｍａｉｎｔａｉｎｅｒを空けておき、関係しそうな情報資源の管理をしている人を検索する。逆にＭａｉｎｔａｉｎｅｒを指定し、その人が管理している情報資源を検索する。
検索要求を受け取った問い合わせ処理部（２）  は、情報資源データ制御部（５）  に検索依頼を送り、情報資源データ制御部（５）  は、その依頼を解析し、それをもとに情報資源データベース（４）  を検索する。該当する結果が見つかれば、その結果を問い合わせ処理部（２）  とサーチャインターフェース（７）  を通じて検索の依頼主に返送される（  検索結果）  。この時も広告の場合と同様に、情報資源データ制御部（５）  において、コストの計算を行い、使用可能コストに余裕がある場合には、エージェントインターフェース（３）  を通じて、他のエージェントへ検索を依頼し、その結果を集めて、情報検索者のもとへ返送する。検索結果は、広告の形式と同様で、検索要求のうち検索の対象となっている項目を該当するデータを補ったものである。コストに関しては、上記で述べた情報資源の広告で触れたように、時間や費用などを考えることができる。また、コストを無制限にすることによって、検索範囲を限定せずにすべてのエージェントに検索を依頼することもでき、逆に最小にすることで、ただひとつのエージェントのみを検索の対象にすることもできる。この一連の処理フローが図９である。図中の（７ａ）はサーチャインターフェース（７）  、（２ａ）および（２ｂ）は問い合わせ処理部（２）  、（３ｂ）はエージェントインターフェース（３）  、（５ｄ）から（５ｉ）は情報資源データ制御部（５）  の動作に、それぞれ対応する。
［第二の実施形態］
図１１は、大規模分散データベースへの実施例であり、請求項４  に対応する。利用者は、検索したい情報のキーワードをデータベース検索フロントエンド（９）  に与え、データベース検索フロントエンド（９）  は、まずそのキーワードに関する情報を持つデータベースサーバの位置情報を、最寄りのエージェントにサーチャインターフェース（７）  を通じて尋ねる。検索依頼を受けたエージェントは、最初に述べた実施例の動作に従い、検索を実行する。その際、各エージェントが、他のエージェントから返送されてくる検索結果を、自分の情報資源データベース（４）  の該当するデータとを比較し、もし検索結果の方が新しいデータであるならば、情報資源データベース（４）  のデータを新しいデータに書換えることで、請求項４  を実現することができる。そうして、データベースサーバの位置情報が得られたならば、データベース検索フロントエンド（９）  は、得られた結果から、適切なサーバをいくつか選び、それらのデータベースサーバにキーワードを転送し、データベースの検索を実行させる。最後にデータベースサーバからの検索結果を統合し、利用者に返送する。この一連の動作を模式的に説明した図が図１２である。
［第三の実施形態］
図１３は、別の大規模分散データベースへの実施例である。
第２の実施形態は、本発明によりデータベースサーバの位置情報が判明した後に、検索を実行する方式であったが、この実施例は、データベースサーバの位置情報の検索と、発見されたデータベースサーバに対するデータベース検索を並行して行う方式である。
データベースサーバの管理者が、あらかじめデータベースサーバの広告をしておくのは、前節と同様である。情報検索を行う人は、サーチャインターフェース（７）  を通じて、データベースの検索を依頼する。その依頼は問い合わせ処理（２）  によって、適切な形式に整形され、情報資源データ制御部（５）  に渡される。
情報資源データ制御部（５）  は、情報資源データベース（４）  を検索し、検索に応じられるデータベースサーバの位置情報を探す。もし、該当するデータベースサーバに関する情報が発見できたなら、データベースインターフェース（１０）を通して、データベースサーバに検索を実行させる。使用可能コストに余裕があれば、更にエージェントインターフェース（３）  を通じて、他のエージェントにも検索依頼を発行し、検索結果を返送するようにしてもらう。一方、先程検索を依頼したデータベースサーバから結果が返送されてきたならば、その結果を一時的に蓄えておき、他のエージェントからの結果が揃うまで、待機する。すべての検索結果が返送されてきたならば、それらを統合して、検索依頼元に送り返す。この一連の動作を模式的に説明した図が図１４である。
この方式では、あるデータベースサーバに複数のエージェントから同じ検索依頼を受ける可能性があるが、あらかじめ検索依頼にＩＤを付与し、データベースサーバは、検索履歴をそのＩＤと共に記憶しておき、重複した検索依頼には、「既に回答済み」と依頼元に返答するなど、同じ検索を何度も行うのを避ける機能を有することが望ましい。
［第四の実施形態］
以上の実施例では、エージェントから得られた情報資源に関する情報は基本的に情報資源提供者側から一方的に与えられるものであるが、図１５の実施例のように、検索の結果として得られた情報資源を実際に使用し、その善し悪しなどの情報をエージェントにフィードバックしてもよい。そうすることで、すべての利用者が効果的に情報資源を利用することが可能となる。例えば、実際に情報資源を使用する際、すでに使用不可能になっていることが判明した情報資源に関しては、各エージェントの情報資源データベースから、該当する情報資源を削除するように広告を行い、他の利用者がその無効な情報資源を利用しようとしないようにする。また、利用者の希望によく叶うものであったならば、生存期間を延長するようなデータ制御のための広告を行い、他の利用者もその情報資源に関する情報を容易に発見しやすいようにする。この実施例は、請求項５  に対応する。
情報資源の評価に関するフィードバック情報は、サーチャインターフェース（７）  を通じて、フィードバック処理部（１１）に渡される。そして、そこで適切な形式に変換され、他のエージェントにも伝播すべく、広告を行うために、情報資源データ制御部（５）  に渡される。広告を受け取った情報資源データ制御部（５）  は、情報資源データベース（４）  中の該当する情報資源のエントリの生存期間を評価に応じて更新し通常の広告と同様にコストに余裕のある限り、他のエージェントへエージェントインターフェース（３）  を通じて、評価を伝達していく。フィードバック処理部（１１）の処理フローは、図１６である。
この図では、利用者からの評価を、＋（満足）  、  （不満）  、＊（使用不能）  の３  段階と仮定している。そして、そのそれぞれの評価に対して、データベース中の該当する情報資源のエントリの生存期間の延長、短縮、削除を要求する広告を行うように情報資源データ制御部（５）  に命令する。
上記の実施例では、情報資源の善し悪しを計る目安として、情報資源データベース内での広告の生存期間を採用していたが、生存期間とは別に、利用されている回数や、一番新しいものなど、他の評価基準で優先順位を付け、ソートし、検索結果を返送してもよい。その場合には、まず、情報資源提供者が広告を行い、各エージェント内の情報資源データベース（４）  に情報資源に関する情報を記録する際に、情報資源に関する評価という属性もデータベースに記録しておく必要がある。同じ情報資源に関する情報が、複数のエージェントからそれぞれ異なる評価値と共に返送されてくる場合には、平均をとるなどして、エージェント組織全体としての評価値を計算する。そして、最終的にサーチャインターフェース（７）  は、情報検索者に検索結果をすべて提示するのでなく、検索者の評価基準に照し合わせて順位を付け、最良のものを提示してもよい。
［第五の実施形態］
上記の実施例では、各エージェントが持っている情報資源に関する評価値は情報検索者が検索することによって、集計され、検索者が情報資源を取捨選択するのに利用されているが、評価値の計算は検索とは関係なく独自で行なわれ、情報資源提供者が自分が公開した情報資源の社会的な評価を知るために利用してもよい。
図１７は、情報資源提供者による情報資源の評価値の集計機能付きの情報資源発見方式の構成図である。プロデューサインターフェース（６）  は、情報資源提供者から広告依頼の他に評価依頼を受け付け、評価依頼を受け取った場合には、もし必要ならば、情報資源提供者の認照を行い、評価依頼処理部（１２）にその内容を送る。評価依頼処理部（１２）は、その内容を解析し、情報資源データ制御部（５）  評価要求を送る。情報資源データ制御部（５）  は、情報資源データベース（４）  の該当する情報資源の評価値を検索すると共に、資源情報の広告や検索と同様に、エージェントインターフェース（３）  を通じて、他のエージェントへも評価依頼を送出する。検索の結果返送されてきた評価値は、情報資源データ制御部（５）  に集められ、そこで集計され、評価依頼処理部（１２）およびプロデューサインターフェース（６）  を通じて、情報資源提供者に返送される。
［第六の実施形態］
図１８は、Ｗｅｂ  文書に関する情報の管理・検索を行う、分散型のサーチエンジンの構成を示している。図中、上述の各実施形態と同じ構成要素には同一の番号を付与してある。
なお、本実施形態は技術思想的には第一  第六の実施形態と同様であるが、ベストモードとして開示するものである。
通常の動作は、Ｗｅｂ  文書作成者が、プロデューサインターフェース（６）  を通して、自分が作成した  Ｗｅｂ文書に関する情報を最寄りのエージェントに広告という形で伝える。広告の具体的な形式については、上述の各実施形態と同様である。広告処理部（１）  は、プロデューサインターフェース（６）  から送られてくる  Ｗｅｂ文書に関する広告情報を基に、登録日時、情報の生存期間、広告コスト・評価値の初期値などの情報を付与し、Ｗｅｂ  文書データ制御部（５）  に渡す。Ｗｅｂ  文書データ制御部（５）  は、基本的に情報資源データ制御部と同じであるが、この実施例が対象とする情報資源がＷｅｂ  文書であるので、便宜的にそう名付けた。Ｗｅｂ  文書データベース（４）  も同様の理由で、情報資源データベースのことである。Ｗｅｂ  文書データ制御部（５）  では、上述した各実施形態と同様に、広告で得られた  Ｗｅｂ文書情報をＷｅｂ  文書データベース（４）  に登録し、広告に要したコストの計算を行い、コストに余裕があれば、エージェントインターフェース（３）  を通じて、他のエージェントへ広告を伝達させる。また、クロック（８）  に基づいて、有効期間を過ぎた  Ｗｅｂ文書情報を  Ｗｅｂ文書データベース（４）  から削除する。
また、他のエージェントから広告依頼を受ける場合は、エージェントインターフェース（７）  を通じて、広告依頼が  Ｗｅｂ文書データ制御部（５）  に渡される。
このように、Ｗｅｂ  文書データ制御部（５）  が広告処理部（１）  やエージェントインターフェース（７）  から広告依頼データを受け取ってからの処理フローが図１９である。
一方、Ｗｅｂ  文書閲覧者は、サーチャインターフェース（７）  を通じて、Ｗｅｂ  文書の検索を行う。問い合わせ処理部（２）  は、Ｗｅｂ  文書閲覧者からの入力を基に、検索要求を作成し、それを  Ｗｅｂ文書データ制御部（５）  に送る。検索要求の形式は、図１０で示したようなものである。Ｗｅｂ  文書データ処理部（５）  は、Ｗｅｂ  文書データベース（４）  を検索し、検索要求を満す  Ｗｅｂ文書を検索し、検索結果を保持する。そして、広告の場合と同様に、残りの利用可能コストを計算し、まだ余裕があれば、エージェントインターフェース（３）  を通じて、他のエージェントに検索要求を転送し、検索結果が返送されてくるのを待つ。
検索要求を出したエージェントすべてから検索結果が返送されてくるか、ある一定時間が経過した時点で、集まった検索結果を、問い合わせ処理部（２）  に送り、リストの形式にし、サーチャインターフェース（７）  を通じて、Ｗｅｂ  文書閲覧者に提示する。他のエージェントから検索要求を受け取る場合は、エージェントインターフェース（７）  を通じて、検索要求が  Ｗｅｂ文書データ制御部（５）  に渡され、検索結果は、エージェントインターフェース（７）  を通じて、依頼元のエージェントへと返送される。
Ｗｅｂ  文書データ処理部（５）  が問い合わせ処理部（２）  やエージェントインターフェース（７）  から検索依頼を受け取ってからの処理フローが図２０である。
Ｗｅｂ  文書閲覧者から、直接検索要求を受け取ったエージェントは、検索結果をＷｅｂ  文書閲覧者に提示し、こうして得られた検索結果を基に、Ｗｅｂ  文書閲覧者は、サーチャインターフェース（７）  を通じて、実際に検索結果に示された  Ｗｅｂ文書にアクセスする。そして、閲覧者に  Ｗｅｂ文書が閲覧者の要求を満たしているか否かの評価を行ってもらう。評価は、サーチャインターフェース（７）  が自動的に行う場合もある。実際の  Ｗｅｂ文書が存在していないとか、何等かの理由で利用できないという状態は好ましくないので、それを負の評価として自動的に収集することが可能である。この時のサーチャインターフェース（７）  の処理フローが図２１である。
［第七の実施形態］
Ｗｅｂ  文書の収集は、Ｗｅｂ  文書作成者からの広告ばかりでなく、既存のサーチエンジンが持つ  Ｗｅｂ文書情報を利用することも可能である。エージェントは、サーチエンジンのラッパーの役割を果し、相互に  Ｗｅｂ文書に関する情報をやりとりする利用形態も考えられる。こうすることで、既存のサーチエンジンを連携・統合し、すべてのサーチエンジンを統一的に利用することが可能となる。
図２２は、このように既存サーチエンジンを利用した分散型サーチエンジンの構成図である。前項の分散型サーチエンジンとほぼ同じであるが、サーチエンジンインターフェース（１３）を持ち、既存のサーチエンジンから  Ｗｅｂ文書情報を得ることができる点が異なる。
このサーチエンジンインターフェース（１３）は、検索要求に含まれるキーワードを抽出して、既存のサーチエンジンを用いて検索を行い、得られたＷｅｂ  文書をｗｅｂ文書データ制御部からサーチャインターフェースを介して、情報検索者に提示するものである。
またＷｅｂ  文書データベース（４）  は、既存のサーチエンジンの  Ｗｅｂ文書情報をキャッシュし、Ｗｅｂ  文書に関する評価情報のデータベースとして機能する。Ｗｅｂ  文書を解析して上述したような広告情報のフォ−マットでＷｅｂ  文書に対応する広告情報を作成し、Ｗｅｂ  文書データベース（４）  に保存を行う。
広告依頼に対する基本的な動作は前項と同じであるが、検索要求に対する動作は、既存サーチエンジンの利用形態に応じて、いくつか考えられる。
・主に既存サーチエンジンを  Ｗｅｂ文書データベースとし、Ｗｅｂ  文書データベース（４）  を、Ｗｅｂ  文書に対する評価情報を蓄えるデータベースとして利用する形態。検索要求に対して、サーチエンジンインターフェース（１３）を通して、サーチ    エンジンを検索し、得られた結果中の各  Ｗｅｂ文書に対して、Ｗｅｂ  文書データベース（４）  を調べ、評価情報を付与し、エージェントまたは  Ｗｅｂ文書閲覧者へと返送する。
・主に  Ｗｅｂ文書データベース（４）  を利用するが、検索結果が十分に得られない場合に、既存サーチエンジンを補助的に利用する形態。
検索要求に対して、まず  Ｗｅｂ文書データベース（４）  を検索し、検索要求に見合う結果が得られない、あるいは、十分な個数の  Ｗｅｂ文書情報が得られなかった場合に、サーチエンジンインターフェース（１３）を通じて、既存のサーチエンジンを利用して検索を行う。そして、その結果を  Ｗｅｂ文書閲覧者に提示すると共に、Ｗｅｂ  文書データベース（４）  に登録し、次回の検索に備える。
・文書データベース（４）  の管理・維持のために、既存サーチエンジンを利用する形態。
検索要求に対して、通常のように  Ｗｅｂ文書データベース（４）  を利用して、検索を行う。それと同時に、検索要求の履歴を蓄えておき、ある一定時間ごとに、検索要求の履歴をもとに、サーチエンジンインターフェース（１３）を通して、サーチエンジンを検索し、その結果を基に  Ｗｅｂ文書データベース（４）  を更新する。
以上説明したように、本発明によれば、情報資源に関する情報の管理を人手に頼らずに自動的行うことができ、資源情報の管理者は情報の登録や維持に手間を割く必要がなくなる。おまけに、本発明は、従来のディレクトリサービスと同様に、基本的には情報資源提供者の申告に基づくため、ディレクトリサービスの利点であった情報の質を損うことはない。
また、資源情報は分散管理され、各エージェント間の結合に冗長性を持たせることで、ネットワーク環境の変化に対して頑健で検索の負荷分散や検索者のアクセスのしやすさを向上させることができ、広告および検索に利用できるコストを制限することで、資源情報を広告するエージェントの範囲と検索対象とするエージェントの範囲を限定することができるため、全体の通信量を低く抑えることができる。そして、ロボットプログラムのような情報資源のサーバへの無用なアクセスを行わずに済むため、サーバへの高負荷を生むこともない。更に、情報資源提供者は常に最寄りのエージェントへアクセスし、資源情報の更新を行うことができ、一方では、情報資源検索者による情報資源の利用可能性についてのフィードバックがかかり、他のエージェントにも即座に更新情報が伝わるため、資源情報の陳腐化現象を起りにくくする効果が期待できる。
情報資源検索者による情報資源の評価のフィードバックは、各エージェント上での資源情報の生存期間を調節することで、有益な情報資源に関する情報は発見されやすく、そうでないものに関する資源情報は発見されにくくなり、検索結果として得られる資源情報は、多数の検索者のフィードバックに基づく全体的な評価に基づいて順位付けられるので、数多くある情報資源を取捨選択するだけの知識や技量を持たない情報資源検索者にとっても、より良い情報資源を発見・選択・利用しやすくなるという効果が期待できる。そのため、本発明は、大規模な資源情報の効率的な分散管理および検索に寄与するところが大きい。
［第八の実施形態］
図２７は本実施形態に関する構成図であり、情報資源情報の分散管理と検索機能を持つ情報資源発見装置を示している。図中、図２３で示したものには同一の番号を付与してある。
まず広告依頼の処理を図２８のフローチャートに基づいて説明する。通常の動作は、情報資源提供者（  プロデューサ）  が、プロデューサインターフェース（６）  を通して、自分の提供するサービスに関する情報を最寄りのエージェントに広告という形で伝える（  広告依頼）  。広告の具体的な内容は、提供する情報資源の  ＵＲＬ、名称、内容を表すキーワード、管理者名などである。プロデューサインターフェース（６）  は、その広告を、エージェントの広告処理部（１）  に伝える。そして、広告の内容を解析し、必要な情報が落ちていないか（  例えば、情報資源の  ＵＲＬや、関連キーワードなど）  、不正なデータが記載されていないか（  例えば、妥当な形式の  ＵＲＬか否か、漢字コードは正常か）  等をチェックし、広告内容を情報資源データ制御部（５）  に渡す。ここで、この広告内容に基づいて、履歴データベース（１４）を更新し、広告の内容は情報資源データベース（４）  に蓄えられる。履歴データベース（１４）の具体的な形式については、後で述べる。
また、情報資源の広告情報は、エージェントインターフェース（３）  を通じて、あらかじめエージェントの管理者が決めておくエージェントに伝達することもできる。広告情報を受け取るエージェントでは、やはりエージェントインターフェース（３）  から広告情報を貰い、情報資源データ制御部（５）  に渡し、先程と同様に、履歴データベース（１４）を更新し、情報資源データベース（４）  を更新する。
一方、情報資源の検索要求の処理は図２９の処理フローチャートに示すように、情報検索者からサーチャインターフェース（７）  を通じて、問い合わせ処理部（２）  へと送られる。そこで、検索要求に関して、必要なデータが落ちていないか（  例えば、検索キーワードとか、結果をメールで返送するのならメールアドレスなど）  、不正なデータが含まれていないか（  例えば、メールアドレスが妥当な形式であるか否か）  などをチェックする。
検索要求を受け取った問い合わせ処理部（２）  は、情報資源データ制御部（５）  に検索依頼を送り、情報資源データ制御部（５）  はその依頼を解析し、それを基に履歴データベース（１４）を更新する。そして情報資源データベース（５）  を検索し、その結果を問い合わせ処理部（２）  とサーチャインターフェース（７）  を通じて検索の依頼主に返送される。
また、検索の場合も広告の場合と同様に、エージェントインターフェース（３）  を通じて、エージェント管理者が定める近隣エージェントへ検索を依頼し、その結果を集めて、情報検索者のもとへ返送することもできる。この場合は、検索要求を転送したエージェントからの検索結果がすべて揃うまで、ある一定時間待ち続ける。検索結果が、エージェントインターフェース（３）  から、情報資源データ制御部（５）  へと送られると、検索結果の内容を解析し（  例えば、通信の過程でデータが壊れていないかどうか）  、どの検索要求に対する検索結果であるのかをチェックする。もし、その検索要求に対する結果を、まだ依頼主（  検索者あるいは別のエージェント）  に返送していないのなら、依頼主に返送するために、検索結果を蓄えている返送用バッファに結果を追加する。そして、検索結果を履歴データベース（５）  に登録し、情報資源データベース（４）  の内容を更新する。この検索結果に対する一連の処理フローが図３０である。こうして、検索要求を送付したエージェントすべてから結果が返送されるか、クロック（８）  を参照して、タイムアウトになるまで待ち続け、返送用バッファの中身を、依頼主に返送する。
履歴データベースの具体的な形式の例は、図３１に示すように、広告情報、検索要求および検索結果を受け取った時刻、それらの  ＩＤ  、関連キーワード、送付元の組からなる。
ＩＤは受け取った情報を識別するためのもので、「Ｒ２３６６６６  ＠Ａ３」のような形式である。先頭の文字は、広告情報、検索要求、検索結果かを示すもので、それぞれ「Ｐ  」、「Ｑ  」、「Ｒ  」である。その後に続く数字列は、情報を区別するために、時刻やプロセス番号などから作った一意的な数字列である。「＠」より後はエージェントの  ＩＤ  である。
次にキーワードの列は、広告情報の場合は情報資源の関連キーワード、検索要求の場合は検索キーワード、検索結果の場合は検索結果として得られている情報資源（  一般に複数ある）  のすべての関連キーワードである。
最後の送付元エージェントは、どのエージェントが、その情報を直接送ってきたかを示す。このデータベースによって、どこのエージェントからは、どのような種類の情報資源に関する情報が集まっているか、または、どのような種類の情報資源の需要が高いのかを知ることが可能となる。
［第九の実施形態］
図３２は、広告情報のスプールを持つ分散検索装置の実施形態である。利用者にとって、検索は、結果が得られるのが早ければ早いほど喜ばしいことであるが、広告処理は、必ずしもそうであるとは限らない。検索処理を行っている時に、広告依頼を受理したからといって、その場ですぐに広告処理を行って、検索処理のパーフォーマンスを犠牲にする必要はなく、後回しにした方が望ましいことがある。実際、ほとんど誰も検索したことのないような情報資源に関する広告は、すぐに他のエージェントに広告を行ったところで、誰からも参照されないかもしれず、急いで広告を行っても、利用者にとってメリットはないかもしれない。これに対し、多くの利用者から、何度も検索されているような分野に属する情報資源ならば、すぐにでも利用者は知りたがるであろうから、急いで広告することに意義がある。本実施形態の構成はそのような目的で、急いで広告する必要がない広告情報に関しては、一旦広告情報スプール（１０）に蓄え、バッチ的に広告処理を行うものである。
本実施形態での一連の処理フローを図３３に示す。広告情報を受け取った情報資源データ制御部（５）  は、広告情報に含まれる情報資源の関連キーワードあるいはその同義語やそれらに関連する単語を使用している検索要求を履歴データベースから検索する。そして、その結果から優先度を決定する。例えば、履歴データベース（５）  を検索して得られる検索要求の数としてもよい。その優先度がある閾値よりも大きければ、すぐに広告処理を行い、そうでなければ一旦広告情報スプール（１５）に蓄える。そして、エージェントが暇になった時点、または広告情報スプール（１５）が一杯になった時点、あるいは、ある一定時間おきに、広告情報スプール（１５）の中の広告情報の処理を始める。この時も、優先度の高い順に処理を行う。
本装置の起動直後では、履歴がないので優先度は特に決められない。そこで最初はエージェントの管理者が優先度を決めておいても構わない。また、それ以後も、管理者の定める優先度と履歴によって決まる優先度を組合わせて利用しても構わない。
［第十の実施形態］
この実施形態は、履歴データベース（１４）に経路情報も記録し、広告や検索要求のより効果的な配送を行うことを目的とする。構成図は図２７と同じであるが、図２７における履歴データベース（１４）の形式は、図３４のように、履歴データベース（１４）の転送元エージェントの代わりに、情報がどのエージェントを経由してきたを示す転送経路を記録する。転送経路に関する情報は、広告情報、検索要求や検索結果が同じエージェントを何度も中継されるのを防ぐために、やりとりされる情報の中に通ってきたエージェントの  ＩＤ  を保持しているので（  メールやネットニュースのＰａｔｈフィールドと同様）  、そこから抽出することが可能である。それらの情報を受け取ったエージェントは、その経路情報を、履歴データベース（１４）に記録しておく。キーワードは、広告および検索結果の場合、対象となる情報資源の関連キーワードの組であり、検索要求の場合には、検索語として指定されたキーワードの組である。また、転送経路は、広告情報、検索要求あるいは検索結果が経由されてきたエージェントの列である。例えば、「Ａ１：Ａ２：Ａ３」はデータがエージェントＡ３からエージェントＡ２を経由してエージェントＡ１まで伝達されてきたことを示す。
例えば、図３４の例では、キーワードｋｗ１  に関係する情報資源の広告情報は、エージェントＡ３から多く広告されていることが分かり（  図３４中、白い丸印を付けた部分が該当。なお、図３４中の丸印は説明のために記入したものであって、実際にデータベースに記録される情報では無い）、ｋｗ１  に関する資源情報は、Ａ３の付近に集中している可能性が高い。したがって、ｋｗ１  に関する検索要求を受け取った場合に、近隣関係にはないエージェントＡ３に直接転送すると、多くの検索結果を得やすい。
逆に、エージェントＡ７からは、ｋｗ１  に関する検索要求が多いことが分かり（  黒い丸印を付けた部分が該当）  、ｋｗ１  に関する情報資源に関する広告をＡ７に直接転送すると、Ａ７からの検索が効果的に行うことが可能となる。このような考察に基づいて、情報資源データ制御部（６）  は、随時履歴データベース（５）  を参照し、広告情報や検索要求の内容に応じて、適切なエージェントを決定し、そこへ広告情報や検索要求の転送を行う。
［第十一の実施形態］
第十の実施形態のような履歴データベース（  図３４）  を採用している分散検索装置において、更に図３５のように、エージェントステイトテーブル（１６）を設ける。エージェントステイトテーブル（１６）は、広告情報、検索要求や検索結果を他のエージェントに転送する際に要したレスポンス時間のテーブルである。図３６はそのテーブルの例である。テーブルの各列は、エージェントＩＤ、そのエージェントに対する応答時間、最後に応答時間を計測した時刻を示す最終チェック時刻の３  項からなる。応答時間において、「−−−−−−」は、正常に通信ができなかったことを示す。
この実施形態においては、近隣のエージェントに広告依頼を送る際に、ネットワークの障害など何らかの理由によって、近隣エージェントに広告依頼を転送できなかった場合に、代わりに最寄りエージェントに広告依頼を送ることを目的としている。通常の広告依頼の処理を行い、近隣のエージェントに広告依頼を送る。そして、その時の応答時間を計測し、エージェントステイトテーブル（１６）を更新する。もし、近隣エージェントに広告依頼を送れなかった場合には（  送れなかったエージェントをＡとする）  、まず図３４に示したような履歴データベース（１４）を検索し、Ａの近隣エージェントを検索する。そして、図３６のようなエージェントステイトテーブル（１６）を調べ、Ａの近隣エージェントから最も応答の早いエージェントＢを選択し、そこに広告依頼を転送する。こうすることで、処理を行えない状態のエージェントを回避し、システム全体として、広告処理を続行させることが可能となる。検索要求の場合にも、同様の手順により、障害を回避し、システム全体として、検索を行うことができる。
つまり図３７に示すように、過去においてエージェントＡからＢを経由してきた広告依頼、検索要求または検索結果を受理したことがあれば、Ａの近隣にＢがいることを知ることができ、Ａに障害が起きても、直接Ｂに送ることが可能となる。
この一連の処理フローが、図３８である。
［第十二の実施形態］
図３９は、一旦スプールに入れられた広告依頼を、近隣エージェントに送付する際に、履歴データベース（１４）を参照し、ネットワークのトラフィックやエージェントの負荷が比較的低い時間帯を選んで、転送を行うようにスケジューリングを行う分散検索装置の構成図である。
図４０は、この実施例のためのエージェントステイトテーブル（１６）の例である。このテーブルは、実施形態十一でのエージェントステイトテーブルの例（  図３６）とは違い、各時間帯毎の平均応答時間と実際に計測を行った回数の情報を保持する。これらの情報は、おもにリアルタイムに行われる検索要求や検索結果の返送処理の際に要した時間を基に更新される。この例では、平均応答時間と計測回数のみをテーブルに記録しているが、実施形態十一のテーブル（  図３６）のように最終チェック時刻やその時の状態に関する情報などを含めてもよい。
広告依頼を受け取った場合の動作は、実施形態九のように、優先度の高くない広告情報を、一旦広告情報スプール（１５）に蓄える。その際に、広告スケジューラ（１７）により、どの時間帯にどのエージェントに広告情報を伝達するかを規定する、広告配送スケジュールが作成される。例えば、図４０において、エージェントＡ１に送らなければならない広告情報は、優先度が非常に低い場合には、Ａ１の処理が最も少ないと予想される  ０１：００から０１：５９  の時間帯に転送を行うようにし、優先度がやや高いと思われるものは、ある程度応答時間が大きい時間帯でも、なるべく早い時間に転送を行うようにする。そして、その広告配送スケジュールに応じて、指定されたエージェントに対して広告情報の配送を行う。
［第十三の実施形態］
図４２は、コストを用いて、広告依頼などの情報の配布範囲を限定した分散検索検索方式において、履歴データベース（１４）に記録されている過去の広告および検索の実績に応じて、各近隣エージェントに送る情報の転送に費やすコストを分配する機能を持つ分散検索装置の構成図である。
広告依頼を受け取った場合の動作は、通常の広告依頼の処理を行い、他のエージェントに広告依頼を転送する際に、履歴データベース（１４）を検索して、過去においてどのエージェントから、その広告に見合う検索要求が多く転送されてきたかを調べる。検索要求が沢山送られてきた方のエージェント群では、その情報に関する需要が多いと見ることができ、その方向に沢山のコストを費やして、広告を行っておけば、需要の高い地域のすぐ近くまで広告情報が行き渡り、次回検索要求が発生する時に、少ないコストで資源情報が発見する可能性が高いであろう。このような、近隣エージェントに対する、広告依頼のコスト配分を行うのが、コストマネージャ（１８）の役割である。
逆に、検索要求が転送されてきた場合で、他のエージェントに検索要求を転送する場合には、広告依頼および検索結果が転送されてきた方向に、該当する資源情報が多いと考えられるため、その方向に沢山のコストを費やして検索を行えば、多くの検索結果を得ることができ、それだけ良い資源情報を発見することが可能と考えられる。
図４２は、コストの分配の例である。過去において、あるキーワードに関する広告依頼を、近隣エージェントＡ  、  Ｂ、  Ｃから、それぞれ、２：５：３  の比率で受け取っていたならば、当然Ｂ  の方向には、そのキーワードに関する情報が多いと思われる。そこでＢ  を検索するコストを多くした方が、よい検索結果が得られると期待される。そこで本実施形態では、前記の２：５：３  の比率で検索コストを分配し、それぞれの近隣エージェントへ検索要求を転送する。なお、この比率は必ずしも比例させる必要は無く、ある程度の重み付けをするように構成しても良い。
【発明の効果】
以上説明したように、本発明によれば、情報資源に関する情報の管理を人手に頼らずに自動的行うことができ、資源情報の管理者は情報の登録や維持に手間を割く必要がなくなる。おまけに、本発明は、従来のディレクトリサービスと同様に、基本的には情報資源提供者の申告に基づくため、ディレクトリサービスの利点であった情報の質を損うことはない。
また、資源情報は分散管理され、各エージェント間の結合に冗長性を持たせることで、ネットワーク環境の変化に対して頑健で検索の負荷分散や検索者のアクセスのしやすさを向上させることができ、広告および検索に利用できるコストを制限することで、資源情報を広告するエージェントの範囲と検索対象とするエージェントの範囲を限定することができるため、全体の通信量を低く抑えることができる。そして、ロボットプログラムのような情報資源のサーバへの無用なアクセスを行わずに済むため、サーバへの高負荷を生むこともない。更に、情報資源提供者は常に最寄りのエージェントへアクセスし、資源情報の更新を行うことができ、一方では、情報資源検索者による情報資源の利用可能性についてのフィードバックがかかり、他のエージェントにも即座に更新情報が伝わるため、資源情報の陳腐化現象を起りにくくする効果が期待できる。
情報資源検索者による情報資源の評価のフィードバックは、各エージェント上での資源情報の生存期間を調節することで、有益な情報資源に関する情報は発見されやすく、そうでないものに関する資源情報は発見されにくくなり、検索結果として得られる資源情報は、多数の検索者のフィードバックに基づく全体的な評価に基づいて順位付けられるので、数多くある情報資源を取捨選択するだけの知識や技量を持たない情報資源検索者にとっても、より良い情報資源を発見・選択・利用しやすくなるという効果が期待できる。そのため、本発明は、大規模な資源情報の効率的な分散管理および検索に寄与するところが大きい。
更に資源情報の分散検索システムにおいて広告情報、検索要求や検索結果に関する履歴を保持、利用する構成を採用することにより、エージェントの負荷の少ない時間帯での広告情報配信、需要の高い地域への情報配信、情報を持っていると思われる地域への優先的な検索、需要とネットワーク環境に応じた広告配信のスケジューリング、過去の検索実績に応じたコスト配分による広告情報および検索要求のルーティングなどが可能となり、省トラフィックおよび効率的な情報配信・情報検索に寄与するところが大きい。
【図面の簡単な説明】
【図１】本発明の分散検索システムにおける検索装置（エージェント）の原理説明図である。
【図２】分散検索システムにおける情報資源の広告と検索に関する説明図である。
【図３】分散検索システムにおける情報資源に関する情報の伝播の説明図である。
【図４】分散検索システムにおける情報資源の評価の伝播に関する説明図である。
【図５】検索装置（エージェント）の実施例の構成を示すブロック図である。
【図６】広告の例を示す図である。
【図７】検索装置（エージェント）における広告の処理を示すフローチャートである。
【図８】検索要求の例を示す図である。
【図９】検索装置（エージェント）における検索の処理を示すフローチャートである。
【図１０】検索結果の例を示す図である。
【図１１】第２の実施形態のの大規模分散データベースにおける検索装置の構成を示すブロック図である。
【図１２】第２の実施形態の大規模分散データベースの動作説明図である。
【図１３】第３の実施形態のの大規模分散データベースにおける検索装置の構成を示すブロック図である。
【図１４】第３の実施形態の大規模分散データベースの動作説明図である。
【図１５】第４の実施形態のの大規模分散データベースにおける検索装置の構成を示すブロック図である。
【図１６】図１５のフィードバック処理部の処理を示すフローチャートである。
【図１７】第５の実施形態の大規模分散データベースにおける検索装置の構成を示すブロック図である。
【図１８】第六の実施形態の大規模分散データベースにおける検索装置の構成を示すブロック図である。
【図１９】第六の実施形態における広告依頼の処理を示すフローチャートである。
【図２０】第六の実施形態における検索要求の処理を示すフローチャートである。
【図２１】第六の実施形態におけるサーチャインターフェースの処理を示すフローチャートである。
【図２２】第七の実施形態における検索装置の構成を示すブロック図である。
【図２３】履歴データベースを付加した検索装置の原理構成図。
【図２４】図２３の分散検索システムにおける情報資源の広告に関する説明図である。
【図２５】図２３の分散検索システムにおける情報資源の検索の説明図である。
【図２６】図２３の分散検索システムにおける情報資源の返送の説明図である。
【図２７】第八の実施形態における検索装置の構成を示すブロック図である。
【図２８】第八の実施形態における広告依頼の処理を示すフローチャートである。
【図２９】第八の実施形態における検索要求の処理を示すフローチャートである。
【図３０】第八の実施形態における検索結果の処理を示すフローチャートである。
【図３１】第八の実施形態における履歴データベースの例を示す図である。
【図３２】第九の実施形態における検索装置の構成を示すブロック図である。
【図３３】第九の実施形態における広告依頼の処理を示すフローチャートである。
【図３４】第十の実施形態における履歴データベースの例を示す図である。
【図３５】第十一の実施形態における検索装置の構成を示すブロック図である。
【図３６】第十一の実施形態におけるエージェントステイトテーブルの例を示す図である。
【図３７】第十一の実施形態における動作の説明図である。
【図３８】第十一の実施形態における代替エージェントの検索による広告依頼の処理を示すフローチャートである。
【図３９】第十二の実施形態における検索装置の構成を示すブロック図である。
【図４０】第十二の実施形態におけるエージェントステイトテーブルの例を示す図である。
【図４１】第十三の実施形態における検索装置の構成を示すブロック図である。
【図４２】第十三の実施形態における動作の説明図である。
【符号の説明】
１  広告処理部、
２  問い合わせ処理部、
３  エージェントインターフェース、
４  情報資源データベース、
５  情報資源データ制御部、
６  プロデューサインターフェース、
７  サーチャインターフェース、
８  クロック、
９  ＤＢ検索フロントエンド、
１０  ＤＢインターフェース、
１１  フィードバック処理部、
１２  評価依頼処理部。
１３  サーチエンジンインターフェース
１４  履歴データベース
１５  広告情報スプール
１６  エージェントステイトテーブル
１７  広告スケジューラ
１８  コストマネージャ
【図１】
0003603613.tif 000002
【図２】
0003603613.tif 000003
【図３】
0003603613.tif 000004
【図４】
0003603613.tif 000005
【図５】
0003603613.tif 000006
【図６】
0003603613.tif 000007
【図７】
0003603613.tif 000008
【図８】
0003603613.tif 000009
【図９】
0003603613.tif 000010
【図１０】
0003603613.tif 000011
【図１１】
0003603613.tif 000012
【図１２】
0003603613.tif 000013
【図１３】
0003603613.tif 000014
【図１４】
0003603613.tif 000015
【図１５】
0003603613.tif 000016
【図１６】
0003603613.tif 000017
【図１７】
0003603613.tif 000018
【図１８】
0003603613.tif 000019
【図１９】
0003603613.tif 000020
【図２０】
0003603613.tif 000021
【図２１】
0003603613.tif 000022
【図２２】
0003603613.tif 000023
【図２３】
0003603613.tif 000024
【図２４】
0003603613.tif 000025
【図２５】
0003603613.tif 000026
【図２６】
0003603613.tif 000027
【図２７】
0003603613.tif 000028
【図２８】
0003603613.tif 000029
【図２９】
0003603613.tif 000030
【図３０】
0003603613.tif 000031
【図３１】
0003603613.tif 000032
【図３２】
0003603613.tif 000033
【図３３】
0003603613.tif 000034
【図３４】
0003603613.tif 000035
【図３５】
0003603613.tif 000036
【図３６】
0003603613.tif 000037
【図３７】
0003603613.tif 000038
【図３８】
0003603613.tif 000039
【図３９】
0003603613.tif 000040
【図４０】
0003603613.tif 000041
【図４１】
0003603613.tif 000042
【図４２】
0003603613.tif 000043