JP7311969B2 - Techniques for user-controlled real-time data processing - Google Patents

Description

This application is filed June 25, 2013 as a continuation-in-part of U.S. patent application Ser. This patent claims priority to US patent application Ser.

TECHNICAL FIELD This document relates to real-time data processing and, in particular, to client-server technology for real-time data processing.

With recent advances in wireless communications and the miniaturization of computing devices, users are now able to use Internet-connected devices anywhere, anytime. There is also a desire to take advantage of the ubiquitous Internet connectivity as a productivity tool, rather than just for entertainment and social networking purposes.

Many merchants, e.g., retailers, restaurants, service providers such as automotive service providers, online commerce sites (or "e-commerce" sites, mobile device commerce utilities (or "m-commerce" utilities), etc.), offer various royalty payments. or may provide a rewards program (e.g., "registration card" technology) that rewards (e.g., by aggregating "points" associated with amounts spent on various items and/or types of items); (reward measures) can be calculated, and the consumer can apply the reward measures (eg, using a "redemption balance" of points) to purchase goods or receive cashback rewards. Consumers are often asked to participate in such programs when making payments to merchants (eg, when checking out at a store, paying restaurant bills, etc.). When users participate in the program, they typically fill out forms, papers or online, answer a series of questions from store staff, and/or perform other tasks to provide registration information to merchants. There is a need to.

After joining, the user is typically required to present a membership card (or code associated with the account, such as a phone number) in order to enroll in the loyalty program. Additionally, existing users will need to perform additional steps to redeem their rewards (e.g., using a registration card to reduce the bill by some reward balance, using a credit card, etc.). and pay the remaining amount separately).

Internet connections for businesses such as restaurants, grocery stores, etc., go beyond simply dialing up bank servers for credit card authorization to provide high-bandwidth access to the Internet, including servers from various service providers. ing. In addition, many companies are beginning to offer wireless Internet access to their customers, including wireless devices that make it convenient for customers to pay, select menus and order. Some inventors are beginning to appreciate the usefulness of such advances in Internet technology.

Postrel US Pat. No. 7,769,630 (hereinafter "Postrel") is for issuing, aggregating and redeeming rewards based on merchant transactions. In Postrel, users, cardholders, shop online using a credit card that has been pre-registered by a card issuer. User registration is usually done in advance and Postrel does not provide technology for card registration at brick and mortar stores.

U.S. Patent Application No. 2012/0041808 to Hofer et al. (hereinafter "Hofer") discloses a system for converting existing, issuer-funded, non-monetary rewards into currency that can be used in retail stores. ing. Hofer, however, does not provide a technology for real-time automated program enrollment at the point-of-sale.

US Patent Application No. 2007/0288311 to Underhill (hereinafter "Underhill") discloses a method for flexible incentive programs in sales organizations. Underhill's technology is a business-to-business web-based incentive program that is specialized for use by suppliers to lock in other businesses to purchase their products. This enrollment technology uses outbound email to existing customers who can enroll in the program. Thus, Underhill's system does not provide technology for real-time decision-making by users at the point of sale.

US Patent Application No. 2007/0083444 (“Matthews”) to Matthews et al. discloses techniques for automatic reconciliation of transaction accounts paid for online transactions. Matthews does not provide technology to connect brick-and-mortar stores to back-end transaction computers.

U.S. Patent Application No. 2012/0101881 to Taylor et al. (hereinafter "Taylor") converts consumer credentials and consumer opt-ins into financial transactions. It discloses how to lock in consumers and provide redemption output through However, users of Taylor's system are required to register their credit card prior to use, ie, this registration is not done in real time, but at the point of sale.

US Patent Application No. 2011/0307318 by LaPorte et al. (hereinafter "LaPorte (LaPorte)") discloses a mobile retail loyalty network in which codes are generated from transactions. The customer scans/photographs the code and sends it to the loyalty server outside the point of sale. Therefore, LaPorte requires the user to own a mobile device and pre-enroll in the loyalty program. Therefore, LaPorte's technology does not provide a real-time point-of-sale solution.

US Patent Application No. 2007/0112632 to Voltmer et al. (hereinafter "Voltmer") discloses a system for networked loyalty programs. Voltmer discloses a technology that allows consumers to earn rewards at a network-wide level without retailers' direct participation in reward functions. This is accomplished by associating a consumer ID with a particular payment instrument such as the consumer's credit card, debit card account, and/or bank account. However, Voltmer does not offer a real-time point-of-sale solution.

Therefore, a solution is desired that overcomes the limitations of current point-of-sale (POS) device technology, including data processing terminals such as handheld devices (eg, VeriFone devices) that enable credit card transactions.

Some embodiments provide a method for efficiently enrolling new members (or updating existing member information) in a rewards or loyalty program when a consumer pays for goods or services. . A reward program can be associated with a merchant or a collection of merchants.

When a consumer initiates payment for goods or services (e.g., by swiping a credit card), in some embodiments information about the consumer (e.g., by retrieving information from the swiped credit card) may be automatically collected and pre-filled in various fields (eg, name, credit card number, etc.) of the digital registration form.

In some embodiments, additional information (eg, email address, phone number, user preferences, etc.) may be collected manually. The information collected may be used to enroll the consumer in a rewards program and automatically associate the payment method used by the consumer with the rewards account. Later, when the consumer uses the same payment method with merchants associated with the rewards program, some embodiments automatically update and/or apply the user's rewards information accordingly. good too. Similarly, if a consumer (after registering for an initial rewards program) uses the same payment method at different merchants associated with different rewards programs, the necessary registration information will automatically be obtained from the existing account and Applies to new reward accounts.

In some embodiments, "billing" information (which may include information related to receipts, purchase orders, invoices, online shopping cart or accounting information, and/or other suitable sources of information related to purchases). ) are collected and/or generated. Such information may include listings of goods and/or services, fees associated with each listing, and the like. In some embodiments, this information may be associated with various reward rules (eg, reward categories, reward rates, etc.) and/or other information (eg, payment method, merchant location, SKU, or inventory keeping unit number).

In some embodiments, a reward balance (or portion thereof) may be applied to claims and automatically redeemed based on received payment information. Redemption of such rewards may be based, at least in part, on a variety of suitable factors (eg, accumulated points, amount charged, type of purchase, user preferences or choices, etc.).

Information associated with each billing, registration, redemption, and/or other operation associated with some embodiments may be collected and provided to various parties. Such information may be collected at various suitable times and in various suitable manners (e.g., via a web-based dashboard, via one or more application programming interfaces (APIs)). .

An exemplary embodiment provides an automated method adapted to associate consumers with reward programs. The method includes providing an invoice to the consumer using a processing device, receiving payment information about the consumer, receiving biographical information about the consumer, and providing user information associated with a rewards program. and updating information about your account.

A second exemplary embodiment provides a software application configured to process payments and update reward program information. This software application generates an invoice for a set of goods or services provided to a consumer, receives a payment method from the consumer, determines a user account associated with the payment method, and includes a set of instructions for updating reward program information associated with the .

A third exemplary embodiment provides an automated method for facilitating redemptions related to reward programs. The method includes, at a payment processing device, receiving an invoice associated with a consumer's purchase, receiving payment information from the consumer, and retrieving user account information associated with the consumer, including a reimbursement balance. automatically applying at least a portion of the reimbursement balance to the bill; and processing the received payment information to settle the remaining portion of the bill.

The above summary is intended to provide a brief introduction to some embodiments of the technology disclosed herein. It is not intended to be an introduction or overview of all inventive subject matter disclosed in this document. The following Detailed Description, and the drawings (or "Figures") referenced in the Detailed Description, further describe the embodiments described in the Summary and other embodiments. Therefore, to understand all the embodiments described herein, a complete review of the Summary, Detailed Description and Drawings is required. Furthermore, the claimed subject matter is not limited by the illustrative details of the Summary, the Detailed Description and the drawings, as the claimed subject matter may be embodied in other specific forms as well. Defined by range.

The novel features of the technology disclosed herein are set forth in the appended claims. However, for illustrative purposes, some embodiments are shown in the following figures.

1 is a schematic block diagram of a conceptual system used by some embodiments; FIG.

2 is a schematic block diagram of a conceptual software architecture used by some embodiments of the system of FIG. 1; FIG.

1 is a schematic block diagram of a conceptual client-side software application provided by some embodiments; FIG.

1 is a schematic block diagram of a conceptual server-side software application provided by some embodiments; FIG.

1 is a data structure diagram of a conceptual data structure used by some embodiments; FIG.

4 is a flowchart of conceptual processes used to facilitate payment and/or registration according to some embodiments;

4 is a flowchart of a conceptual process used to perform new member registration according to some embodiments;

4 is a flowchart of a conceptual process used to apply reimbursement according to some embodiments;

4 is a flowchart of a conceptual process used to update information related to existing members according to some embodiments;

4 is a flowchart of a conceptual process used to optimize post-trade marketing according to some embodiments;

4 is a flowchart of a conceptual process used to provide analytical data to third parties according to some embodiments;

1 is a message flow diagram of a conceptual communication protocol used to facilitate payment and/or registration according to some embodiments; FIG.

FIG. 2 illustrates various graphical user interfaces (GUIs) and associated sub-elements provided by some embodiments that enable users to participate in one or more programs provided by some embodiments; is.

1 is a schematic block diagram of a computer system upon which some embodiments may be implemented; FIG.

1 is a block diagram of an exemplary computer network for data processing; FIG.

FIG. 4 is a block diagram of another example of a computer network for data processing;

FIG. 2 illustrates examples of messages exchanged in a data processing system;

The following detailed description describes and illustrates numerous details, examples, and embodiments. It will be appreciated by those skilled in the art that embodiments are not limited to those described herein and may be practiced without some of the specific details and examples described.

The following sections describe some more detailed embodiments. Section I conceptually describes the system architecture used by some embodiments. Section II describes the conceptual software architecture used by some embodiments. Next, Section III describes various methods of operation used by some embodiments. Section IV describes various exemplary GUI elements provided by some embodiments. Finally, Section V describes an example computer system on which some embodiments may be implemented.

I. System Architecture FIG. 1 shows a schematic block diagram of a conceptual system 100 used by some embodiments. Specifically, the diagram shows various communication paths between system elements. As shown in this figure, the system includes one or more merchants 110 each associated with one or more client devices 120 and a local server 130, and at least one remote server 140 associated with a set of storages 150. , a third party server 160 associated with a set of storages 170 , and one or more networks 180 .

Each merchant 110 may be a collection of physical (and/or virtual) devices associated with a single entity (eg, restaurant, retail store, plane, train, etc.). Each client device 120 may be an electronic device capable of receiving and processing payment information (e.g., a mobile device such as a smart phone or tablet, a POS device such as a cash register or terminal, a dedicated credit card swipe device, etc.) and may be a specific can be associated with merchants 110 of Each local server 130 may be an electronic device (eg, computer, network interface, etc.) capable of interacting with various client devices 120 associated with a particular merchant. In some embodiments, local server 130 may be capable of providing the functionality of client device 120 and operating without an associated client device. Each local server 130 has access to one or more networks. In some embodiments, client device 120 may operate without a local server (eg, client device may directly access one or more networks and/or perform other functions associated with local server 130). .

Remote server 140 may include a set of devices (eg, one or more computers) that can interact with each merchant 110 . Remote server 140 has access to a set of local storages 150, each of which can store (and/or retrieve) data and/or instructions. Remote server 140 and storage 150 may be associated with a first entity that can interact with merchant 110 (eg, via a mutually established protocol, using software provided by the first entity). Such first entity may perform payment and registration, redemption, and/or other suitable processes by interacting with Merchant 110 and/or a suitable third party.

Third party servers 160 may include a set of devices accessible by system 100 . Third party servers 160 have access to a set of local storages 170, each of which can store (and/or retrieve) data and/or instructions associated with the third party system. Third party servers 160 and/or storage 170 may be associated with various third party entities (eg, marketing systems, data mining systems, payment processing systems, etc.). Such so-called third-party entities may include entities associated with one or more merchants 110 (eg, regional restaurant chains with multiple franchisees, retailers with multiple store locations, etc.).

The set of networks 180 includes various local and/or distributed networks (eg, Ethernet, wireless local area or “Wi-Fi” networks, the Internet, cellular communications, etc.) accessed by various elements of the system 100. networks, etc.). In some embodiments, the set of networks 180 includes various devices (not shown) and/or other sub-elements such as servers that can enable interaction between one or more networks, devices, etc. It can include storage, interfaces, and the like.

The operation of system 100 is described in more detail in Section III.

Those skilled in the art will appreciate that system 100 can be implemented in a variety of different ways. For example, different specific elements may be added or omitted. As another example, different communication paths may be used. As yet another example, various single elements may be split into multiple elements and/or multiple elements may be combined into a single element.

Generally speaking, reward programs are useful but cumbersome to register, use, and redeem rewards. Loyalty programs are usually based on frequency, points, miles or cashback. To manage the program, providers use closed-loop loyalty cards, phone numbers, email, mobile phone applications, or registered credit cards. In all cases, registering the customer first is cumbersome. Customers typically have to go through multiple steps to create an account, which hinders account creation. Even if the consumer actually subscribes, the consumer must present the program's credentials in addition to the payment credentials, which can be difficult to remember, so this is also It interferes with using the program. If a customer fails to "earn" credit with a purchase even once because they forgot to provide their credentials and/or the cashier did not ask for their credentials, their evaluation of the program will skyrocket. to

Some believe that today's technological world makes customer loyalty easier. This is due to the prevalence of registered card loyalty programs. Customers can easily pay with a registered credit card and get rewarded. Registration card programs are either card-centric or merchant centric. A card-centric approach consists of a credit card issuer and a loyalty network transacting with the card issuer. Merchant-focused programs attempt to more systematically engage in-store customers through in-store marketing and incentives, but they are difficult to close, especially if immediate rewards are not provided to the customer. be.

In a card-centric program, even though the issuer has many cards enrolled in the program, very few cardholders swipe the enrolled cards at the merchants, and this is primarily because: This is because the cardholder does not know which merchants are participating in the program. This leads to poor customer performance at the merchant level in terms of amount paid per transaction and frequency of visits.

A merchant-centric approach may result in fewer potential members, but consumers will intentionally pay because they know they will register and be rewarded at the store, thus The average payout per transaction is often 30% or more higher than the average payout per transaction for non-members.

Embodiments disclosed herein are particularly useful for obtaining data from secure memory locations such as, for example, chips or magnetic strips placed on credit cards, receiving email input, and obtaining and receiving opt-in commands from users. provide computer technology that can be used to process computer transactions using information obtained from

Accordingly, the technology disclosed herein, in one aspect, not only facilitates communication, but also improves data entry tasks for user devices such as POS devices.

Some embodiments disclosed herein initiate a computer process after the card is swiped and before the credit card is authenticated. The software code may be embedded in a variety of ways within existing code for credit card transactions, thereby interrupting or pausing the existing credit card authorization process to facilitate obtaining authorization to confirm customer eligibility. Proceedings are started. At least one of the entities involved in the transaction (eg, the payment device, issuer network, gateway provider, or payment application itself) encrypts the card data and generates a unique ID. Prior to installing the software, the encryption party is determined according to the entity's wishes.

The unique ID may be different for each store. For example, at store A, the same 16-digit card is assigned a unique ID, which is the same but different than the unique ID created using the same 16-digit card at merchant B. may A unique ID may exist only within the context of a transaction, and thus may be of limited validity. The encryption may be a one-way encryption, ie the back calculation does not reveal the actual number sequence of the cards.

II. Exemplary Software Architecture Subsection II. A describes a conceptual software system provided by some embodiments. Next, subsection II. B describes client-side applications provided by some embodiments. Next, subsection II. 0 describes server-side applications provided by some embodiments. Finally, subsection MD describes conceptual data structures used by some embodiments.

A. System Level Example FIG. 2 illustrates a schematic block diagram of a conceptual software architecture 200 used by some embodiments of system 100 and/or other systems. Specifically, the diagram illustrates various conceptual software elements that allow the components of system 100 to interact. As shown, software architecture 200 includes one or more client-side applications 210, a set of POS software components 220, one or more server-side applications 230, a set of server databases 240, one or more server APIs 250, It includes a set of third party applications 260 , a set of third party databases 270 , one or more third party APIs 280 and a set of network elements 290 .

Client-side application 210 may be configured to be executed by a client device (eg, client device 120 described above), thereby enabling the client device to perform various system functions. Client-side application 210 receives information from one or more users (e.g., cashier, server, consumer, etc.) and communicates with POS software running on a local server (e.g., local server 130 described above). , provide information (eg, receipts, form information, etc.) to one or more users and/or consumers, and/or perform other suitable functions.

POS software 220 may be configured to be executed by a local server or other suitable device (eg, local server 130 described above), thereby enabling the local server to perform various system functions. good too. POS software 220 receives information from one or more users (eg, cashiers, servers, etc.) and/or a set of client-side applications and participates in one or more networks (eg, network 180 described above). Communicate via one or more network communication elements 290 to provide information (e.g., receipts, form information, etc.) to one or more users and/or consumers, and/or perform other suitable functions (e.g., receipts, form information, etc.) For example, receiving payment information, generating receipts, etc.).

Server-side application 230 may be configured to be executed by a remote server or other suitable device (eg, remote server 140 described above), thereby causing the remote server to perform various system functions. may Server-side application 230 communicates with sets of client-side applications (each set may be associated with a merchant) and one or more network communication elements participating in one or more networks (eg, network 180 described above). 290 and/or perform other suitable functions. In some embodiments, server-side application 230 may be implemented as a plug-in capable of driving the behavior of client-side applications and/or may be integrated into appropriate POS software.

Database 240 may include data stored using suitable storage (eg, storage 150 described above), according to some embodiments. Such data may include, for example, data relating to one or more merchants or sets of merchants, data relating to various consumers (e.g., information relating to purchases at participating merchants, loyalty account information, payment method information, etc.). ), and/or other suitable data. Database 240 may optionally be accessed via server-side application 230 or via one or more APIs 250 . Such APIs may allow various external entities (eg, third party analytics vendors, customer vendors, etc.) to access data stored in various databases 240 .

Third-party application 260 may be configured to be executed by a third-party server or other suitable device (eg, third-party server 160 described above), whereby third-party server may be used in some embodiments. It may be possible to interact with the system. Third-party applications 230 communicate with sets of client-side applications (each set may be associated with a merchant) and one or more network communication elements that participate in one or more networks (eg, network 180 described above). 290 and/or perform other suitable functions.

Database 270 may include data stored using suitable storage (eg, storage 170 described above), according to some embodiments. Such data may include, for example, data relating to one or more third parties (eg, payment processing entities, research providers, etc.) and/or other types of data. Database 270 may optionally be accessed via third party application 260 and may be accessed via one or more APIs 280 . Such APIs may allow various external entities (eg, server-side applications 230 , client-side applications, POS software, etc.) to access various data stored in database 270 .

Network communication element 290 may include various interfaces, protocols, etc., that allow various software components (and/or associated system elements) to communicate with each other.

FIG. 15A, which illustrates another network configuration 1500, shows a client device 1502 in communication with a transaction processor 1506 and a registration server 1508 via a communication network 1504. FIG. Some features of these devices are described herein.

Those skilled in the art will appreciate that architecture 200 can be implemented in a variety of different ways. For example, different specific elements may be added and some elements may be omitted. As another example, different communication paths may be used. As yet another example, various single elements may be split into multiple elements and/or multiple elements may be combined into a single element.

B. Client-Side Exemplary Embodiments FIG. 3 is a schematic block diagram of a conceptual client-side software application 300 (eg, client-side application 210 described above) provided by some embodiments. As shown, application 300 may include user interface (UI) module 310 , communication module 320 , payment module 330 , device control module 340 , local storage module 350 , and rewards module 360 .

UI module 310 may be configured to generate various user interface elements and/or process various user inputs. Such UI modules allow, for example, a user to enter information via a touch screen, which information is then collected by a client-side application.

Communications module 320 allows other elements of client-side application 300 to communicate with various external applications (e.g., server-side applications accessed over a set of network interfaces, local servers accessed over a local network, etc.). can interact.

The payment module 330 provides various functions related to payment processing, such as collecting payment information (eg, by receiving swiped credit card information or by receiving consumer-entered payment information). It may be configured to

Device control module 340 may be configured to enable client-side application 300 to appropriately interact with various client device components. For example, in some embodiments, device control module 340 allows application 300 to control touch screen elements associated with the device. As another example, a POS terminal may be instructed to display various instructions, forms, and the like.

Local storage module 350 may be configured to allow client-side application 300 to access local storage associated with the client device.

Rewards module 360 may interact with various remote servers, local servers, and/or third-party components to collect, analyze, and/or distribute reward information. Such information may be associated with loyalty or reward programs, which in turn may be associated with one or more merchants.

Those skilled in the art will appreciate that application 300 can be implemented in a variety of different ways. For example, different specific elements may be added and some elements may be omitted. As another example, different communication paths may be used. As yet another example, various single elements may be split into multiple elements and/or multiple elements may be combined into a single element.

C. Server-Side Exemplary Embodiments FIG. 4 illustrates a schematic block diagram of a conceptual server-side software application 400 (eg, server-side application 230 described above) provided by some embodiments. As shown, the application may include a third party access module 410, a communication module 420, a payment processing module 430, a rules engine 440, a storage access module 450, and a reward processing module 460.

Third party access module 410 allows system 400 to interact with various third party applications. Such modules 410 may include one or more APIs.

The communication module allows other elements of server-side application 400 to interact with various external applications (eg, client-side applications accessed over a set of network interfaces, third-party applications, etc.).

Payment processing module 430 collects payment information (eg, by receiving information from a client-side application), formats the information for submission to a third-party payment processor, and/or processes the information received from the payment processor. It may be configured to provide various functions related to payment processing, such as interpreting a set of responses.

Rules engine 440 may be configured to evaluate consumer information in relation to a set of programmatic criteria and generate an appropriate set of actions based on consumer (and/or third party) interactions. . For example, some reward programs may offer bonus rewards to first-time customers. As another example, some reward programs may provide various promotional materials based on consumer behavioral evaluations.

Storage access module 450 may be configured to allow server-side application 400 to access local storage associated with the server (eg, storage 150 described above).

Rewards processing module 460 may be configured to interact with various client devices, remote servers, and/or third-party components to collect, analyze, and/or distribute rewards information. Such information may be associated with loyalty or reward programs, which in turn may be associated with one or more merchants.

Those skilled in the art will appreciate that application 400 can be implemented in a variety of different ways. For example, different specific elements may be added and some elements may be omitted. As another example, different communication paths may be used. As yet another example, various single elements may be split into multiple elements and/or multiple elements may be combined into a single element.

D. Exemplary Data Structures FIG. 5 shows a data structure diagram of a conceptual data structure 500 used by some embodiments. Such data structures may be used by the software applications described above with reference to FIGS. As shown in FIG. 5, data structure 500 may include member accounts 510 and third party information 520 .

A member account element 510 may be associated with a particular user (or set of users such as a family, business, etc.) enrolled in a rewards program. A member account may include payment methods 530 (eg, credit card information, online payment account information, etc.) and biographic information 540 about the user (eg, name, email address, etc.). Transaction history 550 may include information related to previous interactions between users and merchants associated with reward programs.

Third party information 520 may include specific third parties (eg, merchants or groups of merchants, payment processing services, etc.). Third-party information elements include biographic information 560 (e.g., merchant name, type of reward program, etc.), set of rules 570 (e.g., criteria for sending offers to consumers, rules for generating rewards for users). criteria, etc.), template sets 580 (eg, forms, promotional email templates, etc.). Third party information 520 may be collected, updated, and/or otherwise maintained by the system of some embodiments (e.g., each set of rules may be associated with a merchant and maintained by the system). ).

Those skilled in the art will appreciate that data structure 500 is conceptual in nature, and different embodiments can implement the data structure in a variety of different ways. For example, in some embodiments additional specific elements and/or sub-elements may be added and/or specific elements and/or sub-elements may be omitted. As another example, various sub-elements may be combined as a single element, or a single element may be split into multiple sub-elements.

III. Exemplary Method of Operation Subsection III. A conceptually describes the payment process of some embodiments. Subsection III. B describes a conceptual registration process provided by some embodiments. Subsection III. 0 describes a conceptual redemption process provided by some embodiments. Subsection III. D describes the conceptual process used by some embodiments to update existing account information. Subsection III. E describes the conceptual process used by some embodiments to conduct post-trade marketing. Subsection III. F describes the conceptual process used by some embodiments to collect and provide user data. Finally, subsection III. G describes the message flows used by some embodiments to implement various operations.

The various processes described below use the hardware elements described above with reference to FIG. 1, the software components described above with reference to FIGS. 2-4, the data structures described above with reference to FIG. 5, and/or other may be implemented using various combinations of suitable elements of Additionally, the various processes (or portions thereof) described below may be combined in any suitable variety to provide a combination of various features (eg, payment and registration, payment and redemption of rewards, etc.).

A. Exemplary Embodiment of Payment Processing FIG. 6 is a flowchart of a conceptual process 600 used by some embodiments to make payments and/or registrations. Such a process may be initiated, for example, when a tabletop tablet device is used to present payment options to a consumer, when a server or cashier initiates a payment operation, and the like. Next, the process receives (at 610) a selection of payment options. The available options (cash payment, credit card payment, online account payment, etc.) may be displayed in any suitable manner (e.g., as a list or as a selectable set of buttons); Selections from options may be received in any suitable manner (eg, using a touch screen or using a display screen and keypad).

In some embodiments, the process may perform different sets of actions depending, at least in part, on the payment option selected (e.g., if "cash" is selected as the payment option, the process may simply charge can be viewed or printed and finished).

The process may then offer one or more incentives (not shown) to enroll in a rewards program and/or encourage the user to participate. Such offers can include, for example, marketing materials, one-time discounts, and the like. Next, the process may determine (at 620) whether the recipient of the offer is willing to participate in the rewards program. Such determinations may be made based on input received from the recipient, entered by the server or other collaborator, and/or made in any other suitable manner. If the process determines that the payee does not want to participate, the process may receive payment information (at 625) and process the payment (at 630). Such payment information may be received by a variety of suitable techniques (e.g., swiping a credit card, entering credit card or banking information, providing account information for web-based payment methods, etc.) processed to

On the other hand, if the process determines that the payee wants to participate, the process may receive (at 640) payment information. Such payment information may be received by any suitable technique (eg, swiping a credit card, entering credit card or banking information, providing account information for web-based payment methods, etc.).

Next, process 600 may determine (at 650) whether the payment information was recognized (and/or whether the user is an existing user). Such determination may be made in any suitable manner (e.g., by comparing payment information to an account database, or by prompting the user to indicate whether the user is a new or existing member). by).

In some embodiments, after a consumer has enrolled in a rewards program using a particular payment method, the user can use the same payment method without requiring additional action by the user. , is automatically recognized as an existing member. For example, when a user swipes a credit card for payment (e.g., using a fixed terminal or using a mobile device such as a tablet) and the credit card is determined to be associated with an existing account, Allow reward information to be updated and/or applied to claims without requiring the user to take additional selections or actions other than those necessary to process payments, as if the user were not registered. may

If the process determines (at 650) that the payment information is not recognized, the process performs registration (at 660) and creates an account (at 670). On the other hand, it determines (at 650) that the payment information is not recognized and that the user has already registered (eg, by receiving instructions from the user or by determining that an email is not already associated with the account). (not shown), the process may determine whether to update the account information associated with the user (e.g., by adding another payment method to the account). . Such determinations may be made based on various suitable factors (eg, user preferences, default settings, etc.).

The registration process can include asking the user to enter an email address and other information. In some embodiments, the payment method and information related to that method (e.g., payee name, address, etc.) may be retrieved from the payment information received at 620 (e.g., the consumer's name is stored in the account (which may be encoded with a number and/or other information on the magnetic strip on the back of a credit or bank card; the consumer's name may be obtained from a web-based payment service). Registration is described in more detail with reference to process 700 below.

Once the process 600 determines (at 650) that payment information has been recognized, the process can retrieve and/or update (at 680) account information associated with the user. Such searches and/or updates may communicate with a remote server or other element to determine the user's status (e.g., accumulated points, purchase history, etc.) and/or information regarding current interactions (e.g., payment amount, participation selection, etc.) to the server. Updating account information is described in more detail below with reference to process 900 .

After retrieving and/or updating account information (at 680) or performing registration (at 660) and creating an account (at 670), process 600 applies a reward to the account (at 690) and good too. In some embodiments, such rewards may be provided immediately (eg, by automatically reducing the consumer's payment amount). Alternatively, the user's account may be updated to reflect the additional rewards that have not been redeemed. In some embodiments, a user can select a reward from among a set of applicable rewards (not shown). For example, a list of options (eg, apply points to a balance or redeem points for additional products, etc.) may be presented and selections received from the listed options.

After applying the reward (at 690) or receiving the payment information (at 625), the process interacts (at 630) with (eg, a third party application and/or server) to perform the credit card transaction. , interacting with a web-based service, etc.) to process and complete payment for the transaction.

Process 600 can be performed in a variety of different ways. For example, different embodiments may include different acts, omit various acts, and/or perform acts in a different order than shown. Some embodiments may divide a process into a set of sub-processes and execute the process as a sub-process of a larger macro-process.

B. Registration Exemplary Embodiment FIG. 7 is a flowchart of a conceptual process 700 used to perform registration of new members according to some embodiments. Such a process may be performed, for example, when a user chooses to participate in a rewards program and is identified as a new member.

As shown, the process may retrieve (at 710) reward program information. Such information may include biographical information, rules, etc. regarding the merchant or chain. Next, the process retrieves (at 720) user information (eg, name and credit card number, username, etc.) associated with the payment method. Such information can be retrieved in a variety of suitable ways, depending on the payment method (for example, payment information and biographic information can be retrieved from data stored in a magnetic strip on a bank card when the card is swiped. may read or receive information from a third party).

The process may receive (at 730) additional user information. Such information can be obtained in a variety of suitable ways (eg, by providing a user interface with various form elements such as text fields, checkboxes, selection lists, etc. in which the user can enter information). Additional information may include contact information and/or biographical information (e.g., email address, social networking pages, date of birth, mobile phone number, zip code, etc.), user preferences (e.g., weekly email, electronic preferences such as receiving email daily), and/or other suitable information (eg, number of meals out per month, annual income, etc.). In some embodiments, various rewards, marketing materials, etc. can be based at least in part on contact information and/or biographical information.

The process may then associate (at 740) the payment method with the user's account information and generate (at 750) a user loyalty account. User loyalty accounts and associated payment methods may be stored using remote servers and storage.

The process can provide (at 760) rewards (eg, bonus rewards, instant rewards, etc.) and end. Such rewards may include a variety of suitable criteria (eg, amount spent, number of visits, user status (eg, new members, repeat customers, etc.), etc.). Such rewards can be based at least in part on a set of rules associated with the rewards program.

Process 700 can be performed in a variety of different ways. For example, different embodiments may include different acts, omit various acts, and/or perform acts in a different order than shown. Some embodiments may divide a process into a set of sub-processes and execute the process as a sub-process of a larger macro-process.

C. Exemplary Embodiments of Redemptions FIG. 8 is a flowchart of a conceptual process 800 used to apply redemptions according to some embodiments. Such a process is performed, for example, when an existing user makes a purchase using a registered payment method at a merchant associated with a rewards program.

As shown, the process 800 retrieves (at 810) rewards program information (eg, category, threshold, etc.) and then (at 820) receives payment information (eg, by swiped credit card). , then retrieves (at 830) the user information associated with the payment method. Such information may be retrieved using suitable systems and software in some embodiments. If necessary, new user information may be collected instead.

Next, the process determines (at 840) redemption options (eg, apply points to purchases, receive gifts or promotional items, etc.). Such redemption options may be included in the retrieved rewards program information. Next, the process can receive (at 850) a selection of a redemption option (e.g., by receiving user input, performing a default selection, etc.) and (at 860) associated with a number of reward points (e.g., The selected option can be applied (by deducting an amount from the bill, applying a promotional reward such as a free dessert, etc.). Finally, the process can apply (at 870) payment (eg, by sending credit card information to a third party processor) and exit.

Process 800 can be implemented in a variety of different ways without departing from the spirit of the invention. For example, different embodiments may include different acts, omit various acts, and/or perform acts in a different order than shown. Some embodiments may divide a process into a set of sub-processes and execute the process as a sub-process of a larger macro-process.

D. Account Update Exemplary Embodiment FIG. 9 depicts a flowchart of a conceptual process 900 used by some embodiments to update information associated with an existing member. Such a process may occur, for example, when a user chooses to participate in a rewards program and is identified as an existing member. Alternatively, an existing member can make a selection indicating that the user's information (eg, payment method, address, preferences, etc.) has changed. As another example, an existing user can make a payment using a payment method that is not yet associated with a rewards account (e.g., using a new credit card and confirming that the user has previously registered may be shown). In some embodiments, the process may run automatically if the new credit card (or other payment method) is not recognized.

As shown, the process retrieves reward program information (at 910) and receives user information (at 920). Such information may include biographical information, rules, etc. regarding the merchant or chain. Such user information may include user account information (e.g., username and password, email address, etc.) and/or user information updates (e.g., new payment methods, additional or updated phone numbers, updated electronic email address, etc.). For example, if the user swiped an unrecognized credit card and indicated that the user was an existing user, the email address (or username and password, and/or other suitable identification information).

Next, the process retrieves (at 930) user account information. User account information may include biographic information, payment method information, information related to interaction history, and/or other suitable data. Such account information may be retrieved based at least in part on the user information received at 920 (e.g., account associated with the user using a username or email address provided by the user). to retrieve account information).

The process may then update the user account information (at 940) as needed. For example, if a credit card not associated with any user account was used for payment, but the user made a selection indicating that they have an existing account, the new payment method may be associated with the existing account ( Therefore, it may be automatically recognized along with other valid payment methods in the future).

Process 900 may provide a reward (at 950) and end. Such rewards can be based on a variety of suitable criteria (eg, amount spent, number of visits, user status (eg, new members, repeat customers), etc.). Such rewards may also be determined based at least in part on a set of rules associated with the rewards program.

Although process 900 has been described with reference to the example of a user adding a new payment method to an existing rewards account, a similar process can be used to add an existing payment method to a new rewards account. For example, if a user has an existing rewards account with a payment method associated with a first merchant, and the user applies that payment method to a second merchant as well, then in some embodiments Automatically recognize the existence of an account with one merchant and apply user information (e.g., name, email, address, zip code, social media information, etc.) to account associated with a second merchant may be created.

Process 900 can be performed in a variety of different ways. For example, different embodiments may include different acts, omit various acts, and/or perform acts in a different order than shown. Some embodiments may divide a process into a set of sub-processes and execute the process as a sub-process of a larger macro-process.

E. Post-Trade Marketing FIG. 10 shows a flowchart of a conceptual process 1000 used by some embodiments to optimize post-trade marketing. Such processing may be performed at regular intervals (e.g., hourly, daily, weekly, etc.) and may be performed on various criteria (e.g., new user sign-ups, updates to existing accounts, during holidays, at specific times of the day). etc.) and/or other appropriate times (e.g., when a retailer initiates a promotional offer, when a threshold such as a spending threshold is reached, based on transaction history, customer based on spending behavior, etc.).

Such a process may trigger various suitable actions such as receipt delivery (eg, email receipt with marketing offer, send marketing email with coupon, etc.). In some embodiments, the receipt may include a selectable element (e.g., URL) that allows the user to provide information about the expense (e.g., who to meet, what was discussed, etc.). , which can be compiled for use by the user (eg, when the user prepares tax documents).

As shown in this figure, the process may retrieve (at 1010) a database entry. Such database entries may be associated with reward program transactions performed using some embodiments. Next, the process determines (at 1020) whether the transaction includes new members. If the process determines that the transaction involves a new member, the process retrieves (at 1030) third party information. Such third-party information may include marketing information (e.g., email templates, promotional content, etc.), which may be obtained from merchants, chains, marketing companies, and/or other suitable third parties. You may

After obtaining the third-party information (at 1030) or determining (at 1020) that the transaction does not involve new members, the process begins (at 1040), at least in part, with the user's transaction history and a set of marketing rules. Marketing information may be generated based on. Next, the process retrieves (at 1050) an appropriate marketing template (eg, email template) and sends (at 1060) the marketing information to the member.

Process 1000 can be performed in a variety of different ways. For example, different embodiments may include different acts, omit various acts, and/or perform acts in a different order than shown. Some embodiments may divide a process into a set of sub-processes and execute the process as a sub-process of a larger macro-process.

F. Merchant Dashboard In some embodiments, various merchants (or "users"), such as merchants, merchant groups, marketing organizations, etc., may have access to user (ie, consumer) data. Such data may include any information related to a user's purchases made using the system of some embodiments. This information may include user status information (e.g. new registrations, existing members, purchase history, zip code, social media account information, etc.), payment information such as payment methods, purchase information (e.g. invoices, list of items, total amount, time stamp, place of purchase, etc.), merchant information (e.g., type, location, size, promotion, etc.), reward information (e.g., unpaid reward points, redeemed reward points, etc.), and/or in some embodiments It can contain other information that can be compiled by the system.

User data can be collected and/or compiled in a variety of suitable ways. For example, in some embodiments, user data is continuously collected as user data is received (eg, when a user registers, when a user pays a registered merchant, etc.). As another example, user data can be collected from various vendors at various suitable times and/or in various suitable manners (e.g., stores may provide information at regular intervals; Chain may provide information formatted in a particular way, etc.). Such user data may include consumption behavior, redemption behavior, statistical information, social media behavior (e.g. counting "likes" by registered users, sharing links with "friends", forwarding messages or links, etc.), etc. can include Data may be collected and/or made available in real-time (i.e., data may be immediately available to various users as it is fed into the system of some embodiments). . Further, in some embodiments, data so collected may be used (e.g., to reward users for "liking" a product or service, or awarding additional points when a user shares a link). may be used to provide rewards to registered users (such as by giving away).

FIG. 11 depicts a flowchart of a conceptual process 1100 used by some embodiments to provide analytical data to third parties. In some embodiments, such processes may be performed continuously upon receipt of user information.

The process may receive (at 1110) a request (or "query") for user information. Such user information may be aggregated in a variety of suitable ways, depending on the wishes of the merchant requesting the information (e.g., all users who have purchased more than a threshold amount over the most recent time period, specific all users who registered within the time frame of Such requests may be made in any suitable manner (e.g., via an API, via a website or other similar portal, by application of some embodiments, as a formatted message, etc.). can receive. The request may include various pertinent parameters (eg, consumer type, merchant type, purchase amount, etc.), which may be used to identify pertinent information based on the request.

The process may then retrieve (at 1120) the requested user information. Such information may be retrieved, for example, by accessing remote storage in some embodiments. Process 1100 may then compile (at 1130) the retrieved information. This information can be compiled in a variety of suitable ways (eg, based on requested elements, based on user preferences, based on various protocols, etc.).

Finally, the process can provide (at 1140) the compiled information to the requestor and terminate. Information may be provided in any suitable manner and/or format, based on any suitable criteria, parameters, and the like.

Process 1100 can be performed in a variety of different ways. For example, different embodiments may include different acts, omit various acts, and/or perform acts in a different order than shown. Some embodiments may divide a process into a set of sub-processes and execute the process as a sub-process of a larger macro-process.

G. Exemplary Message Flow FIG. 12 illustrates a message flow diagram of a conceptual communication protocol 1200 used by some embodiments to make payments and/or registrations. As shown, communication protocols are conducted between various devices including client device 1210 , local server 1220 , remote server 1230 and third party server 1240 . The elements and message flow of FIG. 12 are for illustrative purposes only. Many different message flows occur depending on various relevant factors (e.g., available system elements and/or subelements, user selection, approval and/or denial of various requests to third parties or external systems, etc.) there's a possibility that.

In this example, client device 1210 may be associated with a restaurant's server, local server 1220 may be a POS system used by the restaurant, and remote server 1230 may be provided by the system of some embodiments. Third party server 1240 may include a set of remote devices provided by a third party payment processor.

In operation, a server can initiate a checkout for a customer by making a selection using the client device and client-side application of some embodiments. Such selection may cause message “a” to be sent from client device 1210 to local server 1220 . Local server 1220 may compile the invoice or bill associated with the customer and send a response 'b' containing the invoice (eg, list of items purchased by the consumer, applicable taxes, etc.) .

The client device 1210 can then include the invoice sent in response "b" and information regarding the user's payment method (eg, credit card information swiped with the client device 1210) along with the processing request. Message “c” may be sent to remote server 1230 . Additionally, message "c" may include information regarding user registration (for new users) and/or updated payment information (eg, for existing users adding a new payment method). Such messages may contain transaction information (e.g., bill amount, merchant location, etc.) related to the interaction with the consumer, which may be used to update rewards program information associated with that user. good.

Remote server 1230 may receive message 'c', generate request 'd', and send it to third party server 1240 for processing. Such requests may include payment information (eg, credit card number, name, authorization code, etc.), payment amount, and/or other suitable information. The third party server may analyze request "d" and determine whether to process the payment. Such determinations may be made based on various suitable criteria (eg, user credit limit, merchant reputation, etc.).

Third party server 1240 may send a response “e” to remote server 1230 authorizing or denying the payment request. Such responses may include various authorization codes, identification information, and the like. The remote server may then send a response “f” to client device 1210 indicating the result of the payment transaction and/or any relevant information.

If the payment is declined, the client device 1210 may prompt the user to enter another form of payment and repeat messages "c"-"f" until the payment is authorized. At that point, client device 1210 can send a confirmation message “g” to local server 1220 indicating the outcome of the payment transaction. The local server may return a message 'h' indicating that the payment has been applied and the consumer transaction has been completed.

Client device 1210 may then send message “j” to third party server 1240 confirming the completed transaction. Finally, client device 1210 can send a termination message “k” to local server 1220 indicating that the consumer transaction has been completed and all information has been sent to remote server 1230 .

Those skilled in the art will appreciate that message flow diagram 1200 is for illustrative purposes only and that different embodiments can communicate in a variety of different ways. For example, in some embodiments, a client device may not be able to communicate directly with a remote server and instead need to relay messages through a local server. As another example, in some embodiments a client device may communicate directly with a third party server without using a remote server. Further, different embodiments may send different sets of messages between different devices and/or in different orders than shown.

Some embodiments of a data communication system capable of user-controlled real-time data processing are described with reference to Figures 15A and 15B. A user, e.g., a consumer or customer who pays a bill or makes a financial transaction, or otherwise controls the processing of data, either by explicit control on a transaction-by-transaction basis or by prior user selection or remotely Data processing steps can be controlled based on implicit controls from transactions conducted on the deployed server.

FIG. 15A shows an exemplary data communication system 1500 that includes a client device 1502 that a consumer uses to enter payment information and program enrollment options into the data communication system and, via communication network 1504, a A transaction processor 1506 communicatively connected to a client device for receiving entered payment information and program registration options and determining a response to the client device 1502; a registration server 1508 communicatively connected to modify payment amounts from entered payment information based on a predefined set of rules and consumer status, and a unique personal account number associated with each consumer; and a registration server 1508 that includes a database that stores the . Client device 1502 may be, for example, client device 120 . Transaction processor 1506 may be similar to remote server 140 .

FIG. 15B illustrates that a transaction processor 1556 (substantially similar to transaction processor 1506) and a registration server 1558 (substantially similar to registration server 1508) are co-located on a single hardware platform and the internal data bus of the computer system. 1550 illustrates an exemplary embodiment of a data communication system 1550 that operates similarly to data communication system 1500, except that they can communicate with each other via an internal communication mechanism that is either a software application programming interface (API) or a software application programming interface (API). In such embodiments, registration server 1558 uses explicit user selections, e.g., opt-in menu selections, and/or implicit user actions, e.g., accumulation of user rewards based on the user's previous transactions. , modify the data being processed by the transaction processor 1556 . For example, when a transaction processor receives a data processing request in real-time, the transaction processor transmits to registration server 1558 data (eg, purchase amount) and information regarding the identity of the customer or user for whom the transaction is being processed. Registration server 1558 can then modify the transaction, for example, by offering a discount to the user, and may return this result to transaction processor 1556 in real time. Payment processing for credit card payments is a mostly automated process and currently there are no technical solutions to alter the flow of payment processing while maintaining real-time responsiveness to paying consumers. does not exist.

By using the techniques disclosed herein, it is possible to interrupt the payment processing flow and make changes to the payment data while maintaining the real-time nature of the payment. The process of changing the final payment amount can be expedited by using a unique identifier to track the consumer. Further, by associating the payment data with the consumer's choice as to whether the consumer wishes to receive a change benefit, e.g., a discount on payment, the speed of processing is maintained, thereby allowing the , eliminating the need to fill out multiple menu screens or physical forms. Thus, by using the registration server 1558 in conjunction with the transaction processor 1556, it can be determined in real-time whether a consumer is a known member of the rewards program and, if not, the consumer is You can specify whether you want to enroll in the program.

FIG. 16 depicts a message flow diagram of a conceptual communication protocol 1600 used to perform data processing according to some embodiments. As shown, communication protocols take place between various devices including client device 1602 (which may be similar to 1502 or 1210), processing server 1604 (eg, remote server 1230), and registration server 1606. . The elements and message flow of FIG. 12 are for illustrative purposes only. Many different message flows occur depending on various relevant factors (e.g., available system elements and/or subelements, user selection, approval and/or denial of various requests to third parties or external systems, etc.) there's a possibility that.

Client device 1602 may send message 1610 to processing server 1604 representing a commercial transaction, eg, a credit card payment. Message 1610 may contain information that uniquely identifies the user, such as a credit card number, the amount applied to the user's balance, the user's phone number, or email address. Message 1610 may also include a field indicating that the user wishes to select a subscription plan.

Upon receiving message 1610, processing server 1604 sends message 1612 to registration server 1606 depending on whether the user has indicated an opt-in. Processing server 1604 may send information identifying the user to registration server 1606 in message 1612, along with additional information of its own, such as the user's email address and phone number.

Registration server 1606 processes the received user information and generates and sends message 1614 to processing server 1604 indicating whether the user is registered and whether to apply a discount to the user's payment. Processing server 1604 then sends message 1616 completing the data processing transaction running on client device 1602 . Processing server 1604 may then send transaction completion message 1618 to registration server 1606 . Processing server 1604 receives confirmation message 1620 from the registration server and completes the transaction. Thus, in one advantageous aspect, the communication protocol allows the consumer or user to control the transaction data processed on the processing server 1604, allowing the consumer's preference to choose or decline a transaction. Adjustments can be made to the transaction data in real-time based on , and transaction amounts can also be changed based on similar transactions previously executed by consumers (eg, loyalty rewards).

In some embodiments, the method of performing real-time data processing includes personal information about the consumer, information about the payment the consumer intends to make, and information about the consumer desiring to opt into a loyalty registration program. receiving a first message containing data and, if the received card payment is associated with an existing user account of the consumer, whether the personal information received in the message is already associated with an existing user account; if the received card payment is not associated with an existing user account, updating information about the existing user account, associating the received card payment with the existing user account; changing information about the payment the consumer is about to make; and sending a second message containing the changed information about the payment and additional information for display to the consumer. In some embodiments, the modification includes searching in real-time for a set of rules related to rewards for user accounts and evaluating information about existing user accounts based at least in part on the set of rules. and determining, based at least in part on this evaluation, the reimbursement applicable to the payment the consumer intends to make, wherein the at least one reward, under the Loyalty Rule, is determined by the consumer including at least one of an immediate reward and an unpaid reward that reduces the amount of the payment that the company intends to make.

IV. Examples of Graphical User Interface (GUI) Elements FIG. 13 illustrates various GUIs 1310 provided by some embodiments that enable users to participate in one or more programs provided by some embodiments. 1340 and related sub-elements are shown. Such a GUI can be presented using a suitable client device (eg, client device 120 above).

As shown, GUI 1310 can include first graphical element 1350 , second graphical element 1355 , and a set of selection elements 1360 . In this example, a first graphic element 1350 may include a registration offer (eg, register now to receive instant rewards), and a second graphic element 1355 may include registration benefits and/or other information. Listings (eg, "5% off next purchase", "Free to Join", etc.) can be included. The set of selection elements 1160 may include buttons or other selectable elements with various suitable selection option labels (e.g., "Yes, register", "No, do not register", " "Already a member", "Add a new payment method", etc.).

GUI 1320 can include multiple graphical elements 1365 - 1370 , one or more input elements 1375 , and various selection elements 1360 . Graphic element 1365 can include a set of instructions for registration, and graphic element 1370 can include a combination of displayed text and text entry fields (eg, name, card number, email, etc.). can. Each input element 1375 allows the user to accept terms of use, privacy policy, etc. (eg, by checking a box). Selection element 1360 may include various options (eg, registration, accounting, etc.).

The GUI 1330 can include a graphical element 1380 and a selection element 1360 (eg, go to signature) that can display a summary of the user's claim to which the reward has been applied (if applicable). GUI 1340 can include input element 1385 (eg, an area where a user can enter a signature on a touch screen device) and selection element 1360 (eg, accept signature).

It will be apparent to those skilled in the art that different embodiments may include different GUI elements than those shown in the example of FIG. For example, some embodiments may include various GUIs intended for use by servers or cashiers, and suitable elements for such use (e.g., table selection elements, menu selection elements, etc.). can include As another example, while various GUIs are shown in portrait orientation, different embodiments (and/or different GUIs) may use landscape orientation (and/or can automatically shift between portrait and landscape orientations). may be used).

V. Example Computer System Many of the processes and modules described above can be implemented as software processes specified as at least one set of instructions recorded on a non-transitory storage medium. When these instructions are executed by one or more computing elements (e.g., microprocessors, microcontrollers, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), etc.), this An instruction causes a computational element to perform the operation specified in the instruction.

FIG. 14 conceptually illustrates a schematic block diagram of a computer system 1400 upon which some embodiments may be implemented. For example, the system described above with reference to FIG. 1 can be at least partially implemented using computer system 1400 . As another example, the processes described with reference to FIGS. 6-10 may be implemented, at least in part, using a set of instructions executed using computer system 1400. FIG.

Computer system 1400 can be implemented using various suitable devices. For example, computer systems may include one or more personal computers (PCs), servers, mobile devices (eg, smart phones), tablet devices, and/or any other suitable device. The various devices may operate alone (eg, the computer system may be implemented as a single PC) or in conjunction (eg, several components of the computer system). components may be provided by mobile devices and other components may be provided by tablet devices).

Computer system 1400 includes a bus 1405, at least one processing element 1410, system memory 1415, read-only memory (ROM) 1420, other components (eg, graphics processing unit) 1425, input devices 1430, output devices 1435, permanent storage Device 1440 and/or network interface 1445 may be included. Components of computer system 1400 may be electronic devices that operate automatically based on digital and/or analog input signals. For example, the various examples of GUI elements described above with reference to FIG. good.

Bus 1405 represents all communication paths between the elements of computer system 1400 . Such paths may include wired, wireless, optical, and/or other suitable communication paths. For example, input device 1430 and/or output device 1435 may connect to system 1400 using a wireless connection protocol or system. Processor 1410 may read instructions to be executed and data to be processed from components such as system memory 1415, ROM 1420, and permanent storage device 1440 in order to perform the processes of some embodiments. Such instructions and data may be passed over bus 1405 .

ROM 1420 may store static data and instructions that processor 1410 and/or other elements of the computer system can use. Permanent storage device 1440 may be a read/write memory device. This device may be a non-volatile memory unit that stores instructions and data even when computer system 1400 is turned off or unpowered. Permanent storage devices 1440 may include mass storage devices, such as magnetic or optical disks and their corresponding disk drives.

Computer system 1400 may also use removable and/or remote storage devices as permanent storage devices. The system memory 1415 may be volatile read/write memory such as random access memory (RAM). System memory can store some of the instructions and data that the processor uses at runtime. Sets of instructions and/or data used to implement some embodiments may be stored in system memory 1415 , permanent storage device 1440 and/or read-only memory 1420 . Other components 1425 can perform various other functions.

Input devices 1430 allow a user to provide information to the computer system and/or manipulate various operations of the system. Input devices may include keyboards, cursor control devices, audio input devices and/or video input devices. Output devices 1435 may include printers, displays, and/or audio devices. Some or all of the input devices and/or output devices may be wirelessly or optically connected to the computer system.

Finally, as shown in FIG. 14, computer system 1400 may be connected to network 1450 via network interface 1445 . For example, computer system 1400 may connect to a web server on the Internet such that when a user interacts with an interface running within a web browser, the web browser running on computer system 1400 communicates with the web server. can interact with In some embodiments, network interface 1445 may include one or more APIs. Network interfaces and associated networks 1450 allow the system 1400 to access various remote storage 1460 and/or other external components 1465 (eg, third party servers).

The terms "computer," "server," "processor," and "memory" as used herein and in the claims all refer to electronic devices. These terms exclude persons or groups of persons. As used herein and in the claims, the term "non-transitory storage medium" is strictly limited to tangible physical objects that store information in a form readable by electronic devices. These terms exclude radio signals or other transient signals.

It will be appreciated by those skilled in the art that any or all of the components of computer system 1400 can be used in conjunction with the embodiments disclosed herein. Furthermore, it will be apparent to those skilled in the art that many other system configurations can be used in conjunction with the invention or components of the technology disclosed herein.

It will also be appreciated by those skilled in the art that a user can be identified using a unique identifier derived from unique user information such as, for example, a primary account number (PAN). If this PAN is revoked (lost or stolen) and a new PAN is created by the issuer, the previous unique ID may be automatically associated with the new PAN. This also allows updating the unique ID directly associated with the card issuer itself.

The techniques disclosed herein can also be used to collect rating information from users, for example, by reviewing services or products they have received and completing satisfaction surveys. For example, if the user's rating is below a preset threshold, the SMS may send this to the manager, alerting him of the user's dissatisfaction.

If an existing member made a cash payment at a merchant, the conventional technology did not allow the member to receive credit for the transaction. Alternatively, using the technology disclosed herein, upon completion of a transaction, the user interface can provide the customer with a web link, which the customer can use to upload receipt information and redeem cash transaction rewards. can receive.

If a customer wishes to pay with a mobile phone that uses near field communication (NFC) technology, in addition to submitting payment credentials, the customer will require that the registration server uniquely identify the user. A unique ID credential can be sent containing all the same information used to identify it. Advantageously, the user can actually bypass entering information on the POS and simply send this along with the payment including the opt-in to receive the instant discount.

Some companies can now use beacon transmissions to track the movement of Bluetooth-enabled mobile phones. However, beacon tracking mechanisms are not connected to the transactions that are actually taking place, and are therefore challenged in that they are unable to bridge the gap between tracking customer movements and customer transactions. ing. By using cell phone-specific information to execute transactions, the technology disclosed herein can track users, match other users when they come in, and compare these movements to transactions. to finally determine which phone belongs to which unique ID.

In some embodiments, when an existing member known to registration server 1606 enters a new store and their card is swiped to pay, a unique ID is triggered at the registration server. This correlation may be used to automatically populate the user's email field with an existing email address on file linked to the unique ID linked to the PAN the customer is using.

In some embodiments, customers may sign up for a merchant's rewards program and, instead of receiving redemptions earned by spending at that particular merchant, donate those redemptions to a non-profit organization.

Some embodiments may be implemented in the form of a non-transitory computer-readable storage medium storing software applications that, when executed by one or more computers, cause Allow payments to be processed and reward program information updated by merchants, which includes generating invoices for a set of goods or services offered to consumers and receiving payment methods from consumers. and displaying a user interface on the payment processing device, the user interface configured to receive additional personal information uniquely identifying the customer on the payment processing device, the additional personal information is performed by including at least one form element, sending personal information to a first server, and receiving at least one reward from the server. The first server is configured to identify at least one reward based on the at least one form factor using an application programming interface, the application programming interface in communication with the one or more servers. Determine whether an existing user account for the merchant's rewards program is configured and associated with the payment method. The server updates reward program information associated with the existing user account based at least in part on the invoice for the particular existing user account with which the received payment method is determined to be associated, and at least the reward program is configured to create a new user account associated with the rewards program for the consumer based on the payment method for the consumer who does not have an existing user account with the consumer. In some embodiments, the payment method is or is ultimately linked to a credit card. In some embodiments, the rewards program is associated with one of a restaurant, grocery store, auto service provider, mobile operator, e-commerce site, retailer, or the like. In some embodiments, the software application presents rewards program offers based at least in part on the updated rewards program information for a particular existing user account determined to be associated with the received payment method. Contains the instruction set to generate. In some embodiments, the software application further includes a set of instructions for creating new user accounts. In some embodiments, the software application further includes a set of instructions for generating instant rewards and providing rewards to consumers. In some embodiments, the software application includes a client-side application executed by a client device configured to be communicatively coupled with the server-side application. Methods according to some embodiments can be described using the following sections.

Section 1: A method of facilitating a consumer to enroll in a rewards program while paying for a purchase using a payment processing device having a user interface, the method comprising: , presenting the consumer with an invoice associated with the consumer purchase; receiving payment options selected by the consumer in response to the invoice; prompting the consumer to choose from one of the options of enrolling in the rewards program as a user, (2) having an existing user account with the rewards program, or (3) electively not enrolling in the rewards program; and, in response to selection of option (1) by the consumer, receiving payment information and making payment for the payment option selected by the consumer; and creating a rewards program user account based at least on the payment information. and displaying a user interface on the payment processing device, the user interface configured to receive additional personal information and uniquely identify the customer on the payment processing device; an additional individual on a first server configured to include at least one form element and to identify at least one promotional reward based on the at least one form element using an application programming interface; Transmitting the information includes the application programming interface being configured to communicate with one or more servers and confirming the payment to include the reward from the reward program.

Clause 2: The method of clause 1, further responsive to the consumer's selection of option (2), receiving payment information for a consumer-selected payment option to effect payment. determining whether the received payment information is associated with an existing user account; and, for the particular existing user account with which the received payment information is determined to be associated, an existing user account associated with the rewards program. updating information about user accounts of at least based on invoices; otherwise updating existing user accounts by associating received payment information with existing user accounts; and rewards from reward programs and confirming the payment to include.

Clause 3: The method of paragraph 1, further comprising, in response to the consumer's selection of option (3), receiving payment information for the consumer-selected payment option to effect payment. and confirming payment.

Clause 4: The method of Clause 1, wherein the selected payment option is credit payment.

Clause 5: The method of Clause 1, wherein the received payment information includes credit card information.

Clause 6: The method of Clause 1, wherein creating the rewards program user account includes receiving input of an email address from the consumer.

Clause 7: The method of Clause 1, wherein creating a rewards program user account further comprises receiving one or more of a mobile phone number, a date of birth, and a zip code.

Another method according to some embodiments can be described using the following section.

8. A method of facilitating a consumer to enroll in a rewards program while paying for a purchase using a payment processing device having a user interface, the method comprising: Presenting invoices related to consumer purchases to consumers, receiving payment information from consumers to make payments, and enrolling in rewards programs to receive instant discounts are communicated to consumers on a user interface. receive consent from the consumer to enroll in the rewards program; create a rewards program user account based on at least the payment information; and display a user interface on the payment processing device; A user interface configured to receive additional personal information to uniquely identify the customer on the payment processing device, the additional personal information including at least one form factor; transmitting, using the interface, additional personal information to a first server configured to identify at least one promotional reward based on at least one form element, the application programming interface comprising: configured to communicate with one or more servers; and confirming payment to include an instant discount.

Clause 9: In the method of Clause 8, prompting the consumer to register includes prompting the consumer to enter an email address, and receiving consent from the consumer includes emailing the consumer from the consumer. Including receiving email addresses.

Clause 10: The method of Clause 9, wherein creating a rewards program user account further comprises linking an email address to the user account.

Clause 11: The method of Clause 8, wherein receiving payment information includes receiving credit card information using a credit card swipe element.

Furthermore, while the examples above show many individual modules as separate elements, it will be apparent to those skilled in the art that these modules may be combined into a single functional block or element. It will also be apparent to those skilled in the art that a single module can be split into multiple modules.

Although the technology has been described with reference to many specific details, it will be apparent to those skilled in the art that the technology may be embodied in other specific forms. For example, some embodiments have been described with reference to specific features and/or components. However, it will be apparent to those skilled in the art that other embodiments may be implemented with other types of features and components. It will be apparent to those skilled in the art that the present invention is not limited by the exemplary details set forth above, but is defined by the claims that follow.

Claims (18)

In an automated method of associating consumers with reward programs,
Presenting an invoice to a consumer using a payment processing device at the merchant's point of sale;
receiving data related to card payments from the consumer as a result of the card being presented to the payment processing device;
displaying a user interface on the payment processing device, the user interface configured to receive additional personal information that uniquely identifies the consumer on the payment processing device; the personal information includes at least one form element;
displaying a menu prompting the consumer on the user interface and receiving input from the consumer regarding a payment process for the bill, the input from the consumer comprising: receiving, including selecting to participate in the reward program;
receiving additional personal information that uniquely identifies the consumer via the payment processing device;
using a beacon tracking mechanism to capture the movement of the consumer's mobile phone visiting the merchant;
Identifying, by the payment processing device, the mobile phone of the consumer attempting the payment based on the obtained movement of the mobile phone and obtaining information specific to the identified mobile phone. and
from the payment processing device to a transaction processor performing the payment processing of the invoice, data related to the card payment, input from the consumer, the additional personal information , and information specific to the mobile phone; and
If input from the consumer indicates that the consumer desires to participate in the rewards program, the transaction processor interrupts the payment processing of the bill and directs the card payment to a registration server. transferring data associated with the mobile phone, input from the consumer, the additional personal information , and information specific to the mobile phone;
modifying data associated with the card payment with the registration server while maintaining real-time nature of the payment process, comprising:
Said changing includes:
identifying at least one reward based on the at least one form element using an application programming interface configured to communicate with one or more servers;
determining if the data associated with the received card payment is associated with an existing user account of the consumer;
If the received card payment related data is associated with an existing user account of the consumer, updating information about the existing user account;
if the received card payment related data is not associated with the existing user account, creating a new user account based on the received card payment related data ;
associating information unique to the consumer's mobile phone with an ID unique to the consumer;
changing data associated with the card payment based on the reward and sending a message to the transaction processor indicating the change;
modifying, including
sending, by the transaction processor, a message to the payment processing device indicating completion of processing of the card payment using the modified data associated with the card payment. 2. The method of claim 1, wherein said card payment comprises a direct payment from a credit card or a payment not paid directly from a credit card but ultimately linked to a credit card. 2. The automated method of claim 1, further comprising associating the data associated with the card payment with a system-generated unique identifier associated with the existing user account. In claim 1,
The automated method further comprising retrieving existing user account information if it is determined that the card payment related data is associated with the existing user account. 5. The automated method of claim 4, wherein updating information about the existing user account includes modifying the existing user account information based at least in part on the bill. 5. The automated method of claim 4, wherein updating information about the existing user account includes modifying the existing user account information based at least in part on data associated with the card payment. In claim 1,
retrieving a set of rules associated with the reward program from the one or more computers;
Evaluating information about the existing user account based at least in part on the set of rules;
determining the compensation to be applied to the bill based at least in part on the valuation, wherein the at least one compensation comprises at least one of an immediate compensation or an unpaid compensation;
and processing to confirm the card payment. 2. The automated method of claim 1, wherein the additional personal information includes at least one of the consumer's social media profile, email address, mobile phone number, or zip code. 2. The automated method of claim 1, further comprising sending a marketing offer generated based on the consumer's spending behavior. 2. The method of claim 1, further comprising sending an electronic receipt to the consumer, or sending both an electronic receipt and a marketing offer generated based on the consumer's spending behavior. automated methods including; 11. The automated method of claim 10, wherein sending an electronic receipt to the consumer comprises emailing the electronic receipt or sending the electronic receipt to the consumer's mobile phone. Method. 3. The method of claim 1, wherein a mobile device is used at the point of sale of the merchant. 3. The automated method of claim 1, wherein the input from the consumer is to enroll in the rewards program to receive instant rewards discounts. 2. The automated method of claim 1, wherein providing the bill includes providing the bill on a screen externally connected to the payment processing device. A data communication system,
a client device for facilitating payment processing and for obtaining input of payment information and rewards program enrollment options from a consumer at the point of sale at a merchant to said data communication system;
communicatively coupled to the client device via a communications network for receiving the entered payment information and the rewards program enrollment options, and based on the rewards program enrollment options and results of changes received from an enrollment server; a transaction processor that makes real-time adjustments to payment processing and determines responses to said client device;
a registration server communicatively connected to said client device and said transaction processor for modifying a payment amount from said entered payment information based on a predefined set of rules and consumer status; a registration server including a database storing unique personal account numbers associated with
The processing performed by the client device, the transaction processor and the registration server includes:
obtaining the payment information and the rewards program enrollment option with the client device;
obtaining, by the client device, the consumer's mobile phone movements visiting the merchant using a beacon tracking mechanism;
Identifying, by the client device, the mobile phone of the consumer attempting the payment based on the obtained mobile phone activity and obtaining information specific to the identified mobile phone. and,
transmitting from the payment processing device to the transaction processor the payment information, the rewards program enrollment options , and information specific to the mobile phone;
If the rewards program registration option indicates the consumer's participation in a rewards program, cause the transaction processor to interrupt the payment process and transmit to the registration server the payment information, the rewards program registration option , and transferring information specific to the mobile phone;
modifying data associated with the payment information with the registration server while maintaining the real-time nature of the payment process, comprising:
Said changing includes:
determining if the received payment information is associated with an existing user account of the consumer;
If the received payment information is associated with an existing user account of the consumer, updating information about the existing user account;
creating a new user account based on the received payment information if the received payment information is not associated with the existing user account;
associating information specific to said mobile phone with a unique personal account number associated with each said consumer;
determining an amount to modify a payment received from the consumer at the client device based on a reward;
modifying, including
sending, by the transaction processor, a message to the client device indicating completion of processing of the payment information using data associated with the modified payment information. 16. The system of claim 15, wherein said transaction processor and said registration server are controlled and operated by different entities. In claim 16,
further comprising another client device operating independently at the merchant independently of said client device, whether a given consumer interacts with said client device or with said another client device; , said given consumer is uniquely identified at said registration server based on said given consumer's unique personal account number. 3. The automated method of claim 2, wherein the payment not paid directly from the credit card is a mobile phone payment using Near Field Communication (NFC) technology.