【発明の詳細な説明】
分散処理環境において使用するためのサービス提供システム
この発明は分散処理環境において使用するためのサービス提供システムに関す
る。
分散処理環境は益々有用さが知られるようになっている。分散処理は計算処理
能力が例えばメインフレーム設備にもはや集中しておらずに、いろいろな違った
場所に設置することができてその間で通信リンクを備えている場合を言う。クラ
イアント／サーバ構造は分散処理環境の一形態であり、そこでは１つの計算機応
用、もしくはソフトウエアプロセスが２以上の計算用プラットホーム間で分散し
ていてもよい。こういった計算用プラットホームは例えばパーソナルコンピュー
タであってよく、それがローカルエリア網(LAN)のような網によってリンクされ
ている。
どんな計算用環境でも、一組の異なるプロセスを用いることによってある動作
を支持することがときには必要となる。これらのプロセスは異なる物理的場所に
配置したり設置したりできる。これらのプロセスは例えば情報を用意するための
いくつかのプロセスとその情報の意図した受取人についてセキュリティのチェッ
クを実行するためのプロセスとを含む。
例えば、組織における管理者は市場調査、営業、研究、開始、製造、経理及び
法務部門からの情報に基づいて判断をすることができるようにする必要があるし
、また例えば情報が悪者の手中に入らぬように作られた厳重なセキュリティプロ
セスにかなうようにする必要がある。適切なしかも変らない情報を大きな会社全
体で要求することは複雑で時間を費やすことになり得るし、とくに他のプロセス
も一緒に入ってくる場合はそうである。さらにまた、情報への変更がある部署で
されると、前の決定を無効とすることがあるという影響が会社全体に生じ得る。
複数プロセス活動の他の例は口座設定であろう。これにはいろいろな発生源（
ソース）から情報を集め、新口座所有者をフィルタにかけるためのセキュリティ
プロセスを使用し、口座勘定明細書及び他のプロセスの計画作成を始動させる
ことが必要となろう。
全体のサービスを設定するためにはそこでいくつかの成分となるプロセスに事
実上依存することになり、各成分プロセスには例えば記憶容量、通信帯域幅、発
給までの時間等々の用語で言われるそれ自体の利用可能性要件を備えている。
いつものことであるが、現実にサービスを用意し、それを受取るための時間は
長すぎない方が好い。したがって、あるサービスの提供にあたって異なる処理能
力のものが一緒に使われなければならないようなどんな環境でも、こういった異
なる処理能力を設定するための時間は小さくすることが一般に望ましい。
一つの見方をすると、この発明は分散処理環境下で使用するためのサービス提
供システムを用意するものであり、このシステムの構成は；
サービス要求を受けるための入力と；
要求されたサービスを用意するのに使用するための成分プロセスを識別するた
めのサービス要求処理手段と；
これら成分プロセスの用意に適用できる条件を確立するのに使用するための交
渉手段と；
サービスを用意するために、識別された成分プロセスの利用可能性を示すパラ
メータを記憶するための更新可能なデータメモリへアクセスするための手段と；
要求されたサービスの利用可能性を示すことを含む、サービス要求に対する応
答を送出するための出力とを含み；
前記処理手段はデータメモリ内の１又は複数のパラメータにアクセスし、この
１又は複数のパラメータを用いて要求を処理し、かつ前記応答を送出することに
よりサービスを処理するように適合している。
成分プロセスは例えば別のシステム又は同じシステム内部のプロセス機能によ
って、もしくはその両方によって供給されてよい。
したがって、この発明の実施例はサービスを提供するのに成分プロセスを用意
するために交渉をするように装備されてはいるが、あるサービスの利用可能性を
初期に表示することは記憶されたデータからされるのであって、サービス提供条
件を確立するための実時間交渉からではない。このことは、実際上、実時間交渉
が遅れを生じさせうるので速度の点で有利である。
この処理手段は先ず要求されたサービスの提供に必要となる成分プロセスを識
別して、それらの成分プロセスについてパラメータにアクセスするか、あるいは
全体としてサービスに関連して記憶されている１つ又は複数のパラメータを備え
ていてもよい。
上述のシステムはソフトウエア“エージェント”として実施することができる
。ソフトウエアエージェントは通常はソフトウエアのモジュールであり、それは
プロセスソフトウエアと、データあるいはデータとへアクセスする手段を含んで
いる。プロセスソフトウエアは普通は少なくとも交渉プロセスを含んで他のエー
ジェントと交渉をすることを目的とし、また利用できるデータは普通はそのエー
ジェントに対して局在する、すなわち特定の、データと、そのエージェントを含
む全体システムに関してグローバルな（包括的な）性質をもつデータとの両方を
含んでいる。
エージェント(agents)については次の文献に記載され論じられている。
“Intelligent Agents Theory and Practice”by Ｍ Ｊ Wooldridge and ＮＲ J
ennings (1995),The Knowledge Engineering Review,Vol 10(2)pp115-152。
この発明の実施態様であるシステムはそれ自体が１つのエージェントとなる。
そこにはサービスを用意するのに必要とされる成分プロセス又は資源の少なくと
も一部を用意するための処理及び資源能力を含んでいる。このシステムはしかし
複数の上記モジュール、すなわちエージェント、を含むのがよく、各エージェン
トは成分プロセス又は資源の少なくとも一部を用意するための能力を含む（すな
わち能力の制御機構を備えている）。
上述の“利用可能性を示すパラメータ”は一組の条件又は規則、あるいはデー
タかもしくはその両方の形式をとり、ここでは成分プロセス又は資源が１つの工
ージェントから他のエージェントへ又はサービスの直接提供をするエージェント
によって、ときには“サービス・レベル・アグリーメント（合意）”(SLA)とし
て知られているように、用意することができる。
このシステムが複数のモジュール、すなわちエージェントを含む場合には、サ
ービスの利用可能性はそのサービスの提供で必要とされるエージェント間でのSL
Aによって示されてよい。これらのエージェントは“対等な”関係(peer to peer
relationship)をもってよく、すべてのエージェントのステータス（状態）はサ
ービス提供目的で一緒にされたエージェントのチーム内で実質的に等しくなって
いる。代って、階層的関係をもつエージェントでの利点があり、この関係では主
要なエージェントが“従属する；下位の”エージェントの一群に対する利用可能
性データを有することができる。すなわち、主要なエージェントはサービスを提
供するための自己の能力を示すSLAを記憶しており、このSLAは他のSLA（すなわ
ち従属するエージェントのSLAである）の所定の組によって決められるものであ
る。
このような階層構造は従属するエージェントの複数層があることになるので複
雑であるが、サービスの利用可能性を推定する際の効率は増大する。その理由は
、１つの主要なエージェントが他の群に対して従属するエージェントの１つの全
体群の代りとなり得るからであり、この主要なエージェントによって交渉された
SLAと第１の群とが両立しないような場合について代りとなる。
この形式の実施態様では、少なくとも何がしかのSLAが限られた寿命すなわち
“時間切れ（タイムアウト）”機構をもつ場合には利点となり得る。そうでなけ
れば、実際の状態が期限外であることによりSLAを支持できないものにするか、
あるいはせいぜい誤解に導くものとする。これがとくに利点とされるのはシステ
ムが先を見越したサービス版を含むときであり、その場合にこのシステムは例え
ばあるサービスに関連して情報を使用者に警告することになる。関連しているSL
Aが時間切れとなると、これはこのシステムが時間切れとか不適切な助言やデー
タ事項を送る可能性を減らすように働く。
“エンティティ”という用語は次のような規格で使用される。ここで使用され
る用語“エンティティ”は計算機環境内で通信をすることができる装置の部分を
意味している。実際には少なくとも１つの入力と１つの出力とを含み、また、と
きとしては、提供することになるサービス、すなわち成分プロセスの１又は複数
を放出するための手段を含む。例えばワークステーション、パーソナルコンピュ
ータもしくは計算機網ノードである。
この発明の実施例では、システムは一般に１又は複数のタスク（成分プロセス
）もしくはサービス提供に必要とされる資源あるいはその両方に接続された制御
出力をさらに含んでいる。
このシステムはまた前記計算機環境内で１又は複数のタスクもしくは資源でサ
ービスを提供するためのもの、あるいはその両方に接続されたデータ入力を含み
、タスク又はプロセスによって出力されたデータを受け、さらに前記データから
前記パラメータを生成するためのデータ処理手段を含む。代って、タスク又はプ
ロセスによって出力されたデータがすでに前記パラメータを含んでいてもよい。
好ましいのは、この発明の実施例のシステムがさらにサービスを支援する際に
成分プロセスの運用と資源の用意との計画を作るための計画作成用手段を備えて
いる。しかしながら、サービス要求を受けるとすると、この計画作成用手段は利
用可能性を示すためにサービス要求に対する応答を出力した
後に始動されるのが
好ましい。これによって例えば計画作成用データもしくは条件を詳細に処理し、
共働させることによって生ずる利用可能性表示の遅れが回避される。
システムがサービス提供に同意（利用可能性を示す応答を）すると、そのサ一
ビスの送出を支援するためにその資源の使用計画を立てることができる。そこで
この発明の実施例は、通信環境内で、サービスを提供する方法を用意し、そこで
はサービスに対する要求を受けること、そのサービスの利用可能性を示す１又は
複数の記憶されたパラメータにアクセスすること、パラメータを応用して出力を
送出すること、及びその後にそのサービス提供のための資源及び処理能力の計画
を立てることを含んでいる。
上記のほかに、この発明の実施例では、関連する情報が前もって（前進的に）
識別することができ、その情報を特に要求はしていないがそれにも拘らずその情
報に関心があると信じられている当事者に配送されるようにしている。情報を拡
げるためのこのような能力は例えば決定を下すものやサービスを要求するものと
いった当事者で情報の存在に気づいていない者に対してとくに有用である。情報
を拡めることは情報が入手可能となったときに生じ、またはそのような情報が関
連するサービスを当事者が始めるときに生ずることになろう。
この発明の実施例であるシステムは大会社がその業務を行う方法を強化するた
めに使用でき、極めて大規模な情報に対してアクセスし、使用しまた価値を加え
る方法を改良することによって行なわれる。‘共働エンジニアリング(concurren
t engineering)’というメタファ（隠喩）が意味するところは、業務活動を逐行
する
最善の方法は必要な情報、資源、及び技能でその活動を実行するのに必要とされ
るすべてを出来るだけ早く、一緒にすることである。
この発明の別な実施例はとくに仮装組織という技術思想を支援するもので、こ
の組織は２以上の実際の組織が例えば業務同意とか契約によって規定された時間
に対してリンクされており、この発明の目的上は単一の組織として取扱われる構
成である。このような条件の下では各組織と関係した資源は全体のシステムに対
して利用可能となる。このような組織はその性質上、実際の組織間の業務のやり
とりのどれがどの程度に実行できるかを制御する厳格な機構に従うものである。
この発明の実施例は次の動作を行うことができる：
（ｉ）関連する情報が組織内に置かれている場合はいつでも決定を下す者がそれ
にアクセスできる（このことは情報が多くの異なるシステム形式と情報モデルで
記憶されているという事実に拘らず可能でなければならない）。
（ii）組織内部の他の部署から情報管理サービスを求めてそれを得ることが決定
を下す者にできる（またときには組織外からでもそれができる）。
（iii）関連する情報を、それが明示的に求められていなくとも、
前進的に(proa ctively)識別し
、時宜を得て配送する（これは例えば決定を下す者がその存在に
気付いていないことによる）。
（iv）現在の決定コンテキストに影響を与える業務プロセスについて別なところ
でされた変更について決定を下す者に知らせる。
（v）決定を下す活動の結論と結果に関心がある当事者を識別する。
上述のように、この発明の実施例の利点は、サービスを提供するという決定が
記憶されているパラメータに基づいており、サービスを提供するように求めてい
る資源についての実時間もしくはほぼ実時間の情報に基づいていないことである
：決定に到達する前に、システムで利用できる資源についての詳細の分析を実行
する必要はない。このシステムは求められた時間にサービスを提供するためにシ
ステムの能力の推定をすることにその決定の基礎をおく。
記憶されているパラメータにはあるサービスにかかると予期されている平均時
間、サービスを提供するためにタスクを実行する予想コスト、もしくはシステム
によってすでに行なわれた仕事の量あるいはそれら全部が含まれることになる。
他の情報も決定に使用でき、どんな基盤でサービスが提供されるか、例えば同じ
エンティティで処理した過去の経験が判断される。
提供の間に詳細な資源分析をしないことは、一度サービスが交渉されてしまう
と、対象を完了させることができないという危険を増大させることになるが、こ
のような欠陥は、後に詳述するように受け入れられるものとして処理できる。
処理手段は一般にデータメモリの更新で使用するための資源からデータを受け
るようにされている。このようなデータは資源の過去の動作に基いたシステムの
能力の尺度を含んでいる。例えば、システムによってサービスが提供される都度
、資源がどんなにうまく実行をしたかについての情報がパラメータを調節するた
めに使用できる。動作情報には実際のコストデータと実際の時間で求められた出
力を用意するのにかかったものを含むことができる。この情報はまたシステムに
とってすぐに利用可能となるタスク現状情報を含むことができる。
ある実施態様では、このシステムは成分サービス又はプロセスを他のエンティ
ティから要求するための分散形計算機環境に接続された要求出力を含んでいる。
成分サービス、すなわちサブサービスはそのサービスを提供するためにこのシス
テムが要求するものである。例えば、要求されているサービスが新業務口座を開
くことであれば、サブサービスは予期される口座所有者の経済的な可能性をチェ
ックするタスクとなろう。このサブサービスは一般に他のシステムもしくは人間
のオペレータでもよいようなエンティティによって用意されることになる。
ある実施態様では、このシステムはサービスを提供するために資源の計画を立
てるための手段を含む。この場合に望ましいのは、処理手段が採用され、ある資
源の計画を立てるために計画を立てるための手段による失敗に応答して、適時に
サービスを完了させるために、
・タスク／サービスの再計画を立てること；
・エンティティに向けて初め要求されたサービスは別な条件下でのみ提供でき
ることをメッセージとして送ること；
・別のサービス提供用エンティティでサービスを再配置すること；もしくは
・そのサービスが提供できないことをそのエンティティに示すこと；とする。
こういった動作はサービス提供で発生することになる問題を取扱う上でシステム
に融通性を与える。
回復のための上記の段階は動作中にサービスが失敗をした場合にも同様に応用
できる。ある資源が使用不能となる、例えば通信の故障が原因の場合である。
そこで一般には、このシステムはさらに計画を立てるための手段のように、故
障を監視するための手段を含んでもよい。ある故障を検出して動作するためには
、このシステムは関連するサービス要求に関係して修正を加えた応答出力を始動
させるように適応されていてよい。さらに、サービス要求を記億し、また関連す
る記憶されたプロセス要求を識別しアクセスするために故障の検出で始動するよ
うにされ、更新可能なデータメモリからの１又は複数の修正されたパラメータを
用いた再処理をして、修正された応答出力を用意するようにされていてよい。
この発明の実施態様では、このシステムは１又は複数の要求しているエンティ
ティに対して同時に複数のサービス事例もしくはサービスのための交渉あるいは
その両方を提供するように構成されている。このやり方の利点はシステムが複数
のサービス要求元によって使用できるようになることである。この点については
、少なくともいくつかの資源もまた複数の資源要求を同時に支援できることが好
ましい。
別な観点でとらえると、この発明はサービス提供用システムを用意しており、
該システムは、あるエンティティと交渉するための手段であって、該エンティテ
ィからの要求に応答してサービスを提供するためのものと、サービスを提供する
ためにこのシステムによって使用できる１又は複数の資源にアクセスするための
手段とで成り、該交渉するための手段にはサービスを提供するための現在のシス
テム能力の尺度に関係する該システムについてのデータを含み、かつ要求に応答
してサービスを提供するために該データに基づいて実質的に交渉するようにされ
ている。
さらに別な観点でとらえると、この発明はサービス提供の方法を用意しており
、この方法は少なくとも１つのサービスプロバイダ（提供するもの）と少なくと
も１つのサービスリクエスタ（要求するもの）とを含む分散形計算機環境内で実
現されるものであり、該サービスプロバイダは該環境内のいずれかのサービスリ
クエスタからの要求を受けるための入力と、該サービスリクエスタに応答を送る
た
めの出力と、該応答の性質を判断するために該要求を処理するための処理手段と
、サービスを提供するためにサービスプロバイダの現在の能力を示すパラメータ
を記憶するための更新可能なデータメモリにアクセスするための手段と、該サー
ビスプロバイダによって使用することができる環境内で１又は複数の資源に対す
る制御出力とを含んでおり、前記処理手段はデータメモリ内に記憶されたデータ
に基づいて該応答の性質を判断するようにしている。
（“サービスプロバイダ”と“サービスリクエスタ”という用語は無論ここで
はそれぞれサービスを提供するかサービスにアクセスするための装置を意味して
おり、ほかのところで時折使用されているような組織(organisation)などの意味
ではない。）
この発明の実施態様を添付の図面を参照して例としての目的でのみ以下に記述
して行く。
図１はこの発明の実施態様を支持するのに適した分散形構造の図であり、
図２は図１の構造の基本的な構成ブロックを示す図であり、
図３は図２の構成ブロックの異なる部分間に存在する関係を例示する図であり、
図４は仮装エージェンシイの技術思想を例示する図であり、
図５はこの発明の実施例によるエージェントの構成部分を示す図であり、
図６はこの発明の実施例が動作できるシナリオの例を示す図であり、
図７は図６に示したシナリオ内でサービスを動作させるためのプロセスの流れ図
であり、
図８はハードウエア用語でエージェントとそれが置かれる構造を示すものである
。
この発明を作り上げる際に各種の産業及び商業分野からの多数の業務プロセス
を分析し、いくつかの共通の特性が識別される結果となった：
（ｉ）複数の組織がしばしば業務プロセス内に含まれ、各組織が全体の活動の中
で自己の利益を最大にしようと試みる。
（ii）複数の組織は物理的に分散されている。この分散は１つの敷地、１つの国
家、あるいは大陸をもまたいでされている。この状態は次の文献に記述されてい
るような仮想組織に対して一層明白なものとなる。“Social Dimensions of Off
ice Automation”by A.Mowshowitz(1986),Advances in Computers,Vol 25,pp335
-404,こ
れは短時間の間、集団に対する忠誠の義務(allegiances)を形成し、その後、一
緒にいることが利を生まなくなる場合には解散をする。
（iii）組織内部では、タスク、情報及び資源で業務プロセス内に含まれるもの
についての所有権は集中が排除されている。
（iv）組織内部の異なるグループは相対的に自律的であり、グループはその資源
をどのように、誰が、どんなコストで、どの時間フレームで使うかを制御する。
また、自分の情報システムを有していてそれが自己固有の特異な(idiosyncratic
)表現をもち、その資源を管理するようにしている。
（ｖ）自然な同時発生性を高度に有している。多くの相互に関連するタスクが業
務プロセスのいずれもの所定点で実行される。構成要素であるサブパートの制御
と資源とが集中化を排除されてはいるが、全体のプロセスについての拘束条件を
置く必要がある（例えば全体の時間、全体の予算などである）。また
（vi）業務プロセスは高度に動的であり、予測がたてられない。実行されること
が必要な全活動について完全で論理に基いた（アプリオリな）規格を与え、かつ
どのように命令を下すようにするかはむづかしい。作られる詳細な時間計画はい
ずれも不可避の遅れや予期しない事象（例えば人間が病気になったり、タスクが
予想以上に長時間を要するなど）によってしばしば乱されてしまう。
この発明の実施例はこの種の環境での業務を支援するように設計されている。
図１はこの発明の実施例が動作することができる業務組織内部の適切な構造の
概観図を示す。図１ではエージェント１０の分散システムが適切な通信網１１を
経由して相互に接続されている。エージェントと通信網とを含むこの環境は分散
処理環境を構成している。各部署１２で組織内のものはこの環境内でそれ自身の
エージェント１０によって表現されており、他のエージェントに対してその部署
に関係するサービスを提供できる。
分散形計算機環境はこの明細書内では特定の技術部門としてとらえてはならず
、単に計算機処理能力と資源とが別個に配置されていて、何らかの通信リンクを
経てアクセスできるという環境を意味するものを意識している。
ここでの記述で用語“エージェント(agent)”は分散形計算機環境で動作する
機能もしくはプロセスであって、かつ動作についての要求を受けて、結果を送出
す
るために自律的に動作できるものを言う。エージェントは通常は更新することが
できるローカルデータへのアクセスを備え、また普通はそれが置かれている分散
形環境についての何らかの包括的な情報をも備えている。エージェントは自律的
に動作し、決定を下す機能（インテリジェンス）を備えて、エージェントが交渉
をし、かつ到来するメッセージに応答して結果を出力することができるようにす
る。
各エージェントは１又は複数のサービスを実行することができる。サービスは
問題を解決する活動の何らかのユニットに対応している。一番単純なサービス（
タスクと呼ばれる）はこの発明の実施例では問題を解決する努力の原子的ユニッ
トを表わしている。これらの原子的ユニットは順序づけ拘束条件（例えば、２つ
のタスクが並列に実行できるとか、並列して実行されなければならないとか、直
列に実行されなければならないとか）と条件づき制御とを付加することによって
、複雑なサービスを形成するように組合せができる。サービスのネスト形成は任
意に複雑なものとできるし、最上位では全体の業務プロセスがサービスとして眺
められるようになる。
サービスは１又は複数のエージェントと関係しており、エージェントはサービ
スの管理と実行の義務を負う。各サービスは１つのエージェントによって管理さ
れるが、他の多数のエージェントによるサブサービスの実行を含んでいてもよい
。エージェントは自律的であるから、エージェント間には制御の依存性は存在し
ない；したがって、あるエージェントが他のエージェントによって管理されてい
るサービスを必要とする場合は単にサービスを開始するように命令することはで
きない。そこで命令ではなく、そのエージェントは所望のサービスが実行される
ことになる条項と条件について相互に受入れられる同意を得ておかなければなら
ない。このような契約がサービスレベル同意(SLA)と呼ばれている。SLAを得るた
めの機構が交渉である。すなわち一緒に決定をするプロセスで、当事者は自分達
の要求（多分に矛盾したものとなる）を言語に表わしてから、譲歩か新しい代替
を求めるプロセスによって同意に向って進む。この機構は“Negotiation Princi
ples”by H J Mueller(1996),Foundation of Distributed Artificial Intellig
ence,WileyInterscience,ed.O'Hara and Jenningsに記されている。
図３を参照して、エージェント３１，３２，３３は一般に同じ基本構造を有し
ている。これには
“エージェントヘッド”３１が含まれており、それがエージェ
ントの動作を管理するとともにピアとの対話（相互作用）を担務し、また
“エー ジェンシイ”
３０を含み、それが他のエージェント３２，３３を資源として含ん
でいる、エージェント領域の問題解決資源を表わしている。このヘッドには多数
の機能部品で各主動作について担務するものを備えている。主動作としては通信
、サービス実行、情況評価及び対話（相互作用）管理がある（詳細後述）。この
内部構造はGRATEとARCHONのエージェントモデルと関連があり、このモデルにつ
いては次の文献に記載がある。
“Controlling Co-operative Problem Solving in Industrial Multi-Agent Sys
tems using JointIntentions”by N.R.Jennings(1995),Artificial Intelligenc
e 75(2)195-240;
“GRATE：A General Framework for Co-operative Problem Solving”by N.R.Je
nnings,E.H.Mamdani,I.Laresgoiti,J.Perez and J.Corera(1992),IEE-BCS Journ
al of Intelligent Systems Engineering,1(2)102-114；
“Using ARCHON to develop real-word DAI application for electricity tran
sportation management and particle accelerator control”by N.R.Jennings,
J.Corera,I.Laresgoiti,E.H.Mamdani,F.Perrolat,P Skarek and L.Z.Varga(1996
),IEEE Expert.
図８を参照して、一般に、あるエージェント１０は１片のソフトウエアとして
実施され、例えばＣプログラム用言語で書かれていて、例えばUNIX(商標）応用
のプラットホームのような適当な計算機プラットホーム８０上で運用される。要
求と結果とがエージェント１０と要求元エンティティとの間を通過し、要求元エ
ンティティは別のエージェント８５かユーザ端末１２，８２であってよく、適当
な通信網である例えばTCP／IPコンパチブルなローカルエリア網を介して送られ
、この網には計算機プラットホーム８０がインターフェースをとっている。
エージェント１０にはローカルデータメモリ８４，８５を備えることができる
し、あるいはまた、網８６を経てデータベース８２へアクセスしてもよい。こう
いったデータメモリはエージェント間のSLAを保持して、システムによって提供
されることになるサービスを支持する。
各エージェント１０は一般に（その“エージェントヘッド”内に）１組のプロ
セス５１，５２，５３を含んでいて、エージェントとそれがする対話（相互作用
）を管理するのに使用し、また（例えばその“エージェンシイ”内に）タスク処
理能力か資源４１，４２，４６かのいずれかもしくは双方を備えて、求められた
サービスを実際に用意するようにされていてもよい。
ある実施例で分散形処理環境の原理に従うものでは、複数のエージェント１０
が１つの共通な計算機プラットホーム８０上に存在することができ、また逆に、
１個のエージェント１０がその環境内で複数の計算機プラットホーム８０にわた
って実現されるようにもできる。また、計算機環境は異種形式であってもよく、
各種の異なる計算機プラットホームを支援してよい。
エージェント１０はサービスを用意するために相互に通信をし、交渉をするこ
とができる。エージェントによって用意されるサービスは情報とデータの準備か
ら業務プロセス内のいくつかの同時発生タスクの実行までの範囲に及ぶことがで
きる。通常はサービスは多数の初歩的なタスクで構成されている。業務プロセス
の初歩的な機能成分であるタスクは再使用可能な構築用ブロックであり、企業を
構成するプロセスをエージェントが管理できるようにする。一般に、タスク４１
は低レベル構造を備え、その構造はユーザが基本的な動作を定義づけられるよう
にして、業務プロセスを作り上げて、分散形計算機環境内で管理されたオブジェ
クトとして実現できるようにしている。タスクはまた動作するようにされたとき
に消費することになる資源についての暗黙の表現と、求められて作ることになる
情報と動作の継続時間とを含む動作上の要件についての明示の表現とがある。し
たがって、タスクが動作するようにされたときに正規環境下で示すことになるや
り方は予測可能である。この実施例では、１タスクが２つのインターフェースを
支援する：管理インターフェースは動作の標準の組を支援して、その動作ではタ
スクとエージェントとの間で管理指令と情報との交換が許される；動作インター
フェースは非標準であるがタスク間で動作メッセージの交換が許される同意され
た動作の組を支援する。本質的には、エージェント１０で図１のインフラストラ
クチャ上のものはそれが提供するサービスによって特徴づけられている。
この実施例では、構造について３つの主たる要件が存在する：自律性、同時性
及び併合性である。自律性は局部的な組織、例えば法務部門が自分達の局部的な
タスクとプロセスをどのように実行するかを規定できる。この規定は局部的な組
織を代表するエージェントが他のエージェントとどのように対話（相互作用）す
るかを決める。エージェントに関連したタスクとサービスは同時に運用すること
ができ、そのエージェントによって監視され管理されるタスクとサービスとの間
で対話（相互作用）をしている。併合性はエージェントに対して歩進的にサービ
スを規定することができるようにし、全体の分散システムを再設計する必要はな
い。
図２はこの構造の基本的な構築用ブロック２０の表現を示す。この基本的な構
築用ブロックはエージェント２１とエージェントの制御下にあるタスク２２とを
含む。ある実施例では、構築用ブロック２０はピアからピアへの基調で動作する
ようにできる。言い換えれば各ユニット２０はサービスを供給したり、要求した
りするときにいずれかの他のユニットと交渉することができる。大部分の商用環
境は、組織のモデル上で見付けられ、モデルは関係づけられた資源とサービスの
集りに論理的に分けられている。したがって、現在の実施例では、構造はこの原
理によって功利的な感覚でサービスとタスクとをまとめるようにしている。この
目的のためにはタスクとサービスとをまとめてグループとすることはあるエージ
ェンシイとしてひとまとめにして知られている。
あるエージェンシイはタスク（と暗黙裡に資源）と（サブの）エージェントで
あるエージェントの直接制御下にあるものとの集合である。あるエージェンシイ
は共通の所有権についてのある形態の下にあるタスクに関する階層構造をもつグ
ループ化を反映しており、またそれに対してはタスクの実行での資源使用を最適
化するような試みに何らかの理由が存在している。エージェンシイ内のタスクと
（サブの）エージェントとの集まりは機能的なグループ化を反映する必然性はな
いが、多くの組織ではこの効果が期待されている。
図３では、他の従たる（サーバント）エージェント３２，３３がまた制御用エ
ージェント３１のエージェンシイ内に所属している。これは従たるエージェント
３１，３２が制御用エージェント３１に独占的にサービスを提供していることを
意味している。しかしながら、従たるエージェントは依然としてその自律性は維
持している。従たるエージェントはそのエージェンシイの外界に対して直接にサ
ービスを提供することはできない。ある条件の下では、エージェントは制御用エ
ージェントと従たるエージェントとの両方の役割をもつことができる。あるエー
ジェンシイ内のエージェントは通常はより低いレベルのエージェンシイの制御用
エージェントとなる。これが論理構造を反映しているエージェンシイの階層組織
に通じている。
一般に２つの形式のエージェント相互作用がある：交渉とサービス管理である
。実際には、これら両極端の間には相互作用のひろがり（スペクトラム）をもた
せることが可能である。
現在の実施例では、多数の別個のサービスが結合されて単一のサービスを提供
するようにできる。このサービスを提供するエージェントは制御用エージェント
に指定され、そこで異なるエージェントからの一組の（サブの）サービスが選ば
れ、グループにまとめられて仮想エージェンシイを形成することを図４に示した
。
仮想エージェンシイはあるエージェントのサービス管理機能を支援する構造で
ある。図４に示すように、仮想エージェンシイ４０はタスクとサブサービス４１
，４２（他のエージェント４３，４４からのもの）の集まりであり、制御用エー
ジェント４５によるある種のサービスを提供することに係わっている。この場合
、制御用エージェント４５は他のエージェント４３，４４から求めることになる
（サブの）サービスのための契約をしている（かそれを求める）ことになる。サ
ービスの提供に係わっている直接制御下にあるタスク４６はエージェンシイのサ
ブセットとなる。各仮想エージェントはあるエージェントが提供するサービスと
の１対１の写像の中に置かれる。サービスを提供する前に、エージェント４５は
その仮想エージェンシイ（の少なくとも一部）を前進的にまとめることができ、
求められている（サブの）サービスに対して他のエージェントと交渉してそれを
行う。すなわち、サービス要求を受けとるのに先行して仮想エージェントに関し
て交渉してSLAを記憶できる。
仮想エージェンシイを支援する重要な利点は、サービスが実時間で自動的に用
意できることであり、また実際に、資源がどこからでもプールできることである
。
１つのエージェントが複数のサービスを提供でき、その１つ１つは仮想エージ
ェンシイがまとめられてしかも制御されることを要求する。このために、エージ
ェントを支援しているプラットホームは複数のスレッドを支援できる必要がある
。オペレーテングシステムで複数のスレッドを支援しているものはOS2,UNIX,Win
dows95（商標）又はWindows NT（商標）である。実際には、分散形計算機プラッ
トホームはとくに多スレッドの応用を支援するために開発されてきた。このよう
なプラットホームの１つはICLからのDAISであり、OMG(the Obiect Management G
roup)のCORBA(Common Obiect Request Broker Architecture)と適合している。C
ORBAに従う製品は同種オブジェクトインターフェースとしてIDL(Interface Defi
nition Languageインターフェース定義言語)を提供する。CORBA標準に密着する
ことの利点は、すべてのCORBAバージョン２に従うプラットホームがそれを用い
る応用のもつ潜在的な領域を拡げて相互に作業ができるようになることである。
この実施例によると、エージェントには３つの機能上の外部インターフェース
がある：
・エージェント交渉インターフェースは、プリミティブの標準の組を備えてサー
ビスを求めているエージェント（クライアントエージェント）とサービスを供
給するエージェント（サーバエージェント）との間で条項（terms）について
の交渉を支援する；
・サービス管理インターフェースは動作（オペレーション）の標準の組を備え、
この動作はクライアントエージェントとサーバエージェントとの間で情報交
換を許す；
・タスク管理インターフェースは動作の標準の組を備え、この動作はエージェ
ントとタスク間で管理指令と情報の交換を許す。
実際には、３つの機能上のインターフェースのすべてが単一の物理的インター
フェースとして、例えば計算機システム内の１つのインターフェースとして、通
信網８６と接続して実現されている。
図５は実施例によるエージェントの高レベル機能モジュールを示す。このモジ
ュールは１つの計算機プラットホームあるいは複数のものの上に置くことができ
る。各モジュールは一般にソフトウエアプロセスであり、そこでは全モジュール
が一緒になってエージェントの特性を規定している。モジュール間の通信はプロ
セスの呼で送られるパラメータによるか、関連する更新可能なデータを含む共通
データファイルへのアクセスを備えている各モジュールによるか、あるいはオブ
ジェクト間のメッセージ送りによるかのいずれかによって実効あるものとしてい
る。
エージェント５０は交渉管理モジュール(NMM)５１を含む。NMM５１は、特定の
サービスを提供するために何がしかの外部エージェントと契約を交わすことが必
要な場合に呼出される。エージェントは詳細な資源割当てを実行せずに契約を行
うことができる。すなわち、あるエージェントのNMM５１はエージェント（サー
バ）がそのエージェントの資源管理モジュール(RMM)（後に詳記）によって詳細
な計画を立てなくてもサービスを提供することを約束できる。このようにして、
エージェントは詳細な資源計画作りから交渉を外して、交渉プロセスの間の実時
間性能を支援する。この実施例では、エージェントは同時に複数の契約について
交渉することができる。あるエージェントのNMM５１はこの目的のために必然的
にマルチスレッドとなっている。
交渉の間に、NMM５１は単一のサービスについての交渉の中でも、またエージ
ェントが関与しているすべての交渉にわたっても、複数の基準を関連づけてバラ
ンスをとる。この基準は、品質、時間、コストなどといったパラメータを表わす
（部分的な）順序を表わす値の空間としてモデル化できる。
交渉用言語は、例えば後に詳記されるように、エージェントの交渉を支援する
ためにNMM５１によって支援されている。この言語は同意されたプリミティブと
、プロトコルであって、契約内のパラメータ値の修正とそれとの同意とを示唆す
ることがエージェントにできるようにするプロトコルとを含んでいる。交渉言語
プロトコルはエージェント間の交渉の間にプリミティブの送りと受けとについて
有効な順序を規定する。契約のための交渉は以前のメッセージでデータ記憶領域
内記憶されているものを参照し、プロトコルに従わせ、そのプロトコルに関して
到来するメッセージを処理するようなメッセージの選択を含んでいる。
ここでの記述の意味する限りでは、契約はエージェント間の交渉後の同意の結
果である。契約（コントラクト）にはサービスの実例を配送するための条項と条
件とを含んでいる。この契約はサービス配送のための基準を作るパラメータにつ
いての同意された値のリストを含んでいる。例えばサービスが利用可能となるか
、発動させることになる度数、発動の継続時間、品質、コスト、欠陥に対する負
担等である。これらのパラメータは契約ひな形として提供の際に各サービスに対
して決められており、交渉をまとめるためにエージェントにより使用される。
RMM５２はエージェントの２つの主たる役割の間のリンクとバランサとして仕
えていて、それは個別となることと、集団（コミュニティ）の一部となることと
である。RMM５２はエージェントによって制御される資源を管理する。RMM５２の
主要な関心事は計画を立てる（スケジューリング）である。これは交渉した契約
の維持にとって本質的なことである。これには既存の契約上の義務が果されるの
を確実にするためにサービスとタスクとの共働と計画を立てることが含まれてい
る。RMM５２は内部の時間進行に合わせて条件と情報の変更を定期的にチェック
する。RMM５２はまた契約が必要なときにはNMM５１による交渉を始動させる。
サービス／タスク管理モジュール(SMM)５３はサービスとタスクとのランチン
グ（起動）と制御を担務する。SMM５３はすでに作られている契約を取扱い、条
項と条件とが効力あるものとされていることを確かにし、適切なレベルの報告が
行なわれ、契約が無事に完了することを確かにする。SMM５３はまた現に行なわ
れているサービスの状態を維持する。これには、次のサービスの分解を実行する
ために、スタックと現に行なわれているサブサービスとタスクに対するポインタ
との保持が含まれる。さらに、SMM５３は条件のチェックと得られた結果を戻す
ことを含むサービスの起動のために求められている情報を用意することを担務す
る。SMM５３はさらにタスクとタスク誤り追跡とを実行する。
エージェントは複数のサービスとタスクとを同時に実行することができる。エ
ージェントのSMM５３はこの目的のためにマルチスレッドとなっている必要があ
る。動作中は、SMM５３はそのエージェンシイ内のタスクからと他のエージェン
ト（例えばサーバ）からとの例外を処理することも担務する。例外は、この実施
例によって、いくつかのやり方の１つで解決することができる:RMM５１によるタ
スク／サービスの資源の再割当て；契約の条項の再交渉（欠陥のあるサーバエー
ジェントの場合など）；別なエージェントでサービスを再配置（権利侵害さ
れた(aggreived)クライアントエージェントの場合など）；例外は無視して、ペ
ナルティ（自己負担）をとる（それが適当とされるとき）。この融通性のある例
外解決のやり方は、詳細な資源計画のないままに、契約に入ってしまったが、特
定の資源が（サーバとしての）エージェントに対する要求が予見できないために
完了できない場合にも適用される。
各エージェント５０には情報メモリが例えば主メモリ又は外部データ記憶装置
内にあって、それが永続性のあるものと一時的との（ワーキング）メモリを提供
している。このメモリは自己と知識(acquaintance)とのモデルに区分されている
。
自己モデル(SM)５４はエージェント５０によって提供されるサービスについて
の情報を含む。SM５４はあるエージェントの統治の下にサービスと情報との表現
を維持し、あるエージェントが（サービスの供給元として）交わした契約(SLAs)
を記憶する。
知識モデル(AM)５５はエージェント５５が他のエージェントにより提供された
サービスについての情報の絵と、それらのエージェントの動作についの履歴とが
作れるようにする。このような履歴情報は選択ができる場合についてのある問題
に対してどの解決をあるエージェントがとったかを判断できる。AM５５はまたあ
るエージェントが（サービスの受領側として）他のエージェントとした契約(SLA
s)も記憶する。
SLAの本質と概要とは法律上の契約形式からもほぼ正確に求めることができ、
これらは現在の業務上の取引を正常化するためにしばしば使われる。SLAの例は
次のようなものである。
SERVICE_NAMEは同意が関連しているサービスであり、SLA_IDはSLAの独自の識別
子（同じサービスに対して複数の同意がある場合もカバーする）である。SERVER
_AGENTとCLIENT_AGENTは同意した当事者であるエージェントを表わす。DELIVERY
_TYPEはサービスが提供されることになるやり方を同定する。SLAの計画用情報が
サービスの実行用に使用され、管理DURATIONはサーバがサービスを済ませるのに
使える最大時間を表わし、STRAT TIMEとEND TIMEは同意が有効である時間継続期
間を表わす。この場合、同意はエージェントCSDがエージェントDDを呼出して09:
00時から18:00時の間に要求されればいつでも顧客網の値段を定めかつ設計する
ようにし、しかも各サービス実行が３２０分を超えないようにする。この同意に
はまたメタサービス（変形サービス）情報として開始と終了との時刻間で許され
る呼出しの数量、呼出し当りに支払われる値段、サーバで違反毎に発生する負担
(ペナルティ)などの情報を含んでいる。CLIENT_INFOはクライアントがサーバに
対してサービス呼出しで用意すべき情報（この場合はCSDが顧客プロフィルを用
意しなければならない）を特定し、また
REPORTING
POLICYはサーバが完了時に戻す情報を特定する。
２つの支援モジュールがあり、エージェント５０の創生と通信とを支援してい
る。通信モジュール(CM)５６は到来するメッセージと送出するメッセージの両方
に対する焦点となっている。CM５６は分散形計算機環境にわたってソフトウエア
を分配させることを支援する。
初期化モジュール(IM)５７は最初に始動されるモジュールである。このモジュ
ールは他のすべてのエージェントモジュールを初期化する。全部のモジュールが
配置されるときには、IM５７が一番不活性な状態になり、オブジェクト識別子を
分散形計算機環境に輸出して、他のエージェントによって位置決めがされること
になる。IM５７はまたそのエージェントとエージェント管理、検査及びデバグ用
ツールなどの集まりとの間の接続の初動点でもある。
図６はこの発明の実施例による仮想エージェンシイの例を示す。このエージェ
ンシイには６の当事者がおり、その各々がそれぞれのエージェントを備えている
：すなわち、営業部６００とそれが関係するエージェント６０；顧客サービス部
６１０とそれが関係するエージェント６１；法務部６４０とそれが関係するエー
ジェント６４；設計部６３０とそれが関係するエージェント６３；調査部６５０
とそれが関係するエージェント６５；顧客調査部６２０とそれが関係するエージ
ェント６２である。
顧客サービス部６１０は、そのエージェント６１を経て、“顧客に見積”を送
るサービスを提供することができる。このサービスは３つの成分サービスがある
：“法律上の勧告”サービス；“顧客調査”サービス；及び“顧客網のコスト算
定と設計”サービスであり、それに５つの成分タスクが加えられる；“顧客詳細
の捕捉”６１２；“顧客の要求の捕捉”６１１，“サービス要求プロフィルの識
別”６１４；“サービス識別”６１３，及び“見積り提供”６１５である。
法律上の勧告サービスは法律上の勧告エージェント６４によって“正規の”サ
ービス（提供されるサービス形式については後に詳述）として提供され、それに
よって、正規の基調では法務部が予約されたサービスに対する顧客要求を見直し
て、違法であればあるいはどれが法律問題を提起しているかにフラグを立てる。
顧客を調査するサービスは、顧客調査エージェント６２によって提供され、単
一のタスク６２１で成る“オン・デマンド（要求時）”サービスであり、このタ
スクは識別子(ID)を検証しかつ信用度をチェックして顧客を調査する。一般に顧
客調査サービスはアウトソースの信用チェックエージェンシイによって用意され
る。
顧客網のコスト算定と設計サービスで、顧客網コスト算定及び設定エージェン
ト６３によって用意されるものは顧客によって要求された予約サービスのコスト
を算定する。このサービスは３つのタスクと１つの成分サービスとを含む。タス
クは“分析要求”６３２・“設計網”６３１；“見積り提供”６３３である。こ
れらのタスクは顧客の敷地の装置(CPE)についての知識に基いたもので、要求さ
れた網についての見積りを用意する。ある環境では、顧客サイト調査サービスが
利用されて顧客のサイトの調査がされる。
顧客サイト調査サービスは、顧客サイト調査エージェント６５によって用意さ
れ、必要とされる場合に特別に交渉することとされる。“１回限りの”サービス
である。このサービスは設計を始めるには顧客サイトについての詳細が不十分で
ある場合にだけ必要とされる。見積りを用意するプロセスは図７に例示してある
。
顧客の見積り提供サービスは一般に遠隔通信営業部６００に提供されてそこで
する顧客サービスを支援する。顧客サービス見積り要求を受取ると、顧客サ一ビ
スエージェント６１は必要とされるサービスについての見積りを生成して、それ
を顧客に送る。
プロセスは顧客サービス部と接触する顧客により段階７００で開始される。顧
客詳細が段階７０５で捕捉され、また段階７１５でその顧客が調査されている間
に、顧客の要求が段階７１０で捕捉される。顧客の調べが失敗すると、プロセス
は段階７２０で終了する。
顧客の要求は段階７２５で記録されてサービスポートフォリオに対してマップ
される。その要求が標準の棚から取り出せるポートフォリオと合致できるもので
あれば、直ちに見積りが段階７３０，７３５，と７４０で提供され、その後にサ
ービスが終了する。予約されたサービス要求場合には、プロセスはもっと複雑で
、ビッド(bid)マネージャが介在する。
予約事項に対しては、ビッドマネージャ（図示せず）はさらに段階７４５で顧
客の要求を分析し、要求の合法性が段階７５０でチェックされる。要求が違法と
なる可能性があるような環境では、見積りプロセスは段階７７０において顧客か
らのもっと多くの情報を留保して停止されることになる。要求が確かに違法であ
ると段階７６０で判断されると、プロセスは終了して、顧客に通知される。現在
のプロセスでは、ビッドマネージャは人間のオペレータと仮定しているが、多数
のタスクは自動化できることは想到できることである。
網設計と見積書を用意するためには、顧客の構内での既存の装置についての詳
細な計画を所持する必要がある。ある場合には、CPEの計画は存在しないとか、
時代遅れになっていよう。このような場合には、ビッドマネージャは段階７５５
で顧客サイトが調査されるべきか否かを判断することになる。これはビッド値が
あるレベル（すなわち一番利益をもたらすビッド）を越える場合にだけ行なわれ
よう。もし必要であれば、調査が段階７６５で求められる。顧客CPEについて必
要な情報が得られることになれば、段階７７５で網が設計される。網設計と関連
するコスト算定が完了すると、顧客は段階７４０でサービス見積りを知らされて
、プロセスは終了する。
このプロセスでの各動作は資源の割当てを必要とし、開始点と終了点とを有し
、それによって進捗が測定できる。プロセス内の選択点はどの動作を連続的動作
のために準備する必要があるかを示している。同様に、そこには多数の動作で同
時に実行しなければならない／してもよいものとか、共働を必要とするものとか
がある。
エージェントの重要な役割はサービスを提供することである。サービスは他の
エージェントによって要求されることが（他のエージェントと交渉することも）
でき、また一般にはこのことがエージェント間で情報を転送する結果を生むこと
ができる。エージェントはそれが提供する各サービスをどのように用意するかの
規定を含むことを要する。その結果、各サービスについての記述がエージェント
に提示される。サービス記述は次の２つの形式のプリミティブで作られている：
（１）タスク−そのエージェントの制御範囲中で完全に実行される；
（２）サービス−インフラストラクチャを介して他のエージェントによって用さ
れる。
タスクとサービスとは同時に始動することができ、それらの間の相互作用（対
話）と通信とはサービス記述内の拘束条件によって自動的に管理される。代って
、サービスは他のエージェントからのサービス条項で再帰的に定義することがで
きるが、その結果、規定は単にタスク条項だけとなることに留意したい。
あるサービスはタスクと、他の（サブ）サービスであってあるエージェントが
（サーバとして）そのエージェンシイからあるいは（クライアントとして）他の
エージェントから、何がしかの機能動作を提供あるいは受領するものとがパッケ
ージされたものである。サービスは他のサービスの成分として再使用できる。こ
の実施例では、あるサービスはタスク、他の（サブ）サービス、及び性能パラメ
ータで成る再帰的制御構造である。性能パラメータは２つのエージェント（それ
ぞれクライアントとサーバと呼ばれる）間の交渉プロセスの間に用意される。こ
れらのパラメータが動作時にサービスの依頼の正確な特性を決めている。
ある場合には、エージェントは確実性と信頼性ついての何らかの基本的なレベ
ルをもつ特定のサービスの存在と利用可能性とを保証する必要がある。これは性
能パラメータによって定義されることになる。３つのサービス基本レベルがある
：一回限りのものはサービスの一回の動作ができる（動作度数は交渉の際に同意
される）;正規のものは、同意されかつ予め計画された時に複数回動作できる；
要求時のものは、同意した時間窓内の時間と度数でサービスの動作ができる。
サービス記述が作られて、あるエージェントについて登録され、言語として複
雑な同時動作の形式化を支援する言語が使われる。この記述は全体でサービスを
定義する段階を規定する宣言文のリストを含んでいる。この言語の範囲内では、
各宣言文は使用することになる仮想エージェンシイのサブセットと制御が次の宣
言文に移ってもよいとするような条件との両方を表現する。この言語はまた、同
時に実行してもよい、あるいは同時に実行しなければならないタスク又は（サブ
）サービスを表現するようなプリミティブをも含んでいる。ある場合には、また
継続的な動作も用意される。
好ましいのは、サービス記述言語がほん訳された言語であって、それ故にサー
ビスがサービス創生をするものによって再定義され、さらに進んだ再編集なしに
あるエージェントで登録されるようにする。このために、エージェント内の各コ
アモジュールはモジュールの主たる機能（サービス交渉、資源管理及びサービス
／タスク実行の各々）を支援するためのほん訳器（変換器）を含んでいる。言語
は一般に宣言的非決定論(declarative non-determinism)−これは仮想エージエ
ンシイがどの要素を採用するかを動的に決められるようにする−とプロセス制御
の指揮−これはサービス創生をするものが言語宣言文の構造を定めて命令する−
との特徴を組合せている。
使用にあたっては、エージェントはサービス記述を用いて、第１に、その仮想
エージェンシイ内のサブサービスのために一番よく交渉をするにはどうするかを
、また、第２に、自分自分のタスク（もしあれば）と一緒にこれらサブサービス
を実行するにはどう管理するかを判断する。
例えばサービスは次の特徴によって定義できる：
１． 各サービスは独特な名称を有している。
２． 各サービスにはガード（保護）がある。ガードはサービスを送出するた
めに必要とされる情報を宣言する。また、ある値ｘが利用可能であり、
かつ５より大きいなどの場合にだけサービスが放出できるといった拘
束条件を置いてもよい。
３． 各サービスには仮定を置いてもよい。ある仮定は情報にさらに拘束条件
を課したり、あるいはデフォールト値（この値が次に信じれることにな
るが恐らくは未知である）を指定することにする。
４． 各サービスはそのサービスがどのように実行できるかを記述するもので
ある本体(body)である。
例として、サービス記述を含むエージェントの自己モデルの一部は次のような
やり方で例示できる：
(Service
:NamePriceForecast
:Guard(Region,ProductionCapacity,CapacityCompetition,Deman
d,Experience)
:Assumption(Saleslevel:Default100:Obtain)
:Body(Sequence
(Parallel
(Sequence CreateTable,SetYears
(94..96))
(Calculate(Region,ProductionCapacity,
CapacityCompetition,Demand,
Experience))
StoreInTable))
このルーチンは価格予想が立てられる基盤として、領域についての情報、会社
の生産能力と競争力、クライアントによって特定される需要、およびサービスガ
ードで固定されている会社の経験について情報があることを述べている。一般に
、この情報は自動的に利用できず、要求によって提供されねばならない。これは
エージェントの自己と知識モデル(p.19)とを眺めて行なわれる。前もって与えら
れない情報の大部分は“プロバイデッド・バイ(…で用意される)”スロットで示
されたところにより適切なサービスを送出することを介して得られることになる
。この初期条件（ガード）をチェックした後に、適切な計算を実行するために、
エージェントは（特定の需要と関係する）営業レベルが１００％であることを仮
定することになる。たとえその計算を正当化するためにしても、エージェントは
営業レベルの確定値を得るためにサービスを送出しなければならない。これがチ
ェックされると、エージェントはサービス実行を開始し、言い換えれば本体を送
出する。
本体(body)内のサービスのいずれもがエージェント自身で実行されることが必
要であるということがない点に留意したい。本体の並列部分(p.25-p.26)は別の
エージェントによって用意されることになりそうである。一般に、本体内の各サ
ービスはエージェントの自己が知識モデル内のどこかで示されることになる。事
実、本体が記述するところは短いシーケンスのサービスとして価格予想が用意さ
れていることである。第１のサービスは並列サービスで、それに“ストアイン・
テーブル（表内記憶）”が続く。この並列サービスはテーブルの創生を記述し、
そこでは９４年から９６年までが初期化される。同時に(並行して)、エージェン
トは何らかの計算を実行する。これが成功したときには結果がテーブル内に記憶
される。
エージェントが通信し交渉をすることができるようにする言語を定義する必要
がある。さらに、２以上のエージェントが通信をしているときには、問題領域に
ついて共通の理解(view)を共有しなければならない。次の記述は２つのピアレベ
ルのエージェントでそれぞれが自身のそれぞれのエージェンシイを代表している
場合の両者間で交渉をするための言語の例を用意している。しかし、他の言語形
態もこの目的のために等しく適していることは理解できよう。一般的なサービス
／情報交渉構造は次による。
１．(サービスもしくは情報の一部を)見付け／位置を定める−コンタクを
とる。
２．(形体もしくはサービスか情報の本質は何かを)尋ね／説明する−詳細
を得る。
３．(サービスの設定もしくは何がしかの情報を受けるように)確定し／交
渉する−何をするかで同意する。
４．(サービスを実行し、もしくは情報を放出するのに進捗を眺めることが
できまた必要ならば告知することができる能力を備えて)実行／眺望
(view)／告知をする−同意したことを行なう。
５．終了
この構造は明示のサービス要求とともにもっと一般的な暗黙のサービス要求で
業務内で情報を見付け、位置を定め、かつ管理するというものの両方に適用され
ることが重要である。この構造は次のプリミティブを採用しており、上記構造に
従って番号を付してある。
１．CAN(YOU/ANYONE)DO<a service s>
CAN(YOU/ANYONE)PROVICE<informationi>
-->>return list of service/information providers
このプリミティブはキャスト（立役者）が複数いる状態でも等しく適用でき、
その場合には部署又は企業に基づいたエージェントとロケーションブローカとが
含まれているとともにサービスに対する同報通信要求の契約網形式も含まれてい
る。いろいろな程度の成熟度が想定され、エージェント自身のために開発された
モデルの形式に依存したサービスプロバイダの位置が関係している詳細な条項で
の想定がされる。こういったプリミティブは“誰”がこれをすることができるか
と“どこにいる（ある）のか”といったことで要約することができる。
２．SERVICE DETAILS<ask agent a,regarding service s>
INFORMATION DETAILS<ask agent a,regarding information i>
-->>return list of<inputs required>,<outputs given>,
<Optional Resource("time"/"cost"/"..."estimate〉
これらのプリミティブはそのサービスが何で成り立っているかをもっと詳細に
正確に確立させるようにする。“何”をすることができるかを言うこととして要
約できるものである。全体的な共通言語は何も仮定されていないので、本質的に
追加されるプリミティブはここでは“EXPLAIN<ontology/term>”となり、これが
新条項を処理することがエージェントにできるようにするのに必要となる。
３．PROPOSE<agent a,service s,conditions c,optional rationale r>
COUNTER PROPOSE<agentａ，service s,conditions c,
optional rationale r〉
REJECT
ACCEPT
-->>return<agreement(working conventions，reporting level,
penalties,etc)>
これらはエージェントがサービスをどのように提供するかについて同意できる
ようにする基本的なプリミティブである。条件は“強制的(mandatory)”と“好
ましい(desirable)”とに分けられる。サービス提供についてのオプションの原
理(optional rationale)と詳細とはエージェントに対して“不必要な”強制的要
件から生ずるデッドロックを破壊する機構を用意するか、サービス提供の新しい
／代替的な形態を用意するかする。これは一層成就した形の交渉プロセスが開発
／研究されることができるようにする。ここで注意すべき重要な事は修正後（そ
して恐らくはネスト状にした問合せ／説明の後に）提案が受理されて、特定の契
約を生み、それが実行されるように計画できることである。
４．INVOKE<agent a,service s,agreement c>
INFORM（ie notify）<agenta,mode of acknowledgement m>
QUERY/INSPECT<service s>
REVIEW<services delivered d〉
何らかの先の同意についてサービスが呼出され、その後に進捗が照会できるよ
うになるか、契約における報告のレベルに従って正式に調べられるようになる。
エージェントにとって相互に事象（予期できないものもしくはその他のもの）を
告知し合うことが必要であれば、そのときは受領告知モードでこれが行なえて、
“なし”、“受領告知必要”もしくは“再交渉”が設定される。これは重要なプ
リミティブであり、必要であれば全体の交渉プロミスがネスト状態となるように
なる。
５．TERMINATE<status s,optionreason r>
サービスが終結するときは、その“成功”で満足が得られているかあるいは契
約者に設定された“放出”基準が満足されていないかのいずれかである。不満足
であれば、オプションの理由が終結に対して与えられなければならない。
上述したところは業務プロセスの演出を管理するのに適しているこの発明の実
施形態を例示した。この実施例は複数のエージェントで分散形計算機環境上にあ
るものがどのように共働して適切な情報を集め、その情報を使用するタスクと資
源とを管理できるようにする。このようなシステムは組織内部でプロセスを潜在
的に加速してよりよい全体サービスをその内部と外部の顧客に提供するとともに
、タスクと資源とを運用することによって利用可能であるサービスを用意し、と
くに仮想エージェンシイ内の予め交渉したSLAsを利用してその用意をするように
している。
このシステムはサービスの提供について要求元のエンティティと交渉ができる
という点で、またあるいはもしくはサービスの提供で利用できる資源と交渉がで
きるという点で融通性があり、したがってそのエンティティにとって受入れられ
るサービスの修正版を決定することができたり、そのサービスを提供するために
前記の資源との修正された関係を見付けたりできる。
加えて、このシステムではユーザへの情報とサービス提供とについて予見的に
振舞うことが可能であり、例えばそのユーザによって潜在的に求められているサ
ービスに影響を与えるような変化に関係した予見的な振舞いができる。
─────────────────────────────────────────────────────
フロントページの続き
(31)優先権主張番号 ９６０７５０４．９
(32)優先日 平成８年４月11日(1996．4．11)
(33)優先権主張国 イギリス（ＧＢ）
(81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，
ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ
Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ
，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，
ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＬＳ，ＭＷ，ＳＤ，Ｓ
Ｚ，ＵＧ)，ＵＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ
，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ
，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，
ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，Ｇ
Ｅ，ＨＵ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ
，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，
ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，Ｐ
Ｌ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ
，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，
ＶＮ，ＹＵ
(72)発明者 ウィーガンド、マーク・エリック
イギリス国、アイピー12・１エルディー、
サフォーク、ウッドブリッジ、オーチャー
ド・クローズ 19
【要約の続き】
する。契約が最終段階となるときには、RMM（５２）は
そのエージェントにより制御された資源の管理を監督
し、SMM（５３）はサービスとエージェント（５０）に
より求められたタスクとを制御して契約を完了させる。