フォーマット化したデータ構造を用いた保証付き決済取引システム及び方法
【課題】オンラインカード保有者取引を認証するための、３−Ｄセキュア・プロトコルに整合した認証プログラムを提供する。
【解決手段】カード保有者のオンライン取引を認証するために使用するｅ−コマース認証プログラムの結果を搬送するためのフォーマット化したデータ構造を提供する。このデータ構造は最大２０バイトの長さを有し、ｅ−コマースに使用する３−Ｄセキュア・メッセージ・プロトコルと整合するように設計されている。このデータ構造は、販売者名の省略形を含み、認証サービス・プロバイダを識別し、使用する認証方法を識別し、カード保有者情報を取引に結び付ける販売者認証コードを含む指定フィールドを含む。前記ｅ−コマース認証プログラムによって使用され、認証結果を所望のフォーマットで生成するための保証付き決済アルゴリズムが提供される。１つの保証付き決済アルゴリズムでは、秘密キーを用いて、カード保有者のアカウント番号と前記データ構造の指定フィールドからの情報との連続体を暗号化する。他の保証付き決済アルゴリズムでは、一対の秘密キーを用いて、カード保有者のアカウント番号、カード有効期限日、及びサービスコードの連続体を暗号化する。両方の場合において、暗号化結果の一部を用いて販売者認証コードを規定する。
【解決手段】カード保有者のオンライン取引を認証するために使用するｅ−コマース認証プログラムの結果を搬送するためのフォーマット化したデータ構造を提供する。このデータ構造は最大２０バイトの長さを有し、ｅ−コマースに使用する３−Ｄセキュア・メッセージ・プロトコルと整合するように設計されている。このデータ構造は、販売者名の省略形を含み、認証サービス・プロバイダを識別し、使用する認証方法を識別し、カード保有者情報を取引に結び付ける販売者認証コードを含む指定フィールドを含む。前記ｅ−コマース認証プログラムによって使用され、認証結果を所望のフォーマットで生成するための保証付き決済アルゴリズムが提供される。１つの保証付き決済アルゴリズムでは、秘密キーを用いて、カード保有者のアカウント番号と前記データ構造の指定フィールドからの情報との連続体を暗号化する。他の保証付き決済アルゴリズムでは、一対の秘密キーを用いて、カード保有者のアカウント番号、カード有効期限日、及びサービスコードの連続体を暗号化する。両方の場合において、暗号化結果の一部を用いて販売者認証コードを規定する。
【発明の詳細な説明】
【技術分野】
【０００１】
（優先権及び関連出願のクロスリファレンス）
本願は、米国特許暫定出願番号60/477,187、2003年6月10日出願に基づいて優先権を主張し、その全文を参考文献として本明細書に含める。本願はさらに、国際特許出願番号PCT/US04/17756、2004年6月4日出願、発明の名称”Customer Authentication in E-Commerce Transactions”並びに米国特許出願番号10/096,271、2002年3月11日出願、発明の名称”System and Method for conducting Secure Payment Transactions”にも関連し、後者の第１段落に挙げた優先権主張の基になるいくつかの先行出願共々、参考文献として本明細書に含める。
【背景技術】
【０００２】
（発明の背景）
本発明は、インターネットのような開放型（オープン）電子ネットワーク上で関係者によって行われる取引を認証するシステム及び方法に関するものである。特に、本発明は、顧客がクレジットカードを含む決済カードで支払を後払いするインターネット取引の認証に関するものである。
【０００３】
Ｅ−コマース（電子商取引）は現在、大衆化している。インターネットのような電子ネットワーク上で取引を行うことは現在、販売者及び顧客の双方にとっての利便性、より低いコスト、市場への到達性及び選択性、といったよく言われる利点を有する。しかし、インターネットの匿名性は、商業または小売りの販売に、詐欺及び誤用の問題をもたらす。取引市場は、販売を認証し、販売を証明し、販売を確認し、販売の無拒否を保証し、支払を保証し、そして匿名性を制御したい要望がある。同様に、購入者（バイヤー）は、販売の認証、販売の完全性、悪質な販売の償還請求、販売の確認、プライバシー、及び匿名性を制御したい要望がある。
【０００４】
【特許文献１】米国特許出願10/096,271
【発明の開示】
【０００５】
共同譲渡されている米国特許出願番号10/096,271、2002年3月11日出願は、顧客端末においてユーザ・ソフトウェアを利用して、１つ以上の隠れフィールドを含むことのできるウェブページを表示するために使用する一組のウェブページデータを受信する安全な決済取引を行うシステム及び方法を記載し、その全文を参考文献として本明細書に含む。取引及びカード保有者のデータを有するウェブページは購入データとして販売者に送信される。販売者はこのウェブページデータを、例えば電子的にカード発行者（発行会社）に提出して、決済取引の認証または認可を行う。
【０００６】
カード発行者及び他の金融機関は今日、標準化されたインターネット取引プロトコルを提供または使用して、オンライン取引性能を改善し、電子商取引の成長を加速させている。一部の標準化されたプロトコル（例えばVisa Internationalによって開発された３−Ｄセキュア（登録商標）プロトコル）の下で、カード発行者または発行銀行は取引を認証し、これにより詐欺、及び関連するカード保有者が未承認の取引に起因する払い戻しの生じ易さを低減している。認証取引の存在は、オンライン購入中にカード保有者を認証するよう努力したにもかかわらず詐欺が発生したら、カード発行者がその責任を負うことになり得る。カード発行者または発行銀行は、発行者が認証した取引の支払を受けることを販売者に保証することができる。３−Ｄセキュア（登録商標）プロトコルは、カード発行者によって提供された（例えばVisaまたはMasterCard SecureCode（登録商標）によって検証された）、リモート（遠隔）取引中に販売者が顧客を認証するための認証プログラムと一貫性があり、これらのプログラムの下にある。３−Ｄセキュア（登録商標）プロトコルは、既存のセキュア・ソケッツ・レイヤー（ＳＳＬ：Secure Sockets Layer）暗号化機能をてこ入れし、オンライン・ショッピング（買物）セッション中の発行者によるカード保有者の認証による拡張された安全を提供する。参加中の販売者はMerchant Plug In（ＭＰＩ：販売者プラグイン）（登録商標）と称されるソフトウェア部品を用いて、メッセージを交換し、情報を伝達し、そして参加者に問合せして、オンライン購入中のカード保有者とそのカードの発行者との間の認証セッションを確立する。
【０００７】
３−Ｄセキュア・プロトコル・サービスは、３つのドメイン（領域）モデル、即ち発行者ドメイン、アクワイアラ（加盟店からバリューを回収して現金化する企業体）ドメイン、及び相互運用ドメインの各モデルに基づく。発行者は、サービス中にカード保有者の登録を管理し、オンライン取引中にカード保有者を認証する責任を負う。アクワイアラは、インターネット取引に参加中の販売者がアクワイアラとの合意の下で操作を行う手続きを規定し、認証取引のバックエンド処理を行う責任を負う。相互運用ドメインは、汎用プロトコル及び共用のサービスによって、他の２つのドメイン間の取引交換を促進する。カード保有者及びその取引銀行は「発行者ドメイン」に含むことができ、販売者及びその取引銀行は「アクワイアラ・ドメイン」に含むことができる。発行銀行または金融機関とアクワイアラ銀行または金融機関との間の通信、及びカード発行者のインフラストラクチャ（基盤）は「相互運用ドメイン」に含むことができる。３−Ｄセキュアに準拠する銀行及び販売者と取引する間に、消費者は、取引中の関係者が本当に記録にあるカード保有者であるか否かを判定するための、カード保有者の取引銀行からの独立した認証ウィンドウまたはポップアップ・スクリーンが存在すること以外は、前と同じインターネット・ショッピングを経験することができる。前記プロトコルの下でのオンライン・インターネット購入取引の流れは次の通りである：
(1) 顧客が、販売者のウェブサイトにおいて、暗号化されたセキュア・ソケッツ・レイヤー（ＳＳＬ）接続を介して、通常の方法で決済データを記入する。
(2) 次に販売者は、ＭＰＩを通してメッセージをディレクトリに送信し、このディレクトリはカード発行者に問い合わせて、顧客が３−Ｄセキュア・プログラム中に登録されているか否かを見出す。
(3) カード発行者は前記ディレクトリに、カード保有者が登録されているか否かを示すメッセージで応答して、登録されていれば、このカードを発行した銀行にウェブ・アドレスを提供する。そしてこのメッセージを処理して、販売者に応答を返す。
(4) 次に販売者は、カード保有者の装置を通して発行銀行にメッセージを送信して、カード保有者とカード発行者との間の認証セッションを開始し、このセッションでは、取引明細、例えば販売社名及び取引金額を確認のためにカード保有者に提供することもできる。
(5) 次に発行銀行は認証ウィンドウをカード保有者に提供し、この認証ウィンドウは、販売者名及び金額のような取引に関する情報、個人的なセキュリティ・メッセージ、及びカード保有者が認証の詳細を入力可能な応答領域を詳細に示している。
(6) 顧客は、発行銀行がシステムを実現するために選定した方法に応じて、種々の方法のうちの１つで取引を承認する。選択肢は、静的なパスワードまたはＰＩＮ（個人識別番号）を入力することから、スマートカード及びパーソナル（個人用）カードリーダ（ＰＣＲ：Personal Card Reader）を利用して認証トークンを生成することにまで及ぶ。
(7) 発行者は取引及びカード保有者データを処理して認証を行うことができる。認証が有効であれば、発行者は、取引が成功したことを示すメッセージを販売者に送信する。発行者は、認証に失敗したか認証を完了できなかった場合にも販売者に通知する。このメッセージは、認証プロセスの結果を符号化したアカウント（口座）保有者認証値（ＡＡＶ：Accountholder Authentication Value）を含むことができる。
【０００８】
今日、クレジットカードまたはデビットカードを使用する顧客を認証するための解決法を拡張する方法が考慮されている。顧客またはカードを安全に認証して販売者への支払を行うために使用されるデータ及びアルゴリズムに注意が向けられている。この解決法は、３−Ｄセキュアのような汎用プロトコルの産業上の実現、及びスマートカードが単純かつ静的なパスワードを超えるべく認証を強化するための他の産業規格、例えばＥＭＶ規格と整合すべきである。
【０００９】
（発明の概要）
本発明によれば、オンラインカード保有者取引を認証するための、３−Ｄセキュア・プロトコルに整合した認証プログラムが提供される。この認証プログラムは、アクセス制御サーバー（ＡＣＳ：Access Control Server）を使用してカード保有者の取引を認証する。ＡＣＳは安全決済アルゴリズム（ＳＰＡ：Secure Payment Algorithms）をカード保有者及び取引情報に適用して、暗号化されたアカウント保有者認証値（ＡＡＶ）を生成して、このＡＡＶは認証された取引に割り当てられる。生成されたＡＡＶは、３−Ｄセキュア・プロトコルのメッセージを含むのに適したデータ構造を有する。
【００１０】
本発明の好適例では、前記データ構造が約２０バイトのベース６４符号化した文字を超えない長さを有する。その第１バイトは制御バイトとすることができ、バイト２〜９は販売者名の概略を表現することができ、そしてバイト１０は、カード保有者の取引を認証した特定のＡＣＳを示す。ＡＣＳは種々の認証方法（例えばパスワード・ベース（パスワードに基づくもの）、チップ・ベース、あるいはＰＣ識別法）を用いてカード保有者の取引を認証することができる。前記ＡＡＶデータ構造のバイト１１は、この認証方法、及びＡＣＳが販売者認証コード（ＭＡＣ：Merchant Authentication Code）を生成するために使用した秘密（シークレット）暗号キーを識別する。前記ＡＡＶデータ構造のバイト１２〜１５は、ＡＣＳが処理した取引の通し（シーケンス）番号を識別し、バイト１６〜２０はＭＡＣを表現する。
【００１１】
ＳＰＡは、特定取引用のＭＡＣ値を生成するための適切な暗号化プロセスを含むことができる。１つの暗号化プロセスは秘密（シークレット）キーを用いて、カード保有者のアカウント（口座）番号とＡＡＶのフィールド１〜６（またはバイト１〜１５）との連続体を暗号化する。この暗号化結果の最初の４０ビット（または５バイト）はＭＡＣフィールドに割り当てられる。他の暗号化プロセスでは、一対のデータ・エンクリプション・スタンダード（ＤＥＳ：Data Encryption Standard：米国のデータ暗号化規格）キーを用いて、カード保有者のアカウント番号、カード有効期限日、及びサービスコードを暗号化して、３ディジット（１０進数字）のカード保有者検証コード（ＣＶＣ２：Card Verification Code）番号を生成する。この３ディジットの番号は２進化１０進数（ＢＣＤ：Binary Decimal）に変換され、この２進化１０進数は、前記ＡＡＶデータ構造中のＭＡＣフィールドに置かれて1.5バイトを占める。このＭＡＣフィールドの残りの3.5バイトは、０で埋めるか０を置くことができる。
【００１２】
ＡＡＶデータを含む３−Ｄセキュア・プロトコルの電子メッセージは、前記アクセス制御サーバー（ＡＣＳ）によってディジタル署名することができる。ＡＡＶデータを含むメッセージを受信する販売者は、前記ＡＡＶデータを抽出する前に、３−Ｄセキュア・プロトコルに従って前記ディジタル署名の有効性を確認することを求められる。販売者は、前記ＡＡＶデータ、及び特に前記ＭＡＣデータを、決済認証要求メッセージに転送することができる。
【００１３】
本発明のさらなる特徴、性質、及び種々の利点は、以下の図面を参照した実施例の詳細な説明より一層明らかになる。
【００１４】
各図面を通して、特に断わりのない限り、同一参照番号及び符号は、図示する実施例の同様の特徴、素子、構成要素、または部分を表わすために用いている。
【００１５】
（実施例の詳細な説明）
本発明は、電子取引における遠隔的な（リモート）関係者を認証するための解決法を提供する。特に、この解決法は、電子取引に遠隔的に参加するカード保有者を認証するために用いる安全決済アプリケーション（例えば図１のＳＰＡ１３５）に関係する。この解決法は、工業規格のｅ−コマース（電子商取引）プラットフォーム上、例えば３−Ｄセキュア準拠のｅ−コマース・プラットフォーム上、及び郵便注文（メールオーダー）及び電話注文、あるいは移動装置のような非ｅ−コマース環境における取引認証に用いることができ、こうした非ｅ−コマース環境では発行者が認証トークンまたはコードを用いてカード保有者を認証することができる。
【００１６】
表１は、本明細書で用いるいくつかの用語、頭文字、または省略形の語彙辞典である：
【表１】
【００１７】
以下、図１を参照しながら説明する。ＳＰＡ１３５は、カード保有者認証検証値（ＣＡＶＶ）を、３−Ｄセキュア・メッセージ・フォーマットに整合するフォーマットで生成するために使用する暗号文アルゴリズム（即ち”ＨＭＡＣ”及び”ＣＶＣ２”アルゴリズム）を含むことができる。
【００１８】
ＳＰＡ１３５は、カード発行者が当該カードの保有者を認証するために選定または実現可能なあらゆる適切な認証プログラムと統合することができる。これらの認証プログラムは、スマートカード・ベース及びパスワード・ベースの解決法（例えば、図１のチップ・ベースの認証プログラム１４１及び３−Ｄセキュアのパスワード・ベースの認証プログラム１４２）を含むことができる。これらの認証プログラムは、例えばＰＣ識別に基づく他の解決法を含むことができる。
【００１９】
本発明の安全決済アプリケーション（ＳＰＡ１３５）を利用した認証プログラムは、３−Ｄセキュア・プロトコルに準拠したｅ−コマース・プラットフォーム上で行われる電子取引を安全にするための解決法またはプログラムとすることができる。この目的のために、ＳＰＡ１３５は、３−Ｄセキュア・メッセージ中で容易に使用可能なデータ・フォーマットの認証結果を使用し生成するように設計されている。特に、規定のフィールド及びバイト長を有するフォーマット化されたデータ構造は、認証結果を３−Ｄセキュア・メッセージ中で搬送することを促進するために使用することができる。
【００２０】
好適な認証プログラム１０００（図１）におけるＳＰＡ１３５の適用を図示する目的で、ここではカード決済取引を好適な取引として用いる。このカード決済取引への参加者は、カード保有者、発行者、販売者、及びアクワイアラを含むことができる。
【００２１】
カード保有者は、例えば認証プログラム１０００のライセンス（使用許諾された）メンバーによって発行された決済カードの認可ユーザである。カード保有者は、発行された決済カードを用いて販売者とのオンライン取引を決済することができる。認証プログラム１０００は、サードパーティ（第三者機関）によって提供される認証プログラムまたはサービスの一部とすることができ、このサードパーティは例えば、カード保有者のアイデンティティ（正体）及び存在が取引の完了に先立って適正に認証されることを保証することができる。
【００２２】
発行者は決済カードを発行するメンバー（例えば金融機関）であり、銘柄（商標）を付けることができる（例えばマスターカード（登録商標）及び／またはMaestro cards（登録商標））。発行者は、決済カードの銘柄の規定及び地域的な法規に従って、決済カードを使用する認可された取引に対する支払を保証する。発行者は、販売者または他の関係者に認証サービスを提供することに加えて、カード保有者が認証プログラム１０００に参加する資格を判定する責任を負う。
【００２３】
販売者は、小売人、あるいは、例えば販売者加入契約に従い、発行者の決済カードが適正に提示された際に、これらのカードでの支払いを受け付ける他の個人、商店、会社である。認証プログラム１０００に加入することによって、販売者は加入者に、インターネット上での認証された電子的やり取りを提供することができる。決済カードを受け付ける販売者はさらにアクワイアラとの関係を持つ。認証プログラム１０００に参加する販売者は、詐欺及び争議のコストの低減、取引量の増加、無認可カードの使用防止、及び発行者のカードベースへのアクセスを含むいくつかの形の恩恵を受けることができる。
【００２４】
アクワイアラは、販売者との関係を維持し、取引に関するデータを販売者またはカード受け付け者から取得するエンティティ（実体）である。アクワイアラは、販売者が認証プログラム１０００に参加する資格を判定する役割をすることができる。
【００２５】
図１に示すように、好適な認証プログラム１０００は、階層化された複数の構成要素を有する安全なｅ−コマースの構成またはプラットフォームとして実現することができる。これらの階層化された構成要素は、データ搬送（トランスポート）層１００、販売者の要求層１２０、認証層１３０、及び発行者プラットフォーム１４０を含む。認証層１３０は、取引または決済（支払）を認証するために設けられた安全決済アプリケーション（ＳＰＡ１３５）に関係する。
【００２６】
データ搬送層１００は、カード保有者、発行者、販売者及びアクワイアラの間で認証情報及び結果を通信するデータ収集及び搬送インフラストラクチャに関係する。データ搬送は、例えば汎用カード保有者認証フィールド（ＵＣＡＦ、表１参照）のような標準化されたデータ構造、アーキテクチャまたはメカニズムに基づくものとすることができる。
【００２７】
ＵＣＡＦは一般に、フレキシブル（柔軟）なデータ構造を有する可変長、３２文字のフィールドとして規定することができ、種々の発行者のセキュリティ及び認証方法の必要性をサポートするように仕立てることができる。図２に、ＵＣＡＦの一般的な構造を示す。ＵＣＡＦ中の最初の制御バイトは、各セキュリティ決済アプリケーションまたは態様に特有の値を含む。ＵＣＡＦ中の残りのバイトはアプリケーション特有のデータを含むことができる。認証または認可プロバイダ（提供者）は、ＵＣＡＦの制御バイト値、及びＵＣＡＦアプリケーション特有のデータの構造を割り当て及び管理する役割をすることができる。
【００２８】
好適な制御バイトの規定は次のようにすることができる：
使用法 最初及びその後の取引用の３−ＤセキュアＳＰＡのＡＡＶ
ベース６４符号化値 ｊ
１６進数の値 ｘ’８Ｃ’
他の好適な制御バイトの規定は次のようにすることができる：
使用法 試行用の３−ＤセキュアＳＰＡのＡＡＶ
ベース６４符号化値 ｊ
１６進数の値 ｘ’８６’
【００２９】
従来のＵＣＡＦ実現では、アプリケーション特有のデータは、制御バイトを含めて最大２４バイトの長さを有する２進数（バイナリ）データとして規定することができる。しかし、一部の取引認可ネットワークは、認可メッセージ中の２進数データの通過を制限する。従って、認証プログラム１０００中でＳＰＡ１３５が生成するすべてのＵＣＡＦデータは、認証メッセージ中に含めるより先にベース６４符号化することができる。ベース６４符号化手順は、関連する２進数データの文字表現である。結果的な文字表現は、等価な２進数の約３倍の大きさ（長さ）である。この理由により、ＵＣＡＦフィールドは一般に最大長３２文字で規定することができる。しかし、認証プログラム１０００における３−Ｄセキュア・メッセージ送信との整合のために、ＵＣＡＦフィールドは２８文字の長さに制限される。
【００３０】
アカウント保有者認証値（ＡＡＶ）は、ＳＰＡを含む発行者の認証プラットフォームに関係するＵＣＡＦの特定実現である。ＡＡＶは、発行者によるカード保有者の認証が良好であった際に発行者が生成して販売者に提供し、（アクワイアラへの）取引認証要求中に置くことができる。チャージバック（課金、料金徴収）または他のあり得る争議の場合には、ＡＡＶを用いて取引に関連する処理パラメータを識別することができる。ＵＣＡＦは、認証プロセス中に認証目的でＡＡＶを販売者から発行者に送信するために使用するメカニズムである。
【００３１】
再び図１を参照しながら説明する。販売者要求層１２０は、他の層及びカード保有者とやり取りする販売者能力に関係する。認証プログラム１０００に参加中の販売者は、３−Ｄセキュア・メッセージを処理することのできるアプリケーション・ソフトウェア能力（例えば販売者プラグイン（ＭＰＩ：Merchant Plug-Ins））を実現することができる。ＭＰＩは、３−Ｄセキュア・メッセージを処理する制御アプリケーションとして働くことができる。
【００３２】
本発明のＳＰＡ１３５を含む認証層１３０は、カード保有者アカウントの所有権を検証するための（例えば発行者によって提供されるか、あるいは発行者と契約した）認証プロセスまたはサービスを表わす。例えばアクセス制御サーバー（ＡＣＳ）を使用する発行者は、認証層１３０／ＳＰＡ１３５をＡＡＶ確認サーバー／プロセスと共同で実現することができる。
【００３３】
前記認証プロセスに関係する好適なｅ−コマース・ネットワークの構成要素またはエンティティは、例示目的で、表２に示す発行者、アクワイアラ、または相互運用性ドメイン（領域）に属するものとして組織することができる。
【表２】
【００３４】
表２に示すように、発行者ドメイン中に存在する機能は、（アクワイアラ・ドメイン中の）ＭＰＩと（発行者ドメイン中の）アクセス制御サーバーとの間でメッセージを搬送するための導管として作用することのできるカード保有者ブラウザを含む。関連のカード保有者ソフトウェアは例えば、スマートカードの使用をサポートするためのオプション的なソフトウェアを含むことができる。登録サーバーは、認証プログラム１０００の下で発行者が３−Ｄセキュアを実現するためのカード保有者登録プロセスを手助けする。このサーバーは、最初のカード保有者認証を実行するため、並びにリセット、３−Ｄセキュア決済履歴の視認のような管理活動用に用いることができる。
【００３５】
アクセス制御サーバーは、オンライン購入の過程中に少なくとも２つの基本機能を提供する。第１に、ＡＣＳは、与えられたカード保有者アカウント番号がプログラム１０００中に登録されているか否かを検証する。第２に、ＡＣＳはカード保有者識別用の認証プロセスを実行する。この目的のために、ＡＣＳはＡＡＶ確認サーバー／プロセスと協働するか、あるいはＡＡＶ確認サーバー／プロセスを含むことができる。このＡＡＶ確認サーバー／プロセスは、販売者またはアクワイアラから受信したカード保有者認証データの有効性を確認するために使用することもできる。
【００３６】
アクワイアラ・ドメイン中の機能は、販売者プラグイン（ＭＰＩ）及び署名確認サーバーの機能を含むことができる。ＭＰＩは、支払者認証メッセージを作成して処理し、そして販売者ソフトウェアに制御を戻してさらなる認証処理を行わせることができる。ＭＰＩ認証プロセスは、カード保有者が決済（支払）に使用するアカウント番号を含む購入要求を提出した後であるが購入の認可を得るより先に呼び出すことができる。署名確認サーバーは、発行者によって問題なく認可された購入要求上のディジタル署名の有効性を確認するために使用することができる。
【００３７】
相互運用性ドメイン中の機能はディレクトリ・サーバーを含むことができる。ディレクトリ・サーバーは、認証プログラム１０００中に登録された販売者に、集中化された決定（判定）能力を提供するグローバル・ディレクトリ・サーバーとすることができる。販売者の検証要求メッセージ中に含まれるアカウント番号に基づいて、ディレクトリ・サーバーはまず、このアカウント番号が参加中のカード発行者のカード範囲の一部をなすか否かを判定する。ディレクトリ・サーバーは次に、資格のある要求を適切な発行者のＡＣＳに向けてさらなる処理をさせる。相互運用性ドメインは、末端エンティティ及びその従属者から成るすべての私的な階層の証明書を、要求に応じて生成して、これら３つのドメインにわたる種々の構成要素及び他の従属的な証明当局に分配するのに適した証明当局（機関）を含むことができる。
【００３８】
プログラム１０００中のカード保有者認証プロセスは、これら３つのドメイン間でのメッセージ及びデータの交換を含む。次の好適な３−Ｄセキュア・ドメイン間メッセージを認証プロセス中で段階的に用いることができる：
(1) 確認要求／応答
メッセージ対：ＶＥＲｅｑ／ＶＥＲｅｓ
【００３９】
認証プロセス中の第１ステップは、カード保有者のアカウント番号が、認証プログラム１０００に参加中の発行者のカード範囲の一部をなすことをチェックまたは確認することである。この目的のために、検証要求メッセージＶＥＲｅｑがＭＰＩからディレクトリ・サーバーに送信されて、カード範囲の資格がチェックされる。指定されたアカウント番号がディレクトリ・サーバー内の有資格のカード範囲内に含まれる場合には、このメッセージをディレクトリ・サーバーから発行者のＡＣＳに転送して、前記指定のアカウント番号が発行者によってプログラム１０００中の参加者として登録、及び／または有効にされているか否かをさらにチェックすることができる。
【００４０】
ＭＰＩは、参加中の各発行者がカード範囲をローカル（自分の所）にキャッシュ記憶する随意的な能力を有する。こうした場合には、ＭＰＩはカード範囲要求／応答メッセージを用いて、ディレクトリ・サーバーからカード範囲キャッシュの更新を要求することができる。カード範囲をキャッシュ記憶する販売者にとっては、発行者が認証プログラム１０００中に登録されていないことをローカルキャッシュが示す場合にはＶＥＲｅｑ／ＶＥＲｅｓメッセージを利用することができない。
【００４１】
(2) 支払者認証要求／応答
メッセージ対：ＰＡＲｅｑ／ＰＡＲｅｓ
一旦、カード保有者が発行者によって登録されているか、あるいはプログラム１０００中の有効な参加者であることが判明すると、この特定カード保有者を認証するプロセスにはさらに、前記特定カード発行者が関与する。支払者認証要求／応答メッセージをＭＰＩから前記特定カード発行者のＡＣＳに送信して認証を実行することができる。プログラム１０００中の認証プロセスのこの段階では、カード保有者に認証ウィンドウを提供することができる。この認証ウィンドウをカード保有者のブラウザ上に表示して、発行者が関連情報をこのウィンドウ内に置くことができる。カード保有者は、個人識別または認証用のパスワード、コードまたはトークンを、表示された認証ウィンドウを通して入力することを要求される。そして前記特定カード発行者のＡＣＳは、例えばＳＰＡ１３５を用いて、収集し、あるいは入力された情報を認証して、これに従いアカウント保有者認証値（ＡＡＶ）を生成することができる。このＡＡＶは、ＵＣＡＦ内の指定されたカード保有者認証検証値（ＣＡＶＶ）（表１参照）フィールド内の３−ＤセキュアＰＡＲｅｓメッセージ中で搬送される。
【００４２】
ＣＡＶＶは、発行者によって要求中の販売者に返送されたメッセージ対ＰＡＲｅｑ／ＰＡＲｅｓの応答部分中のデータフィールドのうちの１つである。発行者は適切なディジタル署名を自分の応答上に置くことができる。販売者はさらに、受信したＡＡＶを決済／取引認証要求（図４参照）の一部として含めてアクワイアラに送信して発行者に転送させることができる。
【００４３】
図３に、認証プログラム１０００の下でのカード保有者取引用の好適なカード認証プロセス３００を図式的に示す。例示目的のため、以下のプロセス３００の説明は、カード保有者３１０が発行者によって認証プログラム１０００中に登録され、参加中の販売者の所でオンラインで買い物（ショッピング）をする間に使用するパスワードまたはコードを発行者から取得済みであるものと仮定する。プロセス３００は、構成要素間のすべての通信チャンネルが、セキュア・ソケット・レイヤー・プロトコル（ＳＳＬ（登録商標）：Secure Sockets Layer：保証付きソケット層）のリンク（例えばＳＳＬ−１、ＳＳＬ−２、ＳＳＬ−３、ＳＳＬ−４、ＳＳＬ−５及びＳＳＬ−６）を用いて適正な安全性を有することも仮定する。
【００４４】
プロセス３００中のステップ３５１では、カード保有者３１０が販売者のウェブサイトで買い物をして、精算（チェックアウト）する段になると、決済カード情報（例えばアカウント番号）及び他の情報（例えば発送情報）をリンクＳＳＬ−１経由で入力する。一旦、すべての決済（支払）及び発送情報を入力すると、販売者はカード保有者３１０に、注文を提出する前に購入を再点検する機会を与えることができる。
【００４５】
次のステップ３５２では、ＭＰＩ３２０がリンクＳＳＬ−２経由でディレクトリ・サーバー３３０に、カード保有者３１０の特定発行者による登録を検証することを、検証要求メッセージＶＥＲｅｑを用いて要求する。ステップ３５２は随意的に、ＭＰＩ３２０においてローカル・カード・ディレクトリ・キャッシュによってローカルで実行することができる。ＶＥＲｅｑメッセージに応答して、ディレクトリ・サーバー３３０は、特定発行者が参加中であることを判定して、これにより、要求をリンクＳＳＬ−３経由で前記特定発行者のＡＣＳ３４０に転送して、カード保有者３１０の現在の登録状態を照査することができる。結果的な応答は同じリンク（例えばＳＳＬ−３及びＳＳＬ−２）上でＭＰＩ３２０に戻される。カード保有者３１０がプログラム１０００中に登録されていることをＡＣＳ３４０が示す場合には、ＭＰＩ３２０は支払者認証要求メッセージを作成して、ステップ３５４においてこのメッセージをリンクＳＳＬ−４経由でカード保有者のブラウザに送信することができる。次のステップ３５５では、カード保有者のブラウザが前記メッセージを適切な発行者のＡＣＳ３４０に向かわせて、カード保有者認証を開始することができる。ＡＣＳ３４０が前記支払者認証要求メッセージを受信すると、ＡＣＳ３４０はユーザ認証の対話を開始させることができる。このユーザ認証の対話の一部として、ＡＣＳ３４０は別個の対話型認証ウィンドウをカード保有者３１０に対して表示して、カード保有者３１０によるパスワード、コード、または他のデータの入力を促すことができる。
【００４６】
ステップ３５６では、ＡＣＳ３４０は（ＳＰＡ１３５を用いて）、カード保有者３１０によって入力されたパスワードまたはコードを認証することができる。ＡＣＳ３４０は、認証プログラムの提供者（プロバイダ）による３−Ｄセキュアの実現により、ＳＰＡのＡＡＶを構成することができる。ＡＣＳ３４０は適切な支払者認証応答メッセージを構成してディジタル署名することができる。そしてこの支払者認証応答メッセージは（リンクＳＳＬ−６経由で）ＭＰＩ３２０に戻される。この時点では、カード保有者３１０に対して表示される認証ウィンドウは消失させることができる。
【００４７】
カード保有者認証プロセス３００が完了した後に、販売者は、受信したＳＰＡのＡＡＶを、認可メッセージ内のＵＣＡＦフィールドを介してアクワイアラに渡すことを要求され得る。そしてこのＳＰＡのＡＡＶは、従来の認可メッセージ処理の一部として、アクワイアラから発行者に渡される。発行者がＡＡＶを受信すると、認可要求処理の一部としてその有効性を確認し、そしてアーカイブ記録して、後に発生し得るカード保有者の争議の解決に使用することができる。
【００４８】
標準的な３−Ｄセキュアのバージョン1.0.2のメッセージ・フォーマット及びデータ・フォーマットは、関与する関係者またはエンティティ間のすべてのデータ通信に用いることができる。特に、ＡＣＳ３４０が作成して販売者に返送し、販売者がＵＣＡＦメッセージ中に含めるＳＰＡのＡＡＶは２８文字長であり、３−Ｄセキュアのベース６４符号化用に規定された２０バイトのフィールドを含む。
【００４９】
表３に、前記２０バイトのＳＰＡのＡＡＶの好適なデータ構造またはフォーマットを示す：
【表３】
【００５０】
３−Ｄセキュアの解決法に加えて、既存のＰＣ識別及び他の認証の解決法（例えば図１）を共に提供する発行者は、異なる認証の解決法から対応する認証メッセージ中で受け取ったＡＡＶ値どうしを区別することができる。３−Ｄセキュアに整合するプログラム１０００から生じた２０バイトのＡＡＶ（例えば表２）は、一般的な２８倍とのＡＡＶ構造（即ち、非３−Ｄセキュア・プログラム）と次のように異なり得る：取引金額及び通貨コードが２０バイトのＡＡＶ中に含まれない、というのは、この情報は署名付きのＰＡＲｅｓメッセージ中に含まれるからである；販売者取引スタンプ（ＭＴＳ：Merchant Transaction Stamp）は取引識別子（ＸＩＤ：Transaction Identifier）として含まれず、署名付きのＰＡＲｅｓメッセージ中に含まれて同じ機能を提供する。さらに、販売者名の省略形フィールドが拡張されている。その結果、ＳＨＡ−１省略形を作成する前に必要な販売者名の編集は最小限で済ませることができる。
【００５１】
販売者は、その後の認可（例えば分割発送）のために制御バイトを修正する必要がない。分割発送のためには、プログラム１０００の３−Ｄセキュア準拠の実現によって生成した元のＡＡＶを再送すればよい。
【００５２】
２０バイトのＳＰＡのＡＡＶ中の制御バイト値は、カード保有者認証要求（ＰＡＲｅｑ）の結果に基づくものである。この結果は、支払者認証応答（ＰＡＲｅｓ：Payer Authentication Response）メッセージの取引状態フィールド中に示すことができる。表４に、ＰＡＲｅｓメッセージ中の取引状態フィールドの好適な値を示す：
【表４】
【００５３】
ＰＡＲｅｑメッセージ中に含まれる販売者名は、販売者名の省略形を作成するより前に編集することができる。この編集は特に、ユニバーサル・トランスファー・フォーマット（ＵＴＦ−８：Universal Transfer Format：汎用転送フォーマット）符号化に応じることができるが、他の種類の符号化用のユニコード（Unicode）（登録商標）文字を参照することもできる。
【００５４】
上記編集は、ユニコード表現を持たないあらゆるＵＴＦ−８バイト・シーケンス（列）を消去することができる。こうした編集は、２進数1111で始まるあらゆるＵＴＦ−８バイト、及びこれに続く２進数10で始まるすべてのバイトを消去することができる。
【００５５】
他の編集は、次のユニコード表現を有するあらゆるＵＴＦ−８バイト・シーケンス、あるいはバイト・シーケンスを消去することができる：
0000〜001F（アスキー制御文字）；
007F〜00A0（”DEL”及び”C1”制御文字）；
00AD（ソフト・ハイフン）；及び、
2000〜206F（一般的な句読点）。
こうした編集は、次のＵＴＦ−８バイトを消去することができる：
１６進数 00〜1F
１６進数 7F
１６進数 C280〜C2A0
１６進数 C2AD
１６進数 E280〜E281AF
さらに他の編集は、あらゆる前後の余白（例えばＵＴＦ−８バイトの１６進数20）を消去することができる
【００５６】
チャージバック（課金）または他にあり得る争議の処理の場合には、２０バイトのＡＡＶを用いて取引に関連する処理パラメータを識別することができる。とりわけ、ＡＡＶフィールド値は次の項目を識別することができる：
・取引を処理した物理的位置
・上記位置についての取引全体中の取引を明確に識別するために使用可能な通し番号
・ＭＡＣを作成するために使用した秘密キー、この秘密キーは、ＡＡＶデータの完全性を保証するだけでなく、ＡＡＶ構造全体を特定のＰＡＮに結合して３−Ｄセキュアを実現する。
【００５７】
ＡＡＶ中のフィールドの依存性は、処理パラメータの適正な識別を保証するように確立することができる。これらのフィールドの依存性は、発行者のＡＣＳ装置を構築または構成する際に考慮することができる。同じＡＣＳ識別子で構成されるすべてのＡＣＳについて：
・ＢＩＮキー識別子フィールドは、識別されたＡＣＳによって処理するＢＩＮ範囲毎に一意的でなければならない。大部分の発行者は、自分のＢＩＮ範囲の大部分または全部について共通のキー組を使用することができる。しかし、この構成は、独立したキー組の使用をサポートするソフトウェア・ベンダー（供給者）の選定、あるいは独立したキー組の使用を必要とする発行者の選定における柔軟性（フレキシビリティ）をもたらす。
・前記取引通し番号フィールドは、チャージバックが発生し得る時間内に識別されたＡＣＳによって生成したＡＡＶ毎に一意的でなければならない。
【００５８】
複数の論理的装置または物理的機械どうしの間でＢＩＮキー及び共通組の取引通し番号を共用する能力を有するＡＣＳ装置は、同じＡＣＳ識別子を使用するように構成することが有利である。あるいはまた、装置毎に別個のＡＣＳ識別子またはＡＣＳ識別子の組が必要になり得る。１台のＡＣＳ設備が複数の発行者として働く場合には、２つ以上の発行者が１つのＡＣＳ識別子を共用することができる。これらの場合には、関連する取引用のＢＩＮフィールド値は、フィールド内容の配置の判断における決定要因となり得る。
【００５９】
ＳＰＡ１３５において特定アルゴリズムを利用して、販売者認証コード（ＭＡＣ）値を生成することができる。例えば、ＡＣＳ識別子サブフィールドによって識別されたＡＣＳが、”ＨＭＡＣ”アルゴリズムまたは”ＣＶＣ２”アルゴリズムを用いてＭＡＣ値を生成することができる。
【００６０】
ＨＭＡＣアルゴリズムは、ＢＩＮキー識別子サブフィールドによって識別される秘密キーに基づいてＭＡＣ値を暗号文で生成する。この秘密キーは発行者と共用し、次のデータの連続体によってカード保有者のアカウント番号をＡＡＶと結び付ける：
・前記アカウント番号は、現在の支払者認証要求（ＰＡＲｅｑ）メッセージに対応する検証要求（ＶＥＲｅｑ）メッセージ中で受信される。このアカウント番号は２進化１０進数（ＢＣＤ）として表現することができ、左詰で右側を１６進数’F’で埋めて２０ディジット（合計１０バイト）の長さにする。
・ＡＡＶの左側１５バイト、即ちフィールド１〜６が構成される。
【００６１】
前記秘密キーの長さは、最小１２８ビット（１６バイト）〜最大１９２ビット（２４バイト）で随意的に選択することができる。この間に入るあらゆるキーサイズ（キー長）（例えば１６０ビット）が許容される。実際に使用するキー長は、実現毎に独立して選択することができる。３−Ｄセキュア認証プログラム（例えばプログラム１０００）用に規定されたＳＰＡのＡＡＶ内のＭＡＣフィールドには、ＨＭＡＣアルゴリズムを適用することによって得られた結果の暗号文を置くことができる。
【００６２】
以下の例１及び例２は、それぞれ２０バイト及び１６バイトのキーを用いたＨＭＡＣアルゴリズムを適用してＳＰＡのＡＡＶを生成する例を示す。
例１（２０バイトのキー）
仮定するアカウント番号：5432 109876543210
仮定する販売者名：”SPA Merchant, Inc.” （ＳＰＡ商会）（すべてアスキー文字、編集不要）
仮定するＡＡＶ制御バイト＝8C
最初の８バイト、即ち販売者名のＳＨＡ−１省略形＝7CA7 FBB6 058B 5114
仮定するＡＣＳのＩｄ（識別番号）＝01
仮定する認証方法＝１（パスワード）
仮定するＢＩＮキーＩｄ＝１
仮定する取引通し番号＝0000002F
仮定するキー（２０バイト）＝
OBOBOBOBOBOBOBOBOBOBOBOBOBOBOBOBOBOBOBOB
従って、ＳＨＡ−１ ＨＭＡＣは、
5432 109876543210 FFFF 8C 7CA7FBB6058B5114 0111 0000002F
に基づく。
この値はＭＡＣを生成し、その最初の５バイトは：
3457 BA1E FF
である。
従って、完全なＡＡＶは１６進数で：
8C 7CA7FBB6058B5114 0000002F 3547BA1EFF
である。
ベース６４符号化した後に、この値は：
jHyn+7YFiIEUAREAAAAvNUe6Hv8=
となる。
例２（１６バイトのキー）
仮定するアカウント番号：5432 109876543210
仮定する販売者名：”SPA Merchant, Inc.” （ＳＰＡ商会）（すべてアスキー文字、編集不要）
仮定するＡＡＶ制御バイト＝8C
最初の８バイト、即ち販売者名のＳＨＡ−１省略形＝7CA7 FBB6 058B 5114
仮定するＡＣＳのＩｄ（識別番号）＝01
仮定する認証方法＝１（パスワード）
仮定するＢＩＮキーＩｄ＝１
仮定する取引通し番号＝0000002F
仮定するキー（２０バイト）＝00112233445566778899AABBCCDDEEFF
従って、ＳＨＡ−１ ＨＭＡＣは、
5432 109876543210 FFFF 8C 7CA7FBB6058B5114 0111 0000002F
に基づく。
この値はＭＡＣを生成し、その最初の５バイトは：
EB27 FC7F AB
である。
従って、完全なＡＡＶは１６進数で：
8C 7CA7FBB6058B5114 0111 0000002F EB27FC7FAB
である。
ベース６４符号化した後に、この値は：
jHyn+7Yfi1 EUAREAAAA v6yf8f6s=
となる。
【００６３】
ＣＶＣ２アルゴリズムも、ＭＡＣフィールド値を暗号文で生成する。ＨＭＡＣアルゴリズムとは対照的に、ＣＶＣ２アルゴリズムは、ＢＩＮキー識別子サブフィールドによって識別される２つの６４ビットＤＥＳキーを用いる。ＣＶＣ２アルゴリズムでは、すべての暗号化及び暗号解読ステップがＤＥＳの電子コードブック（ＥＣＢ：Electronic Code Book）形式を用いることができる。
【００６４】
ＣＶＣ２アルゴリズムは３ディジットのＣＶＣ２値を生成する。ＣＶＣ２アルゴリズムによって処理してこの３ディジットのＣＶＣ２値を生成するための入力データを表５に示す：
【表５】
【００６５】
結果的な３ディジットのＣＶＣ２値は２進化１０進数（ＢＣＤ）形式に変換され、ＭＡＣサブフィールドの左側２バイトに置かれ、その上位に２進数０が用いられて未使用の最初の半バイトが満たされる。ＭＡＣサブフィールドの残りの３バイトは２進数０で満たすことができる。例えば：ＣＶＣ２＝123、ＭＡＣサブフィールド＝0123000000（合計１０ディジット）である。
【００６６】
例３及び表６は、ＣＶＣ２アルゴリズムの適用、及びこのアルゴリズムを適用してＳＰＡのＡＡＶ値を生成することに関係する処理ステップを例示する。
例３
仮定するアカウント番号：5432 109876543210
仮定する販売者名：”SPA Merchant, Inc.” （ＳＰＡ商会）（すべてアスキー文字、編集不要）
仮定するＡＡＶ制御バイト＝8C
最初の８バイト、即ち販売者名のＳＨＡ−１省略形＝7CA7 FBB6 058B 5114
仮定するＡＣＳのＩｄ（識別番号）＝7
仮定する認証方法＝１（パスワード）
仮定するＢＩＮキーＩｄ＝１
仮定する取引通し番号＝0000002F
キーＡ＝0011223344556677、キーＢ＝8899AABBCCDDEEFF
従って、ＣＶＣ２アルゴリズムの計算は、
アカウント番号＝5432109876543210、有効期限日＝0047、
サービスコード＝140
に基づく。
この値は、３ディジットのＣＶＣ２値＝439を生成する。（計算は表６参照）
算出したＣＶＣ２値に基づいて、ＭＡＣフィールド＝0439000000となる。
従って、完全なＡＡＶは１６進数で：
8C 7CA7FBB6058B5114 01 11 0000002F 0439000000
である。
この値をベース６４符号化すれば：
jHyn+7Yfi1 EUAREAAAAvBDkAAAA=
となる。
以上の例３で用いる演算ステップを表６に示す：
【表６】
【００６７】
３−Ｄセキュア・プロトコルによって規定されているように、販売者に返送されるすべてのＰＡＲｅｓメッセージは、関連するカード保有者の発行者ＡＣＳによってディジタル署名されている。販売者は、ＳＰＡのＡＡＶをＰＡＲｅｓメッセージから抽出してアクワイアラに送信する認可要求に含めるより先に、このディジタル署名の有効性を確認する必要があり得る。発行者が３−Ｄセキュアの実現及び他の認証プラットフォームを共にサポートする場合には、前記認可要求メッセージの処理中にこれら２つの認証プラットフォームを区別する必要があり得る。このことは以下の２つの方法のうちの１つによって達成することができる：
１．最初のベース６４符号化された文字は、
ａ．規定された３−Ｄセキュアの実現内のＳＰＡのＡＡＶについては”j”または”h”である。
ｂ．ＰＣ認証のＳＰＡのＡＡＶについては”g”または”A”である。
２．２進数に変換される制御バイトは次のいずれかである：
ａ．マスターカード社の３−Ｄセキュアの実現用に規定されたＡＡＶについては、１６進数”8C”または１６進数”86”
ｂ．ＰＣ認証のＳＰＡのＡＡＶについては、１６進数”82”または１６進数”02”
【００６８】
プログラム１０００に参加中の各発行者は、ＡＣＳ識別子のサブフィールドが、ＭＡＣを生成するのに使用したアルゴリズムを示すように適切に設定されていることを保証することができる。この指標を適正に設定し損なっていれば、取引／決済認可プロセス中に不適正な有効性確認が生じ得る。
【００６９】
本発明は特定の好適な実施例に関連付けて説明してきたが、本発明の範囲を逸脱することなしに、当業者にとって明らかな種々の変形、代替、及び変更を加え得ることは明らかである。
【図面の簡単な説明】
【００７０】
【図１】本発明の原理による、保証付き決済アルゴリズム（ＳＰＡ）を利用してアカウント保有者認証値（ＡＡＶ）を生成する好適な認証プログラムを図式的に示す図である。
【図２】本発明の原理による、図１のＳＰＡの出力を搬送するために使用される汎用カード保有者アカウント・フィールドの構造を図式的に示す図である。
【図３】本発明の原理による好適な決済取引認証プロセスに関係するステップ、及びエンティティ間のリンクの一部を示す図である。
【図４】オンライン決済取引の認証及び認可に関係する好適な認証及び認可エンティティ間のやり取りを図式的に示す図である。
【技術分野】
【０００１】
（優先権及び関連出願のクロスリファレンス）
本願は、米国特許暫定出願番号60/477,187、2003年6月10日出願に基づいて優先権を主張し、その全文を参考文献として本明細書に含める。本願はさらに、国際特許出願番号PCT/US04/17756、2004年6月4日出願、発明の名称”Customer Authentication in E-Commerce Transactions”並びに米国特許出願番号10/096,271、2002年3月11日出願、発明の名称”System and Method for conducting Secure Payment Transactions”にも関連し、後者の第１段落に挙げた優先権主張の基になるいくつかの先行出願共々、参考文献として本明細書に含める。
【背景技術】
【０００２】
（発明の背景）
本発明は、インターネットのような開放型（オープン）電子ネットワーク上で関係者によって行われる取引を認証するシステム及び方法に関するものである。特に、本発明は、顧客がクレジットカードを含む決済カードで支払を後払いするインターネット取引の認証に関するものである。
【０００３】
Ｅ−コマース（電子商取引）は現在、大衆化している。インターネットのような電子ネットワーク上で取引を行うことは現在、販売者及び顧客の双方にとっての利便性、より低いコスト、市場への到達性及び選択性、といったよく言われる利点を有する。しかし、インターネットの匿名性は、商業または小売りの販売に、詐欺及び誤用の問題をもたらす。取引市場は、販売を認証し、販売を証明し、販売を確認し、販売の無拒否を保証し、支払を保証し、そして匿名性を制御したい要望がある。同様に、購入者（バイヤー）は、販売の認証、販売の完全性、悪質な販売の償還請求、販売の確認、プライバシー、及び匿名性を制御したい要望がある。
【０００４】
【特許文献１】米国特許出願10/096,271
【発明の開示】
【０００５】
共同譲渡されている米国特許出願番号10/096,271、2002年3月11日出願は、顧客端末においてユーザ・ソフトウェアを利用して、１つ以上の隠れフィールドを含むことのできるウェブページを表示するために使用する一組のウェブページデータを受信する安全な決済取引を行うシステム及び方法を記載し、その全文を参考文献として本明細書に含む。取引及びカード保有者のデータを有するウェブページは購入データとして販売者に送信される。販売者はこのウェブページデータを、例えば電子的にカード発行者（発行会社）に提出して、決済取引の認証または認可を行う。
【０００６】
カード発行者及び他の金融機関は今日、標準化されたインターネット取引プロトコルを提供または使用して、オンライン取引性能を改善し、電子商取引の成長を加速させている。一部の標準化されたプロトコル（例えばVisa Internationalによって開発された３−Ｄセキュア（登録商標）プロトコル）の下で、カード発行者または発行銀行は取引を認証し、これにより詐欺、及び関連するカード保有者が未承認の取引に起因する払い戻しの生じ易さを低減している。認証取引の存在は、オンライン購入中にカード保有者を認証するよう努力したにもかかわらず詐欺が発生したら、カード発行者がその責任を負うことになり得る。カード発行者または発行銀行は、発行者が認証した取引の支払を受けることを販売者に保証することができる。３−Ｄセキュア（登録商標）プロトコルは、カード発行者によって提供された（例えばVisaまたはMasterCard SecureCode（登録商標）によって検証された）、リモート（遠隔）取引中に販売者が顧客を認証するための認証プログラムと一貫性があり、これらのプログラムの下にある。３−Ｄセキュア（登録商標）プロトコルは、既存のセキュア・ソケッツ・レイヤー（ＳＳＬ：Secure Sockets Layer）暗号化機能をてこ入れし、オンライン・ショッピング（買物）セッション中の発行者によるカード保有者の認証による拡張された安全を提供する。参加中の販売者はMerchant Plug In（ＭＰＩ：販売者プラグイン）（登録商標）と称されるソフトウェア部品を用いて、メッセージを交換し、情報を伝達し、そして参加者に問合せして、オンライン購入中のカード保有者とそのカードの発行者との間の認証セッションを確立する。
【０００７】
３−Ｄセキュア・プロトコル・サービスは、３つのドメイン（領域）モデル、即ち発行者ドメイン、アクワイアラ（加盟店からバリューを回収して現金化する企業体）ドメイン、及び相互運用ドメインの各モデルに基づく。発行者は、サービス中にカード保有者の登録を管理し、オンライン取引中にカード保有者を認証する責任を負う。アクワイアラは、インターネット取引に参加中の販売者がアクワイアラとの合意の下で操作を行う手続きを規定し、認証取引のバックエンド処理を行う責任を負う。相互運用ドメインは、汎用プロトコル及び共用のサービスによって、他の２つのドメイン間の取引交換を促進する。カード保有者及びその取引銀行は「発行者ドメイン」に含むことができ、販売者及びその取引銀行は「アクワイアラ・ドメイン」に含むことができる。発行銀行または金融機関とアクワイアラ銀行または金融機関との間の通信、及びカード発行者のインフラストラクチャ（基盤）は「相互運用ドメイン」に含むことができる。３−Ｄセキュアに準拠する銀行及び販売者と取引する間に、消費者は、取引中の関係者が本当に記録にあるカード保有者であるか否かを判定するための、カード保有者の取引銀行からの独立した認証ウィンドウまたはポップアップ・スクリーンが存在すること以外は、前と同じインターネット・ショッピングを経験することができる。前記プロトコルの下でのオンライン・インターネット購入取引の流れは次の通りである：
(1) 顧客が、販売者のウェブサイトにおいて、暗号化されたセキュア・ソケッツ・レイヤー（ＳＳＬ）接続を介して、通常の方法で決済データを記入する。
(2) 次に販売者は、ＭＰＩを通してメッセージをディレクトリに送信し、このディレクトリはカード発行者に問い合わせて、顧客が３−Ｄセキュア・プログラム中に登録されているか否かを見出す。
(3) カード発行者は前記ディレクトリに、カード保有者が登録されているか否かを示すメッセージで応答して、登録されていれば、このカードを発行した銀行にウェブ・アドレスを提供する。そしてこのメッセージを処理して、販売者に応答を返す。
(4) 次に販売者は、カード保有者の装置を通して発行銀行にメッセージを送信して、カード保有者とカード発行者との間の認証セッションを開始し、このセッションでは、取引明細、例えば販売社名及び取引金額を確認のためにカード保有者に提供することもできる。
(5) 次に発行銀行は認証ウィンドウをカード保有者に提供し、この認証ウィンドウは、販売者名及び金額のような取引に関する情報、個人的なセキュリティ・メッセージ、及びカード保有者が認証の詳細を入力可能な応答領域を詳細に示している。
(6) 顧客は、発行銀行がシステムを実現するために選定した方法に応じて、種々の方法のうちの１つで取引を承認する。選択肢は、静的なパスワードまたはＰＩＮ（個人識別番号）を入力することから、スマートカード及びパーソナル（個人用）カードリーダ（ＰＣＲ：Personal Card Reader）を利用して認証トークンを生成することにまで及ぶ。
(7) 発行者は取引及びカード保有者データを処理して認証を行うことができる。認証が有効であれば、発行者は、取引が成功したことを示すメッセージを販売者に送信する。発行者は、認証に失敗したか認証を完了できなかった場合にも販売者に通知する。このメッセージは、認証プロセスの結果を符号化したアカウント（口座）保有者認証値（ＡＡＶ：Accountholder Authentication Value）を含むことができる。
【０００８】
今日、クレジットカードまたはデビットカードを使用する顧客を認証するための解決法を拡張する方法が考慮されている。顧客またはカードを安全に認証して販売者への支払を行うために使用されるデータ及びアルゴリズムに注意が向けられている。この解決法は、３−Ｄセキュアのような汎用プロトコルの産業上の実現、及びスマートカードが単純かつ静的なパスワードを超えるべく認証を強化するための他の産業規格、例えばＥＭＶ規格と整合すべきである。
【０００９】
（発明の概要）
本発明によれば、オンラインカード保有者取引を認証するための、３−Ｄセキュア・プロトコルに整合した認証プログラムが提供される。この認証プログラムは、アクセス制御サーバー（ＡＣＳ：Access Control Server）を使用してカード保有者の取引を認証する。ＡＣＳは安全決済アルゴリズム（ＳＰＡ：Secure Payment Algorithms）をカード保有者及び取引情報に適用して、暗号化されたアカウント保有者認証値（ＡＡＶ）を生成して、このＡＡＶは認証された取引に割り当てられる。生成されたＡＡＶは、３−Ｄセキュア・プロトコルのメッセージを含むのに適したデータ構造を有する。
【００１０】
本発明の好適例では、前記データ構造が約２０バイトのベース６４符号化した文字を超えない長さを有する。その第１バイトは制御バイトとすることができ、バイト２〜９は販売者名の概略を表現することができ、そしてバイト１０は、カード保有者の取引を認証した特定のＡＣＳを示す。ＡＣＳは種々の認証方法（例えばパスワード・ベース（パスワードに基づくもの）、チップ・ベース、あるいはＰＣ識別法）を用いてカード保有者の取引を認証することができる。前記ＡＡＶデータ構造のバイト１１は、この認証方法、及びＡＣＳが販売者認証コード（ＭＡＣ：Merchant Authentication Code）を生成するために使用した秘密（シークレット）暗号キーを識別する。前記ＡＡＶデータ構造のバイト１２〜１５は、ＡＣＳが処理した取引の通し（シーケンス）番号を識別し、バイト１６〜２０はＭＡＣを表現する。
【００１１】
ＳＰＡは、特定取引用のＭＡＣ値を生成するための適切な暗号化プロセスを含むことができる。１つの暗号化プロセスは秘密（シークレット）キーを用いて、カード保有者のアカウント（口座）番号とＡＡＶのフィールド１〜６（またはバイト１〜１５）との連続体を暗号化する。この暗号化結果の最初の４０ビット（または５バイト）はＭＡＣフィールドに割り当てられる。他の暗号化プロセスでは、一対のデータ・エンクリプション・スタンダード（ＤＥＳ：Data Encryption Standard：米国のデータ暗号化規格）キーを用いて、カード保有者のアカウント番号、カード有効期限日、及びサービスコードを暗号化して、３ディジット（１０進数字）のカード保有者検証コード（ＣＶＣ２：Card Verification Code）番号を生成する。この３ディジットの番号は２進化１０進数（ＢＣＤ：Binary Decimal）に変換され、この２進化１０進数は、前記ＡＡＶデータ構造中のＭＡＣフィールドに置かれて1.5バイトを占める。このＭＡＣフィールドの残りの3.5バイトは、０で埋めるか０を置くことができる。
【００１２】
ＡＡＶデータを含む３−Ｄセキュア・プロトコルの電子メッセージは、前記アクセス制御サーバー（ＡＣＳ）によってディジタル署名することができる。ＡＡＶデータを含むメッセージを受信する販売者は、前記ＡＡＶデータを抽出する前に、３−Ｄセキュア・プロトコルに従って前記ディジタル署名の有効性を確認することを求められる。販売者は、前記ＡＡＶデータ、及び特に前記ＭＡＣデータを、決済認証要求メッセージに転送することができる。
【００１３】
本発明のさらなる特徴、性質、及び種々の利点は、以下の図面を参照した実施例の詳細な説明より一層明らかになる。
【００１４】
各図面を通して、特に断わりのない限り、同一参照番号及び符号は、図示する実施例の同様の特徴、素子、構成要素、または部分を表わすために用いている。
【００１５】
（実施例の詳細な説明）
本発明は、電子取引における遠隔的な（リモート）関係者を認証するための解決法を提供する。特に、この解決法は、電子取引に遠隔的に参加するカード保有者を認証するために用いる安全決済アプリケーション（例えば図１のＳＰＡ１３５）に関係する。この解決法は、工業規格のｅ−コマース（電子商取引）プラットフォーム上、例えば３−Ｄセキュア準拠のｅ−コマース・プラットフォーム上、及び郵便注文（メールオーダー）及び電話注文、あるいは移動装置のような非ｅ−コマース環境における取引認証に用いることができ、こうした非ｅ−コマース環境では発行者が認証トークンまたはコードを用いてカード保有者を認証することができる。
【００１６】
表１は、本明細書で用いるいくつかの用語、頭文字、または省略形の語彙辞典である：
【表１】
【００１７】
以下、図１を参照しながら説明する。ＳＰＡ１３５は、カード保有者認証検証値（ＣＡＶＶ）を、３−Ｄセキュア・メッセージ・フォーマットに整合するフォーマットで生成するために使用する暗号文アルゴリズム（即ち”ＨＭＡＣ”及び”ＣＶＣ２”アルゴリズム）を含むことができる。
【００１８】
ＳＰＡ１３５は、カード発行者が当該カードの保有者を認証するために選定または実現可能なあらゆる適切な認証プログラムと統合することができる。これらの認証プログラムは、スマートカード・ベース及びパスワード・ベースの解決法（例えば、図１のチップ・ベースの認証プログラム１４１及び３−Ｄセキュアのパスワード・ベースの認証プログラム１４２）を含むことができる。これらの認証プログラムは、例えばＰＣ識別に基づく他の解決法を含むことができる。
【００１９】
本発明の安全決済アプリケーション（ＳＰＡ１３５）を利用した認証プログラムは、３−Ｄセキュア・プロトコルに準拠したｅ−コマース・プラットフォーム上で行われる電子取引を安全にするための解決法またはプログラムとすることができる。この目的のために、ＳＰＡ１３５は、３−Ｄセキュア・メッセージ中で容易に使用可能なデータ・フォーマットの認証結果を使用し生成するように設計されている。特に、規定のフィールド及びバイト長を有するフォーマット化されたデータ構造は、認証結果を３−Ｄセキュア・メッセージ中で搬送することを促進するために使用することができる。
【００２０】
好適な認証プログラム１０００（図１）におけるＳＰＡ１３５の適用を図示する目的で、ここではカード決済取引を好適な取引として用いる。このカード決済取引への参加者は、カード保有者、発行者、販売者、及びアクワイアラを含むことができる。
【００２１】
カード保有者は、例えば認証プログラム１０００のライセンス（使用許諾された）メンバーによって発行された決済カードの認可ユーザである。カード保有者は、発行された決済カードを用いて販売者とのオンライン取引を決済することができる。認証プログラム１０００は、サードパーティ（第三者機関）によって提供される認証プログラムまたはサービスの一部とすることができ、このサードパーティは例えば、カード保有者のアイデンティティ（正体）及び存在が取引の完了に先立って適正に認証されることを保証することができる。
【００２２】
発行者は決済カードを発行するメンバー（例えば金融機関）であり、銘柄（商標）を付けることができる（例えばマスターカード（登録商標）及び／またはMaestro cards（登録商標））。発行者は、決済カードの銘柄の規定及び地域的な法規に従って、決済カードを使用する認可された取引に対する支払を保証する。発行者は、販売者または他の関係者に認証サービスを提供することに加えて、カード保有者が認証プログラム１０００に参加する資格を判定する責任を負う。
【００２３】
販売者は、小売人、あるいは、例えば販売者加入契約に従い、発行者の決済カードが適正に提示された際に、これらのカードでの支払いを受け付ける他の個人、商店、会社である。認証プログラム１０００に加入することによって、販売者は加入者に、インターネット上での認証された電子的やり取りを提供することができる。決済カードを受け付ける販売者はさらにアクワイアラとの関係を持つ。認証プログラム１０００に参加する販売者は、詐欺及び争議のコストの低減、取引量の増加、無認可カードの使用防止、及び発行者のカードベースへのアクセスを含むいくつかの形の恩恵を受けることができる。
【００２４】
アクワイアラは、販売者との関係を維持し、取引に関するデータを販売者またはカード受け付け者から取得するエンティティ（実体）である。アクワイアラは、販売者が認証プログラム１０００に参加する資格を判定する役割をすることができる。
【００２５】
図１に示すように、好適な認証プログラム１０００は、階層化された複数の構成要素を有する安全なｅ−コマースの構成またはプラットフォームとして実現することができる。これらの階層化された構成要素は、データ搬送（トランスポート）層１００、販売者の要求層１２０、認証層１３０、及び発行者プラットフォーム１４０を含む。認証層１３０は、取引または決済（支払）を認証するために設けられた安全決済アプリケーション（ＳＰＡ１３５）に関係する。
【００２６】
データ搬送層１００は、カード保有者、発行者、販売者及びアクワイアラの間で認証情報及び結果を通信するデータ収集及び搬送インフラストラクチャに関係する。データ搬送は、例えば汎用カード保有者認証フィールド（ＵＣＡＦ、表１参照）のような標準化されたデータ構造、アーキテクチャまたはメカニズムに基づくものとすることができる。
【００２７】
ＵＣＡＦは一般に、フレキシブル（柔軟）なデータ構造を有する可変長、３２文字のフィールドとして規定することができ、種々の発行者のセキュリティ及び認証方法の必要性をサポートするように仕立てることができる。図２に、ＵＣＡＦの一般的な構造を示す。ＵＣＡＦ中の最初の制御バイトは、各セキュリティ決済アプリケーションまたは態様に特有の値を含む。ＵＣＡＦ中の残りのバイトはアプリケーション特有のデータを含むことができる。認証または認可プロバイダ（提供者）は、ＵＣＡＦの制御バイト値、及びＵＣＡＦアプリケーション特有のデータの構造を割り当て及び管理する役割をすることができる。
【００２８】
好適な制御バイトの規定は次のようにすることができる：
使用法 最初及びその後の取引用の３−ＤセキュアＳＰＡのＡＡＶ
ベース６４符号化値 ｊ
１６進数の値 ｘ’８Ｃ’
他の好適な制御バイトの規定は次のようにすることができる：
使用法 試行用の３−ＤセキュアＳＰＡのＡＡＶ
ベース６４符号化値 ｊ
１６進数の値 ｘ’８６’
【００２９】
従来のＵＣＡＦ実現では、アプリケーション特有のデータは、制御バイトを含めて最大２４バイトの長さを有する２進数（バイナリ）データとして規定することができる。しかし、一部の取引認可ネットワークは、認可メッセージ中の２進数データの通過を制限する。従って、認証プログラム１０００中でＳＰＡ１３５が生成するすべてのＵＣＡＦデータは、認証メッセージ中に含めるより先にベース６４符号化することができる。ベース６４符号化手順は、関連する２進数データの文字表現である。結果的な文字表現は、等価な２進数の約３倍の大きさ（長さ）である。この理由により、ＵＣＡＦフィールドは一般に最大長３２文字で規定することができる。しかし、認証プログラム１０００における３−Ｄセキュア・メッセージ送信との整合のために、ＵＣＡＦフィールドは２８文字の長さに制限される。
【００３０】
アカウント保有者認証値（ＡＡＶ）は、ＳＰＡを含む発行者の認証プラットフォームに関係するＵＣＡＦの特定実現である。ＡＡＶは、発行者によるカード保有者の認証が良好であった際に発行者が生成して販売者に提供し、（アクワイアラへの）取引認証要求中に置くことができる。チャージバック（課金、料金徴収）または他のあり得る争議の場合には、ＡＡＶを用いて取引に関連する処理パラメータを識別することができる。ＵＣＡＦは、認証プロセス中に認証目的でＡＡＶを販売者から発行者に送信するために使用するメカニズムである。
【００３１】
再び図１を参照しながら説明する。販売者要求層１２０は、他の層及びカード保有者とやり取りする販売者能力に関係する。認証プログラム１０００に参加中の販売者は、３−Ｄセキュア・メッセージを処理することのできるアプリケーション・ソフトウェア能力（例えば販売者プラグイン（ＭＰＩ：Merchant Plug-Ins））を実現することができる。ＭＰＩは、３−Ｄセキュア・メッセージを処理する制御アプリケーションとして働くことができる。
【００３２】
本発明のＳＰＡ１３５を含む認証層１３０は、カード保有者アカウントの所有権を検証するための（例えば発行者によって提供されるか、あるいは発行者と契約した）認証プロセスまたはサービスを表わす。例えばアクセス制御サーバー（ＡＣＳ）を使用する発行者は、認証層１３０／ＳＰＡ１３５をＡＡＶ確認サーバー／プロセスと共同で実現することができる。
【００３３】
前記認証プロセスに関係する好適なｅ−コマース・ネットワークの構成要素またはエンティティは、例示目的で、表２に示す発行者、アクワイアラ、または相互運用性ドメイン（領域）に属するものとして組織することができる。
【表２】
【００３４】
表２に示すように、発行者ドメイン中に存在する機能は、（アクワイアラ・ドメイン中の）ＭＰＩと（発行者ドメイン中の）アクセス制御サーバーとの間でメッセージを搬送するための導管として作用することのできるカード保有者ブラウザを含む。関連のカード保有者ソフトウェアは例えば、スマートカードの使用をサポートするためのオプション的なソフトウェアを含むことができる。登録サーバーは、認証プログラム１０００の下で発行者が３−Ｄセキュアを実現するためのカード保有者登録プロセスを手助けする。このサーバーは、最初のカード保有者認証を実行するため、並びにリセット、３−Ｄセキュア決済履歴の視認のような管理活動用に用いることができる。
【００３５】
アクセス制御サーバーは、オンライン購入の過程中に少なくとも２つの基本機能を提供する。第１に、ＡＣＳは、与えられたカード保有者アカウント番号がプログラム１０００中に登録されているか否かを検証する。第２に、ＡＣＳはカード保有者識別用の認証プロセスを実行する。この目的のために、ＡＣＳはＡＡＶ確認サーバー／プロセスと協働するか、あるいはＡＡＶ確認サーバー／プロセスを含むことができる。このＡＡＶ確認サーバー／プロセスは、販売者またはアクワイアラから受信したカード保有者認証データの有効性を確認するために使用することもできる。
【００３６】
アクワイアラ・ドメイン中の機能は、販売者プラグイン（ＭＰＩ）及び署名確認サーバーの機能を含むことができる。ＭＰＩは、支払者認証メッセージを作成して処理し、そして販売者ソフトウェアに制御を戻してさらなる認証処理を行わせることができる。ＭＰＩ認証プロセスは、カード保有者が決済（支払）に使用するアカウント番号を含む購入要求を提出した後であるが購入の認可を得るより先に呼び出すことができる。署名確認サーバーは、発行者によって問題なく認可された購入要求上のディジタル署名の有効性を確認するために使用することができる。
【００３７】
相互運用性ドメイン中の機能はディレクトリ・サーバーを含むことができる。ディレクトリ・サーバーは、認証プログラム１０００中に登録された販売者に、集中化された決定（判定）能力を提供するグローバル・ディレクトリ・サーバーとすることができる。販売者の検証要求メッセージ中に含まれるアカウント番号に基づいて、ディレクトリ・サーバーはまず、このアカウント番号が参加中のカード発行者のカード範囲の一部をなすか否かを判定する。ディレクトリ・サーバーは次に、資格のある要求を適切な発行者のＡＣＳに向けてさらなる処理をさせる。相互運用性ドメインは、末端エンティティ及びその従属者から成るすべての私的な階層の証明書を、要求に応じて生成して、これら３つのドメインにわたる種々の構成要素及び他の従属的な証明当局に分配するのに適した証明当局（機関）を含むことができる。
【００３８】
プログラム１０００中のカード保有者認証プロセスは、これら３つのドメイン間でのメッセージ及びデータの交換を含む。次の好適な３−Ｄセキュア・ドメイン間メッセージを認証プロセス中で段階的に用いることができる：
(1) 確認要求／応答
メッセージ対：ＶＥＲｅｑ／ＶＥＲｅｓ
【００３９】
認証プロセス中の第１ステップは、カード保有者のアカウント番号が、認証プログラム１０００に参加中の発行者のカード範囲の一部をなすことをチェックまたは確認することである。この目的のために、検証要求メッセージＶＥＲｅｑがＭＰＩからディレクトリ・サーバーに送信されて、カード範囲の資格がチェックされる。指定されたアカウント番号がディレクトリ・サーバー内の有資格のカード範囲内に含まれる場合には、このメッセージをディレクトリ・サーバーから発行者のＡＣＳに転送して、前記指定のアカウント番号が発行者によってプログラム１０００中の参加者として登録、及び／または有効にされているか否かをさらにチェックすることができる。
【００４０】
ＭＰＩは、参加中の各発行者がカード範囲をローカル（自分の所）にキャッシュ記憶する随意的な能力を有する。こうした場合には、ＭＰＩはカード範囲要求／応答メッセージを用いて、ディレクトリ・サーバーからカード範囲キャッシュの更新を要求することができる。カード範囲をキャッシュ記憶する販売者にとっては、発行者が認証プログラム１０００中に登録されていないことをローカルキャッシュが示す場合にはＶＥＲｅｑ／ＶＥＲｅｓメッセージを利用することができない。
【００４１】
(2) 支払者認証要求／応答
メッセージ対：ＰＡＲｅｑ／ＰＡＲｅｓ
一旦、カード保有者が発行者によって登録されているか、あるいはプログラム１０００中の有効な参加者であることが判明すると、この特定カード保有者を認証するプロセスにはさらに、前記特定カード発行者が関与する。支払者認証要求／応答メッセージをＭＰＩから前記特定カード発行者のＡＣＳに送信して認証を実行することができる。プログラム１０００中の認証プロセスのこの段階では、カード保有者に認証ウィンドウを提供することができる。この認証ウィンドウをカード保有者のブラウザ上に表示して、発行者が関連情報をこのウィンドウ内に置くことができる。カード保有者は、個人識別または認証用のパスワード、コードまたはトークンを、表示された認証ウィンドウを通して入力することを要求される。そして前記特定カード発行者のＡＣＳは、例えばＳＰＡ１３５を用いて、収集し、あるいは入力された情報を認証して、これに従いアカウント保有者認証値（ＡＡＶ）を生成することができる。このＡＡＶは、ＵＣＡＦ内の指定されたカード保有者認証検証値（ＣＡＶＶ）（表１参照）フィールド内の３−ＤセキュアＰＡＲｅｓメッセージ中で搬送される。
【００４２】
ＣＡＶＶは、発行者によって要求中の販売者に返送されたメッセージ対ＰＡＲｅｑ／ＰＡＲｅｓの応答部分中のデータフィールドのうちの１つである。発行者は適切なディジタル署名を自分の応答上に置くことができる。販売者はさらに、受信したＡＡＶを決済／取引認証要求（図４参照）の一部として含めてアクワイアラに送信して発行者に転送させることができる。
【００４３】
図３に、認証プログラム１０００の下でのカード保有者取引用の好適なカード認証プロセス３００を図式的に示す。例示目的のため、以下のプロセス３００の説明は、カード保有者３１０が発行者によって認証プログラム１０００中に登録され、参加中の販売者の所でオンラインで買い物（ショッピング）をする間に使用するパスワードまたはコードを発行者から取得済みであるものと仮定する。プロセス３００は、構成要素間のすべての通信チャンネルが、セキュア・ソケット・レイヤー・プロトコル（ＳＳＬ（登録商標）：Secure Sockets Layer：保証付きソケット層）のリンク（例えばＳＳＬ−１、ＳＳＬ−２、ＳＳＬ−３、ＳＳＬ−４、ＳＳＬ−５及びＳＳＬ−６）を用いて適正な安全性を有することも仮定する。
【００４４】
プロセス３００中のステップ３５１では、カード保有者３１０が販売者のウェブサイトで買い物をして、精算（チェックアウト）する段になると、決済カード情報（例えばアカウント番号）及び他の情報（例えば発送情報）をリンクＳＳＬ−１経由で入力する。一旦、すべての決済（支払）及び発送情報を入力すると、販売者はカード保有者３１０に、注文を提出する前に購入を再点検する機会を与えることができる。
【００４５】
次のステップ３５２では、ＭＰＩ３２０がリンクＳＳＬ−２経由でディレクトリ・サーバー３３０に、カード保有者３１０の特定発行者による登録を検証することを、検証要求メッセージＶＥＲｅｑを用いて要求する。ステップ３５２は随意的に、ＭＰＩ３２０においてローカル・カード・ディレクトリ・キャッシュによってローカルで実行することができる。ＶＥＲｅｑメッセージに応答して、ディレクトリ・サーバー３３０は、特定発行者が参加中であることを判定して、これにより、要求をリンクＳＳＬ−３経由で前記特定発行者のＡＣＳ３４０に転送して、カード保有者３１０の現在の登録状態を照査することができる。結果的な応答は同じリンク（例えばＳＳＬ−３及びＳＳＬ−２）上でＭＰＩ３２０に戻される。カード保有者３１０がプログラム１０００中に登録されていることをＡＣＳ３４０が示す場合には、ＭＰＩ３２０は支払者認証要求メッセージを作成して、ステップ３５４においてこのメッセージをリンクＳＳＬ−４経由でカード保有者のブラウザに送信することができる。次のステップ３５５では、カード保有者のブラウザが前記メッセージを適切な発行者のＡＣＳ３４０に向かわせて、カード保有者認証を開始することができる。ＡＣＳ３４０が前記支払者認証要求メッセージを受信すると、ＡＣＳ３４０はユーザ認証の対話を開始させることができる。このユーザ認証の対話の一部として、ＡＣＳ３４０は別個の対話型認証ウィンドウをカード保有者３１０に対して表示して、カード保有者３１０によるパスワード、コード、または他のデータの入力を促すことができる。
【００４６】
ステップ３５６では、ＡＣＳ３４０は（ＳＰＡ１３５を用いて）、カード保有者３１０によって入力されたパスワードまたはコードを認証することができる。ＡＣＳ３４０は、認証プログラムの提供者（プロバイダ）による３−Ｄセキュアの実現により、ＳＰＡのＡＡＶを構成することができる。ＡＣＳ３４０は適切な支払者認証応答メッセージを構成してディジタル署名することができる。そしてこの支払者認証応答メッセージは（リンクＳＳＬ−６経由で）ＭＰＩ３２０に戻される。この時点では、カード保有者３１０に対して表示される認証ウィンドウは消失させることができる。
【００４７】
カード保有者認証プロセス３００が完了した後に、販売者は、受信したＳＰＡのＡＡＶを、認可メッセージ内のＵＣＡＦフィールドを介してアクワイアラに渡すことを要求され得る。そしてこのＳＰＡのＡＡＶは、従来の認可メッセージ処理の一部として、アクワイアラから発行者に渡される。発行者がＡＡＶを受信すると、認可要求処理の一部としてその有効性を確認し、そしてアーカイブ記録して、後に発生し得るカード保有者の争議の解決に使用することができる。
【００４８】
標準的な３−Ｄセキュアのバージョン1.0.2のメッセージ・フォーマット及びデータ・フォーマットは、関与する関係者またはエンティティ間のすべてのデータ通信に用いることができる。特に、ＡＣＳ３４０が作成して販売者に返送し、販売者がＵＣＡＦメッセージ中に含めるＳＰＡのＡＡＶは２８文字長であり、３−Ｄセキュアのベース６４符号化用に規定された２０バイトのフィールドを含む。
【００４９】
表３に、前記２０バイトのＳＰＡのＡＡＶの好適なデータ構造またはフォーマットを示す：
【表３】
【００５０】
３−Ｄセキュアの解決法に加えて、既存のＰＣ識別及び他の認証の解決法（例えば図１）を共に提供する発行者は、異なる認証の解決法から対応する認証メッセージ中で受け取ったＡＡＶ値どうしを区別することができる。３−Ｄセキュアに整合するプログラム１０００から生じた２０バイトのＡＡＶ（例えば表２）は、一般的な２８倍とのＡＡＶ構造（即ち、非３−Ｄセキュア・プログラム）と次のように異なり得る：取引金額及び通貨コードが２０バイトのＡＡＶ中に含まれない、というのは、この情報は署名付きのＰＡＲｅｓメッセージ中に含まれるからである；販売者取引スタンプ（ＭＴＳ：Merchant Transaction Stamp）は取引識別子（ＸＩＤ：Transaction Identifier）として含まれず、署名付きのＰＡＲｅｓメッセージ中に含まれて同じ機能を提供する。さらに、販売者名の省略形フィールドが拡張されている。その結果、ＳＨＡ−１省略形を作成する前に必要な販売者名の編集は最小限で済ませることができる。
【００５１】
販売者は、その後の認可（例えば分割発送）のために制御バイトを修正する必要がない。分割発送のためには、プログラム１０００の３−Ｄセキュア準拠の実現によって生成した元のＡＡＶを再送すればよい。
【００５２】
２０バイトのＳＰＡのＡＡＶ中の制御バイト値は、カード保有者認証要求（ＰＡＲｅｑ）の結果に基づくものである。この結果は、支払者認証応答（ＰＡＲｅｓ：Payer Authentication Response）メッセージの取引状態フィールド中に示すことができる。表４に、ＰＡＲｅｓメッセージ中の取引状態フィールドの好適な値を示す：
【表４】
【００５３】
ＰＡＲｅｑメッセージ中に含まれる販売者名は、販売者名の省略形を作成するより前に編集することができる。この編集は特に、ユニバーサル・トランスファー・フォーマット（ＵＴＦ−８：Universal Transfer Format：汎用転送フォーマット）符号化に応じることができるが、他の種類の符号化用のユニコード（Unicode）（登録商標）文字を参照することもできる。
【００５４】
上記編集は、ユニコード表現を持たないあらゆるＵＴＦ−８バイト・シーケンス（列）を消去することができる。こうした編集は、２進数1111で始まるあらゆるＵＴＦ−８バイト、及びこれに続く２進数10で始まるすべてのバイトを消去することができる。
【００５５】
他の編集は、次のユニコード表現を有するあらゆるＵＴＦ−８バイト・シーケンス、あるいはバイト・シーケンスを消去することができる：
0000〜001F（アスキー制御文字）；
007F〜00A0（”DEL”及び”C1”制御文字）；
00AD（ソフト・ハイフン）；及び、
2000〜206F（一般的な句読点）。
こうした編集は、次のＵＴＦ−８バイトを消去することができる：
１６進数 00〜1F
１６進数 7F
１６進数 C280〜C2A0
１６進数 C2AD
１６進数 E280〜E281AF
さらに他の編集は、あらゆる前後の余白（例えばＵＴＦ−８バイトの１６進数20）を消去することができる
【００５６】
チャージバック（課金）または他にあり得る争議の処理の場合には、２０バイトのＡＡＶを用いて取引に関連する処理パラメータを識別することができる。とりわけ、ＡＡＶフィールド値は次の項目を識別することができる：
・取引を処理した物理的位置
・上記位置についての取引全体中の取引を明確に識別するために使用可能な通し番号
・ＭＡＣを作成するために使用した秘密キー、この秘密キーは、ＡＡＶデータの完全性を保証するだけでなく、ＡＡＶ構造全体を特定のＰＡＮに結合して３−Ｄセキュアを実現する。
【００５７】
ＡＡＶ中のフィールドの依存性は、処理パラメータの適正な識別を保証するように確立することができる。これらのフィールドの依存性は、発行者のＡＣＳ装置を構築または構成する際に考慮することができる。同じＡＣＳ識別子で構成されるすべてのＡＣＳについて：
・ＢＩＮキー識別子フィールドは、識別されたＡＣＳによって処理するＢＩＮ範囲毎に一意的でなければならない。大部分の発行者は、自分のＢＩＮ範囲の大部分または全部について共通のキー組を使用することができる。しかし、この構成は、独立したキー組の使用をサポートするソフトウェア・ベンダー（供給者）の選定、あるいは独立したキー組の使用を必要とする発行者の選定における柔軟性（フレキシビリティ）をもたらす。
・前記取引通し番号フィールドは、チャージバックが発生し得る時間内に識別されたＡＣＳによって生成したＡＡＶ毎に一意的でなければならない。
【００５８】
複数の論理的装置または物理的機械どうしの間でＢＩＮキー及び共通組の取引通し番号を共用する能力を有するＡＣＳ装置は、同じＡＣＳ識別子を使用するように構成することが有利である。あるいはまた、装置毎に別個のＡＣＳ識別子またはＡＣＳ識別子の組が必要になり得る。１台のＡＣＳ設備が複数の発行者として働く場合には、２つ以上の発行者が１つのＡＣＳ識別子を共用することができる。これらの場合には、関連する取引用のＢＩＮフィールド値は、フィールド内容の配置の判断における決定要因となり得る。
【００５９】
ＳＰＡ１３５において特定アルゴリズムを利用して、販売者認証コード（ＭＡＣ）値を生成することができる。例えば、ＡＣＳ識別子サブフィールドによって識別されたＡＣＳが、”ＨＭＡＣ”アルゴリズムまたは”ＣＶＣ２”アルゴリズムを用いてＭＡＣ値を生成することができる。
【００６０】
ＨＭＡＣアルゴリズムは、ＢＩＮキー識別子サブフィールドによって識別される秘密キーに基づいてＭＡＣ値を暗号文で生成する。この秘密キーは発行者と共用し、次のデータの連続体によってカード保有者のアカウント番号をＡＡＶと結び付ける：
・前記アカウント番号は、現在の支払者認証要求（ＰＡＲｅｑ）メッセージに対応する検証要求（ＶＥＲｅｑ）メッセージ中で受信される。このアカウント番号は２進化１０進数（ＢＣＤ）として表現することができ、左詰で右側を１６進数’F’で埋めて２０ディジット（合計１０バイト）の長さにする。
・ＡＡＶの左側１５バイト、即ちフィールド１〜６が構成される。
【００６１】
前記秘密キーの長さは、最小１２８ビット（１６バイト）〜最大１９２ビット（２４バイト）で随意的に選択することができる。この間に入るあらゆるキーサイズ（キー長）（例えば１６０ビット）が許容される。実際に使用するキー長は、実現毎に独立して選択することができる。３−Ｄセキュア認証プログラム（例えばプログラム１０００）用に規定されたＳＰＡのＡＡＶ内のＭＡＣフィールドには、ＨＭＡＣアルゴリズムを適用することによって得られた結果の暗号文を置くことができる。
【００６２】
以下の例１及び例２は、それぞれ２０バイト及び１６バイトのキーを用いたＨＭＡＣアルゴリズムを適用してＳＰＡのＡＡＶを生成する例を示す。
例１（２０バイトのキー）
仮定するアカウント番号：5432 109876543210
仮定する販売者名：”SPA Merchant, Inc.” （ＳＰＡ商会）（すべてアスキー文字、編集不要）
仮定するＡＡＶ制御バイト＝8C
最初の８バイト、即ち販売者名のＳＨＡ−１省略形＝7CA7 FBB6 058B 5114
仮定するＡＣＳのＩｄ（識別番号）＝01
仮定する認証方法＝１（パスワード）
仮定するＢＩＮキーＩｄ＝１
仮定する取引通し番号＝0000002F
仮定するキー（２０バイト）＝
OBOBOBOBOBOBOBOBOBOBOBOBOBOBOBOBOBOBOBOB
従って、ＳＨＡ−１ ＨＭＡＣは、
5432 109876543210 FFFF 8C 7CA7FBB6058B5114 0111 0000002F
に基づく。
この値はＭＡＣを生成し、その最初の５バイトは：
3457 BA1E FF
である。
従って、完全なＡＡＶは１６進数で：
8C 7CA7FBB6058B5114 0000002F 3547BA1EFF
である。
ベース６４符号化した後に、この値は：
jHyn+7YFiIEUAREAAAAvNUe6Hv8=
となる。
例２（１６バイトのキー）
仮定するアカウント番号：5432 109876543210
仮定する販売者名：”SPA Merchant, Inc.” （ＳＰＡ商会）（すべてアスキー文字、編集不要）
仮定するＡＡＶ制御バイト＝8C
最初の８バイト、即ち販売者名のＳＨＡ−１省略形＝7CA7 FBB6 058B 5114
仮定するＡＣＳのＩｄ（識別番号）＝01
仮定する認証方法＝１（パスワード）
仮定するＢＩＮキーＩｄ＝１
仮定する取引通し番号＝0000002F
仮定するキー（２０バイト）＝00112233445566778899AABBCCDDEEFF
従って、ＳＨＡ−１ ＨＭＡＣは、
5432 109876543210 FFFF 8C 7CA7FBB6058B5114 0111 0000002F
に基づく。
この値はＭＡＣを生成し、その最初の５バイトは：
EB27 FC7F AB
である。
従って、完全なＡＡＶは１６進数で：
8C 7CA7FBB6058B5114 0111 0000002F EB27FC7FAB
である。
ベース６４符号化した後に、この値は：
jHyn+7Yfi1 EUAREAAAA v6yf8f6s=
となる。
【００６３】
ＣＶＣ２アルゴリズムも、ＭＡＣフィールド値を暗号文で生成する。ＨＭＡＣアルゴリズムとは対照的に、ＣＶＣ２アルゴリズムは、ＢＩＮキー識別子サブフィールドによって識別される２つの６４ビットＤＥＳキーを用いる。ＣＶＣ２アルゴリズムでは、すべての暗号化及び暗号解読ステップがＤＥＳの電子コードブック（ＥＣＢ：Electronic Code Book）形式を用いることができる。
【００６４】
ＣＶＣ２アルゴリズムは３ディジットのＣＶＣ２値を生成する。ＣＶＣ２アルゴリズムによって処理してこの３ディジットのＣＶＣ２値を生成するための入力データを表５に示す：
【表５】
【００６５】
結果的な３ディジットのＣＶＣ２値は２進化１０進数（ＢＣＤ）形式に変換され、ＭＡＣサブフィールドの左側２バイトに置かれ、その上位に２進数０が用いられて未使用の最初の半バイトが満たされる。ＭＡＣサブフィールドの残りの３バイトは２進数０で満たすことができる。例えば：ＣＶＣ２＝123、ＭＡＣサブフィールド＝0123000000（合計１０ディジット）である。
【００６６】
例３及び表６は、ＣＶＣ２アルゴリズムの適用、及びこのアルゴリズムを適用してＳＰＡのＡＡＶ値を生成することに関係する処理ステップを例示する。
例３
仮定するアカウント番号：5432 109876543210
仮定する販売者名：”SPA Merchant, Inc.” （ＳＰＡ商会）（すべてアスキー文字、編集不要）
仮定するＡＡＶ制御バイト＝8C
最初の８バイト、即ち販売者名のＳＨＡ−１省略形＝7CA7 FBB6 058B 5114
仮定するＡＣＳのＩｄ（識別番号）＝7
仮定する認証方法＝１（パスワード）
仮定するＢＩＮキーＩｄ＝１
仮定する取引通し番号＝0000002F
キーＡ＝0011223344556677、キーＢ＝8899AABBCCDDEEFF
従って、ＣＶＣ２アルゴリズムの計算は、
アカウント番号＝5432109876543210、有効期限日＝0047、
サービスコード＝140
に基づく。
この値は、３ディジットのＣＶＣ２値＝439を生成する。（計算は表６参照）
算出したＣＶＣ２値に基づいて、ＭＡＣフィールド＝0439000000となる。
従って、完全なＡＡＶは１６進数で：
8C 7CA7FBB6058B5114 01 11 0000002F 0439000000
である。
この値をベース６４符号化すれば：
jHyn+7Yfi1 EUAREAAAAvBDkAAAA=
となる。
以上の例３で用いる演算ステップを表６に示す：
【表６】
【００６７】
３−Ｄセキュア・プロトコルによって規定されているように、販売者に返送されるすべてのＰＡＲｅｓメッセージは、関連するカード保有者の発行者ＡＣＳによってディジタル署名されている。販売者は、ＳＰＡのＡＡＶをＰＡＲｅｓメッセージから抽出してアクワイアラに送信する認可要求に含めるより先に、このディジタル署名の有効性を確認する必要があり得る。発行者が３−Ｄセキュアの実現及び他の認証プラットフォームを共にサポートする場合には、前記認可要求メッセージの処理中にこれら２つの認証プラットフォームを区別する必要があり得る。このことは以下の２つの方法のうちの１つによって達成することができる：
１．最初のベース６４符号化された文字は、
ａ．規定された３−Ｄセキュアの実現内のＳＰＡのＡＡＶについては”j”または”h”である。
ｂ．ＰＣ認証のＳＰＡのＡＡＶについては”g”または”A”である。
２．２進数に変換される制御バイトは次のいずれかである：
ａ．マスターカード社の３−Ｄセキュアの実現用に規定されたＡＡＶについては、１６進数”8C”または１６進数”86”
ｂ．ＰＣ認証のＳＰＡのＡＡＶについては、１６進数”82”または１６進数”02”
【００６８】
プログラム１０００に参加中の各発行者は、ＡＣＳ識別子のサブフィールドが、ＭＡＣを生成するのに使用したアルゴリズムを示すように適切に設定されていることを保証することができる。この指標を適正に設定し損なっていれば、取引／決済認可プロセス中に不適正な有効性確認が生じ得る。
【００６９】
本発明は特定の好適な実施例に関連付けて説明してきたが、本発明の範囲を逸脱することなしに、当業者にとって明らかな種々の変形、代替、及び変更を加え得ることは明らかである。
【図面の簡単な説明】
【００７０】
【図１】本発明の原理による、保証付き決済アルゴリズム（ＳＰＡ）を利用してアカウント保有者認証値（ＡＡＶ）を生成する好適な認証プログラムを図式的に示す図である。
【図２】本発明の原理による、図１のＳＰＡの出力を搬送するために使用される汎用カード保有者アカウント・フィールドの構造を図式的に示す図である。
【図３】本発明の原理による好適な決済取引認証プロセスに関係するステップ、及びエンティティ間のリンクの一部を示す図である。
【図４】オンライン決済取引の認証及び認可に関係する好適な認証及び認可エンティティ間のやり取りを図式的に示す図である。
【特許請求の範囲】
【請求項１】
電子ネットワーク上でのカード保有者の販売者との取引を認証するシステムにおいて、
少なくとも１つの３−Ｄセキュア（登録商標）認証プログラムを含む発行者プラットフォームの層と；
販売者プラグイン（ＭＰＩ）と；
保証付き決済アルゴリズム（ＳＰＡ）と；
データ搬送層とを具えて、
前記発行者プラットフォームが、前記ＳＰＡを用いて前記取引及び前記カード保有者の情報を処理し認証方法によって認証してアカウント保有者認証値（ＡＡＶ）を生成し、前記ＡＡＶを前記データ搬送層を通して前記ＭＰＩに搬送するアクセス制御サーバー（ＡＣＳ）を具え、
前記ＡＡＶが、３−Ｄセキュア・メッセージ・プロトコルに整合したフォーマット化されたデータ構造であり、前記フォーマット化されたデータ構造が最大２０バイトの長さを有し、前記販売者の名前の省略形を識別するバイト、前記ＡＣＳを識別するバイト、前記認証方法を識別するバイト、秘密暗号文キーを識別するバイト、及び販売者認証コード（ＭＡＣ）を含むバイトを含むことを特徴とする取引認証システム。
【請求項２】
前記ＡＡＶが、ベース６４符号化されてフォーマット化されたデータ構造であることを特徴とする請求項１に記載のシステム。
【請求項３】
前記ＳＰＡが前記ＭＡＣを生成するための暗号化アルゴリズムを具え、該暗号化アルゴリズムが、前記ＡＡＶ中で識別される秘密キーを用いて、前記カード保有者のアカウント番号と前記ＡＡＶのバイトのうち前記ＭＡＣを表わすバイトを除いたバイトの複数フィールドとの連続体を暗号化し、前記暗号化の結果の一部が前記ＡＡＶ中の前記ＭＡＣのバイトを形成することを特徴とする請求項１に記載のシステム。
【請求項４】
前記ＳＰＡが前記ＭＡＣを生成するための暗号化アルゴリズムを具え、前記暗号化アルゴリズムが、前記ＡＡＶ中で識別される一対の秘密キーＡ及びＢを用いて、前記カード保有者のアカウント番号、カードの有効期限日、及びサービスコードの連続体を暗号化して３ディジットのＣＶＣ２フィールドを生成して、前記ＭＡＣ中の２バイトに置くことを特徴とする請求項１に記載のシステム。
【請求項５】
前記一対の秘密キーＡ及びＢが、６４ビットのデータ・エンクリプション・スタンダード（ＤＥＳ）キーであることを特徴とする請求項４に記載のシステム。
【請求項６】
前記ＡＣＳが、前記ＭＰＩから前記ＡＣＳへの決済認証要求メッセージに応答して前記ＡＡＶを生成すべく構成されていることを特徴とする請求項１に記載のシステム。
【請求項７】
前記ＡＡＶを、前記ＡＣＳからの決済認証応答メッセージ中で搬送すべく構成されていることを特徴とする請求項１に記載のシステム。
【請求項８】
前記ＡＣＳがさらに、前記決済認証応答メッセージ上にディジタル署名を配置すべく構成されていることを特徴とする請求項７に記載のシステム。
【請求項９】
前記ＭＰＩが、受信した前記決済認証応答メッセージ上の前記ディジタル署名を検証すべく構成されていることを特徴とする請求項１に記載のシステム。
【請求項１０】
前記ＭＰＩが、前記ＡＣＳからの決済認証応答メッセージ中に含まれる前記ＭＡＣのフィールドを抽出し、前記抽出したＭＡＣを、第三者への決済認証要求メッセージ中に配置すべく構成されていることを特徴とする請求項１に記載のシステム。
【請求項１１】
３−Ｄセキュア環境における関係者間でカード保有者の取引認証情報を搬送するためのデータ構造において、
前記データ構造が、２０バイトのベース６４符号化された文字を具え、前記２０バイトの第１バイトが制御バイトであり、第２〜９バイトが販売者名の省略形を表わし、第１０バイトが、前記カード保有者の取引を認証方法によって認証するアクセス制御サーバー（ＡＣＳ）を識別し、第１１バイトが、前記認証方法、及び前記ＡＣＳが販売者認証コード（ＭＡＣ）を生成するために使用した秘密暗号化キーを識別し、第１２〜１５バイトが、前記ＡＣＳによって処理された取引の番号を識別する取引通し番号を表わし、第１６〜２０バイトが前記ＭＡＣを表わすことを特徴とする取引認証情報搬送用データ構造。
【請求項１２】
前記ＭＡＣが、前記カード保有者のアカウント番号と前記データ構造の第１〜１５バイトの複数フィールドとの連続体を暗号化したものの部分を含み、前記第１１バイトにおいて識別される単一のキーを前記暗号化に使用することを特徴とする請求項１１に記載のデータ構造。
【請求項１３】
前記ＭＡＣが、前記カード保有者のアカウント番号、カード有効期限日、及びサービスコードの連続体を暗号化したものの部分を含み、前記第１１バイトにおいて識別される一対の秘密キーＡ及びＢを前記暗号化に使用することを特徴とする請求項１１に記載のデータ構造。
【請求項１４】
前記ＭＡＣの第１６〜２０バイトに３ディジットの暗号化結果を置いたことを特徴とする請求項１３に記載のデータ構造。
【請求項１５】
前記一対の秘密キーＡ及びＢが、６４ビットのデータ・エンクリプション・スタンダード（ＤＥＳ）であることを特徴とする請求項１３に記載のデータ構造。
【請求項１６】
３−Ｄセキュア環境における電子ネットワーク上でのカード保有者の販売者との取引を認証する方法において、
アクセス制御サーバー（ＡＣＳ）を用いて、前記カード保有者及び前記取引の情報を処理して、認証方法によって前記カード保有者を認証するステップと；
保証付き決済アルゴリズム（ＳＰＡ）を実行して、前記認証の結果を表わすアカウント保有者認証値（ＡＡＶ）を生成するステップと；
前記ＡＡＶを３−Ｄセキュア・メッセージ中で前記販売者に搬送するステップとを具ええて、
前記ＡＡＶが、最大２０バイトの長さを有するフォーマット化されたデータ構造であり、前記販売者の名前の省略形を識別するバイト、前記ＡＣＳを識別するバイト、前記認証方法を識別するバイト、販売者認証コード（ＭＡＣ）を含むバイト、及び前記ＳＰＡが前記ＭＡＣを生成するために使用する秘密暗号文キーを識別するバイトを含むことを特徴とする取引認証方法。
【請求項１７】
前記ＡＡＶが、ベース６４符号化されてフォーマット化されたデータ構造であることを特徴とする請求項１６に記載の方法。
【請求項１８】
前記ＳＰＡを実行するステップが、
前記ＡＡＶ中で識別される秘密キーを用いて、前記カード保有者のアカウント番号と、前記ＡＡＶのバイトのうち前記ＭＡＣを表わすバイトを除いたバイトの少なくとも一部分との連続体を暗号化するステップと；
前記暗号化の結果の一部分を、前記ＡＡＶ中の前記ＭＡＣのバイトに割り当てるステップと
を具えていることを特徴とする請求項１６に記載の方法。
【請求項１９】
前記ＳＰＡを実行するステップが、
前記ＡＡＶ中で識別される一対の秘密キーＡ及びＢを用いて、前記カード保有者のアカウント番号、カードの有効期限日、及びサービスコードの連続体を暗号化して、３ディジットのＣＶＣ２フィールドを生成するステップと；
前記生成した結果を、前記ＭＡＣ中の２バイトに割り当てるステップと
を具えていることを特徴とする請求項１６に記載の方法。
【請求項２０】
前記一対の秘密キーＡ及びＢが、６４ビットのデータ・エンクリプション・スタンダード（ＤＥＳ）キーであることを特徴とする請求項１７に記載の方法。
【請求項２１】
前記ＡＡＶを３−Ｄセキュア・メッセージ中で前記販売者に搬送するステップが、前記ＡＡＶを、前記ＡＣＳによってディジタル署名された決済認証応答メッセージ中で搬送するステップを具えていることを特徴とする請求項１６に記載の方法。
【請求項２２】
さらに、
まず、前記販売者が、受信した前記決済認証応答メッセージ上の前記ディジタル署名を検証するステップと；
次に、前記販売者が、前記受信した前記決済認証応答メッセージから前記ＭＡＣのフィールドを抽出するステップと
を具えていることを特徴とする請求項２１に記載の方法。
【請求項１】
電子ネットワーク上でのカード保有者の販売者との取引を認証するシステムにおいて、
少なくとも１つの３−Ｄセキュア（登録商標）認証プログラムを含む発行者プラットフォームの層と；
販売者プラグイン（ＭＰＩ）と；
保証付き決済アルゴリズム（ＳＰＡ）と；
データ搬送層とを具えて、
前記発行者プラットフォームが、前記ＳＰＡを用いて前記取引及び前記カード保有者の情報を処理し認証方法によって認証してアカウント保有者認証値（ＡＡＶ）を生成し、前記ＡＡＶを前記データ搬送層を通して前記ＭＰＩに搬送するアクセス制御サーバー（ＡＣＳ）を具え、
前記ＡＡＶが、３−Ｄセキュア・メッセージ・プロトコルに整合したフォーマット化されたデータ構造であり、前記フォーマット化されたデータ構造が最大２０バイトの長さを有し、前記販売者の名前の省略形を識別するバイト、前記ＡＣＳを識別するバイト、前記認証方法を識別するバイト、秘密暗号文キーを識別するバイト、及び販売者認証コード（ＭＡＣ）を含むバイトを含むことを特徴とする取引認証システム。
【請求項２】
前記ＡＡＶが、ベース６４符号化されてフォーマット化されたデータ構造であることを特徴とする請求項１に記載のシステム。
【請求項３】
前記ＳＰＡが前記ＭＡＣを生成するための暗号化アルゴリズムを具え、該暗号化アルゴリズムが、前記ＡＡＶ中で識別される秘密キーを用いて、前記カード保有者のアカウント番号と前記ＡＡＶのバイトのうち前記ＭＡＣを表わすバイトを除いたバイトの複数フィールドとの連続体を暗号化し、前記暗号化の結果の一部が前記ＡＡＶ中の前記ＭＡＣのバイトを形成することを特徴とする請求項１に記載のシステム。
【請求項４】
前記ＳＰＡが前記ＭＡＣを生成するための暗号化アルゴリズムを具え、前記暗号化アルゴリズムが、前記ＡＡＶ中で識別される一対の秘密キーＡ及びＢを用いて、前記カード保有者のアカウント番号、カードの有効期限日、及びサービスコードの連続体を暗号化して３ディジットのＣＶＣ２フィールドを生成して、前記ＭＡＣ中の２バイトに置くことを特徴とする請求項１に記載のシステム。
【請求項５】
前記一対の秘密キーＡ及びＢが、６４ビットのデータ・エンクリプション・スタンダード（ＤＥＳ）キーであることを特徴とする請求項４に記載のシステム。
【請求項６】
前記ＡＣＳが、前記ＭＰＩから前記ＡＣＳへの決済認証要求メッセージに応答して前記ＡＡＶを生成すべく構成されていることを特徴とする請求項１に記載のシステム。
【請求項７】
前記ＡＡＶを、前記ＡＣＳからの決済認証応答メッセージ中で搬送すべく構成されていることを特徴とする請求項１に記載のシステム。
【請求項８】
前記ＡＣＳがさらに、前記決済認証応答メッセージ上にディジタル署名を配置すべく構成されていることを特徴とする請求項７に記載のシステム。
【請求項９】
前記ＭＰＩが、受信した前記決済認証応答メッセージ上の前記ディジタル署名を検証すべく構成されていることを特徴とする請求項１に記載のシステム。
【請求項１０】
前記ＭＰＩが、前記ＡＣＳからの決済認証応答メッセージ中に含まれる前記ＭＡＣのフィールドを抽出し、前記抽出したＭＡＣを、第三者への決済認証要求メッセージ中に配置すべく構成されていることを特徴とする請求項１に記載のシステム。
【請求項１１】
３−Ｄセキュア環境における関係者間でカード保有者の取引認証情報を搬送するためのデータ構造において、
前記データ構造が、２０バイトのベース６４符号化された文字を具え、前記２０バイトの第１バイトが制御バイトであり、第２〜９バイトが販売者名の省略形を表わし、第１０バイトが、前記カード保有者の取引を認証方法によって認証するアクセス制御サーバー（ＡＣＳ）を識別し、第１１バイトが、前記認証方法、及び前記ＡＣＳが販売者認証コード（ＭＡＣ）を生成するために使用した秘密暗号化キーを識別し、第１２〜１５バイトが、前記ＡＣＳによって処理された取引の番号を識別する取引通し番号を表わし、第１６〜２０バイトが前記ＭＡＣを表わすことを特徴とする取引認証情報搬送用データ構造。
【請求項１２】
前記ＭＡＣが、前記カード保有者のアカウント番号と前記データ構造の第１〜１５バイトの複数フィールドとの連続体を暗号化したものの部分を含み、前記第１１バイトにおいて識別される単一のキーを前記暗号化に使用することを特徴とする請求項１１に記載のデータ構造。
【請求項１３】
前記ＭＡＣが、前記カード保有者のアカウント番号、カード有効期限日、及びサービスコードの連続体を暗号化したものの部分を含み、前記第１１バイトにおいて識別される一対の秘密キーＡ及びＢを前記暗号化に使用することを特徴とする請求項１１に記載のデータ構造。
【請求項１４】
前記ＭＡＣの第１６〜２０バイトに３ディジットの暗号化結果を置いたことを特徴とする請求項１３に記載のデータ構造。
【請求項１５】
前記一対の秘密キーＡ及びＢが、６４ビットのデータ・エンクリプション・スタンダード（ＤＥＳ）であることを特徴とする請求項１３に記載のデータ構造。
【請求項１６】
３−Ｄセキュア環境における電子ネットワーク上でのカード保有者の販売者との取引を認証する方法において、
アクセス制御サーバー（ＡＣＳ）を用いて、前記カード保有者及び前記取引の情報を処理して、認証方法によって前記カード保有者を認証するステップと；
保証付き決済アルゴリズム（ＳＰＡ）を実行して、前記認証の結果を表わすアカウント保有者認証値（ＡＡＶ）を生成するステップと；
前記ＡＡＶを３−Ｄセキュア・メッセージ中で前記販売者に搬送するステップとを具ええて、
前記ＡＡＶが、最大２０バイトの長さを有するフォーマット化されたデータ構造であり、前記販売者の名前の省略形を識別するバイト、前記ＡＣＳを識別するバイト、前記認証方法を識別するバイト、販売者認証コード（ＭＡＣ）を含むバイト、及び前記ＳＰＡが前記ＭＡＣを生成するために使用する秘密暗号文キーを識別するバイトを含むことを特徴とする取引認証方法。
【請求項１７】
前記ＡＡＶが、ベース６４符号化されてフォーマット化されたデータ構造であることを特徴とする請求項１６に記載の方法。
【請求項１８】
前記ＳＰＡを実行するステップが、
前記ＡＡＶ中で識別される秘密キーを用いて、前記カード保有者のアカウント番号と、前記ＡＡＶのバイトのうち前記ＭＡＣを表わすバイトを除いたバイトの少なくとも一部分との連続体を暗号化するステップと；
前記暗号化の結果の一部分を、前記ＡＡＶ中の前記ＭＡＣのバイトに割り当てるステップと
を具えていることを特徴とする請求項１６に記載の方法。
【請求項１９】
前記ＳＰＡを実行するステップが、
前記ＡＡＶ中で識別される一対の秘密キーＡ及びＢを用いて、前記カード保有者のアカウント番号、カードの有効期限日、及びサービスコードの連続体を暗号化して、３ディジットのＣＶＣ２フィールドを生成するステップと；
前記生成した結果を、前記ＭＡＣ中の２バイトに割り当てるステップと
を具えていることを特徴とする請求項１６に記載の方法。
【請求項２０】
前記一対の秘密キーＡ及びＢが、６４ビットのデータ・エンクリプション・スタンダード（ＤＥＳ）キーであることを特徴とする請求項１７に記載の方法。
【請求項２１】
前記ＡＡＶを３−Ｄセキュア・メッセージ中で前記販売者に搬送するステップが、前記ＡＡＶを、前記ＡＣＳによってディジタル署名された決済認証応答メッセージ中で搬送するステップを具えていることを特徴とする請求項１６に記載の方法。
【請求項２２】
さらに、
まず、前記販売者が、受信した前記決済認証応答メッセージ上の前記ディジタル署名を検証するステップと；
次に、前記販売者が、前記受信した前記決済認証応答メッセージから前記ＭＡＣのフィールドを抽出するステップと
を具えていることを特徴とする請求項２１に記載の方法。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公表番号】特表２００７−５１７２７２（Ｐ２００７−５１７２７２Ａ）
【公表日】平成１９年６月２８日（２００７．６．２８）
【国際特許分類】
【出願番号】特願２００６−５３３７４１（Ｐ２００６−５３３７４１）
【出願日】平成１６年６月１０日（２００４．６．１０）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０１８６５８
【国際公開番号】ＷＯ２００５／００１６３５
【国際公開日】平成１７年１月６日（２００５．１．６）
【出願人】（５００５５７８６４）マスターカード インターナシヨナル インコーポレーテツド (18)
【Ｆターム（参考）】
【公表日】平成１９年６月２８日（２００７．６．２８）
【国際特許分類】
【出願日】平成１６年６月１０日（２００４．６．１０）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０１８６５８
【国際公開番号】ＷＯ２００５／００１６３５
【国際公開日】平成１７年１月６日（２００５．１．６）
【出願人】（５００５５７８６４）マスターカード インターナシヨナル インコーポレーテツド (18)
【Ｆターム（参考）】
[ Back to top ]