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

Abstract

Disclosed is an automated method configured to associate a consumer with a reward program. The method includes providing a consumer with a bill using the processing device, receiving payment information about the consumer, receiving biometric information about the consumer, and a user associated with the reward program. And updating information about the account. A software application configured to process payments and update reward program information generates a bill for a set of goods or services to be provided to the consumer and receives a payment method from the consumer , Determining an account associated with the payment method, and including a set of instructions to update reward program information associated with the account. An automated method of facilitating redemption associated with a reward program includes receiving a bill related to a consumer's purchase, receiving payment information from the consumer, and billing at least a portion of the redemption balance. And applying to. [Selected figure] Figure 1

Description

  This application is a continuation-in-part of US patent application Ser. No. 13 / 927,046, filed Jun. 25, 2013, entitled “Automated Payment, Reward Program Enrollment, and Redemption”, filed March 25, 2016. Priority is claimed to US Patent Application No. 15 / 049,275 filed on the day, the entireties of which are incorporated herein by reference.

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

  With recent advances in wireless communication and miniaturization of computing devices, users can use devices connected to the Internet regardless of location or time. It is also desired to use ubiquitous Internet connectivity as a tool for improving productivity, not just for entertainment or social networking.

  Many vendors, for example, retailers, restaurants, service providers such as car service providers, online commerce sites (or “e-commerce” sites, mobile device commerce utilities (or “m-commerce” utilities, etc.), have various royalties Or a reward program (eg, “Registration Card” technology) can be provided (eg, by aggregating “points” related to the amount of money spent on various items and / or item types) (Reward measures) can be calculated, and the consumer can apply compensation measures (e.g., using the "redemption balance" of points) to purchase goods or receive cashback rewards. In many cases, consumers are required to participate in such programs at the time of payment to the merchant (e.g., when accounting at a store, paying a bill for a restaurant, etc.). When participating in the program, the user typically fills out the form, form or online, performs a series of questions from the store staff, and / or performs other tasks to provide registration information to the merchant There is a need to.

  After joining, the user usually needs to present a member card (or a code associated with an account such as a telephone number) in order to register for the loyalty program. In addition, existing users need to perform additional steps to reimburse the rewards (e.g. use a registration card to reduce the billed amount by some reward balance and use a credit card Pay the remaining amount separately).

  The Internet connection of companies such as restaurants and grocery stores not only dials up a bank server for credit card authentication but also has high bandwidth access to the Internet including servers of various service providers ing. In addition, many companies are beginning to provide users with wireless Internet access, including wireless devices that make it convenient for users to pay, select menus and order. Some inventors have begun to recognize the utility of such advances in Internet technology.

  U.S. Pat. No. 7,769,630 (hereinafter "Postrel") of Postrel is for issuing, aggregating and redeeming rewards based on merchant transactions. In Postrel, a cardholder who is a user purchases online using a credit card registered in advance by a card issuer. User registration is usually done in advance, and Postrel does not provide the technology for card registration at a real store.

  US Patent Application No. 2012/0041808 by Hofer et al. (Hereinafter "Hofer") discloses a system for converting an existing, issuer-funded, non-monetary reward into a currency that can be used by a retail store. ing. Hofer, however, does not provide a technique for performing automated program registration in real time at the point-of-sale.

  U.S. Patent Application No. 2007/0288311 by Underhill (hereinafter "Underhill") discloses a method for flexible incentive programs in sales organizations. Underhill's technology is a web-based inter-company incentive program that suppliers are specialized to use to lock in other operators that purchase supplier products. This registration technique uses outbound email to existing customers who can register with the program. Thus, Underhill's system does not provide the technology for real-time decision-making at the point of sale by the user.

  US Patent Application No. 2007/0083444 by Matthews et al. ("Matthews") discloses a technique for automatic adjustment of trading accounts paid in on-line transactions. Matthews does not provide the technology to connect real stores to back-end trading computers.

  US Patent Application No. 2012/01001881 by Taylor et al. (Hereinafter "Taylor (Taylor)") converts consumer credit information (consumer credentials) and consumer subscription information (consumer opt-ins) into financial transactions. Discloses a way to lock down consumers and provide reimbursement output. However, users of Taylor's system need to register a credit card prior to use, i.e. this registration is not real time and does not occur at the point of sale.

  U.S. Patent Application No. 2011/0303318 to LaPorte et al. (Hereinafter "LaPorte (LaPorte)") discloses a mobile retail royalty network in which a code is generated from a transaction. The customer scans / captures the code and sends it to the loyalty server outside the point of sale. Thus, LaPorte requires the user to own the mobile device and pre-register for the loyalty program. Thus, 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 a networked loyalty program. Voltmer discloses a technology that allows consumers to earn rewards at the network-wide level without retailers participating directly in the rewards function. This is accomplished by associating a consumer ID with a particular payment instrument, such as a consumer's credit card, debit card account, and / or bank account. However, Voltmer does not provide a real time point of sale solution.

  Thus, there is a need for a solution 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 way to efficiently register new members (or update existing member information) in a reward or loyalty program as the consumer pays for goods or services. . The reward program can be associated with a vendor or a collection of vendors.

  Once the consumer initiates payment of the goods or services (eg, by swiping a credit card), in some embodiments, information about the consumer (eg, by retrieving information from the swiped credit card) May be automatically collected and pre-populated 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 collected information may be used to register the consumer in a reward program and automatically associate the payment method used by the consumer with the reward account. Thereafter, when the consumer uses the same payment method to the merchant associated with the reward program, in some embodiments, depending on the situation, automatically updating and / or applying the user's reward information It is also good. Similarly, if the consumer (after registering for the initial reward program) has used the same payment method at different vendors associated with different reward programs, the necessary registration information is automatically obtained from the existing account, Applies to new reward accounts.

  In some embodiments, information regarding "billing" (including receipts, purchase orders, bills, online shopping carts or accounting information, and / or information related to other suitable sources related to the purchase) Can be collected and / or generated. Such information may include a list of goods and / or services, charges associated with each list item, 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, vendor location, SKU, etc.) Or, it may be associated with a stock keeping unit number or the like.

  In some embodiments, based on the payment information received, the reward balance (or a portion thereof) may be applied to the bill and automatically redeemed. Such reimbursement may be based at least in part on a variety of appropriate factors (eg, cumulative points, billed amounts, types of purchases, user preferences or preferences, etc.).

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

  One exemplary embodiment provides an automated method adapted to associate a consumer with a reward program. The method includes providing a consumer with a bill using the processing device, receiving payment information about the consumer, receiving biometric information about the consumer, and a user associated with the reward program. And updating information about the account.

  A second exemplary embodiment provides a software application configured to process payments and update reward program information. The software application generates a bill for a set of goods or services offered to the consumer, receives a payment method from the consumer, determines the user account associated with the payment method, and the user account Including an instruction set for updating reward program information associated with the

  The third exemplary embodiment provides an automated method that facilitates redemption associated with a reward program. The method retrieves, at a payment processing device, receiving a bill relating to the consumer's purchase, receiving payment information from the consumer, and retrieving user account information associated with the consumer, including a redemption balance. And automatically applying at least a portion of the redemption 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 does not provide an introduction or summary 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 of the Invention and other embodiments. Therefore, in order to understand all the embodiments described herein, it is necessary to fully consider the summary, the detailed description and the drawings. Further, claimed subject matter may be embodied in other specific forms as well, and claimed subject matter is not limited by the summary, detailed description and exemplary details of the drawings, and is therefore intended to Defined by range.

  The novel features of the technology disclosed herein are set forth in the appended claims. However, for the purpose of explanation, several embodiments are shown in the following drawings.

FIG. 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.

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

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

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

5 is a flowchart of a conceptual process used to facilitate payment and / or registration in accordance with some embodiments.

FIG. 6 is a flowchart of a conceptual process used to perform registration of new members according to some embodiments.

FIG. 6 is a flowchart of a conceptual process used to apply redemption according to some embodiments.

5 is a flowchart of a conceptual process used to update information associated with existing members according to some embodiments.

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

5 is a flowchart of a conceptual process used to provide analysis data to a third party according to some embodiments.

FIG. 6 is a message flow diagram of a conceptual communication protocol used to facilitate payment and / or registration in accordance with some embodiments.

Diagram showing various graphical user interfaces (GUIs) and associated sub-elements provided by some embodiments that allow a user to participate in one or more programs provided by some embodiments. It is.

FIG. 1 is a schematic block diagram of a computer system that can implement some embodiments.

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

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

FIG. 5 illustrates an example of messages exchanged in a data processing system.

  In the following detailed description, numerous details, examples, and embodiments are set forth and described. It will be apparent to those skilled in the art, however, that the embodiments are not limited to the embodiments described herein, but can 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. Section III then describes the 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 of a computer system that implements some embodiments.

I. System Architecture FIG. 1 shows a schematic block diagram of a conceptual system 100 used by some embodiments. Specifically, this figure shows various communication paths between system elements. As shown, the system includes one or more vendors 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 storage 150. , A third party server 160 associated with a set of storage 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 (e.g., a restaurant, retail store, plane, train, etc.). Each client device 120 may be an electronic device capable of receiving and processing payment information (eg, a mobile device such as a smartphone or tablet, a POS device such as a register or terminal, a dedicated credit card swipe device, etc.), Can be associated with the vendor 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 vendor. In some embodiments, local server 130 may provide the functionality of client device 120 and may operate without an associated client device. Each local server 130 can access one or more networks. In some embodiments, client device 120 can operate without a local server (eg, client device can directly access one or more networks, and / or perform other functions associated with local server 130) .

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

  Third party server 160 may include a set of devices accessible by system 100. The third party server 160 can access a set of local storage 170, and each storage can store (and / or retrieve) data and / or instructions associated with the third party system. Third party server 160 and / or storage 170 may be associated with various third party entities (e.g., marketing systems, data mining systems, payment processing systems, etc.). Such so-called third party entities can include entities associated with one or more vendors 110 (e.g., a local restaurant chain with multiple franchisees, a retailer with multiple store locations, etc.).

  One set of networks 180 may be various local and / or distributed networks (eg, Ethernet, wireless local area or “Wi-Fi” networks, Internet, cellular communications, etc.) accessed by various elements of system 100. Networks etc.). In some embodiments, the set of networks 180 may be a server that can enable interaction between various devices (not shown) and / or other subcomponents, eg, one or more networks, devices, etc., It can include storage, interfaces, etc.

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

  It will be apparent to those skilled in the art 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, the provider uses a closed loop loyalty card, a telephone number, an email, a mobile phone application, or a registered credit card. In all cases, registering a customer first is cumbersome. Customers typically have to go through several steps in order to create an account, which hinders account creation. Even if the consumer actually subscribes, the consumer needs to present the program's credentials in addition to the payment credentials, which may be difficult to remember, so It is an obstacle when using the program. A customer's assessment of the program can be rapid once the customer has never been able to "get" credit when making a purchase, either because he has forgotten to present his credentials and / or the cashier has not asked for credentials. To decline.

  In today's technology world, some think that customer loyalty is easier. This is because registration card loyalty programs are widespread. Customers can easily make payments and get rewards with a registered credit card. The registration card program is either card-centric or merchant centric. The card-centric approach consists of a loyalty network that deals with credit card issuers and card issuers. The dealer-centered program attempts to more systematically capture store customers through in-store marketing and incentives, but it is difficult to close, especially if immediate rewards are not given to customers. is there.

  In card-centric programs, even if the issuer has registered a large number of cards in the program, there may be very few cardholders who swipe registered cards at a member store, mainly because This is because the cardholder does not know which distributors are participating in the program. This degrades customer performance at the merchant level for payment per transaction and frequency of visits.

  The seller-centric approach may have fewer potential members, but the consumer deliberately pays because it is registered at the store and knows that it will be rewarded, so The average payment per transaction is often more than 30% higher than the average payment per non-member transaction.

  The embodiments disclosed herein specifically retrieve data from secure memory locations such as, for example, chips or magnetic strips placed on credit cards, receive email input, receive opt-in commands from users, and receive Provide computer technology that can be used to process computer transactions using the provided information.

  Thus, in one aspect, the techniques disclosed herein not only facilitate communication but also improve the data entry task of user devices such as POS devices.

  In some embodiments disclosed herein, after swiping a card, computer processing is initiated before credit card authentication is performed. The software code may be embedded in the credit card transaction's existing code in various ways, thereby interrupting or suspending the existing credit card authentication process and obtaining certification to verify the customer's qualifications. The procedure is started. At least one of the entities involved in the transaction (e.g., payment device, issuer network, gateway provider or payment application itself) encrypts the card data and generates a unique ID. Before installing the software, the party to perform the encryption 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 different from, but different from, the unique ID created at seller B using the same 16 digit card. May be A unique ID may only exist within the context of a transaction, and thus may be of limited duration. The encryption may be one-way encryption, ie it may not be possible to know the actual number sequence of the card by back calculation.

II. Exemplary Software Architecture Subsection II. In A, we describe the conceptual software system provided by some embodiments. Next, subsection II. B describes the client-side application provided by some embodiments. Next, subsection II. At 0, server-side applications provided by some embodiments are described. Finally, subsection MD describes the conceptual data structures used by some embodiments.

A. System Level Example FIG. 2 shows a schematic block diagram of a conceptual software architecture 200 used by some embodiments of system 100 and / or other systems. In particular, the figure shows various conceptual software elements that allow components of system 100 to interact. As shown, the 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, 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 are included.

  The client-side application 210 may be configured to be executed by a client device (e.g., the client device 120 described above), which may allow the client device to perform various system functions. The client-side application 210 receives information from one or more users (eg, cashiers, servers, consumers, etc.) and communicates with POS software running on a local server (eg, the 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.

  The POS software 220 may be configured to be executed by a local server or other suitable device (eg, the local server 130 described above), which allows the local server to perform various system functions. It is also good. POS software 220 receives information from one or more users (eg, cashiers, servers, etc.) and / or a set of client-side applications and joins one or more networks (eg, network 180 described above) Communicate via one or more network communication elements 290, provide information (eg, receipts, form information, etc.) to one or more users and / or consumers, and / or other appropriate functions (eg, For example, receipt of payment information, generation of a receipt, etc. can be performed.

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

  Database 240 may include data stored using appropriate storage (e.g., storage 150 described above) according to some embodiments. Such data may include, for example, data associated with one or more vendors or sets of vendors, data associated with various consumers (eg, information regarding purchases at participating vendors, loyalty account information, payment method information, etc.) And / or other suitable data may be included. The database 240 may optionally be accessed via the server-side application 230, and may be accessed via one or more APIs 250. Such an API may allow various external entities (eg, third party analysts, customers, etc.) to access data stored in various databases 240.

  The third party application 260 may be configured to be executed by a third party server or other suitable device (e.g., the third party server 160 described above), such that the third party server is a part of some embodiments. It may be possible to interact with the system. The third party application 230 communicates with multiple sets of client side applications (each set may be associated with a vendor) and one or more network communication elements that participate in one or more networks (e.g., the network 180 described above) Communications may be via 290 and / or other suitable functions may be performed.

  Database 270 may include data stored using appropriate storage (e.g., storage 170 described above) according to some embodiments. Such data may include, for example, data associated with one or more third parties (eg, payment processing entities, researchers, 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 an API may allow various external entities (eg, server-side application 230, client-side application, POS software, etc.) to access various data stored in database 270.

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

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

  It will be apparent to those skilled in the art that the architecture 200 can be implemented in a variety of different ways. For example, different specific elements may be added, or 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. Exemplary Client-Side 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, the application 300 may include a user interface (UI) module 310, a communication module 320, a payment module 330, a device control module 340, a local storage module 350, and a reward module 360.

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

  Communication module 320 allows other elements of client-side application 300 to interact with various external applications (eg, server-side applications accessed via a set of network interfaces, local servers accessed via a local network, etc.) It can interact.

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

  Device control module 340 may be configured to allow client-side application 300 to properly interact with various client device components. For example, in some embodiments, device control module 340 may allow application 300 to control touch screen elements associated with the device. As another example, the POS terminal may be instructed to display various instructions, formats, 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.

  The reward 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 may further be associated with one or more vendors.

  Those skilled in the art will appreciate that the application 300 can be implemented in a variety of different ways. For example, different specific elements may be added, or 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. Exemplary Server-Side Embodiments FIG. 4 shows a schematic block diagram of a conceptual server-side software application 400 (eg, the 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 module 410 can include one or more APIs.

  The communication module may allow other elements of server-side application 400 to interact with various external applications (eg, client-side applications accessed through 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 receives from a payment processor It may be configured to provide various functions related to payment processing, such as interpreting a set of responses.

  The rules engine 440 may be configured to evaluate consumer information in conjunction with a set of program metrics and generate an appropriate set of actions based on consumer (and / or third party) interactions. . For example, some reward programs may provide bonus rewards to initial customers. As another example, some reward programs may provide various promotional materials based on an evaluation of consumer behavior.

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

  The reward 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 reward information. Such information may be associated with loyalty or reward programs, which may further be associated with one or more vendors.

  It will be apparent to those skilled in the art that application 400 can be implemented in a variety of different ways. For example, different specific elements may be added, or 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 Structure 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 application described above with reference to FIGS. As shown in FIG. 5, data structure 500 may include member accounts 510 and third party information 520.

  The member account component 510 may be associated with a particular user (or a set of users, such as a family, business, etc.) registered with the reward program. The member account may include payment methods 530 (eg, credit card information, online payment account information, etc.), and biometric information 540 about the user (eg, name, email address, etc.). Transaction history 550 may include information related to previous interactions between the user and merchant associated with the reward program.

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

  It will be clear to those skilled in the art that data structure 500 is inherently conceptual, and different embodiments may implement data structures in a variety of different ways. For example, in some embodiments, additional specific elements and / or subelements may be added and / or specific elements and / or subelements may be omitted. As another example, various subelements may be integrated as a single element, or a single element may be divided into multiple subelements.

III. Exemplary Method of Operation Subsection III. A conceptually illustrates the payment process of some embodiments. Subsection III. B describes the conceptual registration process provided by some embodiments. Subsection III. In 0 we describe the conceptual redemption process provided by some embodiments. Subsection III. Section 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 perform post-trade marketing. Subsection III. F describes the conceptual process used to collect and provide user data according to some embodiments. Finally, subsection III. G describes the message flow used to implement various operations according to some embodiments.

  The various processes described below may be the hardware elements described above with reference to FIG. 1, the software components described above with reference to FIGS. 2 to 4, the data structures described above with reference to FIG. 5, and / or the like. It may be implemented using various combinations of appropriate elements of In addition, the various processes (or portions thereof) described below may be appropriately combined in various ways to provide a combination of various features (eg, payment and registration, payment and reimbursement, etc.).

A. Exemplary Embodiment of Payment Processing FIG. 6 is a flowchart of a conceptual process 600 used by some embodiments to make payment and / or registration. Such a process may begin, for example, when presenting a payment option to a consumer using a desktop tablet device, when a server or cashier initiates a payment operation, etc. Next, the process receives (at 610) a selection of payment options. The available options (cash payment, credit card payment, online account payment, etc.) are displayed in various appropriate ways (eg as a list or as a selectable set of buttons), Selections from options may be received in various suitable manners (eg, using a touch screen or using a display screen and a keypad).

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

  Next, the process may offer one or more incentives (not shown) to enroll in the reward program, and / or may prompt 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 reward program. Such a determination may be made based on input received from the recipient, input by the server or other collaborator, and / or made in any other suitable manner. If the process determines that the recipient does not want to participate, the process may (at 625) receive payment information and process the payment (at 630). Such payment information can be received by any suitable means (eg, swipe a credit card, enter credit card or bank information, provide account information for a web-based payment method, etc.) and is appropriate. Processed

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

  Next, process 600 may determine (at 650) whether the payment information has been recognized (and / or if the user is an existing user). Such determinations may be made in various appropriate ways (eg, by comparing payment information to a database of accounts, or prompting the user to indicate whether the user is a new member or an existing member) Can be done by

  In some embodiments, after the consumer registers with the rewards program using a particular payment method, the user does not need additional manipulation by the user if the same payment method is being used , Are automatically recognized as existing members. For example, if the user swipes a credit card for payment (e.g. using a fixed terminal or using a mobile device such as a tablet) and it is determined that the credit card is associated with an existing account, As if the user were not registered, the rewards information would be updated and / or applied to the bill without requiring the user to perform any actions other than those required to process the additional selection or payment. May be

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

  The registration process can include asking the user to enter an email address or other information. In some embodiments, the payment method and information associated with the method (eg, recipient's name, address, etc.) may be read from the payment information received at 620 (eg, the consumer's name may be an account It may be encoded with a number and / or other information on the magnetic strip on the back of the credit card or bank card, and the consumer's name may be obtained from a web-based payment service). Registration will be described in more detail later with reference to process 700.

  Once the process 600 determines (at 650) that the payment information has been recognized, the process can retrieve and / or update account information associated with the user (at 680). Such a search and / or update may communicate with the remote server or other element to determine the user's status (eg, cumulative points, purchase history, etc.) and / or information regarding current interactions (eg, It may include sending the payment amount, participation choices, etc. to the server. Updating account information will be described in more detail later 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), the process 600 applies rewards to the account (at 690) It is also good. In some embodiments, such rewards may be provided immediately (e.g., by automatically reducing the amount paid by the consumer). Alternatively, the user's account may be updated to reflect additional rewards that have not been redeemed. In some embodiments, the user can select a reward from an applicable set of rewards (not shown). For example, a list of options (eg, applying points to balances, exchanging points for additional items, etc.) may be presented and a selection may be received from the listed options.

  After applying the reward (at 690) or receiving payment information (at 625), the process interacts (eg, with a third party application and / or server) to perform a credit card transaction (at 630) Transaction payments can be processed and terminated, eg, by interacting with web-based services.

  Process 600 may be implemented in a variety of different manners. For example, different embodiments may include different operations, omit various operations, and / or perform the operations in a different order than illustrated. Some embodiments may divide the process into sets of sub-processes, and may execute the processes as larger macro-process sub-processes.

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

  As shown, the process may retrieve (at 710) reward program information. Such information can include biometric information about the vendor or the chain, rules, and the like. Next, the process retrieves (at 720) user information (e.g., name and credit card number, username, etc.) associated with the payment method. Such information can be retrieved in a variety of appropriate ways depending on the payment method (e.g. payment information and biometric information from data stored on the magnetic strip on the bank card when the card is swiped) It may be read out, and information may be received from a third party).

  The process may receive (at 730) additional user information. Such information can be obtained in a variety of suitable manners (eg, by providing a user interface having various form elements such as text fields, check boxes, selection lists, etc., where the user can enter the information). Additional information may include contact information and / or biometric information (eg, email address, social networking page, birthday, mobile phone number, zip code etc.), user preferences (eg, receive email weekly), electronic It may include preferences such as receiving email daily) and / or other appropriate information (eg, number of eating outs 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 biometric information.

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

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

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

C. Exemplary Embodiment of Redemption FIG. 8 is a flowchart of a conceptual process 800 used to apply redemption according to some embodiments. Such a process is performed, for example, when an existing user makes a purchase using a payment method registered at a vendor associated with the reward program.

  As shown, process 800 retrieves (at 810) reward program information (eg, categories, thresholds, etc.) and then (at 820) receives payment information (eg, by a swiped credit card) Then, (at 830) retrieve user information associated with the payment method. Such information may be retrieved using appropriate systems and software of some embodiments. If necessary, new user information may be collected instead.

  Next, the process determines (at 840) a redemption option (eg, applying points to the purchase, receiving a gift or promotional item, etc.). Such redemption options may be included in the retrieved reward program information. The process may then receive (at 850) a selection of redemption options (eg, by receiving user input, performing default selections, etc.) and (at 860) related to the number of reward points (eg, number of reward points) The selected option can be applied by reducing the amount from billing, applying a promotional reward such as free dessert, etc. Finally, the process can apply (at 870) payment (eg, by sending credit card information to a third party processor) and end.

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

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

  As shown, the process retrieves (at 910) reward program information and receives (at 920) user information. Such information can include biometric information about the vendor or the chain, rules, and the like. Such user information may include updating of user account information (eg, username and password, email address etc.) and / or user information (eg, new payment methods, additional or updated telephone numbers, updated electronic E-mail address etc. can be included. For example, if the user swipes an unrecognizable credit card and indicates that the user is an existing user, the email address (or username and password, and / or other appropriate) associated with the reward account The identification information may be required to be provided to the user.

  Next, the process retrieves (at 930) user account information. The user account information may include biometric information, payment method information, information related to the 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 (eg, an account associated with the user using a username or email address provided by the user) (You may search account information by this).

  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 has made a selection to indicate 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 (at 950) a reward and may end. Such rewards may be based on various appropriate 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 reward program.

  Although process 900 has been described with reference to an example where a user adds a new payment method to an existing reward account, a similar process may be used to add an existing payment method to a new reward account. For example, if the user has an existing reward account with a first merchant associated with the payment method, and the user applies the payment method to the second merchant, in some embodiments, An account associated with a second merchant, automatically recognizing the existence of an account associated with one of the vendors, applying user information (eg, name, email, address, zip code, social media information, etc.) You may create

  Process 900 may be implemented in a variety of different manners. For example, different embodiments may include different operations, omit various operations, and / or perform the operations in a different order than illustrated. Some embodiments may divide the process into sets of sub-processes, and may execute the processes as larger macro-process sub-processes.

E. Post-Transaction Marketing FIG. 10 shows a flowchart of a conceptual process 1000 used by some embodiments to optimize post-transaction marketing. Such processing may be performed at regular intervals (e.g., hourly, daily, weekly, etc.) and various criteria (e.g., new user sign up, existing account update, holiday time, specific time) Etc.) and / or at other appropriate times (eg, when a retailer initiates a promotional offer, a threshold, such as a spending threshold, is reached), based on the transaction history, the customer's Based on the spending behavior, etc.).

  Such processes may trigger various appropriate actions such as receipt delivery (e.g., emailing a receipt containing a marketing offer, sending a marketing email with a coupon, etc.). In some embodiments, the receipt may include a selectable element (e.g., a URL), which allows the user to provide information regarding the expense (e.g. This can be compiled for use by the user (e.g., when the user prepares a tax document).

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

  After obtaining the third party information (at 1030) or after determining (at 1020) that the deal involves a new member, the process at least partially (at 1040) the user's transaction history and a set of marketing rules And may generate marketing information. Next, the process retrieves (at 1050) the appropriate marketing template (e.g., email template) and sends (at 1060) marketing information to the member.

  Process 1000 may be implemented in a variety of different manners. For example, different embodiments may include different operations, omit various operations, and / or perform the operations in a different order than illustrated. Some embodiments may divide the process into sets of sub-processes, and may execute the processes as larger macro-process sub-processes.

F. Merchant Dashboard In some embodiments, various merchants (or "users"), such as vendors, groups of vendors, marketing organizations, etc., may have access to user (i.e., consumer) data. Such data may include any information related to the user's purchase made using the system of some embodiments. This information includes user status information (eg, new registration, existing members, purchase history, zip code, social media account information, etc.), payment information such as payment method, purchase information (eg, invoice, list of items, total amount, Time stamp, place of purchase, etc.), vendor information (eg, type, place, size, promotion, etc.), reward information (eg, unpaid reward points, redeemed reward points, etc.), and / or of some embodiments It can contain other information that can be compiled by the system.

  User data may be collected and / or compiled in any suitable manner. For example, in some embodiments, user data is collected continuously while receiving user data (eg, when a user registers, when a user pays to a registered merchant, etc.). As another example, user data may be collected from different vendors at different appropriate times and / or in different appropriate manners (eg, stores may provide information at regular intervals, region The chain may provide information etc. formatted in a specific way). Such user data includes consumption behavior, reimbursement behavior, statistical information, social media behavior (eg, aggregation of “likes” by registered users, sharing of links with “friends”, forwarding of messages or links, etc.) Can be included. Data may be collected and / or made available in real time (ie, data may be made readily available to various users as it is provided to the system of some embodiments) . Further, in some embodiments, such collected data (e.g., provide rewards to users who "liked" a product or service, or additional points when users share links. It may be used to provide rewards to registered users, such as by giving.

  FIG. 11 shows a flowchart of a conceptual process 1100 used by some embodiments to provide analysis data to a third party. In some embodiments, such a process may be performed continuously upon receiving user information.

  The process may receive (at 1110) a request (or “query”) of user information. Such user information may be aggregated in any suitable manner depending on the desires of the distributor requesting the information (e.g. all users who have purchased a threshold amount or more over the last period, All users registered within the time frame of Such requests may be by any suitable means (eg, via an API, via a website or other similar portal, as a formatted message by application of some embodiments, etc.) I can receive it. The request may include various appropriate parameters (eg, consumer type, vendor type, purchase price, etc.), which may be used to identify appropriate 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 may be compiled in various suitable ways (e.g., based on requested elements, based on user preferences, based on different protocols, etc.).

  Finally, the process can provide (at 1140) the compiled information to the requester and exit. The information may be provided in various suitable manners and / or formats based on various suitable criteria, parameters, etc.

  Process 1100 may be implemented in a variety of different manners. For example, different embodiments may include different operations, omit various operations, and / or perform the operations in a different order than illustrated. Some embodiments may divide the process into sets of sub-processes, and may execute the processes as larger macro-process sub-processes.

G. Exemplary Message Flow FIG. 12 shows a message flow diagram of a conceptual communication protocol 1200 that may be used by some embodiments to make payment and / or registration. As shown, communication protocols may occur 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 may occur depending on various related factors (eg, available system elements and / or subelements, user selection, approval and / or denial of various requests to a third party or external system, etc.) there's a possibility that.

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

  In operation, the server can initiate checkout for the customer by making selections using the client device and client side applications of some embodiments. Such selection may send message "a" from client device 1210 to local server 1220. The local server 1220 may compile a bill or bill associated with the customer and send a response “b” that includes the bill (eg, a list of items purchased by the consumer, applicable taxes, etc.) .

  The client device 1210 may then include, along with the processing request, the bill sent in response “b” and information regarding the user's payment method (eg, credit card information swiped using the client device 1210) The message “c” may be sent to the remote server 1230. Additionally, the message "c" may include information regarding user registration (for a new user) and / or updated payment information (eg, if an existing user adds a new payment method). Such a message may include transaction information (eg, billing amount, merchant location, etc.) associated with the consumer's interaction, which may also be used to update the reward program information associated with the user. Good.

  The remote server 1230 may receive the message “c”, generate a request “d”, and send it to the third party server 1240 for processing. Such request may include payment information (eg, credit card number, name, authorization code, etc.), payment amount, and / or other appropriate information. The third party server may analyze the request "d" to determine whether to process the payment. Such a determination may be made based on various appropriate criteria (e.g., user credit limits, merchant reputation, etc.).

  The third party server 1240 may send a response “e” to the remote server 1230 to allow or deny the payment request. Such responses can include various authentication codes, identification information, and the like. The remote server may then send a response “f” to the client device 1210 indicating the result of the payment process and / or any relevant information.

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

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

  It will be apparent to those skilled in the art that message flow diagram 1200 can be communicated in a variety of different manners in different embodiments for purposes of illustration only. For example, in some embodiments, the client device may not be able to communicate directly with the remote server, but may instead need to relay messages via the local server. As another example, in some embodiments, the client device may communicate directly with the third party server without using a remote server. Furthermore, different embodiments may transmit different sets of messages between different devices and / or in different orders than shown here.

  Several embodiments of data communication systems that can implement user-controlled real-time data processing are described with reference to FIGS. 15A and 15B. The user, for example, a consumer or a customer who pays a bill, or conducts a financial transaction, or controls the processing of data in some other manner, by explicit control per transaction, or in advance by user selection or remotely Data processing steps can be controlled based on implicit control from the transactions performed on the deployed server.

  FIG. 15A shows an exemplary data communication system 1500, which includes a client device 1502 that a consumer uses to enter payment information and program registration options into the data communication system, and a communication network 1504. A transaction processor 1506 communicably connected to the client device, which receives the input payment information and program registration options, and determines a response to the client device 1502, the client device 1502 and the transaction processor A registration server 1508 communicably connected to change the payment amount from the entered payment information based on a predefined rule set and the status of the consumer, and a unique personal account number associated with each consumer Store And a registration server 1508 that contains the database. The client device 1502 may be, for example, the client device 120. Transaction processor 1506 may be similar to remote server 140.

  FIG. 15B shows that the transaction processor 1556 (substantially similar to the transaction processor 1506) and the registration server 1558 (substantially similar to the registration server 1508) are co-located on a single hardware platform and the internal data bus of the computer system Or illustrates an exemplary embodiment of a data communication system 1550 that operates similarly to data communication system 1500, except that it can communicate with one another via an internal communication mechanism, which may be a software application programming interface (API). In such embodiments, registration server 1558 may use explicit user selection, eg, opt-in menu selection, and / or implicit user action, eg, storing user rewards based on the user's previous transactions. , Modify the data being processed by the transaction processor 1556. For example, when the transaction processor receives a data processing request in real time, the transaction processor sends data (eg, purchase price) and identity information of the customer or user whose transaction is being processed to the registration server 1558. The registration server 1558 may then change the transaction, for example by providing a discount to the user, and may return this result to the transaction processor 1556 in real time. Credit card payment processing is mostly an automated process, and at the present time a technical solution for changing the flow of payment processing while maintaining real-time responsiveness to the paying consumer Does not exist.

  By using the disclosed technology, the payment processing flow can be interrupted and changes can be made to 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. Furthermore, by correlating the payment data with the consumer's choice as to whether the consumer would like to benefit from the change, eg payment discount, processing speed is maintained, thereby allowing the consumer to There is no need to fill in multiple menu screens or physical forms. In this way, by using the registration server 1558 in conjunction with the transaction processor 1556, it is possible to identify in real time whether the consumer is a known member of the reward program or not, if the member is not a known member, Identify whether you want to register for the program.

  FIG. 16 shows a message flow diagram of a conceptual communication protocol 1600 used to perform data processing in accordance with some embodiments. As shown, the communication protocol is performed 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 may occur depending on various related factors (eg, available system elements and / or subelements, user selection, approval and / or denial of various requests to a third party or external system, etc.) there's a possibility that.

  The client device 1602 may send a message 1610 representing a transaction, eg, credit card payment, to the processing server 1604. The message 1610 may include information uniquely identifying the user, such as a credit card number, an amount applied to the user's balance, a user's phone number, or an email address. Also, the message 1610 can include a field indicating that the user wishes to select a registration plan.

  When the processing server 1604 receives the message 1610, the processing server 1604 transmits a message 1612 to the registration server 1606 according to whether or not the user instructs opt-in. The processing server 1604 can transmit information identifying the user in the message 1612 to the registration server 1606 along with unique additional information such as the user's e-mail address and telephone number.

  The registration server 1606 processes the received user information, generates a message 1614 indicating whether the user is registered and whether to apply the reduction to the user's payment, and sends it to the processing server 1604. Next, the processing server 1604 sends a message 1616 to complete the data processing transaction in progress on the client device 1602. The processing server 1604 may then send a transaction complete message 1618 to the registration server 1606. Processing server 1604 receives confirmation message 1620 from the registration server and completes the transaction. Thus, in an advantageous aspect, the communication protocol allows the consumer or user to control the transaction data processed on the processing server 1604 and to select the consumer's preference for selecting or declining a transaction. Adjustments can be made to transaction data in real time, and transaction amounts can be changed based on similar transactions (eg, loyalty rewards) previously executed by the consumer.

  In some embodiments, the method of performing real-time data processing includes personal information regarding the consumer, information regarding the payment the consumer is about to make, and information regarding the consumer who wishes to select a loyalty registration program. Receiving a first message containing data and, if the card payment received is associated with the consumer's existing user account, whether the personal information received in the message is already associated with the existing user account Check if the received card payment is not associated with the existing user account, update the information on the existing user account, associate the received card payment with the existing user account, and Payments that consumers are going to It relates includes changing the information, the information that has changed about the payment, and transmitting a second message including the additional information for display to the consumer. In some embodiments, the change is to search in real time a set of rules related to the reward for the user account, and evaluate information about the existing user account based at least in part on the set of rules. And, based at least in part on this evaluation, determining the redemption to be applied to the payment the consumer is about to make, at least one reward being based on the royalty rule, Include at least one of an immediate fee and an unpaid fee that reduces the amount of payment that the is trying to make.

IV. Example Graphical User Interface (GUI) Elements FIG. 13 illustrates various GUIs 1310 provided by some embodiments that allow a user to participate in one or more programs provided by some embodiments. 1340 and related subelements are shown. Such a GUI can be presented using an appropriate client device (e.g., client device 120 described above).

  As shown, the GUI 1310 can include a first graphic element 1350, a second graphic element 1355, and a set of selection elements 1360. In this example, the first graphic element 1350 can include a registration offer (eg, register now to receive an immediate reward), and the second graphic element 1355 can be a registration profit and / or other information. A list (e.g., "5% off subsequent purchases", "free to join", etc.) may be included. The set of selection elements 1160 can include buttons or other selectable elements, and labels of various appropriate selection options (eg, "Yes, register", "No, not register", " "Any member", "add a new payment method", etc. can be attached.

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

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

  It will be apparent to those skilled in the art that different embodiments may include various GUI elements different from those shown in the example of FIG. For example, some embodiments can include various GUIs intended for use by a server or cashier, and appropriate elements for such use (eg, table selection elements, menu selection elements, etc.) Can be included. As another example, while various GUIs are shown vertically, in different embodiments (and / or different GUIs), horizontal orientation may be used (and / or vertical and horizontal orientations may be automatically shifted) You may

V. Example Computer System Many of the processes and modules described above can be implemented as software processes identified 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 (eg, microprocessor, microcontroller, digital signal processor (DSP), application specific integrated circuit (ASIC), field programmable gate array (FPGA), etc.) The instruction causes the computing element to perform the operation specified by the instruction.

  FIG. 14 conceptually illustrates a schematic block diagram of a computer system 1400 upon which some embodiments can be implemented. For example, the system described above with reference to FIG. 1 can be implemented at least in part 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.

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

  Computer system 1400 includes a bus 1405, at least one processing element 1410, system memory 1415, read only memory (ROM) 1420, other components (eg, a graphics processing unit) 1425, an input device 1430, an output device 1435, permanent storage. Devices 1440 and / or network interfaces 1445 may be included. The 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. 13 may be implemented, at least in part, using an instruction set executed on computer system 1400 and displayed using output device 1435. Good.

  Bus 1405 represents all communication paths between the elements of computer system 1400. Such paths can 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 execute and data to process 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 via bus 1405.

  ROM 1420 may store static data and instructions that may be used by processor 1410 and / or other components of the computer system. Permanent storage device 1440 may be a readable / writable memory device. This device may be a non-volatile memory unit that stores instructions and data even if the computer system 1400 is turned off or not powered. Permanent storage device 1440 may include a mass storage device (such as a magnetic or optical disk and corresponding disk drive).

  Computer system 1400 may use removable storage devices and / or remote storage devices as permanent storage devices. The system memory 1415 may be volatile readable / writable memory such as random access memory (RAM). The system memory can store some of the instructions and data that the processor uses at run time. 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 device 1430 allows a user to provide information to a computer system and / or manipulate various operations of the system. The input devices can include a keyboard, a cursor control device, an audio input device and / or a video input device. Output device 1435 can include a printer, a display, and / or an audio device. Some or all of the input 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 operating in a web browser, the web browser running on computer system 1400 is a web server Can interact with In some embodiments, network interface 1445 can include one or more APIs. The network interface and associated network 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 in the present specification and claims all refer to electronic devices. These terms exclude people or groups of people. The term "non-transitory storage medium" as used in the present specification and claims is completely limited to tangible physical objects that store information in a form readable by an electronic device. These terms exclude radio signals or other transient signals.

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

  It will also be apparent to those skilled in the art that the unique identifier derived from unique user information, such as, for example, a primary account number (PAN) can be used to identify the user. If this PAN is revoked (by loss or theft) and a new PAN is created by the issuer, then the previous unique ID may be automatically associated with the new PAN. In this way, the unique ID directly associated with the card issuer can be updated.

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

  If the existing member paid cash at the merchant, the conventional practice was that the member did not receive the credit for the transaction. On the other hand, using the technology disclosed herein, the user interface can provide a web link to the customer through the user interface when the transaction is completed, and the customer can use this to upload receipt information and pay cash transaction rewards. It can be received.

  In addition to sending payment eligibility information, when the customer wishes to pay on a mobile phone using near field communication (NFC) technology, the customer has the registration server uniquely identify the user. Unique identity credentials can be sent that contain all the same information used to identify. Advantageously, the user can receive an immediate discount simply by actually bypassing the input of information on the POS and actually transmitting it with the payment, including opt-in.

  Currently, some companies can use beacon transmission to track the movement of Bluetooth-enabled mobile phones. However, the issue is that the beacon tracking mechanism is not connected to the actual transactions being conducted, and therefore can not bridge the gap between tracking the customer's movement and the customer's transaction. ing. By using cell phone specific information to perform transactions, the technology disclosed herein can track users, combine them with other users as they come in, compare these movements with the transactions Finally, it can be determined which telephone belongs to which unique ID.

  In some embodiments, when an existing member known to registration server 1606 enters a new store and the card is swipe for payment, a unique ID is triggered at the registration server. This correlation may be used to automatically enter in the user's email field an existing email address on a file linked to a unique ID linked to the PAN being used by the customer.

  In some embodiments, the customer can donate to these non-profit organizations instead of signing up with the merchant's compensation program and receiving the redemption earned by spending on that particular merchant.

  Some embodiments may be embodied in the form of a non-transitory computer readable storage medium storing a software application, which, when executed by the one or more computers, causes the one or more computers to execute. Process payments and update reward program information by the seller, which generates a bill for a set of goods or services offered to the consumer and receives a payment method from the consumer And displaying a user interface on the payment processing device, the user interface being configured to receive additional personal information uniquely identifying the customer on the payment processing device, the additional personal information Includes at least one form element and sends personal information to the first server And that signal is performed by receiving at least one reward from the server. The first server is configured to identify the at least one reward based on the at least one form element using the application programming interface, the application programming interface to communicate with the one or more servers Configured to determine if the existing user account of the merchant's reward program is associated with a payment method. The server updates the reward program information associated with the existing user account based at least in part on the bill of the particular existing user account determined to be associated with the received payment method, at least the reward program The system is configured to create a new user account associated with the reward program for the consumer based on the payment method for the consumer who does not have an existing user account. In some embodiments, the payment method is a credit card or is ultimately linked to a credit card. In some embodiments, the reward program is associated with one of a restaurant, a grocery store, a car servicer, a mobile operator, an e-commerce site, a retailer, etc. In some embodiments, the software application determines a reward program offer based on at least a portion of the updated reward program information for an existing particular 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 a new user account. In some embodiments, the software application further includes a set of instructions for generating an instant reward and providing the reward to the consumer. In some embodiments, the software application comprises a client-side application executed by a client device configured to be communicatively coupled to the server-side application. Methods in accordance with some embodiments can be described using the following sections.

  Section 1: A method of facilitating a consumer to register with a reward program while making a purchase payment using a payment processing device having a user interface, the method using a payment processing device Presenting a bill associated with the consumer purchase to the consumer, receiving the payment option selected by the consumer in response to the bill, and displaying on the user interface (1) of the new reward program Encourage the consumer to make a choice from one of the options of registering with the reward program as a user, (2) having an existing user account for the reward program, or (3) selectively not registering the reward program. And receive payment information for the payment option selected by the consumer, depending on the selection of the option (1) by the consumer. Performing a payment program user account based on at least the payment information, and displaying the user interface on the payment processing device, the user interface receiving additional personal information and processing the payment Configured to uniquely identify the customer on the device, the additional personal information includes at least one form element and, based on the at least one form element using the application programming interface, Sending additional personal information to a first server configured to identify one promotion reward, the application programming interface being configured to communicate with the one or more servers; Reward from Reward Program Unnecessarily and a to confirm the payment.

  Section 2: In the method according to paragraph 1, the method further comprises receiving payment information of the payment option selected by the consumer in response to the consumer's selection of option (2) And determining whether the received payment information is associated with an existing user account, and for the particular existing user account that is determined to be associated with the received payment information, associated with the compensation program. Updating the information on the user account of at least based on the bill, and in other cases updating the existing user account by associating the received payment information with the existing user account, and the reward from the reward program And determining payment to include.

  Paragraph 3: In the method described in the first paragraph, the method further comprises receiving payment information of the payment option selected by the consumer in response to the consumer's selection of option (3) And finalizing payment.

  Clause 4: In the method according to clause 1, the payment option selected is credit payment.

  Clause 5: In the method according to clause 1, the received payment information includes credit card information.

  Clause 6: In the method according to clause 1, creating a reward program user account includes receiving an input of an email address from a consumer.

  Clause 7: In the method according to clause 1, creating the user account of the reward program further comprises receiving one or more of a mobile phone number, a birthday, and a zip code.

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

  A method of facilitating a consumer to register with a reward program while making a purchase payment using a payment processing device having a user interface, the method comprising: using the payment processing device Presenting a bill related to a consumer purchase to a consumer, receiving payment information from the consumer to make a payment, and registering for a reward program to receive an immediate discount on the consumer on the user interface Prompting the customer to receive consent from the consumer to register for the reward program, creating a user account for the reward program based at least on the payment information, and displaying the user interface on the payment processing device. And the user interface receives additional personal information and uniquely identifies the customer on the payment processing device And the additional personal information includes at least one form element, and uses the application programming interface to identify the at least one promotion reward based on the at least one form element. Sending additional personal information to a first configured server, the application programming interface being configured to communicate with the one or more servers, and paying to include an immediate discount And determining.

  Item 9: In the method described in Item 8, prompting the consumer to register includes prompting the consumer to enter an e-mail address, and receiving consent from the consumer is emailing from the consumer Including receiving an email address.

  Clause 10: In the method according to clause 9, creating a reward program user account further comprises linking an email address to the user account.

  Clause 11: In the method according to clause 8, receiving payment information includes receiving credit card information using a credit card swipe element.

  Furthermore, although in the above example many individual modules are shown as separate elements, it will be clear to those skilled in the art that these modules may be combined as a single functional block or element. It will also be apparent to those skilled in the art that a single module can be divided into multiple modules.

  Although the technology has been described with reference to numerous 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 particular features and / or components. However, it will be apparent to those skilled in the art that other embodiments may be practiced with other types of features and components. It will be obvious to one skilled in the art that the present invention is not limited by the above-described exemplary details, but rather by the scope of the claims.

Claims (22)

In an automated way to associate consumers with reward programs,
Presenting a bill to the consumer using a payment processing device at the point of sale of the seller;
Receiving a card payment from the consumer as a result of the card being swiped on the payment processing device;
Displaying a user interface on the payment processing device, the user interface being configured to receive additional personal information uniquely identifying the consumption on the payment processing device, the additional individual The information includes at least one form element, and
Displaying on the user interface the consumer a menu to prompt for input and receiving input from the consumer about the payment process;
Receiving additional personal information uniquely identifying the consumer via the payment processing device;
Sending the additional personal information to the server;
Receiving a message from the server based on processing from the server;
The process performed by the server is
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;
Identifying the consumer as having an existing user account of the merchant's reward program;
Determining whether the received card payment is associated with the consumer's existing user account;
Updating information regarding the existing user account if the received card payment is associated with the consumer's existing user account;
Associating the received card payment with the existing user account by associating the existing user account if the received card payment is not associated with the existing user account.   The automated method according to claim 1, wherein the payment of the card includes direct payment from a credit card or payment not directly from a credit card but ultimately linked to a credit card.   The automated method of claim 1, further comprising associating the card payment with a system-generated unique identifier associated with the existing user account. In claim 1,
The automated method further comprising retrieving the existing user account information if it is determined that the card payment is associated with an existing user account.   The automated method of claim 4, wherein updating the information regarding the existing user account comprises changing the existing user account information based at least in part on the bill.   The automated method according to claim 4, wherein updating the information regarding the existing user account comprises changing the existing user account information based at least in part on the card payment. In claim 1,
Retrieving a set of rules associated with the reward program from the one or more computers;
Evaluating information regarding the existing user account based at least in part on the set of rules;
Determining a redemption to be applied to the bill based at least in part on the evaluation, wherein the at least one reward comprises at least one of an immediate reward and an unpaid reward;
Performing the process of determining a payment.   The automated method of claim 1, wherein the additional personal information comprises at least one of an email address, a mobile phone number, or a zip code.   9. The method of claim 8, wherein the additional personal information comprises the consumer's social media profile.   The automated method of claim 1, further comprising transmitting to the consumer an electronic receipt and / or a marketing offer generated based on the consumer's consumption behavior.   The automated receipt of claim 10, wherein sending an electronic receipt to the consumer comprises sending the electronic receipt by email or sending the electronic receipt to the consumer's mobile phone. Method.   The automated method of claim 1, wherein the point of sale of the merchant comprises a mobile device based point of sale.   The method of claim 1, wherein the input from the consumer is to register for a reward program that receives an immediate discount.   The automated method of claim 1, wherein providing the bill comprises providing the bill on a screen externally connected to the processing device. A method of performing real time data processing, comprising
Receiving a first message including data including personal information regarding the consumer, information regarding the payment the consumer is about to make, and information regarding the consumer wishing to select a loyalty registration program. ,
Checking whether personal information received in the message is already associated with an existing user account;
Updating information regarding the existing user account if the received card payment is associated with the consumer's existing user account;
Associating the existing card account with the existing user account, associating the existing card account with the existing user account, if the received card payment is not associated with the existing user account;
Changing information regarding the payment that the consumer is about to make based on the association;
Sending a second message including the changed information regarding the payment and additional information to display to the consumer.   The method according to claim 15, wherein the payment related information includes mobile phone payment information. In claim 15, the change is in real time,
Searching a set of rules related to the reward for the user account;
Evaluating information regarding the existing user account based at least in part on the set of rules;
Determining the redemption to be applied to the payment that the consumer is going to make based on at least a part of the evaluation, the at least one reward being based on a royalty rule A method comprising at least one of immediate compensation and unpaid compensation to reduce the amount of payment being made. In claim 15,
Providing the third party the difference of the change as financial credit.   The method according to claim 15, wherein the additional information to display to the consumer is a mobile phone number or an email address associated with the consumer. A data communication system,
A client device that the consumer uses to enter payment information and program registration options into the data communication system;
A transaction processor communicatively connected to the client device via a communications network, receiving the input payment information and program registration options, and determining a response to the client device;
A registration server communicably connected to the client device and the transaction processor, and changing a payment amount from the input payment information based on a predefined rule set and a state of the consumer, each consumer And a registration server including a database storing a unique personal account number associated with.   21. The system of claim 20, wherein the transaction processor and the registration server are controlled and operated by different entities. In claim 21,
The method may further comprise another client device independently operating in a commercial vendor independently of the client device, regardless of whether a given consumer is interacting with the client device or interacting with the other client device. A system in which the given consumer is uniquely identified at the registration server based on a unique personal account number of the given consumer.