JP2005327239A - セキュリティ関連プログラミング・インターフェース - Google Patents

Abstract

【課題】 コンピューティング・システムのセキュリティを強化するために、イベントや他の情報の処理に関連付けられるインターフェースを提供すること。
【解決手段】 プログラミング・インターフェースは、新しいセキュリティ・ポリシーを複数のセキュリティ・エンジンに伝達することに関連付けられた第１の機能グループを含む。複数のセキュリティ・エンジンのそれぞれは、既存のセキュリティ・ポリシーをその新しいセキュリティ・ポリシーに置き換えるように構成される。さらに、このプログラミング・インターフェースは、各セキュリティ・エンジンが新しいセキュリティ・ポリシーを実装する準備が整ったことを示すインジケーションを伝達することに関連付けられた第２の機能グループを含む。
【選択図】 図７

Description

本願明細書で説明するシステムと方法は、コンピューティング・システムに関し、詳細には、セキュリティ関連イベントなどのイベントの処理や他の情報の処理に関連付けられるインターフェースに関する。

コンピュータ・システムは、普及の拡大が進んでおり、しばしば、ローカル・エリア・ネットワーク（ＬＡＮ）やインターネットなどのネットワークを経由して他のコンピュータ・システムと相互接続されている。電子メール（Ｅメール）、インスタント・メッセージング、オンライン・エンターテインメントなどの機能は、ネットワークに接続してのコンピュータ・システムの利用を促進する。これらの機能は、ユーザーが、たとえば、他のユーザーと通信したり、オーディオおよび／またはビデオのコンテンツを取り出したり、オンライン・ソースから商品やサービスを購入したりすることを可能にする。

このコンピュータ・システムの相互接続の増加は、悪意のあるユーザーによるコンピュータ・システムへの攻撃の可能性を増大させる。これらの攻撃には、（たとえば、他のユーザーのコンピュータを動作不能にしようとしたり、他のユーザーのコンピュータから情報を取得しようとしたり、他のコンピュータへの攻撃を開始しようとしたりする）悪意のあるプログラムを他のユーザーのコンピュータにインストールすることが含まれる。また、攻撃には、（たとえば、コンピュータに対して送信される要求の連続ストリームを生成することによって、）そのコンピュータの性能を大幅に低下させて、使用不能に追い込むことも含まれる。こうした攻撃は、コンピュータ・ユーザーにとって迷惑行為であり、結果として、データを損失したり、データを破損したり、コンピュータから機密データがコピーされたり、コンピュータが動作不能になったりする可能性がある。

そのような攻撃の被害（severity）を防止したり、最小限に抑えたりするために、各種のセキュリティ・プログラムやセキュリティ・サービスが開発されている。これらのプログラムやサービスは、コンピュータ・システム上で実行され、そのコンピュータ・システムを悪意ある攻撃から保護する。そのようなプログラムの例として、アンチ・ウィルス・プログラムやファイア・ウォール・プログラムなどがある。通常、このようなプログラムやサービスは、特定タイプの攻撃を防ぐことを目的としている。たとえば、アンチ・ウィルス・プログラムはコンピュータ・ウィルスのロードおよび／または実行を防ぎ、ファイア・ウォール・プログラムは、コンピュータへの外部ユーザーの不正アクセス（許可されていないアクセス）を防ぐ。

これらの異なるプログラム同士は互いに通信しないのが普通である。たとえば、アンチ・ウィルス・プログラムは、通常、ウィルスを検出した事実をファイア・ウォール・プログラムに伝えない。したがって、コンピュータ・システム内の各種セキュリティ・プログラムは、そのコンピュータ・システムに対して特定の攻撃があったことを知ることができない。そこで、コンピュータ・システム内の各種のコンポーネントやセキュリティ・プログラムの間で、セキュリティ・ポリシーやイベント情報を伝達し合うことを可能にするインターフェースを提供することが望ましいことになる。

本願明細書で説明するシステムと方法は、コンピューティング・システムのセキュリティを強化するために、イベントや他の情報の処理に関連付けられるインターフェースを提供する。

特定の実施形態では、プログラミング・インターフェースは、新しいセキュリティ・ポリシーを複数のセキュリティ・エンジンに伝達することに関連付けられた第１の機能グループを含む。複数のセキュリティ・エンジンのそれぞれは、既存のセキュリティ・ポリシーをその新しいセキュリティ・ポリシーに置き換えることができる。さらに、このプログラミング・インターフェースは、各セキュリティ・エンジンの、新しいセキュリティ・ポリシーを実装する準備ができていることのインジケーションを伝達することに関連付けられた第２の機能グループを含む。

複数の図面を通して使用した類似の参照符号は、同様のコンポーネントおよび／または機能を参照している。

本願明細書で説明するシステムと方法は、１つまたは複数のプログラムやサービスで生成されるイベントなど、種々の情報を処理する。さらに、コンピューティング・システム内の種々のコンポーネントおよびプログラムの間でセキュリティ関連情報などの情報を伝達し合うことを可能にするインターフェースについて説明する。このコンピューティング・システムは、セキュリティ・エンジンや他のコンピューティング・システムなど、複数のソースイベントや他の情報を受け取るイベント・マネージャを含む。セキュリティ・エンジンの例として、アンチ・ウィルス・エンジン、ファイア・ウォール・エンジン、侵入（intrusion）検知エンジンなどがある。イベント・マネージャは、特定のソースから受け取ったイベント情報を、その情報を利用する可能性のある１つまたは複数のセキュリティ・エンジンに伝達して、コンピューティング・システムのセキュリティ・レベルを向上させる。

本願明細書で説明する特定の例はセキュリティ関連イベントや他のセキュリティ関連情報を参照するが、代替実施形態は任意のタイプのイベントや情報を処理できる。この情報には、ホスト・コンピュータ内のセキュリティ関連コンポーネントで利用される可能性のあるあらゆる情報が含まれる。代替実施形態は、ホスト・コンピュータのセキュリティに必ずしも関連していない情報を受取、処理し、配布することができる。本願明細書では、「インターフェース」、「プログラム・インターフェース」、「アプリケーション・プログラム・インターフェース（ＡＰＩ）」の各用語を区別なく使用している。

イベント処理
図１は、種々のイベントが生成および処理される環境１００の一例を示している。イベントの例としては、コンピュータ・ウィルスの検出、機密データへのアクセス試行の検出、コンピュータ・ウィルスを破壊したことの通知、特定のアプリケーション・プログラムが停止していることや実行を妨げられていることの通知、システム状態情報の変更、などがある。ホスト・コンピュータ１０２は、ネットワーク１０８を経由して複数のサーバー１０４および１０６に接続される。ホスト・コンピュータ１０２とサーバー１０４および１０６には、図９を参照して後述する装置など、任意のタイプのコンピューティング装置を使用できる。ネットワーク１０８には、ローカル・エリア・ネットワーク（ＬＡＮ）、ワイドエリア・ネット・ワーク（ＷＡＮ）、インターネットなど、任意のタイプのデータ通信ネットワークを使用できる。図１は２台のサーバー１０４および１０６に接続されたホスト・コンピュータ１０２を示しているが、ホスト・コンピュータ１０２は、ホスト・コンピュータとの通信が可能な任意の数のサーバーや他の装置に接続できる。

環境１００は、家庭、企業、学校、研究所などにおけるネットワーク設定のように種々の設定（setting）のどれでも表すことができる。たとえば、サーバー１０４は企業内ＬＡＮ上のサーバー装置であることが可能であり、ホスト・コンピュータ１０２は企業内ＬＡＮ上のデスクトップまたはポータブルのコンピューティング装置であることが可能である。また、別の例として、サーバー１０４はインターネット上のサーバー装置であることが可能であり、ホスト・コンピュータ１０２は、ユーザーの家庭のデスクトップ・コンピューティング装置であることも可能である。

ホスト・コンピュータ１０２は、ホスト・コンピュータ１０２に対する攻撃の監視、検出、対応など、各種のセキュリティ関連機能を実行するセキュリティ・モジュール１１０を含む。セキュリティ・モジュール１１０は、３つのセキュリティ・エンジン１１４、１１６および１１８に接続されたイベント・マネージャ１１２を含む。セキュリティ・エンジンには、悪意のあるユーザーおよび／または悪意のあるプログラムからの保護を支援する任意のサービスがあてはまる。セキュリティ・エンジン１１４〜１１８は、ソフトウェア、ハードウェアまたはソフトウェアとハードウェアの組合せとして実装できる。個々のセキュリティ・エンジンは、アンチ・ウィルス・プログラムや侵入検知プログラムなどのセキュリティ関連アプリケーション・プログラムである。セキュリティ・エンジン１１４〜１１８を「サービス」と呼ぶこともできる。ある特定のセキュリティ・モジュール１１０は、イベント・マネージャ１１２に接続された任意の数のセキュリティ・エンジンを含むことができる。さらにセキュリティ・モジュール１１０は、セキュリティ関連ポリシー・リーダーや他のポリシー・ハンドリング・メカニズムなど、他のモジュール、コンポーネントまたはアプリケーション・プログラム（図示せず）も含むことができる。

セキュリティ・モジュール１１０は、システム状態情報１２０およびシステム構成情報１２２にも接続される。システム状態情報１２０は、ホスト・コンピュータ１０２の現在の動作状態または動作モードに関する情報を含む。システム構成情報１２２は、ホスト・コンピュータ１０２の構成に関する情報を含む。システム状態情報１２０およびシステム構成情報１２２は、メモリ装置やハードディスク・ドライブなどの不揮発性ストレージ装置に格納できる。一実施形態では、イベント・マネージャ１１２およびセキュリティ・エンジン１１４〜１１８は、システム状態情報１２０とシステム構成情報１２２を受け取ることができる。

さらにホスト・コンピュータ１０２は、ホスト・コンピュータ１０２や他の装置にある各種のコンポーネントやプログラムの間でセキュリティ・ポリシーやイベント情報を伝達し合うことを可能にするアプリケーション・プログラム・インターフェース（ＡＰＩ）１２４を含む。たとえば、ＡＰＩ１２４は、コンポーネントやプログラムがセキュリティ・エンジン１１４〜１１８やイベント・マネージャ１１２と通信してセキュリティ関連情報をやりとりすることを可能にする。ＡＰＩ１２４はさらに、たとえば、新しいセキュリティ・エンジンのロード、既存のセキュリティ・エンジンのアンロード、セキュリティ・エンジンへのセキュリティ・ポリシーの送付、セキュリティ・エンジンへのデータ変更の伝達、ユーザーとセキュリティ・エンジンとの対話、セキュリティ・エンジンの集中化した構成管理、などを促進する。ＡＰＩ１２４に関しては後で詳細に説明する。

図１には示していないが、さらに別のデータ・ソースやデータ・プロバイダがセキュリティ・モジュール１１０およびイベント・マネージャ１１２に情報やイベントを伝達できる。この別のデータは、たとえば、ＩＩＳ（Internet Information Service）に関連する構成情報、システム管理アプリケーションから提供されるデータ、システム・レジストリに格納されているデータ、ユーザーまたはシステム管理者から提供される情報などである。

各セキュリティ・エンジン１１４〜１１８は、悪意のあるユーザーやアプリケーション・プログラムから、ホスト・コンピュータ１０２を安全にするのを支援するために、特定のセキュリティ関連機能を実行する。これらの悪意のあるユーザーやアプリケーション・プログラムは、ホスト・コンピュータ１０２またはホスト・コンピュータ１０２の機能を動作不能にしようとしたり、ホスト・コンピュータ１０２からデータ（たとえば、パスワードなどの機密情報）を取得しようとしたり、ホスト・コンピュータ１０２を使用（他のコンピュータ・システムへの攻撃を支援するなど）しようとしたりする可能性がある。たとえば、セキュリティ・エンジン１１４はコンピュータ・ウィルスを検出し、セキュリティ・エンジン１１６はファイア・ウォール保護を提供し、セキュリティ・エンジン１１８は１つまたは複数のユーザー特権または特性に基づいて特定アプリケーション・プログラムの実行を阻止（block）する。この例では、セキュリティ・エンジン１１４は、コンピュータ・ウィルス（computer viruses）、ワーム（worms）、トロイの木馬（Trojan horses）などの感染からホスト・コンピュータ１０２を保護する。また、ファイア・ウォール保護には、ネットワーク接続経由での他の装置からのアクセスからホスト・コンピュータ１０２を保護することが含まれる。特定アプリケーション・プログラムの実行阻止には、適切な特権を持たないユーザーがホスト・コンピュータ１０２上でアプリケーション・プログラムを実行するのを防ぐことが含まれる。さらに、ネットワークへの不正なアクセスやストレージ装置への不正なアクセスなどの不正な動作を検出した場合に、アプリケーション・プログラムの実行を阻止できる。

他の実施形態では、１つまたは複数のセキュリティ・エンジンが侵入検知や脆弱性分析を実行できる。侵入検知には、たとえば、悪意のあるアプリケーション・プログラムおよび／またはユーザーがホスト・コンピュータ１０２にいつアクセスしたかを識別することや、適切なアクションにより、ユーザーや管理者に通知したり、悪意のあるアプリケーション・プログラムを動作不能にしたり、悪意のあるユーザーのアクセスを停止させたりすることが含まれる。脆弱性分析には、たとえば、正しくインストールまたは更新されていないセキュリティ・エンジンあるいはコンポーネント、正しく構成されていないセキュリティ・エンジンあるいはコンポーネント、インストールされていないパッチやホット・フィックス、長さや使用文字の要件を満たしていないパスワード、などに起因する、ホスト・コンピュータ１０２の脆弱性を検出することを試みることが含まれる。個々のセキュリティ・エンジン１１４〜１１８は、イベント・マネージャ１１２に接続されている他のセキュリティ・エンジンの存在や機能を認識しなくてよい。

各セキュリティ・エンジン１１４〜１１８は、イベント（たとえば、コンピュータ・ウィルスの検出、ホスト・コンピュータ１０２からデータを取得する試行の検出、ユーザーによるアプリケーション・プログラムの実行の防止など）をイベント・マネージャ１１２に伝達する。これらのイベントには、セキュリティ・エンジンが収集した情報、セキュリティ・エンジンが実行したアクション、イベント・マネージャが１つまたは複数のデータ・ソースから収集したデータ、などが含まれる。情報の例として、特定のインストールにおいてインスタンス化されたすべての仮想サーバーのリストが含まれる。イベント・マネージャ１１２は、これらのイベントを処理し、個々のイベントに含まれる情報を、その情報から恩恵を得る可能性がある他のセキュリティ・エンジン１１４〜１１８に伝達する。

セキュリティ・モジュール１１０は、さらに、１つまたは複数のルールおよび各種データを含むセキュリティ関連ポリシーを受け取る。イベント・マネージャ１１２は、そのルールを適切なセキュリティ・エンジン１１４〜１１８に配布し、必要に応じてデータをセキュリティ・エンジンに提供する。各セキュリティ・エンジン１１４〜１１８は、イベント・マネージャ１１２から受け取ったこれらのルールおよびデータを格納する。セキュリティ・モジュール１１０、イベント・マネージャ１１２およびセキュリティ・エンジン１１４〜１１８の動作については、後で詳細に説明する。

図２は、データおよびルールを含むセキュリティ・ポリシー２００の一例を示している。一実施形態では、セキュリティ・ポリシー２００はセキュリティ・モジュール１１０に格納される。特定のセキュリティ・モジュールは、任意の数の様々なデータ・ソースから任意の数の様々なセキュリティ・ポリシー２００を受取、格納することができる。あるいは、セキュリティ・ポリシー２００を、ホスト・コンピュータ１０２内にある別のモジュールまたはコンポーネントに格納できる。図２の例では、セキュリティ・ポリシー２００のデータ部分２０２は、１つまたは複数のデータ要素を含む。図２に示すように、これらの要素は、変数に割り当てられた値を含む（たとえば、変数「Ａ」には値「１」が割り当てられ、変数「Ｂ」には値「４」が割り当てられている）。代替実施形態では、図２に示すデータの代わりに、あるいは図２に示すデータに加えて、他のタイプのデータを含めることもできる。セキュリティ・ポリシー２００に含まれるデータは、たとえば、セキュリティ・ポリシー２００に含まれる１つまたは複数のルールで使用されたり、１つまたは複数の他のセキュリティ・ポリシーに含まれる１つまたは複数のルールで使用されたりする。

また、セキュリティ・ポリシー２００は、複数のルールを収容するルール部分２０４も含む。セキュリティ・ポリシー２００に含まれるルールは、１つまたは複数のセキュリティ・エンジンに関連付けることができる。たとえば、特定のルールを、特定のセキュリティ・エンジンにのみ適用されるようにできる。これらのルールは、各ルールが関連付けられるセキュリティ・エンジンに基づいてセキュリティ・ポリシー２００内に配置することができる。あるいは、各ルールに関連付けられた識別子によって、そのルールを適用できるセキュリティ・エンジンを識別することができる。特定の実施形態では、１つのルールを任意の数のセキュリティ・エンジンに関連付けることができる。他の実施形態では、特定のルールを適用するセキュリティ・エンジンをホスト・コンピュータに含めないことも可能である。この状況では、そのルールはどのセキュリティ・エンジンにも関連付けられない。

図２の例では、これらのルールは、ＩＦ−ＴＨＥＮ構造を使用して定義されている。これ以外に、ルールのセットは様々な異なる形式をとることができる。図２に示すＩＦ−ＴＨＥＮ構造を使用すると、ルールは、特定の条件（複数）と、対応する特定のアクション（複数）または結果（複数）を定義する。ルールの執行中にその特定の条件が検出されると、それに対応する特定のアクションまたは結果が実行される。ルールは、様々な異なる条件とそれに対応するアクションまたは結果を特定することができる。条件の例として、リソース（たとえば、メモリ・ロケーション、ネットワーク・アドレスまたはポート、他のプログラム、ストレージ装置内のファイルなど）に対するアクセス試行、特定ロケーション（たとえば、メモリ内の特定ロケーション、ストレージ装置内の特定ロケーションなど）に対するデータ書き込み試行、特定プログラムの実行試行、ホスト・コンピュータ１０２の現在の動作状態の各種態様、などがある。結果の例として、リソースへのアクセスの防止、特定ロケーションへのデータ書き込みの防止、プログラムの実行防止、ルールにある条件の発生が検出されたことの通知の生成（たとえば、その発生をログに記録する、ユーザーや他のコンピュータにメッセージを送る）、などがある。特定の結果が、防止でなく、性質として許可である場合もある。たとえば、結果は、ホスト・コンピュータ１０２によってルールにある条件が満たされた場合のみ特定のリソースまたはロケーションにアクセスできることを示したり、ホスト・コンピュータ１０２によってルールにある条件が満たされた場合のみ特定のプログラムを実行できることを示したりできる。

さらにルールの例として、特定のディレクトリまたはフォルダにあるデータ・ファイルの更新を特定のアプリケーション・プログラムまたはサービスに許可すること、ＦＴＰ（ファイル転送プロトコル）が有効な場合にポート２１でのトラフィックの受信を可能にすること、特定のウィルス・シグネチャが検出された場合にウィルス警告メッセージを生成すること、などがある。他の例として、特定のアプリケーション・プログラムが特定のリビジョン・レベルにアップグレードされていない場合にイベントを生成すること、そのアプリケーション・プログラムが最低限のリビジョン・レベルにもアップグレードされていない場合にネットワークにアクセスするのを防ぐこと、ホスト・コンピュータがネットワークポート３５経由でデータを受信するのを防ぐこと、などがある。

図３は、各種セキュリティ・エンジンから要求されるデータに関して、セキュリティ・モジュールによって保持されるテーブル３００の一例を示す図である。一実施形態では、テーブル３００は、セキュリティ・モジュール１１０に格納される。あるいは、テーブル３００を、ホスト・コンピュータ１０２内にある別のモジュールまたはコンポーネントに格納できる。セキュリティ・エンジンがセキュリティ・モジュールにデータを要求するたびに、セキュリティ・モジュールは、テーブルを更新して（必要な場合）、そのデータ要求を取り込む。テーブル３００の第１列３０２は、特定のデータ要素、変数などの識別子や情報など、を示している。テーブル３００の第２列３０４は、そのデータ要素を以前に要求したセキュリティ・エンジンを示している。たとえば、テーブル３００は、データ要素「Ａ」が以前にセキュリティ・エンジン「１」から要求されたことを示している。同様に、データ要素「Ｄ」は、以前にセキュリティ・エンジン「１」、「４」、および「６」から要求されている。後で詳細に説明するように、テーブル３００に格納される情報は、更新されたデータをどのセキュリティ・エンジンが受け取るべきかを指定するために、セキュリティ・モジュールによって使用される。

図４は、セキュリティ・ポリシーのルールおよびデータを取得して配布する手続４００の一実施形態を示すフロー図である。手続４００は、たとえば、ホスト・コンピュータの初期化直後に実行することができる。最初にセキュリティ・モジュールが、そのホスト・コンピュータ用のセキュリティ・ポリシーを取得する（ブロック４０２）。イベント・マネージャが、そのセキュリティ・ポリシーの中で、各セキュリティ・エンジンに関連するルールを識別する（ブロック４０４）。イベント・マネージャは次に、そのルールを、該当するセキュリティ・エンジンに伝達する（ブロック４０６）。

各セキュリティ・エンジンが、関連付けられたルールを適用するために必要なデータを、たとえば、セキュリティ・エンジンが適用するルールに含まれるデータ要素を識別することによって、識別する（ブロック４０８）。各セキュリティ・エンジンは次に、識別したデータをイベント・マネージャに要求する（ブロック４１０）。イベント・マネージャは、セキュリティ・エンジンからデータ要求を受け取った後、要求されたデータ要素を、今後の参照のために、テーブル（たとえば、図３のテーブル３００）または他のデータ構造に記録する（ブロック４１２）。最後にイベント・マネージャが、要求されたデータを探し出し、要求しているセキュリティ・エンジンにそのデータを提供する（ブロック４１４）。このように、イベント・マネージャは、すべてのデータをすべてのセキュリティ・エンジンに提供するのではなく、要求されたデータを、要求している各セキュリティ・エンジンに提供する。

図５は、更新されたセキュリティ・ポリシー・データを処理する手続５００の一実施形態を示すフロー図である。最初にセキュリティ・モジュールが、更新されたデータを受け取る（ブロック５０２）。たとえば、更新されたデータは、既存の変数の更新値を含む場合がある。セキュリティ・モジュールは、更新されたデータを以前に要求していた、１つまたは複数のセキュリティ・エンジンを識別する（ブロック５０４）。一実施形態では、セキュリティ・モジュールは、図３に示すテーブル３００のようなテーブルを使用してこれらのセキュリティ・エンジンを識別する。セキュリティ・モジュールは、該当するセキュリティ・エンジンを識別した後、識別した各セキュリティ・エンジンに更新されたデータを提供する（ブロック５０６）。最後にセキュリティ・エンジンが、更新されたデータでセキュリティ・エンジンのデータ要素を更新する（ブロック５０８）。手続５００は、更新されたデータをセキュリティ・モジュールが受け取るたびに、繰り返される。別の実施形態では、セキュリティ・モジュールが定期的に、データが更新されているかどうか、各種データ・ソースをチェックする。データが更新されていたら、セキュリティ・モジュールがその更新されたデータを取得し、手続５００に従ってそのデータを配布する。

一実施形態では、ルールが更新されると、セキュリティ・モジュールが、そのルールに関連付けられたセキュリティ・エンジンを識別し、その識別したセキュリティ・エンジンに、更新されたルールを配布する。セキュリティ・モジュールは、新しいルールを受け取ると、その新しいルールを使用する可能性があるセキュリティ・エンジンを識別し、該当するセキュリティ・エンジンにその新しいルールを配布する。同様に、既存のルールが削除されると、セキュリティ・モジュールは、そのルールに関連付けられたすべてのセキュリティ・エンジンからそのルールを削除する。別の実施形態では、ルールが更新されると、セキュリティ・モジュールが、（更新されたルールを含む）新しいルール・セットを作成し、この新しいルール・セットをセキュリティ・エンジンに配布する。これによって、セキュリティ・エンジンにある既存のルールが置き換えられる。

図６は、１つまたは複数のセキュリティ・エンジンに、情報（イベント情報やシステム状態情報など）を配布する処理を行う手続６００の一実施形態を示すフロー図である。最初にイベント・マネージャが、セキュリティ・エンジンからイベントを受け取る（ブロック６０２）。イベント・マネージャは次に、そのイベントに含まれる情報、イベント・タイプやそのイベントを引き起こした攻撃の性質など、を識別する（ブロック６０４）。さらにイベント・マネージャは、そのイベントに含まれる情報を利用する可能性のある他のセキュリティ・エンジンを識別する（ブロック６０６）。種々のセキュリティ・エンジン同士の関係は、たとえば、ホスト・コンピュータが受け取るセキュリティ・ポリシーの中で指定される。これらの関係は、セキュリティ・ポリシーの作成時にシステム管理者または他のシステム・オペレータが、全体として、または部分的に定義できる。

イベント・マネージャは次に、そのイベントに含まれる情報を、識別したセキュリティ・エンジンに提供する（ブロック６０８）。識別されたセキュリティ・エンジンは次に、受け取った情報を適用する（ブロック６１０）。このようなイベント情報の共有（または相互依存）により、悪意のある攻撃に対してホスト・コンピュータによって提供されるセキュリティのレベルを強化する。イベント情報の共有は、個々のセキュリティ・エンジンがホスト・コンピュータ内の他のセキュリティ・エンジンのことを認識する必要がないように、イベント・マネージャによって管理される。本願明細書で説明するセキュリティ関連情報は中央ロケーションに格納できるので、他の装置、コンポーネント、およびアプリケーション・プログラムなどからその情報にアクセスすることが可能である。たとえば、他のセキュリティ・エンジンやコンピューティング・システムが、その格納されているセキュリティ関連情報にアクセスできる。

手続６００の一例では、アンチ・ウィルス・セキュリティ・エンジンが、特定のポートを経由して繰り返されるネットワークへのアクセス試行を検出する。このアンチ・ウィルス・セキュリティ・エンジンは、この情報（たとえば、アクセス試行の日時やアクセス試行に使用されたポート）をイベント・マネージャに報告する。この例では、アンチ・ウィルス・セキュリティ・エンジンは、そのようなアクセス試行に反応する役目を負っていない。イベント・マネージャは、アンチ・ウィルス・セキュリティ・エンジンから情報を受取、侵入検知セキュリティ・エンジンとファイアウォール・セキュリティ・エンジンがそのような情報を使用できることを決定する。侵入検知セキュリティ・エンジンとファイアウォール・セキュリティ・エンジンは、その情報を受け取った後、受け取った情報に基づいてそれぞれの動作を調整することができる。たとえば、侵入検知セキュリティ・エンジンは、侵入者をチェックする頻度を高めることができる。また、ファイアウォール・セキュリティ・エンジンは、そのアクセス試行に使用されたポートを一時的に無効にすることができる。このように、複数のセキュリティ・エンジンがセキュリティ関連イベントに関する共有情報に基づいてそれぞれの動作を調整できるようにすることで、攻撃に対するホスト・コンピュータの全体的なセキュリティが高まる。

手続６００の別の例では、脆弱性セキュリティ・エンジン（vulnerability security engine）が、ホスト・コンピュータに特定のパッチがインストールされているかどうかを調べる。そのパッチがインストールされていない場合は、脆弱性セキュリティ・エンジンが、そのパッチがインストールされていないことを示すイベントを生成する。ホスト・ファイアウォール・セキュリティ・エンジンとビヘイビア・ブロック・セキュリティ・エンジン（behavioral blocking security engine）は、そのパッチがインストールされていない場合の通知を、イベント・マネージャに登録する。ホスト・ファイアウォール・セキュリティ・エンジンとビヘイビア・ブロック・セキュリティ・エンジンは、パッチがインストールされていないという通知を受け取ると、パッチが施されていないアプリケーション・プログラムの機能を制限するルール（または実行させないようにするルール）を執行する。

別の実施形態では、セキュリティ・モジュール内の各種コンポーネント間（たとえば、イベント・マネージャと複数のセキュリティ・エンジンとの間））でシステム状態情報が共有される。システム状態情報は、種々のデータ・ソースから提供を受けることができる。システム状態情報の例として、現在のネットワーク状態、ネットワーク接続が有線か無線かの情報、ホスト・コンピュータがアクセスしているのは企業内ネットワークか未知のネットワークかの情報、ホスト・コンピュータの構成情報などがある。このように、１つのセキュリティ・エンジンが特定のシステム状態情報を識別すると、その識別した情報を、他のセキュリティ・エンジンおよびホスト・コンピュータ内の他のコンポーネントやモジュールとの間で共有できる。

特定の実施形態では、各種コンポーネントによって収集されたシステム状態情報が中央ロケーションに格納される。これによって、他の装置、コンポーネント、アプリケーション・プログラムなどからその情報にアクセスできるようになる。たとえば、あるセキュリティ・エンジンが収集したシステム状態情報には、他のセキュリティ・エンジン、セキュリティ・モジュールおよびコンピューティング・システムからアクセスできる。

セキュリティ・ポリシーの更新
前述のとおり、セキュリティ・ポリシーを使用して、たとえばセキュリティ・エンジンやセキュリティ・プロバイダによって適用されるルールを記述することができる。セキュリティ・ポリシーに変更が加えられると、更新されたルールが各種セキュリティ・エンジンに供給され、これらの各種セキュリティ・エンジンはほぼ同時に、更新されたルールの使用を開始するように切り替わる。

図１を参照して説明したコンポーネント、プログラムおよびモジュールのほかに、ホスト・コンピュータ１０２は、１つまたは複数のソース装置（サーバー１０４および１０６など）からセキュリティ・ポリシーを受け取る。このセキュリティ・ポリシーは、ホスト・コンピュータ１０２上の各種セキュリティ・エンジンがどのように動作すべきかを記述している。図１ではホスト・コンピュータ１０２を１台だけ示しているが、複数のホスト・コンピュータ１０２が同じソース装置からセキュリティ・ポリシーを取得できることを理解されたい。

ソース装置の例として、デスクトップ（ワークステーション）コンピューティング装置、サーバー・コンピューティング装置、ポータブル（ハンドヘルド）コンピューティング装置、ゲーム・コンソール、ネットワーク機器、携帯電話、携帯情報端末（ＰＤＡ）、ネットワーキング装置（たとえば、ルーター、ゲートウェイ、ファイア・ウォール、無線アクセス・ポイントなど）などがある。

ホスト・コンピュータ１０２は、さらに、ポリシー・リーダー・モジュール、ルール・マネージャ、ルール・セット・ジェネレータ・モジュールおよびダイナミック・ルール・データ・ストアを含むことができる。これらのモジュールの１つまたは複数を結合して単一モジュールにしたり、かつ／またはこれらのモジュールの１つまたは複数を分割して２つまたはそれ以上のモジュールにしたりできることを理解されたい。

一般に、セキュリティ・エンジン１１４〜１１８が執行しているセキュリティ・ポリシーを更新するには、まず、ポリシー・リーダー・がソース装置からセキュリティ・ポリシーを取得する。ルール・セット・ジェネレータが、その新しく取得したセキュリティ・ポリシーを使用して、各種セキュリティ・エンジンのそれぞれに向けて、１つまたは複数のルールのセットと関連データを生成する。これらのルール・セットは次に、各種セキュリティ・エンジンに伝達され、関連データはダイナミック・ルール・データ・ストアに格納される。関連データもセキュリティ・エンジンに伝達することができる。各セキュリティ・エンジンは、１つまたは複数のルールのセットを受け取るとすぐに、その新しいルール・セットを処理して、その新しいルール・セットを使用する準備を整える。ただし、各セキュリティ・エンジンは、新しいルール・セットに切り替えるよう指示されない限り、現在のルール・セットを使用し続ける。ルール・マネージャが、各セキュリティ・エンジンから、各セキュリティ・エンジンが新しいルール・セットに切り替える準備が整ったことのインジケーションを受信すると、ルール・マネージャは、すべてのセキュリティ・エンジンに対し、新しいルール・セットに切り替えるよう指示する。

特定の実施形態では、ルール・マネージャが、ホスト・コンピュータ１０２におけるセキュリティ・ポリシーの更新を調整する。ルール・マネージャは、種々のセキュリティ・エンジンが新しいルール・セットに切り替える準備を整えたことのインジケーションをそのセキュリティ・エンジンから受信し、新しいルール・セットの使用を開始すべきときに、そのセキュリティ・エンジンにインジケーション（指示）を渡す。

ポリシー・リーダー・モジュールは、新しいセキュリティ・ポリシーをソース装置から取得する。ポリシー・リーダー・モジュールは、新しいセキュリティ・ポリシーがソースにおいて使用可能になっているかどうかを、定期的に、または不定期にチェックするよう構成できる。あるいは、ポリシー・リーダー・モジュールは、他のあるコンポーネント（たとえば、ルール・マネージャ、ソース装置、または図１に示されていない他のある装置）から、新しいセキュリティ・ポリシーをソースから取得するよう指示（indication）を受けることができる（または、新しいセキュリティ・ポリシーがソースにおいて使用可能になっているかどうかをチェックするよう指示を受けることができる）。ポリシー・リーダーは、取得しようとする特定のセキュリティ・ポリシーをソースに対して指定できる。あるいは単に、そのホスト・コンピュータ向けの最も新しいセキュリティ・ポリシーをソースに対して要求できる。最も新しいセキュリティ・ポリシーがホスト・コンピュータ上で既に執行されているかどうかを判別するために、ホスト・コンピュータで現在使用しているセキュリティ・ポリシーと、最も新しいセキュリティ・ポリシーとを比較することができる。このような比較は、ソース、ポリシー・リーダー、あるいは他のコンポーネントで行うことができる。

ソースから新しいセキュリティ・ポリシーが取得されると、ルール・セット・ジェネレータが、個々のセキュリティ・エンジン１１４〜１１８のそれぞれに向けてルール・セットを生成する。ホスト・コンピュータ１０２でセキュリティ・ポリシーが執行されているときには、個々のセキュリティ・エンジンはそれぞれ異なるルールを使用できる。たとえば、あるセキュリティ・エンジン１１４がファイア・ウォールであり、別のセキュリティ・エンジン１１６がアンチウィルス・コンポーネントである場合がある。セキュリティ・ポリシーは、アンチ・ウィルス・エンジン専用のルールを識別でき（したがって、ファイア・ウォール・エンジンはそれらを無視してよい）、また、ファイア・ウォール・エンジン専用のルールも識別できる（したがって、アンチ・ウィルス・エンジンはそれらを無視してよい）。

特定の実施形態では、セキュリティ・ポリシー自体がルールのリストと関連データになる。また、セキュリティ・ポリシーは、どのルールとデータがどのセキュリティ・エンジン向けかの指定を含むこともでき、一方、（たとえば、どのルールがどのセキュリティ・エンジン向けかの判別をホスト・コンピュータにゆだねることにより）そのような指定を含まないことも可能である。このセキュリティ・ポリシーは、設計者が、ホスト・コンピュータの保護に関与するすべてのルールを、異なるセキュリティ・エンジンごとに、異なるレコードまたはファイルにルールを振り分けることなく、単一のレコードまたはファイルにまとめることを可能にする。

さらに、設計者は、本願明細書で説明する技法を使用して、特定の攻撃から保護する役割をあるセキュリティ・エンジンから別のセキュリティ・エンジンにシフトする新しいセキュリティ・ポリシーを、用意することができる。たとえば、特定タイプの攻撃からの保護を、あるセキュリティ・ポリシーではアンチ・ウィルス・プログラムによって実施し、新しいセキュリティ・ポリシーではファイア・ウォール・プログラムによって実施するように変更することができる。設計者は、本願明細書で説明する技法を使用することにより、この役割シフトがすべてのセキュリティ・エンジンにおいてほぼ平行して行われるようにでき、これによって、シフト中の攻撃に対するホスト・コンピュータの脆弱性を低減することができる。

ルール・セット・ジェネレータは、どのルールと関連データ（もしあれば）がどのセキュリティ・エンジンで使用されるかを、セキュリティ・ポリシーに基づいて識別する。ルール・セット・ジェネレータは、セキュリティ・エンジンごとに、そのセキュリティ・エンジン向けのルール・セットを生成し、その生成したルール・セットをそのセキュリティ・エンジンが使用できるようにする（たとえば、ルール・セットをセキュリティ・エンジンに送信したり、セキュリティ・エンジンに、生成したルール・セットを取得できるメモリ内のロケーションを通知したりすることができる）。この生成は、様々な異なる方法で行うことができる。たとえば、セキュリティ・エンジンで執行されている現在のルールに関係なく、新しいルール・セットをルール・セット・ジェネレータで生成できる。また、別の例として、現在のルール・セットと新しいルール・セットの相違点を取り込むように、現在のルール・セットを修正または変更できる。また、ルール・セット・ジェネレータは、セキュリティ・ポリシーからルールを単純にコピーしたり、ルールを記述しているセキュリティ・ポリシーの情報に基づいてルールを生成したりすることができる。

特定の実施形態では、セキュリティ・ポリシーは、どのルールをどのセキュリティ・エンジンに配布すべきかを特定する。たとえば、各ルールをある特定のラベルまたは識別子（たとえば、「Ｓｅｃｕｒｉｔｙ Ｅｎｇｉｎｅ １」や「Ａｎｔｉｖｉｒｕｓ ｅｎｇｉｎｅ」など）に関連付けることができる。ルール・セット・ジェネレータは、各種セキュリティ・エンジン向けのルール・セットを生成する際に、これらの識別子を使用できる。代替実施形態では、ルール・セット・ジェネレータは、どのルールをどのセキュリティ・エンジンに配布すべきかを推測できる。他の実施形態では、これらの技法を組み合わせて使用できる（たとえば、一部のルールについては、セキュリティ・ポリシーが割当て先のセキュリティ・エンジンを特定することが可能でありし、他のルールについては、ルール・セット・ジェネレータが割当て先のセキュリティ・エンジンを推測することが可能である）。

ルール・セット・ジェネレータで生成されたルール・セットは、様々な異なる形式をとることができる。特定の実施形態では、これらのルールは、前述したｉｆ−ｔｈｅｎ構造に従う。この構造を使用すると、ルールは、特定の条件と、対応する特定のアクションまたは結果を定義する。ルールの執行中にその特定の条件が検出されると、それに対応する特定のアクションまたは結果が実行される。様々な条件および対応する結果のすべてが、ルールによって識別できる。個々の条件の例として、特定リソース（たとえば、メモリ・ロケーション、ネットワーク・アドレスまたはポート、他のプログラム、ストレージ装置内のファイルなど）に対するアクセス試行、特定ロケーション（たとえば、メモリ内の特定ロケーション、ストレージ装置内の特定ロケーションなど）に対するデータ書き込み試行、特定プログラムの実行試行、ホスト・コンピュータの現在の動作状態の各種態様（たとえば、リソース使用可能、プログラム実行中など）などがある。個々の結果の例として、リソースへのアクセスを防止すること、特定ロケーションへのデータ書き込みを防止すること、プログラムの実行を防止すること、ルールにある条件の発生が検出されたことの通知を生成すること（たとえば、その発生をログに記録する、ユーザーや他のコンピュータにメッセージを送るなど）、がある。個々の結果が、性質として防止でなく許可である場合もある。たとえば、結果は、ホスト・コンピュータによりルールにある条件が満たされた場合のみ特定のリソースまたはロケーションにアクセスできることを示したり、ホスト・コンピュータによりルールにある条件が満たされた場合のみ特定のプログラムを実行できることを示したりすることができる。

特定の実施形態では、ホスト・コンピュータ１０２は、セキュリティ・エンジンによって執行されている各種ルールに関連付けられたデータであるダイナミック・ルール・データ・ストアを含む。特定の実施形態では、ダイナミック・ルール・データ・ストアは、２つのデータ・セットを含むことができる。１つのセットは、セキュリティ・エンジンによって執行されている現在のルールに使用されているセットであり、もう１つのセットは新しいルールのセットであり、執行しようとしてセキュリティ・エンジンが更新されているルールのセットである。新しいセキュリティ・ポリシーが受け取られると、ルール・セット・ジェネレータが、セキュリティ・エンジンに渡された新しいルール・セットに関連付けられたデータを使用して、ダイナミック・ルール・データ・ストアを更新する。

各セキュリティ・エンジンは、ルール・セット・ジェネレータから１つまたは複数のルールのセットを受け取るルール変更モジュールを含む。ルールに関連付けられたデータは、ルールとともにルール・セット・ジェネレータから受け取ることができる。あるいはルール変更モジュールが、必要なデータをダイナミック・ルール・データから取得できる。また、ルール・セット・ジェネレータがセキュリティ・ポリシーに基づいて各セキュリティ・エンジン向けのルール・セットを生成することを既に説明したが、そのほかに、各セキュリティ・エンジンが、ルール・セット・ジェネレータからルール・セットを受け取る代わりに、セキュリティ・ポリシー全体（またはセキュリティ・ポリシーの大部分）を受取、独自のルール・セットを生成することができる点に注意されたい。

ルール変更モジュールは、新しいポリシーを執行する新しい内部ルールを生成するために、必要に応じて新しいルール・セットを処理する。新しい内部ルールを生成するための新しいルール・セットの処理とは、新しいルール・セットをセキュリティ装置によって執行できる状態にするために、セキュリティ・エンジンが実行しなければならないすべてのアクションを指す。たとえば、この処理には、新しいルール・セットを内部フォーマットに変換すること、ルールをメモリ内の特定ロケーションに格納すること、ルールを特定の配列または順序に整理することなどが含まれる。ルール変更モジュールは、様々な方法で新しいルールを生成できる。たとえば、ルールを、ルール・セット・ジェネレータから受け取ったときと同じフォーマットで保管したり、セキュリティ・エンジンで使用する内部フォーマットに変換したりできる。

新しいルールがどのように生成されるかにかかわらず、各セキュリティ・エンジンは、これまでのホスト・コンピュータ用セキュリティ・ポリシー（更新されるセキュリティ・ポリシー）を執行する現在のルール・セットを保持する。新しいルールの生成中および新しいルールが生成された後でも、セキュリティ・エンジンは現在のルールを執行し続ける。セキュリティ・エンジンは、（たとえば、ルール・マネージャによって）新しいルールを執行するよう指示されない限り、新しいルールの執行を開始しない。

ルール変更モジュールは、新しいルールの生成を終了した後、ルール・マネージャに対して、新しいルールの生成を終了したことと、新しいルールを使用する切替え準備が整ったこと（したがって、新しいセキュリティ・ポリシーの執行を開始すること）を知らせる。ルール・マネージャは、そのような知らせをすべてのセキュリティ・エンジンから受け取った後、各セキュリティ・エンジンに対し、新しいルールの使用を開始するように指示する。ルール・マネージャがすべてのセキュリティ・エンジンから知らせを受け取るまで、ルール・マネージャは、各セキュリティ・エンジンに対して新しいルールの使用を開始するよう指示するのを待つ。各セキュリティ・エンジンは、開始するように指示されると、新しいルールの使用を開始する。セキュリティ・エンジンは、新しいルールの使用を開始するとすぐに、それまで使用していたルールを削除することができるようになる。

状況によっては、セキュリティ・エンジンが新しいルールの処理に失敗する可能性がある。その場合、セキュリティ・エンジンは、その失敗の知らせをルール・マネージャに返す。あるいは、ルール・マネージャは、セキュリティ・エンジンからの応答に制限時間を課すことができる。その制限時間内に、新しいルールの使用を開始する準備が整ったことを知らせる応答を、すべてのセキュリティ・エンジンがしない場合、ルール・マネージャは、１つまたは複数のセキュリティ・エンジンが新しいルールの処理に失敗したと見なすことができる。

ルール・マネージャは、１つまたは複数のセキュリティ・エンジンが新しいルールの処理に失敗したことを識別した場合には、どのセキュリティ・エンジンにも新しいルールの使用開始を指示しない。逆に、ルール・マネージャは、新しいルールへの切替えを中止するよう指示を送る（このことをロール・バックと呼ぶ場合もある）。その中止またはロール・バックの指示は、各セキュリティ・エンジンに対し、ルール・セット・ジェネレータから受け取った新しいルールおよびその処理の結果であるすべての新しいルールを無視し、現在のルールを使用し続けるよう伝える。特定の実施形態では、セキュリティ・エンジンが、そのような中止またはロール・バックの指示に応答して、生成した（または生成しつつある）新しいルールを安全に削除できる。

特定の実施形態では、各セキュリティ・エンジンは、新しいルールの使用を開始できることがほぼ確実になってから、新しいルールの使用を開始する準備が整ったことをルール・マネージャに伝える。言い換えると、セキュリティ・エンジンは、新しいルールの執行を開始するよう指示されたときに新しいルールの執行開始に失敗することはほぼありえないという、新しいルールの処理上のポイントにセキュリティ・エンジンがなるまで、ルール・マネージャに対して、新しいルールの使用を開始する準備が整ったことを伝えることを待つ。特定の実施形態では、これは、新しいルール・セットを生成し、使用するいずれかのルール・セット（古いルールか新しいルール）にポインタを保持するセキュリティ・エンジンによって達成される。セキュリティ・エンジンは、新しいルール・セットを生成した後、ルール・マネージャに対し、新しいルール・セットの使用を開始する準備が整ったことを伝える。その後、新しいルール・セットの使用を開始するよう指示されると、セキュリティ・エンジンは、単にそのポインタを古いルール・セットから新しいルール・セットに切り替えるだけでよい。セキュリティ・エンジンは、ほぼ確実に、セキュリティ・エンジンが、そのポインタを切り替えて新しいルールの使用を開始することができる、ことを保証する。「ほぼ確実」とは、失敗は絶対ありえないという１００％の保証を求めるものではないことを理解されたい。「ほぼ確実」であっても失敗につながる特定の状況が発生する可能性はある（たとえば、ポインタの切替えを妨げる停電やウィルス攻撃など）。しかしながら、そうした失敗の可能性が非常に小さいことも理解されたい。

ルール・マネージャは、様々な異なる方法のうちの任意の方法で、セキュリティ・エンジンに対し、新しいルール・セットの使用を開始する（「新しいルール・セットに切り替える」とも言う）よう指示できる。ただし、使用する方法は、すべてのセキュリティ・エンジンがほぼ同時に（本願明細書では「ほぼ平行して」とも言う）新しいルール・セットの使用を開始できるように、すべてのセキュリティ・エンジンにほぼ同時に通知するよう動作しなければならない。すべてのセキュリティ・エンジンに、ほぼ同時に新しいルール・セットの使用を開始させることにより、ルールの切替えに起因するホスト・コンピュータの脆弱性は軽減される。一般に、各セキュリティ・エンジンがそれぞれの新しいルール・セットの使用を開始するタイミングが近接するほど、新しいルール・セットへの切替え中の脆弱性は小さくなる。ルール・マネージャが複数のセキュリティ・エンジンに対してほぼ同時に、新しいルール・セットの使用を開始するよう指示を出す方法の、いくつかの例を以下に挙げる。

ルール・マネージャが複数のセキュリティ・エンジンに対して新しいルール・セットの使用を開始するよう指示を出す方法の１つは、すべてのセキュリティ・エンジンに対して一度に発行できるイベント・オブジェクトを使用する方法である。たとえば、各セキュリティ・エンジンは、ルール・セット・ジェネレータから新しいルールを受け取った後、（ホスト・コンピュータを保護している通常の動作中に）ルールがアクセスされるたびに特定イベントのポーリングを開始する内部フラグを立てる。そこで、ルール・マネージャは、セキュリティ・エンジンに対し、（セキュリティ・エンジンがポーリングしているのと同じ）イベントを発行することにより、新しいルール・セットの使用を開始するよう指示できる。したがって、そのイベントが発行された後に行われるポーリングによって必ず、イベントが発行されていることが検出され、それによって、ポーリングをしているセキュリティ・エンジンに、新しいルール・セットを使用すべきであることが伝えられる。たとえば、発行されているイベントの検出に応答して、セキュリティ・エンジン内のポインタを、新しいルール・セットをポイントするよう切り替えることができる。

イベントをポーリングするほかに、イベントに対して待機するスレッドをセキュリティ・エンジンで実行することもできる。イベントが発行されると、このスレッドが発行を検出し、それによってセキュリティ・エンジンに、新しいルール・セットを使用すべきであることが伝えられる。たとえば、イベントが発行されていることを検出したスレッドに応答して、セキュリティ・エンジン内のポインタを、新しいルール・セットをポイントするよう切り替えることができる。

イベントが発行され、新しいルール・セットが使用されると、セキュリティ・エンジンはイベントのポーリングを終了できる。また、イベントに対して待機するスレッドをセキュリティ・エンジンが実行していれば、そのスレッドを終了させることができる。

ルール・マネージャが複数のセキュリティ・エンジンに対して新しいルール・セットの使用を開始するよう指示する別の方法は、各セキュリティ・エンジンによって公開（expose）されている関数（たとえば、「ｓｗｉｔｃｈ（切替え）」関数）を呼び出す方法である。セキュリティ・エンジンのそのような関数を呼び出すことが、そのセキュリティ・エンジンに対し、新しいルール・セットの使用を開始するよう指示することになる。たとえば、セキュリティ・エンジンに対して呼び出されているそのような関数に応答して、セキュリティ・エンジンはそのポインタを、新しいルール・セットをポイントするよう切り替える。

ルール・マネージャが複数のセキュリティ・エンジンに対して新しいルール・セットの使用を開始するよう指示する別の方法は、各セキュリティ・エンジンがアクセスできる共有データ構造を各セキュリティ・エンジンに通知する方法である。ルール・マネージャは、たとえば、各セキュリティ・エンジンに対して関数（たとえば、「ｉｄｅｎｔｉｆｙ ｄａｔａ ｓｔｒｕｃｔｕｒｅ（データ構造識別）」関数）を呼び出したり、新しいルールがセキュリティ・エンジンに渡される際に共有データ構造を特定したりすることによって、様々なタイミングで各セキュリティ・エンジンに共有データ構造を知らせることができる。共有データ構造は、様々な異なる形式の中から任意の形式をとることができる。それらの形式には、メモリ内（たとえば、ＲＡＭ（ランダム・アクセス・メモリ）内やフラッシュ・メモリなどの不揮発性メモリ内）のロケーションや、ローカルまたはリモート・ストレージ装置に格納されたファイル、などがある。

各セキュリティ・エンジンは、（たとえば、（ホスト・コンピュータを保護している通常の動作中に）ルールがアクセスされるたびに）この共有データ構造をチェックしてその値を求める。ルール・マネージャは、共有データ構造に格納される値を変えることにより、各セキュリティ・エンジンに対し、新しいルール・セットの使用を開始するよう指示できる。たとえば、共有データ構造は、最初に、値「ｐｒｅｖｉｏｕｓ（前）」または値０を格納して、現在のルール・セットを使用すべきであると示すことができ、新しいルール・セットの使用を開始するよう切り替えるタイミングになると、ルール・マネージャが共有データ構造に値「ｎｅｗ（新）」または値「ｓｗｉｔｃｈ（切替え）」または値１を書き込んで、新しいルール・セットを使用すべきであることを指示することができる。

前述したように、ダイナミック・ルール・データ・ストアは、セキュリティ・エンジンによって執行されている各種ルールに関連付けられたデータを格納する。したがって、ホスト・コンピュータが新しいポリシーの執行を開始するよう更新されると、セキュリティ・エンジンで使用されるデータも変化する可能性がある。このデータは、ホスト・コンピュータの動作中も変化する可能性がある（たとえば、後からセキュリティ・エンジンがダイナミック・ルール・データ・ストアにデータを要求したり、ダイナミック・ルール・データ・ストアにデータを格納したりする可能性がある）。適切なデータがセキュリティ・エンジンに対して使用可能になるようにするために、ダイナミック・ルール・データ・ストアは、セキュリティ・ポリシーの更新時に、セキュリティ・エンジンと同様に動作することができる。すなわち、２つのルール・セット・データが保持され、１つのセットが切替え前に使用され、もう１つのセットが切替え後に使用される。その新しいほうのデータがダイナミック・ルール・データ・ストアに格納され、ダイナミック・ルール・データ・ストアは、新しいデータ・セットの使用を開始する準備が整ったときにルール・マネージャに通知を返す。そしてダイナミック・ルール・データ・ストアは、新しいデータ・セットの使用を開始するようルール・マネージャから指示を受けるまで、前のデータ・セットを使用し続ける。

ホスト・コンピュータ内の各種コンポーネントを、ホスト・コンピュータ上で実行される同じアプリケーション・プロセス内に実装できることに注目されたい。たとえば、ポリシー・リーダー、ルール・マネージャ、ダイナミック・ルール・データ、ルール・セット・ジェネレータおよびセキュリティ・エンジンをすべて、同じアプリケーション・プロセスに含めることができる。

あるいは、ホスト・コンピュータ内の異なるコンポーネントを、ホスト・コンピュータ上で実行される２つ以上のアプリケーション・プロセスに分けて実装することができる。たとえば、１つまたは複数のセキュリティ・エンジンを、他のセキュリティ・エンジンとも、ポリシー・リーダー、ルール・マネージャ、ダイナミック・ルール・データおよびルール・セット・ジェネレータとも別のプロセスで動作させることができる。異なるコンポーネントが異なるアプリケーション・プロセスで動作できるようにすると、たとえば、ホスト・コンピュータのセキュリティを強化するために、異なる開発者が異なるプラグイン・コンポーネント（たとえば、異なるプラグイン・セキュリティ・エンジン）を設計できるようになる。これらの追加プラグイン・コンポーネントは、他の非プラグイン・コンポーネントと同様に新しいポリシーを執行するようアップグレードされる。

複数のコンポーネントを複数のアプリケーション・プロセスに分ける場合、それらの各種コンポーネントが互いに通信できるようにするメカニズムが使用される。このような通信により、たとえば、新しいルール・セットとデータを異なる複数のプロセスにあるセキュリティ・エンジンに渡すことができ、データを異なる複数のプロセスにあるセキュリティ・エンジンからダイナミック・ルール・データに渡すことができ、新しいルール・セットの使用を開始させる指示を異なる複数のプロセスにあるセキュリティ・エンジンに渡すことができる。一例として、本願明細書で説明するコンポーネントは、ＣＯＭ（コンポーネント・オブジェクト・モデル）コンポーネントとして実装できる。ＣＯＭアーキテクチャに関する詳細は、Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ｒｅｄｍｏｎｄ、Ｗａｓｈｉｎｇｔｏｎから入手できる。

本願明細書の説明では、各セキュリティ・エンジンは、新しいルール・セットの使用開始をルール・マネージャから指示されることに注意されたい。そうしない場合でも、各セキュリティ・エンジンが実質的に同時に新しいルール・セットの使用を開始することを可能にする別の方法で、この指示を実現することが可能である。たとえば、ルール・マネージャを使用せずに、各セキュリティ・エンジンに新しいルール・セットの使用を開始するよう指示する制御メカニズムを、各種セキュリティ・エンジンのすべてに配布することができる。これを達成する方法として、たとえば、各セキュリティ・エンジンが、新しいルール・セットの使用を開始する準備が整ったことを他の各セキュリティ・エンジンに通知することとし、すべてのセキュリティ・エンジンが、新しいルール・セットの使用を開始する準備が整ったことを他のすべてのセキュリティ・エンジンに通知しない限り、どのセキュリティ・エンジンも新しいルール・セットの使用を開始しないとすることが考えられる。

図７は、セキュリティ・ポリシーを更新するプロセス７００の一例を示すフローチャートである。プロセス７００は、ホスト・コンピュータ上でセキュリティ・ポリシーの更新を調整しているコンポーネント、本願明細書で説明しているルール・マネージャなど、によって実装される。プロセス７００は、ソフトウェア、ハードウェア、ファームウェアまたはこれらの組合せで実行できる。

最初に、装置上で執行されるべき新しいポリシーを取得する（ブロック７０２）。ポリシーは「プル（pull）」方式で取得でき、この方式では、ホスト・コンピュータが新しいポリシーのソースにアクセスを開始し、新しいポリシーがそのソースから使用可能になっているかどうかをチェックする。また、ポリシーは「プッシュ（push）」方式でも取得でき、この方式では、新しいセキュリティ・ポリシーが使用可能であることについて、または新しいセキュリティ・ポリシーそのものについて（たとえば、メッセージあるいは他のインジケーションが）ホスト・コンピュータに通知される。

新しいポリシーをどのような方法で取得したかにかかわらず、いったん新しいポリシーを取得すると、その新しいポリシーに対する新しいルール・セットおよび／またはそのルールに関連付けられたデータを、各セキュリティ装置に提供する（ブロック７０４）。前述したように、各セキュリティ・エンジンに対して、新しいポリシーに基づく別々のルール・セットおよび／またはデータが生成されることになる。

次に、セキュリティ・エンジンから戻り値を受け取る（ブロック７０６）。特定の実施態様では、各セキュリティ・エンジンは、プロセス７００を実装しているコンポーネントに対して、「成功」を意味する値か、「失敗」を意味する値を返す。セキュリティ・エンジンが「成功」を意味する値を返した場合は、セキュリティ・エンジンが、受け取ったルール・セットおよび／またはデータの処理を完了し、その新しいルール・セットおよび／またはデータの使用を開始する準備が整ったことを表す。このことは、セキュリティ・エンジンが新しいルール・セットおよび／またはデータを実装する準備が整ったと言うこともできる。この後は、たとえば、セキュリティ・エンジンがポインタを、前のルール・セットではなく新しいルール・セットをポイントするよう切り替えるだけである。一方、セキュリティ・エンジンが「失敗」を意味する値を返した場合は、セキュリティ・エンジンが、受け取ったルール・セットおよび／またはデータを処理できなかった（または、しなかった）ため、セキュリティ・エンジンは新しいルール・セットおよび／またはデータの使用を開始することができないということになる。さらに、前述したように、セキュリティ・エンジンからの応答に制限時間（タイム・アウト値または時間しきい値とも言う）を課すことができる。この制限時間内にセキュリティ・エンジンが「成功」または「失敗」を意味する値で応答しない場合、プロセス７００を実装しているコンポーネントは、そのセキュリティ・エンジンを、「失敗」を意味する値を返したものとして扱う。

ルールを送ることと応答を受け取ること（ブロック７０４および７０６）は非同期プロセスであることを理解されたい。異なるセキュリティ・エンジンは、受け取ったルールおよび／またはデータの処理に要する時間も異なる場合があり、プロセス７００は単純に、すべてのセキュリティ・エンジンがそれぞれの処理を終了するのを待つ（制限時間が課されている任意の時間まで待つ）。

プロセス７００は、すべてのセキュリティ・エンジンが「成功（OK）」を意味する値を返したかどうかに基づいて先に進められる（ブロック７０８）。すべてのセキュリティ・エンジンが「成功」を意味する値を返した場合は、すべてのセキュリティ・エンジンが、新しいルール・セットの使用を開始する準備を整えており、したがって、すべてのセキュリティ・エンジンに、新しいルール・セットの使用を開始するよう指示する（ブロック７１０）。

一方、少なくとも１つのセキュリティ・エンジンが「成功」を意味する値を返さない場合は、各セキュリティ・エンジンに対してロール・バック呼出しを発行する（ブロック７１２）。このロール・バック呼出しは基本的に更新プロセスを中止させるので、どのセキュリティ・エンジンも（「成功」を意味する値を返したセキュリティ・エンジンであっても）、新しいルール・セットの使用を、依然として開始しないことになる。

図８は、セキュリティ・ポリシーを更新するプロセス８００の別の例を示すフローチャートである。プロセス８００は、装置上のセキュリティ・エンジン、図１のホスト・コンピュータ１０２上のセキュリティ・エンジン１１４〜１１８など、によって実装される。プロセス８００は、ソフトウェア、ハードウェア、ファームウェアまたはこれらの組合せで実行できる。

最初に、執行されるべき新しいポリシーの新しいルール・セットおよび／またはデータを受け取る（ブロック８０２）。前述したように、これらのルールおよびデータは、ほぼ同時に受け取ることができ、あるいは、セキュリティ・エンジンが必要に応じてデータ・ストア（たとえば、本願明細書で説明しているダイナミック・ルール・データ・ストア）からデータを取得できる。次に、これらの新しいルールおよび／またはデータを処理する（ブロック８０４）。新しいルールおよび／またはデータを処理することは、新しいセキュリティ・ポリシーの執行時にセキュリティ・エンジンが従う内部ルール・セットを（たとえば、そのセキュリティ・エンジンの内部フォーマットで）作成する。

プロセス８００は、ルールの処理が成功したかどうかに基づいて先に進められる（ブロック８０６）。セキュリティ・エンジンが、受け取ったルール・セットおよび／またはデータの処理を終了し、新しいルール・セットおよび／またはデータの使用を開始する準備を整えた場合は（たとえば、この後はセキュリティ・エンジンがポインタを、前のルール・セットではなく新しいルール・セットをポイントするよう切り替えるだけであれば）、処理は成功したことになる。そうでない場合は、処理が成功しなかったことになる。処理が成功した場合は、「成功」を意味する値が返される（ブロック８０８）。一方、処理が成功しなかった場合は、「失敗」を意味する値が返される（ブロック８１０）。ブロック８０８および８１０の戻り値は、ホスト・コンピュータ上でセキュリティ・ポリシーの更新を調整しているコンポーネント（たとえば、本願明細書で説明しているルール・マネージャ）に返される。

戻り値に関係なく、セキュリティ・エンジンは、ロール・バックを指示されるか、新しいルールの使用開始を指示されるまで、前の（古い）ルール・セットを使用し続ける（ブロック８１２）。新しいルールの使用を開始するよう指示された場合、セキュリティ・エンジンは、たとえば、ポインタを前のルール・セットから新しいルール・セットに切り替えることによって、新しいルールおよび／またはデータの使用を開始する（ブロック８１４）。新しいルールの使用開始の指示は、前述したように、セキュリティ・エンジンが、様々な方法のうちの任意の方法で取得できる。

一方、ロール・バックを指示された場合、セキュリティ・エンジンは、新しいルールおよび／またはデータを処理した結果をすべて破棄する（ブロック８１６）。この破棄は、セキュリティ・エンジンが、受け取った新しいルール・セットの処理を終了しているかどうかにかかわらず、実行できる。

したがって、図８からわかるように、セキュリティ・エンジンは、新しいルールに切り替える指示を受け取るまで、前のルール・セットを使用し続ける。そのような指示を受け取るまでに、セキュリティ・エンジンは新しいルールの使用を開始する準備を整えており、切替えにはほとんど時間を要しない。たとえば、セキュリティ・エンジンは、単にポインタを、前のルール・セットではなく新しいルール・セットをポイントするよう切り替えるだけでよい。

アプリケーション・プログラム・インターフェース（ＡＰＩ）
図１を参照して前述したＡＰＩ１２４などのＡＰＩは、ホスト・コンピュータ内の各種コンポーネントおよびプログラム（たとえば、セキュリティ・エンジン）の間でセキュリティ・ポリシーやイベント情報を伝達し合うことを可能にする。一実施形態では、ＡＰＩは、ＣＯＭ（コンポーネント・オブジェクト・モデル）を使用して定義される。ＡＰＩは、セキュリティ・エンジンをロードおよびアンロードしたり、セキュリティ・ポリシーをセキュリティ・エンジンに送付したり、セキュリティ・ポリシー・データの変更内容を当該セキュリティ・エンジンに伝達したり、ポリシーで指定される特定の動作を許可または拒否する意志決定時にホスト・ユーザーがセキュリティ・エンジンと対話することを可能にしたり、セキュリティ・エンジンの集中構成管理を行ったり、するメソッドをサポートする。

本願明細書で説明するシステムと手順（procedures）は、個々のコンピューティング・システムやコンピューティング・システムのグループをセキュリティ・ポリシーの対象にすることによって、コンピューティング・システムのセキュリティを集中管理することを可能にするものである。また、これらのシステムと方法は、それらのコンピューティング・システムや他のデータ・ソースによって生成されるイベントや他の情報（セキュリティ関連イベントなど）を収集し、相互に関係付ける。

一実施形態では、本インターフェースは、認証された安全なプロトコルによって、セキュリティ・ポリシーやイベント・データベースへのクライアント・アクセスをサポートする。本インターフェースは、各種コンポーネント間の通信、またはアプリケーション・プログラムと１つまたは複数のセキュリティ・エンジンの間の通信、を可能にする。さらに本インターフェースは、セキュリティ・エンジン同士が通信したり、セキュリティ・エンジンと他の装置、コンポーネント、サービスまたはプログラムが通信したりする方法を定義する。

一実施形態では、本インターフェースは、カスタム・ローダを使用して、攻撃者がＣＯＭレジストリ値を変更してセキュリティ・エンジンを攻撃者自身のコードと取り替える可能性を減らす、ＣＯＭインターフェースとして定義される。

一実施例では、本ＡＰＩでサポートされる関数呼出しは次のとおりである。

エージェントからセキュリティ・エンジンへの関数呼出し（Agent-to-Security Engine Function Calls）
・Ｉｎｉｔｉａｌｉｚｅ
・Ｓｈｕｔｄｏｗｎ
・ＰｒｅｐａｒｅＰｏｌｉｃｙ
・ＣｏｍｍｉｔＰｏｌｉｃｙ
・ＲｏｌｌｂａｃｋＰｏｌｉｃｙ
・ＷｒｉｔｅＤａｔａ
・ＷｒｉｔｅＣｏｎｆｉｇ
これら７つの関数呼出しを「ＩＳｅｃｕｒｉｔｙＥｎｇｉｎｅインターフェース」と呼ぶ。
セキュリティ・エンジンからエージェントへの関数呼出し（Security Engine-to-Agent Function Calls）
・ＲｅａｄＡｎｄＲｅｇｉｓｔｅｒＮｏｔｉｆｙＤａｔａ
・ＷｒｉｔｅＳＥＤａｔａ
・ＵｎＲｅｇｉｓｔｅｒＮｏｔｉｆｙＤａｔａ
・ＧｅｔＤａｔａＡｔｔｒｉｂｕｔｅ
・ＲｅａｄＡｎｄＲｅｇｉｓｔｅｒＮｏｔｉｆｙＣｏｎｆｉｇ
・ＵｎＲｅｇｉｓｔｅｒＮｏｔｉｆｙＣｏｎｆｉｇ
・ＱｕｅｒｙＵｓｅｒ
・Ｃｏｍｐｌｅｔｅ
上記の最初の７つの関数呼出しを「ＩＳｅｃｕｒｉｔｙＡｇｅｎｔインターフェース」と呼び、最後の関数呼出し（Ｃｏｍｐｌｅｔｅ）を「ＩＡｇｅｎｔＣａｌｌｂａｃｋインターフェース」と呼ぶ。

関数呼出しは、「呼出し」、「メソッド」、「関数」または「サービス」とも呼ばれる。これらの関数呼出しの詳細については、後述する。代替実施形態では、追加の関数呼出しを使用したり、かつ／または本願明細書で説明する関数呼出しの１つまたは複数を省いたりできる。

一実施形態では、イベント・マネージャやセキュリティ・エージェントなどのエージェントがＡＰＩを介してセキュリティ・エンジンと通信する。エージェントは、「マネージャ」とも呼ばれる。特定の実施形態では、未処理のままになっているＡＰＩ呼出しがある場合、エージェントは特定のセキュリティ・エンジンを呼び出さない。非同期のＡＰＩ呼出しについては、このルールに例外がある。これらの場合、許可されるエージェントアクションは、後述の状態テーブルで定義される。

Ｉｎｉｔｉａｌｉｚｅ関数呼出し（Initialize Function Call）
このメソッドは、エージェントに知られているセキュリティ・エンジンごとに１回ずつ呼び出される。このメソッドは、エージェントの起動中に呼び出される。Ｉｎｉｔｉａｌｉｚｅ関数呼出しは、セキュリティ・エンジンをロードし、そのセキュリティ・エンジンが初期化動作を実行することを可能にする。

このメソッドは、エージェントによってセキュリティ・エンジンごとに次々に非同期に呼び出され、コール・バックは受け取られた際に処理される。エージェントは、すべてのコール・バックが完了するまで待機してから、先に進む。
このメソッドは次のように定義される。
HRESULT Initialize(
[in] ISecurityAgent *pAgent,
[in] IAgentCallback *pCallback);
ｐＡｇｅｎｔは、セキュリティ・エンジンがエージェントにコール・バックするために使用できるＣＯＭインターフェースである。
ｐＣａｌｌｂａｃｋは、後で定義するコール・バック・オブジェクトである。
Ｉｎｉｔｉａｌｉｚｅ関数呼出しが失敗したか、所定時間内に戻らなかった場合は、Ｓｈｕｔｄｏｗｎが呼び出されることになる。予想される競合条件のために、セキュリティ・エンジンは、Ｉｎｉｔｉａｌｉｚｅが戻る前にＳｈｕｔｄｏｗｎ処理を行う。

Ｓｈｕｔｄｏｗｎ関数呼出し（Shutdown Function Call）
このメソッドは、エージェントによって初期化（Initialize）するために呼び出されたセキュリティ・エンジンごとに１回ずつ呼び出される。このメソッドは、セキュリティ・エンジンが自らのシャット・ダウン処理を開始するのを可能にする。Ｉｎｉｔｉａｌｉｚｅが失敗した場合でも、エージェントはＳｈｕｔｄｏｗｎを呼び出して、セキュリティ・エンジンが、割り当てられていたすべてのリソースを閉じることを可能にする。たとえば、このメソッドは、ＤＬＬ＿ＰＲＯＣＥＳＳ＿ＤＥＴＡＣＨ処理中には実行できない複雑なシャット・ダウンをセキュリティ・エンジンが実行することを可能にする。

このメソッドは、完了までかなりの時間を要することがあるので、シャット・ダウン処理が完了したことを、コール・バック・オブジェクトを使用して知らせる。このメソッドがイン・プロセス・システムのシャット・ダウンの結果として呼び出された場合は、処理を完了するために使用できる時間が限られ、コール・バックが完了する前にシステムがエージェントを強制終了する場合がある。

このメソッドは次のように定義される。
typedef enum tagSHUTDOWN_TYPE
{
SHUTDOWN_NORMAL=0,
SHUTDOWN_SYSTEM
} SHUTDOWN_TYPE;

HRESULT Shutdown(
[in] SHUTDOWN_TYPE eType,
[in] IAgentCallback *pCallback);
ｅＴｙｐｅは、ＳＨＵＴＤＯＷＮ＿ＮＯＲＭＡＬまたはＳＨＵＴＤＯＷＮ＿ＳＹＳＴＥＭの列挙型である。
ｐＣａｌｌｂａｃｋは、後で定義するコール・バック・オブジェクトである。
ＤＬＬ Ｕｎｌｏａｄは、Ｓｈｕｔｄｏｗｎコール・バックが行われた後（またはタイム・アウトが発生した後）に発生することになる。コール・バックは非同期に行うことができるので、エージェントは、セキュリティ・エンジンＤＬＬのアンロードに進む前に、コール・バックを行ったスレッドが終了するまで、待機せざるを得ない場合がある。これにより、コール・バック・スタック・フレームは、アンロードされることになるＤＬＬの外側のポイントまでアンワインド（unwind）でき、プロセス内の例外を回避できる。コール・バックがＳｈｕｔｄｏｗｎ呼出し中に行われた場合は、セキュリティ・エンジン・スレッドがシャット・ダウンされると見なされるので、この余分なステップは不要になる。
エラーは動作中のイベントとしてログ記録されるが、エラー以外は無視される。これは、エージェント（Ａｇｅｎｔ）がまさにクローズ・ダウンされかかっているためである。

ＰｒｅｐａｒｅＰｏｌｉｃｙ関数呼出し（PreparePolicy Function Call）
このメソッドは、エージェントが更新されたポリシーを受け取ったときに、エージェントによって呼び出される。その結果としてポリシーがマージされ、各ＲｕｌｅＳｅｔが作成されて正しいセキュリティ・エンジンに渡される。ＸＭＬデータはＩＳｔｒｅａｍオブジェクトとして渡される。ＩＳｔｒｅａｍオブジェクトは、ＭＳＸＭＬ（Microsoft XML）（ＤＯＭ（Document Object Model）またはＳＡＸ（Simple API for XML））がＸＭＬデータを読み取るために使用できる。このメソッドは次のように定義される。
HRESULT PreparePolicy(
[in] IStream *pstreamRuleset,
[in] IAgentCallback *pCallback);
ｐｓｔｒｅａｍＲｕｌｅｓｅｔは、ＸＭＬ Ｒｕｌｅ Ｓｅｔの読み取りを可能にするＳｔｒｅａｍオブジェクトに対するＣＯＭインターフェースである。このＩＳｔｒｅａｍは、マシンに対してローカルであり、ネットワークを介してアクセスするデータではない、と見なすことができる。
ｐＣａｌｌｂａｃｋは、後で定義するコール・バック・オブジェクトである。
この呼出しがエラーを返した場合、セキュリティ・エンジンは、前に適用したポリシー（ブート時のポリシーの可能性がある）の実行を続けると見なされる。エージェントは、ＰｒｅｐａｒｅＰｏｌｉｃｙが成功しているすべてのセキュリティ・エンジンに対してＲｏｌｌｂａｃｋＰｏｌｉｃｙを呼び出すが、失敗しているセキュリティ・エンジンに対しては呼び出さない。このプロセスは、いずれかのセキュリティ・エンジンがエラーを返すと、ただちに開始される。さらに、ＰｒｅｐａｒｅＰｏｌｉｃｙコール・バックが所定時間内に到達しない場合、エージェントはこれをそのセキュリティ・エンジンの一部の障害として扱う。したがって、セキュリティ・エンジンは、ＰｒｅｐａｒｅＰｏｌｉｃｙ呼出しが返される前にエージェントがＲｏｌｌｂａｃｋＰｏｌｉｃｙを呼び出す可能性があることを想定している。

ＣｏｍｍｉｔＰｏｌｉｃｙ関数呼出し（CommitPolicy Function Call）
このメソッドは、ＰｒｅｐａｒｅＰｏｌｉｃｙ呼出しに対してすべてのセキュリティ・エンジンが成功を返したときに、エージェントによって呼び出される。この呼出しにより、セキュリティ・エンジンは新しいポリシーに切り替わる。このメソッドは次のように定義される。
ＨＲＥＳＵＬＴ ＣｏｍｍｉｔＰｏｌｉｃｙ（ｖｏｉｄ）；
この呼出しは同期的であり、エージェントは、１つの呼出しが完了してから次の呼出しを行う。一実施形態では、ポリシーの更新に失敗する可能性のある操作はすべてＰｒｅｐａｒｅＰｏｌｉｃｙ呼出しで実行されるており、ＣｏｍｍｉｔＰｏｌｉｃｙ呼出しは古いポリシーデータ構造から新しいポリシーデータ構造への単純な切替えである、との前提条件がある。

ＣｏｍｍｉｔＰｏｌｉｃｙメソッドは、セキュリティ・エンジンのＵｓｅｒ部分とＫｅｒｎｅｌ部分の間の通信障害などのような、破局的な障害を返す。万一この呼出しがエラーを返した場合、エージェントは前のポリシーをリロードして再適用しようと試みる。エラーが存在しているため、この試みは機能しない可能性があり、ポリシーの執行は不明の状態で放置されることになる。ＣｏｍｍｉｔＰｏｌｉｃｙが失敗した場合の動作中のエラーは、エージェントによってログ記録されることになる。

ＲｏｌｌｂａｃｋＰｏｌｉｃｙ関数呼出し（RollbackPolicy Function Call）
このメソッドは、セキュリティ・エンジンがそのＰｒｅｐａｒｅＰｏｌｉｃｙ呼出しに対してエラーを返した場合に、エージェントによって呼び出される。この呼出しは、エージェントが、更新を中止して、実施中のポリシーに復帰するように他のすべてのセキュリティ・エンジンに対して指示することを引き起こす。このメソッドは次のように定義される。
ＨＲＥＳＵＬＴ ＲｏｌｌｂａｃｋＰｏｌｉｃｙ（ｖｏｉｄ）；
この呼出しは、セキュリティ・エンジンでの予想されるロール・バック処理が、大量であり、ＰｒｅｐａｒｅＰｏｌｉｃｙの処理のほぼミラーリングであるという理由で、非同期である。セキュリティ・エンジンは、この呼出しの処理を完了すると、Ｃｏｍｐｌｅｔｅを呼び出して、ロール・バックのステータスを知らせる。

ポリシーがロール・バックされると、ＰｒｅｐａｒｅＰｏｌｉｃｙに従って登録されていたデータがすべて、エージェントによって登録解除され、システムは、各セキュリティ・エンジンが登録していた前のデータ・セットにロール・バックされる。この理由から、セキュリティ・エンジンは、エージェントからＣｏｍｍｉｔＰｏｌｉｃｙ呼出しを受け取るまで、不要になるデータのローカル・コピーを破棄しない。エージェントは、ポリシーのロール・バック中にセキュリティ・エンジンからのＲｅａｄＡｎｄＲｅｇｉｓｔｅｒＤａｔａ呼出しが到着するタイミング・ウインドウ（時間窓）を管理する役割がある。

ＲｏｌｌｂａｃｋＰｏｌｉｃｙとＣｏｍｐｌｅｔｅコール・バックは、破局的な障害を返す場合がある。セキュリティ・エンジンは、ロール・バックがサポートされるようなＰｒｅｐａｒｅＰｏｌｉｃｙを実装することが求められる。ＲｏｌｌｂａｃｋＰｏｌｉｃｙが失敗した場合は、動作中のエラーがエージェントによってログ記録される。これが発生した後の、そのセキュリティ・エンジンおよび協力しているセキュリティ・エンジンによるポリシーの執行の状態については、何の想定もできない。その後の更新されたポリシーは、そのセキュリティ・エンジンに送られ続けることになる。

ＷｒｉｔｅＤａｔａ関数呼出し（WriteData Function Call）
このメソッドは、セキュリティ・エンジンが以前にＲｅａｄＡｎｄＲｅｇｉｓｔｅｒＮｏｔｉｆｙＤａｔａを呼び出した対象のデータの一片が変化したときに、エージェントによって呼び出される。パラメータは、メモリの所有権がエージェントに属することを除き、ＲｅａｄＡｎｄＲｅｇｉｓｔｅｒＮｏｔｉｆｙＤａｔａ呼出しとほぼ同じであるので、セキュリティ・エンジンは、いったん処理されたアイテムを削除してはならない。

セキュリティ・エンジンがエージェントから新しいポリシーを受け取る処理の間、たとえば、ＰｒｅｐａｒｅＰｏｌｉｃｙ呼出しと、ＣｏｍｍｉｔＰｏｌｉｃｙ呼出しまたはＲｏｌｌｂａｃｋＰｏｌｉｃｙ呼出しとの間）は、ＷｒｉｔｅＤａｔａは呼び出されない。このときにエージェントが検出したデータ変更は、新しいポリシーがコミットまたはロール・バックされたときに、一括処理されて、当該セキュリティ・エンジンに送られる。保留中の更新のキューは、同じデータ片に対して複数の変更を連続して伝達することをできるだけ避けるよう、エージェントによって最適化される。ＷｒｉｔｅＤａｔａメソッドは次のように定義される。
#define DF_DYNAMIC 0x1
#define DF_COLLECTION 0x2
#define DF_BOOLEAN 0x4
#define DF PERSISTED 0x8

HRESULT WriteData(
[in] REFGUID guidDataID,
[in] DWORD dwFlags,
[in] DWORD dwDataSize,
[in] VARIANT varData,
[in] DWORD dwKeySize,
[in] byte *pbKeyValue);
キー（Ｋｅｙ）を渡すためのパラメータ（ｄｗＫｅｙＳｉｚｅ、ｐｂＫｅｙＶａｌｕｅ）は、前のクエリに関連付けられたコンテクストをセキュリティ・エンジンに戻すときに使用される。セキュリティ・エンジンは、このコンテクストを使用して、クエリの結果と、エージェントに対して発行した、前のＱｕｅｒｙＵｓｅｒ呼出しとを相互に関連付ける。この追加データが必要なのは、同じルール内の異なるコンテクストに対して特定のクエリが複合的に発生する場合があるからである（たとえば、アプリケーションＸがレジストリ値の変更を許容するかどうかをユーザーに尋ねた後、アプリケーションＹについて同じ質問をする場合がある）。

エラーはＯｐｅｒａｔｉｏｎａｌ Ｅｖｅｎｔｓとしてログ記録されるが、それ以外は無視される。同じデータ片に対するその後の更新は、失敗しているセキュリティ・エンジンにも引き続き通知されることになる。セキュリティ・エンジンは、これを防ぎたい場合、そのデータ片に対してＵｎＲｅｇｉｓｔｅｒＮｏｔｉｆｙＤａｔａを呼び出すことができる。

ＷｒｉｔｅＣｏｎｆｉｇ関数呼出し（WriteConfig Function Call）
このメソッドは、エージェントが構成データを当該セキュリティ・エンジンに配布することを可能にする。セキュリティ・エンジンがＲｅａｄＡｎｄＲｅｇｉｓｔｅｒＮｏｔｉｆｙＣｏｎｆｉｇメソッドを使用して構成データを読み取ると、このメソッドを呼び出しているエージェントがそのデータに対する変更をセキュリティ・エンジンに知らせる。このメソッドは次のように定義される。
HRESULT WriteConfig(
[in] WCHAR *wszDataName,
[in] VARIANT varData);
ｗｓｚＤａｔａＮａｍｅは、書き込まれる構成データ・アイテムのテキスト（Text）名であり、このデータのレジストリで使用される名前である。
ｖａｒＤａｔａは、その名前で表される単一データ・アイテムを格納するバリアント構造である。このデータは、レジストリにあるそのデータの型に応じて、様々なデータ型になる。エージェントではデータ型をチェックしないが、セキュリティ・エンジンでは、データ型が必要なので、コンテクストに従ってデータ型をチェックすることが求められる。

エラーはＯｐｅｒａｔｉｏｎａｌ Ｅｖｅｎｔｓとしてログ記録されるが、それ以外は無視される。同じ構成パラメータデータに対するその後の更新は、失敗しているセキュリティ・エンジンにも引き続き通知されることになる。セキュリティ・エンジンは、これを防ぎたい場合、そのデータ片に対してＵｎＲｅｇｉｓｔｅｒＮｏｔｉｆｙＣｏｎｆｉｇを呼び出さなければならない。

エージェントからのＡＰＩ呼出しが未処理のままになっている間は、特定のセキュリティ・エンジンがそのエージェントを呼び出すことはあまりない。エージェントはこれをエラーとして扱い、２つ目の呼出しを無視する。

ＲｅａｄＡｎｄＲｅｇｉｓｔｅｒＮｏｔｉｆｙＤａｔａ関数呼出し（ReadAndRegisterNotifyData Function Call）
このメソッドは、セキュリティ・エンジンが、ルールの処理で使用するために、ダイナミック・ルール・データ・サブシステムからデータを読み取ることを可能にする。いったんセキュリティ・エンジンがそのデータを読み取ると、そのデータに対する変更は、エージェントが、ＩＳｅｃｕｒｉｔｙＥｎｇｉｎｅインターフェースのＷｒｉｔｅＤａｔａメソッドを呼び出して、セキュリティ・エンジンに通知する。このメソッドは次のように定義される。
HRESULT ReadAndRegisterNotifyData(
[in] REFGUID guidDataID,
[out] DWORD *pdwFlags,
[out] DWORD *pdwDataSize,
[out] VARIANT *pvarData);
ｇｕｉｄＤａｔａＩＤは、取得するデータ・アイテムのＧＵＩＤである。
ｐｄｗＦｌａｇｓは、データ・アイテムを説明するフラグ・セットである。値の例として、ＤＹＮＡＭＩＣまたはＳＴＡＴＩＣ、ならびにＣＯＬＬＥＣＴＩＯＮまたはＢＯＯＬＥＡＮなどがある。
ｐｄｗＤａｔａＳｉｚｅは、バリアント・データで返される配列にあるデータ・アイテム（Data Items）の全体サイズである。
ｐｖａｒＤａｔａは、データ・アイテムの配列への参照か、Ｂｏｏｌｅａｎデータ型のデータ・アイテム値、を格納するバリアント構造である。バリアントは入力では空である。

もはやポリシー内にはないデータをセキュリティ・エンジンが要求するとエラーになる。エージェントは、あらゆるエラーに対してＯｐｅｒａｔｉｏｎａｌ Ｅｖｅｎｔを生成する。この場合、影響を受けるデータがセキュリティ・エンジンとエージェントとで矛盾のない表示（view）になっているという保証はない。

ＷｒｉｔｅＳＥＤａｔａ関数呼出し（WriteSEData Function Call）
このメソッドは、（存続のため、または他のセキュリティ・エンジンが使用するために）セキュリティ・エンジンが所有し、公開しているデータの一片が変化したときに、セキュリティ・エンジンによって呼び出される。パラメータは、メモリの所有権がセキュリティ・エンジンに属することを除き、ＷｒｉｔｅＤａｔａ呼出しとほぼ同じであるので、エージェントは、いったん処理されたアイテムを削除してはならない。このメソッドは次のように定義される。
HRESULT WriteSEData(
[in] REFGUID guidDataID,
[in] DWORD dwDataSize,
[in] VARIANT varData);
このメソッドは、いずれかのスレッドで別のＷｒｉｔｅＳＥＤａｔａ呼出しが未処理のままである間も含めて、いつでも呼び出すことができる。必要に応じてシリアル化（serialization）を保証するのはエージェントの役割である。

データ・アイテムの所有者は、コレクション定義内で、所有者を定義するＧＵＩＤによって識別される。これは、セキュリティ・エンジンのＧＵＩＤ、エージェントの識別子のＧＵＩＤ、あるいは別のコンシューマの識別子のＧＵＩＤである可能性がある。

セキュリティ・エンジンがその所有するコレクションを定義する場合、データはこのＡＰＩを介してエージェントに公開されると見なされる。

エージェントはあらゆるエラーをＯｐｅｒａｔｉｏｎａｌ Ｅｖｅｎｔとしてログ記録する。セキュリティ・エンジンは、エラーがあった後も更新の提供を続けるかどうかを決定できる。エラーがあった後は、そのデータのエージェント側のバージョンとセキュリティ・エンジン側の表示（view）とに矛盾がないという保証はない。

ＵｎＲｅｇｉｓｔｅｒＮｏｔｉｆｙＤａｔａ関数呼出し（UnRegisterNotifyData Function Call）
このメソッドは、セキュリティ・エンジンが、関係のなくなったデータ・アイテムに関するＷｒｉｔｅＤａｔａ通知の受取を中止することを可能にする。このメソッドは次のように定義される。
HRESULT UnRegisterNotifyData(
[in] REFGUID guidDataID);
ｇｕｉｄＤａｔａＩＤは、セキュリティ・エンジンにとって関係がなくなった変更通知の対象であるデータ・アイテムを識別するＧＵＩＤである。セキュリティ・エンジンは、ヌルＧＵＩＤ｛００００００００−００００−００００−００００００００００００｝を渡すことによって、現在の通知をすべて登録解除する意志を示すことができる。
エージェントはあらゆるエラーをＯｐｅｒａｔｉｏｎａｌ Ｅｖｅｎｔとしてログ記録する。これには、データがエージェントに認識されていないケースが含まれ、ポリシー管理のトラブルの診断に役立つ。

ＧｅｔＤａｔａＡｔｔｒｉｂｕｔｅ関数呼出し（GetDataAttribute Function Call）
このメソッドは、セキュリティ・エンジンが、データ・アイテムに関連付けられた特定の属性を取得することを可能にする。属性名は、テキストの場合も含め、Ｐｏｌｉｃｙ ＸＭＬにある名前と同じである。属性値は、ポリシーが変更された場合のみ変更される可能性があるので、このデータについては、通知システムは不要である。このメソッドは次のように定義される。
HRESULT GetDataAttribute(
[in] REFGUID guidDataID,
[in] WCHAR *wszAttributeName,
[out] VARIANT *pvarAttributeValue);
このメソッドはいつでも呼び出すことができる。
ｇｕｉｄＤａｔａＩＤは、属性を取得するデータ・アイテムを識別するＧＵＩＤである。
ｗｓｚＡｔｔｒｉｂｕｔｅＮａｍｅは、属性の名前であり、ポリシー・ドキュメント内にあるとおりである。
ｐｖａｒＡｔｔｒｉｂｕｔｅＶａｌｕｅは、バリアント（Variant）としての属性値である。通常の出力パラメータ割当てルールが適用される。エージェントは、新しいバリアント（Variant）に情報を割り当てる。これを後で解放するのは呼出し側の役割である。

ＲｅａｄＡｎｄＲｅｇｉｓｔｅｒＮｏｔｉｆｙＣｏｎｆｉｇ関数呼出し（ReadAndRegisterNotifyConfig Function Call）
このメソッドは、セキュリティ・エンジンがエージェントから構成データを読み取るのを可能にする。いったんセキュリティ・エンジンが構成データを読み取ると、そのデータに対する変更は、エージェントが、ＩＳｅｃｕｒｉｔｙＥｎｇｉｎｅインターフェースのＷｒｉｔｅＣｏｎｆｉｇメソッドを呼び出して、セキュリティ・エンジンに通知する。

エージェントとエージェントがホストするセキュリティ・エンジンの構成データは、共通ルートの下に配置できる。このメソッドは次のように定義される。
HRESULT ReadAndRegisterNotifyConfig(
[in] WCHAR *wszDataName,
[out] VARIANT *pvarData);
ｗｓｚＤａｔａＮａｍｅは、取得する構成データ・アイテムのテキスト（Text）名であり、このデータのレジストリで使用される名前である。これは、共通エージェント・ルートを基準として個々のアイテムを識別する。先頭の「＼」文字は不要である。この値の大文字と小文字は区別されないが、空白文字には意味がある。
ｐｖａｒＤａｔａは、その名前で表される単一データ・アイテムを格納するバリアント構造である。このデータは、レジストリにあるそのデータの型に応じて、様々なデータ型になる。エージェントではデータ型をチェックしないが、セキュリティ・エンジンでは、データ型が必要なので、コンテクストに従ってデータ型をチェックすることが求められる。

エージェントはあらゆるエラーをＯｐｅｒａｔｉｏｎａｌ Ｅｖｅｎｔとしてログ記録する。

ＵｎＲｅｇｉｓｔｅｒＮｏｔｉｆｙＣｏｎｆｉｇ関数呼出し（UnRegisterNotifyConfig Function Call）
このメソッドは、セキュリティ・エンジンが、関係のなくなったデータ・アイテムに関するＷｒｉｔｅＣｏｎｆｉｇ通知の受取を中止することを可能にする。このメソッドは次のように定義される。
HRESULT UnRegisterNotifyConfig(
[in] WCHAR *wszDataName);
ｗｓｚＤａｔａＮａｍｅは、セキュリティ・エンジンにとって関係がなくなった変更通知の対象である構成データ・アイテムを識別するテキスト（Text）名である。

エージェントはあらゆるエラーをＯｐｅｒａｔｉｏｎａｌ Ｅｖｅｎｔとしてログ記録する。これには、データがエージェントに認識されていないケースが含まれ、構成管理のトラブルの診断に役立つ。

ＱｕｅｒｙＵｓｅｒ関数呼出し（QueryUser Function Call）
このメソッドは、セキュリティ・エンジンがエージェントに要求して、特定のメッセージをユーザーに向けて表示させ、ユーザーが選択した答えを返させることを可能にする。エージェントはさらにこの答えをキャッシュすることが可能であり、エージェントが再起動してもその値を保持することができる。ユーザーに提示された質問には、そのユーザーにこの質問が向けられた理由に関する具体的な情報を含めることができる。この情報はセキュリティ・エンジンによって提供され、このメソッドが呼び出されるたびに異なるものにすることができる。この質問が以前に尋ねられたものかどうか、およびその答えは何かについて、エージェントがどのように結論付けるかは、セキュリティ・エンジンが提供するキー情報（Key Information）によって決まる。

この呼出しはただちにセキュリティ・エンジンに戻る。その後セキュリティ・エンジンは、応答の通知があるまで、このクエリをトリガしたセッション／スレッドの動作を一時停止する。通知が行われるのは、ユーザーが応答をキー入力したときか、クエリ（Ｑｕｅｒｙ）がタイム・アウトになったときである。タイム・アウト処理はエージェントによって行われる。この時点で、エージェントはキー入力された応答またはデフォルトの応答で関連データ・アイテムを更新し、その結果とそれに関連するコンテクストをセキュリティ・エンジンに通知する。

そのようなクエリに対する応答を取得することはタイム・クリティカルなので、このＡＰＩは、クエリの発行を必要とするルールを執行しているセキュリティ・エンジンによっていつでも呼び出すことができる。このメソッドは次のように定義される。
HRESULT QueryUser(
[in] REFGUID guidQueryItem,
[in] DWORD dwKeySize,
[in] byte *pbKeyValue,
[in] SAFEARRAY(VARIANT) pvarQueryParams);
ｇｕｉｄＱｕｅｒｙＩｔｅｍは、ユーザーに質問をし、その質問に対する可能な答えを提示することに使用される基本文字列を格納するデータ・アイテムのＧＵＩＤである。
ｄｗＫｅｙＳｉｚｅは、キー値（Key Value）の長さ（バイト単位）である。
ｐｂＫｅｙＶａｌｕｅは、このクエリの一意のキーを定義するバイト・セットである。

ｐｖａｒＱｕｅｒｙＰａｒａｍｓは、ユーザーに向けて表示されるクエリ・テキストに代入されるクエリ・パラメータを格納する、バリアント（Variants）のＳａｆｅａｒｒａｙである。そのパラメータの順序と構文は、このＱｕｅｒｙＵｓｅｒアクションが関連付けられたルール・タイプによって定義される。

データ・アイテムが識別不能の場合は、エージェントがエラーを返す。クエリの実行中のエラーは、Ｏｐｅｒａｔｉｏｎａｌ Ｅｖｅｎｔｓとしてログ記録される。その場合は、デフォルトのアクションがセキュリティ・エンジンに返される。

Ｃｏｍｐｌｅｔｅ関数呼出し（Complete Function Call）
このメソッドは、先の、エージェントからセキュリティ・エンジンへの非同期呼出しに関連付けられた処理をそのセキュリティ・エンジンが完了したことを、エージェントに通知する。特定のセキュリティ・エンジンが、エージェントからの複数の非同期呼出しを未処理のままにしておくことが、潜在的に可能だが、エージェントは各セキュリティ・エンジンの内部状態を、特定のＣｏｍｐｌｅｔｅコール・バックのコンテクストがあいまいであるように管理する。このメソッドは次のように定義される。
HRESULT Complete(
[in] HRESULT hrCompletionCode);
ｈｒＣｏｍｐｌｅｔｉｏｎＣｏｄｅは、エージェントが以前にこのセキュリティ・エンジンに対して行った非同期呼出しのリターン・コードである。

インターフェースの使用法（Interface Usage）
ここでは、これらのＡＰＩを使用して１つまたは複数のセキュリティ・エンジンと対話する方法に関する制約の例について説明する。

セキュリティ・エンジンは、ある特定の時点では、エージェントとの対話に関して、ある特定の状態にある。次のリストは、セキュリティ・エンジンのとりうる各状態を特定する。

エージェントとセキュリティ・エンジンの間で許容される対話は、セキュリティ・エンジンが特定の状態にあるときに各エンティティが呼び出すことのできるＡＰＩと、結果としてセキュリティ・エンジンがとるべき状態変化または他のアクション・ニーズを定義する一組のテーブルとして形式化することができる。エージェントの動作状態は重要でないと見なされ、セキュリティ・エンジンは、セキュリティ・エンジンがメモリにロードされている間、エージェントがずっと定常状態であると見なすことができる。

状態テーブルは、セキュリティ・エンジンのライフ・サイクルの以下のフェーズをカバーする。
・初期化
・エージェントからのポリシー更新
・シャット・ダウン

これらのテーブルでカバーされていない、ＡＰＩ呼出しとセキュリティ・エンジンの状態の組合せは、ＡＰＩの誤用と見なすことができる。そのような誤用を避けるのは、ＡＰＩの呼出し側の責任である。

次の状態テーブルは、セキュリティ・エンジンの初期化中に許容されるＡＰＩのシーケンスを定義する。セキュリティ・エンジンの状態は、エージェントからの入力に応じて変化する。セキュリティ・エンジンの初期化に関連付けられた状態のリストにおいて、許容された入力としてリストされていないＡＰＩの呼出しは、呼出し側のエンティティにおけるプロトコル・エラーということを意味している。

次の状態テーブルは、ポリシーの更新中に許容されるＡＰＩのシーケンスを定義し、関連するセキュリティ・エンジンの状態が変化する。ポリシーの更新に関連付けられた状態のリストにおいて、ここで許容される入力としてリストされていないＡＰＩの呼出しは、呼出し側のエンティティにおけるプロトコル・エラーということを意味する。

ホスト対象のセキュリティ・エンジンが複数あることを考慮した、ポリシー更新の全体のシーケンスの例を以下に示す。
１．各セキュリティ・エンジンのＰｒｅｐａｒｅＰｏｌｉｃｙが呼び出される。
２．各セキュリティ・エンジンがＣｏｍｐｌｅｔｅ（成功）またはＣｏｍｐｌｅｔｅ（失敗）を呼び出すのを、エージェントが待つ。
３．いずれかのセキュリティ・エンジンが失敗を報告した場合、他のすべてのセキュリティ・エンジンに対してＲｏｌｌｂａｃｋＰｏｌｉｃｙメソッドが呼び出されることになる。
４．失敗を報告するセキュリティ・エンジンがない場合は、各セキュリティ・エンジンに対してＣｏｍｍｉｔＰｏｌｉｃｙメソッドが呼び出される。
５．さらに失敗が見つかった場合、またはＣｏｍｍｉｔＰｏｌｉｃｙメソッドが呼び出される前にＳｈｕｔｄｏｗｎが必要になった場合は、各セキュリティ・エンジンに対してＲｏｌｌｂａｃｋＰｏｌｉｃｙメソッドが呼び出される。

次の状態テーブルは、セキュリティ・エンジンのシャット・ダウン中に可能なＡＰＩのシーケンスを定義する。セキュリティ・エンジンの状態は、エージェントからの入力に応じて変化する。セキュリティ・エンジンのシャット・ダウンに関連付けられた状態のリストにおいて、ここで可能な入力としてリストされていないＡＰＩの呼出しは、呼出し側のエンティティにおけるプロトコル・エラーということを意味する。

以下にリストしたのは、エージェントがサポートするコレクション・タイプの例と、各コレクションがＲｅａｄＡｎｄＲｅｇｉｓｔｅｒＮｏｔｉｆｙＤａｔａメソッド呼出しとＷｒｉｔｅＤａｔａメソッド呼出しによって動的データとして渡される方法に関する説明である。

以下で説明するデータ・アイテムの多くは、単一のＢＳＴＲ文字列を渡すことによって、あるいは符号なし整数をＬＯＮＧバリアント型またはＬＯＮＧＬＯＮＧバリアント型にパッキングすることによって、処理できる。このモデルに容易には適合しないアイテムは、ＤｉｒｅｃｔｏｒｙＳｅｔ、ＰｒｏｔｏｃｏｌＳｅｔおよびＩＰｖ４ＡｄｄｒｅｓｓＳｅｔである。これらの各タイプに対しては、データをＢＳＴＲ文字列にパッキングしてＳａｆｅＡｒｒａｙで容易に転送できるようにするパッキング・システムが提案されている。

ＦｉｌｅＳｅｔ
各アイテムに対して渡されるデータ：
Ｆｉｌｅｎａｍｅ（ファイル名）−文字列

実装：
ＢＳＴＲ

ＤｉｒｅｃｔｏｒｙＳｅｔ
各アイテムに対して渡されるデータ：
Ｄｉｒｅｃｔｏｒｙ Ｎａｍｅ（ディレクトリ名）−文字列
Ｒｅｃｕｒｓｉｖｅ（再帰）−フラグ

実装：
パッキングされたＢＳＴＲ −“再帰フラグ：文字列”

再帰フラグは単一文字−
「Ｒ」−再帰
「Ｆ」−フラット

ＲｅｇｉｓｔｒｙＳｅｔ
各アイテムに対して渡されるデータ：
Ｒｅｇｉｓｔｒｙ Ｋｅｙ Ｎａｍｅ（レジストリキー名）−文字列

実装：
パッキングされたＢＳＴＲ −“再帰フラグ：文字列”

再帰フラグは単一文字−
「Ｒ」−再帰
「Ｆ」−フラット

Ｐｒｏｔｏｃｏｌ
各アイテムに対して渡されるデータ：
Ｐｒｉｍａｒｙ ／ Ｓｅｃｏｎｄａｒｙ（プライマリまたはセカンダリ）−文字列または列挙
ＩＰ Ｔｙｐｅ（ＩＰタイプ）−文字列または列挙
Ｄｉｒｅｃｔｉｏｎ（方向）−文字列または列挙
Ｐｏｒｔ（ポート）またはＰｏｒｔ Ｒａｎｇｅ（ポート範囲）−１つまたは２つの整数（１６ビットの符号なし整数）

実装：
パッキングされたＬＯＮＧＬＯＮＧ：
１バイト−プライマリ／セカンダリ
１バイト−ＩＰタイプ（ＴＣＰ／ＵＤＰ）
１バイト−方向（入力／出力／入出力）
１バイト−未使用
２バイト−ポート範囲の終了（またはゼロ）
２バイト−ポート範囲の開始（またはポート）

ＰｒｏｃｅｓｓＳｅｔ
各アイテムに対して渡されるデータ：
Ｐｒｏｃｅｓｓ Ｎａｍｅ（プロセス名）またはＰａｔｈ（パス）−文字列

実装：
ＢＳＴＲ

ＮｅｔｗｏｒｋＰｏｒｔＳｅｔ
各アイテムに対して渡されるデータ：
Ｐｏｒｔ（ポート）またはＰｏｒｔ Ｒａｎｇｅ（ポート範囲）−１つまたは２つの整数（１６ビットの符号なし整数）

実装：
パッキングされたＬＯＮＧ： 開始＝下位ワード、終了＝上位ワード。
ポート範囲でない場合、上位ワードはゼロ。

ＮｅｔｗｏｒｋＩＰｖ４ＡｄｄｒｅｓｓＳｅｔ
各アイテムに対して渡されるデータ：
以下のいずれか：
ＩＰｖ４ Ａｄｄｒｅｓｓ（ＩＰｖ４アドレス）−文字列（ワイルドカードを含むことができる）
ＩＰｖ４ Ａｄｄｒｅｓｓ Ｒａｎｇｅ（ＩＰｖ４アドレス範囲）−２つの文字列
ＦＱＤＮ−文字列
Ｈｏｓｔｎａｍｅ（ホスト名）−文字列

実装：
パッキングされたＢＳＴＲ：“Ｔ：文字列１：文字列２”
Ｔ−タイプ（アドレス、アドレス範囲、ホスト名またはＦＱＤＮを表す１文字）
文字列１−アドレス、開始アドレス、ホスト名またはＦＱＤＮ
文字列２−アドレス範囲の終了アドレス

ＵｓｅｒＳｅｔ
各アイテムに対して渡されるデータ：
Ｕｓｅｒ Ａｃｃｏｕｎｔ Ｎａｍｅ（ユーザー・アカウント名）−文字列

実装：
ＢＳＴＲ

ＵｓｅｒＧｒｏｕｐＳｅｔ
各アイテムに対して渡されるデータ ：
Ｕｓｅｒ Ｇｒｏｕｐ Ｎａｍｅ（ユーザー・グループ名）−文字列

実装：
ＢＳＴＲ

ＦｉｌｅＯｐＳｅｔ
各アイテムに対して渡されるデータ：
Ｆｉｌｅ Ｏｐｅｒａｔｉｏｎ（ファイル操作）−文字列（または列挙）

実装：
ＢＳＴＲ

ＤｉｒＯｐＳｅｔ
各アイテムに対して渡されるデータ：
Ｄｉｒｅｃｔｏｒｙ Ｏｐｅｒａｔｉｏｎ（ディレクトリ操作）−文字列（または列挙）

実装：
ＢＳＴＲ

ＰｒｏｃｅｓｓＯｐＳｅｔ
各アイテムに対して渡されるデータ：
Ｐｒｏｃｅｓｓ Ｏｐｅｒａｔｉｏｎ（プロセス操作）−文字列（または列挙）

実装：
ＢＳＴＲ

ＲｅｇＫｅｙＯｐＳｅｔ
各アイテムに対して渡されるデータ：
Ｒｅｇｉｓｔｒｙ Ｋｅｙ Ｏｐｅｒａｔｉｏｎ（レジストリキー操作）−文字列（または列挙）

実装：
ＢＳＴＲ

ＲｅｇＶａｌｕｅＯｐＳｅｔ
各アイテムに対して渡されるデータ：
Ｒｅｇｉｓｔｒｙ Ｖａｌｕｅ Ｏｐｅｒａｔｉｏｎ（レジストリ値操作）−文字列（または列挙）

実装：
ＢＳＴＲ

ＵｓｅｒＯｐＳｅｔ
各アイテムに対して渡されるデータ：
Ｕｓｅｒ Ａｃｃｏｕｎｔ Ｏｐｅｒａｔｉｏｎ（ユーザー・アカウント操作）−文字列（または列挙）

実装：
ＢＳＴＲ

ＵｓｅｒＧｒｏｕｐＯｐＳｅｔ
各アイテムに対して渡されるデータ：
Ｕｓｅｒ Ｇｒｏｕｐ Ｏｐｅｒａｔｉｏｎ（ユーザー・グループ操作）−文字列（または列挙）

実装：
ＢＳＴＲ

ＪｏｂＯｐＳｅｔ
各アイテムに対して渡されるデータ：
Ｊｏｂ Ｏｐｅｒａｔｉｏｎ（ジョブ操作）−文字列（または列挙）

実装：
ＢＳＴＲ

Ｇｅｎｅｒｉｃ
各アイテムに対して渡されるデータ：
Ｖａｌｕｅ（値）−文字列

実装：
ＢＳＴＲ

ＱｕｅｒｙＳｅｔ
ＱｕｅｒｙＳｅｔは、セキュリティ・エンジンに対しては、ユーザーへのクエリの結果を格納する単一アイテム・コレクションとして動作する。関連するコンテクストが、別個のパラメータとしてセキュリティ・エンジンに渡される。セキュリティ・エンジンにとっては、必要なのはコンテクストとクエリ結果だけであり、ＱｕｅｒｙＳｅｔの内部構造は通常、必要とされない。

Ｂｏｏｌｅａｎ（ｂｏｏｌＤｅｆｉｎｅ）
単一アイテムに対して渡されるデータ：
Ｂｏｏｌｅａｎ（ブーリアン、ブール型、論理型）−真または偽

実装：
ＬＯＮＧ −偽＝０、真＝１

図９は、本願明細書で説明している技法を実装できる、一般的なコンピュータ環境９００を示している。コンピュータ環境９００は、コンピューティング環境の一例に過ぎず、コンピュータおよびネットワークのアーキテクチャの使用または機能の範囲に関して制限を示唆しようとするものではまったくない。コンピュータ環境９００は、この例のコンピュータ環境９００に示したコンポーネントの任意の１つまたは組合せに関して依存性も必要条件も有しないことを理解されたい。

コンピュータ環境９００は、コンピュータ９０２の形態の中に複数の汎用コンピューティング装置を含む。コンピュータ９０２は、１つまたは複数のメディア・プレーヤ・アプリケーションを実行できる。コンピュータ９０２のコンポーネントとして、（必要に応じて暗号プロセッサやコプロセッサを含む）１つまたは複数のプロセッサ（処理ユニット）９０４、システム・メモリ９０６、プロセッサ９０４を含む各種システム・コンポーネントをシステム・メモリ９０６に接続するシステム・バス９０８などがあるが、これだけに限られない。

システム・バス９０８は１つまたは複数の、いくつかのタイプのバス構造を表し、これには、メモリ・バスまたはメモリ・コントローラ、ポイント・ツー・ポイント接続、スイッチング・ファブリック、ペリフェラル・バス、高速グラフィックス・ポート、様々なバス・アーキテクチャのいずれかを使用するプロセッサまたはローカル・バスなどが含まれる。そのようなバス・アーキテクチャの例として、ＩＳＡ（Industry Standard Architecture）バス、ＭＣＡ（Micro Channel Architecture）バス、ＥＩＳＡ（Enhanced ISA）バス、ＶＥＳＡ（Video Electronics Standards Association）ローカル・バス、Ｍｅｚｚａｎｉｎｅバスとしても知られるＰＣＩ（Peripheral Component Interconnects）バスなどがある。

通常、コンピュータ９０２は、コンピュータでの読み取りが可能な様々なメディアを含む。そのようなメディアとして、コンピュータ９０２からのアクセスが可能な任意の市販メディアを使用でき、これには、揮発性メディアと不揮発性メディアの両方、リムーバブル・メディアと非リムーバブル・メディアの両方が含まれる。

システム・メモリ９０６には、ＲＡＭ（ランダム・アクセス・メモリ）９１０のような揮発性メモリおよび／またはＲＯＭ（読み出し専用メモリ）９１２のような不揮発性メモリの形態で、コンピュータでの読み取りが可能なメディアが含まれる。ＢＩＯＳ（基本入出力システム）９１４は、起動時などにコンピュータ９０２内の各要素間の情報転送を支援する基本ルーチンを含み、ＲＯＭ９１２に格納される。ＲＡＭ９１０は一般に、処理ユニット９０４からのダイレクトにアクセスすることができ、かつ／または処理ユニット９０４によって現在操作されているデータおよび／またはプログラム・モジュールを含む。

さらにコンピュータ９０２は、他のリムーバブル、非リムーバブル、揮発性または不揮発性のコンピュータ・ストレージ・メディアを含むことができる。例として、図９では、非リムーバブルで不揮発性の磁気メディア（図示せず）の読み取りおよび書き込みを行うハードディスク・ドライブ９１６、リムーバブルで不揮発性の磁気ディスク９２０（たとえば、「フロッピー（登録商標）ディスク」）の読み取りおよび書き込みを行う磁気ディスク・ドライブ９１８、リムーバブルで不揮発性の光ディスク９２４（ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭなどの光メディア）の読み取りおよび／または書き込みを行う光ディスク・ドライブ９２２などを示している。ハードディスク・ドライブ９１６、磁気ディスク・ドライブ９１８および光ディスク・ドライブ９２２は、それぞれ、１つまたは複数のデータ・メディア・インターフェース９２５によってシステム・バス９０８に接続される。あるいは、ハードディスク・ドライブ９１６、磁気ディスク・ドライブ９１８および光ディスク・ドライブ９２２は、１つまたは複数のインターフェース（図示せず）によってシステム・バス９０８に接続できる。

各ディスク・ドライブとそれに対応する、コンピュータでの読み取りが可能なメディアは、コンピュータでの読み取りが可能な命令、データ構造、プログラム・モジュールおよび他のコンピュータ９０２用データの不揮発性ストレージを提供する。この例ではハードディスク９１６、リムーバブル磁気ディスク９２０およびリムーバブル光ディスク９２４を示しているが、コンピュータからアクセスできるデータを格納できる、コンピュータでの読み取りが可能な他のタイプのメディア（磁気カセットや他の磁気ストレージ装置、フラッシュ・メモリカード、ＣＤ−ＲＯＭ、ＤＶＤ（デジタル多用途ディスク）または他の光ストレージ、ＲＡＭ（ランダム・アクセス・メモリ）、ＲＯＭ（読み出し専用メモリ）、ＥＥＰＲＯＭ（電気的消去が可能かつ書き込み可能なＲＯＭ）など）も、この例のコンピューティング・システムおよび環境の実装のために利用できることを理解されたい。

ハードディスク９１６、磁気ディスク９２０、光ディスク９２４、ＲＯＭ９１２および／またはＲＡＭ９１０には、例としてオペレーティング・システム９２６、１つまたは複数のアプリケーション・プログラム９２８、他のプログラム・モジュール９３０およびプログラム・データ９３２をはじめとする任意の数のプログラム・モジュールを格納できる。そのようなオペレーティング・システム９２６、１つまたは複数のアプリケーション・プログラム９２８、他のプログラム・モジュール９３０およびプログラム・データ９３２（またはこれらによる何らかの組合せ）のそれぞれは、分散ファイル・システムをサポートする常駐コンポーネントのすべてまたは一部を実装することができる。

ユーザーは、キーボード９３４やポインティング装置９３６（たとえば「マウス」）などの入力装置を介してコマンドや情報をコンピュータ９０２に入力できる。他の入力装置９３８（具体的には図示せず）として、マイクロホン、ジョイスティック、ゲーム・パッド、パラボラ・アンテナ、シリアル・ポート、スキャナなども使用できる。これらの入力装置や他の入力装置は、システム・バス９０８に接続された入出力インターフェース９４０を介して処理ユニット９０４に接続されるが、他のインターフェースやバス構造（パラレル・ポート、ゲーム・ポート、ＵＳＢ（ユニバーサル・シリアル・バス））で接続することもできる。

モニタ９４２や他のタイプのディスプレイ装置も、ビデオ・アダプタ９４４などのインターフェースを介してシステム・バス９０８に接続できる。モニタ９４２に加え、他の出力ペリフェラル装置として、入出力インターフェース９４０を介してコンピュータ９０２に接続できるスピーカ（図示せず）やプリンタ９４６などのコンポーネントも使用できる。

コンピュータ９０２は、リモート・コンピューティング装置９４８などの、１つまたは複数のリモート・コンピュータとの論理接続を使用する、ネットワーク接続された環境で動作できる。リモート・コンピューティング装置９４８としては、たとえば、パーソナルコンピュータ、ポータブル・コンピュータ、サーバー、ルーター、ネットワーク・コンピュータ、ピア装置や他の共通ネットワーク・ノード、ゲーム・コンソールなどを使用できる。リモート・コンピューティング装置９４８は、コンピュータ９０２を基準に本願明細書で説明している要素および機能の多くまたはすべてを含むことのできるポータブル・コンピュータとして図示されている。

コンピュータ９０２とリモート・コンピュータ９４８の論理接続は、ＬＡＮ（ローカル・エリア・ネットワーク）９５０および一般のＷＡＮ（ワード・エリア・ネットワーク）９５２として表される。そのようなネットワーキング環境は、事務所、企業内コンピュータ・ネットワーク、イントラネット、インターネットなどではごく普通のものである。

ＬＡＮネットワーキング環境に実装された場合、コンピュータ９０２は、ネットワーク・インターフェースまたはアダプタ９５４を介してローカル・ネットワーク９５０に接続される。ＷＡＮネットワーキング環境に実装された場合、コンピュータ９０２は、通常、広域ネットワーク９５２を経由する通信を確立するためにモデム９５６や他の手段を含む。モデム９５６は、コンピュータ９０２に内蔵または外付けすることができ、入出力インターフェース９４０または他の適切なメカニズムを介してシステム・バス９０８に接続できる。図示したネットワーク接続は例示的なものであることと、コンピュータ９０２および９４８の間の通信リンクを確立するために他の手段を用いることが可能であることを理解されたい。

コンピューティング環境９００を用いて図示したような、ネットワーク接続された環境では、コンピュータ９０２と関連するものとして表されたプログラム・モジュールまたはその一部は、リモート・メモリ・ストレージ装置に格納できる。一例として、リモート・アプリケーション・プログラム９５８は、リモート・コンピュータ９４８のメモリ装置に常駐する。図示するために、本願明細書では、アプリケーション・プログラムや、オペレーティング・システムなどの他の実行可能プログラム・コンポーネントを別個のブロックとして表したが、そのようなプログラムやコンポーネントは、様々な時点でコンピューティング装置９０２の種々のストレージ・コンポーネントに常駐し、そのコンピュータのデータ・プロセッサによって実行されることが理解される。

各種のモジュールや技法は、本願明細書において、１つまたは複数のコンピュータや他の装置で実行されるプログラム・モジュールのような、コンピュータで実行可能な命令群の一般的なコンテクストで説明することができる。一般に、プログラム・モジュールは、特定のタスクを実行したり、特定の抽象データ型を実装したりするルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。一般に、プログラム・モジュールの機能は、必要に応じて結合または分散され、様々な実施形態で使用できる。

これらのモジュールや技法の実装を、コンピュータでの読み取りが可能な、何らかの形式のメディアに格納したり、そのようなメディアで転送したりできる。コンピュータでの読み取りが可能なメディアには、コンピュータからのアクセスが可能な任意の市販メディアを使用できる。一例として（これに限るものではない）、コンピュータでの読み取りが可能なメディアは、「コンピュータ・ストレージ・メディア」と「通信メディア」を含むことができる。

「コンピュータ・ストレージ・メディア」には、コンピュータでの読み取りが可能な命令群、データ構造、プログラム・モジュール、その他のデータなどの情報の記憶のための任意の方法や技法において実装される、揮発性または不揮発性で、リムーバブルまたは非リムーバブルのメディアが含まれる。コンピュータ・ストレージ・メディアには、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリなどのメモリ技術、ＣＤ−ＲＯＭ、ＤＶＤ（デジタル多用途ディスク）などの光ストレージ、磁気カセット、磁気テープ、磁気ディスク・ストレージなどの磁気ストレージ装置、あるいはその他の、必要情報を格納でき、コンピュータからのアクセスが可能な任意のメディアが含まれ、これらだけには限定されない。

「通信メディア」は一般に、コンピュータでの読み取りが可能な命令群、データ構造、プログラム・モジュール、または他のデータを、搬送波や他の伝送メカニズムなどの変調データ信号で具体化する。通信メディアはさらに、任意の情報配信メディアを含む。「変調データ信号」という用語は、その１つまたは複数の特性を、信号内の情報をエンコードするように設定するか変化させた信号を意味する。一例として（これに限るものではない）、通信メディアには、有線ネットワークや直接有線接続などの有線メディアと、音波、ＲＦ、赤外線などの無線メディアとが含まれる。これらの任意の組合せも、コンピュータでの読み取りが可能なメディアの範囲に含まれる。

概念的には、プログラミング・インターフェースは、一般に、図１０または図１１に示すように、一般的に表すことができる。図１０では、インターフェースＩｎｔｅｒｆａｃｅ１を、第１のコード・セグメントと第２のコード・セグメントの間の通信で使用する管路（conduit）として示している。図１１では、インターフェースを、インターフェース・オブジェクトＩ１およびＩ２を含むものとして表している（Ｉ１およびＩ２は、第１および第２のコード・セグメントの一部であってもなくてもよい）。このインターフェースは、システムの第１のコード・セグメントと第２のコード・セグメントが媒体Ｍを介して通信することを可能にする。図１１の見方として、インターフェース・オブジェクトのＩ１とＩ２を同じシステムの別々のインターフェースと見なすことができ、また、オブジェクトＩ１およびＩ２と媒体Ｍとでインターフェースを構成すると見なすこともできる。図１０および１１では、両方向のフローとそのフローのそれぞれの側にあるインターフェースを示しているが、特定の実施態様では、片方向の情報フローだけを有すること（あるいは後述のように、情報フローを有しないこと）や、一方の側にのみインターフェース・オブジェクトを有することが可能である。一例として（これに限るものではない）、ＡＰＩ（アプリケーション・プログラミング・インターフェース（またはアプリケーション・プログラム・インターフェース））、エントリ・ポイント、メソッド、関数、サブ・ルーチン、リモート・プロシージャ・コール、ＣＯＭ（コンポーネント・オブジェクト・モデル）インターフェースなどの用語は、プログラミング・インターフェースの定義の中に包含されている。

そのようなプログラミング・インターフェースの態様には、第１のコード・セグメントが情報（ここでは「情報」を最も広い意味で使用しており、データ、コマンド、要求などを含む）を第２のコード・セグメントに伝達するメソッド、第２のコード・セグメントがその情報を受け取るメソッド、およびその情報の構造、シーケンス、構文、編成、スキーマ、タイミング、内容（content）を含めることができる。この点に関しては、インターフェースで定義される方式で情報が伝送される限り、媒体が有線であれ、無線であれ、有線と無線の組合せであれ、土台となる伝送媒体自体はインターフェースの動作にとっては重要でないと考えられる。状況によっては、情報転送が別のメカニズム（たとえば、コード・セグメント間の情報フローとは別に、バッファやファイルなどに置かれた情報）で行われる場合、あるいは第２のコード・セグメントが実行する機能に第１のコード・セグメントが単純にアクセスする場合のような、情報転送が存在しない場合のように通常の意味において、情報が片方向または両方向で渡されない場合がある。ある特定の状況、たとえば、コード・セグメントが、疎結合または密結合された構成のシステムの一部かどうかに依存する場合、では、これらの態様のいずれかまたはすべてが重要になる可能性があり、したがって、このリストは例示であり、非限定的であると考えなければならない。

このプログラミング・インターフェースの概念は、当業者には既知であり、本発明の前述の詳細な説明から明らかである。ただし、プログラミング・インターフェースの実装には別の方法があり、明確に除外しない限り、それらも本発明の特許請求の範囲に包含される。そのような他の方法は、図１０および１１の過度に単純化した表現より緻密または複雑な表現になる可能性があるが、それにもかかわらず、同様な機能を実行し、同じ全体的な結果を達成する。以下では、プログラミング・インターフェースのいくつかの説明に役立つ代替の実装例について簡単に説明する。

ファクタリング（Factoring；要素への分解）
あるコード・セグメントから別のコード・セグメントへの通信は、その通信を複数の別々の通信に分割することによって間接的に達成できる。これを図１２および１３で概略的に示す。図に示すように、複数のインターフェースを、分割可能な機能セットの項目（terms of divisible sets of functionality）で表すことができる。そこで、図１０および１１のインターフェース機能は、ちょうど、数学的に、２４を、あるいは２×２×３×２を提供するように、同じ結果を達成するために、要素に分解することができる。したがって、図１２に示すように、インターフェースＩｎｔｅｒｆａｃｅ１で実現される機能を細分して、そのインターフェースの通信を複数のインターフェースＩｎｔｅｒｆａｃｅ１Ａ、Ｉｎｔｅｒｆａｃｅ１Ｂ、Ｉｎｔｅｒｆａｃｅ１Ｃなどに変換し、同じ機能を達成することができる。また、図１３に示すように、インターフェースＩ１で実現される機能を、複数のインターフェースＩ１ａ、Ｉ１ｂ、Ｉ１ｃなどに細分して、同じ結果を達成することができる。同様に、第１のコード・セグメントから情報を受け取る第２のコード・セグメントのインターフェースＩ２を、複数のインターフェースＩ２ａ、Ｉ２ｂ、Ｉ２ｃなどに、ファクタリングできる。ファクタリングを行う場合、第１のコード・セグメントに含まれるインターフェースの数と、第２のコード・セグメントに含まれるインターフェースの数は同じである必要はない。図１２、図１３のいずれの場合でも、インターフェースＩｎｔｅｒｆａｃｅ１およびＩ１の機能的意味（functional spirit）は、それぞれ図１０および１１の場合と同じままである。インターフェースのファクタリングはさらに、結合（associative）、交換（commutative）、その他の数学的特性に従うことができ、それによって、そのファクタリングをわかりにくくすることができる。たとえば、操作の順序が重要でない場合があり、その場合は、インターフェースで実行されるある機能を、そのインターフェースに到達するかなり前に実行したり、別のコードまたはインターフェースの一部で実行したり、そのシステムの別のコンポーネントで実行したりできる。さらに、プログラミング分野の当業者であれば、同じ結果を達成する、異なる関数呼出しを作成する方法が多岐にわたっていることを理解されよう。

再定義（Redefinition）
場合によっては、意図した結果を達成しながら、プログラミング・インターフェースの特定の態様（たとえば、パラメータ）を無視、追加または再定義することができる。これを図１４および１５に示す。たとえば、図１０のインターフェースＩｎｔｅｒｆａｃｅ１が、３つのパラメータｉｎｐｕｔ、ｐｒｅｃｉｓｉｏｎおよびｏｕｔｐｕｔを含む関数呼出しＳｑｕａｒｅ（ｉｎｐｕｔ、ｐｒｅｃｉｓｉｏｎ、ｏｕｔｐｕｔ）を含み、この呼出しが第１のコード・セグメントから第２のコード・セグメントに発行される、と仮定する。ある特定の条件下で中間のパラメータｐｒｅｃｉｓｉｏｎが、図１４に示すように、無用な場合は、このパラメータを無視したほうが好都合で有る場合があり、あるいは（この状況では）ｍｅａｎｉｎｇｌｅｓｓパラメータに置き換えることもできる。さらに、関係のないａｄｄｉｔｉｏｎａｌパラメータを追加することもできる。いずれの場合も、第２のコード・セグメントによって入力が２乗（square）された後に出力が返される限り、２乗の機能は達成できる。ｐｒｅｃｉｓｉｏｎは、コンピューティング・システムのある程度下流や他の部分で十分意味を持つパラメータである場合があるが、２乗を計算するという狭い用途でいったん不要と認識されると、置き換えられるか無視される可能性がある。たとえば、有効なｐｒｅｃｉｓｉｏｎ値を渡す代わりに、誕生日などの無意味な値を渡しても結果に悪影響を及ぼさないと考えられる。同様に、図１５に示すように、インターフェースＩ１はインターフェースＩ１’に置き換えられ、パラメータを無視するか、そのインターフェースにパラメータを追加するよう再定義される。インターフェースＩ２は同様にインターフェースＩ２’として再定義され、不要なパラメータや他の場所で処理される可能性のあるパラメータを無視するよう再定義される。ここでのポイントは、プログラミング・インターフェースが特定の用途には不要である可能性がある、パラメータなどの、アスペクトを含む場合があるケースでは、したがって、それらを無視したり、再定義したり、他の用途のために別の場所で処理したりできる、ということである。

インライン・コーディング
さらに、別々の２つのコード・モジュールのある機能またはすべての機能を結合して、それらの間の「インターフェース」の形態を変えることが便利である場合がある。たとえば、図１０および１１の機能を、それぞれ図１６および１７の機能に変換できる。図１６では、図１０にあった第１および第２のコード・セグメントが、その両方を含む１つのモジュールにマージされている。この場合、それらのコード・セグメントは引き続き互いに通信しているが、そのインターフェースは、単一モジュールにとってより適した形態に変更することができる。したがって、たとえば、形式的なＣａｌｌ文とＲｅｔｕｒｎ文は不要になっても、インターフェースＩｎｔｅｒｆａｃｅ１に準拠する同様の処理や応答が引き続き有効になる場合がある。同様に、図１７に示すように、図１１のインターフェースＩ２の一部（またはすべて）をインターフェースＩ１とインラインでコーディングして、インターフェースＩ１”を形成することができる。図に示すように、インターフェースＩ２はＩ２ａとＩ２ｂに分割され、インターフェース部分Ｉ２ａはインターフェースＩ１とインラインでコーディングされて、インターフェースＩ１”が形成されている。具体例として、図１１のインターフェースＩ１が関数呼出しｓｑｕａｒｅ（ｉｎｐｕｔ，ｏｕｔｐｕｔ）を実行し、これをインターフェースＩ２が受取、その後、（２乗すべき）ｉｎｐｕｔとして渡された値が第２のコード・セグメントによって処理され、２乗した結果がｏｕｔｐｕｔとして戻されるとする。このような場合、第２のコード・セグメントで実行される処理（ｉｎｐｕｔの２乗）は、インターフェースを呼び出すことなく、第１のコード・セグメントで実行できる。

ディボース（Divorce）
あるコード・セグメントから別のコード・セグメントへの通信は、その通信を複数の別々の通信に分割する（breaking）ことによって間接的に達成できる。これを図１８および１９で概略的に示す。図１８に示すように、第１のインターフェースＩｎｔｅｒｆａｃｅ１上の通信を、異なるインターフェース（ここではインターフェースＩｎｔｅｒｆａｃｅ２Ａ、Ｉｎｔｅｒｆａｃｅ２ＢおよびＩｎｔｅｒｆａｃｅ２Ｃ）に準拠するよう変換するために、１つまたは複数個のミドルウェア（機能および／またはインターフェース機能をオリジナルのインターフェースから完全に分離するので、「ディボース（divorce）インターフェース」、）が提供される。こうしたことを行うのは、たとえば、Ｉｎｔｅｒｆａｃｅ１プロトコルに従って、たとえばオペレーティング・システムと通信するよう設計された、複数のアプリケーションのインストールされたベースがある場合であり、しかしこの場合、オペレーティング・システムは、別のインターフェース（ここではインターフェースＩｎｔｅｒｆａｃｅ２Ａ、Ｉｎｔｅｒｆａｃｅ２ＢおよびＩｎｔｅｒｆａｃｅ２Ｃ）を使用するように変更される。このポイントは、第２のコード・セグメントで使用しているオリジナルのインターフェースを、第１のコード・セグメントで使用しているインターフェースと互換性のないものに変換することであり、そのために、媒介手段を用いて古いインターフェースと新しいインターフェースの互換をとることである。同様に、図１９に示すように、第３のコード・セグメントを導入し、インターフェースＩ１からの通信を完全分離インターフェースＤＩ１で受取、完全分離インターフェースＤＩ２から、たとえば、ＤＩ２と動作するよう再設計されたインターフェースＩ２ａおよびＩ２ｂにインターフェース機能を伝達して、機能的に同じ結果を実現することができる。同様に、ＤＩ１およびＤＩ２は、連係動作により、図１１のインターフェースＩ１およびＩ２の機能を新しいオペレーティング・システム向けに変換し、かつ、機能的に同一もしくは同等の結果を実現することができる。

リライティング（Rewriting）
さらにまた別の可能な変種（variant）として、コードを動的にリライト（rewrite）して、インターフェース機能を別の何かに置き換え、全体としては同じ結果を達成することができる。たとえば、中間言語（たとえば、Ｍｉｃｒｏｓｏｆｔ ＩＬ，Ｊａｖａ（登録商標） ＢｙｔｅＣｏｄｅなど）で表されたコード・セグメントを、実行環境（たとえば、．Ｎｅｔフレームワーク、Ｊａｖａ（登録商標）ランタイム環境、または他の同様なランタイム・タイプの環境で提供される実行環境）でＪＩＴ（Just-in-Time）コンパイラまたはインタープリタにかけるシステムが考えられる。ＪＩＴコンパイラは、第１のコード・セグメントから第２のコード・セグメントへの通信を動的に変換するように書くことができる、つまり、通信を、第２のコード・セグメント（オリジナルの第２のコード・セグメントか、別の第２のコード・セグメント）で要求される可能性のある異なるインターフェースに準拠させるように書くことができる。これを図２０および２１に示す。図２０からわかるように、この方式は、前述したディボース方式（Divorce scenario）とよく似ている。これは、たとえば、複数のアプリケーションがインストールされたベースが、Ｉｎｔｅｒｆａｃｅ１プロトコルに従ってオペレーティング・システムと通信するよう設計されている場合であり、そのために、オペレーティング・システムが、別のインターフェースを使用するよう変更される場合である。ＪＩＴコンパイラは、インストールされたベース・アプリケーションからの通信を、オペレーティング・システムの新しいインターフェースに、直ちに（on the fly）準拠させることができる。図２１に示すように、この、インターフェースを動的にリライティングする方式は、インターフェースの動的なファクタリング(factoring)やその他の動的な変換にも同様に適用できる。

さらに、代替実施形態を用いて同一または同等のインターフェースとしての結果を達成する前述の方式が、直列および／または並列に、あるいは他の媒介コードを使用して、様々に組み合わせることができる点にも注意されたい。したがって、前述の各代替実施形態は、相互に排他的ではなく、図１０および１１で示した一般的な方式と同一または同等の方式を作り出すために、混在させ、整合させ、および結合させることができる。さらに、ほとんどのプログラミング構造物と同様に、本願明細書では説明できないが、本発明の趣旨および範囲によって表現される、同一または同等のインターフェース機能を達成する他の同様な方法があることに注意されたい。つまり、本願明細書で説明した方法は、インターフェースの価値の根底を成す、インターフェースによって表される機能性、およびインターフェースによって可能になる有益な結果の少なくとも一部であることに注意されたい。

これまでの説明では、構造的な特徴および／または方法論的な動作（act）に特有の言い回し（language）を使用したが、特許請求の範囲で定義される本発明は、説明した特定の特徴または動作（act）に限定されるものではないことを理解されたい。むしろ、この特定の特徴および動作（act）は、本発明の実装の例示的形態として開示したものである。

種々のイベントが生成および処理される環境の一例を示す図である。 データおよびルールを含むセキュリティ・ポリシーの一例を示す図である。 各種セキュリティ・エンジンから要求されるデータに関して、セキュリティ・モジュールによって保持されるテーブルの一例を示す図である。 セキュリティ・ポリシーのルールおよびデータを取得して配布する手続の一実施形態を示すフロー図である。 更新されたセキュリティ・ポリシー・データを処理する手続の一実施形態を示すフロー図である。 １つまたは複数のセキュリティ・エンジンに、情報を配布する処理を行う手続の一実施形態を示すフロー図である。 セキュリティ・ポリシーを更新する手続の一実施形態を示すフロー図である。 セキュリティ・ポリシーを更新する手続の別の実施形態を示すフロー図である。 一般的なコンピュータ環境を示す図である。 プログラミング・インターフェースの種々の実装例の１つを示す図である。 プログラミング・インターフェースの種々の実装例の１つを示す図である。 プログラミング・インターフェースの種々の実装例の１つを示す図である。 プログラミング・インターフェースの種々の実装例の１つを示す図である。 プログラミング・インターフェースの種々の実装例の１つを示す図である。 プログラミング・インターフェースの種々の実装例の１つを示す図である。 プログラミング・インターフェースの種々の実装例の１つを示す図である。 プログラミング・インターフェースの種々の実装例の１つを示す図である。 プログラミング・インターフェースの種々の実装例の１つを示す図である。 プログラミング・インターフェースの種々の実装例の１つを示す図である。 プログラミング・インターフェースの種々の実装例の１つを示す図である。 プログラミング・インターフェースの種々の実装例の１つを示す図である。

符号の説明

１００ 種々のイベントが生成および処理される環境
１０２ ホスト・コンピュータ
１０４ サーバー
１０６ サーバー
１０８ ネットワーク
１１０ セキュリティ・モジュール
１１２ イベント・マネージャ
１１４ セキュリティ・エンジン
１１６ セキュリティ・エンジン
１１８ セキュリティ・エンジン
１２０ システム状態情報
１２２ システム構成情報
１２４ アプリケーション・プログラム・インターフェース（ＡＰＩ）
２００ セキュリティ・ポリシー
２０２ データ
２０４ ルール
３００ セキュリティ・モジュールによって保持されるテーブル
３０２ データ要素
３０４ セキュリティ・エンジン
９００ 一般的なコンピュータ環境
９０２ コンピュータ
９０４ 処理ユニット
９０６ システム・メモリ
９０８ システム・バス
９１０ ＲＡＭ（ランダム・アクセス・メモリ）
９１２ ＲＯＭ（読み出し専用メモリ）
９１４ ＢＩＯＳ（基本入出力システム）
９１６ ハードディスク・ドライブ
９１８ 磁気ディスク・ドライブ
９２０ リムーバブルで不揮発性の磁気ディスク
９２２ 光ディスク・ドライブ
９２４ リムーバブルで不揮発性の光ディスク
９２５ データ・メディア・インターフェース
９２６ オペレーティング・システム
９２８ アプリケーション・プログラム
９３０ 他のプログラム・モジュール
９３２ プログラム・データ
９３４ キーボード
９３６ マウス
９３８ 他の装置
９４０ 入出力インターフェース
９４２ モニタ
９４４ ビデオ・アダプタ
９４６ プリンタ
９４８ リモート・コンピューティング装置
９５０ ＬＡＮ（ローカル・エリア・ネットワーク）
９５２ インターネット
９５４ ネットワーク・アダプタ
９５６ モデム
９５８ リモート・アプリケーション・プログラム

Claims (32)

1. コンピュータでの読み取りが可能な１つまたは複数のメディアに関して実施されるプログラミング・インターフェースであって、
   既存のセキュリティ・ポリシーを新しいセキュリティ・ポリシーに置き換えるよう構成されている複数のセキュリティ・エンジンに、新しいセキュリティ・ポリシーを伝達することに関連付けられる第１の機能グループ、および
   前記新しいセキュリティ・ポリシーを実装する準備ができていることのインジケーションで、各セキュリティ・エンジンについてのインジケーションを伝達することに関連付けられた第２の機能グループ
   を備えることを特徴とするプログラミング・インターフェース。
2. 前記第１の機能グループは、前記複数のセキュリティ・エンジンのそれぞれに前記新しいセキュリティ・ポリシーを削除するように指示するメソッドを含むことを特徴とする請求項１に記載のプログラミング・インターフェース。
3. 前記第１の機能グループは、特定のセキュリティ・エンジンを初期化するメソッドを含むことを特徴とする請求項１に記載のプログラミング・インターフェース。
4. 前記第１の機能グループは、前記複数のセキュリティ・エンジンのそれぞれに前記新しいセキュリティ・ポリシーを実装するように指示するメソッドを含むことを特徴とする請求項１に記載のプログラミング・インターフェース。
5. 前記第１の機能グループは、既存のセキュリティ・ポリシーに関連付けられた新しいデータを前記複数のセキュリティ・エンジンの少なくとも１つに伝達するメソッドをさらに備えることを特徴とする請求項１に記載のプログラミング・インターフェース。
6. 前記第１の機能グループは、構成情報を前記複数のセキュリティ・エンジンの少なくとも１つに伝達するメソッドをさらに備えることを特徴とする請求項１に記載のプログラミング・インターフェース。
7. 前記第２の機能グループは、特定のセキュリティ・エンジンが前記新しいセキュリティ・ポリシーを実装したかどうかを示すメソッドを含むことを特徴とする請求項１に記載のプログラミング・インターフェース。
8. 前記第２の機能グループは、特定のセキュリティ・ポリシーに関連付けられた更新されるデータを取得するメソッドをさらに含むことを特徴とする請求項１に記載のプログラミング・インターフェース。
9. 前記第２の機能グループは、前記複数のセキュリティ・エンジンの１つが識別した新しいデータをセキュリティ・エージェントに伝達するメソッドをさらに備えることを特徴とする請求項１に記載のプログラミング・インターフェース。
10. 前記第２の機能グループは、前記複数のセキュリティ・エンジンの１つが前記複数のセキュリティ・エンジンを含むシステムのユーザーに問い合わせを行うことを可能にするメソッドをさらに備えることを特徴とする請求項１に記載のプログラミング・インターフェース。
11. 前記複数のセキュリティ・エンジンの少なくとも１つがアンチウィルス・サービスを実装することを特徴とする請求項１に記載のプログラミング・インターフェース。
12. 前記複数のセキュリティ・エンジンの少なくとも１つがファイアウォール・アプリケーションを実装することを特徴とする請求項１に記載のプログラミング・インターフェース。
13. すべてのセキュリティ・エンジンが前記新しいセキュリティ・ポリシーを実装する準備を整えたことを示した後に、前記複数のセキュリティ・エンジンが前記新しいセキュリティ・ポリシーを実装することを特徴とする請求項１に記載のプログラミング・インターフェース。
14. １つまたは複数のマイクロ・プロセッサと１つまたは複数のソフトウェア・プログラムを含むコンピュータ・システムであって、前記１つまたは複数のソフトウェア・プログラムはアプリケーション・プログラム・インターフェースを利用して複数のセキュリティ・エンジンにセキュリティ・ポリシーを実装し、前記アプリケーション・プログラム・インターフェースは、
    新しいセキュリティ・ポリシーを前記複数のセキュリティ・エンジンに伝達する第１の機能、
    前記複数のセキュリティ・エンジンのそれぞれが前記新しいセキュリティ・ポリシーを適用する準備を整えたかどうかを識別する第２の機能、および
    すべてのセキュリティ・エンジンが前記新しいセキュリティ・ポリシーを適用する準備を整えたことを確認した後に、前記複数のセキュリティ・エンジンのそれぞれに前記新しいセキュリティ・ポリシーを実装するよう指示する第３の機能
    を備えることを特徴とするコンピュータ・システム。
15. 前記複数のセキュリティ・エンジンの少なくとも１つが前記新しいセキュリティ・ポリシーを適用できない場合に、前記複数のセキュリティ・エンジンのそれぞれに、前記新しいセキュリティ・ポリシーを削除させる第４の機能をさらに備えることを特徴とする請求項１４に記載のコンピュータ・システム。
16. 第１のセキュリティ・エンジンが識別したイベント情報をその他のセキュリティ・エンジンに伝達することに関連付けられた第４の機能をさらに備えることを特徴とする請求項１４に記載のコンピュータ・システム。
17. 第１のセキュリティ・エンジンが識別したセキュリティ関連情報をイベント・マネージャに伝達することに関連付けられた第４の機能をさらに備えることを特徴とする請求項１４に記載のコンピュータ・システム。
18. 前記イベント・マネージャは前記セキュリティ関連情報を前記複数のセキュリティ・エンジンの少なくとも１つに伝達することを特徴とする請求項１７に記載のコンピュータ・システム。
19. 前記複数のセキュリティ・エンジンの少なくとも１つが第１のタイプのセキュリティ攻撃に関連付けられていることを特徴とする請求項１４に記載のコンピュータ・システム。
20. 前記複数のセキュリティ・エンジンの少なくとも１つが第２のタイプのセキュリティ攻撃に関連付けられていることを特徴とする請求項１９に記載のコンピュータ・システム。
21. セキュリティ・ポリシーを第１のセキュリティ・エンジンに伝達することを容易にするために、１つまたは複数の第１の機能を呼び出すこと、
    前記第１のセキュリティ・エンジンが前記セキュリティ・ポリシーを適用したかどうかの決定を容易するために、１つまたは複数の第２の機能を呼び出すこと、および
    セキュリティ関連情報を前記第１のセキュリティ・エンジンから第２のセキュリティ・エンジンに伝達することを容易にするために、１つまたは複数の第３の機能を呼び出すこと
    を備えることを特徴とする方法。
22. 前記セキュリティ関連情報はセキュリティ攻撃のタイプを識別することを特徴とする請求項２１に記載の方法。
23. 前記第１のセキュリティ・エンジンを含むシステムのユーザーと対話することを容易にするために、１つまたは複数の第４の機能を呼び出すことをさらに備えることを特徴とする請求項２１に記載の方法。
24. 構成情報を前記第１のセキュリティ・エンジンに伝達することを容易にするために、１つまたは複数の第４の機能を呼び出すことをさらに備えることを特徴とする請求項２１に記載の方法。
25. 前記第１のセキュリティ・エンジンと前記第２のセキュリティ・エンジンとに前記セキュリティ・ポリシーを実装することを指示することを容易にするために、１つまたは複数の第４の機能を呼び出すことをさらに備えることを特徴とする請求項２１に記載の方法。
26. 改訂したセキュリティ・ポリシーを前記第１のセキュリティ・エンジンに伝達することを容易にするために、１つまたは複数の第４の機能を呼び出すことをさらに備えることを特徴とする請求項２１に記載の方法。
27. セキュリティ関連イベントをイベント・マネージャに伝達する第１の機能を公開する手段、
    前記セキュリティ関連イベントに関連付けられた複数のセキュリティ・エンジンを識別する第２の機能を公開する手段、および
    前記セキュリティ関連イベントを前記識別されたセキュリティ・エンジンに伝達する第３の機能を公開する手段
    を備えることを特徴とするシステム。
28. 新しいセキュリティ・ポリシーを前記複数のセキュリティ・エンジンに伝達する第４の機能を公開する手段、および
    既存のセキュリティ・ポリシーを前記新しいセキュリティ・ポリシーに置き換えることを前記複数のセキュリティ・エンジンに指示する第５の機能を公開する手段
    をさらに備えることを特徴とする請求項２７に記載のシステム。
29. 前記複数のセキュリティ・エンジンの少なくとも１つが前記新しいセキュリティ・ポリシーを実装できない場合に、前記新しいセキュリティ・ポリシーを削除することを、前記複数のセキュリティ・エンジンに指示する第６の機能を公開する手段をさらに備えることを特徴とする請求項２８に記載のシステム。
30. 前記セキュリティ関連イベントがウィルスの検出であることを特徴とする請求項２７に記載のシステム。
31. 前記セキュリティ関連イベントがストレージ装置に対する不正なアクセス試行であることを特徴とする請求項２７に記載のシステム。
32. 特定のセキュリティ・エンジンが別の関数呼出しの処理を完了したことを前記イベント・マネージャに通知する第４の機能を公開する手段をさらに備えることを特徴とする請求項２７に記載のシステム。
    

Images