リスク検知、レポート機能、及びインフラストラクチャのためのシステム及び方法
少なくとも１つのビジネスプロセスに関連するリスクを監視する方法、システム、及び装置であって、複数のドキュメントインスタンスの中の少なくとも１つを評価する段階であって、ドキュメントインスタンスの各々は、それに関連して、複数のリスクカテゴリに対して複数のドキュメント値を含むようになっている段階と、少なくとも１つのビジネスプロセスに承認された少なくとも１つの受諾可能なリスクポリシーに従って、リスクカテゴリの複数を実行する段階と、少なくとも１つのリスクカテゴリの中の少なくとも１つのドキュメントの承認レートに従って、複数のドキュメントの中の少なくとも１つに適格性を付与する段階と、を含む。このシステム、方式、及び装置は、効率的にリスクを監視し、柔軟性のあるリスクポリシーの修正又は更新を可能にする。
【発明の詳細な説明】
【発明の詳細な説明】
【０００１】
（関連出願への相互参照）
本出願は、２００３年６月９日に出願された米国仮出願番号６０／４７６，６２８の優先権を主張する。
【０００２】
（技術分野）
本発明は、リスク管理分野に関し、詳細には、レビュー、メッセージング、インフラストラクチャ、及びリスク状態に関するドキュメント及びメッセージの関連プロセスを含む、システム及びサブコンポーネントのリスク解析に関する。
【０００３】
（背景技術）
リスク評価及びリスクに基づく意志決定は一般的である。例えば、銀行及び投資機関は、リスクを評価して、これらのリスク評価に基づいて投資、融資、及び他の取引リスクを決定する。例えば、金融機関は、取引先企業と取引するために、特にタイプ、コスト、及びアプローチに関して決定を行うにあたって外国為替（ＦＸ）リスク、信用リスク、与信リスク、及び運用リスクなどのリスクを調査することがある。保険会社は、リスク対報酬を評価する同様の決定を行い、損害賠償請求及び見込み損害賠償請求の大きさの確率に基づいて保険証券を発行する。本例では、利用可能で適切な履歴データは、現在及び将来のアクションに関する意思決定をサポートするために使用される。
【０００４】
リスクを評価してリスク評価に基づいてアクションの決定をサポートする技術が開発されている。しかしながら、ビジネスプロセスにおけるリスク管理のプロセス及びアーキテクチャは、歴史的にいって１つ又は多数のローカル（内部）及び外部（相互）のビジネス及び技術領域にわたって展開することは困難である。更に、既存のシステムにおいて、リスクに基づく決定が行われると、実施予定の取引の拒絶、又は新規取引又は移行の開始（例えば、保険の再精算、保険の適格性を得る又は取得すために、自動的に行うため及び／又は販売するため）、及び／又は適切な担当者への警告通知を含む、様々なアクションを実施することが困難な場合がある。
【０００５】
データセキュリティ制御は、データシステム（例えば、ネットワーク及びコンピュータ）に関してリスク評価を利用する。受諾可能及び受諾不可なものを示し、「署名」への注意を含むことができる特定のポリシーに基づいて、適切なアクション又は不適切なアクション（ホスト／ネットワークシステム上のアクション）のパターンは、許可又は拒否される。履歴情報は、受諾可能なアクションを過去のアクションに基づいて部分的に決定するために保持できる。従って、現在及び／又は将来においてアクションは、過去に許可されたアクションに基づいて許可又は拒否される。このようなデータセキュリティ制御の１つの手段は、本技術分野においてファイアウォールとして公知である。
【０００６】
侵入検知システム（ＩＤＳ）は、コンピュータシステム及びネットワークで利用できる。ＩＤＳは、権限のないコンピュータの使用を検知及び識別するために利用できる。一般に、ＩＤＳは、ログ、ネットワークトラフィック、ファイル修正、及び他の利用可能なソースを介して、悪意ある行為を検知するために特定のパターン又は署名を探す。これらの署名は、有限状態マシン、簡単なパターンマッチング、又は特別なアルゴリズムを用いて識別される。多くのＩＤＳは、偽陽性及び偽陰性の警告を発する傾向がある。偽陽性は、ＩＤＳが問題（例えば、権限のない行為）を識別したがその問題が起きていない場合に発生する。偽陰性は、問題が起きたときにＩＤＳが問題を検知しなかった場合に発生する。
【０００７】
履歴データの信頼性及び偽陽性及び偽陰性の可能性を考慮すると、ネガティブパターンの単なる署名は、システムを完全に保護するために望ましいが十分ではない。ネガティブ署名アプローチは、許可されていないものの識別を解決する。補完的アプローチ、つまりポジティブ署名アプローチは、許可されるもの又は少なくとも許容偏差内で受諾可能なものを具体的に定義する。
【０００８】
本明細書ではポリシーとも呼ぶルールは、具体的に許可されるアクション及び／又は具体的に拒否されるアクションを表す。ルールは、取引が行われるパラメータを指定する。動的ルールは、応答が様々な検討に基づいて変化する等の、特定の入力等に応じて様々な応答が経時的に変化するようなルールである。
【０００９】
理想的には、ＩＤＳテストに使用されるルールは動的ルールであろう。しかしながら、ルールはセキュリティシステムのバイナリコードの一部として「ハードコード」される場合が多いので、ルールは一般に真に動的ではない。動的ルールの欠如は、例えば、セキュリティソフトウェアが更新された場合（例えば、実行可能コードが長くなって遅くなり、アップグレードするためにマシンを停止する必要がある場合）を含む、様々な状況で問題を起こす。
【００１０】
更に、ビジネスプロセスは、一般にこれらのビジネスプロセスを操作するコンピュータシステムへの侵入に関連するルールよりもはるかに複雑である。例えば、情報フローは複数の入口から到来するいが、中心点に届かない場合がある。動的ルールの欠如を隠してビジネスプロセスの絶えず増加する複雑性を償うために、ネットワークベースのファイアウォールは、一般にＮＡＴとして公知のネットワークアドレス変換又は一般にＰＡＴとして公知のポートアドレス変換を介して、ＩＰアドレスを変更して具体的な内部ネットワーク構成を隠すことができる。しかしながら、メッセージングのコンテキストは、この種の「処置」ではコンテンツの外観が変更されるとはいえ同じ状態のままである。この種の処置は、特定の取引タイプのビジネスプロセスの変更又は終了を隠すために又は是正するために役立たず、同様に特定の取引又は状態の許可又は不許可を経時的に変更するのに役立たない。更にこの種の処置では、企業間分散プロセス全体にわたる様々なリスクが識別され解決される単純な方法で、動的に追加されることになる様々な監視技術又は制御技術を考慮することができない。
【００１１】
従って、効果的にリスクを監視すると共にリスクポリシーを変更又は更新する柔軟性を許容するシステム、方法、及び装置に対するニーズが存在する。
【００１２】
（発明の開示）
本発明は、各々がそれに関連して複数のリスクカテゴリに対して複数のドキュメント値を含む複数のドキュメントインスタンスの少なくとも１つを評価する段階と、少なくとも１つのビジネスプロセスに承認された少なくとも１つの受諾可能なリスクポリシーに従って複数のリスクカテゴリを実行する段階と、少なくとも１つのリスクカテゴリの少なくとも１つのドキュメントの承認評定に従って複数のドキュメントの少なくとも１つに適格性を与える段階とを含む、少なくとも１つのビジネスプロセスに関連するリスクを監視する方法、システム、及び装置を備えている。
【００１３】
つまり、本発明は、効果的にリスクを監視すると共にリスクポリシーを変更又は更新する柔軟性を許容にするシステム、方法、及び装置を提供する。
本発明は、添付図面と共に本発明の以下の詳細な説明を検討することで容易に理解できるであろう。図面中、同じ数字は類似の部分を示している。
【００１４】
（発明を実施するための最良の形態）
本発明の図面及び説明は、本発明を明確に理解するのに関連する要素を示すために簡略化されており、一般的な情報装置、機器、システム、及び方法に見いだされる多数の他の要素は明瞭にするため取り除かれていることを理解されたい。当業者であれば、本発明を実施するために他の要素が望ましいこと及び／又は必要であることを理解できるであろう。しかしながら、このような要素は、本技術分野では公知であり、これらは本発明の一層の理解を助けないので、このような要素の説明は本明細書では行わない。本明細書の開示は、全てここに開示され当業者には公知の又は明らかなアプリケーション、ネットワーク、システム、及び方法の変形例及び変更例に向けられている。更に、本発明は、本明細書全てに例示的に説明されているが、当業者であれば、本明細書開示に基づいて、本発明が無数の商取引及び処理に好都合に採用できることを理解できるであろう。
【００１５】
図１は、リスクポリシー１０７に対して複数の値１０４を含むドキュメント１０１の評価を示すフローダイアグラムである。ドキュメント１０１は、Ｗｅｂアクセス、Ｗｅｂサービス、ゲートウェイ、光学的文字認識（ＯＣＲ）又は走査等によって電子的形式に変換された物理的ドキュメントを介して、又は当業者に公知の任意の類似の方法によって図示のシステムに提供することがきる。本発明は、ドキュメント又はその電子的形式に変換されたものが提供される方法に限定されるものではない。
【００１６】
本明細書で用いる場合、ドキュメント１０１は、ビジネスシステム又はプロセスにとって重要な値であり、又はその値を表す。値は、本技術分野で公知のように、例えばレコード内のフィールドである。ドキュメント１０１は、最初は書面ベースの定義又は構造を有するか、又は確立された又は構造化されたデータソースの１つ又はそれ以上のドキュメントのサブセット又はスーパーセットである。この種のデータソース又は書面ベースの定義は、他のソースから取得した値を含む、値を含むことができる。ドキュメント１０１への参照は、限定されるものではないが、ドキュメント内の全てのフィールドへの参照である。
【００１７】
ドキュメントは、ＲＤＳシステム及びそれに関連するインフラストラクチャに定義することができる。例えば、スクリプト言語、又はＧＵＩ（グラフィックユーザインタフェース）を実行する技術、又は他の表現を使用することができる。本発明の１つの態様によれば、ＸＭＬ［ＸＭＬ］などの拡張言語を使用することができる。ここで使用されるＸＭＬは、『Ｓｕｒｖｅｙ Ｓａｍｐｌｅ：Ｗｅｂ Ｆｏｒｍ Ｄｅｓｉｇｎ ｉｎ ＡＳＰ．ＮＥＴ』（Ａｌｌｅｎ Ｗａｇｎｅｒ著）に基づく。
ＸＭＬコードの例を以下に示す。
【００１８】
（ＸＭＬ−Ａ）
＜Ｄｏｃｕｍｅｎｔ Ｔｉｔｌｅ＝”ＢｕｉｌｄｉｎｇＳｅｃｕｒｉｔｙ” ＳｏｕｒｃｅＴｙｐｅ＝”ＵｓｅｒＷｅｂＩｎｐｕｔ” Ｓｏｕｒｃｅ＝”ｗｗｗ．ｘｘｘ．ｃｏｍ／ｓｕｒｖｅｙ”＞ ＜Ｄｅｓｔｉｎａｔｉｏｎ＝ ”ＭａｓｔｅｒＤＢ．ＢｌｄＳｅｃｕｒｉｔｙ”＞
＜Ｑｕｅｓｔｉｏｎ ＩＤ＝”０” ｖｉｓｉｂｌｅ＝”ｙｅｓ” Ｔｅｘｔ＝”Ｂｕｉｌｄｉｎｇ Ｎｕｍｂｅｒ？” Ｔｙｐｅ＝”Ｎｕｍｅｒｉｃ”＞
＜Ａｎｓｗｅｒ Ｔａｇ＝”Ｂｕｉｌｄｉｎｇ Ｎｕｍｂｅｒ” ＰｒｉｍａｒｙＫｅｙ＝”ＢＬＤ”＞
＜／Ｑｕｅｓｔｉｏｎ＞
＜Ｑｕｅｓｔｉｏｎ ＩＤ＝”１” ｖｉｓｉｂｌｅ＝”ｙｅｓ” Ｔｅｘｔ＝”Ｗｈａｔ ｃｏｕｎｔｒｙ ｉｓ ｂｕｉｌｄｉｎｇ ｉｎ” Ｔｙｐｅ＝”Ｃｈａｒａｃｔｅｒ”＞
＜Ａｎｓｗｅｒ Ｔａｇ＝”ＣｏｕｎｔｒｙＶａｌｕｅ”＞
＜／Ｑｕｅｓｔｉｏｎ＞
＜Ｑｕｅｓｔｉｏｎ ＩＤ＝”２” ｖｉｓｉｂｌｅ＝”ｎｏ” Ｔｙｐｅ＝”ｒｅａｌ”＞
＜Ａｎｓｗｅｒ Ｃｏｍｐｕｔｅ＝ＣｏｕｎｔｒｙＲｉｓｋＴａｂｌｅ（ＣｏｕｎｔｒｙＶａｌｕｅ）．ｒｉｓｋｖａｌｕｅ ＊ ４＞
＜／Ｑｕｅｓｔｉｏｎ＞
＜Ｑｕｅｓｔｉｏｎ ＩＤ＝”３” ｖｉｓｉｂｌｅ＝”ｙｅｓ” Ｔｅｘｔ＝”Ａｒｅ Ｆｅｎｃｅｓ ｈｉｇｈｅｒ ｔｈａｎ １０ ｆｅｅｔ？” Ｔｙｐｅ＝”ｉｎｔｅｇｅｒ”＞
＜Ａｎｓｗｅｒ ＩＤ＝”１” Ｔｅｘｔ＝”Ｙｅｓ”＞
＜Ａｎｓｗｅｒ ＩＤ＝”２” Ｔｅｘｔ＝”Ｎｏ”＞
＜／Ｑｕｅｓｔｉｏｎ＞
＜Ｑｕｅｓｔｉｏｎ ＩＤ＝”４”， ｖｉｓｉｂｌｅ＝”ｙｅｓ” Ｔｅｘｔ＝”Ｄｏ ｆｅｎｃｅｓ ｈａｖｅ ｂａｒｂｅｄ ｗｉｒｅ？” Ｔｙｐｅ＝”ｍｕｌｔｉｐｌｅ ｃｈｏｉｃｅ＞
＜Ａｎｓｗｅｒ ＩＤ＝”１” Ｔｅｘｔ＝”Ｙｅｓ”＞
＜Ａｎｓｗｅｒ ＩＤ＝”２” Ｔｅｘｔ＝”Ｎｏ”＞
＜／Ｑｕｅｓｔｉｏｎ＞
＜／Ｄｏｃｕｍｅｎｔ＞
【００１９】
本発明の本態様によれば、ｓｕｒｖｅｙ等のドキュメント１０１を指定できる。このドキュメント仕様はデータ定義を作成できるが、当業者であれば既存のデータベース定義を組み込むための他の方法を理解できるであろう。ＳｏｕｒｃｅＴｙｐｅは、一次キーＢＬＤを備えるＭａｓｔｅｒＤＢ．ＢｌｄＳｅｃｕｒｉｔｙ等のデータベース内の適切なレコードに情報を保存するＷｅｂベース入力とすることができる。配置されるＷｅｂサイトは、本例ではｗｗｗ．ｘｘｘ．ｃｏｍ／ｓｕｒｖｅｙである。
【００２０】
Ｑｕｅｓｔｉｏｎ（質問）はＩＤを用いて番号付けを行い、本例では「Ｖｉｓｉｂｌｅ」フラグが「Ｙｅｓ」か否かに基づいて表示される。本例では、表示される質問は「Ｔｅｘｔ」で提供され、応答タイプは「Ｔｙｐｅ」で提供される。Ｔｙｐｅは、限定されるものではないが、「ｃｈａｒａｃｔｅｒ（文字）」、「ｎｕｍｅｒｉｃ（数値）」、「ｆｒｅｅｆｏｒｍ（フリーフォーム）」、「ｍｕｌｔｉｐｌｅ ｃｈｏｉｃｅ（複数選択）」、Ｂｏｏｌｅａｎ等を指定することができる。他のタイプは当業者には明白であり、適切な又は不適切な入力タイプに照らして確認することができる。
【００２１】
「Ａｎｓｗｅｒ（回答）」は、前述の例では複数の目的があり、通常は送信者の入力を表す。送信者は、例示的に、人物、プロセス、自動化された又は手動の電子的又は機械的入力とすることができる。
【００２２】
「Ｔａｇ（タグ）」は質問の変数名として使用できる。前述の例では、ＣｏｕｎｔｒｙＶａｌｕｅ（ＩＤ＝１で定義）は、ＩＤ＝２の計算フィールドにおいてＣｏｕｎｔｒｙＶａｌｕｅでインデックス付けされたＣｏｕｎｔｒｙＲｉｓｋＴａｂｌｅのリスク値を表示する。本例の質問に対する回答は、本例の入力の間は表示されないが、Ｃｏｕｎｔｒｙのリスク値を４で乗算した値である。
【００２３】
前述の例は、Ｗｅｂベースの入力を示す。当業者であれば、他の入力フォームを提供できることが理解できであろう。例えば、質問が表示されず、データベース等のデジタルフォーマットから「回答」又は入力として、情報にアクセスする問い合わせ等の、電子的問い合わせの形式を取ることができる。質問に応答する入力は、データベース、ディレクトリ、又はフラットファイル等のデータストアの中の情報を表す任意の送信済み電子パケットとすることができる。この場合、データ記述は、入力されることになる値を取得する方法を記述する。例えば、データ記述は、値がデータベーステーブル内の特定のフィールドであること、又はデータ値内のビットＹから始まる先頭Ｘビットであることを記述することができる。「ｖｉｓｉｂｌｅ＝”Ｎｏ”」の場合、質問に応答する入力は、人間の入力から取得したのではなく計算値である。
【００２４】
図４は、「Ｔａｇ」及び「ｃｏｍｐｕｔｅ（計算）」の例示的な使用を示す。同様に、ドキュメント１０１は一連の値を含むことができる。簡単にするため、値１〜値４（前述の行４０２）は本例ではユーザに表示され、その行より下の残りの値はユーザに表示されない。値ｎ ４０３は、図示のように本実施形態では値１のコピーである。値５ ４０５は、データベース４０６等のローカルストアから取得される。値５及び値６はタグで各々識別されるが、このタグは説明を目的としており、それぞれＴＡＧ＿Ｖ５（例えば＜Ａｎｓｗｅｒ Ｔａｇ＝”ＴＡＧ＿Ｖ５”＞）及びＴＡＧ＿Ｖ６として表わされる。より複雑な計算４０４は、セキュリティシステムに必要であり、計算可能な任意の関数ｆであり、表示値及び非表示値を利用することができる。関数ｆの結果は、本例では値６の結果の配置等の必要な又は要求された場所に導くことができる。これは、例えば前述の例のように＜Ａｎｓｗｅｒ Ｃｏｍｐｕｔｅ＝”ＴＡＧ＿Ｖ５＊ＴＡＧ＿Ｖ６”＞としてコード化される。
【００２５】
図１の説明に戻ると、リスクカテゴリ１０２は、リスクを一定の目的を解決する様々なグループに分類でき、１つ又はそれ以上のビジネスプロセスの許容可能なリスクに基づくことができる。例えば［ＢＳ ７７９９］では、情報セキュリティは機密性（Ｃ）、整合性（Ｉ）、及び可用性（Ａ）の維持という特徴がある。リスク管理アプリケーションでは、システムが様々な固有基準又は適用基準に基づいて別々に評価され、この種の評価が同時に解析できることが一般的である。前述の機密性、整合性、又は可用性の等級を用いるＢＳ ７７９９の例では、各々の基準を満たすために必要な制御は異なっており、実際には、一部のケースでは矛盾することがある。例えば、コンテナ出荷では、商品の積込み及び商品のコンテナへの封入を制御するプロセスの評価は、別個の異なる、矛盾する可能性のあるリスク関連基準に基づいて評価される場合がある。
【００２６】
図１で参照されたリスクカテゴリ（Ｒｉｓｋ Ｃａｔｅｇｏｒｉｅｓ）は、限定されるものではないが、例えば、ＸＭＬ又は類似のスキーマで指定することができる。例えば、この種のリスク分類のＸＭＬコーディングを以下に示す。
【００２７】
＜Ｒｉｓｋ Ｃａｔｅｇｏｒｉｅｓ＞
＜Ｃａｔｅｇｏｒｙ Ｎａｍｅ＝”Ｃｏｎｆｉｄｅｎｔｉａｌｉｔｙ” Ｄｅｓｃｒｉｐｔｉｏｎ＝”Ｆｏｒ ｐｒｉｖａｃｙ ｐｒｏｔｅｃｔｉｏｎ”＞
＜Ｃａｔｅｇｏｒｙ Ｎａｍｅ＝”Ｉｎｔｅｇｒｉｔｙ” Ｄｅｓｃｒｉｐｔｉｏｎ＝”Ｆｏｒ ｍｏｄｉｆｉｃａｔｉｏｎ ｏｆ ｄａｔａ”＞
＜Ｃａｔｅｇｏｒｙ Ｎａｍｅ＝”Ａｖａｉｌａｂｉｌｉｔｙ” Ｄｅｓｃｒｉｐｔｉｏｎ＝”Ｆｏｒ ａｂｉｌｉｔｙ ｔｏ ｕｓｅ ｒｅｓｏｕｒｃｅ”＞
＜／ＲｉｓｋＣａｔｅｇｏｒｉｅｓ＞
【００２８】
しかしながら、リスクカテゴリは、リスクの一部の属性の特定のリスク態様ではなく、リスクの一部の属性に対するリスクの集計とすることができる。つまり、集計は、１対１ １０６、多対１ １０９、又は１対多 １０５とすることができる。このように、前述の例示的なＸＭＬ−Ａは、以下のように変更することができる。
【００２９】
（ＸＭＬ−Ｂ）
＜Ｑｕｅｓｔｉｏｎ ＩＤ＝”３” ｖｉｓｉｂｌｅ＝”ｙｅｓ” Ｔｅｘｔ＝”Ａｒｅ Ｆｅｎｃｅｓ ｈｉｇｈｅｒ ｔｈａｎ １０ ｆｅｅｔ？” Ｔｙｐｅ＝”ｉｎｔｅｇｅｒ”＞
＜Ａｎｓｗｅｒ ＩＤ＝”１” Ｔｅｘｔ＝”Ｙｅｓ”＞
＜Ｒｉｓｋ Ｎａｍｅ＝”ＲｉｓｋＣａｔ１” Ｓｃｒｉｐｔ＝”Ａｄｄ（５０）”＞
＜Ｒｉｓｋ Ｎａｍｅ＝”ＲｉｓｋＣａｔ２” Ｓｃｒｉｐｔ＝”Ａｄｄ（２０）”＞
＜／Ａｎｓｗｅｒ｝
＜Ａｎｓｗｅｒ ＩＤ＝”２” Ｔｅｘｔ＝”Ｎｏ”＞
＜Ｒｉｓｋ Ｎａｍｅ＝”ＲｉｓｋＣａｔ１” Ｓｃｒｉｐｔ＝”Ａｄｄ（１０）”＞
＜Ｒｉｓｋ Ｎａｍｅ＝”ＲｉｓｋＣａｔ２” Ｓｃｒｉｐｔ＝”Ｓｕｂｓｔｒａｃｔ（１０）”＞
＜／Ａｎｓｗｅｒ＞
＜／Ｑｕｅｓｔｉｏｎ ＞
【００３０】
ＸＭＬ−Ｂで質問３の応答が「Ｙｅｓ」であれば、５０がリスクカテゴリ１に追加され、２０がリスクカテゴリ２に追加される。Ａｎｓｗｅｒ ＩＤ＝”２”で示すように、減算、加算、除算、乗算、定数又は係数の乗算、又は他の計算関数を利用できる点に留意されたい。更に、計算は各段階で生じることができる。例えば、回答ＡがＹＥＳであれば３を乗算し、その結果が５０より大きければ質問Ｂを質問して応答が回答Ｃであれば３を減算する。更に、１つ、又は多数、又は他のソースのデータを、この種の計算の実行時に取り出すことができる。例えば、関数Ｆは入力値（例えば「Ａｄｄ（ｔｈｉｓＩｎｐｕｔ＊５）」）に対して実行され、応答（つまりｔｈｉｓＩｎｐｕｔ）に５を乗算し、その結果を適切なリスクカテゴリに追加することができる。関数は複雑であってもよく、例えば、Ｊａｖａ（登録商標）又は別の高級言語を用いるプログラミングスクリプトを組み込むといった、他のプログラミング態様を含むことができる。限定されるものではないが、プログラミングスクリプト又は計算は、関数内で値を表すために、又は例えばデータベース又はＷｅｂロケーションテーブル内の値などの値を検索するインデックスとして、ＸＭＬ−Ａに記述されている「ＣｏｕｎｔｒｙＶａｌｕｅ」等のタグ名を指定できる。
【００３１】
リスクカテゴリは、１つ又はそれ以上のリスクポリシー１０７に従って解析することができる。その結果、ドキュメント１０１、詳細にはドキュメント１０１の値は、１つ又はそれ以上の要求されたリスクポリシーに基づいて、リスクポリシーに照らして評価することができる。
【００３２】
以下の例では、複数のルールが適用され、「Ａｃｔｉｏｎ（アクション）」、つまり専門言語又は公知の言語（例えばＢａｓｉｃ、Ｖｉｓｕａｌ Ｂａｓｉｃ、Ｃ、Ｃ＋＋、Ｊａｖａ（登録商標）、Ｐｅｒｌ）を用いるスクリプトは、「Ｃｒｉｔｅｒｉａ（基準）」、つまり真又は偽を返すスクリプトが評価される場合に実行される。当業者には、以下の例が特定の言語に限定されず、例えばＸＭＬで実行できることは明らかであろう。
【００３３】
Ｎａｍｅ： ＜ｐｏｌｉｃｙ ｎａｍｅ＞
Ｒｕｌｅ： ＜ｌａｂｅｌ＞
Ｃｒｉｔｅｒｉａ： ＜ｃｏｎｄｉｔｉｏｎａｌ ｓｃｒｉｐｔ＞
Ａｃｔｉｏｎ： ＜ｓｃｒｉｐｔ＞
Ｐｏｌｉｃｙ−Ｒｕｌｅ：
ＰｏｌｉｃｙＮａｍｅ： ＳｉｌｖｅｒＢｕｉｌｄｉｎｇ
Ｒｕｌｅ： ＲｅｑｕｉｒｅＳｕｐｅｒｖｉｓｏｒ
Ｃｒｉｔｅｒｉａ： （（Ｒｉｓｋｃａｔ１ ＞ ５０） ｏｒ （Ｒｉｓｋｃａｔ２＞１０００）） ａｎｄ （ｒｉｓｋｃａｔ３＞５）
Ａｃｔｉｏｎ： Ｒｅｑｕｉｒｅ（”Ｓｕｐｅｒｖｉｓｏｒ”， ＲＥＤ）； ｅｘｉｔ（）
Ｒｕｌｅ： ＥｍａｉｌＣｏｍｍｅｒｃｅ
Ｃｒｉｔｅｒｉａ： （（Ｒｉｓｋｃａｔ１ ＞ ２０） ｏｒ （Ｒｉｓｋｃａｔ２＞１００））
Ａｃｔｉｏｎ： Ｎｏｔｉｆｉｃａｔｉｏｎ （ｅｍａｉｌ， ”ｗａｒｎｉｎｇ＠ｃｏｍｍｅｒｃｅ．ｃｏｍ”， ”Ｒｅｖｉｅｗ Ｃｏｍｐａｎｙ Ｘ Ｗａｒｎｉｎｇ ｌｏｇｓ”）
Ｒｕｌｅ： Ａｃｃｅｐｔ
Ｃｒｉｔｅｒｉａ： Ｎｕｌｌ
Ａｃｔｉｏｎ： Ａｃｃｅｐｔ（”１ Ｊｕｎｅ ２００４”）
【００３４】
前述の例は上から下に解釈される。以下に注目すべき関数の一部を例示するが、関数はそれらに限定されるものではない。
【００３５】
Ｅｘｉｔ（）：終了し、任意の追加的ルールに照らしたテストを行わない。
Ｒｅｑｕｉｒｅ（＜Ｇｒｏｕｐ＞，＜ＦＬＡＧ＞，＜ｅｆｆｅｃｔｉｖｅ ｄａｔｅ＞）：ドキュメントの受諾は、グループ＜Ｇｒｏｕｐ＞の誰かが受諾することが必要である。ユーザには、ユーザが問題の重要性を理解するのに役立つようにＦＬＡＧ値（例えばＲＥＤ条件）が提供され、＜ｅｆｆｅｃｔｉｖｅ ｄａｔｅ（発効日）＞はグループのユーザがドキュメントを受諾した場合に、ドキュメントのユーザによる受諾の発効日を記述する（つまり、受諾の有効期間）。
【００３６】
Ｎｏｔｉｆｉｃａｔｉｏｎ（＜ｔｙｐｅ＞，＜ｕｓｅｒ ｎａｍｅ＞，＜ｓｕｂｊｅｃｔ＞，＜Ｂｏｄｙ＞）：＜ｕｓｅｒ ｎａｍｅ（ユーザ名）＞に、件名＜ｓｕｂｊｅｃｔ＞、本文＜Ｂｏｄｙ＞の通知を送信する。通知の種類として電子メール、カレンダー、ファックス、自動通話、及び他の形式の通知システムを挙げることができるが、これらに限定されるものではない。緊急通知は、警察、運輸、商業、軍事時、又は他の機関等による優先度の高い応答者アクションに関して政府機関（例えば「９１１」呼び出し）に電話をかけることができる。
【００３７】
Ｓｃｈｅｄｕｌｅ（＜ｄａｔｅ／Ｔｉｍｅ＞，＜ａｃｔｉｏｎｓ ｓｃｒｉｐｔ＞）：これは、特定の日付及び時刻（＜ｄａｔｅ／Ｔｉｍｅ＞フィールド）に実行されることになるアクションスクリプトをスケジュールする。例えば、特定の時刻の後に取引を開始すること又は通知を設定することができる。
Ａｃｃｅｐｔ（＜ｄａｔｅ＞）：インスタンスがポリシーに照らして受諾され、日付フィールド内の日付を含む日付まで有効である。
【００３８】
Ｓｔｏｒｅ（＜ｖａｌｕｅ１＞，＜ｌｏｃａｔｉｏｎ１＞，＜ｖａｌｕｅ２＞，＜ｌｏｃａｔｉｏｎ２＞，．．．）：値１を場所１に、値２を場所２になどと保存する。場所として、例えばデータベースフィールドがある。保存は、例えばローカルストレージ又はインターデータストア又はイントラデータストアに行われる（図５を参照）。
【００３９】
ＰｕｓｈＰｏｌｉｃｙ（＜ｐｏｌｉｃｙ ｄｅｓｃｒｉｐｔｉｏｎ＞：これはポリシーを本システムに設定する又は別のシステムに設定する。例えば、一部の条件セットを満たすことが、他のＲＤＳを処理するＲＤＳインスタンスのポリシー変更を引き起こす。
【００４０】
ＣｒｅａｔｅＴｒａｎｓａｃｔｉｏｎ（＜ｔｒａｎｓａｃｔｉｏｎ ｔｙｐｅ＞，＜ｒｅｃｉｐｉｅｎｔ＞，＜ｆｉｅｌｄ１＞，＜ｖａｌｕｅ１＞，．．．）：ＰｕｓｈＰｏｌｉｃｙに類似するが、取引作成は、取引ドキュメントを取引タイプフォームの受取人に送信する。取引データフィールドは、値１をフィールド１に配置する。
【００４１】
当業者には本明細書の開示に照らして理解できるであろうが、特別なスクリプト及び他のプログラミング言語の形式は、より高機能及び複雑な基準及びルールのコーディングを許容するために、本発明で同様に使用できる。この種の追加的な複雑性としては、外部から内部へ及び内部から外部へのループを含むループ構造、外部の特別なスクリプト、初期値、及び他の複雑な条件文を含む外部データへのアクセス等を挙げることができる。
【００４２】
ポリシーテンプレートは、リスクポリシー生成を可能するための、又はリスクポリシーの入力として利用するためのデータ移転を可能にするため、提案、変更、修正、又は一般的に受諾された業務を提供することができる。例えば、ポリシーデータは、当業者には明らかなように多数の形式を取ることができ、ポリシーテンプレートは一方の形式から別の形式への移転を実現できる。以下に、ＸＭＬを用いて示した「トリガポリシー」ポリシーテンプレートを例示的に説明する。
【００４３】
（トリガポリシー）
＜ＴｒｉｇｇｅｒＰｏｌｉｃｙ＞
＜Ｅｖｅｎｔ ＩＤ＝”１” Ｄｏｃｕｍｅｎｔ＝”ＢｕｉｌｄｉｎｇＳｅｃｕｒｉｔｙ” Ｃｒｉｔｅｒｉａ＝” ＣｏｕｎｔｒｙＶａｌｕｅ ＝ ”Ｋｏｒｅａ”＞
＜Ｐｏｌｉｃｙ Ｎａｍｅ＝”ＧｏｌｄＢｕｉｄｉｎｇＡｓｉａ”＞
＜Ｐｏｌｉｃｙ Ｎａｍｅ＝”ＳｉｌｖｅｒＢｕｉｌｄｉｎｇ”＞
＜／Ｅｖｅｎｔ＞
＜Ｅｖｅｎｔ ＩＤ＝”２” Ｄｏｃｕｍｅｎｔ＝”ＢｕｉｌｄｉｎｇＳｅｃｕｒｉｔｙ”＞
＜Ｐｏｌｉｃｙ Ｎａｍｅ＝”ＧｏｌｄＢｕｉｄｉｎｇ”＞
＜Ｐｏｌｉｃｙ Ｎａｍｅ＝”ＳｉｌｖｅｒＢｕｉｌｄｉｎｇＡｓｉａ”＞
＜／Ｅｖｅｎｔ＞
＜Ｅｖｅｎｔ ＩＤ＝”３” Ｄｏｃｕｍｅｎｔ＝”ＦａｃｉｌｉｔｙＳｕｒｖｅｙ”＞
＜Ｐｏｌｉｃｙ Ｎａｍｅ＝”ＳｕｒｖｅｙＰｏｌｉｃｙ”＞
＜／Ｅｖｅｎｔ＞
＜／ＴｒｉｇｇｅｒＰｏｌｉｃｙ＞
【００４４】
例えば、例示的な「ＢｕｉｌｄｉｎｇＳｅｃｕｒｉｔｙ」ドキュメントでは（前述の例のＸＭＬ−Ａ及びＸＭＬ−Ｂを参照）、トリガポリシーテンプレートは最初にＣｏｕｎｔｒｙ（カントリー）の値が「Ｋｏｒｅａ」に一致するかどうかを調べる。一致すれば、ポリシーＧｏｌｄＢｕｉｌｄｉｎｇＡｓｉａ及びＳｉｌｖｅｒＢｕｉｌｄｉｎｇがドキュメントに対してテストされる。一致しなければ、ポリシーＧｏｌｄＢｕｉｌｄｉｎｇ及びＳｉｌｖｅｒＢｕｉｌｄｉｎｇＡｓｉａがドキュメントに対してテストされる。
【００４５】
また、トリガポリシー等のポリシーテンプレートは、他のインスタンスを作成又は組み込むことができる。以下に例を示す。
【００４６】
＜Ｅｖｅｎｔ ＩＤ＝”１” Ｄｏｃｕｍｅｎｔ＝”ＢｕｉｌｄｉｎｇＳｅｃｕｒｉｔｙ” Ｃｒｉｔｅｒｉａ＝”ＣｏｕｎｔｒｙＶａｌｕｅ ＝ Ｋｏｒｅａ”＞
＜Ｒｅｐｌａｃｅ Ｄｏｃｕｍｅｎｔ＝”ＫｏｒｅａＢｕｉｌｄｉｎｇＦｏｒｍ”＞
＜／Ｅｖｅｎｔ＞
＜Ｅｖｅｎｔ ＩＤ＝”２” Ｄｏｃｕｍｅｎｔ＝”ＫｏｒｅａＢｕｉｌｄｉｎｇＦｏｒｍ” Ｃｒｉｔｅｒｉａ＝” ＣｏｕｎｔｒｙＶａｌｕｅ ＝ ”Ｋｏｒｅａ”＞
＜Ｐｏｌｉｃｙ Ｎａｍｅ＝”ＧｏｌｄＢｕｉｄｉｎｇＡｓｉａ”＞
＜Ｐｏｌｉｃｙ Ｎａｍｅ＝”ＳｉｌｖｅｒＢｕｉｌｄｉｎｇ”＞
【００４７】
本例では、ＢｕｉｌｄｉｎｇＳｅｃｕｒｉｔｙドキュメントは新規ドキュメントＫｏｒｅａＢｕｉｌｄｉｎｇＦｏｒｍに変換される。フォームＫｏｒｅａＢｕｉｌｄｉｎｇＦｏｒｍの新規インスタンスはトリガポリシーを通過する。ＢｕｉｌｄｉｎｇＳｅｃｕｒｉｔｙからＫｏｒｅａＢｕｉｌｄｉｎｇＦｏｒｍへのマッピングは、当業者には明らかなように様々な方法で実現できる。タグ値からタグ値へのマッピングは、ポリシーテンプレートを用いる情報移転についての例示的なアプローチである。例えば、カントリー値は２つのフォームで存在することができ、ポリシーテンプレートマッピングは１対１で行われる。
【００４８】
本明細書で用いる場合、ドキュメント１０１のインスタンスは、承認されたインスタンス又は否認されたインスタンスのいずれかである。ドキュメントインスタンスは、次の２つの条件の内の１つが真ならば承認されたドキュメントである。
【００４９】
（１）Ａｃｃｅｐｔ（）が実行された。
（２）Ｒｅｑｕｉｒｅ（）が実行され、その中でＲｅｑｕｉｒｅ（）で指定されたグループの１メンバがドキュメントを承認した。
【００５０】
計算１０８は、リスクカテゴリの計算例を示す。計算方法は、例えば、複雑でエンティティに固有であるか又は汎用的でエンティティに固有でない。簡単にするため、本例では例示的な操作は次の形式になる。Ｆ（ｇ（Ｖａｌｕｅ），ｈ（Ｖａｌｕｅ，Ｖａｌｕｅ‘））＝Ｒｉｓｋ Ｃａｔ Ｖａｌｕｅ。ここで、Ｆは入力値の数学的合計である。本例でｇ及びｈは、（値＝真）ならば５０を返し、それ以外では１００を返すといった様々な代数関数とすることができる。同様に、複数の選択肢を一般化できる。例えば、ある計算は（値×定数）を返す。ここで定数は定義済みの整数である。つまり、値ｇ及びｈは１つ又は複数の入力であるか又は１つ又は複数の入力を必要とし、その入力は、質問に応答するデータ入力などの外部入力であるか、又はｈの計算１０８のように取得データへの定数の適用などの内部入力である。
【００５１】
図２は複数のリスクポリシーの適用を示すフローダイアグラムである。ドキュメント１０１のドキュメントインスタンス２０２は、本例では特定の入力インスタンス用の「記入フォーム」を表す。例示的なドキュメントインスタンス２０２は、１つ又はそれ以上のリスクカテゴリに照らして重み付けされ２０５、ここでリスクカテゴリ値ｘ、ｙは、リスクカテゴリｙのドキュメントｙの値を表す。結果的に、ドキュメントインスタンス２０２は、特定の例示的なリスクポリシー２０１に関して、グループのユーザがドキュメントインスタンスを受諾又は否認した後に、Ａｃｃｅｐｔ（）関数を介して又はＲｅｑｕｉｒｅ（）関数を介して承認されるというようにして承認される。ドキュメントインスタンス２０２は、例えば所定のドキュメント１０１に対するリスクポリシーアプリケーションの階層において最終的な承認の前に、複数のポリシー２０３、２０４により承認され得る。
【００５２】
図２の例示的な実施形態において、リスクポリシー２０３は１つのポリシーでのみ受諾されたドキュメントインスタンスを明示し、リスクポリシー２０４は複数のポリシーにより承認されたドキュメントインスタンスを明示する。
【００５３】
ＸＭＬ−Ｂの例において、リスクカテゴリ（ＲｉｓｋＣａｔ）値はドキュメントに依存し、同じドキュメントインスタンスは別のポリシーに関連する値などの複数のＲｉｓｋＣａｔ値を生成しないことに留意されたい。しかしながら、同じドキュメントインスタンスは、リスクカテゴリが各々のポリシーで異なる値を持つとみなすことで、２つの異なるポリシーで評価できる。例えば、ある会社が内部機密ポリシー及び外部機密ポリシーをもつことができる。このようなポリシーは、組織から発せられる任意の機密デジタルデータが送信中に暗号化される必要があるのに対して、内部で送信されるデータは暗号化される必要がない可能性がある。つまり、ドキュメントは、内部サーバから発せられるデータが暗号化されるか否かを指定する。結果的に、内部ポリシーについて、「機密」リスクカテゴリは一般に、内部サーバから同じ又は別の内部サーバへの送信には影響を及ぼさないであろう。しかしながら、そのドキュメントの暗号化に関する「ＮＯ」の回答は、送信が外部向けであれば「機密」リスクカテゴリのリスクに影響を及ぼす。従って、本例では、機密リスクカテゴリのスコアは、ポリシーが異なると異なる結果になる。
【００５４】
例示的なＸＭＬ−Ｂにおけるこの制約は、リスクカテゴリが１つだけの意味をもつと理解する検閲者による評価を単純化することができる。リスクカテゴリに関するこの種の制約は単に例示的なものであり、本発明で使用される必要はない。リスク値の評価は、この種の例示的なアプローチにおいて、指定されたポリシールールに制約される。リスクポリシーの参照は、以下のようにＸＭＬ−Ｂに組み込むことができる。
【００５５】
＜Ｒｉｓｋ Ｎａｍｅ＝”ｃｏｎｆｉｄｅｎｔｉａｌｉｔｙ” ｐｏｌｉｃｙ＝”ｃｏｎｆｉｄｅｎｔｉａｌｉｔｙ− −ｅｘｔｅｒｎａｌ” Ｓｃｒｉｐｔ＝”Ａｄｄ（５）”＞
＜Ｒｉｓｋ Ｎａｍｅ＝”ｃｏｎｆｉｄｅｎｔｉａｌｉｔｙ” ｐｏｌｉｃｙ＝”ｃｏｎｆｉｄｅｎｔｉａｌｉｔｙ−ｉｎｔｅｒｎａｌ” Ｓｃｒｉｐｔ＝”Ａｄｄ（０）”＞
【００５６】
ドキュメントインスタンスは、ポリシーに関して承認を受けることができる。同様に、ポリシー及び適格性はリンクすることができる。図３は、ポリシーと適格性との間の関係を示すフローダイアグラムである。ドキュメントの組３０５は、関係３０６を介してポリシー又はポリシーの組３０１に関連する。適格性３０２は、１つ又はそれ以上のポリシーインスタンス３０１に関連する。例えば、ドキュメントインスタンス１０１又はドキュメントインスタンスの組３０５がポリシー１に照らして承認されると、適格性１ ３０２及び適格性２が得られる。適格性は複数のポリシー承認３０４を必要する場合がある。本例ではドキュメントインスタンスは、適格性３を得るためにポリシー２及びポリシーｍの承認を得る必要がある。従って、ポリシーと適格性との間に階層化が存在する場合がある。ポリシーの階層性に関して前述したように、適格性も同様に他の適格性及びポリシーの両方に関して階層性がある。適格性は、ＸＭＬなどでは以下の示すようにコード化することができる。
【００５７】
（ＱＵＡＬテンプレート）
＜Ｑｕａｌｉｆｉｃａｔｉｏｎｓ＞
＜ＱＵＡＬ Ｎａｍｅ＝”ＧｏｌｄＳｅａｌ” Ｄｅｓｃｒｉｐｔｉｏｎ＝”Ｃｏｒｐｏｒａｔｅ Ｇｏｌｄ Ｓｅａｌ ｆｏｒ Ｖｅｎｄｏｒ”＞
＜／Ｒｕｌｅｓ ＩＤ＝”１”＞
＜Ｃａｔ ＩＤ＝”１” Ｎａｍｅ＝”ＧｏｌｄＰｏｌｉｃｙＰｈｙｓｉｃａｌ”＞
＜Ｃａｔ ＩＤ＝”２” Ｎａｍｅ＝”ＧｏｌｄＰｏｌｉｃｙＰｒｏｃｅｓｓｅｓ”＞
＜／Ｒｕｌｅｓ＞＜／ＱＵＡＬ＞
＜ＱＵＡＬ Ｎａｍｅ＝”ＳｉｌｖｅｒＳｅａｌ” Ｄｅｓｃｒｉｐｔｉｏｎ＝”Ｃｏｒｐｏｒａｔｅ Ｓｉｌｖｅｒ Ｓｅａｌ ｆｏｒ Ｖｅｎｄｏｒ”＞
＜Ｒｕｌｅｓ ＩＤ＝”１”＞
＜Ｃａｔ ＩＤ＝”１” Ｎａｍｅ＝”ＧｏｌｄＰｏｌｉｃｙＰｈｙｓｉｃａｌ”＞
＜Ｃａｔ ＩＤ＝”２” Ｎａｍｅ＝”ＳｉｌｖｅｒＰｏｌｉｃｙＰｒｏｃｅｓｓｅｓ”＞
＜／Ｒｕｌｅｓ＞
＜Ｒｕｌｅｓ ＩＤ＝”２”＞
＜Ｃａｔ ＩＤ＝”１” Ｎａｍｅ＝”ＳｉｌｖｅｒＰｏｌｉｃｙＰｈｙｓｉｃａｌ”＞
＜Ｃａｔ ＩＤ＝”２” Ｎａｍｅ＝”ＧｏｌｄＰｏｌｉｃｙＰｒｏｃｅｓｓｅｓ”＞
＜／Ｒｕｌｅｓ＞
＜Ｒｕｌｅｓ ＩＤ＝”３”＞
＜Ｃａｔ ＩＤ＝”１” Ｎａｍｅ＝”ＳｉｌｖｅｒＰｏｌｉｃｙＰｈｙｓｉｃａｌ”＞
＜Ｃａｔ ＩＤ＝”２” Ｎａｍｅ＝”ＳｉｌｖｅｒＰｏｌｉｃｙＰｒｏｃｅｓｓｅｓ”＞
＜／Ｒｕｌｅｓ＞
＜／ＱＵＡＬ＞
＜／ＲｉｓｋＣａｔｅｇｏｒｉｅｓ＞
【００５８】
前述の例では、適格性「ＧｏｌｄＳｅａｌ」は、ＧｏｌｄＰｏｌｉｃｙＰｈｙｓｉｃａｌ及びＧｏｌｄＰｏｌｉｃｙＰｒｏｃｅｓｓｅｓが達成できた場合にのみ得ることができる。しかしながら、ＧｏｌｄＰｏｌｉｃｙＰｈｙｓｉｃａｌ又はＧｏｌｄＰｏｌｉｃｙＰｈｙｓｉｃａｌが達成され、更に同様にＳｉｌｖｅｒＰｏｌｉｃｙＰｒｏｃｅｓｓｅｓ又はＳｉｌｖｅｒＰｏｌｉｃｙＰｈｙｓｉｃａｌが達成されると「ＳｉｌｖｅｒＳｅａｌ」を得ることができるが、ＧｏｌｄＰｏｌｉｃｙＰｒｏｃｅｓｓｅｓ及びＧｏｌｄＰｏｌｉｃｙＰｈｙｓｉｃａｌの両方が達成されれば「ＳｉｌｖｅｒＳｅａｌ」を得ることができない。
【００５９】
図１０は、図４の例示的な説明を簡略化したものである。図示したように、ドキュメントインスタンスは異なる時期に入力された複数の入力「ドキュメント」に関連することができる。例えば、ドキュメントＡ（線１００２より下の値）は、時刻＝０に受信してデータベース１００４に保存することができる。ドキュメントＢ（線１００２より上の値）は、時刻＝１に受信することができる。ドキュメントＡは、ドキュメントインスタンス１００３に配置することができる。
【００６０】
前述のポリシー評価は、リスク検知システム（ＲＤＳ）の一部とすることができる。ＲＤＳは、図５で示したように大規模インフラストラクチャ内で存在できる。ＲＤＳは、ドキュメントに照らしてポリシーを評価すること、ポリシー５０７を評価するためにストレージを管理すること、及び適格性を決定することができる。ＲＤＳは、１つ又はそれ以上のアグリゲータ５０６にリンクすることができる。アグリゲータは、複数のＲＤＳから情報を取得してポリシー及びドキュメントを他のＲＤＳに供給するＲＤＳを備えることができる。２つのドキュメントが２つのＲＤＳで現れる場合、アグリゲータはイントラ・グローバルデータベース５０２のような調停者を備えることができる。アグリゲータは、部分的に履歴に基づいてポリシーを動的に生成又は適用することができる。例えば、別々のＲＤＳインスタンスからアグリゲータへの複数の入力が過度にカントリリスクにさらされることを示す場合、アグリゲータは様々なＲＤＳでポリシーを修正してリスクを制御することができる。例えば、カントリリスクの受諾可能なしきい値が高くリセットされているために、取引を表す修正後のドキュメントが修正後のポリシーによって受諾されなくなり、結果的に以前は受諾可能だったドキュメントのスコアが受諾できなくなる場合がある。
【００６１】
ＲＤＳ及びアグリゲータは、イントラ・グローバルデータベースから情報を受信すること、及びインターグローバルデータベース５０２から情報を取得することができる。インターグローバルデータベースは組織の外側にある。例えば、外部組織である税関国境保護局は、ビジネス相手として推奨できない人物又は法人の「監視リスト」、並びに特定のクラスの貨物向けの取扱要件等を制御する「監視リスト」を有する。米国務省は公知のテロリストリストを保持しており、他の官庁及び政府機関、規制機関、標準機構、パートナ、及び他の様々なプロバイダもＲＤＳにとって有益なデータを保持している。また、一部の会社は、動的及び予防的にポリシーを生成するために有益な統計的データ及び他のデータを提供することができる。この種の情報は、システムに配布して信頼レベルを確立することができる。
【００６２】
信頼マネージャ５０３は、公開鍵インフラストラクチャ（ＰＫＩ）［Ｘ５００、Ｘ５０９、ＲＦＣ３２８０］又はＫｅｒｂｅｒｏｓ［Ｎｅｕｍａｎ］又は本技術分野で公知の他の手段［Ｍｅｎｅｚｅｓ］といったセキュリティ信頼システムを表す。信頼マネージャは、内部規制組織又は外部規制組織によって管理される。規制組織は、インフラストラクチャ内で通信することが承認されたものを規制する任意の人物又はグループであり、これらの承認された通信者が有する権限を規制することができる。信頼マネージャは、セキュリティを拡張可能にすることができる。しかしながら、図５のインフラストラクチャは、暗号化鍵の物理的交換又は本技術分野で公知の他の方法等によってセキュリティを直接確立できるので、信頼マネージャの利用を必要としない。
【００６３】
入口５０１はデータを受け取るソースとすることができる。ＲＤＳは、入口から直接的に又は入口と共同してデータを受け取ることができる。入口は、侵入検知システムのプローブとすることができる。入口は、データだけを受け取ること、及びＲＤＳ又はインター又はイントラ・グローバルデータベースに、ＲＤＳ又はアグリゲータが使用するためのデータを配置することによって費用を低減できる。入口は特殊化すること及びＲＤＳの仕事負荷を軽減するために使用できる。
【００６４】
例えば、前述のＸＭＬ−Ｂはポリシーの執行を含むが、入口は一定レベルのドキュメントのポリシーレビューを行うことができる。これは、部外者がＲＤＳのポリシーを識別するリスクを低減する。また、入口は、直接的に又は信頼マネージャ５０３を介して信頼を確立できる。
【００６５】
図６は、ポリシーテンプレート、ポリシールール、又はＸＭＬ−Ａ又はＸＭＬ−Ｂ等の適格性又はドキュメントのポリシーテンプレートの安全な送信を示すフローダイアグラムである。例えば、テンプレート６０５を送信することができる６０２。送信者は、例えば、アグリゲータ、ＲＤＳ、又は規制組織とすることができる。信頼マネージャ６０４は、ＲＤＳ及び送信者６０３の間に信頼を確立できる。例として、信頼マネージャがＰＫＩであり、送信者によって送信されたメッセージが署名されている場合、ＲＤＳは証明書に基づいて署名を検証できる。アグリゲータとすることもできるＲＤＳは、認証されることができるテンプレートを受け取り、ポリシーテンプレートを以下の評価に組み込むことができる。
【００６６】
ポリシーテンプレートは、インフラストラクチャ内の様々な組織及び構成要素によって生成することができる。優先順位つまり評価順序は、図７で示すように指定される。前述のポリシールールアプリケーションの例では、ポリシーは「上から下に」評価される。ポリシー７０２はサブポリシーから構成することができる。例えば、ポリシー７０２はポリシー７０３の前に実行できる。政府機関が法人７０３又はローカルに設定された法人又は人物７０４に優先するように、一部の組織は高位に置くことができる。また、組織は、ポリシーテンプレートの中で優先順位を指定することができる。例を示す。
【００６７】
Ｒｕｌｅ：＜ｌａｂｅｌ＞
Ｐｒｉｏｒｉｔｙ：＜Ｈｉｇｈ＝１ ｔｏ Ｌｏｗ＝１０＞
Ｃｒｉｔｅｒｉａ：＜ｃｏｎｄｉｔｉｏｎａｌ ｓｃｒｉｐｔ＞
Ａｃｔｉｏｎ：＜ｓｃｒｉｐｔ＞
【００６８】
本例では、政府機関は複数のテンプレートをＲＤＳに配置して、これらに他のソース７０２にまさる優先順位を与えることができる。
【００６９】
ＲＤＳへのアクセスは様々な組織に許可される。アクセス制御は、ユーザが誰か及びユーザが識別される方法に基づいて、情報へのアクセスを制限すること及び情報の修正を制限することができる。図９はアクセス９０６を有するユーザ９０５を示す。ユーザ９０５は、規制間組織又は規制内組織９０２に所属することができる。信頼関係９０３は、信頼マネージャ９０４と規制組織９０２との間の信頼を示すこと、及び信頼関係９０７は信頼マネージャ９０４とＲＤＳ９０１との間の信頼を示すことができる。信頼は、コンピュータセキュリティ向けに開発されたメカニズムを通じて、信頼マネージャとユーザとの間に設定することができる。この種の例として、ユーザを検証するために規制機関を代理して行動するＰＫＩ内の登録代理人、及びユーザの公開鍵の証明プロセスを挙げることができる。信頼マネージャ９０４を介して確立された信頼関係に基づいて、ユーザは、ＲＤＳへの独自のアクセス権限を有し、一定のアクセス制御メカニズムを介してそのユーザに提供された権限に基づいてアグリゲータつまりグローバルデータベースへのアクセス権限を有することができる。政府の代理人又はパートナは制限又は拡張されたアクセスを有することができるが、内部のユーザは異なるアクセス権限を有することができる。例えば、政府の代理人は、定義されたイベントの発生、及びオンラインのＩＤ又はロールの証明の提供を含む適切な信用証明の提示を条件に、他の方法では制限されるデータ及びデータストアへの一定のアクセス権限が自動的に付与され得る。
【００７０】
ＲＤＳは、別のＲＤＳと通信して、ポリシー、ドキュメント、及び／又は適格性インスタンス又はテンプレートを提供することができる。ＲＤＳ１ ８０１は、ＲＤＳ２ ８０２又はグローバルデータベース８０６、８０３、８０４にオブジェクトを送信することができる。送信８０３又は８０４は、デジタル署名、又はＳＳＬ、ＶＰＮ、ＩＰＳＥＣ等による安全なトンネルを介して送信すること、又は当業者に公知の他の安全な手段によって、認証することができる。セキュリティは、送信８０３及び８０４への信頼関係８０５を介して信頼マネージャを通じて使用すること又は確立することができる。関係８０５は、公開鍵インフラストラクチャ（ＰＫＩ）における証明機関（ＣＡ）を代理する信頼マネージャ等による証明関係を表すことができる。
【００７１】
図８は、ＣＡを代理する信頼マネージャにより認定された公開鍵で署名されたインスタンスなどの安全な方法で、ＲＤＳが様々なインスタンス及びレポートを送り出すプッシュアプローチを示す。実際には、ＲＤＳはプッシュアプローチを必要とせず、引き出された情報に応じてローカルに情報を提供できる。つまり、ＲＤＳはプッシュの代わりにプルを提供する。したがって、ＲＤＳアプリケーション８０２、８０６はローカルにデータを要求して受信することができる８０１。
【００７２】
ＲＤＳ、又は同様にグローバルデータベース、又はファイル、ディレクトリ等の他のデータストアデータである外部に提供するデータは、ユーザに有用である。図８では、数種類の情報を提供することができる。レポートとして、監査ログ、発覚リスク集計、発見された異常、及び監査状態を示すイベントを挙げることができる。レポートにより外部の当事者は使用手順をレビューすることができるが、特定の監査レベルのアクセス権限も同様に必要であろう。適格性テンプレート、ポリシーテンプレート、又はドキュメントテンプレートにより、ＲＤＳが外部レビューのためにテンプレートを送信すること、又はＲＤＳが別のＲＤＳに組み込まれることが可能になる。
【００７３】
ＲＤＳは様々なロール（Ｒｏｌｅ）をサポートすることができる。これらのロールを以下に示す。ＲＤＳ管理者：限定されるものではないが、ユーザへのアクセス提供つまりＩＤ管理、グループ、及び外部構成要素へのアクセス提供、システム性能の監視、バックアップ実施の確認、及び他一般的にシステムが監視するリスクと関連のない基本タスク等のシステムの基本管理を行う。テンプレート作成者：ポリシー、ドキュメント、及び適格性テンプレートを含むアプリケーションで使用される各種テンプレートを作成する。
【００７４】
データ入力者：データをシステムに提供する。例えば、いくつかのフォームへの記入を許可されている他のフォームへの記入を許可されていない者や、特定のグループのフォームのみ記入することを許可された者など、異なる権限をもつデータ入力者の様々なカテゴリが存在する。
【００７５】
リスクマネージャ：リスクカテゴリ及び適格性についてポリシーの許容範囲、リスクカテゴリが決定される方法、及びポリシーが様々なカテゴリに対して行うアクションを指定する。
【００７６】
ドキュメント承認者：各々のインスタンス又は一部の定義済みグループ又はインスタンスのグループについて、ドキュメントの受諾を必要とするＲｅｑｕｉｒｅ（）アクションが設定されたときに、ポリシーに照らしてドキュメントインスタンスを承認する。
【００７７】
監督承認者：承認者の特別なグループ。一部の組織は、承認者並びにドキュメント承認の監督者を必要とする場合がある。
監査員：他者のアクションをレビューする読み取り専用のアクセスを有する。
【００７８】
ロールは、少なくとも部分的にコンピュータシステムによって実行できる。例えば、テンプレートはＲＤＳ及びアグリゲータによっても作成することができ、データ入力者がその入口になることができる。リスクマネージャは、例えばＲＤＳ又はアグリゲーとすることができる特別な種類のテンプレート作成者である。これらは過去のアクションをレビューして、将来のアクションに対するポリシーを決定する。
【００７９】
本発明の複合一貫コンテナ出荷の例では、定義済みカテゴリとしては、インフラストラクチャ資産、輸送資産、及び出荷品を挙げることができる。インフラストラクチャ資産は、積込み地点から積降し地点への移動を含む複合一貫コンテナの次の場所への移動に使用されるインフラストラクチャに関する。インフラストラクチャ資産の例としては、コンピュータシステム、情報処理システム、倉庫、及び港内のターミナルを挙げることができる。インフラストラクチャ資産は、物理的エンティティ又は物品に限定されず、法律的エンティティとすることができる。例えば、倉庫を所有及び／又は管理する会社はインフラストラクチャ資産として分類できる。輸送資産は出荷品の物理的な移動に直接的に使用される資産であり、出荷の一部でない資産とすることができる。例えば、出荷品を移動する具体的目的に使用される鉄道機関、コンテナ、又は他の船舶又は航空機は、輸送資産とすることができる。ある資産がインフラストラクチャ資産又は輸送資産か否かを決定することが困難であれば、その両者として取り扱うことができる。出荷品は、実際に出荷される商品、及びこれら商品の移動に使用される又は関連する特定の資産又は資料である。このカテゴリとしては、限定されるものではないが、物理的な出荷品を収容するコンテナ、防壁とすることができる又は手書き又は電子的の出荷修正を示すことができる封印、及び出荷命令や積載手形等の具体的な出荷に関する資料を挙げることができる。
【００８０】
調査、調査票、及び／又は他のメカニズムは、インフラストラクチャ資産、及びインフラストラクチャ資産に関して何らかの責任のある担当者等のインフラストラクチャ資産の他の特徴を識別するために使用できる。インフラストラクチャ資産は、下位区分、システム、又は構成要素を備えることができる。例えば、建物はインフラストラクチャ資産とすることができる。しかしながら、建物内に位置する格納施設ではあるが異なる物理的、論理的、又は法律的支配を受ける格納施設は、建物の下位構成要素として取り扱うことができるが、依然としてインフラストラクチャ資産として分類される。インフラストラクチャ資産は、以下の様々な基準に照らして施設の種類に基づいて評価されるが、これらの基準に限定されるものではない。
物理的セキュリティの制御（例えば、鍵の種類、フェンスの高さ、警備員の数など）。
人的セキュリティの制御（例えば、素性調査、雇用契約等）。
データシステムの制御（例えば、機密性、整合性、及び利用可能性など）。
履歴制御（例えば、固定資産が適切に執行されているか否かを判断する前歴）。
保険（例えば、保険の種類及び限度）。
資産に対する事前の法律的及び／又は規制的アクション（例えば、資産、判決、差止命令、評決、和解命令などに照らして開始された既存の法律的又は規制的アクション）。
契約による制御（例えば、インフラストラクチャ資産、その作業者又はプラントに関する契約条項など）。
製造元制御（例えば、その素性、評価方法など）
記録の維持及び監査の制御（例えば、記録の維持方法、制御を監査する種類など）。
手順及び慣行（例えば、タスクの達成方法）。
【００８１】
これらの基準又は構成要素又はこれらの分解要素は、リスクカテゴリとして取り扱うことができる。必要に応じて追加的なリスクカテゴリを含むことができる。評価された資産の性質は、それを評価するために使用されるリスクカテゴリ、並びにリスクカテゴリ値を計算するために使用されたデータ値の選択又は重みを決定することができる。つまり、値の小さな倉庫の物理的セキュリティのリスクカテゴリを構成する質問は、例えば値の大きなデータセンターの同じリスクカテゴリを構成する質問とは異なる場合がある。
【００８２】
資産は、ＲＤＳが使用するために複数の方法で入力することができる。これはＷｅｂシステムを用いて入力すること、又は別のアプリケーションがＲＤＳに例えば新規資産を報告することができる。１つ又はそれ以上の種類の資産を入力するために、専用ＲＤＳが存在する。次に、これらは、資産に関するデータを他のＲＤＳシステムに提供することができる。新規資産は、別のデータベースに影響する場合がある（例えば、製造元データベース）。固定資産情報は、アグリゲータ、別のＲＤＳ、インターデータストア又はイントラデータストア、又は他のソースから得ることができる。また、情報は、現地作業、調査、政府フォーム、又は他の内部又は外部のデータから取得できる。
【００８３】
資産が定義されると、適切なポリシーに基づいて評価が行われる。新規資産の導入は、新規製造元との取引やＷｅｂベースの入力等のトリガイベントであり、トリガイベントは、トリガポリシーに照らした評価を引き起こすことができる。この評価は、ポリシーの一部として複数のアクションを作成することができる。例えば、ａ）特定の調査（例えば、物理的建物の調査）が実行され、結果的に通知が適切な人々に送られて新規製造元が加入したので調査を完了する必要があることを通知する。ｂ）外部関係者の評価（例えば、サイト調査又は他の解析を行うための第３者の獲得の開始）などの内部及び外部のデータ検査が開始される（例えば、禁止された関係者リストの照合、任意の法律／規制アクションの照合、保険証券、財務状態の検証など）。詳細な情報を受け取ると、これはトリガポリシーによってポリシーに照らしてテストされる。詳細な情報を受け取ると、ポリシーは一部のケースに関して条件を満たし、資産の適格性は条件を満たしたケースで達成される。更に、資産適格性（輸送、インフラストラクチャ、又は出荷品、並びに出荷そのものの適格性）は、出荷が予約されるサプライチェーン等の他の事象の前提条件、船主からの直接的な予約ベース又は例えば船舶以外の運送の一般運送業者からの受入れベースで運送業者による出荷品の運搬、運搬の価格設定、配送時刻の約束、商品運搬又は商品の運送、処理、梱包、又は保管に使用される他の資産の保険金とすることができる。
【００８４】
ポリシーに基づく承認は、適格性と同様に短期間とすることができる。例えば、予期される制御に対して重要な障害ではない、又は予期される制御を欠くマテリアルが存在する場合、短期間の承認が提供される。例えば、建物の物理的セキュリティポリシーは変化することがある。特定の機密基準を満たす建物は、最大１か月前の物理的セキュリティポリシーに基づいて承認された鍵のみを受領することできる。１か月後には、短期間の承認は無効になるであろう。
【００８５】
ポリシーは、前述のように階層性の中で指定することができる。例えば、「Ｇｏｌｄ Ｓｅａｌ」（階層内の高レベル）は、他の方法では階層内の低レベルに対して必要な所定の出荷時調査を必要としないであろう。同様に、これは適格性についても成り立つ。理解できるように、同じアプローチは、評価時に「Ｇｏｌｄ Ｓｅａｌ」として所定の基準を満たすものを用いて資産を分類するために採用できる。船舶−輸送は、それ自体が「インフラストラクチャ資産」である会社によって所有されることができる。当然ながら、多数の例示的な資産に関して、一方向の「所有者」の関係が存在し、他方向の「所有される」関係が存在する。資産は、任意の特定の取引リスクの評価に関連のある関係をもつことができる。これらの関係は、１対１、１対多、及び／又は多対多でありリスクを評価するために使用できる。実例として、ポートは、例えば物理的セキュリティに照らして評価することができる。関係は、ポートの一部の物理的セキュリティが別のエンティティによって「管理されている」ことを示すことができる。また、「管理された」エンティティを評価して、そのリスクをポートのリスクに適切に計算することができる。
【００８６】
リスクに影響することになる関係に利用可能な関連付けを次に示す。Ｏｗｎｅｄ ｂｙ（被所有者）、Ｌｅｓｓｏｒ ｏｆ（賃貸人）、Ｌｅｓｓｅｅ ｏｆ（賃借人）、Ｃｕｓｔｏｍｅｒ ｏｆ（顧客）、Ｖｅｎｄｏｒ ｏｆ（製造元）、Ｓｕｐｐｌｉｅｒ ｏｆ（供給元）、Ｍａｎａｇｅｄ ｂｙ（被管理者）、Ｒｅｇｕｌａｔｅｄ ｂｙ（被規制者）、Ｉｎｓｕｒｅｄ ｂｙ（被保険者）、Ａｕｄｉｔｅｄ ｂｙ（被監査者）、Ｅｖａｌｕａｔｅｄ ｂｙ（被評価者）、Ｉｎｓｐｅｃｔｅｄ ｂｙ（被点検者）、Ａｕｄｉｔｅｄ ｂｙ（被監査者）、Ｏｐｅｒａｔｅｄ ｂｙ（被操作者）、Ｐｒｏｃｅｓｓｅｓ ｆｏｒ（プロセス）、Ｆｉｎａｎｃｉａｌ ｉｎｓｔｉｔｕｔｉｏｎ ｆｏｒ（金融機関）、Ｉｎｓｕｒｅｒ ｏｆ（保険者）、Ｇｕａｒａｎｔｏｒ ｏｆ（保証人）、Ｓｅｃｕｒｉｔｙ ｆｏｒ（担保）、Ｒｅｌａｔｅｄ ｔｏ（関連、関連付けの種類がシステム内で指定されていない場合）、及び以上の逆（例えば、被所有者の逆は所有者）。
【００８７】
出荷品としては、輸送される商品、そのパッケージ、商品を中に収納して輸送する複合一貫コンテナ、及び商品のコンテナ用の様々なセキュリティ、可視性、又は状態装置、及び出荷に関連するドキュメント又はメッセージを挙げることができる。出荷品は、特定の出荷、特にその中のコンテナのリスク管理の評価において評価されるものの一部である。リスク及びリスク情報リポジトリ及びアプローチの領域としては以下のものを挙げることができる。
【００８８】
インフラストラクチャ資産又は輸送資産（全てのサプライチェーン段階、対処する作業者、及びビジネスプロパティ向けの責任プログラムを含む）の全て又は一部の様々な局面（例えば、物理的、論理的、財務的など）におけるリスク状況は、出荷品の収集、製造、梱包、積込み、封印、移動などに使用することができる。
インフラストラクチャ資産、その所有権、又はリスクに影響する他の重要な「関連する」関係についての関連情報のインター又はイントラデータストアのスクリーニング。
検査、積込み、及び記録の様々な種類の手順、独立した検査機関の利用、物理的アクセス制御、論理的保護などを含む、コンテナが積み込まれて封印される条件。
他の可能性のあるパラメータの中でも、例えば、輸送期間、重さ、時間、場所、状態等及び他の関連するリスク管理ルール及び例外手順に関する、以下のコンテナについての肯定及び否定ルールセット。
【００８９】
一定の期間にすぎない。
一定の期間より短くない。
特定の測定された距離以内である。
少なくとも特定の測定された距離の範囲。
陸路か海路かに拘わらず予想された経路からの変動。
ＧＰＳ追跡による決定を含む禁止場所。
ＧＰＳ追跡による決定を含む予想場所。
原産地又は季節に基づく不適切な起点又は目的地などの付属ドキュメントの異常。
センサー又は封印のための開封又は小容積ルール。
予期しない核物質、生体物質、化学物質。
予期しない温度変化。
ＣＯ２などの予期しない気体内容物。
サプライチェーンの関係者に提供済みの出荷又はコンテナに関連するステータスメッセージの異常の解析。
出荷に関連するドキュメント（ステータスメッセージ以外）の異常の解析。
【００９０】
様々な発生履歴及び署名テンプレート、並びにレポート機能は、本発明の中で独立したサービスであることに留意されたい。つまり、システムの一部の態様が一部の承認機関又は人物によって承認されたことを知ることは有用であろう。一例として、製造元はポリシーに照らして所定の機関によって承認される場合がある。この承認はＲＤＳの中に組み込むことができる。承認インシデンスは、署名されるか又はその中に配置された他のセキュリティ制御をもつことができる。会社は、規制機関が資金を供給する手段として販売する承認インシデンスを購入すること、又は承認インシデンス又はその一部を第三者に販売することができる。
【００９１】
図１１に示すように、本発明の特定の例示的な説明では、その中に値をもつドキュメントが提供される。その値は１つ又はそれ以上のリスクポリシーに基づいて得ることができ、そのポリシーは、１つ又はそれ以上のリスクポリシーテンプレートに存在できる。リスク解析は、複数の採点メカニズムに基づいて実行できる。例えば、金融機関は、ドキュメント及びその値を１つの方法で採点するが、保険制度は同じドキュメント及びその値を別の方法で採点する。
【００９２】
この種の例示的な実施形態では、グローバルサプライチェーンのリスクを評価できる。例えば、サプライチェーンの倉庫は、多数の値を有する多数のドキュメントを含むことができる。これらのドキュメントは、各々のカテゴリにおけるドキュメントのリスクに基づいて分類できる。例えば、倉庫セキュリティは１つのカテゴリ、電源装置は別のカテゴリとすることができる。リスクは、値に基づいたリスクポリシーに照らして解析できる。例えば、倉庫セキュリティのドキュメントは、値「カメラの存在：はい」を含むことができる。この種の値ファクタは、倉庫セキュリティに対するポリシーのアプリケーションに実質的に影響し、その値へのリスクポリシーのアプリケーションに基づいて、セキュリティが成功したか失敗したか、又は所定の適格性に達したかどうかに実質的に影響することは明らかである。
【００９３】
このため、サプライチェーン内のこの例示的リンクは、各々のカテゴリについて、及びカテゴリ全体について採点することができる。リスク解析及び全体のリスク解析は、１つ又はそれ以上のテンプレートに従うであろう。例えば、犯罪が多い第１の国に倉庫が存在する場合、総スコア８０又はセキュリティスコア８５は受諾できない。しかしながら、犯罪が少ない第２の国に倉庫が存在する場合、総スコア７０又はセキュリティスコア７５は受諾可能と思われる。
【００９４】
追加的に、又は別の方法として、他のフローは本発明の使用を通じて監視できる。例えば、取引フローは、独立した取引部分又は取引全体によって採点できる。採点としては、購入発注、請求、又はコンテナ格納などを挙げることができる。同様に、採点は、例えば、手動、電子的、又は両者を組み合わせた任意のビジネスプロセスに導くことができ、採点は、任意のドキュメント又はフローの全て又は選択された部分について行なうことができる。レポート機能は、本発明の適用の任意の部分又は全体で利用可能である。レポート機能は、例えば電子的又は書面とすることができる。
【００９５】
当業者であれば、本明細書に記載された教示内容及び本明細書で参照され本開示に組み込まれた参考資料に基づいて、簡単に利用可能なハードウェア及びソフトウェア技術を用いて本発明を実施することができる。更に、ＸＭＬを含む任意の多様な計算態様、言語、又はスクリプトは、本発明に組み込むことができる。
【００９６】
本当業者であれば、本発明の精神又は範囲を逸脱することなく本発明の多数の修正例及び変更例を実施できることを理解できるであろう。従って、本発明は、発明の修正例及び変更例を、特許請求の範囲及びその均等物の範囲にある限りカバーすることを意図している。
【図面の簡単な説明】
【００９７】
【図１】ドキュメント、リスクカテゴリ、及びポリシーの間のマッピングを示す図である。
【図２】複数のドキュメントインスタンスに対する複数のリスクポリシーを示す図である。
【図３】ドキュメント、ポリシー、及び適格性の関係を示す図である。
【図４】ドキュメントインスタンスによってデータベースから値を取得してフィールド（値）に組み込むことを示す図である。
【図５】ＲＤＳの構成要素を示す図である。
【図６】テンプレートの安全な送信を示す図である。
【図７】様々な組織からのポリシーの性能を示す図である。
【図８】インスタンス又はテンプレートのＲＤＳからの安全な送信を示す図である。
【図９】トラストマネージャに関するユーザアクセスを示す図である。
【図１０】図４の方法を用いて複数のドキュメントを１つのドキュメントに結合することを示す図である。
【発明の詳細な説明】
【０００１】
（関連出願への相互参照）
本出願は、２００３年６月９日に出願された米国仮出願番号６０／４７６，６２８の優先権を主張する。
【０００２】
（技術分野）
本発明は、リスク管理分野に関し、詳細には、レビュー、メッセージング、インフラストラクチャ、及びリスク状態に関するドキュメント及びメッセージの関連プロセスを含む、システム及びサブコンポーネントのリスク解析に関する。
【０００３】
（背景技術）
リスク評価及びリスクに基づく意志決定は一般的である。例えば、銀行及び投資機関は、リスクを評価して、これらのリスク評価に基づいて投資、融資、及び他の取引リスクを決定する。例えば、金融機関は、取引先企業と取引するために、特にタイプ、コスト、及びアプローチに関して決定を行うにあたって外国為替（ＦＸ）リスク、信用リスク、与信リスク、及び運用リスクなどのリスクを調査することがある。保険会社は、リスク対報酬を評価する同様の決定を行い、損害賠償請求及び見込み損害賠償請求の大きさの確率に基づいて保険証券を発行する。本例では、利用可能で適切な履歴データは、現在及び将来のアクションに関する意思決定をサポートするために使用される。
【０００４】
リスクを評価してリスク評価に基づいてアクションの決定をサポートする技術が開発されている。しかしながら、ビジネスプロセスにおけるリスク管理のプロセス及びアーキテクチャは、歴史的にいって１つ又は多数のローカル（内部）及び外部（相互）のビジネス及び技術領域にわたって展開することは困難である。更に、既存のシステムにおいて、リスクに基づく決定が行われると、実施予定の取引の拒絶、又は新規取引又は移行の開始（例えば、保険の再精算、保険の適格性を得る又は取得すために、自動的に行うため及び／又は販売するため）、及び／又は適切な担当者への警告通知を含む、様々なアクションを実施することが困難な場合がある。
【０００５】
データセキュリティ制御は、データシステム（例えば、ネットワーク及びコンピュータ）に関してリスク評価を利用する。受諾可能及び受諾不可なものを示し、「署名」への注意を含むことができる特定のポリシーに基づいて、適切なアクション又は不適切なアクション（ホスト／ネットワークシステム上のアクション）のパターンは、許可又は拒否される。履歴情報は、受諾可能なアクションを過去のアクションに基づいて部分的に決定するために保持できる。従って、現在及び／又は将来においてアクションは、過去に許可されたアクションに基づいて許可又は拒否される。このようなデータセキュリティ制御の１つの手段は、本技術分野においてファイアウォールとして公知である。
【０００６】
侵入検知システム（ＩＤＳ）は、コンピュータシステム及びネットワークで利用できる。ＩＤＳは、権限のないコンピュータの使用を検知及び識別するために利用できる。一般に、ＩＤＳは、ログ、ネットワークトラフィック、ファイル修正、及び他の利用可能なソースを介して、悪意ある行為を検知するために特定のパターン又は署名を探す。これらの署名は、有限状態マシン、簡単なパターンマッチング、又は特別なアルゴリズムを用いて識別される。多くのＩＤＳは、偽陽性及び偽陰性の警告を発する傾向がある。偽陽性は、ＩＤＳが問題（例えば、権限のない行為）を識別したがその問題が起きていない場合に発生する。偽陰性は、問題が起きたときにＩＤＳが問題を検知しなかった場合に発生する。
【０００７】
履歴データの信頼性及び偽陽性及び偽陰性の可能性を考慮すると、ネガティブパターンの単なる署名は、システムを完全に保護するために望ましいが十分ではない。ネガティブ署名アプローチは、許可されていないものの識別を解決する。補完的アプローチ、つまりポジティブ署名アプローチは、許可されるもの又は少なくとも許容偏差内で受諾可能なものを具体的に定義する。
【０００８】
本明細書ではポリシーとも呼ぶルールは、具体的に許可されるアクション及び／又は具体的に拒否されるアクションを表す。ルールは、取引が行われるパラメータを指定する。動的ルールは、応答が様々な検討に基づいて変化する等の、特定の入力等に応じて様々な応答が経時的に変化するようなルールである。
【０００９】
理想的には、ＩＤＳテストに使用されるルールは動的ルールであろう。しかしながら、ルールはセキュリティシステムのバイナリコードの一部として「ハードコード」される場合が多いので、ルールは一般に真に動的ではない。動的ルールの欠如は、例えば、セキュリティソフトウェアが更新された場合（例えば、実行可能コードが長くなって遅くなり、アップグレードするためにマシンを停止する必要がある場合）を含む、様々な状況で問題を起こす。
【００１０】
更に、ビジネスプロセスは、一般にこれらのビジネスプロセスを操作するコンピュータシステムへの侵入に関連するルールよりもはるかに複雑である。例えば、情報フローは複数の入口から到来するいが、中心点に届かない場合がある。動的ルールの欠如を隠してビジネスプロセスの絶えず増加する複雑性を償うために、ネットワークベースのファイアウォールは、一般にＮＡＴとして公知のネットワークアドレス変換又は一般にＰＡＴとして公知のポートアドレス変換を介して、ＩＰアドレスを変更して具体的な内部ネットワーク構成を隠すことができる。しかしながら、メッセージングのコンテキストは、この種の「処置」ではコンテンツの外観が変更されるとはいえ同じ状態のままである。この種の処置は、特定の取引タイプのビジネスプロセスの変更又は終了を隠すために又は是正するために役立たず、同様に特定の取引又は状態の許可又は不許可を経時的に変更するのに役立たない。更にこの種の処置では、企業間分散プロセス全体にわたる様々なリスクが識別され解決される単純な方法で、動的に追加されることになる様々な監視技術又は制御技術を考慮することができない。
【００１１】
従って、効果的にリスクを監視すると共にリスクポリシーを変更又は更新する柔軟性を許容するシステム、方法、及び装置に対するニーズが存在する。
【００１２】
（発明の開示）
本発明は、各々がそれに関連して複数のリスクカテゴリに対して複数のドキュメント値を含む複数のドキュメントインスタンスの少なくとも１つを評価する段階と、少なくとも１つのビジネスプロセスに承認された少なくとも１つの受諾可能なリスクポリシーに従って複数のリスクカテゴリを実行する段階と、少なくとも１つのリスクカテゴリの少なくとも１つのドキュメントの承認評定に従って複数のドキュメントの少なくとも１つに適格性を与える段階とを含む、少なくとも１つのビジネスプロセスに関連するリスクを監視する方法、システム、及び装置を備えている。
【００１３】
つまり、本発明は、効果的にリスクを監視すると共にリスクポリシーを変更又は更新する柔軟性を許容にするシステム、方法、及び装置を提供する。
本発明は、添付図面と共に本発明の以下の詳細な説明を検討することで容易に理解できるであろう。図面中、同じ数字は類似の部分を示している。
【００１４】
（発明を実施するための最良の形態）
本発明の図面及び説明は、本発明を明確に理解するのに関連する要素を示すために簡略化されており、一般的な情報装置、機器、システム、及び方法に見いだされる多数の他の要素は明瞭にするため取り除かれていることを理解されたい。当業者であれば、本発明を実施するために他の要素が望ましいこと及び／又は必要であることを理解できるであろう。しかしながら、このような要素は、本技術分野では公知であり、これらは本発明の一層の理解を助けないので、このような要素の説明は本明細書では行わない。本明細書の開示は、全てここに開示され当業者には公知の又は明らかなアプリケーション、ネットワーク、システム、及び方法の変形例及び変更例に向けられている。更に、本発明は、本明細書全てに例示的に説明されているが、当業者であれば、本明細書開示に基づいて、本発明が無数の商取引及び処理に好都合に採用できることを理解できるであろう。
【００１５】
図１は、リスクポリシー１０７に対して複数の値１０４を含むドキュメント１０１の評価を示すフローダイアグラムである。ドキュメント１０１は、Ｗｅｂアクセス、Ｗｅｂサービス、ゲートウェイ、光学的文字認識（ＯＣＲ）又は走査等によって電子的形式に変換された物理的ドキュメントを介して、又は当業者に公知の任意の類似の方法によって図示のシステムに提供することがきる。本発明は、ドキュメント又はその電子的形式に変換されたものが提供される方法に限定されるものではない。
【００１６】
本明細書で用いる場合、ドキュメント１０１は、ビジネスシステム又はプロセスにとって重要な値であり、又はその値を表す。値は、本技術分野で公知のように、例えばレコード内のフィールドである。ドキュメント１０１は、最初は書面ベースの定義又は構造を有するか、又は確立された又は構造化されたデータソースの１つ又はそれ以上のドキュメントのサブセット又はスーパーセットである。この種のデータソース又は書面ベースの定義は、他のソースから取得した値を含む、値を含むことができる。ドキュメント１０１への参照は、限定されるものではないが、ドキュメント内の全てのフィールドへの参照である。
【００１７】
ドキュメントは、ＲＤＳシステム及びそれに関連するインフラストラクチャに定義することができる。例えば、スクリプト言語、又はＧＵＩ（グラフィックユーザインタフェース）を実行する技術、又は他の表現を使用することができる。本発明の１つの態様によれば、ＸＭＬ［ＸＭＬ］などの拡張言語を使用することができる。ここで使用されるＸＭＬは、『Ｓｕｒｖｅｙ Ｓａｍｐｌｅ：Ｗｅｂ Ｆｏｒｍ Ｄｅｓｉｇｎ ｉｎ ＡＳＰ．ＮＥＴ』（Ａｌｌｅｎ Ｗａｇｎｅｒ著）に基づく。
ＸＭＬコードの例を以下に示す。
【００１８】
（ＸＭＬ−Ａ）
＜Ｄｏｃｕｍｅｎｔ Ｔｉｔｌｅ＝”ＢｕｉｌｄｉｎｇＳｅｃｕｒｉｔｙ” ＳｏｕｒｃｅＴｙｐｅ＝”ＵｓｅｒＷｅｂＩｎｐｕｔ” Ｓｏｕｒｃｅ＝”ｗｗｗ．ｘｘｘ．ｃｏｍ／ｓｕｒｖｅｙ”＞ ＜Ｄｅｓｔｉｎａｔｉｏｎ＝ ”ＭａｓｔｅｒＤＢ．ＢｌｄＳｅｃｕｒｉｔｙ”＞
＜Ｑｕｅｓｔｉｏｎ ＩＤ＝”０” ｖｉｓｉｂｌｅ＝”ｙｅｓ” Ｔｅｘｔ＝”Ｂｕｉｌｄｉｎｇ Ｎｕｍｂｅｒ？” Ｔｙｐｅ＝”Ｎｕｍｅｒｉｃ”＞
＜Ａｎｓｗｅｒ Ｔａｇ＝”Ｂｕｉｌｄｉｎｇ Ｎｕｍｂｅｒ” ＰｒｉｍａｒｙＫｅｙ＝”ＢＬＤ”＞
＜／Ｑｕｅｓｔｉｏｎ＞
＜Ｑｕｅｓｔｉｏｎ ＩＤ＝”１” ｖｉｓｉｂｌｅ＝”ｙｅｓ” Ｔｅｘｔ＝”Ｗｈａｔ ｃｏｕｎｔｒｙ ｉｓ ｂｕｉｌｄｉｎｇ ｉｎ” Ｔｙｐｅ＝”Ｃｈａｒａｃｔｅｒ”＞
＜Ａｎｓｗｅｒ Ｔａｇ＝”ＣｏｕｎｔｒｙＶａｌｕｅ”＞
＜／Ｑｕｅｓｔｉｏｎ＞
＜Ｑｕｅｓｔｉｏｎ ＩＤ＝”２” ｖｉｓｉｂｌｅ＝”ｎｏ” Ｔｙｐｅ＝”ｒｅａｌ”＞
＜Ａｎｓｗｅｒ Ｃｏｍｐｕｔｅ＝ＣｏｕｎｔｒｙＲｉｓｋＴａｂｌｅ（ＣｏｕｎｔｒｙＶａｌｕｅ）．ｒｉｓｋｖａｌｕｅ ＊ ４＞
＜／Ｑｕｅｓｔｉｏｎ＞
＜Ｑｕｅｓｔｉｏｎ ＩＤ＝”３” ｖｉｓｉｂｌｅ＝”ｙｅｓ” Ｔｅｘｔ＝”Ａｒｅ Ｆｅｎｃｅｓ ｈｉｇｈｅｒ ｔｈａｎ １０ ｆｅｅｔ？” Ｔｙｐｅ＝”ｉｎｔｅｇｅｒ”＞
＜Ａｎｓｗｅｒ ＩＤ＝”１” Ｔｅｘｔ＝”Ｙｅｓ”＞
＜Ａｎｓｗｅｒ ＩＤ＝”２” Ｔｅｘｔ＝”Ｎｏ”＞
＜／Ｑｕｅｓｔｉｏｎ＞
＜Ｑｕｅｓｔｉｏｎ ＩＤ＝”４”， ｖｉｓｉｂｌｅ＝”ｙｅｓ” Ｔｅｘｔ＝”Ｄｏ ｆｅｎｃｅｓ ｈａｖｅ ｂａｒｂｅｄ ｗｉｒｅ？” Ｔｙｐｅ＝”ｍｕｌｔｉｐｌｅ ｃｈｏｉｃｅ＞
＜Ａｎｓｗｅｒ ＩＤ＝”１” Ｔｅｘｔ＝”Ｙｅｓ”＞
＜Ａｎｓｗｅｒ ＩＤ＝”２” Ｔｅｘｔ＝”Ｎｏ”＞
＜／Ｑｕｅｓｔｉｏｎ＞
＜／Ｄｏｃｕｍｅｎｔ＞
【００１９】
本発明の本態様によれば、ｓｕｒｖｅｙ等のドキュメント１０１を指定できる。このドキュメント仕様はデータ定義を作成できるが、当業者であれば既存のデータベース定義を組み込むための他の方法を理解できるであろう。ＳｏｕｒｃｅＴｙｐｅは、一次キーＢＬＤを備えるＭａｓｔｅｒＤＢ．ＢｌｄＳｅｃｕｒｉｔｙ等のデータベース内の適切なレコードに情報を保存するＷｅｂベース入力とすることができる。配置されるＷｅｂサイトは、本例ではｗｗｗ．ｘｘｘ．ｃｏｍ／ｓｕｒｖｅｙである。
【００２０】
Ｑｕｅｓｔｉｏｎ（質問）はＩＤを用いて番号付けを行い、本例では「Ｖｉｓｉｂｌｅ」フラグが「Ｙｅｓ」か否かに基づいて表示される。本例では、表示される質問は「Ｔｅｘｔ」で提供され、応答タイプは「Ｔｙｐｅ」で提供される。Ｔｙｐｅは、限定されるものではないが、「ｃｈａｒａｃｔｅｒ（文字）」、「ｎｕｍｅｒｉｃ（数値）」、「ｆｒｅｅｆｏｒｍ（フリーフォーム）」、「ｍｕｌｔｉｐｌｅ ｃｈｏｉｃｅ（複数選択）」、Ｂｏｏｌｅａｎ等を指定することができる。他のタイプは当業者には明白であり、適切な又は不適切な入力タイプに照らして確認することができる。
【００２１】
「Ａｎｓｗｅｒ（回答）」は、前述の例では複数の目的があり、通常は送信者の入力を表す。送信者は、例示的に、人物、プロセス、自動化された又は手動の電子的又は機械的入力とすることができる。
【００２２】
「Ｔａｇ（タグ）」は質問の変数名として使用できる。前述の例では、ＣｏｕｎｔｒｙＶａｌｕｅ（ＩＤ＝１で定義）は、ＩＤ＝２の計算フィールドにおいてＣｏｕｎｔｒｙＶａｌｕｅでインデックス付けされたＣｏｕｎｔｒｙＲｉｓｋＴａｂｌｅのリスク値を表示する。本例の質問に対する回答は、本例の入力の間は表示されないが、Ｃｏｕｎｔｒｙのリスク値を４で乗算した値である。
【００２３】
前述の例は、Ｗｅｂベースの入力を示す。当業者であれば、他の入力フォームを提供できることが理解できであろう。例えば、質問が表示されず、データベース等のデジタルフォーマットから「回答」又は入力として、情報にアクセスする問い合わせ等の、電子的問い合わせの形式を取ることができる。質問に応答する入力は、データベース、ディレクトリ、又はフラットファイル等のデータストアの中の情報を表す任意の送信済み電子パケットとすることができる。この場合、データ記述は、入力されることになる値を取得する方法を記述する。例えば、データ記述は、値がデータベーステーブル内の特定のフィールドであること、又はデータ値内のビットＹから始まる先頭Ｘビットであることを記述することができる。「ｖｉｓｉｂｌｅ＝”Ｎｏ”」の場合、質問に応答する入力は、人間の入力から取得したのではなく計算値である。
【００２４】
図４は、「Ｔａｇ」及び「ｃｏｍｐｕｔｅ（計算）」の例示的な使用を示す。同様に、ドキュメント１０１は一連の値を含むことができる。簡単にするため、値１〜値４（前述の行４０２）は本例ではユーザに表示され、その行より下の残りの値はユーザに表示されない。値ｎ ４０３は、図示のように本実施形態では値１のコピーである。値５ ４０５は、データベース４０６等のローカルストアから取得される。値５及び値６はタグで各々識別されるが、このタグは説明を目的としており、それぞれＴＡＧ＿Ｖ５（例えば＜Ａｎｓｗｅｒ Ｔａｇ＝”ＴＡＧ＿Ｖ５”＞）及びＴＡＧ＿Ｖ６として表わされる。より複雑な計算４０４は、セキュリティシステムに必要であり、計算可能な任意の関数ｆであり、表示値及び非表示値を利用することができる。関数ｆの結果は、本例では値６の結果の配置等の必要な又は要求された場所に導くことができる。これは、例えば前述の例のように＜Ａｎｓｗｅｒ Ｃｏｍｐｕｔｅ＝”ＴＡＧ＿Ｖ５＊ＴＡＧ＿Ｖ６”＞としてコード化される。
【００２５】
図１の説明に戻ると、リスクカテゴリ１０２は、リスクを一定の目的を解決する様々なグループに分類でき、１つ又はそれ以上のビジネスプロセスの許容可能なリスクに基づくことができる。例えば［ＢＳ ７７９９］では、情報セキュリティは機密性（Ｃ）、整合性（Ｉ）、及び可用性（Ａ）の維持という特徴がある。リスク管理アプリケーションでは、システムが様々な固有基準又は適用基準に基づいて別々に評価され、この種の評価が同時に解析できることが一般的である。前述の機密性、整合性、又は可用性の等級を用いるＢＳ ７７９９の例では、各々の基準を満たすために必要な制御は異なっており、実際には、一部のケースでは矛盾することがある。例えば、コンテナ出荷では、商品の積込み及び商品のコンテナへの封入を制御するプロセスの評価は、別個の異なる、矛盾する可能性のあるリスク関連基準に基づいて評価される場合がある。
【００２６】
図１で参照されたリスクカテゴリ（Ｒｉｓｋ Ｃａｔｅｇｏｒｉｅｓ）は、限定されるものではないが、例えば、ＸＭＬ又は類似のスキーマで指定することができる。例えば、この種のリスク分類のＸＭＬコーディングを以下に示す。
【００２７】
＜Ｒｉｓｋ Ｃａｔｅｇｏｒｉｅｓ＞
＜Ｃａｔｅｇｏｒｙ Ｎａｍｅ＝”Ｃｏｎｆｉｄｅｎｔｉａｌｉｔｙ” Ｄｅｓｃｒｉｐｔｉｏｎ＝”Ｆｏｒ ｐｒｉｖａｃｙ ｐｒｏｔｅｃｔｉｏｎ”＞
＜Ｃａｔｅｇｏｒｙ Ｎａｍｅ＝”Ｉｎｔｅｇｒｉｔｙ” Ｄｅｓｃｒｉｐｔｉｏｎ＝”Ｆｏｒ ｍｏｄｉｆｉｃａｔｉｏｎ ｏｆ ｄａｔａ”＞
＜Ｃａｔｅｇｏｒｙ Ｎａｍｅ＝”Ａｖａｉｌａｂｉｌｉｔｙ” Ｄｅｓｃｒｉｐｔｉｏｎ＝”Ｆｏｒ ａｂｉｌｉｔｙ ｔｏ ｕｓｅ ｒｅｓｏｕｒｃｅ”＞
＜／ＲｉｓｋＣａｔｅｇｏｒｉｅｓ＞
【００２８】
しかしながら、リスクカテゴリは、リスクの一部の属性の特定のリスク態様ではなく、リスクの一部の属性に対するリスクの集計とすることができる。つまり、集計は、１対１ １０６、多対１ １０９、又は１対多 １０５とすることができる。このように、前述の例示的なＸＭＬ−Ａは、以下のように変更することができる。
【００２９】
（ＸＭＬ−Ｂ）
＜Ｑｕｅｓｔｉｏｎ ＩＤ＝”３” ｖｉｓｉｂｌｅ＝”ｙｅｓ” Ｔｅｘｔ＝”Ａｒｅ Ｆｅｎｃｅｓ ｈｉｇｈｅｒ ｔｈａｎ １０ ｆｅｅｔ？” Ｔｙｐｅ＝”ｉｎｔｅｇｅｒ”＞
＜Ａｎｓｗｅｒ ＩＤ＝”１” Ｔｅｘｔ＝”Ｙｅｓ”＞
＜Ｒｉｓｋ Ｎａｍｅ＝”ＲｉｓｋＣａｔ１” Ｓｃｒｉｐｔ＝”Ａｄｄ（５０）”＞
＜Ｒｉｓｋ Ｎａｍｅ＝”ＲｉｓｋＣａｔ２” Ｓｃｒｉｐｔ＝”Ａｄｄ（２０）”＞
＜／Ａｎｓｗｅｒ｝
＜Ａｎｓｗｅｒ ＩＤ＝”２” Ｔｅｘｔ＝”Ｎｏ”＞
＜Ｒｉｓｋ Ｎａｍｅ＝”ＲｉｓｋＣａｔ１” Ｓｃｒｉｐｔ＝”Ａｄｄ（１０）”＞
＜Ｒｉｓｋ Ｎａｍｅ＝”ＲｉｓｋＣａｔ２” Ｓｃｒｉｐｔ＝”Ｓｕｂｓｔｒａｃｔ（１０）”＞
＜／Ａｎｓｗｅｒ＞
＜／Ｑｕｅｓｔｉｏｎ ＞
【００３０】
ＸＭＬ−Ｂで質問３の応答が「Ｙｅｓ」であれば、５０がリスクカテゴリ１に追加され、２０がリスクカテゴリ２に追加される。Ａｎｓｗｅｒ ＩＤ＝”２”で示すように、減算、加算、除算、乗算、定数又は係数の乗算、又は他の計算関数を利用できる点に留意されたい。更に、計算は各段階で生じることができる。例えば、回答ＡがＹＥＳであれば３を乗算し、その結果が５０より大きければ質問Ｂを質問して応答が回答Ｃであれば３を減算する。更に、１つ、又は多数、又は他のソースのデータを、この種の計算の実行時に取り出すことができる。例えば、関数Ｆは入力値（例えば「Ａｄｄ（ｔｈｉｓＩｎｐｕｔ＊５）」）に対して実行され、応答（つまりｔｈｉｓＩｎｐｕｔ）に５を乗算し、その結果を適切なリスクカテゴリに追加することができる。関数は複雑であってもよく、例えば、Ｊａｖａ（登録商標）又は別の高級言語を用いるプログラミングスクリプトを組み込むといった、他のプログラミング態様を含むことができる。限定されるものではないが、プログラミングスクリプト又は計算は、関数内で値を表すために、又は例えばデータベース又はＷｅｂロケーションテーブル内の値などの値を検索するインデックスとして、ＸＭＬ−Ａに記述されている「ＣｏｕｎｔｒｙＶａｌｕｅ」等のタグ名を指定できる。
【００３１】
リスクカテゴリは、１つ又はそれ以上のリスクポリシー１０７に従って解析することができる。その結果、ドキュメント１０１、詳細にはドキュメント１０１の値は、１つ又はそれ以上の要求されたリスクポリシーに基づいて、リスクポリシーに照らして評価することができる。
【００３２】
以下の例では、複数のルールが適用され、「Ａｃｔｉｏｎ（アクション）」、つまり専門言語又は公知の言語（例えばＢａｓｉｃ、Ｖｉｓｕａｌ Ｂａｓｉｃ、Ｃ、Ｃ＋＋、Ｊａｖａ（登録商標）、Ｐｅｒｌ）を用いるスクリプトは、「Ｃｒｉｔｅｒｉａ（基準）」、つまり真又は偽を返すスクリプトが評価される場合に実行される。当業者には、以下の例が特定の言語に限定されず、例えばＸＭＬで実行できることは明らかであろう。
【００３３】
Ｎａｍｅ： ＜ｐｏｌｉｃｙ ｎａｍｅ＞
Ｒｕｌｅ： ＜ｌａｂｅｌ＞
Ｃｒｉｔｅｒｉａ： ＜ｃｏｎｄｉｔｉｏｎａｌ ｓｃｒｉｐｔ＞
Ａｃｔｉｏｎ： ＜ｓｃｒｉｐｔ＞
Ｐｏｌｉｃｙ−Ｒｕｌｅ：
ＰｏｌｉｃｙＮａｍｅ： ＳｉｌｖｅｒＢｕｉｌｄｉｎｇ
Ｒｕｌｅ： ＲｅｑｕｉｒｅＳｕｐｅｒｖｉｓｏｒ
Ｃｒｉｔｅｒｉａ： （（Ｒｉｓｋｃａｔ１ ＞ ５０） ｏｒ （Ｒｉｓｋｃａｔ２＞１０００）） ａｎｄ （ｒｉｓｋｃａｔ３＞５）
Ａｃｔｉｏｎ： Ｒｅｑｕｉｒｅ（”Ｓｕｐｅｒｖｉｓｏｒ”， ＲＥＤ）； ｅｘｉｔ（）
Ｒｕｌｅ： ＥｍａｉｌＣｏｍｍｅｒｃｅ
Ｃｒｉｔｅｒｉａ： （（Ｒｉｓｋｃａｔ１ ＞ ２０） ｏｒ （Ｒｉｓｋｃａｔ２＞１００））
Ａｃｔｉｏｎ： Ｎｏｔｉｆｉｃａｔｉｏｎ （ｅｍａｉｌ， ”ｗａｒｎｉｎｇ＠ｃｏｍｍｅｒｃｅ．ｃｏｍ”， ”Ｒｅｖｉｅｗ Ｃｏｍｐａｎｙ Ｘ Ｗａｒｎｉｎｇ ｌｏｇｓ”）
Ｒｕｌｅ： Ａｃｃｅｐｔ
Ｃｒｉｔｅｒｉａ： Ｎｕｌｌ
Ａｃｔｉｏｎ： Ａｃｃｅｐｔ（”１ Ｊｕｎｅ ２００４”）
【００３４】
前述の例は上から下に解釈される。以下に注目すべき関数の一部を例示するが、関数はそれらに限定されるものではない。
【００３５】
Ｅｘｉｔ（）：終了し、任意の追加的ルールに照らしたテストを行わない。
Ｒｅｑｕｉｒｅ（＜Ｇｒｏｕｐ＞，＜ＦＬＡＧ＞，＜ｅｆｆｅｃｔｉｖｅ ｄａｔｅ＞）：ドキュメントの受諾は、グループ＜Ｇｒｏｕｐ＞の誰かが受諾することが必要である。ユーザには、ユーザが問題の重要性を理解するのに役立つようにＦＬＡＧ値（例えばＲＥＤ条件）が提供され、＜ｅｆｆｅｃｔｉｖｅ ｄａｔｅ（発効日）＞はグループのユーザがドキュメントを受諾した場合に、ドキュメントのユーザによる受諾の発効日を記述する（つまり、受諾の有効期間）。
【００３６】
Ｎｏｔｉｆｉｃａｔｉｏｎ（＜ｔｙｐｅ＞，＜ｕｓｅｒ ｎａｍｅ＞，＜ｓｕｂｊｅｃｔ＞，＜Ｂｏｄｙ＞）：＜ｕｓｅｒ ｎａｍｅ（ユーザ名）＞に、件名＜ｓｕｂｊｅｃｔ＞、本文＜Ｂｏｄｙ＞の通知を送信する。通知の種類として電子メール、カレンダー、ファックス、自動通話、及び他の形式の通知システムを挙げることができるが、これらに限定されるものではない。緊急通知は、警察、運輸、商業、軍事時、又は他の機関等による優先度の高い応答者アクションに関して政府機関（例えば「９１１」呼び出し）に電話をかけることができる。
【００３７】
Ｓｃｈｅｄｕｌｅ（＜ｄａｔｅ／Ｔｉｍｅ＞，＜ａｃｔｉｏｎｓ ｓｃｒｉｐｔ＞）：これは、特定の日付及び時刻（＜ｄａｔｅ／Ｔｉｍｅ＞フィールド）に実行されることになるアクションスクリプトをスケジュールする。例えば、特定の時刻の後に取引を開始すること又は通知を設定することができる。
Ａｃｃｅｐｔ（＜ｄａｔｅ＞）：インスタンスがポリシーに照らして受諾され、日付フィールド内の日付を含む日付まで有効である。
【００３８】
Ｓｔｏｒｅ（＜ｖａｌｕｅ１＞，＜ｌｏｃａｔｉｏｎ１＞，＜ｖａｌｕｅ２＞，＜ｌｏｃａｔｉｏｎ２＞，．．．）：値１を場所１に、値２を場所２になどと保存する。場所として、例えばデータベースフィールドがある。保存は、例えばローカルストレージ又はインターデータストア又はイントラデータストアに行われる（図５を参照）。
【００３９】
ＰｕｓｈＰｏｌｉｃｙ（＜ｐｏｌｉｃｙ ｄｅｓｃｒｉｐｔｉｏｎ＞：これはポリシーを本システムに設定する又は別のシステムに設定する。例えば、一部の条件セットを満たすことが、他のＲＤＳを処理するＲＤＳインスタンスのポリシー変更を引き起こす。
【００４０】
ＣｒｅａｔｅＴｒａｎｓａｃｔｉｏｎ（＜ｔｒａｎｓａｃｔｉｏｎ ｔｙｐｅ＞，＜ｒｅｃｉｐｉｅｎｔ＞，＜ｆｉｅｌｄ１＞，＜ｖａｌｕｅ１＞，．．．）：ＰｕｓｈＰｏｌｉｃｙに類似するが、取引作成は、取引ドキュメントを取引タイプフォームの受取人に送信する。取引データフィールドは、値１をフィールド１に配置する。
【００４１】
当業者には本明細書の開示に照らして理解できるであろうが、特別なスクリプト及び他のプログラミング言語の形式は、より高機能及び複雑な基準及びルールのコーディングを許容するために、本発明で同様に使用できる。この種の追加的な複雑性としては、外部から内部へ及び内部から外部へのループを含むループ構造、外部の特別なスクリプト、初期値、及び他の複雑な条件文を含む外部データへのアクセス等を挙げることができる。
【００４２】
ポリシーテンプレートは、リスクポリシー生成を可能するための、又はリスクポリシーの入力として利用するためのデータ移転を可能にするため、提案、変更、修正、又は一般的に受諾された業務を提供することができる。例えば、ポリシーデータは、当業者には明らかなように多数の形式を取ることができ、ポリシーテンプレートは一方の形式から別の形式への移転を実現できる。以下に、ＸＭＬを用いて示した「トリガポリシー」ポリシーテンプレートを例示的に説明する。
【００４３】
（トリガポリシー）
＜ＴｒｉｇｇｅｒＰｏｌｉｃｙ＞
＜Ｅｖｅｎｔ ＩＤ＝”１” Ｄｏｃｕｍｅｎｔ＝”ＢｕｉｌｄｉｎｇＳｅｃｕｒｉｔｙ” Ｃｒｉｔｅｒｉａ＝” ＣｏｕｎｔｒｙＶａｌｕｅ ＝ ”Ｋｏｒｅａ”＞
＜Ｐｏｌｉｃｙ Ｎａｍｅ＝”ＧｏｌｄＢｕｉｄｉｎｇＡｓｉａ”＞
＜Ｐｏｌｉｃｙ Ｎａｍｅ＝”ＳｉｌｖｅｒＢｕｉｌｄｉｎｇ”＞
＜／Ｅｖｅｎｔ＞
＜Ｅｖｅｎｔ ＩＤ＝”２” Ｄｏｃｕｍｅｎｔ＝”ＢｕｉｌｄｉｎｇＳｅｃｕｒｉｔｙ”＞
＜Ｐｏｌｉｃｙ Ｎａｍｅ＝”ＧｏｌｄＢｕｉｄｉｎｇ”＞
＜Ｐｏｌｉｃｙ Ｎａｍｅ＝”ＳｉｌｖｅｒＢｕｉｌｄｉｎｇＡｓｉａ”＞
＜／Ｅｖｅｎｔ＞
＜Ｅｖｅｎｔ ＩＤ＝”３” Ｄｏｃｕｍｅｎｔ＝”ＦａｃｉｌｉｔｙＳｕｒｖｅｙ”＞
＜Ｐｏｌｉｃｙ Ｎａｍｅ＝”ＳｕｒｖｅｙＰｏｌｉｃｙ”＞
＜／Ｅｖｅｎｔ＞
＜／ＴｒｉｇｇｅｒＰｏｌｉｃｙ＞
【００４４】
例えば、例示的な「ＢｕｉｌｄｉｎｇＳｅｃｕｒｉｔｙ」ドキュメントでは（前述の例のＸＭＬ−Ａ及びＸＭＬ−Ｂを参照）、トリガポリシーテンプレートは最初にＣｏｕｎｔｒｙ（カントリー）の値が「Ｋｏｒｅａ」に一致するかどうかを調べる。一致すれば、ポリシーＧｏｌｄＢｕｉｌｄｉｎｇＡｓｉａ及びＳｉｌｖｅｒＢｕｉｌｄｉｎｇがドキュメントに対してテストされる。一致しなければ、ポリシーＧｏｌｄＢｕｉｌｄｉｎｇ及びＳｉｌｖｅｒＢｕｉｌｄｉｎｇＡｓｉａがドキュメントに対してテストされる。
【００４５】
また、トリガポリシー等のポリシーテンプレートは、他のインスタンスを作成又は組み込むことができる。以下に例を示す。
【００４６】
＜Ｅｖｅｎｔ ＩＤ＝”１” Ｄｏｃｕｍｅｎｔ＝”ＢｕｉｌｄｉｎｇＳｅｃｕｒｉｔｙ” Ｃｒｉｔｅｒｉａ＝”ＣｏｕｎｔｒｙＶａｌｕｅ ＝ Ｋｏｒｅａ”＞
＜Ｒｅｐｌａｃｅ Ｄｏｃｕｍｅｎｔ＝”ＫｏｒｅａＢｕｉｌｄｉｎｇＦｏｒｍ”＞
＜／Ｅｖｅｎｔ＞
＜Ｅｖｅｎｔ ＩＤ＝”２” Ｄｏｃｕｍｅｎｔ＝”ＫｏｒｅａＢｕｉｌｄｉｎｇＦｏｒｍ” Ｃｒｉｔｅｒｉａ＝” ＣｏｕｎｔｒｙＶａｌｕｅ ＝ ”Ｋｏｒｅａ”＞
＜Ｐｏｌｉｃｙ Ｎａｍｅ＝”ＧｏｌｄＢｕｉｄｉｎｇＡｓｉａ”＞
＜Ｐｏｌｉｃｙ Ｎａｍｅ＝”ＳｉｌｖｅｒＢｕｉｌｄｉｎｇ”＞
【００４７】
本例では、ＢｕｉｌｄｉｎｇＳｅｃｕｒｉｔｙドキュメントは新規ドキュメントＫｏｒｅａＢｕｉｌｄｉｎｇＦｏｒｍに変換される。フォームＫｏｒｅａＢｕｉｌｄｉｎｇＦｏｒｍの新規インスタンスはトリガポリシーを通過する。ＢｕｉｌｄｉｎｇＳｅｃｕｒｉｔｙからＫｏｒｅａＢｕｉｌｄｉｎｇＦｏｒｍへのマッピングは、当業者には明らかなように様々な方法で実現できる。タグ値からタグ値へのマッピングは、ポリシーテンプレートを用いる情報移転についての例示的なアプローチである。例えば、カントリー値は２つのフォームで存在することができ、ポリシーテンプレートマッピングは１対１で行われる。
【００４８】
本明細書で用いる場合、ドキュメント１０１のインスタンスは、承認されたインスタンス又は否認されたインスタンスのいずれかである。ドキュメントインスタンスは、次の２つの条件の内の１つが真ならば承認されたドキュメントである。
【００４９】
（１）Ａｃｃｅｐｔ（）が実行された。
（２）Ｒｅｑｕｉｒｅ（）が実行され、その中でＲｅｑｕｉｒｅ（）で指定されたグループの１メンバがドキュメントを承認した。
【００５０】
計算１０８は、リスクカテゴリの計算例を示す。計算方法は、例えば、複雑でエンティティに固有であるか又は汎用的でエンティティに固有でない。簡単にするため、本例では例示的な操作は次の形式になる。Ｆ（ｇ（Ｖａｌｕｅ），ｈ（Ｖａｌｕｅ，Ｖａｌｕｅ‘））＝Ｒｉｓｋ Ｃａｔ Ｖａｌｕｅ。ここで、Ｆは入力値の数学的合計である。本例でｇ及びｈは、（値＝真）ならば５０を返し、それ以外では１００を返すといった様々な代数関数とすることができる。同様に、複数の選択肢を一般化できる。例えば、ある計算は（値×定数）を返す。ここで定数は定義済みの整数である。つまり、値ｇ及びｈは１つ又は複数の入力であるか又は１つ又は複数の入力を必要とし、その入力は、質問に応答するデータ入力などの外部入力であるか、又はｈの計算１０８のように取得データへの定数の適用などの内部入力である。
【００５１】
図２は複数のリスクポリシーの適用を示すフローダイアグラムである。ドキュメント１０１のドキュメントインスタンス２０２は、本例では特定の入力インスタンス用の「記入フォーム」を表す。例示的なドキュメントインスタンス２０２は、１つ又はそれ以上のリスクカテゴリに照らして重み付けされ２０５、ここでリスクカテゴリ値ｘ、ｙは、リスクカテゴリｙのドキュメントｙの値を表す。結果的に、ドキュメントインスタンス２０２は、特定の例示的なリスクポリシー２０１に関して、グループのユーザがドキュメントインスタンスを受諾又は否認した後に、Ａｃｃｅｐｔ（）関数を介して又はＲｅｑｕｉｒｅ（）関数を介して承認されるというようにして承認される。ドキュメントインスタンス２０２は、例えば所定のドキュメント１０１に対するリスクポリシーアプリケーションの階層において最終的な承認の前に、複数のポリシー２０３、２０４により承認され得る。
【００５２】
図２の例示的な実施形態において、リスクポリシー２０３は１つのポリシーでのみ受諾されたドキュメントインスタンスを明示し、リスクポリシー２０４は複数のポリシーにより承認されたドキュメントインスタンスを明示する。
【００５３】
ＸＭＬ−Ｂの例において、リスクカテゴリ（ＲｉｓｋＣａｔ）値はドキュメントに依存し、同じドキュメントインスタンスは別のポリシーに関連する値などの複数のＲｉｓｋＣａｔ値を生成しないことに留意されたい。しかしながら、同じドキュメントインスタンスは、リスクカテゴリが各々のポリシーで異なる値を持つとみなすことで、２つの異なるポリシーで評価できる。例えば、ある会社が内部機密ポリシー及び外部機密ポリシーをもつことができる。このようなポリシーは、組織から発せられる任意の機密デジタルデータが送信中に暗号化される必要があるのに対して、内部で送信されるデータは暗号化される必要がない可能性がある。つまり、ドキュメントは、内部サーバから発せられるデータが暗号化されるか否かを指定する。結果的に、内部ポリシーについて、「機密」リスクカテゴリは一般に、内部サーバから同じ又は別の内部サーバへの送信には影響を及ぼさないであろう。しかしながら、そのドキュメントの暗号化に関する「ＮＯ」の回答は、送信が外部向けであれば「機密」リスクカテゴリのリスクに影響を及ぼす。従って、本例では、機密リスクカテゴリのスコアは、ポリシーが異なると異なる結果になる。
【００５４】
例示的なＸＭＬ−Ｂにおけるこの制約は、リスクカテゴリが１つだけの意味をもつと理解する検閲者による評価を単純化することができる。リスクカテゴリに関するこの種の制約は単に例示的なものであり、本発明で使用される必要はない。リスク値の評価は、この種の例示的なアプローチにおいて、指定されたポリシールールに制約される。リスクポリシーの参照は、以下のようにＸＭＬ−Ｂに組み込むことができる。
【００５５】
＜Ｒｉｓｋ Ｎａｍｅ＝”ｃｏｎｆｉｄｅｎｔｉａｌｉｔｙ” ｐｏｌｉｃｙ＝”ｃｏｎｆｉｄｅｎｔｉａｌｉｔｙ− −ｅｘｔｅｒｎａｌ” Ｓｃｒｉｐｔ＝”Ａｄｄ（５）”＞
＜Ｒｉｓｋ Ｎａｍｅ＝”ｃｏｎｆｉｄｅｎｔｉａｌｉｔｙ” ｐｏｌｉｃｙ＝”ｃｏｎｆｉｄｅｎｔｉａｌｉｔｙ−ｉｎｔｅｒｎａｌ” Ｓｃｒｉｐｔ＝”Ａｄｄ（０）”＞
【００５６】
ドキュメントインスタンスは、ポリシーに関して承認を受けることができる。同様に、ポリシー及び適格性はリンクすることができる。図３は、ポリシーと適格性との間の関係を示すフローダイアグラムである。ドキュメントの組３０５は、関係３０６を介してポリシー又はポリシーの組３０１に関連する。適格性３０２は、１つ又はそれ以上のポリシーインスタンス３０１に関連する。例えば、ドキュメントインスタンス１０１又はドキュメントインスタンスの組３０５がポリシー１に照らして承認されると、適格性１ ３０２及び適格性２が得られる。適格性は複数のポリシー承認３０４を必要する場合がある。本例ではドキュメントインスタンスは、適格性３を得るためにポリシー２及びポリシーｍの承認を得る必要がある。従って、ポリシーと適格性との間に階層化が存在する場合がある。ポリシーの階層性に関して前述したように、適格性も同様に他の適格性及びポリシーの両方に関して階層性がある。適格性は、ＸＭＬなどでは以下の示すようにコード化することができる。
【００５７】
（ＱＵＡＬテンプレート）
＜Ｑｕａｌｉｆｉｃａｔｉｏｎｓ＞
＜ＱＵＡＬ Ｎａｍｅ＝”ＧｏｌｄＳｅａｌ” Ｄｅｓｃｒｉｐｔｉｏｎ＝”Ｃｏｒｐｏｒａｔｅ Ｇｏｌｄ Ｓｅａｌ ｆｏｒ Ｖｅｎｄｏｒ”＞
＜／Ｒｕｌｅｓ ＩＤ＝”１”＞
＜Ｃａｔ ＩＤ＝”１” Ｎａｍｅ＝”ＧｏｌｄＰｏｌｉｃｙＰｈｙｓｉｃａｌ”＞
＜Ｃａｔ ＩＤ＝”２” Ｎａｍｅ＝”ＧｏｌｄＰｏｌｉｃｙＰｒｏｃｅｓｓｅｓ”＞
＜／Ｒｕｌｅｓ＞＜／ＱＵＡＬ＞
＜ＱＵＡＬ Ｎａｍｅ＝”ＳｉｌｖｅｒＳｅａｌ” Ｄｅｓｃｒｉｐｔｉｏｎ＝”Ｃｏｒｐｏｒａｔｅ Ｓｉｌｖｅｒ Ｓｅａｌ ｆｏｒ Ｖｅｎｄｏｒ”＞
＜Ｒｕｌｅｓ ＩＤ＝”１”＞
＜Ｃａｔ ＩＤ＝”１” Ｎａｍｅ＝”ＧｏｌｄＰｏｌｉｃｙＰｈｙｓｉｃａｌ”＞
＜Ｃａｔ ＩＤ＝”２” Ｎａｍｅ＝”ＳｉｌｖｅｒＰｏｌｉｃｙＰｒｏｃｅｓｓｅｓ”＞
＜／Ｒｕｌｅｓ＞
＜Ｒｕｌｅｓ ＩＤ＝”２”＞
＜Ｃａｔ ＩＤ＝”１” Ｎａｍｅ＝”ＳｉｌｖｅｒＰｏｌｉｃｙＰｈｙｓｉｃａｌ”＞
＜Ｃａｔ ＩＤ＝”２” Ｎａｍｅ＝”ＧｏｌｄＰｏｌｉｃｙＰｒｏｃｅｓｓｅｓ”＞
＜／Ｒｕｌｅｓ＞
＜Ｒｕｌｅｓ ＩＤ＝”３”＞
＜Ｃａｔ ＩＤ＝”１” Ｎａｍｅ＝”ＳｉｌｖｅｒＰｏｌｉｃｙＰｈｙｓｉｃａｌ”＞
＜Ｃａｔ ＩＤ＝”２” Ｎａｍｅ＝”ＳｉｌｖｅｒＰｏｌｉｃｙＰｒｏｃｅｓｓｅｓ”＞
＜／Ｒｕｌｅｓ＞
＜／ＱＵＡＬ＞
＜／ＲｉｓｋＣａｔｅｇｏｒｉｅｓ＞
【００５８】
前述の例では、適格性「ＧｏｌｄＳｅａｌ」は、ＧｏｌｄＰｏｌｉｃｙＰｈｙｓｉｃａｌ及びＧｏｌｄＰｏｌｉｃｙＰｒｏｃｅｓｓｅｓが達成できた場合にのみ得ることができる。しかしながら、ＧｏｌｄＰｏｌｉｃｙＰｈｙｓｉｃａｌ又はＧｏｌｄＰｏｌｉｃｙＰｈｙｓｉｃａｌが達成され、更に同様にＳｉｌｖｅｒＰｏｌｉｃｙＰｒｏｃｅｓｓｅｓ又はＳｉｌｖｅｒＰｏｌｉｃｙＰｈｙｓｉｃａｌが達成されると「ＳｉｌｖｅｒＳｅａｌ」を得ることができるが、ＧｏｌｄＰｏｌｉｃｙＰｒｏｃｅｓｓｅｓ及びＧｏｌｄＰｏｌｉｃｙＰｈｙｓｉｃａｌの両方が達成されれば「ＳｉｌｖｅｒＳｅａｌ」を得ることができない。
【００５９】
図１０は、図４の例示的な説明を簡略化したものである。図示したように、ドキュメントインスタンスは異なる時期に入力された複数の入力「ドキュメント」に関連することができる。例えば、ドキュメントＡ（線１００２より下の値）は、時刻＝０に受信してデータベース１００４に保存することができる。ドキュメントＢ（線１００２より上の値）は、時刻＝１に受信することができる。ドキュメントＡは、ドキュメントインスタンス１００３に配置することができる。
【００６０】
前述のポリシー評価は、リスク検知システム（ＲＤＳ）の一部とすることができる。ＲＤＳは、図５で示したように大規模インフラストラクチャ内で存在できる。ＲＤＳは、ドキュメントに照らしてポリシーを評価すること、ポリシー５０７を評価するためにストレージを管理すること、及び適格性を決定することができる。ＲＤＳは、１つ又はそれ以上のアグリゲータ５０６にリンクすることができる。アグリゲータは、複数のＲＤＳから情報を取得してポリシー及びドキュメントを他のＲＤＳに供給するＲＤＳを備えることができる。２つのドキュメントが２つのＲＤＳで現れる場合、アグリゲータはイントラ・グローバルデータベース５０２のような調停者を備えることができる。アグリゲータは、部分的に履歴に基づいてポリシーを動的に生成又は適用することができる。例えば、別々のＲＤＳインスタンスからアグリゲータへの複数の入力が過度にカントリリスクにさらされることを示す場合、アグリゲータは様々なＲＤＳでポリシーを修正してリスクを制御することができる。例えば、カントリリスクの受諾可能なしきい値が高くリセットされているために、取引を表す修正後のドキュメントが修正後のポリシーによって受諾されなくなり、結果的に以前は受諾可能だったドキュメントのスコアが受諾できなくなる場合がある。
【００６１】
ＲＤＳ及びアグリゲータは、イントラ・グローバルデータベースから情報を受信すること、及びインターグローバルデータベース５０２から情報を取得することができる。インターグローバルデータベースは組織の外側にある。例えば、外部組織である税関国境保護局は、ビジネス相手として推奨できない人物又は法人の「監視リスト」、並びに特定のクラスの貨物向けの取扱要件等を制御する「監視リスト」を有する。米国務省は公知のテロリストリストを保持しており、他の官庁及び政府機関、規制機関、標準機構、パートナ、及び他の様々なプロバイダもＲＤＳにとって有益なデータを保持している。また、一部の会社は、動的及び予防的にポリシーを生成するために有益な統計的データ及び他のデータを提供することができる。この種の情報は、システムに配布して信頼レベルを確立することができる。
【００６２】
信頼マネージャ５０３は、公開鍵インフラストラクチャ（ＰＫＩ）［Ｘ５００、Ｘ５０９、ＲＦＣ３２８０］又はＫｅｒｂｅｒｏｓ［Ｎｅｕｍａｎ］又は本技術分野で公知の他の手段［Ｍｅｎｅｚｅｓ］といったセキュリティ信頼システムを表す。信頼マネージャは、内部規制組織又は外部規制組織によって管理される。規制組織は、インフラストラクチャ内で通信することが承認されたものを規制する任意の人物又はグループであり、これらの承認された通信者が有する権限を規制することができる。信頼マネージャは、セキュリティを拡張可能にすることができる。しかしながら、図５のインフラストラクチャは、暗号化鍵の物理的交換又は本技術分野で公知の他の方法等によってセキュリティを直接確立できるので、信頼マネージャの利用を必要としない。
【００６３】
入口５０１はデータを受け取るソースとすることができる。ＲＤＳは、入口から直接的に又は入口と共同してデータを受け取ることができる。入口は、侵入検知システムのプローブとすることができる。入口は、データだけを受け取ること、及びＲＤＳ又はインター又はイントラ・グローバルデータベースに、ＲＤＳ又はアグリゲータが使用するためのデータを配置することによって費用を低減できる。入口は特殊化すること及びＲＤＳの仕事負荷を軽減するために使用できる。
【００６４】
例えば、前述のＸＭＬ−Ｂはポリシーの執行を含むが、入口は一定レベルのドキュメントのポリシーレビューを行うことができる。これは、部外者がＲＤＳのポリシーを識別するリスクを低減する。また、入口は、直接的に又は信頼マネージャ５０３を介して信頼を確立できる。
【００６５】
図６は、ポリシーテンプレート、ポリシールール、又はＸＭＬ−Ａ又はＸＭＬ−Ｂ等の適格性又はドキュメントのポリシーテンプレートの安全な送信を示すフローダイアグラムである。例えば、テンプレート６０５を送信することができる６０２。送信者は、例えば、アグリゲータ、ＲＤＳ、又は規制組織とすることができる。信頼マネージャ６０４は、ＲＤＳ及び送信者６０３の間に信頼を確立できる。例として、信頼マネージャがＰＫＩであり、送信者によって送信されたメッセージが署名されている場合、ＲＤＳは証明書に基づいて署名を検証できる。アグリゲータとすることもできるＲＤＳは、認証されることができるテンプレートを受け取り、ポリシーテンプレートを以下の評価に組み込むことができる。
【００６６】
ポリシーテンプレートは、インフラストラクチャ内の様々な組織及び構成要素によって生成することができる。優先順位つまり評価順序は、図７で示すように指定される。前述のポリシールールアプリケーションの例では、ポリシーは「上から下に」評価される。ポリシー７０２はサブポリシーから構成することができる。例えば、ポリシー７０２はポリシー７０３の前に実行できる。政府機関が法人７０３又はローカルに設定された法人又は人物７０４に優先するように、一部の組織は高位に置くことができる。また、組織は、ポリシーテンプレートの中で優先順位を指定することができる。例を示す。
【００６７】
Ｒｕｌｅ：＜ｌａｂｅｌ＞
Ｐｒｉｏｒｉｔｙ：＜Ｈｉｇｈ＝１ ｔｏ Ｌｏｗ＝１０＞
Ｃｒｉｔｅｒｉａ：＜ｃｏｎｄｉｔｉｏｎａｌ ｓｃｒｉｐｔ＞
Ａｃｔｉｏｎ：＜ｓｃｒｉｐｔ＞
【００６８】
本例では、政府機関は複数のテンプレートをＲＤＳに配置して、これらに他のソース７０２にまさる優先順位を与えることができる。
【００６９】
ＲＤＳへのアクセスは様々な組織に許可される。アクセス制御は、ユーザが誰か及びユーザが識別される方法に基づいて、情報へのアクセスを制限すること及び情報の修正を制限することができる。図９はアクセス９０６を有するユーザ９０５を示す。ユーザ９０５は、規制間組織又は規制内組織９０２に所属することができる。信頼関係９０３は、信頼マネージャ９０４と規制組織９０２との間の信頼を示すこと、及び信頼関係９０７は信頼マネージャ９０４とＲＤＳ９０１との間の信頼を示すことができる。信頼は、コンピュータセキュリティ向けに開発されたメカニズムを通じて、信頼マネージャとユーザとの間に設定することができる。この種の例として、ユーザを検証するために規制機関を代理して行動するＰＫＩ内の登録代理人、及びユーザの公開鍵の証明プロセスを挙げることができる。信頼マネージャ９０４を介して確立された信頼関係に基づいて、ユーザは、ＲＤＳへの独自のアクセス権限を有し、一定のアクセス制御メカニズムを介してそのユーザに提供された権限に基づいてアグリゲータつまりグローバルデータベースへのアクセス権限を有することができる。政府の代理人又はパートナは制限又は拡張されたアクセスを有することができるが、内部のユーザは異なるアクセス権限を有することができる。例えば、政府の代理人は、定義されたイベントの発生、及びオンラインのＩＤ又はロールの証明の提供を含む適切な信用証明の提示を条件に、他の方法では制限されるデータ及びデータストアへの一定のアクセス権限が自動的に付与され得る。
【００７０】
ＲＤＳは、別のＲＤＳと通信して、ポリシー、ドキュメント、及び／又は適格性インスタンス又はテンプレートを提供することができる。ＲＤＳ１ ８０１は、ＲＤＳ２ ８０２又はグローバルデータベース８０６、８０３、８０４にオブジェクトを送信することができる。送信８０３又は８０４は、デジタル署名、又はＳＳＬ、ＶＰＮ、ＩＰＳＥＣ等による安全なトンネルを介して送信すること、又は当業者に公知の他の安全な手段によって、認証することができる。セキュリティは、送信８０３及び８０４への信頼関係８０５を介して信頼マネージャを通じて使用すること又は確立することができる。関係８０５は、公開鍵インフラストラクチャ（ＰＫＩ）における証明機関（ＣＡ）を代理する信頼マネージャ等による証明関係を表すことができる。
【００７１】
図８は、ＣＡを代理する信頼マネージャにより認定された公開鍵で署名されたインスタンスなどの安全な方法で、ＲＤＳが様々なインスタンス及びレポートを送り出すプッシュアプローチを示す。実際には、ＲＤＳはプッシュアプローチを必要とせず、引き出された情報に応じてローカルに情報を提供できる。つまり、ＲＤＳはプッシュの代わりにプルを提供する。したがって、ＲＤＳアプリケーション８０２、８０６はローカルにデータを要求して受信することができる８０１。
【００７２】
ＲＤＳ、又は同様にグローバルデータベース、又はファイル、ディレクトリ等の他のデータストアデータである外部に提供するデータは、ユーザに有用である。図８では、数種類の情報を提供することができる。レポートとして、監査ログ、発覚リスク集計、発見された異常、及び監査状態を示すイベントを挙げることができる。レポートにより外部の当事者は使用手順をレビューすることができるが、特定の監査レベルのアクセス権限も同様に必要であろう。適格性テンプレート、ポリシーテンプレート、又はドキュメントテンプレートにより、ＲＤＳが外部レビューのためにテンプレートを送信すること、又はＲＤＳが別のＲＤＳに組み込まれることが可能になる。
【００７３】
ＲＤＳは様々なロール（Ｒｏｌｅ）をサポートすることができる。これらのロールを以下に示す。ＲＤＳ管理者：限定されるものではないが、ユーザへのアクセス提供つまりＩＤ管理、グループ、及び外部構成要素へのアクセス提供、システム性能の監視、バックアップ実施の確認、及び他一般的にシステムが監視するリスクと関連のない基本タスク等のシステムの基本管理を行う。テンプレート作成者：ポリシー、ドキュメント、及び適格性テンプレートを含むアプリケーションで使用される各種テンプレートを作成する。
【００７４】
データ入力者：データをシステムに提供する。例えば、いくつかのフォームへの記入を許可されている他のフォームへの記入を許可されていない者や、特定のグループのフォームのみ記入することを許可された者など、異なる権限をもつデータ入力者の様々なカテゴリが存在する。
【００７５】
リスクマネージャ：リスクカテゴリ及び適格性についてポリシーの許容範囲、リスクカテゴリが決定される方法、及びポリシーが様々なカテゴリに対して行うアクションを指定する。
【００７６】
ドキュメント承認者：各々のインスタンス又は一部の定義済みグループ又はインスタンスのグループについて、ドキュメントの受諾を必要とするＲｅｑｕｉｒｅ（）アクションが設定されたときに、ポリシーに照らしてドキュメントインスタンスを承認する。
【００７７】
監督承認者：承認者の特別なグループ。一部の組織は、承認者並びにドキュメント承認の監督者を必要とする場合がある。
監査員：他者のアクションをレビューする読み取り専用のアクセスを有する。
【００７８】
ロールは、少なくとも部分的にコンピュータシステムによって実行できる。例えば、テンプレートはＲＤＳ及びアグリゲータによっても作成することができ、データ入力者がその入口になることができる。リスクマネージャは、例えばＲＤＳ又はアグリゲーとすることができる特別な種類のテンプレート作成者である。これらは過去のアクションをレビューして、将来のアクションに対するポリシーを決定する。
【００７９】
本発明の複合一貫コンテナ出荷の例では、定義済みカテゴリとしては、インフラストラクチャ資産、輸送資産、及び出荷品を挙げることができる。インフラストラクチャ資産は、積込み地点から積降し地点への移動を含む複合一貫コンテナの次の場所への移動に使用されるインフラストラクチャに関する。インフラストラクチャ資産の例としては、コンピュータシステム、情報処理システム、倉庫、及び港内のターミナルを挙げることができる。インフラストラクチャ資産は、物理的エンティティ又は物品に限定されず、法律的エンティティとすることができる。例えば、倉庫を所有及び／又は管理する会社はインフラストラクチャ資産として分類できる。輸送資産は出荷品の物理的な移動に直接的に使用される資産であり、出荷の一部でない資産とすることができる。例えば、出荷品を移動する具体的目的に使用される鉄道機関、コンテナ、又は他の船舶又は航空機は、輸送資産とすることができる。ある資産がインフラストラクチャ資産又は輸送資産か否かを決定することが困難であれば、その両者として取り扱うことができる。出荷品は、実際に出荷される商品、及びこれら商品の移動に使用される又は関連する特定の資産又は資料である。このカテゴリとしては、限定されるものではないが、物理的な出荷品を収容するコンテナ、防壁とすることができる又は手書き又は電子的の出荷修正を示すことができる封印、及び出荷命令や積載手形等の具体的な出荷に関する資料を挙げることができる。
【００８０】
調査、調査票、及び／又は他のメカニズムは、インフラストラクチャ資産、及びインフラストラクチャ資産に関して何らかの責任のある担当者等のインフラストラクチャ資産の他の特徴を識別するために使用できる。インフラストラクチャ資産は、下位区分、システム、又は構成要素を備えることができる。例えば、建物はインフラストラクチャ資産とすることができる。しかしながら、建物内に位置する格納施設ではあるが異なる物理的、論理的、又は法律的支配を受ける格納施設は、建物の下位構成要素として取り扱うことができるが、依然としてインフラストラクチャ資産として分類される。インフラストラクチャ資産は、以下の様々な基準に照らして施設の種類に基づいて評価されるが、これらの基準に限定されるものではない。
物理的セキュリティの制御（例えば、鍵の種類、フェンスの高さ、警備員の数など）。
人的セキュリティの制御（例えば、素性調査、雇用契約等）。
データシステムの制御（例えば、機密性、整合性、及び利用可能性など）。
履歴制御（例えば、固定資産が適切に執行されているか否かを判断する前歴）。
保険（例えば、保険の種類及び限度）。
資産に対する事前の法律的及び／又は規制的アクション（例えば、資産、判決、差止命令、評決、和解命令などに照らして開始された既存の法律的又は規制的アクション）。
契約による制御（例えば、インフラストラクチャ資産、その作業者又はプラントに関する契約条項など）。
製造元制御（例えば、その素性、評価方法など）
記録の維持及び監査の制御（例えば、記録の維持方法、制御を監査する種類など）。
手順及び慣行（例えば、タスクの達成方法）。
【００８１】
これらの基準又は構成要素又はこれらの分解要素は、リスクカテゴリとして取り扱うことができる。必要に応じて追加的なリスクカテゴリを含むことができる。評価された資産の性質は、それを評価するために使用されるリスクカテゴリ、並びにリスクカテゴリ値を計算するために使用されたデータ値の選択又は重みを決定することができる。つまり、値の小さな倉庫の物理的セキュリティのリスクカテゴリを構成する質問は、例えば値の大きなデータセンターの同じリスクカテゴリを構成する質問とは異なる場合がある。
【００８２】
資産は、ＲＤＳが使用するために複数の方法で入力することができる。これはＷｅｂシステムを用いて入力すること、又は別のアプリケーションがＲＤＳに例えば新規資産を報告することができる。１つ又はそれ以上の種類の資産を入力するために、専用ＲＤＳが存在する。次に、これらは、資産に関するデータを他のＲＤＳシステムに提供することができる。新規資産は、別のデータベースに影響する場合がある（例えば、製造元データベース）。固定資産情報は、アグリゲータ、別のＲＤＳ、インターデータストア又はイントラデータストア、又は他のソースから得ることができる。また、情報は、現地作業、調査、政府フォーム、又は他の内部又は外部のデータから取得できる。
【００８３】
資産が定義されると、適切なポリシーに基づいて評価が行われる。新規資産の導入は、新規製造元との取引やＷｅｂベースの入力等のトリガイベントであり、トリガイベントは、トリガポリシーに照らした評価を引き起こすことができる。この評価は、ポリシーの一部として複数のアクションを作成することができる。例えば、ａ）特定の調査（例えば、物理的建物の調査）が実行され、結果的に通知が適切な人々に送られて新規製造元が加入したので調査を完了する必要があることを通知する。ｂ）外部関係者の評価（例えば、サイト調査又は他の解析を行うための第３者の獲得の開始）などの内部及び外部のデータ検査が開始される（例えば、禁止された関係者リストの照合、任意の法律／規制アクションの照合、保険証券、財務状態の検証など）。詳細な情報を受け取ると、これはトリガポリシーによってポリシーに照らしてテストされる。詳細な情報を受け取ると、ポリシーは一部のケースに関して条件を満たし、資産の適格性は条件を満たしたケースで達成される。更に、資産適格性（輸送、インフラストラクチャ、又は出荷品、並びに出荷そのものの適格性）は、出荷が予約されるサプライチェーン等の他の事象の前提条件、船主からの直接的な予約ベース又は例えば船舶以外の運送の一般運送業者からの受入れベースで運送業者による出荷品の運搬、運搬の価格設定、配送時刻の約束、商品運搬又は商品の運送、処理、梱包、又は保管に使用される他の資産の保険金とすることができる。
【００８４】
ポリシーに基づく承認は、適格性と同様に短期間とすることができる。例えば、予期される制御に対して重要な障害ではない、又は予期される制御を欠くマテリアルが存在する場合、短期間の承認が提供される。例えば、建物の物理的セキュリティポリシーは変化することがある。特定の機密基準を満たす建物は、最大１か月前の物理的セキュリティポリシーに基づいて承認された鍵のみを受領することできる。１か月後には、短期間の承認は無効になるであろう。
【００８５】
ポリシーは、前述のように階層性の中で指定することができる。例えば、「Ｇｏｌｄ Ｓｅａｌ」（階層内の高レベル）は、他の方法では階層内の低レベルに対して必要な所定の出荷時調査を必要としないであろう。同様に、これは適格性についても成り立つ。理解できるように、同じアプローチは、評価時に「Ｇｏｌｄ Ｓｅａｌ」として所定の基準を満たすものを用いて資産を分類するために採用できる。船舶−輸送は、それ自体が「インフラストラクチャ資産」である会社によって所有されることができる。当然ながら、多数の例示的な資産に関して、一方向の「所有者」の関係が存在し、他方向の「所有される」関係が存在する。資産は、任意の特定の取引リスクの評価に関連のある関係をもつことができる。これらの関係は、１対１、１対多、及び／又は多対多でありリスクを評価するために使用できる。実例として、ポートは、例えば物理的セキュリティに照らして評価することができる。関係は、ポートの一部の物理的セキュリティが別のエンティティによって「管理されている」ことを示すことができる。また、「管理された」エンティティを評価して、そのリスクをポートのリスクに適切に計算することができる。
【００８６】
リスクに影響することになる関係に利用可能な関連付けを次に示す。Ｏｗｎｅｄ ｂｙ（被所有者）、Ｌｅｓｓｏｒ ｏｆ（賃貸人）、Ｌｅｓｓｅｅ ｏｆ（賃借人）、Ｃｕｓｔｏｍｅｒ ｏｆ（顧客）、Ｖｅｎｄｏｒ ｏｆ（製造元）、Ｓｕｐｐｌｉｅｒ ｏｆ（供給元）、Ｍａｎａｇｅｄ ｂｙ（被管理者）、Ｒｅｇｕｌａｔｅｄ ｂｙ（被規制者）、Ｉｎｓｕｒｅｄ ｂｙ（被保険者）、Ａｕｄｉｔｅｄ ｂｙ（被監査者）、Ｅｖａｌｕａｔｅｄ ｂｙ（被評価者）、Ｉｎｓｐｅｃｔｅｄ ｂｙ（被点検者）、Ａｕｄｉｔｅｄ ｂｙ（被監査者）、Ｏｐｅｒａｔｅｄ ｂｙ（被操作者）、Ｐｒｏｃｅｓｓｅｓ ｆｏｒ（プロセス）、Ｆｉｎａｎｃｉａｌ ｉｎｓｔｉｔｕｔｉｏｎ ｆｏｒ（金融機関）、Ｉｎｓｕｒｅｒ ｏｆ（保険者）、Ｇｕａｒａｎｔｏｒ ｏｆ（保証人）、Ｓｅｃｕｒｉｔｙ ｆｏｒ（担保）、Ｒｅｌａｔｅｄ ｔｏ（関連、関連付けの種類がシステム内で指定されていない場合）、及び以上の逆（例えば、被所有者の逆は所有者）。
【００８７】
出荷品としては、輸送される商品、そのパッケージ、商品を中に収納して輸送する複合一貫コンテナ、及び商品のコンテナ用の様々なセキュリティ、可視性、又は状態装置、及び出荷に関連するドキュメント又はメッセージを挙げることができる。出荷品は、特定の出荷、特にその中のコンテナのリスク管理の評価において評価されるものの一部である。リスク及びリスク情報リポジトリ及びアプローチの領域としては以下のものを挙げることができる。
【００８８】
インフラストラクチャ資産又は輸送資産（全てのサプライチェーン段階、対処する作業者、及びビジネスプロパティ向けの責任プログラムを含む）の全て又は一部の様々な局面（例えば、物理的、論理的、財務的など）におけるリスク状況は、出荷品の収集、製造、梱包、積込み、封印、移動などに使用することができる。
インフラストラクチャ資産、その所有権、又はリスクに影響する他の重要な「関連する」関係についての関連情報のインター又はイントラデータストアのスクリーニング。
検査、積込み、及び記録の様々な種類の手順、独立した検査機関の利用、物理的アクセス制御、論理的保護などを含む、コンテナが積み込まれて封印される条件。
他の可能性のあるパラメータの中でも、例えば、輸送期間、重さ、時間、場所、状態等及び他の関連するリスク管理ルール及び例外手順に関する、以下のコンテナについての肯定及び否定ルールセット。
【００８９】
一定の期間にすぎない。
一定の期間より短くない。
特定の測定された距離以内である。
少なくとも特定の測定された距離の範囲。
陸路か海路かに拘わらず予想された経路からの変動。
ＧＰＳ追跡による決定を含む禁止場所。
ＧＰＳ追跡による決定を含む予想場所。
原産地又は季節に基づく不適切な起点又は目的地などの付属ドキュメントの異常。
センサー又は封印のための開封又は小容積ルール。
予期しない核物質、生体物質、化学物質。
予期しない温度変化。
ＣＯ２などの予期しない気体内容物。
サプライチェーンの関係者に提供済みの出荷又はコンテナに関連するステータスメッセージの異常の解析。
出荷に関連するドキュメント（ステータスメッセージ以外）の異常の解析。
【００９０】
様々な発生履歴及び署名テンプレート、並びにレポート機能は、本発明の中で独立したサービスであることに留意されたい。つまり、システムの一部の態様が一部の承認機関又は人物によって承認されたことを知ることは有用であろう。一例として、製造元はポリシーに照らして所定の機関によって承認される場合がある。この承認はＲＤＳの中に組み込むことができる。承認インシデンスは、署名されるか又はその中に配置された他のセキュリティ制御をもつことができる。会社は、規制機関が資金を供給する手段として販売する承認インシデンスを購入すること、又は承認インシデンス又はその一部を第三者に販売することができる。
【００９１】
図１１に示すように、本発明の特定の例示的な説明では、その中に値をもつドキュメントが提供される。その値は１つ又はそれ以上のリスクポリシーに基づいて得ることができ、そのポリシーは、１つ又はそれ以上のリスクポリシーテンプレートに存在できる。リスク解析は、複数の採点メカニズムに基づいて実行できる。例えば、金融機関は、ドキュメント及びその値を１つの方法で採点するが、保険制度は同じドキュメント及びその値を別の方法で採点する。
【００９２】
この種の例示的な実施形態では、グローバルサプライチェーンのリスクを評価できる。例えば、サプライチェーンの倉庫は、多数の値を有する多数のドキュメントを含むことができる。これらのドキュメントは、各々のカテゴリにおけるドキュメントのリスクに基づいて分類できる。例えば、倉庫セキュリティは１つのカテゴリ、電源装置は別のカテゴリとすることができる。リスクは、値に基づいたリスクポリシーに照らして解析できる。例えば、倉庫セキュリティのドキュメントは、値「カメラの存在：はい」を含むことができる。この種の値ファクタは、倉庫セキュリティに対するポリシーのアプリケーションに実質的に影響し、その値へのリスクポリシーのアプリケーションに基づいて、セキュリティが成功したか失敗したか、又は所定の適格性に達したかどうかに実質的に影響することは明らかである。
【００９３】
このため、サプライチェーン内のこの例示的リンクは、各々のカテゴリについて、及びカテゴリ全体について採点することができる。リスク解析及び全体のリスク解析は、１つ又はそれ以上のテンプレートに従うであろう。例えば、犯罪が多い第１の国に倉庫が存在する場合、総スコア８０又はセキュリティスコア８５は受諾できない。しかしながら、犯罪が少ない第２の国に倉庫が存在する場合、総スコア７０又はセキュリティスコア７５は受諾可能と思われる。
【００９４】
追加的に、又は別の方法として、他のフローは本発明の使用を通じて監視できる。例えば、取引フローは、独立した取引部分又は取引全体によって採点できる。採点としては、購入発注、請求、又はコンテナ格納などを挙げることができる。同様に、採点は、例えば、手動、電子的、又は両者を組み合わせた任意のビジネスプロセスに導くことができ、採点は、任意のドキュメント又はフローの全て又は選択された部分について行なうことができる。レポート機能は、本発明の適用の任意の部分又は全体で利用可能である。レポート機能は、例えば電子的又は書面とすることができる。
【００９５】
当業者であれば、本明細書に記載された教示内容及び本明細書で参照され本開示に組み込まれた参考資料に基づいて、簡単に利用可能なハードウェア及びソフトウェア技術を用いて本発明を実施することができる。更に、ＸＭＬを含む任意の多様な計算態様、言語、又はスクリプトは、本発明に組み込むことができる。
【００９６】
本当業者であれば、本発明の精神又は範囲を逸脱することなく本発明の多数の修正例及び変更例を実施できることを理解できるであろう。従って、本発明は、発明の修正例及び変更例を、特許請求の範囲及びその均等物の範囲にある限りカバーすることを意図している。
【図面の簡単な説明】
【００９７】
【図１】ドキュメント、リスクカテゴリ、及びポリシーの間のマッピングを示す図である。
【図２】複数のドキュメントインスタンスに対する複数のリスクポリシーを示す図である。
【図３】ドキュメント、ポリシー、及び適格性の関係を示す図である。
【図４】ドキュメントインスタンスによってデータベースから値を取得してフィールド（値）に組み込むことを示す図である。
【図５】ＲＤＳの構成要素を示す図である。
【図６】テンプレートの安全な送信を示す図である。
【図７】様々な組織からのポリシーの性能を示す図である。
【図８】インスタンス又はテンプレートのＲＤＳからの安全な送信を示す図である。
【図９】トラストマネージャに関するユーザアクセスを示す図である。
【図１０】図４の方法を用いて複数のドキュメントを１つのドキュメントに結合することを示す図である。
【特許請求の範囲】
【請求項１】
少なくとも１つのビジネスプロセスに関連するリスクを監視する方法であって、
複数のドキュメントインスタンスの中の少なくとも１つを評価する段階であって、前記ドキュメントインスタンスの各々は、それに関連して、複数のリスクカテゴリに対して複数のドキュメント値を含むようになっている段階と、
前記少なくとも１つのビジネスプロセスに承認された少なくとも１つの受諾可能なリスクポリシーに従って、前記リスクカテゴリの複数を実行する段階と、
少なくとも１つのリスクカテゴリの中の前記少なくとも１つのドキュメントの承認レートに従って、複数の前記ドキュメントの中の少なくとも１つに適格性を付与する段階と、
を含むことを特徴とする方法。
【請求項２】
前記リスクが、インフラストラクチャに関連することを特徴とする請求項１に記載の方法。
【請求項３】
前記評価段階が、少なくとも１つの受諾可能なリスクポリシーの中で指定されたグループの少なくとも１つのメンバによる所要の調停段階を含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記実行段階が、前記少なくとも１つのメンバへの少なくとも１つの通知を含むことを特徴とする請求項３に記載の方法。
【請求項５】
前記適格性付与段階が、前記少なくとも１つのドキュメントを前記ビジネスプロセスに入ることを許可することを特徴とする請求項１に記載の方法。
【請求項６】
前記ドキュメントが、調査を含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記ドキュメントが、第２の複数のドキュメントのスーパーセットを備えることを特徴とする請求項１に記載の方法。
【請求項８】
前記リスクポリシーが、階層的であってもよいことを特徴とする請求項１に記載の方法。
【請求項９】
前記適格性が、階層的であってもよいことを特徴とする請求項１に記載の方法。
【請求項１０】
前記ドキュメントが、前記ビジネスプロセス内の少なくとも１つの資産を記述することを特徴とする請求項１に記載の方法。
【請求項１１】
前記評価段階が、物理的セキュリティの制御、人的セキュリティの制御、データシステムの制御、履歴制御、保険、資産に対するアクション、契約による制御、製造元の制御、記録維持、及び監査制御からなる少なくとも１つのグループについての評価段階を含むことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記監査制御が認可を含むことを特徴とする請求項１１に記載の方法。
【請求項１３】
前記監査制御が拒否を含むことを特徴とする請求項１１に記載の方法。
【請求項１４】
前記監査制御が物理的監督を含むことを特徴とする請求項１１に記載の方法。
【請求項１５】
前記適格性認定が、前記ビジネスプロセス内の前記少なくとも１つのドキュメントの使用を不許可にすることを特徴とする請求項１に記載の方法。
【請求項１６】
少なくとも１つのビジネスプロセスに関連するリスクを監視する方法であって、
複数のドキュメントインスタンスの中の少なくとも１つを評価する段階であって、前記ドキュメントインスタンスの各々は、それに関連して、複数のリスクカテゴリに対して複数のドキュメント値を含むようになっている段階と、
前記少なくとも１つのビジネスプロセスに承認された少なくとも１つの受諾可能なリスクポリシーに従って、前記リスクカテゴリの複数を実行する段階と、
少なくとも１つのリスクカテゴリの中の前記少なくとも１つのドキュメントの否認レートに従って、複数の前記ドキュメントの中の少なくとも１つに適格性を付与しない段階と、
を含むことを特徴とする方法。
【請求項１７】
前記リスクが、インフラストラクチャに関連することを特徴とする請求項１６に記載の方法。
【請求項１８】
前記評価段階が、少なくとも１つの受諾可能なリスクポリシーの中で指定されたグループの少なくとも１つのメンバによる所要の調停段階を含むことを特徴とする請求項１６に記載の方法。
【請求項１９】
前記適格性付与段階が、前記少なくとも１つのドキュメントを前記ビジネスプロセスに入ることを許可することを特徴とする請求項１６に記載の方法。
【請求項２０】
前記リスクポリシーが、階層的であってもよいことを特徴とする請求項１６に記載の方法。
【請求項２１】
前記適格性が、階層的であってもよいことを特徴とする請求項１６に記載の方法。
【請求項１】
少なくとも１つのビジネスプロセスに関連するリスクを監視する方法であって、
複数のドキュメントインスタンスの中の少なくとも１つを評価する段階であって、前記ドキュメントインスタンスの各々は、それに関連して、複数のリスクカテゴリに対して複数のドキュメント値を含むようになっている段階と、
前記少なくとも１つのビジネスプロセスに承認された少なくとも１つの受諾可能なリスクポリシーに従って、前記リスクカテゴリの複数を実行する段階と、
少なくとも１つのリスクカテゴリの中の前記少なくとも１つのドキュメントの承認レートに従って、複数の前記ドキュメントの中の少なくとも１つに適格性を付与する段階と、
を含むことを特徴とする方法。
【請求項２】
前記リスクが、インフラストラクチャに関連することを特徴とする請求項１に記載の方法。
【請求項３】
前記評価段階が、少なくとも１つの受諾可能なリスクポリシーの中で指定されたグループの少なくとも１つのメンバによる所要の調停段階を含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記実行段階が、前記少なくとも１つのメンバへの少なくとも１つの通知を含むことを特徴とする請求項３に記載の方法。
【請求項５】
前記適格性付与段階が、前記少なくとも１つのドキュメントを前記ビジネスプロセスに入ることを許可することを特徴とする請求項１に記載の方法。
【請求項６】
前記ドキュメントが、調査を含むことを特徴とする請求項１に記載の方法。
【請求項７】
前記ドキュメントが、第２の複数のドキュメントのスーパーセットを備えることを特徴とする請求項１に記載の方法。
【請求項８】
前記リスクポリシーが、階層的であってもよいことを特徴とする請求項１に記載の方法。
【請求項９】
前記適格性が、階層的であってもよいことを特徴とする請求項１に記載の方法。
【請求項１０】
前記ドキュメントが、前記ビジネスプロセス内の少なくとも１つの資産を記述することを特徴とする請求項１に記載の方法。
【請求項１１】
前記評価段階が、物理的セキュリティの制御、人的セキュリティの制御、データシステムの制御、履歴制御、保険、資産に対するアクション、契約による制御、製造元の制御、記録維持、及び監査制御からなる少なくとも１つのグループについての評価段階を含むことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記監査制御が認可を含むことを特徴とする請求項１１に記載の方法。
【請求項１３】
前記監査制御が拒否を含むことを特徴とする請求項１１に記載の方法。
【請求項１４】
前記監査制御が物理的監督を含むことを特徴とする請求項１１に記載の方法。
【請求項１５】
前記適格性認定が、前記ビジネスプロセス内の前記少なくとも１つのドキュメントの使用を不許可にすることを特徴とする請求項１に記載の方法。
【請求項１６】
少なくとも１つのビジネスプロセスに関連するリスクを監視する方法であって、
複数のドキュメントインスタンスの中の少なくとも１つを評価する段階であって、前記ドキュメントインスタンスの各々は、それに関連して、複数のリスクカテゴリに対して複数のドキュメント値を含むようになっている段階と、
前記少なくとも１つのビジネスプロセスに承認された少なくとも１つの受諾可能なリスクポリシーに従って、前記リスクカテゴリの複数を実行する段階と、
少なくとも１つのリスクカテゴリの中の前記少なくとも１つのドキュメントの否認レートに従って、複数の前記ドキュメントの中の少なくとも１つに適格性を付与しない段階と、
を含むことを特徴とする方法。
【請求項１７】
前記リスクが、インフラストラクチャに関連することを特徴とする請求項１６に記載の方法。
【請求項１８】
前記評価段階が、少なくとも１つの受諾可能なリスクポリシーの中で指定されたグループの少なくとも１つのメンバによる所要の調停段階を含むことを特徴とする請求項１６に記載の方法。
【請求項１９】
前記適格性付与段階が、前記少なくとも１つのドキュメントを前記ビジネスプロセスに入ることを許可することを特徴とする請求項１６に記載の方法。
【請求項２０】
前記リスクポリシーが、階層的であってもよいことを特徴とする請求項１６に記載の方法。
【請求項２１】
前記適格性が、階層的であってもよいことを特徴とする請求項１６に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公表番号】特表２００７−５００９１５（Ｐ２００７−５００９１５Ａ）
【公表日】平成１９年１月１８日（２００７．１．１８）
【国際特許分類】
【出願番号】特願２００６−５３３６２１（Ｐ２００６−５３３６２１）
【出願日】平成１６年６月８日（２００４．６．８）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０１８２１８
【国際公開番号】ＷＯ２００４／１１１７８７
【国際公開日】平成１６年１２月２３日（２００４．１２．２３）
【出願人】（５０５４５６４１４）グリーンライン・システムズ・インコーポレーテッド (2)
【公表日】平成１９年１月１８日（２００７．１．１８）
【国際特許分類】
【出願日】平成１６年６月８日（２００４．６．８）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０１８２１８
【国際公開番号】ＷＯ２００４／１１１７８７
【国際公開日】平成１６年１２月２３日（２００４．１２．２３）
【出願人】（５０５４５６４１４）グリーンライン・システムズ・インコーポレーテッド (2)
[ Back to top ]