JP3363752B2 - 仲介エージェント装置およびそれを実現するプログラム記憶媒体 - Google Patents

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は，エージェント間通
信を仲介する仲介エージェント装置およびそれを実現す
るプログラム記憶媒体に関する。

【０００２】ＷＷＷが成功を納め，インターネットが非
常な勢いで広がっている。これに伴い膨大な量の情報が
インターネットに置かれ始めている。インターネットの
他にもオンラインデータベースやその他の電子的な形で
膨大な量の情報がある。

【０００３】しかし，ユーザが本当に欲しい情報を見つ
け出すのは難しい。例えばリンクを一つずつたどってい
く方法であっても，あるいはキーワードサーチで得られ
る大量のヒットのリストであっても，実際に欲しい情報
（ページ）を見つけるためにはそれらの画面を一つずつ
見なければならない場合が多い。このようにせっかくあ
る情報を有効利用できずにいるユーザの状況がみられ，
忙しいユーザにとっては，時間的にも精神的にも大きな
負担となっている。そのため，大量の分散情報を統合的
に扱うことのできる技術の確立が，ますます重要になっ
てきている。

【０００４】

【従来の技術】エージェントとは，ソフトウェアをソフ
トウェアエージェントという自律モジュールとして，共
通の言語（例えばＡＣＬ(Agent Communication Languag
e)）を話すことにより，ソフトウェアを連携させること
を可能にする技術である。

【０００５】しかし，共通の言語を話したり聞いたりす
るだけでは，連携はうまくいかない。あるエージェント
の依頼に対して，その要求に応えるサービスを提供でき
るエージェントがどこにいるのかが分からなければ連携
は始まらない。

【０００６】また，エージェント間の共通の言語（ＡＣ
Ｌなど）は，通常，メッセージの文法は定めているが，
メッセージの中身を表すための単語などは定めていな
い。したがって，もしサービスを提供できるようなエー
ジェントを見つけたとしても，そのエージェントが理解
できる言葉を使って依頼しなければ，うまく処理がなさ
れない。

【０００７】

【発明が解決しようとする課題】このように，従来は，
せっかく共通の言語を使ってエージェントが連携する基
盤が存在していても，エージェント同士をよりうまく連
携させる上位の仕組みが整備されていなかった。

【０００８】本発明は，一般的に，情報源のエージェン
トからの宣伝メッセージに基づいて，他のエージェント
からの依頼メッセージに対し，実際のサービスを提供す
るエージェントをいろいろな手段（仲立ち，推薦，委
託）によって結び付けることを目的とする。

【０００９】またその際に，他のエージェントに対して
実際にそのメッセージを処理できるかどうかを判断する
こと，あるいはそのエージェントが理解できる言葉に変
換することなどを目的とする。

【００１０】

【課題を解決するための手段】図１は，本発明の原理説
明図である。図１において，１は仲介エージェント装置
（これをファシリテータともいう），２はメッセージ送
受信部，３はメッセージ処理部，４はディレクトリ保持
部，５はセッション管理部，６は他エージェント装置，
７はネットワークを表す。

【００１１】メッセージ送受信部２は，他エージェント
装置６にメッセージを送信したり，他エージェント装置
６からメッセージを受信したりする手段である。メッセ
ージ処理部３は，メッセージ分配部３１と，メッセージ
の内容に対応した処理手段として，宣伝処理部３２，仲
立ち処理部３３，推薦処理部３４，委託処理部３５，予
約処理部３６，言明処理部３７を持ち，各メッセージに
応じて適切な処理を実行する。

【００１２】メッセージ分配部３１は，メッセージを分
配する手段である。具体的には，メッセージ送受信部２
から受けたメッセージの種類に応じて，以下の各処理手
段へメッセージを分配する。

【００１３】宣伝処理部３２は，宣伝メッセージを処理
する手段である。具体的には，宣伝メッセージによって
通知された他エージェント装置６の処理能力などに関す
る情報（宣伝情報）をディレクトリ保持部４に登録す
る。

【００１４】仲立ち処理部３３は，仲立ちを依頼する仲
立ちメッセージを処理する手段である。具体的には，デ
ィレクトリ保持部４の情報に基づき，依頼メッセージを
転送し，それらに対する回答メッセージの処理をセッシ
ョンとしてセッション管理部５に登録する。

【００１５】推薦処理部３４は，推薦を依頼する推薦メ
ッセージを処理する手段である。具体的には，ユーザエ
ージェントからの推薦メッセージに対して，ディレクト
リ保持部４の情報に基づき，適切な他エージェント装置
６を推薦するメッセージを送り返す。

【００１６】委託処理部３５は，適切な他エージェント
装置６へのメッセージ送信の委託を依頼する委託メッセ
ージを処理する手段である。具体的には，ユーザエージ
ェントからの委託メッセージに対して，ディレクトリ保
持部４の情報に基づき，適切な他エージェント装置６を
選び，もともとのメッセージにあった処理を委託するメ
ッセージを他エージェント装置６に送り出す。

【００１７】予約処理部３６は，予約を依頼する予約メ
ッセージを処理する手段である。具体的には，セッショ
ン管理部５のセッション保持部５１に予約されたことを
実行するための適切なセッションを登録する。

【００１８】言明処理部３７は言明メッセージを処理す
る手段である。具体的には，言明メッセージをセッショ
ン管理部５の言明保持部５２に登録する。言明メッセー
ジは，仲立ちメッセージによって他エージェント装置６
に依頼したものに対する他エージェント装置６からの回
答メッセージである。

【００１９】ディレクトリ保持部４は，他エージェント
装置６の能力などの情報を保持する手段であり，対応エ
ージェント保持部４１，対応可能メッセージ形式保持部
４２，翻訳保持部４３を持つ。対応エージェント保持部
４１，対応可能メッセージ形式保持部４２および翻訳保
持部４３は，それぞれが保持している情報に関して，登
録，検索，更新，あるいは削除をすることができる。

【００２０】対応エージェント保持部４１は，特定の依
頼に対して，どのエージェントで対応できるかの情報を
保持する手段である。対応可能メッセージ形式保持部４
２は，あるエージェントがどういった形式のメッセージ
に対応可能であるかの情報を保持する手段である。

【００２１】翻訳保持部４３は，メッセージをあるエー
ジェントが理解できる形式に翻訳するための情報を対応
関係としてリスト等の形式で保持する手段である。セッ
ション管理部５は，登録されているセッションを実行す
る手段であり，セッション保持部５１，言明保持部５２
を持つ。

【００２２】セッション保持部５１は，実行するセッシ
ョンを保持する手段である。削除されるまで繰り返し実
行される処理（セッション）がリスト等の形式で保持さ
れている。

【００２３】言明保持部５２は，他エージェント装置６
からの言明メッセージを保持する手段である。本発明
は，以下のように作用する。

【００２４】メッセージ送受信部２で受け取られたメッ
セージは，メッセージ処理部３の要請でメッセージ処理
部３に渡され，メッセージ分配部３１で適切な処理部３
１〜３７に渡される。

【００２５】各処理部３１〜３７では，ディレクトリ保
持部４に情報を登録したり，ディレクトリ保持部４から
情報を引き出したり，セッション管理部５にメッセージ
やセッションを登録したりする。

【００２６】一方，セッション管理部５では適当なルー
ル（通常一定時間ごと）に基づいて，登録されているセ
ッションの内容を実行する。これによって，仲立ちした
メッセージを複数の他エージェント装置６に送った場合
に，回答メッセージの待ち合わせなどを行う。

【００２７】

【発明の実施の形態】以下に，本発明の実施の形態の一
例を説明する。初めに図１に示す各処理手段の処理の流
れおよびデータの構造を説明する。

【００２８】〔１〕メッセージ送受信部 図２は，メッセージ送受信部２の処理フローチャートで
ある。メッセージ送受信部２の処理は，図２（Ａ）に示
すメッセージ受信のループと，図２（Ｂ）および（Ｃ）
に示す２つの受動的な処理からなる。

【００２９】メッセージ受信のチェックの処理では，図
２（Ａ）に示すように，受信したメッセージがあるかど
うかをチェックし（Ｓ１０），受信メッセージがある場
合には，受信したメッセージをリストに保存しておく
（Ｓ１１）。

【００３０】次に，受信メッセージの有無の問い合わせ
に対しては，受動的に図２（Ｂ）に示す処理を行う。新
しい受信メッセージがあるかどうかについてのメッセー
ジ処理部３からの問い合わせがあったならば（Ｓ１
２），ステップＳ１３へ進み，受信メッセージの保存リ
ストをチェックする。

【００３１】受信メッセージの保存リストに新しい受信
メッセージがある場合には，その受信メッセージをメッ
セージ処理部３へ渡し（Ｓ１４），その受信メッセージ
を保存リストから消す（Ｓ１５）。

【００３２】新しい受信メッセージがない場合には，受
信メッセージがない旨をメッセージ処理部３に知らせる
（Ｓ１６）。また，メッセージ送信依頼に対しては，受
動的に図２（Ｃ）に示す処理を行う。

【００３３】メッセージ送信依頼を受けたならば（Ｓ１
７），ステップＳ１８へ進み，そのメッセージを指定さ
れた他エージェント装置６へ送る。以上の処理のために
メッセージ送受信部２に必要なデータ構造は，受信した
メッセージのリストおよび受信メッセージがどこまで読
み出されたのかのポインタである。

【００３４】〔２〕メッセージ処理部およびメッセージ
分配部 図３は，メッセージ処理部３およびメッセージ分配部３
１の処理フローチャートである。

【００３５】メッセージ処理部３は，メッセージ送受信
部２に新しい受信メッセージがあるかどうかを問い合わ
せる（Ｓ３１）。受信メッセージがある場合には，メッ
セージ送受信部２からそのメッセージを受けとって，メ
ッセージ分配部３１に渡す（Ｓ３２）。メッセージ分配
部３１は，そのメッセージに対応した処理部３１〜３７
にそのメッセージを渡す（Ｓ３３）。

【００３６】メッセージ処理部３のメッセージ分配部３
１に必要なデータ構造は，メッセージのパターンとそれ
に対応した処理部３１〜３７のリストである。 〔３〕宣伝処理部 図４は，宣伝処理部３２の処理フローチャートである。

【００３７】宣伝処理部３２は，メッセージ分配部３１
からメッセージを受け取る（Ｓ４１）。受け取ったメッ
セージを解析し（Ｓ４２），その解析結果をもとに他エ
ージェント装置６の能力等に関する情報をディレクトリ
保持部４のそれぞれ適切な部分に登録する（Ｓ４３）。

【００３８】〔４〕仲立ち処理部 図５は，仲立ち処理部３３の処理のフローチャートであ
る。仲立ち処理部３３は，メッセージ分配部３１から仲
立ちメッセージを受け取る（Ｓ５１）。メッセージを受
け取ったならば，ディレクトリ保持部４の対応エージェ
ント保持部４１に登録されている全てのエージェントの
それぞれについて，以下のステップＳ５３からステップ
Ｓ５８までの処理を繰り返す（Ｓ５２）。

【００３９】まず，対応エージェント保持部４１に登録
されているうち処理の終わっていないエージェントをと
ってくる（Ｓ５３）。次に，翻訳保持部４３の情報によ
り，そのエージェントの理解できる形にメッセージを変
換する（Ｓ５４）。

【００４０】続いて，対応エージェント保持部４１の情
報により，変換されたメッセージがそのエージェントが
対応している種類（カテゴリ）のものかどうかを判断す
る（Ｓ５５）。そのエージェントが対応している種類の
ものでない場合には，ステップＳ５８へ進む。対応して
いる種類のものである場合には，さらに対応可能メッセ
ージ形式保持部４２の情報により，そのエージェントが
回答できるものであるか否かをチェックする（Ｓ５
６）。回答できるかどうかは，そのエージェントが持つ
データベースに，質問された条件や回答等の項目がある
かどうかによって判断する。回答できないものである場
合には，ステップＳ５８へ進む。回答できるものである
場合には，そのエージェントに仲立ちメッセージをもと
に生成した処理依頼のメッセージを送る（Ｓ５７）。

【００４１】その後，対応エージェント保持部４１に登
録されている全てのエージェントについて処理が終了し
たかどうかを判断し（Ｓ５８），全てのエージェントに
ついて処理が終了した場合には，ステップＳ５９へ進
み，まだ処理が終了していないエージェントがある場合
には，ステップＳ５３へ戻る。

【００４２】以上のステップＳ５３からステップＳ５８
の処理ループで，少なくとも一つのエージェントにメッ
セージを送れたかどうかを判断する（Ｓ５９）。少なく
とも一つのエージェントにメッセージを送れた場合に
は，セッション管理部５に回答メッセージの待ち合わせ
の処理や，必要であればタイムアウト処理などを含んだ
セッションを登録し（Ｓ６０），処理を終了する。エー
ジェントに一つもメッセージを送信しなかった場合に
は，メッセージの送信元に仲立ちができない旨のメッセ
ージを送り（Ｓ６１），処理を終了する。

【００４３】図５の処理フローチャートにおいて，ステ
ップＳ５４の処理は，翻訳の在り方（ポリシー）によ
り，ステップＳ５６の処理あるいはステップＳ５７の処
理の前に行うという形であってもよい。また，ステップ
Ｓ５５の処理を行っただけで，ステップＳ５６の処理を
行わないでメッセージを送ってしまう場合もある。

【００４４】〔５〕推薦処理部 図６は，推薦処理部３４の処理のフローチャートであ
る。メッセージ分配部３１から推薦を依頼する推薦メッ
セージを受け取る（Ｓ７１）。推薦先を決定するため，
まず推薦先のリストを空リストにする（Ｓ７２）。その
後，対応エージェント保持部４１に登録されている全て
のエージェントのそれぞれについて，以下のステップＳ
７４からステップＳ７９までの処理を繰り返す（Ｓ７
３）。

【００４５】まず，対応エージェント保持部４１に登録
されているうち処理の終わっていないエージェントをと
ってくる（Ｓ７４）。次に，翻訳保持部４３の情報によ
り，そのエージェントの理解できる形にメッセージを変
換する（Ｓ７５）。

【００４６】続いて，対応エージェント保持部４１の情
報により，変換されたメッセージがそのエージェントが
対応している種類（カテゴリ）のものかどうかを判断す
る（Ｓ７６）。そのエージェントが対応している種類の
ものでない場合には，ステップＳ７９へ進む。対応して
いる種類のものである場合には，さらに対応可能メッセ
ージ形式保持部４２の情報により，そのエージェントが
回答できるものであるかどうかをチェックする（Ｓ７
７）。回答できるかどうかは，そのエージェントが持つ
データベースに，質問された条件や回答等の項目がある
かどうかによって判断する。回答できないものである場
合には，ステップＳ７９へ進む。回答できるものである
場合には，そのエージェントを推薦先のリストに加える
（Ｓ７８）。

【００４７】ステップＳ７９では，対応エージェント保
持部４１に登録されている全てのエージェントについて
処理が終了したかどうかを判断する。まだ全てのエージ
ェントについて処理が終了していない場合には，ステッ
プＳ７４へ戻って，未処理のエージェントについて同様
に処理を繰り返す。

【００４８】全てのエージェントについて処理が終了し
た場合には，ステップＳ８０により推薦メッセージの送
信元に推薦先のリストをメッセージとして送り，処理を
終了する。

【００４９】図６に示す処理フローチャートにおいて，
ステップＳ７５の処理は，翻訳の在り方（ポリシー）に
より，ステップＳ７７の処理の前という形であってもよ
い。また，ステップＳ７７の処理を行わないで，ステッ
プＳ７６の処理だけで推薦メッセージを送るという場合
もある。

【００５０】〔６〕委託処理部 図７は，委託処理部３５の処理のフローチャートであ
る。委託処理部３５の処理は，送るメッセージが委託メ
ッセージになるだけで，基本的には仲立ち処理部３３の
処理と同じである。

【００５１】委託処理部３５は，メッセージ分配部３１
から委託メッセージを受け取る（Ｓ９１）。メッセージ
を受け取ったならば，ディレクトリ保持部４の対応エー
ジェント保持部４１に登録されている全てのエージェン
トのそれぞれについて，以下のステップＳ９３からステ
ップＳ９８までの処理を繰り返す（Ｓ９２）。

【００５２】まず，対応エージェント保持部４１に登録
されているうち処理の終わっていないエージェントをと
ってくる（Ｓ９３）。次に，翻訳保持部４３の情報によ
り，そのエージェントの理解できる形にメッセージを変
換する（Ｓ９４）。

【００５３】続いて，対応エージェント保持部４１の情
報により，変換されたメッセージがそのエージェントが
対応している種類（カテゴリ）のものかどうかを判断す
る（Ｓ９５）。そのエージェントが対応している種類の
ものでない場合には，ステップＳ９８へ進む。対応して
いる種類のものである場合には，さらに対応可能メッセ
ージ形式保持部４２の情報により，そのエージェントが
回答できるものであるか否かをチェックする（Ｓ９
６）。回答できるかどうかは，そのエージェントが持つ
データベースに，質問された条件や回答等の項目がある
かどうかによって判断する。回答できないものである場
合には，ステップＳ９８へ進む。回答できるものである
場合には，そのエージェントに委託メッセージをもとに
生成した委託メッセージを送る（Ｓ９７）。

【００５４】その後，対応エージェント保持部４１に登
録されている全てのエージェントについて処理が終了し
たかどうかを判断し（Ｓ９８），全てのエージェントに
ついて処理が終了した場合には，ステップＳ９９へ進
み，まだ処理が終了していないエージェントがある場合
には，ステップＳ９３へ戻る。

【００５５】以上のステップＳ９３からステップＳ９８
の処理ループで，少なくとも一つのエージェントにメッ
セージを送れたかどうかを判断する（Ｓ９９）。少なく
とも一つのエージェントにメッセージを送れた場合に
は，委託メッセージを送ったエージェントのリストを，
委託メッセージの送信元へ返信する（Ｓ１００）。エー
ジェントに一つもメッセージを送れなかった場合には，
ステップＳ１０１により，委託メッセージの送信元に委
託不可のメッセージを送り，処理を終了する。

【００５６】図７の処理フローチャートにおいて，ステ
ップＳ９４の処理は，翻訳の在り方（ポリシー）によ
り，ステップＳ９６の処理あるいはステップＳ９７の処
理の前に行うという形であってもよい。また，ステップ
Ｓ９６の処理を行わないで，ステップＳ９５の処理を行
っただけでメッセージを送る場合もある。

【００５７】〔７〕予約処理部 図８は，予約処理部３６の処理のフローチャートであ
る。ステップＳ１１１では，予約処理部３６は，メッセ
ージ分配部３１から予約メッセージを受け取る。ステッ
プＳ１１２では，セッション保持部５１に予約内容を実
行するセッションを登録する。

【００５８】〔８〕言明処理部 図９は，言明処理部の処理のフローチャートである。ス
テップＳ１２１では，言明処理部３７は，メッセージ分
配部３１からメッセージを受け取る。ステップＳ１２２
では，言明保持部５２にそのメッセージを登録する。

【００５９】

〔９〕ディレクトリ保持部 ディレクトリ保持部４は，指定された対応エージェント
保持部４１，対応可能メッセージ形式保持部４２，翻訳
保持部４３に情報を登録，検索，更新，あるいは削除す
るように指示されると，その指定された保持部４１〜４
３に情報を登録，検索，更新，あるいは削除する。

【００６０】対応エージェント保持部４１，対応可能メ
ッセージ形式保持部４２，翻訳保持部４３は，それぞれ
が保持している情報に関して，登録，検索，更新，ある
いは削除することができる。

【００６１】対応エージェント保持部４１には，メッセ
ージのパターンあるいはメッセージの種類を指定する情
報等とエージェントとの対応関係をリストなどの形で保
持する。

【００６２】対応可能メッセージ形式保持部４２には，
あるエージェントまたはあるエージェントグループが処
理することのできるメッセージの形式に関する情報を，
そのエージェント（グループ）と対応させてリストなど
の形で保持する。

【００６３】翻訳保持部４３には，あるエージェントま
たはあるエージェントグループからのメッセージを他の
エージェント，あるいは他のエージェントグループが理
解できるメッセージに変換するための情報を対応関係と
してリストなどの形で保持している。

【００６４】〔１０〕セッション管理部 セッション管理部５は，セッション保持部５１と言明保
持部５２とを持ち，それぞれが保持している情報に関し
て，登録，検索，更新，あるいは削除することができ
る。

【００６５】セッション保持部５１には，削除されるま
で繰り返し実行される処理（セッション）がリストなど
の形で保持されている。このセッションには自分自身を
削除する処理を書くことがある。

【００６６】言明保持部５２には，他エージェント装置
６からの言明メッセージがリストなどの形で保持されて
いる。図１０は，セッション管理部５の処理のフローチ
ャートである。

【００６７】セッション管理部５は，セッション保持部
５１にある全てのセッションのそれぞれについて，ステ
ップＳ１３２〜ステップＳ１３３の処理を繰り返す（Ｓ
１３１）。

【００６８】ステップＳ１３２では，セッション保持部
５１に登録されているセッションのうちまだ実行されて
いないセッションをとってくる。次に，そのセッション
を実行する（Ｓ１３３）。その後，セッション保持部５
１に登録されている全てのセッションを実行したかどう
かを判断し（Ｓ１３４），全てのセッションを実行して
いない場合には，ステップＳ１３２以降の処理を繰り返
す。

【００６９】全てのセッションを実行した場合には，ス
テップＳ１３５へ進み，一定の時間が経過したなどの所
定の基準によって，セッション保持部５１，言明保持部
５２の情報を削除する。また，一定時間の経過あるいは
何らかの別の基準で処理を一時的に止め，ステップＳ１
３２へ戻る。なお，ステップＳ１３５，Ｓ１３６の処理
を省略した構成をとることもできる。

【００７０】

【実施例】以下，本発明の具体的な実施例について説明
する。本実施例では，ネットワーク上に分散された異な
る用語体系を用いて構築されているような複数のデータ
ベースを利用検索するシステムを考える。ネットワーク
上に構築されたデータベースの中に，小田中市場データ
ベースと，百道浜市場データベースとがあるとする。

【００７１】ここで，他エージェント装置からくる具体
的な処理として検索の場合を想定しているが，もちろん
処理は検索だけに限定されるわけではない。図１１は，
本実施例のシステム構成例を示す。図１１において，１
００は仲介エージェント装置（ファシリテータ），２１
０ａ〜ｃはユーザエージェント（ＵＡ），２２０ａ〜ｃ
はユーザのブラウザ，３１０ａ〜ｃはデータベースエー
ジェント（ＤＢＡ），３２０ａ〜ｃは各種のデータベー
ス（ＤＢ）を表す。

【００７２】ファシリテータ１００，ユーザエージェン
ト２１０，ＤＢエージェント３１０間は，ＡＣＬ（Agen
t Communication Language）により通信を行う。ＡＣＬ
は，エージェント間でやりとりをするメッセージを規定
するエージェント間通信言語であり，情報の内容などの
知識を宣言的に表現する知識表現言語ＫＩＦ（Knowledg
e Interchange Format）と，エージェント間通信のトラ
ンザクションを規定する動詞にあたる部分（パーフォー
マティブ（performative）と呼ぶ）を規定する言語であ
るＫＱＭＬ（Knowledge Query and Manipulation Langu
age)，およびエージェント間で共通する共通用語体系で
あるオントロジー（Ontology）からなっている。

【００７３】エージェント同士がＡＣＬにより通信を行
うためには，実際の情報をエージェントの持つ知識（仮
想知識ベース（ＶＫＢ）と呼ぶ）として抽象化する必要
がある。図１１に示す構成においては，扱う情報がデー
タベースであるため，各データベース３２０の情報を抽
象化したものがデータベースエージェント３１０の持つ
ＶＫＢとなる。ここで，検索機能を実現するためのＶＫ
Ｂを，「指定したフィールド値を取り出す操作が可能な
レコードの集合」と定義する。

【００７４】ＫＩＦによるＶＫＢの定義は，以下のよう
になる。 (defrelation database (?db) := (and (set ?db) (exists (?set-of-fields) (and (set ?set-of-fields) (not (empty ?set-of-fields)) (forall (?record ?field) (=> (member ?record ?db) (member ?field ?set-of-fields) (defined (field-value ?record ?field)))))))) ＶＫＢへのアクセスは，ＶＫＢにより記述されている知
識の一部を条件によって切り出すこと，切り出した知識
に対する操作（取り出す，消去する，書き換える等）を
指定すること，からなる。

【００７５】ＡＣＬでＶＫＢにアクセスする場合には，
ＫＩＦの文により対象となるＶＫＢ上の知識を切り出
し，それに対する操作をＫＱＭＬのパーフォーマティブ
で指定する。

【００７６】ＫＱＭＬのパーフォーマティブとして，例
えば，「ask-all/ask-one （質問する）」，「reply
（回答する）」，「advertise （宣伝（アドバタイズ）
する）」，「sorry （回答不能を伝える）」等がある。

【００７７】ＫＩＦの文としては，例えば，(1) ＶＫＢ
のレコードの特定のフィールドとその値とを対応づける
リレーション（商品名，カテゴリ等），(2) 数値同士を
比較する算術的なリレーション（＝＜，＝＞等），(3)
リレーション同士の論理的組合わせを定義するリレーシ
ョン（AND,OR等），(4) 条件のあてはまるものに適応し
て二次的な結果を得るリレーション（レコード数，合
計，平均，最大，最小，先頭，最後等），を定義する。

【００７８】データベースエージェント３１０が，ファ
シリテータ１００へ，自己の能力をアドバタイズするこ
とにより，他のエージェント（例えばユーザエージェン
ト２１０）からのアクセスが可能になる。ＶＫＢの名
前，ＶＫＢで扱うことのできるカテゴリ，ＶＫＢに現れ
るフィールド，ＶＫＢで用いるオントロジー，ＶＫＢへ
のアクセスで利用できるリレーション等をアドバタイズ
する。

【００７９】アドバタイズは，例えば，以下のように行
う。 ((database百道浜市場) (=> (memer ?x 百道浜市場) (isa ?x 農産物) (field-definition 百道浜市場 商品名 'is-text) (field-definition 百道浜市場 カテゴリ名 'is-tex
t) (field-definition 百道浜市場 カテゴリコード 'is-
number) (field-definition 百道浜市場 生産者名 'is-text) ... (default-ontology standard.database.kif) (allows-relational-db-query 百道浜市場))) この例では，ＶＫＢの名前が百道浜市場であり，扱うカ
テゴリは農産物，フィールドとしては商品名，カテゴリ
名，カテゴリコード，生産者名等が存在し，標準のオン
トロジーを用いることをアドバタイズしている。また，
上記の(1) から(4) で定められるＫＩＦの文の全てを扱
うことが可能な場合には，(allows-relational-db-quer
y 百道浜市場) という表現でアドバタイズする。

【００８０】図１２は，本発明の実施例による仲介エー
ジェント装置（ファシリテータ）１００の構成例を示
す。図１２において，１２０はＫＱＭＬメッセージ送受
信部，１３０はＫＱＭＬメッセージ処理部，１３１はパ
ーフォーマティブ（Performative）処理部対応部，１３
２は宣伝処理部，１３３仲立ち処理部，１３４は推薦処
理部，１３５は委託処理部，１３６は予約処理部，１３
７は言明処理部，１４０はディレクトリ保持部，１４１
はカテゴリエージェント保持部，１４２は対応可能メッ
セージ形式保持部，１４３は翻訳保持部，１５０はセッ
ション管理部，１５１はセッション保持部，１５２は言
明保持部を表す。

【００８１】ＫＱＭＬメッセージ送受信部１２０は，通
信ライブラリを利用して，他のエージェント装置と通信
を行う。受信したメッセージは保存しておき，関数呼出
しにより読み出す。

【００８２】ＫＱＭＬメッセージ処理部１３０のパフォ
ーマティブ処理部対応部１３１は，ＫＱＭＬメッセージ
の解析を行い，各パフォーマティブに対応する処理部１
３２〜１３７を呼び出す。宣伝処理部１３２はパーフォ
ーマティブのadvertise を処理し，仲立ち処理部１３３
はパーフォーマティブのask-all/ask-one を処理し，推
薦処理部１３４はパーフォーマティブのrecommend を処
理し，委託処理部１３５はパーフォーマティブのrecrui
t を処理し，予約処理部１３６はパーフォーマティブの
subscribe を処理し，言明処理部１３７はパーフォーマ
ティブのreplyを処理する。

【００８３】各処理部１３２〜１３７は，ディレクトリ
保持部１４０に保存されている情報を利用して処理を行
い，結果をセッション管理部１５０へ送る。ディレクト
リ保持部１４０は，カテゴリエージェント保持部１４
１，対応可能メッセージ形式保持部１４２，翻訳保持部
１４３を持ち，データベースエージェント３１０のアド
バタイズ情報（取り扱い可能なカテゴリ，フィールド
等）を保存し，ＫＱＭＬメッセージ処理部１３０の各処
理部１３２〜１３７の要求に応える。

【００８４】カテゴリエージェント保持部１４１では，
指定されたカテゴリを取り扱うことができるデータベー
スエージェント３１０を回答する。図１３は，カテゴリ
エージェント保持部１４１が保持するデータ形式の例を
示す。カテゴリエージェント保持部１４１のリストに
は，カテゴリ名，エージェント名，データベース名を保
持する。

【００８５】対応可能メッセージ形式保持部１４２で
は，指定されたメッセージを取り扱うことができるデー
タベースエージェント３１０を回答する。図１４は，対
応可能メッセージ形式保持部１４２が保持するデータ形
式の例を示す。対応可能メッセージ形式保持部１４２の
リストには，エージェント名，データベース名，条件を
保持する。条件の部分には，実際のメッセージを付加し
て実行すると，そのメッセージが各エージェントで受け
付け可能な形式であるかどうかをチェックする関数（受
付可能なメッセージなら特定コードを返す関数）の実際
の内容が登録される。

【００８６】翻訳保持部１４３では，データベースエー
ジェント３１０が取り扱える用語に変換をする情報を保
持する。図１５および図１６は，翻訳保持部のデータ形
式の例を示す図である。図１５の翻訳保持部１４３のリ
ストは，どのデータベースエージェントに対しどのオン
トロジーを使用するのかについての情報を記録する。図
１６のリストは，翻訳元と翻訳先のオントロジー間の用
語変換をする翻訳関数の内容情報を記録する。

【００８７】複数のデータベースエージェントへの統合
的なアクセスが可能となるためには，データベースエー
ジェント同士の異なる用語を変換する必要がある。用語
変換は，ファシリテータ１００とデータベースエージェ
ント３１０で行う場合が考えられるが，データベースエ
ージェント３１０で行う場合には，一つの標準となる用
語体系（以降，標準オントロジーという）に対して，各
データベースエージェント３１０の用語体系を結び付け
る処理を各データベースエージェント３１０で行う。こ
の場合，データベースエージェント３１０で送受信する
メッセージは，標準オントロジーが基準となる。

【００８８】ファシリテータ１００で行う場合には，標
準オントロジーを含む複数のオントロジー間を結び付け
る処理をファリシテータ１００で行う。この場合，デー
タベースエージェント３１０で送受信するメッセージ
は，任意のオントロジーが基準となる。

【００８９】既存のデータベースにおいては，独自の用
語体系を確立しているところが少なくない。また，ユー
ザの中には，情報提供側の用語体系を認識しているユー
ザも多く，ユーザの要求を正確に伝えるためには，ユー
ザの用語と情報提供側の用語とが同じ場合に，ユーザの
メッセージをそのままデータベースエージェントに伝達
できることが必要となる。このことから，用語変換は，
原則的に任意のオントロジーを基準としたメッセージが
可能であるファシリテータ１００において行う。

【００９０】図１７は，用語変換を説明する図である。
ここで，百道浜市場データベース３２２は標準オントロ
ジーを，小田中市場データベース３２１は独自の小田中
市場オントロジーを使用しているとする。ファシリテー
タ１００は，用語変換として標準オントロジーと小田中
市場オントロジーとの間を変換する。

【００９１】小田中市場データベースエージェント３１
１と百道浜市場データベースエージェント３１２の各々
が，使用するオントロジーをファシリテータ１００にあ
らかじめアドバタイズしておく。また，ユーザエージェ
ント２１０側で各オントロジーごとのＧＵＩを用意する
ことにより，ユーザは任意の用語体系による検索が行え
る。

【００９２】もし，ユーザが小田中市場オントロジーを
認識しているならば，小田中市場体系検索画面を利用し
て検索を行うことができ，その場合に，ユーザの検索要
求は，ファシリテータ１００を通して，小田中市場デー
タベースエージェント３１１に対してはそのままで送ら
れ，百道浜市場データベースエージェント３１２に対し
ては標準オントロジーに基づいた用語体系に変換されて
送られる。

【００９３】セッション管理部１５０のセッション保持
部１５１には，図１８に示すように，セッションの処理
内容が関数Ｘ，関数Ｙ，…として登録される。セッショ
ン管理部１５０の言明保持部１５２には，図１９に示す
ように，言明メッセージが，メッセージ１，メッセージ
２，…として登録される。

【００９４】ユーザエージェント２１０は，ＨＴＭＬ等
のブラウザ言語（ブラウザ２２０が用いる）とＡＣＬと
を変換する機能を持つ。図２０は，ユーザエージェント
の構成例を示す図である。

【００９５】ユーザエージェント２１０は，表示系をユ
ーザ側，その他の処理系をサーバ側のマシンで動かす。
サーバ側のｈｔｔｐｄ２１１とユーザ側はＨＴＴＰで通
信し，ユーザ側のＨＴＴＰ通信部２１３からの通信があ
ると，サーバ側のｈｔｔｐｄ２１１は，ＣＧＩやＮＳＡ
ＰＩにより処理系へ通信を行う。

【００９６】ユーザ側のＧＵＩ２１２は，検索条件指定
および検索結果の画面をアプレットにより表示する。ま
た，適用分野ごとに異なるＧＵＩのカスタマイズを効率
よく行うために，入出力フォーマットファイルによりア
プレットを自動生成する。ユーザ側のＨＴＴＰ通信部２
１３は，サーバ側のｈｔｔｐｄ２１１との通信を，ＨＴ
ＭＬのフォームで使用するエンコーディング方法を用い
て通信を行う。

【００９７】ユーザ管理部２１４は，ＧＵＩ２１２をア
プレットによりユーザ側で動作させるときのユーザ認
証，メッセージを生成するときに必要なユーザ情報等を
管理する。

【００９８】ＫＩＦ生成部２１５は，ユーザの検索要求
からＫＩＦメッセージを生成し，ＫＩＦメッセージ管理
部２１６へ送る。ＫＩＦメッセージ管理部２１６は，回
答メッセージの解析に用いるＫＩＦメッセージの内容を
保持する。

【００９９】ＫＩＦ解析部２１７は，回答されたＫＩＦ
メッセージの解析を，対応する元のメッセージを参考に
行い，適切な項目に回答値を対応させる。ＫＱＭＬエン
ジン部２１８は，ＫＱＭＬの生成，ＫＱＭＬの解析，適
切な処理関数の呼出し等を行う。

【０１００】エージェント通信部２１９は，通信ライブ
ラリを利用して，他エージェント装置と通信を行う。メ
ッセージをすべて保存し，他のモジュールからは関数呼
出しにより保存したメッセージを読み出すことができ
る。

【０１０１】図２１は，データベースエージェントの構
成例を示す図である。データベースエージェント３１０
は，ＳＱＬ等のデータベースアプリケーション言語とＡ
ＣＬとを変換する機能をもつ。

【０１０２】エージェント通信部３１１は，ユーザエー
ジェント２１０のエージェント通信部２１９と同様の働
きをする。ＫＱＭＬエンジン部３１２は，アドバタイズ
のタイミング制御，ＫＱＭＬメッセージの解析，ＫＱＭ
Ｌメッセージの生成等を行う。

【０１０３】ＫＩＦ／ＳＱＬ変換部３１３は，ＫＩＦメ
ッセージをＳＱＬコマンドに変換し，ＯＤＢＣ等のライ
ブラリを用いてデータベース３２０へアクセスする。ま
た，データベース３２０から返ってきた結果をＫＩＦメ
ッセージに変換する。

【０１０４】データベース３２０は，既存のデータベー
スアプリケーションによりデータを扱う。次に，ファシ
リテータ１００の処理の流れを，やり取りされるメッセ
ージと併せて説明する。

【０１０５】〔１〕宣伝メッセージ 例えば，図２２に示すような宣伝メッセージ（途中省
略）が，情報源を持つ他エージェント装置から送られて
きたとする。

【０１０６】ＫＱＭＬメッセージ処理部１３０がＫＱＭ
Ｌメッセージ送受信部１２０に新しいメッセージの存在
を聞くと図２２の宣伝メッセージが返される。パーフォ
ーマティブ処理部対応部１３１は，ＫＱＭＬのperforma
tive（この場合は "advertise"）をもとに，メッセージ
を宣伝処理部１３２に渡す。

【０１０７】宣伝処理部１３２では，内容をパースし
て，例えばこのエージェント（kodanaka-demo@bighorn.
people.flab.fujitsu.co.jp)は小田中市場という名前
で，農産物カテゴリの情報を持っているということを，
ディレクトリ保持部１４０のカテゴリエージェント保持
部１４１に登録する。

【０１０８】また，このエージェントには“商品名”で
聞けることや，関係データベース的な聞き方（"(allows
-relational-db-query...)" の部分による）ができるこ
とを，ディレクトリ保持部１４０の対応可能メッセージ
形式保持部１４２に登録する。

【０１０９】さらに，このエージェントの話す言葉が，
“kodanaka.database.fujitsu.kif"であり（"(default-
ontology...)" の部分による），"standard.database.f
ujitsu.kif”で“（カテゴリーコード？ｘ"01000")" と
いう文は，“kodanaka.database.fujitsu.kif"では
“（カテゴリーコード？ｘ"11060")" と変換される（"
(store-translation...)"の部分による）ことを，関数
としてディレクトリ保持部１４０の翻訳保持部１４３に
登録する。

【０１１０】〔２〕仲立ちメッセージの処理 仲立ち，推薦，委託メッセージの場合，仲立ちメッセー
ジが一番複雑なので，まず仲立ちメッセージについて説
明する。

【０１１１】例えば，図２３に示すような仲立ちメッセ
ージが他のエージェント装置から送られてきたとする。
ＫＱＭＬメッセージ処理部１３０がＫＱＭＬメッセージ
送受信部１２０に新しいメッセージの存在を聞くと，図
２３の仲立ちメッセージが返される。

【０１１２】パーフォーマティブ処理部対応部１３１
は，ＫＱＭＬのperformative（この場合は“broker-al
l”）をもとに，メッセージを仲立ち処理部１３３に渡
す。仲立ち処理部１３３では，内容をパースして，ディ
レクトリ保持部１４０の対応エージェント保持部１４１
に登録されている全てのエージェントの一つ一つに対し
て，以下の処理を繰り返す。

【０１１３】ディレクトリ保持部１４０の翻訳保持部１
４３の情報より，そのエージェントの理解できる形に変
換する。翻訳保持部１４３では，送る先のエージェント
のオントロジーを引き出す。例えば図２２の宣伝メッセ
ージを送ったkodanaka-demo@bighorn.people.flab.fuji
tsu.co.jp であれば，オントロジーはkodanaka.databas
e.fujitsu.kif になる。次に，もともとのメッセージの
オントロジーstandard.database.fujitsu.kif からこの
オントロジーkodanaka.database.fujitsu.kif に変換す
るための関数を引き出し，順番に適応していく。例えば
図２２の宣伝メッセージを送ったkodanaka-demo@bighor
n.people.flab.fujitsu.co.jp であれば，メッセージ中
の“（カテゴリーコード？ｘ"01000")" を“（カテゴリ
ーコード？ｘ"11060")" に変更する関数があるので，そ
のように変換される。

【０１１４】次に，上記のようにして得られたメッセー
ジについて，ディレクトリ保持部１４０の対応エージェ
ント保持部１４１より，そのエージェントが対応してい
る種類のものかをチェックする。例えば図２２の宣伝メ
ッセージを送ったkodanaka-demo@bighorn.people.flab.
fujitsu.co.jp であれば，このメッセージは，農産物に
関するメッセージなので処理が可能である。

【０１１５】さらに，ディレクトリ保持部１４０の対応
可能メッセージ形式保持部１４２の情報より，そのエー
ジェントが答えられるかをチェックする。具体的にはメ
ッセージをエージェントに対応する対応可能メッセージ
形式保持部１４２に登録された関数に渡して実行するこ
とによりチェックする。例えば，図２２の宣伝メッセー
ジを送ったkodanaka-demo@bighorn.people.flab.fujits
u.co.jp であれば，メッセージが宣伝メッセージ中に指
定された“商品名”などだけからなり，関係データベー
ス的なメッセージであるかを関数によりチェックする。

【０１１６】以上のチェックに通れば，そのエージェン
ト（今の場合kodanaka-demo@bighorn.people.flab.fuji
tsu.co.jp ）に，このメッセージの処理依頼のメッセー
ジを送る。

【０１１７】以上の処理をディレクトリ保持部１４０の
対応エージェント保持部１４１に登録されている全ての
エージェントについて行う。以上の処理過程で少なくと
も一つのエージェントに依頼メッセージを送れたなら
ば，セッション管理部１５０に送り出した回答メッセー
ジの待ち合わせや，（処理を複数のエージェントに依頼
したなら）返ってきた複数のメッセージを統合して返す
処理や，タイムアウト処理などを含んだセッションを関
数としてセッション保持部１５１に登録する。

【０１１８】もし一つのエージェントにも依頼メッセー
ジを送ることができなかった場合には，メッセージの送
信元に仲立ちができない旨の（sorry のperformativeを
持つ）メッセージを送る。

【０１１９】〔３〕推薦メッセージの処理 推薦メッセージの場合，基本的に仲立ちメッセージの処
理と同じであるが，セッションを登録しないで，エージ
ェントのリストを返すところが異なる。

【０１２０】例えば，図２４に示すような推薦メッセー
ジが他のエージェントから送られてきたとする。なお，
recommend-one の場合に処理が違う部分も以下に記述さ
れている。

【０１２１】ＫＱＭＬメッセージ処理部１３０がＫＱＭ
Ｌメッセージ送受信部１２０に新しいメッセージの存在
を聞くと図２４の推薦メッセージが返される。パーフォ
ーマティブ処理部対応部１３１は，ＫＱＭＬのperforma
tive（この場合は“recommend-all"）をもとに，メッセ
ージを推薦処理部１３４に渡す。

【０１２２】推薦処理部１３４では，内容をパースし
て，ディレクトリ保持部１４０の対応エージェント保持
部１４１に登録されている全てのエージェントの一つ一
つに対して，以下の処理を繰り返す。

【０１２３】まず送り返すエージェントのリストを空に
する。ディレクトリ保持部１４０の翻訳保持部１４３の
情報より，そのエージェントの理解できる形に変換す
る。

【０１２４】翻訳保持部１４３では，送る先のエージェ
ントのオントロジーを引き出す。例えば図２２の宣伝メ
ッセージを送ったkodanaka-demo@bighorn.people.flab.
fujitsu.co.jp であれば，オントロジーはkodanaka.dat
abase.fujitsu.kif になる。次にもともとのメッセージ
のオントロジーstandard.database.fujitsu.kif からこ
のオントロジーkodanaka.database.fujitsu.kif に変換
するための関数を引き出し，順番に適応していく。例え
ば図２２の宣伝メッセージを送ったkodanaka-demo@bigh
orn.people.flab.fujitsu.co.jp であれば，メッセージ
中の“（カテゴリーコード？ｘ"01000")" を“（カテゴ
リーコード？ｘ"11060")" に変更する関数があるので，
そのように変換される。

【０１２５】次に上記のようにして得られたメッセージ
について，ディレクトリ保持部１４０の対応エージェン
ト保持部１４１より，そのエージェントが対応している
種類のものかをチェックする。例えば図２２の宣伝メッ
セージを送ったkodanaka-demo@bighorn.people.flab.fu
jitsu.co.jp であれば，このメッセージは，農産物に関
するメッセージなので処理が可能である。

【０１２６】さらに，ディレクトリ保持部１４０の対応
可能メッセージ形式保持部１４２の情報より，そのエー
ジェントが答えられるかをチェックする。具体的にはメ
ッセージをエージェントに対応する対応可能メッセージ
形式保持部１４２に登録された関数に渡して実行するこ
とによりチェックする。例えば図２２の宣伝メッセージ
を送ったkodanaka-demo@bighorn.people.flab.fujitsu.
co.jp であれば，メッセージが宣伝メッセージ中に指定
された“商品名”などだけからなり，関係データベース
的なメッセージであるかを関数によりチェックする。

【０１２７】以上のチェックに通れば，そのエージェン
ト（今の場合kodanaka-demo@bighorn.people.flab.fuji
tsu.co.jp ）を送り返すエージェントのリストに付け加
える。なお，パーフォーマティブがrecommend-one の場
合には，一つでもチェックを通るエージェントがあれ
ば，その時点でそのエージェントを図２５に示すような
返信メッセージを返して処理を抜けてしまう。

【０１２８】以上の処理をディレクトリ保持部１４０の
対応エージェント保持部１４１に登録されている全ての
エージェントについて行う。以上の処理を終わったなら
ば，得られたエージェントのリストをメッセージを送っ
てきたエージェントに返信する。返信メッセージは例え
ば図２６に示すようなものになる。

【０１２９】以上が基本的な動作であるが，推薦の場
合，対応可能メッセージ形式保持部１４２のチェックを
行わずに，対応エージェント保持部１４０の情報だけに
基づいて送る場合もある。その場合には，上記の処理で
対応可能メッセージ形式保持部１４２の部分を実行しな
いだけである。

【０１３０】〔４〕委託メッセージの処理 委託メッセージの場合，基本的に仲立ちメッセージの処
理と同じであるが，セッションを登録しないところが仲
立ちメッセージの処理と異なる。例えば，図２７に示す
ような委託メッセージが他のエージェントから送られて
きたとする（パーフォーマティブがrecruit-one の場合
について，処理が違う部分も以下に記述されている）。

【０１３１】ＫＱＭＬメッセージ処理部１３０がＫＱＭ
Ｌメッセージ送受信部１２０に新しいメッセージの存在
を聞くと図２７の委託メッセージが返される。パーフォ
ーマティブ処理部対応部１３１は，ＫＱＭＬのperforma
tive（この場合は“recruit-all"）をもとに，メッセー
ジを委託処理部１３５に渡す。

【０１３２】委託処理部１３５では，内容をパースし
て，ディレクトリ保持部１４０の対応エージェント保持
部１４１に登録されている全てのエージェントの一つ一
つに対して，以下の処理を繰り返す。

【０１３３】ディレクトリ保持部１４０の翻訳保持部１
４３の情報より，そのエージェントの理解できる形に変
換する。翻訳保持部１４３では，送る先のエージェント
のオントロジーを引き出す。例えば図２２の宣伝メッセ
ージを送ったkodanaka-demo@bighorn.people.flab.fuji
tsu.co.jp であれば，オントロジーはkodanaka.databas
e.fujitsu.kif になる。次にもともとのメッセージのオ
ントロジーstandard.database.fujitsu.kif からこのオ
ントロジーkodanaka.database.fujitsu.kif に変換する
ための関数を引き出し，順番に適応していく。例えば図
２２の宣伝メッセージを送ったkodanaka-demo@bighorn.
people.flab.fujitsu.co.jp であれば，メッセージ中の
“（カテゴリーコード？ｘ"01000")" を“（カテゴリー
コード？ｘ"11060")" に変更する関数があるので，その
ように変換される。

【０１３４】次に上記のようにして得られたメッセージ
について，ディレクトリ保持部１４０の対応エージェン
ト保持部１４１より，そのエージェントが対応している
種類のものかをチェックする。例えば図２２の宣伝メッ
セージを送ったkodanaka-demo@bighorn.people.flab.fu
jitsu.co.jp であれば，このメッセージは，農産物に関
するメッセージなので処理が可能である。

【０１３５】さらに，ディレクトリ保持部１４０の対応
可能メッセージ形式保持部１４２の情報より，そのエー
ジェントが答えられるかをチェックする。具体的にはメ
ッセージをエージェントに対応する対応可能メッセージ
形式保持部１４２に登録された関数に渡して実行するこ
とによりチェックする。例えば図２２の宣伝メッセージ
を送ったkodanaka-demo@bighorn.people.flab.fujitsu.
co.jp であれば，メッセージが宣伝メッセージ中に指定
された“商品名”などだけからなり，関係データベース
的なメッセージであるかを関数によりチェックする。

【０１３６】以上のチェックに通れば，そのエージェン
ト（今の場合kodanaka-demo@bighorn.people.flab.fuji
tsu.co.jp ）に対し，委託メッセージを送り，そのエー
ジェントにさらにメッセージの処理を委託する。なお，
recruit-one の場合には，一つでもチェックを通るエー
ジェントがあれば，その時点でそのエージェントに対
し，図２７の委託メッセージでrecruit-all を，図２８
に示すようにrecruit-one に変えたメッセージを送って
処理を抜けてしまう。

【０１３７】以上の処理をディレクトリ保持部１４０の
対応エージェント保持部１４１に登録されている全ての
エージェントについて行う。 〔５〕予約メッセージの処理 予約メッセージの処理を以下に記述する。例えば，図２
９に示すような予約メッセージが他エージェント装置か
ら送られてきたとする。

【０１３８】ＫＱＭＬメッセージ処理部１３０がＫＱＭ
Ｌメッセージ送受信部１２０に新しいメッセージの存在
を聞くと以上のメッセージが返される。パーフォーマテ
ィブ処理部対応部１３１は，ＫＱＭＬのperformative
（この場合は“subscribe"）をもとに，メッセージを予
約処理部１３６に渡す。

【０１３９】予約処理部１３６では，内容をパースし
て，セッション管理部１５０のセッション保持部１５１
に適当な時間を設定し以下のような関数を登録する。現
在の時刻と設定された時刻を比較して現在の時刻が後で
あれば，以下を実行する関数である。

【０１４０】１．メッセージ部分（:contentの内容）に
適当な他のパラメタを付加して，パーフォーマティブ処
理部対応部１３１に渡す。 ２．自分自身のセッションをセッション保持部１５１か
ら消す。

【０１４１】３．時間を適切な時間だけ後にした（:sch
edule once-a-dayの場合は24時間）だけで他の内容は変
わらないセッションを登録する。 〔６〕言明メッセージの処理 例えば，図２３の仲立ちメッセージによって発せられた
依頼のメッセージに対する回答メッセージとして，図３
０に示すような言明メッセージが送られてきたとする
（言明メッセージのperformativeの種類としては，tel
l, reply, sorry,error などがある。）。

【０１４２】ＫＱＭＬメッセージ処理部１３０がＫＱＭ
Ｌメッセージ送受信部１２０に新しいメッセージの存在
を聞くと以上のメッセージが返される。パーフォーマテ
ィブ処理部対応部１３１は，ＫＱＭＬのperformative
（この場合は“reply") をもとに，メッセージを言明処
理部１３５に渡す。

【０１４３】言明処理部１３５では，このメッセージを
セッション管理部１５０の言明保持部１５２に登録す
る。 〔７〕セッション管理部 セッション管理部１５０では，実質的に図１０の処理フ
ローチャートにあったように登録されたセッションを実
行するだけである。実際の動作は登録されたセッション
に依存する。

【０１４４】セッションは，例えば，指定した時間が経
ってしまっていたら処理できなかった旨を「仲立ちメッ
セージ」の送信元にメッセージとして送り，そうでなけ
れば送り出した依頼メッセージに対応する回答メッセー
ジが全て返ってきたかを言明保持部１５２をチェックす
ることにより調べ，もし全てが返ってきていたらそれら
の情報を統合して「仲立ちメッセージ」の送信元に回答
メッセージとして送り返すといったものである。

【０１４５】図３１に「仲立ちメッセージ」の場合に登
録されるセッションの例を示す。図３１のセッション
は，一つの実行関数（モジュール）であり，この例で
は，Allegro Common LISP によって記述されている。こ
のセッションでは，（check-reply-message-for-ask-al
l ）で，データベースエージェントからの返事が返って
きたかあるいはタイムアウトを確認する。（'308103010
4 ）は，タイムアウトする時間を示し，（progn...）
は，前の条件が成立したら実際に実行される部分を示
す。

【０１４６】

【発明の効果】以上説明したように，本発明によれば仲
介エージェント装置（ファシリテータ）により，ユーザ
エージェントはサービスを提供するエージェントの所
在，特定のエージェントに対する聞き方（メッセージの
作り方）などを管理することなく，依頼のメッセージを
送ることができる。すなわち，情報源や依頼元を含む複
数のエージェント装置を，よりうまく連携させることが
可能になり，ひいてはエージェントシステムを使うユー
ザに，より適切な情報を提供することができるようにな
る。

【０１４７】例えば，電子商取引（ＥＣ）へ参画する企
業は，商品情報等を電子的に管理する企業も多い。これ
らの企業が持つ既存のデータベース等，異なる種類の情
報源を統合し，これらのデータへ統合的にアクセスする
ためのシステムの構築を実現することができる。

【図面の簡単な説明】

【図１】本発明の原理説明図である。

【図２】メッセージ送受信部の処理フローチャートであ
る。

【図３】メッセージ処理部およびメッセージ分配部の処
理フローチャートである。

【図４】宣伝処理部の処理フローチャートである。

【図５】仲立ち処理部の処理フローチャートである。

【図６】推薦処理部の処理フローチャートである。

【図７】委託処理部の処理フローチャートである。

【図８】予約処理部の処理フローチャートである。

【図９】言明処理部の処理フローチャートである。

【図１０】セッション管理部の処理フローチャートであ
る。

【図１１】実施例のシステム構成例を示す図である。

【図１２】実施例における仲介エージェント装置（ファ
シリテータ）の構成例を示す図である。

【図１３】カテゴリエージェント保持部のデータ形式の
例を示す図である。

【図１４】対応可能メッセージ形式保持部のデータ形式
の例を示す図である。

【図１５】翻訳保持部のデータ形式の例（１）を示す図
である。

【図１６】翻訳保持部のデータ形式の例（２）を示す図
である。

【図１７】用語変換の説明図である。

【図１８】セッション保持部のデータ形式の例を示す図
である。

【図１９】言明保持部のデータ形式の例を示す図であ
る。

【図２０】ユーザエージェントの構成例を示す図であ
る。

【図２１】データベースエージェントの構成例を示す図
である。

【図２２】宣伝メッセージの例を示す図である。

【図２３】仲立ちメッセージの例を示す図である。

【図２４】推薦メッセージの例を示す図である。

【図２５】返信メッセージの例を示す図である。

【図２６】返信メッセージの例を示す図である。

【図２７】委託メッセージの例を示す図である。

【図２８】委託メッセージの例を示す図である。

【図２９】予約メッセージの例を示す図である。

【図３０】言明メッセージの例を示す図である。

【図３１】仲立ちメッセージの場合に登録されるセッシ
ョンの例を示す図である。

【符号の説明】

１ 中間エージェント装置（ファシリテータ） ２ メッセージ送受信部 ３ メッセージ処理部 ３１ メッセージ分配部 ３２ 宣伝処理部 ３３ 仲立ち処理部 ３４ 推薦処理部 ３５ 委託処理部 ３６ 予約処理部 ３７ 言明処理部 ４ ディレクトリ保持部 ４１ 対応エージェント保持部 ４２ 対応可能メッセージ形式保持部 ４３ 翻訳保持部 ５ セッション管理部 ５１ セッション保持部 ５２ 言明保持部 ６ 他エージェント装置 ７ ネットワーク

フロントページの続き (56)参考文献 国際公開97／3404（ＷＯ，Ａ１) Ｆｉｎｉｎ，Ｔ．，ｅｔ ａｌ，ＫＱ ＭＬ ａｓ ａｎ Ａｇｅｎｔ Ｃｏｍ ｍｕｎｉｃａｔｉｏｎ Ｌａｎｇｕａｇ ｅ，Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ ｔ ｈｅ Ｔｈｉｒｄ Ｉｎｔｅｒｎａｔｉ ｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｉｎｆｏｒｍａｔｉｏｎ ａｎｄ Ｋ ｎｏｗｌｅｄｇｅ Ｍａｎａｇｅｍｅｎ ｔ，米国，ＡＣＭ Ｐｒｅｓｓ，1994 年，ｐ．456−463 岸本，広域ネットワークにおけるエー ジェント通信ブローカ，電子情報通信学 会技術研究報告，日本，（社）電子情報 通信学会，1993年10月７日，Ｖｏｌ. 93，Ｎｏ．262（ＣＳ93−119），ｐ．47 −54 岩田・外４名著，メディエータを用い た物理エージェントとソフトウェアエー ジェントの協調環境の構築，電子情報通 信学会技術研究報告，日本，（社）電子 情報通信学会，1996年１月18日，Ｖｏ ｌ．95，Ｎｏ．460（ＡＩ95−42），ｐ. １−８ (58)調査した分野(Int.Cl.⁷，ＤＢ名) G06N 5/04 G06F 13/00 G06F 15/16

Claims (5)

(57)【特許請求の範囲】
1. 【請求項１】 複数のエージェント装置間のメッセージ
   の仲介をする仲介エージェント装置であって， 他のエージェント装置からのメッセージを送信または受
   信するメッセージ送受信手段と， メッセージによる依頼を処理できる他のエージェント装
   置の能力に関する宣伝情報を蓄積するディレクトリ保持
   手段と， 他のエージェント装置に依頼したメッセージに対する回
   答メッセージを待ち合わせて処理するために登録された
   セッションであって，ある条件が成立したときに実行す
   べき処理の内容が記述されたセッションを管理し，前記
   登録されたセッションをそれが削除されるまで所定の契
   機で繰り返し実行する制御を行うセッション管理手段
   と， 前記メッセージ送受信手段で他のエージェント装置から
   処理を依頼するメッセージを受信した場合に，前記ディ
   レクトリ保持手段が保持する他のエージェント装置の能
   力に関する宣伝情報および前記受信したメッセージを他
   のエージェント装置が理解できるメッセージに変換する
   ための情報を参照して，他のエージェント装置の理解で
   きる形に前記メッセージを変換するとともに，変換され
   たメッセージが当該エージェント装置が対応しているカ
   テゴリのものか，また，当該エージェント装置が回答で
   きるものかを判断して適切な他のエージェント装置を選
   択し，選択したエージェント装置への仲立ち，選択した
   エージェント装置の推薦，または選択したエージェント
   装置へのメッセージの委託を行い，回答メッセージの処
   理が必要な場合には前記セッション管理手段にセッショ
   ンを登録するメッセージ処理手段とを備えたことを特徴
   とする仲介エージェント装置。
2. 【請求項２】 請求項１に記載する仲介エージェント装
   置において， 前記ディレクトリ保持手段は，仲介するメッセージの用
   語を，仲介先の他のエージェント装置が使用する用語に
   変換するための情報を保持する翻訳保持手段を有し， 前記メッセージ処理手段は，前記翻訳保持手段が保持す
   る情報を用いて仲介するメッセージを変換することを特
   徴とする仲介エージェント装置。
3. 【請求項３】 請求項１に記載する仲介エージェント装
   置において， 前記ディレクトリ保持手段は，特定の依頼メッセージに
   対して，どのエージェント装置で対応できるかの情報を
   保持する対応エージェント保持手段と，あるエージェン
   ト装置がどのような形式のメッセージに対応可能である
   かを保持する対応可能メッセージ形式保持手段とを有
   し， 前記メッセージ処理手段は，前記対応エージェント保持
   手段が保持する情報，または前記対応エージェント保持
   手段と前記対応可能メッセージ形式保持手段が保持する
   情報を用いて，仲介先となる１または複数のエージェン
   ト装置を選択することを特徴とする仲介エージェント装
   置。
4. 【請求項４】 請求項１に記載する仲介エージェント装
   置において， 前記メッセージ処理手段は，他のエージェント装置から
   の能力に関する情報を通知する宣伝メッセージを受信し
   たときに，前記ディレクトリ保持部にその能力に関する
   情報を登録する宣伝処理手段を持つことを特徴とする仲
   介エージェント装置。
5. 【請求項５】 複数のエージェント装置間のメッセージ
   の仲介をする仲介エージェント装置をコンピュータによ
   って実現するためのプログラムを記憶した媒体であっ
   て， 他のエージェント装置からのメッセージを送信または受
   信するメッセージ送受信の処理と， 他のエージェント装置に依頼したメッセージに対する回
   答メッセージを待ち合わせて処理するために登録された
   セッションであって，ある条件が成立したときに実行す
   べき処理の内容が記述されたセッションを管理し，前記
   登録されたセッションをそれが削除されるまで所定の契
   機で繰り返し実行する制御を行うセッション管理の処理
   と， 他のエージェント装置から処理を依頼するメッセージを
   受信した場合に，あらかじめ蓄積した他のエージェント
   装置の能力に関する宣伝情報および前記受信したメッセ
   ージを他のエージェント装置が理解できるメッセージに
   変換するための情報を参照して，他のエージェント装置
   の理解できる形に前記メッセージを変換するとともに変
   換されたメッセージが当該エージェント装置が対応して
   いるカテゴリのものか，また，当該エージェント装置が
   回答できるものかを判断して適切な他のエージェント装
   置を選択し，選択したエージェント装置への仲立ち，選
   択したエージェント装置の推薦，または選択したエージ
   ェント装置へのメッセージの委託を行い，回答メッセー
   ジの処理が必要な場合にそれを処理するためのセッショ
   ンを登録するメッセージ処理とを， コンピュータに実行させるプログラムを格納したことを
   特徴とする仲介エージェント装置を実現するプログラム
   記憶媒体。