JP2022514613A - オフライン認証を安全に実施するための技術 - Google Patents

Abstract

オフライン認証のプロセス中に機密データ（例えば、対話データ）を安全に伝達するためのシステムおよび方法が開示されている。データパケットは、一方向通信において、ユーザデバイスからアクセスデバイスによって受信され得る。データパケットは、証明機関によって認証されたデジタル証明書およびユーザデバイスによって生成されたデジタル署名値を含む対話データを取得するために変換されてもよい。ユーザデバイスに関連付けられた第二の公開鍵は、証明機関に関連付けられたデジタル証明書および第一の公開鍵を利用して取得することができる。対話データの有効性は、少なくとも部分的に、ユーザデバイスに関連付けられたデジタル署名値および第二の公開鍵に基づいて判定され得る。対話データが有効であると判定された場合、対話データの識別子が承認され、この承認に基づいてアクセスが提供され得る。

Description

関連出願の相互参照
本国際出願は、２０１８年１２月１９日出願の米国特許出願１６／２２６，５８３号に対する優先権を主張するもので、その開示の全体があらゆる目的のために参照により本明細書に組み込まれる。

本開示の実施形態は、オフライン認証のプロセス中に、機密データを安全に提供することに関する。いくつかの文脈では、オフライン認証は、受信デバイス（例えば、端末）のタイミング制約のために、オンライン認証よりも好ましい。例えば、多くの大量の高速ペース認証システム（例えば、交通機関端末、チケットシステムなど）は、最小限の時間遅延で受信デバイスによりユーザを認証することを要求する。

ユーザデバイス（例えば、携帯電話）によって提供される情報には、機密データが含まれ得る。結果として、この情報を傍受し得る熟練した不正行為者から、ユーザを保護するために、セキュリティ対策が必要となる。この機密データは、あるデバイスから別のデバイスに伝送され得るため、現在の技術では問題が生じる可能性がある。これらの技術では、通信の遅延が発生するだけでなく、不正行為者が通信を傍受することもできる。機密データのサイズが大きすぎて、他の従来の方法を使用できない場合がある。

本発明の実施形態は、これらおよび他の問題に、個々にかつまとめて対処する。

本発明の実施形態は、機密データ（例えば、認証情報、アカウントデータなど）を受信デバイスに安全に伝達するために使用できる方法、システム、デバイス、およびコンピュータ可読媒体を対象とする。有利なことに、本発明の実施形態では、機密データは、安全である（例えば、犯罪者がデータを傍受および／または取得するのを防止する）方法で伝達され、既存のインフラストラクチャをいかなる顕著な方法で更新する必要もない。

本発明の一実施形態は、オフライン認証を実施するための方法を対象とする。方法は、アクセスデバイスで、証明機関に関連付けられた第一の公開鍵を受信することを含み得る。アクセスデバイスがオフラインモードで動作している間、この方法の追加ステップが発生する場合がある。方法は、一方向通信からアクセスデバイスによって、ユーザデバイスからデータパケットを取得することをさらに含んでもよい。方法は、アクセスデバイスで、証明機関によって認証されたデジタル証明書およびユーザデバイスによって生成されたデジタル署名値を含む対話データを取得するためデータパケットを変換することをさらに含み得る。方法は、アクセスデバイスで、証明機関に関連付けられたデジタル証明書および第一の公開鍵を利用して、ユーザデバイスに関連付けられた第二の公開鍵を取得することをさらに含み得る。方法は、アクセスデバイスで、ユーザデバイスに関連付けられたデジタル署名値および第二の公開鍵に少なくとも部分的に基づいて、対話データの有効性を判定することをさらに含み得る。方法は、対話データが有効であると判定された場合、アクセスデバイスにおいて、対話データの識別子を承認することをさらに含んでもよい。方法は、アクセスデバイスによって、対話データの識別子が承認されているとの判定に少なくとも部分的に基づいてアクセスを提供することをさらに含んでもよい。

本発明の別の実施形態は、一つ以上のプロセッサによってコンピュータ実行可能命令を実行することで、アクセスデバイスに動作を実施させるコンピュータ実行可能命令を格納する、一つ以上のメモリを備えるアクセスデバイスを対象とする。動作は、アクセスデバイスで、証明機関に関連付けられた第一の公開鍵を受信することを含んでもよい。動作は、アクセスデバイス（例えば、オフラインモードで動作している間）によって、一方向通信からユーザデバイスからデータパケットを取得することをさらに含み得る。動作は、アクセスデバイス（例えば、オフラインモードで動作している間）で、証明機関によって認証されたデジタル証明書およびユーザデバイスによって生成されたデジタル署名値を含む対話データを取得するようにデータパケットを変換することをさらに含み得る。動作は、アクセスデバイス（例えば、オフラインモードで動作している間）で、証明機関に関連付けられたデジタル証明書および第一の公開鍵を利用して、ユーザデバイスに関連付けられた第二の公開鍵を取得することをさらに含み得る。動作は、アクセスデバイス（例えば、オフラインモードで動作している間）で、ユーザデバイスに関連付けられたデジタル署名値および第二の公開鍵に少なくとも部分的に基づいて、対話データの有効性を判定することをさらに含み得る。動作は、対話データが有効であると判定された場合、アクセスデバイス（例えば、オフラインモードで動作している間）で、対話データの識別子を承認することをさらに含み得る。動作は、アクセスデバイス（例えば、オフラインモードで動作している間）で、対話データの識別子が承認されていると判定することに少なくとも部分的に基づいてアクセスを提供することをさらに含んでもよい。

本発明の別の実施形態は、（非一時的）コンピュータ可読媒体を対象とする。コンピュータ可読媒体は、本明細書で論じる方法を実施するためのコードを含む。一部の実施形態では、携帯式ユーザデバイスなどのコンピューティングデバイスが、このコンピュータ可読媒体を備えてもよい。

本発明のこれらのおよび他の実施形態について、図面を参照して以下でさらに詳細に記載する。

一部の実施形態による、オフライン認証のための機密データを提供するシステムのブロック図を示す。 一部の実施形態による、登録方法を示す。 一部の実施形態による、例示的な証明書の仕様書を示す。 一部の実施形態による、機密データを安全に伝達するためオフライン認証を実施する方法のフローチャートを示す。 一部の実施形態による、生成されたコードについての例示的なデータ仕様書を示す。 一部の実施形態による、オフライン認証を実施するための方法のフローチャートを示す。 取引処理システムを示すブロック図を示す。 建物アクセスシステムを示すブロック図を示す。

従来の取引（例えば、決済取引）では、アカウント識別子（例えば、個人アカウント識別子）は、携帯電話などの携帯式消費者デバイスからアクセスデバイス（例えば、ＰＯＳ端末）へと、最終的には従来の支払処理ネットワークを通して渡されてもよい。一部の従来の技術では、アカウント識別子は、暗号化および／または難読化される場合があるが、暗号化／難読化されたデータは、依然として、取引メッセージの中に提供される可能性があり、データフィールドは、潜在的な不正行為者には容易に識別可能である。

本明細書に記載のプロセスは、このデータが受信デバイス（例えば、交通機関のゲートで端末デバイス）に提供されるとき、機密データ（例えば、アカウント識別子などのアカウントデータ）を保護するために使用され得る。以下にさらに詳細に説明するように、本発明の実施形態は、機密データの一つ以上のデータフィールドおよび暗号アルゴリズム（例えば、楕円曲線暗号アルゴリズム）を使用してデジタル署名を生成する。機密データおよびデジタル署名は、クイックレスポンス（ＱＲ）コードに変換され、ユーザのデバイス（例えば、携帯電話のディスプレイを介して）で提示されてもよい。端末デバイスは、ＱＲコード（登録商標）を読み取り、基礎となるデータを取得し、デジタル署名を検証して、機密データが変更されていないことを保証する。従来のシステムとは異なり、本明細書の実施形態は、端末装置が、端末デバイスとユーザのデバイスとの間の通信を全く起こさずに、ユーザのデバイスのディスプレイからＱＲコード（登録商標）のみを取得する必要があるように、データの一方向転送を利用し得る。したがって、機密データは、オフライン認証プロセスが傍受のリスクが低減されて実行され得るように、安全かつ効率的に通信され得る。

本発明の詳細な実施形態について論じる前に、特定の用語についてのいくつかの説明が有用であり得る。

「コンピューティングデバイス」（「ユーザデバイス」とも呼ばれる）は、計算を実施することができ、他のデバイスと通信できる、任意の好適なデバイスであってもよい。携帯電話などの携帯式コンピューティングデバイスは、コンピューティングデバイスの一例である。他のタイプのコンピューティングデバイスは、ポータブルではない場合がある。

「クイックレスポンス（ＱＲ）コード」は、機械可読データを含む黒および白の正方形の多次元配列を含み得る。ＱＲコード（登録商標）はマトリックスバーコードと呼ばれる場合があります。

「楕円曲線暗号（ＥＣＣ）アルゴリズム」には、有限フィールド上の楕円曲線の代数構造に基づく公開鍵暗号アルゴリズムが含まれる場合がある。ＥＣＣは、同等のセキュリティを提供するために、ＥＣＣ以外の暗号アルゴリズム（Ｒａｖｅｓｔ－Ｓｈａｍｉｒ－Ａｄｌｅｍａｎ（ＲＳＡ）アルゴリズムなど）よりも小さな暗号鍵を必要とする場合がある。

「暗号化された値」は、任意の好適な暗号化されたバージョンの値を含み得る。暗号化された値は、例えば、対称および／または非対称の暗号化技術を利用して、任意の好適な暗号化技術を利用する、値（例えば、識別子）から生成され得る。

「機密データ」とも呼ばれる「対話データ」は、ユーザデバイスとアクセスデバイスとの間の対話のために利用される任意の適切なデータを含んでもよい。一例として、対話データは、トラック２等価データ（ＩＳＯ ７８１３に定義される）、タイムスタンプ情報、証明機関（ＣＡ）公開鍵インデックス、特定のユーザデバイスに関連付けられ、特定のＣＡによって認証される公開鍵証明書、対話データの他のデータフィールドを利用して生成されるデジタル署名等が含まれるが、これらに限定されない、図３に描写される任意の適切なデータフィールドを含んでもよい。

本出願の目的のために、「支払データ」は、金融用途に関して、取引を実行するように支払サービスによって使用されるそれらのデータ要素、および非金融取引に関して、本発明を除いて必要ないかなるデータ要素も含むことができる。例えば、一部の実施形態では、「支払データ」は、プライマリアカウント番号、有効期限、サービスコード、および任意データなど、クレジットカード業界の当業者が理解するような、トラック１および／またはトラック２のデータを含んでもよい。「支払データ」はまた、一意のカード識別番号またはサービスプロバイダの一意の識別番号を含んでもよい。支払データは、ユーザデバイス（例えば、携帯電話など）上に位置するメモリ内に存在してもよい。

「デジタル署名」には、デジタルメッセージの真正性を検証するために使用できる値が含まれる場合がある。有効なデジタル署名は、受信者が既知の送信者によって作成されたと信じる理由、送信者がメッセージを送信したことを拒否できない理由、およびメッセージが送信中に変更されていない理由を与えることができる。

「承認事業体」は、要求を承認する事業体とすることができる。承認事業体の例は、発行者、政府機関、文書保管所、アクセス管理者などであり得る。「発行者」は通常、ユーザのアカウントを保持するビジネス事業体（例えば、銀行）を指し得る。発行者はまた、消費者に対して携帯電話、スマートカード、タブレット、またはラップトップなどのユーザデバイスに格納される、支払証明書を発行することができる。「承認事業体コンピュータ」は、承認事業体によって、または承認事業体に代わって操作されてもよい。

「アクワイアラ」は通常、特定の小売業者または他の事業体とビジネス関係を有するビジネス事業体（例えば、商業銀行）とすることができる。一部の事業体は、発行者およびアクワイアラの両方の機能を果たすことができる。一部の実施形態は、こうした単一事業体の発行者－アクワイアラを含み得る。アクワイアラは、「転送コンピュータ」とも総称され得る、アクワイアラコンピュータを操作し得る。

「リソースプロバイダ」は、物品、サービス、情報、および／またはアクセスなど、リソースを提供できる事業体であり得る。リソースプロバイダの例には、小売業者、アクセスデバイス、安全なデータアクセスポイントなどを含む。「小売業者」は通常、取引に携わり、物品もしくはサービスを販売する、または物品もしくはサービスへのアクセスを提供することができる事業体であり得る。「リソースプロバイダコンピュータ」は、リソースプロバイダによって、またはリソースプロバイダに代わって操作され得る、任意の好適なコンピューティングデバイスであってもよい。

「処理ネットワークコンピュータ」（中央サーバコンピュータとも呼ばれる）は、ネットワークデータを処理するために使用される、サーバコンピュータを含み得る。一部の実施形態では、処理ネットワークコンピュータは、データベースに結合されてもよく、一つ以上のクライアントコンピュータからの要求にサービスを提供する、いずれのハードウェア、ソフトウェア、他のロジック、または前述の組み合わせを含んでもよい。処理ネットワークコンピュータは、一つ以上の計算装置を備えてもよく、一つ以上のクライアントコンピュータからの要求にサービスを提供する、様々なコンピュータ構造、配置、およびコンパイルのうちのいずれを使用してもよい。一部の実施形態では、処理ネットワークコンピュータは、複数のサーバコンピュータを操作し得る。こうした実施形態では、各サーバコンピュータは、所与の領域に対する取引を処理するか、または取引データに基づいて特定タイプの取引に対処するように構成され得る。

処理ネットワークコンピュータは、承認サービスと、例外ファイルサービスと、清算および決済サービスとをサポートし配信するのに使用される、データ処理サブシステム、ネットワーク、ならびに動作を含んでいてもよい。例示的な処理ネットワークコンピュータは、ＶｉｓａＮｅｔ（商標）を含んでいてもよい。ＶｉｓａＮｅｔ（商標）を含むネットワークは、クレジットカード取引、デビットカード取引、および他のタイプの商取引を処理することができる。具体的には、ＶｉｓａＮｅｔ（商標）には、承認要求を処理する統合支払システム（Ｉｎｔｅｇｒａｔｅｄ Ｐａｙｍｅｎｔｓシステム）と、清算および決済サービスを実施するＢａｓｅ ＩＩシステムとが含まれる。処理ネットワークコンピュータは、インターネットを含む、任意の好適な有線または無線ネットワークを使用することができる。

「承認要求メッセージ」は、取引処理コンピュータおよび／または承認事業体コンピュータ（例えば、支払カードの発行者）へ送られて、取引に対する承認を要求する電子メッセージであってもよい。一部の実施形態による承認要求メッセージは、支払デバイスまたは支払アカウントを使用する消費者によりなされる支払いと関連付けられた、電子取引情報を交換するシステムの標準である、ＩＳＯ８５８３に準拠することができる。承認要求メッセージは、支払デバイスまたは支払アカウントと関連付けられてもよい、発行者アカウント識別子を含んでもよい。承認要求メッセージはまた、単に例として、サービスコード、ＣＶＶ（カード検証値）、ｄＣＶＶ（動的カード検証値）、有効期限などを含む、「識別情報」に対応する追加のデータ要素を含むことができる。承認要求メッセージはまた、取引を識別および／または承認するかの判定に利用されてもよい、いかなる他の情報だけでなく、取引額、小売業者識別子、小売業者所在地など、現在の取引と関連付けられた、任意の情報などの「取引情報」を含んでもよい。

「承認応答メッセージ」は、承認事業体コンピュータまたは取引処理コンピュータによって生成された、承認要求メッセージに応答する電子メッセージとすることができる。承認応答メッセージは、単に例として、次の状態指標のうちの一つ以上を含んでもよい。承認 ― 取引が承認された。拒否－取引が承認されなかった。または、コールセンタ ― 応答はより多くの情報を保留中で、小売業者は、フリーダイヤルの認証電話番号に電話する必要がある。承認応答メッセージはまた、承認事業体（例えば、発行者銀行）が、承認要求メッセージに応じて、取引の承認を示す、リソースプロバイダコンピュータへの電子メッセージ（直接または取引処理コンピュータを介してのいずれか）で返信するコードであり得る、承認コードを含むことができる。コードは、承認の証明として役割を果たし得る。一部の実施形態では、取引処理コンピュータは、承認応答メッセージを生成するか、またはそれをリソースプロバイダに転送し得る。

「サーバコンピュータ」は通常、強力なコンピュータまたはコンピュータのクラスタである。例えば、サーバコンピュータは、大型メインフレーム、ミニコンピュータクラスタ、またはユニットとして機能するサーバ群であり得る。一例では、サーバコンピュータは、ウェブサーバに結合されるデータベースサーバであり得る。

「プロセッサ」は、任意の好適な単数または複数のデータ計算デバイスを指すことができる。プロセッサは、所望の機能を達成するために共に動作する、一つ以上のマイクロプロセッサを備えることができる。プロセッサは、ユーザおよび／またはシステム生成要求を実行するプログラム構成要素を実行するために適切な、少なくとも一つの高速データプロセッサを備えるＣＰＵを含んでもよい。ＣＰＵは、ＡＭＤのアスロン、デュロン、および／もしくはオプテロン、ＩＢＭおよび／もしくはモトローラーのＰｏｗｅｒＰＣ、ＩＢＭおよびソニーのセルプロセッサ、インテルのセレロン、アイテニウム、ペンティアム（登録商標）、ジーオン、および／もしくはＸＳｃａｌｅ、ならびに／または同様のプロセッサなどのマイクロプロセッサであり得る。

「メモリ」は、電子データを保存できる、任意の好適な単数または複数のデバイスであり得る。好適なメモリとして、所望の方法を実施するためにプロセッサによって実行できる命令を保存する、非一時的コンピュータ可読媒体が含まれ得る。メモリの例として、一つまたは複数のメモリチップ、ディスクドライブなどが含まれ得る。こうしたメモリは、任意の好適な電気的、光学的、および／または磁気的な動作モードを使用して動作することができる。

図１は、一部の実施形態による、オフライン認証のための機密データを提供するためのシステム１００のブロック図を示す。システム１００は、認証、アクセス制御、ならびに／または金融取引および／もしくは非金融取引の承認のために、図１に示す様々なコンピュータを利用するデータ通信を容易にするように使用され得る。システム１００は、ユーザデバイス１０２、リソースプロバイダコンピュータ１０４、転送コンピュータ１０６、中央サーバコンピュータ１０８、および承認事業体コンピュータ１１０を含む。これらのシステムおよびコンピュータの各々が、互いと動作連通していてもよい。説明を簡単にするために、ある一定数の構成要素を図１に示している。しかしながら、本発明の実施形態は、各構成要素を一つより多く含んでもよいことは理解されるものとする。加えて、本発明の一部実施形態は、図１に示す構成要素のすべてより少ないまたは多い数を含んでもよい。加えて、図１の構成要素は、任意の好適な通信プロトコルを使用して、任意の好適な通信媒体（インターネットを含む）を介して通信してもよい。

ユーザデバイス１０２は、いかなる好適な形態であってもよい。例えば、ユーザデバイス１０２は、携帯電話、携帯情報端末（ＰＤＡ）、ネットブック、スマートウォッチ、ラップトップコンピュータ、ポケベル、スマートメディアなどを含んでもよい。

一部の実施形態では、ユーザデバイス１０２は、電話などの特定のデバイス機能を有効にするために使用される回路を含んでもよい。これらの機能を有効にするための機能要素は、ユーザデバイス１０２の機能および動作を実行する命令を実行できる一つ以上のプロセッサを含んでもよい。プロセッサは、ユーザデバイス１０２のメモリにアクセスして、スクリプトおよびモバイルアプリケーションを供給するなどの命令を実行する際に使用される命令またはデータを取得することができる。ユーザデバイス１０２は、キーボード、ディスプレイ、スピーカ、マイクロフォン、および／またはタッチスクリーンなどの入力／出力要素を含み得る。これらのＩ／Ｏ要素は、ユーザがユーザデバイス１０２および入力データを動作することを可能にするために使用され得る。これらの入力／出力要素はまた、例えば、デバイスのスピーカを介してデータを出力するように構成され得る。ユーザデバイス１０２はまた、ディスプレイを使用してデータを出力してもよい。

ユーザデバイス１０２は、アプリケーション（例えば、アプリケーション１１６）および／またはその他の任意の適切なモジュールもしくはデータを含み得るメモリを含み得る。ユーザデバイス１０２は、メモリにインストールされたまたは格納された任意の数のアプリケーションを有することができる。ユーザデバイス１０２のメモリはまた、本明細書において説明される方法を実装するために、一つ以上のプロセッサにより実行可能なコードを含んでもよい。一部の実施形態では、メモリは、機密データ（例えば、支払データ（例えば、トラック２データ）、公開／秘密鍵ペアの秘密鍵、公開／秘密鍵ペアの公開鍵を含む証明書）を格納するように構成されてもよい。アプリケーション１１６は、秘密鍵および／または対応する公開鍵を含む証明書を受信するように構成され得る。公開／秘密鍵ペアは、証明機関（例えば、中央サーバコンピュータ１０８）によって提供されてもよく、証明書は、証明機関によって認証されてもよい。実施形態によっては、証明書は、ユーザデバイス１０２の公開鍵が、証明機関の公開鍵および暗号アルゴリズムを利用して取得され得るように、証明機関の公開鍵を利用してデジタル署名されてもよい。

一部の実施形態では、アプリケーション１１６は、ユーザデバイス１０２のプロセッサに、機密データを含むコード（例えば、ＱＲコード（登録商標）、音声埋め込みデータなど）を生成させるように構成されてもよい。生成されると、コードは、コードが受信デバイス（例えば、アクセスデバイス１１８）によって取得できるように、ユーザデバイス１０２のディスプレイ（および／またはスピーカ）で提示され得る。

リソースプロバイダコンピュータ１０４は、リソースプロバイダ（例えば、小売業者など）によって、またはリソースプロバイダに代わって操作されてもよく、転送コンピュータは、リソースプロバイダと関連付けられてもよい。例えば、転送コンピュータは、リソースプロバイダと関連付けられたアカウントを管理する責任を負う、アクワイアラ（例えば、金融機関）によって操作されてもよい。承認事業体コンピュータ１１０は、発行者（例えば、別の金融機関）によって操作されてもよい。一部の実施形態では、事業体はアクワイアラおよび発行者の両方であり、本発明の実施形態はこうした事業体を含む。

中央サーバコンピュータ１０８は、承認サービスと、例外ファイルサービスと、清算および決済サービスとをサポートし配信するのに使用される、データ処理サブシステム、ネットワーク、ならびに動作を含んでいてもよい。例示的な支払処理ネットワークは、ＶｉｓａＮｅｔ（商標）を含んでいてもよい。ＶｉｓａＮｅｔ（商標）などの支払処理ネットワークは、クレジットカード取引、デビットカード取引、および他のタイプの商取引を処理することができる。具体的には、ＶｉｓａＮｅｔ（商標）には、承認要求を処理するＶＩＰシステム（Ｖｉｓａ Ｉｎｔｅｇｒａｔｅｄ Ｐａｙｍｅｎｔｓシステム）と、清算および決済サービスを実施するＢａｓｅ １１システムが含まれる。

中央サーバコンピュータ１０８は、サーバコンピュータを含み得る。サーバコンピュータは通常、強力なコンピュータまたはコンピュータのクラスタである。例えば、サーバコンピュータは、大型メインフレーム、ミニコンピュータクラスタ、またはユニットとして機能するサーバ群であり得る。一例では、サーバコンピュータは、ウェブサーバに結合されるデータベースサーバであり得る。中央サーバコンピュータ１０８は、インターネットを含む、任意の好適な有線または無線ネットワークを使用することができる。

一部の実施形態では、中央サーバコンピュータ１０８（または別の好適なシステム）は、証明機関であるように構成されてもよい。証明機関として動作し、中央サーバコンピュータ１０８は、任意の適切な数のユーザデバイスに対して公開／秘密鍵ペアを生成し、それぞれの鍵ペアの公開鍵を含む対応する証明書を生成するように構成され得る。一部の実施形態では、中央サーバコンピュータ１０８は、中央サーバコンピュータ１０８に関連付けられた公開鍵を利用して、各証明書にデジタル署名し得る。中央サーバコンピュータ１０８は、その公開鍵を任意の適切な数のデバイス（例えば、アクセスデバイス１１８）に配布するようにさらに構成されてもよい。

リソースプロバイダコンピュータ１０４は、ユーザデバイス１０２と対話できるアクセスデバイス１１８も有してもよく、またはアクセスデバイス１１８からの通信を受信してもよい。図１では、アクセスデバイス１１８は、リソースプロバイダコンピュータ１０４に位置する。しかしながら、本発明の他の実施形態の任意の他の好適な位置に配置され得る。リソースプロバイダコンピュータ１０４は、リソースプロバイダ（例えば、小売業者）によって操作される、任意の好適な計算装置を含み得る。一部の実施形態では、リソースプロバイダコンピュータ１０４は、リソースプロバイダ（例えば、小売業者）と関連付けられた、一つ以上のウェブサイトをホストし得る、一つ以上のサーバコンピュータを含んでもよい。一部の実施形態では、リソースプロバイダコンピュータ１０４は、ユーザ（例えば、消費者）とリソースプロバイダとの取引のため、支払検証および／または認証プロセスの一部として、転送コンピュータ１０６を介して中央サーバコンピュータ１０８にデータを送るように構成されてもよい。リソースプロバイダコンピュータ１０４はまた、リソースプロバイダとユーザ１０３との間の取引に対する承認要求メッセージを生成し、追加の取引処理のため、承認要求メッセージを承認事業体コンピュータ１１０に（例えば、中央サーバコンピュータ１０８を介して）ルーティングするように構成されてもよい。

本発明の実施形態によるアクセスデバイスは、任意の好適な形態であってもよい。アクセスデバイスの例として、販売時点情報管理（ＰＯＳ）デバイス、携帯電話、ＰＤＡ、パーソナルコンピュータ（ＰＣ）、タブレットＰＣ、改札口、ハンドヘルド専用リーダ、セットトップボックス、電子キャッシュレジスタ（ＥＣＲ）、現金自動預入支払機（ＡＴＭ）、仮想キャッシュレジスタ（ＶＣＲ）、キオスク、セキュリティシステム、アクセスシステムなどが挙げられる。アクセスデバイス１１８は、入力／出力（Ｉ／Ｏ）デバイス１２０、プロセッサ１２２、およびコンピュータ可読媒体１２４を含んでもよい。Ｉ／Ｏデバイス１２０は、ユーザデバイス１０２と対話するように構成された、撮像デバイス（例えば、カメラ）、デジタルスキャナ、バーコードリーダ、マイクロフォン等を含んでもよい。一部の実施形態では、アクセスデバイス１１８は、リソースへのアクセスを管理するように構成されてもよい。一例として、アクセスデバイス１１８は、交通機関の駅の交通機関のゲートの改札口に位置してもよく、アクセスデバイス１１８は、改札口の動作を管理して、交通機関の駅の一部へのアクセスを可能にしてもよい。

典型的なアクセストランザクションでは、ユーザ１０３は、アプリケーション１１６を利用して、ユーザデバイス１０２で視覚および／または音声コード（例えば、ＱＲコード（登録商標）、音声埋め込みデータなど）を生成してもよい。例えば、アプリケーション１１６は、ＱＲコード（登録商標）１１４および／または音声１１５を生成するために利用され得る。視覚および／または音声コード（例えば、ＱＲコード（登録商標）１１４、音声１１５など）を生成するために、ユーザデバイス１０２は、ユーザデバイス１０２のメモリに格納された対話データ（例えば、ＩＳＯ ７８１３に定義されるトラック２データのような支払データ、証明機関（ＣＡ）公開鍵インデックス、ユーザデバイス１０２に関連付けられた公開鍵証明書、トークン／暗号文など）を取得し得る。対話データのうちの少なくとも一部は、アクセストランザクションの開始前に証明機関（例えば、中央サーバコンピュータ１０８）とのユーザデバイス１０２で実施される登録プロセスに応答して格納されてもよい。ユーザデバイス１０２はさらに、対話データの少なくとも一部のデータフィールドおよび暗号アルゴリズム（例えば、楕円曲線暗号アルゴリズム）を利用してデジタル署名を生成するように構成されてもよい。対話データおよびデジタル署名は、視覚および／またはコード（例えば、ＱＲコード（登録商標）１１４および／または音声１１５）に変換され、ユーザデバイス１０２（例えば、それぞれディスプレイを介して、スピーカを介して）で提示されてもよい。ユーザ１０３は、Ｉ／Ｏデバイス１２０（例えば、ＱＲスキャナ、マイクロフォンなど）が視覚および／または音声コードを取り込むために利用され得るように、ユーザデバイス１０２をアクセスデバイス１１８の近くに保持してもよい。アクセスデバイス１１８のプロセッサ１２２は、取り込まれたコードを変換して、基礎となるデータ（例えば、ＱＲコード（登録商標）１１４および／または音声１１５に埋め込まれた対話データ）を取得するように構成されてもよい。

一旦変換されると、アクセスデバイス１１８のプロセッサ１２２は、対話データからＣＡ公開鍵インデックスを取得することができる。ＣＡ公開鍵インデックスは、特定のＣＡと関連付けられ、アクセスデバイス１１８のメモリに格納される特定の公開鍵と関連付けられてもよい。一部の実施形態では、アクセスデバイス１１８は、複数の公開鍵を格納してもよく、それぞれが特定のＣＡに対応し、それぞれが固有のＣＡ公開鍵インデックスと関連付けられる。対話データのＣＡ公開鍵インデックスを使用して、アクセスデバイス１１８は、対話データに含まれる公開鍵証明書の証明機関（およびその格納された公開鍵）を識別し得る。取得したＣＡ公開鍵は、ＣＡ（例えば、中央サーバコンピュータ１０８）によって認証され、ユーザデバイス１０２と関連付けられる公開鍵を取得するために、暗号アルゴリズムへの入力として、対話データの公開鍵証明書とともに利用され得る。

一旦取得されると、証明書から取得され、ユーザデバイス１０２と関連付けられる公開鍵は、対話データのデジタル署名を検証するために利用され得る。一部の実施形態では、アクセスデバイス１１８は、ユーザデバイス１０２のデジタル署名および公開鍵を、暗号アルゴリズム（楕円曲線暗号アルゴリズム）への入力として利用して、対話データの一つ以上のデータフィールドに対応するハッシュ値を取得してもよい。対話データの一つ以上の対応するデータフィールドは、アクセスデバイス１１８によって再ハッシュされてもよく、結果として得られた値を、取得したハッシュ値と比較してもよい。結果として得られるハッシュが取得されたハッシュと一致する場合、アクセスデバイス１１８は、対話データが有効（例えば、変更されていない）と判定し得る。ハッシュが一致しない場合、アクセスデバイス１１８は、対話データが無効（例えば、変更された）であり、さらなる処理が行われないと判定し得る。

一部の実施形態では、対話データが有効であると判定された場合、アクセスデバイス１１８は、視覚および／または音声コードが所定の閾値期間内（例えば、過去１０分以内、過去５分以内など）に生成されたかどうかを判定するために、対話データのタイムスタンプデータを現在の時間と比較するように構成され得る。一部の実施形態では、対話データのタイムスタンプデータが古くなった場合（例えば、所定の閾値期間外の生成時間を示す）、アクセスデバイス１１８はアクセスを拒否してもよく、さらなる処理は行われなくてもよい。対話データのタイムスタンプデータが所定の閾値期間内の時間を示す場合、アクセスデバイス１１８は、対話データから識別子（例えば、アカウント識別子）を取得するように構成され得る。この識別子は、アクセスデバイス１１８によって、格納された制限リスト（例えば、アクセスが直ちに拒否されるアカウント識別子のリスト）と比較され得る。対話データからの識別子が、格納された制限リストの識別子のいずれとも一致しない場合、アクセスデバイス１１８は、ユーザデバイス１０２にアクセスを許可するように構成され得る。一例として、アクセスデバイス１１８が交通機関の駅の交通機関のゲートでの改札口である場合、アクセスデバイス１１８は、ユーザ１０３が交通機関の駅の一部分にアクセスできるように改札口が回転することを可能にし得る。

ユーザ１０３および／またはユーザデバイス１０２のアクセスを可能にすることに続く任意の適切な時間において、アクセスデバイス１１８は、オフライン認証プロセス中に取得された対話データの少なくとも一部を利用して、リソースプロバイダコンピュータ１０４にオンライン承認プロセスを実行させるように構成され得る。例えば、リソースプロバイダコンピュータ１０４（またはアクセスデバイス１１８）は、「承認要求メッセージ」を生成し、このメッセージを転送コンピュータ１０６に転送するように構成され得る。転送コンピュータ１０６は通常、特定のリソースプロバイダ（例えば、小売業者）または他の事業体と取引関係があり、取引のプロセスに関与し得る、ビジネス事業体（例えば、商業銀行）と関連付けられる。転送コンピュータ１０６は、リソースプロバイダ用のアカウントを発行および管理し、リソースプロバイダに代わって、承認事業体コンピュータ１１０と資金を交換し得る。一部の事業体は、承認事業体コンピュータ１１０および転送コンピュータ１０６両方の機能を果たすことができる。本発明の実施形態は、こうした単一事業体の発行者－アクワイアラコンピュータを含む。承認要求メッセージを受信した後、転送コンピュータ１０６は、承認要求メッセージを中央サーバコンピュータ１０８に送信し得る。中央サーバコンピュータ１０８はその後、承認要求メッセージを、ユーザデバイス１０２の承認事業体コンピュータ１１０、または承認事業体に代わって役割を果たす第三者事業体に転送し得る。

中央サーバコンピュータ１０８は、処理（例えば、支払処理）に使用される、少なくとも一つのサーバコンピュータを含むか、または操作する、ネットワークであってもよい。中央サーバコンピュータ１０８の中にあるサーバコンピュータは、プロセッサと、プロセッサに結合されたコンピュータ可読媒体とを含んでもよく、コンピュータ可読媒体は、本明細書に記載される機能を果たすために、プロセッサによって実行可能なコードを含む。一部の実施形態では、サーバコンピュータは、データベースに結合されてもよく、一つ以上のクライアントコンピュータからの要求にサービスを提供する、いずれのハードウェア、ソフトウェア、他のロジック、または前述の組み合わせを含んでもよい。サーバコンピュータは、一つ以上の計算装置を備えてもよく、一つ以上のクライアントコンピュータからの要求にサービスを提供する、様々なコンピュータ構造、配置、およびコンパイルのうちのいずれを使用してもよい。一部の実施形態では、中央サーバコンピュータ１０８は、複数のサーバコンピュータを操作し得る。こうした実施形態では、各サーバコンピュータは、所与の領域に対する取引を処理するか、または取引データに基づいて特定タイプの取引に対処するように構成され得る。

中央サーバコンピュータ１０８は、承認サービスと、例外ファイルサービスと、清算および決済サービスとをサポートし配信するのに使用される、データ処理サブシステム、ネットワーク、ならびに動作を含んでいてもよい。中央サーバコンピュータ１０８は、ＶｉｓａＮｅｔ（商標）を含んでもよい。ＶｉｓａＮｅｔ（商標）を含むネットワークは、クレジットカード取引、デビットカード取引、および他のタイプの商取引を処理することができる。具体的には、ＶｉｓａＮｅｔ（商標）には、承認要求を処理する統合支払システム（Ｉｎｔｅｇｒａｔｅｄ Ｐａｙｍｅｎｔｓシステム）と、清算および決済サービスを実施するＢａｓｅ ＩＩシステムとが含まれる。支払処理ネットワークは、インターネットを含む、任意の好適な有線または無線ネットワークを使用することができる。

中央サーバコンピュータ１０８は、取引要求メッセージを処理し、取引要求メッセージに対する適切な宛先（例えば、認証コンピュータ）を判定し得る。中央サーバコンピュータ１０８はまた、取引の清算および決済に対処し、ならびに／またはそれらを容易にし得る。

承認事業体コンピュータ１１０は通常、消費者用の消費者アカウントを発行および維持する、ビジネス事業体（例えば、銀行）と関連付けられる。承認事業体コンピュータ１１０は、クレジットカードおよびデビットカードなどを含む、消費者アカウント用の支払デバイスを発行してもよい。

承認事業体コンピュータ、または承認事業体に代わって役割を果たす第三者事業体が、承認要求メッセージを受信した後、承認事業体コンピュータ１１０、または発行者に代わって役割を果たす第三者事業体は、現在の取引が承認されている（または承認されていない）かどうかを示すため中央サーバコンピュータ１０８に承認応答メッセージを返信し得る。中央サーバコンピュータ１０８はその後、承認応答メッセージを転送して転送コンピュータ１０６に戻す。次いで転送コンピュータ１０６は、応答メッセージをリソースプロバイダコンピュータ１０４に返信し得る。一部の実施形態では、リソースプロバイダコンピュータ１０４は、ユーザデバイス１０２に取引（例えば、通知、電子メール、または任意の適切な電子通信手段を介して）を通知してもよい。

一日の終わりに、通常の清算および決済プロセスを、システム１００によって行うことができる。清算プロセスは、アクワイアラと発行者との間で金銭的詳細を交換して、ユーザのアカウントへの転記およびユーザの決済状況の調整を容易にするプロセスである。

本明細書に記載される技術を利用することによって、機密データを伝達するためのより安全な方法が可能になる。機密データは、不正行為者の目や耳からこのようなデータを保護するために、視覚および／または音声コードに埋め込まれる場合がある。追加で、機密データは、受信デバイスのリーダおよび／またはマイクロフォンを介して直接通信され、データが傍受され、変更または盗まれる可能性を低減する。ここで説明する技術を利用することによって、従来の技術に関して同じレベルのセキュリティを確保しつつ、機密データの全体的なデータフットプリントを削減することができる。このデータの通信を通して、ユーザおよび／またはユーザデバイスに関するサーバから追加のデータを取得することなく、最小限の時間で、ユーザが受信デバイスで認証されることを可能にするオフライン認証の方法が有効化される。

図２は、一部の実施形態による、登録方法（例えば、方法２００）を示す。当然のことながら、方法２００のステップは、任意の適切な順序で実施され得る。図２に提供された例では、中央サーバコンピュータ１０８は、証明機関として動作してもよい。したがって、中央サーバコンピュータ１０８は、それ自体の公開／秘密鍵ペアを生成し、その公開鍵を任意の適切な数のデバイスに配布するように構成され得る。証明機関として動作する中央サーバコンピュータ１０８は、さらに、一つ以上のデバイス（例えば、ユーザデバイス１０２）に対して公開／秘密鍵ペアを生成し、秘密鍵および対応する公開鍵を含む証明書をそれぞれのデバイスに配布するように構成され得る。これらの機能は、方法２００によって達成され得る。

一例として、方法２００は、中央サーバコンピュータ１０８（証明機関として動作）とアクセスデバイス１１８との間でデータを交換してもよい、ステップ１で開始されてもよい。アクセスデバイス１１８は、例えば、任意の適切なユーザインターフェースおよび／またはアプリケーションプログラミングインターフェースおよび／またはメッセージを介して、中央サーバコンピュータ１０８の公開鍵を要求してもよい。この要求の受信を通して、中央サーバコンピュータ１０８は、中央サーバコンピュータ１０８のために生成された将来の公開鍵がアクセスデバイス１１８に提供されることを示すマッピングを維持するように構成され得る。一部の実施形態では、中央サーバコンピュータ１０８は、定期的に（例えば、２４時間ごと、１２時間ごとなど）新しい公開／秘密鍵ペアを生成してもよい。中央サーバコンピュータ１０８は、その公開鍵を証明機関の公開鍵インデックスと関連付けてもよい。このインデックスは、中央サーバコンピュータ１０８を他の潜在的な証明機関から一意に識別する任意の適切な英数字値であってもよい。

ステップ２では、中央サーバコンピュータ１０８は、その公開鍵および証明機関（ＣＡ）公開鍵インデックスをアクセスデバイス１１８に提供してもよい。これは、アクセスデバイス１１８からの要求に応じて生じ得る。一部の実施形態では、公開鍵は、作成のいくつかの閾値期間内に提供されてもよい。すなわち、公開鍵は、アクセスデバイス１１８からの要求とは独立して提供され得る。むしろ、新しい公開鍵が生成された直後に、中央サーバコンピュータ１０８によって新しい公開鍵が提供され得る。

ステップ３では、アクセスデバイス１１８は、受信した公開鍵をＣＡ公開鍵インデックスへの関連付けと共にローカルメモリに格納してもよい。一部の実施形態では、アクセスデバイス１１８は、マッピング、データベース、または他の適切なストレージコンテナ内に、様々な証明機関に関連付けられた複数のＣＡ公開鍵インデックスを格納するように構成され得る。ＣＡ公開鍵インデックスは、ＣＡ公開鍵インデックスに対応するＣＡの関連付けられた公開鍵を取得するために使用できる。

ステップ４で、ユーザデバイス１０２は、中央サーバコンピュータ１０８（証明機関として動作）に登録してもよい。ステップ４で実施される登録プロセスは、任意の適切なユーザインターフェース、アプリケーションプログラミングインターフェース、または任意の適切な通信手段を利用してもよい。例としてのみ、ユーザデバイス１０２は、アプリケーション（例えば、図１のアプリケーション１１６）を利用して、名前、住所、政府識別識別子、支払データ、および／または同類のものなどのアカウント情報を提供し得る。

ステップ５で、かかるデータを受信するか、またはユーザデバイス１０２から直接要求することにより、中央サーバコンピュータ１０８は、ユーザデバイス１０２に対して公開／秘密鍵ペアを生成するように構成され得る。実施形態によっては、中央サーバコンピュータ１０８は、ユーザデバイス１０２に関連付けられた公開鍵から公開鍵証明書を生成してもよい。図３は、一部の実施形態による、例示的な証明書の仕様書３００（例えば、ユーザデバイス１０２用の公開鍵証明書）を示す。

ユーザデバイス１０２の公開鍵証明書は、図３に示されるものと同じ、それ以上、またはそれより少ないデータフィールドを含んでもよい。データフィールド１～８の一部は、特定のデータサイズ（バイト単位）で示されているが、データフィールドは図示されたものとはデータサイズが異なる場合があることが理解されるべきである。

一部の実施形態では、公開鍵証明書は、証明書の形式に対応するデータフィールド１を含んでもよい。一部の実施形態では、証明書の形式は、証明書用の特定の書式設定の仕様書を識別し得る。例として、図３に示すように、公開鍵証明書は形式「１４」を利用してもよい。

一部の実施形態では、公開鍵証明書は、証明書エンコーディングに対応するデータフィールド２を含んでもよい。図３に示す例では、公開鍵証明書は、「００」の符号化を利用してもよい。

一部の実施形態では、公開鍵証明書は、スイートインジケータに対応するデータフィールド３を含み得る。図３に図示した実施例では、スイートインジケータは、ユーザデバイス１０２に関連付けられた認証された公開鍵と共に使用されるアルゴリズムスイートを識別し得る。

一部の実施形態において、公開鍵証明書は、証明書の有効期限に対応するデータフィールド４を含んでもよい。証明書の有効期限は、証明書が期限切れで使用できないとみなされ得る日付（例：ＹＹＹＹＭＭＤＤ、ＵＴＣ の形式）を示すことができる。公開鍵証明書には、さらに、証明書の有効期限であるデータフィールド５を含めることができる。証明書の有効期限は、その後、証明書は、期限切れで使用できないとみなされ得る証明書の有効期限データに関連する時間（例えば、ＨＨＭＭ、ＵＴＣ、または任意の適切な形式）を示してもよい。

実施形態によっては、公開鍵証明書は、証明書シリアル番号に対応するデータフィールド６を含んでもよい。証明書のシリアル番号は、証明書の作成に使用された ＣＡ 秘密鍵を識別する任意の適切な英数字値であってよい。

一部の実施形態では、公開鍵証明書は、デバイス（例えば、ユーザデバイス１０２）に関連付けられた公開鍵に対応するデータフィールド７を含むことができる。一部の実施形態では、デバイスに関連付けられた公開鍵は、スイートインジケータ（例えば、データフィールド３）に対応する楕円曲線アルゴリズムに基づいて生成され得る。一部の実施形態では、データフィールド７は、スイートインジケータによって識別される曲線上の公開鍵ポイントのｘ座標に対応してもよい。

実施形態によっては、公開鍵証明書は、公開鍵証明書の署名に対応するデータフィールド８を含んでもよい。データフィールド８には、証明機関に関連付けられた秘密鍵を利用して証明機関によって生成されたデジタル署名を含めることができる。一部の実施形態において、デジタル署名は、データフィールド１～７（または証明書のデータフィールドの任意の適切な組み合わせ）のそれぞれに関連し得る。非限定的な例として、データフィールド１～７は、任意の適切なハッシュアルゴリズムを使用してハッシュ化することができ、結果として得られるハッシュ値は、証明機関の秘密鍵と共に、スイートインジケータ（例えば、データフィールド３）に対応する暗号アルゴリズム（例えば、楕円曲線暗号アルゴリズム）への入力として利用することができる。結果として得られる値は、証明書のデジタル署名としてデータフィールド８に格納され得る。

図２に戻ると、生成されたデジタル証明書およびユーザデバイス１０２に関連付けられた秘密鍵は、ステップ６でユーザデバイス１０２に提供され得る。ステップ７で、ユーザデバイス１０２は、デジタル証明書および秘密鍵を後で使用するためにローカルメモリに格納してもよい。

ステップ８で、ユーザデバイス１０２のユーザ（例えば、図１のユーザ１０３）は、ユーザデバイス１０２の任意の適切なユーザインターフェース（例えば、アプリケーション１１６によって提供されるユーザインターフェース）を利用して、機密データの任意の適切な部分を入力してもよい。一例として、ユーザは、デビットカード／クレジットカード番号、有効期限、および／または関連するＣＶＶコードなどの支払データ（例えば、機密データの例）を入力することができる。実施形態によっては、ユーザデバイス１０２のカメラを利用して、デビットカードおよび／またはクレジットカードの画像を取り込んでもよく、支払データを、任意の適切な画像認識技術を利用して画像から抽出してもよい。この文脈において、「支払データ」は、ＩＳＯ ７８１３に定義されるトラック２等価データの任意の適切な部分を含み得る。支払データ（および／またはユーザが入力した任意の適切な機密データ部分）は、ユーザデバイス１０２のローカルメモリに格納され得る。

図４は、一部の実施形態による、オフライン認証を実施する機密データを安全に伝達するための方法４００のフローチャートを示す。方法４００は、図２の方法２００を実施することに続いて、任意の適切な時間に実施され得る。

方法４００は、４０２で開始されてもよく、ユーザデバイス１０２は、視覚および／または音声コード（例えば、図１のＱＲコード（登録商標）１１４、図１の音声１１５など）を生成してもよい。一部の実施形態において、生成されたコードは、ユーザデバイス１０２のローカルメモリに格納された機密データの少なくとも一部分を含む／埋め込まれてもよい。一例として、方法２００のステップ８を実施することによって、機密データはローカルメモリに格納され得る。機密データは、ＩＳＯ ７８１３に定義される任意の適切なトラック２等価データおよび／またはユーザに関連する任意の適切なデータを含み得る。図５は、一部の実施形態による、生成されたコードのための例示的なデータ仕様書５００を示す。

一部の実施形態では、生成されたコードは、データ仕様書５００に含まれるデータフィールドの任意の適切な組み合わせを含み得る。特定のデータサイズは、データ仕様書５００の各データフィールドに示され得るが、これらのサイズは変化し得ることが理解されるべきである。

一部の実施形態では、生成されたコードは、ペイロードフォーマットインジケータを含みうる。ペイロードフォーマットインジケータは、タグ「８５」（または任意の適切な識別子）で識別されてもよく、および／または生成されたコードのバージョンを定義してもよい。一例として、生成されたコードがＱＲコード（登録商標）である場合、ＱＲコード（登録商標）のバージョンは、ペイロードフォーマットインジケータ（例えば、値「ＣＰＶ０１」）を使用して示され得る。生成されたコードが音声形式である場合、生成されたコードのバージョンは、異なるペイロードフォーマットインジケータを使用して示される場合がある。一部の実施形態において、生成されたコードの複数のバージョンを採用してもよい。したがって、ペイロードフォーマットインジケータは、コードのフォーマットを決定するために、受信デバイス（例えば、図１のアクセスデバイス１１８）によって利用されてもよい。

一部の実施形態では、データ仕様書５００によって提供されるように、生成されたコードは、アプリケーションテンプレートを含んでもよい。アプリケーションテンプレートは、タグ「６１」（または任意の適切な識別子）で識別されてもよく、アプリケーション固有のデータのコンテナとして利用されてもよい。例として、アプリケーションテンプレートデータフィールドは、アプリケーション名フィールドなどの一つ以上のサブフィールドを含み得る。一部の実施形態では、アプリケーション名フィールドは、タグ「４Ｆ」（または任意の適切な識別子）で識別され得る。実施形態によっては、アプリケーション名フィールドは、データ仕様書５００に含まれるデータを処理および／または生成しうるアプリケーションのタイプおよび／または名前を識別し得る。

一部の実施形態において、データ仕様書５００によって提供されるように、生成されたコードは、共通データテンプレート（例えば、データ仕様書５００の一部分）を含み得る。共通データテンプレートは、タグ「６２」（または任意の好適な識別子）で識別されてもよく、様々なタイプのアプリケーションにわたって共通であり得るアプリケーションデータのコンテナとして利用されてもよい。一例として、共通データテンプレートは、トラック２等価データフィールド、アプリケーション交換プロファイルデータフィールド、アプリケーションデータフィールド、アプリケーションクリプトグラムデータフィールド、一つ以上のタイムスタンプデータフィールド、証明機関の公開鍵インデックス、公開鍵証明書データフィールド、およびデジタル署名データフィールドなどの一つ以上のサブフィールドを含み得る。

トラック２等価データフィールドは、「５７」（または別の適切な識別子）のタグで識別され得る。トラック２等価データフィールドは、ＩＳＯ７８１３に定義される任意のトラック２データを含み得る。一例として、トラック２等価データには、個人アカウント番号（ＰＡＮ）、および有効期限、ＣＶＶコード、取引カウンターなどが含まれ得る。一部の実施形態では、トラック２等価データフィールドは、いくつかの所定のサイズ（例えば、１９バイト）までサイズを変化させてもよい。

共通データテンプレートのアプリケーション交換プロファイルデータフィールドは、「８２」（または別の適切な識別子）のタグで識別され得る。アプリケーションデータフィールドは、共通データテンプレートに含めることもできる。アプリケーションデータフィールドは、「９Ｆ１０」（または別の適切な識別子）のタグで識別され得る。アプリケーション交換プロファイルデータフィールドおよび／またはアプリケーションデータフィールドはそれぞれ、承認事業体（例えば、図１の承認事業体コンピュータ１１０）および／または中央サーバコンピュータ（例えば、図１の中央サーバコンピュータ１０８）用のデータをそれぞれ含み得る。これらの各フィールドは、サイズが異なる場合がある。例えば、アプリケーション交換プロファイルデータフィールドは、２バイトの長さであってもよく、一方、アプリケーションデータフィールドは、所定のサイズ（例えば、３２バイト）までサイズを変化させてもよい。

共通データテンプレートのアプリケーションクリプトグラムは、「９Ｆ２６」（または別の適切な識別子）のタグで識別されうる。一部の実施形態において、クリプトグラム値は、特定のコードを識別するためにユーザデバイスによって生成されてもよい。クリプトグラムは、生成されたコードに対して固有であってよい。一部の実施形態において、クリプトグラムは、任意の好適なサイズ（例えば、最大８バイト）であってもよい。

共通データテンプレートは、一つ以上のタイムスタンプデータフィールドを含んでもよい。たとえば、タイムスタンプデータは二つのデータフィールドに格納できる。これらのデータフィールドのそれぞれは、それぞれタグ「９Ｆ３６」および「９Ｆ２７」（またはその他の適切な識別子）で識別され得る。これら二つのデータフィールドの結合データには、コードが生成された日付および／または時刻が含まれている場合がある。一部の実施形態では、単一のデータフィールドを利用して、かかるタイムスタンプデータを格納してもよい。

共通データテンプレートには、証明機関の公開鍵インデックスデータフィールドを含めることができる。このデータフィールドは、タグ「８Ｆ」（または別の適切な識別子）で識別され得る。証明機関の公開鍵インデックスには、公開鍵証明書フィールドに含まれる公開鍵証明書を生成する証明機関を識別する値を含めることができる。実施形態によっては、証明機関の公開鍵インデックスをこのデータフィールドから取得し、証明機関に対応する特定の公開鍵を識別するために利用してもよい。

共通データテンプレートには、公開鍵証明書データフィールドを含めることができる。このデータフィールドは、タグ「９Ｆ４６」（または別の適切な識別子）によって識別され得る。一部の実施形態では、公開鍵証明書データフィールドは、デジタル証明書（例えば、図３の証明書の仕様書３００に従って書式を設定されたデジタル証明書）を含んでもよい。公開鍵証明書データフィールドは、特定のデバイス（または特定のユーザおよび／またはアカウント）に関連付けられた公開鍵証明書に対応する図３のデータフィールドの任意の適切な組み合わせを含むため任意の適切なサイズであってもよい。

共通データテンプレートは、デジタル署名データフィールドをさらに含み得る。このデータフィールドは、タグ「９Ｆ４Ｂ」（または任意の適切な識別子）によって識別され得る。デジタル署名データフィールドは、コードの一つ以上の他のデータフィールドのデジタル署名に対応する値を含み得る。例として、ユーザデバイスは、図５で論じる他のデータフィールドの値のすべて（または一部）をハッシュ化して、ハッシュ化された値を生成するように構成され得る。その後、ユーザデバイスは、秘密鍵および暗号アルゴリズム（例えば、楕円曲線暗号アルゴリズム）を利用して、デジタル署名値を生成してもよい。この値は、後続の検証プロセスのためにデジタル署名データフィールドに格納することができる。

図４に戻ると、ステップ４０２で、ユーザデバイス１０２は、機密データ（例えば、図５のデータ仕様書５００のデータフィールドに対応する機密データ）からコードを生成し得る。機密データは、デバイスのローカルメモリから収集され得る。一部の実施形態では、ユーザデバイス１０２は、少なくとも一部の機密データを生成してもよい。一例として、ユーザデバイス１０２は、機密データの任意の適切な数のデータフィールドをハッシュ化し得る（例えば、トラック２等価データフィールド、アプリケーション交換プロファイルデータフィールド、アプリケーションデータフィールド、および一つ以上のタイムスタンプデータフィールドに対応する図５に示される網掛けのフィールド）。ハッシュ値およびユーザデバイス１０２の秘密鍵（ローカルメモリに格納される）は、デジタル署名を生成するために暗号アルゴリズムで利用され得る。このデジタル署名は、コードに変換および／またはコード生成に利用される前に、機密データに含まれる場合がある。実施形態によっては、このコードは、クイックレスポンス（ＱＲ）コードなど、視覚的であってもよい。一部の実施形態では、データ仕様書５００に関連して考察されるデータは、任意の適切なプロセスを利用してＱＲコード（登録商標）に変換されてもよい。

変換／コード生成プロセスの非限定的な例として、データ仕様書５００に示されるデータ（例えば、機密データ）は、ベース６４符号化ストリング（例えば、ＲＦＣ ４６４８に定義される通り）に変換され、次いでＩＳＯ １８００４準拠のＱＲコード（登録商標）記号に変換されてもよい。一部の実施形態では、この変換は、デフォルトの拡張チャネル解釈およびバイトモードを利用してもよい。この変換では、さらに、誤り訂正レベルＬ、Ｍ、Ｑ、またはＨ、およびＩＳＯ １８００４に定義されるｐの値を利用することができる。一部の実施形態では、変換は、データ仕様書５００（またはむしろ変換される実際のデータ）に示されるデータに適応することになる最小ＱＲコード（登録商標）バージョンを決定し得る。データマスキングは、ＩＳＯ １８００４で定義されているように、この変換中に実行されてもよく、ＩＳＯ １８００４に従って、通常の配向および通常の反射配置が利用されてもよい。

一部の実施形態では、視覚的コード（または視覚コードに加えて）ではなく、ユーザデバイス１０２は、音声コードを生成してもよい。非限定的な例として、ユーザデバイス１０２は、任意の適切な周波数シフトキーイング（ＦＳＫ）および／または周波数変調方式を利用して、機密データを音声に変換してもよい。ＦＳＫおよび／または周波数変調は、デジタルデータが、音声トーンの周波数（またはピッチ）の変化によって表され得る技術を指すことが意図される。このデジタルデータは、音声として送信され、これらのピッチ変更／変調の解釈を通して埋め込まれたデータが抽出される。

４０４では、生成されたコードは、ユーザデバイスのＩ／Ｏデバイスに提供され得る。生成されたコードが視覚コード（例えば、機密データを埋め込むＱＲコード（登録商標））である場合、生成されたコードは、ユーザデバイス１０２のディスプレイに提供され得る。生成されたコードが音声コード（例えば、機密データを埋め込む音声）である場合、生成されたコードは、ユーザデバイス１０２のスピーカを介して提示され得る。一部の実施形態では、ユーザデバイス１０２は、視覚コードおよび音声コードを生成し、ユーザデバイス１０２のそれぞれディスプレイおよびスピーカを介して、生成されたコードのそれぞれを提示し得る。

４０６で、コードは、アクセスデバイス１１８によって取得され得る。一例として、アクセスデバイス１１８は、バーコードリーダ、スキャナ、カメラ、または視覚コード（例えば、図１のＱＲコード（登録商標）１１４）を取り込むように構成される任意の適切な入力／出力（Ｉ／Ｏ）デバイスを含んでもよい。一部の実施形態では、この視覚コードは、ユーザデバイス１０２のディスプレイで提示され、アクセスデバイス１１８のＩ／Ｏデバイスによって読み取られてもよい。一部の実施形態では、アクセスデバイス１１８は、マイクロフォンまたは音声コード（例えば、図１の音声１１５）を取り込む用に構成される別の適切なＩ／Ｏデバイスを含んでもよい。一旦取得されると、コード（または複数のコード）は、所定の方式に従って変換され得る。一例として、ＱＲコード（登録商標）をバイナリデータに変換して、埋め込まれた機密データを抽出することができる。コードが音声の形態である場合、音声の様々な変調は、埋め込まれた機密データを抽出するための所定の方式に従って解釈され得る。

４０８で、アクセスデバイス１１８は、コードから抽出されたデータを検証してもよい。一部の実施形態では、アクセスデバイス１１８は、コードから抽出された機密データから証明書公開鍵インデックス値を取得してもよい。アクセスデバイス１１８は、取得した証明書公開鍵インデックス値を利用して、証明書公開鍵インデックス値に関連付けられた公開鍵についてルックアップを実施および／または検索することができる。アクセスデバイス１１８は、それぞれが異なる証明機関と関連付けられる、複数の公開鍵を潜在的に格納し得る。証明書の公開鍵インデックス値を利用すると、認証する証明機関（例えば、抽出された機密データに含まれる公開鍵証明書の生成で信用されている証明機関）に関連付けられた正しい公開鍵が確実に使用されるようにできる。ＣＡ公開鍵が取得されると、暗号アルゴリズム（例えば、楕円曲線暗号アルゴリズム）を使用して、機密の公開鍵証明書が変更されていないことを検証することができる。例として、ＣＡ公開鍵および証明書のデジタル署名（例えば、図３のデータフィールド８）は、暗号アルゴリズムへの入力として提供されてもよい。一部の実施形態では、使用される特定の暗号アルゴリズムは、証明書で指定され得る。例えば、図３のデータフィールド３は、証明書のデジタル署名を検証するために利用される特定のアルゴリズムスイートを明確にしてもよい。上述の入力を前提にすると、暗号アルゴリズムは結果として得られた値を出力し得る。アクセスデバイス１１８は、所定の方式に従って、デジタル証明書の一つ以上のデータフィールド（例えば、図３のデータフィールド１～７）をハッシュ化して、ハッシュ値を計算してもよい。計算ハッシュ値が暗号アルゴリズムから取得した結果として得られた値と一致する場合、証明書は有効（例えば、変更されてない）と見なされてよい。計算されたハッシュ値が結果として得られた値と一致しない場合、証明書は無効（例えば、変更されてない）と見なされることがある。証明書が無効である場合、アクセスデバイス１１８は、ユーザデバイス１０２へのアクセスを拒否し、処理を終了し得る。

証明書が有効であると判定された場合、アクセスデバイス１１８は、ユーザデバイス１０２に関連付けられた公開鍵（例えば、データフィールド７）を証明書から抽出してもよい。ユーザデバイス１０２に関連付けられた取得した公開鍵を使用して、アクセスデバイス１１８は、機密データを検証してもよい。例えば、ユーザデバイス１０２に関連付けられた公開鍵、機密データに含まれるデジタル署名、および／または機密データの任意の適切な部分を利用して、機密データを検証してもよい（例えば、機密データが変更されたかどうかを判定するために）。非限定的な例として、ユーザデバイス１０２およびデジタル署名に関連付けられた公開鍵は、結果として得られた値を得るために、暗号アルゴリズム（例えば、上記で利用された同じまたは異なる暗号アルゴリズム）への入力として提供されてもよい。データフィールドの所定の組み合わせ（例えば、トラック２等価データフィールド、アプリケーション交換プロファイルデータフィールド、アプリケーションデータフィールド、および一つ以上のタイムスタンプデータフィールドに対応する図５の網掛けデータフィールド）は、アクセスデバイス１１８によってハッシュ化されて、計算されたハッシュ値を生成し、計算されたハッシュ値を結果として得られた値と比較することができる。値が一致する場合、アクセスデバイス１１８は、コードから抽出された機密データが有効（例えば、変更されてない）と判定するように構成され得る。値が一致しない場合、アクセスデバイス１１８は、アクセスを拒否し、処理を終了するように構成され得る。

４１０で、アクセスデバイス１１８は、（任意に）タイミング制約を処理してもよい。一例として、有効なコード（例えば、視覚コードまたは音声コード）は、アクセス要求の所定の期間内に生成されなければならないことが予め決められてもよい。すなわち、コードが有効になるように、アクセスデバイス１１８がコードを取得および／または処理する前の１０分、５分、３０秒以内にコードを生成しなければならないことが予め決められてもよい。したがって、アクセスデバイス１１８は、現在の時間を、機密データの一つ以上のタイムスタンプデータフィールドによって示される時間と比較するように構成され得る。一部の実施形態では、上述のように、機密データの一つ以上のタイムスタンプデータフィールドは、コードが生成された日および／または時間を示し得る。当然のことながら、一部の実施形態では、一つのタイムスタンプデータフィールドは、日を示してもよく、別のタイムスタンプデータフィールドは、時間を示してもよい。一部の実施形態では、二つのタイムスタンプデータフィールドの組み合わせは、コードが生成された日および／または時間を識別するために利用されてもよい。比較により、コードが割り当てられた期間外（例えば、現在の時間の１０分以上前）に生成されたことを示す場合、アクセスデバイス１１８は、アクセスを拒否し、処理を終了するように構成され得る。比較が、コードが割り当てられた期間内（例えば、現在の時間の１０分前以内）に生成されたことを示す場合、アクセスデバイス１１８はさらなる動作を実行し得る。

タイミング制約を処理する代わりに、またはそれに加えて、アクセスデバイス１１８は、４１２で制限を処理するように構成され得る。一部の実施形態では、アクセスデバイス１１８は、アクセスが拒否される識別子に対応する制限された識別子のリストを維持し得る。一部の実施形態では、アクセスデバイス１１８は、機密データ（例えば、トラック２等価データフィールドに含まれるアカウント識別子）から任意の適切な識別子を抽出してもよい。抽出された識別子は、制限された識別子のリストと比較され得る。抽出された識別子がリスト上の識別子と一致する場合、アクセスデバイス１１８は、アクセスを拒否し、処理を終了することができる。抽出された識別子がリスト上の識別子のいずれとも一致しない場合、アクセスデバイス１１８はさらなる動作を実行し得る。

４１４では、アクセスデバイス１１８は、４０８～４１２の動作の任意の適切な組み合わせに基づいて、ユーザデバイス１０２へのアクセスを許可または拒否するように構成され得る。例えば、機密データが無効であると判定された場合、および／またはコードが古い（例えば、割り当てられた期間よりも古い）と判定された場合、および／または機密データに含まれる識別子が制限された識別子と一致する場合、アクセスデバイス１１８は、ユーザデバイス１０２へのアクセスを拒否するように構成されてもよい。機密データが有効である場合、コードは適時に生成され（タイミング制約が強制された場合）、機密データに含まれる識別子が制限されたリスト上に（制限されたリストが用いられる場合）表示されない場合、アクセスデバイス１１８は、アクセスを許可するように構成され得る。

一部の実施形態では、アクセスデバイス１１８は、オンライン取引をサポートしてもよい。これらの実施形態では、アクセスデバイス１１８は、４１６で承認要求メッセージを、承認事業体コンピュータ１１０に（例えば、図１の転送コンピュータ１０６および／または中央サーバコンピュータ１０８を介して）送信してもよい。承認要求メッセージは、機密データの任意の適切な部分でありうる。実施形態によっては、承認要求メッセージは、許可されたアクセスに対する支払に対応する金額を含み得る。承認事業体コンピュータ１１０は、データを４１８で処理して、任意の適切な時間にアクセスデバイス１１８に返され得る承認応答メッセージを生成してもよい。このプロセスは、図７に関連してさらに深く論じられ得る。

図６は、一部の実施形態による、オフライン認証を実施するための方法のフローチャートを示す。方法６００は、コンピューティングデバイス（例えば、図１のアクセスデバイス１１８）によって実施されてもよい。コンピューティングデバイスは、一つ以上のプロセッサと、コンピュータ実行可能命令を格納する一つ以上のメモリとを備えてもよく、一つ以上のプロセッサによりコンピュータ実行可能命令を実行することによって、コンピューティングデバイスに方法６００を実施させる。図６に示し以下に記載されるステップは、図１の取引処理の説明およびその対応する説明と併せて使用することができる。それらの説明は、参照により本明細書に組み込まれる。

方法６００は、ブロック６０２で開始されてもよく、ここで、証明機関（例えば、証明機関として部分的に動作している図１の中央サーバコンピュータ１０８）と関連付けられる第一の公開鍵を受信してもよい。一部の実施形態では、第一の公開鍵は、任意の適切な方法で（例えば、図２の方法２００により）証明機関によって配布され得る。

方法６００の残りのステップは、オフラインモードで動作している間、アクセスデバイス１１８によって実施されてもよい。一部の実施形態では、アクセスデバイス１１８は、その処理を実施するためにリモートデバイス（例えば、リソースプロバイダコンピュータ、転送コンピュータ、中央サーバコンピュータ、承認事業体コンピュータなど）と通信しない場合、オフラインモードで動作してその処理を実施することができる。

方法は、ユーザデバイス（例えば、図１のユーザデバイス１０２）からデータパケットを一方向通信で取得することができる６０４に進むことができる。データパケットは、機密データの任意の適切な部分を含んでもよく、視覚および／または音声コードの形態であってもよい。一例として、データパケットは、図５のデータ仕様書５００のデータフィールドを含んでもよく、ＱＲコード（登録商標）、音声、または任意の適切な視覚および／または音声コードの形態であってもよい。

６０６で、データパケットは、対話データ（例えば、データパケットに含まれる機密データ、図５のデータ仕様書５００に指定されるデータフィールド）を取得するため変換されてもよい。例えば、データパケットは、証明機関（例えば、中央サーバコンピュータ１０８）によって認証された少なくともデジタル証明書と、ユーザデバイス（例えば、ユーザデバイス１０２）によって生成されるデジタル署名値とを備えてもよい。

６０８では、ユーザデバイス（例えば、ユーザデバイス１０２）に関連付けられた第二の公開鍵は、証明機関に関連付けられたデジタル証明書および第一の公開鍵を利用して取得され得る。一例として、データパケットに含まれる証明書は、図４の４０６に記載されるものと同様の方法で検証されてもよい。デジタル証明書の第一の公開鍵およびデジタル署名は、結果として得られる値を得るために暗号アルゴリズムに入力され得る。証明書の対応するデータフィールドをハッシュ化して、ハッシュ値を生成できる。結果として得られる値がハッシュ値と一致する場合、証明書は有効（例えば、変更されていない）と見なされ得る。有効な場合、アクセスデバイスは、ユーザデバイスに関連づけられた第二の公開鍵を証明書から取得するように構成できる。

６１０で、アクセスデバイスは、ユーザデバイスに関連付けられたデジタル署名値および第二の公開鍵に少なくとも部分的に基づいて、対話データの有効性を判定し得る。上述のように、図４の４０６に関連して、データパケットに含まれる第二の公開鍵およびデジタル署名値も、結果として得られる値を生成するために暗号アルゴリズムに提供され得る。データパケットの一つ以上のデータフィールドもハッシュ化されて、ハッシュ値を生成してもよい。結果として得られる値がハッシュ値と一致する場合、データパケットは有効であると判定され得る。結果として得られる値がハズの値と一致しない場合、データパケットは無効であると判定されてもよく、これ以上の処理は行われなくてよい。

６１２で、対話データが有効であると判定されるとき、アクセスデバイスは、対話データの識別子を承認するように構成され得る。一例として、アカウント識別子などの識別子は、対話データ（例えば、変換されたデータパケットデータ）から取得されてもよい。アクセスデバイスは、制限された識別子のリストを維持してもよい。制限された識別子のリストでアカウント識別子が見つかった場合、アクセスデバイスはアクセスを拒否し、処理を終了するように構成され得る。

６１４で、アクセスは、対話データの識別子が承認されている（例えば、アカウント識別子が制限された識別子のリスト上にない）と判定することに少なくとも部分的に基づいて、アクセスデバイスによって提供されてもよい。

図７は、取引処理システム７００のブロック図を示す。図７は、ユーザデバイス７１０（例えば、図１～６のユーザデバイス１０２の一例）を操作できるユーザ７０６（例えば、図１ユーザ１０３）を示す。ユーザ７０６は、ユーザデバイス７１０を使用して、小売業者などのリソースプロバイダでチケットなどの物品またはサービスに対して支払うことができる。小売業者は、リソースプロバイダコンピュータ７３０および／またはアクセスデバイス７２０（例えば、図１～６のアクセスデバイス１１８の例）を操作することができる。小売業者は、支払処理ネットワークの一部として動作するアクワイアラ及び処理ネットワークコンピュータ７５０（例えば、図１の中央サーバコンピュータ１０８の一例）によって操作される転送コンピュータ７４０（例えば、輸送コンピュータ１０６）を介して、発行者によって操作される承認事業体コンピュータ７６０（例えば、図１の承認事業体コンピュータ１１０）と通信してもよい。

支払処理ネットワークは、データ処理サブシステム、ネットワーク、および認証サービス、例外ファイルサービス、ならびに清算および決済サービスをサポートし配信するのに使用される操作を含んでいてもよい。例示的な支払処理ネットワークは、ＶｉｓａＮｅｔ（商標）を含んでいてもよい。ＶｉｓａＮｅｔ（商標）などの支払処理ネットワークは、クレジットカード取引、デビットカード取引、および他のタイプの商取引を処理することができる。具体的には、ＶｉｓａＮｅｔ（商標）には、承認要求を処理するＶＩＰシステム（Ｖｉｓａ Ｉｎｔｅｇｒａｔｅｄ Ｐａｙｍｅｎｔシステム）と、清算および決済サービスを実施するＢａｓｅ ＩＩシステムが含まれる。支払処理ネットワークは、インターネットを含む、任意の好適な有線または無線ネットワークを使用することができる。

アクセスデバイス７２０（例えば、交通機関の改札口）でユーザデバイス７１０を使用する典型的な支払い取引フローを、以下のように説明することができる。ユーザデバイス７１０およびアクセスデバイス７２０は、上述のように、方法４００のステップを実施することができる。ユーザデバイス７１０がアクセスを許可される場合、アクセスデバイス７２０によって取引メッセージが生成され、許可されたアクセスに関連付けられた支払を進行することができる。一部の実施形態では、アクセスデバイス７２０によって生成される取引メッセージは、アクセスが許可された機密データの任意の適切な部分などの任意の適切なデータを含み得る。一例として、取引メッセージは、ユーザデバイス７１０によって生成され、アクセスデバイス７２０によって取得されるコードに示されるトラック２データを含み得る。取引メッセージは、許可されたアクセスに対応する金額（例えば、支払価格）をさらに示し得る。

リソースプロバイダコンピュータ７３０は、この情報を外部の通信インターフェースを介してアクセスデバイス７２０から受信することができる。リソースプロバイダコンピュータ７３０は、アクセスデバイス７２０から受信した情報の少なくとも一部を含む承認要求メッセージを生成し、このメッセージを転送コンピュータ４１０に電子送信することができる。転送コンピュータ７４０は、承認要求メッセージを受信し、処理し、および承認のために、処理ネットワークコンピュータ７５０に転送することができる。

一般に、クレジットカードまたはデビットカードの取引の発生に先立ち、処理ネットワークコンピュータ７５０は、発行者の取引がどのように承認されるべきかについて、各発行者との確立したプロトコルを有する。取引額が閾値未満であるときなどの場合には、処理ネットワークコンピュータ７５０は、承認要求メッセージを生成して承認事業体コンピュータ７６０に送信することなしに、ユーザのアカウントに関して有する情報に基づいて取引を承認するように構成され得る。取引額が閾値より大きいときなどの他の場合では、処理ネットワークコンピュータ７５０は、承認要求メッセージを受信し、ユーザデバイス７１０に関連付けられた発行者を決定し、ならびに検証および承認用に取引用の承認要求メッセージを承認事業体コンピュータ７６０に転送することができる。取引が承認されると、承認事業体コンピュータ７６０は、（取引が承認または拒否されたことを示す承認コードを含み得る）承認応答メッセージを生成し、この電子メッセージを外部の通信インターフェースを介して処理ネットワークコンピュータ７５０に送信することができる。次いで、処理ネットワークコンピュータ７５０は、承認応答メッセージを、転送コンピュータ７４０に転送することができ、転送コンピュータ７４０は、承認指示を含む電子メッセージをリソースプロバイダコンピュータ７３０に、続いてアクセスデバイス７２０に送信することができる。

一日の終わりに、または他の好適な時間間隔で、リソースプロバイダコンピュータ７３０と、転送コンピュータ７４０と、処理ネットワークコンピュータ７５０と／または承認事業体コンピュータ７６０との間の清算および決済処理が、取引に対して行われ得る。

図８は、建物アクセスシステム８００のブロック図を示す。図８は、ユーザ８０６（例えば、図１のユーザ１０３）が操作するユーザデバイス８１０（例えば、図１のユーザデバイス１０２）を示す。ユーザデバイス８１０は、アクセスデバイス８２０（例えば、上記の図のアクセスデバイス１１８の一例）と対話し、図 ４の方法４００に関連して上述されたようにコードの形態（例えば、視覚および／または音声コード）で機密データを渡すことができる。アクセスデバイス８２０は、マイクロフォン、スキャナ、撮像デバイス、または同類のものを介してユーザデバイス８１０から機密データを取得するように構成され得る。アクセスデバイス８２０は、上述の方法でコードを変換することによって、機密データを抽出してもよい。機密データは、ユーザデバイス８１０に関連付けられ、証明機関によって認証されたデジタル証明書を含んでもよく、そのＩＤは、機密データで（例えば、ＣＡ公開鍵インデックスを介して）示されてもよい。証明機関と関連付けられ、アクセスデバイス８２０のローカルメモリに格納された公開鍵を取得および利用することによって、アクセスデバイス８２０は、機密データに含まれるデジタル証明書から、ユーザデバイス８１０に関連付けられた公開鍵を取得してもよい。ユーザデバイス８１０に関連付けられた公開鍵は、機密データが有効であるかどうか（例えば、変更されていない）を判定するために利用され得る。例えば、ユーザデバイス８１０によって生成され、機密データに含まれるデジタル署名値は、ユーザデバイス８１０と暗号アルゴリズム（例えば、楕円曲線暗号アルゴリズム）と関連付けられた公開鍵を利用して抽出されてもよい。機密データの多数の所定のデータフィールドをハッシュ化することができ、そのハッシュ値を抽出したデジタル署名値と比較することができる。値が一致する場合、アクセスデバイス８２０は、機密データが有効（例えば、変更されていない）と判定するように構成され得る。値が一致しない場合、アクセスデバイス８２０は、機密データが無効である（例えば、変更された）と判定するように構成され得る。データが無効である場合、アクセスデバイス８２０は、建物８３０へのアクセスを拒否し得る。データが有効な場合、アクセスデバイス８２０は、建物８３０へのアクセスを許可するか、またはさらなる処理を実施してもよい。

一部の実施形態では、データが有効であると判定されたとしても、アクセスデバイス８２０は、追加の処理を実施するように構成され得る。例えば、機密データのタイムスタンプデータは、機密データを含むコードがユーザデバイス８１０によって生成された日付および／または時間を判定するために利用され得る。コード生成の日付および／または時刻が、現在の時間よりも前の所定の期間よりも大きい場合、アクセスデバイス８２０は、建物８３０へのアクセスを拒否し得る。コード生成のデータおよび／または時間が、現在の時間より前の所定の期間である場合、アクセスデバイス８２０は、建物８３０へのアクセスを許可してもよく、またはさらなる処理を実施してもよい。例えば、タイミング処理の代わりに、または上述のタイミング処理に加えて、アクセスデバイス８２０は、機密データに含まれる識別子を制限された識別子のリストに対してチェックするように構成され得る。制限された識別子のリストには、アクセスが拒否されるすべての識別子を含めることができる。一部の実施形態では、アクセスデバイス８２０が、機密データに含まれる識別子が制限された識別子のリストに含まれていないと判定した場合、アクセスデバイス８２０は、建物８３０へのアクセスを許可し得る。しかしながら、機密データに含まれる識別子も制限された識別子のリストに含まれる場合、アクセスデバイス８２０は、ユーザ８０６の建物８３０へのアクセスを拒否してもよい。


技術面の改善

本明細書に記載される技術を利用することによって、機密データを伝達するためのより安全な方法が可能になる。機密データは、不正行為者の目や耳からこのようなデータを保護するために、視覚および／または音声コードに埋め込まれる場合がある。追加で、機密データは、受信デバイスのリーダおよび／またはマイクロフォンを介して直接通信され、データが傍受され、変更または盗まれる可能性を低減する。ここで説明する技術を利用することによって、従来の技術に関して同じレベルのセキュリティを確保しつつ、機密データの全体的なデータフットプリントを削減することができる。このデータの通信を通して、ユーザおよび／またはユーザデバイスに関するサーバから追加のデータを取得することなく、最小限の時間で、ユーザが受信デバイスで認証されることを可能にするオフライン認証の方法が有効化される。

本明細書に記載されるコンピューティングデバイスのいずれもが、上記の事業体または構成要素のいずれかを実装するために使用され得る、コンピュータシステムの例であってもよい。こうしたコンピュータシステムのサブシステムは、システムバスを介して相互接続されてもよい。追加のサブシステムには、プリンタ、キーボード、記憶デバイス、およびディスプレイアダプタに結合されるモニタが含まれる。入出力（Ｉ／Ｏ）コントローラに結合する、周辺デバイスおよびＩ／Ｏデバイスは、シリアルポートなどの当技術分野で既知の任意の数の手段によって、コンピュータシステムに接続することができる。例えば、Ｉ／Ｏポートまたは外部インターフェースを使用して、インターネットなどの広域ネットワーク、マウス入力デバイス、またはスキャナに、コンピュータ装置を接続できる。システムバスを介した相互接続により、中央プロセッサが、各サブシステムと通信し、サブシステム間の情報の交換だけでなく、システムメモリまたは記憶デバイスからの命令の実行を制御することが可能になり得る。システムメモリおよび／または記憶デバイスは、コンピュータ可読媒体を具現化してもよい。

記載のように、本発明のサービスは、一つ以上の機能、プロセス、動作、または方法ステップを実装することを伴い得る。一部の実施形態では、機能、プロセス、動作、または方法ステップは、好適にプログラムされたコンピューティングデバイス、マイクロプロセッサ、データプロセッサなどによる一組の命令またはソフトウェアコードの実行の結果として実装されてもよい。命令またはソフトウェアコードのセットは、コンピューティングデバイス、マイクロプロセッサなどによってアクセスされるメモリ、または他の形態のデータ記憶要素に格納されてもよい。他の実施形態では、機能、プロセス、動作、または方法ステップは、ファームウェアまたは専用のプロセッサ、集積回路によって実装されてもよい。

本出願に記載のソフトウェアコンポーネントまたは機能のいずれかは、例えば、従来の技術もしくはオブジェクト指向の技術を使った、例えば、Ｊａｖａ、Ｃ＋＋、またはＰｅｒｌなどの任意の好適なコンピュータ言語を使用する、プロセッサによって実行されるソフトウェアコードとして実施されてもよい。ソフトウェアコードは、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、ハードドライブもしくはフロッピーディスクなどの磁気媒体、またはＣＤ－ＲＯＭのような光媒体などの、コンピュータ可読媒体上の一連の命令またはコマンドとして格納されてもよい。そのようなコンピュータ可読媒体は、単一の計算装置上またはその内部にあってもよく、システムまたはネットワーク内の異なる計算装置上もしくはその内部に存在し得る。

上の記載は例示であり、限定するものではない。本開示を検討すると、本発明の多くの変形が、当業者に対して明らかとなるであろう。そのため、本発明の範囲は、上の記載を参照して判定されるべきではなく、代わりに、係属中の特許請求の範囲を参照して、それらの全範囲または同等物と併せて判定されるべきである。

いずれの実施形態の一つ以上の特徴は、本発明の範囲から逸脱することなく、いずれの他の実施形態の一つ以上の特徴と組み合わせてもよい。

「一つの（ａ）」、「一つの（ａｎ）」、または「その（ｔｈｅ）」の列挙は、特に反対の指示がない限り、「一つ以上」を意味することを意図している。

上で言及したすべての特許、特許出願、刊行物、および記載は、あらゆる目的のためにその全体が参照により本明細書に援用される。いずれも先行技術と認められない。

Claims (20)

1. オフライン認証を実施するためのコンピュータ実装方法であって、
   アクセスデバイスで、証明機関に関連付けられた第一の公開鍵を受信することと、
   オフラインモードで動作している間、
   一方向通信から前記アクセスデバイスによって、ユーザデバイスからデータパケットを取得することと、
   前記アクセスデバイスで、前記証明機関によって認証されたデジタル証明書および前記ユーザデバイスによって生成されたデジタル署名値を含む対話データを取得するため前記データパケットを変換することと、
   前記アクセスデバイスで、前記証明機関に関連付けられた前記デジタル証明書および前記第一の公開鍵を利用して、前記ユーザデバイスに関連付けられた第二の公開鍵を取得することと、
   前記アクセスデバイスで、前記ユーザデバイスに関連付けられた前記デジタル署名値および前記第二の公開鍵に少なくとも部分的に基づいて、前記対話データの有効性を判定することと、
   前記対話データが有効であると判定された場合、前記アクセスデバイスで、前記対話データの識別子を承認することと、
   前記アクセスデバイスによって、前記対話データの前記識別子が承認されているとの判定に少なくとも部分的に基づいてアクセスを提供することと、を含む、方法。
2. 前記データパケットが、前記ユーザデバイスのディスプレイを介して提示されるクイックレスポンス（ＱＲ）コードの形態で取得される、請求項１に記載のコンピュータ実装方法。
3. 前記データパケットが、前記ユーザデバイスのスピーカを介して提示される音声の形態で取得される、請求項１に記載のコンピュータ実装方法。
4. 前記デジタル証明書が、前記アクセスデバイスが前記データパケットを取得する前の閾値期間内に、前記証明機関によって認証されている、請求項１に記載のコンピュータ実装方法。
5. 前記デジタル署名値が、楕円曲線暗号アルゴリズムを利用して生成される、請求項１に記載のコンピュータ実装方法。
6. 前記アクセスデバイスによって、前記対話データの前記識別子が承認されていると判定することに少なくとも部分的に基づいてリソースへのアクセスを提供することが、
   前記アクセスデバイスによって、前記識別子を、格納された制限された識別子のリストと比較することと、
   前記アクセスデバイスによって、前記識別子が前記制限された識別子のリストから除外されると判定することであって、前記リソースへのアクセスを提供することが、前記識別子が前記制限された識別子のリストから除外されると前記判定することに少なくとも部分的に基づく、判定することと、をさらに含む、請求項１に記載のコンピュータ実装方法。
7. 前記アクセスデバイスによって、前記対話データの少なくとも一つのタイムスタンプデータフィールドを抽出することと、
   前記アクセスデバイスによって、前記少なくとも一つのタイムスタンプデータフィールドを現在の時間と比較することであって、前記リソースへのアクセスを提供することが、前記少なくとも一つのタイムスタンプデータフィールドを前記現在の時間と比較することに少なくとも部分的にさらに基づく、比較することと、をさらに含む、請求項１に記載のコンピュータ実装方法。
8. 前記リソースへのアクセスの提供後、前記アクセスデバイスにより、中央サーバコンピュータでオンライン承認要求手順を実施することをさらに含む、請求項１に記載のコンピュータ実装方法。
9. 前記デジタル署名値が、楕円曲線暗号アルゴリズム、前記ユーザデバイスに関連付けられた秘密鍵、および前記対話データの少なくとも一つのタイムスタンプデータフィールド、公開鍵インデックスデータフィールド、および公開鍵証明書を利用して生成される、請求項１に記載のコンピュータ実装方法。
10. 前記アクセスデバイスによって、復号された対話データから証明機関インデックスを取得することと、
    前記アクセスデバイスによって、前記証明機関インデックスに少なくとも部分的に基づく前記証明機関に関連付けられた前記第一の公開鍵を取得することと、をさらに含む、請求項１に記載のコンピュータ実装方法。
11. アクセスデバイスであって、
    一つ以上のプロセッサと、
    コンピュータ実行可能命令を格納する一つ以上のメモリであって、前記一つ以上のプロセッサにより前記コンピュータ実行可能命令を実行することによって、前記アクセスデバイスに、
    証明機関に関連付けられた第一の公開鍵を受信することと、
    オフラインモードで動作している間、
    一方向通信で、ユーザデバイスからデータパケットを受信することと、
    前記データパケットを変換して、前記証明機関によって認証されたデジタル証明書および前記ユーザデバイスによって生成されたデジタル署名値を含む対話データを取得することと、
    前記証明機関に関連付けられた前記デジタル証明書および前記第一の公開鍵を利用して、前記ユーザデバイスに関連付けられた第二の公開鍵を取得することと、
    前記ユーザデバイスに関連付けられた前記デジタル署名値および前記第二の公開鍵に少なくとも部分的に基づいて、前記対話データの有効性を判定することと、
    前記対話データが有効であると判定された場合、前記対話データの識別子を承認することと、
    前記対話データの前記識別子が承認されていると判定することに少なくとも部分的に基づいてアクセスを提供することと、を行わせる、一つ以上のメモリと、を備えるアクセスデバイス。
12. 前記データパケットが、前記ユーザデバイスのディスプレイを介して提示されるクイックレスポンス（ＱＲ）コードの形態で取得される、請求項１１に記載のアクセスデバイス。
13. 前記データパケットが、前記ユーザデバイスのスピーカを介して提示される音声の形態で取得される、請求項１１に記載のアクセスデバイス。
14. 前記デジタル証明書が、前記アクセスデバイスが前記データパケットを取得する前の閾値期間内に、前記証明機関によって認証されている、請求項１１に記載のアクセスデバイス。
15. 前記デジタル署名値が、楕円曲線暗号アルゴリズムを利用して生成される、請求項１１に記載のアクセスデバイス。
16. 前記対話データの前記識別子が承認されていると判定することに少なくとも部分的に基づいて前記リソースへのアクセスを提供することによって、前記アクセスデバイスに、
    前記識別子を、格納された制限された識別子のリストと比較することと、
    前記識別子が前記制限された識別子のリストから除外されると判定することであって、前記リソースへのアクセスを提供することが、前記識別子が前記制限された識別子のリストから除外されると前記判定することに少なくとも部分的に基づいている、判定することと、をさらに行わせる、請求項１１に記載のアクセスデバイス。
17. 前記一つ以上のプロセッサにより前記コンピュータ実行可能命令を実行することによって、前記アクセスデバイスに、
    前記対話データの少なくとも一つのタイムスタンプデータフィールドを抽出することと、
    前記少なくとも一つのタイムスタンプデータフィールドを現在の時間と比較することであって、前記リソースへのアクセスを提供することが、前記少なくとも一つのタイムスタンプデータフィールドを前記現在の時間と比較することにさらに少なくとも部分的に基づく、比較することと、をさらに行わせる、請求項１１に記載のアクセスデバイス。
18. 前記一つ以上のプロセッサにより前記コンピュータ実行可能命令を実行することによって、前記アクセスデバイスに、
    前記リソースへのアクセス提供後に、中央サーバコンピュータでオンライン承認要求手順を実施することをさらに行わせる、請求項１１に記載のアクセスデバイス。
19. 前記デジタル署名値が、楕円曲線暗号アルゴリズム、前記ユーザデバイスに関連付けられた秘密鍵、および少なくとも一つのタイムスタンプデータフィールド、公開鍵インデックスデータフィールド、および前記対話データの公開鍵証明書を利用して生成される、請求項１１に記載のアクセスデバイス。
20. 前記一つ以上のプロセッサにより前記コンピュータ実行可能命令を実行することによって、前記アクセスデバイスに、
    前記復号された対話データから証明機関インデックスを取得することと、
    前記証明機関インデックスに少なくとも部分的に基づく前記証明機関に関連付けられた前記第一の公開鍵を取得することと、をさらに行わせる、請求項１１に記載のアクセスデバイス。

Images