JP4903346B2 - 擬似或いは代理口座番号なしでコンピュータネットワークを越えて安全な支払いを処理するための改善された方法およびシステム - Google Patents

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)ステップ５の結果を、このトランザクションのための６桁の１０進数のＭＡＣとして使用する。
【００８１】
ＭＡＣは、カード所有者のＰＣのセキュアードアプリケーションによって提供され、また、このＭＡＣは、適切なマスターカードセキュアードアプリケーション機能、或いは検査サイトで検証されることとなる。生成されたとき、ステップ６の結果として生じた６桁の１０進数の数字は、実際のＭＡＣとしてＭＡＣフィールドに挿入される。検証されたとき、セキュアードアプリケーション機能は、ＭＡＣフィールドの最も左の７桁の数字を使用して上述した６つのステップを実行し、その後、ステップ６の結果として生じた６桁の数字と、受信したＭＡＣフィールドの最も右側の６桁の数字とを比較する。その結果、正確にマッチした場合は、認証されたトランザクションであることを示す。マッチしない場合は、拒絶しなければならないトランザクションであることを示している。
【００８２】
本発明の好適な実施態様は説明を目的として開示したが、当業者は、特許請求の範囲で定義した本発明の範囲や本質から逸脱することなく幾多の追加、変更、および置換が可能であることを理解するであろう。
【図面の簡単な説明】
【図１】 本発明の一実施態様によるトランザクション方法に関連する処理コンポーネントのブロック図である。

Claims (6)

1. 検査サイトにリンクされた支払いネットワークを使用して、利用可能な一定量の資金を持つ支払い口座番号を用いて、公衆通信ネットワークを越えて電子トランザクションを処理する方法であって、
   （ａ）前記支払い口座番号を発行する発行人の第１のコンピュータが前記支払い口座番号に関連付けられた秘密鍵を生成するステップと、
   （ｂ）前記支払い口座番号の所有者の第２のコンピュータが前記秘密鍵を使用して、前記トランザクションに特有のメッセージ認証コードを生成するステップと、
   （ｃ）前記第２のコンピュータが前記メッセージ認証コードを含む承認要求メッセージを生成するステップと、
   （ｄ）前記メッセージ認証コードの真偽を検査サイトの第３のコンピュータが検証するために、前記第２のコンピュータが、前記承認要求メッセージを、アクワイアラーを介して前記支払いネットワークを越えて前記検査サイトへ転送するステップと、
   （ｅ）前記第３のコンピュータが、前記秘密鍵を使用して、前記検査サイトによって前記メッセージ認証コードを検証するステップと、
   （ｆ）前記第３のコンピュータが、トランザクション額および前記利用可能な資金に基づく前記承認要求メッセージの応答を前記第１のコンピュータから前記支払いネットワークを越えて受け取るステップと、
   を含む方法であって、
   前記第３のコンピュータは、前記承認要求メッセージを、前記検査サイトに対応し、銀行識別番号に基づき、前記支払いネットワークを越えて前記第１のコンピュータにルーティングし、
   前記承認要求メッセージは満了日フィールドを含み、前記メッセージ認証コードは、前記満了日フィールドに置かれることにより、擬似満了日として振る舞い、前記メッセージ認証コードの前記検証は、当該擬似満了日に基づき実行され、
   前記応答は前記発行人によって第１のコンピュータが前記承認要求メッセージを検証して提供する方法。
2. 検査サイトに関連付けられた銀行識別番号（ＢＩＮ）を持つ支払い口座番号および前記検査サイトを用いて公衆通信ネットワークを越えて電子トランザクションを処理する方法であって、
   （ａ）前記支払い口座番号を発行する発行人の第１のコンピュータが前記支払い口座番号に関連付けられたカードごとの鍵(per-card key)を生成するステップと、
   （ｂ）前記支払い口座番号の所有者の第２のコンピュータが前記カードごとの鍵を使用してメッセージ認証コード（ＭＡＣ）を生成するステップと、
   （ｃ）前記第２のコンピュータが前記ＭＡＣおよび前記支払い口座番号を含むＭＡＣ検証要求を生成するステップと、
   （ｄ）支払い処理ウェブサイト用のサーバが前記ＭＡＣを検証するステップと、
   （ｅ）前記サーバが、前記検証に基づき、電子トランザクションに関連付けられたトランザクションシーケンス番号を１増分することにより、前記ＭＡＣに関する予想されるトランザクションシーケンス番号（ＥＴＳＮ）を生成するステップと、
   （ｆ）前記サーバが、前記検査サイトの第３のコンピュータへ、前記ＥＴＳＮに関連付けられた少なくとも基準日を含む基準データを提供するステップと、
   （ｇ）前記第３のコンピュータが前記カードごとの鍵および前記ＥＴＳＮを使用して第２のメッセージ認証コードを生成するステップと、
   （ｈ）前記第３のコンピュータが前記検査サイトに関連付けられた前記ＢＩＮに基づき、前記検査サイトへ前記第２のメッセージ認証コードをルーティングするステップと、
   （ｉ）前記第３のコンピュータが、関連付けられたＥＴＳＮおよび基準データを有する未検証のメッセージ認証コードの前記支払い口座番号に関連付けられた前記カードごとの鍵を決定し、前記決定されたカードごとの鍵並びに前記関連付けられたＥＴＳＮおよび基準データを使用して、前記検査サイトによって、前記第２のメッセージ認証コードを検証するステップと、
   を含み、前記ステップ（ｇ）は更に、
   （ｊ）前記基準データを使用して前記第２のメッセージ認証コードを擬似満了日に変換するステップと、
   （ｋ）前記擬似満了日を含む満了日フィールドを持つ承認要求を生成するステップと、
   （ｌ）前記承認要求に応答し、前記擬似満了日に基づき前記第２のメッセージ認証コードを検証するステップと、
   を含む方法。
3. 請求項２に記載の方法において、
   前記メッセージ認証コードを生成するステップは、さらに、
   前記支払い口座番号に関連付けられたトランザクションシーケンス番号およびアプリケーションバージョン番号、および、満了日を使用するステップを、含む、
   ことを特徴とする方法。
4. 請求項３に記載の方法において、
   前記ＭＡＣ検証要求は、前記アプリケーションバージョン番号および前記満了日をも含む、
   ことを特徴とする方法。
5. 請求項４に記載の方法において、
   前記ＭＡＣを検証するステップは、前記カードごとの鍵を使用するステップをも含む、
   ことを特徴とする方法。
6. 請求項２に記載の方法において、
   前記基準データは、基準日および月を表す数字を含む、
   ことを特徴とする方法。

Images