JP4597529B2 - 金融取引で使用するための認証の仕組みおよび方法 - Google Patents

Description

この発明は、一般にワイドエリアデータネットワークなどのコンピュータネットワークを使用する支払システムおよび方法に関する。特に、この発明は、集積回路カードなどを使用してインターネットなどのオープンネットワーク上で実行される支払システムおよび対応する方法の一部である認証の仕組みに関する。この方法は、認証の仕組みおよび方法を実現するためのソフトウェアにも関する。

技術背景
パーソナルコンピュータなどのユーザ端末またはメインアクセス装置を使用してインターネット上で購入を行なうことが知られている。インターネット上でオンライン購入された品物および／またはサービスの支払のためにスマートカードを使用するアーキテクチャおよびシステムは、ＵＳ６，２８２，５２２から既知である。クライアント端末上のクライアントサーバは、消費者とのやり取りを制御し、消費者のスマートカードを受入れるカードリーダにインターフェイスする。インターネット上の支払サーバは、取引およびデータの記憶を扱うコンピュータおよび端末を含む。ウェブサイト上で販売するために販売業者によって提供される品物および／またはサービスを広告する販売業者サーバもインターネット上で接続される。販売業者は、インターネット上で購入された品物および／またはサービスのスマートカードでの支払を受入れるために取得者と契約する。消費者は、クライアント端末で自分のスマートカードを使用して遠隔の販売業者サーバから品物および／またはサービスを購入する。インターネットは、クライアント端末、販売業者サーバおよび支払サーバの間の経路設定機能を提供する。

図１は、たとえば、インターネットにアクセスしかつ閲覧するためのユーザ端末またはメインアクセス装置１の概略図である。典型的には、端末１は、中央処理ユニット（ＣＰＵ）２を含み、これは、双方向通信のためにバス３を介してメモリ４および入出力（Ｉ／Ｏ）装置６に接続される。入出力装置６は、データを入力するためのキーボード、および取引の進行を表示するためおよび／またはメッセージもしくはプロンプトを表示するための液晶（ＬＣＤ）ディスプレイまたは発光ダイオード（ＬＥＤ）ディスプレイ、ＣＲＴなどの視覚的表示ユニットなどのスクリーンであってもよい。入出力装置６の１つはカードリーダ７であってもよく、これを用いて、集積回路カード（ＩＣＣ）５が受入スロットに導入されたときにそれを読むことができる。またはこれに代えて、カードリーダ７はＩＣＣ５を読取るためのスタンドアローン装置であってもよい。入出力装置６の１つは、インターネットサービスプロバイダ（ＩＳＰ）、たとえば、５６Ｋ、ＡＤＳＬなどを介してインターネットにアクセスするためのモデム９であってもよく、無線またはケーブルモデムであってもよい。端末の実際の形は大きく変わることがあり、Intel Corp. USAによって供給されるマイクロプロセッサのPentium（登録商標）ファミリーなどのプロセッサを含んでもよい。さらに、端末１は１つの場所にある必要はなく、カードリーダ７、キーボードおよびディスプレイなどの入出力装置、モデムおよびプロセッサなどの端末のさまざまな部品は異なる位置にあって、ケーブル、無線伝送または同様のもので接続されるか、またはローカルエリアネットワークの一部であるか、もしくは通信ネットワークによって相互接続されてもよい。

図２は、集積回路カード（ＩＣＣ）５の概略図である。ＩＣＣ５は少なくとも入出力（Ｉ／Ｏ）ポート１０および何らかの永久的な記憶装置、たとえば、バス１７を介して入出力ポート１０に接続されるＥＥＰＲＯＭ１５によって、またはバッテリ支援のランダムアクセスメモリ（ＲＡＭ）によって提供され得る不揮発性メモリを含む。入出力ポート１０
は、カードリーダ７を介して端末１と通信するために使用することができる。集積回路カードは、そこに１つまたは複数の集積回路が挿入されて少なくとも記憶機能を行なうカードである。オプションで、ＩＣＣ５は自立型の持運び可能なインテリジェントカードであってもよく、たとえばＲＡＭ１４によって提供される揮発性メモリなどの読取／書込可能な作業メモリ、および中央プロセッサ１２ならびに必要な回路を含んでもよいため、カードＩＣＣ５は、マイクロプロセッサとして動作することができ、たとえば、コードを記憶するためのリードオンリメモリ１３、シーケンサ１６および電圧源ＶｓｓおよびＶＤＤを受入れるためのカードリーダ７との接続、プロセッサ１２のためのリセットおよびシーケンサ１６へのクロックＣＬＫなどとして動作することができる。ＩＣＣ５は、バンクカード、クレジットカード、デビットカード、電子財布、医療カード、ＳＩＭカードまたは同様のものとして使用することができる。クロック、乱数発生器、割込制御、制御論理、チャージポンプ、電力接続、およびカードが外界と通信するのを可能にするインターフェイスの接触などのマイクロコントローラの他の特徴も存在し得るが、図示されていない。たとえば、暗号化モジュール（図示せず）は、さまざまな暗号化アルゴリズムを行なうために使用される任意のハードウェアモジュールである。

電子商取引業者は、図１に示されるように、通常ウェブページを介してユーザ端末からアクセス可能な商品またはサービスへのウェブサイトアクセスを備えたウェブサーバを提供し、これら商品およびサービスは、図２のＩＣＣ５などのカードを使用して購入可能である。多くの電子商取引業者は現在ではカード保有者のプロファイルをサポートしている。カード保有者のプロファイルは、カード保有者についての情報を収集し、このデータを使用してカード保有者の精算プロセスを合理化することからなる。収集された情報は、典型的には、課金住所、出荷住所、支払方法の詳細（たとえば、カード番号および満了期限）、電子メールアドレスおよび通信の好みを含む。多くの販売業者は、プロファイルされない精算もサポートしている。この場合、販売業者はカード保有者のプロファイルのデータベースをサポートしないか、またはカード保有者がこの販売業者とプロファイルを作成しないことを選んでいる。どちらの場合も、プロファイルされない精算プロセスは、カード保有者が手動ですべての出荷、課金および支払の詳細を提供することを必要とする。電子商取引業者は、オンラインショッピングおよび購入の体験がカード保有者にとってより効率的であるようにするために、さまざまなオンライン精算プロセスを実現している。いくつかの販売業者は、販売業者によって管理されるプロファイルデータベースに記憶されたカード保有者のデータおよび支払詳細を最大限に使用することによって、カード保有者に合理化された購入プロセスを提供することを意図した高速精算プロセス（図３）を実現している。閲覧し、特定の品目を選択した後、カード保有者は高速精算のオプションを選択する。販売業者はカード保有者のプロファイルを検索し、注文およびカード保有者の支払の詳細を組合せてユーザ端末にページを提示する。カード保有者はこれら詳細を検討して、注文を提出／確認することができる。

シングルクリック精算プロセスは、多くの販売業者によって実現されている（図４を参照）。シングルクリック精算プロセスは、販売業者によって管理されるプロファイルデータベースに記憶されるカード保有者のデータおよび支払詳細を最大限に使用することによって、カード保有者に最も効率的なオンライン購入プロセスを提供するためのものである。閲覧し、特定の品目を選択した後、カード保有者はシングルクリック注文オプションを選択し、これは一般に、品目の詳細および価格が説明されるすべてのページで利用可能である。通常、顧客はその品目を自分の「買物かご」に追加するか、または「シングルクリック」でそれを注文して支払うことができる。販売業者は注文の詳細およびカード保有者の支払の詳細を組合せて、注文書を作成し、これはカード保有者へのページで確認される。顧客は通常、何らかの形の顧客管理／ステータスページを通じて、当初のシングルクリックの後に取消、変更または複数のシングルクリックの注文を組合せることができる。

大抵の販売業者は標準的な精算をサポートしており、これは通常、注文の詳細を確認し、カード保有者の支払の詳細を収集するプロセスである（図５を参照）。標準的な精算プロセスは、プロファイルされないカード保有者によって使用されるはずである。支払の詳細を収集する必要があるためである。しかしながら、プロファイルされたカード保有者でも、異なる支払詳細／個人的な詳細を使用したい場合に、標準的な精算を使用することを選択することが多い。

閲覧し、特定の品目を選択した後、カード保有者は標準的な精算オプションを選択する。販売業者は、注文の詳細を示しかつカード保有者の支払の詳細を要求するページを提示する。カード保有者は、注文の詳細を検討し、支払の詳細を供給し、かつ必要であれば関係する個人情報を供給し、注文を提出／確認することができる。場合によっては、この組合された注文詳細確認／支払詳細要求ページは、図５に示されるように２つのページに分かれることもある。

今日では、遠隔取引は、すべての金融取引のうちのかなりの取引量を占める。さまざまな金融取引システムの説明は、“Secure Electronic Commerce”, W. Ford and M. S. Baum, Prentice Hall, 1997; “Digital Cash” by P. Wayner, Academic Press, 2^nd edition, 1997; “Designing Systems for Internet Commerce”, G. W. Treese and L. C. Stewart, Addison-Wesley, 1998などの書籍に見られる。リスクの面からすると、これら取引は保証されないことが多く、したがって、取得者／販売業者のリスクである。インターネットでのそのような金融取引のセキュリティは高くなければならないが、複雑な手続なしに便利な買物が可能でなければならない。インターネット金融取引の容易さおよびセキュリティを向上するための継続的な必要性がある。

発明の概要
この発明は、カード保有者が実際にその金融取引を許可したという証拠を提供できなかったために、これまで払戻しによって損害を被ってきた金融取引環境においてカード保有者認証の目的を達成する。これは、相互作用点（ＰＯＩ：point-of-interaction）でカード保有者を強く認証し、かつカードの存在ならびにカード保有者が取引を始めたことの明らかな証拠を提供することによって、インターネットチャネルを確実にするためのメカニズムを提供する。この発明は、以下の少なくとも１つを含むいくつかの目的を有する。

・カード保有者の許可しない取引という理由による払戻しを低減する。

・クレジットおよびデビットの取引の両方をサポートする。

・取得者システムの影響を最低限に抑える。

・販売業者の採用を迅速化する。

・真の口座番号、仮想の口座および偽りの口座番号に対する認証をサポートする。

一局面では、この発明は、コンピュータに基づく認証機構を提供し、特に、この発明はインターネットを介した金融取引を提供するためのコンピュータで実現される方法およびシステムを提供する。

この発明は、一局面では、集積回路カードを使用してネットワーク上で商品の販売を取
引するためにネットワーク支払システムで使用するための認証の仕組みを提供し、前記認証の仕組みは、前記ネットワークと通信する販売業者サーバを含み、前記販売業者サーバは販売のための商品の少なくとも第１の品目を有し、前記認証の仕組みはさらに、前記ネットワークと通信するクライアント端末を含み、前記クライアント端末は販売のための前記第１の品目を検討するための出力装置および販売のための前記第１の品目を購入するために購入取引を開始するための入力装置を有し、前記クライアント端末は販売業者の識別子に関連する情報および前記販売業者サーバから得られた金融取引情報に関連する情報を使用して購入メッセージを構築するように配置され、前記認証の仕組みはさらに、前記集積回路カードと通信するためのカードリーダを含み、前記クライアント端末は質問メッセージを生成するための手段を有し、前記質問メッセージは販売業者の識別子および口座番号に関連する情報から生成され、前記認証の仕組みはさらに、質問メッセージをカードリーダで受取り質問メッセージから値を生成するための手段を含む。この値は、ＩＣＣによって予測可能でない値であることが好ましい。ＩＣＣは、前記値の少なくとも或る部分から暗号メッセージを生成するための手段を有し、カードリーダは前記暗号メッセージの少なくとも或る部分から認証トークンを生成するための手段を有する。クライアント端末は、ネットワークを介して伝送するためにメッセージ内で認証トークンの少なくとも一部を伝送するための手段を有する。伝送は販売業者サーバに対するものであってもよい。ネットワークは金融取引を承認するための取引承認サーバを有してもよく、伝送は前記承認サーバに対して行なわれる。質問メッセージを生成するための前記手段は、販売業者の識別子、口座番号、および購入金額ならびに購入通貨のうちの少なくとも１つに関連する情報から質問メッセージを生成するように適合してもよい。前記認証トークンの少なくとも一部を伝送するための手段は、前記認証トークンの少なくとも一部を販売業者サーバに転送するように適合してもよく、販売業者サーバは、前記認証トークンの少なくとも一部を許可要求メッセージ内の購入情報とともに取引承認サーバに送るように適合される。質問メッセージを生成するための手段は、販売業者の識別子および口座番号、ならびにオプションで購入金額および購入通貨のうちの少なくとも１つを連結するように適合されてもよい。質問メッセージを生成するための手段は、販売業者の識別子、および口座番号、ならびにオプションで購入金額および購入通貨のうちの少なくとも１つの連結を圧縮するように適合してもよく、圧縮はハッシュ関数の適用によってもよい。承認サーバは、認証トークンの少なくとも一部を再構築し、再構築されたメッセージを販売業者サーバから伝送された許可要求メッセージ内の認証トークンの少なくとも一部と比較してもよい。取引承認サーバは、比較が正の場合に販売業者サーバに承認メッセージを送信するように適合してもよい。集積回路カードは、メモリおよび前記メモリに記憶される第１のデータオブジェクトを有してもよく、暗号メッセージの少なくとも或る部分から認証トークンを生成するための手段は、第１のデータオブジェクトに従って、暗号メッセージの部分の或る部分を選択するように適合してもよい。第２のデータオブジェクトは前記メモリに記憶してもよく、質問メッセージを生成するための手段は、第２のデータオブジェクトに従って、質問メッセージの生成に購入金額および購入通貨の少なくとも１つを含めてもよい。

別の局面では、この発明は、集積回路カードを使用してネットワーク上で商品の販売を取引する一部としての認証のための方法を提供し、この方法は、前記ネットワーク上でクライアント端末と販売業者サーバとの間の通信を確立するステップを含み、前記販売業者サーバは販売のための商品の少なくとも第１の品目を有し、この方法はさらに、前記クライアント端末で販売のための前記第１の品目を検討し、販売のための前記第１の品目を購入するために購入取引を開始し、かつ販売業者の識別子に関連する情報および前記販売業者サーバから入手された金融取引情報を使用して購入メッセージを構築するステップと、クライアント端末で質問メッセージを生成するステップとを含み、情報は販売業者の識別子および口座番号に関連し、この方法はさらに、カードリーダで質問メッセージを受取り質問メッセージから値を生成するステップと、集積回路カードとカードリーダとの間で通信を確立しかつ前記値の少なくとも或る部分から暗号メッセージを生成し、暗号メッセー
ジの少なくとも或る部分からカードリーダに認証トークンを生成し、ネットワークを介して承認サーバに伝送するために認証トークンの少なくとも一部をクライアント端末からメッセージ内で伝送するステップを含む。質問メッセージを生成するステップは、販売業者の識別子、口座番号、および購入金額ならびに購入通貨のうちの少なくとも１つに関する情報から質問メッセージを生成するステップを含んでもよい。前記認証トークンの少なくとも一部を伝送するステップは、前記認証トークンの少なくとも一部を販売業者サーバに伝送し、かつ前記認証トークンの少なくとも一部を認証要求メッセージ内の購入情報とともに販売業者サーバから取引承認サーバに伝送するステップを含んでもよい。質問メッセージを生成するステップは、販売業者の識別子、口座番号、およびオプションで購入金額ならびに購入通貨のうちの少なくとも１つを連結するステップを含んでもよい。質問メッセージを生成するステップは、販売業者の識別子、口座番号、およびオプションで購入金額ならびに購入通貨のうちの少なくとも１つの連結を、たとえば、ハッシュ関数を適用することによって圧縮するステップを含んでもよい。この方法は、承認サーバで認証トークンの少なくとも一部を再構築し、かつ再構築されたメッセージを販売業者サーバから伝送された許可要求メッセージ内の認証トークンの少なくとも一部と比較し、続いて比較が正の場合に販売業者サーバに承認メッセージを送信するステップを含んでもよい。集積回路カードは、メモリおよび前記メモリに記憶される第１のデータオブジェクトを有してもよく、この方法は、第１のデータオブジェクトに従って、暗号メッセージの部分の或る部分を選択することによって、暗号メッセージの或る部分から認証トークンを生成するステップをさらに含んでもよい。この方法は、第２のデータオブジェクトに従って、購入購入金額および購入通貨の少なくとも１つから質問メッセージを生成するステップをさらに含んでもよい。

この発明は、あらゆる環境で保証のための基礎をなすべき４つの構成要素を規定することによって、遠隔取引のためのすべてのチャネルおよび取引の種類に対処する。

ａ） ＣＡＭ機能、すなわち、カード／口座が本物であるという証拠。

ｂ） ＣＶＭ機能、すなわち、カード保有者が本物であるという証拠。

ｃ） 発行者による取引の許可の証明。

ｄ） 取引環境の説明。

この発明の一局面でのインフラの定義および実装は、電子商取引環境での保証された取引を実現する。そのようなサービスに好適な取引の第１のカテゴリはインターネットに基づく「電子商取引」および無線に基づく「ｍ−商取引」の両方の電子商取引の支払である。モデルは一般的であるため、これは一貫して複数のチャネルで使用可能であり、通信販売または電話注文を含む他の環境に拡張可能である。間接的なカード保有者の利点は以下の通りである。

・知覚されるリスクの低減。

・インターネット上でビジネスを行なう準備のできた販売業者が多くなる。

・上述のことが電子商取引のさらなる採用に繋がり、結果としてビジネスでの競争が刺激される。

・本物の「私ではない」取引に関する争いの低減／排除、結果として「いざこざ」の低減。

図面を参照してこの発明を説明する。

例示的な実施例の説明
この発明は、認証トークンを生成して汎用カード保有者認証フィールド（ＵＣＡＦ）内で発行者に運ぶパーソナルカードリーダ（ＰＣＲ）を使用する、たとえば、電子商取引に適用するためのＩＣＣ認証プログラムに関する。トークン生成機構を設計するにあたって、チェック数字等を使用し、データ要件を必要最小限に削減することによってカード保有者の使いやすさが実現されている。一局面では、この発明は、ＵＣＡＦを介したインターネットに基づく電子商取引のために、パーソナルカードリーダを使用したＩＣＣに基づく認証を実現するために使用される機構の機能的アーキテクチャを含む。

顧客およびカード保有者という言葉は、この発明の目的では交換可能であるが、一貫性のため、通常はカード保有者という言葉を使用する。これはカードが発行された人を厳密に意味するのではなく、カード、および、たとえば一例としてはＰＩＮなどのそのカードの認証機構の両方を所有する人を指す。文章および図面の全体において、販売業者、取得者、および発行者への言及は、データの入力またはメッセージ、ウェブページ等を渡すことに関するときはインターネットと通信するそれぞれのサーバを指す。

すべての表、図および文章の、番号の付けられたバイトへの言及、たとえば、「バイト１が転送される」などの言及は、ブロック／サブブロックの始まりから数えた、より大きなブロック内でのバイトへの言及のスタイルである。バイトは、最上位バイト／最下位バイトスタイルでは値に対して番号を付けられない。ときとして、このことによって、数値データ要素、たとえば、アプリケーション取引カウンタの最上位バイトがバイト１と称され、最下位がバイト２と称されることがある。一方、ビットは逆の態様で識別され、最上位ビットが「第１の」ビットで、ビット８と称され、最下位ビットが「最後の」ビットで、ビット１と称される。図６を参照されたい。番号が与えられ／示され、その基数が説明されない場合、十進法（十進数）と仮定される。数が与えられ／示され、始まりが「０ｘ」である場合、十六進法（十六進数）であると仮定される。

明細書の文章を例示しかつ明確にするために例が使用され、明細書と関連する例の内容との間に相違がある場合には、明細書が基準であると常にみなされるべきである。

用語
ＡＡＣ アプリケーション認証暗号
ＡＡＶ 口座保有者認証値
ＡＣ 認証暗号
ＡＦＬ アプリケーションファイルロケータ、ＩＣＣ内のどこに何の記録があるかを識別する
ＡＩＤ アプリケーション識別子、ＩＣＣ内で所与のアプリケーションを識別する十六進法の列
ＡＩＰ アプリケーション交換プロファイル、特定の機能をサポートするためのＩＣＣの機能を示す
ＡＰＤＵ アプリケーション処理データユニット、ＩＣＣと何らかの外部アプリケーションとの間で送信されるメッセージ
ＡＲＱＣ アプリケーション要求暗号
ＡＴＣ アプリケーション取引カウンタ
ＢＣＤ 二進化十進数
ビッグエンディアン 符号化スタイル、値はその最上位バイトが最初に記録され、各
連続するバイトが続き、最下位バイトが最後に記憶される
ＣＡＰ チップ認証プログラム
ＣＤＯＬ カードリスク管理データオブジェクトリスト
ＣＩＤ 暗号情報データ
ＣＳＮ カード連続番号
ＣＶＣ２ カード検証コード
ＣＶＭ カード保有者検証方法、カード保有者をカードに対して検証するために使用される方法
ＤＡＣ 動的認証暗号
ＤＯＭ 文書オブジェクトモデル、ブラウザによってプラグインに供給される現在のＨＴＭＬページのプログラム的な図
ＨＨＤ ハンドヘルド装置、たとえば、カードリーダ
ＥＭＶ ユーロペイ マスターカード ビザ
ＩＡ インターフェイスアプリケーション
ＩＡＤ 発行者アプリケーションデータ
ＩＡＦ インターフェイス認証フラグ、ＩＩＰＤの第１のバイト
ＩＣＣ 集積回路カード、チップカードまたはスマートカードとしても知られる
ＩＩＰＢ 発行者インターネット固有ビットマップ、ＡＣを確認するために発行者に送信される必要のあるビットを識別する
ＩＩＰＤ 発行者インターネット固有データ、インターネットに関連する取引のために暗号計算に関して発行者によって使用される固有のデータ
ＩＴＶ 対話型テレビ
ＬＡＴＣ 低い「バイトの」アプリケーション取引カウンタ
リトルエンディアン 符号化スタイル、値はその最下位ビットが第１に記憶され、各連続するバイトが続き、最上位バイトが最後に記憶される
ＭＡＣ メッセージ認証コード。メッセージ内のデータアイテムについて計算される暗号署名であって、メッセージの起源を証明しかつそれらのデータアイテムが変更されたかを検出する
ＭＣＤ メインカード保有者装置、閲覧および／または注文および／または支払が行なわれる装置
ニブル バイトの半分、すなわち、４ビット
Ｐ１ ＡＰＤＵのパラメータ１、ＩＣＣに送信されるコマンドを効率的にカスタマイズする
ＰＡＮ 主要口座番号
ＰＣ パーソナルコンピュータ
ＰＣＲ パーソナルカードリーダ
カード保有者ＩＡ カード保有者インターフェイスアプリケーション、認証要求者、カード保有者およびＰＣＲの間をインターフェイスする、ＭＣＤで作動するアプリケーション
ＰＤＡ 携帯情報端末
ＰＤＯＬ 処理オプションデータオブジェクトリスト、端末に利用可能な／端末によってサポートされる処理オプションのリスト
ＰＩＮ 個人識別番号
ＳＰＡ 安全な支払アプリケーション
ＴＬＶ タグの長さの値
ＵＣＡＦ 汎用カード保有者認証フィールド
ＵＮ 予測不可能な数字。

この発明による認証機構は、汎用カード保有者認証フィールド（ＵＣＡＦ）の使用である。この機構は、便宜上、チップ−ＵＣＡＦと称される。この言葉自身は、この発明を限
定しない。この発明は、ＵＣＡＦインフラを利用する安全な認証方法を提供する。これは以下の要素を含む。

・発行者提供のチップ−ＵＣＡＦ使用可能なインターフェイスアプリケーション
・チップ−ＵＣＡＦ口座保有者認証値（ＡＡＶ）の生成
・カード保有者の認証
・ＵＣＡＦ認証データフィールドでの、販売業者のＡＡＶデータの提示、収集および処理
・ＵＣＡＦに含まれるＡＡＶデータの、取得者の受入れおよび処理
・ＵＣＡＦ認証データフィールドでのＡＡＶデータの運搬のサポートを含めるためのバンキングネットワークの展開
・ＵＣＡＦ認証データフィールド内のＡＡＶデータの認証サポート
以下の実体がチップ−ＵＣＡＦ認証取引の期間に関与する。

・カード保有者−カード保有者は取引を開始し、販売業者の支払ウェブページへのデータの入力、カード保有者インターフェイスアプリケーション、およびパーソナルカードリーダへの責任を負う。

・販売業者−販売業者は、たとえば、インターネットと通信する販売業者サーバから、認証取引を始めるために必要なデータを供給し、結果的なＵＣＡＦデータを受取り、それらの取得者を介してカード発行者に承認のために送る。

・カード保有者インターフェイスアプリケーション−カード保有者ＩＡは、販売業者によって供給される関連データを検出し、直接的および間接的にカード保有者とやり取りし、カード保有者を通じてパーソナルカードリーダとやり取りする。カード保有者ＩＡは、ＡＡＶおよびＵＣＡＦを作成し、販売業者のページに適切なデータを投入する。たとえば、カード保有者ＩＡは、インターネット上で販売業者にアクセスするために使用されるメインカード保有者装置（ＭＣＤ）のインターネットブラウザの一部として作動してもよい。

・パーソナルカードリーダ−ＰＣＲはカード保有者およびＩＣＣとやり取りして、認証トークンを生成し、これは間接的に発行者に渡される。

・ＩＣＣ−チップカードは、提出されたＰＩＮ検証の使用を通じてカード保有者を認証し、ＰＣＲによって供給されるデータに基づいて好適な暗号を生成する。

・取得者−取得者は、たとえば、取得者サーバで、販売業者からフォーマットされたＵＣＡＦデータを受入れ、ＵＣＡＦデータの使用および存在のインジケータとともにそれを適切な通信ネットワークを介して発行銀行に送る。マスターカードは取得者である。

・発行者−カード発行者は、チップ−ＵＣＡＦ機構にサインアップしたカード保有者にＰＣＲを配布する。発行者は、インターネットと通信する発行者サーバプラットホームを維持する。この発明によると、発行者サーバは、その発行者のルールによって、取得者による許可要求内で伝送されＵＣＡＦに符号化された認証トークンを確認する。

一局面では、この発明は、電子商取引支払サービスのための認証を提供する。カード保有者存在ステータスが、オンラインでの取引に対して発行者に提供される。既存の支払機構ネットワークを通じた古典的な認証ルートも使用可能である。パーソナルカードリーダは、スタンドアローン装置として、またはカード保有者のアクセス装置（たとえば、ラップトップ、ＰＣ、ポケットＰＣ、スマートフォン、パームパイロット、ＰＤＡ）に接続さ
れる／一体化されて動作するものとして使用される。リーダは、限られたカード保有者のやり取りを可能にするためにディスプレイおよびキーパッドを有することが好ましい。パーソナルカードリーダの仕様は、最大限可能な数の異なるカードの実現例を可能とし、かつ同時にカード保有者の便宜を図ることが好ましい。パーソナルカードリーダは、ＰＩＮ確認結果を示すために、接続されない装置に対しては、メインカード保有者装置で手動で入力されなくてはならないトークンを示すために、ディスプレイ機能を有することが好ましい。パーソナルカードリーダは、データの発行者からの指標をＩＣＣから入手できなければならず、これはＩＣＣの署名の検証を可能にするためにそれらに転送されなければならない。パーソナルカードリーダは、取引の金額および通貨を生成されたトークンに組み込むべきか否かについての発行者からの指標をＩＣＣから入手できることが好ましい。そのような指標が作られるとき、リーダは、カード保有者が金額および関連する数値通貨コードを入力できるようにしなくてはならない。取引金額がカード保有者によって入力される場合、これは、「自然な」フォーマットであることが好ましく、すなわち、十進法のインジケータを含むことが好ましいが、カードの署名に含めるためにＩＳＯ ４２１７ベースの通貨単位に変換される。カード保有者によって入力されるか、またはその他の態様でリーダに通信されるそのような金額は、ＰＩＮを介してカード保有者によって承認される前に、関連する３文字の通貨シンボル、たとえば、ＥＵＲとともに表示されることが好ましい。

ＵＣＡＦ（汎用カード保有者認証フィールド）データフィールドは、デジタルメッセージ内の汎用データ運搬領域であって、あらゆる形の通信ネットワーク上で取得者から発行者への認証データの通信を可能にする。たとえば、ＵＣＡＦは３２文字のフィールド（１つの制御バイトおよび２３のデータバイトの２４バイトであって６４進法で符号化され３２文字になる）であって、さまざまな発行者のセキュリティおよび認証要件をサポートするために適合可能な柔軟なデータ構造を備えてもよい。たとえば、ＩＳＯ ８５８３データ要素４８、サブ要素４３は、ＵＣＡＦを含むように指定してもよい。ＵＣＡＦという言葉は、販売業者とＭＣＤとの間でデータを渡し、戻すために規定されるインターフェイス、すなわち、あらゆる所与のチャネルに対する明細書内のフィールド名も指す。

口座保有者認証値（ＡＡＶ）は、ＵＣＡＦアプリケーションの特定のデータの或る部分、たとえば、２３バイトに与えられる言葉である。各ＵＣＡＦアプリケーションは、そのＡＡＶに対する適切な構造を決定する責任を負う。所与のＵＣＡＦアプリケーションの実現の各例は、一貫した態様でそのアプリケーションのＡＡＶ構造を使用しなければならず、すなわち、ＡＡＶフォーマットは所与のＵＣＡＦアプリケーションに対して標準化される。

チップ−ＵＣＡＦカード保有者認証機構を使用するには、カード保有者は適切なＩＣＣ支払カードおよびパーソナルカードリーダを有する必要がある。ＰＣＲはカード発行者によってカード保有者に供給され、カード発行者は、そのカード保有者がＰＣＲを有し、かつチップ−ＵＣＡＦカード保有者認証機構に「参加している」と登録する。販売業者によって供給されるＵＣＡＦ取引データは表示のために使用され、その一部は取引関連のＰＣＲ質問の生成で使用される。販売業者がＵＣＡＦ応答内でＡＡＶデータに行なう必要がある処理は他にはない。これは、チップ−ＵＣＡＦに対する値にセットされるＵＣＡＦ制御バイト値を通じて販売業者に示される。カード保有者インターフェイスアプリケーション（カード保有者ＩＡ）は、認証要求者（販売業者）、カード保有者およびＰＣＲの間のやり取りを提供する。インターフェイスアプリケーションは、カード保有者に現在のＵＣＡＦ機構の安全な面を提示する。これは取引データをカード保有者に提示し、ＰＣＲに転送される質問を生成し、ＰＣＲトークン応答を受取り、ＵＣＡＦをフォーマットしかつ所与のチャネルに対して戻りデータを投入する責任を負う。カード保有者ＩＡは、チップ−ＵＣＡＦ取引を実施するために、それが満たさなければならない最低限の要件のセットを有
する。これは、インテリジェントフォーム記入、受領追跡／ログ、個人金融ソフトウェアとの統合等の付加的な機能性も追加する。

メインカード保有者装置（ＭＣＤ）は、閲覧／買物が恐らく実行され、かつこの明細書／機構の範囲では、支払および認証プロセスが行なわれる装置である。インターネットブラウザ環境での何らかのプラットホーム上のＰＣ装置に関してこの発明を説明する。カード保有者ＩＡは、この環境で実行しなければならない。

パーソナルカードリーダ（ＰＣＲ）は、電子商取引のために、装置に挿入されたカード保有者のＩＣＣによってＰＩＮ入力および確認を可能にする装置、たとえば、取引内容データのオフラインおよび認証を可能にする装置である。接続されないＰＣＲ、すなわち、外部システムとの物理的／電気的な接続を有さず、かつ装置からやり取りされるデータのためのインターフェイスがキーパッドおよびディスプレイを介したカード保有者である装置をこの発明で使用してもよい。他の種類の接続を備えたパーソナルカードリーダを使用してもよい。

接続されないＰＣＲ装置は、外部システムとの物理的／電気的な接続を有さない。装置からやり取りされるデータのためのインターフェイスは人、すなわち、カード保有者とやり取りするためのキーパッドおよびディスプレイである。接続されない装置を使用するとき、カード保有者は、ＰＩＮに加え、ＰＣＲが使用する或るデータをカードとともに手動で入力して認証値を生成しなければならない。認証値はＰＣＲのディスプレイに表示され、カード保有者は手動でカード保有者インターフェイスアプリケーションに入力する。チェック数字はデータ入力の確認を可能にするために使用される。

ＰＣＲ接続装置は、データを手動で渡すというカード保有者の不便なしに、より多くのデータをＭＣＤに転送することを可能にする。接続される装置は、接続ケーブルが取外されたときに、接続されないモードで動作できるようにしてもよい。

ＰＣＲ１方向接続装置は、外への方向にのみＭＣＤに接続される。装置へのデータのためのインターフェイスはキーパッドである。これはカード保有者とやり取りするためのディスプレイを有する。カード保有者は、ここでもＭＣＤとＰＣＲとの間のデータ輸送機構として働く。カード保有者は、ＰＩＮに加え、ＰＣＲが使用する或るデータをカードとともに手動で入力して認証値を生成しなければならない。認証値は１方向接続を通じてＭＣＤに送り出される。

２方向ＰＣＲ接続装置は、両方の方向でＭＣＤに接続される。装置はカード保有者のＰＩＮ入力のためのキーパッドおよびカード保有者とのやり取りのためのディスプレイを有する。カード保有者はＰＩＮを入力しさえすればよい。ＭＣＤはＰＣＲが使用するデータのすべてをカードとともに転送して、認証値を生成することができる。認証値はＭＣＤに送り出される。

一体型ＰＣＲ装置は、スマートカードリーダへの直接的な接続を有するＭＣＤである。この用語は組込みスマートカードリーダを備えたＰＤＡに当てはまるが、この技術は直接的に接続されたスマートカードリーダを備えたデスクトップＰＣであってもよい。カード保有者はＰＩＮを入力しさえすればよい。ＭＣＤはＰＣＲの機能性のすべてを行ない、接続されたリーダを通じてＩＣＣへ直接的にコマンドを転送する。ＩＣＣからの応答はＭＣＤ自身によって処理される。ソフトウェアは、カード保有者ＩＡが２方向接続装置に対するのと同じように挙動することができるように書かれ、すなわち、通信がカード保有者ＩＡによってＰＣＲに行なわれるときに、ドライバが同じＭＣＤ上に「偶然にある」ＰＣＲへのデータおよびそこからのデータを授受する。

接続され一体化されたＰＣＲ装置は、ＭＣＤに一体化される自立型ＰＣＲである。そのような装置に対する要件は、接続された装置に対するものと変わらず、ＰＣキーボード、他の入出力装置に一体化されてもよい。

ＵＣＡＦに関しては、ＵＣＡＦ使用可能な取得者は、ＵＣＡＦ使用可能な販売業者と関係を有する。取得者は、それらの販売業者が追加のＵＣＡＦデータを取得システムに渡すことを可能にし、かつそれらのシステムが供給されたＵＣＡＦデータの存在を識別しかつそれを発行銀行に渡すのを可能にする。

発行者ホスト、または発行者ホストとしてこの機構に対して作用する何らかのその他の要素は、認証ネットワークメッセージ内で渡されたデータを取り、そのデータをＵＣＡＦに含め、かつ認証トークンの確認を可能にする責任を負う。

この発明で説明されるチップに基づく機能が本質的にカード保有者の存在を発行銀行に対して検証する手段を提供する場合、この発明は、遠隔バンキング環境（「電子バンキング」または「ｍ−バンキング」）でも実現可能である。このことは、製品、サービスおよび環境に亘って一貫した消費者認証方法を銀行に提供する。

チップ−ＵＣＡＦは、ＵＣＡＦインフラを使用して、カード保有者、販売業者、取得者および発行者の間で認証およびセキュリティデータを運ぶ。図７はこの発明の或る実施例による典型的なチップ−ＵＣＡＦ取引のプロセスフロー図である。このフローは、取引を行なう前に、カード保有者がサービスに対して発行者に登録し、カード保有者インターフェイスアプリケーションを入手および初期化し、かつＩＣＣカードと互換性のあるパーソナルカードリーダを入手していることを前提とする。さらに、カード保有者が販売業者サーバで提供される製品またはサービスを識別し、精算プロセスを開始し、かつ販売業者によって支払カード詳細を提供するようにすでに要求されていることを前提とする。一旦品目が選択され、精算段階が開始すると、カード保有者は、課金住所、出荷住所および支払カードの詳細を販売業者に提供する。課金および出荷住所情報は直接的に入力されるか、または特定のカード保有者に対して販売業者で記憶される情報に基づいてもよい。販売業者が注文の確認および認証を要求するとき、販売業者のウェブサーバはこの取引を一意的に説明する一連の隠されたフィールドを提供する。たとえば、この情報は以下の１つまたはいくつかを含み得る。

・販売業者名
・カード受入都市
・カード受入州／国コード
・通貨コード
・販売金額
・販売業者取引スタンプ
・ＵＣＡＦ認証データフィールド
・支払カード番号（以前に供給されたカード番号の最後５桁が販売業者によって投入される）
・ＵＣＡＦブランド。

図７の番号を参照してこの発明の或る実施例を以下に説明する。

１．カード保有者のインターフェイスアプリケーションは、ＵＣＡＦ認証ページから販売業者の識別子情報および取引データを取得し、カード保有者に提示される質問を構築する。

２．カード保有者は支払カード（ＩＣＣ５）をパーソナルカードリーダに挿入する。パーソナルカードリーダで実現されるアプリケーションは、カード保有者に質問を入力するように要求するか、または質問は自動的にそこに転送される。パーソナルカードリーダは対で販売金額通貨を抽出し、カード保有者に販売金額をその通貨で入力するように要求する。

３．カード保有者は、取引に合意した証拠として、個人セキュリティコード、たとえば、パーソナルカードリーダのＰＩＮを入力するように促される。パーソナルカードリーダは支払カード（ＩＣＣ）にＰＩＮを検証するように要求する。

４．パーソナルカードリーダは、好適な暗号化ルーチンを使用して取引関連のデータ（すなわち、質問）に署名するように支払カード（ＩＣＣ）に要求する。

５．ＩＣＣは、取引データおよび他のＩＣＣの特定のデータ上で暗号を戻し、カード発行者はその暗号を確認する必要がある。署名および／または暗号化の方法は、上述の書籍および“Applied Cryptography”, B. Schneier, 1996, ISBN 0-471-11709-9, “Understanding Public Key Infrastructure”, C. Adams. S. Lloyd, New Riders, 1999から既知である。

６．パーソナルカードリーダは、次いで暗号の一部およびカード発行者によって識別される可変のデータを使用してデータトークンを構築する。

７．パーソナルカードリーダは、データトークンをフォーマットし、それをカード保有者に提示し、カード保有者はそれをカード保有者インターフェイスアプリケーションで手動でまたは伝送によって入力する。

８．カード保有者インターフェイスアプリケーションは、ＵＣＡＦに含めるためにＡＡＶを構築する。カード保有者インターフェイスアプリケーションは、この特定の取引のために生成されたチップ−ＵＣＡＦを、販売業者ＵＣＡＦ認証ページに設けられた隠された認証データフィールドに挿入する。取引は、販売業者による認証処理のために提出される。

９．販売業者は、その取得者に許可要求を提出する。許可要求は、変更されないチップ−ＵＣＡＦ値を含まなければならず、これは許可処理中に発行者によって検証される。

１０．取得者は（ローカル）許可要求を受入れ、許可要求メッセージを作成する。このメッセージはチップ−ＵＣＡＦデータを含む。許可要求メッセージはバンキングネットワークを介してカード発行者に送られる。取得者および発行者は、固有のメッセージのフォーマットに対するＵＣＡＦの仕様について合意する必要がある。

１１．バンキングネットワークは、チップ−ＵＣＡＦを含む許可要求メッセージをカード発行者に送る。

１２．許可要求メッセージを受取ると、カード発行者は以下のことを行なう。

ａ） 許可要求が、販売業者がＵＣＡＦ使用可能であると示さない場合（たとえば、セキュリティレベルインジケータビットが「０」にセットされ、「ＵＣＡＦは販売業者によってサポートされていない」と示す場合、後に説明する）、許可要求は、発行者の許可システムによって通常通りに処理される。

ｂ） 許可要求が、販売業者がＵＣＡＦ使用可能であり、カード保有者がチップ−ＵＣＡＦサービスに登録されているが、チップ−ＵＣＡＦ認証データが存在しないと示す場合（たとえば、セキュリティレベルインジケータビットが「１」にセットされ、「ＵＣＡＦは販売業者によってサポートされているが、カード保有者によって提供されていない」と示す場合、後に説明する）、発行者は許可を承認するか拒否するかを決定しなければならない。そのような状況は、カード保有者が支払取引を処理するためにチップ−ＵＣＡＦ使用可能なカード保有者インターフェイスおよびパーソナルカードリーダを使用しなかったことを示す。

ｃ） 許可要求がＵＣＡＦ認証データを含む場合、カード発行者はＡＡＶを確認する。

１３．発行者は、以前のステップの結果に基づいて承認で応答するか、または拒否する。この応答は同じネットワークシステムを介して販売業者に戻され、販売業者は適切にその顧客に応答する。

１４．販売業者の顧客に対する応答は、好適なフォーマットであればどのようなものでもよく、たとえば、オンライン許可のためのＨＴＭＬページ確認を通じてもよく、バッチ許可のための電子メールを介してもよい。

チップ−ＵＣＡＦのセキュリティは、或るセキュリティ機能に依存する。具体的には、チップ−ＵＣＡＦは、ＩＣＣによる暗号の生成、つまりアプリケーション要求暗号（ＡＲＱＣ）またはアプリケーション認証暗号（ＡＡＣ）に依存して、
・カード保有者の存在を立証し、かつ
・カード保有者による取引の承認を立証する。

さらに、これは本物の取引の再使用および偽りのチップ−ＵＣＡＦ取引の生成に対する予防策を提供する。したがって、好適なセキュリティ手段とともに使用されるとき、特にＰＩＮセキュリティに関連するとき、チップ−ＵＣＡＦは適切なレベルのセキュリティを提供してインターネット取引のカード保有者による拒絶がないようにする。

チップ−ＵＣＡＦによって提供されるセキュリティのレベルの評価は、以下の仮定に基づく。

・メインカード保有者装置（ＭＣＤ）、すなわち、実際の支払動作を行なうためにカード保有者によって使用されるプラットホームは信用できるものとみなされる。これは物理的な装置、たとえば、ＰＣまたは携帯電話、質問を生成するインターフェイスアプリケーション（ＩＡ）および関連するときにパーソナルカードリーダと通信するアプリケーションに当てはまる。ＭＣＤの制御されない本質のため、この仮定はあらゆる同様の製品に有効であるとみなされる。

・ＭＣＤで入力され販売業者に送信される、ＰＡＭまたは満了期限などの機密事項を扱う支払詳細のセキュリティは、この製品の範囲外である。このデータの機密性は、たとえばＳＳＬ暗号化に依存することによって、および販売業者のホストシステムでカードの詳細を保護することによって、ＭＣＤと販売業者との間のリンクの暗号化によって実施されるべきである。

ＩＣＣは確認を使用して、たとえば、オフラインのＰＩＮ確認を通じてカード保有者の存在を立証する。オフラインのＰＩＮ確認は、ＡＲＱＣの生成前に要求される。結果として、有効なＡＲＱＣを生成するにはカード保有者の存在が必要であり、そのような有効な
暗号の存在は、このカード保有者の存在を示すのに十分である。

しかしながら、これは、オフラインのＰＩＮ確認を義務付けないＡＡＣの生成には当てはまらない。カード保有者の存在を立証するためには、発行者は質問応答内で伝送されるＣＶＲのみに依存しなければならない。カード検証結果（ＣＶＲ）は、カードから伝送されるあらゆる情報を指し、カード保有者のＰＩＮが正しくカードによって検証されているかを発行者がチェックするのを可能にする。伝送中にＣＶＲの整合性を保護することが重要である。

この特性は、ＩＣＣがＡＡＣ計算入力データにＣＶＲを含めるときに確実となる。しかしながら、そのような挙動は義務ではない。ＣＶＲをＡＲＱＣまたはＡＡＣ計算入力データに含めないＩＣＣは、インターネット取引のためにＰＩＮなしに使用可能である。結果として、そのようなＩＣＣは、チップ−ＵＣＡＦプログラムのフレームで使用されないことが好ましい。

チップ−ＵＣＡＦは、取引の説明の要約をＡＲＱＣまたはＡＡＣ計算への入力として使用する。この要約は、ＡＲＱＣまたはＡＡＣ計算への入力パラメータからＵＮフィールドとして使用される。発行者による暗号の確認の成功は、カード保有者の存在の証明と組み合わさって、カード保有者による取引の承認についての何らかの保証を提供する。

取引の説明が確実に実際に考慮されるようにするため、ＡＲＱＣまたはＡＡＣの計算は予測不可能な数字（ＵＮ）を効率的に使用しなければならない。しかしながら、そのような挙動は義務ではない。結果として、ＵＮをＡＲＱＣまたはＡＡＣ計算入力データに含めないＩＣＣは、チップ−ＵＣＡＦプログラムのフレームで使用されないことが好ましい。

本物の取引の再実行に対する予防策を確実にするためには、２つの条件が満たされるべきである。

・ＩＣＣから受取られたＡＴＣは、その特定のＩＣＣに対して最後に受取られたＡＴＣに対してチェックされなければならない。既に受取られたＡＴＣを使用する取引は放棄されるべきである。

・ＩＣＣによって生成されるＡＲＱＣまたはＡＡＣは、ＡＴＣの関数として変動しなければならない。これはＡＴＣがＡＲＱＣまたはＡＡＣ計算への入力データに含められる場合にのみ当てはまる。しかしながら、そのような挙動は義務ではない。したがって、ＡＴＣをＡＲＱＣまたはＡＡＣ計算入力データに含めないＩＣＣは、チップ−ＵＣＡＦプログラムのフレームで使用されないことが好ましい。

パーソナルカードリーダ装置の使用に関連する主なセキュリティの問題は、装置自身による、カードのＰＩＮの露呈、またはＩＳＯ２トラックなどのカードに記憶された機密情報の露呈のリスクである。不正なまたは改竄されたパーソナルカードリーダは、ＰＩＮまたはＩＳＯ２トラックの機密性を危険に晒す。リスクのレベルは装置の種類によって異なる。

・接続されないパーソナルカードリーダのスタンドアローンの性質は、機密情報へのアクセスを得ようとする悪意のある者によってこれらの装置が物理的にアクセスされることを必要とする。そのような装置へは小規模な攻撃のみがあり得るため、そのような攻撃の影響は低いと予想される。

・１方向または２方向で接続されるパーソナルカードリーダは、物理的な接続の存在の
ため、不正使用の可能性が高い。そのような装置には大規模な攻撃があり得るため、そのような攻撃の影響は大きいと予想される。

・一体型のパーソナルカードリーダは、外界との透過的な通信の面でさらに柔軟性を提供し、不正使用の可能性が高い。

さらに、ＩＣＣによって戻されるＡＲＱＣまたはＡＡＣは、完全に発行者に転送される必要はない。それらはＩＩＰＢによって指定されるように切り捨ててもよく、このためＩＩＰＢは、ＡＲＱＣまたはＡＡＣからの或る数のビット、たとえば、少なくとも１６ビットがパーソナルカードリーダから戻されるデータトークンに含まれるように規定されなければならない。切り捨てられた暗号のサイズが小さいため、不正使用検出システムは、異常な数の暗号確認の失敗を検出しかつ適切な動作をとるために存在するべきである。

ＡＲＱＣまたはＡＡＣは、販売業者によって供給される情報に基づいて、発行者によって確認されるべきである。つまり、検証プロセスにおいて、発行者は、カード保有者装置によって提供される質問に依存するのではなく、元々の入力データから質問を構築するべきである。このことは、この発明に従って入力データおよび特別な認証トークンが販売業者から発行者に送信されることを必要とする。

アプリケーション暗号（ＡＲＱＣまたはＡＡＣ）を計算するために使用されるカードは、計算への入力としてＣＶＲを使用しなくてはならない。そうしないカードは、チップ−ＵＣＡＦ認証に使用するべきではない。アプリケーション暗号（ＡＲＱＣまたはＡＡＣ）を計算するために使用されるカードは、計算への入力としてＵＮを使用しなくてはならない。そうしないカードは、チップ−ＵＣＡＦ認証に使用するべきではない。アプリケーション暗号（ＡＲＱＣまたはＡＡＣ）を計算するために使用されるカードは、計算への入力としてＡＴＣを使用しなくてはならない。そうしないカードは、チップ−ＵＣＡＦ認証に使用するべきではない。発行者はＡＴＣが再使用されないようにするべきである。

発行者は、異常な数の暗号提出の失敗を検出しかつそれに働きかけるために不正使用検出システムを用いることが理想的である。

発行者は、ＵＣＡＦ自身のカード保有者のソフトウェアによって供給されるものに依存するのではなく、許可メッセージから暗号の検証のための質問データを再構築すべきである。

図８は、この発明の一実施例に従った詳細なＰＣＲおよびチップ−ＵＣＡＦのフローを示す。この図と以下の文章とは、この発明の一実施例の単なる例示としての役割を果たし、販売業者がＵＣＡＦ認証ページ上にＵＣＡＦ販売業者データを供給する点に始まって、販売業者が自分の取得者から許可応答を受取る点に至る、チップ認証プログラムに関するステップの単なる例示としての役割を果たす。さらに、たとえばステップ８で挿入されるカードといったいくつかのステップの特定の順序は任意であり、または、むしろ必須ではない。

この実施例のために、メインカード保有者装置は標準ブラウザを実行するＰＣであること、および、ＵＣＡＦ販売業者データがＨＴＭＬフォームの隠しフィールドに提示されることが仮定される。この実施例は、接続されていないＰＣＲが使用されることを仮定している。接続されていない装置、または一方向に接続された装置は、ＰＩＮ入力を含まない何らかのデータを入力するよう、カード保有者にプロンプトを表示し、二方向に接続された装置、または一体化された装置は、データの同じ要素がそれに渡されるよう、カード保有者ＩＡに要求しなければならない。しかしながら、この通信プロトコルの正確な仕組み
は、どの実現化例にも固有のものである。

販売業者からカード保有者への許可の確認は、この発明から除外されない。

図８では、販売業者がＰＡＮ、満了期限などを含む支払詳細を既に収集し、注文および支払詳細がＵＣＡＦ認証ページを介して最終決定可能な注文処理パイプラインの段階にあることが仮定される。カード保有者は自分のカード保有者ＩＡをＰＡＮの詳細で既に個人化しており、そのため、この支払に使用されているＰＡＮの最後５桁がＵＣＡＦフィールドに提示されると、カード保有者ＩＡは、それがそのＰＡＮの代わりを果たし得るかどうかを認識できる。

図８の番号について言及する。

１．取引データを照合する−販売業者は、ＵＣＡＦ仕様により必要とされる取引関連データを照合する。

２．取引データを送信する−販売業者は、所与のｅコマースチャネルについて規定されたメカニズムを介して、そのチャネルについてＵＣＡＦ仕様により規定されるように取引データを送信する。

３．ＵＣＡＦフィールドを検出する−メインカード保有者装置（ＭＣＤ）にインストールされたインターフェイスアプリケーション（ＩＡ）は、ＵＣＡＦ隠しフィールドの存在を検出し、たとえば販売業者により供給されたＰＡＮの最後５桁といった数字が、ＩＡに既に知られているＰＡＮに関連することを判断し、残りのＵＣＡＦデータを確認し、それ自体を提示する。

４．取引データを表示する−ＩＡは、そのユーザインターフェイスを介して、取引関連データをカード保有者に表示する。カード保有者はこの時点で取引を拒否するように決めてもよい。

５．カード詳細を確認する−インターフェイスアプリケーションは、カード保有者に、それが選択したカード詳細が正しいことを確認するよう要求してもよい。これは、たとえば、おそらく、カード保有者ＩＡをカード詳細で個人化する際にカード保有者が特定のカードに関連付けた「わかりやすい」識別子の使用を介して、カード保有者にどのカードをＰＣＲで物理的に使用するかを思い出させる、という形を取ってもよい。

６．質問を生成する−インターフェイスアプリケーションは、ある取引データ＋ＰＡＮからＰＣＲ質問を生成させる。

７．ＰＣＲ質問を表示する−接続されていない装置、または一方向に接続された装置については、インターフェイスアプリケーションは質問を表示し、それはカード保有者によってＰＣＲに入力されなければならない。

８．カード挿入−カード保有者はＩＣＣ５をＰＣＲに挿入する。

９．ＰＣＲ質問を転送する−ＰＣＲ質問はＰＣＲに転送される。接続されていない装置、または一方向に接続された装置については、カード保有者は、インターフェイスアプリケーションおよびＰＣＲ自体からのプロンプトに応答して質問をＰＣＲに入力することによって、これを行なう。その他の場合、それはＰＣＲに送信可能である。

１０．オプション：転送金額−認証機構が金額および通貨を必要とする場合、金額はＰＣＲに転送される。接続されていない装置、または一方向に接続された装置については、カード保有者は、ＰＣＲからのプロンプトに応答して取引金額をＰＣＲに入力することによって、これを行なう。その他の場合、それはＰＣＲに送信可能である。

１１．ＰＩＮを入力する−カード保有者は、インターフェイスアプリケーションおよび／またはＰＣＲ自体からのプロンプトに応答して、ＰＣＲまたはＭＣＤにおいてＰＩＮなどのセキュリティまたは確認コードを入力する。

１２．ＵＮを作り出す−ＰＣＲは予測不可能な数字を作り出す。

１３．ＡＣを生成する−ＰＣＲはＡＣ生成（GenerateＡＣ）コマンドを構築し、カードに送信する。

１４．ＡＣを含む応答−カードは、ＡＣおよび他のデータをＰＣＲへの応答として戻す。

１５．ＰＣＲトークンを作り出す−ＰＣＲは、ＩＩＰＢにおいて発見された発行者仕様に基づいて応答を「分解」し、ＰＣＲトークンを作り出す。

１６．ＰＣＲトークンを表示する−ＰＣＲは１０進数のトークンをカード保有者に表示する。

１７．ＰＣＲトークンを転送する−ＰＣＲトークンはＰＣＲから転送される。接続されていない装置については、カード保有者は、インターフェイスアプリケーションからのプロンプトおよびＰＣＲ上の表示に応答して、ＰＣＲトークンをインターフェイスアプリケーションに入力することによって、これを行なう。その他の場合、それは自動的に転送可能である。

１８．ＵＣＡＦを符号化する−インターフェイスアプリケーションは、チップ−ＵＣＡＦ構造を符号化し、ＵＣＡＦ制御バイトを設定し、次に、ＵＣＡＦにおける送信のためにそれを６４進法で符号化する。

１９．ＵＣＡＦを戻す−インターフェイスアプリケーションは、さまざまな戻りデータアイテムを、販売業者の支払要求通信に符号化する。

２０．許可要求を構築する−販売業者は、販売業者に戻された隠しフィールドにおけるＩＡにより供給されたデータを抽出し、自分の取得者への固有の許可要求を構築する。

２１．許可要求−販売業者は、ＵＣＡＦを含む許可データを自分の取得者に渡し、取得者はそれを適切な発行者に渡す。

２２．ＳＬＩを設定する−取得者は、セキュリティレベルインジケータ（ＳＬＩ）を、許可取引にとって適切なように設定する。

２３．ＩＳＯ８５８３−０１００−取得者は許可要求を発行者に送り、発行者は次に、メッセージに対して何らかの初期標準処理を行なう。

２４．ＵＣＡＦ処理−発行者はＵＣＡＦの存在についてチェックする。

２５．オプション：質問を再構築する−ＰＣＲへの質問がメッセージデータから再度作り出され、予測不可能な数字が再度生成されるようにする。

２６．カードデータを検索する−発行者は、あるデータ要素を、再構築可能にするために、ＩＣＣデータベースから検索しなければならない。

２７．再構築−ＰＣＲによって使用されるアルゴリズムの知識に基づいて、ＰＣＲトークンが発行者によって生成される。

２８．比較する−発行者は、許可メッセージにおける削減されたＰＣＲトークンを、入力データから生成されたＰＣＲトークンと比較する。これは、比較を取扱う「セキュリティボックス」への変更を伴う場合がある。

２９．ＩＳＯ８５８３−０１１０−発行者は許可要求応答を取得者に送る。

３０．許可応答−発行者は、取得者を介して、許可応答を販売業者へ戻す。

ステップ１〜２１はこの機構に特有のものである。

・販売業者は、ある特有の特定されたフォーマットで取引データを照合し、提示する
・カード保有者のメインアクセス装置、カード保有者インターフェイスアプリケーション、ＰＣＲ、およびカード保有者自身が、ＰＣＲトークンを生成させ、販売業者に戻らせる
・販売業者は新しいデータを既存の取得者通信に渡す。

ステップ２２は、ＵＣＡＦデータを取扱う際に取得者が取るべき追加ステップを示す。

・取得者は、販売業者によって供給されるデータに依存して、セキュリティレベルインジケータの設定に対して責任を負う。

ステップ２３は、ＩＳＯ８５８３−０１００許可要求メッセージを介した、取得者への、それから発行者への支払データの既存の送信の要約である。

・０１００メッセージを受取ると、発行者は、ＵＣＡＦに何らかのデータがあるかどうかを判断する小規模なステップを実行しなければならず、それを適切に処理する。

ステップ２４〜２８はこの機構に特有のものである。

・発行者はＵＣＡＦからデータを抽出し、ＰＣＲ認証トークンを検証する。

ステップ２９および３０は、既存のＩＳＯ８５８３−０１１０許可要求応答メッセージおよび販売業者への応答の要約である。

・ＰＣＲトークンが有効であることに満足した発行者は、取得者を介して、０１１０メッセージを販売業者に戻す。

この詳細なフロー図および説明は、関与するｅコマースチャネルとは独立した解決策を示す。インターフェイスアプリケーションと販売業者システムとの間のリンクであるステップ２および１９は、所与のｅコマースチャネルについての仕様に対して依存が存在する点である。

この発明の一局面によれば、異なるチャネルが使用可能であり、インターネットアプリケーションの形をした異なる発行者ソフトウェア、および、たとえばＨＴＭＬフォーム、ＸＭＬデータ交換などといった、おそらく異なるものの必ず標準化された販売業者のやり取りを必要とする。しかしながら、データ内容、アルゴリズム、およびフローは、異なるチャネル間でも同じままである。

上述の機構では、販売業者は、自分自身および取引についての詳細を提供する。

要約すると、これらのデータ要素は、以下のものから選択される。

・販売業者の名前
・販売業者の市
・販売業者の州／国コード
・通貨コード
・販売金額
・販売業者の取引スタンプ
・ＵＣＡＦブランド
・支払カード番号（最後の５桁）。

この発明に従った方法において使用され得るあるカード特有データは、発行者インターネット固有データ（ＩＩＰＤ）である。発行者インターネット固有データ（ＩＩＰＤ）は、カード上でのその存在がオプションであるデータオブジェクトである。それは、同様に名付けられた発行者インターネット固有ビットマップ（ＩＩＰＢ）とは、チップ認証プログラムに起因するその導入以外は関係ない。それは、インターネット環境で使用される際に名目上暗号の生成とともに固有の態様で使用するよう発行者が選択するデータを含んでいるが、それは、他のデータ、または代替的なデータも所持していてもよい。たとえば、発行者へのカード連続番号（ＣＳＮ）の転送が必要とされるかもしれない。これは、所与のカードにとって静的であり、それをＩＩＰＤに符号化することによって発行者に渡され得る。このＣＳＮは、最初のＩＡＦ「バイト」の下位ニブルにおいて渡され得る。この手法は、カード保有者のデータ入力を軽減する。その使用は文字通り、発行者に固有のものである。

ＩＩＰＤの最初のバイトは、主としてパーソナルカードリーダ（ＰＣＲ）により使用される１組の包括的なフラグを所持する。表１は、これらの概略的な表示を表わす。

ビット８が１に設定されている場合、それは、ＡＣを生成する際に取引金額および通貨を使用すべきであることを発行者が要求していることを示す。ＰＣＲにとって、これは、それがカード保有者／メインカード保有者アクセス装置（ＭＣＤ）に通貨および金額を供給するよう促す／要求することを意味しており、インターフェイスアプリケーション（ＩＡ）にとっては、金額および通貨が供給される必要があることを意味する。ビット８が０に設定されている場合、金額（０）および通貨（９９９−通貨が関与しない取引について使用されるコード）についてのデフォルト値が、ＡＣを生成する際に使用される。ビット７が１に設定されている場合、それは、カードから要求されるべき暗号の種類がＡＲＱＣであることを発行者が要求していることを示す。ビット７が０に設定されている場合、それは、カードから要求されるべき暗号の種類がＡＡＣであることを発行者が要求していることを示す。最初のバイト以降のＩＩＰＤデータは、発行者に固有の使用に対して自由である。

ＩＩＰＤは、その内容が、インターネットに関連した使用のために暗号を生成するのに所与のチップ実現化例によって要求されないかもしれないので、オプションの構造である。しかしながら、それは処理をどう進めるかをＰＣＲに指示するインジケータを含むため、それがない場合には、ＰＣＲはデフォルト設定に頼らなければならない。カードがＩＩＰＤを有さない場合、０×４０のデフォルトバイト値が使用可能であり、たとえば「取引金額および通貨がなければ、ＡＲＱＣが生成される」。

ＩＩＰＤは、口座保有者認証値（ＡＡＶ）で発行者に送信されなければならない。しかしながら、それは好ましくは、ＰＣＲによってカード保有者インターフェイスアプリケーション（ＩＡ）に転送されない。なぜなら、これは、接続されていない装置については、カード保有者にあまりにも大きなデータ転送負荷を与えるためである。ＩＩＰＤは所与のカードについて静的であるため、それは、ＰＡＮおよび他の静的カードデータがカード保有者ＩＡに供給されるのと同じように、カード保有者ＩＡに供給可能である。

さらに、カード保有者ＩＡは、通貨および金額がＰＣＲに転送される必要があるかどうかを判断するために、ＩＩＰＤを知っていなければならず、または、たとえば０×４０といったデフォルト値を使わなければならない。通貨情報は、ＰＣＲ質問の一部として転送可能である。

ＵＣＡＦ準拠により課されるデータ空間制限、および、少なくとも何人かの発行者が接続されていない装置、または一方向に接続された装置を使用する必要があることの双方のために、装置がＭＣＤに転送し返さなければならないデータは、サイズが制限されている。したがって、ＩＣＣに送られたGenerateＡＣコマンドに応答して生成されたＡＣを再計算するよう発行者によって要求されたデータの選択された一部のみが、好ましくは転送される。

最初のGenerateＡＣコマンドへのＩＣＣによる応答は、以下の要素から構成される。

・暗号情報データ（ＣＩＤ）
・アプリケーション取引カウンタ（ＡＴＣ）
・ＩＣＣによって計算された暗号（ＡＣ）
・発行者アプリケーションデータ（ＩＡＤ）。

それらは、以下のもののいずれかであるデータを含む。

・この取引に独特のもので、カード保有者によってＰＣＲからカード保有者装置へ転送
されなければならないデータ
・この特定の機構について特定の値であることが仮定され、そのため、カード保有者によってＰＣＲからカード保有者装置へ転送される必要のないデータ
・この取引またはＩＣＣに独特のもので、発行者ホストによって、そのカードデータベースを介して知られているかまたは少なくとも推論可能なものであり、そのため、カード保有者によってＰＣＲからカード保有者アクセス装置へ転送される必要のないデータ。

発行者インターネット固有ビットマップ（ＩＩＰＢ）は、カード上でのその存在がオプションであるデータオブジェクトである。このデータは、GenerateＡＣ応答のどのビットが発行者ホストシステムによって要求されているかを示す送信フラグからなる。フラグは、各ビットベースで、ＣＩＤ（たとえば１バイト）、ＡＴＣ（たとえば２バイト）、ＡＣ（たとえば８バイト）およびＩＡＤ（たとえば０〜３２バイト）から送られなければならないビットに対応している（図９参照）。ＩＩＰＢは長さが変更可能であり、たとえば、ＩＡＤが規定されていない場合の１１バイトから、発行者アプリケーションデータ（ＩＡＤ）が利用可能な３２バイト全体を発行者のアプリケーション技術が使用している場合の４３バイトまで変わる。

ＩＩＰＢは、これらの値のうち、どの、そしていくつのビットをそれが認証確認のために使用するかについて、発行者が完全に選択できるようにし、これにより、ＰＣＲ自体が任意の特定のカード技術を認識して、その技術に特有のものとなる必要性を排除する。ＩＩＰＢは、カード保有者ＩＡによりＡＡＶに取入れられて発行者に渡されるトークンをＰＣＲに構築させるビットマスクとして使用可能である。

発行者は、暗号を検証するのに必要とする最小可能ビットをマークするＩＩＰＢを規定できる。必要であるとしてマークされるビットの数は、ＰＣＲによって生成されるデータトークンの潜在的なサイズを決定する。

新しいＩＩＰＢタグを持たない既存のカードに主として関連するために、ＩＩＰＢはオプションの構造である。しかしながら、それはＰＣＲが抽出して圧縮しなければならないビットを識別するために使用されるため、それがない場合には、ＰＣＲはデフォルト設定に頼らなければならない。デフォルトＩＩＰＢは、たとえば、１９バイトの構造であり得る。この結果は、発行者に送られている３５ビットのデータであり、それをＰＣＲのディスプレイ上に表わすには、１１個の１０進法数字を必要とする。最後のチェック数字を含めると、デフォルトＩＩＰＢは、カード保有者によって入力されるべき１２桁のトークンをもたらす。

発行者は、あるアプリケーション技術にとって適切にＩＩＰＢを特定できる。このＩＩＰＢは次に、ＰＣＲがＰＣＲに記憶されたデフォルトＩＩＰＢよりもむしろカードに記憶されたＩＩＰＢを使用するように、そのアプリケーションについての個人化仕様に含まれる必要がある。

発行者が、自分の発行したカードとトークンを作り出すために使用されたＰＣＲとの間に１対１の整合があることを快適に感じている場合、または要求している場合、発行者はその特定のリーダにおけるデフォルトＩＩＰＢを変更してもよい。これは、ＩＩＰＢがカードに記憶される必要がないことを意味する。しかしながら、そのようなカードはどれも、デフォルトＩＩＰＢを使用するＰＣＲでは使用不可であろう。

カード保有者のブラウザから販売業者に送られるデータは、各ブラウザチャネルについてのＵＣＡＦ認証データフィールドのみからなり得る。

ＵＣＡＦは２４バイトのユーザ認証トークンを含み得る。これらの２４バイトは、好ましくは、カード保有者ＩＡによって符号化、たとえば６４進法で符号化されて、販売業者に戻される３２個のＡＳＣＩＩ文字のデータを与える。販売業者は、ＵＣＡＦデータを、取得者との自分固有の通信において渡し、取得者は次にＵＣＡＦを、発行者に送られる許可要求メッセージに投入できる。ＵＣＡＦの包括的な構造を図１０に示す。

ＵＣＡＦ制御バイトは１バイトの値であり、それは、ＵＣＡＦがどの種類のデータを移送するために使用されているかを示す。以下の値は、ＵＣＡＦ制御バイト符号化に使用可能である。

・０×８２などの第１の値−ウォレットサーバを用いたＳＰＡ−ＵＣＡＦ
・０×８８などの第１の値−ＩＣＣを用いたチップ−ＵＣＡＦ。

以前の拒否または分割出荷のいずれかのために販売業者が許可を再送信する必要がある場合には、ＵＣＡＦ制御バイトの先頭ビットは消去されなければならず、以下の値をもたらす。

・０×０２などの第３の値−ウォレットサーバを用いた、次のＳＰＡ−ＵＣＡＦ許可
・０×０８などの第４の値−チップを用いた、次のチップ−ＵＣＡＦ許可。

この発明は、バイオメトリックスなどの他の認証手法を含み、そのような場合、その特定の手法にはそれ独自の制御バイト値が割当てられ、アプリケーション特有データの構造はバイオメトリックス認証アプローチをサポートするよう適合される。この場合、すべてのバイオメトリックス認証アプリケーションは、一貫したアプリケーション特有データ構造を使用すべきである。

口座保有者認証値（ＡＡＶ）を概略的に図１１に示す。以下のデータがＵＣＡＦにおいて発行者に転送される。

・ＩＩＰＤ−オプションで、長さが可変であるが、常に複数のバイトである。それは、そのカードについてのＩＩＰＤにおいて発行者の規定した位置にあるよう発行者によって規定された、たとえば４ビットのカード連続番号を含んでいてもよい。

・たとえば長さが３２ビット（４バイト）の予測不可能な数字
・ＰＣＲトークンに符号化されるようなＩＩＰＢデータトークン−長さは不明、ビット数はＩＩＰＢによって決定される。

長さは、好ましくは、たとえば１８４以下であるといったビットの第１の最大数に制限される。なぜなら、理想的には、発行者はＩＩＰＢを供給すべきではなく、それは、ＩＩＰＤと組合されると、たとえば１５２ビット（最大データ領域−長さ（ＵＮ））といったビットの第２の最大数を超えるものが転送されなければならない結果をもたらす場合があるためである。念のため、カード保有者ＩＡは、第１の最大値を超える、つまり１８４ビットよりも多いビットをもたらすいかなる演算もエラーとなって、データが符号化されないことを確実にすることができる。

ＩＩＰＤデータの有無を示す、チップ−ＵＣＡＦ用のＡＡＶの符号化へと構築される表示は、必要ない。ＡＡＶに何を期待すべきかを発行者のホストシステムが知っていることを確実にするのは、発行者次第である。カード保有者ＩＡにより任意のＩＩＰＤが符号化されて包められることは、任意のＩＩＰＤが、特定の取引のためにカード保有者によって使用された支払カードに関連するかどうかに依存する。

チップ−ＵＣＡＦ用のＡＡＶに符号化されたＵＮは、サイズが丸々４バイトであってもよく、それは、GenerateＡＣコマンドにおいてＩＣＣに送られるＵＮと同じサイズである。ＵＮの大きさは、データ移送フォーマットに影響を与えることなく、その全範囲内で変更可能であり、たとえば増やされるか、または場合によっては減らされさえする。

ＵＮ範囲の制限は、データをＭＣＤからＰＣＲに転送するためにカード保有者が入力しなければならない桁数を制限する結果であり得る。互換性の理由により、この制限は、ＰＣＲに提示されるＰＣＲ質問のサイズの表示が別にない限り、接続された装置および接続されていない装置の双方に適用可能である。

発行者は、ＩＩＰＤおよびＩＩＰＢデータトークン双方の長さを知っている。カード保有者ＩＡはＩＩＰＤの長さを知っているが、それはＩＩＰＢデータトークンの長さは知らず、そのため、それは好ましくは、ビットを右寄せすべきである。つまり、図１２に示すように、０フィラーを用いて、最下位ビットが最後のビット位置に現われる。その結果、ＰＣＲトークンにおいて渡されない任意の左寄せされたＩＩＰＢデータトークンデータは、それが０に設定され、したがって数値トークン導出にかかわりがなかったために、それが表わした０値に設定される。これは、カード保有者ＩＡがまず、ＡＡＶの２３バイト全体をゼロにしたためであり、転送されたＰＣＲトークンの左端のセットビットからの残りのビットすべてが、０の設定を有するＵＮへバックアップする結果となる。これらのビットのうちのいくつかは、それらがＩＩＰＢデータトークンにおいて有する０値を表わすものの、残りは単なる０フィラーである。

カード保有者ＩＡは、どのビットが０に設定されたデータを表わし、どのフィラーが同様に０に設定されているかを知らないが、それは問題ではない。なぜなら、発行者は、ＩＩＰＢの有効長を知っているため、どのビットがデータであるかを知っているからである。

販売業者と取得者との間のリンクは固有であり得るが、販売業者は、好ましくは、以下の追加データを取得者に転送すべきである。

・ＵＣＡＦ認証データフィールド
・エラーステータスインジケータ。

発行者は、取得者から、許可ネットワークを介して認証要求メッセージを受取る。それは、修正されたセキュリティレベルインジケータ（ＳＬＩ）およびＵＣＡＦ認証データに加え、標準許可データを含む。認証要求メッセージは、ＵＣＡＦ取引での使用のために拡張されたＳＬＩを含む。

カード保有者のデータ入力の精度を高めるため、単一の後続するチェック数字が使用可能である。この追加の数字が付与する確認チェックの価値は、数字をさらに入力する不便さを補って余りある。チェック数字に使用されるアルゴリズムは、ＰＡＮを確認するために使用されるような、「係数（Modulus）１０」としても知られる「ルーンの公式（Luhn Formula）」などの任意の好適なチェックアルゴリズムであり得る。チェック数字は、ｎ桁のＰＣＲ質問に適用可能であり、たとえば、７桁の質問についてたとえば８桁といったある桁数を入力するよう、カード保有者に要求する。パーソナルカードリーダは、チェック数字を確認し、正しくない値が入力された場合にはカード保有者に連絡する。組合されたＵＮ／通貨数字が使用された場合、チェック数字は完全な「数字」に当てはまる。正しくない値が入力された場合には、装置は、好ましくは、プロセスを破棄または再始動してはならず、ＰＣＲ質問が再度入力されるのを待つ／促すことが可能である。所望すれば、
ＰＣＲ質問を入力する無効な試みの数に対して、制限が設けられてもよく、設けられなくてもよい。

接続されていない装置については、チェック数字は好ましくは、表示されたｎ桁のＰＣＲトークンに適用され、たとえば、１２桁のＰＣＲトークンについて１３桁といったある桁数をＭＣＤ上に入力するよう、カード保有者に要求する。パーソナルカードリーダは、チェック数字を計算し、それを表示されたＰＣＲトークンの最後に適用する。

一方向に接続された装置については、チェック数字は同様に適用されるべきである。なぜなら、一方向通信はデータ送信のハンドシェイク検証を許容しないためである。カード保有者ＩＡは、これらの装置についてチェック数字を検証し、もしエラーが検出されればエラーをカード保有者に報告しなければならない。これは、ＰＣＲとの取引が繰返される必要があることをもたらす。

チェック数字は、送信媒体エラー検出メカニズムである。ＭＣＤと双方向に接続された／一体化された装置との間のいずれの方向の通信についても、根底にある送信プロトコルは同様に、送信のみに関連する任意のエラーを訂正するかもしれない。

ＰＣＲ質問は発行者に渡される。ＰＣＲ質問は、GenerateＡＣコマンドにおいて取引金額が必要とされているかどうかに依存して、たとえば１つ、または、２つか３つといったそれ以上の部分からなる。

・予測不可能な数字（ＵＮ）
・オプションの通貨コード
・上述のルーンチェック数字といった、１つ以上のチェック数字。

ＰＣＲ質問は、予測不可能な数字（ＵＮ）を作り出すために使用される。ＰＣＲは、GenerateＡＣコマンドの一部として、ＵＮをＩＣＣに供給する。ＵＮは、カード保有者ＩＡから得られた値を含む全３２ビット構造として供給され得る。この値の範囲は、好ましくは制限される。この範囲の大きさは、カード保有者が接続されていない装置にキー入力するのに受入れ可能と思われる最大の桁数によって決まり得る。「予測不可能」という用語は、その数字がＩＣＣにとって予測不可能であることを意味し、それが、ＩＣＣに値を供給するアプリケーション、またはカード外部の任意の他のエンティティにとって予測不可能であるという意味ではない。

ＰＣＲ質問は、好ましくは、ある桁数を有する１０進数であり、それはＰＣＲに転送されなければならない。ＵＮと同様、それも、追加の後続するチェック数字とオプションの通貨コードとからなり得る。このため、接続されていない装置、および一方向に接続された装置については、カード保有者は質問を手動で転送し、入力される桁数は、カード保有者の都合、またむしろ不都合の問題である。他の種類の接続された装置については、質問は直接渡されることができ、したがって、使用される桁数は問題ではない。しかしながら、相互運用性の理由により、発行者は、ある特定の取引のためにカード保有者によって使用された装置の種類を認識しないため、または認識してはならないため、カード保有者ＩＡは、好ましくは、ＵＮの可能な範囲を表わすのと同じ最大桁数を使用する。

桁数は、たとえば８までに制限され得る。ＰＣＲはこの「制限」を認識できない。なぜなら、ＰＣＲ質問のＵＮ部分は単に、３２ビットのＵＮ構造に適合可能となるべき値であるためである。

（たとえばＩＩＰＤのバイト１におけるＩＡＦフラグ設定によって示されるように）Ａ
Ｃを生成するために使用されるGenerateＡＣコマンドにＰＣＲが金額および通貨を取入れることを発行者が要求している機構では、ＰＣＲは、金額および通貨がそれに転送されることを必要とし得る。３桁の通貨コードを接続されていない装置、または一方向に接続された装置に転送する際に生じ得るカード保有者への混乱を軽減するために、コードは、質問において渡されるＵＮの終わりに取入れられ得る。このため、チェック数字が勘案される場合、カード保有者は、機構が金額入力を要求する際、全部で１２桁の質問を入力する。

要約すると、ＰＣＲ質問のソースは、以下のものとなり得る。

・取引金額
・取引通貨
・販売業者の名前
・ＰＡＮ。

ＰＣＲ質問を生成するために使用されるメカニズムは、相互に運用可能でなければならない。なぜなら、発行者は、ＵＮがソースデータに対して有効性をチェックされるホストシステム上で、同じ動作を再現する必要があるためである。

ＵＣＡＦデータフィールドにおいて販売業者によって供給されるような、および、カード保有者に表示されるような金額は、好ましくは、符号化、たとえばＢＣＤ符号化され、右寄せされ、ゼロで埋められて６バイトにされる。

ＵＣＡＦデータフィールドにおいて販売業者によって供給されるような、および、カード保有者に英字コードを表示する通貨ルックアップにおいて使用されるような通貨は、好ましくは、符号化、たとえばＢＣＤ符号化され、右寄せされ、ゼロで埋められて２バイトにされる。

取引金額および通貨は、好ましくは、金額および通貨を使用するためのＩＡＦ設定（ビット８）にかかわらず、ＰＣＲ質問の予測不可能な数字部分の計算に常に使用される。そのフラグは、金額および通貨が暗号計算において追加的に、および明示的に使用されているかどうかを判断し、質問に関して、質問がカード保有者ＩＡから接続されていないパーソナルカードリーダへの通貨コード用転送メカニズムとして使用されるかどうかのみに影響を与える。

ＵＣＡＦデータフィールドにおいて販売業者によって供給されるような、および、カード保有者に表示されるような販売業者名は、販売業者から受取られた２２個のユニコードの２バイト文字から、２２個の１バイトのＡＳＣＩＩ文字に変換される。これは、２２個の２バイトのユニコードシーケンスの各々における各「奇数の」バイト−最初のバイトを取り去ることによって行なうことができる。

ＰＡＮは、最小数のバイトに符号化、たとえばＢＣＤ符号化されるべきであり、たとえば１９桁のマエストロ（Maestro）ＰＡＮといった、奇数のＰＡＮ数字が供給される場合、それは右寄せされてゼロで埋められるべきである。ＰＡＮを質問生成に含めることは、カード保有者ＩＡが、この取引のためにカード保有者によって使用されているＰＡＮ全体の知識を有することを必要とする。

たとえばＳＨＡ−１ハッシュアルゴリズムといった好適な暗号化アルゴリズムが、金額、通貨、名前およびＰＡＮから形成される３８バイトまたは４０バイトの連結入力データに適用される。結果として生じる２０バイトのハッシュデータ構造の最初の４バイトは「
抽出」され、３２ビットの符号なしの整数値として扱われる。１００，０００，０００の係数が次にこの値に適用されて、９９，９９９，９９９までの範囲の値を得る。通貨コードを送信しなければならない場合、それはここで付加される。最後に、ルーンチェック数字などのチェックビットが、これまで計算されて最後に付加された数字全体にわたって適用され、質問を作り出す。プロセスフロー全体を図１３に示す。

ＰＣＲ質問は、オプションのゼロを８桁まで埋込んだ数として渡される。ゼロ埋込はオプションである。なぜなら、ＰＣＲは、ＰＣＲ質問について一定の桁数に頼ってはおらず、むしろ、ＯＫ／入力ボタンを用いてＰＣＲ質問入力の終わりを示すためである。この数字に、オプションの通貨コードと計算されたチェック数字とが加えられ得る。

この転送フォーマットは、装置間の論理的な違いを最小限に抑え、理想的には通信プロトコル自体しか違わないようにするために、理想としては全種類の装置に使用されるべきである。これは、いずれかの種類の装置に質問データを渡す際の違いが、単に通信／転送メカニズムにあり、そのデータの処理にはないことを意味する。

質問はＡＡＶで渡されるため、発行者ホストにとって可能な最適化は、ＰＣＲ質問を最初に再計算する必要なく、最後に渡された質問をＰＣＲトークンの再計算に使用することである。この最適化の欠点は、発行者が質問の有効性をチェックしないことであり、それは後に、カード保有者の論争、および、ことによると払戻しにつながる場合がある。

説明された機構の実現化例は、アプリケーション暗号（ＡＣ）を、ＩＣＣおよびカード保有者を認証するためのメカニズムとして使用する。コマンドGenerateＡＣは、アプリケーション要求暗号（ＡＲＱＣ）、または、ＩＡＦのビット７が１に設定されている場合にはアプリケーション認証暗号（ＡＡＣ）を生成するよう、ＩＣＣに要求するために使用される。このコマンドにおいて供給され得るデータは、以下のとおりである。

・予測不可能な数字（ＵＮ）
・金額
・通貨。

予測不可能な数字（ＵＮ）は、GenerateＡＣコマンドにおいてＩＣＣに渡されるデータの４バイト／３２ビットの構成要素である。それは、アプリケーションとは対照的に、ＩＣＣにとって予測不可能な数字／データであり、実質上、カードに対する、取引に関連する質問である。ＰＣＲ質問は、ＵＮを作り上げるために使用される。最大８桁の質問は、ＵＮにとって必要とされる３２ビットの下位２７ビットを占める。残りの５ビットはしたがって、この機構のためにはゼロである。ＰＣＲ質問のＵＮ部分は、数値を渡すものとして考えられるべきである（図１４参照）。この数値が符号のない３２ビットの整数として扱われる場合、最上位セットビットを超えるビットはすべて、暗黙的に０に設定される。ＵＮがカードに送られると、カード保有者によって入力された１０進数の質問の未処理の「２進」値が、ＡＰＤＵコマンドにおいて渡される。それは、入力された質問数字のＢＣＤ符号化された同等物としては送られない。

金額および通貨の使用は、発行者の自由裁量による。金額および通貨を使用すべきであると発行者が示した場合、パーソナルカードリーダには金額および通貨データが供給される。通貨は、拡張されたＰＣＲ質問の一部として供給され、金額は明示的に／別個に、転送／入力される。金額および通貨を使用してはならないと発行者が示した場合、または、この選択を示さず、それらを使用しないデフォルトが追従された場合、金額および通貨についてのデフォルト値が使用可能である。

GenerateＡＣコマンドへの応答全体は発行者に送られるには大きすぎかもしれないため、ＰＣＲは、ＩＩＰＢを用いて、発行者が自分に通信されなければならないと判断したビット値の列をもたらすデータ抽出および圧縮プロセスを行なう。図１５を参照されたい。１のビット設定は、データ内の対応するビット位置が必要され、送られなければならないことを示すために使用可能である。０のビット設定は、発行者がビット設定を何にすべきかを知っているか、または他の方法で導出できるので、ビットを送る必要がないことを示すために使用可能である。ＩＩＰＢデータトークンは、好ましくは右から左へ構築され、抽出されるべき第１のビットが出力データの最後のバイトのビット１に置かれ、第２のビットがビット２に置かれる、などとなっている。ＩＩＰＢデータトークンは、転送すべきビットがもう残っていない状態になるまで、このように埋められる。

ＩＩＰＢデータトークンは、ＰＣＲからカード保有者ＩＡに転送されるデータである。接続される装置タイプはすべて、このデータをＭＣＤに直接転送し、一方、接続されていない装置は、カード保有者を用いて、このデータを手動で転送する。

接続されていない装置についてのＰＣＲトークンに関し、接続されていない装置は、転送されるべきデータのビットパターンを表わす数字を計算し、表示する。カード保有者は次に、この数字を、ＭＣＤ上で実行するカード保有者ＩＡで利用可能な適切な領域に入力しなければならない。接続されていないＰＣＲは、ＰＣＲからＭＣＤ上で実行するカード保有者ＩＡへデータを転送するためだけに生成される数値トークンを、ＩＩＰＢデータトークンから作り出す。ビットを表示された数字に変換するために使用されるアルゴリズムは相互運用可能であり、このためカード保有者ＩＡ上で可逆性であることが重要である。つまり、ビットからトークンに変換するために使用されるのと同じアルゴリズムが、トークンからビットに変換するために反転されなければならない。これを行なうための「圧縮された」方法は、ビットパターンを２進数として扱い、２進法から１０進法への数学的変換を行なうことである（図１６）。

ＰＣＲトークンは、スペース、ダッシュまたはコンマを分離記号として用いて提示されてもよく、１つ以上のチェック数字を含めてたとえば２０桁の最大可能表示長に制限される。

カード保有者ＩＡは、ＩＩＰＢデータトークンをＵＣＡＦに符号化する際に先頭ゼロ埋込を使用して残りのデータ空間を埋めるため、任意の特定サイズのトークンを期待していない。

エラー検出および訂正が提供可能である。ＰＣＲトークンは、トークン数字全体にわたって適用される、ルーンチェック数字などの１つ以上のチェック数字を使用可能である。カード保有者ＩＡはチェック数字を検証して、送信エラーがあれば報告する。キー入力ミスがある場合には、カード保有者ＩＡは、ＰＣＲトークンをカード保有者ＩＡに再入力しなければならないカード保有者に連絡する。

一方向に接続された装置については、ＰＣＲとＭＣＤ上のカード保有者ＩＡとの間の通信メカニズムは固有のものであってもよく、どのエラー検出メカニズムも同様に固有のものであってもよい。しかしながら、特にどんな種類のハンドシェイクプロトコルも行なえないかもしれない、一方向に接続された装置において、エラーが起こったことをカード保有者ＩＡが認識し、カード保有者に連絡することが可能でなければならない。送信エラーが稀に起こった場合には、カード保有者ＩＡはそのエラーをＰＣＲに連絡できないため、ＰＣＲに対する認証プロセスを初めから再度繰返すよう、つまり、カードを挿入／スイッチオンし、データおよびＰＡＮを入力し、次にＰＣＲに再送信させるよう、カード保有者に求めることは、許容可能である。また、これに代えて、ＰＣＲは再送信機能／ボタンを
採用してもよい。

他の接続された装置タイプについては、ＰＣＲとＭＣＤ上のカード保有者ＩＡとの間の通信メカニズムはここでも、任意のエラー検出メカニズムに沿って、固有のものであってもよい。

上述の完全なプロセスの要約を図１７に示す。

チップ−ＵＣＡＦの使用−カード保有者の観点
カード保有者はこの機構に加入しなければならない。チップ−ＵＣＡＦを使用するためには、カード保有者はまず、好適なＩＣＣを有する必要がある。カード保有者は次に、パーソナルカードリーダ（ＰＣＲ、接続された、または接続されていないもの）と、ＰＣなどのメインアクセス装置にインストールされた、必要なシンクライアントのカード保有者インターフェイスアプリケーション（ＩＡ）ソフトウェアとを有する必要がある。ＵＣＡＦの本質が、既に提供された支払カードの詳細のみについての支払認証機構であるため、カード保有者インターフェイスアプリケーション（ＩＡ）は、それがＰＡＮについて既に知っている支払カードについての認証要求のみに応答する。したがって、カード保有者は、支払に使用しようとする任意の支払カードの詳細を、それらのカードがＵＣＡＦ認証で使用可能となる前に、カード保有者ＩＡに事前登録する。ＵＣＡＦが使用可能な販売業者に許可を要求すると、販売業者はＵＣＡＦデータをカード保有者に提示する。ＵＣＡＦクライアントが利用可能である場合、それはカード保有者とやり取りする。カード保有者は、第１および第２のコード？？、つまりＰＡＮおよびＩＩＰＤを「知っている」必要がある。カード保有者は、自分のＰＩＮの詳細を秘密にしたままにする責任を負わなければならず、そのため、カード保有者の許可なくカードを使用しようとする試みがなされた場合には、ＰＣＲが正しいＰＩＮなしでトークンを生成することはできない。カード保有者は、ｅコマースベースの購入に使用される可能性のある各ＰＣに、ローカルなチップ−ＵＣＡＦクライアントをインストールする必要がある。カード保有者は、ＵＣＡＦ支払認証に使用される各支払カードのＰＡＮ詳細を、そのカードを支払および関連する認証に使用しようとする前に、カード保有者インターフェイスアプリケーションに登録しなければならない。

販売業者の観点から
主な販売業者プロセスフローを図１８に示す。販売業者にとって懸念される２つの主な局面は、第１に、販売業者のウェブページへの変更、第２に、ＵＣＡＦをサポートするために必要な処理である。販売業者のサーバがチップ−ＵＣＡＦをサポートするためには、販売業者のサーバは、そのウェブサイトを介して追加データを提示し、カード保有者インターフェイスアプリケーションを介して挿入された追加データを処理しなければならない。販売業者によって必要とされる努力に照らしてＵＣＡＦ機構を説明するために、顧客がカード保有者として販売業者と保つことのできる２種類の関係が考慮される。つまり、プロファイルされた関係と、プロファイルされていない関係とである。高速精算およびシングルクリックは、カード保有者がプロファイルされていることを必要とし、一方、標準精算は、プロファイルされたカード保有者およびプロファイルされていないカード保有者によって同様に使用可能である。シングルクリックは一般に、顧客がシングルクリックオプションを既に許可していることを必要とする。なぜなら、多くの顧客はこの衝動買いする機能を厄介に感じているためである。ＵＣＡＦを使用するためには、販売業者のサーバは、ＵＣＡＦ隠しデータフィールドを含むＵＣＡＦ認証ページを提示する前に、たとえばＰＡＮ、満了期限およびＣＶＣ２といった、あるカード保有者の支払詳細の知識を持っていなければならない。なぜなら、フィールドのうちの１つは、取引に使用されているＰＡＮの最後５桁を含まなければならないためである。

高速精算（図１９）のためにＵＣＡＦの使用をサポートするには、注文／支払詳細確認ページはＵＣＡＦ隠しフィールドをサポートしなければならず、ＵＣＡＦ機能性の点で、ＵＣＡＦ認証ページとなる。これは、カード保有者インターフェイスアプリケーション（カード保有者ＩＡ）がそれ自体を提示し、カード保有者との必要なやり取りを要求して、ＵＣＡＦ認証データを得る機会を提供する。カード保有者ＩＡは次に、カード保有者による注文提出の前に、ＵＣＡＦ認証フィールドを投入できる。

シングルクリック購入プロセス（図２０）中にＵＣＡＦの使用をサポートするには、販売業者のサーバは、ＵＣＡＦ転送ページをサポート可能である。ＵＣＡＦ転送ページは、カード保有者による使用については意図されておらず、その表示は、認証プロセスが進行中であることを示すべきである。このページは、ＵＣＡＦ認証ページとして作用し、隠しＵＣＡＦフィールドを提示する。ＵＣＡＦ転送ページはＵＣＡＦ隠しフィールドもサポートしなければならず、カード保有者インターフェイスアプリケーションがそれ自体を提示し、カード保有者との必要なやり取りを要求して、ＵＣＡＦ認証データを得る機会を提供する。シングルクリックを提供する販売業者の中には、ある時間枠内に行なわれた一連のシングルクリック購入を１つの注文に自動的に組合せる機能も提供している。つまり、「これと−クリック−これと−クリック−あっ、それからこれも買おう−クリック」といったことである。多数の近接するシングルクリック購入が組合される場合、許可は一般に、注文が「終了」して組合された価格がわかった後でのみ求められる。これは、許可に使用される金額に対して、認証に使用される金額を、シングルクリックプロセスへの混乱とともにいかに解決するかという問題を残す。販売業者は以下のことを認証するよう決心するかも知れない。

・組合わされたシングルクリックショッピング動作の最初の購入のみ認証−特殊な構成によって、取得者はこの場合、許可を、それが通貨が変換された許可のためとして扱う必要がある。これは、認証の検証が起こり得るように、最初の金額−認証プロセスに使用される金額を入れることを意味する。

各購入を累積的に認証−各シングルクリックは、カード保有者への認証要求（ＵＣＡＦ転送ページ）を伴い、毎回、金額は現在の累積総額に沿って増加する。最後のＵＣＡＦ認証のみが、次に発行者に送られる。

ＵＣＡＦを使用するカード保有者が、認証プロセスを引起こしてＵＣＡＦデータを供給できるようになるためにシングルクリック精算を起動させる場合、ＵＣＡＦ転送ページが必要とされる。このため、販売業者は、シングルクリックオプションがカード保有者によって選択される前に、ＵＣＡＦが使用されているかどうかを知らなくてはならない。追加の隠しフィールドである、ＵＣＡＦ使用可能フィールドは、シングルクリック精算オプションを提供するページごとにサポートされなければならない。

カード保有者インターフェイスアプリケーションはこのフィールドを認識し、「０１」といったある値をフィールドに自動的に記入して、ＵＣＡＦに準拠するカード保有者ＩＡが支払を容易にすることを示す。

カード保有者によって使用される特定のカードについてＵＣＡＦ認証を行なうことができるＵＣＡＦ準拠のカード保有者ＩＡなしで、シングルクリック精算が起動される場合、ＵＣＡＦ転送ページは表示されなくてもよい。

シングルクリックの概念に対する影響を最小限に抑え、販売業者がデータを収集できるようにするＵＣＡＦ転送ページでのフォーム記入プロセスを完了するために、カード保有者ＩＡは、隠しボタンでクリックイベントを起動する。販売業者はＵＣＡＦ転送ページ上
に、隠しボタンである「ＵＣＡＦ提出」ボタンを設ける。このボタンは、カード保有者ＩＡが、フォーム記入が完了した場合にクリックイベントを起動するようにする。クリックイベントが起こると、「ページ」は、許可要求において送られるべきデータを、販売業者のウェブサーバに送信する。

ＩＡはページが転送ページであるかないかを判断できないため、ＵＣＡＦ提出ボタンがページ上で、必要なＵＣＡＦデータ入力フィールドおよび認証フィールドに付随する場合はいつでも、ＩＡは、認証トークン生成プロセスの完了とともにそれを常に実施する。販売業者は、この機能を所望するように自由に使える。つまり、販売業者は、そうしたければ、従来のＵＣＡＦ認証ページ上の「自動提出」を利用してもよい。

ＵＣＡＦ認証データフィールドに特定のエラー表示内容を設定することをもたらすエラーをＩＡが検出した場合、または、カード保有者がキャンセルしてＵＣＡＦ提出ボタンが存在する場合には、ＩＡは依然としてクリックイベントを実施し、フォームデータを販売業者に提出する。「良好な」認証データのみを送りたい販売業者はしたがって、エラー表示を認識し、適切なエラーページをカード保有者に戻すことを考慮すべきである。

標準精算（図２１）のためにＵＣＡＦの使用をサポートするには、注文／支払詳細確認ページはＵＣＡＦ隠しフィールドをサポートし、ＵＣＡＦ認証ページとならなければならない。これは、カード保有者インターフェイスアプリケーション（カード保有者ＩＡ）がそれ自体を提示し、カード保有者との必要なやり取りを要求して、ＵＣＡＦ認証データを得る機会を提供する。カード保有者ＩＡは次に、カード保有者による注文提出の前に、ＵＣＡＦ認証フィールドを投入できる。

ＵＣＡＦを使用するには、販売業者は、ＵＣＡＦ隠しデータフィールドを有するＵＣＡＦ認証ページを提示する前に、カード保有者の支払詳細、ＰＡＮ、満了期限およびＣＶＣ２の知識を持っていなければならない。なぜなら、フィールドのうちの１つは、取引に使用されているＰＡＮの最後５桁を含まなければならないためである。したがって、ＵＣＡＦを使用する場合、組合わされた注文詳細確認／支払詳細要求ページは、図示されているように２つのページに分割されなければならない。

ＵＣＡＦ認証ページまたは転送ページは、販売業者が注文および支払詳細情報を確認するためにカード保有者に提示するウェブページである。ＵＣＡＦが使用可能な販売業者にとって、これらのページは、認証を試みる前にＵＣＡＦデータを提示し、獲得する機能である。このため、ＵＣＡＦ認証ページおよびＵＣＡＦ転送ページは、販売業者、カード保有者および発行者の間での主要な一体化点である。

ＵＣＡＦ認証ページは、公的なインターネットを介して送信される、カード保有者および取引に特有のデータを含む。したがって、ＵＣＡＦ認証ページは、好ましくは、このデータの漏洩を防止するために十分に安全な暗号化方法（たとえば１２８ビットＳＳＬまたは同等物）を用いて保護されるべきである。

ＰＣブラウザベースのチャネルにおけるカード保有者ＩＡとの販売業者サーバのやり取りはすべて、ＨＴＭＬフォームの隠しフィールドを介する。全販売業者および全ＵＣＡＦアプリケーションとの相互運用性を確実にするために、これらの隠しフィールドの実現化例は、ネーミング規定、サイズおよび許容内容を含め、すでに標準化されている。

・販売業者から供給される入来データフィールドは、販売業者ウェブサーバによってカード保有者のブラウザに送られるＨＴＭＬページソースに現われる。これらのフィールドについての値はページソース内で直接設定され、文字列フォーマットで表現される。

・カード保有者によって戻される発信データフィールドは、販売業者ウェブサーバによってカード保有者のブラウザに送られるＨＴＭＬページソースに現われる。これらのフィールドについての値は、ページソース内で最初にブランク値に設定される。

カード保有者ＩＡは、ブラウザの文書オブジェクトモデル（ＤＯＭ）とやり取りすることにより、値を文字列としてプログラム設定する。

入来する販売業者供給データについては、販売業者サーバは、それが供給しなければならないデータ値を、以下の隠しフォームフィールドにおいて提示する。

・Ucaf_Merchant_Name−販売業者の名前は、４文字が２２グループある８８個の１６進法の文字（０−９、Ａ−Ｆ）からなり、各グループはユニコード文字を表わす。ＵＣＡＦフィールドにおいて販売業者によって供給される名前は、カード保有者インターフェイスアプリケーション（カード保有者ＩＡ）によってカード保有者に表示される名前である。それは、質問の生成に使用される名前でもある。

・Ucaf_City−最大１３文字の、販売業者が自分の取得銀行に登録されている市である。

・Ucaf_State_Country−米国の州コードを伝える最大３文字、または、３文字のＩＳＯ３１６６英字国コードである。

・Ucaf_Currency_Code−取引通貨用の３桁のＩＳＯ４２１７通貨コードである。

・Ucaf_Sale_Amount−最大１２桁で、通貨コードにより反映される基本通貨単位で表現される取引金額である。

・Ucaf_ＭＴＳ−２バイトの販売業者リファレンスの１６進法表示を含むオプションのフィールドである。

・Ucaf_Brand−カード保有者によってこの取引のために選択された支払カード詳細のブランドを表わす２桁のコードである。

・Ucaf_Payment_Card_Number−カード保有者によってこの取引のために選択された支払カード詳細の最後の５桁である。これは、使用中のカードが、カード保有者ＩＡが熟知しているカードで、したがってＵＣＡＦ口座保有者認証値を生成するためにその代わりを果たすことができるかどうかを、カード保有者ＩＡが判断するために使用される。

発信カード保有者戻りデータに関し、販売業者は、認証情報を収集するために以下の隠しフィールドを提示する。

Ucaf_Authentication_Data−販売業者によってブランク、つまり’＝’’’’’に設定され、カード保有者ＩＡによってＵＣＡＦ認証データを投入される。このデータは、ＨＴＭＬフォームデータにとって通常の方法で、販売業者に戻される。それは、フォームフィールドのすべてが、ＨＴＴＰ ＰＯＳＴ要求で、販売業者のウェブサーバにテキストフォーマットで「通知（POST）」し返されることを意味する。入来フィールドおよび発信フィールドの双方は、販売業者のウェブサーバが戻りデータとして関心のあるデータと元々送られたデータであるため関心がないデータとを区別するプロセスで、通知し返される。つまり、入来フィールドの読出専用の局面は、ブラウザによって送られたデータを販売業者が使用せずに処理することによって、効果的に強化される。

シングルクリックをサポートする追加のＵＣＡＦフィールドに関し、シングルクリック支払中に販売業者がＵＣＡＦをサポートし、ＵＣＡＦ転送ページを提示することができるようにするには、以下の隠しフォーム要素が、シングルクリック支払オプションを選択可能などのページにも提示されていなければならない。

・Ucaf_Payment_Card_Number−カード保有者によってこの取引のために選択された支払カード詳細の最後の５桁である。これは、使用中のカードが、カード保有者ＩＡが熟知しているカードで、したがってＵＣＡＦ口座保有者認証値を生成するためにその代わりを果たすことができるかどうかを、カード保有者ＩＡが判断するために使用される。

・Ucaf_Enabled−販売業者によって０、つまり’＝’’００’’’に、またはブランク、つまり’＝’’’’’に設定され、もしあればカード保有者ＩＡによって“０１”に設定され、支払カード番号は、カード保有者ＩＡに知られた支払カードに整合する。

カード保有者は、シングルクリック支払方法を、それが簡単で必要なやり取りがないために、使用するよう選択するかもしれない。ＵＣＡＦの追加の認証要件を使用する際にカード保有者にとってこの円滑なフローを維持するために、フォーム提出ボタンが利用可能とされる。ＵＣＡＦ認証データの取得および投入が完了次第、カード保有者ＩＡはクリックイベントを起動して、ＵＣＡＦ転送ページを販売業者に自動的に提出する。

このクリックイベントを適正に実現するために、ＵＣＡＦ転送ページは、以下の追加の隠しフォーム要素を必要とする。

・Ucaf_AAV_Submit−カード保有者ＩＡがクリックイベントをオンに起動するための隠し仮想ボタンである。

販売業者サーバは、関連データを獲得し、それを記憶することができる。販売業者サーバは、カード保有者インターフェイスアプリケーションによって供給されるＵＣＡＦ認証データフィールドを獲得し、保持することができる。認証データフィールドは、販売業者に、カード保有者を取引にリンクさせるデータを提供する。このデータは、分割出荷用の次の許可の提出にとって必要とされ、例外処理中に販売業者にとって価値のあるものになるかもしれない。

販売業者は、すべてのチップ−ＵＣＡＦｅコマース取引について許可を要求することが要求される。販売業者は、すべての許可の試みについて、ＵＣＡＦを供給しなければならない。次の許可の試みも、ＡＡＶを含まなければならない。しかしながら、販売業者は、
次の許可のために制御バイトを調整する必要がある。発行者は、３０暦日などのある時点よりも古いＡＡＶを有する初期許可要求を拒否してもよい。

許可がリアルタイムで送られなくてもよいのと同様に、ＵＣＡＦ認証データは発行者に「リアルタイム」で送られなくてもよい。ＵＣＡＦ認証データを含む許可要求はしたがって、販売業者の取得者に送られるデータを一括する点で、通常の許可要求と異なるように扱われなくてもよい。事前許可も可能であり、初めの許可のためのものとして扱われる。

継続的に発生する支払取引は、初めの許可のみについてＡＡＶデータを含むべきである。継続的に発生する支払のための初めの許可は、チップ−ＵＣＡＦ処理にふさわしいかもしれない。販売業者は、継続的に発生する取引のための継続的に発生する支払において、ＵＣＡＦデータを提供しなくてもよい。

販売業者は、分割出荷の各部分について許可を得ることを要求される。販売業者は、ＵＣＡＦに、初めの、および次の許可要求の各々を供給しなければならない。次の許可において制御バイトを修正し損ねると、発行者が許可の時点で拒否するようになるかもしれない。

販売業者は、許可要求を繰返す必要があるかもしれない。たとえば、販売業者は、あるタイムアウト期間内に元の許可要求への応答を受取らなかったか、または、取得者へのデータ送信の際にエラーの他の表示を受取る。そのような状況では、ＵＣＡＦ認証データは、初めの許可のためのものとして扱われるべきである。既存のプロトコルは、許可要求が繰返し提出か再提出かを取得者に示す。

ある状況では、販売業者は、元の取引と同じＡＡＶ値を有する所与のチップ−ＵＣＡＦ取引のために、第２の許可要求を生成してもよい。

以下のアドレスにおいて、ビット的には元の要求と同一ではない許可要求がアドレス指定される。たとえば、許可要求は異なるシステム由来ＩＤ番号を有していてもよい。販売業者は、以下の場合に、第２の許可要求を生成してもよい。

・初めの拒否の後で許可要求を再送信したい場合
・元の許可を完全に破棄したものの、後になってそれを再任命しようと決めた場合。

販売業者は、制御バイトの値を修正することによって、そのような許可を次の許可として扱うべきである。これは、それらが潜在的な再実行攻撃として間違ってＡＡＶ検証機能で拒否されることを防止する。

販売業者はＵＣＡＦデータの内容に関与すべきではない。なぜなら、これは、以下の２つの状況を除き、発行者のために意図されたものであるからである。

・次の許可を作る際の制御バイトの修正
・あるＵＣＡＦ内容を介して販売業者に通知された、インターフェイスアプリケーションによって検出されたエラーについてのチェック。

たとえば分割出荷のために次の許可を処理する場合、販売業者は、初めの許可に含まれるＵＣＡＦの制御バイトを、カード保有者インターフェイスアプリケーションによって設定された値から、先頭ビットを消去することによって、修正しなければならない。これは、初めの許可に引き続いて起こる許可の一部としてＵＣＡＦ認証が供給されることを反映する。

制御バイトは、ＵＣＡＦデータを６４進法で復号して２４バイトの値を取得し、第１のバイトの値を変更し、次に再び６４進法で符号化して、更新されたＵＣＡＦを作り出すことによって、修正可能である。または単に、第１の文字のＡＳＣＩＩ文字値から定数３８を減算することにより、第１の６４進法で符号化された文字を変更して、第１の文字について新しい値を生成する。

カード保有者ＩＡが、データフォーマット／検証問題、または欠落した必要なUcaf_隠しフィールドを介して、販売業者によって供給されたデータにエラーを発見した場合、もしくはそれ独自の内部の問題を有する場合には、カード保有者ＩＡは販売業者に連絡しようとする。ＵＣＡＦは認証メカニズムであり、支払メカニズムではないため、販売業者は、ＵＣＡＦデータが供給されない状態で、またはエラーが表示された状態で認証プロセスを続行するかどうかについて、自由に自分自身の判断を下す。

カード保有者が認証プロセスをキャンセルした場合、Ucaf_Authentication_Dataと呼ばれるUcaf_隠しフィールドは空の値に設定され、このため、ＵＣＡＦクライアントを持たない場合と違わないように見える。

販売業者サーバは、自分のＵＣＡＦ認証ページまたはＵＣＡＦ転送ページに提出された記録におけるＵＣＡＦデータの存在を検出する機能を有する。ＵＣＡＦ認証データが存在する場合、販売業者は、初めの許可を送信するために、それを変更せずに取得者に提出しなければならない。販売業者は、次の許可についての制御バイトの値を修正するだけである。販売業者はまた、ＵＣＡＦが利用可能であるとして取引にフラグを立て、そのため、取得者は、適切な値をセキュリティレベルインジケータに投入することができる。

ＵＣＡＦ認証データが供給されていない場合、販売業者はこれを自分の取得者に示さなければならない。そのため、彼らは、適切な値をセキュリティレベルインジケータに投入することができる。

販売業者と取得者との間のリンクにおいて、データ内容の一部は、ＭＡＣ適用の使用を介して、途上での修正に対して保護されることが可能であり、そのような場合、ＵＣＡＦデータもＭＡＣへの入力として含まれ得る。

カード保有者インターフェイスアプリケーションの機能要件
パーソナルカードリーダのインターフェイスアプリケーション（カード保有者ＩＡ）は、販売業者、カード保有者、および、カード保有者を介してのパーソナルカードリーダ（ＰＣＲ）間のインターフェイスとして作用するソフトウェアの構成要素である。標準のカード保有者ＩＡは支払手段決定プロセスでは何の役割も果たさないが、ベンダーは、適切な支払カードの選択におけるカード保有者へのサポートを実際に含み得る、より優れた機能性のためのサポートを自由に追加できる。カード保有者ＩＡは、一旦起動されると、以下の動作を行なわなければならない。

・チャネルからデータを検索する
・取引に使用されているＰＡＮが、それに知られているＰＡＮかどうかを判断する
・販売業者取引データを確認する
・取引詳細をカード保有者に表示する
・選択されたＰＡＮ、およびそのカードがＩＡに知られている任意の名前がはっきりと表示され、認証を行なうのに使用する必要がある物理的なＩＣＣをカード保有者に思い出させる
・ＰＣＲ質問を計算し、表示する
・カード保有者が、パーソナルカードリーダ上に自分のＰＩＮを入力することを含む、行なう必要のある動作について認識するように、命令が表示されるかまたは利用可能であることを確実にする
・カード保有者の承認の表示として、トークンがカード保有者によって入力されるのを待つ
・ＡＡＶをＵＣＡＦに投入し、結果として生じるＵＣＡＦデータを６４進法で符号化する
・必要なＵＣＡＦデータフィールドをチャネルに投入する
・カード保有者にデータを販売業者に提出するよう指示する。または、ＰＣブラウザチャネルにおいてシングルクリック購入を処理する場合には、提出ボタンのクリックイベントを「始動する」
・最後に、任意のオプションのロギングを実行する。

カード保有者ＩＡは、販売業者の注文プロセスにおいて適切な時点に達すると自動的に起動されるべきである。カード保有者ＩＡは、カード保有者ＩＡによりサポートされ適切なチャネル仕様において規定された配送チャネルを介して、販売業者からデータを受取ることができる。カード保有者ＩＡは販売業者の入力データを確認し、有効な取引データのみを進める。カード保有者ＩＡはまた、取引に使用される支払カードに関する、カード保有者からのある入力データを得る。カード保有者ＩＡは取引についてのカード保有者への情報を表示し、それは、正しい金額フォーマッティングを有する、たとえばＥＵＲ、ＵＳＤなどの通貨文字を含む表示での取引金額を含まなければならない。ＰＣＲ質問は、これがＰＣＲに入力されなければならないというはっきりとした指示とともに、カード保有者に表示される。それはまた、カード保有者が自分のＰＩＮをＰＣＲに入力する必要があること、および、結果として生じるＰＣＲトークンがカード保有者ＩＡに入力されるべきであることも、はっきりと示す。

カード保有者ＩＡはＰＣＲ質問を生成するかまたはＰＣＲ質問が生成されるようにし、ＰＣＲトークンを受取ると、ＩＡはＡＡＶを投入し、ＵＣＡＦを６４進法で符号化する。

カード保有者ＩＡは、カード保有者ＩＡによりサポートされ適切なチャネル仕様において規定された配送チャネルを介して、ＵＣＡＦデータを販売業者のサーバに送ることができる。

カード保有者ＩＡはまた、支払詳細、ＰＡＮ、満了期限、およびアドレスなどの追加顧客詳細のためのフィールド自由記入機能といった、追加の「使いやすさ」機能も提供してもよい。カード保有者がカード保有者ＩＡに２つ以上の支払カードを登録することは十分に可能であり、そのため、カード保有者ＩＡはその場合、ある特定の支払についてどのカードを使用していたかについての任意のフォーム記入における選択を、カード保有者に提供する必要がある。これらの要件についての詳細は、この文書の範囲外である。ＩＡはＥＣＭＬ（ｅコマースモデリング言語）フォーム記入をサポートし、フィールド名自動記入を「最良に推量する」かもしれない。

販売業者は、カード保有者のＰＣにインストールされているかもしれないＵＣＡＦカード保有者ＩＡとの何らかのやり取りを探している任意のページのUcaf_Payment_Card_Numberフィールドにおける支払カード番号の最後５桁を供給しなければならない。カード保有者ＩＡは、販売業者によって供給された最後５桁が、そのカード保有者ＩＡに登録されたカードのうちの１つの最後５桁に整合するという事前の知識を既に有しているカードのみを認証するよう起動しなければならない。

実行可能となると、カード保有者ＩＡは、任意の所与のウェブページ上のフォーム内の
フィールドのフィールド名を判断できるのと同様にページがロードされ、ブラウザに表示するような方法で、インターネットブラウザプロセスに一体化し、または他のやり方でそれ自体をインターネットブラウザプロセスに付加する。

規定されたＵＣＡＦフォームフィールドのいずれかが認識されると、アプリケーションは次に、認証プロセスを続行するために、ＵＣＡＦ処理を開始し、それらのフィールドから必要なデータを抽出しなければならない。

カード保有者ＩＡ起動フローを図２２に示す。

パーソナルカードリーダ（ＰＣＲ）は、チップ−ＵＣＡＦ機構の一構成要素である。図２３は、ＰＣＲ処理フローの概念図を示す。

１．カード保有者がＩＣＣ５を接続された装置、または接続されていない装置に挿入すると、処理が始まる。以下では、接続されていない装置が仮定される。

２．ＰＣＲは、ＩＣＣ５およびカード上の関連プログラムを探し、アプリケーションラベルを短時間表示することによってカードをカード保有者に確認する。

３．パーソナルカードリーダは、発行者インターネット固有ビットマップ（ＩＩＰＢ）をＩＣＣ５から読出す。ＩＩＰＢの長さが間違っている場合、またはＩＩＰＢによって示される、転送されるべきビット数がその特定のパーソナルカードリーダには多過ぎる場合、パーソナルカードリーダは、「致命的エラー」というメッセージを表示する。

４．パーソナルカードリーダは、カード保有者に質問を入力するよう促す。質問は、予測不可能な数字（ＵＮ）、取引通貨コード（オプション）および後続するチェック数字のために使用されるデータを含む。

５．カード保有者は、自分のメインアクセス装置上にプロンプトで表示された１２桁の数字を入力し、ＰＣＲがエラーについてチェックする。パーソナルカードリーダは、チェック数字が正しいことを判断し、質問が有効か無効かをカード保有者に連絡する。無効である場合、ＰＣＲは再度質問を要求する。

６．パーソナルカードリーダは、カード保有者に取引金額を入力するよう促す。認証取引が取引金額を利用しなかった場合、このステップは完全に飛ばされる。質問は取引通貨コードを含んでいたため、表示は、表示ラインの終わりに、カード保有者への通貨の視覚的な確認として３文字の通貨シンボルを取入れる。

７．カード保有者は、自分のメインアクセス装置上にプロンプトで表示された金額を入力する。

８．カード保有者はここで自分のＰＩＮを入力しなければならず、そのためパーソナルカードリーダは、カード保有者にＰＩＮを入力するようプロンプトを表示する。

９．カード保有者は自分のＰＩＮ数字を入力し、「入力」を押す。

１０．パーソナルカードリーダはＰＩＮをＩＣＣに提出する。ＩＣＣが無効のＰＩＮ入力を報告し返してきた場合、パーソナルカードリーダは、それが有効なＰＩＮを報告する場合であれば残っている試みの数を、カード保有者に連絡する。

１１．装置は、すべてカード保有者によって入力されたような予測不可能な数字、金額および通貨コードとして取引データを使用して、GenerateＡＣコマンドを準備する。コマンドはＩＣＣに送られる。認証取引が取引金額を利用しなかった場合、金額（０）および通貨コード（９９９）についての、デフォルトだが有効な値が使用される。

１２．ＩＣＣは返答し、ＰＣＲは、カードから読出されたＩＩＰＢを使用して、解体されてトークンに圧縮されるべきGenerateＡＣへの返答からのビットを判断する。ＩＣＣにＩＩＰＢが見つからない場合、リーダに記憶されたデフォルトのＩＩＰＢ値が使用される。ＩＩＰＢの長さが間違っている場合、パーソナルカードリーダは「致命的エラー」というメッセージを表示する。

１３．装置は次に、ｎ桁（+１つのチェック数字）の数値トークンを計算し、表示する。カード保有者はトークンを読出し、自分のメイン装置のアプリケーションに入力する。メインアクセス装置上のアプリケーションは、チェック数字を検証し、トークンがエラーを含むかどうかをカード保有者に連絡し、トークンが再入力されるよう要求する。カード保有者がトークンを正しくキー入力した場合、オンライン取引プロセスは続行する。

上述の機構は、あるデータ構造を必要とする。発行者インターネット固有データ（ＩＩＰＤ）は、以下の構造を有する２値データを含む、オプションの０バイト〜３２バイトの汎用構造である。

・バイト１−ＩＡＦ
・バイト２〜３１−追加の発行者に特有の内容。

ＩＩＰＤの最初のバイトは、インターネット認証フラグ（ＩＡＦ）バイトである。各ビットは、ＰＣＲが取らなければならない／使用しなければならない、動作または発行者からのオプションと通信する。フラグ設定は、金額および通貨がＡＣ生成において明示的に使用されなければならないかどうか、および、ＡＡＣまたはＡＲＱＣがＩＣＣから要求されるべきかどうかを示す。ＩＣＣ５にＩＩＰＤがない場合には、０×４０のデフォルトバイト値がＩＡＦのために使用される。

ＩＡＦの後に続くどのデータも、発行者によって固有に使用されるためのものである。インターネット発行者固有データ（ＩＩＰＤ）は、認証トークンの検証を支援するために、発行者の認証検証システムに転送されるべき固有データ、一般にカード特有の静的データを、発行者が特定できるようにする。それは、インターネット認証環境のために発行者固有データを保持する汎用オブジェクトとしての役割を果たす。ＩＩＰＤ内で伝えられるべきデータは、基本的に、アプリケーション暗号を検証する発行者ホストシステムにより必要とされる任意のカード静的データであるが、どういうわけか、カードデータベースから得ることは不可能または複雑である。例は、キー導出インデックスおよび／または暗号バージョン番号を含み得る。

カードは、１桁のカード連続番号（ＣＳＮ）を使用してもよい。ＵＣＡＦ仕様はこのフィールドについて何も提供しないので、ＣＳＮを転送するためにＩＩＰＤが使用可能である。それは、それを表わすのに４ビットを必要とするＩＩＰＤをそれに置くことによって、発行者に運ばれる。ＣＳＮの位置付けおよびフォーマットは、発行者に依存する。

カード保有者は、もしあればＩＩＰＤを、カード保有者ＩＡに直接供給しなければならない。これは、カード保有者が必要に応じてこのデータをカード保有者ＩＡに供給するように、発行者が任意のカードの特定のＩＩＰＤをカード保有者に通信しなければならないことを意味する。相互運用性の理由により、データをより正確な１６進法の形で供給する
よりもむしろ、発行者は、可変整数のバイトであるＩＩＰＤを１０進法の３ビットバイトの形で供給する必要がある。つまり、各バイトの値は、次のバイトの値からダッシュまたはスペースで分けられた１０進法の値として入力される。ＩＩＰＤが３ビットバイトとして提示されることを確実にするために、先頭ゼロ埋込が使用される。この要件は、ダッシュまたはスペースキーを持たないＭＣＤが各３ビットバイトを認識できるように、必要である。

ＰＣＲはＩＩＰＤの最初のバイトのみをインターネット認証フラグ（ＩＡＦ）バイトとして使用するが、ＩＩＰＤ全体は依然としてＩＣＣに個人化されるべきである。これは、ＩＣＣからデータを抽出可能な接続されたリーダが、ＩＩＰＤを検出でき、このためカード保有者がＩＩＰＤを手動で入力することを必要としないためである。

さらに別のデータ構造は、発行者インターネット固有ビットマップである。発行者インターネット固有ビットマップ（ＩＩＰＢ）は、２値データを含む、オプションの１１バイト〜４３バイトの構造である。ビットマップは、データアイテムＣＩＤ、ＡＴＣ、ＡＣおよびＩＡＤの連結値に対するマスクである。それは必ずしも、応答データに対する直接のマスクでなくてもよい。なぜなら、第１のタグなしおよび第２のタグ付きのGenerateＡＣ応答の双方は、ＰＣＲによって取扱可能であるためである。第２の応答データは、タグおよび長さ、ならびにＣＩＤ、ＡＴＣ、ＡＣおよびＩＡＤの値を含む。ＩＣＣ５がＩＩＰＢを持たない場合には、１９バイト構造のデフォルトバイト値が使用される。ＩＩＰＢを使用して、ＩＩＰＢデータトークンに転送されるべきビットを判断した後で、接続されていないＰＣＲは、カード保有者への表示用にＰＣＲトークンを構築しなければならない。

ＵＣＡＦ内のＡＡＶデータ空間を介してのみならず、より重要には、接続されていないパーソナルカードリーダ（ＰＣＲ）から利用可能なデータ転送が制限されているので、認証暗号を検証するために発行者に情報のどのビットを渡すかを規定するのは、ＩＩＰＢである。ＩＩＰＢはしたがって、発行者の検証データ要件の規定である。ＩＩＰＢは、以下のものから要求される、それらのビットのマスクである。

・暗号情報データ（ＣＩＤ）
・アプリケーション取引カウンタ（ＡＴＣ）
・アプリケーション暗号（ＡＣ）
・発行者アプリケーションデータ（ＩＡＤ）。

ＣＩＤから要求される唯一の情報は、カードによって生成されたＡＣがＡＲＱＣまたはＡＡＣのいずれであったかということである。カードはＡＲＱＣまたはＡＡＣのいずれかを生成するので、双方の暗号インジケータビットを送る必要はなく、２つのインジケータビットの一番上だけが必要とされる。ＣＩＤの残りは以下に示すように設定され、そのため送られない。

ＡＴＣは、各取引の後でインクリメントする１６ビットのカウンタである。ＡＴＣの値は暗号に含まれ、暗号に一意性を提供する。ＡＴＣのインクリメントする性質のため、送信されるＡＴＣのビット数を十分実質的に削減することが可能である。

この機構のためにＩＩＣによって計算されるよう要求される暗号（ＡＣ）は、アプリケーション要求暗号（ＡＲＱＣ）であるが、カード実現化例の中には、その代わりにアプリケーション認証暗号（ＡＡＣ）を生成することを選ぶ、またはその発行者によって要求されるものもあるかもしれない。双方の場合において、ＡＣは、ＩＣＣに渡されるかまたは他の態様で知られるデータについて計算される、８バイトのメッセージ認証コード（ＭＡＣ）である。８バイトのＡＣのうち２バイトのみがＰＣＲトークンに転送され、発行者ホ
スト処理は、受取られたＡＣを再構築によって生成されたＡＣと比較する際に、このことを考慮に入れなければならない。どの２バイトが選択されるかはもちろん、ＩＩＰＢによって判断される。デフォルトＩＩＰＢは、最初の２バイトをとるよう設定されている。

発行者アプリケーションデータ（ＩＡＤ）は、カードに記憶された静的データであって発行者がＰＡＮおよび満了期限に基づきＩＣＣデータベースから検索でき、そのため転送される必要のない、キー導出インデックスおよび暗号バージョン番号を含む、発行者が知っている値、仮定された静的値、および取引特有の値の組合せを有するフィールドを含む。同様に含まれているのは、定数である動的認証暗号（ＤＡＣ）であり、これは転送されなくてもよい。同様に含まれているのはカード検証結果（ＣＶＲ）であり、それは４バイトのフィールドで、そのバイト１はＣＶＲの長さであり、一定の知られた定数である。バイト２、３および４は、仮定および要求された、取引またはカードに特有のビット値の混合を含む。これらのビットは、オフラインＰＩＮ検証が成功したかどうか、ＰＩＮ再試行番号が超えたかどうか、前の取引が失敗したかどうかについての価値のある情報を提供する。

図２４は標準的な取引に関するステップを示し、以下に説明する。

１．カードの起動；取引をする際、カードをカードリーダに挿入しなければならない。

２．アプリケーションの選択：アプリケーション選択プロセスは、端末がＩＣＣのデータを用いて、認証暗号を生成するのに使用されるＩＣＣアプリケーションを判断するプロセスである。このプロセスは２つのステップからなる。

・端末によってサポートされるＩＣＣアプリケーションのリストを作り出す。

上述の生成されたリストから実行すべきアプリケーションを選択する。

３．アプリケーション処理を開始する：端末は取引処理を開始する。

４．アプリケーションデータを読出す：端末は、ＡＦＬによって示されるデータを読出す。

５．オフラインカード認証：重要なＩＣＣ常駐データの正当性を確認するため、およびＩＣＣを認証するために、データおよびカード認証が端末によって行なわれる。チップ−ＵＣＡＦ認証サービスのために使用されるようなパーソナルカードリーダは、オンライン専用端末であると考えられることができ、端末アプリケーションはしたがって、アプリケーション交換プロファイルの設定において示されているようなオフラインカード認証を行なう必要はない。これは、端末に挿入されたカードが本物であることを端末が検証しなくてもよいことを意味し、これは、暗号を確認する際にカード発行者に残され得る。

６．プロセス制限：処理制限機能の目的は、端末のアプリケーションとＩＣＣのアプリケーションとの互換性の程度を判断すること、および、起こり得る取引の拒否を含む任意の必要な調整を行なうことである。

端末アプリケーションはこれらのテストを行なわなくてもよい。なぜなら、結果の如何にかかわらず、端末はＡＲＱＣ（ＩＣＣが要求を「拒否した」場合にはＡＡＣも受入れる）またはＡＡＣを要求するためである。

７．カード保有者の検証：チップ−ＵＣＡＦ認証機構は、カード保有者を認証するため
に、有効なＰＩＮ（個人識別番号）を要求する。

８．端末リスク管理：端末リスク管理は、取得者、発行者およびシステムを不正使用から保護するために、端末によって行なわれるリスク管理の部分である。カード発行者はいずれにせよ取引をオンラインで処理するので、端末リスク管理はオプションである。

９．端末動作分析：端末リスク管理および通常のオフライン取引に関するアプリケーション機能が一旦完了すると、端末は、取引がオフラインで承認されるべきか、オフラインで拒否されるべきか、またはオンラインで送信されるべきかについて、第１の決定を下す。

１０．第１の動作分析：ＩＣＣは、発行者を不正使用または過度のクレジットリスクから保護する、それ独自のリスク管理を行なってもよい。このリスク管理プロセスの結果、ＩＣＣは、取引をオンラインで完了するかまたはオフラインで完了するか、照会を要求するか、もしくは取引を拒否するかを決定してもよい。端末は、ＡＲＱＣまたはＡＡＣのいずれかのアプリケーション暗号を生成するよう、カードに求める。インターネット認証フラグ（ＩＡＦ）のビット７は、ＡＲＱＣ（０に設定）またはＡＡＣ（１に設定）のいずれを求めるかを示す。ＩＣＣがＡＲＱＣを生成するよう求められた場合、ＡＰＤＵのＰ１は０×８０に設定される。ＩＣＣがＡＡＣを生成するよう求められている場合、ＡＰＤＵのＰ１は０×０に設定される。

この要求で、端末は、たとえば以下の特定のデータを含まなければならない。

・許可済みの金額
・端末の国コード
・端末の検証結果
・取引通貨コード
・取引日
・取引の種類
・予測不可能な数字
・端末の種類
・データ認証コード。

端末は、GenerateＡＣコマンドに含まれるデータ列を構築する。ＩＣＣは、データアイテムおよびカードが保持する他のデータアイテムについてアプリケーション暗号（ＡＣ）を生成する。GenerateＡＣコマンドに対する端末の応答は、ＡＣ、および、暗号生成において含まれた、カードが保持する他のデータを含む。

・暗号情報データ（ＣＩＤ）
・アプリケーション取引カウンタ（ＡＴＣ）
・オプションの発行者アプリケーションデータ（ＩＡＤ）。

他のデータ要素も同様に戻されてもよいが、端末アプリケーションによって無視されてもよい。

１１．端末オンライン処理：オンライン処理は通常、発行者、支払システム、または取得者によって規定されたリスクの許容可能な限度外の取引を、発行者が見直し、許可または拒否できることを確実にするために行なわれる。パーソナルカードリーダ端末アプリケーションについては、オンライン処理段階と同等のものが、カード保有者に表示されるデータトークンを、GenerateＡＣ応答データから準備する。しかしながら、これは実際には
ＩＣＣとの取引が完了するまでは起こらず、以下に説明される。端末はオンライン処理を行なう必要はない。

１２．発行者はカードスクリプト処理をする：発行者は、端末によってＩＣＣに送られるコマンドスクリプトを提供して、現在の取引には必ずしも関連しないもののＩＣＣのアプリケーションが引続き機能するためには重要である機能を行なってもよい。パーソナルカードリーダはコマンドスクリプトを提供する能力を持っておらず、そのため端末はこのステップを行なわない。

１３．取引完了：完了機能は、取引の処理を終了させる。端末は、取引がエラー処理によって時期尚早に終了しない限り、この機能を常に行なう。カード実現化例の中には、それらの内部のリスク管理に従って、ＡＲＱＣよりもむしろＡＡＣを生成するものがあってもよい。ＣＩＤのビット８は、カードがＡＡＣかＡＲＱＣのどちらを生成したかを判断する。ビット８が０の場合、カードはＡＡＣを生成した。ビット８が１の場合、カードはＡＲＱＣを生成した。ＩＣＣが第１のGenerateＡＣでＡＡＣを戻した場合には、取引は「オフライン拒否」であり、さらなる処理は必要とされない。ＩＣＣが第１のGenerateＡＣコマンドでＡＲＱＣを戻した場合には、端末はカードにＡＡＣを生成するよう要求すべきである。この要求で、端末は、たとえば以下のデータリストからの特定のデータを含まなければならない。

・許可済みの金額
・端末の国コード
・端末の検証結果
・取引通貨コード
・取引日
・取引の種類
・予測不可能な数字
・端末の種類
・データ認証コード。

端末は、GenerateＡＣコマンドに含まれるデータ列を構築する。ＩＣＣは、ＣＤＯＬ２におけるデータアイテムについてアプリケーション暗号（ＡＣ）を生成する。ＩＣＣ内の取引状態はここで終了し、カードはここでパワーオフとされてもよい。

１４．トークン生成：成功した取引がカードで終了されると、端末は、カード保有者に提示するトークンを生成しなければならない。トークンは、ＩＩＰＢ値に従った第１の、または唯一のGenerateＡＣへの応答から生成される。カードが物理的に端末内にある場合、トークンはカード保有者にのみ表示されなければならない。これは、ＰＣＲとＩＣＣとのやり取りの期間全体を通してカードがリーダ内に残っていても、トークンが表示されている間にそれが取外されれば、端末はその表示を消去してそれ自体のスイッチをオフにしなければならない。上述の機構では、カード保有者の動作による、ＩＣＣからの戻りコードで示された任意のエラー、または端末によるエラーの検出は、ＰＣＲ自体がスイッチオフとなる前に、取引が停止されて適切なエラーメッセージが表示される処理をもたらさなければならない。ＰＣＲは、そのような状況では、トークンを生成して表示してはならない。

この発明で使用可能なメインアクセス装置の図である。 この発明で使用され得る集積回路カードの図である。 既知の高速精算ページのフロー図である。 既知のシングルクリックプロセスのフロー図である。 既知の標準的なプロセスのフロー図である。 どのようにバイトが記述されるかを示す図である。 この発明の或る実施例による認証システムの図である。 この発明の或る実施例による認証システムのさらに詳細なフロー図である。 この発明の或る実施例によるＩＩＰＢデータ構造の図である。 この発明の或る実施例によるＵＣＡＦ構造の図である。 この発明の或る実施例でのＡＡＶの符号化の図である。 「０にセットされるフィラー」と「０にセットされるデータ」の図である。 この発明の或る実施例によるＰＣＲ質問を形成するためのプロセスのフロー図である。 この発明の或る実施例によるＵＮの２７ビットまでを放棄する質問からの８桁の図である。 この発明の或る実施例によるビット抽出および圧縮の図である。 要求されるデータビットの二進数から十進数トークンへの変換の例の図である。 この発明の或る実施例によるフロープロセスの概略図である。 この発明の或る実施例による購入の完了から販売業者の受入れまでのフロープロセスの図である。 この発明の或る実施例による変形された高速精算ページのフロー図である。 この発明の或る実施例による変形されたシングルクリックプロセスのフロー図である。 この発明の或る実施例による変形された標準的なプロセスのフロー図である。 この発明の或る実施例によるカード起動プロセスのフロー図である。 この発明の或る実施例によるＰＣＲ−ＩＣＣ交換プロセスのフロー図である。 この発明の或る実施例によるカード起動からトークン生成までのプロセスのフロー図である。

Claims (14)

1. 認証のために集積回路カードを使用してネットワーク上で商品の販売を取引するためのネットワーク支払システムとともに使用するための認証システムであって、
   前記ネットワークと通信する販売業者サーバを含み、前記販売業者サーバは販売のための商品の少なくとも第１の品目を有し、前記システムはさらに、
   前記ネットワークと通信するクライアント端末を含み、前記クライアント端末は、販売のための前記第１の品目を検討するための出力装置および販売のための前記第１の品目を購入するために購入取引を開始するための入力装置を有し、前記クライアント端末は、販売業者の識別子に関連する情報および前記販売業者サーバから入手された金融取引情報を使用して購入メッセージを構築するように配置され、前記システムはさらに、
   前記集積回路カードと通信するためのカードリーダを含み、前記カードリーダは前記ネットワークから切断されており、
   前記クライアント端末は、質問メッセージを生成するための手段を有し、前記質問メッセージは前記販売業者の識別子および口座番号に関連する情報から生成され、前記システムはさらに、
   前記質問メッセージを前記カードリーダで受取って前記質問メッセージから値を生成するための手段を含み、
   前記集積回路カードは、前記値の少なくとも或る部分から暗号文を生成するための手段を有し、前記集積回路カードは、メモリ、および前記メモリに記憶される第１のデータオブジェクトを有しており、
   前記カードリーダは、前記暗号文の選択された一部から認証トークンを生成するための手段を有し、前記カードリーダにおける暗号文はマスクを受けており、前記マスクは、前記暗号文のうちのどのビットが、前記暗号文の前記選択された一部を形成するかを規定しており、前記選択された一部は、前記暗号文の再計算の後に前記暗号文を認証するために必要なものであり、前記暗号文の選択された一部から認証トークンを生成するための前記手段は、前記第１のデータオブジェクトに従って、前記暗号文の一部の或る部分を選択するように適合されており、
   前記クライアント端末は、前記ネットワークを介して前記販売業者サーバ又は承認サーバへ伝送するためにメッセージ内で前記認証トークンを伝送するための手段を有する、システム。
2. 前記質問メッセージを生成するための手段は、前記販売業者の識別子、口座番号、および購入金額ならびに購入通貨のうちの少なくとも１つに関連する情報から前記質問メッセージを生成するように適合される、請求項１に記載のシステム。
3. 前記質問メッセージを生成するための手段は、前記販売業者の識別子および前記口座番号、ならびにオプションで購入金額および購入通貨のうちの少なくとも１つを連結するように適合される、請求項１または２に記載のシステム。
4. 前記質問メッセージを生成するための手段は、前記販売業者の識別子、前記口座番号、およびオプションで購入金額ならびに購入通貨のうちの少なくとも１つの連結を圧縮するように適合される、請求項１から３のいずれかに記載のシステム。
5. 圧縮はハッシュ関数である、請求項４に記載のシステム。
6. 前記集積回路カードは、メモリおよび前記メモリに記憶される第２のデータオブジェクトを有し、前記質問メッセージを生成するための手段は、前記第２のデータオブジェクトに従って、前記質問メッセージの生成に購入金額および購入通貨のうちの少なくとも１つを含める、請求項１から５のいずれかに記載のシステム。
7. 集積回路カードを使用してネットワーク上で商品の販売を取引するための認証のための方法であって、
   前記ネットワーク上で販売業者サーバとクライアント端末との間に通信を確立するステップを含み、前記販売業者サーバは販売のための商品の少なくとも第１の品目を有し、前記方法はさらに、
   前記クライアント端末で販売のための前記第１の品目を検討し、販売のための前記第１の品目を購入するために購入取引を開始し、かつ販売業者の識別子に関連する情報および前記販売業者サーバから入手された金融取引情報を使用して購入メッセージを構築するステップと、
   クライアント端末で質問メッセージを生成するステップを含み、情報は前記販売業者の識別子および口座番号に関連し、前記方法はさらに、
   カードリーダで前記質問メッセージを受取って前記質問メッセージから値を生成するステップとを含み、前記カードリーダは前記ネットワークから切断されており、
   前記集積回路カードと前記カードリーダとの間に通信を確立しかつ前記値の少なくとも或る部分から暗号文を生成するステップとを含み、前記集積回路カードは、メモリ、および前記メモリに記憶される第１のデータオブジェクトを有しており、
   前記暗号文の選択された一部からカードリーダで認証トークンを生成するステップと、
   前記カードリーダにおける前記暗号文にマスクを受けさせるステップとを含み、前記マスクは、前記暗号文のうちのどのビットが、前記暗号文の前記選択された一部を形成するかを規定しており、前記選択された一部は、前記暗号文の再計算の後に前記暗号文を認証するために必要なものであり、前記暗号文の選択された一部は、前記第１のデータオブジェクトに従って選択され、前記方法はさらに、
   前記ネットワークを介して前記販売業者サーバ又は承認サーバに伝送するために、前記クライアント端末からのメッセージ内で前記認証トークンを伝送するステップとを含む、方法。
8. 質問メッセージを生成するステップは、前記販売業者の識別子、口座番号、および購入金額ならびに購入通貨のうちの少なくとも１つに関連する情報から質問メッセージを生成するステップを含む、請求項７に記載の方法。
9. 質問メッセージを生成するステップは、前記販売業者の識別子および前記口座番号、ならびにオプションで購入金額および購入通貨のうちの少なくとも１つを連結するステップを含む、請求項７または８に記載の方法。
10. 質問メッセージを生成するステップは、前記販売業者の識別子、前記口座番号、およびオプションで購入金額ならびに購入通貨のうちの少なくとも１つの連結を圧縮するステップを含む、請求項７から９のいずれかに記載の方法。
11. 圧縮するステップは、ハッシュ関数を適用するステップを含む、請求項１０に記載の方法。
12. 前記集積回路カードは、メモリおよび前記メモリに記憶される第２のデータオブジェクトを有し、前記方法は、前記第２のデータオブジェクトに従って、購入金額および購入通貨のうちの少なくとも１つから質問メッセージを生成するステップをさらに含む、請求項７から１１のいずれかに記載の方法。
13. 前記カードリーダは、携帯可能な装置である、請求項１から６のいずれかに記載のシステム。
14. 前記カードリーダは、携帯可能な装置である、請求項７から１２のいずれかに記載の方法。

Images