JP2022002132A - ユーザ制御リアルタイムデータ処理のための技術 - Google Patents

Abstract

【課題】消費者を報酬プログラムに関連付けるように自動化した方法及びシステムを提供する。【解決手段】方法は、処理デバイスを使用して消費者に請求書を提供することと、消費者に関する支払い情報を受信することと、消費者に関するバイオグラフィック情報を受信することと、報酬プログラムに関連するユーザアカウントに関する情報を更新することと、を含む。支払いを処理し、報酬プログラム情報を更新するソフトウェアは、消費者に提供される一組の商品又はサービスのための請求書を生成し、消費者からの支払い方法を受信し、支払い方法に関連付けられたアカウントを判定し、アカウントに関連する報酬プログラム情報を更新する命令セットを含む。報酬プログラムに関連する償還を容易にする方法は、消費者の購入に関連する請求書を受け取ることと、消費者から支払い情報を受信することと、償還残高の少なくとも一部を請求書に適用することと、を含む。【選択図】図６

Description

本出願は、２０１３年６月２５日に提出された米国特許出願第１３／９２７，０４６号、発明の名称「Automated Payment, Reward Program Enrollment, and Redemption」の一部継続出願として２０１６年３月２日に出願された米国特許出願第１５／０４９，２７５号の優先権を主張し、これらの文献の全体は、参照により本明細書に援用される。

技術分野
本文書は、リアルタイムデータ処理に関し、詳しくは、リアルタイムデータ処理のためのクライアント−サーバ技術に関する。

近年の無線通信の進歩とコンピューティングデバイスの小型化に伴い、ユーザは、場所や時間を問わず、インターネットに接続されたデバイスを使用できるようになっている。単に娯楽やソーシャルネットワーキングを目的とするのではなく、生産性向上のためのツールとして、ユビキタスなインターネット接続性を利用することも望まれている。

多くの業者、例えば、小売業者、レストラン、自動車サービス業者等のサービスプロバイダ、オンライン商取引サイト（又は「ｅコマース」サイト、モバイルデバイスコマースユーティリティ（又は「ｍコマース」ユーティリティ）等）は、様々なロイヤルティ又は報酬プログラム（例えば、「登録カード」技術）を提供でき、これにより（例えば、様々なアイテム及び／又はアイテムのタイプに費やされた金額に関連する「ポイント」を集計することによって）報酬措置（reward measures）を算出でき、消費者は、報酬措置を適用して（例えば、ポイントの「償還残高」を使用して）商品を購入し、又はキャッシュバック報酬を受け取ることができる。多くの場合、消費者は、業者への支払い時に（例えば、店舗で会計を行うとき、レストランの勘定書を支払っているとき等に）このようなプログラムに参加するよう求められる。ユーザは、プログラムに参加する場合、通常、書式、用紙又はオンラインに必要事項を記入し、店舗スタッフからの一連の質問に答え、及び／又は業者に登録情報を提供するための他のタスクを実行する必要がある。

参加後、ユーザは、ロイヤルティプログラムに登録するために、通常、メンバカード（又は電話番号等のアカウントに関連付けられたコード）を提示する必要がある。更に、既存のユーザは、報酬を償還するために、追加のステップを実行する必要がある（例えば、登録カードを使用して、幾らかの報酬残高によって請求額を減額し、クレジットカードを使用して、残りの金額を別途支払う）。

レストラン、食料品店等の企業のインターネット接続は、単にクレジットカード認証のために銀行サーバにダイヤルアップするのみでなく、様々なサービスプロバイダのサーバを含むインターネットへの高帯域幅アクセスを行えるようになっている。更に、多くの企業が利用者に無線インターネットアクセスを提供し始めており、これは、利用者が代金を支払い、メニューを選択及び注文することを便利にするワイヤレスデバイスを含む。一部の発明者は、このようなインターネット技術の進歩の有用性を認識し始めている。

Ｐｏｓｔｒｅｌの米国特許第７，７６９，６３０号（以下、「Ｐｏｓｔｒｅｌ」）は、業者取引（merchant transactions）に基づいて報酬を発行、集約、償還するためのものである。Ｐｏｓｔｒｅｌでは、ユーザであるカード所有者が、カード発行者によって事前に登録されているクレジットカードを用いてオンラインで買い物をする。ユーザ登録は、通常、事前に行われ、Ｐｏｓｔｒｅｌは、実店舗でのカード登録の技術を提供していない。

Ｈｏｆｅｒらによる米国特許出願第２０１２／００４１８０８号（以下、「Ｈｏｆｅｒ」）は、既存の、発行者が資金を提供した、非金銭的な報酬を小売店舗で使用できる通貨に変換するシステムを開示している。しかしながら、Ｈｏｆｅｒは、販売時点（point-of-sale）においてリアルタイムで自動化されたプログラム登録を行う技術を提供していない。

Ｕｎｄｅｒｈｉｌｌによる米国特許出願第２００７／０２８８３１１号（以下、「Ｕｎｄｅｒｈｉｌｌ」）は、販売組織における柔軟なインセンティブプログラムのための方法を開示している。Ｕｎｄｅｒｈｉｌｌの技術は、サプライヤ製品を購入する他の事業者を囲い込むために、サプライヤが使用するように特化された企業間のＷｅｂベースのインセンティブプログラムである。この登録技術は、プログラムに登録できる既存顧客へのアウトバウンド電子メールを使用する。したがって、Ｕｎｄｅｒｈｉｌｌのシステムは、ユーザによる販売時点におけるリアルタイムの意思決定のための技術を提供していない。

Ｍａｔｔｈｅｗｓらによる米国特許出願第２００７／００８３４４４号（「Ｍａｔｔｈｅｗｓ」）は、オンライン取引で支払われる取引アカウントの自動調整のための技術を開示している。Ｍａｔｔｈｅｗｓは、実店舗をバックエンド取引コンピュータに接続する技術を提供していない。

Ｔａｙｌｏｒらによる米国特許出願第２０１２／０１０１８８１号（以下「Ｔａｙｌｏｒ（Ｔａｙｌｏｒ）」）は、消費者の信用情報（consumer credentials）と消費者の加入情報（consumer opt-ins）を金融取引に変換することによって、消費者を囲い込み、償還のアウトプットを提供する方法を開示している。しかしながら、Ｔａｙｌｏｒのシステムのユーザは、使用前にクレジットカードを登録する必要があり、すなわち、この登録は、リアルタイムではなく、販売時点では行われない。

ＬａＰｏｒｔｅらによる米国特許出願第２０１１／０３０７３１８号（以下、「ＬａＰｏｒｔｅ（ＬａＰｏｒｔｅ）」）は、取引からコードが生成されるモバイル小売ロイヤリティネットワークを開示している。顧客は、コードをスキャン／撮影しこれを販売時点外で、ロイヤルティサーバに送信する。したがって、ＬａＰｏｒｔｅでは、ユーザがモバイルデバイスを所有し、ロイヤルティプログラムに事前に登録する必要がある。したがって、ＬａＰｏｒｔｅの技術は、リアルタイムの販売時点ソリューション（point-of-sale solution）を提供していない。

Ｖｏｌｔｍｅｒらの米国特許出願第２００７／０１１２６３２号（以下、「Ｖｏｌｔｍｅｒ」）は、ネットワーク化されたロイヤルティプログラムのためのシステムを開示している。Ｖｏｌｔｍｅｒは、小売業者が報酬機能に直接参加することなく、ネットワーク全体のレベルで消費者が報酬を獲得する技術を開示している。これは、消費者のクレジットカード、デビットカードアカウント、及び／又は銀行アカウント等の特定の支払い手段に消費者ＩＤを関連付けることによって達成される。しかしながら、Ｖｏｌｔｍｅｒは、リアルタイムの販売時点ソリューションを提供していない。

したがって、クレジットカードの取引を可能にするハンドヘルドデバイス（例えば、ＶｅｒｉＦｏｎｅデバイス）等のデータ処理端末を含む現在のＰＯＳ（point-of-sale）デバイス技術の限界を克服するソリューションが望まれている。

幾つかの実施形態は、消費者が商品やサービスの支払いを行う際に、報酬プログラム又はロイヤルティプログラムにおいて、新しいメンバを効率的に登録する（又は既存のメンバ情報を更新する）方法を提供する。報酬プログラムは、業者又は業者の集合体に関連付けることができる。

消費者が（例えば、クレジットカードをスワイプすることによって）商品又はサービスの支払いを開始すると、幾つかの実施形態では、（例えば、スワイプされたクレジットカードから情報を検索することによって）消費者に関する情報を自動的に収集し、デジタル登録フォームの様々なフィールド（例えば、氏名、クレジットカード番号等）に事前に入力を行ってもよい。

幾つかの実施形態では、追加の情報（例えば、電子メールアドレス、電話番号、ユーザ設定等）を手動で収集してもよい。収集された情報を使用して、報酬プログラムに消費者を登録し、消費者によって使用された支払い方法を報酬アカウントに自動的に関連付けてもよい。その後、消費者が、報酬プログラムに関連付けられた業者に対し同じ支払い方法を使用する際、幾つかの実施形態では、状況に応じて、ユーザの報酬情報を自動的に更新及び／又は適用してもよい。同様に、消費者が（最初の報酬プログラムに登録した後）、異なる報酬プログラムに関連する異なる業者において同じ支払い方法を使用した場合、必要な登録情報は、既存のアカウントから自動的に取得され、新しい報酬アカウントに適用される。

幾つかの実施形態では、「請求」に関する情報（領収書、発注書、請求書、オンラインショッピングカート又は会計情報、及び／又は購入に関連する他の適切な情報源に関連する情報を含むことができる。）を収集及び／又は生成する。このような情報は、商品及び／又はサービスのリスト、各リストアイテムに関連付けられた料金等を含むことができる。幾つかの実施形態では、この情報は、様々な報酬ルール（例えば、報酬のカテゴリ、報酬率等）に関連付けてもよく、及び／又は他の情報（例えば、支払い方法、業者の場所、ＳＫＵ、又は在庫保管ユニット番号等）に関連付けてもよい。

幾つかの実施形態では、受け取った支払い情報に基づいて、報酬残高（又はその一部）を請求に適用して自動的に償還してもよい。このような報酬の償還は、少なくとも部分的に様々な適切な要因（例えば、累積ポイント、請求金額、購入のタイプ、ユーザの好み又は選択等）に基づいて行うことができる。

請求、登録、償還、及び／又は幾つかの実施形態に関連する他の動作のそれぞれに関連する情報を収集し、様々な当事者に提供してもよい。このような情報は、様々な適切な時点で、様々な適切な手法で（例えば、ウェブベースのダッシュボードを介して、１又は複数のアプリケーションプログラミングインタフェース（ＡＰＩ）を介して）収集してもよい。

例示的な一実施形態は、消費者を報酬プログラムに関連付けるように適合された自動化された方法を提供する。この方法は、処理デバイスを使用して消費者に請求書を提供することと、消費者に関する支払い情報を受信することと、消費者に関するバイオグラフィック情報を受信することと、報酬プログラムに関連するユーザアカウントに関する情報を更新することとを含む。

第２の例示的な実施形態は、支払いを処理し、報酬プログラム情報を更新するように構成されたソフトウェアアプリケーションを提供する。このソフトウェアアプリケーションは、消費者に提供される一組の商品又はサービスのための請求書を生成し、消費者からの支払い方法を受信し、支払い方法に関連付けられたユーザアカウントを判定し、ユーザアカウントに関連する報酬プログラム情報を更新する命令セットを含む。

第３の例示的な実施形態は、報酬プログラムに関連する償還を容易にする自動化された方法を提供する。この方法は、支払い処理デバイスにおいて、消費者の購入に関連する請求書を受け取ることと、消費者から支払い情報を受信することと、償還残高を含む、消費者に関連するユーザアカウント情報を検索することと、償還残高の少なくとも一部を請求書に自動的に適用することと、受け取った支払い情報を処理して、請求書の残りの部分を決済することとを含む。

以上の要約は、ここに開示する技術の幾つかの実施形態を簡単に紹介することを意図している。これは、本文書で開示される全ての発明主題の紹介又は概要を示すものではない。以下の詳細な説明、及び詳細な説明で参照される図面（又は「図」）は、発明の概要に記載した実施形態及び他の実施形態を更に記述する。したがって、本明細書に記載された全ての実施形態を理解するためには、概要、詳細な説明及び図面を完全に検討する必要がある。更に、特許請求される主題は、他の特定の形態でも具現化できるため、特許請求される主題は、概要、詳細な説明及び図面の例示的な詳細によって限定されるものではなく、特許請求の範囲によって定義される。

ここに開示する技術の新規な特徴は、添付の特許請求の範囲に記載されている。しかしながら、説明のために、幾つかの実施形態を以下の図面に示す。

幾つかの実施形態によって使用される概念的システムの概略的なブロック図である。

図１のシステムの幾つかの実施形態によって使用される概念的ソフトウェアアーキテクチャの概略的なブロック図である。

幾つかの実施形態によって提供される概念的なクライアント側ソフトウェアアプリケーションの概略的なブロック図である。

幾つかの実施形態によって提供される概念的なサーバ側ソフトウェアアプリケーションの概略的なブロック図である。

幾つかの実施形態によって使用される概念的なデータ構造のデータ構造図である。

幾つかの実施形態によって支払い及び／又は登録を容易にするために使用される概念的プロセスのフローチャートである。

幾つかの実施形態によって新しいメンバの登録を実行するために使用される概念的プロセスのフローチャートである。

幾つかの実施形態によって償還を適用するために使用される概念的プロセスのフローチャートである。

幾つかの実施形態によって既存のメンバに関連する情報を更新するために使用される概念的プロセスのフローチャートである。

幾つかの実施形態によって取引後のマーケティングを最適化するために使用される概念的プロセスのフローチャートである。

幾つかの実施形態によって分析データをサードパーティに提供するために使用される概念的プロセスのフローチャートである。

幾つかの実施形態によって支払い及び／又は登録を容易にするために使用される概念的な通信プロトコルのメッセージフロー図である。

幾つかの実施形態によって提供される１又は複数のプログラムにユーザが参加することを可能にする、幾つかの実施形態によって提供される様々なグラフィカルユーザインタフェース（ＧＵＩ）及び関連するサブエレメントを示す図である。

幾つかの実施形態を実装できるコンピュータシステムの概略的なブロック図である。

データ処理のための例示的なコンピュータネットワークのブロック図である。

データ処理のためのコンピュータネットワークの別の例のブロック図である。

データ処理システムで交換されるメッセージの例を示す図である。

以下の詳細な説明では、多くの詳細、実施例、及び実施形態を記述及び説明する。なお、実施形態は、ここに記述する実施形態に限定されず、説明された特定の詳細及び実施例の一部を用いずに実施できることは、当業者には明らかである。

以下のセクションでは、幾つかのより詳細な実施形態を説明する。セクションＩでは、幾つかの実施形態によって使用されるシステムアーキテクチャを概念的に説明する。セクションＩＩでは、幾つかの実施形態によって使用される概念的ソフトウェアアーキテクチャを説明する。次に、セクションＩＩＩでは、幾つかの実施形態によって使用される様々な動作方法を説明する。セクションＩＶでは、幾つかの実施形態によって提供される様々な例示的なＧＵＩ要素を説明する。最後に、セクションＶでは、幾つかの実施形態を実装するコンピュータシステムの一例を説明する。

Ｉ．システムアーキテクチャ
図１は、幾つかの実施形態によって使用される概念的なシステム１００の概略的なブロック図を示している。具体的には、この図は、システム要素間の様々な通信経路を示している。この図に示すように、システムは、それぞれが１又は複数のクライアントデバイス１２０及びローカルサーバ１３０に関連付けられた１又は複数の業者１１０と、一組のストレージ１５０に関連付けられた少なくとも１つのリモートサーバ１４０と、一組のストレージ１７０に関連付けられたサードパーティサーバ１６０と、１又は複数のネットワーク１８０とを含む。

各業者１１０は、単一のエンティティ（例えば、レストラン、小売店、飛行機、電車等）に関連付けられた物理的（及び／又は仮想的）デバイスの集合であってもよい。各クライアントデバイス１２０は、支払い情報を受け取って処理できる電子デバイス（例えば、スマートフォン又はタブレットのようなモバイルデバイス、レジスタ又は端末等のＰＯＳデバイス、専用のクレジットカードスワイプ装置等）であってもよく、特定の業者１１０に関連付けることができる。各ローカルサーバ１３０は、特定の業者に関連付けられた様々なクライアントデバイス１２０とインタラクトできる電子デバイス（例えば、コンピュータ、ネットワークインタフェース等）であってもよい。幾つかの実施形態では、ローカルサーバ１３０は、クライアントデバイス１２０の機能を提供でき、関連するクライアントデバイスなしで動作できるものであってもよい。各ローカルサーバ１３０は、１又は複数のネットワークにアクセスできる。幾つかの実施形態では、クライアントデバイス１２０は、ローカルサーバなしで動作できる（例えば、クライアントデバイスは、１又は複数のネットワークに直接アクセスでき、及び／又はローカルサーバ１３０に関連する他の機能を実行できる）。

リモートサーバ１４０は、各業者１１０とインタラクトできる一組のデバイス（例えば、１又は複数のコンピュータ）を含むことができる。リモートサーバ１４０は、一組のローカルストレージ１５０にアクセスでき、各ストレージは、データ及び／又は命令を格納（及び／又は検索）できる。リモートサーバ１４０及びストレージ１５０は、（例えば、相互に確立されたプロトコルを介して、第１のエンティティによって提供されるソフトウェアを使用して）業者１１０とインタラクトできる第１のエンティティに関連付けてもよい。このような第１のエンティティは、業者１１０及び／又は適切なサードパーティ間でインタラクトすることによって支払い及び登録、償還、及び／又は他の適切なプロセスを実行してもよい。

サードパーティサーバ１６０は、システム１００によってアクセス可能な一組のデバイスを含むことができる。サードパーティのサーバ１６０は、一組のローカルストレージ１７０にアクセスでき、各ストレージは、サードパーティシステムに関連付けられたデータ及び／又は命令を格納（及び／又は検索）できる。サードパーティサーバ１６０及び／又はストレージ１７０は、様々なサードパーティエンティティ（例えば、マーケティングシステム、データマイニングシステム、支払い処理システム等）に関連付けることができる。このようないわゆるサードパーティエンティティは、１又は複数の業者１１０に関連するエンティティ（例えば、複数のフランチャイジーを有する地域のレストランチェーン、複数の店舗ロケーションを有する小売業者等）を含むことができる。

一組のネットワーク１８０は、システム１００の様々な要素によってアクセスされる様々なローカルネットワーク及び／又は分散ネットワーク（例えば、イーサネット(登録商標)、無線ローカルエリア又は「Ｗｉ−Ｆｉ」ネットワーク、インターネット、セルラー通信ネットワーク等）を含むことができる。幾つかの実施形態では、一組のネットワーク１８０は、様々なデバイス（図示せず）及び／又は他の下位要素、例えば、１又は複数のネットワーク、デバイス等の間のインタラクションを可能にできるサーバ、ストレージ、インタフェース等を含むことができる。

システム１００の動作については、セクションＩＩＩでより詳細に説明する。

システム１００が様々な異なる手法で実現できることは、当業者にとって明らかである。例えば、異なる特定の要素を追加してもよく、省略してもよい。別の例として、異なる通信経路を使用してもよい。更に別の例として、様々な単一要素を複数の要素に分割してもよく、及び／又は複数の要素を単一の要素に統合してもよい。

包括的に言えば、報酬プログラムは、有用であるが、登録、使用、及び報酬の償還が煩雑である。ロイヤルティプログラムは、通常、頻度、ポイント、マイル又はキャッシュバックに基づいている。プログラムを管理するために、プロバイダは、クローズドループ型のロイヤルティカード、電話番号、電子メール、携帯電話アプリケーション、又は登録されたクレジットカードを使用する。全ての場合において、最初に顧客を登録することは、煩雑である。顧客は、アカウントを作成するために、通常、複数のステップを経なければならず、これがアカウント作成の妨げになっている。消費者が実際に加入しても、消費者は、支払い資格情報に加えて、プログラムの資格情報を提示する必要があるが、これは、覚えておくことが難しい場合もあるため、これも、プログラムを使用する際の障害となっている。資格情報を提示し忘れるか及び／又はレジ担当者が資格情報の提示を求めなかったために、顧客が購入の際にクレジットを「獲得」できないことが一度でもあると、プログラムに対する顧客の評価は急激に低下する。

今日の技術の世界では、顧客囲い込み（loyalty）がより簡単になると考える者もいる。これは、登録カードロイヤルティプログラムが普及しているためである。顧客は、登録されたクレジットカードで簡単に支払いを行い、報酬を得る。登録カードプログラムは、カード中心（card-centric）又は販売業者中心（merchant centric）のいずれかである。カード中心のアプローチは、クレジットカード発行者及びカード発行者と取引を行うロイヤルティネットワークから構成される。販売業者中心のプログラムは、店舗内マーケティングとインセンティブによって、より組織的に店舗の顧客を囲い込もうとするものであるが、特に即時的な報酬を即座に顧客に与えなければ、成約が困難である。

カード中心のプログラムでは、発行者がプログラムに多数のカードを登録していても、加盟店において、登録されたカードをスワイプするカード所有者は非常に少ないことがあり、この理由は、主に、どの販売業者がプログラムに参加しているのかカード所有者が知らないためである。これにより、取引あたりの支払額と、訪問頻度について、販売業者レベルでの顧客パフォーマンスが低下する。

販売業者中心のアプローチでは、潜在的なメンバが少なくなる可能性があるが、消費者は、店舗で登録を行い、報酬が受けられることを知っているため、意図的に支払いを行い、したがって、取引あたりの平均支払い額は、多くの場合、非メンバの取引あたりの平均支払い額より３０％以上高くなる。

ここに開示する実施形態は、特に、例えば、クレジットカードに配置されたチップ又は磁気ストリップ等の安全なメモリロケーションからデータを取得し、電子メール入力を受信し、ユーザからオプトインコマンドを取得し、受信した情報を使用してコンピュータ取引を処理するために使用できるコンピュータ技術を提供する。

したがって、ここに開示する技術は、一側面において、単に通信を容易にするだけでなく、ＰＯＳデバイス等のユーザデバイスのデータ入力作業を改善する。

ここに開示する幾つかの実施形態では、カードをスワイプした後、クレジットカードの認証が行われる前にコンピュータ処理を開始する。ソフトウェアコードは、クレジットカード取引の既存のコード内に様々な手法で埋め込んでもよく、これにより、既存のクレジットカード認証プロセスを中断又は一時停止して、顧客の資格を確認するための認証の取得の手続きが開始される。取引に関わるエンティティの少なくとも１つ（例えば、支払いデバイス、発行者ネットワーク、ゲートウェイプロバイダ又は支払いアプリケーション自体）がカードデータを暗号化し、一意のＩＤを生成する。ソフトウェアをインストールする前に、エンティティの希望に応じて暗号化を行う当事者が決定される。

一意のＩＤは、店舗毎に異なっていてもよい。例えば、店舗Ａにおいて、同じ１６桁のカードに一意のＩＤが割り当てられ、これは、販売業者Ｂにおいて、同じ１６桁のカードを使用して作成された一意のＩＤと同じであっても異なっていてもよい。一意のＩＤは、取引のコンテキスト内においてのみ存在してもよく、したがって、有効な期間が限定的であってもよい。暗号化は、一方向暗号化であってもよく、すなわち、逆算によってカードの実際の数列を知ることはできないものであってもよい。

ＩＩ．例示的なソフトウェアアーキテクチャ
サブセクションＩＩ．Ａでは、幾つかの実施形態によって提供される概念的ソフトウェアシステムを説明する。次に、サブセクションＩＩ．Ｂでは、幾つかの実施形態によって提供されるクライアント側アプリケーションについて説明する。次に、サブセクションＩＩ．０では、幾つかの実施形態によって提供されるサーバ側アプリケーションについて説明する。最後に、サブセクションＭＤでは、幾つかの実施形態によって使用される概念的なデータ構造を説明する。

Ａ．システムレベルの例
図２は、システム１００及び／又は他のシステムの幾つかの実施形態によって使用される概念的ソフトウェアアーキテクチャ２００の概略的なブロック図を示している。具体的には、この図は、システム１００のコンポーネントがインタラクトすることを可能にする様々な概念的ソフトウェア要素を示している。図示のように、ソフトウェアアーキテクチャ２００は、１又は複数のクライアント側アプリケーション２１０、一組のＰＯＳソフトウェア要素２２０、１又は複数のサーバ側アプリケーション２３０、一組のサーバデータベース２４０、１又は複数のサーバＡＰＩ２５０、一組のサードパーティアプリケーション２６０、一組のサードパーティデータベース２７０、１又は複数のサードパーティＡＰＩ２８０、及び一組のネットワーク要素２９０を含む。

クライアント側アプリケーション２１０は、クライアントデバイス（例えば、上述したクライアントデバイス１２０）によって実行されるように構成してもよく、これにより、クライアントデバイスが様々なシステム機能を実行できるようにしてもよい。クライアント側アプリケーション２１０は、１又は複数のユーザ（例えば、レジ担当者、サーバ、消費者等）から情報を受信し、ローカルサーバ（例えば、上述したローカルサーバ１３０）上で動作するＰＯＳソフトウェアと通信し、１又は複数のユーザ及び／又は消費者に情報（例えば、領収書、フォーム情報等）を提供し、及び／又は他の適切な機能を実行してもよい。

ＰＯＳソフトウェア２２０は、ローカルサーバ又は他の適切なデバイス（例えば、上述したローカルサーバ１３０）によって実行されるように構成してもよく、これにより、ローカルサーバが様々なシステム機能を実行できるようにしてもよい。ＰＯＳソフトウェア２２０は、１又は複数のユーザ（例えば、レジ担当者、サーバ等）及び／又は一組のクライアント側アプリケーションから情報を受信し、１又は複数のネットワーク（例えば、上述のネットワーク１８０）に参加する１又は複数のネットワーク通信要素２９０を介して通信し、１又は複数のユーザ及び／又は消費者に情報（例えば、領収書、フォーム情報等）を提供し、及び／又は他の適切な機能（例えば、支払い情報の受信、領収書の生成等）を実行できる。

サーバ側アプリケーション２３０は、リモートサーバ又は他の適切なデバイス（例えば、上述のリモートサーバ１４０）によって実行されるように構成してもよく、これにより、遠隔サーバに様々なシステム機能を実行させるようにしてもよい。サーバ側アプリケーション２３０は、複数組のクライアント側アプリケーション（各組は業者に関連付けてもよい）と通信し、１又は複数のネットワーク（例えば、上述のネットワーク１８０）に参加する１又は複数のネットワーク通信要素２９０を介して通信し、及び／又は他の適切な機能を実行してもよい。幾つかの実施形態では、サーバ側アプリケーション２３０は、クライアント側のアプリケーションの動作を駆動できるプラグインとして実現してもよく、及び／又は適切なＰＯＳソフトウェアに統合してもよい。

データベース２４０は、幾つかの実施形態によって、適切なストレージ（例えば、上述したストレージ１５０）を用いて保存されるデータを含むことができる。このようなデータは、例えば、１又は複数の業者又は業者の組に関連するデータ、様々な消費者に関連するデータ（例えば、参加業者での購入に関する情報、ロイヤルティアカウント情報、支払い方法情報等）、及び／又は他の適切なデータを含むことができる。データベース２４０は、状況に応じて、サーバ側アプリケーション２３０を介してアクセスしてもよく、１又は複数のＡＰＩ２５０を介してアクセスしてもよい。このようなＡＰＩにより、様々な外部エンティティ（例えば、サードパーティ解析業者、顧客業者等）が様々なデータベース２４０に格納されたデータにアクセスできるようにしてもよい。

サードパーティアプリケーション２６０は、サードパーティサーバ又は他の適切なデバイス（例えば、上述したサードパーティサーバ１６０）によって実行されるように構成してもよく、これにより、サードパーティサーバが幾つかの実施形態のシステムとインタラクトできるようにしてもよい。サードパーティアプリケーション２３０は、複数組のクライアント側アプリケーション（各組は業者に関連付けてもよい）と通信し、１又は複数のネットワーク（例えば、上述のネットワーク１８０）に参加する１又は複数のネットワーク通信要素２９０を介して通信し、及び／又は他の適切な機能を実行してもよい。

データベース２７０は、幾つかの実施形態によって、適切なストレージ（例えば、上述したストレージ１７０）を用いて保存されるデータを含むことができる。このようなデータは、例えば、１又は複数のサードパーティ（例えば、支払い処理エンティティ、リサーチ業者等）に関連するデータ及び／又は他のタイプのデータを含むことができる。データベース２７０は、状況に応じて、サードパーティアプリケーション２６０を介してアクセスしてもよく、１又は複数のＡＰＩ２８０を介してアクセスしてもよい。このようなＡＰＩにより、様々な外部エンティティ（例えば、サーバ側アプリケーション２３０、クライアント側アプリケーション、ＰＯＳソフトウェア等）がデータベース２７０に格納された様々なデータにアクセスできるようにしてもよい。

ネットワーク通信要素２９０は、様々なインタフェース、プロトコル等を含むことができ、これらにより、様々なソフトウェアコンポーネント（及び／又は関連するシステム要素）が互いに通信できるようにしてもよい。

別のネットワーク構成１５００を示す図１５Ａには、通信ネットワーク１５０４を介して、取引プロセッサ１５０６及び登録サーバ１５０８と通信するクライアントデバイス１５０２が示されている。これらのデバイスの幾つかの特徴は、本明細書に記載されている。

アーキテクチャ２００を様々な異なる手法で実現できることは、当業者にとって明らかである。例えば、異なる特定の要素を追加してもよく、何らかの要素を省略してもよい。別の例として、異なる通信経路を使用してもよい。更に別の例として、様々な単一要素を複数の要素に分割してもよく、及び／又は複数の要素を単一の要素に統合してもよい。

Ｂ．クライアント側の例示的な実施形態
図３は、幾つかの実施形態によって提供される概念的なクライアント側ソフトウェアアプリケーション３００（例えば、上述したクライアント側アプリケーション２１０）の概略的なブロック図である。図示のように、アプリケーション３００は、ユーザインタフェース（ＵＩ）モジュール３１０、通信モジュール３２０、支払いモジュール３３０、デバイス制御モジュール３４０、ローカルストレージモジュール３５０、及び報酬モジュール３６０を含むことができる。

ＵＩモジュール３１０は、様々なユーザインタフェース要素を生成するように、及び／又は様々なユーザ入力を処理するように構成してもよい。このようなＵＩモジュールにより、例えば、ユーザは、タッチスクリーンを介して情報を入力でき、この情報は、次にクライアント側アプリケーションによって収集される。

通信モジュール３２０により、クライアント側アプリケーション３００の他の要素は、様々な外部アプリケーション（例えば、一組のネットワークインタフェースを介してアクセスされるサーバ側アプリケーション、ローカルネットワークを介してアクセスされるローカルサーバ等）とインタラクトできる。

支払いモジュール３３０は、（例えば、スワイプされたクレジットカード情報を受信することによって、又は消費者が入力した支払い情報を受け取ることによって）支払い情報を収集する等、支払い処理に関連する様々な機能を提供するように構成してもよい。

デバイス制御モジュール３４０は、クライアント側アプリケーション３００が様々なクライアントデバイスコンポーネントと適切にインタラクトできるようにできるように構成してもよい。例えば、幾つかの実施形態では、デバイス制御モジュール３４０により、アプリケーション３００は、デバイスに関連するタッチスクリーン要素を制御できる。別の例として、様々な指示、書式等を表示するようにＰＯＳ端末に指示してもよい。

ローカルストレージモジュール３５０は、クライアント側アプリケーション３００がクライアントデバイスに関連するローカルストレージにアクセスすることを可能にするように構成してもよい。

報酬モジュール３６０は、様々なリモートサーバ、ローカルサーバ、及び／又はサードパーティのコンポーネントとインタラクトして、報酬情報を収集、分析、及び／又は配布してもよい。このような情報は、ロイヤルティ又は報酬プログラムに関連付けてもよく、更にこれらは、１又は複数の業者に関連付けてもよい。

アプリケーション３００を様々な異なる手法で実現できることは、当業者にとって明らかである。例えば、異なる特定の要素を追加してもよく、何らかの要素を省略してもよい。別の例として、異なる通信経路を使用してもよい。更に別の例として、様々な単一要素を複数の要素に分割してもよく、及び／又は複数の要素を単一の要素に統合してもよい。

Ｃ．サーバ側の例示的な実施形態
図４は、幾つかの実施形態によって提供される概念的なサーバ側ソフトウェアアプリケーション４００（例えば、上述のサーバ側アプリケーション２３０）の概略的なブロック図を示している。図示のように、アプリケーションは、サードパーティアクセスモジュール４１０、通信モジュール４２０、支払い処理モジュール４３０、ルールエンジン４４０、ストレージアクセスモジュール４５０、及び報酬処理モジュール４６０を含むことができる。

サードパーティアクセスモジュール４１０により、システム４００は、様々なサードパーティアプリケーションとインタラクトできる。このようなモジュール４１０は、１又は複数のＡＰＩを含むことができる。

通信モジュールにより、サーバ側アプリケーション４００の他の要素は、様々な外部アプリケーション（例えば、一組のネットワークインタフェースを介してアクセスされるクライアント側アプリケーション、サードパーティのアプリケーション等）とインタラクトできる。

支払い処理モジュール４３０は、（例えば、クライアント側アプリケーションから情報を受信することによって）支払い情報を収集し、サードパーティの支払い処理プロセッサに提出するために情報をフォーマット化し、及び／又は支払プロセッサから受信した一組の応答を解釈する等、支払い処理に関連する様々な機能を提供するように構成してもよい。

ルールエンジン４４０は、一連のプログラム評価基準に関連して消費者情報を評価し、消費者（及び／又はサードパーティ）のインタラクトに基づいて適切な一連のアクションを生成するように構成してもよい。例えば、幾つかの報酬プログラムは、初回の顧客にボーナス報酬を提供してもよい。別の例として、幾つかの報酬プログラムは、消費者行動の評価に基づいて、様々な販促資料を提供してもよい。

ストレージアクセスモジュール４５０は、サーバ側アプリケーション４００がサーバに関連するローカルストレージ（例えば、上述のストレージ１５０）にアクセスすることを可能にするように構成してもよい。

報酬処理モジュール４６０は、様々なクライアントデバイス、リモートサーバ、及び／又はサードパーティのコンポーネントとインタラクトし、報酬情報を収集、分析、及び／又は配布するように構成してもよい。このような情報は、ロイヤルティ又は報酬プログラムに関連付けてもよく、更にこれらは、１又は複数の業者に関連付けてもよい。

アプリケーション４００を様々な異なる手法で実現できることは、当業者にとって明らかである。例えば、異なる特定の要素を追加してもよく、何らかの要素を省略してもよい。別の例として、異なる通信経路を使用してもよい。更に別の例として、様々な単一要素を複数の要素に分割してもよく、及び／又は複数の要素を単一の要素に統合してもよい。

Ｄ．例示的なデータ構造
図５は、幾つかの実施形態によって使用される概念的データ構造５００のデータ構造図を示している。図２〜図４を参照して上述したソフトウェアアプリケーションによってこのようなデータ構造を使用してもよい。図５に示すように、データ構造５００は、メンバアカウント５１０及びサードパーティ情報５２０を含むことができる。

メンバアカウント要素５１０は、報酬プログラムに登録した特定のユーザ（又は家族、企業等の一組のユーザ）に関連付けてもよい。メンバアカウントは、支払い方法５３０（例えば、クレジットカード情報、オンライン支払いアカウント情報等）、及びユーザに関するバイオグラフィック情報５４０（例えば、氏名、電子メールアドレス等）を含むことができる。取引履歴５５０は、報酬プログラムに関連付けられているユーザと業者との間の以前のインタラクトに関連する情報を含むことができる。

サードパーティ情報５２０は、特定のサードパーティ（例えば、業者又は業者のグループ、支払い処理サービス等）を含むことができる。サードパーティ情報要素は、バイオグラフィック情報５６０（例えば、業者の名称、報酬プログラムの種類等）、一組のルール５７０（例えば、消費者にオファーを送るための基準、ユーザに報酬を生成するための基準等）、テンプレートセット５８０（例えば、フォーム、プロモーション電子メールテンプレート等）を含むことができる。サードパーティ情報５２０は、幾つかの実施形態のシステムによって収集、更新、及び／又は他の手法で維持してもよい（例えば、ルールの各セットは、業者に関連付け、システムによって維持してもよい）。

データ構造５００が本質的に概念的であることは、当業者にとって明らかであり、異なる実施形態では、様々な異なる手法でデータ構造を実現できる。例えば、幾つかの実施形態では、追加の特定の要素及び／又は下位要素を追加してもよく、及び／又は特定の要素及び／又は下位要素を省略してもよい。別の例として、様々な下位要素を単一の要素として統合してもよく、単一の要素を複数の下位要素に分割してもよい。

ＩＩＩ．例示的な動作方法
サブセクションＩＩＩ．Ａでは、幾つかの実施形態の支払い処理を概念的に説明する。サブセクションＩＩＩ．Ｂでは、幾つかの実施形態によって提供される概念的な登録プロセスを説明する。サブセクションＩＩＩ．０では、幾つかの実施形態によって提供される概念的な償還プロセスを説明する。サブセクションＩＩＩ．Ｄでは、既存のアカウント情報を更新するために幾つかの実施形態によって使用される概念的プロセスを説明する。サブセクションＩＩＩ．Ｅでは、取引後のマーケティングを行うために幾つかの実施形態によって使用される概念的プロセスを説明する。サブセクションＩＩＩ．Ｆでは、幾つかの実施形態によってユーザデータを収集及び提供するために使用される概念的プロセスを説明する。最後に、サブセクションＩＩＩ．Ｇでは、幾つかの実施形態によって様々な動作を実現するために使用されるメッセージフローを説明する。

以下に説明する様々なプロセスは、図１を参照して上述したハードウェア要素、図２〜図４を参照して上述したソフトウェアコンポーネント、図５を参照して上述したデータ構造、及び／又は他の適切な要素の様々な組み合わせを使用して実施してもよい。更に、以下に説明する様々なプロセス（又はその一部）を適切な様々に組合せて、様々な特徴（例えば、支払い及び登録、支払い及び報酬の償還等）の組み合わせを提供してもよい。

Ａ．支払い処理の例示的な実施形態
図６は、支払及び／又は登録を行うために幾つかの実施形態によって使用される概念的プロセス６００のフローチャートである。このようなプロセスは、例えば、卓上のタブレットデバイスを使用して消費者に支払いオプションを提示するとき、サーバやレジ係が支払い操作を開始したとき等に開始してもよい。次に、プロセスは、（６１０において）支払いオプションの選択を受信する。利用可能なオプション（現金での支払い、クレジットカードによる支払い、オンラインアカウントでの支払い等）は、様々な適切な手法で（例えば、リストとして、又は選択可能な一組のボタンとして）で表示され、オプションからの選択は、様々な適切な手法で（例えば、タッチスクリーンを使用して、又は表示画面及びキーパッドを使用して）受け取ることができる。

幾つかの実施形態では、プロセスは、少なくとも部分的に、選択された支払オプションに応じて、異なる動作の組を実行できる（例えば、支払いオプションとして「現金」が選択された場合、プロセスは単に請求書を表示又は印刷して終了できる）。

次に、プロセスは、報酬プログラムに登録するための１又は複数のインセンティブをオファーしてもよく（図示せず）、及び／又はユーザに参加を促すことができる。このようなオファーは、例えば、マーケティング資料、ワンタイム割引等を含むことができる。次に、プロセスは、（６２０において）オファーの受取人が報酬プログラムに参加する意思があるか否かを判定してもよい。このような判定は、受取人から受信し、サーバ又は他の協力者によって入力され、及び／又は他の適切な手法で行われた入力に基づいて行うことができる。受取人が参加を望まないとプロセスが判定した場合、プロセスは、（６２５において）、支払い情報を受信し、（６３０において）支払いを処理してもよい。このような支払い情報は、様々な適切な手法（例えば、クレジットカードをスワイプし、クレジットカード又は銀行情報を入力し、ウェブベースの支払い方法のためのアカウント情報を提供する等）によって受信でき、適切に処理される。

一方、受取人が参加を望むとプロセスが判定した場合、プロセスは、（６４０において）支払い情報を受信してもよい。このような支払い情報は、様々な適切な手法（例えば、クレジットカードをスワイプし、クレジットカード又は銀行情報を入力し、ウェブベースの支払い方法のためのアカウント情報を提供する等）によって受信できる。

次に、プロセス６００は、（６５０において）支払い情報が認識されたか（及び／又はユーザが既存のユーザか）を判定してもよい。このような判定は、様々な適切な手法で（例えば、支払い情報をアカウントのデータベースと比較することによって、又はユーザが新しいメンバであるか既存のメンバであるかをユーザが指示するように促すことによって）行うことができる。

幾つかの実施形態では、消費者が特定の支払い方法を使用して報酬プログラムに登録した後は、ユーザは、同じ支払い方法が使用されている場合、ユーザによる追加の操作を必要とすることなく、既存のメンバとして自動的に認識される。例えば、ユーザが、（例えば、固定端末を使用して、又はタブレット等のモバイルデバイスを使用して）支払いのためにクレジットカードをスワイプし、クレジットカードが既存のアカウントに関連すると判定されると、ユーザが登録されていない場合と同様に、ユーザに追加の選択又は支払いを処理するために必要なアクション以外のアクションを要求することなく、報酬情報が更新され及び／又は請求に適用されるようにしてもよい。

（６５０において）支払い情報が認識されないとプロセスが判定した場合、プロセスは、（６６０において）登録を実行し、（６７０において）アカウントを作成する。一方、（６５０において）支払い情報が認識されないと判定すると共に、（例えば、ユーザからの指示を受信することによって、又は電子メールがすでにアカウントに関連付けられていと判定することによって）ユーザが既に登録済みであるとプロセスが判定した場合（図示せず）、プロセスは、（例えば、アカウントに別の支払い方法を追加することによって）ユーザに関連するアカウント情報を更新するか否かを判定してもよい。このような決定は、様々な適切な要因（例えば、ユーザ選択、デフォルト設定等）に基づいて行うことができる。

登録の処理は、ユーザに電子メールアドレスやその他の情報を入力するよう求めることを含むことができる。幾つかの実施形態では、支払い方法及びその方法に関連する情報（例えば、受取人の氏名、住所等）は、６２０において受信した支払い情報から読み出してもよい（例えば、消費者の氏名は、アカウント番号及び／又はクレジットカード又は銀行カードの裏面の磁気ストリップ上の他の情報と共にエンコードされていてもよく、消費者の氏名はウェブベースの決済サービスから入手してもよい）。登録については、後にプロセス７００を参照してより詳細に説明する。

（６５０において）支払い情報が認識されたとプロセス６００が判断すると、プロセスは、（６８０において）ユーザに関連付けられているアカウント情報を検索及び／又は更新できる。このような検索及び／又は更新は、リモートサーバ又は他の要素と通信して、ユーザの状態（例えば、累計ポイント数、購入履歴等）を判定し、及び／又は現在のインタラクトに関する情報（例えば、支払額、参加選択等）をサーバに送信することを含むことができる。アカウント情報の更新については、後にプロセス９００を参照してより詳細に説明する。

（６８０において）アカウント情報を検索及び／又は更新した後、又は（６６０において）登録を実行し、（６７０において）アカウントを作成した後、プロセス６００は、（６９０において）アカウントに報酬を適用してもよい。幾つかの実施形態では、このような報酬は、（例えば、消費者の支払額を自動的に減額することによって）即座に提供してもよい。あるいは、償還されていない追加の報酬を反映するようにユーザのアカウントを更新してもよい。幾つかの実施形態では、ユーザは、適用可能な一組の報酬の中から報酬を選択できる（図示せず）。例えば、オプション（例えば、残高にポイントを適用する、又はポイントを追加商品と交換する等）のリストを提示し、リストされたオプションから選択を受け取ってもよい。

（６９０において）報酬を適用した後、又は（６２５において）支払い情報を受信した後、プロセスは、（６３０において）（例えば、サードパーティのアプリケーション及び／又はサーバとインタラクションしてクレジットカード取引を実行すること、ウェブベースのサービスとインタラクトすること等によって）取引の支払いを処理し、終了できる。

プロセス６００は、様々な異なる手法で実行できる。例えば、異なる実施形態は、異なる動作を含むことができ、様々な動作を省略し、及び／又は図示とは異なる順序で動作を実行してもよい。幾つかの実施形態は、プロセスをサブプロセスの組に分割してもよく、より大きなマクロプロセスのサブプロセスとしてプロセスを実行してもよい。

Ｂ．登録の例示的な実施形態
図７は、幾つかの実施形態によって新しいメンバの登録を実行するために使用される概念的プロセス７００のフローチャートである。このようなプロセスは、例えば、ユーザが報酬プログラムに参加することを選択し、新しいメンバとして識別されたときに実行してもよい。

図に示すように、プロセスは、（７１０において）報酬プログラム情報を検索してもよい。このような情報は、業者又はチェーンに関するバイオグラフィック情報、ルール等を含むことができる。次に、プロセスは、（７２０において）支払い方法に関連付けられたユーザ情報（例えば、氏名とクレジットカード番号、ユーザ名等）を検索する。このような情報は、支払い方法に応じて、様々な適切な手法で検索できる（例えば、支払い情報及びバイオグラフィック情報は、カードがスワイプされたときに銀行カード上の磁気ストリップに格納されたデータから読み出してもよく、サードパーティから情報を受け取ってもよい）。

プロセスは、（７３０において）追加のユーザ情報を受信してもよい。このような情報は、様々な適切な手法で（例えば、ユーザが情報を入力できるテキストフィールド、チェックボックス、選択リスト等の様々なフォーム要素を有するユーザインタフェースを提供することによって）取得できる。追加の情報は、連絡先情報及び／又はバイオグラフィック情報（例えば、電子メールアドレス、ソーシャルネットワーキングページ、誕生日、携帯電話番号、郵便番号等）、ユーザの好み（例えば、電子メールを毎週受け取る、電子メールを毎日受け取るといった好み）、及び／又は他の適切な情報（例えば、月毎の外食回数、年収等）を含むことができる。幾つかの実施形態では、様々な報酬、マーケティング資料等は、少なくとも部分的に連絡先情報及び／又はバイオグラフィック情報に基づくことができる。

次に、プロセスは、（７４０において）支払い方法をユーザのアカウント情報に関連付け、（７５０において）ユーザロイヤルティアカウントを生成してもよい。ユーザロイヤルティアカウント及び関連する支払い方法は、リモートサーバ及びストレージを使用して保存してもよい。

プロセスは、（７６０において）報酬（例えば、ボーナス報酬、即時報酬等）を提供し、終了できる。このような報酬は、様々な適切な基準（例えば、費やされた金額、訪問数、ユーザの状態（例えば、新メンバ、リピート顧客等）等）を含むことができる。このような報酬は、報酬プログラムに関連する一組のルールの少なくとも一部に基づくことができる。

プロセス７００は、様々な異なる手法で実行できる。例えば、異なる実施形態は、異なる動作を含むことができ、様々な動作を省略し、及び／又は図示とは異なる順序で動作を実行してもよい。幾つかの実施形態は、プロセスをサブプロセスの組に分割してもよく、より大きなマクロプロセスのサブプロセスとしてプロセスを実行してもよい。

Ｃ．償還の例示的な実施形態
図８は、幾つかの実施形態によって償還を適用するために使用される概念的プロセス８００のフローチャートである。このようなプロセスは、例えば、既存のユーザが、報酬プログラムに関連する業者において登録した支払い方法を使用して購入を行う場合に実行される。

図示のように、プロセス８００は、（８１０において）報酬プログラム情報（例えば、カテゴリ、閾値等）を検索し、次に、（８２０において）（例えば、スワイプされたクレジットカードによって）支払い情報を受信し、次に、（８３０において）支払い方法に関連するユーザ情報を検索する。このような情報は、幾つかの実施形態の適切なシステム及びソフトウェアを使用して検索してもよい。必要に応じて、これに代わる新しいユーザ情報を収集してもよい。

次に、プロセスは、（８４０において）償還オプション（例えば、購入にポイントを適用する、ギフト又はプロモーションアイテムを受け取る、等）を判定する。このような償還オプションは、検索された報酬プログラム情報に含まれてもよい。次に、プロセスは、（８５０において）（例えば、ユーザ入力を受信すること、デフォルト選択を実行すること等によって）償還オプションの選択を受信でき、（８６０において）（例えば、報酬ポイント数に関連する金額を請求から減額すること、無料のデザート等のプロモーション報酬を適用すること等によって）選択されたオプションを適用できる。最後に、プロセスは、（８７０において）（例えば、クレジットカード情報をサードパーティのプロセッサに送信することによって）支払いを適用し、終了できる。

プロセス８００は、本発明の思想から逸脱することなく、様々な異なる手法で実行できる。例えば、異なる実施形態は、異なる動作を含むことができ、様々な動作を省略し、及び／又は図示とは異なる順序で動作を実行してもよい。幾つかの実施形態は、プロセスをサブプロセスの組に分割してもよく、より大きなマクロプロセスのサブプロセスとしてプロセスを実行してもよい。

Ｄ．アカウント更新の例示的な実施形態
図９は、既存のメンバに関連する情報を更新するために幾つかの実施形態によって使用される概念的プロセス９００のフローチャートを示している。このようなプロセスは、例えば、ユーザが報酬プログラムに参加することを選択し、既存のメンバとして識別された場合に実行してもよい。あるいは、既存のメンバは、ユーザの情報（例えば、支払い方法、住所、好み等）が変更されたことを示す選択を行うことができる。別の例として、既存のユーザは、未だ報酬アカウントに関連付けられていない支払い方法を用いて支払いを行うことができる（例えば、新しいクレジットカードを使用すると共に、ユーザは、以前に登録済みであることを示してもよい）。幾つかの実施形態では、新しいクレジットカード（又は他の支払い方法）が認識されない場合、プロセスを自動的に実行してもよい。

図示のように、プロセスは、（９１０において）報酬プログラム情報を検索し、（９２０において）ユーザ情報を受信する。このような情報は、業者又はチェーンに関するバイオグラフィック情報、ルール等を含むことができる。このようなユーザ情報は、ユーザアカウント情報（例えば、ユーザ名とパスワード、電子メールアドレス等）及び／又はユーザ情報の更新（例えば、新しい支払い方法、追加の又は更新された電話番号、更新された電子メールアドレス等）を含むことができる。例えば、認識できないクレジットカードをユーザがスワイプし、また、ユーザが既存のユーザであることを示した場合、報酬アカウントに関連付けられた電子メールアドレス（又はユーザ名及びパスワード、及び／又は他の適切な識別情報）をユーザに提供するように求めてもよい。

次に、プロセスは、（９３０において）ユーザアカウント情報を検索する。ユーザアカウント情報は、バイオグラフィック情報、支払い方法情報、インタラクト履歴に関連する情報、及び／又は他の適切なデータを含むことができる。このようなアカウント情報は、９２０において受信したユーザ情報の少なくとも一部に基づいて検索してもよい（例えば、ユーザによって提供されたユーザ名又は電子メールアドレスを使用して、ユーザに関連付けられたアカウントを特定し、これにより、アカウント情報を検索してもよい）。

その後、プロセスは、必要に応じて、（９４０において）ユーザアカウント情報を更新してもよい。例えば、どのユーザアカウントにも関連付けられていないクレジットカードが支払いに使用されたが、ユーザが既存のアカウントを有することを示す選択を行った場合、新しい支払い方法を既存のアカウントに関連付けてもよい（したがって、将来的にその他の有効な支払い方法と共に自動的に認識されるようにしてもよい）。

プロセス９００は、（９５０において）報酬を提供し、終了できる。このような報酬は、様々な適切な基準（例えば、費やされた金額、訪問数、ユーザの状態（例えば、新メンバ、リピート顧客）等）に基づくことができる。また、このような報酬は、報酬プログラムに関連する一組のルールの少なくとも一部に基づいて決定してもよい。

ユーザが既存の報酬アカウントに新しい支払い方法を追加する例を参照してプロセス９００を説明したが、同様のプロセスを使用して、既存の支払い方法を新しい報酬アカウントに追加することもできる。例えば、ユーザが、支払い方法に第１の販売業者が関連付けられた既存の報酬アカウントを有し、ユーザが、その支払い方法を第２の販売業者にも適用すると、幾つかの実施形態では、第１の販売業者に伴うアカウントの存在を自動的に認識し、ユーザ情報（例えば、氏名、電子メール、住所、郵便番号、ソーシャルメディア情報等）を適用して、第２の販売業者に関連するアカウントを作成してもよい。

プロセス９００は、様々な異なる手法で実行できる。例えば、異なる実施形態は、異なる動作を含むことができ、様々な動作を省略し、及び／又は図示とは異なる順序で動作を実行してもよい。幾つかの実施形態は、プロセスをサブプロセスの組に分割してもよく、より大きなマクロプロセスのサブプロセスとしてプロセスを実行してもよい。

Ｅ．取引後マーケティング
図１０は、取引後のマーケティングを最適化するために幾つかの実施形態によって使用される概念的プロセス１０００のフローチャートを示している。このような処理は、一定間隔（例えば、毎時、毎日、毎週等）で実行してもよく、様々な基準（例えば、新しいユーザのサインアップ、既存のアカウントの更新、休日の間、特定の時刻等）に基づいて実行してもよく、及び／又は他の適切な時期（例えば、小売業者がプロモーションオファーを開始したとき、支出閾値等の閾値に達したとき、取引履歴に基づいて、顧客の支出行動に基づいて、等）に実行してもよい。

このようなプロセスは、領収書送達（例えば、マーケティングオファーが含まれた領収書の電子メール送信、クーポン付きのマーケティング電子メールの送信等）等の様々な適切な動作をトリガしてもよい。幾つかの実施形態では、領収書は、選択可能な要素（例えば、ＵＲＬ）を含んでいてもよく、これにより、ユーザは、経費に関する情報（例えば、会議の相手、議論した事柄等）を提供でき、これは、（例えば、ユーザが税務書類を作成する際に）ユーザが利用するためにコンパイルできる。

この図に示すように、プロセスは、（１０１０において）データベースエントリを検索してもよい。このようなデータベースエントリは、幾つかの実施形態を使用して実行される報酬プログラム取引と関連付けてもよい。次に、プロセスは、（１０２０において）取引が新しいメンバを含むか否かを判断する。取引が新しいメンバを含むとプロセスが判断した場合、プロセスは、（１０３０において）サードパーティ情報を検索する。このようなサードパーティ情報には、マーケティング情報（例えば、電子メールテンプレート、宣伝用コンテンツ等）を含めてもよく、これは、業者、チェーン、マーケティング会社、及び／又は他の適切なサードパーティから取得してもよい。

（１０３０において）サードパーティ情報を取得した後又は（１０２０において）その取引が新しいメンバを伴わないと判定した後、プロセスは、（１０４０において）少なくとも部分的に、ユーザの取引履歴と一連のマーケティングルールとに基づいて、マーケティング情報を生成してもよい。次に、プロセスは、（１０５０において）適切なマーケティングテンプレート（例えば、電子メールテンプレート）を検索し、（１０６０において）マーケティング情報をメンバに送信する。

プロセス１０００は、様々な異なる手法で実行できる。例えば、異なる実施形態は、異なる動作を含むことができ、様々な動作を省略し、及び／又は図示とは異なる順序で動作を実行してもよい。幾つかの実施形態は、プロセスをサブプロセスの組に分割してもよく、より大きなマクロプロセスのサブプロセスとしてプロセスを実行してもよい。

Ｆ．販売業者ダッシュボード
幾つかの実施形態では、業者、業者のグループ、マーケティング組織等の様々な販売業者（又は「ユーザ」）が、ユーザ（すなわち消費者）データにアクセスできるようにしてもよい。このようなデータは、幾つかの実施形態のシステムを使用して行われたユーザの購入に関連する任意の情報を含むことができる。この情報は、ユーザ状態情報（例えば、新規登録、既存メンバ、購入履歴、郵便番号、ソーシャルメディアアカウント情報等）、支払い方法等の支払い情報、購入情報（例えば、請求書、アイテムのリスト、総額、タイムスタンプ、購入場所等）、業者情報（例えば、タイプ、場所、サイズ、プロモーション等）、報酬情報（例えば、未払いの報酬ポイント、償還された報酬ポイント等）、及び／又は幾つかの実施形態のシステムによってコンパイルできる他の情報を含むことができる。

ユーザデータは様々な適切な手法で収集及び／又はコンパイルできる。例えば、幾つかの実施形態では、（例えば、ユーザが登録するとき、ユーザが登録された販売業者に支払いをするとき等に）ユーザデータを受信しながらユーザデータを継続的に収集する。別の例として、ユーザデータは、様々な適切な時間に及び／又は様々な適切な手法で、様々な業者から収集できる（例えば、店舗が定期的な間隔で情報を提供してもよく、地域チェーンが特定の手法でフォーマット化された情報等を提供してもよい）。このようなユーザデータは、消費行動、償還行動、統計的情報、ソーシャルメディア行動（例えば、登録ユーザによる「いいね」の集計、「フレンド」とのリンクの共有、メッセージ又はリンクの転送等）等を含むことができる。データは、収集され及び／又はリアルタイムで利用できるようにしてもよい（すなわち、データが幾つかの実施形態のシステムに供給されると、様々なユーザが直ちにデータを利用できるようにしてもよい）。更に、幾つかの実施形態では、このように収集されたデータは、（例えば、製品又はサービスを「いいね」したユーザに報酬を提供すること、又はユーザがリンクを共有したときに追加ポイントを与えること等によって）登録されたユーザに報酬を提供するために使用してもよい。

図１１は、分析データをサードパーティに提供するために幾つかの実施形態によって使用される概念的プロセス１１００のフローチャートを示している。幾つかの実施形態では、このようなプロセスは、ユーザ情報を受信すると連続的に実行してもよい。

プロセスは、（１１１０において）ユーザ情報の要求（又は「クエリ」）を受信してもよい。このようなユーザ情報は、情報を要求する販売業者の希望に応じて様々な適切な手法で集約してもよい（例えば、直近の期間に亘って閾値以上の金額を購入した全てのユーザ、特定の時間枠内に登録した全てのユーザ等）。このような要求は、様々な適切な手法（例えば、ＡＰＩを介して、ウェブサイト又は他の類似するポータルを介して、幾つかの実施形態の適用によって、フォーマット化されたメッセージとして、等）によって受信できる。要求は、様々な適切なパラメータ（例えば、消費者タイプ、業者タイプ、購入金額等）を含むことができ、これらを用いて、要求に基づいて適切な情報を識別してもよい。

次に、プロセスは、（１１２０において）要求されたユーザ情報を検索してもよい。このような情報は、例えば、幾つかの実施形態の遠隔ストレージにアクセスすることによって検索してもよい。次に、プロセス１１００は、（１１３０において）検索された情報をコンパイルしてもよい。この情報は、（例えば、要求された要素に基づいて、ユーザの嗜好に基づいて、様々なプロトコルに基づいて、等）様々な適切な手法でコンパイルできる。

最後に、プロセスは、（１１４０において）コンパイルされた情報を要求側に提供し、終了できる。情報は、様々な適切な基準、パラメータ等に基づいて、様々な適切な手法及び／又はフォーマットで提供できる。

プロセス１１００は、様々な異なる手法で実行できる。例えば、異なる実施形態は、異なる動作を含むことができ、様々な動作を省略し、及び／又は図示とは異なる順序で動作を実行してもよい。幾つかの実施形態は、プロセスをサブプロセスの組に分割してもよく、より大きなマクロプロセスのサブプロセスとしてプロセスを実行してもよい。

Ｇ．例示的なメッセージフロー
図１２は、支払い及び／又は登録を行うために幾つかの実施形態によって使用される概念的な通信プロトコル１２００のメッセージフロー図を示している。図示のように、通信プロトコルは、クライアントデバイス１２１０、ローカルサーバ１２２０、リモートサーバ１２３０、及びサードパーティサーバ１２４０を含む様々なデバイスの間で行われる。図１２の要素及びメッセージフローは、例示のみを目的としている。様々な関連要因（例えば、利用可能なシステム要素及び／又は下位要素、ユーザによる選択、サードパーティ又は外部システムに対する様々な要求の承認及び／又は否認等）に応じて、多くの異なるメッセージフローが発生する可能性がある。

この例では、クライアントデバイス１２１０は、レストランのサーバに関連付けてもよく、ローカルサーバ１２２０は、レストランによって使用されるＰＯＳシステムであってもよく、リモートサーバ１２３０は、幾つかの実施形態のシステムによって提供される一組のリモートデバイスを含むことができ、サードパーティサーバ１２４０は、サードパーティの支払いプロセッサによって提供される一組のリモートデバイスを含むことができる。

動作中、サーバは、幾つかの実施形態のクライアントデバイス及びクライアント側アプリケーションを使用して選択を行うことによって、顧客に対する会計（checkout）を開始できる。このような選択により、メッセージ「ａ」をクライアントデバイス１２１０からローカルサーバ１２２０に送信してもよい。ローカルサーバ１２２０は、顧客に関連付けられた請求書又は勘定書をコンパイルし、請求書（例えば、消費者によって購入された品目のリスト、適用税等）を含む応答「ｂ」を送信してもよい。

クライアントデバイス１２１０は、次に、処理要求と共に、応答「ｂ」で送信された請求書及びユーザの支払い方法に関する情報（例えば、クライアントデバイス１２１０を用いてスワイプされたクレジットカード情報）を含むことができるメッセージ「ｃ」をリモートサーバ１２３０に送信してもよい。更に、メッセージ「ｃ」は、（新規ユーザの場合）ユーザ登録に関する情報及び／又は（例えば、既存のユーザが新しい支払い方法を追加する場合）更新された支払い情報を含むことができる。このようなメッセージは、消費者とのインタラクトに関連する取引情報（例えば、請求額、業者の位置等）を含んでもよく、これを用いて、そのユーザに関連する報酬プログラム情報を更新してもよい。

リモートサーバ１２３０は、メッセージ「ｃ」を受信し、要求「ｄ」を生成し、これをサードパーティサーバ１２４０に処理させるために送信してもよい。このような要求は、支払い情報（例えば、クレジットカード番号、氏名、認証コード等）、支払い金額、及び／又は他の適切な情報を含むことができる。サードパーティサーバは、要求「ｄ」を分析し、支払いを処理するか否かを判定してもよい。このような判定は、様々な適切な基準（例えば、ユーザの信用限度、業者の評判等）に基づいて行うことができる。

サードパーティサーバ１２４０は、支払い要求を許可又は拒否する応答「ｅ」をリモートサーバ１２３０に送信してもよい。このような応答は、様々な認証コード、識別情報等を含むことができる。リモートサーバは、次に、支払い処理の結果及び／又は任意の関連情報を示す応答「ｆ」をクライアントデバイス１２１０に送信してもよい。

支払いが拒否された場合、クライアントデバイス１２１０は、支払いが許可されるまで、ユーザに別の支払い形式を入力し、メッセージ「ｃ」〜「ｆ」を繰り返すように促すことができ、支払いが許可された時点で、クライアントデバイス１２１０は、支払い処理の結果を示す確認メッセージ「ｇ」をローカルサーバ１２２０に送信できる。ローカルサーバは、支払いが適用され、消費者取引が完了したことを示すメッセージ「ｈ」を返してもよい。

次に、クライアントデバイス１２１０は、完了した取引を確認するメッセージ「ｊ」をサードパーティサーバ１２４０に送信してもよい。最後に、クライアントデバイス１２１０は、消費者取引が完了し、全ての情報がリモートサーバ１２３０に送信されたことを示す終了メッセージ「ｋ」をローカルサーバ１２２０に送信できる。

メッセージフロー図１２００は、例示のみを目的として、異なる実施形態では、様々な異なる手法で通信できることは、当業者にとって明らかである。例えば、幾つかの実施形態では、クライアントデバイスは、リモートサーバと直接通信できず、代わりにローカルサーバを介してメッセージを中継する必要があってもよい。別の例として、幾つかの実施形態では、クライアントデバイスは、リモートサーバを使用せずにサードパーティサーバと直接通信してもよい。更に、異なる実施形態では、異なるデバイス間で及び／又はここに示すものとは異なる順序で、異なるメッセージの組を送信してもよい。

図１５Ａ及び図１５Ｂを参照して、ユーザ制御リアルタイムデータ処理（user-controlled real-time data processing）を実現できるデータ通信システムの幾つかの実施形態を説明する。ユーザ、例えば、請求金額を支払う、又は金融取引を行う、又は他の何らかの手法でデータの処理を制御する消費者又は顧客は、取引毎の明示的な制御によって、又は事前のユーザ選択又はリモートに配置されたサーバ上で行われる取引からの暗示的な制御に基づいて、データ処理ステップを制御できる。

図１５Ａは、例示的なデータ通信システム１５００を示しており、これは、消費者が支払い情報及びプログラム登録オプションをデータ通信システムに入力するために使用するクライアントデバイス１５０２と、通信ネットワーク１５０４を介してクライアントデバイスに通信可能に接続された取引プロセッサ１５０６であって、入力された支払い情報及びプログラム登録オプションを受信し、クライアントデバイス１５０２への応答を決定する取引プロセッサ１５０６と、クライアントデバイス１５０２及び取引プロセッサに通信可能に接続され、事前定義されたルールセット及び消費者の状態に基づいて、入力された支払い情報から支払額を変更する登録サーバ１５０８であって、各消費者に関連する一意の個人アカウント番号を格納するデータベースを含む登録サーバ１５０８とを備える。クライアントデバイス１５０２は、例えば、クライアントデバイス１２０であってもよい。取引プロセッサ１５０６は、リモートサーバ１４０と同様であってもよい。

図１５Ｂは、（取引プロセッサ１５０６と略同様の）取引プロセッサ１５５６及び（登録サーバ１５０８と略同様の）登録サーバ１５５８が単一のハードウェアプラットフォーム上に同じ場所に配置され、コンピュータシステムの内部データバス又はソフトウェアアプリケーションプログラミングインタフェース（ＡＰＩ）である内部通信機構を介して互いに通信できる点を除いて、データ通信システム１５００と同様に動作するデータ通信システム１５５０の例示的な実施形態を示している。このような実施形態では、登録サーバ１５５８は、明示的なユーザ選択、例えば、オプトインメニュー選択、及び／又は暗示的なユーザアクション、例えば、ユーザの以前の取引に基づくユーザの報酬の蓄積を用いて、取引プロセッサ１５５６によって処理されているデータを修正する。例えば、取引プロセッサがデータ処理要求をリアルタイムで受信すると、取引プロセッサは、取引が処理されている顧客又は利用者のデータ（例えば、購入金額）及び身元に関する情報を登録サーバ１５５８に送信する。次に、登録サーバ１５５８は、例えば、ユーザに割引を提供することによって、取引を変更でき、この結果を取引プロセッサ１５５６にリアルタイムで返信してもよい。クレジットカード決済の支払い処理は、ほとんどが自動化されたプロセスであり、現時点では、支払いを行っている消費者へのリアルタイムの応答性を維持しながら支払い処理のフローを変更するための技術的解決策は存在しない。

ここに開示する技術を使用することにより、支払いのリアルタイム性を維持しながら、支払い処理フローに割り込みを行い、支払データに変更を加えることができる。最終的な支払い額を変更するプロセスは、消費者を追跡するための一意の識別子を使用することによって速めることができる。更に、消費者が変更の恩恵、例えば、支払いの割引を受けることを望むか否かについての消費者の選択と支払データとを関連付けることにより、処理の速度が維持され、これにより、消費者は、複数のメニュー画面又は物理的な用紙に記入を行う必要がなくなる。このように、取引プロセッサ１５５６と連携して登録サーバ１５５８を使用することにより、消費者が報酬プログラムの既知のメンバであるか否かをリアルタイムで特定でき、既知のメンバでない場合は、消費者がプログラムに登録を望んでいるか否かを特定できる。

図１６は、幾つかの実施形態によってデータ処理を実行するために使用される概念的な通信プロトコル１６００のメッセージフロー図を示している。図示のように、通信プロトコルは、クライアントデバイス１６０２（１５０２又は１２１０と同様であってもよい）、処理サーバ１６０４（例えば、リモートサーバ１２３０）、及び登録サーバ１６０６を含む様々なデバイスの間で行われる。図１２の要素及びメッセージフローは、例示のみを目的としている。様々な関連要因（例えば、利用可能なシステム要素及び／又は下位要素、ユーザによる選択、サードパーティ又は外部システムに対する様々な要求の承認及び／又は否認等）に応じて、多くの異なるメッセージフローが発生する可能性がある。

クライアントデバイス１６０２は、商取引、例えばクレジットカード決済を表すメッセージ１６１０を処理サーバ１６０４に送信してもよい。メッセージ１６１０は、ユーザを一意的に識別する情報、例えば、クレジットカード番号、ユーザの残高に対して適用される金額、ユーザの電話番号、又は電子メールアドレス等を含んでいてもよい。また、メッセージ１６１０は、ユーザが登録プランを選択することを希望することを示すフィールドを含むことができる。

処理サーバ１６０４は、メッセージ１６１０を受信すると、ユーザがオプトインを指示したか否かに応じて、メッセージ１６１２を登録サーバ１６０６に送信する。処理サーバ１６０４は、メッセージ１６１２において、登録サーバ１６０６に対して、ユーザの電子メールアドレスや電話番号等の独自の追加情報と共に、ユーザを特定する情報を送信できる。

登録サーバ１６０６は、受信したユーザ情報を処理し、ユーザが登録されているか及びユーザの支払いに減額を適用するかを示すメッセージ１６１４を生成し、処理サーバ１６０４に送信する。次に、処理サーバ１６０４は、クライアントデバイス１６０２上で実行中のデータ処理取引を完了するメッセージ１６１６を送信する。次に、処理サーバ１６０４は、取引完了メッセージ１６１８を登録サーバ１６０６に送信してもよい。処理サーバ１６０４は、登録サーバから確認メッセージ１６２０を受信し、取引を完了する。このように、有利な一側面において、この通信プロトコルにより、消費者又はユーザは、処理サーバ１６０４上で処理される取引データを制御でき、取引を選択するか断るかについての消費者の好みの選択に基づいて、取引データにリアルタイムで調整を加えることができ、また、消費者によって以前に実行された同様の取引（例えば、ロイヤルティ報酬）に基づいて取引金額を変更することもできる。

幾つかの実施形態では、リアルタイムデータ処理を実行する方法は、消費者に関する個人情報、消費者が行おうとしている支払いに関する情報、及びロイヤルティ登録プログラムを選択することを望む消費者に関する情報を含むデータを含む第１のメッセージを受信することと、受信したカード支払いが消費者の既存のユーザアカウントに関連付けられている場合、メッセージにおいて受信した個人情報が既に既存のユーザアカウントに関連付けられているか否かをチェックすることと、受信したカード支払いが既存のユーザアカウントに関連付けられていない場合、既存のユーザアカウントに関する情報を更新し、受信したカード支払いを既存のユーザアカウントに関連付けることと、関連付けに基づいて、消費者が行おうとしている支払いに関する情報を変更することと、支払いに関する変更された情報と、消費者に表示するための追加情報とを含む第２のメッセージを送信することとを含む。幾つかの実施形態では、変更は、ユーザアカウントのための報酬に関連する一組のルールをリアルタイムで検索することと、一組のルールの少なくとも一部に基づいて既存のユーザアカウントに関する情報を評価することと、この評価の少なくとも一部に基づいて、消費者が行おうとしている支払いに適用される償還を決定することとを含み、少なくとも１つの報酬は、ロイヤルティルールに基づいて、消費者が行おうとしている支払いの額を減らす即時報酬及び未払い報酬の少なくとも１つを含む。

ＩＶ．グラフィカルユーザインタフェース（ＧＵＩ）要素の例
図１３は、幾つかの実施形態によって提供される１又は複数のプログラムにユーザが参加することを可能にする、幾つかの実施形態によって提供される様々なＧＵＩ１３１０〜１３４０及び関連する下位要素を示している。このようなＧＵＩは、適切なクライアントデバイス（例えば、上記のクライアントデバイス１２０）を使用して提示できる。

図示のように、ＧＵＩ１３１０は、第１のグラフィック要素１３５０、第２のグラフィック要素１３５５、及び一組の選択要素１３６０を含むことができる。この例では、第１のグラフィック要素１３５０は、登録オファー（例えば、即時報酬を受け取るために今登録する）を含むことができ、第２のグラフィック要素１３５５は、登録利益及び／又は他の情報のリスト（例えば、「以降の購入は５％オフ」、「参加無料」等）を含むことができる。一組の選択要素１１６０は、ボタン又は他の選択可能な要素を含むことができ、種々の適切な選択オプションのラベル（例えば、「はい、登録します」、「いいえ、登録しません」、「既にメンバ」、「新しい支払い方法を追加する」等）を付すことができる。

ＧＵＩ１３２０は、複数のグラフィック要素１３６５〜１３７０、１又は複数の入力要素１３７５、及び様々な選択要素１３６０を含むことができる。グラフィック要素１３６５は、登録のための一連の指示を含むことができ、グラフィック要素１３７０は、表示されたテキストとテキスト入力フィールド（例えば、氏名、カード番号、電子メール等）との組み合わせを含むことができる。各入力要素１３７５により、ユーザは、（例えば、ボックスをチェックすることによって）利用規約、プライバシポリシ等を承諾できる。選択要素１３６０は、様々なオプション（例えば、登録、会計等）を含むことができる。

ＧＵＩ１３３０は、（適用可能であれば）報酬が適用されたユーザの請求の要約を表示できるグラフィック要素１３８０及び選択要素１３６０（例えば、署名に進む）を含むことができる。ＧＵＩ１３４０は、入力要素１３８５（例えば、ユーザがタッチスクリーンデバイス上に署名を入力できる領域）及び選択要素１３６０（例えば、署名を受け入れる）を含むことができる。

異なる実施形態は、図１３の例に示されているものとは異なる様々なＧＵＩ要素を含んでもよいことは当業者にとって明らかである。例えば、幾つかの実施形態は、サーバ又はレジ担当者による使用を意図した様々なＧＵＩを含むことができ、このような使用のための適切な要素（例えば、テーブル選択要素、メニュー選択要素等）を含むことができる。別の例として、様々なＧＵＩが縦向きに示されているが、異なる実施形態（及び／又は異なるＧＵＩ）では、横向きを使用してもよい（及び／又は縦横の向きを自動的にシフトできるようにしてもよい）。

Ｖ．コンピュータシステムの例
上述したプロセス及びモジュールの多くは、非一時的なストレージ媒体に記録された少なくとも一組の命令として特定されるソフトウェアプロセスとして実現できる。これらの命令が１又は複数の演算要素（例えば、マイクロプロセッサ、マイクロコントローラ、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向けＩＣ（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）等）によって実行されると、この命令により、演算要素は、命令で指定された動作を実行する。

図１４は、幾つかの実施形態を実装できるコンピュータシステム１４００の概略的なブロック図を概念的に示している。例えば、図１を参照して上述したシステムは、コンピュータシステム１４００を使用して少なくとも部分的に実装できる。別の例として、図６〜図１０を参照して説明したプロセスは、少なくとも部分的に、コンピュータシステム１４００を使用して実行される命令セットを使用して、実現してもよい。

コンピュータシステム１４００は、様々な適切なデバイスを使用して実現できる。例えば、コンピュータシステムは、１又は複数のパーソナルコンピュータ（ＰＣ）、サーバ、モバイルデバイス（例えば、スマートフォン）、タブレットデバイス、及び／又は他の任意の適切なデバイスを含むことができる。様々なデバイスは、単独で動作してもよく（例えば、コンピュータシステムは、単一のＰＣとして実現してもよく）、又は協働して動作してもよい（例えば、コンピュータシステムの幾つかの構成要素は、モバイルデバイスによって提供し、他の構成要素は、タブレットデバイスによって提供されてもよい）。

コンピュータシステム１４００は、バス１４０５、少なくとも１つの処理要素１４１０、システムメモリ１４１５、読取専用メモリ（ＲＯＭ）１４２０、他のコンポーネント（例えば、グラフィックス処理ユニット）１４２５、入力デバイス１４３０、出力デバイス１４３５、永久ストレージデバイス１４４０、及び／又はネットワークインタフェース１４４５を含むことができる。コンピュータシステム１４００のコンポーネントは、デジタル入力信号及び／又はアナログ入力信号に基づいて自動的に動作する電子デバイスであってもよい。例えば、図１３を参照して上述したＧＵＩ要素の様々な例は、少なくとも部分的に、コンピュータシステム１４００上で実行される命令セットを使用して実現し、出力デバイス１４３５を用いて表示してもよい。

バス１４０５は、コンピュータシステム１４００の要素間の全ての通信経路を表している。このような経路は、有線、無線、光学、及び／又は他の適切な通信経路を含むことができる。例えば、入力デバイス１４３０及び／又は出力デバイス１４３５は、無線接続プロトコル又はシステムを使用してシステム１４００に接続してもよい。プロセッサ１４１０は、幾つかの実施形態のプロセスを実行するために、実行すべき命令と処理すべきデータを、システムメモリ１４１５、ＲＯＭ１４２０、及び永久ストレージデバイス１４４０等の構成要素から読み出してもよい。このような命令及びデータは、バス１４０５を介して渡すことができる。

ＲＯＭ１４２０には、プロセッサ１４１０及び／又はコンピュータシステムの他の要素が使用できる静的データ及び命令を格納してもよい。永久ストレージデバイス１４４０は、読取／書込可能なメモリデバイスであってもよい。このデバイスは、コンピュータシステム１４００がオフにされ又は電力が供給されていなくても、命令とデータを保存する不揮発性メモリユニットであってもよい。永久ストレージデバイス１４４０は、大容量ストレージデバイス（磁気ディスク又は光ディスク及びこれに対応するディスクドライブ等）を含むことができる。

コンピュータシステム１４００は、永久ストレージデバイスとしてリムーバブルストレージデバイス及び／又はリモートストレージデバイスを使用してもよい。システムメモリ１４１５は、ランダムアクセスメモリ（ＲＡＭ）等の揮発性の読取／書込可能なメモリであってもよい。システムメモリは、プロセッサが実行時に使用する命令及びデータの幾つかを格納できる。幾つかの実施形態を実現するために使用される命令及び／又はデータのセットは、システムメモリ１４１５、永久ストレージデバイス１４４０、及び／又は読出専用メモリ１４２０に格納してもよい。他のコンポーネント１４２５は、様々な他の機能を実行できる。

入力デバイス１４３０により、ユーザは、情報をコンピュータシステムに提供でき及び／又はシステムの様々な動作を操作できる。入力デバイスは、キーボード、カーソル制御デバイス、音声入力デバイス及び／又はビデオ入力デバイスを含むことができる。出力デバイス１４３５は、プリンタ、ディスプレイ、及び／又はオーディオデバイスを含むことができる。入力デバイス及び／又は出力デバイスの幾つか又は全ては、コンピュータシステムに無線又は光学的に接続してもよい。

最後に、図１４に示すように、コンピュータシステム１４００は、ネットワークインタフェース１４４５を介してネットワーク１４５０に接続してもよい。例えば、コンピュータシステム１４００は、インターネット上のウェブサーバに接続してもよく、これにより、ユーザがウェブブラウザ内で動作するインタフェースとインタラクトすると、コンピュータシステム１４００上で実行されているウェブブラウザは、ウェブサーバとインタラクトできる。幾つかの実施形態では、ネットワークインタフェース１４４５は、１又は複数のＡＰＩを含むことができる。ネットワークインタフェース及び関連するネットワーク１４５０により、システム１４００は、様々なリモートストレージ１４６０及び／又は他の外部コンポーネント１４６５（例えば、サードパーティサーバ）にアクセスできる。

本明細書及び特許請求の範囲で使用する「コンピュータ」、「サーバ」、「プロセッサ」、及び「メモリ」という用語は、全て電子デバイスを指す。これらの用語は、人又は人のグループを除外する。本明細書及び特許請求の範囲で使用する「非一時的ストレージ媒体」という用語は、電子デバイスによって読取可能な形式で情報を格納する有形の物理的オブジェクトに完全に限定される。これらの用語は、無線信号又はその他の一時的な信号を除外する。

なお、コンピュータシステム１４００の構成要素のいずれか又は全てを本明細書に開示する実施形態と併せて使用できることは、当業者にとって明らかである。更に、ここに開示する技術の本発明又は構成要素と併せて、他の多くのシステム構成を使用できることも当業者にとって明らかである。

また、例えば、プライマリアカウント番号（primary account number：ＰＡＮ）等の固有のユーザ情報から導出された固有の識別子を使用してユーザを識別できることも当業者にとって明らかである。このＰＡＮが（紛失又は盗難によって）取り消され、新しいＰＡＮが発行者によって作成された場合、以前の一意のＩＤを新しいＰＡＮに自動的に関連付けてもよい。これにより、カード発行者自身に直接的に関連付けけられた一意のＩＤを更新することもできる。

本明細書に開示した技術は、例えば、ユーザが受け取ったサービス又は製品をレビューして満足度調査に回答することによって、ユーザからレーティング情報を収集するために使用することもできる。例えば、ユーザの評価が予め設定された閾値未満である場合、ＳＭＳは、これをマネージャに送信し、マネージャにユーザの不満を警告してもよい。

既存のメンバが加盟店で現金を支払った場合、これまでの通常の技術では、メンバがその取引のクレジットを受け取ることはなかった。一方、ここに開示する技術を使用すれば、取引完了の際に、ユーザインタフェースによって顧客にウェブリンクを提供でき、顧客は、これを用いて、領収書情報をアップロードして、現金取引の報酬を受け取ることができる。

顧客が、近距離無線通信（near field communication：ＮＦＣ）技術を使用する携帯電話での支払いを希望する場合、支払い資格情報を送信することに加えて、顧客は、登録サーバがユーザを一意的に識別するために使用する全ての同じ情報を含む一意のＩＤ資格情報を送信できる。有利な点として、ユーザは、ＰＯＳ上の情報の入力を実際にバイパスし、オプトインを含む支払いと共にこれを実際に送信するだけで、即時割引を受け取ることができる。

現在、一部の企業は、ビーコン送信を使用して、ブルートゥース(登録商標)が有効になっている携帯電話の動きを追跡できる。しかしながら、ビーコン追跡メカニズムは、実際に行われている取引に接続されておらず、したがって、顧客の動きを追跡することと、顧客の取引との間のギャップを埋めることができない点が課題となっている。取引の実行のために携帯電話固有の情報を使用することによって、ここに開示した技術は、ユーザを追跡でき、他のユーザが入ってきたときに他のユーザと組み合わせ、これら動きを取引と比較して、どの電話機がどの固有ＩＤに属するかを最終的に判定できる。

幾つかの実施形態では、登録サーバ１６０６にとって既知の既存のメンバが新しい店舗に入店し、そのカードが支払いのためにスワイプされると、登録サーバにおいて、固有のＩＤがトリガされる。この相関を用いて、ユーザの電子メールフィールドに、顧客が使用しているＰＡＮにリンクされている固有のＩＤにリンクされたファイル上の既存の電子メールアドレスを自動的に入力してもよい。

幾つかの実施形態では、顧客は、販売業者の報酬プログラムにサインアップして、その特定の販売業者での支出によって獲得される償還を受け取る代わりに、これらの償還を非営利団体に寄付できる。

幾つかの実施形態は、ソフトウェアアプリケーションを格納する非一時的なコンピュータ可読ストレージ媒体の形式で実現してもよく、ソフトウェアアプリケーションは、１又は複数のコンピュータによって実行されると、１又は複数のコンピュータに支払いを処理させ、及び販売業者による報酬プログラム情報を更新させ、これは、消費者に提供される一組の商品又はサービスのための請求書を生成することと、消費者からの支払い方法を受信することと、支払い処理デバイスにユーザインタフェースを表示することであって、ユーザインタフェースは、支払い処理デバイス上で顧客を一意的に識別する追加の個人情報を受信するように構成され、追加の個人情報は少なくとも１つのフォーム要素を含むことと、個人情報を第１のサーバに送信することと、少なくとも１つの報酬をサーバから受信することとによって行われる。第１のサーバは、アプリケーションプログラミングインタフェースを使用して、少なくとも１つのフォーム要素に基づいて、少なくとも１つの報酬を特定するように構成され、アプリケーションプログラミングインタフェースは、１又は複数のサーバと通信するように構成され、販売業者の報酬プログラムの既存のユーザアカウントが、支払い方法に関連付けられているか否かを判定する。サーバは、受け取った支払い方法が関連付けられていると判定される特定の既存のユーザアカウントの請求書の少なくとも一部に基づいて、既存のユーザアカウントに関連する報酬プログラム情報を更新し、少なくとも報酬プログラムの既存のユーザアカウントを有していない消費者のための支払い方法に基づいて消費者のための報酬プログラムに関連付けられた新しいユーザアカウントを作成するように構成される。幾つかの実施形態では、支払い方法は、クレジットカードであり又は最終的にクレジットカードにリンクされる。幾つかの実施形態では、報酬プログラムは、レストラン、食料品店、自動車サービス業者、携帯電話事業者、ｅコマースサイト、小売業者等の１つに関連付けられる。幾つかの実施形態では、ソフトウェアアプリケーションは、受信した支払い方法が関連付けられていると判定される既存の特定のユーザアカウントについて、更新された報酬プログラム情報の少なくとも一部に基づいて、報酬プログラムオファーを生成する命令セットを含む。幾つかの実施形態では、ソフトウェアアプリケーションは、更に、新しいユーザアカウントを作成するための命令セットを含む。幾つかの実施形態では、ソフトウェアアプリケーションは、更に、インスタント報酬を生成し、報酬を消費者に提供するための命令セットを含む。幾つかの実施形態では、ソフトウェアアプリケーションは、サーバ側アプリケーションと通信可能に接続されるように構成されたクライアントデバイスによって実行されるクライアント側アプリケーションを含む。幾つかの実施形態による方法は、以下の項を用いて記述できる。

第１項：ユーザインタフェースを有する支払い処理デバイスを使用して、消費者が購入の支払いをしながら報酬プログラムに登録することを容易にする方法であって、この方法は、支払い処理デバイスを用いて、消費者購入に関連する請求書を消費者に提示することと、請求書に応答して消費者が選択した支払いオプションを受信することと、ユーザインタフェース上に示される（１）新しい報酬プログラムのユーザとして報酬プログラムに登録する、（２）報酬プログラムの既存のユーザアカウントを有する又は（３）報酬プログラムの選択的非登録、のオプションの１つから、選択を行うように消費者に促すこととを含み、消費者によるオプション（１）の選択に応じて、消費者が選択した支払いオプションの支払い情報を受信して支払いを行うことと、少なくとも支払い情報に基づいて報酬プログラムのユーザアカウントを作成することと、支払い処理デバイスにユーザインタフェースを表示することであって、ユーザインタフェースは、追加の個人情報を受信し、支払い処理デバイス上で顧客を一意的に識別するように構成され、追加の個人情報は、少なくとも１つのフォーム要素を含むことと、アプリケーションプログラミングインタフェースを使用して、少なくとも１つのフォーム要素に基づいて、少なくとも１つのプロモーション報酬を特定するように構成された第１のサーバに追加の個人情報を送信することであって、アプリケーションプログラミングインタフェースは、１又は複数のサーバと通信するように構成されていることと、報酬プログラムからの報酬を含むように支払いを確定することとを含む。

第２項：第１項に記載の方法において、この方法は、更に、オプション（２）の消費者の選択に応答して、消費者が選択した支払いオプションの支払い情報を受信して支払いを行うことと、受信した支払い情報が既存のユーザアカウントと関連しているかを判定することと、受信した支払い情報が関連付けられていると判定された特定の既存のユーザアカウントについて、報酬プログラムに関連する既存のユーザアカウントに関する情報を少なくとも請求書に基づいて更新することと、この他の場合、受信した支払い情報を既存のユーザアカウントに関連付けることによって既存のユーザアカウントを更新することと、報酬プログラムからの報酬を含むように支払いを確定することとを含む。

第３項：第１に記載の方法において、この方法は、更に、オプション（３）の消費者の選択に応答して、消費者が選択した支払いオプションの支払い情報を受信して支払いを行うことと、支払いを確定することとを含む。

第４項：第１項に記載の方法において、選択された支払いオプションはクレジット支払いである。

第５項：第１項に記載の方法において、受信した支払い情報は、クレジットカード情報を含む。

第６項：第１項に記載の方法において、報酬プログラムのユーザアカウントを作成することは、消費者からの電子メールアドレスの入力を受信することを含む。

第７項：第１項に記載の方法において、報酬プログラムのユーザアカウントを作成することは、携帯電話番号、誕生日、及び郵便番号のうちの１又は複数を受信することを更に含む。

幾つかの実施形態による別の方法は、以下の項を用いて記述できる。

第８項ユーザインタフェースを有する支払い処理デバイスを使用して、消費者が購入の支払いをしながら報酬プログラムに登録することを容易にする方法であって、この方法は、支払い処理デバイスを用いて、消費者購入に関連する請求書を消費者に提示することと、消費者から支払い情報を受信して支払いを行うことと、報酬プログラムに登録して即時割引を受けることをユーザインタフェース上で消費者に促すことと、報酬プログラムに登録するための承諾を消費者から受信することと、少なくとも支払い情報に基づいて報酬プログラムのユーザアカウントを作成することと、支払い処理デバイスにユーザインタフェースを表示することであって、ユーザインタフェースは、追加の個人情報を受信し、支払い処理デバイス上で顧客を一意的に識別するように構成され、追加の個人情報は、少なくとも１つのフォーム要素を含むことと、アプリケーションプログラミングインタフェースを使用して、少なくとも１つのフォーム要素に基づいて、少なくとも１つのプロモーション報酬を特定するように構成された第１のサーバに追加の個人情報を送信することであって、アプリケーションプログラミングインタフェースは、１又は複数のサーバと通信するように構成されていることと、即時割引を含むように支払いを確定することとを含む。

第９項：第８項に記載の方法において、消費者に登録を促すことは、消費者に電子メールアドレスの入力を促すことを含み、承諾を消費者から受信することは、消費者から電子メールアドレスを受信することを含む。

第１０項：第９項に記載の方法において、報酬プログラムのユーザアカウントを作成することは、更に、電子メールアドレスをユーザアカウントにリンクすることを含む。

第１１項：第８項に記載の方法において、支払い情報を受け取ることは、クレジットカードスワイプ要素を使用してクレジットカード情報を受信することを含む。

更に、以上の例では、多くの個々のモジュールを別個の要素として示しているが、これらのモジュールは、単一の機能ブロック又は要素として組み合わせてもよいことは、当業者にとって明らかである。また、単一のモジュールを複数のモジュールに分割できることも当業者にとって明らかである。

多くの具体的な詳細を参照して本技術を説明したが、この技術は他の特定の形態で具現化してもよいことは、当業者にとって明らかである。例えば、特定の特徴及び／又は構成要素を参照して幾つかの実施形態を説明した。しかしながら、他のタイプの特徴及び構成要素によって他の実施形態を実施してもよいことは、当業者にとって明らかである。本発明は、上述の例示的な詳細によって限定されるものではなく、特許請求の範囲によって定義されることは、当業者にとって明らかである。

Claims (20)

1. 購入の支払いをしながら、販売業者の支払い処理デバイスにおいて、販売業者報酬プログラムへの消費者の登録を容易にする自動化された方法であって、
   販売業者に配置される支払い処理デバイスにおいて、消費者購入に関連する請求書を消費者に提示することと、
   前記請求書の支払いを行うために、前記支払い処理デバイスにおいて、消費者から、カード支払いに関連する支払い情報を含む入力を受信することと、
   前記支払い処理デバイスにおいて、前記支払い処理デバイスを介して、前記消費者を一意に識別する追加の個人情報を受信することと、
   前記支払い処理デバイスにおいて、前記販売業者に関連する報酬プログラムに登録するためのプロンプトに関連付けられた第１のフォーム要素を含む第１のユーザインタフェースを提示することであって、前記第１のユーザインタフェースは、前記消費者が、前記報酬プログラムの登録において前記請求書の即時割引を受けられることを示すメッセージに関連付けられた第２のフォーム要素をさらに含む、提示することと、
   前記支払い処理デバイスにおいて、前記消費者が報酬プログラムに登録することを望むことを示す承諾に対応する入力を前記消費者から受信することと、
   前記支払い処理デバイスから、処理サーバに対し、（ｉ）前記支払い情報、（ｉｉ）前記消費者を一意的に識別する前記追加の個人情報、及び（ｉｉｉ）前記消費者が前記報酬プログラムに登録することを望むことを示す前記承諾を含む第１のデータ通信を送信することであって、
   前記第１のデータ通信を送信することは、前記処理サーバに、前記販売業者の報酬プログラムへのユーザ登録を管理するよう構成された登録サーバに対し、第２のデータ通信を送信させ、前記第２のデータ通信は、前記消費者を前記報酬プログラムへ登録するための指示、前記支払い情報、及び前記消費者を一意的に識別する前記追加の個人情報を含み、
   前記登録サーバにおける前記第２のデータ通信の受信は、前記登録サーバに、（ｉ）少なくとも支払い情報に基づいて前記消費者の報酬プログラムのユーザアカウントを作成させ、及び（ｉｉ）前記処理サーバに対し、前記消費者が登録され前記即時割引が前記請求書に適用されるための指示を含む第３のデータ通信を送信させ、
   前記処理サーバにおける前記第３のデータ通信の受信は、前記処理サーバに、（ｉ）前記報酬プログラムの前記登録に基づいて前記カード支払いに前記即時割引を適用することにより、前記請求書の最終支払い総額を提示することで、前記支払いを処理させ、及び（ｉｉ）前記処理された支払いを示すメッセージを含む第４のデータ通信を送信させ、
   前記処理サーバは、アプリケーションプログラミングインタフェース（ＡＰＩ）を使用して、少なくとも１つのフォーム要素に基づいて、少なくとも１つのプロモーション報酬を特定するように構成され、前記ＡＰＩは、前記登録サーバを含む１又は複数のサーバと通信するように構成されている、
   送信することと、
   前記支払い処理デバイスにおいて、前記即時割引を含む前記支払いを示す取引完了メッセージを表示することによって、前記支払いを確定することと、を含む方法。
2. 請求項１において、前記フォーム要素を含む前記第１のユーザインタフェースを提示することは、前記消費者に電子メールアドレスの入力を促すことを含み、前記承諾を前記消費者から受信することは、前記消費者から電子メールアドレスを受信することを含む自動化された方法。
3. 請求項１において、作成される前記報酬プログラムの前記ユーザアカウントは、更に、電子メールアドレスを前記ユーザアカウントにリンクすることを含む、自動化された方法。
4. 請求項１において、前記カード支払いは、クレジットカードからの直接支払いを含む自動化された方法。
5. 請求項１において、前記支払いは、クレジットカードから直接支払われないが、最終的にクレジットカードにリンクされる支払いを含む自動化された方法。
6. 請求項５において、前記クレジットカードから直接支払われない前記支払いは、近距離無線通信（ＮＦＣ）技術を使用する携帯電話での支払いを含む自動化された方法。
7. 請求項１において、前記追加の個人情報は、前記消費者のソーシャルメディアプロファイル、電子メールアドレス、携帯電話番号、誕生日、又は郵便番号のうち少なくとも１つを含む自動化された方法。
8. 請求項１において、前記消費者の消費行動に基づいて生成されたマーケティングオファーを前記消費者に送信することを更に含む自動化された方法。
9. 請求項１において、前記消費者に電子領収書を送信すること、又は、電子領収書と前記消費者の消費行動に基づいて生成されたマーケティングオファーとの両方を前記消費者に送信することを更に含む自動化された方法。
10. 請求項９において、前記消費者に前記電子領収書を送信することは、前記電子領収書を電子メールで送信すること又は前記電子領収書を前記消費者の携帯電話に送信することを含む自動化された方法。
11. 請求項１において、前記請求書を提示することは、前記支払い処理デバイスに外部接続された画面上に前記請求書を表示することを含む自動化された方法。
12. 購入の支払いをしながら、販売業者の支払い処理デバイスにおいて、販売業者報酬プログラムへの消費者の登録を容易にするデータ通信システムであって、
    販売業者に配置され、単一の支払い取引における請求書の支払い処理及び前記販売業者に関連付けられた報酬プログラムへの登録を容易にするクライアントデバイスであって、
    （ｉ）消費者からの販売時点の購入の支払い情報、（ｉｉ）前記消費者を一意に識別する追加の個人情報、及び（ｉｉｉ）前記消費者が前記販売業者での前記販売時点で前記報酬プログラムに登録することを望むことを示す、前記データ通信システムへの、報酬プログラム登録入力を取得するように構成され、
    前記消費者が前記報酬プログラムへの登録において前記請求書の即時割引を受けられることを示すメッセージを表示するように構成される、
    クライアントデバイスと、
    通信ネットワークを介して前記クライアントデバイスに通信可能に接続された取引処理サーバであって、
    前記クライアントデバイスから、前記入力された支払い情報及びプログラム登録オプションを受信し、
    登録サーバに、（ｉ）前記支払い情報、（ｉｉ）前記消費者を一意に識別する前記追加の個人情報、及び（ｉｉｉ）前記消費者が前記報酬プログラムに登録することを望むことを示す承諾を含むデータ通信を送信し、
    前記プログラム登録オプション、及び、登録サーバから受信した変更並びに前記クライアントデバイスへの応答の判定の結果に基づいて、リアルタイムで支払い処理を調整するように構成された、
    取引処理サーバと、
    通信ネットワークを介して前記取引処理サーバに通信可能に接続された前記登録サーバであって、前記登録サーバは、事前定義されたルールセット及び前記消費者の状態に基づいて、前記データ通信を処理し、前記販売業者に関連付けられた前記報酬プログラムに登録された各消費者に関連付けられた一意的な個人アカウント番号を格納するデータベースを含み、
    前記支払い処理のリアルタイム性を維持しながら、前記クライアントデバイスにおける前記請求書の支払い処理を中断し、前記クライアントデバイスにおける前記消費者からのカード支払いに関連する支払いデータを調整し、
    前記受信したカード支払いが、前記消費者の既存のユーザアカウントに関連しているかを判定して、
    前記受信したカード支払いが、前記消費者の既存のユーザアカウントに関連付けられている場合、前記既存のユーザアカウントに関する情報を更新することと、
    前記受信したカード支払いが、前記既存のユーザアカウントに関連付けられていない場合、前記消費者を登録し、前記受信したカード支払いを前記報酬プログラムの新規のユーザアカウントに関連付け、
    前記販売時点における購入の最初の支払いを変更する最終支払い総額を判定し、
    前記消費者の登録及び前記判定された最終支払い総額を前記取引処理サーバに送信し、前記クライアントデバイスにおける前記消費者の、前記即時割引を含む前記購入を完了するように構成された、
    前記登録サーバと、を備えるシステム。
13. 請求項１２において、前記取引処理サーバ及び前記登録サーバは、異なる事業体によって制御及び操作されるシステム。
14. 請求項１２において、
    前記クライアントデバイスから独立して商業業者において独自に動作する別のクライアントデバイスを更に備え、所与の消費者が前記クライアントデバイスとインタラクトしているか、前記別のクライアントデバイスとインタラクトしているかに関わらず、前記所与の消費者が、前記登録サーバにおいて、前記所与の消費者の一意的な個人アカウント番号に基づいて、一意的に識別されるシステム。
15. 請求項１２において、作成される前記報酬プログラムの前記新規のユーザアカウントは、電子メールアドレスを前記ユーザアカウントにリンクすることを含むシステム。
16. 請求項１２において、前記支払いは、クレジットカードからの直接支払いを含むシステム。
17. 請求項１２において、前記支払いは、クレジットカードから直接支払われないが、最終的にクレジットカードにリンクされる支払いを含むシステム。
18. 請求項１７において、前記クレジットカードから直接支払われない前記支払いは、近距離無線通信（ＮＦＣ）技術を使用する携帯電話での支払いであるシステム。
19. 請求項１２において、前記追加の個人情報は、前記消費者のソーシャルメディアプロファイル、電子メールアドレス、携帯電話番号、誕生日、又は郵便番号のうち少なくとも１つを含むシステム。
20. 請求項１２において、前記請求書は、前記支払い処理デバイスに外部接続された画面上に前記請求書を表示することにより前記消費者に提示されるシステム。

Images