JP3688462B2 - 情報処理装置及び方法並びに情報処理用プログラムを記録した記録媒体 - Google Patents
情報処理装置及び方法並びに情報処理用プログラムを記録した記録媒体 Download PDFInfo
- Publication number
- JP3688462B2 JP3688462B2 JP10154998A JP10154998A JP3688462B2 JP 3688462 B2 JP3688462 B2 JP 3688462B2 JP 10154998 A JP10154998 A JP 10154998A JP 10154998 A JP10154998 A JP 10154998A JP 3688462 B2 JP3688462 B2 JP 3688462B2
- Authority
- JP
- Japan
- Prior art keywords
- agent
- platform
- platforms
- information processing
- exception
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Images
Landscapes
- Computer And Data Communications (AREA)
Description
【０００１】
【発明の属する技術分野】
この発明は、ネットワーク上に分散する情報をエージェントを使って処理する技術の改良にかかわるもので、より具体的には、モバイルエージェントとステーショナリエージェントとを状況に応じて動的に使い分けることで円滑に情報を処理するようにしたものである。
【０００２】
【従来の技術】
〔エージェントシステム〕
従来から、コンピュータのネットワーク上に分散した情報を処理する技術として、エージェントシステムが知られている。エージェントとは、ソフトウェア上の処理単位であり、周囲の状況に応じて自律的に動作するものである。このエージェントは、ネットワークを構成するノード間で移動する能力を持つモバイルエージェントと、そのような移動の能力を持たないステーショナリエージェントに分けることができる。
【０００３】
エージェントシステムは、このようなエージェントが利用者の要求を満たすために情報処理を行うシステムであり、特に、１つのシステム上で複数のエージェントを使えば、ネットワークのような分散システムでの情報処理を一層効率的に行うことができる。このように複数のエージェントを使うシステムはマルチエージェントシステムと呼ばれる。
【０００４】
エージェントのうち、モバイルエージェントは、ネットワークを構成するノード上を必要に応じて移動することで情報収集などの処理を行い、ステーショナリエージェントは、契約ネットプロトコルなどの手続きを使って他のエージェントと協力することで情報処理を行う。なお、ノードとは、ネットワークを構成する論理的な単位であり、エージェントをプログラムとしてとらえた場合、エージェントの動作を支えるインタプリタやオペレーティングシステムの役割を果たす。このようなノードはプラットフォームとも呼び、一つのマシンすなわちコンピュータ上に複数存在し得る。
【０００５】
〔エージェントシステムの例〕
次に、このようなエージェントシステムの一例を示す。すなわち、図１９は、モバイルエージェントを使ったマルチエージェントシステムの一例として、本出願人が特願平９−１７６１８１で提案しているエージェントシステムの構成例を示す機能ブロック図である。この図に示すエージェントシステムは、複数のノード８００をネットワーク８００Ｎで接続したものであり、ノード８００はシステム上に多数設けることができるが、図１５では２つのノードを代表例として示している。そして、ノード８００のうち、利用者がエージェント生成に使用するノードをローカルノード（８００Ｌ）と呼び、生成されたエージェントが移動して行く先のノードをリモートノード（８００Ｒ）と呼ぶ。
【０００６】
このエージェントシステムにおいて、各ノード８００は、利用者がエージェントを生成する操作を行なったり、エージェントが情報処理を行なった結果を受け取るための入出力手段８０３（Ｌ，Ｒ）を有する。また、各ノードのエージェント管理手段８０４（Ｌ，Ｒ）は、エージェントを生成したり、役割を終えたエージェントを消去する他、エージェントの情報を他のノードへ転送することによって、エージェントを他のノードへ移動させたり、他のノードから同様に移動してくるエージェントを受け入れる手段である。
【０００７】
利用者は、このようなエージェントシステムを用いて何らかの情報処理を行ないたい場合、ローカルノード８００Ｌにおいて、入出力手段８０３Ｌからエージェント管理手段８０４Ｌに指示を与えることによってエージェントを生成させる。
【０００８】
そして、最も基本的な例を示せば、生成されたエージェントに対して、利用者が入出力手段８０３Ｌからスクリプトを与える。スクリプトは、エージェントの行動プログラムであり、どのノードへ移動し、どのような処理を行う、といった内容を具体的に記述したものである。スクリプトのより具体的な例としては、例えば、ノードＡに移動してファイルａのコピーを利用者のノードに送信し、次にノードＢに移動してファイルｂのコピーを利用者のノードに送信し…といった内容が考えられる。そして、各ノードに備えられた解釈実行手段８０２（Ｌ，Ｒ）は、このようなスクリプトを実行することによってエージェントを活動させ、これによって目的とする情報処理を実現する。
【０００９】
この場合、各ノードに備えられたエージェント情報記憶手段８０１（Ｌ，Ｒ）が、エージェントに必要な情報を記憶する。エージェントに必要な情報は、例えば、前記のスクリプトのほか、スクリプトの解釈実行に必要な各変数（スクリプト変数と呼ばれる）や、必要な場合は、エージェントが収集した情報やファイルなどである。また、エージェントのスクリプトに記述される命令としては、一つのノード上だけで実行できる命令のほか、エージェントを他のノードへ移動させるための移動命令がある。解釈実行手段８０２Ｌは、スクリプトの命令を順次実行し、移動命令の実行が必要になった場合には、移動先のノードを指定して、エージェントの移動をエージェント管理手段８０４に依頼する。
【００１０】
このようなエージェントシステムでは、利用者が、いくつかのファイルをネットワーク上から収集したいような場合、この目的を達成するための行動プログラムをエージェントに持たせてネットワーク上に送り出せばよく、送り出されたエージェントは、与えられたスクリプトに基づいて自律的に活動する。このため、利用者のノードとエージェントとの間で通信を始終維持する必要はないことから、ｆｔｐやｔｅｌｎｅｔといった従来のネットワーク機能と比べて回線障害に強いという利点がある。
【００１１】
〔プランニングを用いる構成例〕
図１９に示したエージェントシステムに対して、エージェントの行動プログラムであるスクリプトを、状況に応じて変化させることができるエージェントシステムも知られている。
【００１２】
すなわち、近年のようにネットワークが大規模化・複雑化し、特に、インターネットのような広域ネットワークと接続されることによっていわゆる開放型ネットワークになると、ファイルの所在などのようなネットワークの構成要素がしばしば変化するようになる。ところが、図１９に示した上記のようなエージェントシステムでは、エージェントは生成される時点で固定されたスクリプトを与えられるため、状況に応じて行動を変更することができない。そこで、このような変化に柔軟に対応するため、人手を煩わせずにエージェントの行動を自動的に変化させる技術として、本出願人は、プランニング機能を持ったエージェントシステムを出願している。
【００１３】
この技術では、エージェントの行動プログラムはプランと呼び、プランを生成することをプランニングと呼ぶ。そして、この技術では、状況に応じてプランを適宜作り直すことによって、ネットワークの構成要素の変化に対応する。なお、ネットワークの構成などの変化に対応したり、プランの実行が失敗したためにプランニングを再度やり直すことを再プランニングと呼ぶ。
【００１４】
このようなエージェントシステムの構成例を図２０の機能ブロック図に示す。この技術において、プランの生成に用いる情報としては、「知識」と呼ばれる情報とアクション定義とが挙げられる。このうち「知識」は、エージェントの動作、特にプランニングに利用する各種の情報であり、その一例として、どのファイルがどのノードに存在するかといったネットワークの構成要素に関する情報を含む。例えば図２０の例では、このようなネットワークの構成に関する知識を、ローカル情報記憶手段１Ｌに保存しておき、ネットワークの構成に変化があったときは、更新手段２Ｌが、自動検出や手作業などによって、このような変化を知識に反映させる。また、アクション定義とは、プランを構成する部品として、どのような種類の命令（アクション）が使えるかを表す情報であり、エージェント情報記憶手段３に格納しておく。
【００１５】
このようなエージェントシステムでは、エージェントの生成を指示する利用者は、スクリプトの代わりに、達成したいゴールをノードに与える。ここで、ゴールとは、情報処理の目的として達成したい状態を、予め定められた文法で記述したものである。すると、プラン生成手段５は、与えられた知識を参照しながら、アクション定義に含まれる各種のアクションを組み合わせることによって、ゴールを達成するためのプランを生成する。このようなエージェントシステムでは、ネットワークの構成の変化は、プランニングや再プランニングの際に、知識を介してエージェントのプランに反映されるので、エージェントは人手を介さずに状況の変化に対応し柔軟に行動を変化させることができる。
【００１６】
なお、このようなプランを生成する手段は「プランナ」とも呼ばれ、その実体はプランニングの手続きを表すプログラムの一種である。また、エージェントの行動プログラムやその各部分を呼ぶ広義の概念がスクリプトであり、プランというときは、特に、図２０に示したようなプランニングを行うエージェントによって生成されたスクリプトの全体を指す。
【００１７】
〔プランを使った動作の例〕
続いて、上に述べたようなプランニングを用いたエージェントシステムの具体的な動作手順を図２１に例示する。この手順では、利用者が、情報処理のゴールとしてエージェントに対する要求の記述（要求記述）を入力すると（ステップ２０１）、必要な初期化が行なわれた後（ステップ２０２）、プランが生成される（ステップ２０３）。なお、処理は、ゴールが既に達成されているなど終了条件の判定結果に応じて終了する（ステップ２０４，２０５）。
【００１８】
すなわち、このような終了条件が満たされるまでは（ステップ２０４）、ゴールを達成するために実行を要するプランの実行が行われる。プランの実行では、プランに含まれる各命令を順次実行し（ステップ２０６，２０８）、実行する命令が移動命令の場合には（ステップ２０７）エージェントをノード間で移動させる処理（goアクションと呼ばれる）が実行される（ステップ２０８）。また、各命令の実行やgoアクションの実行に失敗した場合は、必要に応じて新たなプランを生成する（ステップ２０３）。
【００１９】
〔エージェントのライフサイクル〕
次に、以上のようにプランニングを行うエージェントのライフサイクルを示す概念図を図２２に示す。すなわち、エージェントは、ゴール投入と共に生成されて活動を開始すると、まず、プランを生成するプランニングフェーズＰから開始し、生成されたプランにしたがい、プランを実行する実行フェーズＥやノード間で移動する移動フェーズＭに移行し、実行や移動の失敗に応じてこれらの各フェーズ間を移行しながら活動する。そして、当初与えられたゴールを達成すれば正常終了となり、ゴールが達成できずにプランニング自体にも失敗すると完全失敗となって終了する。
【００２０】
【発明が解決しようとする課題】
ところで、複雑なネットワークや大規模なネットワークでは、１つのシステム上にモバイルエージェントとステーショナリエージェントの両方があったり、１つのエージェントが、モバイルエージェントとして移動する機能と、ステーショナリエージェントと同じように他のエージェントと契約ネットプロトコルなどで協調する機能を、両方持っている場合も考えられる。
【００２１】
このような場合、モバイルエージェントとステーショナリエージェントとの統合的活用が重要になる。つまり、あるノードでエージェントが動作する際に、他のノードに固有のファイルやソフトウェアなどの資源を使うことがしばしば必要になる。そして、このようにエージェントが他のノードの資源を使うには、エージェント自身が他のノードへ移動するか、他のノードのエージェントに仕事を頼む必要がある。このように、あるノードにいるエージェントから、他のノードにいるエージェントに仕事を頼むことを協調と呼ぶ。
【００２２】
さらに、このように移動と協調とが可能な場合、ある条件では自分がモバイルエージェントとしてそのノードに移動して行くほうがよいが、別の条件ではそのノードにいるステーショナリエージェントに処理を依頼して協調するほうがよい、といった場合が多い。従来では、プランに基づいて他のノードの資源を利用するために移動と協調とが考えられる場合、移動と協調のうちどちらを行うかを、プラン中の動作列としてあらかじめ規定しておく必要があった。
【００２３】
しかし、このような決定は、通信回線の性質やノードの性質などに応じて動的に行う必要があることが多い。ここで、通信回線の性質としては、例えば信頼性や通信帯域などが考えられ、信頼性の低い回線で接続されているノードの資源を使おうとするときは、協調よりも移動のほうが望ましい。つまり、協調では、そのノードと通信を維持する必要があるが、信頼性の低い回線を通しての通信は途絶えやすく、このように通信が途絶えると協調の処理が中断されるからである。これに対して、エージェント自身がそのノードに移動してしまえば、移動の時に通った回線が切断されていても移動先での処理には差し支えがなく、処理が終了した後で、回線の状態が回復したときに元のノードに戻るなどすれば足りるからである。
【００２４】
また、ノードの性質としては、例えばモバイルエージェントをサポートしているかどうか、などが考えられる。つまり、エージェントに移動する機能があっても、移動先のノードが、エージェントの情報を受け入れて活動させる手段を持っていなければそのノードでエージェントが処理を続けることはできない。
【００２５】
さらに、利用したいノードとの間の通信回線の信頼性が低くても、全てのノードを移動させればよいわけではなく、エージェント自身が他のノードに移動する機能を持ったモバイルエージェントでなければ、移動は不可能であり、協調を選ぶべきである。このように、従来では、モバイルエージェントとステーショナリエージェントとを状況に応じて動的に使い分けることで円滑に情報を処理することは困難であった。
【００２６】
また、モバイルエージェントを他のノードに移動させる場合、移動先のノードは利用者が直接管理できる対象ではなく、特に移動先のノードが信頼性の低い回線の先にあるようなとき、移動先や回線で障害が起きたときの対処も困難であった。
【００２７】
つまり、モバイルエージェントの運用に当たり、次の２点には注意すべきである。第１点は、モバイルエージェントの大きな採用理由の１つに、通信回線の信頼性が低い、あるいは帯域幅が小さい、という状況がある場合が多いことである。このため、モバイルエージェントは携帯端末を用いたモバイルコンピューティングを、もっとも主要な適用分野としている。このように信頼性の低い回線を使うときは、エラーなどの例外が発生したときにどのように対処するかが大きな課題となる。
【００２８】
第２点は、モバイルエージェントは移動により利用者が管理し得ないマシンのノード上で動作し得る、という点である。このため、そのようなマシンでエージェントの動作に例外的状況が発生した場合、モバイルエージェントでない場合に比べて対処が一層困難となる。特に、第１点で挙げたような信頼性の低い通信回線を通じて移動先のマシンを利用している場合には、このような困難は顕著なものとなる。
【００２９】
この発明は、上に述べたような従来技術の問題点を解決するために提案されたもので、その目的は、モバイルエージェントとステーショナリエージェントとを状況に応じて動的に使い分けることで円滑に情報を処理するエージェントの技術を提供することである。また、この発明の他の目的は、通信回線の信頼性が低い場合でも例外的な状況に円滑に対処する技術を提供することである。
【００３０】
【課題を解決するための手段】
上に述べた目的を達成するため、本発明は、ネットワークで互いに接続された複数のプラットフォーム上でソフトウェアエージェントに情報処理を行わせる情報処理装置において、エージェントに他のプラットフォームの資源を使わせるとき、そのエージェントを当該他のプラットフォームへ移動させる移動手段と、エージェントに他のプラットフォームの資源を使わせるとき、そのエージェントから当該他のプラットフォームのエージェントに処理を依頼させる協調手段と、個々のプラットフォームが移動されたエージェントを受け入れて活動させる手段を備えているかどうかを表わすプラットフォームプロファイルを格納する手段と、個々のエージェントがプラットフォーム間で移動する能力を持つかどうかに関するエージェント属性を格納する手段と、エージェントに他のプラットフォームの資源を使わせるとき、前記プラットフォームプロファイル及び前記エージェント属性に基づいて、そのエージェントを当該他のプラットフォームへ移動させるか、そのエージェントから当該他のプラットフォームのエージェントに処理を依頼させるかを決定する決定手段と、を備えたことを特徴とする。
【００３１】
本発明では、エージェントが他のプラットフォームの資源を使うとき、移動か協調かは、プラットフォームプロファイルとエージェント属性の両方に基づいて決める。例えば、そのエージェントとプラットフォームの両方が移動をサポートしていればエージェントを移動させるが、どちらか一方でもサポートしていなければ協調とする。これによって、移動機能を持つモバイルエージェントとステーショナリエージェントの統合的活用が容易になる。
【００３２】
例えば、エージェントが他のプラットフォームの資源を使うとき、そのプラットフォームとの間の回線の信頼性が低ければ、そのプラットフォームに移動することが望ましいが、そのプラットフォームがモバイルエージェントをサポートしていないことをプラットフォームプロファイルから予め判断することで、移動を試すまでもなく、そのプラットフォームのエージェントと協調を行うべきだと判断できる。
【００３３】
また、本発明では、エージェントごとに、プラットフォーム間で移動する能力を持つモバイルエージェントか、移動する能力を持たないステーショナリエージェントかの情報をエージェント属性として用意しておく。そして、エージェントが他のプラットフォームの資源を使うとき、そのエージェントを当該他のプラットフォームへ移動させるか、そのエージェントから当該他のプラットフォームのエージェントに処理を依頼させる（協調）かは、このエージェント属性に基づいて容易に決めることができる。
【００３４】
なお、複数のエージェント間で協調を行うには、従来から知られているエージェント間協調の技術、例えば契約ネットプロトコルや、黒板機能などを使えばよい。
【００３５】
本発明の実施の形態の一つは、与えられた要求を満たすエージェントのプランを生成するプランニング手段と、生成されたプランを実行することでエージェントを動作させる実行手段と、エージェントの動作に必要な情報を格納するためのエージェント情報格納手段と、プラットフォーム上のエージェントに対して、他のプラットフォームに移動させ又は他のプラットフォームのエージェントに処理を依頼させることで他のプラットフォームの資源を使わせるエージェント管理手段と、前記プランの生成、前記移動及び前記依頼に必要な知識を格納する知識格納手段と、前記知識格納手段を管理する知識管理手段と、を備えたことを特徴とする。このような構成によれば、プランニングによってネットワークの予期せぬ変化に柔軟に対応できる。そして、プランニングによってエージェントのプランが変わり、どのエージェントがどのプラットフォームの資源を使うことになっても、プラットフォームプロファイルやエージェント属性に基づいて移動か協調かを容易に決めることができる。このように、移動と協調とを使い分けることで、ネットワークという分散環境でエージェントを使う情報処理が効率化される。また、ネットワークの変化にもプランニングで対応しながら、エージェントの移動と協調とを有効に結び付けて活用するので、開放型ネットワークでも効果的に情報処理を行うことができる。
【００３６】
本発明の実施の形態の一つは、ネットワークで互いに接続された複数のプラットフォーム上でエージェントが情報処理を行う情報処理装置において、エージェントがプラットフォーム間で移動しようとするときの例外に対応するための例外対応手段を備えたことを特徴とする。このような構成によれば、エージェントがプラットフォーム間で移動しようとするときに移動失敗などの例外が発生しても、そのような例外に適切に対応することで情報処理が円滑に行われる。
【００３７】
本発明の実施の形態の一つは、前記例外対応手段は、どのような例外に対してどのように対処するかを表わす例外記述と、前記例外記述に基づいて例外に対処する対処手段と、を備えたことを特徴とする。このような構成によれば、移動時のどのような例外に対してどのように対処するかは例外記述に表わしておき、例外記述を書き換えることで対処の内容を容易に変更することができる。
【００３８】
本発明の実施の形態の一つは、前記例外記述は、（１）移動先として指定されたプラットフォームとの通信が失敗したためにエージェントが移動できない例外、（２）移動先の指定が無効であるためにエージェントが移動できない例外、（３）移動先として指定されたプラットフォームが移動されたエージェントを受け入れて活動させる手段を備えていないためにエージェントが移動できない例外、（４）移動先として指定されたプラットフォームにおける資源不足のためにエージェントが移動できない例外、のうち少なくとも１つについて、どのように対処するかを表わすことを特徴とする。このような構成によれば、移動のときによく起きがちな例外、すなわち移動先との通信の失敗、移動先の指定が無効、移動先がモバイルエージェントに対応していない、移動先での資源不足、のうち少なくとも１つに対する対処を例外記述に表わしておくので、例外に効果的に対処することができる。
【００３９】
本発明の実施の形態の一つは、前記例外記述は、前記通信回線のうち信頼性の低い通信回線に関する情報と、エージェントが前記信頼性の低い通信回線を通してプラットフォーム間で移動するときに発生する可能性がある例外に対してどのように対処するかを表わす情報と、を含むことを特徴とする。このような構成によれば、どの通信回線の信頼性が低いかの情報を予め各プラットフォームなどに用意しておき、エージェントがそのような回線を通して移動しようとするときに通信が途絶したときの対応を決めておく。これによって、通信回線の信頼性が低く、通信が途絶しやすい場合でも動作不全や故障などが起きにくくなる。
【００４０】
本発明の実施の形態の一つは、前記通信回線で一定時間反応が途絶していることを検知するタイムアウト検知手段を備え、前記例外対応手段は、前記信頼性の低い通信回線を通してエージェントを移動させるための通信を行っているときに、前記タイムアウト検知手段が前記途絶を検知した場合、予め決められた待ち時間の後で前記通信を再び試みる処理を繰り返すように構成されたことを特徴とする。このような構成によれば、エージェントを移動させるための通信が途絶えるとしばらく待ってから再び通信を試みる処理が繰り返される。このため、通信回線の信頼性が低くても、状態がよくなっている間にエージェントの情報を送ってエージェントを移動させることができる可能性が高くなる。
【００４１】
本発明の実施の形態の一つは、各プラットフォームは、異なった目的に対応する複数のフィールドを備え、プラットフォームの持っている資源をフィールドごとに分けて管理するフィールド管理手段を備えたことを特徴とする。このような構成によれば、プランニングに使う知識などプラットフォームの資源が情報処理の目的や知識の適用分野などを基準に、フィールドごとに分けて管理される。このため、あるフィールドのエージェントは、自分の目的と関係ない知識まで参照する必要がなく、効率的にプランニングをすることができる。
【００４２】
本発明の実施の形態の一つは、複数のエージェントが情報をやり取りするための黒板手段と、前記黒板手段を、情報の優先度に応じた複数の階層に分けて管理することで各エージェントを協調させるように制御する黒板管理手段と、を備えたことを特徴とする。このような構成によれば、ネットワークの予期せぬ変化のような急ぎの情報は、例えば、黒板の上位階層に書き込むことで、エージェントの通常の動作に割り込ませ、そのような変化に対応してエージェントの動作を制御することができる。
【００４３】
【発明の実施の形態】
以下、この発明の実施の形態（以下「実施形態」という）について図面を参照しながら説明する。なお、この発明は、周辺機器を持つコンピュータを、ソフトウェアで制御することによって実現されることが一般的と考えられる。この場合、そのソフトウェアは、この明細書の記載にしたがった命令を組み合わせることで作られ、上に述べた従来技術と共通の部分には従来技術で説明した手法も使われる。また、そのソフトウェアは、プログラムコードだけでなく、プログラムコードの実行のときに使うために予め用意されたデータも含む。
【００４４】
そして、そのソフトウェアは、ＣＰＵ、コプロセッサ、各種チップセットといった処理装置、キーボードやマウスといった入力装置、メモリやハードディスク装置といった記憶装置、ディスプレイやプリンタといった出力装置などの物理的な資源を活用することでこの発明の作用効果を実現する。
【００４５】
但し、この発明を実現する具体的なソフトウェアやハードウェアの構成はいろいろ変更することができる。例えば、ソフトウェアの形式には、コンパイラ、インタプリタ、アセンブラなどいろいろあり、外部との情報をやり取りするにも、フロッピーディスクなどの着脱可能な記録媒体、ネットワーク接続装置などいろいろ考えられる。また、この発明を実現するソフトウェアやプログラムを記録したＣＤ−ＲＯＭのような記録媒体は、単独でもこの発明の一態様である。さらに、この発明の機能の一部をＬＳＩなどの物理的な電子回路で実現することも可能である。
【００４６】
以上のように、コンピュータを使ってこの発明を実現する態様はいろいろ考えられるので、以下では、この発明や実施形態に含まれる個々の機能を実現する仮想的回路ブロックを使って、この発明と実施形態とを説明する。
【００４７】
〔１．構成〕
〔１−１．プラットフォームの全体構成〕
この実施形態は、ネットワークで互いに接続された複数のプラットフォーム上でエージェントが情報処理を行う情報処理装置であり、図１は、この実施形態を構成する１つのプラットフォームの構成を示すブロック図である。
【００４８】
この図において、１は、エージェントを管理するエージェント管理部であり、このエージェント管理部１は、プランニング、ネットワークＮ上でのエージェントの移動、およびエージェント間での協調を実現するのに必要な構成（後述）を備えている。また、２は、与えられた要求を満たすためにエージェントが実行すべき実行手順すなわちプランを生成するプランニング部であり、３は、このように生成したプランを実行することでエージェントを動作させる実行部である。また、４は、エージェントが動作するときに必要な情報、例えば前記のプランやエージェントの内部状態を表わす変数などを格納するエージェント情報記憶部である。
【００４９】
また、５は、プランニングに必要な知識や、信頼性の低い通信回線で接続された計算機に関する知識など各種の情報（後述）を格納する知識格納部であり、６は、この知識格納部５を管理する知識管理部であり、知識格納部５に格納されている各種の知識について、書き込み、読み出し、修正などの処理を行う。
【００５０】
また、この実施形態では、個々のプラットフォームが、異なった目的に対応する複数のフィールドを備えている。このフィールドは、知識およびエージェントの動作の範囲を示すもので、７は、プラットフォームの持っている資源をフィールドごとに分けて管理するフィールド管理部である。
【００５１】
また、８は、エージェント間の協調やエージェントの動作を制御するのに使う情報を格納する黒板部である。また、９は、黒板部８においてエージェントの動作制御のレベルを表す黒板階層構造を管理する階層黒板管理部である。また、２０は、以上の各部を管理し、またネットワーク間の通信を管理するプラットフォームであり、１１は、各部の情報を出力し、また各部への入力、および各部の状態を制御する情報を入力できる入出力部である。
【００５２】
〔１−２．問題の具体例〕
次に、図２は、この実施形態の情報処理装置を具体的な問題に適用する場合の具体例を示す概念図であり、具体的には、通信回線Ｃ１〜Ｃ５で接続されたいくつかのプラットフォーム１０１〜１０６の上で、旅行のチケットを予約する例である。すなわち、この図２において、１０１は、利用者が持ち歩くことができる携帯計算機であり、携帯電話やＰＨＳのような無線回線などの随時接続・切断可能な回線によって、この実施形態におけるネットワークＮに組込めるものとする。図１は、このようにネットワークに組み込まれるプラットフォームの一例を示したものである。
【００５３】
利用者は、この携帯計算機１０１を通じてネットワークを利用することで、ある地方のある大学（仮に「地方大学」と呼ぶ）に東京から赴く旅行計画および交通機関のチケット予約を行うものとする。
【００５４】
また、図２において、１０２は、ある旅行代理店の計算機であり、ネットワーク上の旅行計画および交通機関チケット予約に利用できる種々の計算機に関する情報を格納している。また、１０３、１０４はそれぞれ、航空会社ＡＬ１，ＡＬ２の計算機であり、１０５は地方大学のある地域を担当している観光局の計算機、さらに１０６は、目的地である地方大学の計算機である。
【００５５】
これら各計算機１０１から１０６には、後に説明するような旅行計画およびチケット予約に必要なデータが格納されている。なお、これら各計算機１０１から１０６は、以下では単に「旅行代理店」「地方大学」や「交通局」のように表わす。
【００５６】
〔１−３．知識格納部の内容〕
次に、図１に示したプラットフォーム１０の知識格納部５に、どのような情報が格納されているかを説明する。この知識格納部５は、プランの生成、エージェントのプラットフォーム間での移動及びエージェント同士の協調に必要な知識を格納する部分であり、この知識格納部５には、具体的には、プランニング用知識５１、プラットフォームプロファイル５２、エージェント属性５３、例外記述５４が格納されている。
【００５７】
〔１−３−１．プランニング用知識〕
このうち、プランニング用知識５１は、エージェントのプラン生成に使うものであり、どのファイルがどのプラットフォームにあるのかといったネットワークの構成に関する知識や、どのようなときにどのようにプランニングを行うのかといった知識の他に、情報処理装置やエージェントの利用目的に応じて各種の知識を含めることができる。
【００５８】
〔１−３−２．プラットフォームプロファイル〕
また、プラットフォームプロファイル５２は、個々のプラットフォームが移動されたエージェントを受け入れて活動させる構成を備えているかどうか、すなわちモバイルをサポートしているかどうかを表わす情報であり、このプラットフォームプロファイル５２の例を図３に示す。この例は、図２に示した各プラットフォームに対応するもので、携帯計算機（図２の１０１）や旅行代理店（図２の１０２）といった各プラットフォームごとに、モバイルエージェントのサポートがあるかないかを記録したものである。
【００５９】
〔１−３−３．エージェント属性〕
また、エージェント属性は、個々のエージェントがプラットフォーム間で移動する能力を持つかどうか、すなわちモバイルをサポートしているかどうかに関する情報であり、このエージェント属性５３の例を図４に示す。この例は、図２に示した実例に対応するもので、エージェントの名称ごとに、そのエージェントがどのプラットフォームに所属するものであるかと、そのエージェントが移動型かどうかを表わす属性mobilityを登録したものである。
【００６０】
この属性mobilityは、エージェントがモバイルエージェントならmobile、ステーショナリエージェントならstationaryという属性値を設定することで、エージェントの移動能力の有無を区別している。このような属性値は、エージェント情報格納部４に格納されているエージェントの情報のうち、エージェントがモバイルをサポートしているかどうかを表わすフラグや、プラットフォーム間での移動に関する情報があるかどうかなどから判断することができる。
【００６１】
そして、エージェント管理部１は、新しくエージェントを生成するときや、移動してきたエージェントを受け入れたときに上に述べたような情報からエージェント属性を判断して登録しておけばよい。
【００６２】
また、所属は、ステーショナリエージェントについてそのエージェントが存在するプラットフォームであり、モバイルエージェントについては、そのエージェントが生成されたプラットフォームの名称である。
【００６３】
〔１−３−４．例外記述〕
例外記述５４は、エージェントがプラットフォーム間で移動しようとするときについて、どのような例外に対してどのように対処するかを表わすものであり、この例外記述５４の例を図５に示す。この例は、次のような例外内容に対して、それぞれ対処内容を定めている。
【００６４】
（１）移動先として指定されたプラットフォームとの通信が失敗したためにエージェントが移動できない例外（通信タイムアウト）。
これは、例えば移動先のプラットフォームに、エージェントを移動させたいという通知を送信したが、相手からの反応が一定時間以上途絶えているような場合である。
【００６５】
（２）移動先の指定が無効であるためにエージェントが移動できない例外（移動先指定誤り）。
これは、つまり移動先の指定が誤っている場合であり、例えば、移動先として指定したプラットフォームあるいはドメインのＩＤなどが無効である場合などが考えられる。このような例外は、エージェントが生成されたプラットフォームから他のプラットフォームへの移動しようとしたときなどに発生する。
【００６６】
（３）移動先として指定されたプラットフォームが移動されたエージェントを受け入れて活動させる構成を備えていないためにエージェントが移動できない例外（モバイルサポートなし）。
これは、つまり移動先のプラットフォームが、そのプラットフォームの機能としてモバイルエージェントをサポートしていない場合であり、このような例外は、エージェントが生成されたプラットフォームから他のプラットフォームへの移動しようとしたときなどに発生する。
【００６７】
（４）移動先として指定されたプラットフォームにおける資源不足のためにエージェントが移動できない例外（移動先資源不足）。
これは、つまり移動先のプラットフォームが、本来は移動されたエージェントを受け入れて活動させる構成を備えているが、たまたまメモリなどの資源が不足しているためエージェントを受け入れられないような場合である。このような例外は、エージェントが、生成されたプラットフォームから他のプラットフォームへ移動しようとしたとき、移動のためにエージェントのデータが転送された後、転送されたエージェントが移動先で動作を再開しようとするときなどに発生する。
【００６８】
なお、（１）の通信タイムアウトでは、信頼性の高い回線で発生した場合と、信頼の低い回線で発生した場合とで、対処内容が異なる。このため、この例外記述は、信頼性の低い通信回線に関する情報を含んでいる。
【００６９】
〔１−３−５．信頼性の低い通信回線に関する情報〕
ここでいう「信頼性の低い通信回線に関する情報」は、図２に示した通信回線Ｃ１〜Ｃ５のうち、どの通信回線の信頼性が低いかを表わす情報であり、このような情報の例を図６に示す。この例では、各通信回線Ｃ１〜Ｃ５について、どのプラットフォーム（接続先１）とどのプラットフォーム（接続先２）を接続しているかと、その通信回線の信頼性が低いか高いかを登録したものである。なお、図２では、信頼性の高い通信回線は太い実線で示し、信頼性の低い通信回線は細い点線で示している。
【００７０】
また、以下では、他のノードとの通信回線の信頼性については、説明を単純にするために、１つの通信回線についてだけ述べるが、実際には、インターネットのようなハブ（中心）のないネットワーク構成では、あるプラットフォームから別のプラットフォームへの通信回線の信頼性は、複数の通信回線の信頼性に基づいて決まる。そのような場合、回線の信頼性については、複数の通信回線の組み合わせごとに登録しておいたり、ある経路の信頼性を、その経路を構成するいくつかの通信回線の信頼性から計算してもよい。
【００７１】
信頼性の低い通信回線に関する情報は、後で詳しく説明するが、プラットフォーム間でエージェントを移動させようとする通信で通信タイムアウトが発生したときに、現在通信に使っている通信回線の信頼性が低いか高いかを調べるのに使うことができ、図５に示す「通信タイムアウト（信頼性の低い回線）」は、エージェントが信頼性の低い通信回線を通してプラットフォーム間で移動するときに通信タイムアウトが発生したとき、どのように対処するかを表わしている。
【００７２】
〔１−４．エージェント管理部の構成〕
また、エージェント管理部１は、プラットフォーム上のエージェントを管理すると共に、個々のエージェントに対して、他のプラットフォームに移動させ又は他のプラットフォームのエージェントに処理を依頼させることで他のプラットフォームの資源を使わせる部分である。このエージェント管理部１は、エージェントを生成したり、登録したり、消滅させたりするための構成（図示せず）の他に、協調部１１と、移動部１２と、決定部１３と、対処部１４と、タイムアウト検知部１５と、を備えている。
【００７３】
このうち、協調部１１は、エージェントが他のプラットフォームの資源を使うとき、そのエージェントから当該他のプラットフォームのエージェントに処理を依頼させる部分であり、具体的には契約ネットプロトコルを実行するためのタスクアナウンス、入札締切、落札といった処理を行うように構成されている。また、移動部１２は、エージェントが他のプラットフォームの資源を使うとき、そのエージェントを当該他のプラットフォームへ移動させる部分であり、具体的には、移動先としてプランなどで指定されるプラットフォームとの間で、エージェント移動の打診や、エージェント情報格納部４に格納されている情報の転送といった処理を行うように構成されている。
【００７４】
また、決定部１３は、エージェントが他のプラットフォームの資源を使うとき、プラットフォームプロファイル５２及びエージェント属性５３に基づいて、そのエージェントを当該他のプラットフォームへ移動させるか、そのエージェントから当該他のプラットフォームのエージェントに処理を依頼させるかを決定する部分である。
【００７５】
また、対処部１４は、例外記述５４に基づいて例外に対処する部分であり、これら対処部１４及び例外記述５４は、エージェントがプラットフォーム間で移動しようとするときの例外に対応するための例外対応手段を構成している。また、タイムアウト検知部１５は、通信回線で一定時間反応が途絶していることを検知する部分であり、信頼性の低い回線での通信タイムアウトの場合の例外記述と組み合わせて使う。
【００７６】
これにより、信頼性の低い通信回線を通してエージェントを移動させるための通信を行っているときに、タイムアウト検知部１５が途絶を検知した場合、対処部１４の働きによって、予め決められた待ち時間の後で前記通信を再び試みる処理を繰り返す、という例外への対応を実現する。
【００７７】
〔１−５．フィールド〕
また、フィールド管理部７に関連して上で説明したように、各プラットフォームは、異なった目的に対応する複数のフィールドを備えている。このフィールドは、情報処理の目的や分野ごとに設定されるエージェントの活動領域であり、ファームとも呼ばれる。このようなフィールドは、一つのプラットフォーム上に複数存在することができ、フィールド管理部７は、メモリなどの資源やプランの生成・実行に用いる情報などを、フィールド毎に管理する。
【００７８】
ここで、図７は、ネットワークＮに複数のホストＨ（マシン）が接続され、各ホストＨ上には１つずつのプラットフォームすなわちノードＸが存在し、ノードＸ上に複数のフィールドＦＬが存在する例を示す概念図である。このようなエージェントシステムでは、プラン生成に用いる知識がフィールドＦＬごとに分けられており、これによって、エージェントはプランニングなどに必要な情報を検索する際、余分な情報まで参照する必要がないので、情報処理が効率化される。なお、プラン生成に用いられる知識はその知識を所持している主体によって、ファームが所持しているファーム知識、エージェントが所持しているエージェント知識などに分けることができる。
【００７９】
〔１−６．黒板〕
また、黒板管理部９は、黒板部８を、情報の優先度に応じた複数の階層に分けて管理することで、協調動作を含め、各エージェントを制御するように構成されている。すなわち、図８に示すように、黒板部８は、上位階層と下位階層を備え、ネットワークの予期せぬ変化のように、例えばエージェント間で急いで伝える必要がある情報は黒板の上位階層に書き込むようになっている。また、これに対応して、黒板管理部９は、そのような情報に関する処理を、エージェントの通常の動作に割り込ませるように構成されている。これによって、ネットワークの予期せぬ変化のような状況の変化に対応してエージェントの動作を制御するすることができる。
【００８０】
〔１−７．他のプラットフォームの構成〕
なお、図１では１つのノードすなわちプラットフォームについてその構成を示したが、これは、この実施形態の情報処理装置に含まれる多数のプラットフォームの一例であり、構成が一部異なる他のプラットフォームが存在する場合も考えられる。例えば、モバイルエージェントをサポートしていないプラットフォームには移動部１２やタイムアウト検知部１５は必要なく、また、エージェント間の情報交換に、特定の１つのプラットフォームの黒板部８と黒板管理部９を使うときは、それ以外のプラットフォームには黒板部８や黒板管理部９は必要ない。
【００８１】
また、例えば、プランニングの機能を持たないプラットフォームがあってもよく、そのようなプラットフォームでは、プランニング用知識５１、プランニング部２は必要がない。また、複数のフィールドを持たないプラットフォームではフィールド管理部７は必要がない。
【００８２】
〔２．作用〕
上に述べたように構成されたこの実施形態は、次のように働く。まず、図９は、この実施の形態における処理手順を示すフローチャートである。
【００８３】
〔２−１．要求の入力〕
すなわち、まず、利用者が、本システムへの要求を、携帯計算機の入出力部２０を通じて入力する（ステップ３０１）。この要求は、情報処理の結果として達成したい状態を、予め定められた形式で記述することによって表す。例えば、利用者は、下記の通り旅行計画およびチケット予約に関する要求を入力する。
出発地：東京
出発日時：１１月３日
到着地：地方大学
到着日時：１１月３日午後０時まで
利用交通機関：航空機
【００８４】
〔２−２．ゴールへの変換〕
このように入力された要求は、続いて、ゴールに変換される（ステップ３０２）。このゴールは、エージェントによる情報処理によって達成したい状態を、エージェントやプランニング部２が処理できる形式で表わしたものである。例えば、上に述べた旅行計画及びチケット予約に関する要求は、例えば、次のようなゴールに変換される。
【００８５】
〔２−３．エージェントの初期化〕
このように要求がゴールに変換されると、プラットフォームのエージェント管理部１が、ゴールの達成に使うエージェントを生成し、初期化の手順を実行する（ステップ３０３）。例えば、“ｕｓｅｒ”という名前でエージェントを生成した場合、初期化の手順として、エージェントを管理するためのリストに名称“ｕｓｅｒ” を登録したり、エージェントｕｓｅｒの内部変数に所定の初期値を設定したり、タイムシェアリングシステムにおけるタイムスライス（ＣＰＵ時間）をエージェントｕｓｅｒに割り当てるなどの処理を行なう。
【００８６】
なお、複数のフィールドが存在するプラットフォームでは（図７）、各エージェントはエージェント管理部１による管理のもとで特定のフィールド内に生成される。そして、これに続くプランニング部２によるプランニングでは、知識管理部６がフィールドに対応する知識を読み出して提供する。
【００８７】
〔２−４．プランニング〕
続いて、プランニング部２が、変換されたゴールを達成するためのプランを生成（プランニング）する（ステップ３０４）。ここで、プランニング用知識５１には、プランを構成する部品として、エージェントはどのような種類の動作を実行できるかという情報が含まれている。このような単位となる動作はアクションとも呼ばれ、動作ごとに、事前条件と事後条件とが予め決められている。
【００８８】
ここで、事前条件とは、その動作を実行するために必要な条件であり、事後条件とは、その動作の実行によって作りだされる条件である。このため、ある動作である事後条件が達成されれば、その事後条件に対応する事前条件を持つ動作が実行できる状態となる。例えば、「ファイルをコピーする」という動作を行うには、「現在いるプラットフォームにファイルが存在する」という事前条件が必要であり、コピーの動作を行なった結果として「ファイルのコピーが存在する」という事後条件が産み出される。
【００８９】
すなわち、プランの生成は、最終的なゴールを事後条件として産み出す動作を発見し、この動作の事前条件を事後条件として産み出すさらに別の動作を発見する、という処理を続けることによって、プランを実行する前の状態（現在の状態）と最終的なゴールとの間をつなぐ動作の列を得ることである。なお、図１０は、生成途中におけるプランの例を示す図であり、この例では、動作Ｐ２の一方の事前条件Ｃ５と、動作Ｐ３の事前条件Ｃ７について、これら事前条件を事後条件として産み出す動作がまだ見つかっていない。このように、事後条件として産み出す他の動作がまだ見つかっていない事前条件は未達成ゴールと呼ばれる。
【００９０】
このようなプラン生成の処理は、ゴールの側から因果を逆に遡って行ない、プランの実行を開始する時点で存在している状態（現在の状態）に到達すると終了する。図１１は、このような処理によって完成したプランの例を示す図である。
【００９１】
続いて、プラン生成の具体的な手順を図１２に示す。すなわち、この手順では、ゴールを記録しておくゴールリストの一部を、図１０に示したような未達成ゴールを記録しておく未達成ゴールリストとしておき、次のような処理を行う。まず、ゴールリストに未達成ゴールが存在しなくなるまで（ステップ４０１）、未達成ゴールリストから未達成ゴールを１つずつ選択し（ステップ４０２）、ゴールが満足されている場合を除いて（ステップ４０３）、次のような動作を行う。すなわち、ゴールである事前条件を事後条件によって達成可能な動作が存在すれば（ステップ４０４）この動作を選択し（ステップ４０５）、このように選択した動作（選択動作）を図１０に示したような動作の系列（プラン木）に追加する（ステップ４０５）。
【００９２】
また、ゴールを達成可能な動作が存在しない場合は、ゴールが不確実知識で達成可能かを判断する。ここで、不確実知識とは、ネットワークの構成に関する知識のうち、他のプラットフォームで実際に何らかの処理を行なってみないと、真偽などの具体的な値がわからない知識である。ゴールが不確実知識で達成可能な場合はこの不確実知識を選択動作としてプラン木に追加するが（ステップ４０５）、不確実知識でも達成不可能な場合は、処理をバックトラックさせ（ステップ４０８）、現在の未達成ゴールを生じさせている動作を他の動作に置き換えて再度処理を行う。
【００９３】
例えば、利用者が使用するプラットフォームの知識で、「ファイルａがプラットフォームＡに存在する」とされているとする。この場合、ファイルａを得るというゴールを利用者が与えると、プラットフォームＡに存在するという知識が参照されるので、生成されたエージェントのプランは、「プラットフォームＡに移動してファイルａのコピーを利用者のプラットフォームに送信する」、といった内容になる。
【００９４】
しかし、エージェントがプラットフォームＡに移動した時点で、ファイルａはプラットフォームＢに移動されていると、ファイルａが発見できないためにプランは実行失敗となり、プラットフォームＡ上で再プランニングが行なわれる。このとき、プラットフォームＢの知識がファイルの移動にあわせて更新されており、「ファイルａはプラットフォームＢに存在する」と変更されている場合、新しいプランは「プラットフォームＢに移動してファイルａのコピーを利用者のプラットフォームに送信する」、という内容に変更される。この結果、エージェントはプラットフォームＢに自律的に移動するし、ファイルａを無事発見して利用者のプラットフォームに送信することができる。
【００９５】
〔２−５．不確実知識を利用したかの判断〕
上に述べたようなプランニング手順（図９のステップ３０４）が終了すると、決定部１３が、プランニングにおいて不確実知識を用いたか否かを判別する（ステップ３０５）。不確実知識の使用の有無は、プランニングにおいて不確実知識を用いる度にその旨のデータを記録しておいて、記録したデータに基づいて判別してもよいし、作成されたプラン自体を再度検索することによって、不確実知識が含まれているか否かを判別してもよい。
【００９６】
〔２−６．不確実知識の分類〕
不確実知識は、他のプラットフォーム（以下「目的のプラットフォーム」と呼ぶ）での処理によって確認される知識であるから、プランに不確実知識が用いられた場合、そのプランによって目的が達成されるためには、不確実知識を確認する処理が必要である。ここでは、不確実知識を確認する処理は、プラン実行に先だって行なう。
【００９７】
そして、決定部１３は、不確実知識ごとに、その不確実知識の確認をエージェントの移動で行うべきか、協調で行うべきかを決定することで、例えば「移動」と「分類」の２種類に分類する（ステップ３０６）。この分類では、決定部１３は、次の（１）から（３）の３つの条件を同時に満たす不確実知識について、確認を移動で行うと決定し、条件の１つでも満たさない不確実知識については、確認を協調で行うと決定する。
【００９８】
（１）エージェントが現在いるプラットフォームと目的のプラットフォームとを結ぶ通信回線の信頼性が低いこと
通信回線の信頼性が高ければ目的のプラットフォームと通信を続けることができるためであり、このような通信回線の信頼性は、通信回線の信頼性に関する情報（図６）から、次のように調べることができる。例えば、図６の情報では、個々の通信回線ごとに、どのプラットフォームとどのプラットフォームを接続しているかが記録されている。このため、この２つプラットフォームの組み合わせが、現在のプラットフォームと目的のプラットフォームに一致する通信回線を探し、その通信回線の信頼性を読み出せばよい。
【００９９】
（２）目的のプラットフォームがモバイルをサポートしていること
（３）エージェントの属性がモバイルであること
目的のプラットフォームとエージェントの両方がモバイルをサポートしていなければ、エージェントが移動したり移動先のプラットフォームで活動することができないためである。このうち目的のプラットフォームがモバイルをサポートしているかどうかは、図３に例示したプラットフォームプロファイル５２を参照することで判断でき、また、エージェントがモバイルをサポートしているかどうかは、図４に例示したエージェント属性５３を参照することで判断できる。
【０１００】
なお、必ずしもこれら３つの条件全てに基づいて判断しなければならないわけではない。例えば、ネットワーク内の全てのプラットフォームがモバイルをサポートしていることが予めわかっているような場合は、１つ又は２つの条件で判断することもできる。また、不確実知識が確認できるプラットフォームやそのプラットフォームにいるエージェントが、モバイルではなく、協調動作をサポートしているかどうかなどを、判断の項目に加えることもできる。
【０１０１】
続いて、上に述べたような分類にしたがって、不確実知識の確認が行われる。すなわち、確認を協調で行うと決定された不確実知識については協調部１１が契約ネットプロトコル手続きに基づいて確認を行い（ステップ３０７）、一方、確認を移動で行うと決定された不確実知識については移動部１２がエージェントを移動させることによって確認を行う（ステップ３０８）。
【０１０２】
なお、不確実知識を移動で確認するか協調で確認するかは、プランニング後に決定部１３が行うので、プランニングでは不確実知識の確認のために移動するか協調するかをプランで指定する必要がない。このため、プランニングの手順も単純で済み、処理が効率化される。
【０１０３】
〔２−７．契約ネットプロトコル手続き〕
次に、契約ネットプロトコル(Contract Net Protocol) 手続きの詳細を図１３に示す（参考文献：Smith, R. G., "The Contract Net Protocol: High-level Communication and Control in a Distributed Problem Solver", IEEE Trans. Computers, Vol. 29, pp. 1104-1113(1980). ）。ここで、契約ネットプロトコルでは、エージェントから他のエージェントに依頼される作業をタスクと呼ぶ。また、タスクをエージェント間で依頼する契約ネットプロトコルは、実際には、エージェントが存在するプラットフォームの協調部１１同士の間で行なわれる。
【０１０４】
〔２−７−１．タスクアナウンス〕
契約ネットプロトコルにおいてタスク実行を依頼する場合は、まず、タスクを持つエージェント（以下、タスクマネジャと呼ぶ）が、ステップ６０１において、タスクを依頼したいプラットフォーム群に対して依頼に関する情報（以下「タスク情報」という）をブロードキャストする。なお、ブロードキャストとは一定範囲の相手に対して無差別に情報を送信することであり、タスク情報をブロードキャストすることをタスクアナウンスという。ブロードキャストするタスク情報としては、例えば、タスクＩＤ、タスクの内容、タスクマネジャのＩＤ、プラン評価基準、入札期限などがある。
【０１０５】
〔２−７−２．入札〕
上に述べたようなタスク情報を受信したプラットフォームは、各フィールドにエージェントを生成し、それらにタスク情報を転送する（ステップ６０２）。タスク情報を受け取った各エージェントは、自らが所属しているフィールドにおいてタスクを実行可能かどうか判断し（ステップ６０３）、タスク内容を実行可能なエージェントは、入札する旨の情報（以下「入札情報」や「入札メッセージ」という）をタスクマネジャに送信（入札）する（ステップ６０４）。なお、入札情報を送信したエージェントを入札エージェントと呼ぶ。
【０１０６】
入札情報には、例えば、タスクＩＤ、エージェントＩＤ、タスク実行プラン評価値などがあり、このうちタスク実行プラン評価値は、タスクアナウンスで示されたプラン評価基準に基づいて、入札エージェントが、自分がタスクを実行する場合における評価を計算したものである。
【０１０７】
〔２−７−３．入札締切と落札〕
タスクマネジャは、入札を締め切る入札期限と現在時刻を比較しながら入札情報を受信し、ステップ６０５において入札期限に到達すると、次のステップ６０６において入札締切を示すメッセージを発信する。この締切のメッセージは、タスク情報のブロードキャスト先とした全ての依頼プラットフォームに対してブロードキャストする。そして、タスクマネジャは、ステップ６０９において、落札するエージェントを決定する。この決定は、入札期限までに受信した各入札情報のタスク実行プラン評価値と、予め定めた決定の基準に基づいて、各エージェントの入札情報を比較することによって行なう。
【０１０８】
落札するエージェント（落札エージェントと呼ぶ）の決定は、タスクマネジャが、実際にタスクを依頼する先としてそのエージェントを決定することを意味するが、実際にタスクを依頼する時期は処理の内容に応じて異なっていてもよく、契約ネットプロトコルの終了後に直ちに依頼する場合もあれば、所定の時期まで待って依頼する場合もある。
【０１０９】
落札エージェントを決定すると、タスクマネジャは、ステップ６１０において、各入札エージェントに、落札の内容を表す落札情報をマルチキャスト（同報送信）する。この落札情報を受信することによって、落札エージェントは、タスクを実際に実行すべき旨の実行依頼を待つ状態となる。タスクマネジャは、落札されたタスクの実行をその後、落札エージェントに依頼し、その結果、落札エージェントは依頼されたタスクの内容を実際に実行する。
【０１１０】
上に述べたように、この実施の形態では、エージェント間協調を実現するために契約ネットプロトコルを用いる。そして、契約ネットプロトコルで処理を他のプラットフォームに依頼する場合は、依頼側プラットフォームの持つ条件と請負側プラットフォームの持つ能力との間で、入札制による調和が図られる。このため、システム全体として優れた処理効率が実現される。
【０１１１】
〔２−８．エージェントの移動の詳細〕
また、エージェントがプラットフォーム間で移動する場合の手順を図１４に示す。この例では、エージェントの移動元のプラットフォームをローカルノード、移動先のプラットフォームをリモートノードと呼ぶ。この場合、ローカルノードからの移動要求（ステップ５０１）を受信したリモートノードは（ステップ５０２）、エージェント用のプロセスを設定する（ステップ５０３）。
【０１１２】
続いて、リモートノードから、プロセスの設定が完了した旨の通知（ステップ５０４）を受信したローカルノードは（ステップ５０５）、エージェントのプランや変数領域などのエージェント情報をリモートノードに送信する（ステップ５０６）。このエージェント情報を受信したリモートノードは（ステップ５０７）、エージェント情報を格納し（ステップ５０８）、ローカルノードへ移動成功の通知を送信し（ステップ５０９）、プランの解釈実行を開始する（ステップ５１０）。一方、成功の通知を受信したローカルノードは（ステップ５１１）、不要になったエージェント用のプロセスを消去する（ステップ５１２）。
【０１１３】
〔２−９．プランの実行〕
図９のステップ３０５の判断で、プランに不確実知識が用いられていない場合は、実行部３が直ちにプランを実行し（ステップ３０９）、実行が成功すると手順を終了するが、実行に失敗すると再プランニングを行う。なお、プランに不確実知識が用いられていた場合は、上に述べたように、契約ネットプロトコル（図９のステップ３０７）やエージェントの移動（ステップ３０８）によって不確実知識が確認され、その時点までのプランが実質的に完成してから、実行部３がプランを実行する（ステップ３０９）。
【０１１４】
なお、これら契約ネットプロトコルやエージェントの移動を具体的にどの時点で行い、その結果をどのように使うかは、どのようなときにどのように再プランニングを行うかといった具体的な構成や情報処理の内容などに応じて異なることも考えられるが、例えば次のような例が考えられる。
【０１１５】
この例は、移動の条件を満たしても一律に移動とはせず、移動を使うプランと協調を使うプランを両方作って比較し、有利な方を実行するものである。このような場合は、まず、ステップ３０７の契約ネットプロトコル手続きを使ってゴールの達成を試みるプランを作成し、次に、不確実知識を確認できるプラットフォームに対しステップ３０８のエージェント移動手続きを使って移動することでゴールを達成するプランを作る。そして、このように作ったプラン同士を、必要なデータの量や通信の量などをコストと考えて評価し、コストの最も低い有利なものを選択し、実行する。なお、実行失敗時には再プランニングとして以上のプランニング手順を繰り返す。
【０１１６】
〔２−１０．移動時の例外への対応〕
また、この実施形態では、プラットフォーム間でエージェントを移動させようとするとき、エラーなどの例外が発生しても、対処部１４が例外記述５４に基づいて例外への対処を行う。例えば、移動元のプラットフォームから移動先のプラットフォームに対して、移動手続きの実行通知を送信している最中に、移動先からの応答がなくなり、タイムアウトが発生する場合を考える。
【０１１７】
すなわち、移動に使おうとしている通信回線の信頼性が低い場合、移動元のプラットフォームでは、タイムアウト検知部１５がタイムアウトを検知して対処部１４に知らせ、対処部１４は、図５に示したような例外記述５４にしたがって、次のように対処する。
【０１１８】
すなわち、対処部１４は、移動元のプラットフォームの移動部１２を一旦待ち状態に移行させたうえ、予め決められた待ち時間が経過するごとに移動先への通知を再試行させる。この再試行で、反応が途絶えることなく移動先の計算機に通知が届けば、移動部１２は通常の移動手続きを続行する。その後また反応途絶が発生すれば、再び移動待ち状態に移行し、上に述べたように、待ち時間後の再試行を繰り返す。
【０１１９】
〔２−１１．エージェント間での情報交換〕
また、契約ネットプロトコルによるタスクの依頼など、エージェント間で協調動作を行なう場合、あるエージェントが他のエージェントの振る舞いを制御することによって、予期せぬ状況変化に柔軟に対応することが望ましい。この実施の形態では、図８に示した階層的な黒板部８と、黒板管理部９とを次にように使って、このような柔軟な対応を実現する。
【０１２０】
すなわち、個々のエージェントは、黒板部８のどれか１つの階層に、エージェントの優先度に応じて対応付けられていて、図８の例では、エージェントの７０２と７０３のどちらも、黒板部８の下位階層に対応付けられているものとする。そして、他のエージェントに送る通常の情報は、自分の優先度と同じ階層に記入しておくと、受け取る側のエージェントは、処理の区切りがついたときなどに黒板部８の下位階層を参照し、自分宛のメッセージを発見して受け取る。
【０１２１】
一方、エージェントが、自分に設定された優先度に本来対応する階層よりも高い階層、すなわち上位階層へデータを記入すると、そのような記入は黒板管理部９が検出し、情報の宛先になっているエージェントにハードウェア割り込みなどで情報を通知する。このように、この実施の形態では、黒板部８が階層的に構成され、優先度の高い上位の階層に記入した情報の方が下位の階層に記入された情報よりも優先的に処理される。
【０１２２】
このため、エージェント間で交換する情報を重要度に応じた階層に記入することによって、エージェント間の協調関係を柔軟に制御できるので、予期せぬ状況の変化に対応することが容易になる。また、エージェント単位に優先度を設定しておき、優先度が高いエージェントが交換する情報ほど高い階層を用いたり、情報を黒板部８に入出力する処理も高い階層ほど優先して行なえば、一層きめ細かな制御も可能となる。
【０１２３】
〔３．情報処理の例〕
続いて、上に述べたようなこの実施形態の動作によって、図２で説明した具体的な問題を処理する例を示す。
【０１２４】
〔３−１．要求の入力と最初のプランニング〕
すなわち、上に述べたようなゴールplan_and_reserve_tickets(...) に基づいて最初にプランニングが行われる段階では、ゴールはまだ満足されていないので、プランニング部２は、ゴールを満足する動作を知識管理部６に問い合わせる。しかし、携帯計算機１０１には、要求の入力を受け付ける構成はあったが、ゴールを達成するために必要なチケットの予約手順がないものとする。
【０１２５】
この場合、知識管理部６は、知識格納部５内のプランニング用知識５１を検索した結果、ゴールを満足するために十分な動作がないと判断する。そこで、知識管理部６は、不確実知識である
maybe(plan_and_reserve_tickets(Requirements),ta)
を利用してゴールを満足できるかもしれないことをプランニング部２に伝える。
【０１２６】
この不確実知識は、チケットの予約手順は旅行代理店１０２すなわちノードｔａにあるかもしれないという内容であり、プランニング部２は、この不確実知識を使ったプランを生成する。この時点でのゴールと不確実知識との関係を図１５の概念図に示す。なお、図１５において、Ｋ１〜Ｋ５のような確定している知識は実線の図形で表わし、Ｍ１のような不確実知識は破線の図形で表わす。
【０１２７】
〔３−２．旅行代理店への移動〕
エージェント管理部１は、この不確実知識が確認できる目的のプラットフォームであるノードｔａが、どのような回線で接続されていて、また、エージェントｕｓｅｒ及びノードｔａがモバイルをサポートしているかどうかを知識管理部６に問い合わせる。
【０１２８】
この場合、知識管理部６は、知識格納部５の例外記述５４に記述されている回線の信頼性に関する情報を参照し、携帯計算機１０１が、ノードｔａに信頼性の低い無線回線Ｃ１で接続されていることが判明するため（図６）、その旨を知らせるmobile_connection(ta) といった形式の情報をエージェント管理部１に返信する。
【０１２９】
また、同じように、エージェント管理部１は、知識格納部５に格納されたプラットフォームプロファイル５２とエージェント属性５３に基づいて、エージェントｕｓｅｒとノードｔａの両方がモバイルをサポートしていることを確認する。
【０１３０】
この場合、エージェント管理部１が、エージェントを移動させるための３つの条件
（１）エージェントが現在いるプラットフォームと目的のプラットフォームとを結ぶ通信回線の信頼性が低いこと
（２）目的のプラットフォームがモバイルをサポートしていること
（３）エージェントの属性がモバイルであること
が満たされることを確認する結果、プランニング部２がノードｔａに移動するプランを生成し、このプランにしたがって移動部１２がエージェントｕｓｅｒをノードｔａに移動させる。
【０１３１】
〔３−３．予約手順に基づくプランニング〕
ノードｔａでは、不確実知識の指していた予約手順が発見され、不確実知識Ｍ１は、図１６に示すように、確定した知識Ｋ６となる。このため、エージェントは、この知識Ｋ６の指す予約手順を使って、ゴールresolve_goal(plan_and_reserve_tickets(...)を満たすために再プランニングを行う。その結果、次のようなプランが生成される。
このプランは、図１６に示すように、経路を決める処理Ｐ１と、交通機関を予約する処理Ｐ２１によって、ゴールである予約完了が実現できるというプランである。次に、実行部３はこのプランの実行に移る。
【０１３２】
〔３−４．移動による経路の検索〕
この実行では、まず、動作
を実行する。この動作は、図１６の処理Ｐ１であり、出発地東京および到着地地方大学という条件で旅行経路を検索する動作である。しかし、ノードｔａには地方大学への経路に関するデータベースが存在しないため、プラン実行失敗と判断される。
【０１３３】
そこで、プラン実行失敗の原因となった動作
の事前条件
exists(routeDB(tokyo,a_university))
をゴールとして再プランニングを行う。この事前条件は、経路のデータベース（ＤＢ）が存在していることを意味する。その結果、この事前条件は、不確実知識
により達成可能であることが、知識管理部６より知らされて判明する（図１６）。
【０１３４】
この不確実知識Ｍ２は、経路のデータベースは観光局１０５にあるかも知れないという内容である。この不確実知識についてエージェント管理部１が分類を行うときは、エージェントの現在地であるノードｔａからみて、目的のプラットフォームである
a_tourist_bureau_site
すなわち、観光局１０５がやはり信頼性の低い回線で接続されていることが分かる。また、エージェントｕｓｅｒはすでに述べたようにモバイルをサポートしていて、さらに、この目的のプラットフォームである観光局１０５もモバイルをサポートしている（図３）。
【０１３５】
このため、この不確実知識も、移動によって確認すべきと判断され、プランニング部２は、エージェントが観光局１０５に移動後検索を行い、再び旅行代理店１０２に戻るプランを作成し実行する。今回は、観光局１０５に存在するデータベースから次の情報を検索するという処理Ｐ１に成功し、図１７に示すように、不確実知識Ｍ２は確定した知識Ｋ７となる。
route([tokyo,city1],[city1,a_university])
route([tokyo,city2],[city2,a_university])
これらの情報は、東京から地方大学に行くには、ｃｉｔｙ１を経由する経路と、ｃｉｔｙ２を経由する経路があることを意味する。以下、これらの都市はそれぞれ都市１および都市２と呼ぶ。
【０１３６】
なお、この例のように利用交通機関を指定した経路の検索では、指定された交通機関、すなわちここでは航空機を含んだ経路が検索される。この場合は、例えば東京から都市１への部分が航空機、残りの部分はバスだったものと仮定する。なお、説明を簡単にするため、都市２を経由する経路については省略し、次に述べる時刻表データベースに関する処理については図示しない。
【０１３７】
〔３−５．時刻表の入手〕
このように経路の検索に成功すると、エージェントｕｓｅｒは旅行代理店１０２であるノードｔａに戻り、続いて、図示はしないが、検索された経路に対応する時刻表を手に入れる動作retrieve_tt を実行しようとする。このとき、この動作も都市１から地方大学への交通機関の時刻表データベースがノードｔａに存在しないため失敗し、再プランニングとなる。その結果、やはり地方の観光局１０５にデータベースが存在するという不確実知識を得、上記と同様の移動・再プランニングとなる。
【０１３８】
ただ今回は、移動先の観光局１０５にもデータベースが存在しないとする。その場合、やはり観光局１０５において再プランニングを行い、今度は地方大学１０６にデータベースが存在するという不確実知識を使ったプランが生成される。この不確実知識については、地方大学１０６がモバイルをサポートしていないことから（図３）、協調によって確認すべきと決定される。この結果、エージェントｕｓｅｒは、地方大学１０６のエージェントとの協調によって、都市１から地方大学への交通機関（バス）の時刻表を検索する。
【０１３９】
〔３−６．協調による航空機の予約〕
次に、エージェントｕｓｅｒは、reserve_tickets を実行しようとする。この場合、ここまでの処理によって、図１７に示すように、予約は航空機（Ｐ２）とバス（Ｐ３）の両方について行うことになっているものとする。このうち、まず、航空機の予約に必要な予約受付データベース（チケットデータベース）がノードｔａに存在しないため、再プランニングを行い、その結果、２つの航空会社ａｉｒｌｉｎｅ１、ａｉｒｌｉｎｅ２（以下、それぞれ航空会社１、２とする）に存在するとの不確実知識Ｍ４を得る。
【０１４０】
ここで、この２つの会社の計算機とは、信頼性の高い回線で接続されているとの知識も得られるため、エージェントの移動ではなく、今回は契約ネットプロトコル手続きを実行する。この契約ネットプロトコルでは、エージェントｕｓｅｒは、２つの航空会社社１，２（１０３，１０４）の計算機上のエージェントに、次のようなタスクアナウンスメッセージを送信する。
【０１４１】
このタスクアナウンスメッセージは、東京から都市１までのチケット予約について、値段を評価の基準として入札されたし、という意味である。
【０１４２】
このタスクアナウンスメッセージを受信した航空会社の各エージェントは、ゴール
ticket_reserved(tokyo,city1)
に対しプランニングを行い、その結果、それぞれプラン
reserve_ticket(tokyo,city1)
を作成する。次に各航空会社１，２のエージェントは、作成したプランについてコストを計算する。ここで計算するコストは、タスクアナウンスメッセージに含まれたｐｒｉｃｅ、すなわち、チケットの値段とする。その結果、航空会社１、２のチケットの値段がそれぞれ２００００円、および２３０００円であったとする。
【０１４３】
この場合、各航空会社１，２のエージェントは、以上の結果をそれぞれ以下のような入札メッセージを、旅行代理店１０２で動作中のエージェントに返信する。
【０１４４】
この入札メッセージを受信したエージェントｕｓｅｒは、入札にあるコストを比較し、小さい方を選択する。すなわち、ここでは航空会社１のエージェントairline1_ag1を落札エージェントとして選択する。そして、エージェントｕｓｅｒは、選択した航空会社１の落札エージェントairline1_ag1に対しては、落札を表わすnockdownメッセージを送信し、選択しなかった航空会社２のエージェントairline2_ag1に対しては、落札しなかったことを表わすno_nockdown メッセージを送信する。
【０１４５】
〔３−７．バスの予約〕
このようにして、航空機を予約する処理Ｐ２が終了すると、エージェントｕｓｅｒは、次に、最終ゴールである
resolve_goal(plan_and_reserve_tickets(...))
にとって必要なもう１つの処理、すなわちバスを予約する処理Ｐ３を行う。
【０１４６】
バスを予約する処理Ｐ３は、事前条件としてバスの予約受付データベース（ＤＢ）の存在を必要とする。この予約受付データベースは、エージェントｕｓｅｒの現在地であるノードｔａには存在しないので、実行失敗に続いて再プランニングが行われる結果、バスの予約受付データベースは観光局１０５にあるという不確実知識を使ったプランが得られる。
【０１４７】
観光局１０５は、上に述べたように移動の条件を満たすのでエージェントｕｓｅｒは観光局１０５に移動してバスの予約受付データベースを探すが発見できず、次に、バスの予約受付データベースは地方大学１０６にあるという不確実知識を使ったプランが得られる。
【０１４８】
このとき、地方大学１０６は、モバイルをサポートしていないので、契約ネットプロトコルによってバスを予約する処理Ｐ３を行い、これによって予約完了という最終ゴールが達成される。なお、最初の不確実知識から最終ゴールに至る全体的な流れの概略を図１８に示す。
【０１４９】
〔４．効果〕
以上説明したように、この実施形態では、個々のプラットフォームが移動型のモバイルエージェントをサポートしているかどうかの情報をプラットフォームプロファイル５２として用意しておく。そして、エージェントが他のプラットフォームの資源を使うとき、そのエージェントを当該他のプラットフォームへ移動させるか、そのエージェントから当該他のプラットフォームのエージェントに処理を依頼させる（協調）かは、このプラットフォームプロファイル５２に基づいて容易に決めることができる。
【０１５０】
例えば、エージェントが他のプラットフォームの資源を使うとき、そのプラットフォームとの間の回線の信頼性が低ければ、そのプラットフォームに移動することが望ましいが、そのプラットフォームがモバイルエージェントをサポートしていないことをプラットフォームプロファイル５２から予め判断することで、移動を試すまでもなく、そのプラットフォームのエージェントと協調を行うべきだと判断できる。なお、複数のエージェント間で協調を行うには、従来から知られているエージェント間協調の技術、例えば契約ネットプロトコルや、黒板機能などを使っている。
【０１５１】
また、この実施形態では、エージェントごとに、プラットフォーム間で移動する能力を持つモバイルエージェントか、移動する能力を持たないステーショナリエージェントかの情報をエージェント属性５３として用意しておく。そして、エージェントが他のプラットフォームの資源を使うとき、そのエージェントを当該他のプラットフォームへ移動させるか、そのエージェントから当該他のプラットフォームのエージェントに処理を依頼させる（協調）かは、このエージェント属性に基づいて容易に決めることができる。
【０１５２】
特に、この実施形態では、エージェントが他のプラットフォームの資源を使うとき、移動か協調かは、上に述べたようなプラットフォームプロファイル５２とエージェント属性５３の両方に基づいて決める。例えば、そのエージェントとプラットフォームの両方が移動をサポートしていればエージェントを移動させるが、どちらか一方でもサポートしていなければ協調とする。これによって、移動機能を持つモバイルエージェントとステーショナリエージェントの統合的活用が容易になる。
【０１５３】
また、この実施形態では、プランニングによってネットワークの予期せぬ変化に柔軟に対応できる。そして、プランニングによってエージェントのプランが変わり、どのエージェントがどのプラットフォームの資源を使うことになっても、プラットフォームプロファイル５２やエージェント属性５３に基づいて移動か協調かを容易に決めることができる。このように、移動と協調とを使い分けることで、ネットワークという分散環境でエージェントを使う情報処理が効率化される。また、ネットワークの変化にもプランニングで対応しながら、エージェントの移動と協調とを有効に結び付けて活用するので、開放型ネットワークでも効果的に情報処理を行うことができる。
【０１５４】
また、この実施形態では、エージェントがプラットフォーム間で移動しようとするときに移動失敗などの例外が発生しても、そのような例外に適切に対応することで情報処理が円滑に行われる。特に、この実施形態では、移動時のどのような例外に対してどのように対処するかは例外記述５４に表わしておき、例外記述を書き換えることで対処の内容を容易に変更することができる。
【０１５５】
さらに、この実施形態では、移動のときによく起きがちな例外、すなわち移動先との通信の失敗、移動先の指定が無効、移動先がモバイルエージェントに対応していない、移動先での資源不足、のうち少なくとも１つに対する対処を例外記述５４に表わしておくので、例外に効果的に対処することができる。
【０１５６】
特に、この実施形態では、どの通信回線の信頼性が低いかの情報を予め各プラットフォームなどに用意しておき、エージェントがそのような回線を通して移動しようとするときに通信が途絶したときの対応を決めておく。これによって、通信回線の信頼性が低く、通信が途絶しやすい場合でも動作不全や故障などが起きにくくなる。
【０１５７】
具体的には、この実施形態では、エージェントを移動させるための通信が途絶えるとしばらく待ってから再び通信を試みる処理が繰り返される。このため、通信回線の信頼性が低くても、状態がよくなっている間にエージェントの情報を送ってエージェントを移動させることができる可能性が高くなる。
【０１５８】
さらに、この実施形態では、プランニングに使う知識などプラットフォームの資源が情報処理の目的や知識の適用分野などを基準に、フィールドごとに分けて管理される。このため、あるフィールドのエージェントは、自分の目的と関係ない知識まで参照する必要がなく、効率的にプランニングをすることができる。
【０１５９】
加えて、この実施形態では、ネットワークの予期せぬ変化のような急ぎの情報は、例えば、黒板の上位階層に書き込むことで、エージェントの通常の動作に割り込ませ、そのような変化に対応してエージェントの動作を制御することができる。
【０１６０】
〔５．他の実施形態〕
なお、この発明は上に述べた実施形態に限定されるものではなく、次に例示するような他の実施形態をも含むものである。例えば、この発明において、ネットワークの規模、形式、プラットフォーム数などは自由であり、エージェントを用いて行う情報処理の種類や、動作、知識、プランなどを記述する言語の形式も自由に選択しうる。また、この発明はチケット予約以外の課題に適用できることはもちろんである。
【０１６１】
また、図に示したプラットフォームプロファイル５２（図３）、エージェント属性５３（図４）、例外記述５４（図５、図６）などの形式や内容は例示に過ぎず、他の形式にしたり、それらの情報にどのような項目を含めるかなどは自由に変更することができる。また、例えば、例外記述をエージェント属性などと一緒に、又はそのような情報に対応付けて格納しておくこともできる。また、同じように、通信回線の信頼性に関する情報は、例外記述の一部とせずに、独立した情報として格納しておいてもよいし、プラットフォームプロファイルの一部としてもよい。
【０１６２】
また、上に述べた実施形態では、プラットフォームプロファイル、エージェント属性、例外記述などをプラットフォームごとの知識格納部に格納したが、これらの情報は、エージェントが所有する情報として実現し、エージェントが他のプラットフォームに移動のため転送されるときは、これらの情報がエージェントと一緒に転送されるようにしてもよい。
【０１６３】
また、上に述べた実施形態では、プランニングを行うエージェントを主に例示したが、この発明は、プランニングを行わないエージェントに適用することもできる。また、対処部、例外記述を含めた例外に対応するための構成やタイムアウト検知部は必ずしも設ける必要はなく、また、例外記述の内容も実施形態に示した実例にかかわらず、自由に定めることができる。
【０１６４】
また、同じように、各プラットフォームには必ずしも複数のフィールドを設ける必要はなく、また、黒板部や黒板管理部もこの発明にとって必須ではない。
【０１６５】
【発明の効果】
以上のように、この発明によれば、モバイルエージェントとステーショナリエージェントとを状況に応じて動的に使い分けることで円滑に情報を処理することができる。
【図面の簡単な説明】
【図１】この発明の実施形態の構成を示す機能ブロック図。
【図２】この発明の実施形態における問題の内容を示す概念図。
【図３】この発明の実施形態におけるプラットフォームプロファイルの例を示す図。
【図４】この発明の実施形態におけるエージェント属性の例を示す図。
【図５】この発明の実施形態における例外記述の例を示す図。
【図６】この発明の実施形態における通信回線の信頼性に関する情報の例を示す図。
【図７】この発明の実施形態におけるフィールドを示す概念図。
【図８】この発明の実施形態における黒板部を示す概念図。
【図９】この発明の実施形態における処理手順を示すフローチャート。
【図１０】この発明の実施形態において、生成途中のプランを示す概念図。
【図１１】この発明の実施形態において、完成したプランを示す概念図。
【図１２】この発明の実施形態におけるプラン生成の具体的な手順を示すフローチャート。
【図１３】この発明の実施形態における契約ネットプロトコルの手順を示すフローチャート。
【図１４】この発明の実施形態において、エージェントがプラットフォーム間で移動する手順を示すフローチャート。
【図１５】この発明の実施形態における問題の例について、ゴールを達成する途中経過を示す概念図。
【図１６】この発明の実施形態における問題の例について、ゴールを達成する途中経過を示す概念図。
【図１７】この発明の実施形態における問題の例について、ゴールを達成する途中経過を示す概念図。
【図１８】この発明の実施形態における問題の例について、ゴールを達成する途中経過を示す概念図。
【図１９】従来のエージェントシステムの一例を示すブロック図。
【図２０】プランニングを使う従来のエージェントシステムの例を示すブロック図。
【図２１】プランニングを使う従来のエージェントシステムにおける処理手順を示すフローチャート。
【図２２】プランニングを使う従来のエージェントシステムにおけるエージェントのライフサイクルを示す概念図。
【符号の説明】
１…エージェント管理部
１１…協調部
１２…移動部
１３…決定部
１４…対処部
１５…タイムアウト検知部
２…プランニング部
３…実行部
４…エージェント情報格納部
５…知識格納部
５１…プランニング用知識
５２…プラットホームプロファイル
５３…エージェント属性
５４…例外記述
６…知識管理部
７…フィールド管理部
８…黒板部
９…黒板管理部
２０…入出力部
Ｌ…ローカルマシン
Ｒ…リモートマシン
Ｎ…ネットワーク
Ｃ…条件
Ｐ…動作
Ｓ…状態
８００Ｎ…ネットワーク
８００Ｌ…ローカルノード
８００Ｒ…リモートノード
８０１…エージェント情報記憶手段
８０２…解釈実行手段
８０３…入出力手段
８０４…エージェント管理手段
ＳＴＥＰ…手順の各ステップ
【発明の属する技術分野】
この発明は、ネットワーク上に分散する情報をエージェントを使って処理する技術の改良にかかわるもので、より具体的には、モバイルエージェントとステーショナリエージェントとを状況に応じて動的に使い分けることで円滑に情報を処理するようにしたものである。
【０００２】
【従来の技術】
〔エージェントシステム〕
従来から、コンピュータのネットワーク上に分散した情報を処理する技術として、エージェントシステムが知られている。エージェントとは、ソフトウェア上の処理単位であり、周囲の状況に応じて自律的に動作するものである。このエージェントは、ネットワークを構成するノード間で移動する能力を持つモバイルエージェントと、そのような移動の能力を持たないステーショナリエージェントに分けることができる。
【０００３】
エージェントシステムは、このようなエージェントが利用者の要求を満たすために情報処理を行うシステムであり、特に、１つのシステム上で複数のエージェントを使えば、ネットワークのような分散システムでの情報処理を一層効率的に行うことができる。このように複数のエージェントを使うシステムはマルチエージェントシステムと呼ばれる。
【０００４】
エージェントのうち、モバイルエージェントは、ネットワークを構成するノード上を必要に応じて移動することで情報収集などの処理を行い、ステーショナリエージェントは、契約ネットプロトコルなどの手続きを使って他のエージェントと協力することで情報処理を行う。なお、ノードとは、ネットワークを構成する論理的な単位であり、エージェントをプログラムとしてとらえた場合、エージェントの動作を支えるインタプリタやオペレーティングシステムの役割を果たす。このようなノードはプラットフォームとも呼び、一つのマシンすなわちコンピュータ上に複数存在し得る。
【０００５】
〔エージェントシステムの例〕
次に、このようなエージェントシステムの一例を示す。すなわち、図１９は、モバイルエージェントを使ったマルチエージェントシステムの一例として、本出願人が特願平９−１７６１８１で提案しているエージェントシステムの構成例を示す機能ブロック図である。この図に示すエージェントシステムは、複数のノード８００をネットワーク８００Ｎで接続したものであり、ノード８００はシステム上に多数設けることができるが、図１５では２つのノードを代表例として示している。そして、ノード８００のうち、利用者がエージェント生成に使用するノードをローカルノード（８００Ｌ）と呼び、生成されたエージェントが移動して行く先のノードをリモートノード（８００Ｒ）と呼ぶ。
【０００６】
このエージェントシステムにおいて、各ノード８００は、利用者がエージェントを生成する操作を行なったり、エージェントが情報処理を行なった結果を受け取るための入出力手段８０３（Ｌ，Ｒ）を有する。また、各ノードのエージェント管理手段８０４（Ｌ，Ｒ）は、エージェントを生成したり、役割を終えたエージェントを消去する他、エージェントの情報を他のノードへ転送することによって、エージェントを他のノードへ移動させたり、他のノードから同様に移動してくるエージェントを受け入れる手段である。
【０００７】
利用者は、このようなエージェントシステムを用いて何らかの情報処理を行ないたい場合、ローカルノード８００Ｌにおいて、入出力手段８０３Ｌからエージェント管理手段８０４Ｌに指示を与えることによってエージェントを生成させる。
【０００８】
そして、最も基本的な例を示せば、生成されたエージェントに対して、利用者が入出力手段８０３Ｌからスクリプトを与える。スクリプトは、エージェントの行動プログラムであり、どのノードへ移動し、どのような処理を行う、といった内容を具体的に記述したものである。スクリプトのより具体的な例としては、例えば、ノードＡに移動してファイルａのコピーを利用者のノードに送信し、次にノードＢに移動してファイルｂのコピーを利用者のノードに送信し…といった内容が考えられる。そして、各ノードに備えられた解釈実行手段８０２（Ｌ，Ｒ）は、このようなスクリプトを実行することによってエージェントを活動させ、これによって目的とする情報処理を実現する。
【０００９】
この場合、各ノードに備えられたエージェント情報記憶手段８０１（Ｌ，Ｒ）が、エージェントに必要な情報を記憶する。エージェントに必要な情報は、例えば、前記のスクリプトのほか、スクリプトの解釈実行に必要な各変数（スクリプト変数と呼ばれる）や、必要な場合は、エージェントが収集した情報やファイルなどである。また、エージェントのスクリプトに記述される命令としては、一つのノード上だけで実行できる命令のほか、エージェントを他のノードへ移動させるための移動命令がある。解釈実行手段８０２Ｌは、スクリプトの命令を順次実行し、移動命令の実行が必要になった場合には、移動先のノードを指定して、エージェントの移動をエージェント管理手段８０４に依頼する。
【００１０】
このようなエージェントシステムでは、利用者が、いくつかのファイルをネットワーク上から収集したいような場合、この目的を達成するための行動プログラムをエージェントに持たせてネットワーク上に送り出せばよく、送り出されたエージェントは、与えられたスクリプトに基づいて自律的に活動する。このため、利用者のノードとエージェントとの間で通信を始終維持する必要はないことから、ｆｔｐやｔｅｌｎｅｔといった従来のネットワーク機能と比べて回線障害に強いという利点がある。
【００１１】
〔プランニングを用いる構成例〕
図１９に示したエージェントシステムに対して、エージェントの行動プログラムであるスクリプトを、状況に応じて変化させることができるエージェントシステムも知られている。
【００１２】
すなわち、近年のようにネットワークが大規模化・複雑化し、特に、インターネットのような広域ネットワークと接続されることによっていわゆる開放型ネットワークになると、ファイルの所在などのようなネットワークの構成要素がしばしば変化するようになる。ところが、図１９に示した上記のようなエージェントシステムでは、エージェントは生成される時点で固定されたスクリプトを与えられるため、状況に応じて行動を変更することができない。そこで、このような変化に柔軟に対応するため、人手を煩わせずにエージェントの行動を自動的に変化させる技術として、本出願人は、プランニング機能を持ったエージェントシステムを出願している。
【００１３】
この技術では、エージェントの行動プログラムはプランと呼び、プランを生成することをプランニングと呼ぶ。そして、この技術では、状況に応じてプランを適宜作り直すことによって、ネットワークの構成要素の変化に対応する。なお、ネットワークの構成などの変化に対応したり、プランの実行が失敗したためにプランニングを再度やり直すことを再プランニングと呼ぶ。
【００１４】
このようなエージェントシステムの構成例を図２０の機能ブロック図に示す。この技術において、プランの生成に用いる情報としては、「知識」と呼ばれる情報とアクション定義とが挙げられる。このうち「知識」は、エージェントの動作、特にプランニングに利用する各種の情報であり、その一例として、どのファイルがどのノードに存在するかといったネットワークの構成要素に関する情報を含む。例えば図２０の例では、このようなネットワークの構成に関する知識を、ローカル情報記憶手段１Ｌに保存しておき、ネットワークの構成に変化があったときは、更新手段２Ｌが、自動検出や手作業などによって、このような変化を知識に反映させる。また、アクション定義とは、プランを構成する部品として、どのような種類の命令（アクション）が使えるかを表す情報であり、エージェント情報記憶手段３に格納しておく。
【００１５】
このようなエージェントシステムでは、エージェントの生成を指示する利用者は、スクリプトの代わりに、達成したいゴールをノードに与える。ここで、ゴールとは、情報処理の目的として達成したい状態を、予め定められた文法で記述したものである。すると、プラン生成手段５は、与えられた知識を参照しながら、アクション定義に含まれる各種のアクションを組み合わせることによって、ゴールを達成するためのプランを生成する。このようなエージェントシステムでは、ネットワークの構成の変化は、プランニングや再プランニングの際に、知識を介してエージェントのプランに反映されるので、エージェントは人手を介さずに状況の変化に対応し柔軟に行動を変化させることができる。
【００１６】
なお、このようなプランを生成する手段は「プランナ」とも呼ばれ、その実体はプランニングの手続きを表すプログラムの一種である。また、エージェントの行動プログラムやその各部分を呼ぶ広義の概念がスクリプトであり、プランというときは、特に、図２０に示したようなプランニングを行うエージェントによって生成されたスクリプトの全体を指す。
【００１７】
〔プランを使った動作の例〕
続いて、上に述べたようなプランニングを用いたエージェントシステムの具体的な動作手順を図２１に例示する。この手順では、利用者が、情報処理のゴールとしてエージェントに対する要求の記述（要求記述）を入力すると（ステップ２０１）、必要な初期化が行なわれた後（ステップ２０２）、プランが生成される（ステップ２０３）。なお、処理は、ゴールが既に達成されているなど終了条件の判定結果に応じて終了する（ステップ２０４，２０５）。
【００１８】
すなわち、このような終了条件が満たされるまでは（ステップ２０４）、ゴールを達成するために実行を要するプランの実行が行われる。プランの実行では、プランに含まれる各命令を順次実行し（ステップ２０６，２０８）、実行する命令が移動命令の場合には（ステップ２０７）エージェントをノード間で移動させる処理（goアクションと呼ばれる）が実行される（ステップ２０８）。また、各命令の実行やgoアクションの実行に失敗した場合は、必要に応じて新たなプランを生成する（ステップ２０３）。
【００１９】
〔エージェントのライフサイクル〕
次に、以上のようにプランニングを行うエージェントのライフサイクルを示す概念図を図２２に示す。すなわち、エージェントは、ゴール投入と共に生成されて活動を開始すると、まず、プランを生成するプランニングフェーズＰから開始し、生成されたプランにしたがい、プランを実行する実行フェーズＥやノード間で移動する移動フェーズＭに移行し、実行や移動の失敗に応じてこれらの各フェーズ間を移行しながら活動する。そして、当初与えられたゴールを達成すれば正常終了となり、ゴールが達成できずにプランニング自体にも失敗すると完全失敗となって終了する。
【００２０】
【発明が解決しようとする課題】
ところで、複雑なネットワークや大規模なネットワークでは、１つのシステム上にモバイルエージェントとステーショナリエージェントの両方があったり、１つのエージェントが、モバイルエージェントとして移動する機能と、ステーショナリエージェントと同じように他のエージェントと契約ネットプロトコルなどで協調する機能を、両方持っている場合も考えられる。
【００２１】
このような場合、モバイルエージェントとステーショナリエージェントとの統合的活用が重要になる。つまり、あるノードでエージェントが動作する際に、他のノードに固有のファイルやソフトウェアなどの資源を使うことがしばしば必要になる。そして、このようにエージェントが他のノードの資源を使うには、エージェント自身が他のノードへ移動するか、他のノードのエージェントに仕事を頼む必要がある。このように、あるノードにいるエージェントから、他のノードにいるエージェントに仕事を頼むことを協調と呼ぶ。
【００２２】
さらに、このように移動と協調とが可能な場合、ある条件では自分がモバイルエージェントとしてそのノードに移動して行くほうがよいが、別の条件ではそのノードにいるステーショナリエージェントに処理を依頼して協調するほうがよい、といった場合が多い。従来では、プランに基づいて他のノードの資源を利用するために移動と協調とが考えられる場合、移動と協調のうちどちらを行うかを、プラン中の動作列としてあらかじめ規定しておく必要があった。
【００２３】
しかし、このような決定は、通信回線の性質やノードの性質などに応じて動的に行う必要があることが多い。ここで、通信回線の性質としては、例えば信頼性や通信帯域などが考えられ、信頼性の低い回線で接続されているノードの資源を使おうとするときは、協調よりも移動のほうが望ましい。つまり、協調では、そのノードと通信を維持する必要があるが、信頼性の低い回線を通しての通信は途絶えやすく、このように通信が途絶えると協調の処理が中断されるからである。これに対して、エージェント自身がそのノードに移動してしまえば、移動の時に通った回線が切断されていても移動先での処理には差し支えがなく、処理が終了した後で、回線の状態が回復したときに元のノードに戻るなどすれば足りるからである。
【００２４】
また、ノードの性質としては、例えばモバイルエージェントをサポートしているかどうか、などが考えられる。つまり、エージェントに移動する機能があっても、移動先のノードが、エージェントの情報を受け入れて活動させる手段を持っていなければそのノードでエージェントが処理を続けることはできない。
【００２５】
さらに、利用したいノードとの間の通信回線の信頼性が低くても、全てのノードを移動させればよいわけではなく、エージェント自身が他のノードに移動する機能を持ったモバイルエージェントでなければ、移動は不可能であり、協調を選ぶべきである。このように、従来では、モバイルエージェントとステーショナリエージェントとを状況に応じて動的に使い分けることで円滑に情報を処理することは困難であった。
【００２６】
また、モバイルエージェントを他のノードに移動させる場合、移動先のノードは利用者が直接管理できる対象ではなく、特に移動先のノードが信頼性の低い回線の先にあるようなとき、移動先や回線で障害が起きたときの対処も困難であった。
【００２７】
つまり、モバイルエージェントの運用に当たり、次の２点には注意すべきである。第１点は、モバイルエージェントの大きな採用理由の１つに、通信回線の信頼性が低い、あるいは帯域幅が小さい、という状況がある場合が多いことである。このため、モバイルエージェントは携帯端末を用いたモバイルコンピューティングを、もっとも主要な適用分野としている。このように信頼性の低い回線を使うときは、エラーなどの例外が発生したときにどのように対処するかが大きな課題となる。
【００２８】
第２点は、モバイルエージェントは移動により利用者が管理し得ないマシンのノード上で動作し得る、という点である。このため、そのようなマシンでエージェントの動作に例外的状況が発生した場合、モバイルエージェントでない場合に比べて対処が一層困難となる。特に、第１点で挙げたような信頼性の低い通信回線を通じて移動先のマシンを利用している場合には、このような困難は顕著なものとなる。
【００２９】
この発明は、上に述べたような従来技術の問題点を解決するために提案されたもので、その目的は、モバイルエージェントとステーショナリエージェントとを状況に応じて動的に使い分けることで円滑に情報を処理するエージェントの技術を提供することである。また、この発明の他の目的は、通信回線の信頼性が低い場合でも例外的な状況に円滑に対処する技術を提供することである。
【００３０】
【課題を解決するための手段】
上に述べた目的を達成するため、本発明は、ネットワークで互いに接続された複数のプラットフォーム上でソフトウェアエージェントに情報処理を行わせる情報処理装置において、エージェントに他のプラットフォームの資源を使わせるとき、そのエージェントを当該他のプラットフォームへ移動させる移動手段と、エージェントに他のプラットフォームの資源を使わせるとき、そのエージェントから当該他のプラットフォームのエージェントに処理を依頼させる協調手段と、個々のプラットフォームが移動されたエージェントを受け入れて活動させる手段を備えているかどうかを表わすプラットフォームプロファイルを格納する手段と、個々のエージェントがプラットフォーム間で移動する能力を持つかどうかに関するエージェント属性を格納する手段と、エージェントに他のプラットフォームの資源を使わせるとき、前記プラットフォームプロファイル及び前記エージェント属性に基づいて、そのエージェントを当該他のプラットフォームへ移動させるか、そのエージェントから当該他のプラットフォームのエージェントに処理を依頼させるかを決定する決定手段と、を備えたことを特徴とする。
【００３１】
本発明では、エージェントが他のプラットフォームの資源を使うとき、移動か協調かは、プラットフォームプロファイルとエージェント属性の両方に基づいて決める。例えば、そのエージェントとプラットフォームの両方が移動をサポートしていればエージェントを移動させるが、どちらか一方でもサポートしていなければ協調とする。これによって、移動機能を持つモバイルエージェントとステーショナリエージェントの統合的活用が容易になる。
【００３２】
例えば、エージェントが他のプラットフォームの資源を使うとき、そのプラットフォームとの間の回線の信頼性が低ければ、そのプラットフォームに移動することが望ましいが、そのプラットフォームがモバイルエージェントをサポートしていないことをプラットフォームプロファイルから予め判断することで、移動を試すまでもなく、そのプラットフォームのエージェントと協調を行うべきだと判断できる。
【００３３】
また、本発明では、エージェントごとに、プラットフォーム間で移動する能力を持つモバイルエージェントか、移動する能力を持たないステーショナリエージェントかの情報をエージェント属性として用意しておく。そして、エージェントが他のプラットフォームの資源を使うとき、そのエージェントを当該他のプラットフォームへ移動させるか、そのエージェントから当該他のプラットフォームのエージェントに処理を依頼させる（協調）かは、このエージェント属性に基づいて容易に決めることができる。
【００３４】
なお、複数のエージェント間で協調を行うには、従来から知られているエージェント間協調の技術、例えば契約ネットプロトコルや、黒板機能などを使えばよい。
【００３５】
本発明の実施の形態の一つは、与えられた要求を満たすエージェントのプランを生成するプランニング手段と、生成されたプランを実行することでエージェントを動作させる実行手段と、エージェントの動作に必要な情報を格納するためのエージェント情報格納手段と、プラットフォーム上のエージェントに対して、他のプラットフォームに移動させ又は他のプラットフォームのエージェントに処理を依頼させることで他のプラットフォームの資源を使わせるエージェント管理手段と、前記プランの生成、前記移動及び前記依頼に必要な知識を格納する知識格納手段と、前記知識格納手段を管理する知識管理手段と、を備えたことを特徴とする。このような構成によれば、プランニングによってネットワークの予期せぬ変化に柔軟に対応できる。そして、プランニングによってエージェントのプランが変わり、どのエージェントがどのプラットフォームの資源を使うことになっても、プラットフォームプロファイルやエージェント属性に基づいて移動か協調かを容易に決めることができる。このように、移動と協調とを使い分けることで、ネットワークという分散環境でエージェントを使う情報処理が効率化される。また、ネットワークの変化にもプランニングで対応しながら、エージェントの移動と協調とを有効に結び付けて活用するので、開放型ネットワークでも効果的に情報処理を行うことができる。
【００３６】
本発明の実施の形態の一つは、ネットワークで互いに接続された複数のプラットフォーム上でエージェントが情報処理を行う情報処理装置において、エージェントがプラットフォーム間で移動しようとするときの例外に対応するための例外対応手段を備えたことを特徴とする。このような構成によれば、エージェントがプラットフォーム間で移動しようとするときに移動失敗などの例外が発生しても、そのような例外に適切に対応することで情報処理が円滑に行われる。
【００３７】
本発明の実施の形態の一つは、前記例外対応手段は、どのような例外に対してどのように対処するかを表わす例外記述と、前記例外記述に基づいて例外に対処する対処手段と、を備えたことを特徴とする。このような構成によれば、移動時のどのような例外に対してどのように対処するかは例外記述に表わしておき、例外記述を書き換えることで対処の内容を容易に変更することができる。
【００３８】
本発明の実施の形態の一つは、前記例外記述は、（１）移動先として指定されたプラットフォームとの通信が失敗したためにエージェントが移動できない例外、（２）移動先の指定が無効であるためにエージェントが移動できない例外、（３）移動先として指定されたプラットフォームが移動されたエージェントを受け入れて活動させる手段を備えていないためにエージェントが移動できない例外、（４）移動先として指定されたプラットフォームにおける資源不足のためにエージェントが移動できない例外、のうち少なくとも１つについて、どのように対処するかを表わすことを特徴とする。このような構成によれば、移動のときによく起きがちな例外、すなわち移動先との通信の失敗、移動先の指定が無効、移動先がモバイルエージェントに対応していない、移動先での資源不足、のうち少なくとも１つに対する対処を例外記述に表わしておくので、例外に効果的に対処することができる。
【００３９】
本発明の実施の形態の一つは、前記例外記述は、前記通信回線のうち信頼性の低い通信回線に関する情報と、エージェントが前記信頼性の低い通信回線を通してプラットフォーム間で移動するときに発生する可能性がある例外に対してどのように対処するかを表わす情報と、を含むことを特徴とする。このような構成によれば、どの通信回線の信頼性が低いかの情報を予め各プラットフォームなどに用意しておき、エージェントがそのような回線を通して移動しようとするときに通信が途絶したときの対応を決めておく。これによって、通信回線の信頼性が低く、通信が途絶しやすい場合でも動作不全や故障などが起きにくくなる。
【００４０】
本発明の実施の形態の一つは、前記通信回線で一定時間反応が途絶していることを検知するタイムアウト検知手段を備え、前記例外対応手段は、前記信頼性の低い通信回線を通してエージェントを移動させるための通信を行っているときに、前記タイムアウト検知手段が前記途絶を検知した場合、予め決められた待ち時間の後で前記通信を再び試みる処理を繰り返すように構成されたことを特徴とする。このような構成によれば、エージェントを移動させるための通信が途絶えるとしばらく待ってから再び通信を試みる処理が繰り返される。このため、通信回線の信頼性が低くても、状態がよくなっている間にエージェントの情報を送ってエージェントを移動させることができる可能性が高くなる。
【００４１】
本発明の実施の形態の一つは、各プラットフォームは、異なった目的に対応する複数のフィールドを備え、プラットフォームの持っている資源をフィールドごとに分けて管理するフィールド管理手段を備えたことを特徴とする。このような構成によれば、プランニングに使う知識などプラットフォームの資源が情報処理の目的や知識の適用分野などを基準に、フィールドごとに分けて管理される。このため、あるフィールドのエージェントは、自分の目的と関係ない知識まで参照する必要がなく、効率的にプランニングをすることができる。
【００４２】
本発明の実施の形態の一つは、複数のエージェントが情報をやり取りするための黒板手段と、前記黒板手段を、情報の優先度に応じた複数の階層に分けて管理することで各エージェントを協調させるように制御する黒板管理手段と、を備えたことを特徴とする。このような構成によれば、ネットワークの予期せぬ変化のような急ぎの情報は、例えば、黒板の上位階層に書き込むことで、エージェントの通常の動作に割り込ませ、そのような変化に対応してエージェントの動作を制御することができる。
【００４３】
【発明の実施の形態】
以下、この発明の実施の形態（以下「実施形態」という）について図面を参照しながら説明する。なお、この発明は、周辺機器を持つコンピュータを、ソフトウェアで制御することによって実現されることが一般的と考えられる。この場合、そのソフトウェアは、この明細書の記載にしたがった命令を組み合わせることで作られ、上に述べた従来技術と共通の部分には従来技術で説明した手法も使われる。また、そのソフトウェアは、プログラムコードだけでなく、プログラムコードの実行のときに使うために予め用意されたデータも含む。
【００４４】
そして、そのソフトウェアは、ＣＰＵ、コプロセッサ、各種チップセットといった処理装置、キーボードやマウスといった入力装置、メモリやハードディスク装置といった記憶装置、ディスプレイやプリンタといった出力装置などの物理的な資源を活用することでこの発明の作用効果を実現する。
【００４５】
但し、この発明を実現する具体的なソフトウェアやハードウェアの構成はいろいろ変更することができる。例えば、ソフトウェアの形式には、コンパイラ、インタプリタ、アセンブラなどいろいろあり、外部との情報をやり取りするにも、フロッピーディスクなどの着脱可能な記録媒体、ネットワーク接続装置などいろいろ考えられる。また、この発明を実現するソフトウェアやプログラムを記録したＣＤ−ＲＯＭのような記録媒体は、単独でもこの発明の一態様である。さらに、この発明の機能の一部をＬＳＩなどの物理的な電子回路で実現することも可能である。
【００４６】
以上のように、コンピュータを使ってこの発明を実現する態様はいろいろ考えられるので、以下では、この発明や実施形態に含まれる個々の機能を実現する仮想的回路ブロックを使って、この発明と実施形態とを説明する。
【００４７】
〔１．構成〕
〔１−１．プラットフォームの全体構成〕
この実施形態は、ネットワークで互いに接続された複数のプラットフォーム上でエージェントが情報処理を行う情報処理装置であり、図１は、この実施形態を構成する１つのプラットフォームの構成を示すブロック図である。
【００４８】
この図において、１は、エージェントを管理するエージェント管理部であり、このエージェント管理部１は、プランニング、ネットワークＮ上でのエージェントの移動、およびエージェント間での協調を実現するのに必要な構成（後述）を備えている。また、２は、与えられた要求を満たすためにエージェントが実行すべき実行手順すなわちプランを生成するプランニング部であり、３は、このように生成したプランを実行することでエージェントを動作させる実行部である。また、４は、エージェントが動作するときに必要な情報、例えば前記のプランやエージェントの内部状態を表わす変数などを格納するエージェント情報記憶部である。
【００４９】
また、５は、プランニングに必要な知識や、信頼性の低い通信回線で接続された計算機に関する知識など各種の情報（後述）を格納する知識格納部であり、６は、この知識格納部５を管理する知識管理部であり、知識格納部５に格納されている各種の知識について、書き込み、読み出し、修正などの処理を行う。
【００５０】
また、この実施形態では、個々のプラットフォームが、異なった目的に対応する複数のフィールドを備えている。このフィールドは、知識およびエージェントの動作の範囲を示すもので、７は、プラットフォームの持っている資源をフィールドごとに分けて管理するフィールド管理部である。
【００５１】
また、８は、エージェント間の協調やエージェントの動作を制御するのに使う情報を格納する黒板部である。また、９は、黒板部８においてエージェントの動作制御のレベルを表す黒板階層構造を管理する階層黒板管理部である。また、２０は、以上の各部を管理し、またネットワーク間の通信を管理するプラットフォームであり、１１は、各部の情報を出力し、また各部への入力、および各部の状態を制御する情報を入力できる入出力部である。
【００５２】
〔１−２．問題の具体例〕
次に、図２は、この実施形態の情報処理装置を具体的な問題に適用する場合の具体例を示す概念図であり、具体的には、通信回線Ｃ１〜Ｃ５で接続されたいくつかのプラットフォーム１０１〜１０６の上で、旅行のチケットを予約する例である。すなわち、この図２において、１０１は、利用者が持ち歩くことができる携帯計算機であり、携帯電話やＰＨＳのような無線回線などの随時接続・切断可能な回線によって、この実施形態におけるネットワークＮに組込めるものとする。図１は、このようにネットワークに組み込まれるプラットフォームの一例を示したものである。
【００５３】
利用者は、この携帯計算機１０１を通じてネットワークを利用することで、ある地方のある大学（仮に「地方大学」と呼ぶ）に東京から赴く旅行計画および交通機関のチケット予約を行うものとする。
【００５４】
また、図２において、１０２は、ある旅行代理店の計算機であり、ネットワーク上の旅行計画および交通機関チケット予約に利用できる種々の計算機に関する情報を格納している。また、１０３、１０４はそれぞれ、航空会社ＡＬ１，ＡＬ２の計算機であり、１０５は地方大学のある地域を担当している観光局の計算機、さらに１０６は、目的地である地方大学の計算機である。
【００５５】
これら各計算機１０１から１０６には、後に説明するような旅行計画およびチケット予約に必要なデータが格納されている。なお、これら各計算機１０１から１０６は、以下では単に「旅行代理店」「地方大学」や「交通局」のように表わす。
【００５６】
〔１−３．知識格納部の内容〕
次に、図１に示したプラットフォーム１０の知識格納部５に、どのような情報が格納されているかを説明する。この知識格納部５は、プランの生成、エージェントのプラットフォーム間での移動及びエージェント同士の協調に必要な知識を格納する部分であり、この知識格納部５には、具体的には、プランニング用知識５１、プラットフォームプロファイル５２、エージェント属性５３、例外記述５４が格納されている。
【００５７】
〔１−３−１．プランニング用知識〕
このうち、プランニング用知識５１は、エージェントのプラン生成に使うものであり、どのファイルがどのプラットフォームにあるのかといったネットワークの構成に関する知識や、どのようなときにどのようにプランニングを行うのかといった知識の他に、情報処理装置やエージェントの利用目的に応じて各種の知識を含めることができる。
【００５８】
〔１−３−２．プラットフォームプロファイル〕
また、プラットフォームプロファイル５２は、個々のプラットフォームが移動されたエージェントを受け入れて活動させる構成を備えているかどうか、すなわちモバイルをサポートしているかどうかを表わす情報であり、このプラットフォームプロファイル５２の例を図３に示す。この例は、図２に示した各プラットフォームに対応するもので、携帯計算機（図２の１０１）や旅行代理店（図２の１０２）といった各プラットフォームごとに、モバイルエージェントのサポートがあるかないかを記録したものである。
【００５９】
〔１−３−３．エージェント属性〕
また、エージェント属性は、個々のエージェントがプラットフォーム間で移動する能力を持つかどうか、すなわちモバイルをサポートしているかどうかに関する情報であり、このエージェント属性５３の例を図４に示す。この例は、図２に示した実例に対応するもので、エージェントの名称ごとに、そのエージェントがどのプラットフォームに所属するものであるかと、そのエージェントが移動型かどうかを表わす属性mobilityを登録したものである。
【００６０】
この属性mobilityは、エージェントがモバイルエージェントならmobile、ステーショナリエージェントならstationaryという属性値を設定することで、エージェントの移動能力の有無を区別している。このような属性値は、エージェント情報格納部４に格納されているエージェントの情報のうち、エージェントがモバイルをサポートしているかどうかを表わすフラグや、プラットフォーム間での移動に関する情報があるかどうかなどから判断することができる。
【００６１】
そして、エージェント管理部１は、新しくエージェントを生成するときや、移動してきたエージェントを受け入れたときに上に述べたような情報からエージェント属性を判断して登録しておけばよい。
【００６２】
また、所属は、ステーショナリエージェントについてそのエージェントが存在するプラットフォームであり、モバイルエージェントについては、そのエージェントが生成されたプラットフォームの名称である。
【００６３】
〔１−３−４．例外記述〕
例外記述５４は、エージェントがプラットフォーム間で移動しようとするときについて、どのような例外に対してどのように対処するかを表わすものであり、この例外記述５４の例を図５に示す。この例は、次のような例外内容に対して、それぞれ対処内容を定めている。
【００６４】
（１）移動先として指定されたプラットフォームとの通信が失敗したためにエージェントが移動できない例外（通信タイムアウト）。
これは、例えば移動先のプラットフォームに、エージェントを移動させたいという通知を送信したが、相手からの反応が一定時間以上途絶えているような場合である。
【００６５】
（２）移動先の指定が無効であるためにエージェントが移動できない例外（移動先指定誤り）。
これは、つまり移動先の指定が誤っている場合であり、例えば、移動先として指定したプラットフォームあるいはドメインのＩＤなどが無効である場合などが考えられる。このような例外は、エージェントが生成されたプラットフォームから他のプラットフォームへの移動しようとしたときなどに発生する。
【００６６】
（３）移動先として指定されたプラットフォームが移動されたエージェントを受け入れて活動させる構成を備えていないためにエージェントが移動できない例外（モバイルサポートなし）。
これは、つまり移動先のプラットフォームが、そのプラットフォームの機能としてモバイルエージェントをサポートしていない場合であり、このような例外は、エージェントが生成されたプラットフォームから他のプラットフォームへの移動しようとしたときなどに発生する。
【００６７】
（４）移動先として指定されたプラットフォームにおける資源不足のためにエージェントが移動できない例外（移動先資源不足）。
これは、つまり移動先のプラットフォームが、本来は移動されたエージェントを受け入れて活動させる構成を備えているが、たまたまメモリなどの資源が不足しているためエージェントを受け入れられないような場合である。このような例外は、エージェントが、生成されたプラットフォームから他のプラットフォームへ移動しようとしたとき、移動のためにエージェントのデータが転送された後、転送されたエージェントが移動先で動作を再開しようとするときなどに発生する。
【００６８】
なお、（１）の通信タイムアウトでは、信頼性の高い回線で発生した場合と、信頼の低い回線で発生した場合とで、対処内容が異なる。このため、この例外記述は、信頼性の低い通信回線に関する情報を含んでいる。
【００６９】
〔１−３−５．信頼性の低い通信回線に関する情報〕
ここでいう「信頼性の低い通信回線に関する情報」は、図２に示した通信回線Ｃ１〜Ｃ５のうち、どの通信回線の信頼性が低いかを表わす情報であり、このような情報の例を図６に示す。この例では、各通信回線Ｃ１〜Ｃ５について、どのプラットフォーム（接続先１）とどのプラットフォーム（接続先２）を接続しているかと、その通信回線の信頼性が低いか高いかを登録したものである。なお、図２では、信頼性の高い通信回線は太い実線で示し、信頼性の低い通信回線は細い点線で示している。
【００７０】
また、以下では、他のノードとの通信回線の信頼性については、説明を単純にするために、１つの通信回線についてだけ述べるが、実際には、インターネットのようなハブ（中心）のないネットワーク構成では、あるプラットフォームから別のプラットフォームへの通信回線の信頼性は、複数の通信回線の信頼性に基づいて決まる。そのような場合、回線の信頼性については、複数の通信回線の組み合わせごとに登録しておいたり、ある経路の信頼性を、その経路を構成するいくつかの通信回線の信頼性から計算してもよい。
【００７１】
信頼性の低い通信回線に関する情報は、後で詳しく説明するが、プラットフォーム間でエージェントを移動させようとする通信で通信タイムアウトが発生したときに、現在通信に使っている通信回線の信頼性が低いか高いかを調べるのに使うことができ、図５に示す「通信タイムアウト（信頼性の低い回線）」は、エージェントが信頼性の低い通信回線を通してプラットフォーム間で移動するときに通信タイムアウトが発生したとき、どのように対処するかを表わしている。
【００７２】
〔１−４．エージェント管理部の構成〕
また、エージェント管理部１は、プラットフォーム上のエージェントを管理すると共に、個々のエージェントに対して、他のプラットフォームに移動させ又は他のプラットフォームのエージェントに処理を依頼させることで他のプラットフォームの資源を使わせる部分である。このエージェント管理部１は、エージェントを生成したり、登録したり、消滅させたりするための構成（図示せず）の他に、協調部１１と、移動部１２と、決定部１３と、対処部１４と、タイムアウト検知部１５と、を備えている。
【００７３】
このうち、協調部１１は、エージェントが他のプラットフォームの資源を使うとき、そのエージェントから当該他のプラットフォームのエージェントに処理を依頼させる部分であり、具体的には契約ネットプロトコルを実行するためのタスクアナウンス、入札締切、落札といった処理を行うように構成されている。また、移動部１２は、エージェントが他のプラットフォームの資源を使うとき、そのエージェントを当該他のプラットフォームへ移動させる部分であり、具体的には、移動先としてプランなどで指定されるプラットフォームとの間で、エージェント移動の打診や、エージェント情報格納部４に格納されている情報の転送といった処理を行うように構成されている。
【００７４】
また、決定部１３は、エージェントが他のプラットフォームの資源を使うとき、プラットフォームプロファイル５２及びエージェント属性５３に基づいて、そのエージェントを当該他のプラットフォームへ移動させるか、そのエージェントから当該他のプラットフォームのエージェントに処理を依頼させるかを決定する部分である。
【００７５】
また、対処部１４は、例外記述５４に基づいて例外に対処する部分であり、これら対処部１４及び例外記述５４は、エージェントがプラットフォーム間で移動しようとするときの例外に対応するための例外対応手段を構成している。また、タイムアウト検知部１５は、通信回線で一定時間反応が途絶していることを検知する部分であり、信頼性の低い回線での通信タイムアウトの場合の例外記述と組み合わせて使う。
【００７６】
これにより、信頼性の低い通信回線を通してエージェントを移動させるための通信を行っているときに、タイムアウト検知部１５が途絶を検知した場合、対処部１４の働きによって、予め決められた待ち時間の後で前記通信を再び試みる処理を繰り返す、という例外への対応を実現する。
【００７７】
〔１−５．フィールド〕
また、フィールド管理部７に関連して上で説明したように、各プラットフォームは、異なった目的に対応する複数のフィールドを備えている。このフィールドは、情報処理の目的や分野ごとに設定されるエージェントの活動領域であり、ファームとも呼ばれる。このようなフィールドは、一つのプラットフォーム上に複数存在することができ、フィールド管理部７は、メモリなどの資源やプランの生成・実行に用いる情報などを、フィールド毎に管理する。
【００７８】
ここで、図７は、ネットワークＮに複数のホストＨ（マシン）が接続され、各ホストＨ上には１つずつのプラットフォームすなわちノードＸが存在し、ノードＸ上に複数のフィールドＦＬが存在する例を示す概念図である。このようなエージェントシステムでは、プラン生成に用いる知識がフィールドＦＬごとに分けられており、これによって、エージェントはプランニングなどに必要な情報を検索する際、余分な情報まで参照する必要がないので、情報処理が効率化される。なお、プラン生成に用いられる知識はその知識を所持している主体によって、ファームが所持しているファーム知識、エージェントが所持しているエージェント知識などに分けることができる。
【００７９】
〔１−６．黒板〕
また、黒板管理部９は、黒板部８を、情報の優先度に応じた複数の階層に分けて管理することで、協調動作を含め、各エージェントを制御するように構成されている。すなわち、図８に示すように、黒板部８は、上位階層と下位階層を備え、ネットワークの予期せぬ変化のように、例えばエージェント間で急いで伝える必要がある情報は黒板の上位階層に書き込むようになっている。また、これに対応して、黒板管理部９は、そのような情報に関する処理を、エージェントの通常の動作に割り込ませるように構成されている。これによって、ネットワークの予期せぬ変化のような状況の変化に対応してエージェントの動作を制御するすることができる。
【００８０】
〔１−７．他のプラットフォームの構成〕
なお、図１では１つのノードすなわちプラットフォームについてその構成を示したが、これは、この実施形態の情報処理装置に含まれる多数のプラットフォームの一例であり、構成が一部異なる他のプラットフォームが存在する場合も考えられる。例えば、モバイルエージェントをサポートしていないプラットフォームには移動部１２やタイムアウト検知部１５は必要なく、また、エージェント間の情報交換に、特定の１つのプラットフォームの黒板部８と黒板管理部９を使うときは、それ以外のプラットフォームには黒板部８や黒板管理部９は必要ない。
【００８１】
また、例えば、プランニングの機能を持たないプラットフォームがあってもよく、そのようなプラットフォームでは、プランニング用知識５１、プランニング部２は必要がない。また、複数のフィールドを持たないプラットフォームではフィールド管理部７は必要がない。
【００８２】
〔２．作用〕
上に述べたように構成されたこの実施形態は、次のように働く。まず、図９は、この実施の形態における処理手順を示すフローチャートである。
【００８３】
〔２−１．要求の入力〕
すなわち、まず、利用者が、本システムへの要求を、携帯計算機の入出力部２０を通じて入力する（ステップ３０１）。この要求は、情報処理の結果として達成したい状態を、予め定められた形式で記述することによって表す。例えば、利用者は、下記の通り旅行計画およびチケット予約に関する要求を入力する。
出発地：東京
出発日時：１１月３日
到着地：地方大学
到着日時：１１月３日午後０時まで
利用交通機関：航空機
【００８４】
〔２−２．ゴールへの変換〕
このように入力された要求は、続いて、ゴールに変換される（ステップ３０２）。このゴールは、エージェントによる情報処理によって達成したい状態を、エージェントやプランニング部２が処理できる形式で表わしたものである。例えば、上に述べた旅行計画及びチケット予約に関する要求は、例えば、次のようなゴールに変換される。
〔２−３．エージェントの初期化〕
このように要求がゴールに変換されると、プラットフォームのエージェント管理部１が、ゴールの達成に使うエージェントを生成し、初期化の手順を実行する（ステップ３０３）。例えば、“ｕｓｅｒ”という名前でエージェントを生成した場合、初期化の手順として、エージェントを管理するためのリストに名称“ｕｓｅｒ” を登録したり、エージェントｕｓｅｒの内部変数に所定の初期値を設定したり、タイムシェアリングシステムにおけるタイムスライス（ＣＰＵ時間）をエージェントｕｓｅｒに割り当てるなどの処理を行なう。
【００８６】
なお、複数のフィールドが存在するプラットフォームでは（図７）、各エージェントはエージェント管理部１による管理のもとで特定のフィールド内に生成される。そして、これに続くプランニング部２によるプランニングでは、知識管理部６がフィールドに対応する知識を読み出して提供する。
【００８７】
〔２−４．プランニング〕
続いて、プランニング部２が、変換されたゴールを達成するためのプランを生成（プランニング）する（ステップ３０４）。ここで、プランニング用知識５１には、プランを構成する部品として、エージェントはどのような種類の動作を実行できるかという情報が含まれている。このような単位となる動作はアクションとも呼ばれ、動作ごとに、事前条件と事後条件とが予め決められている。
【００８８】
ここで、事前条件とは、その動作を実行するために必要な条件であり、事後条件とは、その動作の実行によって作りだされる条件である。このため、ある動作である事後条件が達成されれば、その事後条件に対応する事前条件を持つ動作が実行できる状態となる。例えば、「ファイルをコピーする」という動作を行うには、「現在いるプラットフォームにファイルが存在する」という事前条件が必要であり、コピーの動作を行なった結果として「ファイルのコピーが存在する」という事後条件が産み出される。
【００８９】
すなわち、プランの生成は、最終的なゴールを事後条件として産み出す動作を発見し、この動作の事前条件を事後条件として産み出すさらに別の動作を発見する、という処理を続けることによって、プランを実行する前の状態（現在の状態）と最終的なゴールとの間をつなぐ動作の列を得ることである。なお、図１０は、生成途中におけるプランの例を示す図であり、この例では、動作Ｐ２の一方の事前条件Ｃ５と、動作Ｐ３の事前条件Ｃ７について、これら事前条件を事後条件として産み出す動作がまだ見つかっていない。このように、事後条件として産み出す他の動作がまだ見つかっていない事前条件は未達成ゴールと呼ばれる。
【００９０】
このようなプラン生成の処理は、ゴールの側から因果を逆に遡って行ない、プランの実行を開始する時点で存在している状態（現在の状態）に到達すると終了する。図１１は、このような処理によって完成したプランの例を示す図である。
【００９１】
続いて、プラン生成の具体的な手順を図１２に示す。すなわち、この手順では、ゴールを記録しておくゴールリストの一部を、図１０に示したような未達成ゴールを記録しておく未達成ゴールリストとしておき、次のような処理を行う。まず、ゴールリストに未達成ゴールが存在しなくなるまで（ステップ４０１）、未達成ゴールリストから未達成ゴールを１つずつ選択し（ステップ４０２）、ゴールが満足されている場合を除いて（ステップ４０３）、次のような動作を行う。すなわち、ゴールである事前条件を事後条件によって達成可能な動作が存在すれば（ステップ４０４）この動作を選択し（ステップ４０５）、このように選択した動作（選択動作）を図１０に示したような動作の系列（プラン木）に追加する（ステップ４０５）。
【００９２】
また、ゴールを達成可能な動作が存在しない場合は、ゴールが不確実知識で達成可能かを判断する。ここで、不確実知識とは、ネットワークの構成に関する知識のうち、他のプラットフォームで実際に何らかの処理を行なってみないと、真偽などの具体的な値がわからない知識である。ゴールが不確実知識で達成可能な場合はこの不確実知識を選択動作としてプラン木に追加するが（ステップ４０５）、不確実知識でも達成不可能な場合は、処理をバックトラックさせ（ステップ４０８）、現在の未達成ゴールを生じさせている動作を他の動作に置き換えて再度処理を行う。
【００９３】
例えば、利用者が使用するプラットフォームの知識で、「ファイルａがプラットフォームＡに存在する」とされているとする。この場合、ファイルａを得るというゴールを利用者が与えると、プラットフォームＡに存在するという知識が参照されるので、生成されたエージェントのプランは、「プラットフォームＡに移動してファイルａのコピーを利用者のプラットフォームに送信する」、といった内容になる。
【００９４】
しかし、エージェントがプラットフォームＡに移動した時点で、ファイルａはプラットフォームＢに移動されていると、ファイルａが発見できないためにプランは実行失敗となり、プラットフォームＡ上で再プランニングが行なわれる。このとき、プラットフォームＢの知識がファイルの移動にあわせて更新されており、「ファイルａはプラットフォームＢに存在する」と変更されている場合、新しいプランは「プラットフォームＢに移動してファイルａのコピーを利用者のプラットフォームに送信する」、という内容に変更される。この結果、エージェントはプラットフォームＢに自律的に移動するし、ファイルａを無事発見して利用者のプラットフォームに送信することができる。
【００９５】
〔２−５．不確実知識を利用したかの判断〕
上に述べたようなプランニング手順（図９のステップ３０４）が終了すると、決定部１３が、プランニングにおいて不確実知識を用いたか否かを判別する（ステップ３０５）。不確実知識の使用の有無は、プランニングにおいて不確実知識を用いる度にその旨のデータを記録しておいて、記録したデータに基づいて判別してもよいし、作成されたプラン自体を再度検索することによって、不確実知識が含まれているか否かを判別してもよい。
【００９６】
〔２−６．不確実知識の分類〕
不確実知識は、他のプラットフォーム（以下「目的のプラットフォーム」と呼ぶ）での処理によって確認される知識であるから、プランに不確実知識が用いられた場合、そのプランによって目的が達成されるためには、不確実知識を確認する処理が必要である。ここでは、不確実知識を確認する処理は、プラン実行に先だって行なう。
【００９７】
そして、決定部１３は、不確実知識ごとに、その不確実知識の確認をエージェントの移動で行うべきか、協調で行うべきかを決定することで、例えば「移動」と「分類」の２種類に分類する（ステップ３０６）。この分類では、決定部１３は、次の（１）から（３）の３つの条件を同時に満たす不確実知識について、確認を移動で行うと決定し、条件の１つでも満たさない不確実知識については、確認を協調で行うと決定する。
【００９８】
（１）エージェントが現在いるプラットフォームと目的のプラットフォームとを結ぶ通信回線の信頼性が低いこと
通信回線の信頼性が高ければ目的のプラットフォームと通信を続けることができるためであり、このような通信回線の信頼性は、通信回線の信頼性に関する情報（図６）から、次のように調べることができる。例えば、図６の情報では、個々の通信回線ごとに、どのプラットフォームとどのプラットフォームを接続しているかが記録されている。このため、この２つプラットフォームの組み合わせが、現在のプラットフォームと目的のプラットフォームに一致する通信回線を探し、その通信回線の信頼性を読み出せばよい。
【００９９】
（２）目的のプラットフォームがモバイルをサポートしていること
（３）エージェントの属性がモバイルであること
目的のプラットフォームとエージェントの両方がモバイルをサポートしていなければ、エージェントが移動したり移動先のプラットフォームで活動することができないためである。このうち目的のプラットフォームがモバイルをサポートしているかどうかは、図３に例示したプラットフォームプロファイル５２を参照することで判断でき、また、エージェントがモバイルをサポートしているかどうかは、図４に例示したエージェント属性５３を参照することで判断できる。
【０１００】
なお、必ずしもこれら３つの条件全てに基づいて判断しなければならないわけではない。例えば、ネットワーク内の全てのプラットフォームがモバイルをサポートしていることが予めわかっているような場合は、１つ又は２つの条件で判断することもできる。また、不確実知識が確認できるプラットフォームやそのプラットフォームにいるエージェントが、モバイルではなく、協調動作をサポートしているかどうかなどを、判断の項目に加えることもできる。
【０１０１】
続いて、上に述べたような分類にしたがって、不確実知識の確認が行われる。すなわち、確認を協調で行うと決定された不確実知識については協調部１１が契約ネットプロトコル手続きに基づいて確認を行い（ステップ３０７）、一方、確認を移動で行うと決定された不確実知識については移動部１２がエージェントを移動させることによって確認を行う（ステップ３０８）。
【０１０２】
なお、不確実知識を移動で確認するか協調で確認するかは、プランニング後に決定部１３が行うので、プランニングでは不確実知識の確認のために移動するか協調するかをプランで指定する必要がない。このため、プランニングの手順も単純で済み、処理が効率化される。
【０１０３】
〔２−７．契約ネットプロトコル手続き〕
次に、契約ネットプロトコル(Contract Net Protocol) 手続きの詳細を図１３に示す（参考文献：Smith, R. G., "The Contract Net Protocol: High-level Communication and Control in a Distributed Problem Solver", IEEE Trans. Computers, Vol. 29, pp. 1104-1113(1980). ）。ここで、契約ネットプロトコルでは、エージェントから他のエージェントに依頼される作業をタスクと呼ぶ。また、タスクをエージェント間で依頼する契約ネットプロトコルは、実際には、エージェントが存在するプラットフォームの協調部１１同士の間で行なわれる。
【０１０４】
〔２−７−１．タスクアナウンス〕
契約ネットプロトコルにおいてタスク実行を依頼する場合は、まず、タスクを持つエージェント（以下、タスクマネジャと呼ぶ）が、ステップ６０１において、タスクを依頼したいプラットフォーム群に対して依頼に関する情報（以下「タスク情報」という）をブロードキャストする。なお、ブロードキャストとは一定範囲の相手に対して無差別に情報を送信することであり、タスク情報をブロードキャストすることをタスクアナウンスという。ブロードキャストするタスク情報としては、例えば、タスクＩＤ、タスクの内容、タスクマネジャのＩＤ、プラン評価基準、入札期限などがある。
【０１０５】
〔２−７−２．入札〕
上に述べたようなタスク情報を受信したプラットフォームは、各フィールドにエージェントを生成し、それらにタスク情報を転送する（ステップ６０２）。タスク情報を受け取った各エージェントは、自らが所属しているフィールドにおいてタスクを実行可能かどうか判断し（ステップ６０３）、タスク内容を実行可能なエージェントは、入札する旨の情報（以下「入札情報」や「入札メッセージ」という）をタスクマネジャに送信（入札）する（ステップ６０４）。なお、入札情報を送信したエージェントを入札エージェントと呼ぶ。
【０１０６】
入札情報には、例えば、タスクＩＤ、エージェントＩＤ、タスク実行プラン評価値などがあり、このうちタスク実行プラン評価値は、タスクアナウンスで示されたプラン評価基準に基づいて、入札エージェントが、自分がタスクを実行する場合における評価を計算したものである。
【０１０７】
〔２−７−３．入札締切と落札〕
タスクマネジャは、入札を締め切る入札期限と現在時刻を比較しながら入札情報を受信し、ステップ６０５において入札期限に到達すると、次のステップ６０６において入札締切を示すメッセージを発信する。この締切のメッセージは、タスク情報のブロードキャスト先とした全ての依頼プラットフォームに対してブロードキャストする。そして、タスクマネジャは、ステップ６０９において、落札するエージェントを決定する。この決定は、入札期限までに受信した各入札情報のタスク実行プラン評価値と、予め定めた決定の基準に基づいて、各エージェントの入札情報を比較することによって行なう。
【０１０８】
落札するエージェント（落札エージェントと呼ぶ）の決定は、タスクマネジャが、実際にタスクを依頼する先としてそのエージェントを決定することを意味するが、実際にタスクを依頼する時期は処理の内容に応じて異なっていてもよく、契約ネットプロトコルの終了後に直ちに依頼する場合もあれば、所定の時期まで待って依頼する場合もある。
【０１０９】
落札エージェントを決定すると、タスクマネジャは、ステップ６１０において、各入札エージェントに、落札の内容を表す落札情報をマルチキャスト（同報送信）する。この落札情報を受信することによって、落札エージェントは、タスクを実際に実行すべき旨の実行依頼を待つ状態となる。タスクマネジャは、落札されたタスクの実行をその後、落札エージェントに依頼し、その結果、落札エージェントは依頼されたタスクの内容を実際に実行する。
【０１１０】
上に述べたように、この実施の形態では、エージェント間協調を実現するために契約ネットプロトコルを用いる。そして、契約ネットプロトコルで処理を他のプラットフォームに依頼する場合は、依頼側プラットフォームの持つ条件と請負側プラットフォームの持つ能力との間で、入札制による調和が図られる。このため、システム全体として優れた処理効率が実現される。
【０１１１】
〔２−８．エージェントの移動の詳細〕
また、エージェントがプラットフォーム間で移動する場合の手順を図１４に示す。この例では、エージェントの移動元のプラットフォームをローカルノード、移動先のプラットフォームをリモートノードと呼ぶ。この場合、ローカルノードからの移動要求（ステップ５０１）を受信したリモートノードは（ステップ５０２）、エージェント用のプロセスを設定する（ステップ５０３）。
【０１１２】
続いて、リモートノードから、プロセスの設定が完了した旨の通知（ステップ５０４）を受信したローカルノードは（ステップ５０５）、エージェントのプランや変数領域などのエージェント情報をリモートノードに送信する（ステップ５０６）。このエージェント情報を受信したリモートノードは（ステップ５０７）、エージェント情報を格納し（ステップ５０８）、ローカルノードへ移動成功の通知を送信し（ステップ５０９）、プランの解釈実行を開始する（ステップ５１０）。一方、成功の通知を受信したローカルノードは（ステップ５１１）、不要になったエージェント用のプロセスを消去する（ステップ５１２）。
【０１１３】
〔２−９．プランの実行〕
図９のステップ３０５の判断で、プランに不確実知識が用いられていない場合は、実行部３が直ちにプランを実行し（ステップ３０９）、実行が成功すると手順を終了するが、実行に失敗すると再プランニングを行う。なお、プランに不確実知識が用いられていた場合は、上に述べたように、契約ネットプロトコル（図９のステップ３０７）やエージェントの移動（ステップ３０８）によって不確実知識が確認され、その時点までのプランが実質的に完成してから、実行部３がプランを実行する（ステップ３０９）。
【０１１４】
なお、これら契約ネットプロトコルやエージェントの移動を具体的にどの時点で行い、その結果をどのように使うかは、どのようなときにどのように再プランニングを行うかといった具体的な構成や情報処理の内容などに応じて異なることも考えられるが、例えば次のような例が考えられる。
【０１１５】
この例は、移動の条件を満たしても一律に移動とはせず、移動を使うプランと協調を使うプランを両方作って比較し、有利な方を実行するものである。このような場合は、まず、ステップ３０７の契約ネットプロトコル手続きを使ってゴールの達成を試みるプランを作成し、次に、不確実知識を確認できるプラットフォームに対しステップ３０８のエージェント移動手続きを使って移動することでゴールを達成するプランを作る。そして、このように作ったプラン同士を、必要なデータの量や通信の量などをコストと考えて評価し、コストの最も低い有利なものを選択し、実行する。なお、実行失敗時には再プランニングとして以上のプランニング手順を繰り返す。
【０１１６】
〔２−１０．移動時の例外への対応〕
また、この実施形態では、プラットフォーム間でエージェントを移動させようとするとき、エラーなどの例外が発生しても、対処部１４が例外記述５４に基づいて例外への対処を行う。例えば、移動元のプラットフォームから移動先のプラットフォームに対して、移動手続きの実行通知を送信している最中に、移動先からの応答がなくなり、タイムアウトが発生する場合を考える。
【０１１７】
すなわち、移動に使おうとしている通信回線の信頼性が低い場合、移動元のプラットフォームでは、タイムアウト検知部１５がタイムアウトを検知して対処部１４に知らせ、対処部１４は、図５に示したような例外記述５４にしたがって、次のように対処する。
【０１１８】
すなわち、対処部１４は、移動元のプラットフォームの移動部１２を一旦待ち状態に移行させたうえ、予め決められた待ち時間が経過するごとに移動先への通知を再試行させる。この再試行で、反応が途絶えることなく移動先の計算機に通知が届けば、移動部１２は通常の移動手続きを続行する。その後また反応途絶が発生すれば、再び移動待ち状態に移行し、上に述べたように、待ち時間後の再試行を繰り返す。
【０１１９】
〔２−１１．エージェント間での情報交換〕
また、契約ネットプロトコルによるタスクの依頼など、エージェント間で協調動作を行なう場合、あるエージェントが他のエージェントの振る舞いを制御することによって、予期せぬ状況変化に柔軟に対応することが望ましい。この実施の形態では、図８に示した階層的な黒板部８と、黒板管理部９とを次にように使って、このような柔軟な対応を実現する。
【０１２０】
すなわち、個々のエージェントは、黒板部８のどれか１つの階層に、エージェントの優先度に応じて対応付けられていて、図８の例では、エージェントの７０２と７０３のどちらも、黒板部８の下位階層に対応付けられているものとする。そして、他のエージェントに送る通常の情報は、自分の優先度と同じ階層に記入しておくと、受け取る側のエージェントは、処理の区切りがついたときなどに黒板部８の下位階層を参照し、自分宛のメッセージを発見して受け取る。
【０１２１】
一方、エージェントが、自分に設定された優先度に本来対応する階層よりも高い階層、すなわち上位階層へデータを記入すると、そのような記入は黒板管理部９が検出し、情報の宛先になっているエージェントにハードウェア割り込みなどで情報を通知する。このように、この実施の形態では、黒板部８が階層的に構成され、優先度の高い上位の階層に記入した情報の方が下位の階層に記入された情報よりも優先的に処理される。
【０１２２】
このため、エージェント間で交換する情報を重要度に応じた階層に記入することによって、エージェント間の協調関係を柔軟に制御できるので、予期せぬ状況の変化に対応することが容易になる。また、エージェント単位に優先度を設定しておき、優先度が高いエージェントが交換する情報ほど高い階層を用いたり、情報を黒板部８に入出力する処理も高い階層ほど優先して行なえば、一層きめ細かな制御も可能となる。
【０１２３】
〔３．情報処理の例〕
続いて、上に述べたようなこの実施形態の動作によって、図２で説明した具体的な問題を処理する例を示す。
【０１２４】
〔３−１．要求の入力と最初のプランニング〕
すなわち、上に述べたようなゴールplan_and_reserve_tickets(...) に基づいて最初にプランニングが行われる段階では、ゴールはまだ満足されていないので、プランニング部２は、ゴールを満足する動作を知識管理部６に問い合わせる。しかし、携帯計算機１０１には、要求の入力を受け付ける構成はあったが、ゴールを達成するために必要なチケットの予約手順がないものとする。
【０１２５】
この場合、知識管理部６は、知識格納部５内のプランニング用知識５１を検索した結果、ゴールを満足するために十分な動作がないと判断する。そこで、知識管理部６は、不確実知識である
maybe(plan_and_reserve_tickets(Requirements),ta)
を利用してゴールを満足できるかもしれないことをプランニング部２に伝える。
【０１２６】
この不確実知識は、チケットの予約手順は旅行代理店１０２すなわちノードｔａにあるかもしれないという内容であり、プランニング部２は、この不確実知識を使ったプランを生成する。この時点でのゴールと不確実知識との関係を図１５の概念図に示す。なお、図１５において、Ｋ１〜Ｋ５のような確定している知識は実線の図形で表わし、Ｍ１のような不確実知識は破線の図形で表わす。
【０１２７】
〔３−２．旅行代理店への移動〕
エージェント管理部１は、この不確実知識が確認できる目的のプラットフォームであるノードｔａが、どのような回線で接続されていて、また、エージェントｕｓｅｒ及びノードｔａがモバイルをサポートしているかどうかを知識管理部６に問い合わせる。
【０１２８】
この場合、知識管理部６は、知識格納部５の例外記述５４に記述されている回線の信頼性に関する情報を参照し、携帯計算機１０１が、ノードｔａに信頼性の低い無線回線Ｃ１で接続されていることが判明するため（図６）、その旨を知らせるmobile_connection(ta) といった形式の情報をエージェント管理部１に返信する。
【０１２９】
また、同じように、エージェント管理部１は、知識格納部５に格納されたプラットフォームプロファイル５２とエージェント属性５３に基づいて、エージェントｕｓｅｒとノードｔａの両方がモバイルをサポートしていることを確認する。
【０１３０】
この場合、エージェント管理部１が、エージェントを移動させるための３つの条件
（１）エージェントが現在いるプラットフォームと目的のプラットフォームとを結ぶ通信回線の信頼性が低いこと
（２）目的のプラットフォームがモバイルをサポートしていること
（３）エージェントの属性がモバイルであること
が満たされることを確認する結果、プランニング部２がノードｔａに移動するプランを生成し、このプランにしたがって移動部１２がエージェントｕｓｅｒをノードｔａに移動させる。
【０１３１】
〔３−３．予約手順に基づくプランニング〕
ノードｔａでは、不確実知識の指していた予約手順が発見され、不確実知識Ｍ１は、図１６に示すように、確定した知識Ｋ６となる。このため、エージェントは、この知識Ｋ６の指す予約手順を使って、ゴールresolve_goal(plan_and_reserve_tickets(...)を満たすために再プランニングを行う。その結果、次のようなプランが生成される。
【０１３２】
〔３−４．移動による経路の検索〕
この実行では、まず、動作
【０１３３】
そこで、プラン実行失敗の原因となった動作
exists(routeDB(tokyo,a_university))
をゴールとして再プランニングを行う。この事前条件は、経路のデータベース（ＤＢ）が存在していることを意味する。その結果、この事前条件は、不確実知識
【０１３４】
この不確実知識Ｍ２は、経路のデータベースは観光局１０５にあるかも知れないという内容である。この不確実知識についてエージェント管理部１が分類を行うときは、エージェントの現在地であるノードｔａからみて、目的のプラットフォームである
a_tourist_bureau_site
すなわち、観光局１０５がやはり信頼性の低い回線で接続されていることが分かる。また、エージェントｕｓｅｒはすでに述べたようにモバイルをサポートしていて、さらに、この目的のプラットフォームである観光局１０５もモバイルをサポートしている（図３）。
【０１３５】
このため、この不確実知識も、移動によって確認すべきと判断され、プランニング部２は、エージェントが観光局１０５に移動後検索を行い、再び旅行代理店１０２に戻るプランを作成し実行する。今回は、観光局１０５に存在するデータベースから次の情報を検索するという処理Ｐ１に成功し、図１７に示すように、不確実知識Ｍ２は確定した知識Ｋ７となる。
route([tokyo,city1],[city1,a_university])
route([tokyo,city2],[city2,a_university])
これらの情報は、東京から地方大学に行くには、ｃｉｔｙ１を経由する経路と、ｃｉｔｙ２を経由する経路があることを意味する。以下、これらの都市はそれぞれ都市１および都市２と呼ぶ。
【０１３６】
なお、この例のように利用交通機関を指定した経路の検索では、指定された交通機関、すなわちここでは航空機を含んだ経路が検索される。この場合は、例えば東京から都市１への部分が航空機、残りの部分はバスだったものと仮定する。なお、説明を簡単にするため、都市２を経由する経路については省略し、次に述べる時刻表データベースに関する処理については図示しない。
【０１３７】
〔３−５．時刻表の入手〕
このように経路の検索に成功すると、エージェントｕｓｅｒは旅行代理店１０２であるノードｔａに戻り、続いて、図示はしないが、検索された経路に対応する時刻表を手に入れる動作retrieve_tt を実行しようとする。このとき、この動作も都市１から地方大学への交通機関の時刻表データベースがノードｔａに存在しないため失敗し、再プランニングとなる。その結果、やはり地方の観光局１０５にデータベースが存在するという不確実知識を得、上記と同様の移動・再プランニングとなる。
【０１３８】
ただ今回は、移動先の観光局１０５にもデータベースが存在しないとする。その場合、やはり観光局１０５において再プランニングを行い、今度は地方大学１０６にデータベースが存在するという不確実知識を使ったプランが生成される。この不確実知識については、地方大学１０６がモバイルをサポートしていないことから（図３）、協調によって確認すべきと決定される。この結果、エージェントｕｓｅｒは、地方大学１０６のエージェントとの協調によって、都市１から地方大学への交通機関（バス）の時刻表を検索する。
【０１３９】
〔３−６．協調による航空機の予約〕
次に、エージェントｕｓｅｒは、reserve_tickets を実行しようとする。この場合、ここまでの処理によって、図１７に示すように、予約は航空機（Ｐ２）とバス（Ｐ３）の両方について行うことになっているものとする。このうち、まず、航空機の予約に必要な予約受付データベース（チケットデータベース）がノードｔａに存在しないため、再プランニングを行い、その結果、２つの航空会社ａｉｒｌｉｎｅ１、ａｉｒｌｉｎｅ２（以下、それぞれ航空会社１、２とする）に存在するとの不確実知識Ｍ４を得る。
【０１４０】
ここで、この２つの会社の計算機とは、信頼性の高い回線で接続されているとの知識も得られるため、エージェントの移動ではなく、今回は契約ネットプロトコル手続きを実行する。この契約ネットプロトコルでは、エージェントｕｓｅｒは、２つの航空会社社１，２（１０３，１０４）の計算機上のエージェントに、次のようなタスクアナウンスメッセージを送信する。
【０１４１】
【０１４２】
このタスクアナウンスメッセージを受信した航空会社の各エージェントは、ゴール
ticket_reserved(tokyo,city1)
に対しプランニングを行い、その結果、それぞれプラン
reserve_ticket(tokyo,city1)
を作成する。次に各航空会社１，２のエージェントは、作成したプランについてコストを計算する。ここで計算するコストは、タスクアナウンスメッセージに含まれたｐｒｉｃｅ、すなわち、チケットの値段とする。その結果、航空会社１、２のチケットの値段がそれぞれ２００００円、および２３０００円であったとする。
【０１４３】
この場合、各航空会社１，２のエージェントは、以上の結果をそれぞれ以下のような入札メッセージを、旅行代理店１０２で動作中のエージェントに返信する。
【０１４４】
【０１４５】
〔３−７．バスの予約〕
このようにして、航空機を予約する処理Ｐ２が終了すると、エージェントｕｓｅｒは、次に、最終ゴールである
resolve_goal(plan_and_reserve_tickets(...))
にとって必要なもう１つの処理、すなわちバスを予約する処理Ｐ３を行う。
【０１４６】
バスを予約する処理Ｐ３は、事前条件としてバスの予約受付データベース（ＤＢ）の存在を必要とする。この予約受付データベースは、エージェントｕｓｅｒの現在地であるノードｔａには存在しないので、実行失敗に続いて再プランニングが行われる結果、バスの予約受付データベースは観光局１０５にあるという不確実知識を使ったプランが得られる。
【０１４７】
観光局１０５は、上に述べたように移動の条件を満たすのでエージェントｕｓｅｒは観光局１０５に移動してバスの予約受付データベースを探すが発見できず、次に、バスの予約受付データベースは地方大学１０６にあるという不確実知識を使ったプランが得られる。
【０１４８】
このとき、地方大学１０６は、モバイルをサポートしていないので、契約ネットプロトコルによってバスを予約する処理Ｐ３を行い、これによって予約完了という最終ゴールが達成される。なお、最初の不確実知識から最終ゴールに至る全体的な流れの概略を図１８に示す。
【０１４９】
〔４．効果〕
以上説明したように、この実施形態では、個々のプラットフォームが移動型のモバイルエージェントをサポートしているかどうかの情報をプラットフォームプロファイル５２として用意しておく。そして、エージェントが他のプラットフォームの資源を使うとき、そのエージェントを当該他のプラットフォームへ移動させるか、そのエージェントから当該他のプラットフォームのエージェントに処理を依頼させる（協調）かは、このプラットフォームプロファイル５２に基づいて容易に決めることができる。
【０１５０】
例えば、エージェントが他のプラットフォームの資源を使うとき、そのプラットフォームとの間の回線の信頼性が低ければ、そのプラットフォームに移動することが望ましいが、そのプラットフォームがモバイルエージェントをサポートしていないことをプラットフォームプロファイル５２から予め判断することで、移動を試すまでもなく、そのプラットフォームのエージェントと協調を行うべきだと判断できる。なお、複数のエージェント間で協調を行うには、従来から知られているエージェント間協調の技術、例えば契約ネットプロトコルや、黒板機能などを使っている。
【０１５１】
また、この実施形態では、エージェントごとに、プラットフォーム間で移動する能力を持つモバイルエージェントか、移動する能力を持たないステーショナリエージェントかの情報をエージェント属性５３として用意しておく。そして、エージェントが他のプラットフォームの資源を使うとき、そのエージェントを当該他のプラットフォームへ移動させるか、そのエージェントから当該他のプラットフォームのエージェントに処理を依頼させる（協調）かは、このエージェント属性に基づいて容易に決めることができる。
【０１５２】
特に、この実施形態では、エージェントが他のプラットフォームの資源を使うとき、移動か協調かは、上に述べたようなプラットフォームプロファイル５２とエージェント属性５３の両方に基づいて決める。例えば、そのエージェントとプラットフォームの両方が移動をサポートしていればエージェントを移動させるが、どちらか一方でもサポートしていなければ協調とする。これによって、移動機能を持つモバイルエージェントとステーショナリエージェントの統合的活用が容易になる。
【０１５３】
また、この実施形態では、プランニングによってネットワークの予期せぬ変化に柔軟に対応できる。そして、プランニングによってエージェントのプランが変わり、どのエージェントがどのプラットフォームの資源を使うことになっても、プラットフォームプロファイル５２やエージェント属性５３に基づいて移動か協調かを容易に決めることができる。このように、移動と協調とを使い分けることで、ネットワークという分散環境でエージェントを使う情報処理が効率化される。また、ネットワークの変化にもプランニングで対応しながら、エージェントの移動と協調とを有効に結び付けて活用するので、開放型ネットワークでも効果的に情報処理を行うことができる。
【０１５４】
また、この実施形態では、エージェントがプラットフォーム間で移動しようとするときに移動失敗などの例外が発生しても、そのような例外に適切に対応することで情報処理が円滑に行われる。特に、この実施形態では、移動時のどのような例外に対してどのように対処するかは例外記述５４に表わしておき、例外記述を書き換えることで対処の内容を容易に変更することができる。
【０１５５】
さらに、この実施形態では、移動のときによく起きがちな例外、すなわち移動先との通信の失敗、移動先の指定が無効、移動先がモバイルエージェントに対応していない、移動先での資源不足、のうち少なくとも１つに対する対処を例外記述５４に表わしておくので、例外に効果的に対処することができる。
【０１５６】
特に、この実施形態では、どの通信回線の信頼性が低いかの情報を予め各プラットフォームなどに用意しておき、エージェントがそのような回線を通して移動しようとするときに通信が途絶したときの対応を決めておく。これによって、通信回線の信頼性が低く、通信が途絶しやすい場合でも動作不全や故障などが起きにくくなる。
【０１５７】
具体的には、この実施形態では、エージェントを移動させるための通信が途絶えるとしばらく待ってから再び通信を試みる処理が繰り返される。このため、通信回線の信頼性が低くても、状態がよくなっている間にエージェントの情報を送ってエージェントを移動させることができる可能性が高くなる。
【０１５８】
さらに、この実施形態では、プランニングに使う知識などプラットフォームの資源が情報処理の目的や知識の適用分野などを基準に、フィールドごとに分けて管理される。このため、あるフィールドのエージェントは、自分の目的と関係ない知識まで参照する必要がなく、効率的にプランニングをすることができる。
【０１５９】
加えて、この実施形態では、ネットワークの予期せぬ変化のような急ぎの情報は、例えば、黒板の上位階層に書き込むことで、エージェントの通常の動作に割り込ませ、そのような変化に対応してエージェントの動作を制御することができる。
【０１６０】
〔５．他の実施形態〕
なお、この発明は上に述べた実施形態に限定されるものではなく、次に例示するような他の実施形態をも含むものである。例えば、この発明において、ネットワークの規模、形式、プラットフォーム数などは自由であり、エージェントを用いて行う情報処理の種類や、動作、知識、プランなどを記述する言語の形式も自由に選択しうる。また、この発明はチケット予約以外の課題に適用できることはもちろんである。
【０１６１】
また、図に示したプラットフォームプロファイル５２（図３）、エージェント属性５３（図４）、例外記述５４（図５、図６）などの形式や内容は例示に過ぎず、他の形式にしたり、それらの情報にどのような項目を含めるかなどは自由に変更することができる。また、例えば、例外記述をエージェント属性などと一緒に、又はそのような情報に対応付けて格納しておくこともできる。また、同じように、通信回線の信頼性に関する情報は、例外記述の一部とせずに、独立した情報として格納しておいてもよいし、プラットフォームプロファイルの一部としてもよい。
【０１６２】
また、上に述べた実施形態では、プラットフォームプロファイル、エージェント属性、例外記述などをプラットフォームごとの知識格納部に格納したが、これらの情報は、エージェントが所有する情報として実現し、エージェントが他のプラットフォームに移動のため転送されるときは、これらの情報がエージェントと一緒に転送されるようにしてもよい。
【０１６３】
また、上に述べた実施形態では、プランニングを行うエージェントを主に例示したが、この発明は、プランニングを行わないエージェントに適用することもできる。また、対処部、例外記述を含めた例外に対応するための構成やタイムアウト検知部は必ずしも設ける必要はなく、また、例外記述の内容も実施形態に示した実例にかかわらず、自由に定めることができる。
【０１６４】
また、同じように、各プラットフォームには必ずしも複数のフィールドを設ける必要はなく、また、黒板部や黒板管理部もこの発明にとって必須ではない。
【０１６５】
【発明の効果】
以上のように、この発明によれば、モバイルエージェントとステーショナリエージェントとを状況に応じて動的に使い分けることで円滑に情報を処理することができる。
【図面の簡単な説明】
【図１】この発明の実施形態の構成を示す機能ブロック図。
【図２】この発明の実施形態における問題の内容を示す概念図。
【図３】この発明の実施形態におけるプラットフォームプロファイルの例を示す図。
【図４】この発明の実施形態におけるエージェント属性の例を示す図。
【図５】この発明の実施形態における例外記述の例を示す図。
【図６】この発明の実施形態における通信回線の信頼性に関する情報の例を示す図。
【図７】この発明の実施形態におけるフィールドを示す概念図。
【図８】この発明の実施形態における黒板部を示す概念図。
【図９】この発明の実施形態における処理手順を示すフローチャート。
【図１０】この発明の実施形態において、生成途中のプランを示す概念図。
【図１１】この発明の実施形態において、完成したプランを示す概念図。
【図１２】この発明の実施形態におけるプラン生成の具体的な手順を示すフローチャート。
【図１３】この発明の実施形態における契約ネットプロトコルの手順を示すフローチャート。
【図１４】この発明の実施形態において、エージェントがプラットフォーム間で移動する手順を示すフローチャート。
【図１５】この発明の実施形態における問題の例について、ゴールを達成する途中経過を示す概念図。
【図１６】この発明の実施形態における問題の例について、ゴールを達成する途中経過を示す概念図。
【図１７】この発明の実施形態における問題の例について、ゴールを達成する途中経過を示す概念図。
【図１８】この発明の実施形態における問題の例について、ゴールを達成する途中経過を示す概念図。
【図１９】従来のエージェントシステムの一例を示すブロック図。
【図２０】プランニングを使う従来のエージェントシステムの例を示すブロック図。
【図２１】プランニングを使う従来のエージェントシステムにおける処理手順を示すフローチャート。
【図２２】プランニングを使う従来のエージェントシステムにおけるエージェントのライフサイクルを示す概念図。
【符号の説明】
１…エージェント管理部
１１…協調部
１２…移動部
１３…決定部
１４…対処部
１５…タイムアウト検知部
２…プランニング部
３…実行部
４…エージェント情報格納部
５…知識格納部
５１…プランニング用知識
５２…プラットホームプロファイル
５３…エージェント属性
５４…例外記述
６…知識管理部
７…フィールド管理部
８…黒板部
９…黒板管理部
２０…入出力部
Ｌ…ローカルマシン
Ｒ…リモートマシン
Ｎ…ネットワーク
Ｃ…条件
Ｐ…動作
Ｓ…状態
８００Ｎ…ネットワーク
８００Ｌ…ローカルノード
８００Ｒ…リモートノード
８０１…エージェント情報記憶手段
８０２…解釈実行手段
８０３…入出力手段
８０４…エージェント管理手段
ＳＴＥＰ…手順の各ステップ
Claims (15)
- ネットワークで互いに接続された複数のプラットフォーム上でソフトウェアエージェントに情報処理を行わせる情報処理装置において、
エージェントに他のプラットフォームの資源を使わせるとき、そのエージェントを当該他のプラットフォームへ移動させる移動手段と、
エージェントに他のプラットフォームの資源を使わせるとき、そのエージェントから当該他のプラットフォームのエージェントに処理を依頼させる協調手段と、
個々のプラットフォームが移動されたエージェントを受け入れて活動させる手段を備えているかどうかを表わすプラットフォームプロファイルを格納する手段と、
個々のエージェントがプラットフォーム間で移動する能力を持つかどうかに関するエージェント属性を格納する手段と、
エージェントに他のプラットフォームの資源を使わせるとき、前記プラットフォームプロファイル及び前記エージェント属性に基づいて、そのエージェントを当該他のプラットフォームへ移動させるか、そのエージェントから当該他のプラットフォームのエージェントに処理を依頼させるかを決定する決定手段と、
を備えたことを特徴とする情報処理装置。 - 与えられた要求を満たすエージェントのプランを生成するプランニング手段と、
生成されたプランを実行することでエージェントを動作させる実行手段と、
エージェントの動作に必要な情報を格納するためのエージェント情報格納手段と、
プラットフォーム上のエージェントに対して、他のプラットフォームに移動させ又は他のプラットフォームのエージェントに処理を依頼させることで他のプラットフォームの資源を使わせるエージェント管理手段と、
前記プランの生成、前記移動及び前記依頼に必要な知識を格納する知識格納手段と、
前記知識格納手段を管理する知識管理手段とを備えていることを特徴とする請求項１に記載の情報処理装置。 - エージェントがプラットフォーム間で移動しようとするときの例外に対応するための例外対応手段を備えたことを特徴とする請求項１又は請求項２に記載の情報処理装置。
- 前記例外対応手段は、どのような例外に対してどのように対処するかを表わす例外記述と、前記例外記述に基づいて例外に対処する対処手段と、を備えたことを特徴とする請求項３記載の情報処理装置。
- 前記例外記述は、（１）移動先として指定されたプラットフォームとの通信が失敗したためにエージェントが移動できない例外、（２）移動先の指定が無効であるためにエージェントが移動できない例外、（３）移動先として指定されたプラットフォームが移動されたエージェントを受け入れて活動させる手段を備えていないためにエージェントが移動できない例外、（４）移動先として指定されたプラットフォームにおける資源不足のためにエージェントが移動できない例外、のうち少なくとも１つについて、どのように対処するかを表わすことを特徴とする請求項４記載の情報処理装置。
- 前記例外記述は、前記通信回線のうち信頼性の低い通信回線に関する情報と、エージェントが前記信頼性の低い通信回線を通してプラットフォーム間で移動するときに発生する可能性がある例外に対してどのように対処するかを表わす情報と、を含むことを特徴とする請求項４又は５記載の情報処理装置。
- 前記通信回線で一定時間反応が途絶していることを検知するタイムアウト検知手段を備え、前記例外対応手段は、前記信頼性の低い通信回線を通してエージェントを移動させるための通信を行っているときに、前記タイムアウト検知手段が前記途絶を検知した場合、予め決められた待ち時間の後で前記通信を再び試みる処理を繰り返すように構成されたことを特徴とする請求項６記載の情報処理装置。
- 各プラットフォームは、異なった目的に対応する複数のフィールドを備え、プラットフォームの持っている資源をフィールドごとに分けて管理するフィールド管理手段を備えたことを特徴とする請求項１から７のいずれか１つに記載の情報処理装置。
- 複数のエージェントが情報をやり取りするための黒板手段と、前記黒板手段を、情報の優先度に応じた複数の階層に分けて管理することで各エージェントを協調させるように制御する黒板管理手段と、を備えたことを特徴とする請求項１から８のいずれか１つに記載の情報処理装置。
- 情報処理装置を使用して、ネットワークで互いに接続された複数のプラットフォーム上でエージェントに情報処理を行わせる情報処理方法において、
エージェントに他のプラットフォームの資源を使わせるとき、そのエージェントを当該他のプラットフォームへ移動させるステップと、
エージェントに他のプラットフォームの資源を使わせるとき、そのエージェントから当該他のプラットフォームのエージェントに処理を依頼させるステップと、
個々のプラットフォームが移動されたエージェントを受け入れて活動させる手段を備えているかどうかを表わすプラットフォームプロファイルと、個々のエージェントがプラットフォーム間で移動する能力を持つかどうかに関するエージェント属性に基づいて、エージェントに他のプラットフォームの資源を使わせるとき、そのエージェントを当該他のプラットフォームへ移動させるか、そのエージェントから当該他のプラットフォームのエージェントに処理を依頼させるかを決定するステップと、
を含むことを特徴とする情報処理方法。 - 与えられた要求を満たすエージェントのプランを生成するステップと、生成されたプランを実行することでエージェントを動作させるステップと、
エージェントの動作に必要な情報を格納し及び読み出すステップと、
プラットフォーム上のエージェントに対して、他のプラットフォームに移動させ又は他のプラットフォームのエージェントに処理を依頼させることで他のプラットフォームの資源を使わせるステップと、
前記プランの生成、前記移動及び前記依頼に必要な知識を格納し及び読み出すステップと、
前記知識格納手段を管理するステップと、
を備えていることを特徴とする請求項１０に記載の情報処理方法。 - 前記情報処理装置が、エージェントがプラットフォーム間で移動しようとするときの例外に対応するための例外対応手段を備え、
エージェントをプラットフォーム間で移動させるときの例外に対応するためのステップを含むことを特徴とする請求項１０又は１１に記載の情報処理方法。 - 前記例外対応手段は、どのような例外に対してどのように対処するかを表わす例外記述と、前記例外記述に基づいて例外に対処する対処手段と、を備え
前記例外に対応するためのステップが、どのような例外に対してどのように対処するかを表わす例外記述に基づいて例外に対処するステップを含み、
前記例外記述は、前記通信回線のうち信頼性の低い通信回線に関する情報と、エージェントが前記信頼性の低い通信回線を通してプラットフォーム間で移動するときに発生する可能性がある例外に対してどのように対処するかを表わす情報と、を含むことを特徴とする請求項１２に記載の情報処理方法。 - 前記通信回線で一定時間反応が途絶していることを検知するステップと、前記信頼性の低い通信回線を通してエージェントを移動させるための通信を行っているときに前記途絶が検知された場合、予め決められた待ち時間の後で前記通信を再び試みる処理を繰り返すことを特徴とする請求項１３記載の情報処理方法。
- コンピュータを使用して、ネットワークで互いに接続された複数のプラットフォーム上でエージェントに情報処理を行わせる情報処理用プログラムを記録したコンピュータ読取可能な記録媒体において、
前記プログラムは前記コンピュータに、
エージェントに他のプラットフォームの資源を使わせるとき、そのエージェントを当該他のプラットフォームへ移動させ、エージェントに他のプラットフォームの資源を使わせるとき、そのエージェントから当該他のプラットフォームのエージェントに処理を依頼させ、個々のプラットフォームが移動されたエージェントを受け入れて活動させる手段を備えているかどうかを表わすプラットフォームプロファイルを格納させ、個々のエージェントがプラットフォーム間で移動する能力を持つかどうかに関するエージェント属性を格納させ、エージェントに他のプラットフォームの資源を使わせるとき、前記プラットフォームプロファイル及びエージェント属性に基づいて、そのエージェントを当該他のプラットフォームへ移動させるか、そのエージェントから当該他のプラットフォームのエージェントに処理を依頼させるかを決定させることを特徴とする情報処理用プログラムを記録したコンピュータ読取可能な記録媒体。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP10154998A JP3688462B2 (ja) | 1998-04-13 | 1998-04-13 | 情報処理装置及び方法並びに情報処理用プログラムを記録した記録媒体 |
| US09/289,598 US6477563B1 (en) | 1998-04-13 | 1999-04-12 | Agent system and information processing method for same |
| US10/236,959 US6662207B2 (en) | 1998-04-13 | 2002-09-09 | Agent system and information processing method for same |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP10154998A JP3688462B2 (ja) | 1998-04-13 | 1998-04-13 | 情報処理装置及び方法並びに情報処理用プログラムを記録した記録媒体 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH11296374A JPH11296374A (ja) | 1999-10-29 |
| JP3688462B2 true JP3688462B2 (ja) | 2005-08-31 |
Family
ID=14303520
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP10154998A Expired - Lifetime JP3688462B2 (ja) | 1998-04-13 | 1998-04-13 | 情報処理装置及び方法並びに情報処理用プログラムを記録した記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3688462B2 (ja) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP1967961A3 (en) * | 2000-07-31 | 2008-09-17 | Kabushiki Kaisha Toshiba | Agent system |
| JP2007334475A (ja) * | 2006-06-13 | 2007-12-27 | Central Res Inst Of Electric Power Ind | エージェントプラットフォーム、エージェント管理方法、エージェント遠隔管理プログラムおよびエージェントシステム |
| JP2009211620A (ja) * | 2008-03-06 | 2009-09-17 | Hitachi Information Systems Ltd | 仮想環境複製方法とシステムおよびプログラム |
| US20120078724A1 (en) * | 2010-09-23 | 2012-03-29 | Sony Corporation | System and method for utilizing a morphing procedure in an information distribution network |
| US11693697B2 (en) * | 2020-12-06 | 2023-07-04 | International Business Machines Corporation | Optimizing placements of workloads on multiple platforms as a service based on costs and service levels |
| US11704156B2 (en) | 2020-12-06 | 2023-07-18 | International Business Machines Corporation | Determining optimal placements of workloads on multiple platforms as a service in response to a triggering event |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0749783A (ja) * | 1993-08-05 | 1995-02-21 | Meidensha Corp | 黒板モデルのデータ送信処理方法 |
| JP3622313B2 (ja) * | 1996-01-29 | 2005-02-23 | 株式会社日立製作所 | ドキュメント管理システム |
-
1998
- 1998-04-13 JP JP10154998A patent/JP3688462B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JPH11296374A (ja) | 1999-10-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US6662207B2 (en) | Agent system and information processing method for same | |
| Conry et al. | Multistage negotiation in distributed planning | |
| US8417762B2 (en) | Mechanism for execution of multi-site jobs in a data stream processing system | |
| US6529934B1 (en) | Information processing system and method for same | |
| US8359347B2 (en) | Method and apparatus for cooperative data stream processing | |
| US6557025B1 (en) | Method and apparatus that improves the technique by which a plurality of agents process information distributed over a network through by way of a contract net protocol | |
| CN103947140B (zh) | 用于位置无关软件的需求驱动的部署的系统和方法 | |
| US20030055668A1 (en) | Workflow engine for automating business processes in scalable multiprocessor computer platforms | |
| CN102035886A (zh) | 联盟基础结构内的一致性 | |
| JP3688462B2 (ja) | 情報処理装置及び方法並びに情報処理用プログラムを記録した記録媒体 | |
| JPH10333925A (ja) | オートノマス・エージェント・アーキテクチャ | |
| JP3799925B2 (ja) | エージェントサービス提供方法及びコンピュータ読み取り可能な記録媒体 | |
| Quang et al. | Device-driven on-demand deployment of serverless computing functions | |
| US20030212587A1 (en) | Apparatus and methods for coordinating Web services using role based interpretation of coordination plans | |
| CZ9903576A3 (cs) | Mobilní objekty, zpusob pro rízení mobilních objektu, zpusob a zarízení pro generování skupiny mobilních objektu a pametové médium pro ukládání programu pro generování skupiny mobilních objektu | |
| JP2007265043A (ja) | スケジューラプログラム、サーバシステム、スケジューラ装置 | |
| JP5084355B2 (ja) | フロー処理実行装置、フロー処理実行方法及びプログラム | |
| JP2002108838A (ja) | エージェント実行装置およびエージェント実行方法 | |
| JP2000029847A (ja) | エージェントシステム、情報処理方法及び情報処理用ソフトウェアを記録した記録媒体 | |
| JP2021149461A (ja) | 情報処理装置、情報処理システム、及びプログラム | |
| JPH09160847A (ja) | クライアント・サーバ型分散処理システム | |
| JP2001067325A (ja) | 分散オブジェクト管理方法およびシステム | |
| Shah | To Improve Execution of Mobile Agent in Network Environment using Fault Tolerance Technique | |
| Graham et al. | A Programming and Execution Environment for Distributed Multi Agent Systems | |
| JPH10214289A (ja) | ワークフローシステムにおける複数サーバ間の情報取得方法及びシステム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040706 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040906 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20050531 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20050608 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090617 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090617 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100617 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100617 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110617 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120617 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120617 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130617 Year of fee payment: 8 |
|
| EXPY | Cancellation because of completion of term |