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

Abstract

(57)【要約】 認証要求の満了日領域の擬似的な満了日を利用する、公衆通信網上で電子的な取引を行う安全な方法を提供する。好適な方法の一つは、アカウント番号を用いて公衆通信網上で電子的な取引を行う方法であって、前記アカウント番号に関連したカードごとのキーを発生するステップと、前記カードごとのキーを用いてメッセージ認証コードを発生するステップと、前記メッセージ認証コードを擬似的な満了日に変換するステップと、前記取引に対する認証要求を発生し、その要求が、前記擬似的な満了日を有する満了日領域を有するステップと、前記擬似的な満了日に基づいて前記メッセージ認証コードを検証するステップとを具える。本発明の他の例は、関連の擬似的なアカウント数を有する支払いアカウント数を用いて、公衆通信網上で電子的な取引を行う方法であって、（ａ）認証キーを発生するために使用される複数のキー発生プロセスのうちの一つを表す制御領域を、前記擬似的なアカウント数に設けるステップと、（ｂ）前記擬似的なアカウント数の前記制御領域に表された前記複数のキー発生すプロセスのうちの一つを用いて、前記擬似的なアカウント数に関連した認証キーを発生するステップと、（ｃ）前記認証キーを用いて、前記取引に特有のメッセージ認証コードを発生するステップと、（ｄ）前記メッセージ認証コード及び前記擬似的なアカウント数を有する認証要求メッセージを発生するステップと、（ｅ）表された前記キー発生プロセス及び前記認証キーを用いて、メッセージ認証コードを検証するステップとを具えることを特徴とする方法を有する。

Description

【発明の詳細な説明】

【０００１】優先権申請 本申請書は、２０００年８月１８日登録、名称「コンピュータネットワーク上
で確実なマスターカード支払いを実行するための方法および装置」なる、米国暫
定出願第６０／２２６，２２７号、および、２０００年６月２１日登録、名称「
コンピュータネットワーク上で確実な支払いを実行するための改良法およびシス
テム」なる、米国暫定出願第６０／２１３，０６３号に対する優先権を主張する
ものである。ここに、両暫定申請を引用することにより本申請書に含めることに
する。本申請書はさらに、それ自体、２０００年４月１１日登録、名称「コンピ
ュータネットワーク上で確実な支払いを実行するための方法およびシステム」な
る米国特許出願連番６０／１９５，９６３号、および、２００１年３月１５日登
録、名称「コンピュータネットワークにおける確実な支払いのための方法および
システム」なる、米国特許出願連番第０９／８０９，３６７号にたいして優先権
を主張する、２００１年４月１１日登録、名称「コンピュータネットワーク上で
確実な支払いを実行する改良法およびシステム」なる、米国特許出願連番第０９
／８３３，０４９号にたいする優先権を主張する。この最後の特許出願を、引用
することによって本申請書に含める。

【０００２】 （発明の背景） 本発明は、通信ネットワーク上で確実な金銭取引を実行するための方法および
システム、さらに詳細には、インターネットのようなコンピュータネットワーク
上で確実に支払いを伝送し、かつ、公共通信チャンネル上で、微妙な機密情報を
確実に伝送するための方法およびシステムに関わる。

【０００３】 自明の通り、過去数年において、オンライン商売は巨大な成長を経験してきた
が、そのように成長してもなお、消費者は依然として、個人の財政情報を使用す
ること、および、そのような情報、例えば、クレジットカード番号や個人特定番
号を、インターネットのような、公共通信ネットワークを通じて伝送することで
患わされたり、そうした伝送を不安に思っている。そのため、過去数年、企業は
、コンピュータネットワーク上で行われる支払いの安全性を保証し、かつ、財政
情報の剽窃や不正使用の危険を下げるための方法を、しかも、最善の方法を求め
てあがいている。

【０００４】 例えば、「オンライン取引用、取引仲介番号付き、電子オンライン商業カード
」なる名称で、マイクロソフト社に交付された米国特許第５，８８３，８１０号
は、各取引毎に一時的取引番号を供給し、かつ、それを、恒久口座番号に関連さ
せるシステムに向けられる。取引番号は、一見真のクレジットカード番号のよう
であり、顧客は、この取引番号を使い、それを、商人にたいして、顧客の口座番
号の代用として渡す。このようにすると、顧客は、公共ネットワークを上で彼ま
たは彼女の真のクレジットカード番号を伝送する必要がなくなる。

【０００５】 前記―８１０号特許では、商人が取引番号を発行施設に渡すと、次に同施設は
この取引番号をインデックスとして使用し、顧客の真の口座番号にアクセスし、
承認作業を処理し、前記取引番号の下に、商人に承認応答を返送する。その結果
、顧客はただ取引番号を伝送するだけだからというばかりでなく、その代理番号
は単一の買い物にたいしてのみ有効であるために、リスクは意図的に極小にされ
る。窃盗は「ただ一回の盗みではあまり儲からない。なぜなら、それ（番号）は
、他の買い物や取引にたいして繰り返し使用することができないからである」と
ある。第２カラム、６０−６１行。

【０００６】 従来のシステムにたいする改善には要求がある。特に、各取引において、恒久
的口座番号の伝送に代わって、一意の、繰り返し生成される取引番号の創成・伝
送の必要を回避する、インターネット上の確実な金銭取引の実行を可能とする方
法およびシステムにたいしては要求がある。

【０００７】 ２００１年３月１５日登録の、同時係属中の出願第０９／８０９，３６７号―
引用することによって本申請書に含める―によれば、「偽似」口座番号が顧客に
割り当てられ、かつ、これは暗号的にその消費者の支払い口座番号にリンクされ
る。支払い口座番号は、財政施設またはその他の機関によって発行される口座番
号で、消費者は、それを用いて、品物および／またはサービスにたいする支払い
を実行することが可能になるものである。例えば、支払い口座番号は、クレジッ
トカードまたはデビットカードのような支払いカード、あるいは、消費者のコン
ピュータに保存される電子キャッシュアプリケーションのような支払いアプリケ
ーションに付属する口座番号であってもよい。この偽似口座番号は、商人にとっ
ては、実際の支払い口座番号のように見える。すなわち、この偽似口座番号は、
正当な支払い口座番号と同じ長さを持ち、かつ、正当な特定番号（例えば、Ｍａ
ｓｔｅｒＣａｒｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｉｎｃｏｒｐｏｒａｔｅｄ（
「マスターカード」）の場合には”５”）で始まる。この偽似口座番号は、顧客
により、彼または彼女のオンライン金銭取引の全てにおいて本当の口座番号の代
わりに使用される。

【０００８】 同時係属中の出願第０９／８０９，３６７号の発明によれば、偽似口座番号に
基づく全ての取引は、好ましくは、各口座番号に一意な秘密キーを用いて、暗号
的にその真実性が証明される。この真実証明は、公開キーペアにおける私的キー
に基づくものであってもよいし（「公開キー真実証明」）、あるいは、私的キー
以外の秘密キー（「秘密キー真実証明」）に基づくものであってもよい。従って
、無資格者が何かの偽似口座番号を確認することがあったとしても、それらを用
いて不正な取引をすることはできない。

【０００９】 さらに、同時係属中の出願第０９／８３３，０４９号の発明によれば、支払い
ネットワークを用いて取引を実行する方法が供給される。この方法では、サービ
スプロバイダーに入手者コードが割り当てられる。さらに具体的に言うと、サー
ビスプロバイダーは、第一支払い口座番号による取引承認を求める、第一承認請
求を受け取り、ここに、 （ｉ）前記第一支払い口座番号は、サービスプロバイダーに関連するＢＩＮコ
ードを持ち、かつ、前記第二番号の発行者と関連するＢＩＮコードを持つ、第二
支払い口座番号と関連し、 （ｉｉ）第一承認請求は、入手者と関連する入手者コードを含み、および、 （ｉｉｉ）第一承認請求は、第一支払口座番号のＢＩＮコードに基づいて、サ
ービスプロバイダーにたいして導通が可能である、ことを特徴とする。

【００１０】 この方法においてはさらに、サービスプロバイダーは、第一承認請求にたいし
、第二支払い口座番号による取引の承認を求める第二承認請求を伝送することに
よって応答することを含み、ここに、第二承認請求は、サービスプロバイダーと
関連する入手者コードを含み、かつ、発行者のＢＩＮコード（すなわち、第二支
払い口座番号のＢＩＮコード）に基づいて、支払いネットワークを通じて、発行
者にたいして導通が可能である。

【００１１】 さらに、第二承認請求にたいする応答は、発行者からサービスプロバイダーに
よって受容され、ここに、同応答は、サービスプロバイダーと関連する入手者コ
ードを含み、そのコードに基づいて支払いネットワークを通じて導通が可能であ
る。次に、第一承認請求にたいする応答は、第二承認請求にたいする応答に基づ
いて、サービスプロバイダーによって入手者に伝送され、かつ、第一承認請求に
たいする応答は好ましくは、入手者と関連する入手者コードを含み、そのコード
に基づいて支払いネットワークを介して導通が可能である。

【００１２】 同時係属中の出願第０９／８３３，０４９号の、別の好ましい実施態様では、
第二支払い口座番号と関連する第一支払い講座番号を用いて、商人と取引を実行
する方法が供給される。ここに、同法は、（ａ）１個以上の取引明細に基づくメ
ッセージ真実証明コードを生成し；（ｂ）商人にたいして、少なくとも第一支払
い口座番号とメッセージ真実証明コードを伝送し；（ｃ）商人の側から、第一支
払い口座番号を用いて取引支払いにたいする承認を請求し、ここに、請求は、あ
たかもその支払いが、従来の磁気ストライプ支払いカードによる売り場端末で処
理されるようにフォーマットされており、メッセージ真実証明コードは、従来の
支払いカードの磁気ストライプに使用される型のトラックに含まれる、自由選択
データフィールドに収められて伝送され；（ｄ）第一支払い口座番号に関する承
認請求にたいして、関連する第二支払い口座番号を用いてその取引の支払いにた
いする承認を請求することによって応答し、かつ、（ｅ）第二支払い口座番号と
メッセージ真実証明コードにたいする承認請求にたいする応答に基づいて、第一
支払い口座番号にたいする承認応答を受容するか、または、断るかすることを含
む。

【００１３】 このシステムはさらに改善が可能であり、かつ、公共通信ライン上で行われる
金銭取引の際に、または、それと関連して伝達されるメッセージや情報を保護す
るためにさらに安全性・効率を強化することも可能である。

【００１４】 （発明の概要） 従って、本発明によれば、公共通信ネットワーク上にて、偽似期限切れ日付を
使って口座番号による電子取引を実行する方法が供給される。好ましい方法は、 口座番号と関連する対カードキーを生成すること； 対カードキーを用いてメッセージ真実証明コードを生成すること； メッセージ真実証明コードを偽似期限切れ日付に変換すること； 取引にたいする承認請求を生成することであって、ここに、前記請求は偽似期
限切れ日付を含む期限切れ日付フィールドを持ち；および、 前記期限切れ日付に基づいてメッセージ真実証明を証明すること、を含む。

【００１５】 この好ましい方法はさらに、真実の期限切れ日付を有する口座番号の発行者を
含む支払いネットワークを含み、ここに、前記真実の期限切れ日付を含む第二承
認請求が生成され、かつ、前記第二請求は、取引の承認を求めて発行者に進めら
れることを特徴とする。

【００１６】 本発明の、一つのさらに詳細な実施態様は、関連偽似口座番号を持つ、支払い
口座番号を含み、かつ、下記の行程を含む。すなわち、 （ａ）支払い口座番号と偽似口座番号とを用いて、偽似口座番号と関連する対
カードキーをサービスプロバイダーが生成すること； （ｂ）前記対カードキーを含む、取引に使用される安全支払いアプリケーショ
ンを創成すること； （ｃ）対カードキーを用いてメッセージ真実証明コード（”ＭＡＣ”）を生成
すること； （ｄ）偽似口座番号とＭＡＣを含む安全支払いアプリケーションによってＭＡ
Ｃ真実証明請求を生成すること； （ｅ）ＭＡＣの真実証明をすること； （ｆ）前記真実証明に基づいて、ＭＡＣにたいして、予想取引順序番号（ＥＴ
ＳＮ）を創成すること； （ｇ）参照データ付き安全支払いアプリケーションを供給すること； （ｈ）前記予想取引順序番号と対カードキーを用いて、第二メッセージ真実証
明コードを創成すること； （ｉ）第二メッセージ真実証明コードを、参照データを用いて、偽似期限切れ
日付に変換すること； （ｊ）前記偽似期限切れ日付を含む期限切れ日付フィールドを持つ承認請求を
生成すること；および、 （ｋ）前記承認請求に応答し、かつ、偽似期限切れ日付に基づいて第二メッセ
ージ真実証明コードを証明すること、である。

【００１７】 本発明の別の実施態様によれば、公共通信ネットワーク上で電子取引を実行す
る方法であって、支払い口座番号が関連偽似口座番号を持つことを特徴とする方
法が供給され、前記方法は、下記を含む。すなわち、 （ａ）真実証明キー生成のために使用される、単数または複数のキー生成行程
を示すコントロールフィールドを持つ偽似口座番号を供給すること； （ｂ）前記偽似口座番号のコントロールフィールドに示される、複数のキー生
成行程の内の一つを用いて、前記偽似口座番号と関連する真実証明キーを生成す
ること； （ｃ）前記真実証明キーを用いて、取引にたいして特異的なメッセージ真実証
明コードを生成すること； （ｄ）メッセージ真実証明コードと偽似口座番号とを含む承認請求メッセージ
を生成すること；および、 （ｅ）前記示されたキー生成行程と真実証明キーとを用いて、メッセージ真実
証明コードを証明すること、である。

【００１８】 本発明のさらにもう一つの実施態様によれば、口座番号によって通信ネットワ
ーク上で電子取引を実行する方法であって、 口座番号と関連する対カードキーを生成すること； 前記対カードキーを用いてメッセージ真実証明コードを生成すること； 前記メッセージ真実証明コードを、異なるフィールドを持つ承認請求によって
、異なるやり方で進めるために、少なくとも二つの異なる動作モード供給するこ
と、を含み、ここに、動作モードの少なくとも一つは、メッセージ真実証明コー
ドを、期限切れ日付フィールドに進めるものであり、かつ、動作モードの少なく
とも一つは、メッセージ真実証明コードを、メッセージ真実証明コードフィール
ドに進めるものである。好ましくは、前記メッセージ真実証明コードは、メッセ
ージ真実証明コードフィールドが存在する場合には、自動的にそのメッセージ真
実証明コードフィールドに輸送される。

【００１９】 （発明の詳細な説明） 本発明は、インターネットのようなコンピュータネットワーク上において、確
実な支払いを実行するための方法およびシステムに向けられる。本発明は、同時
係属中の出願連番第０９／８０９，３６７号に開示される「真実」口座番号（す
なわち、発行施設によって発行される、実際のカード支払い口座番号）の代わり
に、「偽似」口座番号を利用する。

【００２０】 本発明はその利点として、インターネットにおける支払い口座番号の使用につ
いて強化された安全性を供給する。本発明によれば、偽似口座番号が盗まれても
、それら盗まれた偽似口座番号は、多くの状況下において、インターネット上で
不正取り引きを実行するの使用することはできない。なぜなら、偽似口座番号に
基づく取引は、各口座番号について一意な秘密キーを用いて暗号的に真実証明が
されるからである。この秘密キーは、ただ、カード保持者の安全支払いアプリケ
ーション（”ＳＰＡ”）内部、および、サービスプロバイダー施設の、本申請書
を通じてただ例示のために取り上げるのであるが、ＭａｓｔｅｒＣａｒｄ Ｉｎ
ｔｅｒｎａｔｉｏｎａｌ Ｉｎｃｏｒｐｏｒａｔｅｄ（「マスターカード」）施
設の高度に安全な装置の内部のみにあるからである。さらに、偽似口座番号は、
カード保持者の真実の口座番号を開示しないので、通常の売り場端末では拒否さ
れる可能性が高い。

【００２１】 本発明の例示の実施態様を示す、いくつかの図面が付属する。この付属の図面
と下記の説明において、マスターカードが、偽似口座番号を供給し、処理する実
体を示すために使用される。本申請書に使用される、関連略号は下記の通りであ
る。 ＢＩＮ―銀行特定番号 ＤＥＡ―データ暗号化アルゴリスム ＰＣ―消費者のパソコン装置 ＭＡＣ―メッセージ真実証明コード ＭＣＩ―マスターカードインターナショナルまたはマスターカード ＭＣＷＳ―マスターカード・ウェブサイト ＰＩＮ―個人特定番号 ＰＯＳ―売り場 ＳＰＡ―安全支払いアプリケーション ＳＳＬ―安全ソケット層（インターネット安全用） ＴＳＮ―取引連続番号

【００２２】 本発明の好ましい実施態様によれば、サービスプロバイダーは、本発明の技法
に従って実行される安全支払いシステムの安全支払いアプリケーション（”ＳＰ
Ａ”）を含む、いくつかの成分を発行し、維持し、および／または、処理する。

【００２３】ＳＰＡシステムの成分 好ましくは、ＳＰＡシステムは、既存の支払い処理操作（例えばマスターカー
ド）にたいして透明であり、かつ、既存の商人、入手者および発行者の各操作に
たいして透明であることが可能である。このシステムは好ましくは、３種のスタ
ンドアローン型成分を利用する。 １．１個以上のＳＰＡウェブサイト ２．カード保持者のＰＣ（またはその他のインターネットアクセス装置）用Ｓ
ＰＡウォーレット ３．ＳＰＡ承認／解除システム

【００２４】 簡単に言うと、ＳＰＡウェブサイトは、新規カード保持者を「登録する」のに
用いられ、さらに、モード１（下記に定義される）において、適当なＳＰＡ承認
／解除システムにたいして、承認請求メッセージを処理する前にそれが受領して
いなければならないデータを供給するのにも用いられる。

【００２５】 ＳＰＡウォーレットは、ＳＰＡ取引で使用するために、ＰＣ（またはそれと類
似のもの）にダウンロードされるソフトウェアである。これは、カード保持者が
アイコン上をクリックすることによって起動される。一旦起動されると、これは
、ソフトウェアと、ある任意のカードに特注されたデータとの結合体を用いて、
安全にインターネット支払いを実行する。

【００２６】 ＳＰＡ承認／解除システムは、ＳＰＡ取引を処理し、それを従来の取引に変換
する（かつ、ある場合には従来取引から変換する）、物理的コンピュータ装置で
あり、このような一つの装置が一人以上の発行者のサービスに与る。

【００２７】 ＳＰＡウェブサイトおよび／またはＳＰＡ承認解除システムはまた本申請書で
はサービスプロバイダーと呼ばれ、および／または、一人以上のサービスプロバ
イダーと関連する。

【００２８】ＳＰＡモード ４種のＳＰＡ操作モードが本システムによってサポートされる。そのモードと
は、 モード０：真実証明なし モード１：期限切れ日付フィールドによる真実証明 モード２および３：ＳＰＡ専用の新規フィールドによる真実証明

【００２９】 モード０および１の利点としては、既存の商人または入手者操作にたいして変
更を要求しない。モード２および３は、商人が、その支払い画面に新規フィール
ドを加え（好ましくは、カード保持者にたいしては表示されない秘密のフィール
ドで、カード保持者ＰＣのＳＰＡソフトウェアには見分けが可能なフィールド）
、かつ、このフィールドがＰＣによって満たされた場合、商人はこのフィールド
（未変更）を入手者に渡し、今度は入手者が、それを（未変更）承認を求めて支
払いシステムに渡すことを要求する。これは、他のシステムでは、ＩＣＣ関連デ
ータを輸送するのに用いられるのと同じフィールドである。

【００３０】 モード２はまた、商人がカード保持者との１回の取引の結果として第二承認請
求を一度でも送っている場合には、この第二の（およびその後の）承認請求メッ
セージは、期限切れ日付フィールドを持たないことを要求する。このような、そ
れ以後の承認請求メッセージは、メール注文・電話注文として考慮されて、保証
はされない。

【００３１】 モード３は、モード３が、商人は、期限切れ日付を持つ、その後の承認請求メ
ッセージを送ってはならないという上記要求を課さないという点を除いては、モ
ード２と同じである。モード３では、このようなその後の承認請求メッセージが
期限切れ日付を持っているか、いないかは関係がない。

【００３２】 モード２は、モード３が行わない制限を課するのであるから、モード２用「秘
密フィールド」の特定子は、（１）ＳＰＡ ＭＡＣフィールドとして使用可能な
秘密フィールドが存在すること、および、（２）商人は決して期限切れ日付付き
、後続承認請求メッセージを送ってはいないこと、という事実を搬送しなければ
ならない。モード３で使用可能な「秘密フィールド」はこの第二の制限を持たな
いがために、別の特定子を持つ。

【００３３】 モード３に好適なフィールドは、電子商取引用（例えば、電子商売で使用され
るＩＣＣ用）の全ての支払いシステムによって受容される「汎用」フィールドで
あってもよい。一方、モード２はこのような「汎用」フィールドを使用すること
はできない。なぜなら、このモードは、商人が後続承認請求メッセージには決し
て期限切れ期日を含めないということを「保証」した場合にのみ使用されるから
である。従って、モード２は、ＳＰＡ取引を受容するに当って特別な準備を行っ
た商人についてのみ使用が可能であるのにたいし、モード３では、全ての支払い
システムによって使用が可能となるよう、電子商取引に追加フィールドを備える
商人であればいずれの商人においても使用が可能である。

【００３４】 モード２または３は、モード０または１に比べて、前者がより効果的な真実証
明を与えるという点で好ましい。ＳＰＡは好ましくは、商人の支払い画面中に示
される「秘密フィールド」の存在によって、商人がモード２または３をサポート
する意図を見て取った場合を除いては、モード０または１で作動する。カード保
持者のＰＣ中のＳＰＡは、モード２または３においては常に、商人がこのモード
をサポートする場合に作動する。

【００３５】 好ましくは、カード保持者のＰＣは、三つの状態、「状態Ａ」、「状態Ｂ」ま
たは「状態Ｃ」の内の一つにおいて作動する。「状態Ａ」では、ＰＣはモード１
か２で作動するが（商人の能力に依存して）、モード０またはモード３では決し
て作動しない。「状態Ｂ」では、ＰＣは、モード１、モード２、または、モード
３で作動するが（この場合も商人の能力に依存して）、モード０で作動すること
は決してない。「状態Ｃ」では、ＰＣはモード０、モード２またはモード３（商
人の能力に依存して）で作動するが、モード１で作動することは決してない。Ｐ
Ｃは、ＳＰＡウェブサイトからの指令の下に、好ましくはこれらの状態間で切り
換えが可能である。

【００３６】 「状態Ａ」は、全ての取引がある程度の真実証明を持つという利点を有する。
「状態Ｂ」は、モード１の提供する真実証明をある程度低下させるが、「汎用」
追加フィールドを受容する全ての商人との取引について、実質的により高度の真
実証明が得られるという利点を有する。「状態Ｃ」は、大手の多くの商人が「汎
用」追加フィールドを備えた場合の将来の使用を意図したもので、ＳＰＡ承認シ
ステムに課される保存要求を相当に下げるが、この「汎用」追加フィールドを準
備しない商人にたいしては真実証明なしというコストを伴う。従って、次第に多
くの商人が「汎用」追加フィールドの受容を可能とはするが、ＳＰＡ独特のモー
ド２追加フイールドを受容できない場合、発行者は、そのＳＰＡウォーレット用
として、「状態Ａ」から「状態Ｂ」へ、さらに最終的に「状態Ｃ」への移行を実
行する。一つの状態から別の状態への移行は好ましくは発行者の選択であり、従
って、異なる発行者からのウォーレットは、異なる状態にあることが可能である
。

【００３７】ＳＰＡ特徴 前述のように、ＳＰＡは、カード保持者のカード上に見える「真実」口座番号
ではなく、偽似口座番号の使用に基づく。偽似口座番号と、対応する「真実」口
座番号との間には１対１対応がある。全てのモードにおいてＳＰＡによって同じ
偽似番号が用いられる。偽似口座番号のＢＩＮは、どのＭａｓｔｅｒＣａｒｄカ
ードにも刻印されていない「偽似ＢＩＮ」である。カード発行者当り一つの偽似
ＢＩＮがあるので、ある偽似口座番号の発行者は特定が可能である。偽似ＢＩＮ
の使用は、ある任意の取引の口座番号を、一つの偽似口座番号として特定する。
商人や入手者は全て、カード保持者を、偽似口座番号によって知っているが、発
行者は、カード保持者を「真実の」口座番号によって知っている。従って、ＳＰ
Ａシステムの機能の一つは、同時係属中の出願書にも記述される通り、二つの数
字の間を「移動する」ことである。

【００３８】 本発明によれば、ＳＰＡシステムのもう一つの機能は、ＳＰＡモード１、モー
ド２、または、モード３承認請求のそれぞれに随伴する、メッセージ真実証明コ
ード（”ＭＡＣ”）を証明することである。モード１の場合、本発明では、ＭＡ
Ｃは、偽似期限切れ日付の形を取り、真実証明される日付は、好ましくは、各モ
ード１取引毎に、ＳＰＡウェブサイトを介して搬送される。モード２または３の
場合は、ＭＡＣは、「ＭＡＣフィールド」、すなわち、全てのモード２／３取引
にたいして添加される、新規ＳＰＡフィールドの一部となる。真実証明される日
付も、このＭＡＣフィールドに含まれる。

【００３９】 同じＳＰＡが、異なるＰＣ上においてコピーを持つことができる。どのＰＣで
も、いくつかの異なるカードにたいしてＳＰＡウォーレットを持つことが可能で
ある。その場合、そのウォーレットは、異なるカード保持者による制御・使用が
可能である。

【００４０】ＳＰＡウェブサイト操作―カード登録 ＰＣにおいてカード保持者が、ＳＰＡにたいしてある任意のカードを登録した
いと思う場合には、彼／彼女は、ＰＣブラウザーを用いてＳＰＡウェブサイトに
接触する。（ＰＣではないウェブアクセス・デバイスも、本申請書に記載される
のと同じやり方で作動する。）ＰＣとＳＰＡウェブサイト間で伝達される全ての
データについてＳＳＬ暗号化が使用される。ウェブサイトは、自分が、既にロー
ドされたＳＰＡアプリケーションではなく、ブラウザーによってアクセスされた
ことを感じ取ると、好ましくは下記のように作動する。

【００４１】 ウェブサイトは、ＰＣにたいして初発画面を送る。この画面は、「真実」口座
番号か、または、そのカード保持者が既にそのカードを何かの（他の）ＰＣに登
録しているのであれば、偽似口座番号のいずれかを尋ねる。ＳＰＡウェブサイト
がその情報を一旦受容すると、そのＢＩＮを調べる。ウェブサイトは、発行され
た全ての偽似ＢＩＮのリストを保持しているので、先ず、その与えられた口座番
号のＢＩＮが、そのリストに載っているかどうかを確定する。載っている場合に
は、それは偽似口座番号であるし、そうでなければ、「真実」口座番号である。

【００４２】 ＢＩＮが「真実の」ＢＩＮを表わしている場合、ＳＰＡウェブサイトは、発行
者がＳＰＡに参加しているかどうかを確定する。ウェブサイトは、この作業を、
「真実」ＢＩＮを偽似ＢＩＮに関連づける第二テーブルを保持することによって
行い、かつ、このテーブル中に、問題の「真実」ＢＩＮに対応する記載を見出し
たならば、この発行者がＳＰＡに参加していることを承知する。この二つの状況
の内のいずれにおいても、ＳＰＡウェブサイトは、ＳＰＡウォーレットをこのカ
ードにたいして支給が可能であることを承知する。発行者がＳＰＡに参加してい
ない場合は、ＳＰＡウェブサイトは好ましくは、メッセージをカード保持者に送
り、彼／彼女に、今回はＳＰＡウォーレットは利用できない旨の通知をする。

【００４３】 ＳＰＡウェブサイトが、カード発行者がＳＰＡをサポートしていることを確定
した場合、ＳＰＡウェブサイトは第二画面を送る。この画面は好ましくは下記を
請求する。 １．カード期限切れ日付 ２．カード保持者名、住所および電話番号 ３．カード保持者が、その所有／コントロールするＰＣの前にいるかどうか ４．偽似口座番号ではなく、「真実」口座番号が、第一行程で供給された場合
、そのカード保持者が以前にＳＰＡ用にそのカードを登録したかどうか、 ５．カードが以前にＳＰＡにたいして登録されたことがある場合（前項にたい
して「イエス」によって、または、偽似口座番号の使用によって、示された場合
）、カード保持者が、その登録時に選択されたパスワードを記憶しているかどう
か、 ６．カードが以前にＳＰＡにたいして登録されたことがあり、かつ、カード保
持者がそのパスワードを覚えている場合（カード保持者が、質問第４を尋ねられ
、「イエス」と返答した場合）、その既に選択されたパスワード。

【００４４】 質問第５は、カード保持者が第一画面に偽似口座番号を入力した場合は必ず含
まれるが、質問第４は尋ねられない。その他の場合は質問第４は尋ねられ、その
質問に対してカード保持者が「イエス」と返答した場合は、質問第５が加えられ
る。質問第５が尋ねられ、「イエス」と返答された場合は、項目第６が加えられ
る。

【００４５】 これがこの口座番号にとって最初の登録である場合、または、カード保持者が
、前の登録時のパスワードを覚えていない場合には、ＳＰＡウェブサイトは、発
行者一意の真実証明用質問を搭載する第三画面をＰＣに送り、下記のような情報
を請求する。（１）カード保持者がメールで受け取った「ＳＰＡ登録コード」、
（２）カードの背に印刷されるＣＶＣ２、（３）カード保持者の社会保険番号（
または、その数字の一部）、（４）カード保持者の母親の結婚前の姓名。この第
三画面の内容は、好ましくは、発行者によって確定され、この発行者が選択した
真実証明情報にたいする請求を呈示する。この第三画面はまた、カード保持者が
パスワードを入力しなければならない場所を供給する。これは、カード保持者が
将来、ＳＰＡを活性化する際に、または将来、現在請求中のＳＰＡウォーレット
の発行が、カード発行者によって承認されると仮定して、別のＰＣ用にＳＰＡの
コピーを請求する際に使用しなければならないからである。注意しなければなら
ないことは、この口座番号に関してＳＰＡが既に存在する場合には、新規のＳＰ
Ａコピーを始めるためには、このパスワードが、以前のパスワードに取って代わ
らなければならないことである。さらに注意すべきことは、例えば、夫婦が同じ
口座番号を共同使用する場合には、その夫婦は同じ偽似口座番号を共有し、従っ
て、別のＰＣに新規ＳＰＡコピーを起動するためには同じパスワードを使用しな
ければならないことである。（しかしながら、夫／妻がこのパスワードを知らな
い場合には、真実証明質問に回答することによって、別のＰＣに新規ＳＰＡコピ
ーを起動してもよい。）

【００４６】 カード保持者からこの情報を受け取ると、ＳＰＡウェブサイトは、呈示された
口座番号のＢＩＮから、この偽似ＢＩＮにたいする承認請求を処理するＳＰＡ承
認システムのアドレスを確定する。これを実行するために、ＳＰＡウェブサイト
は、偽似ＢＩＮによってアクセスされるアドレス表を保持し、対応するＳＰＡ承
認システムのアドレス（単数または複数）を供給する。この決定を行ってから、
ＳＰＡウェブサイトは、カード保持者から入手した情報を、安全手段（例えば、
ＳＳＬ暗号化の下に）によって、このＳＰＡ承認システムに伝送する。ウェブサ
イトはこのデータのコピーを保持する必要はない。なぜなら、データは、ＳＰＡ
承認システムからウェブサイトに戻されるからである。

【００４７】 ＳＰＡウェブサイトとＳＰＡ承認システムとの間の通信方法は好ましくは、ダ
イアルアップテレフォン背景の下に、インターネットを介するものである。この
場合、アドレス表によって供給されるアドレスは、ＳＰＡ承認システムのインタ
ーネットアドレス、およびまたその電話番号である。別の可能性は、マスターカ
ード・バンクネットのような支払いネットワークを介するもので、この場合は、
「アドレス」は単に偽似ＢＩＮそのものである。

【００４８】 一旦ＳＰＡ承認システムが登録要求を受容すると、それが、示されたＢＩＮに
とって適正な施設であることを確認する。そうでない場合は、その登録請求を拒
絶し、そのようにＳＰＡウェブサイトに通知する。ウェブサイトがその応答を受
け取ると、ウェブサイト・オペレーターにメッセージを送り、カード保持者のＰ
Ｃに「お待ち下さい」のメッセージを送る。オペレータが、問題を速やかに（例
えば５分）解決できない場合には、ＳＰＡウェブサイトは、ＰＣにたいして、只
今このカードにたいしてＳＰＡウォーレットを供給することができない旨通知す
る。

【００４９】 ＳＰＡ承認システムが成功裡に登録を完了した場合には、安全手段によって、
好ましくは下記から成るメッセージをＳＰＡウェブサイトに送る。すなわち、 １．カード保持者の名前、住所および電話番号 ２．偽似口座番号 ３．カード期限切れ日 ４．「真実」口座番号の下４桁数字 ５．非可逆的に変形されたパスワード ６．カードキー用暗号化パスワード ７．ＳＰＡコピー数または単一セッション数 ８．ＳＰＡバージョン数 ９．ＳＰＡ単一セッションインディケーター １０．ＳＰＡ状態 １１．偽似ＢＩＮキーインディケーター １２．カード製品名（例えば、「マスターカード」、「マエストロ」、「マス
ターカード・キャッシュ」 １３．「真実」口座番号 １４．第１回ＳＰＡフラグ（１＝たった今確定されたばかりの新規偽似口座番
号）

【００５０】 ＳＰＡ承認システムはさらに、回答をカード保持者ＰＣに経路導通させるため
に、ＳＰＡウェブサイトが要求する情報はそれが何であれ全て戻す。

【００５１】 このメッセージを受け取ると、ＳＰＡウェブサイトは、そのＳＰＡバージョン
数に相当するソフトウェアと共に、上記の項目１から１２までをＳＰＡウォーレ
ットに収める。このウォーレットにはさらに、モード１およびモード２／３取引
連続番号、および、パスワード失敗カウンター用にゼロの初期値が含まれる。次
に、ＳＰＡウェブサイトは、このＳＰＡデータをカード保持者ＰＣに伝送し、Ｐ
Ｃにデータは保存される。

【００５２】 ＳＰＡは、ＳＰＡを搭載したそのＰＣにて使用が可能なカードのメニューを供
給する。ＳＰＡは好ましくは、ＰＣ画面の一列において、各カードに関して下記
の情報を供給する。 １．カードの偽似口座番号 ２．ＳＰＡコピー数（これが単一セッションＳＰＡでない場合） ３．カードの「真実」口座番号の下４桁数字 ４．カードの期限切れ日付 ５．カード保持者の名前 ６．カード製品名（例えば、「マスターカード」、「マエストロ」、「マスタ
ーカード・キャッシュ」

【００５３】 新規ＳＰＡウォーレットがＰＣのＳＰＡに加えられる度毎に、その新規のカー
ドがこのメニューリストに加えられなければならない。カードは、ＳＰＡにたい
して登録された順番に、第一登録が第一順位として、列挙される。このリストは
、カード保持者によって、現在取引用のカードを選択するのに使用される。前述
したように、各カードには、ある特定のソフトウェアセットが関連する（ただし
、同じバージョン数を持つ２枚のカードは、同一ソフトウェアを使用する）。注
意すべきことは、多くの場合、別のＳＰＡがこのＰＣにインストールされること
は決してなく、従って、このリストには単一のカードしかないことである。

【００５４】 これでカード保持者はＳＰＡ取引を実行できることになる。

【００５５】ＳＰＡ承認／解除システム 上に簡単に述べたように、ＳＰＡに参加するカード発行者は全て、１個の「一
次」ＳＰＡ承認／解除システムによるサービスを受ける。この場合、要すれば、
このシステムは、複数の発行者にサービスを提供することが可能である。フル稼
働のＳＰＡシステムの場合、少なくとも１個の「バックアップ」ＳＰＡ承認／解
除システムがあって、このシステムが、一次システムが利用できない場合（例え
ば、故障）はいつでも使用されるようになっていてもよい。「バックアップ」Ｓ
ＰＡ承認／解除システムを使用すると、ＳＰＡ取引は完了されるが、（一過性に
）安全性の質が低下する。

【００５６】 複数の発行者にサービスを提供するＳＰＡ承認／解除システムはそれぞれ好ま
しくは、１個以上の専用サーバーを介してＭａｓｔｅｒＣａｒｄ’ｓ Ｂａｎｋ
ｎｅｔのような支払いシステムに接続される。このシステムは、Ｂａｎｋｎｅｔ
を通じて承認請求メッセージや解除メッセージを受容し、また、Ｂａｎｋｎｅｔ
を通じて発行者と接触する。このようなシステムが好ましくは、そのサポートす
る発行者にたいして完全に透明なやり方で作動する。

【００５７】 ＳＰＡ承認／解除システムの、単一発行者バージョンも利用が可能である。そ
のようなバージョンは、直接、発行者の処理システムに接触する。このバージョ
ンは、発行者の側に若干のプログラム再修正を要求する。その修正プログラムは
、ＳＰＡ取引をその偽似ＢＩＮ（単数または複数）によって認識し、かつ、それ
らの取引をＳＰＡ承認／解除システム（例えば、サービスプロバイダー）に通じ
て、それによって、偽似口座番号から「真実」口座番号への変換、および、ＭＡ
Ｃ真実証明（承認請求メッセージのみ）を実行させるようになっていなければな
らない。

【００５８】 単一発行者ＳＰＡ承認／解除システムのもう一つのバージョンは、発行者のＭ
ＩＰとユーザーの処理装置の間にインストールされてもよい。このシステムは、
発行者にたいして透明であることは可能であるが、ＭＩＰに出入りする全てのト
ラフィックは、このＳＰＡシステムを通過しなければならない。

【００５９】 最後に、ある発行者にたいする承認機能と解除機能は、同じ物理的なボックス
によって実行される必要はない。発行者は、その承認請求メッセージを、その発
行者にたいしＢａｎｋｎｅｔを介して接触するＳＰＡ承認システムに処理させ、
一方、その解除メッセージの方は、会員の処理システムに直接接続する、単一発
行者ＳＰＡ解除システムによって処理させてもよい。

【００６０】 最初は、比較的小数のＳＰＡ承認／解除システムしか無いかも知れない。次第
にたくさんの発行者が、または、発行者グループが、自分達のＳＰＡ承認／解除
システムを持つことを選択するにつれて、元のシステム（たくさんの発行者にサ
ービスを提供する）から適当なデータを、新規のシステム（一人だけの、または
、少なくとも元のよりは数少ない発行者にサービスを提供している）へ転送する
備えを用意しなければならない。偽似口座番号はそれがいずれのものであれ、好
ましくは、ただ一つのＳＰＡ承認システムからのサービスだけを受ける。従って
、この転送は、転送の時点で進行中のいずれの取引にたいしても、それにたいす
る障害を最小としながら実行可能となっていなければならない。

【００６１】偽似口座番号 一つの「真実」支払い口座番号にたいして、それと関連する偽似口座番号は、
好ましくは長さが１６桁数字である。この１６桁偽似口座番号は、この口座番号
専用の、６桁ＢＩＮから始まる。ＢＩＮは、任意の銀行、または、サービスプロ
バイダー連合の任意の会員にたいして一意であってもよく、また、会員内部の、
任意の製品（例えば、ゴールドカードや、組合カード等）にたいして一意であっ
てもよい。

【００６２】 ＢＩＮの直後の２個の数字（または要すれば１個の数字）は、「コントロール
フィールド」として予約されていてもよい。このフィールドは、この偽似口座番
号と共に使用されるアルゴリスム等を示すものである。

【００６３】 チェック桁は偽似口座番号に適正であるから、これにより、約７桁、または要
すれば８桁が残されることとなり、従って、各ＢＩＮは、各コントロールフィー
ルド値について、最大１千万（または１億）の口座番号を表わすことが可能にな
る。

【００６４】 この偽似口座番号構造により、発行者をＢＩＮによって一意に特定することが
可能となるから、発行者は、（１）「手前共の」取引を特定し、かつ、（２）自
分と双方向合意のある他の発行者を特定することが可能となる。後述するように
、プログラム修正や、適当な安全モヂュールを入手することに積極的な発行者は
、自分達自身の真実証明を実行することが可能となるから、「手前共の」取引も
、ある種の他施設の取引も一緒に、その施設自身で実行することが可能になる。
このため、その取引をサービスプロバイダー（またはマスターカードＳＰＡ施設
）に送る必要が無くなる。

【００６５】 好ましくは、偽似口座番号のチェック数字を除く右側７（または８）桁数字は
、左側６桁数字によって特定される施設内部の、特定の口座を特定する示数であ
る。最初は（コントロールフィールド値によってそう指示されるなら）、この示
数は、全施設に共通であってもよい。ＢＩＮ当り、多数の７桁数字（または８桁
数字）組の示数値が、コントロールフィールドにおいて異なる数字を用いること
により利用可能になる。これらの口座番号示数値は好ましくは、サービスプロバ
イダー、この場合は、ＭａｓｔｅｒＣａｒｄによって割り当てられる。その数値
は、順番に（各施設毎に）または、ランダムに割り当てられてもよい。別法とし
て、順番に割り当て、次に暗号化して（ランダム性を持つ７または８桁十進数字
にする）、偽似口座番号として含めてもよい。

【００６６】 口座番号示数値をランダムに割り当てる、または、それら順番に割り当ててか
ら、暗号化して偽似口座番号に含めることの利点は、敵（例えば、不正行為をた
くらむ人々）が、正当な偽似口座番号を「推量」するのをより困難にすることで
ある。もしも口座番号示数を順番に割り当てられたとすると、敵にとって、使用
可能な偽似口座番号を、すなわち、自らに割り当てられた偽似口座番号よりも少
ない偽似口座番号を、または、少し大きいものを「推量」することがごく簡単に
なるからである。ある施設にとって可能な数値の内比較的少数（例えば＜１０％
）しか割り当てられていない時期に、ランダムに割り当てられた、または、暗号
化された口座番号示数を用いることによって、敵が、正当な口座番号示数値を「
推量」することのできるチャンスは、僅かに１０の内約１に過ぎなくなる。これ
は、敵が、不正に使用することを可能にする偽似口座番号を発見することをより
難しくする。

【００６７】 発行者が、偽似口座番号付き取引について自身の処理を実行したいと思う場合
には、サービスプロバイダーにより、数字順に配した全ての偽似口座番号で、各
「真実」口座番号に対応するもののリストを与えられてもよい。この偽似口座番
号が実際の示数を含む場合には、サービスプロバイダーは、発行者に、表示順に
配した「真実」口座番号のみを与える必要がある。偽似口座番号が暗号化口座番
号示数値を含む場合には、サービスプロバイダーは要すれば、発行者に（発行者
に一意な）複合化キーを与え、次に、「真実」口座番号を表示順に与えることも
可能である。恐らく、サービスプロバイダーは発行者に、逆行テーブル（発行者
が、偽似から「真実」への口座番号翻訳を実行する各取引毎に、偽似口座番号を
保存する際に要するものと同様の）を与える必要はない。しかしながら、発行者
に逆行テーブルを与える必要のある場合には、そのテーブルは、発行された偽似
口座番号にたいする各「真実」口座番号と、それに続けて対応偽似口座番号を数
値順にリストすることになる。

【００６８】 いずれにしろ、サービスプロバイダー施設は、偽似口座番号を「真実」口座番
号へ変換し、かつ、「真実」口座番号を偽似口座番号へ変換する能力を付与する
テーブルを維持する。

【００６９】カードの真実証明キー演算 カードに一意な真実証明キーは、偽似口座番号と、対応する「真実」口座番号
の暗号化処理に基く。そこにおいて中間ＢＩＮ一意のキーが生成される行程が望
ましい。なぜなら、国立ＳＰＡ施設によって、また、自身ＳＰＡ取引の証明を実
行したいと思っているカード発行者によって利用される場合に備えられるからで
ある。このようにして、全国規模の施設でも、偽似口座番号ＢＩＮ当りただ一つ
のキーを与えられるだけでよく、自身真実証明を実行する発行者も、（例えば）
一千万の偽似口座番号当り１個のキーを貰うだけですむ。仮に一つの国立ＳＰＡ
施設のキーが危機に瀕したとしても、他の国々の安全が脅かされることはない。
一つの発行者のキーが危機に頻したとしても、他の発行者の安全は脅かされない
。

【００７０】 任意の偽似口座番号と共に使用されるキー生成行程は、その偽似口座番号のコ
ントロールフィールドによって示されてもよい。前記目的を実行するために可能
なキー生成行程は下記のようなものである。すなわち、中央ＳＰＡ施設のみが、
「真実証明キー誘導キー」と呼ばれる、極秘の３倍長ＤＥＡキーを保持する。あ
る任意の偽似口座番号にたいする対カードキーを創成するために、この中央ＳＰ
Ａ施設（例えば、マスターカードＳＰＡ施設）の安全モヂュールによって実行さ
れる好ましい行程は下記の通りである。 １．６４ビットフィールドにおいて、各４ビットの、６個の二進コード十進数
字と考えられる偽似口座（ＢＩＮ）の内、左側６桁数字を左に揃え、かつ、右側
にゼロを並べよ。２４バイトの真実証明キー誘導キーの左側８バイトを暗号化キ
ーとして用いて、これら６４ビットをＤＥＡ暗号化せよ。 ２．前記２４バイト真実証明キー誘導キーの中央８バイトを復号化キーとして
用いて、行程１の結果をＤＥＡ復号化せよ。 ３．前記２４バイト真実証明キー誘導キーの右側８バイトを暗号化キーとして
用いて、行程２の結果をＤＥＡ暗号化せよ。 ４．行程３の結果を、一意な１６バイト対ＢＩＮキーの左側８バイトとして使
用せよ。 ５．６４ビットフィールドにおいて、各４ビットの、６個の二進コード十進数
字と考えられる偽似口座番号（ＢＩＮ）の内、左側６桁数字を左に揃え、かつ、
右側に二進の１を並べよ。２４バイトの真実証明キー誘導キーの左側８バイトを
暗号化キーとして用いて、これら６４ビットをＤＥＡ暗号化せよ。 ６．前記２４バイト真実証明キー誘導キーの中央８バイトを復号化キーとして
用いて、行程５の結果をＤＥＡ復号化せよ。 ７．前記２４バイト真実証明キー誘導キーの右側８バイトを暗号化キーとして
用いて、行程２の結果をＤＥＡ暗号化せよ。 ８．行程７の結果を、一意な１６バイト対ＢＩＮキーの右側８バイトとして使
用せよ。 ９．１６桁「真実」（偽似ではない）口座番号（二進コードの十進数字で、右
揃えされ、かつ、１６桁よりも少ない場合には左に二進のゼロを並べたものと考
えられる）を、ＤＥＡ暗号化キーとして行程４の結果（対ＢＩＮキーの左側８バ
イト）を用いて暗号化せよ。 １０．行程８の結果（対ＢＩＮキーの右側８バイト）をキーとして用いて行程
９の結果を復号化せよ。 １１．行程４の結果（対ＢＩＮキーの左側８バイト）をＤＥＡキーとして用い
て行程１０の結果を暗号化せよ。 １２．行程１１の結果を対カードキーの左側８バイトとして使用せよ。 １３．「真実」口座番号の右側１６桁（二進コードの十進数字で、右揃えされ
、かつ、１６桁よりも少ない場合には左に二進のゼロを並べたものと考えられる
）に二進パターン０１０１０１０．．．を並べ、次に、ＤＥＡキーとして行程４
の結果（対ＢＩＮキーの左側８バイト）を用いて暗号化せよ。 １４．行程８の結果（対ＢＩＮキーの右側８バイト）をＤＥＡキーとして用い
て行程１３の結果を復号化せよ。 １５．行程４の結果（対ＢＩＮキーの左側８バイト）をＤＥＡキーとして用い
て行程１４の結果を暗号化せよ。 １６．行程１５の結果を対カードキーの右側８バイトとして使用せよ。

【００７１】 中央ＳＰＡ施設が、あるカード保持者のＰＣ用にＳＰＡを創成する際、そのア
プリケーションの中に対カードキー（行程１２と１６から）を、そのアプリケー
ションの通常操作時には開示されないやり方で含ませる。

【００７２】 メッセージ真実証明コード付き取引において偽似口座番号を受け取ると、ＳＰ
Ａ施設はその「真実」口座番号を確定し、次に、ＭＡＣを証明するために必要な
キーを創成するために、前記１６個の行程を実行する。

【００７３】 ＳＰＡ施設が、国立ＳＰＡ施設または発行者の安全モヂュールの中に保持され
るべきキーを創成する必要のある場合には、その国にたいして一意な各ＢＩＮに
ついて、または、その発行者のＢＩＮについて、前記行程１から８までを実行す
る。次に、これらのキーは、国立ＳＰＡ施設の、または、発行者の安全モヂュー
ルに確実に配送され、こうしてその各キーは、それを創成するために使用された
偽似口座番号ＢＩＮ（およびコントロールフィールド）に関連付けられる。次に
、この安全モヂュールは、それが、偽似口座番号、「真実」口座番号、ＭＡＣ、
および、指定コントロールフィールド付きで受け取った各取引毎に、先ず、偽似
口座番号ＢＩＮによって指示されるキーを選択し、次にこのキーを対ＢＩＮキー
として用いて前記行程９から１６までを実行して、ＭＡＣを証明するためのキー
を創成する。

【００７４】ＳＰＡ起動 次に、図を参照しながら特異的ＳＰＡ起動を説明する。図１は先ず、金銭取引
カードを所持するカード保持者が、本発明の実施態様に従って、インターネット
上で、ＳＰＡウェブサイトまたはサービスプロバイダーから、安全支払いアプリ
ケーションを入手する様子を描く。最初に、本発明の利点を利用・享受するため
には、物理的カードは必要ではなく、ユーザーまたは参加者を特定し、彼／彼女
を、金銭取引実行のために口座に結びつける口座番号のみが、保持者（この場合
はカード保持者）にたいして発行されることを理解しなければならない。カード
保持者は、コンピュータ、携帯電話または電子秘書（ＰＤＡ）のような、インタ
ーネット上で通信が可能な適当な装置を使って、サービスプロバイダーと関連す
るウェブサイトに接触してもよい。下記の議論では簡単のために、カード保持者
は、インターネット上で通信するためにコンピュータを使用するものと仮定する
。

【００７５】 図１に示す様に、サービスプロバイダー、例えばＭａｓｔｅｒＣａｒｄ Ｉｎ
ｔｅｒｎａｔｉｏｎａｌ Ｉｎｃｏｒｐｏｒａｔｅｄ（すなわち、マスターカー
ドの代理店）は、１個以上の物理的に安全なモヂュール１２を支配下に置いてお
り、これらモヂュールは、モヂュール内に保存された情報にたいする物理的保護
を提供する。これら安全モヂュールは各々１個以上の「誘導キー」を含むが、こ
のキーは、後述するように、安全支払いアプリケーションの内部に供給される、
口座一意的秘密暗号キー（対カードキー）を創成・再創成するのに使用される。

【００７６】 先ず、本発明の好ましい実施態様によれば、カード保持者は、サービスプロバ
イダーからＳＰＡを入手しなければならない。安全支払いアプリケーション（Ｓ
ＰＡ）をダウンロードして起動するための好ましい行程としては、 １．カード保持者は、インターネットを介してサービスプロバイダーのウェブ
サイトに接触する（直接に、または、別のウェブサイト、例えば、発行者のウェ
ブサイトからハイパーリンクを通じてそのウェブサイトへ）。 ２．カード保持者は、当事者には一般に既知のＳＳＬ暗号化の下に、（ａ）支
払いカード口座番号、（ｂ）カード期限切れ日付、および、（ｃ）カード真実証
明情報を供給する。カード真実証明情報は、例えば、前述したように、カードの
ＣＶＣ値、すなわち、ある種のカードの署名パネルの隣にプリントされる３から
４個の数値を含んでいてもよい。この数値は、秘密の暗号化キーを用いて、発行
銀行によって生成されるが、その同じキーを用いて証明することが可能である。 ３．サービスプロバイダーは、カード口座番号とカード期限切れ日付の合法性
を、カード保持者の支払いカードの発行者からゼロ額承認を入手することによっ
て確認してもよい。例えば、マスターカードは、Ｂａｎｋｎｅｔ通信ネットワー
クを介してこのような承認を入手することが可能である。 ４．サービスプロバイダーは、カード保持者の支払いカードの発行者が、その
サービスプロバイダーに、ＣＶＣ２数値を証明するための暗号キー（単数または
複数）を支給してくれた場合、そのＣＶＣ２値を証明してもよい。 ５．サービスプロバイダーは、他のカード証明情報を、その情報を、証明のた
めに、発行者に送ることによって証明してもよい。このことをやり易くするため
に、サービスプロバイダーのウェブサイト、または、例えばＭＣＷＳは、ＳＰＡ
用登録時に、消費者に尋ねる項目のリストを維持していてもよい。そのような項
目のリストとしては、 項目番号 項目説明 ０１ ＣＶＣ２ ０２ ＰＩＮ ０３ 母親の結婚前の姓名 ０４ この口座における最終請求額 ０５ 請求書の宛名の市街名 ０６ 社会保険番号の下４桁数字

【００７７】 発行者は、消費者が、発行者によって発行される口座番号を、サービスプロバ
イダーに登録する際に、サービスプロバイダーにどのデータを供給してもらいた
いかを指定することが可能である。発行者は、あるＢＩＮ（製品）とは異なる別
のＢＩＮを取り扱いたい場合には、ＢＩＮ毎に別々のデータ項目を指定してもよ
い。サービスプロバイダーのウェブサイトは質問を選び、消費者に返答を促す。
結果は、ゼロ額承認請求の一部として発行者に供給される。

【００７８】 ６．サービスプロバイダー（”ＳＰ”）は、カード保持者の供給したデータの
合法性を確認した後、偽似口座番号と秘密キーとを創成または選択し、これらの
データ要素を、安全支払いソフトウェアアプリケーション中に組み込む。このア
プリケーションは、インターネットにおいて、好ましくはＳＳＬ暗号化の下に、
カード保持者により、彼／彼女のＰＣにダウンロード用に利用可能とされる。

【００７９】 偽似口座番号は、そのＢＩＮとして、偽似口座番号用に予約された、特別ＢＩ
Ｎを有する。偽似口座番号の残りは、サービスプロバイダーによって、テーブル
参照行程を経て、「真実」口座番号および、それと関連する期限切れ日付に翻訳
されることが可能な数値である。チェック数字は、偽似口座番号において適正で
ある。

【００８０】 好ましくは、割り当てられる特別サービスプロバイダーＢＩＮは、たくさんの
そのような特別ＢＩＮから成る一組から選ばれたものであってもよく、その組に
おいて、各ＢＩＮは、ある特定の銀行または特定の国または地域、あるいは、あ
る国または地域内部の特定の製品に対応するものであってもよい。

【００８１】 サービスプロバイーダーがＳＰＡに埋め込むことが好ましい、秘密の対カード
キーは、各カード口座番号にたいして一意であり、好ましくは、カード口座番号
と誘導キーを用いて安全モヂュール内部で導出される。（この行程は下記でさら
に詳述する）。導出キーそのものも、さらに高いレベルの導出キーを用いて、同
じまたは別の安全モヂュールから導出されてもよい。

【００８２】 カード保持者は、安全支払いアプリケーションをダウンロードする前に、パス
ワードをサービスプロバイダーに供給してもよいし、あるいは、安全支払いアプ
リケーションがカード保持者のコンピュータにイントールされる際にパスワード
を選んでもよい。パスワードが供給または選択されると、カード保持者は、彼ま
たは彼女のＰＣ上で安全支払いアプリケーションを起動するためには、そのパス
ワードを入力することを要求される。

【００８３】 当業者ならば認識されるように、サービスプロバイダーは定期的にＳＰＡを更
新し、かつ、そのＳＰＡを、ディジタルウォーレット・アプリケーションの一部
としてダウンロード可能としてもよい。ＳＰＡに加えて、ディジタルウォーレッ
トも下記の内の１個以上を保存してもよい。すなわち、カード保持者の個人情報
；パース（手持ち額）アプリケーション；デット（負債）アプリケーション；消
費者対消費者アプリケーション；および、その他のアプリケーションであって、
これらは全てＳＰＡの下に安全保証される。

【００８４】ＳＰＡウォーレット操作―初回セッション起動 ＰＣ中のＳＰＡは、カード保持者が、彼／彼女のＰＣ画面上に表示されるＳＰ
Ａアイコンをクリックすると起動される。始めて起動された場合（初回インスト
ール後、または、前に閉じられて後）、ＳＰＡによって実行される最初の作業は
、カード保持者にたいして、ＳＰＡカード（以前にそれにたいしてＳＰＡウォー
レットが入手されているカード）の全リストを表示し、カード保持者に、当面の
取引に彼／彼女が使いたいと思うカードの選択を促すことである。

【００８５】 複数のカード保持者が一つの共通のＰＣを共有してもよいことに注意しなけれ
ばならない。このため、カード保持者名は、各ＳＰＡカードに関する表示情報の
一部となり、また、各カードは、それ自身の、カード保持者選択のＳＰＡパスワ
ードを有する。

【００８６】 カード保持者が、この共通リストから一枚のカードを選択したならば、ＳＰＡ
は、好ましくは、このカードに関するパスワード失敗カウンターを検査する。こ
のカウンターが、ＳＰＡ内部閾値を越えた場合は、このＳＰＡカードでは、不成
功に終わったパスワード入力試行が過度の数行われており、再登録しなければな
らないことをカード保持者に通知する。次に、ＳＰＡは二つの選択肢、「再登録
」または「キャンセル」を表示する。カード保持者が前者を選択した場合、ＳＰ
ＡはＳＰＡウェブサイトに接触し、中断してブラウザーと交代する。カード保持
者が後者を選んだ場合、ＳＰＡは単純に中断する。

【００８７】 ＳＰＡが、選択されたカードにたいするパスワード失敗カウンターが指定の閾
値を越えていないと判断した場合、カード保持者は、そのカードにたいするパス
ワードを入力するよう督促される。これは、ＳＰＡがこのカードにたいして始め
て適用された際に彼／彼女が選択したパスワードである。カード保持者がパスワ
ード入力を完了すると、ＳＰＡはこのパスワードを非可逆的に変形して、それを
、ＳＰＡ保存数値と比較する。厳密な照合が見られない場合、ＳＰＡは、このカ
ードにたいするパスワード失敗カウンターを進め（これはＳＰＡによってセーブ
されており、従って、ＳＰＡが起動される際に非ゼロ値を持っていてもよい）、
パスワードの再入力を促す。この行程が、パスワードが適正に入力されるまで、
または、パスワード失敗カウンターが指定の値に達するまで、繰り返される。こ
の後の場合、ＳＰＡは、パスワード失敗カウンターの現在数値をセーブし、カー
ド保持者に、前述の「再登録」または「キャンセル」選択肢を与えた後で中断す
る。カード保持者が、適正なパスワードを入力することに成功せずＳＰＡを非活
性化した場合、ＳＰＡも、パスワード失敗カウンターの現在数値をセーブする。

【００８８】 非可逆的変換された、カード保持者入力のパスワードと、ＳＰＡ内部に保存さ
れる数値との間に厳密な適合が起これば、ＳＰＡはパスワード失敗カウンターを
リセットし、好ましくはこの証明されたばかりのパスワードを暗号キーとして用
いて対カードキーを復号化する。次に、ＳＰＡはカード保持者の住所と電話番号
を表示し、「あなたの住所と電話番号は変わりましたか？」と尋ね、「イエス」
と「ノー」ボタンを供給する。「イエス」をクリックすると、カード保持者に、
住所および／または電話番号の訂正を可能とするウィンドーが表示される。

【００８９】 ＳＰＡ次に今選択されたばかりのカードの期限切れ期日を調べ、カードが既に
期限切れか（ＰＣのクロックに基づいて）、または、次の３０日以内に期限切れ
になるかを確定する。そうだとすると、ＳＰＡは、カード保持者に、彼／彼女は
このカードの新規コピーを受け取っているかどうかを尋ね、もしそうなら、新規
カードの期限切れ期日をキーで入力して下さいと頼む。（カード保持者は、「ノ
ー」と言う選択肢を持つ。）これでＳＰＡは、この選択されたばかりのカードに
ついて取引を処理する態勢を整えた。

【００９０】ＳＰＡ動作 前述したように、安全支払いアプリケーション（”ＳＰＡ”）は、支払い取引
について、下記を含む、異なる動作モードを有していてよい。すなわち、 １．期限切れ日付フィールドのみを用いる真実証明 ２．追加フィールドを用いる真実証明

【００９１】 モード２は、商人が取引において追加フィールドを受容可能な場合に使用され
るもので、本申請書では「ＭＡＣフィールド」と呼ばれる。これは、モード１よ
りも高度の真実証明を与えるので、実行可能な場合は何時でも使用される。商人
は、ＰＣ中のＳＰＡにたいして、ＰＣによって記入されてもよいデータフィール
ド中にＭＡＣフィールドを含めることによって、ＳＰＡがモード２適合性である
ことを示さなければならない。（これは、秘密フィールドであってもよく、その
場合、カード保持者に表示されない。）ＰＣがＳＰＡ実行可能の場合は必ず、上
記商人は全て、このＭＡＣフィールドを入手者に渡し、従って、そのフィールド
を供給することが可能となっていなければならない。

【００９２】 ＰＣが商人画面にＭＡＣフィールドを見つけることができない場合は、ＰＣは
モード１に従って動作する。

【００９３】 下記の説明は、実施例によって、この二つのモードにおけるＳＰＡの好ましい
動作状態を記述する。

【００９４】 カード保持者のＰＣ（またはその他の装置）がそれを通じてＳＰＡを入手する
登録行程は下記の通りである。カード保持者のＰＣによって受容されるＳＰＡソ
フトウェアは両動作モードをサポートする。各モードにたいして、別々の取引連
番が使用される。すなわち、モード１にたいしては一方が、モード２にたいして
他方が使われる。両方とも”０”に初期化され、各モード１およびモード２の取
引毎に別々に進む。

【００９５】モード１―期限切れ日付フィールドのみを使用する真実証明 モード１では、承認請求メッセージの期限切れ日付フィールドが、ある形式の
ＭＡＣを搬送するのに使用される。この「偽似」期限切れ日付は、全ての期限切
れ日付同様、ＭＭＹＹにフォーマットされる。好ましくは、今日の市場における
多くの、または、全ての商人の現時処理システムと共に動作するよう、その偽似
期限切れ日付は、次の４８ヶ月以内に入るものでなければならない。

【００９６】 モード１取引連番は、２０個の二進ビットから成り、各モード１取引毎に進め
られる。従って、２^２０＝１百万回のモード１取引が起こるまでは、全部が１か
ら全部がゼロへとサイクルしない。このフィールドの左に、４ビットから成る「
バージョン数」がある。これは、ある任意の口座番号用ＳＰＡが滞在する各ＰＣ
にたいして一意の数字である。

【００９７】 前述のように、ＳＰＡウォーレットは現在表示の画面を調べ、それがＭＡＣフ
ィールドを置くことのできる「秘密フィールド」を探す。そのようなフィールド
を見つけると、後述のようにモード２またはモード３に進む。

【００９８】 ＳＰＡがそのフィールドを見つけられない場合、前の取引のために使用したの
と同じ言語を用いて、それが「理解」できるフィールド、すなわち、「名前」、
「住所」、「電話番号」、「カード番号」および「カード期限切れ日付」を探す
。これらのフィールドの多くが見つからない場合、ＳＰＡは、カード保持者に画
面の言語を選択するように請求する。カード保持者によって選択された言語が、
ＳＰＡが前に使用していたものと違っている場合は、ＳＰＡは試行を繰り返す。
ＳＰＡが全然または僅かしかフィールドを特定できない場合、カード保持者に、
商人支払い画面が本当に存在しているかどうか確認するように尋ねる。（カード
保持者のＳＰＡの起動が速すぎることがあり得るからである。）カード保持者が
「ノー」を示した場合は（商人支払い画面が表示されていない）、ＳＰＡは中断
し、制御を以前に走っていたプログラムに戻す（恐らくはブラウザー）。

【００９９】 カード保持者が「イエス」を示した場合（支払い画面が表示されている）、ま
たは、ＳＰＡが、商人支払いフィールドの多くまたは全てを特定可能な場合は、
ＳＰＡは自動的に、その特定可能なフィールド（いくらかでもあればその全てを
）を埋める。次にＳＰＡは、ＳＰＡウェブサイトに送るべきメッセージを準備す
る。ＰＣとＳＰＡウェブサイト間の通信は全て（いずれの方向でも）、ＳＳＬ暗
号化を用いて保護されていなければならない。このメッセージは下記のものから
成っていてもよい。すなわち、 １．偽似口座番号（１６個の十進数字として） ２．偽似ＢＩＮキーインディケーター（８ビット） ３．ＳＰＡ状態インディケーター（１ビット：０＝「状態Ａ」、１＝「状態Ｂ
」｛「状態Ｃ」にはモード１取引は無い｝） ４．ＳＰＡバージョン番号（１５ビットとして）。このフィールドは、ＳＰＡ
タイプ（クレジット、デビット、プリペイド）、および、このタイプの改訂番号
を示す。クレジットカードＳＰＡの場合、改訂０、ＳＰＡバージョン番号は十六
進数００００である。 ５．単一セッションＳＰＡインディケーター（１ビット：０＝正常ＳＰＡ、１
＝単一セッションＳＰＡ） ６．ＳＰＡコピー数または単一セッション数（１０ビットとして） ７．最後に使用したモード１取引順序数（２０ビットとして） ８．カードの期限切れ日付（４個の二進コード十進数、または、１６ビット） ９．ＭＡＣであり、好ましくは１６から３２個の二進ビットから成り、好まし
くはデータ要素３番から８番まで（好ましくはこの順序で）に載せられ、対カー
ドキーを用いて生成されるＭＡＣ。

【０１００】 次に、ＳＰＡウォーレットが、インタネットを介してＳＰＡウェブサイトに接
触し、前記データ要素を伝送する。次にウォーレットは応答を待つ（ＳＰＡウェ
ブサイトが、適当なＳＰＡ承認システムへ接触している間）。数秒後、ＳＰＡウ
ォーレットは、カード保持者にたいして「お待ち下さい」を表示する。次に他の
テキストが表示され、カード保持者にたいして、ＳＰＡが所望の取引の準備のた
めにマスターカードに接触中であること、かつ、このため少し時間がかかること
を記述する。ディスプレーは好ましくは、数秒に１回変化し、それによって、カ
ード保持者が「何かが現在起こっている」ことが知れるようになっている。

【０１０１】 過度の時間が経った場合は、ＳＰＡウォーレットは再びＳＰＡウェブサイトに
接触して、請求を繰り返す。ＳＰＡが、通常は接触できるＳＰＡウェブサイトに
接触できない場合には、バックアップＳＰＡウェブサイトに接触する。このよう
な試行の指定の時間と回数の後に、ＳＰＡが、ＳＰＡウェブサイトから応答を得
られなかった場合には、ＳＰＡは、カード保持者に、「今回は取引を完了するこ
とができませんでした」という旨を通知して、中断する。今度はカード保持者は
、別のＳＰＡカードを、別の支払い手段（例えば、手動でマスターカード口座番
号を入力する）を、または、後に改めて再試行しなければならない。

【０１０２】 ＳＰＡが最終的にＳＰＡウェブサイトから受容する応答は、「進めることがで
きません」表示、「進めることができます」表示、または、「状態を変更してく
ださい」表示である。

【０１０３】 応答が「進めることができません」表示である場合、ＳＰＡはさらに「理由」
コードを与える。好ましくは、三つの理由がある。 １．このＳＰＡコピー数はもはや有効ではない（なぜなら、比較的最近のＳＰ
Ａコピーが、最後に同じ”ｎ”ビットを持っている）。（同じ偽似口座番号にた
いして、有限数のＳＰＡコピー、例えば１６、が同時使用される可能性がある）
。 ２．これは、期限切れとなった、単一セッションＳＰＡである。 ３．ＭＡＣは真実証明されなかった、取引連番が有効でない、または、「．．
．まで無効」―インディケーターが、未来の日付を保持している、あるいは、「
無効コピー」フラグが設定されている。

【０１０４】 「進めることができません」表示が第一理由のためである場合、カード保持者
には、好ましくは、下記が通知される。すなわち、 ＭＣ−Ｉｎｔｅｒｎｅｔ．ｃｏｍに接触して、このＰＣにたいしてこのカード
を再登録しなければなりません。あなたが最初このカードをこのＰＣに登録して
から、この同じカードを、他のＰＣ上で、合計少なくとも１６（または別の数）
回登録しました。そのため、このＰＣにおけるあなたの元の登録は無効となりま
した。

【０１０５】 「手続不能」表示が第２の理由に対する場合、カードホルダに以下の情報が提
供される。 このＰＣ上のこのカードは、４時間（又は他の時間中）だけ使用可能でした。
この時間は満了しました。継続のためには、MC-internet.comにコンタクトし、
このＰＣに対してこのカードを再登録する必要があります。

【０１０６】 上記状況のいずれの場合でも、カードホルダに２個のボタンが提示され、その
一方は「再登録」と称され、他方は「取消」と称される。第１のものを起動する
ことによって、ＰＣのＳＰＡが、ＳＰＡウェブサイトにコンタクトし、その後中
断する。第２のものを起動することによって、ＰＣのＳＰＡが直ぐに中断する。

【０１０７】 「手続不能」表示が第３の理由に対する場合、試みは、考えられる不正であり
、カードホルダに以下の情報が提供される。 手続不能。発行人にコンタクトして下さい。 このメッセージの表示後、ＳＰＡは中断します。

【０１０８】 応答が「変更状態」表示の場合、新たな状態の同一性(identity)が応答に含ま
れる。ＰＣのＳＰＡは、状態を変更し、この新たな状態に対してこの擬似的なア
カウント番号を格納する。これによって他のＭｏｄｅ−１を開始してもしなくて
もよい。

【０１０９】 応答が「手続可能」を表す場合、この応答は、（カードホルダに表示されない
）以下のデータによって行われる。 １．後に説明する基準日（２進化１０進数としての２バイトのフォーマット化
されたＹＹＭＭ。） ２．月数インディケータ（４桁の２進化１０進数としての２バイト。）

【０１１０】 この場合、ＳＰＡは、好適には以下のように進行する。 １．Ｍｏｄｅ−１取引順序番号を増分する。 ２．この取引順序番号及びＰｅｒ−Ｃａｒｄ Ｋｅｙを使用して、６４ビット
２進ＭＡＣを形成する。 ３．この６４ビット２進ＭＡＣを、ＳＰＡウェブサイトからの受取直後に基準
日及び月数インディケータを用いて擬似満了日に変換する。 ４．この擬似満了日を、ＳＰＡが示すことができる場合には顧客の支払いスク
リーンの「満了日」領域に配置する。 ５．擬似アカウント番号を、ＳＰＡが示すことができる場合には顧客の支払い
スクリーンの「アカウント番号」領域に配置する。 ６．ＳＰＡが示すことも占有することもできない顧客の支払いスクリーンに任
意のアイテムが存在する場合、まだ占有されていない（残りの）アイテムをリス
トする「ドラッグアンドドロップ」メニューを表示する。 ７．顧客に対する基本データが設けられたカードホルダにメッセージを表示し
、その後中断する（ＳＰＡが未知であり、カードホルダによって手動で入力する
必要があるこの顧客を有するカードホルダ顧客番号のような一部のデータが存在
することができる。これによって、ＰＣのブラウザは、この充填スクリーンを顧
客に送出する。）。

【０１１１】 「ドラッグアンドドロップ」メニュー中のデータは、ＳＰＡが顧客の支払いス
クリーンに示すことができなかった以下のアイテムのうちの任意のものを有する
。 １．実際の名前（Ｊｏｈｎ Ｒ．Ｊｏｎｅｓ）として表示されるカードホルダ
名。 ２．実際のアドレス（１１１ Ｆｉｒｓｔ Ｓｔｒｅｅｔ，Ｅｌｙ．ＮＶ９９
９９９）として表示されるカードホルダのアドレス。 ３．実際の電話番号（６５０−１１１−２２２２）として表示されるカードホ
ルダの電話番号。 ４．（カードホルダが擬似的なアカウント番号を未知であり又は認識していな
いので、）単語「カードアカウント番号」として表示されるカードアカウント番
号。 ５．（擬似的な満了日であり、カードホルダに対して無意味であるので、）単
語「カード満了日」として表示されるカード満了日。 スクリーンがこれらアイテムの全てを必要としない場合の「取消」ボタンも存
在する。擬似的なアカウント番号及び擬似的な満了日が顧客の支払いスクリーン
に示される前に「取消ボタン」に当たった場合、好適には、カードホルダに対し
て以下のメッセージを表示する。 取消を所望しますか？取消によって支払いを許容することができません。「は
い、取り消します」ボタン及び「いいえ、継続します」ボタンが続く。

【０１１２】 「はい」のボタンを選択する場合、ＳＰＡは中断され、（どのプログラムが以
前に実行されたとしても）制御はブラウザに戻る。「いいえ」を選択する場合、
「取消」ウィンドウが取り除かれ、ＳＰＡは「ドラッグアンドドロップ」手順を
継続する。

【０１１３】 ＳＰＡが首尾よく完了し、その結果中断すると、制御がブラウザに戻り、かつ
、現在充填されている顧客の支払いスクリーンを顧客に送信のためにカードホル
ダがブラウザを使用すると仮定される。カードホルダが他の購買の準備を行うま
で、ＳＰＡを再び起動する必要がない。

【０１１４】Ｍｏｄｅ−１ ＳＰＡ要求の特定の処理 好適には、Ｍｏｄｅ−１ ＳＰＡは、各取引の間、ＳＰＡに基づく支払いを実
行する前に開始される。図２に示すように、ＳＰＡは、ウェブサイト又はサーバ
（好適には、マスターカードのサービスプロバイダ）に対して、（例えば）１６
桁の擬似アカウント番号からなる要求と、実際のアカウント数の４桁の１０進日
付と、４ビットＳＰＡバージョン数と、２０ビットＭｏｄｅ−１取引シーケンス
番号（ＴＳＮ）の現在の値と、その後ろ３桁の値に基づく１６ビットＭＡＣとを
送り出す。好適には、ＭＡＣは、ＳＰＡ固有の１６バイトのカードごとのキーを
用いたトリプルＤＥＡ暗号化と、２０ビットのＭｏｄｅ−１取引シーケンス番号
に連結した４ビットのＳＰＡバージョン数に（左から右に）連結した（２進１０
進数としての）１６ビットの満了日と、６４ビットの領域の左側への桁そろえ及
び２進数の１を用いた正当であるか否かのパディングと、結果的に得られる暗号
文字の最も左側の１６ビットの選択とによって形成される。

【０１１５】 図３は、Ｍｏｄｅ１におけるＳＰＡ開始及び取引支払い準備に含まれるステッ
プのシーケンスを示す。既に説明したように、ＳＰＡは、先ず、ステップ２０に
おいて、開始要求をサービスプロバイダに送り出す。マスターカードのウェブサ
イトがこの情報を受け取ると、ステップ２２において、特別なセキュリティモジ
ュール装備のＳＰＡシステムを用いて、好適には満了日に基づくＭＡＣ、ＳＰＡ
バージョン数及び取引シーケンス番号を確認する。ＭＡＣが正当である場合、こ
のシステムは、ステップ２４において、取引シーケンス番号を増分して「予測さ
れる取引シーケンス番号」を形成するとともに、表示された擬似アカウント番号
のＢＩＮに対するＳＰＡ許可要求を処理するＳＰＡ許可システムに対する関連の
擬似アカウント番号及びＳＰＡバージョン数に対する「予測される取引シーケン
ス番号」の更新を行う。しかしながら、ステップ２６において、このＳＰＡ許可
システムは、この擬似アカウント番号及びＳＰＡバージョン数に対して以前受信
した最高数の「予測される取引シーケンス番号」以下の「予測される取引シーケ
ンス番号」の場合、直前に受信した「予測される取引シーケンス番号」を拒絶す
る。このＳＰＡ許可システムは、ステップ２８において、直前に受信した満了日
が付与され、現在記録されている満了日以降の場合には、この擬似アカウント番
号に関連した満了日を更新する。

【０１１６】 この特別なＳＰＡシステムは、以下の二つの基準データ値：１）（実際には本
月又は次の月の）フォーマットＭＭＹＹを有する４桁の１０進数と、２）（１０
進数）２５６未満の最大値を有する８ビット２進数の「月数インディケータ」と
称されるデータ値を、マスタカードウェブサイトに送信し、その後、ステップ３
０において、カードホルダのＰＣのＳＰＡに送信する。このデータは、適切なＳ
ＰＡ許可システムに送信される情報に含まれる。

【０１１７】擬似満了日の発生 先ず、実際のＭｏｄｅ−１取引に対して、Ｍｏｄｅ−１取引シーケンス数が増
分される。その後、左側に４ビットのＳＰＡバージョン数を有する結果的に得ら
れる２０ビット数に対して、８バイト領域で左側に桁合わせされ、２進数ゼロを
用いた正当であるか否かのパディング及び倍長ＳＰＡのカードごとのキーを用い
たトリプルＤＥＡ暗号化を行う。その結果は、６４ビットの２進ＭＡＣとなる。

【０１１８】 ステップ３２において、取引の擬似満了日領域が、以下のようにして６４ビッ
トの２進ＭＡＣから取得される。 １．「月数インディケータ」（２進数）の最も左にある“１”のビットを選択
するとともに、このビット位置から最も右にあるビットまでのビット位置の個数
を（最も左にある“１”のビットのビット位置を含めて）計数する。この個数を
“Ｎ”と称する。例えば、「月数インディケータ」が０１０１０１００（１０進
数で８４）の場合、値“Ｎ”は７となる。“Ｎ”を決定したので、“Ｎ”ビット
の各々の群として６４ビットの２進ＭＡＣを考察すると、最も右にあるビットを
超える左のものを無視する。最も左の群から開始すると、「月数インディケータ
」以下で出くわした最初の群を選択する。そのような群が見つからない場合、こ
の群から２^Ｎを減算したものから最も左の群を選択し、（＞０かつ＜月数インデ
ィケータである）この結果を選択値として使用する。 ２．ステップ１の結果を２進数１１００（１０進数で１２）で除算して、商及
び余りを生成する。これら商及び余りを１０進数に変換する。（００から１１の
範囲の値を有する）１０進数の余りを、１０進数の「基準日」の最も左の２桁（
ＭＭ）に加算する。結果が１２より大きい場合、結果から１２を減算し、結果が
１２より大きいか否かに関係なく、現在の取引に対する擬似の満了日の最も左の
２桁のＭＭの結果となる。１２の減算が要求される結果を取得する場合、商（に
１）を増分する。 ３．ｍｏｄ−１００、ステップ２でも示したように増分する場合もあるステッ
プ２からの２桁の１０進数の商に、「基準日」の最も右の２桁（ＹＹ）を加算す
る。現在の取引に対する擬似の満了日の最も右の２桁ＹＹを、結果として使用す
る。

【０１１９】カードホルダと顧客との間の通信 一度、ＳＰＡがカードホルダのコンピュータにインストールされると、カード
ホルダは、好適にはインターネットの支払いに対してＳＰＡを使用し、ＳＰＡは
、全てのインターネット取引に対してカードホルダの擬似的なアカウント数を提
供する。ＳＰＡ Ｍｏｄｅ １において、これがＳＰＡ取引であることは、顧客
に対して明白である。アカウント番号が実際には擬似のアカウント番号であり、
満了日が実際にはＭＡＣの表示であるとしても、顧客は、受信する他の任意のイ
ンターネットＳＳＬとこの取引が異なることに気付かない。

【０１２０】許可要求の取得者の処理 図４は、本発明の実施の形態による、取得者３４、サービスプロバイダ（マス
ターカード）２０、発行者３６及び購買者３８の間の通信を示す。

【０１２１】 取得者３４がインターネットの顧客３８から許可要求メッセージを受信すると
、ＢＩＮテーブルの発行者ＢＩＮをルックアップする。擬似アカウント番号の取
引の場合、「発行者」は、サービスプロバイダ又はマスターカードが許可した処
理ファシリティに対応する。

【０１２２】 本発明の一実施の形態において、一部の国が、自国の取引を処理する特別な安
全モジュール装備のファシリティを有することができる。そのようなファシリテ
ィの各々は、中央のサービスプロバイダの承認のみでセットアップし、取引にお
いて処理を行う国用の暗号化キー及びアカウント数変換データのみを保持する。
そのような自国のＳＰＡファシリティを有する国において、全ての取引がこのフ
ァシリティに送り出され、その結果、同一国の取引が当該国を除外する必要がな
い。これを、所望の場合には国内の個別の銀行に対して行うこともできる。

【０１２３】 自国の取引を処理するための国内のＳＰＡファシリティは、全ての取引を中央
処理ファシリティに行わせる場合に比べて有用である。

【０１２４】許可要求のサービスプロバイダ処理 先ず、アカウント番号が実際には擬似的なアカウント番号であるか否かを発行
者ＢＩＮから決定し、擬似的なアカウント番号である場合、処理のために取引を
特定のシステムに送り出す。このシステムは、擬似的なアカウント番号を対応す
る「実際の」アカウント番号に変換するのに必要なテーブルを格納する。このシ
ステムは、ＳＰＡバージョン数及び擬似的なアカウント数に対して、受信した２
０ビットの最大数の「予測される取引シーケンス番号」の記録も格納し、それは
、ＭＡＣがこの取引シーケンス番号に対して確認されたか否かの表示も伴う。さ
らに、システムは、ＭＡＣがまだ確認されていない過去４８時間以内に受信した
任意の「予測される取引シーケンス番号」を格納する。そのような予測される取
引シーケンス番号の各々に関連して、システムは、予測される取引シーケンス番
号の各々に適用する「基準日」及び「月数インディケータ」の表示も格納する。

【０１２５】 「基準日」は、許可要求メッセージ内で許容し得る最新の満了日を表す日付の
値である。バックグランドから、一部の顧客が直ちに許可を要求せず、バッチ許
可要求を要求する。したがって、この日付は、典型的には取引開始日の１又は２
日前となる。

【０１２６】 「月数インディケータ」は、支払いカードが許容される最終満了日に対応する
現在の日付を超える月数を表す。典型的には、この数を４８ヶ月とする。 このシステムは、登録が発生する際にカードホルダのＰＣのＳＰＡに配置され
た独自かつ秘密の１６バイトの暗号化キーを決定する機能を有する安全モジュー
ルも有する。このシステムによって実行される処理は、以下の通りである。 １．格納した上記変換テーブルを用いて、擬似的なアカウント番号から「実際
の」アカウント番号を決定する。 ２．安全モジュールを用いて、（既に説明したような）擬似的なアカウント番
号及び「実際の」アカウント番号を用いたこのＳＰＡに特有の暗号化キーを決定
する。 ３．ＭＡＣが未だ確認されていない過去４８時間以内に最初に受け取った２０
ビットの「予測される取引シーケンス番号」を選択する。この２０ビットの取引
シーケンス番号及びＰＣのＳＰＡに対して既に規定したような関連のＳＰＡバー
ジョン数を算出する。関連の「予測される取引シーケンス番号」に対する「基準
日」及び「月数インディケータ」を用いて、ＰＣに対するＳＰＡに対して既に規
定した方法を用いた満了日をこのＭＡＣから決定する。この満了日が現在の満了
日に等しい場合、ＭＡＣが検証される。ＭＡＣの検証となるこの「予測される取
引シーケンス番号」に対するエントリは、関連のＳＰＡバージョン番号に対する
最高数の「予測される取引シーケンス番号」である場合には「検証されたＭＡＣ
」としてマークされ、関連のＳＰＡバージョン番号に対する最高数の「予測され
る取引シーケンス番号」でない場合には削除される。「検証されたＭＡＣ」とし
てマークされるとともに同一のＳＰＡバージョン数に関連した任意の低い番号を
付した「予測される取引シーケンス番号」に対するエントリは、削除される。 ４．ＭＡＣがステップ３（又はステップ５）で検証されると、この取引の顧客
がこの同一の取引に対する第２の許可要求メッセージを決して送信しないことを
既知でない場合、この擬似的なアカウント番号に対する「ヒストリデータ」にエ
ントリを形成する（一部の顧客は、取引後の所定の時間内に商品の全てを搬送す
ることができない場合には同一の取引に対して二度以上の許可要求メッセージを
送信するおそれがある。）。このヒストリデータは、既に説明したデータの全て
に加えて、顧客及び取得者の同一性と、このエントリに対する「満了日」とを有
する。このエントリ満了日を、将来の特定の時間（例えば６ヶ月）とする。 ５．ＭＡＣがステップ３で検証を行わない場合、既に検証したＭＡＣに関連し
ない過去４８時間中に受信した最も古いものから最も新しいものまでの他の全て
の「予測される取引シーケンス番号」に対して、ステップ３で規定した手順を繰
り返す。これらの試みのうちの任意のものに対して、結果的に得られるデータが
現在の取引中のものに整合する場合、ＭＡＣは、検証されたものと考えられる。
ＭＡＣの検証となる２０桁の「予測される取引シーケンス番号」は、当該関連し
たＳＰＡバージョン数に対して最高の「予測された取引シーケンス数」である場
合には、「検証されたＭＡＣ」としてマークされ、当該関連したＳＰＡバージョ
ン数に対して最高の「予測された取引シーケンス数」でない場合には、削除され
る。ＭＡＣがこのステップで検証された場合、ステップ４も実行する。 ６．ステップ３又はステップ５でＭＡＣが検証を行わない場合、当該擬似的な
アカウント数に対する「ヒストリーデータ」がアクセスされる。同一の満了日Ｍ
ＡＣを発生する同一顧客及び取得者に対するこのデータにエントリが存在し、こ
のエントリが満了しなかった場合、ＭＡＣを許容する（これは、既に認証された
取引に対する他の認証要求メッセージであると仮定される。）。このエントリの
ためにＭＡＣが許容される場合、エントリ満了日を、２ヶ月未満の場合には将来
に対して約２ヶ月とする必要がある。その理由は、これが「再支払い」となるお
それがあり、他の月におけるこれと同一の取引に対する他の認証要求メッセージ
となるおそれがあるからである。 ７．ＭＡＣがステップ３、ステップ５又はステップ６で検証を行わない場合、
取引が拒否される。この場合、「断り」応答が取得者に送り出される。 ＭＡＣが検証されると、マスターカードは、発行者に対する許可要求メッセー
ジをフォーマット化する。許可要求メッセージは、（擬似的なアカウント番号で
はなく）「正しい」アカウント番号と、（ＭＡＣではなく）「正しい」満了日と
を有する。しかしながら、マスターカードＳＰＡ許可システムは、発行者からの
許可応答の受信の予測の際に所得者から受信されるようなアカウント番号領域及
び満了日領域の記録を保持する必要がある。

【０１２７】 発行者に送信される許可応答メッセージにおいて、許可応答が、取得者ＢＩＮ
に基づく支払いネットワークを通じて送り出される場合、マスターカードは、取
引メッセージの取得者ＢＩＮを、「擬似的な」取得者ＢＩＮとしての役割を果た
すマスターカードの特定のＢＩＮのうちの一つに置換する。取得者ＢＩＮは、発
行者が取得者の代わりにマスターカードに応答するように置換される。許可要求
メッセージが来る場所と許可応答メッセージを戻す場所が同一であるという記録
を支払いネットワークが保持する場合、このステップを実行する必要はない。

【０１２８】 取得者及び発行者に対して交換料金を正確に算出するために擬似的な取得者Ｂ
ＩＮが用いられる場合、擬似的な取得者ＢＩＮは、取得者が配置された国又は結
果として同一の交換料金を付与する他の国若しくは領域に対応する必要がある。
各国が、それに関連した特定のＢＩＮを有する場合、マスターカードは、取得者
ＢＩＮを、取得者の国に関連した特定のＢＩＮに置換する。取得者の国が、それ
に関連した特定のＢＩＮを有しない場合、他の国に関連した特定のＢＩＮを、同
一の交換料金となるものに選択することができる。

【０１２９】 擬似的な取得者ＢＩＮを使用する場合、マスターカードは、所得者からの許可
要求で受信した取得者参照データ（以後、「オリジナル取得者参照データ」と称
する。）をデータベースに格納する。発行者に対して許可メッセージをフォーマ
ット化するに際しに、マスターカードは、オリジナル取得者参照データを、擬似
的な取得者ＢＩＮ、適切な取引タイプのインディケータ及びオリジナル取得者基
準データを見つけるためにマスターカードが使用するインデックス値を有する「
擬似的な」取得者参照データに置換する。

【０１３０】 国内的な(national)ＳＰＡファシリティが擬似的なアカウント番号の取引を処
理する場合、そのファシリティは、以下の様に動作する。しかしながら、この国
内的なＳＰＡファシリティは、国内の発行者に対する取引のみ処理し、したがっ
て、その国に適用する暗号化キー及びアカウント番号変換テーブルエントリしか
必要としない。

【０１３１】 ＳＰＡ許可システムでは、実際の許可要求を受信するまで待機するのに比べて
、新たな「予測される取引シーケンス番号」を受信する際にＭＡＣ表示の満了日
を計算し及び格納するのが有効である。この場合、許可要求を受信すると、許可
要求メッセージ中の満了日と、以前の任意の許可要求メッセージ中の満了日に未
だ整合しない過去４８時間以内に予め計算され及び格納された満了日とを比較す
る必要がある。

【０１３２】許可要求の発行者ハンドリング 図５は、発行者が例えばマスターカード又は許可された国内のＳＰＡファシリ
ティから受信した後の発行者３６、マスターカード（サービスプロバイダ）１０
、取得者３４及び本発明の一実施の形態による顧客３８の間の通信を示す。

【０１３３】 発行者は、他の任意の取引のように取引を許可する。許可応答の戻りは、「擬
似的な」取得者、すなわち、擬似的なアカウント番号を「正しい」アカウント番
号に変換するとともにＭＡＣ表示の満了日を検証した同一のマスターカードＳＰ
Ａ許可システムに戻される。

【０１３４】 既に説明したように、このシステムは、取引の（一時的な）記録を維持し、す
なわち、アカウント番号の領域及び満了日の領域を、取得者から受け取った値に
戻すことができる。取得者から受け取った値に置換されたこれらの領域を有する
許可応答は、通常のマスターカードの取引の場合のように、取得者に送出され、
取得者から顧客に送出される。

【０１３５】 ＳＰＡ許可システムが実際には国内のＳＰＡファシリティである場合、このフ
ァシリティは、以前の説明で示した機能を実行する。

【０１３６】クリアリング及び清算(Settlement) 取得者は、通常の方法で取引の清算を行う。取得者は、マスターカードのＩＮ
ＥＴ（クリアリング及び清算）システムに行き、そのシステムは、擬似的なアカ
ウント番号を「正しい」アカウント番号に変換する（そのような交換メッセージ
に満了日の領域は存在しない。）。

【０１３７】 一度、ＩＮＥＴが取引を「正しい」アカウント番号に変換すると、その番号は
、他の任意の取引と同様に、発行者に送り出され、クリアリング及び清算される
。

【０１３８】例外処理 将来の料金返還(chargeback)、コピー要求、又は発行者によって開始されるこ
の取引に関連する他の任意の例外処理がある場合、それをＩＮＥＴ（又はＳＰＡ
例外処理システム）に送り出す必要があり、この場合、変換は、「正しい」アカ
ウント番号から擬似的なアカウント番号まで行われる。このファシリティが個別
の取引の記録を保持する必要がないので、この変換はテーブルに基づくことがで
きる。取引中のデータによって、それが発行者から適切なマスターカードファシ
リティに送出される。

【０１３９】 同様に、顧客及び取得者から発行者までの任意の応答は、適切なマスターカー
ドファシリティに送出され、この場合、「正しい」アカウント番号を応答に関連
させる。

【０１４０】Ｍｏｄｅ １に対する他の例 図６は、Ｍｏｄｅ １に対する他の例を示す。図６の各“Ｘ”は桁を表す。本
例では、ＭＡＣを、取引シーケンスに基づいて発生し、ＭＡＣは、既に説明した
擬似的な満了日となる。さらに、（４０，４２によって表される）ＭＡＣを発生
するのに使用される取引シーケンス番号の１以上の下方の桁は、擬似的なアカウ
ント番号４４で置換される。その桁は、図示したようにカードホルダ番号とチェ
ック桁との間で置換される。

【０１４１】 本例では、ＳＰＡは、取引中にマスターカードウェブサイト又はサーバと通信
するのに必要とされない。ＳＰＡファシリティは、登録されたＳＰＡの各々に対
する取引シーケンス番号のカウンタを維持する。ＳＰＡファシリティは、許可要
求を受け取ると、擬似的なアカウント番号の取引シーケンス番号の下の桁ととも
に維持する取引シーケンス番号カウントの上の桁に基づいてＭＡＣを発生する。
その後、ＳＰＡファシリティは、このＭＡＣを擬似的な満了日に変換し、この満
了日を、許可要求メッセージ中の満了日と比較する。また、ＳＰＡファシリティ
は、取引シーケンス番号が以前の取引からの数の繰り返しでないことを検証する
。

【０１４２】Ｍｏｄｅ ２及び３：他の領域を用いた認証 ＳＰＡウォレット(wallet)は、（カードホルダが適切な方向に従った場合には
）顧客の支払いスクリーンがＰＣ上に表示されるまで有効にならないようにする
必要がある。したがって、ＳＰＡは、取引の処理の準備を行うと、現在表示され
ているスクリーンを検査し、見えるものを理解することを試みる。先ず、ＳＰＡ
は、ＳＰＡ ＭＡＣ領域である「隠し」領域を探す。

【０１４３】 Ｍｏｄｅ−２取引に対して、この領域の識別子を、特定の値とする必要がある
。Ｍｏｄｅ−３取引に対して、この領域の識別子を、互いに相違する値とする必
要がある。ＳＰＡが、一方がＭｏｄｅ−２識別子を有するとともに他方がＭｏｄ
ｅ−３識別子を有する二つの隠し領域を見つけた場合、ＳＰＡは常に、Ｍｏｄｅ
−２領域を選択し、これをＭｏｄｅ−２取引と考える。

【０１４４】 ＳＰＡがこの「隠し」領域を見つけることができる場合、これは、“Ｍｏｄｅ
−２”又は“Ｍｏｄｅ−３”取引となる。そのような取引の場合、ＳＰＡは、「
カード番号」領域、「満了日」領域、並びにカードホルダの名前、アドレス及び
電話番号を特定する領域も見付けることができる。その理由は、ＳＰＡに従う顧
客の場合、規格化された方法によってこれらの領域の全てが識別されるからであ
る。この場合、ＳＰＡは、支払いスクリーン全体を占有する。

【０１４５】 Ｍｏｄｅ−２又はＭｏｄｅ−３取引のイベントにおいて、ＳＰＡは、以下のよ
うな処理を行う。 １．カードホルダの名前、カードホルダのアドレス及びカードホルダの電話番
号に対する顧客の支払いスクリーンのエントリを占有する。 ２．顧客の支払いスクリーンの「アカウント番号」領域を擬似のアカウント番
号で占有する。 ３．顧客の支払いスクリーンの「満了日」領域を、（カードホルダが相互に更
新された）このカードに対してＳＰＡに記憶された満了日で占有する。 ４．Ｍｏｄｅ−２取引シーケンス番号を増分（し及び永久的に格納）する。 ５．ＭＡＣを形成する。 ６．以下に規定するような（上記のようにして発生したＭＡＣを有する）ＭＡ
Ｃ領域を形成する。 ７．顧客支払いスクリーンの「隠し」領域にＭＡＣ領域を配置する。 ８．顧客の支払いスクリーンが占有されるとともにそれを送信できるという情
報をカードホルダに提供する。 ９．サスペンドし、その結果、制御がＰＣのブラウザに戻される。 カードホルダは、適切な領域を互いに占有するように、ＳＰＡが占有したスク
リーンを送信する通常のブラウザ機能を用いることが予測される。

【０１４６】 Ｍｏｄｅ−２／３ ＭＡＣ領域は、好適には以下のデータ要素からなる。 １．（８ビットの）擬似ＢＩＮキーインディケータ ２．（１ビット：０＝Ｍｏｄｅ−２，１＝Ｍｏｄｅ−３の）ＳＰＡモードイン
ディケータ ３．（１５ビットの）ＳＰＡバージョン数。この領域は、ＳＰＡタイプ（貸方
、借方、前払い）及びこのタイプに対するバージョン数を表す。クレジットカー
ドＳＰＡ、リビジョン０及びＳＰＡバージョンに対して、数は全てゼロとなる。 ４．（１ビット：０＝通常のＳＰＡ，１＝単一セッションのＳＰＡの）単一セ
ッションＳＰＡインディケータ。 ５．（１０ビットの）ＳＰＡコピー数及び単一セッション数 ６．（２０ビットの）直前に増分したＭｏｄｅ−２／３取引シーケンス番号 ７．（４桁の２進化１０進数すなわち１６ビットの）カードの満了日 ８．カードごとのキーを用いて順に発生したデータ要素＃２−＃７の２進化３
２ビットのＭＡＣ

【０１４７】 Ｍｏｄｅ−２及びＭｏｄｅ−３は、同一セットの取引シーケンス番号を使用す
る。したがって、同一の擬似的なアカウント番号に対する同一のＰＣの同一のカ
ードホルダのＳＰＡからは、Ｍｏｄｅ−３取引と同一の取引シーケンス番号を有
するＭｏｄｅ−２取引は決して存在しない。

【０１４８】 ＳＰＡが再び有効になる（非中断状態になる）と、全てのＳＰＡカードのリス
トを表示し、そのうちの一つを選択するようカードホルダに問い合わせる。しか
しながら、ＳＰＡが中断されるが閉じられない場合、及び直前に使用されたカー
ドをカードホルダが選択する場合、ＳＰＡは、アドレス、電話番号又はカード満
了日が変更されたか否かをカードホルダに（再び）問い合わせない。また、ＳＰ
Ａは、パスワードを再入力することを要求しない。その代わりに、ＳＰＡは、（
別の状況ではキーとしてパスワードを用いることによって暗号化される）クリア
テキストのカード後とのキーを保持する。このクリアテキストキーは、ＳＰＡが
閉じられるとき又は他のカードが選択されるときに消去される。

【０１４９】Ｍｏｄｅ ２要求の特定の処理 このモードにおいて、（例えば）１３桁の１０進数の個別のＭＡＣ領域は、Ｓ
ＰＡ固有の領域として取引に含まれる。これら１３桁は以下の通りである。 １．“ＳＰＡ”インディケータ：１桁。この領域は、通常、値１を有する。し
かしながら、カードホルダが、（例えばデスクトップコンピュータ又はラップト
ップコンピュータ上で）同一の「正しい」アカウント番号に対してＳＰＡのコピ
ーを１個より多く有する場合、ＳＰＡの他のバージョンは、ＳＰＡインディケー
タフィールドに互いに相違する数を有する（ＳＰＡ取引シーケンス番号は、ＳＰ
Ａのそのようなバージョンの各々に対して独自のものである。）。 ２．ＳＰＡのこのバージョンに対するＳＰＡ取引シーケンス番号：６桁。この
フィールドは、この特別のコンピュータで開始したＳＰＡ取引に対して増分する
（各コンピュータは、ＳＰＡのそれ自体のバージョンを有し、したがって、それ
自体のセットのシーケンス番号を有するようになる。）。 ３．ＭＡＣそれ自体：６桁。後に説明するように、実際のＭＡＣは、上記の二
つの領域で算出される。

【０１５０】 提案されるＭＡＣ−発生プロセスは、以下の通りである。 １．ＳＰＡバージョン数の７桁を（左に）表示するとともに（このコンピュー
タに対する）ＳＰＡ取引シーケンス番号を２進化１０進数で表示して、２８ビッ
トを生成する。６４ビット領域でこれら２８ビットを左に桁合わせするとともに
、ゼロのビットを用いた正当であるか否かのパディングを行う。 ２．暗号化キーとしてカードごとのキーの最も左の８バイトを用いたステップ
１の結果のＤＥＡ暗号化。 ３．暗号化キーとしてカードごとのキーの最も左の８バイトを用いたステップ
２の結果のＤＥＡ暗号化。 ４．暗号化キーとしてカードごとのキーの最も左の８バイトを用いたステップ
３の結果のＤＥＡ暗号化。 ５．ステップ４の結果的に得られる６４ビットを、各々が４ビットの１６進数
と考える。その１６進数を（左から右に）走査し、１６進数で９未満の値を有す
る最初の６桁を選択する。そのような６桁が見つからない場合、桁を再走査する
とともに１６進数で９より大きい桁のみを選択し、かつ、その各々から１６進数
Ａを減算することによって、必要な残りの桁を見つける。 ６．この取引に対する６桁の２進ＭＡＣとしてステップ５の結果を用いる。 ＭＡＣは、カードホルダのＰＣのＳＰＡによって発生し、適切なマスターカー
ドＳＰＡファシリティによって検証される。発生の際には、ステップ６に起因す
る６桁の１０進数は、実際のＭＡＣとしてＭＡＣフィールドに挿入される。検証
の際には、ＳＰＡファシリティは、ＭＡＣフィールドの最も左の７桁を用いて上
記６ステップを実行し、その後、受信したＭＡＣフィールドの最も右の６桁に対
して、ステップ６に起因する６桁と比較する。正確な整合は、認証された取引を
表す。非整合は、拒否する必要がある取引を表す。

【０１５１】カードホルダと顧客との間の通信 ＭＡＣフィールドが顧客によってサポートされるときには常に、ＳＰＡは、取
引に関連するＭＡＣを形成するために、嵌め込まれた秘密キーを使用し、このＭ
ＡＣ及びそれに基づくデータを、取引の一部となるＭＡＣ領域に配置する。

【０１５２】 カードホルダの取引メッセージの受信に応答して、顧客は、取得者に対する通
常の認証要求をフォーマット化する。この認証要求は、消費者のＰＣから提供さ
れるようなＭＡＣ領域を有する。

【０１５３】 顧客が、カードホルダ取引に対して複数の認証／クリアリング取引を開始する
場合、これらの取引のうちの最初のもののみがＭＡＣ領域及び満了日を有する。
次の取引は、擬似的なアカウント番号のみを有し、顧客が発生したメールオーダ
及び電話注文取引と考えられる。これは、再び発生する全ての支払い及び複数の
複数のクリアリングを伴う部分的な支払いにも当てはまる。

【０１５４】認証要求のサービスプロバイダハンドリング サービスプロバイダは、取引を受け取ると、アカウント番号が擬似的なアカウ
ント番号であるか否かを発行者ＢＩＮから決定し、擬似的なアカウント番号であ
る場合、処理のために取引を特定のＳＰＡ認証システムに送信する。このシステ
ムを、既に説明したよう国内のＳＰＡファシリティとすることができる。このシ
ステムは、ＭＡＣフィールドの存在から、それがＭｏｄｅ−２取引であることを
自動的に記す。アカウント番号を擬似的なアカウント番号から対応する「正しい
」アカウント番号に変換した後、システムは、ＭＡＣを形成するためにＰＣで用
いられる実質的には同一の手順を用いて、（既に説明したように）カードごとの
キーを決定し、かつ、ＭＡＣを検証するようこのキーを使用する。システムは、
取引シーケンス番号もチェックし、そのために、システムが処理する擬似的なア
カウント番号の各々のバージョン数に対して取引シーケンス番号情報を維持する
。

【０１５５】 １．取引シーケンス番号が、少なくとも４８時間前に受信したこのＳＰＡのこ
のバージョンに対する最大の取引シーケンス番号より小さい（又は等しい）場合
、又は ２．取引シーケンス番号が、このＳＰＡのこのバージョンに対する既に受信し
た任意の取引シーケンス番号に整合する場合（これは、過去４８時間内に受信し
た取引シーケンス番号に制約される。）、 システムは取引を拒否する。

【０１５６】 ＭＡＣ又は取引シーケンス番号が検証をし損なうと、このファシリティによっ
て、取引が断られる。ＭＡＣと取引シーケンス番号の両方が検証を行う場合、こ
のファシリティによって、「正しい」アカウント番号（及びカードホルダのＰＣ
によって取引に挿入された「正しい」満了日）を有する取引を、発行者に送出す
る。

【０１５７】認証要求の発行者ハンドリング 発行者は、他の任意の取引のように取引を認証する。認証応答は、擬似的なア
カウント番号を「正しい」アカウント番号に変換するとともにＭＡＣを認証した
同一のＳＰＡ認証システムに戻す。認証応答を送出する支払いネットワークが応
答メッセージ中の取得者ＢＩＮに基づく場合、擬似的な取得者ＢＩＮを、既に説
明したようにして使用することができる。

【０１５８】 このシステムは、「正しい」アカウント番号を擬似的なアカウント番号に戻し
、元の取引中にあったデータを復元する（Ｍｏｄｅ ２の場合、開始から取引に
保持された満了データは、「正しい」満了データとなり、その結果、この領域を
復元する必要はない。）。結果的に得られるメッセージは、取引を通常のように
処理するとともに通常の方法で認証応答を顧客に送信する「正しい」取得者に送
信される。顧客は、他の任意の取引に対する場合のように認証応答に応答する。

【０１５９】 取引が国内のＳＰＡファシリティに送出されると、このファシリティは、上記
説明で示した機能を実行する。

【０１６０】クリアリング及び清算 ＳＰＡクリアリングメッセージは、全てのクリアリングメッセージのようにマ
スターカードＩＮＥＴ（クリアリング及び清算）に送出される。ＳＰＡ取引が認
識可能なＢＩＮを有するので、ＩＮＥＴは、擬似的なアカウント番号を「正しい
」アカウント番号に置換する。この取引に対する任意の例外処理が次にある場合
、「正しい」アカウント番号を擬似的なアカウント番号に変換できるＳＰＡファ
シリティに例外処理メッセージが送出されるように、メッセージに対して他の変
更が行われる。そのような変化を有するクリアリングメッセージは、通常の方法
で取引を処理するカード発行者に送信される。取得者が発行者にもなる場合、マ
スターカードは、クリアされた取引を、表示された変更及び適切な料金計算を行
う取得者／発行者に戻す。

【０１６１】例外処理 取引についてのメッセージを発行者から取得者又は顧客に戻す必要がある場合
、メッセージは、任意の取引メッセージを処理する場合のように発行者によって
処理される。取引記録中のデータによって、マスターカードファシリティにメッ
セージを送出し、マスターカードファシリティは、「正しい」アカウント番号を
擬似的なアカウント番号に戻す。その後、例外処理メッセージは、そのような他
の任意のメッセージのようにそれを処理する取得者に送出される。

【０１６２】 また、取得者と発行者との間で送信が行われる取引についての任意のドキュメ
ンテーションをＭＣＩによって変更し、取得者が擬似的なアカウント番号を受信
するとともに、発行者が「正しい」アカウント番号を受信するようにする。その
ようなデータが電子的であり、かつ、識別可能である場合、データは内的に変更
される。そのようなドキュメンテーションが全体的に電子的でない場合、正しい
アカウント番号及び擬似的なアカウント番号を反映する他の形態を形成すること
ができる。そのようなドキュメンテーションを直接取得者に送出する発行者に対
して、両方の番号を提供するよう要求することができる。

【０１６３】識別用のプラスチックカードの発行 一部の状況において、カードホルダは、インターネットを通じてチケットを購
入し、チケットが入場を許容するイベントの出現の際に、取引に使用されるカー
ドを発生してチケットの合法な処理を認証することを要求する。

【０１６４】 ＳＰＡプログラムの開始時に、カードホルダは、「識別目的のみ」であること
を明確に表すカードのように擬似的なアカウント番号を示す実際のプラスチック
カードを発行する。

【０１６５】 次いで、擬似的なアカウント番号を用いてカードホルダを合法的に認証する必
要がある顧客は、（マスターカードに適切な識別及び認証情報を提供することに
よって）マスターカードに登録し、顧客は、秘密キーが設けられるとともに、登
録の暗号プルーフとして認証を行う。その後、そのような顧客は、「正しい」ア
カウント番号を取得するために取引データと顧客の権利の両方を認証する暗号化
認証の下で擬似的なアカウント番号取引の詳細のコピーを提供することによって
、マスターカードファシリティから「正しい」アカウント番号を取得することが
できる。マスターカードは、暗号化された形態の「正しい」アカウント番号を顧
客に送り出し、その結果、カードホルダは、「正しい」アカウント番号に対応す
るカードを用いて識別される。

【０１６６】ＳＰＡウォレット動作：Ｍｏｄｅ−０取引処理 Ｍｏｄｅ−０は、「状態Ｃ」の擬似的なアカウント番号に対するウォレットと
ともにのみ使用される。それは、Ｍｏｄｅ−１を「状態Ａ」又は「状態Ｂ」で使
用する状況の下で使用される（ＳＰＡは、ＳＰＡ ＭＡＣ領域として使用可能な
「隠し」領域に対する識別子を見つけることができない。）。Ｍｏｄｅ−０で動
作する際に、ＰＣのＳＰＡは、単に顧客の支払いスクリーンの「支払い番号」領
域の擬似的なアカウント番号及びこのスクリーンの「満了日」領域の実際の満了
日の置換を行う。それは、Ｍｏｄｅ−１に対して説明したように顧客の支払いス
クリーンの他の銀行に充填を行う。 本発明は、上記実施の形態に限定されるものではなく、幾多の変更及び変形が
可能である。

【図面の簡単な説明】

【図１】 本発明の一つの実施態様による取引法に含まれる、いくつかの処理成
分のブロックダイアグラムである。

【図２】 本発明の一つの実施態様において、安全支払いアプリケーション初回
請求内部に供給される情報の表示である。

【図３】 本発明の一つの実施態様に従って、期限切れ日付フィールド値を入手
するために実行される行程を描いたフローダイアグラムである。

【図４】 本発明の一つの実施態様に従って、商人、入手者、サービスプロバイ
ダーおよび発行者の間での通信のフローを描いたフローダイアグラムである。

【図５】 本発明の一つの実施態様に従って、発行者、サービスプロバイダー、
入手者および商人の間での情報のフローを描いたフローダイアグラムである。

【図６】 本発明の一つの実施態様に従ってメッセージを送る別法を表わす図で
ある。

───────────────────────────────────────────────────── フロントページの続き (31)優先権主張番号 ０９／８０９，３６７ (32)優先日 平成13年３月15日(2001．3．15) (33)優先権主張国 米国（ＵＳ） (31)優先権主張番号 ０９／８３３，０４９ (32)優先日 平成13年４月11日(2001．4．11) (33)優先権主張国 米国（ＵＳ） (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ，ＴＲ)，ＯＡ(ＢＦ ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ， ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，Ｇ Ｍ，ＫＥ，ＬＳ，ＭＷ，ＭＺ，ＳＤ，ＳＬ，ＳＺ，ＴＺ ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ， ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＧ，ＡＬ，ＡＭ， ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，Ｂ Ｚ，ＣＡ，ＣＨ，ＣＮ，ＣＯ，ＣＲ，ＣＵ，ＣＺ，ＤＥ ，ＤＫ，ＤＭ，ＤＺ，ＥＣ，ＥＥ，ＥＳ，ＦＩ，ＧＢ， ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，Ｉ Ｎ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＡ，ＭＤ， ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＭＺ，ＮＯ，ＮＺ，Ｐ Ｌ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ， ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ (72)発明者 カール エム キャンベル アメリカ合衆国 ペンシルヴェニア州 19073 ニュートウ スクエア マリン ロード 809 Ｆターム(参考） 5B085 AE02 AE03 AE12 AE23 5J104 AA08 PA07 PA10 【要約の続き】 なアカウント数に関連した認証キーを発生するステップ と、（ｃ）前記認証キーを用いて、前記取引に特有のメ ッセージ認証コードを発生するステップと、（ｄ）前記 メッセージ認証コード及び前記擬似的なアカウント数を 有する認証要求メッセージを発生するステップと、 （ｅ）表された前記キー発生プロセス及び前記認証キー を用いて、メッセージ認証コードを検証するステップと を具えることを特徴とする方法を有する。

Claims (14)

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