非接触型支払カード取引変数を引渡すためにビットマップを使用する方法およびシステム
電子支払システムが、近接型支払カード型取引及び磁気ストライプカード型取引を共に処理すべく構成されている。磁気ストライプカード取引データは、一般的な業界標準ISO7811のデータ構造またはトラック中で、カード、リーダ、および取引認可または承認パーティの相互間で伝達される。動的認証コードのような近接型支払カード取引データは、同じ規格でフォーマット化されたデータ構造中の未使用空間内に配置される。未使用空間の利用可能性は、カード発行者またはベンダーによって変化する。発行者特有のビットマップは、磁気ストライプトラック内の任意データフィールド中の利用可能な空間へのインデックスを提供する。ビットマップも、カードの任意データフィールド中に格納する。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願のクロスリファレンス
本出願は、2004年7月15日に出願の米国暫定特許出願第60/588,624号に基づいて優先権を主張する。この特許出願は、その全体を参考文献として本願明細書に含める。
【背景技術】
【０００２】
現代の経済においては、支払取引用のプラスチックカードが至る所で使用されている。関係するすべてのパーティ（関係者）、例えば支払カード産業、消費者、銀行および販売業者が、このようなカードベースの支払取引の安全および不正防止に関心を有する。
【０００３】
初期のプラスチックカードでは、一般データ、例えばカード番号およびカード保有者の名前が刻印されていた。署名欄およびセキュリティプリンティングは、不正および偽造に対する保護を提供するために設けられたこのようなカードの特徴機能であった。これらのセキュリティ上の特徴機能は、販売員の視覚による確認のみに基づくので、不正が排除されなかった。
【０００４】
現在、プラスチックカードは、カード保有者情報および他のセキュリティおよび暗号化コードが機械可読の形式で格納された、カードの裏面に設けられた磁気ストライプを有する。データの機械可読性は、不正および偽造をより困難にする。磁気ストライプの物理構造およびデータ内容は、望ましい相互運用性（例えば、ほとんどの現金預払機カードが、世界中のすべての預払機に対応すること）を実現するために標準化されている。これを目的として、業界標準化組織およびグループ（例えば国際標準化機構（ISO）および国際電気標準会議（IEC））は、支払カードのための自主的な最小規格を公式化した。支払カードの磁気ストライプに適用可能な規格の例としては、ISO/IEC7811規格（「ISO7811」）があり、この規格は、支払カードの磁気ストライプのデータ構造および符号化についての最低要求を設定する。
【０００５】
ISO7811によると、磁気ストライプデータは、３つのトラックに配置しなければならない。磁気ストライプカードは、これら３つのトラックうちの何れか一つまたはこれらのトラックの組合せを有することができる。この規格によると、国際航空輸送協会(IATA)によって開発された第１トラックは、２１０bpiで７９個の７ビット文字用の空間を有する。第１トラックは、アスキー（ASCII）に基づく７ビット方式（６つのデータビットおよび１つのパリティビット）で符号化される。７番目のビットは、各バイトの終端にある奇数パリティビットである。オンライン金融取引のために米国銀行協会によって開発された第２トラックは、４０bpiで４０個の５ビット数字用の空間を有する。同様に金融取引に使用される第３トラックは、２１０bpiで１０７桁の数字用の空間を有する。
【０００６】
ISO7811は、さらに、トラック内をデータフィールドに区切り、それらを特定情報用に予約する。例えば、第１トラックは、会員番号、国番号、姓、名またはイニシャル、ミドルネームおよび有効期限その他の特定情報用の所定のデータフィールドを含む。データは、アスキー形式で符号化される。
【０００７】
表１に、トラック２用に推奨される標準化されたデータフィールド・フォーマットを示す。
【０００８】
【表１】
【０００９】
３つのトラックの各々はデータフィールドを含み、これらはカード発行者またはベンダー（販売者）による個別利用のために予約される。カード発行者またはベンダーは、しばしば、「任意データ」とラベル付けされた予約データフィールドを、静的な認証値またはベンダー特有の他の識別情報を格納するために利用する。例えば、譲受人マスターカードインターナショナル社（「マスターカード（登録商標）」）は、第２トラックの任意データフィールドに数字のカード検証コード値（CVC1）を格納することを選択している。CVC1値は、３桁の暗号化番号であり、磁気ストライプ情報が全く変更されていないことを保証するためにチェックされる。他のカードベンダーまたは発行者は、任意データフィールドに他のコードまたは値を格納することもあれば、何も格納しないこともある。
【００１０】
取引を処理するために、カードリーダ／端末は、カードの磁気ストライプトラックに記録されたフォーマット化された（書式付き）データを読み込む。フォーマット化されたデータは、取引の検証または承認のため発行者または銀行に送信することができる。
【００１１】
支払カード産業は、現在、半導体デバイス技術の開発成果を活用し、プラスチックの支払カードにより多くの機能および特徴機能を組み込んでいる。例えば、実際の集積回路チップを含むスマートカード、および近接読取り用に磁場または無線周波数識別（RFID）タグを使用する非接触型カードが現在利用可能である。スマートカードおよび／または近接型カードに内蔵された電子処理特徴機能は、安全なカード使用および不正防止のためのより厳格な解決法の展開を可能にする。例えば、いくつかの利用可能なスマートカードは、「カード上で」デジタル署名に基づくセキュリティ対策のための暗号化機能を実行するように構成されている。
【００１２】
【特許文献１】米国特許出願公開第20050127164号
【００１３】
このような新たな種類のカードに基づく電子支払システムは使用中であるか、または開発中である。例えば、譲受人マスターカードは、近接型支払カードによる電子支払システムを実現するための独自の仕様であるペイパス（PayPass）（登録商標）ISO/IEC14443実現仕様（「ペイパス（PayPass）」）を開発した。ペイパスで使用することのできるセキュリティ対策は、動的な認証値または認証数（CVC3）の生成に基づく。動的認証値は、各取引と共に変化する。従って、無認可の者が特定取引用のCVC3番号を得た場合であっても、この無認可の者は、このCVC3番号を次回のまたは何れかの取引用の認証値として使用することができない。（例えば、John Wankmuellerの米国特許出願公開第20050127164号明細書（特許文献１）を参照）。
【００１４】
新たなカード技術に基づく何れの電子支払システムも、新たなシステムが、磁気ストライプカードを処理するために設計された従来のインフラストラクチャ（基盤）（例えば、端末、カードリーダおよび事務代行（バックオフィス）操作）に対して後方互換性を有する場合にのみ、ユーザに受け入れられると考えられる。従って、磁気ストライプカードシステムおよび近接型支払カードシステムの双方で機能可能な支払カードの提供は、有利であろう。このようなカードの場合、磁気ストライプカードによる取引のためにISO7811によって要求されるデータフィールドまたは情報を妨害しないフォーマットで、動的認証値（CVC3）または他の近接型カード機能特有のデータを発行者または他の認証パーティ（関係者）に送信することが好ましい。磁気ストライプカードの運用に要求される標準化されたデータフィールドが妨害されないことを期待して、CVC3番号および近接型カード機能特有の他のデータを、磁気ストライプ・トラックデータフォーマットの任意データフィールドに配置することが提案されてきた。不都合なことに、ベンダーおよび発行者による任意データフィールドの使用法には、一貫性がない。例えば、ベンダーによって使用される静的認証値（例えばCVC2）は、３桁の数字でも４桁の数字でもあり得る。従って、任意データフィールド中のCVC3の配置に利用可能な空間は、任意データフィールドのベンダー符号化に応じてカードごとに変わり得る。任意データスペースのこのような様々な利用性は、近接型カード機能の関連データ（例えば、CVC3）を記憶するための空間の使用を標準化することを困難にする。
【００１５】
現在、近接型支払カード実現を既存の標準化された磁気ストライプ支払カード取引処理と互換にする方法が考えられている。既存の磁気ストライプカードインフラおよび処理と一緒に使用できる近接型カードの開発が注目されている。特に、磁気ストライプカードによる取引において使用される既存の標準化されたデータ構造または情報を妨害しない方法による、近接型カード関連データのフォーマット化が注目されている。
【発明の開示】
【発明が解決しようとする課題】
【００１６】
本発明は、既に設置されている、磁気ストライプカード取引を処理するための電子支払システムまたはインフラストラクチャと互換性のある形式での近接型カード取引データの通信のための標準化方法およびシステムを提供する。
【課題を解決するための手段】
【００１７】
標準化方法およびシステムは、近接型カード取引データ（例えば、動的認証コード）を、磁気ストライプカード取引の処理に一般的に使用されるISO7811バイトレベルにフォーマット化されたデータ構造中に配置または統合する。近接型支払カード取引データは、任意データフィールド（例えば第２トラックの任意データフィールド）の未使用部分に配置される。カード内の任意データフィールド中の未使用空間の利用可能性は、カード発行者またはベンダーが変えることができる。発行者またはベンダーに特有のビットマップは、カード内の任意データフィールドの利用可能な未使用空間を識別する。動的認証コード、未識別番号、自動取引カウンタおよび／または他の近接型カード取引パラメータが、ビットマップによって識別される利用可能な自由空間内の任意データフィールド中に配置される。
【００１８】
カードの任意データフィールド中の近接型カード機能データまたは数字のフレキシブル（自在）な配置方法は、カード機能に全く悪影響を与えない。カード挙動は、ベンダーによる任意データフィールドの使用法とは無関係である。
【００１９】
本発明のさらなる特徴、性質および様々な利点は、図面、付録および以下の実施例の詳細な説明より明らかになる。
【発明を実施するための最良の形態】
【００２０】
本発明は、近接型カード機能データまたは数字を磁気ストライプカードに使用される任意データフィールド中に配置するための標準化方法およびシステムを提供する。数字は、カード発行者またはベンダーが使用していない任意データフィールド中の利用可能空間内に格納される。任意データフィールド中のこのような数字の桁数およびその正確な桁位置は、ビットマップを用いてフレキシブル（自在）に割当てられる。ビットマップは、カードの任意データフィールド中に格納される。カードの任意データフィールド中の、近接型カード機能データまたは数字のフレキシブルな配置法は、カード機能に全く悪影響を与えない。カード挙動は、ベンダーによる任意データフィールドの使用法とは無関係である。
【００２１】
説明の都合上、本明細書では、本発明によるデータ配置方法を、トラック２内で規定される任意データフィールドを参照することによって説明する。しかし、本発明によるデータ配置方法は、更なるまたは別の任意データフィールド（例えば第１トラックの任意データフィールド）に容易に拡張されることは明らかである。さらに、本発明による格納方法は、本明細書では、取引の処理中にセキュリティ対策として生成されるカード認証コード（CVC3）番号の配置を例として用いて説明する。しかし、他のデータも同様に配置されまたは伝達することができることは明らかである。
【００２２】
標準化方法およびフォーマットは、システムが近接型支払カード取引および磁気ストライプカード取引の双方を処理できるように、適切な電子支払システムアプリケーションに組み込むことができる。近年、譲受人マスターカードインターナショナル社（「マスターカード」）は、近接型支払カード技術の実現のための独自仕様であるマスターカード・ペイパスISO/IEC14443実現仕様（「ペイパス」）を開発した。ペイパス実現は、ISO14443規格およびISO7811規格に整合し、本発明の原理を例示するのに好都合な例を提供する。ペイパス実現は「ペイパス・マグストライプ」アプリケーションを提供し、これは、近接型カードおよび磁気ストライプカードに基づく取引を処理できる。（図５参照）。ペイパス・マグストライプ・アプリケーションは、デビットおよびクレジット決済のための現在利用可能な磁気ストライプ・アプリケーションの拡張である。ペイパス・マグストライプは、磁気ストライプカード取引に現在使用されているものと同様の処理インフラストラクチャ（基盤）を使用する。例示目的でのペイパス実現の選択は好適なものに過ぎず、本発明の原理は、より一般的に、他の業界共通のまたは独自の規格の下で動作する電子支払装置およびシステムに適用されることは明らかである。
【００２３】
図５を参照すれば、相互作用中の支払カード（例えばペイパスカード１）とリーダ端末２との間での近接型支払カード取引において、セキュリティ手順の一部として、端末２は予測不能な数（UN）を生成して支払カードに送信する。その応答として、支払カード１は、UNの一部に基づいてCVC3番号を計算するとともに、計算したCVC3番号を端末に送信する。支払カード１は、CVC3番号を計算するためにカードに格納された秘密暗号鍵を使用することができる。あるいはまた、支払カード１は、UNの一部およびカードのアプリケーション取引カウンタ（ATC）に基づいてCVC3番号を計算するというカード発行者の選択肢で個人化することができる。この場合には、支払カード１は、計算したCVC3番号およびATCの双方を端末２に送信する。カードに格納されたビットマップ（BM）および位置CVC3のデータ要素（PCVC）は、端末２に、近接型支払カード取引データを任意データ空間内に配置するための規則を提供する。対象となる近接型支払カード取引のために、端末２は、この規則により、任意データフィールド中にATC、UNおよびCVC3番号をパッケージ化またはフォーマット化する。端末は、その後、取引の認可のために、磁気ストライプカード規格に従って、アクワイアラ（加盟店契約会社）のホスト４および／または発行者のホスト５に任意データフィールドを伝達することができる。端末２は、例えば、認可または承認（８、１１０）のため、第２トラックの一部としての任意データフィールドを、標準化されたメッセージ１００のデータ要素３５（DE35）中で発行者に送信することができる。
【００２４】
図１は、任意データフィールド（例えば、第２トラックの任意データフィールド）中の異なる位置の番号付けまたはインデックス付けを示す。任意データに存在する桁数を添字ｍによって示す。カードベンダーおよび発行者は、従来の支払システム用の任意データフィールドの一部を使用する。その結果、任意データフィールド中の小部分のみが、ペイパスデータを搬送するための手段として利用可能である。従って、UNおよびATCの異なる組合せの使用および任意データフィールド中のこのようなデータ要素の配置にはフレキシビリティ（柔軟性）が要求される。
【００２５】
例えば、最も一般な場合には、CVC3番号は、多様化された秘密鍵および次の入力データ：すなわちトラックデータの静的部分、カードのATC、および端末によって提供されるUNを用いることによって、ペイパスカードによって生成される。あらゆる例において、入力データ形式の全部が使用されているわけではなく、あるいは使用する必要はない。事務代行（バックオフィス）システム、およびカード発行者がトラックの任意データフィールド中で使用可能とする桁数に応じて、異なる組合せの入力データを使用してCVC3番号を生成することができる。
【００２６】
図２は、ビットマップと任意データフィールドの桁位置との関係を示す。ビットマップの各ビットは、任意データフィールド中の位置を参照する。ビットマップの最下位ビット（すなわち、右端のビットb1）は、位置p1を参照する。ビットマップ中のビット数qは、常に８の倍数である。数qは、式
q = ( ( m / 8 ) + 1 )
を介して任意データフィールドの桁数mと関係する。
【００２７】
従って、第２トラックの任意データフィールド（「第２トラックデータ」）の場合には、桁数mは13が最大であるので、ビットマップは16ビットまたは2バイトである。第１トラックの任意データフィールド（「第１トラックデータ」）の場合には、mの最大値は48であるので、ビットマップの長さは6バイトまたは48ビットである。
【００２８】
図３は、例示的な２バイトのビットマップ（BM = 0x031A）を示し、このビットマップは、第２トラックデータ（13桁）中の桁p10、p9、p5、p4およびp2を識別する。ペイパス・アプリケーションで使用される特定のビットマップは、UNおよびATCを配置するための第２トラックデータの特定の位置を指示することができる。別のビットマップの、位置CVC3（PCVC）は、CVC3番号を配置するための第２トラックデータ中の特定位置を指示するのに使用することができる。
【００２９】
ビットマップは、カード発行者またはベンダーの所望に応じて個人化することができるカードパラメータである。（例えば、カード個人化段階で）ビットマップを設計することによって、カード発行者は、ペイパスデータ（数字）の数、位置および使用法の十分なフレキシビリティを保つことができる。端末は、ビットマップを使用することによって、カード個人化段階においてベンダーによって指定された任意データ中の位置に、UNおよびATC数字を配置する。また端末は、ベンダー指定のビットマップに応じてCVC3数字を配置する。
【００３０】
端末は、バイナリ（２進）からBCDへの変換の役割を割り当てられている。この割当ては、カードの複雑性を低減し、取引性能を改善する。端末プロセスまたはアプリケーションが、任意データフィールドの充填または配置を全部行うので、カード上のプロセスは、ビットマップに関係するかあるいはビットマップを意識する必要がない。好適な実現では、ビットマップの値とは無関係に、カード上のプロセスは常に同一である。例えば、カード上のCVC3計算がATCに基づく場合には、カード上の計算は、常にATC全体（すなわち、２バイト全部）を使用する。端末は、ATCをバイナリコードからBCDコードに変換するとともに、ビットマップに示されるATC数字の最下位部分を任意データに置く。カード挙動は、配置されたATC数字の桁数および任意データフィールド中のこれらの数字の位置とは無関係である。
【００３１】
カード上のプロセスの独立性の他の例では、カードは、CVC3計算中に端末から受信したUN全体を含む。端末プロセスは、ビットマップに示されるＵＮの上位に０を付け、これにより、UNの関係部分のみが任意データフィールド中に配置される。例えば、ある特定のカード発行者特有のビットマップが、UN数字３桁のみを任意データフィールド中に配置することを示している場合には、端末はその上位に５つのゼロを付けてUNを送信しなければならない、というのはUNの長さは常に８桁でならないからである（例えば、UNの値が123である場合には、端末は00000123をカードに送信する）。カードは、UN 00000123の８桁全部をCVC3の計算に含め、一方で、端末は３桁の数字123のみを任意データフィールド中に配置する。他のカードについて、発行者特有のビットマップが、６桁のUNを任意データフィールドに配置することを示している場合には、端末はＵＮの上位に２つの０を付けてUNを送信しなければならない（例えば、UNの値が456789である場合には、端末は00456789をカードに送信する）。カードは、00456789の８桁全部をCVC3の計算に含め、一方で、端末は６つの数字456789のみを任意データフィールド中に配置する。これらの例は、カードの挙動は、任意データフィールドに含まれるUN数字の桁数および任意データフィールド中その位置とは無関係であることを示す。
【００３２】
カード挙動の独立性のさらに別の例として、カードによって返されるCVC3番号は常に２バイト長であり、かつバイナリ形式である。端末は、CVC3をBCD値に変換するとともに、PCVGビットマップに基づいて、任意データフィールド中に配置するCVC3数字の桁数を決定する。図４は、例示的なPCVGビットマップ（BM=0x00E0）を示し、このビットマップは、UNまたはATCの配置用のビットマップと同様に、カード上の処理および取引機能が、任意データフィールドに配置されたCVC3数字の桁数および位置とは無関係であることを保証する。
【００３３】
図６は、ペイパス・マグストライプ・アプリケーションを使用する取引（１００）の実行中に、ペイパスカードおよび端末との間で生じ得る相互作用および通信を示す図である。
【００３４】
取引１００の第１ステップ１０１では、端末はペイパス・マグストライプ・アプリケーションを選択する。ステップ１０２では、カードはファイル制御情報要求で応答する。要求された情報は、さらなる取引のためにカードが必要とするタグのリストおよび端末常駐データ要素の長さ（PDOL）を含むことができる。ステップ１０３では、端末は命令（GET PROCESSING OPTIONS：処理オプションを得る）を発行し、この命令は要求されたPDOL情報を含むことができる。ステップ１０４では、カードは、端末によって読み込まれるべきすべてのデータがSF1 1を有するファイルの第１レコードに含まれることを示すインジケータ（指標）（AIPおよびAFL）を返す。次に、ステップ１０５および１０６では、端末は命令（READ RECORD：記録の読み込み）を発行することによって、カードから静的データを取り出し、カードは適切な第１トラックデータおよび第２トラックデータおよびビットマップを返す。ステップ１０７では、端末は、ステップ１０６においてカードから返された予測不能な数のデータオブジェクトリスト（UDOL）の処理によって生じたデータ要素の連結リストであるデータフィールドを使用して、コマンド（COMPUTE CRYPTOGRAPHIC CHECKSUM：暗号チェックサムを計算する）発行する。このコマンドは、ペイパスカードにおける動的CVC3第２トラック番号の計算を開始させる。これに加えて、あるいはその代わりに、動的CVC3第１トラック番号を計算することができる。この計算は、カードに格納された秘密鍵を使用するとともに、端末によって送信されたUNおよび／またはカードのATCに基づく。ステップ１０９では、カードはATCおよび計算されたCVC3の第２トラック番号および／または第１トラック番号を端末に送信する。
【００３５】
近接型支払取引の関係データを第２トラックデータフォーマットに配置するために、端末は、カードによって提供されるビットマップを用いる本発明によるビットマップ・ガイド（案内）の手順を使用する。（図２〜４を参照）。端末は、CVC3第２トラック番号をBCD符号化数字に変換し、関係数字を、第２トラックデータの任意データフィールド中の、カードによって提供されるビットマップ（「CVC3用の第２トラックビットマップ（PCVC3Track2）」）に示される場所にコピーする。また端末は、UNの関係数字を、第２トラックデータの任意データフィールド中にコピーする。UN数字の桁数（nUN）は、任意データフィールド中の最下位にコピーする。ビットマップ（「UN用の第２トラックビットマップ」）は、端末が第２トラックデータの任意データフィールド中にUN数字をコピーしなければならない場所を指示する。（NATCTrackによって指示される）任意データフィールドに含めるべきATC数字の桁数が０でない場合には、端末は、ATCをBCD符号化数字に変換し、第２トラックデータの任意データフィールド中の関係ATC数字を、カードによって提供されたビットマップ（「ATC用の第２トラックビットマップ（PUNATCTrack）」）に示される場所にコピーする。
【００３６】
端末は、カードがREAD RECORDコマンド（ステップ１０５）に応答して第１トラックデータ（ステップ１０６）を返す場合には、同様のビットマップ・ガイドの手順を使用して、データを第１トラックの任意データフィールド中に配置することができる。トラック１データについては、端末は、カードによって返されたデータを、任意データフィールド中にコピーする前にアスキー符号化文字に変換する。
【００３７】
ビットマップの使用は、カードの複雑性に悪影響を及ぼすことなしに、任意データフィールドの利用可能な桁のフレキシブルかつ効率的な使用を可能にする。
【００３８】
本発明は、特にその好適な実施例を参照して説明してきたが、本発明の範囲を逸脱することなしに、様々な変形および変更を加えることができることは当業者にとって明らかである。従って、開示された本発明の実施例は単なる例示であり、本発明は請求項において特定した事項のみの範囲に限定される。
【図面の簡単な説明】
【００３９】
【図１】図１は、任意データフィールド中の異なる桁位置を番号付けまたはインデックス付けする方法を示す図表である。
【図２】図２は、ビットマップと任意データフィールドの桁位置との関係を示す図である。
【図３】図３は、例示的な２バイトビットマップ（BM=0x031A）を示す図であり、このビットマップは、本発明の原理による、第２トラックの任意データフィールド（１３桁）中の５つの使用可能な桁位置p10、p9、p5、p4およびp2を識別する。
【図４】図４は、例示的なPCVGビットマップ（BM=0x00E0）を示す図であり、このビットマップは、本発明の原理による、CVC3数字を配置することができる第２トラックの任意データフィールド（１３桁）中の３つの使用可能な桁位置p8、p7およびp5を識別する。
【図５】図５は、本発明の原理による、近接型支払カード取引および磁気ストライプカード取引の双方を処理できる電子支払システムの概略図である。
【図６】図６は、本発明の原理による、電子取引の実行中の近接型支払カードと端末との間の相互作用および通信を示す図である。
【技術分野】
【０００１】
関連出願のクロスリファレンス
本出願は、2004年7月15日に出願の米国暫定特許出願第60/588,624号に基づいて優先権を主張する。この特許出願は、その全体を参考文献として本願明細書に含める。
【背景技術】
【０００２】
現代の経済においては、支払取引用のプラスチックカードが至る所で使用されている。関係するすべてのパーティ（関係者）、例えば支払カード産業、消費者、銀行および販売業者が、このようなカードベースの支払取引の安全および不正防止に関心を有する。
【０００３】
初期のプラスチックカードでは、一般データ、例えばカード番号およびカード保有者の名前が刻印されていた。署名欄およびセキュリティプリンティングは、不正および偽造に対する保護を提供するために設けられたこのようなカードの特徴機能であった。これらのセキュリティ上の特徴機能は、販売員の視覚による確認のみに基づくので、不正が排除されなかった。
【０００４】
現在、プラスチックカードは、カード保有者情報および他のセキュリティおよび暗号化コードが機械可読の形式で格納された、カードの裏面に設けられた磁気ストライプを有する。データの機械可読性は、不正および偽造をより困難にする。磁気ストライプの物理構造およびデータ内容は、望ましい相互運用性（例えば、ほとんどの現金預払機カードが、世界中のすべての預払機に対応すること）を実現するために標準化されている。これを目的として、業界標準化組織およびグループ（例えば国際標準化機構（ISO）および国際電気標準会議（IEC））は、支払カードのための自主的な最小規格を公式化した。支払カードの磁気ストライプに適用可能な規格の例としては、ISO/IEC7811規格（「ISO7811」）があり、この規格は、支払カードの磁気ストライプのデータ構造および符号化についての最低要求を設定する。
【０００５】
ISO7811によると、磁気ストライプデータは、３つのトラックに配置しなければならない。磁気ストライプカードは、これら３つのトラックうちの何れか一つまたはこれらのトラックの組合せを有することができる。この規格によると、国際航空輸送協会(IATA)によって開発された第１トラックは、２１０bpiで７９個の７ビット文字用の空間を有する。第１トラックは、アスキー（ASCII）に基づく７ビット方式（６つのデータビットおよび１つのパリティビット）で符号化される。７番目のビットは、各バイトの終端にある奇数パリティビットである。オンライン金融取引のために米国銀行協会によって開発された第２トラックは、４０bpiで４０個の５ビット数字用の空間を有する。同様に金融取引に使用される第３トラックは、２１０bpiで１０７桁の数字用の空間を有する。
【０００６】
ISO7811は、さらに、トラック内をデータフィールドに区切り、それらを特定情報用に予約する。例えば、第１トラックは、会員番号、国番号、姓、名またはイニシャル、ミドルネームおよび有効期限その他の特定情報用の所定のデータフィールドを含む。データは、アスキー形式で符号化される。
【０００７】
表１に、トラック２用に推奨される標準化されたデータフィールド・フォーマットを示す。
【０００８】
【表１】
【０００９】
３つのトラックの各々はデータフィールドを含み、これらはカード発行者またはベンダー（販売者）による個別利用のために予約される。カード発行者またはベンダーは、しばしば、「任意データ」とラベル付けされた予約データフィールドを、静的な認証値またはベンダー特有の他の識別情報を格納するために利用する。例えば、譲受人マスターカードインターナショナル社（「マスターカード（登録商標）」）は、第２トラックの任意データフィールドに数字のカード検証コード値（CVC1）を格納することを選択している。CVC1値は、３桁の暗号化番号であり、磁気ストライプ情報が全く変更されていないことを保証するためにチェックされる。他のカードベンダーまたは発行者は、任意データフィールドに他のコードまたは値を格納することもあれば、何も格納しないこともある。
【００１０】
取引を処理するために、カードリーダ／端末は、カードの磁気ストライプトラックに記録されたフォーマット化された（書式付き）データを読み込む。フォーマット化されたデータは、取引の検証または承認のため発行者または銀行に送信することができる。
【００１１】
支払カード産業は、現在、半導体デバイス技術の開発成果を活用し、プラスチックの支払カードにより多くの機能および特徴機能を組み込んでいる。例えば、実際の集積回路チップを含むスマートカード、および近接読取り用に磁場または無線周波数識別（RFID）タグを使用する非接触型カードが現在利用可能である。スマートカードおよび／または近接型カードに内蔵された電子処理特徴機能は、安全なカード使用および不正防止のためのより厳格な解決法の展開を可能にする。例えば、いくつかの利用可能なスマートカードは、「カード上で」デジタル署名に基づくセキュリティ対策のための暗号化機能を実行するように構成されている。
【００１２】
【特許文献１】米国特許出願公開第20050127164号
【００１３】
このような新たな種類のカードに基づく電子支払システムは使用中であるか、または開発中である。例えば、譲受人マスターカードは、近接型支払カードによる電子支払システムを実現するための独自の仕様であるペイパス（PayPass）（登録商標）ISO/IEC14443実現仕様（「ペイパス（PayPass）」）を開発した。ペイパスで使用することのできるセキュリティ対策は、動的な認証値または認証数（CVC3）の生成に基づく。動的認証値は、各取引と共に変化する。従って、無認可の者が特定取引用のCVC3番号を得た場合であっても、この無認可の者は、このCVC3番号を次回のまたは何れかの取引用の認証値として使用することができない。（例えば、John Wankmuellerの米国特許出願公開第20050127164号明細書（特許文献１）を参照）。
【００１４】
新たなカード技術に基づく何れの電子支払システムも、新たなシステムが、磁気ストライプカードを処理するために設計された従来のインフラストラクチャ（基盤）（例えば、端末、カードリーダおよび事務代行（バックオフィス）操作）に対して後方互換性を有する場合にのみ、ユーザに受け入れられると考えられる。従って、磁気ストライプカードシステムおよび近接型支払カードシステムの双方で機能可能な支払カードの提供は、有利であろう。このようなカードの場合、磁気ストライプカードによる取引のためにISO7811によって要求されるデータフィールドまたは情報を妨害しないフォーマットで、動的認証値（CVC3）または他の近接型カード機能特有のデータを発行者または他の認証パーティ（関係者）に送信することが好ましい。磁気ストライプカードの運用に要求される標準化されたデータフィールドが妨害されないことを期待して、CVC3番号および近接型カード機能特有の他のデータを、磁気ストライプ・トラックデータフォーマットの任意データフィールドに配置することが提案されてきた。不都合なことに、ベンダーおよび発行者による任意データフィールドの使用法には、一貫性がない。例えば、ベンダーによって使用される静的認証値（例えばCVC2）は、３桁の数字でも４桁の数字でもあり得る。従って、任意データフィールド中のCVC3の配置に利用可能な空間は、任意データフィールドのベンダー符号化に応じてカードごとに変わり得る。任意データスペースのこのような様々な利用性は、近接型カード機能の関連データ（例えば、CVC3）を記憶するための空間の使用を標準化することを困難にする。
【００１５】
現在、近接型支払カード実現を既存の標準化された磁気ストライプ支払カード取引処理と互換にする方法が考えられている。既存の磁気ストライプカードインフラおよび処理と一緒に使用できる近接型カードの開発が注目されている。特に、磁気ストライプカードによる取引において使用される既存の標準化されたデータ構造または情報を妨害しない方法による、近接型カード関連データのフォーマット化が注目されている。
【発明の開示】
【発明が解決しようとする課題】
【００１６】
本発明は、既に設置されている、磁気ストライプカード取引を処理するための電子支払システムまたはインフラストラクチャと互換性のある形式での近接型カード取引データの通信のための標準化方法およびシステムを提供する。
【課題を解決するための手段】
【００１７】
標準化方法およびシステムは、近接型カード取引データ（例えば、動的認証コード）を、磁気ストライプカード取引の処理に一般的に使用されるISO7811バイトレベルにフォーマット化されたデータ構造中に配置または統合する。近接型支払カード取引データは、任意データフィールド（例えば第２トラックの任意データフィールド）の未使用部分に配置される。カード内の任意データフィールド中の未使用空間の利用可能性は、カード発行者またはベンダーが変えることができる。発行者またはベンダーに特有のビットマップは、カード内の任意データフィールドの利用可能な未使用空間を識別する。動的認証コード、未識別番号、自動取引カウンタおよび／または他の近接型カード取引パラメータが、ビットマップによって識別される利用可能な自由空間内の任意データフィールド中に配置される。
【００１８】
カードの任意データフィールド中の近接型カード機能データまたは数字のフレキシブル（自在）な配置方法は、カード機能に全く悪影響を与えない。カード挙動は、ベンダーによる任意データフィールドの使用法とは無関係である。
【００１９】
本発明のさらなる特徴、性質および様々な利点は、図面、付録および以下の実施例の詳細な説明より明らかになる。
【発明を実施するための最良の形態】
【００２０】
本発明は、近接型カード機能データまたは数字を磁気ストライプカードに使用される任意データフィールド中に配置するための標準化方法およびシステムを提供する。数字は、カード発行者またはベンダーが使用していない任意データフィールド中の利用可能空間内に格納される。任意データフィールド中のこのような数字の桁数およびその正確な桁位置は、ビットマップを用いてフレキシブル（自在）に割当てられる。ビットマップは、カードの任意データフィールド中に格納される。カードの任意データフィールド中の、近接型カード機能データまたは数字のフレキシブルな配置法は、カード機能に全く悪影響を与えない。カード挙動は、ベンダーによる任意データフィールドの使用法とは無関係である。
【００２１】
説明の都合上、本明細書では、本発明によるデータ配置方法を、トラック２内で規定される任意データフィールドを参照することによって説明する。しかし、本発明によるデータ配置方法は、更なるまたは別の任意データフィールド（例えば第１トラックの任意データフィールド）に容易に拡張されることは明らかである。さらに、本発明による格納方法は、本明細書では、取引の処理中にセキュリティ対策として生成されるカード認証コード（CVC3）番号の配置を例として用いて説明する。しかし、他のデータも同様に配置されまたは伝達することができることは明らかである。
【００２２】
標準化方法およびフォーマットは、システムが近接型支払カード取引および磁気ストライプカード取引の双方を処理できるように、適切な電子支払システムアプリケーションに組み込むことができる。近年、譲受人マスターカードインターナショナル社（「マスターカード」）は、近接型支払カード技術の実現のための独自仕様であるマスターカード・ペイパスISO/IEC14443実現仕様（「ペイパス」）を開発した。ペイパス実現は、ISO14443規格およびISO7811規格に整合し、本発明の原理を例示するのに好都合な例を提供する。ペイパス実現は「ペイパス・マグストライプ」アプリケーションを提供し、これは、近接型カードおよび磁気ストライプカードに基づく取引を処理できる。（図５参照）。ペイパス・マグストライプ・アプリケーションは、デビットおよびクレジット決済のための現在利用可能な磁気ストライプ・アプリケーションの拡張である。ペイパス・マグストライプは、磁気ストライプカード取引に現在使用されているものと同様の処理インフラストラクチャ（基盤）を使用する。例示目的でのペイパス実現の選択は好適なものに過ぎず、本発明の原理は、より一般的に、他の業界共通のまたは独自の規格の下で動作する電子支払装置およびシステムに適用されることは明らかである。
【００２３】
図５を参照すれば、相互作用中の支払カード（例えばペイパスカード１）とリーダ端末２との間での近接型支払カード取引において、セキュリティ手順の一部として、端末２は予測不能な数（UN）を生成して支払カードに送信する。その応答として、支払カード１は、UNの一部に基づいてCVC3番号を計算するとともに、計算したCVC3番号を端末に送信する。支払カード１は、CVC3番号を計算するためにカードに格納された秘密暗号鍵を使用することができる。あるいはまた、支払カード１は、UNの一部およびカードのアプリケーション取引カウンタ（ATC）に基づいてCVC3番号を計算するというカード発行者の選択肢で個人化することができる。この場合には、支払カード１は、計算したCVC3番号およびATCの双方を端末２に送信する。カードに格納されたビットマップ（BM）および位置CVC3のデータ要素（PCVC）は、端末２に、近接型支払カード取引データを任意データ空間内に配置するための規則を提供する。対象となる近接型支払カード取引のために、端末２は、この規則により、任意データフィールド中にATC、UNおよびCVC3番号をパッケージ化またはフォーマット化する。端末は、その後、取引の認可のために、磁気ストライプカード規格に従って、アクワイアラ（加盟店契約会社）のホスト４および／または発行者のホスト５に任意データフィールドを伝達することができる。端末２は、例えば、認可または承認（８、１１０）のため、第２トラックの一部としての任意データフィールドを、標準化されたメッセージ１００のデータ要素３５（DE35）中で発行者に送信することができる。
【００２４】
図１は、任意データフィールド（例えば、第２トラックの任意データフィールド）中の異なる位置の番号付けまたはインデックス付けを示す。任意データに存在する桁数を添字ｍによって示す。カードベンダーおよび発行者は、従来の支払システム用の任意データフィールドの一部を使用する。その結果、任意データフィールド中の小部分のみが、ペイパスデータを搬送するための手段として利用可能である。従って、UNおよびATCの異なる組合せの使用および任意データフィールド中のこのようなデータ要素の配置にはフレキシビリティ（柔軟性）が要求される。
【００２５】
例えば、最も一般な場合には、CVC3番号は、多様化された秘密鍵および次の入力データ：すなわちトラックデータの静的部分、カードのATC、および端末によって提供されるUNを用いることによって、ペイパスカードによって生成される。あらゆる例において、入力データ形式の全部が使用されているわけではなく、あるいは使用する必要はない。事務代行（バックオフィス）システム、およびカード発行者がトラックの任意データフィールド中で使用可能とする桁数に応じて、異なる組合せの入力データを使用してCVC3番号を生成することができる。
【００２６】
図２は、ビットマップと任意データフィールドの桁位置との関係を示す。ビットマップの各ビットは、任意データフィールド中の位置を参照する。ビットマップの最下位ビット（すなわち、右端のビットb1）は、位置p1を参照する。ビットマップ中のビット数qは、常に８の倍数である。数qは、式
q = ( ( m / 8 ) + 1 )
を介して任意データフィールドの桁数mと関係する。
【００２７】
従って、第２トラックの任意データフィールド（「第２トラックデータ」）の場合には、桁数mは13が最大であるので、ビットマップは16ビットまたは2バイトである。第１トラックの任意データフィールド（「第１トラックデータ」）の場合には、mの最大値は48であるので、ビットマップの長さは6バイトまたは48ビットである。
【００２８】
図３は、例示的な２バイトのビットマップ（BM = 0x031A）を示し、このビットマップは、第２トラックデータ（13桁）中の桁p10、p9、p5、p4およびp2を識別する。ペイパス・アプリケーションで使用される特定のビットマップは、UNおよびATCを配置するための第２トラックデータの特定の位置を指示することができる。別のビットマップの、位置CVC3（PCVC）は、CVC3番号を配置するための第２トラックデータ中の特定位置を指示するのに使用することができる。
【００２９】
ビットマップは、カード発行者またはベンダーの所望に応じて個人化することができるカードパラメータである。（例えば、カード個人化段階で）ビットマップを設計することによって、カード発行者は、ペイパスデータ（数字）の数、位置および使用法の十分なフレキシビリティを保つことができる。端末は、ビットマップを使用することによって、カード個人化段階においてベンダーによって指定された任意データ中の位置に、UNおよびATC数字を配置する。また端末は、ベンダー指定のビットマップに応じてCVC3数字を配置する。
【００３０】
端末は、バイナリ（２進）からBCDへの変換の役割を割り当てられている。この割当ては、カードの複雑性を低減し、取引性能を改善する。端末プロセスまたはアプリケーションが、任意データフィールドの充填または配置を全部行うので、カード上のプロセスは、ビットマップに関係するかあるいはビットマップを意識する必要がない。好適な実現では、ビットマップの値とは無関係に、カード上のプロセスは常に同一である。例えば、カード上のCVC3計算がATCに基づく場合には、カード上の計算は、常にATC全体（すなわち、２バイト全部）を使用する。端末は、ATCをバイナリコードからBCDコードに変換するとともに、ビットマップに示されるATC数字の最下位部分を任意データに置く。カード挙動は、配置されたATC数字の桁数および任意データフィールド中のこれらの数字の位置とは無関係である。
【００３１】
カード上のプロセスの独立性の他の例では、カードは、CVC3計算中に端末から受信したUN全体を含む。端末プロセスは、ビットマップに示されるＵＮの上位に０を付け、これにより、UNの関係部分のみが任意データフィールド中に配置される。例えば、ある特定のカード発行者特有のビットマップが、UN数字３桁のみを任意データフィールド中に配置することを示している場合には、端末はその上位に５つのゼロを付けてUNを送信しなければならない、というのはUNの長さは常に８桁でならないからである（例えば、UNの値が123である場合には、端末は00000123をカードに送信する）。カードは、UN 00000123の８桁全部をCVC3の計算に含め、一方で、端末は３桁の数字123のみを任意データフィールド中に配置する。他のカードについて、発行者特有のビットマップが、６桁のUNを任意データフィールドに配置することを示している場合には、端末はＵＮの上位に２つの０を付けてUNを送信しなければならない（例えば、UNの値が456789である場合には、端末は00456789をカードに送信する）。カードは、00456789の８桁全部をCVC3の計算に含め、一方で、端末は６つの数字456789のみを任意データフィールド中に配置する。これらの例は、カードの挙動は、任意データフィールドに含まれるUN数字の桁数および任意データフィールド中その位置とは無関係であることを示す。
【００３２】
カード挙動の独立性のさらに別の例として、カードによって返されるCVC3番号は常に２バイト長であり、かつバイナリ形式である。端末は、CVC3をBCD値に変換するとともに、PCVGビットマップに基づいて、任意データフィールド中に配置するCVC3数字の桁数を決定する。図４は、例示的なPCVGビットマップ（BM=0x00E0）を示し、このビットマップは、UNまたはATCの配置用のビットマップと同様に、カード上の処理および取引機能が、任意データフィールドに配置されたCVC3数字の桁数および位置とは無関係であることを保証する。
【００３３】
図６は、ペイパス・マグストライプ・アプリケーションを使用する取引（１００）の実行中に、ペイパスカードおよび端末との間で生じ得る相互作用および通信を示す図である。
【００３４】
取引１００の第１ステップ１０１では、端末はペイパス・マグストライプ・アプリケーションを選択する。ステップ１０２では、カードはファイル制御情報要求で応答する。要求された情報は、さらなる取引のためにカードが必要とするタグのリストおよび端末常駐データ要素の長さ（PDOL）を含むことができる。ステップ１０３では、端末は命令（GET PROCESSING OPTIONS：処理オプションを得る）を発行し、この命令は要求されたPDOL情報を含むことができる。ステップ１０４では、カードは、端末によって読み込まれるべきすべてのデータがSF1 1を有するファイルの第１レコードに含まれることを示すインジケータ（指標）（AIPおよびAFL）を返す。次に、ステップ１０５および１０６では、端末は命令（READ RECORD：記録の読み込み）を発行することによって、カードから静的データを取り出し、カードは適切な第１トラックデータおよび第２トラックデータおよびビットマップを返す。ステップ１０７では、端末は、ステップ１０６においてカードから返された予測不能な数のデータオブジェクトリスト（UDOL）の処理によって生じたデータ要素の連結リストであるデータフィールドを使用して、コマンド（COMPUTE CRYPTOGRAPHIC CHECKSUM：暗号チェックサムを計算する）発行する。このコマンドは、ペイパスカードにおける動的CVC3第２トラック番号の計算を開始させる。これに加えて、あるいはその代わりに、動的CVC3第１トラック番号を計算することができる。この計算は、カードに格納された秘密鍵を使用するとともに、端末によって送信されたUNおよび／またはカードのATCに基づく。ステップ１０９では、カードはATCおよび計算されたCVC3の第２トラック番号および／または第１トラック番号を端末に送信する。
【００３５】
近接型支払取引の関係データを第２トラックデータフォーマットに配置するために、端末は、カードによって提供されるビットマップを用いる本発明によるビットマップ・ガイド（案内）の手順を使用する。（図２〜４を参照）。端末は、CVC3第２トラック番号をBCD符号化数字に変換し、関係数字を、第２トラックデータの任意データフィールド中の、カードによって提供されるビットマップ（「CVC3用の第２トラックビットマップ（PCVC3Track2）」）に示される場所にコピーする。また端末は、UNの関係数字を、第２トラックデータの任意データフィールド中にコピーする。UN数字の桁数（nUN）は、任意データフィールド中の最下位にコピーする。ビットマップ（「UN用の第２トラックビットマップ」）は、端末が第２トラックデータの任意データフィールド中にUN数字をコピーしなければならない場所を指示する。（NATCTrackによって指示される）任意データフィールドに含めるべきATC数字の桁数が０でない場合には、端末は、ATCをBCD符号化数字に変換し、第２トラックデータの任意データフィールド中の関係ATC数字を、カードによって提供されたビットマップ（「ATC用の第２トラックビットマップ（PUNATCTrack）」）に示される場所にコピーする。
【００３６】
端末は、カードがREAD RECORDコマンド（ステップ１０５）に応答して第１トラックデータ（ステップ１０６）を返す場合には、同様のビットマップ・ガイドの手順を使用して、データを第１トラックの任意データフィールド中に配置することができる。トラック１データについては、端末は、カードによって返されたデータを、任意データフィールド中にコピーする前にアスキー符号化文字に変換する。
【００３７】
ビットマップの使用は、カードの複雑性に悪影響を及ぼすことなしに、任意データフィールドの利用可能な桁のフレキシブルかつ効率的な使用を可能にする。
【００３８】
本発明は、特にその好適な実施例を参照して説明してきたが、本発明の範囲を逸脱することなしに、様々な変形および変更を加えることができることは当業者にとって明らかである。従って、開示された本発明の実施例は単なる例示であり、本発明は請求項において特定した事項のみの範囲に限定される。
【図面の簡単な説明】
【００３９】
【図１】図１は、任意データフィールド中の異なる桁位置を番号付けまたはインデックス付けする方法を示す図表である。
【図２】図２は、ビットマップと任意データフィールドの桁位置との関係を示す図である。
【図３】図３は、例示的な２バイトビットマップ（BM=0x031A）を示す図であり、このビットマップは、本発明の原理による、第２トラックの任意データフィールド（１３桁）中の５つの使用可能な桁位置p10、p9、p5、p4およびp2を識別する。
【図４】図４は、例示的なPCVGビットマップ（BM=0x00E0）を示す図であり、このビットマップは、本発明の原理による、CVC3数字を配置することができる第２トラックの任意データフィールド（１３桁）中の３つの使用可能な桁位置p8、p7およびp5を識別する。
【図５】図５は、本発明の原理による、近接型支払カード取引および磁気ストライプカード取引の双方を処理できる電子支払システムの概略図である。
【図６】図６は、本発明の原理による、電子取引の実行中の近接型支払カードと端末との間の相互作用および通信を示す図である。
【特許請求の範囲】
【請求項１】
近接型支払カードの取引パラメータを、第１トラック、第２トラック、および第３トラックのデータ構造（複数トラック）を含む業界標準（ISO7811）フォーマット化されたデータ構造中に統合する方法において、
（ａ）前記近接型支払カード上のトラック内の任意データフィールド中の未使用位置を識別するビットマップを提供するステップと；
（ｂ）前記近接型支払カードの取引パラメータを、前記トラック内の前記任意データフィールド中の、前記ビットマップによって識別される位置に配置するステップとを具え、
これにより、結果的なトラックデータが、磁気ストライプカード取引を処理する電子支払システム・インフラストラクチャと互換のフォーマットを有することを特徴とする近接型支払カードの取引パラメータの統合方法。
【請求項２】
前記近接型支払カードの取引パラメータが、動的認証コード（CVC3）を含み、ビットマップを提供するステップ（ａ）が、前記第２トラック内の１３桁数字の任意データフィールド中の未使用位置を識別する２バイトのビットマップを提供することを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記近接型支払カードの取引パラメータが、動的認証コード（CVC3）、自動取引カウンタ（ATC）、および未識別の番号（UN）のうち少なくとも２つを含み、ビットマップを提供するステップ（ａ）が、前記トラック内の前記任意データフィールド中の、現存する前記近接型支払カードの取引パラメータを配置するための未使用位置を識別する、対応する複数のビットマップを提供することを含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記近接型支払カードの取引パラメータが、近接型支払カードと端末との間の取引に関係し、ステップ（ｂ）がさらに、端末プロセスを用いて、前記近接型支払カードの取引パラメータを、前記トラック内の前記任意データフィールド中の前記ビットマップによって識別される位置に配置することを含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記端末が前記近接型支払カードにUNを送信し、前記支払型カードは、受信した前記UNの一部に基づいてCVC3値を計算し、計算したCVC3値を前記トラック内の前記任意データフィールド中に配置するために、前記端末に伝達することを特徴とする請求項４に記載の方法。
【請求項６】
前記近接型カードが、前記UNの一部およびATCに基づいてCVC3値を計算し、計算したCVC3値および前記ATCを前記トラック内の前記任意データフィールド中に配置するために、前記端末に伝達することを特徴とする請求項５に記載の方法。
【請求項７】
前記近接型カードが、前記計算したCVC3値をバイナリ形式で前記端末に伝達し、前記端末は、受信した前記CVC3値を、前記トラック内の前記任意データフィールド中に配置する前に、BCD形式に変換することを特徴とする請求項５に記載の方法。
【請求項８】
近接型支払カードおよび端末が関与する取引に関係する取引パラメータを、第１トラック、第２トラック、および第３トラックのデータ構造（複数トラック）を含む業界標準（ISO7811）フォーマット化されたデータ構造中に統合するためのシステムであって、
（ａ）前記近接型支払カード上のトラック内の任意データフィールド中の未使用位置を識別するビットマップと；
（ｂ）前記取引パラメータを、前記トラック内の前記任意データフィールド中の、前記ビットマップによって識別される位置に配置して、結果的なトラックデータが、磁気ストライプカード取引を処理する電子支払システム・インフラストラクチャと互換のフォーマットを有するように構成されたアプリケーションと
を具えていることを特徴とする近接型支払カードの取引パラメータの統合システム。
【請求項９】
前記取引パラメータが、動的認証コード（CVC3）を含み、前記ビットマップが、前記第２トラック内の１３桁数字の任意データフィールド中の未使用位置を特定する２バイトのビットマップを含むことを特徴とする請求項８に記載のシステム。
【請求項１０】
前記取引パラメータが、動的認証コード（CVC3）、自動取引カウンタ（ATC）、および未識別の番号（UN）のうち少なくとも２つを含み、前記ビットマップが、現存する前記取引パラメータを配置するための、前記トラック内の前記任意データフィールド中の未使用位置を識別する、対応する複数のビットマップを含むことを特徴とする請求項８に記載のシステム。
【請求項１１】
前記アプリケーションが、前記取引パラメータを、前記トラック内の前記任意データフィールド中の、前記ビットマップによって識別される位置に配置する端末アプリケーションを含むことを特徴とする請求項８に記載のシステム。
【請求項１２】
前記端末が前記近接型支払カードにUNを送信し、前記支払型カードは、受信した前記UNの一部に基づいてCVC3値を計算し、計算したCVC3値を前記端末に伝達し、前記端末アプリケーションは、受信した前記CVC3を前記トラック内の前記任意データフィールド中に配置するように構成されていることを特徴とする請求項１１に記載のシステム。
【請求項１３】
前記近接型カードが、前記UNの一部およびATCに基づいてCVC3値を計算し、計算したCVC3値および前記ATCを前記端末に伝達し、前記端末アプリケーションは、受信した前記CVC3値および前記ATCを前記トラック内の前記任意データフィールド中に配置するように構成されていることを特徴とする請求項１２に記載のシステム。
【請求項１４】
前記近接型カードが、前記計算したCVC3値をバイナリ形式で前記端末に伝達し、前記端末アプリケーションは、受信した前記CVC3値をBCD形式に変換し、BCD形式の前記CVC3を前記トラック内の前記任意データフィールド中に配置するように構成されていることを特徴とする請求項１２に記載のシステム。
【請求項１】
近接型支払カードの取引パラメータを、第１トラック、第２トラック、および第３トラックのデータ構造（複数トラック）を含む業界標準（ISO7811）フォーマット化されたデータ構造中に統合する方法において、
（ａ）前記近接型支払カード上のトラック内の任意データフィールド中の未使用位置を識別するビットマップを提供するステップと；
（ｂ）前記近接型支払カードの取引パラメータを、前記トラック内の前記任意データフィールド中の、前記ビットマップによって識別される位置に配置するステップとを具え、
これにより、結果的なトラックデータが、磁気ストライプカード取引を処理する電子支払システム・インフラストラクチャと互換のフォーマットを有することを特徴とする近接型支払カードの取引パラメータの統合方法。
【請求項２】
前記近接型支払カードの取引パラメータが、動的認証コード（CVC3）を含み、ビットマップを提供するステップ（ａ）が、前記第２トラック内の１３桁数字の任意データフィールド中の未使用位置を識別する２バイトのビットマップを提供することを含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記近接型支払カードの取引パラメータが、動的認証コード（CVC3）、自動取引カウンタ（ATC）、および未識別の番号（UN）のうち少なくとも２つを含み、ビットマップを提供するステップ（ａ）が、前記トラック内の前記任意データフィールド中の、現存する前記近接型支払カードの取引パラメータを配置するための未使用位置を識別する、対応する複数のビットマップを提供することを含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記近接型支払カードの取引パラメータが、近接型支払カードと端末との間の取引に関係し、ステップ（ｂ）がさらに、端末プロセスを用いて、前記近接型支払カードの取引パラメータを、前記トラック内の前記任意データフィールド中の前記ビットマップによって識別される位置に配置することを含むことを特徴とする請求項１に記載の方法。
【請求項５】
前記端末が前記近接型支払カードにUNを送信し、前記支払型カードは、受信した前記UNの一部に基づいてCVC3値を計算し、計算したCVC3値を前記トラック内の前記任意データフィールド中に配置するために、前記端末に伝達することを特徴とする請求項４に記載の方法。
【請求項６】
前記近接型カードが、前記UNの一部およびATCに基づいてCVC3値を計算し、計算したCVC3値および前記ATCを前記トラック内の前記任意データフィールド中に配置するために、前記端末に伝達することを特徴とする請求項５に記載の方法。
【請求項７】
前記近接型カードが、前記計算したCVC3値をバイナリ形式で前記端末に伝達し、前記端末は、受信した前記CVC3値を、前記トラック内の前記任意データフィールド中に配置する前に、BCD形式に変換することを特徴とする請求項５に記載の方法。
【請求項８】
近接型支払カードおよび端末が関与する取引に関係する取引パラメータを、第１トラック、第２トラック、および第３トラックのデータ構造（複数トラック）を含む業界標準（ISO7811）フォーマット化されたデータ構造中に統合するためのシステムであって、
（ａ）前記近接型支払カード上のトラック内の任意データフィールド中の未使用位置を識別するビットマップと；
（ｂ）前記取引パラメータを、前記トラック内の前記任意データフィールド中の、前記ビットマップによって識別される位置に配置して、結果的なトラックデータが、磁気ストライプカード取引を処理する電子支払システム・インフラストラクチャと互換のフォーマットを有するように構成されたアプリケーションと
を具えていることを特徴とする近接型支払カードの取引パラメータの統合システム。
【請求項９】
前記取引パラメータが、動的認証コード（CVC3）を含み、前記ビットマップが、前記第２トラック内の１３桁数字の任意データフィールド中の未使用位置を特定する２バイトのビットマップを含むことを特徴とする請求項８に記載のシステム。
【請求項１０】
前記取引パラメータが、動的認証コード（CVC3）、自動取引カウンタ（ATC）、および未識別の番号（UN）のうち少なくとも２つを含み、前記ビットマップが、現存する前記取引パラメータを配置するための、前記トラック内の前記任意データフィールド中の未使用位置を識別する、対応する複数のビットマップを含むことを特徴とする請求項８に記載のシステム。
【請求項１１】
前記アプリケーションが、前記取引パラメータを、前記トラック内の前記任意データフィールド中の、前記ビットマップによって識別される位置に配置する端末アプリケーションを含むことを特徴とする請求項８に記載のシステム。
【請求項１２】
前記端末が前記近接型支払カードにUNを送信し、前記支払型カードは、受信した前記UNの一部に基づいてCVC3値を計算し、計算したCVC3値を前記端末に伝達し、前記端末アプリケーションは、受信した前記CVC3を前記トラック内の前記任意データフィールド中に配置するように構成されていることを特徴とする請求項１１に記載のシステム。
【請求項１３】
前記近接型カードが、前記UNの一部およびATCに基づいてCVC3値を計算し、計算したCVC3値および前記ATCを前記端末に伝達し、前記端末アプリケーションは、受信した前記CVC3値および前記ATCを前記トラック内の前記任意データフィールド中に配置するように構成されていることを特徴とする請求項１２に記載のシステム。
【請求項１４】
前記近接型カードが、前記計算したCVC3値をバイナリ形式で前記端末に伝達し、前記端末アプリケーションは、受信した前記CVC3値をBCD形式に変換し、BCD形式の前記CVC3を前記トラック内の前記任意データフィールド中に配置するように構成されていることを特徴とする請求項１２に記載のシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公表番号】特表２００８−５０８５７８（Ｐ２００８−５０８５７８Ａ）
【公表日】平成２０年３月２１日（２００８．３．２１）
【国際特許分類】
【出願番号】特願２００７−５２１６９６（Ｐ２００７−５２１６９６）
【出願日】平成１７年７月１５日（２００５．７．１５）
【国際出願番号】ＰＣＴ／ＵＳ２００５／０２５２２１
【国際公開番号】ＷＯ２００６／０２００７３
【国際公開日】平成１８年２月２３日（２００６．２．２３）
【出願人】（５００５５７８６４）マスターカード インターナシヨナル インコーポレーテツド (18)
【Ｆターム（参考）】
【公表日】平成２０年３月２１日（２００８．３．２１）
【国際特許分類】
【出願日】平成１７年７月１５日（２００５．７．１５）
【国際出願番号】ＰＣＴ／ＵＳ２００５／０２５２２１
【国際公開番号】ＷＯ２００６／０２００７３
【国際公開日】平成１８年２月２３日（２００６．２．２３）
【出願人】（５００５５７８６４）マスターカード インターナシヨナル インコーポレーテツド (18)
【Ｆターム（参考）】
[ Back to top ]