特表2024-545621 | 知財ポータル「IP Force」

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

▶ アメリカン　エキスプレス　トラヴェル　リレイテッド　サーヴィシーズ　カンパニー，　インコーポレイテッドの特許一覧

特表2024-545621モバイル・デバイス取引のクリデンシャル貸与

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1A
1B
2A
2B
3A
3B
4
5

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-12-10

(54)【発明の名称】モバイル・デバイス取引のクリデンシャル貸与

(51)【国際特許分類】

G06Q 20/38 20120101AFI20241203BHJP

H04L 9/10 20060101ALI20241203BHJP

H04L 9/14 20060101ALI20241203BHJP

G06Q 20/36 20120101ALI20241203BHJP

【ＦＩ】

G06Q20/38 310

H04L9/10 A

H04L9/14

G06Q20/36

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2024532492

(86)(22)【出願日】2022-11-30

(85)【翻訳文提出日】2024-07-18

(86)【国際出願番号】 US2022080617

(87)【国際公開番号】W WO2023102401

(87)【国際公開日】2023-06-08

(31)【優先権主張番号】17/539,380

(32)【優先日】2021-12-01

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＢＬＵＥＴＯＯＴＨ

(71)【出願人】

【識別番号】520107951

【氏名又は名称】アメリカンエキスプレストラヴェルリレイテッドサーヴィシーズカンパニー，インコーポレイテッド

【氏名又は名称原語表記】ＡＭＥＲＩＣＡＮＥＸＰＲＥＳＳＴＲＡＶＥＬＲＥＬＡＴＥＤＳＥＲＶＩＣＥＳＣＯＭＰＡＮＹ，ＩＮＣ．

【住所又は居所原語表記】２００ＶｅｓｅｙＳｔｒｅｅｔ，ＮｅｗＹｏｒｋ，ＮＹ１０２８５－４９００Ｕ．Ｓ．Ａ．

(74)【代理人】

【識別番号】100083116

【弁理士】

【氏名又は名称】松浦憲三

(74)【代理人】

【識別番号】100140992

【弁理士】

【氏名又は名称】松浦憲政

(74)【代理人】

【識別番号】100153822

【弁理士】

【氏名又は名称】増田重之

(72)【発明者】

【氏名】ビスワス，マニク

(72)【発明者】

【氏名】シャンカールシムハラグー，ムクンド

【テーマコード（参考）】

5L020

【Ｆターム（参考）】

5L020AA69

5L020AA72

(57)【要約】

第１のクライアント・デバイスが第２のクライアント・デバイスに非接触支払い用の支払いトークンの使用を認可できるようにするシステム及び方法が記載されており、支払いトークンは、第１のデバイスによって設定された制限を用いて第２のデバイスによる使用が認証される。一実施形態において、システムは、セキュア要素を含むコンピューティング・デバイスを備える。本システムはまた、プロセッサによって実行されると、コンピューティング・デバイスに、少なくとも、サブ支払いトークンを生成するための指示を受信させ、サブ支払いトークンに対する鍵制限の選択を受信させる、機械可読命令を含む。セキュア要素に記憶されたアプリケーションは、鍵制限に基づいてサブ支払いトークンを生成するために呼び出される。サブ支払いトークンは受信され、サブ支払い鍵とアプリケーション取引カウンタ範囲とを含む。サブ支払いトークンは、無線通信セッションを通じて第２のコンピューティング・デバイスに送信される。

【特許請求の範囲】

【請求項1】

プロセッサ、メモリ、及びセキュア要素を含むコンピューティング・デバイスであって、前記セキュア要素がアプリケーションを含む、コンピューティング・デバイスと、
前記メモリに記憶された機械可読命令であって、前記プロセッサによって実行されると、前記コンピューティング・デバイスに、少なくとも、
前記コンピューティング・デバイスに記憶された支払いトークンに付随するサブ支払いトークンを生成するための指示を受信することと、
前記サブ支払いトークンに対する鍵制限の選択を受信することと、
前記鍵制限に基づいて前記サブ支払いトークンを生成するために前記セキュア要素内の前記アプリケーションを実行することと、
前記アプリケーションから前記サブ支払いトークンを受信することであって、前記サブ支払いトークンがサブ支払い鍵及びアプリケーション取引カウンタ範囲を含む、前記サブ支払いトークンを受信することと、
クライアント・デバイスとの無線通信セッションを確立することと、
前記無線通信セッションを通じて前記サブ支払いトークンを前記クライアント・デバイスのウォレット・アプリケーションに送信することと
を行わせる、機械可読命令と、
を備える、システム。

【請求項2】

前記鍵制限が、カテゴリ制限パラメータ、単一の取引限度制限パラメータ、又は日付制限パラメータのうちの少なくとも一つを含む、請求項１に記載のシステム。

【請求項3】

前記アプリケーション取引カウンタ範囲が、前記サブ支払いトークンに対して許可された取引の数量に少なくとも部分的に基づいている、請求項１又は２に記載のシステム。

【請求項4】

前記ウォレット・アプリケーションが、第２のウォレット・アプリケーションであり、前記機械可読命令が、前記プロセッサによって実行されると、前記コンピューティング・デバイスに、少なくとも、
前記コンピューティング・デバイス上に第１のウォレット・アプリケーションのユーザ・インターフェースを表示させ、前記ユーザ・インターフェースが、前記鍵制限の前記選択を受信するように構成される、請求項１乃至３のいずれか一項に記載のシステム。

【請求項5】

前記サブ支払いトークンを前記クライアント・デバイスの前記ウォレット・アプリケーションに送信することが、前記コンピューティング・デバイスに、少なくとも、
前記セキュア要素に記憶された暗号鍵を使用して前記サブ支払いトークンをセキュア化すること
を更に行わせる、請求項１乃至４のいずれか一項に記載のシステム。

【請求項6】

前記サブ支払いトークンを前記クライアント・デバイスの前記ウォレット・アプリケーションに送信することが、ピアツーピア・メッセージング・プロトコルを使用することを含む、請求項１乃至５のいずれか一項に記載のシステム。

【請求項7】

前記セキュア要素が、前記コンピューティング・デバイスで実行されるプロセッサ・コンポーネント又は制限されたアプリケーション・コンポーネントである、請求項１乃至６のいずれか一項に記載のシステム。

【請求項8】

第１のクライアント・デバイスによって、第２のクライアント・デバイスとの無線通信セッションを確立することと、
前記第１のクライアント・デバイスによって、前記無線通信セッションを通じて前記第２のクライアント・デバイスからサブ支払いトークンを受信することであって、前記サブ支払いトークンがサブ支払い鍵及びアプリケーション取引カウンタ範囲を含み、前記サブ支払い鍵が前記第２のクライアント・デバイスに記憶された支払い鍵とリンクされている、サブ支払いトークンを受信することと、
前記第１のクライアント・デバイスによって、前記サブ支払いトークンを前記第１のクライアント・デバイスのセキュア要素で実行される支払いアプリケーションに提供することと、
前記第１のクライアント・デバイスによって、前記サブ支払いトークンを使用することによってポイント・オブ・セール端末で支払いを実行することと
を含む、方法。

【請求項9】

前記支払いが、近接場通信支払い又はクイック・レスポンス・コード支払いのうちの少なくとも一つである、請求項８に記載の方法。

【請求項10】

前記無線通信セッションがピアツーピア無線通信セッションである、請求項８又は９に記載の方法。

【請求項11】

前記サブ支払いトークンが暗号化ペイロードとして受信され、
前記第１のクライアント・デバイスによって、前記暗号化ペイロードを検証することと、
前記サブ支払いトークンにアクセスするために、前記第１のクライアント・デバイスによって、前記暗号化ペイロードを復号することと
を更に含む、請求項８乃至１０のいずれか一項に記載の方法。

【請求項12】

前記支払いを実行することが、
前記第１のクライアント・デバイスによって、前記ポイント・オブ・セール端末に、前記アプリケーション取引カウンタ範囲及び前記サブ支払い鍵を提供すること
を更に含む、請求項８乃至１１のいずれか一項に記載の方法。

【請求項13】

前記セキュア要素が、前記第１のクライアント・デバイスで実行されるプロセッサ・コンポーネント又は制限されたアプリケーション・コンポーネントである、請求項８乃至１２のいずれか一項に記載の方法。

【請求項14】

前記セキュア要素で実行される前記支払いアプリケーションに前記サブ支払いトークンを提供することが、
前記第１のクライアント・デバイスによって、認証クリデンシャルを前記セキュア要素に提供することによってセキュア要素セッションを確立すること
を更に含む、請求項８乃至１３のいずれか一項に記載の方法。

【請求項15】

コンピューティング・デバイスと、
プロセッサ及びメモリを含むセキュア要素と、
前記メモリに記憶された機械可読命令であって、前記プロセッサによって実行されると、前記セキュア要素に、少なくとも、
サブ支払い鍵を生成するために前記コンピューティング・デバイスで実行されるウォレット・アプリケーションからの要求を受信することであって、前記要求が鍵制限を含む、要求を受信することと、
前記セキュア要素に記憶された支払い鍵及び前記鍵制限に少なくとも部分的に基づいて、前記サブ支払い鍵を生成することと、
前記サブ支払い鍵を前記ウォレット・アプリケーションに返すことと
を行わせる、機械可読命令と
を備える、システム。

【請求項16】

前記セキュア要素が、前記支払い鍵についてのアプリケーション取引カウンタと、前記サブ支払い鍵についてのサブアプリケーション取引カウンタとを含む、請求項１５に記載のシステム。

【請求項17】

前記サブ支払い鍵が、カテゴリ制限パラメータ、単一の取引限度制限パラメータ、又は日付制限パラメータのうちの少なくとも一つを含む前記鍵制限を含む、請求項１５又は１６に記載のシステム。

【請求項18】

前記鍵制限が、口座名義人によって許可される取引の数量である、請求項１５乃至１７のいずれか一項に記載のシステム。

【請求項19】

前記サブ支払い鍵を生成することが、前記セキュア要素に、少なくとも、
前記口座名義人によって許可された取引の前記数量に少なくとも部分的に基づいて、アプリケーション取引カウンタ（ＡＴＣ）範囲を生成すること
を更に行わせる、請求項１８に記載のシステム。

【請求項20】

前記サブ支払い鍵が、前記ＡＴＣ範囲の開始値と前記ＡＴＣ範囲の終了値とを含む、請求項１９に記載のシステム。

【発明の詳細な説明】

【技術分野】

【0001】

関連出願の相互参照
本出願は、２０２１年１２月１日に提出された「ＭＯＢＩＬＥＤＥＶＩＣＥＴＲＡＮＳＡＣＴＩＯＮＣＲＥＤＥＮＴＩＡＬＬＥＮＤＩＮＧ」と題する米国特許出願第１７／５３９，３８０号に対する利益及び優先権を主張するものであり、その内容は参照によりその全体が本明細書に組み込まれる。

【背景技術】

【0002】

個人は、経済的支援を提供するため、誰かが自分の代わりに購入を行うことを可能にするため、又はその他の適切な理由などのために、様々な理由で他人にお金を貸与すること、又は与えることを望むことがある。場合によっては、個人が相手に現金を提供することを選択する場合がある。他の例では、個人は、相手に支払い手段（例えば、クレジット・カード、デビット・カード、ギフト・カードなど）を限定的な期間、貸与することを選択する場合がある。こうした選択肢では、個人は相手の支出行動をほとんど、又はまったく制御できない。

【発明の概要】

【課題を解決するための手段】

【0003】

本開示は、非接触支払い又はその他のデバイスベースの支払いのために、第１のデバイスが第２のデバイスに支払いトークン（例えば、支払い手段と関連付けられるトークン）を貸与できるようにすることに関する。第１のデバイスは、第２のユーザによる第２のデバイスでの支払いトークンの使用を限定するための制限を設けるように、貸与支払いトークンを構成することができる。したがって、実施形態は、バックエンド・サーバの関与なしに、第１のクライアント・デバイスが第２のクライアント・デバイスによって使用されるサブ支払いトークンを生成できるようにすることに関する。サブ支払いトークンは、第１のクライアント・デバイスから第２のクライアント・デバイスに直接通信することができる。サブ支払いトークンは、リアルタイム又はほぼリアルタイムの方法で、第１のクライアント・デバイスによって設定された制限付きで生成することができる。したがって、実施形態は、第１のデバイスから第２のデバイスに支払いクリデンシャルを貸与するための、より高速で安全な方法を提供する。

【0004】

非接触支払いは、非接触型ポイント・オブ・セール端末でのもう一つの有効な支払い技法となっている。典型的な非接触支払いのシナリオでは、（例えば、取引口座の支払いトークンを有する）モバイル・デバイスと問い合わせ側デバイス（例えば、ポイント・オブ・セールデバイス）は、支払いモードについて合意する。支払いモードに基づいて、モバイル・デバイスによってアプリケーション暗号文が生成される。アプリケーション暗号文は、そのイシュアから認証を得るために、問い合わせ側デバイスが使用することができる。アプリケーション暗号文は、少なくとも二つの保証を提供することができる：１）モバイル・デバイスが、イシュアによって生成／管理されるアカウント固有秘密鍵（ＡＳＳＫ：ＡｃｃｏｕｎｔＳｐｅｃｉｆｉｃＳｅｃｒｅｔＫｅｙ）（例えば、支払い鍵）を有していること；及び２）モバイル・デバイスが、取引固有データを使用してアプリケーション暗号文を生成することにより、支払いをローカル認証したエンティティであること。

【0005】

場合によっては、ＡＳＳＫは機密性の高いデータ要素として扱われ、強力なセキュリティ制御で管理される。従来、これらの鍵のライフサイクルを管理するために、ハードウェア・セキュリティ・モジュールが使われている。これらの鍵の寿命はイシュア定義であり、イシュアの製品要件に応じて数分から数年に及ぶ。

【0006】

アプリケーション暗号文とは別に、モバイル・デバイスと問い合わせ側デバイスは、取引の決済に要求される複数の他のデータ要素を交換することができる。いくつかの非限定的な例としては、永久口座番号（ＰＡＮ）、有効期限、ＰｒｏｃｅｓｓｉｎｇＤａｔａＯｂｊｅｃｔＬｉｓｔなどが挙げられる。これらの要素は、それらの製品要件に応じてイシュアによって生成／管理される。

【0007】

本開示の様々な実施形態は、第１のデバイスが、ユーザが選択した制限付きの非接触支払いに使用可能なトークン（例えば、支払い手段）を第２のデバイスに安全に貸与することを可能にすることによって、非接触支払いの分野を改善する。例えば、前述したＡＳＳＫ（例えば、支払い鍵）は、一般に、口座名義人ユーザのモバイル・デバイスに転送される前に、イシュアによって生成又は導出される。一般に、セキュア要素によって強制されるセキュリティ制御のため、口座名義人ユーザは、それを抽出したり、他人に渡したりすることはできない。これにより、彼又は彼女の支払いカードを他人に貸与したいと思っている口座名義人ユーザの可能性は短期間制限されるが、適切なセキュリティ及び制限が伴う。実施形態では、口座名義人ユーザの支払い鍵を使用して、別のデバイスに提供可能なサブ支払い鍵を導出することができる。

【0008】

いくつかの実施形態では、支払い鍵（例えば、ＡＳＳＫ）を保持しているモバイル・デバイスは、モバイル・デバイスによって定義された限られた数の取引で有効であるように設定することができるセッションベースのサブ支払い鍵（例えば、アカウント固有サブ秘密鍵（ＡＳＳＳＫ：ＡｃｃｏｕｎｔＳｐｅｃｉｆｉｃＳｕｂＳｅｃｒｅｔＫｅｙ）を導出する。このように、モバイル・デバイスは、サブ支払い鍵及びその他の関連データを別の受信者に送信することができ、これにより、受信者は、ＰＯＳ端末での通常の非接触支払い又は通常のオンライン購入を行うことができる。いくつかの実施形態では、累積取引総額、単一の取引値限度など、追加的なリスク・パラメータを、イシュアの要求に応じてこのサブ支払い鍵に追加することができる。以下の議論は、本開示の様々なコンポーネントの動作の例示的な例を提供するが、以下の例示的な例の使用は、以下の例示的な例によって開示される原理と一致する他の実装形態を排除するものではない。

【図面の簡単な説明】

【0009】

本開示の多くの態様は、以下の図面を参照すると、より良く理解することができる。図面のコンポーネントは、必ずしも縮尺通りではなく、代わりに本開示の原理を明確に図示することに重点が置かれている。更には、図面では同様の符号は、いくつかの図を通じて対応する部分を指している。

【0010】

【図1A】図１Ａは、本開示の様々な実施形態による、ネットワーク化環境の図である。

【図1B】図１Ｂは、本開示の様々な実施形態による、図１Ａのネットワーク化環境における第１のクライアント・デバイスのオペレーティング・システム層の図である。

【図2A】図２Ａは、本開示の様々な実施形態による、図１Ａのネットワーク化環境内のコンピューティング環境で実行される第１のウォレット・アプリケーションの一部として実装される機能性の一例を示すフローチャートである。

【図2B】図２Ｂは、本開示の様々な実施形態による、図１Ａのネットワーク化環境内のコンピューティング環境で実行される第１の支払いアプリケーションの一部として実装される機能性の一例を示すフローチャートである。

【図3A】図３Ａは、本開示の様々な実施形態による、図１Ａのネットワーク化環境内のコンピューティング環境で実行される第２のウォレット・アプリケーションの一部として実装される機能性の一例を示すフローチャートである。

【図3B】図３Ｂは、本開示の様々な実施形態による、図１Ａのネットワーク化環境内のコンピューティング環境で実行される第２の支払いアプリケーションの一部として実装される機能性の一例を示すフローチャートである。

【図4】図４は、本開示の様々な実施形態による、図１Ａのネットワーク化環境内のコンピューティング環境で実行されるイシュア・サービスの一部として実装される機能性の一例を示すフローチャートである。

【図5】図５は、本開示の様々な実施形態による、図１Ａのネットワーク環境の様々なコンポーネント間の対話の一例を図示するシーケンス図である。

【発明を実施するための形態】

【0011】

図１Ａを参照すると、様々な実施形態による、ネットワーク化環境１００が示される。ネットワーク化環境１００は、コンピューティング環境１０３、第１のクライアント・デバイス１０６、第２のクライアント・デバイス１０９、及びポイント・オブ・セール（ＰＯＳ）端末１１２を含み、これらはネットワーク１１５を介して互いにデータ通信をしている。ネットワーク１１５は、例えば、インターネット、イントラネット、エクストラネット、ワイド・エリア・ネットワーク（ＷＡＮｓ）、ローカル・エリア・ネットワーク（ＬＡＮｓ）、有線ネットワーク、無線ネットワーク、ピアツーピア・ネットワーク、又は他の適切なネットワークなど、又は二つ以上のそのようなネットワークの任意の組合せを含む。例えば、このようなネットワークは、衛星ネットワーク、ケーブル・ネットワーク、イーサネット・ネットワーク、及びその他の種類のネットワークを含むことができる。ネットワーク１１５は複数のネットワークを表すことができ、ネットワーク１１５に接続されたデバイスは、ネットワーク１１５に接続された他のデバイスとデータ通信を行うことができる。

【0012】

コンピューティング環境１０３は、サーバ・コンピュータ又はコンピューティング機能を提供する任意の他のシステムを含むことができる。代替的に、コンピューティング環境１０３は、例えば、一つ若しくは複数のサーバ・バンク、一つ若しくは複数のコンピュータ・バンク、又は他の配置で構成することが可能な複数のコンピューティング・デバイスを採用することが可能である。そのようなコンピューティング・デバイスは、単一の施設に配置することが可能である、又は多くの異なる地理的場所に分散することが可能である。例えば、コンピューティング環境１０３は、ホストされたコンピューティング・リソース、グリッド・コンピューティング・リソース、及び／又は任意の他の分散型のコンピューティング用配置を共に含むことが可能な複数のコンピューティング・デバイスを含むことが可能である。場合によっては、コンピューティング環境１０３は、処理、ネットワーク、ストレージ、又は他のコンピューティング関連リソースの配分されたキャパシティが経時的に変化し得る、弾力的なコンピューティング・リソースに対応することが可能である。

【0013】

様々なアプリケーション及び／又は他の機能性は、様々な実施形態によりコンピューティング環境１０３内で実行することが可能である。また、様々なデータは、コンピューティング環境１０３からアクセス可能なデータ・ストア１１８に記憶される。理解され得る通り、データ・ストア１１８は、複数のデータ・ストア１１８の代表であってもよい。データ・ストア１１８に記憶されるデータは、例えば、以下で説明される様々なアプリケーションの動作及び／又は機能的なエンティティに関連付けられる。

【0014】

コンピューティング環境１０３上で実行されるコンポーネントには、例えば、イシュア・サービス１２１及び他のアプリケーション、サービス、プロセス、システム、エンジン、又は本明細書で詳細に議論しない機能性が含まれる。イシュア・サービス１２１は、ＰＯＳ端末１１２からの取引要求を認証するかどうかを決定するために実行され得る。イシュア・サービス１２１は、サブ支払い鍵１２３を使用した取引要求を識別し、認証することができる。イシュア・サービス１２１は、サブ支払い鍵１２３と関連付けられる取引制限を強制することができ、この取引制限は口座名義人によって設定されている。

【0015】

データ・ストア１１８に記憶されるデータは、例えば、金融機関での金融口座名義人のユーザ・アカウント１２４、及び潜在的に他のデータを含む。ユーザ・アカウント１２４は、支払いトークン１２７、金融口座に関連付けられた支払い鍵１３０、及び／又は潜在的に他のデータを含むことができる。

【0016】

支払いトークン１２７は、クレジット・カード、デビット・カート、ギフト・カード、ウォレット・アプリケーション、及び／又は他の適切な金融商品などの金融口座番号を表すことができる。支払いトークン１２７は、取引１３３及びサブ支払いトークン１３４を含むことができる。取引１３３は、ユーザ・アカウント１２４の口座名義人によって実行された金融取引を表すことができる。

【0017】

サブ支払いトークン１３４は、ユーザ・アカウント１２４の口座名義人によって生成され、制御されるトークン又は特定の支払い手段を表すことができる。サブ支払いトークン１３４は、支払いトークン１２７に付随され得る。サブ支払いトークン１３４は、第２のユーザによって実行されたサブ取引１３６を認証するためのサブ支払い鍵１２３にリンクされ得る。サブ支払いトークン１３４は、経済的支援を提供するため、第２のユーザが口座名義人の代わりに購入を行うことを可能にするため、及び／又は他の金融上の状況のために、制限付きで第２のユーザに提供され得る。サブ支払いトークン１３４は、口座名義人の第１のクライアント・デバイス１０６によって生成され得る。サブ取引１３６は、第２のユーザによって行われた金融取引を表すことができる。

【0018】

支払い鍵１３０は、金融エンティティのイシュア・システムによって生成又は管理される鍵を表すことができる。支払い鍵１３０は、モバイル・デバイスによって行われる取引１３３（例えば、ＰＯＳ端末での非接触支払い、又は第１のクライアント・デバイス１０６によって行われるオンライン取引）を検証するために使用され得る。アプリケーション暗号文が問い合わせ側デバイスに提供されると、セキュリティ機構として支払い鍵１３０が提供される。支払い鍵１３０の非限定的な一例は、アカウント固有秘密鍵である。支払い鍵１３０は、機密性の高いデータ要素として扱われ得、したがって、強力なセキュリティ制御により管理され得る。例えば、支払い鍵１３０は、認証した後にアクセス権が付与されるハードウェア・セキュリティ・モジュールに記憶され得る。別の例として、アカウント固有秘密鍵（例えば、支払い鍵１３０）を抽出して別のユーザに転送することはできない。ハードウェア・セキュリティ・モジュールは、支払い鍵１３０のライフサイクルを管理するために使うことができる。これらの支払い鍵１３０の寿命はイシュア定義であり、イシュアの製品要件に応じて数分から数年に及ぶ。

【0019】

第１のクライアント・デバイス１０６及び第２のクライアント・デバイス１０９は、ネットワーク１１５に結合され得る複数のクライアント・デバイスの代表である。第１のクライアント・デバイス１０６及び第２のクライアント・デバイス１０９は、例えば、コンピュータ・システムのようなプロセッサベースのシステムを含むことができる。このようなコンピュータ・システムは、デスクトップ・コンピュータ、ラップトップ・コンピュータ、携帯情報端末、携帯電話、スマートフォン、セットトップ・ボックス、音楽プレーヤ、ウェブ・パッド、タブレット・コンピュータ・システム、ゲーム機、電子ブック・リーダ、又は同様の機能を有する他のデバイスの形態で具体化され得る。第１のクライアント・デバイス１０６及び第２のクライアント・デバイス１０９は、ディスプレイを含むことができる。ディスプレイは、例えば、液晶ディスプレイ（ＬＣＤ）ディスプレイ、ガス・プラズマベースのフラット・パネル・ディスプレイ、有機発光ダイオード（ＯＬＥＤ）ディスプレイ、電気泳動式インク（Ｅインク）ディスプレイ、ＬＣＤプロジェクタ、又は他のタイプのディスプレイ・デバイスなどの、一つ又は複数のデバイスを含んでよい。

【0020】

第１のクライアント・デバイス１０６及び第２のクライアント・デバイス１０９は、それぞれ、第１のセキュア要素１６５及び第２のセキュア要素１６８を有することができる。第１のセキュア要素１６５及び第２のセキュア要素１６８は、ハードウェア・コンポーネントとして、ソフトウェア・コンポーネントとして、又はハードウェアとソフトウェアとの組合せとして実装され得る。第１のセキュア要素１６５及び第２のセキュア要素１６８は、制限されたアプリケーションの限られたセットを実行することができ、また、機密支払い情報、識別情報クリデンシャル、暗号データ、及び／又は潜在的に他の機密データを記憶することができる。いくつかの実施形態において、第１のセキュア要素１６５及び第２のセキュア要素１６８は、耐改ざん性のコンピューティング・デバイスを含み、このコンピューティング・デバイスは、プロセッサ及びメモリを含む。場合によっては、セキュア要素を実装するために使用されるハードウェア・コンポーネント及び／又はソフトウェア・コンポーネントは、ＧｌｏｂａｌＰｌａｔｆｏｒｍ（登録商標）といったセキュリティ標準化団体によって保証されている。

【0021】

第１のクライアント・デバイス１０６は、ユーザ・アカウント１２４の口座名義人によって使用され得る。第１のクライアント・デバイス１０６は、第１のウォレット・アプリケーション１７１及び／又は他のアプリケーションなどの様々なアプリケーションを実行するように構成され得る。第１のウォレット・アプリケーション１７１は、取引を実行するための支払い情報（例えば、支払いトークン１２７）を提供するために実行され得、他の個人に貸与するためのサブ支払い鍵１２３を生成するために実行され得る。第１のウォレット・アプリケーション１７１はまた、例えば、コンピューティング環境１０３及び／又は他のサーバによって出されるネットワーク・コンテンツにアクセスし、それによってディスプレイに第１のユーザ・インターフェース１７３をレンダリングするために、第１のクライアント・デバイス１０６において実行され得る。このため、第１のウォレット・アプリケーション１７１は、例えば、ブラウザ、専用アプリケーションなどを含むことができ、ユーザ・インターフェース１７３は、ネットワーク・ページ、アプリケーション画面などを含んでもよい。第１のクライアント・デバイス１０６は、例えば、電子メール・アプリケーション、ソーシャル・ネットワーキング・アプリケーション、ワード・プロセッサ、スプレッドシート、及び／又は他のアプリケーションなど、第１のウォレット・アプリケーション１７１以外のアプリケーションを実行するように構成されてもよい。

【0022】

第１のセキュア要素１６５は、ユーザ・アカウント１２４の口座名義人によって選択された認証されたユーザによって使用されるサブ支払い鍵１２３を生成するための第１の支払いアプリケーション１７５を含むことができる。第１のセキュア要素１６５は、支払いトークン１２７、支払い鍵１３０、サブ支払いトークン１３４、サブ支払い鍵１２３、及びその他の潜在的データを記憶することができる。サブ支払い鍵１２３は、ユーザ・アカウント１２４の口座名義人によって設定された一つ又は複数の鍵制限１７８と関連付けられる。

【0023】

第１の支払いアプリケーション１７５は、第１のセキュア要素１６５上で実行される一つ又は複数のアプリケーションを表すことができる。例えば、第１の支払いアプリケーション１７５は、支払い鍵１３０を提供することによって取引を促進するために実行される、又はサブ支払い鍵１２３を生成するために実行される支払いアプレットを含むことができる。

【0024】

サブ支払い鍵１２３は、支払い鍵１３０に付随する鍵を表すことができる。サブ支払い鍵１２３は、口座名義人が別の個人に支払いトークン１２７（例えば、クレジット・カード、チャージ・カード、デビット・カード、ギフト・カードなどの支払い手段）を貸与する機構を提供するために、ユーザ・アカウント１２４の口座名義人によって生成され得る。別の個人は、近接場通信タップ、オンライン購入、クイック・レスポンス・コード購入、及びデバイスを用いた他の適切な非接触購入などによる様々な方法で購入を行うために、第２のクライアント・デバイス１０９でトークンを使用することができる。

【0025】

サブ支払い鍵１２３は、第１のクライアント・デバイス１０６において第１のセキュア要素１６５によって生成され得る。サブ支払い鍵１２３は、支払い鍵１３０から導出され得、ユーザ・アカウント１２４の口座名義人に対して設定された鍵制限１７８を示す様々なパラメータを含むことができる。いくつかの例では、サブ支払い鍵１２３は、支払い鍵１３０、アプリケーション取引カウンタ範囲、サブＡＴＣ、制限パラメータ（例えば、鍵制限１７８）、及び他の適切なデータ要素を含む。いくつかの実装形態において、サブ支払い鍵１２３は、アカウント固有秘密サブ鍵であり得る。

【0026】

鍵制限１７８は、口座名義人によって第１のクライアント・デバイス１０６から選択された、サブ支払い鍵１２３に対する一つ又は複数の取引制限を表すことができる。鍵制限１７８のいくつかの非限定的な例は、認証される取引の数量（例えば、５つの許可された取引）、サブ支払い鍵１２３を使用する期間（例えば、１週間、１ヶ月、６ヶ月）、取引カテゴリ（例えば、航空券、カーレンタル、食品、住宅、小売、教育）、取引金額の制限（例えば、購入は１００ドルを超えることができない）、制限場所（例えば、購入はシカゴ市内で許可される）、及び他の適切な取引制限を含む。いくつかの実施形態では、鍵制限１７８はイシュア・サービス１２１によって強制され得る。イシュア・サービス１２１は、サブ支払い鍵１２３に設定された鍵制限１７８と取引要求に関連付けられた取引データに基づいて、取引要求を承認するか拒否するかを決定することができる。例えば、イシュア・サービス１２１は、取引データ（例えば、取引金額、取引場所、取引カテゴリ・タイプ、参加マーチャント、取引日時など）を、サブ支払い鍵１２３の鍵制限１２３として設定されたパラメータと比較することによって、鍵制限１７８を強制することができる。このように、サブ支払い鍵１２３を受信すると、イシュア・サービス１２１は、鍵制限１７８として設定されたパラメータを確認し、それに従っているか、それらのパラメータを取引データと比較することができる。

【0027】

取引データが鍵制限１７８に従うものでない場合、イシュア・サービス１２１は取引が拒否されたことをＰＯＳ端末１１２に通知することができる。例えば、サブ支払い鍵１２３は、取引が１００ドルを超えることができないという鍵制限１７８を有することができる。この鍵制限１７８は、パラメータとしてサブ支払い鍵１２３に含まれ得る。取引要求がイシュア・サービス１２１に提出されると、サブ支払い鍵１２３と取引データもイシュア・サービス１２１に提出される。取引データが、取引が２００ドルのコストがかかるものの購入であることを示す場合、イシュア・サービス１２１は、２００ドルというコストを、鍵制限１７８によって設定された１００ドルという限度と比較することができる。したがって、イシュア・サービス１２１は、取引が拒否されたことをＰＯＳ端末１１２に通知することができる。

【0028】

第２のクライアント・デバイス１０９は、ユーザ・アカウント１２４の口座名義人からサブ支払い鍵１２３を受け取っている別の個人によって使用され得る。第２のクライアント・デバイス１０９は、第２のウォレット・アプリケーション１８１及び／又は他のアプリケーションなど、様々なアプリケーションを実行するように構成され得る。第２のウォレット・アプリケーション１８１は、取引中の支払い情報をＰＯＳ端末１１２に提供するために実行され得る。いくつかの実施形態では、第２のウォレット・アプリケーション１８１は、第１のクライアント・デバイス１０６から送信されたサブ支払い鍵１２３を受信し、非接触取引中にサブ支払い鍵１２３をＰＯＳ端末１１２に提供するために実行され得る。第２のウォレット・アプリケーション１８１はまた、例えば、コンピューティング環境１０３及び／又は他のサーバによって出されるネットワーク・コンテンツにアクセスし、それによってディスプレイに第２のユーザ・インターフェース１８３をレンダリングするために、第２のクライアント・デバイス１０９において実行され得る。このため、第２のウォレット・アプリケーション１８１は、例えば、ブラウザ、専用アプリケーションなどを含むことができ、第２のユーザ・インターフェース１８３は、ネットワーク・ページ、アプリケーション画面などを含んでもよい。第２のクライアント・デバイス１０９は、例えば、電子メール・アプリケーション、ソーシャル・ネットワーキング・アプリケーション、ワード・プロセッサ、スプレッドシート、及び／又は他のアプリケーションなど、第２のウォレット・アプリケーション１８１以外のアプリケーションを実行するように構成されてもよい。

【0029】

第１のセキュア要素１６５と同様に、第２のセキュア要素１６８は、第１のクライアント・デバイス１０６から受信された第２の支払いアプリケーション１８５及びサブ支払い鍵１２３を含むことができる。第２のセキュア要素１６８は、サブ支払いトークン１３４、サブ支払い鍵１２３、及びその他の潜在的データを記憶することができる。第２の支払いアプリケーション１８５は、第１の支払いアプリケーション１７５と機能的に同様のものとすることができる。

【0030】

次に、図１Ｂは、第１のクライアント・デバイス１０６がオペレーティング・システム層１８７を有することを示す。オペレーティング・システム層１８７は、コンピューティング・ハードウェア及びソフトウェア・リソースを管理するシステム・ソフトウェアであり得る。同様のオペレーティング・システム層１８７は第２のクライアント・デバイス１０９に実装され得る。いくつかの実施形態において、オペレーティング・システム層１８７は、第１のウォレット・アプリケーション１７１が第１のセキュア要素１６５と通信することを可能にするアプリケーション・プログラミング・インターフェースを有し得る。加えて、第１のセキュア要素１６５は、一つ又は複数の第１の支払いアプリケーション１７５を含むことができる。いくつかの例では、第１の支払いアプリケーション１７５は、第１のウォレット・アプリケーション１７１に支払い情報（例えば、支払い鍵１３０、サブ支払い鍵１２３、及び／又は他のデータ）を提供するために実行される支払いアプレットを表すことができ、この場合、第１のウォレット・アプリケーション１７１は、支払い情報をＰＯＳ端末１１２まで中継することができる。

【0031】

第１の支払いアプリケーション１７５は、アプリケーション・データ１８９を含むことができる。アプリケーション・データ１８９は、以下のようなデータ要素を含むことができる：支払い鍵１３０（例えば、アカウント固有秘密鍵）、アプリケーション取引カウンタ、アカウント暗号鍵（例えば、動的データ認証（ＤＤＡ）／複合ＤＤＡ（ＣＤＡ）処理用のアカウント固有Ｒｉｖｅｓｔ－Ｓｈａｍｉｒ－Ａｄｌｅｍａｎ（ＲＳＡ）秘密鍵）、証明書（例えば、Ｅｕｒｏｐａｙ、Ｍａｓｔｅｒｃａｒｄ、及びＶｉｓａ（ＥＭＶ）証明書）、ＤａｔａＯｂｊｅｃｔＬｉｓｔｓ、機能性を管理するためのアプレット変数、サブ支払い鍵１２３、サブ支払い鍵１２３のためのサブアプリケーション取引カウンタ（サブＡＴＣ）、及びその他の潜在的データ。

【0032】

サブＡＴＣは、サブ支払い鍵１２３を使用して完了された取引の数量のカウントを維持することができる。したがって、サブＡＴＣは、サブ支払い鍵１２３を使用して取引が完了されるたびにインクリメントされ得る。このように、サブ支払い鍵１２３は別個の取引カウンタを持っているので、口座名義人が支払い鍵１３０を用いて行う取引は、サブ支払い鍵１２３に許可される取引の数量に干渉することがない。サブＡＴＣは、サブ支払い鍵１２３に許可される取引の数量を強制するために使用され得る。取引要求を受信すると、イシュア・サービス１２１はサブＡＴＣとサブ支払い鍵１２３のＡＴＣ範囲とを確認することができる。サブＡＴＣがサブ支払い鍵１２３のＡＴＣ範囲を超えている場合、イシュア・サービス１２１は取引を拒否する。加えて、前述のように、サブＡＴＣ及びサブ支払い鍵１２３は、第１のウォレット・アプリケーション１７１が第１の支払いアプリケーション１７５にサブ支払いトークン１３４の要求を提供するときに生成される。

【0033】

次に、ネットワーク化環境１００の様々なコンポーネントの動作について一般的な説明が提供される。始めに、ユーザ・アカウント１２４の第１のユーザ（例えば、口座名義人）は、第１のクライアント・デバイス１０６を使用して、第２のユーザに支払いトークン１２７（例えば、クレジット・カード、チャージ・カード、デビット・カード、又はギフト・カード）を貸与することができる。第１のユーザは、第１のウォレット・アプリケーション１７１を使用して、第１のユーザの支払いトークン１２７に付随するサブ支払いトークン１３４を生成する要求を示すことができる。第１のウォレット・アプリケーション１７１から、第１のユーザは、第２のユーザに許可される取引の数量（例えば、鍵制限１７８）を選択又は指定することができる。第１のウォレット・アプリケーション１７１は、第１の支払いアプリケーション１７５を呼び出して、サブ支払い鍵１２３及びサブ支払いトークン１３４を生成することができる。第１の支払いアプリケーション１７５は、許可された取引の数量に基づいて、アプリケーション取引カウンタ（ＡＴＣ）範囲を生成することができる。次に、サブ支払い鍵１２３は、支払い鍵１３０、ＡＴＣ範囲、及びその他の潜在的データに基づいて生成され得る。その後、第１の支払いアプリケーション１７５は、サブ支払い鍵１２３を含むサブ支払いトークン１３４を返すことができる。

【0034】

その後、第１のウォレット・アプリケーション１７１は、第２のクライアント・デバイス１０９のネットワーク・アドレス（例えば、電子メール・アドレス）又はデバイス識別子（例えば、電話番号）を（例えば、第１のクライアント・デバイス１０６に記憶された連絡先リストから、又はユーザ・インターフェースによって提供された入力から）識別することができる。第１のウォレット・アプリケーション１７１は、ピアツーピア通信プロトコル又はネットワーク１１５によって、サブ支払いトークン１３４を第２のクライアント・デバイス１０９に送信することができる。したがって、第１のクライアント・デバイス１０６は、金融取引口座プロバイダと関連付けられるイシュア・サービス１２１の関与なしに、サブ支払いトークン１３４を生成し、サブ支払いトークン１３４を第２のクライアント・デバイス１０９に送信することができる。

【0035】

サブ支払いトークン１３４を受信した後、第２のクライアント・デバイス１０９は、暗号鍵を使用してサブ支払いトークン１３４を検証することができる。次に、第２のウォレット・アプリケーション１８１は、認証プロセスを開始するために、第２のセキュア要素１６８から、第２の支払いアプリケーション１８５を選択することができる。認証した後、第２の支払いアプリケーション１８５は、サブ支払いトークン１３４を処理し、第２のセキュア要素１６８に記憶することができる。

【0036】

第２のユーザは、第２のクライアント・デバイス１０９を使用し、ＰＯＳ端末１１２でサブ支払い鍵１２３を使用して非接触支払いを行うことができる。ＰＯＳ端末１１２は取引認可要求をイシュア・サービス１２１に送信することができる。イシュア・サービス１２１は、取引認可要求がサブ支払い鍵１２３を含んでいることを識別することができる。イシュア・サービス１２１はまた、支払い鍵１３０がサブ支払い鍵１２３にリンクされていることを識別することができる。イシュア・サービス１２１は、鍵制限１７８、サブ支払い鍵１２３のサブＡＴＣ、取引のための取引データ、及びその他のリスク規則に基づいて、取引認可要求を承認又は拒否することができる。

【0037】

次に図２Ａを参照すると、様々な実施形態による第１のウォレット・アプリケーション１７１の一部の動作の一例を提供するフローチャートが示されている。図２Ａのフローチャートは、本明細書に記載されるように第１のウォレット・アプリケーション１７１の部分の動作を実装するために採用され得る多くの異なるタイプの機能的な配置の単なる例を提供するものであることを理解されたい。代替として、図２Ａのフローチャートは、一つ又は複数の実施形態による、第１のクライアント・デバイス１０６又は第２のクライアント・デバイス１０９（図１Ａ）において実装される方法の要素の一例を描いたものとして見てもよい。

【0038】

四角２０５から始まって、第１のウォレット・アプリケーション１７１は、ユーザ・アカウント１２４に関連付けられた取引を行うことを他のユーザに認証するサブ支払いトークン１３４を生成する意図又は指示を受信することができる。例えば、第１のユーザは、ユーザ・アカウント１２４の口座名義人として、第２のユーザに自分の支払いトークン１２７を貸与することを望むことができる。いくつかの実施形態では、第１のウォレット・アプリケーション１７１は、第１のユーザ（例えば、口座名義人）が支払いトークン１２７の貸与を開始するためのユーザ・インターフェース・コンポーネントを選択することができる第１のユーザ・インターフェース１７３をレンダリングすることができる。

【0039】

四角２０８において、第１のウォレット・アプリケーション１７１は、支払いトークン１２７の貸与に許可される取引の数量の選択を受信することができる。第１のウォレット・アプリケーション１７１は、第１のユーザ・インターフェース１７３を更新し、様々な鍵制限１７８を受信するためのユーザ・インターフェース・コンポーネント又はデータ・フィールドを含むことができる。例えば、許可される取引の数量に加えて、第１のユーザ・インターフェース１７３は、取引値限度、サブ支払いトークン１３４が有効である期間、カテゴリ支出制限、取引の場所制限、及び／又は他の適切な鍵制限１７８など、他の鍵制限１７８を受信することができる。

【0040】

四角２１１では、第１のウォレット・アプリケーション１７１は、第１の支払いアプリケーション１７５を呼び出して、サブ支払いトークン１３４（例えば、サブ支払い鍵１２３）を生成することができる。第１のウォレット・アプリケーション１７１は、第１の支払いアプリケーション１７５に、鍵制限１７８（例えば、許可される取引の数量）を提供することができる。いくつかの実施形態では、第１の支払いアプリケーション１７５は、第１のセキュア要素１６５上で実行される。結果として、いくつかの実施形態において、第１のウォレット・アプリケーション１７１は、認証のためのクリデンシャルを提供することができる。

【0041】

四角２１４では、第１のウォレット・アプリケーション１７１は、サブ支払いトークン１２７を受信することができ、この貸与支払いトークン１２７はサブ支払い鍵１２３を含む。サブ支払い鍵１２３は、第１のクライアント・デバイス１０６に記憶された支払い鍵１３０から導出され得る。サブ支払い鍵１２３は、一つ又は複数の鍵制限１７８を含むこともできる。サブ支払い鍵１２３は、口座名義人によって選択された許可される取引の数量を示すアプリケーション取引カウンタ（ＡＴＣ）範囲をパラメータとして含むことができる。例えば、サブ支払い鍵１２３に関連付けられるサブＡＴＣが０ｘ０００５にあり、３つの新規取引が許可された場合、ＡＴＣ範囲は０ｘ０００６～０ｘ０００８となる。

【0042】

四角２１７では、第１のウォレット・アプリケーション１７１は、暗号化スキームを使用することによって、サブ支払いトークン１３４をセキュア化できる。いくつかの実施形態では、暗号化は、第１のウォレット・アプリケーション１７１によって省略され得る。代わりに、いくつかの実施形態では、第１の支払いアプリケーション１７５は、第１のウォレット・アプリケーション１７１に返す前に、サブ支払いトークン１３４を暗号化することができる。

【0043】

四角２２０では、第１のウォレット・アプリケーション１７１は、サブ支払いトークン１３４を第２のクライアント・デバイス１０９に送信することができる。第１のウォレット・アプリケーション１７１は、連絡先リスト内の連絡先受信者を選択するための第１のユーザ・インターフェース１７３を表示することができる。代替的に、第１のユーザ・インターフェース１７３は、受信者に関連付けられた第２のクライアント・デバイス１０９の連絡先情報（例えば、ネットワーク・アドレス又はモバイル・デバイス識別子）を受信するように構成され得る。連絡先情報が（例えば、連絡先リストから、又はユーザ・インターフェースから）識別された後、第１のウォレット・アプリケーション１７１は、サブ支払いトークン１３４を第２のクライアント・デバイス１０９に送信することができる。いくつかの実施形態では、第１のウォレット・アプリケーション１７１は、Ｂｌｕｅｔｏｏｔｈプロトコル、ＮＦＣプロトコル、無線ローカル・エリア・ネットワーク、又は他の適切な無線プロトコルなどのピアツーピア・メッセージング・プロトコルを使用することができる。

【0044】

他の実施形態において、第１のウォレット・アプリケーション１７１は、テキスト・メッセージ・プロトコル（例えば、ＳＭＳ、ＭＭＳなど）、電子メール・プロトコル、チャット・メッセージ・アプリケーション、又は他の適切な通信プロトコルなどの他の通信プロトコルを使用することができる。そして、第１のウォレット・アプリケーション１７１は完了へと進むことができる。

【0045】

図２Ｂに移ると、様々な実施形態による第１の支払いアプリケーション１７５の一部の動作の一例を提供するフローチャートが示されている。図２Ｂのフローチャートは、本明細書に記載されるように第１の支払いアプリケーション１７５の部分の動作を実装するために採用され得る多くの異なるタイプの機能的な配置の単なる例を提供するものであることを理解されたい。代替として、図２Ｂのフローチャートは、一つ又は複数の実施形態による、第１のセキュア要素１６５又は第２のセキュア要素１６８（図１Ａ）において実装される方法の要素の一例を描いたものとして見てもよい。加えて、図２Ｂのフローチャートの一部も、第１のウォレット・アプリケーション１７１又は第２のウォレット・アプリケーション１８１で実行され得る。

【0046】

四角２３０から始まって、第１の支払いアプリケーション１７５は、第１のウォレット・アプリケーション１７１から要求を受信して、サブ支払いトークン１３４（例えば、サブ支払い鍵１２３）を生成することができる。要求は、一つ又は複数の鍵制限１７８を含むことができる。例えば、鍵制限１７８は、サブ支払い鍵１２３に対して許可される取引の数量を含むことができる。いくつかの実装形態では、第１の支払いアプリケーション１７５は、第１のウォレット・アプリケーション１７１によって提供されるクリデンシャルを検証することによって、第１のウォレット・アプリケーション１７１を認証することができる。認証プロセスは、一部の実装形態では独自の認証プロセスであってよい。他の実装形態では、認証プロセスは、ＧｌｏｂａｌＰｌａｔｆｏｒｍ（登録商標）ＳｅｃｕｒｅＣｈａｎｎｅｌＰｒｏｔｏｃｏｌなどの標準、又は他の適切な認証プロトコルを含むことができる。

【0047】

四角２３３では、第１の支払いアプリケーション１７５は、サブ支払い鍵１２３のためのアプリケーション取引カウンタ（ＡＴＣ）範囲を生成することができる。ＡＴＣ範囲は、口座名義人によって選択された許可された取引の数量に少なくとも部分的に基づいて生成され得る。例えば、サブ支払い鍵１２３のサブＡＴＣが０ｘ０００５にあり、３つの新規取引が要求された場合、サブ支払い鍵１２３に関し、ＡＴＣ範囲は０ｘ０００６～０ｘ０００８となる。

【0048】

四角２３６では、第１の支払いアプリケーション１７５は、支払い鍵１３０及びＡＴＣ範囲に少なくとも部分的に基づいて、サブ支払い鍵１２３を生成することができる。いくつかの実装形態では、ＡＴＣ範囲は、サブ支払い鍵１２３に追加されるパラメータである。例えば、サブ支払い鍵１２３は、ＡＴＣ範囲開始値及びＡＴＣ範囲終了値をパラメータとして支払い鍵１３０に追加することによって生成され得る。ＡＴＣ範囲開始はＡＴＣ範囲の開始点を表し、ＡＴＣ範囲終了はＡＴＣ範囲の終了点を表すことができる。その他の鍵制限１７８は、パラメータとしてサブ支払い鍵１２３に追加され得る。例えば、取引値限度、期間限度、カテゴリ取引タイプ制限、及び他の潜在的な制限は、パラメータとしてサブ支払い鍵１２３に追加され得る。

【0049】

四角２３９では、第１の支払いアプリケーション１７５は、サブ支払い鍵１２３に使用されるＡＴＣ範囲を、コンピューティング環境１０３のデータ・ストア１１８に記憶されるイシュア・アプリケーション・データに追加することができる。ＡＴＣ範囲は、支払い鍵１３０が再計算されるときにイシュアによって使用され得る。例えば、ＡＴＣ範囲は、サブ支払い鍵１２３のＡＴＣ範囲に割り当てられたメモリ場所に新しい支払い鍵１３０が記憶されるのを防ぐために、支払い鍵１３０のメモリ場所を再計算するときに有用である。永久口座番号（ＰＡＮ）、有効期限、その他のペイロード・データ要素など、支払い鍵１３０及びその他の関連するペイロード・データ要素は、同一のままであり得ることに留意されたい。

【0050】

四角２４２では、第１の支払いアプリケーション１７５は、サブ支払い鍵１２３を含むサブ支払いトークン１３４を、第１のウォレット・アプリケーション１７１に返すことができる。いくつかの実施形態では、サブ支払いトークン１３４は、第１のセキュア要素１６５に記憶された暗号鍵を使用して、第１の支払いアプリケーション１７５によって暗号化される。そして、第１の支払いアプリケーション１７５は終了へと進むことができる。

【0051】

次に図３Ａを見てみると、様々な実施形態による第２のウォレット・アプリケーション１８１の一部の動作の一例を提供するフローチャートが示されている。図３Ａのフローチャートは、本明細書に記載されるように第２のウォレット・アプリケーション１８１の部分の動作を実装するために採用され得る多くの異なるタイプの機能的な配置の単なる例を提供するものであることを理解されたい。代替として、図３Ａのフローチャートは、一つ又は複数の実施形態による、第２のセキュア要素１６８（図１Ａ）において実装される方法の要素の一例を描いたものとして見てもよい。

【0052】

四角３０５から始まって、第２のウォレット・アプリケーション１８１は、第１のウォレット・アプリケーション１７１との通信セッションを確立することができる。通信セッションは、ピアツーピア無線プロトコル、又は他の適切な無線通信プロトコルであってよい。いくつかの実施形態において、第２のウォレット・アプリケーション１８１は、第２のユーザに第１のクライアント・デバイス１０６との通信セッションの確立を検証するように促すための第２のユーザ・インターフェース１８３を表示することができる。

【0053】

四角３０８では、第２のウォレット・アプリケーション１８１は、無線通信セッションによって第１のウォレット・アプリケーション１７１から貸出ペイロードを受信することができる。貸与ペイロードを受信した後、第２のウォレット・アプリケーション１８１は、第２のセキュア要素１６８に記憶されている様々な第２の支払いアプリケーション１８５の中から第２の支払いアプリケーション１８５を選択することができる。貸与ペイロードは、サブ支払いトークン１３４とサブ支払い鍵１２３を含む。

【0054】

四角３１４では、第２のウォレット・アプリケーション１８１は、認証のために第２の支払いアプリケーション１８５にクリデンシャルを提供することができる。認証プロセスは、一部の実装形態では独自の認証プロセスであってよい。他の実装形態では、認証プロセスは、ＧｌｏｂａｌＰｌａｔｆｏｒｍ（登録商標）ＳｅｃｕｒｅＣｈａｎｎｅｌＰｒｏｔｏｃｏｌなどの標準、又は他の適切な認証プロトコルを含むことができる。認証が達成された後、第２のウォレット・アプリケーション１８１と第２のセキュア要素１６８に記憶された第２の支払いアプリケーション１８５との間でセキュアなセッションを確立することができる。

【0055】

四角３１７では、第２のウォレット・アプリケーション１８１は、確立されたセキュアなセッションを通じて貸与ペイロードを第２の支払いアプリケーション１８５に送信することができる。第２の支払いアプリケーション１８５は、サブ支払い鍵１２３を含むサブ支払いトークン１３４を、貸与ペイロードから抽出することができる。

【0056】

四角３２０では、第２のウォレット・アプリケーション１８１は、取引を実行するために使用され得る。例えば、第２のユーザは店舗で、ＮＦＣを通して支払い情報を受け付けるＰＯＳ端末の前にいる可能性がある。第２のユーザは、第２のクライアント・デバイス１０９において、第２のクライアント・デバイス１０９に記憶されたサブ支払い鍵１２３に関連付けられるサブ支払いトークン１３４を使用することを選択することができる。支払いプロセスの一部として、第２のクライアント・デバイス１０９は、サブ支払い鍵１２３をＰＯＳ端末１１２に提供することができる。ＰＯＳ端末１１２は、承認のためにサブ支払い鍵１２３と他の取引データをイシュア・サービス１２１に転送することができる。イシュア・サービス１２１は取引を承認し、ＰＯＳ端末１１２に通知することができる。そして、第２のウォレット・アプリケーション１８１は終了へと進むことができる。

【0057】

次に図３Ｂを参照すると、様々な実施形態による第２の支払いアプリケーション１８５の一部の動作の一例を提供するフローチャートが示されている。図３Ｂのフローチャートは、本明細書に記載されるように第２の支払いアプリケーション１８５の部分の動作を実装するために採用され得る多くの異なるタイプの機能的な配置の単なる例を提供するものであることを理解されたい。代替として、図３Ｂのフローチャートは、一つ又は複数の実施形態による、第２のセキュア要素１６８（図１Ａ）において実装される方法の要素の一例を描いたものとして見てもよい。

【0058】

四角３３０から始まって、第２の支払いアプリケーション１８５は、第２のウォレット・アプリケーション１８１から貸与ペイロードを受信することができる。いくつかの実施形態では、第２の支払いアプリケーション１８５は、第２のウォレット・アプリケーション１８１とのセッションを認証することができる。認証プロセスは、独自のプロトコルであってもよいし、ＧｌｏｂａｌＰｌａｔｆｏｒｍ（登録商標）ＳｅｃｕｒｅＣｈａｎｎｅｌＰｒｏｔｏｃｏｌ又は第２のセキュア要素１６８で実行されるアプリケーションへのアクセスを認証するための他の適切なプロトコルなど、標準化されたプロセス又はプロトコルであってもよい。

【0059】

四角３３３では、第２の支払いアプリケーション１８５は、サブ支払いトークン１３４とサブ支払い鍵１２３を貸与ペイロードから抽出することができる。サブ支払い鍵１２３は、第２のセキュア要素１６８に記憶され得る。いくつかの実施形態では、第２の支払いアプリケーション１８５は、暗号鍵を使用して貸与ペイロードを検証することができる。検証することで、貸与ペイロードは復号され、サブ支払い鍵１２３へのアクセスを提供することができる。

【0060】

四角３３６では、第２の支払いアプリケーション１８５は、取引を実行する際、サブ支払い鍵１２３へのアクセスを提供することができる。例えば、第２のクライアント・デバイス１０９の第２のユーザは、サブ支払い鍵１２３に関連付けられたサブ支払いトークン１３４を使用することを選択することができる。第２のウォレット・アプリケーション１８１は、サブ支払い鍵１２３を要求することができ、第２の支払いアプリケーション１８５は、サブ支払い鍵１２３を第２のウォレット・アプリケーション１８１に提供することができ、第２のウォレット・アプリケーション１８１は、ＰＯＳ端末１１２との非接触購入を完了するためにサブ支払い鍵１２３を使用することができる。そして、第２の支払いアプリケーション１８５は終了へと進むことができる。

【0061】

次に図４を見てみると、様々な実施形態によるイシュア・サービス１２１の一部の動作の一例を提供するフローチャートが示されている。図４のフローチャートは、本明細書に記載されるようにイシュア・サービス１２１の部分の動作を実装するために採用され得る多くの異なるタイプの機能的な配置の単なる例を提供するものであることを理解されたい。代替として、図４のフローチャートは、一つ又は複数の実施形態による、コンピューティング環境１０３（図１Ａ）において実装される方法の要素の一例を描いたものとして見てもよい。

【0062】

四角４０５から始まって、イシュア・サービス１２１はマーチャントのＰＯＳ端末１１２から取引データを受信することができる。非限定的な一例では、取引データは、第２のクライアント・デバイス１０９との非接触支払いを実行したＰＯＳ端末１１２によって生成され得る。取引データは、サブ支払いトークン１３４、サブ支払い鍵１２３、取引金額、及び他の取引データを含むことができる。

【0063】

四角４０８では、イシュア・サービス１２１は、サブ支払い鍵１２３及び他の鍵制限１７８に基づいて、取引データがサブ取引１３６に関連付けられることを識別することができる。いくつかの例では、イシュア・サービス１２１は、金融報告において、取引１３３をユーザ・アカウント１２４の口座名義人のサブ取引１３６と区別することができる。この金融報告は、口座名義人が、相手に提供されたサブ支払いトークン１３４で完了したサブ取引１３６を見るために使用され得る。サブ取引１３６は、ユーザ・アカウント１２４の口座名義人が支払うべき責任を負う。取引データは、取引中に第２のクライアント・デバイス１０９がデータ要素を署名することで生成されたアプリケーション暗号文を含むことができる。

【0064】

四角４１１では、イシュア・サービス１２１はサブ支払い鍵１２３を使用してアプリケーション暗号文を検証できる。アプリケーション暗号文は、暗号演算によりサブ支払い鍵１２３を導出することで検証され得る。

【0065】

四角４１４では、イシュア・サービス１２１は、リスク規則に基づいて、サブ取引１３６を承認するか拒否するかを決定することができる。いくつかの実施形態では、リスク規則は、鍵制限１７８をチェックすることを含む。例えば、イシュア・サービス１２１は、サブＡＴＣ及びＡＴＣ範囲に少なくとも部分的に基づいて、サブ支払い鍵１２３が許可されたサブ取引１３６の数量を超えたかどうかを確認することができる。例えば、サブＡＴＣがＡＴＣ範囲を超えている場合、イシュア・サービス１２１はサブ取引１３６を否認することができる。

【0066】

他の例では、イシュア・サービス１２１は取引データを鍵制限１７８と比較することができる。例えば、取引データは、サブ取引１３６が小売購入のためのものであることを示すことができ、鍵制限１７８は、サブ支払い鍵１２３が教育関連の購入に制限されていることを示す。結果として、この例では、イシュア・サービス１２１はＰＯＳ端末１１２に取引を拒否するように命令することができる。また、リスク規則は、潜在的な不正を評価する規則を含むこともできる。そして、イシュア・サービス１２１は終了へと進むことができる。

【0067】

次に、図５に移ると、ネットワーク化環境１００に示される動作のシーケンス図５００が示されている。シーケンス図５００は、図２Ａ及び図２Ｂからの代替の実施形態を表すことができる。シーケンス図５００は、様々な実施形態により、口座名義人がサブ支払いトークン１３４及びサブ支払い鍵１２３を生成し、それらを第２のユーザに提供することに関する。代替的な実施形態において、シーケンス図５００は、ネットワーク化環境１００において実装される動作方法を表すことができる。

【0068】

始めに、ブロック５０３において、第１のウォレット・アプリケーション１７１は、第１のユーザ（例えば、ユーザ・アカウント１２４の口座名義人）に、ユーザ・アカウント１２４の支払いトークン１２７（例えば、クレジット・カード、チャージ・カード、デビット・カード、又はギフト・カード）に付随するサブ支払いトークン１３４を発行するためのユーザ・インターフェース・コンポーネントを選択することを可能にする、第１のユーザ・インターフェース１７３を表示することができる。第１のユーザ・インターフェース１７３では、第１のユーザは、第２のユーザ用にサブ支払いトークン１３４の許可される取引の数量を選択することができる。第１のユーザ・インターフェース１７３は、他の鍵制限１７８を受信するためにも使用され得る。

【0069】

ブロック５０８では、第１のウォレット・アプリケーション１７１は、第１の支払いアプリケーション１７５を選択して、サブ支払いトークン１３４のためのサブ支払い鍵１２３を生成することができる。第１の支払いアプリケーション１７５が選択された後、第１のウォレット・アプリケーション１７１は、第１の支払いアプリケーション１７５とのセッションを認証するためのクリデンシャルを提供することができる。いくつかの実施形態では、第１のウォレット・アプリケーション１７１と第１の支払いアプリケーション１７５との間の認証は、ＧｌｏｂａｌＰｌａｔｆｏｒｍ（登録商標）ＳｅｃｕｒｅＣｈａｎｎｅｌＰｒｏｔｏｃｏｌ標準又は他の適切なプロトコルに従って実装することができる。

【0070】

ブロック５１１では、第１の支払いアプリケーション１７５は、第１のウォレット・アプリケーション１７１のクリデンシャルを検証することができる。第１の支払いアプリケーション１７５は、クリデンシャルの認証に関して成功／失敗メッセージを送信することができる。場合によっては、ブロック５０８とブロック５１１の機能性は省略できる。

【0071】

ブロック５１４において、認証成功メッセージを受信した後、第１のウォレット・アプリケーション１７１は、第１の支払いアプリケーション１７５とのセッションを確立することができる。第１の支払いアプリケーション１７５は、成功／失敗メッセージを第１のウォレット・アプリケーション１７１に送信することができる。次に、第１のウォレット・アプリケーション１７１は、サブ支払い鍵１２３の要求を第１の支払いアプリケーション１７５に送信することができる。要求は、許可される取引の数量、及びその他の鍵制限１７８を含み得る。要求を受信した後、第１の支払いアプリケーション１７５は要求を検証し、それがサブ支払い鍵１２３を生成するのに十分なアクセス権を有しているかどうかを判定することができる。例えば、第１の支払いアプリケーション１７５は、必要とされるデータ要素（例えば、支払い鍵１３０）に対するアクセス権をそれが有しているかどうかを判定することができる。

【0072】

次に、第１の支払いアプリケーション１７５は、支払い鍵１３０に少なくとも部分的に基づいて、サブ支払い鍵１２３を生成することができる。いくつかの実装形態では、サブ支払い鍵１２３も、生成されたＡＴＣ範囲とサブＡＴＣの初期値に少なくとも部分的に基づいて生成される。第１の支払いアプリケーション１７５は、ＡｐｐｌｉｃａｔｉｏｎＩｎｔｅｒｃｈａｎｇｅＰｒｏｆｉｌｅ（ＡＩＰ）、ＡｐｐｌｉｃａｔｉｏｎＦｉｌｅＬｏｃａｔｏｒ（ＡＦＬ）、ＰｒｏｃｅｓｓｉｎｇＯｐｔｉｏｎｓＤａｔａＯｂｊｅｃｔＬｉｓｔ（ＰＤＯＬ）、ＣａｒｄＲｉｓｋＭａｎａｇｅｍｅｎｔＤａｔａＯｂｊｅｃｔＬｉｓｔ１、及び潜在的な他のＥＭＶ関連データのような、他の取引固有の詳細も蓄積することができる。更に、第１の支払いアプリケーション１７５は、認証中にイシュア・サービス１２１がＡＴＣ範囲に基づいて支払い鍵１３０を再計算できるように、ＡＴＣ範囲をイシュア・アプリケーション・データに追加することができる。

【0073】

ブロック５１７では、第１の支払いアプリケーション１７５は、サブ支払い鍵１２３を第１のウォレット・アプリケーション１７１に送信することができる。いくつかの実施形態では、サブ支払い鍵１２３を送信する前に、第１の支払いアプリケーション１７５は、サブ支払い鍵１２３に関連付けられるテンプレートをパーソナライズすることができ、サブ支払い鍵１２３を暗号化することができる。

【0074】

ブロック５２０では、第１のウォレット・アプリケーション１７１は、第２のウォレット・アプリケーション１８１とのセッションを確立する要求を送信することができる。第１のウォレット・アプリケーション１７１は、ネットワーク１１５によって、又はデータ通信の他の手段によって、第２のウォレット・アプリケーション１８１とピアツーピア通信プロトコル（例えば、Ｂｌｕｅｔｏｏｔｈ、ＮＦＣなど）を通信することができる。

【0075】

いくつかの実施形態では、第１のウォレット・アプリケーション１７１は、連絡先リストから選択された連絡先、ユーザ指定のデバイス情報（例えば、電話番号、電子メール・アドレス）、及びクライアント・デバイスの他の適切な識別情報に少なくとも部分的に基づいて、要求を送信することができる。他の実施形態では、第１のウォレット・アプリケーション１７１は、ピアツーピア通信プロトコル又はネットワーク１１５を使用して、第２のクライアント・デバイス１０９を識別することができる。

【0076】

ブロック５２４では、第２のウォレット・アプリケーション１８１は、第１のウォレット・アプリケーション１７１と第２のウォレット・アプリケーション１８１との間のセッションを確立するための成功／失敗メッセージを第１のウォレット・アプリケーション１７１に送信することができる。いくつかの実施形態では、第２のウォレット・アプリケーション１８１は、第１のウォレット・アプリケーション１７１の身元を検証するためのクリデンシャルを第１のウォレット・アプリケーション１７１から受信することができる。

【0077】

ブロック５２８では、第１のウォレット・アプリケーション１７１は、サブ支払いトークン１３４を第２のウォレット・アプリケーション１８１に送信することができる。サブ支払いトークン１３４は、サブ支払い鍵１２３を含むことができる。

【0078】

ブロック５３２では、第２のウォレット・アプリケーション１８１は、第２の支払いアプリケーション１８５を選択して、サブ支払いトークン１３４を送信することができる。第２の支払いアプリケーション１８５を選択した後、第２のウォレット・アプリケーション１８１は認証のためにクリデンシャルを送信することができる。認証プロセスは、一部の実装形態では独自の認証プロセスであってよい。他の実装形態では、認証プロセスは、ＧｌｏｂａｌＰｌａｔｆｏｒｍ（登録商標）ＳｅｃｕｒｅＣｈａｎｎｅｌＰｒｏｔｏｃｏｌなどの標準、又は他の適切な認証プロトコルを含むことができる。

【0079】

ブロック５３５では、第２の支払いアプリケーション１８５は、成功／失敗メッセージを第２のウォレット・アプリケーション１８１に送信することができる。いくつかの実施形態では、第２の支払いアプリケーション１８５は、サブ支払いトークン１３４の受信に関連付けられた第２のウォレット・アプリケーション１８１からの要求を受信することができる。第２のウォレット・アプリケーション１８１は、サブ支払いトークン１３４をアンパック及び／又は記憶するための適切なアクセス制御をそれが有することを保証するために、要求を検証することができる。

【0080】

ブロック５３７では、第２のウォレット・アプリケーション１８１は、サブ支払いトークン１３４を第２の支払いアプリケーション１８５に送信することができる。いくつかの実施形態では、第２の支払いアプリケーション１８５は、サブ支払いトークン１３４をアンラップして、サブ支払い鍵１２３を第２のセキュア要素１６８に記憶することができる。

【0081】

ブロック５４０では、第２のユーザは、物理的な店舗にいて、非接触支払い機能を有するＰＯＳ端末１１２の前にいることができる。第２の支払いアプリケーション１８５は、サブ支払いトークン１３４をＰＯＳ端末１１２に提供することによって、非接触支払いを促進することができる。

【0082】

ブロック５４３では、ＰＯＳ端末１１２は取引が完了したかどうかを示す成功／失敗メッセージを提供し得る。いくつかの実施形態では、ＰＯＳ端末１１２はイシュア・サービス１２１からの取引承認を要求することができる。イシュア・サービス１２１は、サブ支払い鍵１２３を識別して、鍵制限１７８を強制することができる。例えば、イシュア・サービス１２１は、サブＡＴＣがＡＴＣ動作範囲を超えていたかどうかを判定することができる。したがって、イシュア・サービス１２１は、サブ支払い鍵１２３に対して許可された取引が残っているかどうかを判定することができる。

【0083】

別の例として、イシュア・サービス１２１は取引データを他の鍵制限１７８と比較することができる。例えば、取引値が１５０ドルという値を超えないように鍵制限１７８は設定され得る。取引データが、取引は７５ドルであると示す場合、この鍵制限１７８は満たされる。鍵制限１７８及びその他のリスク要因のすべてを確認した後、イシュア・サービス１２１は取引承認メッセージをＰＯＳ端末１１２に送信することができる。そして、シーケンス図５００は終了へと進むことができる。

【0084】

上で議論した、いくつかのソフトウェア・コンポーネントは、それぞれのコンピューティング・デバイスのメモリに記憶され、それぞれのコンピューティング・デバイスのプロセッサによって実行可能である。この点において、用語「実行可能な」とは、最終的にプロセッサによって実行され得る形態にあるプログラム・ファイルを意味する。実行可能なプログラムの例としては、メモリのランダム・アクセス部分にロードされプロセッサによって実行され得るフォーマットで機械コードに変換可能なコンパイルされたプログラム、メモリのランダム・アクセス部分にロードされプロセッサによって実行され得るオブジェクト・コードなど適切なフォーマットとして表現され得るソース・コード、又は別の実行可能プログラムによって解釈され、プロセッサによって実行されるようにメモリのランダム・アクセス部分において命令を生成することができるソース・コードを挙げることができる。実行可能なプログラムは、メモリのあらゆる部分又はコンポーネントに記憶され得、例えばランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハード・ドライブ、ソリッドステート・ドライブ、ユニバーサル・シリアル・バス（ＵＳＢ）フラッシュ・ドライブ、メモリ・カード、コンパクト・ディスク（ＣＤ）若しくはデジタル・バーサタイル・ディスク（ＤＶＤ）などの光学ディスク、フロッピ・ディスク、磁気テープ、又は他のメモリ・コンポーネントに記憶され得る。

【0085】

メモリは、揮発性及び非揮発性両方の、メモリ及びデータ・ストレージ・コンポーネントを含む。揮発性のコンポーネントは、電力が失われるとデータ値を保持しないコンポーネントである。非揮発性のコンポーネントは、電力が失われてもデータの値を保持するコンポーネントである。故に、メモリは、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、ハード・ディスク・ドライブ、ソリッドステート・ドライブ、ＵＳＢフラッシュ・ドライブ、メモリ・カード・リーダを介してアクセスされるメモリ・カード、関連付けられたフロッピ・ディスク・ドライブを介してアクセスされるフロッピ・ディスク、光学ディスク・ドライブを介してアクセスされる光学ディスク、適切なテープ・ドライブを介してアクセスされる磁気テープ、又は他のメモリ・コンポーネント、又はこれらのメモリ・コンポーネントのうち任意の二つ以上の組合せを含むことができる。加えて、ＲＡＭは、静的ランダム・アクセス・メモリ（ＳＲＡＭ）、動的ランダム・アクセス・メモリ（ＤＲＡＭ）、又は磁気的なランダム・アクセス・メモリ（ＭＲＡＭ）及び他のそのようなデバイスを含むことが可能である。ＲＯＭは、プログラム可能読み取り専用メモリ（ＰＲＯＭ）、消去可能プログラム可能読み取り専用メモリ（ＥＰＲＯＭ）、電気的消去可能プログラム可能読み取り専用メモリ（ＥＥＰＲＯＭ）、又は他の同様なメモリ・デバイスを含むことができる。

【0086】

本明細書で説明されるアプリケーション及びシステムは、上で議論したような汎用のハードウェアによって実行されるソフトウェア又はコードとして具体化されることが可能であるが、代替として、本明細書で説明されるアプリケーション及びシステムはまた、専用ハードウェア、又はソフトウェア／汎用ハードウェアと専用ハードウェアとの組合せとして具体化されることもできる。専用ハードウェアとして具体化される場合、それぞれは、いくつかの技術のうちの一つ又はそれらの組合せのいずれかを採用する回路又は状態機械として実装されることが可能である。このような技術は、限定はしないが、一つ若しくは複数のデータ信号を印加すると様々な論理機能を実装する論理ゲートを有するディスクリート論理回路、適切な論理ゲートを有する特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル・ゲート・アレイ（ＦＰＧＡ）、又は他のコンポーネントなどを含むことができる。そのような技術は、一般的には当業者に周知であるため、結果的に本明細書では詳細に説明されていない。

【0087】

図２Ａ、図２Ｂ、図３Ａ、図３Ｂ、図４、及び図５のフローチャート及びシーケンス図は、本開示の様々な実施形態の部分の実装の、機能性及び動作を表している。ソフトウェアとして具体化される場合、それぞれのブロックは、指定の論理機能を実装するためのプログラム命令を含むコードの、モジュール、セグメント、又は部分を表現することが可能である。プログラム命令は、コンピュータ・システム内のプロセッサなどの適切な実行システムによって認識可能な数値命令を含むプログラミング言語又は機械コードで記述された人間可読ステートメントを含むソース・コードの形態として具体化されることが可能である。機械コードは、様々なプロセスを通じてソース・コードから変換されることが可能である。例えば、機械コードは、対応するアプリケーションの実行に先立って、コンパイラを用いてソース・コードから生成されることが可能である。別の例として、機械コードは、インタプリタによる実行と同時的にソース・コードから生成されることが可能である。他の手法もまた使用され得る。ハードウェアとして具体化される場合、それぞれのブロックは、指定される一つ又は複数の論理機能を実装するために、一つの回路又はいくつかの相互接続された回路を表現することが可能である。

【0088】

図２Ａ、図２Ｂ、図３Ａ、図３Ｂ、図４、及び図５のフローチャート及びシーケンス図は、具体的な実行の順序を辿っているが、実行の順は、描かれているものとは異なっていてもよいことを理解されたい。例えば、二つ以上のブロックの実行の順序は、示されている順序に対してスクランブルされてもよい。また、連続して示される二つ以上のブロックは、同時的に、又は部分的に同時に実行され得る。更には、いくつかの実施形態では、図２Ａ、図２Ｂ、及び図５のフローチャート及びシーケンス図に示されるブロックのうちの一つ又は複数は、スキップ又は省略され得る。加えて、実用性の向上、課金、性能測定、又はトラブルシューティング支援の提供などの目的で、あらゆる数のカウンタ、状態変数、警告セマフォ、又はメッセージが、本明細書で説明される論理フローに追加される場合がある。すべてのそのような変形例は、本開示の範囲内であることを理解されたい。

【0089】

また、ソフトウェア又はコードを含む、本明細書で説明されるあらゆるロジック又はアプリケーションは、コンピュータ・システム又は他のシステム内のプロセッサなどの命令実行システムによる、又はそれと組み合わせた使用に向けて、任意の非一時的なコンピュータ可読媒体として具体化され得る。この意味で、ロジックは、コンピュータ可読媒体からフェッチされ、命令実行システムによって実行されることが可能な、命令及び宣言を含んでいるステートメントを含むことが可能である。本開示のコンテキストでは、「コンピュータ可読媒体」は、命令実行システムによる、又はそれと組み合わせた使用に向けて、本明細書で説明されるロジック又はアプリケーションを、含むこと、記憶すること、又は維持することが可能な、あらゆる媒体であることができる。その上、複数のコンピューティング・デバイスにまたがって配置される分散型のコンピュータ可読媒体の集合（例えば、ストレージ・エリア・ネットワーク、又は分散型若しくはクラスタ化されたファイルシステム若しくはデータベース）はまた、集合的に、単一の非一時的なコンピュータ可読媒体とも考えることができる。

【0090】

コンピュータ可読媒体は、磁気、光学、又は半導体の媒体など、多くの物理的媒体のいずれかを含むことが可能である。適切なコンピュータ可読媒体のより具体的な例としては、限定はしないが、磁気テープ、磁気フロッピ・ディスケット、磁気ハード・ドライブ、メモリ・カード、ソリッドステート・ドライブ、ＵＳＢフラッシュ・ドライブ、又は光学ディスクが挙げられよう。また、コンピュータ可読媒体は、静的ランダム・アクセス・メモリ（ＳＲＡＭ）及び動的ランダム・アクセス・メモリ（ＤＲＡＭ）又は磁気的なランダム・アクセス・メモリ（ＭＲＡＭ）を含む、ランダム・アクセス・メモリ（ＲＡＭ）であることができる。加えて、コンピュータ可読媒体は、読み取り専用メモリ（ＲＯＭ）、プログラム可能読み取り専用メモリ（ＰＲＯＭ）、消去可能プログラム可能読み取り専用メモリ（ＥＰＲＯＭ）、電気的消去可能プログラム可能読み取り専用メモリ（ＥＥＰＲＯＭ）、又は他のタイプのメモリ・デバイスであることが可能である。

【0091】

更には、本明細書で説明される、あらゆるロジック又はアプリケーションは、多様な方法で実装され、構造化されることが可能である。例えば、説明される一つ又は複数のアプリケーションは、単一のアプリケーションの、モジュール又はコンポーネントとして実装され得る。更には、本明細書で説明される一つ又は複数のアプリケーションは、共有されたコンピューティング・デバイス若しくは別個のコンピューティング・デバイス、又はそれらの組合せにおいて、実行され得る。例えば、本明細書で説明される複数のアプリケーションは、同一のコンピューティング・デバイスにおいて、又は同一のコンピューティング環境１０３内の複数のコンピューティング・デバイスにおいて、実行され得る。

【0092】

「Ｘ、Ｙ、又はＺのうちの少なくとも一つ」という言い回しなどの、選言的な語句は、そうではないと明言されない限り、項目、用語などがＸ、Ｙ、及び／若しくはＺのいずれかであり得る、又はそのいずれかの組合せ（例えば、Ｘ；Ｙ；Ｚ；Ｘ及び／又はＹ；Ｘ及び／又はＺ；Ｙ及び／又はＺ；Ｘ、Ｙ、及び／又はＺ、など）であり得ることを提示するために一般的に使用されるようなコンテキストで、理解される。故に、そのような選言的な語句は、一般的に、特定の実施形態が、Ｘのうちの少なくとも一つ、Ｙのうちの少なくとも一つ、及び／又はＺのうちの少なくとも一つのそれぞれが存在するよう要求していることを含意するよう意図されておらず、またそのように含意してはならない。

【0093】

本開示の上述の実施形態は、本開示の原理を明瞭に理解するために説明された実装形態の可能な例に過ぎないことが強調されるべきである。本開示の思想及び原理から実質的に逸脱することなく上述の実施形態に対して多くの変形及び変更が成され得る。すべてのそのような変形及び変更は、本明細書において本開示の範囲内に含められ、以下の特許請求の範囲によって保護されることが意図されている。

【0094】

本開示の様々な実施形態は、以下の条項に記載される。以下の条項では、本開示のいくつかの実施形態について説明するが、本開示の他の実施形態は上記にも記載されている。

【0095】

条項１
プロセッサ、メモリ、及びセキュア要素を含むコンピューティング・デバイスであって、セキュア要素がアプリケーションを含む、コンピューティング・デバイスと；メモリに記憶された機械可読命令であって、プロセッサによって実行されると、コンピューティング・デバイスに、少なくとも：コンピューティング・デバイスに記憶された支払いトークンに付随するサブ支払いトークンを生成するための指示を受信することと；サブ支払いトークンに対する鍵制限の選択を受信することと；鍵制限に基づいてサブ支払いトークンを生成するためにセキュア要素内のアプリケーションを実行することと；アプリケーションからサブ支払いトークンを受信することであって、サブ支払いトークンがサブ支払い鍵及びアプリケーション取引カウンタ範囲を含む、サブ支払いトークンを受信することと；クライアント・デバイスとの無線通信セッションを確立することと；無線通信セッションを通じてサブ支払いトークンをクライアント・デバイスのウォレット・アプリケーションに送信することとを行わせる、機械可読命令とを備える、システム。

【0096】

条項２
鍵制限が、カテゴリ制限パラメータ、単一の取引限度制限パラメータ、又は日付制限パラメータのうちの少なくとも一つを含む、条項１に記載のシステム。

【0097】

条項３
アプリケーション取引カウンタ範囲が、サブ支払いトークンに対して許可された取引の数量に少なくとも部分的に基づいている、条項１又は２に記載のシステム。

【0098】

条項４
ウォレット・アプリケーションが、第２のウォレット・アプリケーションであり、機械可読命令が、プロセッサによって実行されると、コンピューティング・デバイスに、少なくとも：コンピューティング・デバイス上に第１のウォレット・アプリケーションのユーザ・インターフェースを表示させ、ユーザ・インターフェースが、鍵制限の選択を受信するように構成される、条項１乃至３のいずれか一項に記載のシステム。

【0099】

条項５
サブ支払いトークンをクライアント・デバイスのウォレット・アプリケーションに送信することが、コンピューティング・デバイスに、少なくとも：セキュア要素に記憶された暗号鍵を使用してサブ支払いトークンをセキュア化することを更に行わせる、条項１乃至４のいずれか一項に記載のシステム。

【0100】

条項６
サブ支払いトークンをクライアント・デバイスのウォレット・アプリケーションに送信することが、ピアツーピア・メッセージング・プロトコルを使用することを含む、条項１乃至５のいずれか一項に記載のシステム。

【0101】

条項７
セキュア要素が、コンピューティング・デバイスで実行されるプロセッサ・コンポーネント又は制限されたアプリケーション・コンポーネントである、条項１乃至６のいずれか一項に記載のシステム。

【0102】

条項８
第１のクライアント・デバイスによって、第２のクライアント・デバイスとの無線通信セッションを確立することと；第１のクライアント・デバイスによって、無線通信セッションを通じて第２のクライアント・デバイスからサブ支払いトークンを受信することであって、サブ支払いトークンがサブ支払い鍵及びアプリケーション取引カウンタ範囲を含み、サブ支払い鍵が第２のクライアント・デバイスに記憶された支払い鍵とリンクされている、サブ支払いトークンを受信することと；第１のクライアント・デバイスによって、サブ支払いトークンを第１のクライアント・デバイスのセキュア要素で実行される支払いアプリケーションに提供することと；第１のクライアント・デバイスによって、サブ支払いトークンを使用することによってポイント・オブ・セール（ＰＯＳ）端末で支払いを実行することとを含む、方法。

【0103】

条項９
支払いが、近接場通信支払い又はクイック・レスポンス・コード支払いのうちの少なくとも一つである、条項８に記載の方法。

【0104】

条項１０
無線通信セッションがピアツーピア無線通信セッションである、条項８又は９に記載の方法。

【0105】

条項１１
サブ支払いトークンが暗号化ペイロードとして受信され、第１のクライアント・デバイスによって、暗号化ペイロードを検証することと；サブ支払いトークンにアクセスするために、第１のクライアント・デバイスによって、暗号化ペイロードを復号することとを更に含む、条項８乃至１０のいずれか一項に記載の方法。

【0106】

条項１２
支払いを実行することが、第１のクライアント・デバイスによって、ＰＯＳ端末に、アプリケーション取引カウンタ範囲及びサブ支払い鍵を提供することを更に含む、条項８乃至１１のいずれか一項に記載の方法。

【0107】

条項１３
セキュア要素が、第１のクライアント・デバイスで実行されるプロセッサ・コンポーネント又は制限されたアプリケーション・コンポーネントである、条項８乃至１２のいずれか一項に記載の方法。

【0108】

条項１４
セキュア要素で実行される支払いアプリケーションにサブ支払いトークンを提供することが、第１のクライアント・デバイスによって、認証クリデンシャルをセキュア要素に提供することによってセキュア要素セッションを確立することを更に含む、条項８乃至１３のいずれか一項に記載の方法。

【0109】

条項１５
コンピューティング・デバイスと；プロセッサ及びメモリを含むセキュア要素と；メモリに記憶された機械可読命令であって、プロセッサによって実行されると、セキュア要素に、少なくとも：サブ支払い鍵を生成するためにコンピューティング・デバイスで実行されるウォレット・アプリケーションからの要求を受信することであって、要求が鍵制限を含む、要求を受信することと；セキュア要素に記憶された支払い鍵及び鍵制限に少なくとも部分的に基づいて、サブ支払い鍵を生成することと；サブ支払い鍵をウォレット・アプリケーションに返すこととを行わせる、機械可読命令とを備える、システム。

【0110】

条項１６
セキュア要素が、支払い鍵についてのアプリケーション取引カウンタと、サブ支払い鍵についてのサブアプリケーション取引カウンタとを含む、条項１５に記載のシステム。

【0111】

条項１７
サブ支払い鍵が、カテゴリ制限パラメータ、単一の取引限度制限パラメータ、又は日付制限パラメータのうちの少なくとも一つを含む鍵制限を含む、条項１５又は１６に記載のシステム。

【0112】

条項１８
鍵制限が、口座名義人によって許可される取引の数量である、条項１５乃至１７のいずれか一項に記載のシステム。

【0113】

条項１９
サブ支払い鍵を生成することが、セキュア要素に、少なくとも：口座名義人によって許可された取引の数量に少なくとも部分的に基づいて、アプリケーション取引カウンタ（ＡＴＣ）範囲を生成することを更に行わせる、条項１８に記載のシステム。

【0114】

条項２０
サブ支払い鍵が、ＡＴＣ範囲の開始値とＡＴＣ範囲の終了値とを含む、条項１９に記載のシステム。

【0115】

【図1A】