JP5670295B2 - 証明書確認及び他のサービスを提供するための方法 - Google Patents

Description

（関連出願の説明）
本発明は、１９９９年９月１３日出願の米国仮特許出願第６０／１５３，７２６号「Ｔｒａｎｓａｃｔｉｏｎ Ｃｏｏｒｄｉｎａｔｏｒ ｆｏｒ Ｃｅｒｔｉｆｉｃａｔｅ Ｓｔａｔｕｓ Ｃｈｅｃｋｉｎｇ ａｎｄ Ｏｔｈｅｒ Ｓｅｒｖｉｃｅｓ」、１９９９年９月１３日出願の米国仮特許出願第６０／１５３，７２４号「Ｔｒａｎｓａｃｔｉｏｎ Ｃｏｏｒｄｉｎａｔｏｒ Ｒｅｑｕｉｒｅｍｅｎｔｓ ａｎｄ Ｈｉｇｈ Ｌｅｖｅｌ Ｄｅｓｉｇｎ」、及び１９９９年９月１０日出願の米国仮特許出願第６０／１５３，２０３号「Ｓｙｓｔｅｍ ａｎｄ Ｐｒｏｃｅｓｓ ｆｏｒ Ｃｅｒｔｉｆｉｃａｔｉｏｎ ｉｎ Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｍｍｅｒｃｅ」の優先権を主張し、これらの開示内容は、引用により本明細書に組み込まれている。

本発明は、一般的に、公開鍵インフラストラクチャーによるサービスを提供することによって、電子商取引を容易にする技術分野に関する。

電子商取引の世界では、契約当事者間の関係を証明する新しい試みがなされてきた。これらの試みは、当事者は取引に関して互いに顔を合わせたり声を聞いたりできず、又は簡単に互いの身元や取引の権限を確認できないことから行われている。
この問題に対する１つの解決策は、各々の契約当事者に、送信メッセージに署名するための秘密鍵を与えることである。署名した当事者は、当事者の秘密鍵を署名したメッセージを復号化する関連の公開鍵を利用できるようにするので、受け取った当事者は、送信者の身元を確認できる。

しかし、送信者の公開鍵は、受信者には先験的に分からない場合がある。この場合、送信者は証明機関から発行されるデジタル証明書を署名付きメッセージと一緒に送信できる。証明書は、それ自身、特定の公開鍵が送信者の公開鍵であることを証明する、署名付き電子文書（証明機関の秘密鍵を署名した）である。
時として、受信者は、認証機関の公開鍵に慣れていない場合があり、又は受信者は、証明書が依然として有効か否かが分からない場合がある。この場合、受信者は、信任をおこなうエンティティを用いて証明書の信憑性と有効性を調べようとする。公知の１つのプロトコルとして、証明書のステータスを調べるためのオンライン証明書ステータスプロトコル（ＯＣＳＰ）がある。

本発明は、証明書の検証及び保証を含む証明書関連サービス及び他のサービスを安全に提供することによって、電子商取引を容易にするシステム及び方法を開示する。好適な実施形態において、このサービスは、４コーナー信用モデルのコンテキスト内で提供される。４コーナーモデルは、オンライン取引に従事する、署名取引先(subscribing customer)と呼ばれる買い手と、信用取引先(relying customer)と呼ばれる売り手とを含んでいる。買い手は、発行関係先(issuing participant)と呼ばれる第１の金融機関の取引先である。発行関係先は、買い手の証明機関としての機能を果たし、買い手に秘密鍵及び発行関係先が署名したデジタル証明書を含むハードウェア・トークンを発行する。売り手は、信用関係先(relying participant)と呼ばれる第２の金融機関の取引先である。信用関係先は、売り手に対する証明機関としての機能を果たし、買い手に秘密鍵及び信用関係先が署名したデジタル証明書を含むハードウェア・トークンを発行する。

取引時に、買い手は、取引データ・ハッシュを生成し、ハッシュに署名し、売り手に取引データ、署名、及びそのデジタル証明書を送る。次に、売り手は、金融機関、信用関係先との通信によりシステムサービスを要求できる。

好適な実施形態において、本システムサービスは、証明書ステータス照合サービス及び保証サービスを含むことができる。証明書ステータス照合サービスにより、信用関係先は、署名取引先の証明書を検証できる。保証サービスにより、信用取引先は、署名取引先の証明書が有効であるという担保裏書保証を受け取る。これらのサービスを提供する詳細なメッセージフローは以下の詳細な説明に示されている。

好適な実施形態において、各々の関係先及びルート・エンティティ(root entity)は、サービス及び業務を、原子性、一貫性、独立性、及び耐久性の特性をもつ単一の取引と組み合わせるための取引コーディネーター（トランザクション・コーディネータ）に提供される。取引コーディネーターは、他のサービスに関連するメッセージ及びリクエストと同時に、証明書ステータスメッセージ及びリクエストに関する、単一の一貫性のあるインターフェイスを提供する。結果として、本発明は、必要な柔軟性を提供し、検査及び否認防止目的のための複数の提示サービスに関連する取引情報の集中的且つ一貫性のある取得を可能にする。更に、本発明は、付加的サービスの統合化と、それらのサービスを取引先に提供することを容易にする。

本発明の取引コーディネーターは、単一のインターフェイスを備え、銀行間又は他の金融機関間の、又は、銀行又は金融機関と取引先との間の電子商取引を容易にするようになっている。また、取引コーディネーターは、取引先に対する単一の入口点を提供して証明書照合サービスを得るようになっており、更に柔軟性を提供して、単一の入口点を提供しながら保証サービス、支払いサービス、又は証明付きメールサービス等の新規なビジネス用途を付加するようになっている。生成された付加的サービスをサポートするために、容易に拡張できるよう設計されることが好ましい。

本発明の取引コーディネーターは、現行のメッセージインフラストラクチャに対する解析、フロー制御、エラー処理を提供し、適切なシステムサービスに対するメッセージコンポーネントの手順を指示するためのメッセージスイッチとしての機能を果たす（例えば、ＯＣＳＰ応答システム、保証エンジン等）。更に、取引コーディネーターは、これらのサービスからの応答を統合された応答に順序正しくまとめ、応答を要求クライアントに送る。

また、本発明の取引コーディネーターは、証明書照合サービス又は他のサービスに関する請求書発行データを集中的な一般方式で記録する。全ての銀行及び他の金融機関には、請求書発行に対する要求があるので、請求書発行データは、書き込み単純抽出機能よって、個々の金融機関のニーズに合わせて抽出及び修正できるようになっている。

また、本発明の取引コーディネーターでは、銀行又は他の金融機関は、必要に応じて異なる形式の取引に対して互いに相互課金を行うことができる。更に、本発明の取引コーディネーターでは、市販規格品のソフトウエア・アプリケーションを組み込むことができ、電子的に署名して文書を証明するための単一の電子署名サービスを提供できる。

更に、本発明の取引コーディネーターは、全ての主要サービスを分離するので、コンポーネントの再利用を容易にして、これらのサービスの保守及び機能強化を単純化する。本発明の取引コーディネーターは、それを非標準にさせてベンダー固定と実行遅れをもたらすこともある、オンライン証明書照合機能性の交換を必要としない。
本発明の前述及び他の目的、特徴、及び利点は、以下の詳細な説明及び添付図面を参照することにより理解できる。

本発明で用いる４コーナーモデルの好適な実施形態のブロック図である。 ４コーナーモデルの各々のエンティティに設けることが好ましいコンポーネントを示すブロック図である。 取引コーディネーターの好適な実施形態のブロック図である。 好適な実施形態における取引コーディネーターの特定の態様を示すブロック図／フローチャートを組み合わせたものである。 取引コーディネーターの署名コンポーネントの好適な作動を示すブロック図／フローチャートを組み合わせたものである。 証明書ステータス照合を実行する場合の取引コーディネーターが実行するステップの好適な実施形態を示すブロック図／フローチャートを組み合わせたものである。 証明書を検証するための取引フローの好適な実施形態を示すブロック図／フローチャートを組み合わせたものである。 保証サービスの１つの好適な実施形態に関する取引フローを示すブロック図／フローチャートを組み合わせたものである。 サーバー側認証の好適な実施形態のブロック図／フローチャートを組み合わせたものである。 クライアント側認証の好適な実施形態のブロック図／フローチャートを組み合わせたものである。 メッセージ認証処理を示すブロック図／フローチャートを組み合わせたものである。 取引コーディネーターのコンポーネントに関連したセキュリティ関連フローの好適な実施形態のブロック図／フローチャートを組み合わせたものである。 好適な実施形態におけるシステムエンティティの間で送受信されるメッセージのサイズ（推定）を示すブロック図／フローチャートを組み合わせたものである。 本システムのＯＣＳＰプロキシ中心の実施形態に関する取引フローを示すブロック図／フローチャートを組み合わせたものである。

本発明は、金融機関が取引先に対して電子証明書ステータス照合及び他のサービスを安全に実行することを容易にするシステムに関する。好適な実施形態において、本発明のシステムは、これらのサービスを提供するためのコーナー信用モデルを使用する。図１は、本発明で使用する４コーナー信用モデルの好適な実施形態を示す。
図１に示すように、４コーナーモデルは、第１の機関１０２と第２の機関１０４とを含んでいる。第１の機関１０２は、本システムの関係先であり、取引先にスマートカードを発行するという理由で、以下では「発行関係先」と呼ぶ。第２の機関１０４は、本システムの関係先であり、取引先は発行関係先１０２及び発行関係先１０２の取引先によってなされる表示を信用するという理由で、以下では「信用関係先」と呼ぶ。

また、図１には、第１の取引先１０６と第２の取引先１０８とが示されている。第１の取引先１０６及び第２の取引先１０８は、それぞれ発行関係先１０２及び信用関係先１０４の取引先であることが好ましい。第１の取引先１０６は、発行関係先１０２により提供されるサービスに署名するという理由で「署名取引先」と呼ぶ。第２の取引先１０８は、発行関係先１０２及び署名取引先１０６によってなされる表示を信用するという理由で、「信用取引先」と呼ぶ。

また、図１には、ルート・エンティティ１１０が示されている。ルート・エンティティ１１０は、典型的には、電子商取引及び電子通信を容易にするための運用ルールの共通セットを制定して施行する組織である。ルート・エンティティ１１０は、運用ルールに従うことに同意した複数の銀行及び／又は他の金融機関が共同保有できる。このようなルート・エンティティの例示的な１つの実施形態は、２０００年２月１１日に出願された係属中の米国特許出願第０９／５０２，４５０号「Ｍｅｔｈｏｄ ｆｏｒ Ｃｅｒｔｉｆｉｃａｔｉｏｎ−Ｒｅｌａｔｅｄ ａｎｄ Ｏｔｈｅｒ Ｓｅｒｖｉｃｅｓ」に説明されており、その開示内容は、引用により本明細書に組み込まれている。

図２は、４コーナーモデルのエンティティに設けるのが好ましいコンポーネントを示すブロック図である。図２に示すように、関係先１０２、１０４及びルート・エンティティ１１０の各々は、本システムが提供するサービスに関連する、全てのエンティティ間のメッセージを送受信するためのゲートウェイとして機能する、取引コーディネーター２０２を備えている。以下に更に詳細に説明するように、取引コーディネーター２０２は、発行関係先１０２及び信用関係先１０４のオンラインサービスに対する単一のインターフェイスと、取引コーディネーター２０２と４コーナーモデルの他のエンティティとの間の安全な電子通信を保証するのに必要な装置用安全機能とを備えている。取引コーディネーター２０２の１つの好適な実施形態を図３から図６を参照して以下に詳細に説明する。

関係先１０２、１０４及び信用関係先１０４の各々は、更にＯＣＳＰレスポンダ２０４及びハードウェア・セキュリティ・モジュール（ＨＳＭ）２０６を備えることが好ましい。ＯＣＳＰレスポンダ２０４に関する例示的な要件を以下に説明する。ＨＳＭ２０６は、図６を参照して以下に説明するように、メッセージに署名を行い、メッセージに対する署名を証明するようになっている。

更に、関係先１０２、１０４及び信用関係先１０４の各々は、請求書発行データ・データベース２０８（関係先１０２、１０４の場合は、銀行の請求書発行アプリケーション２１０に接続される）、未処理取引ログ２１２、取引先データ・データベース２１４、リスクマネージャ２１６（取引先データ・データベース２１４に接続される）、及び第２のハードウェア・セキュリティ・モジュール２１８を更に備えることが好ましく、それぞれ取引コーディネーター２０２に接続されている。

図２に示すように、信用取引先１０８は、インターネットを介して情報を送受信するようになったＷｅｂサーバー２２０を更に備えることが好ましい。信用取引先１０８は、以下に詳細に説明するように、信用関係先１０４と通信を行うための銀行インターフェイス２２２を更に備えることが好ましい。銀行インターフェイス２２２（信用関係先に設けるのが好ましい追加コンポーネントと同様に）の１つの好適な実施形態は、本出願と同時出願の係属中の米国特許出願番号０９／６５７，６０４号「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｆａｃｉｌｉｔａｔｉｎｇ Ａｃｃｅｓｓ Ｂｙ Ｓｅｌｌｅｒｓ ｔｏ Ｃｅｒｔｉｆｉｃａｔｅ−Ｒｅｌａｔｅｄ ａｎｄ Ｏｔｈｅｒ Ｓｅｒｖｉｃｅｓ」に説明されており、その開示内容は、引用により本明細書に組み込まれている。信用取引先１０８は、システムメッセージに署名及び証明を行うためのハードウェア・セキュリティ・モジュール２３０を更に備えることが好ましい。

図２に示すように、署名取引先１０６は、以下に説明するように、インターネットを見るためのＷｅｂブラウザ２２４と、デジタルメッセージを署名するためのスマートカード２２６（及び関連の読み取り装置）を備えことが好ましい。
好適な実施形態において、各々のシステムエンティティは、認証を容易にするために、身元証明書（保証証明書と呼ぶ場合もある）と、ユーティリティ証明書である２つのデジタル証明書（及び関連の秘密鍵）を備えることが好ましい。更に、好適な実施形態において、各々の取引コーディネーター２０２は、自身の身元証明書、実用証明書、及び関連の秘密鍵を備えることが好ましい。

身元秘密鍵は、電子商取引の内容に対するエンティティの契約責務の証拠としてルート・エンティティ１１０が要求する電子署名を生成するのに利用される。証明書チェーンは、この鍵を使用する操作をサポートするのに必要である。以下に説明するように、身元証明書のステータスは、認証エンティティが取得してもよい。

ユーティリティ秘密鍵は、追加的取引のセキュリティを与える電子署名を生成するのに利用される。典型的に、ユーティリティ秘密鍵は、セキュア・ソケット・レイヤー（ＳＳＬ）をサポートするために、Ｓ／ＭＩＭＥメッセージに署名するために、及び他のユーティリティ・アプリケーションのために使用される。また、認証チェーンは、ユーティリティ秘密鍵を使用する操作をサポートするために必要である。しかし、ユーティリティ証明書のステータスは、リクエスタには利用できなくてもよい。本明細書の全範囲にわたって、用語「証明書」は、特に断らない限り身元証明書を呼ぶ。

好適な実施形態において、署名取引先１０６のデジタル証明書及び関連の秘密鍵は、発行関係先１０２から署名取引先に与えられる。発行関係先１０２は、署名取引先１０６に対して、少なくとも署名取引先の身元証明書に関連する秘密鍵を含むスマートカード又は他の適切な手段を発行することが好ましい。所望であれば、スマートカードは、同様に署名取引先の身元証明書を含んでいてもよい。スマートカードに関する好適な仕様、その製造方法、及びその内容は、２０００年８月１４日に出願された係属中の米国特許仮出願第６０／２２４，９９４号「Ｓｉｇｎｉｎｇ Ｉｎｔｅｒｆａｃｅ Ｒｅｑｕｉｒｅｍｅｎｔｓ， Ｓｍａｒｔ Ｃａｒｄ Ｃｏｍｐｌｉａｎｃｅ Ｒｅｑｕｉｒｅｍｅｎｔｓ， ａｎｄ Ａｄｄｉｔｉｏｎａｌ Ｄｉｓｃｌｏｓｕｒｅ」に説明されており、その開示内容は、引用により本明細書に組み込まれている。

図３は、取引コーディネーター２０２の好適な実施形態を示すブロック図である。図３に示すように、取引コーディネーター２０２は、２つのコンポーネント、即ちＴＣリクエストマネージャ３０４と転送サービスコンポーネント３０６とを有するインターフェイス３０２を備えている。インターフェイス３０２は、複数のサービスモジュール３０８及びコア・コンポーネント３１０との間で送受信を行う。サービスモジュール３０８は、証明書ステータス照合モジュール３１２、保証モジュール３１４、支払い保証サービス３１６、及び他のサービス３１８を含むことが好ましい。コア・コンポーネント３１０は、ロギングコンポーネント３２０、請求書発行コンポーネント３２２、及び署名コンポーネント３２４を含むことが好ましい。

転送サービスコンポーネント３０６は、取引コーディネーターへの単一の入口点を備え、リクエスタ、取引コーディネーターのサービスモジュール、及びコア・コンポーネントとの間の分離レイヤーとしての機能を果たす。ＴＣリクエストマネージャ３０４は、以下に詳細に説明するように、転送サービスコンポーネント３０６からのサービスリクエストを受け取り、それを適切なサービスモジュール及び／又はコア・コンポーネントへ転送する。

証明書ステータス照合モジュール３１２の機能は、図２におけるシステム内のエンティティの証明書を検証することである。保証モジュール３１４の機能は、特定のビジネス取引に関連する電子通信に署名を行うエンティティの身元を保証することである。好適な実施形態において、保証を行う典型的には発行関係先１０２である関係先は、署名取引先の秘密鍵により生成されるデジタル署名を署名取引先１０６が履行しなかったことが判明した場合に、いくらかの又は全ての取引金額に対する金融上の責任を引き受ける。

支払い保証サービス３１６の機能は、信用取引先１０８に署名取引先１０６の金融債務の履行能力に関する即時確認を提供することによって、取引に関連するリスクを更に低減することである。更に、発行関係先１０２は、何らかの理由で署名取引先１０６が信用取引先１０８への支払いを滞納した場合に、いくらか又は全ての取引金額に対する支払い保証を発行してもよい。また、支払いサービスは、本出願と同日に出願された係属中の米国特許出願第０９／６５７，６２２号「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｐｒｏｖｉｄｉｎｇ Ｐａｙｍｅｎｔ Ｓｅｒｖｉｃｅｓ ｉｎ Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｍｍｅｒｃｅ」に説明されているようにして行ってもよく、この開示内容は、引用により本明細書に組み込まれている。

証明付きメールサービス３１８の機能は、オフライン取引をサポートするものである。オフライン取引は、即座にリクエストを提供する代わりに、受信エンティティがリクエストを処理待ち行列状態で出す場合に起こる。典型的に、受信確認通知は、リクエスタに送信される。このシナリオは、取引量が非常に多く、全てのリクエストに対してオンライン応答を行うことができない場合に実行されることが好ましい。証明付きメールサービス３１８は、信用取引先１０８と信用関係先１０４との間、信用関係先１０４と発行関係先１０２との間、及び任意のルート・エンティティ１１０間のリクエストを満たすために使用することが好ましい。

ロギングコンポーネント３２０の機能は、否認防止及びセキュリティ検査を目的として、未処理の取引ログ５８（図５参照）における全てのサービスリクエスト及びＯＣＳＰ応答を記録することである。
請求書発行コンポーネント３２２は、取引コーディネーター２０２が受け取ったメッセージ（応答及びリクエスト）に対する請求書発行履歴を生成して格納することである。このモジュール及びコンポーネントの好適な操作を以下に詳細に説明する。

図４は、ブロック図／フローチャートを組み合わせたものであり、好適な実施形態における取引コーディネーター操作を示す。図４に示すように、ステップ４００２で、取引コーディネーター２０２の転送サービスコンポーネント３０６は、他のシステムエンティティからのサービスリクエストを受け取り、リクエストマネージャ３０４にそのサービスを転送する。ステップ４００２で、リクエストマネージャ３０４は、サービスリクエスト形式が有効か否かを照合する。サービスリクエスト形式が有効である場合、メッセージ検証モジュール４０４を呼び出してリクエスタ、請求書発行データ、及びサービスリクエスト形式に関する情報を要求する。メッセージ検証モジュール４０４は、解析モジュール４０６を呼び出して未処理サービスリクエストから関連情報を抽出する。

ステップ４００６で、リクエストマネージャ３０４は、認証モジュール４０８を呼び出してリクエスタを認証する。認証モジュール４０８は以下に詳細に説明する。
ステップ４００８で、認証モジュール４０８は、取引コーディネーター２０２の署名コンポーネント３２４を呼び出して、即ちハードウェア２１８を呼び出してリクエスタを認証する。署名コンポーネント３２４の好適な構造及び操作は以下に詳細に説明する。
ステップ４０１０で、認証モジュール４０８は、証明書ステータス照合モジュール４１４を呼び出し、次にＯＣＳＰレスポンダ２０４を呼び出してリクエスタに関する証明書ステータス照合を行う。証明書ステータス照合モジュール４１４の好適な構造及び操作を以下に詳細に説明する。

ステップ４０１２で、認証モジュール４０８は、取引先認証照合モジュール４１８を呼び出し、リクエスタが認定されていることを検証してサービスリクエストを出す。取引先認証照合モジュール４１８の好適な構成及び操作を以下に詳細に説明する。
ステップ４０１４で、リクエストマネージャ３０４は、提供されたサービスに対する適切な請求書に必要な、任意の請求書発行データを請求書発行コンポーネント３２２に送り、請求書発行ログへ記録する。

ステップ４０１８で、リクエストマネージャ３０４は、サービスリクエストをサービスリクエストルータ４２６へ送る。ステップ４０２０で、サービスリクエストルータ４２６は、適切なサービスモジュール３０８を呼び出してリクエストを実行する。
ステップ４０２２で、サービスリクエストルータ４２６は、ステップ４０２０で呼び出したサービスモジュールからサービス応答を受け取る。サービスリクエストルータ４２６は、サービス応答をリクエストマネージャ３０４へ戻し、次にサービス応答を転送サービスコンポーネント３０６へ送る。転送サービスコンポーネント３０６は、サービス応答を、サービスリクエストを作るエンティティへ送る。

図５は、署名コンポーネント３２４の好適な操作を示すブロック図／フローチャートを組み合わせたものである。署名コンポーネント３２４は、スマートカード及びハードウェア・セキュリティ・モジュール等の種々の署名手段に対して単一のインターフェイスを備え、暗号化処理を用いて署名を証明することが好ましい。
図５において、ステップ５００２で、署名コンポーネント３２４は、リクエストを受け取ると、署名リクエストであるか又は検証リクエストであるかを決定する。検証リクエストの場合、署名コンポーネント３２４は、検証リクエストをハードウェア・セキュリティ・モジュール２１８へ送る（ステップ５００４）。ステップ５００８で、ハードウェア・セキュリティ・モジュール２１８は、このリクエストに応答して検証を行い、署名検証応答を署名コンポーネント３２４へ戻す。

リクエストが文書への署名である場合、署名コンポーネント３２４は、署名に関するリクエスト（これは署名を行う文書を含む必要がある）をハードウェア・セキュリティ・モジュール２１８へ送る（ステップ５００６）。ステップ５０１０で、ハードウェア・セキュリティ・モジュール２１８は、このリクエストに応答して文書に署名し、署名付き文書を署名コンポーネント３２４へ戻す。最後に、ステップ５０１２で、署名コンポーネント３２４は、署名−検証応答又は署名付き文書を、リクエストを行ったコンポーネントへ戻す。

図６は、証明書ステータス照合を実行する場合に取引コーディネーター２０２が実行するステップの好適な操作を示すブロック図／フローチャートを組み合わせたものである。ステップ６００２で、証明書照合サービスモジュール３１２は、サービスリクエストルータ４２６から未解析の証明書ステータス照合リクエストを受け取り、それをリクエストに応じて関連の取引先情報（照合すべき証明書を含む）を抽出する解析コンポーネント４０６へ送る。ステップ６００４で、証明書照合サービスモジュール３１２は、取引先データベース６０６から任意の追加サービス仕様実行情報を取得する。

ステップ６００６で、照合すべき証明書が、取引コーディネーター２０２がリクエストを受け取った関係先の取引先に属する場合、証明書照合サービスモジュール３１２は、リクエストをローカル取引先ハンドラ６０２に引き渡す。そうでなければ、証明書照合サービスモジュール３１２は、リクエストを非ローカル取引先ハンドラ６２０へ引き渡す。
ローカル取引先ハンドラ６０２がリクエストを引き渡す場合には、システムはステップ６００８を実行し、ローカル取引先ハンドラ６０２は、証明書照合リクエストを証明書照合サービスモジュール３１２へ送る。次に、証明書ステータス照合コンポーネント３１２は、関連のＯＣＳＰレスポンダ２０４（即ち、証明書ステータス照合コンポーネント３１２として同じ取引コーディネーター２０２に属する）から、照合すべき証明書に関する証明書ステータスを取得する。この場合のフローは以下のステップ６０３２に進む。

対照的に、照合すべき証明書が、リクエストを受け取った関係先の取引先に属していない場合には、ステップ６０１０で、非ローカル取引先ハンドラ６０５は、発行関係先のＩＰアドレスを調べるが、発行関係先は、静的ＤＮＳルックアップテーブル６０４におけるリクエストの対象である証明書を発行するようになっている。取引コーディネーター２０２_RPは、証明書に関するＡＩＡ拡張子を用いて、発行関係先１０２の場所を識別するようになっていることが好ましい。ステップ６０１２で、非ローカル取引先ハンドラ６１０は、対象の証明書をＯＣＳＰリクエスト定式化モジュール６０８へ送る。ステップ６０１４で、ＯＣＳＰリクエスト定式化モジュール６０８は、証明書に対するＯＣＳＰリクエストを定式化して、リクエストを署名コンポーネント３２４へ送る。ステップ６０１６で、署名コンポーネント３２４は署名付きリクエストを戻す。

ステップ６０１８で、ＯＣＳＰリクエスト定式化モジュール６０８は、署名付きリクエストを、対象の証明書を発行した発行関係先１０２へ送る。ステップ６０２０で、発行関係先１０２は、リクエストに対するＯＣＳＰ応答をＯＣＳＰリクエスト定式化モジュール６０８へ戻す。
ステップ６０２２で、ＯＣＳＰリクエスト定式化モジュール６０８は、応答を非ローカル取引先ハンドラ６１０へ送る。ステップ６０２４で、非ローカル取引先ハンドラ６１０は、未処理応答データを否認防止目的の未処理取引ログ２１２へ記録する。

ステップ６０２６で、非ローカル取引先ハンドラ６１０は、未処理応答データを関係先コンポーネント４０６へ送り、応答に応じて発行関係先１０２の証明書とその取引コーディネーター２０２_IPを抽出する。
ステップ６０２８で、非ローカル取引先ハンドラ６１０は、ステップ６０１２から６０２４を繰り返すことによって発行関係先１０２の取引コーディネーター証明書を検証すが、ステップ６０１４で生成されたＯＣＳＰリクエストを、発行関係先１０２ではなくルート・エンティティ１１０へ送る。

同様に、ステップ６０３０で、非ローカル取引先ハンドラ６１０は、ステップ６０１２から６０２４を繰り返すことによって発行関係先１０２の証明書を検証すが、ステップ６０１４で生成されたＯＣＳＰリクエストを、発行関係先１０２ではなくルート・エンティティ１１０へ送る。
ステップ６０３２で、非ローカル取引先ハンドラ６１０が受け取った、又はローカル取引先ハンドラ６０２が生成した証明書照合応答データは、応答に署名を行う署名コンポーネント３２４へ送る。ステップ６０３４で、署名付き応答は、証明書照合サービスモジュール３１２に戻され、次に証明書照合サービスモジュール３１２はこの応答をサービス要求ルータ４２６へ送る。

図７は、証明書を検証するための、システム２００内の取引フローの好適な実施形態を示すブロック図／フローチャートを組み合わせたものである。図７に示すように、ステップ７００２で、署名取引先１０６は、署名取引先１０６と信用取引先１０８との間の取引を示すデータ・ハッシュを生成し、ハッシュを署名用のスマートカード２２６へ送る。ステップ７００４で、スマートカード２２６は、データに署名を行い、署名付きデータを、署名取引先１０６及び発行関係先１０２の証明書と共に戻す。

ステップ７００６で、署名取引先１０６は、署名付きデータ及び２つの証明書を信用取引先１０８へ送る。ステップ７００８で、信用取引先１０８は、署名取引先１０６から送られてきたデータに関する署名を検証する。この検証は、受け取った証明書の有効期限の照合を含むことが好ましい。もしくは、検証は、信用関係先１０４による信用取引先１０８に対するサービスとして提供されてもよい。次に、信用取引先１０８は、署名取引先及び関係先の証明書を含むＯＳＣＰリクエストを生成し、このリクエストを署名用ハードウェア・セキュリティ・モジュール２３０へ送る。ステップ７０１０で、ハードウェア・セキュリティ・モジュール２３０は署名付きリクエストを戻す。

ステップ７０１２で、信用取引先１０８は、署名付きＯＣＳＰリクエストを自身の証明書と共に信用関係先１０４へ送る。ステップ７０１４で、信用関係先１０４の取引コーディネーター２０２_RPは、署名付きＯＣＳＰリクエストを受け取り、取引先データベースを照合して、リクエストを処理する前に、リクエストが実在の信用取引先により署名されていることを確認する。好適な実施形態において、信用関係先１０４は、異なる関係先の取引先から受け取ったリクエストを処理しない。ステップ７０１６で、取引コーディネーター２０２_RPは、未処理の取引データ（即ち、未解析リクエスト、署名、及び付随の信用取引先証明書）を未処理取引ログ２１２_RPへ格納する。ステップ７０１８で、提供されたサービスに対して適切に請求するのに必要な任意の請求書発行データは、請求書発行ログ２０８_RPへ格納される。もしくは、請求書発行データは、オフライン処理で未処理取引ログから抽出してシステム性能を高めてもよい。

ステップ７０２０で、取引コーディネーター２０２_RPは、信用取引先の証明書、信用関係先証明書、及び公開鍵を用いて、サービスリクエストに関する信用取引先の署名を検証する。信用取引先の証明書及び公開鍵は、ハードウェア・セキュリティ・モジュール２１８_RPに格納されることが好ましい。
ステップ７０２２で、取引コーディネーター２０２_RPは、信用取引先の証明書含むＯＣＳＰリクエストを発生して、それに署名を行いＯＣＳＰレスポンダ２０４へ送る。もしくは、取引コーディネーター及びＯＣＳＰレスポンダが同じ場所に配置される場合は、リクエストに関する署名を必要としないこともある。ステップ７０２４で、ＯＣＳＰレスポンダ２０４は、リクエストの署名を検証し、ローカルリポジトリーを照合して信用取引先の証明書の有効性を決定し、証明書のステータスに関連する応答を取引コーディネーター２０２_RPへ戻す。

システム操作の一部として、信用取引先１０８は、多くの場合、信用関係先１０４以外の関係先の取引先である署名取引先１０６の証明書を検証する必要があることに留意されたい。この場合、信用関係先１０４は、検証すべき証明書を発行する発行関係先ではないので、信用関係先は証明書ステータスの直接の知識をもたない。
好適な実施形態において、本システムでは、この問題を、他の関係先が発行した証明書に関するＯＣＳＰリクエストを受け取る各々の関係先が、リクエストを証明書に関する発行関係先へ送るようにさせることによって解決する。特にステップ７０２６において、信用関係先１０４は、署名取引先の発行関係先を決定する。署名取引先が別の関係先の取引先である場合、信用関係先１０４は、署名取引先の証明書に関する署名付き検証リクエストを発生し、それを自身の証明書と共に確認済み発行関係先１０２へ送る。もしくは、検証リクエストに署名するのではなく、代わりに信用関係先は、発行関係先１０２に対するクライアント側認証手段を備えることもでき、例えば、以下に説明するＯＣＳＰプロキシ中心モデルである。

署名取引先及び信用取引先の両者が同じ関係先の取引先である場合、署名取引先の証明書の検証は、前述のローカルハンドラモジュール６０２が行う。
ステップ７０２８で、発行関係先１０２は、その取引コーディネーター２０２_RPを照合して、リクエストを行うことが認定されているエンティティがリクエストに署名したことを確認する。ステップ７０３０で、発行関係先１０２は、受け取った未処理データ（即ち、未解析リクエスト、署名、及び付随の信用取引先証明書）を未処理取引ログ２１２_RPへ格納する。ステップ７０３２で、発行関係先１０２は、リクエストに対する関連の請求書発行データを請求書発行ログ２０８へ格納する。もしくは、請求書発行データは、オフライン処理で未処理取引ログから抽出してシステム性能を高めてもよい。

ステップ７０３４で、発行関係先１０２は、信用関係先の取引コーディネーター証明書（リクエストと共に送られた）と、ルート公開鍵（ハードウェア・セキュリティ・モジュール２１８_IPに格納できる）とを用いてリクエストに関する取引コーディネーター２０２_RPの署名を検証する。ステップ７０３６で、発行関係先の取引コーディネーター２０２_IPは、信用関係先の取引コーディネーター証明書に対する署名付きＯＣＳＰリクエストを発生し、このリクエストをルート・エンティティ１１０へ送る。

ステップ７０３８で、ルート・エンティティ１１０の取引コーディネーター２０２_Rは、リクエストを受け取り、未処理リクエストを未処理取引ログ２１２_Rへ格納する。ステップ７０４０で、取引コーディネーター２０２_Rは、リクエストに対する請求書発行データを請求書発行データログ２０８_Rへ格納する。ステップ７０４２で、取引コーディネーター２０２_Rは、リクエストの署名を検証し、次に、そのリクエストをＯＣＳＰレスポンダ２０４_Rへ送る。ステップ７０４４で、ＯＣＳＰレスポンダ２０４_Rは、ローカルリポジトリーを照合して、対象の証明書のステータスを決定し、関連のステータスを取引コーディネーター２０２_Rへ戻す。ステップ７０５６で、取引コーディネーター２０２_Rは、信頼関係先の取引コーディネーター証明書のステータスを示す、署名付き応答を取引コーディネーター２０２_IPへ送る。

ステップ７０４８で、発行関係先１０２の取引コーディネーター２０２_IPは、ルート・エンティティ１１０からのＯＣＳＰ応答を否認防止目的のための未処理取引ログ２１２_IPへ格納する。ステップ７０５０で、取引コーディネーター２０２_IPは、署名取引先の証明書に関するＯＣＳＰリクエストを発生し、それに署名し、自身のローカルＯＣＳＰレスポンダ２０４_IPへ自身の証明書と共に送る。もしくは、取引コーディネーター２０２_IP及びＯＣＳＰレスポンダ２０４_IPが同じ場所に配置されている場合、リクエストに関する署名を必要としない場合もある。また、２つが同じ場所に配置されている場合、取引コーディネーターは、再署名リクエスト及び応答とは対照的に単なるパススルーとして機能する。

ステップ７０５２で、ＯＣＳＰレスポンダ２０４_IPは、リクエストに関する署名を検証し、応答を発生し、それに署名し、署名付き応答を取引コーディネーター２０２_IPへ戻す。ステップ７０５４で、取引コーディネーター２０２_IPは、ＯＣＳＰレスポンダの証明書を検証し、応答に再署名し、自身の証明書と共に取引コーディネーター２０２_RPへ戻す。
ステップ７０５６で、信用関係先１０４の取引コーディネーター２０２_RPは、発行関係先１０２から受け取った未処理応答データを否認防止目的のための未処理取引ログ２１２_RPへ格納する。ステップ７０５８で、取引コーディネーター２０２_RPは、信用関係先の取引コーディネーター証明書（リクエストと共に送られた）と、ルート公開鍵（ハードウェア・セキュリティ・モジュール２１８_RPに格納できる）とを用いて、取引コーディネーター２０２_IPの応答に関する署名を検証する。ステップ７０６０で、取引コーディネーター２０２_RPは、信用関係先の取引コーディネーター証明書に対する署名付きＯＣＳＰリクエストを発生し、それをルート・エンティティ１１０へ送る。

ステップ７０６２で、ルート・エンティティ１１０の取引コーディネーター２０２_Rは、未処理リクエストデータを未処理取引ログ２１２_Rへ格納する。ステップ７０６４で、取引コーディネーター２０２_Rは、関連の請求書発行データを請求書発行ログ２０８_Rへ格納する。ステップ７０６６で、取引コーディネーター２０２_Rは、リクエストに関する署名を検証し、リクエストをＯＣＳＰレスポンダ２０４_Rへ送る。ステップ７０６８で、ＯＣＳＰレスポンダ２０４_Rは、ローカルリポジトリーを照合して 発行関係先の取引コーディネーター証明書のステータスを決定し、そのステータスに関する応答を取引コーディネーター２０２_Rへ戻す。ステップ７０７０で、取引コーディネーター２０２_Rは、対象の証明書のステータスに関する署名付き応答を取引コーディネーター２０２_RPへ送る。

ステップ７０７２で、信用関係先１０４の取引コーディネーター２０２_RPは、応答を否認防止目的のための未処理取引ログ２１２_RPへ格納する。この時点で、署名取引先の証明書の処理が完了する。
ステップ７０７４で、取引コーディネーター２０２_RPは、ここで応答即ち署名取引先の証明書の後半部を、署名付きＯＣＳＰリクエストを発生して、それをルート・エンティティ１１０へ送ることで処理する。

ステップ７０７６で、ルート・エンティティ１１０の取引コーディネーター２０２_Rは、未処理リクエストデータを未処理取引ログ２１２へ格納する。ステップ７０７８で、取引コーディネーター２０２_Rは、関連の請求書発行データを請求書発行ログ２０８へ格納する。
ステップ７０８０で、取引コーディネーター２０２_Rは、リクエストに関する署名を検証し、そのリクエストをＯＣＳＰレスポンダ２０４_Rへ送る。ステップ７０８２で、ＯＣＳＰレスポンダ２０４_Rは、ローカルリポジトリーを照合して対象の証明書のステータスを決定し、応答を取引コーディネーター２０２_Rへ戻す。ステップ７０８４で、取引コーディネーター２０２_Rは、署名付き応答を取引コーディネーター２０２_RPへ送る。

ステップ７０８６で、信用関係先１０４の取引コーディネーター２０２_RPは、ルート・エンティティ１１０からの応答を否認防止目的のための未処理取引ログ２１２_RPへ格納する。ステップ７０８８で、取引コーディネーター２０２_RPは、発行関係先１０２の取引コーディネーター２０２_RP及びそのローカルキャッシュからの応答からＯＣＳＰ応答を生成し、それに署名を行い、自身の証明書と共に信用取引先１０８へ送る。

ステップ７０９０で、信用取引先１０８は、ハードウェア・セキュリティ・モジュール２３０に格納されたルート公開鍵証明書を用いて応答を検証する。ステップ７０９４で、信用取引先１０８は、証明書が無効になっていないかを決定するために、信用関係先の取引コーディネーター証明書に対するリクエストを取引コーディネーター２０２_Rへ送る。ステップ７０９４で、取引コーディネーター２０２_RPは、リクエストに関する署名を検証し、リクエストをローカルＯＣＳＰレスポンダ２０４_RPへ送り、信用取引先の取引コーディネーター証明書が無効になっていないことを保証する。ステップ７０９６で、ローカルＯＣＳＰレスポンダ２０４_RPは、取引コーディネーター２０２_RPからのこのリクエストに応答する。

ステップ７０９８で、取引コーディネーター２０２_RPは、信用関係先の取引コーディネーター証明書に対するＯＣＳＰリクエストを、ルート・エンティティ１１０の取引コーディネーター２０２_Rへ送る。ステップ７１００で、取引コーディネーター２０２_Rは、リクエストに関する署名を検証して、信用関係先の取引コーディネーター証明書のステータスを決定する。ステップ７１０２で、取引コーディネーター２０２Ｒは、ローカルＯＣＳＰレスポンダ２０４_Rから受け取った応答を取引コーディネーター２０２_RPへ送る。

ステップ７１０４で、取引コーディネーター２０２_RPは、ルート・エンティティ１１０から受け取った応答を信用取引先１０８へ送る。ステップ７１０６で、信用取引先１０８は、確認通知を署名取引先１０６へ与える。
前述のステップ７０９２から７１０４に関連して、システム操作の一部として、信用取引先１０８は、典型的に、信用関係先の取引コーディネーター証明書のステータスを取得することを必要とする点に留意されたい。４コーナーモデル内で、発行関係先１０２及び信用関係先１０４の取引コーディネーター及びＯＣＳＰレスポンダ証明書は、ルート・エンティティ１１０により署名される。ルート・エンティティ１１０はＯＣＳＰレスポンダを操作するが、このサービスは、関係先だけが利用できる。結果的に、信用取引先１０８は、信用関係先の証明書の検証をルート・エンティティ１１０に要求できない。

好適な実施形態において、本システムは、各々の関係先１０２、１０４にルートレスポンダプロキシを操作させることでこの問題を解決する。このプロキシは、典型的には、別の同様のリソースロケータを介して、ルートに代わって取引先からのリクエストを受け入れ、認証されたセキュア・ソケット・レイヤー経路上でリクエストを送り、要求パーティへ戻す。

また、前述の４コーナーモデルは、取引に署名した特定のエンティティ（例えば署名取引先）の身元を保証する保証サービスを提供するのに用いてもよい。このような保証サービスを提供する１つの実施形態は以下に説明される。保証サービスを提供する別の実施形態は、２０００年８月１４日に出願された係属中の米国特許仮出願第６０／２２４，９９４号「Ｓｉｇｎｉｎｇ Ｉｎｔｅｒｆａｃｅ Ｒｅｑｕｉｒｅｍｅｎｔｓ， Ｓｍａｒｔ Ｃａｒｄ Ｃｏｍｐｌｉａｎｃｅ Ｒｅｑｕｉｒｅｍｅｎｔｓ， ａｎｄ Ａｄｄｉｔｉｏｎａｌ Ｄｉｓｃｌｏｓｕｒｅ」に説明されており、その開示内容は、引用により本明細書に組み込まれている。

図８は、保証サービスの１つの好適な実施形態の取引フローチャートである。図８に示すように、ステップ８００２で、署名取引先１０６は、署名取引先１０６と信用取引先１０８との間のデータ・ハッシュを生成し、このハッシュを署名用のスマートカード２２６へ送る。ステップ８００４で、スマートカード２２６は、データに署名し、署名を信用関係先の証明書及び信用関係先の証明書と共に戻す。随意的に、このメッセージは、カード及び署名セキュリティデータ（ＣＳＳＤ）を含んでもよく、重複メッセージに対する保護といった追加的なセキュリティを与えるようになっている。

ステップ８００６で、署名取引先１０６は、署名付きデータ、署名、署名取引先の証明書、及び発行関係先の証明書（随意的にＣＳＳＤ）を信用取引先１０８へ送る。ステップ８００８で、信用取引先１０８は、署名取引先１０６が送付したデータに関する署名を検証する。もしくは、検証は、信用関係先１０４による信用取引先１０８へのサービスとして提供してもよい。次に、信用取引先１０８は、保証リクエストを生成し、リクエストを署名用のハードウェア・セキュリティ・モジュール２３０へ送る。ステップ８０１０で、ハードウェア・セキュリティ・モジュール２３０は、署名付きリクエストを信用取引先の証明書のコピーと共に戻す。

ステップ８０１２で、信用取引先１０８は、署名付き保証リクエスト及び信用取引先証明書を信用関係先１０４へ送る。
ステップ８０１４で、信用関係先１０４の取引コーディネーター２０２_RPは、取引先データ・データベース２１４_RPを照合して、リクエストを処理する前に、実在の取引先がリクエストに署名したことを確認する。ステップ８０１６で、取引コーディネーター２０２_RPは、取引に関する（即ち「未解析」リクエスト、署名、及び付随の証明書）未処理取引データを未処理取引ログ２１２_RPへ格納する。ステップ８０１８で、取引コーディネーター２０２_RPは、関連の請求書発行データを請求書発行ログ２０８_RPへ格納する。もしくは、請求書発行データは、オフライン処理で未処理取引ログから抽出してシステム性能を高めてもよい。

ステップ８０２０で、取引コーディネーター２０２_RPは、信用取引先証明書（リクエストと共に送られた）、信用関係先証明書、及びルート公開鍵（両者ともハードウェア・セキュリティ・モジュール２１８_RPに格納できる）を用いて、リクエストに関する関連取引先の署名を検証する。次に、取引コーディネーター２０２_RPは、信用取引先証明書を含むＯＣＳＰリクエストを発生し、それに署名してローカルＯＣＳＰレスポンダ２０４_RPへ送る。もしくは、取引コーディネーター又はＯＣＳＰレスポンダが同じ場所に配置されている場合は、リクエストに関する署名を必要ない場合もある。

ステップ８０２２で、ＯＣＳＰレスポンダ２０４_RPは、リクエスに対する署名を検証し、信用取引先証明書のステータスに関するローカルリポジトリーを照合し、ステータスに関する応答を取引コーディネーター２０２_RPへ戻す。
ステップ８０２４で、取引コーディネーター２０２_RPは、リスクマネージャ２１６_RPを呼び出し、信用取引先１０８が保証リクエストを行うことが金融上認可されているか否かを決定する。認可されていれば、次に、ステップ８０２６で、取引コーディネーター２０２_RPは、署名取引先１０６に対する保証リクエストに応じることについての関係先の責任を決定する。本実施例において、このエンティティは、発行関係先１０２である。次に、取引コーディネーター２０２_RPは、署名取引先１０６に対する保証リクエストを生成し、それに署名し、自身の証明書と共に発行関係先１０２へ送る。署名取引先及び信用取引先の両者が同じ関係先の取引先である場合には、代わりに保証リクエストを関係先でローカル処理してもよい点に留意されたい。

ステップ８０２８で、取引コーディネーター２０２_IPは、取引先データ・データベース２１４_IPを照合して リクエストが、リクエストを行うことを認可されたエンティティにより署名されていることを確認する。ステップ８０３０で、取引コーディネーター２０２_IPは、未処理取引データ（即ち「未解析」リクエスト、署名、及び付随の証明書）を未処理取引ログ２１２へ格納する。ステップ８０３２で、取引コーディネーター２０２_IPは、リクエストに対する関連の請求書発行データを請求書発行ログ２０８_IPへ格納する。もしくは、請求書発行データは、オフライン処理で未処理取引ログから抽出してシステム性能を高めてもよい。ステップ８０３４で、取引コーディネーター２０２_IPは、取引コーディネーター２０２_RPの証明書（リクエストと共に送られた）、及びルート公開鍵（ハードウェア・セキュリティ・モジュール２１８_IPに格納できる）を用いて、リクエストに関する取引コーディネーター２０２_RPの証明書を検証する。次に、取引コーディネーター２０２_IPは、信用関係先取引コーディネーター２０２証明書に対するＯＣＳＰリクエストを発生し、それに署名してルート・エンティティ１１０へ送る。

ステップ８０３６で、ルート・エンティティ１１０の取引コーディネーター２０２Ｒは、未処理リクエストを未処理取引ログ２１２_Rへ格納する。ステップ８０３８で、取引コーディネーター２０２_Rは、リクエストに対する関連の請求書発行データを請求書発行ログ２０８_Rへ格納する。ステップ８０４０で、取引コーディネーター２０２_Rは、リクエストに関する署名を検証し、次にリクエストをＯＣＳＰレスポンダ２０４_Rへ送る。ＯＣＳＰレスポンダ２０４_Rは、ローカルリポジトリーを照合して信用関係先取引コーディネーター証明書のステータスを決定し、そのステータスに関連する応答を取引コーディネーター２０２_Rへ戻す。次に、取引コーディネーター２０２_Rは、署名付き応答を取引コーディネーター２０２_IPへ戻す。

ステップ８０４２で、発行関係先１０２の取引コーディネーター２０２_IPは、未処理応答を否認防止目的のための未処理取引ログ２１２_IPへ格納する。ステップ８０４４で、次に、取引コーディネーター２０２_IPは、受け取ったリクエストから署名取引先証明書を含むＯＣＳＰリクエストを発生し、それに署名し、自身の証明書と共にローカルＯＣＳＰレスポンダ２０４_IPへ送る。もしくは、取引コーディネーター及びＯＣＳＰレスポンダが同じ場所に配置されている場合には、リクエストに関する署名を必要としない場合もある。また、２つが同じ場所に配置されている場合には、取引コーディネーターは、再署名リクエスト及び応答とは対照的に単なるパススルーとして機能する。

ステップ８０４６で、ＯＣＳＰレスポンダ２０４_IPは、リクエストに関する署名を検証し、応答を発生し、それに署名し、署名付き応答を取引コーディネーター２０２_IPへ戻す。ステップ８０４８で、取引コーディネーター２０２_IPは、リスクマネージャ２１６_IPを呼び出し、署名取引先１０６に対する保証書を発行するか否かを決定する。ステップ８０５０で、リスクマネージャ２１６_IPは、保証書を発行する必要があるか否かを示す署名付きメッセージを取引コーディネーター２０２_IPへ戻す。ステップ８０５２で、取引コーディネーター２０２_IPは、署名付き応答を未処理取引ログ２１２_IPへ格納する。

ステップ８０５４で、取引コーディネーター２０２_IPは、署名付き応答をルート・エンティティ１１０の取引コーディネーター２０２_RPへ送り、発行関係先１０２が保証書を発行するに十分な担保を保有しているか否かを決定する。ステップ８０５６で、取引コーディネーター２０２_Rは、リスクマネージャ２１６_Rと相互作用して、発行関係先１０２が適切に担保によって保証されているか否かを決定し、保証されている場合、発行関係先１０２の担保レベルを発行された保証書にふさわしい大きさだけ低減し、応答を発行関係先１０２へ戻す。

ステップ８０５８で、取引コーディネーター２０２_IPは、取引コーディネーター２０２_Rの署名を検証し、保証応答を生成し、自身の証明書と共に取引コーディネーター２０２_RPへ戻す。
ステップ８０６０で、信用関係先１０４の取引コーディネーター２０２_RPは、未処理応答を否認防止目的のための未処理取引ログ２１２へ格納する。ステップ８０６２で、取引コーディネーター２０２_RPは、取引コーディネーター２０２_IPの証明書（リクエストと共に送られた）、及びルート公開鍵（ハードウェア・セキュリティ・モジュール２１８_RPに格納できる）を用いて、応答に関する取引コーディネーター２０２ＩＰの署名を検証する。次に、取引コーディネーター２０２_RPは、発行関係先の取引コーディネーター証明書に対する署名付きＯＣＳＰリクエストを生成し、それをルート・エンティティ１１０へ送る。

ステップ８０６４で、ルート・エンティティ１１０の取引コーディネーター２０２_Rは、未処理リクエストを未処理取引ログ２１２_Rへ格納する。ステップ８０６６で、取引コーディネーター２０２_Rは、関連の請求書発行データを請求書発行ログ２０８_Rへ格納する。ステップ８０６８で、取引コーディネーター２０２_Rは、リクエストに関する署名を検証する。次に、取引コーディネーター２０２_Rは、リクエストをＯＣＳＰレスポンダ２０４_Rへ格納する。ＯＣＳＰレスポンダ２０４_Rは、そのローカルリポジトリーを照合して対象の証明書のステータスを決定し、応答を取引コーディネーター２０２_Rへ戻す。次に、取引コーディネーター２０２_Rは、署名付き応答を取引コーディネーター２０２_RPへ送る。

ステップ８０７０で、信用関係先１０４の取引コーディネーター２０２_RPは、未処理応答を否認防止目的のための未処理取引ログ２１２_RPへ格納する。ステップ８０７２で、取引コーディネーター２０２_RPは、ルート・エンティティ１１０の取引コーディネーター２０２_Rを調べて発行関係先が保証書を発行するだけの十分な担保を保有しているか否かを確認する。

ステップ８０７４で、取引コーディネーター２０２_Rは、未処理リクエストを未処理取引ログ２１２_Rへ格納する。ステップ８０７６で、取引コーディネーター２０２_Rは、関連の請求書発行データを請求書発行ログ２０８_Rへ格納する。ステップ８０７８で、取引コーディネーター２０２_Rは、発行関係先１０２が保証書を発行するだけの十分な担保を保有しているか否かに関連する、「イエス」又は「ノー」応答を、信用関係先１０４の取引コーディネーター２０２_RPへ送る。

ステップ８０８０で、取引コーディネーター２０２_RPは、未処理リクエストを否認防止目的のための未処理取引ログ２１２_RPへ格納する。ステップ８０８２で、取引コーディネーター２０２_RPは、取引コーディネーター２０２_IPから受け取ったリクエストから保証リクエストを生成し、それに署名し、取引コーディネーター２０２_RPの証明書と共に信用取引先１０８へ送る。

ステップ８０８４で、信用取引先１０８は、ハードウェア・セキュリティ・モジュール２３０に格納されたルート公開鍵を用いて応答を検証する。ステップ８０８６で、信用取引先１０８は、無効になっているか否かを調べるために、取引コーディネーター２０２_RPの証明書に対するリクエストを取引コーディネーター２０２_RPへ送る。
ステップ８０８８で、取引コーディネーター２０２_RPは、リクエストに関する署名を検証し、応答をＯＣＳＰレスポンダ２０４_RPに送り、信用取引先１０８の取引コーディネーター証明書が無効になっていないことを保証する。ステップ８０９０で、ローカルＯＣＳＰレスポンダ２０４_RPは、その証明書に対するＯＣＳＰリクエストを取引コーディネーター２０２_Rへ送る。

ステップ８０９４で、取引コーディネーター２０２_Rは、リクエストに関する署名を検証し、ローカルＯＣＳＰレスポンダ２０４_Rを調べて取引コーディネーター２０２_RPの証明書のステータスを決定する。次に、取引コーディネーター２０２_Rは、ローカルＯＣＳＰレスポンダ２０４_Rから受け取った応答を取引コーディネーター２０２_RPへ送る。
ステップ８０９６で、取引コーディネーター２０２_RPは、取引コーディネーター２０２_Rから受け取った応答を信用取引先１０８へ送る。ステップ８０９８で、信用取引先１０８は、確認通知を署名取引先１０６へ送る。

好適な実施形態において、各々の取引コーディネーター２０２は、取引に、取引コーディネーターによって調整された原子性、一貫性、独立性、及び耐久性を もたらす。原子性は、取引を終了するのに必要な全てのアクションが成功するか又は全て失敗すること、即ち取引は分割できない作業単位であることを意味する。一貫性は、取引の実行後に、システムは、正しい状態を保つ、安定状態にある、又は取引の開始を行う状態に戻ることを意味する。独立性は、各々の取引が、同時に実行できる他の取引に影響されないことを意味する。耐久性は、各々の取引の効果が、取引が委ねられた後に不変であることを意味する。原子性、一貫性、独立性、及び耐久性の組み合わせは、ＡＣＩＤ特性と呼ぶ場合もある。

取引コーディネーター２０２は、取引処理手続きモニタ又はコンポーネント取引モニタを組み込むことによって、分散コンピューティング環境においてＡＣＩＤ特性を備えることが好ましい。好適な取引処理手続きモニタは、ＢＥＲ Ｓｙｓｔｅｍ社のＢＥＲ ＴＵＸＥＤＯ、マイクロソフト社のＭＳＭＱ、ＮＣＲ社のＴｏｐ Ｅｎｄ、及びＩＢＭ ＴｒａｎｓａｒｃのＥｎｃｉｎａを含むことができる。好適なコンポーネント取引モニタは、Ｉｏｎａ Ｔｅｃｈｎｏｌｏｇｉｅｓ社のＯｒｂｉｘ ＯＴＭ、ＢＥＲ Ｓｙｓｔｅｍ社のＢＥＡ ＷｅｂＬｏｇｉｃＢＥＲを含むことができる。

取引コーディネーターが調整する取引ステップの任意の組み合わせは、ＡＣＩＤ特性を有する取引を形作るよう組み合わせることができる。１つ又はそれ以上の予め定義された取引は、図５から図７に示す各々の工程に対して与えられる。つまり、例えば、図５に示すリクエストと応答との間に生じるステップは、ＡＣＩＤ特性を有する取引を形作るよう組み合わせることができる。

好適な実施形態において、取引コーディネーターコンポーネントは、取引処理ライブラリを介して取引処理手続きモニタと相互作用する。実行される取引処理手続きモニタを別の取引処理手続きモニタと置換できる、柔軟なアーキテクチャの実現を容易にするために、ライブラリは、特定ブランドの取引処理手続きモニタを使用していたとしても、取引処理手続きモニタ機能性にアクセスするよう書き込まれていてもよい。

前述の各々の取引処理手続きモニタには、本システムの取引コーディネーターの会社に対する適合性に関連する特定の機能がある。例えば、ＴＵＸＥＤＯ取引処理手続きモニタは、以下のように設計されている。
（１）高性能なメッセージ受け渡しエンジン。
（２）クライアント及びサーバーが分散取引に参加して、アプリケーションに意識させないで２元コミットプロセスを管理することを可能にする、分散取引管理。
（３）ハードウェア・ホスティング・プログラムに無関係に、開発者がＢＥＡ ＴＵＸＥＤＯアプリケーションを書き込むことを可能にする、取引マネージャインターフェイス用アプリケーション。
（４）自動的にアプリケーションの並列コピーを生成して管理し、それらを平等に利用することを保証する、動的作業負荷平衡化。
（５）分散アプリケーションが非同期、非結合様式で同時に作動するのを可能にし、メッセージのコンテキスト、内容、及び日時に基づいてキューに優先順位をつける、取引キューイング。
（６）最もデータを有効に利用できる場所で取引を処理することを可能にするデータ依存ルーチン。
（７）サーバーマネージャが異常処理を再起動して、進行中であった取引をロールバックする、アプリケーション異常、取引異常、ネットワーク異常、及びノード異常からの自動回復。

マイクロソフト社のＭＳＭＱ取引処理手続きモニタは、以下のように設計されている。
（１）完全なＣＯＭコンポーネントのサポート。
（２）様々なプログラム言語（例えば、Ｖｉｓｕａｌ Ｃ＋＋、Ｖｉｓｕａｌ Ｊ＋＋）からのアクセス。
（３）進化したメッセージキューイング利点をもたらす、５つ（オープン、クローズ、送信、受信、位置指定）のＡＰＩ。
（４）スライド・ウインドウ・プロトコル、回復可能ストレージ、メッセージ配信のための動的経路指定、定期的で順序正しいメッセージ配信。
（５）データベース更新等の他の作動を有する取引内に含むことができる能力。
（６）他のリソースに関する操作を委ねる又は中止して、取引中のデータ保全性を維持する能力。
（７）組み込みメッセージ暗号化、保全性、及び署名サポート。
（８）何れのＭＳＭＱイベントが、ＷｉｎｄｏｗｓＮＴ（登録商標）セキュリティログの検査記録を生成する必要があるかの指示能力をもつ管理者。

典型的に、ＭＳＭＱは、ＭＳ ＷｉｎｄｏｗｓＮＴ（登録商標） Ｓｅｒｖｅｒ、Ｓｔａｎｄａｒｄ Ｅｄｉｔｉｏｎ４．０及びＭＳ ＷｉｎｄｏｗｓＮＴ（登録商標） Ｓｅｒｖｅｒ、Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ４．０の機能を含む。２４クライアント以上のサポート、原価基準ルーチン、及びＭＳＭＱ Ｃｏｎｎｅｃｔｏｒが必要な場合は、ＭＳＭＱは、ＮＴ Ｓｅｒｖｅｒ、Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ４．０上で実行するのが好ましい。ＭＳＭＱは高性能なメッセージ受け渡しエンジンであるが、取引処理手続きモニタに必要な機能を有していないので、本システムでの使用には適していないことに留意されたい。

ＩＢＭ Ｅｃｉｎａは、Ｓｕｎ、ＩＢＭ、Ｄｉｇｉｔａｌ Ｅｑｕｉｐｍｅｎｔ Ｃｏｒｐ、Ｈｅｗｌｅｔｔ Ｐａｃｋａｒｄ、及びＷｉｎｄｏｗｓ（登録商標）を含む多数のハードウェア・プラットホームに関してＴｒａｎｓａｒｃから入手できる。ＩＢＭ Ｅｃｉｎａ取引処理手続きモニタは、以下のように設計されている。
（１）多種多様なシステムを統合する分散取引処理手続きアプリケーションを可能にする相互運用性。
（２）Ｘ／ＯｐｅｎＸＡアプリケーション・プログラム・インターフェイスを介し、メインフレームに付加的なソフトウェアを必要とすることなく、ｓｙｎｃ−ｌｅｖｅｌ０，１，２サービスを含むメインフレームＬＵ６．２同時使用を提供する、Ｏｒａｃｌｅ、Ｉｎｇｒｅｓ、Ｉｎｆｏｍｉｘ、又はＳｙｂａｓｅ等の多重ＸＡコンプライアントデータベース又はリソースマネージャの同時使用。
（３）取引処理手続きアプリケーションが必要とする性能及び信頼性。
（４）有効な完全分散型２元コミット機構。
（５）性能を高め単点故障を排除する、自動負荷平衡化及びアプリケーション複製サービス。
（６）クライアント及びサーバーの両者が、取引の関係先の身元及び権限を検証することを可能にする、基本的ＤＣＥの遺伝性セキュリティ機構。
（７）自動認証照合を含み、検査記録構造を与えるのを容易にする、追加的なセキュリティ機構。
（８）多数のユーザ及び大量のデータをサポートするための企業的拡張性。
（９）有効な管理を可能にするのを容易にする集中管理。

Ｔｏｐ Ｅｎｄ取引処理手続きモニタは以下のように設計される。
（１）堅固なミドルウェア
（２）分散取引管理
（３）クライアント／サーバー相互作用
（４）信頼性の高いファイル転送
（５）動的作業負荷平衡化
（６）回復可能取引キューイング
（７）アプリケーション並列化
（８）２元コミット処理手続き
（９）自動回復
（１０）メッセージ依存ルーチン
（１１）多重データベースサポート（ＭｉｃｒｏｓｏｆｔＳＱＬサーバー、Ｏｒａｃｌｅ、及びＳｙｂａｓｅ）
（１２）インターネット・アプリケーションの拡張性及び有用性

好適な実施形態において、本システムの各々の取引コーディネーターは、認証(authentication)、認定(authorization)、セッション・セキュリティ、メッセージ・セキュリティ、否認防止(non-repudiation)、及び検査(auditing)を含む複数のサービスを提供するようになっている。
好適な実施形態において、取引コーディネーターは、ルート・エンティティ１１０により定義されるＰＫＩに基づくＰＫＩＸ認証を利用する。本システム以外のサービスに関する他の認証機構は、取引コーディネーターを操作するエンティティにより決定されるのと同様にサポートできる。

好適な実施形態において、認証は、デジタル認証を使用することでもたらされる。認証は、セッションレベル、メッセージレベル、又は両レベルで生じる。
好適な実施形態において、セキュア・ソケット・レイヤー（ＳＳＬ）プロトコルは、セッションレベルの認証をもたらす。セキュア・ソケット・レイヤー・プロコルは２つのフェーズからなる。即ち、サービス側認証と随意的なクライアント側認証とである。所定の取引コーディネーター２０２は、取引先又は他の取引コーディネーターからのリクエストを受け取る場合にはサーバーとして、他の取引コーディネーターへリクエストを送る場合にはクライアントとしての機能を果たす。

図９は、サーバー側認証を示す。サーバー９０は、クライアント９５からのリクエストを受け取り（ステップ９００２）、そのユーティリティ証明書をクライアントへ送る（ステップ９００４）。ステップ９００６で、クライアント９５は、公開鍵を発生し、サーバーの公開鍵を用いて暗号化し、サーバー９０へ送る（ステップ９００６）。ステップ９００８で、サーバー９０は秘密鍵を用いてクライアント９５が送ってきた公開鍵を復号し、クライアントから受け取った公開鍵を用いて認証したメッセージを戻すことによって、クライアント９５に対して自身を認証する。その後のデータは、クライアント生成の公開鍵を用いて暗号化し認証する。

セキュア・ソケット・レイヤー・サーバー側認証により、クライアント９５は誰と通信しているのかを知ることができる。サーバー側認証は、ネットワーク取引が行われる全てのセッションに必要とされることが望ましい。サーバー９０を認証するために、クライアント９５は、サーバー９０のユーティリティ証明書チェーンにおけるルート証明書権限についての公開鍵証明書を所有する必要がある。

図１０は、随意的なクライアント側認証を示す。ステップ１０００２で、サーバー９０はクライアント９５へチャレンジを送る。クライアント９５は、自身の秘密鍵を用いてチャレンジに署名を行い、自身の公開鍵と一緒に署名付きチャレンジを戻すことにより、サーバー９０に対して自身を認証する（ステップ１０００４）。

セキュア・ソケット・レイヤー・クライアント側認証は、クライアント９５が有効なユーティリティ証明書と付随の秘密鍵とを所有することを保証する。好適な実施形態において、セキュア・ソケット・レイヤー・クライアント側認証は随意的であるが、発行関係先１０２及び信用関係先１０４が、クライアント９５からデジタル署名されたリクエストを要求しない場合に採用される。取引コーディネーター２０２_IP、２０２_RP、２０２_Rは、クライアント９５が有効なルート証明書を保持していることを決定するために、クライアントのユーティリティ証明書チェーンにおけるルート証明書権限についての公開鍵証明書を所有する必要がある。

好適な実施形態において、セッションレベルで、発行関係先１０２及び信用関係先１０４は、自身で取引先クライアントに対する認証を行う。また、発行関係先１０２及び信用関係先１０４は、セッションが確立された時に、取引先クライアントに取引コーディネーター２０２_IP、２０２_RP、２０２_Rに対して自身を認証するよう要求できる。つまり、クライアント９５が、通信を行っている関係先の検証済み取引先でない場合、その関係先に対する取引コーディネーターは、メッセージを処理する前にセッションを中止できる。また、関係先は、メッセージレベルの認証を要求する代わりに、セッションレベルでの取引先のクライアント側認証を要求できる。

取引コーディネーター２０２_IP、２０２_RP、２０２_Rの間の認証は、セッションレベル又はメッセージレベル又はその両方の何れかで発生してもよい。対照的に、信用取引先は、取引コーディネーター２０２ＲＰに送られる全てのリクエストにデジタル署名を行うことで、メッセージレベルの認証を提供することを要求されることが望ましい。しかし、前述のように、関係先は、信用取引先にセッションレベルでクライアント側認証を提供することを要求してもよい。

図１１は、好適な実施形態を示すブロック図／フローチャートを組み合わせたものである。以下に説明するように、この方法は、メッセージ中に含まれるデータにデジタル署名を付加することによって、取引コーディネーター２０２へ送られてきたメッセージを認証するように作動する。

ステップ１１０２で、認証モジュール４０８は、ハードウェア・セキュリティ・モジュール２１８を呼び出して、典型的にメッセージと共に送られてくる発信者の公開鍵証明書を用いて、受け取ったメッセージに関する署名を検証する。ステップ１１０４で、認証モジュール４０８は、ハードウェア・セキュリティ・モジュール２０６を呼び出して、発信者のチェーンにおけるルートの証明書を発端にして発信者の証明書チェーンを有効にすることで、発信者が有効なルート保証証明書を所有していることを確認する。発信者の公開鍵証明書といった、発信者チェーンの複数部分は、メッセージと共に送られる。ルート証明書といった、チェーンの他の部分は、既にＨＳＭ２０６及び／又は取引先データベース２１４に格納されている。

ステップ１１０６で、認証モジュール４０８は、タイムソース１１を呼び出し、最新の時間を取得し、発信者のチェーンを含む証明書がいずれも既に期限切れになっていないことを検証する。全ての関係先及びルート・エンティティ１１０は、同期タイムソースを備えることが望ましい。
ステップ１１０８で、認証モジュール４０８は、ＯＣＳＰレスポンダ２０４を呼び出し、ハードウェア・セキュリティ・モジュール２１８に格納された証明書以外の、発信者のチェーンの証明書が無効になっていないことを確認する。

メッセージ認証は、セッション認証に比べて高レベルの認証を提供する。セッション認証はユーティリティ鍵を利用する。一般的に、ＯＣＳＰ照合は、ユーティリティ鍵に関して行われないので、ＳＳＬ証明書が無効になっている場合、認証プロセス中にクライアントもサーバーも確認できない。更に、ユーティリティ鍵は、保護を受けないで格納されるので、鍵が格納されているトークンを所有する誰もが認定ユーザを装うことができる。他方で、メッセージ認証をもたらすのに使用される保証鍵は、保護されているので、単にトークンを所有していても鍵に近づいて認定ユーザを装う資格はない。

好適な実施形態において、取引先認証照合モジュール４１８（図５参照）は、サービスリクエスタがそのサービスを受けるよう認定されているかを確認する。認証を決定するために、リクエスタの身元は、セッションレベル認証又はメッセージレベル認証から決定できる。取引先認証照合モジュール４１８は、ユーザの認証済み身元、又は与えられたユーティリティからの識別名、又は保証証明書を抽出して、これを取引先データ・データベース２１４の認定ユーザリストと比較することで認証照合を実行することが好ましい。好適な実施形態において、取引先認証照合は、金融機関の証明機関の識別名に従属する識別名をもつ任意のユーザといった、識別名の一部に基づいていてもよく、又は特定のユーザのみが認定されるよう完全な識別名に基づいていてもよい。

取引先認証照合モジュール４１８は、複数のレベルで認証照合を実行できる。例えば、ユーザレベルでのサービスを許可又は否定する能力を有していてもよく、又は、ユーザが保有する担保の細かい基準に基づいて許可又は否定する能力を有していてもよい。
好適な実施形態において、取引コーディネーター２０２は、セキュア・ソケット・レイヤー（ＳＳＬ）を用いてセッション・セキュリティを提供する。典型的に、ＳＳＬは、３段階のセッション・セキュリティを提供する。即ち、機密性、データ保全性、及びセッション認証である。取引コーディネーター２０２からの、又は取引コーディネーター２０２への通信は、ＳＳＬを用いて暗号化することが好ましい。

本システムのメッセージ・セキュリティは、デジタル署名を用いて提供されることが好ましい。デジタル署名は、２段階のメッセージ・セキュリティを提供する。即ち、認証及びデータ保全性である。典型的に、デジタル署名は、保護された秘密鍵を用いて認証を行い、秘密鍵は署名メッセージに対して使用される。
前述のように、デジタル署名は、署名プロセス中に生成されるハッシュ又はメッセージ・ダイジェストを使用して、データ保全性をもたらすことが好ましい。メッセージ・ダイジェストは、署名付きデータの何れかのビットが変更されると、別の「指紋」が生じてデータの受信者が署名を検証できないようになったデータの「指紋」を与える。

好適な実施形態において、機密性は、セッションレベルにおいて、全てのルート通信に対して与えられる。取引コーディネーターは、ルート・エンティティ１１０により定義された機密性ルールに従うことが好ましい。
好適な実施形態において、各々の取引コーディネーター２０２は、ログ内の実行サービスの否認防止を保証し、これらのログの保全性を保証するのに必要な全てのデータを記録する。例えば、信用関係先１０４は、信用取引先１０８に対して実行する全てのサービスに関するそのような否認防止を提供することが好ましい。つまり、各々の実行サービスに対して、取引コーディネーター２０２ＲＰは、信用取引先１０８への応答のみならず、サービスの実行に関係するどのパーティも提供サービスを拒否できないことを保証するのに必要な全てのデータを保持する。

好適な実施形態において、デジタル署名付きメッセージは、この否認防止の基準を提供する。例えば、前述の検証サービスのコンテキストにおいて、取引コーディネーター２０２は、否認防止目的のために全ての受信データのログを保持する。取引コーディネーター２０２は、受信時にメッセージをそのとおりに記録し、解析しないこと、変更しないこと、又は受信形式とは別の形式で格納しないことが好ましい。受信メッセージの変更は、メッセージのデジタル署名を証明できなくするので、メッセージは否認防止目的には不適切なものになる。

好適な実施形態において、各々の受信メッセージには、否認防止サービスの一部としてタイムスタンプが押される。応答は、特定の時間に実行される認証照合と関連する。認証照合の時間は、応答における署名付き属性であり、未処理取引ログ２１２が取得することが好ましい。

好適な実施形態において、取引コーディネーター２０２は、検査目的のための情報も記録する。セキュリティ検査ログは、非取引先からの多数回の疑わしいリクエストや、多数回の疑わしい無効署名といった、システムに対する潜在的攻撃を検出するのに利用できる。また、セキュリティ検査ログは、鍵漏えいが発生した時に役に立つ。その理由は、記録され関連証明書が無効になる前に鍵は漏えいされ得るからである。セキュリティ検査ログは、漏えい鍵を用いて処理が発生したことを確認するのに使用できることが好ましい。

検査記録は、係争解決、否認防止、及び請求書発行の目的で保持される。好適な実施形態において、取引コーディネーターは、送受信した全てのメッセージを記録し、メッセージ全体を記録する。メッセージは、「未処理」形式で記録できる。もしくは、取引コーディネーターは、メッセージを構成部分に分解してスキーマとして格納でき、メッセージ全体は、署名を保存した様態で再構成できる。好適な実施形態において、ログはこのような特性であるので、ログ入力は、検出されることなく偽造（追加、削除、又は変更）できない。更に、取引コーディネーターが未処理形式で記録される場合、未処理データをＣＯＴＳソリューションで読み取り可能な形式に変換する能力を含むことが好ましい。これは疎結合ユーティリティであってもよく、又は取引コーディネーター機能性の一部であってもよく、別個のおそらく優先順位が低いバックグラウンド・プロセスとして実行される。また、これは完全に別個のシステムで実行されてもよい。ログは、転送及びセッションに関連する他のデータを含んでもよい。一例として、送信者／受信者のＩＰアドレス、ポストＵＲＬ、ＳＭＴＰヘッダー等を挙げることができる。

転送サービスコンポーネント３０６（図３参照）は、取引コーディネーター２０２と、通信中のエンティティとの間のセキュア・ソケット・レイヤー・セッションを確立する、安全な通信コンポーネントを備えることが好ましい。好適な実施形態において、安全な通信コンポーネントは、前述のようなセッション認証を行う。つまり、取引コーディネーター２０２がサーバー９０としての機能を果たす場合、安全な通信コンポーネントは、サーバー側のセッション認証をもたらし、クライアント側のセッション認証を要求できる。対照的に、取引コーディネーター２０２がクライアント９５としての機能を果たす場合、安全な通信コンポーネントは、サーバー９０の認証に対する責任を負う。

クライアントとして、取引コーディネーター２０２は、セッション鍵を発生してその鍵を通信しようとする取引コーディネーターへ送ることで、セッション・セキュリティの確立に対する責任も負うことが好ましく、鍵はサーバーの公開鍵で暗号化される。その後の２つのパーティ間の通信は、そのセッション鍵を用いて暗号化される。

図１２は、取引コーディネーター２０２のコンポーネントに関連したセキュリティ関連フローの好適な実施形態のブロック図／フローチャートを組み合わせたものである。図１２に示すように、ステップ１２０２で、転送サービスコンポーネント３０６はリクエストを受け取る。ステップ１２０４で、転送サービスコンポーネント３０６は、そのリクエストをリクエストマネージャ３０４へ送る。リクエストマネージャ３０４は、入力メッセージに対して、そのメッセージ処理前に、全てのセキュリティ関連機能性を確実に実行することが好ましい。

ステップ１２０６で、リクエストマネージャは、ロギングコンポーネント３２０を呼び出して、未処理データを記録する。ロギングコンポーネント３２０は、否認防止及び検査のサポートを必要とするデータを集める。前述のように、全てのリクエスト及び応答は、受信形式で記録されることが好ましい。
ステップ１２０８で、リクエストマネージャ３０４は、リクエストに関する署名が要求されているかを確認する。ステップ１２１０で、リクエストマネージャ３０４が、リクエストには署名の必要がないことを確認すると、リクエストマネージャ３０４は、クライアントのユーティリティ証明書を用いて取引先認証照合モジュール５４を呼び出す。

ステップ１２１２で、リクエストマネージャ３０４が署名の必要があることを確認すると、リクエストマネージャ３０４は取引先認証モジュール４０８を呼び出す。ステップ１２１４で、取引先認証モジュール４０８は、リクエストに関する署名を証明し、署名コンポーネント３２４を呼び出して証明書チェーンを検証する。
署名コンポーネント３２４は、メッセージ・セキュリティをもたらし、セッション及びメッセージ認証サービスをサポートすることが好ましい。署名コンポーネント３２４は、ハードウェア・セキュリティ・モジュール２１８と相互作用して暗号化機能を果たす。ルート・エンティティ１１０は、全ての取引に対して使用されるデジタル署名方法の仕様を定めることが好ましい。署名コンポーネント３２４は、ハードウェア・セキュリティ・モジュール２１８と相互作用して署名検証プロセスに含まれる暗号化機能を果たすことが好ましい。

ステップ１２１６で、取引先認証モジュール４０８は、前述のように証明書ステータス照合モジュール４１４を介してリクエストをＯＣＳＰレスポンダ２０４へ送ることで、取引先の保証証明書のステータスを照合する。
ステップ１２１８で、取引先認証モジュール１１０は、取引先の保証証明書を用いて取引先認証照合モジュール４１８を呼び出す。ステップ１２２０で、取引先認証照合モジュール４１８は、取引先データベース２１４を照合して、取引先からのリクエストが、要求サービスを取得することの認定がなされているのを確認する。ステップ１２２２で、認定に関するリクエストは、リクエストマネージャ３０４へ戻され、前述のようにサービスが提供されたシステムの処理が継続する。

取引コーディネーターと以下のエンティティとの間のネットワーク通信に関する好適なセキュリティ要件を説明する。エンティティは、取引先、ＯＣＳＰレスポンダ、及び他の取引コーディネーターである。好適な要件、信用取引先１０８がリクエストを信用関係先１０４へ出すようになった一例として説明される。

信用関係先１０４の取引コーディネーター２０２_RPが信用取引先１０８からリクエストを受け取る場合、取引コーディネーター２０２_RPは、リクエストを認証する。典型的に、署名は、信用取引先１０８から取引コーディネーター２０２_RPへ送られた全てのメッセージに対して必要である。更に、取引コーディネーター２０２_RPは、信用取引先１０８にセキュア・ソケット・レイヤー・クライアント側セッション証明書の提供を要求する場合もある。

取引コーディネーター２０２_RPは、信用取引先１０８へ送られた全てのメッセージに対する認証をもたらすことが好ましい。更に、取引コーディネーター２０２_RPは、信用取引先１０８を用いて何れかのセッションを確立した場合には、セキュア・ソケット・レイヤー・サーバー側セッション証明書をもたらす。

好適な実施形態において、取引コーディネーター２０２_RPは、認定を行って 信用取引先１０８が信用関係先１０４に対する実在の取引先であるか否かを確認する。また、取引コーディネーター２０２_RPは、認定を行って、要求されているサービスの形式又はレベルを受け取ることが認定されているか否か確認できる。信用取引先１０８は、資格があるサービスを列挙する取引先データベース２１４_RPに関する入口を有することが好ましい。信用取引先１０８は、セキュア・ソケット・レイヤー・サーバー側セッション認証が採用される場合、識別名によって保証証明書に存在することが確認でき、また、その識別名によってユーティリティ証明書に存在することが確認できるのが好ましい。この取引コーディネーター態様は、ＣＯＴＳアクセス制御／認証パッケージと一体であってもよい。

好適な実施形態において、信用取引先１０８と取引コーディネーター２０２_RPとの間の通信は、ルート・エンティティ１１０により定義される仕様に基づいて暗号化され、サーバー側の認証が必要である。
典型的に、信用取引先１０８と取引コーディネーター２０２_RPとの間で交換されるメッセーはデジタル署名される。取引コーディネーター２０２_RPは、受け取った全ての署名付きメッセージを証明し、証明書チェーンを検証し、チェーン内の証明書が無効になっていないことを保証するのが好ましい。更に、取引コーディネーター２０２_RPは、信用取引先１０８へ送る全てのメッセージに署名する。

好適な実施形態において、取引コーディネーター２０２_RPは、信用取引先１０８に対する否認防止サービスを提供する。典型的に、取引コーディネーター２０２_RPは、任意のルートコンポーネントから受け取ったサービスに対するリクエストに関連する、全てのリクエストを記録する。これは他の関係先及びルート・エンティティ１１０のコンポーネントはもちろん、取引コーディネーター２０２_RPの他のコンポーネントも含む。信用関係先１０４は、信用取引先１０８からのサービスに対する全てのリクエストと、取引先からの否認申し立てから自身を保護するために信用取引先１０８から受け取った全ての確認通知とを記録するのが好ましい。

好適な実施形態において、取引コーディネーター２０２_RPは、検査目的で信用取引先１０８からのサービスに対するリクエストの全てを記録する。従って、システム管理者は、システムに対する潜在的攻撃を検出でき、鍵漏えいが発生した後でサービスに対するリクエストを受け取ったか否かを確認できる。また、リクエスト検査は、起こり得るどんな請求書発行係争をもサポートするのに利用できる。

好適な実施形態において、取引コーディネーター２０２_IP、２０２_RP、２０２_Rは、それぞれＯＣＳＰレスポンダ２０４_IP、２０４_RP、２０４_Rだけと、即ち同じ金融機関にあるＯＣＳＰレスポンダと通信する。他の金融機関にあるＯＣＳＰレスポンダからの応答が必要な場合には、好ましくは、通信は他の金融機関の取引コーディネーター２０２を通過する必要がある。

ＯＣＳＰレスポンダ２０４_IP、２０４_RP、２０４_Rは、リクエストを受け取っているエンティティの身元を識別でき、取引コーディネーター２０２_IP、２０２_RP、２０２_Rは、ＯＣＳＰ応答を受け取っているエンティティの身元を識別できることが好ましい。同じ場所に配置された取引コーディネーター２０２_IP、２０２_RP、２０２_RとＯＣＳＰレスポンダ２０４_IP、２０４_RP、２０４_Rとは、何らかの明示的な認証なしでローカルプロセスからのメッセージを受け取っていることを識別できるのが好ましい。この場合、セキュア・ソケット・レイヤー認証も署名付きリクエストも要求しない。しかし、ＯＣＳＰレスポンダ２０４_IP、２０４_RP、２０４_Rは、典型的に全てのリクエストに署名し、取引コーディネーター２０２_IP、２０２_RP、２０２_Rは、典型的にインターネットＰＫＩ ＯＣＳＰ仕様に基づいて署名付きリクエストを受け取る。

取引コーディネーター２０２_IP、２０２_RP、２０２_R及びＯＣＳＰレスポンダ２０４_IP、２０４_RP、２０４_Rが同じ場所に配置されておらず、誰と通信しているのかはっきり確認できない場合は、各々のコンポーネントの間の認証はなるべく必要である。リクエストに対する認証は、メッセージレベルであることが好ましく、セッションレベルであってもよい。同様に、応答に対する認証は、メッセージレベルであることが好ましく、セッションレベルであってもよい。

取引コーディネーター２０２_IP、２０２_RP、２０２_Rは、典型的に、ＯＣＳＰレスポンダ２０４_IP、２０４_RP、２０４_Rに関する認証照合を行わないことを理解されたい。その理由は、ＯＣＳＰレスポンダ２０４_IP、２０４_RP、２０４_Rは、典型的に、取引コーディネーター２０２_IP、２０２_RP、２０２_Rからサービスを要求しないからである。

ＯＣＳＰレスポンダ２０４は、それぞれの取引コーディネーター２０２と同じ場所に配置されるのが好ましいので、典型的に、その間の通信に対して通信セキュリティ機構を提供する必要はない。２つのコンポーネントは、完全に１つの金融機関の制御下にある物理環境に収容されているので、保護は、セキュリティ機構の実施とは対照的にポリシーにより提供され得る。
しかし、これらのコンポーネントが同じ場所に配置されていない場合は、通信の機密性又は保全性を危うくするネットワーク攻撃に対して通信を保護することが好ましい。この保護をもたらすＳＳＬを利用することが好ましい。

好適な実施形態において、各々のＯＣＳＰレスポンダ２０４は、それぞれの取引コーディネーター２０２と同じ場所に配置されているので、取引コーディネーター２０２は、ＯＣＳリクエストに署名する必要はない。しかし、ＯＣＳＰレスポンダ２０４は、ルート・エンティティ１１０により定義される仕様が要求する場合はリクエストに署名できる。

ＯＣＳＰ応答が署名を行う場合、特に応答が提供サービスに直接的に関連している場合は、完全なレスポンダの署名を記録することが好ましい。しかし、サービスに対するリクエストに関する認証照合の一部として、取引コーディネーター２０２がＯＣＳＰ応答を要求している場合、ＯＣＳＰ応答は、典型的に否認防止目的のために記録されない。その理由は、ＯＣＳＰ照合は、入ってくるリクエストを処理するか否かを確認するために実行されるものであり、リクエスト自身の処理の一部ではないからである。唯一、リクエスト処理に関連する情報は、否認防止目的で保持する必要がある。好適な実施形態において、ローカルＯＣＳＰ応答は、信用関係先１０４が同様に該当証明書の発行関係先１０２であり、ＯＣＳＰリクエストが、例えば証明書に対する検証リクエスト中に取引先証明書の証明を照合するサービス提供処理の一環である場合にのみ記録される。

好適な実施形態において、ＯＣＳＰレスポンダ２０４は取引コーディネーター２０２のサービスを要求しないので、セキュリティ検査目的のためにＯＣＳＰ応答を記録する必要はない。更に、取引コーディネーター２０２は自身を検査できないので、セキュリティ検査目的のために取引コーディネーター２０２が生成したＯＣＳＰリクエストを記録する必要はない。

取引コーディネーターは、他の取引コーディネーターからの全てのリクエストを認証する。典型的に、このことは、セキュア・ソケット・レイヤー・クライアント証明書か、又は、取引コーディネーターを、他の取引コーディネーターからの全リクエストに関して署名を要求するよう設定している金融機関のいずれか一方で達成される。

好適な実施形態において、第２の取引コーディネーターからリクエストを受け取る第１の取引コーディネーターは、認証照合を行って、要求している取引コーディネーターがリクエストを行うことが認定されているか否かを確認する。この認証照合は、そこからサービスを得ようとする取引コーディネーターの取引先データベースに対する入口を備える、全て認定済み取引コーディネーター２０２_IP、２０２_RP、２０２_Rを設けることで容易になる。サービス要求を受けた取引コーディネーター２０２が署名を必要とする場合、リクエスタは、識別名によって保証証明書に存在することが確認できることが好ましい。そうでない場合には、ユーティリティ証明書からの検証は、セキュア・ソケット・レイヤー・クライアント側認証が必要な場合にのみ許可されることが好ましい。

信用取引先１０８と取引コーディネーター２０２_RPの間の通信は暗号化されることが好ましく、サーバー側セッション認証が必要である。
関係先は、他の取引コーディネーターからその取引コーディネーターへ送られた全てのリクエストが署名付きであることを要求する場合もある。その代わりに、関係先は、セキュア・ソケット・レイヤー・クライアント側セッション証明書を要求とする場合もある。取引コーディネーター２０２_IP、２０２_RP、２０２_Rは、他の取引コーディネーターへ送られる全ての応答に署名することが好ましい。

取引コーディネーター２０２_IP、２０２_RP、２０２_Rは、否認防止サービスを提供する。その目的ために、取引コーディネーター２０２_IP、２０２_RP、２０２_Rは、他の取引コーディネーターから受け取ったリクエストに対するリクエストに関する全ての応答を記録することが好ましい。
取引コーディネーター２０２_IP、２０２_RP、２０２_Rが受け取った、サービスに対するリクエストを記録できることが好ましい。これによりシステム管理者は、システムに対する潜在的な攻撃を検出でき、また、システム管理者は、鍵漏えいが発生した後でサービスに対するリクエストを受け取ったか否かを確認できる。また、リクエスト検査は、起こり得るどんな請求書発行係争をもサポートするのに利用できる。

取引コーディネーターの好適なアーキテクチャ・コンポーネントを以下に詳細に説明する。
取引コーディネーターのコンポーネントは、専用のソフトウェアコードとして実現するのが好ましいが、他のソフトウェア製品も本明細書で説明するように利用できる。このコードに加えて、関係先は、前述の証明書ステータス照合サービスに関する彼ら自身のビジネス仕様ルールや、４コーナーモデルによりもたらされる他のサービスを書き込んで実行できる。

好適な実施形態において、取引先ソフトウェア開発キットをツール・セットとして利用して、取引コーディネーター２０２と取引先又は他の取引コーディネーターとの間のインターフェイスを容易にする。ソフトウェア開発キットは、転送サービスコンポーネント３０６と一体であることが好ましい。ソフトウェア開発キットは、信用取引先１０８が保有するウェブサイトにおける、アプリケーションのオリジナルウェブサーバー用の全てのハイパーテキスト転送プロトコル要求を遮断するようになっていることが好ましい。ソフトウェア開発キットは、メッセージが、定義ルールセットに基づいた署名を必要とするか否かを確認することが好ましい。また、ソフトウェア開発キットは、署名及び公開鍵証明書をハードウェア・セキュリティ・モジュール２３０の助けを借りて認証する。このようなＳＤＫの好適な実施形態は、本出願と同時出願の係属中の米国特許出願番号０９／６５７，６０４号「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｆａｃｉｌｉｔａｔｉｎｇ Ａｃｃｅｓｓ Ｂｙ Ｓｅｌｌｅｒｓ ｔｏ Ｃｅｒｔｉｆｉｃａｔｅ−Ｒｅｌａｔｅｄ ａｎｄ Ｏｔｈｅｒ Ｓｅｒｖｉｃｅｓ」に説明されており、その開示内容は、引用により本明細書に組み込まれている。

ソフトウェア開発キットによりもたらされる機能の広がりに応じて、この使用法は、取引コーディネーター操作の他の領域に拡張できることが好ましい。典型的に、ソフトウェア開発キットを取引コーディネーターで使用できるようにするには、特定の変更及び機能性の追加が必要である。

Ｍｉｃｒｏｓｏｆｔ（登録商標）ＳＱＬサーバーは、請求書発行データを格納するためのデータベースとして使用できる。取引コーディネーター２０２は、データベース・ライブラリを介してサーバーと相互作用するようになっていることが好ましい。もしくは、サーバーとの相互作用は、取引コーディネーターの開発がＪＡＶＡ（登録商標）上で行われる場合には、ＪＡＶＡ（登録商標）Ｄａｔａｂａｓｅ Ｃｏｎｎｅｃｔｉｖｉｔｙを用いて行ってもよい。更に、データベース・ライブラリは、他のサーバーに書き込まれていてもよく、これにより取引コーディネーター２０２に影響を与えることなくＭｉｃｒｏｓｏｆｔ ＳＱＬサーバーを他のデータベースで置き換えることが可能になる。

Ｍｉｃｒｏｓｏｆｔ ＳＱＬサーバーは、以下の機能を備えることが好ましい。
（１）レポート、データ分析、意志決定、及びデータモデル化に不可欠な複数の情報を有効に分析するためのオンライン分析処理（ＯＬＡＰ）
（２）ディスク格納アーキテクチャ
（３）マルチフェーズ・クエリ・オプチマイザー
（４）クエリ・オプチマイザーが最新情報を利用してクエリ効率を高めるようにできる自動統計
（５）運用システムへの影響を最低限にした状態で高性能オンラインバックアップをもたらすアクティブ・バックアップ
（６）ユーザが単独で作業して後で結合することを可能にするマージ複製
（７）マージ競合を解決するための組み込み優先順位ベース競合解決
（８）ウェブへのデータ公開能力
（９）複数の異質のソースからのデータを取り込んで変換するデータ変換サービス
（１０）物理的及び論理的データベース一貫性照合能力
（１１）動的列レベル固定
（１２）統計的収集を管理し効率的方法を保証するクエリ・オプチマイザー
（１３）性能を高めるための、単一クエリの各々のステップが並行実行されて最適な応答時間をもたらす、複数のプロセッサを横切る単一クエリのクエリ内並行実行
（１４）意志決定サポート、データウェアハウス、及びオンライン分析処理アプリケーションに見られる、大きなデータベース及び複雑なクエリを上手くサポートする、再設計されたクエリプロセッサ
（１５）ソート速度
（１６）テーブル毎の複数トリガー及びトリガーの直接反復
（１７）最適なメモリ割り当て及び使用のための動的メモリ、及び動的メモリ管理
（１８）並行バックアップ及び素子速度でのユーティリティスケールの修復
（１９）性能向上及び手動調整の必要のないスマート先読みロジック
（２０）重要な構成のランタイムチェック

好ましくは、トランザクション・コーディネータを維持するエンティティが、トランザクションごとに請求書を生成することができるようにするために、十分なデータが収集され、および記憶される。この目的のために、好ましい実施形態において、トランザクション・コーディネータによって生成された、どの入および出メッセージも、そのすべてが、データベースにおける連続したレコードに記憶される。そのようなメッセージは、受信されたすべての要求、作られたすべての要求、生成されたすべての応答、および受信されたすべての応答を含む。これによって、トランザクションごとの請求書を生成するのに必要なデータすべてのアベイラビリティ（availability）を確証する。

好ましくは、トランザクション・コーディネータ２０２は、集中化された一般的な方法で、請求書データを記録する。関係先は、集中請求書データから、関係先に関連する請求書データを抜き出すために、自らのルーチンを書き込むことによって、記録を入手してもよい。データベースにデータを供給することに加えて、データは、ＥＸＣＥＬ登録商標のスプレッドシート（spreadsheets）で供給されてもよい。

好ましい実施形態において、トランザクション・コーディネータの、タイム・スタンプ・コンポーネントとして、Ｄａｔｕｍ Ｉｎｃ．のＴｙｍｅＳｅｒｖｅ Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｓｅｒｖｅｒ（“ＴＹＭＳＹＮＣ”）登録商標が使用されている。ＴＹＭＳＹＮＣは、米国海軍天文台によって管理されている、協定世界時間に対する最も近いマイクロ秒まで、完全な正確性をもって、ナブスター全地球位置把握システムの衛星の配置から時間を読み取る、時間同期パッケージである。この製品は、ワークステーションを、ＴＣＰ／ＩＰ（transmission control protocol over internet protocol）およびＬＡＮ（local area network）ネットワークで同期させるように適応していてもよい。好ましくは、ネットワーク・タイム・プロトコル（Network Time Protocol）を用いて、ネットワーク内で時間を配分する。ＴＹＭＳＹＮＣは、コンピュータ・システムのクロックを、継続的に、協定世界時間に同期させるように構成されてもよい。要求ならびに応答が生成され、およびメッセージが受信され、ならびに送信される時間は、好ましくは、否認防止目的、および監査目的で記憶される。

好ましい実施形態において、トランクザクション・コーディネータ２０２とのすべての通信は、安全接続（secure connections）で実行される。好ましくは、同期通信のための、安全ソケット・レイヤ暗号化体系（secure socket layer encryption scheme）が使用される。安全ソケット・レイヤは、コマーシャル／ウェブ・サーバ実装と適合する方法で使用され、およびインターネット等の電子ネットワークを介して、セキュリティとプライバシーを提供する。安全ソケット・レイヤは、アプリケーション独立であり、そのために、プロトコルは、それらの最上部に、透過的に重ねられる。

安全ソケット・レイヤは、すべてのネットワーク通信に関する機密性、データ完全性、および認証（authentication）を与える。安全ソケット・レイヤは、通常、通信エンティティ間を通るすべてのデータを暗号化することによって、機密性を確証する。安全ソケット・レイヤ・イネーブルド・クライアント９５およびサーバ９０が最初に通信するときに、プロトコルのバージョンに関して同意し、および暗号化アルゴリズムを選択する。好ましくは、ネットワーク承認暗号化アルゴリズムおよびキー長が、ルート・エンティティ（root entity）１１０によって特定される。

安全ソケット・レイヤはまた、通常、暗号の使用によって、データ完全性を確証する。メッセージが正しく解読されない場合、レシピエント（recipient）は、誰かがそのメッセージに干渉したことを告げることができる。

安全ソケット・レイヤはまた、サーバおよびクライアント認証をサポートし、暗号化キーを取り決め、およびデータが、より高いレベルのアプリケーションによって交換される前に、サーバを認証する。認証は、好ましくは、デジタル署名およびパブリック・キー証明書の使用を通して与えられ、それは電子通信セッションが最初に確立されたときに交換される。

好ましい実施形態において、各トランザクション・コーディネータは、Ｓ／ＭＩＭＥメッセージを送信するためのＳＭＴＰを用いて、およびＳＳＬｖ３接続（ＨＴＴＰＳ）を介してＨＴＴＰプロトコルを通して通信し、パブリック・インターネットでメッセージを受信し、および送信することができる。すなわち、各トランザクション・コーディネータは、好ましくは、以下の二つの通信モードをサポートするように適応する：
・ 安全ソケット・レイヤ（ＳＳＬｖ３）を介したＨＴＴＰ−同期通信（すなわちＨＴＴＰＳ）のためのものである。ＨＴＴＰＳは、ウェブ・ページを安全に転送するために、ウェブ・サーバとウェブ・ブラウザとの間の、安全ソケット・レイヤを統合する、ハイパーテキスト転送プロトコルである。ＨＴＴＰキープ・アライブ（HTTP keep alive）の使用が推奨される。
・ Ｓ／ＭＩＭＥｖ２−ＳＭＴＰを使用した非同期通信のためのものである。

好ましい実施形態において、各トランザクション・コーディネータは、信用取引先（relying customer）との通信中はＨＴＴＰＳサーバとして、および他の金融機関におけるトランザクション・コーディネータへの要求をするときは、ＨＴＴＰＳクライアントとして振舞う。どちらの方法でも、証明書ステータス・チェック（credential status checking）のための、すべてのＳＳＬ通信は、たった一つのサーバ認証のみを採用してもよい。

好ましい実施形態において、各トランザクション・コーディネータは、ルート・エンティティ１１０によって承認される他のトランスポート・プロトコル（transport protocol）（例えば、ＩＩＯＰ）を介して届けられるメッセージを受信してもよい。さらに、関係先は、構成により、局所的に他のトランスポート・プロトコルを実行してもよい。しかしながら、前もっての合意がない場合、ＨＴＴＰＳサポートのみが、任務を負うべきである。

好ましい実施形態において、証明書ステータス・チェック・サービス３１２のために、Ｖａｌｉｃｅｒｔ登録商標のＯＣＳＰレスポンダが使用される。しかしながら、ＯＣＳＰレスポンダ２０４へのアクセスは、ライブラリを用いて達成されてもよい。このように、新しいライブラリを書き込むことによって、新しいＯＣＳＰレスポンダ・ベンダが実装されてもよい。

好ましくは、ＯＣＳＰレスポンダ２０４は、証明書取り消しリストを使用せずに、証明書ステータスを決定する。ＯＣＳＰレスポンダ２０４は、認証局、および証明書を発行し、確認し、ならびに無効にするコンポーネントに関わる処理のほとんどを動かし、および潜在的に大きな証明書取り消しリストをダウンロードする必要性を排除するかもしれない。代替的に、これら機能は、個別の署名キーを与えられてもよい様々なコンポーネントの間で配分されてもよい。例えば、証明書を発行する機能は、取り消し機能から分離されてもよく、およびこれらの機能を実行するコンポーネントは、別個の署名キーを備えてもよい。

好ましい実施形態において、署名コンポーネントとして、ハードウェア・セキュリティ・モジュールが使用される。ハードウェア・セキュリティ・モジュールは、好ましくは、署名をし、および署名を確認するための、高速装置である。ハードウェア・セキュリティ・モジュールは、通常、暗号サービスを、認証されたエンティティに供給する、ネットワーク化されたハードウェア装置である。適切なハードウェア・セキュリティ・モジュールは、ＮＣｉｐｈｅｒによって製造される。

好ましい実施形態において、トランザクション・コーディネータ２０２は常に、その通常の動作時間中、要求を処理するために利用可能であり、その時間は、一週間７日一日２４時間でもよい。本システムが、確実にアベイラビリティの要件に適合するために、システム・アベイラビリティの、詳細な要件解析が実行されるべきである。様々な関係先が様々な要件を有するかもしれないので、多くの異なる種類の故障が生じるかもしれない。公知のとおり、多くの様々なハードウェアおよびソフトウェア・ベンダが、高アベイラビリティなシステムに関して、様々なオプションを提供する。しかしながら、これらのオプションは、一定の金融機関によって選択されるハードウェアおよびソフトウェアに関して利用可能であるかもしれないし、利用可能ではないかもしれない。

トランザクション・コーディネータに影響を与えるかもしれない、数多くの、公知の、潜在的なハードウェア故障がある。例えば、サーバへの電力供給が故障するかもしれない。好ましくは、複数の冗長ホットスワップ電力供給（hot-swap power supply）は、自動的に、冗長な電力供給に転換する。サーバが故障し、またはクラッシュした場合、トランザクション・コーディネータは、好ましくは、自動フェイル・オーバー（automatic fail over）のための、高アベイラビリティ・クラスタリングを備える。さらに、トランザクション・コーディネータは、好ましくは、ネットワーク・オペレーティング・システム（ＮＯＳ）ハングの場合に、自動的にサーバをリブートするための、セルフ再スタート機能を具備する。

トランザクション・コーディネータはまた、好ましくは、ディスク故障またはクラッシュを扱うための、複数の冗長ホットスワップ・ディスク・ドライブおよびディスク・アレイ・コントローラも具備する。トランザクション・コーディネータはまた、ＮＩＣ故障の場合の、冗長ネットワーク・インターフェース・カード（ＮＩＣｓ）のためのサポートを供給するための、ネットワーク・インターフェースも具備する。クーリング・システム故障の場合には、トランザクション・コーディネータは、好ましくは、個別に取り外すことができるホット・スワッパブル冗長ファン（hot swappable redundant fans）を具備する、冗長ホットスワップ・クーリング・システムを使用する。トランザクション・コーディネータはまた、好ましくは、ハードウェアおよびソフトウェア故障を検出するために、インテリジェント・プラットフォーム・マネージメント・インターフェース（Intelligent Platform Management Interface）も具備する。インテリジェント・プラットフォーム・マネージメント・インターフェースは、装置管理のための通信を単純化し、および標準化する、オープン・スペック（open specification）である。メモリ破損の場合、トランザクションは、好ましくは、自己修正メモリを使用する。自己修正メモリは、好ましくは、管理されたエラー・チェックならびに修正システム・メモリおよびキャッシュ・メモリである。

アプリケーション・クラッシュの場合、トランザクション・コーディネータ２０２は、好ましくは、アプリケーションを再スタートするための、トランザクション処理モニタリングを使用する。トランザクション・コーディネータはまた、アプリケーションの冗長なコピーをランさせてもよく、およびトランザクション処理モニタは、トランザクションを冗長コピーに転送してもよい。一定のアプリケーション・アベイラビリティ特性は、アドレス・アプリケーション・クラッシュも支援するかもしれない特定の方法で、アプリケーションがコード化されることを求めるかもしれない。

オペレーティング・システムのクラッシュの場合、トランザクションは、好ましくは、ネットワークによってサポートされている待機マシンに転送される。ＣＯＲＢＡ等のミドルウェアを含むディレクトリ・サービスはまた、新しいトランザクション要求を、新しいマシンに再ディレクトするためにも使用されてもよい。
ハードウェアおよびソフトウェア・アベイラビリティ製品に加えて、アプリケーションおよびネットワークを監視するために、好ましくは、モニタリング・インフラストラクチャが使用される。

好ましい実施形態において、アプリケーションを監視するために、ソフトウェア・モニタリング・ツール（Ｔｒｉｖｏｌｉ等）が使用される。このツールは、好ましくは、アプリケーション故障の場合に、管理者を呼び出すように構成される。（ＮｅｔＶｉｅｗで作られるもの等の）ネットワーク・モニタリング・システムはまた、管理者が、ネットワークを監視することができるようにするためにも、使用されてよい。

好ましくは、トランザクションをシミュレートするために、カスタム・リトン・アプリケーション・デーモン（custom written application daemons）が使用される。これらのトランザクションが故障すると、システム管理者に知らされてもよい。また、データベース監視のために、データベース・ベンダ・ツールが使用されてもよい。ほとんどのデータベースは、デッドロック（deadlocks）および他のデータベース問題を検出する、データベース・モニタリング・ツールを供給する。

トランザクション・コーディネータのための配分アプローチは、好ましくは、ルート・エンティティ１１０が、関係先に配分したいものの機能であると定義される。アプリケーション配分は、通常、ルート・エンティティ１１０からのウェブ・ダウンロードを介して実行されてもよい。ウェブ・ダウンロード・メカニズムは、選択的ダウンロード、認証、およびトラッキングを備えてもよい。

好ましい実施形態において、トランザクション・コーディネータは、ＣＩＣＳ、ＩＭＳ、および他のレガシー・システム等、現存のオペレーショナル・システムとの統合をサポートするように適応してもよい。

関係先は、上述の、トランザクション・コーディネータ・アーキテクチャおよび機能全体を使用することを選択してもよく、または代わりに、トランザクション・コーディネータのコンポーネントを使用し、ならびに自分の実装を、前記コンポーネントに追加することを選択してもよい。ウェブ・ダウンロード・アプローチは、好ましくは、関係先の様々な要件を満足するように構成される。ダウンロード・メカニズムは、好ましくは、少なくとも三つのダウンロード・オプション：（１）ダウンロード・トランザクション・コーディネータ・エグゼクタブル（download transaction coordinator executable）・オプション（２）トランザクション・コーディネータのソース・コードおよびバイナリ・オプションおよび（３）トランザクション・コーディネータ・クラスのソース・コード・オプションを、供給する。

第一のオプションは、好ましくは、トランザクション・コーディネータ全体を使用することを選択する関係先の対応をする。このオプションは、異なるプラットフォームに対するオプションを供給する。第二のオプションは、好ましくは、上述のトランザクション・コーディネータのコンポーネントを、自らの実装に差し込むことを選択する関係先の対応をする。このダウンロード・メカニズムも、異なるプラットフォームに対するオプションを供給する。第三のオプションは、好ましくは、高耐久性開発を選択し、および上述のトランザクション・コーディネータの実装の、一定の部分を使用することのみを選択する金融機関の対応をする。

好ましくは、ダウンロード・メカニズムによって、金融機関は、エグゼクタブルだけでなく、ソース・コードもダウンロードすることができる。ダウンロードされたエグゼクタブルは、自らにおいて使用されてもよく、およびソース・コードは、他のカスタム・アプリケーションを開発するために使用されてもよいので、ルート・エンティティ１１０は、好ましくは、ルート・エンティティ１１０との、信頼されたパートナーであり、よってトランザクション・コーディネータを使用する権限を与えられている機関にのみ、ダウンロード・アクセスを供給する。好ましくは、これは、認証／承認処理を介して達成される。

ルート・エンティティ１１０は、好ましくは、どの関係先が、トランザクション・コーディネータの特定のコンポーネントをダウンロードするか追跡してもよい。このように、ルート・エンティティ１１０は、ある時間において使用されているトランザクション・コーディネータおよび／またはそのコンポーネントのバージョンを決定してもよい。ルート・エンティティ１１０は、（１）ダウンロードされたコンポーネントに対して、金融機関から料金を請求するため、および（２）メンテナンスの目的で、トランザクション・コーディネータのバージョンを追跡するために、この情報を使用してもよい。

好ましくは、トランザクション・コーディネータは、顕著に性能を低下させることなく、増加するユーザに対処するために、スケーラブル（scalable）になるよう適応している。アプリケーションに対するスケーラビリティの要件を満足させる際の一つのステップは、ユーザ・ベースの潜在的な成長を予測することである。一般的に、分配されたアーキテクチャを有するアプリケーションは、高負荷のコンポーネントの、配分された複数のインスタンスが、ある時間においてランすることを可能にすることによって、より高いスケーラビリティを容易にする。トランザクション・コーディネータ・アーキテクチャは、好ましくは、配分されたものであり、それゆえに、スケーラビリティをサポートする。さらに、トランザクション・コーディネータのロード・キャパシティは、好ましくは、選択された開発マシンに合わせて、揃っている。この情報は、予想された数のトランザクションをサポートするために、適切なハードウェアを選択するために使用される。好ましくは、トランザクション・コーディネータ（および、ＯＣＳＰレスポンダ）は、毎分、１０００までの確認トランザクションを、信頼性高く扱うように適応している。

上述の通り、ＯＣＳＰチェックは、通常、ユーティリティ証明書に関しては実行されない。署名が、要求において求められない場合、安全ソケット・レイヤの、クライアント側の証明書が取り消されなかったことを確証するための、適切なメカニズムはない。好ましくは、安全ソケット・レイヤ証明書が取り消された場合、金融機関は、バンド外（例えば、ブロードキャスト・メッセージ）で知らされ、および影響が及んだユーザは、関係先の取引先データベースから削除される。

各トランザクション・コーディネータは、通常、そのハードウェア・セキュリティ・モジュールに記憶されるいくつかの証明書のセットを信用する。これらの証明書について、ＯＣＳＰチェックは実行されない。取り消された証明書が、ハードウェア・セキュリティ・モジュールに存在する場合、オンライン処理中には、それは検出されないであろう。好ましくは、金融機関は、それらが、ハードウェア・セキュリティ・モジュールから証明書を削除することができるように、ハードウェア・セキュリティ・モジュールに記憶された証明書が取り消されたか、通知される。

トランザクション・コーディネータは、クライアントとして振舞うとき、自らが通信しているサーバを認証する。しかし、このチェックは通常、サーバが、トランザクション・コーディネータが信頼する認証局によって発行された証明書であることを保証するにすぎない。サーバ自身の同一性およびステータスに関するチェックはない。好ましい実施形態において、トランザクション・コーディネータは、サーバを、信頼されたサーバのリストと照合し、およびサーバの証明書のＯＣＳＰチェックを実行する。しかしながら、サーバ・インターセプト（server intercepting）要求によって得られるものはほとんどないので、これらの追加チェックに起因する性能の低下は通常正当化されない。

通常、トランザクション・コーディネータは、潜在的なアタック（attacks）を検出するための自動化処理を有していない。好ましくは、システムおよびアセキュリティ管理者検査監査は、そのような潜在的なアタックを識別するために、周期的にログする。

通常、安全ソケット・レイヤの、クライアント側認証チェックを通過しない要求は、ログされない。アタック（例えば、サービス・アタックの否定）がこのレベルで生じた場合、参照するログはない。

好ましい実施形態において、トランザクション・コーディネータは、ファイアウォールによって保護されている。好ましくは、ファイアウォール・コンポーネントは、入ってくる要求のログを維持する。

トランザクション・コーディネータは、好ましくは自動侵入検出メカニズムを備える。これらの処理は通常、入トラヒックを監視し、または疑わしい動作を探して、監査ログを走査し、および必要な場合には、適切な行動をとる。

トランザクション・コーディネータは、通常、否認防止目的でログを維持する。しかしながら、しばしば前記システムは、ユーザが、否認防止をサポートするために必要なデータを検索するのを支援する機能を含まない。ユーザは手動で、すべてのサポートしているデータを見つけるために、ログを通してサーチする。他の実施形態においては、自動否認防止ツールが、この処理において、ユーザを支援するために使用されてもよい。

好ましい実施形態において、トランザクション・コーディネータおよびＯＣＳＰレスポンダは、証明書ステータス・チェック要求に関して、通常のインターネット・タイム・アウト値を採用する。他のサービスに関しては、タイム・アウト値は、そのサービスに適切なように設定されてもよい。好ましい実施形態において、タイム・アウト値は、トランザクション・コーディネータにおいて構成することができる。

以下の説明は、トランザクション・コーディネータのための、可能なハードウェアおよびソフトウェア実装を略述している。

トランザクション・コーディネータのために使用されるメイン・サーバは、Ｈｅｗｌｅｔｔ Ｐａｃｋａｒｄ Ｎｅｔｓｅｒｖｅｒ ＬＨ４でもよい。好ましくは、サーバは以下の仕様を有する：４Ｐ２−４５０ＭＨＺプロセッサ、５１２−７６８ＭＢ ＲＡＭ、４０−６０ＧＢ ＨＤ でＲａｉｄ５アレイ、ＵＰＳ、およびテープ・バックアップのための外部ＤＬＴ４０Ｅ ＤＬＴ４０００テープ・ドライブである。好ましくは、少なくとも５つのワークステーションが使用され、その各々は、以下の使用を有する：Ｐ２４００ＭＨｚプロセッサ、１２８ＭＢ ＲＡＭ、および６ＧＢ ＨＤである。

トランザクション・コーディネータは、好ましくは、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ ＮＴ（登録商標）４．０／２０００，Ｓｕｎ Ｓｏｌａｒｉｓ，およびＨｅｗｌｅｔｔ Ｐａｃｋａｒｄ ＨＰ−ＵＸに基づいて、サーバ上でサポートされることができるように、プラットフォーム独立である。実装は、好ましくはＪＡＶＡ（登録商標）でなされるが、コード化は、同様にＣ／Ｃ＋＋でなされてもよいものもある。

Ｗｉｎｄｏｗｓ ＮＴ Ｓｅｒｖｅｒ ｗ／Ｓｅｒｖｉｃｅ Ｐａｃｋ３が、オペレーティング・システムとして使用されてもよい。Ｍｉｃｒｏｓｏｆｔ Ｖｉｓｕａｌ ＳｏｕｒｃｅＳａｆｅ６．０は、ソース・コントロールのために使用されてもよい。ＳｙｍａｎｔｅｃのＶｉｓｕａｌ Ｃａｆｅ Ｐｒｏｆｅｓｓｉｏｎａｌ Ｅｄｉｔｉｏｎ３．０（Ｊａｖａ（登録商標） Ｖｅｒｓｉｏｎ１．２）が、開発のために使用されてもよい。ＲＳＡ Ｓｅｃｕｒｉｔｙ ＳｙｓｔｅｍｓのＳＳＬ／Ｊ ＳＤＫは、安全ソケット・レイヤ実装のために使用されてもよく、ＸＥＴＩのＪＫＩＸによっても求められる。

署名確認に関して、ｎＣｉｐｈｅｒのハードウェア・セキュリティ・モジュールが使用されてもよい。署名取引先からの署名に関して、Ｄａｔａｋｅｙスマート・カードが使用されてもよい。好ましくは、ＯＣＳＰレスポンダは、暗号機能に、およびＡＳＮ．１通信のためにインターフェースを供給するツールキットを備える。好ましい実施形態において、ＸＥＴＩのＪＫＩＸが、この目的で使用されてもよい。

デジタル・タイム・スタンプに関して、ＤａｔｕｍのＴＹＭＳＹＮＣまたは他の信頼できるタイム・ソースが使用されてもよい。ＭＳ ＳＱＬサーバが、上述のデータベースに関して使用されてもよい。Ｍｅｔｒｏ ＷｏｒｋｓのＣｏｄｅ Ｗａｒｒｉｅｒは、ポータブルＣ／Ｃ＋＋開発の、開発のために使用されてもよい。コード・ポータビリティ（code portability）を検査するためのコード完全性チェックを実行するために、ＣｏｄｅＩｎｔｅｇｒｉｔｙが使用されてもよい。

通常、様々なエンティティの間を通過するデータのサイズは、パブリック・キー・インフラストラクチャ・システムの性能に関して、手助けとなる。エンティティ間で提出されるメッセージは、それゆえに、好ましくは、送信されるデータのサイズを推定するように解析される。前記解析は、特定のルート拡張とともに、ＲＦＣ２４５９で定義された、証明書フィールドに基づいて実行されてもよい。

証明書フィールドの正確なデータ長は、固定された長さを有し、好ましくは、推定中に考慮される。しかしながら、長さが様々である多くのフィールドがある。これらのフィールドに関して、好ましくは、サイズに関する自由な推定がなされる（すなわち、小さいよりも、大きい）。また、すべてのメッセージ・サイズの推定は、好ましくは、すべての拡張に関するサイズを含む。すなわち、メッセージが５つの異なる拡張を許可する場合、前記サイズは、好ましくは、５つすべての拡張が要求とともに送信されているという前提で、算出される。

図１３は、好ましい実施形態における、システム・エンティティ間を通過する様々なメッセージ（推定）サイズを表している。図１３に記載の通り、署名取引先（subscribing customer）１０６から信用取引先（relying customer）１０８に渡されるメッセージの、全体の推定メッセージ・サイズは、２６１０バイトである。前記メッセージは、通常、二つの証明書を具備し、各々が１１４６バイトであり、ルート・エンティティによって署名された、発行関係先（issuing participant）の証明書は、１２８バイト、発行関係先の署名は、１２８バイト、およびＨＴＴＰヘッダは６２バイトである。

信用取引先１０８から信用関係先１０４へ渡されるメッセージの、全体の推定メッセージ・サイズは、２０２２バイトである。前記メッセージは、通常、二つの要求を具備し、一つは署名取引先の証明書に関し、一つは発行関係先の証明書に関し、各々は５５バイトであり、メッセージ拡張は２１０バイトであり、バージョン・ナンバ（version number）は４バイトであり、信用関係先の名は１３２バイトであり、信用関係先の署名は１２８バイトであり、信用関係先の証明書は１１４６バイトであり、ＨＴＴＰヘッダは６２バイトである。

信用関係先１０４から発行関係先１０２へ渡されるメッセージの、全体の推定メッセージ・サイズは、１６０１バイトである。前記メッセージは、通常、署名取引先の証明書または発行関係先の証明書に関する要求を具備し、それは５５バイトであり、メッセージ拡張は２１０バイト、信用関係先のトランザクション・コーディネータ証明書におけるルート・エンティティの署名は１２８バイト、信用関係先のトランザクション・コーディネータ証明書は１１４６バイト、およびＨＴＴＰヘッダは６２バイトである。

発行関係先１０２から信用関係先１０４へ渡されるメッセージの、全体の推定メッセージ・サイズは、２０８６バイトである。前記メッセージは、通常、署名取引先の証明書か、または発行関係先の証明書のいずれかに関する応答を具備し、それは４５６バイトであり、メッセージ拡張は２９４バイト、発行関係先の証明書は１１４６バイト、ルート・エンティティの署名は１２８バイト、およびＨＴＴＰヘッダは６２バイトである。

信用関係先１０４から信用取引先１０８へ渡されるメッセージの、全体の推定メッセージ・サイズは、２２１３バイトである。前記メッセージは、通常、署名取引先の証明書または発行関係先の証明書に関する応答を具備し、それは５５バイトであり、メッセージ拡張は２１０バイト、信用関係先のトランザクション・コーディネータからの応答は１２７バイト、信用関係先のトランザクション・コーディネータ証明書は１１４６バイト、信用関係先・トランザクション・コーディネータの証明書への、ルート・エンティティの署名は１２８バイト、およびＨＴＴＰヘッダは６２バイトである。

異なるフィールドの、メッセージ・サイズ推定の詳細は、以下の表に記載されている。通常、エンティティ間で渡されるメッセージのサイズは、２Ｋから３Ｋの間である。トランザクション・ボリュームが算出されると、この情報は、好ましくは、ネットワーク・ロード（network load）を推定するために使用される。

証明書サイズ―拡張無しまたはルート特化命令

証明書拡張―ルート命令および拡張を伴う

ＯＣＳＰ要求―ルート命令および拡張を伴う

ＯＣＳＰ応答―ルート命令および拡張を伴う

ＯＣＳＰトランザクションおよび保証トランザクションに関する有効要求および応答時間、およびすべてのトランザクションに関する確認時間は、好ましくは、ルート・エンティティ１１０によって特定される。以下の節は、トランザクション・コーディネータに対する、好ましいパフォーマンス・ターゲットを記述している。記述された応答時間は、特定的に、システム応答時間を表す。好ましくは、手動処理（確認に対する必要性に言及し、それを要求し、クレームをファイルする等）が完了する、経過した時間フレームも確立される。

好ましくは、有効要求および応答時間（すなわち、ＯＣＳＰ）は、ルート制御インフラストラクチャ内での、すべての応答時間トランザクションに関して、１０秒以下である。（取引先から取引先へ、または取引先からルートへの）ルート・インフラストラクチャ外の認可は、好ましくは６０秒を超えない。合計の往復時間は、好ましくは７０秒を超えない。好ましくは、応答時間は、インターネット上での待ち時間を含む。エンド・ツー・エンド（end to end）応答時間は、好ましくは、最長の有効パス（すなわち、署名取引先から信用取引先へ、信用関係先へ、発行関係先へ、そしてルート・エンティティへ）を含む。

例示的なパフォーマンス要件は、以下のとおりであろう：信用関係先のトランザクション・コーディネータへの、証明書ステータス・チェックの通知と、応答の受信との間はたった６秒であり、およびキャッシングが有効で、新しさの証明（すなわち、関係先によって送信されるメッセージにおける、関係先証明書のステータスを含む）が有効で、二つの証明書の証明書チェーン（certificate chain）が認可されており、トランザクションが四角トランザクション（four-corner transaction）であり、ならびにシステム・エンティティは、（インターネットではなく）１０Ｍｂｐｓ ＬＡＮに接続されている場合に、応答に関するデータが局所的に利用可能である証明書ステータス・チェックへ、応答を向かわせるのにたった３秒である。

保証要求応答時間は、オフライン・トランザクションを含む。好ましくは、これらのオフライン・トランザクションは、営業日の終わりに開始する８時間の時間帯を超えない。

損失した、傷ついた、または無効な証明書の通知に対する応答のための応答時間は、好ましくは、オフライン・トランザクションを含む。好ましくは、これらのオフライン・トランザクションは、１時間を超えない。

証明書の取り消しも、好ましくは、オフライン・トランザクションを含む。好ましくは、これらのオフライン・トランザクションは1時間を超えない。

トランザクション・コーディネータはまた、好ましくは、トランザクションの確認を供給する。オンライン・トランザクション要求は、好ましくは、不完全な要求または応答を含むステータス確認を、７０秒以内で受信する。トランザクション・コーディネータはまた、好ましくは、不完全なトランザクション要求または応答の検索のために、要求ステータス、不完全な要求応答、ならびに不完全なトランザクションのためのトランザクション・キューイング（transaction queuing）の受信を記憶するための方法を供給する。

トランザクション・コーディネータはまた、好ましくは、トランザクション回復要件を具備する。適切なシステム・リソース割り当ては、好ましくはトランザクション・ロールバック（transaction roll-back）を考慮する。

トランザクション・コーディネータはまた、好ましくは、フェイル・オーバー要件を与える。好ましい実施形態において、トランザクション・コーディネータは、システム冗長性、システム／ホット・バックアップ、およびパブリック・インターネット内での冗長性を備える。

トランザクション・コーディネータの開発中、開発環境におけるパフォーマンス・ベースライン（performance baseline）が、好ましくは確立される。このベースライン情報は、開発マシン自身でのアプリケーション・コンポーネントのパフォーマンスを向上させるために使用される。しかしながら、好ましいターゲット・パフォーマンスを達成するために、予測される数のトランザクションをサポートすることができる適切な生産ハードウェアと、および適切な帯域幅のネットワークが、通常、正しい位置に配置される。

以下の節では、トランザクション・コーディネータのより高いパフォーマンスのための、好ましいチューニング方法を述べる。

エンティティ間を通過しているメッセージのサイズは、各メッセージとともに送信される証明書の一部またはすべてを排除することによって減らすことが可能であるかもしれない。通常、メッセージのレシピエントは、センダーの身元（すなわち、保証証明書に現れるセンダーの識別名前）を知っており、自らの完全な証明パスへアクセスする。必要とされる証明書の多くも、ローカル・レポジトリから入手可能である。

認証処理の一部として実行されるＯＣＳＰチェックは、取引先データベースが、取り消された証明書を反映させるように設計され、および認証チェックが、その識別名とは対照的に、ユーザの識別名ならびに証明書と照合される場合、省略される。

上述の好ましい実施形態において、トランザクション・コーディネータは、未処理のトランザクション・データを記憶し、それから請求の目的で、データのサブセットを個別に記憶するために、前記データをパースする。しかしながら、代替的に、この機能は、未処理トランザクション・データベースを監視し、およびデータベースに記憶されたデータから、関連する請求データを抽出するオフライン処理に、オフロードされてもよい。

トランザクション・コーディネータとＯＣＳＰレスポンダを同じ場所に配置することによって、署名し、ならびに要求を確認する必要性、およびこれらのコンポーネント間での安全ソケット・レイヤ接続を確立する必要性を排除する。

金融機関間で、およびルート・エンティティ１１０との通信中に、安全ソケット・レイヤを使用することによって、通常、各要求メッセージをデジタル署名する必要性を排除する。しかしながら、デジタル署名された要求は、より高い安全性を供給する。各関係先は、好ましくは、パフォーマンスと安全性を引き換えることに伴うリスクを評価する。

ＯＣＳＰ応答をキャッシングすることは、通常、ルート・エンティティへのＯＣＳＰ要求を送信し、および受信するのにかかる時間を減らすことによって、往復時間を改善する。好ましい実施形態において、ＯＣＳＰ応答の確認は、オンライン・トランザクション処理の一部として確認を実行するのとは対照的に、データをキャッシュに入れるときに実行される。

好ましい実施形態において、トランザクション・コーディネータは、有効性応答をキャッシュし、および証明書を発効させるために、キャッシュされた応答を用いてもよい。応答がキャッシュされる期間は、好ましくは、ルート・エンティティ１１０によって、ポリシー事項（policy matter）として設定される。この期間は、好ましくは４乃至５分の範囲内であろう。

トランザクション・コーディネータが、キャッシュされた応答を使用する性能を実装する場合、好ましくは、否認防止の目的と同様に、請求および監査のための、それらの使用をログするように適応する。ログされた情報は、好ましくは、キャッシュされた応答が、新しく得られた応答よりもむしろ証明書を認可するために使用されたことを示す。

高い値のトランザクションに関して、クライアント・アプリケーションは、キャッシュされた応答よりも、新しい応答の使用を好むかもしれない。したがって、好ましい実施形態においては、トランザクション・コーディネータは、好ましくは、キャッシュされた応答よりも、新しい応答を使用する明確な要求に対する、新たに得られた有効性応答を入手し、および使用する。

好ましい実施形態において、応答のレシピエントは、レスポンダの証明書のステータスを調べる。代替的に、この第二の要求を排除するために、トランザクション・コーディネータは、信用取引先か、または他のトランザクション・コーディネータへの応答を送信するときはいつも、（ルートによって署名された）その証明書のステータスを自動的に含んでもよい。

以下の節では、トランザクション・コーディネータのテストを記述する。好ましくは、トランザクション・コーディネータは、本節において列挙された項目に関してテストされる。

構造的な柔軟性を与えるために、トランザクション・コーディネータは、好ましくは、一つ以上のハードウェア・プラットフォーム（例えば、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ ＮＴ（登録商標）４．０／２０００、Ｓｕｎ Ｓｏｌａｒｉｓ およびＨｅｗｌｅｔｔ Ｐａｃｋａｒｄ ＨＰ−ＵＸ）にポートされる。これによって関係先は、サポートされたプラットフォームのリストから、自らのハードウェア・プラットフォームを選択することができる。好ましくは、トランザクション・コーディネータが、サポートされたプラットフォームの各々に、円滑にインストールされることを確証するためのテストが実行される。そのような、適切なハードウェアをテストすることを可能にすることが、通常求められる。

好ましくは、トランザクション・コーディネータが、クリーンな（clean）Ｗｉｎｄｏｗｓ ＮＴ（登録商標）マシンにインストールされ、およびアンインストールされることを確証するためのテストが実行される。

トランザクション・コーディネータが、他のオペレーティング・システムをサポートするために拡張される場合、好ましくは、同じソース・コードに由来するエグゼクタブルが、サポートされたオペレーティング・システムのすべてにインストールすることができることを確証するためのテストが実行される。適切なオペレーティング・システムを有する適切なハードウェアは、これらのテストを実行することを求められてもよい。

好ましくは、トランザクション・コーディネータは、他のサード・パーティ・ベンダのソフトウェア・ツールと連携する。これらのソフトウェア・ツールへのインターフェースは、好ましくは、開発およびシステム・テスト段階中、開発サイトでテストされる。さらに、これらのツールとの、トランザクション・コーディネータ・インターフェースが安定していることを確証するために、通常、取引先サイトで複雑なテストが実行される。これは、後述のとおり、取引先／機能テスト中に行われる。

トランザクション・コーディネータの機能は、好ましくは、開発およびシステム・テスト段階中に、テストされる。これらのテスト中、カスタム・リトン・コードのすべてが、少なくとも一回実行されることを確証するために、適切なツールが使用される。他の好ましいテスト段階においては、取引先は、トランザクション・コーディネータの機能をテストする。

セキュリティは、トランザクション・コーディネータの重要な部分である。好ましくは、データが、ある点から他の点に安全に転送されることを確証するためのテストが実行される。好ましくは、パブリック・キー・インフラストラクチャの安全面を総括的にテストするためのテスト・ケースが、作成される。

システム２００内で送信されるメッセージに関するメッセージング・プロトコル定義およびシステム２００に関する証明書ステータス・プロトコル定義は、係属アメリカ合衆国特許仮出願第６０／２３１，３１９号、本出願と同日に出願された、トランザクション・コーディネータ証明書ステータス・チェック（ＣＳＣ）プロトコル定義、トランザクション・コーディネータ・メッセージング・プロトコル定義、およびトランザクション・コーディネータ要件と題された前記出願に記述されており、それは、参照のためにここに統合されている。好ましい実施形態において、各トランザクション・コーディネータは、このメッセージング・プロトコル定義をサポートする。特定的には、各トランザクション・コーディネータは、メッセージング・プロトコル定義で定義されたとおり、すべての有効なＸＭＬメッセージを受信ならびに送信し、誤った形式のメッセージをログしならびに報告し、および要求に応答して、有効なＸＭＬメッセージを生成することができる。

代替的な実施形態において、前記システムは、代わりに、トランザクション・コーディネータ２０２を採用しないＯＣＳＰ中心モデルとして実装される。この代替的実施形態は、通常に、典型的なＯＣＳＰレスポンダによって供給されるよりも、明らかに多くの機能を供給するように適応した、向上したＯＣＳＰレスポンダを採用する。特に、向上したＯＣＳＰレスポンダは、以下の追加的機能を供給するように適応している：
・ ＳＳＬを使用した暗号通信
・ 要求と応答の両方のための、未処理トランザクションのロギング
・ 応答を伴う証明書チェーンの供給
・ 好ましくは、ＨＳＭを使用した、要求への署名の確認
・ 要求を伴う証明書チェーンの認可（その一部は、ローカル・データベースまたはＨＳＭに記憶されていてもよい）
・ 次のものに基づいた新しい要求の作成
・受信された要求の、サービス・ロケータ（service lacator）要求拡張における値
・応答を伴う証明書における、オーソリティ情報アクセス拡張
・応答が、これらの他の新しく作成された要求において受信されるまでの、要求での処理の延期。すなわち、要求への応答を同期させる機能。
・適切なときの、転送の応答
この代替的実施形態は、新しいサービスを追加する柔軟性を与えることなく、証明書ステータス・チェック・サービスの一部のみを供給する。また、請求は、この代替的実施形態においては実行されない。さらに、この代替的実施形態は、ベンダ・ロッキング（vendor locking）を生じさせるかもしれない。この代替的実施形態の賛否両論の詳細が以下に列挙されている。

図１４は、この代替的実施形態のためのトランザクションの流れを示す。図１４におけるメッセージの流れは、以下の表に要約されている：

１ 署名取引先（subscribing customer, ＳＣ）は、署名されたデータ、署名、 ＳＣおよびＩＰ証明書（任意でＣＳＳＤ）を、信用取引先
（relying customer, ＲＣ）に送信する。
２ ＲＣは、ＳＣによって送信されたデータの署名を確認し、ＳＣの証明書チェーンを認可し、それからＳＣ証明書番号を含むＯＣＳＰ要求を作成する。このデータは、署名のために、ＨＳＭに送信される。
３ ＲＣによって署名された、ＳＣの証明書に対するＯＣＳＰ要求は、ＲＣの証明書チェーンとともに、信用関係先（relying participant, ＲＰ）ＯＣＳＰレスポンダ（ＯＲ）に送信される。証明書チェーン全体が、メッセージとともに渡されなければならない。
４ ＲＰ ＯＣＳＰレスポンダは、そのＯＣＳＰログに、要求をログする。
ＲＰ ＯＣＳＰレスポンダは、要求における署名を確認し、およびＲＣの証明書チェーンを認可する。すべての確認はソフトウェアで実行される。チェーン全体（ルートを含む）は、署名／証明書チェーンの確認が実行されるように、メッセージとともに渡されなければならない。ＲＣの証明書が取り消されなかったことを確証するためのチェックは、実行されない。
５ ＲＰ ＯＣＳＰレスポンダは、ＲＣから受信された単一の要求を含む、新しい要求を作成し、そのＨＳＭを用いてそれに署名する。金融機関の間での、署名された要求は、必要とされない。その代わり、ルート・エンティティ（ＲＯＯＴ）は、確認／認可／取引先検索が、ＳＳＬ接続と関連する証明書に基づいているような場合である、ＳＳＬクライアント側認証を要求してもよい。
６ ＲＰ ＯＣＳＰレスポンダは、受信された要求の、サービス・ロケータ要求拡張における値に基づいて、署名されたＯＣＳＰ要求を、適切な発行関係先のＯＣＳＰレスポンダに送信する。
７ ＩＰ ＯＣＳＰレスポンダは、そのＯＣＳＰログに、要求をログする。ＩＰ ＯＣＳＰレスポンダは、要求における署名を検査し、ＲＰ ＯＲの証明書チェーンを認可する。すべての検査はソフトウェアで実行される。チェーン全体（ルートを含む）は、署名／証明書チェーンの検査が実行されるようにするために、メッセージとともに渡されなければならない。
８ ＩＰ ＯＣＳＰレスポンダは、ＲＰ ＯＣＳＰレスポンダの証明書番号を含むＯＣＳＰ要求を作成し、およびそのＨＳＭを用いてそれに署名する。
９ ＩＰ ＯＣＳＰレスポンダはそれから、ステップ４において受信された要求における署名に関連した証明書におけるオーソリティ情報アクセス拡張に基づいて、ＲＯＯＴ ＯＣＳＰレスポンダに要求を送信する。ＩＰ
ＯＣＳＰレスポンダは、ＳＣの証明書における応答を発行する前に、ＲＰ ＯＣＳＰレスポンダの証明書に関するＲＯＯＴからの応答を待つ。ＩＰがＳＳＬクライアント側認証のみを要求し、署名されたＯＣＳＰ要求を求めない場合、このステップは必要ではないかもしれない。
１０ ＲＯＯＴ ＯＣＳＰレスポンダは、そのＯＣＳＰログに、要求をログする。ＲＯＯＴ ＯＣＳＰレスポンダは、要求における署名を確認し、ＩＰ ＯＣＳＰレスポンダの証明書チェーンを認可する。金融機関の間で署名された要求は求められない。その代わり、ＲＯＯＴは、確認／認可／取引先検索が、ＳＳＬ接続に関連する証明書に基づいている場合である、
ＳＳＬクライアント側認証を求めるかもしれない。
１１ ＲＯＯＴ ＯＣＳＰレスポンダは、ＲＰ ＯＣＳＰレスポンダの証明書のステータスを決めるために、そのローカル・データベースを調べ、それから応答を生成し、およびそのＨＳＭを用いてそれに署名をする。
１２ ＲＯＯＴ ＯＣＳＰレスポンダは、それから応答をＩＰ ＯＣＳＰレスポンダに返す。
１３ ＩＰ ＯＣＳＰレスポンダは、そのＯＣＳＰログに、応答をログする。ＩＰ ＯＣＳＰレスポンダは、要求における署名を確認し、およびルートのＯＣＳＰレスポンダ証明書チェーンを認可する。しかしながら、否認防止をサポートするのに十分な情報が、ログに維持されていないかもしれないことが注目される。
証明書チェーン全体は、メッセージとともに渡されなければならない。
１４ ＩＰ ＯＣＳＰレスポンダは、それから、ＳＣの証明書のステータスを決めるために、そのローカル・データベースを調べる。ＩＰ ＯＣＳＰレスポンダは、応答を生成し、およびそのＨＳＭを用いてそれに署名をする。
１５ ＩＰ ＯＣＳＰレスポンダは、署名された応答を、ＲＰ ＯＣＳＰレスポンダに送信する。
１６ ＲＰ ＯＣＳＰレスポンダは、ＯＣＳＰログに、ＯＣＳＰ応答をログする。ＲＰ ＯＣＳＰレスポンダは、応答における署名を確認し、および
ＩＰのＯＣＳＰレスポンダ証明書チェーンを認可する。証明書チェーン全体は、メッセージとともに渡されなければならない。
１７ ＲＰ ＯＣＳＰレスポンダは、ＩＰ ＯＣＳＰレスポンダの証明書の番号を含むＯＣＳＰ要求を作成し、およびそのＨＳＭを用いてそれに署名をする。
１８ ＲＰ ＯＣＳＰレスポンダはそれから、ステップ１４で受信された応答における署名に関連する証明書におけるオーソリティ情報アクセス拡張に基づいて、ＲＯＯＴ ＯＣＳＰレスポンダに要求を送信する。
１９ ＲＯＯＴ ＯＣＳＰレスポンダは、そのＯＣＳＰログに、未処理要求をログする。ＲＯＯＴ ＯＣＳＰレスポンダは、要求における署名を確認し、およびＲＰ ＯＣＳＰレスポンダの証明書チェーン全体を認可する。証明書チェーン全体は、メッセージとともに渡されなければならない。
２０ ＲＯＯＴ ＯＣＳＰレスポンダは、ＩＰ ＯＣＳＰレスポンダの証明書のステータスを決めるために、そのローカル・データベースを調べ、それから応答を生成し、およびそのＨＳＭを用いてそれに署名をする。
２１ ＲＯＯＴ ＯＣＳＰレスポンダは、署名された応答を、ＯＣＳＰレスポンダに送信する。
２２ ＲＰ ＯＣＳＰレスポンダは、そのＯＣＳＰログに、応答をログする。ＲＰ ＯＣＳＰレスポンダは、応答における署名を確認し、およびルートのＯＣＳＰレスポンダ証明書チェーンを認可する。証明書チェーンは、メッセージとともに送信されてもよく、またはチェーンの一部は、ＨＳＭか、または証明書確認データベースにあってもよい。
２３ ＲＰ ＯＣＳＰレスポンダは、それがステップ２において（例えば、一回だけ）受信した情報、およびステップ１４においてそれが受信したＳＣの証明書に関するステータス情報を含むＲＣに関する応答を作成し、およびそのＨＳＭを用いてそれに署名をする。
２４ ＲＰ ＯＣＳＰレスポンダは、ＲＣに応答を返す。
２５ ＲＣは、応答における署名を確認するため、およびＲＰのＯＣＳＰレスポンダ証明書チェーンを認可するために、そのＨＳＭを使用する。証明書チェーンは、メッセージとともに渡されてもよく、またはチェーンの一部がＨＳＭにあってもよい。
２６ ＲＣは、ＩＰの証明書番号を含むＯＣＳＰ要求を作成する。このデータは、署名のために、ＨＳＭに送信される。
２７ ＲＣによって署名された、ＩＰの証明書に対するＯＣＳＰ要求は、ＲＣの証明書チェーンとともに、信用関係先（ＲＰ）
ＯＣＳＰレスポンダ（ＯＲ）に送信される。証明書チェーン全体は、メッセージとともに渡される必要がある。
２８ ＲＰ ＯＣＳＰレスポンダは、そのＯＣＳＰログに、要求をログする。ＲＰ ＯＣＳＰレスポンダは、要求における署名を確認し、およびＲＣの証明書チェーンを認可する。すべての確認はソフトウェアで実行される。チェーン全体（ルートを含む）は、署名／証明書チェーンの確認が実行されるようにするために、メッセージとともに渡されなければならない。
ＲＣの証明書が取り消されなかったことを確証するためのチェックは実行されない。
２９ ＲＰ ＯＣＳＰレスポンダは、ＲＣから受信された単一の要求を含む、新しい要求を作成し、およびそのＨＳＭを用いてそれに署名をする。金融機関の間で署名された要求は、必要とされない。その代わり、ＲＯＯＴは、確認／認可／取引先検索が、ＳＳＬ接続に関連する証明書に基づいている場合である、ＳＳＬクライアント側認証を求めてもよい。
３０ ＲＰ ＯＣＳＰレスポンダは、受信された要求のサービス・ロケータ要求拡張における値に基づいて、署名されたＯＣＳＰ要求を、ＲＯＯＴ
ＯＣＳＰレスポンダに送信する。
３１ ＲＯＯＴ ＯＣＳＰレスポンダは、そのＯＣＳＰログに、要求をログする。ＲＯＯＴ ＯＣＳＰレスポンダは、要求における署名を確認し、およびＲＰ ＯＲの証明書チェーンを認可する。すべての確認は、ソフトウェアで実行される。チェーン全体（ルートを含む）は、署名／証明書チェーンの確認が実行されるようにするために、メッセージとともに渡されなければならない。
３２ ＲＯＯＴ ＯＣＳＰレスポンダは、ＲＰ ＯＣＳＰレスポンダの証明書のステータスを決めるために、そのローカル・データベースを調べ、それから応答を生成し、およびそのＨＳＭを用いて、それに署名する。
３３ ＲＯＯＴ ＯＣＳＰレスポンダはそれから、ＲＰ ＯＣＳＰレスポンダに応答を返す。
３４ ＲＰ ＯＣＳＰレスポンダは、そのＯＣＳＰログに、応答をログする。ＲＰ ＯＣＳＰレスポンダは、応答における署名を確認し、および
ＲＯＯＴのＯＣＳＰレスポンダ証明書チェーンを認可する。否認防止をサポートするのに十分な情報が、ログにないかもしれないことが注目される。証明書チェーン全体は、メッセージとともに渡されなければならない。

このＯＣＳＰ代理中心モデルは、上述のトランザクション・コーディネータ・モデルと比較すると、長所と短所がある。この代替的実施形態の賛否両論は、以下の表に要約されている：

ＯＣＳＰレスポンダ２０４に対する技術的およびセキュリティの要件は、好ましくは、ルート・エンティティ１１０によって特定される。要件の、例示的な一例が、後述されている。

技術的要件
好ましい実施形態において、各ＯＣＳＰレスポンダ２０４は、オンライン証明書ステータス・プロトコル（Online Certificate Status Protocol）（ＯＣＳＰ）にしたがって動作する。

好ましい実施形態において、ＯＣＳＰレスポンダ２０４がＯＣＳＰ要求を受信するとき、リクエスタの証明書を認可し、リクエスタを認証し、およびリクエスタは、リクエスタの証明書にローカル・ステータス・チェックを実行することによって、要求を受信した関係先との、契約したシステム・ユーザであるか確認する。リクエスタの認証は、機関間の要求の場合は、署名したＯＣＳＰ要求を用いて、または、取引先要求の場合は、安全ソケット・レイヤ・クライアント認証を通して達成されてもよい。さらに、安全ソケット・レイヤは、すべての要求の機密性を確証することを求められてもよい。

好ましい実施形態において、各ＯＣＳＰレスポンダ２０４は、要求されたサービスのロケータ拡張およびローカル・テーブルに基づいて機関間要求をする時、ピア・サーバ（peer server）を選択する。代替的実施形態において、この情報は、軽量ディレクトリ・アクセス・プロトコル（ＬＤＡＰ）検索によって得られてもよい。

好ましい実施形態において、各ＯＣＳＰレスポンダ２０４は、ルート・エンティティ１１０によって特定された規則に従った証明書をキャッシュしてもよい。

好ましい実施形態において、各ＯＣＳＰレスポンダ２０４は、機関間応答が、承認されたレスポンダ証明書によって署名されたか確認する。機関間ＯＣＳＰ要求に関して、信用関係先２０４のＯＣＳＰレスポンダは、好ましくは、例えば発行関係先１０２からの応答を、それをリクエスタに送信する前に、再署名する。

好ましい実施形態において、各ＯＣＳＰレスポンダは、以下の応答：“取り消し”、“良”、および“不明”をサポートする。クライアントＯＣＳＰレスポンダが、時間ｔにおいて作られた特定の証明書に関する“取り消された”応答を受信した場合、クライアントＯＣＳＰレスポンダは、前記証明書、または前記証明書の証明書チェーンにおけるある証明書が、時間ｔより前に取り消されたとみなす。そのようなものとして、クライアントＯＣＳＰレスポンダは、チェックされた証明書に対応するプライベート・キーを用いて、時間ｔの後にデジタル署名されたドキュメントに対する責任を、サーバＯＣＳＰレスポンダに移すための、十分な根拠を有しない。

クライアントＯＣＳＰレスポンダが、時間ｔにおいて作られた特定の証明書に関する“良い”応答を受信する場合、クライアントＯＣＳＰレスポンダは、前記証明書およびその証明書チェーンにおける一つおきの証明書が、時間ｔにおいて、すべて支払済み（in good standing）であったとみなす。そのようなものとして、クライアントＯＣＳＰレスポンダは、時間ｔの前にデジタル署名されたドキュメントに関する責任を、サーバＯＣＳＰレスポンダに移すのに十分な根拠を有する。

クライアントＯＣＳＰレスポンダは、時間ｔにおいて作られた特定の証明書に関する“不明”応答を受信した場合、クライアントＯＣＳＰレスポンダは、前記証明書、または前記証明書の証明書チェーンにおける一つの証明書が、すべて支払済みであるか、不明であるとみなす。そのようなものとして、クライアントＯＣＳＰレスポンダは、チェックされた証明書に対応するプライベート・キーを用いてデジタル署名されたドキュメントに関する責任を、サーバＯＣＳＰレスポンダに移すのに十分な根拠を有していない。

セキュリティ要件
好ましい実施形態において、各ＯＣＳＰレスポンダ２０４は、そのプライベート・キーを、ルート・エンティティ１１０によって確立された要件に適合するハードウェア・セキュリティ・モジュールに記憶する。

好ましい実施形態において、各ＯＣＳＰレスポンダ２０４は、サーバ安全ソケット・レイヤ、クライアント安全ソケット・レイヤおよびＯＣＳＰ応答に対して別個のキーを使用する。
好ましい実施形態において、各ＯＣＳＰレスポンダ２０４は、機関によって強くなったプラットフォーム・コンフィギュレーションで動作することができる。機関が強化したプラットフォームは、機関のファイアウォール内の使用に関して承認された、試験をし、およびテストをしたプラットフォームである。
好ましい実施形態において、各ＯＣＳＰレスポンダ２０４は、すべての署名された要求および応答、すべての例外またはエラー、およびすべての管理およびコンフィギュレーション動作の詳細なログを維持する。
好ましい実施形態において、各ＯＣＳＰレスポンダ２０４は、すべての管理トランザクションに対してエンティティを認証するために、安全ソケット・レイヤ・クライアント認証等、強い認証を使用する。
好ましい実施形態において、各ＯＣＳＰレスポンダ２０４は、ルート・エンティティ１１０によって確立された、最小限のセキュリティ要件に適合する。さらに、ＯＣＳＰレスポンダを維持する機関は、追加のＯＣＳＰレスポンダ・セキュリティ規則を特定してもよい。
好ましい実施形態において、各ＯＣＳＰレスポンダ２０４は、反復した方法で、高度に利用可能で、および採用可能になるように構成される。さらに、各ＯＣＳＰレスポンダは、好ましくは、1秒より少ない時間で、すべての要求に応答する。
ＯＣＳＰレスポンダは、通常、ユーティリティ証明書のチェックを実行することを求められない。しかしながら、ＯＣＳＰレスポンダは、リクエスタに、ユーティリティ証明書のステータスへの、認証されていないアクセスを許可するように構成されているかもしれない。
好ましい実施形態において、各ＯＣＳＰレスポンダは、機関のレポジトリへの認証されたインターフェースとして機能するように求められるかもしれない。この好ましい実施形態の実装の詳細は、ＯＣＳＰレスポンダを維持するエンティティに委ねられてもよい。

好ましい実施形態において、各ＯＣＳＰレスポンダは、追加機能をサポートするための追加インターフェースを具備する。特に、各ＯＣＳＰレスポンダは、好ましくは、情報を、関係先の顧客サービス要件をサポートするために利用可能にするための、追加インターフェースを具備する。さらに、各ＯＣＳＰレスポンダは、好ましくは、システムおよびイベント・ログを外部に出すための、機関によって定義された標準インターフェースを具備してもよい。各ＯＣＳＰレスポンダはまた、請求アプリケーションのための情報を外部に出すためのインターフェースを具備してもよい。請求データは、ログを含むあらゆる形式で外部に出されも良いが、好ましくは、リクエスタが、要求の種類およびボリュームを決定することができるようにする。

好ましい実施形態において、図1に記載の関係先１０２、１０４は、ルート・エンティティ１１０によって直接デジタル証明書を発行されるので、レベル１関係先と称される。従って、各関係先の証明書チェーンは、ルート・エンティティ１１０から開始する。各レベル１関係先は、他のレベル１関係先の証明書のステータスを入手するため、ルート・エンティティ１１０に依存する。

さらなる好ましい実施形態において、本システムは、レベル２関係先と呼ばれる、追加的関係先を含んでもよい。各レベル２関係先は、好ましくは、それと関連するレベル１関係先によって、デジタル証明書を発行される。これらレベル２関係先は、それらの別個の取引先に対する認証局として機能し、および前記取引先にシステム・サービスを供給してもよい。

レベル１関係先は、好ましくは、レベル２関係先に対して最高点の信頼を与える。そのようなものとして、レベル２関係先は、好ましくは、彼らの保証となるレベル１関係先に直接報告する。レベル２関係先はまた、他の関係先の証明書のステータスを入手するために、彼らの保証となるレベル１関係先に依存しなければならない。レベル１およびレベル２関係先を含む好ましい実施形態はさらに、係属アメリカ合衆国特許出願第０９／５０２，４５０号、２０００年２月１１日提出、証明関連および他のサービスを供給するためのシステムおよび方法と題した前記出願に記述されており、それは、参照のためにここに統合されている。

好ましい実施形態において、各関係先は、各関係先のハードウェアならびにソフトウェア・コンポーネントの動作環境を識別する、ハードウェアならびにソフトウェア・コンフィギュレーション・ベースラインを集合的に実装しおよび維持する。そのようなものとして、コンフィギュレーション・ベースラインは、システムの日々の動作および管理を容易にするコンフィギュレーション・リファレンス（configuration reference）として機能する。前記ベースラインは、システムワイドなレベルで、一以上の関係先によってなされるコンフィギュレーション変更の統括を容易にする。さらに、ベースラインは、一つ以上の認証局のハードウェアまたはソフトウェア故障の場合に、システムワイドなサービス・リカバリを容易にする。

好ましい実施形態において、本システムの、コンフィギュレーション・ベースラインのマスタ・コピーは、ルート・エンティティ１１０によって維持される。通常、マスタ・コピーは、事業の副社長等、ルート・エンティティ１１０の役員が保持する。

好ましい実施形態において、ルート・エンティティ１１０は、ルート・エンティティ１１０のハードウェアおよびソフトウェア・コンフィギュレーションの、真実の、および正確な記録を保持する。ルート認証局のコンフィギュレーション・ベースラインの少なくとも３のコピーが、以下の三つのロケーションに、ルート・エンティティ１１０によって保持される：（１）ルート認証局と同じ物理的ロケーションであり、それによって動作上の変更が生じたときに、それらが記録されるようにする；（２）ルート認証局の物理的ロケーションの外部にある安全ロケーションであるが、制御されたコンテナである；および（３）ルート・エンティティ１１０のバックアップおよびアーカイブ記録を伴うオフサイト（offsite）・ロケーションである。このハードウェアおよびソフトウェア・コンフィギュレーションの他のコピーは、ルート・エンティティ１１０の判断で、レベル１認証局に供給されてもよい。

好ましい実施形態において、各レベル１関係先は、その認証局アーキテクチャのハードウェアおよびソフトウェア・コンフィギュレーションの、真実であり、かつ正確な記録を維持する。各レベル１関係先は、好ましくは、以下の三つのロケーションに、そのコンフィギュレーション・ベースライン・ドキュメントの少なくとも３のコピーを準備し、保持し、および維持する：（１）レベル１認証局の同じ物理的ロケーションであり、それによって動作上の変更は、それらが生じると記録されるようにする；（２）レベル１認証局の物理的ロケーションの外部である安全ロケーションであるが、制御されたコンテナである；および（３）レベル１認証局のバックアップおよびアーカイブ記録を伴うオフサイト・ロケーションである。さらに、各レベル１関係先は、好ましくは、そのコンフィギュレーション・ベースラインのコピーを、ルート・エンティティ１１０に供給する。
好ましい実施形態において、レベル２関係先も、それらの認証局アーキテクチャのハードウェアおよびソフトウェア・コンフィギュレーションの真実の、および正確な記録を維持する。各レベル２関係先は、以下の三つのロケーションにおいて、そのコンフィギュレーション・ドキュメントの、少なくとも三つのコピーを準備し、保持し、および維持する：（１）レベル２認証局と同じ物理的ロケーションであり、それによって、動作上の変更が生じたときに、それらが記録されるようにする；（２）レベル２認証局の物理的ロケーションの外部にある安全ロケーションであるが、制御されたコンテナである；および（３）レベル２認証局のバックアップおよびアーカイブ記録を伴うオフサイト・ロケーションである。さらに、各レベル２関係先は、好ましくは、そのコンフィギュレーション・ベースラインを、その保証しているレベル１認証局に供給する。

ハードウェアおよびソフトウェア・コンフィギュレーションの文書化を容易にするための形式が供給されてもよい。好ましい実施形態において、ルート・エンティティ１１０の、ならびに各関係先の認証局ディレクトリ、ＯＣＳＰレスポンダ、およびインターネット・ファイアウォールのハードウェアならびにソフトウェア・コンフィギュレーションも、文書化される。

好ましい実施形態において、ルート・エンティティ１１０は、システム・ワイド・レベルでの、コンフィギュレーション管理に対する重要な責任を有する。この責任は通常、事業の副社長等、ルート・エンティティ１１０の役員に委任される。各認証局は、好ましくは、認証局のハードウェアおよびソフトウェア・コンフィギュレーションの正確な記録を維持することに対する、操作上の責任を有する技術操作スタッフを有する。

好ましい実施形態において、各認証局の初期コンフィギュレーション・ベースラインは、各下位認証局のコンフィギュレーション・ベースラインを託すことによって、作られる。

好ましい実施形態において、コンフィギュレーション変更は、以下の基準に従わなければならない：（１）コンフィギュレーション変更は、定義されたシステム要件に取り組むことを求められなければならない；（２）コンフィギュレーション変更は、認証局のオペレーション・スタッフによって推奨されなければならない；（３）オペレーショナル・プラットフォームのコンフィギュレーション変更は、ルート・エンティティの場合には、事業の副社長等、役員によって、およびレベル１またはレベル２認証局の場合には、認証局の完全性に対して責任がある最高幹部によって承認されなければならない；（４）コンフィギュレーション変更の通知は、影響のある当事者に対して行われなければならない；（５）コンフィギュレーション変更は、統治または基準設定機関によって示される、関連するコンフィギュレーション変更基準を考慮しなければならない；および（６）コンフィギュレーション変更は、変更日および前のコンフィギュレーションの各々の期間を公表することによって、記録されなければならない。各認証局は、通常、バックアップ・テープ等、他の保管された素材とともに、コンフィギュレーション変更を保管する。

好ましい実施形態において、コンフィギュレーション・ベースラインは、ルート・エンティティのシステム・セキュリティ・ポリシーと関連して実装され、および各認証局の監査されたコンポーネントである。

本発明は、特定の実施形態との関係において記述されてきたが、数多くの代替例、変更および変形が、前述の説明に照らして、当業者には明らかであることが明白である。

Claims (1)

1. 電子ネットワークを介して証明書ステータスチェックサービスを実行する方法であって、前記方法は、
   （ａ）信用取引先から、信用関係先の取引コーディネータにおいて、前記信用取引先からのサービス要求を受信するステップであって、前記サービス要求は、申込取引先の証明書によってデジタル署名されたドキュメントを含み、発行関係先の証明書を添付したものであり、前記サービス要求は、信用取引先の証明書でデジタル署名されており、前記サービス要求に信用関係先の証明書及びルート認証局のパブリック・キーを添付しているものであるステップであって、前記サービス要求を前記信用関係先の前記取引コーディネータに送信する前に、前記信用取引先の取引コーディネータが前記署名されたドキュメントへの前記申込取引先の署名を確認し、前記申込取引先の証明書及び前記発行関係先の証明書を含んだ前記サービス要求を生成し、ハードウェアセキュリティモジュールを使用して前記サービス要求に署名し、前記信用取引先の証明書に添付するものであるステップと、
   （ｂ）前記信用関係先の取引コーディネータが取引先データベースをチェックし、前記サービス要求が既存の信用取引先によって署名されたことを前記要求を処理する前に確認し、前記サービス要求が既存の信用取引先によって署名された場合に、
   （ｃ）前記信用関係先の取引コーディネータが、
   （ｉ）前記信用取引先の証明書及び前記信用関係先の証明書及び前記ルート認証局のパブリック・キーを使用して前記信用取引先の前記サービス要求への署名を確認し、
   （ｉｉ）前記申込取引先の証明書を確認するための要求を生成し、前記要求に署名をし、前記要求を前記信用関係先の証明書と共に前記発行関係先に送り、
   （ｉｉｉ）前記発行関係先から応答を受信し、前記発行関係先の証明書及び前記ルート認証局のパブリック・キーを使用して前記応答の署名を確認し、前記発行関係先の証明書をルート取引コーディネータから要求し、前記発行関係先からの前記応答は、前記発行関係先の取引コーディネータが取引先データベースをチェックし、前記申込取引先が前記申込取引先の電子証明書の確認の要求を行うことを認可されたエンティティであることを確認した場合になされるものであり、
   （ｉｖ）前記ルート取引コーディネータから応答を受信し、前記信用取引先のための前記サービス要求に対する応答を生成し、前記応答に署名し、前記応答を前記信用関係先の証明書と共に信用取引先に送る、ステップと、を備えた方法。

Images