JP2021530053A - トークン状態の同期 - Google Patents

Abstract

アプリケーショントークンを管理するための技法には、第一のサービスプロバイダコンピュータへ通信デバイス上の第一のサービスプロバイダアプリケーションによって、第一のアプリケーショントークンに対する第一の要求を提供すること、第一のサービスプロバイダコンピュータと通信するトークンサービスコンピュータから通信デバイス上のアカウント管理アプリケーションによって、第一のアプリケーショントークンを受信すること、およびアカウント管理アプリケーションのトークンコンテナに、第一のアプリケーショントークンを保存することが含まれ得る。

Description

関連出願の相互参照
本出願は、２０１８年７月３日に出願された米国仮特許出願第６２／６９３，６３１号の優先権を主張するもので、その全体は参照により本明細書に組み込まれる。

リソースにアクセスするためのデジタル手段は、ますます普及している。スマートフォンなどの通信デバイスは、旅行、娯楽、および購入などの相互作用のための様々なアプリケーションで構成され得る。一つの例は、一つまたは複数の支払手段に関連する支払データを保存することができるウォレットアプリケーションである。保存された支払データは、取引を実施するためにウォレットアプリケーションを介して提示され得る。もう一つの例は、チケット発券アプリケーションであり、それにはクイックレスポンス（ＱＲ）コードが保存されている場合があり、このコードは、スキャンしてチケットを旅行やイベントなどに交換できる。

このようなアプリケーションの量が増えるにつれて、アプリケーションの統合はますます困難になる。たとえば、何千もの交通および娯楽プロバイダ、何百ものサードパーティチケットベンダ、何十ものウォレットアプリケーションプロバイダがある可能性がある。ユーザが選択したウォレットプロバイダを使用して、数百または数千もの予想されるチャネルからチケットを購入できるようにするためには、数百または数千のプロバイダはそれぞれ、ウォレットプロバイダそれぞれと通信できるようにする必要がある。

多くのリソースアクセスアプリケーションのもう１つの欠点は、ＱＲコード（登録商標）などのバーコードを使用することであり、ＱＲコードは通常、ユーザが手動で選択する必要があり、アクセスポイントでリーダにスキャンインすることが難しい場合がある。さらに、このようなコードは容易に転送およびコピーされ、プロバイダがその使用に対する管理を維持することを困難にする。

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

一部の実施形態によれば、アプリケーショントークンを管理するためのプロセスには、第一のサービスプロバイダコンピュータへ通信デバイス上の第一のサービスプロバイダアプリケーションによって、第一のアプリケーショントークンに対する第一の要求を提供すること、第一のサービスプロバイダコンピュータと通信するトークンサービスコンピュータから通信デバイス上のアカウント管理アプリケーションによって、第一のアプリケーショントークンを受信すること、および、アカウント管理アプリケーションのトークンコンテナに、第一のアプリケーショントークンを保存することが含まれ得る。

他の実施形態によると、通信デバイスはメモリ、プロセッサ、およびプロセッサによって実行されると、通信デバイス上の第一のサービスプロバイダアプリケーションによって、第一のサービスプロバイダコンピュータへ、第一のアプリケーショントークンに対する第一の要求を提供するステップと、第一のサービスプロバイダコンピュータと通信するトークンサービスコンピュータから通信デバイス上のアカウント管理アプリケーションによって、第一のアプリケーショントークンを受信するステップと、第一のアプリケーショントークンをアカウント管理アプリケーションのトークンコンテナに保存するステップと、を実行する命令を含む非一時的コンピュータ可読媒体を含み得る。

他の実施形態によると、方法は、通信デバイス上のサービスプロバイダアプリケーションからサービスプロバイダコンピュータによって、アプリケーショントークンの要求を受信すること、およびサービスプロバイダコンピュータによって、通信デバイス上のアカウント管理アプリケーション上のトークンコンテナにアプリケーショントークンをプロビジョニングするための、トークンサービスコンピュータへのプロビジョニング要求を送信することを含み得る。

他の実施形態によると、サービスプロバイダコンピュータは、メモリ、プロセッサ、およびプロセッサによって実行されるとき、通信デバイス上のサービスプロバイダアプリケーションから、アプリケーショントークンの要求を受信するステップと、トークンサービスコンピュータにプロビジョニング要求を送信して、通信デバイス上のアカウント管理アプリケーション上のトークンコンテナにアプリケーショントークンをプロビジョニングするステップとを実行する命令を含む非一時的コンピュータ可読媒体を含み得る。

他の実施形態によると、方法は、トークンサービスコンピュータで、通信デバイス上のアカウント管理アプリケーション上のトークンコンテナにアプリケーショントークンをプロビジョニングするプロビジョニング要求を受信することを含んでもよく、通信デバイスは、サービスプロバイダコンピュータに関連付けられたサービスプロバイダアプリケーションも備え、トークンサービスコンピュータから通信デバイス上のアカウント管理アプリケーションへ、通信デバイス上のアカウント管理アプリケーションのトークンコンテナへのアプリケーショントークンを送信する。

他の実施形態によると、トークンサービスコンピュータは、メモリと、プロセッサと、およびプロセッサによって実行されるとき、アプリケーショントークンを、通信デバイス上のアカウント管理アプリケーション上のトークンコンテナにプロビジョニングするためのプロビジョニング要求を受信するステップであって、通信デバイスは、サービスプロバイダコンピュータに関連付けられたサービスプロバイダアプリケーションも備える、ステップと、トークンサービスコンピュータから通信デバイス上のアカウント管理アプリケーションへ、通信デバイス上のアカウント管理アプリケーションのトークンコンテナへのアプリケーショントークンを送信するステップと、を実行する命令を含む非一時的コンピュータ可読媒体とを含んでもよい。

図１は、一部の実施形態による、サービスプロバイダコンピュータおよびアカウント管理サーバのセットと相互作用する通信デバイスを示す。 図２Ａは、一部の実施形態による、サービスプロバイダコンピュータのセットと相互作用する通信デバイスを示す。 図２Ｂは、一部の実施形態による、サービスプロバイダコンピュータのセットと相互作用する通信デバイスを示す。 図３は、一部の実施形態による、アプリケーショントークンプロビジョニング、引き換えプロセスおよびシステムを示す。 図４Ａは、一部の実施形態による、通信デバイスのブロック図を示す。 図４Ｂは、一部の実施形態による、通信デバイスのブロック図を示す。 図５は、一部の実施形態による、サービスプロバイダコンピュータのブロック図を示す。 図６は、一部の実施形態による、トークンサービスコンピュータのブロック図を示す。 図７は、一部の実施形態による、アプリケーショントークンのプロビジョニングプロセスを示す。 図８は、一部の実施形態による、別のアプリケーショントークンのプロビジョニングプロセスを示す。 図９は、一部の実施形態による、アプリケーショントークンの引き換えプロセスを示す。 図１０は、一部の実施形態による、ロイヤルティデータ更新フローを示す。 図１１は、一部の実施形態による、ロイヤルティデータ更新フローを示す。 図１２は、一部の実施形態による、アプリケーショントークンおよびトークン状態を管理するためのプロセスのフロー図を示す。

アプリケーショントークンを管理する技術について説明される。一部の実施形態では、通信デバイス上の第一のサービスプロバイダアプリケーションは、第一のサービスプロバイダコンピュータに、第一のアプリケーショントークンに対する第一の要求を提供し得る。通信デバイス上のアカウント管理アプリケーションは、第一のサービスプロバイダコンピュータと通信するトークンサービスコンピュータから、第一のアプリケーショントークンを受信する。第一のアプリケーショントークンは、アカウント管理アプリケーションのトークンコンテナに保存される。

実施形態によっては、サービスプロバイダは、トークンサービスコンピュータを操作して、トークンコンテナにリンクされているアプリケーション固有のトークンを発行することができる。アプリケーション固有のトークンは独自のトークン状態を持つことができ、アプリケーショントークンとそれぞれのトークン状態はユーザの通信デバイスにプロビジョニングできる。通信デバイスに保存されているアプリケーショントークンを使用すると、トークン状態が更新される場合がある。このように、データセキュリティおよび利便性は、チケット発行情報（例えば、交通機関および旅行情報）、ロイヤルティ情報、またはその他のアプリケーション固有の情報もしくはデータなどのデータに関連して提供され得る。

本発明の実施形態を論じるのに先立ち、いくつかの用語の説明が本発明の実施形態を理解するのに役立ち得る。

「通信デバイス」は、別のデバイスと通信可能な一つまたは複数の電子的構成要素（例えば集積チップ）を含むデバイスであり得る。「ポータブル通信デバイス」は、ユーザが運び、操作することが可能な通信デバイスの一つの形態であり得る。ポータブル通信デバイスは、ネットワークにリモート通信機能を提供することができ、他のデバイスとデータまたは通信の送受信を行うように構成することができる。ポータブル通信デバイスは、携帯電話（例えば、スマートフォン、セルラー式電話など）、タブレット、携帯型メディアプレイヤー、携帯情報端末デバイス（ＰＤＡ）、ウェアラブルコンピュータデバイス（例えば腕時計）、電子ブックリーダデバイスなどのモバイルデバイスの形態、またはカード（例えばスマートカード）もしくはフォブ（ｆｏｂ）などの形態であり得る。ポータブル通信デバイスの例として、ポータブルコンピュータ（例えば、ノートパソコン、ネットブック、ウルトラブックなど）も挙げられてもよい。ポータブル通信デバイスは、通信および／またはネットワーク接続機能を備える車両（例えば、車両などの自動車）の形態でもあり得る。

「サーバコンピュータ」は、強力なコンピュータ、またはコンピュータのクラスタを含んでもよい。例えば、サーバコンピュータは、大型メインフレーム、ミニコンピュータクラスタ、またはユニットとして機能するサーバ群であり得る。一例では、サーバコンピュータは、ウェブサーバに結合されるデータベースサーバであり得る。サーバコンピュータは、データベースに結合されてもよく、一つまたは複数のクライアントのコンピュータからの要求にサービスを提供する、いずれのハードウェア、ソフトウェア、他のロジックまたは前述の組み合わせを含んでもよい。サーバコンピュータは、一つまたは複数の計算装置を含んでもよく、一つまたは複数のクライアントコンピュータからの要求にサービスを提供する、さまざまなコンピュータ構造、配置およびコンパイルのうちのいずれを使用し得る。

「アプリケーション」は、特定の目的に対して使用されるコンピュータプログラムであり得る。

「時間データ要素」は、任意の適切な時間に関連するデータを含み得る。例えば、時間データ要素は、時間、日付、月、年、または上記の任意の適切な組み合わせであってもよい。時間データ要素はまた、時間、日付、月、年、または上記の任意の適切な組み合わせから派生することもできる。暗号化された時間データ要素は、暗号化された時間、日付、月、年、および／または上記の適切な組み合わせを含み得るデータ要素であってもよい。

「アプリケーショントークン」は、リソースまたは場所へのアクセスを制御するために使用される識別子であってもよい。アプリケーショントークンは、例えば、電子チケットである場合がある。別の例として、アプリケーショントークンはロイヤルティプログラム（ロイヤルティクレジットなど）に関連付けられる場合がある。いくつかの実施形態では、アプリケーショントークンの形式は、受信した情報をアプリケーショントークンとして識別するために受信エンティティによって使用できるいくつかの表示を含み得る。実施形態によっては、トークンの形式はまた、受信エンティティがアプリケーショントークンに関連付けられた発行者を識別することを可能にし得る。例えば、トークンの形式は、トークンの発行者を識別するためにトークン発行者識別子を含み得る。

「トークン発行者」、「トークンプロバイダ」、「トークンサービスコンピュータ」、または「トークンサービスシステム」は、トークンをサービスするシステムを含み得る。一部の実施形態において、トークンサービスコンピュータは、トークンの要求、決定（例えば、生成）および／または発行、ならびにトークンのリポジトリ（例えば、トークンヴォールト）内の他のデータへの確立されたマッピングの維持を容易にすることができる。一部の実施形態において、トークンサービスコンピュータは、トークンバインディングの信頼度レベルを示すために、所与のトークンに対してトークン保証レベルを確立してもよい。トークンサービスコンピュータは、生成されたトークンが保存されるトークンヴォールトを含むか、またはトークンヴォールトと通信することができる。トークンサービスコンピュータは、トークンを使用して提出された取引のトークン処理をサポートする場合がある。実施形態によっては、トークンサービスシステムは、トークン化コンピュータのみ、または取引処理ネットワークコンピュータなどの他のコンピュータとの組み合わせを含み得る。トークン化エコシステムのさまざまなエンティティが、トークンサービスプロバイダの役割を引き受ける場合がある。例えば、支払ネットワークおよび発行者またはその代理人は、本発明の実施形態によれば、トークンサービスを実装することによって、トークンサービスプロバイダになり得る。

「アクセスデバイス」は、小売業者のコンピュータまたは取引処理ネットワーク（例えば、支払処理ネットワーク）と通信するため、および消費者通信デバイスと相互作用するための任意の適切なデバイスであってもよい。アクセスデバイスは、概して、小売業者の位置など、任意の好適な位置に配置することができる。アクセスデバイスは、任意の好適な形態であり得る。アクセスデバイスの一部の例として、エントリゲート、販売時点情報管理（ＰＯＳ）デバイス、携帯電話、ＰＤＡ、パーソナルコンピュータ（ＰＣ）、タブレットＰＣ、ハンドヘルド専用リーダ、セットトップボックス、電子キャッシュレジスタ（ＥＣＲ）、現金自動預入支払機（ＡＴＭ）、仮想キャッシュレジスタ（ＶＣＲ）、キオスク、セキュリティシステム、アクセスシステム、ウェブサイトなどが挙げられる。アクセスデバイスは、任意の好適な接触または非接触動作モードを使用して、消費者通信デバイスとの間でデータの送受信、または該消費者通信デバイスに関連付けられたデータの送受信を行うことができる。アクセスデバイスがＰＯＳ端末を含んでもよい一部の実施形態では、任意の好適なＰＯＳ端末を使用でき、該端末はリーダと、プロセッサと、コンピュータ可読媒体とを含むことができる。リーダは、任意の好適な接触または非接触動作モードを含むことができる。例えば、例示的なリーダは、無線周波数（ＲＦ）アンテナ、光学スキャナ、バーコードリーダ、または磁気ストライプリーダを含んで、消費者通信デバイスと相互作用することができる。

「プロビジョニング」は、使用するデータを提供するプロセスを含んでもよい。例えば、プロビジョニングは、通信デバイスにトークンを提供すること、送達することまたは通信デバイス上のトークンを有効にすることを含んでもよい。プロビジョニングは、取引システム内または外部のいかなるエンティティによって完了してもよい。例えば、一部の実施形態では、トークンが、発行者または取引処理ネットワークによって、モバイルデバイス上にプロビジョニングされてもよい。プロビジョニングされたトークンは、対応するトークンデータを、トークンヴォールトまたはトークンレジストリに保存または保持してもよい。一部の実施形態では、トークンヴォールトまたはトークンレジストリは、その後デバイスにプロビジョニングまたは送達されてもよい、トークンを生成することができる。実施形態によっては、発行者は、トークンの生成およびプロビジョニングが発生し得るトークンの範囲を指定してもよい。さらに、一部の実施形態では、発行者は、トークンヴォールトを生成してトークンヴォールトにトークン値の通知を行い、トークンヴォールトに保存するためにトークン記録情報（例えば、トークン属性）を提供し得る。

「ユーザ」は、取引を行うために通信デバイスを操作する個人を含むことができる。ユーザはまた、消費者またはアカウント保有者と呼ばれ得る。

「鍵」は、入力データを別の表現へと変換するために暗号アルゴリズムにおいて使用される情報を指すことができる。暗号アルゴリズムは元データを代替表現へと変換する暗号化アルゴリズム、または暗号化された情報を元データへと戻す変換を行う復号アルゴリズムであり得る。暗号化アルゴリズムの例として、高度暗号化標準（Ａｄｖａｎｃｅ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）（ＡＥＳ）、データ暗号化標準（Ｄａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ）（ＤＥＳ）、トリプルデータ暗号化標準／アルゴリズム（Ｔｒｉｐｌｅ Ｄａｔａ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ／Ａｌｇｏｒｉｔｈｍ）（ＴＤＥＳ／ＴＤＥＡ）、またはその他の好適なアルゴリズムが挙げられてもよい。暗号化アルゴリズムで使用される鍵は、任意の適切な長さ（例えば、５６ビット、１２８ビット、１６９ビット、１９２ビット、２５６ビットなど）であり得る。一部の実施形態では、より長い鍵の長さは、ハッキングの影響を受けにくい、より安全な暗号化を提供し得る。

「デジタル署名」または「暗号署名」には、複製が特に困難なデジタルコードで文書を暗号化する電子署名の種類が含まれ得る。デジタル署名には、電子記録またはメッセージの発信元および身元に関する保証または証拠を提供するために使用されるデータが含まれ得る。デジタル署名は、公開鍵暗号（非対称暗号）に基づくことができる。デジタル署名は、Ｒｉｖｅｓｔ−Ｓｈａｍｉｒ−Ａｄｌｅｍａｎ（ＲＳＡ）などの公開鍵アルゴリズムを使用して生成できる。デジタル署名を作成するために、署名ソフトウェアを使用して、署名エンティティによって署名される電子データの一方向ハッシュを作成してもよい。次に、署名エンティティの秘密鍵を使用してハッシュを暗号化し、デジタル署名を形成する。他の事例では、対称鍵ペアの対称鍵を使用して、デジタル署名を作成できる。

「検証」という用語には、情報が正当であることの照合または確認の行為が含まれる場合がある。例としては、電子記録に添付されたデジタル署名が、実際に正当なものであり、デジタル署名の作成を主張するエンティティによって署名されたことを照合する行為が挙げられ得る。いくつかの実施形態では、デジタル署名は、署名エンティティの公開鍵と併せて検証アルゴリズムに従って検証されてもよい。また、対称鍵ペアの対称鍵を使用して基になるデータに署名した場合、対応する対称鍵を使用して署名を検証できる。

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

「承認応答メッセージ」は、承認要求メッセージに応答する電子メッセージとすることができる。実施形態によっては、承認応答メッセージは、発行金融機関、サービスプロバイダ、または支払処理ネットワークによって生成され得る。承認応答メッセージは、単に例として、次の状態指標のうちの一つ以上を含んでもよい。承認―取引が承認された。拒否―取引が承認されなかった。または、コールセンタ―応答はより多くの情報を保留中で、小売業者は、フリーダイヤルの承認電話番号に電話する必要がある。承認応答メッセージはまた、クレジットカード発行銀行が承認要求メッセージに応じて、取引の承認を示す小売業者のアクセスデバイス（例えば、ＰＯＳ装置）に電子メッセージ（直接または支払処理ネットワークを介してのいずれか）で返信するコードであり得る、承認コードを含むことができる。コードは、承認の証明として役割を果たし得る。上述の通り、一部の実施形態では、支払処理ネットワークは、承認応答メッセージを生成してもよく、または承認応答メッセージを小売業者に転送してもよい。

「承認処理」または「承認操作」は、少なくとも承認要求メッセージおよび／または承認応答メッセージを生成および送信することを含んでもよい。承認処理には、取引を承認するかどうかの判断もさらに含まれてもよい。

「取引処理システム」は、取引要求メッセージを処理しルーティングできる、一つまたは複数のデバイスのネットワークを含んでもよい。例示的な取引処理システムは、承認サービス、例外ファイルサービス、取引スコアリングサービス、ならびに清算および決済サービスをサポートし、配信するのに使用するデータ処理サブシステム、ネットワークおよび操作を含んでもよい。例示的な取引処理システムは、ＶｉｓａＮｅｔ（商標）を含んでもよい。ＶｉｓａＮｅｔ（商標）などの取引処理システムは、クレジットカード取引、デビットカード取引および他のタイプの商取引を処理することができる。特にＶｉｓａＮｅｔ（商標）には、承認要求を処理するＶＩＰシステム（Ｖｉｓａ統合決済システム）と、清算および決済サービスを実施するＢａｓｅＩＩシステムを含むことができる。

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

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

図１は、一部の実施形態による、サービスプロバイダコンピュータ１１２〜１１６およびアカウント管理サーバ１１８のセットと通信する通信デバイス１１０を示す。図１に示すサービスプロバイダコンピュータは、サービスプロバイダコンピュータＡ１１２、サービスプロバイダコンピュータＢ１１４、およびサービスプロバイダコンピュータＣ１１６を含む。

サービスプロバイダコンピュータ１１２〜１１６は、異なるサービスプロバイダまたはサービスプロバイダエージェントに対応しうる。例として、サービスプロバイダは、場所またはイベントへのアクセスを容易にすることができる。サービスプロバイダの例としては、交通機関（鉄道やバスサービスなどを提供する）、航空会社、映画館などがある。サービスプロバイダエージェントは、複数の異なるサービスプロバイダ（例えば、異なる航空会社にわたって航空券を販売するウェブサイト、または航空券代理店）に代わって、リソースへのアクセスを容易にする場合がある。

各サービスプロバイダコンピュータ（１１２〜１１６）は、それぞれのサービスプロバイダアプリケーション（１０２〜１０６）に関連付けられる。サービスプロバイダＡ １１２は、サービスプロバイダアプリケーションＡ １０２に関連付けられる。サービスプロバイダコンピュータＢ １１４は、サービスプロバイダアプリケーションＢ １０４に関連付けられる。サービスプロバイダコンピュータＣ １１６は、サービスプロバイダアプリケーションＣ １０６に関連付けられる。サービスプロバイダアプリケーション１０２〜１０６は、リソースへのアクセスを管理するために使用され得る。たとえば、ユーザがサービスプロバイダアプリケーションと相互作用して、旅行用のチケットを購入してもよい。

図１に示すように、サービスプロバイダアプリケーション１０２〜１０６は、アカウント管理アプリケーション１０８と通信している。アカウント管理アプリケーション１０８は、サービスプロバイダアプリケーション１０２〜１０６にわたるリソースへのアクセスを容易にするために、データを中央管理するために使用され得る。例えば、アカウント管理アプリケーション１０８は、デジタルウォレットであってもよく、一組のサービスプロバイダアプリケーションを介してデジタル通貨、チケットなどを保存してもよい。

各サービスプロバイダアプリケーション１０２〜１０６は、異なる形式、データ、およびデータ構造を使用し得る。サービスプロバイダアプリケーション１０２〜１０６がアカウント管理アプリケーション１０８の機能を利用するためには、各サービスプロバイダアプリケーションは、アカウント管理アプリケーション１０８に統合され、アカウント管理アプリケーション１０８は、各サービスプロバイダアプリケーション１０２〜１０６によって提供されるデータを処理できなければならない。

図２Ａを参照すると、複数のアカウント管理アプリケーションプロバイダが存在する。異なる通信デバイス／ユーザは、異なるアカウント管理アプリケーションを選択できる。例えば、異なる通信デバイス製造業者は、異なるそれぞれのネイティブアカウント管理アプリケーションと互換性があってもよい。別の例として、ユーザは、一つまたは複数の好ましいアカウント管理アプリケーションを選択して、通信デバイスにインストールしてもよい。

図２Ａに示すように、３つの異なる通信デバイスである、通信デバイスＡ２１０、通信デバイスＢ２２０、および通信デバイスＣ２３０はそれぞれ、異なるそれぞれのアカウント管理アプリケーションで構成される。通信デバイスＡ２１０は、アカウント管理アプリケーションＡ２１２を含む。通信デバイスＢ２２０は、アカウント管理アプリケーションＢ２２２を含む。通信デバイスＣ２３０は、アカウント管理アプリケーションＣ２３２を含む。

各アカウント管理アプリケーション（アカウント管理アプリケーションＡ ２１２、アカウント管理アプリケーションＢ ２２２、アカウント管理アプリケーションＣ ２３２）は、さまざまなサービスプロバイダに関連付けられたデータを保存するように構成されている。アカウント管理アプリケーション２１２、２２２、２３２は、サービスプロバイダコンピュータＡ ２４０、サービスプロバイダＢ ２５０、サービスプロバイダＣ ２６０、およびサービスプロバイダＤ ２７０に通信可能に結合される。アカウント管理アプリケーション２１２、２２２、２３２は、サービスの提供を容易にするために、任意の所定のサービスプロバイダコンピュータと相互作用する必要がある場合がある。

具体的な例として、ユーザは、特定の電子ウォレット、アカウント管理アプリケーションＡ２１２で構成される通信デバイスＡ２１０を操作する。ユーザは頻繁に列車で移動し、いくつかの異なるサービスプロバイダを通して列車のチケットを購入する。電子ウォレットを使用してすべての列車チケットを管理するために、アカウント管理アプリケーションＡには、様々なサービスプロバイダコンピュータとインターフェースするように構成されたプログラミングが含まれる。サービスプロバイダコンピュータＡは、地元のライトレールサービスによって運営される。サービスプロバイダコンピュータＢ ２５０は、都市間列車サービスによって運営される。サービスプロバイダコンピュータＣ ２６０は旅行代理店によって運営される。サービスプロバイダコンピュータＤ ２７０は、ユーザが異なるプロバイダの価格を比較できる旅行アグリゲータサービスによって運営される。ユーザは、これらの各プロバイダから異なる時間にチケットを購入する。したがって、アカウント管理アプリケーションＡは、各サービスプロバイダコンピュータ（Ａ ２４０、Ｂ ２５０、Ｃ ２６０、およびＤ ２７０）とインターフェース、それぞれのサービスプロバイダコンピュータによって提供される様々な形式のチケットを受け入れ、それぞれのサービスプロバイダコンピュータと通信して、チケットを有効にする、かつ引き換えるように構成されたコードを含む。同様に、サービスプロバイダは、さまざまなアカウント管理アプリケーションに統合する必要がある。例えば、通信デバイスＢは、通信デバイスＡとは別のウォレットがインストールされており（アカウント管理アプリケーションＢ２２２対アカウント管理アプリケーションＡ２１２）、通信デバイスＣは、さらに別の電子ウォレットがインストールされている（アカウント管理アプリケーションＣ２３２）。各サービスプロバイダコンピュータには、これらのアカウント管理アプリケーションそれぞれとインターフェースし、それぞれを理解するための機能が含まれている必要がある。

図２Ｂは、実施形態に従い、複数のアカウント管理アプリケーションおよびサービスプロバイダコンピュータの統合を容易にする、トークンサービスコンピュータ２８２（例えば、トークンサービスプロバイダによって運営される）を有するシステム２００Ｂを図示する。システム２００Ｂは、通信デバイスＡ２１６、通信デバイスＢ２２６、通信デバイスＣ２３６、トークンサービスコンピュータ２８２、サービスプロバイダコンピュータＡ２４２、サービスプロバイダＢ２５２、サービスプロバイダＣ２６２、およびサービスプロバイダコンピュータＤ２７２を含む。

各通信デバイスは、それぞれのアカウント管理アプリケーションを含む。通信デバイスＡ２１６は、アカウント管理アプリケーションＡ２１８を含む。通信デバイスＢ２２６は、アカウント管理アプリケーションＢ２２８を含む。通信デバイスＣ２３６は、アカウント管理アプリケーションＣ２３８を含む。

図２Ａとは対照的に、図２Ｂのシステムでは、トークンサービスコンピュータ２８２を介して、アカウント管理アプリケーション２１８、２２８、２３８は、様々なサービスプロバイダコンピュータ２４２、２５２、２６２、２７２に適合するのではなく、一つのインターフェースであるトークンサービスコンピュータ２８２と通信することができる。同様に、サービスプロバイダコンピュータ２４２、２５２、２６２、２７２は、トークンサービスコンピュータ２８２と通信できる。したがって、トークンサービスコンピュータの使用は、当事者間の通信を合理化する。

図３は、一部の実施形態による、通信デバイス３６０、トークンサービスコンピュータ３３０、サービスプロバイダウェブサイト３２０、アクセスデバイス３５０、およびサービスプロバイダコンピュータ３４０の間の相互作用の概要を示す。サービスプロバイダコンピュータ３４０、アクセスデバイス３５０、およびサービスプロバイダウェブサイト３２０は、交通機関プロバイダ、コンサート会場、旅行代理店、チケット代理店などのサービスプロバイダと関連付けられてもよい。例えば、サービスプロバイダコンピュータ３４０は、鉄道、すなわち、Ｕ．Ｓ．Ａ．Ｒａｉｌｗａｙｓに関連付けられたサーバコンピュータである。サービスプロバイダウェブサイト３２０は、Ｕ．Ｓ．Ａ．Ｒａｉｌｗａｙｓの一般向けウェブサイトである。アクセスデバイス３６０は、Ｕ．Ｓ．Ａ．Ｒａｉｌｗａｙｓが運営する鉄道駅の特定のプラットフォームに入るためのゲートのアクセス端末である。通信デバイス３６０は、例えば、近距離無線通信対応の携帯電話であってもよい。通信デバイス３６０は、サービスプロバイダアプリケーションＡ ３６２（Ｕ．Ｓ．Ａ．Ｒａｉｌｗａｙｓに対応する）およびサービスプロバイダアプリケーションＢ ３６４（他のサービスプロバイダに対応する）を含む。

最初は、ユーザは通信デバイス３６０と相互作用して、Ｕ．Ｓ．Ａ．Ｒａｉｌｗａｙｓの交通機関のチケットを購入する。ユーザは、サービスプロバイダアプリケーションＡ ３６２を介して、および／またはサービスプロバイダウェブサイト３２０を介して、交通機関のチケットを購入することができる。

ステップＳ１で、通信デバイス３６０のアプリケーションは、ユーザがアプリケーション３６２を介してチケットを購入する場合、チケット購入情報をサービスプロバイダウェブサイト３２０に送信し得る。代替で、ユーザは、通信デバイス３６０上のブラウザを介して、サービスプロバイダウェブサイト３２０と直接相互作用してもよい。ステップＳ２で、サービスプロバイダウェブサイト３２０は、チケット購入情報をサービスプロバイダコンピュータ３４０に送信する。

ステップＳ３で、サービスプロバイダコンピュータ３４０は、チケット購入を処理するが、これには、購入詳細を確認し、口座から引き落とすために、外部の取引処理システムおよび／または発行者と調整することが含まれ得る。サービスプロバイダコンピュータ３４０は、チケットを表すアプリケーショントークン３６６を発行し、アプリケーショントークン３６６の記録を保持してもよい。

ステップＳ５で、サービスプロバイダコンピュータ３４０は、トークンサービスコンピュータ３３０を介してフルフィルメントを開始することができる。サービスプロバイダコンピュータ３４０は、アプリケーショントークン３６６に関する情報をトークンサービスコンピュータ３３０に送信しうる。

ステップＳ６で、トークンサービスコンピュータ３３０は、アプリケーショントークン３６６に関連付けられたトークンコンテナ３６７を準備することができる。一部の実施形態において、トークンサービスコンピュータ３３０は、通信デバイス３６０にプロビジョニングするためのトークンコンテナ３６７を生成する。トークンサービスコンピュータ３３０は、サービスプロバイダコンピュータ３４０から受信したアプリケーショントークン３６６を取得しうる。トークンサービスコンピュータ３３０は、アプリケーショントークンをトークンコンテナ内に配置してもよい。トークンサービスコンピュータ３３０は、トークンコンテナ３６７に関連して、コンテナ識別子（ＩＤ）３４２を生成し、保存してもよい。コンテナＩＤ３４２は、例えば、トークンコンテナ３６７を特徴付ける１６桁の番号、名前などであってもよい。コンテナＩＤ３４２は、トークンサービスコンピュータ３３０および／またはサービスプロバイダ３４０に保存されてもよい。トークンサービスコンピュータ３３０は、アプリケーショントークン３６６に関連して、トークン状態３４４をさらに確立し、保存してもよい。トークン状態３４４は、アプリケーショントークンの状態に対応してもよい。トークン状態３４４の例には、新規生成された、引き換えられた、および価値が付加されたが含まれる。

ステップＳ７で、トークンサービスコンピュータ３３０は、トークンコンテナ３６７および／またはアプリケーショントークン３６６を通信デバイス３６０にプロビジョニングし得る。トークンサービスコンピュータ３３０は、任意の適切な形態の無線または有線通信を介して、トークンコンテナ３６７およびアプリケーショントークン３６６を通信デバイス３６０に送信する。

通信デバイス３６０は、トークンコンテナ３６７を保存し、これは次に、アプリケーショントークン３６６を保存する。アプリケーショントークンは、異なる場所またはリソースへのアクセスに関連付けられる。たとえば、あるアプリケーショントークンは２０１９年７月３日のＣａｌｉｆｏｒｎｉａ Ａｉｒｗａｙｓの航空券に対応し、別のアプリケーショントークンは２０１９年７月４日のＵ．Ｓ．Ａ．Ｒａｉｌｗａｙｓの列車チケットに対応し、第三のアプリケーショントークンは特定のコンサートのコンサートチケットに対応する。異なるサービスプロバイダに関連付けられたアプリケーショントークンは、同じトークンコンテナ３６７に保存され得る。代替で、複数のトークンコンテナを、例えば、サービスプロバイダまたはサービスプロバイダアプリケーションごとに一つずつプロビジョニングすることもできる。

ステップＳ８で、通信デバイス３６０は、アクセスデバイス３５０と相互作用して、場所またはリソースへのアクセスを取得する。この特定の例では、ユーザは短波通信対応電話をゲートにタグ付けして、列車のプラットフォームにアクセスする。通信デバイス３６０は、アプリケーショントークン３６６をアクセスデバイス３５０に送信する。

ステップＳ９で、アクセスデバイス３５０は、アプリケーショントークン３６６のヘッダを照合し、Ｕ．Ｓ．Ａ．Ｒａｉｌｗａｙｓに対応するアプリケーショントークン３６６を識別する。アクセスデバイス３５０は、信号を送信し、ゲートを開き、ユーザに列車プラットフォームへのアクセスを許可する。アクセスデバイス３５０は、確認を通信デバイス３６０に送信し、通信デバイス３６０に、Ｕ．Ｓ．Ａ．Ｒａｉｌｗａｙｓの旅程用のアプリケーショントークン３６６を使用済みとしてマークさせる。

ステップＳ１０で、アクセスデバイス３５０は、サービスプロバイダコンピュータ３４０に情報を送信する。送信された情報は、Ｕ．Ｓ．Ｒａｉｌの旅行のアプリケーショントークンが引き換えられたことを示す。

ステップＳ１１で、サービスプロバイダコンピュータ３４０は、その記録データベースを更新して、アプリケーショントークンが引き換えられたことを示す。記録の更新は、引き換えられたアプリケーショントークン３６６に関連付けられた保存されたトークン状態３４４を変更することを含み得る。

図４Ａは、一部の実施形態による、通信デバイス４０１のブロック図を示す。通信デバイス４０１は、メモリ４０２に結合されるデバイスハードウェア４０４を含んでもよい。デバイスハードウェア４０４は、プロセッサ４０５、通信サブシステム４０９、ユーザインターフェース４０６、およびディスプレイ４０７（ユーザインターフェース４０６の一部であってよい）を含んでもよい。

プロセッサ４０５は、一つまたは複数の集積回路（例えば、一つまたは複数のシングルコアもしくはマルチコアマイクロプロセッサおよび／またはマイクロコントローラ）として実装でき、ポータブル通信デバイス４０１の動作を制御するため使用される。プロセッサ４０５は、メモリ４０２に保存されるプログラムコードまたはコンピュータ可読コードに応じて、様々なプログラムを実行でき、複数の同時実行プログラムまたはプロセスを保持し得る。

通信サブシステム４０９は、他のデバイスと通信し、かつ／またはインターネットなどの外部ネットワークと接続するように、通信デバイス４０１により使用され得る、一つまたは複数の送受信機および／またはコネクタを含んでもよい。一部の実施形態では、通信サブシステム４０９は、アンテナなどの連動無線転送（例えば、データ伝送）要素と共に半導体チップ（または他のデータ記憶要素）の形態で実装されることの多い、非接触要素をさらに含むことができる。非接触要素は、通信デバイス４０１に結合されてもよく（例えば、組み込まれて）、セルラーネットワークを介して送信されるデータまたは制御命令は、非接触要素インターフェース（図示せず）によって非接触要素に適用されてもよい。非接触要素は、短距離無線通信機能を使用してデータを送受信することができてもよい。通信サブシステム４０９は、呼掛けデバイス（例えば、データを受信）および呼掛けられるデバイス（例えば、データを送信）の両方となるコンポーネントを含んでもよい。したがって、通信デバイス４０１は、セルラーネットワーク（または任意の他の好適な無線ネットワーク、例えばインターネットもしくは他のデータネットワーク）および狭域通信の両方を介して、データまたは制御命令を伝達および転送することが可能であり得る。通信デバイス４０１はまた、無線データ転送（例えば、データ伝送）のためのアンテナを含んでもよい。

ユーザインターフェース４０６は、ユーザが、通信デバイス４０１と相互作用し、その機能を呼び出すことが可能になるように、入出力要素のいかなる組み合わせも含み得る。いくつかの実施形態では、ディスプレイ４０７は、ユーザインターフェース４０６の一部であってもよい。ディスプレイ４０７およびユーザインターフェース４０６は、ユーザが情報およびメッセージを見ることを可能にし得る。通信デバイスは、ユーザが情報をデバイスに入力することを可能にする入力要素と、ユーザが音声通信、音楽などを聞くことを可能にするスピーカと、ユーザが自分の音声を通信デバイス４０１を介して伝送することを可能にするマイクロフォンと、をさらに含むことができる。

メモリ４０２は、任意の数の不揮発性メモリ（例えば、フラッシュメモリ）および揮発性メモリ（例えば、ＤＲＡＭ、ＳＲＡＭ）のいかなる組み合わせ、もしくはいかなる他の非一時的記憶媒体、またはそれらの媒体の組み合わせを使用して実装され得る。メモリ４０２は、モバイルオペレーティングシステム４２０、およびプロセッサ４０５により実行される一つまたは複数のアプリケーションが常駐するアプリケーション環境４１０を保存してもよい。

アプリケーション環境４１０は、アプリケーショントークンを管理するために使用されるアプリケーションを含んでもよい。いくつかの実施形態では、アプリケーションは、サービスプロバイダアプリケーションＡ４１２、サービスプロバイダアプリケーションＢ４１４、およびアカウント管理アプリケーション４１６を含み得る。

サービスプロバイダアプリケーション（Ａ４１２およびＢ４１４）は、サービスまたはその他のリソースへのアクセスを提供する機能を含み得る。サービスプロバイダアプリケーションの例としては、チケット発券アプリケーション、交通機関アプリケーション、小売業者アプリケーションなどがある。サービスプロバイダアプリケーションは、チケットの販売または引き換えなどのバックエンド機能を実行するために、それぞれのサービスプロバイダコンピュータと通信可能に結合され得る。

アカウント管理アプリケーション４１６は、一つまたは複数のアカウントを管理するための機能を含んでもよい。アカウント管理アプリケーション４１６の例には、モバイルまたはデジタルウォレットアプリケーション、発行者アプリケーション、および銀行業務アプリケーションが含まれる。アカウント管理アプリケーション４１６は、サービスプロバイダアプリケーションＡ ４１２およびサービスプロバイダアプリケーションＢ ４１４に関連付けられた機能を保存および管理するための単一のアプリケーションを提供し得る。

メモリ４０２は、第一のサービスプロバイダコンピュータへ通信デバイス上の第一のサービスプロバイダアプリケーションによって、第一のアプリケーショントークンに対する第一の要求を提供することと、第一のサービスプロバイダコンピュータと通信するトークンサービスコンピュータから通信デバイス上のアカウント管理アプリケーションによって、第一のアプリケーショントークンを受信することと、アカウント管理アプリケーションのトークンコンテナに、第一のアプリケーショントークンを保存することと、を含む方法を実施するためプロセッサ４０５によって実行可能なコードを含み得る。

図４Ｂは、いくつかの実施形態による、アカウント管理アプリケーション４１６の詳細図を示す。アカウント管理アプリケーション４１６は、アプリケーショントークン４１７−１〜４１７−ｎおよびトークン状態４１８−１〜４１８−ｎを保存してもよい。アカウント管理アプリケーション４１６は、アプリケーショントークン４１７−１〜４１７−ｎおよびトークン状態４１８−１〜４１８−ｎを安全に、例えば、暗号化および／または安全なハードウェア要素を使用して、保存することができる。

一部の実施形態では、アプリケーショントークン４１７−１〜４１７−ｎは、購入したサービスまたは物品に関連付けられたデジタルチケットである。ユーザがサービスプロバイダから複数のサービスまたは物品を取得する場合、サービスまたは物品をアプリケーション固有のトークンにさらにリンクさせることができる。例えば、多区間の交通機関チケットを取得する場合、各チケットはデジタルチケットとして発行され、アプリケーショントークンで表すことができる。代替で、または追加で、アプリケーショントークンは、ロイヤルティデータ（例えば、フリークエントショッパーのリワードポイント）を表す場合がある。また、各アプリケーショントークン４１７−１〜４１７−ｎは、それぞれのトークン状態４１８−１〜４１８−ｎを有してもよい。各トークン状態は、対応するアプリケーショントークンの一つまたは複数のトークン属性を表す場合がある。続けて交通機関システムに関する上記の例では、各トークン状態は、旅行の区間のチケットが使用されたかどうかなどの属性を表す場合がある。

通信デバイス４０１は、プロビジョニングされたアプリケーショントークン４１７−１〜４１７−ｎおよび関連するトークン状態４１８−１〜４１８−ｎを、アカウント管理アプリケーション４１６によってアクセス可能なデジタルコンテナに保存し得る。プロビジョニングされたアカウントトークン４１７−１〜４１７−ｎは、関連するサービスプロバイダで物品またはサービスにアクセスするために使用され得る。例えば、プロビジョニングされたアカウントトークンは、通信デバイス４０１から交通機関のゲートでアクセスデバイスへ提供されて、交通機関システムへのアクセスを得ることができる。アプリケーショントークンが消費されるとき、サービスプロバイダは、通信デバイス４０１上のアプリケーショントークンのトークン状態を更新し得る。たとえば、チケットが使用済みの場合、サービスプロバイダは、チケットを表すトークンのトークン状態を未使用状態から使用済み状態に変更することができる。実施形態によっては、サービスプロバイダは、状態更新要求をトークンサービスコンピュータに送信することによって（例えば、図６に示すように）、通信デバイス４０１上のトークン状態を更新することができ、トークンサービスコンピュータは、自身のトークン状態を更新して、更新を通信デバイス４０１に同期することができる。

アカウント管理アプリケーション４１６はさらに、アプリケーショントークンと関連付けられた相互作用がいつどこで発生するかのログを保存し得る。したがって、アプリケーショントークンの整合性は、引き換え時に検証できる。

図５は、一部の実施形態による、サービスプロバイダコンピュータ５０１のブロック図を示す。サービスプロバイダコンピュータ５０１は、ネットワークインターフェース５０２、プロセッサ５０４、メモリ５０６、およびコンピュータ可読媒体５０８を含む。

プロセッサ５０４は、一つまたは複数の集積回路（例えば、一つまたは複数のシングルコアもしくはマルチコアマイクロプロセッサおよび／またはマイクロコントローラ）として実装できる。プロセッサ５０４は、サービスプロバイダコンピュータ５０１の動作を制御するために使用され得る。プロセッサ５０４は、メモリ５０６に保存されたプログラムコードまたはコンピュータ可読コードに応じて、様々なプログラムを実行することができる。プロセッサ５０４は、同時に実行される複数のプログラムまたはプロセスを維持する機能を含んでもよい。

ネットワークインターフェース５０２は、サービスプロバイダコンピュータ５０１がリソースプロバイダコンピュータ、トランスポートコンピュータ、ルーティング管理インターフェースなどの他のエンティティと通信できるように、一つまたは複数の通信ネットワークに接続するように構成され得る。例えば、トランスポートコンピュータとの通信は、直接、間接、および／またはアプリケーションプログラミングインターフェース（ＡＰＩ）を介して行うことができる。

メモリ５０６は、任意の数の不揮発性メモリ（例えば、フラッシュメモリ）および揮発性メモリ（例えば、ＤＲＡＭ、ＳＲＡＭ）のいかなる組み合わせ、もしくはいかなる他の非一時的記憶媒体、または媒体の組み合わせを使用して実装され得る。

コンピュータ可読媒体５０８は、記憶および／または伝送のための一つまたは複数の非一時的媒体を備えてもよい。好適な媒体には、例として、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、ハードドライブもしくはフロッピーディスクなどの磁気媒体、またはコンパクトディスク（ＣＤ）もしくはＤＶＤ（デジタル多目的ディスク）などの光媒体、フラッシュメモリ、および同類のものが含まれる。コンピュータ可読媒体２０８は、そのような記憶または伝送デバイスのいかなる組み合わせであってもよい。

コンピュータ可読媒体５０８は、一連の命令またはコマンドとして保存されるソフトウェアコードを含んでもよい。コンピュータ可読媒体５０８は、本明細書に記載する方法を実施するための、プロセッサ５０４により実行可能なコードを備える。コンピュータ可読媒体５０８は、通信モジュール５１０、暗号化モジュール５１２、発行モジュール５１４、および検証モジュール５１６を備えてもよい。これらのモジュールは各々、プロセッサ５０４と併せて、以下に説明される機能を実行するように構成されたコードを含み得る。

通信モジュール５１０は、プロセッサ５０４にメッセージの生成、メッセージの転送、メッセージの再フォーマット、および／またはその他の方法で他のエンティティとの通信を行わせるコードを含み得る。

暗号化モジュール５１２は、本発明の実施形態でデータを暗号化するための任意の適切な暗号化アルゴリズムを含み得る。適切なデータ暗号化アルゴリズムには、ＤＥＳ、トリプルＤＥＳ、ＡＥＳなどが含まれ得る。暗号化モジュール５１２はまた、かかる暗号化アルゴリズムと共に使用され得る暗号鍵を保存してもよい。任意の対応する鍵ペアの他の鍵は、トークンサービスコンピュータ６０１に暗号化モジュール６１２を保存してもよい。暗号化モジュール５１２は、対称または非対称の暗号化技術を利用して、データを暗号化および／または検証してもよい。トークンサービスコンピュータおよびサービスプロバイダコンピュータ５０１は、暗号化鍵ペアのそれぞれの暗号化鍵を有する（保存する）ことができる。

発行モジュール５１４は、プロセッサ５０４にアプリケーショントークンを生成させるコードを含み得る。発行モジュールは、旅行、イベント、またはアイテムデータなどの要求された詳細を受信できる。発行モジュールは、要求された詳細に対応するアプリケーショントークンを生成できる。発行モジュールは、アプリケーショントークンを購入するためのアカウント情報を処理するための支払データを処理するコードをさらに含み得る（これは、一つまたは複数の外部支払処理ネットワークおよび／または銀行と協力して行われ得る）。

検証モジュール５１６は、プロセッサ５０４にアプリケーショントークンを検証させるコードを含み得る。アプリケーショントークンの検証には、保存されたアプリケーショントークン記録の検証、アプリケーショントークンのデジタル署名の検証、受信した検証データの処理のうちの一つ以上の検証が含まれ得る。検証モジュールは、プロセッサ５０４に、アプリケーションに関連づけられたトークン状態を更新させるコード（例えば、アプリケーショントークンを使用済み、期限切れとしてマークするなど）をさらに含んでもよい。

図６は、一部の実施形態による、トークンサービスコンピュータ６０１のブロック図を示す。トークンサービスコンピュータ６０１は、ネットワークインターフェース６０２、プロセッサ６０４、メモリ６０６、およびコンピュータ可読媒体６０８を含む。

プロセッサ６０４は、一つまたは複数の集積回路（例えば、一つまたは複数のシングルコアもしくはマルチコアマイクロプロセッサおよび／またはマイクロコントローラ）として実装できる。プロセッサ６０４は、トークンサービスコンピュータ６０１の動作を制御するために使用され得る。プロセッサ６０４は、メモリ６０６に保存されたプログラムコードまたはコンピュータ可読コードに応じて、様々なプログラムを実行することができる。プロセッサ６０４は、同時に実行される複数のプログラムまたはプロセスを維持する機能を含んでもよい。

ネットワークインターフェース６０２は、ゲートウェイサーバ６００がリソースプロバイダコンピュータ、トランスポートコンピュータ、ルーティング管理インターフェースなどの他のエンティティと通信できるように、一つまたは複数の通信ネットワークに接続するように構成され得る。例えば、トランスポートコンピュータとの通信は、直接、間接、および／またはＡＰＩを介して行うことができる。

メモリ６０６は、任意の数の不揮発性メモリ（例えば、フラッシュメモリ）および揮発性メモリ（例えば、ＤＲＡＭ、ＳＲＡＭ）のいかなる組み合わせ、もしくはいかなる他の非一時的記憶媒体、または媒体の組み合わせを使用して実装され得る。

コンピュータ可読媒体６０８は、記憶および／または伝送のための一つまたは複数の非一時的媒体を備えてもよい。好適な媒体には、例として、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、ハードドライブもしくはフロッピーディスクなどの磁気媒体、またはコンパクトディスク（ＣＤ）もしくはＤＶＤ（デジタル多目的ディスク）などの光媒体、フラッシュメモリ、および同類のものが含まれる。コンピュータ可読媒体６０８は、そのような記憶または伝送デバイスのいかなる組み合わせであってもよい。

コンピュータ可読媒体６０８は、一連の命令またはコマンドとして保存されるソフトウェアコードを含んでもよい。コンピュータ可読媒体６０８は、本明細書に記載する方法を実施するための、プロセッサ６０４により実行可能なコードを備える。コンピュータ可読媒体６０８は、通信モジュール６１０、暗号化モジュール６１２、プロビジョニングモジュール６１４、および更新モジュール６１６を備えてもよい。これらのモジュールは各々、プロセッサ６０４と併せて、以下に説明される機能を実行するように構成されたコードを含み得る。

通信モジュール６１０は、プロセッサ５０４にメッセージの生成、メッセージの転送、メッセージの再フォーマット、および／またはその他の方法で他のエンティティとの通信を行わせるコードを含み得る。

暗号化モジュール６１２は、本発明の実施形態でデータを暗号化するための任意の適切な暗号化アルゴリズムを含み得る。適切なデータ暗号化アルゴリズムには、ＤＥＳ、トリプルＤＥＳ、ＡＥＳなどが含まれ得る。暗号化モジュール６１２はまた、かかる暗号化アルゴリズムと共に使用され得る暗号鍵を保存してもよい。任意の対応する鍵ペアの他の鍵は、サービスプロバイダコンピュータ５０１に暗号化モジュール５１２を保存してもよい。暗号化モジュール６１２は、対称または非対称の暗号化技術を利用して、データを暗号化および／または検証してもよい。トークンサービスコンピュータ６０１およびサービスプロバイダコンピュータ５０１は、暗号化鍵ペアのそれぞれの暗号化鍵を有する（保存する）ことができる。

プロビジョニングモジュール６１４は、プロセッサ６０４にトークンコンテナを生成させるコードを含み得る。プロビジョニングモジュールは、例えば、特定の通信デバイスおよび／またはアプリケーショントークンのためのトークンコンテナを生成するように構成されたコードを含み得る。

更新モジュール６１６は、トークンコンテナおよび／またはアプリケーショントークンを更新するためのコードを含み得る。更新モジュールには、アプリケーショントークンをトークンコンテナに追加するように構成されたコードを含んでもよい。更新モジュール５１６は、アプリケーショントークンに関連付けられたトークン状態を更新するよう構成されたコードを含み得る（例えば、アプリケーショントークンを使用済みとしてマークする、値を追加する、旅行に区間を追加する、ロイヤルティデータを更新するなどによって）。

一部の実施形態では、トークンサービスコンピュータには、トークンヴォールト（非表示）が含まれている場合がある。例として、トークンヴォールトはアプリケーショントークンを保存できる。各アプリケーショントークンはまた、それぞれのトークン状態に関連して保存できる（図４に関連して上述したように）。アプリケーショントークンおよび対応するトークン状態は、トークンヴォールトに保存され、通信デバイスにプロビジョニングされてもよい（例えば、図４に関連して図示及び説明したように）。アプリケーショントークンが引き換えられると（例えば、旅行、イベントへのアクセスなど）、アプリケーショントークンのトークン状態がトークンヴォールトで更新され得る。

図７は、一部の実施形態による、アプリケーショントークンのプロビジョニングプロセス７００を示す。通信デバイス７５０は、そこに、モバイルウォレットアプリケーションなどのアカウント管理アプリケーション７５４およびサービスプロバイダコンピュータ７６０に関連付けられた小売業者または交通機関アプリケーションなどのサービスプロバイダアプリケーション７５２をインストールした可能性がある。アプリケーショントークンのプロビジョニングプロセス７００は、アプリケーショントークンを通信デバイス７５０にプロビジョニングする最初のプロセスであり得る。

最初は、ユーザは、通信デバイス７５０と相互作用して、アプリケーショントークンを購入してもよい。ユーザは、例えば、サービスプロバイダアプリケーション７５２を介して、および／またはサービスプロバイダウェブサイトと通信するウェブブラウザを介して、購入のためにアプリケーショントークンを選択し得る。別の例として、ユーザは、キオスクを介して、例えば、地下鉄駅または空港で、アプリケーショントークンを購入してもよい。サービスプロバイダアプリケーション７５２は、アプリケーショントークンおよび／またはトークンコンテナが通信デバイス７５０上に存在するかどうかを判定し得る。サービスプロバイダアプリケーション７５２は、例えば、アカウント管理アプリケーション７５４に問い合わせて、アカウントトークンが以前にプロビジョニングされているか、かつ／またはトークンコンテナが現在、アカウント管理アプリケーション７５４上または通信デバイス７５０上の他の場所に保存されているかどうかを判定し得る。代替で、または追加で、サービスプロバイダアプリケーション７５２は、サービスプロバイダアプリケーション７５２および／またはサービスプロバイダコンピュータ７６０内に保存された記録を検索してもよい。

ステップＳ７０２で、サービスプロバイダアプリケーション７５２は、アプリケーショントークンに対する要求をサービスプロバイダコンピュータ７６０に送信し得る。要求には、アプリケーショントークンに関する詳細（例えば、アムステルダムからミュンヘンまでの鉄道乗車券１枚）が含まれる場合がある。要求には、アプリケーショントークンの支払いに使用する口座番号などの支払情報が含まれる場合がある。実施形態によっては、要求は、これが第一のアプリケーショントークン要求であることを示す表示をさらに含み得る。要求は、通信デバイス７５０とサービスプロバイダコンピュータ７６０との間の有線または無線接続を介して送信されてもよい。サービスプロバイダコンピュータ７６０は、サービスプロバイダアプリケーション７５２から、アプリケーショントークンに対する要求を受信してもよい。

ステップＳ７０４で、サービスプロバイダコンピュータ７６０は、ユーザ、通信デバイス７５０、および／または支払情報を検証し、アプリケーショントークンを生成してもよい。アプリケーショントークンは、例えば、デジタルチケットの形式で生成され得る。アプリケーショントークンには、許可へのアクセスに関する情報（例えば、一つの鉄道の旅、特定のコンサートへのアクセス、特定の建物へのアクセスなど）が含まれる場合がある。アプリケーショントークンは、サービスプロバイダを特徴づける情報を含み得る（例えば、アプリケーショントークンは、サービスプロバイダがＴｒａｖｅｌ Ｃｏｒｐ．であることを指定するヘッダを含み得る）。アプリケーショントークンは、サービスプロバイダに固有の形式および／またはサイズでもよい。例として、一つのサービスプロバイダは、他のサービスプロバイダとは異なるタイプのファイルとしてアプリケーショントークンを保存してもよく、異なるサービスプロバイダは、異なるタイプの情報を保存するために異なるフィールドを設定する場合がある（例えば、一つのサービスプロバイダは、最初の３つのヘッダフィールドとして、日付、時間、サービスプロバイダＩＤを保存してもよく、別のサービスプロバイダは、最初の３つのヘッダフィールドとして、店の場所、金額、トークンＩＤを保存してもよい）。

サービスプロバイダコンピュータ７６０は、生成されたアプリケーショントークンを暗号化されたペイロード（例えば、ＪａｖａＳｃｒｉｐｔ Ｏｂｊｅｃｔ Ｎｏｔａｔｉｏｎ（ＪＳＯＮ）ウェブ暗号化ペイロード）にパッケージ化し得る。実施形態によっては、サービスプロバイダコンピュータ７６０は、一つの暗号鍵（例えば、一時的な公開楕円曲線暗号（ＥＣＣ）鍵）を保存してもよく、トークンサービスコンピュータ７７０は、別の対応する暗号鍵を保存してもよい。サービスプロバイダコンピュータ７６０は、アプリケーショントークンを暗号化してもよい。サービスプロバイダコンピュータ７６０は、少なくとも暗号化されたアプリケーショントークンを含む暗号化されたペイロードを生成し得る。

ステップＳ７０６で、サービスプロバイダコンピュータ７６０は、通信デバイス７５０にインストールされたサービスプロバイダアプリケーション７５２に暗号化されたペイロードを送信する。サービスプロバイダアプリケーション７５２は、暗号化されたペイロードを受信する。

ステップＳ７０８で、サービスプロバイダアプリケーション７５２は、暗号化されたペイロードをアカウント管理アプリケーション７５４にプッシュする。この時点では、アカウント管理アプリケーションは、暗号化されたパケットの内容を復号／表示できない可能性がある。

ステップＳ７１０で、アカウント管理アプリケーション２５４は、プロビジョニング要求をトークンサービスコンピュータ７７０に送信し得る。アカウント管理アプリケーション２５４は、さらに、トークンサービスコンピュータ７７０に、ユーザおよび／または通信デバイスの登録を要求してもよい。

トークンサービスコンピュータ７７０は、暗号化されたペイロードを受信時に復号し得る。トークンサービスコンピュータ７７０およびサービスプロバイダコンピュータ７６０は、アプリケーショントークンまたはその一部を暗号化および復号することを可能にする対称暗号鍵を共有し得る。他の実施形態では、トークンサービスコンピュータ７７０およびサービスプロバイダコンピュータ７６０はそれぞれ、公開鍵を利用して、アプリケーショントークンの一部分を暗号化し、秘密鍵を利用して、アプリケーショントークンの一部分を復号することができる。

実施形態によっては、トークンサービスコンピュータ７７０は、アプリケーショントークンに対してトークンコンテナを生成するべきであると判定し得る。トークンサービスコンピュータは、サービスプロバイダアプリケーション７５２および／またはアカウント管理アプリケーション７５４によって提供される情報に基づいて、受信した登録およびプロビジョニング要求にトークンコンテナが必要であるという表示を受信する場合がある。代替で、または追加で、トークンサービスコンピュータ７７０は、通信デバイス７５０および／またはアカウント管理アプリケーション７５４に関連付けられた保存されたデータの検索に基づいて、トークンコンテナが必要であると判断し得る。

トークンサービスコンピュータ７７０は、ユーザおよび／または通信デバイスをトークンサービスに登録するための操作を実行してもよい。登録には、例えば、暗号化鍵またはパスワードの発行が含まれる場合がある。

トークンサービスコンピュータ７７０は、トークンコンテナを生成する。トークンサービスコンピュータは、複数のアプリケーショントークンを保持できるトークンコンテナを生成し得る。例として、トークンコンテナには、少なくとも１００個の２０バイト長のアプリケーショントークンを保存する機能が含まれ得る。アプリケーショントークンの長さは、さまざまなサービスプロバイダに固有であってよい。トークンコンテナを生成して、アプリケーショントークンに関連付けられたトークンコンテナ記録を含めることができる。たとえば、トークンコンテナ記録の形式は、後続データの長さ（１バイト）、プログラム識別子（４バイト）、時間間隔（分）（２バイト）、およびアプリケーショントークン（１〜２５０バイト）などであってよい。トークンコンテナは、識別子（例えば、トークンコンテナに固有の１６桁の数字など）と関連付けられてもよい。また、トークンコンテナは、サービスプロバイダ７５０用に特にフォーマットされてもよく、他のサービスプロバイダ用の他のトークンコンテナは、同じまたは異なるフォーマットであってもよい。

トークンサービスコンピュータ７７０は、アプリケーショントークンを変更するための操作をさらに実行してもよい。トークンサービスコンピュータ７７０は、トークンサービスコンピュータ７７０の鍵を使用して、アプリケーショントークンに暗号形式で署名し得る。トークンサービスコンピュータ７７０は、アカウント管理アプリケーション７５４によって使用可能になるようにアプリケーショントークンをさらに変更してもよい。トークンサービスコンピュータ７７０は、例えば、アプリケーショントークンを第一の形式から第二の形式に変換してもよい。代替で、または追加で、トークンサービスコンピュータ７７０は、アプリケーショントークンに関連付けられたヘッダ情報を追加または変更してもよい。

ステップＳ７１２で、トークンサービスコンピュータ７７０は、アカウントトークンをアカウント管理アプリケーション７５４にプロビジョニングしてもよい。トークンサービスコンピュータ７７０は、アカウントトークンをアカウント管理アプリケーションに送信してもよい。トークンサービスコンピュータ７７０は、アプリケーショントークンと共にトークンコンテナを送信してもよい（例えば、アプリケーショントークンはトークンコンテナに保存される）。アカウント管理アプリケーションは、アカウント管理アプリケーションのトークンコンテナにアプリケーショントークンを受信し、保存することができる。アプリケーショントークンまたはアプリケーショントークンに関連付けられた補足データには、アプリケーショントークンを保存するトークンコンテナを識別するコンテナ識別子を含めることができる。

実施形態によっては、トークンサービスコンピュータ７７０は、通信デバイス７５０がアプリケーショントークンでプロビジョニングされたことを示すために、サービスプロバイダコンピュータ７６０に通知を送信してもよい。

図８は、いくつかの実施形態による、別のアプリケーショントークンのプロビジョニングプロセス８００を示す。通信デバイス８５０は、その中に、モバイルウォレットアプリケーションなどのアカウント管理アプリケーション８５４をインストールしてもよい。通信デバイス８５０は、さらに、サービスプロバイダアプリケーションＡ ８５２およびサービスプロバイダアプリケーションＢ ８５６を含む。アプリケーショントークンのプロビジョニングプロセス８００は、第一のプロビジョニング（例えば、図７に関連して上述された）の後の、後続のプロビジョニングイベントであってよい。

最初は、ユーザは、通信デバイス８５０と相互作用して、アプリケーショントークンを購入してもよい。ユーザは、例えば、サービスプロバイダアプリケーション８５２を介して、および／またはサービスプロバイダウェブサイトと通信するウェブブラウザを介して、購入のためにアプリケーショントークンを選択し得る。サービスプロバイダアプリケーションＡは、アプリケーショントークンおよび／またはトークンコンテナが通信デバイス８５０上に存在するかどうかを判定し得る。サービスプロバイダアプリケーションＡ８５２は、例えば、アカウント管理アプリケーション８５４に問い合わせて、アカウントトークンが以前にプロビジョニングされたかどうか、かつ／またはトークンコンテナが現在アカウント管理アプリケーション８５４に保存されているかどうかを判定し得る。代替で、または追加で、サービスプロバイダアプリケーションＡ８５２は、サービスプロバイダアプリケーションＡ８５２および／またはサービスプロバイダコンピュータＡ８６０内に保存された記録を検索してもよい。

ステップＳ８０２で、サービスプロバイダアプリケーションＡ ８５２は、アプリケーショントークンに対する要求をサービスプロバイダコンピュータＡ ８６０に送信し得る。要求には、アプリケーショントークンに関連する情報（例えば、ミュンヘンからプラハまでの鉄道乗車券１枚）が含まれる場合がある。要求には、アプリケーショントークンの支払いに使用する口座番号などの支払情報が含まれる場合がある。いくつかの実施形態では、要求は、これが後続のアプリケーショントークン要求である表示をさらに含み得る。要求は、通信デバイス８５０とサービスプロバイダコンピュータＡ８６０との間の有線または無線接続を介して送信されてもよい。

ステップＳ８０４で、サービスプロバイダコンピュータＡ８６０は、ユーザ、通信デバイス８５０、および／または支払情報を検証し、アプリケーショントークンを生成してもよい。アプリケーショントークンＡは、例えば、デジタルチケットの形式で生成されうる。アプリケーショントークンＡには、許可へのアクセスに関する情報（例えば、一つの鉄道の旅、特定のコンサートへのアクセス、特定の建物へのアクセスなど）が含まれる場合がある。アプリケーショントークンＡは、サービスプロバイダＡを特徴付ける情報を含み得る（例えば、アプリケーショントークンは、サービスプロバイダＡがＰｏｒｔｌａｎｄ Ｍｅｔｒｏｐｏｌｉｔａｎ Ｔｒａｎｓｉｔ Ａｕｔｈｏｒｉｔｙであることを示すヘッダを含み得る）。アプリケーショントークンＡは、サービスプロバイダＡに固有の形式および／またはサイズでもよい。

ステップＳ８０６で、サービスプロバイダコンピュータＡ ８６０は、アプリケーショントークン情報をトークンサービスコンピュータ８７０に送信する。サービスプロバイダコンピュータＡ８６０は、トークンサービスコンピュータ８７０に、この特定のアプリケーショントークン（例えば、特定の旅行またはイベント）に関する情報を送信してもよい。サービスプロバイダコンピュータＡ８６０は、以前にプロビジョニングされたトークンコンテナ（例えば、トークンコンテナの識別子）に関する情報をさらに送信し得る。

トークンサービスコンピュータ８７０は、アプリケーショントークン情報を受信し、アカウント管理アプリケーション８５４に送信するアプリケーショントークン情報を準備する。実施形態によっては、トークンサービスコンピュータ８７０は、アカウント管理アプリケーション８５４によって使用可能になるようにアプリケーショントークンを変更する操作を実行する。トークンサービスコンピュータ８７０は、例えば、アプリケーショントークンを第一の形式から第二の形式に変換してもよい。代替で、または追加で、トークンサービスコンピュータ８７０は、アプリケーショントークンに関連付けられたヘッダ情報を追加または変更してもよい。トークンサービスコンピュータ８７０は、トークンサービスコンピュータ８７０の鍵を使用して、アプリケーショントークンにさらに暗号形式で署名し得る。

ステップＳ８０８で、トークンサービスコンピュータ８７０は、アプリケーショントークン（アプリケーショントークンＡ）をアカウント管理アプリケーション８５４に送信する。トークンサービスコンピュータ８７０は、アプリケーショントークンＡを、特定の識別子（例えば、１２３４５９７８９）を有するトークンコンテナに保存する必要があることを示す情報と共に、アプリケーショントークンＡを送信してもよい。アカウント管理アプリケーション８５４は、アカウント管理アプリケーション８５４のトークンコンテナ内に、アプリケーショントークンＡを受信し、保存してもよい。

実施形態によっては、トークンサービスコンピュータ８７０は、通信デバイス８５０がアプリケーショントークンＡでプロビジョニングされたことを示すために、サービスプロバイダコンピュータＡ８６０に通知を送信してもよい。

その後、ユーザは、別のサービスプロバイダである、サービスプロバイダＢと関連付けられたアプリケーションと相互作用して、第二のアプリケーショントークンを購入し得る。例えば、アプリケーショントークンＡは、第一の鉄道プロバイダを介して購入された鉄道の旅の第一の区間用であってもよく、アプリケーショントークンＢは、第二の鉄道プロバイダを介して購入された鉄道の旅の第二の区間用であってもよい。もう一つの例として、アプリケーショントークンＡは、Ｔｒａｎｓｌｙｖａｎｉａｎ Ａｉｒｌｉｎｅｓのアプリケーションで購入したＴｒａｎｓｙｌｖａｎｉａｎ Ａｉｒｌｉｎｅｓの航空券である場合がある。ユーザは、その後、チケットアグリゲータアプリケーションを介して別のＴｒａｎｓｙｌｖａｎｉａｎ Ａｉｒｌｉｎｅｓの航空券を購入できる。ユーザは、サービスプロバイダアプリケーションＢ８５６を介してアプリケーショントークンＢの購入を開始することができる。代替で、または追加で、ユーザは、サービスプロバイダウェブサイトを介して（例えば、通信デバイス８５０上のウェブブラウザアプリケーションを介して）、アプリケーショントークンの購入を開始してもよい。

ステップＳ８１２で、サービスプロバイダアプリケーションＢ８５６は、アプリケーショントークンに対する要求をサービスプロバイダコンピュータＢ８８０に送信し得る。この要求には、アプリケーショントークンに関する情報が含まれる可能性がある。要求には、アプリケーショントークンの支払いに使用する口座番号などの支払情報が含まれる場合がある。いくつかの実施形態では、要求は、これが後続のアプリケーショントークン要求である表示をさらに含み得る。要求は、通信デバイス８５０とサービスプロバイダコンピュータＢ８８０との間の有線または無線接続を介して送信されてもよい。

ステップＳ８１４で、サービスプロバイダコンピュータＢ８６０は、ユーザ、通信デバイス８５０、および／または支払情報を検証し、アプリケーショントークンＢを生成し得る。アプリケーショントークンＢは、例えば、デジタルチケットの形式で生成され得る。アプリケーショントークンＢには、許可へのアクセスに関する情報（例えば、一つの鉄道の旅、特定のコンサートへのアクセス、特定の建物へのアクセスなど）が含まれる場合がある。アプリケーショントークンＢは、サービスプロバイダＢを特徴付ける情報を含み得る（例えば、アプリケーショントークンＢは、サービスプロバイダがＴｒａｖｅｌ Ｃｏｒｐ．であることを特定するヘッダを含み得る）。アプリケーショントークンＢは、サービスプロバイダＢに固有の形式および／またはサイズであり得る。一部の実施形態では、アプリケーショントークンの発行および／または検証は、別のサービスプロバイダとの通信を伴う場合がある。例えば、サービスプロバイダＢがチケット販売アプリケーションであり、かつ、サービスプロバイダＡがコンサート会場である場合、サービスプロバイダＢは、アプリケーショントークンＢを発行する前に、コンサート会場／サービスプロバイダＡからチケットの購入を調整することができる。

ステップＳ８１６で、サービスプロバイダコンピュータＢ ８８０は、アプリケーショントークン情報をトークンサービスコンピュータ８７０に送信する。サービスプロバイダコンピュータＢ８８０は、トークンサービスコンピュータ８７０に、この特定のアプリケーショントークン（例えば、特定の旅行またはイベント）に関する情報を送信し得る。サービスプロバイダコンピュータＢ８８０は、以前にプロビジョニングされたトークンコンテナ（例えば、トークンコンテナの識別子）に関する情報をさらに送信し得る。

トークンサービスコンピュータ８７０は、アプリケーショントークン情報を受信し、アカウント管理アプリケーション８５４に送信するアプリケーショントークン情報を準備する。実施形態によっては、トークンサービスコンピュータ８７０は、アカウント管理アプリケーション８５４によって使用可能になるようにアプリケーショントークンを変更する操作を実行する。トークンサービスコンピュータ８７０は、例えば、アプリケーショントークンを第一の形式から第二の形式に変換してもよい。代替で、または追加で、トークンサービスコンピュータ８７０は、アプリケーショントークンに関連付けられたヘッダ情報を追加または変更してもよい。トークンサービスコンピュータ８７０は、トークンサービスコンピュータ８７０の鍵を使用して、アプリケーショントークンにさらに暗号形式で署名し得る。

ステップＳ８１８で、トークンサービスコンピュータ８７０は、アプリケーショントークン（アプリケーショントークンＢ）をアカウント管理アプリケーション８５４に送信する。トークンサービスコンピュータ８７０は、アプリケーショントークンＢを、アプリケーショントークンＢが特定の識別子（例えば、１２３４５９７８９）を有するトークンコンテナに保存される必要があることを示す情報と共に送信しうる。アカウント管理アプリケーション８５４は、アカウント管理アプリケーションのトークンコンテナ内にアプリケーショントークンを受信し、保存してもよい。

実施形態によっては、トークンサービスコンピュータ８７０は、通信デバイス８５０がアプリケーショントークンＢでプロビジョニングされたことを示すために、サービスプロバイダコンピュータＢ８８０に通知を送信してもよい。

図９は、一部の実施形態による、アプリケーショントークンの引き換えプロセスを示す。ユーザは、通信デバイス９５０を使用して、アプリケーショントークン（図７および／または図８に関して上述したようにプロビジョニングされる）を引き換えることができる。通信デバイスは、アプリケーショントークンを引き換えるためにアクセスデバイス９６０と相互作用してもよく、アクセスデバイス９６０は、バックエンド上のサービスプロバイダコンピュータ９７０と通信してもよい。アクセスデバイス９６０は、例えば、交通機関代理店またはイベント会場のチケットスキャナであってもよい。別の例として、アクセスデバイス９６０は、ＰＯＳデバイスであってもよい。図９に示すように、アカウント管理アプリケーション９５２は、アプリケーショントークンの引き換えに使用される。他の実施形態では、アプリケーショントークンは、サービスプロバイダアプリケーションを介して引き換えることができる。

ステップＳ９０１では、アカウント管理アプリケーション９５２は、アクセスデバイス９６０と相互作用して、アプリケーショントークンを引き換える。相互作用は、例えば、ユーザが通信デバイス９５０をアクセスデバイスにタップすることを含んでもよい。アカウント管理アプリケーション９５２は、アクセスデバイスとの通信セッションを開始してもよい。通信セッションは、近距離通信（例えば、ＥＭＶ非接触仕様を使用して）を介してもよい。代替で、または追加で、アカウント管理アプリケーション９５２は、任意の適切な有線または無線の通信形態を介してアクセスデバイス９６０と相互作用し得る。相互作用に基づいて、アカウント管理アプリケーションは、アクセスデバイス９６０に、アプリケーショントークンに対する承認要求を送信することができる。

アカウント管理アプリケーション９５２は、アクセスデバイス９６０に、保存されたアプリケーショントークンのすべてまたは一部を送信してもよい。一部の実施形態において、ユーザは、まず適切なアプリケーショントークンを選択することができる（例えば、アカウント管理アプリケーション９５２を介して表示されるいくつかのチケットのうちの一つを選択することによって）。その後、アカウント管理アプリケーション９５２は、選択されたアプリケーショントークンをアクセスデバイス９６０にプッシュしてもよい。代替で、アカウント管理アプリケーションは、一つまたは複数の適切なアプリケーショントークンを識別して、アクセスデバイス９６０にプッシュしてもよい。例えば、アクセスデバイスは、アクセスデバイス識別子をアカウント管理アプリケーション９５２に送信する。アクセスデバイス識別子は、アクセスデバイスがＳｕｐｅｒ Ｔｉｘによって運営されていることを示す。したがって、アカウント管理アプリケーション９５２は、Ｓｕｐｅｒ Ｔｉｘと関連付けられると識別される４つのアプリケーショントークンを識別し、４つの識別されたアプリケーショントークンをアクセスデバイスに送信する。別の例として、アカウント管理アプリケーション９５２は、トークンコンテナ全体およびその中のすべてのアプリケーショントークンをアクセスデバイス９６０に送信し得る。

実施形態によっては、アカウント管理アプリケーション９５２および／またはアクセスデバイスは、現在および／または将来の引き換えの検証で使用するために、さらにイベント固有および／またはデバイス固有のデータを処理し得る。例えば、アクセスデバイス９６０は、アカウント管理アプリケーションに、タイムスタンプ、プログラム識別子、場所名、および／または端末識別子のうちの一つ以上を提供し得る。アカウント管理アプリケーション９５２はさらに、受信したタイムスタンプと比較するためのタイムスタンプを生成し得る。

実施形態によっては、アカウント管理アプリケーション９５２は、通信デバイス９５０上に保存された暗号化鍵（例えば、秘密鍵）を取得することができ、その後、取得した鍵を使用してイベント固有またはデバイス固有のデータに署名することができる。これは、サービスプロバイダコンピュータ９７０によって、通信デバイス９５０が要求を発信したことを検証するために、後で使用され得る。いくつかの実施形態では、検証は、イベントまたはデバイス固有のデータに署名した秘密鍵に関連付けられた公開鍵を使用して、サービスプロバイダコンピュータ９７０によって実行され得る。例えば、いくつかの実施形態では、イベント固有のデータはｎｏｎｃｅであってもよく、ｎｏｎｃｅは通信デバイス９５０上のセキュア要素内に存在する秘密鍵によって署名されてもよい。アカウント管理アプリケーション９５２は、ｎｏｎｃｅを生成してもよく、通信デバイス９５０上のセキュア要素から秘密鍵を取得して、それに署名してもよい。署名されたｎｏｎｃｅは、その後、サービスプロバイダコンピュータ９７０だけに、またはｎｏｎｃｅと共に提供され得る。これにより、サービスプロバイダコンピュータ９７０は、アカウント管理アプリケーション９５２およびアクセスデバイス９６０が通信デバイスを介して相互作用したこと、および引き換え要求が適切なアカウント管理アプリケーションから送信されていることを確認することができる。

ステップＳ９０２で、アクセスデバイス９６０は、一つまたは複数のアプリケーショントークンを受信し、分析する。アクセスデバイス９６０が複数のアプリケーショントークンを受信した場合、アクセスデバイス９６０は、引き換えのためのアクセストークンを識別し得る。アクセスデバイス９６０は、アクセスデバイスに関連付けられたパラメータをアプリケーショントークンデータと比較することに基づいて、引き換えのためのアクセストークンを識別し得る。例えば、アクセスデバイスはロンドンにあってもよい。アカウント管理アプリケーション９５２で４つの列車チケットを受領し、そのうちの一つの列車チケットがロンドンの出発地に関連付けられている場合、アクセスデバイス９６０は、アプリケーショントークンの詳細を使用して、ロンドンの出発地に関連付けられた引き換えのためのアプリケーショントークンを識別および選択することができる。

一部の実施形態において、アクセスデバイス９６０は、アプリケーショントークンをオフラインで検証する。アプリケーショントークンは、アプリケーショントークンを発行したトークンサービスコンピュータによって暗号形式で署名されている可能性がある。アクセスデバイス９６０は、アプリケーショントークンを発行したトークンサービスコンピュータの保存された暗号化鍵を持ち得る。アクセスデバイス９６０は、保存された暗号化鍵および所定のアルゴリズムを使用して、トークンサービスコンピュータの暗号化署名を検証し、それによって、他のコンピュータを問い合わせる必要なく、アプリケーショントークンを検証し得る。これは、アプリケーショントークンをすばやく、またはインターネットへの接続がない状況で検証する必要がある場合に特に有用である。例えば、交通機関の料金ゲートで、ユーザが迅速に通過できるように、チケットを迅速に検証することが望ましい。代替で、または追加で、アクセスデバイス９６０は、ステップＳ９０６に関して以下に説明するように、デバイスおよび／またはイベントデータを使用してアプリケーショントークンを検証してもよい。代替で、または追加で、アクセスデバイス９６０は、サービスプロバイダコンピュータ９７０によって検証される要求を転送してもよい。

一部の実施形態において、ステップＳ９０４で、アクセスデバイス９６０は、アプリケーショントークン承認要求をサービスプロバイダコンピュータ９７０に転送する。アクセスデバイス９６０は、受信したアプリケーショントークン承認要求を転送し得る。あるいは、アクセスデバイス９６０は、サービスプロバイダコンピュータ９７０に送信する前に、アプリケーショントークン承認要求を変更してもよい（例えば、受信したアプリケーショントークンのセットの一つを選択すること、トークン状態を変更すること、および／または同類のものによって）。アクセスデバイス９０６がすでにアプリケーショントークン承認要求を検証している場合、アクセスデバイス９０６は、要求が検証されたことを示すデータを含み得る。

ステップＳ９０６で、サービスプロバイダコンピュータ９７０は、アプリケーショントークン承認要求を受信し、処理する。サービスプロバイダコンピュータ９７０は、受信したアプリケーショントークン承認要求を検証してもよい。実施形態によっては、アクセスデバイス９６０は、アプリケーショントークン要求を既に検証している可能性があり、その場合、サービスプロバイダコンピュータ９７０は、検証を確認または記録してもよい。あるいは、サービスプロバイダコンピュータ９７０は、アプリケーショントークンを独立して検証してもよい。サービスプロバイダコンピュータは、例えば、アプリケーショントークンのデジタル署名を検証してもよい。別の例として、サービスプロバイダコンピュータ９７０は、受信したアプリケーショントークンを保存されたアプリケーショントークンと比較して、検証を実行してもよい。アプリケーショントークンを検証すると、サービスプロバイダコンピュータ９７０は、保存されたトークン状態を修正して、アプリケーショントークンを引き換えたものとして記録してもよい。

さらに、前述した署名済みのデバイスおよび／またはイベント固有のデータもまた、サービスプロバイダコンピュータ９７０によって検証できる。デバイスおよび／またはイベント固有のデータは、アクセスデバイス９６０および／または通信デバイス９５０から取得できる。例えば、いくつかの実施形態では、上述のように、デバイスおよび／またはイベント固有のデータは、通信デバイス９５０内のセキュア要素内の暗号鍵によって署名され得る。結果として生じるデジタル署名は、サービスプロバイダコンピュータ９７０によって、対応する暗号鍵（例えば、公開鍵）を使用して検証され、正しい通信デバイス９５０がアプリケーショントークンの引き換えを要求していることを確実にすることができる。

ステップＳ９０８で、サービスプロバイダコンピュータ９７０は、アクセスデバイス９６０にアプリケーショントークン承認応答を送信する。応答は、アプリケーショントークンが有効かどうかを示す。いくつかの実施形態では、ステップＳ９０８は省略されてもよい。例えば、アクセスデバイスがアプリケーショントークンをオフラインで検証した場合、アクセスデバイスがサービスプロバイダコンピュータ９７０から追加の検証情報を受信する必要はない可能性がある。

ステップＳ９１０で、アクセスデバイス９６０は、アカウント管理アプリケーション９５２に応答を送信する。一部の実施形態では、アクセスデバイス９６０は、要求が受信されたのと同じ近距離通信セッション内で応答を送信し得る。応答は、要求が検証されたかどうか（例えば、場所またはリソースへのアクセスが許可されるはずである）、または検証されていないかどうか（例えば、アクセスが拒否されるはずである）を示すことができる。要求／アプリケーショントークンが検証された場合でも、アクセスデバイスはこのようなアクセスを許可することができる（例えば、ゲートを開く、またはオペレータ（例えば、場所への入場を管理する人）に通知を送信することによって）。ステップ９１０は、アクセスデバイスがオフライン検証を実施した場合に、ステップ９０４〜９０８の前に発生し得る。あるいは、サービスプロバイダコンピュータ９７０がアプリケーショントークンを検証した場合、アクセスデバイス９６０は、ステップ９０４〜９０８の後にステップ９１０を実施することができる。

ステップＳ９１２で、アカウント管理アプリケーション９５２は、アプリケーショントークンに関連付けられたトークン状態を更新し得る。実施形態によっては、アカウント管理アプリケーションは、Ｓ９０１で要求を送信すると、アプリケーショントークンを「使用済み」としてマークすることによって、トークン状態を直ちに更新することができる。別の方法として、または追加的に、アカウント管理アプリケーション９５２は、Ｓ９１０の応答で受信した情報に基づいてトークン状態を更新し得る。

交通機関の環境
一部の実施形態によれば、強化されたトークン化システムは、交通機関の環境で使用され得る。交通機関の環境には、大量の交通機関のチケット発券や都市間の移動が含まれることがある。大量の交通機関のチケット発券には、チケットの価格が変動しない、ウォークイン客にサービスを提供する、従量制運賃の計算を行うという特徴があってもよく、通常、ゲートイン／ゲートアウト施設のある都市の地下鉄に関連付けられている。大量の交通機関のチケット発券は、オフラインのデータ認証を使用してもよく、摩擦が少なく、顧客満足度が高い非接触型カードやモバイルウォレットを使用できる。都市間移動の場合、顧客は、保証された座席（例えば、前払いの予約）、運賃の変動（例えば、早期予約は運賃を引き下げられ得る）を望む場合があり、大量の交通機関のチケット発券よりもチケットの価格が高い場合がある。運賃計算も複雑になる場合があり、片道か往復、シーズンパス、団体割引であるかなどが考慮され得る。駅はまたゲート解除されてもよく、チケット検査に頼る場合がある。

チケットの購入と表示は、サービスまたはアプリケーションプロバイダに関連付けられたチケット発券アプリケーションによって処理できる。実施形態によっては、一部の選択された旅行のみが、デジタルチケットの資格を得ることができ、トークン化システムによって処理され得る。チケット発券アプリケーションは、どの旅行が資格を得るかを示すことができる。チケット発券アプリケーションは、プッシュプロビジョニングによりデジタルチケットコンテナ（トークンコンテナ）を作成し（すでに存在しない場合）、交通機関のバックオフィスに、消費者の通信デバイスのデジタルトークンコンテナにチケットをプッシュするよう（例えば、アプリケーショントークンおよびトークン状態の形式で）通知することができる。交通機関のバックオフィスは、再パーソナライズを繰り返すことでトークンコンテナ内のチケットを追加／更新できる（例えば、トークン状態の更新）。チケット発券アプリケーションは、どのチケットが使用されたか、一部使用されたか、または未使用かを示す更新を交通機関のバックオフィスから受け取ることができる。実施形態によっては、トークンコンテナにプッシュされるチケットは、チケット発券アプリケーションから直接購入、本人による直接購入、またはウェブサイトを介したオンライン購入など、異なるソースから得ることができる。

実施形態によっては、消費者は、デフォルトの支払トークンが旅行に対して請求されるのを防ぐために、交通機関のゲートでタップする前にデジタルチケットコンテナを引き出してもよい。消費者は、消費者の通信デバイス上のモバイルウォレットアプリケーション上にデジタルチケットを引き出し、交通機関のゲートでタップすることができる。交通機関のゲートはトークンを読み取り（例えば、発行者の任意データとして送信することができる）、通信デバイスは交通機関のゲートデータを取引ログに書き込み得る。ゲートはチケットを検証し、消費者が交通機関のシステムにアクセスできるようにオープンにすることができる。交通機関のゲートは、取引ログにステーションＩＤを記録してもよい（例えば、ステーションＩＤおよびタイムスタンプをログに記録することができる）。取引ログは、パスバック制御と車中検証に使用できる。通信デバイスのデジタルトークンコンテナ内には、複数の有効なチケットが同時に存在できることに留意されたい。実施形態によっては、すべての有効なチケットは、タップ中にゲートに送信することができ（例えば、片道のチケットとシーズンパスが同時に存在し得る）、交通機関のバックオフィスは、どのチケットを使用済みとしてマークするかを判定するために規則を適用することができる。デジタルチケットは穴を開けることができるが（例えば、トークン状態を部分的に使用または使用された状態に更新）、デジタルトークンコンテナから削除する必要はない。一部の実施形態において、認証されたリーダのみがチケットに穴を開けることができる（例えば、デジタルトークンコンテナを読み取り、書き込み、更新する）。実施形態によっては、認証されたログ記録（例えば、暗号化されたログ記録）を使用して、不正行為を防止し、プライバシーを保護することができるが、システムに複雑さ（例えば、鍵管理）を追加する可能性がある。

本明細書に記述されるデジタルチケット発券トークン化は、タップアンドペイチケット履行機構としてアプリケーショントークンにトークンコンテナを使用する概念を包含する。トークンコンテナは、チケットの状態を安全に維持し、非接触メカニズム（近距離通信（ＮＦＣ）など）を使用してゲートリーダと通信し、チケット発行エンティティがその属性を動的にパーソナライズ（例えば、トークン状態を更新）できるようにする。トークンコンテナおよび／またはアプリケーショントークンを使用したタップは、支払い取引につながらない可能性があり、ゲートとチケット発行者（例えば、交通機関のオペレータ）の間のプライベート通信のみにつながる可能性がある。デジタルチケット発券トークン化は、即時のチケット発行を可能にし、非接触リーダ技術を使用してグローバルに相互運用可能にし、代替（紙チケット、ＱＲコードなど）よりも優れた顧客のユーザ体験を提供し、高負荷下でスケーラブルで信頼性の高い一方で、運用コストを低く抑えることができる。

ロイヤルティ環境
一部の実施形態によれば、強化されたトークン化システムを利用して、デジタルトークンコンテナに保存されたロイヤルティ情報を管理することもできる。発行者から提供されたロイヤリティ情報は、以下のように小売業者に配信され得る。発行者は、トークンアクティベーション要求（ＴＡＲ）応答の一部として、オプションでロイヤルティ情報を提供することができる。トークンサービスコンピュータは、プロビジョニング中にロイヤルティデータをトークン状態に動的に注入できる。デジタルウォレットアプリケーションは、支払い取引の一環として端末にロイヤルティ情報を送信する責任を負う場合がある。取引中に送信されるロイヤリティタグとサブタグに関して、発行者間で差異が生じる場合がある。各発行者は、専有タグを使用することができ、使用されるタグの数とこれらのタグが保持するコンテンツに差異が生じる場合がある。実施形態によっては、発行者が提供するロイヤルティデータは、可変長を有することができるファイル制御情報（ＦＣＩ）または発行者アプリケーションデータ（ＩＡＤ）内の発行者の任意データに保持することができる。トークンサービスコンピュータは、このデータをパーソナライズに（および再パーソナライズ中）に配置できる（例えば、トークン状態の更新）。ＦＣＩ発行者の任意データは、端末からのｓｅｌｅｃｔアプリケーション識別子コマンドに応じて端末に提供され、ＩＡＤ発行者の任意データは、端末からのｇｅｔ処理オプションコマンドに応じて端末に提供され得る。

図１０および図１１は、ロイヤルティ動作の例を示す。これらの例では、発行者（例えば、銀行）がロイヤルティデータ（例えば、ロイヤルティリワードの管理）を生成した。他の例では、ロイヤルティデータは、小売業者、交通機関プロバイダなどのサービスプロバイダによって生成され得る。

図１０は、一部の実施形態による、ロイヤルティデータフローを示す。実施形態によっては、発行者は、任意で、ＴＡＲ応答においてロイヤルティおよび追加の発行者データを返却することができる。第一のステップで、消費者はウォレットアプリケーションに関する発行者の利用規約を承諾してもよい。第二のステップで、ウォレットアプリケーションは、トークンサービスコンピュータへのプロビジョニングトークン呼び出しをトリガし得る。第三のステップでは、トークンサービスコンピュータは、トークンアクティベーションリクエスト（ＴＡＲ）を発行者に送信できる。第四のステップでは、発行者はＴＡＲに応答し、オプションでロイヤルティと追加の発行者の任意データを返却することができる。第五のステップで、トークンサービスコンピュータは、ロイヤルティおよび追加の発行者提供データをトークンのパーソナライズ（例えば、トークン状態）に注入してもよく、トークンのパーソナライズをウォレットアプリケーションに戻す。第六のステップで、ウォレットアプリケーションは、トークン（およびそのトークン状態）をコンシューマデバイスにプロビジョニングします。

図１１は、一部の実施形態による、ロイヤルティデータ更新フローを示す。発行者は、更新（例えば、交換／更新）によって変更される場合、ロイヤリティ（およびその他の発行者の任意データ）を更新することができる。これは、発行者が開始した再パーソナライズ（例えば、トークン状態の更新）を介して達成され得る。第一のステップで、発行者はＡＰＩ呼び出しを介して更新されたロイヤルティ情報をプッシュすることができる。第二のステップで、トークンサービスコンピュータは、この情報をトークンペルソに注入し、ウォレットアプリケーションに再度パーソナライズ呼び出し（例えば、トークン状態更新）をトリガすることができる。ウォレットアプリケーションは、トークンの新しいパーソナライズを取得し、ウォレットアプリケーションに保存されたパーソナライズ（例えば、トークン状態）を更新するために、トークンサービスコンピュータに連絡してもよい。

図１２は、一部の実施形態による、トークンおよびトークン状態を管理するためのプロセス１２００の流れ図を示す。プロセス１２００は、例えば、トークンサービスコンピュータに関連付けられたサーバコンピュータによって実施され得る。プロセス１２００は、ブロック１２０２で、アプリケーションプロバイダ（例えば、チケット発行エンティティ、交通機関事業者、小売業者など）から、ユーザの通信デバイスにアプリケーショントークンをプロビジョニングするためのプロビジョニング要求を受信することによって開始することができる。

ブロック１２０４では、アプリケーショントークンおよびアプリケーショントークンのトークン状態は、トークンヴォールト内のユーザに関連付けられた取引トークンにリンクされ得る。ブロック１２０６では、アプリケーショントークンおよびアプリケーショントークンのトークン状態は、ユーザの通信デバイスにプロビジョニングされ得る。ブロック１２０８で、プロセス１２００は、アプリケーショントークンのトークン状態を更新するために、アプリケーションプロバイダから状態更新要求を受信し得る。

ブロック１２１０で、プロセス１２００は、アプリケーショントークンのトークン状態を更新し得る。トークンヴォールトに保存されているアプリケーショントークンのトークン状態。ブロック１２１２で、トークンヴォールトに保存された更新されたトークン状態は、通信デバイスでトークン状態と同期され得る。一部の実施形態において、トークン状態は「パーソナライズ」と呼ばれてもよく、交通機関情報および／またはロイヤルティ情報などの使用情報を含んでもよい。

イベント固有のデータとデバイス固有のデータの例
通信デバイスおよびアクセスデバイスは、イベント固有のデータおよび／またはデバイス固有のデータを追跡、保存、および分析してもよい。このデータは、相互作用の検証、不正行為の監視および防止に使用される場合がある。さらに、交通機関の設定では、ユーザがいつアクセスデバイスにタップインまたはそれからタップアウトするかを追跡することが重要である（例えば、アプリケーショントークンが１日パスなどの期間に基づいている場合）。次の例は、通信デバイスおよびアクセスデバイスが管理するように構成することができるイベント固有のデータおよびデバイス固有のデータのタイプを示している。

アクセスデバイス
アクセスデバイスは、アカウント管理アプリケーションに次の情報を提供することができてもよい。
・ タイムスタンプ−正確なタイムスタンプ（５バイト）
・ タイムスタンプ変換係数−ユニバーサル時間（１バイト）に変換する係数
・ プログラム識別子−プログラム識別子（４バイト）
・ 期間番号−プログラムが割り当てた期間（２バイト）
・ 場所名−固有のプログラムが割り当てた場所（２０バイト）
・ 端末識別子−プログラム内の特定の場所に割り当てられた固有の端末（アクセスデバイス）識別子（２バイト）
上記のデータを正確に維持するのは、プログラムオペレーターの責任である。たとえば、電源障害またはシステムリセットの場合、タイムスタンプを同期する必要があり、期間が期限切れになるたびに、システム内のすべてのアクセスデバイスにわたって期間番号を増やす必要がある。

また、アクセスデバイスは、アカウント管理アプリケーションから提供される署名を検証できることが必要である。特定のアプリケーショントークンの受け入れまたは不正行為の判断に関するアクセスデバイス内のロジックは、プログラム固有である。

通信デバイス
アクセスデバイスのタイムスタンプを補完するものとして、アカウント管理アプリケーションは、通信デバイスユニバーサルタイムスタンプ（ＵＴＣ）を取得できる場合がある。これは、いくつかのメカニズムによって実現できる。
・ デバイスが全地球測位システム（ＧＰＳ）信号を取得できる場合、アプリはＧＰＳ信号の時刻にアクセスできる。
・ デバイスがネットワークにアクセスできる場合、セルネットワーク時間を取得したり、データサービスが利用可能な場合、複数のサービスから署名された時間を取得したりできる。
・ デバイスがネットワークまたはＧＰＳ信号にアクセスできない場合でも、アプリが最後の起動以降の正確な時間にどうにかアクセスできる限り、まだできることはある。デバイスは、最後のブートからの時間を追跡し続けている。このため、これは、受信した最後の正確な時間とともに、現在の正確な時間を計算するために使用できる。

アカウント管理アプリケーションには、次の機能を持つログを含めることができる。
・ 最小１００タップ（４０バイト／タップ＝４０００バイト）をログに記録する機能。
・ ログ記録のフォーマットは、以下の通り（区切り文字のない定義済みの長さ値）。
− 端末（アクセスデバイス）タイムスタンプ（５バイト）−端末発信元
− プログラム識別子（４バイト）−端末発信元
− 期間番号（２バイト）−端末発信元
− 場所名（２０バイト）−端末発信元
− 端末識別子（２バイト）−端末発信元
− アプリケーションのタイムスタンプ（５バイト）−アプリケーション配信元
− ステータスワード（２バイト）−アプリケーション発信元

トークンコンテナの仕様例
アカウント管理アプリケーションには、次の機能を持つトークンコンテナを含めることができる。
・ 最小１００、２０バイト長のチケット（２５００バイト）を保存する機能。
・ 記録の最大サイズは２５５バイト−５ヘッダバイトおよび２５０バイトのチケットブロブ（アプリケーショントークン）
アプリケーショントークンの実際の長さはプログラム固有であるため、コンテナに保存／維持できるアプリケーショントークンの実際の数は異なり、コンテナが最大容量に達するたびにガベージコレクションが確実に起こるようにすることは、アカウント管理アプリケーションおよび／またはトークンサービスコンピュータの責任である。

トークンコンテナ記録の形式は、以下の通り（長さ／値のペア）であってよい。
・ 後続データの長さ（１バイト）
・ プログラム識別子（４バイト）
・ 間隔（分）（２バイト）
・ チケットブロブ（アプリケーショントークン）（１〜２５０バイト）

本明細書に記載される技術は、複数の利点を有する。トークンサービスコンピュータによって、個々のサービスプロバイダアプリケーションを個々のアカウント管理アプリケーションと統合する必要はない。したがって、トークンサービスコンピュータによって実行される機能は、統合を簡素化し、スケーラビリティを向上させる。

さらに、本明細書に記載された暗号化技術は、デジタルチケットなどのアプリケーショントークンの発行および引き換えにおけるセキュリティを向上させる。データは署名され、セキュア鍵を使用して検証される。これらの暗号化操作は、相互作用固有のデータをさらに活用する場合がある。したがって、システムは、アプリケーションを使用して場所またはリソースにアクセスしようとするユーザ／デバイスが、アプリケーショントークンが発行されたユーザまたはデバイスであることを保証することができる。

追加の利点には、オフライン検証機能がある。アクセスデバイスは、バックエンドサーバと通信することなく、アプリケーショントークンが有効であることを暗号形式で検証できる。したがって、リモートサーバとの間でメッセージの送受信を行う場合よりも、アプリケーショントークンの検証がはるかに迅速になり得る。アプリケーショントークンは、インターネット接続なしでさらに検証できる。これらの改善は、速度と携帯性が重要な場合、交通機関の設定で特に有用である。

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

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

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

本明細書で説明される方法およびプロセスは本質的に例示的であり、一部の実施形態に従う方法およびプロセスは、そのステップの一つ以上を本明細書で説明されるものと異なる順番で実行してもよく、特に記載されていない一つまたは複数の追加のステップを含むことができ、一つまたは複数のステップを省略してもよく、一つまたは複数のステップを単一のステップにまとめることができ、一つまたは複数のステップを複数のステップおよび／またはそれらの任意の組み合わせに分けてもよい。

任意の実施形態の一つまたは複数の特徴は、本発明の範囲から逸脱することなく、他の実施形態の一つまたは複数の特徴と組み合わせることができる。

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

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

Claims (35)

1. 第一のサービスプロバイダコンピュータに通信デバイス上の第一のサービスプロバイダアプリケーションによって、第一のアプリケーショントークンに対する第一の要求を提供することと、
   前記第一のサービスプロバイダコンピュータと通信するトークンサービスコンピュータから、前記通信デバイス上のアカウント管理アプリケーションによって、前記第一のアプリケーショントークンを受信することと、
   前記アカウント管理アプリケーションのトークンコンテナに前記第一のアプリケーショントークンを保存することと、を含む方法。
2. 前記第一のアプリケーショントークン要求を提供した後、および前記第一のアプリケーショントークンを受信する前に、
   前記通信デバイス上の前記第一のサービスプロバイダアプリケーションによって、前記第一のサービスプロバイダコンピュータから暗号化されたアプリケーショントークンを受信することと、
   前記通信デバイス上の前記アカウント管理アプリケーションに前記通信デバイス上の前記第一のサービスプロバイダアプリケーションによって、前記暗号化されたアプリケーショントークンを提供することと、
   前記トークンサービスコンピュータに前記通信デバイス上の前記アカウント管理アプリケーションによって、前記暗号化されたアプリケーショントークンを提供することと、をさらに含む、請求項１に記載の方法。
3. 前記第一のアプリケーショントークンが前記アカウント管理アプリケーションによって受信されたときに、前記トークンコンテナが前記第一のアプリケーショントークンとともに受信される、請求項２に記載の方法。
4. 前記第一のアプリケーショントークン要求を提供する前に、前記トークンコンテナを受信し、保存することをさらに含む、請求項１に記載の方法。
5. 前記トークンサービスコンピュータおよび前記第一のサービスプロバイダコンピュータが、暗号化鍵ペアのそれぞれの暗号化鍵を持つ、請求項１〜４のいずれかに記載の方法。
6. 前記暗号化鍵ペアは対称鍵ペアである、請求項５に記載の方法。
7. 第二のサービスプロバイダコンピュータに前記通信デバイス上の第二のサービスプロバイダアプリケーションによって、第二のアプリケーショントークンに対する第二の要求を提供することと、
   前記第二のサービスプロバイダコンピュータと通信する前記トークンサービスコンピュータから、前記通信デバイス上の前記アカウント管理アプリケーションによって、前記第二のアプリケーショントークンを受信することと、
   前記アカウント管理アプリケーションの前記トークンコンテナに前記第二のアプリケーショントークンを保存することと、をさらに含む、請求項１に記載の方法。
8. メモリと、
   プロセッサと、
   前記プロセッサによって実行されるとき、
   第一のサービスプロバイダコンピュータに前記通信デバイス上の第一のサービスプロバイダアプリケーションによって、第一のアプリケーショントークンに対する第一の要求を提供するステップと、
   前記第一のサービスプロバイダコンピュータと通信するトークンサービスコンピュータから、前記通信デバイス上のアカウント管理アプリケーションによって、前記第一のアプリケーショントークンを受信するステップと、
   前記アカウント管理アプリケーションのトークンコンテナに前記第一のアプリケーショントークンを保存するステップと、を実行する命令を含む非一時的コンピュータ可読媒体と、を備える通信デバイス。
9. 前記ステップが、前記第一のアプリケーショントークン要求を提供した後、および前記第一のアプリケーショントークンを受信する前に、
   前記通信デバイス上の前記第一のサービスプロバイダアプリケーションによって、前記第一のサービスプロバイダコンピュータから暗号化されたアプリケーショントークンを受信することと、
   前記通信デバイス上の前記アカウント管理アプリケーションに前記通信デバイス上の前記第一のサービスプロバイダアプリケーションによって、前記暗号化されたアプリケーショントークンを提供することと、
   前記トークンサービスコンピュータに前記通信デバイス上の前記アカウント管理アプリケーションによって、前記暗号化されたアプリケーショントークンを提供することと、をさらに含む、請求項８に記載の通信デバイス。
10. 前記第一のアプリケーショントークンが前記アカウント管理アプリケーションによって受信されたときに、前記トークンコンテナが前記第一のアプリケーショントークンと共に受信される、請求項９に記載の通信デバイス。
11. 前記ステップが、前記第一のアプリケーショントークン要求を提供する前に、前記トークンコンテナを受信および保存することをさらに含む、請求項８に記載の通信デバイス。
12. 前記トークンサービスコンピュータおよび前記第一のサービスプロバイダコンピュータが、暗号化鍵ペアのそれぞれの暗号化鍵を持つ、請求項８〜１１のいずれかに記載の通信デバイス。
13. 前記暗号化鍵ペアが対称鍵ペアである、請求項１２に記載の通信デバイス。
14. 前記ステップが、
    第二のサービスプロバイダコンピュータに前記通信デバイス上の第二のサービスプロバイダアプリケーションによって、第二のアプリケーショントークンに対する第二の要求を提供することと、
    前記第一のサービスプロバイダコンピュータと通信する前記トークンサービスコンピュータから前記通信デバイス上の前記アカウント管理アプリケーションによって、前記第二のアプリケーショントークンを受信することと、
    前記アカウント管理アプリケーションの前記トークンコンテナに前記第二のアプリケーショントークンを保存することと、をさらに含む、請求項８に記載の通信デバイス。
15. 通信デバイス上のサービスプロバイダアプリケーションからサービスプロバイダコンピュータによって、アプリケーショントークンに対する要求を受信することと、
    前記サービスプロバイダコンピュータによって、前記通信デバイス上のアカウント管理アプリケーション上のトークンコンテナに前記アプリケーショントークンをプロビジョニングするための、トークンサービスコンピュータへのプロビジョニング要求を送信することと、を含む、方法。
16. 前記プロビジョニング要求を送信することが、
    前記サービスプロバイダアプリケーションに前記サービスプロバイダコンピュータによって、暗号化されたアプリケーショントークンを送信することと、
    それによって、前記サービスプロバイダアプリケーションに、前記プロビジョニング要求および前記暗号化されたアプリケーショントークンを前記トークンサービスコンピュータに送信させることと、を含む、請求項１５に記載の方法。
17. 前記アプリケーショントークンを生成することと、
    前記アプリケーショントークンを暗号化することと、をさらに含む、請求項１６に記載の方法。
18. 前記トークンコンテナが、前記アプリケーショントークンと共に前記アカウント管理アプリケーションに送信される、請求項１５〜１７のいずれかに記載の方法。
19. 前記サービスプロバイダコンピュータが、前記プロビジョニング要求を前記トークンサービスコンピュータに直接送信する、請求項１５に記載の方法。
20. 前記トークンコンテナが、前記受信前に前記アカウント管理アプリケーションに保存される、請求項１５または１９のいずれかに記載の方法。
21. メモリと、
    プロセッサと、
    前記プロセッサによって実行されるとき、
    通信デバイス上のサービスプロバイダアプリケーションから、アプリケーショントークンに対する要求を受信するステップと、
    前記通信デバイス上のアカウント管理アプリケーション上のトークンコンテナに前記アプリケーショントークンをプロビジョニングするために、プロビジョニング要求をトークンサービスコンピュータに送信するステップと、を実行する命令を含む非一時的コンピュータ可読媒体と、を備える、サービスプロバイダコンピュータ。
22. 前記プロビジョニング要求を送信することが、
    暗号化されたアプリケーショントークンを前記サービスプロバイダアプリケーションに送信することと、
    それによって、前記サービスプロバイダアプリケーションに、前記プロビジョニング要求および前記暗号化されたアプリケーショントークンを前記トークンサービスコンピュータに送信させることと、を含む、請求項２１に記載のサービスプロバイダコンピュータ。
23. 前記トークンコンテナが、前記アプリケーショントークンと共に前記アカウント管理アプリケーションに送信される、請求項２１または２２に記載のサービスプロバイダコンピュータ。
24. 前記サービスプロバイダコンピュータが、前記プロビジョニング要求を前記トークンサービスコンピュータに直接送信する、請求項２１に記載のサービスプロバイダコンピュータ。
25. 前記トークンコンテナが、前記受信前に前記アカウント管理アプリケーションに保存される、請求項２１または２４に記載のサービスプロバイダコンピュータ。
26. トークンサービスコンピュータで、通信デバイス上のアカウント管理アプリケーション上のトークンコンテナにアプリケーショントークンをプロビジョニングするためのプロビジョニング要求を受信することであって、前記通信デバイスが、サービスプロバイダコンピュータに関連付けられたサービスプロバイダアプリケーションも備える、受信することと、
    前記トークンサービスコンピュータから前記通信デバイス上の前記アカウント管理アプリケーションに、前記通信デバイス上の前記アカウント管理アプリケーション内の前記トークンコンテナへの前記アプリケーショントークンを送信することと、を含む、方法。
27. 前記トークンサービスコンピュータが、前記トークンコンテナを前記アプリケーショントークンと共に送信する、請求項２６に記載の方法。
28. 前記トークンサービスコンピュータが、前記アカウント管理アプリケーションから前記プロビジョニング要求を暗号化された形式で受信し、前記アプリケーショントークンを送信する前に前記アプリケーショントークンを復号する、請求項２６または２７に記載の方法。
29. 前記トークンサービスコンピュータが、前記プロビジョニング要求を受信する前に、前記トークンコンテナを送信した、請求項２６に記載の方法。
30. 前記トークンサービスコンピュータが、前記サービスプロバイダコンピュータから前記プロビジョニング要求を受信する、請求項２６または２９に記載の方法。
31. メモリと、
    プロセッサと、
    前記プロセッサによって実行されるとき、
    通信デバイス上のアカウント管理アプリケーション上のトークンコンテナにアプリケーショントークンをプロビジョニングするためのプロビジョニング要求を受信するステップであって、前記通信デバイスはサービスプロバイダコンピュータに関連付けられたサービスプロバイダアプリケーションも備える、ステップと、
    前記トークンサービスコンピュータから前記通信デバイス上の前記アカウント管理アプリケーションに、前記通信デバイス上の前記アカウント管理アプリケーション内の前記トークンコンテナへの前記アプリケーショントークンを送信するステップと、を実行する命令を含む非一時的コンピュータ可読媒体と、を備える、トークンサービスコンピュータ。
32. 前記トークンコンテナが、前記アプリケーショントークンと共に前記アカウント管理アプリケーションに送信される、請求項３１に記載のトークンサービスコンピュータ。
33. 前記プロビジョニング要求が、前記アカウント管理アプリケーションから暗号化された形式で受信され、前記アプリケーショントークンを送信する前に前記アプリケーショントークンを復号する、請求項３１または３２に記載のトークンサービスコンピュータ。
34. 前記トークンサービスコンピュータが、前記プロビジョニング要求を受信する前に、前記トークンコンテナを送信した、請求項３１に記載のトークンサービスコンピュータ。
35. 前記トークンサービスコンピュータが、前記サービスプロバイダコンピュータから前記プロビジョニング要求を受信する、請求項３１または３４に記載のトークンサービスコンピュータ。

Images