JP4903346B2

JP4903346B2 - Improved method and system for processing secure payments across computer networks without pseudo or proxy account numbers

Info

Publication number: JP4903346B2
Application number: JP2002503838A
Authority: JP
Inventors: ジェイホーガンエドワード; エムキャンベルカール
Original assignee: マスターカードインターナシヨナルインコーポレーテツド
Priority date: 2000-06-22
Filing date: 2001-06-21
Publication date: 2012-03-28
Anticipated expiration: 2021-06-21
Also published as: AU7001201A; CA2413882A1; EP1295267A2; AU2001270012B8; AU2001270012B2; WO2001099071A2; WO2001099071A3; JP2003536181A

Description

【０００１】
【発明の属する技術分野】
本発明は、通信ネットワークを越えて安全な金融トランザクションを処理する方法およびシステムに関連し、さらに詳細には、インターネットなどのコンピュータネットワークを越えて安全に支払いを送信し、公衆の通信チャネルを越えて慎重を期するべき情報を送信するための方法およびシステムに関連するものである。
【０００２】
優先出願
本願は、米国仮特許出願第60/225,168号（2000年8月14日出願）、「安全な電子商取引トランザクションを処理する方法およびシステム」、同じく仮出願第60/213,325号（2000年6月22日）、「先の出願と同名」、それぞれの優先権の利益を主張し、これらを参照によって本明細書に合体させるものである。本願は、さらに、米国特許出願通し番号09/833,049号（2001年4月11日）、「コンピュータネットワークを越えて安全な支払いを処理する改善された方法およびシステム」の優先権の利益を主張し、これを参照によって本明細書に合体させ、そしてそれ自体は、米国仮特許出願第60/195,963号（2000年4月11日）、「コンピュータネットワークを越えて安全な支払いを処理する方法およびシステム」、そして、米国特許出願通し番号09/809,367号（2001年5月15日）、「コンピュータネットワークを越えて安全な支払いを処理する法およびシステム」、それぞれの優先権の利益を主張している。
【０００３】
自明であるが、オンラインコマースはここ数年で多大な成長を遂げてきたが、実際には、増加し続ける消費者は、いまだに、インターネットなどの公衆の通信ネットワークを越えてクレジットカード番号や個人識別番号（暗証番号）などの情報を送信したり、個人の金融情報を使用したりすることでトラブルにあったり、心配したりしている。その結果、ここ数年は、企業は最適の方法、即ち、コンピュータネットワークを越えた安全な支払いを保証し、金融情報の盗難や悪用の危険性を低減する方法を見つけるために懸命に努力してきた。
【０００４】
例えば、米国特許出願第5,883,810号「オンライントランザクションのためのトランザクション代理番号を用いた電子オンラインコマースカード」（マイクロソフトコーポレイション社に譲渡されている）は、各トランザクションに一時的なトランザクション番号を提供し、それを永続的な口座番号に関連付け、このトランザクション番号は本当のクレジットカード番号のように見え、顧客はこのトランザクション番号を使用し、これを商人に顧客口座番号の代わりとして提出するシステムを目的とする。この件に関しては、顧客は公衆ネットワークを越えて自分の本当のクレジットカード番号を送信する必要がない。
【０００５】
前述の‘810特許では、商人は、発行機関にトランザクション番号を渡し、次に発行機関がトランザクション番号をインデックスとして使用し、本物の顧客口座番号にアクセスし、承認を処理し、承認応答即ち許可応答をトランザクション番号に基づき商人へ返送する。その結果、その特許の主張によれば、危険性を最小化することができる。その理由は、顧客がトランザクション番号を送信するというだけではなく、さらに、代理番号は一回の購買のみに有効である、即ち、「それはその他の買物やトランザクションに繰り返して使用できないため、泥棒が盗んでも大きな利益を得られない」（Col. 2、60-61行）からである。
【０００６】
従来のシステムは改良する必要があり、より詳細には、繰り返し生成される固有のトランザクション番号の送信および生成の必要性を回避し、それぞれの処理されるトランザクションに対する永続的な口座番号を置き換えるような、インターネットを越えて安全な金融トランザクションを処理する方法およびシステムが必要とされている。
【０００７】
同時係属中の出願09/809,367号（2001年3月15日）は参照によって本明細書に合体させているが、「擬似」口座番号は、顧客に割り当てられ、暗号学的に顧客の支払い口座番号にリンクされている。この支払い口座番号は、金融機関によって、或いは、顧客が品物および／またはサービスのために支払いをするために使用できるその他の組織によって発行された口座番号である。例えば、支払い口座番号は、クレジットカード、或いはデビットカードなどの支払い（決済）カードから、或いは、顧客のコンピュータ上に格納された電子キャッシュアプリケーションなどの支払いアプリケーションから得た口座番号とすることもできる。擬似口座番号は、商人には本物の支払い口座番号のように見える。即ち、擬似口座番号は、適正な支払い口座番号と同じ長さを持ち、適正な識別番号（例えば、マスターカードインターナショナルインコーポレイティド（マスターカード）用には「５」）から始まる。擬似口座番号は、顧客によって、自己の全てのオンライン金融トランザクション（取引）のために本物の口座番号の代わりに使用される。
【０００８】
同時係属中の出願09/809,367号の発明によれば、擬似口座番号に基づく全てのトランザクションは、それぞれの口座番号に固有の秘密鍵を使用して暗号学的に認証することが好適である。認証は、公開鍵ペア（公開鍵認証）の私用鍵、或いは、私用鍵(private key)以外の秘密鍵（secret key）に基づかせることができる。従って、許可されていない人が何らかの擬似口座番号を確かめようとした場合は、その番号を使用して不正なトランザクションを実施できないようにされる。
【０００９】
さらに、同時係属中の出願09/833,049号の発明によれば、サービスプロバイダーがアクワイアラーコードに割り当てられており、支払いネットワークを使用してトランザクションを処理する方法が提供される。より詳細には、サービスプロバイダーが第１の支払い口座番号を使用してトランザクションの許可即ち承認のための承認要求のための第１の承認要求を受信し、
(i)第１の支払い口座番号はサービスプロバイダーに関連付けられたＢＩＮコード（銀行識別番号）を持ち、第２の支払い口座番号の発行人に関連付けられたＢＩＮコードを持つ第２の支払い口座番号に関連付けられ、
(ii)第１の承認要求は、アクワイアラー（加盟者獲得機関）に関連付けられたアクワイアラーコードを含み、
(iii)第１の支払い口座番号は、第１の支払い口座番号のＢＩＮコードに基づき支払いネットワークを介してサービスプロバイダーへルーティングすることができる。
【００１０】
本方法は、さらに、サービスプロバイダーが、第２の支払い口座番号を使用してトランザクションの許可即ち承認を求めて第２の承認要求を送信することによって、第１の承認要求に応答するステップを含み、第２の承認要求は、サービスプロバイダーに関連付けられ、発行人のＢＩＮコード（即ち、第２の支払い口座番号のＢＩＮコード）に基づき発行人へ支払いネットワークを介してルーティングされるものである。
【００１１】
さらに、発行人からの第２の承認要求への応答は、サービスプロバイダーによって受信され、この応答は、サービスプロバイダーに関連付けられたアクワイアラーコードを含み、当該コードに基づき支払いネットワークを通じてルーティングされ得る。その後、第１の承認要求への応答は、サービスプロバイダーによって、第２の承認要求への応答に基づきアクワイアラーへ送信され、そして、第１の承認要求への応答は、アクワイアラーに関連付けられたアクワイアラーコードを含み、当該コードに基づき支払いネットワークを通じてルーティングされ得ることが好適である。
【００１２】
この同時係属中の出願09/833,049号の発明のその他の好適な実施態様では、第２の支払い口座番号に関連付けられた第１の支払い口座番号を使用して商人とのトランザクションを処理する方法であって、(a)１つまたは複数のトランザクションの詳細に基づきメッセージ認証コードを生成するステップ、(b)商人へ少なくとも第１の支払い口座番号およびメッセージ認証コードを送信するステップ、(c)商人によって、第１の支払い口座番号を使用してトランザクションの支払いをするために許可（承認）を要求するステップであって、前記要求はあたかも、従来の磁気ストライプの支払いカードを用いてＰＯＳ端末で提出されたかのようであり、前記メッセージ認証コードは、従来の支払いカードの磁気ストライプで使用されるタイプのトラックに含まれる任意のデータフィールドに送られるようなステップ、(d)関連付けられた第２の支払い口座番号を使用してトランザクションの支払いをするための承認を要求することによって、第１の支払い口座番号のための承認要求に応答するステップ、(e)メッセージ認証コードおよび第２の支払い口座番号のための承認要求への応答に基づき第１の支払い口座番号のための承認要求を受け入れる、或いは拒否するステップを含む方法を提供する。
【００１３】
このシステムは、まだ改良の余地があり、公衆通信ラインを越えて処理される金融トランザクション中或いはその関連で送信される情報おいびメッセージを保護することで安全をより強化することができ、このような改良は、擬似或いは代理の口座番号を使用せずに実施され得る。
【００１４】
発明の概要
従って、本発明によれば、支払いネットワークおよび「検査サイト」を使用して利用可能な一定の量の資金を持つ支払い口座番号を用いて電子トランザクションを処理する方法を提供する。本方法は、
(a)前記支払い口座番号に関連付けられた秘密鍵を生成するステップ、
(b)前記秘密鍵を使用して前記トランザクションに特有のメッセージ認証コード（ＭＡＣ）を生成するステップ、
(c)前記メッセージ承認コードを含む許可（承認）要求メッセージを生成するステップ、
(d)前記ＭＡＣの真偽を検証するために、前記承認要求メッセージを前記支払いネットワークを越えて前記検査サイトへ転送するステップ、
(e)前記秘密鍵を使用して前記検査サイトによって前記メッセージ認証コードを検証するステップ、
(f)トランザクション額および前記利用可能な資金に基づき前記支払いネットワークを越えて前記承認要求メッセージに応答するステップ、
を含むものである。
【００１５】
本発明の好適な実施態様によれば、承認要求メッセージは、検査サイトに対応する特別銀行識別番号に基づき支払いネットワークを越えてルーティングされる、即ち経路決定される。ソフトウェアは、秘密鍵を生成するためにユーザの場所に置くことが好適である。
【００１６】
本発明のその他の好適な実施態様によれば、承認要求メッセージは、満了日フィールドを含み、メッセージ認証コードはこの満了日フィールドに置かれる。
【００１７】
本発明のさらなる目的、特徴、および利点が、本発明の好適な実施態様を示す付属の図面を考慮した以下の詳細な説明から明らかとなるであろう。
図面の全体にわたり、特に記述がなければ同じ符号および文字は、説明した実施態様における同一の機能、コンポーネント、或いは部分を指し示すものである。さらに、本発明の主題を、好適な実施態様と共に図面を参照して詳細に説明する。請求の範囲で定義した発明の主題の本質および範囲から逸脱することなく、説明する実施態様には変更や修正が施され得ることを意図するものである。
【００１８】
好適な実施態様の詳細な説明
上述したように、本発明は、クレジットカードの口座番号のような支払い口座番号を使用して安全な電子商取引（e-コマース）トランザクションを処理する方法およびシステムを目的とする。本発明の好適な実施態様では、支払い口座番号は、仮想の支払い口座番号であり、即ちこれはISO（国際標準化機構）7816の口座番号であり、これは電子トランザクションで使用されるが、物理的なISO7816タイプカードにリンクさせる必要はない。或いは、支払い口座番号は、物理的なISO7816タイプカードに発行された支払い口座番号とすることができ、或いは、支払い口座番号は、物理的なISO7816タイプカードに発行された支払い口座番号にリンクさせることもできる。
【００１９】
以下の本発明の詳細な説明では、マスターカードインターナショナルインコーポレイティド社（またはマスターカード）への言及が多くあるが、これは単なる例示であり、以下に述べるように特別支払い口座番号を処理するような特別なものである。また、以下のような頭字語を使用することがある。
【００２０】
ＢＩＮ − 銀行識別番号
ＤＥＡ − データ暗号化アルゴリズム
ＰＣ − 消費者のパーソナルコンピュータ装置
ＭＡＣ − メッセージ認証コード
ＭＣＩ − マスターカードインターナショナル或いはマスターカード
ＭＣＷＳ− マスターカードウェブサイト
ＰＩＮ − 個人識別番号（暗証番号）
ＰＯＳ − 販売時点管理
ＳＳＬ − セキュアソケットレイヤー（インターネット用セキュリティ）
ＴＳＮ − トランザクションシーケンス番号
【００２１】
本発明のある態様によれば、支払い口座番号の１つまたは複数のＢＩＮ範囲或いはＢＩＮが、安全なe-コマーストランザクションに関連付けられる。これらのＢＩＮ或いはＢＩＮ範囲は、以降、「特別」ＢＩＮ或いはＢＩＮ範囲と称することもある。特別ＢＩＮを持つ支払い口座番号は、以降、「特別」支払い口座番号と称することもある。
【００２２】
本発明のその他の態様によれば、特別支払い口座番号の所有者には、秘密鍵（カードごとの鍵）が提供され、特別支払い口座番号を使用してｅ−コマーストランザクションが処理されるときに、この鍵を使用してメッセージ認証コード（ＭＡＣ）を生成することができる。
【００２３】
本発明のさらにその他の態様によれば、秘密鍵のコピーを持つ少なくとも１つの機能が提供され、これは、特別支払い口座番号の所有者によって生成されたＭＡＣを検証するのに使用され得る。このような機能は、以降、「検査サイト」と称することがある。
【００２４】
従って、図１に示すように、本発明には幾つかの処理コンポーネントがあり、これらについて説明する。特別支払い口座番号（ＳＰＡＮ）の所有者或いは消費者には、自己のコンピュータ１０に安全な特別支払い口座番号ソフトウェアアプリケーション（ＳＰＡＮＳＡ）を提供することができる。ＳＰＡＮＳＡは、ＳＰＡＮに関連付けられた秘密鍵を保持し、この鍵を使用してＭＡＣを生成する。ＭＡＣは、発生元の商人１２へ送信され、承認要求メッセージ（ＭＡＣ）をアクワイアラー銀行１４（加盟者獲得銀行）へ転送して承認プロセスを開始する。
【００２５】
特別支払い口座番号を使用するｅ−コマーストランザクションは、支払い（決済）ネットワーク１６を通じて承認されることが好適である。例えば、特別支払い口座番号がマスターカードクレジットカード番号である場合は、これらは、マスターカードのバンクネット支払いネットワークを通じて承認され得る。特別支払い口座番号のための承認要求メッセージおよび承認応答メッセージは、口座番号の特別ＢＩＮに基づき支払いネットワーク１６を通じて検査サイト１８へルーティングされる。このため、例えば、支払いネットワーク１６とインターフェイスを取るような発行機関およびアクワイアラーのコンピュータは、検査サイト１８に対応する特別ＢＩＮを指示するルックアップテーブルを含むことができる。しかしながら、支払いネットワーク１６とインターフェイスを取るような検査サイト１８の１つまたは複数のコンピュータは、特別ＢＩＮに対応する発行人を指示するルックアップテーブルを含む。
【００２６】
本発明によれば、検査サイト１８が承認要求メッセージを受信するとき、検査サイト１８は、特別支払い口座番号に関連付けられた秘密鍵を使用してトランザクションに関連付けられたＭＡＣを検証することができる。さらに、検査サイト１８は、承認要求メッセージを発行人２０（特別支払い口座番号を発行した機関）へ伝えることができる。検査サイト１８は、承認要求メッセージに対して、ＭＡＣが検証されたか（即ち本物であると立証された）否かの表示で、および／または、発行機関からの承認応答で応答する。
【００２７】
検査サイト１８が承認要求メッセージを発行機関に転送する場合は、検査サイトは、ＭＡＣが検証されたか否かを発行機関２０に表示することができる。一例であるが、特別支払い口座番号がマスターカードのクレジット或いはデビットカードの口座番号であると仮定すると、検査サイトは、発行銀行へ、外向けのバンクネット内で、或いは、マスターカードデビットスイッチのデビットメッセージ内で、ＭＡＣが検証済みであることを表示することができる。この表示部は、マスターカードの「0100/0200」タイプメッセージで使用される現行のセキュリティ表示フィールドに新たに定義した値とすることができる。検査サイトは、全てのトランザクションに対して、入ってくるセキュリティレベル表示部の内容を消去し、その出力に対しては、供給されたセキュリティレベル（すなわちＭＡＣが検証されたか否か）を書き込むことができる。
【００２８】
特別支払い口座番号を使用する例示のトランザクションでは、特別ＢＩＮ範囲のため、発行銀行の承認応答メッセージは、検査サイトへルーティングされ戻される。承認応答メッセージが承認されたことを示している場合、検査サイト１８は、ＭＡＣが検証されたアクワイアラーに返す表示部即ちインジケータに「承認」を表示する。その後、アクワイアラー１４は、メッセージを発生元の承認１２へ返送する。このようにして、商人は、そのアクワイアラーを通じて発行銀行が当該トランザクションを承認したことだけでなく、検査サイトがＭＡＣの有効性を確認したことを知る。このことは、当該トランザクションはカード所有者から発生したものに違いないこと、そして、それは「保証」されたトランザクションたり得ることを意味する。
【００２９】
上述したように、ＳＰＡＮＳＡは、特別ＰＡＮ所有者のコンピュータ上に格納することができる。さらに、コンピュータと別に、このアプリケーションは、携帯電話や携帯情報端末（ＰＤＡ）にも格納することができる。特別ＰＡＮ所有者が、ウェブサイト２２（例えば、検査サイトを含む、発行人のウェブサイト、或いは、その他の適する場所）からインターネットを越えて当該アプリケーションに要求することが好適である。このウェブサイトは、望ましくは、ＤＥＳ鍵などのような顧客に特有の秘密暗号鍵を作成する能力を具えるハードウェアセキュリティモジュール２４に結合、或いは、これとアクセスできることが好適である。それぞれのセキュリティモジュールは、望ましくは、顧客に固有の秘密暗号鍵を生成し、そして再生成するのに使用されるような１つまたは複数の「派生鍵（derivation key）」を含む。
【００３０】
所有者のコンピュータに格納されている安全なＰＡＮアプリケーションは、トランザクションシーケンス番号（後で詳述する）を含むことができ、各トランクションのたびに、検査サイト或いはその他の支援サイトと通信を行う必要はない。その代わりに、特別ＰＡＮの所有者のコンピュータに格納されているアプリケーションは、特別の発行機関が望むどんな間隔であっても、検査サイト或いはその他の支援サイトと、トランザクションシーケンスカウンターをやりとりし、それの同期を取ることができる。
【００３１】
また、本発明はリモートワレット（財布）サーバーと共に使用することもできる。この場合は、安全なＰＡＮアプリケーションは格納されず、特別ＰＡＮ所有者のコンピュータシステムで管理および保守される。有利なことに、この実施態様では、本発明は、特別ＰＡＮ所有者が一般のインターネットブラウザを利用することを可能にし、このブラウザを使用してリモートのワレットサーバー（このサーバーはその中に安全なＰＡＮアプリケーションを有する）にアクセスする。この実施態様では、特別ＰＡＮ所有者のローカルのシステムは、一般的なインターネットブラウザよりも優れた何らかの追加ソフトウェアや機能を含む必要がない。
【００３２】
有利なことに、本発明は、仮想現実の第１の口座番号の利用を可能にする。擬似或いは代理の口座番号を利用するシステムとは対象的に、本発明は、変換することなく、アクワイアラーのコンピュータにより切替えられ得るものであり、バックエンドの切替え或いは処理の機能に変更を施す必要がない。
【００３３】
また、擬似或いは代理の口座番号を利用するシステムとは対象的に、本発明は、１）中央サイトに決済（clearing）ファイルを送信する必要性を除去することによって、全ての決済手順を簡単化し、２）中央サイトに返送される必要があるチャージバック（charge back）の必要性を除去し、３）本物の口座番号に変換するために中央サイトのシステムに送信されることから、トランザクションが彼らの請求書に載せられた後、カード所有者によって為された全ての検索要求を除去する。カード所有者にはこれらのトランザクションのための本物の口座番号が提供されそれを使用する。
【００３４】
擬似或いは代理の口座番号を利用するシステムとは対象的に、本発明は、特別支払い口座番号を本物の口座番号に変換するのに必要とされるトランザクションログの記憶を作成し管理する必要性を除去する。
【００３５】
ＭＡＣは、多数の方法で検査サイトへ送信され得る。以下にＭＡＣを検査サイトへ送信する方法の一例を示す。
ＭＡＣオプション１
この実施態様では、ＭＡＣはカード満了日（有効期限日）フィールドに置かれ、「擬似満了日」として振舞う。ＭＡＣ生成について以下でさらに詳細に説明する。この実施態様では、商人サイトには何ら変更を施す必要がない。商人に対して考えられるただ１つ追加の要件は、トランザクションＭＡＣが認証されたことを示すアクワイアラーからのメッセージ内の追加の承認応答フィールドを受け入れるような商人の機能であるが、これを使用する必要はない。この表示のために使用される前記フィールドは、通常のバンクカード承認メッセージ送受信ＰＯＳシステムにおいて、現行はサポートされている何らかのフィールドとすることができる。
【００３６】
ＭＡＣオプション２
この実施態様は、その他のオプションと関連して使用され得る。本実施態様では、カード所有者のコンピュータ或いはリモートワレットサーバーは、トランザクションに関連する商人データのログを保持する。例えば、カード所有者のコンピュータ或いはリモートワレットサーバーは、
(a)トランザクションＭＡＣ、
(b)商人のウェブアドレス（ＵＲＬ）、
(c)商人のセキュアソケットレイヤー（ＳＳＬ）の証明通し番号、および／または、
(d)完全な商人のＳＳＬ証明、
をログ即ち記録する。
この実施態様は、カード所有者が後でトランザクションは自分によって開始されたものでないと主張した場合に、当該クレームが間違いであることを証明するのに十分なデータを前記ログが提供することができるという点でさらなる安全を提供する。この実施態様の場合は、商人ウェブサイトは変更されていない。
【００３７】
ＭＡＣオプション３
この実施態様では、トランザクションＭＡＣは、オプション１或いは４の場合のように、カード満了日の場所に置かれる。ＭＡＣは、商人提供のデータ要素に基づき生成される。この商人提供のデータ要素は、ＭＡＣを計算するのに必要な商人提供のデータを伝送するために設計された、追加の別個のフィールドでカード所有者或いはリモートワレットサーバーに渡される。ある実施態様では、商人のＳＳＬ証明通し番号などの商人が既に、ＭＡＣ演算で使用されるデータフィールド内に保持しているようなデータ要素にリンクさせる。例えば、ＭＡＣは以下のデータ要素、
(a)ＰＡＮ、
(b)本物のカード満了日（４桁の数字のＭＭＹＹフォーマット）、
(c)トランザクションシーケンス番号（これはカード所有者のシステムおよび検査サイトの両者で同期して保持される）、
(d)トランザクションの日時、
(e)安全なＰＡＮアプリケーションバージョン番号、
(f)商人のＳＳＬ証明通し番号などの商人を識別するデータ、
を使用して作成することができる。
【００３８】
この実施態様は、商人の電子コマースサイトの変更を必要とする。商人は、彼らのシステムを、彼らの商人証明通し番号を外部に向かう承認要求メッセージで送信するように変更する必要がある。しかしながら、この実施態様は、商人を特定のトランザクションにリンクするキーとなる商人識別データを提供する。カード所有者システムと検査サイトで計算されるＭＡＣ検証ステップは、この追加の商人識別フィールドを持つ。検査サイトが、入ってくる承認要求メッセージが商人提供の証明通し番号を持つことを認識した場合は、それをＭＡＣ計算で使用して、カード所有者システムがＭＡＣを生成したときに使用された同じプロセスにマッチさせる。
【００３９】
ＭＡＣオプション４
この実施態様では、トランザクションＭＡＣは、カード満了日フィールド内、および、ＣＶＣ２或いはこれに相当するフィールド内に置かれる。ＣＶＣ２とは、幾つかのカードの署名欄の隣に印刷されている３桁の数字の値のことである。背景技術として、ＩＳＯ支払いカードは、発行人によって暗号学的に生成された静的な（少なくとも）３桁のコードを持つ。例えば、マスターカード支払いカードでは、このコードはＣＶＣ２と呼ばれる。この値は、秘密暗号鍵を使用して発行銀行によって生成され、この同一の鍵を使用して検証され得る。このオプションは、より長いトランザクションＭＡＣ（即ち、ＭＡＣ出力サイズは３桁増分される）の生成を可能にする。この実施態様の場合は、ＣＶＣ２（或いはこれに相当するコード）フィールドは、動的に生成され、ＭＡＣで満たされる。商人サイトは、カード所有者のプロンプティングおよびＣＶＣ２或いはこれに相当するフィールドのその後の伝送、をサポートする必要がある。
【００４０】
ＭＡＣオプション５
この実施態様では、トランザクションＭＡＣは、ＣＶＣ２或いはこれに相当するフィールドに置かれる。この実施態様は、少なくとも３桁のＭＡＣを生成することを可能にする。
このオプションの好適な実施態様では、ＭＡＣがトランザクションのために生成されたとき、ＭＡＣは、本物即ち静的なＣＶＣ２値（即ち、発行銀行によって生成され、支払いカードと共に発行されたＣＶＣ２値）を対照して検査される。生成したＭＡＣが静的なＣＶＣ２値と同じ場合は、安全なＰＡＮアプリケーションのトランザクションカウンターは増分され、新たなＭＡＣが生成される。その後、この新たなＭＡＣは静的なＣＶＣ２値と比較され、その結果、この２つの値が同一か否かを判定する。このプロセスは、生成されたＭＡＣ値が静的なＣＶＣ２値と同じでなくなるまで繰り返される。ＭＡＣがトランザクションのために検証されるとき、この検証プロセスは、当該トランザクションと共に送信されたものを受信したＣＶＣ２値と、支払いカードに対して予想される静的なＣＶＣ２値とを比較する。これらの値が同一である場合は、検証プロセスは、安全なＰＡＮアプリケーションは当該トランザクションのために使用されてなく、かつ、ＭＡＣは送信されていないものと判断する。受信したＣＶＣ２値が静的なＣＶＣ２値と異なる場合は、安全なＰＡＮアプリケーションは当該トランザクションのために使用されており、かつ、ＣＶＣ２フィールドがＭＡＣを含むものであると判断する。本検証プロセスは、その後、ＣＶＣ２フィールド内のＭＡＣの検証を試みる。
【００４１】
特別支払い口座番号を、本実施態様で使用する必要はない（しかしながらこれらを使用することも可能である）。代わりに、上述したように、ＣＶＣ２フィールド内の値を使用して、いつ、安全なＰＡＮアプリケーションが当該トランザクションで使用されたのかを判定することができる。
【００４２】
カード所有者認証の一般的背景技術
カード所有者の認証は多数提供されており当該分野では良く知られているが、カード所有者の安全なＰＡＮアプリケーションの発行人によって指定され得る。認証方法には、ＳＳＬを用いたネットスケープやマイクロソフトインターネットエクスポローラ・ブラウザなどのようなカード所有者のインターネットブラウザによってアクセスされるリモートワレットサーバーの使用も含まれるが、これらに限定されるものではない。ここで、この認証方法には、ユーザＩＤおよびパスワードによるアクセスの使用、および／または、チップカードベースのデジタルＩＤ認証のアクセスの使用を含むことができる。リモートワレットサーバーの場合は、本発明は、カード所有者のシステム自体によって管理および保持されているような、ローカルで格納されたアプリケーションを含むこともできる。
【００４３】
本発明のトランザクション認証は、以下に説明するようにトランザクションの詳細を越えるＭＡＣの生成によって提供される。
【００４４】
本発明の口座番号の保護は、仮想口座番号の使用によってさらに向上させることができ、これはＰＯＳ端末での対面式のトランザクションでの磁気ストライプのゼロの値からなる（仮想口座番号には発行された磁気ストライプが無いからである）。これらの仮想口座番号は、検査サイトにルーティングするのに必要とされるこれらの口座番号を示す特別ＢＩＮ範囲の範囲内に入らなければならないということに関連して、それぞれの発行機関には、特別ＢＩＮ範囲が与えられ、その結果、本発明の下で仮想口座番号を使用する。
【００４５】
本発明の場合は、本発明の口座番号はそれに関連付けられたトランザクション特有のＭＡＣ無しでは使用不可であるという理由から、カード所有者の自己の口座番号を明かす前の、商人認証の必要性が除去される。カード所有者の認証無しで古いＭＡＣでトランザクションを再生するような、本発明の下での口座番号の何らかの不正使用の試みは、特別検査サイトにルーティングされるが、当該トランザクションの試行のためには検証は行われない。従って、全ての不正使用の試行は失敗に終わることとなる。
【００４６】
カード所有者は、安全なＰＡＮアプリケーションをダウンロードする前にパスワードを提供することができ、或いは、アプリケーションがカード所有者のＰＣ上に導入されたときにパスワードを選択することができる。パスワードが選択或いは提供された場合は、その後、カード所有者は、自己のＰＣの当該アプリケーションを活動状態にするためにこのパスワードを入力する必要がある。カード所有者によって選択されたこのパスワードを使用して、秘密鍵を暗号化、さもなければ変更することができる。この安全な（セキュア）ＰＡＮアプリケーションは、デジタルワレットアプリケーションの一部としてダウンロードすることもできる。
【００４７】
顧客に固有の秘密鍵の生成
安全なＰＡＮアプリケーションのなかに埋め込まれた秘密鍵は、それぞれの特別支払い口座番号に固有であって、望ましくは、派生鍵および特別支払い口座番号を使用してセキュリティモジュールから派生させる。各発行人或いは各ＢＩＮ範囲のための派生鍵とすることができる。派生鍵は、例えば、３倍長のＤＥＡ鍵とすることもできる。当該分野に知られるいかなる暗号化方法を使用しても、派生鍵で顧客特有の鍵を生成することができる。
【００４８】
検査サイトはそのなかに派生鍵のコピーを持つセキュリティモジュールに結合或いはアクセスを持つことが好適である。検査サイトが特別支払い口座番号のための承認要求を受信したとき、検査サイトは、前記特別支払い口座番号と共に適切な派生鍵を使用してＭＡＣを検証するのに必要な鍵を派生させる。
【００４９】
ＭＡＣの生成
本発明によってＭＡＣが生成され使用され得ることを示す例示の方法を以下に示す。上述したように、ＭＡＣはトランザクションの満了日フィールドに置くことができる。その後、ＭＡＣは、「擬似」満了日として振舞う。この擬似満了日は、満了日のようにＭＭＹＹの形式でフォーマットされる。望ましくは、今日の市場にいる全ての或いはほとんどの商人の現行処理システムで動作するように、擬似満了日は当該トランザクションの４８ヶ月以内に含まれるようにする。
【００５０】
望ましくは、安全なＰＡＮアプリケーション（以降、「セキュアードアプリケーション」とも呼ぶ。）、トランザクションシーケンス番号を含み、これは、２０桁のビットから構成され、トランザクションごとに増分される。従って、２^２０までは、即ち約１００万個のトランザクションが発生するまでは、全てゼロから全て１になるまでのような回転はしない。また、このセキュアードアプリケーションは、４ビットの「バージョン番号」を含むことができ、これは、与えられた口座番号のためのセキュアードアプリケーションが存在するそれぞれのＰＣ、或いは、その他の装置に固有の番号である。
【００５１】
カード所有者のセキュアードアプリケーションによって処理されるトランザクションごとに、トランザクションシーケンス番号は最初に増分される。結果として生じる２０ビットの数、および、その左に連結される４ビットのセキュアードアプリケーションバージョン番号は、８バイトフィールドにおいて左寄せされ、その右側には２進数のゼロがパッディングされ、２倍長のセキュアードアプリケーションのカードごとの鍵を使用して３倍長のＤＥＡ暗号化が施される。この結果が６４ビットの２進数のＭＡＣとなる。
【００５２】
満了日フィールドへのＭＡＣの書き込み
トランザクションの満了日フィールドは、その後、以下のように、上述した６４ビットの２進数のＭＡＣから得ることができる。
１．「月表示の数（２進数であり、以下でより詳細に説明する）」内の最も左の「１」のビットを選択し、このビット位置から最も右のビット（最下位ビット）までのビット位置の数をカウントする（最も左の「１」のビットを含む）。この数を「Ｎ」と呼ぶ。例えば、「月表示の数」が「0101 0100（十進で84）」である場合は、「Ｎ」の値は７になる。「Ｎ」を決定した後、６４ビットの２進数のＭＡＣを、「Ｎ」ビットごとのグループと見なし、使い残しの最も右のビットは無視する。最も左のグループから開始し、「月表示の数」以下のものではじめに見つかったグループを選択する。このようなグループが見つからなかった場合は、最も左のグループを選択し、この選択したグループに「月表示の数」を加算し、この合計から２^Ｎを引き、この結果（これは＞０、かつ、＜「月表示の数」となる。）を選択した値として使用する。
２．ステップ１の結果を２進数の「1100(十進で12)」で割り、商および余りを生成する。この商および余りを十進数に変換する。十進数でのこの余り（00から11までの範囲の値を持つ）を、「基準日(reference date)」の２つの最も左（最上位）の十進数の数字（ＭＭ）に加えるが、これについては後で詳述する。結果が１２を越える場合は、当該結果から１２を引き、いずれの場合であっても、
当該結果を、当該トランザクションのためのカード満了日の最も左の数字、即ちＭＭとして使用する。得られた結果が１２を引く必要があった場合は、商を１だけ増分する。
３．ステップ２による２つの十進数の数の商（ステップ２で述べたように増分されている可能性がある）を、「基準日」の最も右の２つの数字（ＹＹ）に加え、１００でモジュラー演算する（Add, mod-100・・）。結果を、当該トランザクションのためのカード満了日の２つの最も右の数、即ちＹＹとして使用する。
【００５３】
ＣＶＣ２フィールド或いはこれに相当するものへのＭＡＣの書き込み
上述したような方法でＭＡＣを生成することができるが、当該分野で知られているいかなる方法でも生成できる。さらに、満了日フィールドにＭＡＣを置くことに加えて、或いはそれに代わって、ＭＡＣ、或いはその一部をＣＶＣ２フィールド或いはこれに相当するフィールドに置く、即ち書き込むこともできる。
【００５４】
カード所有者と商人との間の通信
一旦、セキュアードアプリケーションがカード所有者のコンピュータに導入されたあと、カード所有者は、このセキュアードアプリケーションを全てのインターネット決済のために使用し、このセキュアードアプリケーションは、全てのインターネットトランザクションのためにカード所有者の特別支払い口座番号を提供する。これがセキュアードアプリケーションのトランザクションであるという事実は、商人にはトランスペレントである、すなわち、商人には気付かれない。口座番号は実際には特別支払い口座番号であり、満了日は実際にはＭＡＣを表すものとすることができるが、商人は、当該トランザクションが受信したその他のインターネットＳＳＬトランザクションと違うことを気付かない。
【００５５】
より具体的には、ＭＡＣフィールドが商人によってサポートされているときは、いつも、セキュアードアプリケーションは、それに埋め込まれた秘密鍵を使用して当該トランザクションに関連するメッセージ認証コード（ＭＡＣ）を作成し、ＭＡＣフィールド内にこのＭＡＣ、および、それに基づくデータを置き、これはトランザクションの一部となる。
【００５６】
カード所有者のトランザクションメッセージの受信したあとすぐに、商人は、アクワイアラーのために従来の承認要求をフォーマットする。この承認要求は、望ましくは、消費者のＰＣによって提供されたままのＭＡＣフィールドを含む。
【００５７】
トランザクションの始めにＭＡＣフィールドおよび満了日を含むもののみ、商人は、カード所有者のトランザクションのための複数の承認／清算（clearings）のトランザクションを開始すべきである。これに続くトランザクションは、支払い口座番号のみを含み、商人が生起したメールオーダー・電話オーダーのトランザクションと考えることができる。
また、これは、複数の清算（clearings）を伴う全ての繰り返される支払いおよび部分的な支払いは本物である。
【００５８】
承認要求のアクワイアラーの取り扱い
アクワイアラーがインターネットの商人から承認要求を受信したとき、自己のＢＩＮテーブル内の発行人ＢＩＮを調べる。マスターカードの支払いシステムでは、アクワイアラーが、当該トランザクションのＢＩＮが自国以外の発行人に対応するものと判断した場合は、当該トランザクションをバンクネットシステム経由でマスターカードにルーティングさせる。アクワイアラーが、当該トランザクションのＢＩＮが自国の発行人に対応するものと判断した場合は、当該トランザクションをバンクネット経由でマスターカードにルーティングさせることもできる。或いは、発行人がアクワイアラーと同じ国にいる場合は、アクワイアラーは、通常は、当該トランザクションをＢＩＮによって指定された発行人へ直接的にルーティングさせることができる。特別支払い口座番号のトランザクションの場合は、望ましくは、当該トラザクションを中央処理機能（好適にはマスターカード承認の処理機能、即ち検査サイト）にルーティングする。
【００５９】
本発明のある実施態様では、幾つかの国は、国内のトランザクションを処理する特別セキュリティモジュール装備の機能を持つことができる。これらの機能のそれそれは、マスターカードの承認のみによってセットアップされ、処理するトランザクションの国のための口座番号変換データおよび暗号鍵のみを保持することが好適である。このような国の検査サイトの機能を持つ国では、全てのトランザクションがこの機能を用いて送信され、その結果、同じ国のトランザクションはその国を離れる必要がない。国内トランザクションを処理する国の検査サイト機能は、全てのトランザクションを中央処理機能へ送信するよりも、効率的にすることができる。
【００６０】
セキュアードアプリケーションの始動
セキュアードアプリケーションは、セキュアードアプリケーションベースの支払いが実行される直前に、トランザクションごとに始動させることができる。セキュアードアプリケーションは、支払い処理ウェブサイト（望ましくはマスターカードのウェブサイト或いはサーバー）に、要求を送信する。この要求は、例えば、１６桁の特別支払い口座番号、４桁の十進数の数字からなる支払い口座番号の満了日、４ビットのセキュアードアプリケーションのバージョン番号、２０ビットのトランザクションシーケンス番号の現在値、および、これらの値のうち後の方の３つの値に基づく１６ビットのＭＡＣ（メッセージ認証コード）から構成される。ＭＡＣは、２０ビットのトランザクションシーケンス番号と連結され、さらに、４ビットのセキュアードアプリケーションバージョン番号と（左から右へ）連結されている１６ビットの満了日（2進化１０進数で）を使用して、これを６４ビットフィールド内で左寄せし、その右に2進数のゼロをパッディングし、その後、結果として生じた暗号文の最も左の１６ビットを選択することで、３倍長ＤＥＡ暗号によって暗号化され得る。
【００６１】
ウェブサイトがこの情報を受信したとき、このサイトは、特別セキュリティモジュール装備のセキュアードアプリケーションシステムを使用して、セキュアードアプリケーションバージョン番号、トランザクションシーケンス番号、および満了日に基づきＭＡＣを検証する。ＭＡＣが検証されると、即ち本物であると証明された場合は、このシステムは、トランザクションシーケンス番号を増分し（保持する）、「予想されるトランザクションシーケンス番号（ＥＴＳＮ）」を生成し、指示された特別支払い口座番号のＢＩＮのためのセキュアードアプリケーションの承認要求を処理する問題となっているセキュアードアプリケーション認証システム（例えば検査サイト）のセキュアードアプリケーションバージョン番号および特別支払い口座番号のためのＥＴＳＮを更新させる。このセキュアードアプリケーション承認システム（検査サイト）は、受信したＥＴＳＮが、このセキュアードアプリケーションバージョン番号および特別支払い口座番号のために前回受信した最も大きな番号が振られたＥＴＳＮと同じ或いは未満である場合は、その受信したばかりのＥＴＳＮを拒否する。このセキュアードアプリケーション承認システム（検査サイト）は、受信したばかりの満了日も与えられ、この受信したばかりの満了日が記録にある現在の満了日よりも後である場合は、この特別支払い口座番号に関連付けられた満了日を更新する。
【００６２】
この特別セキュアードアプリケーションシステムは、以下の２つのデータ値をウェブに送信することが好適であり、このウェブサイトは、その後、これらをカード所有者のＰＣのセキュアードアプリケーションに送信する。
１）「基準日」と称するデータ値。これはＭＭＹＹのフォーマットの４桁の十進数の数である（実際は当月或いはその次の月の日付）。
２）「月表示の数」と称するデータ値。これは、８ビットの２進数であり、最大値は２５６（十進数で）未満である。これらデータは、適切なセキュアードアプリケーション承認システム（検査サイト）に送信される情報にも含まれる。
【００６３】
承認要求を処理する中央処理機能（および／または国の機能）
特別支払い口座番号の特別ＢＩＮによって、アクワイアラーおよび支払いネットワークは、トランザクションを検査サイトへルーティングさせる。
検査サイトは、それぞれのセキュアードアプリケーションバージョン番号および特別支払い口座番号のために、受信した２０ビットの最も大きな番号が振られたＥＴＳＮの記録を、ＭＡＣがこのトランザクションシーケンス番号に対して（正当であることを）検証されたか否かの表示と共に、格納する。さらに、検査サイトは、ＭＡＣが検証されていないということに関して、過去４８時間以内に受信した「予想されるトランザクションシーケンス番号」を格納する。このような予想されるトランザクションシーケンス番号のそれぞれに関連して、本システムは、それぞれの予想されるトランザクションシーケンス番号に適合する「月表示の数」および「基準日」の表示も格納する。
【００６４】
「基準日」は、承認要求メッセージが受け入れ可能な、最も早い満了日を指示する日付の値である。背景として、幾つかの商人は、即座に承認を要求せずに、一緒にまとめてバッチ式で承認を要求する。従って、この日付は、典型的には、トランザクションが始動された日付の１つまたは２日前の日付である。
【００６５】
「月表示の数」は、支払いカードが受け付けられる最新の満了日に対応する現行の日付よりも後の月を表す数を示す。
【００６６】
検査サイトは、登録されたときにカード所有者のＰＣのセキュアードアプリケーション内に置かれた固有かつ秘密の１６バイトの暗号鍵を決定する能力を持つセキュリティモジュールへのアクセスを持つ、或いはそのモジュールに結合されている。検査サイトで実行される処理は以下の通りである。
【００６７】
１．セキュリティモジュールを使用して、適切な派生鍵および特別支払い口座番号を用いてこのセキュアードアプリケーションに対して固有の暗号鍵を決定する。
２．検証されていないＭＡＣのために４８時間以内に初めて受信した２０ビットのＥＴＳＮを選択する。ＰＣのセキュアードアプリケーションのために上で定義したように、そのＥＴＳＮに関連付けられたセキュアードアプリケーションバージョン番号およびこの２０ビットのトランザクションシーケンス番号に基づき６４ビットＭＡＣを計算する。関連付けられたＥＴＳＮのために指定された「月表示の数」および「基準日」を使用して、ＰＣのセキュアードアプリケーションのために上で定義した手法を使用してこのＭＡＣから満了日を決定する。この決定した満了日が現行のトランザクションの満了日と同じ場合は、当該ＭＡＣは正当に検証されたこととなる。ＭＡＣ検証の結果として生じたこのＥＴＳＮのエントリーは、このエントリーが、これに関連付けられたセキュアードアプリケーションバージョン番号のための最も大きな番号が振られたＥＴＳＮである場合は、「ＭＡＣ検証済み」とマークされ、或いは、前記最も大きな番号が振られたＥＴＳＮでない場合は、削除される。「ＭＡＣ検証済み」とマークされ、かつ、同一のセキュアードアプリケーションバージョン番号に関連付けられている、より小さい番号が振られたＥＴＳＮにエントリーは、ここで削除される。
【００６８】
３．ステップ２（或いはステップ４）でマックが正当であると検証された場合は、このトランザクションの商人が同じトランザクションのために第２の承認要求メッセージを決して送信しないであろうということが分かっている場合を除いて、この特別支払い口座番号のための「履歴データ」にエントリーを作成する。なお、幾つかの商人は、トランザクション即ち取引の後に指定された納期で商品の全てを出荷できない場合は、第２或いはそれ以上の認証要求メッセージを送信することもできる。この履歴データエントリーは、上述したデータの全て、およびこれらに加えて、商人およびアクワイアラーの身元、および、このエントリーのための「満了日」を含む。この満了日のエントリーは、未来の指定された時間（例えば６ヶ月）である。
【００６９】
ステップ２でＭＡＣが正当なものであると検証されなかった場合は、既に検証済みのＭＡＣに関連付けられていない最も古いものから最新のものまで、過去４８時間以内に受信したその他の「予想されるトランザクションシーケンス番号」の全てに対してステップ２で定義したプロシージャー（手順）を繰り返す。再度、これらの試行で結果として生じる日付が、現行のトランザクションの日付とマッチする場合は、当該ＭＡＣは検証されたものと考える。ＭＡＣが検証されたときに、ＭＡＣ検証の結果として生じた２０桁のＥＴＳＮが、問題の関連付けられたセキュアードアプリケーションバージョン番号のための最も大きいＥＴＳＮである場合は、そのＭＡＣ検証の結果として生じた２０桁のＥＴＳＮは、「ＭＡＣ検証済み」とマークされ、その問題の関連付けられたセキュアードアプリケーションバージョン番号のための最も大きいＥＴＳＮでない場合は、削除される。ＭＡＣがこのステップで検証された場合は、ステップ３も実行する。
５．ステップ２でもステップ４でもＭＡＣが正当なものであると検証されなかった場合は、問題となっている特別支払い口座番号のための「履歴データ」をアクセスする。同じ満了日のＭＡＣを生成する同じ商人およびアクワイアラーのためのデータのエントリーがあって、当該エントリーが満了していない場合は、当該ＭＡＣを受け入れる（これは、既に承認されたトランザクションのための追加の承認要求メッセージであると推定される）。このエントリーのためにＭＡＣが受け入れられたとき、このエントリーの満了日が、２ヶ月よりも小さい場合は、この満了日は約２ヶ月にされるべきである。その理由は、これは、「繰り返しの支払い」であるかもしれず、そして、次の月あたりに同じトランザクションに対するその他の承認要求メッセージがあるかもしれないからである。
【００７０】
ステップ２、ステップ４、或いはステップ５でＭＡＣが正当であるものと検証されなかった場合は、当該トランザクションは拒絶される。この場合は、「拒絶」応答が、アクワイアラーへ送信され、および／または、ＭＡＣが検証されなかった事実が、上述したセキュリティフィールドなどの特別フィールドに表示される。
【００７１】
要約すれば、検査サイトはＭＡＣフィールドの存在に注目する。検査サイトは、（上述したように）秘密鍵を決定し、ＭＡＣを作成するのにＰＣで使用されたものと本質的には同一のプロシージャーを用いてこの鍵を使ってＭＡＣを検証する。本システムは、トランザクションシーメンス番号も検査し、そうするために、処理する特別口座番号ごとのバージョン番号ごとにトランザクションシーケンス番号情報を保持しなければならない。
【００７２】
本システムは、
１．当該トランザクションシーケンス番号が、少なくとも４８時間前に受信したこのセキュアードアプリケーション番号のこのバージョンのための最も大きなトランザクションシーケンス番号以下であるか、或いは、
２．当該トランザクションシーケンス番号が、このセキュアードアプリケーション番号のこのバージョンのための既に受信したトランザクションシーケンス番号のいずれかとマッチするか、
の場合にトランザクションを拒否する。
【００７３】
ＭＡＣ或いはトランザクションシーケンス番号の検証が失敗した場合は、この機能は、当該トランザクションを拒絶させる、および／または、ＳＥＴセキュリティフィールドなどのような適切なフィールドに検証失敗を表示させる。ＭＡＣおよびトランザクションシーケンス番号の双方が、正当なものであると検証された場合は、この機能は、当該トランザクションを発行人にルーティングさせる。
ＭＡＣが正当なものであると検証された場合は、中央処理機能、或いは検査サイトは、発行人のための承認要求メッセージをフォーマットする。承認要求メッセージは、ＭＡＣが正当なものと検証されたか否かを示す情報を含むことができる。
【００７４】
擬似ＢＩＮの使用
承認応答が、発行人へ送信された承認要求メッセージのアクワイアラーＢＩＮに基づき支払いネットワークを通じてルーティングされる場合、マスターカードは、トランザクションメッセージ内のアクワイアラーＢＩＮを、「擬似」アクワイアラーＢＩＮとして機能する特別マスターカードＢＩＮで置換することができる。アクワイアラーＢＩＮが置換された結果、発行人は当該アクワイアラーの代わりにマスターカードへ応答する。支払いネットワークが、承認要求メッセージがどこから送信されたのか、および、承認応答メッセージを同じ場所に送信したのかの記録を保持している場合は、このステップを実行する必要はない。
【００７５】
擬似アクワイアラーＢＩＮを使用する場合は、アクワイアラーおよび発行人が交換料金(interchange fee)を正確に計算するために、擬似アクワイアラーＢＩＮは、アクワイアラーが位置する国、または、同じ交換料金提供するであろう地域、或いは、その他の国、に対応すべきである。それぞれの国がそれら国に関連付けられた特別ＢＩＮを持つ場合は、マスターカードは、アクワイアラーＢＩＮを当該アクワイアラーの国に関連付けられた特別ＢＩＮで置換することができる。アクワイアラーの国が、その国に関連付けられた特別ＢＩＮを持っていない場合は、同じ交換料金を生じるような、その他の国に関連付けられた特別ＢＩＮを選択することもできる。
【００７６】
擬似アクワイアラーＢＩＮを使用する場合は、マスターカードは、データベースに、アクワイアラーから承認要求で受信したアクワイアラー基準（reference）データを格納する（以降、「オリジナルアクワイアラー基準データ」とも呼ぶ）。発行人のための承認要求をフォーマットする場合、マスターカードは、オリジナルアクワイアラー基準データを、擬似アクワイアラーＢＩＮ、適切なトランザクションタイプインジケータ、および、オリジナルアクワイアラー基準データを見つけるためにマスターカードが使用できるような、インデックス値、を含む「擬似」アクワイアラー基準データで置換する。
【００７７】
セキュアードアプリケーション承認システム（或いは検査サイト）が、実際の承認要求を受信するまで待たずに、新たなＥＴＳＮを受信するときに、ＭＡＣが表示する満了日を計算し格納することでより効率的にすることもできる。その後、承認要求を受信したとき、当該承認要求メッセージ内の満了日と、以前の承認要求メッセージ内のいずれかの満了日といまだにマッチしていない、過去４８時間以内に事前計算され格納されたものとを比較する。
【００７８】
承認要求の発行人の取り扱い
発行人は、その他のいずれかのトランザクションのようにトランザクションを承認する。承認応答は、「擬似」アクワイアラー、即ち、特別支払い口座番号トランザクションを初めに受信した検査サイト、或いは、同じマスターカードセキュアードアプリケーション承認システムへ、ルーティングで戻される。
上述したように、検査サイトは、ＭＡＣが検証されたか否かの表示を伴う承認応答をアクワイアラーへ送信する。その後、このメッセージは、通常のマスターカードトランザクションのように、アクワイアラーから商人へ送信される。
【００７９】
追加フィールドを使用しての認証
本発明のＭＡＣは、例えば３つの十進数の数字からなる別個のＭＡＣフィールドに書き込むことができる。これらの１３の数字は、以下のようにすることができる。
１．１つの十進数の数字の「バージョンインジケータ」フィールド。このフィールドは、通常は「１」を含む。しかしながら、カード所有者が、同じ特別支払い口座番号のためのセキュアードアプリケーションのコピーを複数持っている場合は（例えば、デスクトップコンピュータとラップトップコンピュータ上に）、セキュアードアプリケーションの追加バージョンは、バージョン表示フィールドに異なる数字を持つこととなる（セキュアードアプリケーショントランザクションシーケンス番号は、セキュアードアプリケーションのこのようなバージョンのそれぞれに対して固有である）。
２．６つの十進数の数字であって、セキュアードアプリケーションのこのバージョンのためのセキュアードアプリケーショントランザクションシーケンス番号。このフィールドは、この特定のコンピュータで始動されたセキュアードアプリケーショントランザクションごとに増分される（各コンピュータは、セキュアードアプリケーションの自己のバージョンを持ち、従って、それ独自のシーケンス番号のセットを持つこととなる）。
【００８０】
３．ＭＡＣ自身、６桁の十進数の数字
この状況では、お勧めのＭＡＣ生成プロセスは以下のようになる。
(a) セキュアードアプリケーションバージョン番号（左に）およびセキュアードアプリケーショントランザクションシーケンス番号（このコンピュータのための）の７桁の数字を２進化１０進数で記述し、その結果、２８ビットを生成する。６４ビットフィールド内でこれら２８ビットを左寄せし、その右側にゼロのビットをパッディング（埋める）する。
(B)カードごとの鍵の最も左側の８バイトを暗号鍵として使用して、ステップ１の結果をＤＥ暗号化（DE-encrypt）する。
(c)カードごとの鍵の最も右側の８バイトを復号鍵として使用して、ステップ２の結果をDE復号（DE-Decrypt）する。
(d)カードごとの鍵の最も左側の８バイトを暗号鍵として使用して、ステップ３の結果をDEA暗号化（DEA-encrypt）する。
(e)ステップ４の６４ビットの結果を４ビットずつの１６桁の１６進数と考える。これら１６桁の１６進数の数字を（左から右へ）スキャンし、１６進数で「９」以下の値を持つはじめの６つの数字を選択する。このようなはじめの６つの数字が見つからない場合は、これらの数字を再スキャンすることによって、残りの必要な数字を選択するが、この時点では、１６進数で「９」を超える数字のみを選択し、選択したそれぞれから１６進数の「Ａ」を引く。
(f)ステップ５の結果を、このトランザクションのための６桁の１０進数のＭＡＣとして使用する。
【００８１】
ＭＡＣは、カード所有者のＰＣのセキュアードアプリケーションによって提供され、また、このＭＡＣは、適切なマスターカードセキュアードアプリケーション機能、或いは検査サイトで検証されることとなる。生成されたとき、ステップ６の結果として生じた６桁の１０進数の数字は、実際のＭＡＣとしてＭＡＣフィールドに挿入される。検証されたとき、セキュアードアプリケーション機能は、ＭＡＣフィールドの最も左の７桁の数字を使用して上述した６つのステップを実行し、その後、ステップ６の結果として生じた６桁の数字と、受信したＭＡＣフィールドの最も右側の６桁の数字とを比較する。その結果、正確にマッチした場合は、認証されたトランザクションであることを示す。マッチしない場合は、拒絶しなければならないトランザクションであることを示している。
【００８２】
本発明の好適な実施態様は説明を目的として開示したが、当業者は、特許請求の範囲で定義した本発明の範囲や本質から逸脱することなく幾多の追加、変更、および置換が可能であることを理解するであろう。
【図面の簡単な説明】
【図１】本発明の一実施態様によるトランザクション方法に関連する処理コンポーネントのブロック図である。[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a method and system for processing secure financial transactions across a communications network, and more particularly to securely transmitting payments across a computer network such as the Internet and across a public communications channel. It relates to a method and system for transmitting sensitive information.
[0002]
Priority application
This application includes US Provisional Patent Application No. 60 / 225,168 (filed August 14, 2000), “Method and System for Processing Secure Electronic Commerce Transactions”, and Provisional Application No. 60 / 213,325 (June 22, 2000). ), “Same name as previous application”, claiming the benefit of each priority, and which is incorporated herein by reference. This application further claims the benefit of the priority of US Patent Application Serial No. 09 / 833,049 (April 11, 2001), "Improved Method and System for Handling Secure Payments Over Computer Networks" This is incorporated herein by reference, and as such is US Provisional Patent Application No. 60 / 195,963 (Apr. 11, 2000), “Method and System for Processing Secure Payments Over Computer Networks” And US Patent Application Serial No. 09 / 809,367 (May 15, 2001), "Laws and Systems for Processing Secure Payments Over Computer Networks", each claiming the benefit of priority.
[0003]
Obviously, online commerce has grown tremendously over the last few years, but in fact, the ever-growing consumer is still going beyond public communication networks such as the Internet, credit card numbers and personal identification I'm worried or worried about sending information such as a number (password) or using personal financial information. As a result, in the last few years, companies have worked hard to find the best way to ensure secure payments across computer networks and reduce the risk of financial theft and misuse. .
[0004]
For example, US Patent Application No. 5,883,810 “Electronic Online Commerce Card Using Transaction Proxy Number for Online Transactions” (assigned to Microsoft Corporation) provides a temporary transaction number for each transaction, Is intended for a system where the transaction number looks like a real credit card number and the customer uses this transaction number and submits it to the merchant instead of the customer account number. In this regard, customers do not need to send their true credit card numbers across public networks.
[0005]
In the aforementioned '810 patent, the merchant passes the transaction number to the issuing authority, which then uses the transaction number as an index to access the real customer account number, processes the approval, and approves or authorizes the response. To the merchant based on the transaction number. As a result, the risk can be minimized according to the claims of the patent. The reason is not only that the customer sends the transaction number, but also the proxy number is only valid for a single purchase, ie, “the thief stole because it cannot be used repeatedly for other shopping and transactions. But I can't get a big profit "(Col. 2, lines 60-61).
[0006]
Traditional systems need to be improved, and more specifically, avoid the need to send and generate unique transaction numbers that are repeatedly generated, and replace permanent account numbers for each processed transaction. What is needed is a method and system for processing secure financial transactions across the Internet.
[0007]
Co-pending application 09 / 809,367 (March 15, 2001) is incorporated herein by reference, but a “pseudo” account number is assigned to the customer and cryptographically the customer's payment account. Linked to a number. This payment account number is an account number issued by a financial institution or other organization that a customer can use to pay for goods and / or services. For example, the payment account number may be an account number obtained from a payment (settlement) card such as a credit card or debit card, or from a payment application such as an electronic cash application stored on the customer's computer. The pseudo account number looks like a real payment account number to the merchant. That is, the pseudo account number has the same length as the proper payment account number and starts with the proper identification number (eg, “5” for MasterCard International Inc. (MasterCard)). The pseudo account number is used by the customer in place of the real account number for all his online financial transactions.
[0008]
According to the invention of co-pending application 09 / 809,367, all transactions based on pseudo account numbers are preferably cryptographically authenticated using a private key unique to each account number. Authentication can be based on a private key of a public key pair (public key authentication) or a secret key other than a private key. Thus, if an unauthorized person attempts to verify some pseudo account number, the number is used to prevent unauthorized transactions.
[0009]
Further, according to the invention of co-pending application 09 / 833,049, a method is provided in which a service provider is assigned to an acquirer code and processes a transaction using a payment network. More specifically, the service provider receives a first authorization request for an authorization request for authorization or authorization of a transaction using the first payment account number;
(i) the first payment account number has a BIN code (bank identification number) associated with the service provider and a second payment account number with a BIN code associated with the issuer of the second payment account number; Associated,
(ii) The first authorization request includes the acquirer code associated with the acquirer
(iii) The first payment account number can be routed to the service provider via the payment network based on the BIN code of the first payment account number.
[0010]
The method further includes the step of the service provider responding to the first approval request by sending a second approval request for authorization or approval of the transaction using the second payment account number. The second authorization request is associated with the service provider and is routed through the payment network to the issuer based on the issuer's BIN code (ie, the BIN code of the second payment account number).
[0011]
In addition, a response to the second authorization request from the issuer is received by the service provider, which includes an acquirer code associated with the service provider and can be routed through the payment network based on the code. A response to the first approval request is then sent by the service provider to the acquirer based on the response to the second approval request, and the response to the first approval request is associated with the acquirer. Preferably, it includes an acquirer code and can be routed through a payment network based on the code.
[0012]
In another preferred embodiment of the invention of this co-pending application 09 / 833,049, a method for processing a transaction with a merchant using a first payment account number associated with a second payment account number. (A) generating a message authentication code based on the details of one or more transactions; (b) sending at least a first payment account number and a message authentication code to the merchant; (c) by the merchant. Requesting authorization (approval) to pay for the transaction using the first payment account number, said request being submitted at the POS terminal using a conventional magnetic stripe payment card And the message authentication code is contained in a track of the type used in conventional payment card magnetic stripes. (D) the first payment account number by requesting approval to pay for the transaction using the associated second payment account number. Responding to an authorization request for, (e) accepting or rejecting an authorization request for the first payment account number based on a response to the authorization request for the message authentication code and the second payment account number A method comprising:
[0013]
This system still has room for improvement and can be further enhanced by protecting information and snoring messages sent during or in connection with financial transactions processed across public communication lines. Such improvements can be implemented without using pseudo or proxy account numbers.
[0014]
Summary of the Invention
Accordingly, the present invention provides a method for processing electronic transactions using a payment account number with a certain amount of funds available using a payment network and a “test site”. This method
(a) generating a secret key associated with the payment account number;
(b) generating a message authentication code (MAC) specific to the transaction using the secret key;
(c) generating a permission (approval) request message including the message approval code;
(d) transferring the approval request message across the payment network to the inspection site to verify the authenticity of the MAC;
(e) verifying the message authentication code by the inspection site using the secret key;
(f) responding to the approval request message across the payment network based on the transaction amount and the available funds;
Is included.
[0015]
According to a preferred embodiment of the present invention, the approval request message is routed across the payment network based on the special bank identification number corresponding to the inspection site. The software is preferably placed at the user's location to generate a secret key.
[0016]
According to another preferred embodiment of the present invention, the approval request message includes an expiration date field, and the message authentication code is placed in this expiration date field.
[0017]
Further objects, features and advantages of the present invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, which illustrate preferred embodiments of the invention.
Throughout the drawings, the same reference signs and characters refer to the same functions, components, or parts in the described embodiments unless otherwise specified. Furthermore, the subject matter of the present invention will be described in detail with reference to the drawings together with preferred embodiments. It is intended that changes and modifications may be made to the described embodiments without departing from the spirit and scope of the claimed subject matter.
[0018]
Detailed Description of the Preferred Embodiment
As mentioned above, the present invention is directed to a method and system for processing secure electronic commerce (e-commerce) transactions using a payment account number, such as a credit card account number. In a preferred embodiment of the present invention, the payment account number is a virtual payment account number, ie it is an ISO (International Standards Organization) 7816 account number, which is used in electronic transactions, There is no need to link to a new ISO7816 type card. Alternatively, the payment account number can be the payment account number issued to the physical ISO7816 type card, or the payment account number can be linked to the payment account number issued to the physical ISO7816 type card. You can also.
[0019]
In the following detailed description of the invention, there are many references to MasterCard International, Inc. (or MasterCard), but this is merely an example, so as to process a special payment account number as described below. It is a special one. The following acronyms may be used.
[0020]
BIN-Bank identification number
DEA-Data encryption algorithm
PC-Consumer personal computer device
MAC-Message authentication code
MCI-MasterCard International or Mastercard
MCWS- MasterCard website
PIN-Personal identification number (password)
POS-Point of sale management
SSL-Secure Socket Layer (Internet security)
TSN-Transaction sequence number
[0021]
According to one aspect of the invention, one or more BIN ranges or BINs of a payment account number are associated with a secure e-commerce transaction. These BINs or BIN ranges may hereinafter be referred to as “special” BINs or BIN ranges. A payment account number with a special BIN may hereinafter be referred to as a “special” payment account number.
[0022]
According to another aspect of the invention, the owner of the special payment account number is provided with a private key (key per card) and when the e-commerce transaction is processed using the special payment account number. This key can be used to generate a message authentication code (MAC).
[0023]
According to yet another aspect of the invention, at least one function with a copy of the private key is provided, which can be used to verify the MAC generated by the owner of the special payment account number. Such a function may hereinafter be referred to as an “inspection site”.
[0024]
Thus, as shown in FIG. 1, the present invention has several processing components, which will be described. Special payment account number (SPAN) owners or consumers can be provided with a secure special payment account number software application (SPANSA) on their computer 10. SPANSA maintains a secret key associated with the SPAN and uses this key to generate a MAC. The MAC is sent to the originating merchant 12 and forwards an approval request message (MAC) to the acquirer bank 14 (member acquisition bank) to initiate the approval process.
[0025]
E-commerce transactions that use special payment account numbers are preferably approved through the payment (settlement) network 16. For example, if the special payment account number is a master card credit card number, these may be authorized through the bank card payment network of the master card. An authorization request message and an authorization response message for the special payment account number are routed through the payment network 16 to the inspection site 18 based on the special BIN of the account number. Thus, for example, issuing and acquirer computers that interface with payment network 16 may include a look-up table that points to a special BIN corresponding to inspection site 18. However, one or more computers at the inspection site 18 that interface with the payment network 16 include a look-up table that indicates the issuer corresponding to the special BIN.
[0026]
According to the present invention, when the inspection site 18 receives the approval request message, the inspection site 18 can verify the MAC associated with the transaction using the private key associated with the special payment account number. Further, the inspection site 18 can transmit an approval request message to the issuer 20 (the institution that issued the special payment account number). The inspection site 18 responds to the approval request message with an indication of whether the MAC has been verified (ie, verified as authentic) and / or with an approval response from the issuing authority.
[0027]
When the inspection site 18 forwards the approval request message to the issuing organization, the inspection site can display on the issuing organization 20 whether or not the MAC has been verified. As an example, assuming that the special payment account number is the credit card or debit card account number of the master card, the inspection site will either debit the master bank debit switch to the issuing bank, in the outgoing bank net, or In the message, it can be shown that the MAC has been verified. This display can be a newly defined value in the current security display field used in the “0100/0200” type message on the master card. The inspection site erases the contents of the incoming security level display section for all transactions, and writes the supplied security level (that is, whether or not the MAC is verified) to the output. it can.
[0028]
In the exemplary transaction using a special payment account number, the issuing bank authorization response message is routed back to the inspection site because of the special BIN range. If the approval response message indicates approval, the inspection site 18 displays “approval” on the display or indicator that the MAC returns to the verified acquirer. The acquirer 14 then sends the message back to the originating approval 12. In this way, the merchant learns not only that the issuing bank has approved the transaction through its acquirer but also that the inspection site has confirmed the validity of the MAC. This means that the transaction must have originated from the cardholder, and it can be a “guaranteed” transaction.
[0029]
As mentioned above, SPANSA can be stored on a special PAN owner's computer. Further, apart from the computer, this application can also be stored in a mobile phone or a personal digital assistant (PDA). It is preferred that the special PAN owner make a request to the application across the Internet from a website 22 (eg, an issuer's website, including an inspection site, or other suitable location). The website is preferably coupled to or accessible to a hardware security module 24 that has the ability to create a customer-specific secret encryption key, such as a DES key. Each security module preferably includes one or more “derivation keys” as used to generate and regenerate a secret cryptographic key unique to the customer.
[0030]
The secure PAN application stored on the owner's computer can include a transaction sequence number (discussed in detail below) and must communicate with the inspection site or other support site for each trunkion There is no. Instead, the application stored on the special PAN owner's computer exchanges transaction sequence counters with the inspection site or other support site at any interval desired by the special issuing authority. Can be synchronized.
[0031]
The present invention can also be used with a remote wallet server. In this case, the secure PAN application is not stored and is managed and maintained by the special PAN owner's computer system. Advantageously, in this embodiment, the present invention allows a special PAN owner to use a common Internet browser, using this remote wallet server (this server is a secure With PAN application). In this embodiment, the special PAN owner's local system does not need to include any additional software or functionality that is superior to a typical Internet browser.
[0032]
Advantageously, the present invention allows the use of a virtual reality first account number. In contrast to systems that use pseudo or proxy account numbers, the present invention can be switched by the acquirer's computer without conversion, requiring changes to the back end switching or processing functions. There is no.
[0033]
Also, in contrast to systems that use pseudo or proxy account numbers, the present invention simplifies all payment procedures by 1) eliminating the need to send a clearing file to the central site. 2) Eliminates the need for charge back that needs to be returned to the central site, and 3) the transaction is sent to the central site system for conversion to a real account number Remove all search requests made by the cardholder after being placed on the bill. The cardholder is provided with and uses a real account number for these transactions.
[0034]
In contrast to systems that use pseudo or proxy account numbers, the present invention addresses the need to create and manage the transaction log storage required to convert a special payment account number to a real account number. Remove.
[0035]
The MAC can be sent to the inspection site in a number of ways. An example of a method for transmitting the MAC to the inspection site is shown below.
MAC option 1
In this embodiment, the MAC is placed in the card expiration date (expiration date) field and behaves as a “pseudo expiration date”. MAC generation is described in further detail below. In this embodiment, there is no need to make any changes to the merchant site. The only additional requirement considered for the merchant is the merchant's ability to accept an additional authorization response field in the message from the acquirer indicating that the transaction MAC has been authenticated, but use this There is no need. The field used for this display can be any field currently supported in a normal bank card authorization message send / receive POS system.
[0036]
MAC option 2
This embodiment can be used in conjunction with other options. In this embodiment, the cardholder's computer or remote wallet server maintains a log of merchant data associated with the transaction. For example, a cardholder's computer or remote wallet server
(a) Transaction MAC,
(b) the merchant's web address (URL),
(c) Merchant Secure Socket Layer (SSL) certification serial number and / or
(d) Full merchant SSL certification,
Log.
This embodiment allows the log to provide sufficient data to prove that the claim is incorrect if the cardholder later claims that the transaction was not initiated by him. This provides further safety. In this embodiment, the merchant website has not changed.
[0037]
MAC option 3
In this embodiment, the transaction MAC is placed at the card expiration date location, as in option 1 or 4. The MAC is generated based on merchant-provided data elements. This merchant-provided data element is passed to the cardholder or remote wallet server in an additional separate field designed to transmit the merchant-provided data necessary to calculate the MAC. In one embodiment, the merchant, such as the merchant's SSL certificate serial number, is linked to a data element that is already held in the data field used in the MAC operation. For example, MAC is the following data element:
(a) PAN,
(b) Real card expiry date (4-digit number MMYY format),
(c) Transaction sequence number (this is kept synchronized both at the cardholder's system and at the inspection site),
(d) transaction date and time,
(e) Secure PAN application version number,
(f) data identifying the merchant, such as the merchant's SSL certification serial number;
Can be created using.
[0038]
This embodiment requires modification of the merchant's electronic commerce site. Merchants need to modify their system to send their merchant identification serial number in an outbound authorization request message. However, this embodiment provides merchant identification data that is the key to linking the merchant to a particular transaction. The MAC verification step calculated at the cardholder system and at the inspection site has this additional merchant identification field. If the inspection site recognizes that the incoming authorization request message has a merchant-provided certification serial number, it uses it in the MAC calculation and the same process used when the cardholder system generated the MAC To match.
[0039]
MAC option 4
In this embodiment, the transaction MAC is placed in the card expiration date field and in the CVC2 or equivalent field. CVC2 is a three-digit numeric value printed next to the signature field of some cards. As background art, ISO payment cards have a static (at least) three-digit code that is cryptographically generated by the issuer. For example, in a master card payment card, this code is called CVC2. This value can be generated by the issuing bank using a private encryption key and verified using this same key. This option allows the generation of longer transaction MACs (ie, the MAC output size is incremented by 3 digits). In this embodiment, the CVC2 (or equivalent code) field is dynamically generated and filled with the MAC. The merchant site needs to support cardholder prompting and subsequent transmission of CVC2 or equivalent fields.
[0040]
MAC option 5
In this embodiment, the transaction MAC is placed in CVC2 or a corresponding field. This embodiment makes it possible to generate at least a three-digit MAC.
In the preferred embodiment of this option, when the MAC is generated for a transaction, the MAC contrasts the real or static CVC2 value (ie, the CVC2 value generated by the issuing bank and issued with the payment card). Inspected. If the generated MAC is the same as the static CVC2 value, the secure PAN application transaction counter is incremented and a new MAC is generated. This new MAC is then compared with a static CVC2 value, so that it is determined whether the two values are the same. This process is repeated until the generated MAC value is no longer the same as the static CVC2 value. When the MAC is verified for a transaction, this verification process compares the CVC2 value received with the one sent with the transaction with the expected static CVC2 value for the payment card. If these values are the same, the verification process determines that the secure PAN application is not used for the transaction and the MAC is not being transmitted. If the received CVC2 value is different from the static CVC2 value, it is determined that the secure PAN application is being used for the transaction and that the CVC2 field contains the MAC. The verification process then attempts to verify the MAC in the CVC2 field.
[0041]
Special payment account numbers need not be used in this embodiment (although they can also be used). Instead, as described above, the value in the CVC2 field can be used to determine when a secure PAN application was used in the transaction.
[0042]
General background of cardholder authentication
Many cardholder authentications are provided and well known in the art, but may be specified by the issuer of the cardholder's secure PAN application. Authentication methods include, but are not limited to, the use of a remote wallet server accessed by the cardholder's Internet browser, such as Netscape using SSL or Microsoft Internet Explorer browser. Here, the authentication method can include the use of access by user ID and password and / or the use of access of chip card based digital ID authentication. In the case of a remote wallet server, the present invention may also include locally stored applications such as those managed and maintained by the cardholder system itself.
[0043]
The transaction authentication of the present invention is provided by the generation of a MAC that exceeds the transaction details as described below.
[0044]
The protection of the account number of the present invention can be further enhanced by the use of a virtual account number, which consists of a zero value of the magnetic stripe in a face-to-face transaction at a POS terminal (issued to the virtual account number). Because there is no magnetic stripe). In connection with the fact that these virtual account numbers must fall within the special BIN range indicating these account numbers required for routing to the inspection site, each issuing authority has a special A BIN range is given, so that virtual account numbers are used under the present invention.
[0045]
In the case of the present invention, the need for merchant authentication before revealing the cardholder's own account number is eliminated because the account number of the present invention cannot be used without the transaction-specific MAC associated with it. Is done. Any unauthorized use of an account number under the present invention, such as replaying a transaction with an old MAC without cardholder authentication, is routed to a special inspection site, but for that transaction attempt No verification is performed. Thus, all unauthorized use attempts will fail.
[0046]
The cardholder can provide a password before downloading the secure PAN application, or can select the password when the application is installed on the cardholder's PC. If a password is selected or provided, then the cardholder must enter this password to activate the application on his PC. This password selected by the cardholder can be used to encrypt or otherwise change the private key. This secure PAN application can also be downloaded as part of a digital wallet application.
[0047]
Generation of customer-specific secret key
The private key embedded in the secure PAN application is unique to each special payment account number and is preferably derived from the security module using the derived key and special payment account number. It can be a derived key for each issuer or each BIN range. The derived key can be, for example, a triple-length DEA key. Any encryption method known in the art can be used to generate a customer specific key with a derived key.
[0048]
The inspection site preferably has binding or access to a security module that has a copy of the derived key therein. When the inspection site receives an authorization request for a special payment account number, the inspection site uses the appropriate derived key with the special payment account number to derive the key necessary to verify the MAC.
[0049]
MAC generation
An exemplary method illustrating that a MAC can be generated and used in accordance with the present invention is shown below. As described above, the MAC can be placed in the transaction expiration date field. The MAC then behaves as a “pseudo” expiration date. This pseudo expiration date is formatted in the MMYY format like the expiration date. Desirably, the pseudo-expiration date is included within 48 months of the transaction so as to work with all or most merchant's current processing systems in the market today.
[0050]
Preferably, it includes a secure PAN application (hereinafter also referred to as a “secured application”), a transaction sequence number, which consists of 20 digits of bits and is incremented for each transaction. Therefore, 2²⁰Until that is, that is, until about 1 million transactions are generated, the rotation from all zero to all one is not performed. The secured application can also include a 4-bit “version number”, which is a number unique to each PC or other device on which the secured application exists for a given account number. is there.
[0051]
For each transaction processed by the cardholder's secured application, the transaction sequence number is first incremented. The resulting 20-bit number, and the 4-bit secured application version number concatenated to its left, is left justified in the 8-byte field and padded with binary zeros on the right, double-length secured Three times longer DEA encryption is performed using a key for each card of the application. The result is a 64-bit binary MAC.
[0052]
Write MAC to expiration date field
The transaction expiration date field can then be obtained from the 64-bit binary MAC described above as follows.
1. Select the leftmost “1” bit in “Number of month display (binary number, will be explained in more detail below)”, and the bit from this bit position to the rightmost bit (least significant bit) Count the number of positions (including the leftmost “1” bit). This number is called “N”. For example, when the “number of months display” is “0101 0100 (84 in decimal)”, the value of “N” is 7. After determining “N”, the 64-bit binary MAC is considered as a group of “N” bits, and the leftmost left-most bit is ignored. Start from the leftmost group and select the first group found below the number of months displayed. If no such group is found, select the leftmost group, add “Number of Months” to this selected group, and add 2^NAnd use this result (this is> 0 and <"number of months") as the selected value.
2. The result of step 1 is divided by the binary number “1100 (12 in decimal)” to generate a quotient and a remainder. Convert this quotient and remainder to decimal. Add this remainder in decimal (with a value in the range 00 to 11) to the two leftmost (most significant) decimal digits (MM) of the "reference date", but this Will be described in detail later. If the result exceeds 12, subtract 12 from the result and in any case,
The result is used as the leftmost number on the card expiration date for the transaction, ie MM. If the result obtained needs to subtract 12, increment the quotient by one.
3. The quotient of the two decimal numbers from step 2 (which may have been incremented as described in step 2) is added to the rightmost two digits (YY) of the “base date” and modular at 100 Calculate (Add, mod-100 ...). The result is used as the two rightmost numbers, YY, for the card expiration date for the transaction.
[0053]
Write MAC to CVC2 field or equivalent
The MAC can be generated by the method described above, but can be generated by any method known in the art. Further, in addition to or instead of placing the MAC in the expiration date field, the MAC, or a part thereof, can be placed in, or written to, the CVC2 field or a corresponding field.
[0054]
Communication between cardholder and merchant
Once the secured application is installed on the cardholder's computer, the cardholder uses this secured application for all Internet payments, and this secured application is used by the cardholder for all internet transactions. Provide a special payment account number. The fact that this is a secure application transaction is transparent to the merchant, ie, the merchant is unaware. Although the account number is actually a special payment account number and the expiration date can actually represent the MAC, the merchant is unaware that the transaction is different from other Internet SSL transactions received.
[0055]
More specifically, whenever the MAC field is supported by the merchant, the secured application uses the private key embedded in it to create a message authentication code (MAC) associated with the transaction, and the MAC Place this MAC and data based on it in the field, which becomes part of the transaction.
[0056]
Upon receipt of the cardholder transaction message, the merchant formats a conventional authorization request for the acquirer. This approval request preferably includes the MAC field as provided by the consumer's PC.
[0057]
Only those that include the MAC field and expiration date at the beginning of the transaction, the merchant should initiate multiple approvals / clearings transactions for the cardholder's transaction. Subsequent transactions include only the payment account number and can be thought of as mail order / phone order transactions generated by the merchant.
This is also true for all repeated and partial payments with multiple clearings.
[0058]
Handling requester approval requests
When an acquirer receives an approval request from an internet merchant, it looks up the issuer BIN in its own BIN table. In the master card payment system, if the acquirer determines that the BIN of the transaction corresponds to an issuer other than the home country, the acquirer routes the transaction to the master card via the bank net system. If the acquirer determines that the BIN for the transaction corresponds to the issuer in his country, the transaction can be routed to the master card via the bank net. Alternatively, if the issuer is in the same country as the acquirer, the acquirer can usually route the transaction directly to the issuer specified by the BIN. In the case of a special payment account number transaction, the transaction is preferably routed to a central processing function (preferably a processing function of the master card approval, i.e., an inspection site).
[0059]
In some embodiments of the present invention, some countries may have the capability of special security module equipment to handle domestic transactions. Each of these functions is preferably set up only by master card authorization and preferably only holds account number conversion data and encryption keys for the transaction country to process. In a country with such a country inspection site function, all transactions are sent using this function, so that transactions in the same country need not leave that country. The country's inspection site function that processes domestic transactions can be more efficient than sending all transactions to the central processing function.
[0060]
Starting a secured application
The secured application can be started on a transaction-by-transaction basis, just before secure application-based payment is performed. The secured application sends the request to a payment processing website (preferably a master card website or server). This request may include, for example, a 16-digit special payment account number, a payment account number expiration date consisting of 4 decimal digits, a 4-bit secured application version number, a current value of a 20-bit transaction sequence number, and , And a 16-bit MAC (Message Authentication Code) based on the latter three of these values. The MAC is concatenated with a 20-bit transaction sequence number, and further using a 16-bit expiration date (in binary-coded decimal) concatenated with a 4-bit secured application version number (from left to right) This is left-justified within a 64-bit field, padded with binary zeros to the right, and then encrypted with triple-length DEA encryption by selecting the leftmost 16 bits of the resulting ciphertext Can be done.
[0061]
When the website receives this information, the site uses a secured application system with a special security module to verify the MAC based on the secured application version number, transaction sequence number, and expiration date. If the MAC is verified, i.e. proved to be authentic, the system increments (holds) the transaction sequence number and generates an "expected transaction sequence number (ETSN)" The secure application version number and the ETSN for the special payment account number of the secure application authentication system (eg, inspection site) in question to process the secure application approval request for the BIN of the special payment account number. This secured application approval system (inspection site) will determine if the received ETSN is equal to or less than the highest numbered ETSN previously received for this secured application version number and special payment account number. Reject the ETSN just received. The secured application authorization system (inspection site) is also given an expiration date that has just been received, and this special payment account number will be included if the expiration date just received is later than the current expiration date in the record. Update the associated expiration date.
[0062]
The special secured application system preferably sends the following two data values to the web, which then sends them to the secured application of the cardholder's PC.
1) A data value called "reference date". This is a 4-digit decimal number in the MMYY format (actually the date of the current or next month).
2) A data value referred to as “number of month indications”. This is an 8-bit binary number with a maximum value less than 256 (in decimal). These data are also included in the information sent to the appropriate secured application approval system (inspection site).
[0063]
Central processing function (and / or country function) to process approval requests
With the special BIN for the special payment account number, the acquirer and payment network will route the transaction to the inspection site.
The inspection site shall record the ETSN record with the highest 20-bit number received for each secured application version number and special payment account number that the MAC is valid against this transaction sequence number ( A) Stores with verification indication. In addition, the inspection site stores the “expected transaction sequence number” received within the last 48 hours regarding that the MAC has not been verified. In association with each such expected transaction sequence number, the system also stores a “number of month indications” and a “base date” indication that match each expected transaction sequence number.
[0064]
The “reference date” is a date value indicating the earliest expiration date that can be accepted by the approval request message. By way of background, some merchants request approval in batches together, rather than promptly requesting approval. Thus, this date is typically one or two days before the date the transaction was initiated.
[0065]
The “number of month indications” indicates a number representing a month after the current date corresponding to the latest expiration date on which the payment card is accepted.
[0066]
The inspection site has access to, or is bound to, a security module that has the ability to determine a unique and secret 16-byte encryption key that is placed in the secured application of the cardholder's PC when it is registered Has been. The processing executed at the inspection site is as follows.
[0067]
1. A security module is used to determine a unique encryption key for this secured application using the appropriate derived key and special payment account number.
2. Select the first 20-bit ETSN received within 48 hours for an unverified MAC. A 64-bit MAC is calculated based on the secured application version number associated with that ETSN and this 20-bit transaction sequence number as defined above for the PC's secured application. Determine the expiration date from this MAC using the method defined above for the PC's secured application, using the "number of month indications" and "base date" specified for the associated ETSN . If the determined expiration date is the same as the expiration date of the current transaction, the MAC has been properly verified. This ETSN entry resulting from MAC verification is marked as “MAC verified” if this entry is the highest numbered ETSN for the secured application version number associated with it. Alternatively, if it is not the ETSN assigned the largest number, it is deleted. Entries are now deleted in the lower numbered ETSN marked as “MAC verified” and associated with the same secured application version number.
[0068]
3. If step 2 (or step 4) verifies that the Mac is valid, then it is known that the merchant of this transaction will never send a second approval request message for the same transaction An entry is made in the “history data” for this special payment account number. It should be noted that some merchants can also send a second or more authentication request message if they cannot ship all of the goods with a delivery date specified after the transaction. This historical data entry includes all of the data described above, and in addition, the identity of the merchant and acquirer, and an “expiration date” for this entry. This expiry date entry is a designated time in the future (eg, 6 months).
[0069]
If step 2 did not verify that the MAC is valid, the other “expected” received within the last 48 hours, from the oldest to the latest that is not associated with the already verified MAC The procedure defined in step 2 is repeated for all the “transaction sequence numbers”. Again, if the date resulting from these attempts matches the date of the current transaction, the MAC is considered verified. When the MAC is verified, if the 20-digit ETSN resulting from the MAC verification is the highest ETSN for the associated secured application version number in question, the 20 resulting from the MAC verification The digit ETSN is marked “MAC verified” and is deleted if it is not the highest ETSN for the associated secured application version number in question. If the MAC is verified at this step, step 3 is also executed.
5. If neither the step 2 nor the step 4 verifies that the MAC is valid, the “history data” for the special payment account number in question is accessed. If there is an entry of data for the same merchant and acquirer that generates the same expiration date MAC and the entry has not expired, accept the MAC (this is an additional for already approved transactions) Is presumed to be an approval request message). When the MAC is accepted for this entry, if the expiration date of this entry is less than two months, this expiration date should be about two months. The reason is that this may be a “repeat payment” and there may be other approval request messages for the same transaction around the next month.
[0070]
If the MAC is not verified as valid in step 2, step 4 or step 5, the transaction is rejected. In this case, a “reject” response is sent to the acquirer and / or the fact that the MAC was not verified is displayed in a special field such as the security field described above.
[0071]
In summary, the inspection site looks at the presence of the MAC field. The inspection site determines the secret key (as described above) and uses this key to verify the MAC using essentially the same procedure used on the PC to create the MAC. The system also checks the transaction Siemens number and, in order to do so, must maintain transaction sequence number information for each version number for each special account number that it processes.
[0072]
This system
1. The transaction sequence number is less than or equal to the largest transaction sequence number for this version of this secured application number received at least 48 hours ago, or
2. Whether the transaction sequence number matches any of the transaction sequence numbers already received for this version of this secured application number;
If the transaction is rejected.
[0073]
If the verification of the MAC or transaction sequence number fails, the function will reject the transaction and / or display a verification failure in an appropriate field, such as a SET security field. If both the MAC and the transaction sequence number are verified as valid, this function routes the transaction to the issuer.
If the MAC is verified as valid, the central processing function, or inspection site, formats an approval request message for the issuer. The approval request message can include information indicating whether the MAC is verified as valid.
[0074]
Use of pseudo-BIN
If the approval response is routed through the payment network based on the acquirer BIN of the approval request message sent to the issuer, the master card will specialize the acquirer BIN in the transaction message as a “pseudo” acquirer BIN. It can be replaced with a master card BIN. As a result of replacing the acquirer BIN, the issuer responds to the master card on behalf of the acquirer. This step need not be performed if the payment network keeps a record of where the authorization request message was sent from and where the authorization response message was sent to the same location.
[0075]
When using a pseudo-acquirer BIN, the pseudo-acquirer BIN provides the same exchange fee as the country in which the acquirer is located, in order for the acquirer and issuer to accurately calculate the interchange fee. It should correspond to the region or other countries that will be. If each country has a special BIN associated with those countries, the master card can replace the acquirer BIN with the special BIN associated with that acquirer's country. If the acquirer country does not have a special BIN associated with that country, it can also select a special BIN associated with another country that results in the same exchange fee.
[0076]
When using the pseudo acquirer BIN, the master card stores the acquirer reference data received in the approval request from the acquirer in the database (hereinafter also referred to as “original acquirer reference data”). When formatting an approval request for an issuer, the master card can use the original acquirer criteria data to find the pseudo acquirer BIN, the appropriate transaction type indicator, and the original acquirer criteria data. Is replaced with “pseudo” acquirer reference data including index values.
[0077]
When the secure application approval system (or inspection site) receives a new ETSN without waiting for an actual approval request to be received, it calculates the expiration date displayed by the MAC and stores it more efficiently. You can also. Subsequently, when an approval request is received, the expiration date in the approval request message does not yet match any expiration date in the previous approval request message, and has been precalculated and stored within the past 48 hours And compare.
[0078]
Handling of issuers of approval requests
The issuer approves the transaction like any other transaction. The authorization response is routed back to the “pseudo” acquirer, ie, the test site that originally received the special payment account number transaction, or the same master card secured application authorization system.
As described above, the inspection site sends an approval response with an indication of whether the MAC has been verified to the acquirer. This message is then sent from the acquirer to the merchant like a normal master card transaction.
[0079]
Authentication using additional fields
The MAC of the present invention can be written into a separate MAC field consisting of, for example, three decimal digits. These 13 numbers can be as follows:
1. “Version Indicator” field with one decimal digit. This field normally contains “1”. However, if the cardholder has multiple copies of the secured application for the same special payment account number (eg, on desktop and laptop computers), an additional version of the secured application will appear in the version display field. Will have a different number (the secured application transaction sequence number is unique for each such version of the secured application).
2. Six decimal digits, the secured application transaction sequence number for this version of the secured application. This field is incremented for each secured application transaction started on this particular computer (each computer will have its own version of the secured application and thus will have its own set of sequence numbers).
[0080]
3. MAC itself, 6-digit decimal number
In this situation, the recommended MAC generation process is as follows.
(a) Describe the 7 digit number of the secured application version number (to the left) and the secured application transaction sequence number (for this computer) in binary-coded decimal, resulting in 28 bits. These 28 bits are left-justified within the 64-bit field and zero bits are padded on the right.
(B) Using the leftmost 8 bytes of the key for each card as an encryption key, the result of step 1 is DE-encrypted (DE-encrypt).
(c) DE-decrypt the result of step 2 using the rightmost 8 bytes of the key for each card as a decryption key.
(d) Using the leftmost 8 bytes of the key for each card as an encryption key, the result of step 3 is DEA-encrypted (DEA-encrypt).
(e) Consider the 64-bit result of step 4 as a 16-digit hexadecimal number of 4 bits each. These 16-digit hexadecimal numbers are scanned (from left to right) and the first six numbers having a value of “9” or less in hexadecimal are selected. If these first six numbers are not found, rescan these numbers to select the remaining required numbers, but at this point, select only numbers that are more than “9” in hexadecimal. Then, subtract hexadecimal “A” from each selected.
(f) Use the result of step 5 as a 6-digit decimal MAC for this transaction.
[0081]
The MAC will be provided by the secured application of the cardholder's PC, and this MAC will be verified at the appropriate master card secured application function or inspection site. When generated, the 6-digit decimal number resulting from step 6 is inserted into the MAC field as the actual MAC. When verified, the secured application function performs the six steps described above using the leftmost seven digits of the MAC field, and then receives the six digits resulting from step 6 and Compare the rightmost 6 digits of the MAC field. If the result is an exact match, it indicates an authenticated transaction. If it does not match, it indicates that the transaction must be rejected.
[0082]
While the preferred embodiment of the invention has been disclosed for purposes of illustration, those skilled in the art will be able to make numerous additions, modifications and substitutions without departing from the scope and nature of the invention as defined in the claims. You will understand that.
[Brief description of the drawings]
FIG. 1 is a block diagram of processing components associated with a transaction method according to one embodiment of the present invention.

Claims

A method of processing electronic transactions across a public communication network using a payment network linked to an inspection site and using a payment account number with a certain amount of funds available,
(A) a first computer of an issuer issuing the payment account number generating a secret key associated with the payment account number;
(B) a second computer of the owner of the payment account number using the private key to generate a message authentication code specific to the transaction;
(C) the second computer generating an approval request message including the message authentication code;
(D) In order for the third computer at the inspection site to verify the authenticity of the message authentication code, the second computer sends the approval request message to the inspection across the payment network via an acquirer. Transferring to the site;
(E) the third computer using the private key to verify the message authentication code by the inspection site;
(F) the third computer receives a response of the approval request message based on the transaction amount and the available funds from the first computer across the payment network;
A method comprising:
Said third computer, the authorization request message, corresponding to the test site, based on the bank identification number, and routed to the first computer over said payment network,
The approval request message includes an expiration date field, the message authentication code, the Rukoto placed on the expiration date field, behave as a pseudo expiration date, the verification of the message authentication code is performed based on the pseudo-expiration date And
How the first computer provides to verify the authorization request message by the previous SL responsive the issuer.

A payment account number having a bank identification number (BIN) associated with an inspection site and a method of processing electronic transactions across a public communications network using the inspection site, comprising:
(A) a first computer of an issuer issuing the payment account number generating a per-card key associated with the payment account number;
(B) the second computer of the owner of the payment account number generates a message authentication code (MAC) using the key for each card;
A step (c) said second computer generates a MAC verification request including the MAC and the payment account number,
(D) a server for a payment processing website verifies the MAC;
(E) the server generates an expected transaction sequence number (ETSN) for the MAC by incrementing a transaction sequence number associated with an electronic transaction by one based on the validation;
(F) the server providing reference data including at least a reference date associated with the ETSN to a third computer at the inspection site;
(G) the third computer generating a second message authentication code using the per-card key and the ETSN;
(H) the third computer routes the second message authentication code to the inspection site based on the BIN associated with the inspection site;
(I) the third computer determines a key for each card associated with the payment account number of an unverified message authentication code with associated ETSN and reference data; Verifying the second message authentication code by the inspection site using a key and the associated ETSN and reference data;
The step (g) further comprises:
(J) converting the second message authentication code using the reference data into a pseudo-expiration date;
(K) generating an approval request having an expiration date field including the pseudo expiration date;
(L) responding to the approval request and verifying the second message authentication code based on the pseudo-expiration date;
Including methods.

The method of claim 2, wherein
The step of generating the message authentication code further comprises:
Using a transaction sequence number and application version number associated with the payment account number, and an expiration date,
A method characterized by that.

The method of claim 3, wherein
The MAC verification request also includes the application version number and the expiration date.
A method characterized by that.

The method of claim 4, wherein
Verifying the MAC also includes using a per-card key;
A method characterized by that.

The method of claim 2, wherein
The reference data includes a number representing a reference date and a month,
A method characterized by that.