IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ ビザ インターナショナル サービス アソシエーションの特許一覧

特開2023-71651異種データメッセージの機密データを安全に伝達するための技術
<>
  • 特開-異種データメッセージの機密データを安全に伝達するための技術 図1
  • 特開-異種データメッセージの機密データを安全に伝達するための技術 図2
  • 特開-異種データメッセージの機密データを安全に伝達するための技術 図3
  • 特開-異種データメッセージの機密データを安全に伝達するための技術 図4
  • 特開-異種データメッセージの機密データを安全に伝達するための技術 図5
  • 特開-異種データメッセージの機密データを安全に伝達するための技術 図6
  • 特開-異種データメッセージの機密データを安全に伝達するための技術 図7
  • 特開-異種データメッセージの機密データを安全に伝達するための技術 図8
  • 特開-異種データメッセージの機密データを安全に伝達するための技術 図9
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023071651
(43)【公開日】2023-05-23
(54)【発明の名称】異種データメッセージの機密データを安全に伝達するための技術
(51)【国際特許分類】
   H04L 9/32 20060101AFI20230516BHJP
   G06F 21/60 20130101ALI20230516BHJP
   G06F 21/34 20130101ALI20230516BHJP
   G06Q 20/20 20120101ALI20230516BHJP
【FI】
H04L9/32 100C
G06F21/60 360
G06F21/34
G06Q20/20 340
【審査請求】有
【請求項の数】20
【出願形態】OL
(21)【出願番号】P 2023009214
(22)【出願日】2023-01-25
(62)【分割の表示】P 2021545350の分割
【原出願日】2018-10-15
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.JAVA
(71)【出願人】
【識別番号】505468864
【氏名又は名称】ビザ インターナショナル サービス アソシエーション
(74)【代理人】
【識別番号】110000855
【氏名又は名称】弁理士法人浅村特許事務所
(72)【発明者】
【氏名】オービエ、アンドレアス
(72)【発明者】
【氏名】オービエ、クリスチャン
(57)【要約】
【課題】識別子などの機密を安全に通信するための、システムおよび方法を開示する。
【解決手段】ユーザデバイスは、端末タイプ指標を含む第一のメッセージを受信してもよい。端末タイプ指標の特定の値について、ユーザデバイスは、第一の識別子および暗号化された識別子を含む、要求メッセージを送信するように構成され得る。端末タイプ指標の他の値については、ユーザデバイスは、第二の識別子の第一の部分および暗号化された識別子の第二の部分に少なくとも部分的に基づいて、難読化された識別子を生成するように構成され得る。その後、ユーザデバイスは、難読化された識別子および暗号化された識別子を含む、要求メッセージを送信し得る。
【選択図】図1
【特許請求の範囲】
【請求項1】
機密データを通信するためのコンピュータ実装方法であって、
アクセスデバイスによって、ターミナルタイプインジケータを含む第一のメッセージをユーザデバイスに送信することであって、前記ユーザデバイスが、1)静的アカウント識別子に対応する第一の識別子、および2)プライマリアカウント識別子に対応する第二の識別子を格納するように構成され、前記ユーザデバイスが、前記第二の識別子の一部を使用して暗号化された識別子を生成するようにさらに構成される、送信すること、
第一のターミナルタイプを示す前記ターミナルタイプインジケータに基づいて、
前記アクセスデバイスによって前記ユーザデバイスから、前記第一の識別子および前記ユーザデバイスによって生成された前記暗号化された識別子を含む第一の要求メッセージを受信すること、
前記第一の要求メッセージの受信に少なくとも部分的に基づいて、前記アクセスデバイスによって管理されるリソースへのアクセスを許可するかどうかを決定すること、および
第二のターミナルタイプを示す前記ターミナルタイプインジケータに基づいて、
前記アクセスデバイスによって前記ユーザデバイスから、難読化された識別子および前記暗号化された識別子を含む第二の要求メッセージを受信することであって、前記難読化された識別子が、前記第二の識別子の第一の部分および前記暗号化された識別子の第二の部分に基づいて前記ユーザデバイスによって生成される、受信すること、および
前記第二の要求メッセージの受信に少なくとも部分的に基づいて取引を開始すること、を含む、コンピュータ実装方法。
【請求項2】
前記暗号化された識別子が、前記ユーザデバイスに格納されたカウンタ値をさらに利用して生成され、前記ユーザデバイスが、前記第一の要求メッセージまたは前記第二の要求メッセージの送信に応答して、変更されたカウンタ値を生成するようにさらに構成される、請求項1に記載のコンピュータ実装方法。
【請求項3】
前記暗号化された識別子を生成することが、前記ユーザデバイスに格納された固有の導出キーで前記第二の識別子および前記変更されたカウンタ値を暗号化することをさらに含む、請求項2に記載のコンピュータ実装方法。
【請求項4】
前記暗号化された識別子の前記第二の部分が、前記暗号化された識別子の右端7ビットを含む、請求項1に記載のコンピュータ実装方法。
【請求項5】
前記第二の識別子の前記第一の部分が、前記第二の識別子の左端8ビットを含む、請求項1に記載のコンピュータ実装方法。
【請求項6】
前記第二の識別子の前記第一の部分が、取得者に関連付けられた識別番号を含む、請求項1に記載のコンピュータ実装方法。
【請求項7】
前記第一の識別子および前記暗号化された識別子を含む前記第一の要求メッセージを受信することによって、前記アクセスデバイスが以下の動作:
前記第一の識別子を格納された複数の識別子と比較すること、
前記第一の識別子が前記格納された複数の識別子に含まれる場合に前記第一の要求メッセージを拒否することであって、前記第一の要求メッセージを拒否することによって、前記アクセスデバイスによって管理される前記リソースに前記ユーザデバイスがアクセスすることが拒否される、拒否すること、および
前記格納された複数の識別子が前記第一の識別子を含む場合に前記第一の要求メッセージを承認することであって、前記第一の要求メッセージを承認することによって、前記アクセスデバイスによって管理される前記リソースに前記ユーザデバイスがアクセスすることが許可される、承認すること、を実行する、請求項1に記載のコンピュータ実装方法。
【請求項8】
前記第一の識別子および前記暗号化された識別子を含む前記第一の要求メッセージを受信することによって、前記アクセスデバイスがさらに以下の動作:
前記第一の識別子および前記暗号化された識別子を含む、認証要求メッセージを生成すること、および
前記認証要求メッセージを認証側エンティティコンピュータに送信すること、を実行する、請求項1に記載のコンピュータ実装方法。
【請求項9】
前記認証側エンティティコンピュータが、
前記第一の識別子および前記暗号化された識別子を含む、認証要求メッセージを受信し、
前記第一の識別子と関連付けられた格納された識別子を識別し、
前記暗号化された識別子から復号化された識別子を生成し、
前記格納された識別子を前記復号化された識別子と比較し、
前記格納された識別子を前記復号化された識別子と比較することに少なくとも部分的に基づいて、前記認証要求メッセージを処理するように構成される、請求項8に記載のコンピュータ実装方法。
【請求項10】
前記取引を開始することが、
前記難読化された識別子および前記暗号化された識別子を含む、認証要求メッセージを生成すること、および
前記認証要求メッセージを認証側エンティティコンピュータに送信することであって、前記難読化された識別子および前記暗号化された識別子を含む前記認証要求メッセージを送信することによって、前記認証側エンティティコンピュータに、
前記難読化された識別子の特定の部分に少なくとも部分的に基づいて導出キーを導出させ、
前記導出キーを利用して、前記暗号化された識別子から復号化された識別子を生成させ、
前記復号化された識別子を使用して、前記認証要求メッセージを処理させる、送信すること、を含む、請求項1に記載のコンピュータ実装方法。
【請求項11】
アクセスデバイスであって、
一つまたは複数のプロセッサ、および
機密データを通信するためのコンピュータ実行可能命令を格納する一つまたは複数のメモリであって、前記一つまたは複数のプロセッサによって前記コンピュータ実行可能命令を実行することによって、前記アクセスデバイスに、
ターミナルタイプインジケータを含む第一のメッセージをユーザデバイスに送信することであって、前記ユーザデバイスが、1)静的アカウント識別子に対応する第一の識別子、および2)プライマリアカウント識別子に対応する第二の識別子を格納するように構成され、前記ユーザデバイスが、前記第二の識別子の一部を使用して暗号化された識別子を生成するようにさらに構成される、送信すること、
第一のターミナルタイプを示す前記ターミナルタイプインジケータに基づいて、
前記ユーザデバイスから、前記第一の識別子および前記ユーザデバイスによって生成された前記暗号化された識別子を含む第一の要求メッセージを受信すること、
前記第一の要求メッセージの受信に少なくとも部分的に基づいて、前記アクセスデバイスによって管理されるリソースへのアクセスを許可するかどうかを決定すること、および
第二のターミナルタイプを示す前記ターミナルタイプインジケータに基づいて、
前記ユーザデバイスから、難読化された識別子および前記暗号化された識別子を含む第二の要求メッセージを受信することであって、前記難読化された識別子が、前記第二の識別子の第一の部分および前記暗号化された識別子の第二の部分に基づいて前記ユーザデバイスによって生成される、受信すること、および
前記第二の要求メッセージの受信に少なくとも部分的に基づいて取引を開始することを実行させる、一つまたは複数のメモリ、を備える、アクセスデバイス。
【請求項12】
前記第一のターミナルタイプが、前記アクセスデバイスが交通機関と関連付けられることを示す、請求項11に記載のアクセスデバイス。
【請求項13】
前記アクセスデバイスによって管理される前記リソースへのアクセスを許可するかどうかを決定することが、ほぼリアルタイムで実行される、請求項11に記載のアクセス装置。
【請求項14】
前記第一の識別子の第一の左端8ビットが、前記第二の識別子の第二の左端8ビットに合致する、請求項11に記載のユーザデバイス。
【請求項15】
前記アクセスデバイスが非接触型リーダである、請求項11に記載のユーザデバイス。
【請求項16】
前記コンピュータ実行可能命令を実行することにより、前記アクセスデバイスに、前記第一の識別子および前記暗号化された識別子を含む認証要求メッセージを認証側エンティティコンピュータにさらに送信させ、前記認証要求メッセージが、前記第一の要求メッセージの受信に少なくとも部分的に基づいて送信され、前記認証要求メッセージが、取引タイプ値を含む、請求項11に記載のユーザデバイス。
【請求項17】
前記認証側エンティティコンピュータが、前記認証要求メッセージの前記第一の識別子が、前記第一の識別子が七つのゼロで終了しないことを識別することに少なくとも部分的に基づいて、前記静的アカウント識別子であると識別するように構成される、請求項16に記載のユーザデバイス。
【請求項18】
前記第一のメッセージが、前記第一の識別子およびチェックサム値を含むデータフィールドを含み、前記チェックサム値が、前記第一の識別子が変更されていないことを示し、前記アクセスデバイスによって管理される前記リソースへのアクセスを許可するかどうかを決定することが、前記チェックサム値が、前記第一の識別子が変更されていないことを示すことを少なくとも部分的に決定することに基づく、請求項11に記載のユーザデバイス。
【請求項19】
前記第一の要求メッセージの受信に少なくとも部分的に基づいて、前記アクセスデバイスによって管理される前記リソースへのアクセスを許可するかどうかを決定することが、
前記第一の識別子を、要求されたアクセスが拒否された識別子を示す格納されたブラックリストと比較すること、および
前記第一の識別子が前記格納されたブラックリストに含まれる場合、前記リソースへのアクセスを拒否すること、をさらに含む、請求項18に記載のユーザデバイス。
【請求項20】
前記難読化された識別子が、前記第二の識別子の最初の八桁、七つのゼロ、およびチェックサム値を含む、請求項11に記載のユーザデバイス。
【発明の詳細な説明】
【技術分野】
【0001】
本開示の実施形態は、取引で利用されるメッセージ内の機密データを難読化することに関する。これらの技術は、接触および/または非接触スマートカード取引に適用することができる。概して、非接触スマートカードは、消費者に効率的な支払方法を提供するように設計されている。スマートカードは、例えば、無線周波数または赤外線信号を使用することによって、必要な情報を販売時点情報管理(POS)デバイスに提供して、取引を完了することができる。POSデバイスは、提供された情報を受信し、取引を処理し得る。
【背景技術】
【0002】
スマートカードによって送られる情報は、ユーザのアカウント識別子(例えば、個人アカウント番号)などの機密データを含むことができる。結果として、この情報を傍受し得る熟練した不正行為者から、ユーザを保護するために、セキュリティ対策が必要となる。アカウント識別子全体が暗号化されていないため、現在の技術は問題がある場合がある。他の従来の技術では、アカウント識別子は、暗号化され得るが、既知のデータフィールドを有する既知のプロトコルに従って、依然として送信および/または提供される。利口な不正行為者は、メッセージ内の暗号化されたデータフィールドを簡単に識別することができるため、その情報を自身の非道な行為に利用できる可能性が高い。加えて、従来の技術を使用すると、アカウント識別子は静的なままであり、不正行為者がユーザの取引を追跡できる可能性がある。
【0003】
その上さらに、従来のシステムでは、機密情報の使用は制限されない。例えば、不正行為者は、一旦機密情報を取得したなら、様々な状況で機密情報を利用し得る。
【発明の概要】
【発明が解決しようとする課題】
【0004】
本発明の実施形態は、これらおよび他の問題に、個々にかつまとめて対処する。
【課題を解決するための手段】
【0005】
本発明の実施形態は、非接触スマートカードなどのユーザデバイスと関連付けられたアカウント識別子(例えば、PAN)を、安全に伝達するために使用できる方法、システム、デバイス、およびコンピュータ可読媒体を対象とする。一部の実施形態では、ユーザデバイスには、プライマリアカウント番号(PAN)およびセカンダリアカウント番号(SAN:secondary account number)が保存されていてもよい。アカウント識別子(例えば、PAN)は、プライバシーの保護のため、アカウント識別子を追跡することができないように伝達されてもよい。有利には、本発明の実施形態では、アカウント情報は、安全に、かつ既存の支払インフラを著しく更新する必要が全くないように伝達される。
【0006】
追加のアカウント識別子(例えば、SAN)は、静的識別子が必要とされる状況で、本明細書で論じる実施形態において利用され得る。例として、いくつかのタイプのアクセスデバイスは、ほぼリアルタイムで、ユーザによるリソースへのアクセスを許可または拒否することが期待される。したがって、こうしたアクセスデバイスは、スマートカードのユーザへのアクセスを迅速に許可もしくは拒否するために、許可リストおよび/またはブロックリストと照合するよう、静的識別子を利用してもよい。追加のアカウント識別子(例えば、SAN)は、特定の状況においてのみ利用され得る。例えば、システムによって、SANが、特定のタイプの端末および/もしくは小売業者、ならびに/または取引が関与する取引でのみ使用可能であることを保証し得る。非限定的な例として、システムは、SANが、交通端末(例えば、公共交通機関の自動改札)が関与する取引でのみ利用され得ることを保証するように、構成されてもよい。
【0007】
本発明の一実施形態は、ユーザデバイスによってアクセスデバイスから、端末タイプ指標を含む第一のメッセージを受信することを含む方法を対象とする。方法は、第一の端末タイプを示す端末タイプ指標に応じて、ユーザデバイスからアクセスデバイスへ、第一の識別子(例えば、SAN)および暗号化された識別子(例えば、PANおよび取引カウンタから生成された暗号化された識別子)を含む、要求メッセージを送信することをさらに含み得る。方法は、第二の端末タイプを示す端末タイプ指標に応じて、ユーザデバイスによって、第二の識別子(例えば、プライマリPAN)の第一の部分および暗号化された識別子の第二の部分に少なくとも部分的に基づいて、難読化された識別子を生成することをさらに含み得る。方法は、ユーザデバイスからアクセスデバイスへ、送信することをさらに含み得る。一部の実施形態では、要求メッセージは、難読化された識別子および暗号化された識別子を含み得る。
【0008】
本発明の別の実施形態は、一つ以上のプロセッサと、一つ以上のプロセッサによって実行されるとき、ユーザデバイスに動作を実施させるコンピュータ実行可能命令を含む、一つ以上のメモリとを備えるユーザデバイスを対象とする。動作は、ユーザデバイスによってアクセスデバイスから、端末タイプ指標を含む第一のメッセージを受信することを含み得る。動作は、第一の端末タイプを示す端末タイプ指標に応じて、ユーザデバイスからアクセスデバイスへ、第一の識別子(例えば、SAN)および暗号化された識別子(例えば、プライマリPANおよび取引カウンタから生成された暗号化された識別子)を含む、要求メッセージを送信することをさらに含み得る。動作は、第二の端末タイプを示す端末タイプ指標に応じて、ユーザデバイスによって、第二の識別子(例えば、プライマリPAN)の第一の部分および暗号化された識別子の第二の部分に少なくとも部分的に基づいて、難読化された識別子を生成することをさらに含み得る。動作は、ユーザデバイスからアクセスデバイスへ、送信することをさらに含み得る。一部の実施形態では、要求メッセージは、難読化された識別子および暗号化された識別子を含み得る。
【0009】
本発明の別の実施形態は、(非一時的)コンピュータ可読媒体を対象とする。コンピュータ可読媒体は、本明細書で論じる方法を実施するためのコードを含む。一部の実施形態では、スマートカードなどのユーザデバイスが、このコンピュータ可読媒体を備えてもよい。
【0010】
本発明のこれらのおよび他の実施形態について、図面を参照して以下でさらに詳細に記載する。
【図面の簡単な説明】
【0011】
図1図1は、一部の実施形態による、取引を処理するためのシステムのブロック図を示す。
図2図2は、一部の実施形態による、データを生成しユーザデバイスに保存する方法を示す。
図3図3は、一部の実施形態による、コンピューティングデバイス(例えば、スマートカード)上に常駐するデータから、一意に導出された鍵を生成するための方法を示す。
図4図4は、一部の実施形態による、オフライン認証を実施するための方法を示す。
図5図5は、一部の実施形態による、機密データを安全に伝達するための方法のフローチャートを示す。
図6図6は、一部の実施形態で使用するための例示的な記録形式を示す。
図7図7は、一部の実施形態で使用するための別の例示的な記録形式を示す。
図8図8は、一部の実施形態による、データ検証を実施するための方法のフローチャートを示す。
図9図9は、一部の実施形態による、データ検証を実施する別の方法のフローチャートを示す。
【発明を実施するための形態】
【0012】
上記のように、慣例の支払取引では、アカウント識別子(例えば、プライマリPANとも呼ばれる個人アカウント識別子)は、非接触スマートカードなどのユーザデバイスから、最終的に従来の支払処理ネットワークを通って、アクセスデバイス(例えば、POS端末、自動改札機リーダなど)を通過するとき、暗号化されていない。一部の従来の技術では、アカウント識別子は、暗号化および/または難読化される場合があるが、暗号化/難読化されたデータは、依然として、取引メッセージの従来のデータフィールドの中に提供されてもよく、データフィールドは、潜在的な不正行為者には容易に識別可能である。
【0013】
アカウント識別子全体の暗号化は、可能であるものの、すべての状況下で実用的であるわけではない場合がある。アカウント識別子が暗号化されている場合、従来の取引処理システムでは、取引をうまく処理できない場合がある。例えば、代表的なアカウント識別子は銀行識別番号(BIN)を含む。BINは、承認要求メッセージを、適切な発行者または支払プロセッサにルーティングするように使用される。アカウント識別子が暗号化される場合、BINは変更される。BINが変わると、適切な承認要求メッセージを、正しい発行者にルーティングできない。
【0014】
アカウント識別子全体の暗号化に関連付けられた別の制限は、アカウント識別子における数字の配列と関連付けられる、エラーチェックに関する。エラーチェックは、アカウント識別子の数字が適切な配列にあるかを判定する、チェックサムアルゴリズムを使用して達成され得る。チェックサムアルゴリズムの例は、MOD-10アルゴリズム(「Luhnチェック」としても知られる)である。
【0015】
したがって、アカウント識別子全体の暗号化によって、少なくともBIN、チェックサムが損なわれ、レシートに印刷された数字によりアカウント識別子を識別する機能が毀損するであろう。
【0016】
本明細書に記載されるプロセスは、開始するデバイス(例えば、スマートカード)にあるアカウント識別子を保護するために使用され得る。以下でさらに詳細に説明するように、本発明の実施形態では、アカウント識別子の一部分のみを難読化し、これにより、BINにアカウントを与えて暗号化しないままとし、Luhnチェックの利用を続けることが可能になる。加えて、本発明の実施形態はまた、代表的な承認要求メッセージ内のアカウント識別子を難読化するだけでなく、暗号化されたアカウント識別子全体を、識別できる可能性を低くするために、メッセージの他の場所に提供することを保証するようにも使用できる。
【0017】
また本明細書で論じる技術によって、取引の状況(例えば、どのタイプの端末が情報を要求しているか)に応じて、難読化された識別子またはSANを、ユーザデバイスが利用することも可能になる。したがって、取引タイプ、端末タイプなどの第一のセットに関連付けられている取引に対して、難読化されたPANを取引で利用してもよく、一方SANは、取引タイプ、端末タイプなどの第二のセットと関連付けられる取引に利用してもよい。SANは、許容可能な状況で利用されるとき、承認事業体によって処理のみされるように制限されてもよい。取引/端末タイプ取引の第一のセットに対して、ユーザの活動を追跡できないように、難読化されたPANを利用してもよい。これらの技術によって、オフライン取引(例えば、端末がその場でスマートカードを認証する取引)、およびオフライン取引から生じる後続のオンライン取引に、静的識別子を利用することが可能になり、一方、対応するオフライン認証が不要なオンライン認証取引には、動的識別子(例えば、動的値)を利用してもよい。
【0018】
本発明の詳細な実施形態について論じる前に、特定の用語についてのいくつかの説明が有用であり得る。
【0019】
「コンピューティングデバイス」(「ユーザデバイス」とも呼ばれる)は、計算を実施することができ、他のデバイスと通信できる、任意の好適なデバイスであってもよい。スマートカードなどの消費者用ポータブルデバイスは、コンピューティングデバイスの一例である。他のタイプのコンピューティングデバイスは、ポータブルではない場合がある。
【0020】
「動的値」は、動的に変化する値を指すことを意図する。コンピューティングデバイスは、様々な動的値を維持できる。動的値の例は、アプリケーション取引カウンタ(ATC:application transaction counter)である。ATCは最初に、コンピューティングデバイス(例えば、承認事業体)の発行者によって、所定の値に設定されてもよい。その後、ATCは各取引と共に値が増加してもよい。交互にATCは、各取引と共にその初期の所定値から減少し得る。ATCは、任意の長さの値であってもよい。加えて、発行者は、対応するATCを、発行者のコンピュータがアクセス可能なように維持してもよい。この対応するATCは、不正目的で再現された可能性のある支払サービスを識別するために使用され得る。代替の実施形態では、取引データに基づく暗号文、デジタル署名、またはハッシュ値が、コンピューティングデバイスに保存されたATCの代わりに、またはそれと併せて使用され得る。
【0021】
他の動的値(例えば、データ要素)の例には、時刻、現在の取引額、および端末からランダムに生成された番号などが含まれ得る。データ要素は、取引ごとに、またはほぼ取引ごとに変更できるという意味で動的である。動的データ要素は、ユーザのコンピューティングデバイスに関係してもよく、および/または概してユーザに関係し得る。
【0022】
「承認事業体」は、要求を承認する事業体とすることができる。承認事業体の例は、発行者、政府機関、文書保管所、アクセス管理者などであり得る。「発行者」は通常、ユーザのアカウントを保持するビジネス事業体(例えば、銀行)を指し得る。発行者はまた、消費者に対して携帯電話、スマートカード、タブレット、またはラップトップなどのユーザデバイスに保存される、支払証明書を発行することができる。「承認事業体コンピュータ」は、承認事業体によって、または承認事業体に代わって操作されてもよい。
【0023】
「アクワイアラ」は通常、特定の小売業者または他の事業体とビジネス関係を有するビジネス事業体(例えば、商業銀行)とすることができる。一部の事業体は、発行者およびアクワイアラの両方の機能を果たすことができる。一部の実施形態は、こうした単一事業体の発行者-アクワイアラを含み得る。アクワイアラは、「転送コンピュータ」とも総称され得る、アクワイアラコンピュータを操作し得る。
【0024】
「リソースプロバイダ」は、物品、サービス、情報、および/またはアクセスなど、リソースを提供できる事業体であり得る。リソースプロバイダの例には、小売業者、アクセスデバイス、安全なデータアクセスポイントなどを含む。「小売業者」は通常、取引に携わり、物品もしくはサービスを販売する、または物品もしくはサービスへのアクセスを提供することができる事業体であり得る。「リソースプロバイダコンピュータ」は、リソースプロバイダによって、またはリソースプロバイダに代わって操作され得る、任意の好適なコンピューティングデバイスであってもよい。
【0025】
「処理ネットワークコンピュータ」(中央サーバコンピュータとも呼ばれる)は、ネットワークデータを処理するために使用される、サーバコンピュータを含み得る。一部の実施形態では、処理ネットワークコンピュータは、データベースに結合されてもよく、一つ以上のクライアントコンピュータからの要求にサービスを提供する、いずれのハードウェア、ソフトウェア、他のロジック、または前述の組み合わせを含んでもよい。処理ネットワークコンピュータは、一つ以上の計算装置を備えてもよく、一つ以上のクライアントコンピュータからの要求にサービスを提供する、様々なコンピュータ構造、配置、およびコンパイルのうちのいずれを使用してもよい。一部の実施形態では、処理ネットワークコンピュータは、複数のサーバコンピュータを操作し得る。こうした実施形態では、各サーバコンピュータは、所与の領域に対する取引を処理するか、または取引データに基づいて特定タイプの取引に対処するように構成され得る。
【0026】
処理ネットワークコンピュータは、承認サービスと、例外ファイルサービスと、清算および決済サービスとをサポートし配信するのに使用される、データ処理サブシステム、ネットワーク、ならびに動作を含んでいてもよい。例示的な処理ネットワークコンピュータは、VisaNet(商標)を含んでいてもよい。VisaNet(商標)を含むネットワークは、クレジットカード取引、デビットカード取引、および他のタイプの商取引を処理することができる。特にVisaNet(商標)には、承認要求を処理する統合支払システム(Integrated Paymentsシステム)と、清算および決済サービスを実施するBase IIシステムとが含まれる。処理ネットワークコンピュータは、インターネットを含む、任意の好適な有線または無線ネットワークを使用することができる。
【0027】
「承認要求メッセージ」は、取引処理コンピュータおよび/または承認事業体コンピュータ(例えば、支払カードの発行者)へ送られて、取引に対する承認を要求する電子メッセージであってもよい。一部の実施形態による承認要求メッセージは、支払デバイスまたは支払アカウントを使用する消費者によりなされる支払いと関連付けられた、電子取引情報を交換するシステムの標準である、ISO8583に準拠することができる。承認要求メッセージは、支払デバイスまたは支払アカウントと関連付けられてもよい、発行者アカウント識別子を含んでもよい。承認要求メッセージはまた、単に例として、サービスコード、CVV(カード検証値)、dCVV(動的カード検証値)、有効期限などを含む、「識別情報」に対応する追加のデータ要素を含むことができる。承認要求メッセージはまた、取引を識別および/または承認するかの判定に利用されてもよい、いかなる他の情報だけでなく、取引額、小売業者識別子、小売業者所在地など、現在の取引と関連付けられた、任意の情報などの「取引情報」を含んでもよい。
【0028】
「承認応答メッセージ」は、承認事業体コンピュータまたは取引処理コンピュータによって生成された、承認要求メッセージに応答する電子メッセージとすることができる。承認応答メッセージは、単に例として、次の状態指標のうちの一つ以上を含んでもよい。承認―取引が承認された。拒否―取引が承認されなかった。または、コールセンター―応答はより多くの情報を保留中で、小売業者は、フリーダイヤルの認証電話番号に電話する必要がある。承認応答メッセージはまた、承認事業体(例えば、発行者銀行)が、承認要求メッセージに応じて、取引の承認を示す、リソースプロバイダコンピュータへの電子メッセージ(直接または取引処理コンピュータを介してのいずれか)で返信するコードであり得る、承認コードを含むことができる。コードは、承認の証明として役割を果たし得る。一部の実施形態では、取引処理コンピュータは、承認応答メッセージを生成するか、またはそれをリソースプロバイダに転送し得る。
【0029】
「プライマリアカウント番号」(PAN:primary account number)は、支払アカウントに対する識別子であり得る。PANは、一連の英数字(例えば、16個)を含み得る。PAN(またはPANの難読化もしくは暗号化されたバージョン)を使用して、支払取引を開始、承認、決済、または解決することができる。一部の実施形態では、PANをいかなるタイプの取引に利用してもよい。
【0030】
「‐アカウント番号」(SAN)は、支払アカウントに対する別の識別子であり得る。SANは、一連の英数字(例えば、16個)を含み得る。SAN(またはPANの難読化もしくは暗号化されたバージョン)を使用して、取引を開始、承認、決済、または解決することができる。一部の実施形態では、SANの使用を特定のタイプの取引に制限し得る。例えば、SANは、取引が特定のタイプの小売業者(例えば、公共交通機関、交通機関の小売業者、競技場の小売業者など)を含むとき、取引が特定の端末タイプの端末(例えば、自動改札機など)によって開始されるとき、および/または取引が特定タイプの取引(例えば、交通機関の取引、料金の確認取引など)であるときに利用され得る。一部の実施形態では、SANがPANと関連付けられてもよく、両方が特定のユーザのアカウント(例えば、ユーザに代わって発行者により維持される金融口座)と関連付けられてもよい。一部の実施形態では、PANおよび関連付けられたSAN各々が、同じ左端の8桁(例えば、銀行識別番号(BIN)に対応する)を含む場合がある。
【0031】
「難読化された識別子」は、難読化されたバージョンの識別子(例えば、16桁のPAN)である、識別子を含み得る。一部の実施形態では、難読化された識別子は、「形式保存」であってもよく、既存の取引処理ネットワークで使用されるアカウント識別子に準拠する数値形式(例えば、ISO8583金融取引メッセージ形式)を有することができる。一部の実施形態では、難読化された識別子は、支払取引を開始、承認、決済、もしくは解決するように、または元の証明書が通常提供されるであろう他のシステムで、元の証明書を表すように、PANの代わりに使用されてもよい。
【0032】
「暗号化された識別子」は、任意の好適な暗号化された値を含み得る。暗号化された値は、例えば、対称および/または非対称の暗号化技術を利用して、任意の好適な暗号化技術を利用する、識別子(例えば、プライマリPAN)から生成され得る。一部の実施形態では、暗号化された識別子は、プライマリPANおよび動的値を利用して生成されてもよく、両方ともにユーザデバイスに保存されている。
【0033】
本出願の目的のために、「支払データ」は、金融用途に関して、取引を実行するように支払サービスによって使用されるそれらのデータ要素、および非金融取引に関して、本発明を除いて必要ないかなるデータ要素も含むことができる。例えば、支払サービスが、磁気ストライプクレジットカード取引であるとき、「支払データ」は、プライマリアカウント番号、有効期限、サービスコード、および任意データなど、クレジットカード業界の当業者が理解するような、トラック1および/またはトラック2のデータを含むであろう。「支払データ」はまた、一意のカード識別番号、またはサービスプロバイダに対する一意の識別番号も含み得る。支払データは、ユーザデバイス(例えば、クレジットおよび/またはデビットカード、スマートカードなど)上に配置されるメモリの中に存在し得る。
【0034】
「サーバコンピュータ」は通常、強力なコンピュータまたはコンピュータのクラスタである。例えば、サーバコンピュータは、大型メインフレーム、ミニコンピュータクラスタ、またはユニットとして機能するサーバ群であり得る。一例では、サーバコンピュータは、ウェブサーバに結合されるデータベースサーバであり得る。
【0035】
「プロセッサ」は、任意の好適な単数または複数のデータ計算デバイスを指すことができる。プロセッサは、所望の機能を達成するために共に動作する、一つ以上のマイクロプロセッサを備えることができる。プロセッサは、ユーザおよび/またはシステム生成要求を実行するプログラム構成要素を実行するのに適切な、少なくとも一つの高速データプロセッサを備えるCPUを含んでもよい。CPUは、AMDのアスロン、デュロン、および/もしくはオプテロン、IBMおよび/もしくはモトローラのPowerPC、IBMおよびソニーのセルプロセッサ、インテルのセレロン、アイテニウム、ペンティアム(登録商標)、ジーオン、および/もしくはXScale、ならびに/または同様のプロセッサ(複数可)などのマイクロプロセッサであってもよい。
【0036】
「メモリ」は、電子データを保存できる、任意の好適な単数または複数のデバイスであってもよい。好適なメモリとして、所望の方法を実施するためにプロセッサによって実行できる命令を保存する、非一時的コンピュータ可読媒体が含まれ得る。メモリの例として、一つ以上のメモリチップ、ディスクドライブなどが含まれ得る。こうしたメモリは、任意の好適な電気的、光学的、および/または磁気的な動作モードを使用して動作することができる。
【0037】
図1は、一部の実施形態による、取引を処理するためのシステム100のブロック図を示す。システム100は、認証、ならびに/または金融取引および非金融取引の承認のために、図1に示す様々なコンピュータ間のデータ通信を促進するように使用され得る。システム100は、ユーザデバイス102、リソースプロバイダコンピュータ104、転送コンピュータ106、中央サーバコンピュータ108、および承認事業体コンピュータ110を含む。これらのシステムおよびコンピュータの各々が、互いと動作連通していてもよい。説明を簡単にするために、ある一定数の構成要素を図1に示している。しかしながら、本発明の実施形態は、各構成要素を一つより多く含んでもよいことは理解されるものとする。加えて、本発明の一部実施形態は、図1に示す構成要素のすべてより少ないまたは多い数を含んでもよい。加えて、図1の構成要素は、任意の好適な通信プロトコルを使用して、任意の好適な通信媒体(インターネットを含む)を介して通信してもよい。
【0038】
リソースプロバイダコンピュータ104は、リソースプロバイダ(例えば、小売業者、交通システムなど)によって、またはリソースプロバイダに代わって操作されてもよく、転送コンピュータは、リソースプロバイダと関連付けられてもよい。例えば、転送コンピュータは、リソースプロバイダと関連付けられたアカウントを管理する責任を負う、アクワイアラ(例えば、金融機関)によって操作されてもよい。承認事業体コンピュータ110は、発行者(例えば、別の金融機関)によって操作されてもよい。一部の実施形態では、事業体はアクワイアラおよび発行者の両方であり、本発明の実施形態はこうした事業体を含む。
【0039】
ユーザデバイス102は、いかなる好適な形態であってもよい。例えば、ユーザデバイス102は、財布および/またはポケットに収まることができるように、携帯型でかつコンパクトであり得る。ユーザデバイス102の例としては、スマートカード、クレジットカードおよび/またはデビットカード、キーチェーンデバイスなどを挙げることができる。ユーザデバイス102の他の例には、携帯電話、携帯情報端末(PDA)、ポケットベル、支払カード、セキュリティカード、アクセスカード、スマートメディア、トランスポンダなどが含まれ得る。ユーザデバイス102はまた、小売店舗のポイントなどを保存するためのストアドバリューカードであってもよい。
【0040】
ユーザデバイス102は、コンピュータ可読媒体(CRM)112および本体114を備えてもよい。CRM112は、プラスチック基材、ハウジング、または他の構造の形態であってもよい、本体114上にあり得る。ユーザデバイス102は、カードの形態である場合、個人アカウント番号(PAN)が浮き出すエンボス領域116を有してもよい。一部の実施形態では、CRM112は、PAN、およびセカンダリアカウント番号(例えば、SAN)、ならびに/またはカウンタを保存してもよい。
【0041】
コンピュータ可読媒体112は、データを保存するメモリであってもよく、いかなる好適な形態であってもよい。例示のCRM112は、磁気ストライプ、メモリチップなどの形態であってもよい。コンピュータ可読媒体112は、プライマリPAN、ならびに/または暗号化されたおよび/もしくは難読化されたPANを、暗号化または難読化された形式で電子的に保存し得る。
【0042】
中央サーバコンピュータ108は、承認サービスと、例外ファイルサービスと、清算および決済サービスとをサポートし配信するのに使用される、データ処理サブシステム、ネットワーク、ならびに動作を含んでいてもよい。例示の支払処理ネットワークは、VisaNet(商標)を含んでいてもよい。VisaNet(商標)などの支払処理ネットワークは、クレジットカード取引、デビットカード取引、および他のタイプの商取引を処理することができる。特にVisaNet(商標)には、承認要求を処理するVIPシステム(Visa Integrated Paymentsシステム)と、清算および決済サービスを実施するBase 11システムが含まれる。
【0043】
中央サーバコンピュータ108は、サーバコンピュータを含み得る。サーバコンピュータは通常、強力なコンピュータまたはコンピュータのクラスタである。例えば、サーバコンピュータは、大型メインフレーム、ミニコンピュータクラスタ、またはユニットとして機能するサーバ群であり得る。一例では、サーバコンピュータは、ウェブサーバに結合されるデータベースサーバであり得る。中央サーバコンピュータ108は、インターネットを含む、任意の好適な有線または無線ネットワークを使用することができる。
【0044】
リソースプロバイダコンピュータ104は、ユーザデバイス102と相互作用できるアクセスデバイス118(例えば、自動改札機、ドア、販売時点情報管理端末など)も有してもよく、またはアクセスデバイス118からの通信を受信してもよい。図1では、アクセスデバイス118は、リソースプロバイダコンピュータ104の構成要素であってもよく、ならびに/またはアクセスデバイス118は、リソースプロバイダコンピュータによってアクセス可能であり、および/もしくはリソースプロバイダコンピュータ104と通信してもよい。一部の実施形態では、アクセスデバイス118は、本発明の他の実施形態では、いかなる他の好適な場所にも配置される可能性がある。リソースプロバイダコンピュータ104は、リソースプロバイダ(例えば、小売業者)によって操作される、任意の好適な計算装置を含み得る。一部の実施形態では、リソースプロバイダコンピュータ104は、リソースプロバイダ(例えば、小売業者)と関連付けられた、一つ以上のウェブサイトをホストし得る、一つ以上のサーバコンピュータを含んでもよい。一部の実施形態では、リソースプロバイダコンピュータ104は、ユーザ(例えば、消費者)とリソースプロバイダとの取引のため、支払検証および/または認証プロセスの一部として、転送コンピュータ106を介して中央サーバコンピュータ108にデータを送るように構成されてもよい。リソースプロバイダコンピュータ104はまた、リソースプロバイダとユーザ103との取引に対する承認要求メッセージを生成し、追加の取引処理のため、承認要求メッセージを承認事業体コンピュータ110に(例えば、転送コンピュータ106および/または中央サーバコンピュータ108を介して)ルーティングするように構成されてもよい。
【0045】
本発明の実施形態によるアクセスデバイスは、任意の好適な形態であってもよい。アクセスデバイスの例として、販売時点情報管理(POS)デバイス、自動改札機、ドア、携帯電話、PDA、パーソナルコンピュータ(PC)、タブレットPC、ハンドヘルド専用リーダ、セットトップボックス、電子キャッシュレジスタ(ECR)、現金自動預入支払機(ATM)、仮想キャッシュレジスタ(VCR)、キオスク、セキュリティシステム、アクセスシステムなどが挙げられる。
【0046】
アクセスデバイス118は、リーダ120、プロセッサ122、およびコンピュータ可読媒体124を含み得る。リーダ120では、任意の好適な接触または非接触動作モードを使用することができる。例えば、例示のカードリーダには、ユーザデバイス102と相互作用するように、RF(無線周波数)アンテナ、磁気ストライプリーダなどを含むことができる。
【0047】
少なくとも一実施形態では、ユーザ103は、ユーザデバイス102(例えば、クレジットカード)を使用して、リソースプロバイダコンピュータ104で商品またはサービスの購入を開始し得る。ユーザデバイス102は、POS(販売時点情報管理)端末などのアクセスデバイス118と、相互作用することができる。例えば、ユーザ103は、クレジットカードを取り出してもよく、それをPOS端末の適切なスロットに通してもよい。あるいは、POS端末が非接触リーダであってもよく、ユーザデバイス102が、非接触カードなどの非接触型デバイスであってもよい。この相互作用の間に、ユーザデバイス102は、アクセスデバイス118が特定のタイプの端末(例えば、POSデバイス)であると判定するように構成され得る。アクセスデバイス118が、この特定のタイプの端末であると仮定すると、ユーザデバイス102は、ユーザデバイス102に保存されたプライマリPANの難読化されたバージョンと、プライマリPANの暗号化されたバージョンとを、アクセスデバイス118に提供し得る。
【0048】
承認要求メッセージはその後、転送コンピュータ106に転送されてもよい。転送コンピュータ106は通常、特定のリソースプロバイダ(例えば、小売業者)または他の事業体と取引関係があり、取引のプロセスに関与し得る、ビジネス事業体(例えば、商業銀行)と関連付けられる。転送コンピュータ106は、リソースプロバイダ用のアカウントを発行および管理し、リソースプロバイダに代わって、承認事業体コンピュータ110と資金を交換し得る。一部の事業体は、承認事業体コンピュータ110および転送コンピュータ106両方の機能を果たすことができる。本発明の実施形態は、こうした単一事業体の発行者-アクワイアラコンピュータを含む。承認要求メッセージを受信した後、転送コンピュータ106は、承認要求メッセージを中央サーバコンピュータ108に送り得る。中央サーバコンピュータ108はその後、承認要求メッセージを、ユーザデバイス102の承認事業体コンピュータ110、または承認事業体に代わって役割を果たす第三者事業体に転送し得る。
【0049】
中央サーバコンピュータ108は、処理(例えば、支払処理)に使用される、少なくとも一つのサーバコンピュータを含むか、または操作する、ネットワークであってもよい。中央サーバコンピュータ108の中にあるサーバコンピュータは、プロセッサと、プロセッサに結合されたコンピュータ可読媒体とを含んでもよく、コンピュータ可読媒体は、本明細書に記載される機能を果たすために、プロセッサによって実行可能なコードを含む。一部の実施形態では、サーバコンピュータは、データベースに結合されてもよく、一つ以上のクライアントコンピュータからの要求にサービスを提供する、いずれのハードウェア、ソフトウェア、他のロジック、または前述の組み合わせを含んでもよい。サーバコンピュータは、一つ以上の計算装置を備えてもよく、一つ以上のクライアントコンピュータからの要求にサービスを提供する、様々なコンピュータ構造、配置、およびコンパイルのうちのいずれを使用してもよい。一部の実施形態では、中央サーバコンピュータ108は、複数のサーバコンピュータを操作し得る。こうした実施形態では、各サーバコンピュータは、所与の領域に対する取引を処理するか、または取引データに基づいて特定タイプの取引に対処するように構成され得る。
【0050】
中央サーバコンピュータ108は、承認サービスと、例外ファイルサービスと、清算および決済サービスとをサポートし配信するのに使用される、データ処理サブシステム、ネットワーク、ならびに動作を含んでいてもよい。中央サーバコンピュータ108は、VisaNet(商標)を含んでもよい。VisaNet(商標)を含むネットワークは、クレジットカード取引、デビットカード取引、および他のタイプの商取引を処理することができる。特にVisaNet(商標)には、承認要求を処理する統合支払システム(Integrated Paymentsシステム)と、清算および決済サービスを実施するBase IIシステムとが含まれる。支払処理ネットワークは、インターネットを含む、任意の好適な有線または無線ネットワークを使用することができる。
【0051】
中央サーバコンピュータ108は、取引要求メッセージを処理し、取引要求メッセージに対する適切な宛先(例えば、認証コンピュータ(複数可))を判定し得る。中央サーバコンピュータ108はまた、取引の清算および決済に対処し、ならびに/またはそれらを容易にし得る。
【0052】
承認事業体コンピュータ110は通常、消費者(例えば、ユーザ103)用の消費者アカウントを発行および維持する、ビジネス事業体(例えば、銀行)と関連付けられる。承認事業体コンピュータ110は、クレジットカードおよびデビットカードなどを含む、消費者アカウント用の支払デバイスを発行してもよい。
【0053】
承認事業体コンピュータ、または承認事業体に代わって役割を果たす第三者事業体が、承認要求メッセージを受信した後、承認事業体コンピュータ110、または発行者に代わって役割を果たす第三者事業体は、PANを取引に利用するべきと判定してもよい。例えば、承認事業体コンピュータ110は、難読化されたPANが、承認要求メッセージの中で利用されている、承認要求メッセージの小売業者タイプが、PANを含むことを示す、および/または承認要求メッセージの取引タイプが、PANを含むことを示すと判定し得る。一部の実施形態では、承認要求メッセージに含まれるPANは、既知のセカンダリアカウント識別子(SAN)のマッピングと照合されてもよく、識別された場合、承認要求メッセージは拒否され得る。一部の実施形態では、承認要求メッセージの中のPANが、既知のSANのマッピングに含まれていない(例えば、SANではない)場合、メッセージをさらに処理してもよい。PANが利用されていると判定されると、承認事業体コンピュータは、取引を許可または却下するように、承認要求メッセージを処理し得る。承認事業体コンピュータは、承認応答メッセージを中央サーバコンピュータ108に送り返して、現在の取引が承認されるか否か(または承認されないか)を示してもよい。中央サーバコンピュータ108はその後、承認応答メッセージを転送して転送コンピュータ106に戻す。次いで転送コンピュータ106は、応答メッセージをリソースプロバイダコンピュータ104に送り返す。
【0054】
リソースプロバイダコンピュータ104が、承認応答メッセージを受信した後、リソースプロバイダコンピュータ104のところにあるアクセスデバイス118によって、その後、承認応答メッセージをユーザ103に提供し得る。応答メッセージは、アクセスデバイス118によって表示されてもよく、またはレシート上に印刷されてもよい。
【0055】
一日の終わりに、通常の清算および決済プロセスを、システム100によって行うことができる。清算プロセスは、アクワイアラと発行者との間で金銭的詳細を交換して、ユーザのアカウントへの転記およびユーザの決済状況の調整を容易にするプロセスである。
【0056】
別の例示的実施形態では、ユーザ103は、ユーザデバイス102を利用して、オフライン取引を開始してもよい。例えば、ユーザ103は、特定の端末タイプを有する(例えば、交通システムへのアクセスを許可/制限する、交通機関の自動改札機および/または料金確認デバイスを示す)アクセスデバイス118のところで、ユーザデバイス102を提示してもよい。一部の実施形態では、アクセスデバイスが非接触リーダであってもよく、ユーザデバイス102が、非接触カードなどの非接触デバイスであってもよい。一部の実施形態では、ユーザデバイス102を提示すると、アクセスデバイス118は、ユーザデバイス102に認証データを要求し得る。アクセスデバイス118が特定の端末タイプであるため、ユーザデバイスは、CRM112のユーザデバイス102に保存されたSANなどの情報を提供し得る。加えて、ユーザデバイスは、アクセスデバイス118に提供されるデータ内に、PANの暗号化されたバージョンを提供し得る。
【0057】
承認事業体コンピュータ、または承認事業体に代わって役割を果たす第三者事業体が、承認要求メッセージを受信した後、承認事業体コンピュータ110、または発行者に代わって役割を果たす第三者事業体は、SANが承認要求メッセージに含まれることを判定するように構成され得る。例として、承認事業体コンピュータ110は、メッセージに含まれるアカウント番号フィールドのデータが、7つのゼロで終わっていないという判定、要求する小売業者が、特定の小売業者タイプ(例えば、交通機関の小売業者タイプ)と関連付けられるという判定、ならびに/または承認要求メッセージが、取引のタイプ(例えば、交通機関の取引)および/もしくは承認要求メッセージが生成された端末のタイプ(例えば、交通端末)を示すという判定に、少なくとも部分的に基づいて、SANが承認要求メッセージに含まれると判定してもよい。承認事業体コンピュータは、SANの使用を許可しない取引において、SANを含むいかなる承認要求メッセージも拒否するように構成され得る。SANが許可される取引(例えば、交通機関の取引、料金の取引など)についてのメッセージに、SANが含まれる場合、承認事業体コンピュータは、承認要求メッセージの処理を進めて、取引を承認または拒否することができる。承認事業体コンピュータは、承認応答メッセージを中央サーバコンピュータ108に送り返して、現在の取引が承認されるか否か(または承認されないか)を示してもよい。中央サーバコンピュータ108はその後、承認応答メッセージを転送して転送コンピュータ106に戻す。次いで転送コンピュータ106は、応答メッセージをリソースプロバイダコンピュータ104に送り返す。
【0058】
少なくとも一実施形態では、承認事業体は、ユーザデバイス102に対してパーソナライゼーションプロセスを実施してもよい。このパーソナライゼーションプロセスの間、マスター導出鍵(MDK:master derivation key)、PAN、およびSANは、ユーザデバイス102(例えば、CRM112内)に保存され得る。ユーザデバイス102は、マスター鍵から一つ以上の一意の導出鍵を導き出す機能を果たすように構成され得る。一部の実施形態では、ユーザデバイス102が、マスター鍵および少なくともPANの一部分を使用して、UDKを導出してもよい。例えば、UDKは、マスター鍵およびPANの左端8桁を使用して導出されてもよい。一部の実施形態では、PANの左端8桁は、銀行識別番号(BIN)と関連付けられてもよい。
【0059】
生成されると、UDKを任意の好適な時点に利用して、暗号化された識別子および/または難読化された識別子を生成してもよい。一部の実施形態では、UDKは、識別子全体(例えば、PAN)だけでなく、カウンタ、日付、時間、および/または取引額などの動的値をも暗号化し得る。例として、PANは、ユーザデバイス102上に保存された動的値(例えば、取引カウンタ)と連結され、UDKおよび暗号化アルゴリズムを使用して暗号化されてもよい。一部の実施形態では、暗号化された識別子の一部分(例えば、右端の7桁)は識別し、難読化された識別子を生成しするように使用され得る。一部の実施形態では、難読化された識別子は、PANの元の8桁(BINに対応する)、暗号化された識別子の一部分、およびチェックサム値(例えば、Luhnチェックサムに対応する)を含み得る。その上さらなる実施形態では、難読化された識別子は、PANの元の8桁(BINに対応する)、任意の好適な数のパディング値(例えば、7つのゼロ)、およびチェックサム値を含み得る。難読化された識別子および/または暗号化された識別子は、ユーザデバイス102に保存され得る。
【0060】
取引の初期化時(例えば、非交通機関での取引)、または別の好適な時点に、ユーザデバイス102は、難読化された値および暗号化された識別子を、データトラックの形態で提供するように構成され得る。データトラックは、トラック1またはトラック2のデータトラックとしてフォーマットできる。トラック1(「国際航空運送協会」)は、トラック2よりも多くの情報を保存し、カード所有者の氏名だけでなく、アカウント番号および他の任意データも含む。このトラックは、クレジットカードで予約を確保するときに、航空会社が使用することがある。トラック2(「米国銀行協会」(ABA))が現在最もよく使用されている。トラック2は、ATMおよびクレジットカードチェッカーによって読み取られてもよい。ABAがトラック2の仕様を設計しており、全世界の銀行が従わなければならない。カード保有者のアカウント、暗号化されたPIN、および他の任意データが含まれる。
【0061】
一部の実施形態では、難読化された値は、従来ユーザのアカウント番号(例えば、タグ57)を含む、トラック2のデータトラックのデータフィールドに提供されてもよい。一部の実施形態では、暗号化された識別子は、トラック2のデータトラックの異なる部分(例えば、タグ9F1F(任意データタグ)に、タグ9F7C(顧客専用データタグ)に、タグ9F10(発行者アプリケーションデータ)に、もしくはトラック2のデータの任意の好適な部分に、または上記のいかなる好適な組み合わせ)に提供されてもよい。
【0062】
他の実施形態では、取引(例えば、交通機関の取引)の初期化時、または別の好適な時点に、ユーザデバイス102は、SANおよび暗号化された識別子を、データトラックの形態で提供するように構成され得る。一部の実施形態では、SANは、従来ユーザのアカウント番号(例えば、タグ57)を含む、トラック2のデータトラックのデータフィールドに提供されてもよい。一部の実施形態では、暗号化された識別子は、トラック2のデータトラックの異なる部分(例えば、タグ9F1F(任意データタグ)に、タグ9F7C(顧客専用データタグ)に、タグ9F10(発行者アプリケーションデータ)に、もしくはトラック2のデータの任意の好適な部分に、または上記のいかなる好適な組み合わせ)に提供されてもよい。
【0063】
従来の取引処理によれば、アクセスデバイス118は、トラック2のデータトラックを受信し、データをリソースプロバイダコンピュータ104に提供してもよく、リソースプロバイダコンピュータ104は、その後、トラック2のデータの少なくとも一部分を、承認要求メッセージによって転送コンピュータ106に転送し得る。一部の実施形態では、アクセスデバイス118は、承認要求メッセージを生成し、トラック2のデータの少なくとも一部分を含み、承認要求メッセージを直接、転送コンピュータ106に転送し得る。
【0064】
受信時、または別の好適な時点に、転送コンピュータ106は、承認要求メッセージを中央サーバコンピュータ108に転送し得る。中央サーバコンピュータ108は、暗号化された値が承認要求メッセージの中に存在すると判定し得る。中央サーバコンピュータ108は、マスター導出鍵および難読化された識別子の一部分(承認メッセージにも含まれる)を利用して、保存されたUDKを読み出すか、ならびに/またはUDKを導出し得る。UDKを中央サーバコンピュータ108が利用して、暗号化された値を復号して、暗号化されていないPAN全体を取得し得る。一部の実施形態では、中央サーバコンピュータ108は、承認要求メッセージを修正して、暗号化されていないPANを含め、さらなる処理のために、修正された承認要求メッセージを承認事業体コンピュータ110へ送信し得る。
【0065】
他の実施形態では、中央サーバコンピュータ108および/または承認事業体コンピュータ110は、難読化された識別子の少なくとも一部分(例えば、BINに対応する最初の8桁)を利用して、変更されていない承認要求メッセージを承認事業体コンピュータ110に転送し得る。承認事業体コンピュータ110は、マスター導出鍵、および難読化された識別子の一部分またはSAN(承認メッセージにも含まれる)を利用して、保存されたUDKを読み出すか、ならびに/またはUDKを導出し得る。UDKを承認事業体コンピュータ110が利用して、暗号化された識別子を復号して、暗号化されていないPAN全体を取得し得る。中央サーバコンピュータ108および/または承認事業体は、SANを利用して、関連付けられたPANを読み出すために、既知のPAN/SANの関連付けを示すマッピングを調べてもよい。関連付けられたPANを、暗号化されていないPANと比較して、承認要求メッセージを検証することができる。
【0066】
承認事業体コンピュータ110は、承認要求メッセージを処理し、承認応答メッセージを送信して中央サーバコンピュータ108に戻してもよい。一部の実施形態では、承認応答メッセージは、難読化された識別子および暗号化された値を含み、暗号化されていない識別子を除外してもよい。
【0067】
中央サーバコンピュータ108は、承認応答メッセージを転送して、転送コンピュータ106を介してリソースプロバイダコンピュータ104に戻し得る。リソースプロバイダコンピュータ104が、承認応答メッセージを受信した後、リソースプロバイダコンピュータ104のところにあるアクセスデバイス118によって、その後、承認応答メッセージをユーザ103に提供し得る。応答メッセージは、アクセスデバイス118によって表示されてもよく、またはレシート上に印刷されてもよい。
【0068】
一日の終わりに、通常の清算および決済プロセスを、システム100によって行うことができる。
【0069】
本明細書に記載される技術を利用することによって、機密データ(例えば、PAN)を伝達するためのより安全な方法が可能になる。静的識別子が必要な取引(例えば、ブロックリストに基づいてアクセスを確認または拒否するために)については、SANを利用して取引を実施し得る。SANを利用し、SANが特定のタイプ(複数可)の取引(例えば、交通機関の取引、料金の取引など)でのみ利用され得ることを保証することによって、SANは不正行為者から保護される。たとえ不正行為者が盗聴して、SANにアクセスすることができたとしても、システムによって、SANが特定のタイプの取引にのみ利用され、他の取引には利用できないことが保証されるであろう。他の取引(例えば、非交通機関での取引)に対して、PANは暗号化され、従来とは異なるデータフィールドに提供され、通常PANを含むであろう、従来のデータフィールドには代わりに、PANが判定される可能性の低い、難読化された値が含まれる。難読化された値には、依然として元のBINが含まれ、承認要求/応答メッセージに対する従来のルーティング技術は、変わらないままであることが保証され得る。本明細書に記載される技術によって、承認要求/応答メッセージからPANを識別することが、不可能でないにしても困難になる。加えて、一部の実施形態では、PANは、常に変化している動的値を使用して暗号化される。したがって、暗号化された値および難読化された値は、承認要求ごとに変更することができ、特定のユーザに対する取引を経時的に追跡することが、不可能でないにしても困難になる。それゆえ、本明細書で論じる技術を利用することで、機密データを送信するためのプライバシーの保護およびセキュリティが向上する。
【0070】
図2は、一部の実施形態による、データを生成しユーザデバイス(例えば、図1のユーザデバイス102)に保存する方法200を示す。方法200は、承認事業体コンピュータ(例えば、承認事業体コンピュータ110)がマスター導出鍵を取得し得る、202から始まってもよい。一部の実施形態では、マスター導出鍵(MDK)を利用して、一つ以上の一意の導出鍵を導き出してもよい。承認事業体コンピュータ110は、一つのユーザデバイスに対するMDKが、そのユーザデバイスに対して一意であることを保証し得る。したがって、承認事業体コンピュータ110は、様々なユーザデバイス(例えば、ユーザデバイス102)に対応し得る、多くのマスター導出鍵を管理してもよい。
【0071】
204で、承認事業体コンピュータ110は、ユーザデバイスがパーソナライズされるユーザに対応する、個人アカウント番号(PAN)を取得し得る。少なくとも一実施形態では、PANは、ユーザに代わって承認事業体によって管理される、ユーザの金融口座と関連付けられ得る。
【0072】
206で、承認事業体コンピュータ110は、セカンダリアカウント番号(SAN)を取得および/または生成し得る。全体を通して論じるように、SANが一つ以上の特定タイプの取引でのみ利用され得るように、SANは、承認事業体のコンピュータ110によって制限されてもよい。例として、交通システムまたは料金の確認システムなどで、ユーザを迅速に(例えば、リアルタイムまたはほぼリアルタイムで)認証しなければならない場合があり得る。システムの状況を考えると、ほぼリアルタイムでリソース(例えば、交通リソース)へのアクセスを可能にするほど十分迅速に、ユーザのオンライン認証を実施することが可能ではない場合がある。したがって、一部の認証システムでは、アクセスデバイスでオフライン認証を実施し、その後、関係する取引を行うための承認要求メッセージでフォローアップする。このSANを生成して、こうしたオフライン認証シナリオで利用してもよい。
【0073】
208で、承認事業体コンピュータ110は、PANとSANとの関係を示す、アカウント番号マッピングを維持してもよい。承認事業体コンピュータ110は、図5に関してより詳細に論じるように、検証の目的でマッピングを利用するように構成されてもよい
【0074】
210で、承認事業体コンピュータ110は、ユーザデバイス102にデータを送信し得る。例として、承認事業体コンピュータ110は、MDK、PAN、およびSANをユーザデバイス102に送信し得る。一部の実施形態では、承認事業体コンピュータ110が、データを中間デバイスに送信してもよく、その後、中間デバイスがデータをユーザデバイス102に転送し得る。
【0075】
212で、データはCRM112内のユーザデバイス102に保存され得る。214で、ユーザデバイス102は、MDKを使用して、一つ以上の一意の導出鍵を生成してもよい。例として、一意の導出鍵(UDK:unique derivation key)は、図3に関係してより詳細に記載されるプロセスにより生成され得る。一つ以上のUDKが生成されてもよく、各UDKは特定の目的のために利用されてもよいことは理解されるべきである。例えば、UDKはMAC用に、別のUDKは暗号化用に、また別のUDKは暗号文生成用に生成されてもよく、さらに別のUDKは図3のプロセスによって生成され得る。ユーザデバイス102が、好適な数のUDKを生成してもよく、またはこうしたUDKが代わりに、202もしくは任意の好適な時点に、承認事業体コンピュータ110によって生成されてもよいことは理解されるべきである。
【0076】
216で、ユーザデバイス102は、承認事業体コンピュータ110によって有効化されてもよい。有効化されると、ユーザデバイス102は、アクセスデバイスで、または様々な取引を実施するためにオンラインで利用され得る。
【0077】
図3は、一部の実施形態による、ユーザデバイス(例えば、スマートカード)上に常駐するデータから、一意に導出された鍵を生成するための方法を示す。方法は、ユーザデバイス102の一つ以上のプロセッサを利用して、図1のユーザデバイス102によって実施されてもよい。
【0078】
少なくとも一実施形態では、マスター導出鍵(MDK)302および識別子304は、パーソナライゼーションプロセス(例えば、図2の方法200)の実施中、ユーザデバイス102に保存されている。一部の実施形態では、識別子304は、個人アカウント番号の例であってもよい。UDK306は、ユーザデバイス102上に存在するこうしたデータから導出されてもよい。
【0079】
例として、ユーザデバイス102は、識別子308の一部分を識別するように構成されてもよい。一部の実施形態では、その識別子308の一部分は、識別子304全体よりも少ない部分を含み得る。例えば、その識別子308の一部分は、識別子304の左端8桁を含み得る。一部の実施形態では、識別子304の左端8桁は、支払処理ネットワーク(例えば、システム100)内のルーティングのために使用され得る、銀行識別番号(BIN)に対応してもよい。
【0080】
一部の実施形態では、その識別子308の一部分は、所定の固定長の文字列を作成するように、いくつかのパディングビット(例えば、パディング310)と連結されてもよい。一部の例では、連結された値は、パディングが64ビットを含み、識別子308の一部分が、別の64ビット(各々8ビットを含む8桁)を含む、長さ128ビットであってもよいが、連結された値は、この長さであることに限定されない。連結された値は、MDK302と共に、データ暗号化アルゴリズム312への入力として提供されてもよい。
【0081】
データ暗号化アルゴリズム312は、任意の好適な暗号化方法論を含み得る。例えば、データ暗号化アルゴリズム312には、トリプルDES暗号化アルゴリズムを利用してもよい。一部の実施形態では、データ暗号化アルゴリズム312によって行われる暗号化から生じる値が、UDK306である。
【0082】
図4は、一部の実施形態による、オフライン認証を実施するための方法400を示す。方法は、発見プロセスがアクセスデバイス118によって実行され得る、402から始まってもよい。例えば、図1のリーダ120は、リーダのRFフィールドに入ってきた可能性のある、非接触カードの存在に対してポーリングしてもよい。
【0083】
404で、アクセスデバイス118は、ユーザデバイス102でアプリケーション選択プロセスを開始し得る。アプリケーション選択プロセスは、ユーザデバイス102の有効化後、直ちに実施されてもよく、ユーザデバイス102およびアクセスデバイス118(またはリーダ120)の両方がサポートするアプリケーションのうちの、どのアプリケーションを使用して、取引を行うかを判定するプロセスである。例として、アクセスデバイス118(例えば、アクセスデバイス118のリーダ120)は、相互にサポートするアプリケーションの候補リストを作成し得る。候補リストからの単一のアプリケーションを識別し選択して、取引を処理し得る。
【0084】
406で、アプリケーション処理を開始してもよい。例えば、アクセスデバイス118(またはリーダ120)は、ユーザデバイス102に、取引処理が始まると信号を送ってもよい。一部の実施形態では、取引処理の開始では、アクセスデバイス118(リーダ120)からユーザデバイス102へ、GET PROCESSING OPTIONS(処理オプション取得)コマンドを送ることによって、信号を送ることができる。このコマンドを発行するとき、アクセスデバイス118は、任意の好適なデータ要素を提供し得る。一部の実施形態では、ユーザデバイス102およびアクセスデバイス118(リーダ120)によって、相互にサポートされる非接触経路(複数可)が判定され、非接触経路を選んで取引を処理してもよい。後続の取引処理は、選ばれた非接触経路に従って実施されてもよい。
【0085】
408で、ユーザデバイス102は、アプリケーションデータを、アクセスデバイス118(リーダ120)に戻して提供してもよい。一部の実施形態では、ユーザデバイス102が最初に、GET PROCESSING OPTIONSを受信してもよい。コマンドに応じて、ユーザデバイス102は、任意の好適なアプリケーションデータを生成し得る。例として、ユーザデバイス102に保存されたカウンタが、修正されてもよい(例えば、値の増加、減少など)。ユーザデバイス102は、保存されたPANと共にカウンタを利用して、ユーザデバイス102にも保存され得る、暗号化されたPANを生成し得る。GET PROCESSING OPTIONSコマンドによって、アクセスデバイス118が特定の端末タイプ(例えば、非交通端末タイプ、またはユーザデバイスに保存される端末タイプの第一のセットの端末タイプなど)であると示される場合に、ユーザデバイス102は、保存されたPANの一部分および暗号化された識別子の一部分から、難読化されたPANを生成し得る。難読化されたPANおよび暗号化された識別子は、この使用事例ではアプリケーションデータとして提供され得る。しかしながら、GET PROCESSING OPTIONSコマンドによって、アクセスデバイス118が別の特定の端末タイプ(例えば、交通端末タイプ、またはユーザデバイスに保存される端末タイプの第二のセットの端末タイプなど)であると示される場合に、ユーザデバイス102は、保存されたSANおよび暗号化された識別子を、アプリケーションデータとして提供し得る。
【0086】
410で、アクセスデバイス118(リーダ120)が、取引を処理するために必要なアプリケーションデータを読み取ると、アプリケーションデータの読み取りは完了とみなされ得る。読み取り時間中、アクセスデバイス118は、取引に必須の全データ要素が、カードによって返ってきたかを判定し得る。必須のデータ要素すべてが返ってきたわけではない場合、または冗長なデータが返ってきた(例えば、データ要素の発生が二回以上返された)場合、アクセスデバイス118(リーダ120)は取引を終了してもよい。
【0087】
412で、アクセスデバイス118(リーダ120)は制限を処理してもよい。例として、アクセスデバイス118(リーダ120)は、アプリケーションの有効期限、アプリケーションの使用法、および/またはSANが端末例外ファイル(TEF:Terminal Exception File)上にあるかを確認し得る。TEFは、リソースへのアクセスを与えるべきではないSANが保存されている、ブラックリストと見なされ得る。SANが端末例外ファイルに登場する場合、アクセスデバイス118(リーダ120)は、ユーザデバイス102にアクセス(例えば、アクセスデバイス118によって管理される自動改札機への)を与えないように構成されてもよく、さらなる処理は行われなくてもよい。
【0088】
しかしながら、SANがTEFに含まれない場合、方法400は、オフラインデータ認証を実行し得る、414に進んでもよい。オフラインデータ認証は、オフライン取引をサポートするアクセスデバイス(リーダ)に対して実施されてもよく、オフライン取引が要求されるユーザデバイスに対して実施されてもよい。オフラインデータ認証中、アクセスデバイス118(リーダ120)は、ユーザデバイス102によって返される動的署名を検証してもよく、ユーザデバイス102からのデータを認証し得る。
【0089】
一部の実施形態では、アクセスデバイス118(リーダ120)は、オンライン取引をサポートしてもよい。これらの実施形態では、アクセスデバイス118(リーダ120)は、416で承認要求メッセージを、承認事業体コンピュータ110に(例えば、図1の転送コンピュータ106および/または中央サーバコンピュータ108を介して)送ってもよい。承認要求メッセージは、SANおよびユーザデバイス102に保存される暗号化された識別子を含み得る。
【0090】
418で承認要求メッセージを受信すると、または任意の好適な時点に、承認事業体コンピュータ110は、所定のホストベースのリスク管理パラメータを使用して、取引を検討し、承認または拒否する。一部の実施形態では、承認事業体コンピュータ110は、取引がSANを含むことを判定するように構成されてもよい。一部の実施形態では、承認要求メッセージのアカウント識別子フィールドの値が読み出され、対応するPANにマッピングされる、既知の全SANを含むマッピングと比較されてもよい。アカウント識別子フィールドの値が、既知のSANと等しい場合、取引はSANを利用していると判定され得る。一部の実施形態では、承認事業体コンピュータ110は、取引を開始するアクセスデバイス(例えば、アクセスデバイス118)が特定のタイプであるか、もしくはアクセスデバイスと関連付けられた小売業者が、特定の小売業者タイプであるか、または承認要求メッセージの取引タイプが、許容可能な取引タイプを示す取引においてのみ、SANを利用することが可能になるように構成されてもよい。非限定的な例として、承認事業体コンピュータ110は、非交通端末タイプと関連付けられるアクセスデバイス(例えば、非交通機関の小売業者によって操作されるアクセスデバイス)を伴う取引で、SANを利用するオンライン処理を拒否し、一方で、交通端末タイプと関連付けられるアクセスデバイス(例えば、交通機関の小売業者によって操作されるアクセスデバイス120)を伴う取引のために、SANを利用するオンライン処理を許可するように構成されてもよい。
【0091】
一部の実施形態では、承認要求メッセージに含まれるSANは、暗号化された識別子に対応するPANと関連付けられてもよい。承認事業体コンピュータ110は、銀行識別番号(BIN)に対応するSANの左端8桁を読み出すように構成され得る。承認事業体コンピュータ110は、BINと、承認事業体コンピュータ110によって維持されるマッピングに保存されるような、SANと関連付けられたPANとを利用して、UDKを導出し得る。導出されたUDKを使用して、承認事業体コンピュータ110は、承認メッセージの暗号化された識別子を復号して、復号されたPANを判定し得る。復号されたPANは、マッピングに保存され、メッセージのSANと関連付けられたPANと比較されてもよい。復号されたPANが保存されたPANと一致する場合、メッセージは有効とみなされ、そうでない場合には、無効とみなされ得る。承認事業体コンピュータ110はさらに、従来のオンライン不正および信用調査を実施し、カード生成暗号文を利用して、オンラインカード認証を実施するなどを行い得る。
【0092】
図5は、一部の実施形態による、機密データを安全に伝達するための方法500のフローチャートを示す。方法500は、コンピューティングデバイス(例えば、図1のユーザデバイス102、スマートカード)によって実施されてもよい。コンピューティングデバイスは、一つ以上のプロセッサと、コンピュータ実行可能命令を保存する一つ以上のメモリとを備えてもよく、一つ以上のプロセッサによりコンピュータ実行可能命令を実行することによって、コンピューティングデバイスに方法500を実施させる。図5に示し以下に記載されるステップは、図1の取引処理の説明および対応する説明と併せて使用することができる。それらの説明は、参照により本明細書に組み込まれる。コンピューティングデバイスは、一つ以上のUDK、第一の識別子(例えば、セカンダリアカウント番号(SAN))、第二の識別子(例えば、プライマリアカウント番号(PAN))、動的値、またはコンピューティングデバイスのメモリ内にある任意の好適なデータを保存し得る。
【0093】
暗号化された識別子は、任意の好適なタイプで(例えば、図4に関係して上で論じたように、アクセスデバイスからGET PROCESSING OPTIONSコマンドを受信した後)、生成されてもよい(例えば、コンピューティングデバイスによって)。コンピューティングデバイスは、一意の導出鍵(例えば、UDK206)を使用して、第二の識別子(例えば、PAN)および動的値(例えば、カウンタ、日付、時間など)を暗号化することによって、暗号化された識別子を生成し得る。一部の実施形態では、第二の識別子および動的値は、暗号化される前に、共に、および/または追加のパディング値で連結されてもよい。一部の実施形態では、暗号化された識別子は、コンピューティングデバイスに保存されてもよい(例えば、タグ9F7C(顧客専用データタグ)および/もしくはタグ9F10(発行者アプリケーションデータ)など、トラック1ならびに/もしくはトラック2のデータの一部として、タグ9F1F(任意データタグ)の中に、もしくはトラック1および/もしくはトラック2のデータのいずれかの部分の中に、または上記のいかなる好適な組み合わせ。加えて、または代替で、暗号化された識別子は、上記のタグのいずれか、またはトラック1および/もしくはトラック2のデータの別の好適な部分で潜在的に利用可能な、将来使用するため確保されているデータフィールドの一部として提供されてもよい。
【0094】
方法500は、要求メッセージが、コンピューティングデバイス(例えば、スマートカード)によって、アクセスデバイス(例えば、自動改札機)から受信され得る、ブロック502から始まってもよい。一部の実施形態では、要求メッセージは、上記のような図4のGET PROCESSING OPTIONSコマンドに対応し得る。アクセスデバイスは、ユーザデバイスにデータを要求するように構成された、任意の好適なデバイスであってもよい。
【0095】
504で、コンピューティングデバイスは、要求メッセージに少なくとも部分的に基づいて、要求するアクセスデバイスのタイプ指標を判定し得る。例として、要求メッセージは、要求が特定のタイプの端末/アクセスデバイスによって開始されたことを示す、タイプ指標を含み得る。非限定的な例として、要求メッセージは、要求するデバイスが、地下鉄システムなどの交通システム内にある自動改札機であることを示していてもよい。コンピューティングデバイスは、タイプ指標が第一のタイプセット(例えば、交通タイプを含む第一のタイプセット)に属するか否かを判定してもよい。
【0096】
506で、タイプ指標が第一のタイプセットに含まれると判定された場合、または要求メッセージが特定のタイプの端末/アクセスデバイスによって開始されたと判定される場合、コンピューティングデバイスは、少なくとも第一の識別子(例えば、SAN)、およびPANから生成/導出された暗号化された識別子を含む、第二のメッセージを(例えば、アクセスデバイスへ)送信し得る。一部の実施形態によれば、メッセージは、アクセスデバイスに提供されてもよく、アクセスデバイスによって、コンピューティングデバイスのユーザが、リソースへのアクセスを許可または拒否される。非限定的な例として、交通機関の駅にある自動改札機などのアクセスデバイスでは、第一の識別子(例えば、SAN)に基づいて、ユーザへのアクセスが許可または拒否され得る。図4に関係して上に記載されるように、一部の実施形態では、アクセスデバイス(または関連付けられたリソースプロバイダコンピュータ)は続いて、承認要求メッセージを生成し得る。承認要求メッセージは、とりわけ、第一の識別子(SAN)を含む第一のデータフィールドと、暗号化された識別子を含む第二のデータフィールドとを含み得る。一部の実施形態では、承認要求メッセージは、さらなる承認処理のために、中央サーバコンピュータ(例えば、図1の中央サーバコンピュータ108)に送信される。
【0097】
508で、タイプ指標が、第一のタイプセットに含まれないと判定された場合、または特定タイプの端末/アクセスデバイスではないと判定された場合、難読化された識別子が生成され得る(例えば、ユーザデバイス102によって)。一部の実施形態では、難読化された識別子は、第二の識別子(PAN)の最初の8桁、7つのゼロ、およびLuhnチェックサム値を含み得る。他の実施形態では、難読化された識別子は、第二の識別子(例えば、PAN)のその一部分および暗号化された識別子の一部分に、少なくとも部分的に基づいて生成されてもよい。例として、難読化された識別子は、識別子の最初の8桁および暗号化された識別子の最後の7桁(または任意の好適な数のゼロ)を含むように生成されてもよい。これは単に一例であり、識別子のより少ないまたは多い桁、および暗号化された識別子のより少ないまたは多い桁が利用され得る。同様に、難読化されたものは、16桁または任意の好適な数の桁を含み得る。一部の実施形態では、Luhnチェックサム値は、難読化された識別子から計算され、難読化された識別子の一部として含まれてもよい(例えば、進行中の例では最後の桁、桁16)。
【0098】
510で、第二のメッセージ(例えば、トラック2のメッセージ)が提供されてもよい(例えば、ユーザデバイス102によって)。一部の実施形態では、メッセージは、少なくとも難読化された識別子および暗号化された識別子を含んでもよい。一部の実施形態によれば、メッセージは、アクセスデバイス(例えば、アクセスデバイス118)に提供されてもよく、アクセスデバイスによって、承認要求メッセージを生成させる(例えば、図1のアクセスデバイス118および/またはリソースプロバイダコンピュータ104によって)。承認要求メッセージは、とりわけ、難読化された識別子を含む第一のデータフィールドと、暗号化された識別子を含む第二のデータフィールドとを含み得る。一部の実施形態では、承認要求メッセージは、さらなる承認処理のために、中央サーバコンピュータ(例えば、図1の中央サーバコンピュータ108)に送信される。
【0099】
図6は、一部の実施形態で使用する、例示的な記録形式600を示す。例えば、記録形式600は、SANおよび暗号化された識別子を含む、トラック2のデータ(例えば、認証データ)を含み得る。記録形式600は、図5の506に関係して記載される、第二のメッセージの例であってもよい。非限定的な一例では、PAN601は、ユーザと関連付けられ、ユーザのデバイス(例えば、スマートカード)上に保存されてもよい。一部の実施形態では、SAN602は、ユーザと関連付けられ、ユーザのデバイス上に保存されてもよい。図6に説明するように、PAN601およびSAN602は各々16桁を含んでもよい。一部の実施形態では、PAN601は、トラック2のデータによって定義されるように、トラック2のデータのタグ57に保存される。一部の実施形態では、SAN602は、トラック2のデータによって定義されるように、トラック2のデータのタグ5Aに保存される。
【0100】
記録形式600の最初の16桁(例えば、識別子データフィールド603)(例えば、桁1~16)は従来、SAN602に確保され得る。次に、区切り文字データフィールド604が、アカウント識別子と有効期限データフィールド606との間に緩衝を提供する。サービスコードデータフィールド608が、有効期限データフィールド606に続いてもよい。個人識別番号検証指標(PVKI)データフィールド610およびPIN検証情報データフィールド614が後に続く。次に、dCVVデータフィールド614、取引カウンタデータフィールド616、および非接触指標データフィールド618が含まれる。最後に、任意データフィールド620が後に続く。任意データフィールドは、暗号化値データフィールド621および暗号文バージョン番号データフィールド623を含み得る。暗号化値データフィールド621および暗号文バージョン番号データフィールド623は、必ずしも図6に示される数ではなく、任意の好適な桁数を含んでもよい。
【0101】
一部の実施形態によれば、PAN601を最初に利用して、暗号化された値(例えば、暗号化された識別子)を生成してもよい。例として、図1のユーザデバイス102は、図3のPAN601およびUDK306を、記憶装置から読み出すように構成されてもよい。一部の実施形態では、取引カウンタ(または他の動的値)もまた読み出されてもよい。PANおよび取引カウンタ(または他の動的値)は、暗号化アルゴリズムへの入力として、UDK306と共に利用されて、暗号化された値を生成し得る。一部の実施形態では、PANおよび取引カウンタ(または他の動的値)は、入力の前に連結されてもよい。結果として得られた暗号化された値は、記録形式600で保存され得る。例として、結果として得られた暗号化された値は、任意データフィールド620の暗号化値データフィールド621内に示されるように保存されてもよい。一部の実施形態では、任意データフィールド620は、トラック2標準によって定義される、特定のタグに対応する(例えば、タグ9F1F(任意データタグ)、タグ9F7C(顧客専用データタグ)、タグ9F10(発行者アプリケーションデータ)、トラック2のデータの任意の好適な部分、または上記の任意の好適な組み合わせで)。
【0102】
一部の実施形態では、暗号文バージョン番号データフィールド623は、任意データフィールド620が、暗号化値データフィールド621内に暗号化された値を含むことを示す、番号を保存してもよい。
【0103】
一部の実施形態によれば、ユーザデバイス102は、識別子データフィールド603にSAN602を提供するように構成され得る。識別子データフィールド603の桁16は、識別子データフィールド603が、変更されていないことを検証するために利用され得る(例えば、受信時に)、チェックサム値(例えば、Luhnチェックサム/値)を含み得る。一部の実施形態では、ユーザデバイス102によって、トラック2のデータの要求者が、特定の端末タイプ(例えば、交通端末タイプ、オフライン認証に関連付けられた端末タイプなど)と関連付けられていると判定されたとき、SAN602が、識別子データフィールド603内に提供されてもよい。
【0104】
取引が開始されると、識別子データフィールド603内に含まれるSAN602、および任意データフィールド620内の(例えば、暗号化値データフィールド621の)暗号化された値が、提供されてもよい(例えば、上記のようにアクセスデバイスに)。一部の実施形態では、取引カウンタの値を増加(または減少)することができ、および/または新しい動的値を、取引カウンタデータフィールド716の中に生成し保存してもよい。別の取引がユーザデバイス102によって開始される場合、本明細書で論じるプロセスは、新しい取引カウンタ/動的値およびPAN701を利用して繰り返されて、その後、後続の取引で提供され得る、新しい暗号化された値および新しい難読化された識別子を生成してもよい。
【0105】
図7は、一部の実施形態で使用する、別の例示的な記録形式700を示す。例えば、記録形式700は、難読化された識別子および暗号化された識別子を含む、トラック2のデータ(例えば、支払データ)を含み得る。記録形式600は、図5の510に関係して記載される、第二のメッセージの例であってもよい。非限定的な一例では、PAN701は、ユーザと関連付けられ、ユーザのデバイス(例えば、スマートカード)上に保存されてもよい。一部の実施形態では、SAN702もまた、ユーザと関連付けられ、ユーザのデバイス上に保存されてもよい。図7に説明するように、PAN701およびSAN702は各々16桁を含んでもよい。一部の実施形態では、PAN701は、トラック2のデータによって定義されるように、トラック2のデータのタグ57に保存される。一部の実施形態では、SAN702は、トラック2のデータによって定義されるように、トラック2のデータのタグ5Aに保存されてもよい。
【0106】
記録形式700の最初の16桁(例えば、識別子データフィールド703)(例えば、桁1~16)は、アカウント識別子の難読化されたバージョン(例えば、難読化されたPAN703、PAN701の難読化されたバージョン)に確保され得る。次に、区切り文字データフィールド704が、アカウント識別子と有効期限データフィールド706との間に緩衝を提供する。サービスコードデータフィールド708が、有効期限データフィールド706に続いてもよい。個人識別番号検証指標(PVKI)データフィールド710およびPIN検証情報データフィールド712が後に続く。次に、dCVVデータフィールド714、取引カウンタデータフィールド716、および非接触指標データフィールド718が含まれ得る。最後に、任意データフィールド720が後に続き得る。任意データフィールドは、暗号化値データフィールド721および暗号文バージョン番号データフィールド723を含み得る。暗号化値データフィールド721および暗号文バージョン番号データフィールド723は、必ずしも図7に示される数ではなく、任意の好適な桁数を含んでもよい。
【0107】
一部の実施形態によれば、PAN701を最初に利用して、暗号化された値(例えば、暗号化された識別子)を生成してもよい。例として、図1のユーザデバイス102は、図3のPAN701およびUDK306を、記憶装置から読み出すように構成されてもよい。一部の実施形態では、取引カウンタ(または他の動的値)もまた読み出されてもよい。PAN701および取引カウンタ(または他の動的値)は、暗号化アルゴリズムへの入力として、UDK306と共に利用されて、暗号化された値を生成し得る。一部の実施形態では、PAN701および取引カウンタ(または他の動的値)は、入力の前に連結されてもよい。結果として得られた暗号化された値は、記録形式700で保存され得る。例として、結果として得られた暗号化された値は、任意データフィールド720の暗号化値データフィールド721内に示されるように保存されてもよい。一部の実施形態では、任意データフィールド720は、トラック2標準によって定義される、特定のタグに対応する(例えば、タグ9F1F(任意データタグ)、タグ9F7C(顧客専用データタグ)、タグ9F10(発行者アプリケーションデータ)、トラック2のデータの任意の好適な部分、または上記の任意の好適な組み合わせで)。
【0108】
一部の実施形態では、暗号文バージョン番号データフィールド723は、任意データフィールド720が、暗号化値データフィールド721内に暗号化された値を含むことを示す、番号を保存してもよい。
【0109】
一部の実施形態によれば、ユーザデバイス102は、難読化されたPAN703を生成するように構成されてもよい。例として、ユーザデバイス102は、PAN701の最初の8桁を取得し、識別子データフィールド703の桁1~8にこの情報を保存してもよい。一部の実施形態では、識別子データフィールド703の桁9~15は、ゼロなどのパディング値を含み得る。あるいは、ユーザデバイス102は、暗号化された値の何らかの部分を取得し、記録形式700内にその部分を保存するように構成されてもよい。例えば、暗号化された値の最後の7桁を取得し、識別子データフィールド703の桁9~15として保存してもよい。識別子データフィールド703の桁16は、識別子データフィールド703が、変更されていないことを検証するために利用され得る(例えば、受信時に)、チェックサム値(例えば、Luhnチェックサム/値)を含み得る。
【0110】
取引が開始されると、難読化されたPAN703、および任意データフィールド720内の(例えば、暗号化値データフィールド721の)暗号化された値が、提供されてもよい(例えば、上記のようにアクセスデバイスに)。取引カウンタの値を増加(または減少)することができ、および/または新しい動的値を、取引カウンタデータフィールド716の中に生成し保存してもよい。別の取引がユーザデバイス102によって開始される場合、本明細書で論じるプロセスは、新しい取引カウンタ/動的値およびPAN701を利用して繰り返されて、その後、後続の取引で提供され得る、新しい暗号化された値および新しい難読化された識別子を生成してもよい。
【0111】
図8は、一部の実施形態による、データ検証を実施するための方法のフローチャートを示す。方法800は、コンピューティングデバイス(例えば、図1の中央サーバコンピュータ108および/または承認事業体コンピュータ110)によって実施され得る。コンピューティングデバイスは、一つ以上のプロセッサと、コンピュータ実行可能命令を保存する一つ以上のメモリとを備えてもよく、一つ以上のプロセッサによりコンピュータ実行可能命令を実行することによって、コンピューティングデバイスに方法800を実施させる。
【0112】
方法800は、メッセージ(例えば、承認要求メッセージ)を受信し得る、ブロック802から始まってもよい。一部の実施形態では、メッセージは、第一の識別子(例えば、SAN)および暗号化された識別子を含んでもよい。図8に示し以下に記載されるステップは、図1の取引処理の説明および対応する説明と併せて使用することができる。それらの説明は、参照により本明細書に組み込まれる。
【0113】
ブロック804で、コンピューティングデバイスは、承認要求メッセージを開始した、要求するデバイスと関連付けられたタイプを検証し得る。一部の実施形態では、コンピューティングデバイスは、承認要求メッセージに含まれる値(例えば、小売業者の名前、住所、タイプ指標、端末タイプなど)を、コンピューティングデバイスに保存されるか、またはコンピューティングデバイスがアクセス可能なデータ(例えば、SANの利用が許される値)と比較してもよい。承認要求メッセージに含まれる値が、保存されたデータに含まれる場合、コンピューティングデバイスによって、承認要求メッセージをさらに処理することが可能になり得る。値が承認要求メッセージに含まれていない場合、コンピューティングデバイスは、承認要求メッセージを拒否し、それを示す承認応答メッセージを要求者に送信し得る。
【0114】
806で、第一の識別子(例えば、SAN)を利用して、予想される識別子(例えば、プライマリPAN)を取得してもよい。一部の実施形態では、コンピューティングデバイスは、PANとSANとの既知の関連を示すマッピングを調べてもよい。
【0115】
808で、コンピューティングデバイスは、暗号化された識別子および一意の導出鍵を利用して、復号された識別子を生成し得る。一部の実施形態では、コンピューティングデバイスが、第一の識別子(例えば、SAN)の一部分から、一意の導出鍵(UDK)を導き出してもよい。一部の実施形態では、UDKは、事前に導出され、記憶装置から読み出されてもよい。例として、コンピューティングデバイスは、第一の識別子の左端8桁を読み出し、それらの数字を所定の暗号化アルゴリズムへの入力として使用して、UDKを生成し得る。左端の8桁は、銀行識別番号(BIN)に対応してもよい。UDKは、生成されると、暗号化された識別子を復号するために利用され得る。
【0116】
810で、コンピューティングデバイスは、復号された識別子が予想される識別子510と一致することを、検証するように構成され得る。すなわち、復号された識別子は、コンピューティングデバイスによって維持されるマッピング内に定義されるような、第一の識別子(例えば、SAN)と関連付けられたプライマリPANに対応する。
【0117】
812で、メッセージは、復号された識別子を利用して、コンピューティングデバイスによって処理されてもよい。例として、コンピューティングデバイスは、中央サーバコンピュータ(例えば、図1の中央サーバコンピュータ108)であってもよい。このシナリオでは、メッセージ(例えば、承認要求メッセージ)を処理することは、復号された識別子を含むようにメッセージを修正することと、さらなる処理のために承認事業体コンピュータ(例えば、承認事業体コンピュータ110)にメッセージを送信することとを含み得る。一部の実施形態では、コンピューティングデバイスは、承認事業体コンピュータ110であってもよい。このシナリオでは、メッセージを処理することは、復号された識別子を含むメッセージデータによる、取引の承認を含み得る。処理は、取引が承認または拒否されたことを示す、承認応答メッセージの生成をさらに含んでもよい。承認応答メッセージは、暗号化された識別子を含み、例えば、図1に関係する上記のプロセスによって、中央サーバコンピュータ108に送信されてもよい。
【0118】
図9は、一部の実施形態による、データ検証を実施する別の方法のフローチャートを示す。方法900は、コンピューティングデバイス(例えば、図1の中央サーバコンピュータ108および/または承認事業体コンピュータ110)によって実施され得る。コンピューティングデバイスは、一つ以上のプロセッサと、コンピュータ実行可能命令を保存する一つ以上のメモリとを備えてもよく、一つ以上のプロセッサによりコンピュータ実行可能命令を実行することによって、コンピューティングデバイスに方法900を実施させる。
【0119】
方法900は、メッセージ(例えば、承認要求メッセージ)を受信し得る、ブロック902から始まってもよい。一部の実施形態では、メッセージは、難読化された識別子および暗号化された識別子を含んでもよい。図9に示し以下に記載されるステップは、図1の取引処理の説明および対応する説明と併せて使用することができる。それらの説明は、参照により本明細書に組み込まれる。
【0120】
ブロック904で、コンピューティングデバイスは、メッセージが識別された暗号化されたものを含むことを識別し得る。一部の実施形態では、メッセージが暗号化された識別子を含むことを識別することは、特定のデータフィールド(例えば、図3の任意データフィールド320)を、ゼロでない値について確認することを含み得る。データフィールドが、ゼロでない値を含む場合、コンピューティングデバイスによって、暗号化された値がメッセージの中に存在すると結論を出し得る。一部の実施形態では、メッセージが暗号化された識別子を含むことを識別することは、特定のデータフィールド(例えば、図3の暗号文バージョン番号データフィールド323)を、ゼロでない値(または特定の値)について確認することを含み得る。
【0121】
ブロック906で、コンピューティングデバイスは、暗号化された識別子および一意の導出鍵を利用して、復号された識別子を生成し得る。一部の実施形態では、コンピューティングデバイスが、難読化された識別子の一部分から、一意の導出鍵(UDK)を導き出してもよい。一部の実施形態では、UDKは、事前に導出され、記憶装置から読み出されてもよい。例として、コンピューティングデバイスは、難読化された識別子の左端8桁を読み出し、それらの数字を所定の暗号化アルゴリズムへの入力として使用して、UDKを生成し得る。UDKは、生成されると、暗号化された識別子を復号するために利用され得る。
【0122】
ブロック908で、メッセージは、復号された識別子を利用して、コンピューティングデバイスによって処理されてもよい。例として、コンピューティングデバイスは、中央サーバコンピュータ(例えば、図1の中央サーバコンピュータ108)であってもよい。このシナリオでは、メッセージ(例えば、承認要求メッセージ)を処理することは、復号された識別子を含むようにメッセージを修正することと、さらなる処理のために承認事業体コンピュータ(例えば、承認事業体コンピュータ110)にメッセージを送信することとを含み得る。一部の実施形態では、コンピューティングデバイスは、承認事業体コンピュータ110であってもよい。このシナリオでは、メッセージを処理することは、復号された識別子を含むメッセージデータによる、取引の承認を含み得る。処理は、取引が承認または拒否されたことを示す、承認応答メッセージの生成をさらに含んでもよい。承認応答メッセージは、暗号化された識別子を含み、例えば、図1に関係する上記のプロセスによって、中央サーバコンピュータ108に送信されてもよい。
【0123】
技術面の改善
本明細書に記載される技術を利用することによって、機密データ(例えば、PAN)を伝達するためのより安全な方法が可能になる。PANは、暗号化され、非従来型のデータフィールドだけでなく、通常はPANを含むであろうが、代わりにPANが判定される可能性が低い難読化された値を含む、従来のデータフィールドにも提供される。難読化された値には、依然として元のBINが含まれ、承認要求/応答メッセージに対する従来のルーティング技術は、変わらないままであることが保証され得る。本明細書に記載される技術によって、承認要求/応答メッセージからPANを識別することが、不可能でないにしても困難になる。加えて、一部の実施形態では、PANは、常に変化している動的値を使用して暗号化される。したがって、暗号化された値は、各承認要求に対して変更することができ、特定のユーザに対する取引を経時的に追跡することが、不可能でないにしても困難になる。その結果、これらの方法によって、特定のユーザおよび/またはアカウントが、承認要求/応答メッセージから識別できないことを保証することによって、個人データのプライバシーに関して改善をもたらす。
【0124】
本明細書に記載されるコンピューティングデバイスのいずれもが、上記の事業体または構成要素のいずれかを実装するために使用され得る、コンピュータシステムの例であってもよい。こうしたコンピュータシステムのサブシステムは、システムバスを介して相互接続してもよい。追加のサブシステムには、プリンタ、キーボード、記憶デバイス、およびディスプレイアダプタに結合されるモニタが含まれる。入出力(I/O)コントローラに結合する、周辺デバイスおよびI/Oデバイスは、シリアルポートなどの当技術分野で既知の任意の数の手段によって、コンピュータシステムに接続することができる。例えば、I/Oポートまたは外部インターフェースを使用して、インターネットなどの広域ネットワーク、マウス入力デバイス、またはスキャナに、コンピュータ装置を接続できる。システムバスを介した相互接続により、中央プロセッサが、各サブシステムと通信し、サブシステム間の情報の交換だけでなく、システムメモリまたは記憶デバイスからの命令の実行を制御することが可能になり得る。システムメモリおよび/または記憶デバイスは、コンピュータ可読媒体を具現化してもよい。
【0125】
記載のように、本発明のサービスは、一つ以上の機能、プロセス、動作、または方法ステップを実装することを伴い得る。一部の実施形態では、機能、プロセス、動作、または方法ステップは、好適にプログラムされたコンピューティングデバイス、マイクロプロセッサ、データプロセッサなどによる一組の命令またはソフトウェアコードの実行の結果として実装されてもよい。命令またはソフトウェアコードのセットは、コンピューティングデバイス、マイクロプロセッサなどによってアクセスされるメモリ、または他の形態のデータ記憶要素に保存されてもよい。他の実施形態では、機能、プロセス、動作、または方法ステップは、ファームウェアまたは専用のプロセッサ、集積回路によって実装されてもよい。
【0126】
本出願に記載のソフトウェアコンポーネントまたは機能のいずれかは、例えば、従来の技術もしくはオブジェクト指向の技術を使った、例えば、Java、C++、またはPerlなどの任意の好適なコンピュータ言語を使用する、プロセッサによって実行されるソフトウェアコードとして実施されてもよい。ソフトウェアコードは、ランダムアクセスメモリ(RAM)、読み出し専用メモリ(ROM)、ハードドライブもしくはフロッピーディスクなどの磁気媒体、またはCD-ROMのような光媒体などの、コンピュータ可読媒体上の一連の命令またはコマンドとして保存されてもよい。そのようなコンピュータ可読媒体は、単一の計算装置上またはその内部にあってもよく、システムまたはネットワーク内の異なる計算装置上もしくはその内部に存在し得る。
【0127】
上の記載は例示であり、限定するものではない。本開示を検討すると、本発明の多くの変形が、当業者に対して明らかとなるであろう。そのため、本発明の範囲は、上の記載を参照して判定されるべきではなく、代わりに、係属中の特許請求の範囲を参照して、それらの全範囲または同等物と併せて判定されるべきである。
【0128】
いずれの実施形態の一つ以上の特徴は、本発明の範囲から逸脱することなく、いずれの他の実施形態の一つ以上の特徴と組み合わせてもよい。
【0129】
「一つの(a)」、「一つの(an)」、または「その(the)」の列挙は、特に反対の指示がない限り、「一つ以上」を意味することを意図している。
【0130】
上で言及したすべての特許、特許出願、刊行物、および記載は、あらゆる目的のためにその全体が参照により本明細書に援用される。いずれも先行技術と認められない。
図1
図2
図3
図4
図5
図6
図7
図8
図9