JP5093957B2 - コンピュータネットワーク上で安全な支払いを行うための向上した方法及びシステム - Google Patents

Description

【０００１】
優先権申請
本申請書は、２０００年８月１８日登録、名称「コンピュータネットワーク上で確実なマスターカード支払いを実行するための方法および装置」なる、米国暫定出願第６０／２２６，２２７号、および、２０００年６月２１日登録、名称「コンピュータネットワーク上で確実な支払いを実行するための改良法およびシステム」なる、米国暫定出願第６０／２１３，０６３号に対する優先権を主張するものである。ここに、両暫定申請を引用することにより本申請書に含めることにする。本申請書はさらに、それ自体、２０００年４月１１日登録、名称「コンピュータネットワーク上で確実な支払いを実行するための方法およびシステム」なる米国特許出願連番６０／１９５，９６３号、および、２００１年３月１５日登録、名称「コンピュータネットワークにおける確実な支払いのための方法およびシステム」なる、米国特許出願連番第０９／８０９，３６７号にたいして優先権を主張する、２００１年４月１１日登録、名称「コンピュータネットワーク上で確実な支払いを実行する改良法およびシステム」なる、米国特許出願連番第０９／８３３，０４９号にたいする優先権を主張する。この最後の特許出願を、引用することによって本申請書に含める。
【０００２】
（発明の背景）
本発明は、通信ネットワーク上で確実な金銭取引を実行するための方法およびシステム、さらに詳細には、インターネットのようなコンピュータネットワーク上で確実に支払いを伝送し、かつ、公共通信チャンネル上で、微妙な機密情報を確実に伝送するための方法およびシステムに関わる。
【０００３】
自明の通り、過去数年において、オンライン商売は巨大な成長を経験してきたが、そのように成長してもなお、消費者は依然として、個人の財政情報を使用すること、および、そのような情報、例えば、クレジットカード番号や個人特定番号を、インターネットのような、公共通信ネットワークを通じて伝送することで患わされたり、そうした伝送を不安に思っている。そのため、過去数年、企業は、コンピュータネットワーク上で行われる支払いの安全性を保証し、かつ、財政情報の剽窃や不正使用の危険を下げるための方法を、しかも、最善の方法を求めてあがいている。
【０００４】
例えば、「オンライン取引用、取引仲介番号付き、電子オンライン商業カード」なる名称で、マイクロソフト社に交付された米国特許第５，８８３，８１０号は、各取引毎に一時的取引番号を供給し、かつ、それを、恒久口座番号に関連させるシステムに向けられる。取引番号は、一見真のクレジットカード番号のようであり、顧客は、この取引番号を使い、それを、商人にたいして、顧客の口座番号の代用として渡す。このようにすると、顧客は、公共ネットワークを上で彼または彼女の真のクレジットカード番号を伝送する必要がなくなる。
【０００５】
前記―８１０号特許では、商人が取引番号を発行施設に渡すと、次に同施設はこの取引番号をインデックスとして使用し、顧客の真の口座番号にアクセスし、承認作業を処理し、前記取引番号の下に、商人に承認応答を返送する。その結果、顧客はただ取引番号を伝送するだけだからというばかりでなく、その代理番号は単一の買い物にたいしてのみ有効であるために、リスクは意図的に極小にされる。窃盗は「ただ一回の盗みではあまり儲からない。なぜなら、それ（番号）は、他の買い物や取引にたいして繰り返し使用することができないからである」とある。第２カラム、６０−６１行。
【０００６】
従来のシステムにたいする改善には要求がある。特に、各取引において、恒久的口座番号の伝送に代わって、一意の、繰り返し生成される取引番号の創成・伝送の必要を回避する、インターネット上の確実な金銭取引の実行を可能とする方法およびシステムにたいしては要求がある。
【０００７】
２００１年３月１５日登録の、同時係属中の出願第０９／８０９，３６７号―引用することによって本申請書に含める―によれば、「偽似」口座番号が顧客に割り当てられ、かつ、これは暗号的にその消費者の支払い口座番号にリンクされる。支払い口座番号は、財政施設またはその他の機関によって発行される口座番号で、消費者は、それを用いて、品物および／またはサービスにたいする支払いを実行することが可能になるものである。例えば、支払い口座番号は、クレジットカードまたはデビットカードのような支払いカード、あるいは、消費者のコンピュータに保存される電子キャッシュアプリケーションのような支払いアプリケーションに付属する口座番号であってもよい。この偽似口座番号は、商人にとっては、実際の支払い口座番号のように見える。すなわち、この偽似口座番号は、正当な支払い口座番号と同じ長さを持ち、かつ、正当な特定番号（例えば、ＭａｓｔｅｒＣａｒｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｉｎｃｏｒｐｏｒａｔｅｄ（「マスターカード」）の場合には”５”）で始まる。この偽似口座番号は、顧客により、彼または彼女のオンライン金銭取引の全てにおいて本当の口座番号の代わりに使用される。
【０００８】
同時係属中の出願第０９／８０９，３６７号の発明によれば、偽似口座番号に基づく全ての取引は、好ましくは、各口座番号に一意な秘密キーを用いて、暗号的にその真実性が証明される。この認証は、公開キーペアにおける私的キーに基づくものであってもよいし（「公開キー認証」）、あるいは、私的キー以外の秘密キー（「秘密キー認証」）に基づくものであってもよい。従って、無資格者が何かの偽似口座番号を確認することがあったとしても、それらを用いて不正な取引をすることはできない
【０００９】
さらに、同時係属中の出願第０９／８３３，０４９号の発明によれば、支払いネットワークを用いて取引を実行する方法が供給される。この方法では、サービスプロバイダーに入手者コードが割り当てられる。さらに具体的に言うと、サービスプロバイダーは、第一支払い口座番号による取引承認を求める、第一承認請求を受け取り、ここに、
（ｉ）前記第一支払い口座番号は、サービスプロバイダーに関連するＢＩＮコードを持ち、かつ、前記第二番号の発行者と関連するＢＩＮコードを持つ、第二支払い口座番号と関連し、
（ｉｉ）第一承認請求は、入手者と関連する入手者コードを含み、および、
（ｉｉｉ）第一承認請求は、第一支払口座番号のＢＩＮコードに基づいて、サービスプロバイダーにたいして導通が可能である、ことを特徴とする。
【００１０】
この方法においてはさらに、サービスプロバイダーは、第一承認請求にたいし、第二支払い口座番号による取引の承認を求める第二承認請求を伝送することによって応答することを含み、ここに、第二承認請求は、サービスプロバイダーと関連する入手者コードを含み、かつ、発行者のＢＩＮコード（すなわち、第二支払い口座番号のＢＩＮコード）に基づいて、支払いネットワークを通じて、発行者にたいして導通が可能である。
【００１１】
さらに、第二承認請求にたいする応答は、発行者からサービスプロバイダーによって受容され、ここに、同応答は、サービスプロバイダーと関連する入手者コードを含み、そのコードに基づいて支払いネットワークを通じて導通が可能である。次に、第一承認請求にたいする応答は、第二承認請求にたいする応答に基づいて、サービスプロバイダーによって入手者に伝送され、かつ、第一承認請求にたいする応答は好ましくは、入手者と関連する入手者コードを含み、そのコードに基づいて支払いネットワークを介して導通が可能である。
【００１２】
同時係属中の出願第０９／８３３，０４９号の、別の好ましい実施態様では、第二支払い口座番号と関連する第一支払い講座番号を用いて、商人と取引を実行する方法が供給される。ここに、同法は、（ａ）１個以上の取引明細に基づくメッセージ認証コードを生成し；（ｂ）商人にたいして、少なくとも第一支払い口座番号とメッセージ認証コードを伝送し；（ｃ）商人の側から、第一支払い口座番号を用いて取引支払いにたいする承認を請求し、ここに、請求は、あたかもその支払いが、従来の磁気ストライプ支払いカードによる売り場端末で処理されるようにフォーマットされており、メッセージ認証コードは、従来の支払いカードの磁気ストライプに使用される型のトラックに含まれる、自由選択データフィールドに収められて伝送され；（ｄ）第一支払い口座番号に関する承認請求にたいして、関連する第二支払い口座番号を用いてその取引の支払いにたいする承認を請求することによって応答し、かつ、（ｅ）第二支払い口座番号とメッセージ認証コードにたいする承認請求にたいする応答に基づいて、第一支払い口座番号にたいする承認応答を受容するか、または、断るかすることを含む。
【００１３】
このシステムはさらに改善が可能であり、かつ、公共通信ライン上で行われる金銭取引の際に、または、それと関連して伝達されるメッセージや情報を保護するためにさらに安全性・効率を強化することも可能である。
【００１４】
（発明の概要）
従って、本発明によれば、公共通信ネットワーク上にて、偽似期限切れ日付を使って口座番号による電子取引を実行する方法が供給される。好ましい方法は、
口座番号と関連するＰｅｒ−Ｃａｒｄ Ｋｅｙを生成すること；
Ｐｅｒ−Ｃａｒｄ Ｋｅｙを用いてメッセージ認証コードを生成すること；
メッセージ認証コードを偽似期限切れ日付に変換すること；
取引にたいする承認請求を生成することであって、ここに、前記請求は偽似期限切れ日付を含む期限切れ日付フィールドを持ち；および、
前記期限切れ日付に基づいてメッセージ認証コードを検証すること、を含む。
【００１５】
この好ましい方法はさらに、真実の期限切れ日付を有する口座番号の発行者を含む支払いネットワークを含み、ここに、前記真実の期限切れ日付を含む第二承認請求が生成され、かつ、前記第二請求は、取引の承認を求めて発行者に進められることを特徴とする。
【００１６】
本発明の、一つのさらに詳細な実施態様は、関連偽似口座番号を持つ、支払い口座番号を含み、かつ、下記の行程を含む。すなわち、
（ａ）支払い口座番号と偽似口座番号とを用いて、偽似口座番号と関連するＰｅｒ−Ｃａｒｄ Ｋｅｙをサービスプロバイダーが生成すること；
（ｂ）前記Ｐｅｒ−Ｃａｒｄ Ｋｅｙを含む、取引に使用される安全支払いアプリケーションを創成すること；
（ｃ）Ｐｅｒ−Ｃａｒｄ Ｋｅｙを用いてメッセージ認証コード（”ＭＡＣ”）を生成すること；
（ｄ）偽似口座番号とＭＡＣを含む安全支払いアプリケーションによってＭＡＣ検証要求を生成すること；
（ｅ）ＭＡＣの検証をすること；
（ｆ）前記検証に基づいて、ＭＡＣにたいして、予想取引順序番号（ＥＴＳＮ）を創成すること；
（ｇ）参照データ付き安全支払いアプリケーションを供給すること；
（ｈ）前記予想取引順序番号とＰｅｒ−Ｃａｒｄ Ｋｅｙを用いて、第二メッセージ認証コードを創成すること；
（ｉ）第二メッセージ認証コードを、参照データを用いて、偽似期限切れ日付に変換すること；
（ｊ）前記偽似期限切れ日付を含む期限切れ日付フィールドを持つ承認請求を生成すること；および、
（ｋ）前記承認請求に応答し、かつ、偽似期限切れ日付に基づいて第二メッセージ認証コードを検証すること、である。
【００１７】
本発明の別の実施態様によれば、公共通信ネットワーク上で電子取引を実行する方法であって、支払い口座番号が関連偽似口座番号を持つことを特徴とする方法が供給され、前記方法は、下記を含む。すなわち、
（ａ）認証キー生成のために使用される、単数または複数のキー生成行程を示すコントロールフィールドを持つ偽似口座番号を供給すること；
（ｂ）前記偽似口座番号のコントロールフィールドに示される、複数のキー生成行程の内の一つを用いて、前記偽似口座番号と関連する認証キーを生成すること；
（ｃ）前記認証キーを用いて、取引にたいして特異的なメッセージ認証コードを生成すること；
（ｄ）メッセージ認証コードと偽似口座番号とを含む承認請求メッセージを生成すること；および、
（ｅ）前記示されたキー生成行程と認証キーとを用いて、メッセージ認証コードを検証すること、である。
【００１８】
本発明のさらにもう一つの実施態様によれば、口座番号によって通信ネットワーク上で電子取引を実行する方法であって、
口座番号と関連するＰｅｒ−Ｃａｒｄ Ｋｅｙを生成すること；
前記Ｐｅｒ−Ｃａｒｄ Ｋｅｙを用いてメッセージ認証コードを生成すること；
前記メッセージ認証コードを、異なるフィールドを持つ承認請求によって、異なるやり方で進めるために、少なくとも二つの異なる動作モード供給すること、を含み、ここに、動作モードの少なくとも一つは、メッセージ認証コードを、期限切れ日付フィールドに進めるものであり、かつ、動作モードの少なくとも一つは、メッセージ認証コードを、メッセージ認証コードフィールドに進めるものである。好ましくは、前記メッセージ認証コードは、メッセージ認証コードフィールドが存在する場合には、自動的にそのメッセージ認証コードフィールドに輸送される。
【００１９】
（発明の詳細な説明）
本発明は、インターネットのようなコンピュータネットワーク上において、確実な支払いを実行するための方法およびシステムに向けられる。本発明は、同時係属中の出願連番第０９／８０９，３６７号に開示される「真実」口座番号（すなわち、発行施設によって発行される、実際のカード支払い口座番号）の代わりに、「偽似」口座番号を利用する。
【００２０】
本発明はその利点として、インターネットにおける支払い口座番号の使用について強化された安全性を供給する。本発明によれば、偽似口座番号が盗まれても、それら盗まれた偽似口座番号は、多くの状況下において、インターネット上で不正取り引きを実行するのに使用することはできない。なぜなら、偽似口座番号に基づく取引は、各口座番号について一意な秘密キーを用いて暗号的に認証がされるからである。この秘密キーは、ただ、カード保持者の安全支払いアプリケーション（”ＳＰＡ”）内部、および、サービスプロバイダー施設の、本申請書を通じてただ例示のために取り上げるのであるが、ＭａｓｔｅｒＣａｒｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｉｎｃｏｒｐｏｒａｔｅｄ（「マスターカード」）施設の高度に安全な装置の内部のみにあるからである。さらに、偽似口座番号は、カード保持者の真実の口座番号を開示しないので、通常の売り場端末では拒否される可能性が高い。
【００２１】
本発明の例示の実施態様を示す、いくつかの図面が付属する。この付属の図面と下記の説明において、マスターカードが、偽似口座番号を供給し、処理する実体を示すために使用される。本申請書に使用される、関連略号は下記の通りである。
ＢＩＮ―銀行特定番号
ＤＥＡ―データ暗号化アルゴリスム
ＰＣ―消費者のパソコン装置
ＭＡＣ―メッセージ認証コード
ＭＣＩ―マスターカードインターナショナルまたはマスターカード
ＭＣＷＳ―マスターカード・ウェブサイト
ＰＩＮ―個人特定番号
ＰＯＳ―売り場
ＳＰＡ―安全支払いアプリケーション
ＳＳＬ―安全ソケット層（インターネット安全用）
ＴＳＮ―取引連続番号
【００２２】
本発明の好ましい実施態様によれば、サービスプロバイダーは、本発明の技法に従って実行される安全支払いシステムの安全支払いアプリケーション（”ＳＰＡ”）を含む、いくつかの成分を発行し、維持し、および／または、処理する。
【００２３】
ＳＰＡシステムの成分
好ましくは、ＳＰＡシステムは、既存の支払い処理操作（例えばマスターカード）にたいして透明であり、かつ、既存の商人、入手者および発行者の各操作にたいして透明であることが可能である。このシステムは好ましくは、３種のスタンドアローン型成分を利用する。
１．１個以上のＳＰＡウェブサイト
２．カード保持者のＰＣ（またはその他のインターネットアクセス装置）用ＳＰＡウォーレット
３．ＳＰＡ承認／解除システム
【００２４】
簡単に言うと、ＳＰＡウェブサイトは、新規カード保持者を「登録する」のに用いられ、さらに、モード１（下記に定義される）において、適当なＳＰＡ承認／解除システムにたいして、承認請求メッセージを処理する前にそれが受領していなければならないデータを供給するのにも用いられる。
【００２５】
ＳＰＡウォーレットは、ＳＰＡ取引で使用するために、ＰＣ（またはそれと類似のもの）にダウンロードされるソフトウェアである。これは、カード保持者がアイコン上をクリックすることによって起動される。一旦起動されると、これは、ソフトウェアと、ある任意のカードに特注されたデータとの結合体を用いて、安全にインターネット支払いを実行する。
【００２６】
ＳＰＡ承認／解除システムは、ＳＰＡ取引を処理し、それを従来の取引に変換する（かつ、ある場合には従来取引から変換する）、物理的コンピュータ装置であり、このような一つの装置が一人以上の発行者のサービスに与る。
【００２７】
ＳＰＡウェブサイトおよび／またはＳＰＡ承認解除システムはまた本申請書ではサービスプロバイダーと呼ばれ、および／または、一人以上のサービスプロバイダーと関連する。
【００２８】
ＳＰＡモード
４種のＳＰＡ操作モードが本システムによってサポートされる。そのモードとは、
モード０：認証なし
モード１：期限切れ日付フィールドによる認証
モード２および３：ＳＰＡ専用の新規フィールドによる認証
【００２９】
モード０および１の利点としては、既存の商人または入手者操作にたいして変更を要求しない。モード２および３は、商人が、その支払い画面に新規フィールドを加え（好ましくは、カード保持者にたいしては表示されない秘密のフィールドで、カード保持者ＰＣのＳＰＡソフトウェアには見分けが可能なフィールド）、かつ、このフィールドがＰＣによって満たされた場合、商人はこのフィールド（未変更）を入手者に渡し、今度は入手者が、それを（未変更）承認を求めて支払いシステムに渡すことを要求する。これは、他のシステムでは、ＩＣＣ関連データを輸送するのに用いられるのと同じフィールドである。
【００３０】
モード２はまた、商人がカード保持者との１回の取引の結果として第二承認請求を一度でも送っている場合には、この第二の（およびその後の）承認請求メッセージは、期限切れ日付フィールドを持たないことを要求する。このような、それ以後の承認請求メッセージは、メール注文・電話注文として考慮されて、保証はされない。
【００３１】
モード３は、モード３が、商人は、期限切れ日付を持つ、その後の承認請求メッセージを送ってはならないという上記要求を課さないという点を除いては、モード２と同じである。モード３では、このようなその後の承認請求メッセージが期限切れ日付を持っているか、いないかは関係がない。
【００３２】
モード２は、モード３が行わない制限を課するのであるから、モード２用「秘密フィールド」の特定子は、（１）ＳＰＡ ＭＡＣフィールドとして使用可能な秘密フィールドが存在すること、および、（２）商人は決して期限切れ日付付き、後続承認請求メッセージを送ってはいないこと、という事実を搬送しなければならない。モード３で使用可能な「秘密フィールド」はこの第二の制限を持たないがために、別の特定子を持つ。
【００３３】
モード３に好適なフィールドは、電子商取引用（例えば、電子商売で使用されるＩＣＣ用）の全ての支払いシステムによって受容される「汎用」フィールドであってもよい。一方、モード２はこのような「汎用」フィールドを使用することはできない。なぜなら、このモードは、商人が後続承認請求メッセージには決して期限切れ期日を含めないということを「保証」した場合にのみ使用されるからである。従って、モード２は、ＳＰＡ取引を受容するに当って特別な準備を行った商人についてのみ使用が可能であるのにたいし、モード３では、全ての支払いシステムによって使用が可能となるよう、電子商取引に追加フィールドを備える商人であればいずれの商人においても使用が可能である。
【００３４】
モード２または３は、モード０または１に比べて、前者がより効果的な認証を与えるという点で好ましい。ＳＰＡは好ましくは、商人の支払い画面中に示される「秘密フィールド」の存在によって、商人がモード２または３をサポートする意図を見て取った場合を除いては、モード０または１で作動する。カード保持者のＰＣ中のＳＰＡは、モード２または３においては常に、商人がこのモードをサポートする場合に作動する。
【００３５】
好ましくは、カード保持者のＰＣは、三つの状態、「状態Ａ」、「状態Ｂ」または「状態Ｃ」の内の一つにおいて作動する。「状態Ａ」では、ＰＣはモード１か２で作動するが（商人の能力に依存して）、モード０またはモード３では決して作動しない。「状態Ｂ」では、ＰＣは、モード１、モード２、または、モード３で作動するが（この場合も商人の能力に依存して）、モード０で作動することは決してない。「状態Ｃ」では、ＰＣはモード０、モード２またはモード３（商人の能力に依存して）で作動するが、モード１で作動することは決してない。ＰＣは、ＳＰＡウェブサイトからの指令の下に、好ましくはこれらの状態間で切り換えが可能である。
【００３６】
「状態Ａ」は、全ての取引がある程度の真実証明を持つという利点を有する。「状態Ｂ」は、モード１の提供する真実証明をある程度低下させるが、「汎用」追加フィールドを受容する全ての商人との取引について、実質的により高度の真実証明が得られるという利点を有する。「状態Ｃ」は、大手の多くの商人が「汎用」追加フィールドを備えた場合の将来の使用を意図したもので、ＳＰＡ承認システムに課される保存要求を相当に下げるが、この「汎用」追加フィールドを準備しない商人にたいしては真実証明なしというコストを伴う。従って、次第に多くの商人が「汎用」追加フィールドの受容を可能とはするが、ＳＰＡ独特のモード２追加フイールドを受容できない場合、発行者は、そのＳＰＡウォーレット用として、「状態Ａ」から「状態Ｂ」へ、さらに最終的に「状態Ｃ」への移行を実行する。一つの状態から別の状態への移行は好ましくは発行者の選択であり、従って、異なる発行者からのウォーレットは、異なる状態にあることが可能である。
【００３７】
ＳＰＡ特徴
前述のように、ＳＰＡは、カード保持者のカード上に見える「真実」口座番号ではなく、偽似口座番号の使用に基づく。偽似口座番号と、対応する「真実」口座番号との間には１対１対応がある。全てのモードにおいてＳＰＡによって同じ偽似番号が用いられる。偽似口座番号のＢＩＮは、どのＭａｓｔｅｒＣａｒｄカードにも刻印されていない「偽似ＢＩＮ」である。カード発行者当り一つの偽似ＢＩＮがあるので、ある偽似口座番号の発行者は特定が可能である。偽似ＢＩＮの使用は、ある任意の取引の口座番号を、一つの偽似口座番号として特定する。商人や入手者は全て、カード保持者を、偽似口座番号によって知っているが、発行者は、カード保持者を「真実の」口座番号によって知っている。従って、ＳＰＡシステムの機能の一つは、同時係属中の出願書にも記述される通り、二つの数字の間を「移動する」ことである。
【００３８】
本発明によれば、ＳＰＡシステムのもう一つの機能は、ＳＰＡモード１、モード２、または、モード３承認請求のそれぞれに随伴する、メッセージ認証コード（”ＭＡＣ”）を検証することである。モード１の場合、本発明では、ＭＡＣは、偽似期限切れ日付の形を取り、真実証明される日付は、好ましくは、各モード１取引毎に、ＳＰＡウェブサイトを介して搬送される。モード２または３の場合は、ＭＡＣは、「ＭＡＣフィールド」、すなわち、全てのモード２／３取引にたいして添加される、新規ＳＰＡフィールドの一部となる。真実証明される日付も、このＭＡＣフィールドに含まれる。
【００３９】
同じＳＰＡが、異なるＰＣ上においてコピーを持つことができる。どのＰＣでも、いくつかの異なるカードにたいしてＳＰＡウォーレットを持つことが可能である。その場合、そのウォーレットは、異なるカード保持者による制御・使用が可能である。
【００４０】
ＳＰＡウェブサイト操作―カード登録
ＰＣにおいてカード保持者が、ＳＰＡにたいしてある任意のカードを登録したいと思う場合には、彼／彼女は、ＰＣブラウザーを用いてＳＰＡウェブサイトに接触する。（ＰＣではないウェブアクセス・デバイスも、本申請書に記載されるのと同じやり方で作動する。）ＰＣとＳＰＡウェブサイト間で伝達される全てのデータについてＳＳＬ暗号化が使用される。ウェブサイトは、自分が、既にロードされたＳＰＡアプリケーションではなく、ブラウザーによってアクセスされたことを感じ取ると、好ましくは下記のように作動する。
【００４１】
ウェブサイトは、ＰＣにたいして初発画面を送る。この画面は、「真実」口座番号か、または、そのカード保持者が既にそのカードを何かの（他の）ＰＣに登録しているのであれば、偽似口座番号のいずれかを尋ねる。ＳＰＡウェブサイトがその情報を一旦受容すると、そのＢＩＮを調べる。ウェブサイトは、発行された全ての偽似ＢＩＮのリストを保持しているので、先ず、その与えられた口座番号のＢＩＮが、そのリストに載っているかどうかを確定する。載っている場合には、それは偽似口座番号であるし、そうでなければ、「真実」口座番号である。
【００４２】
ＢＩＮが「真実の」ＢＩＮを表わしている場合、ＳＰＡウェブサイトは、発行者がＳＰＡに参加しているかどうかを確定する。ウェブサイトは、この作業を、「真実」ＢＩＮを偽似ＢＩＮに関連づける第二テーブルを保持することによって行い、かつ、このテーブル中に、問題の「真実」ＢＩＮに対応する記載を見出したならば、この発行者がＳＰＡに参加していることを承知する。この二つの状況の内のいずれにおいても、ＳＰＡウェブサイトは、ＳＰＡウォーレットをこのカードにたいして支給が可能であることを承知する。発行者がＳＰＡに参加していない場合は、ＳＰＡウェブサイトは好ましくは、メッセージをカード保持者に送り、彼／彼女に、今回はＳＰＡウォーレットは利用できない旨の通知をする。
【００４３】
ＳＰＡウェブサイトが、カード発行者がＳＰＡをサポートしていることを確定した場合、ＳＰＡウェブサイトは第二画面を送る。この画面は好ましくは下記を請求する。
１．カード期限切れ日付
２．カード保持者名、住所および電話番号
３．カード保持者が、その所有／コントロールするＰＣの前にいるかどうか
４．偽似口座番号ではなく、「真実」口座番号が、第一行程で供給された場合、そのカード保持者が以前にＳＰＡ用にそのカードを登録したかどうか、
５．カードが以前にＳＰＡにたいして登録されたことがある場合（前項にたいして「イエス」によって、または、偽似口座番号の使用によって、示された場合）、カード保持者が、その登録時に選択されたパスワードを記憶しているかどうか、
６．カードが以前にＳＰＡにたいして登録されたことがあり、かつ、カード保持者がそのパスワードを覚えている場合（カード保持者が、質問第４を尋ねられ、「イエス」と返答した場合）、その既に選択されたパスワード。
【００４４】
質問第５は、カード保持者が第一画面に偽似口座番号を入力した場合は必ず含まれるが、質問第４は尋ねられない。その他の場合は質問第４は尋ねられ、その質問に対してカード保持者が「イエス」と返答した場合は、質問第５が加えられる。質問第５が尋ねられ、「イエス」と返答された場合は、項目第６が加えられる。
【００４５】
これがこの口座番号にとって最初の登録である場合、または、カード保持者が、前の登録時のパスワードを覚えていない場合には、ＳＰＡウェブサイトは、発行者一意の真実証明用質問を搭載する第三画面をＰＣに送り、下記のような情報を請求する。（１）カード保持者がメールで受け取った「ＳＰＡ登録コード」、（２）カードの背に印刷されるＣＶＣ２、（３）カード保持者の社会保険番号（または、その数字の一部）、（４）カード保持者の母親の結婚前の姓名。この第三画面の内容は、好ましくは、発行者によって確定され、この発行者が選択した真実証明情報にたいする請求を呈示する。この第三画面はまた、カード保持者がパスワードを入力しなければならない場所を供給する。これは、カード保持者が将来、ＳＰＡを活性化する際に、または将来、現在請求中のＳＰＡウォーレットの発行が、カード発行者によって承認されると仮定して、別のＰＣ用にＳＰＡのコピーを請求する際に使用しなければならないからである。注意しなければならないことは、この口座番号に関してＳＰＡが既に存在する場合には、新規のＳＰＡコピーを始めるためには、このパスワードが、以前のパスワードに取って代わらなければならないことである。さらに注意すべきことは、例えば、夫婦が同じ口座番号を共同使用する場合には、その夫婦は同じ偽似口座番号を共有し、従って、別のＰＣに新規ＳＰＡコピーを起動するためには同じパスワードを使用しなければならないことである。（しかしながら、夫／妻がこのパスワードを知らない場合には、真実証明質問に回答することによって、別のＰＣに新規ＳＰＡコピーを起動してもよい。）
【００４６】
カード保持者からこの情報を受け取ると、ＳＰＡウェブサイトは、呈示された口座番号のＢＩＮから、この偽似ＢＩＮにたいする承認請求を処理するＳＰＡ承認システムのアドレスを確定する。これを実行するために、ＳＰＡウェブサイトは、偽似ＢＩＮによってアクセスされるアドレス表を保持し、対応するＳＰＡ承認システムのアドレス（単数または複数）を供給する。この決定を行ってから、ＳＰＡウェブサイトは、カード保持者から入手した情報を、安全手段（例えば、ＳＳＬ暗号化の下に）によって、このＳＰＡ承認システムに伝送する。ウェブサイトはこのデータのコピーを保持する必要はない。なぜなら、データは、ＳＰＡ承認システムからウェブサイトに戻されるからである。
【００４７】
ＳＰＡウェブサイトとＳＰＡ承認システムとの間の通信方法は好ましくは、ダイアルアップテレフォン背景の下に、インターネットを介するものである。この場合、アドレス表によって供給されるアドレスは、ＳＰＡ承認システムのインターネットアドレス、およびまたその電話番号である。別の可能性は、マスターカード・バンクネットのような支払いネットワークを介するもので、この場合は、「アドレス」は単に偽似ＢＩＮそのものである。
【００４８】
一旦ＳＰＡ承認システムが登録要求を受容すると、それが、示されたＢＩＮにとって適正な施設であることを確認する。そうでない場合は、その登録請求を拒絶し、そのようにＳＰＡウェブサイトに通知する。ウェブサイトがその応答を受け取ると、ウェブサイト・オペレーターにメッセージを送り、カード保持者のＰＣに「お待ち下さい」のメッセージを送る。オペレータが、問題を速やかに（例えば５分）解決できない場合には、ＳＰＡウェブサイトは、ＰＣにたいして、只今このカードにたいしてＳＰＡウォーレットを供給することができない旨通知する。
【００４９】
ＳＰＡ承認システムが成功裡に登録を完了した場合には、安全手段によって、好ましくは下記から成るメッセージをＳＰＡウェブサイトに送る。すなわち、
１．カード保持者の名前、住所および電話番号
２．偽似口座番号
３．カード期限切れ日
４．「真実」口座番号の下４桁数字
５．非可逆的に変形されたパスワード
６．カードキー用暗号化パスワード
７．ＳＰＡコピー数または単一セッション数
８．ＳＰＡバージョン数
９．ＳＰＡ単一セッションインディケーター
１０．ＳＰＡ状態
１１．偽似ＢＩＮキーインディケーター
１２．カード製品名（例えば、「マスターカード」、「マエストロ」、「マスターカード・キャッシュ」
１３．「真実」口座番号
１４．第１回ＳＰＡフラグ（１＝たった今確定されたばかりの新規偽似口座番号）
【００５０】
ＳＰＡ承認システムはさらに、回答をカード保持者ＰＣに経路導通させるために、ＳＰＡウェブサイトが要求する情報はそれが何であれ全て戻す。
【００５１】
このメッセージを受け取ると、ＳＰＡウェブサイトは、そのＳＰＡバージョン数に相当するソフトウェアと共に、上記の項目１から１２までをＳＰＡウォーレットに収める。このウォーレットにはさらに、モード１およびモード２／３取引連続番号、および、パスワード失敗カウンター用にゼロの初期値が含まれる。次に、ＳＰＡウェブサイトは、このＳＰＡデータをカード保持者ＰＣに伝送し、ＰＣにデータは保存される。
【００５２】
ＳＰＡは、ＳＰＡを搭載したそのＰＣにて使用が可能なカードのメニューを供給する。ＳＰＡは好ましくは、ＰＣ画面の一列において、各カードに関して下記の情報を供給する。
１．カードの偽似口座番号
２．ＳＰＡコピー数（これが単一セッションＳＰＡでない場合）
３．カードの「真実」口座番号の下４桁数字
４．カードの期限切れ日付
５．カード保持者の名前
６．カード製品名（例えば、「マスターカード」、「マエストロ」、「マスターカード・キャッシュ」
【００５３】
新規ＳＰＡウォーレットがＰＣのＳＰＡに加えられる度毎に、その新規のカードがこのメニューリストに加えられなければならない。カードは、ＳＰＡにたいして登録された順番に、第一登録が第一順位として、列挙される。このリストは、カード保持者によって、現在取引用のカードを選択するのに使用される。前述したように、各カードには、ある特定のソフトウェアセットが関連する（ただし、同じバージョン数を持つ２枚のカードは、同一ソフトウェアを使用する）。注意すべきことは、多くの場合、別のＳＰＡがこのＰＣにインストールされることは決してなく、従って、このリストには単一のカードしかないことである。
【００５４】
これでカード保持者はＳＰＡ取引を実行できることになる。
【００５５】
ＳＰＡ承認／解除システム
上に簡単に述べたように、ＳＰＡに参加するカード発行者は全て、１個の「一次」ＳＰＡ承認／解除システムによるサービスを受ける。この場合、要すれば、このシステムは、複数の発行者にサービスを提供することが可能である。フル稼働のＳＰＡシステムの場合、少なくとも１個の「バックアップ」ＳＰＡ承認／解除システムがあって、このシステムが、一次システムが利用できない場合（例えば、故障）はいつでも使用されるようになっていてもよい。「バックアップ」ＳＰＡ承認／解除システムを使用すると、ＳＰＡ取引は完了されるが、（一過性に）安全性の質が低下する。
【００５６】
複数の発行者にサービスを提供するＳＰＡ承認／解除システムはそれぞれ好ましくは、１個以上の専用サーバーを介してＭａｓｔｅｒＣａｒｄ’ｓ Ｂａｎｋｎｅｔのような支払いシステムに接続される。このシステムは、Ｂａｎｋｎｅｔを通じて承認請求メッセージや解除メッセージを受容し、また、Ｂａｎｋｎｅｔを通じて発行者と接触する。このようなシステムが好ましくは、そのサポートする発行者にたいして完全に透明なやり方で作動する。
【００５７】
ＳＰＡ承認／解除システムの、単一発行者バージョンも利用が可能である。そのようなバージョンは、直接、発行者の処理システムに接触する。このバージョンは、発行者の側に若干のプログラム再修正を要求する。その修正プログラムは、ＳＰＡ取引をその偽似ＢＩＮ（単数または複数）によって認識し、かつ、それらの取引をＳＰＡ承認／解除システム（例えば、サービスプロバイダー）に通じて、それによって、偽似口座番号から「真実」口座番号への変換、および、ＭＡＣ真実証明（承認請求メッセージのみ）を実行させるようになっていなければならない。
【００５８】
単一発行者ＳＰＡ承認／解除システムのもう一つのバージョンは、発行者のＭＩＰとユーザーの処理装置の間にインストールされてもよい。このシステムは、発行者にたいして透明であることは可能であるが、ＭＩＰに出入りする全てのトラフィックは、このＳＰＡシステムを通過しなければならない。
【００５９】
最後に、ある発行者にたいする承認機能と解除機能は、同じ物理的なボックスによって実行される必要はない。発行者は、その承認請求メッセージを、その発行者にたいしＢａｎｋｎｅｔを介して接触するＳＰＡ承認システムに処理させ、一方、その解除メッセージの方は、会員の処理システムに直接接続する、単一発行者ＳＰＡ解除システムによって処理させてもよい。
【００６０】
最初は、比較的小数のＳＰＡ承認／解除システムしか無いかも知れない。次第にたくさんの発行者が、または、発行者グループが、自分達のＳＰＡ承認／解除システムを持つことを選択するにつれて、元のシステム（たくさんの発行者にサービスを提供する）から適当なデータを、新規のシステム（一人だけの、または、少なくとも元のよりは数少ない発行者にサービスを提供している）へ転送する備えを用意しなければならない。偽似口座番号はそれがいずれのものであれ、好ましくは、ただ一つのＳＰＡ承認システムからのサービスだけを受ける。従って、この転送は、転送の時点で進行中のいずれの取引にたいしても、それにたいする障害を最小としながら実行可能となっていなければならない。
【００６１】
偽似口座番号
一つの「真実」支払い口座番号にたいして、それと関連する偽似口座番号は、好ましくは長さが１６桁数字である。この１６桁偽似口座番号は、この口座番号専用の、６桁ＢＩＮから始まる。ＢＩＮは、任意の銀行、または、サービスプロバイダー連合の任意の会員にたいして一意であってもよく、また、会員内部の、任意の製品（例えば、ゴールドカードや、組合カード等）にたいして一意であってもよい。
【００６２】
ＢＩＮの直後の２個の数字（または要すれば１個の数字）は、「コントロールフィールド」として予約されていてもよい。このフィールドは、この偽似口座番号と共に使用されるアルゴリスム等を示すものである。
【００６３】
チェック桁は偽似口座番号に適正であるから、これにより、約７桁、または要すれば８桁が残されることとなり、従って、各ＢＩＮは、各コントロールフィールド値について、最大１千万（または１億）の口座番号を表わすことが可能になる。
【００６４】
この偽似口座番号構造により、発行者をＢＩＮによって一意に特定することが可能となるから、発行者は、（１）「手前共の」取引を特定し、かつ、（２）自分と双方向合意のある他の発行者を特定することが可能となる。後述するように、プログラム修正や、適当な安全モヂュールを入手することに積極的な発行者は、自分達自身の真実証明を実行することが可能となるから、「手前共の」取引も、ある種の他施設の取引も一緒に、その施設自身で実行することが可能になる。このため、その取引をサービスプロバイダー（またはマスターカードＳＰＡ施設）に送る必要が無くなる。
【００６５】
好ましくは、偽似口座番号のチェック数字を除く右側７（または８）桁数字は、左側６桁数字によって特定される施設内部の、特定の口座を特定する示数である。最初は（コントロールフィールド値によってそう指示されるなら）、この示数は、全施設に共通であってもよい。ＢＩＮ当り、多数の７桁数字（または８桁数字）組の示数値が、コントロールフィールドにおいて異なる数字を用いることにより利用可能になる。これらの口座番号示数値は好ましくは、サービスプロバイダー、この場合は、ＭａｓｔｅｒＣａｒｄによって割り当てられる。その数値は、順番に（各施設毎に）または、ランダムに割り当てられてもよい。別法として、順番に割り当て、次に暗号化して（ランダム性を持つ７または８桁十進数字にする）、偽似口座番号として含めてもよい。
【００６６】
口座番号示数値をランダムに割り当てる、または、それら順番に割り当ててから、暗号化して偽似口座番号に含めることの利点は、敵（例えば、不正行為をたくらむ人々）が、正当な偽似口座番号を「推量」するのをより困難にすることである。もしも口座番号示数を順番に割り当てられたとすると、敵にとって、使用可能な偽似口座番号を、すなわち、自らに割り当てられた偽似口座番号よりも少ない偽似口座番号を、または、少し大きいものを「推量」することがごく簡単になるからである。ある施設にとって可能な数値の内比較的少数（例えば＜１０％）しか割り当てられていない時期に、ランダムに割り当てられた、または、暗号化された口座番号示数を用いることによって、敵が、正当な口座番号示数値を「推量」することのできるチャンスは、僅かに１０の内約１に過ぎなくなる。これは、敵が、不正に使用することを可能にする偽似口座番号を発見することをより難しくする。
【００６７】
発行者が、偽似口座番号付き取引について自身の処理を実行したいと思う場合には、サービスプロバイダーにより、数字順に配した全ての偽似口座番号で、各「真実」口座番号に対応するもののリストを与えられてもよい。この偽似口座番号が実際の示数を含む場合には、サービスプロバイダーは、発行者に、表示順に配した「真実」口座番号のみを与える必要がある。偽似口座番号が暗号化口座番号示数値を含む場合には、サービスプロバイダーは要すれば、発行者に（発行者に一意な）複合化キーを与え、次に、「真実」口座番号を表示順に与えることも可能である。恐らく、サービスプロバイダーは発行者に、逆行テーブル（発行者が、偽似から「真実」への口座番号翻訳を実行する各取引毎に、偽似口座番号を保存する際に要するものと同様の）を与える必要はない。しかしながら、発行者に逆行テーブルを与える必要のある場合には、そのテーブルは、発行された偽似口座番号にたいする各「真実」口座番号と、それに続けて対応偽似口座番号を数値順にリストすることになる。
【００６８】
いずれにしろ、サービスプロバイダー施設は、偽似口座番号を「真実」口座番号へ変換し、かつ、「真実」口座番号を偽似口座番号へ変換する能力を付与するテーブルを維持する。
【００６９】
カードの認証キーの演算
カードに一意な認証キーは、偽似口座番号と、対応する「真実」口座番号の暗号化処理に基く。そこにおいて中間ＢＩＮ一意のキーが生成される行程が望ましい。なぜなら、国立ＳＰＡ施設によって、また、自身ＳＰＡ取引の証明を実行したいと思っているカード発行者によって利用される場合に備えられるからである。このようにして、全国規模の施設でも、偽似口座番号ＢＩＮ当りただ一つのキーを与えられるだけでよく、自身認証を実行する発行者も、（例えば）一千万の偽似口座番号当り１個のキーを貰うだけですむ。仮に一つの国立ＳＰＡ施設のキーが危機に瀕したとしても、他の国々の安全が脅かされることはない。一つの発行者のキーが危機に頻したとしても、他の発行者の安全は脅かされない。
【００７０】
任意の偽似口座番号と共に使用されるキー生成行程は、その偽似口座番号のコントロールフィールドによって示されてもよい。前記目的を実行するために可能なキー生成行程は下記のようなものである。すなわち、中央ＳＰＡ施設のみが、「認証キー誘導キー」と呼ばれる、極秘の３倍長ＤＥＡキーを保持する。ある任意の偽似口座番号にたいするＰｅｒ−Ｃａｒｄ Ｋｅｙを創成するために、この中央ＳＰＡ施設（例えば、マスターカードＳＰＡ施設）の安全モヂュールによって実行される好ましい行程は下記の通りである。
１．６４ビットフィールドにおいて、各４ビットの、６個の二進コード十進数字と考えられる偽似口座（ＢＩＮ）の内、左側６桁数字を左に揃え、かつ、右側にゼロを並べよ。２４バイトの認証キー誘導キーの左側８バイトを暗号化キーとして用いて、これら６４ビットをＤＥＡ暗号化せよ。
２．前記２４バイト認証キー誘導キーの中央８バイトを復号化キーとして用いて、行程１の結果をＤＥＡ復号化せよ。
３．前記２４バイト認証キー誘導キーの右側８バイトを暗号化キーとして用いて、行程２の結果をＤＥＡ暗号化せよ。
４．行程３の結果を、一意な１６バイト対ＢＩＮキーの左側８バイトとして使用せよ。
５．６４ビットフィールドにおいて、各４ビットの、６個の二進コード十進数字と考えられる偽似口座番号（ＢＩＮ）の内、左側６桁数字を左に揃え、かつ、右側に二進の１を並べよ。２４バイトの認証キー誘導キーの左側８バイトを暗号化キーとして用いて、これら６４ビットをＤＥＡ暗号化せよ。
６．前記２４バイト認証キー誘導キーの中央８バイトを復号化キーとして用いて、行程５の結果をＤＥＡ復号化せよ。
７．前記２４バイト認証キー誘導キーの右側８バイトを暗号化キーとして用いて、行程２の結果をＤＥＡ暗号化せよ。
８．行程７の結果を、一意な１６バイト対ＢＩＮキーの右側８バイトとして使用せよ。
９．１６桁「真実」（偽似ではない）口座番号（二進コードの十進数字で、右揃えされ、かつ、１６桁よりも少ない場合には左に二進のゼロを並べたものと考えられる）を、ＤＥＡ暗号化キーとして行程４の結果（対ＢＩＮキーの左側８バイト）を用いて暗号化せよ。
１０．行程８の結果（対ＢＩＮキーの右側８バイト）をキーとして用いて行程９の結果を復号化せよ。
１１．行程４の結果（対ＢＩＮキーの左側８バイト）をＤＥＡキーとして用いて行程１０の結果を暗号化せよ。
１２．行程１１の結果をＰｅｒ−Ｃａｒｄ Ｋｅｙの左側８バイトとして使用せよ。
１３．「真実」口座番号の右側１６桁（二進コードの十進数字で、右揃えされ、かつ、１６桁よりも少ない場合には左に二進のゼロを並べたものと考えられる）に二進パターン０１０１０１０．．．を並べ、次に、ＤＥＡキーとして行程４の結果（対ＢＩＮキーの左側８バイト）を用いて暗号化せよ。
１４．行程８の結果（対ＢＩＮキーの右側８バイト）をＤＥＡキーとして用いて行程１３の結果を復号化せよ。
１５．行程４の結果（対ＢＩＮキーの左側８バイト）をＤＥＡキーとして用いて行程１４の結果を暗号化せよ。
１６．行程１５の結果をＰｅｒ−Ｃａｒｄ Ｋｅｙの右側８バイトとして使用せよ。
【００７１】
中央ＳＰＡ施設が、あるカード保持者のＰＣ用にＳＰＡを創成する際、そのアプリケーションの中にＰｅｒ−Ｃａｒｄ Ｋｅｙ（行程１２と１６から）を、そのアプリケーションの通常操作時には開示されないやり方で含ませる。
【００７２】
メッセージ認証コード付き取引において偽似口座番号を受け取ると、ＳＰＡ施設はその「真実」口座番号を確定し、次に、ＭＡＣを検証するために必要なキーを創成するために、前記１６個の行程を実行する。
【００７３】
ＳＰＡ施設が、国立ＳＰＡ施設または発行者の安全モヂュールの中に保持されるべきキーを創成する必要のある場合には、その国にたいして一意な各ＢＩＮについて、または、その発行者のＢＩＮについて、前記行程１から８までを実行する。次に、これらのキーは、国立ＳＰＡ施設の、または、発行者の安全モヂュールに確実に配送され、こうしてその各キーは、それを創成するために使用された偽似口座番号ＢＩＮ（およびコントロールフィールド）に関連付けられる。次に、この安全モヂュールは、それが、偽似口座番号、「真実」口座番号、ＭＡＣ、および、指定コントロールフィールド付きで受け取った各取引毎に、先ず、偽似口座番号ＢＩＮによって指示されるキーを選択し、次にこのキーを対ＢＩＮキーとして用いて前記行程９から１６までを実行して、ＭＡＣを証明するためのキーを創成する。
【００７４】
ＳＰＡ起動
次に、図を参照しながら特異的ＳＰＡ起動を説明する。図１は先ず、金銭取引カードを所持するカード保持者が、本発明の実施態様に従って、インターネット上で、ＳＰＡウェブサイトまたはサービスプロバイダーから、安全支払いアプリケーションを入手する様子を描く。最初に、本発明の利点を利用・享受するためには、物理的カードは必要ではなく、ユーザーまたは参加者を特定し、彼／彼女を、金銭取引実行のために口座に結びつける口座番号のみが、保持者（この場合はカード保持者）にたいして発行されることを理解しなければならない。カード保持者は、コンピュータ、携帯電話または電子秘書（ＰＤＡ）のような、インターネット上で通信が可能な適当な装置を使って、サービスプロバイダーと関連するウェブサイトに接触してもよい。下記の議論では簡単のために、カード保持者は、インターネット上で通信するためにコンピュータを使用するものと仮定する。
【００７５】
図１に示す様に、サービスプロバイダー、例えばＭａｓｔｅｒＣａｒｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｉｎｃｏｒｐｏｒａｔｅｄ（すなわち、マスターカードの代理店）は、１個以上の物理的に安全なモヂュール１２を支配下に置いており、これらモヂュールは、モヂュール内に保存された情報にたいする物理的保護を提供する。これら安全モヂュールは各々１個以上の「誘導キー」を含むが、このキーは、後述するように、安全支払いアプリケーションの内部に供給される、口座一意的秘密暗号キー（Ｐｅｒ−Ｃａｒｄ Ｋｅｙ）を創成・再創成するのに使用される。
【００７６】
先ず、本発明の好ましい実施態様によれば、カード保持者は、サービスプロバイダーからＳＰＡを入手しなければならない。安全支払いアプリケーション（ＳＰＡ）をダウンロードして起動するための好ましい行程としては、
１．カード保持者は、インターネットを介してサービスプロバイダーのウェブサイトに接触する（直接に、または、別のウェブサイト、例えば、発行者のウェブサイトからハイパーリンクを通じてそのウェブサイトへ）。
２．カード保持者は、当事者には一般に既知のＳＳＬ暗号化の下に、（ａ）支払いカード口座番号、（ｂ）カード期限切れ日付、および、（ｃ）カード認証情報を供給する。カード認証情報は、例えば、前述したように、カードのＣＶＣ値、すなわち、ある種のカードの署名パネルの隣にプリントされる３から４個の数値を含んでいてもよい。この数値は、秘密の暗号化キーを用いて、発行銀行によって生成されるが、その同じキーを用いて検証することが可能である。
３．サービスプロバイダーは、カード口座番号とカード期限切れ日付の合法性を、カード保持者の支払いカードの発行者からゼロ額承認を入手することによって確認してもよい。例えば、マスターカードは、Ｂａｎｋｎｅｔ通信ネットワークを介してこのような承認を入手することが可能である。
４．サービスプロバイダーは、カード保持者の支払いカードの発行者が、そのサービスプロバイダーに、ＣＶＣ２数値を検証するための暗号キー（単数または複数）を支給してくれた場合、そのＣＶＣ２値を証明してもよい。
５．サービスプロバイダーは、他のカード証明情報を、その情報を、証明のために、発行者に送ることによって証明してもよい。このことをやり易くするために、サービスプロバイダーのウェブサイト、または、例えばＭＣＷＳは、ＳＰＡ用登録時に、消費者に尋ねる項目のリストを維持していてもよい。そのような項目のリストとしては、
項目番号 項目説明
０１ ＣＶＣ２
０２ ＰＩＮ
０３ 母親の結婚前の姓名
０４ この口座における最終請求額
０５ 請求書の宛名の市街名
０６ 社会保険番号の下４桁数字
【００７７】
発行者は、消費者が、発行者によって発行される口座番号を、サービスプロバイダーに登録する際に、サービスプロバイダーにどのデータを供給してもらいたいかを指定することが可能である。発行者は、あるＢＩＮ（製品）とは異なる別のＢＩＮを取り扱いたい場合には、ＢＩＮ毎に別々のデータ項目を指定してもよい。サービスプロバイダーのウェブサイトは質問を選び、消費者に返答を促す。結果は、ゼロ額承認請求の一部として発行者に供給される。
【００７８】
６．サービスプロバイダー（”ＳＰ”）は、カード保持者の供給したデータの合法性を確認した後、偽似口座番号と秘密キーとを創成または選択し、これらのデータ要素を、安全支払いソフトウェアアプリケーション中に組み込む。このアプリケーションは、インターネットにおいて、好ましくはＳＳＬ暗号化の下に、カード保持者により、彼／彼女のＰＣにダウンロード用に利用可能とされる。
【００７９】
偽似口座番号は、そのＢＩＮとして、偽似口座番号用に予約された、特別ＢＩＮを有する。偽似口座番号の残りは、サービスプロバイダーによって、テーブル参照行程を経て、「真実」口座番号および、それと関連する期限切れ日付に翻訳されることが可能な数値である。チェック数字は、偽似口座番号において適正である。
【００８０】
好ましくは、割り当てられる特別サービスプロバイダーＢＩＮは、たくさんのそのような特別ＢＩＮから成る一組から選ばれたものであってもよく、その組において、各ＢＩＮは、ある特定の銀行または特定の国または地域、あるいは、ある国または地域内部の特定の製品に対応するものであってもよい。
【００８１】
サービスプロバイーダーがＳＰＡに埋め込むことが好ましい、秘密のＰｅｒ−Ｃａｒｄ Ｋｅｙは、各カード口座番号にたいして一意であり、好ましくは、カード口座番号と誘導キーを用いて安全モヂュール内部で導出される。（この行程は下記でさらに詳述する）。導出キーそのものも、さらに高いレベルの導出キーを用いて、同じまたは別の安全モヂュールから導出されてもよい。
【００８２】
カード保持者は、安全支払いアプリケーションをダウンロードする前に、パスワードをサービスプロバイダーに供給してもよいし、あるいは、安全支払いアプリケーションがカード保持者のコンピュータにイントールされる際にパスワードを選んでもよい。パスワードが供給または選択されると、カード保持者は、彼または彼女のＰＣ上で安全支払いアプリケーションを起動するためには、そのパスワードを入力することを要求される。
【００８３】
当業者ならば認識されるように、サービスプロバイダーは定期的にＳＰＡを更新し、かつ、そのＳＰＡを、ディジタルウォーレット・アプリケーションの一部としてダウンロード可能としてもよい。ＳＰＡに加えて、ディジタルウォーレットも下記の内の１個以上を保存してもよい。すなわち、カード保持者の個人情報；パース（手持ち額）アプリケーション；デット（負債）アプリケーション；消費者対消費者アプリケーション；および、その他のアプリケーションであって、これらは全てＳＰＡの下に安全保証される。
【００８４】
ＳＰＡウォーレット操作―初回セッション起動
ＰＣ中のＳＰＡは、カード保持者が、彼／彼女のＰＣ画面上に表示されるＳＰＡアイコンをクリックすると起動される。始めて起動された場合（初回インストール後、または、前に閉じられて後）、ＳＰＡによって実行される最初の作業は、カード保持者にたいして、ＳＰＡカード（以前にそれにたいしてＳＰＡウォーレットが入手されているカード）の全リストを表示し、カード保持者に、当面の取引に彼／彼女が使いたいと思うカードの選択を促すことである。
【００８５】
複数のカード保持者が一つの共通のＰＣを共有してもよいことに注意しなければならない。このため、カード保持者名は、各ＳＰＡカードに関する表示情報の一部となり、また、各カードは、それ自身の、カード保持者選択のＳＰＡパスワードを有する。
【００８６】
カード保持者が、この共通リストから一枚のカードを選択したならば、ＳＰＡは、好ましくは、このカードに関するパスワード失敗カウンターを検査する。このカウンターが、ＳＰＡ内部閾値を越えた場合は、このＳＰＡカードでは、不成功に終わったパスワード入力試行が過度の数行われており、再登録しなければならないことをカード保持者に通知する。次に、ＳＰＡは二つの選択肢、「再登録」または「キャンセル」を表示する。カード保持者が前者を選択した場合、ＳＰＡはＳＰＡウェブサイトに接触し、中断してブラウザーと交代する。カード保持者が後者を選んだ場合、ＳＰＡは単純に中断する。
【００８７】
ＳＰＡが、選択されたカードにたいするパスワード失敗カウンターが指定の閾値を越えていないと判断した場合、カード保持者は、そのカードにたいするパスワードを入力するよう督促される。これは、ＳＰＡがこのカードにたいして始めて適用された際に彼／彼女が選択したパスワードである。カード保持者がパスワード入力を完了すると、ＳＰＡはこのパスワードを非可逆的に変形して、それを、ＳＰＡ保存数値と比較する。厳密な照合が見られない場合、ＳＰＡは、このカードにたいするパスワード失敗カウンターを進め（これはＳＰＡによってセーブされており、従って、ＳＰＡが起動される際に非ゼロ値を持っていてもよい）、パスワードの再入力を促す。この行程が、パスワードが適正に入力されるまで、または、パスワード失敗カウンターが指定の値に達するまで、繰り返される。この後の場合、ＳＰＡは、パスワード失敗カウンターの現在数値をセーブし、カード保持者に、前述の「再登録」または「キャンセル」選択肢を与えた後で中断する。カード保持者が、適正なパスワードを入力することに成功せずＳＰＡを非活性化した場合、ＳＰＡも、パスワード失敗カウンターの現在数値をセーブする。
【００８８】
非可逆的変換された、カード保持者入力のパスワードと、ＳＰＡ内部に保存される数値との間に厳密な適合が起これば、ＳＰＡはパスワード失敗カウンターをリセットし、好ましくはこの証明されたばかりのパスワードを暗号キーとして用いてＰｅｒ−Ｃａｒｄ Ｋｅｙを復号化する。次に、ＳＰＡはカード保持者の住所と電話番号を表示し、「あなたの住所と電話番号は変わりましたか？」と尋ね、「イエス」と「ノー」ボタンを供給する。「イエス」をクリックすると、カード保持者に、住所および／または電話番号の訂正を可能とするウィンドーが表示される。
【００８９】
ＳＰＡ次に今選択されたばかりのカードの期限切れ期日を調べ、カードが既に期限切れか（ＰＣのクロックに基づいて）、または、次の３０日以内に期限切れになるかを確定する。そうだとすると、ＳＰＡは、カード保持者に、彼／彼女はこのカードの新規コピーを受け取っているかどうかを尋ね、もしそうなら、新規カードの期限切れ期日をキーで入力して下さいと頼む。（カード保持者は、「ノー」と言う選択肢を持つ。）これでＳＰＡは、この選択されたばかりのカードについて取引を処理する態勢を整えた。
【００９０】
ＳＰＡ動作
前述したように、安全支払いアプリケーション（”ＳＰＡ”）は、支払い取引について、下記を含む、異なる動作モードを有していてよい。すなわち、
１．期限切れ日付フィールドのみを用いる認証
２．追加フィールドを用いる認証
【００９１】
モード２は、商人が取引において追加フィールドを受容可能な場合に使用されるもので、本申請書では「ＭＡＣフィールド」と呼ばれる。これは、モード１よりも高度の真実証明を与えるので、実行可能な場合は何時でも使用される。商人は、ＰＣ中のＳＰＡにたいして、ＰＣによって記入されてもよいデータフィールド中にＭＡＣフィールドを含めることによって、ＳＰＡがモード２適合性であることを示さなければならない。（これは、秘密フィールドであってもよく、その場合、カード保持者に表示されない。）ＰＣがＳＰＡ実行可能の場合は必ず、上記商人は全て、このＭＡＣフィールドを入手者に渡し、従って、そのフィールドを供給することが可能となっていなければならない。
【００９２】
ＰＣが商人画面にＭＡＣフィールドを見つけることができない場合は、ＰＣはモード１に従って動作する。
【００９３】
下記の説明は、実施例によって、この二つのモードにおけるＳＰＡの好ましい動作状態を記述する。
【００９４】
カード保持者のＰＣ（またはその他の装置）がそれを通じてＳＰＡを入手する登録行程は下記の通りである。カード保持者のＰＣによって受容されるＳＰＡソフトウェアは両動作モードをサポートする。各モードにたいして、別々の取引連番が使用される。すなわち、モード１にたいしては一方が、モード２にたいして他方が使われる。両方とも”０”に初期化され、各モード１およびモード２の取引毎に別々に進む。
【００９５】
モード１―期限切れ日付フィールドのみを使用する真実証明
モード１では、承認請求メッセージの期限切れ日付フィールドが、ある形式のＭＡＣを搬送するのに使用される。この「偽似」期限切れ日付は、全ての期限切れ日付同様、ＭＭＹＹにフォーマットされる。好ましくは、今日の市場における多くの、または、全ての商人の現時処理システムと共に動作するよう、その偽似期限切れ日付は、次の４８ヶ月以内に入るものでなければならない。
【００９６】
モード１取引連番は、２０個の二進ビットから成り、各モード１取引毎に進められる。従って、２^２０＝１百万回のモード１取引が起こるまでは、全部が１から全部がゼロへとサイクルしない。このフィールドの左に、４ビットから成る「バージョン数」がある。これは、ある任意の口座番号用ＳＰＡが滞在する各ＰＣにたいして一意の数字である。
【００９７】
前述のように、ＳＰＡウォーレットは現在表示の画面を調べ、それがＭＡＣフィールドを置くことのできる「秘密フィールド」を探す。そのようなフィールドを見つけると、後述のようにモード２またはモード３に進む。
【００９８】
ＳＰＡがそのフィールドを見つけられない場合、前の取引のために使用したのと同じ言語を用いて、それが「理解」できるフィールド、すなわち、「名前」、「住所」、「電話番号」、「カード番号」および「カード期限切れ日付」を探す。これらのフィールドの多くが見つからない場合、ＳＰＡは、カード保持者に画面の言語を選択するように請求する。カード保持者によって選択された言語が、ＳＰＡが前に使用していたものと違っている場合は、ＳＰＡは試行を繰り返す。ＳＰＡが全然または僅かしかフィールドを特定できない場合、カード保持者に、商人支払い画面が本当に存在しているかどうか確認するように尋ねる。（カード保持者のＳＰＡの起動が速すぎることがあり得るからである。）カード保持者が「ノー」を示した場合は（商人支払い画面が表示されていない）、ＳＰＡは中断し、制御を以前に走っていたプログラムに戻す（恐らくはブラウザー）。
【００９９】
カード保持者が「イエス」を示した場合（支払い画面が表示されている）、または、ＳＰＡが、商人支払いフィールドの多くまたは全てを特定可能な場合は、ＳＰＡは自動的に、その特定可能なフィールド（いくらかでもあればその全てを）を埋める。次にＳＰＡは、ＳＰＡウェブサイトに送るべきメッセージを準備する。ＰＣとＳＰＡウェブサイト間の通信は全て（いずれの方向でも）、ＳＳＬ暗号化を用いて保護されていなければならない。このメッセージは下記のものから成っていてもよい。すなわち、
１．偽似口座番号（１６個の十進数字として）
２．偽似ＢＩＮキーインディケーター（８ビット）
３．ＳＰＡ状態インディケーター（１ビット：０＝「状態Ａ」、１＝「状態Ｂ」｛「状態Ｃ」にはモード１取引は無い｝）
４．ＳＰＡバージョン番号（１５ビットとして）。このフィールドは、ＳＰＡタイプ（クレジット、デビット、プリペイド）、および、このタイプの改訂番号を示す。クレジットカードＳＰＡの場合、改訂０、ＳＰＡバージョン番号は十六進数００００である。
５．単一セッションＳＰＡインディケーター（１ビット：０＝正常ＳＰＡ、１＝単一セッションＳＰＡ）
６．ＳＰＡコピー数または単一セッション数（１０ビットとして）
７．最後に使用したモード１取引順序数（２０ビットとして）
８．カードの期限切れ日付（４個の二進コード十進数、または、１６ビット）
９．ＭＡＣであり、好ましくは１６から３２個の二進ビットから成り、好ましくはデータ要素３番から８番まで（好ましくはこの順序で）に載せられ、Ｐｅｒ−Ｃａｒｄ Ｋｅｙを用いて生成されるＭＡＣ。
【０１００】
次に、ＳＰＡウォーレットが、インタネットを介してＳＰＡウェブサイトに接触し、前記データ要素を伝送する。次にウォーレットは応答を待つ（ＳＰＡウェブサイトが、適当なＳＰＡ承認システムへ接触している間）。数秒後、ＳＰＡウォーレットは、カード保持者にたいして「お待ち下さい」を表示する。次に他のテキストが表示され、カード保持者にたいして、ＳＰＡが所望の取引の準備のためにマスターカードに接触中であること、かつ、このため少し時間がかかることを記述する。ディスプレーは好ましくは、数秒に１回変化し、それによって、カード保持者が「何かが現在起こっている」ことが知れるようになっている。
【０１０１】
過度の時間が経った場合は、ＳＰＡウォーレットは再びＳＰＡウェブサイトに接触して、請求を繰り返す。ＳＰＡが、通常は接触できるＳＰＡウェブサイトに接触できない場合には、バックアップＳＰＡウェブサイトに接触する。このような試行の指定の時間と回数の後に、ＳＰＡが、ＳＰＡウェブサイトから応答を得られなかった場合には、ＳＰＡは、カード保持者に、「今回は取引を完了することができませんでした」という旨を通知して、中断する。今度はカード保持者は、別のＳＰＡカードを、別の支払い手段（例えば、手動でマスターカード口座番号を入力する）を、または、後に改めて再試行しなければならない。
【０１０２】
ＳＰＡが最終的にＳＰＡウェブサイトから受容する応答は、「進めることができません」表示、「進めることができます」表示、または、「状態を変更してください」表示である。
【０１０３】
応答が「進めることができません」表示である場合、ＳＰＡはさらに「理由」コードを与える。好ましくは、三つの理由がある。
１．このＳＰＡコピー数はもはや有効ではない（なぜなら、比較的最近のＳＰＡコピーが、最後に同じ”ｎ”ビットを持っている）。（同じ偽似口座番号にたいして、有限数のＳＰＡコピー、例えば１６、が同時使用される可能性がある）。
２．これは、期限切れとなった、単一セッションＳＰＡである。
３．ＭＡＣは真実証明されなかった、取引連番が有効でない、または、「．．．まで無効」―インディケーターが、未来の日付を保持している、あるいは、「無効コピー」フラグが設定されている。
【０１０４】
「進めることができません」表示が第一理由のためである場合、カード保持者には、好ましくは、下記が通知される。すなわち、
ＭＣ−Ｉｎｔｅｒｎｅｔ．ｃｏｍに接触して、このＰＣにたいしてこのカードを再登録しなければなりません。あなたが最初このカードをこのＰＣに登録してから、この同じカードを、他のＰＣ上で、合計少なくとも１６（または別の数）回登録しました。そのため、このＰＣにおけるあなたの元の登録は無効となりました。
【０１０５】
「手続不能」表示が第２の理由に対する場合、カードホルダに以下の情報が提供される。
このＰＣ上のこのカードは、４時間（又は他の時間中）だけ使用可能でした。この時間は満了しました。継続のためには、MC-internet.comにコンタクトし、このＰＣに対してこのカードを再登録する必要があります。
【０１０６】
上記状況のいずれの場合でも、カードホルダに２個のボタンが提示され、その一方は「再登録」と称され、他方は「取消」と称される。第１のものを起動することによって、ＰＣのＳＰＡが、ＳＰＡウェブサイトにコンタクトし、その後中断する。第２のものを起動することによって、ＰＣのＳＰＡが直ぐに中断する。
【０１０７】
「手続不能」表示が第３の理由に対する場合、試みは、考えられる不正であり、カードホルダに以下の情報が提供される。
手続不能。発行人にコンタクトして下さい。
このメッセージの表示後、ＳＰＡは中断します。
【０１０８】
応答が「変更状態」表示の場合、新たな状態の同一性(identity)が応答に含まれる。ＰＣのＳＰＡは、状態を変更し、この新たな状態に対してこの擬似的なアカウント番号を格納する。これによって他のＭｏｄｅ−１を開始してもしなくてもよい。
【０１０９】
応答が「手続可能」を表す場合、この応答は、（カードホルダに表示されない）以下のデータによって行われる。
１．後に説明する基準日（２進化１０進数としての２バイトのフォーマット化されたＹＹＭＭ。）
２．月数インディケータ（４桁の２進化１０進数としての２バイト。）
【０１１０】
この場合、ＳＰＡは、好適には以下のように進行する。
１．Ｍｏｄｅ−１取引順序番号を増分する。
２．この取引順序番号及びＰｅｒ−Ｃａｒｄ Ｋｅｙを使用して、６４ビット２進ＭＡＣを形成する。
３．この６４ビット２進ＭＡＣを、ＳＰＡウェブサイトからの受取直後に基準日及び月数インディケータを用いて擬似満了日に変換する。
４．この擬似満了日を、ＳＰＡが示すことができる場合には顧客の支払いスクリーンの「満了日」領域に配置する。
５．擬似アカウント番号を、ＳＰＡが示すことができる場合には顧客の支払いスクリーンの「アカウント番号」領域に配置する。
６．ＳＰＡが示すことも占有することもできない顧客の支払いスクリーンに任意のアイテムが存在する場合、まだ占有されていない（残りの）アイテムをリストする「ドラッグアンドドロップ」メニューを表示する。
７．顧客に対する基本データが設けられたカードホルダにメッセージを表示し、その後中断する（ＳＰＡが未知であり、カードホルダによって手動で入力する必要があるこの顧客を有するカードホルダ顧客番号のような一部のデータが存在することができる。これによって、ＰＣのブラウザは、この充填スクリーンを顧客に送出する。）。
【０１１１】
「ドラッグアンドドロップ」メニュー中のデータは、ＳＰＡが顧客の支払いスクリーンに示すことができなかった以下のアイテムのうちの任意のものを有する。
１．実際の名前（Ｊｏｈｎ Ｒ．Ｊｏｎｅｓ）として表示されるカードホルダ名。
２．実際のアドレス（１１１ Ｆｉｒｓｔ Ｓｔｒｅｅｔ，Ｅｌｙ．ＮＶ９９９９９）として表示されるカードホルダのアドレス。
３．実際の電話番号（６５０−１１１−２２２２）として表示されるカードホルダの電話番号。
４．（カードホルダが擬似的なアカウント番号を未知であり又は認識していないので、）単語「カードアカウント番号」として表示されるカードアカウント番号。
５．（擬似的な満了日であり、カードホルダに対して無意味であるので、）単語「カード満了日」として表示されるカード満了日。
スクリーンがこれらアイテムの全てを必要としない場合の「取消」ボタンも存在する。擬似的なアカウント番号及び擬似的な満了日が顧客の支払いスクリーンに示される前に「取消ボタン」に当たった場合、好適には、カードホルダに対して以下のメッセージを表示する。
取消を所望しますか？取消によって支払いを許容することができません。「はい、取り消します」ボタン及び「いいえ、継続します」ボタンが続く。
【０１１２】
「はい」のボタンを選択する場合、ＳＰＡは中断され、（どのプログラムが以前に実行されたとしても）制御はブラウザに戻る。「いいえ」を選択する場合、「取消」ウィンドウが取り除かれ、ＳＰＡは「ドラッグアンドドロップ」手順を継続する。
【０１１３】
ＳＰＡが首尾よく完了し、その結果中断すると、制御がブラウザに戻り、かつ、現在充填されている顧客の支払いスクリーンを顧客に送信のためにカードホルダがブラウザを使用すると仮定される。カードホルダが他の購買の準備を行うまで、ＳＰＡを再び起動する必要がない。
【０１１４】
Ｍｏｄｅ−１ ＳＰＡ要求の特定の処理
好適には、Ｍｏｄｅ−１ ＳＰＡは、各取引の間、ＳＰＡに基づく支払いを実行する前に開始される。図２に示すように、ＳＰＡは、ウェブサイト又はサーバ（好適には、マスターカードのサービスプロバイダ）に対して、（例えば）１６桁の擬似アカウント番号からなる要求と、実際のアカウント数の４桁の１０進日付と、４ビットＳＰＡバージョン数と、２０ビットＭｏｄｅ−１取引シーケンス番号（ＴＳＮ）の現在の値と、その後ろ３桁の値に基づく１６ビットＭＡＣとを送り出す。好適には、ＭＡＣは、ＳＰＡ固有の１６バイトのカードごとのキーを用いたトリプルＤＥＡ暗号化と、２０ビットのＭｏｄｅ−１取引シーケンス番号に連結した４ビットのＳＰＡバージョン数に（左から右に）連結した（２進１０進数としての）１６ビットの満了日と、６４ビットの領域の左側への桁そろえ及び２進数の１を用いた正当であるか否かのパディングと、結果的に得られる暗号文字の最も左側の１６ビットの選択とによって形成される。
【０１１５】
図３は、Ｍｏｄｅ１におけるＳＰＡ開始及び取引支払い準備に含まれるステップのシーケンスを示す。既に説明したように、ＳＰＡは、先ず、ステップ２０において、開始要求をサービスプロバイダに送り出す。マスターカードのウェブサイトがこの情報を受け取ると、ステップ２２において好適には、特別なセキュリティモジュール装備のＳＰＡシステムを用いて、満了日、ＳＰＡバージョン数及び取引シーケンス番号に基づいて、ＭＡＣを確認する。ＭＡＣが正当である場合、このシステムは、ステップ２４において、取引シーケンス番号を増分して「予測される取引シーケンス番号」を形成するとともに、表示された擬似アカウント番号のＢＩＮに対するＳＰＡ許可要求を処理するＳＰＡ許可システムに対する関連の擬似アカウント番号及びＳＰＡバージョン数に対する「予測される取引シーケンス番号」の更新を行う。しかしながら、ステップ２６において、このＳＰＡ許可システムは、この擬似アカウント番号及びＳＰＡバージョン数に対して以前受信した最高数の「予測される取引シーケンス番号」以下の「予測される取引シーケンス番号」の場合、直前に受信した「予測される取引シーケンス番号」を拒絶する。このＳＰＡ許可システムは、ステップ２８において、直前に受信した満了日が付与され、現在記録されている満了日以降の場合には、この擬似アカウント番号に関連した満了日を更新する。
【０１１６】
この特別なＳＰＡシステムは、以下の二つの基準データ値：１）（実際には本月又は次の月の）フォーマットＭＭＹＹを有する４桁の１０進数と、２）（１０進数）２５６未満の最大値を有する８ビット２進数の「月数インディケータ」と称されるデータ値を、マスタカードウェブサイトに送信し、その後、ステップ３０において、カードホルダのＰＣのＳＰＡに送信する。このデータは、適切なＳＰＡ許可システムに送信される情報に含まれる。
【０１１７】
擬似満了日の発生
先ず、実際のＭｏｄｅ−１取引に対して、Ｍｏｄｅ−１取引シーケンス数が増分される。その後、左側に４ビットのＳＰＡバージョン数を有する結果的に得られる２０ビット数に対して、８バイト領域で左側に桁合わせされ、２進数ゼロを用いた正当であるか否かのパディング及び倍長ＳＰＡのカードごとのキーを用いたトリプルＤＥＡ暗号化を行う。その結果は、６４ビットの２進ＭＡＣとなる。
【０１１８】
ステップ３２において、取引の擬似満了日領域が、以下のようにして６４ビットの２進ＭＡＣから取得される。
１．「月数インディケータ」（２進数）の最も左にある“１”のビットを選択するとともに、このビット位置から最も右にあるビットまでのビット位置の個数を（最も左にある“１”のビットのビット位置を含めて）計数する。この個数を“Ｎ”と称する。例えば、「月数インディケータ」が０１０１０１００（１０進数で８４）の場合、値“Ｎ”は７となる。“Ｎ”を決定したので、“Ｎ”ビットの各々の群として６４ビットの２進ＭＡＣを考察すると、最も右にあるビットを超える左のものを無視する。最も左の群から開始すると、「月数インディケータ」以下で出くわした最初の群を選択する。そのような群が見つからない場合、この群から２^Ｎを減算したものから最も左の群を選択し、（＞０かつ＜月数インディケータである）この結果を選択値として使用する。
２．ステップ１の結果を２進数１１００（１０進数で１２）で除算して、商及び余りを生成する。これら商及び余りを１０進数に変換する。（００から１１の範囲の値を有する）１０進数の余りを、１０進数の「基準日」の最も左の２桁（ＭＭ）に加算する。結果が１２より大きい場合、結果から１２を減算し、結果が１２より大きいか否かに関係なく、現在の取引に対する擬似の満了日の最も左の２桁のＭＭの結果となる。１２の減算が要求される結果を取得する場合、商（に１）を増分する。
３．ｍｏｄ−１００、ステップ２でも示したように増分する場合もあるステップ２からの２桁の１０進数の商に、「基準日」の最も右の２桁（ＹＹ）を加算する。現在の取引に対する擬似の満了日の最も右の２桁ＹＹを、結果として使用する。
【０１１９】
カードホルダと顧客との間の通信
一度、ＳＰＡがカードホルダのコンピュータにインストールされると、カードホルダは、好適にはインターネットの支払いに対してＳＰＡを使用し、ＳＰＡは、全てのインターネット取引に対してカードホルダの擬似的なアカウント数を提供する。ＳＰＡ Ｍｏｄｅ １において、これがＳＰＡ取引であることは、顧客に対して明白である。アカウント番号が実際には擬似のアカウント番号であり、満了日が実際にはＭＡＣの表示であるとしても、顧客は、受信する他の任意のインターネットＳＳＬとこの取引が異なることに気付かない。
【０１２０】
許可要求の取得者の処理
図４は、本発明の実施の形態による、取得者３４、サービスプロバイダ（マスターカード）２０、発行者３６及び購買者３８の間の通信を示す。
【０１２１】
取得者３４がインターネットの顧客３８から許可要求メッセージを受信すると、ＢＩＮテーブルの発行者ＢＩＮをルックアップする。擬似アカウント番号の取引の場合、「発行者」は、サービスプロバイダ又はマスターカードが許可した処理ファシリティに対応する。
【０１２２】
本発明の一実施の形態において、一部の国が、自国の取引を処理する特別な安全モジュール装備のファシリティを有することができる。そのようなファシリティの各々は、中央のサービスプロバイダの承認のみでセットアップし、取引において処理を行う国用の暗号化キー及びアカウント数変換データのみを保持する。そのような自国のＳＰＡファシリティを有する国において、全ての取引がこのファシリティに送り出され、その結果、同一国の取引が当該国を除外する必要がない。これを、所望の場合には国内の個別の銀行に対して行うこともできる。
【０１２３】
自国の取引を処理するための国内のＳＰＡファシリティは、全ての取引を中央処理ファシリティに行わせる場合に比べて有用である。
【０１２４】
許可要求のサービスプロバイダ処理
先ず、アカウント番号が実際には擬似的なアカウント番号であるか否かを発行者ＢＩＮから決定し、擬似的なアカウント番号である場合、処理のために取引を特定のシステムに送り出す。このシステムは、擬似的なアカウント番号を対応する「実際の」アカウント番号に変換するのに必要なテーブルを格納する。このシステムは、ＳＰＡバージョン数及び擬似的なアカウント数に対して、受信した２０ビットの最大数の「予測される取引シーケンス番号」の記録も格納し、それは、ＭＡＣがこの取引シーケンス番号に対して確認されたか否かの表示も伴う。さらに、システムは、ＭＡＣがまだ確認されていない過去４８時間以内に受信した任意の「予測される取引シーケンス番号」を格納する。そのような予測される取引シーケンス番号の各々に関連して、システムは、予測される取引シーケンス番号の各々に適用する「基準日」及び「月数インディケータ」の表示も格納する。
【０１２５】
「基準日」は、許可要求メッセージ内で許容し得る最新の満了日を表す日付の値である。バックグランドから、一部の顧客が直ちに許可を要求せず、バッチ許可要求を要求する。したがって、この日付は、典型的には取引開始日の１又は２日前となる。
【０１２６】
「月数インディケータ」は、支払いカードが許容される最終満了日に対応する現在の日付を超える月数を表す。典型的には、この数を４８ヶ月とする。
このシステムは、登録が発生する際にカードホルダのＰＣのＳＰＡに配置された独自かつ秘密の１６バイトの暗号化キーを決定する機能を有する安全モジュールも有する。このシステムによって実行される処理は、以下の通りである。
１．格納した上記変換テーブルを用いて、擬似的なアカウント番号から「実際の」アカウント番号を決定する。
２．安全モジュールを用いて、（既に説明したような）擬似的なアカウント番号及び「実際の」アカウント番号を用いたこのＳＰＡに特有の暗号化キーを決定する。
３．ＭＡＣが未だ確認されていない過去４８時間以内に最初に受け取った２０ビットの「予測される取引シーケンス番号」を選択する。この２０ビットの取引シーケンス番号及びＰＣのＳＰＡに対して既に規定したような関連のＳＰＡバージョン数を算出する。関連の「予測される取引シーケンス番号」に対する「基準日」及び「月数インディケータ」を用いて、ＰＣに対するＳＰＡに対して既に規定した方法を用いた満了日をこのＭＡＣから決定する。この満了日が現在の満了日に等しい場合、ＭＡＣが検証される。ＭＡＣの検証となるこの「予測される取引シーケンス番号」に対するエントリは、関連のＳＰＡバージョン番号に対する最高数の「予測される取引シーケンス番号」である場合には「検証されたＭＡＣ」としてマークされ、関連のＳＰＡバージョン番号に対する最高数の「予測される取引シーケンス番号」でない場合には削除される。「検証されたＭＡＣ」としてマークされるとともに同一のＳＰＡバージョン数に関連した任意の低い番号を付した「予測される取引シーケンス番号」に対するエントリは、削除される。
４．ＭＡＣがステップ３（又はステップ５）で検証されると、この取引の顧客がこの同一の取引に対する第２の許可要求メッセージを決して送信しないことを既知でない場合、この擬似的なアカウント番号に対する「ヒストリデータ」にエントリを形成する（一部の顧客は、取引後の所定の時間内に商品の全てを搬送することができない場合には同一の取引に対して二度以上の許可要求メッセージを送信するおそれがある。）。このヒストリデータは、既に説明したデータの全てに加えて、顧客及び取得者の同一性と、このエントリに対する「満了日」とを有する。このエントリ満了日を、将来の特定の時間（例えば６ヶ月）とする。
５．ＭＡＣがステップ３で検証を行わない場合、既に検証したＭＡＣに関連しない過去４８時間中に受信した最も古いものから最も新しいものまでの他の全ての「予測される取引シーケンス番号」に対して、ステップ３で規定した手順を繰り返す。これらの試みのうちの任意のものに対して、結果的に得られるデータが現在の取引中のものに整合する場合、ＭＡＣは、検証されたものと考えられる。ＭＡＣの検証となる２０桁の「予測される取引シーケンス番号」は、当該関連したＳＰＡバージョン数に対して最高の「予測された取引シーケンス数」である場合には、「検証されたＭＡＣ」としてマークされ、当該関連したＳＰＡバージョン数に対して最高の「予測された取引シーケンス数」でない場合には、削除される。ＭＡＣがこのステップで検証された場合、ステップ４も実行する。
６．ステップ３又はステップ５でＭＡＣが検証を行わない場合、当該擬似的なアカウント数に対する「ヒストリーデータ」がアクセスされる。同一の満了日ＭＡＣを発生する同一顧客及び取得者に対するこのデータにエントリが存在し、このエントリが満了しなかった場合、ＭＡＣを許容する（これは、既に認証された取引に対する他の認証要求メッセージであると仮定される。）。このエントリのためにＭＡＣが許容される場合、エントリ満了日を、２ヶ月未満の場合には将来に対して約２ヶ月とする必要がある。その理由は、これが「再支払い」となるおそれがあり、他の月におけるこれと同一の取引に対する他の認証要求メッセージとなるおそれがあるからである。
７．ＭＡＣがステップ３、ステップ５又はステップ６で検証を行わない場合、取引が拒否される。この場合、「断り」応答が取得者に送り出される。
ＭＡＣが検証されると、マスターカードは、発行者に対する許可要求メッセージをフォーマット化する。許可要求メッセージは、（擬似的なアカウント番号ではなく）「正しい」アカウント番号と、（ＭＡＣではなく）「正しい」満了日とを有する。しかしながら、マスターカードＳＰＡ許可システムは、発行者からの許可応答の受信の予測の際に所得者から受信されるようなアカウント番号領域及び満了日領域の記録を保持する必要がある。
【０１２７】
発行者に送信される許可応答メッセージにおいて、許可応答が、取得者ＢＩＮに基づく支払いネットワークを通じて送り出される場合、マスターカードは、取引メッセージの取得者ＢＩＮを、「擬似的な」取得者ＢＩＮとしての役割を果たすマスターカードの特定のＢＩＮのうちの一つに置換する。取得者ＢＩＮは、発行者が取得者の代わりにマスターカードに応答するように置換される。許可要求メッセージが来る場所と許可応答メッセージを戻す場所が同一であるという記録を支払いネットワークが保持する場合、このステップを実行する必要はない。
【０１２８】
取得者及び発行者に対して交換料金を正確に算出するために擬似的な取得者ＢＩＮが用いられる場合、擬似的な取得者ＢＩＮは、取得者が配置された国又は結果として同一の交換料金を付与する他の国若しくは領域に対応する必要がある。各国が、それに関連した特定のＢＩＮを有する場合、マスターカードは、取得者ＢＩＮを、取得者の国に関連した特定のＢＩＮに置換する。取得者の国が、それに関連した特定のＢＩＮを有しない場合、他の国に関連した特定のＢＩＮを、同一の交換料金となるものに選択することができる。
【０１２９】
擬似的な取得者ＢＩＮを使用する場合、マスターカードは、所得者からの許可要求で受信した取得者参照データ（以後、「オリジナル取得者参照データ」と称する。）をデータベースに格納する。発行者に対して許可メッセージをフォーマット化するに際しに、マスターカードは、オリジナル取得者参照データを、擬似的な取得者ＢＩＮ、適切な取引タイプのインディケータ及びオリジナル取得者基準データを見つけるためにマスターカードが使用するインデックス値を有する「擬似的な」取得者参照データに置換する。
【０１３０】
国内的な(national)ＳＰＡファシリティが擬似的なアカウント番号の取引を処理する場合、そのファシリティは、以下の様に動作する。しかしながら、この国内的なＳＰＡファシリティは、国内の発行者に対する取引のみ処理し、したがって、その国に適用する暗号化キー及びアカウント番号変換テーブルエントリしか必要としない。
【０１３１】
ＳＰＡ許可システムでは、実際の許可要求を受信するまで待機するのに比べて、新たな「予測される取引シーケンス番号」を受信する際にＭＡＣ表示の満了日を計算し及び格納するのが有効である。この場合、許可要求を受信すると、許可要求メッセージ中の満了日と、以前の任意の許可要求メッセージ中の満了日に未だ整合しない過去４８時間以内に予め計算され及び格納された満了日とを比較する必要がある。
【０１３２】
許可要求の発行者ハンドリング
図５は、発行者が例えばマスターカード又は許可された国内のＳＰＡファシリティから受信した後の発行者３６、マスターカード（サービスプロバイダ）１０、取得者３４及び本発明の一実施の形態による顧客３８の間の通信を示す。
【０１３３】
発行者は、他の任意の取引のように取引を許可する。許可応答の戻りは、「擬似的な」取得者、すなわち、擬似的なアカウント番号を「正しい」アカウント番号に変換するとともにＭＡＣ表示の満了日を検証した同一のマスターカードＳＰＡ許可システムに戻される。
【０１３４】
既に説明したように、このシステムは、取引の（一時的な）記録を維持し、すなわち、アカウント番号の領域及び満了日の領域を、取得者から受け取った値に戻すことができる。取得者から受け取った値に置換されたこれらの領域を有する許可応答は、通常のマスターカードの取引の場合のように、取得者に送出され、取得者から顧客に送出される。
【０１３５】
ＳＰＡ許可システムが実際には国内のＳＰＡファシリティである場合、このファシリティは、以前の説明で示した機能を実行する。
【０１３６】
クリアリング及び清算 (Settlement)
取得者は、通常の方法で取引の清算を行う。取得者は、マスターカードのＩＮＥＴ（クリアリング及び清算）システムに行き、そのシステムは、擬似的なアカウント番号を「正しい」アカウント番号に変換する（そのような交換メッセージに満了日の領域は存在しない。）。
【０１３７】
一度、ＩＮＥＴが取引を「正しい」アカウント番号に変換すると、その番号は、他の任意の取引と同様に、発行者に送り出され、クリアリング及び清算される。
【０１３８】
例外処理
将来の料金返還(chargeback)、コピー要求、又は発行者によって開始されるこの取引に関連する他の任意の例外処理がある場合、それをＩＮＥＴ（又はＳＰＡ例外処理システム）に送り出す必要があり、この場合、変換は、「正しい」アカウント番号から擬似的なアカウント番号まで行われる。このファシリティが個別の取引の記録を保持する必要がないので、この変換はテーブルに基づくことができる。取引中のデータによって、それが発行者から適切なマスターカードファシリティに送出される。
【０１３９】
同様に、顧客及び取得者から発行者までの任意の応答は、適切なマスターカードファシリティに送出され、この場合、「正しい」アカウント番号を応答に関連させる。
【０１４０】
Ｍｏｄｅ １に対する他の例
図６は、Ｍｏｄｅ １に対する他の例を示す。図６の各“Ｘ”は桁を表す。本例では、ＭＡＣを、取引シーケンスに基づいて発生し、ＭＡＣは、既に説明した擬似的な満了日となる。さらに、（４０，４２によって表される）ＭＡＣを発生するのに使用される取引シーケンス番号の１以上の下方の桁は、擬似的なアカウント番号４４で置換される。その桁は、図示したようにカードホルダ番号とチェック桁との間で置換される。
【０１４１】
本例では、ＳＰＡは、取引中にマスターカードウェブサイト又はサーバと通信するのに必要とされない。ＳＰＡファシリティは、登録されたＳＰＡの各々に対する取引シーケンス番号のカウンタを維持する。ＳＰＡファシリティは、許可要求を受け取ると、擬似的なアカウント番号の取引シーケンス番号の下の桁とともに維持する取引シーケンス番号カウントの上の桁に基づいてＭＡＣを発生する。その後、ＳＰＡファシリティは、このＭＡＣを擬似的な満了日に変換し、この満了日を、許可要求メッセージ中の満了日と比較する。また、ＳＰＡファシリティは、取引シーケンス番号が以前の取引からの数の繰り返しでないことを検証する。
【０１４２】
Ｍｏｄｅ ２及び３：他の領域を用いた認証
ＳＰＡウォレット(wallet)は、（カードホルダが適切な方向に従った場合には）顧客の支払いスクリーンがＰＣ上に表示されるまで有効にならないようにする必要がある。したがって、ＳＰＡは、取引の処理の準備を行うと、現在表示されているスクリーンを検査し、見えるものを理解することを試みる。先ず、ＳＰＡは、ＳＰＡ ＭＡＣ領域である「隠し」領域を探す。
【０１４３】
Ｍｏｄｅ−２取引に対して、この領域の識別子を、特定の値とする必要がある。Ｍｏｄｅ−３取引に対して、この領域の識別子を、互いに相違する値とする必要がある。ＳＰＡが、一方がＭｏｄｅ−２識別子を有するとともに他方がＭｏｄｅ−３識別子を有する二つの隠し領域を見つけた場合、ＳＰＡは常に、Ｍｏｄｅ−２領域を選択し、これをＭｏｄｅ−２取引と考える。
【０１４４】
ＳＰＡがこの「隠し」領域を見つけることができる場合、これは、“Ｍｏｄｅ−２”又は“Ｍｏｄｅ−３”取引となる。そのような取引の場合、ＳＰＡは、「カード番号」領域、「満了日」領域、並びにカードホルダの名前、アドレス及び電話番号を特定する領域も見付けることができる。その理由は、ＳＰＡに従う顧客の場合、規格化された方法によってこれらの領域の全てが識別されるからである。この場合、ＳＰＡは、支払いスクリーン全体を占有する。
【０１４５】
Ｍｏｄｅ−２又はＭｏｄｅ−３取引のイベントにおいて、ＳＰＡは、以下のような処理を行う。
１．カードホルダの名前、カードホルダのアドレス及びカードホルダの電話番号に対する顧客の支払いスクリーンのエントリを占有する。
２．顧客の支払いスクリーンの「アカウント番号」領域を擬似のアカウント番号で占有する。
３．顧客の支払いスクリーンの「満了日」領域を、（カードホルダが相互に更新された）このカードに対してＳＰＡに記憶された満了日で占有する。
４．Ｍｏｄｅ−２取引シーケンス番号を増分（し及び永久的に格納）する。
５．ＭＡＣを形成する。
６．以下に規定するような（上記のようにして発生したＭＡＣを有する）ＭＡＣ領域を形成する。
７．顧客支払いスクリーンの「隠し」領域にＭＡＣ領域を配置する。
８．顧客の支払いスクリーンが占有されるとともにそれを送信できるという情報をカードホルダに提供する。
９．サスペンドし、その結果、制御がＰＣのブラウザに戻される。
カードホルダは、適切な領域を互いに占有するように、ＳＰＡが占有したスクリーンを送信する通常のブラウザ機能を用いることが予測される。
【０１４６】
Ｍｏｄｅ−２／３ ＭＡＣ領域は、好適には以下のデータ要素からなる。
１．（８ビットの）擬似ＢＩＮキーインディケータ
２．（１ビット：０＝Ｍｏｄｅ−２，１＝Ｍｏｄｅ−３の）ＳＰＡモードインディケータ
３．（１５ビットの）ＳＰＡバージョン数。この領域は、ＳＰＡタイプ（貸方、借方、前払い）及びこのタイプに対するバージョン数を表す。クレジットカードＳＰＡ、リビジョン０及びＳＰＡバージョンに対して、数は全てゼロとなる。
４．（１ビット：０＝通常のＳＰＡ，１＝単一セッションのＳＰＡの）単一セッションＳＰＡインディケータ。
５．（１０ビットの）ＳＰＡコピー数及び単一セッション数
６．（２０ビットの）直前に増分したＭｏｄｅ−２／３取引シーケンス番号
７．（４桁の２進化１０進数すなわち１６ビットの）カードの満了日
８．カードごとのキーを用いて順に発生したデータ要素＃２−＃７の２進化３２ビットのＭＡＣ
【０１４７】
Ｍｏｄｅ−２及びＭｏｄｅ−３は、同一セットの取引シーケンス番号を使用する。したがって、同一の擬似的なアカウント番号に対する同一のＰＣの同一のカードホルダのＳＰＡからは、Ｍｏｄｅ−３取引と同一の取引シーケンス番号を有するＭｏｄｅ−２取引は決して存在しない。
【０１４８】
ＳＰＡが再び有効になる（非中断状態になる）と、全てのＳＰＡカードのリストを表示し、そのうちの一つを選択するようカードホルダに問い合わせる。しかしながら、ＳＰＡが中断されるが閉じられない場合、及び直前に使用されたカードをカードホルダが選択する場合、ＳＰＡは、アドレス、電話番号又はカード満了日が変更されたか否かをカードホルダに（再び）問い合わせない。また、ＳＰＡは、パスワードを再入力することを要求しない。その代わりに、ＳＰＡは、（別の状況ではキーとしてパスワードを用いることによって暗号化される）クリアテキストのカード後とのキーを保持する。このクリアテキストキーは、ＳＰＡが閉じられるとき又は他のカードが選択されるときに消去される。
【０１４９】
Ｍｏｄｅ ２要求の特定の処理
このモードにおいて、（例えば）１３桁の１０進数の個別のＭＡＣ領域は、ＳＰＡ固有の領域として取引に含まれる。これら１３桁は以下の通りである。
１．“ＳＰＡ”インディケータ：１桁。この領域は、通常、値１を有する。しかしながら、カードホルダが、（例えばデスクトップコンピュータ又はラップトップコンピュータ上で）同一の「正しい」アカウント番号に対してＳＰＡのコピーを１個より多く有する場合、ＳＰＡの他のバージョンは、ＳＰＡインディケータフィールドに互いに相違する数を有する（ＳＰＡ取引シーケンス番号は、ＳＰＡのそのようなバージョンの各々に対して独自のものである。）。
２．ＳＰＡのこのバージョンに対するＳＰＡ取引シーケンス番号：６桁。このフィールドは、この特別のコンピュータで開始したＳＰＡ取引に対して増分する（各コンピュータは、ＳＰＡのそれ自体のバージョンを有し、したがって、それ自体のセットのシーケンス番号を有するようになる。）。
３．ＭＡＣそれ自体：６桁。後に説明するように、実際のＭＡＣは、上記の二つの領域で算出される。
【０１５０】
提案されるＭＡＣ−発生プロセスは、以下の通りである。
１．ＳＰＡバージョン数の７桁を（左に）表示するとともに（このコンピュータに対する）ＳＰＡ取引シーケンス番号を２進化１０進数で表示して、２８ビットを生成する。６４ビット領域でこれら２８ビットを左に桁合わせするとともに、ゼロのビットを用いた正当であるか否かのパディングを行う。
２．暗号化キーとしてカードごとのキーの最も左の８バイトを用いたステップ１の結果のＤＥＡ暗号化。
３．暗号化キーとしてカードごとのキーの最も左の８バイトを用いたステップ２の結果のＤＥＡ暗号化。
４．暗号化キーとしてカードごとのキーの最も左の８バイトを用いたステップ３の結果のＤＥＡ暗号化。
５．ステップ４の結果的に得られる６４ビットを、各々が４ビットの１６進数と考える。その１６進数を（左から右に）走査し、１６進数で９未満の値を有する最初の６桁を選択する。そのような６桁が見つからない場合、桁を再走査するとともに１６進数で９より大きい桁のみを選択し、かつ、その各々から１６進数Ａを減算することによって、必要な残りの桁を見つける。
６．この取引に対する６桁の２進ＭＡＣとしてステップ５の結果を用いる。
ＭＡＣは、カードホルダのＰＣのＳＰＡによって発生し、適切なマスターカードＳＰＡファシリティによって検証される。発生の際には、ステップ６に起因する６桁の１０進数は、実際のＭＡＣとしてＭＡＣフィールドに挿入される。検証の際には、ＳＰＡファシリティは、ＭＡＣフィールドの最も左の７桁を用いて上記６ステップを実行し、その後、受信したＭＡＣフィールドの最も右の６桁に対して、ステップ６に起因する６桁と比較する。正確な整合は、認証された取引を表す。非整合は、拒否する必要がある取引を表す。
【０１５１】
カードホルダと顧客との間の通信
ＭＡＣフィールドが顧客によってサポートされるときには常に、ＳＰＡは、取引に関連するＭＡＣを形成するために、嵌め込まれた秘密キーを使用し、このＭＡＣ及びそれに基づくデータを、取引の一部となるＭＡＣ領域に配置する。
【０１５２】
カードホルダの取引メッセージの受信に応答して、顧客は、取得者に対する通常の認証要求をフォーマット化する。この認証要求は、消費者のＰＣから提供されるようなＭＡＣ領域を有する。
【０１５３】
顧客が、カードホルダ取引に対して複数の認証／クリアリング取引を開始する場合、これらの取引のうちの最初のもののみがＭＡＣ領域及び満了日を有する。次の取引は、擬似的なアカウント番号のみを有し、顧客が発生したメールオーダ及び電話注文取引と考えられる。これは、再び発生する全ての支払い及び複数の複数のクリアリングを伴う部分的な支払いにも当てはまる。
【０１５４】
認証要求のサービスプロバイダハンドリング
サービスプロバイダは、取引を受け取ると、アカウント番号が擬似的なアカウント番号であるか否かを発行者ＢＩＮから決定し、擬似的なアカウント番号である場合、処理のために取引を特定のＳＰＡ認証システムに送信する。このシステムを、既に説明したよう国内のＳＰＡファシリティとすることができる。このシステムは、ＭＡＣフィールドの存在から、それがＭｏｄｅ−２取引であることを自動的に記す。アカウント番号を擬似的なアカウント番号から対応する「正しい」アカウント番号に変換した後、システムは、ＭＡＣを形成するためにＰＣで用いられる実質的には同一の手順を用いて、（既に説明したように）カードごとのキーを決定し、かつ、ＭＡＣを検証するようこのキーを使用する。システムは、取引シーケンス番号もチェックし、そのために、システムが処理する擬似的なアカウント番号の各々のバージョン数に対して取引シーケンス番号情報を維持する。
【０１５５】
１．取引シーケンス番号が、少なくとも４８時間前に受信したこのＳＰＡのこのバージョンに対する最大の取引シーケンス番号より小さい（又は等しい）場合、又は
２．取引シーケンス番号が、このＳＰＡのこのバージョンに対する既に受信した任意の取引シーケンス番号に整合する場合（これは、過去４８時間内に受信した取引シーケンス番号に制約される。）、
システムは取引を拒否する。
【０１５６】
ＭＡＣ又は取引シーケンス番号が検証をし損なうと、このファシリティによって、取引が断られる。ＭＡＣと取引シーケンス番号の両方が検証を行う場合、このファシリティによって、「正しい」アカウント番号（及びカードホルダのＰＣによって取引に挿入された「正しい」満了日）を有する取引を、発行者に送出する。
【０１５７】
認証要求の発行者ハンドリング
発行者は、他の任意の取引のように取引を認証する。認証応答は、擬似的なアカウント番号を「正しい」アカウント番号に変換するとともにＭＡＣを認証した同一のＳＰＡ認証システムに戻す。認証応答を送出する支払いネットワークが応答メッセージ中の取得者ＢＩＮに基づく場合、擬似的な取得者ＢＩＮを、既に説明したようにして使用することができる。
【０１５８】
このシステムは、「正しい」アカウント番号を擬似的なアカウント番号に戻し、元の取引中にあったデータを復元する（Ｍｏｄｅ ２の場合、開始から取引に保持された満了データは、「正しい」満了データとなり、その結果、この領域を復元する必要はない。）。結果的に得られるメッセージは、取引を通常のように処理するとともに通常の方法で認証応答を顧客に送信する「正しい」取得者に送信される。顧客は、他の任意の取引に対する場合のように認証応答に応答する。
【０１５９】
取引が国内のＳＰＡファシリティに送出されると、このファシリティは、上記説明で示した機能を実行する。
【０１６０】
クリアリング及び清算
ＳＰＡクリアリングメッセージは、全てのクリアリングメッセージのようにマスターカードＩＮＥＴ（クリアリング及び清算）に送出される。ＳＰＡ取引が認識可能なＢＩＮを有するので、ＩＮＥＴは、擬似的なアカウント番号を「正しい」アカウント番号に置換する。この取引に対する任意の例外処理が次にある場合、「正しい」アカウント番号を擬似的なアカウント番号に変換できるＳＰＡファシリティに例外処理メッセージが送出されるように、メッセージに対して他の変更が行われる。そのような変化を有するクリアリングメッセージは、通常の方法で取引を処理するカード発行者に送信される。取得者が発行者にもなる場合、マスターカードは、クリアされた取引を、表示された変更及び適切な料金計算を行う取得者／発行者に戻す。
【０１６１】
例外処理
取引についてのメッセージを発行者から取得者又は顧客に戻す必要がある場合、メッセージは、任意の取引メッセージを処理する場合のように発行者によって処理される。取引記録中のデータによって、マスターカードファシリティにメッセージを送出し、マスターカードファシリティは、「正しい」アカウント番号を擬似的なアカウント番号に戻す。その後、例外処理メッセージは、そのような他の任意のメッセージのようにそれを処理する取得者に送出される。
【０１６２】
また、取得者と発行者との間で送信が行われる取引についての任意のドキュメンテーションをＭＣＩによって変更し、取得者が擬似的なアカウント番号を受信するとともに、発行者が「正しい」アカウント番号を受信するようにする。そのようなデータが電子的であり、かつ、識別可能である場合、データは内的に変更される。そのようなドキュメンテーションが全体的に電子的でない場合、正しいアカウント番号及び擬似的なアカウント番号を反映する他の形態を形成することができる。そのようなドキュメンテーションを直接取得者に送出する発行者に対して、両方の番号を提供するよう要求することができる。
【０１６３】
識別用のプラスチックカードの発行
一部の状況において、カードホルダは、インターネットを通じてチケットを購入し、チケットが入場を許容するイベントの出現の際に、取引に使用されるカードを発生してチケットの合法な処理を認証することを要求する。
【０１６４】
ＳＰＡプログラムの開始時に、カードホルダは、「識別目的のみ」であることを明確に表すカードのように擬似的なアカウント番号を示す実際のプラスチックカードを発行する。
【０１６５】
次いで、擬似的なアカウント番号を用いてカードホルダを合法的に認証する必要がある顧客は、（マスターカードに適切な識別及び認証情報を提供することによって）マスターカードに登録し、顧客は、秘密キーが設けられるとともに、登録の暗号プルーフとして認証を行う。その後、そのような顧客は、「正しい」アカウント番号を取得するために取引データと顧客の権利の両方を認証する暗号化認証の下で擬似的なアカウント番号取引の詳細のコピーを提供することによって、マスターカードファシリティから「正しい」アカウント番号を取得することができる。マスターカードは、暗号化された形態の「正しい」アカウント番号を顧客に送り出し、その結果、カードホルダは、「正しい」アカウント番号に対応するカードを用いて識別される。
【０１６６】
ＳＰＡウォレット動作：Ｍｏｄｅ−０取引処理
Ｍｏｄｅ−０は、「状態Ｃ」の擬似的なアカウント番号に対するウォレットとともにのみ使用される。それは、Ｍｏｄｅ−１を「状態Ａ」又は「状態Ｂ」で使用する状況の下で使用される（ＳＰＡは、ＳＰＡ ＭＡＣ領域として使用可能な「隠し」領域に対する識別子を見つけることができない。）。Ｍｏｄｅ−０で動作する際に、ＰＣのＳＰＡは、単に顧客の支払いスクリーンの「支払い番号」領域の擬似的なアカウント番号及びこのスクリーンの「満了日」領域の実際の満了日の置換を行う。それは、Ｍｏｄｅ−１に対して説明したように顧客の支払いスクリーンの他の銀行に充填を行う。
本発明は、上記実施の形態に限定されるものではなく、幾多の変更及び変形が可能である。
【図面の簡単な説明】
【図１】 本発明の一つの実施態様による取引法に含まれる、いくつかの処理成分のブロックダイアグラムである。
【図２】 本発明の一つの実施態様において、安全支払いアプリケーション初回請求内部に供給される情報の表示である。
【図３】 本発明の一つの実施態様に従って、期限切れ日付フィールド値を入手するために実行される行程を描いたフローダイアグラムである。
【図４】 本発明の一つの実施態様に従って、商人、入手者、サービスプロバイダーおよび発行者の間での通信のフローを描いたフローダイアグラムである。
【図５】 本発明の一つの実施態様に従って、発行者、サービスプロバイダー、入手者および商人の間での情報のフローを描いたフローダイアグラムである。
【図６】 本発明の一つの実施態様に従ってメッセージを送る別法を表わす図である。

Claims (14)

1. アカウント番号を用いて公衆通信網上で電子的な取引を行う方法であって、
   カード保持者のコンピュータ装置が、カード保持者からのアカウント番号の入力を受け付けるステップと、
   サービスプロバイダーのサーバが、前記アカウント番号に関連してＰｅｒ−Ｃａｒｄ Ｋｅｙを生成するステップと、
   前記装置が、前記Ｐｅｒ−Ｃａｒｄ Ｋｅｙを保存するステップと、
   電子的な取引を行うに当たり、前記装置が、前記保存したＰｅｒ−Ｃａｒｄ Ｋｅｙを用いて、メッセージ認証コードを発生するステップと、
   前記装置が、基準日及び月数インディケータを用いて、前記メッセージ認証コードを擬似的な満了日に変換するステップと、
   前記装置が、前記取引に対する認証要求を発生し、その要求が、前記擬似的な満了日を格納する満了日領域を有するステップと、
   前記サーバが、前記擬似的な満了日、ＳＰＡバージョン数又は取引シーケンス番号に基づいて前記メッセージ認証コードを検証するステップとを具えることを特徴とする方法。
2. 前記装置が、前記電子的な取引を、公衆網と、前記アカウント番号の発行者を有する支払いネットワーク上で行い、前記アカウント番号が正しい満了日を有し、前記正しい満了日を有する第２の認証要求を発生するステップと、前記装置が、前記取引の承認に対して前記発行者の前記第２の要求を送り出すステップとを更に具えることを特徴とする請求項１記載の方法。
3. 関連の擬似的なアカウント番号を有する支払いアカウント番号を用いて、公衆網上で電子的な取引を行う方法であって、
   （ａ）カード保持者のコンピュータ装置が、カード保持者からの支払いアカウント番号の入力を受け付けるステップと、
   （ｂ）サービスプロバイダーのサーバが、前記支払いアカウント番号に関連して擬似的なアカウント番号及びＰｅｒ−Ｃａｒｄ Ｋｅｙを生成するステップと、
   （ｃ）前記装置が、前記擬似的なアカウント番号及び前記Ｐｅｒ−Ｃａｒｄ Ｋｅｙを保存するステップと、
   （ｄ）電子的な取引を行うに当たり、前記装置が、前記保存したＰｅｒ−Ｃａｒｄ Ｋｅｙを用いて、メッセージ認証コード（“ＭＡＣ”）を発生するステップと、
   （ｅ）前記装置が、安全な支払いアプリケーションによって、前記擬似的なアカウント番号及び前記ＭＡＣを有するＭＡＣ検証要求を発生するステップと、
   （ｆ）前記サーバが、前記擬似的なアカウント番号を用いて前記ＭＡＣを検証するステップと、
   （ｇ）前記サーバが、前記検証に基づいて、前記ＭＡＣに対する予測される取引シーケンス番号（ＥＴＳＮ）を形成するステップと、
   （ｈ）前記装置が、前記安全な支払いアプリケーションに参照データを設けるステップと、
   （ｉ）前記装置が、前記予測される取引シーケンス番号及び前記Ｐｅｒ−Ｃａｒｄ Ｋｅｙを用いて、第２のメッセージ認証コードを形成するステップと、
   （ｊ）前記装置が、前記参照データを用いて、前記第２のメッセージ認証コードを擬似的な満了日に変換するステップと、
   （ｋ）前記装置が、前記擬似的な満了日を有する満了日領域を有する認証要求を発生するステップと、
   （ｌ）前記サーバが、前記認証要求に応答し、前記擬似的な満了日に基づいて、前記第２のメッセージ認証コードを検証するステップとを具えることを特徴とする方法。
4. 前記Ｐｅｒ−Ｃａｒｄ Ｋｅｙを、ＢＩＮごとのキーを用いて発生することを特徴とする請求項３記載の方法。
5. 前記ＭＡＣ検証要求が、前記支払いアカウント番号の満了日、バージョン数及び取引シーケンス番号の値を更に有し、前記ＭＡＣを検証するステップが、前記満了日、前記バージョン数及び前記取引シーケンス番号の値に基づくことを特徴とする請求項３記載の方法。
6. 前記第２のメッセージ認証コードを形成するステップが、前記バージョン数を使用することを特徴とする請求項５記載の方法。
7. 前記参照データが基準日及び月数インディケータを有することを特徴とする請求項３記載の方法。
8. 前記第２のメッセージ認証コードを検証するステップが、
   前記擬似的なアカウント番号及び格納された変換テーブルを用いて、前記支払いアカウント番号を決定するステップと、
   前記支払いアカウント番号及び前記擬似的なアカウント番号を用いて、前記擬似的なアカウント番号に関連したＰｅｒ−Ｃａｒｄ Ｋｅｙを決定するステップと、
   関連のメッセージ認証コードが検証されなかった第２の予測される取引シーケンス番号を選択するステップと、
   前記第２の予測される取引シーケンス番号に対して特定した第２の参照データを用いて、前記第２のメッセージ認証コードを第２の擬似的な満了日に変換するステップと、
   前記第２の擬似的な満了日及び前記擬似的な満了日を比較するステップと、
   前記比較に基づいて、前記第２のメッセージ認証コードを検証するステップ
   とを具えることを特徴とする請求項３記載の方法。
9. 前記第２の擬似的な満了日が前記擬似的な満了日に整合する場合、前記第２のメッセージ認証コードを検証することを特徴とする請求項８記載の方法。
10. 関連の擬似的なアカウント番号を有する支払いアカウント番号を用いて、公衆通信網上で電子的な取引を行う方法であって、
    （ａ）サービスプロバイダーのサーバが、認証キーを発生するために使用される複数の認証キー発生プロセスのうちの一つを表す制御領域を、前記擬似的なアカウント番号に設けるステップと、
    （ｂ）カード保持者のコンピュータ装置が、前記擬似的なアカウント番号の前記制御領域に表された前記複数の認証キーを発生するプロセスのうちの一つを用いて、前記擬似的なアカウント番号に関連した認証キーを発生するステップと、
    （ｃ）前記装置が、前記認証キーを用いて、前記取引に特有のメッセージ認証コードを発生するステップと、
    （ｄ）前記装置が、前記メッセージ認証コード及び前記擬似的なアカウント番号を有する認証要求メッセージを発生するステップと、
    （ｅ）前記サーバが、表された前記認証キー発生プロセス及び前記認証キーを、前記擬似的なアカウント番号に対して用いて、メッセージ認証コードを検証するステップとを具えることを特徴とする方法。
11. 前記認証キーを、前記擬似的なアカウント番号上の認証キー誘導キーをも用いて発生させることを特徴とする請求項１０記載の方法。
12. 前記認証キーを、ＢＩＮごとのキーをも用いて発生させることを特徴とする請求項１１記載の方法。
13. アカウント番号を用いて通信網上で電子的な取引を行う方法であって、
    サービスプロバイダーのサーバが、前記アカウント番号に関連したＰｅｒ−Ｃａｒｄ Ｋｅｙを発生するステップと、
    カード保持者のコンピュータ装置が、前記Ｐｅｒ−Ｃａｒｄ Ｋｅｙを用いてメッセージ認証コードを発生するステップと、
    前記装置が、互いに相違する領域を有する認証要求を有する前記メッセージ認証コードを互いに相違する方法で送出する少なくとも二つの互いに相違する動作モードを提供し、前記動作モードのうちの少なくとも一つが満了日領域に前記メッセージ認証コードを送出するモードであり、前記動作モードのうちの少なくとも一つがメッセージ認証コード領域に前記メッセージ認証コードを送出するモードであるステップとを具えることを特徴とする方法。
14. 前記メッセージ認証コードが存在する場合には、前記メッセージ認証コードを、前記メッセージ認証コード領域で自動的に搬送することを特徴とする請求項１３記載の方法。

Images