JP2004535619A

JP2004535619A - Systems and methods for secure payment transactions

Info

Publication number: JP2004535619A
Application number: JP2002577680A
Authority: JP
Inventors: ジェイホーガンエドワード; キャンベルカール; クランズレイアーサー; ラザフォードブルース; オーフェイスティーブン
Original assignee: マスターカードインターナシヨナルインコーポレーテツド
Priority date: 2001-04-02
Filing date: 2002-04-02
Publication date: 2004-11-25
Also published as: EP1374131A2; CA2442814A1; EP1374131A4; WO2002079911A3; AU2002254513B2; AU2002254513B8; WO2002079911A2

Abstract

安全な電子支払いにおいて、支払い口座発行者（４０６）から、購入者の操作するユーザソフトウェア（４０２）へ認証データを送信する。ユーザソフトウェアは、販売業者（４０４）のウェブページ上の隠れたフィールドを使って、認証データを販売業者（４０４）へ送信する。販売業者（４０４）は認証データに基づいて認証要求メッセージを生成する。直接販売業者（４０４）からか又は販売業者の取得者を介して、認証要求メッセージを決済機関（４０８）に送信する。決済機関（４０８）は、支払い要求メッセージを照合する口座発行者（４０６）に認証要求メッセージを転送することによって、決済機関（４０８）に送信する認証応答メッセージを生成する。決済機関（４０８）は、直接販売業者（４０４）からか又は販売業者の取得者を介して、認証応答メッセージを転送する。In secure electronic payment, authentication data is transmitted from a payment account issuer (406) to user software (402) operated by a purchaser. The user software sends the authentication data to the merchant (404) using a hidden field on the merchant's (404) web page. The merchant (404) generates an authentication request message based on the authentication data. An authentication request message is sent to the clearing house (408) either directly from the merchant (404) or via the merchant's acquirer. The clearing house (408) generates an authentication response message to send to the clearing house (408) by forwarding the authentication request message to the account issuer (406) matching the payment request message. The clearing house (408) forwards the authentication response message either directly from the merchant (404) or via the merchant's acquirer.

Description

【関連出願へのクロスリファレンス】
【０００１】
本出願は、ここでは全体のなかで参照によって含まれる２００１年９月２６日出願の米国特許出願０９−９６３、２７４号“認証データ収集と有効化のための一般カード保持者認証フィールド（ＵＣＡＦ）を利用した共通相互操作システムと方法”の一部継続出願である。本出願は以下の追加的出願に対する優先権を主張している。追加的出願のすべてが、参照によって含まれ、それは以下のとおりである。２００１年４月１日出願の米国仮特許出願６０−２８０、７７６号“安全な支払いアプリケーション（ＳＰＡ）と一般カード保持者認証フィールド（ＵＣＡＦ）ためのシステムと方法”、２００１年６月４日出願の米国仮特許出願６０−２９５、６３０号“一般カード保持者認証フィールドを利用した安全な支払いアプリケーションのための方法とプロセス”、２００１年７月２４日出願の米国仮特許出願６０−３０７、５７５号“安全な支払いアプリケーションを利用した通信ネットワークを介した取引を行うための方法とシステム”、２００１年６月２２日出願の米国特許出願０９−８８６、４８６号“擬似的又はプロキシ口座番号のないコンピュータネットワークを介した安全な支払いを行うための方法とシステム”、２００１年６月２２日出願の米国特許出願０９−８８６、４８５号“コンピュータネットワークを介した安全な支払いを行うための方法とシステム”。
【技術分野】
【０００２】
オンラインショッピングは、販売業者にとっては経費を削減し新たな消費者を獲得しながらも、消費者にとってはかつてないほど手軽で便利になっている。しかし、多くの消費者はクレジット番号のような機密情報の盗用を恐れ、これらの利点を利用しようとしていない。このような情報の安全性を高めるために努力がなされている。例えば、セキュア・ソケット・レイヤー（ＳＳＬ）技術において、消費者と販売業者間で送るメッセージを暗号化することによって、第三者が情報を傍受して利用することができないようにしている。しかし、この方法では、販売業者は消費者の身元照合ができない。その結果、第三者が物理的なクレジットカードの盗用のような他の不正手段によってクレジットカード番号を入手しようとする場合、ＳＳＬ手法では、第三者は盗んだ情報を不正利用できない。
【０００３】
セキュア・エレクトロニクス・トランザクション（登録商標ＳＥＴ）技術では、消費者／カード保持者、販売業者、クレジットカード発行者を認証するデジタル証明書を利用して上記問題の解決を試みている。各証明書は、委託された認証機関が発行している。現在、ＳＥＴ（登録商標）は、インターネット上の決済扱い方法としては最も安全ではあるが、カード保持者のコンピュータにデジタル証明書と暗号化ソフトウェアをインストールしなければならない。
【発明の開示】
【０００４】
よって、本発明のひとつの目的は、顧客の口座番号のような機密情報を脅かされることなく、顧客がオンラインで買い物ができる決済システムを提供することである。
【０００５】
本発明の別の目的は、数多くの電子証明の発行なしで、顧客の身元を認証する決済システムを提供することである。
【０００６】
本発明のさらに別の目的は、消費者が大きいソフトウェアファイルをダウンロードする必要なく、そして消費者のコンピュータのスピードを遅くしてしまう集中的計賛を必要とせず、情報の安全性を保持してオンライン上の消費者の身元を認証できる決済システムを提供することである。
【０００７】
これらのそして他の目的は、次の本発明のアスペクトによって達成する。
【０００８】
本発明の一つの態様によれば、ユーザのソフトウェアは、ウェブページの表示に利用するウェブページデータの１セットを受信する。ユーザのソフトウェアは、ウェブページが１つ以上の隠れたフィールドを含むか否かを判断する。ウェブページが隠れたフィールドを含む場合、ユーザのソフトウェアは、行うべき第一の支払い手順を選択する。隠れたデータを販売業者に送信するために、第一の支払い手順は、隠れたフィールドを隠れたデータで満たすことを含む。ウェブページが隠れたフィールドを含まない場合、ユーザのソフトウェアは、行うべき第二の支払い手順を選択する。購入データを販売業者に送信するために、第二の支払い手順は、ウェブページの１個以上の可視フィールドを購入データで満たすことを含む。
【０００９】
本発明の別の態様によれば、ユーザのソフトウェアは、１個以上の隠れたフィールドを含むウェブページの表示に利用するウェブページデータの１セットを受信する。ユーザのソフトウェアは、支払い口座発行者の発行する支払い口座の口座名義人身元の認証する、支払い口座発行者からの認証データを受信する。認証データを販売業者に送信するために、ユーザのソフトウェアは、隠れたフィールドを認証データで満たす。
【００１０】
本発明の別の態様によれば、ユーザのソフトウェアは、第一のウェブページに表示するのに使用するウェブページデータの第一のセットを受信する。ユーザのソフトウェアは、第一のウェブページが第一の隠れたフィールドを含んでいるか否かを判断する。第一の隠れたフィールドは、ウェブページが１回のクリックによる支払い手順を行うのに利用可能であることを示す。ユーザのソフトウェアは、第一の隠れたフィールドを、ユーザのソフトウェアを少なくとも１つの決済取引を行うのに利用する旨、販売業者に通知するためデータで満たす。
【発明を実施するための最良の形態】
【００１１】
図４は、本発明の安全な決済取引を行う典型的システムを図示している。このシステムは、ユーザのソフトウェア４０２、商品及び／又はサービスを売る販売業者４０４、マスターカード（登録商標）決済機関のような決済機関４０８、支払い口座発行者４０６を含んでいる。ユーザのソフトウェア４０２は、購入者、すなわち、ソフトウェア４０２のユーザである購入者の操作するアクセスデバイス上で作動する。アクセスデバイスは、例えば、コンピュータ、携帯情報端末（ＰＤＡ）、又は携帯電話でよい。アクセスデバイスは、ユーザのソフトウェア４０２に付加した、又はその一部としてウェブブラウザ上で作動するのが好ましい。
【００１２】
多数の販売業者と口座名義人にとって共通の名前を使った隠れたフィールドと可視フィールドが識別できるように、ウェブブラウザはウェブページのフィールドの名前に基づく宛先を支援するのが、好ましい。一般的には、発行者４０６は、商品及び／又はサービス購入に利用する販売業者からのクレジットカードあるいは他の支払い口座を購入者に発行する銀行である。購入者は、銀行口座の口座名義人と言える。システムは、後で詳述するように、発行者４０６からはじまって、ユーザのソフトウェア４０２、販売業者４０４、決済機関４０８へ、そして発行者４０６に戻るループを効果的に巡る認証データ４１４を利用している。発行者４０６の受信したデータ４２０は、元の認証データ４１４から獲得すべきで、ループ上を巡っている間、認証データ４１４上で不正操作が行われていないとする。それゆえに、発行者４０６は、認証データ４１４と決済機関４０８から受信したデータ４２０に基づいて口座名義人の身元を認証し、取引の真偽を照合できる。
【００１３】
図８は、図４で示した認証データ４１４として利用可能な口座名義人の認証値（ＡＡＶ）としてここでは参照するデータ構造８０２の例を示している。ＡＡＶ８０２は、３２個の６４エンコードベースの文字を表す２値データのうちの２４バイトで構成される。第一の１４バイト８０８は、通常、システムデータを表すことができ、制御バイト８０４と他のシステムデータ８０６を含む。データのうち、残りの１０バイト８１０は、発行者４０６が定義する。制御バイト８０４は、行われるべき認証の種類に関する情報を提供する。例えば、制御バイト８０４は、口座名義人の最初の認証又は事前認証のための“８２”という１６進法表記値と続く口座名義人の認証のための“０２”値を含む。追加的認証のアプローチは、それ自身の制御バイト値によって割り当てられる。例えば、認証手順に基づく計量生物学は、制御バイト８０４のための独自の値を持っている。表Ｉは、ＡＡＶ８０２の様々な箇所を示している。
【００１４】
表Ｉ

【００１５】
表Ｉは、データ構成要素番号を示している。データ構成要素番号１、即ち、制御バイト８０４は、初期認証に関連する全てのＡＡＶのための１６進法表記“８２”と設定され、これは事前認証を示す。構成要素２〜６は、システムデータ８０６であり、販売業者のウェブサイトで提供する取引の具体的内容である。構成要素番号７は、発行者の定義するデータ８１０で構成される。この構成要素は、口座名義人を特定の取引とリンクさせるデータを含んでいる。
【００１６】
発行者４０６の操作するＡＡＶ生成プロセッサ４４０が、ＡＡＶ８０２のシステムデータ８０６と発行者の定義するデータ８１０を生成し、特殊な支払いアウントにリンクさせる。口座名義人の身元の認証の要求４１２を受信したときには、ＡＡＶ生成プロセッサ４４０がシステムデータ８０６と発行者の定義するデータ８１０を２値形式で生成する。ＡＡＶ８０２の２４バイトの２値バージョンを作成するために、制御バイト８０４のみならず、データ８０６と８１０の２セットが結合する。２４バイトの２値データバージョンのベース６４のコード化では、３２文字であるＡＡＶ８０２のベース６４バージョンを生成する。
【００１７】
制御バイト８０４と販売業者の確認ページから供される情報をもとに、システムデータ８０６を生成する。データ８０６は、以下の手順で生成する。
【００１８】
１．制御バイト８０４は、ＡＡＶ８０２のために生成する。制御バイト８０４は、例えば、１６進表示値である“８２．”の２値コード化の桁表示でもよい。
【００１９】
２．売上高は、以下のステップによって生成する。
ａ）ゼロに続く８までを売上高から削除する。
ｂ）第一の残りの売上高の４桁は、４つの２値コード化した桁として売上高フィールドに置く。
【００２０】
３．ステップ２ｂで切り捨てた売上高の右端の桁数が決まる。この数は、ただ一つで、２値コード化した桁であり、売上高切捨てフィールドに置く。
【００２１】
４．３桁の通貨コードは、２値化データに変換し、残り１０ビットを１２ビットフィールド中に右に位置調整し、左に２値データ“００．”を当てる。
【００２２】
５．販売業者名は、１６進法表記のユニコード制御値のセットで示し、以下のルールを使って編集する。販売業者名がラテン文字１として表現する場合があるが、他の文字はすべて編集の必要はない。
ａ）すべてのラテン１の制御文字は削除する。これは、００００から００１Ｆと００７Ｆから００９Ｆの１６進法表記範囲のユニコード文字である。
ｂ）“＆”（１６進法表記の００２６）と、“＠“（１６進法表記の００４０）と、“１／４”（１６進法表記の００ＢＣ）と、“１／２”（１６進法表記の００８Ｄ）と、“３／４”（１６進法表記の００ＢＥ）を除き、残りのラテン１の非アルファベット文字をスペース文字で置き換える（１６進法表記の００２０）。ユニコードの非制御文字と非アルファベット文字は、００２１から００２Ｆまで、００３Ａから００４０まで、００５Ｂから００６０まで、０００７Ｂから０００７Ｅまで、００Ａ０から００ＢＦまで、００Ｄ７、と００Ｆ７のセットにある。
ｃ）通常の厳密な文字セット中（２０００から２０６Ｆまで）のどんな文字も、スペース文字（００２０）と置き換える。
ｄ）販売業者名の中の第一の３桁だけを含むため、前述第三の桁を超える、（００３０）から（００３９）のラテン１のいずれの桁も削除する。
ｅ）前のステップ（ａ）から（ｄ）までを完了した後、全ての連続するスペース文字（００２０）は、ひとつのスペース文字（００２０）と置き換える。
ｆ）前のステップ全てを完了後、前後全てのスペース文字を削除する。
【００２３】
６．編集した（又は無編集の）販売業者名のＳＨＡ−１のハッシュを生成し、表Ｉ中のデータ構成要素５を満たすのに利用する。
【００２４】
７．販売業者の支払い画面からのＭＴＳを２値化コード桁としてファイルしたＭＴＳに挿入する。
【００２５】
処理結果である１４バイトの２値化した値は、発行者の定義するデータ８１０とＡＡＶ８０２を生成するためにエンコードしたベース６４と結合する予定のシステムデータ８０６である。
【００２６】
発行者の定義するデータ８１０の生成に利用する手順は、最終的にはどのアプローチをＡＡＶ８０２の照合に利用するかによる。例えば、暗号的アプローチでは、発行者の定義するデータ８１０は、発行者４０６の選んだ数、テキスト列、あるいは他のデータを暗号化することによって生成する。例えば、暗号化するデータは、販売業者名、取引高、日付、購入に利用した口座の口座番号の一連のデータでありうる。メッセージ認証コード（ＭＡＣ）を生成するために、データを、後に詳述する秘密の鍵を使って暗号化する。ＩＳＯ認証の暗号化アルゴリズムを使って、ＭＡＣを生成するのが好ましい。ＭＡＣは、ＡＡＶ８０２からのシステムデータ構成要素８０４と８０６と共に結合する発行者の定義するデータ８１０に含まれている。認証中、発行者４０６は、真偽の照合のための発行者の定義するデータ要素８１０を、暗号を使って照合する。暗号を使ったアプローチは、ある１つの機能でＡＡＶ８０２を生成し、別の機能で照合し、その２つの機能はリアルタイム通信ではないシステムにおいて特に有益である。この暗号を使ったアプローチのために、ＡＡＶ８０２中の発行者の定義するデータ８１０は、表ＩＩ記載のデータ構成要素を含む。
【００２７】
表ＩＩ

【００２８】
発行者の定義するデータ８１０は、１０バイナリ・バイトに限定されるので、上記各データ構成要素の場所のみ含めばよい。データ８１０は、ＭＡＣの４バイト、取引順序番号の４バイト、鍵表示データの１バイト、ＡＡＶフォーマットインジケータとＡＡＶ生成プロセッサインジケータの結合した合計データ量の１バイトを含むのが好ましい。
【００２９】
不正改ざんがあるか否かを、ＭＡＣは暗号を使ってチェックする。取引の照合に使うＡＡＶ生成プロセッサ４４０とＡＡＶ照合プロセッサ４４２は共に、ＭＡＣ生成に利用する秘密鍵へアクセスできる。
【００３０】
ＡＡＶ生成プロセッサ４４０は、各取引のために以下のステップを行う。
【００３１】
１．以下のＡＡＶデータ構成要素を生成する。
ＡＡＶフォーマット数、ＡＡＶ生成機能インジケータ、鍵表示データ
【００３２】
２．前のＡＡＶで使った取引順序番号を、発行者４０６の選択した所定量増加させる。増加数の右端ビットのうち、１又はそれ以上のビットを、ＡＡＶ取引順序番号のデータ構成要素として利用する。
【００３３】
３．鍵表示データで表示した鍵を使い、以下のデータを連結し暗号化してＭＡＣを生成する。すなわち、そのデータとは、（１）販売業者に提供されている口座番号、（２）ＭＡＣサブフィールド自身を除く、全てのＡＡＶ、（３）他の発行者の選択したデータ、である。暗号を使って計算したＭＡＣの左端の場所を、ＡＡＶ・ＭＡＣデータ構成要素として発行する。
【００３４】
暗号を使ったアプローチでは、ＭＡＣを生成するために、ＡＡＶ生成プロセッサ４４０の利用する秘密の暗号鍵をＡＡＶ照合プロセッサ４４２は判別する。２つのプロセッサ４４０と４４２は、秘密の暗号鍵を生成する鍵を共有するのが好ましい。ＭＡＣ生成鍵の多く（数百、数千、あるいは数百万）を、その共有鍵から得る。何年にもわたり、鍵生成のための鍵は利用できるが、ＭＡＣ生成鍵は、ＭＡＣ生成アルゴリズムと発行者の鍵管理方針の必要条件によっては比較的頻繁に変更するのが好ましい。いずれにせよ、鍵生成のための鍵が脅かされているという疑いがある場合には、その鍵を変更すべきである。
【００３５】
複数の制御（３つの制御が好ましい）の下、分割した知識を利用して、その共有した鍵生成のための鍵を、ＡＡＶ照合プロセッサ４４２が生成し、１つ又はそれ以上の鍵構成要素としてＡＡＶ生成プロセッサ４４０まで運ぶ。暗号鍵の生成と分散は、ＩＳＯ安全基準に適合すべきである。同様に、鍵生成のための鍵からＭＡＣ生成鍵を得るための仕組みも、ＩＳＯ安全基準に準じるべきである。更に、好ましくは、ＡＡＶ生成プロセッサ４４０又はＡＡＶ照合プロセッサ４４２に結合する記憶媒体に格納したいずれの暗号鍵も、ＩＳＯ基準に従って物理的脅威から鍵を保護する物理的に安全なハードウェアのみに存在する。
【００３６】
ＡＡＶ照合プロセッサが、ＡＡＶを１個以上のＡＡＶ生成プロセッサから受信すると、照合プロセッサがＡＡＶ生成プロセッサと共有するいずれの暗号鍵も、他のＡＡＶ生成プロセッサと共有するいずれの鍵とも関連性をもつべきではない。
【００３７】
以下は、初期取引用ＡＡＶの暗号を使った生成例である。
初期認証取引例のデータ：
制御バイトの値：８２
売上高：＄８７６５４．３２
通過コード：８４０
販売業者名（ＳＰＡＭｅｒｃｈａｎｔ、Ｉｎｃ．のユニコード表示）：
００５３００５０００４１００２０００４Ｄ００６５００７２
００６３００６８００６１００６Ｅ００７４００２Ｃ００２０００４９００６Ｅ００６３００２Ｅ
ＭＴＳ：ＦＯＢ
発行者の定義したデータ：５５３９０９００４００４８６４７１２３４
販売業者名のＳＨＡ−ｌのハッシュ（上記編集後）＝３１９８ＢＥ３０ＩＦＢＤ７４ＯＦＥ２ＡＤ７ＥＤ２ＥＤ８２９Ｅ６９０６ＥＣＥ３６Ｆ
２４バイナリ・バイト・ソースの結果：
８２８７６５３８４０３１９８ＢＥ３０１ＦＢＤ７４Ｆ０ＡＢ５５３９０９００４００４８６４７１２３４
３２文字のベース６４のコード化列へ変換：
ｇｏｄＩＯＥＡｘｍＬ４ｗＨ７１０８ＫｔＶＯＱｋＡＱＡＳＨＲｘＩ０
【００３８】
本例の詳細は以下のとおりである。
マップ：ＡＡＡＡＡＡＡＡＢＢＢＢＢＢＢＢＢＢＢＢＢＢＢＢＣＣＣＣＤＤＤＤＤＤＤＤＤＤＤＤ
ソース：０２８７６５３８４０
２値：１０００００１０１００００１１１０１１００１０１００１１１００００１００００００
６ビット：
ワード：００４０２９３７１４０４
ベース６４：Ａｏｄｌ０Ｅ
マップ：
ＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦ
ソース：３１９８ＢＥ３０１ＦＢＤ７４Ｆ０ＡＢ
２値：
００１１０００１１００１１０００１０１１１１１０００１１０００００００１１１１１１０１１１１０１０１１１０１００１１１１００００１０１０１０１１
６ビット：
ワード：００４９３８１１５６４８０７５９５３５２６０
ベース６４：ＡｘｍＬ４ｗＨ７１０８Ｋ
マップ：ＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧ
ソース：５５３９０９００４０
２値：０１０１０１０１００１１１００１００００１００１０００００００００１００００００
６ビット：
ワード：４５２１１４１６３６００１６
ベース６４：ｔＶ０ＱｋＡＱ
マップ：ＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧ
ソース：０４８６４７１２３４
２値：０００００１００１００００１１００１０００１１１０００１００１０００１１０１００
６ビット：
ワード：００１８０７１７４９０８５２
ベース６４：ＡＳＨＲｘＩ０
結果：
２４バイト・ソース：８２８７６５３８４０３１９８ＢＥ３０ＩＦＢＤ７４Ｆ０ＡＢ５５３９０９００４００４８６４７１２３４
３２文字のベース６４のコード化列へ変換：ｇｏｄｌＯＥＡｘｍＬ４ｗＨ７１０８ＫｔＶＯＱｋＡＱＡＳＨＲｘＩ０
【００３９】
以下は、暗号を使って、次の取引に対するＡＡＶ生成の例である。
次の取引例の期日：
制御バイト値：８２
売上高：＄８７６５４．３２
通貨コード：８４０
販売業者名（ＳＰＡＭｅｒｃｈａｎｔ、Ｉｎｃ．のユニコード表示）：
００５３００５０００４１００２０００４Ｄ００６５００７２
００６３００６８００６１００６Ｅ００７４００２Ｃ００２０
００４９００６Ｅ００６３００２Ｅ
ＭＴＳ：ＦＯＡＢ
発行者の定義したデータ：５５３９０９００４００４８６４７１２３４
販売業者名のＳＨＡ−ｌのハッシュ（上記編集後）＝３１９８ＢＥ３０ＩＦＢＤ７４ＯＦＥ２ＡＤ７ＥＤ２ＥＤ８２９Ｅ６９０６ＥＣＥ３６Ｆ
２４バイナリ・バイトのソースの結果：
０２８７６５３８４０３１９８ＢＥ３０ＩＦＢＤ７４Ｆ０ＡＢ５５３９０９００４００４８６４７１２３４
３２文字のベース６４のコード化列へ変換：
ＡｏｄＩＯＥＡｘｍＬ４ｗＨ７１０８ＫｔＶＯＱｋＡＱＡＳＨＲＩ０
本例の詳細は以下のとおり。
マップ：ＡＡＡＡＡＡＡＡＢＢＢＢＢＢＢＢＢＢＢＢＢＢＢＢＣＣＣＣＤＤＤＤＤＤＤＤＤＤＤＤ
ソース：８２８７６５３８４０
２値：１０００００１０１００００１１１０１１００１０１００１１１００００１００００００
６ビット：
ワード：３２４０２９３７１４０４
ベース６４：ｇｏｄ１ＯＥ
マップ：ＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＥＦＦＦＦＦＦＦ
ソース：３１９８ＢＥ３０１ＦＢＤ７４Ｆ０ＡＢ
２値：００１１０００１１００１１０００１０１１１１１０００１１０００００００１１１１１１０１１１１０１０１１１０１００１１１１００００１０１０１０１１
６ビット：
ワード：００４９３８１１５６４８０７５９５３５２６０１０
ベース６４：ＡｘｍＬ４ｗＨ７１０８Ｋ
マップ：ＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧ
ソース：５５３９０９００４０
２値：０１０１０１０１００１１１００１００００１００１００００９００００１００００００
６ビット：
ワード：４５２１１４１６３６００１６
ベース６４：ｔＶＯＱｋＡＱ
マップ：ＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧＧ
ソース：０４８６４７１２３４
２値：０００００１００１００００１１００１０００１１１０００１００１０００１１０１００
６ビット：
ワード：００１８０７１７４９０８５２
ベース６４：ＡＳＨＲｘＩ０
結果：
２４バイト・ソース：８２８７６５３８４０３１９８ＢＥ３０ＩＦＢＤ７４Ｆ０ＡＢ５５３９０９００４００４８６４７１２３４
３２文字のベース６４のコード化列へ変換：ｇｏｄＩＯＥＡｘｍＬ４ｗＨ７Ｉ０８ＫｔＶＯＱｋＡＱＡＳＨＲｘＩ０
マップ凡例：
Ａ―２値コードの桁（ＢＣＤ）として表した制御バイト値
Ｂ―売上高―ＢＣＤとして表した４つの最上位桁
Ｃ―売上高切捨てフィールド―ＢＣＤとして表した１桁
Ｄ―通貨コード―２値化して表した３桁
Ｅ―販売業者名のＳＨＡ−１のハッシュ―ＳＨＡ−１のハッシュ値のはじめの７バイト
Ｆ―ＭＴＳ―２バイト値
Ｇ―ＢＣＤとして表した発行者の定義するデータ、１０バイト
【００４０】
比較アプローチは、ＡＡＶ生成と照合機能は、例えば、共通データ記憶システムを介するなど相互にリアルタイムで通信するシステムに好適である。比較アプローチでは、ランダム値又は発行者４０６の選択した他のアルゴリズムを使って、発行者の定義するデータ８１０を生成する。結果の値８１０は、ＡＡＶ８０２への／からのシステムデータ８０６と結合する。その場合、ＡＡＶ８０２を、取引真偽を照合するためのＡＡＶ照合プロセッサ４４２の利用する共通データベースへ保存する。照合中、認証要求４２０の受信したＡＡＶをデータベースに格納したＡＡＶと比較することによって、発行者４０６は取引の真偽を照合する。比較アプローチ陽のＡＡＶを生成し、以下の手順に従って格納する。
【００４１】
１．発行者の定義、例えば、ランダム数ジェネレータなどに従って、発行者の定義するデータ８１０を生成する。
【００４２】
２．発行者の定義するデータ８１０を、少なくとも特定の口座番号とリンクするデータベースに格納する。
【００４３】
３．販売業者の隠れたフィールドデータを、少なくとも発行者の定義するデータ８１０とリンクするデータベースに格納する。
【００４４】
４．データベースを、ＡＡＶ照合プロセッサ４４２で利用可能にする。
【００４５】
５．発行者の定義するデータ構成要素８１０を、２４バイトの２値への／からのシステムデータ構成要素８０８と結合する。２４バイトの２値化の値は、３２文字７０２生成のために、ベース６４でコード化する。
【００４６】
図１は、上記ＡＡＶ８０２を含む認証データ４１４を使った図４で示した決済取引システムの操作の典型的手順を図示している。図中の手順においては、販売業者４０４の操作するサーバ４４８で利用可能なウェブサイトの様々なページを口座名義人が見る（ステップ１３２）。購入者が、自分が販売業者４０４から購入したいと思う商品及び／又はサービスを見つけて選択する（ステップ１１４）。商品及び／又はサービスを選択すると、口座名義人が販売業者の精算手順を開始する（ステップ１１６）。例えば、一般的に利用されている“ショッピングカート”方法では、仮想ショッピングカート、すなわち、買い物客が仮に購入しようと考えたアイテムのリストに置く商品及び／又はサービスを買い物客が選択する。買い物客がアイテムのリストに完全に満足すれば、どの時点でショッピングカートのアイテムについて精算手順を開始するかを販売業者のウェブページ上の可視的な“精算”ボタンでクリックして買い物客は精算の開始を行う。他の可能な方法では、１回のクリックによる精算手順を利用している。その１回のクリックによる精算手順では、販売業者４０４が口座名義人の情報を格納し、情報を多数取引のために利用している。格納した情報は、口座名義人の請求先と出荷先のアドレス、Ｅメールアドレス、口座番号、口座有効期限を含む。その場合、アイテムに関連した可視的“購入”ボタンをクリックすることによって、口座名義人は即座にアイテムの精算の開始が行える（ステップ１１６）。
【００４７】
発行者４０６の普及した基準に従って、販売業者のウェブサイトが１回のクリックで購入できるように構成されている場合、１回のクリックで購入ができる各販売業者のウェブページは、“ＵＣＡＦ使用可能インジケータフィールド”とも言える特定の隠れたフィールドを含んでいる。この特定の隠れたフィールドは後に詳述する。ウェブページ上のこの隠れたフィールドの存在は、ユーザのソフトウェアにウェブページが１回のクリックによるショッピングを行えるよう構成されている旨知らせるものである。
【００４８】
精算フェーズが開始されると（ステップ１１６）、ＵＣＡＦ使用可能インジケータフィールドがウェブページ上には存在しない場合（ステップ１２８）、ユーザのソフトウェア４０２は、販売業者４０４からの新たなウェブページデータ４１０をネットワーク４３４の場所４２６を介して要求・受信する（ステップ１０２）。ネットワーク４３４は、例えば、インターネットでもよい。ウェブページデータは、口座名義人のコンピュータ画面上の“精算”ウェブページ（別名、“注文確認”ウェブページ）を表示するのに利用する。口座名義人及び／又はユーザのソフトウェア４０２は、いくつかのあるいは全てのこの情報を確認ページ上のフィールドに入れることによって、請求先アドレス、出荷先アドレス、及び／又は支払い口座の詳細を販売業者４０４に提供する（ステップ１３０）。請求及び出荷アドレス情報は、口座名義人によって手動で入力するか、ユーザのソフトウェア４０２によって自動的に満たすか、又は特定の口座名義人のための販売業者のサーバに格納した情報に基づいて自動的に満たす。注文を確認するために、口座名義人は、可視的確認ページ上の“提出”ボタンをクリックする（ステップ１３２）。上記のように認証データ４１４を使って作動するように販売業者４０４のウェブサイトを構成している場合、販売業者の注文確認ページは、以下の１個以上の隠れたフィールドを含む。
【００４９】
（１）ユーザのソフトウェア４０２に情報を配信する隠れたフィールド、（２）ユーザのソフトウェア４０２からのＡＡＶのような情報を受信する隠れたフィールド。これらの隠れたフィールドは、ここではまとめて“一般カード保持者認証フィールド（ＵＣＡＦ）”と呼び、これは以下で詳述する。確認ページ上のＵＣＡＦを介して、ユーザのソフトウェア４０２は以下の情報のいくつか又は全てを受信する。
【００５０】
表ＩＩＩ

【００５１】
販売業者の注文確認ページ中に含まれるこれら隠れたフィールドの具体的な値は、以下のとおり与えられる。具体的な値は、以下取引詳細に基づく。
販売業者名：ＳＰＡＭｅｒｃｈａｎｔ、Ｉｎｃ．
販売業者の所在地：購入場所は、ニューヨーク
取引高：ＵＳ＄８７６５４．３２
販売業者の所有するフィールド：
＜ＩＮＰＵＴｔｙｐｅ＝”ＨＩＤＤＥＮ”ｎａｍｅ＝”Ｕｃａｆ＿Ｍｅｒｃｈａｎｔ＿Ｎａｍｅ”ｖａｌｕｅ＝”００５３００５０００４１００２０００４Ｄ００６５００７２００６３００６８００６１００６Ｅ００７４００２Ｃ００２０００４９００６Ｅ００６３００２Ｅ”＞
＜ＩＮＰＵＴｔｙｐｅ＝”ＨＩＤＤＥＮ”ｎａｍｅ＝”Ｕｃａｆ＿Ｃｉｔｙ”ｖａｌｕｅ＝”Ｐｕｒｃｈａｓｅ”＞
＜ＩＮＰＵＴｔｙｐｅ＝”ＨＩＤＤＥＮ”ｎａｍｅ＝”Ｕｃａｆ＿Ｓｔａｔｅ＿Ｃｏｕｎｔｒｙ”ｖａｌｕｅ＝”ＮＹ”＞＜ＩＮＰＵＴｔｙｐｅ＝”ＨＩＤＤＥＮ”ｎａｍｅ＝”Ｕｃａｆ＿Ｃｕｒｒｅｎｃｙ＿Ｃｏｄｅ”ｖａｌｕｅ＝”８４０”＞＜ＩＮＰＵＴｔｙｐｅ＝”ＨＩＤＤＥＮ”ｎａｍｅ＝”Ｕｃａｆ＿Ｓａｌｅ＿Ａｍｏｕｎｔ”ｖａｌｕｅ＝００００８７６５４３２１”＞
＜ＩＮＰＵＴｔｙｐｅ＝”ＨＩＤＤＥＮ”ｎａｍｅ＝”Ｕｃａｆ＿ＭＴＳ”ｖａｌｕｅ＝”Ｆ０ＡＢ”＞
＜ＩＮＰＵＴｔｙｐｅ＝”ＨＩＤＤＥＮ”ｎａｍｅ＝”Ｕｃａｆ＿Ｂｒａｎｄ”ｖａｌｕｅ”０１”
発行者サーバの所有するフィールド
＜ＩＮＰＵＴｔｙｐｅ＝”ＨＩＤＤＥＮ”ｎａｍｅ＝”Ｕｃａｆ＿Ａｕｔｈｅｎｔｉｃａｔｉｏｎ＿Ｄａｔａ”ｖａｌｕｅ＝”
ｇｏｄｌＯＥＡｘｍＬ４ｗＨ７１Ｏ８ＫｔＶＯＱｋＡＱＡＳＲＲｘＩ０”＞＜ＩＮＰＵＴｔｙｐｅ＝”ＨＩＤＤＥＮ”ｎａｍｅ＝”Ｕｃａｆ＿Ｐａｙｍｅｎｔ＿Ｃａｒｄ＿Ｎｕｍｂｅｒ”ｖａｌｕｅ＝”
１２３４５６７８９９８７４５６３”＞
＜ＩＮＰＵＴｔｙｐｅ＝”ＨＤＤＥＮ”ｎａｍｅ＝”Ｕｃａｆ＿Ｐａｙｍｅｎｔ＿Ｃａｒｄ＿ＥｘｐＤａｔｅ＿Ｍｏｎｔｈ”ｖａｌｕｅ＝”０２”＞
＜ＩＮＰＵＴｔｙｐｅ＝”ＨＩＤＤＥＮ”ｎａｍｅ＝”Ｕｃａｆ＿Ｐａｙｍｅｎｔ＿Ｃａｒｄ＿ＥｘｐＤａｔｅ＿Ｙｅａｒ”ｖａｌｕｅ＝”２００４＞
＜ＩＮＰＵＴｔｙｐｅ＝”ＨＪＤＤＥＮ”ｎａｍｅ＝”Ｕｃａｆ＿Ｐａｙｍｅｎｔ＿Ｃａｒｄ＿ＣＶＣ２”ｖａｌｕｅ＝”２５６”＞
【００５２】
特定の口座名義人からの経常的支払いの受信を希望する販売業者のために、以下の情報をＵＣＡＦ構造内にて収集する。
【００５３】
取引頻度−これは、経常的支払いの頻度を示す。販売業者の割り当てる有効値は、週が“Ｗ”、月が“Ｍ”、四半期が“Ｑ”、年が“Ａ”である。
【００５４】
支払い回数−口座名義人と販売業者間の経常的支払いの合計を判定するためのもの。このフィールドに、支払い不履行の最大限度値がないのが好ましい。この経常的支払い機能を利用する各ブランドは、自身の実行限度値を設定してもよい。例えば、支払いの最適最大数は、２６０である。
【００５５】
第一回目の支払い−このフィールドは、第一回目の経常的支払いのＤＤＭＭＹＹＹＹと表現した期日と経常的支払い関係とに口座名義人が同意するか否かを伝えるものである。
【００５６】
販売業者取消し方針−このフィールドは、口座名義人が経常的支払いをキャンセルできるか否かを示している。値が“１”は、「はい」、“０”は「いいえ」である。経常的支払いの構成要素は、ＵＣＡＦのために定義した１つの隠れたフィールドと選択的に結合できる。この新たな隠れたフィールドは、Ｕｃａｆ＿Ｒｅｃｕｒ＿Ｐａｙｍｅｎｔと名づけられ、以下の場所を含む。
【００５７】
“ＦＮＮＮＤＤＭＭＹＹＹＹＣ”において、
・Ｆは、経常的支払いの頻度。有効値は以下の通り。
Ｗ−週、Ｍ−月、Ｑ−四半期、Ａ−年
・ＮＮＮは、経常的支払い数。
・ＤＤＭＭＹＹＹＹは、第一の経常的支払いの期日。例えば、２０００年５月２９日は、“２９０３２００２”と表す。
・Ｃ−販売業者キャンセル方針。これは、カード保持者が経常的支払いをキャンセルできるか否かを示している。値が“１”は、「はい」、“０”は「いいえ」である。
【００５８】
例えば、販売業者４０４が１年間に毎月という内容で２００１年３月１日に第一の支払いを行うという経常的支払いを支援する場合や、口座名義人が取引のキャンセルを許される場合に、Ｕｃａｆ＿Ｒｅｃｕｒ＿Ｐａｙｍｅｎｔの値は、“Ｍ１２０１０３２００１１”となる。このアプローチでは、経常的支払いのための複数の隠れたフィールドを販売業者４０４が繰返し満たさなければならない。何故なら、１つの隠れたフィールドに情報が集約されるからである。
【００５９】
販売業者４０４は、販売業者の支払いページの隠れたフィールドの１つに、販売業者取引スタンプ（ＭＴＳ）を選択的に含むことができる。ＭＴＳは、各取引に固有であり、よって、追加的な安全フォームとして利用できる。特に、ＭＴＳは、口座名義人が販売業者のウェブサイトに実際アクセスしたことを示すのに利用して、取引が正当なものであって、不正な販売業者の再取引や正当な販売業者と見せかける他者ではないという証拠を提供する。
【００６０】
１回のクリックによる購入以外の取引のために、販売業者名や売上高などの口座名義人情報を表示するための可視的フィールドを、注文確認ページは含む。買い物客が確認ボタンをクリックする前に、販売業者名と取引高は確認ページ上で見ることができるという事実は（後に説明する図２のステップ２１０）、口座名義人が実際取引を確認・了承したという追加的証拠を提供する。この特徴は、口座名義人による取引拒否を発行者４０６が厳密に調べる際の助けとなる。
【００６１】
図１を再び参照すると、販売業者４０４の注文確認ウェブページが、上記隠れたフィールドを含む場合（ステップ１０４）、この場合、発行者４０６から始まってユーザのソフトウェア４０２、販売業者４０４、決済機関４０８へと続き発行者４０６へと戻るループ中に認証データ４１４を送る上記技術を利用する認証手順１０６を使って、購入を行う。一方、注文確認ウェブページが隠れたフィールドを含まない場合（ステップ１０４）、続いて、ユーザのソフトウェア４０２は、クレジットカード番号や有効期限などの購入データを伴うウェブページの可視的フィールドを満たすことを含む従来の支払い手順１０８を行い（ステップ１１０）、購入データを販売業者４０４へ認証目的に送信するために、データで満たされたウェブページフィールドを利用する（ステップ１１２）。
【００６２】
ステップ１２８では、口座名義人が“購入”ボタンをクリックしたウェブページにＵＣＡＦ使用可能インジケータフィールドが存在する場合、ユーザのソフトウェア４０２は、ＵＣＡＦ使用可能インジケータフィールドを、口座名義人がＵＣＡＦ使用可能な決済取引を行うユーザのソフトウェア４０２を利用していることを販売業者４０４に通知するコード（例えば、“０１”）で満たす（ステップ１３４）。コードで満たしたＵＣＡＦ使用可能インジケータフィールドを含むウェブページを、販売業者４０４に提示する（ステップ１３６）。販売業者４０４は、確認ページデータをユーザのソフトウェア４０２に送信する（ステップ１３８）。しかし、購入者は、例えば、“注文を処理しています。”という簡単なメッセージを含んだページ又はウィンドウを見るにすぎない。このメッセージを表示している間に、ユーザのソフトウェア４０２は、口座名義人のアドレス情報と口座番号を有する確認ページ上の様々な隠れたフィールドを自動的に満たす（ステップ１４０）。
【００６３】
次に、認証手順１０６を行う。
【００６４】
いずれの場合でも、認証手順１０６又は認証手順１０８において、認証が付与されれば（ステップ１１８）、商品及び／又はサービスを出荷し配達するか、そうでなければ、購入者に提供する（ステップ１２０）。精算と決済手順は、発行者４０６と決済機関４０８間の精算と決済を行うために利用できる（ステップ１２２）。販売業者４０４は取得者と取引があれば（以下説明する図５のアイテム５１４）、支払いを発行者４０６と取得者５１４間で精算・決済する（ステップ１２２）。
【００６５】
一方、認証が拒否されれば（ステップ１１８）、口座名義人は拒否を通知される（ステップ１２４）、そして取引を終える（ステップ１２６）。
【００６６】
取引を認証するための認証データ４１４を利用する手順１０６の例を図２に示す。販売業者の注文確認ページ中の隠れたフィールドから受信した及び／又は口座名義人の提供した情報を含みながら、ユーザのソフトウェア４０２は発行者４０６に口座名義人の身元認証の要求４１２を送信する（ステップ２０２）。ネットワーク４３４の場所４２８を介して要求４１２を送る。口座名義人の身元認証の要求４１２に応答して、発行者４０６はＡＡＶのような認証データ４１４をユーザのソフトウェア４０２へネットワーク４２８を介して送信する。ユーザのソフトウェア４０２が発行者４０６からの認証データ４１４を受け取ると（ステップ２０４）、ソフトウェア４０２は隠れたデータ４１６中の認証データ４１４を含み（ステップ２０６）、販売業者４０４のウェブページ上の隠れたフィールドを満たすために隠れたデータ４１６を利用する（ステップ２０８）。例えば、ＡＡＶは、確認ページ上で隠れた認証データフィールドに入れる。
【００６７】
各取引ごとに各口座名義人を認証するのが好ましい。口座名義人の認証に失敗すれば、失敗の旨、口座名義人に通知する。口座名義人であることが確認できれば、発行者のＡＡＶ−生成プロセッサ４４０は、ＡＡＶ８０２を生成する。この場合、発行者４０６は認証データ４１４中のＡＡＶ８０２を含み、データ４１４をユーザのソフトウェア４０２に送る。
【００６８】
ユーザのソフトウェア４０２の入力した確認ページ上の隠れたフィールドにある他の情報は、口座名義人の支払い口座の詳細、例えば、彼（女）の口座番号、有効期限、そして任意にカード有効性確認（ＣＶＣ２）値などを含む。更に、隠れたフィールドは上記ＵＣＡＦ使用可能インジケータフィールドを含むのが好ましい。状況によっては、販売業者の供給した口座番号（口座名義人が書かれている場合）と隠れた口座番号フィールドに挿入された口座番号間の相違点をユーザのソフトウェア４０２は確認できる。ユーザのソフトウェア４０２は口座名義人に相違点を警告し確認を要求する。場合によっては、口座名義人が発行者４０６と共に登録された複数の口座を持つ。このような場合、口座名義人は支払いに利用する口座番号を選択する。
【００６９】
確認用ウェブページの隠れたフィールドがデータで満たされれば、そのページは認証データ４１４（ＡＡＶ８０２を有する）、支払い口座情報、他の関連情報を有する隠れたデータ４１６を含む。ページ上の“提示”ボタンをクリックして、確認ページを販売業者４０４に提示する（ステップ２１０）。これが例えばショッピングカート型取引の場合、この提示ボタンが口座名義人には見えて、口座名義人がこれをクリックする。しかし、１回のクリックによる取引においては、提示ボタンは隠れたままで、ユーザのソフトウェア４０２が提示ボタンを自動的にクリックする。
【００７０】
販売業者４０４は、確認ページ上の隠れたデータ４１６を受信し、制御バイト８０４とＡＡＶ８０２に含まれる販売業者名のハッシュを有効化する。状況によっては、販売業者４０２は販売業者取引スタンプ（販売業者が生成していれば）と売上高の照合も行える。
【００７１】
好ましくは、販売業者４０４が、口座名義人を特定の取引へリンクに利用するＡＡＶを獲得し保持する。分割出荷の次の認識を行うのに、そのデータを使うことができ、例外的処理の間はそのデータを販売業者４０４の値としてもよい。
【００７２】
販売業者４０４が不正なＡＡＶ８０２を受信していないこと確認するため、最上位ビットが“１”であることを確認して、制御バイト８０４を照合する。これは、ベース６４でエンコード化したＡＶＶ８０２の最左端の文字が小文字の“ｇ”であることを照合することによって行われる。
【００７３】
ＡＡＶに含まれる販売業者名のハッシュが正確には隠れたフィールドの１つに含まれる販売業者名のハッシュと一致することを確認して、販売業者名の照合を行う。これを達成するために、ベース６４でコード化したＡＶＶ８０２の７〜１６文字が、正確に前計算値と一致するかを販売業者４０４は照合する。販売業者名のＳＨＡ−１のハッシュの処理を行うことによって、この前計算値が得られる。
【００７４】
例えば、ＡＡＶは以下のデータであってよい。
ｇｏｄｌＯＥＡｘｍＬ４ｗＨ７１０８ＫｔＶＯＱｋＡＱＡＳＨＲｘ１０
【００７５】
販売業者照合プロセスでは、７から２６文字を分析する。
ＡｘｍＬ４ｗＨ７１０
【００７６】
販売業者４０４は、この前計算値と既知の販売業者名のＳＨＡ−１のハッシュを比較する。この値の有効化に成功しない場合、販売業者４０４は取引を断る。
【００７７】
状況によっては、隠れたフィールドの１つに示した売上高に基づいて、販売業者４０４はＡＡＶ売上高を有効化する。販売業者４０４はベース６４でコード化したＡＶＶ８０２を２４バイナリ・バイトのソースに変換し、売上高、売上高切捨てフィールド、取引通貨コードを識別する。表Ｉのデータ内容と隠れたフィールドを介して示した売上高と通貨コードに従って、販売業者４０４は売上高、売上高切捨てフィールド、取引通貨コードを有効化させていく。値の有効化に成功しなかった場合、販売業者４０４は取引を断る。
【００７８】
販売業者４０４はＡＡＶ８０２で得られたＭＴＳを任意に有効化させる。ＭＴＳを有効化した場合、販売業者４０４はＡＡＶ８０２のＭＴＳ構成要素を識別し、それを注文確認ページの隠れたフィールドに示したＭＴＳと比較する。この値の有効化に成功しなかった場合、販売業者４０４は取引を断る。何故なら、ＡＡＶ８０２はおそらく不正だからである。
【００７９】
販売業者４０４は隠れたデータ４１６から許可要求メッセージ４１８を獲得し（ステップ２２２）、許可要求メッセージ４１８を決済機関４０８に追加的ネットワーク又はネットワーク部４３０を介して送る（ステップ２１２）。なぜなら、隠れたデータ４１６は、認証データ４１４を含み、許可要求メッセージ４１８は最終的には認証データ４１４から得るからである。
【００８０】
許可要求メッセージ４１８は、少なくとも以下のデータ構成要素を含むのが好ましい。
・販売業者に送る口座名義人の支払い口座番号
・販売業者名
・通貨コード
・売上高
・販売業者取引スタンプ（この構成要素が使われていない場合、販売業者４０４がデフォルト値を１６進法表記の“００００”に設定する）
状況に応じて、以下のデータ構成要素が含まれる。
・カード引受人の市
・カード引受人の州／国
【００８１】
何故なら、隠れたデータ４１６と許可要求メッセージ４１８は、機密の取引特定データを含み、それをインターネットのような公のネットワークを通じて送信してもよいので、隠れたデータ４１６と許可要求メッセージ４１８は、データが脅かされないよう、例えば、１２８ビットのＳＳＬ又はそれと同等の安全な暗号化方法を利用して保護するのが好ましい。
【００８２】
決済機関４０８は、別のネットワーク又はネットワーク部４３２を介して、許可要求メッセージ４２０を発行者４０６に送信する（ステップ２１４）。決済機関４０８から発行者４０６に送る許可要求メッセージ４２０は、一般的には販売業者４０４から決済機関４０８に送った許可要求メッセージ４１８と同じか、又はこれから獲得する。許可応答メッセージ４２２を生成するため、発行者４０６は、許可要求メッセージ４２０を処理するための照合手順２１６を利用する。
【００８３】
図６は、許可要求メッセージ４２０を生成するため、図１と図２を参照して説明した許可応答メッセージ４２２を処理するのに発行者４０６が利用する典型的な手順２１６を示している。図６に示した典型的な手順２１６は、上記のとおり暗号を使って生成したＡＡＶ８０２の利用に適し、暗号を使った照合アブローチを利用している。図示した手順２１６では、発行者４０６の操作する暗号を使ったＡＡＶ照合プロセッサ４４２が、機能によって受信した各許可要求メッセージ４２０のための以下のステップを行う。
【００８４】
安全レベルのルーティング
１．安全レベルインジケータが１という値に設定されると（ステップ６０２）、照合プロセッサ４４２は、ＵＸＡＦベースの照合システムのために、口座番号が登録されていることを照合する（ステップ６０４）。口座が登録されていれば（ステップ６０４）、プロセッサ４４２は取引を断る（ステップ６０６）。何故なら、このようなシナリオは以下の（ｉ）口座名義人が、決済取引を処理するための自分のＵＣＡＦ使用可能なソフトウェア４０２を使っていなかったから又は（２）非認証の第三者が取引を開始していたからである。
ａ）口座が、ＵＣＡＦベースで登録されてない場合（ステップ６０４）、認証要求を、従来の（即ち、非ＵＣＡＦベース）支払い処理用に構成された認証システムに転送する（ステップ６０８）。
【００８５】
２．安全レベルインジケータが２に設定されている場合、（ステップ６０２）、プロセッサ４４２は、以下のとおり、ＡＡＶ照合処理をすすめる。
【００８６】
ＡＡＶ照合
１．示されていたデータフォーマットに基づいて、ＡＡＶを許可要求メッセージから抽出し、ベース６４でデコードし、解釈する（ステップ６１０）。
【００８７】
２．ＡＡＶの鍵識別データ、そのＡＡＶ生成プロセッサインジケータ、その取引順序番号を使って、照合プロセッサ４４２は、ＭＡＣ照合に利用する暗号鍵を判別する（ステップ６１２）。
【００８８】
３．適当なＭＡＣアルゴリズムを使って、プロセッサ４４２は、ＡＡＶ８０２内でＭＡＣの照合を試みる（ステップ６１４）。ＭＡＣの照合に不成功の場合（ステップ６１６）、取引を断る（ステップ６１８）。何故なら、ＡＡＶ８０２は有効ではなく、よって取引は不正とみられるからである。
【００８９】
４．ＡＡＶの制御バイトが、これが初期認証要求であることを示している場合（ステップ６２０）、
ａ）プロセッサ４４２は、（ＡＡＶ生成プロセッサ４４０からの）同じ取引順序番号か否かチェックし、“ｎ”秒以上前に受信した前の初期認証において、売上高が既に生じている（ここでは、“ｎ”は発行者が特定し、代表的に６０とする）（ステップ６２６）。
ｉ）注：対応する許可応答メッセージが失われている場合、許可要求メッセージの自動再送のために、例えば、秒という具合に、選択的に遅延が可能である。
ｂ）取引順序番号が、“ｎ”以上秒前に受信した前の許可要求メッセージにおいて既に発生したものである場合（ステップ６２６）、そのときは、取引を断る、即ち、このＡＡＶ生成プロセッサ４４０からのこの取引順序番号は、“コピーとして検出したもの”である（ステップ６２８）。試みられた取引は、以前の有効ＡＡＶの不正な再生を含んでいる。
ｃ）取引順序番号がまだ発生していない場合（ステップ６２６）、そのときは、ＡＡＶの取引順序番号を、将来の取引に“利用する”ものとして識別する（ステップ６３２）。
ｄ）この初期認証要求のＡＡＶ８０２を照合した後、発行者４０６は、状況に応じて口座名義人の登録状況を確認でき、自動的に口座名義人を登録する（ステップ６３４）。
ｅ）ＡＡＶが有効であると確認したので、この取引の照合は成功である（ステップ６３０）。成功した照合の表示は、許可応答メッセージ４２２に含まれる。
【００９０】
５．このＡＡＶの制御バイト８０４が、これは次の認証要求であることを示している場合（ステップ６２０）、またＡＡＶの取引順序番号が、使用しているＡＡＶ生成プロセッサ４４０に対する“コピーとして検出したもの”である場合（ステップ６２２）、取引を断る（ステップ６２４）。これは、販売業者に由来する既に再生したＳＰＡ取引の再提示である。
【００９１】
６．一方、ＴＳＮがコピーとして検出したものでない場合（ステップ６２２）、ＡＡＶは有効で、それゆえに取引の照合は成功している（ステップ６３０）。照合成功の表示は、それゆえに許可応答メッセージ４２２に含まれる。
【００９２】
照合を行うため、発行者４０６のＡＡＶ照合プロセッサ４４２は、ＵＣＡＦベース認証のために登録した口座番号毎の記録を維持するのが好ましい。更に、ＡＡＶ照合プロセッサ４４２は、各ＡＡＶ生成プロセッサ４４０と共有する鍵生成のための鍵（又は複数の鍵）を格納している。また、口座番号とそれと関連したＡＡＶの不正な再生を検出するために、ＡＶＶ照合プロセッサ４４２は、どのＡＡＶを既に受信したかを示す記録を格納している。
【００９３】
また、ＡＡＶ照合は比較アプローチを利用して行える。例えば、図７に示した照合手順２１６において、ＡＡＶ照合プロセッサ４４２は、各許可要求メッセージのため以下のステップを行う。
【００９４】
１．安全レベルインジケータが“１”に設定されている場合（ステップ６０２）
ａ）プロセッサ４４２は、口座番号がＵＣＡＦベースのシステムに登録されているか否かを判別する（ステップ６０４）。口座が登録されている場合（ステップ６０４）、取引は断られる（ステップ６０６）、何故なら、このようなシナリオでは、口座名義人が決済取引を処理するための自分のＵＣＡＦの可能なソフトウェア４０２を使っていなかったこと、又は非認証の第三者がこの取引を開始したことを示しているからである。
ｂ）口座がＵＣＡＦベースで登録されていない場合（ステップ６０４）、認証要求を、従来の（即ち、非ＵＣＡＦベースの）支払い処理のための発行者の認証システムに転送する（ステップ６０８）。
【００９５】
２．安全レベルインジケータが“２”に設定されている場合（ステップ６０２）
ａ）プロセッサ４４２は、口座番号がＵＣＡＦベースのシステムに既に登録されているか否かを判別する（ステップ７０２）。登録されている場合（ステップ７０２）、発行者４０６は、認証要求からのＡＡＶを抽出し（ステップ７０６）、以下説明する更なる処理を続ける。
ｂ）口座が登録されていない場合（ステップ７０２）、この取引は断られる（ステップ７０４）。
【００９６】
３．この口座が登録されている場合（ステップ７０２）、ステップ７０６の後に、許可要求メッセージのＡＡＶ８０２は、ベース６４でデコードする（ステップ７０８）。
【００９７】
４．これが初期認証要求であることをＡＡＶのコントロールバイトが示している場合（ステップ７１０）、許可要求メッセージ４２０に含まれる取引データを有する発行者のデータベースに格納したＡＡＶ取引情報の比較に基づいて、以下のＡＡＶ手順が行われる。
ａ）認証要求中に受信したＡＡＶが、発行者のデータベースの登録に一致していることをプロセッサ４４２が認証する（ステップ７１２）。一致する登録がない場合（ステップ７１２）、取引は断られる（ステップ７１４）。
ｂ）受信したＡＡＶが、一致していることに基づいて有効であると判別した場合（ステップ７１２）、発行者の定義するデータ８１０が以前の取引において受信されていないことをプロセッサ４４２は照合し、発行者の定義するデータ８１０を“ｎ”秒以上前の以前の取引において受信している場合（ここでは、“ｎ”は代表的に６０に等しい）（ステップ７１６）、その取引は断られ、ＡＡＶ８０２はコピーとして検出されたものとなる（ステップ７１８）。
ｃ）発行者の定義するデータ構成要素を以前に受信している場合、（ステップ７１６）、そのときは、発行者の定義するデータ８０２は“利用した”となり（ステップ７２０）、発行者の定義するデータ８１０を追加的に有効化する（ステップ７２２）。
ｄ）追加的なデータの有効化は、許可要求メッセージ４２０に含まれるデータを有する販売業者隠れたフィールドから獲得したデータの比較を含むことができる（ステップ７２２）。これによって、発行者４０６は口座番号や販売業者名などの追加的なフィールドを有効化できる。データの照合に成功した場合（ステップ７２２）、このＡＡＶ８０２の照合は成功である（ステップ７２６）。照合成功の表示は、それ故に許可応答メッセージ４２２に含まれる。データが一致しない場合（ステップ７２２）、そのとき、取引は断られる（ステップ７２４）。
【００９８】
５．ＡＡＶのコントロールバイトが、これが次の認証要求であることを示す場合（ステップ７１０）、以下のステップを行う。
ａ）発行者の定義するデータ８１０が、“コピーしたものとして疑わしい”データセットである場合（ステップ７２８）、プロセッサ４４２は取引を断る（ステップ７３０）。
ｂ）発行者の定義するデータ８１０が初期認証において受信されておらず、“コピーしたものとして疑わしい”データセットでない場合（ステップ７２８）、プロセッサ４４２は、許可要求メッセージ４２０中に含まれるデータを有する販売業者の隠れたフィールドから獲得したデータを比較することによって、追加的な有効化の確認を行う（ステップ７２２）。これによって、発行者４０６は口座番号と販売業者名を有効化できる。データが一致する場合（ステップ７２２）、この照合は成功であり（ステップ７２６）、それ故に、照合成功の表示が許可応答メッセージ４２２に含まれる。
【００９９】
暗号を使った又は比較による照合アプローチが許可応答メッセージ４２２の生成に利用されたか否かに関わらず、発行者４０６は、許可応答メッセージ４２２を決済機関４０８へネットワーク又はネットワーク部４３２を介して送信する（ステップ２１８）。決済機関４０８は、許可応答メッセージ４２４を販売業者４０４へネットワーク又はネットワーク部４３０を介して送信する（ステップ２２０）。許可応答メッセージ４２２は、代表的に発行者４０６から決済機関へ送信した許可応答メッセージ４２２と同じか、又はこれから得たものである。
【０１００】
状況によっては、決済機関４０８は、発行者４０６に代わって、照合手順２１６を行うことができ、その場合、決済機関４０８は、認証メッセージ４２４を生成するための許可要求メッセージ４１８を処理する自身の照合プロセッサ４４６を含む。換言すれば、決済機関４０８は、許可応答メッセージを生成するための許可要求メッセージを処理する役割において、発行者４０６の“代理を務める”ことができる。発行者の認証システムが一時的に使用できない場合、このような“代行処理”は、特に有益である。何故なら、この“代行処理”によって、許可応答メッセージ４２２を生成するために処理する許可要求メッセージ４２０を発行者４０６へ送信する必要がなくなる、即ち、発行者４０６からの許可応答メッセージ４２２が不要になるからである。
【０１０１】
いずれにせよ、発行者４０６又は決済機関４０８が照合手順２１６を行ったか否かに関わらず、販売業者４０４が受信する許可応答メッセージ４２４が取引の承認を含む場合（図１のステップ１１８）、取引の完了を確認するために、口座名義人への領収書のページに基づいて、販売業者４０４がＨＴＭＬベースのページを提示する。このページは、顧客の問合せに利用する参照番号を含むのが好ましい。さらに、口座名義人には見えないが、完了した取引を確認するために、ユーザのソフトウェア４０２が読める隠れた取引識別フィールドを、領収書のページは提供している。このとき、商品を出荷し及び／又は、サービスを提供する（ステップ１２０）。従来の精算及び決済のいずれもが、発行者４０６と決済機関４０８間の支払いを精算し決済するのに利用できる（ステップ１２２）。
【０１０２】
図５は、本発明に関する安全な決済取引を行う別のシステムを示している。図４に示したシステムと同様に、図５に示すシステムは、ユーザのソフトウェア４０２と、販売業者４０４と、決済機関４０８と、支払い口座発行者４０６とを含んでいる。しかし、図５に示すシステムはまた、取得者５１４も含んでいる。取得者５１４は、一般的には販売業者４０４の口座の取得銀行である。発行者４０６から、ユーザのソフトウェア４０２、販売業者４０４、取得者５１４、決済機関４０８に至り発行者４０６に戻るループを巡るデータ中に、認証データ４１４は含まれる。そこでは、発行者が、認証データ４１４が不正に改ざんされていないかあるいは不法に変更されていないかを確認する。図４に示したシステムと同様に、図５に示すこのシステムは、図１に示した手順に従って動作する。しかし、図５に示すこのシステムにと関連して利用する支払い手順１０６は、以下更に詳しく述べるように、認証データ４１４と他のデータ／メッセージが巡るループ中の取得者５１４を含む。
【０１０３】
図３は、図５に示したシステムに利用する典型的な支払い手順１０６を示している。図示した手順１０６において、販売業者４０４からの商品及び／又はサービスの購入を行う口座名義人の身元を認証するための要求４１２を、ユーザのソフトウェア４０２がネットワーク部４２８を介して発行者４０６へ送信する（ステップ２０２）。認証のための要求４１２に応答して、発行者４０６は、ネットワーク部４２８を介して認証データ４１４を送信し、認証データ４１４をユーザのソフトウェア４０２が受信する（ステップ２０４）。ユーザのソフトウェア４０２は、隠れたデータ４１６中の認証データ４１４を含み（ステップ２０６）、販売業者４０４のウェブページ中の隠れたフィールドを満たすための隠れたデータ４１６を利用する（ステップ２０８）。図２に示す手順について述べたように、ユーザのソフトウェア４０２が、隠れたデータ４１６を販売業者４０４へネットワーク部４２６を介して送信する（ステップ２１０）。販売業者４０４が許可要求メッセージ５０６を認証データ４１６から得て（ステップ２２２）、許可要求メッセージ５０６を取得者５１４へ別のネットワーク又はネットワーク部５０２を介して送信する（ステップ３０２）。取得者５１４は、許可要求メッセージ５０８を決済機関４０８へさらに別のネットワーク又はネットワーク部５０４を介して送信する（ステップ３０４）。取得者５１４から決済機関４０８へ送信した許可要求メッセージ５０８は、一般的には、販売業者４０４から取得者５１４へ送信したメッセージ５０６と同じか、このメッセージ５０６から得る。決済機関は、許可要求メッセージ４２０を発行者４０６へネットワーク又はネットワーク部４３２を介して送信する（ステップ３０６）。決済機関４０８から発行者４０６へ送信した許可要求メッセージ４２０は、販売業者４０４から取得者５１４へ送信したメッセージ５０６と同じか又はこのメッセージ５０６から得ることができ、及び／又は、取得者５１４から決済機関４０８へ送信したメッセージ５０８と同じか又はこのメッセージ５０８から得ることができる。許可応答メッセージ４２２を生成するために、発行者４０６は、決済機関４０８から受信した許可要求メッセージ４２０を処理する照合手順２１６を利用する。発行者４０６は、許可応答メッセージ４２２を決済機関４０８へネットワーク又はネットワーク部４３２を介して送信する（ステップ３０８）。決済機関４０８は、許可応答メッセージ５１０を取得者５１４へネットワーク又はネットワーク部５０４を介して送信する（ステップ３１０）。決済機関４０８から取得者５１４へ送信した許可応答メッセージ５１０は、一般的には、発行者４０６から決済機関４０８へ送信したメッセージ４２２と同じか、このメッセージ４２２から得る。
【０１０４】
状況によっては、図４で示したシステムについての説明のように、決済機関４０８は、発行者４０６の代わりに任意に、照合手順２１６を行える。このような代行処理は、決済機関４０８が行い、この場合、決済機関４０８は、許可応答メッセージ５１０を生成するための許可要求メッセージ５０８を処理する。
【０１０５】
いずれせよ、発行者４０６又は決済機関４０８が照合手順２１６を行ったか否かに関わらず、取得者５１４は、許可応答メッセージ５１２を販売業者４０４へネットワーク又はネットワーク部５０２を介して送信する（ステップ３１２）。取得者５１４から販売業者４０４へ送信した許可応答メッセージ５１２は、発行者４０６から決済機関４０８へ送信したメッセージ４２２と同じかこのメッセージ４２２から得ることができ、及び／又は、決済機関４０８から取得者５１４へ送信したメッセージ５１０と同じかこのメッセージ５１０から得ることができる。
【０１０６】
ユーザのソフトウェア４０２をＡＡＶベースの取引に利用するためにダウンロードする前に、口座名義人は発行者４０６を登録するのが好ましい。
【０１０７】
登録処理は、以下の有益な特徴を提供する。
・口座名義人を強力に認証する
・発行者４０６とともに口座名義人を登録する
・口座名義人のコンピュータへユーザのソフトウェア４０２をダウンロードする。
【０１０８】
ユーザのソフトウェア４０２を得るために、口座名義人はまず、発行者のオンラインバンキングのウェブサイトへアクセスする。この発行者のオンラインバンキングのウェブサイトは、発行者のウェブサーバ４４４からアクセスできる。口座名義人が既に発行者のオンラインバンキングサイトに登録されている場合、口座名義人は自分の既存のアクセス資格を利用してログする。この資格は、従来のオンラインバンキング口座名義人の認証方法のいずれを利用しても照合できる。
【０１０９】
発行者のオンラインバンキングサイトへのアクセスのために、口座名義人がまだ登録されていない場合、発行者４０６は、ユーザのソフトウェア４０２を得る前に口座名義人に登録を要求する。ユーザのソフトウェア４０２を使って行う次の取引の安全性を確保するために、登録前又は登録中に、発行者４０６が強力に口座名義人の身元を認証するのが好ましい。口座名義人の認証に成功すれば、登録処理は、口座名義人のプロファイルの開始へすすむ。口座名義人は、ユーザのソフトウェア４０２の登録継続の選択肢と共に提示される。登録の選択継続を選択すると、口座名義人のウェブブラウザをユーザのソフトウェア登録ページに案内する。このページは、ソフトウェア４０２へ登録可能な口座のリストと共に、口座名義人を提示し、口座名義人のプロファイルを発行者の照合プロセッサ４４２内に設けるために口座名義人からの様々な情報を要求する。この情報は、少なくとも以下を含むのが好ましい。
【０１１０】
・口座番号
・口座満期日
・口座ＣＶＣ２照合値
【０１１１】
以下の追加的情報は、プロファイルの開始中に収集できる。
・口座名義人名
・口座名義人請求先住所
・口座名義人出荷先住所
【０１１２】
状況によっては、発行者４０６は、発行者のオンラインバンキングサイトから利用できる口座名義人情報に基づいて、プロファイルの設置を自動的に行える。この処理のいくつか又は全てを自動化することによって、この情報の再入力を口座名義人に要求することを回避でき、その結果、口座名義人に便利な登録技術を提供できる。
【０１１３】
口座名義人から又は自動化したインターフェースから集めたデータを、口座名義人の登録要求の一部として、発行者の照合プロセッサ４４２へ送信する。照合プロセッサ４４２を発行者の外部にある機関が操作するシステムのために、この要求とその結果である応答は、機関間の送信中に、十分に保護すべきである。例えば、これらのメッセージを保護した私的ネットワーク結合を介して送信するか、インターネットのような公的ネットワークを介した送信前にメッセージを暗号化することによって、要求と応答の安全性を確保できる。発行者の照合プロセッサ４４２は登録要求を処理し、以下（ａ）か（ｂ）のどちらによって応答する。
【０１１４】
（ａ）登録が成功して終了したことを確認する、又は（ｂ）失敗した登録を、その失敗の理由を記載したメッセージに沿って示す。
【０１１５】
発行者は、オンライン上に登録した口座名義人が正しく認識・確認されたことを保証する強力な認証装置を選択すべきである。発行者が登録処理を実行する場合、認証目的に利用できる共有する秘密を認識する際には以下のガイドライン／選択を維持すべきである。
【０１１６】
・ただ１つよりは複数の情報を、共有する秘密に利用すべきである。例えば、口座名義人の母親の旧姓と彼（彼女）の社会保障番号の最後の４桁を、発行者の生成するパスワードと結合して利用できる。
【０１１７】
・共有する秘密は、確認可能なものにすべきである。例えば、口座名義人の母親の旧姓を使う場合、認証システムをこの情報を確認できるものにすべきである。
【０１１８】
・共有する秘密全ての認識には、複数の出所へのアクセスを必要とすべきである。１つの文書内及び／又は公的情報から完全に利用できる共有の秘密を使うのは避けるのが好ましい。例えば、発行者４０６は使用限度額と住所情報を利用することを利用すべきであり、この共有の秘密の両方とも、口座名義人の毎月の預金取引明細書上で利用できる。この明細書が盗み見られた場合、この共有の秘密は脅かされる。
【０１１９】
・発行者４０６は、状況によって、共有の秘密を判別するためのいくつかの情報を利用できる。例えば、以下の情報が利用できる。
【０１２０】
・明細とは別にした、メーラー中の口座名義人の請求先の住所へ送った銀行の生成したパスワード
・カードの署名パネル上のみ利用可能なＣＶＣ２
・口座名義人の社会保障番号の最後の４桁のような、確認可能な非公的番号。
・口座での使用限度額（毎月の預金取引明細書上で利用可能）
登録の成功後、口座名義人は、ユーザのソフトウェア４０２を彼（女）のアクセスデバイス〜代表的には、コンピュータ、ＰＤＡ、あるいは携帯電話など〜のダウンロードとインストールができる。口座名義人が販売業者の購入ページへ案内される際、ユーザのソフトウェア４０２を自動的に起動するために、口座名義人のアクセスデバイスは、装置の開始／代理手続の一部分としてユーザのソフトウェア４０２が操作されるように構成されるのが好ましい。
【０１２１】
起動と表示の際、購入取引中に口座名義人の身元を認証するために、ユーザのソフトウェア４０２は、口座名義人のアクセス資格を要求する。このアクセス資格は、一般的には発行者４０２が管理し、以下のいくつか又は全てを含むのが好ましい。
・ユーザｉｄ／パスワード
・スマートカード／ＰＩＮ
・解除したパスワードの残高の機密事項
・生物学的測定による照合
・電子証明書
・他の安全な発行者の承認した認証機構
【０１２２】
カード保持者の安全性を最大限に確保し、カード保持者の強力な認証を発行者に供与するために、認証は、各取引に対し発行者の照合プロセッサ４４２を通じて行うのが好ましい。
【０１２３】
状況によって、発行者４０６は、ＡＡＶ生成と口座名義人取引を追跡するデータの格納を選択できる。ＡＡＶ、カードの市、カードの州／国、ブランドを含むＡＡＶ生成の履歴の追跡は、議論による管理と料金返還処理の支援において、発行者４０６への助けとなりうる。更に、発行者４０６は、その認証結果の記録と取引における口座名義人の確認に基づいて、口座名義人への拒否をためすことができる。そのような拒否は、主として、各取引に関連したＡＡＶ、カードの市、カードの州／国、ブランドに基づいて行われる。発行者４０６は、売上げ履歴を口座名義人へのオンラインで利用可能とすることを選択でき、その結果、顧客サービスの問合せの数を減らすことができる。
【０１２４】
分割発送を含む購入の場合、販売業者４０４は、各発送に対する認証を要求し獲得するのが好ましい。分割発送による次の認証を行う場合、販売業者４０４は、初期認証ＡＡＶ８０２に含まれる制御バイト８０４を６進法表記の“８２”から６進法表記の“０２”へ変える。次の認証のための制御バイト８０４の変更に失敗すると、発行者４０６は認証を断ることになる。
【０１２５】
初期発行者の拒否の後、販売業者４０４は、認証要求の再送を希望してもよい。その場合、６進法表記の“８２”から“０２”まで変更した制御バイト８０４と共に、ＡＡＶ８０２を次の認証として送信する。
【０１２６】
いくつかのケースにおいては、所与の取引のために、元の要求中のＡＡＶと同じ値を有するＡＡＶを持った第二の認証要求を、販売業者４０４が生成してもよい。第二の認証要求は、ビットのような元の要求と一致している。例えば、要求は、異なるシステムの形跡のＩＤ番号を有することもある。一般的には、販売業者４０４は、以下の場合に第二の認証要求を生成してもよい。
・販売業者４０４が、所定のタイムアウト期間内の元の認証要求への応答を受信しない、又は、
・販売業者４０４は元の認証を完全に取消すが、後に元に戻すよう判別する。
【０１２７】
販売業者４０４は、制御バイト８０４の最上位ビットを読み取って、そのような認証要求を次の認証要求として取り扱うのが好ましい。これによって、そのような要求を発行者４０６が起こりうる再攻撃として誤って拒否する。
【０１２８】
図１から図７で説明した適正なソフトウェアの制御の下で動作する様々な標準的コンピュータブラットフォーム上で、図１から図７の方法を実行できることは、当業者によって明らかになるであろう。場合によっては、従来のパーソナルコンピュータ中の周辺カードのような、専用のコンピュータハードウェアが上記方法の操作上の効率を高めることができる。
【０１２９】
図９と図１０は、本発明の実用化に適した代表的なコンピュータハードウェアを示す。図９を参照すると、このコンピュータシステムは、処理部９１０と、ディスプレイ９２０、キーボード９３０と、モデムのような周辺通信デバイス９４０とを含む。このシステムは、またプリンタ９６０も含む。
【０１３０】
一般的には、磁気メディアのような（即ち、ディスケット）のようなコンピュータで読み取り可能なメディア及び／又は光学メディア（例えば、ＣＤ−ＲＯＭ又はＤＶＤ）へ読込み及び書込みができる、データとアプリケーションソフトウェアを格納する１つ以上のディスクドライブ９７０をこのコンピュータシステムは含む。図示はしていないが、デジタルポインタ（例えば、“マウス”）などの他の入力デバイスも含まれる。図９と図１０に示したコンピュータハードウェアは、図４と図５の示したユーザのソフトウェア４０２を動作するのに利用でき及び／又は販売業者４０４、販売業者のサーバ４４８、取得者５１４、支払い及び／又は決済機関４０８、照合プロセッサ４４６、発行者４０６、ＡＡＶ生成プロセッサ４４０、照合プロセッサ４４２、及び／又は発行者のサーバ４４４の機能を実行するのに利用できる。
【０１３１】
図１０は、更に処理部９１０を説明する機能的ブロック図である。処理部９１０は、通常、処理部１０１０と、制御ロジック１０２０と、メモリユニット１０３０とを備える。処理部９１０は、また、タイマ１０５０と、入出力ポート１０４０を備えることが好ましい。処理部９１０は、また、処理部で利用するマイクロプロセッサによっては、共通プロセッサ１０６０を含む。制御ロジック１０２０は、処理部１０１０と協力して、メモリユニット１０３０と入出力ポート１０４０間の通信を扱うのに必要な制御を行う。タイマ１０５０は、処理部１０１０と制御ロジック１０２０のためのタイミング参照信号を供給する。共通プロセッサ１０６０は、暗号アルゴリズムが必要とするような複合的な計算をリアルタイムに行う能力を拡張する。
【０１３２】
メモリユニット１０３０は、揮発性及び非揮発性のメモリやＲＯＭのような異なる種類のメモリを含む。例えば、図１０に示すように、メモリユニット１０３０は、ＲＯＭ１０３１と、ＥＥＰＲＯＭ１０３２と、ＲＡＭ１０３３とを含む。本発明の実用化に、異なるコンピュータプロセッサ、メモリ構成、データ構成等を利用でき、また本発明は、特定のプラットフォームに制限されない。例えば、処理部９１０は、図９と図１０にコンピュータシステムの一部として示されているが、処理部９１０及び／又はこの構成要素は、ＰＤＡ又は携帯電話組み入れることができる。
【０１３３】
本発明は具体的な実施例と連結して説明してきたが、添付した請求項に記載した発明の主旨や範囲を逸脱しない範囲内において様々な変形や代用が可能であることは、当業者にとっては明らかである。
【図面の簡単な説明】
【０１３４】
【図１】本発明の決済取引を行う典型的手順を説明するためのフロー図である。
【図２】図１で説明した手順で利用するひとつの典型的支払い手順を説明するためのフロー図である。
【図３】図１で説明した手順で利用する別の典型的支払い手順を説明するためのフロー図である。
【図４】本発明の決済取引を行うひとつの典型的システムを説明するためのブロック図である。
【図５】本発明の決済取引を行う別の典型的システムを説明するためのブロック図である。
【図６】図２と図３で示した手順で利用するひとつの典型的な許可要求メッセージ照合手順を説明するためのフロー図である。
【図７】図２と図３で示した手順で利用する別の典型的な許可要求メッセージ照合手順を説明するためのフロー図である。
【図８】本発明の典型的な口座名義人認証値（ＡＡＶ）を説明するためのブロック図である。
【図９】本発明の決済取引を行う典型的なコンピュータシステムを説明するための図である。
【図１０】図９で示したコンピュータシステムで利用する典型的処理部を説明する[Cross-reference to related applications]
[0001]
This application is hereby incorporated by reference into U.S. patent application Ser. No. 09-963,274, filed Sep. 26, 2001, entitled "General Cardholder Authentication Field (UCAF) for Authentication Data Collection and Validation." Application for Common Interoperability System and Method Utilizing "". This application claims priority to the following additional applications. All of the additional applications are included by reference and are as follows. US Provisional Patent Application 60-280,776, filed April 1, 2001, entitled "System and Method for Secure Payment Application (SPA) and General Cardholder Authentication Field (UCAF)," filed June 4, 2001. U.S. Provisional Patent Application No. 60-295,630, entitled "Methods and Processes for Secure Payment Applications Utilizing General Cardholder Authentication Fields," U.S. Provisional Patent Application No. 60-307,575, filed July 24, 2001. No. 09-886,486, filed Jun. 22, 2001, entitled "No Pseudo or Proxy Account Number." Methods and Systems for Making Secure Payments Through Computer Networks ", June 2001 2 filed U.S. Patent Application No. 09-886,485 "Method and system for secure payment via the computer network".
【Technical field】
[0002]
Online shopping is becoming ever easier and more convenient for consumers, while reducing costs and acquiring new consumers for merchants. However, many consumers are afraid of stealing sensitive information, such as credit numbers, and are not willing to take advantage of these benefits. Efforts are being made to increase the security of such information. For example, secure socket layer (SSL) technology encrypts messages sent between consumers and merchants to prevent third parties from intercepting and using information. However, this method does not allow the merchant to verify the identity of the consumer. As a result, if the third party attempts to obtain the credit card number by other fraudulent means such as physical credit card theft, the SSL method does not allow the third party to illegally use the stolen information.
[0003]
Secure Electronics Transaction (registered trademark) technology attempts to solve this problem using digital certificates that authenticate consumers / cardholders, merchants, and credit card issuers. Each certificate is issued by a contracted certification body. Currently, SET® is the most secure way to handle payments on the Internet, but requires the installation of digital certificates and encryption software on the cardholder's computer.
DISCLOSURE OF THE INVENTION
[0004]
Accordingly, it is an object of the present invention to provide a payment system that allows a customer to shop online without threatening confidential information such as the customer's account number.
[0005]
It is another object of the present invention to provide a payment system that authenticates a customer's identity without issuing numerous digital certificates.
[0006]
Yet another object of the present invention is to maintain the security of information without the need for consumers to download large software files and without the need for intensive praise that would slow down the consumer's computer speed. It is to provide a payment system that can authenticate the identity of consumers online.
[0007]
These and other objects are achieved by the following aspects of the present invention.
[0008]
According to one aspect of the invention, a user's software receives a set of web page data for use in displaying a web page. The user's software determines whether the web page contains one or more hidden fields. If the web page contains hidden fields, the user's software selects the first payment procedure to be performed. To send the hidden data to the merchant, a first payment procedure involves filling the hidden fields with the hidden data. If the web page does not contain hidden fields, the user's software selects a second payment procedure to perform. To send the purchase data to the merchant, a second payment procedure involves filling one or more visible fields of the web page with the purchase data.
[0009]
According to another aspect of the invention, the user's software receives a set of web page data for use in displaying a web page that includes one or more hidden fields. The user's software receives authentication data from the payment account issuer that authenticates the account holder's identity of the payment account issued by the payment account issuer. To send the authentication data to the merchant, the user's software fills the hidden fields with the authentication data.
[0010]
According to another aspect of the invention, the user's software receives a first set of web page data for use in displaying on a first web page. The user's software determines whether the first web page includes the first hidden field. The first hidden field indicates that the web page is available for performing a one click payment procedure. The user's software fills the first hidden field with data to notify the merchant that the user's software will be used to perform at least one payment transaction.
BEST MODE FOR CARRYING OUT THE INVENTION
[0011]
FIG. 4 illustrates an exemplary system for conducting secure payment transactions of the present invention. The system includes a user's software 402, a merchant 404 selling goods and / or services, a clearing house 408, such as a MasterCard® clearing house, and a payment account issuer 406. The user's software 402 runs on the access device operated by the purchaser, ie, the purchaser who is the user of the software 402. The access device may be, for example, a computer, a personal digital assistant (PDA), or a mobile phone. The access device preferably runs on a web browser in addition to or as part of the user's software 402.
[0012]
Preferably, the web browser supports addressing based on the names of the fields on the web page, so that many merchants and account holders can identify hidden and visible fields using a common name. Generally, issuer 406 is a bank that issues a purchaser with a credit card or other payment account from a merchant for purchasing goods and / or services. The buyer is the account holder of the bank account. The system utilizes the authentication data 414, beginning with the issuer 406, and effectively going through a loop back to the user's software 402, merchant 404, clearing house 408, and back to the issuer 406, as described in more detail below. ing. It is assumed that the data 420 received by the issuer 406 should be obtained from the original authentication data 414, and that no unauthorized operation has been performed on the authentication data 414 during the loop. Therefore, the issuer 406 can authenticate the account holder's identity based on the authentication data 414 and the data 420 received from the clearing house 408, and can verify the authenticity of the transaction.
[0013]
FIG. 8 shows an example of a data structure 802 referred to here as an authentication value (AAV) of an account holder that can be used as the authentication data 414 shown in FIG. The AAV 802 is composed of 24 bytes of binary data representing 32 64 encoding base characters. The first 14 bytes 808 can typically represent system data and include a control byte 804 and other system data 806. The remaining 10 bytes 810 of the data are defined by the issuer 406. Control byte 804 provides information regarding the type of authentication to be performed. For example, control byte 804 includes a hexadecimal value of "82" for initial or pre-authentication of the account holder, followed by a "02" value for authentication of the account holder. Additional authentication approaches are assigned by their own control byte values. For example, metric biology based authentication procedures have their own value for control byte 804. Table I shows the various parts of AAV802.
[0014]
Table I

[0015]
Table I shows the data component numbers. Data component number 1, the control byte 804, is set to the hexadecimal notation "82" for all AAVs associated with the initial authentication, indicating pre-authentication. The components 2 to 6 are system data 806, and are specific contents of the transaction provided on the website of the seller. The component number 7 is composed of data 810 defined by the issuer. This component contains data that links the account holder to a particular transaction.
[0016]
The AAV generation processor 440 operated by the issuer 406 generates system data 806 of the AAV 802 and data 810 defined by the issuer, and links them to a special payment out. When receiving the request 412 for authentication of the account holder's identity, the AAV generation processor 440 generates system data 806 and data 810 defined by the issuer in a binary format. To create a 24-byte binary version of AAV 802, two sets of

data

806 and 810 are combined, as well as control byte 804. The encoding of a base 64 of a 24-byte binary data version produces a base 64 version of AAV802 that is 32 characters.
[0017]
The system data 806 is generated based on the information provided from the control byte 804 and the confirmation page of the seller. The data 806 is generated according to the following procedure.
[0018]
1. Control bytes 804 are generated for AAV 802. The control byte 804 may be, for example, a binary coded digit display of “82.” which is a hexadecimal display value.
[0019]
2. Sales are generated by the following steps.
a) Delete up to 8 following zero from sales.
b) The first four digits of the remaining sales are placed in the sales field as four binary coded digits.
[0020]
3. The number of digits at the right end of the sales amount truncated in step 2b is determined. This number is a single, binary coded digit and is placed in the Sales Truncation field.
[0021]
The 4.3-digit currency code is converted into binary data, the remaining 10 bits are right-aligned in a 12-bit field, and binary data "00."
[0022]
5. The vendor name is indicated by a set of Unicode control values in hexadecimal notation and is edited using the following rules. The distributor name may be represented as Latin letter 1, but all other letters need not be edited.
a) Delete all Latin 1 control characters. This is a Unicode character in the hexadecimal notation range from 0000 to 001F and 007F to 009F.
b) "&" (0026 in hexadecimal notation), "$" (0040 in hexadecimal notation), "1/4" (00BC in hexadecimal notation), and "1/2" (16 Except for 008D in hexadecimal notation and "3/4" (00BE in hexadecimal notation), the remaining non-alphabetic characters of Latin 1 are replaced with space characters (0020 in hexadecimal notation). Unicode non-control characters and non-alphabet characters are in the set 0021-002F, 003A-0040, 005B-0060, 0007B-0007E, 00A0-00BF, 00D7, and 00F7.
c) Replace any character in the regular exact character set (2000 to 206F) with the space character (0020).
d) Since only the first three digits in the name of the seller are included, any digits of Latin 1 from (0030) to (0039) exceeding the third digit are deleted.
e) After completing the previous steps (a) to (d), replace all consecutive space characters (0020) with one space character (0020).
f) After completing all the previous steps, delete all space characters before and after.
[0023]
6. A hash of the edited (or unedited) merchant name SHA-1 is generated and used to fill data component 5 in Table I.
[0024]
7. The MTS from the distributor's payment screen is inserted into the filed MTS as a binary code digit.
[0025]
The 14-byte binarized value that is the processing result is system data 806 to be combined with the data 810 defined by the issuer and the base 64 encoded to generate the AAV 802.
[0026]
The procedure used to generate data 810 defined by the issuer ultimately depends on which approach is used for AAV 802 verification. For example, in a cryptographic approach, issuer-defined data 810 is generated by encrypting a number, text string, or other data of the publisher 406's choice. For example, the data to be encrypted may be a series of data including a merchant name, a transaction amount, a date, and an account number of an account used for purchase. To generate a message authentication code (MAC), the data is encrypted using a secret key, described in more detail below. Preferably, the MAC is generated using an ISO certified encryption algorithm. The MAC is included in issuer-defined data 810 that combines with the

system data components

804 and 806 from the AAV 802. During authentication, the publisher 406 cryptographically verifies the publisher-defined data element 810 for authenticity verification. The cryptographic approach generates AAV 802 with one function and verifies it with another, and the two functions are particularly useful in systems that are not real-time communications. For this cryptographic approach, issuer-defined data 810 in AAV 802 includes the data components listed in Table II.
[0027]
Table II

[0028]
Since the data 810 defined by the issuer is limited to 10 binary bytes, only the location of each of the above data components need be included. Data 810 preferably includes four bytes of MAC, four bytes of transaction sequence number, one byte of key indication data, and one byte of the combined total amount of AAV format indicator and AAV generation processor indicator.
[0029]
The MAC checks whether there is any unauthorized tampering with the encryption. Both the AAV generation processor 440 and the AAV verification processor 442 used for transaction verification have access to the secret key used for MAC generation.
[0030]
AAV generation processor 440 performs the following steps for each transaction.
[0031]
1. The following AAV data components are generated.
AAV format number, AAV generation function indicator, key display data
[0032]
2. The transaction sequence number used in the previous AAV is increased by a predetermined amount selected by the issuer 406. One or more bits of the rightmost bit of the increment are used as the data component of the AAV transaction sequence number.
[0033]
3. Using the key indicated by the key display data, the following data is concatenated and encrypted to generate a MAC. That is, the data are (1) the account number provided to the seller, (2) all AAVs except for the MAC subfield itself, and (3) data selected by other issuers. The location at the left end of the MAC calculated using the encryption is issued as an AAV / MAC data component.
[0034]
In the cryptographic approach, the AAV verification processor 442 determines the secret encryption key used by the AAV generation processor 440 to generate a MAC. The two

processors

440 and 442 preferably share a key to generate a secret encryption key. Many (hundreds, thousands, or even millions) of MAC-generated keys are derived from the shared key. Although keys for key generation are available for many years, it is preferred that the MAC generation key be changed relatively frequently, depending on the requirements of the MAC generation algorithm and the issuer's key management policy. In any case, if you suspect that the key for key generation has been compromised, you should change that key.
[0035]
Under a plurality of controls (preferably three controls), the AAV matching processor 442 generates a key for the shared key generation using the divided knowledge and generates one or more key components. Carry to AAV generation processor 440. The generation and distribution of cryptographic keys should conform to ISO security standards. Similarly, a mechanism for obtaining a MAC generation key from a key for key generation should conform to the ISO security standard. Further, preferably, any cryptographic keys stored on a storage medium coupled to the AAV generation processor 440 or the AAV verification processor 442 are present only in physically secure hardware that protects the keys from physical threats according to ISO standards. .
[0036]
When the AAV verification processor receives an AAV from one or more AAV generation processors, any encryption keys shared by the verification processor with the AAV generation processor should be related to any keys shared with other AAV generation processors. is not.
[0037]
The following is an example of generation using AAV encryption for initial transaction.
Initial certification transaction example data:
Control byte value: 82
Sales: $ 87654.32
Pass code: 840
Merchant name (Unicode designation of SPAMerchant, Inc.):
0053 0050 0041 0020 004D 0065 0072
0063 0068 0061 006E 0074 002C 0020 0049 006E 0063 002E
MTS: FOB
Issuer-defined data: 553909000040048641234
SHA-1 hash of the seller name (after editing above) = 31 98 BE 30 IF BD 74 OF E2 AD 7E D2 ED 82 9E 69 06 EC E36F
Results for 24 binary byte sources:
82 87 65 38 40 31 98 BE 30 1F BD 74 F0 AB 55 39 09 00 40 04 86 47 12 34
Convert to a 32 character base 64 coded sequence:
GodIOEAxmL4wH7108KtVOQkAQASHRxI0
[0038]
The details of this example are as follows.
Map: AAAAAAAABBBBBBBBBBBBBBBBBBBCCCDDDDDDDDDDDDD
Source: 0287653840
Binary: 100000101000011101100101001110000000000
6 bits:
Word: 00 40 29 37 14 04
Base 64: Aodl0E
map:
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEFFFFFFFFFFFFFFFF
Source: 3198BEE310FDB74F0AB
Binary:
00110001100110001011111000110000000011111110111101011101001111000010101011
6 bits:
Word: 00 49 38 11 56 48 07 59 53 52 52 60
Base 64: AxmL4WH710K
Map: GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
Source: 5539090040
Binary: 01010101001110010000100100000000000000000
6 bits:
Word: 45 21 14 16 36 00 16
Base 64: tV0QkAQ
Map: GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
Source: 0 4 8 6 4 7 1 2 3 4
Binary: 0000010010000110010001110001001000110100
6 bits:
Word: 00 18 07 17 49 08 52
Base 64: ASHRxI0
result:
24-byte source: 82 87 65 38 40 31 98 BE 30 IF BD 74F0 AB 55 39 09 00 40 04 86 47 12 34
Convert to 32 character base 64 coded sequence: godlOEAxmL4wH7108KtVOQkAQASHRxI0
[0039]
The following is an example of AAV generation for the next transaction using cryptography.
Date of the following transaction example:
Control byte value: 82
Sales: $ 87654.32
Currency code: 840
Merchant name (Unicode designation of SPAMerchant, Inc.):
0053 0050 0041 0020 004D 0065 0072
0063 0068 0061 006E 0074 002C 0020
0049 006E 0063 002E
MTS: FOAB
Issuer-defined data: 553909000040048641234
SHA-1 hash of the seller name (after editing above) = 31 98 BE 30 IF BD 74 OF E2 AD 7E D2 ED 82 9E 69 06 EC E36F
Results for a source of 24 binary bytes:
02 87 65 38 40 31 98 BE 30 IF BD 74 F0 AB 55 39 09 00 40 04 86 47 12 34
Convert to a 32 character base 64 coded sequence:
AodIOEAxmL4wH7108KtVOQkAQASHRI0
Details of this example are as follows.
Map: AAAAAAAABBBBBBBBBBBBBBBBBBBCCCDDDDDDDDDDDDD
Source: 828763840
Binary: 100000101000011101100101001110000000000
6 bits:
Word: 32 40 29 37 14 04
Base 64: good1OE
Map: EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEFFFFFFFF
Source: 3198BE301FBD74F0AB
Binary: 001100011001100010111110001100000001111110111101011101001001111000010101011
6 bits:
Words: 00 49 38 11 56 48 07 59 53 53 52 60 10
Base 64: AxmL4WH710K
Map: GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
Source: 5539090040
Binary: 010101010011100100000100100009000010000000
6 bits:
Word: 45 21 14 16 36 00 16
Base 64: tVOQkAQ
Map: GGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGGG
Source: 0486471234
Binary: 0000010010000110010001110001001000110100
6 bits:
Word: 00 18 07 17 49 08 52
Base 64: ASHRxI0
result:
24-byte source: 82 87 65 38 40 31 98 BE 30 IF BD 74F0 AB 55 39 09 00 40 04 86 47 12 34
Convert to 32 character base 64 coded sequence: GodIOEAxmL4wH7I08KtVOQkAQASHRxI0
Map legend:
A-Control byte value expressed as binary code digits (BCD)
B—Sales—Four most significant digits expressed as BCD
C—Sales truncated field—one digit expressed as BCD
D-Currency code-3 digits expressed in binary
E—Hash of SHA-1 of merchant name—First 7 bytes of SHA-1 hash value
F-MTS-2 byte value
Publisher-defined data expressed as G-BCD, 10 bytes
[0040]
The comparison approach is suitable for systems where the AAV generation and matching functions communicate with each other in real time, such as via a common data storage system. In the comparison approach, a random value or other algorithm of the publisher 406 is used to generate publisher-defined data 810. The resulting value 810 is combined with the system data 806 to / from the AAV 802. In that case, the AAV 802 is stored in a common database used by the AAV matching processor 442 for matching the transaction authenticity. During verification, issuer 406 verifies the authenticity of the transaction by comparing the received AAV of authentication request 420 with the AAV stored in the database. The AAV for the comparison approach is generated and stored according to the following procedure.
[0041]
1. Data 810 defined by the issuer is generated according to the issuer definition, for example, a random number generator.
[0042]
2. Issuer-defined data 810 is stored in a database that is linked to at least a particular account number.
[0043]
3. The merchant's hidden field data is stored in a database that is linked to at least publisher-defined data 810.
[0044]
4. The database is made available to the AAV matching processor 442.
[0045]
5. The data component 810 defined by the issuer is combined with the system data component 808 to / from a 24-byte binary value. The 24-byte binarization value is coded at base 64 to generate 32 characters 702.
[0046]
FIG. 1 illustrates a typical procedure for operating the payment transaction system shown in FIG. 4 using the authentication data 414 containing the AAV 802. In the procedure shown in the figure, the account holder views various pages of the website available on the server 448 operated by the seller 404 (step 132). The buyer finds and selects the goods and / or services that he / she wants to purchase from merchant 404 (step 114). Upon selecting the goods and / or services, the account holder initiates the merchant checkout procedure (step 116). For example, in a commonly used "shopping cart" method, the shopper selects a virtual shopping cart, i.e., goods and / or services to place on a list of items that the shopper tentatively wishes to purchase. Once the shopper is completely satisfied with the list of items, the shopper pays by clicking on the visible “Checkout” button on the merchant's web page at which point to initiate the checkout procedure for the shopping cart item To start. Another possible method utilizes a one-click checkout procedure. In the settlement procedure by one click, the merchant 404 stores the information of the account holder and uses the information for many transactions. The stored information includes the account holder's billing and shipping addresses, email addresses, account numbers, and account expiration dates. In that case, by clicking the visible "buy" button associated with the item, the account holder can immediately begin paying for the item (step 116).
[0047]
If the merchant's website is configured to be purchased with a single click according to the pervasive standards of publisher 406, then each merchant's web page that can be purchased with a single click will be labeled "UCAF-enabled" It contains certain hidden fields that can be called "indicator fields". This particular hidden field will be described in detail later. The presence of this hidden field on the web page informs the user's software that the web page is configured for one-click shopping.
[0048]
When the checkout phase is initiated (step 116), if the UCAF availability indicator field is not present on the web page (step 128), the user's software 402 will network new web page data 410 from the merchant 404. The request / reception is made via the location 426 at 434 (step 102). The network 434 may be, for example, the Internet. The web page data is used to display an "checkout" web page (also known as an "order confirmation" web page) on the account holder's computer screen. The account holder and / or user software 402 may enter some or all of this information into fields on the confirmation page to provide the billing address, shipping address, and / or payment account details to the merchant 404. (Step 130). Billing and shipping address information may be entered manually by the account holder, automatically filled by the user's software 402, or automatically based on information stored on the merchant's server for the particular account holder. Meet. To confirm the order, the account holder clicks the "Submit" button on the visible confirmation page (step 132). If merchant 404's website is configured to operate using authentication data 414 as described above, the merchant's order confirmation page includes one or more of the following hidden fields.
[0049]
(1) Hidden fields that deliver information to the user's software 402; (2) Hidden fields that receive AAV-like information from the user's software 402. These hidden fields are collectively referred to herein as the "General Cardholder Authentication Field (UCAF)", which is described in more detail below. Via the UCAF on the confirmation page, the user's software 402 receives some or all of the following information.
[0050]
Table III

[0051]
Specific values for these hidden fields included in the merchant's order confirmation page are given below. Specific values are based on the transaction details below.
Distributor name: SPAMerchant, Inc.
Seller Location: New York
Transaction volume: US $ 87654.32
Fields owned by the seller:
<INPUTtype = “HIDDEN” name = “Ucaf_Merchant_Name” value = ”0053005000410020004D006550020072006300680061006E00740002C00200049006E0063002E”>
<INPUTtype = “HIDDEN” name = “Ucaf_City” value = “Purchase”>
<INPUTtype = “HIDDEN” name = “Ucaf_State_Country” value = “NY”><INPUTtype = “HIDDEN” name = “Ucaf_Currency_Code” value = “840NuteAnalyu =” 840 ”> =“ INPutAmateNe = ”NativeAnalysis =“ 840 ”> =“ INPUTAmateNe = ”NativeAnalysis =“ 840 ”> =“ INPUTAnalysis = “840”> = “INPACTAny” = “840”> = “INPACTAny” = “840”> = “INPACTAnon” = “840”> = INPACTAnonym.
<INPUTtype = "HIDDEN" name = "Ucaf_MTS" value = "F0AB">
<INPUTtype = "HIDDEN" name = "Ucaf_Brand" value "01"
Fields owned by the issuer server
<INPUTtype = “HIDDEN” name = “Ucaf_Authentication_Data” value = ”
GodlOEAxmL4wH71O8KtVOQkAQASRRxI0 "><INPUTtype=" HIDDEN "name =" Ucaf_Payment_Card_Number "value ="
123456789874563 ">
<INPUTtype = “HDDEN” name = “Ucaf_Payment_Card_ExpDate_Month” value = “02”>
<INPUTtype = "HIDDEN" name = "Ucaf_Payment_Card_ExpDate_Year" value = "2004"
<INPUTtype = “HJDDEN” name = “Ucaf_Payment_Card_CVC2” value = “256”>
[0052]
For merchants who wish to receive recurring payments from a particular account holder, the following information is collected in the UCAF structure.
[0053]
Transaction Frequency-This indicates the frequency of recurring payments. The valid values assigned by the seller are “W” for week, “M” for month, “Q” for quarter, and “A” for year.
[0054]
Number of payments-to determine the total recurring payments between the account holder and the merchant. Preferably, this field does not have a maximum credit default value. Each brand that uses this recurring payment feature may set its own execution limit. For example, the optimal maximum number of payments is 260.
[0055]
First Payment-This field indicates whether the account holder agrees with the date of the first recurring payment, expressed as DDMMYYYY, and the recurring payment relationship.
[0056]
Merchant Cancellation Policy-This field indicates whether the account holder can cancel recurring payments. A value of "1" is "Yes" and a value of "0" is "No". The recurring payment component can be selectively combined with one hidden field defined for UCAF. This new hidden field is named Ucaf_Recur_Payment and includes the following locations:
[0057]
In “FNNNDDMMYYYYC”,
F is the frequency of recurring payments. Valid values are:
W-week, M-month, Q-quarter, A-year
・ NNN is the number of recurring payments.
DDMMYYYY is the date of the first recurring payment. For example, May 29, 2000 is represented as “29032002”.
C-Distributor cancellation policy. This indicates whether the cardholder can cancel the recurring payment. A value of "1" is "Yes" and a value of "0" is "No".
[0058]
For example, if the merchant 404 supports a recurring payment that makes a first payment on March 1, 2001 on a monthly basis for one year, or if the account holder is allowed to cancel the transaction, Ucaf_Recur_Payment may be used. Is “M12010320011”. This approach requires the merchant 404 to repeatedly fill multiple hidden fields for recurring payments. This is because information is aggregated in one hidden field.
[0059]
Merchant 404 can optionally include a merchant transaction stamp (MTS) in one of the hidden fields on the merchant's payment page. The MTS is specific to each transaction and is therefore available as an additional security form. In particular, the MTS can be used to indicate that the account holder has actually accessed the merchant's website, and that the transaction is legitimate, impersonating the fraudulent merchant's re-transaction or legitimate merchant. Provide evidence that you are not others.
[0060]
The order confirmation page includes visual fields for displaying account holder information, such as merchant name and sales, for transactions other than a single click purchase. The fact that the merchant name and transaction volume can be viewed on the confirmation page before the shopper clicks the confirm button (step 210 in FIG. 2 described below) is that the account holder confirms and approves the actual transaction. Provide additional evidence that you have This feature assists issuer 406 in scrutinizing transaction rejections by the account holder.
[0061]
Referring back to FIG. 1, if the order confirmation web page of merchant 404 includes the hidden fields (step 104), then starting with issuer 406, user software 402, merchant 404, clearing house 408. The purchase is made using an authentication procedure 106 that utilizes the above technique to send authentication data 414 during a loop back to issuer 406. On the other hand, if the order confirmation web page does not include a hidden field (step 104), then the user's software 402 determines that the visible fields of the web page with purchase data, such as credit card number and expiration date, are filled. A conventional payment procedure 108 is performed (step 110), including using the data-filled web page fields to send the purchase data to the merchant 404 for authentication purposes (step 112).
[0062]
In step 128, if a UCAF enabled indicator field is present on the web page where the account holder clicked the "Buy" button, the user's software 402 sets the UCAF enabled indicator field to a UCAF enabled payment for the account holder. A code (for example, "01") for notifying the seller 404 that the software 402 of the user making the transaction is used is filled in (step 134). The web page containing the UCAF enabled indicator field filled with the code is presented to merchant 404 (step 136). The merchant 404 sends the confirmation page data to the user's software 402 (step 138). However, the buyer simply sees a page or window containing a simple message, for example, "Processing order." While displaying this message, the user's software 402 automatically fills in various hidden fields on the confirmation page with the account holder's address information and account number (step 140).
[0063]
Next, an authentication procedure 106 is performed.
[0064]
In either case, in the authentication procedure 106 or the authentication procedure 108, if authentication is granted (step 118), the goods and / or services are shipped and delivered, or otherwise provided to the purchaser (step 120). ). The checkout and settlement procedure can be used to settle and settle between issuer 406 and clearing house 408 (step 122). If there is a transaction with the acquirer (item 514 in FIG. 5 described below), the seller 404 setstles and setstle the payment between the issuer 406 and the acquirer 514 (step 122).
[0065]
On the other hand, if the authentication is rejected (step 118), the account holder is notified of the rejection (step 124) and ends the transaction (step 126).
[0066]
An example of a procedure 106 that uses authentication data 414 to authenticate a transaction is shown in FIG. The user's software 402 sends a request 412 for identity verification of the account holder to the issuer 406, including information received from a hidden field in the merchant's order confirmation page and / or provided by the account holder ( Step 202). Send request 412 via location 428 of network 434. In response to the request 412 for account holder identity verification, the issuer 406 sends authentication data 414, such as an AAV, to the user's software 402 over the network 428. When the user's software 402 receives the authentication data 414 from the publisher 406 (step 204), the software 402 includes the authentication data 414 in the hidden data 416 (step 206) and hides the hidden data on the merchant 404 web page. The hidden data 416 is used to fill the fields (step 208). For example, the AAV places the authentication data field hidden on the confirmation page.
[0067]
Preferably, each account holder is authenticated for each transaction. If the authentication of the account holder fails, the account holder is notified of the failure. If the account holder can be verified, the issuer's AAV-generation processor 440 generates an AAV 802. In this case, issuer 406 includes AAV 802 in authentication data 414 and sends data 414 to user software 402.
[0068]
Other information in the hidden fields on the confirmation page entered by the user's software 402 includes details of the account holder's payment account, such as his (woman) account number, expiration date, and optionally a card validation. (CVC2) value. Further, the hidden fields preferably include the UCAF enable indicator field. In some situations, the user's software 402 can check for differences between the merchant-supplied account number (if the account holder is written) and the account number inserted in the hidden account number field. The user's software 402 alerts the account holder of the difference and requests confirmation. In some cases, the account holder has multiple accounts registered with issuer 406. In such a case, the account holder selects an account number to be used for payment.
[0069]
If the hidden fields of the confirmation web page are filled with data, the page includes authentication data 414 (with AAV 802), payment account information, and hidden data 416 with other relevant information. By clicking the "present" button on the page, a confirmation page is presented to the seller 404 (step 210). If this is a shopping cart type transaction, for example, the present button is visible to the account holder and the account holder clicks on it. However, in a single click transaction, the user's software 402 automatically clicks on the submit button while the submit button remains hidden.
[0070]
Merchant 404 receives the hidden data 416 on the confirmation page and validates the control byte 804 and the merchant name hash contained in AAV 802. In some situations, merchant 402 can also collate the merchant transaction stamp (if generated by the merchant) with sales.
[0071]
Preferably, merchant 404 acquires and maintains an AAV that uses the account holder to link to a particular transaction. The data can be used to perform the next recognition of the partial shipment, and the data may be the value of merchant 404 during exceptional processing.
[0072]
In order to confirm that the merchant 404 has not received the illegal AAV 802, the control byte 804 is checked by confirming that the most significant bit is “1”. This is performed by checking that the leftmost character of the AVV 802 encoded by the base 64 is a lowercase “g”.
[0073]
The verification of the vendor name is performed after confirming that the hash of the vendor name included in the AAV exactly matches the hash of the vendor name included in one of the hidden fields. To accomplish this, the merchant 404 checks whether the 7-16 characters of the AVV 802 coded on the base 64 exactly match the pre-computed value. This pre-computed value is obtained by processing the hash of SHA-1 of the name of the seller.
[0074]
For example, the AAV may be the following data.
GodlOEAxmL4wH7108KtVOQkAQASHRx10
[0075]
The merchant matching process analyzes 7 to 26 characters.
AxmL4wH710
[0076]
The merchant 404 compares this pre-calculated value with the hash of SHA-1 of the known merchant name. If this value is not successfully validated, merchant 404 declines the transaction.
[0077]
In some situations, merchant 404 activates AAV sales based on the sales shown in one of the hidden fields. Merchant 404 translates base 64 encoded AVV 802 into a 24 binary byte source and identifies sales, sales truncation fields, and transaction currency codes. In accordance with the data contents of Table I and the sales and currency codes indicated via the hidden fields, the seller 404 activates the sales, the sales truncation field, and the transaction currency code. If the value is not successfully validated, merchant 404 declines the transaction.
[0078]
The merchant 404 optionally activates the MTS obtained by the AAV 802. When MTS is enabled, merchant 404 identifies the ATS 802 MTS component and compares it to the MTS indicated in the hidden field on the order confirmation page. If this value is not successfully validated, merchant 404 rejects the transaction. AAV 802 is probably fraudulent.
[0079]
Merchant 404 obtains authorization request message 418 from hidden data 416 (step 222) and sends authorization request message 418 to clearing house 408 via additional network or network portion 430 (step 212). This is because the hidden data 416 includes the authentication data 414, and the permission request message 418 is ultimately obtained from the authentication data 414.
[0080]
The permission request message 418 preferably includes at least the following data components:
・ Payment account number of the account holder sent to the seller
・ Distributor name
・ Currency code
·amount of sales
Merchant transaction stamp (if this component is not used, merchant 404 sets default value to "0000" in hexadecimal notation)
The following data components are included depending on the situation.
・ City of card acceptor
・ State / Country of Card Acceptor
[0081]
Because the hidden data 416 and the permission request message 418 include sensitive transaction-specific data and may be transmitted over a public network such as the Internet, the hidden data 416 and the permission request message 418 The data is preferably protected from threats using, for example, 128-bit SSL or an equivalent secure encryption method.
[0082]
The clearing house 408 sends the permission request message 420 to the issuer 406 via another network or the network unit 432 (step 214). The permission request message 420 sent from the clearing house 408 to the issuer 406 is generally the same as or obtained from the permission request message 418 sent from the merchant 404 to the clearing house 408. To generate the authorization response message 422, the issuer 406 utilizes a matching procedure 216 to process the authorization request message 420.
[0083]
FIG. 6 illustrates an exemplary procedure 216 used by the publisher 406 to process the authorization response message 422 described with reference to FIGS. 1 and 2 to generate an authorization request message 420. The exemplary procedure 216 shown in FIG. 6 is suitable for use of the AAV 802 generated cryptographically as described above, and utilizes a cryptographic collation approach. In the illustrated procedure 216, the AAV verification processor 442 using the cipher operated by the issuer 406 performs the following steps for each permission request message 420 received by the function.
[0084]
Safety level routing
1. When the security level indicator is set to a value of 1 (step 602), the verification processor 442 verifies that the account number is registered for a UXAF based verification system (step 604). If the account has been registered (step 604), processor 442 declines the transaction (step 606). Such scenarios may be because (i) the account holder did not use his UCAF-enabled software 402 to process the payment transaction, or (2) Because it had started.
a) If the account is not registered on a UCAF basis (step 604), forward the authentication request to an authentication system configured for conventional (ie, non-UCAF based) payment processing (step 608).
[0085]
2. If the security level indicator is set to 2 (step 602), the processor 442 proceeds with the AAV verification process as follows.
[0086]
AAV verification
1. Based on the indicated data format, AAV is extracted from the permission request message, decoded and interpreted at base 64 (step 610).
[0087]
2. Using the AAV key identification data, the AAV generation processor indicator, and the transaction sequence number, the matching processor 442 determines an encryption key to be used for MAC matching (step 612).
[0088]
3. Using the appropriate MAC algorithm, processor 442 attempts to match the MAC in AAV 802 (step 614). If the MAC verification is unsuccessful (step 616), the transaction is rejected (step 618). This is because AAV 802 is not valid and the transaction is therefore considered fraudulent.
[0089]
4. If the control byte of the AAV indicates that this is an initial authentication request (step 620),
a) The processor 442 checks for the same transaction sequence number (from the AAV generation processor 440), and that the sales have already occurred in the initial authentication received more than "n" seconds ago (here, “N” is specified by the issuer, typically 60) (step 626).
i) Note: If the corresponding grant response message is lost, a selective delay, eg in seconds, is possible for automatic retransmission of the grant request message.
b) If the transaction sequence number has already occurred in a previous authorization request message received "n" seconds or more ago (step 626), then reject the transaction, ie, from the AAV generation processor 440. This transaction sequence number is "detected as a copy" (step 628). The attempted transaction involves a fraudulent playback of a previously valid AAV.
c) If a transaction sequence number has not yet occurred (step 626), then identify the AAV transaction sequence number as "utilized" for future transactions (step 632).
d) After checking the AAV 802 of the initial authentication request, the issuer 406 can confirm the registration status of the account holder according to the situation, and automatically registers the account holder (step 634).
e) The verification of this transaction is successful because the AAV has been validated (step 630). An indication of a successful match is included in the authorization response message 422.
[0090]
5. If the AAV control byte 804 indicates that this is the next authentication request (step 620), and the AAV transaction sequence number has been detected as a "copy" to the AAV generation processor 440 used. "(Step 622), the transaction is rejected (step 624). This is a resubmission of the already rebuilt SPA transaction from the merchant.
[0091]
6. On the other hand, if the TSN was not detected as a copy (step 622), the AAV is valid and therefore the transaction match was successful (step 630). An indication of a successful match is therefore included in the authorization response message 422.
[0092]
To perform the reconciliation, AAV reconciliation processor 442 of issuer 406 preferably maintains a record for each account number registered for UCAF-based authentication. Further, the AAV matching processor 442 stores a key (or a plurality of keys) for key generation that is shared with each AAV generation processor 440. Also, to detect unauthorized playback of an account number and its associated AAV, the AVV verification processor 442 stores a record indicating which AAV has already been received.
[0093]
Also, AAV matching can be performed using a comparison approach. For example, in the verification procedure 216 shown in FIG. 7, the AAV verification processor 442 performs the following steps for each permission request message.
[0094]
1. When the safety level indicator is set to "1" (step 602)
a) Processor 442 determines whether the account number is registered with the UCAF based system (step 604). If the account is registered (step 604), the transaction is declined (step 606) because, in such a scenario, the account holder may use his UCAF capable software 402 to process the settlement transaction. This is because it indicates that it has not been used or that an unauthorized third party has initiated this transaction.
b) If the account is not registered on a UCAF basis (step 604), forward the authentication request to the issuer's authentication system for conventional (ie, non-UCAF based) payment processing (step 608).
[0095]
2. When the safety level indicator is set to "2" (step 602)
a) Processor 442 determines whether the account number is already registered with a UCAF-based system (step 702). If registered (step 702), issuer 406 extracts the AAV from the authentication request (step 706) and continues with the further processing described below.
b) If no account is registered (step 702), the transaction is declined (step 704).
[0096]
3. If this account is registered (step 702), after step 706, the AAV 802 of the permission request message is decoded on the base 64 (step 708).
[0097]
4. If the AAV control byte indicates that this is an initial authentication request (step 710), based on a comparison of the AAV transaction information stored in the issuer's database with the transaction data contained in the authorization request message 420, AAV procedure is performed.
a) The processor 442 authenticates that the AAV received during the authentication request matches the publisher's database entry (step 712). If there is no matching registration (step 712), the transaction is declined (step 714).
b) If the received AAV is determined to be valid based on the match (step 712), processor 442 verifies that issuer-defined data 810 has not been received in a previous transaction. If the issuer-defined data 810 has been received in a previous transaction more than "n" seconds ago (where "n" is typically equal to 60) (step 716), the transaction is rejected. , AAV 802 are detected as copies (step 718).
c) If the data component defined by the issuer has been previously received (step 716), then the data 802 defined by the issuer is "used" (step 720) and the definition of the issuer is The data 810 to be activated is additionally validated (step 722).
d) Validating the additional data may include comparing data obtained from the merchant hidden fields with the data included in the authorization request message 420 (step 722). This allows issuer 406 to enable additional fields such as account number and merchant name. If the data collation is successful (step 722), the collation of the AAV 802 is successful (step 726). An indication of a successful match is therefore included in the authorization response message 422. If the data does not match (step 722), then the transaction is declined (step 724).
[0098]
5. If the control byte of the AAV indicates that this is the next authentication request (step 710), the following steps are performed.
a) If the issuer-defined data 810 is a "suspiciously copied" dataset (step 728), processor 442 declines the transaction (step 730).
b) If the issuer-defined data 810 has not been received during the initial authentication and is not a “suspiciously copied” data set (step 728), the processor 442 has the data included in the authorization request message 420. Additional validation is confirmed by comparing data obtained from the merchant's hidden fields (step 722). This allows issuer 406 to validate the account number and merchant name. If the data match (step 722), the match was successful (step 726), and an indication of a successful match is included in the authorization response message 422.
[0099]
Issuer 406 sends authorization response message 422 to clearing house 408 via network or network portion 432, regardless of whether a cryptographic or comparison verification approach was used to generate authorization response message 422. (Step 218). The clearing house 408 sends the authorization response message 424 to the merchant 404 via the network or the network unit 430 (Step 220). The authorization response message 422 is the same as or obtained from the authorization response message 422 typically sent from the issuer 406 to the clearing house.
[0100]
In some situations, clearing house 408 may perform verification procedure 216 on behalf of issuer 406, in which case clearing house 408 may process its own authorization request message 418 to generate authentication message 424. A matching processor 446 is included. In other words, clearing house 408 can “represent” publisher 406 in the role of processing an authorization request message to generate an authorization response message. Such "proxy processing" is particularly beneficial if the issuer's authentication system is temporarily unavailable. This is because the “proxy processing” eliminates the need to transmit the permission request message 420 to be processed to generate the permission response message 422 to the issuer 406, that is, the permission response message 422 from the issuer 406 becomes unnecessary. Because it becomes.
[0101]
In any case, regardless of whether issuer 406 or clearing house 408 has performed verification procedure 216, if authorization response message 424 received by merchant 404 includes a transaction approval (step 118 in FIG. 1), the transaction Merchant 404 presents an HTML-based page based on the receipt to the account holder page to confirm the completion of the. This page preferably includes a reference number used for customer inquiries. In addition, the receipt page provides a hidden transaction identification field that is invisible to the account holder but readable by the user's software 402 to confirm the completed transaction. At this time, the merchandise is shipped and / or a service is provided (step 120). Both conventional settlement and settlement can be used to settle and settle payments between the issuer 406 and the settlement authority 408 (step 122).
[0102]
FIG. 5 shows another system for conducting secure payment transactions according to the present invention. Like the system shown in FIG. 4, the system shown in FIG. 5 includes the user's software 402, a merchant 404, a clearing house 408, and a payment account issuer 406. However, the system shown in FIG. 5 also includes an acquirer 514. The acquirer 514 is typically the acquiring bank of the merchant 404 account. The authentication data 414 is included in the data that goes from the issuer 406 to the user's software 402, the seller 404, the acquirer 514, the settlement institution 408, and returns to the issuer 406. There, the issuer confirms whether the authentication data 414 has been tampered with or changed illegally. Like the system shown in FIG. 4, this system shown in FIG. 5 operates according to the procedure shown in FIG. However, the payment procedure 106 utilized in connection with this system shown in FIG. 5 includes the acquirer 514 in a loop around authentication data 414 and other data / messages, as described in more detail below.
[0103]
FIG. 3 illustrates an exemplary payment procedure 106 utilized in the system illustrated in FIG. In the illustrated procedure 106, the user's software 402 sends a request 412 from the merchant 404 to authenticate the identity of the account holder making the purchase of goods and / or services to the issuer 406 via the network unit 428. (Step 202). In response to the request for authentication 412, the issuer 406 sends the authentication data 414 via the network unit 428, and the authentication data 414 is received by the user's software 402 (step 204). The user's software 402 includes the authentication data 414 in the hidden data 416 (step 206) and utilizes the hidden data 416 to fill hidden fields in the merchant 404 web page (step 208). As described with respect to the procedure shown in FIG. 2, the user's software 402 sends the hidden data 416 to the merchant 404 via the network 426 (step 210). The seller 404 obtains the permission request message 506 from the authentication data 416 (step 222), and transmits the permission request message 506 to the acquirer 514 via another network or the network unit 502 (step 302). The acquirer 514 sends the permission request message 508 to the clearing house 408 via another network or the network unit 504 (step 304). The permission request message 508 sent from the acquirer 514 to the clearing house 408 is generally the same as or obtained from the message 506 sent from the merchant 404 to the acquirer 514. The clearing house transmits the permission request message 420 to the issuer 406 via the network or the network unit 432 (step 306). The authorization request message 420 sent from the clearing house 408 to the issuer 406 can be the same as or obtained from the message 506 sent from the merchant 404 to the acquirer 514 and / or settled from the acquirer 514. It can be the same as or derived from the message 508 sent to the institution 408. To generate authorization response message 422, issuer 406 utilizes a verification procedure 216 that processes authorization request message 420 received from clearing house 408. The issuer 406 sends the permission response message 422 to the clearing house 408 via the network or the network unit 432 (step 308). The clearing house 408 transmits the permission response message 510 to the acquirer 514 via the network or the network unit 504 (Step 310). The authorization response message 510 sent from the clearing house 408 to the acquirer 514 is generally the same as or obtained from the message 422 sent from the issuer 406 to the clearing house 408.
[0104]
In some situations, the clearing house 408 can optionally perform the reconciliation procedure 216 on behalf of the issuer 406, as described for the system shown in FIG. Such a proxy process is performed by the settlement institution 408. In this case, the settlement institution 408 processes the permission request message 508 for generating the permission response message 510.
[0105]
In any case, regardless of whether issuer 406 or clearing house 408 performed verification procedure 216, acquirer 514 sends authorization response message 512 to merchant 404 via network or network unit 502 (step 312). ). The authorization response message 512 sent from the acquirer 514 to the merchant 404 can be the same as or obtained from the message 422 sent from the issuer 406 to the clearing house 408, and / or can be obtained from the clearing house 408 by the acquirer. It can be obtained from or the same as the message 510 sent to 514.
[0106]
Prior to downloading the user's software 402 for use in AAV-based transactions, the account holder preferably registers the issuer 406.
[0107]
The registration process offers the following beneficial features:
・ Strongly authenticate account holders
・ Register the account holder with the issuer 406
Download the user's software 402 to the account holder's computer.
[0108]
To obtain the user's software 402, the account holder first accesses the publisher's online banking website. The publisher's online banking website can be accessed from the publisher's web server 444. If the account holder is already registered on the issuer's online banking site, the account holder logs using his existing access credentials. This qualification can be verified using any of the conventional online banking account holder authentication methods.
[0109]
If the account holder is not already registered for access to the issuer's online banking site, the issuer 406 requests the account holder to register before obtaining the user's software 402. Preferably, the issuer 406 strongly authenticates the account holder's identity before or during registration to ensure the security of the next transaction made using the user's software 402. If the account holder is successfully authenticated, the registration process proceeds to the start of the account holder profile. The account holder is presented with an option to continue registering the user's software 402. Choosing to continue with the registration will direct the account holder's web browser to the user's software registration page. This page presents the account holder, along with a list of accounts that can be registered with the software 402, and requests various information from the account holder to provide the account holder's profile in the issuer's matching processor 442. . This information preferably includes at least the following:
[0110]
·account number
・ Account expiration date
-Account CVC2 verification value
[0111]
The following additional information can be gathered during the start of the profile.
・ Account holder name
・ Account holder billing address
・ Account holder shipping address
[0112]
In some situations, issuer 406 can automatically set up a profile based on account holder information available from the issuer's online banking site. By automating some or all of this processing, it is possible to avoid requiring the account holder to re-enter this information, thereby providing a convenient registration technique for the account holder.
[0113]
Data collected from the account holder or from the automated interface is transmitted to the issuer's matching processor 442 as part of the account holder's registration request. For systems in which the verification processor 442 is operated by an organization outside the issuer, this request and the resulting response should be adequately protected during transmission between the organizations. Requests and responses can be secured, for example, by transmitting these messages over a protected private network connection or by encrypting the messages before transmission over a public network such as the Internet. Issuer's match processor 442 processes the registration request and responds with either (a) or (b) below.
[0114]
(A) confirm that the registration was successful and ended; or (b) indicate the failed registration along with a message describing the reason for the failure.
[0115]
Issuers should choose a strong authentication device that ensures that the account holder registered online is correctly identified and verified. When an issuer performs a registration process, the following guidelines / choices should be maintained when recognizing shared secrets that can be used for authentication purposes.
[0116]
• More than one piece of information should be used for shared secrets. For example, the account holder's mother's maiden name and the last four digits of his (her) social security number can be used in combination with a password generated by the issuer.
[0117]
-Shared secrets should be identifiable. For example, if you use the maiden name of the account holder's mother, the authentication system should be able to verify this information.
[0118]
• Recognition of all shared secrets should require access to multiple sources. It is preferable to avoid using a shared secret that is fully available within one document and / or from public information. For example, issuer 406 should utilize the use of credit limits and address information, and both of this shared secret are available on the account holder's monthly account statement. If this statement is stolen, the secret of this sharing is threatened.
[0119]
Issuer 406 has some information available to determine the shared secret, depending on the situation. For example, the following information can be used.
[0120]
・ A bank-generated password sent to the billing address of the account holder in the mailer, separate from the statement
CVC2 available only on the signature panel of the card
A verifiable non-public number, such as the last four digits of the account holder's social security number.
・ Usage limit on account (available on monthly deposit statement)
After successful registration, the account holder can download and install the user's software 402 on his (woman) access device-typically a computer, PDA, or mobile phone. In order to automatically launch the user's software 402 when the account holder is directed to the merchant's purchase page, the account holder's access device must be configured by the user's software 402 as part of the equipment start / proxy procedure. Preferably it is configured to be operated.
[0121]
Upon activation and display, the user's software 402 requests the account holder's access credentials to authenticate the account holder's identity during the purchase transaction. This access entitlement is generally managed by the publisher 402 and preferably includes some or all of the following:
・ User id / Password
・ Smart card / PIN
・ Confidential information on the balance of the released password
・ Verification by biological measurement
・ Electronic certificate
・ Authentication mechanism approved by another secure issuer
[0122]
In order to maximize the security of the cardholder and to provide the cardholder with strong authentication, the authentication is preferably performed through the issuer's verification processor 442 for each transaction.
[0123]
In some circumstances, issuer 406 may choose to store data that tracks AAV generation and account holder transactions. Tracking the history of AAV generation, including AAV, card city, card state / country, and brand, can assist issuer 406 in assisting with discussion-based management and fee refund processing. Further, the issuer 406 can reject the account holder based on the record of the authentication result and the confirmation of the account holder in the transaction. Such rejections are primarily based on the AAV, card city, card state / country, and brand associated with each transaction. Issuer 406 may choose to make the sales history available online to the account holder, thereby reducing the number of customer service inquiries.
[0124]
For purchases involving split shipments, merchant 404 preferably requests and obtains authorization for each shipment. When performing the next authentication by split shipment, the merchant 404 changes the control byte 804 included in the initial authentication AAV 802 from “82” in hexadecimal notation to “02” in hexadecimal notation. If the change of the control byte 804 for the next authentication fails, the issuer 406 will refuse the authentication.
[0125]
After rejection of the initial issuer, merchant 404 may wish to resend the authentication request. In that case, the AAV 802 is transmitted as the next authentication together with the control byte 804 changed from “82” in hexadecimal notation to “02”.
[0126]
In some cases, for a given transaction, merchant 404 may generate a second authentication request with an AAV having the same value as the AAV in the original request. The second authentication request matches the original request, such as bits. For example, the request may have an ID number that is indicative of a different system. In general, merchant 404 may generate a second authentication request when:
The merchant 404 does not receive a response to the original authentication request within a predetermined timeout period, or
The merchant 404 decides to completely revoke the original authentication but later to undo it.
[0127]
Merchant 404 preferably reads the most significant bit of control byte 804 and treats such an authentication request as the next authentication request. This will cause issuer 406 to erroneously reject such a request as a possible re-attack.
[0128]
It will be apparent to those skilled in the art that the methods of FIGS. 1-7 can be performed on a variety of standard computer platforms operating under the appropriate software controls described in FIGS. In some cases, dedicated computer hardware, such as peripheral cards in conventional personal computers, can increase the operational efficiency of the method.
[0129]
9 and 10 show typical computer hardware suitable for putting the present invention into practical use. Referring to FIG. 9, the computer system includes a processing unit 910, a display 920, a keyboard 930, and a peripheral communication device 940 such as a modem. The system also includes a printer 960.
[0130]
Generally, data and application software that can read from and write to computer readable media such as magnetic media (ie, diskettes) and / or optical media (eg, CD-ROM or DVD) are provided. The computer system includes one or more disk drives 970 for storing. Although not shown, other input devices such as a digital pointer (eg, a “mouse”) are also included. The computer hardware shown in FIGS. 9 and 10 can be used to operate the user software 402 shown in FIGS. 4 and 5 and / or the merchant 404, merchant server 448, acquirer 514, payment And / or may be used to perform the functions of the clearing house 408, the reconciliation processor 446, the issuer 406, the AAV generation processor 440, the reconciliation processor 442, and / or the issuer's server 444.
[0131]
FIG. 10 is a functional block diagram further explaining the processing unit 910. The processing unit 910 generally includes a processing unit 1010, control logic 1020, and a memory unit 1030. It is preferable that the processing unit 910 further includes a timer 1050 and an input / output port 1040. The processing unit 910 includes a common processor 1060 depending on the microprocessor used in the processing unit. The control logic 1020 cooperates with the processing unit 1010 to perform control necessary for handling communication between the memory unit 1030 and the input / output port 1040. The timer 1050 supplies a timing reference signal for the processing unit 1010 and the control logic 1020. The common processor 1060 extends the ability to perform complex calculations in real time as required by cryptographic algorithms.
[0132]
The memory unit 1030 includes different types of memories such as volatile and nonvolatile memories and ROMs. For example, as shown in FIG. 10, the memory unit 1030 includes a ROM 1031, an EEPROM 1032, and a RAM 1033. Different computer processors, memory configurations, data configurations, etc., can be used to implement the invention, and the invention is not limited to a particular platform. For example, while the processing unit 910 is shown as part of a computer system in FIGS. 9 and 10, the processing unit 910 and / or its components may incorporate a PDA or mobile phone.
[0133]
Although the present invention has been described in connection with specific embodiments, it will be apparent to those skilled in the art that various modifications and substitutions can be made without departing from the spirit and scope of the invention described in the appended claims. Is clear.
[Brief description of the drawings]
[0134]
FIG. 1 is a flowchart illustrating a typical procedure for performing a settlement transaction according to the present invention.
FIG. 2 is a flowchart illustrating one exemplary payment procedure used in the procedure described in FIG.
FIG. 3 is a flow diagram illustrating another exemplary payment procedure utilized in the procedure described in FIG.
FIG. 4 is a block diagram illustrating one exemplary system for performing a settlement transaction according to the present invention.
FIG. 5 is a block diagram illustrating another exemplary system for performing a settlement transaction according to the present invention.
FIG. 6 is a flowchart for explaining one typical permission request message collation procedure used in the procedures shown in FIGS. 2 and 3;
FIG. 7 is a flowchart for explaining another typical permission request message collation procedure used in the procedures shown in FIGS. 2 and 3;
FIG. 8 is a block diagram illustrating a typical account holder authentication value (AAV) of the present invention.
FIG. 9 is a diagram for explaining a typical computer system for performing a settlement transaction according to the present invention.
FIG. 10 illustrates a typical processing unit used in the computer system shown in FIG.

Claims

Receiving, by the user's software, a set of web page data for displaying the web page;
Determining, by the user's software, whether the web page includes at least one hidden field;
If the web page includes at least one hidden field, a first payment procedure including filling the at least one hidden field with the hidden data by a user's software that sends the hidden data to a merchant; Select to use to make a specific payment transaction,
If the web page does not include at least one hidden field, a second payment procedure for sending purchase data to the merchant, including filling the visible fields included in at least one web page with the purchase data, A method for conducting a settlement transaction, characterized in that it is selected for use in conducting a particular settlement transaction.

The first payment procedure further includes receiving, by the user's software, authentication data from a payment account issuer, wherein the hidden data comprises the authentication data, and wherein the authentication data comprises payment account issuance. 2. The method according to claim 1, wherein the method is for authenticating the identity of the account holder of the payment account issued by the third party.

The first payment procedure further includes, in response to a request to authenticate the account holder's identity and a request to authenticate the account holder's identity, the payment account issuer to the user's software. 3. The method of claim 2, wherein the authentication data to be sent is sent from the user's software to the payment account issuer.

The first payment procedure further comprises:
Transmitting a permission request message obtained from the authentication data from the seller to a clearing house;
Transmitting at least one of the authorization request message and a message obtained from the authorization request message from the clearing house to the payment account issuer;
Using the authorization request message and a reconciliation procedure that processes at least one of the messages obtained from the authorization request message by the payment account issuer to generate an authorization response message;
Transmitting the authorization response message from the payment account issuer to the clearing house;
4. The method of claim 3, further comprising transmitting at least one of the authorization response message and the message obtained from the authentication response message from the clearing house to the merchant.

The first payment procedure further comprises:
Transmitting a first permission request message obtained from the authentication data from the seller to the acquirer;
Transmitting at least one of the first permission request message and a second permission request message obtained from the first permission request message from the acquirer to the settlement institution;
The clearing house sends to the payment account issuer a first and a second permission request message, and a third permission request message obtained from at least one of the first and second permission request messages. Sending at least one;
Using the reconciliation procedure for processing at least one of the first and second authentication request messages and the third authorization request message by the payment account issuer to generate a first authorization response message; ,
Transmitting the first authorization response message from the payment account issuer to the clearing house;
Transmitting at least one of the first authorization response message and a second authorization response message obtained from the first authorization response message from the clearing house to the acquirer;
From the acquirer to the merchant, at least one of the first and second authorization response messages and a third authorization response message obtained from at least one of the first and second authorization response messages Transmitting one.

The first payment procedure further comprises:
Transmitting a permission request message obtained from the authentication data from the seller to a clearing house;
Transmitting at least one of the authorization request message and a message obtained from the authorization request message from the clearing house to the payment account issuer;
Using the authorization request message and a reconciliation procedure that processes at least one of the messages obtained from the authorization request message by the payment account issuer to generate an authorization response message;
Transmitting the authorization response message from the payment account issuer to the clearing house;
3. The method of claim 2, comprising transmitting at least one of the authorization response message and a message obtained from the authorization response message from the clearing house to the merchant.

The first payment procedure further comprises:
Transmitting a first permission request message obtained from the authentication data to the acquirer from the seller;
Transmitting at least one of the first permission request message and a second permission request message obtained from the first permission request message from the acquirer to a clearing house;
At least one of at least one of the first and second permission request messages and a third permission request message obtained from at least one of the first and second permission request messages, Transmitting to the payment account issuer from:
The payment account issuer for generating a first authorization response message, wherein the verification procedure processes at least one of the first and second authorization request messages and at least one of the third authorization request messages. Steps used by
Transmitting the first authorization response message from the payment account issuer to the clearing house;
Transmitting at least one of the first authorization response message and a second authorization response message obtained from the first authorization response message from the clearing house to the acquirer;
At least one of the first and second authorization response messages and at least one of the third authorization response messages obtained from at least one of the first and second authorization response messages from the acquirer; Transmitting to the merchant.

The first payment procedure further comprises:
Transmitting the permission request message obtained from the hidden data from the merchant to a clearing house;
Sending at least one of an authorization request message and a message obtained from the authorization request message from the clearing house to a payment account issuer;
Using the authorization request message and a reconciliation procedure that processes at least one of the messages obtained from the authorization request message by the payment account issuer to generate an authorization response message;
Transmitting the authorization response message from the payment account issuer to the clearing house;
Transmitting the authorization response message and at least one of the messages obtained from the authorization response message from the clearing house to the merchant.

The hidden data includes at least data associated with the particular payment transaction;
The collating procedure includes:
The payment account issuer determining whether the data associated with the particular payment transaction has been previously used to authenticate any payment transaction;
9. Refusing authentication of the authorization response message if the data associated with the particular payment transaction was previously used to authenticate any payment transaction. .

The first payment procedure includes:
Transmitting a first permission request message obtained from the hidden data to the acquirer from the seller;
Transmitting at least one of the first permission request message and a second permission request message obtained from the first permission request message from the acquirer to a clearing house;
The at least one of the first and second permission request messages, and at least one of a third permission request message obtained from the at least one of the first and second permission request messages, Transmitting from the clearing house to a payment account issuer;
A reconciliation procedure for processing the at least one of the first and second authorization request messages and at least one of the third authorization request messages to generate a first authorization response message. Steps used by the publisher;
Sending a first authorization response message from the payment account issuer to the clearing house;
Transmitting at least one of the first authorization response message and a second authorization response message obtained from the first authorization response message from the clearing house to the acquirer;
Acquiring at least one of the at least one of the first and second authorization response messages and at least one of a third authorization response message obtained from the at least one of the first and second authorization response messages And transmitting to the merchant from the distributor.

The hidden data includes at least one of data associated with the particular payment transaction;
The collating procedure includes:
Determining by the payment account issuer whether data associated with the particular payment transaction has been previously used to authenticate any payment transaction;
Rejecting authentication of said first authorization response message if data associated with said particular payment transaction was previously used to authenticate any of the payment transactions. .

The first payment procedure further comprises:
Transmitting a permission request message obtained from the hidden data from the merchant to a clearing house;
The clearing house using a verification procedure to process the authorization request message to generate an authorization response message;
Transmitting the authorization response message from the clearing house to the merchant.

The first payment procedure further comprises:
Transmitting a first permission request message obtained from the hidden data to the acquirer from the seller;
Transmitting at least one of the first permission request message and a second permission request message obtained from the first permission request message from the acquirer to a clearing house;
The clearing house using a verification procedure that processes at least one of the first and second authorization request messages to generate a first authorization response message;
Transmitting the first authorization response message from the clearing house to the acquirer;
Transmitting said first authorization response message and a second authorization response message obtained from said first authorization response message from said acquirer to said seller. Method.

A user software receiving a set of web page data displaying a web page including at least one of the hidden fields;
The user software receives the authentication data from the payment account issuer for authenticating the identity of the account holder of the payment account issued by the payment account issuer;
A method for conducting a settlement transaction, wherein said user software fills said at least one hidden field with said authentication data to send said authentication data to a merchant.

Sending a request to authenticate the account holder's identity from the user's software to the payment account issuer and, in response to the request to authenticate the account holder's identity, 15. The method of claim 14, wherein the payment account issuer sends to the user's software.

A permission request message obtained from the authentication data is transmitted from the seller to a clearing house,
Transmitting at least one of the authorization request message and a message obtained from the authorization request message from the clearing house to the payment account issuer;
Utilizing the payment account issuer to perform a reconciliation procedure that processes the authorization request message and the at least one of the messages obtained from the authorization request message to generate an authorization response message;
Transmitting the authorization response message from the payment account issuer to the clearing house;
The method of claim 15, wherein at least one of the authorization response message and a message obtained from the authorization response message is transmitted from the clearing house to the merchant.

A first permission request message obtained from the authentication data is transmitted from the seller to the acquirer,
Transmitting at least one of the first permission request message and a second permission request message obtained from the first permission request message from the acquirer to a clearing house;
The at least one of the first and second authorization request messages and at least one of a third authorization request message obtained from the at least one of the first and second authorization request messages to the clearing house From to the payment account issuer,
A reconciliation procedure for processing the at least one of the first and second authorization request messages and at least one of the third authorization request messages to generate a first authorization response message. Use the publisher,
Transmitting the first authorization response message from the payment account issuer to the clearing house;
Transmitting at least one of the first authorization response message and a second authorization response message obtained from the first authorization response message from the clearing house to the acquirer;
Acquiring at least one of the at least one of the first and second authorization response messages and a third authorization response message obtained from the at least one of the first and second authorization response messages to the acquirer 16. The method according to claim 15, wherein the information is transmitted to the merchant.

Transmitting a permission request message obtained from the authentication data from the seller to a clearing house,
Transmitting at least one of the authorization request message and a message obtained from the authorization request message from the clearing house to the payment account issuer;
The payment account issuer utilizing a reconciliation procedure that processes the authorization request message and the at least one of the messages obtained from the authorization request message to generate an authorization response message;
Transmitting the authorization response message from the payment account issuer to the clearing house;
The method of claim 14, wherein at least one of the authorization response message and a message obtained from the authorization response message is transmitted from the clearing house to the merchant.

A first permission request message obtained from the authentication data is transmitted from the seller to the acquirer,
Transmitting at least one of the first permission request message and a second permission request message obtained from the first permission request message from the acquirer to a clearing house;
The at least one of the first and second authorization request messages and at least one of a third authorization request message obtained from the at least one of the first and second authorization request messages to the clearing house From to the payment account issuer,
A reconciliation procedure that processes the at least one of the first and second authorization request messages and the at least one of a third authorization request message to generate a first authorization response message. Used by the publisher,
Transmitting the first authorization response message from the payment account issuer to the clearing house;
Transmitting at least one of the first authorization response message and a second authorization response message obtained from the first authorization response message from the clearing house to the acquirer;
Acquiring at least one of the at least one of the first and second authorization response messages and at least one of a third authorization response message obtained from the at least one of the first and second authorization response messages; The method according to claim 14, wherein the data is transmitted to the merchant.

Transmitting a permission request message obtained from the authentication data from the seller to a clearing house,
The clearing house uses a verification procedure to process the authorization request message to generate an authorization response message;
The method of claim 14, wherein the authorization response message is sent from the clearing house to the merchant.

A first permission request message obtained from the authentication data is transmitted from the seller to the acquirer,
Transmitting at least one of the first permission request message and a second permission request message obtained from the first permission request message from the acquirer to a clearing house;
The clearing house uses a verification procedure that processes the at least one of the first and second authorization request messages to generate a first authorization response message;
Transmitting the first authorization response message from the clearing house to the acquirer;
The method according to claim 14, wherein at least one of the first permission response message and a second permission response message obtained from the first permission response message is transmitted from the acquirer to the seller. Method.

A first set of web page data displaying a first web page is received by the user's software;
Determining whether the user software includes a first hidden field that indicates to the user software that the first web page is available to perform a one-click payment procedure;
If the first web page includes the first hidden field, the user's software may use the first hidden field to perform the user's software to perform at least one payment transaction. A method for conducting a settlement transaction characterized by filling with data notified to a merchant.

23. The method of claim 22, wherein the one click payment procedure to make use of the first web page is selected by an account holder.

The user's software receiving the second set of web page data representing a second web page including a second hidden field and a hidden button;
The user software filling the second hidden field with authentication data to send the authentication data to the merchant to authenticate the identity of the account holder;
The user software clicking on the hidden button to initiate transmission of the authentication data to the merchant.

26. The method of claim 24, wherein the user's software receives the authentication data from a payment account issuer that issues a payment account to the account holder.

Transmitting a permission request message obtained from the authentication data from the seller to a clearing house,
Transmitting at least one of the authorization request message and a message obtained from the authorization request message from the clearing house to the payment account issuer;
The payment account issuer utilizing a reconciliation procedure that processes the authorization request message and the at least one of the messages obtained from the authorization request message to generate an authorization response message;
Transmitting the authorization response message from the payment account issuer to the clearing house;
26. The method of claim 25, wherein at least one of the authorization response message and a message obtained from the authorization response message is transmitted from the clearing house to the merchant.

A first permission request message obtained from the authentication data is transmitted from the seller to the acquirer,
Transmitting at least one of the first permission request message and a second permission request message obtained from the first permission request message from the acquirer to a clearing house;
The at least one of the first and second authorization request messages and at least one of a third authorization request message obtained from the at least one of the first and second authorization request messages to the clearing house From to the payment account issuer,
A reconciliation procedure for processing the at least one of the first and second authorization request messages and at least one of a third authorization request message to generate a first authorization response message. Used by
Transmitting the first authorization response message from the payment account issuer to the clearing house;
Transmitting at least one of the first authorization response message and a second authorization response message obtained from the first authorization response message from the clearing house to the acquirer;
Acquiring at least one of the at least one of the first and second authorization response messages and a third authorization response message obtained from the at least one of the first and second authorization response messages to the acquirer 26. The method of claim 25, wherein said information is transmitted to said merchant.

A first user processor for receiving a set of web page data for displaying a web page;
A second user processor for determining whether the web page includes at least one of a hidden field;
If the web page includes at least one of the hidden fields, the at least one hidden field is used to transmit a particular payment transaction to a merchant and the hidden data is used to transmit the hidden data to a merchant. A processor that selects the first payment system that is configured by a third user processor that satisfies
If the web page does not include at least one of the hidden fields, transmitting at least one visible field included in the web page from the purchase data to the merchant for use in performing the particular payment transaction. A processor for selecting a second payment system comprising a processor that fills at least one visible field with purchase data.

The first payment system further includes:
A payment account issuer that issues the payment account to the account holder,
A fourth user processor for receiving authentication data from the payment account issuer, the hidden data composed of the authentication data, and the authentication data for authenticating the identity of the account holder. 29. The device of claim 28, wherein

The first payment system further includes:
The request for authenticating the account holder's identity and the authentication data transmitted from the payment account issuer to the fourth user processor in response to the request for authenticating the account holder's identity, The apparatus of claim 29, further comprising a fifth user processor for transmitting to an account issuer.

The first payment system further includes:
A clearing house that receives a permission request message obtained from the authentication data from the seller,
With
The clearing house further transmits at least one of the authorization request message and a message obtained from the authorization request message to the payment account issuer;
The payment account issuer comprises a matching processor for matching the authorization request message and the at least one of the messages obtained from the authorization request message to generate an authorization response message, the payment account issuer comprising: Send to
31. The apparatus of claim 30, wherein the clearing house further sends at least one of the payment account issuer, the authorization response message, and a message obtained from the authorization response message to the merchant.

The first payment system further includes:
An acquirer receiving a first permission request message obtained from the authentication data from the seller,
A settlement institution receiving at least one of the first permission request message and the second permission request message obtained from the first permission request message from the acquirer;
With
The clearing house further includes at least one of a third authorization request message obtained from the at least one of the first and second authorization request messages and the at least one of the first and second authorization request messages. One to the payment account issuer,
The payment account issuer matches the at least one of the first and second authorization request messages with at least one of the third authorization request messages to generate a first authorization response message. Consists of a collation processor,
The payment account issuer further sends the first authorization response message to the clearing house, and the clearing house further includes a second authorization response obtained from the first authorization response message and the first authorization response message. Sending at least one of the messages to the acquirer, the acquirer further obtaining from the at least one of the first and second authorization response messages and the at least one of the first and second authorization response messages. 31. The apparatus of claim 30, wherein at least one of the third authorization response messages is sent to the merchant.

The first payment system further includes:
A settlement institution receiving a permission request message obtained from the authentication data from the seller,
With
The clearing house further sends at least one of the authorization request message and a message obtained from the authorization request message to the payment account issuer;
The payment account issuer comprises a matching processor for matching the authorization request message and the at least one of the messages obtained from the authorization request message, generating an authorization response message;
The payment account issuer further sends the authorization response message to the clearing house,
The apparatus of claim 29, wherein the clearing house further transmits at least one of the authorization response message and a message obtained from the authorization response message to the merchant.

The first payment system further includes:
An acquirer receiving a first permission request message obtained from the authentication data from the seller,
A clearing house receiving at least one of the first permission request message and the second permission request message obtained from the first permission request message from the acquirer;
Wherein the clearing house further comprises a third authorization request message obtained from the at least one of the first and second authorization request messages and the at least one of the first and second authorization request messages. Sending at least one to the payment account issuer, the payment account issuer matching the at least one of the first and second authorization request messages with the at least one of the third authorization request messages Generating a first authorization response message, the payment account issuer further transmitting the first authorization response message to the clearing house, and the clearing house further comprises the first authorization response message. A message and at least one of a second authorization response message obtained from the first authorization response message to the acquirer, the acquirer further comprising: Providing at least one of the at least one of the first and second authorization response messages and at least one of the third authorization response messages obtained from the at least one of the first and second authorization response messages to the seller. 30. The apparatus of claim 29, wherein transmitting.

The first payment system further includes:
Payment account issuer,
A clearing house that receives a permission request message obtained from the hidden data from the seller;
Wherein the clearing house further transmits at least one of the authorization request message and a message obtained from the authorization request message to the payment account issuer, wherein the payment account issuer transmits the authorization request message and the authorization request message. A reconciliation processor for reconciling said at least one of said messages obtained from generating a permission response message, wherein said payment account issuer sends said permission response message to said clearing house, said clearing house further comprising: 29. The apparatus of claim 28, wherein at least one of an authorization response message and a message derived from the authorization response message is sent to the merchant.

The hidden data includes at least data associated with the particular payment transaction, and the matching processor includes:
A processor that determines whether the data associated with the particular payment transaction was previously used in any payment transaction;
36. The apparatus of claim 35, further comprising: a processor for rejecting authentication of the authorization response message if the data associated with the particular payment transaction was previously used in any payment transaction.

The first payment system further includes:
Payment account issuer,
An acquirer receiving a first permission request message obtained from the hidden data from the seller;
A clearing house receiving at least one of the first permission request message and the second permission request message obtained from the first permission request message from the acquirer;
Wherein the clearing house further comprises a third authorization request message obtained from the at least one of the first and second authorization request messages and the at least one of the first and second authorization request messages. Sending at least one to the payment account issuer, the payment account issuer matching the at least one of the first and second authorization request messages with the at least one of the third authorization request messages Generating a first authorization response message, wherein the payment account issuer sends the first authorization response message to the clearing house, and the clearing house further comprises the first authorization response message. And at least one of a second authorization response message obtained from the first authorization response message to the acquirer, wherein the acquirer further comprises Transmitting at least one of the at least one of the first and second authorization response messages and the third authorization response message obtained from the at least one of the first and second authorization response messages to the merchant; 29. The device of claim 28, wherein:

The hidden data includes at least data related to the particular payment transaction, and the matching processor includes:
A processor that determines whether data related to the specific payment transaction has been used to authenticate any of the payment transactions previously,
38. The apparatus of claim 37, further comprising a processor for rejecting authentication of the first authorization response message if data associated with the particular payment transaction was previously used to authenticate any of the payment transactions.

The first payment system further includes a clearing house that receives a permission request message obtained from the hidden data from the merchant, the clearing house includes a matching processor that matches the permission request message, The apparatus of claim 28, wherein a message is generated and the clearing house further sends the authorization response message to the merchant.

The first settlement system, further, an acquirer receiving a first permission request message obtained from the hidden data from the seller,
A settlement institution for receiving at least one of the first permission request message and a second permission request message obtained from the first permission request message from the acquirer, wherein the settlement institution comprises: A matching processor for matching the at least one of the second authorization request messages, generating a first authorization response message, wherein the clearing house further transmits the first authorization response message to the acquirer; 29. The apparatus of claim 28, wherein the acquirer further sends at least one of the first authorization response message and a second authorization response message derived from the first authorization response message to the merchant. .

A first user processor for receiving a set of web page data displaying a web page including at least one hidden field;
A payment account issuer that issues payment accounts to the account holder,
A second user processor for receiving authentication data from the payment account issuer for authenticating the account holder's identity;
A third user processor filling the at least one hidden field with the authentication data for transmission to a merchant.

A fourth user processor that sends a request to authenticate the account holder's identity to the payment account issuer, wherein the authentication data is transmitted in response to the request to authenticate the account holder's identity. 42. The apparatus of claim 41, wherein the payment account issuer transmits to the second user processor.

A payment institution that receives the authorization request message obtained from the authentication data from the merchant; and the payment institution further issues at least one of the authorization request message and the message obtained from the authorization request message to the payment account. The payment account issuer comprising: a reconciliation processor that reconciles the authorization request message with the at least one of the messages obtained from the authorization request message, generating an authorization response message; 43. The method of claim 42, further comprising transmitting the authorization response message to the clearing house, wherein the clearing organization transmits at least one of the authorization response message and a message obtained from the authorization response message to the merchant. The described device.

An acquirer receiving a first permission request message obtained from the authentication data from the seller,
Further comprising a clearing house for receiving from the acquirer at least one of the first permission request message and a second permission request message obtained from the first permission request message,
The clearing house further includes a third authorization obtained from the at least one of the first and second authorization request messages obtained from the first authorization request message and a third authorization request message obtained from the first and second authorization request messages. Sending at least one of the at least one of the request messages to the payment account issuer, wherein the payment account issuer sends the at least one of the first and second authorization request messages and the third authorization A reconciliation processor for reconciling at least one of the request messages, generating a first authorization response message, wherein the payment account issuer further comprises a first authorization response message from the first authorization response message; Sending at least one of the obtained second authorization response messages to the acquirer, the acquirer further comprising the at least one of the first and second authorization response messages; 43. The apparatus of claim 42, wherein at least one of a third authorization response message obtained from the at least one of the first and second authorization response messages is transmitted to the merchant. .

A payment institution for receiving an authorization request message obtained from the authentication data from the merchant, wherein the payment institution further issues the authorization request message and at least one of the messages obtained from the authorization request message to the payment account; The payment account issuer comprises a matching processor for matching the authorization request message and the at least one of the messages obtained from the authorization request message, generating an authorization response message, Further transmitting the authorization response message to the clearing house, wherein the clearing organization sends at least one of the authorization response message and a message obtained from the authorization response message to the merchant. 42. The apparatus according to 41.

An acquirer receiving a first permission request message obtained from the authentication data from the seller,
A payment institution that receives at least one of the first permission request message and the second permission request message obtained from the first permission request message from the acquirer, wherein the payment institution further comprises the first Issuing at least one of the at least one of the second authorization request messages and at least one of the third authorization request messages obtained from the at least one of the first and second authorization request messages. A payment processor, wherein the payment account issuer includes a matching processor for matching the at least one of the first and second authorization request messages with at least one of the third authorization request messages; Generating a first authorization response message, the payment account issuer further sends the first authorization response message to the clearing house, and the clearing house further transmits the first authorization response message. A message and at least one of a second authorization response message obtained from the first authorization response message to the acquirer, the acquirer further comprising the at least one of the first and second authorization response messages. 42. The method of claim 41, wherein at least one of a third authorization response message obtained from the one and the at least one of the first and second authorization response messages is transmitted to the merchant. Equipment.

A payment institution that receives a permission request message obtained from the authentication data from the merchant, the payment institution includes a verification processor that verifies the permission request message, and generates a permission response message; The apparatus of claim 41, further comprising transmitting the authorization response message to the merchant.

An acquirer receiving a first permission request message obtained from the authentication data from the seller,
A payment institution that receives at least one of the first permission request message and the second permission request message obtained from the first permission request message from the acquirer; And a matching processor for matching the at least one of the second authorization request messages and generating a first authorization response message, the clearing house further transmitting the first authorization response message to the acquirer. 42. The method according to claim 41, wherein the acquirer further transmits at least one of the first permission response message and a second permission response message obtained from the first permission response message to the seller. The described device.

A first user processor receiving a first set of web page data displaying a first web page;
A second determining whether the first web page includes a first hidden field indicating to the user's software that it can be used by a one-click payment system to conduct a payment transaction; A user processor,
If the first web page includes the first hidden field, the user processor informs a merchant that the first hidden field will be used to perform the at least one payment transaction. And a third user processor that fills with the data of (1).

50. The arrangement of claim 49, further comprising an account holder selecting said one click payment procedure utilizing said first web page.

A fourth user processor for receiving a second set of web page data representing a second web page including a second hidden field and a hidden button;
A fifth user processor that fills the second hidden field with authentication data for authenticating the account holder's identity and sends the authentication data to the merchant;
51. The arrangement of claim 50, further comprising: a sixth user processor clicking on said hidden button to initiate transmission of said authentication data to said merchant.

A payment account issuer that issues a payment account to the account holder;
The arrangement of claim 51, further comprising: a seventh user processor for receiving the authentication data from the payment account issuer.

A payment institution that receives an authorization request message obtained from the authentication data from the merchant, wherein the payment institution further includes at least one of the authorization request message and at least one of the messages obtained from the authorization request message. The payment account issuer comprises a matching processor for matching the authorization request message and the at least one of the messages obtained from the authorization request message to generate an authorization response message, wherein the payment account issuer comprises: The method of claim 52, further comprising transmitting the authorization response message to the clearing house, wherein the clearing organization further transmits the authorization response message and at least one obtained from the authorization response message to the merchant. Arrangement.

An acquirer receiving a first permission request message obtained from the authentication data from the seller,
A payment institution that receives at least one of the first permission request message and a second permission request message obtained from the first permission request message from the acquirer, wherein the payment institution further comprises the first And at least one of a third authorization request message obtained from the at least one of the second authorization request messages and the at least one of the first and second authorization request messages to the payment account issuer. And wherein the payment account issuer comprises a matching processor for matching the at least one of the first and second authorization request messages with at least one of the third authorization request messages, the first authorization response message The payment account issuer further sends the first authorization response message to the clearing house, and the clearing house further Sending at least one of a permission response message and a second permission response message obtained from the first permission response message to the acquirer, the acquirer further comprising the at least one of the first and second permission response messages. 53. The arrangement of claim 52, wherein at least one of a third authorization response message obtained from the at least one of the one and the first and second authorization response messages is transmitted to the merchant. .

A user processor receiving a set of web page data for displaying a web page;
The user processor determining whether the web page includes at least one of the hidden fields;
If the web page includes at least one of the hidden fields, the at least one hidden field is used to transmit the hidden data to a merchant for use in performing a particular payment transaction. The user processor selecting a first payment procedure including filling with data;
If the web page includes at least one of the hidden fields, at least one visible field included in the web page is used to send the purchase data to the merchant for use in performing the particular payment transaction. Selecting the second payment procedure including filling with purchase data for transmission. A computer-readable medium having a set of instructions that can direct a processor.

The first payment procedure further comprises the user processor receiving authentication data and the hidden data from a payment account issuer, wherein the hidden data comprises the authentication data, and wherein the authentication data is the payment account. 56. The computer readable medium according to claim 55, for authenticating the identity of the account holder of the payment account issued by the issuer.

The first payment procedure further comprises sending a request from the user processor to the payment account issuer to authenticate the identity of the account holder, and transmitting the authentication data from the payment account issuer to the user. 57. The computer readable medium of claim 56, wherein said medium is transmitted to said processor in response to said request to authenticate said identity of said account holder.

The first payment procedure further comprises:
Transmitting a permission request message obtained from the authentication data from the seller to a clearing house,
Transmitting at least one of the authorization request message and a message obtained from the authorization request message from the clearing house to the payment account issuer;
The payment account issuer utilizing a reconciliation procedure that processes the authorization request message and the at least one of the messages obtained from the authorization request message to generate an authorization response message;
Transmitting the authorization response message from the payment account issuer to the clearing house;
The computer-readable medium of claim 57, wherein at least one of the authorization response message and a message obtained from the authorization response message is transmitted from the clearing house to the merchant.

The first payment procedure further comprises:
A first permission request message obtained from the authentication data is transmitted from the seller to the acquirer,
Transmitting at least one of the first permission request message and a second permission request message obtained from the first permission request message from the acquirer to a clearing house;
The at least one of the first and second authorization request messages and at least one of a third authorization request message obtained from the at least one of the first and second authorization request messages to the clearing house From to the payment account issuer,
A reconciliation procedure for processing the at least one of the first and second authentication request messages and at least one of the third authorization request messages to utilize a first authorization response message; Used by the publisher,
Sending the first authorization response message from the payment account issuer to the clearing house;
Transmitting at least one of the first authorization response message and a second authorization response message obtained from the first authorization response message from the clearing house to the acquirer;
Acquiring at least one of the at least one of the first and second authorization response messages and a third authorization response message obtained from the at least one of the first and second authorization response messages to the acquirer 58. The computer readable medium of claim 57, wherein said medium is transmitted to said merchant.

The first payment procedure further comprises:
Transmitting a permission request message obtained from the authentication data from the seller to a clearing house,
Transmitting at least one of the authorization request message and a message obtained from the authorization request message from the clearing house to the payment account issuer;
The payment account issuer utilizing a reconciliation procedure that processes the authorization request message and the at least one of the messages obtained from the authorization request message to generate an authorization response message;
Transmitting the authorization response message from the payment account issuer to the clearing house;
The computer-readable medium of claim 56, wherein at least one of the authorization response message and a message obtained from the authorization response message is transmitted from the clearing house to the merchant.

The first payment procedure further comprises:
A first permission request message obtained from the authentication data is transmitted from the seller to the acquirer,
Transmitting at least one of the first permission request message and a second permission request message obtained from the first permission request message from the acquirer to a clearing house;
The at least one of the first and second authorization request messages and at least one of a third authorization request message obtained from the at least one of the first and second authorization request messages to the clearing house From to the payment account issuer,
A reconciliation procedure for processing the at least one of the first and second authorization request messages and at least one of the third authorization request messages to generate a first authorization response message. Used by the publisher,
Transmitting the first authorization response message from the payment account issuer to the clearing house;
Transmitting at least one of the first authorization response message and a second authorization response message obtained from the first authorization response message from the clearing house to the acquirer;
Acquiring at least one of the at least one of the first and second authorization response messages and a third authorization response message obtained from the at least one of the first and second authorization response messages to the acquirer 57. The computer readable medium of claim 56, wherein said medium is transmitted to said merchant.

The first payment procedure further comprises:
Transmitting a permission request message obtained from the hidden data from the seller to a clearing house,
Transmitting at least one of the authorization request message and a message obtained from the authorization request message from the clearing house to a payment account issuer;
The payment account issuer using a matching procedure to process the at least one of an authorization request message and a message obtained from the authorization request message to generate a first authorization response message;
Transmitting the first authorization response message from the payment account issuer to the clearing house;
The computer-readable medium of claim 55, wherein at least one of the authorization response message and an authorization response message obtained from the authorization response message are transmitted from the clearing house to the merchant.

The hidden data includes at least data associated with the particular payment transaction, and the matching processor includes:
A processor that determines whether the data associated with the particular payment transaction was previously used in any payment transaction;
63. The apparatus of claim 62, further comprising a processor for rejecting authentication of the authorization response message if the data associated with the particular payment transaction was previously utilized in any payment transaction.

The first payment procedure further comprises:
Transmitting a first permission request message obtained from the hidden data from the seller to the acquirer,
Transmitting at least one of the first permission request message and a second permission request message obtained from the first permission request message from the acquirer to a clearing house;
The at least one of the first and second authorization request messages and at least one of a third authorization request message obtained from the at least one of the first and second authorization request messages to the clearing house From to the payment account issuer,
A reconciliation procedure for processing the at least one of the first and second authorization request messages and at least one of the third authorization request messages to generate a first authorization response message. Used by the publisher,
Transmitting the first authorization response message from the payment account issuer to the clearing house;
Transmitting at least one of the first authorization response message and a second authorization response message obtained from the first authorization response message from the clearing house to the acquirer;
Acquiring at least one of the at least one of the first and second authorization response messages and a third authorization response message obtained from the at least one of the first and second authorization response messages to the acquirer 56. The computer readable medium of claim 55, wherein said medium is transmitted to said merchant.

The hidden data includes at least data related to the specific payment transaction, and the matching procedure includes:
The payment account issuer determining whether the data associated with the particular payment transaction was previously used to authenticate any payment transaction;
Rejecting authentication of said first authorization response message if said data associated with said particular payment transaction was previously used to authenticate any of the payment transactions. Computer readable media.

The first payment procedure further comprises:
Transmitting a permission request message obtained from the hidden data from the seller to a clearing house;
The clearing house using a verification procedure to process the authorization request message to generate an authorization response message;
Transmitting the authorization response message from the clearing house to the merchant.

The first payment procedure further comprises:
Transmitting a first permission request message obtained from the hidden data from the seller to the acquirer,
Transmitting at least one of the first permission request message and a second permission request message obtained from the first permission request message from the acquirer to a clearing house;
The clearing house uses a verification procedure that processes the at least one of the first and second authorization request messages to generate a first authorization response message;
Transmitting the first authorization response message from the clearing house to the acquirer;
The computer according to claim 55, wherein at least one of the first permission response message and a second permission response message obtained from the first permission response message is transmitted from the acquirer to the seller. Readable media.

A user processor receiving a set of web page data displaying a web page including at least one hidden field;
The user processor receives authentication data from the payment account issuer for authenticating the identity of the account holder of the payment account issued by the payment account issuer,
A computer readable processor-instructed set of instructions, wherein the at least one hidden field is filled by the user processor with the authentication data for transmitting the authentication data to a merchant. Medium.

The set of instructions may further be directed by the at least one processor to perform the following steps:
The request for authentication of the identity of the account holder and the authentication data transmitted from the payment account issuer to the user processor in response to the request for authentication of the identity of the account holder, 70. The computer readable medium of claim 68, wherein the transmission is from a user processor to the payment account issuer.

The first payment procedure may further include the step of instructing the at least one processor to perform the following steps:
Transmitting a permission request message obtained from the authentication data from the seller to a clearing house,
Transmitting at least one of the authorization request message and a message obtained from the authorization request message from the clearing house to the payment account issuer;
The payment account issuer utilizing a reconciliation procedure that processes the authorization request message and the at least one of the messages obtained from the authorization request message to generate an authorization response message;
Transmitting the authorization response message from the payment account issuer to the clearing house;
70. The computer-readable medium of claim 69, wherein at least one of the authorization response message and a message obtained from the authorization response message is transmitted from the clearing house to the merchant.

The set of instructions may further be directed by the at least one processor to perform the following steps:
A first permission request message obtained from the authentication data is transmitted from the seller to the acquirer,
Transmitting at least one of the first permission request message and a second permission request message obtained from the first permission request message from the acquirer to a clearing house;
The at least one of the first and second authorization request messages and at least one of a third authorization request message obtained from the at least one of the first and second authorization request messages to the clearing house From to the payment account issuer,
A reconciliation procedure for processing the at least one of the first and second authorization request messages and at least one of the third authorization request messages to generate a first authorization response message. Used by the publisher,
Transmitting the first authorization response message from the payment account issuer to the clearing house;
Transmitting at least one of the first authorization response message and a second authorization response message obtained from the first authorization response message from the clearing house to the acquirer;
The at least one of the first and second authorization response messages and the at least one of the third authorization response messages obtained from the at least one of the first and second authorization response messages, 70. The computer readable medium of claim 69, wherein the medium is sent to a merchant.

The set of instructions may further be directed by the at least one processor to perform the following steps:
Transmitting a permission request message obtained from the authentication data from the seller to a clearing house,
Transmitting the permission request message and a message obtained from the permission request message from the clearing house to the payment account issuer;
The payment account issuer utilizing a reconciliation procedure that processes the authorization request message and the at least one of the messages obtained from the authorization request message to generate an authorization response message;
Transmitting the authorization response message from the payment account issuer to the clearing house;
The computer-readable medium of claim 68, wherein at least one of the authorization response message and a message obtained from the authorization response message is transmitted from the clearing house to the merchant.

The set of instructions may further be directed by the at least one processor to perform the following steps:
A first permission request message obtained from the authentication data is transmitted from the seller to the acquirer,
The second permission request message obtained from the first permission request message and the first permission request message, transmitted from the acquirer to a clearing house,
Providing at least one of the first and second authorization request messages and at least one of the third authorization request messages obtained from the at least one of the first and second authorization request messages from the clearing house to the Send to payment account issuer,
A matching step of processing the at least one of the first and second authorization request messages and the at least one of the third authorization request messages to generate a first authorization response message; Used by the account issuer,
Transmitting the first authorization response message from the payment account issuer to the clearing house;
Transmitting at least one of the first authorization response message and a second authorization response message obtained from the first authorization response message from the clearing house to the acquirer;
The at least one of the first and second authorization response messages and the at least one of the third authentication response messages obtained from the at least one of the first and second authorization response messages from the acquirer, 70. The computer readable medium of claim 68, for transmission to a merchant.

The set of instructions may further be directed by the at least one processor to perform the following steps:
Transmitting a permission request message obtained from the authentication data from the seller to a clearing house,
The clearing house uses a verification procedure to process the authorization request message to generate an authorization response message;
The computer readable medium of claim 68, wherein the authorization response message is transmitted from the clearing house to the merchant.

The set of instructions may further be directed by the at least one processor to perform the following steps:
A first permission request message obtained from the authentication data is transmitted from the seller to the acquirer,
Transmitting at least one of the first permission request message and a second permission request message obtained from the first permission request message from an acquirer to a clearing house;
The clearing house uses a verification procedure that processes the at least one of the first and second authorization request messages to generate a first authorization response message;
Transmitting the first authorization response message from the clearing house to the acquirer;
70. The seller of claim 68, wherein at least one of the first authorization response message and a second authorization response message obtained from the first authorization response message is transmitted from the acquirer to the seller. A computer readable medium.

A user processor receiving a first set of web page data displaying a first web page;
Determining whether the first web page includes a first hidden field to notify the user's software that the first web page is available to perform a one-click payment procedure; Determining by the user processor;
If the first web page includes the first hidden field, the first hidden page is provided with data for notifying a merchant of using the user's software to perform at least one payment transaction. Computer-readable medium having a set of instructions that can direct the processor.

The set of instructions further comprises receiving the signal from the account holder to select a single click payment procedure utilizing the first web page from the account holder. 77. The method of claim 76, wherein is can be directed.

The set of instructions further comprises:
The user processor receiving a second set of web page data representing a second web page including a second hidden field and a hidden button;
Filling the second hidden field with authentication data for authenticating an account holder's identity to send the authentication data to the merchant;
Wherein the user processor can direct the at least one processor to click on the hidden button to initiate transmission of the authentication data to the merchant. 78. The method of claim 77.

The set of instructions further comprises:
The method according to claim 1, wherein the at least one processor is operable to receive the authentication data from the payment account issuer that issued a payment account to the account holder. 78. The method of claim 78.

The set of instructions further comprises:
Transmitting a permission request message obtained from the authentication data from the seller to a clearing house;
Sending at least one of the messages obtained from the authorization request message from a clearing house to a payment account issuer;
The payment account issuance using a reconciliation procedure that processes the authorization request message and the at least one of the messages obtained from the authorization request message to generate an authorization response message;
Sending an authorization response message from the payment account issuer to the clearing house;
80. The processor of claim 79, wherein the at least one processor is operable to send at least one of an authorization response message and a message obtained from the authorization response message from a clearing house to a merchant. Computer readable media.

Sending a first authorization request message obtained from the authentication data from the merchant to the acquirer;
Transmitting at least one of a first authorization request message and a second authorization request message obtained from the first authorization request message from the acquirer to the clearing house;
A payment account issuer from a clearing house for at least one of the third authorization request messages obtained from the first and second authorization request messages and at least one of the first and second authorization request messages; Sending to
A payment account issuer processes the at least one of the first and second authorization request messages and the at least one of the third authorization request messages to generate a first authorization response message. Using a matching procedure for
Sending a first authorization response message from the payment account issuer to the clearing house;
Sending at least one of a first authorization response message and a second authorization response message obtained from the first authorization response message from the clearing house to the acquirer;
Providing at least one of the third authorization response message obtained from at least one of the first and second authorization response messages and the first and second authorization response messages from the acquirer to the seller; 80. The computer-readable medium of claim 79, wherein the set of instructions is further operative to direct the at least one processor to perform the steps of transmitting.