JP2016540326A - 取引の承認におけるリアルタイムリベートの処理のための方法及びシステム - Google Patents

Abstract

リワード口座を用いて資金が提供される支払取引に対するリベートを開始する方法は、口座データエントリを記録することであって、エントリのそれぞれが口座識別子とリワードバランスとを含む、記録することと、小売商を含んだ取引に対する承認要求を受信することであって、承認要求が支払情報と取引量とを含む、受信することと、取引量と少なくとも１つの変換ルールとに基づいて取引リワード値を計算することと、削減量を特定することであって、削減量は、取引リワード値と、口座識別子が支払情報と対応しているデータエントリに含まれるリワードバランスとの少ない方である、特定することと、データエントリに含まれるリワードバランスを、特定された削減量に基づいて更新することと、取引リワード値と削減量と変換ルールとに基づいてリベート量を計算することと、小売商の口座から支払情報に対応する口座へのリベート量に対するリベート要求を送信することと、を含む。

Description

本開示は、リワード口座を用いて資金が提供される支払取引のためのリベートを開始することに関し、特に、リワードバランスに基づく支払取引の処理に続いてリワード口座におけるリベートを自動的に開始することに関する。

使用を増加させるための取り組みとして、多くの支払カードのイッシュアがカード保有者に対して支払カードの使用に対するリワードの提供を提案している。リワードは、キャッシュ又は生産物との引き換え、キャッシュバック、エアラインのマイル、特定のベンダのリワードポイント（トラベルサービス、ホテル、小売商、リテーラ等）、各レベルが相応の恩恵を有し得るアクティビティに基づくリワードレベル、及びその他など、様々な形式でなされ得る。しかしながら、これらの従来のリワードのスキームはしばしば、恩恵を得るためにカード保有者がなすべき相当量の行動を必要とする。更に、カード保有者は典型的に店頭において直接的にリワードの有益な点を享受することができず、代わりに、リワードを引き換え、リワードを受け取り、そしてリワードを使用することを店頭で要求され得る。

店頭におけるリワードの恩恵の回収を簡素化するため、リワードポイントや、特別な支払カードを使用した際の他の恩恵を回収することができるようにする、いくつかのシステム及び方法が開発されてきた。例えば、参照により全体が取り込まれる２００９年９月４日に出願された米国特許公報第2010/0057553号に記載されたシステムは、ポイントのリワードバランスの使用に対してのみ承認される支払カードを使用する。しかしながら、カードがポイントの使用に対してのみ承認されるため、従来の支払取引のためにカードを使用することができずに、特に消費者が複数の支払カードを持ち歩きたくない場合に失望感を与えたり消費者を混乱させたりし得る。従来の支払カードとしての使用とリワードバランスを介した支払とを切り替えるためにカード保有者がトグルし得る、物理的なスイッチが支払カードに含まれた他のシステムが開発されている。しかしながら、この場合もやはり使用の種別を切り替えることを忘れ得る消費者に失望感を与え得る。さらに、２つの支払方法の違いは、結果として、カード保有者がクレジットとリワードバランスの両方を使用して支払うことを不可能にし得る。

従って、カード保有者による介入がなく、リワードバランスを介した部分的な支払を可能にする、従来の支払取引とリワードバランスに対する取引の両方のために使用し得る支払カードを消費者へ提供するための技術的な解決方法が必要である。

本開示は、リワード口座を用いて資金が提供される支払取引のためのリベートを開始するシステムおよび方法についての記載を提供する。

リワード口座を用いて資金が提供される支払取引に対するリベートを開始する方法は、データベースに、複数の口座データエントリを記録することであって、口座データエントリのそれぞれが、少なくとも口座識別子とリワードバランスとを含む消費者リワード口座に関連するデータを含む、記録することと、受信装置によって、小売商を含んだ支払取引に対する承認要求を受信することであって、承認要求が少なくとも支払情報と取引量とを含む、受信することと、処理装置によって、少なくとも取引量と少なくとも１つの変換ルールとに基づいて取引リワード値を計算することと、処理装置によって、削減量を特定することであって、削減量は、取引リワード値と、含まれている口座識別子が支払情報と対応しているデータベース内の特定の口座データエントリに含まれるリワードバランスとの少ない方である、特定することと、データベースにおいて、特定の口座データエントリに含まれるリワードバランスを、特定された削減量に基づいて更新することと、処理装置によって、取引リワード値と特定された削減量と少なくとも１つの変換ルールとに基づいてリベート量を計算することと、送信装置によって、小売商に関連付けられた支払口座から支払情報に対応する支払口座への計算されたリベート量に対するリベート要求を送信することと、を含む。

リワード口座を用いて資金が提供される支払取引に対するリベートを開始するシステムは、データベース、受信装置、処理装置、及び送信装置を含む。データベースは、複数の口座データエントリを記録するように構成され、口座データエントリのそれぞれは、口座識別子とリワードバランスとを少なくとも含む消費者リワード口座に関連するデータを含む。受信装置は、小売商を含んだ支払取引に対する承認要求を受信するように構成され、当該承認要求は、少なくとも支払情報と取引量とを含む。処理装置は、少なくとも取引量と少なくとも１つの変換ルールとに基づいて取引リワード値を計算し、取引リワード値と、含まれている口座識別子が支払情報と対応しているデータベース内の特定の口座データエントリに含まれるリワードバランスとの少ない方である削減量を特定し、データベースにおいて、特定の口座データエントリに含まれるリワードバランスを、特定された削減量に基づいて更新し、取引リワード値と特定された削減量と少なくとも１つの変換ルールとに基づいてリベート量を計算する、ように構成される。送信装置は、小売商に関連付けられた支払口座から支払情報に対応する支払口座への計算されたリベート量に対するリベート要求を送信するように構成される。

本開示の範囲は、添付された図面と共に読む場合に例示的な実施形態についての以下の詳細な記載から最もよく理解される。以下の図が図面に含まれる。
例示的な実施形態に従う、リワード口座を用いて資金が提供される支払取引に対するリベートを開始し処理するシステムを示す高レベルのアーキテクチャである。 例示的な実施形態に従う、支払取引の資金が提供されたリワード口座に対するリベートを開始する図１の処理サーバを示すブロック図である。 例示的な実施形態に従う、リワード口座を用いて資金が提供される支払取引の処理と、リワードバランスに基づいたリワード口座に対するリベートの開始及び処理とに対する処理を示すフローチャートである。 例示的な実施形態に従う、リワード口座を用いて資金が提供される支払取引に続く、図２に示す処理サーバによるリベートを開始する処理を示すフローチャートである。 例示的な実施形態に従う、リワード口座を用いて資金が提供される支払取引に対するリベートを開始する例示的な方法を示すフローチャートである。 例示的な実施形態に従う、コンピュータシステムのアーキテクチャを示すブロック図である。

本開示の適用可能な更なる範囲は、以下に提供される詳細な説明から明らかになる。例示的な実施形態の詳細な説明は、説明の目的のみを意図したものであり、従って必ずしも開示の範囲を制限することを意図したものではない。

用語の定義
支払ネットワーク―現金代替の使用を介して金銭を移動するために利用されるシステム又はネットワーク。支払ネットワークは、取引の様々なタイプに対する金銭の移動を処理するため、様々な異なるプロトコルや手続きを利用し得る。支払ネットワークを介して行われ得る取引は、製品あるいはサービスの購入、クレジット購入、引き落とし取引、資金の移動、口座払い戻しなどを含み得る。支払ネットワークは、支払カードや信用状、小切手、金融勘定などを含み得る現金代替を介して取引を行うよう構成され得る。支払ネットワークとして動作するよう構成されたネットワークあるいはシステムの例は、ＭａｓｔｅｒＣａｒｄ（登録商標）、ＶＩＳＡ（登録商標）、Ｄｉｓｃｏｖｅｒ（登録商標）、Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ（登録商標）、ＰａｙＰａｌ（登録商標）などを含む。ここでの「支払ネットワーク」の語の使用は、エンティティとしての支払ネットワークと、支払ネットワークを含む備品、ハードウェア及びソフトウェアなどの物理的な支払ネットワークの両方を参照し得る。

支払口座―当座預金口座、貯蓄口座、信用口座、仮想支払口座のような取引の資金を供給するために利用され得る金融口座。支払口座は、人や家族、会社、法人、政府エンティティなどを含み得る、エンティティに関連付けられ得る。場合によっては、支払口座は、PayPal（登録商標）などによって運営されるそれら口座のように仮想的であり得る。

支払カード―関連付けられた支払口座を介した金融取引に資金提供するために小売商に提供され得る、支払口座に関連付けられたカード又はデータ。支払カードは、クレジットカード、引き落としカード、チャージカード、ストアドバリューカード、プリペイドカード、フリートカード、仮想支払番号、仮想カード番号、ＣＰＮ（controlled payment numbers）などを含み得る。支払カードは、小売商に提供される物理的なカード、又は（例えばスマートフォン又はコンピュータのような通信装置に蓄積されるような）関連付けられた支払口座を表わすデータであり得る。例えば、場合によっては、支払口座番号を含むデータは、関連付けられた支払口座によって資金が供給される取引の処理のための支払カードとして考慮され得る。場合によっては、小切手は利用可能な支払カードとして考慮され得る。

リワード（Ｒｅｗａｒｄ）口座―取引に資金を提供するために用いられた場合、口座所有者に対するリワードを獲得し得る支払口座。リワードは、ポイント、レベル、キャッシュバック、マイル又は当業者にとって明らかである他の適切な固有の値であり得る。口座所有者によって獲得されるより多くの報酬が結果として増加した（例えばより高くなった）リワードバランスとなり得るように、未払いの報酬の分量はリワードバランスとして参照され得る。ここで使用される「ポイント」は、一般にリワード口座に対するリワードを指し得、「ポイントバランス」は一般にリワード口座に対するリワードバランスを指し得る。

小売商（Ｍｅｒｃｈａｎｔ）―消費者又は他の小売商などの他のエンティティによる購入のための生産物（例えば商品及び／又はサービス）を提供するエンティティ。小売商は、消費者、リテーラー、卸売業者、製造業者、又は当業者に明らかな購入のための生産物を提供する任意の他の種類のエンティティであり得る。場合によっては、小売商は、購入のために提供される商品及び／又はサービスについての専門的な知識を有し得る。他の場合には、小売商は、提供される生産物の特別な知識を有し得ない又は要求し得ない。他の実施形態では、単一の取引に関わるエンティティは小売商として考慮され得る。

イッシュア（Ｉｓｓｕｅｒ）―受取人が有利になる信用状又は与信枠を設定（例えば取引を開始）し、信用状又は与信枠内で特定された量に対する、受取人によって利用される為替手形（ｄｒａｆｔ）を引き受けるエンティティ。多くの場合、イッシュアは、銀行、又は、信用状又は与信枠の取引を開始することを許可された他の金融機関であり得る。場合によっては、受取人に対する与信枠を拡大し得る任意のエンティティがイッシュアとして考慮され得る。イッシュアによって開始された与信枠は支払口座の形式で表され得、支払カードの使用を介して受取人によって利用され得る。

アクワイアラ（Ａｃｑｕｉｒｅｒ）―小売商に代わって支払カードの取引を処理し得るエンティティ。アクワイアラは、銀行、又は、小売商に代わって支払カードの取引を処理することを許可された他の金融機関であり得る。多くの場合、アクワイアラは受取人として振る舞う小売商と与信枠の取引を開始し得る。アクワイアラは、イッシュアによって提供される与信枠の受取人であり得る消費者がアクワイアラによって代表された小売商と支払カードを介して取引する例では、資金をイッシュアと交換し得る。

支払取引―金銭又は他の金銭的な利益が、あるエンティティから他のエンティティに交換される、２つのエンティティの間の取引。支払取引は、商品又はサービスの購入のため、負債の返済のため、又は当業者に明らかな他の金銭的な利益の交換のための資金の移動であり得る。場合によっては、支払取引は、クレジットカードの取引などの支払カード及び／又は支払口座を介して資金を提供する取引を指し得る。このような支払取引は、イッシュア、支払ネットワーク及びアクワイアラを介して処理され得る。支払取引などを処理する処理は、承認（ａｕｔｈｏｒｉｚａｔｉｏｎ）、バッチ処理（ｂａｔｃｈｉｎｇ）、クリアリング（ｃｌｅａｒｉｎｇ）、セトルメント（ｓｅｔｔｌｅｍｅｎｔ）及び資金提供（ｆｕｎｄｉｎｇ）の少なくとも１つを含み得る。承認は、消費者による支払明細の小売商への提供、（例えば支払明細を含む）取引明細の小売商からアクワイアラへの発行、及び、取引に資金を提供するために用いられた消費者の支払口座のイッシュアによる支払明細の検証を含み得る。バッチ処理は、一括処理において、アクワイアラへの配布のために承認された取引を他の承認された取引と共に記録することを指し得る。クリアリングは、バッチ処理された取引をアクワイアラから支払ネットワークへ処理のために送信することを含み得る。セトルメントは、イッシュアの受取人を含んだ取引のために支払ネットワークによるイッシュアの引き落としを含み得る。ある場合には、イッシュアは支払ネットワークを介してアクワイアラへ支払い得る。他の場合には、イッシュアは直接アクワイアラへ支払い得る。資金提供は、クリアリングされ及びセトルメントされた支払取引のための、アクワイアラから小売商への支払を含み得る。注文及び／又は上述したステップのカテゴリ化されたものが、処理される支払取引の一部として実行されることは当業者にとって明らかである。

リワード口座に対するリベート要求を処理するシステム
図１は、リワード口座を用いて資金が提供される支払取引に対するリベートを開始し処理するシステム１００を示している。

システムは消費者１０２を含み得る。消費者１０２は、イッシュア１０４によって保有される、リワードが利用可能な支払口座（例えばリワード口座）を有し得る。ある場合には、イッシュア１０４は、リワード口座を用いて支払口座に資金を提供するために使用するリワード口座に関連付けられた支払カードを消費者１０２に発行する。消費者１０２は、リワード口座によって資金が提供されるように、小売商１０６と支払取引を実行し得る。

小売商１０６（又は小売商１０６と関連付けられたアクワイアラ）は、リワード口座によって資金が提供される支払取引に対する承認要求を、支払ネットワーク１０８へ発行し得る。支払ネットワーク１０８は、当業者に明らかなシステム及び方法を用いて支払取引を処理し得る。処理の一部又は処理の後に、支払ネットワーク１０８は処理サーバ１１０へ承認要求のコピーを送信し得る。処理サーバ１１０へ送信される承認要求は、少なくとも（例えば支払取引に資金を提供するために用いられるリワード口座を示す）支払情報と取引量とを含み得る。

以下により詳細に説明される処理サーバ１１０は、リワードバランスに基づいてリワード口座に対するリベート要求を開始するように構成され得る。処理サーバ１１０は、少なくとも取引の量と少なくとも１つの変換ルールとに基づいて取引リワード値を計算し得る。変換ルールは、小売商１０６、消費者１０２、イッシュア１０４、支払取引に対する取引データ又は任意の他の適切な値に基づき得る。取引リワード値は、リワードを介して支払取引全体に資金を提供するために必要なリワード口座内のリワードの値を表すものであり得る。例えば、取引リワード値は、＄１５０の取引に対して１５０ポイントになるように計算され得る。

処理サーバ１１０はまた、以下により詳細に説明される、消費者１０２に対応する口座データエントリを口座データベース１１２内に記録し得る。口座データエントリは、支払取引に資金を提供するために消費者１０２によって使用されるリワード口座に対するリワードバランスを少なくとも含み得る。ある場合には、処理サーバ１１０は、イッシュア１０４と関連づけられ得、及び／又は、イッシュア１０４から口座情報（例えばリワードバランス）を受信し得る。処理サーバ１１０は、口座データエントリ内に含まれる取引リワード値とリワードバランスとの少ない方に基づく、口座データエントリに対する削減量を特定し得る。このような例では、削減量は、リワードバランスが支払取引に資金を提供するために必要なリワードの量を超えるシナリオ、又は、リワードバランスがリワードの量を超えずに支払取引に部分的に資金を提供するためだけに使用され得るシナリオに対するものであり得る。

処理サーバ１１０はその後、削減量に基づいて消費者１０２に関連付けられた口座データエントリ内のリワードバランスを更新し得る。処理サーバ１１０はまた、削減量と少なくとも１つの変換ルールとに基づいて、支払取引に対するリワード口座上で処理されるべきリベートに対するリベートの量を計算し得る。処理サーバ１１０はその後、換金されたリワードに基づいてリワード口座に対するリベートの量がイッシュア１０４へ支払われるように、リベート要求を支払ネットワーク１０８へ発行し得る。支払ネットワーク１０８は、当業者に明らかなシステム及び方法を用いてリベートを処理し得る。

ある実施形態では、処理サーバ１１０は、支払ネットワーク１０８へリベート要求が成功裏に送信されたことを示す通知を消費者１０２に送信し得る。消費者１０２又は消費者１０２に関連付けられたコンピューティング装置に送信され得るこの通知は、ショートメッセージサービスのメッセージ、マルチメディアサービスのメッセージ、電子メール、従来の郵便、電話、ウェブサイト、アプリケーションプログラム、又は当業者に明らかな任意の他の適切な方法を介して、消費者１０２へ送信され得る。他の実施形態では、処理サーバ１１０は、リベート要求が成功裏に処理されたことを示す他の通知を、リベート要求が成功裏に送信されたことを示す通知に加えて又は代わりに送信し得る。ある実施形態では、処理サーバ１１０はまた、計算された更新済みのリワードバランスに基づくリワード口座の更新を提供するため、イッシュア１０４へ通知を送信し得る。

ある場合には、処理サーバ１１０は、消費者１０２に関連付けられた口座データエントリに対するリワードバランスが取引リワード値より少ない支払取引のための要求を発行するために消費者１０２からの許可を要求し得る。このような例では、処理サーバ１１０は、消費者１０２（例えば、消費者１０２に関連付けられたモバイルコンピューティング装置又は支払取引の行われたＰＯＳ装置等のコンピューティング装置）へ要求を発行し得る。消費者１０２は、要求に応答し得、その応答は処理サーバ１１０によって受信され適切に処理され得る。処理サーバ１１０は、消費者１０２が彼らのリワードバランスを使用することを望む場合に上述したリベート要求を発行し得、又は、消費者１０２が彼らのリワードバランスを使用することを望まない場合に何らの要求も発行しないようにし得る。ある実施形態では、処理サーバ１１０は、リワードバランスの部分的な使用に基づいて、リベート要求を送信するように構成され得る。

ここで説明したシステム及び方法は、リワード口座に対するリワードを用いた支払取引に消費者１０２が資金を提供できるようにする従来型のシステム及び方法に対して、いくつかの改善を提供し得る。処理サーバ１１０は、消費者１０２に第２の支払カードの使用を要求することなく、又は取引を行う前に何らかの動作を起こさせることなく、支払取引の資金の提供に対するリワードバランスを利用し得るため、処理サーバ１１０は、より速くより効率的な、リワードを介した支払取引の資金の提供を提供し得る。結果として、システム１００は、潜在的に消費者により受け入れられ、次に、より高い使用率になり得、消費者１０２及びイッシュア１０４の両方に利益をもたらし得る。

加えて、リベート要求としてリワードの使用を処理することにより、支払取引そのものは既存の支払システムを変更することなく従来的に行われ得る。更に、リベート要求は支払取引に伴う記録を消去するものとして送信され得、結果としてリベート要求の処理が非常に高速になる。このような例では、小売商１０６から支払ネットワーク１０８へ発行された最初の承認要求は、処理サーバ１１０による干渉や介入なしに従来的に発行され得て、これにより従来の処理速度を維持し、リベート要求をクリアリングする速度と結びつく場合にはリワードを用いた支払取引のためのリベートの処理は消費者１０２にとって気づかない遅延になる。

処理装置
図２はシステム１００の処理サーバ１１０の実施形態を説明している。図２で説明される処理サーバ１１０の実施形態は、説明にのみ提供されること、及びここで議論するような機能を実行するために適した処理サーバ１１０の全ての可能性のある構成に対して包括的ではないことは当業者にとって明白である。例えば、図６に示され以下でより詳細に議論されるコンピュータシステム６００は、処理サーバ１１０の適切な構成であり得る。

処理サーバ１１０は受信ユニット２０２を含み得る。受信ユニット２０２は、１つ以上のネットワークプロトコルを介して１つ以上のネットワーク上のデータを受信するように構成され得る。受信ユニット２０２は、リワード口座によって資金が提供される支払取引に対応する支払ネットワーク１０８からの承認要求を受信するように構成され得、この承認要求は少なくとも取引量と支払情報とを含む。支払情報は、口座識別子又は当業者に明らかな他の適切な情報であって、支払取引に資金を提供するために使用されるリワード口座を識別するために用いられ得るもの、を含み得る。

処理サーバ１１０は更に、処理ユニット２０４を含み得る。処理ユニット２０４は、支払取引に資金を提供するために用いられるリワード口座に関連付けられる、口座データベース１１２に記録された口座データエントリ２０８を識別するための支払情報を使用し得る。口座データベース１１２に記録された口座データエントリ２０８のそれぞれは、口座識別子とリワードバランスとを少なくとも含む消費者のリワード口座に関連するデータを含み得る。口座識別子は、識別番号、（関連付けられたリワード口座の）支払口座番号、ユーザ名、電子メールアドレス、電話番号等のような、識別子に用いるユニークな値であり得る。リワードバランスは、リワード口座に関連付けられた消費者１０２によって得られた報酬のバランスであり得る。ある場合には、リワードバランスは、イッシュア１０４から処理サーバ１１０（例えば受信ユニット２０２を介して）によって受信され得る。

処理ユニット２０４は更に、メモリ２１０に記録され得る、少なくとも取引量と１つ以上の変換ルールとに基づいて取引リワード値を計算するように構成され得る。ある場合には、取引リワード値は更に、消費者１０２（例えば消費者１０２の口座レベル）、イッシュア１０４（例えばイッシュアの属性、イッシュアのカテゴリ等）、小売商１０６（例えば小売商の属性、小売商のカテゴリ、小売商の業界等）、承認要求に含まれる取引データ（生産物のデータ、取引時間及び／又は日付、地理的な位置等）、及び当業者に明らかな更なるもの、の少なくとも１つに基づき得る。

処理ユニット２０４はまた、識別された口座データエントリ２０８内に含まれる取引リワード値とリワードバランスとの少ない方であり得る削減量を識別するように構成され得る。処理ユニット２０４はその後、現在のリワードバランスに基づいて識別された口座データエントリ２０８に含まれるリワードバランスを更新し得、識別された削減量と少なくとも１つの変換ルールとに基づいて、リベート量を計算し得る。処理ユニット２０４は、計算したリベート量のリベート要求を生成し得る。例えば、取引量が＄１００であり得、処理ユニット２０４が１００ポイントの取引リワード値を計算し得る。識別された口座データエントリ２０８は、７５ポイントのリワードバランスを含み得る。処理ユニット２０４は従って、リワードバランスをゼロポイントに更新し得る７５ポイントの削減量を識別し、結果として＄７５の計算されたリベート量にし得る。処理ユニット２０４はその後、リワード口座へのＳ７５のリベート要求を生成し得る。

処理サーバ１１０はまた、送信ユニット２０６を含み得る。送信ユニット２０６は、１つ以上のネットワークプロトコルを介して１つ以上のネットワーク上でデータを送信するように構成され得る。送信ユニット２０６は、処理のために支払ネットワーク１０８へ生成されたリベート要求を送信するように構成され得る。送信ユニット２０６はまた、リベート要求が成功裏に送信されたことを示す送信通知を消費者１０２及び／又はイッシュア１０４に送信するように構成され得る。

ある実施形態では、受信ユニット２０２は、リベート要求が成功裏に処理された場合に支払ネットワーク１０８から通知を受信し得る。このような実施形態では、送信ユニット２０６は更に、成功裏の処理を示す通知を、消費者１０２及び／又はイッシュア１０４に送信するように構成され得る。ある場合には、この通知は、リベート要求の成功裏の送信を示す先の通知に加えて又は代わりに送信され得る。

識別された口座データエントリ２０８のリワードバランスが支払取引のリワード値より少なく、かつ、（例えば、識別された口座データエントリ２０８に記録され得る、以前に受信した消費者の属性に基づいて）処理サーバ１１０がリワードを用いた支払取引の部分的な資金の提供に対して消費者１０２の同意を求める実施形態においては、送信ユニット２０６は、消費者１０２に対して、処理を進めるための消費者１０２の許可に対する要求を送信するように構成され得る。この要求は、消費者１０２に関連付けられたコンピューティング装置又は（例えば承認要求に示されるような）支払取引を行うために用いられるＰＯＳ（ｐｏｉｎｔ−ｏｆ−ｓａｌｅ）を介するような、当業者に明らかな適切な方法を用いて消費者１０２に送信され得る。受信ユニット２０２は、消費者１０２から、取引量の部分的な量に対するリベート要求を処理すること又はリベート要求を保留することを示す応答を受信するように構成され得る。処理ユニット２０４は、応答に含まれる表示を識別し得、更に上述のように動作し得る。ある場合には、口座データエントリ２０８は、リワードバランスが計算された取引リワード値より少ない場合に処理ユニット２０４がリベート要求を生成したかを表示し得る。

支払取引の処理及びリベート要求の後の処理
図３は、リワード口座を用いて資金が提供される支払取引の処理と、リワード口座で得たリワードを用いたリベート要求の後の処理とに対するプロセスを示している。

ステップ３０２では、消費者１０２は、リワード口座を用いた商品又はサービスの購入のために小売商１０６との支払取引を開始し得る。支払取引の開始の一部として、消費者１０２は（例えば支払カード又は他の適切な方法を介して）リワード口座の口座番号を小売商１０６に提供し得る。ステップ３０４において、小売商１０６（又は小売商１０６と関連付けられたアクワイアラ）は、承認要求を生成して、承認要求を処理のために支払ネットワーク１０８へ発行し得る。ステップ３０６では、支払ネットワーク１０６は承認要求を、リワード口座のイッシュア１０４へ転送し得る。ステップ３０８においてイッシュア１０８は、支払取引（例えばリワード口座内の適切な資金に基づいて）を承認し得、ステップ３１０において承認を示す承認応答を支払ネットワーク１０８へ返送する。

ステップ３１２では、支払ネットワーク１０８は、支払取引の許可を示す承認応答を小売商１０６へ転送し得る。ステップ３０４から３１２は従来のシステムと方法を用いた支払取引の処理を示すものであり、追加的なステップ及び／又は追加的なエンティティが含まれ得ることは、当業者に明らかである。ステップ３１４では、小売商１０６は消費者１０２に受領を提供し、及び／又は、消費者１０２に商品又はサービスのために取引されたものを提供する。

ステップ３１６では、支払ネットワーク１０８は、少なくとも支払情報と取引量とを含む、支払取引のための承認要求のコピーを処理サーバ１１０へ送信し得る。ステップ３１８では、処理サーバ１１０は、支払取引に資金を提供するために使用されるリワード口座に関連づけられた口座データエントリ２０８を識別し得、更に、支払取引に資金を提供するためにリワードを使用する可能性を、識別された口座データエントリ２０８に含まれるリワードバランスと、取引量と少なくとも１つの変換ルールとに基づいて計算される取引リワード値とに基づいて識別する。消費者１０２が支払取引に全部又は一部の資金を提供するためのリワードの使用を承認することを要求され得る例では、ステップ３２０では、処理サーバ１１０は消費者１０２へ承認要求を発行し得る。

ステップ３２２では、消費者１０２は、コンピューティング装置（例えばモバイルコンピューティング装置、小売商人１０６におけるＰＯＳ（ｐｏｉｎｔ−ｏｆ−ｓａｌｅ）装置、等）又は他の適切な方法を介してポイントの使用を許可し得る。ステップ３２４において、消費者の許可を示す許可応答は、処理サーバ１１０へ送信され得る。ステップ３２６では、処理サーバ１１０はその後、削減量と少なくとも変換ルールとに基づいて、リベート量のためのリベート要求を生成し得る。ステップ３２８では、処理サーバ１１０は支払ネットワーク１０８へリベート要求を送信し得る。

ステップ３３０では、支払ネットワーク１０８は、当業者に明らかである方法及びシステムを用いてリベート要求を処理し得る。リベートは、小売商１０６と関連付けられたアカウントから消費者１０２に関連付けられたリワード口座へ処理され得る。ステップ３３２では、支払ネットワーク１０８は、リベート量に対するリベートが成功裏に処理されたことを示すリベート応答をリワード口座へ送信し得る。ステップ３３４では、処理サーバ１１０は、リベートの成功裏の処理を示す通知を消費者１０２へ送信し得る。ある場合には、この通知は、更新されたリワード量と、当業者に明らかである他の適切な情報とを更に含んでもよい。

リベート要求を生成し開始する方法
図４は、システム１００の処理サーバ１１０を介して実行されるようなリワード口座を用いて資金が提供される支払取引に対するリベートのためのリベート要求を生成し処理する方法を説明している。

ステップ４０２では、処理サーバ１１０の受信ユニット２０２は、リワード口座を用いて資金を提供する支払取引に対する承認要求を受信し得る。承認要求は支払情報と取引量とを少なくとも含み得る。ステップ４０４では、処理サーバ２０４は、支払取引がリワードを用いた支払取引の全部又は部分的な資金の提供に対して有効な取引であるかを判定する。ステップ４０４は、承認要求に含まれる支払情報を用いた、口座データベース１１２に記録された口座データエントリ２０８の識別を含み得る。有効な口座データエントリ２０８が識別されなかった場合、取引は有効なものとして考慮され得ず、処理は終了し得る。

有効な口座データエントリ２０８が識別され、取引がリワードを用いた全部又は部分的な資金の提供であり得る場合、ステップ４０６において、処理ユニット２０４は、支払取引の資金の提供に対して、口座内に十分なリワードバランスがあるかを判定し得る。ステップ４０６は、支払取引に対する取引量と１つ以上の変換ルールとに基づいて取引リワード値を計算することと、識別された口座データエントリ２０８に含まれるリワードバランスが計算された取引リワード値を満たす又は超えるかを識別することとを含み得る。リワードバランスが十分でない場合、ステップ４０８において、処理ユニット２０４は、識別された口座データエントリ２０８に含まれるデータに基づくなど、支払取引の部分的な資金の提供に対するリワード口座に関連付けられた消費者１０２からのデフォルトの許可があるかを判定し得る。

デフォルトの許可が消費者１０２によって提供されたものでない場合、その場合には、ステップ４１０において、処理サーバ１１０の送信ユニット２０６は消費者１０２へ許可要求を送信し得る。ある場合には、許可要求の通信の方法は識別された口座データエントリ２０８に含まれ得る。ステップ４１２では、受信ユニット２０２は、支払取引に部分的に資金を提供するためのリワードの使用を許可又は拒否することを示す、消費者１０２からの応答を受信し得る。ステップ４１４では、処理ユニット２０４は、消費者の応答においてリワードの利用が許可されているかを識別し得る。使用が許可されていない場合、その後処理は完了し得る。

消費者の応答において消費者１０２によって使用が許可されている場合、又は消費者１０２によってデフォルトで使用が許可されている場合、又は支払取引に全ての資金を提供するための十分なリワードバランスがある場合、そのときは、ステップ４１６において処理ユニット２０４は、識別された口座データエントリ２０８におけるリワードバランスから対応するリワード量を差し引き得る。処理ユニット２０４は、ステップ４１８において支払取引のためのリベートを処理し得る。リベートを処理することは、リベートの量を計算することであり得、これは、取引リワード値と、リワード削減量と、変換ルール、計算されたリベート量及び処理のために送信ユニット２０６によって支払ネットワーク１０８へそれらを送信することの少なくとも１つとに基づき得る。ステップ４２０では、送信ユニット２０６は、リベートの処理を示す、消費者１０２へ通知を送信し得る。ある場合には、通知は、削減量、リベート量及び更新されたリベートバランスの少なくとも１つを含み得る。

リワード口座を用いて資金が提供される支払取引に対してリベートを開始する方法
図５は、リワード口座を用いて資金が提供される支払口座に対してリベートを開始する方法５００を示している。

ステップ５０２では、複数の口座データエントリ（例えば口座データエントリ２０８）は、データベース（例えば口座データベース１１２）に記録され得、口座データエントリ２０８のそれぞれは、少なくとも口座の識別子とリワードバランスとを含む消費者のリワード口座に関連するデータを含む。ステップ５０４では、小売商（小売商１０６）を含んだ支払取引に対する承認要求を受信装置（例えば受信ユニット２０２）によって受信し得、この承認要求は少なくとも支払情報と取引量とを含む。ステップ５０６では、取引リワード値が、少なくとも取引量と少なくとも１つの変換ルールとに基づいて、処理装置（例えば処理ユニット２０４）によって計算され得る。ある実施形態では、少なくとも１つの変換ルールは、小売商１０６、取引量、口座レベル及び小売商のカテゴリの少なくとも１つに関連付けられる。

ステップ５０８では、削減量が処理装置２０４によって特定され得、この削減量は取引リワード値と、含まれる口座識別子が支払情報と対応しているデータベース１１２内の特定の口座データエントリ２０８に含まれるリワードバランスとの少ない方である。ある実施形態では、口座データエントリ２０８のそれぞれは更に、リワードバランスが計算された取引リワード値よりも少ない場合に、対応するリワードバランスが使用されるべきかの指示を含み得る。ある実施形態では、承認要求に含まれる支払情報は、特定の口座データエントリ２０８に含まれる口座識別子を含み得る。

ステップ５１０では、特定の口座データエントリ２０８に含まれるリワードバランスは、データベース１１２において、識別された削減量に基づいて更新され得る。ステップ５１２では、リベート量は、取引リワード値、識別された削減量及び少なくとも１つの変換ルールに基づいて、処理装置２０４によって計算され得る。ステップ５１４において、小売商１０６に関連付けられた支払口座から承認要求に含まれた支払情報に対応する支払口座への計算されたリベート量に対するリベート要求が、送信装置（例えば送信ユニット２０６）によって送信され得る。ある実施形態では、リベート要求は支払ネットワーク（例えば支払ネットワーク１０８）へ送信され得る。

ある実施形態では、方法５００は更に、リベート要求が成功裏に送信されたことを示す通知を、特定の口座データエントリ２０８と関連付けられた消費者（例えば消費者１０２）に対して、送信装置２０６によって送信することを更に含み得る。他の実施形態において、方法５００は更に、送信されたリベート要求に応答してリベートが成功裏に処理されたことの表示を受信装置２０２によって受信することと、特定された口座データエントリに関連付けられた消費者１０２へ、成功裏にリベートが処理されたことを示す通知を送信装置２０６によって送信することとを含み得る。

ある実施形態では、方法５００は更に、リワードバランスが取引リワード値より少ない場合、リベート要求の送信前に、リベート要求の送信へ進むための指示を、受信装置２０２によって受信することを含み得る。更なる実施形態では、この進むための指示は、特定の口座データエントリ２０８に関連付けられたコンピューティング装置へ、進むための要求を送信装置２０６によって送信したことに応答して受信され得る。更なる実施形態では、この進むための要求は、特定の口座データエントリ２０８内に含まれるリワードバランスを少なくとも含み、ショートメッセージサービスのメッセージ、マルチメディアメッセージサービスのメッセージ、電子メール、及び支払取引と関連付けられたＰＯＳ（ｐｏｉｎｔ−ｏｆ−ｓａｌｅ）装置への送信の少なくとも１つを介して送信され得る。

コンピュータシステムアーキテクチャ
図６は、本開示に係る実施形態又はその一部がコンピュータ可読コードとして実装され得るコンピュータシステム６００を説明している。例えば、図１の処理サーバ１１０は、コンピュータシステム６００においてハードウェア、ソフトウェア、ファームウェア、格納された命令を有するコンピュータ可読メディア又はこれらの組み合わせを用いて実装され得、１つ以上のコンピュータシステム又は他の処理システムを用いて実装され得る。ハードウェア、ソフトウェア又は任意のそれらの組み合わせは、図３‐５の方法を実装するために使用されるモジュールおよびコンポーネントを具体化し得る。

プログラム可能な論理が使用される場合、そのような論理は商業上利用可能な処理プラットフォーム又は特別な目的の装置上で実行され得る。当業者は、開示された主題の実施形態がマルチコアマルチプロセッサシステム、ミニコンピュータ、メインフレームコンピュータ、仮想的に任意の装置に組み込まれた普及又は小規模のコンピュータと同様に、分散された機能によりリンク又はクラスタ化されたコンピュータを含む様々なコンピュータシステムの構成において実施できることを理解し得る。例えば、少なくとも１つのプロセッサ装置およびメモリは、上述の実施形態を実装するのに使用され得る。

ここで論じられるようなプロセッサユニット又はプロセッサ装置は、１つのプロセッサ、複数個のプロセッサもしくはそれらの組み合わせである。プロセッサ装置は１つ以上の処理の“コア”を有し得る。ここで論じられるような“コンピュータプログラムメディア”、“固定のコンピュータ可読メディア”および“コンピュータ使用可能なメディア”という言葉は、一般的にリムーバブルストレージユニット６１８、リムーバブルストレージユニット６２２およびハードディスクドライブ６１２にインストールされたハードディスクのような有形のメディアを参照するのに使用される。

本開示に係る様々な実施形態は、このコンピュータシステム６００の例に関して記述される。この記述を読むと、当業者には他のコンピュータシステムおよび／あるいはコンピュータアーキテクチャを用いて本開示をどのように実装するかは明らかになる。操作が連続的な処理として記述され得るにも関わらず、いくつかの操作は実際には平行し、同時に、および／あるいは分散された環境で、そしてシングルもしくはマルチプロセッサマシンによってアクセスするためのローカルもしくはリモートに格納されたプログラムコードを伴って実行され得る。加えて、ある実施形態では、操作の順序は、開示された主題要素の概念から逸脱することなく再構成され得る。

プロセッサ装置６０４は、特別な目的もしくは一般的な目的のプロセッサ装置であり得る。プロセッサ装置６０４は、バス、メッセージキュー、ネットワーク、マルチコアメッセージ通過スキームなどの通信基盤６０６接続され得る。ネットワークは、ここに開示された機能を実行するために適したあらゆるネットワークであり、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、ワイヤレスネットワーク（例えばＷｉＦｉ）、移動通信ネットワーク、衛星ネットワーク、インターネット、光ファイバ、同軸ケーブル、赤外線、無線周波数（ＲＦ）又はあらゆるこれらの組み合わせを含み得る。他の適したネットワークタイプおよび構成は、当業者に明白だろう。コンピュータシステム６００はまた、メインメモリ６０８（例えばランダムアクセスメモリ、読み出し専用のメモリなど）を含み、また補助メモリ６１０を含み得る。補助メモリ６１０は、フロッピーディスクドライブ、磁気型ドライブ、光ディスクドライブ、フラッシュメモリなどのような、ハードディスクドライブ６１２、リムーバブルストレージデバイス６１４を含み得る。

リムーバブルストレージドライブ６１４は、周知の方法でリムーバブルストレージユニット６１８から読み込みおよび／あるいは書き込みをし得る。リムーバブルストレージユニット６１８は、リムーバブルストレージドライブ６１４によって読み込みおよび書き込みするリムーバブルストレージメディアを含み得る。例えば、もしリムーバブルストレージドライブ６１４がフロッピーディスクドライブであるならば、リムーバブルストレージユニット６１８は、フロッピーディスクであり得る。ある実施形態では、リムーバブルストレージユニット６１８は、固定コンピュータ可読記憶メディアであり得る。

ある実施形態では、補助メモリ６１０は、例えばリムーバブルストレージユニット６２２およびインターフェース６２０のような、コンピュータシステム６００内にコンピュータプログラム又は他の命令を読み込ませる選択的な手段を含み得る。これら手段の例は、（例えば、ビデオゲームシステムにみられるような）プログラムカートリッジおよびカートリッジインターフェース、取り外し可能なメモリチップ（例えばＥＥＰＲＯＭ、ＰＲＯＭなど）および関連したソケット、並びに他のリムーバブルストレージユニット６２２、並びに関連技術の当業者に明白であるようなインターフェース６２０を含み得る。

コンピュータシステム６００（例えばメインメモリ６０８および／あるいは補助メモリ６１０）に格納されたデータは、光ストレージ（例えば、コンパクトディスク、デジタル万能ディスク、ブルーレイディスクなど）又は磁気型ストレージ（例えばハードディスクドライブ）のような、あらゆる種類の適切なコンピュータ可読メディアに格納され得る。データは、関連データベース、構造化問い合わせ言語（ＳＱＬ）データベース、分散データベース、オブジェクトデータベースなどのような、あらゆる種類適切なデータベース構成に構成され得る。適切な構成およびストレージの種類は、当業者に明白だろう。

コンピュータシステム６００はまた、通信インターフェース６２４を含み得る。通信インターフェース６２４は、ソフトウェアおよびデータがコンピュータシステム６００と外部のデバイスとの間で伝送されるように構成され得る。代表的な通信インターフェース６２４は、モデム、ネットワークインターフェース（例えばイーサネットカード）、通信ポート、ＰＣＭＣＩＡスロットおよびカードなどを含み得る。ソフトウェアおよび通信インターフェース６２４を介して伝送されたデータは、当業者に明白となる電気的、電磁的、光学的、もしくは他の信号の形式であり得る。信号は、信号を運ぶよう構成された通信パス６２６を経由して移動し、ワイヤ、光ファイバ、電話回線、携帯電話リンク、無線周波数リンクなどを用いて実装され得る。

コンピュータプログラムメディアおよびメディア使用可能なコンピュータは、メモリ半導体（例えばＤＲＡＭｓなど）であるメインメモリ６０８および補助メモリ６１０のようなメモリを参照し得る。これらコンピュータプログラム製品は、ソフトウェアをコンピュータシステム６００に提供するための手段でありうる。コンピュータプログラム（例えばコンピュータ制御ロジック）は、メインメモリ６０８および／あるいは補助メモリ６１０に格納され得る。コンピュータプログラムはまた、通信インターフェース６２４を介して受信され得る。そのようなコンピュータプログラムは、処理するときに、コンピュータシステム６００にここで記述した本方法を実装することを可能にし得る。特に、コンピュータプログラムは、処理するときに、プロセッサデバイス６０４にここで記述されるような図３−５で示される手法を実装することを可能にする。従って、そのようなコンピュータプログラムは、コンピュータシステム６００の制御を意味し得る。現在開示されているものがソフトウェアを用いて実装される場合、ソフトウェアは、コンピュータプログラム製品に格納され、リムーバブルストレージドライブ６１４、インターフェース６２０、ハードディスクドライブ６１２もしくは通信インターフェース６２４を用いてコンピュータシステム６００に読み込まれ得る。

本開示と一貫した技術は、他の特徴、リワード口座を用いて資金を提供する支払取引のためのリベートを開始するシステムおよび方法を提供する。開示されたシステムおよび方法の様々な代表的な実施形態について上述したが、それらは例示の目的のみのために提示され、限定ではないことが理解されるべきである。それは排他的でなく、示された正確な形式に開示内容を限定するものではない。変更および変形は、上記教示の観点で可能であり、スコープから逸脱することなく公開内容の実施から得られ得る。

Claims (20)

1. リワード口座を用いて資金が提供される支払取引に対するリベートを開始する方法であって、
   データベースに、複数の口座データエントリを記録することであって、口座データエントリのそれぞれは、少なくとも口座識別子とリワードバランスとを含む消費者リワード口座に関連するデータを含む、前記記録することと、
   受信装置によって、小売商を含んだ支払取引に対する承認要求を受信することであって、前記承認要求は、少なくとも支払情報と取引量とを含む、前記受信することと、
   処理装置によって、少なくとも前記取引量と少なくとも１つの変換ルールとに基づいて取引リワード値を計算することと、
   前記処理装置によって、削減量を特定することであって、前記削減量は、前記取引リワード値と、前記含まれている口座識別子が前記支払情報と対応している前記データベース内の特定の口座データエントリに含まれる前記リワードバランスとの少ない方である、前記特定することと、
   前記データベースにおいて、前記特定の口座データエントリに含まれる前記リワードバランスを、前記特定された削減量に基づいて更新することと、
   前記処理装置によって、前記取引リワード値と前記特定された削減量と少なくとも１つの変換ルールとに基づいてリベート量を計算することと、
   送信装置によって、前記小売商に関連付けられた支払口座から前記支払情報に対応する支払口座への前記計算されたリベート量に対するリベート要求を送信することと、を含むことを特徴とする方法。
2. 前記送信装置によって、前記リベート要求が成功裏に送信されたことを示す通知を、前記特定の口座データエントリに関連付けられた消費者へ送信することを含む、ことを特徴とする請求項１に記載の方法。
3. 口座データエントリのそれぞれは更に、前記リワードバランスが前記計算された取引リワード値よりも少ない場合に、前記対応するリワードバランスが使用されるべきかの指示を含む、ことを特徴とする請求項１に記載の方法。
4. 前記少なくとも１つの変換ルールは、前記小売商、前記取引量、口座レベル及び小売商のカテゴリの少なくとも１つに関連付けられる、ことを特徴とする請求項１に記載の方法。
5. 前記リワードバランスが前記取引リワード値より少ない場合、前記方法は更に、
   前記受信装置によって、前記リベート要求を前記送信することの前に、前記リベート要求を送信することへ進むための指示を受信する、ことを含む、ことを特徴とする請求項１に記載の方法。
6. 前記進むための指示は、前記特定の口座データエントリに関連付けられたコンピューティング装置へ、進むための要求を前記送信装置によって送信したことに応じて受信される、ことを特徴とする請求項５に記載の方法。
7. 前記進むための要求は、前記特定の口座データエントリに含まれる前記リワードバランスを少なくとも含み、ショートメッセージサービスのメッセージ、マルチメディアメッセージサービスのメッセージ、電子メール、及び前記支払取引と関連付けられた販売用リワード装置への送信の少なくとも１つを介して送信される、ことを特徴とする請求項６に記載の方法。
8. 前記支払情報は、前記特定の口座データエントリに含まれる前記口座識別子を含む、ことを特徴とする請求項１に記載の方法。
9. 前記リベート要求は、支払ネットワークへ送信される、ことを特徴とする請求項１に記載の方法。
10. 前記受信装置によって、前記送信されたリベート要求に応じて、リベートの成功裏の処理の表示を受信することと、
    前記送信装置によって、前記リベートの前記成功裏の処理を示す通知を、前記特定の口座データエントリに関連付けられた消費者へ送信することを更に含む、ことを特徴とする請求項１に記載の方法。
11. リワード口座を用いて資金が提供される支払取引に対するリベートを開始するシステムであって、
    複数の口座データエントリを記録するように構成されたデータベースであって、口座データエントリのそれぞれは、少なくとも口座識別子とリワードバランスとを含む消費者リワード口座に関連するデータを含む、前記データベースと、
    小売商を含んだ支払取引に対する承認要求を受信するように構成された受信装置であって、前記承認要求は、少なくとも支払情報と取引量とを含む、前記受信装置と、
    処理装置であって、
    少なくとも前記取引量と少なくとも１つの変換ルールとに基づいて取引リワード値を計算し、
    前記取引リワード値と、前記含まれている口座識別子が前記支払情報と対応している前記データベース内の特定の口座データエントリに含まれる前記リワードバランスとの少ない方である削減量を特定し、
    前記データベースにおいて、前記特定の口座データエントリに含まれる前記リワードバランスを、前記特定された削減量に基づいて更新し、
    前記取引リワード値と前記特定された削減量と少なくとも１つの変換ルールとに基づいてリベート量を計算する、ように構成された前記処理装置と、
    前記小売商に関連付けられた支払口座から前記支払情報に対応する支払口座への前記計算されたリベート量に対するリベート要求を送信するように構成された送信装置と、を含むことを特徴とするシステム。
12. 前記送信装置は更に、前記リベート要求が成功裏に送信されたことを示す通知を、前記特定の口座データエントリに関連付けられた消費者へ送信するように構成される、ことを特徴とする請求項１１に記載のシステム。
13. 口座データエントリのそれぞれは更に、前記リワードバランスが前記計算された取引リワード値よりも少ない場合に、前記対応するリワードバランスが使用されるべきかの指示を含む、ことを特徴とする請求項１１に記載のシステム。
14. 前記少なくとも１つの変換ルールは、前記小売商、前記取引量、口座レベル及び小売商のカテゴリの少なくとも１つに関連付けられる、ことを特徴とする請求項１１に記載のシステム。
15. 前記受信装置は更に、前記リワードバランスが前記取引リワード値より少ない場合に、前記リベート要求を送信する前に、前記リベート要求を送信することへ進むための指示を受信するように構成される、ことを特徴とする請求項１１に記載のシステム。
16. 前記進むための指示は、前記特定の口座データエントリに関連付けられたコンピューティング装置へ、進むための要求を前記送信装置によって送信したことに応じて受信される、ことを特徴とする請求項１５に記載のシステム。
17. 前記進むための要求は、前記特定の口座データエントリに含まれる前記リワードバランスを少なくとも含み、ショートメッセージサービスのメッセージ、マルチメディアメッセージサービスのメッセージ、電子メール、及び前記支払取引と関連付けられた販売用リワード装置への送信の少なくとも１つを介して送信される、ことを特徴とする請求項１６に記載のシステム。
18. 前記支払情報は、前記特定の口座データエントリに含まれる前記口座識別子を含む、ことを特徴とする請求項１１に記載のシステム。
19. 前記リベート要求は、支払ネットワークへ送信される、ことを特徴とする請求項１１に記載のシステム。
20. 前記受信装置は更に、前記送信されたリベート要求に応じて、リベートの成功裏の処理の表示を受信するように構成され、
    前記送信装置は更に、前記リベートの前記成功裏の処理を示す通知を、前記特定の口座データエントリに関連付けられた消費者へ送信するように構成される、ことを特徴とする請求項１１に記載のシステム。

Images