JP2009508209A - モジュール方式のエージェントアーキテクチャ - Google Patents

Abstract

エージェントアーキテクチャは、アプリケーションを何も実行せずに動作することを可能にする基本機能を備えることができる。基本アプリケーションは、何らかのモジュールを有する必要がない。機能が望ましい場合、モジュールを追加することができる。エージェントは、コントローラからポリシーおよび手順を受け取ることができ、そのポリシーおよび手順に基づいてモジュールを実行する。次いで、エージェントは戻り、情報を報告することができる。このようにすると、個々のタスクまたはアプリケーションに対する変更時に、再コンパイルする必要のないシステムを設計することが可能になり、それにより、新しいタスクおよびアプリケーションの開発が非常に容易になる。

Description

この出願は、2004年1月22日に出願されたRyan Rileyによる、「Client-Server Data Execution Flow」と題する米国特許出願第10/763808号の一部継続出願であり、また2004年1月22日に出願されたAnthony F. GigliottiおよびRyan Rileyによる、「Distributed Policy Driven Software Delivery」と題する米国特許出願第10/763814号の一部継続出願である。

本発明は、コンピュータソフトウェアの分野に関する。より詳細には、本発明は、エージェントソフトウェアのためのモジュール方式アーキテクチャに関する。

コンピュータウイルスおよび他の技法によるインターネット攻撃の増加は、多くの会社に対して著しい財政上の損害を引き起こしてきた。現在のアンチウイルスソフトウェアは、「攻撃的(offensive)」コード(例えば、既知のウイルス)のリストに対して、到来するファイルを比較することにより動作する。ファイルが、これらの攻撃的コードの1つに類似する場合、それは削除され、システムが保護される。しかし、最近のウイルス攻撃に関して、この手法には、いくつかの重大な問題がある。

第1に、ウイルスが新しくて、既知のウイルスリスト中にない場合、アンチウイルスソリューションは、それがウイルスであると識別しないことになり、したがって、ウイルスが広がるのを阻止しようとしない。第2に、「コードレッド」および「SQL slammer(スラマー)」などの最近のワームは、大部分のウイルス保護システムにより保護されたいずれの送信方法も利用しない。これらのウイルスの新しいストランド(strand)は、そのオペレーションを実施するためにコンピュータにより使用されるソフトウェア中の欠陥を利用することによって、直接コンピュータシステムを攻撃するように設計される。ウイルスは、したがって、アンチウイルスソフトウェアに介入されることなく、企業のネットワークおよび複製に侵入することができる。

最近のネットワークをアンチウイルスソフトウェアが保護することを妨げる他の重大な要因は、最近のウイルスの複製および増殖の速度である。数年前は、ウイルスが米国全体に広まるためには数年もかかる可能性があったが、最近のウイルスは、数分の間に全世界にわたり広がることができる。

最近のウイルス問題の根底には、システム管理および維持がある。ネットワークアプリケーションのすべては、あるレベルの攻撃に対して脆弱であるが、ソフトウェア製造者はこれらのエラーを解消するように努力して働き、ウイルス作成者がそれらを利用できる前に、問題に対する修正をリリースする。実際、アプリケーション製造者は、大部分の時間、ウイルスがさらにリリースされる前に、ウイルスがこれらのホールを利用するのを阻止するはずのアプリケーションに対する修正をリリースしてきた。残念なことに、最近のネットワークの複雑さに起因して、大部分の管理者は、ネットワーク中のすべてのコンピュータに対して、ソフトウェア製造者からリリースされた、ますます数の増加するセキュリティパッチおよび最新の修正に遅れずについていくことができない。

ネットワークアプリケーションのセキュリティホールを識別し、かつ管理するプロセスを自動化する解決策が求められている。この問題に対する典型的な解決策は、様々なコンピュータにインストールされる複数のアプリケーションのユーザを含む。これらのアプリケーションは、特定の条件が生じたときに実行される。例えば、会社は、特定の条件を検出するとそれぞれが実行されるいくつかのアンチウイルスコンポーネントをインストールすることができる。しかし、この手法を用いる場合、特に、それがネットワークアプリケーションのセキュリティホールを管理することに関する場合、いくつかの問題がある。それぞれの(アンチウイルスなどの)全体のタスクは、通常、それぞれが共にコンパイルされた複数のアプリケーションを必要とする。しかし、これは、1つのアプリケーションへの変更が他のアプリケーションの再コンパイルを必要とするので、開発および維持を困難にする可能性がある。さらに、複数のアプリケーションを同時に実行することは、メモリおよびプロセッサ資源を浪費することになり得る。特定のアプリケーションは、ある時間に動作する必要のない場合があるが、従来技術の解決策は、アプリケーションに対して、それが動作中の他のアプリケーションと共にコンパイルされている場合、動作することを要求する。

従来技術の欠点を克服する解決策が求められている。

エージェントアーキテクチャは、アプリケーションを何も実行せずに動作することを可能にする基本機能を備えることができる。基本アプリケーションは、何らかのモジュールを有する必要がない。機能が望ましい場合、モジュールを追加することができる。エージェントは、コントローラからポリシーおよび手順を受け取ることができ、そのポリシーおよび手順に基づいてモジュールを実行する。次いで、エージェントは戻り、情報を報告することができる。このようにすると、個々のタスクまたはアプリケーションに対する変更時に、再コンパイルする必要のないシステムを設計することが可能になり、それにより、新しいタスクおよびアプリケーションの開発が非常に容易になる。

この明細書に組み込まれ、またはその一部を構成する添付の図面は、本発明の1つまたは複数の実施形態を示しており、また詳細な説明と併せて、本発明の原理および実装形態を説明するように働く。

本発明の諸実施形態は、コンピュータ、サーバ、およびソフトウェアのシステムに即して本明細書で述べられる。当業者であれば、本発明の以下の詳細な説明は例示のためだけであり、決して限定することを意図していないことが理解されよう。この開示の利益を有するこのような当業者であれば、本発明の他の諸実施形態を容易に思いつくことになろう。添付の図面で示される本発明の実装形態に対する参照を次に詳細に行う。同じまたは同様の部品を参照するために、同じ参照指示を、図面および以下の詳細な説明を通して使用することになる。

明確化のために、本明細書で述べる実装形態の定型的な特徴のすべてが示され述べられてはいない。当然であるが、任意のこのような実際の実装形態の開発では、アプリケーションに関連する、またビジネスに関連する制約の遵守など開発者の特有な目標を達成するために、実装形態に特有な数多くの決定を行う必要があること、またこれらの特有な目標は、実装形態ごとに、また開発者ごとに変化することが理解されよう。さらに、このような開発努力は複雑であり、時間のかかるものであるかもしれないが、それにもかかわらず、この開示の利益を有する当業者にとっては、日常的な設計業務となるはずであることが理解されよう。

本発明によれば、コンポーネント、プロセスステップ、および/またはデータ構造は、様々なタイプのオペレーティングシステム、コンピューティングプラットフォーム、コンピュータプログラム、および/または汎用マシンを用いて実施することができる。さらに、当業者であれば、ハードワイヤードのデバイス、FPGA(書換え可能ゲートアレー)、ASIC(特定用途向けIC)などの汎用性が低い性質のデバイスもまた、本明細書に開示された本発明の概念の範囲および趣旨から逸脱することなく使用できることが理解されよう。

本発明は、エージェントアーキテクチャにアプリケーションを何も実行せずに動作できる基本機能を提供する。その基本アプリケーションは、何らかのモジュールを有する必要がない。機能が望ましい場合に、モジュールを追加することができる。エージェントは、コントローラからポリシーおよび手順を受け取ることができ、そのポリシーおよび手順に基づいてモジュールを実行する。次いで、エージェントは戻り、情報を報告することができる。このようすると、個々のタスクまたはアプリケーションに対して変更が行われた後、再コンパイルする必要のないシステムを設計することができ、それにより、新しいタスクおよびアプリケーションの開発が非常に容易になる。

本発明の実施形態では、エージェントアーキテクチャは、主モジュール、補助モジュール、およびモジュール設定の3つの部分から構成され得る。

エージェントの主モジュールは、基本アプリケーションであり、それは、コンフィギュレーションファイルに基づいて、割り当てられたモジュールをメモリ中に動的にロードし、またそのモジュールを使用してコントローラから受け取られたポリシーおよび手順を実行する。この設計の基礎は、これらのアプリケーションの開始フェーズ中に、主モジュールが補助的なモジュールをメモリにロードするまで、主モジュールは、いずれのタスク、機能、設定、制御、サブ機能、または手順も認識しないことである。この設計により、エージェントが、コントローラからのポリシーおよび手順をモジュールが実行するためのシェルとして働くことを可能にする。

設計的に、エージェントは、モジュールを何もロードすることなく動作することができるが、タスクを何も実施せず、またはコントローラへの通信を何も行わない。モジュールを動的にロードすることによってのみ、エージェントは、どのアクション、タスク、手順、または機能を実施できるかを知りかつ理解することになる。

補助モジュールおよびモジュール設定は、エージェントを構成するすべてのアクション、タスク、手順、または機能を実施するように設計される。モジュールは、別個に動的にロードされたライブラリとして作成され、またエージェントによりメモリ中にロードされ得る。

モジュールは、コンフィギュレーションファイルで定義できるモジュール設定を含むことができる。例えば、「Comms」モジュールは以下のような設定を有することができる。
<module name="comms" library="mod_comms.dll"
entry="module_main@comms@@YAHPAVinput@xp@@PAVoutput@3@1@Z" timeout="60">
<interface-accept<
<local addr="any" port="any" />
</interface-accept>
<interface-connect>
<local addr="any" port="any" />
<remote addr="192.168.1.1" port="8311" />
</interface-connect>
</module>

上記の例では、モジュールノードは、モジュール名、モジュールに対するライブラリ、およびモジュールをメモリ中にロードするためにエージェントが使用するエントリポイント、ならびに必要な任意の追加情報(例えば、タイムアウト設定)を含む。

本発明の実施形態では、モジュールは、全二重および半二重接続を用いて互いに通信することができる。すなわち、主モジュールが補助モジュールに書き込むために使用する1つのコンジット（conduit）、補助モジュールが主モジュールに書き込むために使用する1つのコンジット、および補助モジュールが診断情報を書き込むための1つのコンジットである。実質的には、各サブモジュールにとり、3つのコンジットは標準の入力、出力、およびエラーに見える。メッセージ構造は、メッセージを完全にディスパッチする（dispatch）のに必要なすべての情報を含むことができ、したがって、モジュールがメッセージ状態のリストを保有する必要はない。言い換えると、モジュールは、何らかのモジュールグローバル情報のほかに状態情報を保有する必要はなく、それをメッセージ構造中に挿入することができる。

本発明の実施形態では、補助モジュール間の通信における各メッセージは、スタックベースとすることができる。最上位のエレメントは、どの補助モジュールがメッセージを次に処理すべきか、およびその補助モジュールが実行するコマンドを指定することができる。この組(補助モジュール名およびコマンド)は、メッセージエレメント中で唯一必要な情報である。補助モジュールがメッセージを受け取るごとに、最上位エレメントを取り除くことができる。メッセージは、メッセージの残りが処理される前に、さらに処理するために他の補助モジュールに転送される必要がある場合、現在の補助モジュールは、そのスタックの最上位にエレメントを追加することができる。メッセージが、さらなる処理のために補助モジュールを訪れた後、現在の補助モジュールに戻るべきである場合、現在のモジュールは、まずそれ自体をスタックの最上位に追加し、次いで、他の補助モジュールを追加することができる。コマンドに対する応答が適切である場合、その応答を新しい最上位のエレメント内に配置することができる。補助モジュールがコマンドの処理を完了したとき、それは、主モジュールにメッセージを送ることができ、次いで、主モジュールは、スタックが空ではない限り、それを適切な補助モジュールへとディスパッチするが、空である場合、メッセージは完全に処理されており、アクションは何も行われない。

いくつかの一般的な補助モジュールの説明をここで提供することができる。しかし、当業者であれば、これらのものは単なる例に過ぎないこと、また特に述べられない限り、特許請求の範囲がこれらの例に限定されるべきではないことが理解されよう。

上記で簡単に述べたように、通信、または「comms」モジュールを提供することができる。このモジュールは、ユーザインターフェース、他のエージェント、またはコントローラなどの外部エンティティとの通信を担当することができる。

ポリシーモジュールは、モジュールを機能させることに関するいくつかのポリシーを保有するために提供され得る。本発明の実施形態では、これは、期限が切れた後、メッセージをトリガして主モジュールに送るようにするいくつかの繰返しおよび単一使用タイマの保有を含むことができる。パッケージをインストールさせ、またはアセットスキャンを行わせるのは、メッセージのコンテンツである。したがって、ポリシーが有用であるためには、メッセージが時間と関連することを知る必要がある。

パッケージをインストールするために、パッケージモジュールを提供することができる。このアクションは、エージェントとコントローラとでは非常に異なり、それをここで詳細に述べる。パッケージは、最初はグローバルアップデートリポジトリ(GUR : Global Update Repository)上に存在することができる。エージェントがパッケージを要求したとき、コントローラは、パッケージをダウンロードし、それをエージェントへと中継する前にローカルにキャッシュすることができる。

パッケージ構造は少なくとも2つの部分、ヘッダとファイルを備えることができる。ヘッダは、パッケージのコンテンツ、パッケージをインストールする方法、およびインストールプロセスから予想される結果に関する情報のすべてを含むことができる。ファイルは、パッケージをインストールするために使用されるものである。諸例には、MSI実行可能ファイル、シェルスクリプトまたはバッチファイル、.tar.gzアーカイブ、およびunified diff.パッチファイルが含まれる。

2つのタイプのパッケージがあり得る。すなわち、カスタムパッケージ、およびGURパッケージである。カスタムパッケージは、ユーザにより、ユーザインターフェースから特定のコントローラへとアップロードされ得る。ユーザは、配布されるファイル、およびそのファイルを実行するために使用されるコマンドラインパラメータを指定することができる。カスタムパッケージは、次いで、ユーザインターフェースのカスタムパッケージ領域を介して配布することが可能になる。GURパッケージは、中心化されたGURチームにより作成され、GURを介してコントローラに配布され得る。

本発明の実施形態では、パッケージモジュールのデューティは、様々なインストール状態を表す以下で列挙されたパッケージの6個のリストを維持するように回る。

インストールの第1の状態は、「利用可能」である。スキャンモジュールは、ローカルシステムを走査し、利用可能なパッケージに関する情報をこのモジュールに送ることにより、利用可能なリストを取り込むことができる。パッケージは、スキャンモジュールの発見に基づいてエージェントに利用可能となり、それを、この文書において後でさらに詳細に述べる。あるパッケージがインストールされたリスト中にある場合、パッケージモジュールはスキャンモジュールのインテリジェンスに従い、そのパッケージを利用可能なものとして再リストする。これは、パッケージが環境の外側から移された場合に相当する。そのパッケージが、任意の他のリスト中に存在する場合、それを無視することができる。その他の場合、パッケージを、利用可能なリストに追加することができる。

インストールの第2の状態は、「スケジュールされている」ことである。ユーザインターフェースから、管理者は、特定のパッケージを、特定のデータに関して、特定の時間にインストールするように指定することができる。このようなパッケージは、利用可能なリストからスケジュールされたリストへと移すことができる。スケジュールされたリストに挿入されると、パッケージモジュールはポリシーモジュール中に新しいポリシーを作成することができる。スケジュールの期限が切れたとき、またはスケジュールされたパッケージに対して指定された時間が終了したとき、ポリシーモジュールは、パッケージモジュールに通知することができ、そのパッケージは保留リストに移動することができる。パッケージが、不可能なデータ(例えば、過去の)に対してスケジュールされた場合、エージェントは、スケジュールされた時間が経過した場合と同様に働き、そのパッケージを保留リストへ移動することができる。

インストールの第3の状況は、「待ち(waiting)」である。待ちリストは、「自動インストール」とマークされている利用可能なモジュールを含むことができる。「自動インストール」は、ウェブサイトで構成可能な特有のポリシーにより実施される。ユーザによる手動のアクションにより、または必要なエージェントに対するポリシーの期限が切れた場合、パッケージを待ちリストから保留リストへ移動することができる。

インストールの第4の状態は、「保留」である。保留リストは、コントローラから現在ダウンロードされているパッケージのすべてを含むことができる。すべての部分のダウンロードが完了したとき、パッケージは、処理リストへと移動させることができる。パッケージのすべての部分を取得することができない場合、取得されたものはエージェントでキャッシュすることができ、そのパッケージを失敗リストへと移動することができる。

インストールの第5の状態は、「処理」である。1つずつ、このリスト上のパッケージを、app-packファイルに記憶されたパラメータに従ってインストールすることができる。インストールが成功裡に完了すると、パッケージは、インストール済みリストへと移動させることができる。app-packヘッダ中に記憶されたパラメータごとに、インストールプロセスの何らかの部分が失敗した場合、インストールプロセスは終了し、パッケージは、失敗リストへと移動され得る。

インストールの第6の状態は「失敗」である。失敗リストは、全体のプロセス中の何らかの点で失敗したパッケージを含むことができる。この一例としては、要求パッケージがGUR上で見つからなかった場合である。他の例は、適正な実行コマンドが、app-pack中のスクリプトノードに割り当てられなかった場合である。他の例は、コントローラからエージェントへのパッケージの転送が中断され、再開できない場合である。この点からのパッチが失敗した場合、パッケージは再スケジュールされ、待ちとして再リストされ、または利用可能なリストに戻すことができる。

一般に使用されるモジュールに戻ると、コントローラパッケージモジュールをさらに提供することができる。パッケージに関するコントローラの役割は、GURから利用可能なパッケージをキャッシュし、ユーザインターフェースからアップロードされたカスタムパッケージを記憶し、また要求されたとき、パッケージヘッダおよびパッケージファイルをエージェントに送達することである。エージェントがパッケージを要求したとき、それが、キャッシュまたはカスタム記憶中で利用可能である場合、そのヘッダはすぐに返され、そのファイルを、HTTPまたはFTPなどの外部接続を介するダウンロードに対して利用可能にする。パッケージがローカルに存在しない場合、パッケージを、HTTPを介してGURに要求することができる。GURであってもそのパッケージを有していない場合、コントローラは、パッケージを発見できなかったことをエージェントに回答することができ、そのパッケージは失敗リストに移される。

アセットモジュールは、ローカルシステム上にどのようなハードウェアおよびソフトウェアコンポーネントがインストールされているかに関して報告することができる。アセットモジュールは、正確で、かつ一貫性のあるデータセットを維持するために、スキャンおよびパッケージモジュールにより使用され、またはそれを利用することができる。

スキャンモジュールは、ローカルシステム用としてどのパッケージを利用できるかをパッケージモジュールに報告することを担当することができる。スキャンモジュールは、ローカルシステムに基づき、パッケージを求めてどのように走査するかを詳細に示すスキャン定義ファイルを取得するために、パッケージモジュールを使用することができる。スキャンモジュールが適正なスキャン定義ファイルを受け取り、それにマップした後、スキャンプロセスは、任意のパッケージがエージェントに対して利用可能かどうかを判定することができる。

図1は、本発明の実施形態によるエージェントベースのシステムを示すブロック図である。各エージェント100a、100bは、ネットワークの異なるノードに存在することができる。コントローラ102は、中心に位置することができる。中心化されたコントローラ102は、動的にロードされたモジュールにより実行されるポリシーおよび手順を、エージェント100a、100bに送ることができる。エージェント100a、100bは、次いで、自律的に、モジュールに割り当てられたポリシーおよび手順に基づいて、割り当てられたモジュールを実行することができる。割り当てられたポリシーおよび手順が完了すると、エージェントは、コントローラ102に戻り、状況を報告することができる。

図2は、本発明の実施形態によるコンピュータシステムで、1つまたは複数のアプリケーションを実行するための方法を示す流れ図である。200で、エージェントを動作させることができるが、エージェントは補助モジュールを含んでいない。エージェントは、補助モジュールがロードされるまで、1つまたは複数のアプリケーションに関するいずれの情報も含まない。202で、1つまたは複数の補助モジュールをエージェント中にロードすることができ、その1つまたは複数の補助モジュールは、1つまたは複数のアプリケーションを実行するためのポリシーおよび/または手順を含む。204で、1つまたは複数のモジュール設定をエージェント中にロードすることができる。206で、エージェントを用いて、ポリシーおよび/または手順を実行することができる。この動作中、1つまたは複数のモジュール設定を、ポリシーおよび/または手順に適用することができる。エージェントは、主モジュールを含むことができ、また主モジュールおよび任意のロードされた補助モジュールは、3つのコンジットを用いて通信することができる。すなわち、主モジュールから補助モジュールへの通信用コンジット、補助モジュールから主モジュールへの通信用コンジット、また補助モジュールが診断情報を書き込むためのコンジットである。これらのコンジットは、全二重、および半二重接続を表すことができる。

この発明の諸実施形態およびアプリケーションが示されまた述べられてきたが、この開示の利益を有する当業者であれば、本明細書に記載の本発明の概念から逸脱することなく、上記で述べたものよりさらに多くの変更形態が可能であることが理解されるはずである。したがって、本発明は、添付の特許請求の範囲の趣旨以外のものに限定されることはない。

本発明の実施形態によるエージェントベースのシステムを示すブロック図である。 本発明の実施形態によるコンピュータシステムで、1つまたは複数のアプリケーションを実行するための方法を示す流れ図である。

符号の説明

100a エージェント
100b エージェント
102 コントローラ

Claims (16)

1. コンピュータシステムで1つまたは複数のアプリケーションを実行する方法であって、
   補助モジュールを含んでいないエージェントを動作させるステップと、
   前記1つまたは複数のアプリケーションを実行するためのポリシーおよび/または手順を含む1つまたは複数の補助モジュールを、前記エージェント中にロードするステップと、
   前記エージェントを用いて、前記ポリシーおよび/または手順を実行するステップと
   を含む方法。
2. 前記エージェントが、前記1つまたは複数の補助モジュールがロードされるまで、前記1つまたは複数のアプリケーションに関する情報を含んでいない、請求項1に記載の方法。
3. 1つまたは複数のモジュール設定を前記エージェント中にロードするステップをさらに含む、請求項1に記載の方法。
4. 前記実行するステップが、実行中に、前記1つまたは複数のモジュール設定を前記ポリシーおよび/または手順に適用するステップを含む、請求項3に記載の方法。
5. 前記エージェントが主モジュールを含む、請求項1に記載の方法。
6. 前記主モジュールおよび補助モジュールが、3つのコンジット、すなわち、前記主モジュールから前記補助モジュールへの通信用コンジットと、前記補助モジュールから前記主モジュールへの通信用コンジットと、前記補助モジュールが診断情報を書き込むためのコンジットとを用いて通信する、請求項5に記載の方法。
7. 前記コンジットが、全二重および半二重接続を表す、請求項6に記載の方法。
8. コンピュータシステムで1つまたは複数のアプリケーションを実行するための装置であって、
   主モジュールを含むエージェントと、
   前記1つまたは複数のアプリケーションを実行するためのポリシーおよび/または手順をそれぞれが含む1つまたは複数の補助モジュールと
   を備え、
   前記エージェントが、前記1つまたは複数の補助モジュールをロードし、かつ前記ポリシーおよび/または手順を実行するように構成される、装置。
9. コンピュータシステムで1つまたは複数のアプリケーションを実行するための装置であって、
   補助モジュールを含んでいないエージェントを動作させる手段と、
   前記1つまたは複数のアプリケーションを実行するためのポリシーおよび/または手順を含む1つまたは複数の補助モジュールを、前記エージェント中にロードする手段と、
   前記エージェントを用いて、前記ポリシーおよび/または手順を実行する手段と
   を備える装置。
10. 前記エージェントが、前記1つまたは複数の補助モジュールがロードされるまで、前記1つまたは複数のアプリケーションに関する情報を含んでいない、請求項9に記載の装置。
11. 1つまたは複数のモジュール設定を前記エージェント中にロードする手段をさらに備える、請求項9に記載の装置。
12. 前記実行する手段が、実行中に、前記1つまたは複数のモジュール設定を前記ポリシーおよび/または手順に適用する手段を含む、請求項11に記載の装置。
13. 前記エージェントが主モジュールを含む、請求項9に記載の装置。
14. 前記主モジュールおよび補助モジュールが、3つのコンジット、すなわち、前記主モジュールから前記補助モジュールへの通信用コンジットと、前記補助モジュールから前記主モジュールへの通信用コンジットと、前記補助モジュールが診断情報を書き込むためのコンジットとを用いて通信する、請求項13に記載の装置。
15. 前記コンジットが、全二重および半二重接続を表す、請求項14に記載の装置。
16. コンピュータシステムで1つまたは複数のアプリケーションを実行する方法を実施するために、マシンで実行可能な命令のプログラムを具体的に実施する、マシンで読取り可能なプログラム記憶デバイスであって、前記方法が、
    補助モジュールを含んでいないエージェントを動作させるステップと、
    前記1つまたは複数のアプリケーションを実行するためのポリシーおよび/または手順を含む1つまたは複数の補助モジュールを、前記エージェント中にロードするステップと、
    前記エージェントを用いて、前記ポリシーおよび/または手順を実行するステップと
    を含む、プログラム記憶デバイス。

Images