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

証明書確認及び他のサービスを提供するためのシステム及び方法

Info

Publication number
JP2003509746A
JP2003509746A JP2001522463A JP2001522463A JP2003509746A JP 2003509746 A JP2003509746 A JP 2003509746A JP 2001522463 A JP2001522463 A JP 2001522463A JP 2001522463 A JP2001522463 A JP 2001522463A JP 2003509746 A JP2003509746 A JP 2003509746A
Authority
JP
Japan
Prior art keywords
certificate
party
request
transaction coordinator
transaction
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2001522463A
Other languages
English (en)
Other versions
JP5275536B2 (ja
Inventor
デイヴィッド ソロ
マック ヒックス
マーク スターランド
ラリー ネポムセノ
チャールズ ダリン
Original Assignee
デイヴィッド ソロ
マック ヒックス
マーク スターランド
ラリー ネポムセノ
チャールズ ダリン
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by デイヴィッド ソロ, マック ヒックス, マーク スターランド, ラリー ネポムセノ, チャールズ ダリン filed Critical デイヴィッド ソロ
Publication of JP2003509746A publication Critical patent/JP2003509746A/ja
Application granted granted Critical
Publication of JP5275536B2 publication Critical patent/JP5275536B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

(57)【要約】 証明書認可および保証を含む、証明書関連および他のサービスを安全に供給することにより、電子商取引を容易にするためのシステムおよび方法が開示される。サービスは、四角トラスト・モデルで供給される。四角モデルは、バイヤー（１０６）すなわち署名取引先、およびセラー（１０８）すなわち信用取引先を含み、それらはオンライン・トランザクションに関与する。バイヤーは、第一の金融機関（１０２）の取引先、すなわち発行関係先であり、ハードウェア・キーならびに関連するプライベート・キーおよび署名されたデジタル証明書を発行する認証局である。セラーは、第二の金融機関（１０４）の取引先、すなわち信用関係先であり、それも、ハードウェア・キーならびに関連するプライベート・キーおよび署名されたデジタル証明書を発行する認証局である。

Description

【発明の詳細な説明】
【０００１】 （関連出願の説明） 本発明は、１９９９年９月１３日出願の米国仮特許出願第６０／１５３，７２
６号「Ｔｒａｎｓａｃｔｉｏｎ Ｃｏｏｒｄｉｎａｔｏｒ ｆｏｒ Ｃｅｒｔｉ
ｆｉｃａｔｅ Ｓｔａｔｕｓ Ｃｈｅｃｋｉｎｇ ａｎｄ Ｏｔｈｅｒ Ｓｅｒ
ｖｉｃｅｓ」、１９９９年９月１３日出願の米国仮特許出願第６０／１５３，７
２４号「Ｔｒａｎｓａｃｔｉｏｎ Ｃｏｏｒｄｉｎａｔｏｒ Ｒｅｑｕｉｒｅｍ
ｅｎｔｓ ａｎｄ Ｈｉｇｈ Ｌｅｖｅｌ Ｄｅｓｉｇｎ」、及び１９９９年９
月１０日出願の米国仮特許出願第６０／１５３，２０３号「Ｓｙｓｔｅｍ ａｎ
ｄ Ｐｒｏｃｅｓｓ ｆｏｒ Ｃｅｒｔｉｆｉｃａｔｉｏｎ ｉｎ Ｅｌｅｃｔ
ｒｏｎｉｃ Ｃｏｍｍｅｒｃｅ」の優先権を主張し、これらの開示内容は、引用
により本明細書に組み込まれている。
【０００２】 （技術分野） 本発明は、一般的に、公開鍵インフラストラクチャーによるサービスを提供す
ることによって、電子商取引を容易にする技術分野に関する。
【０００３】 （背景技術） 電子商取引の世界では、契約当事者間の関係を証明する新しい試みがなされて
きた。これらの試みは、当事者は取引に関して互いに顔を合わせたり声を聞いた
りできず、又は簡単に互いの身元や取引の権限を確認できないことから行われて
いる。 この問題に対する１つの解決策は、各々の契約当事者に、送信メッセージに署
名するための秘密鍵を与えることである。署名した当事者は、当事者の秘密鍵を
署名したメッセージを復号化する関連の公開鍵を利用できるようにするので、受
け取った当事者は、送信者の身元を確認できる。
【０００４】 しかし、送信者の公開鍵は、受信者には先験的に分からない場合がある。この
場合、送信者は証明機関から発行されるデジタル証明書を署名付きメッセージと
一緒に送信できる。証明書は、それ自身、特定の公開鍵が送信者の公開鍵である
ことを証明する、署名付き電子文書（証明機関の秘密鍵を署名した）である。 時として、受信者は、認証機関の公開鍵に慣れていない場合があり、又は受信
者は、証明書が依然として有効か否かが分からない場合がある。この場合、受信
者は、信任をおこなうエンティティを用いて証明書の信憑性と有効性を調べよう
とする。公知の１つのプロトコルとして、証明書のステータスを調べるためのオ
ンライン証明書ステータスプロトコル（ＯＣＳＰ）がある。
【０００５】 （発明の開示） 本発明は、証明書の検証及び保証を含む証明書関連サービス及び他のサービス
を安全に提供することによって、電子商取引を容易にするシステム及び方法を開
示する。好適な実施形態において、このサービスは、４コーナー信用モデルのコ
ンテキスト内で提供される。４コーナーモデルは、オンライン取引に従事する、
署名取引先(subscribing customer)と呼ばれる買い手と、信用取引先(relying c
ustomer)と呼ばれる売り手とを含んでいる。買い手は、発行関係先(issuing par
ticipant)と呼ばれる第１の金融機関の取引先である。発行関係先は、買い手の
証明機関としての機能を果たし、買い手に秘密鍵及び発行関係先が署名したデジ
タル証明書を含むハードウェア・トークンを発行する。売り手は、信用関係先(r
elying participant)と呼ばれる第２の金融機関の取引先である。信用関係先は
、売り手に対する証明機関としての機能を果たし、買い手に秘密鍵及び信用関係
先が署名したデジタル証明書を含むハードウェア・トークンを発行する。
【０００６】 取引時に、買い手は、取引データ・ハッシュを生成し、ハッシュに署名し、売
り手に取引データ、署名、及びそのデジタル証明書を送る。次に、売り手は、金
融機関、信用関係先との通信によりシステムサービスを要求できる。
【０００７】 好適な実施形態において、本システムサービスは、証明書ステータス照合サー
ビス及び保証サービスを含むことができる。証明書ステータス照合サービスによ
り、信用関係先は、署名取引先の証明書を検証できる。保証サービスにより、信
用取引先は、署名取引先の証明書が有効であるという担保裏書保証を受け取る。
これらのサービスを提供する詳細なメッセージフローは以下の詳細な説明に示さ
れている。
【０００８】 好適な実施形態において、各々の関係先及びルート・エンティティ(root enti
ty)は、サービス及び業務を、原子性、一貫性、独立性、及び耐久性の特性をも
つ単一の取引と組み合わせるための取引コーディネーター（トランザクション・
コーディネータ）に提供される。取引コーディネーターは、他のサービスに関連
するメッセージ及びリクエストと同時に、証明書ステータスメッセージ及びリク
エストに関する、単一の一貫性のあるインターフェイスを提供する。結果として
、本発明は、必要な柔軟性を提供し、検査及び否認防止目的のための複数の提示
サービスに関連する取引情報の集中的且つ一貫性のある取得を可能にする。更に
、本発明は、付加的サービスの統合化と、それらのサービスを取引先に提供する
ことを容易にする。
【０００９】 本発明の取引コーディネーターは、単一のインターフェイスを備え、銀行間又
は他の金融機関間の、又は、銀行又は金融機関と取引先との間の電子商取引を容
易にするようになっている。また、取引コーディネーターは、取引先に対する単
一の入口点を提供して証明書照合サービスを得るようになっており、更に柔軟性
を提供して、単一の入口点を提供しながら保証サービス、支払いサービス、又は
証明付きメールサービス等の新規なビジネス用途を付加するようになっている。
生成された付加的サービスをサポートするために、容易に拡張できるよう設計さ
れることが好ましい。
【００１０】 本発明の取引コーディネーターは、現行のメッセージインフラストラクチャに
対する解析、フロー制御、エラー処理を提供し、適切なシステムサービスに対す
るメッセージコンポーネントの手順を指示するためのメッセージスイッチとして
の機能を果たす（例えば、ＯＣＳＰ応答システム、保証エンジン等）。更に、取
引コーディネーターは、これらのサービスからの応答を統合された応答に順序正
しくまとめ、応答を要求クライアントに送る。
【００１１】 また、本発明の取引コーディネーターは、証明書照合サービス又は他のサービ
スに関する請求書発行データを集中的な一般方式で記録する。全ての銀行及び他
の金融機関には、請求書発行に対する要求があるので、請求書発行データは、書
き込み単純抽出機能よって、個々の金融機関のニーズに合わせて抽出及び修正で
きるようになっている。
【００１２】 また、本発明の取引コーディネーターでは、銀行又は他の金融機関は、必要に
応じて異なる形式の取引に対して互いに相互課金を行うことができる。更に、本
発明の取引コーディネーターでは、市販規格品のソフトウエア・アプリケーショ
ンを組み込むことができ、電子的に署名して文書を証明するための単一の電子署
名サービスを提供できる。
【００１３】 更に、本発明の取引コーディネーターは、全ての主要サービスを分離するので
、コンポーネントの再利用を容易にして、これらのサービスの保守及び機能強化
を単純化する。本発明の取引コーディネーターは、それを非標準にさせてベンダ
ー固定と実行遅れをもたらすこともある、オンライン証明書照合機能性の交換を
必要としない。 本発明の前述及び他の目的、特徴、及び利点は、以下の詳細な説明及び添付図
面を参照することにより理解できる。
【００１４】 （発明を実施するための最良の形態） 本発明は、金融機関が取引先に対して電子証明書ステータス照合及び他のサー
ビスを安全に実行することを容易にするシステムに関する。好適な実施形態にお
いて、本発明のシステムは、これらのサービスを提供するためのコーナー信用モ
デルを使用する。図１は、本発明で使用する４コーナー信用モデルの好適な実施
形態を示す。 図１に示すように、４コーナーモデルは、第１の機関１０２と第２の機関１０
４とを含んでいる。第１の機関１０２は、本システムの関係先であり、取引先に
スマートカードを発行するという理由で、以下では「発行関係先」と呼ぶ。第２
の機関１０４は、本システムの関係先であり、取引先は発行関係先１０２及び発
行関係先１０２の取引先によってなされる表示を信用するという理由で、以下で
は「信用関係先」と呼ぶ。
【００１５】 また、図１には、第１の取引先１０６と第２の取引先１０８とが示されている
。第１の取引先１０６及び第２の取引先１０８は、それぞれ発行関係先１０２及
び信用関係先１０４の取引先であることが好ましい。第１の取引先１０６は、発
行関係先１０２により提供されるサービスに署名するという理由で「署名取引先
」と呼ぶ。第２の取引先１０８は、発行関係先１０２及び署名取引先１０６によ
ってなされる表示を信用するという理由で、「信用取引先」と呼ぶ。
【００１６】 また、図１には、ルート・エンティティ１１０が示されている。ルート・エン
ティティ１１０は、典型的には、電子商取引及び電子通信を容易にするための運
用ルールの共通セットを制定して施行する組織である。ルート・エンティティ１
１０は、運用ルールに従うことに同意した複数の銀行及び／又は他の金融機関が
共同保有できる。このようなルート・エンティティの例示的な１つの実施形態は
、２０００年２月１１日に出願された係属中の米国特許出願第０９／５０２，４
５０号「Ｍｅｔｈｏｄ ｆｏｒ Ｃｅｒｔｉｆｉｃａｔｉｏｎ−Ｒｅｌａｔｅｄ
ａｎｄ Ｏｔｈｅｒ Ｓｅｒｖｉｃｅｓ」に説明されており、その開示内容は
、引用により本明細書に組み込まれている。
【００１７】 図２は、４コーナーモデルのエンティティに設けるのが好ましいコンポーネン
トを示すブロック図である。図２に示すように、関係先１０２、１０４及びルー
ト・エンティティ１１０の各々は、本システムが提供するサービスに関連する、
全てのエンティティ間のメッセージを送受信するためのゲートウェイとして機能
する、取引コーディネーター２０２を備えている。以下に更に詳細に説明するよ
うに、取引コーディネーター２０２は、発行関係先１０２及び信用関係先１０４
のオンラインサービスに対する単一のインターフェイスと、取引コーディネータ
ー２０２と４コーナーモデルの他のエンティティとの間の安全な電子通信を保証
するのに必要な装置用安全機能とを備えている。取引コーディネーター２０２の
１つの好適な実施形態を図３から図６を参照して以下に詳細に説明する。
【００１８】 関係先１０２、１０４及び信用関係先１０４の各々は、更にＯＣＳＰレスポン
ダ２０４及びハードウェア・セキュリティ・モジュール（ＨＳＭ）２０６を備え
ることが好ましい。ＯＣＳＰレスポンダ２０４に関する例示的な要件を以下に説
明する。ＨＳＭ２０６は、図６を参照して以下に説明するように、メッセージに
署名を行い、メッセージに対する署名を証明するようになっている。
【００１９】 更に、関係先１０２、１０４及び信用関係先１０４の各々は、請求書発行デー
タ・データベース２０８（関係先１０２、１０４の場合は、銀行の請求書発行ア
プリケーション２１０に接続される）、未処理取引ログ２１２、取引先データ・
データベース２１４、リスクマネージャ２１６（取引先データ・データベース２
１４に接続される）、及び第２のハードウェア・セキュリティ・モジュール２１
８を更に備えることが好ましく、それぞれ取引コーディネーター２０２に接続さ
れている。
【００２０】 図２に示すように、信用取引先１０８は、インターネットを介して情報を送受
信するようになったＷｅｂサーバー２２０を更に備えることが好ましい。信用取
引先１０８は、以下に詳細に説明するように、信用関係先１０４と通信を行うた
めの銀行インターフェイス２２２を更に備えることが好ましい。銀行インターフ
ェイス２２２（信用関係先に設けるのが好ましい追加コンポーネントと同様に）
の１つの好適な実施形態は、本出願と同時出願の係属中の米国特許出願番号０９
／６５７，６０４号「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｆａｃｉ
ｌｉｔａｔｉｎｇ Ａｃｃｅｓｓ Ｂｙ Ｓｅｌｌｅｒｓ ｔｏ Ｃｅｒｔｉｆ
ｉｃａｔｅ−Ｒｅｌａｔｅｄ ａｎｄ Ｏｔｈｅｒ Ｓｅｒｖｉｃｅｓ」に説明
されており、その開示内容は、引用により本明細書に組み込まれている。信用取
引先１０８は、システムメッセージに署名及び証明を行うためのハードウェア・
セキュリティ・モジュール２３０を更に備えることが好ましい。
【００２１】 図２に示すように、署名取引先１０６は、以下に説明するように、インターネ
ットを見るためのＷｅｂブラウザ２２４と、デジタルメッセージを署名するため
のスマートカード２２６（及び関連の読み取り装置）を備えことが好ましい。 好適な実施形態において、各々のシステムエンティティは、認証を容易にする
ために、身元証明書（保証証明書と呼ぶ場合もある）と、ユーティリティ証明書
である２つのデジタル証明書（及び関連の秘密鍵）を備えることが好ましい。更
に、好適な実施形態において、各々の取引コーディネーター２０２は、自身の身
元証明書、実用証明書、及び関連の秘密鍵を備えることが好ましい。
【００２２】 身元秘密鍵は、電子商取引の内容に対するエンティティの契約責務の証拠とし
てルート・エンティティ１１０が要求する電子署名を生成するのに利用される。
証明書チェーンは、この鍵を使用する操作をサポートするのに必要である。以下
に説明するように、身元証明書のステータスは、認証エンティティが取得しても
よい。
【００２３】 ユーティリティ秘密鍵は、追加的取引のセキュリティを与える電子署名を生成
するのに利用される。典型的に、ユーティリティ秘密鍵は、セキュア・ソケット
・レイヤー（ＳＳＬ）をサポートするために、Ｓ／ＭＩＭＥメッセージに署名す
るために、及び他のユーティリティ・アプリケーションのために使用される。ま
た、認証チェーンは、ユーティリティ秘密鍵を使用する操作をサポートするため
に必要である。しかし、ユーティリティ証明書のステータスは、リクエスタには
利用できなくてもよい。本明細書の全範囲にわたって、用語「証明書」は、特に
断らない限り身元証明書を呼ぶ。
【００２４】 好適な実施形態において、署名取引先１０６のデジタル証明書及び関連の秘密
鍵は、発行関係先１０２から署名取引先に与えられる。発行関係先１０２は、署
名取引先１０６に対して、少なくとも署名取引先の身元証明書に関連する秘密鍵
を含むスマートカード又は他の適切な手段を発行することが好ましい。所望であ
れば、スマートカードは、同様に署名取引先の身元証明書を含んでいてもよい。
スマートカードに関する好適な仕様、その製造方法、及びその内容は、２０００
年８月１４日に出願された係属中の米国特許仮出願第６０／２２４，９９４号「
Ｓｉｇｎｉｎｇ Ｉｎｔｅｒｆａｃｅ Ｒｅｑｕｉｒｅｍｅｎｔｓ， Ｓｍａｒ
ｔ Ｃａｒｄ Ｃｏｍｐｌｉａｎｃｅ Ｒｅｑｕｉｒｅｍｅｎｔｓ， ａｎｄ
Ａｄｄｉｔｉｏｎａｌ Ｄｉｓｃｌｏｓｕｒｅ」に説明されており、その開示内
容は、引用により本明細書に組み込まれている。
【００２５】 図３は、取引コーディネーター２０２の好適な実施形態を示すブロック図であ
る。図３に示すように、取引コーディネーター２０２は、２つのコンポーネント
、即ちＴＣリクエストマネージャ３０４と転送サービスコンポーネント３０６と
を有するインターフェイス３０２を備えている。インターフェイス３０２は、複
数のサービスモジュール３０８及びコア・コンポーネント３１０との間で送受信
を行う。サービスモジュール３０８は、証明書ステータス照合モジュール３１２
、保証モジュール３１４、支払い保証サービス３１６、及び他のサービス３１８
を含むことが好ましい。コア・コンポーネント３１０は、ロギングコンポーネン
ト３２０、請求書発行コンポーネント３２２、及び署名コンポーネント３２４を
含むことが好ましい。
【００２６】 転送サービスコンポーネント３０６は、取引コーディネーターへの単一の入口
点を備え、リクエスタ、取引コーディネーターのサービスモジュール、及びコア
・コンポーネントとの間の分離レイヤーとしての機能を果たす。ＴＣリクエスト
マネージャ３０４は、以下に詳細に説明するように、転送サービスコンポーネン
ト３０６からのサービスリクエストを受け取り、それを適切なサービスモジュー
ル及び／又はコア・コンポーネントへ転送する。
【００２７】 証明書ステータス照合モジュール３１２の機能は、図２におけるシステム内の
エンティティの証明書を検証することである。保証モジュール３１４の機能は、
特定のビジネス取引に関連する電子通信に署名を行うエンティティの身元を保証
することである。好適な実施形態において、保証を行う典型的には発行関係先１
０２である関係先は、署名取引先の秘密鍵により生成されるデジタル署名を署名
取引先１０６が履行しなかったことが判明した場合に、いくらかの又は全ての取
引金額に対する金融上の責任を引き受ける。
【００２８】 支払い保証サービス３１６の機能は、信用取引先１０８に署名取引先１０６の
金融債務の履行能力に関する即時確認を提供することによって、取引に関連する
リスクを更に低減することである。更に、発行関係先１０２は、何らかの理由で
署名取引先１０６が信用取引先１０８への支払いを滞納した場合に、いくらか又
は全ての取引金額に対する支払い保証を発行してもよい。また、支払いサービス
は、本出願と同日に出願された係属中の米国特許出願第０９／６５７，６２２号
「Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｐｒｏｖｉｄｉｎｇ Ｐａｙ
ｍｅｎｔ Ｓｅｒｖｉｃｅｓ ｉｎ Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｍｍｅｒｃｅ
」に説明されているようにして行ってもよく、この開示内容は、引用により本明
細書に組み込まれている。
【００２９】 証明付きメールサービス３１８の機能は、オフライン取引をサポートするもの
である。オフライン取引は、即座にリクエストを提供する代わりに、受信エンテ
ィティがリクエストを処理待ち行列状態で出す場合に起こる。典型的に、受信確
認通知は、リクエスタに送信される。このシナリオは、取引量が非常に多く、全
てのリクエストに対してオンライン応答を行うことができない場合に実行される
ことが好ましい。証明付きメールサービス３１８は、信用取引先１０８と信用関
係先１０４との間、信用関係先１０４と発行関係先１０２との間、及び任意のル
ート・エンティティ１１０間のリクエストを満たすために使用することが好まし
い。
【００３０】 ロギングコンポーネント３２０の機能は、否認防止及びセキュリティ検査を目
的として、未処理の取引ログ５８（図５参照）における全てのサービスリクエス
ト及びＯＣＳＰ応答を記録することである。 請求書発行コンポーネント３２２は、取引コーディネーター２０２が受け取っ
たメッセージ（応答及びリクエスト）に対する請求書発行履歴を生成して格納す
ることである。このモジュール及びコンポーネントの好適な操作を以下に詳細に
説明する。
【００３１】 図４は、ブロック図／フローチャートを組み合わせたものであり、好適な実施
形態における取引コーディネーター操作を示す。図４に示すように、ステップ４
００２で、取引コーディネーター２０２の転送サービスコンポーネント３０６は
、他のシステムエンティティからのサービスリクエストを受け取り、リクエスト
マネージャ３０４にそのサービスを転送する。ステップ４００２で、リクエスト
マネージャ３０４は、サービスリクエスト形式が有効か否かを照合する。サービ
スリクエスト形式が有効である場合、メッセージ検証モジュール４０４を呼び出
してリクエスタ、請求書発行データ、及びサービスリクエスト形式に関する情報
を要求する。メッセージ検証モジュール４０４は、解析モジュール４０６を呼び
出して未処理サービスリクエストから関連情報を抽出する。
【００３２】 ステップ４００６で、リクエストマネージャ３０４は、認証モジュール４０８
を呼び出してリクエスタを認証する。認証モジュール４０８は以下に詳細に説明
する。 ステップ４００８で、認証モジュール４０８は、取引コーディネーター２０２
の署名コンポーネント３２４を呼び出して、即ちハードウェア２１８を呼び出し
てリクエスタを認証する。署名コンポーネント３２４の好適な構造及び操作は以
下に詳細に説明する。 ステップ４０１０で、認証モジュール４０８は、証明書ステータス照合モジュ
ール４１４を呼び出し、次にＯＣＳＰレスポンダ２０４を呼び出してリクエスタ
に関する証明書ステータス照合を行う。証明書ステータス照合モジュール４１４
の好適な構造及び操作を以下に詳細に説明する。
【００３３】 ステップ４０１２で、認証モジュール４０８は、取引先認証照合モジュール４
１８を呼び出し、リクエスタが認定されていることを検証してサービスリクエス
トを出す。取引先認証照合モジュール４１８の好適な構成及び操作を以下に詳細
に説明する。 ステップ４０１４で、リクエストマネージャ３０４は、提供されたサービスに
対する適切な請求書に必要な、任意の請求書発行データを請求書発行コンポーネ
ント３２２に送り、請求書発行ログへ記録する。
【００３４】 ステップ４０１８で、リクエストマネージャ３０４は、サービスリクエストを
サービスリクエストルータ４２６へ送る。ステップ４０２０で、サービスリクエ
ストルータ４２６は、適切なサービスモジュール３０８を呼び出してリクエスト
を実行する。 ステップ４０２２で、サービスリクエストルータ４２６は、ステップ４０２０
で呼び出したサービスモジュールからサービス応答を受け取る。サービスリクエ
ストルータ４２６は、サービス応答をリクエストマネージャ３０４へ戻し、次に
サービス応答を転送サービスコンポーネント３０６へ送る。転送サービスコンポ
ーネント３０６は、サービス応答を、サービスリクエストを作るエンティティへ
送る。
【００３５】 図５は、署名コンポーネント３２４の好適な操作を示すブロック図／フローチ
ャートを組み合わせたものである。署名コンポーネント３２４は、スマートカー
ド及びハードウェア・セキュリティ・モジュール等の種々の署名手段に対して単
一のインターフェイスを備え、暗号化処理を用いて署名を証明することが好まし
い。 図５において、ステップ５００２で、署名コンポーネント３２４は、リクエス
トを受け取ると、署名リクエストであるか又は検証リクエストであるかを決定す
る。検証リクエストの場合、署名コンポーネント３２４は、検証リクエストをハ
ードウェア・セキュリティ・モジュール２１８へ送る（ステップ５００４）。ス
テップ５００８で、ハードウェア・セキュリティ・モジュール２１８は、このリ
クエストに応答して検証を行い、署名検証応答を署名コンポーネント３２４へ戻
す。
【００３６】 リクエストが文書への署名である場合、署名コンポーネント３２４は、署名に
関するリクエスト（これは署名を行う文書を含む必要がある）をハードウェア・
セキュリティ・モジュール２１８へ送る（ステップ５００６）。ステップ５０１
０で、ハードウェア・セキュリティ・モジュール２１８は、このリクエストに応
答して文書に署名し、署名付き文書を署名コンポーネント３２４へ戻す。最後に
、ステップ５０１２で、署名コンポーネント３２４は、署名−検証応答又は署名
付き文書を、リクエストを行ったコンポーネントへ戻す。
【００３７】 図６は、証明書ステータス照合を実行する場合に取引コーディネーター２０２
が実行するステップの好適な操作を示すブロック図／フローチャートを組み合わ
せたものである。ステップ６００２で、証明書照合サービスモジュール３１２は
、サービスリクエストルータ４２６から未解析の証明書ステータス照合リクエス
トを受け取り、それをリクエストに応じて関連の取引先情報（照合すべき証明書
を含む）を抽出する解析コンポーネント４０６へ送る。ステップ６００４で、証
明書照合サービスモジュール３１２は、取引先データベース６０６から任意の追
加サービス仕様実行情報を取得する。
【００３８】 ステップ６００６で、照合すべき証明書が、取引コーディネーター２０２がリ
クエストを受け取った関係先の取引先に属する場合、証明書照合サービスモジュ
ール３１２は、リクエストをローカル取引先ハンドラ６０２に引き渡す。そうで
なければ、証明書照合サービスモジュール３１２は、リクエストを非ローカル取
引先ハンドラ６２０へ引き渡す。 ローカル取引先ハンドラ６０２がリクエストを引き渡す場合には、システムは
ステップ６００８を実行し、ローカル取引先ハンドラ６０２は、証明書照合リク
エストを証明書照合サービスモジュール３１２へ送る。次に、証明書ステータス
照合コンポーネント３１２は、関連のＯＣＳＰレスポンダ２０４（即ち、証明書
ステータス照合コンポーネント３１２として同じ取引コーディネーター２０２に
属する）から、照合すべき証明書に関する証明書ステータスを取得する。この場
合のフローは以下のステップ６０３２に進む。
【００３９】 対照的に、照合すべき証明書が、リクエストを受け取った関係先の取引先に属
していない場合には、ステップ６０１０で、非ローカル取引先ハンドラ６０５は
、発行関係先のＩＰアドレスを調べるが、発行関係先は、静的ＤＮＳルックアッ
プテーブル６０４におけるリクエストの対象である証明書を発行するようになっ
ている。取引コーディネーター２０２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 en
cryption scheme）が使用される。安全ソケット・レイヤは、コマーシャル／ウ
ェブ・サーバ実装と適合する方法で使用され、およびインターネット等の電子ネ
ットワークを介して、セキュリティとプライバシーを提供する。安全ソケット・
レイヤは、アプリケーション独立であり、そのために、プロトコルは、それらの
最上部に、透過的に重ねられる。
【０１４２】 安全ソケット・レイヤは、すべてのネットワーク通信に関する機密性、データ
完全性、および認証（authentication）を与える。安全ソケット・レイヤは、通
常、通信エンティティ間を通るすべてのデータを暗号化することによって、機密
性を確証する。安全ソケット・レイヤ・イネーブルド・クライアント９５および
サーバ９０が最初に通信するときに、プロトコルのバージョンに関して同意し、
および暗号化アルゴリズムを選択する。好ましくは、ネットワーク承認暗号化ア
ルゴリズムおよびキー長が、ルート・エンティティ（root entity）１１０によ
って特定される。
【０１４３】 安全ソケット・レイヤはまた、通常、暗号の使用によって、データ完全性を確
証する。メッセージが正しく解読されない場合、レシピエント（recipient）は
、誰かがそのメッセージに干渉したことを告げることができる。
【０１４４】 安全ソケット・レイヤはまた、サーバおよびクライアント認証をサポートし、
暗号化キーを取り決め、およびデータが、より高いレベルのアプリケーションに
よって交換される前に、サーバを認証する。認証は、好ましくは、デジタル署名
およびパブリック・キー証明書の使用を通して与えられ、それは電子通信セッシ
ョンが最初に確立されたときに交換される。
【０１４５】 好ましい実施形態において、各トランザクション・コーディネータは、 Ｓ／ＭＩＭＥメッセージを送信するためのＳＭＴＰを用いて、およびＳＳＬｖ３
接続（ＨＴＴＰＳ）を介してＨＴＴＰプロトコルを通して通信し、パブリック・
インターネットでメッセージを受信し、および送信することができる。すなわち
、各トランザクション・コーディネータは、好ましくは、以下の二つの通信モー
ドをサポートするように適応する： ・ 安全ソケット・レイヤ（ＳＳＬｖ３）を介したＨＴＴＰ−同期通信（すな
わちＨＴＴＰＳ）のためのものである。ＨＴＴＰＳは、ウェブ・ページを安全に
転送するために、ウェブ・サーバとウェブ・ブラウザとの間の、安全ソケット・
レイヤを統合する、ハイパーテキスト転送プロトコルである。ＨＴＴＰキープ・
アライブ（HTTP keep alive）の使用が推奨される。 ・ Ｓ／ＭＩＭＥｖ２−ＳＭＴＰを使用した非同期通信のためのものである。
【０１４６】 好ましい実施形態において、各トランザクション・コーディネータは、信用取
引先（relying customer）との通信中はＨＴＴＰＳサーバとして、および他の金
融機関におけるトランザクション・コーディネータへの要求をするときは、ＨＴ
ＴＰＳクライアントとして振舞う。どちらの方法でも、証明書ステータス・チェ
ック（credential status checking）のための、すべてのＳＳＬ通信は、たった
一つのサーバ認証のみを採用してもよい。
【０１４７】 好ましい実施形態において、各トランザクション・コーディネータは、ルート
・エンティティ１１０によって承認される他のトランスポート・プロトコル（tr
ansport protocol）（例えば、ＩＩＯＰ）を介して届けられるメッセージを受信
してもよい。さらに、関係先は、構成により、局所的に他のトランスポート・プ
ロトコルを実行してもよい。しかしながら、前もっての合意がない場合、ＨＴＴ
ＰＳサポートのみが、任務を負うべきである。
【０１４８】 好ましい実施形態において、証明書ステータス・チェック・サービス３１２の
ために、Ｖａｌｉｃｅｒｔ登録商標のＯＣＳＰレスポンダが使用される。しかし
ながら、ＯＣＳＰレスポンダ２０４へのアクセスは、ライブラリを用いて達成さ
れてもよい。このように、新しいライブラリを書き込むことによって、新しいＯ
ＣＳＰレスポンダ・ベンダが実装されてもよい。
【０１４９】 好ましくは、ＯＣＳＰレスポンダ２０４は、証明書取り消しリストを使用せず
に、証明書ステータスを決定する。ＯＣＳＰレスポンダ２０４は、認証局、およ
び証明書を発行し、確認し、ならびに無効にするコンポーネントに関わる処理の
ほとんどを動かし、および潜在的に大きな証明書取り消しリストをダウンロード
する必要性を排除するかもしれない。代替的に、これら機能は、個別の署名キー
を与えられてもよい様々なコンポーネントの間で配分されてもよい。例えば、証
明書を発行する機能は、取り消し機能から分離されてもよく、およびこれらの機
能を実行するコンポーネントは、別個の署名キーを備えてもよい。
【０１５０】 好ましい実施形態において、署名コンポーネントとして、ハードウェア・セキ
ュリティ・モジュールが使用される。ハードウェア・セキュリティ・モジュール
は、好ましくは、署名をし、および署名を確認するための、高速装置である。ハ
ードウェア・セキュリティ・モジュールは、通常、暗号サービスを、認証された
エンティティに供給する、ネットワーク化されたハードウェア装置である。適切
なハードウェア・セキュリティ・モジュールは、ＮＣｉｐｈｅｒによって製造さ
れる。
【０１５１】 好ましい実施形態において、トランザクション・コーディネータ２０２は常に
、その通常の動作時間中、要求を処理するために利用可能であり、その時間は、
一週間７日一日２４時間でもよい。本システムが、確実にアベイラビリティの要
件に適合するために、システム・アベイラビリティの、詳細な要件解析が実行さ
れるべきである。様々な関係先が様々な要件を有するかもしれないので、多くの
異なる種類の故障が生じるかもしれない。公知のとおり、多くの様々なハードウ
ェアおよびソフトウェア・ベンダが、高アベイラビリティなシステムに関して、
様々なオプションを提供する。しかしながら、これらのオプションは、一定の金
融機関によって選択されるハードウェアおよびソフトウェアに関して利用可能で
あるかもしれないし、利用可能ではないかもしれない。
【０１５２】 トランザクション・コーディネータに影響を与えるかもしれない、数多くの、
公知の、潜在的なハードウェア故障がある。例えば、サーバへの電力供給が故障
するかもしれない。好ましくは、複数の冗長ホットスワップ電力供給（hot-swap
power supply）は、自動的に、冗長な電力供給に転換する。サーバが故障し、
またはクラッシュした場合、トランザクション・コーディネータは、好ましくは
、自動フェイル・オーバー（automatic fail over）のための、高アベイラビリ
ティ・クラスタリングを備える。さらに、トランザクション・コーディネータは
、好ましくは、ネットワーク・オペレーティング・システム（ＮＯＳ）ハングの
場合に、自動的にサーバをリブートするための、セルフ再スタート機能を具備す
る。
【０１５３】 トランザクション・コーディネータはまた、好ましくは、ディスク故障または
クラッシュを扱うための、複数の冗長ホットスワップ・ディスク・ドライブおよ
びディスク・アレイ・コントローラも具備する。トランザクション・コーディネ
ータはまた、ＮＩＣ故障の場合の、冗長ネットワーク・インターフェース・カー
ド（ＮＩＣｓ）のためのサポートを供給するための、ネットワーク・インターフ
ェースも具備する。クーリング・システム故障の場合には、トランザクション・
コーディネータは、好ましくは、個別に取り外すことができるホット・スワッパ
ブル冗長ファン（hot swappable redundant fans）を具備する、冗長ホットスワ
ップ・クーリング・システムを使用する。トランザクション・コーディネータは
また、好ましくは、ハードウェアおよびソフトウェア故障を検出するために、イ
ンテリジェント・プラットフォーム・マネージメント・インターフェース（Inte
lligent 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 part
icipant）の証明書は、１２８バイト、発行関係先の署名は、１２８バイト、お
よびＨＴＴＰヘッダは６２バイトである。
【０１８３】 信用取引先１０８から信用関係先１０４へ渡されるメッセージの、全体の推定
メッセージ・サイズは、２０２２バイトである。前記メッセージは、通常、二つ
の要求を具備し、一つは署名取引先の証明書に関し、一つは発行関係先の証明書
に関し、各々は５５バイトであり、メッセージ拡張は２１０バイトであり、バー
ジョン・ナンバ（version number）は４バイトであり、信用関係先の名は１３２
バイトであり、信用関係先の署名は１２８バイトであり、信用関係先の証明書は
１１４６バイトであり、ＨＴＴＰヘッダは６２バイトである。
【０１８４】 信用関係先１０４から発行関係先１０２へ渡されるメッセージの、全体の推定
メッセージ・サイズは、１６０１バイトである。前記メッセージは、通常、署名
取引先の証明書または発行関係先の証明書に関する要求を具備し、それは５５バ
イトであり、メッセージ拡張は２１０バイト、信用関係先のトランザクション・
コーディネータ証明書におけるルート・エンティティの署名は１２８バイト、信
用関係先のトランザクション・コーディネータ証明書は１１４６バイト、および
ＨＴＴＰヘッダは６２バイトである。
【０１８５】 発行関係先１０２から信用関係先１０４へ渡されるメッセージの、全体の推定
メッセージ・サイズは、２０８６バイトである。前記メッセージは、通常、署名
取引先の証明書か、または発行関係先の証明書のいずれかに関する応答を具備し
、それは４５６バイトであり、メッセージ拡張は２９４バイト、発行関係先の証
明書は１１４６バイト、ルート・エンティティの署名は１２８バイト、およびＨ
ＴＴＰヘッダは６２バイトである。
【０１８６】 信用関係先１０４から信用取引先１０８へ渡されるメッセージの、全体の推定
メッセージ・サイズは、２２１３バイトである。前記メッセージは、通常、署名
取引先の証明書または発行関係先の証明書に関する応答を具備し、それは５５バ
イトであり、メッセージ拡張は２１０バイト、信用関係先のトランザクション・
コーディネータからの応答は１２７バイト、信用関係先のトランザクション・コ
ーディネータ証明書は１１４６バイト、信用関係先・トランザクション・コーデ
ィネータの証明書への、ルート・エンティティの署名は１２８バイト、およびＨ
ＴＴＰヘッダは６２バイトである。
【０１８７】 異なるフィールドの、メッセージ・サイズ推定の詳細は、以下の表に記載され
ている。通常、エンティティ間で渡されるメッセージのサイズは、２Ｋから３Ｋ
の間である。トランザクション・ボリュームが算出されると、この情報は、好ま
しくは、ネットワーク・ロード（network load）を推定するために使用される。
【０１８８】 証明書サイズ―拡張無しまたはルート特化命令
【０１８９】 証明書拡張―ルート命令および拡張を伴う
【０１９０】 ＯＣＳＰ要求―ルート命令および拡張を伴う
【０１９１】 ＯＣＳＰ応答―ルート命令および拡張を伴う
【０１９２】 ＯＣＳＰトランザクションおよび保証トランザクションに関する有効要求およ
び応答時間、およびすべてのトランザクションに関する確認時間は、好ましくは
、ルート・エンティティ１１０によって特定される。以下の節は、トランザクシ
ョン・コーディネータに対する、好ましいパフォーマンス・ターゲットを記述し
ている。記述された応答時間は、特定的に、システム応答時間を表す。好ましく
は、手動処理（確認に対する必要性に言及し、それを要求し、クレームをファイ
ルする等）が完了する、経過した時間フレームも確立される。
【０１９３】 好ましくは、有効要求および応答時間（すなわち、ＯＣＳＰ）は、ルート制御
インフラストラクチャ内での、すべての応答時間トランザクションに関して、１
０秒以下である。（取引先から取引先へ、または取引先からルートへの）ルート
・インフラストラクチャ外の認可は、好ましくは６０秒を超えない。合計の往復
時間は、好ましくは７０秒を超えない。好ましくは、応答時間は、インターネッ
ト上での待ち時間を含む。エンド・ツー・エンド（end to end）応答時間は、好
ましくは、最長の有効パス（すなわち、署名取引先から信用取引先へ、信用関係
先へ、発行関係先へ、そしてルート・エンティティへ）を含む。
【０１９４】 例示的なパフォーマンス要件は、以下のとおりであろう：信用関係先のトラン
ザクション・コーディネータへの、証明書ステータス・チェックの通知と、応答
の受信との間はたった６秒であり、およびキャッシングが有効で、新しさの証明
（すなわち、関係先によって送信されるメッセージにおける、関係先証明書のス
テータスを含む）が有効で、二つの証明書の証明書チェーン（certificate chai
n）が認可されており、トランザクションが四角トランザクション（four-corner
transaction）であり、ならびにシステム・エンティティは、（インターネット
ではなく）１０Ｍｂｐｓ ＬＡＮに接続されている場合に、応答に関するデータ
が局所的に利用可能である証明書ステータス・チェックへ、応答を向かわせるの
にたった３秒である。
【０１９５】 保証要求応答時間は、オフライン・トランザクションを含む。好ましくは、こ
れらのオフライン・トランザクションは、営業日の終わりに開始する８時間の時
間帯を超えない。
【０１９６】 損失した、傷ついた、または無効な証明書の通知に対する応答のための応答時
間は、好ましくは、オフライン・トランザクションを含む。好ましくは、これら
のオフライン・トランザクションは、１時間を超えない。
【０１９７】 証明書の取り消しも、好ましくは、オフライン・トランザクションを含む。好
ましくは、これらのオフライン・トランザクションは1時間を超えない。
【０１９８】 トランザクション・コーディネータはまた、好ましくは、トランザクションの
確認を供給する。オンライン・トランザクション要求は、好ましくは、不完全な
要求または応答を含むステータス確認を、７０秒以内で受信する。トランザクシ
ョン・コーディネータはまた、好ましくは、不完全なトランザクション要求また
は応答の検索のために、要求ステータス、不完全な要求応答、ならびに不完全な
トランザクションのためのトランザクション・キューイング（transaction queu
ing）の受信を記憶するための方法を供給する。
【０１９９】 トランザクション・コーディネータはまた、好ましくは、トランザクション回
復要件を具備する。適切なシステム・リソース割り当ては、好ましくはトランザ
クション・ロールバック（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）として機能する。前記ベースラインは、システ
ムワイドなレベルで、一以上の関係先によってなされるコンフィギュレーション
変更の統括を容易にする。さらに、ベースラインは、一つ以上の認証局のハード
ウェアまたはソフトウェア故障の場合に、システムワイドなサービス・リカバリ
を容易にする。
【０２４０】 好ましい実施形態において、本システムの、コンフィギュレーション・ベース
ラインのマスタ・コピーは、ルート・エンティティ１１０によって維持される。
通常、マスタ・コピーは、事業の副社長等、ルート・エンティティ１１０の役員
が保持する。
【０２４１】 好ましい実施形態において、ルート・エンティティ１１０は、ルート・エンテ
ィティ１１０のハードウェアおよびソフトウェア・コンフィギュレーションの、
真実の、および正確な記録を保持する。ルート認証局のコンフィギュレーション
・ベースラインの少なくとも３のコピーが、以下の三つのロケーションに、ルー
ト・エンティティ１１０によって保持される：（１）ルート認証局と同じ物理的
ロケーションであり、それによって動作上の変更が生じたときに、それらが記録
されるようにする；（２）ルート認証局の物理的ロケーションの外部にある安全
ロケーションであるが、制御されたコンテナである；および（３）ルート・エン
ティティ１１０のバックアップおよびアーカイブ記録を伴うオフサイト（offsit
e）・ロケーションである。このハードウェアおよびソフトウェア・コンフィギ
ュレーションの他のコピーは、ルート・エンティティ１１０の判断で、レベル１
認証局に供給されてもよい。
【０２４２】 好ましい実施形態において、各レベル１関係先は、その認証局アーキテクチャ
のハードウェアおよびソフトウェア・コンフィギュレーションの、真実であり、
かつ正確な記録を維持する。各レベル１関係先は、好ましくは、以下の三つのロ
ケーションに、そのコンフィギュレーション・ベースライン・ドキュメントの少
なくとも３のコピーを準備し、保持し、および維持する：（１）レベル１認証局
の同じ物理的ロケーションであり、それによって動作上の変更は、それらが生じ
ると記録されるようにする；（２）レベル１認証局の物理的ロケーションの外部
である安全ロケーションであるが、制御されたコンテナである；および（３）レ
ベル１認証局のバックアップおよびアーカイブ記録を伴うオフサイト・ロケーシ
ョンである。さらに、各レベル１関係先は、好ましくは、そのコンフィギュレー
ション・ベースラインのコピーを、ルート・エンティティ１１０に供給する。 好ましい実施形態において、レベル２関係先も、それらの認証局アーキテクチ
ャのハードウェアおよびソフトウェア・コンフィギュレーションの真実の、およ
び正確な記録を維持する。各レベル２関係先は、以下の三つのロケーションにお
いて、そのコンフィギュレーション・ドキュメントの、少なくとも三つのコピー
を準備し、保持し、および維持する：（１）レベル２認証局と同じ物理的ロケー
ションであり、それによって、動作上の変更が生じたときに、それらが記録され
るようにする；（２）レベル２認証局の物理的ロケーションの外部にある安全ロ
ケーションであるが、制御されたコンテナである；および（３）レベル２認証局
のバックアップおよびアーカイブ記録を伴うオフサイト・ロケーションである。
さらに、各レベル２関係先は、好ましくは、そのコンフィギュレーション・ベー
スラインを、その保証しているレベル１認証局に供給する。
【０２４３】 ハードウェアおよびソフトウェア・コンフィギュレーションの文書化を容易に
するための形式が供給されてもよい。好ましい実施形態において、ルート・エン
ティティ１１０の、ならびに各関係先の認証局ディレクトリ、ＯＣＳＰレスポン
ダ、およびインターネット・ファイアウォールのハードウェアならびにソフトウ
ェア・コンフィギュレーションも、文書化される。
【０２４４】 好ましい実施形態において、ルート・エンティティ１１０は、システム・ワイ
ド・レベルでの、コンフィギュレーション管理に対する重要な責任を有する。こ
の責任は通常、事業の副社長等、ルート・エンティティ１１０の役員に委任され
る。各認証局は、好ましくは、認証局のハードウェアおよびソフトウェア・コン
フィギュレーションの正確な記録を維持することに対する、操作上の責任を有す
る技術操作スタッフを有する。
【０２４５】 好ましい実施形態において、各認証局の初期コンフィギュレーション・ベース
ラインは、各下位認証局のコンフィギュレーション・ベースラインを託すことに
よって、作られる。
【０２４６】 好ましい実施形態において、コンフィギュレーション変更は、以下の基準に従
わなければならない：（１）コンフィギュレーション変更は、定義されたシステ
ム要件に取り組むことを求められなければならない；（２）コンフィギュレーシ
ョン変更は、認証局のオペレーション・スタッフによって推奨されなければなら
ない；（３）オペレーショナル・プラットフォームのコンフィギュレーション変
更は、ルート・エンティティの場合には、事業の副社長等、役員によって、およ
びレベル１またはレベル２認証局の場合には、認証局の完全性に対して責任があ
る最高幹部によって承認されなければならない；（４）コンフィギュレーション
変更の通知は、影響のある当事者に対して行われなければならない；（５）コン
フィギュレーション変更は、統治または基準設定機関によって示される、関連す
るコンフィギュレーション変更基準を考慮しなければならない；および（６）コ
ンフィギュレーション変更は、変更日および前のコンフィギュレーションの各々
の期間を公表することによって、記録されなければならない。各認証局は、通常
、バックアップ・テープ等、他の保管された素材とともに、コンフィギュレーシ
ョン変更を保管する。
【０２４７】 好ましい実施形態において、コンフィギュレーション・ベースラインは、ルー
ト・エンティティのシステム・セキュリティ・ポリシーと関連して実装され、お
よび各認証局の監査されたコンポーネントである。
【０２４８】 本発明は、特定の実施形態との関係において記述されてきたが、数多くの代替
例、変更および変形が、前述の説明に照らして、当業者には明らかであることが
明白である。
【図面の簡単な説明】
【図１】 本発明で用いる４コーナーモデルの好適な実施形態のブロック図である。
【図２】 ４コーナーモデルの各々のエンティティに設けることが好ましいコンポーネン
トを示すブロック図である。
【図３】 取引コーディネーターの好適な実施形態のブロック図である。
【図４】 好適な実施形態における取引コーディネーターの特定の態様を示すブロック図
／フローチャートを組み合わせたものである。
【図５】 取引コーディネーターの署名コンポーネントの好適な作動を示すブロック図／
フローチャートを組み合わせたものである。
【図６】 証明書ステータス照合を実行する場合の取引コーディネーターが実行するステ
ップの好適な実施形態を示すブロック図／フローチャートを組み合わせたもので
ある。
【図７】 証明書を検証するための取引フローの好適な実施形態を示すブロック図／フロ
ーチャートを組み合わせたものである。
【図８】 保証サービスの１つの好適な実施形態に関する取引フローを示すブロック図／
フローチャートを組み合わせたものである。
【図９】 サーバー側認証の好適な実施形態のブロック図／フローチャートを組み合わせ
たものである。
【図１０】 クライアント側認証の好適な実施形態のブロック図／フローチャートを組み合
わせたものである。
【図１１】 メッセージ認証処理を示すブロック図／フローチャートを組み合わせたもので
ある。
【図１２】 取引コーディネーターのコンポーネントに関連したセキュリティ関連フローの
好適な実施形態のブロック図／フローチャートを組み合わせたものである。
【図１３】 好適な実施形態におけるシステムエンティティの間で送受信されるメッセージ
のサイズ（推定）を示すブロック図／フローチャートを組み合わせたものである
。
【図１４】 本システムのＯＣＳＰプロキシ中心の実施形態に関する取引フローを示すブロ
ック図／フローチャートを組み合わせたものである。
───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.7 識別記号 ＦＩ テーマコート゛(参考） Ｈ０４Ｌ 9/00 ６７５Ｂ (31)優先権主張番号 ６０／１５３，７２６ (32)優先日 平成11年９月13日(1999．9．13) (33)優先権主張国 米国（ＵＳ） (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＭＺ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ， ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＧ，ＡＬ，ＡＭ，ＡＴ， ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＢＺ，Ｃ Ａ，ＣＨ，ＣＮ，ＣＲ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ ，ＤＺ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ， ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，Ｋ Ｅ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ ，ＬＴ，ＬＵ，ＬＶ，ＭＡ，ＭＤ，ＭＧ，ＭＫ，ＭＮ， ＭＷ，ＭＸ，ＭＺ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，Ｒ Ｕ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ， ＹＵ，ＺＡ，ＺＷ (71)出願人 ネポムセノ ラリー アメリカ合衆国 カリフォルニア州 94103 サン フランシスコ サード ス トリート 201 フォース フロア (71)出願人 ダリン チャールズ アメリカ合衆国 ニュージャージー州 07042 モントクレア ハイ ストリート 73 (72)発明者 ソロ デイヴィッド アメリカ合衆国 ニューヨーク州 10103 ニューヨーク フィフス アヴェニュー 666 サード フロア (72)発明者 ヒックス マック アメリカ合衆国 カリフォルニア州 94103 サン フランシスコ サード ス トリート 201 フォース フロア (72)発明者 スターランド マーク イギリス ロンドン シーイー３ピー ３ エイエイチ ロンバルド ストリート 54 フォース フロア (72)発明者 ネポムセノ ラリー アメリカ合衆国 カリフォルニア州 94103 サン フランシスコ サード ス トリート 201 フォース フロア (72)発明者 ダリン チャールズ アメリカ合衆国 ニュージャージー州 07042 モントクレア ハイ ストリート 73 Ｆターム(参考） 5B058 CA01 KA08 KA31 YA02 YA03 5J104 AA07 KA01 MA01 PA07 PA10

Claims (36)

    【特許請求の範囲】
  1. 【請求項１】 ロギング・コンポーネントと； 請求コンポーネントと； 署名コンポーネントと； 保証サービス、証明書ステータス・チェック・サービス、または支払い補償サ
    ービスの、少なくとも一つと；および 前記コンポーネントのオペレーションと、少なくとも一つのサービスとを、
    一つ以上のトランザクションに結びつけるための、トランザクション処理モニタ
    と； を具備するトランザクション処理システムであって、前記一つ以上のトランザク
    ションは、原子性、一貫性、分離性、および耐久性の属性を有する、前記システ
    ム。
  2. 【請求項２】 電子ネットワークを介して、証明書ステータス・チェックを実行するための安
    全な方法であって、少なくとも一つの電子ネットワーク、少なくとも一つの署名
    取引先、少なくとも一つの信用取引先、少なくとも一つの発行関係先、少なくと
    も一つの信用関係先、および少なくとも一つのルートを具備する前記方法であっ
    て： （ａ）スマート・カードを前記少なくとも一つの署名取引先に発行するステッ
    プであって；前記署名取引先は、署名されるべきデータを、前記スマート・カー
    ドに送信し；および前記スマート・カードは、署名を生成し、ならびに前記署名
    を、前記署名取引先の証明書と前記発行関係先の証明書とともに戻す、前記ステ
    ップと （ｂ）前記署名されたデータ、前記署名取引先の証明書、および前記発行関係
    先の証明書を、前記少なくとも一つの信用取引先に送信するステップであって；
    前記少なくとも一つの信用取引先は、前記署名されたデータの前記署名を確認し
    、および前記署名取引先の証明書および前記発行関係先の証明書を含む、オンラ
    イン証明書ステータス・プロトコル（ＯＣＳＰ）要求を作成し；および前記ＯＣ
    ＳＰ要求は、署名のためにハードウェア・セキュリティ・モジュールに送信されて
    いる、前記署名取引先の証明書および前記発行関係先の証明書を含み；および前
    記ハードウェア・セキュリティ・モジュールは、署名ならびに前記信用取引先の
    証明書を戻す前記ステップと； （ｃ）前記署名取引先の証明書および前記発行関係先の証明書を含む前記ＯＣ
    ＳＰ要求を、前記信用取引先の証明書とともに、前記信用関係先のトランザクシ
    ョン・コーディネータに送信するステップであって； 前記信用関係先のトランザクション・コーディネータは、前記要求を処
    理する前に、前記要求が、現存の信用取引先によって署名されたことを確認する
    ために、取引先データベースをチェックし；および 前記信用関係先のトランザクション・コーディネータは、未処理トラン
    ザクション・データを未処理トランザクション・ログに記憶し、および請求デー
    タを請求ログに記憶し；および前記信用関係先のトランザクション・コーディネ
    ータは、前記サービス要求とともに送信された、前記信用取引先の証明書を用い
    て、前記サービス要求における前記信用取引先の署名を確認し；および 前記信用関係先の証明書およびルート・パブリック・キーであって、そ
    の両方が、そのハードウェア・セキュリティ・モジュールに記憶され；および 前記信用関係先のトランザクション・コーディネータは、前記信用取引
    先の証明書を含むＯＣＳＰ要求を生成し、それに署名をし、およびそれを同じ場
    所にあるＯＣＳＰレスポンダに送信し；および 前記ＯＣＳＰレスポンダは、前記要求における前記信用取引先の署名を
    確認し、そのローカル・レポジトリをチェックし、および応答を、前記信用関係
    先のトランザクション・コーディネータに返し；および 前記信用関係先のＯＣＳＰレスポンダは、前記署名取引先の証明書に対
    する要求を生成し、それに署名し、およびそれを、前記信用関係先の証明書とと
    もに、前記発行関係先に送信する前記ステップと； （ｄ）前記発行関係先のトランザクション・コーディネータによる、前記署名
    取引先証明書に対する前記要求を受信するステップであって； 前記発行関係先のトランザクション・コーディネータは、前記要求を処
    理する前に、現存する署名取引先が前記サービス要求に署名したことを確認する
    ために、その取引先データベースをチェックし；および 前記発行関係先のトランザクション・コーディネータは、前記未処理ト
    ランザクション・データを、その未処理トランザクション・ログに記憶し；およ
    び 前記発行関係先のトランザクション・コーディネータは、前記要求に対
    する請求データを、その請求ログに記憶し；および 前記発行関係先のトランザクション・コーディネータは、前記要求とと
    もに送信される前記信用関係先のトランザクション・コーディネータの証明書と
    、および前記発行関係先のトンラザクション・コーディネータのハードウェア・
    セキュリティ・モジュールに記憶される、前記ルート・パブリック・キーを用い
    ることによって、前記要求における前記信用関係先のトランザクション・コーデ
    ィネータの署名を確認し；および 前記発行関係先のトランザクション・コーディネータは、前記信用関係
    先の証明書に対する、署名されたＯＣＳＰ要求を生成し、およびそれを、前記ル
    ートのトランザクション・コーディネータに送信する前記ステップと； （ｅ）前記ルートのトランザクション・コーディネータによる、前記信用関係
    先の証明書に対する前記要求を受信するステップであって、前記ルートのトラン
    ザクション・コーディネートは、前記未処理トランザクション・データを、その
    未処理トランザクション・ログに記憶し、および請求データをその請求ログに記
    憶する前記ステップであって；および 前記ルートのトランザクション・コーディネータは、前記要求における
    前記署名を確認し、および前記要求を、そのＯＣＳＰレスポンダに送信し；およ
    び 前記ルートのＯＣＳＰレスポンダは、そのローカル・レポジトリをチェ
    ックし、および応答を、ルートのトランザクション・コーディネータに返し；お
    よび 前記ルートのトランザクション・コーディネータは、署名された応答を
    、前記発行関係先のトランザクション・コーディネータに送信する前記ステップ
    と； （ｆ）前記発行関係先のトランザクション・コーディネータによる前記応答を
    受信するステップであって、前記発行関係先のトランザクション・コーディネー
    タは、否認防止の目的で、前記応答を、その未処理トランザクション・ログに記
    憶し；および 前記発行関係先のトランザクション・コーディネータは、前記署名取引
    先の証明書を含む、それが受信した前記要求から、ＯＣＳＰ要求を生成し、それ
    に署名をし、およびそれ自らの証明書とともに、それを前記発行関係先のＯＣＳ
    Ｐレスポンダに送信し；および 前記発行関係先のＯＣＳＰレスポンダは、前記要求における前記署名を
    確認し、応答を生成し、それに署名し、および前記署名された応答を、前記発行
    関係先のトランザクション・コーディネータに返し；および 前記発行関係先のトランザクション・コーディネータは、前記ＯＣＳＰ
    レスポンダの署名を確認し、前記応答に再署名し、およびそれ自らの証明書とも
    もに、それを、前記信用関係先のトランザクション・コーディネータに返す前記
    ステップと； （ｇ）前記信用関係先のトランザクション・コーディネータによる応答を受信
    するステップであって、前記信用関係先のトランザクション・コーディネータは
    、否認防止の目的で、前記未処理応答データを、その未処理トランザクション・
    ログに記憶し；および 前記信用関係先のトランザクション・コーディネータは、前記発行関係
    先・トランザクション・コーディネータの証明書、およびそのハードウェア・セ
    キュリティ・モジュールに記憶されている前記ルート・パブリック・キーを用い
    て、前記応答における前記署名を確認し；および 前記信用関係先のトランザクション・コーディネータは、前記発行関係
    先の証明書に対するＯＣＳＰ要求を生成し、およびそれを、前記ルートのトラン
    ザクション・コーディネータに送信する前記ステップと； （ｈ）前記ルートのトランザクション・コーディネータによる要求を受信する
    ステップであって、前記ルートのトランザクション・コーディネータは、前記未
    処理要求データをその未処理トランザクション・ログに記憶し、および前記請求
    データを、その請求ログに記憶し；および 前記ルートのトランザクション・コーディネータは、前記要求における
    前記署名を確認し；および 前記ルートのトランザクション・コーディネータは、前記要求を、その
    ＯＣＳＰレスポンダに送信し；および 前記ルートのＯＣＳＰレスポンダは、そのローカル・レポジトリをチェ
    ックし、および応答を、前記ルートのトランザクション・コーディネータに返し
    ；および 前記ルートのトランザクション・コーディネータは、前記応答を、前記
    信用関係先のトランザクション・コーディネータに送信する前記ステップと； （ｉ）前記信用関係先のトランザクション・コーディネータによる前記応答を
    受信するステップであって、前記信用関係先のトランザクション・コーディネー
    タは、否認防止の目的で、前記応答を、その未処理トランザクション・ログに記
    憶し；および 前記信用関係先のトランザクション・コーディネータは、前記発行関係
    先の証明書に対する、署名されたＯＣＳＰ要求を生成し、およびそれを、前記ル
    ートのトランザクション・コーディネータに送信する前記ステップと； （ｊ）前記ルートのトランザクション・コーディネータによる前記要求を受信
    するステップであって、前記ルートのトランザクション・コーディネータは、前
    記未処理要求データを、その未処理トランザクション・ログに記憶し；および 前記ルートのトランザクション・コーディネータは、関連する請求デー
    タを、その請求ログに記憶し；および 前記ルートのトランザクション・コーディネータは、前記要求における
    前記署名を確認し、および前記要求を、そのＯＣＳＰレスポンダに送信し；およ
    び 前記ルートのＯＣＳＰレスポンダは、そのローカル・レポジトリをチェ
    ックし、および応答を、前記ルートのトランザクション・コーディネータに返し
    ；および 前記ルートのトランザクション・コーディネータは、署名された応答を
    、前記信用関係先のトランザクション・コーディネータに送信する前記ステップ
    と； （ｋ）前記信用関係先のトランザクション・コーディネータによる前記応答を
    受信するステップであって、前記信用関係先のトランザクション・コーディネー
    タは、否認防止の目的で、前記応答を、その未処理トランザクション・ログに記
    憶し；および 前記信用関係先のトランザクション・コーディネータは、前記発行関係
    先のトランザクション・コーディネータから受信された前記応答からＯＣＳＰ応
    答を生成し、それに署名をし、およびそれを、前記信用関係先の証明書とともに
    信用取引先に送信する前記ステップと； （ｌ）前記信用取引先による前記応答を受信するステップであって、前記信用
    取引先は、そのハードウェア・セキュリティ・モジュールに記憶された前記ルー
    トのパブリック・キー証明書を用いて、前記応答を確認し；および 前記証明書が取り消されたか決めるために、前記信用取引先は、前記信
    用関係先の証明書に対する要求を送信する前記ステップと； （ｍ）前記信用関係先のトランザクション・コーディネータによる前記要求を
    受信するステップであって、前記信用関係先のトランザクション・コーディネー
    タは、前記要求における前記署名を確認し、および前記信用取引先の証明書が取
    り消されなかったことを確証するために、要求を、そのローカルＯＣＳＰレスポ
    ンダに送信し；および 前記信用関係先のローカルＯＣＳＰレスポンダは、前記信用関係先のト
    ランザクション・コーディネータに、応答を返し；および 前記信用関係先のトランザクション・コーディネータは、前記信用関係
    先の証明書における要求を、前記ルートのトランザクション・コーディネータに
    送信する前記ステップと； （ｎ）前記ルートのトランザクション・コーディネータによる前記要求を受信
    するステップであって、前記ルートのトランザクション・コーディネータは、前
    記要求における前記署名を確認し、および前記信用関係先の証明書のステータス
    を決めるために、そのローカルＯＣＳＰレスポンダと照合し；および 前記ルートのトランザクション・コーディネータは、そのローカルＯＣ
    ＳＰレスポンダから受信された前記応答を、前記信用関係先のトランザクション
    ・コーディネータに転送する前記ステップと （ｏ）前記信用関係先のトランザクション・コーディネータによる前記応答を
    受信するステップであって、前記信用関係先のトランザクション・コーディネー
    タは、前記応答を、前記信用取引先に転送する前記ステップと （ｐ）前記信用取引先による前記応答を受信するステップであって、前記信用
    取引先は、前記署名取引先に受領通知をする前記ステップと を具備する前記方法。
  3. 【請求項３】 ネットワークを介して、一つ以上のサービスを供給するためのシステムであっ
    て： ルート・エンティティであって、ルート・エンティティ認証局を操作し、前記
    ルート・エンティティ認証局に対するルート・エンティティ・コンフィギュレー
    ション・ベースラインを維持し、前記ルート・エンティティ・コンフィギュレー
    ション・ベースラインは、前記ルート・エンティティ認証局の動作環境を含む、
    前記ルート・エンティティと； 少なくとも一つのレベル１関係先であって、レベル１認証局を操作し、前記レ
    ベル１認証局に対するコンフィギュレーション・ベースラインを維持し、前記レ
    ベル１認証局に対する前記コンフィギュレーション・ベースラインは、前記レベ
    ル１認証局の動作環境を含む、前記レベル１関係先と； 少なくとも一つのレベル２関係先であって、レベル２認証局を操作し、前記レ
    ベル２認証局に対するコンフィギュレーション・ベースラインを維持し、前記レ
    ベル２認証局に対する前記コンフィギュレーション・ベースラインは、前記レベ
    ル２認証局の動作環境を含む、前記レベル２関係先と； を具備する前記システム。
  4. 【請求項４】 各エンティティの認証局の前記コンフィギュレーション・ベースラインは、あ
    る形式で記録されることを特徴とする、請求項３に記載のシステム。
  5. 【請求項５】 各エンティティのコンフィギュレーション・ベースラインのコピーは、前記ル
    ート・エンティティによって維持されることを特徴とする、請求項３に記載のシ
    ステム。
  6. 【請求項６】 コンフィギュレーション・マネージャをさらに具備する、請求項３に記載のシ
    ステムであって、前記コンフィギュレーション・マネージャは、前記ルート・エ
    ンティティの役員であり、さらに、前記システム内のコンフィギュレーション管
    理に第一の責任を有する、前記システム。
  7. 【請求項７】 各認証局は、技術操作スタッフを具備し、前記技術操作スタッフは、エンティ
    ティ認証局のコンフィギュレーションの記録を管理することに対して第一の責任
    を有することを特徴とする、請求項３に記載のシステム。
  8. 【請求項８】 各エンティティの認証局に対する前記コンフィギュレーション・ベースライン
    は、前記エンティティの認証局の同じ物理的ロケーションに維持されることを特
    徴とする、請求項３に記載のシステム。
  9. 【請求項９】 各エンティティの認証局に対する前記コンフィギュレーション・ベースライン
    は、前記エンティティの認証局の前記物理的ロケーションの外部の、安全なロケ
    ーションに維持されることを特徴とする、請求項３に記載のシステム。
  10. 【請求項１０】 各エンティティの認証局に対する前記コンフィギュレーション・ベースライン
    は、オフサイト・ロケーションに維持されることを特徴とする、請求項３に記載
    のシステム。
  11. 【請求項１１】 システム要件に取り組むために、エンティティの認証局の前記コンフィギュレ
    ーション・ベースラインに変更がなされることを特徴とする、請求項３に記載の
    システム。
  12. 【請求項１２】 影響を受ける当事者は、エンティティの認証局の前記コンフィギュレーション
    ・ベースラインへの変更を通知されることを特徴とする、請求項３に記載のシス
    テム。
  13. 【請求項１３】 エンティティの認証局の前記コンフィギュレーション・ベースラインへの変更
    は、統治機関によって示されるコンフィギュレーション変更基準を考慮すること
    を特徴とする、請求項３に記載のシステム。
  14. 【請求項１４】 エンティティの認証局の前記コンフィギュレーション・ベースラインへの変更
    は、基準設定機関によって示されるコンフィギュレーション変更基準を考慮する
    ことを特徴とする、請求項３に記載のシステム。
  15. 【請求項１５】 少なくとも一つのルート・エンティティ、少なくとも一つの発行関係先、およ
    び少なくとも一つの信用関係先を含む複数のエンティティを含むネットワークを
    介して、証明書ステータス・チェックを供給するステップであって、各エンティ
    ティは： トランザクション・コーディネータと； オンライン証明書ステータス・プロトコル・レスポンダであって、証明書のス
    テータスをチェックし、前記トランザクション・コーディネータから、オンライ
    ン証明書ステータス要求を受信し、オンライン証明書ステータス応答を、前記ト
    ランザクション・コーディネータに送信する、前記オンライン証明書ステータス
    ・プロトコル・レスポンダと；および 少なくとも一つのハードウェア・セキュリティ・モジュールと を具備する、前記システム。
  16. 【請求項１６】 前記オンライン証明書ステータス・プロトコル・レスポンダは、チェックされた
    証明書に関連する取り消された応答を送信することを特徴とする、請求項１５に
    記載のシステムであって、前記取り消された応答は、前記証明書、すなわち前記
    証明書の証明書チェーンにおける一つの証明書が、特定の時間よりも前に取り消
    されたことを示す、前記システム。
  17. 【請求項１７】 前記発行関係先は、前記チェックされた証明書に対応するプライベート・キー
    を用いて、前記特定の時間の後に署名されたドキュメントに対する責任を受け入
    れないことを特徴とする、請求項１６に記載のシステム。
  18. 【請求項１８】 前記オンライン証明書ステータス・プロトコル・レスポンダは、チェックされ
    た証明書に関連する良い応答を送信することを特徴とする、請求項１５に記載の
    システムであって、前記良い応答は、前記証明書および前記証明書の前記証明書
    チェーンにおける一つおきの証明書が、特定の時間においてすでに支払い済みで
    あることを示す、前記システム。
  19. 【請求項１９】 前記発行関係先は、前記チェックされた証明書に対応するプライベート・キー
    を用いて、前記特定の時間の前に署名されたドキュメントに対する責任を受け入
    れることを特徴とする、請求項１８に記載のシステム。
  20. 【請求項２０】 前記オンライン証明書ステータス・プロトコル・レスポンダは、証明書に関す
    る不明応答を送信することを特徴とする、請求項１５に記載のシステムであって
    、前記不明応答は、前記証明書、すなわち前記証明書の前記証明書チェーンにお
    ける一つの証明書が、特定の時間において、支払済みであることが不明であるこ
    とを示す、前記システム。
  21. 【請求項２１】 前記発行関係先は、前記チェックされた証明書に対応するプライベート・キー
    を用いて、前記特定の時間より前に署名されたドキュメントに対する責任を受け
    入れないことを特徴とする、請求項２０に記載のシステム。
  22. 【請求項２２】 前記オンライン証明書ステータス・プロトコル・レスポンダは、そのプライベ
    ート・キーを、ハードウェア・セキュリティ・モジュールに記憶することを特徴
    とする、請求項１５に記載のシステム。
  23. 【請求項２３】 前記オンライン証明書ステータス・プロトコル・レスポンダは、前記ルート・
    エンティティによって確立された、一組の最小セキュリティ要件に適合すること
    を特徴とする、請求項１５に記載のシステム。
  24. 【請求項２４】 第一の関係先、第二の関係先、第一の取引先、および第二の取引先を具備する
    システムであって、前記第一の取引先は、前記第一の関係先の取引先であり、前
    記第二の取引先は、前記第二の関係先の取引先であり、各エンティティは、デジ
    タル証明書および関連するプライベート・キーを供給される前記システムにおい
    て、証明書を認可するための方法は： ａ）前記第一の取引先が、そのプライベート・キーでデータに署名をし； ｂ）前記第一の取引先が、前記署名されたデータを、前記第二の取引先に送信し
    ； ｃ）前記第二の取引先が、前記第一の取引先の証明書に対する認可要求を生成し
    ； ｄ）前記第二の取引先が、前記第一の取引先の証明書に対する前記認可要求を、
    前記第二の関係先に送信し； ｅ）前記第二の関係先が、前記認可要求を前記第一の関係先に転送し； ｆ）前記第一の関係先が、前記認可要求に対する応答を、前記第二の関係先へ送
    信し；および ｇ）前記第二の関係先が、前記応答を、前記第二の取引先に送信する ことを具備する前記方法。
  25. 【請求項２５】 前記第二の取引先は、前記認可要求に署名するために、ハードウェア・セキュ
    リティ・モジュールを使用することを特徴とする、請求項２４に記載の方法。
  26. 【請求項２６】 各関係先は、否認防止のために、前記認可要求に関するデータを記憶すること
    を特徴とする、請求項２４に記載の方法。
  27. 【請求項２７】 各関係先は、請求のために、前記認可要求に関するデータを記憶することを特
    徴とする、請求項２４に記載の方法。
  28. 【請求項２８】 各関係先は、前記要求を処理する前に、前記認可要求が、承認されたエンティ
    ティから受信されたことを確認するために、取引先データベースをチェックする
    ことを特徴とする、請求項２４に記載の方法。
  29. 【請求項２９】 各関係先は、前記認可要求を生成するために、オンライン証明書ステータス・
    プロトコル・レスポンダを使用することを特徴とする、請求項２４に記載の方法
    。
  30. 【請求項３０】 第一の関係先、第二の関係先、第一の取引先、および第二の取引先を具備する
    システムであって、前記第一の取引先は、前記第一の関係先の取引先であり、前
    記第二の取引先は、前記第二の関係先の取引先であり、各エンティティはデジタ
    ル証明書および関連するプライベート・キーを供給される前記システムにおいて
    、保証サービスを供給する方法は： ａ）前記第一の取引先が、そのプライベート・キーでデータに署名をし； ｂ）前記第一の取引先が、前記署名されたデータおよびその証明書を、前記第二
    の取引先に送信し； ｃ）前記第二の取引先が、前記第一の取引先の証明書に対する保証要求を生成し
    ； ｄ）前記第二の取引先が、前記保証要求を、前記第二の関係先に送信し； ｅ）前記第二の関係先が、前記保証要求を、前記第一の関係先に転送し； ｆ）前記第一の関係先が、保証を発行するべきか否かを決定し； ｇ）前記第一の関係先が、前記決定を、前記第二の関係先に送信し；および ｈ）前記第二の関係先は、前記決定を、前記第二の取引先に送信する ことを具備する前記方法。
  31. 【請求項３１】 前記第二の取引先は、前記保証要求に署名をするために、ハードウェア・セキ
    ュリティ・モジュールを使用することを特徴とする、請求項３０に記載の方法。
  32. 【請求項３２】 各関係先は、否認防止のために、前記保証要求に関するデータを記憶すること
    を特徴とする、請求項３０に記載の方法。
  33. 【請求項３３】 各関係先は、請求のために、前記保証要求に関するデータを記憶することを特
    徴とする、請求項３０に記載の方法。
  34. 【請求項３４】 各関係先は、要求を処理する前に、前記要求が承認されたエンティティから受
    信されたことを確認するために、取引先データベースをチェックすることを特徴
    とする、請求項３０に記載の方法。
  35. 【請求項３５】 ルート・エンティティ、第一の関係先、第二の関係先、第一の取引先、および
    第二の取引先を具備するシステムであって、前記第一の取引先は、前記第一の関
    係先の取引先であり、前記第二の取引先は、前記第二の関係先の取引先であり、
    各エンティティは、デジタル証明書および関連するプライベート・キーを供給さ
    れる前記システムにおいて、証明書を認可するための方法は： ａ）前記第二の取引先が、前記第二の関係先の証明書を含む認可要求を生成し； ｂ）前記第二の取引先が、前記第二の関係先の証明書を含む前記認可要求を、前
    記第二の関係先に送信し； ｃ）前記第二の関係先が、前記第二の関係先の証明書に対する認可要求を生成し
    ； ｄ）前記第二の関係先が、前記第二の関係先の証明書を含む前記認可要求を、前
    記ルート・エンティティに送信し； ｅ）前記ルート・エンティティは、前記認可要求に対する応答を、前記第二の関
    係先に送信し；および ｆ）前記第二の関係先は、前記応答を、前記第二の取引先に送信する ことを具備する前記方法。
  36. 【請求項３６】 前記第二の関係先は、前記認可要求を生成するために、オンライン証明書ステ
    ータス・プロトコル・レスポンダを使用することを特徴とする、請求項３５に記
    載の方法。
JP2001522463A 1999-09-10 2000-09-08 証明書確認及び他のサービスを提供するためのシステム及び方法 Expired - Fee Related JP5275536B2 (ja)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US15320399P 1999-09-10 1999-09-10
US60/153,203 1999-09-10
US15372699P 1999-09-13 1999-09-13
US15372499P 1999-09-13 1999-09-13
US60/153,724 1999-09-13
US60/153,726 1999-09-13
PCT/US2000/024663 WO2001018721A1 (en) 1999-09-10 2000-09-08 System and method for providing certificate validation and other services

Related Child Applications (3)

Application Number Title Priority Date Filing Date
JP2011254357A Division JP5670296B2 (ja) 1999-09-10 2011-11-21 証明書確認及び他のサービスを提供するための方法
JP2011254358A Division JP5670297B2 (ja) 1999-09-10 2011-11-21 証明書確認及び他のサービスを提供するためのシステム
JP2011254356A Division JP5670295B2 (ja) 1999-09-10 2011-11-21 証明書確認及び他のサービスを提供するための方法

Publications (2)

Publication Number Publication Date
JP2003509746A true JP2003509746A (ja) 2003-03-11
JP5275536B2 JP5275536B2 (ja) 2013-08-28

Family

ID=27387400

Family Applications (4)

Application Number Title Priority Date Filing Date
JP2001522463A Expired - Fee Related JP5275536B2 (ja) 1999-09-10 2000-09-08 証明書確認及び他のサービスを提供するためのシステム及び方法
JP2011254356A Expired - Fee Related JP5670295B2 (ja) 1999-09-10 2011-11-21 証明書確認及び他のサービスを提供するための方法
JP2011254358A Expired - Fee Related JP5670297B2 (ja) 1999-09-10 2011-11-21 証明書確認及び他のサービスを提供するためのシステム
JP2011254357A Expired - Fee Related JP5670296B2 (ja) 1999-09-10 2011-11-21 証明書確認及び他のサービスを提供するための方法

Family Applications After (3)

Application Number Title Priority Date Filing Date
JP2011254356A Expired - Fee Related JP5670295B2 (ja) 1999-09-10 2011-11-21 証明書確認及び他のサービスを提供するための方法
JP2011254358A Expired - Fee Related JP5670297B2 (ja) 1999-09-10 2011-11-21 証明書確認及び他のサービスを提供するためのシステム
JP2011254357A Expired - Fee Related JP5670296B2 (ja) 1999-09-10 2011-11-21 証明書確認及び他のサービスを提供するための方法

Country Status (6)

Country Link
EP (1) EP1221120A4 (ja)
JP (4) JP5275536B2 (ja)
AU (1) AU764840B2 (ja)
CA (1) CA2384158A1 (ja)
HK (1) HK1045001A1 (ja)
WO (1) WO2001018721A1 (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007502578A (ja) * 2003-08-12 2007-02-08 インテル・コーポレーション 安全な移動体通信及び高価な取引の実行に対しランタイムパッケージ署名において信頼性の高いハードウェアベースのアイデンティティ信任状を使用する方法
JP2007518369A (ja) * 2004-01-09 2007-07-05 コアストリート、 リミテッド Ｏｃｓｐ及び分散型ｏｃｓｐのための効率的に署名可能なリアルタイム・クレデンシャル
JP2009528730A (ja) * 2006-02-28 2009-08-06 西安西▲電▼捷通▲無▼綫▲網▼絡通信有限公司 認証サーバのセキュアアクセスプロトコルの適合試験の方法およびそれについての装置
JP2010509659A (ja) * 2006-11-03 2010-03-25 アールアイシー・インベストメンツ・エルエルシー 患者情報管理システム
JP2016096547A (ja) * 2014-11-13 2016-05-26 エルジー シーエヌエス カンパニー リミテッドＬＧ ＣＮＳ Ｃｏ．， Ｌｔｄ． 否認防止方法、このための決済管理サーバおよび使用者端末

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7134021B2 (en) * 1999-10-22 2006-11-07 Hitachi, Ltd. Method and system for recovering the validity of cryptographically signed digital data
US20030229811A1 (en) * 2001-10-31 2003-12-11 Cross Match Technologies, Inc. Method that provides multi-tiered authorization and identification
GB2386802A (en) * 2002-03-18 2003-09-24 Hewlett Packard Co Auditing of secure communication sessions over a communication network
EP2518670A4 (en) * 2010-09-07 2015-02-25 Zte Corp SYSTEM AND METHOD FOR REMOTE PAYMENT BASED ON MOBILE TERMINALS
CN111242705B (zh) * 2019-12-31 2023-12-26 航天信息股份有限公司企业服务分公司 一种发票数据的获取方法和装置
GB2604104A (en) * 2021-02-18 2022-08-31 Nchain Holdings Ltd Digital security systems and methods

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998026385A2 (en) * 1996-12-13 1998-06-18 Certco, Llc Reliance server for electronic transaction system
JPH113387A (ja) * 1997-02-06 1999-01-06 Fujitsu Ltd 決済システム
JPH11503541A (ja) * 1995-04-07 1999-03-26 ファイナンシャル サービシーズ テクノロジー コンソルティウム 電子資金取引証書

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5453601A (en) * 1991-11-15 1995-09-26 Citibank, N.A. Electronic-monetary system
US5920847A (en) * 1993-11-01 1999-07-06 Visa International Service Association Electronic bill pay system
US6285991B1 (en) * 1996-12-13 2001-09-04 Visa International Service Association Secure interactive electronic account statement delivery system
US6085168A (en) * 1997-02-06 2000-07-04 Fujitsu Limited Electronic commerce settlement system
US6125349A (en) * 1997-10-01 2000-09-26 At&T Corp. Method and apparatus using digital credentials and other electronic certificates for electronic transactions
US5913210A (en) * 1998-03-27 1999-06-15 Call; Charles G. Methods and apparatus for disseminating product information via the internet
CA2361053A1 (en) * 1999-01-29 2000-08-03 Richard Ankney Reliance manager for electronic transaction system
EP1203332A4 (en) * 1999-02-12 2002-09-25 Mack Hicks SYSTEM AND METHOD FOR PROVIDING CERTIFICATION-RELATED AND OTHER SERVICES

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11503541A (ja) * 1995-04-07 1999-03-26 ファイナンシャル サービシーズ テクノロジー コンソルティウム 電子資金取引証書
WO1998026385A2 (en) * 1996-12-13 1998-06-18 Certco, Llc Reliance server for electronic transaction system
JPH113387A (ja) * 1997-02-06 1999-01-06 Fujitsu Ltd 決済システム

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2007502578A (ja) * 2003-08-12 2007-02-08 インテル・コーポレーション 安全な移動体通信及び高価な取引の実行に対しランタイムパッケージ署名において信頼性の高いハードウェアベースのアイデンティティ信任状を使用する方法
JP2007518369A (ja) * 2004-01-09 2007-07-05 コアストリート、 リミテッド Ｏｃｓｐ及び分散型ｏｃｓｐのための効率的に署名可能なリアルタイム・クレデンシャル
US7966487B2 (en) 2004-01-09 2011-06-21 Corestreet, Ltd. Communication-efficient real time credentials for OCSP and distributed OCSP
JP4796971B2 (ja) * 2004-01-09 2011-10-19 コアストリート、 リミテッド Ｏｃｓｐ及び分散型ｏｃｓｐのための効率的に署名可能なリアルタイム・クレデンシャル
JP2009528730A (ja) * 2006-02-28 2009-08-06 西安西▲電▼捷通▲無▼綫▲網▼絡通信有限公司 認証サーバのセキュアアクセスプロトコルの適合試験の方法およびそれについての装置
JP2010509659A (ja) * 2006-11-03 2010-03-25 アールアイシー・インベストメンツ・エルエルシー 患者情報管理システム
JP2016096547A (ja) * 2014-11-13 2016-05-26 エルジー シーエヌエス カンパニー リミテッドＬＧ ＣＮＳ Ｃｏ．， Ｌｔｄ． 否認防止方法、このための決済管理サーバおよび使用者端末

Also Published As

Publication number Publication date
WO2001018721A8 (en) 2001-10-11
JP5670297B2 (ja) 2015-02-18
JP2012038350A (ja) 2012-02-23
EP1221120A4 (en) 2009-07-15
HK1045001A1 (zh) 2002-11-08
WO2001018721A1 (en) 2001-03-15
AU764840B2 (en) 2003-09-04
EP1221120A1 (en) 2002-07-10
JP5275536B2 (ja) 2013-08-28
JP5670295B2 (ja) 2015-02-18
JP2012059283A (ja) 2012-03-22
CA2384158A1 (en) 2001-03-15
JP2012053918A (ja) 2012-03-15
AU7359200A (en) 2001-04-10
WO2001018721A9 (en) 2002-10-03
JP5670296B2 (ja) 2015-02-18

Similar Documents

Publication Publication Date Title
US8818903B2 (en) Transaction coordinator for digital certificate validation and other services
JP5670295B2 (ja) 証明書確認及び他のサービスを提供するための方法
CN111183426B (zh) 基于区块链的通知的系统和方法
CN111095865B (zh) 用于发布可验证声明的系统和方法
CN111095327B (zh) 用于验证可验证声明的系统和方法
CN111066020B (zh) 用于创建去中心化标识的系统和方法
EP3688650B1 (en) System and method for providing a representational state transfer proxy service for a blockchain cloud service
US20200328878A1 (en) System and method for blockchain-based cross-entity authentication
US7949871B2 (en) Method for creating virtual service connections to provide a secure network
EP1540881B1 (en) System and method for the transmission, storage and retrieval of authenticated documents
US6363365B1 (en) Mechanism for secure tendering in an open electronic network
US20200076625A1 (en) High precision timestamps in blockchain
US11489672B2 (en) Verification of conditions of a blockchain transaction
US20100064349A1 (en) Secure transmission and exchange of standardized data
US9077719B2 (en) Method and system for automatic distribution and installation of a client certificate in a secure manner
US20200089509A1 (en) Collaborative model execution
US20140089156A1 (en) Addresses in financial systems
CN111612452A (zh) 一种基于区块链的知识产权管理系统及方法
Vogler et al. Distributed transaction processing as a reliability concept for mobile agents
Moser et al. Building dependable and secure Web services.
Gritzalis, D. Gritzalis, C. Moulinos, J. Iliadis An integrated architecture for deploying a virtual private medical network over the Web
Torres et al. An implementation of a trusted and secure DRM architecture
Tobarra et al. Application of formal methods to the analysis of web services security
WO2001020513A9 (en) System and method for providing certificate validation and other services
WO2000045564A1 (en) Reliance manager for electronic transaction system

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20070910

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100408

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20100708

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20100715

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20101008

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20101202

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20110209

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20110217

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110602

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20110721

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20111121

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120110

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120127

A911 Transfer of reconsideration by examiner before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20120202

A912 Removal of reconsideration by examiner before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A912

Effective date: 20120427

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20121211

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20121218

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20130115

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20130118

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130516

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees