JP2004500671A - コンピューターネットワークを介して安全な支払いを実行する改良方法及びシステム - Google Patents

Abstract

購入者がアクワイヤラー銀行を有する店と通信ネットワークを介して金融取引を行う方法を提供する。本発明の方法では、第１の許可要求を実アカウント番号と関連する仮アカウント番号を用いてサービスプロバイダに送り、サービスプロバイダが第２の許可要求を実アカウント番号となるべくサービスプロバイダと関連する仮アクワイヤラーコードとを用いて発行者に転送し、第２の要求に対する応答がサービスプロバイダに返送され、このサービスプロバイダがなるべく実アカウント番号に基づいて、第１の要求に対する応答をなるべく「実」アクワイヤラーに送るようにする。取引データを含むメッセージ認証コードを更に生成し、許可要求を、任意フィールドを含む１以上のフィールドを有する標準支払用カードトラックのようにフォーマットし、任意フィールドにメッセージ認証コードを配置する。

Description

【０００１】
（優先権出願）
本願は米国仮出願６０／１９５，８６３、２０００年４月１１日出願、発明の名称“Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｃｏｎｄｕｃｔｉｎｇ Ｓｅｃｕｒｅ Ｐａｙｍｅｎｔｓ Ｏｖｅｒ Ａ Ｃｏｍｐｕｔｅｒ Ｎｅｔｗｏｒｋ”（この出願は参考のためにここに包含されている）及び米国特許出願第０９／８０９，３６７号、２００１年３月１５日出願、発明の名称“Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｃｏｎｄｕｃｔｉｎｇ Ｓｅｃｕｒｅ Ｐａｙｍｅｎｔｓ Ｏｖｅｒ Ａ Ｃｏｍｐｕｔｅｒ Ｎｅｔｗｏｒｋ” （この出願も参考のためにここに包含されている）を優先権主張するものであります。
【０００２】
（技術分野及び発明の背景）
本発明は、通信ネットワークを介して安全な金融取引を実行する方法及びシステム、特にインターネットのようなコンピュータネットワークを介して支払いを安全に送信する方法及びシステム、及び公衆通信チャネルを介して機密情報を安全に送信する方法及びシステムに関するものである。
自明のように、オンラインコマースはここ数年の間にものすごい成長をとげているが、依然として多くの消費者がトラブルにみまわれ、個人金融情報をインターネットのような公衆ネットワークを介して利用することやクレジットカード番号や個人識別番号のような情報をインターネットのような公衆通信ネットワークを介して送信することに心配をぬぐえないでいる。その結果として、ここ数年間に亘って、多くの会社がコンピュータネットワークを介して行われる支払いのセキュリティを保証し、金融情報の盗聴や悪用の危険を低減させる最良の方法を見つける努力をしている。
【０００３】
例えば、マイクロソフトに譲渡された米国特許第５，８８３，８１０号「Ｅｌｅｃｔｒｏｎｉｃ Ｏｎｌｉｎｅ Ｃｏｍｍｅｒｃｅ Ｃａｒｄ Ｗｉｔｈ Ｔｒａｎｓａｃｔｉｏｎ Ｐｒｏｘｙ Ｎｕｍｂｅｒ Ｆｏｒ Ｏｎｌｉｎｅ Ｔｒａｎｓａｃｔｉｏｎｓ（オンライン取引用のトランザクションプロキシ番号付き電子オンラインコマースカード）」は、各取引ごとに、一時的取引番号を付与し、該取引番号を永久アカウント番号と関連させるシステムを開示している。このシステムでは、取引番号を実クレジットカード番号のようにみなせ、顧客はこの取引番号を使用し、これを加盟店に顧客アカウント番号の代りとして提出することができる。このシステムでは、顧客は自分の実クレジットカード番号を公衆ネットワークを介して送信する必要はない。
【０００４】
上記の第５，８８３，８１０号特許では、加盟店は取引番号を発行機関に送り、発行機関はこの取引番号をインデックスとして用いて実顧客アカウント番号をアクセスし、許可処理を行い、許可応答を取引番号の下で加盟店に返送する。その結果として、危険は最小になる。その理由は、顧客は取引番号を送るのみであるため、並びに代理番号は一回の買い物又は取引にのみ有効で、他の買い物又は取引に対し繰り返し使用できないため、盗聴するには極めて不利であるためである。（第２欄，第６０−６１行参照）。
【０００５】
従来のシステムは改良の必要があり、特に各取引の実行ごとに、永久アカウント番号の送信の代わりに繰り返し発生される一意の取引番号の生成及び送信を行う必要なしに、安全な商取引をインターネットを介して実行する方法及びシステムが必要とされている。
【０００６】
同時継続出願０９／８０９，３６７号（２００１年３月１５日出願）の発明では、「仮」アカウント番号を顧客に割り当て、顧客の支払いアカウント番号に暗号化してリンクさせる。支払いアカウント番号は，消費者が品物及び／又はサービスの支払いのために使用できる金融機関や他の機関により発行されたアカウント番号である。例えば、支払いアカウント番号はクレジットカードやデビットカードのような支払用カードからのアカウント番号、或いは顧客のコンピュータに格納されている電子マネーアプリケーションのような支払いアプリケーションのアカウントからのアカウント番号とすることができる。仮アカウント番号は加盟店には実支払いアカウント番号のように見える。即ち、仮アカウント番号は正当な支払いアカウント番号と同一の長さを有し、正当な識別番号（例えば、マスターカードインターナショナルインコーポレーテッド（「マスターカード」）に対しては”５”）で始まる。仮アカウント番号は顧客により顧客の全てのオンライン商取引に対して実アカウント番号の代わりに使用される。
【０００７】
この同時継続出願の発明では、仮アカウント番号に基づく全ての取引を、各アカウント番号ごとに一意の秘密鍵を用いて暗号化して認証を行うのが好ましい。この認証は、公開鍵ペアの個人鍵に基づくもの（公開鍵認証）又は個人鍵以外の秘密鍵に基づくもの（秘密鍵認証）とすることができる。このようにすると、無許可の人が仮アカウント番号を突きとめたとしても、仮アカウント番号を用いて不正な取引を行うことはできない。
【０００８】
このシステムは更に改良すべきであり、セキュリティを更に向上させて、公衆通信ラインを介して行われている商取引中送信されるメッセージや情報を保護すべきである。
【０００９】
（発明の開示）
それゆえ、本発明では、支払いネットワークを用いて取引を行う方法において、サービスプロバイダは取引の許可（ａｕｔｈｏｒｉｚａｔｉｏｎ）に対する第１の許可要求を第１の支払いアカウント番号を用いて受信し、
（ｉ） 第１の支払いアカウント番号は前記サービスプロバイダと関連す
るＢＩＮコードを有するとともに第２の支払いアカウント番号と関連し、
第２の支払いアカウント番号は該第２の番号の発行者と関連するＢＩＮコ
ードを有し、
（ｉｉ） 前記第１の許可要求はアクワイヤラー（ａｃｑｕｉｒｅｒ）と関連するアク
ワイヤラーコードを含み、
（ｉｉｉ） 前記第１の許可要求は、第１の支払いアカウント番号のＢＩＮコー
ドに基づいて、支払いネットワークを経て前記サービスプロバイダに送る
ことができることを特徴とする。
【００１０】
本発明の方法は、更に、前記第１の許可要求に応答して、前記サービスプロバイダは、前記取引の許可に対する第２の許可要求を第２の支払いアカウント番号を用いて送信し、第２の許可要求は該サービスプロバイダと関連する第２のアクワイヤラーコードを含むと共に、前記第２のＢＩＮコードに基づいて、支払いネットワークを経て前記発行者に送ることができることを特徴とする。
【００１１】
更に、第２の許可要求に対する前記発行者からの応答を前記サービスプロバイダにより受信し、該応答は前記サービスプロバイダと関連するアクワイヤラーコードを含み、該コードに基づいて、支払いネットワークを経て送ることができることを特徴とする。更に、第１の許可要求に対する応答が前記サービスプロバイダにより、前記第２の許可要求に対する応答に基づいて、アクワイヤラーに送信され、前記第１の許可要求に対する応答はアクワイヤラーと関連するアクワイヤラーコードを含み、該コードに基づいて支払いネットワークを経て送ることができる。
【００１２】
本発明の他の好適実施例では、通信ネットワークを介する加盟店（ｍｅｒｃｈａｎｔ）との取引を、第２の支払いアカウント番号と関連する第１の支払いアカウント番号を用いて実行する方法において、
（ａ） 一つ以上の取引明細に基づいてメッセージ認証コードを生成し、
（ｂ） 少なくとも前記第１の支払いアカウント番号とメッセージ認証コードを加盟店に送信し、
（ｃ） 加盟店が取引の支払いに対する許可を前記第１の支払いアカウント番号を用いて要求し、該要求は、あたかも支払いが慣例の磁気支払用カードでポイントオブセールス（ＰＯＳ）端末で行われるようにフォーマットされ、該フォーマットは少なくとも任意データフィールドを含むトラックを有するものとし、該フィールドで前記メッセージ認証コードを送信し、
（ｄ） 前記第１の支払いアカウント番号に対する許可要求に応答して、前記取引の支払いに対する許可を前記第２の支払いアカウント番号を用いて要求し、
（ｅ） 前記第２の支払いアカウント番号及びメッセージ認証コードに対する許可要求に対する応答に基づいて、前記第１の支払いアカウント番号に対する許可要求を受諾又は拒否することを特徴とする。
【００１３】
本発明の目的、特徴及び利点は本発明の好適実施例を示す添付図面について以下に記載する詳細な説明から更に明らかになる。
全図を通して、断らない限り、同一の符号及び番号は図示の実施例の同一の構成要素や構成部分やコンポーネントを示す。更に、本発明の要旨を図面を参照して好適実施例と関連して詳細に説明するが、特許請求の範囲で限定する本発明の範囲及び精神から逸脱することなく、多くの変更を加えることができること勿論である。
【００１４】
（適実施例の詳細な説明）
安全支払いアプリケーション （Ｓｅｃｕｒｅ Ｐａｙｍｅｎｔ Ａｐｐｌｉｃａｔｉｏｎ） の初期化
本発明の好適実施例では、サービスプロバイダは、本発明の技術に従って実行すべき安全支払いシステムの安全支払いアプリケーション（ＳＰＡ）を含むいくつかのコンポーネントを発行、保守及び／又は処理する。
【００１５】
図１は、最初に、金融取引カードを保持するカード所有者がどのようにして安全支払いアプリケーションをサービスプロバイダ１０からインターネットを介して得ることができるかを示したものである。最初に、本発明の利点を利用及び獲得するためには物理的カードは不要であり、金融取引を行うためにユーザ又は関係者を識別するとともにアカウントにリンクするアカウント番号を所有者（この場合にはカード所有者）に発行するだけであることを理解する必要がある。カード所有者は、インターネットを介して通信できるコンピュータや携帯電話や携帯情報端末（ＰＤＡ）などの任意の適切なデバイスを用いて、サービスプロバイダと関連するウエブサーバにコンタクトすることができる。以下の説明を簡単とするために、カード所有者はインターネットを介して通信するためにコンピュータを使用するものとする。
【００１６】
図１に示すように、サービスプロバイダ、例えばマスターカードインターナショナルインコーポレーテッド（又はマスターカードの代理業者）はその制御下に１以上の物理的セキュアセキュリティモジュール１２を有する。これらのセキュリティモジュールはモジュール内に格納された情報の物理的保護を提供する。各セキュリティモジュールは１以上の「誘導鍵」を含み、これらの誘導鍵は、以下に説明するように、アカウント固有の秘密暗号鍵を生成及び再生成するために使用され、生成及び再生成された秘密鍵は安全支払いアプリケーションに付与される。
【００１７】
最初に、本発明の好適実施例では、カード所有者はサービスプロバイダから安全支払いアプリケーション（ＳＰＡ）を得る必要がある。ＳＰＡをダウンロードし初期化する好適な手順は、
１．　カード所有者はインターネットを介してサービスプロバイダのウエブサイトに（直接或いは発行者のウエブサイトのような他のウエブサイトを経由して当該ウエブサイトに至るハイパーリンクを経て）コンタクトする。
２．　カード所有者は、当業者に公知のＳＳＬ暗号方式の下で、（ａ）支払用カードアカウント番号、（ｂ）カード有効期限及び（ｃ）カード認証情報を送る。カード認証情報は、例えばカードのＣＶＣ２ｖａｌｕｅを含むことができる。ＣＶＣ２ｖａｌｕｅはカードの署名パネルの隣に印刷される３桁又は４桁の値である。
３． サービスプロバイダは、カードアカウント番号及びカード有効期限の正当性を、カード所有者の支払用カードの発行者からゼロアマウント許可を得ることにより確認する。例えば、マスターカードはこの許可をＢａｎｋｎｅｔ（商標）通信ネットワークを介して得ることができる。
４． サービスプロバイダは、カード所有者の支払用カードの発行者がサービスプロバイダにＣＶＣ２ｖａｌｕｅを検証するための暗号鍵を提供した場合に、ＣＶＣ２ｖａｌｕｅを検証することができる。
５． サービスプロバイダは、他のカード認証情報を検証のために発行者に送ることにより他のカード認証情報を検証することができる。
６． サービスプロバイダ（ＳＰ）がカード所有者提供カードデータの正当性を確認した後、ＳＰは仮アカウント番号及び秘密鍵を生成又は選択し、これらのデータ要素を安全支払いソフトウエアアプリケーションに埋込み、インターネットを介してＳＳＬ暗号方式の下で行うのが好ましいダウンロードのためにこのアプリケーションをカード所有者に使用可能にする。
【００１８】
仮アカウント番号はそのＢＩＮとして仮アカウント番号用に確保された特殊ＢＩＮを有する。仮アカウント番号の残りは、サービスプロバイダがテーブルルックアップ処理により「実」アカウント番号に翻訳することができる値である。
【００１９】
割り当てられた特殊サービスプロバイダＢＩＮは多数のこのような特殊ＢＩＮの組の中の一つとすることができ、この場合には各ＢＩＮは特定の国又は地域及び／又は国又は地域内の特定の製品に対応させることができる。従って、割り当てられる特殊ＢＩＮは提示された「実」アカウント番号の国及び／又は製品に対応するものとすることができる。
【００２０】
サービスプロバイダがＳＰＡに埋め込むのが好ましい秘密鍵は各カードアカウント番号ごとに一意であり、そのカードアカウント番号と誘導鍵を用いてセキュリティモジュール内で導出するのが好ましい。この誘導鍵自体も同一の又は他のセキュリティモジュール内で高レベル誘導鍵を用いて導出することができる。
【００２１】
カード所有者は、安全支払いアプリケーションをダウンロードする前にパスワードをサービスプロバイダに供給するか、或いは安全支払いアプリケーションをカード所有者のコンピュータにインストールしているときにパスワードを選択することができる。パスワードを供給或いは選択する場合、その後カード所有者は安全支払いアプリケーションを起動するためにこのパスワードを入力することを要求される。カード所有者により選択されたパスワードはＳＰＡに含まれる秘密鍵を暗号化するのに使用することができる。
【００２２】
当業者であれば認識されるように、ＳＰＡはディジタルワレット（電子財布）アプリケーションの一部分としてダウンロードすることができる。ＳＰＡに加えて、ディジタルワレットはカード所有者の個人情報とパース（財布）アプリケーションのような他のアプリケーションを格納することができる。
【００２３】
カード固有秘密鍵の生成
以下の手順をサービスプロバイダ又はその代理業者により制御されるセキュリティモジュール１２内で実行して安全支払いアプリケーションに含めるカード固有秘密鍵を得るのが好ましい。以下の手順は、カード所有者の支払用カードが１６桁のアカウント番号を有するものとし、且つ当業者に既知のデータ暗号アルゴリズム（ＤＥＡ）を２倍長鍵とともに使用するものとする。ＤＥＡは米国政府標準暗号アルゴリズムであり、連邦情報処理規格（ＦＩＰＳ）４６−１に記載されており、その全てがここに含まれているものとする。ＤＥＡはＡＮＳＩ規格Ｘ９．３２にも定義されており、その全てもここに含まれているものとする。
【００２４】
セキュリティモジュールは１６バイトからなる誘導鍵というセキュア高レベル鍵を保持し、この誘導鍵を多数の又は全てのカードアカウント番号と一緒に使用し、カード所有者の１６桁の支払いアカウント番号を与えられると、パー・カード鍵（カード単位鍵）というカード固有秘密鍵を暗号手法で計算する。誘導鍵は各国ごとに、或いは各特殊バンク識別番号又はＢＩＮごとに一意にすることができる。
【００２５】
好ましくは、手順は次のとおりである。
１．　支払いアカウント番号を各４ビットの１６桁の２進化１０進数とみなし、１６バイト誘導鍵の左側の８バイトを暗号化鍵として用いてこれらの６４ビットをＤＥＡ暗号化する。
２．　手順１の結果を１６バイト誘導鍵の右側の８バイトを復号鍵として用いてＤＥＡ復号化する。
３．　手順２の結果を１６バイト誘導鍵の左側の８バイトを（再び）暗号鍵として用いてＤＥＡ暗号化する。
４．　手順３の結果を固有パー・カード鍵の左側の８バイトとして使用する。
５．　手順３の結果を１６バイト誘導鍵の左側の８バイトを暗号鍵として用いてＤＥＡ暗号化する。
６．　手順５の結果を１６バイト誘導鍵の右側の８バイトを復号鍵として用いてＤＥＡ復号化する。
７．　手順６の結果を１６バイト誘導鍵の左側の８バイトを（再び）暗号鍵として用いてＤＥＡ暗号化する。
８．　手順７の結果を１６バイト固有パー・カード鍵の右側の８バイトとして使用し、この鍵を安全支払いアプリケーション内に、このアプリケーションの通常の動作中にこの鍵が暴露されないように置く。
【００２６】
カード所有者と加盟店との通信
図２は、本発明の代表的な実施例に従ってインターネットを介して安全支払いを実行する際のカード所有者１４と加盟店１６との間の情報の流れを示す。
ＳＰＡがカード所有者のコンピュータにインストールされたら、カード所有者はＳＰＡを全てのインターネット支払いに使用するのが好ましく、ＳＰＡが全てのインターネット取引に対しカード所有者の仮アカウント番号を提供する。
【００２７】
カード所有者が取引を行いたい希望を指示したら、加盟店はカード所有者のコンピュータに次のデータ要素：（１）アクワイヤラーＢＩＮ、（２）ＭＩＤ（アクワイヤラーに既知の加盟店識別子）及び取引の日時（ＧＭＴ又は等価時間）を送るのが望ましい。
【００２８】
好ましくは、ＳＰＡはそれに埋め込まれた秘密鍵を用いて取引に関するメッセージ認証コード（ＭＡＣ）を生成する。例えば、約８桁の１０進数のＭＡＣを次のデータ要素に基づいて生成することができる。
１． カード所有者のＳＰＡに格納され且つＳＰＡがＭＡＣを発生するたびにＳＰＡによりインクリメントされる取引シーケンス番号。この取引シーケンス番号は、例えば６桁の１０進数とすることができる。
２． 加盟店から受信されるＢＩＮ、受信されなければゼロ（ＢＩＮは、例えば６桁の１０進数とすることができる）。
３． 加盟店から受信されるＭＩＤ、受信されなければゼロ（ＭＩＤは、例えば６桁の１０進数とすることができる）。
４． 加盟店から受信される日付け及び時刻（最も近い時間または分）（ＧＭＴ）、受信されなければゼロ（日付は、例えば１０桁の１０進数とすることができる）。
５． カード所有者のために表示され、通常カード所有者から加盟店へのメッセージに含まれる取引額（取引額は、例えば８桁の１０進数とすることができる）。
【００２９】
加盟店はカード所有者のコンピュータからフルトラック−１イメージを、あたかも加盟店が磁気ストライプリーダを含むコンピュータと通信するかのように受信可能とするのが好ましい。（トラック−１イメージは支払用カードの磁気ストライプのトラック１上のデータをいう。）更に、加盟店はトラック−１データをアクワイヤラーに、まるで取引がポイントオブセールス（ＰＯＳ）取引であるように送ることができるのが好ましい。
【００３０】
加盟店がフルトラック−１データを受け取ることができる場合には、ＭＡＣ自体及びＭＡＣの基礎をなすデータ要素はトラック−１の任意データフィールド（任意に使用可能なデータフィールド）に置かれる。仮アカウント番号はトラック−１のアカウント番号フィールドに置かれ、カード有効期限データはトラック−１の有効期限フィールドに置かれる。
【００３１】
ＭＡＣをトラック−１の任意データフィールドで送ることにより、多くの加盟店はそれぞれのシステム及び／又はソフトウエアを変更する必要がない。その理由は、これらの加盟店はトラック−１の任意データを含むＰＯＳ取引をすでに処理することができるためである。他の加盟店は、ＰＯＳを処理するシステム及び／又はソフトウエアを容易に使用可能にすることができる。
【００３２】
加盟店がフルトラック−１データを受信できない場合には、仮アカウント番号をカード所有者の「実」アカウント番号の代わりに使用することを除いて、ＳＰＡは慣例のＳＳＬ支払いメッセージを送ることができる。加盟店は次に取引データを通常のごとくアクワイヤラーに送る。実際には、取引期間中、ＰＯＳ取引をトラック−１データで処理できない加盟店はＭＡＣを受信し処理する必要がないかもしれない。
【００３３】
ＭＡＣは、トラック−１の任意データフィールドで送る代わりに、他のフォーマットで送ることもでき、この場合には加盟店とアクワイヤラーはそれぞれのシステム及び／又はソフトウエアをこの他のフォーマットを処理するように変更する必要がある。
【００３４】
カード所有者の取引メッセージの受信時に、加盟店はアクワイヤラーに対し慣例の許可要求をフォーマットする。トラック−１データを受け取ることができる加盟店は、この許可要求を、あたかもこれがＰＯＳ端末から発生したかのように正確にフォーマットし、カード所有者により供給されたトラック−１データに含める。
【００３５】
加盟店がカード所有者取引に対し多数の許可／清算取引（ｍｕｌｔｉｐｌｅ ａｕｔｈｏｒｉｚｉｎｇ／ｃｌｅａｒｉｎｇ ｔｒａｎｓａｃｔｉｏｎｓ）を開始する場合には、これらの取引の最初の取引のみをトラック−１データに含めるのが好ましい。後続の取引は仮アカウント番号と有効期限データのみを含み、通信販売取引とみなすことができる。これは、多数の清算を伴う定期循環支払いや分割支払いの全てに対し真である。
【００３６】
許可要求のアクワイヤラー処理
図３は、本発明の代表的実施例におけるアクワイヤラー１８と、サービスプロバイダ１０と、発行者２０との間の通信を示す。
インターネット取引におけるトラック−１データの存在はインターネット加盟店から慣例の電話線を介して受信するアクワイヤラーに悪影響を与えないようにすべきである。その理由は、このような取引は慣例のＰＯＳ端末からの取引と同一にフォーマットされるためである。しかし、（慣例の電話ではなく）インターネットを介して取引を受信するアクワイヤラーは、トラック−１データなしの取引はそのまま配達するとともにトラック−１データを用いる取引は、あたかも該取引がＰＯＳ端末から到来するかのように、異なる物理的ワイヤを経て配達する「変換ボックス」を必要とする。このような変換ボックスの設計は当業者が容易に実施し得る範囲のことである。
【００３７】
アクワイヤラー１８がインターネット加盟店１６から許可要求メッセージを受信すると、アクワイヤラー１８は発行者ＢＩＮをそのＢＩＮテーブルでルックアップする。仮アカウント番号取引の場合には、「発行者」はサービスプロバイダの許可プロセッシングファシリティ１０に対応し、これがこの要求を受信する。仮アカウント番号でなく実アカウント番号の場合には、通常の処理が行われる。
【００３８】
いくつかの国はドメスティック（国内）取引を処理する特殊セキュリティモジュールを具えたファシリティを有し得る。このようなドメスティックファシリティの各々はサービスプロバイダの同意が得られる場合にのみセットアップするとともに、暗号鍵とアカウント番号変換データをその国の取引の処理のために保持するだけとするのが好ましい。このようなドメスティックファシリティを有する国では、全ての同一国の取引がこのファシリティに送られる。これは、望ましいなら、国内の個々の銀行に対し行うこともできる。
ドメスティック取引を処理するドメスティックファシリティはドメスティック取引を中央処理ファシリティに行わせるよりも遥かに効率が良い。
【００３９】
許可要求のサービスプロバイダ処理
サービスプロバイダは要求を受信すると、発行者ＢＩＮから、アカウント番号が本当に仮アカウント番号であるか決定し、そうであれば、取引を特殊処理システムに送る。このシステムはテーブルルックアップ手法を用いて仮アカウント番号を「実」アカウント番号に変換する。システムが、トラック−１イメージが含まれていることを決定する場合には、システムはセキュリティモジュールを用いてこのカードアカウント番号に対し適切なカード毎の鍵（Ｐｅｒ Ｃａｒｄ Ｋｅｙ）をＭＡＣの検証のために導出する。
【００４０】
ＭＡＣを検証したら、システムはトラック−１の任意データエリア内のＢＩＮを検査する。ＢＩＮがすべてゼロでない場合には、システムはこのＢＩＮを取引のアクワイヤラーＢＩＮと比較し、（加盟店はその取引を一括処理し、遅延した許可を得ることがあることを考慮に入れて）トラック−１の任意データエリアに含まれるデータ及び時間が正当であることを検証する。システムは、更に、許可要求額がトラック−１任意データエリア内の取引額（カード所有者により許可された額）を規定額（例えば２０％）以上超えないことを検証する。
【００４１】
アクワイヤラーはアクワイヤラーリファレンスデータ（アクワイヤラーリファレンス番号ともいう）内にＭＩＤを含むことができる。２３桁のアクワイヤラーリファレンスデータは必須「取引タイプ」インジケータ及び必須アクワイヤラ−ＢＩＮを含むものとするが、残りの桁はアクワイヤラーの任意使用用であり、場合によりＭＩＤを含むことができるものとする。サービスプロバイダはそのインターネットアクワイヤラーから、アクワイヤラーリファレンスデータ内にＭＩＤを含むアクワイヤラーの指示を得ることができ、もしそうなら、これらのアクワイヤラーはアクワイヤラーリファレンスデータ内にＭＩＤを含む。このようなアクワイヤラーの場合には、トラック−１イメージがアクワイヤラーＢＩＮを含む場合、サービスプロバイダシステムはトラック−１任意データエリア内のＭＩＤがアクワイヤラーリファレンスデータ内のＭＩＤと一致することも検証することができる。
【００４２】
サービスプロバイダシステムは、許可要求内の取引シーケンス番号との比較用に取引シーケンス番号（ＴＳＮ）の履歴を蓄積することができる。この比較はある条件、例えばトラック−１の額が規定のしきい値（たとえば＄２００）を超えるときにトリガすることができる。このようなしきい値は、トラック−１イメージがアクワイヤラーＢＩＮを含まないときは低くすることができる。比較がトリガされると、システムはトラック−１任意データエリアに含まれる取引シーケンス番号を当該カードアカウント番号に対する取引シーケンス番号の蓄積履歴と比較することができる。現取引の取引シーケンス番号が（１）現アカウント番号に対する最小蓄積値より高く且つ（２）このアカウントに対する如何なる蓄積値にも一致しない場合には、現取引は先の正当取引からの不正なデータ再生ではないという妥当な保証が得られる。
【００４３】
ＴＳＮの蓄積履歴は所定数のＴＳＮに制限することができる。例えば、システムは特定のカードアカウント番号に対し受信された最新の１０個の取引シーケンス番号を蓄積することができる。更に、取引シーケンス番号の検証はリアルタイムで行う必要はない。この検証はシステムが発行者から許可を得ている間に行うことができる。
【００４４】
これらの検査の目的は、インターネット加盟店と結託して暗号化されてない取引データを得ることができる犯罪者が正当な取引からデータを不正に再生することを極めて困難にすることにある。
【００４５】
サービスプロバイダシステムが上述した検証処理を終了したら（取引シーケンス番号検証の例外があり得る）、システムは発行者２０に対する許可要求メッセージをフォーマットする。このメッセージは「実」アカウント番号と有効期限を含むが、他のトラック−１データを除外する。システムはアクワイヤラーＢＩＮを「仮」アクワイヤラーＢＩＮとして作用する特殊ＢＩＮと置き換える。アクワイヤラーＢＩＮは、発行者がアクワイヤラーの代わりにサービスプロバイダに応答するように置き換えられる。
【００４６】
アクワイヤラーと発行者がインターチェンジフィー（売上交換手数料）を正しく計算するためには、仮アクワイヤラーＢＩＮは、アクワイヤラーが位置する国又は同一のインターチェンジフィーを出力する他の国或いは地域に対応させるのが好ましい。各国が国と関連する特殊ＢＩＮを有する場合には、サービスプロバイダはアクワイヤラーＢＩＮをアクワイヤラーの国と関連する特殊ＢＩＮと置き換えることができる。アクワイヤラーの国が国と関連する特殊ＢＩＮを持たない場合には、同一のインターチェンジフィーを生ずる他の国と関連する特殊ＢＩＮを選択することができる。
【００４７】
サービスプロバイダはデータベースに、アクワイヤラーからの許可要求で受信されたアクワイヤラーリファレンスデータ（以後「原アクワイヤラーリファレンスデータ」という）を格納する。発行者に対する許可メッセージのフォーマッティングにおいて、サービスプロバイダは原アクワイヤラーリファレンスデータを、仮アクワイヤラーＢＩＮと、適切な取引タイプインジケータと、サービスプロバイダが原アクワイヤラーリファレンスデータを見つけ出すために使用し得るインデックス値とを含む「仮」アクワイヤラーリファレンスデータと置き換える。
【００４８】
ドメスティックファシリティが仮アカウント番号取引を処理するとき、このファシリティは上述のように動作する。しかし、このドメスティックファシリティはドメスティック発行者に対する取引のみを処理し、その結果、暗号鍵と当該国に適用されるアカウント番号変換テーブルエントリーを必要とするだけとするのが好ましい。
【００４９】
許可要求の発行者処理
図４は、本発明の代表的実施例における発行者がサービスプロバイダから又は許可されたドメスティックプロセッシングファシリティから許可要求を受信した後の発行者２０とサービスプロバイダ１０とアクワイヤラー１８との間の通信を示す。
【００５０】
発行者２０は取引を任意の他の取引と同様に許可する。発行者は許可応答を「仮」アクワイヤラーＢＩＮに返送し、これはサービスプロバイダファシリティかサービスプロバイダにより許可されたファシリティのいずれかである。
【００５１】
サービスプロバイダ１０は発行者からの許可応答を受信すると、アクワイヤラーＢＩＮを検査してそれが「仮」アクワイヤラーＢＩＮであるか決定する。そうであれば、サービスプロバイダは、許可応答が原フォーマットに「復元」する必要がある仮アカウント番号取引に対応することを決定する。従って、サービスプロバイダは「実」アカウント番号を仮アカウント番号に変換し、原取引内にあったアクワイヤラーリファレンスデータを復元する。次にサービスプロバイダは得られたメッセージを「実」アクワイヤラーに送信し、実アクワイヤラーは取引を通常のごとく処理し、許可応答を加盟店へ通常の方法で送る。加盟店は許可応答に、他の取引の場合のように応答する。
【００５２】
決済及び清算（ Ｓｅｔｔｌｅｍｅｎｔ ａｎｄ Ｃｌｅａｒｉｎｇ ）
図５は本発明の代表的な実施例における決済や清算のための加盟店１６とアクワイヤラー１８と、サービスプロバイダ１０又は支払いプロセッサ、例えばマスターカードのバンクネットと、発行者２０との間の通信の流れを示す。
【００５３】
清算メッセージは本質的に許可要求メッセージと同様に処理される．上述したように、（そのＢＩＮテーブル内のエントリーのために）アクワイヤラー１８は仮アカウント番号を用いて清算メッセージをサービスプロバイダ１０又は支払いプロセッサに自動的に送る。このファシリティにて、仮アカウント番号が「実」アカウント番号と置き換えられ、アクワイヤラーＢＩＮが「仮」アクワイヤラーＢＩＮと置き換えられ、アクワイヤラーリファレンスデータの残部が原アクワイヤラーレファレンスデータを得るためにサービスプロバイダが後で使用するインデックスと置き換えられる。これらの変更を与えられた清算メッセージが「実」カード発行者２０に送信され、実カード発行者２０が取引を通常の方法で処理する。アクワイヤラーがたまたま発行者でもある場合には、サービスプロバイダは清算された取引をアクワイヤラーに実アカウント番号及び適正な手数料計算と一緒に返送する。
【００５４】
例外処理
取引に関するメッセージを発行者からアクワイヤラー又は加盟店に返送する必要があるときは、このメッセージは任意の取引メッセージを通常のごとく処理する発行者により処理される。発行者に知られている取引は「仮」アクワイヤラーＢＩＮを含むために、「仮」アクワイヤラーＢＩＮが取引メッセージをサービスプロバイダファシリティに送付せしめる。このファシリティにて、「実」アカウント番号が「仮」アカウント番号と置き換えられ、仮アクワイヤラーリファレンスデータが原アクワイヤラーレファレンスデータと置き換えられる。次に取引メッセージはアクワイヤラーに送られ、アクワイヤラーがこのメッセージを他のこのような取引メッセージと同様に処理する。
【００５５】
ＩＤ用プラスチックカードの発行
場合によっては、カード所有者はインターネットを介してチケットを購入することができるが、カード所有者は、そのチケットが入場を許可するイベント会場に出かけると、そのチケットの正当性を認証するために取引に使用したカードの提示を要求される。
【００５６】
このような場合に適応するために、サービスプロバイダは物理的プラスティックカードを発行し、カード所有者に郵送することができ、カード所有者はインターネット用の仮アカウント番号を取得する。これらのカードには「ＩＤ専用、取引には無効」と明記される。エンボス加工された符号化アカウント番号は仮アカウント番号であるが、ＣＶＣ２は「実」支払用カードのものとすることができる。
【００５７】
他の方法として、仮アカウント番号を用いてカード所有者を認証する正当な必要性を有する加盟店を（サービスプロバイダに適切な識別及び認証情報を与えることにより）サービスプロバイダに登録することができ、これらの加盟店にはそれらの登録の暗号化証明として秘密鍵又は証明書を付与する。その後、このような加盟店は、仮アカウント番号取引明細のコピーを取引データと「実」アカウント番号を得る加盟店の権利の両方を認証する暗号認証下で供給することにより、「実」アカウント番号をサービスプロバイダファシリティから得ることができる。次にサービスプロバイダは「実」アカウント番号を暗号化された形で加盟店に転送することができるため、カード所有者を「実」アカウント番号に対応するカードで識別することができる。
【００５８】
本発明はインターネット上での支払いアカウント番号の使用に対し強化されたセキュリティをもたらす利点を提供する。
以上は本発明の原理を説明しているに過ぎない。当業者であれば、ここに明示又は明記されていないが、本発明の原理を具体化し、本発明の精神及び範囲に含まれる種々のシステム及び方法を考案することができる。
【図面の簡単な説明】
【図１】本発明の方法に従って安全支払いアプリケーションをプロバイダからインターネットを介して取得するシステムのブロック図である。
【図２】本発明の方法を用いて安全支払いをインターネットを介して行う際のカード所有者と加盟店との間の情報の流れを示す図である。
【図３】本発明の方法におけるアクワイヤラーとサービスプロバイダと発行者との間の情報の流れを示す図である。
【図４】本発明の方法における発行者とサービスプロバイダとアクワイヤラーとの間の情報の流れを示す図である。
【図５】本発明の方法における決算及び清算用の加盟店とアクワイヤラーとの間の通信の流れを示す図である。

Claims (13)

1. 支払いネットワークを用いて取引を行う方法において、
   （ａ）　サービスプロバイダにより、取引の許可に対する第１の許可要求を第１の支払いアカウント番号を用いて受信し、この第１の許可要求において、
   （ｉ）第１の支払いアカウント番号は前記サービスプロバイダと関連する第
   １のＢＩＮコードを有するとともに第２の支払いアカウント番号と関連し
   、第２の支払いアカウント番号は該第２の番号の発行者と関連する第２の
   ＢＩＮコードを有し、前記第２の支払いアカウント番号は前記第１の許可
   要求に含まれず、
   （ｉｉ） 前記第１の許可要求はアクワイヤラーと関連する第１のアクワイヤ
   ラーコードを含み、
   （ｉｉｉ） 前記第１の許可要求は、前記第１のＢＩＮコードに基づいて、支払
   いネットワークを経て前記サービスプロバイダに送ることができ；
   （ｂ） 前記第１の許可要求に応答して、前記サービスプロバイダにより、前記取引の許可に対する第２の許可要求を第２の支払いアカウント番号を用いて送信し、第２の許可要求はサービスプロバイダと関連する第２のアクワイヤラーコードを含むと共に、前記第２のＢＩＮコードに基づいて、支払いネットワークを経て前記発行者に送ることができ、
   （ｃ） 第２の許可要求に対する応答を前記サービスプロバイダにより前記発行者から受信し、該応答は前記第２のアクワイヤラーコードを含み、該コードに基づいて支払いネットワークを経て送ることができ、
   （ｄ） 前記第１の許可要求に対する応答を前記サービスプロバイダにより、前記第２の許可要求に対する応答に基づいて、アクワイヤラーに送信し、この第１の許可要求に対する応答は前記第１のアクワイヤラーコードを含み、該コードに基づいて支払いネットワークを経て送ることができることを特徴とする取引方法。
2. 前記発行者からの前記第２の許可要求に対する応答は、更に、前記第２のアカウント番号を含み、前記サービスプロバイダにより送信される前記第１の許可要求に対する応答は前記第１の支払いアカウント番号を含むことを特徴とする請求項１記載の方法。
3. 前記第１の許可要求は取引データを含むメッセージ認証コードを含み、該要求は１つの任意フィールドを含む複数のフィールドを有する標準トラックでフォーマットし、任意フィールドに前記メッセージ認証コードを置くことを特徴とする請求項１記載の方法。
4. 前記サービスプロバイダは前記メッセージ認証コードを検証することを特徴とする請求項３記載の方法。
5. 通信ネットワークを介する加盟店との取引を、第２の支払いアカウント番号と関連する第１の支払いアカウント番号を用いて行う方法において、
   （ａ） 一つ以上の取引明細に基づいてメッセージ認証コードを生成し、
   （ｂ） 少なくとも前記第１の支払いアカウント番号とメッセージ認証コードを加盟店に送信し、
   （ｃ） 加盟店が前記第１の支払いアカウント番号を用いて取引の支払いに対する許可を要求し、該要求は、あたかも支払いが慣例の磁気支払用カードでＰＯＳ端末で行われるようにフォーマットされ、該フォーマットは少なくとも任意データフィールドを含むトラックを有するものとし、該フィールドで前記メッセージ認証コードを送信し、
   （ｄ） 前記第１の支払いアカウント番号に対する許可要求に応答して、前記第２の支払いアカウント番号を用いて前記取引の支払いに対する許可を要求し、
   （ｅ） 前記第２の支払いアカウント番号及びメッセージ認証コードに対する許可要求に対する応答に基づいて、前記第１の支払いアカウント番号に対する許可要求を受諾又は拒否することを特徴とする取引方法。
6. 前記第１及び第２の支払いアカウント番号はそれぞれのＢＩＮコードを含み、第１のＢＩＮコードはサービスプロバイダと関連し、第２のＢＩＮコードは第２の支払いアカウント番号の発行者と関連し、前記サービスプロバイダは、前記第１のＢＩＮコードに基づいて支払いネットワークを経て前記加盟店の要求を受信し、且つ前記サービスプロバイダは第２の支払いアカウント番号を用いて支払いの許可に対する前記要求を発生し、該要求を前記第２のＢＩＮコードに基づいて前記ネットワークを経て前記発行者に送ることを特徴とする請求項５記載の方法。
7. 前記サービスプロバイダは前記支払いに対する許可要求内にサービスプロバイダと関連するアクワイヤラーコードを含み、前記発行者からの前記応答が前記サービスプロバイダに返送されることを特徴とする請求項６記載の方法。
8. 前記加盟店による前記要求は関連する加盟店アクワイヤラーコードを含み、且つ前記サービスプロバイダは前記受諾または拒否ステップに基づくメッセージを発生させ、該メッセージを前記関連する加盟店アクワイヤラーコードに送ることを特徴とする請求項７記載の方法。
9. 通信ネットワークを介して取引を行う方法において、
   発行者ＢＩＮを有する発行者が第１の支払いアカウント番号をコンピュータを有するユーザに発行し、前記発行者ＢＩＮは前記第１の支払いアカウント番号と関連するものとし、
   発行される各第１の支払いアカウント番号に対し一意の秘密鍵を発生するセキュリティモジュールを設け、
   前記第１の支払いアカウント番号と関連する第２のアカウント番号を発生し、
   サービスプロバイダが安全支払いアプリケーションを前記コンピュータに提供し、該アプリケーションは前記第２のアカウント番号と前記秘密鍵を含み、
   前記安全支払いアプリケーションを前記コンピュータに格納し、
   前記金融取引を行う加盟店を選択し、前記加盟店は関連するアクワイヤラーＢＩＮを有し、
   前記コンピュータに取引データを送り、
   前記取引データに基づいてメッセージ認証コードを生成し、
   前記メッセージ認証コードと前記第２のアカウント番号を含むトラックデータを前記加盟店に送信し、
   前記データに基づいて第１の許可要求を発生し、
   前記第１の要求を前記サービスプロバイダに送信し、
   前記第１の要求を前記秘密鍵で検証し、
   前記第２のアカウント番号と関連する前記第１の支払いアカウント番号を取得し、
   前記第１の支払いアカウント番号を用いて第２の許可要求を該番号と関連する前記発行者ＢＩＮに送信し、
   前記第２の要求を許可または拒否することを特徴とする取引方法。
10. 前記トラックデータは任意データフィールドと、アカウント番号フィールドと、有効期限フィールドとを具え、前記トラックデータの送信ステップは、
    前記メッセージ認証データを前記任意データフィールドに置き、
    前記第２のアカウント番号を前記アカウント番号フィールドに置き、
    有効期限を前記有効期限フィールドに置くことを特徴とする請求項９記載の方法。
11. 前記取引データは前記関連するアクワイヤラーＢＩＮ及び取引額を含むことを特徴とする請求項１０記載の方法。
12. 前記検証ステップは更に前記取引データを検証することを特徴とする請求項１１記載の方法。
13. 前記第２の許可要求は前記サービスプロバイダと関連するアクワイヤラーコードを含み、更に、
    前記許可または拒否ステップに基づいてメッセージを発生し、
    前記メッセージを前記アクワイヤラーコードに基づいて前記サービスプロバイダに送り、
    前記加盟店の関連アクワイヤラーＢＩＮを用いて前記加盟店に前記メッセージを通知することを特徴とする請求項９記載の方法。