(57)【要約】本発明の実施例は最低一つのセンサ要素を有し、ゴール又は変更メソッド要素、及び最低一つのビヘビア要素を有する最低一つのエージェントからなるコンピュータで実行可能な要素を有するコンピュータで読み取り可能な媒体を含む。最低一つのセンサ要素は、ゴール又は変更メソッド要素から発生する最低一つの値に最低一部基づく最低一つのイベントを発生させる。最低一つのビヘビア要素は最低一つのセンサ要素から発生する最低一つのイベントに最低一部基づく実行スレッドを起動するかどうかを決定する。システムの複合実行スレッドは、エージェントレベル、イベントレベル、センサレベル及びビヘビアレベル上のいずれの演算子によっても発生させることができる。
2007523397.tif 000002
【特許請求の範囲】
【請求項１】
コンピュータで実行できる要素を有するコンピュータで読み取り可能なメディアであって、ゴール又は変更メソッド要素及び少なくとも一つのビヘビア要素を含む少なくとも一つのセンサ要素を有する少なくとも一つのエージェントからなり、ここで少なくとも一つのセンサ要素は、ゴールまたは変更メソッド要素から発した少なくとも一つの値に少なくとも一部基づく少なくとも一つのイベントを発生させ、そして少なくとも一つのビヘビア要素は少なくとも一つのセンサ要素から発生した少なくとも一つのイベントに少なくとも一部基づく実行スレッドを起動させるかどうかを決定するコンピュータで読み取り可能なメディア。
【請求項２】
少なくとも一つのビヘビア要素は、少なくとも一つの発生イベントを記録するかどうかを決定する、請求項１のコンピュータで読み取り可能なメディア。
【請求項３】
少なくとも一つのイベントは変更又は更新イベントの一つである、請求項１のコンピュータで読み取り可能なメディア。
【請求項４】
少なくとも一つのビヘビア要素は少なくとも一つのイベント発生センサ要素のエージェントの外側にある、請求項１のコンピュータで読み取り可能なメディア。
【請求項５】
少なくとも一つのビヘビア要素は少なくとも一つのコールを発生させることを含む、請求項１のコンピュータで読み取り可能なメディア。
【請求項６】
少なくとも一つのセンサ要素は少なくとも一つのコールに少なくとも一部基づく少なくとも一つのイベントを発生させるため、そのゴール又は変更メソッド要素により起動される、請求項５のコンピュータで読み取り可能なメディア。
【請求項７】
少なくとも一つのセンサ要素は少なくとも一つのコールを発生させるビヘビア要素のエージェントの外側にあるエージェントに含まれる、請求項６のコンピュータで読み取り可能なメディア。
【請求項８】
ビヘビア要素は、少なくとも一つのセンサ要素から発生した少なくとも一つのイベントに少なくとも一部基づく少なくとも一つの他のビヘビア要素又はエージェントを包含又は再開する、請求項１のコンピュータで読み取り可能なメディア。
【請求項９】
少なくとも一つのビヘビア要素が、実行スレッドが起動すると少なくとも一つの他のビヘビア要素により受けられるステータスイベントを発生させる、請求項１のコンピュータで読み取り可能なメディア。
【請求項１０】
少なくとも一つのビヘビア要素は実行スレッドの終了時、少なくとも一つの他のビヘビア要素により受けることができるステータスイベントを発生させる、請求項１のコンピュータで読み取り可能なメディア。
【請求項１１】
少なくとも一つのビヘビア要素が独立したトリガ条件に基づき実行スレッドを起動させるかどうかを決定する、請求項１のコンピュータで読み取り可能なメディア。
【請求項１２】
独立したトリガ条件が特定実行スレッド起動のための優先順位ステータスを更に決定し、そして複数の実行スレッドが起動についてのそれらの優先順位ステータスに基づき順に実行される、請求項１１のコンピュータで読み取り可能なメディア。
【請求項１３】
少なくとも一つのビヘビア要素中の、又は外のｃｏｎｔｉｎｕｅＷｈｅｎ，ｒｅｓｕｍｅＷｈｅｎ，およびｃｏｍｐｌｅｔｅＷｈｅｎステートメントの少なくとも一つが起動に対するそれらの優先順位ステータスに基づき実行スレッドを同期させるように作動する、請求項１２のコンピュータで読み取り可能なメディア。
【請求項１４】
独立したトリガ条件が少なくとも一つのｗｈｅｎステートメント及び少なくとも一つのｉｆステートメントを含み、ｗｈｅｎステートメントは独立したトリガ条件が作動するようになるように応答するイベントを表示し、そしてｉｆステートメントは予め決められたフィルタ値に基づく、請求項１１のコンピュータで読み取り可能なメディア。
【請求項１５】
独立したトリガ条件は複数の発生イベントが作動するようになることを要求する、請求項１１のコンピュータで読み取り可能なメディア。
【請求項１６】
独立したトリガ条件は少なくとも一つのビヘビア要素の局部認識に基づく、請求項１１のコンピュータで読み取り可能なメディア。
【請求項１７】
少なくとも一つのビヘビア要素は独立したトリガ条件が再度作動するようになる前に、作動する独立したトリガ条件に対し実行スレッドを起動する、請求項１４のコンピュータで読み取り可能なメディア。
【請求項１８】
少なくとも一つのビヘビア及びセンサ要素は少なくとも一つのキーワードを定義し、少なくとも一つのキーワードは少なくとも一つの特殊エージェント、少なくとも一つのビヘビア又はセンサ及び独立したトリガ条件を起動するための特定イベントを表示する、請求項１のコンピュータで読み取り可能なメディア。
【請求項１９】
少なくとも一つのキーワードは、エージェント又はイベントは少なくとも一つのエージェントに未知であり、ビヘビア又はセンサ要素のいづれかを表示するように作動する、請求項１８のコンピュータで読み取り可能なメディア。
【請求項２０】
少なくとも一つのキーワードは、予め決められたエージェントクラスを表示するように作動する、請求項１８のコンピュータで読み取り可能なメディア。
【請求項２１】
少なくとも一つのキーワードは予め決められたエージェントクラス内の特定エージェントを表示する、請求項２０のコンピュータで読み取り可能なメディア。
【請求項２２】
少なくとも一つのキーワードは特定のビヘビア又はセンサが起動するときを表示するように作動する、請求項１８のコンピュータで読み取り可能なメディア。
【請求項２３】
少なくとも一つのエージェントはイベントを発生させる、請求項１のコンピュータで読み取り可能なメディア。
【請求項２４】
ビヘビアを基礎とした多エージェント計算システムを可能にするコンピュータで読み取り可能なメディア上に具現化されたコンピュータプログラムであって、少なくとも一つのゴール又は変更メソッド要素は少なくとも一つの値を発生させ、少なくとも一つのセンサ要素は、少なくとも一つのゴール又は変更メソッド要素から発生する少なくとも一つの値を少なくとも一部基づいた少なくとも一つのイベントを発生させ、そして少なくとも一つのビヘビア要素は少なくとも一つのセンサ要素から発生する少なくとも一つのイベントに少なくとも一部基づいた実行スレッドを起動するかどうかを決定し、リクエストを受けるためのコード部分、および少なくとも一つのゴール又は変更メソッド要素、及び少なくとも一つの通常、徹底又は冗長ビヘビア要素を含む、少なくとも一つのセンサ要素を有する複数のエージェントからなる実行骨組からなる、コンピュータプログラム。
【請求項２５】
リクエストは少なくとも一つのエージェントから受けられる、請求項２４のビヘビアに基づく多エージェント計算システムを可能にするためのコンピュータで読み取り可能なメディア上に具現化されたコンピュータプログラム。
【請求項２６】
実行骨組はエージェント指向言語構造になるためオブジェクト指向言語構造上に重畳され、オブジェクト及びエージェントはエージェント指向言語構造内の相互交換可能な要素である、請求項２４のビヘビアに基づく多エージェント計算システムを可能にするためのコンピュータで読み取り可能なメディア上に具現化されたコンピュータプログラム。
【請求項２７】
エージェント指向言語構造はオブジェクト指向に基づく言語構造からなる、請求項２６のビヘビアに基づく多エージェント計算システムを可能にするためのコンピュータで読み取り可能なメディア上に具現化されたコンピュータプログラム。
【請求項２８】
エージェントは複製可能であるエージェントのコミュニティを形成する、請求項２６のビヘビアに基づく多エージェント計算システムを可能にするためのコンピュータで読み取り可能なメディア上に具現化されたコンピュータプログラム。
【請求項２９】
エージェントは複製コミュニティ間で移動できるエージェントのコミュニティからなる、請求項２８のビヘビアに基づく多エージェント計算システムを可能にするためのコンピュータで読み取り可能なメディア上に具現化されたコンピュータプログラム。
【請求項３０】
エージェントは目標コミュニティ識別パラメータを知ることによってコミュニティ間で移動する、請求項２９のビヘビアに基づく多エージェント計算システムを可能にするためのコンピュータで読み取り可能なメディア上に具現化されたコンピュータプログラム。
【請求項３１】
エージェントは目標コミュニティを探す、請求項２９のビヘビアに基づく多エージェントシステムを可能にするためのコンピュータで読み取り可能なメディア上に具現化されたコンピュータプログラム。
【請求項３２】
層状システムはエージェントコミュニティによりそれら自身を格子計算で作動するようにする、請求項２６のビヘビアに基づく多エージェント計算システムを可能にするためのコンピュータで読み取り可能なメディア上に具現化されたコンピュータプログラム。
【請求項３３】
エージェントは少なくとも一つのスタブの使用によりコミュニティを超えて作動し、スタブは少なくとも一つのセンサを保持し、そして自動的に発生する、請求項２６のビヘビアに基づく多エージェント計算システムを可能にするためのコンピュータで読み取り可能なメディア上に具現化されたコンピュータプログラム。
【請求項３４】
エージェントはサービスを達成するためまとめられる名前空間の一部になる、請求項２６のビヘビアに基づく多エージェント計算システムを可能にするためのコンピュータで読み取り可能なコンピュータプログラム。
【請求項３５】
サービスはキーワード又は名前空間を注記する属性により表示される、請求項２６のビヘビアに基づく他エージェント計算システムを可能にするためのコンピュータで読み取り可能なメディア上に具現化されたコンピュータプログラム。
【請求項３６】
少なくとも一つのエージェントは神経ネットワークのニューロン、少なくとも一つのセンサとして少なくとも一つのトリガ値を有する少なくとも一つのエージェント、及び少なくとも一つのビヘビア要素は少なくとも一つの下位階層の少なくとも一つのトリガ値からの少なくとも一つのイベントに応答するように作動する、請求項２６のビヘビアに基づく多エージェント計算システムを可能にするためのコンピュータで読み取り可能なメディア上に具現化されたコンピュータプログラム。
【請求項３７】
少なくとも一つのエージェントは、少なくとも一つの自己書き込み学習エージェントを実行するため少なくとも一つのビヘビア内の少なくとも一つの突然変異又は交差演算子を利用し、これによりコンピュータプログラムが自動的に進化する、請求項２６のビヘビアに基づく多エージェント計算システムを可能にするためのコンピュータで読み取り可能なメディア上に具現化されたコンピュータプログラム。
【請求項３８】
少なくとも一つのビヘビアは自己管理のため少なくとも一つのファイルに割り当てられる、請求項２６のビヘビアに基づく多エージェント計算システムを可能にするためのコンピュータで読み取り可能なメディア上に具現化されたコンピュータプログラム。
【請求項３９】
エージェント指向のデータベースであって、少なくとも一つのセンサ要素は、ゴール又はメソッド変更要素から発生する少なくとも一つの値に少なくとも一部基づく少なくとも一つのイベントを発生させるように作動し、ゴール又はメソッド変更要素を含む少なくとも一つのセンサ要素を有する少なくとも一つのエージェントを含む多くの分野からなるデータベース。
【請求項４０】
少なくとも一つのエージェントはビヘビア要素を含む、請求項３９のデータベース。
【発明の詳細な説明】
【発明分野】
【０００１】
本発明は一般にコンピュータプログラム言語に関し、特にビヘビアに基づく多エージェント計算システムを実行するためのシステム及び方法に関する。
【発明を実施するための最良の形態】
【０００２】
本発明の実施例は、データタイプとしてのビヘビアに基づく多エージェントシステムを実行するためのいくつかの方法についての装置及び実施例を含む。
【０００３】
特定のプログラム言語概念はＲＩＤＬ（ロボット‐知能定義言語）と称する特定の言語実行について、明細書で述べられる。しかし明細書に記述されるように色々な概念及び態様を使用した他の実行は本発明から離れることなく実行される。
【０００４】
ＲＩＤＬは一態様で伝統的言語にいくつかのキーワードを付けるハードウェア又はソフトウェア（仮想）ロボットプログラムに適したロボットプログラム言語である。例えばＲＩＤＬはＪａｖａの上位集合、Ｃ＃，ＤＯＴＮＥＴ、Ｃ＋＋の上位集合としてのＡＧＥＮＴ＃であるが、しかしＣ＃，ＤＯＴＮＥＴ、Ｃ＋＋およびＪａｖａの他に、他の言語構造が使用されることは理解されるべきである。従って、明細書で記述されるようなＲＩＤＬはＲＩＤＬ適用ファミリを駆動させる色々な概念、原理及び方法の要約記述を含む。
【０００５】
明細書で記述されるように、ＲＩＤＬの言語、方法論及び実行はコンパイラに関して記述されるが、しかし本発明はコンパイルに限定せず、本発明は又明細書に記述されるように特殊な文法及び実行にも限定されない。例えば本発明の態様はインタープリタ又は他の言語読み取りエンジンを使用して実行される。
｛コンパイラ・レベルの態様｝
＜データタイプとしてのエージェント＞
【０００６】
色々な実施例において、付加キーワードは多エージェントシステムの生成を非常に容易にする。例えばキーワード「エージェント」は伝統的な「オブジェクト」と同様のレベルで付加される。ここでの目的のため、キーワードエージェント及びオブジェクトは文法の観点から相互置換可能である。キーワードの効果はブロックがエージェントを定義することを表示する。この技術の熟練者は「エージェント」以外の他の言葉が使用できることに気付くだろう。このようなオブジェクトは事実上エージェントであることを表示する属性をオブジェクトに注記することもまた可能である。文法はどうであれ、オブジェクティブは囲まれているものはエージェントであり、そのように作動することを表示することである。
【０００７】
本発明の一態様によると、エージェントはオブジェクトと全く同様の生来のデータタイプと考えられる。オブジェクトについて実行される全ての作動はまたエージェントにも実行される。このような作動の例は新エージェントの生成、エージェントの消滅、パラメータとしての通過エージェント、エージェントへのレファレンス（ポインタ）生成、エージェント複製等である。
【０００８】
オブジェクトについてと同様に、エージェント定義は事実上エージェントのクラスを定義する。例えばエージェント例は新ステートメントによりまたはそのタイプ（エージェントクラス）の新変数が定義される場合作成される。
【０００９】
最後に全てのオブジェクトは定義エージェントによる言語が定義され、従ってオブジェクトをエージェントであると指定する必要はない。コンパイラは以下に述べる特徴が使用される（センサそして／又はビヘビア）かどうかを決定することにより能動エージェント（エージェント）と受動エージェント（オブジェクト）の間を区分する。従ってデータタイプとしてのエージェントは以下に述べる色々な特徴を考慮することによってのみ完全に理解できる。
＜センサ＞
【００１０】
センサはエージェントが応答する内部又は外部信号を定義する。明細書で使用されるセンサはセンサと注記される伝統的タイプの変数である。この注記は属性を変数に付加するか又は特別変数が定義されることを表示するために新キーワードを使用することにより行われる。一つの例で属性「センサ」は既存変数に注記するために使用される。
【００１１】
センサは多エージェントシステムの一部である。一実施例でセンサ１０４は特定エージェントの一部であるが、しかしセンサはまた「グローバル」として定義され、ここでそれはいずれかの特定エージェントの一部ではなく、全エージェントに利用できる（従ってそれはエージェントができるよう「消滅」できない）。
【００１２】
センサが更新又は変更されると、それは何が発生したかを表示するためイベントを発信する。センサに関連するイベントは二つあり、更新イベント及び変更イベントである。センサは以下のように作動する：それが新しい値を受ける毎に、それは更新イベントを発信する。もし新しい値が前の値と異なれば、更新イベントもまた発信される。これらのイベントはビヘビア（以下に述べる）により受けられる。
【００１３】
この時、言語Ｃ＃及びＣ＋＋は、変数に何かが発生する場合、変数がイベントを発信することを可能にする注記を有する。しかしこのイベントを受けるため、リスナは発信変数へ登録しなければならない。反対に本発明の一態様によると、リスナはイベントを受けるために登録する必要はない。例えば「ビヘビア」１０４はイベントのタイプを聞き、そのタイプに適するいかなるイベントでもビヘビア１０６により取り出される。従って本発明は以前の多エージェントシステムとは対照的で、ここでは多くのエージェントはダイナミックであり、ビヘビアはどのエージェントが存在するかを必ずしも知る必要はない。このような場合、ビヘビアはこれらのエージェントに登録できない。この機能はいずれかの演算子が論じられる場合、更に詳細に論じられるだろう。
【００１４】
説明的隠喩を使用するため：もしＣ＃及びＣ＋＋で電話の会話中ならば、ユーザは回線の他端でユーザの知る誰かに話す。しかしもし他端で誰かが何かを云い、そしてそのユーザは相手が出つつあることを事前に知らなかった場合、ユーザは相手に聞き入らないだろう。ＲＩＤＬで、相手が出ることを期待しなかったか又は事前に相手の存在を知らされていなかった場合でさえ、ユーザは他端で話している誰かに聞き入り、ユーザは彼ら全てと会話ができる。従ってこの態様は環境内の、そしてエージェントの連続した変動する数及び変動する環境を持った不確定の意味がある。
【００１５】
Ｃ＃及びＣ＋＋及び関連プログラム言語において、プログラムはイベントを発信する必要性は明確である。プログラマはリスナ（例えば「ｔｈｒｏｗＥｖｅｎｔ（ｍｙＥｖｅｎｔ）」に知らせるため、イベント上のメソッドをコールするためコードを書かなければならない。しかし本発明の色々な態様で、リスナはイベントが記録されるかどうかを決定する。
＜ビヘビア＞
【００１６】
ビヘビアが作動するとは、それがそれ自身の実行スレッドを有することを意味する。ビヘアはプログラマから見れば同時に走る。ビヘビアは値を戻さず、むしろ特定のイベントが発生する場合、取るべきいくつかの作動を定義する。それは外部又は内部イベントに応答して何を行うべきかを定義する。ビヘビアは常に空（ｖｏｉｄ）であり、別の引数はとらない。それらはイベント及びエージェント状態の充分定義された組み合わせで起動することにより応答知性を実行する。
【００１７】
ゴール及びセンサはエージェントの外で可視である一方、ビヘビアは常にプライベ−トであり又はプロテクトされる。プロテクトビヘビアのみが重畳され、それらの可視性（プロテクトされ又はプライベートの）は全チャイルドエージェントにより持続されなければならない。
【００１８】
ビヘビアはビヘビアとして注記されるメソッド（オブジェクトの一部又は本発明においてエージェントの一部である手順）である。この注記はメソッドに属性を付加することにより、又は特定メソッドが定義されることを表示するため新キーワードを使用することにより行われる。そのようなことで一例では、新キーワード「ビヘビア」はこのような特定メソッドを表示するために使用される。
【００１９】
ビヘビアはそれら自身のイベントを有する。例えばビヘビアが始動する毎に、それは起動イベントを発信し、そして終了次第それは終了イベントを発信する。他のイベントは定義され、ここで表示されるイベント名は、正確な文法は変動するので、説明用だけである。他の潜在イベントの例は保留、生成、消滅、待機等である。いくつの数のイベントでも実行できる。一態様でイベントはそのステータスについての他のビヘビア及び他のエージェントへ情報を提供する。一実施例で、ビヘビアは開発者の部分へ何の作用もせず、これらのイベントを発信する。
【００２０】
一実施例でビヘビアはそれらが起動されるような伝統的方法と異なる。例えばそれらがオブジェクト指向方法論で定義されるように、伝統的方法はある別のメソッドにより呼び出される。メソッドは新しい実行スレッド生成の一部として潜在的に呼び出されるが、この場合においてさえそれはメソッドがコールされる時を決定するある外部ロジックである。対照的にビヘビアはそれらが起動される時を越えて完全に制御される。一実施例でビヘビアは外部ロジックにより呼び出されないが、それらは自身が起動する時を決定するだけである。そのようなことでこれらビヘビア１０６は外部コードが作動になる必要はない。
【００２１】
ビヘビアはそれが起動されるべき時を表示するセクションを有する。例えばこのセクションはトリガ条件を含む。トリガ条件は、それはそうである必要はないが、一般に実行するためのコードから分離されている。しかし色々な実施例でトリガ条件はビヘビアの仕様の一部である。
【００２２】
上で述べたように、トリガ条件はビヘビアに近いことに注目することが重要である。実行されるコード及びそれを実行させる条件は、同一場所へまとめられる。これはシステムのビヘビアが分離していることについて推論することを可能にする。エージェントの作動を記述する場合、何がこれらの認識をさせ、誰がこれらをさせているかを知ることなく、世界のその局部認識に基づくそのビヘビアを記述することができる。エージェントはその周囲の力に応答して、これは例えば経済、コンピュータ科学、金融、ビジネス、社会科学及び多くの他分野での多くの大規模問題に対する自然なモデルである。
【００２３】
一実施例でトリガ条件はその起動を駆動するためセンサ及びビヘビアにより発信されるイベントを使用する。トリガ条件は二つの部分を概念的に含む、即ちそれが応答するイベントを表示する「ｗｈｅｎ」部分及び、イベントをフィルタするため値及び他のパラメータに基づく「ｉｆ」部分である。Ｖｉｓｕａｌ  Ｂａｓｉｃ、Ｃ＃及びＣ＋＋及びＪａｖａのような他の言語は単一イベントを発信し、そして捕捉することを可能にする。しかし例えばＲＩＤＬにおいて、どのイベントをビヘビアが捕捉したいかを選択するため多くのイベント及び複合条件を使用することが可能である。要するにビヘビアはあるリアルタイム形式の質問をイベントへ適用する。
【００２４】
既知イベントに基づくトリガ条件を定義することが可能である。エージェントはオブジェクトのようにデータタイプであるので、それらを保持する（もし変数に保持される場合）変数名により又は参照（ポインタ）により、それらを参照することが可能である。その結果トリガ条件は静的に定義することができる。
【００２５】
色々な実施例が特定イベントを待つことにより特徴づけられる。第一にそれはエージェント内でどのセンサ又はビヘビアを指定する必要があるかを意味する。次にそれらはどのタイプのイベントが起こることを待っているかを定義する必要がある。例えば自然モデルは待っているエージェント、ドットが続き、次にセンサを指定し、ドットが続き、次にイベントを指定することを表示することである。例えば「ＭｙＡｇｅｎｔ．ＭｙＳｅｎｓｏｒ．更新」は自然モデルである。しかし文法はいかなる形状又は形式をも取り得る。要点はエージェント、次にセンサ／ビヘビアそして最後にイベントを表示することである。
【００２６】
トリガ条件の「ｗｈｅｎ」部分において、イベントは「ｏｒ」キーワードと連結するか又は類似の意味を持った何かにより連結される。これはそれらが、ビヘビアが感知するイベント表を生成することを可能にする。
【００２７】
トリガ条件の「ｉｆ」部分で全ての通常のプログラミング演算子はブール演算子を含み使用される。「ｉｆ」部分において、ビヘビア／メソッドの本体で使用できる変数及び演算子は全て利用できる。例えば範囲内の各変数は使用でき、ここでその範囲はＪａｖａ及びＣ＃及びＣ＋＋のような伝統的言語におけるように定義される。
｛ゴール｝
【００２８】
ゴールはエージェントへのリクエストを実行する。ゴールは能動オブジェクトではなくそれはデータを含まない。直接の帰結としてゴールはそれらに関連するイベントを有しない。ゴールは多数のパラメータでコールされ、そしてこれらのパラメータは複合データタイプである。それらがコールされると、それらはそれらのデータを（受動）データメンバ及びメンバセンサへ送る。従ってそれらはエージェントのインターフェース又は通信チャネルと見なされる。それらはエージェントが応答するかしないかを決めるエージェントに対するリクエストを表現するため、ゴールは通常方法（オブジェクトのように）と異なる。
【００２９】
ゴールもまた他のいかなる通常方法と同様に戻りタイプを有する。センサはゴール内からで通常方法内からでなく設定されるだけなので、メソッドはある種の保障された実行と見なされる一方、ゴールはその結果が各呼び出しで異なるリクエストを実行する。リクエストは考慮されることが保障されていないが、エージェントの推理及び状態に応じ、それらは色々なエージェント作動に至る。結局、エージェントはなすべき更により重要な仕事を有し、エッジでバランスするロボットのように、その音センサにより捕捉された鳥の音へは決して注意を払わない。
【００３０】
ゴールはセンサ値を変更することを可能にする唯一の場所である。それらはエージェントへのリクエストを表示するため、それらはそれらのリクエストをセンサ変更へ変換し、それに対してエージェントの能動部分が応答する。メソッドはエージェントの状態を読むため、又は何かを直接能動的に達成させるために使用される。ゴールは「側面‐効果」を有すのみで、それらはそれが反応できるエージェントに対するリクエストを概念的に説明する。そのようなことで、ゴールはエージェント上のみ利用可能であり、常に受動的なオブジェクト上ではできない。メソッドをコールするならば、エージェントはそれを「知らない」ということも知るだろう。
【００３１】
ゴールは通常方法と同様の方法で文法的に宣言される。しかしそれらはエージェントリクエストを扱うことを表示するため「ゴール」限定子を受ける。
【００３２】
図１は色々なＲＩＤＬエージェント１００構成、それらが発信するイベント及びそれらが処理される場所の間の関係を明確にする。ゴール１０２は、センサ１０４への書き込みアクセスを有し、（同一エージェントにおいてのみ）センサ１０４は変更又は更新イベントを発信することにより新しい値に応答し、これはビヘビア１０６により処理され、それが次に起動及び終了イベントを発信する。これらのイベントは最終的に他のビヘビア（表示なし）により捕捉される。ビヘビア１０６は全てそれら自身のエージェントゴール１０２又は他エージェントのゴールをコールすることにより変更へ影響させようと努力する。
＜イベント演算子＞
【００３３】
待機するイベントの明確な表示はしばしば十分柔軟ではない。例えば開発者が多くのイベントを待ちたい場合、一つの解決法は全ての可能性を徹底的に指定し、しかし以下で定義されるそれらのような他の演算子と組み合わせることである。これは非常に退屈なことである（そして時には情報欠如のため不可能でさえある）。そのようなことで一実施例で本発明は一般的イベントを含む。考え方は指名されたエージェントのセンサ１０４又はビヘビア１０６から来るイベントを待つことである。例えばこれを書く方法はイベント名を除くか又は一般的イベントに対する名称「イベント」を使用することである。又多くのほかの注記を含んでもよい。例えば注記「ＭｙＡｇｅｎｔ．ＭｙＳｅｎｓｏｒ」又は「ＭｙＡｇｅｎｔ．ＭｙＳｅｎｓｏｒ．イベント」は変更及び更新イベントの両方に応答する。
＜センサ／ビヘビア演算子＞
【００３４】
一つのシナリオで、エージェント構造は全体として知られていず、どのビヘビア１０６又はセンサ１０４がエージェント内であるかは知られていない。エージェントのいずれかのビヘビア１０６又はセンサ１０４内の作動について尚知りたいだろう。このため一実施例で「センサ」及び「ビヘビア」のようなキーワードは特定センサ１０４又はビヘビア１０６の表示を置換する。再度他の文法が使用されるが、要点はスタブがセンサ１０４又はビヘビア１０６の明示名の代わりに使用される。例えばこれを書く可能な方法は「ＭｙＡｇｅｎｔ．センサ．変更」である。このエージェントは、エージェントＭｙＡｇｅｎｔのセンサがその値（それはその値を変更したい更新を無視する）を変更するまで待つであろう。この技術の専門家は再度開発者はイベントの指定の選択又は一般イベント表示を使用しなければならない（前章で定義したように）ことに気付くだろう。同じ文脈でエージェントは明示ビヘビアの名称をビヘビアの待機を表示するスタブと置換することができる。例えば「ＭｙＡｇｅｎｔ．ビヘビア．起動」はエージェントＭｙＡｇｅｎｔ内のビヘビアが起動することを待っており、これはどのビヘビアが定義されるかを知る必要なくエージェントは作動するかどうかを監視することを効果的に可能にする、ということを意味する。
【００３５】
センサ１０４及びビヘビア１０６の名称をスタブする能力は第一エージェントの書き込み時に定義されなかった他のエージェントを処理出来るエージェントの適用を可能にする。新構造でトリガ条件の「ｗｈｅｎ」部分で旨く働く。しかし条件の「ｉｆ」部分に関して、例えば１００以上の高い値を有するいかなるセンサにも応答したいのはよいだろう。そのような例でセンサ１０４の名称がスタブされるので、「ｉｆ」部分はそれが１００を超えるかどうかを見るためそれはどのセンサをテストすべきか迷う。そのようなことで「ｉｆ」部分が必要とすることはエージェントのどのセンサ１０４がイベントを発信したかを知ることである。従って一実施例で、「ｗｈｅｎ」節は変数名をもったセンサ１０４の注記を含む。この変数はイベントを発信したセンサ１０４の参照を記憶する。「ｉｆ」部分が「ｗｈｅｎ」部分の後で評価するので、「ｉｆ」部分はセンサ１０４を認識するため、及びその特性（その値のような）を調査するため、この変数を使用できる。
【００３６】
トリガ条件により起動されたビヘビア１０６の本体内で、「ｗｈｅｎ」部分からの変数もまた使用できる。従ってビヘビア１０６は必要であればその応答をイベント発信センサ１０４へ向ける。これは内省属性と組んで特に強力である。
＜エージェント演算子＞
【００３７】
別の例でビヘビア１０６は、ビヘビア１０６がそのトリガ条件を待ち始めた後に、時刻の任意の点でエージェントソサイエティへ入るエージェントを含み、任意のエージェントから来るエージェントに応答したい。事実ビヘビア１０６は受動でアイドルであり、そして開発者側にコードが何もない場合でさえ、ビヘビア１０６は、システムを去る新ジョイナ及びエージェントを含み、システムの各エージェントに気付きたい。
【００３８】
この技術に精通する人は、この問題は基本的に以前の問題と異なることに気付くだろう。エージェントは設計時に定義されるので、従ってエージェンクラスは走行時その定義を変更できない。以前エージェントレベルの演算子はなかったので、それらはどのエージェントについて話をしているかは常に知っていた。従ってイベント、センサ及びビヘビアレベルのいずれの演算子も、もし全エージェントが共にコンパイルされれば、（そしてエージェントの演算子はいずれも使用せず、従って常に既知データタイプ（エージェント）の変数又はポインタを参照し、コンパイラは常に知る）コンパイラにより分解できる。
【００３９】
エージェントレベルの「いずれの」演算子も完全な新レベルの複合を導入する。もしエージェントレベルの「いずれの」演算子も使用されれば、エージェントは、コンパイル時には未知であったソサイエティへ入ることが可能である。これはエージェントが走行時にそれらのいずれの演算子も今や分解せねばならないことを意味する。他のどこからか来るＲＩＤＬエージェントをグループへ入れることを可能にする色々な態様が以下の「走行時レベル態様」の章で論じられる。
【００４０】
一実施例で、エージェントは最初未知であったエージェントについて話すかもしれない。例えば特定エージェントを参照する代わりに、ビヘビア１０６のトリガ条件において、エージェントクラスを参照するかもしれない。上で述べたように、エージェントはデータタイプであり、そのため名前を有する。データタイプの例は名前を有するかもしれないし、又有していないかもしれない（変数対ダイナミックメモリ割り当て）。従ってエージエントデータタイプ（エージェント定義で使用される名前）の名前の使用により、クラスのエージェントは全て表示できる。トリガ条件がエージェントのクラス名を使用する場合、それはエージェントクラスのメンバである任意エージェントからの特定イベントを待つことを実際は意味する。
【００４１】
再度これがトリガ条件の概念の「ｗｈｅｎ」部分に作用する間に、それは「ｉｆ」部分そしてまたコード実行に対する問題を提起する。イベントを取り出す場合、次にそれらはイベントを送出したエージェントが特定条件（トリガ条件の「ｉｆ」部分）に合致するかどうかをチェックしたい。従ってそれらがイベントを受ける場合、それらはまたイベントを送出したエージェントの参照を捕捉する必要がある。
【００４２】
一実施例でエージェントクラスは変数名を注記している。例えばこの変数はイベントをもたらしたエージェントの参照を記憶する。この参照により、パブリックセンサの値を含む、エージェントの全パブリック特性へアクセスする。エージェント参照への通常作動は全てこれらの発生する参照に行われる。
【００４３】
別実施例で、以前未知のエージェントと相互作用できることを望む。このため一実施例で参照（ポインタ）はジェネリック・タイプ・エージェントに含まれる。例えばエージェントはこのジェネリック参照タイプで定義される。例えば「エージェント．センサ．イベント」へのコールはいずれのエージェントがいずれのセンサのいずれのイベントにも応答するだろう。この技術に精通する人は再度異なる文法注記が可能であることに気付くだろう。
＜エージェントレベルイベント及び演算子＞
【００４４】
これまでセンサ１０４及びビヘビア１０６だけがイベントを発信すると仮定して来た。しかし色々な実施例で、エージェント自身もまたイベントを発信する。特にそれらが発生及び消滅することを表示するイベントはコミュニティ（しかし他のどこかで発生した）に入るか又はそのグループ（しかし消滅していない）を去る。これはエージェントが互いの作動へより一層合わせて応答することを可能にする。一実施例で「歓迎コミュニティ」は例えばそれらにコミュニティの規則を教えるためエージェント入りに応答することができる。
【００４５】
エージェントレベルイベントは任意のエージェント演算子と関連する。例えば一つの可能な注記が「＜ＮｅｗＭｅｍｂｅｒ：＞ＭｙＡｇｅｎｔ．加入」とすると、これはグループへ入るクラスのＭｙＡｇｅｎｔの任意エージェントを待ち、そして変数ＮｅｗＭｅｍｂｅｒへのその新エージェントに参照を割り当てる。これはほんの文法例であり、同じ効果は全く別の注記によって得られる。別の例は「＜ＮｅｗＢｏｒｎ：＞Ａｇｅｎｔ．ｂｏｒｎ」であり、これはコミュニティ内で新しく生成したいかなるタイプのいかなるエージェントにも応答する。コミュニティはサービスレベル態様を参照して以下により詳細に論ずる。
＜包含／再開＞
【００４６】
知的システムはしばしば層状に生成され、上位層は下位層と相互作用し、そして下位層へ重畳する。それにもかかわらず下位層は一般に作動している。限られた機能のみが重畳する一方、作動の大部分は元のままである。エージェント全体を除去しそしてそれを別のもので置換するよりも、本発明は特定ビヘビアを包含することを可能にする。包含は一つのビヘビアが別のビヘビアを停止させ、そして制御を継承することを意味する。これは一般に定義されたビヘビア規則の例外を処理するために行われる。例外の処理後、制御は再開ステートメントにより包含ビヘビアに対し再開される。
【００４７】
包含及び例外は走行時の特徴である。それらはいかなるビヘビア１０６でも使用可能である。例えばエージェントが変数「ＭｙＡｇｅｎｔ」に記憶されると、「ＭｙＡｇｅｎｔ．ＭｙＢｅｈａｖｉｏｒ．包含」により名前「ＭｙＢｅｈａｖｉｏｒ」でビヘビアを直接指定できる。再度他の文法が同一効果を達成できる。
【００４８】
ビヘビア１０６はそれ自体を含み、いかなるビヘビアによっても包含できる。一実施例で包含ビヘビアは他のいかなるビヘビア（それは非作動であるので、従ってそれ自身によってではなく）によってでも再開できる。包含を行うビヘビア１０６は再開を行うビヘビアと同一である必要はない。
【００４９】
一実施例でビヘビア１０６は全て「包含」（又はある同等の名称）と呼ばれる予め定義された特性を有する。特性はビヘビア１０６の一部であるが、それはセンサ１０４である。例えばこのようなセンサ１０４はスカラセンサ（例えば「ｉｎｔ」又は「ｉｎｔｅｇｅｒ」）である。一実施例で特性はセンサが包含される回数をカウントする。もしビヘビアが包含されないならば、その包含特性はゼロとなる。ビヘビアが包含リクエストを受ける毎に、カウンタは一つ増加する。ビヘビアが再開リクエストを受ける毎にそれはそのカウンタを減算する。ビヘビアは包含特性がゼロならば作動する。包含ビヘビアは包含により終了する。これは包含時にそれはそのトリガ条件を再評価することを意味する。これはビヘビアはそれが再起動される場合、最初にその環境を見ることを意味する。この機能はそれが不正な作動を行うことを防ぐ。
【００５０】
この技術に精通する人は、包含特性は真センサであると気付くだろう。従ってそれが変更されると、それはイベントを発信する。包含状態はトリガ条件で使用される。「ｃｏｍｐｌｅｔｅＷｈｅｎ」ステートメント（以下で述べる）と組み合わせて、これはまたビヘビア１０６がそれ自身の包含ステータスを監視することを可能にする。この構造を使用してビヘビア１０６はそれが包含される少し前にコードを実行でき、ビヘビアはその本体の中間で中断されるので障害を起こさないことを保証する。
【００５１】
上に述べた特性は走行時の特徴であるので、それらはまたその一つだけが参照を有するエージェントにも利用できる。従ってこれらの特徴は「任意の」演算子を持った他のビヘビアを選択するビヘビア本体で呼び出される。
【００５２】
包含及び再開の特徴は文法キーワードとして記述してきた。しかしこれらの特徴はまたエージェントで利用可能な初期値による方法として提供される。例えばエージェン「ｓｈｏｐＡｇｅｎｔ」に対し、もしその「ｂｕｙＢｅｈａｖｉｏｒ」を包含したい場合、もし機能がエージェントのメソッドとして実行された場合は、「ｓｈｏｐＡｇｅｎｔ．ｓｕｂｓｕｍｅ（「ｂｕｙＢｅｈａｖｉｏｒ」）」と書くことができる。もし包含はキーワードであったのであれば、同じことが「ｓｕｂｓｕｍｅ  ｓｈｏｐＡｇｅｎｔ．ｂｕｙＢｅｈａｖｉｏｒ」のラインに沿って書かれたであろう。そのようなことで書き方がどうであれ、概念は同じである。
＜継承＞
【００５３】
オブジェクト指向の主な特徴の一つは派生タイプを生成する能力である。オブジェクトの機能は機能の全てを継承し、そして必要に応じ機能を重畳することにより改良される。本発明はエージェントについても同様のことを行うために利用される。エージェントが改良される場合、オブジェクトについてと全く同じことができる。メソッドは改良するため重畳することができる。
【００５４】
一実施例で、それらが起動される場合それら自身を決定するため、ビヘビアは他コードにより呼び出すことはできない。そのようなことでビヘビアはパラメータを持たない。ビヘビアが重畳される場合、それらは新しいビヘビアにより直ちに置換される。
【００５５】
センサは変数タイプである。従って通常範囲の規則が適用される。これはセンサが同一名のセンサと置換されることを意味する。
【００５６】
より重要なことは、イベント機構は継承時そのままである。エージェントはビヘビアを継承する場合、このビヘビアのトリガ条件は、それがチャイルドエージェントのビヘビアを見る必要があることを考慮するだろう。ビヘビアがチャイルドに存在しないならば、それは親エージェントのこれらのビヘビアを探すだろう。任意のセンサ／ビヘビア演算子と組み合わせて、これはエージェントが比較的複雑なロジックの実行を可能にし、そこで親は子エージェントの構造またはその他の能力を明確に知ることなく機能を提供できる。図２は重畳がＲＩＤＬで受け入れられる一実施例を図解する。
＜エージェント任意演算子再訪＞
【００５７】
エージェント「任意」演算子の定義において、クラス名前を指定する。もし「任意」クラスが子を有するクラス名称を指定すれば、その子孫は全てまた「任意」演算子により考慮される。そのようなことで、エージェントの子は改良された同一クラスのエージェントである。
【００５８】
もし子エージェントの名称が任意演算子で使用されれば、次に親エージェントは任意演算子の一部にはならない。親はＣｈｉｌｄＡｇｅｎｔのクラスの一部ではない。例えばもし自動車が乗物の子エージェントであれば、いずれの乗物も自動車を含むが、しかし「任意の」自動車はどの乗物も含まない。
【００５９】
「任意」演算子は継承物である事実に気付くことはそれらを複雑な意思決定に適するようにする。例えば一つのエージェントは一つのビヘビア１０６を以下の条件で起動させる：もし何らかの船が接近し、そして近くに軍隊の船がいないならば、ビヘビアを起動させる。別の例で、もし教師がクラスルームを持たず、そして利用できるクラスルームがない場合、エージェントはビヘビアを起動させる。この技術に精通する人は、センサは変数であり、エージェントはデータタイプであるので、センサはそれ自身エージェントであることに気付くであろう。又エージェントはメソッドに対するパラメータとして通過できる。
＜ビヘビアからのイベントの分割（イベント処理構造）／トリガ条件の変更＞
【００６０】
上の章でトリガ条件を有するビヘビアを論じた。トリガ条件へ応答し、そしていずれかが特定イベントを発信し又は直接メソッドを呼び出す、言語構造を生成することもまた可能である。一態様におけるこのような構造は基本的にトリガ条件をメソッド／ビヘビアから分割する。同様にトリガ条件はｗｈｅｎ及びｉｆ部分を混ぜる。
｛サービスレベル態様｝
【００６１】
ソフトウェアの集積がかつてより激しくなり、ソフトウェアがかつてより複雑になるので、ソフトウェアが設計される方法は変化しつつある。最近サービス指向ソフトウェア技術への傾向がある。このアプローチの基本は、ソフトウェア適用はＸＭＬウエッブサービスのような基準に基づくインタフェースを有する。ソフトウェアはこのインタフェースによりサービスとしてその機能を提供する。異なるソフトウエアパッケージを統合することはサービスを単なる張り合わせることとなっている。
【００６２】
ソフトェア技術で、名前空間はオブジェクトを集めて論理集合にするために使用される。「ディスク」という名前空間は、例えばディスクとインタフェースする全てのルーティンを含む。本発明の一態様によると、名前空間はオブジェクトをまとめるのと同じような方法でエージェントをまとめるのに使用される。特にエージェントは名前空間の一部となり、名前空間をオブジェクトと共有する。換言するとこの態様では、言語はこれらが両方共同一規則に従うので、エージェントとオブジェクトを区分しない。
【００６３】
名前空間のレベルで本発明の一実施例は「サービス」を含む。言語レベルでのサービスは名前空間と同様で、その中でそれらはオブジェクトとエージェントを同様の機能でまとめる。特にそれは単一サービスを結合して達成するエージェントとオブジェクトをまとめる。色々な実施例で、新キーワードの使用により、名前空間に注記する属性の使用により、又はエージェントを含む各名前空間は全サービスであると仮定することにより表示できる。
【００６４】
名前空間はサービスであれば、それは機能を提供する。機能は定義されたインタフェースによりアクセスできる。色々な実施例で、本発明はこのインタフェースを指定する方法を提供する。
【００６５】
第一実施例でオブジェクト又はエージェントがサービスへのインタフェースであることを明確に定義する方法が含まれる。例えばこれは属性をオブジェクトまたはエージェントに提供することにより行われる。
【００６６】
別実施例でサービスの名前と同一の名前をオブジェクト又はエージェントにつける方法が含まれる。この場合、パブリック変数及びメソッドはサービスの実際のインタフェースである。このクラスのエージェント又はオブジェクトは、サービスが始まりそしてこのエージェント又はオブジェクトの一例だけがサービス毎に生成される場合、インスタンスが自動的に生成される。
＜エージェント指向データベースレベルの態様＞
【００６７】
エージェント指向データベース（ＡＯＤＢ）への一つのアプローチは各レコード（ＯＯＤＢのオブジェクト）を特別種類のエージェントと見なすことである。エージェントはセンサだけ（ビヘビアはなし）を含み、そしてこれらのエージェント上の継承は禁止される。各外部フィールド及び各計算された又は他の方法で取得されたフィールドはセンサであると考えられる。従ってデータベースはセンサのみを有するエージェントのセットである。
【００６８】
このアプローチは各レコードのフィールドに何が起こるかを監視する。フィールドが更新される毎に、更新イベント（ビヘビアのトリガ条件により使用されるタイプの）が発信される。フィールドが値を変更すれば、更新イベントは発信される。結果はデータベースの変更を監視、そしてそれに応答するビヘビアが定義される。概念的観点から、データベースは他のエージェントが応答するエージェントで一杯になる。
【００６９】
又、データベースエージェントはセンサ及びビヘビア及び他の属性を持った普通のエージェントのようである。データベースエージェントと普通のエージェントとの違いは、そのセンサがデータベースへ記憶されることである。この場合、ソフトウェア設計者は概念的には本格的エージェントで仕事をする。データベースの構造及びエージェントシステムの構造は十分適合しなければならない。このアプローチの利点は、設計者はエージェントモデルの完全な自由を有することである。コンパイラはモデルを支持するのに必要なテーブルを生成する。このアプローチを使用する場合、このエージェントは持続することを表示するため、エージェントにキーワードを注記することが望ましい。これはコンパイラが持続するかそして持続しないエージェントの間の区別を可能にする。
｛走行時レベル態様‐実行の瞬間｝
【００７０】
コンパイラ態様で述べたイベント機構の力は、コンパイラが行える最適化タイプにより示される。これらの最適化は走行時性能に影響を与える。これらは走行時の下でここで分類されるが、しかしそれらは走行時エンジンのための必要なリスト及び他の材料を発生させるため、コンパイラが作動することを要求する。
【００７１】
色々な実施例で、リアルタイムの最適化された、速度最適の実行はＲＩＤＬの特徴である。上で述べたように、トリガ条件は「ｗｈｅｎ」と「ｉｆ」部分に分割される。「ｗｈｅｎ」部分はトリガ条件の「ｉｆ」部分の評価をトリガするイベントを指定する。各イベントは以前に定義したビヘビア又はセンサ（及び更に以前定義したエージェント）にリンクし、そして各ビヘビアはそのトリガ条件においてそれらのイベントに依存するので、依存グラフはグラフのリーブのようなセンサと共に、ビヘビア間に描かれる。センサが更新又は変更される毎に、又はビヘビアが起動し又は終了する毎に、イベントはグラフにより伝播し、そして再評価される必要のあるトリガ条件のフラグをセットする。トリガ条件は評価され、そしてもしそれらが合致すれば、ビヘビアが実行されることを要求することを表示するためフラグがセットされる。
【００７２】
一実施例で、フラグ付きビヘビアを選択し、そしてそれを実行する実行スレッドのプールがある。例えば実行スレッドのプールは一端では単スレッドであり、また他端ではビヘビアと同じ数の多くのスレッドがある。実行スレッドの数はコンパイラ実行に依存するが、しかしシステムのエージェント及びビヘビアの数からとは異なる。この技術に精通する人は「フラギング」ビヘビアは多くの形をとることに気付くだろう。例えばそれはフラグとして変数セットを含み、ビヘビア（識別）がリストに追加できそして／又はビヘビア専用の実行スレッドが始動できる（同時に実行にフラグをつけ、そして開始させることと同等の）。
＜ビヘビアの自動優先順位検出＞
【００７３】
本発明の一態様によると、ヒエラルキグラフで下位であるビヘビアはより高い優先順位が与えられている。実際ヒエラルキでの下位にあることはビヘビアはハードウェア及びソフトウェアのインタフェースにより近いことを意味する。それはそれらがイベントにより近くそしてそれらはより応答性がよいことが要求されることを意味する。
【００７４】
ロボット及び機械制御における例はこれを明確にする。もしビヘビアが直接ハードウェアセンサへ結合されていれば、非常に速い応答が要求されるようである。しかし最高レベルでビヘビアは既に他のＲＩＤＬセンサへ応答しているビヘビアにより構築されたセンサに応答する。換言するとグラフでより高位のビヘビアはよりぼんやりしたデータと連動する。この情報を処理することは通常下位レベルビヘビア（例えば反射対思考）より時間に敏感でない。
【００７５】
前のようにセンサ１０４又はビヘビア１０６のイベントは依存グラフにより伝播しそして再評価される必要のあるトリガ条件をリストに入れる。一実施例でトリガ条件処理器はこのリストを処理する。例えばリストは優先順位に基づき、これは新ビヘビアトリガ条件がリストに加えられる毎に、それが全ての待機ビヘビアの最高優先順位を有するや否や、それが実行されるように、それは実行キューへ分類される。優先順位はリーブの距離を反映し、ここでリーブは最高の優先順位を有し、そして各付加依存は優先順位を下げる。
【００７６】
比較的小規模システムではトリガ条件を即座に評価することは可能である。この場合、トリガ条件の評価は即時と仮定すると、他のビヘビアは待っていないので、各ビヘビアは自動的に最高の優先順位を有する。
【００７７】
トリガ条件が合えば、対応するビヘビアは、実行すべきビヘビアを含む新リストに記憶される。再度このリストはビヘビア（上と同じ優先順位定義の）優先順位により分類される。スレッドのプールは次に最高優先順位の待機ビヘビアを実行する。
【００７８】
最終結果として下位レベルビヘビアは、それらに依存する上位レベルビヘビアが実行機会を得る前に、多数回実行することである。これは上位レベルビヘビアが、フレームがそれが評価されれば真であったであろうトリガ条件として定義される「フレーム」を失うことを意味する。この特徴は、そこでは速い応答が要求される下位レベルでそれは速い応答を保証することに利点がある。同時にそれはエージェントの作動を支配する不確定原理に適合する。エージェントはそれが真であると信じられることは実際（尚）真であることは決して確かではない。そのようなことでエージェントはその仮定が尚保持されているかチェックを続けることを要求される。この不確定原理の最終結果は多エージェントシステムは、それらは異常処理をするため地面から構築されるので遥かに頑丈であることである。
【００７９】
ビヘビア１０６はしばしば多くのイベントを待つ。この場合ビヘビア１０６はそれを実行させたイベントより下位の優先順位を常に有する。従ってビヘビアの優先順位は走行時動的に変化する。
【００８０】
センサ１０４のイベントはセンサを更新し、イベントを起こしたビヘビア１０６より下位の優先順位を有する。センサ１０４がビヘビア１０６の外から更新される場合は、それはリーブビヘビアと見なされ、最高の優先順位を有する。
【００８１】
タイマのようなシステムで定義されたイベントでトリガされるビヘビア１０６はリーブビヘビアと考えられ、そして最高優先順位を有する。
【００８２】
他の色々な実施例で全ビヘビアで保持すべき、そして割り当てられる優先順位に影響する付加規則がある。例えば別ビヘビアの終了に基づき起動されるビヘビア１０６はその他のビヘビアより常に下位優先順位である。別の例で、別ビヘビアの起動に基づき起動されるビヘビアはその他ビヘビアと同じ優先順位を有する。
＜徹底ビヘビア＞
【００８３】
色々な例で上のヒエラルキ構成は意図しない優先順位の結果となる。特にソフトウェアの中に二つの依存グラフがある。例えばグラフの一つはデータを実行することに関与する。もう一つのグラフはもう一つのグラフの作動を監視する。このようなグラフは同一センサから始動し、そして上位レベルでは相互作用を起こさないので、コンパイラは一つのグラフ又は別のグラフへ上位優先順位を割り当てることができない。代わりにコンパイラは両方に似た優先順位を割り当て、走行時それらをリソースに対し競わせる。
【００８４】
この問題に対する一つのアプローチはユーザがビヘビアの優先順位を明確に定義することを可能にすることである。しかしこのアプローチはエラーを起こしやすい。従って本発明の色々な実施例は「徹底」表示を含む。例えばビヘビアが「徹底」とマークされる場合、これはビヘビアがいかなるフレームも見逃すことを許されないことを意味する。例えばビヘビアは次回そのトリガ条件が真になる前に、それが実行されることを保証するために十分な優先順位を持って応答する。色々な実施例で、徹底はビヘビアがある時間枠内で実行されることの保証をもたらさないかもしれないが、しかしそれはトリガ条件が真になる毎にそれが実行され、そして前の実行が終了した後に、次の実行が起こることを保証する。
【００８５】
更に徹底ビヘビアはそれ自身のイベントに関し徹底である。そのようなことでその徹底性は依存リストの他のビヘビアへは影響しない。換言すれば、それが待機する別ビヘビアはまた徹底になるか、又は他の方法で優先順位を変更するのはビヘビアが徹底であるからではない。そのようなことで徹底と明確にマークされたビヘビアだけが、いかなるフレームも決して失わない。勿論別ビヘビアが徹底ビヘビアだけに依存すれば、それが待機する多くのイベントが発生するので、それは通常ビヘビアより頻繁にトリガされる。
＜冗長ビヘビア＞
【００８６】
冗長ビヘビアは徹底ビヘビアの反対である。ビヘビアが冗長とマークされる場合、これはそれが全ての通常ビヘビアより下位優先順位を有することを意味する。徹底ビヘビアのように冗長ビヘビアはいかなる方法でも他のビヘビアの優先順位を変更させない。例えば冗長ビヘビアと明確にマークされたビヘビアだけがこの下位優先順位を有する。勿論、別ビヘビアが冗長ビヘビアのみに依存するならば、それが待っているイベントは発生しないので、それは冗長ビヘビアより、より頻繁にはトリガされないだろう。
＜実時間で描かれたヒエラルキグラフ＞
【００８７】
実時間システムの支持において、ビヘビアは特定数字の優先順位レベルへ明確に描かれることを可能にする。例えば開発者はこれらのビヘビアを取り付け、そして数字の優先順位レベルが定義される各ビヘビアに対し、上で定義した規則が適用される。
＜ｃｏｎｔｉｎｕｅＷｈｅｎステートメント＞
【００８８】
「ｃｏｎｔｉｎｕｅＷｈｅｎ」ステートメントはトリガ条件が続くステートメントである。それはビヘビアの本体のいずれかの点で使用できるステートメントである。例えばそれはビヘビアが特定のトリガ条件が真になるまで待つように指示を出す。このようなステートメントはもしビヘビアが順の一連作動を実行する必要があれば、特に有益である。それはビヘビア間の同期を保証するため基本構築を提供する。一例の状況は、それがある高さ（センサ）に到達するまでロボットはその腕（作動）を上げる必要がある場合である。次にそれがそのように成功裏に実施した後に、それはボタンを押す必要がある。
【００８９】
ｃｏｎｔｉｎｕｅＷｈｅｎステートメントは状態機を使用してまた実行される機能に関する省略注記である。例えばｃｏｎｔｉｎｕｅＷｈｅｎステートメントを含むビヘビアは同一効果を有するため特定のトリガ条件と組み合わせて状態機を使用するいくつかのビヘビアへ分割できる。一実施例で最初に状態機はその状態が０であり、そしてビヘビアのトリガ条件と共に状態０を持つ。ビヘビアの第一部分の終了時、それは状態機を状態１にする。ｃｏｎｔｉｎｕｅＷｈｅｎ後の部分を作る第二ビヘビアは、ｃｏｎｔｉｎｕｅＷｈｅｎで特定されたトリガ条件と共に状態１を待つ。状態機の最後のビヘビアが起動される場合、状態は０へ戻される。
【００９０】
一態様でコンパイラは示すように例えば以下のコードによりこの変換をソフトウェアへ適用する。
【００９１】
ｖｏｉｄＭｙＢｅｈａｖｉｏｒ（）：ｂｉｈａｖｉｏｒ
ｗｈｅｎ  ＴｒｉｇＣｏｎｄＷｈｅｎ
ｉｆ  ＴｒｉｇＣｏｎｄＩｆ
｛
Ｓｔａｔｅｍｅｎｔ1；
Ｓｔａｔｅｍｅｎｔ2；
ｃｏｎｔｉｎｕｅＷｈｅｎＴｒｉｇＣｏｎｄＣｏｎｔｉｎｕｅＷｈｅｎ1
ｉｆ  ＴｒｉｇＣｏｎｄＣｏｎｔｉｎｕｅＩｆ1；
Ｓｔａｔｅｍｅｎｔ3；
ｃｏｎｔｉｎｕｅＷｈｅｎＴｒｉｇＣｏｎｄＣｏｎｔｉｎｕｅＷｈｅｎ２
ｉｆ  ＴｒｉｇＣｏｎｄＣｏｎｔｉｎｕｅＩｆ2
Ｓｔａｔｅｍｅｎｔ4
｝
【００９２】
これは以下のように変換される。
【００９３】
ｉｎｔＭｙＢｅｈａｖｉｏｒＳｔａｔｅ＝0；
【００９４】
ｖｏｉｄＭｙＢｅｈａｖｉｏｒＰａｒｔ0（）：ｂｅｈａｖｉｏｒ
ｗｈｅｎＭｙＢｅｈａｖｉｏｒＳｔａｔｅ．ｃｈａｎｇｅｓ  ｏｒ  ＴｒｉｇＣｏｎｄＷｈｅｎ
ｉｆ（ＭｙＢｅｈａｖｉｏｒＳｔａｔｅ＝0）  ａｎｄ  ＴｒｉｇＣｏｎｄ
｛
Ｓｔａｔｅｍｅｎｔ1；
Ｓｔａｔｅｍｅｎｔ2；
ＭｙＢｅｈａｖｉｏｒＳｔａｔｅ＝1；
｝
【００９５】
ｖｏｉｄＭｙＢｅｈａｖｉｏｒＰａｒｔ1（）：ｂｅｈａｖｉｏｒ
ｗｈｅｎＭｙＢｅｈａｖｉｏｒＳｔａｔｅ．ｃｈａｎｇｅｓ  ｏｒ  ＴｒｉｇＣｏｎｄＣｏｎｔｉｎｕｅＷｈｅｎ1
ｉｆ（ＭｙＢｅｈａｖｉｏｒＳｔａｔｅ＝1）  ａｎｄ  ＴｒｉｇＣｏｎｄＣｏｎｔｉｎｕｅＩｆ1）
｛
Ｓｔａｔｅｍｅｎｔ3；
ＭｙＢｅｈａｖｉｏｒＳｔａｔｅ＝2；
｝
【００９６】
ｖｏｉｄＭｙＢｅｈａｖｉｏｒＰａｒｔ２（）：ｂｅｈａｖｉｏｒ
ｗｈｅｎ  ＭｙＢｅｈａｖｉｏｒＳｔａｔｅ.ｃｈａｎｇｅｓ  ｏｒ  ＴｒｉｇＣｏｎｄＣｏｎｔｉｎｕｅＷｈｅｎ2
ｉｆ（ＭｙＢｅｈａｖｉｏｒＳｔａｔｅ＝2）  ａｎｄ  ＴｒｉｇＣｏｎｄＣｏｎｔｉｎｕｅＩｆ2
｛
Ｓｔａｔｅｍｅｎｔ4；
ＭｙＢｅｈａｖｉｏｒＳｔａｔｅ＝0；
｝
【００９７】
結果は、ビヘビアはトリガ条件及びその指標に対し実行されるメソッドを含む。
【００９８】
一実施例でコンパイラはｃｏｎｔｉｎｕｅＷｈｅｎビヘビアを多くのビヘビアへ変換し，そして変数は両ビヘビアからアクセスされ，他のどこ（それらは概念的にローカルであるから）からもアクセスされない。例えばエージェントの他のどこでも参照されないユニークな名前で、エージェント内でグローバルな変数を生成することにより、それはこれを達成する。
＜ｃｏｍｐｌｅｔｅＷｈｅｎステートメント＞
【００９９】
上に述べた実施例で、ｃｏｎｔｉｎｕｅＷｈｅｎステートメントはビヘビア本体内で使用される。しかしｗｈｅｎ及びｃｏｍｐｌｅｔｅＷｈｅｎステートメントは両方共ビヘビア本体の外で使用される。そのようなことで「ｗｈｅｎ」条件は本体が実行される時を表示する。「ｃｏｍｐｌｅｔｅＷｈｅｎ」ステートメントは「ｗｈｅｎ」ステートメントの逆である。それはビヘビアが実行を停止すべきトリガ条件を特定する。ｃｏｍｐｌｅｔｅＷｈｅｎは再度本体がそれに続く。一実施例でｃｏｍｐｌｅｔｅＷｈｅｎがトリガされる場合、ビヘビア本体は停止し、そしてｃｏｍｐｌｅｔｅＷｈｅｎの後で本体が実行される。ｃｏｍｐｌｅｔｅＷｈｅｎ本体内でビヘビア本体で定義されるローカル変数は全てアクセスできる。概念上コードは本体内にあり、そして実行されるべく残存する全てを置換する。
【０１００】
ｃｏｍｐｌｅｔｅＷｈｅｎステートメントはビヘビア本体を変換することにより達成される。例えば以下のビヘビアを仮定する：
【０１０１】
ｖｏｉｄＭｙＢｅｈａｖｉｏｒ（）：ｂｅｈａｖｉｏｒ
ｗｈｅｎ  ＴｒｉｇＣｏｎｄＷｈｅｎ
ｉｆ  ＴｒｉｇＣｏｎｄＩｆ
｛
Ｓｔａｔｅｍｅｎｔ1；
Ｓｔａｔｅｍｅｎｔ2；
Ｓｔａｔｅｍｅｎｔ3；
｝
ｃｏｍｐｌｅｔｅＷｈｅｎＴｒｉｇＣｏｎｄＣｏｍｐｌｅｔｅＷｈｅｎ
ｉｆ  ＴｒｉｇＣｏｎｄＣｏｍｐｌｅｔｅＩｆ
｛  
ＣＳｔａｔｅｍｅｎｔ1；
ＣＳｔａｔｅｍｅｎｔ2；
｝
【０１０２】
これは同じ効果の以下のコードに変換できる：
【０１０３】
ｂｏｏｌＭｙＢｅｈａｖｉｏｒＣｏｍｐｌｅｔｅＮｏｗ＝ｆａｌｓｅ：
【０１０４】
ｖｏｉｄＭｙＢｅｈａｖｉｏｒＭｕｓｔＣｏｍｐｌｅｔｅ（）：ｅｘｈａｕｓｔｉｖｅ  ｂｅｈａｖｉｏｒ／／＆  ｈｉｇｈｅｓｔ  ｐｒｉｏｒｉｔｙ
ｗｈｅｎＴｒｉｇＣｏｎｄＣｏｍｐｌｅｔｅＷｈｅｎ
ｉｆ  ＴｒｉｇＣｏｎｄＣｏｍｐｌｅｔｅＩｆ
｛
ＭｙＢｅｈａｖｉｏｒＣｏｍｐｌｅｔｅＮｏｗ＝ｔｒｕｅ；
｝
【０１０５】
ｖｏｉｄＭｙＢｅｈａｖｉｏｒ（）：ｂｅｈａｖｉｏｒ
ｗｈｅｎ  ＴｒｉｇＣｏｎｄＷｈｅｎ
ｉｆ  ＴｒｉｇＣｏｎｄＩｆ
｛
ｉｆ  ｎｏｔ  ＭｙＢｅｈａｖｉｏｒＭｕｓｔＣｏｍｐｌｅｔｅ
｛
Ｓｔａｔｅｍｅｎｔ1；
ｉｆ  ｎｏｔ  ＭｙＢｅｈａｖｉｏｒＭｕｓｔＣｏｍｐｌｅｔｅ
｛
Ｓｔａｔｅｍｅｎｔ2；
ｉｆ  ｎｏｔ  ＭｙＢｅｈａｖｉｏｒＭｕｓｔＣｏｍｐｌｅｔｅ
｛
Ｓｔａｔｅｍｅｎｔ3；
｝
｝
｝
ｉｆ  ＭｙＢｅｈａｖｉｏｒＭｕｓｔＣｏｍｐｌｅｔｅ
｛
ＣＳｔａｔｅｍｅｎｔ1；
ＣＳｔａｔｅｍｅｎｔ2；
｝
｝
【０１０６】
色々な実施例で終了条件のチェックは最高の優先順位を持たねばならない。何故ならばビヘビアの優先順位がいかに高くても，それに関係なくそれが終了しなければならない事実は一層より高い優先順位を有するからである。一実施例で、徹底キーワードはこの例で使用され、何故ならば終了条件のチェックはイベントをトリガするものはどれも更新しない。例えばそれは変数を更新し、センサを更新しない。そのようなことで、コンパイラは第一コードを後者へ変換し、これにより機能を実行する。又他の手段は要求される機能を実行するために使用される。
【０１０７】
いかなる方法が選択されても、コンパイラはｃｏｍｐｌｅｔｅＷｈｅｎステートメントを持ったビヘビアをこのようなステートメントを持たないビヘビアへ変換することができる。そのようなことでそれは単なる非常に有益な強力な省略注記である。ステートメントの使用は、特に次の例で示すように各ビヘビアのシステム定義の包含センサと組み合わせて非常に頻繁である：
【０１０８】
ｖｏｉｄＭｙＢｅｈａｖｉｏｒ（）：ｂｅｈａｖｉｏｒ
ｗｈｅｎ  ＯｔｈｅｒＳｅｎｓｏｒ1.ｃｈａｎｇｅｓ
｛
Ｓｔａｔｅｍｅｎｔ1；
Ｓｔａｔｅｍｅｎｔ2；
｝
ｃｏｍｐｌｅｔｅＷｈｅｎＭｙＢｅｈａｖｉｏｒ.ｓｕｂｓｕｍｅｄ.ｃｈａｎｇｅｓ
ｉｆ  ＭｙＢｅｈａｖｉｏｒ.ｓｕｂｓｕｍｅｄ
｛
Ｃｌｅａｎ＿ｕｐ＿ｂｅｈａｖｉｏｒ；
｝
【０１０９】
事実このステートメントの使用は非常に頻繁なため、色々なイベントを捕捉し、色々な作動をするため、ビヘビアの終わりで多くのｃｏｍｐｌｅｔｅＷｈｅｎを使用することを可能にする。例えば、もし多くのイベントに同一作動をとらせたいならば、トリガ条件をより精巧なものにすればよい。
【０１１０】
変換の後、一実施例ではコンパイラは多くのｃｏｍｐｌｅｔｅＷｈｅｎステートメントを実行するためイフ・ステートメントを使用するコードを発生させる。入れ子イフ・ステートメントを持った例で：
【０１１１】
ｖｏｉｄＭｙＢｅｈａｖｉｏｒ（）：ｂｅｈａｖｉｏｒ
ｗｈｅｎ  ＴｒｉｇＣｏｎｄＷｈｅｎ
ｉｆ  ＴｒｉｇＣｏｎｄＩｆ
｛
Ｓｔａｔｅｍｅｎｔ1；
Ｓｔａｔｅｍｅｎｔ2；
Ｓｔａｔｅｍｅｎｔ3；
｝
ｃｏｍｐｌｅｔｅＷｈｅｎＴｒｉｇＣｏｎｄＣｏｍｐｌｅｔｅＷｈｅｎ1
ｉｆ  ＴｒｉｇＣｏｎｄＣｏｍｐｌｅｔｅＩｆ1
｛
Ｃ１Ｓｔａｔｅｍｅｎｔ1；
Ｃ１Ｓｔａｔｅｍｅｎｔ2；
｝
ｃｏｍｐｌｅｔｅＷｈｅｎＴｒｉｇＣｏｎｄＣｏｍｐｌｅｔｅＷｈｅｎ2
ｉｆ  ＴｒｉｇＣｏｎｄＣｏｍｐｌｅｔｅＩｆ2
｛
Ｃ２Ｓｔａｔｅｍｅｎｔ1；
Ｃ２Ｓｔａｔｅｍｅｎｔ2；
｝
【０１１２】
これは同一効果の以下のコードへ変換される：
【０１１３】
ｉｎｔＭｙＢｅｈａｖｉｏｒＣｏｍｐｌｅｔｅＮｏｗ＝0；
【０１１４】
ｖｏｉｄＭｙＢｅｈａｖｉｏｒＭｕｓｔＣｏｍｐｌｅｔｅ1（）：ｅｘｈａｕｓｔｉｖｅ  ｂｅｈａｖｉｏｒ（＆  ｈｉｇｈｅｓｔ  ｐｒｉｏｒｉｔｙ）
ｗｈｅｎ  ＴｒｉｇＣｏｎｄＣｏｍｐｌｅｔｅＷｈｅｎ１
ｉｆ  ＴｒｉｇＣｏｎｄＣｏｍｐｌｅｔｅＩｆ1
｛
ＭｙＢｅｈａｖｉｏｒＣｏｍｐｌｅｔｅＮｏｗ＝0；
｝
【０１１５】
ｖｏｉｄＭｙＢｅｈａｖｉｏｒＭｕｓｔＣｏｍｐｌｅｔｅ1（）：ｅｘｈａｕｓｔｉｖｅ  ｂｅｈａｖｉｏｒ（＆  ｈｉｇｈｅｓｔ  ｐｒｉｏｒｉｔｙ）
ｗｈｅｎＴｒｉｇＣｏｎｄＣｏｍｐｌｅｔｅＷｈｅｎ2
ｉｆ  ＴｒｉｇＣｏｎｄＣｏｍｐｌｅｔｅＩｆ2
｛
ＭｙＢｅｈａｖｉｏｒＣｏｍｐｌｅｔｅＮｏｗ＝2；
｝
ｖｏｉｄＭｙＢｅｈａｖｉｏｒ（）：ｂｅｈａｖｉｏｒ
ｗｈｅｎ  ＴｒｉｇＣｏｎｄＷｈｅｎ
ｉｆ  ＴｒｉｇＣｏｎｄＩｆ
｛
ｉｆ  ｎｏｔ  ＭｙＢｅｈａｖｉｏｒＭｕｓｔＣｏｍｐｌｅｔｅ
｛
Ｓｔａｔｅｍｅｎｔ1；
ｉｆ  ｎｏｔ  ＭｙＢｅｈａｖｉｏｒＭｕｓｔＣｏｍｐｌｅｔｅ
｛
Ｓｔａｔｅｍｅｎｔ2；
ｉｆ  ｎｏｔ  ＭｙＢｅｈａｖｉｏｒＭｕｓｔＣｏｍｐｌｅｔｅ
｛
Ｓｔａｔｅｍｅｎｔ3；
｝
｝
｝
ｉｆ  ＭｙＢｅｈａｖｉｏｒＭｕｓｔＣｏｍｐｌｅｔｅ＝1
｛
Ｃ1Ｓｔａｔｅｍｅｎｔ1；
Ｃ1Ｓｔａｔｅｍｅｎｔ2；
｝
ｉｆ  ＭｙＢｅｈａｖｉｏｒＭｕｓｔＣｏｍｐｌｅｔｅ＝2
｛
Ｃ2Ｓｔａｔｅｍｅｎｔ1；
Ｃ2Ｓｔａｔｅｍｅｎｔ2；
｝
｝
【０１１６】
再度同様の効果は、入れ子イフ・ステートメントを使用する代わりにイベントを発信することにより得られる。コンパイラもまた実行される必要のある多くのテストを削減するため、より知的にチェックするように作動する。
【０１１７】
この技術に精通する人は、包含もまた同じように作動することに気付くだろう。「イフ」ステートメントの使用により、又はイベントを発信することにより、包含される方法は、スレッド（後者はより多くのオーバーヘッド処理とより複雑性を生じさせる）は実際に消滅することなく直ちに終了する。上の変換はｃｏｎｔｉｎｕｅＷｈｅｎ及びｃｏｍｐｌｅｔｅＷｈｅｎステートメントのないビヘビアについて上で論じた走行時レベルの実行もまたこれらのステートメントを持ったビヘビアへ適用される。
＜デッドロック検出＞
｛走行時レベル態様‐エージェントの可動性｝
＜コミュニティ＞
上の記述は全て互いに気付くエージェントに焦点を当てた。しかし一実施例でエージェントは「コミュニティ」に存在するエージェントに気付くだけである。例えばコミュニティはアプリケーションと同じである。そのようなことでアプリケーション内のエージェントは全て互いに気付く。この技術に精通する人は、多くのコミュニティを含むアプリケーションはしばしば一般に多くのアプリケーションであると考えられる。
【０１１８】
一実施例でコミュニティ自身は移動できる。即ちサービスはそれ自身を別のコンピュータへコピーでき、そして遠隔からそれ自身を始動させることができる。その結果コミュニティは他のコンピュータ上でそれ自身を作動にする。更にこのような実施例でエージェントは複製コミュニティ間で移動する。特にエージェントはそのステータスを含む他のコミュニティへ送信されるメッセージを発生させる。例えばこのようなメッセージはエージェントタイプとそのセンサの全ての値を含む。一つの実施はエージェントのセンサをＸＭＬへ「デハイドレート」することであり、そしてこのＸＭＬ定義を複製コミュニティへ伝送する。ここで新エージェントが生成され、そしてエージェントの全センサはＸＭＬメッセージ（「ハイドレート」）で受ける値に設定される。新エージェントは次に確認メッセージを第一エージェントへ返信し、これは次にそれ自身を破棄することを選択する。またもしエージェントがそれ自身を破棄しなければ、それは単純にそれ自身を複製する。
【０１１９】
一実施例でエージェントがいつでも、そしてコミュニティ内で何かの理由で新しく生成される場合は（例えば又データタイプに作用する新演算子により）、全ビヘビアのトリガ条件が評価される。その結果により、ビヘビアは起動するか又は起動しない。コミュニティで起動したビヘビア及びそのエージェントの新コミュニティへの移動を生み出すビヘビアはそのトリガ条件が新コミュニティに適合しないため、新コミュニティ内では直ちに起動しない。
＜格子計算＞
【０１２０】
それら自身のコピーを（他のプロセッサ及び機械上に）生み出すコミュニティ能力はそれらがネットワーク内で利用できる全ての認定された処理能力を利用することを可能にする。そのようなことで格子計算の多エージェント翻訳が可能となる。例えば使用を認定された身近のコンピュータは全て多エージェントシステムを実行する計算格子を自動的、動的に生成する。従って多エージェントシステムは、例えばゲーム、物理計算、大規模銀行業務計算及び他の大規模用途のような用途向け単一コンピュータの能力を越えて成長する。
＜類似コミュニティ間の移動＞
【０１２１】
コミュニティは、全エージェントの定義が同一であれば、構造的に同一であり、そしていずれのコミュニティも他に関して付加エージェントを持たない。センサの署名はそのタイプと共にセンサの名前である。そのようなことでエージェントＡは、もしそれが同一名を持ち、そしてエージェントＡの全センサがエージェントＢで同一署名のセンサを持つならば、エージェントＢに類似と見なされる。更にコミュニティＣ１は、もしＣ１のエージェントのいくつかがＣ２のエージェントに類似であるならば、コミュニティＣ２に類似なものである。しかしＣ１の全てのエージェントがＣ２のエージェントに類似である必要はない。
【０１２２】
一実施例でエージェントは類似コミュニティ間で移動できる。特にエージェントは、他のコミュニティへ伝送され、そしてそのステータスを含むメッセージを発生させる。例えばそのステータスはエージェントの名前及びエージェントの各センサに対し、センサの署名及びその値で構成される。この情報はデータパッケージ（例えばＸＭＬ定義で）に集合され、そして複製リクエストで他コミュニティへ伝送される。受け入れコミュニティでは、エージェントの特定名が検索される。エージェントが類似かどうかを決定するチェックが行われる。エージェントが類似でなければ、その意味のメッセージが返送され、更なる作動は行われない。エージェントが類似であれば、正の確認が送信コミュニティへ返送され、そして新エージェント例が受け入れコミュニティに生成される。センサに対する受け入れ値は全てエージェントへ割り当てられる。エージェントの生成及びセンサの更新は受け入れコミュニティにより多くのイベントを伝送する。
＜エージェントの移動開始方法＞
【０１２３】
各コミュニティはサービスであり又はインタフェースを有する。例えばインタフェースはＡＣＬ（エージェント通信言語）メッセージ又はＸＭＬメッセージのようなメッセージを受け入れる。一実施例でＲＩＤＬはコミュニティ間の通信を確立するため、ＸＭＬウエブサービスを利用する。各コミュニティは通常ＵＲＬにより表示されるユニークなＩＤを有する。
【０１２４】
移動させたリエージェントはそれが移動するコミュニティのＩＤを知る必要がある。一実施例で二つの特別機能が各エージェントの予め定義された方法である：「ｉｎｔｃｏｐｙＴｏＣｏｍｍｕｎｉｔｙ（ＩＤ）」ここでは特定ＩＤをもったコミュニティは上で述べた複製をリクエストするデータパッケージを伝送され、そして機能の返送コードは成功（０＝コピー成功）の表示を含む；そして「ｉｎｔｍｉｇｒａｔｅＴｏＣｏｍｍｕｎｉｔｙ（ＩＤ）」ここではｃｏｐｙＴｏＣｏｍｍｕｎｉｔｙが最初に実行され、そして成功時コピーされたエージェントは消滅する。もしエージェントがそれ自身を移動させるならば、移動命令後の行を実行しないかも知れない。移動が成功でなければ、次の行は実行され、エージェントによる返送値に基づく診断を可能にする。再度実行文法が変化する。
【０１２５】
一実施例で開発者は類似コミュニティのＩＤを知ることだけ必要であり、そして通信プロトコル、ウエブサービス、ＡＣＬ又は他のいかなる技術も知る必要はない。そのようなことで、エージェントが生成する場合は、いつもそれは開発者の作業の必要なく、類似コミュニティ間でのコピー及び移動する能力を有する。一実施例でこの機能は各エージェントで利用できる方法に含まれる。またこの機能は、機能「ｉｎｔｃｏｐｙＴｏＣｏｍｍｕｎｉｔｙ（エージェントタイプＩＤ）」及び「ｉｎｔｍｉｇｒａｔｅＴｏＣｏｍｍｕｎｉｔｙ（エージェントタイプＩＤ）」を含むライブラリにより提供される。
【０１２６】
そのようなことで移動はエージェント毎の予め定義された方法において又は言語と共に提供されるライブラリにおいて言語に固有のものである。コミュニティが始動する方法を変更することにより、開発者は「一次」及び「二次」コミュニティを生成するため同一ソースコードを全く容易に使用でき、ここで一次コミュニティはある種のブートストラップにそれら自身のエージェントを生成し、そして二次コミュニティは一次コミュニティに類似であるが、エージェントを含まずそれらにコピー又はそれらへ移動するエージェントの受け入れを待つネットワーク上の遠隔端末機上にインストールされる。一実施例で一次コミュニティは、いずれも構築者の分析及び初期エージェントを生成するステートメントを除去することにより自動的に、二次コミュニティへ変更できる。一適用例でゲーム開発者は、付加コードを書き込む必要なくそれらのＰＣの能力を利用するため、ＬＡＮ内のＰＣ上にインストールされる。
＜類似エージェンを持ったコミュニティの検索＞
【０１２７】
一実施例でエージェントは、ＡＣＬ及びＸＭＬウエブサービスの定義内に既に存在するインフラ構造を使用することにより、移動させたいコミュニティのＩＤを得る。更にエージェントはコンピュータ上又はネットワーク上又は類似エージェントを含むコミュニティに対して利用可能なコミュニティを全て検索する。一般にもしそれらの外にコミュニティがあればエージェントが関係する場合、それはどのタイプのエージェントと話をしたいかを知ると想定される。例えば特定エージェントを含む付近の全コミュニティを検索するクエリが提供される。特定エージェントはそれ自身のエージェントか又はそれは別エージェントである。検索は構造上同一エージェントについては勿論のこと、類似エージェントに対しても行われる。又いくつの例の特定エージェント署名のエージェントがコミュニティに存在するかを決定するためのクエリが提供される。
【０１２８】
一実施例で設計者がその背後のプロトコルについて何も知る必要なくこのような機能が使用できることが望ましい。例えば各エージェントは以下の様式の予め定義された方法を含む：
ｃｏｍｍｕｎｉｔｙＣｏｌｌｅｃｔｉｏｎ  ｆｉｎｄＣｏｍｍｕｎｉｔｉｅｓ（ＳｔｒｕｃｔｕｒａｌＩｄｅｎｔｉｃａｌ：ｂｏｏｌ＝ｆａｌｓｅ）
【０１２９】
ここでｃｏｍｍｕｎｉｔｙＣｏｌｌｅｃｔｉｏｎタイプはｃｏｍｍｕｎｉｔｙＣｏｌｌｅｃｔｉｏｎＩｔｅｍの集合であり、そしてｃｏｍｍｕｎｉｔｙＣｏｌｌｅｃｔｉｏｎＩｔｅｍは二つの部分を持った構造である。：即ち集合のＩＤ及び既に存在するエージェントの多くの例である。パラメータ「Ｓｔｒｕｃｔｕａｌ  Ｉｄｅｎｔｉｃａｌ」は構造同一エージェント（真）又は類似エージェント（偽）のいずれの検索かを表示し、ここでデホルト値は類似エージェントの検索である。再度この機能もまた言語で提供されるライブラリの一部であり、ここで以下のような機能が利用できる：
ｃｏｍｍｕｎｉｔｙＣｏｌｌｅｃｔｉｏｎ  ｆｉｎｄＣｏｍｍｕｎｉｔｉｅｓ（エージェントタイプ：エージェント；Ｓｔｒｕｃｔｕｒａｌ  Ｉｄｅｎｔｉｃａｌ：ｂｏｏｌ＝ｆａｌｓｅ）
【０１３０】
この技術に精通する人は、同一機能は色々な方法で文法を変更することにより得られることに気付くだろう。
＜コミュニティを越えて作動するエージェント＞
【０１３１】
一実施例でエージェントは特殊なタイプのより少ないエージェントを持った又はより維持ＣＰＵ能力を持ったコミュニティへ自動的に移動する。しかし「いかなる」演算子もコミュニティに依存し、そして他のコミュニティのエージェントを取り出さない。例えば多ユーザのビデオゲームで、ユーザは１，０００人の軍隊を有し、そしてこれらの兵隊の各々は複雑な戦闘的及び精神的ビヘビアを持ったエージェントにより表示される。更に別の比較的強力なコンピュータはローカルネットワークの一部である。もしユーザがゲームでその機械を使用できれば、その力はより大きな軍隊に利用でき、そしてユーザはゲームにおいてより多くの能力を有するだろう。そのようなことで二次コミュニティは付加兵を受けるために利用できる。しかし二次コミュニティにおり、そして任意の演算子によりそれらの環境に応答する兵は、一次コミュニティにある他のエージェントをもはや見ることができない。
【０１３２】
上の色々な実施例はこの問題に対する解決策を提供する。全モデルはセンサ及びビヘビアにより生成されるイベントにより駆動される。エージェントの状態は大部分センサの値に記憶される。エージェントをコミュニティを越えて互いに応答させるため、センサを保持するスタブが必要である。そのようなことで、これらのスタブがシステムにより自動的に生成される一方、どのエージェントが他機械へ移動でき、どのエージェントができないかを決定するための自由度を維持することが望ましい。
【０１３３】
この目標を達成するため、エージェントはキーワード又は属性を持った「ａｕｔｏＭｉｇｒａｔｅ」と注記される。例えば：
【０１３４】
ｖｏｉｄＭｙＢｅｈａｖｉｏｒ（）：ａｕｔｏＭｉｇｒａｔｅ  ｂｅｈａｖｉｏｒ
【０１３５】
一実施例で全てのａｕｔｏＭｉｇｒａｔｅビヘビアに対しコンパイラもまた、全てのセンサを含み、ビヘビアは一つも含まない一次コミュニティの第二「スタブ」エージェントを生成する。このスタブエージェントは後に以下に述べる変換センサに関与する。二次コミュニティでａｕｔｏＭｉｇｒａｔｅエージェントの完全な定義は、ａｕｔｏＭｉｇｒａｔｅエージェントが依存する各エージェントに対するスタブエージェントと同様に利用できる。
【０１３６】
ａｕｔｏＭｉｇｒａｔｅエージェントが起動されると、それは通常エージェントと同様に作動しそしてエージェントの「実行リスト」はモニタされる。一実施例で実行リストは、上で自動優先順位検出の章で説明したように、実行が必要な優先順位に従い分類されるビヘビアのリストである。
【０１３７】
ビヘビアのリストが例えば値「Ｘ」より長くなれば、ＡｕｔｏＭｉｇｒａｔｅエージェントは移動のために選択され、ここで「Ｘ」は設計者により設定されたパラメータである。従ってイベントモデル及び結果の優先順位検出はプロセッサ作動の指標として利用され、ここでａｕｔｏＭｉｇｒａｔｅエージェントは十分な処理能力がある限りコンピュータ上に留まる。
【０１３８】
移動用ａｕｔｏＭｉｇｒａｔｅを選択するため、いくつかの判定基準が使用される。例えば最も少数の外部センサに依存するａｕｔｏＭｉｇｒａｔｅエージェントが選択される。この場合ａｕｔｏＭｉｇｒａｔｅエージェントが移動用に選択されたシーケンスはコンパイル時に決定される。別の選択法が常駐コンピュータの作業付加を削減するため最も頻繁に起動されるａｕｔｏＭｉｇｒａｔｅエージェントを使用することである。また別の方法は、実行リスト上で最も多くのビヘビアを有するａｕｔｏＭｉｇｒａｔｅを選択すること、又はランダムａｕｔｏＭｉｇｒａｔｅエージェント又は別の方法を選択することである。
【０１３９】
一実施例で一次コミュニティで、センサがａｕｔｏＭｉｇｒａｔｅエージェントが依存するエージェントを更新する度毎にセンサの値更新は、それがこのエージェントのためのスタブを更新する二次コミュニティへ伝送される。同様に二次コミュニティにおいて、移動エージェントのセンサが更新される度毎に、センサの関連値が一次コミュニティへ返送され、ここでそれは移動エージェントのスタブを更新する。センサは更新中のため、これは二次コミュニティに存在したイベントを再生成する。コンパイラは、スタブにより生成されたイベントは使用エージェントの観点からのオリジナルエージェントにより生成されるイベントに同じである。
【０１４０】
一実施例でコミュニティ間の情報伝達はＸＭＬパッケージを利用して達成される。例えばエージェントのイベントへ応答しそして他のコミュニティのスタブエージェントへ情報を伝送するシステム定義ビヘビアが付加される。エージェントはスタブ名を他のコミュニティ（既知ＩＤの）へ伝送するか又はユニークＩＤ（ポインタ）を直接スタブセンサへ伝送する。
【０１４１】
設計時、クラスはａｕｔｏＭｉｇｒａｔｅと指定される。しかしそれは移動する個々の例である。そのようなことで各エージェントはそれが何時移動するかそれ自身で決定する。従ってａｕｔｏＭｉｇｒａｔｅエージェントのいくつかの例が移動する一方、同一エージェントクラスの他の例は移動しない。
【０１４２】
一実施例で単一一次コミュニティに対し多くの二次コミュニティが存在する。各移動で、コミュニティは、類似エージェントを持ったコミュニティの検索の章で上に述べた方法と同様に選択されるが、しかしこの場合判定基準は構造上同一なエージェントを持ったコミュニティを検索する。
＜エージェント移動のためのセキュリティ問題＞
【０１４３】
一実施例でセキュリティ問題はＸＭＬウエブサービス（又はＡＣＬレベル）に対するセキュリティレベルで解決される。例えばサービス使用に関するセキュリティ指標は、エージェントがそれらが認定を有しないコミュニティへ移動しないように守るべきである。
｛デバッグレベル態様｝
＜デバッグビヘビア＞
【０１４４】
多エージェントシステムは、それらは非常に多くの並列ビヘビアを有するためデバックが大変困難である。走行時エラーは走行条件及び再生成の極端に困難なイベントの同時発生により発生する。副作用がシステムの同時性の再生成を不完全にするので、コードによる「ステッピング」は理解できる。伝統的デバック方法は、エージェントを越えてデバッグする場合、駄目になる。従ってエージェント設計者はエージェントは外部エラーに対し、できるだけ頑丈であることを保証すべきである。
【０１４５】
そのようなことで上で概説した特徴は、例えばメソッドやシーケンシャルコードの点よりもむしろエージェント、ビヘビア及びトリガ条件の点で判断することにより設計者のために利用される。
【０１４６】
一実施例でキーワードまたは属性はビヘビアが次のような「デバッグ」ビヘビアであると表示する。
【０１４７】
ｖｏｉｄＭｙＢｅｈａｖｉｏｒ（）：ｄｅｂｕｇ  ｂｅｈａｖｉｏｒ
ｗｈｅｎ  ＴｒｉｇＣｏｎｄＷｈｅｎ
ｉｆ  ＴｒｉｇＣｏｎｄＩｆ
｛
//ｓｔａｔｅｍｅｎｔｓ
｝
【０１４８】
そのような実施例で、デバックビヘビアは通常ビヘビアとは異なる扱いを受ける。例えばデバックビヘビアは「デバック」モードでのみコンパイルされる。「リリース」モードでこれらのビヘビアは自動的に除去される。別の例でデバックビヘビアは最高の優先順位を有する。一実施例で設計者はデバックビヘビア本体でのステートメントを最小化し、ここでそのようなビヘビアは空の本体を有し、そのためビヘビアのトリガのみがモニタされる。別実施例でデバックビヘビアはｃｏｎｔｉｎｕｅＷｈｅｎ又はｃｏｍｐｌｅｔｅＷｈｅｎステートメントを有せず、包含又は再開もされない。一般にデバックビヘビアはエージェントシステムの作動に参加しない。それは作動を単に観察（そして時には記録する）するだけである。
【０１４９】
別例でデバックモードで、各ビヘビアはシステムの「フリーズ」を可能にするためのロジックを含む。フリーズは全ビヘビアがダイナミックシステムの「スナップショット」の分析を可能にすることを停止する。別例でデバックビヘビアは「ゼロ実行時間」で走行し、ここでデバックビヘビアが起動される場合、それはシステムをフリーズし、次に本体を実行する一方、全てはフリーズしたままである。システムはデバックビヘビアが終了したとき、解凍される。これはデバックビヘビアがチェックを走らせ，そして／または走行時の特定点でそれに応じて記録を更新することを可能にする。
＜例外処理＞
【０１５０】
例外は走行時実行される不正操作を含む。そのような作動はゼロポインタ、ゼロによる割り算及び他の多くの問題の使用を含む。それらの問題はトリガ条件評価において及び本体実行時の両方で起こり得る。
【０１５１】
伝統的言語でビヘビアの終了時の捕捉されるエラーイベントが発信される。もしイベントが捕捉されなければ、イベントは究極的に全システムがクラッシュするまで、外に向かって伝播する。本発明によると一実施例で、予め定義されたスカラ特性「例外」はビヘビアと関連する。包含特性のように例外特性は真センサである。それが変更された場合、それはイベントを発信する。例えば設計者は、それらが発生した場合、例外を捕捉するためｃｏｍｐｌｅｔｅＷｈｅｎステートメントを使用し、そしてそれらを処理する。一実施例で、もしビヘビアがその例外を処理しなければ、ビヘビアは直ちに終了する。そのようなことで例外は伝播せず、そしてシステムは作動を続ける。
【０１５２】
例外は真センサのため、エージェントの他のいかなるビヘビアもそれに応答できる。従ってエージェントの別ビヘビアがエージェントで発生する例外処理に専念する。
＜マトリックス分析器＞
【０１５３】
一実施例で「マトリックス分析器」はそれらが実行している間、エージェントをモニタする。例えば電子機器の分析器のように、それは全ての関連パラメータの値を連続的に示し、そしてデータを色々な表示フォーマットで提示する。
【０１５４】
例えば一つの画面はデバックモード（他にマトリックス分析器はそれらを見ない）にあるコンピュータ上に見出されるコミュニティリストを示す。別画面はそのセンサ及びビヘビアの全てを持った単一エージェントを示す。例えば各センサに対し値は示される。ビヘビアに対しコードのステータスは例えば色で示す：黒はコードが現在作動していない事を意味する：緑はコードが実行中であることを意味する：橙色はコードが実行を待っていることを意味する：そして赤は実行中にコードに何か不調が生じたことを意味する。
【０１５５】
別の画面は各エージェントを単一ブロック又は点として表示し、ここで色は例えばエージェントステータスを表示する：もし実行中にエージェントコードの一部に何か不調が生じたならばエージェントは赤になる：もしエージェントが赤でなく、いずれのビヘビアも実行を待っていなければ、エージェントは橙色である。もしエージェントが赤又は橙色でなく、そしてビヘビアも作動していれば、エージェントは緑である：そして「上記のいずれでもない」条件に対し、エージェントは黒である。一実施例でこの画面はマトリックスとして表示される。例えば１６００×１２００ピクセルの画面は１９２万エージェントまでの作動を示す。更に特定ピクセルは、例えばより詳細な分析を可能にする特定エージェントの第二画面を選択することを可能にする特定エージェントの第二画面を選択することを可能にするため強調表示される。
｛ＩＤＥレベル態様｝
＜エージェント画面＞
【０１５６】
別実施例で、可視エージェントの設計者は視覚的にエージェントをモニタする役割である。そのようなことで、そのような視覚モデラには多くの画面がある。例えば一つの画面で開発者はＵＭＬに似た方法でエージェントを見る。単一表示器の代わりにオブジェクト指向（ＯＯ）モデリングにおける変数又はメソッドの前に二つの表示器があり、ここで第一のそれは、もしメソッド、ビヘビア、変数又はセンサがプライベート、パブリック又はフレンドであれば、表示するためＯＯと同様であり、そして第二表示器はそれがメソッドか又はビヘビアのいずれであるか及びそれは変数かセンサかを表示する。第二表示器はそれがエージェント概念（センサ又はビヘビア）であるか又はオブジェクト概念（変数又はメソッド）であるかを基本的に表示する。
＜ビヘビア画面＞
【０１５７】
ビヘビア画面で、センサ及びビヘビアはそれらが属するエージェントの外にあることが示される。それらはエージェント名により注記されるが、しかし同一エージェントのセンサおよびビヘビアは同じ付近に示す必要はない。むしろビヘビア及びセンサは、リーブセンサおよびビヘビアを下（ユーザの好みに応じ又は上又は左から右へ、又は右から左へ）に示し、依存に応じ広がる。一実施例で、センサ及びビヘビアは項目間の依存を示す矢印で接続される。
＜依存画面＞
【０１５８】
ＲＩＤＬの概念に基づき、依存グラフが定義される。一実施例でこのグラフは代わりの方法で視覚化できる。例えばエージェントはユーザ（エージェント画面におけるように）に示され、そして矢印は依存（この技術に精通する人は正確な優先順位は走行時変動し、そして静止した表示ができない）を示すため、エージェント間に描かれる。又エージェントはビヘビア画面に示され、そして矢印は再度依存を表示するためビヘビア及びセンサ間に描かれる。
＜コミュニティ画面＞
【０１５９】
上述のデバッグレベル態様に類似した別実施例で、コミュニティ画面は走行時のエージェントを示す。
｛学習エージェント：神経エージェント‐態様｝
【０１６０】
人工神経ネットワーク（ＡＮＮｓ）において、ニューロンは数学公式である。それらはそれらのトリガ値を表示する数を提供する。閾値はしばしばトリガ値として０又は１だけ生成するためしばしば使用される。ニューロンの公式は下位レベルの全ノードの合計としてしばしば計算される値に基づき、ここで各ノードは専用乗算値により乗算される。分離ＡＮＮｓの場合、ウエイトは０と１の間になければならない。個々ウエイトを変更することにより、そしてニューロンを層にすることにより、システムは単にティーチングにより複雑なデータ（イメージ上の対象物を識別するような）を処理することを学習できる。
【０１６１】
ＲＩＤＬにおいて神経ネットワークの概念は少しの修正で使用できる。一実施例でニューロンはエージェントにより表示される。そのトリガ値はセンサで、それはそのトリガ値を再計算するため下位層のトリガ値からのイベントに応答するビヘビアを有する。最終結果はＡＮＮｓの概念を使用して、ＲＩＤＬソフトウェアは解（従って訓練により）をプログラミングせずに、非常に複雑なタスクを学習することができる。
【０１６２】
エージェントの層を生成するため、色々な原理が利用される。例えば単一層の全エージェントを単一のクラス名の下に置くため継承が使用される。又各エージェントはそれが中にある多くの層を有し、この数は登録される条件の一つである。
【０１６３】
一態様でＲＩＤＬには「全てのため」構造がある。一般にエージェントはそのような作動の途中で生成又は消滅できるので全エージェントを訪問することができる。従ってそれが接続されるエージェントリストを保つことはエージェント自身次第である。そのようなリストは詳しく検討される。例えばリストは「任意の」演算子（例えばそれに対しそれは私のリストにないことを保持する何らかのエージェントがモニタ中の層内に存在すれば、それをリストに付加せよ）を使用して更新が保たれる。
｛自動書き込み学習エージェント：ソフトウェアの遺伝進化一態様｝
＜導入＞
【０１６４】
簡単に加えられた遺伝プログラミングは二つの原理上で作動する：突然変異は小さなランダム変化を行う：交差は両親に発生し、片親のある部分ともう一方の親のある部分をとることにより一つの子を生成する。
【０１６５】
色々な適用に依存するパラメータに基づき、エージェントの成功要因が決定できる。最も成功したエージェントは「繁殖」が許され、上記二つの原理を使用して子孫が生成する。変形が存在し、ここでは多くの両親が、もしそれらが極端に成功的であれば変更せずに次の世代へ移動する。新世代はその成功を測定され、そして新世代は再度また別世代を生成するために再度繁殖できる。エージェントの生命寿命は時には多世代であるが、一般に各世代に対し前世代は消滅する。見られるように遺伝プログラミングはソフトウェアがより効果的なソフトウェアへ自動的に進化することを可能にする方法を提供する。
＜ＤＮＡ突然変異の基礎としてのトリガ条件＞
【０１６６】
上で述べたようなビヘビアに基づく多エージェントシステムは遺伝プログラミングに利用される。それらはエージェントの間の、そして機能の個々のブロックからのエージェントビヘビア内での区別を提供する。これは突然変異及び交差演算子がブラインドソースコード修正におけるよりも、より効率的になるように誘導できる情報を提供する。
【０１６７】
一実施例で遺伝プログラミングは多数のエージェントクラス及び各エージェントクラスの一例だけを想定する。従って各エージェントは個体であり、ユニークである。突然変異又は交差を適用する場合、他に述べられていなければ両親の一つの本体が利用される。エージェントの最初の数は学習コード（例えば神経エージェント）を含む本体を有するビヘビアを含むか、又は全種類の小作動を行う多くのビヘビアを含むかのどちらかである。
【０１６８】
一実施例で突然変異演算子は一エージェントの一ビヘビアに作用する。一態様で多くの突然変異演算子が定義され、例えばアプリケーション固有の頻度で数にランダムに作用する：（ａ）ビヘビア（通常トリガ条件の中の）に発生するセンサ名はセンサの別の存在名へ置換される。この置換は一貫して行われ、従って全ての発生はソフトウェアのロジックをそのままに保つため置換される。センサは同一タイプのセンサにより置換されるだけである。（ｂ）トリガ条件のビヘビアに発生するビヘビア名はビヘビアの別の存在名で置換される。（ｃ）もしセンサがトリガ条件のＷｈｅｎ部分で述べられていれば、同一センサの異なるイベントを待つ。従って「ｓｅｎｃｏｒ．ｕｐｄａｔｅｓ」は「ｓｅｎｓｏｒ．ｃｈａｎｇｅｓ」又は「ｓｅｎｓｏｒ．ｅｖｅｎｔ」のいずれかに変更できる。（ｄ）もしビヘビアがトリガ条件のＷｈｅｎ部分で述べられていれば、同一ビヘビアの異なるイベントを待つ。従って「ｂｅｈａｖｉｏｒ．ａｃｔｉｖａｔｅｓ」はとりわけ「ｂｉｈａｖｉｏｒ．ｃｏｍｐｌｅｔｅｓ」又は「ｂｅｈａｖｉｏｒ．ｅｖｅｎｔ」のいずれかに変更できる。（ｅ）トリガ条件の「ｗｈｅｎ」部分のイベントは省略することができる。（ｆ）トリガ条件の「ｉｆ」部分の条件は省略できる。（ｇ）トリガ条件の「ｉｆ」部分に既にあるセンサの付加条件が付加できる。（ｈ）存在するビヘビア又はセンサの付加イベントはトリガ条件の「ｗｈｅｎ」部分に付加できる。（ｉ）新センサはエージェントに生成でき、そしてセンサはビヘビアのｗｈｅｎ条件に付加される。このセンサの更新は第一の特定突然変異から来る。センサはある確率でパブリック又はプライベートである。
＜エージェントレベル交差＞
【０１６９】
一実施例で新エージェントは、例えば一つのエージェントから多くのビヘビアを、そしてもう一つのエージェントから多くのビヘビアを取ることにより二つのエージェントから構築される。これらのビヘビアは新しいエージェントへまとめられる。両ビヘビアのローカルセンサは全てビヘビアのいずれでも使用されないローカルセンサを除き、新しいエージェントへコピーされる。
＜ベーシックビヘビアレベルの交差＞
【０１７０】
この交差は二つのビヘビアで作動する。新ビヘビアは両ビヘビアのトリガ条件の部分コピーを新トリガ条件へ混ぜることにより生成できる。一実施例で新ビヘビアの本体は両方の親の一つからとられる。本体内のコードには触れずに、アルゴリズムはそのままである。もしコピーされた親が「ｃｏｍｐｌｅｔｅＷｈｅｎ」節を有していれば、その文節は同様にコピーされる。これはアルゴリズムに関連するエラー処理が維持されることを保証する。センサ名の突然変異もまた「ｃｏｍｐｌｅｔｅＷｈｅｎ」文節へ適用される。
＜シーケンスシャルビヘビアレベルの交差＞
【０１７１】
別の交差演算子は二つの親をシーケンシャルにする。一実施例でこの交差演算子は一つの親をとり、そしてその親の本体の端に、それは「ｃｏｎｔｉｎｕｅＷｈｅｎ」ステートメントを第二親のトリガ条件に付ける。その後それは第二親の本体を付加する。両親の「ｃｏｍｐｌｅｔｅＷｈｅｎ」文節は全て付加される。
＜シーケンシャルビヘビアレベルの突然変異＞
【０１７２】
ビヘビアが「ｃｏｎｔｉｎｕｅＷｈｅｎ」ステートメントを有する場合、本体の開始から始まる又は「ｃｏｎｔｉｎｕｅＷｈｅｎ」スタートメントから始まるコードは、次の「ｃｏｎｔｉｎｕｅＷｈｅｎ」ステートメント又は本体の端迄削除される。
【０１７３】
他の演算子が使用できる。要点はＲＩＤＬのトリガ条件及び文法はアルゴリズムが、文法的及び意味的レベルからソフトウェアを中断することなく、それがコードを安全に接着する明確な点を定義することを可能にする。
＜作動中の拡張コミュニティ＞
【０１７４】
多エージェントシステムの遺伝プログラミングは類似コミュニティの概念を使用して可能となる。
【０１７５】
一実施例で開発者はソースコード表示を遺伝プログラムに供給したので、遺伝プログラムはそれ自身のソースコードへのアクセスを有する。遺伝プログラムはソースコードを変更し、コードをリコンパイルする。そうする間に継承を使用することは遺伝プログラムにとって有利である。
【０１７６】
コンパイルの後、新プログラムはスタートし、その結果、新コミュニティが生成する。このコミュニティは普通元のコミュニティに類似している。継承が使用されたので、古いコミュニティのエージェントクラスは大部分そのままであるが、しかし新しい子孫が生成している。
【０１７７】
次に全エージェントは新コミュニティへ移動するために作られる。これが起こってから、古いコミュニティは消滅する。最終結果は我々のエージェントはまだ同じであるが、今やそれらはそれらの子孫と競争する必要がある環境にある。
｛エージェントファイルシステム態様｝
【０１７８】
例えばマイクロソフト（商標）ウインドウズの現在の版ではそうであるように、ファイルシステムがデータベースに基づく場合、エージェント指向のデータベース原理はビヘビアをファイルに割り当てるために使用できる。例えばファイルはそれ自身をモニタし、そしてそれ自身をバックアップすること、又はそれを修復するか、又はユーザにある状態を知らせるか、又は他の方法で自己管理をすることが必要であることを決定する。これはユーザからＰＣ維持の負荷を有利にとることができ有利である。
【０１７９】
本発明は典型的実施例に関して述べてきたが、それはそれに限定するのではない。むしろ付属の特許請求の範囲は、本発明の同等物の範囲及び幅から離れることなく、この技術の熟練者によりなされる本発明の他の変形及び実施例を広く含むと解釈されるべきである。
【図面の簡単な説明】
【０１８０】
本発明の実施例のより完全な理解は付属図面と合わせて考えれば、以下の詳細説明を参照することにより直ちに得られるであろう。
【０１８１】
【図１】本発明の実施例によるＲＩＤＬエージェントの色々な要素を図解する全体ブロック図である。
【図２】重畳が本発明の実施例によりＲＩＤＬで受け入れられる場所を図解する表である。
【図１】
2007523397.tif 000003
【図２】
2007523397.tif 000004
【国際調査報告】
2007523397.tif 000005
2007523397.tif 000006