動的検証値を生成するための方法とシステム
【解決手段】 取引用に検証値を動的に生成し、そのような値を使って支払サービスアプリケーションの信頼性を検証するための方法とシステム。動的に生成される検証値は、ＩＣクレジットカードやスマートカードなどの支払デバイス上で生成され、支払データに埋め込まれ、ＰＯＳ端末装置に送信される。あるいは、支払データは支払デバイスによりＰＯＳ端末装置に送信され、そこで検証値が生成された後、前記支払データ中に埋め込まれる。前記埋め込まれた検証値はサービスプロバイダによって使用され、前記取引の信頼性が検証される。前記方法とシステムは、非接触（無線）環境及び非無線環境で使用されてもよい。
【発明の詳細な説明】
【背景技術】
【０００１】
金融取引に係わる方法およびデバイスが増加し、新しい展開を広げる中、旧来の詐欺や偽造等の問題が依然存在する。事実、クレジットまたはデビットベースの取引をもっと魅力的にし、現金の代わりとしてすぐに利用できるアプリケーション及びデバイスが開発されるにつれて、それに比例して詐欺や偽造活動の増加が見られる。
【０００２】
取引カードの不正使用から金融機関、消費者および商業者を保護するために、業界はホログラム、特殊オーバーレイヤ、及びすかし模様等の詐欺や偽造を減らすための多くの機能を開発してきた。しかしながら、無線環境における金融取引が増加するに従って、それらの機能の多くは効果が薄れてきていると見られている。同様に、金融手段として、物理的なプラスチックカードの代わりに電子デバイスがますます使用されるに従って、取引の当事者を確認するための、顧客の署名やホログラムのような方法を使用する能力が有効でなくなってきている。
【０００３】
クレジットカード業界においてよく見られる詐欺の主要源の１つは、スキミングである。これは、カードを偽造するために、カードの磁気ストライプデータを電子的にコピーすることを指す。初期のスキミングは隠蔽が困難な、面倒な機器を必要とした。クレジットカード技術がより精巧になるにつれて、スキミングに使われる技術も向上してきている。
【０００４】
更に、スキミングの新たな方法も出現している。たとえば、ある例では、小型の窃盗器が端末内に埋め込まれ、集めたカードデータの回収のために取り出されるまで、数週間の間、放置されて、その間何百ものカード番号が集められる。また、もっと悪質なスキミングの方法の１つでは、通話の盗聴を伴い、前記端末とクレジットカード発行人の間の通話回線が盗聴され、通信文字列からカードデータが盗聴される。通話盗聴のもっとも精妙な例の１つでは、スキミング犯が発行者の地域データセンタの隣にオフィスを借り、発行者のコンピュータへ行く回線が盗聴された。盗聴された回線は、スキミング犯のサイトのコンピュータにリダイレクトされた。さらに悪いことに、スキミング犯は遠隔地からクレジットカード番号を回収できるように、それらのコンピュータに遠隔アクセスをすることができた。ある推定によると、スキミングは毎年金融機関に何百、何億ドルもの負担をかけている。更に、１部の業界アナリストによると、スキミングされた各カードは詐欺が発覚する前に少なくとも２，０００ドルの取引に使用されると推定している。
【０００５】
スキミングは、主に磁気ストライプ・ベースの取引を蝕んでいる現象である。これは、取引カードの裏に付けられ、３つの別々のトラックに様々なデータを保存する磁気ストライプが受身の媒体であるためである。つまり、コピーおよび原物間でまったく相違なしに、磁気ストライプのデジタル内容を完全にコピーすることができる。主に、これは磁気ストライプ取引が正当であることに依存するものであるのは、ＰＯＳ端末装置が前記磁気ストライプ上にあるデータを単に読込むことしか要されていないためである。
【０００６】
スキミングを防止可能にする主な手段の１つは、消費者が取引カードの所在をしっかりと把握することである。これによって、消費者は、カードが不当なデバイスを通されるのを防止することができる。しかし、磁気ストライプの非接触カードが発達し、現在の支払環境に迅速な取引の期待をもたらすにつれて、従来のスキミング問題もそれに付随してきている。実際、無線環境において、磁気ストライプデータをスキミングする機会は、より広がっている。無線環境において、仮想スキミング犯は、有線ベースの環境のスキミングで必要となる、スキミングするカードを物理的に所有する必要も、物理装置（例えばＰＯＳ端末装置、通信回線、その他）のいずれにもアクセスする必要がない。スキミング犯は、消費者または小売商に気づかれずに、無線取引を傍受し、カードからＰＯＳ端末装置へ転送されるデータをコピーすることができる。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
それでもなお、処理能力を有するＩＣカードまたは類似したデバイスに磁気ストライプデータおよび磁気ストライプ支払アプリケーションを使用することは増加している。したがって、ここで必要となるのは、動的に取引を承認するために使用可能な検証値を生成することである。この検証値は、各々の取引で異なるため、このような支払サービスの承認方法は、スキミングの機会を大幅に減少させる。したがって、ある取引において使用されたデータがスキミングされたとしても、スキミングされた検証値は次の取引では無効なので、続いて取引をする際にデータは役に立たなくなる。
【課題を解決するための手段】
【０００８】
本発明は、ＩＣクレジットカード等の支払デバイス上に行われる支払サービスの信頼性を確認するための検証値をその支払サービスが取引に使用される度に動的に生成するためのシステムと方法を記載するものである。各々の取引において、検証値は、前記支払サービスに特有のデータから支払デバイス上で動的に生成される。前記支払デバイスからクレジットカード端末などのＰＯＳ端末装置へ送信される支払データに、前記検証値は埋め込まれる。ＰＯＳ端末装置は、前記支払データを前記埋め込まれた検証データと一緒に、支払ネットワーク（前記支払データをサービスプロバイダのコンピュータに送信する）に送信するが、前記検証データは、磁気ストライプのクレジットカードトラック１及び／またはトラック２データの形でもよい。前記サービスプロバイザのコンピュータは、独立して検証値を生成する。前記サービスプロバイダ生成の検証値が前記支払デバイス生成の検証値と一致しない場合、取引は認可されない。
【０００９】
代替の実施例において、前記支払デバイス上で各取引ごとに生成される支払データは、前記支払データが生成された前記支払デバイスからクレジットカード端末のようなＰＯＳ端末装置に送信される。検証値は、前記支払データと前記ＰＯＳ端末装置内に含まれる情報を使用して、前記ＰＯＳ端末装置によって生成される。前記ＰＯＳ端末装置は、前記支払データを前記埋め込まれた検証データと一緒に、支払ネットワーク（前記支払データをサービスプロバイダのコンピュータに送信する）に送信するが、前記検証データは、磁気ストライプのクレジットカードトラック１及び／またはトラック２のデータの形でもよい。前記サービスプロバイダのコンピュータは、個別に検証値を生成する。前記サービスプロバイダ生成の検証値が前記支払デバイス生成の検証値と一致しない場合、取引は認可されない。
【００１０】
本発明は、磁気ストライプトラック１および／またはトラック２のデータが任意のインターフェース（接触ベースのインタフェース及び無線インタフェースを含む）を通じて交換される任意の取引に使用可能である。
【発明を実施するための最良の形態】
【００１１】
本発明の実施形態の側面、特徴、利点、および長所は、以下の説明、添付の請求の範囲および添付の図面によって明確にされる。
【００１２】
本発明の説明の前に、本発明は本明細書で記載される特定の方法、デバイスまたはプロトコールは変化するので、これらに限定されないことは理解されるべきである。説明において使用される用語は、特定のバージョンまたは実施形態を記載するためのものであって、本発明の範囲は添付の請求の範囲を限定するためのものではない。本発明の範囲は添付の請求の範囲によってのみ限定される。特に、本発明は金融取引と関連して記載されるが、本発明はいかなる電子データ交換においても使用可能であることは言うまでもない。
【００１３】
また、本明細書中、及び、添付の請求の範囲で用いられる単数形のもの、「ある」、「１」、「前記」等が付くものは複数のものが含まれると理解されるべきである（そうでないことが文脈から明示されない限り）。このように、たとえば、「鍵」に対する参照は、１若しくはそれ以上の鍵及びそれの相等物に対する参照であることは当業者等には理解される。そうでないと定義されていない限り、本明細書で使用される技術及び科学用語は当業者によって一般に理解される意味と同じである。本明細書で記載されるものに類似または相当する任意の方法及びデバイスが、本発明の実施形態の実際の使用及びテストで使用可能であるが、下記には好ましい方法とデバイスについて説明する。本明細書において言及される全ての公報は引用により本明細書に組み込まれる。ここで、従来の発明によるそのような開示に対して本発明が先行しないものであると自認すると解釈されるべきではない。
【００１４】
通常、本発明は各取引ごとにカード検証値を動的に生成し、そのような値を使って前記支払サービスが確実なものであり、スキミングされていないことを確認するための方法とシステムを提供する。動的に生成されたカード検証値（本明細書において「ｄＣＶＶ」と称される）は、支払デバイスで生成されて、支払データに埋め込まれて、ＰＯＳ端末装置に送られる。代替の実施形態において、支払データは支払デバイスから受け取られ、検証値はＰＯＳ端末装置によって生成され、前記検証値は前記支払データに埋め込まれる。
【００１５】
１実施形態において、前記ＰＯＳ端末装置が受け取るデータは、前記ＰＯＳ端末装置によって単に支払データ（例えば、埋め込まれたｄＣＶＶのない標準の磁気ストライプトラック１および／またはトラック２データ）と解釈される。前記受信データは、前記ＰＯＳ端末装置から支払ネットワークに送信され、次に前記サービスプロバイダに送られる。前記サービスプロバイダが、前記取引はｄＣＶＶが必要であると決定すると、サービスプロバイダは個別に検証値を生成する。前記サービスプロバイダによって生成された検証値が前記支払デバイスから受け取られるｄＣＶＶと一致しない場合、前記取引は、潜在的に不正として認識され許可されない。
【００１６】
代替の実施形態において、データは前記ＰＯＳ端末装置によって受信されて、検証値を生成するために前記ＰＯＳ端末装置によって使われる。前記受信データは、前記ＰＯＳ端末装置から支払ネットワークに送信され、次に前記サービスプロバイダに渡される。前記サービスプロバイダは、個別に検証値を生成する。前記サービスプロバイダによって生成される検証値が前記支払デバイスから受け取られるｄＣＶＶと一致しない場合、前記取引は、潜在的に不正として認識され許可されない。
【００１７】
本出願において、用語「支払デバイス」は、本明細書において記載される取引またはデータ交換において使用可能な、マイクロプロセッサを有する任意のデバイスを意味する。前述の一般性を限定することなしに、「支払デバイス」は、ＩＣカード（スマートカードとも一般に公知の）、メモリーカード、携帯電話、パーソナル携帯情報機器（ＰＤＡ）、携帯電子デバイスまたはコンピュータを含むものとする。
【００１８】
本出願において、「非接触」または「無線」は、２つのデバイス間のデータ交換において、前記デバイスが物理的に接続する必要なしにデータ交換が可能な、いかなる通信方法またはプロトコール（独自開発のプロトコールを含む）を意味する。前述の一般性を制限することなしに、「非接触」または「無線」は、レーザー、無線周波、赤外線通信、Ｂｌｕｅｔｏｏｔｈまたは無線ＬＡＮによるデータ転送を含むものとする。
【００１９】
本出願において、用語「支払サービス」は、支払デバイスおよび他の任意のデバイス間またはロケーション間でのデータ交換を生じさせる支払デバイスで使用される任意のアプリケーションを意味する。当然のことながら、「支払サービス」は金融アプリケーションに限定されるものではない。
【００２０】
本出願において、金融アプリケーションに関連する「支払データ」は、取引を実行するために前記支払サービスによって使用されるデータ要素を意味し、金融取引以外の場合は、本発明に独特の任意の必要データ要素を意味する。たとえば、前記支払サービスが磁気ストライプのクレジットカード取引である場合、「支払データ」はトラック１及び／またはトラック２データを有し、主アカウント番号、失効日、サービスコードおよび任意データ等であることは当業者には明らかである。「支払データ」は、また一意のカードＩＤ番号またはサービスプロバイダ用の一意の識別番号を含んでもよい。
【００２１】
１実施形態において、前記支払データは、支払デバイスにあるメモリに存在する。前記支払デバイスは、また、アプリケーション取引カウンタ（ＡＴＣ）を維持する。前記ＡＴＣは最初、サービスプロバイダによって予め定められた値にセットされる。その後で、前記ＡＴＣは各取引毎にインクリメントされる。あるいは、前記ＡＴＣは各取引毎に、初期の所定値からデクリメントされてもよい。前記ＡＴＣは、任意の長さの値が可能である。さらに、前記支払サービスを使用するサービスプロバイダは、前記サービスプロバイダのコンピュータにアクセス可能な対応するＡＴＣを維持する。下記にさらに詳細に説明するように、この対応するＡＴＣは、スキミングされた可能性がある支払サービスを認識するために使用される。代替の実施形態において、暗号、デジタル署名、または取引データに基づくハッシュ値が、ＡＴＣの代わりにまたは一緒に使用される。
【００２２】
前記支払サービスが起動される度に、認証目的のためにｄＣＶＶが支払デバイスで生成される。図１は、本発明による、各々の取引用にｄＣＶＶの生成方法が示される。まず最初に、予め定められた長さの数字列が作られる。この数字列は、前記支払サービスの前記アカウント番号またはＰＡＮ１０４の対応する左端の桁上にＡＴＣ１０２をオーバーレイして（１０１）作成する。この数字列は、右側で支払サービス用の失効日と支払コードが連結されて、前記連結値１０６が生成される。必要であれば、埋め込み文字１０８が連結値１０６の右側に連結されて（１１０）、予め定められた固定長の数字列１１２を形成する。好適な実施形態において、この数字列１１２は、１２８ビットの長さである（但し、任意の長さの数字列が使用可能である）。前記埋め込み文字１０８は、前記支払サービスとサービスプロバイダーの両方で認識されている、一連の０、１、または任意の他の数値からなる。前記数字列１１２は、同等の長さの２つのブロック、ブロックＡ１１６およびブロックＢ１１８に二分される。ブロックＡ１１６は、次に最初の暗号鍵１２０によって暗号化される（１２１）。前記暗号化ステップ１２１の結果は、ブロックＡ１１６に等しい長さのブロックＣ１２２である。ブロックＣ１２２は、次にブロックＢ１１８によって排他的論理和演算（ＸＯＲ）されて（１２３）、ブロックＤ１２４が生成される。ブロックＤ１２４は次に第２の暗号鍵１２６によって暗号化され（１２５）、ブロックＥ１２８が生成される。ブロックＥ１２８は次に復号鍵１３０を使用して復号され（１２９）、ブロックＦ１３２が生成される。ブロックＦ１３２は次に第４の暗号鍵１３４を使用して暗号化され（１３３）、ブロックＧ１３６が生成される。
【００２３】
前記第１の暗号鍵１２０、前記第２の暗号鍵１２６、前記第３の暗号鍵１３０および前記第４の暗号鍵１３４が任意の予め選択された値を取る事が可能であることは、当業者には明らかである。本発明の実施形態において、前記第１の暗号鍵１２０、前記第２の暗号鍵１２６および前記第４の暗号鍵１３４は、同等であって、前記第３の暗号化とは異なる値である。図１の方法において利用される暗号鍵値の他の代替は、本発明の範囲内である。
【００２４】
好適な実施形態において、前記第１の暗号鍵１２０、前記第２の暗号鍵１２６、前記第３の暗号鍵１３０および前記第４の暗号鍵１３４は、前記支払デバイスにあるデータから派生する一意の鍵の値を取る。使用される際、各支払サービスは、マスタ派生鍵を使ってサービスプロバイダによって個別化される。前記マスタ派生鍵は支払サービスと一緒に、バッチで（すなわち、複数のサービスが同じマスタ派生鍵を受け取る）、または個別に使用される。各々の支払デバイスは、支払サービスに対して一意の鍵を派生する機能によって個別化される。図２は、好適な実施形態において使用される２つの一意の鍵を引き出すための方法である。アカウント番号２０１、アカウント・シーケンス番号２０２、アカウント番号の逆数２０３およびアカウント・シーケンス番号の逆数２０４は、一緒に連結されて連結値２１０が生成される。必要であるならば、予め定められた固定長の文字列を作るために、連結値２１０は、０または他の値を埋め込んでもよい（２１１）。好適な実施形態において、前記連結値２１０は１２８ビットの長さであるが、前記連結値はこの長さに限定されるものではない。前記連結値２１０は、次に各々の暗号化段階の暗号鍵として前記マスタ派生鍵２２１を使用して暗号化される（２２０）。使用される暗号化は、暗号化方法の任意のタイプを含むことができる。たとえば、この暗号化ステップは、トリプルＤＥＳ暗号化を利用することができる。前記暗号化ステップ２２０から生じる値は、アカウント番号によって識別される、アプリケーション用の一意の派生鍵またはＵＤＫ２３０である。２つの追加鍵、ＵＤＫＡ２４０およびＵＤＫＢ２４１は、前記ＵＤＫから派生する。前記ＵＤＫ２３０からのＵＤＫＡ２４０およびＵＤＫＢ２４１の派生は、任意の形式でよく、前記ＵＤＫ２３０の左端半分の値をＵＤＫＡ２４０に割り当てること、また前記ＵＤＫ２３０の右端半分の値をＵＤＫＢ２４１に割り当てることを含む。あるいは、前記ＵＤＫＡ２４０は、前記ＵＤＫ２３０から代替、または別に予め定められたビットシーケンスを選ぶことによって派生させ、残りのビットは前記ＵＤＫＢ２４１に割り当ててもよい。さらに、ＵＤＫＡ２４０およびＵＤＫＢ２４１は同等の長さの中である必要性はない。
【００２５】
図１で提示される方法の結果に戻る。図３は、ｄＣＶＶを生成するために必要となる更なる処理を記載する。ブロックＧ１３６に格納された値の各々のニブル（４ビットグループ）は、２つの別々の繰り返し過程にかけられて、各々のニブルの値が評価される。図３に示すように、ブロックＧ１３６の最も重要な桁（例えば左端）から開始し、各順次ニブルを調べて、もしニブルが０から９（を含む）の範囲の値を含む場合、その値は抽出され（３０１）、以前に抽出された値がある場合はその右に連結することにより新たな数字列（本明細書中で保持列として言及される）中に入れられる（３０５）。その結果、保持文字列が０から９（その数を含む）までの範囲の一連の値を含むことになり、ブロックＧ１３６において現れるのと同じ順序で保持列の左から右に現れる。
【００２６】
次に第２の評価が再度実行されるが、ブロックＧ１３６の最も重要な桁から開始され、各順次ニブルが調べられる。前記ニブルが１０（Ａ）から１５（Ｆ）（その数を含む）の範囲の１６進数の値を含む場合、その値は抽出される（３１０）。前記抽出された値は、次に前記１６進値Ａを前記抽出値から引くことにより十進制にされ、０から５までの範囲の十進数の値になる（３１５）。この十進法にされた値は、次に前記保持列の右端の値の右側に連結される（３２０）。
【００２７】
ブロックＧの全ニブルが上記のように２度調べられると、前記保持列の３つの最も重要なニブル（例、左端）が抽出される（３２５）。この３桁の値が、前記取引用のｄＣＶＶである。他のビット数を前記二回調べられたニブル列から抽出して、取引用のｄＣＶＶを生成してもよい。さらに、異なるニブル、例えば最も右のニブルを、取引用のｄＣＶＶとして使用してもよい。ただし、前記左端の３つのニブルは、好適な実施形態を示す。
【００２８】
一度生成されると、前記ｄＣＶＶは前記支払デバイスからＰＯＳ端末装置に転送される支払データに埋め込まれる。前記ＰＯＳ端末装置によって受信されるデータは、標準の支払データとして前記ＰＯＳ端末装置に現れる。つまり、前記ＰＯＳ端末装置はｄＣＶＶが埋め込まれているかどうか、そのようなｄＣＶＶがどこに位置するかを判定することはできない。前記ＰＯＳ端末装置に対して、前記支払デバイスから受け取られたデータにｄＣＶＶが埋め込まれていることを示すものはない。
【００２９】
図４は、前記支払デバイスから前記ＰＯＳ端末装置へ送信される、ｄＣＶＶが埋め込まれた支払データの典型的なレコード形式を表す。図４のレコード形式は、前記支払サービスのために、失効日４０２およびサービスコード４０３を、主アカウント番号４０１に連結することによって作られる。好適な実施形態において、前記主アカウント番号４０１は１６桁の長さで、前記失効日４０２は４桁の長さ、及び前記サービスコード４０３は、３桁の長さである。しかし、前記主アカウント番号４０１、前記失効日４０２および前記サービスコード４０３は、これらの長さに限定されない。次に他の使用のために通常確保されるフィールドにおいて、ｄＣＶＶがこのレコードに埋め込まれたことを示す数値がインジケータ４０５として配置される。このインジケータの値は、前記支払デバイス上で前記アプリケーションを使用したサービスプロバイダによって把握される。次に、ＰＩＮ検証データのために一般に確保されるフィールドに前記ＡＴＣ４１０が配置される。最後に、前記ｄＣＶＶ４１５はレコードの右に連結される。レコードの残りは、追加の選択的データを含んでもよい。
【００３０】
代替として、図５において、前記支払デバイスから前記ＰＯＳ端末装置に転送される、ｄＣＶＶが埋め込まれた支払情報の第２の典型的な形式が示される。図５の形式は、前記支払サービス用の主アカウント番号５０１に、失効日５０２、サービスコード５０３、ＰＶＫＩ５０４およびＰＩＮ検証データ５０５のためのフィールドを、連結することによって作られる。好適な実施形態において、前記主アカウント番号５０１は１６桁の長さ、前記失効日５０２は４桁の長さ、前記サービスコード５０３は３桁の長さ、そして、前記ＰＶＫＩ５０４は１桁の長さ、前記ＰＩＮ検証データ５０５は４桁の長さである。しかし、前記主アカウント番号５０１、前記失効日５０２、前記サービスコード５０３、前記ＰＶＫＩ５０４および前記ＰＩＮ検証データ５０５は、これらの長さに限定されるものではない。次に、単一のデータフィールド５１０においてそれぞれ動的に生成された前記ＣＶＶ、前記ＡＴＣ、および動的ＣＶＶが埋め込まれたことを識別するためにサービスプロバイダによって使用されるインジケータが順番に格納される。前記レコードの残りは、追加の選択的データを有してもよい。
【００３１】
本発明の重要な観点は、動的に作られたＣＶＶを利用するシステムによって、使用される支払サービスの信頼性を前記サービスプロバイダが判定できるようになることである。この承認ステップは、販売業者、個々のＰＯＳ端末装置、あるいは他の第三者またはデバイスに任されない。図６は、支払アプリケーションがスキミングされているかどうかの判定を行うために、前記支払デバイスで利用される支払アプリケーションの信頼性をサービスプロバイダが評価できるように、どのようにｄＣＶＶが非接触の環境において使用されるかを示す。図６では非接触の環境の実施形態で示されるが、本発明がこの種の環境に限定されるものではなく、磁気ストライプトラック１および／またはトラック２のデータがそのようなデータを送信するための任意の方法または手段を使用して交換される場合のどの取引でも使用可能である。図６に示されるように、前記支払デバイスは、好ましくは上述の方法を使用して前記ｄＣＶＶ６０１を生成する。前記ｄＣＶＶは、前記支払データ６０５に埋め込まれる。これに関しては、図４または図５に示される典型的なレコード形式が利用されてもよい。埋め込まれたｄＣＶＶを有する支払データは、前記ＰＯＳ端末装置６１０にデータ通信によって伝送される。前記ＰＯＳ端末装置は、前記の受信データを支払データの標準形式で認識し、前記サービスプロバイダのコンピュータ６１５に通常支払ネットワーク（図示せず）を通じて前記データストリームを転送する。前記サービスプロバイダのコンピュータは、埋め込まれたｄＣＶＶを有する支払データを受信し（６２０）、適切なインジケータを調べて、前記取引が非接触の取引であるかどうかの判定をする（６２５）。前記サービスプロバイダのコンピュータが、前記取引は非接触の取引でなかったと決定した場合、前記取引はその通常の方法において処理される（６３０）。前記サービスプロバイダのコンピュータが、前記取引は非接触だったと決定した場合、前記サービスプロバイダのコンピュータは支払デバイスから受信したＡＴＣを前記サービスプロバイダのコンピュータに格納された対応するＡＴＣと比べ、前記受信されたＡＴＣが予期されていた次のＡＴＣであるかどうかを判定する（６３５）。前記支払デバイスから受信されたＡＴＣが予期される次のＡＴＣでない場合、前記支払デバイスで使用された支払サービスはスキミングされている可能性を有する（６４０）。予期される次のＡＴＣが受信された場合、前記サービスプロバイダのコンピュータは、上述と同じプロセスを使用して当該取引用にｄＣＶＶを個別に再生成する（６４５）。前記のサービスプロバイダ生成のｄＣＶＶが前記支払デバイスから受け取ったｄＣＶＶに一致する（６５０）場合、前記サービスプロバイダは前記の支払アプリケーションは信頼できるとみなす（６５５）。前記サービスプロバイダのコンピュータは、次の認証のために、前記支払デバイス６６０から受け取ったＡＴＣをこれまで前記サービスプロバイダのコンピュータ中に格納されていたＡＴＣと入れ替える。前記サービスプロバイダ生成のｄＣＶＶが前記支払デバイスから受信されたｄＣＶＶと一致しない場合、前記取引は不正の可能性を持つので、終了される（６６５）。
【００３２】
図６の方法は、非接触の取引と関連して説明されたが、それに限定されるものではない。たとえば、前記方法は、特定の閾値より上の取引に関連して使用されてもよい。そのような場合、前記サービスプロバイダは、前記アプリケーションを使用する際、上記閾値より上の取引用にｄＣＶＶを生成するように前記アプリケーションを構成する。次に、ステップ６２５において問い合わせられるインジケータは、上記閾値より上の取引のために設定される。同様に、前記方法は他の任意の取引条件に関連して使用可能で、これには地理的位置、使用パターンまたは他の任意の条件が含まれるが、これらに限定されるものではない。
【００３３】
代替の実施形態において、前記支払デバイスは、支払データをクレジットカード端末装置のようなＰＯＳ端末装置に送信する（７０１）。前記ＰＯＳ端末装置は、前記データを受信して、前記取引用に検証値を計算する（７０５）。前記検証値は、様々な方法で計算可能であるが、これには、前記ＰＯＳ端末装置によって提供される一意の取引番号、タイムスタンプ、またはタイムスタンプに追加される取引金額が含まれるが、これらに限定されるものではない。前記ＰＯＳ端末装置は、次に前記支払データに検証値および追加データを埋め込みおよび／または追加する（７１０）。前記追加データは、前記取引を検証するためにサービスプロバイダのコンピュータで必要とされる。前記ＰＯＳ端末装置は、次に前記サービスプロバイダのコンピュータに（おそらく支払ネットワーク（図示せず）を通じて）データストームを渡す（７１５）。前記サービスプロバイダのコンピュータは、前記検証値を有する支払データを受信する（７２０）。前記サービスプロバイダのコンピュータは、任意で、前記ＰＯＳ端末装置によって埋め込みまたは付随された追加データの少なくとも一部を、前記サービスプロバイダのコンピュータに保存されている対応するデータと比較し、前記の受信データが正しいかどうかを判定する（７２５）。前記ＰＯＳ端末装置からの受信データが不適当な場合、前記取引データはスキミングされた可能性がある（７３０）。正しいデータが受信される場合、前記サービスプロバイダのコンピュータは個別に前記ＰＯＳ端末装置が使用するのと、同じプロセスを利用して、該当取引のための検証値を再生成する（７３５）。前記サービスプロバイダ生成の検証値が前記ＰＯＳ端末装置から受け取った検証値と一致する場合（７４０）、前記サービスプロバイダは前記支払アプリケーションは信頼性があるとみなす（７４５）。前記サービスプロバイダのコンピュータは次に、任意で、前記サービスプロバイダのコンピュータ内に今まで保存されていた追加データを次に続く認証のために前記支払デバイスから受け取った追加データによって更新する（７５０）。前記サービスプロバイダ生成の検証値が前記ＰＯＳ端末装置から受け取った検証値と一致しない場合、前記取引は不正である可能性があるので、終了される（７５５）。
【００３４】
前記説明は、発明の原理を図示するためだけのものであるとみなされる。更に、多くの修正と変更が当業者において容易に行われるので、本発明を図及び説明にある通りの構成に限定されるべきではない。したがって、すべての適切な修正および同等物が必要とされる場合、これらは本発明の範囲内にあるとみなされる。
【図面の簡単な説明】
【００３５】
【図１】図１は、本発明で使用される暗号化データブロックを生成する方法を示す。
【図２】図２は、支払デバイスに存在するデータから、一意の派生鍵を生成する方法を示す。
【図３】図３は、本発明によるカード検証値を動的に生成するために暗号化データブロックの一部を抽出するための方法を表す。
【図４】図４は、本発明の実施形態で使用される典型的なレコード形式を表す。
【図５】図５は、本発明の実施形態で使用される他の典型的な形式を表す。
【図６】図６は、取引を認証するために動的に生成された検証値を使用した好適な方法のフローチャートである。
【図７】図７は、取引を認証するために動的に生成された検証値を使用した代替方法のフローチャートである。
【背景技術】
【０００１】
金融取引に係わる方法およびデバイスが増加し、新しい展開を広げる中、旧来の詐欺や偽造等の問題が依然存在する。事実、クレジットまたはデビットベースの取引をもっと魅力的にし、現金の代わりとしてすぐに利用できるアプリケーション及びデバイスが開発されるにつれて、それに比例して詐欺や偽造活動の増加が見られる。
【０００２】
取引カードの不正使用から金融機関、消費者および商業者を保護するために、業界はホログラム、特殊オーバーレイヤ、及びすかし模様等の詐欺や偽造を減らすための多くの機能を開発してきた。しかしながら、無線環境における金融取引が増加するに従って、それらの機能の多くは効果が薄れてきていると見られている。同様に、金融手段として、物理的なプラスチックカードの代わりに電子デバイスがますます使用されるに従って、取引の当事者を確認するための、顧客の署名やホログラムのような方法を使用する能力が有効でなくなってきている。
【０００３】
クレジットカード業界においてよく見られる詐欺の主要源の１つは、スキミングである。これは、カードを偽造するために、カードの磁気ストライプデータを電子的にコピーすることを指す。初期のスキミングは隠蔽が困難な、面倒な機器を必要とした。クレジットカード技術がより精巧になるにつれて、スキミングに使われる技術も向上してきている。
【０００４】
更に、スキミングの新たな方法も出現している。たとえば、ある例では、小型の窃盗器が端末内に埋め込まれ、集めたカードデータの回収のために取り出されるまで、数週間の間、放置されて、その間何百ものカード番号が集められる。また、もっと悪質なスキミングの方法の１つでは、通話の盗聴を伴い、前記端末とクレジットカード発行人の間の通話回線が盗聴され、通信文字列からカードデータが盗聴される。通話盗聴のもっとも精妙な例の１つでは、スキミング犯が発行者の地域データセンタの隣にオフィスを借り、発行者のコンピュータへ行く回線が盗聴された。盗聴された回線は、スキミング犯のサイトのコンピュータにリダイレクトされた。さらに悪いことに、スキミング犯は遠隔地からクレジットカード番号を回収できるように、それらのコンピュータに遠隔アクセスをすることができた。ある推定によると、スキミングは毎年金融機関に何百、何億ドルもの負担をかけている。更に、１部の業界アナリストによると、スキミングされた各カードは詐欺が発覚する前に少なくとも２，０００ドルの取引に使用されると推定している。
【０００５】
スキミングは、主に磁気ストライプ・ベースの取引を蝕んでいる現象である。これは、取引カードの裏に付けられ、３つの別々のトラックに様々なデータを保存する磁気ストライプが受身の媒体であるためである。つまり、コピーおよび原物間でまったく相違なしに、磁気ストライプのデジタル内容を完全にコピーすることができる。主に、これは磁気ストライプ取引が正当であることに依存するものであるのは、ＰＯＳ端末装置が前記磁気ストライプ上にあるデータを単に読込むことしか要されていないためである。
【０００６】
スキミングを防止可能にする主な手段の１つは、消費者が取引カードの所在をしっかりと把握することである。これによって、消費者は、カードが不当なデバイスを通されるのを防止することができる。しかし、磁気ストライプの非接触カードが発達し、現在の支払環境に迅速な取引の期待をもたらすにつれて、従来のスキミング問題もそれに付随してきている。実際、無線環境において、磁気ストライプデータをスキミングする機会は、より広がっている。無線環境において、仮想スキミング犯は、有線ベースの環境のスキミングで必要となる、スキミングするカードを物理的に所有する必要も、物理装置（例えばＰＯＳ端末装置、通信回線、その他）のいずれにもアクセスする必要がない。スキミング犯は、消費者または小売商に気づかれずに、無線取引を傍受し、カードからＰＯＳ端末装置へ転送されるデータをコピーすることができる。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
それでもなお、処理能力を有するＩＣカードまたは類似したデバイスに磁気ストライプデータおよび磁気ストライプ支払アプリケーションを使用することは増加している。したがって、ここで必要となるのは、動的に取引を承認するために使用可能な検証値を生成することである。この検証値は、各々の取引で異なるため、このような支払サービスの承認方法は、スキミングの機会を大幅に減少させる。したがって、ある取引において使用されたデータがスキミングされたとしても、スキミングされた検証値は次の取引では無効なので、続いて取引をする際にデータは役に立たなくなる。
【課題を解決するための手段】
【０００８】
本発明は、ＩＣクレジットカード等の支払デバイス上に行われる支払サービスの信頼性を確認するための検証値をその支払サービスが取引に使用される度に動的に生成するためのシステムと方法を記載するものである。各々の取引において、検証値は、前記支払サービスに特有のデータから支払デバイス上で動的に生成される。前記支払デバイスからクレジットカード端末などのＰＯＳ端末装置へ送信される支払データに、前記検証値は埋め込まれる。ＰＯＳ端末装置は、前記支払データを前記埋め込まれた検証データと一緒に、支払ネットワーク（前記支払データをサービスプロバイダのコンピュータに送信する）に送信するが、前記検証データは、磁気ストライプのクレジットカードトラック１及び／またはトラック２データの形でもよい。前記サービスプロバイザのコンピュータは、独立して検証値を生成する。前記サービスプロバイダ生成の検証値が前記支払デバイス生成の検証値と一致しない場合、取引は認可されない。
【０００９】
代替の実施例において、前記支払デバイス上で各取引ごとに生成される支払データは、前記支払データが生成された前記支払デバイスからクレジットカード端末のようなＰＯＳ端末装置に送信される。検証値は、前記支払データと前記ＰＯＳ端末装置内に含まれる情報を使用して、前記ＰＯＳ端末装置によって生成される。前記ＰＯＳ端末装置は、前記支払データを前記埋め込まれた検証データと一緒に、支払ネットワーク（前記支払データをサービスプロバイダのコンピュータに送信する）に送信するが、前記検証データは、磁気ストライプのクレジットカードトラック１及び／またはトラック２のデータの形でもよい。前記サービスプロバイダのコンピュータは、個別に検証値を生成する。前記サービスプロバイダ生成の検証値が前記支払デバイス生成の検証値と一致しない場合、取引は認可されない。
【００１０】
本発明は、磁気ストライプトラック１および／またはトラック２のデータが任意のインターフェース（接触ベースのインタフェース及び無線インタフェースを含む）を通じて交換される任意の取引に使用可能である。
【発明を実施するための最良の形態】
【００１１】
本発明の実施形態の側面、特徴、利点、および長所は、以下の説明、添付の請求の範囲および添付の図面によって明確にされる。
【００１２】
本発明の説明の前に、本発明は本明細書で記載される特定の方法、デバイスまたはプロトコールは変化するので、これらに限定されないことは理解されるべきである。説明において使用される用語は、特定のバージョンまたは実施形態を記載するためのものであって、本発明の範囲は添付の請求の範囲を限定するためのものではない。本発明の範囲は添付の請求の範囲によってのみ限定される。特に、本発明は金融取引と関連して記載されるが、本発明はいかなる電子データ交換においても使用可能であることは言うまでもない。
【００１３】
また、本明細書中、及び、添付の請求の範囲で用いられる単数形のもの、「ある」、「１」、「前記」等が付くものは複数のものが含まれると理解されるべきである（そうでないことが文脈から明示されない限り）。このように、たとえば、「鍵」に対する参照は、１若しくはそれ以上の鍵及びそれの相等物に対する参照であることは当業者等には理解される。そうでないと定義されていない限り、本明細書で使用される技術及び科学用語は当業者によって一般に理解される意味と同じである。本明細書で記載されるものに類似または相当する任意の方法及びデバイスが、本発明の実施形態の実際の使用及びテストで使用可能であるが、下記には好ましい方法とデバイスについて説明する。本明細書において言及される全ての公報は引用により本明細書に組み込まれる。ここで、従来の発明によるそのような開示に対して本発明が先行しないものであると自認すると解釈されるべきではない。
【００１４】
通常、本発明は各取引ごとにカード検証値を動的に生成し、そのような値を使って前記支払サービスが確実なものであり、スキミングされていないことを確認するための方法とシステムを提供する。動的に生成されたカード検証値（本明細書において「ｄＣＶＶ」と称される）は、支払デバイスで生成されて、支払データに埋め込まれて、ＰＯＳ端末装置に送られる。代替の実施形態において、支払データは支払デバイスから受け取られ、検証値はＰＯＳ端末装置によって生成され、前記検証値は前記支払データに埋め込まれる。
【００１５】
１実施形態において、前記ＰＯＳ端末装置が受け取るデータは、前記ＰＯＳ端末装置によって単に支払データ（例えば、埋め込まれたｄＣＶＶのない標準の磁気ストライプトラック１および／またはトラック２データ）と解釈される。前記受信データは、前記ＰＯＳ端末装置から支払ネットワークに送信され、次に前記サービスプロバイダに送られる。前記サービスプロバイダが、前記取引はｄＣＶＶが必要であると決定すると、サービスプロバイダは個別に検証値を生成する。前記サービスプロバイダによって生成された検証値が前記支払デバイスから受け取られるｄＣＶＶと一致しない場合、前記取引は、潜在的に不正として認識され許可されない。
【００１６】
代替の実施形態において、データは前記ＰＯＳ端末装置によって受信されて、検証値を生成するために前記ＰＯＳ端末装置によって使われる。前記受信データは、前記ＰＯＳ端末装置から支払ネットワークに送信され、次に前記サービスプロバイダに渡される。前記サービスプロバイダは、個別に検証値を生成する。前記サービスプロバイダによって生成される検証値が前記支払デバイスから受け取られるｄＣＶＶと一致しない場合、前記取引は、潜在的に不正として認識され許可されない。
【００１７】
本出願において、用語「支払デバイス」は、本明細書において記載される取引またはデータ交換において使用可能な、マイクロプロセッサを有する任意のデバイスを意味する。前述の一般性を限定することなしに、「支払デバイス」は、ＩＣカード（スマートカードとも一般に公知の）、メモリーカード、携帯電話、パーソナル携帯情報機器（ＰＤＡ）、携帯電子デバイスまたはコンピュータを含むものとする。
【００１８】
本出願において、「非接触」または「無線」は、２つのデバイス間のデータ交換において、前記デバイスが物理的に接続する必要なしにデータ交換が可能な、いかなる通信方法またはプロトコール（独自開発のプロトコールを含む）を意味する。前述の一般性を制限することなしに、「非接触」または「無線」は、レーザー、無線周波、赤外線通信、Ｂｌｕｅｔｏｏｔｈまたは無線ＬＡＮによるデータ転送を含むものとする。
【００１９】
本出願において、用語「支払サービス」は、支払デバイスおよび他の任意のデバイス間またはロケーション間でのデータ交換を生じさせる支払デバイスで使用される任意のアプリケーションを意味する。当然のことながら、「支払サービス」は金融アプリケーションに限定されるものではない。
【００２０】
本出願において、金融アプリケーションに関連する「支払データ」は、取引を実行するために前記支払サービスによって使用されるデータ要素を意味し、金融取引以外の場合は、本発明に独特の任意の必要データ要素を意味する。たとえば、前記支払サービスが磁気ストライプのクレジットカード取引である場合、「支払データ」はトラック１及び／またはトラック２データを有し、主アカウント番号、失効日、サービスコードおよび任意データ等であることは当業者には明らかである。「支払データ」は、また一意のカードＩＤ番号またはサービスプロバイダ用の一意の識別番号を含んでもよい。
【００２１】
１実施形態において、前記支払データは、支払デバイスにあるメモリに存在する。前記支払デバイスは、また、アプリケーション取引カウンタ（ＡＴＣ）を維持する。前記ＡＴＣは最初、サービスプロバイダによって予め定められた値にセットされる。その後で、前記ＡＴＣは各取引毎にインクリメントされる。あるいは、前記ＡＴＣは各取引毎に、初期の所定値からデクリメントされてもよい。前記ＡＴＣは、任意の長さの値が可能である。さらに、前記支払サービスを使用するサービスプロバイダは、前記サービスプロバイダのコンピュータにアクセス可能な対応するＡＴＣを維持する。下記にさらに詳細に説明するように、この対応するＡＴＣは、スキミングされた可能性がある支払サービスを認識するために使用される。代替の実施形態において、暗号、デジタル署名、または取引データに基づくハッシュ値が、ＡＴＣの代わりにまたは一緒に使用される。
【００２２】
前記支払サービスが起動される度に、認証目的のためにｄＣＶＶが支払デバイスで生成される。図１は、本発明による、各々の取引用にｄＣＶＶの生成方法が示される。まず最初に、予め定められた長さの数字列が作られる。この数字列は、前記支払サービスの前記アカウント番号またはＰＡＮ１０４の対応する左端の桁上にＡＴＣ１０２をオーバーレイして（１０１）作成する。この数字列は、右側で支払サービス用の失効日と支払コードが連結されて、前記連結値１０６が生成される。必要であれば、埋め込み文字１０８が連結値１０６の右側に連結されて（１１０）、予め定められた固定長の数字列１１２を形成する。好適な実施形態において、この数字列１１２は、１２８ビットの長さである（但し、任意の長さの数字列が使用可能である）。前記埋め込み文字１０８は、前記支払サービスとサービスプロバイダーの両方で認識されている、一連の０、１、または任意の他の数値からなる。前記数字列１１２は、同等の長さの２つのブロック、ブロックＡ１１６およびブロックＢ１１８に二分される。ブロックＡ１１６は、次に最初の暗号鍵１２０によって暗号化される（１２１）。前記暗号化ステップ１２１の結果は、ブロックＡ１１６に等しい長さのブロックＣ１２２である。ブロックＣ１２２は、次にブロックＢ１１８によって排他的論理和演算（ＸＯＲ）されて（１２３）、ブロックＤ１２４が生成される。ブロックＤ１２４は次に第２の暗号鍵１２６によって暗号化され（１２５）、ブロックＥ１２８が生成される。ブロックＥ１２８は次に復号鍵１３０を使用して復号され（１２９）、ブロックＦ１３２が生成される。ブロックＦ１３２は次に第４の暗号鍵１３４を使用して暗号化され（１３３）、ブロックＧ１３６が生成される。
【００２３】
前記第１の暗号鍵１２０、前記第２の暗号鍵１２６、前記第３の暗号鍵１３０および前記第４の暗号鍵１３４が任意の予め選択された値を取る事が可能であることは、当業者には明らかである。本発明の実施形態において、前記第１の暗号鍵１２０、前記第２の暗号鍵１２６および前記第４の暗号鍵１３４は、同等であって、前記第３の暗号化とは異なる値である。図１の方法において利用される暗号鍵値の他の代替は、本発明の範囲内である。
【００２４】
好適な実施形態において、前記第１の暗号鍵１２０、前記第２の暗号鍵１２６、前記第３の暗号鍵１３０および前記第４の暗号鍵１３４は、前記支払デバイスにあるデータから派生する一意の鍵の値を取る。使用される際、各支払サービスは、マスタ派生鍵を使ってサービスプロバイダによって個別化される。前記マスタ派生鍵は支払サービスと一緒に、バッチで（すなわち、複数のサービスが同じマスタ派生鍵を受け取る）、または個別に使用される。各々の支払デバイスは、支払サービスに対して一意の鍵を派生する機能によって個別化される。図２は、好適な実施形態において使用される２つの一意の鍵を引き出すための方法である。アカウント番号２０１、アカウント・シーケンス番号２０２、アカウント番号の逆数２０３およびアカウント・シーケンス番号の逆数２０４は、一緒に連結されて連結値２１０が生成される。必要であるならば、予め定められた固定長の文字列を作るために、連結値２１０は、０または他の値を埋め込んでもよい（２１１）。好適な実施形態において、前記連結値２１０は１２８ビットの長さであるが、前記連結値はこの長さに限定されるものではない。前記連結値２１０は、次に各々の暗号化段階の暗号鍵として前記マスタ派生鍵２２１を使用して暗号化される（２２０）。使用される暗号化は、暗号化方法の任意のタイプを含むことができる。たとえば、この暗号化ステップは、トリプルＤＥＳ暗号化を利用することができる。前記暗号化ステップ２２０から生じる値は、アカウント番号によって識別される、アプリケーション用の一意の派生鍵またはＵＤＫ２３０である。２つの追加鍵、ＵＤＫＡ２４０およびＵＤＫＢ２４１は、前記ＵＤＫから派生する。前記ＵＤＫ２３０からのＵＤＫＡ２４０およびＵＤＫＢ２４１の派生は、任意の形式でよく、前記ＵＤＫ２３０の左端半分の値をＵＤＫＡ２４０に割り当てること、また前記ＵＤＫ２３０の右端半分の値をＵＤＫＢ２４１に割り当てることを含む。あるいは、前記ＵＤＫＡ２４０は、前記ＵＤＫ２３０から代替、または別に予め定められたビットシーケンスを選ぶことによって派生させ、残りのビットは前記ＵＤＫＢ２４１に割り当ててもよい。さらに、ＵＤＫＡ２４０およびＵＤＫＢ２４１は同等の長さの中である必要性はない。
【００２５】
図１で提示される方法の結果に戻る。図３は、ｄＣＶＶを生成するために必要となる更なる処理を記載する。ブロックＧ１３６に格納された値の各々のニブル（４ビットグループ）は、２つの別々の繰り返し過程にかけられて、各々のニブルの値が評価される。図３に示すように、ブロックＧ１３６の最も重要な桁（例えば左端）から開始し、各順次ニブルを調べて、もしニブルが０から９（を含む）の範囲の値を含む場合、その値は抽出され（３０１）、以前に抽出された値がある場合はその右に連結することにより新たな数字列（本明細書中で保持列として言及される）中に入れられる（３０５）。その結果、保持文字列が０から９（その数を含む）までの範囲の一連の値を含むことになり、ブロックＧ１３６において現れるのと同じ順序で保持列の左から右に現れる。
【００２６】
次に第２の評価が再度実行されるが、ブロックＧ１３６の最も重要な桁から開始され、各順次ニブルが調べられる。前記ニブルが１０（Ａ）から１５（Ｆ）（その数を含む）の範囲の１６進数の値を含む場合、その値は抽出される（３１０）。前記抽出された値は、次に前記１６進値Ａを前記抽出値から引くことにより十進制にされ、０から５までの範囲の十進数の値になる（３１５）。この十進法にされた値は、次に前記保持列の右端の値の右側に連結される（３２０）。
【００２７】
ブロックＧの全ニブルが上記のように２度調べられると、前記保持列の３つの最も重要なニブル（例、左端）が抽出される（３２５）。この３桁の値が、前記取引用のｄＣＶＶである。他のビット数を前記二回調べられたニブル列から抽出して、取引用のｄＣＶＶを生成してもよい。さらに、異なるニブル、例えば最も右のニブルを、取引用のｄＣＶＶとして使用してもよい。ただし、前記左端の３つのニブルは、好適な実施形態を示す。
【００２８】
一度生成されると、前記ｄＣＶＶは前記支払デバイスからＰＯＳ端末装置に転送される支払データに埋め込まれる。前記ＰＯＳ端末装置によって受信されるデータは、標準の支払データとして前記ＰＯＳ端末装置に現れる。つまり、前記ＰＯＳ端末装置はｄＣＶＶが埋め込まれているかどうか、そのようなｄＣＶＶがどこに位置するかを判定することはできない。前記ＰＯＳ端末装置に対して、前記支払デバイスから受け取られたデータにｄＣＶＶが埋め込まれていることを示すものはない。
【００２９】
図４は、前記支払デバイスから前記ＰＯＳ端末装置へ送信される、ｄＣＶＶが埋め込まれた支払データの典型的なレコード形式を表す。図４のレコード形式は、前記支払サービスのために、失効日４０２およびサービスコード４０３を、主アカウント番号４０１に連結することによって作られる。好適な実施形態において、前記主アカウント番号４０１は１６桁の長さで、前記失効日４０２は４桁の長さ、及び前記サービスコード４０３は、３桁の長さである。しかし、前記主アカウント番号４０１、前記失効日４０２および前記サービスコード４０３は、これらの長さに限定されない。次に他の使用のために通常確保されるフィールドにおいて、ｄＣＶＶがこのレコードに埋め込まれたことを示す数値がインジケータ４０５として配置される。このインジケータの値は、前記支払デバイス上で前記アプリケーションを使用したサービスプロバイダによって把握される。次に、ＰＩＮ検証データのために一般に確保されるフィールドに前記ＡＴＣ４１０が配置される。最後に、前記ｄＣＶＶ４１５はレコードの右に連結される。レコードの残りは、追加の選択的データを含んでもよい。
【００３０】
代替として、図５において、前記支払デバイスから前記ＰＯＳ端末装置に転送される、ｄＣＶＶが埋め込まれた支払情報の第２の典型的な形式が示される。図５の形式は、前記支払サービス用の主アカウント番号５０１に、失効日５０２、サービスコード５０３、ＰＶＫＩ５０４およびＰＩＮ検証データ５０５のためのフィールドを、連結することによって作られる。好適な実施形態において、前記主アカウント番号５０１は１６桁の長さ、前記失効日５０２は４桁の長さ、前記サービスコード５０３は３桁の長さ、そして、前記ＰＶＫＩ５０４は１桁の長さ、前記ＰＩＮ検証データ５０５は４桁の長さである。しかし、前記主アカウント番号５０１、前記失効日５０２、前記サービスコード５０３、前記ＰＶＫＩ５０４および前記ＰＩＮ検証データ５０５は、これらの長さに限定されるものではない。次に、単一のデータフィールド５１０においてそれぞれ動的に生成された前記ＣＶＶ、前記ＡＴＣ、および動的ＣＶＶが埋め込まれたことを識別するためにサービスプロバイダによって使用されるインジケータが順番に格納される。前記レコードの残りは、追加の選択的データを有してもよい。
【００３１】
本発明の重要な観点は、動的に作られたＣＶＶを利用するシステムによって、使用される支払サービスの信頼性を前記サービスプロバイダが判定できるようになることである。この承認ステップは、販売業者、個々のＰＯＳ端末装置、あるいは他の第三者またはデバイスに任されない。図６は、支払アプリケーションがスキミングされているかどうかの判定を行うために、前記支払デバイスで利用される支払アプリケーションの信頼性をサービスプロバイダが評価できるように、どのようにｄＣＶＶが非接触の環境において使用されるかを示す。図６では非接触の環境の実施形態で示されるが、本発明がこの種の環境に限定されるものではなく、磁気ストライプトラック１および／またはトラック２のデータがそのようなデータを送信するための任意の方法または手段を使用して交換される場合のどの取引でも使用可能である。図６に示されるように、前記支払デバイスは、好ましくは上述の方法を使用して前記ｄＣＶＶ６０１を生成する。前記ｄＣＶＶは、前記支払データ６０５に埋め込まれる。これに関しては、図４または図５に示される典型的なレコード形式が利用されてもよい。埋め込まれたｄＣＶＶを有する支払データは、前記ＰＯＳ端末装置６１０にデータ通信によって伝送される。前記ＰＯＳ端末装置は、前記の受信データを支払データの標準形式で認識し、前記サービスプロバイダのコンピュータ６１５に通常支払ネットワーク（図示せず）を通じて前記データストリームを転送する。前記サービスプロバイダのコンピュータは、埋め込まれたｄＣＶＶを有する支払データを受信し（６２０）、適切なインジケータを調べて、前記取引が非接触の取引であるかどうかの判定をする（６２５）。前記サービスプロバイダのコンピュータが、前記取引は非接触の取引でなかったと決定した場合、前記取引はその通常の方法において処理される（６３０）。前記サービスプロバイダのコンピュータが、前記取引は非接触だったと決定した場合、前記サービスプロバイダのコンピュータは支払デバイスから受信したＡＴＣを前記サービスプロバイダのコンピュータに格納された対応するＡＴＣと比べ、前記受信されたＡＴＣが予期されていた次のＡＴＣであるかどうかを判定する（６３５）。前記支払デバイスから受信されたＡＴＣが予期される次のＡＴＣでない場合、前記支払デバイスで使用された支払サービスはスキミングされている可能性を有する（６４０）。予期される次のＡＴＣが受信された場合、前記サービスプロバイダのコンピュータは、上述と同じプロセスを使用して当該取引用にｄＣＶＶを個別に再生成する（６４５）。前記のサービスプロバイダ生成のｄＣＶＶが前記支払デバイスから受け取ったｄＣＶＶに一致する（６５０）場合、前記サービスプロバイダは前記の支払アプリケーションは信頼できるとみなす（６５５）。前記サービスプロバイダのコンピュータは、次の認証のために、前記支払デバイス６６０から受け取ったＡＴＣをこれまで前記サービスプロバイダのコンピュータ中に格納されていたＡＴＣと入れ替える。前記サービスプロバイダ生成のｄＣＶＶが前記支払デバイスから受信されたｄＣＶＶと一致しない場合、前記取引は不正の可能性を持つので、終了される（６６５）。
【００３２】
図６の方法は、非接触の取引と関連して説明されたが、それに限定されるものではない。たとえば、前記方法は、特定の閾値より上の取引に関連して使用されてもよい。そのような場合、前記サービスプロバイダは、前記アプリケーションを使用する際、上記閾値より上の取引用にｄＣＶＶを生成するように前記アプリケーションを構成する。次に、ステップ６２５において問い合わせられるインジケータは、上記閾値より上の取引のために設定される。同様に、前記方法は他の任意の取引条件に関連して使用可能で、これには地理的位置、使用パターンまたは他の任意の条件が含まれるが、これらに限定されるものではない。
【００３３】
代替の実施形態において、前記支払デバイスは、支払データをクレジットカード端末装置のようなＰＯＳ端末装置に送信する（７０１）。前記ＰＯＳ端末装置は、前記データを受信して、前記取引用に検証値を計算する（７０５）。前記検証値は、様々な方法で計算可能であるが、これには、前記ＰＯＳ端末装置によって提供される一意の取引番号、タイムスタンプ、またはタイムスタンプに追加される取引金額が含まれるが、これらに限定されるものではない。前記ＰＯＳ端末装置は、次に前記支払データに検証値および追加データを埋め込みおよび／または追加する（７１０）。前記追加データは、前記取引を検証するためにサービスプロバイダのコンピュータで必要とされる。前記ＰＯＳ端末装置は、次に前記サービスプロバイダのコンピュータに（おそらく支払ネットワーク（図示せず）を通じて）データストームを渡す（７１５）。前記サービスプロバイダのコンピュータは、前記検証値を有する支払データを受信する（７２０）。前記サービスプロバイダのコンピュータは、任意で、前記ＰＯＳ端末装置によって埋め込みまたは付随された追加データの少なくとも一部を、前記サービスプロバイダのコンピュータに保存されている対応するデータと比較し、前記の受信データが正しいかどうかを判定する（７２５）。前記ＰＯＳ端末装置からの受信データが不適当な場合、前記取引データはスキミングされた可能性がある（７３０）。正しいデータが受信される場合、前記サービスプロバイダのコンピュータは個別に前記ＰＯＳ端末装置が使用するのと、同じプロセスを利用して、該当取引のための検証値を再生成する（７３５）。前記サービスプロバイダ生成の検証値が前記ＰＯＳ端末装置から受け取った検証値と一致する場合（７４０）、前記サービスプロバイダは前記支払アプリケーションは信頼性があるとみなす（７４５）。前記サービスプロバイダのコンピュータは次に、任意で、前記サービスプロバイダのコンピュータ内に今まで保存されていた追加データを次に続く認証のために前記支払デバイスから受け取った追加データによって更新する（７５０）。前記サービスプロバイダ生成の検証値が前記ＰＯＳ端末装置から受け取った検証値と一致しない場合、前記取引は不正である可能性があるので、終了される（７５５）。
【００３４】
前記説明は、発明の原理を図示するためだけのものであるとみなされる。更に、多くの修正と変更が当業者において容易に行われるので、本発明を図及び説明にある通りの構成に限定されるべきではない。したがって、すべての適切な修正および同等物が必要とされる場合、これらは本発明の範囲内にあるとみなされる。
【図面の簡単な説明】
【００３５】
【図１】図１は、本発明で使用される暗号化データブロックを生成する方法を示す。
【図２】図２は、支払デバイスに存在するデータから、一意の派生鍵を生成する方法を示す。
【図３】図３は、本発明によるカード検証値を動的に生成するために暗号化データブロックの一部を抽出するための方法を表す。
【図４】図４は、本発明の実施形態で使用される典型的なレコード形式を表す。
【図５】図５は、本発明の実施形態で使用される他の典型的な形式を表す。
【図６】図６は、取引を認証するために動的に生成された検証値を使用した好適な方法のフローチャートである。
【図７】図７は、取引を認証するために動的に生成された検証値を使用した代替方法のフローチャートである。
【特許請求の範囲】
【請求項１】
取引で使用された支払サービスを承認するための方法であって、
前記取引に対して一意の第１の検証値を支払デバイス上で生成する工程であって、前記第１の検証値は第１のデータ値と第２のデータ値とを含むデータから派生されるものである、第１の検証値を生成する工程と、
前記第１の検証値と支払データを有する支払レコードを前記支払デバイスからＰＯＳ端末装置へ送信する工程と、
前記支払レコードを前記ＰＯＳ端末装置からサービスプロバイダのコンピュータに送信する工程と、
前記サービスプロバイダのコンピュータ上で第２の検証値を生成する工程であって、前記第２の検証値は前記サービスプロバイダのコンピュータ中に存在するデータからのみ生成されるものである、第２の検証値を生成する工程と、
前記第１の検証値が前記第２の検証値に一致しない場合は前記取引を不許可とする工程と、
を有することを特徴とする方法。
【請求項２】
請求項１記載の方法において、前記第１のデータ値は、前記支払サービス用の主アカウント番号を有することを特徴とする方法。
【請求項３】
請求項１記載の方法において、前記第１のデータ値は、前記支払デバイス用の一意の認識番号を有することを特徴とする方法。
【請求項４】
請求項１記載の方法において、前記第１のデータ値は、前記支払プロバイダ用の一意の認識番号を有することを特徴とする方法。
【請求項５】
請求項１記載の方法において、前記第２のデータ値は、アプリケーション取引カウンタを有することを特徴とする方法。
【請求項６】
請求項１記載の方法において、前記第２のデータ値は、暗号文を有することを特徴とする方法。
【請求項７】
請求項１記載の方法において、前記第２のデータ値は、デジタル署名を有することを特徴とする方法。
【請求項８】
請求項１記載の方法において、前記第２のデータ値は、前記支払データから派生した値を有することを特徴とする方法。
【請求項９】
請求項１記載の方法において、前記第１の検証値は、前記支払サービスを認識するためのサービスコードと前記支払サービスの失効日とを更に含むデータから派生されることを特徴とする方法。
【請求項１０】
請求項１記載の方法において、前記アプリケーション取引カウンタは、各実行取引毎に任意の非０値によってインクリメントされる。
【請求項１１】
請求項１記載の方法において、前記支払レコードは更にアプリケーション取引カウンタを有することを特徴とする方法。
【請求項１２】
請求項１１記載の方法において、前記アプリケーション取引カウンタを前記サービスプロバイダのコンピュータがアクセス可能なメモリに保存する工程を更に有することを特徴とする方法。
【請求項１３】
請求項１記載の方法において、前記支払デバイスは前記支払レコードを無線通信を通じて、前記ＰＯＳ端末装置に送信することを特徴とする方法。
【請求項１４】
取引用に検証値を動的に生成する方法であって、
前記取引で使用される支払サービス用に第１のデータ値と第２のデータ値を有するベースレコードを生成する工程と、
前記ベースレコードを第１のフィールドと第２のフィールドに分割する工程と、
第１の暗号鍵を使用して前記第１のフィールドを暗号化する工程と、
前記暗号化された第１のフィールドと前記第２のフィールドに排他的論理和演算（ＸＯＲ）を実行して、第１の結果を生成する工程と、
第２の暗号鍵を使って前記第１の結果を暗号化して、第２の結果を生成する工程と、
復号鍵を使って前記第２の結果を復号化し、第３の結果を生成する工程と、
第３の暗号鍵を使って前記第３の結果を暗号化して、第４の結果を生成する工程と
前記第４の結果の最も重要な桁から最も重要でない桁まで、０から９の各値を順次抽出して、第５の結果を生成する工程と、
前記第４の結果の最も重要な桁から最も重要でない桁まで、１６進法のＡからＦまでの各値を順次抽出し、１６進法のＡを差し引いて、第６の結果を生成する工程と、
前記第５の結果と前記第６の結果を連結し、第７の結果を生成する工程と、
前記第７の結果から１若しくはそれ以上の値を前記カード検証値として選択する工程と、を有することを特徴とする方法。
【請求項１５】
請求項１４記載の方法において、前記第１の暗号鍵、前記第２の暗号鍵、前記第３の暗号鍵は同じであることを特徴とする方法。
【請求項１６】
請求項１４記載の方法において、前記復号鍵は前記第１の暗号鍵と異なることを特徴とする方法。
【請求項１７】
請求項１４記載の方法において、前記復号鍵は前記第１の暗号鍵、前記第２の暗号鍵、及び前記第３の暗号鍵と異なることを特徴とする方法。
【請求項１８】
請求項１４記載の方法において、前記ベースレコードは１２８ビットの長さであることを特徴とする方法。
【請求項１９】
請求項１４記載の方法において、前記第１のデータ値は、前記支払サービス用の主アカウント番号を有することを特徴とする方法。
【請求項２０】
請求項１４記載の方法において、前記第１のデータ値は、前記支払デバイス用の一意の認識番号を有することを特徴とする方法。
【請求項２１】
請求項１４記載の方法において、前記第１のデータ値は、前記支払プロバイダ用の一意の認識番号を有することを特徴とする方法。
【請求項２２】
請求項１４記載の方法において、前記第２のデータ値は、アプリケーション取引カウンタを有することを特徴とする方法。
【請求項２３】
請求項１４記載の方法において、前記第２のデータ値は、暗号を有することを特徴とする方法。
【請求項２４】
請求項１４記載の方法において、前記第２のデータ値は、デジタル署名を有することを特徴とする方法。
【請求項２５】
請求項１４記載の方法において、前記第２のデータ値は、前記支払データから派生した値を有することを特徴とする方法。
【請求項２６】
請求項１４記載の方法において、前記第１の検証値は、前記支払サービスを認識するサービスコードと、前記支払サービスの失効日とを更に含むデータから派生されることを特徴とする方法。
【請求項２７】
請求項１４記載の方法において、前記ベースレコードは更に埋め込み文字を有し、前記ベースレコードを予め設定された長さに拡張することを特徴とする方法。
【請求項２８】
請求項１４記載の方法において、前記第１の暗号鍵と前記第２の暗号鍵と、前記の復号鍵と、前記第３の暗号鍵は、前記支払デバイス上に存在するデータから派生されることを特徴とする方法。
【請求項２９】
取引を検証するためのシステムであって、
その中で使用される支払サービスを有する第１の電子デバイスと、
前記第１の電子デバイスと通信する第２の電子デバイスであって、この第２の電子デバイスは前記第１の電子デバイスから支払レコードを受け取り、前記支払レコードは前記支払サービス用のアカウント番号と前記第１の電子デバイス上で生成された第１の検証値とを有する、第２の電子デバイスと、
前記第２の電子デバイスと通信するサービスプロバイダシステムであって、このサービスプロバイダシステムは独立して第２の検証値を生成し、前記第１の検証値と前記第２の検証値が同一でない場合は前記取引を不許可にする、サービスプロバイダシステムと
を有することを特徴とするシステム。
【請求項３０】
請求項２９記載のシステムにおいて、前記第１の電子デバイスは、ＩＣカードであることを特徴とするシステム。
【請求項３１】
請求項２９記載のシステムにおいて、前記第１の電子デバイスは、パーソナル・デジタル・アシスタントであることを特徴とするシステム。
【請求項３２】
請求項２９記載のシステムにおいて、前記第１の電子デバイスは、携帯電話であることを特徴とするシステム。
【請求項３３】
請求項２９記載のシステムにおいて、前記第１の電子デバイスは、
マイクロプロセッサと、
前記第２の電子デバイスとの通信手段と
を有することを特徴とするシステム。
【請求項３４】
請求項２９記載のシステムにおいて、前記第１の電子デバイスは高周波を通じて前記第２の電子デバイスと通信することを特徴とするシステム。
【請求項３５】
請求項２９記載のシステムにおいて、前記電子デバイスは赤外周波を通じて前記第２の電子デバイスと通信することを特徴とするシステム。
【請求項３６】
請求項２９記載のシステムにおいて、前記電子デバイスはレーザー通信を通じて前記第２の電子デバイスと通信することを特徴とするシステム。
【請求項３７】
請求項２９記載のシステムにおいて、前記第２の電子デバイスは
前記第１の電子デバイスとの通信手段と、
端末と、
を有することを特徴とするシステム。
【請求項３８】
請求項３７記載のシステムにおいて、前記第２の電子デバイスは更にハードウエア・セキュリティ鍵を有することを特徴とするシステム。
【請求項１】
取引で使用された支払サービスを承認するための方法であって、
前記取引に対して一意の第１の検証値を支払デバイス上で生成する工程であって、前記第１の検証値は第１のデータ値と第２のデータ値とを含むデータから派生されるものである、第１の検証値を生成する工程と、
前記第１の検証値と支払データを有する支払レコードを前記支払デバイスからＰＯＳ端末装置へ送信する工程と、
前記支払レコードを前記ＰＯＳ端末装置からサービスプロバイダのコンピュータに送信する工程と、
前記サービスプロバイダのコンピュータ上で第２の検証値を生成する工程であって、前記第２の検証値は前記サービスプロバイダのコンピュータ中に存在するデータからのみ生成されるものである、第２の検証値を生成する工程と、
前記第１の検証値が前記第２の検証値に一致しない場合は前記取引を不許可とする工程と、
を有することを特徴とする方法。
【請求項２】
請求項１記載の方法において、前記第１のデータ値は、前記支払サービス用の主アカウント番号を有することを特徴とする方法。
【請求項３】
請求項１記載の方法において、前記第１のデータ値は、前記支払デバイス用の一意の認識番号を有することを特徴とする方法。
【請求項４】
請求項１記載の方法において、前記第１のデータ値は、前記支払プロバイダ用の一意の認識番号を有することを特徴とする方法。
【請求項５】
請求項１記載の方法において、前記第２のデータ値は、アプリケーション取引カウンタを有することを特徴とする方法。
【請求項６】
請求項１記載の方法において、前記第２のデータ値は、暗号文を有することを特徴とする方法。
【請求項７】
請求項１記載の方法において、前記第２のデータ値は、デジタル署名を有することを特徴とする方法。
【請求項８】
請求項１記載の方法において、前記第２のデータ値は、前記支払データから派生した値を有することを特徴とする方法。
【請求項９】
請求項１記載の方法において、前記第１の検証値は、前記支払サービスを認識するためのサービスコードと前記支払サービスの失効日とを更に含むデータから派生されることを特徴とする方法。
【請求項１０】
請求項１記載の方法において、前記アプリケーション取引カウンタは、各実行取引毎に任意の非０値によってインクリメントされる。
【請求項１１】
請求項１記載の方法において、前記支払レコードは更にアプリケーション取引カウンタを有することを特徴とする方法。
【請求項１２】
請求項１１記載の方法において、前記アプリケーション取引カウンタを前記サービスプロバイダのコンピュータがアクセス可能なメモリに保存する工程を更に有することを特徴とする方法。
【請求項１３】
請求項１記載の方法において、前記支払デバイスは前記支払レコードを無線通信を通じて、前記ＰＯＳ端末装置に送信することを特徴とする方法。
【請求項１４】
取引用に検証値を動的に生成する方法であって、
前記取引で使用される支払サービス用に第１のデータ値と第２のデータ値を有するベースレコードを生成する工程と、
前記ベースレコードを第１のフィールドと第２のフィールドに分割する工程と、
第１の暗号鍵を使用して前記第１のフィールドを暗号化する工程と、
前記暗号化された第１のフィールドと前記第２のフィールドに排他的論理和演算（ＸＯＲ）を実行して、第１の結果を生成する工程と、
第２の暗号鍵を使って前記第１の結果を暗号化して、第２の結果を生成する工程と、
復号鍵を使って前記第２の結果を復号化し、第３の結果を生成する工程と、
第３の暗号鍵を使って前記第３の結果を暗号化して、第４の結果を生成する工程と
前記第４の結果の最も重要な桁から最も重要でない桁まで、０から９の各値を順次抽出して、第５の結果を生成する工程と、
前記第４の結果の最も重要な桁から最も重要でない桁まで、１６進法のＡからＦまでの各値を順次抽出し、１６進法のＡを差し引いて、第６の結果を生成する工程と、
前記第５の結果と前記第６の結果を連結し、第７の結果を生成する工程と、
前記第７の結果から１若しくはそれ以上の値を前記カード検証値として選択する工程と、を有することを特徴とする方法。
【請求項１５】
請求項１４記載の方法において、前記第１の暗号鍵、前記第２の暗号鍵、前記第３の暗号鍵は同じであることを特徴とする方法。
【請求項１６】
請求項１４記載の方法において、前記復号鍵は前記第１の暗号鍵と異なることを特徴とする方法。
【請求項１７】
請求項１４記載の方法において、前記復号鍵は前記第１の暗号鍵、前記第２の暗号鍵、及び前記第３の暗号鍵と異なることを特徴とする方法。
【請求項１８】
請求項１４記載の方法において、前記ベースレコードは１２８ビットの長さであることを特徴とする方法。
【請求項１９】
請求項１４記載の方法において、前記第１のデータ値は、前記支払サービス用の主アカウント番号を有することを特徴とする方法。
【請求項２０】
請求項１４記載の方法において、前記第１のデータ値は、前記支払デバイス用の一意の認識番号を有することを特徴とする方法。
【請求項２１】
請求項１４記載の方法において、前記第１のデータ値は、前記支払プロバイダ用の一意の認識番号を有することを特徴とする方法。
【請求項２２】
請求項１４記載の方法において、前記第２のデータ値は、アプリケーション取引カウンタを有することを特徴とする方法。
【請求項２３】
請求項１４記載の方法において、前記第２のデータ値は、暗号を有することを特徴とする方法。
【請求項２４】
請求項１４記載の方法において、前記第２のデータ値は、デジタル署名を有することを特徴とする方法。
【請求項２５】
請求項１４記載の方法において、前記第２のデータ値は、前記支払データから派生した値を有することを特徴とする方法。
【請求項２６】
請求項１４記載の方法において、前記第１の検証値は、前記支払サービスを認識するサービスコードと、前記支払サービスの失効日とを更に含むデータから派生されることを特徴とする方法。
【請求項２７】
請求項１４記載の方法において、前記ベースレコードは更に埋め込み文字を有し、前記ベースレコードを予め設定された長さに拡張することを特徴とする方法。
【請求項２８】
請求項１４記載の方法において、前記第１の暗号鍵と前記第２の暗号鍵と、前記の復号鍵と、前記第３の暗号鍵は、前記支払デバイス上に存在するデータから派生されることを特徴とする方法。
【請求項２９】
取引を検証するためのシステムであって、
その中で使用される支払サービスを有する第１の電子デバイスと、
前記第１の電子デバイスと通信する第２の電子デバイスであって、この第２の電子デバイスは前記第１の電子デバイスから支払レコードを受け取り、前記支払レコードは前記支払サービス用のアカウント番号と前記第１の電子デバイス上で生成された第１の検証値とを有する、第２の電子デバイスと、
前記第２の電子デバイスと通信するサービスプロバイダシステムであって、このサービスプロバイダシステムは独立して第２の検証値を生成し、前記第１の検証値と前記第２の検証値が同一でない場合は前記取引を不許可にする、サービスプロバイダシステムと
を有することを特徴とするシステム。
【請求項３０】
請求項２９記載のシステムにおいて、前記第１の電子デバイスは、ＩＣカードであることを特徴とするシステム。
【請求項３１】
請求項２９記載のシステムにおいて、前記第１の電子デバイスは、パーソナル・デジタル・アシスタントであることを特徴とするシステム。
【請求項３２】
請求項２９記載のシステムにおいて、前記第１の電子デバイスは、携帯電話であることを特徴とするシステム。
【請求項３３】
請求項２９記載のシステムにおいて、前記第１の電子デバイスは、
マイクロプロセッサと、
前記第２の電子デバイスとの通信手段と
を有することを特徴とするシステム。
【請求項３４】
請求項２９記載のシステムにおいて、前記第１の電子デバイスは高周波を通じて前記第２の電子デバイスと通信することを特徴とするシステム。
【請求項３５】
請求項２９記載のシステムにおいて、前記電子デバイスは赤外周波を通じて前記第２の電子デバイスと通信することを特徴とするシステム。
【請求項３６】
請求項２９記載のシステムにおいて、前記電子デバイスはレーザー通信を通じて前記第２の電子デバイスと通信することを特徴とするシステム。
【請求項３７】
請求項２９記載のシステムにおいて、前記第２の電子デバイスは
前記第１の電子デバイスとの通信手段と、
端末と、
を有することを特徴とするシステム。
【請求項３８】
請求項３７記載のシステムにおいて、前記第２の電子デバイスは更にハードウエア・セキュリティ鍵を有することを特徴とするシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公表番号】特表２００７−５１３５２９（Ｐ２００７−５１３５２９Ａ）
【公表日】平成１９年５月２４日（２００７．５．２４）
【国際特許分類】
【出願番号】特願２００６−５２４０１０（Ｐ２００６−５２４０１０）
【出願日】平成１６年８月１８日（２００４．８．１８）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０２６８１３
【国際公開番号】ＷＯ２００５／０２００１２
【国際公開日】平成１７年３月３日（２００５．３．３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕｅｔｏｏｔｈ
【出願人】（５０５４６８８６４）ビザ インターナショナル サービス アソシエーション (2)
【Ｆターム（参考）】
【公表日】平成１９年５月２４日（２００７．５．２４）
【国際特許分類】
【出願日】平成１６年８月１８日（２００４．８．１８）
【国際出願番号】ＰＣＴ／ＵＳ２００４／０２６８１３
【国際公開番号】ＷＯ２００５／０２００１２
【国際公開日】平成１７年３月３日（２００５．３．３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｂｌｕｅｔｏｏｔｈ
【出願人】（５０５４６８８６４）ビザ インターナショナル サービス アソシエーション (2)
【Ｆターム（参考）】
[ Back to top ]