特許 7301869 アプライアンスへのトークンの承認およびプロビジョニングのためのシステムおよび方法

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-06-23

(45)【発行日】2023-07-03

(54)【発明の名称】アプライアンスへのトークンの承認およびプロビジョニングのためのシステムおよび方法

(51)【国際特許分類】

   G06Q 20/38 20120101AFI20230626BHJP

   G06Q 20/02 20120101ALI20230626BHJP

【ＦＩ】

G06Q20/38 310

G06Q20/02 300

【請求項の数】 20

(21)【出願番号】P 2020551859

(86)(22)【出願日】2018-03-27

(65)【公表番号】

(43)【公表日】2021-08-26

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

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

(87)【国際公開日】2019-10-03

【審査請求日】2021-03-09

(73)【特許権者】

【識別番号】505468864

【氏名又は名称】ビザ インターナショナル サービス アソシエーション

(74)【代理人】

【識別番号】100124327

【弁理士】

【氏名又は名称】吉村 勝博

(72)【発明者】

【氏名】ヴィアス，スレンドラ

(72)【発明者】

【氏名】シュクラ，ヴァイビハーバ

(72)【発明者】

【氏名】ラオ，シンドュ，シャンカル

(72)【発明者】

【氏名】トリパティ，サティヤ，プラカシュ

【審査官】松野 広一

(56)【参考文献】

【文献】国際公開第２０１７／２０９７６７（ＷＯ，Ａ１）

【文献】特開２０１４－０３２５１７（ＪＰ，Ａ）

【文献】特表２０１８－５０３２０２（ＪＰ，Ａ）

【文献】特表２０１７－５３７４２１（ＪＰ，Ａ）

【文献】米国特許出願公開第２０１６／０２７５４８８（ＵＳ，Ａ１）

【文献】特開２００２－１９７２９７（ＪＰ，Ａ）

【文献】特開２０１７－０６８６５１（ＪＰ，Ａ）

【文献】森下 太一郎 外２名，シャープのＨＭＳクラウドプラットフォーム，シャープ技報［ｏｎｌｉｎｅ］，SHARP，2016年09月06日，第１０９号，ｐｐ.９－１２

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００－９９／００

(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】

別の非限定的な実施形態または態様によれば、いずれのユーザに関連付けられていないデバイスアカウント識別子およびデバイスアカウント識別子と一意に関連付けられたデバイストークンを含むアプライアンスに内蔵されたメモリと、通信デバイスと、メモリおよび通信デバイスと通信するプロセッサと、を備え、プロセッサが、デバイスアカウント識別子およびデバイストークンのうちの少なくとも一つを含む取引要求を生成するようにプログラムまたは構成されるメモリおよび通信デバイスと通信するプロセッサとを含む、ユーザ固有のアカウントなしで取引を行うためのアプライアンスが本明細書に提供される。

【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】

本発明の更なる利点および詳細は、添付の図面に示される例示的実施形態および態様を参照して、以下でより詳細に説明されている。

【図1】図１は、アプライアンスへのトークンの承認およびプロビジョニングのための方法およびシステムの一実施形態または態様の概略図である。

【図2】図２は、アプライアンスへのトークンの承認およびプロビジョニングのための方法の一実施形態または態様のプロセス図である。

【図3】図３は、アプライアンスへトークンを承認およびプロビジョニングして取引を処理する方法およびシステムの一実施形態または態様の概略図である。

【図4】図４は、アプライアンスへトークンを承認およびプロビジョニングして取引を処理する方法の一実施形態または態様のプロセス図である。

【図5】図５は、アプライアンスへトークンを承認およびプロビジョニングして取引を処理するための方法の一実施形態または態様のプロセス図である。

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

【0049】

以降、説明の目的で、「上部」、「下部」、「右」、「左」、「垂直」、「水平」、「最上部」、「底部」、「横」、「縦」という用語、およびそれらの派生語は、図面において方向づけるように、本発明に関連する。しかしながら、本発明では、明示的に反対の指定がない限り、様々な代替の変形およびステップの連続を仮定することができることは理解されるものとする。また、添付図面に示され、以下の明細書で説明される特定のデバイスおよび方法は、単に本発明の例示的実施形態であることも理解されるものとする。したがって、本明細書に開示される実施形態に関連する、特定の寸法および他の物理的特性は、限定とみなされるべきではない。また、本明細書に記載される任意の数値範囲は、その中にあるすべての部分範囲を含むことを意図することも理解されるべきである。例えば、「１から１０」の範囲は、記載される１という最小値と記載される１０という最大値との間（かつ両値を含む）、すなわち、１以上の最小値および１０以下の最大値を有する、すべての部分範囲を含むことを意図している。

【0050】

本明細書で使用される場合、「アプライアンス」という用語は、プロセッサ、メモリ、および一つ以上のネットワークと通信するように構成された通信デバイスを含むコンシューマデバイスを指す。例えば、限定するものではないが、アプライアンスは、ネットワーク接続された自動車、冷蔵庫、テレビ、洗濯機／乾燥機、コーヒーメーカー、サーモスタット、および／または同類のものを含み得る。

【0051】

本明細書で使用される場合、「通信」および「通信する」という用語は、一つ以上の信号、メッセージ、コマンド、もしくは他のタイプのデータの受信または転送を指す。一つのユニット（例えば、任意のデバイス、システム、またはそれらのコンポーネント）が、別のユニットと通信するというのは、一つのユニットが直接もしくは間接的に、データを他方のユニットから受信および／またはデータを他方のユニットへ送信できることを意味する。これは、本質的に有線および／もしくは無線である、直接または間接的な接続を指してもよい。加えて、二つのユニットは、送信されるデータが、第一と第二のユニットとの間で変更、処理、遅延、リレー、および／またはルーティングされる場合があるとしても、互いに通信することができる。例えば、第一のユニットが受動的にデータを受信し、第二のユニットへ能動的にデータを送信しないとしても、第一のユニットは第二のユニットと通信することができる。別の例として、中間ユニットが一つのユニットからのデータを処理し、処理されたデータを第二のユニットへ送信する場合、第一のユニットは第二のユニットと通信することができる。多くの他の構成が可能であることは理解されるであろう。

【0052】

本明細書で使用される場合、「発行機関」という用語は、クレジットおよび／またはデビットでの支払いを開始するなど、支払い取引を行うために顧客にアカウントを提供する、銀行などの一つ以上の事業体を指すことができる。例えば、発行機関は、顧客またはアプライアンスと関連付けられた一つ以上のアカウントを一意に識別する、個人アカウント番号（ＰＡＮ）などのアカウント識別子を、顧客またはアプライアンスに提供することができる。アカウント識別子は、支払いカードなどの物理的な金融機器に表示されることがあり、かつ／または電子式であり電子決済に使用することができる。本明細書で使用される場合、「アカウント識別子」という用語は、顧客アカウントに関連付けられた一つ以上のＰＡＮ、トークン、または他の識別子を含んでもよい。アカウント識別子は、直接的または間接的に発行機関に関連付けられる場合があり、それにより、アカウント識別子は、ＰＡＮまたはその他の種類のアカウント識別子にマッピングするトークンであり得る。「トークン」という用語は、ＰＡＮなど、元のアカウント識別子の代用または代替識別子として使用される、識別子を指すことができる。アカウント識別子は、英数字、または文字および／もしくは記号の任意の組み合わせであってもよい。トークンは、元のアカウント識別子を直接使用することなく、取引を行うために使用できるように、一つ以上のデータベースでＰＡＮまたは他の元のアカウント識別子と関連付けることができる。一部の例では、ＰＡＮなどの元のアカウント識別子は、異なる個人に対してまたは異なる目的のために、複数のトークンと関連付けられてもよい。発行機関は、銀行識別番号（ＢＩＮ）、または他の発行機関の中から一意に識別する他の固有識別子と関連付けることができる。「発行機関」、「発行銀行」、および「発行者システム」という用語はまた、一つ以上のソフトウェアアプリケーションを実行するサーバコンピュータなど、発行機関によってまたはそれに変わって運用される、一つ以上のコンピュータシステムを指すこともできる。例えば、発行者システムは、支払い取引を承認するための一つ以上の承認サーバを含んでもよい。

【0053】

本明細書で使用される場合、「加盟店」という用語は、支払い取引などの取引に基づいて、商品および／またはサービス、あるいは商品および／またはサービスへのアクセスを顧客に提供する、個人または事業体を指す。加盟店には、レストラン、フードトラック、クラブ、ジム、小売店、専門サービスプロバイダ（例えば、歯科医、医師、配管工など）、公園、博物館、アトラクション、スポーツ施設、および／または同類のものが含まれるが、これらに限定されない。当然のことながら、その他の多くの種類の加盟店が本発明の範囲内にある。

【0054】

本明細書で使用される場合、「アクワイアラ機関」という用語は、取引サービスプロバイダによってライセンスされ、取引サービスプロバイダによって承認された事業体を指し、取引サービスプロバイダの携帯金融デバイスを使用して取引を開始することができる。取引には、元の信用取引（ＯＣＴｓ）および口座資金取引（ＡＦＴｓ）が含まれる場合がある。アクワイアラ機関は、取引サービスプロバイダから、取引サービスプロバイダの携帯金融デバイスを使用して取引を開始することを承認される場合がある。アクワイアラ機関はペイメントゲートウェイと契約して、ファシリテータが加盟店を後援できるようにする。アクワイアラ機関は、銀行などの金融機関である場合がある。「アクワイアラ機関」、「アクワイアラ銀行」、および「アクワイアラシステム」という用語はまた、一つ以上のソフトウェアアプリケーションを実行するサーバコンピュータなど、アクワイアラ機関によってまたはそれに変わって運用される、一つ以上のコンピュータシステムを指すこともできる。

【0055】

本明細書で使用される場合、「金融デバイス」という用語は、例として、携帯型（例えば、物理的）支払いカード、ギフトカード、スマートカード、スマートメディア、ペイロールカード、ヘルスケアカード、リストバンド、アカウント情報を含む機械可読媒体、キーチェーンデバイス、スーパーマーケットの割引カード、携帯電話、モバイルデバイス、携帯情報端末（ＰＤＡ）、ポケベル、セキュリティカード、コンピュータ、アクセスカード、無線端末、および／またはトランスポンダを指すことができる。金融デバイスは、口座番号または口座名義人の名前などの情報を記憶するための、揮発性または不揮発性メモリを含んでもよい。「金融デバイス」という用語はまた、金融デバイスのユーザと、加盟店などの別の当事者との間の取引を完了するために使用され得る金融取引アカウントに関連する、物理的またはデジタルの任意の固有の識別子を指す場合がある。例えば、金融デバイスは、オンラインストアの支払インターフェースに入力できる金融取引口座番号および確認コードであり得る。他の構成および実施形態が可能であることは理解されるであろう。

【0056】

本明細書で使用される場合、「加盟店システム」という用語は、一つ以上の金融デバイスとの取引を完了するために使用される、一つ以上のサーバコンピュータ、ＰＯＳ（ｐоｉｎｔ－оｆ－ｓａｌｅ）装置、オンラインインターフェース、第三者ホストサービス、および／または同類のものを指し得る。加盟店システムという用語はまた、発行機関、取引サービスプロバイダ、取引処理サーバ、金融デバイス所有者、および／または同類のものとの通信を送信および／または受信するために使用される、一つ以上のサーバコンピュータ、プロセッサ、オンラインインターフェース、第三者ホストサービス、および／または同類のものを指す場合もある。

【0057】

本明細書で使用される場合、「取引サービスプロバイダ」という用語は、加盟店から承認要求を収集し、場合によっては、取引サービスプロバイダと発行機関との間の同意によって、支払いの保証を提供する事業体を指すことができる。本明細書で使用される場合、「反復取引」という用語は、金融デバイスと加盟店との間の任意の一連の反復取引またはパターン取引を指し得る。反復取引は、多くの場合、規則的で同様の金額であるが、反復するためにコストが同一である必要はなく、購入商品／サービスも同一である必要はない。

【0058】

本明細書で使用される場合、「取引処理システム」という用語は、一つ以上のソフトウェアアプリケーションを実行する取引処理サーバなど、取引サービスプロバイダによって、またはそれに代わって運用される一つ以上のコンピュータシステムを指すことができる。取引処理サーバは、一つ以上のプロセッサを含むことができ、一部の非限定的実施形態では、取引サービスプロバイダによってまたはそれに代わって運用することができる。

【0059】

本明細書で使用される場合、「モバイルデバイス」という用語は、一つ以上のネットワークと通信するように構成された、一つ以上の携帯型電子デバイスを指すことができる。例として、モバイルデバイスは、携帯電話（例えば、スマートフォンまたは標準的な携帯電話）、携帯型コンピュータ、ウェアラブルデバイス（例えば、腕時計、眼鏡、レンズ、衣類、および／または同類のもの）、携帯情報端末（ＰＤＡ）、および／または他の類似のデバイスを含んでもよい。

【0060】

本発明の非限定的な実施形態は、アプライアンスに元のアカウント識別子を発行すること、アプライアンスにトークンをプロビジョニングすること、および取引要求を処理するためにアプライアンスを承認することによって、アプライアンスとの取引を実行するための改善されたシステムおよび方法を提供する。アプライアンスに元のアカウント識別子を発行し、アプライアンスにアカウント識別子に対応するトークンをプロビジョニングすることにより、非限定的な実施形態は、アプライアンスに入力されるか、またはアプライアンスに関連付けることができるユーザの個人的な財務情報をさらすリスクなしで、かかるアプライアンスをユーザ（購入者または賃借人など）に提供することを可能にする。さらに、非限定的な実施形態は、様々な加盟店システムとの取引を開始および実施するために使用され得るデバイストークンおよび／またはデバイスＰＡＮを含むメモリを有する改良されたアプライアンスを提供する。こうした改良されたアプライアンスは、より安全で効率的な取引フロー、ならびに本明細書に記載されるその他の利点を提供する。

【0061】

トークンをアプライアンスにプロビジョニングするためのシステムおよび方法が本明細書に提供される。図１は、一つの非限定的な実施形態または態様による、トークンをアプライアンスにプロビジョニングするシステムを示す。図１では、システム（１０００）は、アプライアンス（１０２）、発行者システム（１１４）、および取引処理システム（１１０）を含む。構成要素は、ネットワーク（１０１）を介して通信してもよい。アプライアンスの製造中、または製造後に、元のデバイスの個人アカウント番号（Ｄ_ＰＡＮ）（１０４）は、発行者システム（１１４）および／または取引処理システム（１１０）によってアプライアンス（１０２）に登録される。Ｄ_ＰＡＮ（１０４）は、発行時にユーザまたはアプライアンスの所有者に関連付けられていない元のＰＡＮであり、それにより、一部の非限定的な実施形態ではＤ_ＰＡＮ（１０４）はその後、ユーザＰＡＮにリンクされてもよいが、Ｄ_ＰＡＮ（１０４）は、ヒトには発行されない。一部の非限定的な実施形態または態様では、発行者システム（１１４）および取引処理システム（１１０）の両方が協働してＤ_ＰＡＮ（１０４）をアプライアンスに発行する。一部の非限定的な実施形態または態様では、元のアカウント識別子を登録することは、アプライアンスに特定の固有のデバイス識別子をＤ_ＰＡＮ（１０４）と関連付けることを含む。アプライアンスに特定の固有のデバイス識別子は、アプライアンス（１０２）のメモリ（１０５）にエンコードされてもよい。

【0062】

さらに図１を参照すると、非限定的な実施形態または態様では、アプライアンス（１０２）は、取引を行うため、Ｄ_ＰＡＮ（１０４）でプロビジョニングされてもよい。しかしながら、その他の非限定的な実施形態では、アプライアンスはデバイストークン（Ｄ_{Ｔｏｋｅｎ}）（１０６）をＤ_ＰＡＮ（１０４）の代わりに、またはそれに加えてプロビジョニングしてもよい。たとえば、Ｄ_{Ｔｏｋｅｎ}（１０６）は、Ｄ_ＰＡＮ（１０４）を、潜在的なセキュリティの脆弱性に露出しないように、アプライアンス（１０２）上でプロビジョニングできる。当然のことながら、図１は、Ｄ_{Ｔｏｋｅｎ}（１０６）およびＤ_ＰＡＮ（１０４）を示すが、非限定的な実施形態は、Ｄ_{Ｔｏｋｅｎ}（１０６）または単にＤ_ＰＡＮ（１０４）のみを含み得る。

【0063】

引き続き図１を参照すると、アプライアンス（１０２）がＤ_{Ｔｏｋｅｎ}（１０６）でプロビジョニングされる非限定的な実施形態では、取引処理システム（１１０）はＤ_{Ｔｏｋｅｎ}（１０６）を生成してＤ_{Ｔｏｋｅｎ}（１０６）をＤ_ＰＡＮ（１０４）に関連付けることによって、Ｄ_ＰＡＮ（１０４）をトークン化する。関連付けられたＤ_ＰＡＮ（１０４）およびＤ_{Ｔｏｋｅｎ}（１０６）は、トークンボルト（１１８）に記憶され、非限定的な実施形態では、安全なデータベースを含む。この段階では、Ｄ_ＰＡＮ（１０４）およびＤ_{Ｔｏｋｅｎ}（１０６）は、ユーザＰＡＮ（例えば、マスターＰＡＮ）（Ｍ_ＰＡＮ）などのユーザまたは所有者財務情報と関連付けられない。トークンボルトアーキテクチャの非限定的な実施形態または態様を以下に示す。

【0064】

【表1】

【0065】

取引処理システム（１１０）はＤ_{Ｔｏｋｅｎ}（１０６）をその上に保管するアプライアンス（１０２）に伝達する。この段階では、Ｄ_{Ｔｏｋｅｎ}（１０６）は、アプライアンス（１０２）上に非アクティブ状態で常駐する。

【0066】

次いで、アプライアンス（１０２）は、ユーザによって購入、賃貸、またはリースされてもよい。図１をさらに参照すると、ユーザデバイス（１０３）もまた図示されている。ユーザーデバイス（１０３）は、例えば、スマートフォン、タブレット、コンピューティングデバイス、リモートコントロールなどであるがこれに限定されない、ユーザがアプライアンス（１０２）および／または取引処理システム（１１０）と対話することを可能にする任意の種類のクライアントデバイスであってもよい。しかしながら、ユーザデバイス（１０３）を通して、またはユーザデバイス（１０３）を使用して行われると記載される任意の動作も、例えば、ユーザインターフェースおよびアプライアンス（１０２）上に配置された入力デバイスを通して、ユーザとアプライアンス（１０２）自体との直接的な対話によっても可能であることが理解されるべきである。ユーザデバイス（１０３）は、アプライアンス（１０２）に記憶されたＤ_{Ｔｏｋｅｎ}（１０６）を起動するために使用され得る。

【0067】

非限定的な実施形態または態様において、Ｄ_ＰＡＮ（１０４）および／またはＤ_{Ｔｏｋｅｎ}（１０６）がアプライアンス（１０２）上でプロビジョニングされると、アプライアンス（１０２）はＤ_ＰＡＮ（１０４）および／またはＤ_{Ｔｏｋｅｎ}（１０６）を使用して取引要求を開始するために使用できる。しかしながら、一部の非限定的な実施形態では、Ｄ_ＰＡＮ（１０４）および／またはＤ_{Ｔｏｋｅｎ}（１０６）は、使用前に起動する必要がある場合がある。たとえば、Ｄ_ＰＡＮ（１０４）および／またはＤ_{Ｔｏｋｅｎ}（１０６）は、ユーザのＭ_ＰＡＮをＤ_ＰＡＮ（１０４）および／またはＤ_{Ｔｏｋｅｎ}（１０６）に関連付けるユーザによって起動され得る。これにより、ユーザは、その特定のユーザに対してアクティブ化する一方で、Ｄ_ＰＡＮ（１０４）および／またはＤ_{Ｔｏｋｅｎ}（１０６）を使用して開始された取引について最終的な責任を負う。

【0068】

非限定的な実施形態または態様において、Ｄ_{Ｔｏｋｅｎ}（１０６）は、アプライアンス（１０２）の初期使用時、またはユーザが起動プロセスを受ける選択時に起動される。ユーザは、アプライアンス（１０２）またはユーザデバイス（１０３）を通して、アプライアンス（１０２）の所有権または所有を取引処理システム（１１０）に伝達するように促され得る。取引処理システム（１１０）は、所有者によって開始された起動要求に応じて、Ｍ_ＰＡＮなどのユーザに発行された携帯金融デバイス（クレジットカードまたはデビットカードなど）に関連付けられたアカウント識別子をアプライアンス（１０２）と関連付ける。一部の非限定的な実施形態または態様では、Ｍ_ＰＡＮをＤ_ＰＡＮ（１０４）および／またはＤ_{Ｔｏｋｅｎ}（１０６）に関連付ける起動要求は、アプライアンス（１０２）を介して取引処理システム（１１０）に通信される。一部の非限定的な実施形態または態様では、ユーザまたはアプライアンス（１０２）は、ユーザがユーザデバイス（１０３）を通して関連付け要求を取引処理システム（１１０）に伝達できるように、アプライアンス（１０２）の識別情報を提供する。識別情報は、一意のデバイス識別子など、アプライアンス（１０２）を識別する任意の種類の情報であってもよい。一意のデバイス識別子は、例えば、限定されないが、シリアル番号、ランダムに生成された英数字識別子、一意のアプライアンス属性、および／または同種のものを含み得る。非限定的な実施形態または態様では、識別情報は、ユーザデバイス（１０３）が読み取って取引処理システム（１１０）に送信することができるバーコード（例えば、二次元バーコード、三次元バーコード、ＱＲコード（登録商標）など）、ＲＦＩＤトランスポンダ、または同様のものなどの機械可読印として提供されてもよい。

【0069】

ユーザはまた、ユーザデバイス（１０３）、アプライアンス（１０２）、ポイントオブセールス（ＰＯＳ）システム、または別のデバイスを介してＭ_ＰＡＮを提供することができる。一例として、ユーザは、ユーザデバイス（１０３）上のモバイルアプリケーションを介して携帯金融デバイスをスキャンすることができ、これは携帯金融デバイスの画像を分析して、有効期限やセキュリティコードなどＭ_ＰＡＮおよびその他の情報を画像から判定する。他の例では、ユーザは、Ｍ_ＰＡＮおよびその他の情報を手動で入力してもよい。当然のことながら、ユーザはＭ_ＰＡＮを色々な方法で提供し得る。また一部の非限定的な例では、取引処理システム（１１０）および／または発行者システム（１１４）は、既にＭ_ＰＡＮを有し、ユーザの識別に基づいて識別できる。他の非限定的な実施形態では、ユーザは、Ｍ_ＰＡＮがＰＯＳシステムから取引処理システム（１１０）に伝達されるように、アプライアンス（１０２）の購買またはリースのときＰＯＳで携帯金融デバイスを提示できる。さらなる実施例では、ユーザは既存の銀行口座または電子ウォレットにログインすることによってＭ_ＰＡＮを提供し得る。当然のことながら、Ｍ_ＰＡＮは、様々な他の方法で提供され得る。

【0070】

取引処理システム（１１０）が、例えば、アプライアンス（１０２）またはユーザデバイス（１０３）を介して、ユーザによって開始される起動要求を受信するのに応答して、取引処理システム（１１０）は、上述したように、Ｍ_ＰＡＮを取得、識別、または受信することができる。取引処理システム（１１０）は、起動要求および／またはＭ_ＰＡＮの取得に応じて、Ｍ_ＰＡＮをトークンボルト（１１８）内のＤ_ＰＡＮ（１０４）および／またはＤ_{Ｔｏｋｅｎ}（１０６）に関連付ける。

【0071】

【表2】

【0072】

一部の非限定的な実施形態または態様では、デバイスプロファイルは、アプライアンス（１０２）用に生成され得る。デバイスプロファイルは、例えば、固有の識別子（例えば、デバイス識別子）、アプライアンスの種類、アプライアンスのモデル、アプライアンスの製造業者、アプライアンス取引履歴、アプライアンス使用期間、アプライアンス使用時間、アプライアンスサービス履歴、および／またはそれらの組み合わせなどの一つ以上のアプライアンスパラメータに基づいてもよいが、これらに限定されない。デバイスプロファイルは、トークンボルト（１１８）などであるが、これに限定されない、データベース内のＤ_{Ｔｏｋｅｎ}（１０４）および／またはＤ_ＰＡＮ（１０６）に関連付けることができる。デバイスプロファイルは、発行者システム（１１４）、取引処理システム（１１０）、アプライアンス自体（１０２）、またはその他の任意のデバイスまたはシステムによって生成され得る。一部の非限定的な例では、デバイスプロファイルは、一連のアプライアンスパラメータ、一連のアプライアンスパラメータから生成されたスコアまたは評価、あるいは事前定義されたプロファイルカテゴリであってもよい。

【0073】

一部の非限定的な実施形態または態様では、アプライアンス（１０２）に対してドメイン制限が生成され得る。非限定的な実施形態または態様では、ドメイン制限は、少なくとも部分的にデバイスプロファイルに基づいてもよい。ドメイン制限の非限定的な例としては、信用／デビット限度額、取引限度額、取引数の制限、Ｄ_{Ｔｏｋｅｎ}の持続期間（寿命）、ならびに／あるいは加盟店のカテゴリ制限もしく加盟店の場所制限、および加盟店のロイヤルティまたはリワードポイントプログラム制限などの加盟店ドメイン制限が挙げられる。例として、非限定的な実施形態では、Ｄ_{Ｔｏｋｅｎ}および／またはＤ_ＰＡＮでプロビジョニングされたアプライアンスは、アプライアンス（例えば、テレビ用のストリーミングメディア、自動車用の燃料、および／または同類のもの）が使用できる品目および／またはコンテンツの購入に制限され得る。

【0074】

非限定的な実施形態または態様では、ドメイン制限は、アプライアンスの寿命の様々な時間で変更され得る。例えば、限定はされないが、アプライアンスはＤ_{Ｔｏｋｅｎ}（１０６）および／またはＤ_ＰＡＮ（１０４）がＭ_ＰＡＮに関連付けられる前に特定の信用／デビット限度額に制限される場合がある。非限定的な実施形態では、信用／デビット限度額は、所有期間の増加および／またはＭ_ＰＡＮとの関連付けに伴って増加され得る。他の非限定的な実施形態または態様では、アプライアンスユーザは、アプライアンスのクレジット／デビット限度額の修正を手動で要求し得る。

【0075】

非限定的な実施形態では、デバイスプロファイルは、ターゲットを絞った販売促進のための推奨、オファー、および／または加盟店のロイヤルティもしくはリワードポイントプログラムの制限を実施するために使用され得る。なぜなら、アプライアンスのＤ_ＰＡＮは、特定の加盟店での使用、および／または特定の製品／サービスの購入もしくは製品／サービスのクラスを制限される場合があるので、加盟店は、ターゲットを絞ったプロモーションやオファーをアプライアンスに提供する場合がある。その結果、Ｄ_ＰＡＮの特定の使用分野を考慮すると、ロイヤルティリワードまたはポイントがより早く蓄積される可能性がある。一部の非限定的な例では、ロイヤルティリワードまたはポイントの残高が多いアプライアンスは、ユーザがアプライアンスの販売を申し出たり、リースを終了したり、または別の方法でアプライアンスを誰かに提供した場合に、ユーザ／所有者にとってより高い再販価格または残存価格を維持する場合がある。

【0076】

図１の参照を継続すると、アプライアンス（１０２）のユーザ（例えば、アプライアンスの所有者、アプライアンスのユーザ／賃借人など）が、アプライアンス（１０２）の所有権、所有、および／または制御を販売、返却、またはその他の方法で放棄する場合、ユーザおよび／またはユーザデバイス（１０３）は、所有者のＭ_ＰＡＮをＤ_ＰＡＮ（１０４）および／またはＤ_{Ｔｏｋｅｎ}（１０６）からを切り離すことを目的として、Ｍ_ＰＡＮをＤ_ＰＡＮ（１０４）および／またはＤ_{Ｔｏｋｅｎ}（１０６）に関連付けるために、上述したのと同じ方法で（例えば、ユーザデバイス（１０３）を通して、またはアプライアンス（１０２）を通して直接）、取引処理システム（１１０）と通信し得る。取引処理システム（１１０）はその後、次の表に示すようにＭ_ＰＡＮをトークンボルト（１１８）のＤ_ＰＡＮ（１０４）およびＤ_{Ｔｏｋｅｎ}（１０６）から切り離す。

【0077】

【表3】

【0078】

トークンボルト（１１８）のＤ_ＰＡＮ（１０４）および／またはＤ_{Ｔｏｋｅｎ}（１０６）に関連付けられた対応するＭ_ＰＡＮがない場合、取引の検証または承認はできない。さらに、一部の非限定的な実施形態または態様では、Ｄ_ＰＡＮがＭ_ＰＡＮとの関連付けを解除されると、クレジット／デビット限度額は減らされる可能性があり、取引の検証／承認におけるエラーによる潜在的な損失を削減する。一部の非限定的な実施形態または態様では、Ｍ_ＰＡＮは、別のユーザまたは別のＭ_ＰＡＮを持つ同じユーザからの起動要求に応答して、Ｄ_ＰＡＮおよび／またはＤ_{Ｔｏｋｅｎ}から切り離されている可能性がある。

【0079】

図２を参照すると、非限定的な実施形態による、トークンをアプライアンスにプロビジョニングする方法が図示されている。ステップ（ｓ１）では、アプライアンスの製造業者、代理店、または再販業者は、Ｄ_ＰＡＮおよびＤ_{Ｔｏｋｅｎ}を記憶するためのメモリをアプライアンス（１０２）内に含む。一部の非限定的な実施形態または態様では、メモリは、安全なかつ／または暗号化されたメモリ空間を含む。一部の非限定的な実施形態または態様において、Ｄ_ＰＡＮと関連付けられていないＤ_{Ｔｏｋｅｎ}は、この時点でメモリに記憶できる。ステップ（ｓ２）では、Ｄ_ＰＡＮは、アプライアンスに発行される。Ｄ_ＰＡＮは、ステップ（ｓ２ａ）の発行者システム（１１４）、ステップ（ｓ２ｂ）の取引処理システム（１１０）、またはその両方により発行される。実施形態または態様において、例えば、限定するものではないが、取引処理システム（１１０）がＤ_ＰＡＮの発行に関与せず、Ｄ_{Ｔｏｋｅｎ}がアプライアンスにすでに記憶されていないものは、ステップ（ｓ３）では、Ｄ_ＰＡＮが、トークン化される取引処理システムに伝達される。取引処理システムがＤ_ＰＡＮをステップ（ｓ４）でトークン化し、それによってＤ_{Ｔｏｋｅｎ}を生成する。Ｄ_{Ｔｏｋｅｎ}は、次に、ステップ（ｓ５）でアプライアンス（１０２）に伝達され、そこでは、ユーザが購入、賃貸、リース、またはその他の形態で所有するまで、Ｄ_{Ｔｏｋｅｎ}は記憶され、非アクティブである。

【0080】

Ｄ_{Ｔｏｋｅｎ}がアプライアンス（１０２）にプロビジョニングされた後、図２をさらに参照して、Ｄ_{Ｔｏｋｅｎ}は、ユーザによって起動され得る。ステップ（ｓ６）では、ユーザデバイス（１０３）またはアプライアンス（１０２）を介して、所有者がステップ（ｓ７）で取引処理システム（１１０）と通信し、取引処理システム（１１０）がＭ_ＰＡＮを含むユーザの携帯金融デバイスをステップ（ｓ８）でＤ_ＰＡＮおよび／またはＤ_{Ｔｏｋｅｎ}に関連付けられるようにする識別情報を提供する。

【0081】

図３は、非限定的な実施形態または態様に従う、Ｄ_{Ｔｏｋｅｎ}を使用して取引を処理するシステム（２０００）を示す。図３では、システム（２０００）は、アプライアンス（１０２）、加盟店システム（１０８）、アクワイアラシステム（１１２）、発行者システム（１１４）、および取引処理システム（１１０）を含む。構成要素は、ネットワーク（１０１）を介して通信してもよい。取引を実行すると、アプライアンス（１０２）は、取引要求を伝達し、これには、Ｄ_{Ｔｏｋｅｎ}（１０６）および／またはＤ_ＰＡＮ（１０４）、ならびに任意選択で、取引要求をアクワイアラシステム（１１２）（例えば、アクワイアリング銀行システム）に伝達する加盟店システム（１０８）への取引データが含まれ得る。取引データは、例えば、取引額、取引日、取引時間、取引場所、加盟店識別子、購入する製品／サービスの識別、アプライアンス情報（例えば、一意のデバイス識別子、デバイスプロファイルなど）および／または同類のものを含み得るが、これらに限定されない。次に、アクワイアラシステム（１１２）は、取引要求を取引処理システム（１１０）に伝達し、取引要求を検証し、取引処理の権限を取得する。このような承認は、２段階のプロセスで行われる場合がある。

【0082】

第一に、非限定的な実施形態または態様では、取引処理システム（１１０）は、トークンボルト（１１８）内のＤ_{Ｔｏｋｅｎ}（１０６）および／またはＤ_ＰＡＮ（１０４）のチェックを行うことができ、Ｄ_{Ｔｏｋｅｎ}（１０６）および／またはＤ_ＰＡＮ（１０４）はトークンボルト（１１８）内のＭ_ＰＡＮに関連付けられていると判定することに応じて、取引処理システム（１１０）は、取引が承認されていると判定し得る。取引が承認されるとの判定には、Ｄ_{Ｔｏｋｅｎ}（１０６）および／またはＤ_ＰＡＮ（１０４）に関連付けられたドメイン制限のチェック、Ｍ_ＰＡＮが有効であり、取引および／または同種のものに使用できるとの検証も含まれる。一部の非限定的な実施形態では、取引が承認されているとの判定には、取引要求に含まれる固有のデバイス識別子が、Ｄ_{Ｔｏｋｅｎ}（１０６）および／またはＤ_ＰＡＮ（１０４）に関連付けられた固有の識別子と一致するかどうかの確認が含まれる。取引が承認されると判定する場合、取引処理システム（１１０）は取引を処理する。

【0083】

非限定的な実施形態または態様では、承認の第２のステップは、取引がＤ_ＰＡＮ（１０４）を、任意で一部の実施形態または態様では、取引データを、取引の承認のために発行者システム（１１４）に伝達することによって承認されると判定する取引処理システム（１１０）を含み得る。発行者システム（１１４）が取引を承認すると、承認応答メッセージが生成され、取引処理システム（１１０）に伝達され、取引が処理される。

【0084】

非限定的な実施形態または態様では、取引処理システム（１１０）は、取引が、少なくとも部分的にアプライアンス（１０２）のデバイスプロファイルに基づいて承認されていると判定する。例えば、非限定的な実施形態または態様では、取引処理システム（１１０）は、取引が、少なくとも部分的に、アプライアンス（１０２）のデバイスプロファイルに明記されるドメイン制限に基づいて承認されていると判定し得る。取引処理システム（１１０）が、取引要求がドメイン制限を満たすと判定する場合、取引は承認され、処理され得る。同様に、取引要求がドメイン制限を満たさないと判定するのに応答して、取引処理システム（１１０）は、拒否をアクワイアラシステム（１１２）、加盟店システム（１０８）、アプライアンス（１０２）、および／またはユーザデバイス（１０３）（図示せず）に伝達し得る。

【0085】

非限定的な実施形態または態様では、複数のアプライアンスおよび／または複数のデバイストークンを使用して、取引に従事してもよい。例えば、アプライアンス（１０２）から伝達された取引要求が、ドメイン制限（例えば、取引額が信用限度または取引限度を超える）を満たさないと判定された場合、ユーザに関連付けられた複数のアプライアンスの信用限度（またはその他のドメイン制限）を集計して、取引の実行を許可することができる。かかる実施形態または態様において、取引処理システム（１１０）は、Ｄ_ＰＡＮ（１０４）を含む承認要求を承認のため発行者システム（１１４）に送ることによって、取引額の第一の部分をＤ_{Ｔｏｋｅｎ}（１０６）に請求し、一つ以上の追加のアプライアンスに関連付けられた一つ以上のＤ_{Ｔｏｋｅｎ}に取引額の第２部分を請求する。非限定的な実施形態では、アプライアンス自体は、ドメイン制限が満たされているかどうかを判定し得る。例えば、アプライアンスは、追加のアプライアンス（すなわち、当初要求したアプライアンス（１０２）以外のアプライアンス）がそのドメイン制限を、アプライアンス（１０２）が、そのドメイン制限に基づいて取引を要求できない、または拒否を受信できないと判定することに応答して、アプライアンス（１０２）に伝達できるように互いに通信することができる。他の非限定的な実施形態では、ドメイン制限は、取引処理システム（１１０）、発行者システム（１１４）、またはその他のシステムによって適用可能であるか、または適用できないかを判定され得る。

【0086】

一部の非限定的な実施形態または態様では、取引処理システム（１１０）は、取引が、Ｍ_ＰＡＮおよび任意で、一部の実施態様または態様において、取引データをＭ_ＰＡＮに関連付けられた発行者システム（１１６）へ伝達することによって承認されると判定する。発行者システム（１１６）が取引を承認すると、承認応答が取引処理システム（１１０）に伝達され、取引が処理される。

【0087】

一部の非限定的な実施形態または態様では、取引処理システム（１１０）が、アプライアンス（１０２）によって開始された取引を処理するとき、取引処理システム（１１０）は、取引額に対応する金額を控除するための承認要求を生成し、承認要求を発行者システム（１１６）に伝える。他の非限定的な実施形態または態様では、取引処理システム（１１０）は、アプライアンス（１０２）によって開始された取引の取引データを一定期間にわたって集計し、単一の承認要求を生成して発行者システム（１１６）に伝達して、集計された取引金額に対応する金額を控除する。

【0088】

図２に戻ると、非限定的な実施形態または態様による、アプライアンス（１０２）によって開始される取引を処理する方法も図示されている。ステップ（ｓ９）では、アプライアンス（１０２）は取引要求を加盟店システム（１０８）（図示せず）またはアクワイアラシステム（１１２）に伝達する。取引要求には、取引データ、Ｄ_{Ｔｏｋｅｎ}、および一部の非限定的な例では、Ｄ_ＰＡＮが含まれる。ステップ（ｓ１０）では、アクワイアラシステム（１１２）は取引データ、Ｄ_{Ｔｏｋｅｎ}および一部の非限定的な例では、Ｄ_ＰＡＮを検証および承認のために取引処理システム（１１０）へ伝達する。ステップ（ｓ１１）では、取引処理システム（１１０）がトークンボルトをチェックし、Ｄ_{Ｔｏｋｅｎ}および／またはＤ_ＰＡＮがＭ_ＰＡＮに関連付けられていることを検証する。Ｄ_{Ｔｏｋｅｎ}および／またはＤ_ＰＡＮがＭ_ＰＡＮに関連付けられている場合、ステップ（ｓ１２）で、Ｄ_ＰＡＮを含む承認要求および、一部の非限定的な実施形態では、取引データは発行者システム（１１４）に送信される。取引が承認された場合、発行者システム（１１４）は、ステップ（ｓ１３）で取引処理システム（１１０）に承認応答を伝達する。承認された場合、取引処理システム（１１０）は取引を処理し、ステップ（ｓ１４）では、承認応答を加盟店アクワイアラシステム（１１２）に伝達し、一部の非限定的な例では、例えば、ユーザデバイス（１０３）に伝達された通知を通して、アプライアンス（１０２）および／またはアプライアンスユーザに伝達する。

【0089】

ここで図４を参照すると、アプライアンスへのトークンの承認およびプロビジョニングのための非限定的な実施形態または方法（４０００）の態様のフロー図を示す。方法（４０００）の一つ以上のステップは、本明細書に記述されたような取引処理システムによって部分的または完全に実施され得るが、他のデバイスおよび／またはシステムは、非限定的な実施形態では一つ以上のステップを実行し得ることが理解されるであろう。図４に示す通り、ステップ（４０２）で、元のアカウント識別子がアプライアンスに発行される。本明細書に記載されるように、元のアカウント識別子（Ｄ_ＰＡＮ）は、発行時点でユーザまたはアプライアンスの所有者に関連付けられていない。ステップ（４０４）では、デバイストークン（Ｄ_{Ｔｏｋｅｎ}）が元のアカウント識別子（Ｄ_ＰＡＮ）に関連付けられる。Ｄ_{Ｔｏｋｅｎ}は、生成されるか、すでに存在する可能性がある。Ｄ_{Ｔｏｋｅｎ}は、アプライアンスのメモリに記憶できる。ステップ（４０６）では、ユーザアカウント識別子（Ｍ_ＰＡＮ）はＤ_{Ｔｏｋｅｎ}および／またはＤ_ＰＡＮに関連付けられている。前述のように、この関連付けはトークンボルトに記憶できる。Ｍ_ＰＡＮは、Ｄ_ＰＡＮとは独立して存在するユーザ用の別個の元のアカウント識別子である場合がある。

【0090】

図４を引き続き参照すると、ステップ（４０８）では、Ｄ_{Ｔｏｋｅｎ}を含む取引要求はアプライアンスから受信される。ステップ（４１０）では、Ｍ_ＰＡＮまたは対応するトークンなどのユーザアカウントが、少なくとも部分的にＤ_{Ｔｏｋｅｎ}に基づいて識別される。その後、ステップ（４１２）で、取引が承認されているかどうかが判定される。この判定は、少なくとも部分的にＤ_ＰＡＮに基づき、一部の非限定的な実施形態では、少なくとも部分的にＤ_ＰＡＮおよびＭ_ＰＡＮに基づく。ステップ（４１４）では、取引が承認されたという判定に応じて、取引が処理される。例えば、Ｄ_ＰＡＮはＭ_ＰＡＮに関連付けられているので、取引は最初承認されたという判定に応じて、取引処理システムは、承認要求を生成し、発行者システムに伝達し、取引を完了できる最終承認を得ることができる。

【0091】

ここで図５を参照すると、非限定的な実施形態のフロー図、または取引を処理するためのアプライアンスを承認する方法（５０００）の態様を示す。方法（５０００）の一つ以上のステップは、取引処理システムによって部分的または完全に実施されてもよいが、他のデバイスおよび／またはシステムは、非限定的な実施形態では一つ以上のステップを実行してもよいことが理解されよう。図５に示すように、ステップ（５０２）で、元のアカウント識別子が発行され、アプライアンスに登録される。本書に記載されるように、元のアカウント識別子（Ｄ_ＰＡＮ）は、発行時点でユーザまたはアプライアンスの所有者に関連付けられていない。ステップ（５０４）では、取引要求は、アプライアンスから直接または間接的に受信される。取引要求には、アプライアンスに関連づけられたＤ_{Ｔｏｋｅｎ}および／またはＤ_ＰＡＮが含まれる。ステップ（５０６）では、Ｄ_ＰＡＮを含む承認要求が生成される。ステップ（５０８）では、承認要求はＤ_ＰＡＮに関連付けられた発行者システムに伝達される。

【0092】

また、アプライアンスが支払いを受け取ることを承認するシステムおよび方法も本明細書に記載される。このようなシステムは、非限定的な実施形態および態様に従い図１および図３に示される。このシステムおよび方法は、アプライアンス（１０２）、発行者システム（１１４）、および取引処理システム（１１０）を含む、上述のものと同じ構成要素を使用し得る。構成要素は、ネットワーク（１０１）を介して通信してもよい。元のＤ_ＰＡＮ（１０４）は、発行者システム（１１４）および／または取引処理システム（１１０）によってアプライアンス（１０２）に登録される。Ｄ_ＰＡＮ（１０４）は、発行時にユーザまたはアプライアンスの所有者に関連付けられていない元のＰＡＮであり、それにより、一部の非限定的な実施形態ではＤ_ＰＡＮ（１０４）はその後、ユーザＰＡＮにリンクされてもよいが、Ｄ_ＰＡＮ（１０４）は、ヒトには発行されない。一部の非限定的な実施形態または態様では、発行者システム（１１４）と取引処理システム（１１０）が連携してＤ_ＰＡＮ（１０４）をアプライアンスに発行する。一部の非限定的な実施形態または態様では、元のアカウント識別子を登録することは、アプライアンスに特定の固有のデバイス識別子をＤ_ＰＡＮ（１０４）と関連付けることを含む。アプライアンスに特定の固有のデバイス識別子は、アプライアンス（１０２）のメモリ（１０５）にエンコードされてもよい。

【0093】

取引を承認する方法は、上記に説明されている。取引の承認に有用な同じ構成要素は、アプライアンス（１０２）による支払の受諾を承認するのに有用であり得る。例えば、限定するものではないが、ユーザは、ユーザデバイス（１０３）を通して、またはアプライアンス（１０２）自体を通して、アプライアンス（１０２）と対話して、例えば、アプライアンスのレンタル／リース、または同類のものに対する支払いを提出することができる。従来の支払い方法と同様に、これには、ユーザデバイス（１０３）を通して、またはアプライアンス（１０２）自体を通して、ユーザに関連付けられたアカウント識別子（すなわち、Ｕ_ＰＡＮまたはＵ_{Ｔｏｋｅｎ}）を含む支払要求をユーザがアプライアンス（１０２）に伝達することを含んでもよい。支払要求にはＤ_ＰＡＮ、Ｄ_{Ｔｏｋｅｎ}、Ｕ_ＰＡＮ、および／またはＵ_{Ｔｏｋｅｎ}を含めることができる。さらに、支払要求には、例えば、支払金額、支払日、支払時間、支払場所、加盟店識別子、購入する製品／サービスの識別、アプライアンス情報（例えば、一意のデバイス識別子、デバイスプロファイルなど）および／または同類のものなどであるが、これらに限定されない、支払データが含まれ得る。

【0094】

アプライアンス（１０２）は支払要求を、例えば、レンタカー会社またはその他のリースもしくはレンタル代理店に関連する場合があるが、これらに限定されない加盟店システム（１０８）および／またはアクワイアラシステム（１１２）に伝達する。次に、アクワイアラシステム（１１２）は、支払要求を取引処理システム（１１０）に伝達し、支払要求を検証し、支払処理の承認を受ける。取引処理システム（１１０）は、支払がＵ_ＰＡＮおよび／またはＵ_{Ｔｏｋｅｎ}ならびに随意に、一部の態様または態様では、支払データを、Ｕ_ＰＡＮおよび／またはＵ_{Ｔｏｋｅｎ}に関連付けられた発行者システム（１１６）へ伝達することによって承認されていると判定する。発行者システム（１１６）が支払を承認すると、承認応答が取引処理システム（１１０）に伝達され、支払が処理される。非限定的な実施形態または態様では、取引処理システム（１１０）は、承認をアプライアンス（１０２）、加盟店システム（１０８）、アクワイアラシステム（１１２）、および／またはユーザデバイス（１０３）に伝達する。上述のように、非限定的な実施形態または態様では、取引処理システムによる承認は、二段階承認であってもよく、それによって、第１段階において、取引処理システム（１１０）は、トークンボルト（１１８）のＤ_{Ｔｏｋｅｎ}（１０６）および／またはＤ_ＰＡＮ（１０４）のチェックを実施してもよく、Ｄ_{Ｔｏｋｅｎ}（１０６）および／またはＤ_ＰＡＮ（１０４）がトークンボルト（１１８）のＭ_ＰＡＮ（レンタカー会社、リース会社などに関連付けられたアカウント識別子など）に関連付けられていると判定することに応じて、取引処理システム（１１０）は、支払が承認されていると判定することができる。第二の承認段階では、取引処理システムはＵ_ＰＡＮおよび／またはＵ_{Ｔｏｋｅｎ}ならびに随意に、一部の態様または態様では、支払データを、上記で説明したとおり、Ｕ_ＰＡＮおよび／またはＵ_{Ｔｏｋｅｎ}に関連付けられた発行者システム（１１６）へ伝達してもよい。さらなる非限定的な実施形態または態様では、取引処理システム（１１０）、発行者システム（１１４）、および／またはアプライアンス（１０２）自体は、取引処理システム（１１０）による支払いの承認および処理の前に、支払要求がアプライアンスに関連付けられたドメイン制限を満たすと判定する。

【0095】

一部の非限定的な実施形態または態様では、取引処理システム（１１０）が、アプライアンス（１０２）によって受信された支払要求を処理するとき、取引処理システム（１１０）は、支払値に対応する金額を控除する承認要求を生成し、承認要求を発行者システム（１１４）に伝える。この控除額は、トークンボルト（１１８）に記憶されたＭ_ＰＡＮに関連付けられた発行者システムに入金される。他の非限定的な実施形態または態様では、取引処理システム（１１０）は、アプライアンス（１０２）が一定期間に受け取った支払の支払データを集計し、単一の承認要求を生成して発行者システム（１１４）に伝達し、合計支払金額に相当する金額を控除し、トークンボルト（１１８）に記憶されたＭ_ＰＡＮに関連付けられた発行者システムに合計支払金額を入金する。

【0096】

さらに、ユーザ固有のアカウントを必要とすることなく、取引を行うためのアプライアンスが本明細書に提供される。再度図１を参照すると、アプライアンス（１０２）は、ユーザに関連付けられていないＤ_ＰＡＮ（１０４）および／またはデバイスアカウント識別子と一意に関連付けられるＤ_{Ｔｏｋｅｎ}（１０６）を記憶するアプライアンス（１０２）の内部メモリ（１０５）、通信デバイス、ならびにＤ_ＰＡＮ（１０４）およびＤ_{Ｔｏｋｅｎ}（１０６）のうちの少なくとも一つを含む取引要求を生成するようにプログラムまたは構成されるメモリおよび通信デバイスと通信するプロセッサ、を含む。非限定的な実施形態または態様では、アプライアンスプロセッサは、取引要求を取引処理システムに伝達し、取引要求の拒否を受信し、それに応答して、Ｄ_ＰＡＮ（１０４）およびＤ_{Ｔｏｋｅｎ}（１０６）のうちの少なくとも一つ、および少なくとも一つの他のＤ_ＰＡＮまたは少なくとも一つの他のアプライアンスと関連づけられたＤ_{Ｔｏｋｅｎ}を含む新しい取引要求を生成し、新しい取引要求を取引処理システムに伝達するようにプログラムまたは構成される。

【実施例1】

【0097】

［スマートホーム］
本明細書に記載される本発明の非限定的な実施形態を組み込んだスマートホーム実装において、洗濯機や冷蔵庫、テレビ、および／または同類のものなどの一つ以上のアプライアンスは、商品やサービスの提供者、電力会社、および／またはデバイス製造業者と例えば、限定はされないが、消耗している、または消耗していると考えられる供給品を注文するため、メンテナンスや修理の予定を立てるため、メディアコンテンツまたはソフトウェアの購入のため、サービスへのアクセスを購入するため、および／または同類のもののため取引を行う。取引は、それぞれのアプライアンスに関連付けられた一つ以上のＤ_{Ｔｏｋｅｎ}および／またはＤ_ＰＡＮを使用して要求される。上述のように、各デバイス上にプロビジョニングされたＤ_ＰＡＮには、信用／デビット限度額および／または取引限度額とともに、たとえば、許可された製品、ブランド、および加盟店のリストなどに限定されない、関連するドメイン制限がある場合がある。アプライアンスは、初期信用限度額／デビットファンド値（デバイスモデルおよび／または製造業者により２０ドル、５０ドルなど）で事前構成することもでき、これは、割引の有無に関わらず、アプライアンスの販売／レンタル／リース価格に組み込まれ得る。

【0098】

上記のプロモーションの推奨やオファーの推進に加え、デバイスプロファイルを相対的なプロファイルランキングにも使用できる。デバイスプロファイルの相対的なランキングは、クレジットカード発行者の顧客プロファイルと類似した方法で開発できる。デバイスプロファイルのランクが高いほど、デバイスに発行されたＤ_ＰＡＮを使用して利用できるオファーが良くなる。結果として、より良いプロファイルはデバイスの価値を高め、デバイスの再販価値にプレミアムを追加する。例えば、限定するものではないが、主に洗剤および洗剤様製品を購入する洗濯機は、特定の加盟店ドメインに限定されてもよく、ターゲットを絞ったプロモーションまたはオファーを受け取り得、また、加盟店に関連付けられたロイヤルティまたはリワードポイントを急速に蓄積し得る。この累積価値は再販売の価値を高める。これは、蓄積されたロイヤルティまたはリワードポイントが、将来における運用コストの低下につながる可能性があるためである。このことは、アプライアンスを販売しようとするときに、アプライアンスの所有者が宣伝することができる。同一アプライアンス（製造業者／モデル）だが、デバイスプロファイルが異なると、商品／サービスの違いにより、再販価値が異なる可能性があり、新しい所有者に利益がもたらされる。

【0099】

スマートホームソリューションの追加機能には、ドメイン制限が重複する複数のアプライアンス間で支払を分割することが含まれる。例えば、限定はされないが、Ｄ_ＰＡＮが、特定の月次、四半期、または年次の信用／デビット限度額に制限される冷蔵庫は、取引要求の送信時に、残りの信用／デビット限度額を、電子レンジのデバイスプロファイルに基づいて、十分な信用／デビット限度額の額を維持するＤ_ＰＡＮでプロビジョニングされた電子レンジの値と組み合わせることができる。さらに、一般家庭のアプライアンスは、ドメイン制限が重複する他のデバイスで利用可能なオファー（例えば、割引）を使用する許可を求める場合がある。

【実施例2】

【0100】

［スマートカー］
本明細書に記載される本発明の非限定的な実施形態を組み込んだレンタカーの実施において、１台以上の車両は、他のアプライアンス（例えば、料金所、ガソリンスタンド、その他の自動車、またはその他の類似のシステムもしくはサービスプロバイダ）と取引を行い、かつ／または車両をレンタル／リースする個人と取引を行うことができる。

【0101】

このような例では、レンタカー車両部隊の各車両は、対応するトークン（Ｄ_{Ｔｏｋｅｎ}）と、トークンボルト内の部隊の所有者ＰＡＮ（Ｍ_ＰＡＮ）へのマッピングとを備える、それに発行された金融口座（Ｄ_ＰＡＮ）を有してもよい。各車両は、上記のように、Ｍ_ＰＡＮから資金を控除する承認ではなく、トークンボルトのマッピングに基づいて、借り手からの直接の支払いを受け入れることができ、資金はユーザ／レンタルアカウントから（Ｕ_ＰＡＮまたはＵ_{Ｔｏｋｅｎ}に基づいて）Ｄ_ＰＡＮを通じてアプライアンスが受け取ることになり、Ｍ_ＰＡＮに関連付けられたアカウントに入金される。さらに、上記のプロセスと同様に、Ｄ_{Ｔｏｋｅｎ}にプロビジョニングされた車両は、燃料、通行料、メンテナンス、保険などの要件に対して支払いを行うことができる。ドメイン制限は、特定の加盟店でおよび／または特定の加盟店カテゴリに対する購入のために、自動車支払モジュールで適用できる。レンタカー部隊の車両は、必要に応じて、上記のとおり、信用／デビット限度額の借入れ／集計を可能にするために、さらに互いに接続することができる。

【0102】

このようなシステムは、上記のように、Ｄ_ＰＡＮに関連付けられた燃料リワードポイントなど、特定のロイヤルティポイントまたはリワードポイントとして、借り手にも利益をもたらすことができ、燃料のより良いオファーをもたらすことができる。さらに、借り手が国外に居住している場合、車両は現地通貨で支払うことができ、そのため借り手は、単一のユーザアカウント識別子で複数の外貨取引（通貨換算手数料を含む）を回避することができる。

【0103】

前述のように、すべてのアプライアンスと同様に、車両には、車両の種類、製造業者、取引履歴、レンタル場所、および／または部隊を所有／運営する事業体／機関の関連付けられた信用スコアに基づいて、信用／デビット限度額が割り当てられてもよい。初期信用／デビット限度額は、自動車製造業者と銀行／支払ネットワークとの関係によって定義できる。例えば、自動車会社Ａは銀行Ａおよび取引サービスプロバイダＡとリンクして、自動車会社Ａが製造するすべてのＳＵＶに対して限度額は１０００米ドルを有するＤ_ＰＡＮのあるクレジットカード／デビットカードをプロビジョニングすることができるが、これらに限定されない。

【0104】

本発明は、現在最も実用的で好ましい実施形態とみなされるものに基づいて、例示目的のため詳細に説明されているものの、そのような詳細はその目的に限られ、本発明は、開示される実施形態に限定されないが、それに対して、添付された特許請求の範囲の精神および範囲内にある、修正ならびに同等の構成をカバーすることを意図することは理解されるものとする。例えば、本発明が、可能な限り任意の実施形態の一つ以上の特徴を、任意の他の実施形態の一つ以上の特徴と組み合わせることができると企図することは理解されるものとする。

【産業上の利用可能性】

【0105】

本発明にかかるアプライアンスへのトークンの承認およびプロビジョニングのためのシステムおよび方法により、アプライアンスの所有者に発行された金融商品に依拠することなく、アプライアンスからの商取引を行うことが可能になる。そして、当該システムおよび方法により、複数のアプライアンスや多数の加盟店またはアクワイアラに潜在的に所有者の財務情報を公開することなく、商取引を行うことができる。従って、本発明は、スマートフォン、スマートホーム及びスマートカー等のスマートアプライアンスにおける商取引などに適用できる。

【符号の説明】

【0106】

１０１ ネットワーク
１０２ アプライアンス
１０３ ユーザデバイス
１０４ デバイスの個人アカウント番号（Ｄ_ＰＡＮ）
１０５ メモリ
１０６ デバイストークン（Ｄ_{Ｔｏｋｅｎ}）
１０８ 加盟店システム
１１０ 取引処理システム
１１２ アクワイアラシステム
１１４、１１６ 発行者システム
１１８ トークンボルト
４０２、４０４、４０６、４０８、４１０、４１２、４１４ 処理ステップ
５０２、５０４、５０６、５０８ 処理ステップ
１０００ トークンをアプライアンスにプロビジョニングするシステム
２０００ デバイストークン（Ｄ_{Ｔｏｋｅｎ}）を使用して取引を処理するシステム
４０００ アプライアンスへのトークンの承認およびプロビジョニングのための方法
５０００ 取引を処理するためのアプライアンスを承認する方法
ｓ１、ｓ２ａ、ｓ２ｂ、ｓ３～ｓ１４ 処理ステップ

【図1】

【図2】

【図3】

【図4】

【図5】