(57)【特許請求の範囲】
【請求項１】
情報処理システムの利用者になり代わって業務を行うために，ネットワーク内の複数の処理装置を渡り歩き，自律的に振る舞うことができるエージェントと，ネットワーク内の各処理装置において前記エージェントの実行制御および状態管理を行うエンジンとからなる情報処理システムにおいて，
前記エンジンからエージェントの状態管理情報の通知を受けるエージェント状態取得手段と，
取得したエージェントの状態管理情報に基づき，ある死滅したエージェントが生成した子エージェントが同一エンジンに駐留する場合に，当該子エージェントの死滅または処理依頼の取消しを決定し，前記エンジンにその指示を行うローカルエージェント処理取消し依頼手段と，
取得したエージェントの状態管理情報に基づき，ある死滅したエージェントが生成した子エージェントが他のリモートの処理装置に駐留する場合に，当該子エージェントの死滅または処理依頼の取消しを決定し，他のリモートの処理装置にその指示を行うリモートエージェント処理取消し依頼手段とを有する
特権処理手段を備え，
前記エンジンは，
親エージェントから子エージェントへの処理依頼形態を含むエージェントの状態管理情報を管理するエージェント状態管理手段と，
前記エージェントの状態管理情報を，エージェントの死亡契機または前記特権処理手段から通知を依頼された契機に，前記特権処理手段へ通知する状態管理情報通知手段と，
前記特権処理手段からの依頼に基づき，指定されたエージェントを強制的に死滅させる，または指定されたエージェントへの処理依頼を取り消すエージェント処理取消し手段とを備える
ことを特徴とするエージェント監視制御方式。
【請求項２】
請求項１記載のエージェント監視制御方式において，
前記特権処理手段は，一般のエージェントよりも優先的に実行される特権的なエージェントによって構成される
ことを特徴とするエージェント監視制御方式。
【請求項３】
請求項１記載のエージェント監視制御方式において，
前記特権処理手段は，一般のエージェントよりも高い実行優先度を持つ，前記エンジンが走行するプロセスとは別のプロセス実行手段によって構成される
ことを特徴とするエージェント監視制御方式。
【請求項４】
情報処理システムの利用者になり代わって業務を行うために，ネットワーク内の複数の処理装置を渡り歩き，自律的に振る舞うことができるエージェントと，ネットワーク内の各処理装置において前記エージェントの実行制御および状態管理を行うエンジンとからなる情報処理システムにおいて，
前記エンジンは，
親エージェントから子エージェントへの処理依頼形態を含むエージェントの状態管理情報を管理するエージェント状態管理手段と，
前記エージェントの状態管理情報に基づき，ある親エージェントの死亡契機または他の処理装置で動作するエンジンからの指示時に，死亡したエージェントが生成した子エージェントが自エンジンに駐留する場合に，当該子エージェントを強制的に死滅させる，またはその子エージェントへの処理依頼を取り消すエージェント処理取消し手段と，
前記エージェントの状態管理情報に基づき，ある親エージェントの死亡契機に，死亡した親エージェントが生成した子エージェントが他のリモートの処理装置に駐留する場合に，当該子エージェントの死滅または処理依頼の取消しを決定し，他のリモートの処理装置上のエンジンにその指示を行うリモートエージェント処理取消し依頼手段とを備える
ことを特徴とするエージェント監視制御方式。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は，多数のエージェントがサーバ内，ネットワーク内を自律的に動き回るエージェント処理システムにおけるエージェント監視制御方式に関するものである。
【０００２】
【従来の技術】
ネットワークに接続された複数の処理装置からなるシステムにおける新しい形態の情報処理システムとして，エージェント処理システムが実用化され始めている。「エージェント」は，情報処理システムの利用者になり代わって業務を行うために，自律的に振る舞うことができ，以下の能力を有するものである。
【０００３】
（ａ）  エージェントは，ネットワーク内の複数のサーバを渡り歩くことができる。
（ｂ）  エージェントには，その暴走防止の目的で寿命時間が設けられているが，寿命に達するまで自律的に処理を続行できる。
【０００４】
（ｃ）  エージェントは，他のエージェントの消滅等の干渉はできない。
（ｄ）  エージェントは，別のエージェントを単数または複数個，新たに生成することができる。
【０００５】
（ｅ）  エージェントは，新規生成または既存の別エージェント（以降，子エージェントと呼ぶ）に処理を依頼できる。
（ｆ）  子エージェントは，親のエージェントと同じ能力がある。
【０００６】
これらのエージェントの実行制御を行うために，コンピュータ内に以下の能力を有する「エンジン」が設けられる。
（ａ）  エンジンは，エージェント処理を行うコンピュータ内に一つ以上（ネットワーク内に複数）存在することができる。
【０００７】
（ｂ）  エンジン上で動作するエージェントの寿命管理に加え，エージェントの状態（例えばエージェントが自エンジン内に駐留するか否かのエージェントの所在，自エンジン上のエージェントの実行状態，生死等）を管理している。
【０００８】
以上のようなエージェント処理システムにおいては，従来，次のような問題があった。
図５は，従来方式の動作例を説明する図である。
【０００９】
従来のエージェントの寿命管理や寿命が来た時点での強制消滅だけでは，システムの一時的な負荷の増加により，ＣＰＵなどコンピュータ資源が不足する場合に，仮に新たなエージェントの入力を規制したとしても長時間，高負荷状態が続き，負荷が鎮静化しないという問題があった。この現象が発生するプロセスは，図５に示す通りである。
【００１０】
（Ａ）正常負荷状態で，親エージェント−Ａが子エージェント−ａを生成したとする。生成した子エージェント−ａには，寿命時間を割り当てる。
（Ｂ）高負荷になったとすると，高負荷では資源不足により，エージェントが長時間実行待ちになり，ローカルエンジンの寿命管理により，タイムアウトが発生する。ローカルエンジンは，タイムアウトになった親エージェント−Ａに消滅指示を出す。
【００１１】
（Ｃ）親エージェント−Ａが先にタイムアウトし，死滅すると，その子エージェント−ａは，自身の寿命が無くなるまで親エージェント−Ａから依頼された業務処理を継続するだけでなく，自律的な行動を続ける。例えば，子エージェント−ａは，親エージェント−Ａに対して，依頼された業務処理の結果を報告しようとするが，親エージェント−Ａから応答できないので，何度も通知をリトライする。同様の現象は子エージェント−ａが死滅した場合の孫（子エージェントの子エージェント）などでも見られる。
【００１２】
（Ｄ）この処理は新たなコンピュータ資源の消費要因となってシステム負荷をますます増大させることになるため，上で述べた親・子・孫のエージェント以外の他のエージェントに対して，コンピュータ資源の割り当てをますます少なくすることになる。これにより新たなエージェントのタイムアウト・死滅が起こり，上記（Ｃ）のような無駄なリトライ処理等が新たなシステム負荷の増大をもたらす。
【００１３】
このように，エージェントの死滅から負荷増大へ，また負荷増大から別のエージェントの死滅へというように悪循環が続き，一つのエージェントの死滅が連鎖反応的に，エンジン内の多数のエージェントに波及する。このような高負荷の局面においては，仮に新たなエージェントの入力をオンライン回線の閉塞等の手段で完全にシャットアウトしたとしても，すでにシステムに入り込んだエージェントの自律的な処理により，高負荷状態が続き，それが暫く増長されることになる。
【００１４】
（Ｅ）そして，多くのエージェントが死滅して，やっとシステム負荷は鎮静化する。
【００１５】
【発明が解決しようとする課題】
従来のエージェント寿命管理だけを行う方式では，寿命が来れば，最終的に無効なエージェントの処理を停止できる。負荷が十分に低い，または負荷に対して十分なコンピュータ資源の空きがある場合，これは十分機能するが，一旦高負荷になり資源不足に突入すると，上に示したように負荷がさらに高まり，長時間にわたり収束しない。従来は，このような高負荷を避けるために，予想されるピークトラヒック以上の十分なコンピュータ資源を用意しなければならず，投資額が大きくなるばかりでなく，予想以上のトラヒックが発生した場合には，以上のような高負荷状態に陥ることが起こり得た。
【００１６】
また，子エージェントの生成を制限し，従来のプログラムのようにデータの送受信に切り換える方法も考えられるが，これでは設備投資は抑止できても，エージェントの自律性を活用したサービスとはならない。
【００１７】
本発明は上記問題点の解決を図り，エージェントの自律的な特性は活かしつつ，このような高負荷時のエージェントの無駄な行動のみを規制することで，負荷変動に対するエージェント処理システムの耐力を強化することを目的としている。
【００１８】
【課題を解決するための手段】
上記課題を解決するため，従来のエージェント処理システムにおけるエンジン，エージェント（以下，従来のエージェントを一般エージェントと呼ぶ）に加えて，本発明は，例えば次のような機能実現手段を持つ。
【００１９】
（Ｉ）特権エージェント機構（以下の新規機能で構成）
▲１▼  エージェント状態取得手段
エンジンから一般エージェント状態管理情報の通知を受ける／通知依頼する処理手段である。
【００２０】
▲２▼  ローカルエージェント処理取消し依頼手段
死滅したエージェントに子があり，かつその子が同一エンジンに駐留する場合，その子エージェントの管理状態に基づき，特権エージェントがその子エージェントの死滅／処理依頼の取消しを決定でき，エンジンにその旨指示する処理手段である。
【００２１】
▲３▼  リモートエージェント処理取消し依頼手段
他のリモートのエンジンに子が駐留する場合，その子エージェントの管理状態に基づき，特権エージェントがその子エージェントの死滅／処理依頼の取消しを決定でき，リモートの全エンジン上の特権エージェントに対して，特権エージェント間インタフェース機構による交信手段を用いて，その旨指示する処理手段である。
【００２２】
（ＩＩ）エンジンへの特権エージェント対応の追加機構
▲４▼  一般エージェント間処理依頼形態管理手段
親エージェントから子エージェントへの処理依頼形態（子の処理結果を待ち合わせる非委託型，その他の委託型の区別）を管理する手段である。
【００２３】
▲５▼  一般エージェント状態管理情報の特権エージェントへの通知手段
処理依頼形態の情報も含むエンジン内エージェント状態管理情報を，一般エージェントの死亡契機または特権エージェントからの問い合わせ依頼契機で特権エージェントへ通知する処理手段である。
【００２４】
▲６▼  特権エージェント指示に基づく一般エージェント処理取消し手段
特権エージェントからの依頼に基づき，指定されたエージェントを強制的に死滅させる，または指定された一般エージェントへの処理依頼を取り消す処理手段である。
【００２５】
▲７▼  特権エージェント優先実行制御手段
特権エージェントを一般エージェントよりも優先的に実行させる実行制御手段である。
【００２６】
（ＩＩＩ）特権エージェント間インタフェース機構
▲８▼  特権エージェントと他の特権エージェント間の通信や特権エージェントから他の特権エージェントへのブロードキャストを行い，かつそれを一般エージェント間通信より優先的に実行する手段である。
【００２７】
以上のような特権エージェントに代えて，この特権エージェントが持つ機能をエンジンが走行するプロセスとは別に設置した特権プロセスに吸収して実現することもできる。なお，ここで特権とは，一般エージェントよりも優先的にＣＰＵ使用権を獲得でき，またエンジンへの特殊処理の依頼を行うことができるような特別な権限を意味している。
【００２８】
さらに，上記特権エージェント相当の機能をローカル／リモートのエンジン制御の機能として，エンジン内に吸収して実現することも可能である。
【００２９】
【発明の実施の形態】
図１は本発明の構成例を示す。
図１において，１０，１０′，１０″はＣＰＵおよびメモリなどから構成される処理装置，２０，２０′，２０″はエージェントの管理および実行制御を行うエンジン，３０，３０′，３０″は特権エージェント等の特別な権限が与えられた特権処理手段，４０，４０′，４０″は情報処理システムの利用者になり代わって業務を行うために，ネットワーク内の複数の処理装置を渡り歩き，自律的に振る舞うことができるエージェント，５０は各処理装置を接続するネットワークを表す。
【００３０】
エンジン２０（２０′，２０″も同様）におけるエージェント実行制御部２１は，エージェントの生成，消滅およびエージェントに対するＣＰＵ使用権の割当てなどのエージェントの実行制御を行う手段である。本発明のエージェント実行制御部２１は，特に特権処理手段３０を一般のエージェント４０等によりも優先的に実行制御する手段が設けられている。
【００３１】
エージェント状態管理部２２は，エンジン２０上で動作するエージェント４０の寿命管理に加え，エージェントの状態（自エンジン内に駐留するか否かのエージェントの所在や，自エンジン上のエージェントの実行状態，生死等）を管理している。本発明のエージェント状態管理部２２は，さらに親エージェントから子エージェントへの処理依頼が，子エージェントの処理結果を親エージェントが待ち合わせる非委託型であるか，処理依頼した後，その結果を待たない委託型であるかを区別する処理依頼形態の情報についても管理する。
【００３２】
状態管理情報通知部２３は，エージェント状態管理部２２が管理するエージェント状態管理情報を，一般エージェントの死亡契機または特権処理手段３０からの問い合わせ依頼契機で特権処理手段３０へ通知する。通知する管理情報の中には，親・子エージェントの関係が，処理の委託型であるか非委託型であるかの処理依頼形態の情報も含まれる。
【００３３】
エージェント処理取消し部２４は，特権処理手段３０からの依頼に基づき，指定されたエージェントを強制的に死滅させる，または指定された一般エージェントへの処理依頼を取り消す手段である。
【００３４】
特権処理手段３０（３０′，３０″も同様）におけるエージェント状態取得部３１は，通知依頼により，またはあるエージェントが死滅した場合などに，エンジン２０から一般エージェント状態管理情報の通知を受ける手段である。
【００３５】
ローカルエージェント処理取消し依頼部３２は，死滅したエージェントに子があり，かつその子が同一エンジンに駐留する場合，その子エージェントの状態管理情報に基づき，その子エージェントの死滅／処理依頼の取消しを決定でき，エンジン２０にその旨依頼する処理手段である。
【００３６】
リモートエージェント処理取消し依頼部３３は，他のリモートのエンジン（２０′，２０″等）に子エージェントが駐留する場合，その子エージェントの状態管理情報に基づき，その子エージェントの死滅／処理依頼の取消しを決定でき，リモートの全エンジン上の特権処理手段（３０′，３０″等）に対して，特権処理間インタフェース機構３４を用いて，子エージェントの死滅または処理依頼の取消しを依頼する処理手段である。
【００３７】
特権処理間インタフェース機構３４は，特権処理手段３０と他の特権処理手段（３０′，３０″等）との間の通信や，ブロードキャストを行う処理機構である。
【００３８】
以下，特権処理手段３０を特権エージェントとして実現する場合，特権処理手段３０を特権プロセスとして実現する場合，特権処理手段３０をエンジン２０における制御機能として実現する場合の実施の形態について，それぞれ図２〜図４を参照して説明する。
【００３９】
〔第１の実施の形態〕
第１の実施の形態は，図１に示す特権処理手段３０を特権エージェントで実現する特権エージェント設置方式である。
【００４０】
（Ｉ）特権エージェントは以下の機能を具備する。
▲１▼  一般（親）エージェントが死滅した場合，親エージェントから子エージェントへの処理依頼形態の情報，子エージェントが自エンジン内に駐留しているか否かの情報を，以下の何れかで取得する機能を持つ。
【００４１】
ａ）親エージェントの死滅契機で，エンジンからの非同期報告。
ｂ）または，特権エージェントからの定期的問い合わせに対するエンジンからの応答。
【００４２】
この何れかはシステム個別に決められる。もちろん，一つのシステムで両方の取得方法を利用してもよい。
▲２▼  死滅する一般（親）エージェントと，その子エージェントとの関係を調べ，関係が「非委託型」であれば，即座にその子エージェントの無駄な行動を抑止する。以下にその手順を示す。
【００４３】
ｉ）自エンジン内にその子エージェントが駐留している場合，それを消滅する。または，それへの処理依頼の取消しを指示する。
ｉｉ）自エンジン内に駐留していない場合には，他の全エンジンの特権エージェントに当該エージェントの強制消滅／処理依頼の取消し指令をブロードキャストする。
【００４４】
ｉｉｉ）他のエンジン上の特権エージェントから，強制消滅／処理依頼の取消し指示ブロードキャストを受信した場合，指定された子エージェントについて消滅／処理依頼取消しを指示する。
【００４５】
ここで，ブロードキャスト通知を，特権エージェントの子エージェントで行う方法と，エンジン間のデータ通信で行う方法とがあるが，いずれを実装するかは設計上の事項であり，いずれでもよい。
【００４６】
（ＩＩ）エンジンでは，特権エージェントに対応して以下の機能を追加する。
▲１▼  特権エージェントを，エンジンの開始時に一つだけ生成し，エンジンの終了時に消滅させるように制御する。
【００４７】
▲２▼  エンジン内エージェントの消滅時またはそれ以降，そのエージェントの消滅事象と親エージェントから子エージェントの処理依頼形態等のエージェント状態管理情報を，特権エージェントへ伝達する。
【００４８】
▲３▼  特権エージェントの処理を，他の一般エージェントより優先的に実行する。
▲４▼  一般エージェントに許された処理に加え，特権エージェントだけに一般エージェントの消滅／処理依頼の取消し機能を提供する。
【００４９】
▲５▼  自エンジン上の特権エージェントから，他のエンジン上の特権エージェントへの強制消滅／処理依頼取消し指令を伝達する機能を提供する。
これは，例えば図１に示す特権処理間インタフェース機構の一実装例であり，外部独立プロセスを経由した方式，特権エージェント間で直接交信インタフェースを持つ方式等の実装バリエーションがあるが，これも設計上の事項である。
【００５０】
図２は，第１の実施の形態による処理の例を説明する図である。以下，図２に示す処理（１）  〜（１６）に従って説明する。
（１）  正常負荷の状態において，ローカルエンジン２０上で，親エージェント−Ａが二つの子エージェント−ａ，ａ′を生成したとする。ローカルエンジン２０は，子エージェント−ａ，ａ′への処理依頼形態が委託型であるか非委託型であるかを記録する。
【００５１】
（２）  子エージェント−ａ，ａ′の動作に伴い，子エージェント−ａ，ａ′がそれぞれ自エンジン内に駐留するか否かなどの行動を記録する。
（３）  高負荷になって，エージェントが長時間実行待ちになり，親エージェントン−Ａが寿命に至った場合，ローカルエンジン２０は，親エージェント−Ａの寿命到達により，これを消滅する。
【００５２】
（４）  ローカルエンジン２０は，特権エージェントに対し，親エージェント−Ａの死亡通知と併せて，子エージェント−ａ，ａ′の情報（子エージェントが自エンジン内に駐留・否，処理依頼形態の区分〔委託型／非委託型〕など）を，特権エージェントに伝達する。
【００５３】
（５）  また，ローカルエンジン２０は，特権エージェントの処理を他の一般エージェントよりも優先的に実行する制御を行う。したがって，特権エージェントからの指示があった場合，高負荷状態であっても遅延なくそれが実行される。
【００５４】
（６）  特権エージェントでは，ローカルエンジン２０から通知されたエージェント状態管理情報を取得する。
（７）  その情報をもとに，特権エージェントは，消滅した親エージェント−Ａに子エージェントが存在するかどうか，子エージェントが存在する場合，処理依頼形態が非委託型（親エージェントが子エージェントの処理結果を待ち合わせる依頼形態）であるかどうかを判別する。子エージェントが存在しない場合または依頼形態が委託型である場合には，特権エージェントは何も処理しない。
【００５５】
（８）  子エージェントが存在して，その子エージェントへの処理依頼形態が非委託型である場合には，その子エージェントが自エンジン内に駐留しているかどうかを調べる。他のエンジンに駐留している場合には，処理（１２）へ進む。
【００５６】
（９）  子エージェントが自エンジン内に駐留している場合，ローカルエンジン２０に対し，子エージェントの処理取消しを指示する。
（１０）ローカルエンジン２０では，この特権エージェントからの指示により，自エンジン上の子エージェント−ａの処理を強制的に取り消す。これにより，従来に比べ，負荷の鎮静化が早まる。
【００５７】
（１１）特権エージェントは，さらに他エンジンにも子エージェントがあるかどうかを調べ，  ない場合には処理を終了する。ある場合には，次の処理（１２）を実行する。
【００５８】
（１２）特権エージェントは，リモートエンジン２０′に対し，子エージェント−ａ′の処理取消し指示を出す。
（１３）ローカルエンジン２０は，特権エージェントからの指示をリモートエンジン２０′に転送する。
【００５９】
（１４）その通知を受けたリモートエンジン２０′は，特権エージェントへの指示を，リモートエンジン上の特権エージェントに伝達する。
（１５）その指示を受けた特権エージェントは，子エージェント−ａ′の処理取消しを，リモートエンジン２０′に指示する。
【００６０】
（１６）リモートエンジン２０′は，その指示を受けて，子エージェント−ａ′の処理を強制的に取り消す。これによって，高負荷が防止される。
また，この例の特権エージェントにて，一般エージェントの状態管理情報の定期的取得により，例えば予め指定された制限時間以上，親子間の交信が継続するエージェントがいないか監視させ，もしそのような親子エージェントを発見したならば，両エージェントを強制死滅させることも容易に実現できる。
【００６１】
これにより，悪意でシステム負荷増大をもたらす親子エージェントの取締り，悪影響の阻止も可能となる。
〔第２の実施の形態〕
第２の実施の形態は，図１に示す特権処理手段３０を特権プロセスで実現する特権プロセス設置による方式の例である。
【００６２】
この実施の形態では，上述した特権エージェントの機能を，エンジンが走行するプロセスとは別に設置した特権プロセスに吸収することによって実現する。
この方式は，エンジンがインタプリタ方式でエージェントの実行制御を行う場合，特権エージェント方式に比べオーバヘッドが小さいという特徴がある。
【００６３】
この特権プロセスの実行優先度を一般エージェントより高くするためには，ＯＳレベルの実行優先度をエンジンより高めに設定することで対処可能である。
図３は，第２の実施の形態による処理の例を説明する図である。以下，図３に示す処理（１）  〜（１５）に従って説明する。
【００６４】
（１）  正常負荷の状態において，ローカルエンジン２０上で，親エージェント−Ａが二つの子エージェント−ａ，ａ′を生成したとする。ローカルエンジン２０は，子エージェント−ａ，ａ′への処理依頼形態が委託型であるか非委託型であるかを記録する。
【００６５】
（２）  子エージェント−ａ，ａ′の動作に伴い，子エージェント−ａ，ａ′がそれぞれ自エンジン内に駐留するか否かなどの行動を記録する。
（３）  高負荷になって，エージェントが長時間実行待ちになり，親エージェントン−Ａが寿命に至った場合，ローカルエンジン２０は，親エージェント−Ａの寿命到達により，これを消滅する。
【００６６】
（４）  ローカルエンジン２０は，ローカル特権プロセスに対し，親エージェント−Ａの死亡通知と併せて，子エージェント−ａ，ａ′の情報（子エージェントが自エンジン内に駐留・否，処理依頼形態の区分〔委託型／非委託型〕など）を，ローカル特権プロセスに伝達する。
【００６７】
（５）  ローカル特権プロセスでは，ローカルエンジン２０から通知されたエージェント状態管理情報を取得する。
（６）  その情報をもとに，ローカル特権プロセスは，消滅した親エージェント−Ａに子エージェントが存在するかどうか，子エージェントが存在する場合，処理依頼形態が非委託型（親エージェントが子エージェントの処理結果を待ち合わせる依頼形態）であるかどうかを判別する。子エージェントが存在しない場合または処理依頼形態が委託型である場合には，ローカル特権プロセスは何も処理しない。
【００６８】
（７）  子エージェントが存在して，その子エージェントへの処理依頼形態が非委託型である場合には，その子エージェントが自エンジン内に駐留しているかどうかを調べる。他のエンジンに駐留している場合には，処理（１１）へ進む。
【００６９】
（８）  子エージェントが自エンジン内に駐留している場合，ローカルエンジン２０に対し，子エージェントの処理取消しを指示する。
（９）  ローカルエンジン２０では，このローカル特権プロセスからの指示により，自エンジン上の子エージェント−ａの処理を強制的に取り消す。これにより，従来に比べ，負荷の鎮静化が早まる。
【００７０】
（１０）ローカル特権プロセスは，さらに他エンジンにも子エージェントがあるかどうかを調べ，  ない場合には処理を終了する。ある場合には，次の処理（１１）を実行する。
【００７１】
（１１）ローカル特権プロセスは，リモートエンジン２０′に対し，子エージェント−ａ′の処理取消し指示を出す。
（１２）ローカルエンジン２０は，ローカル特権プロセスからの指示をリモートエンジン２０′に転送する。
【００７２】
（１３）その通知を受けたリモートエンジン２０′は，その指示をリモートエンジン上のリモート特権プロセスに伝達する。
（１４）リモート特権プロセスは，子エージェント−ａ′の処理取消しを，リモートエンジン２０′に指示する。
【００７３】
（１５）リモートエンジン２０′は，その指示を受けて，子エージェント−ａ′の処理を強制的に取り消す。これによって，高負荷が防止される。
〔第３の実施の形態〕
第３の実施の形態は，エンジンによる監視制御方式の例であり，上述した特権エージェントに相当する機能を，ローカル／リモートのエンジン制御の機能として吸収することによって実現する。
【００７４】
この方式は，上述した第１の実施の形態の特権エージェント方式に比べ，エンジンと特権エージェント間の分割損がなく，オーバヘッドが小さいという特徴がある。ただし，悪意による高負荷などに対して，新たなシステム個別の規制を行う場合，上述した第１の実施の形態では特権エージェントだけの変更で簡単に対処可能であるが，システム共通のエンジンでは吸収が困難となる。
【００７５】
また，エンジンにボトルネックがない場合には，上述した第２の実施の形態に比べ，プロセスの分割損が生じないため有利である。しかし，エンジンを搭載したプロセスの処理能力にシステムのボトルネックがあるシステムでは，第２の実施の形態のほうが，特権処理機能の実行に伴うエンジン負荷が別プロセスに分散されるため有効な場合がある。
【００７６】
図４は，第３の実施の形態による処理の例を説明する図である。以下，図４に示す処理（１）  〜（１１）に従って説明する。
（１）  正常負荷の状態において，ローカルエンジン２０上で，親エージェント−Ａが二つの子エージェント−ａ，ａ′を生成したとする。ローカルエンジン２０は，子エージェント−ａ，ａ′への処理依頼形態が委託型であるか非委託型であるかを記録する。
【００７７】
（２）  子エージェント−ａ，ａ′の動作に伴い，子エージェント−ａ，ａ′がそれぞれ自エンジン内に駐留するか否かなどの行動を記録する。
（３）  高負荷になって，エージェントが長時間実行待ちになり，親エージェントン−Ａが寿命に至った場合，ローカルエンジン２０は，親エージェント−Ａの寿命到達により，これを消滅する。
【００７８】
（４）  ローカルエンジン２０は，エンジン内特権エージェント相当処理を呼び出し，エージェント状態管理情報（子エージェントが自エンジン内に駐留・否，処理依頼形態の区分〔委託型／非委託型〕など）を取得する。
【００７９】
（５）  その情報をもとに，消滅した親エージェント−Ａに子エージェントが存在するかどうか，子エージェントが存在する場合，処理依頼形態が非委託型（親エージェントが子エージェントの処理結果を待ち合わせる依頼形態）であるかどうかを判別する。子エージェントが存在しない場合または依頼形態が委託型である場合には，何も処理しない。
【００８０】
（６）  子エージェントが存在して，その子エージェントへの処理依頼形態が非委託型である場合には，その子エージェントが自エンジン内に駐留しているかどうかを調べる。他のエンジンに駐留している場合には，処理（９）  へ進む。
【００８１】
（７）  子エージェントが自エンジン内に駐留している場合，ローカルエンジン２０のメイン処理部に対し，子エージェントの処理取消しを指示し，自エンジン上の子エージェント−ａの処理を強制的に取り消す。これにより，従来に比べ，負荷の鎮静化が早まる。
【００８２】
（８）  エンジン内特権エージェント相当処理では，さらに他エンジンにも子エージェントがあるかどうかを調べ，  ない場合には処理を終了する。ある場合には，次の処理（９）  を実行する。
【００８３】
（９）  ローカルエンジン２０は，全てのリモートエンジン２０′等に対し，子エージェント−ａ′の処理取消し指示を出す。
（１０）リモートエンジン２０′では，その処理取消し指示を受信する。
【００８４】
（１１）リモートエンジン２０′は，子エージェント−ａ′の処理取消しを受けて，子エージェント−ａ′の処理を強制的に取り消す。これによって，高負荷が防止される。
【００８５】
【発明の効果】
従来では，一つのエージェントがタイムアウト・死滅したことが引き金となって，高負荷が拡大していた。このため，このような高負荷状態に突入しないように，十分なコンピュータ資源を用意しなければならず，膨大な設備投資を必要としていた。
【００８６】
これに対して，特権エージェントもしくは特権エージェントに相当する処理手段の導入により，設備はシステムに要求される正味のエージェント処理量を実現するものだけで済むことになるので，同じエージェント処理量が要求されるエージェント処理システムを，従来より経済的に構築可能となる。
【００８７】
また，悪意により，自律的なエージェントに無駄なコンピュータ資源を消費させ，システムを高負荷状態に陥らせることも有り得る。このようなセキュリティ対策は，システム毎に個別な対処となる場合が多く，かつ新たな脅威に対して新たな対策を迅速に追加することが要求される。しかし，従来のエンジンだけでは汎用的機能の範囲での対応に限定され，システム個別の対応も困難であった。
【００８８】
これに対し本発明では，特権エージェントに一般エージェントの状態を監視させ，不正エージェントの取締りをさせることで，個別サービス提供業者のセキュリティポリシーを実現可能である。このように本発明は安全性の向上にも繋がるものである。
【図面の簡単な説明】
【図１】本発明の構成例を示す図である。
【図２】第１の実施の形態による処理の例を説明する図である。
【図３】第２の実施の形態による処理の例を説明する図である。
【図４】第３の実施の形態による処理の例を説明する図である。
【図５】従来方式の動作例を説明する図である。
【符号の説明】
１０，１０′，１０″  処理装置
２０，２０′，２０″  エンジン
２１  エージェント実行制御部
２２  エージェント状態管理部
２３  状態管理情報通知部
２４  エージェント処理取消し部
３０，３０′，３０″  特権処理手段
３１  エージェント状態取得部
３２  ローカルエージェント処理取消し依頼部
３３  リモートエージェント処理取消し依頼部
３４  特権処理間インタフェース機構
４０，４０′，４０″  エージェント
５０  ネットワーク
【図１】
0003548348.tif 000002
【図２】
0003548348.tif 000003
【図３】
0003548348.tif 000004
【図４】
0003548348.tif 000005
【図５】
0003548348.tif 000006