JPH11296374A - 情報処理装置及び方法並びに情報処理用プログラムを記録した記録媒体 - Google Patents

Abstract

(57)【要約】 【課題】 モバイルエージェントとステーショナリエー
ジェントとを状況に応じて動的に使い分けることで円滑
に情報を処理するエージェントの技術を提供する。 【解決手段】 エージェントが他のプラットフォームの
資源を使うとき、移動か協調かは、プラットフォームプ
ロファイル５２とエージェント属性５３の両方に基づい
て決める。移動機能を持つモバイルエージェントとステ
ーショナリエージェントの統合的活用が容易になる。プ
ランニングによってエージェントのプランが変わり、ど
のエージェントがどのプラットフォームの資源を使うこ
とになっても、プラットフォームプロファイルやエージ
ェント属性に基づいて移動か協調かを容易に決めること
ができる。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、ネットワーク上
に分散する情報をエージェントを使って処理する技術の
改良にかかわるもので、より具体的には、モバイルエー
ジェントとステーショナリエージェントとを状況に応じ
て動的に使い分けることで円滑に情報を処理するように
したものである。

【０００２】

【従来の技術】〔エージェントシステム〕従来から、コ
ンピュータのネットワーク上に分散した情報を処理する
技術として、エージェントシステムが知られている。エ
ージェントとは、ソフトウェア上の処理単位であり、周
囲の状況に応じて自律的に動作するものである。このエ
ージェントは、ネットワークを構成するノード間で移動
する能力を持つモバイルエージェントと、そのような移
動の能力を持たないステーショナリエージェントに分け
ることができる。

【０００３】エージェントシステムは、このようなエー
ジェントが利用者の要求を満たすために情報処理を行う
システムであり、特に、１つのシステム上で複数のエー
ジェントを使えば、ネットワークのような分散システム
での情報処理を一層効率的に行うことができる。このよ
うに複数のエージェントを使うシステムはマルチエージ
ェントシステムと呼ばれる。

【０００４】エージェントのうち、モバイルエージェン
トは、ネットワークを構成するノード上を必要に応じて
移動することで情報収集などの処理を行い、ステーショ
ナリエージェントは、契約ネットプロトコルなどの手続
きを使って他のエージェントと協力することで情報処理
を行う。なお、ノードとは、ネットワークを構成する論
理的な単位であり、エージェントをプログラムとしてと
らえた場合、エージェントの動作を支えるインタプリタ
やオペレーティングシステムの役割を果たす。このよう
なノードはプラットフォームとも呼び、一つのマシンす
なわちコンピュータ上に複数存在し得る。

【０００５】〔エージェントシステムの例〕次に、この
ようなエージェントシステムの一例を示す。すなわち、
図１９は、モバイルエージェントを使ったマルチエージ
ェントシステムの一例として、本出願人が特願平９−１
７６１８１で提案しているエージェントシステムの構成
例を示す機能ブロック図である。この図に示すエージェ
ントシステムは、複数のノード８００をネットワーク８
００Ｎで接続したものであり、ノード８００はシステム
上に多数設けることができるが、図１５では２つのノー
ドを代表例として示している。そして、ノード８００の
うち、利用者がエージェント生成に使用するノードをロ
ーカルノード（８００Ｌ）と呼び、生成されたエージェ
ントが移動して行く先のノードをリモートノード（８０
０Ｒ）と呼ぶ。

【０００６】このエージェントシステムにおいて、各ノ
ード８００は、利用者がエージェントを生成する操作を
行なったり、エージェントが情報処理を行なった結果を
受け取るための入出力手段８０３（Ｌ，Ｒ）を有する。
また、各ノードのエージェント管理手段８０４（Ｌ，
Ｒ）は、エージェントを生成したり、役割を終えたエー
ジェントを消去する他、エージェントの情報を他のノー
ドへ転送することによって、エージェントを他のノード
へ移動させたり、他のノードから同様に移動してくるエ
ージェントを受け入れる手段である。

【０００７】利用者は、このようなエージェントシステ
ムを用いて何らかの情報処理を行ないたい場合、ローカ
ルノード８００Ｌにおいて、入出力手段８０３Ｌからエ
ージェント管理手段８０４Ｌに指示を与えることによっ
てエージェントを生成させる。

【０００８】そして、最も基本的な例を示せば、生成さ
れたエージェントに対して、利用者が入出力手段８０３
Ｌからスクリプトを与える。スクリプトは、エージェン
トの行動プログラムであり、どのノードへ移動し、どの
ような処理を行う、といった内容を具体的に記述したも
のである。スクリプトのより具体的な例としては、例え
ば、ノードＡに移動してファイルａのコピーを利用者の
ノードに送信し、次にノードＢに移動してファイルｂの
コピーを利用者のノードに送信し…といった内容が考え
られる。そして、各ノードに備えられた解釈実行手段８
０２（Ｌ，Ｒ）は、このようなスクリプトを実行するこ
とによってエージェントを活動させ、これによって目的
とする情報処理を実現する。

【０００９】この場合、各ノードに備えられたエージェ
ント情報記憶手段８０１（Ｌ，Ｒ）が、エージェントに
必要な情報を記憶する。エージェントに必要な情報は、
例えば、前記のスクリプトのほか、スクリプトの解釈実
行に必要な各変数（スクリプト変数と呼ばれる）や、必
要な場合は、エージェントが収集した情報やファイルな
どである。また、エージェントのスクリプトに記述され
る命令としては、一つのノード上だけで実行できる命令
のほか、エージェントを他のノードへ移動させるための
移動命令がある。解釈実行手段８０２Ｌは、スクリプト
の命令を順次実行し、移動命令の実行が必要になった場
合には、移動先のノードを指定して、エージェントの移
動をエージェント管理手段８０４に依頼する。

【００１０】このようなエージェントシステムでは、利
用者が、いくつかのファイルをネットワーク上から収集
したいような場合、この目的を達成するための行動プロ
グラムをエージェントに持たせてネットワーク上に送り
出せばよく、送り出されたエージェントは、与えられた
スクリプトに基づいて自律的に活動する。このため、利
用者のノードとエージェントとの間で通信を始終維持す
る必要はないことから、ｆｔｐやｔｅｌｎｅｔといった
従来のネットワーク機能と比べて回線障害に強いという
利点がある。

【００１１】〔プランニングを用いる構成例〕図１９に
示したエージェントシステムに対して、エージェントの
行動プログラムであるスクリプトを、状況に応じて変化
させることができるエージェントシステムも知られてい
る。

【００１２】すなわち、近年のようにネットワークが大
規模化・複雑化し、特に、インターネットのような広域
ネットワークと接続されることによっていわゆる開放型
ネットワークになると、ファイルの所在などのようなネ
ットワークの構成要素がしばしば変化するようになる。
ところが、図１９に示した上記のようなエージェントシ
ステムでは、エージェントは生成される時点で固定され
たスクリプトを与えられるため、状況に応じて行動を変
更することができない。そこで、このような変化に柔軟
に対応するため、人手を煩わせずにエージェントの行動
を自動的に変化させる技術として、本出願人は、プラン
ニング機能を持ったエージェントシステムを出願してい
る。

【００１３】この技術では、エージェントの行動プログ
ラムはプランと呼び、プランを生成することをプランニ
ングと呼ぶ。そして、この技術では、状況に応じてプラ
ンを適宜作り直すことによって、ネットワークの構成要
素の変化に対応する。なお、ネットワークの構成などの
変化に対応したり、プランの実行が失敗したためにプラ
ンニングを再度やり直すことを再プランニングと呼ぶ。

【００１４】このようなエージェントシステムの構成例
を図２０の機能ブロック図に示す。この技術において、
プランの生成に用いる情報としては、「知識」と呼ばれ
る情報とアクション定義とが挙げられる。このうち「知
識」は、エージェントの動作、特にプランニングに利用
する各種の情報であり、その一例として、どのファイル
がどのノードに存在するかといったネットワークの構成
要素に関する情報を含む。例えば図２０の例では、この
ようなネットワークの構成に関する知識を、ローカル情
報記憶手段１Ｌに保存しておき、ネットワークの構成に
変化があったときは、更新手段２Ｌが、自動検出や手作
業などによって、このような変化を知識に反映させる。
また、アクション定義とは、プランを構成する部品とし
て、どのような種類の命令（アクション）が使えるかを
表す情報であり、エージェント情報記憶手段３に格納し
ておく。

【００１５】このようなエージェントシステムでは、エ
ージェントの生成を指示する利用者は、スクリプトの代
わりに、達成したいゴールをノードに与える。ここで、
ゴールとは、情報処理の目的として達成したい状態を、
予め定められた文法で記述したものである。すると、プ
ラン生成手段５は、与えられた知識を参照しながら、ア
クション定義に含まれる各種のアクションを組み合わせ
ることによって、ゴールを達成するためのプランを生成
する。このようなエージェントシステムでは、ネットワ
ークの構成の変化は、プランニングや再プランニングの
際に、知識を介してエージェントのプランに反映される
ので、エージェントは人手を介さずに状況の変化に対応
し柔軟に行動を変化させることができる。

【００１６】なお、このようなプランを生成する手段は
「プランナ」とも呼ばれ、その実体はプランニングの手
続きを表すプログラムの一種である。また、エージェン
トの行動プログラムやその各部分を呼ぶ広義の概念がス
クリプトであり、プランというときは、特に、図２０に
示したようなプランニングを行うエージェントによって
生成されたスクリプトの全体を指す。

【００１７】〔プランを使った動作の例〕続いて、上に
述べたようなプランニングを用いたエージェントシステ
ムの具体的な動作手順を図２１に例示する。この手順で
は、利用者が、情報処理のゴールとしてエージェントに
対する要求の記述（要求記述）を入力すると（ステップ
２０１）、必要な初期化が行なわれた後（ステップ２０
２）、プランが生成される（ステップ２０３）。なお、
処理は、ゴールが既に達成されているなど終了条件の判
定結果に応じて終了する（ステップ２０４，２０５）。

【００１８】すなわち、このような終了条件が満たされ
るまでは（ステップ２０４）、ゴールを達成するために
実行を要するプランの実行が行われる。プランの実行で
は、プランに含まれる各命令を順次実行し（ステップ２
０６，２０８）、実行する命令が移動命令の場合には
（ステップ２０７）エージェントをノード間で移動させ
る処理（goアクションと呼ばれる）が実行される（ステ
ップ２０８）。また、各命令の実行やgoアクションの実
行に失敗した場合は、必要に応じて新たなプランを生成
する（ステップ２０３）。

【００１９】〔エージェントのライフサイクル〕次に、
以上のようにプランニングを行うエージェントのライフ
サイクルを示す概念図を図２２に示す。すなわち、エー
ジェントは、ゴール投入と共に生成されて活動を開始す
ると、まず、プランを生成するプランニングフェーズＰ
から開始し、生成されたプランにしたがい、プランを実
行する実行フェーズＥやノード間で移動する移動フェー
ズＭに移行し、実行や移動の失敗に応じてこれらの各フ
ェーズ間を移行しながら活動する。そして、当初与えら
れたゴールを達成すれば正常終了となり、ゴールが達成
できずにプランニング自体にも失敗すると完全失敗とな
って終了する。

【００２０】

【発明が解決しようとする課題】ところで、複雑なネッ
トワークや大規模なネットワークでは、１つのシステム
上にモバイルエージェントとステーショナリエージェン
トの両方があったり、１つのエージェントが、モバイル
エージェントとして移動する機能と、ステーショナリエ
ージェントと同じように他のエージェントと契約ネット
プロトコルなどで協調する機能を、両方持っている場合
も考えられる。

【００２１】このような場合、モバイルエージェントと
ステーショナリエージェントとの統合的活用が重要にな
る。つまり、あるノードでエージェントが動作する際
に、他のノードに固有のファイルやソフトウェアなどの
資源を使うことがしばしば必要になる。そして、このよ
うにエージェントが他のノードの資源を使うには、エー
ジェント自身が他のノードへ移動するか、他のノードの
エージェントに仕事を頼む必要がある。このように、あ
るノードにいるエージェントから、他のノードにいるエ
ージェントに仕事を頼むことを協調と呼ぶ。

【００２２】さらに、このように移動と協調とが可能な
場合、ある条件では自分がモバイルエージェントとして
そのノードに移動して行くほうがよいが、別の条件では
そのノードにいるステーショナリエージェントに処理を
依頼して協調するほうがよい、といった場合が多い。従
来では、プランに基づいて他のノードの資源を利用する
ために移動と協調とが考えられる場合、移動と協調のう
ちどちらを行うかを、プラン中の動作列としてあらかじ
め規定しておく必要があった。

【００２３】しかし、このような決定は、通信回線の性
質やノードの性質などに応じて動的に行う必要があるこ
とが多い。ここで、通信回線の性質としては、例えば信
頼性や通信帯域などが考えられ、信頼性の低い回線で接
続されているノードの資源を使おうとするときは、協調
よりも移動のほうが望ましい。つまり、協調では、その
ノードと通信を維持する必要があるが、信頼性の低い回
線を通しての通信は途絶えやすく、このように通信が途
絶えると協調の処理が中断されるからである。これに対
して、エージェント自身がそのノードに移動してしまえ
ば、移動の時に通った回線が切断されていても移動先で
の処理には差し支えがなく、処理が終了した後で、回線
の状態が回復したときに元のノードに戻るなどすれば足
りるからである。

【００２４】また、ノードの性質としては、例えばモバ
イルエージェントをサポートしているかどうか、などが
考えられる。つまり、エージェントに移動する機能があ
っても、移動先のノードが、エージェントの情報を受け
入れて活動させる手段を持っていなければそのノードで
エージェントが処理を続けることはできない。

【００２５】さらに、利用したいノードとの間の通信回
線の信頼性が低くても、全てのノードを移動させればよ
いわけではなく、エージェント自身が他のノードに移動
する機能を持ったモバイルエージェントでなければ、移
動は不可能であり、協調を選ぶべきである。このよう
に、従来では、モバイルエージェントとステーショナリ
エージェントとを状況に応じて動的に使い分けることで
円滑に情報を処理することは困難であった。

【００２６】また、モバイルエージェントを他のノード
に移動させる場合、移動先のノードは利用者が直接管理
できる対象ではなく、特に移動先のノードが信頼性の低
い回線の先にあるようなとき、移動先や回線で障害が起
きたときの対処も困難であった。

【００２７】つまり、モバイルエージェントの運用に当
たり、次の２点には注意すべきである。第１点は、モバ
イルエージェントの大きな採用理由の１つに、通信回線
の信頼性が低い、あるいは帯域幅が小さい、という状況
がある場合が多いことである。このため、モバイルエー
ジェントは携帯端末を用いたモバイルコンピューティン
グを、もっとも主要な適用分野としている。このように
信頼性の低い回線を使うときは、エラーなどの例外が発
生したときにどのように対処するかが大きな課題とな
る。

【００２８】第２点は、モバイルエージェントは移動に
より利用者が管理し得ないマシンのノード上で動作し得
る、という点である。このため、そのようなマシンでエ
ージェントの動作に例外的状況が発生した場合、モバイ
ルエージェントでない場合に比べて対処が一層困難とな
る。特に、第１点で挙げたような信頼性の低い通信回線
を通じて移動先のマシンを利用している場合には、この
ような困難は顕著なものとなる。

【００２９】この発明は、上に述べたような従来技術の
問題点を解決するために提案されたもので、その目的
は、モバイルエージェントとステーショナリエージェン
トとを状況に応じて動的に使い分けることで円滑に情報
を処理するエージェントの技術を提供することである。
また、この発明の他の目的は、通信回線の信頼性が低い
場合でも例外的な状況に円滑に対処する技術を提供する
ことである。

【００３０】

【課題を解決するための手段】上に述べた目的を達成す
るため、請求項１の発明は、ネットワークで互いに接続
された複数のプラットフォーム上でエージェントが情報
処理を行う情報処理装置において、エージェントが他の
プラットフォームの資源を使うとき、そのエージェント
を当該他のプラットフォームへ移動させる移動手段と、
エージェントが他のプラットフォームの資源を使うと
き、そのエージェントから当該他のプラットフォームの
エージェントに処理を依頼させる協調手段と、個々のプ
ラットフォームが移動されたエージェントを受け入れて
活動させる手段を備えているかどうかを表わすプラット
フォームプロファイルを格納する手段と、エージェント
が他のプラットフォームの資源を使うとき、前記プラッ
トフォームプロファイルに基づいて、そのエージェント
を当該他のプラットフォームへ移動させるか、そのエー
ジェントから当該他のプラットフォームのエージェント
に処理を依頼させるかを決定する決定手段と、を備えた
ことを特徴とする。請求項１の発明では、個々のプラッ
トフォームすなわちノードが移動型のモバイルエージェ
ントをサポートしているかどうかの情報をプラットフォ
ームプロファイルとして用意しておく。そして、エージ
ェントが他のプラットフォームの資源を使うとき、その
エージェントを当該他のプラットフォームへ移動させる
か、そのエージェントから当該他のプラットフォームの
エージェントに処理を依頼させる（協調）かは、このプ
ラットフォームプロファイルに基づいて容易に決めるこ
とができる。

【００３１】例えば、エージェントが他のプラットフォ
ームの資源を使うとき、そのプラットフォームとの間の
回線の信頼性が低ければ、そのプラットフォームに移動
することが望ましいが、そのプラットフォームがモバイ
ルエージェントをサポートしていないことをプラットフ
ォームプロファイルから予め判断することで、移動を試
すまでもなく、そのプラットフォームのエージェントと
協調を行うべきだと判断できる。

【００３２】なお、複数のエージェント間で協調を行う
には、従来から知られているエージェント間協調の技
術、例えば契約ネットプロトコルや、黒板機能などを使
えばよい。

【００３３】請求項２の発明は、ネットワークで互いに
接続された複数のプラットフォーム上でエージェントが
情報処理を行う情報処理装置において、エージェントが
他のプラットフォームの資源を使うとき、そのエージェ
ントを当該他のプラットフォームへ移動させる移動手段
と、エージェントが他のプラットフォームの資源を使う
とき、そのエージェントから当該他のプラットフォーム
のエージェントに処理を依頼させる協調手段と、個々の
エージェントがプラットフォーム間で移動する能力を持
つかどうかに関するエージェント属性を格納する手段
と、エージェントが他のプラットフォームの資源を使う
とき、前記エージェント属性に基づいて、そのエージェ
ントを当該他のプラットフォームへ移動させるか、その
エージェントから当該他のプラットフォームのエージェ
ントに処理を依頼させるかを決定する決定手段と、を備
えたことを特徴とする。請求項２の発明では、エージェ
ントごとに、プラットフォーム間で移動する能力を持つ
モバイルエージェントか、移動する能力を持たないステ
ーショナリエージェントかの情報をエージェント属性と
して用意しておく。そして、エージェントが他のプラッ
トフォームの資源を使うとき、そのエージェントを当該
他のプラットフォームへ移動させるか、そのエージェン
トから当該他のプラットフォームのエージェントに処理
を依頼させる（協調）かは、このエージェント属性に基
づいて容易に決めることができる。

【００３４】請求項３の発明は、ネットワークで互いに
接続された複数のプラットフォーム上でエージェントが
情報処理を行う情報処理装置において、エージェントが
他のプラットフォームの資源を使うとき、そのエージェ
ントを当該他のプラットフォームへ移動させる移動手段
と、エージェントが他のプラットフォームの資源を使う
とき、そのエージェントから当該他のプラットフォーム
のエージェントに処理を依頼させる協調手段と、個々の
プラットフォームが移動されたエージェントを受け入れ
て活動させる手段を備えているかどうかを表わすプラッ
トフォームプロファイルを格納する手段と、個々のエー
ジェントがプラットフォーム間で移動する能力を持つか
どうかに関するエージェント属性を格納する手段と、エ
ージェントが他のプラットフォームの資源を使うとき、
前記プラットフォームプロファイル及び前記エージェン
ト属性に基づいて、そのエージェントを当該他のプラッ
トフォームへ移動させるか、そのエージェントから当該
他のプラットフォームのエージェントに処理を依頼させ
るかを決定する決定手段と、を備えたことを特徴とす
る。請求項１２の発明は、請求項３の発明を方法という
見方からとらえたもので、ネットワークで互いに接続さ
れた複数のプラットフォーム上でエージェントが情報処
理を行う情報処理方法において、エージェントが他のプ
ラットフォームの資源を使うとき、そのエージェントを
当該他のプラットフォームへ移動させるステップと、エ
ージェントが他のプラットフォームの資源を使うとき、
そのエージェントから当該他のプラットフォームのエー
ジェントに処理を依頼させるステップと、個々のプラッ
トフォームが移動されたエージェントを受け入れて活動
させる手段を備えているかどうかを表わすプラットフォ
ームプロファイルと、個々のエージェントがプラットフ
ォーム間で移動する能力を持つかどうかに関するエージ
ェント属性に基づいて、エージェントが他のプラットフ
ォームの資源を使うとき、そのエージェントを当該他の
プラットフォームへ移動させるか、そのエージェントか
ら当該他のプラットフォームのエージェントに処理を依
頼させるかを決定するステップと、を含むことを特徴と
する。請求項１６の発明は、請求項３，１２の発明を、
コンピュータプログラムを記録した記録媒体という見方
からとらえたもので、コンピュータを使って、ネットワ
ークで互いに接続された複数のプラットフォーム上でエ
ージェントに情報処理を行わせる情報処理用プログラム
を記録した記録媒体において、そのプログラムは前記コ
ンピュータに、エージェントが他のプラットフォームの
資源を使うとき、そのエージェントを当該他のプラット
フォームへ移動させ、エージェントが他のプラットフォ
ームの資源を使うとき、そのエージェントから当該他の
プラットフォームのエージェントに処理を依頼させ、個
々のプラットフォームが移動されたエージェントを受け
入れて活動させる手段を備えているかどうかを表わすプ
ラットフォームプロファイルを格納させ、個々のエージ
ェントがプラットフォーム間で移動する能力を持つかど
うかに関するエージェント属性を格納させ、エージェン
トが他のプラットフォームの資源を使うとき、前記プラ
ットフォームプロファイル及びエージェント属性に基づ
いて、そのエージェントを当該他のプラットフォームへ
移動させるか、そのエージェントから当該他のプラット
フォームのエージェントに処理を依頼させるかを決定さ
せることを特徴とする。請求項３，１２，１６の発明で
は、エージェントが他のプラットフォームの資源を使う
とき、移動か協調かは、プラットフォームプロファイル
とエージェント属性の両方に基づいて決める。例えば、
そのエージェントとプラットフォームの両方が移動をサ
ポートしていればエージェントを移動させるが、どちら
か一方でもサポートしていなければ協調とする。これに
よって、移動機能を持つモバイルエージェントとステー
ショナリエージェントの統合的活用が容易になる。

【００３５】請求項４の発明は、ネットワークで互いに
接続された複数のプラットフォーム上でエージェントが
情報処理を行う情報処理装置において、与えられた要求
を満たすエージェントのプランを生成するプランニング
手段と、生成されたプランを実行することでエージェン
トを動作させる実行手段と、エージェントの動作に必要
な情報を格納するためのエージェント情報格納手段と、
プラットフォーム上のエージェントに対して、他のプラ
ットフォームに移動させ又は他のプラットフォームのエ
ージェントに処理を依頼させることで他のプラットフォ
ームの資源を使わせるエージェント管理手段と、前記プ
ランの生成、前記移動及び前記依頼に必要な知識を格納
する知識格納手段と、前記知識格納手段を管理する知識
管理手段と、エージェントが他のプラットフォームの資
源を使うとき、そのエージェントを当該他のプラットフ
ォームへ移動させる移動手段と、エージェントが他のプ
ラットフォームの資源を使うとき、そのエージェントか
ら当該他のプラットフォームのエージェントに処理を依
頼させる協調手段と、個々のプラットフォームが移動さ
れたエージェントを受け入れて活動させる手段を備えて
いるかどうかを表わすプラットフォームプロファイルを
格納する手段と、個々のエージェントがプラットフォー
ム間で移動する能力を持つかどうかに関するエージェン
ト属性を格納する手段と、エージェントが他のプラット
フォームの資源を使うとき、前記プラットフォームプロ
ファイル及び前記エージェント属性に基づいて、そのエ
ージェントを当該他のプラットフォームへ移動させる
か、そのエージェントから当該他のプラットフォームの
エージェントに処理を依頼させるかを決定する決定手段
と、を備えたことを特徴とする。請求項１３の発明は、
請求項４の発明を方法という見方からとらえたもので、
ネットワークで互いに接続された複数のプラットフォー
ム上でエージェントが情報処理を行う情報処理方法にお
いて、与えられた要求を満たすエージェントのプランを
生成するステップと、生成されたプランを実行すること
でエージェントを動作させるステップと、エージェント
の動作に必要な情報を格納し及び読み出すステップと、
プラットフォーム上のエージェントに対して、他のプラ
ットフォームに移動させ又は他のプラットフォームのエ
ージェントに処理を依頼させることで他のプラットフォ
ームの資源を使わせるステップと、前記プランの生成、
前記移動及び前記依頼に必要な知識を格納し及び読み出
すステップと、前記知識格納手段を管理するステップ
と、エージェントが他のプラットフォームの資源を使う
とき、そのエージェントを当該他のプラットフォームへ
移動させるステップと、エージェントが他のプラットフ
ォームの資源を使うとき、そのエージェントから当該他
のプラットフォームのエージェントに処理を依頼させる
ステップと、個々のプラットフォームが移動されたエー
ジェントを受け入れて活動させる手段を備えているかど
うかを表わすプラットフォームプロファイルと、個々の
エージェントがプラットフォーム間で移動する能力を持
つかどうかに関するエージェント属性とに基づいて、エ
ージェントが他のプラットフォームの資源を使うとき、
そのエージェントを当該他のプラットフォームへ移動さ
せるか、そのエージェントから当該他のプラットフォー
ムのエージェントに処理を依頼させるかを決定するステ
ップと、を含むことを特徴とする。請求項４，１３の発
明では、プランニングによってネットワークの予期せぬ
変化に柔軟に対応できる。そして、プランニングによっ
てエージェントのプランが変わり、どのエージェントが
どのプラットフォームの資源を使うことになっても、プ
ラットフォームプロファイルやエージェント属性に基づ
いて移動か協調かを容易に決めることができる。このよ
うに、移動と協調とを使い分けることで、ネットワーク
という分散環境でエージェントを使う情報処理が効率化
される。また、ネットワークの変化にもプランニングで
対応しながら、エージェントの移動と協調とを有効に結
び付けて活用するので、開放型ネットワークでも効果的
に情報処理を行うことができる。

【００３６】請求項５の発明は、請求項１から４のいず
れか１つに記載の情報処理装置において、ネットワーク
で互いに接続された複数のプラットフォーム上でエージ
ェントが情報処理を行う情報処理装置において、エージ
ェントがプラットフォーム間で移動しようとするときの
例外に対応するための例外対応手段を備えたことを特徴
とする。請求項１４の発明は、請求項５の発明を方法と
いう見方からとらえたもので、請求項１２又は１３に記
載の情報処理方法ネットワークで互いに接続された複数
のプラットフォーム上でエージェントが情報処理を行う
情報処理方法において、エージェントがプラットフォー
ム間で移動しようとするときの例外に対応するためのス
テップを含むことを特徴とする。請求項５，１４の発明
では、エージェントがプラットフォーム間で移動しよう
とするときに移動失敗などの例外が発生しても、そのよ
うな例外に適切に対応することで情報処理が円滑に行わ
れる。

【００３７】請求項６の発明は、請求項５記載の情報処
理装置において、前記例外対応手段は、どのような例外
に対してどのように対処するかを表わす例外記述と、前
記例外記述に基づいて例外に対処する対処手段と、を備
えたことを特徴とする。請求項６の発明では、移動時の
どのような例外に対してどのように対処するかは例外記
述に表わしておき、例外記述を書き換えることで対処の
内容を容易に変更することができる。

【００３８】請求項７の発明は、請求項６記載の情報処
理装置において、前記例外記述は、（１）移動先として
指定されたプラットフォームとの通信が失敗したために
エージェントが移動できない例外、（２）移動先の指定
が無効であるためにエージェントが移動できない例外、
（３）移動先として指定されたプラットフォームが移動
されたエージェントを受け入れて活動させる手段を備え
ていないためにエージェントが移動できない例外、
（４）移動先として指定されたプラットフォームにおけ
る資源不足のためにエージェントが移動できない例外、
のうち少なくとも１つについて、どのように対処するか
を表わすことを特徴とする。請求項７の発明では、移動
のときによく起きがちな例外、すなわち移動先との通信
の失敗、移動先の指定が無効、移動先がモバイルエージ
ェントに対応していない、移動先での資源不足、のうち
少なくとも１つに対する対処を例外記述に表わしておく
ので、例外に効果的に対処することができる。

【００３９】請求項８の発明は、請求項６又は７記載の
情報処理装置において、前記例外記述は、前記通信回線
のうち信頼性の低い通信回線に関する情報と、エージェ
ントが前記信頼性の低い通信回線を通してプラットフォ
ーム間で移動するときに発生する可能性がある例外に対
してどのように対処するかを表わす情報と、を含むこと
を特徴とする。請求項１５の発明は、請求項８の発明を
方法という見方からとらえたもので、ネットワークで互
いに接続された複数のプラットフォーム上でエージェン
トが情報処理を行う情報処理方法において、どのような
例外に対してどのように対処するかを表わす例外記述に
基づいて例外に対処するステップを含み、前記例外記述
は、前記通信回線のうち信頼性の低い通信回線に関する
情報と、エージェントが前記信頼性の低い通信回線を通
してプラットフォーム間で移動するときに発生する可能
性がある例外に対してどのように対処するかを表わす情
報と、を含むことを特徴とする。請求項８，１５の発明
では、どの通信回線の信頼性が低いかの情報を予め各プ
ラットフォームなどに用意しておき、エージェントがそ
のような回線を通して移動しようとするときに通信が途
絶したときの対応を決めておく。これによって、通信回
線の信頼性が低く、通信が途絶しやすい場合でも動作不
全や故障などが起きにくくなる。

【００４０】請求項９の発明は、請求項８記載の情報処
理装置において、前記通信回線で一定時間反応が途絶し
ていることを検知するタイムアウト検知手段を備え、前
記例外対応手段は、前記信頼性の低い通信回線を通して
エージェントを移動させるための通信を行っているとき
に、前記タイムアウト検知手段が前記途絶を検知した場
合、予め決められた待ち時間の後で前記通信を再び試み
る処理を繰り返すように構成されたことを特徴とする。
請求項１６の発明は、請求項９の発明を方法という見方
からとらえたもので、請求項１５記載の情報処理方法に
おいて、前記通信回線で一定時間反応が途絶しているこ
とを検知するステップと、前記信頼性の低い通信回線を
通してエージェントを移動させるための通信を行ってい
るときに前記途絶が検知された場合、予め決められた待
ち時間の後で前記通信を再び試みる処理を繰り返すこと
を特徴とする。請求項９，１６の発明では、エージェン
トを移動させるための通信が途絶えるとしばらく待って
から再び通信を試みる処理が繰り返される。このため、
通信回線の信頼性が低くても、状態がよくなっている間
にエージェントの情報を送ってエージェントを移動させ
ることができる可能性が高くなる。

【００４１】請求項１０の発明は、請求項１から９のい
ずれか１つに記載の情報処理装置において、各プラット
フォームは、異なった目的に対応する複数のフィールド
を備え、プラットフォームの持っている資源をフィール
ドごとに分けて管理するフィールド管理手段を備えたこ
とを特徴とする。請求項１０の発明では、プランニング
に使う知識などプラットフォームの資源が情報処理の目
的や知識の適用分野などを基準に、フィールドごとに分
けて管理される。このため、あるフィールドのエージェ
ントは、自分の目的と関係ない知識まで参照する必要が
なく、効率的にプランニングをすることができる。

【００４２】請求項１１の発明は、請求項１から１０の
いずれか１つに記載の情報処理装置において、複数のエ
ージェントが情報をやり取りするための黒板手段と、前
記黒板手段を、情報の優先度に応じた複数の階層に分け
て管理することで各エージェントを協調させるように制
御する黒板管理手段と、を備えたことを特徴とする。請
求項１１の発明では、ネットワークの予期せぬ変化のよ
うな急ぎの情報は、例えば、黒板の上位階層に書き込む
ことで、エージェントの通常の動作に割り込ませ、その
ような変化に対応してエージェントの動作を制御するこ
とができる。

【００４３】

【発明の実施の形態】以下、この発明の実施の形態（以
下「実施形態」という）について図面を参照しながら説
明する。なお、この発明は、周辺機器を持つコンピュー
タを、ソフトウェアで制御することによって実現される
ことが一般的と考えられる。この場合、そのソフトウェ
アは、この明細書の記載にしたがった命令を組み合わせ
ることで作られ、上に述べた従来技術と共通の部分には
従来技術で説明した手法も使われる。また、そのソフト
ウェアは、プログラムコードだけでなく、プログラムコ
ードの実行のときに使うために予め用意されたデータも
含む。

【００４４】そして、そのソフトウェアは、ＣＰＵ、コ
プロセッサ、各種チップセットといった処理装置、キー
ボードやマウスといった入力装置、メモリやハードディ
スク装置といった記憶装置、ディスプレイやプリンタと
いった出力装置などの物理的な資源を活用することでこ
の発明の作用効果を実現する。

【００４５】但し、この発明を実現する具体的なソフト
ウェアやハードウェアの構成はいろいろ変更することが
できる。例えば、ソフトウェアの形式には、コンパイ
ラ、インタプリタ、アセンブラなどいろいろあり、外部
との情報をやり取りするにも、フロッピーディスクなど
の着脱可能な記録媒体、ネットワーク接続装置などいろ
いろ考えられる。また、この発明を実現するソフトウェ
アやプログラムを記録したＣＤ−ＲＯＭのような記録媒
体は、単独でもこの発明の一態様である。さらに、この
発明の機能の一部をＬＳＩなどの物理的な電子回路で実
現することも可能である。

【００４６】以上のように、コンピュータを使ってこの
発明を実現する態様はいろいろ考えられるので、以下で
は、この発明や実施形態に含まれる個々の機能を実現す
る仮想的回路ブロックを使って、この発明と実施形態と
を説明する。

【００４７】〔１．構成〕 〔１−１．プラットフォームの全体構成〕この実施形態
は、ネットワークで互いに接続された複数のプラットフ
ォーム上でエージェントが情報処理を行う情報処理装置
であり、図１は、この実施形態を構成する１つのプラッ
トフォームの構成を示すブロック図である。

【００４８】この図において、１は、エージェントを管
理するエージェント管理部であり、このエージェント管
理部１は、プランニング、ネットワークＮ上でのエージ
ェントの移動、およびエージェント間での協調を実現す
るのに必要な構成（後述）を備えている。また、２は、
与えられた要求を満たすためにエージェントが実行すべ
き実行手順すなわちプランを生成するプランニング部で
あり、３は、このように生成したプランを実行すること
でエージェントを動作させる実行部である。また、４
は、エージェントが動作するときに必要な情報、例えば
前記のプランやエージェントの内部状態を表わす変数な
どを格納するエージェント情報記憶部である。

【００４９】また、５は、プランニングに必要な知識
や、信頼性の低い通信回線で接続された計算機に関する
知識など各種の情報（後述）を格納する知識格納部であ
り、６は、この知識格納部５を管理する知識管理部であ
り、知識格納部５に格納されている各種の知識につい
て、書き込み、読み出し、修正などの処理を行う。

【００５０】また、この実施形態では、個々のプラット
フォームが、異なった目的に対応する複数のフィールド
を備えている。このフィールドは、知識およびエージェ
ントの動作の範囲を示すもので、７は、プラットフォー
ムの持っている資源をフィールドごとに分けて管理する
フィールド管理部である。

【００５１】また、８は、エージェント間の協調やエー
ジェントの動作を制御するのに使う情報を格納する黒板
部である。また、９は、黒板部８においてエージェント
の動作制御のレベルを表す黒板階層構造を管理する階層
黒板管理部である。また、２０は、以上の各部を管理
し、またネットワーク間の通信を管理するプラットフォ
ームであり、１１は、各部の情報を出力し、また各部へ
の入力、および各部の状態を制御する情報を入力できる
入出力部である。

【００５２】〔１−２．問題の具体例〕次に、図２は、
この実施形態の情報処理装置を具体的な問題に適用する
場合の具体例を示す概念図であり、具体的には、通信回
線Ｃ１〜Ｃ５で接続されたいくつかのプラットフォーム
１０１〜１０６の上で、旅行のチケットを予約する例で
ある。すなわち、この図２において、１０１は、利用者
が持ち歩くことができる携帯計算機であり、携帯電話や
ＰＨＳのような無線回線などの随時接続・切断可能な回
線によって、この実施形態におけるネットワークＮに組
込めるものとする。図１は、このようにネットワークに
組み込まれるプラットフォームの一例を示したものであ
る。

【００５３】利用者は、この携帯計算機１０１を通じて
ネットワークを利用することで、ある地方のある大学
（仮に「地方大学」と呼ぶ）に東京から赴く旅行計画お
よび交通機関のチケット予約を行うものとする。

【００５４】また、図２において、１０２は、ある旅行
代理店の計算機であり、ネットワーク上の旅行計画およ
び交通機関チケット予約に利用できる種々の計算機に関
する情報を格納している。また、１０３、１０４はそれ
ぞれ、航空会社ＡＬ１，ＡＬ２の計算機であり、１０５
は地方大学のある地域を担当している観光局の計算機、
さらに１０６は、目的地である地方大学の計算機であ
る。

【００５５】これら各計算機１０１から１０６には、後
に説明するような旅行計画およびチケット予約に必要な
データが格納されている。なお、これら各計算機１０１
から１０６は、以下では単に「旅行代理店」「地方大
学」や「交通局」のように表わす。

【００５６】〔１−３．知識格納部の内容〕次に、図１
に示したプラットフォーム１０の知識格納部５に、どの
ような情報が格納されているかを説明する。この知識格
納部５は、プランの生成、エージェントのプラットフォ
ーム間での移動及びエージェント同士の協調に必要な知
識を格納する部分であり、この知識格納部５には、具体
的には、プランニング用知識５１、プラットフォームプ
ロファイル５２、エージェント属性５３、例外記述５４
が格納されている。

【００５７】〔１−３−１．プランニング用知識〕この
うち、プランニング用知識５１は、エージェントのプラ
ン生成に使うものであり、どのファイルがどのプラット
フォームにあるのかといったネットワークの構成に関す
る知識や、どのようなときにどのようにプランニングを
行うのかといった知識の他に、情報処理装置やエージェ
ントの利用目的に応じて各種の知識を含めることができ
る。

【００５８】〔１−３−２．プラットフォームプロファ
イル〕また、プラットフォームプロファイル５２は、個
々のプラットフォームが移動されたエージェントを受け
入れて活動させる構成を備えているかどうか、すなわち
モバイルをサポートしているかどうかを表わす情報であ
り、このプラットフォームプロファイル５２の例を図３
に示す。この例は、図２に示した各プラットフォームに
対応するもので、携帯計算機（図２の１０１）や旅行代
理店（図２の１０２）といった各プラットフォームごと
に、モバイルエージェントのサポートがあるかないかを
記録したものである。

【００５９】〔１−３−３．エージェント属性〕また、
エージェント属性は、個々のエージェントがプラットフ
ォーム間で移動する能力を持つかどうか、すなわちモバ
イルをサポートしているかどうかに関する情報であり、
このエージェント属性５３の例を図４に示す。この例
は、図２に示した実例に対応するもので、エージェント
の名称ごとに、そのエージェントがどのプラットフォー
ムに所属するものであるかと、そのエージェントが移動
型かどうかを表わす属性mobilityを登録したものであ
る。

【００６０】この属性mobilityは、エージェントがモバ
イルエージェントならmobile、ステーショナリエージェ
ントならstationaryという属性値を設定することで、エ
ージェントの移動能力の有無を区別している。このよう
な属性値は、エージェント情報格納部４に格納されてい
るエージェントの情報のうち、エージェントがモバイル
をサポートしているかどうかを表わすフラグや、プラッ
トフォーム間での移動に関する情報があるかどうかなど
から判断することができる。

【００６１】そして、エージェント管理部１は、新しく
エージェントを生成するときや、移動してきたエージェ
ントを受け入れたときに上に述べたような情報からエー
ジェント属性を判断して登録しておけばよい。

【００６２】また、所属は、ステーショナリエージェン
トについてそのエージェントが存在するプラットフォー
ムであり、モバイルエージェントについては、そのエー
ジェントが生成されたプラットフォームの名称である。

【００６３】〔１−３−４．例外記述〕例外記述５４
は、エージェントがプラットフォーム間で移動しようと
するときについて、どのような例外に対してどのように
対処するかを表わすものであり、この例外記述５４の例
を図５に示す。この例は、次のような例外内容に対し
て、それぞれ対処内容を定めている。

【００６４】（１）移動先として指定されたプラットフ
ォームとの通信が失敗したためにエージェントが移動で
きない例外（通信タイムアウト）。これは、例えば移動
先のプラットフォームに、エージェントを移動させたい
という通知を送信したが、相手からの反応が一定時間以
上途絶えているような場合である。

【００６５】（２）移動先の指定が無効であるためにエ
ージェントが移動できない例外（移動先指定誤り）。こ
れは、つまり移動先の指定が誤っている場合であり、例
えば、移動先として指定したプラットフォームあるいは
ドメインのＩＤなどが無効である場合などが考えられ
る。このような例外は、エージェントが生成されたプラ
ットフォームから他のプラットフォームへの移動しよう
としたときなどに発生する。

【００６６】（３）移動先として指定されたプラットフ
ォームが移動されたエージェントを受け入れて活動させ
る構成を備えていないためにエージェントが移動できな
い例外（モバイルサポートなし）。これは、つまり移動
先のプラットフォームが、そのプラットフォームの機能
としてモバイルエージェントをサポートしていない場合
であり、このような例外は、エージェントが生成された
プラットフォームから他のプラットフォームへの移動し
ようとしたときなどに発生する。

【００６７】（４）移動先として指定されたプラットフ
ォームにおける資源不足のためにエージェントが移動で
きない例外（移動先資源不足）。これは、つまり移動先
のプラットフォームが、本来は移動されたエージェント
を受け入れて活動させる構成を備えているが、たまたま
メモリなどの資源が不足しているためエージェントを受
け入れられないような場合である。このような例外は、
エージェントが、生成されたプラットフォームから他の
プラットフォームへ移動しようとしたとき、移動のため
にエージェントのデータが転送された後、転送されたエ
ージェントが移動先で動作を再開しようとするときなど
に発生する。

【００６８】なお、（１）の通信タイムアウトでは、信
頼性の高い回線で発生した場合と、信頼の低い回線で発
生した場合とで、対処内容が異なる。このため、この例
外記述は、信頼性の低い通信回線に関する情報を含んで
いる。

【００６９】〔１−３−５．信頼性の低い通信回線に関
する情報〕ここでいう「信頼性の低い通信回線に関する
情報」は、図２に示した通信回線Ｃ１〜Ｃ５のうち、ど
の通信回線の信頼性が低いかを表わす情報であり、この
ような情報の例を図６に示す。この例では、各通信回線
Ｃ１〜Ｃ５について、どのプラットフォーム（接続先
１）とどのプラットフォーム（接続先２）を接続してい
るかと、その通信回線の信頼性が低いか高いかを登録し
たものである。なお、図２では、信頼性の高い通信回線
は太い実線で示し、信頼性の低い通信回線は細い点線で
示している。

【００７０】また、以下では、他のノードとの通信回線
の信頼性については、説明を単純にするために、１つの
通信回線についてだけ述べるが、実際には、インターネ
ットのようなハブ（中心）のないネットワーク構成で
は、あるプラットフォームから別のプラットフォームへ
の通信回線の信頼性は、複数の通信回線の信頼性に基づ
いて決まる。そのような場合、回線の信頼性について
は、複数の通信回線の組み合わせごとに登録しておいた
り、ある経路の信頼性を、その経路を構成するいくつか
の通信回線の信頼性から計算してもよい。

【００７１】信頼性の低い通信回線に関する情報は、後
で詳しく説明するが、プラットフォーム間でエージェン
トを移動させようとする通信で通信タイムアウトが発生
したときに、現在通信に使っている通信回線の信頼性が
低いか高いかを調べるのに使うことができ、図５に示す
「通信タイムアウト（信頼性の低い回線）」は、エージ
ェントが信頼性の低い通信回線を通してプラットフォー
ム間で移動するときに通信タイムアウトが発生したと
き、どのように対処するかを表わしている。

【００７２】〔１−４．エージェント管理部の構成〕ま
た、エージェント管理部１は、プラットフォーム上のエ
ージェントを管理すると共に、個々のエージェントに対
して、他のプラットフォームに移動させ又は他のプラッ
トフォームのエージェントに処理を依頼させることで他
のプラットフォームの資源を使わせる部分である。この
エージェント管理部１は、エージェントを生成したり、
登録したり、消滅させたりするための構成（図示せず）
の他に、協調部１１と、移動部１２と、決定部１３と、
対処部１４と、タイムアウト検知部１５と、を備えてい
る。

【００７３】このうち、協調部１１は、エージェントが
他のプラットフォームの資源を使うとき、そのエージェ
ントから当該他のプラットフォームのエージェントに処
理を依頼させる部分であり、具体的には契約ネットプロ
トコルを実行するためのタスクアナウンス、入札締切、
落札といった処理を行うように構成されている。また、
移動部１２は、エージェントが他のプラットフォームの
資源を使うとき、そのエージェントを当該他のプラット
フォームへ移動させる部分であり、具体的には、移動先
としてプランなどで指定されるプラットフォームとの間
で、エージェント移動の打診や、エージェント情報格納
部４に格納されている情報の転送といった処理を行うよ
うに構成されている。

【００７４】また、決定部１３は、エージェントが他の
プラットフォームの資源を使うとき、プラットフォーム
プロファイル５２及びエージェント属性５３に基づい
て、そのエージェントを当該他のプラットフォームへ移
動させるか、そのエージェントから当該他のプラットフ
ォームのエージェントに処理を依頼させるかを決定する
部分である。

【００７５】また、対処部１４は、例外記述５４に基づ
いて例外に対処する部分であり、これら対処部１４及び
例外記述５４は、エージェントがプラットフォーム間で
移動しようとするときの例外に対応するための例外対応
手段を構成している。また、タイムアウト検知部１５
は、通信回線で一定時間反応が途絶していることを検知
する部分であり、信頼性の低い回線での通信タイムアウ
トの場合の例外記述と組み合わせて使う。

【００７６】これにより、信頼性の低い通信回線を通し
てエージェントを移動させるための通信を行っていると
きに、タイムアウト検知部１５が途絶を検知した場合、
対処部１４の働きによって、予め決められた待ち時間の
後で前記通信を再び試みる処理を繰り返す、という例外
への対応を実現する。

【００７７】〔１−５．フィールド〕また、フィールド
管理部７に関連して上で説明したように、各プラットフ
ォームは、異なった目的に対応する複数のフィールドを
備えている。このフィールドは、情報処理の目的や分野
ごとに設定されるエージェントの活動領域であり、ファ
ームとも呼ばれる。このようなフィールドは、一つのプ
ラットフォーム上に複数存在することができ、フィール
ド管理部７は、メモリなどの資源やプランの生成・実行
に用いる情報などを、フィールド毎に管理する。

【００７８】ここで、図７は、ネットワークＮに複数の
ホストＨ（マシン）が接続され、各ホストＨ上には１つ
ずつのプラットフォームすなわちノードＸが存在し、ノ
ードＸ上に複数のフィールドＦＬが存在する例を示す概
念図である。このようなエージェントシステムでは、プ
ラン生成に用いる知識がフィールドＦＬごとに分けられ
ており、これによって、エージェントはプランニングな
どに必要な情報を検索する際、余分な情報まで参照する
必要がないので、情報処理が効率化される。なお、プラ
ン生成に用いられる知識はその知識を所持している主体
によって、ファームが所持しているファーム知識、エー
ジェントが所持しているエージェント知識などに分ける
ことができる。

【００７９】〔１−６．黒板〕また、黒板管理部９は、
黒板部８を、情報の優先度に応じた複数の階層に分けて
管理することで、協調動作を含め、各エージェントを制
御するように構成されている。すなわち、図８に示すよ
うに、黒板部８は、上位階層と下位階層を備え、ネット
ワークの予期せぬ変化のように、例えばエージェント間
で急いで伝える必要がある情報は黒板の上位階層に書き
込むようになっている。また、これに対応して、黒板管
理部９は、そのような情報に関する処理を、エージェン
トの通常の動作に割り込ませるように構成されている。
これによって、ネットワークの予期せぬ変化のような状
況の変化に対応してエージェントの動作を制御するする
ことができる。

【００８０】〔１−７．他のプラットフォームの構成〕
なお、図１では１つのノードすなわちプラットフォーム
についてその構成を示したが、これは、この実施形態の
情報処理装置に含まれる多数のプラットフォームの一例
であり、構成が一部異なる他のプラットフォームが存在
する場合も考えられる。例えば、モバイルエージェント
をサポートしていないプラットフォームには移動部１２
やタイムアウト検知部１５は必要なく、また、エージェ
ント間の情報交換に、特定の１つのプラットフォームの
黒板部８と黒板管理部９を使うときは、それ以外のプラ
ットフォームには黒板部８や黒板管理部９は必要ない。

【００８１】また、例えば、プランニングの機能を持た
ないプラットフォームがあってもよく、そのようなプラ
ットフォームでは、プランニング用知識５１、プランニ
ング部２は必要がない。また、複数のフィールドを持た
ないプラットフォームではフィールド管理部７は必要が
ない。

【００８２】〔２．作用〕上に述べたように構成された
この実施形態は、次のように働く。まず、図９は、この
実施の形態における処理手順を示すフローチャートであ
る。

【００８３】〔２−１．要求の入力〕すなわち、まず、
利用者が、本システムへの要求を、携帯計算機の入出力
部２０を通じて入力する（ステップ３０１）。この要求
は、情報処理の結果として達成したい状態を、予め定め
られた形式で記述することによって表す。例えば、利用
者は、下記の通り旅行計画およびチケット予約に関する
要求を入力する。 出発地：東京 出発日時：１１月３日 到着地：地方大学 到着日時：１１月３日午後０時まで 利用交通機関：航空機

【００８４】〔２−２．ゴールへの変換〕このように入
力された要求は、続いて、ゴールに変換される（ステッ
プ３０２）。このゴールは、エージェントによる情報処
理によって達成したい状態を、エージェントやプランニ
ング部２が処理できる形式で表わしたものである。例え
ば、上に述べた旅行計画及びチケット予約に関する要求
は、例えば、次のようなゴールに変換される。 plan_and_reserve_tickets([departure_place(tokyo),d
eparture_date(11,3),arrival_place(a_university),ar
rival_date(11,3),arrival_time(by,12,0),transport(a
ir)])

【００８５】〔２−３．エージェントの初期化〕このよ
うに要求がゴールに変換されると、プラットフォームの
エージェント管理部１が、ゴールの達成に使うエージェ
ントを生成し、初期化の手順を実行する（ステップ３０
３）。例えば、“ｕｓｅｒ”という名前でエージェント
を生成した場合、初期化の手順として、エージェントを
管理するためのリストに名称“ｕｓｅｒ” を登録した
り、エージェントｕｓｅｒの内部変数に所定の初期値を
設定したり、タイムシェアリングシステムにおけるタイ
ムスライス（ＣＰＵ時間）をエージェントｕｓｅｒに割
り当てるなどの処理を行なう。

【００８６】なお、複数のフィールドが存在するプラッ
トフォームでは（図７）、各エージェントはエージェン
ト管理部１による管理のもとで特定のフィールド内に生
成される。そして、これに続くプランニング部２による
プランニングでは、知識管理部６がフィールドに対応す
る知識を読み出して提供する。

【００８７】〔２−４．プランニング〕続いて、プラン
ニング部２が、変換されたゴールを達成するためのプラ
ンを生成（プランニング）する（ステップ３０４）。こ
こで、プランニング用知識５１には、プランを構成する
部品として、エージェントはどのような種類の動作を実
行できるかという情報が含まれている。このような単位
となる動作はアクションとも呼ばれ、動作ごとに、事前
条件と事後条件とが予め決められている。

【００８８】ここで、事前条件とは、その動作を実行す
るために必要な条件であり、事後条件とは、その動作の
実行によって作りだされる条件である。このため、ある
動作である事後条件が達成されれば、その事後条件に対
応する事前条件を持つ動作が実行できる状態となる。例
えば、「ファイルをコピーする」という動作を行うに
は、「現在いるプラットフォームにファイルが存在す
る」という事前条件が必要であり、コピーの動作を行な
った結果として「ファイルのコピーが存在する」という
事後条件が産み出される。

【００８９】すなわち、プランの生成は、最終的なゴー
ルを事後条件として産み出す動作を発見し、この動作の
事前条件を事後条件として産み出すさらに別の動作を発
見する、という処理を続けることによって、プランを実
行する前の状態（現在の状態）と最終的なゴールとの間
をつなぐ動作の列を得ることである。なお、図１０は、
生成途中におけるプランの例を示す図であり、この例で
は、動作Ｐ２の一方の事前条件Ｃ５と、動作Ｐ３の事前
条件Ｃ７について、これら事前条件を事後条件として産
み出す動作がまだ見つかっていない。このように、事後
条件として産み出す他の動作がまだ見つかっていない事
前条件は未達成ゴールと呼ばれる。

【００９０】このようなプラン生成の処理は、ゴールの
側から因果を逆に遡って行ない、プランの実行を開始す
る時点で存在している状態（現在の状態）に到達すると
終了する。図１１は、このような処理によって完成した
プランの例を示す図である。

【００９１】続いて、プラン生成の具体的な手順を図１
２に示す。すなわち、この手順では、ゴールを記録して
おくゴールリストの一部を、図１０に示したような未達
成ゴールを記録しておく未達成ゴールリストとしてお
き、次のような処理を行う。まず、ゴールリストに未達
成ゴールが存在しなくなるまで（ステップ４０１）、未
達成ゴールリストから未達成ゴールを１つずつ選択し
（ステップ４０２）、ゴールが満足されている場合を除
いて（ステップ４０３）、次のような動作を行う。すな
わち、ゴールである事前条件を事後条件によって達成可
能な動作が存在すれば（ステップ４０４）この動作を選
択し（ステップ４０５）、このように選択した動作（選
択動作）を図１０に示したような動作の系列（プラン
木）に追加する（ステップ４０５）。

【００９２】また、ゴールを達成可能な動作が存在しな
い場合は、ゴールが不確実知識で達成可能かを判断す
る。ここで、不確実知識とは、ネットワークの構成に関
する知識のうち、他のプラットフォームで実際に何らか
の処理を行なってみないと、真偽などの具体的な値がわ
からない知識である。ゴールが不確実知識で達成可能な
場合はこの不確実知識を選択動作としてプラン木に追加
するが（ステップ４０５）、不確実知識でも達成不可能
な場合は、処理をバックトラックさせ（ステップ４０
８）、現在の未達成ゴールを生じさせている動作を他の
動作に置き換えて再度処理を行う。

【００９３】例えば、利用者が使用するプラットフォー
ムの知識で、「ファイルａがプラットフォームＡに存在
する」とされているとする。この場合、ファイルａを得
るというゴールを利用者が与えると、プラットフォーム
Ａに存在するという知識が参照されるので、生成された
エージェントのプランは、「プラットフォームＡに移動
してファイルａのコピーを利用者のプラットフォームに
送信する」、といった内容になる。

【００９４】しかし、エージェントがプラットフォーム
Ａに移動した時点で、ファイルａはプラットフォームＢ
に移動されていると、ファイルａが発見できないために
プランは実行失敗となり、プラットフォームＡ上で再プ
ランニングが行なわれる。このとき、プラットフォーム
Ｂの知識がファイルの移動にあわせて更新されており、
「ファイルａはプラットフォームＢに存在する」と変更
されている場合、新しいプランは「プラットフォームＢ
に移動してファイルａのコピーを利用者のプラットフォ
ームに送信する」、という内容に変更される。この結
果、エージェントはプラットフォームＢに自律的に移動
するし、ファイルａを無事発見して利用者のプラットフ
ォームに送信することができる。

【００９５】〔２−５．不確実知識を利用したかの判
断〕上に述べたようなプランニング手順（図９のステッ
プ３０４）が終了すると、決定部１３が、プランニング
において不確実知識を用いたか否かを判別する（ステッ
プ３０５）。不確実知識の使用の有無は、プランニング
において不確実知識を用いる度にその旨のデータを記録
しておいて、記録したデータに基づいて判別してもよい
し、作成されたプラン自体を再度検索することによっ
て、不確実知識が含まれているか否かを判別してもよ
い。

【００９６】〔２−６．不確実知識の分類〕不確実知識
は、他のプラットフォーム（以下「目的のプラットフォ
ーム」と呼ぶ）での処理によって確認される知識である
から、プランに不確実知識が用いられた場合、そのプラ
ンによって目的が達成されるためには、不確実知識を確
認する処理が必要である。ここでは、不確実知識を確認
する処理は、プラン実行に先だって行なう。

【００９７】そして、決定部１３は、不確実知識ごと
に、その不確実知識の確認をエージェントの移動で行う
べきか、協調で行うべきかを決定することで、例えば
「移動」と「分類」の２種類に分類する（ステップ３０
６）。この分類では、決定部１３は、次の（１）から
（３）の３つの条件を同時に満たす不確実知識につい
て、確認を移動で行うと決定し、条件の１つでも満たさ
ない不確実知識については、確認を協調で行うと決定す
る。

【００９８】（１）エージェントが現在いるプラットフ
ォームと目的のプラットフォームとを結ぶ通信回線の信
頼性が低いこと 通信回線の信頼性が高ければ目的のプラットフォームと
通信を続けることができるためであり、このような通信
回線の信頼性は、通信回線の信頼性に関する情報（図
６）から、次のように調べることができる。例えば、図
６の情報では、個々の通信回線ごとに、どのプラットフ
ォームとどのプラットフォームを接続しているかが記録
されている。このため、この２つプラットフォームの組
み合わせが、現在のプラットフォームと目的のプラット
フォームに一致する通信回線を探し、その通信回線の信
頼性を読み出せばよい。

【００９９】（２）目的のプラットフォームがモバイル
をサポートしていること （３）エージェントの属性がモバイルであること 目的のプラットフォームとエージェントの両方がモバイ
ルをサポートしていなければ、エージェントが移動した
り移動先のプラットフォームで活動することができない
ためである。このうち目的のプラットフォームがモバイ
ルをサポートしているかどうかは、図３に例示したプラ
ットフォームプロファイル５２を参照することで判断で
き、また、エージェントがモバイルをサポートしている
かどうかは、図４に例示したエージェント属性５３を参
照することで判断できる。

【０１００】なお、必ずしもこれら３つの条件全てに基
づいて判断しなければならないわけではない。例えば、
ネットワーク内の全てのプラットフォームがモバイルを
サポートしていることが予めわかっているような場合
は、１つ又は２つの条件で判断することもできる。ま
た、不確実知識が確認できるプラットフォームやそのプ
ラットフォームにいるエージェントが、モバイルではな
く、協調動作をサポートしているかどうかなどを、判断
の項目に加えることもできる。

【０１０１】続いて、上に述べたような分類にしたがっ
て、不確実知識の確認が行われる。すなわち、確認を協
調で行うと決定された不確実知識については協調部１１
が契約ネットプロトコル手続きに基づいて確認を行い
（ステップ３０７）、一方、確認を移動で行うと決定さ
れた不確実知識については移動部１２がエージェントを
移動させることによって確認を行う（ステップ３０
８）。

【０１０２】なお、不確実知識を移動で確認するか協調
で確認するかは、プランニング後に決定部１３が行うの
で、プランニングでは不確実知識の確認のために移動す
るか協調するかをプランで指定する必要がない。このた
め、プランニングの手順も単純で済み、処理が効率化さ
れる。

【０１０３】〔２−７．契約ネットプロトコル手続き〕
次に、契約ネットプロトコル(Contract Net Protocol)
手続きの詳細を図１３に示す（参考文献：Smith, R.
G., "The Contract Net Protocol: High-level Communi
cation and Control in a Distributed Problem Solve
r", IEEE Trans. Computers, Vol. 29, pp. 1104-1113
(1980). ）。ここで、契約ネットプロトコルでは、エー
ジェントから他のエージェントに依頼される作業をタス
クと呼ぶ。また、タスクをエージェント間で依頼する契
約ネットプロトコルは、実際には、エージェントが存在
するプラットフォームの協調部１１同士の間で行なわれ
る。

【０１０４】〔２−７−１．タスクアナウンス〕契約ネ
ットプロトコルにおいてタスク実行を依頼する場合は、
まず、タスクを持つエージェント（以下、タスクマネジ
ャと呼ぶ）が、ステップ６０１において、タスクを依頼
したいプラットフォーム群に対して依頼に関する情報
（以下「タスク情報」という）をブロードキャストす
る。なお、ブロードキャストとは一定範囲の相手に対し
て無差別に情報を送信することであり、タスク情報をブ
ロードキャストすることをタスクアナウンスという。ブ
ロードキャストするタスク情報としては、例えば、タス
クＩＤ、タスクの内容、タスクマネジャのＩＤ、プラン
評価基準、入札期限などがある。

【０１０５】〔２−７−２．入札〕上に述べたようなタ
スク情報を受信したプラットフォームは、各フィールド
にエージェントを生成し、それらにタスク情報を転送す
る（ステップ６０２）。タスク情報を受け取った各エー
ジェントは、自らが所属しているフィールドにおいてタ
スクを実行可能かどうか判断し（ステップ６０３）、タ
スク内容を実行可能なエージェントは、入札する旨の情
報（以下「入札情報」や「入札メッセージ」という）を
タスクマネジャに送信（入札）する（ステップ６０
４）。なお、入札情報を送信したエージェントを入札エ
ージェントと呼ぶ。

【０１０６】入札情報には、例えば、タスクＩＤ、エー
ジェントＩＤ、タスク実行プラン評価値などがあり、こ
のうちタスク実行プラン評価値は、タスクアナウンスで
示されたプラン評価基準に基づいて、入札エージェント
が、自分がタスクを実行する場合における評価を計算し
たものである。

【０１０７】〔２−７−３．入札締切と落札〕タスクマ
ネジャは、入札を締め切る入札期限と現在時刻を比較し
ながら入札情報を受信し、ステップ６０５において入札
期限に到達すると、次のステップ６０６において入札締
切を示すメッセージを発信する。この締切のメッセージ
は、タスク情報のブロードキャスト先とした全ての依頼
プラットフォームに対してブロードキャストする。そし
て、タスクマネジャは、ステップ６０９において、落札
するエージェントを決定する。この決定は、入札期限ま
でに受信した各入札情報のタスク実行プラン評価値と、
予め定めた決定の基準に基づいて、各エージェントの入
札情報を比較することによって行なう。

【０１０８】落札するエージェント（落札エージェント
と呼ぶ）の決定は、タスクマネジャが、実際にタスクを
依頼する先としてそのエージェントを決定することを意
味するが、実際にタスクを依頼する時期は処理の内容に
応じて異なっていてもよく、契約ネットプロトコルの終
了後に直ちに依頼する場合もあれば、所定の時期まで待
って依頼する場合もある。

【０１０９】落札エージェントを決定すると、タスクマ
ネジャは、ステップ６１０において、各入札エージェン
トに、落札の内容を表す落札情報をマルチキャスト（同
報送信）する。この落札情報を受信することによって、
落札エージェントは、タスクを実際に実行すべき旨の実
行依頼を待つ状態となる。タスクマネジャは、落札され
たタスクの実行をその後、落札エージェントに依頼し、
その結果、落札エージェントは依頼されたタスクの内容
を実際に実行する。

【０１１０】上に述べたように、この実施の形態では、
エージェント間協調を実現するために契約ネットプロト
コルを用いる。そして、契約ネットプロトコルで処理を
他のプラットフォームに依頼する場合は、依頼側プラッ
トフォームの持つ条件と請負側プラットフォームの持つ
能力との間で、入札制による調和が図られる。このた
め、システム全体として優れた処理効率が実現される。

【０１１１】〔２−８．エージェントの移動の詳細〕ま
た、エージェントがプラットフォーム間で移動する場合
の手順を図１４に示す。この例では、エージェントの移
動元のプラットフォームをローカルノード、移動先のプ
ラットフォームをリモートノードと呼ぶ。この場合、ロ
ーカルノードからの移動要求（ステップ５０１）を受信
したリモートノードは（ステップ５０２）、エージェン
ト用のプロセスを設定する（ステップ５０３）。

【０１１２】続いて、リモートノードから、プロセスの
設定が完了した旨の通知（ステップ５０４）を受信した
ローカルノードは（ステップ５０５）、エージェントの
プランや変数領域などのエージェント情報をリモートノ
ードに送信する（ステップ５０６）。このエージェント
情報を受信したリモートノードは（ステップ５０７）、
エージェント情報を格納し（ステップ５０８）、ローカ
ルノードへ移動成功の通知を送信し（ステップ５０
９）、プランの解釈実行を開始する（ステップ５１
０）。一方、成功の通知を受信したローカルノードは
（ステップ５１１）、不要になったエージェント用のプ
ロセスを消去する（ステップ５１２）。

【０１１３】〔２−９．プランの実行〕図９のステップ
３０５の判断で、プランに不確実知識が用いられていな
い場合は、実行部３が直ちにプランを実行し（ステップ
３０９）、実行が成功すると手順を終了するが、実行に
失敗すると再プランニングを行う。なお、プランに不確
実知識が用いられていた場合は、上に述べたように、契
約ネットプロトコル（図９のステップ３０７）やエージ
ェントの移動（ステップ３０８）によって不確実知識が
確認され、その時点までのプランが実質的に完成してか
ら、実行部３がプランを実行する（ステップ３０９）。

【０１１４】なお、これら契約ネットプロトコルやエー
ジェントの移動を具体的にどの時点で行い、その結果を
どのように使うかは、どのようなときにどのように再プ
ランニングを行うかといった具体的な構成や情報処理の
内容などに応じて異なることも考えられるが、例えば次
のような例が考えられる。

【０１１５】この例は、移動の条件を満たしても一律に
移動とはせず、移動を使うプランと協調を使うプランを
両方作って比較し、有利な方を実行するものである。こ
のような場合は、まず、ステップ３０７の契約ネットプ
ロトコル手続きを使ってゴールの達成を試みるプランを
作成し、次に、不確実知識を確認できるプラットフォー
ムに対しステップ３０８のエージェント移動手続きを使
って移動することでゴールを達成するプランを作る。そ
して、このように作ったプラン同士を、必要なデータの
量や通信の量などをコストと考えて評価し、コストの最
も低い有利なものを選択し、実行する。なお、実行失敗
時には再プランニングとして以上のプランニング手順を
繰り返す。

【０１１６】〔２−１０．移動時の例外への対応〕ま
た、この実施形態では、プラットフォーム間でエージェ
ントを移動させようとするとき、エラーなどの例外が発
生しても、対処部１４が例外記述５４に基づいて例外へ
の対処を行う。例えば、移動元のプラットフォームから
移動先のプラットフォームに対して、移動手続きの実行
通知を送信している最中に、移動先からの応答がなくな
り、タイムアウトが発生する場合を考える。

【０１１７】すなわち、移動に使おうとしている通信回
線の信頼性が低い場合、移動元のプラットフォームで
は、タイムアウト検知部１５がタイムアウトを検知して
対処部１４に知らせ、対処部１４は、図５に示したよう
な例外記述５４にしたがって、次のように対処する。

【０１１８】すなわち、対処部１４は、移動元のプラッ
トフォームの移動部１２を一旦待ち状態に移行させたう
え、予め決められた待ち時間が経過するごとに移動先へ
の通知を再試行させる。この再試行で、反応が途絶える
ことなく移動先の計算機に通知が届けば、移動部１２は
通常の移動手続きを続行する。その後また反応途絶が発
生すれば、再び移動待ち状態に移行し、上に述べたよう
に、待ち時間後の再試行を繰り返す。

【０１１９】〔２−１１．エージェント間での情報交
換〕また、契約ネットプロトコルによるタスクの依頼な
ど、エージェント間で協調動作を行なう場合、あるエー
ジェントが他のエージェントの振る舞いを制御すること
によって、予期せぬ状況変化に柔軟に対応することが望
ましい。この実施の形態では、図８に示した階層的な黒
板部８と、黒板管理部９とを次にように使って、このよ
うな柔軟な対応を実現する。

【０１２０】すなわち、個々のエージェントは、黒板部
８のどれか１つの階層に、エージェントの優先度に応じ
て対応付けられていて、図８の例では、エージェントの
７０２と７０３のどちらも、黒板部８の下位階層に対応
付けられているものとする。そして、他のエージェント
に送る通常の情報は、自分の優先度と同じ階層に記入し
ておくと、受け取る側のエージェントは、処理の区切り
がついたときなどに黒板部８の下位階層を参照し、自分
宛のメッセージを発見して受け取る。

【０１２１】一方、エージェントが、自分に設定された
優先度に本来対応する階層よりも高い階層、すなわち上
位階層へデータを記入すると、そのような記入は黒板管
理部９が検出し、情報の宛先になっているエージェント
にハードウェア割り込みなどで情報を通知する。このよ
うに、この実施の形態では、黒板部８が階層的に構成さ
れ、優先度の高い上位の階層に記入した情報の方が下位
の階層に記入された情報よりも優先的に処理される。

【０１２２】このため、エージェント間で交換する情報
を重要度に応じた階層に記入することによって、エージ
ェント間の協調関係を柔軟に制御できるので、予期せぬ
状況の変化に対応することが容易になる。また、エージ
ェント単位に優先度を設定しておき、優先度が高いエー
ジェントが交換する情報ほど高い階層を用いたり、情報
を黒板部８に入出力する処理も高い階層ほど優先して行
なえば、一層きめ細かな制御も可能となる。

【０１２３】〔３．情報処理の例〕続いて、上に述べた
ようなこの実施形態の動作によって、図２で説明した具
体的な問題を処理する例を示す。

【０１２４】〔３−１．要求の入力と最初のプランニン
グ〕すなわち、上に述べたようなゴールplan_and_reser
ve_tickets(...) に基づいて最初にプランニングが行わ
れる段階では、ゴールはまだ満足されていないので、プ
ランニング部２は、ゴールを満足する動作を知識管理部
６に問い合わせる。しかし、携帯計算機１０１には、要
求の入力を受け付ける構成はあったが、ゴールを達成す
るために必要なチケットの予約手順がないものとする。

【０１２５】この場合、知識管理部６は、知識格納部５
内のプランニング用知識５１を検索した結果、ゴールを
満足するために十分な動作がないと判断する。そこで、
知識管理部６は、不確実知識である maybe(plan_and_reserve_tickets(Requirements),ta) を利用してゴールを満足できるかもしれないことをプラ
ンニング部２に伝える。

【０１２６】この不確実知識は、チケットの予約手順は
旅行代理店１０２すなわちノードｔａにあるかもしれな
いという内容であり、プランニング部２は、この不確実
知識を使ったプランを生成する。この時点でのゴールと
不確実知識との関係を図１５の概念図に示す。なお、図
１５において、Ｋ１〜Ｋ５のような確定している知識は
実線の図形で表わし、Ｍ１のような不確実知識は破線の
図形で表わす。

【０１２７】〔３−２．旅行代理店への移動〕エージェ
ント管理部１は、この不確実知識が確認できる目的のプ
ラットフォームであるノードｔａが、どのような回線で
接続されていて、また、エージェントｕｓｅｒ及びノー
ドｔａがモバイルをサポートしているかどうかを知識管
理部６に問い合わせる。

【０１２８】この場合、知識管理部６は、知識格納部５
の例外記述５４に記述されている回線の信頼性に関する
情報を参照し、携帯計算機１０１が、ノードｔａに信頼
性の低い無線回線Ｃ１で接続されていることが判明する
ため（図６）、その旨を知らせるmobile_connection(t
a) といった形式の情報をエージェント管理部１に返
信する。

【０１２９】また、同じように、エージェント管理部１
は、知識格納部５に格納されたプラットフォームプロフ
ァイル５２とエージェント属性５３に基づいて、エージ
ェントｕｓｅｒとノードｔａの両方がモバイルをサポー
トしていることを確認する。

【０１３０】この場合、エージェント管理部１が、エー
ジェントを移動させるための３つの条件 （１）エージェントが現在いるプラットフォームと目的
のプラットフォームとを結ぶ通信回線の信頼性が低いこ
と （２）目的のプラットフォームがモバイルをサポートし
ていること （３）エージェントの属性がモバイルであること が満たされることを確認する結果、プランニング部２が
ノードｔａに移動するプランを生成し、このプランにし
たがって移動部１２がエージェントｕｓｅｒをノードｔ
ａに移動させる。

【０１３１】〔３−３．予約手順に基づくプランニン
グ〕ノードｔａでは、不確実知識の指していた予約手順
が発見され、不確実知識Ｍ１は、図１６に示すように、
確定した知識Ｋ６となる。このため、エージェントは、
この知識Ｋ６の指す予約手順を使って、ゴールresolve_
goal(plan_and_reserve_tickets(...)を満たすために再
プランニングを行う。その結果、次のようなプランが生
成される。 retrieve_route(departure_place(tokyo),arrival_plac
e(a_university)); retrieve_tt; reserve_tickets; このプランは、図１６に示すように、経路を決める処理
Ｐ１と、交通機関を予約する処理Ｐ２１によって、ゴー
ルである予約完了が実現できるというプランである。次
に、実行部３はこのプランの実行に移る。

【０１３２】〔３−４．移動による経路の検索〕この実
行では、まず、動作 retrieve_route(departure_place(tokyo),arrival_plac
e(a_university)) を実行する。この動作は、図１６の処理Ｐ１であり、出
発地東京および到着地地方大学という条件で旅行経路を
検索する動作である。しかし、ノードｔａには地方大学
への経路に関するデータベースが存在しないため、プラ
ン実行失敗と判断される。

【０１３３】そこで、プラン実行失敗の原因となった動
作 retrieve_route(departure_place(tokyo),arrival_plac
e(a_university)) の事前条件 exists(routeDB(tokyo,a_university)) をゴールとして再プランニングを行う。この事前条件
は、経路のデータベース（ＤＢ）が存在していることを
意味する。その結果、この事前条件は、不確実知識 maybe(exists(routeDB(tokyo,a_university),a_tourist
_bureau_site)) により達成可能であることが、知識管理部６より知らさ
れて判明する（図１６）。

【０１３４】この不確実知識Ｍ２は、経路のデータベー
スは観光局１０５にあるかも知れないという内容であ
る。この不確実知識についてエージェント管理部１が分
類を行うときは、エージェントの現在地であるノードｔ
ａからみて、目的のプラットフォームである a_tourist_bureau_site すなわち、観光局１０５がやはり信頼性の低い回線で接
続されていることが分かる。また、エージェントｕｓｅ
ｒはすでに述べたようにモバイルをサポートしていて、
さらに、この目的のプラットフォームである観光局１０
５もモバイルをサポートしている（図３）。

【０１３５】このため、この不確実知識も、移動によっ
て確認すべきと判断され、プランニング部２は、エージ
ェントが観光局１０５に移動後検索を行い、再び旅行代
理店１０２に戻るプランを作成し実行する。今回は、観
光局１０５に存在するデータベースから次の情報を検索
するという処理Ｐ１に成功し、図１７に示すように、不
確実知識Ｍ２は確定した知識Ｋ７となる。 route([tokyo,city1],[city1,a_university]) route([tokyo,city2],[city2,a_university]) これらの情報は、東京から地方大学に行くには、ｃｉｔ
ｙ１を経由する経路と、ｃｉｔｙ２を経由する経路があ
ることを意味する。以下、これらの都市はそれぞれ都市
１および都市２と呼ぶ。

【０１３６】なお、この例のように利用交通機関を指定
した経路の検索では、指定された交通機関、すなわちこ
こでは航空機を含んだ経路が検索される。この場合は、
例えば東京から都市１への部分が航空機、残りの部分は
バスだったものと仮定する。なお、説明を簡単にするた
め、都市２を経由する経路については省略し、次に述べ
る時刻表データベースに関する処理については図示しな
い。

【０１３７】〔３−５．時刻表の入手〕このように経路
の検索に成功すると、エージェントｕｓｅｒは旅行代理
店１０２であるノードｔａに戻り、続いて、図示はしな
いが、検索された経路に対応する時刻表を手に入れる動
作retrieve_tt を実行しようとする。このとき、この動
作も都市１から地方大学への交通機関の時刻表データベ
ースがノードｔａに存在しないため失敗し、再プランニ
ングとなる。その結果、やはり地方の観光局１０５にデ
ータベースが存在するという不確実知識を得、上記と同
様の移動・再プランニングとなる。

【０１３８】ただ今回は、移動先の観光局１０５にもデ
ータベースが存在しないとする。その場合、やはり観光
局１０５において再プランニングを行い、今度は地方大
学１０６にデータベースが存在するという不確実知識を
使ったプランが生成される。この不確実知識について
は、地方大学１０６がモバイルをサポートしていないこ
とから（図３）、協調によって確認すべきと決定され
る。この結果、エージェントｕｓｅｒは、地方大学１０
６のエージェントとの協調によって、都市１から地方大
学への交通機関（バス）の時刻表を検索する。

【０１３９】〔３−６．協調による航空機の予約〕次
に、エージェントｕｓｅｒは、reserve_tickets を実行
しようとする。この場合、ここまでの処理によって、図
１７に示すように、予約は航空機（Ｐ２）とバス（Ｐ
３）の両方について行うことになっているものとする。
このうち、まず、航空機の予約に必要な予約受付データ
ベース（チケットデータベース）がノードｔａに存在し
ないため、再プランニングを行い、その結果、２つの航
空会社ａｉｒｌｉｎｅ１、ａｉｒｌｉｎｅ２（以下、そ
れぞれ航空会社１、２とする）に存在するとの不確実知
識Ｍ４を得る。

【０１４０】ここで、この２つの会社の計算機とは、信
頼性の高い回線で接続されているとの知識も得られるた
め、エージェントの移動ではなく、今回は契約ネットプ
ロトコル手続きを実行する。この契約ネットプロトコル
では、エージェントｕｓｅｒは、２つの航空会社社１，
２（１０３，１０４）の計算機上のエージェントに、次
のようなタスクアナウンスメッセージを送信する。

【０１４１】task_announce(plan(ticket_reserved(tok
yo,city1)),cost(price)) このタスクアナウンスメッセージは、東京から都市１ま
でのチケット予約について、値段を評価の基準として入
札されたし、という意味である。

【０１４２】このタスクアナウンスメッセージを受信し
た航空会社の各エージェントは、ゴール ticket_reserved(tokyo,city1) に対しプランニングを行い、その結果、それぞれプラン reserve_ticket(tokyo,city1) を作成する。次に各航空会社１，２のエージェントは、
作成したプランについてコストを計算する。ここで計算
するコストは、タスクアナウンスメッセージに含まれた
ｐｒｉｃｅ、すなわち、チケットの値段とする。その結
果、航空会社１、２のチケットの値段がそれぞれ２００
００円、および２３０００円であったとする。

【０１４３】この場合、各航空会社１，２のエージェン
トは、以上の結果をそれぞれ以下のような入札メッセー
ジを、旅行代理店１０２で動作中のエージェントに返信
する。

【０１４４】bid(bidder(airline1_ag1),reserve_ticke
t(tokyo,city1),cost(20000)) bid(bidder(airline2_ag1),reserve_ticket(tokyo,city
1),cost(23000)) この入札メッセージを受信したエージェントｕｓｅｒ
は、入札にあるコストを比較し、小さい方を選択する。
すなわち、ここでは航空会社１のエージェントairline1
_ag1を落札エージェントとして選択する。そして、エー
ジェントｕｓｅｒは、選択した航空会社１の落札エージ
ェントairline1_ag1に対しては、落札を表わすnockdown
メッセージを送信し、選択しなかった航空会社２のエー
ジェントairline2_ag1に対しては、落札しなかったこと
を表わすno_nockdown メッセージを送信する。

【０１４５】〔３−７．バスの予約〕このようにして、
航空機を予約する処理Ｐ２が終了すると、エージェント
ｕｓｅｒは、次に、最終ゴールである resolve_goal(plan_and_reserve_tickets(...)) にとって必要なもう１つの処理、すなわちバスを予約す
る処理Ｐ３を行う。

【０１４６】バスを予約する処理Ｐ３は、事前条件とし
てバスの予約受付データベース（ＤＢ）の存在を必要と
する。この予約受付データベースは、エージェントｕｓ
ｅｒの現在地であるノードｔａには存在しないので、実
行失敗に続いて再プランニングが行われる結果、バスの
予約受付データベースは観光局１０５にあるという不確
実知識を使ったプランが得られる。

【０１４７】観光局１０５は、上に述べたように移動の
条件を満たすのでエージェントｕｓｅｒは観光局１０５
に移動してバスの予約受付データベースを探すが発見で
きず、次に、バスの予約受付データベースは地方大学１
０６にあるという不確実知識を使ったプランが得られ
る。

【０１４８】このとき、地方大学１０６は、モバイルを
サポートしていないので、契約ネットプロトコルによっ
てバスを予約する処理Ｐ３を行い、これによって予約完
了という最終ゴールが達成される。なお、最初の不確実
知識から最終ゴールに至る全体的な流れの概略を図１８
に示す。

【０１４９】〔４．効果〕以上説明したように、この実
施形態では、個々のプラットフォームが移動型のモバイ
ルエージェントをサポートしているかどうかの情報をプ
ラットフォームプロファイル５２として用意しておく。
そして、エージェントが他のプラットフォームの資源を
使うとき、そのエージェントを当該他のプラットフォー
ムへ移動させるか、そのエージェントから当該他のプラ
ットフォームのエージェントに処理を依頼させる（協
調）かは、このプラットフォームプロファイル５２に基
づいて容易に決めることができる。

【０１５０】例えば、エージェントが他のプラットフォ
ームの資源を使うとき、そのプラットフォームとの間の
回線の信頼性が低ければ、そのプラットフォームに移動
することが望ましいが、そのプラットフォームがモバイ
ルエージェントをサポートしていないことをプラットフ
ォームプロファイル５２から予め判断することで、移動
を試すまでもなく、そのプラットフォームのエージェン
トと協調を行うべきだと判断できる。なお、複数のエー
ジェント間で協調を行うには、従来から知られているエ
ージェント間協調の技術、例えば契約ネットプロトコル
や、黒板機能などを使っている。

【０１５１】また、この実施形態では、エージェントご
とに、プラットフォーム間で移動する能力を持つモバイ
ルエージェントか、移動する能力を持たないステーショ
ナリエージェントかの情報をエージェント属性５３とし
て用意しておく。そして、エージェントが他のプラット
フォームの資源を使うとき、そのエージェントを当該他
のプラットフォームへ移動させるか、そのエージェント
から当該他のプラットフォームのエージェントに処理を
依頼させる（協調）かは、このエージェント属性に基づ
いて容易に決めることができる。

【０１５２】特に、この実施形態では、エージェントが
他のプラットフォームの資源を使うとき、移動か協調か
は、上に述べたようなプラットフォームプロファイル５
２とエージェント属性５３の両方に基づいて決める。例
えば、そのエージェントとプラットフォームの両方が移
動をサポートしていればエージェントを移動させるが、
どちらか一方でもサポートしていなければ協調とする。
これによって、移動機能を持つモバイルエージェントと
ステーショナリエージェントの統合的活用が容易にな
る。

【０１５３】また、この実施形態では、プランニングに
よってネットワークの予期せぬ変化に柔軟に対応でき
る。そして、プランニングによってエージェントのプラ
ンが変わり、どのエージェントがどのプラットフォーム
の資源を使うことになっても、プラットフォームプロフ
ァイル５２やエージェント属性５３に基づいて移動か協
調かを容易に決めることができる。このように、移動と
協調とを使い分けることで、ネットワークという分散環
境でエージェントを使う情報処理が効率化される。ま
た、ネットワークの変化にもプランニングで対応しなが
ら、エージェントの移動と協調とを有効に結び付けて活
用するので、開放型ネットワークでも効果的に情報処理
を行うことができる。

【０１５４】また、この実施形態では、エージェントが
プラットフォーム間で移動しようとするときに移動失敗
などの例外が発生しても、そのような例外に適切に対応
することで情報処理が円滑に行われる。特に、この実施
形態では、移動時のどのような例外に対してどのように
対処するかは例外記述５４に表わしておき、例外記述を
書き換えることで対処の内容を容易に変更することがで
きる。

【０１５５】さらに、この実施形態では、移動のときに
よく起きがちな例外、すなわち移動先との通信の失敗、
移動先の指定が無効、移動先がモバイルエージェントに
対応していない、移動先での資源不足、のうち少なくと
も１つに対する対処を例外記述５４に表わしておくの
で、例外に効果的に対処することができる。

【０１５６】特に、この実施形態では、どの通信回線の
信頼性が低いかの情報を予め各プラットフォームなどに
用意しておき、エージェントがそのような回線を通して
移動しようとするときに通信が途絶したときの対応を決
めておく。これによって、通信回線の信頼性が低く、通
信が途絶しやすい場合でも動作不全や故障などが起きに
くくなる。

【０１５７】具体的には、この実施形態では、エージェ
ントを移動させるための通信が途絶えるとしばらく待っ
てから再び通信を試みる処理が繰り返される。このた
め、通信回線の信頼性が低くても、状態がよくなってい
る間にエージェントの情報を送ってエージェントを移動
させることができる可能性が高くなる。

【０１５８】さらに、この実施形態では、プランニング
に使う知識などプラットフォームの資源が情報処理の目
的や知識の適用分野などを基準に、フィールドごとに分
けて管理される。このため、あるフィールドのエージェ
ントは、自分の目的と関係ない知識まで参照する必要が
なく、効率的にプランニングをすることができる。

【０１５９】加えて、この実施形態では、ネットワーク
の予期せぬ変化のような急ぎの情報は、例えば、黒板の
上位階層に書き込むことで、エージェントの通常の動作
に割り込ませ、そのような変化に対応してエージェント
の動作を制御することができる。

【０１６０】〔５．他の実施形態〕なお、この発明は上
に述べた実施形態に限定されるものではなく、次に例示
するような他の実施形態をも含むものである。例えば、
この発明において、ネットワークの規模、形式、プラッ
トフォーム数などは自由であり、エージェントを用いて
行う情報処理の種類や、動作、知識、プランなどを記述
する言語の形式も自由に選択しうる。また、この発明は
チケット予約以外の課題に適用できることはもちろんで
ある。

【０１６１】また、図に示したプラットフォームプロフ
ァイル５２（図３）、エージェント属性５３（図４）、
例外記述５４（図５、図６）などの形式や内容は例示に
過ぎず、他の形式にしたり、それらの情報にどのような
項目を含めるかなどは自由に変更することができる。ま
た、例えば、例外記述をエージェント属性などと一緒
に、又はそのような情報に対応付けて格納しておくこと
もできる。また、同じように、通信回線の信頼性に関す
る情報は、例外記述の一部とせずに、独立した情報とし
て格納しておいてもよいし、プラットフォームプロファ
イルの一部としてもよい。

【０１６２】また、上に述べた実施形態では、プラット
フォームプロファイル、エージェント属性、例外記述な
どをプラットフォームごとの知識格納部に格納したが、
これらの情報は、エージェントが所有する情報として実
現し、エージェントが他のプラットフォームに移動のた
め転送されるときは、これらの情報がエージェントと一
緒に転送されるようにしてもよい。

【０１６３】また、上に述べた実施形態では、プランニ
ングを行うエージェントを主に例示したが、この発明
は、プランニングを行わないエージェントに適用するこ
ともできる。また、対処部、例外記述を含めた例外に対
応するための構成やタイムアウト検知部は必ずしも設け
る必要はなく、また、例外記述の内容も実施形態に示し
た実例にかかわらず、自由に定めることができる。

【０１６４】また、同じように、各プラットフォームに
は必ずしも複数のフィールドを設ける必要はなく、ま
た、黒板部や黒板管理部もこの発明にとって必須ではな
い。

【０１６５】

【発明の効果】以上のように、この発明によれば、モバ
イルエージェントとステーショナリエージェントとを状
況に応じて動的に使い分けることで円滑に情報を処理す
ることができる。

【図面の簡単な説明】

【図１】この発明の実施形態の構成を示す機能ブロック
図。

【図２】この発明の実施形態における問題の内容を示す
概念図。

【図３】この発明の実施形態におけるプラットフォーム
プロファイルの例を示す図。

【図４】この発明の実施形態におけるエージェント属性
の例を示す図。

【図５】この発明の実施形態における例外記述の例を示
す図。

【図６】この発明の実施形態における通信回線の信頼性
に関する情報の例を示す図。

【図７】この発明の実施形態におけるフィールドを示す
概念図。

【図８】この発明の実施形態における黒板部を示す概念
図。

【図９】この発明の実施形態における処理手順を示すフ
ローチャート。

【図１０】この発明の実施形態において、生成途中のプ
ランを示す概念図。

【図１１】この発明の実施形態において、完成したプラ
ンを示す概念図。

【図１２】この発明の実施形態におけるプラン生成の具
体的な手順を示すフローチャート。

【図１３】この発明の実施形態における契約ネットプロ
トコルの手順を示すフローチャート。

【図１４】この発明の実施形態において、エージェント
がプラットフォーム間で移動する手順を示すフローチャ
ート。

【図１５】この発明の実施形態における問題の例につい
て、ゴールを達成する途中経過を示す概念図。

【図１６】この発明の実施形態における問題の例につい
て、ゴールを達成する途中経過を示す概念図。

【図１７】この発明の実施形態における問題の例につい
て、ゴールを達成する途中経過を示す概念図。

【図１８】この発明の実施形態における問題の例につい
て、ゴールを達成する途中経過を示す概念図。

【図１９】従来のエージェントシステムの一例を示すブ
ロック図。

【図２０】プランニングを使う従来のエージェントシス
テムの例を示すブロック図。

【図２１】プランニングを使う従来のエージェントシス
テムにおける処理手順を示すフローチャート。

【図２２】プランニングを使う従来のエージェントシス
テムにおけるエージェントのライフサイクルを示す概念
図。

【符号の説明】

１…エージェント管理部 １１…協調部 １２…移動部 １３…決定部 １４…対処部 １５…タイムアウト検知部 ２…プランニング部 ３…実行部 ４…エージェント情報格納部 ５…知識格納部 ５１…プランニング用知識 ５２…プラットホームプロファイル ５３…エージェント属性 ５４…例外記述 ６…知識管理部 ７…フィールド管理部 ８…黒板部 ９…黒板管理部 ２０…入出力部 Ｌ…ローカルマシン Ｒ…リモートマシン Ｎ…ネットワーク Ｃ…条件 Ｐ…動作 Ｓ…状態 ８００Ｎ…ネットワーク ８００Ｌ…ローカルノード ８００Ｒ…リモートノード ８０１…エージェント情報記憶手段 ８０２…解釈実行手段 ８０３…入出力手段 ８０４…エージェント管理手段 ＳＴＥＰ…手順の各ステップ

───────────────────────────────────────────────────── フロントページの続き (72)発明者 大須賀 昭彦 神奈川県川崎市幸区柳町70番地 株式会社 東芝柳町工場内

Claims (17)

【特許請求の範囲】
1. 【請求項１】 ネットワークで互いに接続された複数の
   プラットフォーム上でエージェントが情報処理を行う情
   報処理装置において、 エージェントが他のプラットフォームの資源を使うと
   き、そのエージェントを当該他のプラットフォームへ移
   動させる移動手段と、 エージェントが他のプラットフォームの資源を使うと
   き、そのエージェントから当該他のプラットフォームの
   エージェントに処理を依頼させる協調手段と、 個々のプラットフォームが移動されたエージェントを受
   け入れて活動させる手段を備えているかどうかを表わす
   プラットフォームプロファイルを格納する手段と、 エージェントが他のプラットフォームの資源を使うと
   き、前記プラットフォームプロファイルに基づいて、そ
   のエージェントを当該他のプラットフォームへ移動させ
   るか、そのエージェントから当該他のプラットフォーム
   のエージェントに処理を依頼させるかを決定する決定手
   段と、 を備えたことを特徴とする情報処理装置。
2. 【請求項２】 ネットワークで互いに接続された複数の
   プラットフォーム上でエージェントが情報処理を行う情
   報処理装置において、 エージェントが他のプラットフォームの資源を使うと
   き、そのエージェントを当該他のプラットフォームへ移
   動させる移動手段と、 エージェントが他のプラットフォームの資源を使うと
   き、そのエージェントから当該他のプラットフォームの
   エージェントに処理を依頼させる協調手段と、 個々のエージェントがプラットフォーム間で移動する能
   力を持つかどうかに関するエージェント属性を格納する
   手段と、 エージェントが他のプラットフォームの資源を使うと
   き、前記エージェント属性に基づいて、そのエージェン
   トを当該他のプラットフォームへ移動させるか、そのエ
   ージェントから当該他のプラットフォームのエージェン
   トに処理を依頼させるかを決定する決定手段と、 を備えたことを特徴とする情報処理装置。
3. 【請求項３】 ネットワークで互いに接続された複数の
   プラットフォーム上でエージェントが情報処理を行う情
   報処理装置において、 エージェントが他のプラットフォームの資源を使うと
   き、そのエージェントを当該他のプラットフォームへ移
   動させる移動手段と、 エージェントが他のプラットフォームの資源を使うと
   き、そのエージェントから当該他のプラットフォームの
   エージェントに処理を依頼させる協調手段と、 個々のプラットフォームが移動されたエージェントを受
   け入れて活動させる手段を備えているかどうかを表わす
   プラットフォームプロファイルを格納する手段と、 個々のエージェントがプラットフォーム間で移動する能
   力を持つかどうかに関するエージェント属性を格納する
   手段と、 エージェントが他のプラットフォームの資源を使うと
   き、前記プラットフォームプロファイル及び前記エージ
   ェント属性に基づいて、そのエージェントを当該他のプ
   ラットフォームへ移動させるか、そのエージェントから
   当該他のプラットフォームのエージェントに処理を依頼
   させるかを決定する決定手段と、 を備えたことを特徴とする情報処理装置。
4. 【請求項４】 ネットワークで互いに接続された複数の
   プラットフォーム上でエージェントが情報処理を行う情
   報処理装置において、 与えられた要求を満たすエージェントのプランを生成す
   るプランニング手段と、 生成されたプランを実行することでエージェントを動作
   させる実行手段と、 エージェントの動作に必要な情報を格納するためのエー
   ジェント情報格納手段と、 プラットフォーム上のエージェントに対して、他のプラ
   ットフォームに移動させ又は他のプラットフォームのエ
   ージェントに処理を依頼させることで他のプラットフォ
   ームの資源を使わせるエージェント管理手段と、 前記プランの生成、前記移動及び前記依頼に必要な知識
   を格納する知識格納手段と、 前記知識格納手段を管理する知識管理手段と、 エージェントが他のプラットフォームの資源を使うと
   き、そのエージェントを当該他のプラットフォームへ移
   動させる移動手段と、 エージェントが他のプラットフォームの資源を使うと
   き、そのエージェントから当該他のプラットフォームの
   エージェントに処理を依頼させる協調手段と、 個々のプラットフォームが移動されたエージェントを受
   け入れて活動させる手段を備えているかどうかを表わす
   プラットフォームプロファイルを格納する手段と、 個々のエージェントがプラットフォーム間で移動する能
   力を持つかどうかに関するエージェント属性を格納する
   手段と、 エージェントが他のプラットフォームの資源を使うと
   き、前記プラットフォームプロファイル及び前記エージ
   ェント属性に基づいて、そのエージェントを当該他のプ
   ラットフォームへ移動させるか、そのエージェントから
   当該他のプラットフォームのエージェントに処理を依頼
   させるかを決定する決定手段と、 を備えたことを特徴とする情報処理装置。
5. 【請求項５】 ネットワークで互いに接続された複数の
   プラットフォーム上でエージェントが情報処理を行う情
   報処理装置において、 エージェントがプラットフォーム間で移動しようとする
   ときの例外に対応するための例外対応手段を備えたこと
   を特徴とする請求項１から４のいずれか１つに記載の情
   報処理装置。
6. 【請求項６】 前記例外対応手段は、 どのような例外に対してどのように対処するかを表わす
   例外記述と、 前記例外記述に基づいて例外に対処する対処手段と、 を備えたことを特徴とする請求項５記載の情報処理装
   置。
7. 【請求項７】 前記例外記述は、（１）移動先として指
   定されたプラットフォームとの通信が失敗したためにエ
   ージェントが移動できない例外、（２）移動先の指定が
   無効であるためにエージェントが移動できない例外、
   （３）移動先として指定されたプラットフォームが移動
   されたエージェントを受け入れて活動させる手段を備え
   ていないためにエージェントが移動できない例外、
   （４）移動先として指定されたプラットフォームにおけ
   る資源不足のためにエージェントが移動できない例外、 のうち少なくとも１つについて、どのように対処するか
   を表わすことを特徴とする請求項６記載の情報処理装
   置。
8. 【請求項８】 前記例外記述は、 前記通信回線のうち信頼性の低い通信回線に関する情報
   と、 エージェントが前記信頼性の低い通信回線を通してプラ
   ットフォーム間で移動するときに発生する可能性がある
   例外に対してどのように対処するかを表わす情報と、 を含むことを特徴とする請求項６又は７記載の情報処理
   装置。
9. 【請求項９】 前記通信回線で一定時間反応が途絶して
   いることを検知するタイムアウト検知手段を備え、 前記例外対応手段は、前記信頼性の低い通信回線を通し
   てエージェントを移動させるための通信を行っていると
   きに、前記タイムアウト検知手段が前記途絶を検知した
   場合、予め決められた待ち時間の後で前記通信を再び試
   みる処理を繰り返すように構成されたことを特徴とする
   請求項８記載の情報処理装置。
10. 【請求項１０】 各プラットフォームは、異なった目的
    に対応する複数のフィールドを備え、 プラットフォームの持っている資源をフィールドごとに
    分けて管理するフィールド管理手段を備えたことを特徴
    とする請求項１から９のいずれか１つに記載の情報処理
    装置。
11. 【請求項１１】 複数のエージェントが情報をやり取り
    するための黒板手段と、 前記黒板手段を、情報の優先度に応じた複数の階層に分
    けて管理することで各エージェントを協調させるように
    制御する黒板管理手段と、 を備えたことを特徴とする請求項１から１０のいずれか
    １つに記載の情報処理装置。
12. 【請求項１２】 ネットワークで互いに接続された複数
    のプラットフォーム上でエージェントが情報処理を行う
    情報処理方法において、 エージェントが他のプラットフォームの資源を使うと
    き、そのエージェントを当該他のプラットフォームへ移
    動させるステップと、 エージェントが他のプラットフォームの資源を使うと
    き、そのエージェントから当該他のプラットフォームの
    エージェントに処理を依頼させるステップと、 個々のプラットフォームが移動されたエージェントを受
    け入れて活動させる手段を備えているかどうかを表わす
    プラットフォームプロファイルと、個々のエージェント
    がプラットフォーム間で移動する能力を持つかどうかに
    関するエージェント属性に基づいて、 エージェントが他のプラットフォームの資源を使うと
    き、そのエージェントを当該他のプラットフォームへ移
    動させるか、そのエージェントから当該他のプラットフ
    ォームのエージェントに処理を依頼させるかを決定する
    ステップと、 を含むことを特徴とする情報処理方法。
13. 【請求項１３】 ネットワークで互いに接続された複数
    のプラットフォーム上でエージェントが情報処理を行う
    情報処理方法において、 与えられた要求を満たすエージェントのプランを生成す
    るステップと、 生成されたプランを実行することでエージェントを動作
    させるステップと、 エージェントの動作に必要な情報を格納し及び読み出す
    ステップと、 プラットフォーム上のエージェントに対して、他のプラ
    ットフォームに移動させ又は他のプラットフォームのエ
    ージェントに処理を依頼させることで他のプラットフォ
    ームの資源を使わせるステップと、 前記プランの生成、前記移動及び前記依頼に必要な知識
    を格納し及び読み出すステップと、 前記知識格納手段を管理するステップと、 エージェントが他のプラットフォームの資源を使うと
    き、そのエージェントを当該他のプラットフォームへ移
    動させるステップと、 エージェントが他のプラットフォームの資源を使うと
    き、そのエージェントから当該他のプラットフォームの
    エージェントに処理を依頼させるステップと、 個々のプラットフォームが移動されたエージェントを受
    け入れて活動させる手段を備えているかどうかを表わす
    プラットフォームプロファイルと、個々のエージェント
    がプラットフォーム間で移動する能力を持つかどうかに
    関するエージェント属性とに基づいて、 エージェントが他のプラットフォームの資源を使うと
    き、そのエージェントを当該他のプラットフォームへ移
    動させるか、そのエージェントから当該他のプラットフ
    ォームのエージェントに処理を依頼させるかを決定する
    ステップと、 を含むことを特徴とする情報処理方法。
14. 【請求項１４】 ネットワークで互いに接続された複数
    のプラットフォーム上でエージェントが情報処理を行う
    情報処理方法において、 エージェントがプラットフォーム間で移動しようとする
    ときの例外に対応するためのステップを含むことを特徴
    とする請求項１２又は１３に記載の情報処理方法。
15. 【請求項１５】 ネットワークで互いに接続された複数
    のプラットフォーム上でエージェントが情報処理を行う
    情報処理方法において、 どのような例外に対してどのように対処するかを表わす
    例外記述に基づいて例外に対処するステップを含み、 前記例外記述は、 前記通信回線のうち信頼性の低い通信回線に関する情報
    と、 エージェントが前記信頼性の低い通信回線を通してプラ
    ットフォーム間で移動するときに発生する可能性がある
    例外に対してどのように対処するかを表わす情報と、 を含むことを特徴とする情報処理方法。
16. 【請求項１６】 前記通信回線で一定時間反応が途絶し
    ていることを検知するステップと、 前記信頼性の低い通信回線を通してエージェントを移動
    させるための通信を行っているときに前記途絶が検知さ
    れた場合、予め決められた待ち時間の後で前記通信を再
    び試みる処理を繰り返すことを特徴とする請求項１５記
    載の情報処理方法。
17. 【請求項１７】 コンピュータを使って、ネットワーク
    で互いに接続された複数のプラットフォーム上でエージ
    ェントに情報処理を行わせる情報処理用プログラムを記
    録した記録媒体において、 そのプログラムは前記コンピュータに、 エージェントが他のプラットフォームの資源を使うと
    き、そのエージェントを当該他のプラットフォームへ移
    動させ、 エージェントが他のプラットフォームの資源を使うと
    き、そのエージェントから当該他のプラットフォームの
    エージェントに処理を依頼させ、 個々のプラットフォームが移動されたエージェントを受
    け入れて活動させる手段を備えているかどうかを表わす
    プラットフォームプロファイルを格納させ、 個々のエージェントがプラットフォーム間で移動する能
    力を持つかどうかに関するエージェント属性を格納さ
    せ、 エージェントが他のプラットフォームの資源を使うと
    き、前記プラットフォームプロファイル及びエージェン
    ト属性に基づいて、そのエージェントを当該他のプラッ
    トフォームへ移動させるか、そのエージェントから当該
    他のプラットフォームのエージェントに処理を依頼させ
    るかを決定させることを特徴とする情報処理用プログラ
    ムを記録した記録媒体。