JP2015015050A - リアルタイム決済の許可 - Google Patents

Abstract

【課題】リアルタイム決済において、拒否された決済アカウント取引をオーバーライドするプロキシカード決済システムを提供する。
【解決手段】拒否された取引をオーバーライドするリアルタイム要求、または取引を進めるように異なる金融アカウントを選択するリアルタイム要求、および商人に送信される取引承認メッセージへのユーザ識別情報の挿入を含む。プロキシアカウントによって各々アクセス可能な、デビットカード、クレジットカード、ストアードバリューカード、お得意様／ポイントカード、およびクーポン（購入済み特典および他の特典を含む）を含むが、それらに限定されない、複数の金融アカウントに対する特定の情報を含む。
【選択図】図１

Description

本出願は、２０１１年１１月１３日に出願された米国仮特許出願第６１／５５９，１３６号、名称「仮想支払経路（Ｖｉｒｔｕａｌ Ｐａｙｍｅｎｔ Ｐａｔｈ）」から優先権を主張する。上記で特定される優先出願の全体の内容は、参照することにより本明細書に完全に組み込まれる。

本開示は、概して、プロキシカードに関し、より具体的には、プロキシカード決済システムにおいて使用される新規特徴に関する。

従来の商人‐消費者の金融取引において、商人のＰＯＳ（Ｐｏｉｎｔ ｏｆ Ｓａｌｅ）端末またはオンライン決済プロセスエンジンは、取引に対する決済のために、入手者に決済要求を提示する（例えば、Ｃｈａｓｅ ＰａｙｍｅｎｔＴｅｃｈ、または他の第三者の決済処理会社）。その後、入手者は、カードネットワーク（例えば、ＶＩＳＡ、ＭａｓｔｅｒＣａｒｄ、Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ、Ｄｉｓｃｏｖｅｒ、または他のカード処理ネットワーク）を通して、発行人（例えば、Ｃｉｔｉｂａｎｋ、ＣａｐｉｔａｌＯｎｅ、Ｂａｎｋ ｏｆ Ａｍｅｒｉｃａ、および決済を許可する他の金融機関）へ、取引を許可するように要求を提示する。資金が利用可能な場合、発行人は、カードネットワークを通して入手者に許可コードを送信し、入手者は、決済取引に対する承認を商人に通知する。決済プロセスは、商人によって生成され提示された単一の決済要求を伴う。要求は、決済総額およびカードの磁気ストライプ上に符号化された消費者アカウント識別情報など、一般情報を含有するが、要求は、最小在庫管理単位（「ＳＫＵ」）番号などの品目別情報、または電子メールアドレスなどのユーザ識別情報を含有しない。

従来の商人−消費者金融取引はまた、デビットカード、クレジットカード、またはストアードバリューカードなど、消費者の金融アカウントを介する決済を伴っていた。消費者カードは、通常、１つの発行人のみによって維持管理される、１つのタイプのアカウントにのみアクセスする。例えば、「発行人１」のクレジットカードは、「発行人１」からの消費者の金融アカウントにのみアクセスし、決済は単一の発行人（「発行人１」）によって承認／拒絶される。取引の承認または拒絶は、ある特定の発行人によって設定される規則、例えば、信用限度額および地域的制限に依存する。これら規則の違反の通知は、結果として取引の拒否となり、消費者は、規則を変えるように、または拒否された取引に対処するように、発行人に連絡しなくてはならない。

ごく最近では、プロキシカード決済システムにより、ユーザが、複数の発行人によって維持管理される複数の金融アカウントにアクセスするように、単一のカードを利用することが可能である。ユーザは、決済システムからプロキシカードを受け取り、新しい決済システムアカウントを作成するか、またはプロキシカードを決済システムによって既に維持管理されているユーザのデジタルウォレットアカウントと関連付けるかのいずれかである。その後、ユーザは、１つ以上の金融カードアカウントを、プロキシアカウントと関連付ける。例えば、ユーザは、ユーザのプロキシカードアカウントと、複数の発行人（発行人として動作する決済システムを含む）によって維持管理される、複数のデビット／クレジットカード、ストアードバリューカード（例えば、ギフトカード、プリペイドカード、再ロード可能な取引カード、交換用カード（ｅｘｃｈａｎｇｅ ｃａｒｄ）、および他の形態の非信用ベースのバリューカード）、お得意様カードもしくは店のポイントカード、付加価値サービスアカウント（例えば、クーポン、プリペイド特典券、償還特典（ｒｅｄｅｍｐｔｉｏｎ ｏｆｆｅｒ）、および他の形態の特典）、および／または他の形態の金融カードアカウントを関連付けることができる。ユーザは、任意の金融系カードの取引への適用に類似する形で、プロキシカードを商人との取引に適用する。商人は、入手者に決済要求を転送し、入手者は、カードネットワークに決済要求を転送する。カードネットワークは、決済要求に対して発行人として機能する決済システムに、プロキシカード決済要求を転送する。決済システムは、決済要求からプロキシカードアカウント情報を読み取ることができ、プロキシカードと関連付けられる、ユーザのアカウントにアクセスすることができる。決済システムが金融アカウントの発行人である場合、決済システムは、取引を承認または拒否するであろう。別の発行人が金融アカウントを維持管理する場合、決済システムは、新しい決済要求を生成し、カードネットワークを介して発行人へ送信するであろう。取引が承認される場合、決済システムは、発行人からカードネットワークを介して、許可メッセージを受信するであろう。決済システムは、カードネットワークを通して入手者に許可を転送し、カードネットワークは、商人に許可を転送する。その後、商人は取引を承認する。

ある例示的態様では、プロキシカード決済システムにおいて使用される新規特徴は、拒否された取引をオーバーライドするリアルタイム要求、または取引を進めるように異なる金融アカウントを選択するリアルタイム要求、および商人に送信される取引承認メッセージへのユーザ識別情報の挿入を含む。決済システムは、プロキシアカウントによって各々アクセス可能な、デビットカード、クレジットカード、ストアードバリューカード、お得意様／ポイントカード、およびクーポン（購入済み特典および他の特典を含む）を含むが、それらに限定されない、複数の金融アカウントに対する特定の情報を含む。ユーザは、プロキシカードが使用される時にどの金融アカウントにアクセスするかを規定し、プロキシカードが拒否される制限または状況を規定する、規則を設定する。決済要求は、プロキシカードアカウントを維持管理する、決済システムに転送される。決済システムは、金融アカウントが適用されるべき順序、および取引がユーザ定義規則を破っているかどうかを判定するように、規則を使用する前に、ユーザアカウント情報を読み取る。決済システムが金融アカウントを維持管理していない場合、決済システムは、参考アカウントの発行人に新しい決済要求を送信する。取引が発行人または決済システムによって拒否されるべき場合、決済システムは、ユーザの携帯デバイスを介して、ユーザにリアルタイムメッセージを送信することができる。ユーザは、取引を拒否させる規則をオーバーライドするように、または取引を処理する新しいアカウントを選択するように促される場合がある。決済システムは、取引に対する許可を受信すると、カードネットワークおよび入手者を通して、商人へ承認を伝送する前に、承認メッセージの中にユーザ識別情報を挿入することができる。ユーザ識別情報はまた、プロキシカードの磁気ストライプ上に記憶された、またはそうでなければ、プロキシカードアカウント識別子と関連付けられた、プロキシカードアカウント情報において提供することができる。

例示的実施形態のこれらおよび他の態様、目的、特徴、および利点は、ここで提示されるように発明を実行する最適形態を含む、例証される例示的実施形態に関する以下の詳細な説明を考慮して、当業者に明らかとなるであろう。

例示的実施形態に従い、複数の発行人によって維持管理される複数のアカウントにアクセスすることができる、単一のプロキシアカウント用の動作環境を描写するブロック図である。 例示的実施形態に従い、ユーザプロキシカードを登録するための方法を描写する、ブロックフロー図である。 例示的実施形態に従い、プロキシカードの静的規則を定義するための方法を描写する、ブロックフロー図である。 図４ａを備える、例示的実施形態に従い、プロキシカード決済を処理するための方法を描写する、ブロックフロー図である。 図４ｂを備える、例示的実施形態に従い、プロキシカード決済を処理するための方法を描写する、ブロックフロー図である。 例示的実施形態に従い、ユーザのプロキシカードアカウントにアクセスするための方法を描写する、ブロックフロー図である。 例示的実施形態に従い、付加価値サービスを処理するための方法を描写する、ブロックフロー図である。 例示的実施形態に従い、特典を送信するための方法を描写するブロックフロー図である。 図８ａを備える、例示的実施形態に従い、拒否された取引を許可するための方法を描写する、ブロックフロー図である。 図８ｂを備える、例示的実施形態に従い、拒否された取引を許可するための方法を描写する、ブロックフロー図である。

概説
決済システムは、プロキシアカウントによって各々アクセス可能な、デビットカード、クレジットカード、ストアードバリューカード、お得意様／ポイントカード、およびクーポン（購入済み特典および他の特典を含む）を含むが、それらに限定されない、複数の金融アカウントに対する特定の情報を含む。ユーザは、プロキシカードが使用される時にどの金融アカウントにアクセスするかを規定し、プロキシカードが拒否される制限または状況を規定する、規則を設定する。その後、ユーザは、プロキシカードと関連付けられた既定の決済規則を追加、削除、または変更することができる。ユーザは、これら既定の静的規則を変更するか、新しい規則を作成するか、または規則を削除することができる。例示的実施形態では、ユーザは、プロキシカードを使用して決済取引を開始する直前を含み、いつでも、決済システムアカウントにアクセスし、規則を修正することができる。例示的実施形態では、ユーザは、携帯デバイスのアプリケーションを使用して、決済システムアカウントにアクセスすることができる。

ユーザが、取引に先立って、静的決済規則を定義していたか、または規則を追加／削除／修正していた場合、決済システムは最初に、ユーザ定義規則を取引に適用する。そうでなければ、決済システムは、既定の静的決済規則を取引に適用する。取引が拒否されるべき場合、決済システムは、ユーザの携帯デバイスに通信されるメッセージを介して、拒否された取引をユーザに通知する。規則の違反により、取引が拒否された場合、ユーザは、規則をオーバーライドするように促される場合がある。金融アカウントが不足金を有する場合、ユーザは、新しい金融アカウントを選択するように促される場合がある。決済要求を拒否する代わりに、決済システムは、メッセージへのユーザの応答に基づき、決済要求を許可および／または処理することができる。代替的に、決済システムは、元の決済要求を拒否し、通知メッセージをユーザに伝達し、ユーザの応答を受信し、決済のために記憶された規則を訂正することができる。その後、ユーザは、プロキシカードを使用して、商人との新しい決済取引を即座に開始してもよい。次いで、決済システムは、新しい決済要求の受信後、決済取引を承認するであろう。

決済システムは、金融アカウントが、非決済システム発行人によって維持管理されている場合には、新しい決済要求を生成し、または決済システムが、金融アカウントを維持管理している場合には、元の決済要求を許可する。いずれの場合でも、決済システムは、発行人によって受信される許可メッセージ、または金融アカウントの発行人として働く決済システムによって生成される許可メッセージに、ユーザ識別情報を追加することができる。決済システムはまた、ユーザに特典を転送するか、または決済メッセージおよび／または商人識別情報の中で受信される製品識別情報に基づき、決済取引に直接特典を投入することができる。

ユーザは、本明細書に開示する特徴の動作を限定する、またはそうでなければ動作に影響を与えることが可能な場合がある。例えば、ユーザは、あるデータの収集もしくは使用、またはある特徴の起動をオプトインまたはオプトアウトする機会を与えられる場合がある。加えて、ユーザは、ユーザがプライバシーに関する懸念を有する場合がある状態を含み、特徴が採用される方式を変更する機会を与えられる場合がある。命令はまた、個人的に識別可能な情報を含む、情報の使用についての方針、および各ユーザがこのような情報の使用に影響する場合がある方式に関して通知するように、ユーザに提供されてもよい。それゆえ、情報は、所望の場合、個人情報またはユーザのＩＤを開示する危険を冒すことなく、関連広告または他の情報の受信を通して、ユーザの利益になるように使用することができる。

例示的実施形態の機能性は、以下の説明でより詳細に説明され、プログラムフローを示す図面と併せて読まれる。

システムアーキテクチャ 図面全体にわたって同様の数字が同様の（しかし必ずしも同一ではない）要素を示す、図面をここで参照して、例示的実施形態が詳細に説明される。

図１は、例示的実施形態に従い、複数の発行人１６０、１７０によって維持管理される複数のアカウントにアクセスすることができる、プロキシカード１０５のための動作環境１００を描写するブロック図である。図１に描写する通り、例示的動作環境１００は、プロキシカード１０５、商人システム１１０、ユーザ１０１の携帯デバイスシステム１２０、入手者システム１４０、カードネットワークシステム１５０、発行人／決済システム１６０、および１つ以上の通信ネットワーク（図示せず）を介して互いに通信するように構成される、１つ以上の発行人システム１７０を含む。

各通信ネットワークは、ネットワークデバイス（デバイス１０５、１１０、１２０、１４０、１５０、１６０、および１７０を含む）が、データを送受信することができる、有線または無線電気通信手段を含む。例えば、各ネットワークは、ローカルエリアネットワーク（「ＬＡＮ」）、広域ネットワーク（「ＷＡＮ」）、イントラネット、インターネット、携帯電話ネットワーク、カードネットワーク、またはいかなるそれらの組み合わせを含むことができる。本明細書を通して、用語「データ」および「情報」は、テキスト、画像、音声、動画、またはコンピュータを基盤とする環境の中に存在することができる、任意の他の形態の情報を指すように、本明細書において互換的に使用されることは理解されるべきである。

安全な通信チャネル１３０は、ネットワークデバイス（デバイス１１０および１２０を含む）がデータを交換することができる、電気通信手段を含む。例えば、各接続は、ローカルエリアネットワーク（ＬＡＮ）、広域ネットワーク（ＷＡＮ）、イントラネット、インターネット、携帯電話ネットワーク、パーソナルエリアネットワーク（ＰＡＮ）、またはいかなるそれらの組み合わせを含むことができる。例示的実施形態では、安全な通信チャネル１３０は、Ｂｌｕｅｔｏｏｔｈ（登録商標）など、近接通信接続を備える。Ｂｌｕｅｔｏｏｔｈ（登録商標）は、高レベルの安全性を伴うＰＡＮの作成を通して、短距離にわたりデータの交換を可能にすることができる。Ｗｉ‐Ｆｉは、非接触型デバイスが、無線アドホックネットワークを介して通信することができる、また別の近接通信タイプである。代替の例示的実施形態では、安全な通信チャネル１３０は、近距離無線通信（ＮＦＣ）の通信方法を備える。

ＰＯＳ（Ｐｏｉｎｔ ｏｆ Ｓａｌｅ）端末システム１１０は、アプリケーション１１５を介してプロキシカード１０５を読み取り、携帯デバイスシステム１２０および商人ＰＯＳ端末１１８と通信することができる、端末読み取り装置１１３を含む。

例示的実施形態では、端末読み取り装置１１３は、プロキシカード１０５が読み取り装置を通される時、プロキシカード１０５上の磁気ストライプを読み取る、磁気ストライプ読み取り装置を備える。他の例示的実施形態では、端末読み取り装置１１３は、バーコード、ＱＲ（登録商標）コード、またはプロキシカードから情報を捕捉する、他の機械で読み取り可能なスキャナを備える。

別の例示的実施形態では、端末読み取り装置１１３は、Ｂｌｕｅｔｏｏｔｈ（登録商標）通信方法を使用して、携帯デバイス１２０と通信する通信コンポーネントを備える。代替の例示的実施形態では、端末読み取り装置１１３は、Ｗｉ‐Ｆｉ通信方法を使用して、携帯デバイス１２０と通信する。また別の例示的実施形態では、端末読み取り装置１１３は、ＮＦＣ通信方法を使用して、携帯デバイス１２０と通信する。代替の例示的実施形態に従い、端末読み取り装置１１３は、独立型ハードウェアデバイスとして描写される一方、端末読み取り装置１１３はまた、ＰＯＳ端末１１８の統合部であってもよい。

例示的実施形態では、携帯デバイスシステム１２０は、端末読み取り装置１１３など、デバイスと別のデバイスとの間を、電子、磁気、または無線周波数電磁場を介して通信することができる、スマートデバイスを指し得る。例示的実施形態では、携帯デバイス１２０は、記憶容量／メモリ、およびある特定の機能を行うことができる、１つ以上のアプリケーション１２２など、処理能力を有する。例示的実施形態では、携帯デバイス１２０は、オペレーティングシステム（図解せず）およびユーザインターフェース１２３を含有する。例示的携帯デバイス１２０は、処理機能性およびユーザインターフェース機能性を有する各場合において、スマートフォン、携帯電話、ＰＤＡ、ネットブックおよびｉＰａｄなどのモバイルコンピューティングデバイス、他の電子的に使用可能なキーフォブ、電子的に使用可能なクレジットカードタイプのカード、および他のデバイスを含む。ある携帯デバイス１２０は、金融取引、クーポン、発券、安全な認証、および他の関連用途を含む、複数の目的に使用することができる。

安全要素１２６は、可撤性スマートチップもしくはセキュアデジタル（ＳＤ）カード内に存在することができるか、または携帯デバイス１２０上の固定チップ内に埋め込むことができる。ある例示的実施形態では、例えば、ＮＦＣ ＳＩＭ Ｃａｒｄといった、ＳＩＭ（Ｓｕｂｓｃｒｉｂｅｄ Ｉｄｅｎｔｉｔｙ Ｍｏｄｕｌｅ）カードは、安全要素１２６をホストすることができる場合がある。安全要素は、デバイス１２０上に常駐し、ユーザ１０１によってアクセス可能な、ウォレットソフトウェアアプリケーションまたは他のアプリケーション（１２２または１２７）が、安全要素内に記憶される情報を保護しながら、安全要素１２６内である機能と安全に情報を交換することを可能にする。安全要素１２６は、本明細書に記載する機能を行い、その上で動作するアプリケーション１２７を備える。

安全要素１２６は、暗号プロセッサおよび乱数発生器など、スマートカードの典型であるコンポーネントを含む。例示的実施形態では、安全要素１２６は、Ｊａｖａ（登録商標）Ｃａｒｄ Ｏｐｅｎ Ｐｌａｔｆｏｒｍ（ＪＣＯＰ）オペレーティングシステムなど、スマートカードのオペレーティングシステムによって制御されるチップ上の高度に安全なシステムの中に、Ｓｍａｒｔ ＭＸタイプのＮＦＣ制御器１２４を備える。別の例示的実施形態では、安全要素１２６は、随意的な実装など、非ＥＭＶタイプの非接触型スマートカードを含むように構成される。

安全要素１２６は、携帯デバイス１２０の中で、制御器１２４およびアプリケーション１２２と通信する。例示的実施形態では、安全要素１２６は、暗号化されたユーザ情報を記憶し、信頼できるアプリケーションが、記憶された情報にアクセスすることのみを可能にすることができる。制御器１２４は、安全要素１２６における復号およびインストールのために、安全なキーによる暗号化アプリケーション１２２と情報を交換する。例示的実施形態では、制御器１２４は、Ｂｌｕｅｔｏｏｔｈ（登録商標）リンク制御器である。Ｂｌｕｅｔｏｏｔｈ（登録商標）リンク制御器は、Ｂｌｕｅｔｏｏｔｈ（登録商標）指定の手順に従い、データを送受信し、端末読み取り装置１１３を識別し、認証および暗号化機能を実行し、携帯デバイス１２０が、どのように端末読み取り装置１１５からの伝送を調べるのであろうか、またはどのように携帯デバイス１２０を種々の省電力モードに設定するのであろうかを指示することができる場合がある。別の例示的実施形態では、制御器１２４は、類似の機能を行うことができる、Ｗｉ‐Ｆｉ制御器またはＮＦＣ制御器である。

アプリケーション１２２は、携帯デバイス１２０上に存在しその動作を行う、プログラム、機能、ルーチン、アプレット、または類似のエンティティである。例えば、アプリケーション１２２は、携帯デバイス１２０上で動作する、デジタルウォレットアプリケーション、クーポンアプリケーション、お得意様カードアプリケーション、別の付加価値アプリケーション、ユーザインターフェースアプリケーション、または他の好適なアプリケーションのうちの１つ以上であってもよい。加えて、安全要素１２６はまた、決済アプリケーション、安全な形態のアプリケーション１２２、認証アプリケーション、決済提供アプリケーション、または安全要素の安全な機能性を使用する、他の好適なアプリケーションなど、安全な非接触型ソフトウェアアプリケーションを備えてもよい。

例示的デジタルウォレットアプリケーション１２２は、ユーザ１０１によって登録された、１つ以上の金融カードアカウントの記憶が可能である。例示的実施形態では、登録されたアカウントは、ユーザ１０１のデジタルウォレットアプリケーション１２２によって維持管理し、データ記憶ユニット１６７の中に記憶することができる。また別の実施形態では、登録されたアカウントは、決済システム１６０の処理モジュール１６３によって維持管理し、データ記憶ユニット１６７の中に記憶することができる。

携帯デバイス１２０は、アンテナ１２８を介して、端末読み取り装置１１３と通信する。例示的実施形態では、携帯デバイスのアプリケーション１２２が、起動し優先されるとすぐに、制御器１２４は、取引に対する携帯デバイス１２０の準備の状態を通知される。制御器１２４は、アンテナ１２８を通して無線信号を出力するか、またはデバイス読み取り装置１１５からの無線信号を調べる。携帯デバイス１２０と端末読み取り装置１１３との間に安全な通信チャネル１３０を確立すると、端末読み取り装置１１３は、安全要素１２６からの利用可能なアプリケーション１２７の一覧を要求する。ディレクトリが最初に表示され、その後、設定された優先度またはデバイス読み取り装置１１５のタイプに基づき、アプリケーション１２７が、取引のために選ばれ開始される。

ある例示的実施形態では、ネットワークデバイス（デバイス１１０、１２０、１４０、１５０、１６０、および１７０を含む）は、ＨＴＭＬ５対応または他のウェブサーバを含む。ＨＴＭＬ５対応ウェブサーバは、以前のＨＴＭＬバージョンが有さなかった、クロスドキュメントメッセージングのアプリケーションプログラミングインターフェース（「ＡＰＩ」）、およびローカル記憶装置ＡＰＩを含む。ＨＴＭＬ５対応ウェブサーバのクロスドキュメントメッセージングＡＰＩは、ウェブサイトなどのドキュメントが、互いに通信することを可能にする。例えば、第１のドキュメントは、第２のドキュメントに、メッセージを送信して、情報を要求することができる。それに応じて、第２のドキュメントは、要求された情報を含むメッセージを、第１のドキュメントに送信することができる。ＨＴＭＬ５対応ウェブブラウザのローカル記憶装置ＡＰＩは、ウェブブラウザがインストールされている、または実行中のクライアントデバイス上に、ウェブブラウザが情報を記憶することを可能にする。ウェブサイトは、クライアントデバイス上に情報を記憶するために、ローカル記憶装置ＡＰＩを採用することができる。ある例示的実施形態では、他のウェブブラウザはクロスドキュメントメッセージングを有するか、および／またはローカル記憶装置能力がまた使用される場合もある。

例示的実施形態では、プロキシカード１０５は、標準的なクレジットカードまたはデビットカードと同じように見え、および／または機能する。例えば、プロキシカード１０５は、カード１０５の前面に、一覧として記載されるユーザ１０１の氏名および／またはアカウント番号を有する場合がある。例示的プロキシカード１０５は、ユーザ１０１の決済システム１６０のアカウント情報を符号化する、磁気ストライプを含むことができる。例示的実施形態では、磁気ストライプの中に符号化されたアカウント情報は、処理のために、決済システム１６０への決済要求の経路を選択する。

代替の例示的実施形態では、プロキシカード１０５は物理的カードではない。代わりに、プロキシカード１０５は、携帯デバイス１２０の無線タップ、アカウント識別番号、バーコードまたはＱＲ（登録商標）コード、トークン、または他の形態のアカウント識別もしくはアクセスによってアクセス可能なアカウントであり、それらは、期間ＰＯＳ端末１１８もしくは端末読み取り装置１１３に手動で入力されてもよく、または端末読み取り装置１１３によって捕捉されてもよい。本明細書を通して記載する通りのプロキシカード１０５は、物理的カードだけでなくプロキシアカウントをも指す。

ユーザ１０１は、プロキシカード１０５を登録し、および／またはユーザ１０１の決済システム１６０のアカウントにアクセスするように、携帯デバイス１２０または他のネットワークデバイスを使用してもよい。携帯デバイス１２０は、ウェブサーバ（例えば、Ｇｏｏｇｌｅ Ｃｈｒｏｍｅ、Ｍｉｃｒｏｓｏｆｔ Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ、Ｎｅｔｓｃａｐｅ、Ｓａｆａｒｉ、Ｆｉｒｅｆｏｘ、またはウェブページファイルと情報を交換するための他の好適なアプリケーション）を含むか、またはウェブサーバに連結される、適切な技術を備えてもよい。

決済システム１６０は、処理モジュール１６３によってアクセス可能な、データ記憶ユニット１６７を含む。例示的データ記憶ユニット１６７は、１つ以上の有形のコンピュータで読み取り可能な記憶デバイスを含むことができる。

ユーザ１０１は、ウェブサイト（図解せず）および通信ネットワーク（図解せず）を介して、決済システム１６０を眺めるか、登録するか、ダウンロードするか、アップロードするか、またはそうでなければアクセスするように、ウェブサーバを使用することができる。ユーザ１０１は、銀行口座のデビットカード、クレジットカード、ギフトカード、お得意様カード、クーポン、特典、プリペイド特典、店のポイントカード、または購入するかもしくは付加価値サービスを履行するために使用することができる、他のタイプの金融アカウントを含む、１つ以上の登録された金融カードアカウントを、プロキシカード１０５と関連付ける。登録された金融カードアカウントは、各金融アカウントを維持管理する、複数の発行人１６０、１７０を有する場合がある。決済システム１６０はまた、関連付けられた金融アカウントに対する発行人として機能してもよい。ユーザ１０１の登録情報は、決済システム１６０のデータ記憶ユニット１６７の中に保存され、処理モジュール１６３によってアクセス可能である。ユーザ１０１のプロキシカード１０５の登録については、図２に記載する方法を参照して、以下でより詳細に議論する。

ユーザ１０１はまた、プロキシカード１０５の決済規則を定義するように、ウェブサーバを使用してもよい。プロキシカード１０５の決済規則の作成については、図３に記載する方法を参照して、以下でより詳細に議論する。

商人１１０は、ウェブサイト（図解せず）および通信ネットワーク（図解せず）を介して、特典を眺めるか、ダウンロードするか、アップロードするか、作成するか、またはそうでなければ決済システム１６０にアクセスするように、ウェブサーバ（図解せず）を使用する場合がある。

ユーザ１０１は、商人１１０から購入を要求される場合がある。例示的実施形態では、購入は、ＰＯＳ端末１１８にて、プロキシカード１０５を機械に通すことによって開始される。代替の例示的実施形態では、購入は、端末読み取り装置１１３による携帯デバイス１２０の無線「タップ」によって開始される。代替の例示的実施形態では、購入は、ユーザ１０１が、ＰＯＳ端末１１８または携帯デバイス１２０において、アカウント識別番号を入力する時に開始される。アカウント識別番号は、プロキシカード１０５のアカウント番号、または決済取引をプロキシカード１０５のアカウントにリンクさせる、異なる番号である場合がある。また別の代替の例示的実施形態では、購入は、恒久的／一時的な仮想／物理的トークン、ＱＲ（登録商標）コード、バーコード、または端末読み取り装置１１３によって捕捉される、他の好適な機械で読み取り可能な媒体の使用によって開始される。商人のＰＯＳ端末１１８は、入手者１４０（例えば、Ｃｈａｓｅ ＰａｙｍｅｎｔＴｅｃｈ、または他の第三者決済処理会社）、カードネットワーク１５０（例えば、ＶＩＳＡ、ＭａｓｔｅｒＣａｒｄ、Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ、Ｄｉｓｃｏｖｅｒ、または他のカード処理ネットワーク）、決済システム１６０、および発行人１７０（例えば、Ｃｉｔｉｂａｎｋ、ＣａｐｉｔａｌＯｎｅ、Ｂａｎｋ ｏｆ Ａｍｅｒｉｃａ、および決済を許可する他の金融機関）と情報を交換する。プロキシカード１０５の決済の処理については、図４〜８に記載する方法を参照して、以下でより詳細に議論する。

システムプロセス
図２は、例示的実施形態に従い、ユーザプロキシカードを登録するための方法を描写する、ブロックフロー図である。方法２００については、図１に図示するコンポーネントを参照して記載する。

ブロック２１０では、決済システム１６０は、プロキシカード１０５をユーザ１０１に発行する。例示的実施形態では、ユーザ１０１は、ウェブサーバを使用して、プロキシカード１０５を作成および要求し、プロキシカード１０５は、ユーザ１０１に郵送される。ユーザ１０１には、物理的カードを受け取る前に、インターネットを介して、取引に使用するアカウント番号を発行される場合がある。代替の例示的実施形態では、決済システム１６０は、有効化されていないプロキシカード１０５をユーザ１０１に郵送する。その後、プロキシカード１０５は、使用の前に、ユーザ１０１によって有効化される。代替の例示的実施形態では、物理的プロキシカード１０５は発行されない。プロキシカード１０５のアカウント情報は、携帯デバイス１２０の中に記憶され、ＮＦＣ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、Ｗｉ‐Ｆｉ、または携帯デバイス１２０の他の形態の無線タップを介して、端末読み取り装置１１３で決済されるように使用される。代替の例示的実施形態では、購入は、ユーザ１０１が、ＰＯＳ端末１１８または携帯デバイス１２０において、アカウント識別番号を入力する時に開始される。アカウント識別番号は、プロキシカード１０５のアカウント番号、または決済取引をプロキシカード１０５のアカウントにリンクさせる、異なる番号である場合がある。また別の代替の例示的実施形態では、購入は、恒久的／一時的な仮想／物理的トークン、ＱＲ（登録商標）コード、バーコード、またはＰＯＳ端末１１８によって読み取られる、他の好適な機械で読み取り可能な媒体の使用によって開始される。これらの場合には、ＰＯＳ端末１１８は、スキャナ、カメラ、またはバーコードもしくはＱＲ（登録商標）読み取り装置、または他の好適な読み取りデバイスなど、プロキシアカウント情報を捕捉する、他の読み取りデバイスを備えてもよい。プロキシアカウント情報は、紙または他の形態に印刷されてもよい。

ブロック２２０では、ユーザ１０１は、新しい決済システム１６０のアカウントを作製するか、またはプロキシカード１０５を既存の決済システム１６０のアカウントにリンクさせる。決済システム１６０はまた、携帯デバイス１２０上で、デジタルウォレットアプリケーション１２２のアカウントを作成または更新してもよい。

ブロック２３０では、ユーザ１０１は、プロキシカード１０５を有効化し、１つ以上の金融カードアカウント（例えば、デビットカード、クレジットカード、ギフトカード／ストアードバリューカード、お得意様カード／ポイントカード、クーポン、プリペイドまたは他の特典、および購入するかまたは付加価値サービスを履行するために使用される、他のアカウント）を、プロキシカード１０５のアカウントと関連付ける。例示的実施形態では、ユーザは、複数の金融カードアカウントをプロキシカード１０５のアカウントと関連付ける。ユーザ１０１は、各金融カードアカウント用の識別情報を入力することによって、このブロックを実施してもよい。

例示的実施形態では、１つ以上の金融カードアカウントは、決済システム１６０および別の発行人１７０ａによって維持管理される。代替の例示的実施形態では、決済システム１６０は、金融カードアカウントのうちの１つ以上を維持管理し、その金融カードアカウントの発行人として働く。別の例示的実施形態では、金融カードアカウントは、決済システム１６０を含む、１つより多い発行人１７０によって維持管理される。

ブロック２４０では、ユーザ１０１が、プロキシカード１０５を使用して決済を処理する時に従うべき決済規則を定義してもよい。プロキシカード１０５の規則を定義するための方法については、図３に記載する方法を参照して、以下でより詳細に記載する。

図３は、例示的実施形態に従い、プロキシカードの静的規則を定義するための方法を描写する、ブロックフロー図である。方法２４０については、図１に図示するコンポーネントを参照して記載する。

ブロック３１０では、決済システム１６０は、プロキシカード１０５のアカウントと関連付けられる、既定の決済規則を説明する。ブロック３２０から３６５は、例示的な既定の決済規則について記載する。代替の例示的実施形態では、例示的な既定の規則は任意の順で現れてもよい。別の例示的実施形態では、追加資金が必要とされない場合には、例示的な既定の規則のうちの１つ以上が使用されないことがある。例えば、ストアードバリューアカウントの適用後、購入を完了するために、さらなる資金は必要とされない場合、決済取引は、さらなる規則に従うことなく、完全に許可されるであろう。

ブロック３２０〜３６５は、例示的規則の流れを描写する。例示的実施形態では、特典および付加価値サービスが最初に適用される。ブロック３２０では、決済システム１６０は、ユーザ１０１が、任意のクーポン、バウチャー券、プリペイドもしくは他の償還特典、またはプロキシカード１０５と関連付けられる他の形態の付加価値サービスを有するかどうかを、最初に判定するであろう。

決済システム１６０は、ユーザ１０１が利用可能な付加価値サービスを有すると判定する場合、ブロック３２５において、それらの金融アカウントを最初に適用するであろう。例示的実施形態では、決済システム１６０は、種々の形態の付加価値サービスを探し適用する、事前に定義された順序を有するであろう。例えば、決済システム１６０は、最初にバウチャー券、その後クーポン、次いで償還特典、最後に任意の他の形態の登録された付加価値サービスを適用してもよい。

決済システム１６０は、ユーザ１０１が利用可能な付加価値サービスを有さないと判定する場合、ブロック３４０に進むであろう。

例示的実施形態では、お得意様カードは２番目に適用される。ブロック３４０では、決済システム１６０は、ユーザ１０１が、お得意様カード、ポイントカード、またはプロキシカード１０５と関連付けられる他の形態のストアバリューカードを有するかどうかを、判定するであろう。代替の例示的実施形態では、決済システム１０５は、他の形態の付加価値サービスの前に、お得意様カードを適用してもよい。

決済システム１６０は、ユーザ１０１が利用可能なお得意様カードを有すると判定する場合、その金融アカウントを適用するであろう。例示的実施形態では、決済システム１６０は、複数のお得意様カードが利用可能であるかを判定し、各金融アカウントを適用するであろう。

決済システム１６０は、ユーザ１０１が利用可能なお得意様カードを有さないと判定する場合、ブロック３５０に進むであろう。

例示的実施形態では、ストアードバリューアカウントは３番目に適用される。ブロック３５０では、決済システム１６０は、ユーザ１０１がギフトカード、プリペイドカード、再ロード可能な取引カード、交換用カード、およびプロキシカード１０５と関連付けられる、他の形態の非信用ベースのバリューカードを含む、ストアードバリューアカウントを有するかどうかを判定するであろう。

決済システム１６０は、ユーザ１０１が利用可能なストアードバリューカードを有すると判定する場合、その金融アカウントを適用するであろう。例示的実施形態では、決済システム１６０は、複数のストアードバリューアカウントが利用可能かどうかを判定し、各金融アカウントを適用するであろう。

決済システム１６０は、ユーザ１０１が利用可能なストアードバリューカードを有さないと判定する場合、ブロック３６０に進むであろう。

例示的実施形態では、デビットカードおよびクレジットカードは、最後に適用される。ブロック３６０では、決済システム１６０は、ユーザ１０１が、デビットカード、クレジットカード、またはプロキシカード１０５と関連付けられる他の形態の信用ベースのアカウントを有するかどうかを判定するであろう。

決済システム１６０は、ユーザ１０１が利用可能なデビット／クレジットカードを有すると判定する場合、その金融アカウントを適用するであろう。

決済システム１６０が、ユーザ１０１が利用可能なデビット／クレジットカードを有さないと判定する場合、取引は終了するであろう。

例示的実施形態では、既定の静的決済規則は任意の順で示されてもよい。代替の例示的実施形態では、決済システム１６０は、既定の静的決済規則のいずれを追加、削除、またはそうでなければ変更してもよい。

ユーザ１０１もまた、決済規則を設定してもよい。ブロック３７０では、ユーザ１０１が、既定の静的決済規則のいずれを追加、削除、またはそうでなければ変更してもよい。例示的実施形態では、ユーザ１０１もまた、規則の順序を変更してもよい。

例示的実施形態では、ユーザ１０１は、追加の静的決済規則を定義または選択してもよい。ユーザ１０１は、商人のタイプまたは名前（例えば、商人がレストランである場合、クレジットカードＡを最初に使用し、または商人が航空会社である場合、マイレージクレジットカードを使用する）、１日の時間帯または曜日（例えば、＄５以上の昼食に対しては、レストランのお得意様カードを最初に使用し、または平日の午前９時から午後５時の間での支出に対しては、ビジネスクレジットカードを使用する）、または場所もしくは商人が使用する通貨（例えば、欧州の全取引に対してはクレジットカードＸを使用し、または全オンライン取引に対してはクレジットカードＺを使用する）に基づき、決済規則を定義してもよい。ユーザは、条件付きの規則を定義してもよい。例えば、取引がコーヒーショップＢで＄５未満である場合、ギフトカードＹを使用する。

図３を参照して議論した規則に加えて、決済システム１６０はまた、金融アカウントの適用に対する規則を学ぶこともできる。例えば、ユーザが、ある特定の金融アカウントを、ある特定の商人またはある特定のタイプの商人に適用し、ユーザが、所定の回数または期間、そのプロセスを繰り返す場合、決済システム１６０は、プロキシカードが、ある特定の商人またはある特定のタイプの商人で使用される時はいつでも、そのある特定の金融アカウントを適用するように、規則を作成することができる。決済システム１６０は、ある特定の商人またはある特定のタイプの商人に関するある特定の金融アカウントの、ユーザ１０１の過去の使用のログを取ることができる。その後、このようなロギングにより、ユーザが一貫して、同じ金融アカウントを同じ商人または同じタイプの商人に適用すると判定する時、決済システム１６０は、このような使用に対して新しい規則を確立する。例示的実施形態では、決済システム１６０は、ある特定の商人またはある特定のタイプの商人にて、ユーザのプロキシカードを適用する所定の時間内において、決済システム１６０におけるユーザの規則設定に基づき、ある特定の金融アカウントのユーザの過去の適用を識別することができる。決済システム１６０は、学んだ規則を決済規則の適切な順序に挿入してもよい。例えば、学んだ決済規則が、クレジットカードまたはデビットカードに当てはまる場合、学んだ決済規則は、クレジットカードまたはデビットカードを適用するための、標準的規則の前に挿入される。類似の挿入プロセスは、特典、お得意様カード、およびストアードバリューカードに当てはまる。

例示的実施形態では、ユーザ１０１は、携帯デバイス１２０を介して決済システム１６０のアカウントにアクセスすることができ、いつでも静的規則を追加、削除、または修正することができる。例示的実施形態では、ユーザ１０１は、決済システム１６０のアカウントにアクセスし、静的規則を恒久的に変更することなしに、１回ごとまたは複数回ごとに静的規則をオーバーライドすることができる。代替の例示的実施形態では、ユーザ１０１は、決済する時に、ユーザインターフェース１２３を使用して、静的規則を追加、削除、または修正するように、携帯デバイス１２０のアプリケーション１２２を使用することができる。

ブロック３７０から、方法２４０はブロック２５０に進む（図２）。

図２に戻り、ブロック２５０では、決済システム１６０は、ユーザプロキシカード１０５のアカウント識別情報を、ネットワーク１５０に送信する。

ブロック２６０では、ネットワーク１５０は、プロキシカードアカウント識別情報を記憶する。代替の例示的実施形態では、アカウント番号は、発行人として決済システム１６０を識別し、決済の経路は、承認のため、自動的にネットワーク１５０から決済システム１６０へ選択される。

図４は、例示的実施形態に従い、プロキシカード決済を処理するための方法を描写する、ブロックフロー図である。方法４００については、図１に図示するコンポーネントを参照して記載する。

ブロック４０３では、ユーザ１０１は随意に、ブロック２４０で定義した静的規則を修正する。例示的実施形態では、携帯デバイス１２０は、プロキシカード１０５を使用して購入する前に、１つ以上の静的規則を一時的に追加／修正／削除するように使用される。代替の例示的実施形態では、端末読み取り装置１１３および／またはＰＯＳ端末１１８は、プロキシカード１０５を使用して購入する前に、１つ以上の静的規則を一時的に追加／修正／削除するように使用される。

ユーザ１０１は、ブロック４０５において、プロキシカード１０５を、商人１１０との取引に適用する。例示的実施形態では、ユーザ１０１は、商人１１０との取引に対して支払うように、プロキシカード１０５をＰＯＳ端末１１８の機械に通す。代替的に、ユーザは、端末読み取り装置１１３による捕捉のために、印刷されたバーコード、ＱＲ（登録商標）コード、またはプロキシカード情報の他の機械で読み取り可能な指標を示してもよい。

代替の例示的実施形態では、ユーザ１０１は、非接触型「タップ」を端末読み取り装置１１３で開始するために、携帯デバイス１２０を使用する。ＮＦＣ取引の動作の中で、ユーザ１０１は、ＰＯＳシステムの端末読み取り装置１１３に、ＮＦＣ対応の携帯電話１２０など、携帯デバイス１２０をタップする。端末読み取り装置１１３は、デバイスが読み取り装置１１３の範囲内を移動する時、ＮＦＣ対応デバイス１２０を認識し、デバイス１２０との安全な通信チャネルを確立し、読み取り装置１１３とデバイス１２０との間の決済取引を開始する。

代替の例示的実施形態では、ユーザ１０１は、インターネットを介してオンライン購入を完了する。ユーザ１０１は、ウェブサーバを使用して商品用の商人１１０のウェブサイトを閲覧し、１つ以上の製品を購入したいと示唆することができる。ユーザ１０１が製品を購入したいと示唆した（例えば、「精算」リンクを作動させることによって）後、商人１１０のウェブサイトは、ユーザ１０１から決済情報を受信するために、ウェブページの形態でユーザインターフェースを提示することができる。ユーザ１０１は、精算の際に購入を完了するために、プロキシカード１０５の情報を入力する。

別の代替の例示的実施形態では、デジタルウォレットアプリケーション１２２が、商人１１０のウェブサイトおよびユーザ１０１と情報を交換することができる。商人１１０のウェブサイトは、携帯デバイス１２０が、デジタルウォレットアプリケーション１２２を含むかどうかを検出し、ユーザのデジタルウォレットにつながることができる。一度つながると、商人１１０のウェブサイトは、購入要求メッセージを、デジタルウォレットアプリケーション１２２に送信して、決済情報を要求することができる。商人１１０のウェブサイトから購入要求メッセージを受信したのに応答して、デジタルウォレットアプリケーション１２２は、デジタルウォレットアプリケーション１２２の中に保存されるプロキシカード１０５の情報を使用して、購入を確認するように、ユーザ１０１用のユーザインターフェース１２３を、ユーザ１０１に示すことができる。

ブロック４０７では、ＰＯＳ端末は、プロキシアカウントを使用して決済を要求するように、決済要求メッセージを生成し、商人システム１１０は、プロキシカード１０５を取引に適用することによって生成される決済要求メッセージに、製品識別情報を随意で追加する。例示的実施形態では、製品識別情報は、ユーザ‐商人取引において求められる、製品のＳＫＵ数を備える。代替の例示的実施形態では、製品識別情報は、製品を一意的に識別する、いかなる好適な情報をも備えることができる。例えば、製品識別情報は、国際標準図書番号（「ＩＳＢＮ」）などの国際取引商品コード（「ＧＴＩＮ」）、統一商品コード（「ＵＰＣ」）、欧州統一商品番号（「ＥＡＮ」）、日本共通商品コード（「ＪＡＮ」）、ブランド名および型番の組み合わせ、ならびに他の標準的な識別子を含むことができる。代替の例示的実施形態では、製品識別情報は、製品／サービス識別の広いグループ分け（例えば、求める商品／サービスのカテゴリ）を含む。

例示的実施形態では、製品識別情報は、プロキシカード１０５から取得される磁気ストライプ情報の空のトラックの中に挿入される。伝統的に、金融系カードの磁気ストライプ上の少なくとも１つのトラックが、未使用のままである。決済システム１６０が、プロキシカード１０５の発行人として機能するため、磁気ストライプは、磁気ストライプのトラック１および２上に伝統的に記憶されるアカウント情報に加えて、種々の情報を含有するようにフォーマットすることができる。プロキシカードは、情報が商人１１０と決済システム１６０との間を伝送することができる、１つ以上の追加トラックを有するように、フォーマットされてもよい。例示的実施形態では、商人１１０は、クーポン、プリペイド、および他の特典、ならびにお得意様／ポイントプログラムなど、現在の取引に製品別付加価値サービスを適用することを可能にするように、決済要求メッセージの中の空のトラックに、製品識別情報を追加する。代替の例示的実施形態では、製品水準識別情報は、後の取引において使用されるように製品別クーポンおよび特典をユーザ１０１に提供するように使用することができる。

ブロック４１０では、商人１１０は、入手者１４０に決済要求を提示する。例示的実施形態では、商人のＰＯＳ端末１１８は、ネットワーク（図解せず）を介して、入手者１４０に要求を提示する。代替の例示的実施形態では、商人１１０のウェブサイトは、入手者１４０に要求を提示する。

入手者１４０は、ブロック４１５において、カードネットワーク１５０に決済要求を提示する。

ブロック４２０では、カードネットワーク１５０は、取引用の支払いに使用されるアカウント番号が、典型的なカード番号であるかどうかを判定する。例示的実施形態では、カードネットワーク１５０は、プロキシカード１０５のアカウント情報の中にある一連の番号または経路選択情報を使用して、これを自動的に判定する。代替の例示的実施形態では、カードネットワーク１５０は、上記の決済システム１６０によってカードネットワーク１５０に提供された、保存されたアカウント識別情報の一覧を再検討する。

カード番号が典型的なカード番号である場合、決済は、ブロック４２３において、伝統的な決済処理方法に従い処理される。

カード番号が典型的なカード番号でない場合、発行人１７０は、決済システム１６０である（例えば、プロキシカード１０５が取引に使用された場合）。その後、カードネットワーク１５０は、ブロック４２５において、決済要求を決済システム１６０に転送する。

代替の例示的実施形態では、カード番号は、発行人または決済システムを識別する、番号のブロックまたは他の指標など、保存されたアカウント識別情報の一覧に対応する、識別子を備えることができる。この識別子に基づき、識別子が従来の発行人に対応する場合、ブロック４２３で、決済は伝統的な決済処理方法に従って処理され、または識別子が決済システム１６０に対応する場合、ブロック４２５で、決済は決済システム１６０に転送される。

ブロック４２７では、決済システム１６０は随意で、決済要求に挿入された製品識別を読み取る。例示的実施形態では、製品識別情報は上記で商人によって挿入された。例示的実施形態では、製品識別情報は、どの付加価値サービスを現行の取引に適用することができるかを、判定するように使用される。代替の例示的実施形態では、製品識別情報は、どの特典を、将来の取引のためユーザ１０１に提供することができるかを判定するように使用される。

ブロック４３０では、決済システム１６０は、ユーザのプロキシカード１０５のアカウントにアクセスする。ユーザのプロキシカード１０５のアカウントにアクセスするための方法については、図５に記載する方法を参照して、以下でより詳細に記載する。

図５は、例示的実施形態に従い、ユーザのプロキシカードアカウントにアクセスするための方法を描写する、ブロックフロー図である。方法４３０については、図１に図示するコンポーネントを参照して記載する。

ブロック５１０では、決済システム１６０は、プロキシカード１０５の決済要求を、カードネットワーク１５０から受信する。

決済システム１６０は、ブロック５２０において、プロキシカードと関連付けられるユーザ１０１のアカウントを識別する。例示的実施形態では、ユーザ１０１のアカウントは、ユーザ１０１によって定義される静的規則（またはユーザ１０１が既定の規則を修正しなった場合は、規定の規則）、取引に先立って静的規則になされるいかなる修正、および関連付けられた金融アカウントを含有する。例示的実施形態では、決済システム１６０は、取引をどのように進めるかを判定するように、アカウント情報を使用する。

ブロック５３０では、決済システム１６０は、ユーザ１０１が決済規則を定義していたかどうかを判定する。例示的実施形態では、ユーザ１０１は、取引に先立って、静的規則を定義し、および／または規則を修正していた。

ユーザが決済規則を定義していた場合、決済システム１６０は、ブロック５４０において、金融アカウントを取引に適用する順序を判定するように、最初にユーザ定義規則を適用する。例示的実施形態では、決済システム１６０は、最初に取引に先立って、ユーザ１０１によって修正された規則、および第２にユーザ定義の静的規則を適用する。代替の例示的実施形態では、ユーザ１０１は、取引に先立って、規則を修正しなかった。本実施形態では、決済システム１６０は最初に、ユーザ定義の静的規則を適用する。

ブロック５４５では、決済システム１６０は、ユーザ定義規則に基づき取引が拒否されるであろうかどうかを判定する。例えば、ユーザ１０１が、５つ以下の取引が１日の中で発生してもよいという規則を定義しており、これがユーザの６つ目の取引である場合、決済システム１６０は、その取引が拒否されるであろうと判定するであろう。取引が拒否されるであろう場合、方法４３０はブロック８１５に続く（図８）。要求を拒否させることができる他の規則は、詐欺防止規則を含む。例えば、取引が、ユーザ１０１の通常の地理的領域の外側で発生する場合、またはユーザ１０１のアカウント上の活動が、決済システム１６０が定義した取引の金額もしくは回数を超過した場合、決済システム１６０は、決済要求を拒否してもよい。このような詐欺防止規則は、既定の静的規則、もしくはユーザ定義規則、またはそれらの組み合わせの中に含むことができる。

取引が拒否されないであろう場合、方法４３０はブロック４３４に続く（図４）。

ユーザが決済規則を定義していなかった場合、決済システム１６０はブロック５５０に進む。ブロック５５０では、決済システム１６０は、既定の静的決済規則を取引に適用する。

ブロック５５５では、決済システム１６０は、既定の静的規則に基づき取引が拒否されるであろうかどうかを判定する。例えば、ユーザが決済システム１６０でギフトカードのみを登録しており、追加資金が必要である場合、決済システム１６０は、取引が拒否されるであろうと判定するであろう。取引が拒否されるであろう場合、方法４３０はブロック８１５に続く（図８）。

取引が拒否されないであろう場合、方法４３０はブロック４３４に続く（図４）。

ブロック５５５から、方法４３０はブロック４３５に進む（図４）。

図４に戻り、ブロック４３５では、決済システム１６０は、ユーザ１０１が任意のクーポン、バウチャー券、プリペイド特典、償還特典、お得意様／ポイントカード、またはプロキシカード１０５と関連付けられる他の形態の付加価値サービスを有するかどうかを判定する。

決済システム１６０は、ユーザ１０１が利用可能な付加価値サービスを有すると判定する場合、ブロック４３７において、それらの金融アカウントを最初に適用するであろう。例示的実施形態では、決済システム１６０は、種々の形態の付加価値サービスを探し適用する、事前に定義された順序を有するであろう。例えば、決済システム１６０は、最初にバウチャー券、その後クーポン、次いで償還特典、最後に任意の他の形態の登録された付加価値サービスを適用してもよい。付加価値サービスを処理するための方法については、図６に記載する方法を参照して、以下でより詳細に記載する。

図６は、例示的実施形態に従い、付加価値サービスを処理するための方法を描写する、ブロックフロー図である。方法４３７については、図１に図示するコンポーネントを参照して記載する。

ブロック６１０では、ユーザ１０１は、付加価値サービスアカウントをプロキシカード１０５と関連付ける。例示的実施形態では、このステップは、図２の中に記載する登録プロセス中に完了する。代替の例示的実施形態では、ユーザ１０１は、取引前のいつでも、クーポン、お得意様カード、ポイントカード、特典（プリペイド特典を含む）、割引、および他の形態の付加価値サービスを含む、付加価値サービスアカウントをプロキシカードアカウントに追加する。

商人１１０は、ブロック６１５において、決済システム１６０に付加価値サービス割引を随意に提示する。例示的実施形態では、商人、代替的にまたは加えて、製造業者は、決済要求に先立って、ある特定の製品に対する割引、クーポン、および他の形態の付加価値サービスを、決済システム１６０に通知することができる。決済システムは、以下に記載する、ブロック６４５との関連で、記憶もしくは受信された商人および／または製造業者の付加価値サービスに対して、データ記憶ユニット１６７を検索することができる。

ブロック６２０では、決済システム１６０は、決済要求からユーザ識別情報を読み取る。例示的実施形態では、ユーザ識別情報は、プロキシカード１０５のアカウント識別子の中に含有されるか、またはプロキシカード１０５のアカウント識別子によって符号化される。

決済システム１６０は、ブロック６２５において、決済要求から商人１１０の識別情報を読み取る。例示的実施形態では、商人１１０の識別情報は、決済要求の中に含有されるか、または決済要求によって符号化される。

ブロック６３０では、決済システム１６０は、決済要求から製品識別情報を読み取る。例示的実施形態では、製品識別情報は、商人１１０によって決済要求の中に挿入されたＳＫＵ情報である。代替の例示的実施形態では、製品識別情報は、求めるタイプの商品／サービスについての記載である。

決済システム１６０は、ブロック６３５において、プロキシカード１０５と関連付けられた、ユーザ１０１の付加価値サービスにアクセスする。

ブロック６４０では、決済システム１６０は、どの付加価値サービスを適用するか、および／または付加価値サービスを適用する順序を判定する。例示的実施形態では、順序は、ユーザ定義の静的規則、修正されたユーザ定義規則、または既定の静的規則によって定義される。代替の例示的実施形態では、ユーザ１０１は、特定の付加価値サービスに適用されるように、規則を定義することができる。例えば、ユーザ１０１は、クーポンをいつ使うか、または特典をいつ履行するかを規定することができる。これらの規則は、購入閾値（例えば、商人１１０からの１回の購入が＄５０より多い場合、＄１０割引を受ける）、総計購入の閾値（例えば、商人１１０での累積購入額が＄１０００に到達した後、商人１１０から次回の購入で＄１０割引を受ける）、商人１１０からの最低購入回数（例えば、商人１１０からの１０回目の購入の際に＄１０割引を受ける）、時間制限（例えば、昼食時間帯の購入で＄１０割引を受ける）、および／または場所の制限（例えば、特定の商人１１０の場所での購入の際に＄１０割引を受ける）を含むが、それらに限定されない。

ブロック６４５では、決済システム１６０は、ユーザ１０１が、取引向けの保存された特典を有するかどうかを判定する。例示的実施形態では、保存された特典は、クーポン、バウチャー券、店舗のポイント、償還、または他の形態の保存された特典を含むことができるが、それらに限定されない。

ユーザ１０１が、ユーザ１０１によって規定された規則、および特典に対して規定された規則に合致する、取引に対する保存された特典を有する場合、決済システム１６０は、ブロック６５０において、その特典を適用する。例示的実施形態では、決済システム１６０は、その特典に対する発行人１７０として機能し、特典を適用した後、取引の購入価格を調整することができる。

例示的実施形態では、ブロック６４５および６５０はまた、購入取引における商人または特定の製品のＩＤに基づき、購入取引に適用することができる、商人または製造業者によって提供される付加価値サービスを検索することも含む。

ユーザ１０１が、取引用の保存された特典を有さない場合、方法４３７はブロック６５５に進む。

ブロック６５５では、決済システム１６０は、ユーザ１０１が、取引向けのお得意様カードを有するかどうかを判定する。

ユーザ１０１が取引向けのお得意様カードを有する場合、決済システム１６０は、ブロック６６５において、お得意様カードを適用する。例示的実施形態では、決済システム１６０は、そのお得意様カードに対する発行人１７０として機能し、お得意様カードを適用した後、取引の購入価格を調整することができる。代替の例示的実施形態では、お得意様カードは、特典が適用される前に適用される。

ブロック６５５において、ユーザが取引向けのお得意様カードを有さない場合、方法４３７はブロック４４０に進む（図４）。

ブロック６５５から、方法４３７はブロック４４０に進む（図４）。

図４に戻り、ブロック４４０では、決済システム１６０は、ユーザ１０１がギフトカード、プリペイドカード、再ロード可能な取引カード、交換用カード、およびプロキシカード１０５と関連付けられる、他の形態の非信用ベースのバリューカードを含む、ストアードバリューアカウントを有するかどうかを判定するであろう。

決済システム１６０が、ブロック４３５において、ユーザ１０１が利用可能な付加価値サービスを有さないと判定する場合、方法４００は直接ブロック４４０に進むであろう。

ブロック４４３において、決済システム１６０は、ユーザ１０１が利用可能なストアードバリューカードを有すると判定する場合、その金融アカウントを適用するであろう。例示的実施形態では、決済システム１６０は、複数のストアードバリューアカウントが利用可能かどうかを判定し、各金融アカウントを適用するであろう。例示的実施形態では、決済システム１６０は、そのストアードバリューアカウントに対する発行人１７０として機能し、ストアードバリューアカウントを適用した後、取引の購入価格を調整することができる。代替の例示的実施形態では、決済システム１６０は、ストアードバリューアカウントを維持管理する発行人１７０に、新しい決済要求を転送し、取引が承認される場合には、発行人から許可を受信するであろう。

ブロック４４５では、決済システム１６０は、取引のために追加資金が必要とされるかどうかを判定するであろう。例示的実施形態では、決済システム１６０は、追加資金が必要とされるかどうかを判定するために、付加価値サービスおよびストアードバリューアカウントが適用された後に、取引の購入価格を調整するであろう。代替の例示的実施形態では、決済システム１６０は、規則によって定義される通り、付加価値サービスまたはストアードバリューアカウントのみを適用した後に、追加資金が必要とされるかどうかを判定するであろう。別の代替の例示的実施形態では、付加価値サービスおよびストアードバリューアカウントは取引に適用されず、決済システム１６０は自動的にブロック４４５に進む。

決済システム１６０が、ブロック４４０において、ユーザ１０１が利用可能なストアードバリューカードを有さないと判定する場合、方法４００はブロック４４５に進むであろう。

ブロック４４５において、追加資金が取引に対して必要とされない場合、決済システム１６０は、ブロック４４７において、取引を許可するであろう。その後、方法４００はブロック４６０に進むであろう。

ブロック４４５において、追加資金が取引のために必要とされる場合、決済システム１６０は、ブロック４５０において、取引の残余部の資金を調達するように使用される、アカウントの発行人１６０、１７０を判定するであろう。例示的実施形態では、決済システム１６０は、ブロック４５０において、ユーザ１０１が、デビットカード、クレジットカード、またはプロキシカード１０５と関連付けられる、他の形態の信用ベースのアカウントを有するかどうかを判定するであろう。決済システム１６０は、１つ以上のクレジット／デビットカードを選択する規則を、取引に適用するであろう。例示的実施形態では、決済システム１６０は、取引の残余部のために使用される、単一のアカウントを判定するであろう。代替の例示的実施形態では、決済システム１６０は、複数のアカウントが、取引の残余部のために使用されるであろうと判定するであろう。

決済システム１６０がアカウントの発行人である場合、ブロック４５３において、決済システム１６０はアカウント取引を承認または拒否するであろう。例示的実施形態では、決済システム１６０は、十分な資金が利用可能であるかどうか、および／または取引が、取引を完了するために使用される金融アカウントに対する規則に合致するかどうかを判定するであろう。

取引が拒否される場合、方法４００はブロック８１５に進む（図８）。

取引が承認される場合、方法４００はブロック４６５に進む（図４）。

決済システム１６０が、金融アカウントの発行人１７０でない場合、決済システムは、ブロック４５５において、カードネットワーク１５０を介して、各発行人（１７０ａ、１７０ｂなど）に新しい決済要求を送信する。例示的実施形態では、新しい決済要求は、付加価値サービス、ストアードバリューアカウント、および／または異なる発行人１７０によって維持管理される任意の他の金融アカウントを適用した後の、残りの取引残高に対してである。

ブロック４５７では、発行人１７０は、取引を承認または拒否する。

取引が拒否される場合、方法４００はブロック８０５に進む（図８）。

図８は、例示的実施形態に従い、拒否された取引を許可するための方法を描写する、ブロックフロー図である。方法８００については、図１に図示するコンポーネントを参照して記載する。

決済システム１６０が金融アカウントを維持管理する発行人ではない場合（ブロック４５７（図４）参照）、発行人１７０は、ブロック８０５において、カードネットワーク１５０を介して、決済システム１６０に拒否された取引を通知する。

ブロック８１０では、決済システム１６０は、発行人１７０からカードネットワーク１５０を介して、拒否された取引の通知を受信する。

決済システム１６０は、ブロック８１５．において、取引が拒否された理由を判定する。決済システム１６０が、金融アカウントを維持管理する発行人であり（ブロック４５３（図４）またはブロック５４５、５５５（図５）参照）、取引が拒否された場合、決済システム１６０は、取引が拒否された理由を判定する。

ブロック８２０では、決済システム１６０は、取引が１つ以上のユーザ定義規則または他のユーザがオーバーライドできる規則に合致しなかったために、取引が拒否されたのかどうかを判定する。

取引がユーザ定義規則に合致する場合、方法８００はブロック８６０に進む（図８）。

取引がユーザ定義規則に合致しない場合、決済システム１６０は、ブロック８２５において、リアルタイムオーバーライド要求をユーザ１０１に伝達する。例示的実施形態では、オーバーライド要求は、ユーザの携帯デバイス１２０に伝達される。例示的実施形態では、ユーザ１０１は、携帯デバイス１２０のユーザインターフェース１２３を使用して、ユーザ定義規則をオーバーライドするように促される。

ブロック８３０では、ユーザ１０１は、携帯デバイス１２０のユーザインターフェース１２３を使用して、オーバーライド要求に応答する。例示的実施形態では、携帯デバイス１２０は、オーバーライド要求を伝達し、選択に対して利用可能な選択肢を提示するように、ユーザ１０１との情報交換を開始する。例示的実施形態では、アプリケーション１２２が動き、決済システム１６０から受信されたオーバーライド要求を処理し、ユーザインターフェース１２３を介して情報を提示する。アプリケーション１２２は、決済システム１６０から受信された情報、およびアプリケーション１２２の中に記憶された情報に基づき、ユーザ１０１が利用可能な選択肢の一覧を作成してもよい。別の例示的実施形態では、アプリケーション１２２は、利用可能な選択肢に対してユーザ１０１の選択を要求する、一連のプロンプトを作成する。例示的実施形態では、ユーザ応答は随意である。

ユーザ１０１が規則のオーバーライドを許可しない場合、ブロック８３５において、取引は拒否され終了する。

ユーザ１０１がオーバーライドを許可する場合、携帯デバイス１２０は、ブロック８４０において、オーバーライド許可を決済システム１６０に伝達する。

ブロック８４５では、決済システム１６０は、携帯デバイス１２０からオーバーライド許可を受信する。

決済システム１６０は、ブロック８５０において、金融アカウントの発行人１７０を判定する。

決済システム１６０が金融アカウントの発行人である場合、決済システム１６０は、ブロック８５３において取引を許可する。その後、方法８００はブロック４６５に進む（図４）。

決済システム１６０が金融アカウントの発行人でない場合、決済システム１６０は、ブロック８５５において、カードネットワーク１５０を介して発行人１７０に新しい決済要求を送信する。その後、方法８００はブロック４５７に進む（図４）。

取引は拒否されるが、ユーザ定義規則には合致している場合（ブロック８２０（図８）参照）、方法８００はブロック８６０に進む（図８）。

ブロック８６０では、決済システム１６０は、取引が不足金のために拒否されたかどうかを判定する。

取引が不足金のために拒否されたのではなかった場合、取引は終結する。

取引が不足金のために終結した場合、決済システム１６０は、ブロック８６５において、規則をオーバーライドし、異なる金融アカウントを選択するように、ユーザ１０１に要求を伝達する。例示的実施形態では、要求は、ユーザの携帯デバイス１２０に伝達される。例示的実施形態では、ユーザ１０１は、携帯デバイス１２０のユーザインターフェース１２３を使用して、新しいアカウントを選択するように促される。

ブロック８７０では、ユーザ１０１は、携帯デバイス１２０のユーザインターフェース１２３を使用して、要求に応答する。例示的実施形態では、携帯デバイス１２０は、要求を伝達し、選択に対して利用可能な選択肢を提示するように、ユーザ１０１との情報交換を開始する。例示的実施形態では、アプリケーション１２２が動き、決済システム１６０から受信された要求を処理し、ユーザインターフェース１２３を介して情報を提示する。アプリケーション１２２は、決済システム１６０から受信された情報、およびアプリケーション１２２の中に記憶された情報に基づき、ユーザ１０１が利用可能な選択肢の一覧を作成してもよい。別の例示的実施形態では、アプリケーション１２２は、利用可能な選択肢に対してユーザ１０１の選択を要求する、一連のプロンプトを作成する。例示的実施形態では、ユーザ応答は随意である。

ユーザ１０１が異なる金融アカウントを選択しない場合、ブロック８７５において、取引は拒否され終了する。

ユーザ１０１が異なる金融アカウントを選択する場合、携帯デバイス１２０は、ブロック８８０において、決済システム１６０に選択を伝達する。

ブロック８８５では、決済システム１６０は、携帯デバイス１２０から選択を受信する。

決済システム１６０は、ブロック８９０において、金融アカウントの発行人１７０を判定する。

決済システム１６０が金融アカウントの発行人である場合、決済システム１６０は、ブロック８９３において取引を許可する。その後、方法８００はブロック４６５に進む（図４）。

決済システム１６０が金融アカウントの発行人でない場合、決済システム１６０は、ブロック８９７において、カードネットワーク１５０を介して発行人１７０に新しい決済要求を送信する。その後、方法８００はブロック４５７に進む（図４）。

例示的実施形態では、方法８００によって提供されるリアルタイム許可は、決済要求を拒否することと連動して、または決済要求を拒否する代わりに行うことができる。例えば、決済システム１６０が、決済要求を拒否することを判定するか、または発行人１７０から決済要求の拒絶を受信する場合、決済システム１６０は、商人システム１１０に拒否の通知を伝達する。ユーザが、規則をオーバーライドする許可、詐欺防止規則が取引を詐欺の可能性ありと識別したとしても、ユーザは購入するという確認、または異なる金融アカウントの選択を提示した後に、ユーザは、再びプロキシカードを使用することによって、商人との決済取引を即座に再開してもよい。このとき、決済要求を受信すると、決済システム１６０は、決済要求を承認する（または特定の金融アカウントを使用して、決済要求を処理する）であろう。代替的に、決済システム１６０は、通知メッセージをユーザ１０１に伝達し、応答を待ち、かつ商人システム１１０への拒否の通知を発行することなしに、ユーザ１０１の応答を受信した後、決済要求を許可またはさらに処理することができる。

図４に戻って参照すると、取引が承認される場合、発行人１７０は、ブロック４６０において、カードネットワーク１５０を介して、決済システム１６０に許可メッセージを送信する。決済システム１６０が金融アカウントの発行人である場合（ブロック４４７参照）、決済システム１６０は取引の許可を告げる。

ブロック４６５では、決済システム１６０は、許可メッセージを生成し、随意でユーザ識別情報を許可メッセージに追加する。例示的実施形態では、ユーザ１０１の識別情報は、電子メールアドレス、物理アドレス、電話番号、氏名、店の会員番号、または他の形態の識別情報を含んでもよい。例示的実施形態では、ユーザ１０１の識別情報は、特典、クーポン、バウチャー券、広告、または他の形態の償還特典を、ユーザ１０１に送信するように、商人１１０によって使用されてもよい。

ブロック４７０では、決済システム１６０は、将来の取引の際に使用するように、ユーザ１０１に特典を送信する。特典を送信する方法については、図７に記載する方法を参照して、以下でより詳細に記載する。

図７は、例示的実施形態に従い、特典を送信するための方法を描写するブロックフロー図である。方法４７０については、図１に図示するコンポーネントを参照して記載する。

ブロック７１０では、商人１１０は、決済システム１６０に特典を提示する。例示的実施形態では、商人１１０は、顧客が戻ってくるのを促進するように意図した特典を提示する。例えば、商人１１０は、ユーザ１０１の次の取引からある割合を割り引くための、特典を提示してもよい。代替の例示的実施形態では、商人１１０は、取引において購入された製品／サービスに基づき特典を提示する。例えば、商人１１０は、次の訪問の際に履行されるように、同じまたは関連製品の価格を割り引く特典を提示してもよい。例示的実施形態では、特典は、取引より前に提示され、決済システム１６０によってデータ記憶ユニット１６７の中に記憶される。

決済システム１６０は、ブロック７２０において、決済要求の中に商人１１０によって挿入された製品識別情報を読み取る。例示的実施形態では、製品識別情報は製品／サービスのＳＫＵ番号である。

ブロック７３０では、決済システム１６０は、決済要求から商人１１０の識別情報を読み取る。

ブロック７４０では、決済システム１６０は、１つ以上の特典をユーザ１０１に送信することができるかどうかを判定するように、商人１１０の識別情報および製品識別情報を合致させる。例示的実施形態では、特典は、ブロック７１０において、商人によって提示された。代替の例示的実施形態では、特典は、製品識別情報に基づき一般化された特典である（例えば、製造業者のクーポン）。

決済システム１６０は、ブロック７５０において、ユーザ１０１に１つ以上の特典を送信する。例示的実施形態では、特典は、ユーザ１０１の決済システム１６０のアカウントの中に保存され、プロキシカード１５０と関連付けられる。例示的実施形態では、特典の通知は、携帯デバイス、電子メール、ＳＭＳ、テキストメッセージ、またはユーザ１０１によって指定された他の形態の通信方法を介して、ユーザに伝達される。代替の例示的実施形態では、特典は、ユーザ１０１によって指定された通信方法を介して送信される。

ブロック７５０から、方法４７０はブロック４７５に進む（図４）。

図４に戻り、ブロック４７５では、決済システム１６０は、取引許可メッセージをカードネットワーク１５０に転送する。

ブロック４８０では、カードネットワーク１５０は、許可メッセージを入手した人１４０に転送する。

入手者１４０は、ブロック４８５において、許可メッセージを商人１１０に送信する。

ブロック４９０では、商人システム１１０は、決済システム１６０によって決済許可メッセージの中に挿入された、ユーザ１０１の識別情報を随意に読み取る。例示的実施形態では、商人ＰＯＳ端末１１８は、許可メッセージからユーザ１０１の情報を抽出し、後に使用するためにその情報を記憶することができる。例えば、商人は、調査情報のためユーザ１０１に接触するように、お得意様カード情報を転送するように、またはユーザ１０１に他の特典を転送するように、識別情報を使用してもよい。代替の例示的実施形態では、ユーザ識別情報は、プロキシカードの磁気ストライプ上に記憶された、またはそうでなければ、プロキシカードアカウント識別子と関連付けられた、プロキシカードアカウント情報において提供することができる。この場合、端末読み取り装置１１３は、プロキシカード１０５から初期情報を収集する時に、ユーザ情報を読み取る。

ある特定の決済要求に対して各金融アカウントを使用した後、決済システム１６０は、データ記憶ユニット１６７の中で、ユーザ１０１のプロキシカード１０５用の使用した金融アカウントを更新する。例えば、１回限りのクーポン、プリペイドもしくは他の特典、またはお得意様カードが適用される場合、アカウントはその品目の使用を告げるように更新され、そのさらなる使用は許されない。ストアードバリューカードが使用される場合、アカウントは、使用された金額および利用可能である任意の残りの金額を告げるように更新される。デビットカードまたはクレジットカードが使用される場合、アカウントは、利用可能な金額および利用可能である残りの金額を示すように更新される。決済システム１６０はまた、商人によって提供されるお得意様カードまたはポイントカードの金額を増加または減少することができ、将来の使用のために、ロイヤルティまたは他のポイントを蓄積することを可能にする。

概要
ユーザは、本明細書に開示される特徴の動作を制限するか、ないしは別の方法で作用することが許され得る。例えば、ユーザは、あるデータの収集もしくは使用またはある特徴の起動機能を選択するか、または除外する機会を与えられ得る。加えて、ユーザは、その特徴が用いられる様式を変更する機会を与えられる場合があり、ユーザがプライバシーに関する懸念を有し得る状況を含む。個人情報を含む情報の使用に関する方針、および各ユーザがそのような情報の使用に作用し得る様式に関して、ユーザに通知する指示がユーザに提供されてもよい。したがって、情報は、必要に応じて、関連広告、提案、または他の情報の受信を通じて、個人情報またはユーザのＩＤを開示するリスクを冒さずに、ユーザに有益となるように使用され得る。

例示的実施形態のうちの１つ以上は、本明細書に記載および例示される機能を実施するコンピュータプログラムを含んでよく、このコンピュータプログラムは、マシン可読媒体に保存された命令と、命令を実行するプロセッサと、を備えるコンピュータシステム内で実装される。しかしながら、コンピュータプログラミングにおいて例示的実施形態を実装する多くの異なる方法が存在し得ることは明白であるはずであり、例示的実施形態は、任意のコンピュータプログラム命令群に限定されるものとして見なされるべきではない。さらに、熟練したプログラマーであれば、出願文書内の添付のフローチャートおよび関連する説明に基づいて、実施形態を実装するようにそのようなコンピュータプログラムを書くことができるであろう。したがって、特定のプログラムコード命令群の開示は、例示的実施形態を作製および使用する方法を適切に理解するために必要であるとは考えられない。さらに、コンピュータにより行われる動作に対する任意の言及は、複数のコンピュータがその動作を行ってもよいため、単一のコンピュータにより行われるものとして見なされるべきではない。

前述の実施形態に記載される例示的システム、方法、およびブロックは例証であり、代替実施形態では、発明の範囲および趣旨から逸脱することなく、あるブロックが異なる順序で行われるか、互いに平行して行われるか、全体的に省略されるか、および／もしくは異なる例示的方法と組み合わせて行われることができ、ならびに／またはある追加のブロックが行われ得る。したがって、そのような代替実施形態は、本明細書に記載される発明に含まれる。

本発明は、上述される方法および処理機能を行う、コンピュータハードウェアおよびソフトウェアとともに使用され得る。当業者に理解されるように、本明細書に記載されるシステム、方法、および手順は、プログラム可能なコンピュータ、コンピュータ実行可能ソフトウェア、またはデジタル回路において具現化され得る。ソフトウェアは、コンピュータ可読媒体上に保存され得る。例えば、コンピュータ可読媒体は、フロッピー（登録商標）ディスク、ＲＡＭ、ＲＯＭ、ハードディスク、リムーバブル媒体、フラッシュメモリ、メモリスティック、光記録媒体、光磁気記録媒体、ＣＤ−ＲＯＭなどを含み得る。デジタル回路は、集積回路、ゲートアレイ、ビルディングブロックロジック、フィールドプログラマブルゲートアレイ（「ＦＰＧＡ」）などを含み得る。

本発明の特定の実施形態は、詳細に上述されたが、この説明は単に例証を目的とする。例示的実施形態の開示される態様に関する様々な修正、および対応する相当ブロックおよび構成要素は、上述されるものに加えて、以下の請求項に定義される発明の趣旨および範囲から逸脱することなく、当業者により行われ得、その範囲は、そのような修正および相当する構造を包含するように、最も広範囲の解釈に従う。

Claims (26)

1. 拒否された決済アカウント取引のリアルタイム通知を提供するためのコンピュータ実行方法であって：
   決済システムの１つまたは複数のコンピューティングデバイスを使用して、商人のコンピューティングデバイスに関連付けられた商人からユーザによる購入のための、前記商人のコンピューティングデバイスからの第１決済要求を受信する段階であって、前記第１決済要求は、前記ユーザに関連付けられ、前記決済システムによって維持された決済アカウントを識別する情報を含み、前記決済アカウントは、１人または複数の非決済システム発行人によって維持された１つまたは複数の金融アカウントのための情報を含む、段階と；
   前記１つまたは複数のコンピューティングによって、前記決済アカウントのために定義された１つまたは複数の決済規則に少なくとも部分的に基づき前記第１決済要求を処理するために、プロキシアカウントに関連付けられた前記１つまたは複数の金融アカウントのどれを使用するかを選択する段階と；
   前記１つまたは複数のコンピューティングデバイスによって、前記選択された金融アカウントの不足に少なくとも部分的に基づき前記第１決済要求を拒否する段階と；
   前記１つまたは複数のコンピューティングデバイスによって、前記拒否された第１決済要求を前記ユーザに通知する段階であって、前記通知は、選択肢の特定の１つのユーザ選択が前記選択された金融アカウントに関連付けられた前記不足を直ちに解消するように１つまたは複数の選択肢を含む、段階と；
   前記１つまたは複数のコンピューティングデバイスによって、前記ユーザから前記１つまたは複数の選択肢の選択を受信する段階と；
   前記１つまたは複数のコンピューティングデバイスによって、前記受信され選択された選択肢に少なくとも部分的に基づき前記決済アカウントのために定義された前記１つまたは複数の決済規則を更新する段階と；
   前記決済システムの前記１つまたは複数のコンピューティングデバイスを使用して、前記商人のコンピューティングデバイスに関連付けられた前記商人からの前記ユーザによる前記購入のための、前記商人のコンピューティングデバイスからの第２決済要求を受信する段階であって、前記第２決済要求は、前記決済アカウントを識別する情報を含む、段階と；
   前記１つまたは複数のコンピューティングデバイスによって、前記決済アカウントのために定義された前記更新された決済規則に少なくとも部分的に基づき前記第２決済要求を許可する段階と；
   を具備することを特徴とするコンピュータ実行方法。
2. 前記ユーザは、モバイル通信デバイスを介して前記拒否された第１決済要求を通知されることを特徴とする請求項１に記載のコンピュータ実行方法。
3. 前記ユーザは、モバイル通信デバイスを介して前記１つまたは複数の選択肢を選択することを特徴とする請求項１に記載のコンピュータ実行方法。
4. 前記ユーザは、ＰＯＳ端末を介して前記拒否された第１決済要求を通知されることを特徴とする請求項１に記載のコンピュータ実行方法。
5. 前記ユーザは、ＰＯＳ端末を介して前記１つまたは複数の選択肢を選択することを特徴とする請求項１に記載のコンピュータ実行方法。
6. 前記ユーザは、ウェブサイトを介して前記拒否された第１決済要求を通知されることを特徴とする請求項１に記載のコンピュータ実行方法。
7. 前記ユーザは、ウェブサイトを介して前記１つまたは複数の選択肢を選択することを特徴とする請求項１に記載のコンピュータ実行方法。
8. 前記１つまたは複数の選択肢は、代替の金融アカウントの選択を含むことを特徴とする請求項１に記載のコンピュータ実行方法。
9. 前記１つまたは複数の選択肢は、前記第１決済要求が詐欺ではないことを判定するために詐欺検出質問を含むことを特徴とする請求項１に記載のコンピュータ実行方法。
10. コンピュータによって実行される時、拒否された決済アカウント取引のリアルタイム通知をコンピュータによって提供させるコンピュータ読取可能なプログラムコードを有する、非一時的コンピュータ読取可能な媒体上に記録されたコンピュータプログラムであって：
    商人のコンピューティングデバイスに関連付けられた商人からユーザによる購入のための、前記商人のコンピューティングデバイスからの第１決済要求を受信するコンピュータ読取可能なプログラムコードであって、前記第１決済要求は、前記ユーザに関連付けられ、前記決済システムによって維持された決済アカウントを識別する情報を含み、前記決済アカウントは、１人または複数の非決済システム発行人によって維持された１つまたは複数の金融アカウントのための情報を含む、コンピュータ読取可能なプログラムコードと；
    前記決済アカウントのために定義された１つまたは複数の決済規則に少なくとも部分的に基づき前記第１決済要求を処理するために、前記決済アカウントに関連付けられた前記１つまたは複数の金融アカウントのどれを使用するかを選択するコンピュータ読取可能なプログラムコードと；
    前記１つまたは複数の金融アカウントのうち少なくとも１つがそれに関連付けられた不足を有することを判定することに応答して前記第１決済要求を拒否する判定を前記ユーザに通知するコンピュータ読取可能なプログラムコードであって、前記通知は、選択肢の特定の１つのユーザ選択が前記１つまたは複数の金融アカウントのうち少なくとも１つに関連付けられた前記不足を直ちに解消するように１つまたは複数の選択肢を含む、コンピュータ読取可能なプログラムコードと；
    前記ユーザから前記１つまたは複数の選択肢の選択を受信するコンピュータ読取可能なプログラムコードと；
    前記１つまたは複数の選択肢の前記受信された選択に基づき前記決済アカウントのために定義された前記１つまたは複数の決済規則を更新するコンピュータ読取可能なプログラムコードと；
    前記商人のコンピューティングデバイスに関連付けられた前記商人からの前記ユーザによる前記購入のための、前記商人のコンピューティングデバイスからの第２決済要求を受信するコンピュータ読取可能なプログラムコードであって、前記第２決済要求は、前記決済アカウントを識別する情報を含む、コンピュータ読取可能なプログラムコードと；
    を具備することを特徴とするコンピュータプログラム。
11. 前記決済アカウントのために定義された前記更新された決済規則に基づき前記第２決済要求を許可するコンピュータ読取可能なプログラムコードをさらに含むことを特徴とする請求項１０に記載のコンピュータプログラム。
12. 前記ユーザは、モバイル通信デバイスを介して前記拒否された第１決済要求を通知されることを特徴とする請求項１０に記載のコンピュータプログラム。
13. 前記１つまたは複数の選択肢は、代替の金融アカウントを選択することを含むことを特徴とする請求項１０に記載のコンピュータプログラム。
14. 前記ユーザは、ＰＯＳ端末を介して前記拒否された第１決済要求を通知されることを特徴とする請求項１０に記載のコンピュータプログラム。
15. 前記１つまたは複数の選択肢は、前記第１決済要求が詐欺ではないことを判定するために詐欺検出質問を含むことを特徴とする請求項１０に記載のコンピュータプログラム。
16. 前記ユーザは、ウェブサイトを介して前記拒否された第１決済要求を通知されることを特徴とする請求項１０に記載のコンピュータプログラム。
17. 前記ユーザは、ウェブサイトを介して前記１つまたは複数の選択肢を選択することを特徴とする請求項１０に記載のコンピュータプログラム。
18. 拒否された決済アカウント取引のリアルタイム通知を提供するための決済システムであって：
    記憶デバイスと；
    前記記憶デバイスへ通信可能に接続されたプロセッサであって、前記記憶デバイスに記憶され、前記システムに、
    商人のコンピューティングデバイスに関連付けられた商人からユーザによる購入のための、前記商人のコンピューティングデバイスからの第１決済要求を受信する段階であって、前記第１決済要求は、前記ユーザに関連付けられた決済アカウントを識別する情報を含み、前記決済アカウントは、前記システムによって維持され、前記決済アカウントは、１人または複数の非決済システム発行人によって維持された１つまたは複数の金融アカウントに関連付けられた、段階と；
    前記決済アカウントに関連付けられた前記１つまたは複数の金融アカウントのうち少なくとも１つに関連付けられた不足に少なくとも部分的に基づき前記第１決済要求を拒否する段階と；
    前記拒否された第１決済要求を前記ユーザに通知する段階であって、前記通知は、選択肢の特定の１つのユーザ選択が前記決済アカウントに関連付けられた前記１つまたは複数の金融アカウントのうち少なくとも１つに関連付けられた前記不足を解消するように１つまたは複数の選択肢を含む、段階と；
    前記ユーザから前記１つまたは複数の選択肢の選択を受信する段階と；
    前記１つまたは複数の選択肢の前記受信された選択に基づき前記決済アカウントのために定義された１つまたは複数の決済規則を更新する段階と；
    前記商人のコンピューティングデバイスに関連付けられた前記商人からの前記ユーザによる前記購入のための、前記商人のコンピューティングデバイスからの第２決済要求を受信する段階であって、前記第２決済要求は、前記決済アカウントを識別する情報を含む、段階と；
    を行わせるアプリケーションコード命令を実行するプロセッサと；
    を具備することを特徴とする決済システム。
19. 前記プロセッサはさらに、前記決済アカウントのために定義された前記更新された決済規則に基づき前記第２決済要求を前記システムに許可させる記憶リソースに記憶されたアプリケーションコード命令を実行することを特徴とする請求項１８に記載のシステム。
20. 前記ユーザは、モバイル通信デバイスを介して前記拒否された第１決済要求を通知されることを特徴とする請求項１８に記載のシステム。
21. 前記ユーザは、ＰＯＳ端末を介して前記拒否された第１決済要求を通知されることを特徴とする請求項１８に記載のシステム。
22. 前記ユーザは、ＰＯＳ端末を介して前記拒否された第１決済要求の前記通知に応答することを特徴とする請求項１８に記載のシステム。
23. 前記ユーザは、ウェブサイトを介して前記拒否された第１決済要求を通知されることを特徴とする請求項１８に記載のシステム。
24. 前記１つまたは複数の選択肢は、代替の金融アカウントを含むことを特徴とする請求項１６に記載のシステム。
25. 前記１つまたは複数の選択肢は、前記第１決済要求が詐欺ではないことを判定するために詐欺検出質問を含むことを特徴とする請求項１６に記載のシステム。
26. 前記プロセッサはまた、前記決済アカウントのために定義された１つまたは複数の決済規則に少なくとも部分的に基づき前記第１決済要求を処理するために、プロキシアカウントに関連付けられた前記１つまたは複数の金融アカウントのどれを選択するかを前記システムに行わせる記憶リソースに記憶されたアプリケーションコード命令を実行することを特徴とする請求項１６に記載のシステム。

Images