(57)【特許請求の範囲】
【請求項１】
ネットワーク上に存在する複数の領域でソフトウェアエージェントを移動させながら情報処理を行うエージェントシステムにおいて、
前記ソフトウェアエージェントを管理するエージェント管理手段と、
前記複数の領域を個別に管理する各領域管理手段と、
ネットワーク上の各領域が信頼できるかどうかを表す第１の情報を格納する第１情報格納手段を備え、
前記エージェント管理手段は、ソフトウェアエージェントを領域間で移動させようとするとき、移動先の領域の信頼性を前記第１の情報に基づいて判断し、信頼できる領域へのみソフトウェアエージェントを移動させるように構成され、
前記各領域管理手段は、ソフトウェアエージェントが他の領域から移動してこようとするとき、移動元の領域の信頼性を前記第１の情報に基づいて判断し、信頼できる領域から移動してくるソフトウェアエージェントのみを受け入れるように構成された
ことを特徴とするエージェントシステム。
【請求項２】
ソフトウェアエージェントがどの領域に移動したかを履歴に順次記録する履歴管理手段を備え、
前記各領域管理手段は、ソフトウェアエージェントが他の領域から移動してこようとするとき、当該ソフトウェアエージェントの前記履歴、前記第１の情報及び予め定められた基準に基づいて、当該ソフトウェアエージェントを受け入れるかどうかを判断するように構成された
ことを特徴とする請求項１記載のエージェントシステム。
【請求項３】
各領域においてソフトウェアエージェントにプランニングが認められるかどうかを表す第２の情報を格納する第２情報格納手段を有し、
前記エージェント管理手段は、前記第２の情報を参照することによって、プランニングを認めない領域ではプランニングを回避するように構成された
ことを特徴とする請求項１又は２記載のエージェントシステム。
【請求項４】
前記第１の情報又は前記第２の情報のうち少なくとも一方が、１箇所の前記格納手段に集中して保存される
ことを特徴とする請求項１記載のエージェントシステム。
【請求項５】
ネットワーク上に存在する複数の領域で、ソフトウェアとコンピュータから構成されるエージェント管理手段、領域管理手段、格納手段によりソフトウェアエージェントを移動させながら情報処理を行う情報処理方法において、
ネットワーク上の各領域が信頼できるかどうかを表す第１の情報が前記格納手段に格納され、
前記エージェント管理手段により、ソフトウェアエージェントを領域間で移動させようとするとき、移動先の領域の信頼性を前記第１の情報に基づいて判断し、信頼できる領域へのみソフトウェアエージェントを移動させるステップと、
前記領域管理手段により、ソフトウェアエージェントが領域間で移動しようとするとき、移動元の領域の信頼性を前記第１の情報に基づいて判断し、信頼できる領域から移動してくるソフトウェアエージェントのみを移動先の領域に受け入れるステップと、
を含むことを特徴とする情報処理方法。
【請求項６】
前記ソフトウェアとコンピュータから構成される履歴管理手段により、ソフトウェアエージェントがどの領域に移動したかを前記格納手段に格納された履歴に順次記録するステップと、
前記領域管理手段により、ソフトウェアエージェントが領域間で移動しようとするとき、当該ソフトウェアエージェントの前記履歴、前記第１の情報及び予め定められた基準に基づいて、当該ソフトウェアエージェントを移動先の領域に受け入れるかどうかを判断するステップと、
を含むことを特徴とする請求項５記載の情報処理方法。
【請求項７】
各領域においてソフトウェアエージェントにプランニングが認められるかどうかを表す第２の情報が前記格納手段に格納され、
前記管理手段により、前記第２の情報を参照することによって、プランニングを認めない領域ではプランニングを回避するステップ
を含むことを特徴とする請求項５又は６記載の情報処理方法。
【請求項８】
コンピュータを用いて、ネットワーク上に存在する複数の領域でソフトウェアエージェントを移動させながら情報処理を行う情報処理用プログラムを記録した記録媒体において、
当該情報処理用プログラムは前記コンピュータに、
ネットワーク上の各領域が信頼できるかどうかを表す第１の情報を保持させ、
ソフトウェアエージェントが領域間で移動しようとするとき、移動先の領域の信頼性を前記第１の情報に基づいて判断させて、信頼できる領域へのみソフトウェアエージェントを移動させ、
ソフトウェアエージェントが領域間で移動しようとするとき、移動元の領域の信頼性を前記第１の情報に基づいて判断させて、信頼できる領域から移動してくるソフトウェアエージェントのみを移動先の領域に受け入れさせる
ことを特徴とする情報処理用プログラムを記録した記録媒体。
【請求項９】
前記情報処理用プログラムは前記コンピュータに、
ソフトウェアエージェントがどの領域に移動したかを履歴に順次記録させ、
ソフトウェアエージェントが領域間で移動しようとするとき、当該ソフトウェアエージェントの前記履歴、前記第１の情報及び予め定められた基準に基づいて、当該ソフトウェアエージェントを移動先の領域に受け入れるかどうかを判断させる
ことを特徴とする請求項８記載の情報処理用プログラムを記録した記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク上に分散して存在する情報をエージェントを用いて処理する技術の改良に関するもので、特に、エージェントによる動作の柔軟性と安全性を高めたものである。
【背景技術】
【０００２】
〔エージェントシステム〕
従来から、コンピュータのネットワーク上に分散した情報を処理する技術として、エージェントシステムが知られている。エージェントとは、ソフトウェア上の処理単位であり、周囲の状況に応じて自律的に動作するものである。エージェントシステムは、このようなエージェントが、ネットワークを構成するノード上を必要に応じて移動しながら情報収集などの処理を行うシステムである。ここで、ノードとは、ネットワークを構成する論理的な単位であり、一つのマシンすなわちコンピュータ上に複数存在し得る。
【０００３】
図１５は、このようなエージェントシステムの一例として、本出願人が特許文献１で提案しているエージェントシステムについて、その構成例を示す機能ブロック図である。この図に示すエージェントシステムは、複数のノード８００をネットワーク８００Ｎで接続したものであり、多数設けることができるノードのうち図１５では２つだけを例示している。そして、ノード８００のうち、ユーザがエージェント生成に使用するノードをローカルノード（８００Ｌ）と呼び、生成されたエージェントが移動して行く先のノードをリモートノード（８００Ｒ）と呼ぶ。
【特許文献１】特開平１０−１４９２８７号公報
【０００４】
このエージェントシステムにおいて、各ノード８００は、ユーザがエージェントを生成する操作を行ったり、エージェントが情報処理を行った結果を受け取るための入出力手段８０３（Ｌ，Ｒ）を有する。また、各ノードのエージェント管理手段８０４（Ｌ，Ｒ）は、エージェントを生成したり、役割を終えたエージェントを消去する他、エージェントの情報を他のノードへ転送することによって、エージェントを他のノードへ移動させたり、他のノードから同様に移動してくるエージェントを受け入れる手段である。ユーザは、このようなエージェントシステムを用いて何らかの情報処理を行いたい場合、ローカルノード８００Ｌにおいて、入出力手段８０３Ｌからエージェント管理手段８０４Ｌに指示を与えることによってエージェントを生成させる。
【０００５】
そして、最も基本的な例を示せば、生成されたエージェントに対して、ユーザが入出力手段８０３Ｌからスクリプトを与える。スクリプトは、エージェントの行動プログラムであり、どのノードへ移動し、どのような処理を行う、といった内容を具体的に記述したものである。スクリプトのより具体的な例としては、例えば、ノードＡに移動してファイルａのコピーをユーザのノードに送信し、次にノードＢに移動してファイルｂのコピーをユーザのノードに送信し…といった内容が考えられる。そして、各ノードに備えられた解釈実行手段８０２（Ｌ，Ｒ）は、このようなスクリプトを実行することによってエージェントを活動させ、これによって目的とする情報処理を実現する。
【０００６】
この場合、各ノードに備えられたエージェント情報記憶手段８０１（Ｌ，Ｒ）が、エージェントに必要な情報を記憶する。エージェントに必要な情報は、例えば、前記のスクリプトのほか、スクリプトの解釈実行に必要な各変数（スクリプト変数と呼ばれる）や、必要な場合は、エージェントが収集した情報やファイルなどである。また、エージェントのスクリプトに記述される命令としては、一つのノード上だけで実行できる命令のほか、エージェントを他のノードへ移動させるための移動命令がある。解釈実行手段８０２Ｌは、スクリプトの命令を順次実行し、移動命令の実行が必要になった場合には、移動先のノードを指定して、エージェントの移動をエージェント管理手段８０４に依頼する。
【０００７】
このようなエージェントシステムでは、ユーザが、いくつかのファイルをネットワーク上から収集したいような場合、この目的を達成するための行動プログラムをエージェントに持たせてネットワーク上に送り出せばよく、送り出されたエージェントは、与えられたスクリプトに基づいて自律的に活動する。このため、ユーザのノードとエージェントとの間で通信を始終維持する必要はないことから、ftpやtelnetといった従来のネットワーク機能と比べて回線障害に強いという利点がある。
【０００８】
〔プランニングを用いる構成例〕
図１５に示したエージェントシステムに対して、エージェントの行動プログラムであるスクリプトを、状況に応じて変化させることができるエージェントシステムも知られている。
【０００９】
すなわち、近年のようにネットワークが大規模化・複雑化し、特に、インターネットのような広域ネットワークと接続されることによっていわゆる開放型ネットワークになると、ファイルの所在などのようなネットワークの構成要素がしばしば変化するようになる。ところが、図１５に示した上記のようなエージェントシステムでは、エージェントは生成される時点で固定されたスクリプトを与えられるため、状況に応じて行動を変更することができない。そこで、このような変化に柔軟に対応するため、人手を煩わせずにエージェントの行動を自動的に変化させる技術として、本出願人は、プランニング機能を持ったエージェントシステムを出願している。
【００１０】
この技術では、エージェントの行動プログラムはプランと呼び、プランを生成することをプランニングと呼ぶ。そして、この技術では、状況に応じてプランを適宜作り直すことによって、ネットワークの構成要素の変化に対応する。なお、ネットワークの構成などの変化に対応してプランニングを再度やり直すことを再プランニングと呼ぶ。
【００１１】
このようなエージェントシステムの構成例を図１６の機能ブロック図に示す。この技術において、プランの生成に用いる情報としては、「知識」と呼ばれる情報とアクション定義とが挙げられる。このうち「知識」は、エージェントの動作、特にプランニングに利用する各種の情報であり、その一例として、どのファイルがどのノードに存在するかといったネットワークの構成要素に関する情報を含む。例えば図１６の例では、このようなネットワークの構成に関する知識を、ローカル情報記憶手段１Ｌに保存しておき、ネットワークの構成に変化があったときは、更新手段２Ｌが、自動検出や手作業などによって、このような変化を知識に反映させる。また、アクション定義とは、プランを構成する部品として、どのような種類の命令（アクション）が使えるかを表す情報であり、エージェント情報記憶手段３に格納しておく。
【００１２】
このようなエージェントシステムでは、エージェントの生成を指示するユーザは、達成したいゴールをスクリプトの代わりにノードに与える。ここで、ゴールとは、情報処理の目的として達成したい状態を予め定められた文法で記述したものである。すると、プラン生成手段５は、与えられた知識を参照しながら、アクション定義に含まれる各種のアクションを組み合わせることによって、ゴールを達成するためのプランを生成する。このようなエージェントシステムでは、ネットワークの構成の変化は、プランニングや再プランニングの際に、知識を介してエージェントのプランに反映されるので、エージェントは、人手を介さずに状況の変化に対応し、柔軟に行動を変化させることができる。
【００１３】
なお、このようなプランを生成する手段は、「プランナ」とも呼ばれ、その実体はプランニングの手続きを表すプログラムの一種である。また、エージェントの行動プログラムやその各部分を呼ぶ広義の概念がスクリプトであり、プランというときは、特に、図１６に示したようなプランニングを行うエージェントによって生成されたスクリプトの全体を指す。
【００１４】
〔プランニングの例〕
続いて、上記のようなプランニングを用いたエージェントシステムの具体的な動作手順を図１７に例示する。この手順では、ユーザが、情報処理のゴールとしてエージェントに対する要求の記述（要求記述）を入力すると（ステップ２０１）、必要な初期化が行なわれた後（ステップ２０２）、プランが生成される（ステップ２０３）。なお、処理は、ゴールが既に達成されているなど終了条件の判定結果に応じて終了する（ステップ２０４，２０５）。
【００１５】
すなわち、このような終了条件が満たされるまでは、ゴールを達成するために実行を要するプランの実行が行われる（ステップ２０４）。プランの実行では、プランに含まれる各命令を順次実行し、実行する命令が移動命令の場合にはエージェントをノード間で移動させる処理（goアクションと呼ばれる）が実行される（ステップ２０６〜２０８）。また、各命令の実行やgoアクションの実行に失敗した場合は、必要に応じて新たなプランを生成する。
【００１６】
ここで、プランの生成に用いるアクション定義には、アクション（動作）の種類ごとに、事前条件と事後条件とが定義されている。このうち事前条件とは、どんな条件が満たされていればその動作を実行できるかを表し、事後条件は、その動作を実行するとどのような条件が作り出されるかを表す。例えば、「ファイルをコピーする」という動作を行うには、「現在いるノードにファイルが存在する」という事前条件が必要であり、コピーの動作を行なった結果として「ファイルのコピーが存在する」という事後条件が産み出される。
【００１７】
プランの生成は、最終的なゴールを事後条件として産み出す動作を発見し、この動作の事前条件を事後条件として産み出すさらに別の動作を発見する、という処理を続けることによって、プランを実行する前の状態（現在の状態）と最終的なゴールとの間をつなぐ動作の列を得ることである。なお、図１８は、生成途中におけるプランの例を示す図であり、この例では、動作Ｐ２の一方の事前条件Ｃ５と、動作Ｐ３の事前条件Ｃ７について、これら事前条件を事後条件として産み出す動作がまだ見つかっていない。このように、事後条件として産み出す他の動作がまだ見つかっていない事前条件は未達成ゴールと呼ばれる。
【００１８】
このようなプラン生成の処理は、ゴールの側から因果を逆に遡って行ない、プランの実行を開始する時点で存在している状態（現在の状態）に到達すると終了する。図１９は、このような処理によって完成したプランの例を示す図である。
【００１９】
続いて、プラン生成の具体的な手順を図２０に示す。すなわち、この手順では、ゴールを記録しておくゴールリストの一部を、図１８に示したような未達成ゴールを記録しておく未達成ゴールリストとしておき、次のような処理を行う。まず、ゴールリストに未達成ゴールが存在しなくなるまで（ステップ４０１）、未達成ゴールリストから未達成ゴールを１つずつ選択し（ステップ４０２）、ゴールが満足されている場合を除いて（ステップ４０３）、次のような動作を行う。すなわち、ゴールである事前条件を事後条件によって達成可能な動作が存在すれば（ステップ４０４）この動作を選択し（ステップ４０５）、このように選択した動作（選択動作）を図１９に示したような動作の系列（プラン木）に追加する（ステップ４０５）。
【００２０】
また、ゴールを達成可能な動作が存在しない場合は、ゴールが不確実知識で達成可能かを判断する。ここで、不確実知識とは、ネットワークの構成に関する知識のうち、他のノードで実際に何らかの処理を行なってみないと具体的な値がわからない知識である。ゴールが不確実知識で達成可能な場合はこの不確実知識を選択動作としてプラン木に追加するが（ステップ４０５）、不確実知識でも達成不可能な場合は、処理をバックトラックさせ（ステップ４０８）、現在の未達成ゴールを生じさせている動作を他の動作に置き換えて再度処理を行う。
【００２１】
例えば、ユーザが使用するノードのノード知識で、「ファイルａがノードＡに存在する」とされているとする。この場合、ファイルａを得るというゴールをユーザが与えると、ノードＡに存在するという知識が参照されるので、生成されたエージェントのプランは、「ノードＡに移動してファイルａのコピーをユーザのノードに送信する」、といった内容になる。
【００２２】
しかし、エージェントがノードＡに移動した時点で、ファイルａはノードＢに移動されていると、ファイルａが発見できないためにプランは実行失敗となり、ノードＡ上で再プランニングが行なわれる。このとき、ノードＢのノード知識がファイルの移動にあわせて更新されており、「ファイルａはノードＢに存在する」と変更されている場合、新しいプランは「ノードＢに移動してファイルａのコピーをユーザのノードに送信する」、という内容に変更される。この結果、エージェントはノードＢに自律的に移動するし、ファイルａを無事発見してユーザのノードに送信することができる。
【００２３】
また、このように生成されたプランに基づいて、エージェントがノード間で移動する場合の手順を図２１に示す。この例では、ユーザがエージェントを生成したローカルノードから、他のノードであるリモートノードへエージェントが移動するものとする。この場合、ローカルノードからの移動要求（ステップ５０１）を受信したリモートノードは（ステップ５０２）、エージェント用のプロセスを設定する（ステップ５０３）。
【００２４】
続いて、リモートノードから、プロセスの設定が完了した旨の通知（ステップ５０４）を受信したローカルノードは（ステップ５０５）、エージェントのプランや変数領域などのエージェント情報をリモートノードに送信する（ステップ５０６）。このエージェント情報を受信したリモートノードは（ステップ５０７）、エージェント情報を格納し（ステップ５０８）、ローカルノードへ移動成功の通知を送信し（ステップ５０９）、プランの解釈実行を開始する（ステップ５１０）。一方、成功の通知を受信したローカルノードは（ステップ５１１）、不要になったエージェント用のプロセスを消去する（ステップ５１２）。
【００２５】
〔エージェントのライフサイクル〕
次に、以上のようにプランニングを行うエージェントのライフサイクルを示す概念図を図２２に示す。すなわち、エージェントは、ゴール投入と共に生成されて活動を開始すると、まず、プランを生成するプランニングフェーズＰから開始し、生成されたプランにしたがい、プランを実行する実行フェーズＥやノード間で移動する移動フェーズＭに移行し、実行や移動の失敗に応じてこれらの各フェーズ間を移行しながら活動する。そして、当初与えられたゴールを達成すれば正常終了となり、ゴールが達成できずにプランニング自体にも失敗すると完全失敗となって終了する。
【００２６】
〔ファームを用いる例〕
また、１つのノード上に、ファームと呼ばれる領域をいくつか設けたエージェントシステムも考えられる。ここで、ファームとは、情報処理の目的や分野ごとに設定されるエージェントの活動領域であり、フィールドとも呼ばれる。このようなファーム（フィールド）は、一つのノード上に複数存在することができ、メモリなどの資源やプランの生成・実行に用いる情報は、ファーム（フィールド）毎に設けられる。
【００２７】
図２３は、ネットワークＮに複数のホストＨ（マシン）が接続され、各ホストＨ上には１つずつのノードＸが存在し、ノードＸ上に複数のフィールドＦＬが存在する例を示す概念図である。このようなエージェントシステムでは、プラン生成に用いる知識がファーム（フィールドＦＬ）ごとに分けられており、これによって、エージェントはプランニングなどに必要な情報を検索する際、余分な情報まで参照する必要がないので、情報処理が効率化される。なお、プラン生成に用いられる知識はその知識を所持している主体によって、ファームが所持しているファーム知識、エージェントが所持しているエージェント知識などに分けることができる。
【発明の開示】
【発明が解決しようとする課題】
【００２８】
しかしながら、上記のような従来技術には、次のような問題点が存在していた。
（１）まず、エージェントシステムは、アクション定義を参照してプランを生成するが、従来のアクション定義は、action（アクション名，［事前条件］，［アクション列］，［事後条件］）のように、アクション名、事前条件、アクション列、事後条件を含んでいた。そして、従来のアクション定義では、そのアクションがプランの中で実行されるときに、具体的にはどのような動作を行うかが、上記のアクション列の項目に具体的に記述されていた。例えば、次のような従来のアクション定義において、
【表１】
0003692137.tif 000002
checkNodeというアクション名に対応する具体的な手順が下線部に記述されている。ここで、アクション列以外の部分はプランの生成に使う情報であるが、アクション列はプランの実行の際に使う情報である。
【００２９】
このように、従来では、プランの生成に使う情報と実行に使う情報がアクション定義中に混在していたため、スクリプトがアクション定義の言語形式に制約され、自由に記述できなかった。なお、ここでいうスクリプトはプランを構成する具体的な動作の記述である。特に、アクション定義は、必要な項目の情報を列挙するための言語形式であり、複雑な制御構造を持つ動作手続きの記述には不向きであった。また、プランの生成に使う情報と実行に使う情報という性質の異なる両者が、相互の区別が不明確なまま混在していたため、従来では、いずれかを作成したり修正する作業が煩雑であった。
【００３０】
（２）また、エージェントシステムは、知識を参照してプランニングを行い、そのプランを実行するというサイクルを繰り返しながら動作するが、プランの実行で得た情報は、その後のプランニングに用いる知識に反映されることが望ましい。そして、従来では、プランの実行で得た情報によって既存の情報を追加したり更新するには、その動作をプラン中に具体的に明記する必要があった。
【００３１】
しかし、実行の対象であるプランそのものと、プランの生成に用いる知識やその知識を更新する命令とは相互に目的が異なる。従来では、このような目的の異なる情報同士がプラン中に混在していたため相互に分離できず、動作の記述や目的に応じたエージェントの動作（アプリケーション）を構築する作業が煩雑かつ複雑なものとなっていた。
【００３２】
（３）また、エージェントシステムは必要に応じて再プランニングを行うが、従来では、どのようなときに、どのように再プランニングを行うかについて、プラン中に全て具体的に明記しておくか、システム上の標準（デフォルト）に任せるかのいずれか一方を選択するしかなかった。このため、動作に柔軟性が乏しく、様々な状況にエージェントが柔軟に対応することは困難であった。
【００３３】
（４）また、上記のような従来技術における他の問題点は、情報のセキュリティに関する問題である。すなわち、まず、移動してきたエージェントは、ノードやファームの持っているデータファイルなどの各種資源（リソース）に対して不法アクセス・破壊・改竄するおそれがある。また、これとは逆に、ノードやファームが、エージェントの内部データに対して不法アクセス・破壊・改竄するおそれも存在する。このため、セキュリティの機能を持った安全性の高いエージェントシステムが求められていた。
【００３４】
加えて、ノードやファームがプランニングのための知識ベースを十分に整備していない場合、そのノードやファーム上では、エージェントの目的を達成するための正しいプランが生成できるとは限らない。また、ノードやファームによっては、セキュリティや資源の限界などの事情で、プランの実行は認めるがプランニングは認めない場合も考えられる。このような場合、プランニングは適切なノード上でのみ行う必要があり、このような制御の技術も必要であった。
【００３５】
（５）また、エージェントは、ネットワーク上で複数のノード間を順次移動しながら活動を継続するので、たまたまエージェントが活動中だったノードでホストダウンなどの障害が発生するとエージェントの活動も中断される。このような場合、エージェントの情報は障害発生の時点で消滅しているので、従来では、ノードは再起動できてもエージェントの動作を継続することは不可能であった。
【００３６】
また、従来では、ユーザは、自分の使用しているノードでエージェントを生成させ、ネットワーク上に送り出した後は、送り出したエージェントの現在位置を確認したり、そのエージェントが活動を無事継続しているかどうかを確認する手段がなかった。このため、途中のノードで障害が発生したためエージェントが消滅しているにもかかわらず、エージェントの帰還を待つことによって作業が遅れるという問題があった。また、逆に、エージェントが消滅していないのに、帰還が若干遅れたためにエージェントが障害で消滅したと誤解し、エージェントを再び送り出して二度手間になるなどの問題もあった。
【００３７】
さらに、ノードの障害でエージェントが消滅したと思われる場合でも、従来では、エージェントの動作を途中から再開させる手段が存在しなかった。このため、エージェントの生成とエージェントの活動は最初から全部やり直す必要があり、その手順が煩雑であるだけでなく、ネットワーク資源への負担が増加するという問題もあった。
【００３８】
本発明は、上記のような従来技術の問題点を解決するために提案されたもので、その目的は、優れたプランを生成するエージェントの技術を提供することである。また、本発明の他の目的は、信頼性の優れたエージェントの技術を提供することである。
【００３９】
より具体的には、本発明の目的は、次の通りである。
（１）アクション定義の言語形式に制約されることなく、スクリプトを自由に記述できるようにすること。
（２）実行で得られる情報による知識の更新をプラン中に記述する必要をなくすこと。
（３）再プランニングの内容を多様化することによって、エージェントによる動作の柔軟性を高めること。
（４）情報処理の安全性を改善すること。
（５）ノードの障害のために活動を中断したエージェントについて、活動を再開できるようにすること。
【課題を解決するための手段】
【００４０】
上記の目的を達成するため、本発明のエージェントシステムは、ネットワーク上に存在する複数の領域でソフトウェアエージェントを移動させながら情報処理を行うエージェントシステムにおいて、前記ソフトウェアエージェントを管理するエージェント管理手段と、前記複数の領域を個別に管理する各領域管理手段と、ネットワーク上の各領域が信頼できるかどうかを表す第１の情報を格納する第１情報格納手段を備えたことを特徴としている。さらに、エージェント管理手段は、ソフトウェアエージェントを領域間で移動させようとするとき、移動先の領域の信頼性を前記第１の情報に基づいて判断し、信頼できる領域へのみソフトウェアエージェントを移動させるように構成される。また、各領域管理手段は、ソフトウェアエージェントが他の領域から移動してこようとするとき、移動元の領域の信頼性を前記第１の情報に基づいて判断し、信頼できる領域から移動してくるソフトウェアエージェントのみを受け入れるように構成される。
【００４１】
また、本発明の情報処理方法と記録媒体は、上記のエージェントシステムの特徴を、方法とプログラムを記録した記録媒体の観点から把握したものである。
【００４２】
以上のような発明では、各領域は信頼できる領域からしかエージェントを受け入れず、エージェントも信頼できる領域にしか移動しない。このため、エージェントも領域も互いに相手から不法アクセス等によって侵害される危険を軽減できる。
【発明の効果】
【００４３】
本発明によれば、エージェントがノード間で移動するとき、エージェントとノードが相互に移動先や移動元のノードの信頼性を判断することによって、情報処理の安全性が改善されるため、優れたプランを生成するエージェントの技術を提供することができる。
【発明を実施するための最良の形態】
【００４４】
次に、本発明の実施の形態（以下「実施形態」という）について、図面を参照して説明する。なお、本発明は、周辺機器を持つコンピュータを、ソフトウェアで制御することによって実現することが一般的と考えられる。この場合、キーボード及びマウスなどの入力装置で情報を入力し、ＣＲＴ表示装置及びプリンタなどの出力装置で情報を出力できる。また、レジスタ、メモリ、外部記憶装置などの記憶装置は、いろいろな形式で、情報を一時的に保持したり永続的に保存できる。そして、ＣＰＵは、前記ソフトウェアにしたがって、これらの情報に加工及び判断などの処理を加え、さらに、処理の順序を制御することができる。
【００４５】
また、コンピュータを制御するソフトウェアは、各請求項及び明細書に記述する処理に対応した命令を組み合わせることによって作成され、作成されたソフトウェアは、コンパイラやインタプリタなどの処理系によって実行されることで、上記のようなハードウェア資源を活用する。
【００４６】
但し、本発明を実現するための上記のような態様はいろいろ変更することができ、例えば、本発明の装置と外部との間で情報を入出力するには、フレキシブルディスクなどの着脱可能な記録媒体やネットワーク接続装置を使用することもできる。さらに、本発明を実現するソフトウェアを記録したＣＤ−ＲＯＭのような記録媒体は、それ単独でも、本発明の一態様である。また、本発明の機能の一部をＬＳＩなどの物理的な電子回路で実現することも可能である。
【００４７】
以上のように、コンピュータを使用して本発明を実現する態様はいろいろ変更できるので、以下では、本発明の各機能を実現する仮想的回路ブロックを用いることによって、本発明の実施の形態を説明する。
【００４８】
〔１．第１実施形態…アクション定義とスクリプトの分離〕
第１実施形態は、エージェントがプランに基づいて情報処理を行うエージェントシステムにおいて、どのようなアクションをプランに使用できるかを表すアクション定義と、各アクションがどのような動作を行うかを具体的に記述した各スクリプト実体とを、別々に格納するものである。
【００４９】
〔１−１．構成〕
すなわち、図１は第１実施形態のエージェントシステムにおいて、各ノードの構成を示す機能ブロック図である。なお、第１実施形態のエージェントシステムでは、図示はしないが、図１５や図１６に示した従来技術と同様に、複数のノードがネットワークによって接続されており、各ノードには、図１に示す各部分のほかに、入出力を行う手段や、エージェントを管理したりノード間で移動させる手段が設けられている。
【００５０】
このような第１実施形態では、各ノードが第１の格納手段１１１と第２の格納手段１１２とを有する。このうち第１の格納手段１１１は、どのようなアクションをプランに使用できるかを表すアクション定義を格納する手段であり、第２の格納手段１１２は、各アクションがどのような動作を行うかを具体的に記述したスクリプト実体を格納する手段である。また、各アクションのアクション定義には、各アクションに対応する前記スクリプト実体を指すスクリプト名が記述されている。
【００５１】
また、各ノードは、例えばファイルの名称やどのノードにあるかなど、情報処理の対象に関する情報の集合を格納するための第３の格納手段１１３を有する。この第３の格納手段１１３に格納される情報は、ネットワークの構成要素に関する情報を表すいわゆる知識であり、プラン生成の際に参照される。
【００５２】
また、各ノードは、プランナ１１５と実行器１１７とを有し、このうちプランナ１１５は、第１の格納手段１１１に格納されたアクション定義中に記述されたスクリプト名を組み合わせることによってエージェントのプラン１１６を生成する手段である。また、実行器１１７は、生成されたプラン１１６中に含まれる各スクリプト名に対応するスクリプト実体を前記第２の格納手段１１２から順次読み出して実行することによって、エージェントの動作を実現する手段である。また、各ノードは、プラン１１６を実行する際に用いるスクリプト変数を格納するための第４の格納手段１１４を有する。
【００５３】
〔１−２．作用〕
〔１−２−１．情報の格納〕
上記のような第１実施形態では、アクション毎のアクション定義には、アクション名、事前条件、事後条件の他に、そのアクションに対応するスクリプトの名称（スクリプト名）をaction（アクション名，［事前条件］，［呼び出すスクリプトの名称］，［事後条件］）のように記述し、この際、スクリプト名には、対応するスクリプト実体に引き渡す引数を記述する。そして、このように記述したアクション定義は、第１の格納手段１１１に格納しておく。
【００５４】
また、各アクションで行う動作の具体的な実体（スクリプト実体と呼ぶ）はアクション定義とは別に作成し、そのアクションのアクション定義で用いたのと同じスクリプト名を付けて、第２の格納手段１１２に格納しておく。
【００５５】
例えば、アクション定義： 
【表２】
0003692137.tif 000003
には、スクリプト名get_info(Node,′inform.dat′,OriginNode)（下線部）を記述しておく。そして、このスクリプト名に対応する具体的なスクリプト実体は、次のようなスクリプト記述：
【表３】
0003692137.tif 000004
に記述しておく。この際、スクリプト実体の記述は、アクション定義からは分離されているので、アクション定義の言語形式に制約されることなく、if-thenなどの制御構造も用いてスクリプトを自由に記述することができる。
【００５６】
次に、上記のように用意されたアクション定義及びスクリプト実体に基づいて、プランを生成及び実行する手順を図２のフローチャートに示す。
【００５７】
〔１−２−２．プランの生成〕
この手順では、プランナ１１５は、対象に関する情報とアクション定義からプラン１１６を生成するが、このとき、必要なアクションのアクション定義から、スクリプト名を取り出して組み合わせることによって、スクリプト名の並びとしてのプラン１１６を生成する。具体的には、プランニングでは（ステップ１２１）、図１８から２０に示したように、アクション定義を参照することによって、事前条件と事後条件とを接続してゆき、当初の対象を表す情報からゴール達成に至るスクリプト呼び出しの列を生成する。このようなスクリプト名の並びをスクリプト呼出し列と呼ぶ。
【００５８】
〔１−２−３．プランの実行〕
上記のように生成されたプラン１１６を実行する際は、実行器１１７が、メインルーチンからサブルーチンを呼び出すように、プラン１１６として生成されたスクリプト呼び出し列に記述されたスクリプト名をひとつずつ取り出し、スクリプト名に対応するスクリプト実体を第２の格納手段１１２から読み出し、必要な変数の受渡を行ったうえで、スクリプト実体に記述された動作手続きを順次実行する。
【００５９】
具体的には、実行器１１７は、スクリプト呼び出し列に含まれるスクリプト呼び出しを一つずつ取り出し（ステップ１２２）、取り出せなければプランニングに戻るが（ステップ１２３）、取り出したスクリプト呼び出しの文字列のなかからスクリプト名を切り出し、切り出したスクリプト名と同じ名称のスクリプト実体を、第２の格納手段１１２から読み込む（ステップ１２４）。
【００６０】
〔１−２−４．変数値の引き渡し〕
また、実行器１１７は、スクリプト実体の実行に先立って、プラン全体で使う変数と、個々のスクリプトの実行で使う変数との間で、数値を受け渡す。すなわち（ステップ１２５）、呼び出されるスクリプト実体で用いるスクリプト変数名と、呼び出し側から渡される呼び出し引数とを、互いの記載順序などに基づいてマッチング（対応付け）し、各呼び出し引数対応するプランの変数の値をスクリプト変数に受渡し、受け渡した値を第４の格納手段１１４に格納する。例えば、上記の例では、各呼び出し引数との変数名と、スクリプト実体の変数名が、
Node=$node′
inform.dat′=$filename
OriginNode=$origin
のように対応付けられる。そして、実行器１１７は、このように受け渡された変数の値を用いてスクリプト実体の記述にしたがって、情報処理のための手続きを実行し（ステップ１２６）、１つのスクリプト実体の実行が終了すると、スクリプト呼び出しを取り出す処理（ステップ１２２）からの手順を繰り返す。
【００６１】
〔１−３．効果〕
以上のように、第１実施形態では、スクリプトの実体がアクション定義から分離されるので、アクション定義の記述に用いる言語の形式や文法構造に制約されることなく、条件分岐などの制御構造を用いるなど、スクリプトを自由に記述できるようになる。
【００６２】
〔２．第２実施形態…知識の更新〕
次に、第２実施形態は、与えられた知識に基づいて生成したプランにしたがってエージェントが情報処理を行うエージェントシステムにおいて、プランの実行によって得られた情報によって前記知識を更新するようにしたものである。
【００６３】
〔２−１．構成〕
第２実施形態は、複数のノードをコンピュータネットワークで接続したエージェントシステムであり、図３は、第２実施形態におけるノードの構成を示す機能ブロック図である。
【００６４】
この図に示すように、第２実施形態におけるノードは、確定した知識を保存するためのエージェント知識ベース２１１と、知識に基づいてプランを生成するプランニング手段２１６と、を有する。ここで、知識とは、プランニングに用いるためにエージェントシステムの構成要素を表した情報であり、例えばどのノードにどのようなファイルがあるかといった事実を表す。
【００６５】
また、第２実施形態における各ノードは、生成されたプランを実行するためのプラン実行手段２１５と、プランに用いられた未確定の知識を保存するための未確定知識ベース２１２と、プランの実行によって判明した情報によって知識を更新するエージェント知識管理手段２１３と、を有する。また、第２実施形態における各ノードは、エージェントを管理するためのエージェント管理手段２１４を有する。
【００６６】
〔２−２．作用〕
〔２−２−１．未確定知識を用いたプランニング〕
上記のような構成を有する本実施形態では、エージェント管理手段２１４が全体の動作を制御し、この制御にしたがってプランニング手段２１６がプランを生成し、生成されたプランをプラン実行手段２１５が実行する。そして、プランを生成する際に、実際にプランを実行してみないと確認できない未確定の事実を用いる知識（未確定知識）が必要になると、このような未確定知識は、未確定の事実を表す変数を含んだままプランに使用され、また、確定的な知識とは別に保存される。プラン生成後、未確定知識については生成されたプランを実行することによって必要な情報が具体的に判明してから更新する。
【００６７】
ここで、図４は、第２実施形態における処理手順を示すフローチャートである。例えば、プランニング手段２１６がプランニング（ステップ２２１）を行う際、エージェントが知識ベース２１１中に保有する知識のうち、hisnameという項目をプラン中に使用する必要が生じたとする。しかし、項目hisnameの具体的な内容はまだ確定しておらず、プランの実行の際にファイルなどを参照することによって確定する見込であるとする。この場合、エージェント知識管理手段２１３は、未確定変数ＷＨＯを含む未確定知識
info(agent, hisname(WHO))
を、一旦仮にエージェント知識ベース２１１に追加し、この知識hisnameが未確定のままプランに使用する。この場合、一例として、getHisName()という命令の引数としてこの知識を使用するには、未確定変数ＷＨＯを用いて、プラン中に次のように命令を記述する。
getHisName(WHO)
すなわち、この命令では、未確定知識中の変数ＷＨＯが命令の引数に対応している。
【００６８】
〔２−２−２．未確定知識の保存〕
この場合、プランニングが終了すると、エージェント知識管理手段２１３は、この未確定知識をエージェント知識ベース２１１から取り出して未確定知識ベース２１２に追加し（ステップ２２２）、プラン中に引数として用いた変数ＷＨＯと、未確定知識ベースに追加した未確定知識
info(agent, hisname(WHO))
との対応関係を記録して管理する。なお、確定した知識はプラン生成の際に参照されるが、未確定のままの知識は、プランニングの際に参照されるエージェント知識ベース２１１内の知識とは別個独立に未確定知識ベース２１２に格納され、確定するまでは、プランニングの際に参照の対象とはならない。
【００６９】
〔２−２−３．プランの実行による値の確定〕
また、プランニングが終了すると、エージェント管理手段２１４はプラン実行手段２１５を起動し、起動されたプラン実行手段２１５が、上記のような未確定知識を含むプランを実行する（ステップ２２３）。この実行の際に、プラン実行手段２１５は、プラン中の各命令をインタプリタ形式で逐次解釈実行するが、この実行によって変数ＷＨＯの具体的な内容を持っているファイルなどがアクセスされると、変数ＷＨＯ具体的な値が対応付けられる。そして、このような変数と具体的な値との対応関係は、プラン実行手段２１５によって保持される。
【００７０】
このようにプランが実行された後、エージェント管理手段２１４は、次のプランニングに移行する前に、プラン中の変数に値が確定（バインド）しているかどうかをチェックする（ステップ２２４）。このチェックを行うには、未確定知識ベース２１２中の全ての変数名をリストアップし、これら変数名をプラン実行手段２１５に渡して、その状態を問い合わせ、問い合わせの結果が確定済みか未確定かを判断すればよい。
【００７１】
〔２−２−４．知識の更新〕
このとき、
変数WHO="masanori"
のように変数の値が確定していれば、エージェント管理手段２１４は確定した値をエージェント知識管理手段２１３に渡し、エージェント知識管理手段２１３は、未確定知識ベース２１２中の未確定知識に含まれる変数をこの確定した値で、
【表４】
0003692137.tif 000005
のように置き換えることによって、未確定知識を確定させる（ステップ２２５）。また、エージェント知識管理手段２１３は、このように確定した知識を、未確定知識ベース２１２からエージェント知識ベース２１１へ移動させる。このように確定されてエージェント知識ベース２１１に移動された知識は、それ以降のプランニングにおいて参照される。
【００７２】
〔２−３．効果〕
以上のように、第２実施形態では、プランの実行時に得られるであろう情報によって確定するが、プランニングの時点で未確定の知識は、確定した知識とは別に一定の形式で表して保存しておき、プランの実行で得られた情報によって確定させたうえで確定した知識に追加される。そして、これら一連の処理をエージェントが自動的に行うことによって、知識の更新をプラン中に記述する必要をなくなり、プランを記述する煩雑さや複雑さが解消される。
【００７３】
また、第２実施形態では、プランニングの際には確定した知識のみが参照されるので、プランニングによって生成されるプランの確実性が向上する。なお、エージェントが保有するものに限らず、ノードやファームに存在する知識など、あらゆる知識を上記のようなやり方で更新することができる。
【００７４】
〔３．第３実施形態…再プランニングの制御〕
第３実施形態は、プランを実行することによってエージェントに情報処理を行なわせるエージェントシステムにおいて、プランの所望の部分ごとに、実行が失敗した場合の再プランニング動作をユーザが定義しておくか、システム上のデフォルトの動作に任せるかを自由に定められるようにしたものである。
【００７５】
〔３−１．構成〕
第３実施形態は、複数のノードをコンピュータネットワークで接続したもので、図５は、第３実施形態における各ノードの構成を示す機能ブロック図である。この図に示すように、第３実施形態における各ノードは、プラン３１１（スクリプト実体）の所望の部分に対して、実行が失敗した場合の例外処理を定義する手段３１６と、プランを実行する実行手段３１２と、プランの実行に用いるスクリプト変数を格納するための格納手段３１３とを有する。
【００７６】
また、第３実施形態における各ノードは、例外処理手段３１４と、エージェント動作制御手段３１５とを有する。このうち例外処理手段３１４は、プランを例外処理が定義されている前記部分でプランの実行が失敗した場合に、定義された例外処理を実行する手段であり、エージェント動作制御手段３１５は、例外処理が定義されていない部分でプランの実行が失敗した場合に、予め定められている再プランニング動作を実行する手段である。なお、定義する手段３１６は必ずしも全てのノードに設ける必要はなく、例外処理を定義するノードに設ければ足りる。
【００７７】
〔３−２．作用〕
上記のような構成を有する第３実施形態は次のような作用を有する。
〔３−２−１．例外処理の定義〕
すなわち、第３実施形態においてエージェントを生成する場合は、プラン実行の失敗を例外の一種として扱い、例外処理を定義するかどうかに応じて、スクリプトの実体を図６のような形式で記述しておく。すなわち、実行失敗時の例外処理を定義する部分はtry{}というキーワードの｛｝内に記述し、その部分に対する例外処理は、その直後にcatch{} いうキーワードを記述し、その｛｝内に記述する。
【００７８】
これらの構文を用いることによって、構文try{}を用いて記述された箇所でプランの実行失敗が発生した場合に、この構文try{}と対になった構文catch{}を用いて記述された例外処理が実行される。
【００７９】
〔３−２−２．プランの実行と例外の発生〕
ここで、図７は、第３実施形態においてプランを実行する手順を示すフローチャートである。すなわち、この図に示すように、実行手段３１２は、プランから実行文を順次取り出して実行するが（ステップ３２１）、実行時に例外の一種である実行失敗が発生すると（ステップ３２２）、実行手段３１２は、例外発生を表す信号を、例外が発生したスクリプト上の位置と共に例外処理手段３１４に送る。
【００８０】
〔３−２−３．例外発生に対する処理〕
信号を受けた例外処理手段３１４は、その例外の発生した位置がtryブロック内かどうか調べ（ステップ３２３）、tryブロック内で発生した例外ならば、当該tryブロック直後のcatchブロック内に定義されたとおりの例外処理を行う（ステップ３２４〜３２６）。一方、例外の発生した位置がtryブロック内でなければ、エージェント動作制御手段３１５が、予め定められたシステム上の標準（デフォルト）にしたがって再プランニングを行う（ステップ３２７）。
【００８１】
このように、プランの実行時に予約語であるcatchが果たす役割は、対になっているtryブロック内で例外の一種である実行失敗が発生した場合に、この発生を表す信号を検出し、catchブロック内に適切な復帰処理にジャンプすることである。また、図６は、例外が発生した箇所がtryブロックの内側であるか外側であるかに応じて異なった処理が行なわれる状態を示している。
【００８２】
〔３−２−４．構文の入れ子構造〕
また、
【表５】
0003692137.tif 000006
のように、tryとcatchを用いた構文を入れ子の構造にすることによって、例外処理自体に対してもさらに同様の例外処理を適用することができる。この場合は、tryの部分に通常の処理を記述し、catchの部分に復帰処理を記述するが、このcatchの内側でも、tryの部分に本来の復帰処理を記述し、catchの部分には、復帰処理自体の失敗が発生した場合に備えた例外処理を記述しておく。
【００８３】
この構造によれば、実行失敗に対する復帰処理の最中にさらに例外が発生した場合、復帰処理自体がtryブロック化されているため、対応するcatchブロックに記述された例外処理によって対応がなされる。なお、復帰処理自体はTryブロック化されていない場合は、復帰処理中に例外が発生するとシステム上のデフォルトにしたがって再プランニングが行なわれる。
【００８４】
〔３−３．効果〕
以上のように、第３実施形態では、プランの実行失敗が発生した場合に、予め定められているシステム上の標準（デフォルト）に基づいて再プランニングを行うか、失敗から復旧するための例外処理を定義しておくかを、プランの部分ごとに自由に選択できるので、再プランニングに関するエージェントの制御が容易になる。
【００８５】
特に、第３実施形態では、例外処理を定義する部分と、この部分に対する例外処理を、それぞれ決まったキーワードや｛｝などを用いた第１の構文try{}と第２tch{}の構文cで相互に対応させて指定できるので、例外処理の定義が容易になる。
【００８６】
〔４．第４実施形態…セキュリティについて〕
第４実施形態は、ネットワーク上に存在する複数の領域をエージェントが移動しながら情報処理を行うエージェントシステムにおいて、エージェントがノードやファームなどの各領域間で移動したりプランニングを行おうとするとき、エージェントや各領域がセキュリティに関する判断を行うようにしたものである。
【００８７】
〔４−１．構成〕
図８は、第４実施形態の構成を示す機能ブロック図である。この図に示すように、第４実施形態は、まず、各領域すなわちノード及びファームをそれぞれ管理するノード管理部４１１及びファーム管理部４１２と、エージェントを管理するエージェント管理部４１３と、を備えている。なお、第４実施形態は、図示はしないが、複数のノードをコンピュータネットワークで接続したもので、個々のノード上にはエージェントの目的別の活動領域であるファームが複数存在する。そして、ノード管理部４１１、ファーム管理部４１２及びエージェント管理部４１３はそれぞれ、管理の対象とするノード上、及び管理の対象とするファームやエージェントの存在するノード上に存在している。
【００８８】
また、第４実施形態は、信頼リスト格納部４１４と、信頼リスト管理部４１５と、判断部４１６を有する。このうち信頼リスト４１４は、ネットワーク上の各領域が信頼できるかどうかを表す信頼リスト（前記第１の情報に相当する）を格納する部分である。また、信頼リスト管理部４１５は、信頼リストについて更新やアクセスを管理する部分である。また、判断部４１６は、与えられた領域について、信頼リスト管理部４１５を通じて信頼リスト格納部４１４を参照することによって、信頼できるかどうかを判断する部分である。なお、これら信頼リスト格納部４１４、信頼リスト管理部４１５及び判断部４１６は、各ノードごとに設けてもよいし、いくつかのノードに設けてもよいし、１箇所に集中して設けてもよい。
【００８９】
そして、各領域のファーム管理部４１２及びノード管理部４１１は、エージェントが他の領域から移動してこようとするとき、移動元の領域の信頼性を判断部４１６に判断させることによって、信頼できる領域から移動してくるエージェントのみを受け入れるように構成されている。また、各エージェントのエージェント管理部４１３は、エージェントが領域間で移動しようとするとき、移動先の領域の信頼性を判断部４１６に判断させることによって、信頼できる領域へのみエージェントを移動させるように構成されている。
【００９０】
また、信頼リスト格納部４１４には、各領域においてエージェントにプランニングが認められるかどうかを表す第２の情報も格納されており、信頼リスト管理部４１５及び判断部４１６は、この第２の情報にアクセスすることによって、与えられた領域についてエージェントにプランニングが認められるかどうかを判断するように構成されている。そして、エージェント管理部４１３は、判断部４１６にこの第２の情報を参照させることによって、プランニングを認めない領域ではエージェントのプランニングを回避するように構成されている。なお、第１の情報である信頼リストや第２の情報は、ネームサーバなど１箇所に集中して保存することが望ましい。
【００９１】
また、このような信頼リストはどのような形式でもよいが、例えば、ファームを単位とする場合、次のような形式が考えられる。すなわち、ファームと同数のレコードからなるリスト形式として、１つのレコードごとに次の３つのフィールドを持たせる。このうち最初のフィールドはファーム固有の名称や識別子とし、２つ目のフィールドはそのファームの信頼性をＡ，Ｂ，Ｃなどのランクで表し、３つ目のフィールドはそのファームがプランニングを認めるときは１、認めないときは２といったフラグにする。
【００９２】
〔４−２．作用〕
上記のような構成を有する本実施形態では、各領域のノード管理部４１１及びファーム管理部４１２は、エージェントが他の領域から移動してこようとするとき、移動元の領域の信頼性を判断部４１６に判断させることによって、信頼できる領域から移動してくるエージェントのみを受け入れる。なお、各領域やエージェントの管理部は、各領域やエージェントのために信頼性の判断などの処理を代行していると考えられるので、以下の説明では、管理部や判断部に関する記述は省略する。
【００９３】
すなわち、各領域は、エージェントが他の領域から移動してこようとするとき、移動元の領域の信頼性を判断し、信頼できる領域から移動してくるエージェントのみを受け入れる。また、各エージェントは、領域間で移動しようとするとき、移動先の領域の信頼性を判断し、信頼できる領域へのみエージェントを移動させる。
【００９４】
〔４−２−１．エージェントが移動するときの処理〕
ここで、図９は、エージェントがノード間で移動しようとする場合に、ノード及びエージェントが他のノードの信頼性を判断する処理手順の具体例を示すフローチャートである。すなわち、エージェントがプランを実行した結果、他のノードへの移動要求が発生すると（ステップ４２０）、まず、移動しようとしているエージェントが移動先ノードの信頼性を判断し（ステップ４２１）、信頼する場合は、エージェントが現在いるノードへ移動を依頼する（ステップ４２２）。
【００９５】
依頼を受けた移動元のノードは、移動先ノードの信頼性を判断したうえ（ステップ４２３）、信頼する場合は移動先ノードへエージェントの移動を打診する（ステップ４２４）。打診を受けた移動先ノードは移動元ノードの信頼性を判断し（ステップ４２５）、ここでも信頼すると判断された場合に、移動元ノードから移動先ノードへのデータ転送が行なわれてエージェントがノード間で移動する（ステップ４２６）。このように移動したエージェントは移動先ノードで活動を再開して（ステップ４２７）移動成功となる（ステップ４２８）。
【００９６】
但し、ステップ４２１，４２３，４２５のいずれかで信頼しないと判断された場合は、セキュリティ違反による移動失敗が発生し（ステップ４２９）、プランは実行失敗となる。このようにプランが実行失敗となった場合は、再プランニングを行うことによって、例えば、プランで指定されている移動先を、エージェントが探しているファイルと同じファイルがありそうな他のダウンロードサイトに変更し、そのうえで改めてプランを実行すればよい。
【００９７】
〔４−２−２．プランニングに関する処理〕
また、エージェントは、プランニングを許さないノード上でプランニングを行うことを回避する。ここで、図１０は、エージェントにおいてプランニング要求が発生した場合の処理手順を示すフローチャートである。すなわち、プランニング要求が発生すると（ステップ４３１）、エージェントが現在いるノードがプランニングを認めているかどうかが判断され（ステップ４３２）、認めている場合はプランニングが行なわれ（ステップ４３３）、生成したプランが実行される（ステップ４３４）。
【００９８】
一方、エージェントが現在いるノードがプランニングを認めない場合は（ステップ４３２）、セキュリティ違反によるプランニング失敗とみなされる（ステップ４３５）。このような場合、例えば１つ前のノードへ戻って（ステップ４３６）、再プランニングなど、プランニング失敗に続く動作を継続する（ステップ４３７）などの対応が可能である。また、移動先のノード等でプランニングが許されないことが予めわかっている場合などは、移動前に必要なプランニングを済ませてから移動することも考えられる。
【００９９】
〔４−２−３．ファームも信頼性を判断する例〕
なお、ノードにファームがあり、エージェントがファーム間で移動しようとするときに、ファームのあるノードだけでなく、ファームも移動元や移動先のノードについて信頼性を判断する場合の処理手順を図１１に示す。この手順では、セキュリティの判断がノードとファームによって多重に行われるので、情報処理の安全性が一層向上する。
【０１００】
〔４−２−４．移動履歴を用いた判断〕
なお、信頼リスト管理部４１５によって、エージェントがどの領域に移動したかを、信頼リスト格納部４１４内の履歴に順次記録しておき、各領域は、エージェントが他の領域から移動してこようとするとき、当該エージェントの前記履歴と、領域ごとの信頼リスト、及び予め定められた基準に基づいて、当該エージェントを受け入れるかどうかを判断してもよい。また、この場合は、エージェント内のデータ領域に履歴を記録しておいてもよい。
【０１０１】
そして、移動先の領域は、履歴に基づく判断を履歴中の全てのノード等に関して行い、エージェントの持っている履歴の中に信頼できないノードがあったり、信頼できないノードが一定の数を越えている場合に受け入れを拒否する。
【０１０２】
〔４−３．効果〕
以上のように、第４実施形態によれば、各領域は信頼できる領域からしかエージェントを受け入れず、エージェントも信頼できる領域にしか移動しない。このため、エージェントも領域も互いに相手から不法アクセス等によって侵害される危険を軽減できる。
【０１０３】
また、第４実施形態では、エージェントを受け入れる領域は、エージェントが移動してこようとする最新の移動元だけでなく、エージェントが過去にいたことのある他の領域についても信頼性を判断できるので、侵害の可能性から効果的に保護される。例えば、悪意を持っている領域は、移動してきたエージェントを改竄してコンピュータウイルスのような有害な機能を埋め込んだり、有害なエージェントとすり替えて送り出す可能性がある。このため、エージェントを受け入れる領域は、履歴に基づいて、過去に信頼できない領域にいたことのあるエージェントを締め出すことによって、前記のような有害な機能を埋め込まれたり、すりかえられたエージェントによる侵害を回避することができる。
【０１０４】
さらに、第４実施形態では、プランニングを認めていない領域におけるプランニングが回避される。このため、有害なスクリプトを持ったプランを生成したり、プランニングに見せ掛けて有害な処理をしようとするエージェントから領域が保護される。また、領域が、エージェントにプランニングまでさせる資源の余裕がない場合、資源が不当に消費されることがない。
【０１０５】
さらに、エージェントにとっても、プランニングを支援するふりをしてプラン内に不当なスクリプトを埋め込もうとする領域から保護される。また、知識ベースが十分整備された領域でのみプランニングが行われるので、適切なプランが生成され、情報処理が円滑に行われる。
【０１０６】
また、各ノード等が信頼できるかの情報は、ネームサーバなど１箇所に集中して保存し、各ノード等はこの集中保存された情報を参照するようにすれば、信頼性に関する情報の保存領域が節約でき、また、情報の更新が一元化できるので、ノード毎に持っている情報が食い違うといった事態を防止できる。さらに、悪意のある人物や領域が、信頼性に関する情報自体を改竄しようとする場合も、情報を集中保存している１箇所だけについて重点的にセキュリティを強化すれば足りる。
【０１０７】
〔５．第５実施形態…エージェントのトレースと復元〕
第５実施形態は、エージェントが複数のノード間を移動して情報処理を行うエージェントシステムにおいて、エージェントの情報を保存しておき、ノードの障害でエージェントが消滅したとき、エージェントを復元できるようにしたものである。
【０１０８】
〔５−１．構成〕
第５実施形態は、複数のノードをコンピュータネットワークで接続したもので、図１２は、第５実施形態の構成を示す機能ブロック図であり、特に、１つのノードＲについて具体的な構成を例示したものである。この図に示すように、ノードＲは、図１６に示したと同様のローカル情報記憶手段５１１と、プラン生成手段５１２と、エージェント情報記憶手段５１３と、プラン実行手段５１４と、入出力手段５１５と、管理手段５１６（図１６のエージェント管理部７に対応する）を有するほか、エージェントの情報５１７を保存する保存手段５１８と、復元手段５１９とを有する。
【０１０９】
このうち、保存の対象となるエージェントの情報５１７は、後にエージェントを復元できるだけの情報であり、エージェントのプランや変数領域などである。また、保存手段５１８は、エージェントが他のノードへ移動する直前及び他のノードから移動してきた直後に、エージェントの情報５１７を保存する手段である。また、復元手段５１９は、障害によってエージェントが消滅した場合に、保存されている情報５１７を用いてエージェントを復元する手段である。この復元手段５１９は、ノードが再起動された場合にエージェントを自動的に復元する他、ユーザから依頼を受けた場合にエージェントを復元するように構成されている。
【０１１０】
また、第５実施形態では、ネットワークＮのネームサーバ５１０が、各エージェントがどのノードに移動するかを履歴として順次記録するように構成されている。また、ユーザがエージェントを生成してネットワークＮに送り出すのに用いるユーザのノードＵには、確認手段Ｕ１と、依頼手段Ｕ２が設けられている。
【０１１１】
このうち確認手段Ｕ１は、ネームサーバ５１０と通信することによって、前記履歴に記録された最新のノードを確認し、さらに、その最新のノードと通信することによって、当該最新のノードにおけるエージェントの状態を確認するための手段である。また、この確認手段Ｕ１は、前記最新のノードにおいてエージェントが消滅している場合に、この最新のノード以前にエージェントがいた他のノードを前記履歴に基づいて確認するのにも用いられる。また、依頼手段Ｕ２は、確認した前記他のノードに、エージェントの復元を依頼するための手段である。
【０１１２】
〔５−２．作用及び効果〕
上記のような構成を有する本実施形態において、移動してくるエージェントを受け入れるノードで、障害回復後にエージェントが自動的に復元する場合の処理手順を図１３のフローチャートに示す。
【０１１３】
〔５−２−１．情報の保存〕
すなわち、この手順では、エージェントが移動してくるとき（ステップ５２０）、エージェント管理手段がエージェントの情報を受け入れると（ステップ５２１）、保存手段５１８は、受け入れた情報すなわち移動の直後のエージェントの情報５１７（図１２）をコピーしてノードのローカルファイルＬＦに保存する（ステップ５２２）。ここで保存する情報５１７は、エージェントの活動を継続するために必要な全ての情報であり、具体的には、エージェントのプラン、プラン実行のための各種変数、エージェントが所持しているファイルなど、システム構成に応じて定めればよい。なお、エージェントを送り出す側のノードでも、移動直前のエージェントの情報５１７が保存される。
【０１１４】
〔５−２−２．エージェントの復元〕
そして、移動してきたエージェントが活動を開始した後（ステップ５２４）、移動後のノードで障害が発生したためにエージェントが活動を中断した場合は、障害が回復してノードが再起動（再立ち上げ）されると（ステップ５２５）、復元手段５１９は、情報が保存されているエージェントのうち、障害で消滅したものがないかをチェックし（ステップ５２６）、消滅しているエージェントについては、保存されていた情報５１７を用いてエージェントを復元し（ステップ５２７）、復元されたエージェントが活動を再開する（ステップ５２８）。
【０１１５】
〔５−２−３．移動履歴の記録〕
また、エージェントがどのノードを経由して移動しているかを移動履歴として、ネームサーバ５１０など特定のノードに順次記録してゆけば、ノードやユーザがこの移動履歴を利用することによってエージェントをトレース（追跡）することができる。なお、ネームサーバ（ネーミングサービス）とは、一般には、ノード名からＩＰアドレスを検索するサーバであるが、移動履歴の保存は必ずしもネームサーバに行う必要はなく、他の適当なサーバを定めて保存したり、エージェント内部に保存してもよい。
【０１１６】
図１４は、このように保存された履歴を利用してユーザがエージェントをトレースし、必要に応じてエージェントの復元を依頼する処理手順を示すフローチャートである。
【０１１７】
〔５−２−４．最新位置の確認〕
すなわち、自分の使用しているノードＵからエージェントを送り出したユーザが、エージェントのトレースを自分のノードに指示したとする（ステップ５３０１）。なお、全てのエージェントには、ユーザのノードＵで当初生成されたときに固有のＩＤが割り当てられており、エージェントに関する問い合わせや復元の依頼では、このＩＤに基づいて対象となるエージェントが特定される。
【０１１８】
ユーザのノードＵでは、トレースの指示を受けて、確認手段Ｕ１が、エージェントの移動履歴を保存しているネームサーバ５１０へ、エージェントの最新位置を問い合わせる（ステップ５３０２）。この問い合わせを受けたネームサーバ５１０は、移動履歴に最後に追加されたノードを、エージェントの最新位置の情報として返送してくる（ステップ５３０３）。この場合、エージェントは、この最新位置であるノードに現在存在しているであろうと通常は考えられる。
【０１１９】
〔５−２−５．エージェントの状態の確認〕
このため、ノードＵの確認手段Ｕ１は、最新位置であるノードに、エージェントの状態を問い合わせる（ステップ５３０４）。この問い合わせに対して（ステップ５３０５）、動作中との応答があった場合はエージェントは動作を無事継続しているので処理は終了する（ステップ５３０６）。一方、最新位置であるノードでシステムダウンなどの障害が発生している場合は応答がなく、これによって、ノードの障害でエージェントが活動を中断していることが判明する。
【０１２０】
〔５−２−６．エージェントの復元の依頼〕
この場合、ユーザは、自分の判断でエージェントの復元をノードＵに指示する。この指示を受け、ノードＵの確認手段Ｕ１は、障害が起きたノードの１つ前にエージェントがいたノードの位置をネームサーバ５１０に問い合わせ、結果を得る（ステップ５３０８）。そして、ノードＵの依頼手段Ｕ２は、１つ前のノードへエージェントの復元を依頼する（ステップ５３０９）。
【０１２１】
この依頼に対して、１つ前のノードでも障害が発生しているために応答がないときは（ステップ５３１０）、ステップ５３０８に戻り、さらにもう１つ前のノードを問い合わせ、復元を依頼するが（ステップ５３０９）、１つ前のノードが正常に機能している場合は、１つ前のノードでエージェントが復元され（ステップ５３１１）、エージェントは障害が発生した直前のノードで活動を再開する（ステップ５３１２）。
【０１２２】
〔５−２−７．エージェントが復元される例〕
続いて、障害によって消滅したエージェントが復元される例を示す。例えば、エージェントがノードＡ→Ｂ→Ｃと順次移動し、最新のノードＣにいるときに、ノードＣのシステムダウンによって消滅したとする。この場合、一例として、ノードＣにこのエージェントが移動してきた直後の情報を使って、ノードＣが再起動されたときにエージェントが自動的に復元され、ノードＣでの活動を再度実行する。
【０１２３】
また、他の一例として、ユーザが自分の生成したエージェントのトレースを行なった結果、ノードＣにいるはずのエージェントが障害のために動作していないことを知ったとする。この場合、ユーザが、エージェントがノードＣの直前にいたノードＢを指定してエージェントの復元を依頼したとする。この依頼を受けて、ノードＢでは、ノードＣへの移動直前に保存された情報を使ってエージェントが復元され、移動直前の状態から活動を再開する。
【０１２４】
活動を再開したエージェントは、再びノードＣへ移動しようとするが、この時点でノードＣがまだ稼働していないときは、ノードＣへの移動が失敗となり、エージェントは、ノードＣと同じデータを持っていそうな他のノード（例えばミラーサイト）を次の移動対象として再プランニングを行い、新しく生成したプランを実行して活動を続行する。
【０１２５】
なお、情報を保存しておくのは、エージェントが現在いる最新のノードと、その一つ前のノードが適当と考えられるが、これを増やし、例えば最新のノードを含めて３つとするなど、適宜変更できる。
【０１２６】
〔５−３．効果〕
以上のように、第５実施形態では、エージェントの移動時に、移動前や移動後のノードでエージェントのプランや変数領域などエージェントを復元できるだけの情報を保存しておく。そして、ノードの障害によってエージェントが消滅しても、自動的に、又はユーザからの依頼によって、保存しておいたデータからエージェントを再生成して復元することによって処理が再開される。これによって、エージェントは消滅する少し前の状態から活動を継続することができ、ユーザがエージェントを最初から生成し直したり、エージェントが処理を最初からやり直す必要がなくなる。
【０１２７】
具体的には、移動後のノードが正常に再起動できている場合は、そのノードにエージェントが移動してきた直後の状態から活動を再開することができるし、移動後のノードで障害が継続している場合は、１つ前のノードで移動前の状態から活動を再開することができる。
【０１２８】
また、ノードの再起動時にエージェントが自動的に復元される場合は、エージェントシステムのユーザや管理者がエージェントの復元を要求したり指示する負担が解消される。一方、ユーザからの依頼を待ってエージェントが復元される場合は、エージェントが消滅したノードが障害から復旧していない場合でも、ユーザはそのノード以前にエージェントがいた他の所望のノードに依頼することによってエージェントを復元できる。
【０１２９】
特に、エージェントの移動履歴を用いれば、ユーザはエージェントをトレース（追跡）して現在の状態を確認したり、エージェントが過去にいたノードにエージェントの復元を依頼することができる。
【０１３０】
〔６．他の実施の形態〕
なお、本発明は上記実施の形態に限定されるものではなく、次に例示するような他の実施形態をも含むものである。例えば、本発明において、ネットワークの規模、形式、ノード数などは自由であり、エージェントを用いて行う情報処理の種類や、アクション定義、知識、プランなどを記述する言語の形式も自由に選択しうる。
【０１３１】
また、第２実施形態において、未確定知識に用いられた変数の値が確定したかどうかチェックし、確定した値を知識に反映させる処理は、随時行えばよい。すなわち、第２実施形態では生成されたプラン全体を実行した後に行ったが、プラン中の命令を１つ実行する毎にチェックなどを行ってもよい。また、変数を含んだままの未確定の状態で、プランニング時に参照したりプラン中に使用したい知識も考えられる。このため、変数を含んだままの未確定な知識も、確定している知識に準じてプランニングで参照させることも考えられる。
【０１３２】
さらに、このように未確定な知識を、プランニングで参照させるかどうかを、ユーザが自由に指定できるようにしてもよい。このように未確定の知識についても、プランニングの際に参照するかどうかを、ユーザがその知識の性質に応じて自由に指定できるようにすれば、知識の取り扱いに自由度が増え、システムの柔軟な運用が可能となる。
【０１３３】
また、第４実施形態では信頼リストを１箇所に集中保存したが、信頼リストは、ノードごと、ファームごと及びエージェントごとに個別に設けることもできる。この場合は、各ノード及びファームがプランニング動作を許可するかどうかの情報はエージェントが持てば足りる。このように信頼リストを分散保存しておく場合は、例えば、ノード等が持つ信頼リストは、それら各ノード等の管理者が情報を収集して作成しておく。また、エージェントが持つ信頼リストは、情報処理をしてもらうためにそのエージェントの生成を依頼する依頼者が作成し、また、ノード等が、例えば本来のエージェントの行う作業の一部を代行させるために別のエージェントを派生的に生成する場合は、生成するノード等がその派生的エージェントに与えるなどが考えられる。
【図面の簡単な説明】
【０１３４】
【図１】本発明の第１実施形態におけるノードの構成を示す機能ブロック図。
【図２】本発明の第１実施形態において、プランニングとプラン実行の手順を示すフローチャート。
【図３】本発明の第２実施形態におけるノードの構成を示す機能ブロック図。
【図４】本発明の第２実施形態における処理手順を示すフローチャート。
【図５】本発明の第３実施形態におけるノードの構成を示す機能ブロック図。
【図６】本発明の第３実施形態において、try ブロックとcatch ブロックを用いて例外処理が定義されたプランのスクリプトの例を示す図。
【図７】本発明の第３実施形態におけるプラン実行の手順を示すフローチャート。
【図８】本発明の第４実施形態の構成を示す機能ブロック図。
【図９】本発明の第４実施形態において、エージェントが領域間で移動する場合の処理手順を示すフローチャート。
【図１０】本発明の第４実施形態において、プランニングに関する処理手順を示すフローチャート。
【図１１】本発明の第４実施形態において、ノードに加えてファームも信頼性を判断する場合の処理手順を示すフローチャート。
【図１２】本発明の第５実施形態の構成を示す機能ブロック図。
【図１３】本発明の第５実施形態において、エージェントの情報が保存され、ノードの障害で消滅したエージェントが復元される処理手順を示すフローチャート。
【図１４】本発明の第５実施形態において、ユーザがエージェントをトレースして復元を依頼する場合の処理手順を示すフローチャート。
【図１５】従来のエージェントシステムの構成例を示すフローチャート。
【図１６】プランニングを行う従来のエージェントシステムの構成例を示すフローチャート。
【図１７】従来のエージェントシステムにおける処理手順を示すフローチャート。
【図１８】エージェントシステムにおいて、生成途中のプランの例を示す概念図。
【図１９】エージェントシステムにおいて、完成したプランの例を示す概念図。
【図２０】エージェントシステムにおけるプランニングの手順を示すフローチャート。
【図２１】エージェントシステムにおいて、エージェントがノード間で移動する手順を示すフローチャート。
【図２２】エージェントシステムにおけるエージェントのライフサイクルを示す概念図。
【図２３】エージェントシステムにおいてノード上に複数のファーム（フィールド）が存在する状態を示す概念図。
【符号の説明】
【０１３５】
１…ローカル情報記憶手段
２…更新手段
３…エージェント情報記憶手段
４…入出力手段
５…プラン生成手段
６…プラン実行手段
７…エージェント管理部
Ｌ…ローカルマシン
Ｒ…リモートマシン
Ｎ…ネットワーク
１１１…アクション定義（の集合）
１１２…スクリプト実体の集合
１１３…知識（対象に関する情報の集合）
１１４，３１３…スクリプト変数
１１５…プランナ
１１６…プラン
１１７…実行器
２１１…エージェント知識ベース
２１２…未確定知識ベース
２１３…エージェント知識管理手段
２１４…エージェント管理手段
２１５…プラン実行手段
２１６…プランニング手段
３１１…プラン
３１２…実行手段
３１３…スクリプト変数
３１４…例外処理手段
３１５…エージェント動作制御手段
４１１…ノード管理部
４１２…ファーム管理部
４１３…エージェント管理部
４１４…信頼リスト格納部
４１５…信頼リスト管理部
４１６…判断部
５１１…ローカル情報記憶手段
５１２…プラン生成手段
５１３…エージェント情報記憶手段
５１４…プラン実行手段
５１５…入出力手段
５１６…管理手段
５１７…情報
５１８…保存手段
５１９…復元手段
５１０…ネームサーバ
Ｕ…ユーザのノード
Ｕ１…確認手段
Ｕ２…依頼手段
Ｃ…条件
Ｐ…動作
Ｓ…状態
８００Ｎ…ネットワーク
８００Ｌ…ローカルノード
８００Ｒ…リモートノード
８０１…エージェント情報記憶手段
８０２…解釈実行手段
８０３…入出力手段
８０４…エージェント管理手段
ＳＴＥＰ…手順の各ステップ
【図１】
0003692137.tif 000007
【図２】
0003692137.tif 000008
【図３】
0003692137.tif 000009
【図４】
0003692137.tif 000010
【図５】
0003692137.tif 000011
【図６】
0003692137.tif 000012
【図７】
0003692137.tif 000013
【図８】
0003692137.tif 000014
【図９】
0003692137.tif 000015
【図１０】
0003692137.tif 000016
【図１１】
0003692137.tif 000017
【図１２】
0003692137.tif 000018
【図１３】
0003692137.tif 000019
【図１４】
0003692137.tif 000020
【図１５】
0003692137.tif 000021
【図１６】
0003692137.tif 000022
【図１７】
0003692137.tif 000023
【図１８】
0003692137.tif 000024
【図１９】
0003692137.tif 000025
【図２０】
0003692137.tif 000026
【図２１】
0003692137.tif 000027
【図２２】
0003692137.tif 000028
【図２３】
0003692137.tif 000029