JP6031524B2 - 安全に補充可能な電子ウォレット - Google Patents

Description

本開示は、１つには、安全に補充可能な電子ウォレットを提供するための技術およびシステムを提供することを対象とする。

人々は、お金（例えば、現金、銀行のカード等）および他の個人情報（例えば、運転免許証、保険のカード等）を、しばしば財布やハンドバックの中に保管する。人々はまた、要求されると検索が可能な種々のデジタル化された情報を保存する能力のある携帯電話をしばしば持ち運ぶ。従来財布やハンドバッグの中に保管されるいくつかのアイテムは、携帯電話によってデジタル化され、保管され、および管理されることができる。例えば、携帯電話は、支払い情報を保管することにより、ユーザからの要求があり次第、支払い要求を果たすために第三者に提供することができる、電子ウォレットとして機能することができる。しかしながら、財布またはハンドバッグのように、携帯電話は紛失または盗難されやすく、特に電子ウォレットに多額のお金が入っているときにこれはユーザの電子ウォレットを悪用にさらす場合がある。

電子ウォレットの悪用を防ぐため、支払いシステムは、パスワード保護、生体認可、暗号化、または他の種類のセキュリティ等のセキュリティをしばしば採用する。例えば、ユーザは、電子ウォレットからの支払い請求を送信する前に、ユーザ名およびパスワードを入力しなければならないことがある。他の例では、ユーザは、支払い請求を送信する前に、生体認可処理を経なければならないことがある。これらの安全対策は、支払いの処理を遅らせる場合があり、および混雑した小売店の清算処理中等のいくつかの場合において、使用することがユーザにとって厄介であり得る。さらに、安全対策が危険にさらされ、これは電子ウォレットから使用可能な支払いアカウントの悪用を許す場合がある。

詳細な説明が、添付の図面を参照して記載される。図面において、参照番号の左端の桁（複数可）は、その参照番号が初めて出現する図を識別する。異なる図中の同様の参照番号は、類似または同一の項目を示す。
安全に補充可能な電子ウォレットを提供するための実例的なコンピューティング環境の概略図である。 支払いアカウントのホストとなり、モバイル電子デバイスを経由して、支払いアカウントの中の資金への制限付きアクセスを提供する、実例的なサーバのブロック図である。 支払いアカウントの中の資金の一部分に関連付けられた信用情報を受け取るための、および資金の一部分を用いて決済を行うための信用情報を支払い先に送信するための、実例的なモバイル電子デバイスのブロック図である。 電子マネーおよび／または信用情報をモバイル電子デバイス上に読み出し、および次にモバイル電子デバイス上に格納された電子マネーおよび／または信用情報を管理するための、実用的過程のフロー図である。 信用情報を電子モバイルデバイスに送信し、および資金を送金するための有効な要求の照合ができ次第、支払いアカウント間の資金を送金するための、実用的過程のフロー図である。 電子ウォレットに電子マネーをロードするための実用的過程のフロー図である。 電子モバイルデバイスから可能な、電子マネーを使用した決済を行うための実用的過程のフロー図である。 共有の電子マネーおよび／または共有のアカウントを使用した支払いを促進するための実用的過程のフロー図である。 受領者からの請求書を提示する支払いアプリケーションを示すモバイル電子デバイスの実例的なユーザインターフェース（ＵＩ）である。

本開示は、１つには、安全に補充可能な電子ウォレットを提供するための技術およびシステムを提供することを対象とする。種々の実施形態によれば、ホストは、ユーザのための支払いアカウントを保持することができる。ユーザは、安全なチャネルを経由してホストに指示し、ユーザのモバイル電子デバイス（例えば、携帯電話、スマートフォン、電子フォブ等）に支払い情報を送信させることができる。支払い情報は、信用情報、認可キー（複数可）、署名、金額（配分）、および／または他の種類の支払い情報を含むことができる。支払い情報は、使い果たされるかまたは期限切れになると、モバイル電子デバイスを使用したさらなる支払いを阻止する所定の額または電子マネーの配分に限定されてもよい。ユーザは、安全なチャネルを経由してホストに再接続することにより、モバイル電子デバイスを補充することができる。いくつかの実施形態において、ユーザは、ホストからの支払い情報の再発生配分を設定することができる。例えば、ホストは、毎週＄１００をモバイル電子デバイスに提供してもよい。モバイル電子デバイスの紛失または盗難があった場合には、ユーザは支払い情報の将来の配分をキャンセルすることができ、それによりユーザによる潜在的なお金の紛失を最小限にすることができる。

いくつかの実施形態において、ユーザは、支払い情報のうちの少なくとも１つを使用して支払い請求を認証することにより、モバイル電子デバイスを使用して支払いをすることができる。例えば、モバイル電子デバイスは、売主、商店主、または受領者から請求書を受け取ることができる。ユーザは、請求書を閲覧し、次に支払い請求を使用して支払いを認証することができる。モバイル電子デバイスは次に、支払い請求を送信することができ、これは暗号化されてもよく、認可キー、署名、デバイス識別子（ＩＤ）、および／または売主への他のデータを含んでもよい。売主は次に、売主認可キー、署名、売主ＩＤ、および／または他のデータ等の追加データを支払い請求に添付することができる。売主は次に、支払い請求をホストに送信することができる。ホストは、要求を暗号化し、支払い請求の妥当性および／または信頼性を照合することができる。支払い請求が有効であり（例えば、キーおよび／または署名が正しい）、および必要な資金が利用可能である（例えば、現在の配分を超えていない）場合、次にホストは、ユーザから売主に資金を移し、モバイル電子デバイスの配分についての残りの残高を更新することができる。

配分をモバイル電子デバイスに提供することにより、モバイル電子デバイスがユーザのアカウントの中の利用可能なすべての資金のうちの一部分に制限され得る、配分された資金へのアクセスのみを有するため、ユーザは、ユーザのアカウントの中の利用可能なすべての資金の起こり得る盗難および悪用にさらされない。モバイル電子デバイスは、紛失のこの制限されたリスクのために、支払い過程を単純化させることができる。例えば、モバイル電子デバイスは、いったん支払いがモバイル電子デバイスによって受け取られ、格納されると、決済を行うのに先立って、ユーザからのパスワード、生体認可、または他のセキュリティ入力を要求しなくてもよい。

本願に記載の技術およびシステムは、数々の方途によって実装されることができる。以下の図面を参照して実装の例を提供する。

図１は、安全に補充可能な電子ウォレットを提供するための実例的なコンピューティング環境１００の概略図である。環境１００は、支払いアカウントを管理し、支払いアカウントを使用した取引を促進するサーバ１０４を含むホスト１０２を含む。ユーザ１０６は、支払いアカウントに資金を追加したり、資金を引き出したり、決済をしたり、預け入れをしたり、または別様に支払いアカウントとやりとりする等、支払いアカウントを管理するために、ホスト１０２と通信することができる。

いくつかの実施形態において、ユーザ１０６は、１つ以上のネットワーク（複数可）１１０を経由して、サーバ１０４と通信するために、モバイル電子デバイス１０８（「デバイス」）を使用することができる。デバイス１０８は、携帯電話、スマートフォン、タブレットコンピュータ、ラップトップコンピュータ、ネットブック、携帯情報端末（ＰＤＡ）、ゲームデバイス、メディアプレイヤー、電子フォブ、またはネットワーク（複数可）１１０への接続性を含むあらゆる他の電子デバイスであってもよい。ネットワーク（複数可）１１０は、環境１００において種々の団体間での通信を可能にする、有線および／または無線ネットワークを含むことができる。いくつかの実施形態において、ネットワーク（複数可）１１０は、サーバ１０４、デバイス１０８、および商店主１１２の間の通信を促進するために、おそらく互いに連結して使用される、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、携帯電話 ネットワーク（ＭＴＮ）、および他の種類のネットワークを含むことができる。

１つ以上の実施形態において、ユーザ１０６は、ホスト１０２が支払い情報１１６をデバイス１０８に提供することを要求するために、サーバ１０４に補充要求１１４を送信することができる。支払い情報１１６は、ユーザ１０４に関連付けられた支払いアカウントの中の利用可能な資金の一部分の配分と関連付けられることができる。支払い情報１１６は電子マネーであることができ、信用情報、認可キー（複数可）、署名、金額（配分）、および／または他の種類の支払い情報を含む。認可キー（複数可）は、支払い情報の暗号化／暗号解読を可能にするために、公開キー／秘密キーを含むことができる。サーバ１０４は、支払い情報１１６をデバイス１０８に送信することができる。例えば、サーバ１０４は、＄１００の価値のある電子マネーを、関連付けられた電子マネーと共に使用するための認証キーまたは署名と共にデバイス１０８に送信することができる。認証キーまたは署名は、それぞれの配分について新しくされてもよく、よって特定の電子マネーの配分に対応する。ゆえに、いったん資金の配分が使い果たされる（使用済み）かまたは期限切れになると、次に認証キー（複数可）および／または署名は、終了となるかまたは期限切れとなってもよい。デバイス１０８による受け取り後、ユーザ１０６は、商店主１１２等の商店主に対し、商品および／またはサービスの代金を払うために、電子マネーの決済をすることができる。ユーザはまた、電子マネーを使用して、友人、家族、または他の人々または団体等の相手方に対して決済することができる。簡単にするために、本願ではユーザ１０６が「支払人」または「支払い提供者」の同意語である一方で、「商店主１１２」という用語を「支払い先」、「受領者」、「売主」、または「支払い受領者」との同意語として使用する。しかしながら、ユーザ１０６はまた、本願に記載の技術に従い、支払い先として資金を受け取ることができる。

電子マネーは、支払いアカウントの中に格納されている、実際の資金のうちの少なくとも一部分と関連付けられることができ、ゆえに、支出があると、支払い先がホスト１０２を経由してユーザの支払いアカウントから資金を集金することを可能にする。ゆえに、電子マネーは、電子的形態で移され、およびユーザの支払いアカウントの中のお金の額よりも少ないであろう資金の配分された分配に関連付けられていることを除き、小切手等の商業手形と似た動作をすることができる。電子資金もまた、暗号化され、特定のデバイス識別子（ＩＤ）または他の識別情報に関連付けられることができる。

ユーザ１０６は、電子マネーを商店主１１２等の団体に送信することができる。いくつかの例では、商店主１１２は、ユーザ１０６が商店主を特定の所在地に訪問することを可能にする、現実世界の所在地を有し得る。しかしながら、商店主１１２はまた、または代替的に、ネットワーク（複数可）１１０を経由してユーザ１０６にアクセス可能な電子マーケットを有することもできる。例えば、この電子マーケットは、ユーザ１０６が商品および／またはサービスを購入することを可能にするウェブサイトであることができ、または商品が発売、貸出、リースされたこと、または商店主１１２から別様に利用可能になったことをユーザが閲覧することを可能にするカタログに基づくサービスであることもできる。

商店主１１２とユーザ１０６との間における支払い取引の間、商店主は請求書１１８をデバイス１０８に送信することができる。デバイス１０８は、近距離無線通信（ＮＦＣ）または他の通信パス（例えば、インターネット、Ｗｉ−Ｆｉ、携帯電話ネットワーク等）を経由して、請求書１１８を受け取ることができる。デバイス１０８は、電子マネーを管理する支払いアプリケーションを用いて請求書１１８の処理を行うことができる。請求書１１８は、商店主１１８（または他の団体）に対して支払うべき金額、商店主１１８の識別子、および／または他の適用可能な支払い情報を含むことができる。

ユーザ１０６は、請求書１１８を検査することができ、次にそれに応じて応答することができる。例えば、ユーザ１０６は、要求を拒否すること、要求をそのまま受諾すること、または修正を伴って要求を受諾することを判定することができる。ユーザ１０６が請求書１１８を受諾した後、デバイス１０８は、ユーザが署名した請求書１２０を商店主１１２に送信することができる。ユーザが署名した請求書１２０は、電子マネーの額、デバイス１０８および／またはユーザ１０６の識別子、認可キー、署名、および／または他の支払い情報を含むことができる。ユーザが署名した請求書１２０は、デバイス１０８によって暗号化されることができ、商店主１１２によって閲読されない。

ユーザが署名した請求書１２０の受け取り後、商店主１１２は、追加情報を追加して商店主が署名した請求書１２２を作成することができる。追加情報は、商店主ＩＤ、商店主認可キー、署名、および／または他の情報を含むことができる。商店主が署名した請求書１２２は、商店主１１２によって暗号化されることができる。商店主１１２は次に、ユーザの支払いアカウントの中の資金からのホストからの支払いを要求するために、商店主が署名した請求書１２２をホスト１０２のサーバ１０４に送信することができる。いくつかの実施形態において、デバイス１０８は、ユーザが署名した請求書１２０をホスト１０２に直接送信することができる。この状況では、ユーザが署名した請求書１２０は、商店主１１２の識別子を含むことができ、商店主が署名した請求書１２２の代わりになることができる。ゆえに、いくつかの例では、商店主１１２は、データをホスト１０２に送達する必要がない場合がある。

商店主が署名した請求書１２２を受け取り次第、ホストは、あらゆる必要な暗号解読を行うことができ、次に商店主が署名した請求書１２２の信頼性および電子マネーの利用可能性を照合することができる。例えば、ホスト１０２は、デバイス１０８への電子マネーの配分のために指定されたユーザの支払いアカウントが、支払い請求を満たすために十分な資金を有しているかどうかを判定することができる（商店主が署名した請求書１２２を経由して）。ホスト１０２が、商店主が署名した請求書１２２が本物（例えば、適正な暗号解読、適正なキー／署名等）であり、資金が利用可能であると判定すると、サーバ１０４は、商店主１１２へのメッセージ１２４を送信することができる。メッセージ１２４は、支払い金額および商店主への実際の支払いの発生を確定することができる。商店主への支払いは、ユーザ１０６の支払いアカウントと商店主１１２との間で資金を送金することにより行われてもよく、または、他の過程（電信送金等）を経由した商店主への支払いを含むことができる。しかしながら、配分が使い果たされたか、期限が切れたか、または商店主が署名した請求書１２２において示されている額を配分の残高が下回ったため、ユーザの支払いアカウントが十分な資金を有しない場合、次に支払い請求（すなわち、商店主が署名した請求書１２２）は、メッセージ１２４を経由して拒否されるか、または拒絶されることができる。いくつかの実施形態において、サーバ１０４は、支払いが完了したか、または認められなかったことをユーザに通知するために、デバイス１０６へのメッセージを送信することができる。

ユーザ１０６は、ユーザが請求書を承認するか、または別様に電子マネーを使うことを可能にする支払いアプリケーションを管理するためのデバイス１０８によって提示されるユーザインターフェース（ＵＩ）１２６と互いにやりとりすることができる。ＵＩ１２６はまた、ユーザが電子マネーを受け取り、および商店主１１２によって生成された請求書１１８に類似した請求書を生成することを可能にすることができる。いくつかの実施形態において、ＵＩは、ユーザ１０６が安全なチャネルを経由して電子マネーの配分をデバイス１０８上に補充することを可能にすることができる。しかしながら、補充（補充要求１１４を経由）は、パスワード、生体認可、および／または他の安全対策の使用を必要とする場合がある。例えば、補充は、周知のインターネットプロトコル（ＩＰ）アドレスまたは他の周知の通信属性に限定されてもよい。いくつかの実施形態において、補充は、デバイス１０８の他に、別のデバイス（例えば、家庭用コンピュータ、現金自動預入支払機（ＡＴＭ）等）による使用に限定されることができ、これにより、ユーザ（または別の人物）が他方のデバイスにアクセスすることなくデバイス１０８に電子資金を補充することを防ぐ。支払いアプリケーションは、図３を参照してより詳細に検討される。

図２は、支払いアカウントのホストとなり、デバイス１０８を経由して支払いアカウントの中の資金への制限付きアクセスを提供する、実例的なサーバ１０４のブロック図である。サーバ１０４は、プロセッサ（複数可）２０２およびメモリ２０４を含むことができる。メモリ２０４は、種々のモジュール、アプリケーション、プログラム、または他のデータを格納することができる。メモリ２０４は、プロセッサ（複数可）２０２によって実行されると、本願に記載のホスト１０２のための動作をプロセッサに行わせる命令を含むことができる。いくつかの実施形態において、メモリ２０４は、アカウントマネージャ２０６を格納することができる。アカウントマネージャ２０６は、本願に記載のいくつかのまたはすべての種々の動作を行ういくつものモジュールを含むことができる。種々の実施形態によれば、アカウントマネージャ２０６は、いくつかのまたは以下のすべてのモジュール：価額ロードモジュール２０８、照合モジュール２１０、支払いモジュール２１２、およびメッセージモジュール２１４を含むことができる。加えて、サーバ１０４は、支払いアカウント２１６のためのデータストレージを含むことができる。支払いアカウント２１６は、ユーザ１０６のための支払い情報、電子マネー分配、および他の支払いデータを含むことができる。商店主１１２はまた、サーバ１０４によって格納される１つ以上の支払いアカウント２１６を有することができる。それぞれのモジュールが順に検討される。

１つ以上の実施形態において、価額ロードモジュール２０８は、安全なチャネルを使用して、デバイス１０８を経由してユーザ１０６から補充要求１１４を受け取り、および処理することができる。このロード要求は、ユーザ１０６による、ホスト１０２に電子マネーをデバイス１０８に配分させる要求であることができる。価額ロードモジュール２０８は、この要求を分析して、支払いアカウントがこの要求を処理するために適正な資金を有しているかどうか、および補充要求がユーザの支払いアカウントに関連付けられたあらゆる他の制約および規則に適合するかどうかを照合することができる。金額が利用可能であり、不一致が検知されなければ、価額ロードモジュール２０８は、支払い情報１１６をデバイス１０８に送信することができる。いくつかの実施形態において、ユーザ１０６は、価額ロードモジュール２０８を使用して、再発生配分を確立することができる。例えば、ユーザ１０６は、デバイス１０８に一定金額が特定の日々（例えば、毎日、毎週、毎月、または他の間隔で）に送信されるか、またはロードされることを所望することができる。ユーザ１０６がデバイス１０８を紛失した場合、ユーザは、価額ロードモジュール２０８を経由して配分をキャンセルし、少なくとも一時的に、支払い情報のデバイス１０６への送信を中止することができ、これにより、デバイス１０８の悪用を通じてお金を失う可能性を制限することができる。いくつかの実施形態において、後続の配分は、定められた額の補給に限定されることができる。ゆえに、次の配分時にデバイス１０８上にある電子資金の残高が存在する場合、この配分は、例えば前回の額を配分するのではなく、支出された資金を補給するだけであることができる。いくつかの実施形態において、この配分は、所定の長さの時間後に期限切れとなるように設定されることができる。例えば、配分は、次の配分の直前に期限切れとなることができる。

照合モジュール２１０は、商店主が署名した請求書１２２を暗号解読および分析して商店主が署名した請求書１２２が本物であるかどうか判定することができる。例えば、照合モジュール１２０は、商店主が署名した請求書１２２の中に提供される認可キーおよび／または署名を検査することができる。認可キーおよび／または署名は、商店主からのキー、デバイス１０６からのキー、またはその両方を含むことができる。照合モジュール２１０はまた、要求された金額が支払いアカウントの中で利用可能か、およびすでに支出が行われていないか、使い果たされていないか、または期限が切れていないかを判定することができる。加えて、照合モジュール２１０は、商店主が署名した請求書１２２が不正なものかどうか、または不正な活動の結果（例えば、疑わしい所在地で使用された盗まれたデバイス等）の結果であるかどうかを判定するために、要求に応じて不正分析を行うことができる。

支払いモジュール２１２は、支払いが照合モジュール２１０によって承認されると、商店主が署名した請求書１２２に従って支払いを行うことができる。いくつかの実施形態において、支払いモジュール２１２は、ユーザの支払いアカウントから商店主１１２に関連付けられた支払いアカウントに資金を送金することができる。種々の実施形態において、支払いモジュール２１２は、支払いを商店主１１２に送信するために、送金される電子資金を商店主の金融機関に提供し得る。

メッセージモジュール２１４は、メッセージをデバイス１０８および／または商店主１１２に送信することができる。いくつかの実施形態において、メッセージモジュール２１４は、支払いが承認されたかまたは拒否されたかを示す情報を送信することができる。メッセージモジュール１２４はまた、商店主１１２がデバイス１０８による暗号化のためにユーザが署名した請求書１２０からの額を閲覧することができない場合があるため、支払いの額を確定することができる。メッセージモジュール２１４は、電子マネーの残額を、定期的に、ランダムに、および／またはイベントをトリガした後に、デバイス１０６に送信することができる。例えば、電子マネーの残額が、異なるデバイス（すなわち、共有の配分）を有する複数の当事者による使用が可能であるとき、メッセージモジュール２１４は、配分された資金のうちのいくらかが使用された後、それぞれの使用に対してメッセージを送信することができる。

図３は、支払いアカウントの中の資金の一部分に関連付けられた支払い情報を受け取ることができ、および支払い請求（例えば、ユーザが署名した請求書１２０）を支払い先（例えば、商店主１１２）に送信して、資金の一部分に関連付けられた電子マネーを用いて決済を行うための、デバイス１０８のブロック図である。デバイス１０８は、プロセッサ（複数可）３０２およびメモリ３０４を含むことができる。メモリ３０４は、種々のモジュール、アプリケーション、プログラム、または他のデータを格納することができる。メモリ３０４は、プロセッサ（複数可）３０２によって実行されると、本願に記載のデバイス１０８のための動作をプロセッサに行わせる命令を含むことができる。いくつかの実施形態において、メモリ３０４は、支払いアプリケーション３０６を格納することができる。支払いアプリケーション３０６は、本願に記載のいくつかのまたはすべての種々の動作を行う、いくつものモジュールを含むことができる。種々の実施形態によれば、支払いマネージャ３０６は、いくつかのまたは以下のすべてのモジュール：承認モジュール３０８、信用情報モジュール３１０、および価額追跡器３１２を含むことができる。それぞれのモジュールが順に検討される。

種々の実施形態において、承認モジュール３０８は、ユーザが商店主１１２または他の支払い先に対する支払いを行うことを可能にすることができる。承認モジュール３０８は、請求書１１８を受け取り、および請求書からの情報をユーザ１０６に提示することができる。承認モジュール３０８は次に、ユーザ１０６がデバイス１０８を経由して、支払うべき金額を受諾し、ゆえに電子マネーを用いて決済することができるようにする。いくつかの実施形態において、承認モジュール３０８は、ユーザ１０６が支払い金額を修正する、支払い金額を入力する、電子マネーの配分の残高を閲覧する、またはそれらの組み合わせをすることを可能にすることができる。種々の実施形態において、承認モジュール３０８は、最初に請求書（例えば、請求書１１８）を受け取らずに支払いを開始することができる。

信用情報モジュール３１０は、支払い（すなわち、ユーザが署名した請求書１２０）と共に、認証キー（複数可）、署名、デバイスＩＤ、および／または他の情報を格納および送信することができる。例えば、支払い情報１１６は、少なくとも部分的に、信用情報モジュール３１０によって格納されることができる。信用情報モジュール３１０は次に、認証キー（複数可）および／または署名を用いて支払いを暗号化することができ、また、ユーザが署名した請求書１２０を作成するためのデバイスＩＤを含むことができる。

価額追跡器３１２は、所与の配分について電子デバイス上で利用可能である、利用可能な額の電子マネーを追跡することができる。いくつかの実施形態において、価額追跡器はまた、複数のユーザが各々のデバイスを使用して電子マネーの配分を共有する場合等の共有のアカウントの残高を追跡することができる。

実例的な動作
図４は、資金および／または信用情報をデバイス１０８上にロードし、次にデバイス上に格納された資金および／または信用情報を管理するための実用的過程４００のフロー図である。過程４００は、論理流れグラフにおけるブロックの一群として図示され、これはハードウエア、ソフトウエア、またはそれらの組み合わせにおいて実施されることができる一連の動作を表す。ソフトウエアの文脈では、ブロックは、１つ以上のコンピュータ可読のストレージ媒体上に格納されるコンピュータによる実行が可能な、１つ以上のプロセッサによって実行されると、列挙された動作を行う命令を表す。概して、コンピュータによる実行が可能な命令は、特定の機能を行うか、または特定の抽象データ型を実施する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造および同等物を含む。動作が説明される順番は制限として解釈されることを意図しておらず、説明されるあらゆる数のブロックは、あらゆる順番でおよび／または平行して組み合わされて過程を実施することができる。過程４００に加えて、本開示の全体にわたって説明された他の過程は、それに応じて解釈されるべきである。

過程４００は、環境１００を参照して説明され、デバイス１０８によって行われることができる。当然、過程４００は、他の類似のおよび／または異なる環境において行われることができる。

４０２で、デバイス１０８の支払いアプリケーション３０６は、サーバ１０４によって実行される支払い情報を価額ロードモジュール２０８から受け取ることができる。例えば、信用情報モジュール３１０は、支払い金額の配分に関連付けられた認可キー（複数可）および／または署名を受け取ることができる。価額追跡器３１２は、電子マネーの配分の価額を受け取ることができる。いくつかの実施形態において、支払いアプリケーションは、電子マネーにアクセスするために、支払い情報を暗号解読することができる。

４０４で、ユーザ１０６が取引を開始した後、承認モジュール３０８は、支払いを要求する商店主１１２または他の団体から請求書１１８を受け取ることができる。承認モジュール３０８は、要求される金額（すなわち、支払い金額）、要求側当事者（例えば、商店主１１２等）の身元、および／または他の適用可能な情報（例えば、要求の時間、取引の説明等）を判定することができる。

４０６で、支払いアプリケーション３０６は、動作４０４での請求書の受け取りに応じて、商店主１１２またはホスト１０２にユーザが署名した請求書１２０を送信することができる。例えば、承認モジュール３０８は、請求書を承認することができる。いくつかの実施形態において、信用情報モジュール２１０は次に、電子マネーの支払うべき金額と共に認可キー（複数可）、署名、および／または他の情報（例えば、デバイスＩＤ等）を、データを最終的にホスト１０２に送信する商店主１１２に送信することができる。種々の実施形態において、信用情報モジュール２１０は、電子マネーの支払うべき金額と共に、認可キー（複数可）、署名、商店主ＩＤおよび／または他の情報（例えば、デバイスＩＤ等）をホスト１０２に送信することができる。後に、ホスト１０２は、商店主と通信して、支払いを完了するか、または支払いを拒否することができる。ユーザが署名した請求書１２０は、信用情報モジュール２１０によって暗号化されることができる。電子マネーは、金額指定または電子的に追跡される実際の通貨であることができる。ゆえに、電子マネーは、ユーザの支払いアカウントの中の実際の資金の代理であってもよく、または実際の資金であってもよく、ゆえにユーザの支払いアカウントの中の実際の資金の代理でなくてもよい。

４０８で、価額追跡器３１２は、取引が処理されると、配分における電子資金の利用可能な残高を更新することができる。しかしながら、上述したように、もしも取引がさまざまの理由によって拒絶された場合、すると価額追跡器３１２は、利用可能な額を更新しないことができる。

４１０で、支払いアプリケーションは、動作４０２を経由して電子マネーの補充を受け取るかどうか判定することができる。電子マネーが補充されると、過程４００は、動作４０２で継続することができる（動作４１０から「はい」のルートをたどる）。電子マネーが補充されず、別の支払いが処理されると（動作４１０から「いいえ」のルートをたどる）、過程４００は動作４０４で継続することができる。上述のとおり、補充過程はユーザからの要求、時間の経過、または他のトリガによって開始されることができる。

図５は、デバイス１０８に信用情報を送信するための、および資金を送金するための有効な要求の照合があり次第、支払いアカウント間で資金を送金するための実用的過程５００のフロー図である。過程５００は、環境１００を参照して説明され、サーバ（複数可）１０４によって行われることができる。当然、過程５００は、他の類似のおよび／または異なる環境において行われることができる。先と同様に、動作が説明される順番は制限として解釈されることを意図しておらず、説明されるあらゆる数のブロックは、あらゆる順番でおよび／または平行して組み合わされて過程を実施することができる。

５０２で、サーバ１０４上の価額ロードモジュール２０８は、ユーザ１０６から正しい認可情報を受け取ることができる。価額ロードモジュール２０８は次に、デバイス１０８による使用のための、ユーザの支払いアカウントの資金からの電子マネーの分配を認証することができる。

５０４で、価額ロードモジュール２０８は、デバイス１０８に価額および／または信用情報を送信することができる。いくつかの実施形態において、価額ロードモジュール２０８は、支払いアプリケーション３０６を経由したデバイス１０８による使用のための、支払いアカウントの中の資金を指定することができる。資金を使用するために、支払いモジュール２１２は、支払い先（例えば、商店主１１２）に信用情報を送信することができ、これは次に、ユーザの支払いアカウントを経由して、ホスト１０２からの資金の支払いのための信用情報と引き換えられる。支払いアカウントの中の資金は、デバイス１０８による排他的な使用のために明確に保留されるか、または動作５０４に先立って照合されてもよく、これは以下に記載のとおり、デバイス１０８を経由した支出を制限することができる。種々の実施形態において、価額ロードモジュール２０８は、ユーザのアカウントからの資金を電子マネーとしてデバイス１０８に送信することができる。ユーザの支払いアカウントは、資金の額を引き落とされることができ、これは次に電子的に商店主１１２等の他の団体に送信されることができる。

例えば、サーバ１０４は、電子マネーの配分のための固有の識別子（ＩＤ）を生成することができる。サーバ１０４はまた、電子マネーと共に、一対の秘密キーおよび公開キーを作成することができる。デバイス１０８は、配分および電子マネーのために使用される公開キーを受け取ることができ、これはデバイス１０８がサーバ１０４から受け取った公開キーを使用して読み出すことができる。

５０６で、ユーザ１０６が商店主１１２との取引を行った後、サーバ１０４の照合モジュール２１０は、商店主が署名した請求書１２２を、商店主１１２から、またはデバイス１０８から直接受け取ることができる。商店主が署名した請求書１２２は、商店主の身元（または支払い先）、ユーザおよび／またはデバイス１０８、および支払い金額を含むことができる。

５０８で、照合モジュール２１０は、商店主が署名した請求書が有効である、認証されている、および／またはその金額がユーザの支払いアカウントの中において利用可能であるかどうかを判定することができる。商店主が署名した請求書は、信用情報、認証キー（複数可）署名、または他の安全対策が有効である場合に有効となることができる。加えて、照合モジュール２１０は、支払いが不正を被っているかどうか判定するために、商店主が署名した請求書について不正分析を行うことができる。例えば、ユーザ１０６は、デバイス１０８の紛失を報告することができ、これはデバイス１０８からの支払いを停止することができる。いくつかの実施形態において、支払いが共有の支払いアカウントからである場合（図８を参照して下記に記載される）か、または支払いが認証しているユーザ（例えば、両親等）を含む場合等に、この支払いは、別のユーザによる承認を条件としてもよい。支払い金額は、デバイス１０８による排他的な使用のために資金が保留されている場合、支払いアカウントから利用可能であってもよい。しかしながら、資金が明確に保留されていない場合、次に照合モジュール２１０は、ユーザの支払いアカウントが、商店主が署名した請求書１２２において示される支払いを満たすために適正な資金を有しているかどうか判定しなければならなくなることがある。

５１０で、照合モジュール２１０は、商店主が署名した請求書１２２が有効であり、動作５０８で判定したように資金が利用可能であるかどうか判定する。商店主が署名した請求書１２２が有効であり、資金が利用可能である場合（「はい」のルートを経由して）、次に過程５００は動作５１２に進むことができる。

５１２で、支払いモジュール２１２は、ユーザの支払いアカウントから商店主の支払いアカウントに資金を送金することができる。いくつかの例では、資金の送金は、商店主の金融機関を経由して、商店主１１２に電子決済を送金することを含むことができる。

５１４で、メッセージモジュール２１４は、商店主１１２および場合によりデバイス１０８に支払いの通知を送信することができる。いくつかの実施形態において、この通知はまた、デバイス１０８と電子マネーを共有する他のデバイスに送信されることができる。例えば、各々のデバイスを経由して支出を行うことができる電子マネーをあるグループの人々が共有することができる。このグループの中の１人が電子マネーの決済をすると、次に通知が他の構成員に支払いを通知し、このグループの構成員に示される利用可能な残高を更新することができる。

商店主が署名した請求書１２２が有効でなく、および／またはユーザの支払いアカウントの中の資金が利用可能でない場合（判定動作５１０から「いいえ」のルートを経由）、次に支払いモジュール２１２は、商店主１１２および／またはデバイス１０８に５１６での拒否および場合によっては拒否の理由（例えば、資金不足等）を示すメッセージを送信することができる。

図６および７は、電子ウォレットに電子マネーをロードし、およびデバイスを経由して利用可能な電子マネーを使用して決済をするための処理を示す。一連のブロックは、ブロック内に記載の種々の動作を行うことができる各々の団体の下に組織される。しかしながら、他の団体は、これらの過程におけるいくつかの動作を行うことができる。加えて、動作が説明される順番は制限として解釈されることを意図しておらず、説明されるあらゆる数のブロックは、あらゆる順番でおよび／または平行して組み合わされて過程を実施することができる。

図６は、支払いアプリケーション３０６に電子マネーをロードするための実用的過程６００のフロー図である。

６０２で、ユーザ１０６は、デバイス１０８かまたは別のコンピューティングデバイスを使用してサーバ１０４に信用情報および要求された価額を送信することができる。例えば、ユーザ１０６は、ユーザ名、パスワード、生体認可、および／または他のセキュリティ信用情報を送信してユーザの支払いアカウントにアクセスすることができる。ユーザ１０６は次に、デバイス１０８上にロードする電子マネーの金額を選択することができる。いくつかの実施形態において、ユーザはまた、有効時間／期日、しばらく経ってからの自動補充等の電子マネーの他の属性を選択することができる。

６０４で、価額ロードモジュール２０８は、信用情報および要求された価額を受け取ることができる。照合モジュール２１０は、６０６で信用情報を照合することができる。照合モジュール２１０はまた、他のセキュリティ分析を行うことができる。例えば、照合モジュール２１０は、動作６０２からの要求のために使用されたＩＰアドレスがユーザ１０６に関連付けられた既知のＩＰアドレスであるかどうかを判定することができる。いくつかの実施形態において、照合モジュール２１０はまた、認可信用情報（例えば、ホワイト／ブラックリスト等）および／または認証信用情報（例えば、他のユーザからの許可／認証等）を使用して、要求が有効であるか、および／または承認されたかどうか判定することができる。

６０８で、照合モジュール２１０は、信用情報が正しいかどうかを判定することができる。信用情報が正しくない場合（判定動作６０８から「いいえ」のルートをたどる）、次にメッセージモジュール２１４は、６１０でユーザに拒否を送信することができ、これは、デバイス１０８またはコンピューティングデバイスを経由して６１２でユーザによって受け取られることができる。

６１４で、信用情報が正しい場合（判定動作６０８から「はい」のルートをたどる）、次に照合モジュール２１０は、要求された金額がユーザの支払いアカウントの中で利用可能であるかどうかを判定することができる。いくつかの実施形態において、この金額は、関連付けられるアカウントの信用限度に関連することができる。要求された金額が利用可能でない場合（判定動作６１４から「いいえ」のルートをたどる）、上述のとおり、次に動作６１０および６１２が行われることができる。

６１６で、要求された金額が利用可能である場合（判定動作６１４から「はい」のルートをたどる）、価額ロードモジュール２０８は、要求された金額に関連付けられた認証キー（複数可）および／または署名を生成することができる。いくつかの実施形態において、認証キー（複数可）または署名は、電子マネーであることができる。しかしながら、認証キー（複数可）または署名は、商店主が署名した請求書に正確に含まれると、ユーザの支払いアカウントから商店主１１２または他の支払い先の支払いアカウントへの資金の分配を認証する、信用情報であってもよい。

６１８で、価額ロードモジュール２０８は、認証キー（複数可）および／または署名をデバイス１０８に送信することができ、これは、６２０でデバイス１０８によって受け取られることができる。例えば、動作６２０での認証キー（複数可）の受け取りは、ネットワーク（複数可）１１０を経由する等のデバイス１０８によって受け取られることができる一方で、ユーザ１０６は、パソコンを使用して動作６０２で要求を行ってもよい。

図７は、デバイス１０８を経由して利用可能な電子マネーを使用した決済のための実用的過程７００のフロー図である。

７０２で、商店主１１２は、デバイス１０８に請求書１１８を送信することができる。請求書１１８は、未払額、取引情報、参照番号、商店主の説明、取引に関与する商品／サービスの説明、および／または他の情報を含むことができる。７０４で、デバイス１０８は、請求書１１８を受け取ることができる。

７０６で、ユーザ１０６は、要求された支払いを受諾することにより、またはデバイス１０８を経由して承認モジュール３０８を使用して支払いのために別の金額を指定することにより、請求書を完成することができる。デバイス１０８は、請求書に認証キー（複数可）、署名、デバイス情報、ユーザ情報、および／または他のデータを追加してユーザが署名した請求書１２０を作成することができる。いくつかの実施形態において、認証キー（複数可）は、ユーザが署名した請求書１２０を暗号化するために使用されることができる。７０８で、デバイス１０８は、無線自動識別（ＲＦＩＤ）近距離無線通信（ＮＦＣ）または他の単距離通信技術を経由したネットワーク（複数可）１１０を使用して、商店主にユーザが署名した請求書１２０を送信することができる。デバイス１０８はまた、離れた所在地から商店主からの購買を完了したとき等に、インターネット等の他の種類のネットワークを経由してユーザが署名した請求書１２０を送信することができる。いくつかの実施形態において、デバイス１０８はまた、商店主に送信される電子マネーの部分を識別するメッセージをホストに送信することができる。これは、商店主に対する電子マネーの部分の支払いの信頼性を照合することができ、および／またはユーザ１０６と商店主１１２の間における取引の受領書としての役割をすることができる。商店主１１２は、７１０で、ユーザが署名した請求書１２０を受け取ることができる。

７１２で、商店主１１２は、ユーザが署名した請求書１２０に商店主情報、追加の認証キー（複数可）、別の署名、および／または他のデータを追加して、商店主が署名した請求書１２２を作成することができる。種々の実施形態において、追加の認証キー（複数可）は、商店主が署名した請求書１２２を暗号化するために使用されることができる。いくつかの例では、動作７０６で、暗号化により、商店主１１２が、デバイス１０８によって承認された金額を照合することができないかもしれない。しかしながら、商店主は、下記に記載されるように、ホスト１０２によって取引額を通知されることができる。７１４で、商店主は、商店主が署名した請求書１２２をホスト１０２のサーバ１０４に送信することができ、これは７１６でサーバによって受け取られることができる。

いくつかの実施形態において、動作７０８は、請求書をサーバ１０４に直接送信することができ、ゆえに７１０〜７１４の動作を促進することができる。請求書は、商店主識別子を含むことができる。しかしながら、これは取引時にデバイス１０８がサーバ１０４と通信可能であることを必要とする場合があり、これは常に可能ではない（例えば、移動範囲外の携帯電話等）。

７１８で、照合モジュール２１０は、動作５０８および５１０において記載されたように、認証キー（複数可）（および／または署名）および資金を照合することができる。いくつかの実施形態によれば、照合モジュール２１０は、商店主が署名した請求書１２２を暗号解読して、商店主１１２の情報およびデバイス１０８（またはユーザ１０６）からの情報を判定することができる。７２０で、照合モジュール２１０は、要求が有効であるかどうか、および資金が利用可能かどうかを判定することができる。要求が無効であり、および／または資金が利用可能でない場合（「いいえ」のルートをたどる）次にメッセージモジュール２１４は拒否を送信することができ、これはデバイス１０８によって７２４で、および商店主によって７２６で受け取られることができる。

要求が有効であり、資金が利用可能である場合（判定動作７２０から「はい」のルートをたどる）、支払いモジュール２１２は、商店主１１２への支払いを完了するか、および／または７２８で支払いを反映するためにアカウント情報を更新することができる。７３０で、メッセージモジュール２１４は、７３２でデバイス１０８に、および７３４で商店主に支払いの確定を送信することができる。動作７３２での確定は、デバイス１０８上で利用可能な電子マネーの配分の残高を更新することができる。更新された残高は、配分から支払いおよびあらゆる適用される手数料を引いたものに等しくなり得る。

実例的な共有アカウント
図８は、共有の通貨および／または共有のアカウントを使用した支払いを促進するための実用的過程８００のフロー図である。過程８００は、環境１００を参照して説明され、サーバ（複数可）１０４によって行われることができる。当然、過程８００は、他の類似のおよび／または異なる環境において行われることができる。先と同様に、動作が説明される順番は制限として解釈されることを意図しておらず、説明されるあらゆる数のブロックは、あらゆる順番でおよび／または平行して組み合わされて処理を実施することができる。

８０２で、価額ロードモジュール２０８は、アカウントを共有するか、および／または電子マネーを共有する２つ以上のデバイスに信用情報（例えば、電子マネー等）を送信することができる。

８０４で、決済のためにデバイスのうちの１つが使用された後、次に照合モジュール２１０は、少なくとも受領者（例えば、商店主、売主、支払い先等）デバイス、および金額を識別する請求書を受け取ることができる。

８０６で、照合モジュール２１０は、請求書が有効であるかどうか、および金額が利用可能であるかどうかを判定することができる。８０８で、請求書が有効であり、利用可能である場合（「はい」のルートをたどる）、次にアカウントマネージャ２０６は、支払いが１つ以上の他のユーザ（例えば、他のデバイスのユーザ等）よって認証されているかどうかを８１０で判定することができる。８１０で認証が必要とされた場合（「はい」のルートをたどる）、次にメッセージモジュール２１４は、ユーザ（複数可）に認証のための要求を８１２で送信することができる。この要求は、支払いを遅延させ得るリアルタイムの要求であってもよい。いくつかの例では、支払いは、認証要求が行われている間、保留とされることができる。種々の実施形態において、認証要求は、実際の支払い請求が行われるより前に事前承認を得るために、支払いよりも先に行われることができる。

８１４で、過程は、支払いが認証されるかどうか判定することができる。支払いが認証される場合（判定動作８１４から「はい」のルートをたどる）、または認証が必要とされない場合（判定動作８１０から「いいえ」のルートをたどる）、次に支払いモジュール２１２は、８１６で、支払いアカウントから受領者のアカウントに資金を送金することができる。８１８で、メッセージモジュール２１４は、支払いの通知を送信することができ、これは動作８０２で信用情報を受け取った２つ以上のデバイスについての利用可能な資金の残高を更新することができる。

しかしながら、取引が認証されていない場合（判定動作８１４から「いいえ」のルートをたどる）または請求書が有効でないか、または資金が利用可能でない場合（判定動作８０８から「いいえ」のルートをたどる）、次にメッセージモジュール２１４は、ユーザおよび／または受領者に、８２０で拒否を送信することができる。

実例的な動作
図９は、商店主１１２または他の支払い先あるいは受領者からの請求書を提示する支払いアプリケーション３０６を示す、デバイス１０８の実例的なユーザインターフェース（ＵＩ）９００である。

ＵＩ９００は、請求書１１８からの商店主情報９０２を含むことができる。商店主情報は、商店主１１２の説明、参照番号、取引に関わる品目、および／または他のデータを含むことができる。商店主情報９０２はまた、支払うべき金額９０４を含むことができ、これはデバイス１０８を経由して電子マネーを使用して支払われることができる。ユーザ１０６は、支払いコマンド９０６を使用して支払うべき金額を払うか、または拒否コマンド９０８を使用して支払うべき金額を拒否することができる。

ＵＩ９００は、ユーザ１０６が異なる額９１０を払うことができるようにすることができる。ユーザは、異なる額を入力し、次に支払いコマンド９１２を選択することができる。

いくつかの実施形態において、ＵＩ９００は、電子マネーの残りの残高および／または電子マネーの分配に関連する他の情報およびその他を示すアカウントの詳細９１４を含むことができる。アカウントの詳細９１４は、ユーザが詳細コマンド９１６を使用してより多くの情報を獲得することを可能にすることができる。

いくつかの実施形態において、ＵＩ９００は、請求書なしで支払い先への通信を開始することができる。ゆえに、ＵＩ９００は、ユーザ１０６が商店主１１２からの請求書１１８なしで、ユーザが署名した請求書を作成することを可能にすることができる。

結論
発明の対象は構造的特徴および／または方法論的行為に特定的な文言によって説明されたが、添付の特許請求の範囲に画定される発明の対象は、記載された具体的な特徴または行為に必ずしも限定されるものではないことは理解されるものとする。逆に、具体的な特徴および行為は、特許請求する発明を実装する実用的な形態として開示される。

付記
本開示の実施形態は、以下の付記を考慮して説明されることができる。

付記１．サーバで、支払いアカウントからデバイスに資金の配分を電子マネーとして送信するための要求を受け取ることと、
前記電子マネーを、少なくとも前記配分に関連付けられた認証キーを含む支払い情報と共に前記デバイスに送信することと、
前記サーバで、前記デバイスに由来する前記電子マネーの支払いについての要求であって、少なくとも前記認証キーによって暗号化されている前記要求を、支払い先から受け取ることと、
前記要求の暗号解読および前記資金の前記配分の残高が前記デバイスからの以前の支払いによって使い果たされていないことの前記サーバによる照合の後に、支払いを前記支払い先に送信することと、
メッセージを前記支払い先に、前記支払いが認証されていることを示し、前記支払いの額を確定するメッセージを送信することと、を含む、方法。

付記２．前記要求は、前記デバイスによって認証キーを使用して暗号化されている、付記１に記載の方法。

付記３．前記資金の前記配分の残高を更新するメッセージを前記デバイスに送信することをさらに含む、付記１または２に記載の方法。

付記４．前記電子マネーを第２のデバイスに送信することと、
前記支払いを開始したユーザとは違うユーザからの前記要求のための認証を要求することであって、
前記支払いの前記支払い先への前記送信は、前記支払いを開始した前記ユーザとは違う前記ユーザからの前記認証を条件とする、要求することと、をさらに含む、付記１乃至３のうちのいずれか１つに記載の方法。

付記５．サーバで、支払いアカウントからデバイスに資金の配分を電子マネーとして送信するための要求を受け取ることと、
前記電子マネーを前記デバイスに送信することと、
前記サーバで、前記支払い先への、かつ前記デバイスに由来する前記電子マネーの支払いについての要求であって、前記資金の前記配分に関連付けられた署名を含む要求を、支払い先または前記デバイスから受け取ることと、
前記署名が有効であり、かつ前記資金の前記配分の残高が以前の支払いによって使い果たされていない場合、支払いを前記支払い先に送信することと、
を含む、方法。

付記６．前記要求は、前記デバイス、前記支払い先、またはその両方によって暗号化されている、付記５に記載の方法。

付記７．前記署名は、前記デバイスの識別子と、前記配分に関連付けられた仮の識別子とを含み、前記署名は、所定の時間量のうちの少なくとも１つの後か、または前記資金の前記配分の枯渇後に期限切れとなる、付記５または６に記載の方法。

付記８．前記支払いの前記支払い先への送信は、支払人の前記支払いアカウントから前記支払い先の支払いアカウントに支払いを送金することを含む、付記５乃至７のうちのいずれか１つに記載の方法。

付記９．前記支払いが認証されていることを示し、前記支払いの額を確定するメッセージを前記支払い先に送信することをさらに含む、付記５乃至８のうちのいずれか１つに記載の方法。

付記１０．前記支払いを前記支払い先に送信した後に、前記電子マネーの残りの残高を更新するメッセージを、前記デバイスに送信することをさらに含む、付記５乃至９のうちのいずれか１つに記載の方法。

付記１１．前記電子マネーを第２のデバイスに送信することと、
前記支払いを開始したユーザとは違うユーザからの前記要求のための認証を要求することであって、前記支払いの前記支払い先への前記送信は、前記支払いを開始した前記ユーザとは違う前記ユーザからの前記認証を条件とする、要求することと、
をさらに含む、付記５乃至１０のうちのいずれか１つに記載の方法。

付記１２．前記支払いを前記支払い先に送信した後に、前記電子マネーの残りの残高を更新するメッセージを、前記デバイスおよび前記第２のデバイスに送信することをさらに含む、付記１１に記載の方法。

付記１３．電子デバイスで、ホストによって管理されている支払いアカウントから電子マネーの配分を受け取ることと、
前記電子デバイスを経由して、支払い先への前記電子マネーの支払いであって、前記配分の残高を超えている場合無効であり、かつ前記配分に関連付けられた署名を含む、支払いを送信することと、
前記電子デバイスで、前記支払いが有効である場合、前記配分の前記残高の更新を受け取ることであって、前記更新された残高は、前記配分から前記支払いおよびあらゆる適用される手数料を引いたものに等しい、更新を受け取ることと、
を含む、方法。

付記１４．前記電子マネーの配分を受け取ることは、前記配分に関連付けられた認証キーであって、前記電子マネーの前記配分の支払いを暗号化する前記認証キーを受け取ることを含む、付記１３に記載の方法。

付記１５．前記支払いの前記送信は、前記認証キーを用いて前記支払いを暗号化することを含む、付記１４に記載の方法。

付記１６．前記支払いが前記配分の残高を超えている場合、前記支払いの拒否を受け取ることをさらに含む、付記１３乃至１５のうちのいずれか１つに記載の方法。

付記１７．前記支払いの送信に先立って、支払い先から請求書を受け取ることをさらに含み、前記請求書は、前記支払いの額を提供する、付記１３乃至１６のうちのいずれか１つに記載の方法。

付記１８．前記支払いの送信は、近距離無線通信を使用した前記請求書への応答によって行われ、前記応答は、署名を使用して前記請求書をユーザが署名した請求書に変換する、付記１７に記載の方法。

付記１９．前記電子デバイスによる使用が可能な前記電子マネーの配分を更新する、前記支払いアカウントからの前記電子資金の別の配分を受け取ることをさらに含む、付記１３乃至１８のうちのいずれか１つに記載の方法。

付記２０．前記電子マネーの配分は、所定の額の価額とされ、前記別の配分の額は、前記電子デバイスから入手可能な前記電子マネーの額を、前記所定の額に増やすように選択される、付記１９に記載の方法。

付記２１．１つ以上のプロセッサ上で実行されると、
デバイスで、ホストによって管理されている支払いアカウントから電子マネーの配分を受け取ることと、
前記電子マネーのうちの少なくとも一部分を支払いとして支払い先に送信することであって、前記支払いは前記分配に関連付けられた署名を含む、送信することと、
前記分配から前記送信された前記電子マネーの一部分を引いたものに等しい前記電子マネーの残高を、前記電子デバイス上に留保することと、
を含む行為を行い、コンピュータによる実行が可能な命令を格納する、１つ以上のコンピュータ可読媒体。

付記２２．前記支払い先に送信される前記電子マネーの一部分を識別するメッセージを前記ホストに送信することをさらに含む、付記２１に記載の１つ以上のコンピュータ可読媒体。

付記２３．前記ホストに送信される前記メッセージは、前記支払い先への前記電子マネーの前記一部分の前記支払いの信頼性を照合する、付記２２に記載の１つ以上のコンピュータ可読媒体。

付記２４．前記署名は、前記デバイスの識別子を含む、付記２１乃至２３のうちのいずれか１つに記載の１つ以上のコンピュータ可読媒体。

付記２５．前記電子マネーのうちの少なくとも前記一部分の前記送信を行うのに先立って、前記電子マネーの前記一部分を暗号化することをさらに含む、付記２１乃至２４のうちのいずれか１つに記載の１つ以上のコンピュータ可読媒体。

付記２６．前記送信は、前記電子マネーの前記一部分を暗号解読するための認証キーを、前記支払い先に送ることを含む、付記２５に記載の１つ以上のコンピュータ可読媒体。

付記２７．前記メッセージは、前記デバイスと前記支払い先との間の取引の受領書である、付記２１乃至２６のうちのいずれか１つに記載の１つ以上のコンピュータ可読媒体。

Claims (13)

1. １つ以上のプロセッサと、
   コンピュータによる実行が可能な命令を格納する、１つ以上のコンピュータ可読媒体であって、実行されると、前記１つ以上のプロセッサに、
   支払いアカウントから複数のデバイスに資金の配分を電子マネーとして送信する要求の受け取りに応じて、少なくとも前記配分に関連付けられた認証キーを含む支払い情報とともに前記電子マネーを前記複数のデバイスに送信することであって、前記複数のデバイスは、少なくとも第１のデバイスおよび第２のデバイスを含み、前記複数のデバイスは、前記電子マネーおよび前記支払いアカウントを共有する、ことと、
   前記第１のデバイスに由来する前記電子マネーの支払いについての支払い先からの要求を受け取ることに応じて、前記支払い先に支払いを送信することであって、前記要求は、少なくとも前記認証キーによって暗号化されており、前記支払いは、前記要求を復号化し、前記資金の前記配分の残高が前記複数のデバイスからの以前の支払いによって使い果たされていないことを確認した後、および、前記支払いが前記第２のデバイスによって承認された後に送信される、支払いを送信することと、
   前記第１のデバイス以外のデバイスに、前記第１のデバイスに由来する前記電子マネーの前記支払いが実行されたことを示すメッセージを送信して、前記第１のデバイス以外のデバイス上に表示される前記資金の前記配分の前記残高を更新することと
   を実行させる、１つ以上のコンピュータ可読媒体と、を備える、システム。
2. 前記要求は、前記認証キーを使用して前記第１のデバイスによって暗号化されている、請求項１に記載のシステム。
3. 前記１つ以上のコンピュータ可読媒体は、実行されると、前記１つ以上のプロセッサに、
   前記支払い先に、前記支払いが認証されていることを示し、前記支払いの額を確定するメッセージを送信すること、
   を実行させる、コンピュータによる実行が可能な命令をさらに格納する、請求項１に記載のシステム。
4. サーバで、支払いアカウントから複数のデバイスに資金の配分を電子マネーとして送信するための要求を受け取ることであって、前記複数のデバイスは、少なくとも第１のデバイスおよび第２のデバイスを含み、前記複数のデバイスは、前記電子マネーおよび前記支払いアカウントを共有する、ことと、
   前記電子マネーを前記複数のデバイスに送信することと、
   前記サーバで、支払い先への、かつ前記第１のデバイスに由来する前記電子マネーの支払いについての要求であって、前記資金の前記配分に関連付けられた署名を含む要求を、前記支払い先または前記第１のデバイスから受け取ることと、
   前記署名が有効であり、かつ前記資金の前記配分の残高が以前の支払いによって使い果たされていない場合および前記支払いが前記第２のデバイスによって承認された場合、支払いを前記支払い先に送信することと、
   前記第１のデバイス以外のデバイスに、前記第１のデバイスに由来する前記電子マネーの支払いが実行されたことを示すメッセージを送信して、前記第１のデバイス以外のデバイス上に表示される前記資金の前記配分の前記残高を更新することと
   を実行する、方法。
5. 前記署名は、前記第１のデバイスの識別子と、前記配分に関連付けられた仮の識別子とを含み、前記署名は、所定の時間量のうちの少なくとも１つの後か、または前記資金の前記配分の枯渇後に期限切れとなる、請求項４に記載の方法。
6. 複数の電子デバイスへ、ホストによって管理されている支払いアカウントから電子マネーの配分を送信することであって、前記複数の電子デバイスは、少なくとも第１の電子デバイスおよび第２の電子デバイスを含み、前記複数の電子デバイスは、前記電子マネーおよび前記支払いアカウントを共有する、ことと、
   前記第１の電子デバイスを経由して、支払い先への前記電子マネーの支払いであって、前記配分の残高を超えている場合無効であり、かつ前記配分に関連付けられた署名を含む、支払いを受け取ることと、
   前記第１のデバイス以外のデバイスへ、前記支払いが有効である場合および前記支払いが前記第２の電子デバイスによって承認された場合、前記第１のデバイス以外のデバイス上に表示される前記配分の前記残高の更新を送信することであって、前記更新された残高は、前記配分から前記支払いおよびあらゆる適用される手数料を引いたものに等しい、更新を送信することと、
   を含む、方法。
7. 前記電子マネーの配分を送信することは、前記配分に関連付けられた認証キーを送信することを含み、前記認証キーは、前記電子マネーの前記配分の支払いを暗号化するために使用され、前記支払いは、前記認証キーを用いて暗号化されることを含む、請求項６に記載の方法。
8. 前記複数の電子デバイスによる使用が可能な前記電子マネーの前記配分を更新する、前記支払いアカウントからの前記電子マネーの別の配分を送信することをさらに含み、前記電子マネーの配分は、所定の額の価額とされ、前記別の配分の額は、前記複数の電子デバイスから入手可能な前記電子マネーの額を、前記所定の額に増やすように選択される、請求項６に記載の方法。
9. １つ以上のプロセッサ上で実行されると、請求項４乃至請求項８のいずれか１項に記載の前記方法を実行する、コンピュータによる実行が可能な命令を格納する、１つ以上のコンピュータ可読媒体。
10. １つ以上のプロセッサと、
    １つ以上のコンピュータ可読媒体であって、実行されると、前記１つ以上のプロセッサに、
    電子デバイスを含む複数の電子デバイスで、ホストによって管理されている支払いアカウントからの電子マネーの分配を受け取ることに応じて、前記電子マネーのうちの少なくとも一部分を支払いとして支払い先に送信することであって、前記支払いは前記分配に関連付けられた署名を含み、前記複数の電子デバイスは、前記電子マネーおよび前記支払いアカウントを共有する、送信することと、
    前記支払いが前記電子デバイスとは別の電子デバイスによって承認された後に、前記分配から前記電子マネーの前記送信された部分を引いたものに等しい前記電子マネーの残高を、前記電子デバイス上に留保することであって、前記留保は、前記複数の電子デバイス上で行なわれる、ことと
    を実行させる、コンピュータによる実行が可能な命令を格納する、１つ以上のコンピュータ可読媒体と、を備える、電子デバイス。
11. 前記支払い先に送信される前記電子マネーの前記一部分を識別するメッセージを前記ホストに送信することをさらに含み、前記ホストに送信される前記メッセージは、前記支払い先への前記電子マネーの前記一部分の前記支払いの信頼性を照合する、請求項１０に記載の電子デバイス。
12. 前記電子マネーのうちの少なくとも前記一部分の前記送信を行うのに先立って、前記電子マネーの前記一部分を暗号化することをさらに含み、前記送信は、前記電子マネーの前記一部分を暗号解読するための認証キーを、前記支払い先に送ることを含む、請求項１０に記載の電子デバイス。
13. 前記署名は、前記電子デバイスの識別子を含む、請求項１０に記載の電子デバイス。

Images