JP2006527430A - 商業取引における顧客認証システム及び方法 - Google Patents

Abstract

電子商取引における顧客認証用の、３−Ｄセキュア・プロトコルに基づくチップ認証プログラムを提供する。
オンライン取引で顧客(180)を認証するための、３−Ｄセキュア・プロトコルに基づくチップ認証プログラムを提供する。発行者は決済カードの発行者とすることができ、ＥＭＶ準拠の個人用スマートカード(170)によって識別される個々の顧客(180)による取引を認証するためのアクセス制御兼認証要求サーバー(120)を運用する。取引毎に、やり取りの箇所(POI)において、顧客のスマートカード(170)からの情報、及び発行者によって直接送信された取引特有の情報に基づいて認証トークンが生成され、ＰＯＩにウェブページが提供される。ＰＯＩにおいて生成された前記認証トークンは前記認証要求サーバー(120)によって評価され、取引ＰＯＩにおける個々の顧客及び／またはカードの存在が認証される。この認証値は、指定された３−Ｄセキュア・プロトコル準拠の汎用カード保有者認証フィールド(UCAF)にオンラインで搬送される。

Description

（関連出願のクロスリファレンス）
本願は、米国特許暫定出願第60/475,639号、2003年7月4日出願にもとづいて優先権を主張し、この出願は参考文献として本明細書に含める。

（発明の背景）
本発明は、インターネットのような開放型（オープン）ネットワーク上で関係者によって行われる認証取引のシステム及び方法に関するものである。特に、本発明は、顧客が支払（決済）をクレジットカードまたはデビットカードで行うインターネット取引の認証に関するものである。

ｅ−コマース（電子商取引）は今日、大衆化している。インターネットのような電子ネットワーク上で取引を行うことは今日、販売者及び顧客の双方にとって、利便性、より低いコスト、市場への到達性及び市場の選択性、といったよく言われる利点を有する。しかし、インターネットの匿名性は、商業または小売りの販売に、詐欺及び誤用の問題をもたらす。取引市場は、販売を認証し、販売を証明し、販売を確認し、販売の無拒否を保証し、支払を保証し、そして匿名性を制御したい要望がある。同様に、購入者（バイヤー）は、販売の認証、販売の完全性、悪質な販売の償還請求、販売の確認、プライバシー、及び匿名性を制御したい要望がある。

国際特許出願 WO03073389

共同発明及び共同所有の国際特許出願WO03073389には、インターネット上で行われる顧客−販売者の取引において顧客を認証するネットワーク決済システムが記載され、この出願は参考文献として本明細書に含める。インターネットは、販売者のサーバー及び顧客端末を決済サーバーにリンク（連結）させる。顧客は集積回路（ＩＣ）カード（ＩＣＣ：Integrated Circuit Card）を識別装置として用いる。ＩＣＣはカードリーダ（カード読取装置）を介して顧客端末と通信する。ＩＣＣは、未決済の取引についての情報に応答して暗号文を生成する。この情報は、顧客端末が生成するチャレンジ・メッセージとすることができる。カードリーダは、ＩＣＣが生成する暗号文の一部を一意的な認証トークンに変換して、この認証トークンは、インターネット上で例えば決済サーバーに送信して、顧客を認証することができる。

米国特許 6,282,522

他のインターネット決済システムは、インターネット上で購入した商品及び／またはサービスの決済用の「スマート」チップカードに頼るものであり、米国特許第6,282,522号、発明者Davis他に記載され、この特許は参考文献として本明細書に含める。ＩＣＣ及び他のスマートカードは、一般的な産業仕様（例えば、Europay International, Mastercard International及びVisa Internationalによって共同開発されたＥＭＶ（登録商標）規格）に基づき、種々の決済システム間での相互運用性を可能にすることができる。

カード発行者（発行会社）及び他の金融機関は今日、標準化されたインターネット取引プロトコルを提供または使用して、オンライン取引性能を改善し、電子商取引の成長を加速させている。一部の標準化されたプロトコル（例えばVisa Internationalによって開発された３−Ｄセキュア（登録商標）プロトコル）の下で、カード発行者または発行銀行は取引を認証し、これにより詐欺、及び関連するカード保有者が未承認の取引に起因する払い戻しの生じ易さを低減している。認証取引の存在は、オンライン購入中にカード保有者を認証するよう努力したにもかかわらず詐欺が発生したら、カード発行者がその責任を負うことになり得る。販売者はカード発行者または発行銀行によって、発行者が認証した取引の支払を受けることを保証されている。３−Ｄセキュア（登録商標）プロトコルは、カード発行者によって提供された（例えばVisaまたはMasterCard SecureCode（登録商標）によって検証された）、リモート（遠隔）取引中に販売者が顧客を認証するための認証プログラムと一貫性があり、これらのプログラムの下にある。３−Ｄセキュア（登録商標）プロトコルは、既存のセキュア・ソケッツ・レイヤー（ＳＳＬ：Secure Sockets Layer）暗号化機能をてこ入れし、オンライン・ショッピング（買物）セッション中の発行者によるカード保有者の認証による拡張された安全を提供する。参加中の販売者はMerchant Plug In（ＭＰＩ：販売者のプラグイン）（登録商標）と称されるソフトウェア部品を用いて、メッセージを交換し、情報を伝達し、そして参加者に問合せして、オンライン購入中のカード保有者とそのカードの発行者との間の認証セッションを確立する。

３−Ｄセキュア・プロトコル・サービスは、３つのドメイン（領域）モデル、即ち発行者ドメイン、アクワイアラ（加盟店からバリューを回収して現金化する企業体）ドメイン、及び相互運用ドメインの各モデルに基づく。発行者は、サービス中にカード保有者の登録を管理し、オンライン取引中にカード保有者を認証する責任を負う。アクワイアラは、インターネット取引に参加中の販売者がアクワイアラとの合意の下で操作を行う手続きを規定し、認証取引のバックエンド処理を行う責任を負う。相互運用ドメインは、汎用プロトコル及び共用のサービスによって、他の２つのドメイン間の取引交換を促進する。カード保有者及びその取引銀行は「発行者ドメイン」に入れることができ、販売者及びその取引銀行は「発行者ドメイン」に入れることができる。発行銀行または金融機関とアクワイアラ銀行または金融機関との間の通信、及びカード発行者のインフラストラクチャ（基盤）は「相互運用ドメイン」に入れることができる。３−Ｄセキュアに準拠する銀行及び販売者と取引する間に、消費者は、取引中の関係者が本当に記録にあるカード保有者であるか否かを判定するための、カード保有者の取引銀行からの独立した認証ウィンドウまたはポップアップ・スクリーンが存在すること以外は、前と同じインターネット・ショッピングを経験することができる。前記プロトコルの下でのオンライン・インターネット購入取引の流れは次の通りである：
(1) 顧客が、販売者のウェブサイトにおいて、暗号化されたセキュア・ソケッツ・レイヤー（ＳＳＬ）接続を介して、通常の方法で決済データを記入する。
(2) 次に販売者は、ＭＰＩを通してメッセージをディレクトリに送信し、このディレクトリはカード発行者に問い合わせて、顧客が３−Ｄセキュア・プログラム中に登録されているか否かを見出す。
(3) カード発行者は前記ディレクトリに、カード保有者が登録されているか否かを示すメッセージで応答して、登録されていれば、このカードを発行した銀行にウェブ・アドレスを提供する。そしてこのメッセージを処理して、販売者に応答を返す。
(4) 次に販売者は、カード保有者の装置を通して発行銀行にメッセージを送信して、カード保有者とカード発行者との間の認証セッションを開始し、このセッションでは、取引明細、例えば販売社名及び取引金額を確認のためにカード保有者に提供することもできる。
(5) 次に発行銀行は認証ウィンドウをカード保有者に提供し、この認証ウィンドウは、販売者名及び金額のような取引に関する情報、個人的なセキュリティ・メッセージ、及びカード保有者が認証の詳細を入力可能な応答領域を詳細に示している。
(6) 顧客は、発行銀行がシステムを実現するために選定した方法に応じて、種々の方法のうちの１つで取引を承認する。選択肢は、静的なパスワードまたはＰＩＮ（個人識別番号）を入力することから、スマートカード及びパーソナル（個人用）カードリーダ（ＰＣＲ：Personal Card Reader）を利用して認証トークンを生成することにまで及ぶ。
(7) 認証が有効であれば、発行者は、取引が成功したことを示すメッセージを販売者に送信する。発行者は、認証に失敗したか認証を完了できなかった場合にも販売者に通知する。

今日、クレジットカードまたはデビットカードを使用する顧客を認証するための解決法を拡張する方法が考慮されている。やり取りの場所（ＰＯＩ：Point of Interaction）でカード保有者を認証して、ＰＯＩにおけるカード及びカード保有者の双方の存在の明示的な証拠を生成することによって、販売者のインターネット販売チャンネルを安全にするための解決法に注意が向けられている。望まれる解決法は、３−Ｄセキュアのような汎用プロトコルの産業上の実現、及びスマートカードが単純かつ静的なパスワードを超えるべく認証を強化するための他の産業規格、例えばＥＭＶ規格と整合すべきである。

（発明の概要）
本発明によれば、ｅ−コマースにおける顧客取引を認証するための、３−Ｄセキュア・プロトコルに基づくチップ認証プログラム（ＣＡＰ：Chip Authentication Program）が提供される。ＣＡＰの実現は、既存のｅ−コマース・インフラストラクチャ及び技術の最上層におくことができ、ＥＭＶ及び３−Ｄセキュア技術の両者のシームレスな（継ぎ目のない）統合をもたらし、従来の静的なパスワードの解決法より強力な認証が得られる。ＣＡＰ実現は、オンライン販売者が、顧客のアイデンティティ（正体）が直ちに検証される物理的な販売時点取引を旧式的な小売り者が享受することの保証と同様の全地球的な支払保証を、決済カードの発行者から受けるメカニズムを提供する。

ＣＡＰでは、発行者（例えば決済カードの発行会社）が認証サービスを取引毎のベースで関係者に提供する。発行者はアクセス制御サーバー及びこれに関連する認証要求サーバーを運用して、プログラム中に登録されている顧客による取引を認証する。やり取りの場所（ＰＯＩ）で取引毎に認証トークンを作成し、各取引について、顧客及び当該取引を一意的に識別する暗号化情報にもとづく認証が要求される。取引中の顧客は、集積回路チップカード（ＩＣＣ）内に埋め込まれたＥＭＶベースの認証アプリケーションを、ＰＯＩにおけるトークン作成用の個人識別子として用いる。前記トークンに含めるための、販売者または取引に特有の情報は、例えば通常のインターネット・ブラウザのウェブページをＰＯＩに提供することによって、発行者が直接ＰＯＩに提供することができる。ＣＡＰの実現は、ＰＯＩ（例えば顧客のアクセス装置）における販売者に特有のソフトウェア（例えばアプレット（ウェブ上の小規模アプリケーション））の別個のダウンロードまたは表示を必要としないことが有利である。

ＰＯＩにおいて生成される認証トークンはＡＲＳ（Access Request Server：アクセス要求サーバー）によって評価されて、取引のＰＯＩにおける顧客及び／またはカードの存在が認証される。この評価の完了時に、ＡＡＶ（アカウント保有者認証値）がＡＣＳ（Access Control Server：アクセス制御サーバー）によって生成される。このＡＡＶは電子ネットワーク上で、３−Ｄセキュア・プロトコルに整合するフォーマットのＵＣＡＦ（汎用カード保有者認証フィールド）中で搬送される。

電子ネットワーク上の顧客の取引を認証する本発明のシステムは、ネットワーク・アクセス装置、顧客に対し発行され、顧客識別データを含む集積回路チップ、前記アクセス装置に（物理的に、電子的に、あるいはカード保有者の手動操作を介して）リンク（連絡）可能であり、かつ前記チップと通信可能なリーダ、及び前記電子ネットワークにリンクされ、取引の認証を要求中の関係者と通信可能な認証要求サーバー（ＡＲＳ）及びアクセス制御サーバー（ＡＣＳ）を具えていることが好ましい。前記ＡＣＳは、（例えばカード保有者の認証ページを介して）顧客のアクセス装置と直接通信可能なように構成されている。この直接の通信は、要求中の関係者（例えば販売者）から顧客のアクセス装置への認証ソフトウェア（例えば販売者に特有のアプレット）のダウンロードを不要にする。前記ＡＲＳは、要求中の関係者から取引情報を受信して、取引データを顧客のアクセス装置経由で前記リーダに伝達する。前記リーダはこの取引データを処理して、この取引データに基づく値を前記チップに伝える。前記チップは、前記取引データの少なくとも一部分、及びこのチップ上の顧客識別データの少なくとも一部分に基づいて暗号文を生成するための認証アプリケーションを有する。前記リーダは、前記暗号文に基づいて認証トークンを生成して前記ＡＲＳに伝達することができ、前記ＡＲＳは、前記認証トークンからの前記顧客識別データを評価し、これにより前記認証トークンの有効性を確認すべく構成されている。前記認証トークンは、３−Ｄセキュア・プロトコルのメッセージ・フォーマットの共通フォーマットにすることができる。前記認証トークンの評価が無事（良い結果で）完了すると、前記ＡＣＳはＡＡＶを生成し、このＡＡＶは前記電子ネットワーク上で、20バイトの長さを有するＵＣＡＦ中で搬送される。

前記ＡＲＳは、まず前記チップが前記暗号文を生成するために使用したデータを再構成し、次に前記再構成したデータから複製または再生成の暗号文を生成し、そして前記認証トークンを前記複製暗号文と整合させることによって、前記認証トークンからの前記顧客識別データを評価する。

ネットワーク・アクセス装置を用いた電子取引に参加中の顧客のリモート認証を行う本発明の方法は、顧客識別データを有するＩＣチップを顧客に提供するステップと、顧客のネットワーク・アクセス装置にリンク可能かつ前記チップと通信可能なリーダを用意するステップを具えていることが好ましい。この方法はさらに、前記電子ネットワークにリンクされ、前記リーダにデータを伝達可能な認証要求サーバー（ＡＲＳ）を用いて、取引に特有の情報を受信して、この取引に特有のデータを前記リーダに伝達するステップと、前記リーダを用いて、前記取引に特有のデータを前記チップに伝達し、前記取引に特有のデータの少なくとも一部分及び前記顧客識別データの少なくとも一部分に基づいて暗号文を生成することを前記チップに命令するステップと、前記リーダを用いて、前記チップが生成した暗号文の少なくとも一部分に基づいて認証トークンを生成するステップとを具えている。前記方法は追加的に、前記ＡＲＳを用いて前記認証トークンの有効性を確認し、これにより、ＵＣＡＦメッセージを前記電子ネットワーク上で発行者に搬送するためのＡＡＶを生成するステップを具えている。

本発明のさらなる特徴、性質、及び種々の利点は、以下の図面を参照した実施例の説明より一層明らかになる。

（実施例の詳細な説明）
以下、本発明の実施例について図面を参照しながら詳細に説明する。

各図面中では、特に断わりのない限り、同一参照番号及び符号は、図に示す実施例の同様の特徴、素子、構成要素、または部分を表わす。

本発明は、電子取引における遠隔地の（リモート）関係者を認証する解決法を提供する。特に、この解決法は、遠隔地から（リモートで）電子取引に参加するカード保有者を認証することに関係する。この解決法は、産業において標準化されたｅ−コマース（電子商取引）プラットフォーム上、例えば３−Ｄセキュア準拠のｅ−コマース・プラットフォーム上で行われる電子取引関連の認証にも関係し、また、発行者が認証トークンを用いてカード保有者を認証することのできる非ｅ−コマース環境関連の取引、例えばメールオーダー（郵便注文）及び電話注文、あるいは移動装置にも関係し得る。

１つの解決法である「チップ認証プログラム（ＣＡＰ：Chip Authentication Program）」は、カード発行者または発行銀行に認証エンティティ（主体）としての特別な地位を与える。このエンティティは、アクセス制御サーバー及びこれに関連するアクセス要求サーバーを運用して、プログラム中に登録されている顧客を認証する。ＣＡＰは、ＩＣチップカード（例えばＩＣＣ）に埋め込まれたＥＭＶベースの認証アプリケーションを利用し、これらのＩＣチップカードは登録されたカード保有者に対して発行される。カード保有者は、オンライン取引中にＩＣＣ内のＥＭＶベースの認証アプリケーションを使用して、特定取引のための遠隔認証を得ることができる。この認証アプリケーションは、販売者−顧客の「対面」取引用に設計された前記チップカード内の他の従来のＥＭＶ決済アプリケーションとは別個にすることも、従来のアプリケーションに追加することもできる。

カード保有者は、前記ＩＣＣをパーソナル（個人用）カードリーダ（ＰＣＲ）と共に用いて、１回使用の動的な「セキュア・コード」または認証トークンを生成することができる。この目的のために（例えば、このセキュア・コードを受信するために）、カード保有者認証ページを生成して、カード保有者のインターネット・アクセス装置に表示することができる。このカード保有者認証ページは、カード保有者の装置上に他のソフトウェアを事前にインストールするかあるいは追加する特別な必要性なしに、発行者のアクセス制御サーバーによって完全に制御することができる。他の安全な解決法は、例えば、静的なパスワードによる認証を含む。ＣＡＰは、スマートカード用の標準的な技術のいずれかを用いて実現できることは明らかである。しかし、この実現は、標準的なＥＭＶチップ技術を用いて行うことが好ましい。

ＣＡＰは、ｅ−コマース決済及び発行者のサービスの認証のための信頼性あるメカニズムを提供することができる。ＣＡＰは、一般的な決済システム・ネットワークを通る従来の認証ルート（経路）を、決済取引認証に利用することができる。ＣＡＰの１つのバージョンは、販売者、アクワイアラ、及び発行者のシステム間のエンド−ツー−エンドの相互運用のための３−Ｄセキュア・バージョン1.0.2インフラストラクチャと互換性があり、ここでは、これらのシステムのすべてが、一般的に合意された産業上の規格による３−Ｄセキュア・インフラストラクチャをサポートしなければならないものとする。

参考文献として本明細書に含まれる国際特許出願WO03073389は、パーソナル・カードリーダ（ＰＣＲ）を用いたＩＣＣ認証プログラムを記載し、このＰＣＲは、認証トークンを生成して、この認証トークンは、３−Ｄセキュア技術ではなく汎用カード保有者認証フィールド（ＵＣＡＦ：Universal Cardholder Authentication Field）中で発行者に搬送され、販売者において一連のマスターカード社（登録商標）規定の隠れハイパーテキスト・マークアップ言語（ＨＴＭＬ：HyperText Markup Language）フィールドに変換され、発行者、カード保有者、及び販売者間で認証データを交換する。なお本明細書では一般に、参考文献の出願において規定されたのと同じ用語、頭文字、及び略語を用いる。本発明の理解を手助けするために、参考文献の出願の用語リスト及び他の部分を以下に再掲する。

技術：
ＡＡＣ（Application Authentication Cryptogram） アプリケーション認証暗号文
ＡＡＶ（Accountholder Cryptogram） アカウント保有者認証値
ＡＣ（Authentication Cryptogram） 認証暗号文
ＡＣＳ（Access Control Server） アクセス制御サーバー
ＡＦＬ（Application File Locator） アプリケーション・ファイル・ロケータ：ＩＣＣ中のどこでどのような記録が利用可能であるかを識別する。
ＡＩＤ（Application Identifier） アプリケーション識別子：ＩＣＣ中の所定アプリケーションを識別する１６進ストリング。
ＡＩＰ（Application Interchange Profile） アプリケーション交換プロファイル：ＩＣＣが特定機能をサポートする能力を識別する。
ＡＰＤＵ（Application Processing Data Unit） アプリケーション処理データ・ユニット：ＩＣＣと外部アプリケーションとの間で送信されるメッセージ。
ＡＲＱＣ（Authentication Request Cryptogram） 認証要求暗号文
ＡＴＣ（Application Transaction Counter） アプリケーション取引カウンタ
ＢＣＤ（Binary Coded Decimal） ２進化１０進数
Big-Endian ビッグ・エンディアン：最上位バイトを最初に記憶し、後続バイトが順に続き、最下位バイトを最後に値を記憶する符号化スタイル。
ＣＡＰ（Chip Authentication Program） チップ認証プログラム
ＣＤＯＬ（Card Risk Management） カード・リスク（危機）管理
ＣＩＤ（Cryptogram Information Data） 暗号文情報データ
ＣＳＮ（Card Sequence Number） カード・シーケンス（順序）番号
ＣＶＣ２（Card Verification Code） カード検証コード
ＣＶＭ（Cardholder Verification Method） カード保有者検証方法：カードに対するカード保有者を検証するために使用する方法。
ＤＡＣ（Dynamic Authentication Cryptogram） 動的認証暗号文
ＤＯＭ（Document Object Model） 文書オブジェクト・モデル：ブラウザによってプラグイン（機能追加ソフト）に提供される現在のＨＴＭＬページのプログラム的外観。
ＤＳ（Directory Server） ディレクトリ・サーバー
ＨＨＤ（Hand Held Device） ハンドヘルド（手持ち型）装置：例えばカードリーダ
ＥＭＶ（Europay MasterCard Visa） ユーロペイ（登録商標）、マスターカード（登録商標）、VISA（登録商標）
ＩＡ（Interface Application） インタフェース・アプリケーション
ＩＡＤ（Issuer Application Data） 発行者アプリケーション・データ
ＩＡＦ（Internet Authentication Flags） インターネット・アプリケーション・フラグ：ＩＩＰＤ（下記）の第１バイト
ＩＣＣ（Integrated Circuit Card） ＩＣ（集積回路）カード
ＩＩＰＢ（Issuer Internet Proprietary Bitmap） 発行者のインターネット専用ビットマップ
ＩＩＰＤ（Issuer Internet Proprietary Data） 発行者のインターネット専用データ
ＩＴＶ（Interactive Television） 対話型テレビジョン
ＬＡＴＣ（Lower (byte of) Application Transaction Counter） アプリケーション取引カウンタ（ＡＴＣ）の下位バイト
Little-Endian リトル・エンディアン：最下位バイトを最初に記憶し、後続バイトが順に続き、最上位バイトを最後に値を記憶する符号化スタイル。
ＭＡＣ（Message Application Code） メッセージ・アプリケーション・コード：メッセージ中のデータ項目上で計算され、メッセージの出所を証明すると共にこれらのデータ項目が変更されているか否かの検出を可能にする暗号文署名。
ＭＣＤ（Main Cardholder Device） 主カード保有者装置：この装置上でブラウジング（閲覧）及び／または順序付け及び／または決済が実行される。
Nibble ニブル：半バイト、即ち４ビット
ＰＩ（Parameter 1 of APDU） ＡＰＤＵのパラメータ１：ＩＣＣに送信されるコマンドを有効にカスタマイズする。
ＰＡＮ（Primary Account Number） 主アカウント番号
ＰＣ（Personal Computer） パーソナル・コンピュータ
ＰＣＲ（Personal Card-Reader） パーソナル（個人用）カードリーダ
Cardholder IA カード保有者インタフェース・アプリケーション：ＭＣＤ上で実行され、認証要求者と、カード保有者と、ＰＣＲとのインタフェースとなるインタフェース・アプリケーション
ＰＤＡ（Personal Digital Assistance） 個人用携帯情報端末
ＰＤＯＬ（Processing Options Data Object List） 処理選択肢データ・オブジェクト・リスト：端末（例えばＰＣＲ）にとって利用可能であるか、端末によってサポートされる処理選択肢。
ＰＩＮ（Personal Identification Number） 個人識別番号
ＳＰＡ（Secure Payment Application） セキュア（安全）決済アプリケーション
ＴＬＶ（Tag Length Value） タグ長値
ＵＣＡＦ（Universal Cardholder Authentication Field） 汎用カード保有者認証フィールド
ＵＮ （Unpredictable Number） 予測不可能な数

国際特許出願WO03073389に記載の認証方式は、ＵＣＡＦ（Universal Cardholder Authentication Field：汎用カード保有者認証フィールド）の使用である。この認証方式は次の要素を具えている：チップ−ＵＣＡＦをイネーブル（許可）されたインタフェース・アプリケーションを提供された発行者、チップ−ＵＣＡＦアカウント保有者認証値（ＡＡＶ）の生成、カード保有者の認証、販売者のプレゼンテーション（情報提供）、ＵＣＡＦ内のＡＡＶデータの収集及び処理、認証データ・フィールド、ＵＣＡＦに含まれるＡＡＶデータのアクワイアラによる受け入れ及び処理、ＵＣＡＦ認証データ・フィールド内のＡＡＶデータ搬送のサポートを含むためのバンキング（銀行取引）ネットワークの開発、及びＵＣＡＦ認証データ・フィールド内のＡＡＶデータの認証のサポート。

次のエンティティ（実体）が、チップ−ＵＣＡＦ認証取引の寿命中に含まれる：
カード保有者−カード保有者は取引を開始し、販売者の決済ウェブページ、カード保有者のインタフェース・アプリケーション、及びパーソナル・カードリーダのすべてにデータを入力する役割をする。
販売者−販売者は、例えばインターネットと通信可能な販売者サーバーから、認証取引を開始するのに必要なデータを提供し、結果的なＵＣＡＦデータを受信して、承認のためにアクワイアラ経由でカード発行者に転送する。
カード保有者インタフェース・アプリケーション−カード保有者ＩＡは、販売者によって供給される関係データを検出して、カード保有者と直接及び間接的にやり取りし、カード保有者を通してパーソナル・カードリーダとやり取りする。カード保有者ＩＡはＡＡＶ及びＵＣＡＦを作成して、販売者のページに適切なデータを置く。
例えば、カード保有者ＩＡは、インターネット上で販売者にアクセスするために使用中の主カード保有者装置（ＭＣＤ：Main Cardholder Device）上のインターネット・ブラウザの一部として実行することができる。
パーソナル・カードリーダ−ＰＣＲは、カード保有者及びＩＣＣとやり取りして認証トークンを生成し、この認証トークンは間接的に発行者に渡される。ＩＣＣ−チップカードは、提供されたＰＩＮ検証の使用によってカード保有者を認証し、ＰＣＲによって供給されるデータに基づいて適切な暗号文を生成する。
アクワイアラ−アクワイアラはフォーマット（書式）化されたＵＣＡＦデータを販売者から、例えばアクワイアラ・サーバーで受け取り、このＵＣＡＦデータをＵＣＡＦの使用及び存在の識別子と共に、適切な電気通信ネットワーク経由で発行銀行に転送する。
例えば、マスターカード社（登録商標）がアクワイアラである。
発行者−カード発行者は、チップＵＣＡＦ方式に署名契約（サインアップ）したカード保有者にＰＣＲを配付する。発行者は、発行者サーバー・プラットフォームをインターネットと通信可能な状態に維持する。本発明によれば、発行者サーバーはＵＣＡＦに符号化され、アクワイアラによる認証要求において送信された前記認証トークンの有効性を、当該発行者の規則に従って確認する。

国際特許出願WO030733809によれば、ＵＣＡＦ（汎用カード保有者認証フィールド）データ・フィールドは、ディジタル・メッセージ中の、認証データをアクワイアラからあらゆる形態の電気通信ネットワーク上で発行者に伝えることを可能にするための多目的データ搬送領域である。例えば、ＵＣＡＦは、発行者の多種多様なセキュリティ及び認証の必要性をサポートすべく構成可能なフレキシブル（柔軟）なデータ構造を有する32文字フィールド（24バイト−1制御バイト及び23データバイト−がベース６４（Base 64）符号化されて32文字になる）とすることができる。例えば、ISO8583データ要素48では、副要素43をＵＣＡＦを含むように指定することができる。ＵＣＡＦという用語は、販売者とＭＣＤとの間でデータを渡して再び戻すべく規定されたインターフェースも称するように拡張され、即ち、あらゆる所定チャンネル用の仕様中のフィールド名である。ＵＣＡＦは、24倍とのユーザ認証トークンを含むことができる。これらの24バイトは、カード保有者ＩＡによって符号化され、例えばベース６４符号化されて、販売者に返される32アスキー文字のデータを与えることが好ましい。販売者は、アクワイアラとの専用通信においてＵＣＡＦデータを渡し、そしてアクワイアラはこのＵＣＡＦを認証要求メッセージ中に置いて発行者に送信することができる。

アカウント保有者値（ＡＡＶ）とは、ＵＣＡＦアプリケーション特有のデータの一部分、例えば23バイトに与えられる名前である。各ＵＣＡＦアプリケーションは、そのＡＡＶ用の適切な構造を決定する役割をする。所定のＵＣＡＦアプリケーションのすべての実現が、当該ＵＣＡＦアプリケーションのＡＡＶ構造を一貫した方法で使用しなければならず、即ち、ＡＡＶフォーマットは所定のＵＣＡＦアプリケーションに対して規格化されている。

チップ−ＵＣＡＦカード保有者認証方式を使用するために、カード保有者は適切なＩＣＣ決済カード及びパーソナル・カードリーダを持つ必要がある。ＰＣＲはカード発行者によって当該カードの保有者に供給され、カード発行者は、このカード保有者がＰＣＲを持ち、チップ−ＵＣＡＦカード保有者認証方式に「登録」されていることを記録する。販売者によって提供されるＵＣＡＦ取引データは、表示目的に使用され、その一部はＰＣＲチャレンジに関係する取引を生成するために使用される。販売者がＵＣＡＦ応答内のＡＡＶデータ上で実行する必要のある追加的処理は存在しない。このことは、ＵＣＡＦ制御バイト値がチップ−ＵＣＡＦ用の値に設定されているによって販売者に示される。カード保有者インタフェース・アプリケーション（カード保有者ＩＡ）は、認証要求者（販売者）と、カード保有者と、ＰＣＲとの間のやり取りを行う。このインタフェース・アプリケーションは、本発明のＵＣＡＦ方式の安全な面をカード保有者に提供する。このインタフェース・アプリケーションは、取引データをカード保有者に提供し、ＰＣＲに転送されるチャレンジを生成し、ＰＣＲのトークン応答を受信し、ＵＣＡＦをフォーマット化し、そして所定チャンネルについての戻りデータを置く役割をする。カード保有者ＩＡは、チップ−ＵＣＡＦ取引を行うために満たさなければならない最小組の要求を有する。

本発明の文脈では、ＵＣＡＦをイネーブル（許可）されたアクワイアラは、ＵＣＡＦをイネーブルされた販売者と関係を持つ。このアクワイアラは、関係のある販売者に、特別なＵＣＡＦデータをアクワイアラ・システムに渡すことを許可し、これらのアクワイアラ・システムに、供給されたＵＣＡＦデータの存在を識別して発行銀行に渡すことを許可する。発行者のホスト、あるいは前記方式に従って発行者ホストとして動作している他の要素は、認証ネットワーク・メッセージ中で渡された、ＵＣＡＦ内のデータを含むデータを取得して、認証トークンの有効性を確認可能にする役割をする。

本発明によれば３−Ｄセキュア・プロトコルに従うＵＣＡＦは、最大20バイトのユーザ認証トークンを含むことができる。図１０に、こうした３−Ｄセキュア準拠のＵＣＡＦの構造を示す。

図１及び２に、本発明のＣＡＰの実現を図式的に示す。このＣＡＰの実現には、カード保有者自身に加えて種々のシステム構成要素または行為者が関与する。これら種々のシステム構成要素は、物理的なものも論理的なものもあり、認証要求サーバー、カード保有者のＰＣ装置、セキュアコード認証アプリケーション（ＳＣＡＡ：Secure Code Authentication Application）、及び接続または非接続のＰＣＲを含む。これらのシステム構成要素は通常、例えば有線または無線ネットワークを用いてリンクまたは構成される。

認証要求サーバーは論理的エンティティであり、ウェブ・サーバー環境内で、認証要求サービスを、当該エンティティ／構成要素とは無関係に他のエンティティ／構成要素に提供することができる。こうした認証要求サーバーは、異なるｅ−コマース環境及び必要性に容易に適応し進展することができる。一旦、認証要求サーバーがカード保有者を認証すると、このサーバーは肯定または否定の認証結果を、（認証を）要求中のエンティティ／構成要素に返すことができる。

カード保有者のパーソナル（個人用）計算装置は、カード保有者が認証を必要とする行為を装置上で実行するあらゆるコンピュータ・プラットフォームまたはアクセス装置とすることができる。これらのコンピュータ・プラットフォームは、ＰＣＲに接続可能なＰＣプラットフォームとすることができる。あるいはまた、これらのコンピュータ・プラットフォームは、例えばＰＤＡまたは他の移動Ｗｉ−Ｆｉ（Wireless Fidelity：無線ＬＡＮの標準規格の１つ）装置を含む、インターネットにアクセス可能なあらゆる装置とすることができる。カード保有者は、スマート決済カード（例えばＩＣＣ）及びＰＣＲを割り当てられることができる。ＣＡＰの好適な実現では、カード保有者は、セキュアコードが生成され、その有効性確認のために認証要求サーバーに供給される前に、個人識別番号（ＰＩＮ）を自分のＰＣＲに入力しなければならない。

ＰＣＲは、あらゆる適切なＥＭＶ準拠のカード読取装置とすることができ、カード保有者及びＩＣＣとやり取りしてセキュアコードを生成すべく設計されている。従来の暗号化技術（例えばキー技術）を用いてセキュアコードを生成することができる。ＰＣＲは、限定されたカード保有者とのやり取りを可能にするためのディスプレイ及びキーパッドを持つことができる。適切なＰＣＲは、例えば、数字キーパッド及びディスプレイを有する低コストのハンドヘルド・スマートカードリーダとすることができる。ＰＣＲは、カード保有者のパーソナル計算装置との物理的接続を必要としないスタンドアロン（独立型）にすることができる。こうした例では、カード保有者はＰＣＲとＰＣ装置との間ですべてのデータを手動で転送しなければならない。

ＰＣＲは、カード保有者のＰＣ装置に物理的に接続された装置とすることもできる。こうした例では、カード保有者は、認証プロセス開始するために自分のＰＩＮをＰＣＲに入力しさえすればよい、というのは、ＰＣＲによってセキュアコードが自動的に、これに接続された計算装置上のユーザ・インタフェースに渡されるからである。接続されたＰＣＲは、ＰＩＮ入力プロセス中に、通常のＰＩＮのセキュリティ（安全性）または保護を提供することができる。ＰＣＲ上のディスプレイは、ＰＩＮの有効性確認の結果を示し、そして非接続の装置については、カード保有者がＰＣまたはＰＤＡに入力すべき「セキュアコード」を表示する。接続型のリーダは、接続が利用不可能な場合には非接続のリーダとして振舞うことができる。ＣＡＰの実現において使用するＰＣＲは、多種多様なカード実現をサポート可能な汎用的な設計にすることができる。カード保有者は、ＰＣＲにチャレンジを入力すべきか否かを、認証要求サーバーによって（ＰＣ装置の表示インタフェース経由で）入力促進される。ＰＣＲは、こうした表示が行われると、カード保有者にチャレンジの入力を許可し、そしてこのチャレンジをセキュアコードの演算に含めることができるようにすることができる。

セキュアコード認証アプリケーション（ＳＣＡＡ）は、標準的な決済アプリケーションと共に、多用途のクレジットカード、デビットカード、または他のカード（例えばＩＣＣ）上に存在させることができる。ＳＣＡＡは、決済アプリケーションの別個の例とすることができ、この場合には、発行者が、決済及びリモート（遠隔）認証用の別個のセキュリティ環境を用いる選択肢を有する。このアプリケーションは、「１回使用パスコード」の生成及び「取引受諾の証明」の生成を共にサポートすることができる。カード発行者は、ＳＣＡＡを他のサービスに用いることを随意的に選択することができる。ＳＣＡＡはフォーマット化情報またはテンプレートを含むことができ、これらは種々のカード発行者が期待するセキュアコード・フォーマットの種類についてＰＣＲに指示する。こうして、単純なＰＣＲの設計を用いて広範なカードの種類をサポートすることができる。

好適な実現では、カード保有者のパーソナル計算装置、ＩＣＣ、及びＰＣＲのうちの１つ以上を、顧客がインターネットにアクセスして認証された取引を実行するために使用可能な単一の装置（デバイス）または器具に集積することができる。適切な集積装置は、例えば、ＩＣＣ及び非接続のＰＣＲの機能をユーザにとって便利なパッケージ内に集積したディスプレイ付きカードとすることができる。ＩＣＣ及び非接続のＰＣＲをユーザにとって便利なパッケージ内に集積した他の適切な集積装置は、キー・フォブ（key fob：鍵等を付けて腰から提げる小板）とすることができる。ＰＤＡまたは他のパーソナル・インターネット・アクセス装置も、カード保有者に割り当てられたＩＣＣ及びＰＣＲの機能を実行するように構成することができる。図１２は、カード２３０、フォブ２４０、及びＰＤＡ２５０の図式的表現であり、これらのすべてが、ＰＣＲ及びＩＣＣの機能を実行可能な回路を含む。ＰＤＡ２５０はこれに加えて、インターネット・アクセス装置として機能することができる。

図１に好適なＣＡＰ認証プロセス１００を示し、このプロセスは、オンライン・インターネット取引においてカード保有者１８０を認証するために用いることができる。カード保有者１８０は、オンライン取引を行うためのパーソナルＩＣＣ１７０及び非接続のＰＣＲ１６０を提供されている。なお、ＩＣＣ１７０及びＰＣＲ１６０をまとめてディスプレイ付きカード（図１２のカード２３０）とすることができる。プロセス１００は、外部エンティティ１１０によって認証要求サーバー１２０に送信される認証要求１５０に応答して開始される。プロセス１００では、認証要求サーバー１２０が、カード保有者のＰＣ装置１４０上に表示されるカード認証ページ１３０（例えばＨＴＭＬページ）の媒体を通してカード保有者１８０とやり取りする。認証要求サーバー１２０はＨＴＭＬページ１３０を生成してこのページを直接提供することができる。あるいはまた、ＨＴＭＬページ１３０は、電子ネットワーク内に展開する特定のウェブ・サーバー・インフラストラクチャまたは技術次第では、認証要求者（エンティティ１１０）を介して提供することができる。認証の要求（例えば要求１５０）は、ＨＴＴＰ（Hyper Text Transfer Protocol：ハイパーテキスト転送プロトコル）の問合せの結果とすることができ、このＨＴＴＰの問合せは、認証要求サーバー１２０によって生成される応答（例えば結果１５０’）に中のＨＴＭＬを処理することができる。プロセス１００では、認証の要求（１５０）が次の情報またはデータを含むか、さもなければ提供する必要があり得る：
・個人アカウント番号（ＰＡＮ：Personal Account Number）−認証プロセスにおいて使用されるカードのＰＡＮ。
・カード保有者の個人保証メッセージ（ＰＡＭ：Personal Assurance Message）−ＣＡＰプログラム中に登録されたカード保有者は、随意的な個人保証メッセージを提供することを要求されることがありこのメッセージは認証を求められた際に表示される。
・取引明細−認証を要求されている取引の明細は、ウェブサイトからの商品の決済でも銀行口座にアクセスするためでも、カード保有者に対して表示されなければならない。

図１中の整数番号を付けたステップを参照すれば、プロセス１００のステップ１では、認証要求または制御サーバー１２０がカード保有者認証ページ１３０を生成して、このページはカード保有者に対して表示される。カード保有者認証ページ１３０は、カード保有者のＰＣ装置１４０上に表示されるＨＴＭＬページとすることができる。カード保有者認証ページ１３０は、要求中のエンティティ１１０によって提供される取引の明細を表示することができる。１６個の数字（ディジット）のＰＡＮをグループとして表示することができ、３グループのＸ記号（即ち”ＸＸＸＸ”を１グループとした３グループ）に続く最後４つの数字をＰＡＮにおける実際の数字として、カード保有者１８０が認証用の適正なカードを認識または使用することを手助けする。カード保有者がＣＡＰに登録された際に提供されるカード保有者のＰＡＭも表示することができる。次のステップ２では、カード保有者１８０が、リモート決済または識別用のセキュリティ・トークン、即ちセキュアコードの要求を開始することができる。カード保有者１８０は、自分のＩＣＣ１７０をＰＣＲ１６０に読み取らせるよう促される。カード保有者は、異なる種類のセキュアコードを要求する選択肢を与えられる（ステップ２ａ）。これらの異なる種類のセキュアコードは、例えば、リモート決済に対する署名認証、または銀行口座へのアクセスに対する識別認証に対応させることができる。最初の種類のセキュアコード（Bruce, Alfred, Pls. confirm）については、オプションとして、ウェブページ１３０上に表示されたチャレンジをＰＣＲ１６０に入力することをカード保有者に促進することができる。チャレンジが提供されなければ、カード保有者１８０は、ＰＣＲ１６０上の適宜指定されたいずれかのキーストローク（キー押し下げ、例えば「進む」ボタン）を行うことによって先に進むことができる。さらに、ＩＣＣ１７０が、署名または認証しなければならない取引金額を示すインターネット認証フラグ（ＩＡＦ）を有する取引については、この取引金額をウェブページ１３０上でカード保有者１８０に対して表示することができる。作り付けのリストから取引通貨を選択して前記ウェブページ上に表示された金額を入力するようカード保有者１８０に促すことができる。この入力後に、カード保有者１８０は、ＰＣＲ１６０上の適宜指定されたキーストロークを行うことによって次のステップ３に進むことができる。

ステップ３では、カード保有者１８０がカード保有者のＰＩＮを入力するよう促される。ＰＩＮが正しく入力されなければ、カード保有者はＰＩＮを再入力するよう促される。カード保有者１８０に、ＰＩＮを正しく入力する試みを限定回数だけ許可することができる。この限定回数は、ＩＣＣ１７０内の内部再試行（リトライ）カウンタに設定された事前選択数とすることができる。カード保有者が正しいＰＩＮを許可された試行回数以内で入力できなければ、取引は拒絶される。その際にはオプションとして、異なる、あるいは代わりの決済手段を提示するようカード保有者１８０に要求することができる。

正しいＰＩＮが入力された後に、ステップ４では、ＰＣＲ１６０が、最適化されたＥＭＶ取引の対話をカード１７０との間で行って、アプリケーション暗号文を生成する。この暗号文は、ＥＭＶの標準用語における認証要求暗号文（ＡＲＱＣ）とすることができる。一部の例では、ＩＣＣ１７０が、ＡＲＱＣの代わりにアプリケーション認証暗号文（ＡＡＣ）を生成する内部リスク管理ルーチンを有することができる。いずれの種類の暗号文もＰＣＲ１６０に受け入れられる。ステップ５ａでは、ＰＣＲ１６０がＡＱＲＣまたはＡＡＣを、カード保有者１８０に対して表示するための数字セキュアコードに変換する。この数字セキュアコードは、例えば８ディジット長とすることができる。ステップ５ｂでは、ＰＣＲ１６０によって生成されたセキュアコードが読み込まれ、そしてカード保有者１８０はこのセキュアコードを、カード保有者のＰＣ装置１４０上のＨＴＭＬページ１３０中の適切な入力フィールドに手入力することができる。ステップ６では、前記セキュアコード入力を伴うＨＴＭＬページ１３０が、カード保有者によって、承認または有効性の確認を求めて認証要求サーバー１２０に提出される。次のステップ７では、認証要求サーバー１２０がカード保有者データベース１９０にアクセスして、カード特有の静的または動的なデータを検索または更新することができる。前記カード特有の動的なデータは、認証サーバー１２０が追跡することができ、認証取引カウンタ（ＡＴＣ）を含むことができる。最後の既知のＡＴＣのコピーをカード保有者データベース１９０内に保持して、これにより、完全なＡＴＣを部分的なＡＴＣ（下位ビット）と組み合わせて適正に再構成して、セキュアコード中に戻すことができる。

ステップ８では、認証要求サーバー１２０が、ＩＣＣによる暗号文の生成に使用した入力データを再構成することによって、前記セキュアコードの有効性を確認することができる。この再構成された入力データは、既知の静的なデータ、ＰＣＲ１６０によってＩＣＣ１７０に提供された（ステップ４）あらゆる取引特有のデータ（チャレンジ、金額／通貨）を含むことができる。ステップ３においてチャレンジを用いていない例では、ＰＣＲ１６０は、予測不可能な数についてはデフォルトのヌル（０／無）値を用いるように構成することができる。同様に、ステップ３において金額及び通貨の値が使用されていない場合には、ＰＣＲ１６０は両方の変数について０のデフォルト値を用いるように構成することができる。前記再構成した入力データから、アプリケーション暗号文（ＡＱＲＣまたはＡＡＣ）を再計算して、ステップ６においてアプリケーション要求サーバー１２０が受信したセキュアコード中の部分的なアプリケーション暗号文（ＡＣ）と比較することができる。前記再計算したＡＣと前記受信したＡＣとが一致した場合には、カード・データベース１９０内のＡＴＣ値を更新することができる。

プロセス１００中の最終ステップ１９５では、アプリケーション要求サーバー１２０は認証テストの結果を、要求中のエンティティ１１０に提供する。

図２に、接続されたＰＣＲ１６０’をカード保有者１８０に提供する例において使用可能な他の好適な認証プロセス２００を示す。プロセス２００は、あらゆるチャレンジ及び金額／通貨データがＨＴＭＬページ１３０内に埋め込まれたソフトウェア構成要素によって直接または自動的にＰＣＲ１６０’に伝達されること以外は、概ねプロセス１００と同様である。同様に、カード保有者１８０が自分のＰＩＮを正しく入力した（ステップ３）後に、セキュアコードを適正なデータ・フィールド中に自動的に入力して検証することができる。プロセス１００と同様にプロセス２００は、署名または識別動作の選択を、ＰＣＲ１６０’を介してカード保有者１８０に提供することができる。カード保有者１８０が取引金額に署名を要求される例では、プロセス２００は、ＰＩＮ入力を可能にする前に、この金額をＰＣＲ１６０’上に表示することができる。認証要求サーバー１２０は、ＰＣＲ１６０（図１）が生成したセキュアコードの処理と同一の方法で、プロセス２００が生成したセキュアコードを処理する。

プロセス１００及び２００の双方において、ＥＭＶセキュリティの特徴がＣＡＰのセキュリティの基礎になる。より詳細には、ＣＡＰは、カード及びカード保有者の存在の証明を確立して１回使用のセキュアコードを生成するために、ＩＣＣによる暗号文、即ちアプリケーション暗号文（ＡＣ）の生成に頼る。カード保有者による取引承認の証明は、チャレンジの使用に基づく。取引特有の暗号文の使用は、真正な取引の反復提出（二重、三重に出されること）、及び不正な取引の発生に対する保護を提供する。

ＩＣＣ（例えばＩＣＣ１７０）は、標準的なＥＭＶコマンド（例えばGENERATE AC（認証暗号文の生成）コマンド）に応答して、特定取引用の暗号文を生成すべく構成されている。ＩＣＣ１７０によって生成される、GENERATE ACコマンドに対する応答は、次のデータ要素、即ち：暗号文情報データ（ＣＩＤ）、アプリケーション取引カウンタ（ＡＴＣ）、ＩＣＣによって演算された暗号文（ＡＣ）、及び発行者アプリケーション・データ（ＩＡＤ）を含むことができる。これらのデータ要素は、他のソースから取得可能な、特定取引に対する一意的なデータ及び非一意的なデータを含む。取引に対する一意的なデータは、（暗号文形式で）ＰＣＲからインタフェース・アプリケーションに（例えばＨＴＭＬページ１３０を介したセキュアコードとして）転送されて、さらに処理される。他のソースから取得可能なデータは、前記セキュアコードに含める必要はない。こうした非一意的なデータは、発行者の所定のカード方式に対する特定値を有するように想定され、この値は特定のＩＣＣに対しては一意的であり、発行者のホストは、自分のカード保有者データベースによって知ることができる（少なくとも推論可能である）。

ＩＣＣ１７０は、データ・オブジェクトまたはマスク（例えば’0x9F56’のタグを伴う発行者のインターネット専用ビットマップ（ＩＩＰＢ））を具え、このデータ・オブジェクトまたはマスクは、ＰＣＲが、認証データまたは暗号文を生成するためにＩＣＣの応答のどの部分（即ちビット）を使用しなければならないかを決定するために用いる。使用されるビット数は、発行者が規定または選択することができる。このビット数は、例えば、カード保有者が手作業で非接続のＰＣＲ１６０からＰＣ装置１４０に好都合に転送可能な限定数のデータビットを人間工学的に考察することによって選択することができる。前記ＩＩＰＢは、ＰＣＲ１６０または１６０’が、”ＩＩＰＢデータトークン”を導出するためのビットマスクとして使用することができ、このデータトークンは、圧縮されると、認証要求者に渡されるセキュアコード・トークンを形成する。

図９に、好適なＩＩＰＢ構造９００を示す。ＩＩＰＢを構成するビットは、GENERATE Ac応答からのどのビットを、発行者が前記セキュアコード中に含めることを要求しているかを示す伝送フラグとして考えることができる。これらのフラグは、ＰＣＲから送信しなければならないビット（例えば１バイトのＣＩＤ、２バイトのＡＴＣ、８バイトのＡＣ、及び0〜32バイトのＩＡＤ）に、ビット毎のベースで対応させることができる。ＩＩＰＢ９００は、ＩＡＤが規定されていない場合とは異なり、約11バイトの長さにすることができる。発行者のアプリケーション技術が、発行者アプリケーション・データ（ＩＡＤ）にとって利用可能な完全な32バイトを使用する場合には、ＩＩＰＢ９００は43バイトまでの長さにすることができる。従って、データ要素ＣＩＤ、ＡＴＣ、ＡＣ及びＩＡＤの連鎖に対するマスクとして使用されるＩＩＰＢ９００は、11〜43バイトの長さを有する構造を生じさせることができる。ＰＣＲ１６０及び１６０’は共に、ＩＩＰＢ９００の長さがＩＣＣ１７０のＡＣ生成応答中で戻されるデータ項目の長さと一致したことを判定すべく適切に構成することができる。

有効ＩＩＰＢ長とは、ＩＩＰＢによって規定され、ＩＩＰＢデータトークン内で転送されるビット数（ビット転送が要求されていることを示すために１に設定されているＩＩＰＢ内のビット数によって支配される）を称する。好適なＣＡＰの実現では、前記セキュアコードは、８ディジットの１０進数で転送可能な最大ビット数である26ビット（即ち、67,108,863）を超えない。従って有効ＩＩＰＢ長は26ビットを超えることがあり得ない、というのは、さもなければトークン用に９ビット以上を必要とするからである。

ＩＣＣ１７０は、オフラインでのＰＩＮの有効性確認を用いてカード保有者の存在の証明を確立する。ＥＭＶ規格の仕様は、オフラインでのＰＩＮの有効性確認を、ＡＣの生成前に実行することを要求する。結果的に、有効なＡＣを生成するためにはカード保有者の存在が要求され、そして有効な暗号文の存在が、カード保有者の存在を証明するのに十分である。ＡＣは通常はＡＲＱＣに基づくが、カードの内部リスク管理ルーチンが決済取引を辞退することを決定したならば、ＡＡＣに基づかせることもできる。

カード保有者による取引の受諾または承認の証明は、暗号文及びセキュアコードを生成するために認証要求サーバーによって供給されるデータの使用に基づく。認証要求サーバーによって供給されるデータは、カード保有者に対して表示される取引特有のチャレンジとして使用する。このチャレンジは、認証要求サーバーのみが知っている情報から展開された数値である。この数値は、関連または該当するものと発行者が考えることができるあらゆる適切なデータ（例えば取引金額及び通貨コード）に基づくものとすることができる。異なるチャレンジが異なるセキュアコードを生成し、どのチャレンジを用いて特定のセキュアコードを生成することができるかを知る方法として考えられるものはない。従って、取引特有のチャレンジの使用は、カード保有者がこの特定取引を確かに承認したことの証明を発行者及び認証要求サーバーに提供する、というのは、表示されるチャレンジはＰＣＲによって生成された暗号文に含まれ、この暗号文は前記セキュアコードに含まれるからである。

不正な再試行、あるいは真正な取引の再提出（重複提出）に対する保護を保証するために、ＣＡＰの実現は、ＩＣＣから受信したアプリケーション取引カウンタ（ＡＴＣ）を、このＩＣＣについて最後に受信したＡＴＣに対してチェックするように構成することができる。前に受信したＡＴＣを用いる取引は再試行として辞退することができる。さらに、ＩＣＣが生成するＡＣは、ＡＴＣの関数として変化するように計算することができる。このことは、ＡＴＣをＡＣの計算に使用する入力データの一部分として含めることによって達成される。

ＩＣＣが生成するＡＣは、切り取った部分のみを発行者に転送する。各暗号文は、発行者のインターネット専用ビットマップ（ＩＩＰＢ）によって指定された通りに切り取る。発行者は、例えば、ＡＣからの16ビットがＰＣＲによって戻されるセキュアコードに含まれるようにＩＩＰＢを規定することができる。切り取られた暗号文はサイズが縮小されているので、発行者は、暗号文の有効性確認の失敗数の異常を検出するように不正検出システムを実現することができる。

図３及び４に、非接続のＰＣＲについてはチャレンジ数の生成、接続されたＰＣＲについてはＰＩＮの検証に関係する好適なＰＣＲプロセス及びデータフロー（データの流れ）を示す。接続されたＰＣＲの使用と非接続のＰＣＲの使用との主な違いは、ユーザの利便性である。接続されたＰＣＲの場合には、ＰＣ装置とＰＣＲとの間のリンクが、これら２つの間でデータを搬送する。非接続のＰＣＲの場合には、カード保有者がデータを手作業でコピーして上記２つの間で転送しなければならない。なお、図３及び４は、ＩＣＣに送信される正確なコマンド、及びＰＣＲにおける正確な処理ステップを詳細には示していない。明瞭にするために、システム、そのデータ構造、及び概括的な処理の原理を例示する手助けとなる要素のみを図式的に示す。

図３に示す整数番号を付けたステップを参照すれば、ＰＩＮ検証のための処理ステップ、及びカード保有者に対して表示される、これに対応するプロンプト（入力促進記号）は次のようになる：
１． カード保有者は自分のカードを挿入することを要求される。カード保有者は、発行者による認証を可能にする自分のカード（ＩＣＣ）をパーソナル・カードリーダに挿入する。
Insert Card （カード挿入）
非接続のリーダでは、カードを挿入する行為がＰＣＲの電源をオンにするか、あるいは、カード保有者がボタンを押して電源をオンにすることができる。
２． カード保有者は、必要なＰＣＲの機能を選択するよう要求される。
[S]ignまたは [I]d （署名またはＩＤ）
３． カード保有者はＰＣＲの機能の選択を、特定機能のキーまたはメニューシステムによって行う。
４． ＰＣＲは、要求された機能に適した選択リストを用いて、適切なセキュアコードの生成に使用するアプリケーションを探索し選択する。
５． ＰＣＲは、ＩＩＰＢ及びＩＡＦを含む選択されたデータ要素をＩＣＣから読み取る。
カード保有者が「署名」の動作を選択した場合には、
６． ＰＣＲは、カード保有者にチャレンジを入力するよう促す。
チャレンジの生成は発行者にとって独占的であり、チャレンジは、ＥＭＶ取引処理における予測不可能な数（ＵＮ）用に用いられる。
Challenge> （チャレンジ）
７． カード保有者は、ＰＣＲのキーパッド上でこのチャレンジを入力し、[Proceed]（「進む」）キーを押してチャレンジ入力の完了を示さなければならない。
5
58
581
5811
58113
581139
5811396
58113967 [Proceed]
認証要求サーバーがチャレンジを要求しない場合には、カード保有者はチャレンジの数字を何ら入力せずに、単に[Proceed]ボタンを押せばよい。ＰＣＲは、後のGENERATE AC（ＡＣ生成）コマンドに応答するＵＮ用にヌル（０）値を用いる。
８． 金額及び通貨を暗号文に含めるべきことをＩＣＣが示す場合には、ＰＣＲは、カード保有者に選択させるための標準的な通貨のリストを表示する。
１． EUR （ユーロ）
２． USD （米ドル）
３． GBP （英ポンド）
４． その他
> 1 [Proceed] （「１」を選択して「進む」）
９． そしてカード保有者は、金額を入力するよう促される。

> ????????.?? EUR
カード保有者は金額を入力して[Proceed]を押す。
金額及び通貨を暗号文に含めることを要求する発行者は、ＩＡＦの設定においてこの要求を示すことができる。金額及び通貨は、カード保有者認証ページ上でカード保有者に対して表示される。
１０． ＰＣＲは、カード保有者に自分のＰＩＮを入力することを求めるプロンプトを表示する：
enter PIN （ＰＩＮを入力）
１１． カード保有者は自分のＰＩＮの数字を入力し、[Proceed]キーを押してＰＩＮ入力の完了を示し、このことを下記の４ディジット（数字）のＰＩＮの例で示す：
*
**
***
**** [Proceed]
１２． ＰＣＲはＰＩＮをＩＣＣに提供して検証させる。
エラーチェック： ＩＣＣが無効なＰＩＮ入力を報告した場合には、ＰＣＲはＰＩＮ入力の試行の残り回数をカード保有者に通知する：
Bad PIN, 2 left （無効なＰＩＮ、（再試行が）残り２回）
そしてカード保有者は正しいＰＩＮを入力して[Proceed]キーを押し、ＰＣＲは有効なＰＩＮ入力を報告する。
***** [Proceed]
PIN OK! （ＰＩＮが適正）

接続されたリーダを用いたＰＩＮ検証プロセス３１０（図４）は、非接続のリーダを用いたＰＩＮ検証プロセス３００（図３）と概ね同様である。しかし、プロセス３１０では、プロセス３００におけるカードの挿入またはリーダの電源オンではなく、適切なＡＰＤＵコマンドの受信により、取引プロセスのフロー（流れ）を開始することができる。プロセス３１０は、チャレンジデータを受信する方法でもプロセス３００と異なり得る。カード保有者はチャレンジデータを入力することを要求されない、というのは、必要なチャレンジデータはいずれも、取引を開始したＡＰＤＵで提供可能だからである。

プロセス３００及び３１０の双方において、ＰＣＲは同一の方法でセキュアコードを計算することができる。プロセス３１０では、ＡＰＤＵ応答において、前記計算したセキュアコードを戻すことを要求されることがある。この要求は、認証要求サーバーがこの応答を処理する際に、接続されたＰＣＲ及び非接続のＰＣＲを同じ方法で取り扱うことができることを保証する。

ＣＡＰは、ＩＣＣ及びカード保有者を認証するためのメカニズムとしてアプリケーション暗号文（ＡＣ）を使用する。ＥＭＶのコマンド”GENERATE AC”（ＡＣを生成）は、アプリケーション要求暗号文（ＡＲＱＣ）を生成することをＩＣＣに要求するために用いる。このコマンド中で提供しなければならないデータは、ＣＤＯＬ１として好都合に識別されているＥＭＶデータ要素によって指定される。予測不可能な数（ＵＮ）は、GENERATE ACコマンド中でＩＣＣに渡されるデータの４バイト（32ビット）の構成要素である。アプリケーションとは対照的に、ＩＣＣにとって予測不可能であるものは数（またはデータ）である。ＰＣＲに渡されるチャレンジは、暗号文生成にとって予測不可能な数（ＵＮ）として用いられる。８ディジットの最大数を、ＩＣＣに送信する際のＢＣＤ（Binary Coded Decimal：２進化１０進数）形式のチャレンジ用に用いることができる。あらゆる８ディジット未満のチャレンジは、ＵＮを作成する際に、８ディジットまでの通常の（例えば０を付けることによる）パディング（桁合わせ、桁揃え、データ長合わせ）の使用を含むことができる。図５に、好適な８ディジットのチャレンジを示す。

ＣＡＰの実現では、ＰＣＲは、ＩＣＣからのGENERATE ACコマンドに対する応答を処理して、インタフェース・アプリケーションに返さなければならないセキュアコードまたはトークンに至らせる。GENERATE ACコマンドに対するＰＣＲの完全な応答は、発行者に送信するには過大になり得る。従って、ＰＣＲはＩＩＰＢを用いて、データ抽出及び圧縮プロセスを実行してＩＩＰＢデータトークンを生成し、このデータトークンは、（暗号化後に）ＰＣＲからインタフェース・アプリケーションに転送されるデータである。接続されたＰＣＲは、このデータを直接、インタフェース・アプリケーションに転送することができるのに対し、非接続のリーダについては、カード保有者がこのデータを手動で転送しなければならない。

ＩＩＰＢにおける’1’のビット設定（例えば図９参照）は、これに対応するビット位置が応答データ中に要求され、これを送信する必要があることを示す。

‘0’のビット設定は、ビット設定がどうあるべきかを発行者が知っているか、さもなければ導出することができ、従って、このビットはセキュアコードの一部として送信する必要がないことを示す。

ＩＩＰＢデータトークンは右から左へと構成され、最初に抽出されるビットが出力データの最終バイトのビット１に配置され、２番目に抽出されるビットがビット２に配置され、等である。好適なＩＩＰＢデータトークン３７００を図７に示し、このデータトークンは、転送すべきビットがなくなるまで上記方法で満たされる。

ＰＣＲからインタフェース・アプリケーションに転送されるデータ（即ち、好適なＩＩＰＢデータトークン）は、まずセキュアコードとして暗号化される。ＣＡＰ実現では、ＰＣＲは、転送すべきデータのビットパターンを表現する数を算出する適切なアルゴリズムで構成される。従って非接続のリーダはこの数−セキュアコード−を表示して、これによりカード保有は、カード保有者認証ページによって表示される適切なフィールドにこの数を入力することができる。

要求されたビットを表示される数字に変換するために使用するＰＣＲ暗号化アルゴリズムは、認証要求サーバー上で相互運用性があり、かつ可逆的であることが好ましい。ビットからトークンに変換するために使用するのと同じアルゴリズムは、トークンからビットに変換すべく可逆的にすることができる。適切な「圧縮」技法は、ビットパターンを２進数として扱い、図６に示すようにベース（底）２からベース１０への数学的変換を実行することを含む。

ＣＡＰの実現は、一貫性があるように、あるいは、販売者、アクワイアラ、発行者、及びカード保有者を含む取引連鎖中のすべての関係者の３−Ｄセキュア・プラットフォーム、システム、及び方法と互換性があるように設計する。ＣＡＰは、発行者が規定したチップ認証データの使用を標準化することが有利である。ＣＡＰ実現は、広範なカード保有者認証方式及び取引チャンネルをサポートするための、新規及び既存の両方の３−Ｄセキュア・プラットフォーム、システム、及び方法用の標準的なメッセージ・インフラストラクチャを有利に利用することができる。

以下の論理的または物理的な３−Ｄセキュアのエンティティは、ＣＡＰのチップ認証された取引（図８）の寿命全体にわたって関与することができる。
・ カード保有者−カード保有者は取引を開始し、販売者の決済ウェブページ、パーソナル・カードリーダ、及びカード保有者認証ページにデータを入力する責任を負う。カード保有者は、ＰＣＲがセキュアコード認証アプリケーション（ＳＣＡＡ）を用いてセキュアコードを生成するために、自分のＰＩＮをＰＣＲに入力しなければならない。
・ 販売者−販売者は、認証取引を開始するために必要なデータを供給し、結果的な認証データを受信して、検証のためにアクワイアラ経由で発行者に転送する。販売者は通常の３−Ｄセキュア・プロセスを動作させる。
・ カード保有者認証ページ−カード保有者認証ページは、ＡＣＳ（アクセス制御サーバー）が提供するウェブページである。このページは、ＡＣＳが提供する関連データ及び指示を提供して、カード保有者とやり取りする。カード保有者認証ページはＡＣＳによってカード保有者に戻され、インターネット・ブラウザの一部（即ち、「ポップアップ」ウィンドウ）として実行される。このページは、３−Ｄセキュアのマスターカード社の実現用の標準的な表示情報に加えて、発行者が要求すればチャレンジも含むことができる。
・ パーソナル・カードリーダ−パーソナル・カードリーダはカード保有者及びＩＣＣとやり取りしてセキュアコードを生成し、このセキュアコードはＡＣＳを通して間接的に発行者に渡される。リーダの種類及び取引の種類次第では、カード保有者は、要求されたＰＩＮを入力する前に、発行者が生成した認証ポップアップ・ウィンドウ上に表示されるチャレンジ、及び場合によっては金額／通貨を入力することが必要になり得る。カード保有者は、（非接続のＰＣＲ上に表示される）セキュアコードを、ウェブページのカード保有者認証ページ上に入力しなければならない。（ＰＩＮ入力以外のデータ入力、及び場合によっては金額／通貨の確認は、接続されたリーダでは不要である。）
・ ＩＣＣ−ＥＭＶ準拠のスマートカードは、ＰＩＮ検証によってカード保有者を認証して、パーソナル・カードリーダによって提供されるデータに基づいて適切な暗号文を生成する。
・ アクワイアラ−アクワイアラは販売者から取引データを受信して、このデータを適切なネットワーク経由で発行者に転送する。アクワイアラは、標準的な、あるいは互いに合意したプロセスに従って、発行者から認可を得る。
・発行者−発行者は、例えば３−Ｄセキュア用のマスターカード・チップ認証プログラムについて署名契約したカード保有者にパーソナル・カードリーダを配付する。発行者が随意的に、アクワイアラから送信される認証要求内のＤＣＡＦフィールド中の認証データ（ＡＡＶ）の有効性を確認することができることが重要である。
・ アクセス制御サーバー−発行者は、３−Ｄセキュア仕様のアクセス制御サーバーを運用し、このアクセス制御サーバーは、カード保有者認証ページを提供し、セキュアコードをＰＣＲから（即ち、カード保有者から直接的または間接的に）受信する追加的な能力を有する。ＡＣＳは、下記の認証要求サービスを用いることによって、このセキュアコードの有効性を検証する：
（認証要求サービスの動作）
○ 前記チップしか知らないデータ（ＡＴＣ及び暗号文の種類の指標）を前記セキュアコードから抽出する。
○ 暗号文を再生成する。
○ 結果を、前記セキュアコード中の部分的な暗号文と比較する。
・ 登録サーバー−登録サーバー及び登録プロセスは、通常の３−Ｄセキュア・プロセスと同じである。ＰＡＮがスマートカードに属し、チップを用いて静的なパスワードの代わりにセキュアコードが作成されることをカード保有者が示したい要求が存在し得る。このことは、カード保有者の決定、発行者の決定、あるいは恐らくは構成上の選択肢とすることができる。発行者は、セキュアコードのフォーマット、及びカード保有者がＰＣＲに入力すべきチャレンジが表示されるか否かを示さなければならない。これらの決定の大半が、発行者が選択可能な構成上の選択肢であることが理想的である。
・ ディレクトリ・サーバー−ディレクトリ・サーバーは通常の３−Ｄセキュアモードにおいて運用される。

図８に、３−Ｄセキュア（登録商標）環境における好適なＣＡＰ（チップ認証）取引に関与するエンティティ間のステップ及びメッセージ・フロー（メッセージの流れ）の一部５００を示し、上記環境は例えば３−Ｄセキュア・バージョン1.0.2環境とすることができる。ＣＡＰは、カード／カード保有者と発行者のアクセス制御サーバー（ＡＣＳ）５１０との間の認証メカニズムを提供する。図に示す好適なメッセージ・フローは、取引を行う前に、カード保有者５８０が発行者と共にサービスに登録され、スマートカード及びこれに適合するＰＣＲを持っていることを仮定する。さらに、購入をしようとするカード保有者５８０は必要な商品またはサービスを選択済みであり、販売者のウェブサイト上で「チェックアウト」プロセスを開始しているものとする。販売者は既にカード保有者５８０に自分の決済カードの詳細情報を提供することを要求しており、この詳細情報はカード保有者５８０によって販売者のウェブサイト上で、保護された方法で入力されているものとする。ＣＡＰベースの認証は、図のステップ８−セキュアコードの生成及び入力のみに影響する。

標準的な３−Ｄセキュア・バージョン1.0.2のメッセージ・フォーマット及びデータ・フォーマットは、メッセージ・フロー５００のすべてに用いることができる。特に、ＡＣＳ５１０が作成して販売者に戻し、最終的にＵＣＡＦに含まれる、搬送されるＣＡＶＶは、28文字（キャラクタ）長であり、ベース６４符号化において３−Ｄセキュア用に規定された20バイトのフィールドを含む（例えば図１０参照）。ＣＡＰ認証アプリケーション（ＳＣＡＡ）の使用は「認証モード」フィールド中に示すことができる（値’2’）。ＡＡＶ用と同じフォーマットを、動的なセキュアコードＣＡＰ動作において、及び従来の３−Ｄセキュアの静的パスワードの動作モード用に用いることができる。

図８を参照すれば、整数番号を付けたステップ及びメッセージ・フロー５００は次の通りである：
１． 支払明細：カード保有者から販売者へ（HTPPS/POST化したフォーム（書式））
ブラウザで品目を選択したカード保有者は「チェックアウト」し、これにより、決済カードの詳細−この場合に得に関係するものとして−即ち刻印（エンボス）されたカード番号（ＰＡＮ）を含む個人の詳細情報を販売者に提供する。
２． ＶＥＲｅｑ（Verify Enrollment Request：検証登録要求）：販売者からディレクトリ・サーバー（ＤＳ）へ（HTTPS/POST）
販売者の３−Ｄセキュア処理ソフトウェアが、ＶＥＲｅｑを適切な銘柄ディレクトリ・サーバーに送信して、前記ＰＡＮが発行者の３−Ｄセキュア・プログラム中に登録されているか否かを判定する。
販売者がディレクトリ・サーバーのローカルキャッシュを日毎のベースで保守して、決済毎にディレクトリ・サーバーを参照することを回避するよう、販売者に仕向けることができる。このキャッシュは、前記プログラムに参加し、利用され得るすべての銘柄のカード範囲を含むことができる。キャッシュのオプションの使用は、カード保有者のＰＡＮが前記プログラムに参加する資格のない際に、前記ディレクトリにこれらの要求を行うことを防止する。
３． ＶＥＲｅｑ：ディレクトリ・サーバーからアクセス制御サーバー（ＡＣＳ）へ（HTTPS/POST）
カード範囲に基づき、ディレクトリ・サーバーはＶＥＲｅｑを適切なＡＣＳ上に渡す。ＡＣＳは、当該カード（カード保有者のＰＡＮ）が３−Ｄセキュアに登録されているか否かを判定する。
４． ＶＥＲｅｓ（Verify Enrollment Response：検証登録応答）：ＡＣＳからＤＳへ（HTTPS/POSTへの応答）
ＡＣＳは、特定のＰＡＮがシステムに登録されているか否かの指標を返し、登録されていれば、認証を実行するためのカード保有者のブラウザをＡＣＳに転向させる（閲覧するサイトをＡＣＳに切り換えさせる）ために使用するＵＲＬ（Uniform Resource Locator：ウェブサイトを指定する記述子）を返す。
ＡＣＳは一意的なアカウント識別子を返し、この識別子は、カード保有者がＰＡＲｅｑと接触した際に、ＡＣＳが当該決済カードを識別するために使用するＰＡＮであってはならない。このアカウント識別子は、キーを正しく生成してセキュアコードを検証することができるためには、１対１ベースで使用される実際のカードのＰＡＮと一致しなければならない。
５． ＶＥＲｅｓ：ＤＳから販売者へ（HTTPS/POSTに対する応答）
ＤＳはこの応答を販売者に返す。
６． ＰＡＲｅｑ（Payer Authentication Request：支払（決済）者認証要求）：販売者からカード保有者へ（HTMLページ）
販売者の３−Ｄセキュア処理ソフトウェアがＰＡＲｅｑを構成して、これをベース６４符号化してＨＴＭＬフォームのフィールド中に置く（ＰＡＲｅｑ）。カード保有者のブラウザが認証後に転向（閲覧サイト切り換え）しなければならない販売者のＵＲＬは、ＨＴＭＬフォームのフィールド中に置かれ（ＴｅｒｍＵｒｌ）、ＴｅｒｍＵｒｌを介して接触した際にカード保有者が必要とし得る販売者のデータもＨＴＭＬフォームのフィールド中に置かれる（ＭＤ）。そして、カード保有者の支払明細の提示に対する応答として、ＨＴＭＬページがカード保有者に戻される。このフォーム用のＰＯＳＴ（ポスト）アドレスは、ＶＥＲｅｓによればＡＣＳのＵＲＬである。
７． ＰＡＲｅｑ：カード保有者からＡＣＳへ（HIT/POST）
販売者が返すページは一般に、追加的な小さい「ポップアップ」ウィンドウを開くことができ、そしてこのウィンドウは、販売者が記入したフォーム（書式、申込書）データをＡＣＳに提示する。
ＡＣＳはカード保有者の詳細を調べて、この特定の決済カードに対して使用する認証メカニズムを決定し、そしてチップ認証の場合には、認証に必要なチャレンジを決定する。
８． カード保有者認証：ＡＣＳからカード保有者へ、そしてカード保有者からＡＣＳへ（MTMLページにHTPPS/POSTが続く）
ステップ８は、特定の発行者及び／またはカード保有者に適した方法で実行することができる。ＣＡＰの実現では、認証プロセスは、図１及び２を参照して説明し、付録Ａに説明する認証要求サーバーを用いて実行することができる。ＡＣＳ５１０は、２種類以上のカード保有者認証をサポートすることができるが、１つのカード当たり１つの方法のみが可能である。ＡＣＳ５１０は、カード／カード保有者について記憶している情報から、このカードについて可能な方法を決定することができる。ＡＣＳは、カード保有者とのインタフェースを制御して、ＰＣＲの使用をカード保有者に指示する。ＡＣＳ内の構成パラメータに基づいて、発行者は、「１回使用パスコード」セキュアコードを実現するか、あるいは「取引受諾」セキュアコードを実現することができる。後者の違いは、カード保有者は特定取引を受諾するために、非接続のＰＣＲ上で自分のＰＩＮを入力する前にチャレンジを入力しなければならないことにある。１回使用パスコードではこのステップは不要である。
９． ＣＡＶＹの生成：ＡＣＳが行う
採用した認証メカニズムによって有効性が確認されると、ＡＣＳは、実現した３Ｄセキュア・アーキテクチャをセキュア（安全）決済アプリケーションに準拠した（ＳＰＡ）ＡＡＶを構成する。この値は、ＰＡＲｅｓのＣＡＶＶサブフィールド中に置かれて販売者に返される。
１０． ＰＡＲｅｓ（Payer Authentication Response：支払者認証応答）：ＡＣＳからカード保有者へ（HTMLページ）
ＡＣＳは、ＡＡＶ及びメッセージ署名を含むＰＡＲｅｓを構成して、これをベース６４符号化してＨＴＭＬフォームのフィールド中に置く（ＰＡＲｅｓ）。ＰＡＲｅｑにおいて受信した販売者のデータも、ＨＴＭＬ書式フィールド中で販売者に戻される（ＭＤ）。このページ中のフォーム用のＰＯＳＴ（ポスト）アドレスは、ＰＡＲｅｑのＴｅｒｍＵｒｌフィールドによれば販売者のＵＲＬである。
１１． ＰＡＲｅｓ：カード保有者から販売者へ（HTTPS/POST）
そして、ＡＣＳによって返されるページは、ＡＣＳが記入したフォームデータを販売者に提示し、販売者の３−Ｄセキュア処理ソフトウェアはＡＣＳによって生成されたメッセージ署名を検証することができる。
１２． 認証要求：販売者からアクワイアラへ（専用通信）
販売者は、ＰＡＲｅｓにおいて受信したＡＡＶを、標準的な認証要求データと共に、自分のアクワイアラに送信する認証要求に含める。
１３． ＭＴ０１００／２００：アクワイアラから発行者へ（BankNet：銀行ネットワーク）
アクワイアラは認証データを抽出し、認証メッセージ内のＵＣＡＦフィールド中に入れて、例えば適切なマスターカード認証ネットワークに送信する。
１４． ＳＰＡ ＡＡＶの検証：発行者が行う
発行者は、前記認証メッセージのＵＣＡＦフィールドに含まれるＡＡＶ値を検証して、与えられたカードによってカード保有者の認証が行われたことを保証する。
１５． ＭＴ０１１０／０２１０：発行者からアクワイアラへ（BankNet）
標準的な認証処理が実行され、アクワイアラに応答が返される。
１６． 認証応答：アクワイアラから販売者へ（専用通信）
販売者は、自分のアクワイアラから認証応答を受信する。
１７． 応答／受信：販売者からカード保有者へ（HTML）
販売者は、カード保有者の支払が受領されたか否かについての指標をカード保有者に返す。

図１１に、３−Ｄセキュア環境におけるＣＡＰ実現による顧客のオンライン購入に関係し得る好適な処理ステップのシーケンスを示す。ＣＡＰ実現は、既存のｅ−コマースの上層をなすように設計することができ、これにより、販売者及び／または登録されたカード保有者が求めるカード保有者認証あり、及びこうした認証なしで取引を行うことができる。

ステップ２２００では、顧客が、例えば販売者のウェブページ上で、購入する品目を見て選ぶ。顧客は、例えばＰＤＡ２５０（図１２）をこの目的に使用することができる。ステップ２２１０では、販売者が顧客に決済（支払）情報の入力を促すことができ、これに応答して、顧客はカード番号を入力することができる。ステップ２２３０では、販売者が確認要求を表示して、顧客に「提出（注文を出す）」ボタンをクリックすることを要求することができる。ステップ２２３では、前記カード番号がキャッシュ記憶されているカードの範囲内にあるか否かをＭＰＩがチェックする。ステップ２２３において、前記カード番号がキャッシュ記憶されているカードの範囲内になければ、ＭＰＩはステップ２２７０において未認証の認可要求を出す。ステップ２２３において、前記カード番号がキャッシュ記憶されているカードの範囲内にあれば、ＭＰＩはＶＥＲｅｑを生成して、カード保有者がＣＡＰプログラム中に登録されているか否かを見て（ステップ２２４０）、検証を待機することができる。ステップ２２４では、所定の待機時間内に肯定の検証結果を受信しなければ、ＭＰＩはステップ２２７０に進んで、未認証の認可要求を出すことができる。さらにステップ２２４では、前記所定の待機時間内に肯定の検証結果を受信したならば、ＭＰＩはステップ２２５０に進んで、カード保有者の認証を要求するメッセージを発行者に対して生成することができる。

ステップ２２５では、要求に対する肯定の応答をタイムアウト（時間切れ）期間内に受信しなければ、ＭＰＩはステップ２２７０に進んで、未認証の認可要求を出すことができる。さらにステップ２２５では、要求に対する肯定の応答を前記タイムアウト期間内に受信すれば、プロセスはステップ２２６及びステップ２２７の順に進んで、それぞれ署名の有効確認が得られたか否か、及び（ＡＣＳによる）カード保有者認証プロセスが無事完了したか否かを確認することができる。これらのステップのいずれかが否定の結果であれば、ＭＰＩはステップ２２１０に戻り、このステップでは、販売者がカード保有者に決済情報の再入力を促すことができる。これらのステップの両方が、カード保有者の認証プロセスが無事完了したことを示せば、ステップ２２８では、ＭＰＩが認証結果を受け取り、この認証結果は肯定でも否定でもあり得る。そして種々の理由コードを有する。

さらにステップ２２８では、ＭＰＩが前記認証結果を問い合わせ、この結果に応じて、認証済みの認可要求をＵＣＡＦデータと共にＵＣＡＦ搬送フィールドに入れて出すか（ステップ２２６０）、あるいはステップ２２７０に進んで未認証の認可要求を出す。前記問合せの結果における理由次第では、ＭＰＩはオプションとして、決済情報の再入力を顧客に促すことを選ぶか（ステップ２２１０）、あるいは、ステップ２２７０に進んで未認証の認可要求を出すことができる。ＭＰＩは、ステップ２２７０または２２６０において、それぞれ未認証または認証済みの認可要求を出した後に、ステップ２２８０に進んで受信ページを顧客に対して表示することができる。

本発明は特定の好適な実施例に関連して説明してきたが、本発明の範囲を逸脱することなしに、開示した実施例に対して当業者にとって明らかな種々の変形、代替、及び変更を行うことができることは明らかである。

本発明の原理によるチップ認証プログラム及びその処理フローの好適な実現を図式的に示す図である。 本発明の原理によるチップ認証プログラム及びその処理フローの好適な実現を図式的に示す図である。 本発明の原理による、チャレンジ数の生成に関係するパーソナル・カードリーダのプロセス及びデータフローを図式的に示す図である。 本発明の原理による、未接続及び接続中のＰＣＲについてのＰＩＮ検証に関係するパーソナル・カードリーダのプロセス及びデータフローを図式的に示す図である。 本発明の原理による好適な８数字のチャレンジを示す図である。 本発明の原理による好適なＩＩＰＢデータトークンを示す図である。 本発明の原理による、暗号文のビットパターンを２進数として処理し、ベース２からベース１０への数学的変換を実行する好適な圧縮技術を示す図である。 ３−Ｄセキュア（登録商標）環境における好適なＣＡＰ（チップ認証）取引に関係するエンティティ間のメッセージ・フローのステップを（図１及び２と共に）示す図である。 本発明の原理による好適なＩＩＰＢデータ構造を示す図である。 本発明の原理による３−Ｄセキュア互換のＵＣＡＦ構造を示す図である。 本発明の原理による、ｅ−コマース環境における顧客のオンライン購入に関係する処理ステップを（図１及び２と共に）示す図であり、このｅ−コマース環境では、販売者が随意的に、取引のためにカード保持者の認証を要求する。 本発明の原理による好適な集積デバイスを図式的に示す図であり、この集積デバイスでは、ＩＣＣ、ＰＣＲ、及び／またはＰＣ装置の機能が１つの利便性のある物理的パッケージ内に集積されている。

Claims (30)

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. 前記ＡＲＳを用いて有効性を確認するステップがさらに、前記チップから受信したアプリケーション取引カウンタを、前記チップから受信した前記アプリケーション取引カウンタの前の値と整合させて、これにより前記取引を認証するステップを具えていることを特徴とする請求項２７に記載の方法。

Images