(57)【特許請求の範囲】
【請求項１】
コンピュータシステムにおいて、システムコンポーネントにより要求される判定を行うためのシステムであって、
処理ユニットが前記システムコンポーネントにより要求されるアクションを受信するためのトラストマネージャと、
前記処理ユニットがアクションとオブジェクト内に実装された一組のルールであるポリシーとの間の関係を保持するためのポリシーマネージャと
を備え、前記処理ユニットは前記トラストマネージャによって前記ポリシーマネージャから前記アクションに対応するポリシーを取得し、前記処理ユニットは前記ポリシーにより得られる動的情報に基づいて判定を行うことを特徴とするシステム。
【請求項２】
請求項１に記載のシステムにおいて、前記システムコンポーネントはアプリケーションであることを特徴とするシステム。
【請求項３】
請求項１に記載のシステムにおいて、前記ポリシーが前記動的情報を取得する、ユーザインタフェースをさらに備えたことを特徴とするシステム。
【請求項４】
請求項１に記載のシステムにおいて、前記動的情報は前記ポリシーによって保持される状態情報を備えたことを特徴とするシステム。
【請求項５】
請求項１に記載のシステムにおいて、前記動的情報は前記トラストマネージャからのコンテキスト情報を有することを特徴とするシステム。
【請求項６】
請求項１に記載のシステムにおいて、前記ポリシーマネージャはアドミニストレータインタフェースを含むことを特徴とするシステム。
【請求項７】
請求項１に記載のシステムにおいて、前記オブジェクトはアドミニストレータインタフェースを含むことを特徴とするシステム。
【請求項８】
請求項１に記載のシステムにおいて、複数の他のポリシーをさらに有し、前記ポリシーは少なくとも１つの他のポリシーを呼び出すための実行コードを含むことを特徴とするシステム。
【請求項９】
請求項１に記載のシステムにおいて、複数の他のポリシーをさらに有し、前記ポリシーは、複数の他のポリシーを呼び出すために、および最終判定を生成するために前記他のポリシーの判定を数学的に結合するための実行コードを含むことを特徴とするシステム。
【請求項１０】
請求項９に記載のシステムにおいて、複数の他のポリシーをさらに有し、前記ポリシーは、複数の他のポリシーのどの１つを呼び出してそこから判定を受信すべきかを決定するための実行コードを含むことを特徴とするシステム。
【発明の詳細な説明】
【０００１】
（発明の分野）
本発明は、一般にコンピュータシステムに関し、より詳しくは、コンピュータシステムのためのトラストマネジメント（trust management）における改善に関する。
【０００２】
（発明の背景）
トラストマネジメントは、ある潜在的に危険なアクションに関してアプリケーションのようなシステムコンポーネントにより行われる判定を制御する概念を指向している。一般に、適切な判定を行うために、アプリケーションの所望のアクションはポリシーと照合される。特定のアクションに対するポリシーは、その特定のアクションを許可するか拒否するかを判定する一組のルールである。例として、ウェブブラウザはインターネットから実行可能コードをダウンロードするか否かの判定をポリシーに基づいて行う。このポリシーは、ユーザの選択（ｐｒｅｆｅｒｅｎｃｅ）およびコードについてのデジタル署名の有効性を有する。同様に、認証機関は証明を発行するか否かの判定を、要求者がその身元を証明するためのポリシーをコンパイルしているか否かに基づいて行う。一方、マイクロソフトウィンドウズＮＴのようなセキュリティを有するオペレーティングシステムは、ユーザをログオンさせるか否かを、ポリシー、即ち正しいアカウントのパスワードが与えられ、そのアカウントがロックされていないか否か、およびログオンタイムと日付の制限のような他の制約が違反されていないか否かに関するポリシーに基づいて判定する。
【０００３】
しかしながら、一般に、ポリシーとアクションのための要求を照合するオペレーションは、アプリケーションにおけるトラストマネジメントと共通であるが、ポリシーの評価の実施は各アプリケーションにおいて異なる。例えば、ポリシーは各アプリケーションにおいて異なる方法で表され、ユーザが設けたりまたは認識するには時々難しいことがある。さらに、ポリシーはそのアプリケーション内に構築されるので、そのポリシーは本質的に静的であり、２、３のオプションの設定により制限されるように、最小限の修正しかできない。結果として、判定を制御するために、アプリケーションにより使用されるポリシーへに対して、修正を加えたり新しいポリシーの制約を加えるための容易な方法は無い。また、ドメインの範囲までの新しいポリシーを強要するための容易な方法は無い。大きな（企業の）ネットワークのアドミニストレータ（administrator）達は、ポリシーを一様に実施するために多大な苦労を余儀なくされている。
【０００４】
（発明の概要）
簡潔に言うと、本発明は、ポリシーを使用してアプリケーションのようなシステムコンポーネントの要求されたアクションについて判定を行うシステムおよび方法を提供する。本発明によれば、ポリシーは、インテリジェントトラストマネージャ（intelligent trust manager）を介して、どのようなシステムコンポーネントに対しても利用可能な中央で保持されたシステムリソースである。要求アクションを含むアクション情報は、システムコンポーネントから受信され、アクション情報は、要求アクションに対応したポリシーを得るために使用される。この目的のために、ポリシーは、アクション情報内で識別されるアクションへポリシーマネージャ（policy manager）によりマップされるＣＯＭオブジェクト内に実装される。ポリシーは、システムコンポーネントとは独立した資源から、それは例えば、ポリシー内で保持される状態を介して、または、他のコンテキストから、さもなくばユーザインタフェースを通じて、もしくはウェブサイトのような外部資源から種々の情報をポリシーにおいて取得する。ポリシーは実行コードを介し、それにより得られる種々の情報に基づいてその中で判定を行う。そしてポリシーは、システムコンポーネントに判定を返す。
【０００５】
他の利点は、図面を参照した以下の詳細な説明から明らかになるであろう。
【０００６】
（詳細な説明）
好適な動作環境
図１および以下の解説は、本発明が実施される適切なコンピューティング環境について簡潔で一般的な説明を与えることを意図している。必要があるわけではないが、本発明はコンピュータ実行可能な命令、例えばパーソナルコンピュータによって実行されるプログラムモジュールのような命令の一般的なコンテキストの形態で説明される。一般的に、プログラムモジュールは、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造、および特定のタスクを実行するかまたは特定の抽象的なデータタイプを有するものを含む。
【０００７】
さらに、当業者なら理解するであろうが、本発明は他のコンピュータシステム構成、すなわち、ハンドヘルド機器、マルチプロセッサシステム、マイクロプロセッサ内臓またはプログラム可能の消費者向け電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータのようなコンピュータシステム構成をもって実施されてもよい。本発明はまた、分散型コンピューティング環境、即ち、通信ネットワークを介して接続されているリモート処理機器によりタスクが実行される分散型コンピューティング環境において実行されてもよい。分散型コンピューティング環境において、プログラムモジュールはローカルおよびリモートの双方のメモリ記憶装置に置かれてもよい。
【０００８】
図１を参照する。発明を実施するための好適なシステムは、従来のパーソナルコンピュータ２０等の形態の汎用目的のコンピューティングデバイスを含む。上記コンピューティングデバイスは処理ユニット２１、システムメモリ２２、およびシステムメモリを含む種々のシステムコンポーネントを処理ユニット２１に結合するシステムバス２３を含む。システムバス２３はいくつかのタイプのバス構造、即ち、メモリバスまたはメモリコントローラ、ならびに周辺装置バス、および種々のバスアーキテクチャのいずれかを使用するローカルバスを含むバス構造のいずれでもよい。システムメモリは、リードオンリーメモリ（ＲＯＭ）２４およびランダムアクセスメモリ（ＲＡＭ）２５を含む。ベーシックインプット／アウトプットシステム２６（ＢＩＯＳ）、即ち、例えばスタートアップ中に、パーソナルコンピュータ２０内で構成要素間の情報を転送することを助ける基本ルーチンを含んでいるベーシックインプット／アウトプットシステム２６（ＢＩＯＳ）は、ＲＯＭ２４にストアされている。不図示のハードディスクに対して読み／書きするハードディスクドライブ２７、リムーバル磁気ディスク２９に対して読み／書きする磁気ディスクドライブ２８、およびＣＤ−ＲＯＭまたは他の光媒体のような取り外し可能光ディスク３１に対して読み／書きする光ディスクドライブ３０を、パーソナルコンピュータ２０がさらに含んでもよい。ハードディスクドライブ２７、磁気ディスクドライブ２８、および光ディスクドライブ３０は、それぞれ、ハードディスクドライブインタフェース３２、磁気ディスクドライブインタフェース３３、および光ドライブインタフェース３４によって、システムバス２３に接続されている。ドライブおよびそれらに関連するコンピュータ読み取り可能な媒体は、コンピュータ読み取り可能な命令、データ構造、プログラムモジュールおよびパーソナルコンピュータ２０のための他のデータの不揮発性記憶を提供する。ここで説明される好適な環境は、ハードディスク、リムーバル磁気ディスク２９および取り外し可能光ディスク３１を利用しているが、コンピュータによりアクセス可能なデータをストアすることができる他のタイプのコンピュータ読み取り可能媒体、即ち、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ベルヌーイカートリッジ、ランダムアクセスメモリ（ＲＡＭ）、リードオンリーメモリ（ＲＯＭ）等のコンピュータ読み取り可能媒体が、好適な動作環境において使用されてもよいことが、当業者には理解されるはずである。
【０００９】
いくつかのプログラムモジュールは、ハードディスク、磁気ディスク２９、光ディスク３１、ＲＯＭ２４またはＲＡＭ２５上にストアされてもよく、プログラムモジュールは、オペレーティングシステム３５（好ましくはウィンドウズＮＴ）、１つまたは複数のアプリケーションプログラム３６、他のプログラムモジュール３７およびプログラムデータ３８を含む。ユーザは、キーボード４０およびポインティングデバイス４２のような入力装置を介して、パーソナルコンピュータ２０へコマンドおよび情報を入力する。他の入力装置（不図示）は、マイクロホン、ジョイスティック、ゲームパッド、パラボラアンテナ、スキャナ等を含む。これらおよび他の入力装置はしばしば、システムバスへ連結されているシリアルポートインタフェース４６を介して、処理ユニット２１に接続されているが、パラレルポート、ゲームポートまたはユニバーサルシリアルバス（ＵＳＢ）のような他のインタフェースによって接続されてもよい。モニタ４７または他のタイプのディスプレイ装置はまた、ビデオアダプタ４８のようなインタフェースを介して、システムバス２３に接続されている。モニタ４７に加えて、パーソナルコンピュータは典型的には、スピーカおよびプリンタのような他の周辺出力装置（不図示）を含む。
【００１０】
パーソナルコンピュータ２０は、リモートコンピュータ４９のような１つまたは複数のリモートコンピュータへの論理接続を使用していてネットワーク化された環境において動作してもよい。リモートコンピュータ４９は、他のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、同等な装置または他の共通なネットワークのノードであってもよい。メモリ記憶装置５０のみが図１に図示されているが、リモートコンピュータ４９は、典型的にはパーソナルコンピュータ２０に関連した上述の構成要素の多くまたは全てを含んでいる。図１に図示された論理接続は、ローカルエリアネットワーク（ＬＡＮ）５１および広域ネットワーク（ＷＡＮ）５２を含む。そのようなネットワーキング環境は、オフィス、企業全体のコンピュータネットワーク、イントラネットおよびインターネットにおいて普通に使用される。
【００１１】
ＬＡＮネットワーキング環境において使用される時、パーソナルコンピュータ２０は、ネットワークインタフェースまたはアダプタ５３を介してローカルネットワーク５１に接続される。ＷＡＮネットワーキング環境において使用される時、パーソナルコンピュータ２０は典型的には、インターネットのような広域ネットワーク５２上で通信を確立するためのモデム５４または他の手段を含む。モデム５４は、内臓でも外付けでもよく、シリアルポートインタフェース４６を介してシステムバス２３に接続されている。ネットワーク化された環境において、パーソナルコンピュータ２０に関して図示されたプログラムモジュール、またはその一部分は、リモートメモリ記憶機器内にストアされてもよい。図示されたネットワーク接続は好適例であり、コンピュータ間に通信リンクを確立する他の手段が使用されてもよいことは、理解されるであろう。
【００１２】
本発明の好適な実施形態は、ここではコンポーネントオブジェクトモデル（ＣＯＭ）を参照して説明される。ＣＯＭは綿密に文書化された（ｗｅｌｌ−ｄｏｃｕｍｅｎｔｅｄ）技術であって、クライアントはＣＯＭオブジェクトのインタフェースを介してその中のメソッドにアクセスすることによって、ＣＯＭオブジェクトにより提供されるサービスにアクセスする。ＣＯＭは拡張性および将来的な互換性を備えており、さらに、ポリシー（後述）はＣＯＭオブジェクトであるため、それらはＶＢＳｃｒｉｐｔおよびＪｓｃｒｉｐｔのようなよく知られた使い易いスクリプト言語、あるいはＣ＋＋のようなより強力な言語で記述されてもよい。簡素化の目的のために、ＣＯＭの詳細な解説はここには含まれていない。ＣＯＭオブジェクトの詳細な説明は、「Ｉｎｓｉｄｅ  ＯＬＥ」第２版（Ｋｒａｉｇ  Ｂｒｏｃｋｓｃｈｍｉｄｔ著、マイクロソフトプレス（１９９３年））というタイトルの文献に示されており、これによりＣＯＭオブジェクトの詳細な説明は、参照により組み込まれる。ＣＯＭは本発明を実施するために使用されることが好適であるが、本発明をＣＯＭの実施に制限する意図は無いことに留意されたい。例えば、容易に理解されるであろうが、本発明は代わりに、関数または他の同等な実施に対するアプリケーションプログラミングインタフェースの呼び出しを介して実施されてもよい。
【００１３】
インテリジェントトラストマネジメント
図２は、本発明の一般的な概念モデルを示しており、システムコンポーネント６０1−６０n（例えばアプリケーション）は、予め定められたポリシーに従ってトラスト判定をさせるためにインテリジェントトラストマネージャ６２に対して呼び出しを行う。判定を得るために、インテリジェントトラストマネージャ６２は、ポリシーオブジェクト６６1−６６nの中の適切な１つを呼び出すために、ポリシーマネージャ６４と交互に通信する。対応するポリシーオブジェクト（例えば６６3）は、助言的な判定、すなわち、イエス、ノーまたは判定を行うためには不十分な情報のような判定を行い、インテリジェントトラストマネージャ６２を介してシステムコンポーネント（例えば６０1）にその判定を返す。要求は２以上のポリシーオブジェクトに対応しているが、ここでは簡略化の目的のために、リクエストは一般的に１つのポリシーオブジェクトに渡されるだけであることに留意されたい。しかしながら、（以下に詳述するが）、対応するポリシーオブジェクトはそれ自身、１つまたは複数の他のポリシーオブジェクトを呼び出し、それらの判定を使用して自身の最終的な判定を行うことに留意されたい。
【００１４】
図２に表されているように、および本発明の１つの形態に従って、ポリシーは、システムのどのようなシステムコンポーネントに対しても一貫した方法で利用可能な、集中的に保持されるシステムリソースである。なお、ポリシーはシステムコンポーネントからはずされ、分離されており、それに対して透過である。ポリシーを付加するために、ポリシーは任意の他のＣＯＭオブジェクトのように適切に登録されるが、セキュリティの目的のために、その登録操作自身は、以下に説明されるように、通常はポリシーに支配される。ポリシーを別のポリシーと置き換えるために、他のポリシーが登録され、その名前の結び付け（後述）が変更され、その名前を使用するこれらシステムコンポーネントが既知のポリシーの代わりに他のポリシーを呼び出す。他の利点の中でも特に、本発明はこのように、ポリシーを多数のシステムコンポーネントによって分け合える一方、本質的にシステムコンポーネントをポリシー管理の詳細から隠している。ポリシーオブジェクトはＣＯＭオブジェクトなので、それらは判定を行うための実行コードを含み、さらに、状態を維持し、自身のユーザインタフェースを生成し、判定を行うための１つまたは複数の推論エンジン（演繹的処理）を含む。加えて、それらは命名されてもよく、それによってアドミニストレータ達は必要な時に適切なポリシーオブジェクトを直感的に置いて参照しやすく配列してもよいし、デジタル方式で署名されてもよい。それにより、そのオブジェクトを登録しおよび／または呼び出す時のように、セキュリティ目的のためのポリシーオブジェクトの保全を照合することが可能となる。種々のコンポーネントが図２において直接接続されるように示されているが、容易に理解されるように、そのコンポーネントおよび／またはそれらの分割可能な部分はネットワークの種々のシステムを通じて分配されてもよいことに留意されたい。実際は、以下で説明されるように、企業のネットワークにおいて、ポリシーはしばしばドメインを通じて保持され、クライアントアプリケーションはドメインサーバと通信し、ポリシーにアクセスして判定を受信する。
【００１５】
図３により詳細に示されているように、および図４のタイミングチャートに表されているように、アプリケーション６０1が要求しようとしている潜在的に危険なアクションがポリシーに従って許可されるか禁止されるかを決める必要がある時に、アプリケーション（例えばシステムコンポーネント６０1）は判定を行う処理を開始する。例を挙げると、ユーザによってウェブサイトから最初にコンテンツをダウンロードすることを指示されたブラウザアプリケーション（例えば６０1）は、そのアクションがその指示に従う以前に許可されるかどうかを調べるであろう。判定を得るために、アプリケーション６０1は、所望のアクションを識別する名前等およびポリシー固有の引数を含むアクション情報を、要求６８（例えばＣＯＭ要求オブジェクト）の中へバンドルし、判定を要求するインテリジェントトラストマネージャ６２のメソッドを呼び出す。代わりに、１つまたは複数の引数をシステム内で代わりの位置に保持してもよく、この場合、その位置は前もってポリシーに知られ、またはその位置はアプリケーション６０1によって識別される。さらに、アプリケーション６０1はインテリジェントトラストマネージャ６２に任意の証明を渡してもよい。例えばそれは、ある権利を以ってあるファイルにアクセスするために要求されるセキュリティの識別子等である。ここで説明される実施形態において、アプリケーション６０1は、ポリシーが望む引数はもちろん、どのポリシーを呼び出しているかを知る必要がある点に留意されたい。しかしながら、代わりに、アプリケーション６０1は、利用可能なポリシーおよび／またはそれの任意の要求を確かめるように、インテリジェントトラストマネージャ６２に問い合わせてもよい。
【００１６】
インテリジェントトラストマネージャ６２は要求６８を受信する時、インテリジェントトラストマネージャ６２はその中の引渡された情報から、アクション識別子（ＩＤ）を抽出する。インテリジェントトラストマネージャ６２は、ＩＴＭポリシーマネージャ６４にポリシーの名前を与え、それにより対応するポリシーオブジェクト（例えば６６3）のインスタンスが生成される。ＩＴＭポリシーマネージャ６４は、レジストリ７０（例えば、データベース、ライブラリ、テーブルまたはそのような物）へのアクセスを含み、または別に有し、レジストリ７０は各アクション識別子を適切なポリシーオブジェクトへマップするということに留意されたい。より詳しくは、トラストポリシーはＩＴｒｕｓｔＰｏｌｉｃｙインタフェースを実施するＣＯＭオブジェクトである。ポリシーはアクションのための特有の要求に関する判定に対して問い合わせを受けると、入力でＩＴｒｕｓｔａｂｌｅインタフェースを実施する別のＣＯＭオブジェクトへのポインタを受信し、出力としてＴｒｕｓｔｅｄ、Ｃｏｍｐｌｅｔｅｌｙ  ＴｒｕｓｔｅｄまたはＵｎｔｒｕｓｔｅｄを返す。ＩＴｒｕｓｔａｂｌｅインタフェースは、アクションのためのアプリケーションの特定の要求をカプセル化するために使用される。
【００１７】
例として、上述のブラウザを考えてみる。そこにおいては、コンテンツをサイトからダウンロードすべきかどうかについて、判定が必要とされる。要求６８において、アプリケーション６０1は、”Ｆｅｔｃｈ−ＵＲＬ”と呼ばれるアクションを識別し、また、引数としてサイト（例えばｗｗｗ．ｓｉｔｅ１．ｃｏｍ）のＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ）をインテリジェントトラストマネージャ６２へ引渡す。インテリジェントトラストマネージャ６２は、そのアクション識別子”Ｆｅｔｃｈ−ＵＲＬ”を取得し、ＩＴＭポリシーマネージャ６４を介して、対応するポリシーオブジェクト６６3、例えば本例における”ＵＲＬ．ｄｌｌ”を探索しインスタンスを生成する。
【００１８】
一度対応するポリシーオブジェクト６６3のインスタンスが生成されると、インテリジェントトラストマネージャ６２は適切な引数７２（任意の証明を含む）をそこへ転送し、ポリシーオブジェクトへ引渡すと有用であろう任意のコンテキスト７４も一緒に転送する。例えば、インテリジェントトラストマネージャ６２は、マシンの状態に関する情報、スタック情報、アプリケーション６０1に関する情報等をポリシーオブジェクト６６3へ引渡してもよく、例えばこの場合は、インテリジェントトラストマネージャ６２が、そのような情報はポリシーオブジェクト６６3にとって判定を行う時に役に立つであろう、ということを知る、またはさもなければ信じる時である。
【００１９】
この時、ポリシーオブジェクト６６3は、判定を行うためにその内部コードを実行する。もし回答が、利用可能な情報に基づいて、”Ｙｅｓ”または”Ｎｏ”のようにすぐに判定されると、ポリシーオブジェクト６６3は、インテリジェントトラストマネージャ６２を介してその判定７６をアプリケーション６０1に返す（あるいはまた、ポリシーオブジェクトが、その判定および付随する情報をアプリケーションに直接返す方が、適切であるけれども）。判定７６と一緒に、ポリシーオブジェクト６６3は、判定を行うための根拠のような情報を返してもよい。同様に、望むべくは、インテリジェントトラストマネージャ６２は、その返す情報を補足し、（任意に）補足された判定７８を提供してもよい。このように、システムコンポーネント（例えばアプリケーション）は、望むようにその要求を修正してもよい。例えば、回答としてセキュリティ識別子が必要なので、読み／書きのアクセスのためにファイルにアクセスするための判定が”Ｎｏ”である場合、要求しているシステムコンポーネントは、セキュリティ識別子をその要求にバンドルして、２度目の要求をリトライすることを選択してもよい。
【００２０】
さらに、ポリシーオブジェクト（６６3）は、現在、それに対して利用可能な情報に基づいて決定を行うことができないということ（例えば、”Ｉ  ｄｏｎ’ｔ  ｋｎｏｗ”）を応答してもよい。そのような応答と一緒に、ポリシーオブジェクトは、”Ｙｅｓ”または”Ｎｏ”の判定を行う必要があるという情報を規定するリスト等を返してもよい。例えば、ファイルをダウンロードすべきかどうかについての判定は、どのバージョンのアプリケーションが使用されているかに依存してもよい。そのバージョン情報が、例えば、ポリシーオブジェクトによって独立的に決定されない場合、ポリシーオブジェクトは、決定を行うことができず、理由としてバージョン情報の不足を確認しているということを応答してもよい。アプリケーションはそのあと、可能ならば、次の要求内にその情報を供給してもよい。
【００２１】
本発明の１つの形態によれば、ポリシーオブジェクトは動的な決定を行うことができ、それはシステムコンポーネント（例えば、アプリケーション）から独立した、それが取得する（即ち、受信する、或いは別に知っている）付加的で多様な情報に基づいて行われる。
【００２２】
例えば、インテリジェントトラストマネージャ６２によって引渡されるコンテキスト７４は、判定を要求するシステムコンポーネントと独立していてもよく、ほかの”Ｙｅｓ”回答を”Ｎｏ”回答にしたりその逆を行ってもよい。さらにポリシーオブジェクトは、システムコンポーネントから完全に独立したそれの有するユーザインタフェース８０を介して、ユーザとコミュニケーションしてもよい。
【００２３】
例として、もし親最優先パスワードが与えられない場合、ＵＲＬ．ｄｌｌポリシー６６3は、レイティング（ｒａｔｉｎｇ）ガイドラインを超えるどのようなウェブサイトコンテンツに対しても”Ｎｏ”判定を返すように記述されていると仮定する。この例の目的のために、ブラウザアプリケーション６６1はレイティングを知らず、サイトのコンテンツをダウンロードするかまたはポリシーの決定に従いそのようにしないかのどちらかに制限されていると仮定してもよい。実際には、ここで説明されるように、現状のブラウザがそのようなレイティングポリシーを含む限り、本発明はポリシーをブラウザアプリケーションに組み入れることに対する必要性を不要にする。それによって、将来的なブラウザはレイティングポリシーをそれほど有しなくともよい。
【００２４】
要求がｗｗｗ．ｓｉｔｅ１．ｃｏｍにおける判定のために発生する場合、ポリシーオブジェクト６６3は、要求されたコンテンツのレイティングを決定するために、そのサイトと通信するためのコードを含む。レイティングに基づき、ポリシーオブジェクト６６3は、すぐにその判定を行ってもよい。即ち、あるレイティング閾値より小さければ、”Ｙｅｓ”を応答する。しかしながら、あるレイティング閾値を越えるコンテンツに”Ｎｏ”を応答するよりむしろ、ポリシーオブジェクトそれ自身がユーザインタフェース８０を介して通信するように記述され、親最優先パスワードを得るようにしてもよい。注目すべきことは、ポリシーオブジェクト６６3は情報が到来するように動的に調達することが可能であり、アプリケーション６０1とは独立する必要があるが、動的に付加情報を取得する点である。
【００２５】
本発明のもう１つの形態によれば、ポリシーオブジェクトは、インスタンスの生成の間でも、および、もし必要なら、ファイル等に状態データを書き込むことにより永続的にでも、多様な状態情報８２を保持できる。状態情報８２は、動的に判定を行うために使用され、システムコンポーネントから独立している。例えば、会社のマネージャの購入が全体として、一月あたり１０、０００ドル以下の総計である限り、マネージャはある是認されたインターネットサイトからその会社のために品目を購入できるようにセットアップされたポリシーを考える。そのサイトを照会することに加え、要求された購入額をそのポリシーオブジェクト内に状態情報８２として保持された累積月間総計に一時的に加えることにより、その適当なポリシーオブジェクトは動的な判定を行い、要求された購入を許可すべきか否かを判定する。実際には、さらに動的に、そのポリシーオブジェクトはそのサイトから価格を取得し、要求購入総額を決めるために要求量で乗じる。いずれにせよ、月の制限に満たないのなら、”Ｙｅｓ”判定が返され、総計は増やされる。”Ｎｏ”の場合は、より小さな購入品が次回代わりに是認される。このように、ポリシーオブジェクトは、累積された多様な総計に対する提示された総額（またはできれば品目と量）に基づいて、動的に判定する。理解されるように、購入フォームを提示するシステムコンポーネント（例えば、アプリケーション）は、総計について何も知る必要はなく、サイトのＵＲＬおよび要求総額（または量と品目情報）にパスしさえすればよい。これは、制限を増やすことによるようなポリシーを変更することを、相対的に簡単にし、しかしながら確実にすることに留意されたい。制限の必要性だけは、アプリケーションのマネージャの個別のコピー毎よりむしろ、ひとつの確実で集中した位置で変更されるべきだからである。
【００２６】
発明のもう１つの形態によれば、ポリシーは判定を行うために、数学的に結合されるかおよび／または階層的な方法で作られてもよい。この目的のために、ポリシーは他のポリシーを呼び（他のポリシーは、順にさらに他のポリシーを呼ぶことができる）、最終判定を行うためにそれらの判定を使用することができる。例えば、図５から図８に示されるように、ポリシーが”Ｙｅｓ”を判定してもよいのは、その下の２つの他のポリシーが両者とも”Ｙｅｓ”を判定した場合（図５、ブールのＡＮＤ）のみ、２つのポリシーの１つが”Ｙｅｓ”を判定した場合（図６、ブールのＯＲ）のみ等である。ポリシーはまた投票体系を実施して、例えば、それが呼び出すｎ個の内のｍ個（例えば、５個の内の３個）のポリシーが”Ｙｅｓ”を判定する場合（図７）、アクションに対して”Ｙｅｓ”を判定する。
【００２７】
さらに、ポリシーは、それの判定の行い方をそのポリシーに知らせる引数を受け取るように、柔軟に記述されてよい。例えば、論理演算子（例えば、ＡＮＤ、ＯＲ、ＸＯＲ）と一緒に２個または３個以上の他のポリシーの名前を引数として取り、論理演算子によって結合されたような他のポリシーの結果に基づく結果を返すブールのポリシーが存在してもよい。同様に、１つの”Ｙｅｓ”票を返すために、他のポリシーからの必要な”Ｙｅｓ”票の総数を入力として取る”投票”ポリシーが存在してもよい（そこでは、他のポリシーの名前は投票ポリシーオブジェクトへ、引数として引渡されてもよいしまたは既に知られていてもよい）。結果情報はまた、ポリシーに渡されてよい。例えば、あるシステムコンポーネントに対して、３個または２個以下の”Ｙｅｓ”票はｙｅｓを返すが、４個または５個以上は”Ｎｏ”を返し、一方、別のシステムコンポーネントに対しては、１個または２個以上の”Ｙｅｓ”票が”Ｙｅｓ”結果のために必要とされる。
【００２８】
代わりの実施形態において、ポリシーオブジェクトは特有のブール代数体系を使用して結果を返してもよく、それは”Ｔｒｕｓｔｅｄ，  Ｃｏｍｐｌｅｔｅｌｙ  ＴｒｕｓｔｅｄおよびＵｎｔｒｕｓｔｅｄ”モデルに基づく。一般に、”Ｔｒｕｓｔｅｄ”は”Ｙｅｓ”に対応し、”Ｕｎｔｒｕｓｔｅｄ”は”Ｎｏ”に対応し、一方、”Ｃｏｍｐｌｅｔｅｌｙ  Ｔｒｕｓｔｅｄ”は”Ｙｅｓ、およびさらに処理をしない”に対応する。”Ｃｏｍｐｌｅｔｅｌｙ  Ｔｒｕｓｔｅｄ”結果は、サブポリシーが判定を行うために投票する状況において役に立ち、ある（”Ｃｏｍｐｌｅｔｅｌｙ  Ｔｒｕｓｔｅｄ”）サブポリシーは他より多くの重みを与えられる。容易に理解されるように、他の体系（例えば、サブポリシー達がそれらの重みに基づいて多種多様な票を返すことができる）がまた、実施されてもよい。
【００２９】
さらに、ポリシーは他のポリシーを呼び出すことができるので、ポリシーは他のポリシーを選択することによって、それの判定を行ってよい。これは、ユーザ側の記録されて物の数または一日の時刻のような、実質的に任意の多様な基準に基づく。図８と一緒に以下の擬似コードは、この概念を表しており、そこでは、一般的なＵＲＬポリシーによれば、２つの特定のＵＲＬポリシー（ＵＲＬ−ｗｏｒｋｉｎｇ−ｈｏｕｒｓまたはＵＲＬ−ａｆｔｅｒ−ｈｏｕｒｓ）の１つは、事実上、一日の時刻に依存している：
【００３０】
【数１】
0003965020.tif 000002
【００３１】
ＵＲＬポリシーの判定を要求するシステムコンポーネントは、どのポリシーが実際に有効であるかについて何も知る必要がない。それというのも、それはＵＲＬポリシーからアクションに係る判定を要求するだけだからである。ＵＲＬポリシーはシステムコンポーネントに知られておらず、判定を行うために他の２つのポリシーの１つを呼び出す。もちろん、そのような簡素化された例が単一のポリシーにおいて実施されてよいと同時に、ポリシーをますます複雑なポリシーに結合するための能力によって与えられる利点と融通性は、容易に理解される。例えば、上記の例の”ｗｏｒｋｉｎｇ−ｈｏｕｒｓ”ポリシーは高度に複雑で整然と修正されてもよく、一方”ａｆｔｅｒ−ｈｏｕｒｓ”ポリシーは単純であり、けっして変えられず、要するにもとのままでよい。
【００３２】
本発明に必要ではないけれども、ポリシーの管理を容易にするために、マネジメントツール（ＩＴＭアドミニストレータ）８４が提供される（図２）。マネジメントツール８４は、一度にオペレーティングシステム、システムコンポーネントおよびアプリケーションの操作に作用しながら、アドミニストレータ達がポリシーを見て集中的に調整することを可能とし、それはシステムが提供する構成エディタ８６（図９）を使用する。容易に理解されるように、この単一の集中化されたツールは、多種多様な広範囲に及ぶアプリケーションに特化したユーティリティにより、大変便利な物である。マネジメントツール８４はＩＴＭポリシーマネージャ６４と通信し、ポリシーを見て調整するためのエディタインタフェース８６（図９）を表示する。ポリシーはＣＯＭオブジェクトなので、それらは論理的な階層制のグループ化におけるフォルダ下に整理されてもよい。従って、図９に示されるように、アドミニストレータ達は、”Ｉｎｔｒａｎｅｔ”フォルダ下の”Ａｃｔｉｖｅ  Ｃｏｎｔｅｎｔ  Ｐｏｌｉｃｙ”のように、ポリシーを素早く置けるだろう。
【００３３】
さらに、図３に表されているように、各ポリシーオブジェクトできればそれ自身のアドミニストレータユーザインタフェース８８を含む。アドミニストレータのマウスが命名されたポリシーをクリックするか別に適切に選択する時、アドミニストレータユーザインタフェース８８はオープンされる。これは簡単なパッチ、更新およびそのような物を備える。例えば、上述のように、ポリシーオブジェクト内の状態として保存される購入制限が、アドミニストレータユーザインタフェースを介してアドミニストレータによって調整されてもよい。本発明に関して、システムコンポーネントは直接特別なダイナミックリンクライブラリ（ｄｌｌ）に拘束されていないこと、および、このようにポリシーは、システムコンポーネント（例えば、アプリケーション）を修正する必要またはそれらを設定することなしに変更されてよいことに留意されたい。
【００３４】
ポリシーオブジェクトそれ自身は、使用される他のポリシーオブジェクトおよびそれらが如何に使用されるかを支配することに留意すべきである。例えば、認証されているアドミニストレータが変更を行い、かつポリシーオブジェクトのデジタル署名が最初に照合される場合でないでないと、他のポリシーオブジェクトが追加されまたは変更されることを許可しないと判定するポリシーオブジェクトが存在してもよい。言い換えれば、支配しているポリシーは、ポリシーが登録される以前にデジタル署名の照合を要求する。同様に、ポリシー上のデジタル署名を最初に照合しないで呼び出されるポリシーはないことを、ポリシーが保証してもよい。
【００３５】
ポリシーオブジェクトは前もって（例えば、サードパーティによって）記述され、パッケージ９０（図２）または所与のシステムにとって適したそのような物へグループ化できる。このように、ユーザは、適切なポリシーパッケージをインストールする必要があるだけであり、そこから必要とされる時にポリシーを修正する。例えば、ホームユーザおよび小ネットワークのためのポリシーオブジェクトは、企業ネットワークのポリシーよりかなり異なるように思われる。
【００３６】
実際に、企業ネットワーク内では、アドミニストレータはしばしば、多くの何百ものマシン、ユーザおよびシステムコンポーネントを制御する必要がある。そして、アプリケーションのようなシステムコンポーネントがそのようなアドミニストレータのために明示的なサポートを有しない場合、そのシステムコンポーネントはかなり難しいであろう。
【００３７】
本発明は、企業ネットワーク全体に適用するポリシーの生成と実施を可能とする。例えば、企業のポリシーは、その企業のイントラネットの外部から署名無しで実行できる物のダウンロードを不可能とし、署名されたコードをダウンロードする前にユーザに尋ねるが、ユーザの介入無しでイントラネットから任意のコードをインストールするようになっていてもよい。気にかかるかもしれないが、このポリシーはドメイン全体に適用される必要がある。即ち、あらゆるユーザが影響を受けなければならない。ドメイン全体の管理を容易にするために、本発明のインテリジェントトラストマネジメントシステムは、アドミニストレータ達がいくつかのポリシーを”ドメイン全体”として指定できるようにする。それにより、ポリシーは自動的にドメインに参加しているあらゆるマシンに複製され、それにより、これらのポリシーはユーザ一人一人に影響を及ぼす。
【００３８】
最後に、上述のモデルは、ポリシーの判定に従うのはシステムコンポーネント（例えば、アプリケーション）次第である、という忠告である一方、それは実施モデルを有するために実現可能である。実施モデルでは、ポリシーの判定はアプリケーションが否定されたアクションを行うことを防ぐ。例えば、アプリケーションは、ポリシーによってセットアップされたセキュリティコンテキスト中でラン（ｒｕｎ）されてもよく、それにより、そのポリシーおよび他の呼び出されたポリシーはそのアプリケーションのシステムリソースへのアクセスを決めるであろう。
【００３９】
本発明は種々の修正および代替の構成が可能であるが、その中のある例示の実施形態が図面中に示され、詳細に説明されている。しかしながら、開示された特定の形態に本発明を限定する意図は無く、反対に、その意図は全ての修正、代替の構成、およびその本発明の精神と範囲内にある同等のものを含むことにあるということが理解されるはずである。
【図面の簡単な説明】
【図１】  本発明が含まれるコンピュータシステムを表すブロック図である。
【図２】  本発明の概念モデルを一般に表すブロック図である。
【図３】  本発明のトラストマネジメントシステムを実現するための種々のコンポーネントを一般に表すブロック図である。
【図４】  ポリシーの判定を生成するトラストマネジメントシステムの種々のコンポーネントによって処理されるステップを表すタイミングチャートである。
【図５】  多数のポリシーが、最終的な判定を生成するために如何にして結合されるかを示す種々の例を示すブロック図である。
【図６】  多数のポリシーが、最終的な判定を生成するために如何にして結合されるかを示す種々の例を示すブロック図である。
【図７】  多数のポリシーが、最終的な判定を生成するために如何にして結合されるかを示す種々の例を示すブロック図である。
【図８】  多数のポリシーが、最終的な判定を生成するために如何にして結合されるかを示す種々の例を示すブロック図である。
【図９】  ポリシーオブジェクトを集中的に管理するためのエディタ機構の説明図である。
【図１】
0003965020.tif 000003
【図２】
0003965020.tif 000004
【図３】
0003965020.tif 000005
【図４】
0003965020.tif 000006
【図５】
0003965020.tif 000007
【図６】
0003965020.tif 000008
【図７】
0003965020.tif 000009
【図８】
0003965020.tif 000010
【図９】
0003965020.tif 000011