U.S. patent application number 16/924795 was filed with the patent office on 2020-10-29 for measuring conversion of an online advertising campaign from an offline merchant.
This patent application is currently assigned to Twitter,Inc.. The applicant listed for this patent is Geraud Boyer, Amit Kumar, Eckart Walther, Jeffrey WINNER. Invention is credited to Geraud Boyer, Amit Kumar, Eckart Walther, Jeffrey WINNER.
Application Number | 20200342493 16/924795 |
Document ID | / |
Family ID | 1000004943077 |
Filed Date | 2020-10-29 |
![](/patent/app/20200342493/US20200342493A1-20201029-D00000.png)
![](/patent/app/20200342493/US20200342493A1-20201029-D00001.png)
![](/patent/app/20200342493/US20200342493A1-20201029-D00002.png)
![](/patent/app/20200342493/US20200342493A1-20201029-D00003.png)
![](/patent/app/20200342493/US20200342493A1-20201029-D00004.png)
![](/patent/app/20200342493/US20200342493A1-20201029-D00005.png)
![](/patent/app/20200342493/US20200342493A1-20201029-D00006.png)
![](/patent/app/20200342493/US20200342493A1-20201029-D00007.png)
![](/patent/app/20200342493/US20200342493A1-20201029-D00008.png)
![](/patent/app/20200342493/US20200342493A1-20201029-D00009.png)
United States Patent
Application |
20200342493 |
Kind Code |
A1 |
WINNER; Jeffrey ; et
al. |
October 29, 2020 |
MEASURING CONVERSION OF AN ONLINE ADVERTISING CAMPAIGN FROM AN
OFFLINE MERCHANT
Abstract
A technique for tracking conversion of an online offer includes
tracking online and/or offline transactions. A customer accepts an
offer provided by a merchant and submits his or her account
information so that he or she may receive a reward for satisfying
criteria associated with the offer. Transactions of the merchant
are then monitored at the payment processor level to determine
whether the customer satisfies the purchase criteria. Therefore,
online and offline conversion can both be tracked. Further, the
merchant is able to determine the overall effectiveness of
advertising campaigns by analyzing the number of offers that are
both accepted and satisfied.
Inventors: |
WINNER; Jeffrey; (San
Francisco, CA) ; Boyer; Geraud; (San Francisco,
CA) ; Kumar; Amit; (Palo Alto, CA) ; Walther;
Eckart; (Palo Alto, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
WINNER; Jeffrey
Boyer; Geraud
Kumar; Amit
Walther; Eckart |
San Francisco
San Francisco
Palo Alto
Palo Alto |
CA
CA
CA
CA |
US
US
US
US |
|
|
Assignee: |
Twitter,Inc.
San Francisco
CA
|
Family ID: |
1000004943077 |
Appl. No.: |
16/924795 |
Filed: |
July 9, 2020 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
13211253 |
Aug 16, 2011 |
|
|
|
16924795 |
|
|
|
|
61442943 |
Feb 15, 2011 |
|
|
|
61442691 |
Feb 14, 2011 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06Q 30/0246 20130101;
G06Q 30/02 20130101; G06Q 30/0273 20130101 |
International
Class: |
G06Q 30/02 20060101
G06Q030/02 |
Claims
1. In a system (100) comprising a point of sale (POS) system (104)
associated with a merchant (102), and a payment processor (110)
communicatively coupled to the POS system via a network (118): an
offer engine (108) to measure conversion of an online advertising
campaign for the merchant by determining transactions completed,
using the PUS system, between respective customers and the merchant
in response to the respective customers receiving and accepting an
online offer from the merchant via an online advertisement (202,
204) rendered on customer devices coupled to the network and used
by the respective customers to view the online offer, wherein the
online offer specifies at least one criterion for the respective
customers to satisfy the online offer and complete the transactions
with the merchant, the offer engine comprising: a processor; and a
memory storing computer-readable instructions that when executed by
the processor cause the offer engine to: A) provide, via the
network, a merchant registration interface; B) receive, via the
network and in response to A), merchant account registration
information including a merchant identification (ID) issued to the
merchant by one of a merchant bank and the payment processor,
wherein the merchant ID uniquely identifies transactions initiated
at the merchant via the POS system; C) generate a merchant account
based on the merchant account registration information received in
B); D) receive, via the network, from the merchant having the
merchant account generated in C), a request to create the online
offer and offer information associated with the online offer,
wherein the offer information includes the at least one criterion
for the respective customers to satisfy the online offer; E)
determine that a first customer of the respective customers viewing
the online advertisement including the online offer via a first
customer device clicked on the online advertisement including the
online offer; F) provide, via the network and in response to E), an
interface (200) for display on the first customer device of the
first customer to register a first customer account to accept the
online offer; G) receive, via the network and in response to F), a
first payment account number of a first payment account for the
first customer, wherein the first payment account includes at least
one of a customer credit card, a customer debit card, and a
customer prepaid card; H) transmit, via the network to the payment
processor, the merchant ID received in B) and not the offer
information received in D), such that the payment processor has no
offer information associated with the online offer; I) receive, via
the network from the payment processor, in response to H), at least
one transaction initiated using the POS system associated with the
merchant; and J) determine, based on the at least one transaction
received in I) and the offer information received in D), whether
the first customer has completed a first transaction corresponding
to the online offer.
2. The offer engine of claim 1, wherein D); the at least criterion
for the respective customers to satisfy the online offer includes
at least one of: buying a first amount of a product; spending a
second amount of money; completing the transaction at a particular
time; or making a number of purchases within a particular amount of
time.
3. The offer engine of claim 1, wherein after D), and when executed
by the processor, the computer-readable instructions further cause
the offer engine to: cause the online offer to be published, via
the network, as at least one of a contextual advertisement on a
search engine results page, a banner advertisement, a rich media
advertisement, a social network advertisement, and interstitial
advertisement, an online classified advertisement, a
short-message-service (SMS) message, or an email.
4. The offer engine of claim 1, wherein in E), the offer engine
determines, via at least one of a browser cookie and Internet
Protocol (IP) address tracking, that the first customer clicked on
the online advertisement including the online offer.
5. The offer engine of claim 1, wherein in F), the interface
provided by the offer engine comprises: at least one first
interface widget to allow the first customer to register the first
customer account; at least one second interface widget to allow the
first customer to accept the online offer; and at least one third
interface widget to allow the first customer to be electronically
notified when the online offer is satisfied.
6. The offer engine of claim 5, wherein the at least one first
interface widget comprises: a first field to enter the first
payment account number of the first payment account of the first
customer; a second field to enter an expiration date of the first
payment account; and a third field to enter a security code for the
first payment account.
7. The offer engine of claim I, wherein in response to G), the
offer engine: G1) generates and stores the first customer account
in the memory; G2) generates and stores in the first customer
account at least one data object based on the first payment account
number received in G); and G3) associates the online offer with the
first customer account.
8. The offer engine of claim 7, wherein in G2), the offer engine
applies a hash function to the first payment account number to
generate a corresponding hash value as the at least one data
object.
9. The offer engine of claim 1, wherein in I), each transaction of
the at least one transaction received by the offer engine from the
payment processor includes a unique transaction ID, the merchant
ID, a transaction payment account number, a total amount charged,
and a timestamp.
10. The offer engine of claim 1, wherein in J), the offer engine:
J1) determines if the at least one criterion specified by the
online offer is satisfied in the at least one transaction received
from the payment processor; and J2) for each transaction of the at
least one transaction in which the at least one criterion specified
by the online offer is satisfied, determines if one transaction of
the at least one transaction is the first transaction completed by
the first customer, based at least in part on the first payment
account number of the first payment account for the first customer
received in G).
11. The offer engine of claim 10, wherein J1), the at least
criterion includes at least one of: buying a first amount of a
product; spending a second amount of money; completing the
transaction at a particular time; or making a number of purchases
within a particular amount of time.
12. The offer engine of claim 11, wherein in I), each transaction
of the at least one transaction received by the offer engine from
the payment processor includes a unique transaction ID, the
merchant ID, a hashed transaction payment account number, a total
amount charged, and a timestamp.
13. The offer engine of claim 12, wherein in J2), the offer engine:
extracts the hashed transaction payment account number included in
the one transaction; compares the extracted hashed transaction
payment account number against a first hashed account number
corresponding to the first payment account number of the first
payment account for the first customer received in G); and
determines that the first customer has completed the first
transaction corresponding to the online offer if the extracted
hashed transaction payment account number matches the first hashed
account number corresponding to the first payment account number of
the first payment account for the first customer.
14. The offer engine of claim 10, wherein: in I), each transaction
of the at least one transaction received by the offer engine from
the payment processor includes a unique transaction ID; and in J1),
the offer engine: J1a) obtains from the PUS system, via the
network, POS transaction data for the at least one transaction; and
J1b) determines if the at least one criterion specified by the
online offer is satisfied in the at least one transaction received
from the payment processor, based on at least some of the PUS
transaction data obtained from the PUS system and the unique
transaction ID for the at least one transaction.
15. The offer engine of claim 14, wherein for each transaction of
the at least one transaction: the POS system sends a request, via
the network, to the payment processor to process the transaction;
the payment processor returns to the POS system, via the network,
the unique transaction ID of the transaction; the POS system
creates and stores a POS transaction object for the transaction,
the PUS transaction object comprising the unique transaction ID of
the transaction and at least one of: a unique PUS transaction ID;
at least one universal product code (UPC) for at least one item
purchased in the transaction; a description for the at least one
item purchased in the transaction; a subtotal amount for the
transaction; a tax amount for the transaction; or a total amount
for the transaction; and in J1a), the POS transaction data obtained
by the offer engine is based on the POS transaction data
object.
16. In a system (100) comprising a point of sale (POS) system (104)
associated with a merchant (102), and a payment processor (110)
communicatively coupled to the POS system via a network (118): an
offer engine (108) to measure conversion of an online advertising
campaign for the merchant by determining transactions completed,
using the POS system, between respective customers and the merchant
in response to the respective customers receiving and accepting an
online offer from the merchant via an online advertisement (202,
204) rendered on customer devices coupled to the network and used
by the respective customers to view the online offer, wherein the
online offer specifies at least one criterion for the respective
customers to satisfy the online offer and complete the transactions
with the merchant, the offer engine comprising: a processor; and a
memory storing computer-readable instructions that when executed by
the processor cause the offer engine to: A) determine that a first
customer of the respective customers viewing the online
advertisement including the online offer via a first customer
device clicked on the online advertisement including the online
offer; B) provide. via the network and in response to A). an
interface (200) for display on the first customer device of the
first customer to register a first customer account to accept the
online offer; C) receive, via the network and in response to B), a
first payment account number of a first payment account for the
first customer, wherein the first payment account includes at least
one of a customer credit card, a customer debit card, and a
customer prepaid card; D) transmit, via the network to the payment
processor, a merchant identification (ID) for the merchant and no
offer information regarding the online offer, such that the payment
processor has no offer information associated with the online
offer; E) receive, via the network from the payment processor, in
response to D), at least one transaction initiated using the POS
system associated with the merchant; and F) determine, based on the
at least one transaction received in E) whether the first customer
has completed a first transaction corresponding to the online
offer.
17. The offer engine of claim 16, wherein in B), the offer engine
determines, via at least one of a browser cookie and Internet
Protocol (IP) address tracking, that the first customer clicked on
the online advertisement including the online offer.
18. The offer engine of claim 16, wherein in B), the interface
provided by the offer engine comprises: at least one first
interface widget to allow the first customer to register the first
customer account; at least one second interface widget to allow the
first customer to accept the online offer; and at least one third
interface widget to allow the first customer to be electronically
notified when the online offer is satisfied.
19. The offer engine of claim 18, wherein the at least one first
interface widget comprises: a first field to enter the first
payment account number of the first payment account of the first
customer; a second field to enter an expiration date of the first
payment account; and a third field to enter a security code for the
first payment account.
20. The offer engine of claim 16, wherein in response to C), the
offer engine: C1) generates and stores the first customer account
in the memory; C2) generates and stores in the first customer
account at least one data object based on the first payment account
number received in C); and C3) associates the online offer with the
first customer account.
21. The offer engine of claim 20, wherein in C2), the offer engine
applies a hash function to the first payment account number to
generate a corresponding hash value as the at least one data
object.
22. The offer engine of claim 16, wherein in E), each transaction
of the at least one transaction received by the offer engine from
the payment processor includes a unique transaction ID, the
merchant ID, a transaction payment account number, a total amount
charged, and a timestamp.
23. The offer engine of claim 22, wherein: the memory of the offer
engine further stores offer information associated with the online
offer, wherein the offer information includes the at least one
criterion for the respective customers to satisfy the online offer;
and in F), the offer engine: F1) determines, based on the offer
information stored in the memory, if the at least one criterion
specified by the online offer is satisfied in the at least one
transaction received from the payment processor; and F2) for each
transaction of the at least one transaction in which the at least
one criterion specified by the online offer is satisfied,
determines if one transaction of the at least one transaction is
the first transaction completed by the first customer, based at
least in part on the first payment account number of the first
payment account for the first customer received in C).
24. The offer engine of claim 23, wherein in F1), the at least
criterion includes at least one of: buying a first amount of a
product; spending a second amount of money: completing the
transaction at a particular time; or making a number of purchases
within a particular amount of time.
25. The offer engine of claim 24, wherein in E), each transaction
of the at least one transaction received by the offer engine from
the payment processor includes a unique transaction ID, the
merchant ID, a hashed transaction payment account number, a total
amount charged, and a timestamp.
26. The offer engine of claim 25, wherein in F2), the offer engine:
extracts the hashed transaction payment account number included in
the one transaction; compares the extracted hashed transaction
payment account number against a first hashed account number
corresponding to the first payment account number of the first
payment account for the first customer received in C); and
determines that the first customer has completed the first
transaction corresponding to the online offer if the extracted
hashed transaction payment account number matches the first hashed
account number corresponding to the first payment account number of
the first payment account for the first customer.
27. The offer engine of claim 26, wherein: in E), each transaction
of the at least one transaction received by the offer engine from
the payment processor includes a unique transaction ID; and in F1),
the offer engine: F1a) obtains from the POS system, via the
network, POS transaction data for the at least one transaction; and
F1b) determines if the at least one criterion specified by the
online offer is satisfied in the at least one transaction received
from the payment processor, based on at least some of the POS
transaction data obtained from the POS system and the unique
transaction ID for the at least one transaction.
28. The offer engine of claim 27, wherein for each transaction of
the at least one transaction: the POS system sends a request, via
the network, to the payment processor to process the transaction;
the payment processor returns to the PUS system, via the network,
the unique transaction ID of the transaction; the PUS system
creates and stores a PUS transaction object for the transaction,
the POS transaction object comprising the unique transaction ID of
the transaction and at least one of: a unique POS transaction ID;
at least one universal product code (UPC) for at least one item
purchased in the transaction; a description for the at least one
item purchased in the transaction; a subtotal amount for the
transaction; a tax amount for the transaction; or a total amount
for the transaction; and in F1a). the POS transaction data obtained
by the offer engine is based on the POS transaction data
object.
29. The offer engine of claim 26, wherein prior to A), and when
executed by the processor, the computer-readable instructions
further cause the offer engine to: A-4) provide, via the network, a
merchant registration interface; A-3) receive, via the network and
in response to A-4), merchant account registration information
including the merchant ID, wherein the merchant ID is issued to the
merchant by one of a merchant bank and the payment processor, and
wherein the merchant ID uniquely identifies transactions initiated
at the merchant via the PUS system; A-2) generate a merchant
account based on the merchant account registration information
received in A-3); and A-1) receive, via the network, from the
merchant having the merchant account, generated in A-2), a request
to create the online offer and the offer information associated
with the online offer.
30. A method for measuring conversion of an online advertising
campaign for a merchant by determining transactions completed
between respective customers and the merchant in response to the
respective customers receiving and accepting an online offer from
the merchant via an online advertisement rendered on customer
devices coupled to a network and used by the respective customers
to view the online offer, wherein the online offer specifies at
least one criterion for the respective customers to satisfy the
online offer and complete the transactions with the merchant, the
method comprising: A) determining that a first customer of the
respective customers viewing the online advertisement including the
online offer via a first customer device clicked on the online
advertisement including the online offer; B) providing, via the
network and in response to A), an interface for display on the
first customer device of the first customer to register a first
customer account to accept the online offer; C) receiving, via the
network and in response to B), a first payment account number of a
first payment account for the first customer, wherein the first
payment account includes at least one of a customer credit card, a
customer debit card, and a customer prepaid card; D) transmitting,
via the network to a payment processor communicatively coupled to a
point of sale (POS) system associated with the merchant, a merchant
identification (ID) for the merchant and no offer information
regarding the online offer, such that the payment processor has no
offer information associated with the online offer; E) receiving,
via the network from the payment processor, in response to D), at
least one transaction initiated using the POS system associated
with the merchant; and F) determining, based on the at least one
transaction received in E) whether the first customer has completed
a first transaction corresponding to the online offer.
31. The method of claim 30, wherein B) comprises determining, via
at least one of a browser cookie and Internet Protocol (IP) address
tracking, that the first customer clicked on the online
advertisement including the online offer.
2. The method of claim 30, wherein in B), the interface comprises:
at least one first interface widget to allow the first customer to
register the first customer account; at least one second interface
widget to allow the first customer to accept the online offer; and
at least one third interface widget to allow the first customer to
be electronically notified when the online offer is satisfied.
33. The method of claim 32, wherein the at least one first
interface widget comprises: a first field to enter the first
payment account number of the first payment account of the first
customer; a second field to enter an expiration date of the first
payment account; and a third field to enter a security code for the
first payment account.
34. The method of claim 30, wherein C) further comprises: C1)
generating and storing the first customer account; C2) generating
and storing in the first customer account at least one data object
based on the first payment account number received in C); and C3)
associating the online offer with the first customer account.
35. The method of claim 34, wherein C2) comprises applying a hash
function to the first payment account number to generate a
corresponding hash value as the at least one data object.
36. The method of claim 30, wherein in E), each transaction of the
at least one transaction received from the payment processor
includes a unique transaction ID, the merchant ID, a transaction
payment account number, a total amount charged, and a
timestamp.
37. The method of claim 36, further comprising storing offer
information associated with the online offer, wherein the offer
information includes the at least one criterion for the respective
customers to satisfy the online offer, wherein F) comprises: F1)
determining, based on the offer information, if the at least one
criterion specified by the online offer is satisfied in the at
least one transaction received from the payment processor; and F2)
for each transaction of the at least one transaction in which the
at least one criterion specified by the online offer is satisfied,
determining if one transaction of the at least one transaction is
the first transaction completed by the first customer, based at
least in part on the first payment account number of the first
payment account for the first customer received in C).
38. The method of claim 37, wherein in F1), the at least criterion
includes at least one of: buying a first amount of a product;
spending a second amount of money; completing the transaction at a
particular time; or making a number of purchases within a
particular amount of time.
39. The method of claim 38, wherein in E), each transaction of the
at least one transaction received by the offer engine from the
payment processor includes a unique transaction ID, the merchant
ID, a hashed transaction payment account number, a total amount
charged, and a timestamp.
40. The method of claim 39, wherein F2) comprises: extracting the
hashed transaction payment account number included in the one
transaction; comparing the extracted hashed transaction payment
account number against a first hashed account number corresponding
to the first :payment account number of the first payment account
for the first customer received in C); and determining that the
first customer has completed the first transaction corresponding to
the online offer if the extracted hashed transaction payment
account number matches the first hashed account number
corresponding to the first payment account number of the first
payment account for the first customer.
41. The method of claim 40, wherein: in E), each transaction of the
at least one transaction received from the payment processor
includes a unique transaction ID; and F1) comprises: F1a) obtaining
from the POS system, via the network, POS transaction data for the
at least one transaction; and F1b) determining if the at least one
criterion specified by the online offer is satisfied in the at
least one transaction received from the payment processor, based on
at least some of the POS transaction data obtained from the POS
system and the unique transaction ID for the at least one
transaction.
42. The method of claim 41, wherein for each transaction of the at
least one transaction: the POS system sends a request, via the
network, to the payment processor to process the transaction; the
payment processor returns to the POS system, via the network, the
unique transaction ID of the transaction; the POS system creates
and stores a POS transaction object for the transaction, the POS
transaction object comprising the unique transaction ID of the
transaction and at least one of: a unique POS transaction ID; at
least one universal product code (UPC) for at least one item
purchased in the transaction; a description for the at least one
item purchased in the transaction; a subtotal amount for the
transaction; a tax amount for the transaction; or a total amount
for the transaction; and in F1a), the POS transaction data is based
on the POS transaction data object.
43. The method of claim 41, wherein prior to A), the method further
comprises: A-4) providing, via the network, a merchant registration
interface; A-3) receiving, via the network and in response to A-4),
merchant account registration information including the merchant
ID, wherein the merchant ID is issued to the merchant by one of a
merchant bank and the payment processor, and wherein the merchant
ID uniquely identifies transactions initiated at the merchant via
the POS system A-2) generating a merchant account based on the
merchant account registration information received in A-3); and
A-1) receiving, via the network, from the merchant having the
merchant account generated in A-2), a request to create the online
offer and the offer information associated with the online offer.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims priority benefit to United States
provisional patent application titled, "SYSTEM AND METHOD
IMPLEMENTING REFERRAL PROGRAMS," filed on Feb. 15, 2011, having
application Ser. No. 61/442,943 (Attorney Docket Number
CARD/0002USL) and also claims priority benefit to United States
provisional patent application titled, "SYSTEM AND METHOD FOR
IMPLEMENTING PAYMENT NETWORK COOKIES," filed on Feb. 14, 2011,
having application Ser. No. 61/442,691 (Attorney Docket Number
CARD/0003USL), both of which are incorporated by reference
herein.
BACKGROUND
Field of the Invention
[0002] The present invention relates to the field of computer
software and, in particular, to a system and method for monitoring
for transactions.
Description of the Related Art
[0003] Online advertising is a form of promotion that uses the
internet to deliver marketing messages to potential customers.
Examples of online advertising include contextual advertisements on
search engine results pages, banner advertisements, rich media
(e.g., video) advertisements, social network advertisements,
interstitial advertisements, online classified advertisements,
e-mail marketing, and many others.
[0004] One important aspect of an online advertisement is the
online "conversion" of the online advertisement, which refers
generally to a customer completing an online transaction with an
online merchant in response to viewing the online advertisement.
Typically, when a customer views an online advertisement, the
customer's activity across one or more web pages is tracked to
determine whether a particular online transaction is actually
completed by the customer. One example of a tracking technique is
referred to as pixel-based tracking, where a 1.times.1 pixel
image--often referred to as a "web beacon"--is linked to an online
advertisement and included in each web page of, for example, an
online shopping cart. The 1.times.1 pixel image reports information
back to a manager of the online advertisement such that the manager
is able to determine whether the customer has reached an order
confirmation page, indicating that the online advertisement was
successful by resulting in a conversion.
[0005] Although many merchants provide their customers the ability
to shop online, there exists a large number of merchants that have
one or more brick-and-mortar locations, referred to herein as
"offline" merchants. Though offline merchants typically do not
provide an online shopping cart to their customers, the offline
merchants may nonetheless be interested in online advertising that
causes customers to visit their brick-and-mortar locations in an
attempt to increase sales. Unfortunately, as with offline
advertising (e.g., advertising in magazines, TV, radio, etc.), it
is difficult for offline merchants to measure the performance of
their online advertising campaigns.
[0006] One attempt to measure performance of an advertising
campaign involves polling customers and asking them to share the
motivation for the purchase they are making. For example, if a
customer shops at a merchant location during a sale, then the
merchant may ask the customer, "Where did you hear about our sale?"
Unfortunately, some customers are lazy and do not wish to share
such information with the merchant or may provide inaccurate
information. Determining the effectiveness of an online portion of
ad campaign is further complicated when the same advertisements are
presented to potential customers through other channels that are
not online.
[0007] As the foregoing illustrates, there is a need in the art for
an improved technique that overcomes the deficiencies of prior
approaches.
SUMMARY
[0008] One embodiment of the invention provides a method for
tracking conversion of an online offer. The method includes
identifying an online offer accepted by a customer; receiving a set
of transactions executed at a merchant; parsing the set of
transactions to determine that a set of criteria associated with
the online offer has been satisfied by the customer via one or more
transactions at the merchant; and notifying the merchant that the
online offer has been satisfied by the customer.
[0009] Another embodiment of the invention provides a method for
identifying an identification code corresponding to a merchant. The
method includes providing the merchant access to an account;
instructing the merchant to execute a transaction using the
account; parsing one or more transactions made using the account to
identify the transaction; and extracting from the transaction the
identification code of the merchant.
[0010] Further embodiments of the present invention provide a
computer-readable storage medium that includes instructions for
causing a computer system to carry out one or more of the methods
set forth above.
BRIEF DESCRIPTION OF THE DRAWINGS
[0011] So that the manner in which the above recited features of
the invention can be understood in detail, a more particular
description of the invention, briefly summarized above, may be had
by reference to embodiments, some of which are illustrated in the
appended drawings. It is to be noted, however, that the appended
drawings illustrate only typical embodiments of this invention and
are therefore not to be considered limiting of its scope, for the
invention may admit to other equally effective embodiments.
[0012] FIG. 1 is a block diagram illustrating components of a
system in which embodiments of the invention may be
implemented.
[0013] FIG. 2 is a screenshot of an interface configured to gather
customer data from a customer that accepts an offer, according to
one embodiment of the invention.
[0014] FIG. 3 is a flow diagram of method steps for generating a
merchant account, according to one embodiment of the invention.
[0015] FIG. 4 is a flow diagram of method steps for associating a
customer with an offer, according to one embodiment of the
invention.
[0016] FIG. 5 is a flow diagram of method steps for determining
whether a set of offers has been satisfied, according to one
embodiment of the invention.
[0017] FIG. 6 is a flow diagram of method steps for processing a
group offer, according to one embodiment of the invention.
[0018] FIG. 7 is a flow diagram of method steps for processing a
referral offer, according to one embodiment of the invention.
[0019] FIG. 8 is a flow diagram of method steps for processing an
offer involving specific criteria, according to one embodiment of
the invention.
[0020] FIG. 9 is a flow diagram of method steps for extracting an
identification (ID) of a merchant, according to one embodiment of
the invention.
DETAILED DESCRIPTION
[0021] In the following description, several specific details are
presented to provide a thorough understanding of embodiments of the
invention. One skilled in the relevant art will recognize, however,
that the concepts and techniques disclosed herein can be practiced
without one or more of the specific details, or in combination with
other components, etc. In other instances, well-known
implementations or operations are not shown or described in detail
to avoid obscuring aspects of various examples disclosed
herein.
[0022] FIG. 1 is a block diagram illustrating components of a
system 100 in which embodiments of the invention may be
implemented. As shown, system 100 includes a merchant 102, a point
of sale (POS) system 104 with an associated database 106, an offer
engine (OE) 108 with an associated database 109, a payment
processor 110 with an associated database 112, one or more
financial institutions 114, and a network 118. As shown, merchant
102, OE 108, payment processor 110 and financial institutions 114
communicate with one another via network 108, such as the
internet.
[0023] Though not illustrated in FIG. 1, each of OE 108, payment
processor 110 and POS system 104 include conventional components of
a computing device, e.g., a processor, system memory, a hard disk
drive, input devices such as a mouse and a keyboard, and output
devices such as a monitor.
[0024] In one embodiment, DB 106, DB 109 and/or DB 112 can be any
type of storage system, e.g., a relational database hosted on a
network file system (NFS) device, a storage system hosted by a
cloud service provider, and the like. Alternatively, DB 106, DB 109
and/or DB 112 may be integrated in POS system 104, OE 108 and
payment processor 110, respectively, such as a database hosted on a
local disk and managed by an operating system.
[0025] Merchant 102 may be a brick-and-mortal physical merchant, an
online merchant, a mail-order/telephone-order (MOTO) merchant, and
the like. Merchant 102 is capable of processing accounts of
customers when they pay for goods or services offered by merchant
102. Such accounts include credit cards, debit cards, prepaid
cards, and the like. In some embodiments, merchant 102 is equipped
with POS system 104. As shown, POS system 104 is coupled to
database 106, which enables POS system 104 to store detailed
information associated with transactions between merchant 102 and
customers of merchant 102.
[0026] A transaction may be initiated at merchant 102 according to
a variety of techniques. For example, a cashier at merchant 102 may
swipe a credit card through a card reader included in POS system
104. Alternatively, an account may be delivered virtually on a
customer's mobile device, which enables a customer at merchant 102
to wave his/her mobile device in front of a contactless card reader
included in POS system 104. Further, the customer may show his/her
mobile device to a cashier at merchant 102 who manually enters an
account number of the account being used by the customer.
Alternatively, the mobile device may include a contactless chip or
tag that is wireless-readable by POS system 104 using, e.g.,
near-field-communication (NFC) technology.
[0027] Payment processor 110, in conjunction with financial
institutions 114, facilitates payment transactions between merchant
102 and customers thereof, and stores the transactions in DB 112.
More specifically, when a customer attempts to pay for goods and/or
services offered by merchant 102 using his or her account, a POS
terminal submits the transaction through a merchant account to an
acquiring bank of the merchant (i.e., one of the financial
institutions 114). The acquiring bank then transmits a request for
funds through the payment processor 110. The payment processor 110
routes the request for funds to the card holder's issuing bank
(i.e., the appropriate financial institution 114) for authorization
based on a type of the account. The issuing bank verifies the card
number, the transaction type, and the amount. In some examples, the
issuing bank then reserves that amount of the cardholder's credit
limit for the merchant.
[0028] For example, if payment processor 110 detects that the
account is a debit card associated with a checking account of the
customer, then payment processor 110 routes the transaction request
to the bank that issued the debit card, whereupon the issuing bank
indicates to payment processor 110 whether the checking account
possesses sufficient funds to satisfy the transaction request. In
turn, payment processor 110 indicates to the merchant acquiring
bank whether the request is for funds has been approved. If the
transaction is successfully processed, then funds are transferred
from the card holder's account at the issuing bank to the merchant
account at the inquiring bank.
[0029] An Offer Engine (POE) 108 is configured to determine the
effectiveness of advertising campaigns requested and managed by
merchant 102. As shown in FIG. 1, OE 108 is in communication with
both merchant 102 and payment processor 110. OE 108 manages
"offers" that are advertised to, possibly accepted by, and possibly
satisfied by customers of merchant 102. The offer can be coupled to
a reward that is given to the customer when he or she has satisfied
the offer, e.g., cash-back rewards, credit card rewards, store
credit, virtual currency, and the like.
[0030] An offer may be any offer that involves a customer
completing a transaction according to specific criteria, such as
buying a certain amount of a product, spending a certain amount in
one purchase, making a purchase at a particular time, making a
number of purchases within a particular amount of time, and the
like. Offers may also involve a group of customers completing a
transaction according to specific criteria. As is described in
greater detail herein, OE 108 is configured to monitor for
transactions to determine whether the criteria for a particular
offer have been satisfied. As is also described herein, OE 108 can
monitor both online and offline transactions to determine whether
the criteria for a particular offer have been satisfied.
[0031] Offer data is stored in database 109 accessed by OE 108. The
offer data is advertised to customers via webpage advertisements,
email marketing campaigns, short-message-service (SMS) messages,
telemarketing campaigns, and the like, as described herein. As
described below in conjunction with FIG. 2, OE 108 provides an
interface that enables customers (e.g., individuals) to register an
account with OE 108, including their account information, and
subsequently accept and complete offers. OE 108 subsequently
monitors transactions initiated at merchant 102 (i.e., online
and/or offline) to determine whether offers are satisfied by the
customers whom accepted them.
[0032] FIG. 2 is a screenshot of an interface 200 configured to
gather customer data from a customer that accepts an offer,
according to one embodiment of the invention. As shown, interface
200 is accessible via a web browser application and includes offer
advertisement widget 202, offer advertisement widget 204, and offer
acceptance form 206. Offer advertisement widgets 202, 204, when
selected by a customer (e.g., by clicking on them) enable a
customer to accept offers provided by merchant 102 (e.g., "Merchant
A"). For example, the customer may accept the offer advertised in
offer advertisement widget 202 to receive a $20.00 cash back reward
for any in-store purchase over $100.00 at Merchant A. Similarly,
the customer may also accept the offer advertised in offer
advertisement widget 204 to receive a $50.00 cash back reward after
performing five in-store purchases, each being $75.00 or more, at a
physical location of merchant A.
[0033] When an offer advertisement widget, such as offer
advertisement widget 202 or 204, is selected by a customer, an
offer acceptance form 206 is caused to be displayed within
interface 200. The customer then enters a variety of information
that is subsequently used by OE 108 to determine whether the
customer eventually satisfies the offer, as described in further
detail below. The customer enters the details of one or more
accounts, including account number, expiration date, security code,
billing address, etc.
[0034] In some embodiments, the customer may optionally submit his
or her phone number and/or email address to receive additional
offer notifications from OE 108. When the customer provides a phone
number and subsequently satisfies an offer, OE 108 may send an SMS
message to the phone number with a message indicating that the
offer has been satisfied. OE 108 may, in some embodiments, provide
another offer to the customer for acceptance by the customer via
SMS.
[0035] Additionally, the customer may submit his or her information
by providing to OE 108 credentials that link to an existing online
account hosted by an alternative online service, e.g., a Facebook
account or an Oauth account. In particular, OE 108 accesses the
online account using the credentials and retrieves the required
information, thereby reducing the amount of input required by the
customer.
[0036] Additionally, the customer may opt to create a customer
account with OE 108 when accepting, for example, an offer for the
first time. In one example, the customer opts to create a customer
account by clicking on a checkbox titled "Create Account" (not
shown) and included in offer acceptance form 206, which causes a
password input field to appear. Subsequently, and upon providing
valid inputs to OE 108 when accepting the offer, OE 108 generates a
customer account for the customer and stores the customer account
in DB 109. In one example, the customer's email address is assigned
as a login ID and is tied to the password that is input by the
customer. In this way, when the customer accepts additional offers,
he or she is only required to input his or her email address and
password by, for example, clicking the "Sign In" link included in
offer acceptance form 206. In this way, the customer is able to
recall his or her account information and is not required to
redundantly provide his or her account information each time he or
she accepts an offer.
[0037] Though not illustrated in FIG. 2, the customer may associate
one or more of his or her account numbers with his or her account.
Thus, the OE 108 can track transactions made using any one of the
one or more accounts.
[0038] FIG. 3 is a flow diagram of method steps 300 for generating
a merchant account, according to one embodiment of the invention.
Persons skilled in the art will understand that, even though method
300 is described in conjunction with FIG. 1, any system configured
to perform the method steps, in any order, is within the scope of
embodiments of the invention. A merchant account enables merchants
to manage offers through interfaces provided by OE 108. As shown,
method 300 begins at step 302, where OE 108 receives, e.g., from an
administrator of merchant 102, a request to generate a merchant
account. For example, the administrator may click a "Sign Up" link
found on an interface provided by OE 108 that causes a registration
interface to be displayed.
[0039] At step 304, OE 108 receives merchant account registration
information. Merchant account registration includes, for example, a
merchant identification (ID) issued to merchant 102 by the
merchant's acquiring bank and/or payment processor 110, where the
merchant ID may be used to uniquely identify transactions initiated
at merchant 102. POE 110 can filter transaction data processed by
payment processor 110 such that POE 110 is able to determine
whether accepted offers have been satisfied. As described in
further detail below, embodiments of the invention provide a
technique for determining a merchant ID of a merchant, since the
merchant is sometimes not aware of their own merchant ID, and thus
cannot provide this information to the OE 108 at step 304.
[0040] At step 306, and in response to receiving the merchant
account registration information at step 304, OE 108 generates a
merchant account based on the registration information. The
merchant account and associated information is stored in database
109.
[0041] At step 308, OE 108 receives one or more requests to create
offers. Such requests may be generated by merchant 102 via
interfaces provided by OE 108 that enable merchant 102 to submit
information associated with the offers. For example, the merchant
102 may request an offer that provides a reward of $30.00 cash-back
to customers who accept the offer and perform a purchase of $150.00
or more with the merchant in a single transaction any time during
the month of July in a given year.
[0042] At step 310, OE 108 causes the offers to be published so
that they can be accepted by and/or satisfied by one or more
customers. In some embodiments, a third-party, other than the OE
108 may publish the offers according to the techniques described
above, e.g., web marketing campaigns, email marketing campaigns,
etc. For example, merchant 102 may submit, for a particular offer,
a list of customer email addresses to which an email that describes
the offer should be sent. The offer email received by the customers
may include a hyperlink that, when opened by a customer, displays
to the customer an offer acceptance form associated with the offer,
e.g., offer acceptance form 206.
[0043] FIG. 4 is a flow diagram of method steps 400 for associating
a customer with an offer, according to one embodiment of the
invention. Persons skilled in the art will understand that, even
though method 400 is described in conjunction with FIG. 1, any
system configured to perform the method steps, in any order, is
within the scope of embodiments of the invention. As shown, method
400 begins at step 402, where OE 108 detects that a customer
selects to register for an offer, e.g., via clicking on offer
advertisement widget 202.
[0044] At step 404, OE 108 determines whether a customer account
exists for the customer. This may be determined according to a
variety of techniques, including analysis of browser cookies,
internet protocol (IP) addresses, login information, etc., that is
accessible to OE 108 and/or provided by the customer. For example,
the customer may select a "Sign In" hyperlink included in interface
200 and submit his or her login credentials, whereupon OE 108
references database 109 with the login credentials to determine
whether a customer account exists for the customer. If the customer
holds an account with OE 108, then OE 108 may display to the
customer a list of one or more account numbers registered with the
customer's account and previously provided by the customer, and
method 400 proceeds to step 414, described below. If the customer
does not hold an account with OE 108, then OE 108 displays to the
customer input fields that enable him or her to input customer
account registration information and accept the offer, and method
400 proceeds to step 406. At step 406, OE 108 receives customer
account registration information from the customer, e.g., the
customer account registration information described above in
conjunction with FIG. 2.
[0045] At step 408, OE 108 generates a customer account based on
the registration information. The customer account is then stored
by OE 108 in database 109. At step 410, OE 108 generates a data
object based on one or more properties of billing information
included in the registration information. For example, OE 108 may
apply a hash function to each account number to generate a
corresponding hash value for each account. The hash function is
configured to match a hash function executed by payment processor
110 that receives and hashes the account number of the customer
when merchant 102 attempts to charge the customer for goods or
services. In this way, OE 108 is capable of identifying
transactions when reviewing transaction data provided by payment
processor 110 and associated with merchant 102 without storing the
actual account number, which advantageously decreases overall
liability of OE 108 and increases security to the customer. At step
412, OE 108 associates the data object with the customer
account.
[0046] At step 414, OE 108 associates the offer with the customer
account. Thus, OE 108 may subsequently compare offers accepted by
the customer with transaction data of merchants associated with the
offers to determine whether the offers are satisfied, as described
in further detail below in conjunction with FIG. 5.
[0047] FIG. 5 is a flow diagram of method steps 500 for determining
whether a set of offers has been satisfied, according to one
embodiment of the invention. Persons skilled in the art will
understand that, even though method 500 is described in conjunction
with FIG. 1, any system configured to perform the method steps, in
any order, is within the scope of embodiments of the invention. As
shown, method 500 begins at step 502, where OE 108 receives a set
of offers that have been accepted by one or more customers. For
example, OE 108 may query database 109 to return a set of offers
that have not been marked as expired or satisfied such that only
outstanding and/or valid offers are processed.
[0048] At step 504, OE 108 receives a set of transactions
associated with purchases made at one or more merchants. In one
embodiment, OE 108 receives the set of transactions by querying
payment processor 110 for particular transactions from one or more
merchants. In one example, OE 108 may transmit to payment processor
110 both an ID of a merchant and a set of hashed account numbers
associated with customers who have accepted at least one offer with
the merchant. In response, payment processor 110 returns
transactions that match the hashed account numbers. In another
embodiment, a merchant can give the payment processor 110
permission to deliver all transactions from the merchant to a third
party, such as OE 108. For example, the transactions can be
delivered to the OE 108 periodically (e.g., daily) or in
real-time.
[0049] At step 506, OE 108 sets a first offer in the set of offers
as a current offer. At step 508, OE 108 determines whether criteria
of the current offer are satisfied by one or more transactions in
the set of transactions. In one embodiment, each offer is
associated with executable code that, when executed by OE 108,
enables OE 108 to determine whether the current offer has been
satisfied by one or more transactions in the set of transactions.
For example, if a customer accepts an offer that requires him or
her to make an in-store purchase at merchant 102 between the hours
of 5:00PM-6:00PM, and OE 108 determines from a transaction in the
set of transactions that a customer performs a purchase at merchant
102, then OE 108 analyzes timestamp data included the transaction
to determine whether the transaction was performed between the
required hours.
[0050] If, at step 508, OE 108 determines that criteria of the
current offer are not satisfied by one or more transactions in the
set of transactions, then method 500 proceeds to step 512.
Otherwise, at step 509, OE 108 determines whether the one or more
transactions identified at step 508 are associated with an account
number that matches an account number associated with the current
offer. In one embodiment, OE 108 extracts a hashed account number
from each transaction and compares the hashed account number
against the hashed account number associated with the current
offer. If, at step 509, OE 108 determines that the one or more
transactions identified at step 508 are associated with an account
number that matches an account number associated with the current
offer, then method 500 proceeds to step 512. Otherwise, method 500
proceeds to step 510.
[0051] At step 510, OE 108 notifies a merchant associated with the
current offer that the current offer has been satisfied. In one
embodiment, OE 108 is configured to lookup via database 109
notification preferences of the merchant that is associated with
the current offer. For example, OE 108 may determine that the
merchant associated with the current offer prefers to receive a
daily batch file emailed at the end of each day, where the batch
file includes line-by-line detail of each customer who satisfied an
offer and the reward that is to be given to them. In addition to
notifying the merchant, OE 108 may also be configured to notify the
customer associated with the current offer that he or she has
satisfied the current offer, as described above in conjunction with
FIG. 2.
[0052] At step 512, OE 108 determines whether additional offers are
in the set of offers. If, at step 512, OE 108 determines that
additional offers are in the set of offers, then at step 514, OE
108 sets a next offer in the set of offers as the current offer. In
this way, each of the offers in the set of offers are compared
against the set of transaction data.
[0053] FIG. 6 is a flow diagram of method steps 600 for processing
a group offer, according to one embodiment of the invention.
Persons skilled in the art will understand that, even though method
600 is described in conjunction with FIG. 1, any system configured
to perform the method steps, in any order, is within the scope of
embodiments of the invention. As shown, method 600 begins at step
602, where OE 108 determines that a group offer accepted by a first
customer requires that one or more additional customers both accept
and satisfy the group offer.
[0054] At step 604, OE 108 determines whether the one or more
additional customers have accepted the group offer. In one example,
the first customer accepts a group offer that requires a total of
ten or more customers to spend $25.00 or more with merchant 102. In
this case, OE 108 parses accepted group offers included in database
109 to determine whether nine or more different customers, in
addition to the first customer, have also accepted the group
offer.
[0055] If, at step 604, OE 108 determines that the one or more
additional customers have not accepted the group offer, then the
group offer has not been satisfied, and method 600 ends. Otherwise,
method 600 proceeds to step 606, where OE 108 receives a set of
transactions associated with purchases made by the first customer
and the one or more additional customers according to the
techniques described above in conjunction with FIG. 2.
Alternatively, OE 108 may receive from payment processor 110 a set
of all transactions associated with merchant 102 and filter out
transactions that are not relevant to the group offer.
[0056] At step 608, OE 108 determines whether the first customer
and the one or more additional customers have all satisfied the
group offer. If, at step 608, OE 108 determines that the first
customer and the one or more additional customers have all
satisfied the group offer, then method 600 proceeds to step 610,
where OE 108 notifies a merchant associated with the group offer
that the group offer has been satisfied.
[0057] FIG. 7 is a flow diagram of method steps 700 for processing
a referral offer, according to one embodiment of the invention.
Persons skilled in the art will understand that, even though method
700 is described in conjunction with FIG. 1, any system configured
to perform the method steps, in any order, is within the scope of
embodiments of the invention. As shown, method 700 begins at step
702, where OE 108 determines that a referral offer accepted by a
first customer requires that one or more additional customers
recommended by the first customer both accept and satisfy an offer
associated with the referral offer.
[0058] In one example, the first customer is exposed to an offer
advertisement widget for a referral offer that requires him or her
to get additional customers to both accept and satisfy an offer,
where the offer requires them to make a purchase of $25.00 or more
at merchant 102. Typically, the offer provides incentive to the
five or more friends to both accept and satisfy the referral offer,
such as $5.00 cash back for making the $25.00 purchase. In turn,
the first customer is rewarded $50.00 by merchant 102 when each of
the five or more friends both accept and satisfy the offer. The
first customer may notify the five friends according to a variety
of techniques, such as submitting their email addresses into an
interface provided by OE 108, which then delivers a notification of
the offer to each email address.
[0059] At step 704, OE 108 determines whether the one or more
additional customers have accepted the offer. If, at step 704, OE
108 determines that the one or more additional customers have
accepted the offer, then method 700 proceeds to step 706, where OE
108 receives a set of transactions associated with purchases made
by the additional customers. Otherwise, the referral offer remains
outstanding, and method 700 ends.
[0060] At step 708, OE 108 determines whether the one or more
additional customers have all satisfied the offer. Continuing with
the example described above at step 702, OE 108 determines whether
each of the five customers have made a purchase of $25.00 or more
with merchant 102. If, at step 708, OE 108 determines that the one
or more additional customers have all satisfied the offer, then
method 700 proceeds to step 710, where notifies a merchant
associated with the referral offer that the referral offer has been
satisfied.
[0061] As described above, OE 108 is configured to manage various
types of offers using typical transaction data provided by payment
processor 110. Typical transaction data includes properties such as
a unique transaction ID, a merchant ID, the customer's card
information, a total amount charged, and a timestamp. Though the
total amount charged to the customer is included in the transaction
data, important data pertaining to the breakdown of the total
amount charged--among other more detailed information--is absent
from the transaction data, which may be advantageously used by OE
108 to provide offers that are targeted toward, e.g., purchasing
specific items from merchant 102.
[0062] Such detailed information is often stored in POS system 104
used by merchant 102 to process transactions. In one example,
merchant 102 charges a customer $108.00 in total for five $20.00
items purchased, and an 8% sales tax on the total price. As
described above in conjunction with FIG. 1, POS system 104 requests
payment processor 110 to process the transaction, and payment
processor 110 returns to POS system 104 the transaction ID of the
transaction if the transaction is successfully processed. In turn,
POS system 104 creates in database 109 a new POS transaction object
that includes, e.g., a unique POS transaction ID, universal product
codes (UPC) codes of each of the five items, product details of
each of the five items, a subtotal amount, a tax amount, a total
amount, and the transaction ID returned by payment processor 110.
Moreover, many POS systems provide application programming
interfaces (APIs) that enable administrators to extract transaction
data to, e.g., process returns, calculate performance, and the
like.
[0063] FIG. 8 is a flow diagram of method steps 800 for processing
an offer involving specific criteria, according to one embodiment
of the invention. Persons skilled in the art will understand that,
even though method 800 is described in conjunction with FIG. 1, any
system configured to perform the method steps, in any order, is
within the scope of embodiments of the invention. As shown, method
800 begins at step 802, where OE 108 determines that an offer
accepted by a customer requires processing transactional data
collected by a point-of-sale (POS) system, e.g., POS system
104.
[0064] At step 804, OE 108 obtains the POS transaction data from
POS system 104. In one embodiment, POS system 104 is configured to
upload POS transaction data to OE 108 at regular intervals. In
another embodiment, POS system 104 is configured to query POS
system 104 via an API that provides access to POS system 104 to
retrieve the POS transaction data.
[0065] Next, the optional step 806 enables OE 108 to verify that
the purchase did in fact take place and that no corruption of POS
system 104 has occurred. More specifically, at step 806, OE 108
optionally obtains from a payment processor, e.g., payment
processor 110, transaction data that is related to the POS
transaction data. In one example, OE 108 extracts the transaction
ID from the POS transaction data which, as described above, is
returned by payment processor 110 for each transaction that is
successfully processed. OE 108 then queries payment processor 110
for a transaction that matches the transaction ID. If payment
processor 110 returns a transaction based on the transaction ID,
then OE 108 verifies that the POS transaction data obtained from
POS system 104 is not corrupt. Otherwise, OE 108 may notify
merchant 102 of the discrepancy.
[0066] At step 806, OE 108 determines whether the offer is
satisfied based on the transactional data. In one example, the
offer requires that the customer purchases a medium-sized black
T-Shirt to receive a $2.00 reward. OE 108 then, according to the
techniques described above in conjunction with FIG. 5, processes
the POS transaction data to determine whether the offer has in fact
been satisfied. For example, the POS transaction data may include a
"Description" field with a value "Size: M; Color: Blk" that OE 108
is able to parse and identify as a purchase that satisfies the
offer. In another example, merchant 102 may provide a UPC code
associated with medium-sized black T-Shirts to OE 108 when creating
the offer such that OE 108 need only verify that UPC code included
in the POS transaction data is valid.
[0067] At step 808, OE 108 notifies merchant 102 associated with
the offer that the customer has satisfied the offer according to
the
[0068] FIG. 9 is a flow diagram of method steps 900 for extracting
an identification (ID) of a merchant, according to one embodiment
of the invention. Persons skilled in the art will understand that,
even though method 900 is described in conjunction with FIG. 1, any
system configured to perform the method steps, in any order, is
within the scope of embodiments of the invention. In the method
900, OE 108 is configured to act as an issuing bank. More
specifically, OE 108 is configured to issue one or more pre-paid
credit cards that are distributed to merchants who are unaware of
their merchant ID, which is a typical problem. When charges are
attempted on such cards, OE 108 receives a transaction request
because the OE 108 is the issuer of the card. The transaction
received by the OE 108 includes at least a merchant ID of the
merchant that is attempting to charge the card. The transaction may
also include a date/time that the transaction was generated and
amount associated therewith.
[0069] As shown, method 900 begins at step 902, where OE 108 issues
a credit card to a merchant. OE 108 also maintains a hash of the
numbers included on the credit card according to the hashing
techniques described above in conjunction with FIG. 4 such that
comparisons can be made in a secure manner.
[0070] At step 904, OE 108 instructs merchant 102 to execute a
transaction at a specified time and/or for a specified amount of
money. In one example, merchant 102 is instructed by OE 108 to
attempt a charge for $11,302.34 on Jan. 23, 2011 between the hours
of 3:00PM and 4:00PM.
[0071] At step 906, OE 108 identifies the transaction. In one
embodiment, OE 108 is configured to automatically identify the
transaction when a request for the transaction is received. In
another embodiment, OE 108 is configured to parse a set of
transactions, e.g., at the end of each day, to identify the
transaction. At step 908, OE 108 extracts a merchant ID associated
with the identified transaction. In turn, the merchant ID may be
used to register a merchant account, as described above in
conjunction with FIG. 3. In some embodiments, the OE 108 may then
decline the transaction so that no funds are actually transferred
between financial institutions.
[0072] Advantageously, embodiments of the invention provide an
improved technique for monitoring for offline transactions. A
customer accepts an offer provided by a merchant and submits his or
her account information so that he or she may receive a reward for
satisfying criteria associated with the offer. Transactions of the
merchant are then monitored to determine whether the customer
satisfies the purchase criteria. As a result, the merchant is able
to determine the overall effectiveness of advertising campaigns by
analyzing the number of offers that are both accepted and
satisfied.
[0073] While the foregoing is directed to embodiments of the
present invention, other and further embodiments of the invention
may be devised without departing from the basic scope thereof. For
example, aspects of the present invention may be implemented in
hardware or software or in a combination of hardware and software.
One embodiment of the invention may be implemented as a program
product for use with a computer system. The program(s) of the
program product define functions of the embodiments (including the
methods described herein) and can be contained on a variety of
computer-readable storage media. Illustrative computer-readable
storage media include, but are not limited to: (i) non-writable
storage media (e.g., read-only memory devices within a computer
such as CD-ROM disks readable by a CD-ROM drive, flash memory, ROM
chips or any type of solid-state non-volatile semiconductor memory)
on which information is permanently stored; and (ii) writable
storage media (e.g., floppy disks within a diskette drive or
hard-disk drive or any type of solid-state random-access
semiconductor memory) on which alterable information is stored.
Such computer-readable storage media, when carrying
computer-readable instructions that direct the functions of the
present invention, are embodiments of the present invention.
[0074] In view of the foregoing, the scope of the present invention
is determined by the claims that follow.
* * * * *