JPH11195048A - 分散検索システムおよび分散検索システムにおける検索装置 - Google Patents

Abstract

(57)【要約】 【課題】ネットワークに接続された計算機が有する情報
資源を検索するシステムで、システムの管理者の負担や
トラフィックやサーバの負荷を軽減させると共に、検索
者が適切な情報資源を発見できるようにする。 【解決手段】情報提供者が情報資源にコスト情報を付与
し、該コスト情報に応じてネットワーク上で該情報資源
が転送される範囲を決定するよう構成する。また情報検
索依頼者は検索依頼にコスト情報を付与し、該コスト情
報に応じてネットワーク上で該情報資源を検索する計算
機の範囲を決定するよう構成する。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、大規模ネットワークに
接続された膨大な数の計算機が、それぞれ何らかの情報
資源を有し、それを利用者に提供する計算機環境におい
て、利用者が希望する情報資源を有する計算機を探し出
すための機能に関する。

【０００２】

【従来の技術】計算機が提供する情報やサービスは、情
報産業のもとになる無形の物資という意味で、これらを
総称して「情報資源」と呼ぶことにする。今日のよう
に、ネットワークが発達し、ネットワークに接続されて
いる計算機の数が莫大になり、様々なサービスが行われ
るようになるにつれて、それぞれの計算機がどのような
情報資源を有しているのかを知ることが非常に困難にな
ってきた。

【０００３】また、たとえそのような情報が得られたと
しても、計算機やネットワークのメンテナンスや故障な
どによって、ネットワーク環境は刻一刻と変化するた
め、以前に利用できた情報資源が、再び利用できるとは
限らない。そのため、利用者は情報資源を実際に利用し
ようとする時点における最新の情報をもとに、希望する
情報資源を提供する計算機を知る必要がある。

【０００４】また、同じ情報資源を有する計算機は一般
に多数存在しており、そのそれぞれは、計算機の管理者
の運営方針により、情報の新しさ、正確さ、抽象度など
の情報資源の質が、計算機ごとに異なるのが当然であ
る。したがって、利用者としては、多くの計算機群の中
から、より良い情報資源を有する計算機を見つけ出せる
ことが望ましい。しかし、その情報資源の善し悪しは、
実際に利用し、他の情報資源も使い比べてみなければ分
からず、利用者がそれを行うのは、無闇に手間を必要と
し、有意義とは言えない。また、情報資源に関する知識
の乏しい初心者にとっては、そのようなことを見極める
ことすら、困難なことである。そこで、多くの利用者か
ら比較的良いと認知されている情報資源を推薦する機能
も有益である。

【０００５】近年、ネットワーク上の多くの情報資源が
WWW (World Wide Web) によってサービスされるように
なってきた。WWW においては、情報資源の位置情報はUR
L (Uniform Resource Locator)によって表現され、ユー
ザがある情報資源を利用しようとする場合には、その情
報資源の位置情報を示す URL を知る必要がある。しか
し、個人が独力で知り得る URL は、ネットワーク上の
全情報資源に遥かに及ばない。そこで、情報資源に対応
する URL を検索する方法として、サーチエンジンと呼
ばれる検索サービスが、WWW 上で提供されている。これ
らの行っている手法は、基本的に、ネットワークを通じ
て利用可能な情報資源に関する情報を収集するステップ
と、収集した情報を管理し、利用者に提供するステップ
に分けることができる。情報収集の方法は、次の2 通り
に大別できる。 ・ディレクトリサービス 情報資源を提供する側が、サーチエンジンのサービス(
ディレクトリサービス) を行っている管理者( 一種の情
報資源の仲介業者) にディレクトリリストへの登録を依
頼する方式で、Yahoo ( http://www.yahoo.com/ ) や A
ltaVista( http://altavista.digital.com/ ) など多数
のサーチエンジンが該当する。この方式では、情報資源
提供者が、ある程度自信を持って登録依頼を出すので、
情報の質が良い反面、登録作業が管理者の手作業によっ
てなされる場合が多く、管理者の負担が大きいという短
所を持つ。また、その結果として、情報の更新が速やか
かつ正確に行われない恐れもある。 ・ロボット ロボットと呼ばれるプログラムを使用して、HTML(Hyper
-Text Mark-up Language。WWW で提供する情報を記述す
る標準的な言語) 文書内のリンク( アンカー)を順に辿
って、世界中に存在する URLを自動的に探索して回り、
URL のデータベースを構築する方式である。WWW Worm(
コロラド大、O.A.McBryan)や RBS E Spider ( ヒュース
トン大、D.Eichimann)などがそうである。この方式の利
点は、情報資源提供者側が何もしなくてもよいことであ
る。しかし、厳密には、誰かに情報資源を提供する旨を
知らせて、リンクを張って貰わない限り、ロボットが発
見することは不可能である。また、情報資源提供者の知
らない内に情報資源が参照されてしまうために、情報資
源やサービスを更新したことを誰に伝えればよいのかが
分からない点は問題である。更に、機械的に情報資源を
漁るので、役に立たない情報資源を拾いやすく、ネット
ワークや計算機の無用な負荷を生むことになる。

【０００６】次に、集めた情報資源に関する位置情報を
管理し、利用者に提供する方法は、次のように分類する
ことができる。 ・集中管理 一箇所のサーバで全てのデータを提供する方式で、Yaho
o やAltaVista を含め、多くのサーチエンジンが該当す
る。この方式は、管理の対象が一箇所なのでメンテナン
スは容易であるという利点があるが、その反面、利用者
のアクセスが一箇所のサーバに集中するので、サーバの
負荷が非常に大きくなりやすい。また、ある利用者はサ
ーバへの通信コストが高くなってしまうのは必須で、す
べての利用者が快適に利用できるとは限らない上に、一
台のサーバがダウンすると、もはや利用できなくなって
しまうという短所を持ちあわせている。 ・分散管理 互いに異なる幾つかのサーバで分担してデータを管理・
提供する方式であるが、分担の仕方に応じて次のように
分類できる。

【０００７】各利用者がアクセスしやすいサーバを選ん
で使用することで、負荷分散を図る。ミラーリングはこ
れに該当する。この方式の利点は同じ機能を持つサーバ
がいくつもあるので、あるサーバがダウンしてもサービ
スが続けられるという点である。しかし、利用者にとっ
ては、同じサービスを行う代替サーバの位置情報を把握
しておかなければ、この利点を亨受することはできな
い。また、すべてのサーバで常に同じデータを保持しな
ければならないので、データの管理に要するコストが大
きいという問題点を含んでいる。 ・サービスの分散 サービスをいくつかのカテゴリに分類し、各々のカテゴ
リをいくつかのサーバに担当させる。計算機の名前から
その IP アドレスを参照する DNS (Domain Name Servic
e)は、これに該当する。また、大規模分散データベース
WAIS (Wide Area Information Server)も、この範疇に
入れることが可能である。また、アクセスの分散とも両
立する場合がある。この方式では、サービスの種類によ
って、管理するサーバが違うので、メンテナンスは容易
である。しかし、サービスの種類や範囲を限定すると、
結局は集中管理と見なせるので、集中管理の短所が見え
てくる。

【０００８】利用者は、自分の希望するサービスに応じ
てサーバを使い分けなければならず、サービスからそれ
を提供するサーバを知る手段がないと利用者側は不便を
感じる(DNS では、ドメインの階層を利用して、自動的
に捜し出せるので、このような問題はない。WAIS は d
irectory-of-servers という名前のデータベースで、そ
れを行う) 。

【０００９】一方、情報資源の推薦機能としては、ソー
シャルフィルタリングあるいは共助(collaborative) フ
ィルタリングと呼ばれる、他者の推薦や評価値、同じ嗜
好を持つ他者の行動を基にして、利用者にとって好まし
いものを推薦する技術が開発されている。例えば、Tape
stry (Xerox Palo Alto Research Center 、D.Goldber
g、 D.Terry) は、ネットニュースやメーリングリスト
の記事を対象にし、大量の記事の中から、ある人が積極
的に推薦してくれる記事を選択して読むことを支援する
システムである。これに対して、過去の記事に対する評
価値の付け方が似ている( 価値観の似ている) 他の利用
者が、高い評価値を付けたものを推薦するシステムとし
ては、ネットニュースの推薦を行うGroupLens(P.Resnic
k)、音楽アルバムの推薦を行うRingo (MIT、P.Maes、U.
Shardanand) などが挙げられる。

【００１０】ところが、ある分野の嗜好が類似している
からといって、その他の分野に関する嗜好が同じである
保証は得られないので、必ずしも特定の個人の行動や推
薦に従うのが良いとは限らないことがある。また、嗜好
に関する情報は集中管理されているため、嗜好データの
管理に関して、サーチエンジンの情報の集中管理で述べ
たような問題点が浮き彫りになる。

【００１１】

【発明が解決しようとする課題】前節で述べたように、
既存の方法における問題点は、次のように整理すること
ができる。 ・ディレクトリサービスにおいては、登録作業が管理者
の手作業によることが多く、そのため管理者の負担が大
きい。また、管理者の手違いにより、検索がうまく行わ
れなくなる可能性がある。 ・ロボットプログラムが HTML 文書の内容をよく吟味し
ないため、役に立たないHTML 文書を転送する可能性が
大で、それによるトラフィックやサーバへの負荷が増大
しがちであった。 ・トラフィックを低く抑えるためには、ロボットプログ
ラムを起動する頻度を少なくする必用があり、そうする
と収集された情報は古くなりがちで、入手した情報が既
に無効になっている可能性が大きくなる。 ・ロボットによる情報収集は、情報資源提供者側で、提
供するサービス内容の変更知らせるべき相手が分からな
かったり、たとえ変更を伝えることができたとしても、
その内容が即座に検索結果に反映されない可能性があ
る。 ・情報資源のデータベースが巨大になると、検索に対し
て膨大な結果が出力されるために、利用者はどれが最も
適切な情報資源なのかを判断しにくくなる。特に、利用
者が、対象としている情報に関する十分な知識を持って
いない場合に顕著である。 ・特定の嗜好が類似しているからと言って、すべての嗜
好が類似しているとは保証できないので、ある特定の個
人が推薦したものに、常に満足できるとは限らない。更
に、上記のような分散検索方式においては、エージェン
トがどのように配置され、どのように結合されているか
が、検索のパーフォーマンスを左右する．このため、エ
ージェントの管理者は、全体の効率を上げるためには、
エージェントネットワークをどのように構築するかをよ
く検討する必要がある。

【００１２】従来の分散検索方式においては、エージェ
ントの近隣関係は、エージェントの管理者があらかじめ
決定し、チューニングは管理者が手作業で行う必要があ
り、エージェントのネットワーク環境の変化に対して柔
軟に対処することが困難であった。ところが、ネットワ
ーク環境は絶えず変化するものであり、あるエージェン
ト間の通信路が障害の為に通信できなくなったり，一時
的にエージェントの負荷がくなってしまい、速やかに検
索結果を得ることが困難である状況に出喰わすことがあ
る。また、検索要求を受け取ったエージェントすべてか
らの結果が得られないのであれば、十分に望ましい検索
結果を得られないということにも継がる。

【００１３】一方、検索結果の返送によって、資源情報
を得るエージェントは、自分の最寄りの利用者が全然参
照しない、無駄な資源情報を無意味に保持する状況も想
定される。このような状況は、無用な情報の管理コスト
を削減するためには、避けたい状況である。本発明は、
情報資源に関する情報の管理を自動化し、情報資源提供
者による情報資源の広告と利用者による問い合わせを仲
介し、検索結果を利用者に返送する際に、情報資源の広
告も同時に行うことにより、情報の陳腐化を防ぎ、多く
の情報資源から一般的に良いと認知されているものを選
択するようにすることで、上記の問題点を解決した情報
資源の発見を目的とする。

【００１４】更に本発明は、各エージェントが、受け取
った資源情報の広告、検索要求、あるいは検索結果の履
歴として、頻度、発生元、他のエージェントの応答時間
などの情報を記録し、それらのデータを利用し、情報の
転送のスケジューリングを行ったり、情報配送のコスト
の配分を行ったり、転送先として適切なエージェントを
選択することによって、効率良く資源情報を伝播させ、
検索することを目的とする。

【００１５】

【課題を解決するための手段】本発明は、複数のエージ
ェントのネットワークからなり、図１は、各エージェン
ト（検索装置）単体の原理説明図である。図中(1) は広
告処理部であり、情報資源提供者からの情報資源に関す
る広告を受け付け、必要に応じて情報資源提供者に通知
を行うものであり、問い合わせ処理部(2) は、利用者か
らの検索依頼を受け付け、結果を利用者に返送する部分
である。エージェントインターフェース(3) は、他のエ
ージェントと、広告や問い合わせとその結果をやり取り
する部分である。情報資源データベース(4) は、広告処
理部(1) から送付された広告や、エージェントインター
フェース(3) から受け取った広告を保持するものであ
る。情報資源データ制御部(5) は、広告処理部(1) やエ
ージェントインターフェース(3) から受け取った広告に
対して、情報資源データベース(4) に保管したり、広告
に要したコストを計算し、それに応じて、エージェント
インターフェース(3)を通じて、他のエージェントに送
付するなどの処理を指示し、問い合わせ処理部(2) やエ
ージェントインターフェース(3) からの問い合わせに対
しては、情報資源データベース(4) を検索したり、検索
要求の伝達に要したコストの計算を行い、エージェント
インターフェース(3) を通じて他のエージェントへ問い
合わせを回送するなどの処理を行うものである。システ
ム全体における、このような広告・問い合わせなどのデ
ータの授受を模式的に表したものが図２である。図中○
がエージェントを表し、そのそれぞれがここで述べた動
作を行う。また、図中のエージェント間の実線は、通信
可能であるという関係を表している。

【００１６】本発明では、図２のように、前節で述べた
構成を持つ複数のエージェントが、相互に連結したイン
フラを構成し、情報資源提供者が自分の提供できるサー
ビスに関する情報を、広告という形式で、最寄りのエー
ジェントに知らせる。広告を受け取ったエージェント
は、その広告に記載されている内容を情報資源データベ
ースに蓄え、あるコスト内で伝達できる範囲のエージェ
ントにも同様の広告を行う。こうして、広告を受け取っ
たエージェントは、その広告をある一定期間( 生存期間
と呼ぶ) 保持し、それを過ぎた時点で消去するように
し、古い情報がいつまでもエージェントの情報資源デー
タベースに留まらないようにしている。

【００１７】一方、利用者からの問い合わせが発生した
場合は、広告と同様に、あるコスト内で伝達できる範囲
のエージェントにも問い合わせを送付し、該当するデー
タを持つエージェントに問い合わせが到達した時点で、
そのエージェントは結果を利用者に返送する。結果を返
送する際には、問い合わせが経由してきたエージェント
を逆に辿り、各エージェントにその結果を蓄えさせるよ
うにして、最初に情報資源提供者が広告した範囲外に
も、広告が伝播されるようにする( 図３) 。検索に成功
した利用者は、その情報資源を利用し満足のいく結果が
得られた場合、図４のように評価をフィードバックさ
せ、情報資源提供者が行った広告と同じように伝播させ
る。情報資源に関して良い評価を受け取ったエージェン
トは、その情報資源に関する情報の生存期間を延長する
ようにし、利用者を満足させる情報資源に関する広告が
長く情報資源データベースに留まるようにしている。逆
に、否定的な評価を受け取ったエージェントは、その情
報の生存期間を短縮し、検索によって見つけられにくく
する。

【００１８】従って、各エージェントは、近隣のエージ
ェントとの通信だけで済み、更に広告や検索依頼によっ
て特定される情報のみを伝達する為、通信コストを低く
押さえることが可能となる。また、利用者の使用実績を
データベース内の生き残り時間という形で反映し、頻繁
に利用され好評を博する情報資源に関する広告は、そう
でないものよりも長時間データベースに存在し、また広
範囲のエージェントに伝播される為、別の利用者が検索
する際に発見されやすくなる。

【００１９】更に本発明の変更態様として、図１にて説
明した構成に加えて図２３に示すように履歴データベー
ス(5) を設ける構成を考案した。この履歴データベース
（５）は、広告処理部(1) 、問い合わせ処理部(2) およ
びエージェントインターフェース(3) を通じて、転送さ
れてきた広告情報、検索要求および検索結果が、いつ、
どこから( どこを通って) 転送されてきたか、どのよう
な内容を含んでいるかを記録するデータベースである。

【００２０】情報資源データ制御部(6) は、広告処理部
(1) やエージェントインターフェース(3) から受け取っ
た広告に対して、情報資源データベース(4) に保管、履
歴データベース(5) を更新したり、履歴の内容に応じ
て、エージェントインターフェース(3) を通じて、他の
エージェントに送付するなどの処理を指示する。また、
問い合わせ処理部(2) やエージェントインターフェース
(3) からの問い合わせに対しては、情報資源データベー
ス(4) を検索し、履歴データベース(5) を更新し、その
内容に応じて、エージェントインターフェース(3) を通
じて他のエージェントへ問い合わせを回送するなどの処
理を行うものである。エージェントインターフェース
(3) を通じて得られる検索結果を基に、資源情報データ
ベース(4) を更新するのも、情報資源データ制御部(6)
の指示によって行われる。その際に、履歴データベース
(5) を更新するのも、広告・検索要求の場合と同様であ
る。

【００２１】システム全体における、このような広告・
検索要求・検索結果のデータの授受を模式的に表したも
のが、それぞれ図２４、図２５、図２６である。図中の
○がエージェントを表し、そのそれぞれが図２３の構成
を有して、上述した動作を行う。また、図中のエージェ
ント間の実線は、互いのエージェントが近隣関係にある
ことを表している。ここで言う「エージェントが近隣関
係にある」ということは論理的に近隣関係にあるという
ことで、エージェントが互いの位置情報を知り、直接に
通信を行うことができることを意味している。従って必
ずしも、地理的あるいはハードウェア的な（物理的な）
近さを反映するものではない。また、近隣関係がないか
らといって、通信ができないことを意味するのではな
い。

【００２２】この構成においては、図２４のように、前
節で述べた構成を持つ複数のエージェントが、相互に連
結したインフラを構成し、情報資源提供者が自分の提供
できるサービスに関する情報を、広告という形式で、最
寄りのエージェントに知らせる。広告を受け取ったエー
ジェントは、その広告に記載されている内容を情報資源
データベースに蓄え、近隣のエージェントにも同様の広
告を行う。こうして、資源情報がエージェントに徐々に
伝達されていく。

【００２３】一方、利用者からの問い合わせが発生した
場合は、広告と同様に、近隣のエージェントに検索要求
を伝達していき( 図２５) 、該当するデータを持つエー
ジェントに問い合わせが到達した時点で、そのエージェ
ントは結果を利用者に返送する。結果を返送する際に
は、問い合わせが経由してきたエージェントを逆に辿
り、各エージェントにその結果を蓄えさせるようにし
て、最初に情報資源提供者が広告した範囲外にも、広告
が伝播されるようにする( 第２６) 。

【００２４】情報資源の広告情報、検索要求および検索
結果の転送先のエージェントは、システム導入時に、エ
ージェントの管理者が設定するのであるが、ある程度運
用を続けていくと、広告情報、検索要求および検索結果
の履歴が蓄積されてくる。その情報から、「エージェン
トＡから来る広告情報は、Ｆという分野に関するものが
多い」、「エージェントＢからの検索要求は、Ｆという
分野に関するものが多い」、あるいは「エージェントＣ
からの検索結果は、Ｆという分野に関するものが多い」
といったエージェントの扱っている資源情報の傾向が見
て取れるようになる。

【００２５】このような情報を利用し、あるエージェン
トからＦという分野に関する情報の検索要求が来た場合
には、優先的にエージェントＡまたはＣに近い近隣エー
ジェントに検索要求を送付したり、あるいは直接エージ
ェントＡまたはＣに送付することにより、求める情報資
源が発見しやすくなることが期待できる。逆に、Ｆとい
う分野に関する広告が来た場合には、Ｆに対する需要の
高いエージェントに近い方へと、広告情報を伝達してお
けば、その地域の利用者は、Ｆに関する情報を発見しや
すくなることが期待できる。同時に、広告情報の配布に
関しては、需要の高いものを即時に伝達し、そうでない
ものを、ネットワークトラフィックの少ない時間帯に伝
達を行うようにすることで、ネットワークトラフィック
の集中やエージェントの過負荷を防ぐことが可能であ
る。

【００２６】また、履歴情報として、エージェントのレ
スポンス時間に関する情報も記録することにすると、ご
く最近に、ネットワークの不通やエージェントのダウン
という状況があったなら、それに該当するエージェント
への情報伝達を、一時的にストップさせ、他のエージェ
ントに送るようにすることで、エージェントネットワー
クの障害が一部にあったとしても、全体として、情報探
索機能を滞りなく提供することが可能となる。

【００２７】

【発明の実施の形態】［第一の実施形態］図５は本発明
の一実施例構成図であり、情報資源情報の分散管理と検
索機能を持つ情報資源発見装置を示している。図中、図
１で示したものには同一の番号を付与してある( 図１１
および図１３中の番号は、データフローの順番を表すも
ので、それとは無関係である) 。

【００２８】通常の動作は、情報資源提供者( プロデュ
ーサ) が、あらかじめ、プロデューサインターフェース
(6) を通して、自分の提供するサービスに関する情報を
最寄りのエージェントに広告という形で伝える( 広告依
頼) 。広告の具体的な形式は、図６のように、次のよう
な項目とそれに対応する情報の組からなるものとすれば
よい(*を付けた項目は、広告処理部(1) が自動的に付与
する情報であり、情報資源提供者が指定しなくてもよ
い) 。 ID(*): 広告を識別する記号。 From(*): 広告の発送者を特定する情報。例えば、メー
ルアドレス。情報の利用者からの問い合わせに利用した
り、広告内容の改竄を防止するための認照用のデータと
して利用。 Subject: 提供する情報資源の名称。 Keywords: 提供する情報あるいはサービスに関係するキ
ーワード。 URL: 提供する情報の位置情報。位置情報を検索するの
で、このようなフィールドを設けているが、他の検索対
象にしたい情報を記述するフィールドとしてもよい。 Maintainer: 情報資源の管理者を特定する情報。広告の
発送者と同じでも構わない。 Cost: 広告範囲を限定するパラメータ。経由するエージ
ェントの最大数、あるいは広告に費やす時間など。通信
や計算機の使用に関して課金システムが導入されている
のなら、その金額でもよい。 Date(*): エージェントが広告を受け取った日時。 Path(*): 広告が中継されたエージェントのＩＤの列。
ひとつの広告が同じエージェントに何度も伝達されるの
を防ぐのが目的である。

【００２９】プロデューサインターフェース(6) は、そ
の広告を、エージェントの広告処理部(1) に伝える。そ
して、広告の内容を解析し、上記の* を付けたフィール
ドを補足し、広告内容を情報資源データ制御部(5) に渡
す。ここで、広告の生存期間を決定し、広告の内容は情
報資源データベース(4) に蓄えられる。情報資源データ
制御部(5) はクロック(8) を参照しており、既に生存期
間を過ぎた広告を情報資源データベース(4) から削除す
る。また、情報資源データ制御部(5) では、広告に要し
たコストの計算も行い、使用可能コストにまだ余裕のあ
る時には、エージェントインターフェース(3) を通じて
他のエージェントに広告の伝達を行う。

【００３０】コストとしては、広告を依頼してから広告
を終了するまでの時間や、通信費用やデータベースを利
用するために必要な費用などを挙げることができる。特
に、コストを無制限にすることによって、広告範囲を限
定しない従来のブロードキャストを実現することも可能
である。この一連の処理フローが図７である。図中の(6
a)はプロデューサインターフェース(6) 、(1a)は広告処
理部(1) 、(5a)から(5c)は情報資源データ制御部(5) 、
(3c)はエージェントインターフェース(3) の動作に、そ
れぞれ対応する。

【００３１】一方、情報検索者( サーチャ) は、サーチ
ャインターフェース(7) を通じて、問い合わせ処理部
(2) へと検索要求を出す( 検索依頼) 。検索要求の具体
的な形式は、図８のように、広告の形式と同様の形式か
らなり、各項目のうち、既に分かっている項目を適当に
埋め、検索によって知りたい項目を空けておいたものと
すればよい(*の付けられた項目の取り扱いに関しては、
広告と同様に、検索者が付けるのではなく、問い合わせ
処理部(2) が自動的に補う) 。これにより行われる検索
として、例えば、次のような検索の仕方が考えられる。 １．Keywordsをいくつか指定し、それ以外の項目を空け
ておき、指定したキーワードに関連を持つ情報資源の名
称や URL を検索する。 ２．実際にサービスが行われているか否か、あるいは、
サービスの内容を調べるために、URL を指定し、その他
の項目を空けておき、Subject やKeywordsを検索する。 ３．同じ資源を提供している者同士での連携を図るため
に、Subject やKeywordsを指定し、Maintainerを空けて
おき、関係しそうな情報資源の管理をしている人を検索
する。逆にMaintainerを指定し、その人が管理している
情報資源を検索する。

【００３２】検索要求を受け取った問い合わせ処理部
(2) は、情報資源データ制御部(5) に検索依頼を送り、
情報資源データ制御部(5) は、その依頼を解析し、それ
をもとに情報資源データベース(4) を検索する。該当す
る結果が見つかれば、その結果を問い合わせ処理部(2)
とサーチャインターフェース(7) を通じて検索の依頼主
に返送される( 検索結果) 。この時も広告の場合と同様
に、情報資源データ制御部(5) において、コストの計算
を行い、使用可能コストに余裕がある場合には、エージ
ェントインターフェース(3) を通じて、他のエージェン
トへ検索を依頼し、その結果を集めて、情報検索者のも
とへ返送する。検索結果は、広告の形式と同様で、検索
要求のうち検索の対象となっている項目を該当するデー
タを補ったものである。コストに関しては、上記で述べ
た情報資源の広告で触れたように、時間や費用などを考
えることができる。また、コストを無制限にすることに
よって、検索範囲を限定せずにすべてのエージェントに
検索を依頼することもでき、逆に最小にすることで、た
だひとつのエージェントのみを検索の対象にすることも
できる。この一連の処理フローが図９である。図中の(7
a)はサーチャインターフェース(7) 、(2a)および(2b)は
問い合わせ処理部(2) 、(3b)はエージェントインターフ
ェース(3) 、(5d)から(5i)は情報資源データ制御部(5)
の動作に、それぞれ対応する。

【００３３】この実施例は、原則的には請求項3 に対応
するものであるが、請求項の1 および2 にも対応してい
る。検索方法をここで述べたような方式に固定せず、情
報の配布方式のみを考慮した場合が請求項1 に該当し、
情報の配布方式を規定せずに、ここで述べた検索方式の
みを採用したものが請求項2 に該当する。 ［第二の実施形態］図１０は、大規模分散データベース
への実施例であり、請求項4 に対応する。利用者は、検
索したい情報のキーワードをデータベース検索フロント
エンド(9)に与え、データベース検索フロントエンド(9)
は、まずそのキーワードに関する情報を持つデータベ
ースサーバの位置情報を、最寄りのエージェントにサー
チャインターフェース(7) を通じて尋ねる。検索依頼を
受けたエージェントは、最初に述べた実施例の動作に従
い、検索を実行する。その際、各エージェントが、他の
エージェントから返送されてくる検索結果を、自分の情
報資源データベース(4) の該当するデータとを比較し、
もし検索結果の方が新しいデータであるならば、情報資
源データベース(4) のデータを新しいデータに書換える
ことで、請求項4 を実現することができる。そうして、
データベースサーバの位置情報が得られたならば、デー
タベース検索フロントエンド(9) は、得られた結果か
ら、適切なサーバをいくつか選び、それらのデータベー
スサーバにキーワードを転送し、データベースの検索を
実行させる。最後にデータベースサーバからの検索結果
を統合し、利用者に返送する。この一連の動作を模式的
に説明した図が図１１である。 ［第三の実施形態］図１２は、別の大規模分散データベ
ースへの実施例である。

【００３４】第２の実施形態は、本発明によりデータベ
ースサーバの位置情報が判明した後に、検索を実行する
方式であったが、この実施例は、データベースサーバの
位置情報の検索と、発見されたデータベースサーバに対
するデータベース検索を並行して行う方式である。デー
タベースサーバの管理者が、あらかじめデータベースサ
ーバの広告をしておくのは、前節と同様である。情報検
索を行う人は、サーチャインターフェース(7) を通じ
て、データベースの検索を依頼する。その依頼は問い合
わせ処理(2)によって、適切な形式に整形され、情報資
源データ制御部(5) に渡される。

【００３５】情報資源データ制御部(5) は、情報資源デ
ータベース(4) を検索し、検索に応じられるデータベー
スサーバの位置情報を探す。もし、該当するデータベー
スサーバに関する情報が発見できたなら、データベース
インターフェース(10)を通して、データベースサーバに
検索を実行させる。使用可能コストに余裕があれば、更
にエージェントインターフェース(3) を通じて、他のエ
ージェントにも検索依頼を発行し、検索結果を返送する
ようにしてもらう。一方、先程検索を依頼したデータベ
ースサーバから結果が返送されてきたならば、その結果
を一時的に蓄えておき、他のエージェントからの結果が
揃うまで、待機する。すべての検索結果が返送されてき
たならば、それらを統合して、検索依頼元に送り返す。
この一連の動作を模式的に説明した図が図１３である。

【００３６】この方式では、あるデータベースサーバに
複数のエージェントから同じ検索依頼を受ける可能性が
あるが、あらかじめ検索依頼にＩＤを付与し、データベ
ースサーバは、検索履歴をそのＩＤと共に記憶してお
き、重複した検索依頼には、「既に回答済み」と依頼元
に返答するなど、同じ検索を何度も行うのを避ける機能
を有することが望ましい。 ［第四の実施形態］以上の実施例では、エージェントか
ら得られた情報資源に関する情報は基本的に情報資源提
供者側から一方的に与えられるものであるが、図１４の
実施例のように、検索の結果として得られた情報資源を
実際に使用し、その善し悪しなどの情報をエージェント
にフィードバックしてもよい。そうすることで、すべて
の利用者が効果的に情報資源を利用することが可能とな
る。例えば、実際に情報資源を使用する際、すでに使用
不可能になっていることが判明した情報資源に関して
は、各エージェントの情報資源データベースから、該当
する情報資源を削除するように広告を行い、他の利用者
がその無効な情報資源を利用しようとしないようにす
る。また、利用者の希望によく叶うものであったなら
ば、生存期間を延長するようなデータ制御のための広告
を行い、他の利用者もその情報資源に関する情報を容易
に発見しやすいようにする。この実施例は、請求項5 に
対応する。

【００３７】情報資源の評価に関するフィードバック情
報は、サーチャインターフェース(7) を通じて、フィー
ドバック処理部(11)に渡される。そして、そこで適切な
形式に変換され、他のエージェントにも伝播すべく、広
告を行うために、情報資源データ制御部(5) に渡され
る。広告を受け取った情報資源データ制御部(5) は、情
報資源データベース(4) 中の該当する情報資源のエント
リの生存期間を評価に応じて更新し通常の広告と同様に
コストに余裕のある限り、他のエージェントへエージェ
ントインターフェース(3) を通じて、評価を伝達してい
く。フィードバック処理部(11)の処理フローは、図１５
である。

【００３８】この図では、利用者からの評価を、＋（満
足) 、−（不満) 、＊（使用不能)の3 段階と仮定して
いる。そして、そのそれぞれの評価に対して、データベ
ース中の該当する情報資源のエントリの生存期間の延
長、短縮、削除を要求する広告を行うように情報資源デ
ータ制御部(5) に命令する。上記の実施例では、情報資
源の善し悪しを計る目安として、情報資源データベース
内での広告の生存期間を採用していたが、生存期間とは
別に、利用されている回数や、一番新しいものなど、他
の評価基準で優先順位を付け、ソートし、検索結果を返
送してもよい。その場合には、まず、情報資源提供者が
広告を行い、各エージェント内の情報資源データベース
(4) に情報資源に関する情報を記録する際に、情報資源
に関する評価という属性もデータベースに記録しておく
必要がある。同じ情報資源に関する情報が、複数のエー
ジェントからそれぞれ異なる評価値と共に返送されてく
る場合には、平均をとるなどして、エージェント組織全
体としての評価値を計算する。そして、最終的にサーチ
ャインターフェース(7)は、情報検索者に検索結果をす
べて提示するのでなく、検索者の評価基準に照し合わせ
て順位を付け、最良のものを提示してもよい。 ［第五の実施形態］上記の実施例では、各エージェント
が持っている情報資源に関する評価値は情報検索者が検
索することによって、集計され、検索者が情報資源を取
捨選択するのに利用されているが、評価値の計算は検索
とは関係なく独自で行なわれ、情報資源提供者が自分が
公開した情報資源の社会的な評価を知るために利用して
もよい。

【００３９】図１６は、情報資源提供者による情報資源
の評価値の集計機能付きの情報資源発見方式の構成図で
ある。プロデューサインターフェース(6) は、情報資源
提供者から広告依頼の他に評価依頼を受け付け、評価依
頼を受け取った場合には、もし必要ならば、情報資源提
供者の認照を行い、評価依頼処理部(12)にその内容を送
る。評価依頼処理部(12)は、その内容を解析し、情報資
源データ制御部(5) 評価要求を送る。情報資源データ制
御部(5) は、情報資源データベース(4) の該当する情報
資源の評価値を検索すると共に、資源情報の広告や検索
と同様に、エージェントインターフェース(3) を通じ
て、他のエージェントへも評価依頼を送出する。検索の
結果返送されてきた評価値は、情報資源データ制御部
(5) に集められ、そこで集計され、評価依頼処理部(12)
およびプロデューサインターフェース(6) を通じて、情
報資源提供者に返送される。 ［第六の実施形態］図１８は、Web 文書に関する情報の
管理・検索を行う、分散型のサーチエンジンの構成を示
している。図中、上述の各実施形態と同じ構成要素には
同一の番号を付与してある。

【００４０】なお、本実施形態は技術思想的には第一〜
第六の実施形態と同様であるが、ベストモードとして開
示するものである。通常の動作は、Web 文書作成者が、
プロデューサインターフェース(6) を通して、自分が作
成した Web文書に関する情報を最寄りのエージェントに
広告という形で伝える。広告の具体的な形式について
は、上述の各実施形態と同様である。

【００４１】広告処理部(1) は、プロデューサインター
フェース(6) から送られてくる Web文書に関する広告情
報を基に、登録日時、情報の生存期間、広告コスト・評
価値の初期値などの情報を付与し、Web 文書データ制御
部(5) に渡す。Web 文書データ制御部(5) は、基本的に
情報資源データ制御部と同じであるが、この実施例が対
象とする情報資源がWeb 文書であるので、便宜的にそう
名付けた。Web 文書データベース(4) も同様の理由で、
情報資源データベースのことである。Web 文書データ制
御部(5) では、上述した各実施形態と同様に、広告で得
られた Web文書情報をWeb 文書データベース(4) に登録
し、広告に要したコストの計算を行い、コストに余裕が
あれば、エージェントインターフェース(3) を通じて、
他のエージェントへ広告を伝達させる。また、クロック
(8) に基づいて、有効期間を過ぎた Web文書情報を Web
文書データベース(4) から削除する。

【００４２】また、他のエージェントから広告依頼を受
ける場合は、エージェントインターフェース(7) を通じ
て、広告依頼が Web文書データ制御部(5) に渡される。
このように、Web 文書データ制御部(5) が広告処理部
(1) やエージェントインターフェース(7) から広告依頼
データを受け取ってからの処理フローが図１９である。

【００４３】一方、Web 文書閲覧者は、サーチャインタ
ーフェース(7) を通じて、Web 文書の検索を行う。問い
合わせ処理部(2) は、Web 文書閲覧者からの入力を基
に、検索要求を作成し、それを Web文書データ制御部
(5) に送る。検索要求の形式は、図１０で示したような
ものである。Web 文書データ処理部(5) は、Web 文書デ
ータベース(4) を検索し、検索要求を満す Web文書を検
索し、検索結果を保持する。そして、広告の場合と同様
に、残りの利用可能コストを計算し、まだ余裕があれ
ば、エージェントインターフェース(3) を通じて、他の
エージェントに検索要求を転送し、検索結果が返送され
てくるのを待つ。

【００４４】検索要求を出したエージェントすべてから
検索結果が返送されてくるか、ある一定時間が経過した
時点で、集まった検索結果を、問い合わせ処理部(2) に
送り、リストの形式にし、サーチャインターフェース
(7) を通じて、Web 文書閲覧者に提示する。他のエージ
ェントから検索要求を受け取る場合は、エージェントイ
ンターフェース(7) を通じて、検索要求が Web文書デー
タ制御部(5) に渡され、検索結果は、エージェントイン
ターフェース(7) を通じて、依頼元のエージェントへと
返送される。

【００４５】Web 文書データ処理部(5) が問い合わせ処
理部(2) やエージェントインターフェース(7) から検索
依頼を受け取ってからの処理フローが図２０である。We
b 文書閲覧者から、直接検索要求を受け取ったエージェ
ントは、検索結果をWeb 文書閲覧者に提示し、こうして
得られた検索結果を基に、Web 文書閲覧者は、サーチャ
インターフェース(7) を通じて、実際に検索結果に示さ
れた Web文書にアクセスする。そして、閲覧者に Web文
書が閲覧者の要求を満たしているか否かの評価を行って
もらう。評価は、サーチャインターフェース(7) が自動
的に行う場合もある。実際の Web文書が存在していない
とか、何等かの理由で利用できないという状態は好まし
くないので、それを負の評価として自動的に収集するこ
とが可能である。この時のサーチャインターフェース
(7) の処理フローが図２１である。 ［第七の実施形態］Web 文書の収集は、Web 文書作成者
からの広告ばかりでなく、既存のサーチエンジンが持つ
Web文書情報を利用することも可能である。エージェン
トは、サーチエンジンのラッパーの役割を果し、相互に
Web文書に関する情報をやりとりする利用形態も考えら
れる。こうすることで、既存のサーチエンジンを連携・
統合し、すべてのサーチエンジンを統一的に利用するこ
とが可能となる。

【００４６】図２２は、このように既存サーチエンジン
を利用した分散型サーチエンジンの構成図である。前項
の分散型サーチエンジンとほぼ同じであるが、サーチエ
ンジンインターフェース(13)を持ち、既存のサーチエン
ジンから Web文書情報を得ることができる点が異なる。
このサーチエンジンインターフェース（13）は、検索要
求に含まれるキーワードを抽出して、既存のサーチエン
ジンを用いて検索を行い、得られたWeb 文書をｗｅｂ文
書データ制御部からサーチャインターフェースを介し
て、情報検索者に提示するものである。

【００４７】またWeb 文書データベース(4) は、既存の
サーチエンジンの Web文書情報をキャッシュし、Web 文
書に関する評価情報のデータベースとして機能する。We
b 文書を解析して上述したような広告情報のフォーマットでWe
b 文書に対応する広告情報を作成し、Web 文書データベ
ース(4) に保存を行う。広告依頼に対する基本的な動作
は前項と同じであるが、検索要求に対する動作は、既存
サーチエンジンの利用形態に応じて、いくつか考えられ
る。 ・主に既存サーチエンジンを Web文書データベースと
し、Web 文書データベース(4) を、Web 文書に対する評
価情報を蓄えるデータベースとして利用する形態。

【００４８】検索要求に対して、サーチエンジンインタ
ーフェース(13)を通して、サーチエンジンを検索し、得
られた結果中の各 Web文書に対して、Web 文書データベ
ース(4) を調べ、評価情報を付与し、エージェントまた
は Web文書閲覧者へと返送する。 ・主に Web文書データベース(4) を利用するが、検索結
果が十分に得られない場合に、既存サーチエンジンを補
助的に利用する形態。

【００４９】検索要求に対して、まず Web文書データベ
ース(4) を検索し、検索要求に見合う結果が得られな
い、あるいは、十分な個数の Web文書情報が得られなか
った場合に、サーチエンジンインターフェース(13)を通
じて、既存のサーチエンジンを利用して検索を行う。そ
して、その結果を Web文書閲覧者に提示すると共に、We
b 文書データベース(4) に登録し、次回の検索に備え
る。 ・文書データベース(4) の管理・維持のために、既存サ
ーチエンジンを利用する形態。

【００５０】検索要求に対して、通常のように Web文書
データベース(4) を利用して、検索を行う。それと同時
に、検索要求の履歴を蓄えておき、ある一定時間ごと
に、検索要求の履歴をもとに、サーチエンジンインター
フェース(13)を通して、サーチエンジンを検索し、その
結果を基に Web文書データベース(4) を更新する。以上
説明したように、本発明によれば、情報資源に関する情
報の管理を人手に頼らずに自動的行うことができ、資源
情報の管理者は情報の登録や維持に手間を割く必要がな
くなる。おまけに、本発明は、従来のディレクトリサー
ビスと同様に、基本的には情報資源提供者の申告に基づ
くため、ディレクトリサービスの利点であった情報の質
を損うことはない。

【００５１】また、資源情報は分散管理され、各エージ
ェント間の結合に冗長性を持たせることで、ネットワー
ク環境の変化に対して頑健で検索の負荷分散や検索者の
アクセスのしやすさを向上させることができ、広告およ
び検索に利用できるコストを制限することで、資源情報
を広告するエージェントの範囲と検索対象とするエージ
ェントの範囲を限定することができるため、全体の通信
量を低く抑えることができる。そして、ロボットプログ
ラムのような情報資源のサーバへの無用なアクセスを行
わずに済むため、サーバへの高負荷を生むこともない。
更に、情報資源提供者は常に最寄りのエージェントへア
クセスし、資源情報の更新を行うことができ、一方で
は、情報資源検索者による情報資源の利用可能性につい
てのフィードバックがかかり、他のエージェントにも即
座に更新情報が伝わるため、資源情報の陳腐化現象を起
りにくくする効果が期待できる。

【００５２】情報資源検索者による情報資源の評価のフ
ィードバックは、各エージェント上での資源情報の生存
期間を調節することで、有益な情報資源に関する情報は
発見されやすく、そうでないものに関する資源情報は発
見されにくくなり、検索結果として得られる資源情報
は、多数の検索者のフィードバックに基づく全体的な評
価に基づいて順位付けられるので、数多くある情報資源
を取捨選択するだけの知識や技量を持たない情報資源検
索者にとっても、より良い情報資源を発見・選択・利用
しやすくなるという効果が期待できる。そのため、本発
明は、大規模な資源情報の効率的な分散管理および検索
に寄与するところが大きい。 ［第八の実施形態］図２７は本実施形態に関する構成図
であり、情報資源情報の分散管理と検索機能を持つ情報
資源発見装置を示している。図中、図２３で示したもの
には同一の番号を付与してある。

【００５３】まず広告依頼の処理を図２８のフローチャ
ートに基づいて説明する。通常の動作は、情報資源提供
者( プロデューサ) が、プロデューサインターフェース
(6)を通して、自分の提供するサービスに関する情報を
最寄りのエージェントに広告という形で伝える( 広告依
頼) 。広告の具体的な内容は、提供する情報資源の UR
L、名称、内容を表すキーワード、管理者名などであ
る。プロデューサインターフェース(6) は、その広告
を、エージェントの広告処理部(1) に伝える。そして、
広告の内容を解析し、必要な情報が落ちていないか( 例
えば、情報資源の URLや、関連キーワードなど) 、不正
なデータが記載されていないか( 例えば、妥当な形式の
URLか否か、漢字コードは正常か) 等をチェックし、広
告内容を情報資源データ制御部(5) に渡す。ここで、こ
の広告内容に基づいて、履歴データベース(14)を更新
し、広告の内容は情報資源データベース(4) に蓄えられ
る。履歴データベース(14)の具体的な形式については、
後で述べる。

【００５４】また、情報資源の広告情報は、エージェン
トインターフェース(3) を通じて、あらかじめエージェ
ントの管理者が決めておくエージェントに伝達すること
もできる。広告情報を受け取るエージェントでは、やは
りエージェントインターフェース(3) から広告情報を貰
い、情報資源データ制御部(5) に渡し、先程と同様に、
履歴データベース(14)を更新し、情報資源データベース
(4) を更新する。

【００５５】一方、情報資源の検索要求の処理は図２９
の処理フローチャートに示すように、情報検索者からサ
ーチャインターフェース(7) を通じて、問い合わせ処理
部(2) へと送られる。そこで、検索要求に関して、必要
なデータが落ちていないか(例えば、検索キーワードと
か、結果をメールで返送するのならメールアドレスな
ど) 、不正なデータが含まれていないか( 例えば、メー
ルアドレスが妥当な形式であるか否か) などをチェック
する。

【００５６】検索要求を受け取った問い合わせ処理部
(2) は、情報資源データ制御部(5) に検索依頼を送り、
情報資源データ制御部(5) はその依頼を解析し、それを
基に履歴データベース(14)を更新する。そして情報資源
データベース(5) を検索し、その結果を問い合わせ処理
部(2) とサーチャインターフェース(7) を通じて検索の
依頼主に返送される。

【００５７】また、検索の場合も広告の場合と同様に、
エージェントインターフェース(3)を通じて、エージェ
ント管理者が定める近隣エージェントへ検索を依頼し、
その結果を集めて、情報検索者のもとへ返送することも
できる。この場合は、検索要求を転送したエージェント
からの検索結果がすべて揃うまで、ある一定時間待ち続
ける。検索結果が、エージェントインターフェース(3)
から、情報資源データ制御部(5) へと送られると、検索
結果の内容を解析し( 例えば、通信の過程でデータが壊
れていないかどうか) 、どの検索要求に対する検索結果
であるのかをチェックする。もし、その検索要求に対す
る結果を、まだ依頼主( 検索者あるいは別のエージェン
ト) に返送していないのなら、依頼主に返送するため
に、検索結果を蓄えている返送用バッファに結果を追加
する。そして、検索結果を履歴データベース(5) に登録
し、情報資源データベース(4) の内容を更新する。この
検索結果に対する一連の処理フローが図３０である。こ
うして、検索要求を送付したエージェントすべてから結
果が返送されるか、クロック(8) を参照して、タイムア
ウトになるまで待ち続け、返送用バッファの中身を、依
頼主に返送する。

【００５８】履歴データベースの具体的な形式の例は、
図３１に示すように、広告情報、検索要求および検索結
果を受け取った時刻、それらの ID 、関連キーワード、
送付元の組からなる。IDは受け取った情報を識別するた
めのもので、「R236666＠A3」のような形式である。先
頭の文字は、広告情報、検索要求、検索結果かを示すも
ので、それぞれ「P 」、「Q 」、「R 」である。その後
に続く数字列は、情報を区別するために、時刻やプロセ
ス番号などから作った一意的な数字列である。「＠」よ
り後はエージェントの ID である。次にキーワードの列
は、広告情報の場合は情報資源の関連キーワード、検索
要求の場合は検索キーワード、検索結果の場合は検索結
果として得られている情報資源( 一般に複数ある) のす
べての関連キーワードである。

【００５９】最後の送付元エージェントは、どのエージ
ェントが、その情報を直接送ってきたかを示す。このデ
ータベースによって、どこのエージェントからは、どの
ような種類の情報資源に関する情報が集まっているか、
または、どのような種類の情報資源の需要が高いのかを
知ることが可能となる。 ［第九の実施形態］図３２は、広告情報のスプールを持
つ分散検索装置の実施形態である。利用者にとって、検
索は、結果が得られるのが早ければ早いほど喜ばしいこ
とであるが、広告処理は、必ずしもそうであるとは限ら
ない。検索処理を行っている時に、広告依頼を受理した
からといって、その場ですぐに広告処理を行って、検索
処理のパーフォーマンスを犠牲にする必要はなく、後回
しにした方が望ましいことがある。実際、ほとんど誰も
検索したことのないような情報資源に関する広告は、す
ぐに他のエージェントに広告を行ったところで、誰から
も参照されないかもしれず、急いで広告を行っても、利
用者にとってメリットはないかもしれない。これに対
し、多くの利用者から、何度も検索されているような分
野に属する情報資源ならば、すぐにでも利用者は知りた
がるであろうから、急いで広告することに意義がある。
本実施形態の構成はそのような目的で、急いで広告する
必要がない広告情報に関しては、一旦広告情報スプール
(10)に蓄え、バッチ的に広告処理を行うものである。

【００６０】本実施形態での一連の処理フローを図３３
に示す。広告情報を受け取った情報資源データ制御部
(5) は、広告情報に含まれる情報資源の関連キーワード
あるいはその同義語やそれらに関連する単語を使用して
いる検索要求を履歴データベースから検索する。そし
て、その結果から優先度を決定する。例えば、履歴デー
タベース(5) を検索して得られる検索要求の数としても
よい。その優先度がある閾値よりも大きければ、すぐに
広告処理を行い、そうでなければ一旦広告情報スプール
(15)に蓄える。そして、エージェントが暇になった時
点、または広告情報スプール(15)が一杯になった時点、
あるいは、ある一定時間おきに、広告情報スプール(15)
の中の広告情報の処理を始める。この時も、優先度の高
い順に処理を行う。

【００６１】本装置の起動直後では、履歴がないので優
先度は特に決められない。そこで最初はエージェントの
管理者が優先度を決めておいても構わない。また、それ
以後も、管理者の定める優先度と履歴によって決まる優
先度を組合わせて利用しても構わない。 ［第十の実施形態］この実施形態は、履歴データベース
(14)に経路情報も記録し、広告や検索要求のより効果的
な配送を行うことを目的とする。構成図は図２７と同じ
であるが、図２７における履歴データベース(14)の形式
は、図３４のように、履歴データベース(14)の転送元エ
ージェントの代わりに、情報がどのエージェントを経由
してきたを示す転送経路を記録する。転送経路に関する
情報は、広告情報、検索要求や検索結果が同じエージェ
ントを何度も中継されるのを防ぐために、やりとりされ
る情報の中に通ってきたエージェントの ID を保持して
いるので( メールやネットニュースのPathフィールドと
同様) 、そこから抽出することが可能である。

【００６２】それらの情報を受け取ったエージェント
は、その経路情報を、履歴データベース(14)に記録して
おく。キーワードは、広告および検索結果の場合、対象
となる情報資源の関連キーワードの組であり、検索要求
の場合には、検索語として指定されたキーワードの組で
ある。また、転送経路は、広告情報、検索要求あるいは
検索結果が経由されてきたエージェントの列である。例
えば、「A1:A2:A3」はデータがエージェントA3からエー
ジェントA2を経由してエージェントA1まで伝達されてき
たことを示す。

【００６３】例えば、図３４の例では、キーワードkw1
に関係する情報資源の広告情報は、エージェントA3から
多く広告されていることが分かり( 図３４中、白い丸印
を付けた部分が該当。なお、図３４中の丸印は説明のた
めに記入したものであって、実際にデータベースに記録
される情報では無い）、kw1 に関する資源情報は、A3の
付近に集中している可能性が高い。したがって、kw1 に
関する検索要求を受け取った場合に、近隣関係にはない
エージェントA3に直接転送すると、多くの検索結果を得
やすい。

【００６４】逆に、エージェントA7からは、kw1 に関す
る検索要求が多いことが分かり( 黒い丸印を付けた部分
が該当) 、kw1 に関する情報資源に関する広告をA7に直
接転送すると、A7からの検索が効果的に行うことが可能
となる。このような考察に基づいて、情報資源データ制
御部(6) は、随時履歴データベース(5) を参照し、広告
情報や検索要求の内容に応じて、適切なエージェントを
決定し、そこへ広告情報や検索要求の転送を行う。 ［第十一の実施形態］第十の実施形態のような履歴デー
タベース( 図３４) を採用している分散検索装置におい
て、更に図３５のように、エージェントステイトテーブ
ル(16)を設ける。エージェントステイトテーブル(16)
は、広告情報、検索要求や検索結果を他のエージェント
に転送する際に要したレスポンス時間のテーブルであ
る。図３６はそのテーブルの例である。テーブルの各列
は、エージェントID、そのエージェントに対する応答時
間、最後に応答時間を計測した時刻を示す最終チェック
時刻の3 項からなる。応答時間において、「------」
は、正常に通信ができなかったことを示す。

【００６５】この実施形態においては、近隣のエージェ
ントに広告依頼を送る際に、ネットワークの障害など何
らかの理由によって、近隣エージェントに広告依頼を転
送できなかった場合に、代わりに最寄りエージェントに
広告依頼を送ることを目的としている。通常の広告依頼
の処理を行い、近隣のエージェントに広告依頼を送る。
そして、その時の応答時間を計測し、エージェントステ
イトテーブル(16)を更新する。もし、近隣エージェント
に広告依頼を送れなかった場合には( 送れなかったエー
ジェントをＡとする) 、まず図３４に示したような履歴
データベース(14)を検索し、Ａの近隣エージェントを検
索する。そして、図３６のようなエージェントステイト
テーブル(16)を調べ、Ａの近隣エージェントから最も応
答の早いエージェントＢを選択し、そこに広告依頼を転
送する。こうすることで、処理を行えない状態のエージ
ェントを回避し、システム全体として、広告処理を続行
させることが可能となる。検索要求の場合にも、同様の
手順により、障害を回避し、システム全体として、検索
を行うことができる。

【００６６】つまり図３７に示すように、過去において
エージェントＡからＢを経由してきた広告依頼、検索要
求または検索結果を受理したことがあれば、Ａの近隣に
Ｂがいることを知ることができ、Ａに障害が起きても、
直接Ｂに送ることが可能となる。この一連の処理フロー
が、図３８である。 ［第十二の実施形態］図３９は、一旦スプールに入れら
れた広告依頼を、近隣エージェントに送付する際に、履
歴データベース(14)を参照し、ネットワークのトラフィ
ックやエージェントの負荷が比較的低い時間帯を選ん
で、転送を行うようにスケジューリングを行う分散検索
装置の構成図である。

【００６７】図４０は、この実施例のためのエージェン
トステイトテーブル(16)の例である。このテーブルは、
実施形態十一でのエージェントステイトテーブルの例(
図３６）とは違い、各時間帯毎の平均応答時間と実際に
計測を行った回数の情報を保持する。これらの情報は、
おもにリアルタイムに行われる検索要求や検索結果の返
送処理の際に要した時間を基に更新される。この例で
は、平均応答時間と計測回数のみをテーブルに記録して
いるが、実施形態十一のテーブル( 図３６）のように最
終チェック時刻やその時の状態に関する情報などを含め
てもよい。

【００６８】広告依頼を受け取った場合の動作は、実施
形態九のように、優先度の高くない広告情報を、一旦広
告情報スプール(15)に蓄える。その際に、広告スケジュ
ーラ(17)により、どの時間帯にどのエージェントに広告
情報を伝達するかを規定する、広告配送スケジュールが
作成される。例えば、図４０において、エージェントA1
に送らなければならない広告情報は、優先度が非常に低
い場合には、A1の処理が最も少ないと予想される 01:00
から01:59 の時間帯に転送を行うようにし、優先度がや
や高いと思われるものは、ある程度応答時間が大きい時
間帯でも、なるべく早い時間に転送を行うようにする。
そして、その広告配送スケジュールに応じて、指定され
たエージェントに対して広告情報の配送を行う。 ［第十三の実施形態］図４２は、コストを用いて、広告
依頼などの情報の配布範囲を限定した分散検索検索方式
において、履歴データベース(14)に記録されている過去
の広告および検索の実績に応じて、各近隣エージェント
に送る情報の転送に費やすコストを分配する機能を持つ
分散検索装置の構成図である。

【００６９】広告依頼を受け取った場合の動作は、通常
の広告依頼の処理を行い、他のエージェントに広告依頼
を転送する際に、履歴データベース(14)を検索して、過
去においてどのエージェントから、その広告に見合う検
索要求が多く転送されてきたかを調べる。検索要求が沢
山送られてきた方のエージェント群では、その情報に関
する需要が多いと見ることができ、その方向に沢山のコ
ストを費やして、広告を行っておけば、需要の高い地域
のすぐ近くまで広告情報が行き渡り、次回検索要求が発
生する時に、少ないコストで資源情報が発見する可能性
が高いであろう。このような、近隣エージェントに対す
る、広告依頼のコスト配分を行うのが、コストマネージ
ャ(18)の役割である。

【００７０】逆に、検索要求が転送されてきた場合で、
他のエージェントに検索要求を転送する場合には、広告
依頼および検索結果が転送されてきた方向に、該当する
資源情報が多いと考えられるため、その方向に沢山のコ
ストを費やして検索を行えば、多くの検索結果を得るこ
とができ、それだけ良い資源情報を発見することが可能
と考えられる。

【００７１】図４２は、コストの分配の例である。過去
において、あるキーワードに関する広告依頼を、近隣エ
ージェントA 、 B、 Cから、それぞれ、2:5:3 の比率で
受け取っていたならば、当然B の方向には、そのキーワ
ードに関する情報が多いと思われる。そこでB を検索す
るコストを多くした方が、よい検索結果が得られると期
待される。そこで本実施形態では、前記の2:5:3 の比率
で検索コストを分配し、それぞれの近隣エージェントへ
検索要求を転送する。なお、この比率は必ずしも比例さ
せる必要は無く、ある程度の重み付けをするように構成
しても良い。

【００７２】

【発明の効果】以上説明したように、本発明によれば、
情報資源に関する情報の管理を人手に頼らずに自動的行
うことができ、資源情報の管理者は情報の登録や維持に
手間を割く必要がなくなる。おまけに、本発明は、従来
のディレクトリサービスと同様に、基本的には情報資源
提供者の申告に基づくため、ディレクトリサービスの利
点であった情報の質を損うことはない。

【００７３】また、資源情報は分散管理され、各エージ
ェント間の結合に冗長性を持たせることで、ネットワー
ク環境の変化に対して頑健で検索の負荷分散や検索者の
アクセスのしやすさを向上させることができ、広告およ
び検索に利用できるコストを制限することで、資源情報
を広告するエージェントの範囲と検索対象とするエージ
ェントの範囲を限定することができるため、全体の通信
量を低く抑えることができる。そして、ロボットプログ
ラムのような情報資源のサーバへの無用なアクセスを行
わずに済むため、サーバへの高負荷を生むこともない。
更に、情報資源提供者は常に最寄りのエージェントへア
クセスし、資源情報の更新を行うことができ、一方で
は、情報資源検索者による情報資源の利用可能性につい
てのフィードバックがかかり、他のエージェントにも即
座に更新情報が伝わるため、資源情報の陳腐化現象を起
りにくくする効果が期待できる。

【００７４】情報資源検索者による情報資源の評価のフ
ィードバックは、各エージェント上での資源情報の生存
期間を調節することで、有益な情報資源に関する情報は
発見されやすく、そうでないものに関する資源情報は発
見されにくくなり、検索結果として得られる資源情報
は、多数の検索者のフィードバックに基づく全体的な評
価に基づいて順位付けられるので、数多くある情報資源
を取捨選択するだけの知識や技量を持たない情報資源検
索者にとっても、より良い情報資源を発見・選択・利用
しやすくなるという効果が期待できる。そのため、本発
明は、大規模な資源情報の効率的な分散管理および検索
に寄与するところが大きい。

【００７５】更に資源情報の分散検索システムにおいて
広告情報、検索要求や検索結果に関する履歴を保持、利
用する構成を採用することにより、エージェントの負荷
の少ない時間帯での広告情報配信、需要の高い地域への
情報配信、情報を持っていると思われる地域への優先的
な検索、需要とネットワーク環境に応じた広告配信のス
ケジューリング、過去の検索実績に応じたコスト配分に
よる広告情報および検索要求のルーティングなどが可能
となり、省トラフィックおよび効率的な情報配信・情報
検索に寄与するところが大きい。

【図面の簡単な説明】

【図１】本発明の分散検索システムにおける検索装置
（エージェント）の原理説明図である。

【図２】分散検索システムにおける情報資源の広告と検
索に関する説明図である。

【図３】分散検索システムにおける情報資源に関する情
報の伝播の説明図である。

【図４】分散検索システムにおける情報資源の評価の伝
播に関する説明図である。

【図５】検索装置（エージェント）の実施例の構成を示
すブロック図である。

【図６】広告の例を示す図である。

【図７】検索装置（エージェント）における広告の処理
を示すフローチャートである。

【図８】検索要求の例を示す図である。

【図９】検索装置（エージェント）における検索の処理
を示すフローチャートである。

【図１０】検索結果の例を示す図である。

【図１１】第２の実施形態のの大規模分散データベース
における検索装置の構成を示すブロック図である。

【図１２】第２の実施形態の大規模分散データベースの
動作説明図である。

【図１３】第３の実施形態のの大規模分散データベース
における検索装置の構成を示すブロック図である。

【図１４】第３の実施形態の大規模分散データベースの
動作説明図である。

【図１５】第４の実施形態のの大規模分散データベース
における検索装置の構成を示すブロック図である。

【図１６】図１５のフィードバック処理部の処理を示す
フローチャートである。

【図１７】第５の実施形態の大規模分散データベースに
おける検索装置の構成を示すブロック図である。

【図１８】第六の実施形態の大規模分散データベースに
おける検索装置の構成を示すブロック図である。

【図１９】第六の実施形態における広告依頼の処理を示
すフローチャートである。

【図２０】第六の実施形態における検索要求の処理を示
すフローチャートである。

【図２１】第六の実施形態におけるサーチャインターフ
ェースの処理を示すフローチャートである。

【図２２】第七の実施形態における検索装置の構成を示
すブロック図である。

【図２３】履歴データベースを付加した検索装置の原理
構成図。

【図２４】図２３の分散検索システムにおける情報資源
の広告に関する説明図である。

【図２５】図２３の分散検索システムにおける情報資源
の検索の説明図である。

【図２６】図２３の分散検索システムにおける情報資源
の返送の説明図である。

【図２７】第八の実施形態における検索装置の構成を示
すブロック図である。

【図２８】第八の実施形態における広告依頼の処理を示
すフローチャートである。

【図２９】第八の実施形態における検索要求の処理を示
すフローチャートである。

【図３０】第八の実施形態における検索結果の処理を示
すフローチャートである。

【図３１】第八の実施形態における履歴データベースの
例を示す図である。

【図３２】第九の実施形態における検索装置の構成を示
すブロック図である。

【図３３】第九の実施形態における広告依頼の処理を示
すフローチャートである。

【図３４】第十の実施形態における履歴データベースの
例を示す図である。

【図３５】第十一の実施形態における検索装置の構成を
示すブロック図である。

【図３６】第十一の実施形態におけるエージェントステ
イトテーブルの例を示す図である。

【図３７】第十一の実施形態における動作の説明図であ
る。

【図３８】第十一の実施形態における代替エージェント
の検索による広告依頼の処理を示すフローチャートであ
る。

【図３９】第十二の実施形態における検索装置の構成を
示すブロック図である。

【図４０】第十二の実施形態におけるエージェントステ
イトテーブルの例を示す図である。

【図４１】第十三の実施形態における検索装置の構成を
示すブロック図である。

【図４２】第十三の実施形態における動作の説明図であ
る。

【符号の説明】

１ 広告処理部、 ２ 問い合わせ処理部、 ３ エージェントインターフェース、 ４ 情報資源データベース、 ５ 情報資源データ制御部、 ６ プロデューサインターフェース、 ７ サーチャインターフェース、 ８ クロック、 ９ ＤＢ検索フロントエンド、 １０ ＤＢインターフェース、 １１ フィードバック処理部、 １２ 評価依頼処理部。 １３ サーチエンジンインターフェース １４ 履歴データベース １５ 広告情報スプール １６ エージェントステイトテーブル １７ 広告スケジューラ １８ コストマネージャ

Claims (32)

【特許請求の範囲】
1. 【請求項１】ネットワー ク上に複数の計算機が接続さ
   れ、該複数の計算機はそれぞれ情報資源の位置情報を含
   む情報である広告情報を記憶する手段と, 利用者からの
   検索依頼を受け付けて自計算機および前記ネットワーク
   上にある他の計算機が有する広告情報記憶手段を検索す
   る手段と, 該広告情報を前記広告情報記憶手段に登録す
   る依頼を受け付ける手段と、該登録依頼された広告情報
   を前記ネットワーク上にある他の計算機に転送する手段
   とを有して構成される分散検索システムであって、 前記広告情報に付与されるコスト情報に応じて、ネット
   ワーク上で該広告情報が転送される範囲を決定すること
   を特徴とする分散検索システム。
2. 【請求項２】前記ネットワークに接続された他の計算機
   からの検索結果である広告情報を依頼元の計算機に返送
   する際に、検索依頼を中継した計算機を逆に辿りなが
   ら、返送経路上の各計算機に記憶された広告情報を更新
   することを特徴とする請求項１に記載の分散検索システ
   ム。
3. 【請求項３】情報検索者が検索して得られた広告情報に
   対応する情報資源に対して付与する評価値を、前記ネッ
   トワーク上の各計算機上に記憶された広告情報に対応づ
   けて記憶することを特徴とする請求項１に記載の分散検
   索システム。
4. 【請求項４】前記検索結果の中から評価値の良い広告情
   報および/ または該広告情報に対応する情報資源を選択
   して情報検索者に提示することを特徴とする請求項３に
   記載の分散検索システム。
5. 【請求項５】情報資源提供者に対して、自分が広告した
   情報資源の評価値を知らせることを特徴とする請求項３
   に記載の分散検索システム。
6. 【請求項６】前記広告情報に付与された評価値に基づい
   て、前記ネットワーク上の各計算機上に記憶された広告
   情報を記憶する期間の変更および/ または削除を行うこ
   とを特徴とする請求項３に記載の分散検索システム。
7. 【請求項７】ネットワー ク上に複数の計算機が接続さ
   れ、該複数の計算機はそれぞれ情報資源の位置情報を含
   む情報である広告情報を記憶する手段と、利用者からの
   検索依頼を受け付けて自計算機および前記ネットワーク
   に接続された他の計算機が有する情報検索依頼者からの
   検索依頼を受け付けて自計算機および前記ネットワー ク
   に接続された他の計算機が有する広告情報記憶手段を検
   索する手段とを有して構成される分散検索システムであ
   って、 前記検索依頼に付与されるコスト情報に応じて、ネット
   ワーク上で該情報資源を検索する計算機の範囲を決定す
   ることを特徴とする分散検索システム。
8. 【請求項８】前記ネットワークに接続された他の計算機
   からの検索結果である広告情報を依頼元の計算機に返送
   する際に、検索依頼を中継した計算機を逆に辿りなが
   ら、返送経路上の各計算機に記憶された広告情報を更新
   する機能を有することを特徴とする請求項７に記載野分
   散検索システム。
9. 【請求項９】情報検索者が検索して得られた広告情報に
   対応する情報資源に対して付与する評価値を、前記ネッ
   トワーク上の各計算機上に記憶広告情報に対応づけて記
   憶することを特徴とする請求項７に記載の分散検索シス
   テム。
10. 【請求項１０】前記検索結果の中から評価値の良い広告
    情報および/ または該広告情報に対応する情報資源を選
    択して情報検索者に提示することを特徴とする請求項９
    に記載の分散検索システム。
11. 【請求項１１】情報資源提供者に対して、自分が広告し
    た情報資源の評価値を知らせることを特徴とする請求項
    ９に記載の分散検索システム。
12. 【請求項１２】ネットワー ク上に接続され、少なくとも
    情報資源の位置情報を含む情報である広告情報を記憶す
    る手段と有し、利用者からの検索依頼を受け付けて前記
    広告情報記憶手段の検索を行って抽出された広告情報お
    よび／または該広告情報に対応する情報資源の提示を行
    う検索装置であって、 前記広告情報の登録を受け付ける広告処理部と、 前記広告処理手段が受け付けた広告情報を前記広告情報
    記憶手段に記録すると共に前記ネットワークに接続され
    た他の検索装置に該広告情報を転送する処理と、前記ネ
    ットワーク上に接続された他の検索装置から転送された
    広告情報を前記記憶手段に記録すると共に前記転送元の
    他の検索装置を除く前記ネットワーク上に接続された他
    の検索装置に該広告情報を転送する処理とを実行する制
    御部とを備えることを特徴とする分散検索システムにお
    ける検索装置。
13. 【請求項１３】前記制御部は前記広告情報に含まれるコ
    スト情報を基に、当該広告情報を他の検索装置に転送す
    るか否かを決定することを特徴とする請求項１２に記載
    の分散検索システムにおける検索装置。
14. 【請求項１４】前記制御部は前記広告情報に含まれるコ
    スト情報を計算して、当該広告情報のコスト情報を書き
    換えて転送を行うことを特徴とする請求項１３に記載の
    分散検索システムにおける検索装置。
15. 【請求項１５】前記広告処理部は前記広告情報に付与さ
    れた評価値を取得して、当該広告情報の提供者に該評価
    値を提示することを特徴とする請求項１３に記載の分散
    検索システムにおける検索装置。
16. 【請求項１６】ネットワー ク上に接続され、少なくとも
    情報資源の位置情報を含む情報である広告情報を記憶す
    る手段を有し、利用者からの検索依頼を受け付けて前記
    広告情報の検索を行って抽出された広告情報および／ま
    たは該広告情報に対応する情報資源の提示を行う検索装
    置であって、 検索依頼者からの検索依頼を受付け、検索結果を提示す
    るためのインターフェース部と、 前記受け付けた検索依頼に基づいて前記広告情報記憶手
    段の検索を実行すると共に前記ネットワークに接続され
    た他の検索装置に該検索依頼を転送する処理と、前記ネ
    ットワークに接続された他の検索装置から転送された検
    索依頼に基づいて前記広告情報記憶手段の検索を実行す
    ると共に前記転送元の他の検索装置を除く前記ネットワ
    ーク上に接続された他の検索装置に該検索依頼を転送す
    る処理と、前記の各処理により得られた広告情報を依頼
    元であるインターフェース部または転送元の検索装置に
    転送する処理とを実行する制御部とを備えることを特徴
    とする分散検索システムにおける検索装置。
17. 【請求項１７】前記制御部は前記検索依頼の情報に含ま
    れるコスト情報を基に、当該検索依頼を他の検索装置に
    転送するか否かを決定することを特徴とする請求項１６
    に記載の分散検索システムにおける検索装置。
18. 【請求項１８】前記制御部はそれぞれ前記検索依頼の情
    報に含まれるコスト情報を計算して、当該検索依頼の情
    報のコスト情報を書き換えて他の検索装置に転送を行う
    ことを特徴とする請求項１７に記載の分散検索システム
    における検索装置。
19. 【請求項１９】前記インターフェース部が受け取った検
    索結果の広告情報に含まれる情報資源の位置情報に基づ
    いて、情報資源の取得を行う検索部を備えることを特徴
    とする請求項１６に記載の分散検索システムにおける検
    索装置。
20. 【請求項２０】前記制御部は検索して得られた広告情報
    に含まれる情報資源の位置情報に基づいて情報資源の取
    得を行い、依頼元であるインターフェース部または依頼
    元の検索装置に該情報資源を転送することを特徴とする
    請求項１６に記載の分散検索システムにおける検索装
    置。
21. 【請求項２１】情報検索者から情報資源の評価値を受け
    付けて該評価値に基づいて該情報資源に対応する広告情
    報を記憶すべき期間および/ または該広告情報を削除す
    べきか否かを判断するフィードバック処理部を備えると
    共に、 前記制御部は前記フィードバック処理部の判断処理また
    は他の計算機からの依頼に基づいて、広告情報記憶手段
    に記憶された広告情報の記憶すべき期間の変更および/
    または該広告情報を削除する処理を行う処理と、他の計
    算機に前記広告情報の記憶すべき期間の変更および/ ま
    たは該広告情報を削除する処理の実行を依頼する処理を
    実行することを特徴とする請求項１６に記載の分散検索
    システムにおける検索装置。
22. 【請求項２２】前記インターフェース部は、得られた検
    索結果の中から評価値の良い広告情報および/ または該
    広告情報に対応する情報資源を選択して情報検索者に提
    示することを特徴とする請求項１６に記載の分散検索シ
    ステムにおける検索装置。
23. 【請求項２３】検索要求に含まれるキーワードを抽出し
    て、該キーワードを用いて外部のサーチエンジンを用い
    て検索処理を行い、得られた情報資源のデータを情報検
    索者に提示するために前記インターフェース部に送出す
    るサーチエンジンインターフェース部を備えることを特
    徴とする請求項１６に記載の分散検索システムにおける
    検索装置。
24. 【請求項２４】前記制御部は前記得られた情報資源のデ
    ータを解析して該情報資源に対応する広告情報を作成
    し、広告情報記憶手段に登録することを特徴とする請求
    項２３に記載の分散検索システム。
25. 【請求項２５】ネットワー ク上に接続され、少なくとも
    情報資源の位置情報を含む情報である広告情報を記憶す
    る手段と有し、利用者からの検索依頼を受け付けて前記
    広告情報記憶手段の検索を行って抽出された広告情報お
    よび／または該広告情報に対応する情報資源の提示を行
    う検索装置であって、 前記広告情報の登録を受け付ける広告処理部と、 前記広告処理手段が受け付けた広告情報を前記広告情報
    記憶手段に記録すると共に前記ネットワークに接続され
    た他の検索装置に該広告情報を転送する処理と、前記ネ
    ットワーク上に接続された他の検索装置から転送された
    広告情報を前記記憶手段に記録すると共に前記転送元の
    他の検索装置を除く前記ネットワーク上に接続された他
    の検索装置に該広告情報を転送する処理とを実行する制
    御部と、 該検索装置が受信した広告情報、検索依頼、検索結果の
    各情報のうち少なくともいずれかの一つの種類の情報に
    ついて、該情報の転送元および／又は転送経路の情報を
    含めて履歴として記録する履歴データベースとを備える
    ことを特徴とする分散検索システムにおける検索装置。
26. 【請求項２６】前記履歴データベースは少なくとも蓄積
    した情報に関するキーワードと該情報の転送元および／
    又は転送経路の情報とを対応づけて記録することを特徴
    とする請求項２５に記載の分散検索システムにおける検
    索装置。
27. 【請求項２７】広告情報を蓄積する広告情報スプールを
    設けると共に、 前記制御部は、受信した広告情報に対応する検索要求を
    前記履歴データベースより検索し、該検索結果に基づい
    て前記受信した広告情報の優先度を決定し、該優先度に
    基づいて前記受信した広告情報の転送の時期を決定し、
    ただちに転送されない広告情報については前記広告情報
    スプールに蓄積することを特徴とする請求項２５に記載
    の分散検索システムにおける検索装置。
28. 【請求項２８】前記制御部は検索依頼に含まれるキーワ
    ードを基に前記履歴データベースを検索し、該キーワー
    ドが含まれる広告情報の転送元および／又は転送経路に
    基づいて前記検索依頼の転送先を決定することを特徴と
    する請求項２６に記載の分散検索システムにおける検索
    装置。
29. 【請求項２９】前記制御部は広告依頼に含まれるキーワ
    ードを基に前記履歴データベースを検索し、該キーワー
    ドが含まれる検索依頼の転送元および／又は転送経路に
    基づいて前記広告依頼の転送先を決定することを特徴と
    する請求項２６に記載の分散検索システムにおける検索
    装置。
30. 【請求項３０】情報を他の検索装置に転送する際に要し
    たレスポンス時間を前記他の検索装置毎に記録するエー
    ジェントステイトテーブルを設け、 前記制御部は、他の検索装置のうちの一つの検索装置に
    対する情報の転送に失敗したときに、前記履歴データベ
    ースを検索して該履歴データベースに含まれる転送経路
    の情報から前記転送に失敗した検索装置に対して論理的
    に近隣にある他の検索装置を求め、求められた前記他の
    検索装置のうち最も応答が早い検索装置を前記エージェ
    ントステイトテーブルより求め、該求められた他の検索
    装置を選択して前記転送に失敗した情報の転送を行うこ
    とを特徴とする請求項２５に記載の分散検索システムに
    おける検索装置。
31. 【請求項３１】情報を他の検索装置に転送する際に要す
    る応答時間を予め設定した時間帯毎に求めて前記他の検
    索装置毎に記録するエージェントステイトテーブルと、 前記エージェントステイトテーブルを参照して前記他の
    検索装置毎に時間帯毎の負荷の高さを推定し、該推定し
    た負荷の高さと転送すべき広告情報の優先度とに基づい
    て前記広告スプールに蓄積された広告情報を転送する時
    間帯を転送先の検索装置毎に決定する広告スケジューラ
    を備えたことを特徴とする請求項２７に記載の分散検索
    システムにおける検索装置。
32. 【請求項３２】受け付けた情報に含まれるコスト情報
    と、前記履歴データベースに記録された該受け付けた情
    報に対応する情報の経路情報とに基づいて、転送先の他
    の検索装置毎に新たなコスト情報を算出して前記受け付
    けた情報に含まれるコスト情報を該算出したコスト情報
    に書き換え、前記他の検索装置に情報の転送を行うコス
    トマネージャを設けたことを特徴とする請求項２５に記
    載の分散検索システムにおける検索装置。