JPH09231184A - 自律協調情報処理装置並びに自律協調分散処理方法 - Google Patents

Abstract

(57)【要約】 【課題】断続的に多数発生する処理要求を適切に分散配
置することにより、高速な処理を実現する。 【解決手段】外部から送られてくる処理要求を受け付け
るか否かを判断するとともに、受け付けた処理要求を自
己に属する情報処理部1400に適切に割り当てるエージェ
ント1000と、このエージェント1000の要求により処理要
求を処理する情報処理部1400とを備える。そして、各情
報処理部1400の処理状況を監視し、稼働率の低い情報処
理部1400が発生した場合には、各情報処理部1400に割り
付けられた処理要求を稼働率の低い情報処理部1400に移
すことにより、全体として高いパフォーマンスを得る。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、複数の情報処理
要求を受け付け、これらの処理要求を複数のプロセスに
より並行分散処理する自律協調情報処理装置並びに自律
協調処理方法に関する。

【０００２】

【従来の技術】

従来の技術１．従来の技術として、一般問題解決あるい
は、サービスの提供を含む情報処理の並行分散処理を対
象とした上述エージェントによる自律協調処理に係る技
術を説明する。

【０００３】図２３〜図２５は、特開７−６１４２号公
報に示されたマルチエージェント協調システムの構成を
示すブロック図である。図２３は、プランニングエージ
ェント8001の内部構造を示すブロック構成図である。80
01は、他のエージェントあるいはユーザ8007と情報を授
受するための通信部8006と、プランを生成するための規
則が格納されているルールベース8002と、ルールベース
8002を参照してプランを作成するプランニング実行部80
04と、図示しないフィールドマネージャ8201からのメッ
セージに含まれた依頼を評価するための基準を格納した
評価用データ格納部8003と、評価用データ格納部8003に
従って評価を行なう評価部8005と、を備えたプランニン
グエージェントである。

【０００４】図２４は、要素機能エージェント8101の内
部構造を示すブロック構成図である。要素機能エージェ
ント8101は、他のエージェントあるいはユーザ8107と情
報を授受するための通信部8106と、サービスあるいは、
その一部である要素機能の定義を格納する機能定義格納
部8102と、機能定義格納部8102の内容に従ってサービス
あるいはその一部を実行するサービス実行部8104と、評
価基準とプロファイルを格納した評価用データおよびプ
ロファイル格納部8103と、評価用データおよびプロファ
イル格納部8103に従って評価を行なう評価部8105と、を
有している。

【０００５】図２５は、フィールドマネージャ8201の内
部構造を示すブロック構成図である。フィールドマネー
ジャ8201は、エージェントあるいは、ユーザ8205と情報
を授受するための通信部8203と、協調動作を行なうエー
ジェントのメンバや協調動作の手順の定義を格納した協
調定義データベース8204と、協調定義データべース8204
の定義を参照して他のエージェントに協調動作を行なわ
せるためのメッセージを通信部8203を介して送信する協
調動作実行部8202と、を有している。

【０００６】この従来技術の大きな特徴は、 1)ユーザから要求されたサービスを達成するための機能
の組合せと機能間で授受されるデータとそれらを実行す
る順序であるプランを求める問題であるプランニング
と、 2)プランを達成する要素機能あるいは、要素機能と結び
つけられた資源の稼働状態もしくは負荷状況の均衡を保
つように要素機能に対してサービスを達成するためのタ
スクを配分する問題である資源割当と、を切り離して、
1)、2)毎に分割された二段階からなる処理により問題解
決することである。

【０００７】次に、従来システムの動作を図２３〜２５
に基づいて説明する。このマルチエージェント協調シス
テムは、フィールドマネージャ8201が複数のプランニン
グエージェント8001（図２３）を統括し、プランニング
エージェント8001が複数の要素機能エージェント8101を
統括するという階層構造を持つ。ユーザ等からの要求を
フィールドマネージャ8201が受けると、フィールドマネ
ージャ8201は1)のプランニングを行う。そして、ここで
作成されたプランに基づきプランニングエージェント80
01がプランを実行する。プランニングエージェント8001
は、上記プランを実行するために2)の資源割り当てを行
い、どの要素機能エージェント8101を使用するかを決定
する。そして、要素機能エージェント8101はプランニン
グエージェント8002に割り当てられた要求を実行する。
従って、要求の流れは、フィールドマネージャ8201→プ
ランニングエージェント8001→要素機能エージェント81
01というトップダウンの形式をとる。

【０００８】上記処理を詳細に説明すると、以下のよう
になる。まず、図２５のフィールドマネージャ8201は、
ユーザがユーザインターフェースから入力したサービス
要求を通信部8203を介して受け取る。次いで、フィール
ドマネージャ8201は、協調定義データベース8204の記述
に従って協調動作実行部8202が指示を生成する。そし
て、この指示と上記ユーザからのサービス要求に付加し
た情報を通信部8203を介してメンバである複数の適当な
プランニングエージェント8001に対して送る。次に、図
２３のプランニングエージェント8001は、通信部8006を
介して受けとった上記情報の指示に従い、評価部8005が
評価用データ格納部8003の内容に基づいて上記ユーザか
ら要求されたサービスの仕様を評価する。そして、プラ
ンニング実行部8004がルールベース8002の内容に基づき
要求されたサービスを実行するためのプランを生成す
る。ついで、プランニングエージェント8001は、上記評
価の結果が規定の基準に達したかどうか、プランが得ら
れたかどうかを判定する。その結果、評価基準を満たさ
ないか、あるいはプランが得られなければそのプランニ
ングエージェント8001は動作を終了する。そうでない場
合は、プランニングエージェント8001は、生成したプラ
ンに従って必要な要素機能エージェント8101に通信部80
06を介して負荷やその要素機能エージェント8101に付随
する装置の位置などに関する評価を依頼する。また、こ
の時依頼とともに評価のために必要な情報を送る。

【０００９】次いで、図２４の要素機能エージェント81
01は、上記依頼を通信部8106を介して受けとり、評価用
データおよびプロファイル格納部8103の内容に従って、
受けとった情報を評価しその結果を通信部8106を介して
プランニングエージェント8001に返す。ついで、フィー
ルドマネージャ8201は、上記総合評価の結果に基づいて
実際にサービスを達成するための仕事を依頼するプラン
ニングエージェント8001を決定し、処理依頼を行なう。
次いで、依頼を受けたプランニングエージェント8001
は、上記プランにしたがい適当な要素機能エージェント
8101と共に上記仕事を処理する。

【００１０】従来の技術２．次いで、情報検索の並行分
散処理に係る従来技術を挙げる。図２６は、特開平４−
３２６１６２号公報に示された従来のデータベース検索
処理方式の機能ブロック図を示している。この方式かか
るデータベース装置は、LANで結合された端末9001とホ
ストコンピュータ9002からなり、端末9001は、検索処理
を要求するデータベース検索要求プログラム9003、ホス
トコンピュータ9002から受け取った検索結果を格納する
検索結果データ格納部9007、この検索結果を処理する検
索結果データ処理プログラム9008からなり、ホストコン
ピュータ9002は、検索処理を行うデータベース検索処理
プログラム9004、データが格納されたデータベース900
5、検索結果を格納する検索結果データ格納部9006から
なる。

【００１１】図２６に示すデータベースシステムは、端
末9001から、LANで接続されたホストコンピュータ9002
のデータベース9005を検索するに当たり、ホストコンピ
ュータ9002側のデータベース検索処理プログラム9004
と、端末側の検索結果データ処理の並行処理を行なうこ
とにより、端末9001側におけるデータベース9005の検索
要求から検索結果を得るまでの時間の最小化を図ること
を目的としたものである。

【００１２】次に動作を説明する。端末9001の操作によ
り、データベース検索要求プログラム9004が起動され、
検索条件等をホストコンピュータ9002のデータベース検
索処理プログラム9004に受け渡す。データベース検索処
理プログラム9004は、これらを受けとり、端末9001側の
検索結果データ格納部9007に空きがあれば、検索条件に
従って、データベース9005の検索を開始し、１件の検索
結果が得られた時点で、ホスト9002側の検索結果データ
格納部9006を介して端末9001側に転送する。すなわち、
ホストコンピュータ9002側での検索と端末9001側への転
送が１件ずつ行なわれる。端末9001側の検索結果データ
処理プログラム9008は、ホスト9002側から転送されてき
た、検索結果データを受け取って、その表示や編集等の
処理を実施し、処理が完了したら検索結果データを削除
し、ホストコンピュータ9002での次の検索処理を可能と
する。

【００１３】従来の技術３．図２７は、例えば特開平６
−２７４５３２号公報に示された従来の負荷分散支援装
置のブロック図を示している。図２７に示す装置は、構
造化された検索キーワードによって構造化されたインデ
ックスを持つ検索対象を並列計算機上で並列に検索を行
なう際に、対象領域に固有の関数を用いることにより検
索処理の負荷分散のシミュレーションを行ない、適切な
負荷の分散支援を行なうものであり、検索処理の負荷分
散を動的に行なうことにより、並列計算機のプロセッサ
の稼働率を向上することを目的としたものである。

【００１４】図２７に示す装置は、検索キーワード等の
文字情報を入力するための入力手段10001、入力した文
字情報やプロセッサの割り付け情報を出力するためのプ
リンタ等の出力手段10002、入力された情報を記憶する
ための記憶手段10003、入力されたり、途中の処理結果
を文字情報やイメージ情報として表示するための表示手
段10004、入力された各種関数のパラメータをユーザと
の対話により調整するパラメータ調整手段10005、入力
された各検索キーワードと関数から各検索キーワードの
負荷を予測する負荷予測手段10006、予測された検索キ
ーワードの検索時間と使用プロセッサ数から各検索キー
ワードへ割り付けるプロセッサ数を見積もるプロセッサ
割り付け手段10007、プロセッサの割り付け情報を基
に、予め並列計算機上で計測された検索キーワードの実
計測時間を用いて、予測された検索キーワードの検索時
間と実計測時間の検索時間との比較を計算し、大きい順
に並べ変えるプロセッサ割り付け検証手段10008、検索
キーワードのプロセッサへの割り付け情報を調整するプ
ロセッサ割り付け調整手段10009、上述各手段を制御す
る制御手段10010からなる。

【００１５】次にその動作を説明する。はじめに、制御
手段10010の制御により、インデックスと検索キーワー
ドと関数、並列計算機上での検索キーワードの実計測時
間および並列計算機で使用するプロセッサ数が、入力手
段10001により入力され、記憶手段10003に記憶される。
次に、パラメータ調整手段10005の指示により、変更可
能なパラメータが表示手段10004へ表示される。ユーザ
は、入力手段10001を利用してこのパラメータを修正す
る。調整された情報は、記憶手段10003に記憶される。

【００１６】次いで、負荷予測手段10006では、入力さ
れた各検索キーワードごと予め規定された関数に基づい
て、検索にかかる時間が見積もられる。見積もられた検
索時間は、記憶手段10003に記憶される。プロセッサ割
り付け手段10007では、見積もられた検索時間の比から
各検索キーワードに割り付けるプロセッサの数を算出す
る。算出されたプロセッサの割り付け情報は記憶手段10
003に記憶される。プロセッサ割り付け検証手段10008
は、算出されたプロセッサの割り付け情報を基に予め並
列計算機上で計測された検索キーワードの計測データを
用いて、予測された検索キーワードの検索時間と実計測
時間との比較を行ない差の大きい検索キーワード順に、
検索キーワード名と予測検索時間、と実計測時間との差
の情報の表示を表示手段10004において行なう。

【００１７】次に、プロセッサ割り付け調整手段10009
により、検索キーワードへのプロセッサの割り付け情報
を表示手段10004に表示し、ユーザとの対話によりパラ
メータが変更され、次回の検索時の割付プロセッサ数が
変化する。変更結果は、記憶手段10003に記憶される。
変更結果は、プロセッサ割り付け検証手段10008により
さらに検証することができる。最後にプロセッサ割り付
け情報を出力手段10002に出力する。

【００１８】

【発明が解決しようとする課題】図２３〜２５において
示したエージェントにおいては、一度プランニングが終
了し、要求が割り付けられてしまうと割り付けが解除さ
れることがないため、複数の要求が割り付けられている
場合には、待ち状態にある要求は処理されず、処理時間
がかかるという問題があった。すなわち、要求の処理が
先に終了して待ち状態にあるエージェントがあるにもか
かわらず、最初に割り付けられたエージェントで処理さ
れるのを待っている要求が存在し、当該要求の処理が終
了するまでの時間が多くかかるという問題があった。

【００１９】また、図２６に示したデータベース検索処
理方式では、検索対象がホストマシンのデータベースに
限定されていること、検索要求に対する検索結果がすべ
て終了しなければ新たな検索要求を出すことができない
という問題があり、次々と発生する要求を高速に処理す
ることができないという問題があった。

【００２０】また、図２７に示した負荷分散支援装置で
は、負荷分散のシミュレーション時に対象領域に固有の
関数を必要とするため、汎用性に乏しく、インターネッ
ト上に分散配置されているWWWのような複雑で、日々情
報が更新されるような情報源に対して負荷分散を効率よ
く実現するのは、困難である。また、一度割り付けが完
了すると、最後までそのプロセッサが検索を実施するた
め、シュミレーションの誤差が大きい場合には、その検
索処理は低速な処理となってしまうという問題があっ
た。

【００２１】この発明は、上記のような問題点を解消す
るためになされたものであり、ネットワーク等により分
散配置された情報資源を有効に活用し、各プロセスの稼
働率を向上させることにより、処理速度の高速な自律協
調情報処理装置を得ることを目的とする。

【００２２】

【課題を解決するための手段】この発明にかかる自律協
調情報処理装置においては、外部からの処理要求を受け
付けるか否かを判断し、受け付けた上記処理要求の処理
先を指定して出力するエージェント部と、このエージェ
ント部から指示された処理要求を処理する複数の情報処
理部とを備えた自律協調情報処理装置において、上記情
報処理部は、複数の上記処理要求を受け付け、これらの
処理要求の処理状況に応じて処理要求の再割り当てを上
記エージェント部に要求するとともに、再割り当てされ
た処理要求を実行し、上記エージェント部は、上記情報
処理部からの上記再割り当て要求を受け付けたとき、そ
の再割り当て要求を送信した情報処理部の管理する処理
要求を他の上記情報処理部へ移動させ、又は、他の情報
処理部の管理する処理要求をその再割り当て要求を送信
した情報処理部へ移動させることを特徴とするものであ
る。

【００２３】また、上記情報処理部は、複数の上記処理
要求を受け付け、これらの処理要求のうち未処理の処理
要求が無くなり又は予め定められた件数よりも少なくな
った場合には、再割り当て要求を送信するとともに、上
記エージェント部により再割り当てされた処理要求を実
行し、上記エージェント部は、上記情報処理部からの上
記再割り当て要求を受け付けると、他の情報処理部の管
理する処理要求をその再割り当て要求を送信した情報処
理部へ移動させるものである。

【００２４】また、複数の上記エージェント部を備え、
上記複数の情報処理部はそれぞれ複数の上記エージェン
ト部からの処理要求を受け付けるとともに、上記エージ
ェント部は、自己の管理する処理要求の件数又は優先度
から新たな処理要求を受け付けられるか否かを判定し、
この判定結果を通信する協調処理部と、上記協調処理部
が処理要求を受け取ったときに、自己の管理する上記情
報処理部の処理状況又は属性を考慮して、複数の上記情
報処理部から当該処理要求を処理する上記情報処理部を
選択し、この選択した情報処理部へ当該処理要求を割り
当てる情報処理管理部と、を備え、この情報処理管理部
を他のエージェント部と共有することにより、上記情報
処理部は複数のエージェント部への通信を上記情報処理
管理部を介して行うものである。上記情報処理管理部に
は、実施の形態に示すメタ制御管理部が含まれる。

【００２５】また、上記エージェント部ごとに操作でき
る記憶領域を指示するアクセス権制御部と複数の上記エ
ージェント部からの情報を格納し、上記アクセス権制御
部の指示に基づいて、上記エージェント部から操作でき
る記憶領域を制限する内部情報格納部と、を備えるもの
である。

【００２６】また、複数の上記エージェント部を備え、
外部から処理要求を受け付け、複数の上記エージェント
部へ当該処理要求の引き取りが可能であるか否かを問い
合わせ、これらのエージェント部からの返答に基づき当
該処理要求を引き取るエージェント部を決定するプラン
策定部を備えるものである。

【００２７】また、上記プラン策定部は、上記処理要求
をどのエージェント部へ割り付けるかを決定する規則で
ある戦略を複数記憶する戦略格納部と、外部から指示さ
れた上記戦略と上記返答に基づき受け付けた処理要求を
引き渡す上記エージェント部を選択するプラン生成部
と、受け付けた上記処理要求又は上記プラン生成部の処
理状況に基づいて、上記複数の戦略から１つの戦略を選
択し上記プラン生成部へ指示する戦略指示部と、上記プ
ラン生成部により選択されたエージェント部に上記受け
付けた処理要求を通知する通信管理部と、を備えたもの
である。戦略指示部が戦略を指示する方法としては、プ
ラン生成法を直接指示する方法の他、プラン生成部で用
いられるプラン生成のための制御パラメータを指示する
方法が含まれる。

【００２８】また、複数の上記エージェント部と、これ
らのエージェント部のそれぞれに管理された複数の情報
処理部とを備えた自律協調情報処理装置において、上記
情報処理部が管理する上記処理要求の処理状態に基づ
き、１つの上記エージェント部に管理された情報処理部
が保有する処理要求を、他の上記エージェント部が管理
する他の上記情報処理部へ移動するプラン調整部を備え
たものである。

【００２９】また、上記プラン調整部は、上記情報処理
部が保有する処理要求の未処理件数を監視し、未処理件
数の多い上記情報処理部から未処理件数の少ない情報処
理部へ上記処理要求を移すものである。なお、上記保有
件数の少ない上記エージェント部には、保有件数が０の
エージェント部が含まれることはいうまでもない。

【００３０】また、上記プラン調整部は、上記情報処理
部が保有する処理要求それぞれの優先度を監視し、上記
処理要求を上記優先度の高い処理要求を多く保有する情
報処理部から、上記優先度の高い処理要求の保有件数が
少ない情報処理部へ移すもののである。

【００３１】また、上記処理要求の処理に要する時間に
基づき、上記エージェント部又は上記情報処理部の数を
増減させるチューニング部を備えたものである。

【００３２】また、外部からの処理要求を受け付けるか
否かを判断し、受け付けた上記処理要求の処理先を指定
して出力するエージェント部と、このエージェント部か
ら指示された処理要求を処理する複数の情報処理部とを
備えた自律協調情報処理装置において、上記情報処理部
は、過去に処理した処理要求の処理結果を記憶し、この
記憶した処理結果にかかる処理要求を優先処理要求とし
て上記エージェント部に通知し、上記エージェント部
は、新たに処理要求を受け付けた場合には、複数の上記
情報処理部から一部の情報処理部を選択し、選択した情
報処理部に当該処理要求を割り当てるとともに、上記優
先処理要求を記憶し、新たに受け付けた処理要求が上記
優先処理要求と同一であった場合又は上記処理結果を利
用することができる場合には、当該処理要求を上記優先
処理要求を送信してきた上記情報処理装置に割り当てる
ものである。

【００３３】また、複数の上記エージェント部を備えた
自律協調処理装置において、上記エージェント部は、複
数の上記処理要求を保有し、複数の上記情報処理部に複
数の上記処理要求をそれぞれ配分し、上記エージェント
部の上記処理要求件数を監視し、上記処理要求の保有件
数の多い上記エージェント部から上記処理要求の保有件
数の少ない上記エージェント部へ、上記処理要求を移す
処理要求再割当部を備えたものである。なお、上記保有
件数の少ない上記エージェント部には、保有件数が０の
エージェント部が含まれることはいうまでもない。

【００３４】また、外部からの処理要求を受け付けるか
否かを判断し、受け付けた上記処理要求の処理先を指定
して出力するエージェント部と、このエージェント部か
ら指示された処理要求を処理する情報処理部とを備えた
自律協調情報処理装置において、上記エージェント部を
複数備え、上記情報処理部は、複数の上記処理要求を受
け付け、これらの処理要求の処理状況に応じて処理要求
の再割り当てを、自己を管理する上記エージェント部に
要求するとともに、再割り当てされた処理要求を実行
し、上記エージェント部は、上記情報処理部からの上記
再割り当て要求を受け付けたとき、その再割り当て要求
を送信した情報処理部が保有する処理要求を他のエージ
ェント部が管理する情報処理部へ移動させ、又は、他エ
ージェント部が管理する情報処理部が保有する処理要求
をその再割り当て要求を送信した情報処理部へ移動させ
るものである。

【００３５】この発明にかかる自律協調分散処理方法に
おいては、複数の処理要求を複数のプロセスに割り付け
て実行させる自律協調分散処理方法において、新たに受
け付けた処理要求を受け付けられるか否かの情報を上記
プロセスから収集する第１のステップと、上記情報に基
づき受け付ける上記プロセスを選択し、この選択された
プロセスに上記処理要求を割り付けるとともに処理させ
る第２のステップと、上記第２のステップで割り付けら
れた処理要求の処理が終了したプロセスのうち、上記第
２のステップで割り付けられなかった上記処理要求を受
け付られる上記プロセスを探し出し、この探し出された
プロセスに当該処理要求を割り付けるとともに処理させ
る第３のステップと、上記第３のステップ終了後に実行
され、多くの処理要求を保有する上記プロセスから上記
処理要求の保有数が少ないプロセスに上記処理要求を移
して処理させる第４のステップと、を備えたものであ
る。

【００３６】

【発明の実施の形態】

実施の形態１．図１は、実施の形態１に係る自律協調情
報処理装置の機能ブロック図である。図１において示す
ように、1400は複数の処理要求を受け付け、これらの処
理要求を処理する情報処理部であり、処理要求には、１
つないし複数のデータベースから所望する情報の検索、
問題の解決、あるいはサービス提供を受ける等の処理が
含まれる。この情報処理部1400は、通常１つのプロセス
又はスレッドとして独立にプロセッサ時間（ｃｐｕタイ
ム）を割り当てられ実行され、また、複数のプロセッサ
のそれぞれに割り当てられ実行されると、高速に動作す
ることができる。1000は、以下の３つの構成要素からな
り、情報処理部1400とは分離独立した１つまたは複数の
エージェントである。 1)自律した判断をして複数の情報処理部1400間での協調
連携処理を行い、他のエージェント1000との協調処理を
実行し、新たな処理要求を受け付けるか否か、又は、メ
タ制御管理部からの要求に応じた協調処理を行って、新
たな処理要求がメタ制御管理部から受け付けた要求に見
合う処理要求であるか否かを判断し受け付けるか否かを
決定する協調処理部1100、 2)１つまたは複数の情報処理部1400を仮想リンクにより
束縛しその情報処理部1400の実行制御の管理または状態
監視と、リンクの動的な接続変更による情報処理部1400
との接続制御と、協調処理部1100の実行制御の管理と、
情報処理部1400または協調処理部1100との通信を行なう
メタ制御管理部1200、 3)協調処理部1100あるいはメタ制御管理部1200において
利用する内部情報を保管管理する１つないし複数の内部
情報格納部1300、情報処理部1400は、すべてが異なる機
能を実現したものである必要はなく、同一の機能を実現
したものが複数個存在してもよい。

【００３７】この実施の形態１に係る自律協調情報処理
装置は、情報処理部1400とエージェント1000とは互いに
分離独立した構成要素ではあるが、仮想リンクにより束
縛しあっている。異なる情報処理部1400を含めた、他の
プロセス、又はアプリケーションシステム、との協調連
携処理を策定・調整するための協調処理を実現する通信
は、情報処理部1400内では行わず、分離独立して設けら
れたエージェント1000が情報処理部1400からの依頼を受
けて代行処理する。しかしながら、上述通信以外の単な
る情報交換のための通信は、その限りにあらず、情報処
理部1400において行うことも可能である。分離独立と
は、独自に稼働する別プロセスとして実現することを意
味する。このエージェント1000は、他プロセス、アプリ
ケーションシステム、他のエージェント1000との通信を
含む協調処理を自律した判断に基づき行なう協調処理部
1100と、協調処理部1100より得られた情報に基づき、代
行している、すなわち、仮想リンクにより束縛されてい
る、情報処理部1400の実行制御の管理を行ったり、情報
処理部1400の処理状況の監視を行ないその処理状況に応
じて、協調処理部1100に対して情報処理部1400において
処理する処理要求の引き受けを依頼したり、情報処理部
1400の処理状況、又は情報処理部1400の要求に応じて、
協調処理部1100の協調処理の実行制御の管理を自律した
判断に基づき行なうメタ制御管理部1200からなる。

【００３８】協調処理部1100は、例えば、図２に示すよ
うに構成することができる。図２に示す協調処理部1100
は、他の外部プロセス、アプリケーションシステム、他
のエージェント1000との通信を行なう外部通信部1101
と、エージェント1000内のメタ制御管理部1200あるい
は、エージェント1000内の内部情報格納部1300との内部
通信を行なう内部通信部1103と、自律協調処理時の協調
問題の解決を行なう問題解決エンジンである協調問題解
決部1102と、協調問題解決部1102が協調問題解決時の問
題解決の方針／規則として利用する複数存在する戦略リ
ソースを格納する協調戦略リソースベース部1104と、協
調問題解決部1102が協調問題解決時に必要な情報を格納
する内部情報格納部1300とから構成することができる。
この内部情報格納部1300は、オプショナルなもので必須
の構成要素ではない。

【００３９】協調処理部1100とメタ制御管理部1200は、
別プロセスとして分離独立させて実現するとよいが、同
一プロセスにおいて、モジュール分けして実現すること
も可能である。また、協調処理部1100とメタ制御管理部
1200の両者において、共通して利用する内部情報を格納
し、協調処理部とメタ制御管理部1200の両者がその情報
の参照と情報の登録といった利用ができる内部情報格納
部1300を必要に応じてエージェント1000を構成する構成
要素として装備することが可能である。利用目的に応じ
て内部情報格納部1300を複数個設けることも可能であ
る。また、協調処理部1100に固有の内部情報格納部1300
やメタ制御管理部1200に固有の内部情報格納部1300を設
けることも可能である。

【００４０】さらに、上述エージェント1000には、テン
ポラルなエージェント1000と、パーシステントなエージ
ェント、が存在する。テンポラルなエージェント1000
は、そのエージェント1000の存続可能な期間であるライ
フタイムの設定が可能であり、その設定した期間を経過
するとそのエージェント1000は、消滅する。そのエージ
ェント1000と仮想リンクにより束縛されている情報処理
部1400は、そのエージェント1000の指示に従って動作を
決定することになる。すなわち、ある特定のエージェン
ト1000において、そのエージェント1000のライフタイム
が経過した後、そのときの状況に応じて、そのエージェ
ント1000と仮想リンクにより束縛されている複数の情報
処理部1400のなかから、同時に消滅する情報処理部1400
の指定が可能である。また、情報処理部1400の指示によ
り、その情報処理部1400と仮想リンクにより束縛しあっ
ているエージェントを消去することができる。パーシス
テントなエージェント1000は、自分自身を含めた第三者
から消去されるまでは、存続しつづける。

【００４１】内部情報格納部1300に格納された情報は、
基本的には、一時的な利用を意識したものでライフサイ
クルの短いテンポラルなものを想定している。よって、
内部情報格納部1300が属しているエージェントが消滅す
ると内部情報格納部1300も消滅する。しかしながら、常
にシステム起動時に生成するエージェントあるいは指定
したエージェント1000に関しては、内部情報格納部1300
をハードディスク等の別メディアに登録保管し、起動時
に内部情報をダウンロードして利用することが可能であ
る。このように、内部情報格納部1300単位あるいは、内
部情報毎にデータのライフタイムを設定することができ
る。従って、ライフタイムとして設定した期間を過ぎる
と自動的に消滅する。また、ライフタイムを永久と設定
すれば、システム側で情報の消去をその内部情報に対し
て行なうまで存在しつづけることになる。ただし、その
内部情報格納部1300を管理しているエージェント1000が
消滅した段階でその内部情報も消滅する。例えば、エー
ジェント1000が受け入れたタスク要求リスト、検索処理
のための検索キーワードのリストなどを内部情報として
内部情報格納部1300に格納し利用する。

【００４２】◆動作 まず、動作の概要について説明する。外部からエージェ
ント1000へ要求（例えば、検索要求）があると、エージ
ェント1000は他のエージェント1000と通信しあい、お互
いの処理状況等に応じてどのエージェント1000がその要
求を引き受けるかを決定する。要求を引き受けたエージ
ェント1000は、自らが管理する情報処理部1400のうち、
どの情報処理部1400に要求を実行させるかを決定する。
この決定は情報処理部1400の処理状況等に応じて行われ
る。要求を受け付けた情報処理部1400は、要求を実行す
る。情報処理部1400は、複数の要求を受け付けることが
でき、それらは待ち行列に入った順番で実行される。な
お、ここで待ち行列中の要求のうち優先順位の高い要求
が優先的に実行されるようにしても良い。

【００４３】一旦受け付けた要求は、従来の処理方式に
従うと、その情報処理部1400が最後まで処理を行うが、
この実施の形態１では、要求の再割り当てを行うことが
できる。情報処理部1400は、割り当てられた要求の処理
がすべて終了すると、エージェント1000へ終了通知を送
信する。エージェント1000は、この終了通知を受け取る
と、他の情報処理部1400で要求が多く溜まっているもの
がないかを判断し、溜まっている情報処理部1400があれ
ば、その情報処理部1400から処理を終了した情報処理部
1400へ要求を振り分ける。なお、終了通知は、残りの要
求が少なくなり、まもなくすべての要求の処理が終了す
ると予測された場合に、送信することとしてもよい。

【００４４】以上のような動作を行うため、情報処理部
1400の稼働率が上がり、全体として高速処理が可能とな
る。特に、各情報処理部1400が異なるプロセッサで実行
される場合には効果が高い。

【００４５】以下に詳細な動作について説明する。図１
に示すように複数のエージェント1000とそのエージェン
ト1000に仮想リンクにより束縛されている情報処理部14
00からなる自律協調処理装置の動作について説明する。
エージェント1000の持つ使命すなわち、行動のフェーズ
は、２つある。1つは、複数のエージェント1000との協
調処理に応じて、各エージェント1000と仮想リンクによ
り束縛されている情報処理部1400に処理させるタスクを
配分したり、情報処理部1400の実行制御の管理を行なう
第１のフェーズと、もう一つは、情報処理部1400の要求
または、情報処理部1400の実行状況に応じて協調処理部
1100の他エージェント1000との協調メカニズムなる協調
戦略を適宜動的に変更する第２のフェーズである。

【００４６】まず第１のフェーズについて説明する。図
１に示す自律協調情報処理装置外にある外部プロセスあ
るいは、情報処理部1400からエージェント1000へタスク
処理依頼（処理要求ともいう）が入力される。タスク処
理依頼を受けとったエージェント1000は、協調処理部11
00を通して、他の複数のエージェント1000の協調処理部
1100と通信しあい、協調処理部1100において処理要求の
分担割当を行なう。処理要求の分担作業とは、処理要求
をどのエージェント1000に分担させるかを決定する処理
である。処理要求の分担割当時の各エージェント1000の
協調処理部1100は、協調処理部1100内に格納している戦
略のなかかから、エージェント1000間の協調処理の進捗
状況に応じて戦略を選択し、その戦略にのっとって、処
理要求の分担割当のための協調処理を行なう。

【００４７】次に、メタ制御管理部1200は、協調処理部
1100が受けとったタスク処理依頼の処理プランを決定す
る。処理プランは、タスク処理要求をどの情報処理部14
00が実行するかというタスク処理のための計画のことで
あり、エージェント1000が仮想リンクにより束縛してい
る１つないし複数の情報処理部1400の稼働状況に応じて
決定する。この処理は、情報処理部1400とメタ制御管理
部1200間で通信を行なって妥当な処理プランを策定す
る。処理プランが決まると、メタ制御管理部1200は、仮
想リンクにより束縛している１つないし複数の情報処理
部1400に対して分担割り当てされたタスク処理要求を処
理する旨の指示を出す。また、メタ制御管理部1200は、
各エージェント1000の協調処理部1100との通信を介した
協調処理により、獲得した情報に基づいて、適宜動的に
仮想リンクにより束縛している複数の情報処理部1400の
処理の実行制御の管理を行ない、また、情報処理部1400
との仮想リンクの接続の変更を行なうなどのリンクの接
続制御を行なう。

【００４８】第２のフェーズについて説明する。メタ制
御管理部1200は、情報処理部1400と通信して情報処理部
1400における処理状況を把握し、その処理状況に応じ
て、協調処理部1100に対して協調問題解決のための協調
戦略の変更を指示するなど、協調処理部の協調処理の実
行制御の管理を行なう。

【００４９】よって、仮想リンクにより束縛している情
報処理部1400の実行しているモジュールや処理要求の内
容、タスク処理の進捗状況などの処理状況を考慮した協
調処理を協調処理部1100において行なうことが可能であ
る。また、メタ制御管理部1200は、情報処理部1400から
受け付けた要求に応じた協調処理を行なうように協調処
理部1100に指示を出すか、または、新たなエージェント
1000の協調処理部1100とリンクをはりその要求を新たに
リンクのはったエージェント1000の協調処理部1100に処
理を代行させるといった処理を行なう。さらに、メタ制
御管理部1200では、情報処理部1400からの要求によっ
て、エージェント1000を消滅させたり、エージェント10
00とのリンクを適宜変更するといった処理を行なうこと
ができる。

【００５０】協調処理部1100とメタ制御管理部1200は、
適宜必要に応じて内部情報格納部1300を使い分けて、情
報を格納し利用する。協調処理部1100からメタ制御管理
部1200への情報の伝達は、内部情報格納部1300を経由し
て情報伝達するか、あるいは、プロセス間通信により情
報伝送する。プロセス間通信による場合は、メタ制御管
理部1200内の内部情報格納部1300に必要とあれば格納す
ることになる。また、図１に示すメタ制御管理部1200を
複数のメタ制御管理部1200により構成することも可能で
ある。この場合、メタ制御管理部1200における負荷分散
と処理の効率化を実現することが可能となる。

【００５１】図２において示した協調処理部1100の動作
を説明する。外部通信部1101において、外部プロセスあ
るいは、外部アプリケーション、他のエージェント1000
の協調処理部1100との通信により情報を入手し、協調問
題解決部1102に送信される。協調問題解決部1102では、
受け取った情報と、協調戦略リソースベース部1104に登
録されている協調戦略に従って、依頼のあった処理要求
を受け入れるか否か、を判断する。受け入れる場合は、
内部通信部1103を経由してメタ制御管理部1200に通知す
る。また、受信情報を協調問題解決部1102において分析
評価して、その結果を内部通信部1103を経由してメタ制
御管理部1200に通知する。また、協調問題解決部1102
は、メタ制御管理部1200からの要求、メタ制御管理部12
00の処理状況、協調問題解決部1102の処理状況に応じ
て、協調戦略を協調戦略リソースベース部1104より、選
択して、協調問題解決部1102において利用する協調戦略
を変更するなどして協調問題解決部1102自身の処理の実
行制御の管理もあわせて行なう。この協調問題解決部11
02から、上述協調問題解決部1102の処理の実行制御の管
理を行う機能を、分離独立させて実現することが可能で
ある。

【００５２】また、メタ制御管理部1200は、図３に示す
ように、協調処理部1100が引き受けた処理要求の実行手
順の作成または調整を行なう処理スケジュール管理部12
01と、処理スケジュール管理部1201において作成された
処理スケジュールに基づいてメタ制御管理部1200とリン
クしている情報処理部1400の実行制御の管理を行なう実
行管理部1202と、情報処理部1400との情報交換のために
異なる通信規約ごとに用意したインターフェースモジュ
ールを適宜使い分けて通信を行ない情報処理部1400とメ
タ制御管理部1200とのリンクを動的に切替える接続管理
部1203と、によって構成される。

【００５３】図３において示したメタ制御管理部1200の
動作を説明する。メタ制御管理部1200内の処理スケジュ
ール管理部1201では、エージェント1000内の協調処理部
1100が受け取った処理要求をメタ制御管理部1200とリン
クしている情報処理部1400に依頼できる形態へ変換し、
内部情報格納部1300に登録する。実行管理部1202では、
処理スケジュール管理部1201において作成された処理ス
ケジュールに基づいて順次処理要求を情報処理部1400に
依頼する。依頼は、メタ制御管理部1200とリンクしてい
る情報処理部1400に対して処理要求を引き受けることを
依頼するメッセージを情報処理部1400に送信することに
より行う。情報処理部1400は、そのメッセージを受け取
り、引き受け依頼のあった処理要求を受け取るとともに
記憶しておく。このとき接続管理部1203に用意されてい
るインターフェースモジュールを介して通信を行なう。
メタ制御管理部1200における情報処理部1400への処理要
求の受渡し、情報処理部1400の処理の進捗の管理、情報
処理部1400との情報交換時に利用するメッセージは、情
報処理部1400において実現されている機能、又は対象分
野ごとに固有のフォーマット、形式が存在するため、メ
タ制御管理部1200と仮想リンクにより束縛されている情
報処理部1400に合ったインターフェースモジュールを接
続管理部1203において選択して情報交換を行なう。

【００５４】異なる情報処理部1400との通信には、異な
るインターフェースモジュールを介して通信を行なう。
処理要求の情報処理部1400への引き受けの依頼は、実行
管理部1202が行ない、情報処理部1400の処理状況に応じ
て、処理要求の相手先を決定することになる。処理要求
にあった通信プロトコルによる情報交換に基づく、処理
要求の管理を容易にメタ制御管理部1200に組み込むこと
ができる。従って、処理要求に固有のプロトコルあるい
は、通信管理機構をインターフェースモジュールとして
実現し適宜使い分けることができため、１つのメタ制御
管理部1200において、複数の異なる情報処理部1400を容
易に管理することができる。また、情報処理部1400から
処理スケジュールの変更を要求するメッセージをメタ制
御管理部1200において受け取るとその情報処理部1400に
合ったインターフェースモジュールを起動して解読し、
情報処理部1400からの要求に応じて処理スケジュールを
変更することが可能である。

【００５５】実施の形態２．実施の形態２は、メタ制御
管理部1200を複数のエージェント1000で共有することに
より、情報処理部1400の管理等の効率を向上させるもの
である。

【００５６】図４は、実施の形態２に係る自律協調処理
装置の機能ブロック図である。図４において図１と同一
の符号は同一又は相当の部分を表す。1200Aは、基本的
に図１に示したメタ制御管理部1200と同様のものである
が、複数のエージェント1000に共有され、複数の情報処
理部1400を管理するメタ制御管理部となっている。

【００５７】◆動作 次に、動作について説明する。メタ制御管理部1200A
は、複数の協調処理部1100からの要求を受け取ると、情
報処理部1400の処理状況等を考慮して処理プランを作成
する。作成された処理プランは情報処理部1400へ通知さ
れ要求が割り当てられる。情報処理部1400では、上述の
実施の形態１と同様に要求の処理を行い、要求の処理が
終了すると終了通知を行う。このとき、実施の形態１で
は、複数のメタ制御管理部1200へ終了通知を行う必要が
あるが、この実施の形態２では１つのメタ制御管理部12
00Aへ通知を行えばよいため、情報処理部1400の処理負
担が軽く、処理効率が良くなる。

【００５８】ここで、協調処理部1100及び内部情報格納
部1300を別にしている理由は、それぞれのエージェント
1000で別々の協調処理を行うことができるためである。
例えば、１つの協調処理部1100は、処理プランを作成
し、他の協調処理部1100はすでに割り当てた要求の再調
整を行うといった別々の状態をつくることも可能であ
る。

【００５９】また、ここで実現されたメタ制御管理部12
00Aは、各エージェント1000の固有のメタ制御管理部120
0Aとして機能すると同時に、複数のエージェント1000と
複数の情報処理部1400との統括管理をも合わせて行なう
ことになる。よって、メタ制御管理部1200Aにおいて、
協調処理部1100からの入力情報の統合管理機能、協調処
理部1100の使い分け、内部情報の統合管理といったあら
たな機能を実現することになる。メタ制御管理部1200A
を共有している複数のエージェント1000の協調処理部11
00からの入力情報を共有するメタ制御管理部1200Aにお
いて、その入力情報を基にして、情報処理部1400の実行
制御の管理を行ない、情報処理部1400に処理させるタス
クを配分する。また、メタ制御管理部1200Aは情報処理
部1400の要求または、情報処理部1400の実行状況に応じ
て、協調処理部1100を選択し、その協調処理部1100に対
して他エージェント1000との協調メカニズムなる協調戦
略の適宜動的な変更を指示する。

【００６０】また、情報処理部1400におけるエージェン
ト1000の使い分けも、実施の形態１では、情報処理部14
00内部で判断し使い分けなければならないが、図４の構
成では、メタ制御管理部1200が情報処理部1400から自律
して判断を行なって利用するべきエージェント1000を決
定することができるため、情報処理部1400の負荷を軽減
することができる。

【００６１】実施の形態１のエージェント1000のモデル
構成では、エージェント1000の数だけメタ制御管理部12
00が必要になるが、共有することにより、必要なメタ制
御管理部1200の数量を低減することができる。他のエー
ジェント1000の協調処理の結果や他のエージェント1000
の内部情報をあたかも自身のエージェント1000の内部情
報であるかのように利用することができる。複数のエー
ジェント1000にまたがった情報交換は、メタ制御管理部
1200の内部処理として実現できるため効率がよくなる。

【００６２】実施の形態３．実施の形態３は、メタ制御
管理部1200Aだけではなく、内部情報格納部も２つのエ
ージェント1000で共有することにより、エージェント10
00間の情報交換を容易にする実施の形態である。

【００６３】図５は、この実施の形態３に係る自律協調
処理装置の機能ブロック図である。図５において、図４
と同一の符号は同一又は相当の部分を表す。1300Aは、
複数のエージェント1000に共有され、それぞれのエージ
ェント1000に必要な情報を格納する内部情報格納部、15
00は、複数のエージェント1000に共有され、それぞれの
エージェント1000がアクセスできる内部情報格納部1300
A内の記憶領域を制限するアクセス権制御部である。

【００６４】以上のような構成において、次にその動作
について説明する。アクセス権制御部1500は、内部情報
格納部1300A内の記憶領域のうち、当該協調処理部1100
又はメタ制御管理部1200Aがアクセスが可能な領域を指
定し、内部情報格納部1300Aへ通知する。協調処理部110
0又はメタ制御管理部1200Aから内部情報格納部1300Aへ
のアクセス要求があったときは、アクセス権制御部1500
は、この要求主体からどの領域のアクセスが可能である
かを判断し、その領域の情報へのアクセスを解放すると
ともに、アクセス可能な領域以外の記憶領域を隠蔽す
る。

【００６５】以上のような処理を行うことにより、協調
処理部1100又はメタ制御管理部1200Aは、必要な情報を
高速に手に入れることができる。例えば、協調処理部11
00が協調処理に用いる情報を内部情報格納部1300Aから
得ようとしていた場合に、膨大なデータの中から必要な
データを検索すると長時間を要する。また、内部情報格
納部1300Aには、その協調処理部1100が使用するデータ
と使用することのないデータが混在している。そこで、
使用しないデータが記憶されている記憶領域は、アクセ
スできないこととすると、検索領域が狭くなり高速なア
クセスが可能となる。以上のような場合、使用しないデ
ータはエージェント1000に共有されていない別個の内部
情報格納部1300Aに格納することも考えられるが、他の
複数のエージェント1000に共有的に使用されるデータ
は、共有の内部情報格納部1300Aに格納する必要がある
ため、かかる場合おいて、この実施の形態３は特に有効
となる。

【００６６】実施の形態４．実施の形態４は、複数のエ
ージェント1000を集中的に管理するプラン策定部を設け
ることにより処理プランを集中的に作成する実施の形態
である。図６は、この実施の形態４に係る自律協調処理
装置のブロック図である。図６において、図１と同一の
符号は同一又は相当の部分を表す。2000は、複数のエー
ジェント1000を集中的に管理し、外部から受け付けた処
理要求をどのエージェント1000に担当させるかという処
理プランを作成するプラン策定部である。なお、このプ
ラン策定部2000は、図７に示すように、外部からの処理
要求を受け付けるプラン策定処理部2900と、このプラン
策定処理部2900の要求によりプラン策定をするプラン策
定エージェント2800という２つの独立に実行可能なモジ
ュールに分けることもできる。

【００６７】このプラン策定部2000は、情報処理部1400
において処理させたい断続的に同時多発する処理要求を
受け付け、処理要求を登録保管する受付管理部2100、受
け付けた処理要求を解決し実行するために、複数のエー
ジェント1000との協調により、受け付けた処理要求の解
決実施のためのプランを策定しプランを生成するプラン
生成部2200、プラン生成部2200により作成されたプラン
に基づき、エージェント1000に対し処理要求の引き受け
と実行を指示するプラン実行指示管理部2500、プラン策
定時に必要な内部情報を格納するプラン策定内部情報格
納部2400、プラン実行指示管理部2500からの指示に従っ
て各エージェント1000に対して処理要求の分担割当を通
知したり、プラン策定時にプラン生成部2200の指示に従
ってエージェント1000にメッセージを発信し、エージェ
ント1000から送信されてきたメッセージを受信するなど
の通信の送受信の管理を行なう通信管理部2300、から構
成される。

【００６８】以上のような構成において、次にその動作
について説明する。受付管理部2100は外部から処理要求
を受け付けると、プラン策定内部情報格納部2400内へ処
理要求を登録する。また、プラン生成部2200に対して
は、新たな処理要求を受け付けたことを通知する。ここ
で、受付管理部2100は、処理要求の持つ属性により、処
理要求の受付を拒否したり、受付処理にかかる時間を変
えるなどの受付の管理を行なうことができる。

【００６９】図８は、この実施の形態４のプラン策定処
理を示したフローチャートである。以下、この図８に基
づきその動作を説明する。まず、新たな処理要求を受け
付けるとステップＳ１からスタートし、ステップＳ２に
移る。ステップＳ１は、第１のプランニングである。プ
ラン生成部2200では、同じ処理を繰り返し実行しないた
めに、処理要求の受信通知を受け取ると、受け付け済み
であり、かつ未処理である処理要求と、新たに受け付け
た処理要求とを１つにまとめる統合処理を行う。また、
受け付けた処理要求が既に処理済みである場合、その処
理結果を再利用することで処理を完了したとみなすか再
度実行が必要であるかを判定する。再度実行が必要と判
定された処理要求については上述の統合処理のふるいに
かける。この処理を第１次のプランニングという。

【００７０】・第１次のプランニング 受け付け処理要求を複数の処理要求に分解して、上記に
示すように細分化された個々の処理要求と既に受け付け
ている処理要求との統合処理を行なう。プラン生成部22
00は、プラン生成作業中でなければ、直ちにプラン策定
内部情報格納部2400から処理要求の受信通知を読み込
み、優先順位の高い処理要求から順次処理し始める。プ
ラン生成部2200は、処理要求を複数の処理要求に分解
し、個々の処理要求を分析して、この要求を処理できる
エージェント1000の機能要件を明確にする。そして、そ
の条件にあったエージェント1000を探すため、各エージ
ェント1000の協調処理部1100に対して、機能要件を判定
するのに必要な情報の提供を求めるメッセージをマルチ
キャストする。このマルチキャストは、通信管理部2300
を介して行われる。そのメッセージを受けとったエージ
ェント1000は、求められている項目情報をプラン策定部
2000に送信する。プラン策定部2000では、その送信情報
を通信管理部2300において受信し、即プラン策定内部情
報格納部2400に格納する。その受信情報に基づき、プラ
ン生成部2200が新たに受け付け複数に分解した処理要求
と同じ処理要求を抱えているエージェント1000を探す。
そのエージェント1000が見つかればその処理要求は、そ
のエージェント1000が抱えている情報処理部1400におい
て実行されるのを待ち、その実行結果を利用する。見つ
からない場合は、第２のプランニングを起動しその処理
要求の処理プランの策定を行う。この第１のプランニン
グが終了すると、次のステップＳ３に移る。

【００７１】ステップＳ３は第２次のプランニングであ
る。この第２次のプランニングでは、処理要求を処理す
るための実行モジュールの実行回数を極力低減するよう
に、第１次のプランニングにおいて第２次のプランニン
グによる処理プランの策定が必要とされた処理要求に対
して処理プランの策定を行う。 ・第２次のプランニング 通信管理部2300は、ある一定の期間にエージェント1000
から送られてきた情報、あるいは、特に、通信管理部23
00が管理している特定のエージェント1000から情報が送
られてくるのを待って、それまでに得られた情報から、
処理要求を依頼できるエージェント1000を選別する。選
別された各エージェント1000に対して、具体的な処理要
求をマルチキャスト通信にて送信し、処理要求を受けと
ることが可能であるかどうかを問い合わせる。メッセー
ジを受けとったエージェント1000の協調処理部1100は、
エージェント1000と通信して、現在のメタ制御管理部12
00と仮想リンクにより束縛している情報処理部1400の処
理状況を確認し、エージェント1000がかかえている引受
処理要求の未処理残を合わせて考慮して引き受けが可能
であるかどうかをプラン策定部2000に通知する。処理要
求の引き受けは部分的なものでもよく、受けとれる処理
内容も合わせて通知する。プラン策定部2000の通信管理
部2300は、処理要求の引き受けを依頼したすべてのエー
ジェント1000から返信が到着するまで待って、すべての
返信が出そろうと、プラン生成部2200に対して、返信が
出そろったことを通知する。返信の受信の度に、プラン
策定内部情報格納部2400に登録する。

【００７２】プラン策定部2000のプラン生成部2200は、
引き受け可能と通知してきたエージェント1000が送って
きた。引き受け可能な処理内容をすべて調査して、エー
ジェント1000間に重複がない部分の処理要求に関して
は、受けとりを通知してきたエージェント1000に引き受
けを依頼し、重複している処理要求分については、受け
とりを通知してきたエージェント1000間で協調して処理
要求を配分する。エージェント1000の属性や、情報処理
部1400の処理状況あるいは、エージェント1000が持つ未
処理な受けとり処理要求などの諸情報をもとに比較評価
して分担を決定する。ここで、引き受けが可能な処理要
求とは、情報処理部1400が抱えている処理要求のデータ
の追加あるいは制御パラメータの変更のみにて処理が可
能で新たな処理要求として処理する場合に比べて実行可
能モジュールの起動回数を低減することができる処理要
求をいう。引き受け先のエージェント1000と依頼する処
理内容が決定すると、該当するエージェント1000に対し
て決定した処理要求を通信管理部2300を通して通告す
る。通告を受けたエージェント1000の協調処理部1100
は、メタ制御管理部1200に通告のあったことを通知し受
けとった処理要求の処理を指示する。メタ制御管理部12
00は、その指示に従ってメタ制御管理部1200が抱えてい
る情報処理部1400の中から最適な情報処理部1400に対し
て、その処理要求の実行を指示する。ここで、第２次プ
ランニングが終了する。次にステップＳ４に移る。

【００７３】ステップＳ４は第３次のプランニングであ
る。 ・第３次のプランニング しかしながら、一般的には、第２次のプランニングにお
いて、エージェント1000への割当ができず、プラン策定
部2000が抱えたままの処理要求が存在する。ここに残っ
ている処理要求は、要求の一部分のみが依頼できずに溜
っている処理要求や、要求のすべてを依頼できずに残っ
ている処理要求が存在する。プラン生成部2200は、この
処理要求の再統合化処理を行なって処理要求の洗練化を
行なう。プラン生成部2200がこの依頼できずに残ってい
る処理要求を、割り当てられた処理要求を全て処理した
情報処理部1400、すなわちアイドル状態である情報処理
部1400、の割り当て要求に応じてその情報処理部1400と
リンクしているエージェント1000に割り当てる作業が第
３次のプランニングである。この第３次のプランニング
では、情報処理部1400のアイドル状態を極力少なくする
ように処理要求を負荷分散することにより、高速な処理
を実現するものである。受けとった処理要求をすべてや
り終えたエージェント1000から新たな処理要求の引き受
けをプラン策定部2000に打診してくると同時に、第２次
プランニングが終了し稼働していない状態である場合に
この第３次プランニングが起動される。起動されると第
２次プランニングは、ロックされ第３次プランニングが
終了するまで、新たな第２次プランニングはできない。

【００７４】エージェント1000から、処理要求の引き受
け要求の意思表示がプラン策定部2000に対してなされる
と、第２次プランニングにおいて、引き取られなかった
処理要求を意思表示のあったエージェント1000に対し
て、引き受け可能である未処理の処理要求があるかチェ
ックしてもらい、あれば引き受け可能である処理要求の
引き受けを依頼する。複数個の受けとりが可能である場
合は、その中で、優先順位の高いものを優先させて受け
とりを依頼する。第３次のプランニングが終了すると、
次のステップＳ５に移る。

【００７５】ステップＳ５は、第４次のプランニングで
ある。この第４次のプランニングも第３次のプラニング
と同様に情報処理部1400のアイドル状態を極力少なくす
ることにより処理の高速化を実現する負荷分散を行うも
のである。 ・第４次のプランニング 条件が合わず受けとれる処理要求がない場合に、このエ
ージェント1000に処理要求を割り当てるためのプランニ
ング作業が第４次のプランニングである。プラン生成部
2200は、このエージェント1000に新たな処理要求の受け
とり可能条件の提示を求め、その条件を充足する処理要
求を未処理の引き受け処理要求として抱えているかどう
かをエージェント1000に対してマルチキャスト通信して
問い合わせる。問い合わせの結果、条件を充足する処理
要求を未処理の引き受け処理要求として抱えていると答
えてきたエージェント1000の中から、最も多くの未処理
の引き受け処理要求を抱えているエージェント1000、あ
るいは、他のエージェント1000と比べて処理の優先順位
の大きいものを最も多く抱えているエージェント1000の
中からプラン策定部2000の処理の戦略に応じて１個のエ
ージェント1000を選択しそのエージェント1000に対し
て、その抱えている未処理の引き受け処理要求を２分割
して、一方を受けとりの意思表示を行なっているエージ
ェント1000に引き渡すことを通知する。この通知、を受
けたエージェント1000は、直ちに持っている引き受け処
理要求を２分割し、指定されたエージェント1000に２分
割した一方を引き渡す。受けとりの意思表示を行なって
いるエージェント1000は、この引渡し処理要求を受け入
れる。この段階で第４次のプランニングが終了し、ステ
ップＳ６で一連の処理が終了する。

【００７６】しかしながら、第４次のプランニングが終
了した時点でも、受けとれる処理要求がない場合は、受
けとることができる処理要求がプラン策定から提示のあ
るまで待つ。このエージェント1000は、第３次、第４次
のプランニングの起動時に処理要求の受けとりが可能で
ある。第２次、第３次、第４次のプランニングの各フェ
ーズで、受けとりの意思表示をしているエージェント10
00が複数存在するときは、そのエージェント1000間で協
調して分担引き受けする。

【００７７】プランニングの具体例 次により詳細にプランニングを説明する。ここでは、イ
ンターネット上のWebサーバーからデータを検索する場
合を例にとり説明する。 ・第１次のプランニング プラン策定部2200において、まず受け取った検索要求を
検索式に含まれている検索キーワード単位に細分化す
る。ここで、受け取った検索要求は、表１のような要求
を受け取ったとする。

【００７８】

【表１】

【００７９】ユーザー（usr2）より受け取った要求は、
「www1というWebサーバー上から、「a」,「b」という２
つのキーワードの両方を持つデータを検索せよ。」とい
うものである。これをまず細分化する。ここでは、キー
ワードで２つの要求に細分化し、「「a」というキーワ
ードを持つデータを検索せよ」という要求と、「「b」
というキーワードを持つデータを検索せよ」という要求
が作成され、表２のようになる。ここでは、キーワード
によって要求を細分化することができたが、例えば、検
索対象領域が複数指定されている場合には、検索対象ご
とに要求を細分化することもできる。

【００８０】

【表２】

【００８１】次いで、細分化した検索要求ごとにプラン
策定内部情報格納部2400内にある図示しない検索結果デ
ータベースと顧客要求データベースをチェックして、既
に検索済みか検索実施中か未検索であるのかを確認す
る。既に検索済みであるものは、その検索結果を再利用
し、検索中であるものは、その検索が終了するのを待
ち、未検索であるものについては、処理プランの作成を
行う。

【００８２】プラン策定部2200では、検索要求が送信さ
れる度に検索要求を受け付けるため、ある一つの検索要
求の処理プランの作成中であるにもかかわらず、多数の
検索要求を受け付けることがある。したがって、その受
け付けた検索要求の細分化後の検索要求に対して,同じ
検索要求は,一つにまとめるなどして、同じ検索処理は,
２度繰り返さないという負荷分散戦略に基づいて検索要
求の統合再編を行なう。これも第１次のプランニングと
して行なう。

【００８３】ここで作成された処理プランは、クライア
ントの検索要求の処理の進捗管理の基本単位として取り
扱われる。プラン策定部2200は、この第１次のプランニ
ングにおいて作成された処理プランをプラン実行指示管
理部2500に送信し、処理プランの進捗管理を依頼する。

【００８４】・第２次のプランニング 第２次のプランニングは、検索要求を処理するための実
行モジュールの実行回数を極力低減するという負荷分散
戦略に基づいて、検索要求の処理プランを策定するもの
である。第２次のプランニングでは、まず、要求の機能
要件を各エージェント1000へマルチキャストする。ここ
で、WWW1内には、複数の検索領域が存在し、表２「a」
に対する要求は、例えば、URL1〜URL3という３つの領域
ごとに表３のように分割されたとする。このような、要
求を受けられるかについて上述のマルチキャストを行
う。

【００８５】

【表３】

【００８６】エージェント1000は、この機能要件を受信
後、管理している情報処理部1400が現在抱えている検索
要求の検索条件をチェックし、受信した機能要件と比較
することにより、検索要求の引き受けが可能であるかど
うかを判断し、その結果をプラン策定部2000に通知す
る。ここで、あるエージェント1000と仮想リンクしてい
る情報処理部1400の検索要求は表４に示すようなもので
あったとする。引き受けが可能である場合は、引き受け
が可能である処理内容も含めて送信する。ここでいう引
き受けが可能であるかどうかの判定は、エージェント14
00が受け取った検索要求の検索条件と、情報処理部1400
の抱えている検索要求の検索条件を比較して、両検索条
件の検索領域が同一であり、両検索条件の検索対象ＵＲ
Ｌリストに同一のＵＲＬリストが存在するとき、引き受
けが可能であるという。

【００８７】

【表４】

【００８８】表３と表４の関係においては、URL1,URL3
が同一の検索領域となっており、URL1についての「a」
の検索、URL3についての「a」の検索を引き受ける旨を
プラン策定部2000へ送信する。プラン策定部2000は、各
エージェント1000が通告してきた引き受け可能な処理内
容をチェックして、各エージェント1000間で重複してい
ない部分については、引き受けを通告してきたエージェ
ント1000に引き受けを依頼する。

【００８９】重複した部分については、引き受けを通知
してきたエージェント1000間で協調して分担を決定す
る。このときの分担割り当ては、エージェント1000が管
理する情報処理部1400が抱えている検索要求の中で、引
き受け要請されている検索要求の優先順位以上の優先度
を持つ検索要求の数量が少ないものほど優先する。情報
処理部1400への割り当てができなかった検索要求は、プ
ラン策定部2000内のプラン策定内部情報格納部2400に保
管する。プラン策定内部情報格納部2400に登録保管され
ている検索要求の統合再編を行なう。統合再編は、ＵＲ
Ｌのダウンロード回数を極力少なくなるような検索要求
に書き替える。すなわち、ＵＲＬ単位に検索キーワード
を集めることにより、検索要求を集約する。すると、先
ほどのエージェント1000の情報処理部1400に割り当てら
れた検索要求は表５のようになる。

【００９０】

【表５】

【００９１】表３のURL1,3についての検索は、それぞれ
情報処理部a,b1400に割り当てられる。URL2についての
「a」の検索は、該当するものがないため、いずれかの
情報処理部1400へ割り当てられる。このような処理を行
なうことにより、ＵＲＬをダウンロードする回数を削減
することができるため、全体として高速な処理が可能と
なる。

【００９２】・第３次のプランニング しかしながら、一般的には、第２次のプランニングで
は、検索要求のすべての検索処理の情報処理部1400への
割り当てが必ずしも完了するとは限らない。そこで、第
３次のプランニングでは、情報処理部1400のアイドル状
態を極力低減するという負荷分散戦略に基づき、第２次
のプランニングで検索処理を情報処理部1400に割り当て
ることができず、プラン策定部2000が抱えている検索要
求をアイドル状態である情報処理部1400に割り当てる作
業を行なう。

【００９３】受け取った検索要求をすべて処理した情報
処理部1400の要求に応じてエージェント1000は、プラン
策定部2000に対して検索要求の引き受け要求の意思表示
を行なう。プラン策定部2000は、自らが抱えている検索
式の中で優先順位の高い検索キーワードを含む検索要求
の引受を優先的にエージェント1000に依頼する。

【００９４】・第４次のプランニング 第２次のプランニング終了後、プラン策定部2000がエー
ジェント1000に割り当てる検索要求を持ち合わせていな
いとき、すなわち、エージェント1000がプラン策定部20
00から引き受ける検索要求がない場合に、情報処理部14
00のアイドル状態を極力少なくするようにするという負
荷分散戦略に基づき、このエージェント1000に新たな検
索要求を割り当てるためのプランニング作業が第４次の
プランニングである。プラン策定部2000は、エージェン
ト1000より検索要求の引き受け要求の意思表示を受け取
ると、直ちに抱えている検索要求が最も多い情報処理部
1400を探すために、エージェント1000に対して、情報処
理部1400の抱えている検索要求の数量を問い合わせるメ
ッセージを発信し、エージェント1000から得た情報より
検索要求を最も多く抱えている情報処理部1400を探しだ
し、その情報処理部1400が抱えている検索要求を優先順
位の大きいものから順に２つのグループに割り振ること
により２分割する。

【００９５】表６は、あるエージェントA1000と仮想リ
ンクされた情報処理部a1400と、他のエージェントB1000
に仮想リンクされた情報処理部b1400と、が抱えている
検索要求を表している。ここで、エージェントＡ1000
は、検索要求を最も多く抱えているエージェント1000と
して発見されたものである。このエージェントA1000が
抱えている検索要求は、表７のように２つに分割され、
半分の検査要求がエージェントB1000に再割り当てされ
る。

【００９６】

【表６】

【００９７】

【表７】

【００９８】実施の形態５．実施の形態５は、プラン策
定戦略を状況に応じて動的に選択する実施の形態であ
る。図９は、実施の形態５に係る自律協調処理装置の機
能ブロック図である。図９において、図６と同一の符号
は同一又は相当の部分を表す。2200aは、受け付けた処
理要求を解決し実行するために、戦略指示部2600により
指示された戦略に基づいて、受け付けた処理要求の解決
実施のためのプランを策定しプランを生成するプラン生
成部、2700はプラン策定時に利用するプラン策定のため
の策定戦略知識を格納する戦略格納部、2600はプラン策
定のための戦略をプラン生成部2200aの処理状況あるい
は、受け付けた処理要求に応じて、動的に選択変更し、
または、プラン生成部2200aの実行制御の管理を行なう
戦略指示部2600である。

【００９９】以上のような構成において、次にその動作
について説明する。この実施の形態で示す装置は、基本
的には実施の形態４で示した動作と同じであるため、こ
の実施の形態５の特徴的な動作について説明する。特徴
的な動作とは、戦略指示部2600を設けることにより、プ
ラン生成部2200aのプラン策定の方法を適宜プラン生成
部2200aの処理状況、あるいは、受け付けた処理要求に
応じてプラン生成部2200aの実行制御の管理を行なうこ
とである。図９の自律協調情報処理装置では、処理要求
の目的などに応じてプラン生成部2200aにおけるプラン
作成手法、すなわち、プラン作成のための策定戦略を適
宜切替えて処理要求の目的あるいは、プラン策定部200
0、エージェント1000が抱えている処理要求の処理状況
に応じたプランの生成ができる。

【０１００】プラン生成部2200aは、受付管理部2100が
受け付けた処理要求に応じて、戦略指示部2600にプラン
策定の戦略を問い合わせ、戦略指示部2600の指示に従っ
て、処理要求を複数の処理要求への分割、処理要求の統
合管理、さらに、エージェント1000との協調処理の実行
戦略を決定し、その戦略に従って処理を行なうことがで
きる。戦略指示部2600は、プラン生成部2200aからの要
求、あるいは、プラン生成部2200aの処理状況、例え
ば、プランの生成に要する時間や、例えば実施の形態４
で示した第１次、第２次、第３次、第４次のプランニン
グにおいて、処理要求の依頼の受けとりができないエー
ジェント1000の数や、エージェント1000に受けとらせる
ことのできない処理要求の数に応じて、エージェント10
00の持つ属性や、第１次、第２次、第３次、第４次のプ
ランニングを行なうときの制御パラメータを適宜変更し
たり、プランニングそのものを、戦略格納部2700より選
択したプランニングの仕方(方針／規則)に基づいたプラ
ンニング方法に強制的に変更するなどして、プラン生成
部2200aの処理の実行制御の管理を行なう。

【０１０１】戦略指示部2600で生成される戦略には、例
えば、より少ないエージェント1000を用いて要求を処理
できるような戦略、より多くのエージェント1000でより
高速に処理を行う戦略等があり、また、どのように要求
を割り当てることが最適かを策定する方法に、例えば、
前向き推論、後ろ向き推論という２つの方法があるが、
プラン策定状況に応じてどちらの推論を用いるかという
戦略もある。

【０１０２】実施の形態６．実施の形態６は、各エージ
ェント1000の稼働率を考慮して、１度割り当てられた要
求を割り当て直すことにより、各エージェント1000にか
かる負荷を適切に制御する実施の形態である。図１０
は、実施の形態６に係る自律協調処理装置の機能ブロッ
ク図である。図１０において、図１と同一の符号は同一
又は相当の部分を表す。3000は、各エージェント1000に
割り当てられている処理要求を監視し、各エージェント
1000の処理状況に応じて適宜動的にエージェント1000が
受け持つ処理要求の数量の調整、または、処理の優先順
位に基づく処理プランの修正変更を行なうプラン調整部
であり、 1)エージェント1000が抱えている処理要求の数の平準
化、均衡化 2)処理要求の処理の優先順位の逆転の抑制 を目的として、エージェント1000が抱えている処理要求
の数量の調整と処理要求の優先順位に基づく処理プラン
の修正変更を行なう。

【０１０３】3100は、プラン調整部3000で利用する目的
や対象とする問題領域に応じたプラン調整の仕方を記述
したプラン調整戦略知識を格納したプラン調整戦略格納
部、3200はプランの調整を行なうプラン調整処理部、33
00はエージェント1000の抱えている処理要求の監視を行
なうエージェント監視部、3400はプラン調整処理部320
0、あるいはエージェント監視部3300からのエージェン
ト1000へのメッセージの通知あるいは制御信号の伝達、
または、エージェント1000から送信されてくるメッセー
ジあるいは、制御信号の受信を行ない受信情報に応じた
処理を行ない、プラン調整処理部3200、あるいはエージ
ェント監視部3300へ通知する通信管理部である。

【０１０４】次に動作について説明する。プラン調整部
3000のエージェント監視部3300は、定期的にエージェン
ト1000の協調処理部1100と通信管理部2300を介して交信
してエージェント1000が抱えている処理要求を監視す
る。このときエージェント1000が抱えている処理要求と
は、すなわち、そのエージェント1000と仮想リンクによ
って繋がっている情報処理部1400の抱えている処理要求
でもある。そのとき入手した情報は、内部情報格納部13
00に格納する。エージェント1000が抱えている処理要求
がある閾値を越えたエージェント1000を発見すると、直
ちにエージェント監視部3300は、プラン調整処理部3200
にその旨を通知する。プラン調整処理部3200は、エージ
ェント1000の処理の進捗状況や処理要求の発生頻度など
の諸状況に応じて、プラン調整戦略を作成する。その通
知を受け取ったプラン調整処理部3200は、全てのエージ
ェント1000が抱えている処理要求を調査し、閾値を越え
たエージェント1000に対して抱えている処理要求を２分
割し、一方を指定するエージェント1000へ引き渡すこと
を指示するメッセージを発信する。通知を受けたエージ
ェント1000は、引き受けている処理要求を２分割し、プ
ラン調整部3000が指定するエージェント1000へその一方
の処理要求を引き渡す。

【０１０５】プラン調整処理部3200は、分割する処理要
求の引き受けることのできるエージェント1000の要件を
明確にし、抱えている処理要求の数量の少ないエージェ
ント1000へ優先的に引き受けの指定をする。プラン調整
部3000から引き受けを指示されたエージェント1000は、
引き受け要求のあった処理要求の中から受けとることの
できる処理要求のみを受けとる。プラン調整処理部3200
の引き受けの指定とプラン調整部3000から引き受けを指
示されたエージェント1000の引き受け作業の繰り返しに
より、分割調整作業を終了する。また、以下に示す方式
にてプラン調整できる。定期的にプラン調整部3000は、
情報処理部1400の進捗状況を各エージェント1000に報告
させ、その報告に基づき情報処理部1400が抱えている処
理要求の実施順位である実施ＩＤの最小値が、他の情報
処理部1400が抱えている処理要求の実施ＩＤの最大値よ
りも大きい情報処理部1400を発見すると、直ちにプラン
調整部3000は調整案の策定を、発見された情報処理部14
00を束縛するエージェント1000に指示する。各エージェ
ント1000とプラン調整部3000は、協調して、調整すべき
情報処理部1400を決定し、その情報処理部1400を管理す
るエージェント1000にプラン調整の実行を指示する。こ
の指示は、複数のエージェント1000に対して行われる。
プラン調整の実行を指示されたエージェント1000達は、
自己が管理している情報処理部1400の抱えている処理要
求をチェックし、その処理要求を実行優先順位に基づい
て実施順位の上位のものから互いに取り合うことにより
処理要求の再割り当てを行う。

【０１０６】以上の処理により、要求を多く抱えたエー
ジェント1000の負荷を他のエージェント1000に動的に振
り分けることができるので、全体として高速な要求の処
理が可能となる。

【０１０７】また、プラン調整戦略知識を書き変えるだ
けで、プラン調整のメカニズムを容易に変更できる。す
なわち、プラン調整戦略格納部3100を分離独立させて実
現しているため、プラン調整戦略知識の修正、変更が容
易である。なお、図１１に示すように、このプラン調整
部3000は、各情報処理部1400の処理の進捗状況の監視
と、その進捗状況に基づいてプラン調整すべき情報処理
部1400の選択をするプラン調整処理部3600と、プラン調
整処理部3600の指示に従って、選択されたエージェント
1000と協調してその情報処理部1400が抱える処理要求を
再割り当てして調整するプラン調整エージェント3500と
いう２つの独立した実行可能なモジュールに分けること
もできる。

【０１０８】実施の形態７．実施の形態７は、実施の形
態４に示したプランの策定と実施の形態６に示したプラ
ンの調整とを取り入れることにより、より適切な処理要
求の配分を可能とし、高速な処理を可能とする実施の形
態である。

【０１０９】図１２は、実施の形態７に係る自律協調処
理装置の機能ブロック図である。図１２において、図
１、６又は１０と同一の符号は同一又は相当の部分を表
す。4000は、プラン策定協調処理部4200とプラン調整協
調処理部4100とメタ制御管理部1200からアクセスでき、
三者の共有内部情報を格納する内部共有情報格納部であ
る。4100は、自律した判断をして複数の情報処理部1400
間での協調連携処理を行うため、他のエージェント1000
との協調処理を実行するプラン調整協調処理部である。
このプラン策定協調処理部4200は協調処理をプラン調整
という点に限定したことを除き実施の形態１で示した協
調処理部1100と同様のものである。4200は、自律した判
断をして複数の情報処理部1400間での協調連携処理を行
うため、他のエージェント1000との協調処理を実行する
プラン策定協調処理部である。このプラン策定協調処理
部4200は協調処理をプラン策定という点に限定したこと
を除き実施の形態１で示した協調処理部1100と同様のも
のである。

【０１１０】次に動作について説明する。プラン策定部
2000は、実施の形態４または実施の形態５で示した動作
を行ない、プラン調整部3000は、実施の形態６で示した
動作を行なう。ただし、プラン策定部2000は、図１２に
示すように、各エージェント1000のプラン策定専用のプ
ラン策定協調処理部4200と交信して協調処理を行ない、
プラン調整部3000は、プラン調整専用のプラン調整協調
処理部4100と交信して協調処理を行なう。また、協調処
理部1100をプラン策定専用のプラン策定協調処理部4200
とプラン調整専用のプラン調整協調処理部4100に分離し
て、両機能を１個のエージェント1000に内包させる形態
で実現した。従って、プラン策定のための協調処理部11
00と、プラン調整のためのプラン調整協調処理部4100の
両機能を１個のエージェント1000単位での取り扱いが可
能となり、両者間の協調は、エージェント1000の内部処
理となる。

【０１１１】この自律協調情報処理装置でのサービスの
提供を含む問題解決は、以下のような処理の流れにより
行なわれることになる。処理要求がプラン策定部2000に
入力されると、各エージェント1000の構成要素であるプ
ラン策定協調処理部4200とプラン策定部2000との協調に
より処理プランの策定が行なわれ、各エージェント1000
にこの処理プランに従った新規の処理要求の割り当てが
なされる。そして、あるエージェント1000の処理要求が
予め定められた閾値を越えると、プラン調整部3000は、
各エージェント1000の構成要素であるプラン調整協調処
理部4100とプラン調整部3000との協調により、処理要求
の再割り当てを行い。処理要求の均等化、優先順位に従
った処理を目的としてプランの調整を実行する。

【０１１２】以上のような動作により、第１にプラン策
定部2000による適切な処理要求の割り当てが行われ、第
２に、この割り当てが適切なものでなくなった場合で
も、プラン調整部3000による処理要求の割り当て直しが
行われるため、全体として適切な割り当て状態を保つこ
とができる。従って、高速な処理が可能となる。

【０１１３】また、プラン策定部2000、プラン調整部30
00をそれぞれ、目的別、処理対象のカテゴリごとに分け
て実現することにより、システムのモジュール性を向上
させ、システムの構築を機能別に分けた実現が容易に実
現でき、可読性も向上し、処理速度もかなり改善するこ
とができる。この場合、エージェント1000の構成要素で
ある、プラン策定協調処理部4200とプラン調整協調処理
部4100は、それぞれのプラン策定部2000、プラン調整部
3000に対して、別プロセスとして実現することも可能で
あるし、同一のプロセスにて異なる複数のプラン策定部
2000、ないしプラン調整部3000との協調処理として実現
することも可能である。また、互いに分離独立した異な
る複数の協調処理部1100をエージェント1000の構成要素
として持ち合わせることも可能である。

【０１１４】実施の形態８．実施の形態８は、実施の形
態４とは、異なる構成でプラン策定を行う実施の形態で
ある。図１３は、実施の形態８に係る自律協調処理装置
の機能ブロック図である。図１４において、図６と同一
の符号は同一又は相当の部分を表す。これまでの実施の
形態では、情報処理部1400から見た場合、その情報処理
部1400を代行して同一のプラン策定部2000に対して協調
処理にあたる協調処理部1100は、１個であった。この実
施の形態では、情報処理部1400aを代行して同一のプラ
ン策定部2000に対して協調処理にあたる協調処理部1100
は複数個存在する。従って、同一の問題解決に対して複
数の協調処理部1100からの処理要求を適宜使い分けて情
報処理部1400a内に取り込み処理することになる。ま
た、情報処理部1400aにリンクする協調処理部1100を不
特定として、適宜必要に応じて協調処理部1100とのリン
クを成立させ、協調処理部1100からの処理要求を受けと
り処理することも可能である。

【０１１５】1100aは、プラン策定部2000が策定したプ
ランに基づき、自律した判断をして複数の情報処理部14
00a間での協調連携処理を行うために他のエージェント1
000との協調処理を実行する協調処理部であり、複数の
処理要求を受け付け、これらの処理要求を情報処理部14
00aに実行させるものである。1400aは、１つの処理要求
を受け付け、この処理要求を処理する情報処理部であ
り、処理要求には、１つないし複数のデータベースから
所望する情報の検索、問題の解決、あるいはサービス提
供を受ける等の処理が含まれる。また、この情報処理部
1400aは、過去の検索結果又は処理結果を記憶し、これ
らの検索又は処理の内容を自らを管理する接続制御管理
部5000へ通知する作用がある。この通知は、接続制御管
理部5000、協調処理部1100aを介してプラン策定部2000
へ伝えられる。

【０１１６】5000は、協調処理部1100aから受け取った
処理要求をどの情報処理部1400aへ処理させるかを決定
し、決定した情報処理部1400aとその処理要求を受け付
けた協調処理部1100aとを接続する接続制御管理部であ
る。この接続制御管理部5000の内部構成は、図１４のよ
うになっている。5100は、受け取った処理要求の要求内
容と情報処理部1400aの属性及び負荷状況に基づき、当
該処理要求をどの情報処理部1400aへ引き渡すかを決定
する接続制御部、5200は、この接続制御部5100の指示に
基づき特定の情報処理部1400aと特定の協調処理部1100a
とを接続し、当該情報処理部1400aと協調処理部1100aと
の間で情報伝達を行う情報伝達管理部5200である。

【０１１７】以上のような構成において、次にその動作
について説明する。処理要求が外部プロセス、情報処理
部1400a、あるいは、協調処理部1100aからプラン策定部
2000に入力されると、実施の形態４または、実施の形態
５において説明したように、プラン策定部2000とリンク
している協調処理部1100aとの協調作業により処理要求
の処理プランを策定し、各協調処理部1100aに処理要求
を割り当てる。ただし、各協調処理部1100aは、それぞ
れが特有の属性を持ち（もちろん、同一の属性を持って
いる場合もある）、その属性を考慮してプラン策定が行
われる。この属性の違いにより、例えば、優先順位の高
い処理要求を専門的に受付ける協調処理部1100aや、受
け取ることのできる処理要求件数の上限が大きい協調処
理部1100a、逆に上限が少ない協調処理部1100a等が存在
する。

【０１１８】プラン策定は、実施の形態４に示した条件
の他にこれらの属性を考慮して行われる。このとき、各
情報処理部1400aから通知された条件に合う処理要求は
優先的にその情報処理部1400aに割り当てられるように
プランを作成する。例えば、既に検索済みデータと同一
の検索要求がある場合には、既に検索を行った情報処理
部1400aへ当該検索要求を割り付ける。プラン策定部200
0においては、通常、どの協調処理部1100aへ検索要求を
割り付けるかを決定するのみで、どの情報処理部1400a
に割り付けるかという指定は行わないが、上述の場合に
は、例外的に当該情報処理部1400aを指定する。その理
由は、過去に同一の検索条件で検索を行っている情報処
理部1400aがある場合には、検索結果を保持しているの
で、新たに検索を行わなくても検索結果を得ることがで
き、高速に結果を得ることができるからである。

【０１１９】プランを策定した結果、どの協調処理部11
00aが処理要求を担当するかが決定する。各々の協調処
理部1100aは、リンクしている接続制御管理部5000と交
信してどの接続制御管理部5000に担当させるかを決定す
る。各接続制御管理部5000には、管理している情報処理
部1400aに応じた属性があり、この属性と現在の負荷に
基づき、どの接続制御管理部5000が処理要求を処理する
かを決定する。例えば、ある接続制御管理部5000は、全
文検索の得意な情報処理部1400aを多く管理し、ある接
続制御管理部5000は、特定のデータの構文を熟知してお
り構文のかかるデータの検索が得意な情報処理部1400a
を多く管理している等、情報処理部1400aには、情報処
理部1400aのプログラム等により特性があるため、これ
らを予め考慮して接続制御管理部5000を選択する。

【０１２０】処理要求を処理する接続制御管理部5000が
決定し、当該接続制御管理部5000が処理要求を受け付け
ると、次に、情報処理部1400aへの処理要求の割り付け
が行われる。この割り付けは各情報処理部1400aの属
性、負荷状態を考慮しながら、接続制御管理部5000と情
報処理部1400aとの間の協調処理により決定する。そし
て、最終的に処理要求を処理する情報処理部1400aが決
定し、その情報処理部1400aにて処理要求が実行され
る。

【０１２１】また、この実施の形態８では、各情報処理
部1400aは、１つの処理要求しか受け付けず、複数の処
理要求は協調処理部1100aにスタックされている。各協
調処理部1100aにスタックしている処理要求は接続制御
管理部5000の要求に従って各情報処理部1400aへ割り当
てられる。接続制御管理部5000は、情報処理部1400aか
らの要求があると、協調処理部1100aへ処理要求を受け
取りに行く。このとき、各協調処理部1100aに溜まって
いる処理要求のうちどの処理要求を受け取るかは、処理
要求の優先度に基づいて決定される。この際、引き受け
る情報処理部1400aの属性を考慮しても良い。他の実施
の形態では、１つの情報処理部1400に複数の処理要求が
溜まり、これらの処理要求は受付順で処理されるため、
優先度の低い処理要求が高い処理要求よりも先に処理さ
れてしまうという問題、又は、各処理要求の処理に要す
る時間が異なるため各情報処理部1400a間にスタックし
ている処理要求の数に不均衡が生じるなどの問題があっ
た。そのため、これらの問題を解決することを目的とし
てプラン調整部を設けた実施の形態についても説明し
た。一方、この実施の形態では、各情報処理部1400aで
は１つの処理要求しか受け付けず、処理が終了すると優
先順位に従って全ての協調処理部1100aの中から、次に
実行されるべき処理要求を探しだして実行するためかか
る調整が不要になる。

【０１２２】以上のような、動作を行うことにより、プ
ラン策定部2000により適切なプランが決定され、当該プ
ランに基づいて適切に負荷分散が行われる。従って、高
速に処理要求を実行することができる。

【０１２３】ただし、処理要求は、処理させる情報処理
部1400aを指定することもできるし、不特定とし、接続
制御部5100に委ねることもできる。よって、複数の協調
処理部1100aから同一の情報処理部1400aを指定した処理
要求が複数個同時に接続制御部5100に送信されてくるこ
とがある。接続制御部5100では、リンクしている協調処
理部1100aから処理要求を例えば図１４で示す情報伝達
管理部5200が受信する。情報伝達管理部5200では、受信
した処理要求を分析解読して、まず、処理させる情報処
理部1400aを指定しているものと指定のないものに分
け、さらに指定しているものを指定先ごとに分類する。
受け付けた処理要求の処理の順序は、処理要求につけら
れた優先度に基づいて優先順位を決定し処理される。優
先順位は、処理要求が持つ属性例えば緊急と指定すれば
指定がないものより実行順序の優先度を大きくするな
ど、接続制御部5100の受信時刻順序、などにより決定さ
れる。情報伝達管理部5200は、処理要求の引渡し先が指
定されている処理要求については、指定先の情報処理部
1400aと交信しながら、適宜相手先情報処理部1400aへ処
理要求を送信する。

【０１２４】処理要求の引渡し先が複数個指定されてい
るときは、複数個の情報処理部1400aの中から、引きと
り要求が情報伝達管理部5200に送られてきた情報処理部
1400aに処理要求を引き渡す。処理要求に引き受けの条
件が設定されているときは、情報伝達管理部5200におい
て、処理要求に設定された引渡し条件を満足しているか
どうかを情報処理部1400aとコミュニケーションして判
断し、この判断結果に基づき引渡しの可否を決定する。
また、同時に引渡し可能な情報処理部1400aを複数個存
在するときは、情報伝達管理部5200において競合の解消
が行なわれ、さらに優先順位付けが行われる。そして、
この優先順位に従い情報処理部1400aを決定し、その情
報処理部1400aに処理要求を引き渡す。

【０１２５】処理要求の引渡し先が指定されていない処
理要求は、引き渡し可能な情報処理部1400aの中から処
理要求の優先度、優先順位に従って処理要求に設定され
ている引渡し条件を満足する情報処理部1400aに引き渡
す。同時に複数個存在するときは、競合解消を行ない引
渡し先情報処理部1400aを決定する。例えば、競合解消
時、相手先を指定している処理要求がある場合に、その
相手先として指定されている情報処理部1400aの優先順
位を低くすることにより、相手先を指定していない処理
要求にできるだけじゃまされないようにする。そのこと
により、特定の情報処理部1400aに負荷が集中しないよ
うにするといった競合の解消方法が考えられる。

【０１２６】また、上述したように情報処理部1400aか
ら、引き受ける処理要求の条件を指定することができ
る。この条件を接続制御管理部5000に送ると、その条件
を満足する処理要求の提示がある。その中から適宜引き
受ける処理要求を決定し、その処理要求を受けとる。条
件として、要求の発信元の協調処理部1100aを指定する
こともできる。協調処理部1100aを指定したときに、接
続制御管理部5000とリンクされていない協調処理部1100
aを指定したときには、情報伝達管理部5200は、一旦情
報処理部1400aと交信して、情報処理部1400aがその指定
を止め指定を変更するか、接続制御部5100がその指定さ
れた協調処理部1100aと交渉して、その協調処理部1100a
とリンクを新たに張る。交渉の結果拒否されると、その
協調処理に代わる代替の協調処理部1100aがあるかどう
かをその協調処理部1100aに問い合わせる。

【０１２７】代替の協調処理部1100aがあれば、再度そ
の協調処理部1100aと交渉する。このような作業を繰り
返して相手先となる協調処理部1100aを探し、見つから
なければ、指定を止めるよう情報処理部1400aに指示す
る。見つかれば新たな代替の協調処理部1100aを情報伝
達管理部5200を経由して情報処理部1400aに通知し、指
定をその協調処理部1100aへ変更するよう指示し、その
協調処理部1100aにリンクを貼る。また、協調処理部110
0aが引渡し先として指定した情報処理部1400aが、接続
制御管理部5000とリンクされていない場合、情報伝達管
理部5200は、協調処理部1100aに対して指定の変更がで
きないか問い合わせ、変更ができないときは、接続制御
部5100に依頼し、接続制御部5100と相手先情報処理部14
00aとの交渉が成立すれば指定された情報処理部1400aと
リンクを張り接続する。接続制御部5100による交渉が失
敗し拒否されると、代替の情報処理部1400aがあるかど
うか問い合わせ、存在すれば再度交渉する。このような
作業繰り返して相手先情報処理部1400aを探す。

【０１２８】見つかれば、その情報処理部1400aとリン
クを貼り接続する。みつからなければ、協調処理部1100
aに対して、指定を変更するよう指示する。また、情報
処理部1400aから、引き受けの相手先の指定を取り止め
た場合、接続制御管理部5000とリンクしている情報処理
部1400aがすべて、引き受けの相手先である協調処理部1
100aを指定している場合であって、かつ、取り止めた相
手先である協調処理部1100aを引受の相手先として指定
されていない場合、その協調処理部1100aと接続制御管
理部5000とのリンクを解消することができる。ただし、
解消しないでリンクを存続させることもできる。接続制
御部5100は、このような協調処理部1100aと接続制御管
理部5000間、情報処理部1400aと接続制御管理部5000
間、のリンクの接続の制御を行なう。

【０１２９】実施の形態９．図１５は、実施の形態９に
係る自律協調処理装置の機能ブロック図である。図１５
において、図１３又は１４と同一の符号は同一又は相当
の部分を表す。5300は、協調処理部1100a内の内部状況
を監視する監視部、5400は情報処理部1400aと協調処理
部1100aの実行制御の管理を行なう実行制御管理部、550
0は前記協調処理部1100aが抱えている引き受け処理要求
の数量の調整を含め実行制御管理部5400の実行制御の管
理を行なう情報処理調整部である。ただし、接続制御管
理部5000の構成要素である情報処理調整部5500は、オプ
ショナルに装備することが可能である。

【０１３０】以上のような構成において、次にその動作
について説明する。図１５において示す装置の基本的な
動作は、実施の形態８で示す通りである。従って、この
実施の形態９の特徴的な動作について説明する。この実
施の形態は、実施の形態８で示した接続制御管理部5000
の機能を拡張することにより、すなわち、監視部5300、
実行制御管理部5400、を設けることにより、接続制御管
理部5000とリンクされている協調処理部1100aの稼働状
況と、情報処理部1400aの稼働状況を含めた情報伝達管
理部5200の稼働状況に応じて協調処理部1100a、情報処
理部1400a、情報伝達管理部5200の実行制御の管理を行
なう機能を追加したものである。

【０１３１】さらに、オプションとして、情報処理調整
部5500を設けることにより、協調処理部1100aが抱えて
いる引き受け処理要求の数量、あるいは、処理要求の優
先順位に基づく処理の実行順序の制御、または、協調処
理部1100aにおける処理要求の発信管理ができるように
機能拡張したものである。

【０１３２】監視部5300は、実行制御管理部5400の指示
により、接続制御管理部5000とリンクしているすべての
協調処理部1100aのある特定の内部情報を監視し適宜取
り込み、監視部5300内で保存する。例えば、協調処理部
1100aが引き受けた処理要求などを監視させる。実行制
御管理部5400は、その監視部5300内に保管されてる情報
に基づいて、協調処理部1100、情報伝達管理部5200、情
報処理部1400a、接続制御部5100の実行制御の管理を以
下のように行なう。まず、協調処理部1100に対しては、
発信する処理要求の条件を提示し、その条件を充足する
処理要求を接続制御管理部に対して発信するように指示
したり、協調処理戦略の変更を指示する。指示は、情報
伝達管理部5200を経由して行なう。情報伝達管理部5200
に対しては、協調処理部1100aから送られてくる処理要
求の条件チェック、または、処理要求の受付をする協調
処理部1100aを適宜指定し指定した協調処理部1100aから
の要求のみを受け付けるように指示する。また、受け付
けた処理要求の処理の優先順位の決定と、引き受け先の
情報処理部1400aの決定にあたっての競合解消戦略を協
調処理部1100aの内部状況に応じて指定する。情報処理
部1400aに対しては、処理要求の引き受けにあたって、
処理要求の発信先である協調処理部1100aの指定をトッ
プダウンに指示する。

【０１３３】接続制御部5100に対しては、情報処理部14
00aあるいは、協調処理部1100からの要求で協調処理部1
100aと接続制御管理部5000とのリンクまたは情報処理部
1400aと接続制御管理部5000とのリンク設定変更を行な
う時に、接続制御管理部5000と現在リンクの張られてい
る協調処理部1100aの稼働状況を考慮した判断を実行制
御管理部5400側で行ないその結果を指示する。

【０１３４】次に、情報処理調整部5500の動作を説明す
る。情報処理調整部5500は、監視部5300を通して得られ
る協調処理部1100aの内部情報を基に、協調処理部1100a
が抱えている処理要求の数を監視して、その数が予め定
められた値を越えた場合には、その協調処理部1100aが
抱えている処理要求を分割して、分割分は、他の協調処
理部1100aに引き受けさせる。引き受けさせる協調処理
部1100aの選択は、分割した処理要求の引渡し条件と、
協調処理部1100aでの受け入れ条件を比較し、できるだ
け抱えている処理要求が少ない協調処理部1100aを選択
する。また、協調処理部1100aの稼働状況に応じて、実
行制御管理部5400に対して、適宜動的に判断行動基準の
変更や制御パラメータの変更などを指示するなどして実
行制御管理部5400の実行制御の管理を行なう。

【０１３５】実施の形態１０．図１６は、実施の形態１
０に係る自律協調処理装置の機能ブロック図である。図
１６において、図１と同一の符号は同一又は相当の部分
を表す。6000は情報処理部1400とエージェント1000の稼
働数量を増減することにより自律協調処理装置の処理速
度の調節を行なうチューニング部である。このチューニ
ング部6000の詳細な構成を図１７に示す。6300は、エー
ジェント1000や情報処理部1400を含めた処理要求の処理
時間を計測するプロセス監視部、6200は、その計測した
時間を集計し統計学的処理、例えば、移動平均をとるな
どの処理を施して、システムの性能評価値を算定する評
価部、6100は、評価部6200の評価に従って、エージェン
ト1000又は、情報処理部1400の数を増減させる構成部品
生成削除部である。

【０１３６】次に動作について説明する。チューニング
部6000のプロセス監視部6300は、エージェント1000のメ
タ制御管理部1200と交信して、メタ制御管理部1200が管
理している情報処理部1400に対して処理を依頼しその結
果が返ってくるまでの時間、あるいは、エージェント10
00の内部情報格納部に格納されている情報を返してくる
時間、などのターンアラウンド値を計測する。そして、
評価部6200において、計測値を例えば、移動平均をとる
などして、統計学的算術処理を施して、計測評価値を算
定する。その算定された計測評価値をベースにして、評
価部6200内に登録されている閾値と比較して、評価部62
00に登録されている判断規則のなかから、もっともふさ
わしい判断規則を選択して、その判断規則にもとづいて
評価を行ない、エージェント1000あるいは、情報処理部
1400を増やすか削減するかを数量とともに決定する。

【０１３７】次いで、その評価部6200が出した評価に従
って、構成部品生成削除部6100において、エージェント
1000あるいは、情報処理部を新たに生成あるいは、削除
を行なう。以下の処理は、構成部品生成削除部6100にお
いて行なわれる。削除する場合、削除する情報処理部14
00あるいはエージェント1000の選定作業に入る。複数の
情報処理部1400において実現されている機能がそれぞれ
すべて異なる場合は、情報処理部1400は削除できない。
しかしながら、同じ機能を実現した情報処理部1400が複
数個存在するときは、その内のいくつかを消去すること
が可能である。情報処理部1400を削除するときは、その
削除対象の情報処理部1400の作業が終了するのを待って
削除する。

【０１３８】エージェント1000を削除するときは、削除
対象エージェント1000内の協調処理部1100aをロック
し、他エージェント1000あるいは、他プロセスとの交信
を断ち、削除対象エージェント1000内のメタ制御管理部
1200もロックし、情報処理部1400との交信を断つ。ただ
し、現在このエージェント1000の指示に従い作業を行な
っている情報処理部1400が存在しているときは、その処
理が終り処理結果の通知を受け取るまで、その情報処理
部1400との通信のみができる状態となる。結果を受け取
り次第、削除対象エージェント1000内の内部情報格納部
1300に格納されている情報を調査し、他のエージェント
に引き次ぐ必要のある情報が存在するときは、他のエー
ジェント1000に引き継ぎを依頼する。引き継ぎが完了す
ると、その削除対象のエージェント1000を削除する。し
かしながら、引き継ぎができていない場合は、本エージ
ェント1000を削除することはできない。このような場合
は、このエージェント1000が抱えている処理要求をすべ
て、処理してしまうまで、待ちその後削除する。

【０１３９】エージェント1000あるいは、情報処理部14
00を増やすときは、構成部品生成削除部6100内に登録さ
れている各種部品の中から必要な部品を選択して組み合
わせて目的とするエージェント1000あるいは、情報処理
部1400を作成する。エージェント1000に装備する協調戦
略やプロセス管理のためのノウハウは、ディフォルトで
用意されている標準品を組み込む。作成後、稼働してい
るエージェント1000あるいは、情報処理部1400と連携し
て目的に合うようにカスタマイズあるいは、チューニン
グする。また、図４に示すメタ制御管理部1200Aに上記
チューニング部6000をリンクさせて、そのチューニング
部6000と、一個のメタ制御管理部1200Aとの協調により
稼働エージェント1000の数量をチューニングすることも
可能である。このことにより、チューニング部6000とメ
タ制御管理部1200Aで行う通信の処理回数を低減するこ
とができる。

【０１４０】実施の形態１１．図１８は、この実施の形
態１１の自律協調処理装置の機能ブロック図である。図
１８において、図６又は図１０と同一の符号は同一又は
相当の部分を表す。6000は、実施の形態１０で説明した
チューニング部と同様のものであり、プラン調整部3000
から各処理要求の処理時間取得するとともに、この処理
時間を監視し、この監視結果に基づいてエージェント10
00又は情報処理部1400の数の増減を行う。従って、基本
的な動作は実施の形態１０と同様のものである。

【０１４１】実施の形態１２．図１９は、この実施の形
態１２の自律協調処理装置の機能ブロック図である。図
１９において、図１２と同一の符号は同一又は相当の部
分を表す。6000は、実施の形態１０で説明したチューニ
ング部と同様のものであり、プラン調整部3000から各処
理要求の処理時間取得するとともに、この処理時間を監
視し、この監視結果に基づいてエージェント1000又は情
報処理部1400の数の増減を行う。従って、チューニング
部6000の基本的な動作は実施の形態１０と同様のもので
ある。

【０１４２】実施の形態１３．図２０は、この実施の形
態１３の自律協調処理装置の機能ブロック図である。図
２０において、図１３と同一の符号は同一又は相当の部
分を表す。6000は、実施の形態１０で説明したチューニ
ング部と同様のものであり、接続制御管理部5000から各
処理要求の処理時間取得するとともに、この処理時間を
監視し、この監視結果に基づいて協調処理部1100a又は
情報処理部1400の数の増減を行う。従って、チューニン
グ部6000の基本的な動作は実施の形態１０と同様のもの
である。

【０１４３】実施の形態１４．図２１は、この実施の形
態１３の自律協調処理装置の機能ブロック図である。図
２１において、図１５と同一の符号は同一又は相当の部
分を表す。6000は、実施の形態１０で説明したチューニ
ング部と同様のものであり、情報処理調整部5500から各
処理要求の処理時間取得するとともに、この処理時間を
監視し、この監視結果に基づいて協調処理部1100a又は
情報処理部1400の数の増減を行う。従って、チューニン
グ部6000の基本的な動作は実施の形態１０と同様のもの
である。

【０１４４】実施の形態１５．図２２は、実施の形態１
５に係る自律協調処理装置の機能ブロック図である。図
２２において、7400は実施の形態１〜１４のいずれかに
示した自律協調情報処理装置である。7000は処理要求に
制御パラメータを付加し、処理の優先順位を適宜動的に
制御パラメータに応じて設定し、処理の実行順序を制御
する優先順位設定管理部、7100は受け付けた処理要求の
処理状況のいかんにかかわらず、新たな複数の処理要求
の受け付けを行なう受付管理、及び処理プランの登録保
管または処理要求者への処理結果の部分分散転送管理を
行なう処理要求管理部、7200は処理要求管理部7100から
の指示に応じて処理要求者への処理結果の部分分散転送
を行なう処理結果提供部、7300は処理結果の登録保管、
問い合わせ処理、処理要求に適合する処理結果への統合
処理を行なう処理結果統合管理部である。

【０１４５】7500はネットワーク上に分散配置された情
報資源を格納する複数のリソースベース、7600は、ネッ
トワークに接続された各利用者が処理要求を発信した
り、処理結果を受信する操作環境であるクライントであ
る。情報資源とは、マルチメディアデータあるいは、ア
プリケーションシステムを指す。

【０１４６】以上のような構成において、次にその動作
について説明する。まず、クライアント7600から処理要
求を処理要求管理部7100に対して発信する。このとき、
同一のクライアント7600から複数の処理要求を断続的に
発信することができる。また、別クライアント7600から
も同時に処理要求を発信することができる。しかも、発
信した処理要求の処理が終了せずとも新たな処理要求を
発信することができる。処理要求管理部7100において、
クライアント7600からの処理要求を受け付けると、その
受信した処理要求の処理手順なる処理スケジュールの作
成を行なう。受け付けた処理要求を本装置において処理
可能な複数の処理要求に分割する。処理要求には、処理
の順番が決まっているものや他の処理要求とは独立した
ものがあり、同じ処理要求が既に処理されていてもその
結果を利用できないもの、すなわち、同じ処理をやり直
すことが必要な処理要求がある。従って、過去において
処理された結果を再利用することができる処理要求と改
めて処理を行なう必要のあるもの、処理の順序を考慮す
るもの考慮しなくてもよいもの、に分けて処理要求の処
理プランを作成する。

【０１４７】ただし、自律協調情報処理装置7400自身が
上記の処理スケジュールの作成、すなわち、処理プラン
の作成を行う場合には処理要求管理部7100での処理スケ
ジュールの作成は行わず、受け付けた処理要求そのもの
を自律協調情報処理装置7400に引き渡す。例えば、実施
の形態４，５，７，８，９等のプラン策定部2000を備え
た自律協調情報処理装置7400である。

【０１４８】ついで、各処理要求が既に処理済みか、処
理中か、未処理であるかをチェックする。図示しない処
理要求データベースに登録されていれば、自律協調情報
処理装置7400内で処理中である。処理済みであるか未処
理であるかのチェックは、処理結果統合管理部7300に問
い合わせて確認する。以上の作業で処理要求が処理済み
か、処理中か、未処理であるかが確定する。処理中であ
って、処理結果の再利用ができる場合は、処理結果が返
ってくるのを待つ。処理済みであって、処理結果の再利
用ができる場合は、その処理結果を再利用する。処理済
みであると判明し利用者がその処理結果が返送されるの
を待っているものである場合は、直ちにクライアントに
転送する。

【０１４９】それら以外の処理要求は、自律協調処理装
置7400に処理を依頼する。自律協調処理装置7400に処理
を依頼した処理要求は、図示しない処理要求データベー
スに登録する。依頼する処理要求は、優先順位設定管理
部7000において、処理の優先順位あるいは、優先度を割
り当て、処理の従属関係、順序関係、他人の行なった処
理が再利用できるかできないかの区分も属性情報とし
て、処理要求に持たせる。分割した処理要求をさらに他
の処理要求の分割処理要求と統合して、属性情報、優先
度、優先順位、処理の従属関係、順序関係、他人の行な
った処理が再利用できるかできないかの区分を考慮して
自律協調処理装置7400において処理する。処理結果統合
管理部7300において、ばらばらに分割された処理要求の
実施結果を部分的に統合する。例えば、検索条件が複数
のキーワードからなる場合、その検索条件は処理要求管
理部7100によりキーワード毎に別々の処理要求に分解さ
れる。この処理結果統合管理部7300ではこの分解された
処理要求の検索結果を元の処理要求に従って統合する。
すなわち、処理条件が２つのキーワードの論理積であっ
た場合には、これらのキーワードの処理結果同士の論理
積をとり、１つの解を得る。一方、それらのキーワード
の論理和である場合には、それらの処理結果同士の論理
和をとり、１つの解を得る。

【０１５０】そして、最終的に統合された処理結果を処
理結果提供部7200に送り、要求者へ処理結果を転送した
り、処理要求を充足するサービスを提供する。以上のよ
うに処理が高速な実施の形態１〜１４の自律協調情報処
理装置7400を用いることにより、各クライアントは迅速
に処理結果を得ることができる。

【０１５１】

【発明の効果】この発明は、以上に説明したように構成
されているので、以下に記載されるような効果を奏す
る。

【０１５２】外部からの処理要求を受け付けるか否かを
判断し、受け付けた上記処理要求の処理先を指定して出
力するエージェント部と、このエージェント部から指示
された処理要求を処理する複数の情報処理部とを備えた
自律協調情報処理装置において、上記情報処理部は、複
数の上記処理要求を受け付け、これらの処理要求の処理
状況に応じて処理要求の再割り当てを上記エージェント
部に要求するとともに、再割り当てされた処理要求を実
行し、上記エージェント部は、上記情報処理部からの上
記再割り当て要求を受け付けたとき、その再割り当て要
求を送信した情報処理部の管理する処理要求を他の上記
情報処理部へ移動させ、又は、他の情報処理部の管理す
る処理要求をその再割り当て要求を送信した情報処理部
へ移動させるため、一度割り付けられた処理要求であっ
ても、各情報処理部の処理状況に応じて、処理効率が高
くなるように割り付け直されるため、各情報処理部の稼
働率を適切にコントロールでき、高速な処理が可能とな
る。

【０１５３】また、上記情報処理部は、複数の上記処理
要求を受け付け、これらの処理要求のうち未処理の処理
要求が無くなり又は予め定められた件数よりも少なくな
った場合には、再割り当て要求を送信するとともに、上
記エージェント部により再割り当てされた処理要求を実
行し、上記エージェント部は、上記情報処理部からの上
記再割り当て要求を受け付けると、他の情報処理部の管
理する処理要求をその再割り当て要求を送信した情報処
理部へ移動させるため、再割り当てによって、各情報処
理部の稼働率を適切にコントロールできるため、高速な
処理が可能となる。

【０１５４】また、複数の上記エージェント部を備え、
上記複数の情報処理部はそれぞれ複数の上記エージェン
ト部からの処理要求を受け付けるとともに、上記エージ
ェント部は、自己の管理する処理要求の件数又は優先度
から新たな処理要求を受け付けられるか否かを判定し、
この判定結果を通信する協調処理部と、上記協調処理部
が処理要求を受け取ったときに、自己の管理する上記情
報処理部の処理状況又は属性を考慮して、複数の上記情
報処理部から当該処理要求を処理する上記情報処理部を
選択し、この選択した情報処理部へ当該処理要求を割り
当てる情報処理管理部と、を備え、この情報処理管理部
を他のエージェント部と共有することにより、上記情報
処理部は複数のエージェント部への通信を上記情報処理
管理部を介して行うものである。再割り当てによって、
各情報処理部の稼働率を適切にコントロールできるた
め、高速な処理が可能となる。また、情報処理部から複
数のエージェント部への通信が容易となる。

【０１５５】また、上記エージェント部ごとに操作でき
る記憶領域を指示するアクセス権制御部と、複数の上記
エージェント部からの情報を格納し、上記アクセス権制
御部の指示に基づいて、上記エージェント部から操作で
きる記憶領域を制限する内部情報格納部と、を備えたた
め、各エージェントごとに操作できる記憶領域が狭めら
れるため、必要な情報の検索を高速に行うことができ
る。

【０１５６】また、複数の上記エージェント部を備え、
外部から処理要求を受け付け、複数の上記エージェント
部へ当該処理要求の引き取りが可能であるか否かを問い
合わせ、これらのエージェント部からの返答に基づき当
該処理要求を引き取るエージェント部を決定するプラン
策定部を備えたため、各エージェント部が処理要求を引
き取り可能であるか否かの情報の管理と、どのエージェ
ント部に処理要求を割り付けるかの判断を集中的に行う
ため、各エージェント部間の協調処理が大幅に削減され
る。そのため、各エージェント部の処理負担が軽くな
り、また、各エージェント部で同じ処理を実行するとい
う重複がなくなるため、高速に処理を行うことができ
る。

【０１５７】また、上記プラン策定部は、上記処理要求
をどのエージェント部へ割り付けるかを決定する規則で
ある戦略を複数記憶する戦略格納部と、外部から指示さ
れた上記戦略と上記返答に基づき受け付けた処理要求を
引き渡す上記エージェント部を選択するプラン生成部
と、受け付けた上記処理要求又は上記プラン生成部の処
理状況に基づいて、上記複数の戦略から１つの戦略を選
択し上記プラン生成部へ指示する戦略指示部と、上記プ
ラン生成部により選択されたエージェント部に上記受け
付けた処理要求を通知する通信管理部と、を備えたた
め、処理要求の内容又はプラン生成部の処理状況に応じ
て、戦略を変えることができるため、複雑な戦略のため
にプランの生成に時間がかかる等の場合には、簡単な戦
略を選択し、プラン生成部での処理時間を軽減する。ま
た、処理要求の内容によっては複雑な戦略によって綿密
に割り付け先を決定し、最適な割付パターンを生成した
方が全体としての処理が高速となる場合等がある。ま
た、処理内容によって適した戦略、適さない戦略が存在
する場合もあり、これらの状況をふまえて適切な戦略を
用いることにより、全体として高速な処理を行うことが
できる。

【０１５８】また、複数の上記エージェント部と、これ
らのエージェント部のそれぞれに管理された複数の情報
処理部とを備えた自律協調情報処理装置において、上記
情報処理部が管理する上記処理要求の処理状態に基づ
き、１つの上記エージェント部に管理された情報処理部
が保有する処理要求を、他の上記エージェント部が管理
する他の上記情報処理部へ移動するプラン調整部を備え
たため、異なるエージェント部間においても、再割付が
可能となり、各情報処理部の稼働率が適切にコントロー
ルでき、高速な処理が可能となる。

【０１５９】また、上記プラン調整部は、上記情報処理
部が保有する処理要求の未処理件数を監視し、未処理件
数の多い上記情報処理部から未処理件数の少ない情報処
理部へ上記処理要求を移すため、異なるエージェント部
間においても、再割付が可能となり、各情報処理部の稼
働率が適切にコントロールでき、高速な処理が可能とな
る。

【０１６０】また、上記プラン調整部は、上記情報処理
部が保有する処理要求それぞれの優先度を監視し、上記
処理要求を上記優先度の高い処理要求を多く保有する情
報処理部から、上記優先度の高い処理要求の保有件数が
少ない情報処理部へ移すため、異なるエージェント部間
においても、再割付が可能となり、優先順位の高い処理
要求が先に処理されるため、優先順位に従った高速な処
理が可能となる。

【０１６１】また、上記処理要求の処理に要する時間に
基づき、上記エージェント部又は上記情報処理部の数を
増減させるチューニング部を備えたため、情報処理部又
はエージェント部の数を増減できることにより、処理時
間と消費メモリのバランスを調整することができ、少な
い資源で高速な処理を行うことができる。

【０１６２】また、外部からの処理要求を受け付けるか
否かを判断し、受け付けた上記処理要求の処理先を指定
して出力するエージェント部と、このエージェント部か
ら指示された処理要求を処理する複数の情報処理部とを
備えた自律協調情報処理装置において、上記情報処理部
は、過去に処理した処理要求の処理結果を記憶し、この
記憶した処理結果にかかる処理要求を優先処理要求とし
て上記エージェント部に通知し、上記エージェント部
は、新たに処理要求を受け付けた場合には、複数の上記
情報処理部から一部の情報処理部を選択し、選択した情
報処理部に当該処理要求を割り当てるとともに、上記優
先処理要求を記憶し、新たに受け付けた処理要求が上記
優先処理要求と同一であった場合又は上記処理結果を利
用することができる場合には、当該処理要求を上記優先
処理要求を送信してきた上記情報処理装置に割り当てる
ため、既に処理した処理結果を使用することができるた
め、高速に解を得ることができ、全体として高速な処理
が可能となる。

【０１６３】また、複数の上記エージェント部を備えた
自律協調処理装置において、上記エージェント部は、複
数の上記処理要求を保有し、複数の上記情報処理部に複
数の上記処理要求をそれぞれ配分し、上記エージェント
部の上記処理要求件数を監視し、上記処理要求の保有件
数の多い上記エージェント部から上記処理要求の保有件
数の少ない上記エージェント部へ、上記処理要求を移す
処理要求再割当部を備えたため、各エージェント部が保
有する処理要求の数を制御することができる。

【０１６４】また、外部からの処理要求を受け付けるか
否かを判断し、受け付けた上記処理要求の処理先を指定
して出力するエージェント部と、このエージェント部か
ら指示された処理要求を処理する情報処理部とを備えた
自律協調情報処理装置において、上記エージェント部を
複数備え、上記情報処理部は、複数の上記処理要求を受
け付け、これらの処理要求の処理状況に応じて処理要求
の再割り当てを、自己を管理する上記エージェント部に
要求するとともに、再割り当てされた処理要求を実行
し、上記エージェント部は、上記情報処理部からの上記
再割り当て要求を受け付けたとき、その再割り当て要求
を送信した情報処理部の管理する処理要求を他のエージ
ェント部の情報処理部へ移動させ、又は、他エージェン
ト部の情報処理部の管理する処理要求をその再割り当て
要求を送信した情報処理部へ移動させるため、一度割り
付けられた処理要求であっても、各情報処理部の処理状
況に応じて、処理効率が高くなるように割り付け直され
るため、各情報処理部の稼働率を適切にコントロールで
き、高速な処理が可能となる。

【０１６５】また、複数の処理要求を複数のプロセスに
割り付けて実行させる自律協調分散処理方法において、
新たに受け付けた処理要求を受け付けられるか否かの情
報を上記プロセスから収集する第１のステップと、上記
情報に基づき受け付ける上記プロセスを選択し、この選
択されたプロセスに上記処理要求を割り付けるとともに
処理させる第２のステップと、上記第２のステップで割
り付けられた処理要求の処理が終了したプロセスのう
ち、上記第２のステップで割り付けられなかった上記処
理要求を受け付られる上記プロセスを探し出し、この探
し出されたプロセスに当該処理要求を割り付けるととも
に処理させる第３のステップと、上記第３のステップ終
了後に実行され、多くの処理要求を保有する上記プロセ
スから上記処理要求の保有数が少ないプロセスに上記処
理要求を移して処理させる第４のステップと、を備えた
ため、第３のステップＳでは、第２のステップで割り当
てることのできなかった処理要求が、処理要求を全てや
り終えて処理すべき処理要求を持ち合わせていない情報
処理部に割り当てられ、第４のステップでは、一度割り
付けられた未処理の処理要求が、他の情報処理部に割り
付けられ早期に処理が開始されるため、全体として高速
に処理結果が得られるような処理が可能となる。

【０１６６】

【図面の簡単な説明】

【図１】 この発明の実施の形態１における自律協調情
報処理装置の構成を説明する機能ブロック図である。

【図２】 この発明の実施の形態１における協調処理部
の構成を説明する機能ブロック図である。

【図３】 この発明の実施の形態１におけるメタ制御管
理部の構成を説明する機能ブロック図である。

【図４】 この発明の実施の形態２における自律協調情
報処理部の構成を説明する機能ブロック図である。

【図５】 この発明の実施の形態３における自律協調情
報処理装置の構成を説明する機能ブロック図である。

【図６】 この発明の実施の形態４における自律協調情
報処理装置の構成を説明する機能ブロック図である。

【図７】 この発明の実施の形態４におけるプラン策定
部の構成を説明する機能ブロック図である。

【図８】 この発明の実施の形態４におけるプラン策定
処理を説明するフローチャートである。

【図９】 この発明の実施の形態５における自律協調情
報処理装置の構成を説明する機能ブロック図である。

【図１０】 この発明の実施の形態６における自律協調
情報処理装置の構成を説明する機能ブロック図である。

【図１１】 この発明の実施の形態６におけるプラン調
整部の構成を説明する機能ブロック図である。

【図１２】 この発明の実施の形態７における自律協調
情報処理装置の構成を説明する機能ブロック図である。

【図１３】 この発明の実施の形態８における自律協調
情報処理装置の構成を説明する機能ブロック図である。

【図１４】 この発明の実施の形態８における接続管理
部の構成を説明する機能ブロック図である。

【図１５】 この発明の実施の形態９における自律協調
情報処理装置の構成を説明する機能ブロック図である。

【図１６】 この発明の実施の形態１０における自律協
調情報処理装置の構成を説明する機能ブロック図であ
る。

【図１７】 この発明の実施の形態１０におけるチュー
ニング部の構成を説明する機能ブロック図である。

【図１８】 この発明の実施の形態１１における自律協
調情報処理装置の構成を説明する機能ブロック図であ
る。

【図１９】 この発明の実施の形態１２における自律協
調情報処理装置の構成を説明する機能ブロック図であ
る。

【図２０】 この発明の実施の形態１３における自律協
調情報処理装置の構成を説明する機能ブロック図であ
る。

【図２１】 この発明の実施の形態１４における自律協
調情報処理装置の構成を説明する機能ブロック図であ
る。

【図２２】 この発明の実施の形態１５における自律協
調情報処理装置の構成を説明する機能ブロック図であ
る。

【図２３】 従来のマルチエージェント協調システムの
プランニングエージェントの内部構成を示す機能ブロッ
ク図である。

【図２４】 従来のマルチエージェント協調システムの
要素機能エージェントの内部構成を説明するブロック構
成図である。

【図２５】 従来のマルチエージェント協調システムの
フィールドマネージャの内部構成を説明するブロック構
成図である。

【図２６】 従来のデータベース検索の処理方式の内部
構成を説明する機能ブロック構成図である。

【図２７】 従来の負荷分散支援装置を説明する機能ブ
ロック構成図である。

【符号の説明】

1000 エージェント、 1100 協調処理部、 1200 メ
タ制御管理部、 1300内部情報格納部、 1400 情報処
理部、 1500 アクセス権制御部、 2000プラン策定
部、 2600 戦略指示部、 2700 戦略格納部、 3000
プラン調整部、 5000 接続制御管理部、 6000 チ
ューニング部

Claims (14)

【特許請求の範囲】
1. 【請求項１】 外部からの処理要求を受け付けるか否か
   を判断し、受け付けた上記処理要求の処理先を指定して
   出力するエージェント部と、このエージェント部から指
   示された処理要求を処理する複数の情報処理部とを備え
   た自律協調情報処理装置において、 上記情報処理部は、複数の上記処理要求を受け付け、こ
   れらの処理要求の処理状況に応じて処理要求の再割り当
   てを上記エージェント部に要求するとともに、再割り当
   てされた処理要求を実行し、 上記エージェント部は、上記情報処理部からの上記再割
   り当て要求を受け付けたとき、その再割り当て要求を送
   信した情報処理部の管理する処理要求を他の上記情報処
   理部へ移動させ、又は、他の情報処理部の管理する処理
   要求をその再割り当て要求を送信した情報処理部へ移動
   させることを特徴とする自律協調情報処理装置。
2. 【請求項２】 上記情報処理部は、複数の上記処理要求
   を受け付け、これらの処理要求のうち未処理の処理要求
   が無くなり又は予め定められた件数よりも少なくなった
   場合には、再割り当て要求を送信するとともに、上記エ
   ージェント部により再割り当てされた処理要求を実行
   し、 上記エージェント部は、上記情報処理部からの上記再割
   り当て要求を受け付けると、他の情報処理部の管理する
   処理要求をその再割り当て要求を送信した情報処理部へ
   移動させることを特徴とする請求項１に記載の自律協調
   情報処理装置。
3. 【請求項３】 複数の上記エージェント部を備え、 上記複数の情報処理部はそれぞれ複数の上記エージェン
   ト部からの処理要求を受け付けるとともに、 上記エージェント部は、 自己の管理する処理要求の件数又は優先度から新たな処
   理要求を受け付けられるか否かを判定し、この判定結果
   を通信する協調処理部と、 上記協調処理部が処理要求を受け取ったときに、自己の
   管理する上記情報処理部の処理状況又は属性を考慮し
   て、複数の上記情報処理部から当該処理要求を処理する
   上記情報処理部を選択し、この選択した情報処理部へ当
   該処理要求を割り当てる情報処理管理部と、を備え、 この情報処理管理部を他のエージェント部と共有するこ
   とにより、上記情報処理部は複数のエージェント部への
   通信を上記情報処理管理部を介して行うことを特徴とす
   る請求項１又は２に記載の自律協調情報処理装置。
4. 【請求項４】 上記エージェント部ごとに操作できる記
   憶領域を指示するアクセス権制御部と複数の上記エージ
   ェント部からの情報を格納し、上記アクセス権制御部の
   指示に基づいて、上記エージェント部から操作できる記
   憶領域を制限する内部情報格納部と、を備えることを特
   徴とする請求項３に記載の自律協調情報処理装置。
5. 【請求項５】 複数の上記エージェント部を備え、 外部から処理要求を受け付け、複数の上記エージェント
   部へ当該処理要求の引き取りが可能であるか否かを問い
   合わせ、これらのエージェント部からの返答に基づき当
   該処理要求を引き取るエージェント部を決定するプラン
   策定部を備えることを特徴とする請求項１又は２に記載
   の自律協調情報処理装置。
6. 【請求項６】 上記プラン策定部は、 上記処理要求をどのエージェント部へ割り付けるかを決
   定する規則である戦略を複数記憶する戦略格納部と、 外部から指示された上記戦略と上記返答に基づき受け付
   けた処理要求を引き渡す上記エージェント部を選択する
   プラン生成部と、 受け付けた上記処理要求又は上記プラン生成部の処理状
   況に基づいて、上記複数の戦略から１つの戦略を選択し
   上記プラン生成部へ指示する戦略指示部と、 上記プラン生成部により選択されたエージェント部に上
   記受け付けた処理要求を通知する通信管理部と、を備え
   ることを特徴とする請求項５に記載の自律協調情報処理
   装置。
7. 【請求項７】 複数の上記エージェント部と、これらの
   エージェント部のそれぞれに管理された複数の情報処理
   部とを備えた自律協調情報処理装置において、 上記情報処理部が管理する上記処理要求の処理状態に基
   づき、１つの上記エージェント部に管理された情報処理
   部が保有する処理要求を、他の上記エージェント部が管
   理する他の上記情報処理部へ移動するプラン調整部を備
   えた請求項１〜６のいずれかに記載の自律協調情報処理
   装置。
8. 【請求項８】 上記プラン調整部は、上記情報処理部が
   保有する処理要求の未処理件数を監視し、未処理件数の
   多い上記情報処理部から未処理件数の少ない情報処理部
   へ上記処理要求を移すことを特徴とする請求項７に記載
   の自律協調情報処理装置。
9. 【請求項９】 上記プラン調整部は、上記情報処理部が
   保有する処理要求それぞれの優先度を監視し、上記処理
   要求を上記優先度の高い処理要求を多く保有する情報処
   理部から、上記優先度の高い処理要求の保有件数が少な
   い情報処理部へ移すことを特徴とする請求項７に記載の
   自律協調情報処理装置。
10. 【請求項１０】 上記処理要求の処理に要する時間に基
    づき、上記エージェント部又は上記情報処理部の数を増
    減させるチューニング部を備えた請求項１〜９に記載の
    自律協調情報処理装置。
11. 【請求項１１】 外部からの処理要求を受け付けるか否
    かを判断し、受け付けた上記処理要求の処理先を指定し
    て出力するエージェント部と、このエージェント部から
    指示された処理要求を処理する複数の情報処理部とを備
    えた自律協調情報処理装置において、 上記情報処理部は、過去に処理した処理要求の処理結果
    を記憶し、この記憶した処理結果にかかる処理要求を優
    先処理要求として上記エージェント部に通知し、 上記エージェント部は、新たに処理要求を受け付けた場
    合には、複数の上記情報処理部から一部の情報処理部を
    選択し、選択した情報処理部に当該処理要求を割り当て
    るとともに、上記優先処理要求を記憶し、新たに受け付
    けた処理要求が上記優先処理要求と同一であった場合又
    は上記処理結果を利用することができる場合には、当該
    処理要求を上記優先処理要求を送信してきた上記情報処
    理装置に割り当てることを特徴とする自律協調情報処理
    装置。
12. 【請求項１２】 複数の上記エージェント部を備えた自
    律協調処理装置において、 上記エージェント部は、複数の上記処理要求を保有し、
    複数の上記情報処理部に複数の上記処理要求をそれぞれ
    配分し、 上記エージェント部の上記処理要求件数を監視し、上記
    処理要求の保有件数の多い上記エージェント部から上記
    処理要求の保有件数の少ない上記エージェント部へ、上
    記処理要求を移す処理要求再割当部を備えたことを特徴
    とする請求項１１に記載の自律協調情報処理装置。
13. 【請求項１３】 外部からの処理要求を受け付けるか否
    かを判断し、受け付けた上記処理要求の処理先を指定し
    て出力するエージェント部と、このエージェント部から
    指示された処理要求を処理する情報処理部とを備えた自
    律協調情報処理装置において、 上記エージェント部を複数備え、 上記情報処理部は、複数の上記処理要求を受け付け、こ
    れらの処理要求の処理状況に応じて処理要求の再割り当
    てを自己を管理する上記エージェント部に要求するとと
    もに、再割り当てされた処理要求を実行し、 上記エージェント部は、上記情報処理部からの上記再割
    り当て要求を受け付けたとき、その再割り当て要求を送
    信した情報処理部が保有する処理要求を他のエージェン
    ト部が管理する情報処理部へ移動させ、又は、他のエー
    ジェント部が管理する情報処理部が保有する処理要求
    を、その再割り当て要求を送信した情報処理部へ移動さ
    せることを特徴とする自律協調情報処理装置。
14. 【請求項１４】 複数の処理要求を複数のプロセスに割
    り付けて実行させる自律協調分散処理方法において、 新たに受け付けた処理要求を受け付けられるか否かの情
    報を上記プロセスから収集する第１のステップと、 上記情報に基づき受け付ける上記プロセスを選択し、こ
    の選択されたプロセスに上記処理要求を割り付けるとと
    もに処理させる第２のステップと、 上記第２のステップで割り付けられた処理要求の処理が
    終了したプロセスのうち、上記第２のステップで割り付
    けられなかった上記処理要求を受け付られる上記プロセ
    スを探し出し、この探し出されたプロセスに当該処理要
    求を割り付けるとともに処理させる第３のステップと、 上記第３のステップ終了後に実行され、多くの処理要求
    を保有する上記プロセスから上記処理要求の保有数が少
    ないプロセスに上記処理要求を移して処理させる第４の
    ステップと、を備えた自律協調分散処理方法。