Note: Descriptions are shown in the official language in which they were submitted.
CA 02874582 2014-11-24
WO 2012/170088 PCT/US2012/027810
SYSTEM AND METHOD FOR ADMINISTERING MARKETING PROGRAMS
Field of the Invention
The present disclosure relates generally to systems and methods for providing
.. marketing partners an automated platform for managing promotions, and more
particularly
to systems and methods for establishing and maintaining loyalty incentive
programs and
other promotions that permit consumers to receive discounts- and notices of
discounts
without requiring a coupon to be redeemed,
Baelround of the Invention
Loyalty incentive or reward programs are used as a form of highly customizable
and
targeted marketing. A loyalty program provider will attract customers who sign-
up for a
loyalty program. Shopping benefits such as discounts are offered to the
customers by the
provider. The provider then markets to merchants that the provider can bring
customers to
the merchant. For example, a loyalty program provider may approach a merchant,
such as
the clothing retailer GAP Inc., with an offer to bring customers to the GAP
in exchange
for a fee. The provider would then send a solicitation (via email or regular
mail) to its
customers offering!, for example, a 10% discount coupon that may be redeemed
at the GAP
on a particular day. The success of the solicitation can be assessed based on
the number of
coupons redeemed,
in such a loyalty solicitation, the merchant would pay the loyalty program
provider a
percentage of the sales (e.g., 10%) that result from the solicitation. The
merchant benefits
from the increased sales. The loyalty program provider benefits from the
commission that it
receives, and the customers benefit from the received discount.
There are several areas that could be improved in such traditional loyalty
programs.
For example, such traditional programs suffer from leakage. Leakage occurs
when the
merchant does not fully report sales resulting from the solicitation. Leakage
results in loss
revenues thr the loyalty program provider. Further, administration marketing
programs such
as coupon redemption is costly. For example, setting up and maintaining
offers, eligibility
.. criteria, redemption criteria, reporting criteria and other functions of a
promotion system
traditionally requires business analysts of the reward program platform
provider to manually
con-figure the platform. What is needed is a marketing and promotions platform
that enables
CA 02874582 2014-11-24
WO 2012/170088 PCT/US2012/027810
intelligent, automated (e.g., via application programming interfaces)
interfaces with a
reward platform,
Summary of the Invention
In one embodiment, a computing platform includes application programming
interfaces that enable third parties to create, configure, manage, modify,
update, delete,
report on, and enhance reward offers and marketing programs. For example, a
program
provider may wish to create a custom application ("partner application") that
serves as a
front-end or interface with the computing platform. The partner application
accesses the
computing platform via various application programming interfaces (APIs).
Although in
various embodiments, steps may occur in any order, in an embodiment a
marketing program
is set up and merchants are associated with the marketing program. Offers are
created and
associated with the program and/or the merchant and customers are offered and
signed up
for the offers.
In one embodiment an automated marketing system, comprises: a network
interface
communicating with a inernory, the memory communicating with a processor for
automated
marketing and storing a computer program and a plurality of application
programming
interfaces (APIs); and the processor, when executing a computer program,
performs
operations. The operations include receiving, by the processor and via an
offer setup API, a
first offer setup request, wherein the offer setup API is from the plurality
of APIs; parsing,
by the processor, the offer set up request into a plurality of first offer
parameters; validating,
by the processor, at least one of the offer setup request and the first offer
parameters; in
response to the validating, notifYing, by the processor, a first approver of
the offer setup
request; receiving, by the processor and from the first approver, an approval
of the offer set
up request; saving, by the processor and to the memory, a first offer
comprising the first
offer parameters, wherein the first offer is associated with a first marketing
program; and
determining, by the processor, a first population comprising a plurality of
transaction
accounts that comply with first offer criteria, wherein the first offer
parameters comprise the
first offer criteria.
In an embodiment, the first offer criteria comprise at least one of a customer
identifier, a customer demographic, a customer location, spend frequency, a
spend threshold,
a spend history, an award cap, a tiered reward requirement, a product
identifier, a product
2
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
category, a stock-keeping unit (SKU), a universal product code (UPC), a QR
code, a
merchant, a merchant type, an industry, a merchant location.
In one embodiment, operations performed by the system include receiving via an
enrollment API from the plurality of APIs, a first enrollment setup-request;
validating the
first enrollment setup-request, wherein the validating comprises determining
that the first
enrollment setup request is associated with at least one of the first offer
and a second offer;
receiving an approval of the first enrollment setup-request from at least one
of the first
approver and the second approver; parsing the first enrollment setup request
into rust
enrollment parameters and saving the first offer enrollment parameters to the
memory and
receiving a first offer acceptance from a first user associated with a first
transaction account
from the first population.
In another embodiment, a method for operating a loyalty incentive program
includes
the following steps: a list of participating merchants is received; a list of
participating
account holders is received; a record of charge corresponding to a purchase by
an account
holder customer is received from a merchant, and upon receipt, an account of
the account
holder customer is debited by the amount of the charge, a merchant
identification contained
in the record of charge is compared with the list of participating merchants,
and an account
holder identification contained in the record of charge is compared with the
list of
participating account holders. if the account holder is a participating
account holder and the
merchant is a participating merchant, then it is determined whether the record
of charge
qualifies for a rebate credit. if the record of charge qualifies for a rebate
credit, then the
rebate credit is provided to an account of the account holder customer.
in another embodiment, a method includes the following steps: participation of
a
merchant in a loyalty incentive program is solicited; an offer from a
participating merchant
is received; enrollment of an account holder customer to the loyalty incentive
program is
solicited; the offer is provided to an enrolled account holder customer;
information is
received which relates to a purchase by the enrolled account holder customer
in accordance
with the offer from the participating merchant; an amount of a discount in
accordance with
the offer is calculated; and the amount of the discount is provided to a
transaction account
provider so that an account of the enrolled account holder customer is
credited in the amount
of the discount.
Tn an embodiment, a method for managing a rewards program includes monitoring
spend data associated with a transaction account. The spend data may be
analyzed and
3
compared to a set of criteria (spend levels at particular merchants, spend
level on classes of
products, spend level in a particular region). The transaction account may
then be assigned to
one or more transaction account populations based on spend data and criteria.
The spend data
associated with the transaction account is also analyzed to determine whether
a beneficiary of
the transaction account qualifies for a reward in accordance with a rewards
program. Where
the spend data complies with the rules governing the rewards program, a reward
(e.g. a credit
of monetary value to the transaction account, a merchant prepaid account, a
discount, a credit
of loyalty points) is provided to a beneficiary of the transaction account.
The spend data ,
activities associated with the transaction accounts of the population are also
monitored. Where
the activities comply with criteria associated with the transaction account
population, a rewards
offer (an offer of a credit of monetary value to the transaction account, a
merchant prepaid
account, a discount, a credit of loyalty points) is sent to owner of
transaction accounts
associated with the population.
In an embodiment, the criteria may be established by a merchant or a prepaid
account
issuer. Enrollment in a transaction account population may be automatic or may
include
registration by the owner of the transaction account. Further features of
various embodiments,
as well as the structure and operation of various embodiments are described in
detail below
with reference to the accompanying drawings.
According to another embodiment, there is provided a method comprising:
receiving, by a payment processing computer and via an offer setup API,
partner access
preferences for an external partner system, wherein the offer setup API is
from a plurality of
APIs;
authorizing, by the payment processing computer and via the Offer Setup API,
the
external partner system based on the partner access preferences in response to
information from
the external partner system conforming with predefined business rules, wherein
partner access
preferences define that the external user is authorized to initiate an offer
setup request in
accordance with a business rule associated with the external partner system;
creating, by the payment processing computer and via the offer setup API, an
offer
setup tool;
determining, by the payment processing computer, user access preferences in
response
to an input from the external partner system via a partner registration API;
granting, by the payment processing computer, access to the offer setup tool
for the
external partner system in response to the authorizing;
receiving, by the payment processing computer, an offer setup request via the
offer
setup tool;
parsing, by the payment processing computer, the offer setup request into a
plurality of
first offer parameters;
validating, by the payment processing computer, the first offer parameter
based on the
predefined business rules associated with the external user for creating an
offer;
4
CA 2874582 2019-10-02
approving, by the payment processing computer, the offer setup request in
response to
the validating;
creating, by the payment processing computer, a first offer comprising the
first offer
parameter, wherein the first offer is associated with a reward program and
wherein the first
offer comprises a reward;
registering, by the payment processing computer and in response to the
creating, a
transaction account with a rewards program system;
linking, by the payment processing computer, the transaction account to a
reward
program identifier that indicates that the transaction account is associated
with the rewards
program system, in response to the registering the transaction account with
the rewards
program system, wherein the transaction account is accessed by the reward
program that is
configured to distribute offers from an offer database to the transaction
account;
authorizing, by an authorization server of the payment processing computer, a
transaction with a merchant system in response to a consumer system initiating
the transaction
with the merchant system using the transaction account, wherein the
authorization is based on
a first amount of credit associated with the transaction account;
reducing, by the payment processing computer, an amount of available credit
for the
transaction account by a transaction amount included with the authorization;
receiving, by the payment processing computer and in response to the
authorizing,
transaction information for the transaction from the merchant system for the
transaction
between the merchant system and the consumer system;
identifying, by the payment processing computer and in response to the
authorizing,
the merchant system as an identified merchant system based on the transaction
originating with
the merchant system;
accessing, by the payment processing computer and in response to the
authorizing, a
plurality of offers associated with a plurality of merchants;
selecting, by the payment processing computer and in response to the
accessing, a
subset of the plurality of offers associated with the identified merchant
system;
analyzing, by the payment processing computer and in response to the
selecting, the
transaction amount and a transaction date to determine that the transaction
information qualifies
for a reward in accordance with the first offer of the subset of offers;
determining, by the payment processing computer and in response to the
selecting, the
reward based on the offer parameters, an attribute of the transaction account,
the transaction
information, a type of the offer, lack of spend at a particular merchant,
spend at other merchants
and a rule;
converting, by the paymmt processing computer using a configuration table, a
calculated discount of the reward between a monetary credit and reward points,
based on
service fees and percent of a purchase price;
applying, by the payment processing computer, the reward as a credit to the
transaction
in the transaction account during a settlement operation;
4a
CA 2874582 2019-10-02
. .
adjusting, by the payment processing computer, the amount of the available
credit for
the transaction account, in response to the applying the reward;
linking, by the payment processing computer, the reward with the transaction
information associated with the transaction and based on the registering the
transaction account
with the rewards program system;
generating, by the payment processing computer, a record of the reward
associated with
the transaction account used to conduct the transaction, wherein the record of
the reward is
associated with a charge associated with the transaction information
corresponding to the
transaction;
displaying, by the payment processing computer, an indicator of an amount of
the
reward on a statement in connection with the charge corresponding to the
transaction; and
processing, by the payment processing computer, a return transaction by
calculating a discount
reversal amount for an eligible return item based on a stock keeping unit
(SKU) associated with
the eligible return item, a date of a purchase of the eligible return item and
an amount of the
purchase of the eligible return item.
According to another embodiment, there is provided a tangible, non-transitory
computer-readable storage medium having computer-executable instructions
stored thereon
that, when executed by a payment processing computer, causes the payment
processing
computer to perform a method comprising:
receiving, by the payment processing computer and via an offer setup API,
partner
access preferences for an external partner system, wherein the offer setup API
is from a
plurality of APIs;
authorizing, by the payment processing computer and via the Offer Setup API,
the
external partner system based on the partner access preferences in response to
information from
the external partner system conforming with the predefined business rules,
wherein the partner
access preferences define that the external user is authorized to initiate an
offer setup request
in accordance with a first business rule associated with the external partner
system;
creating, by the payment processing computer and via the offer setup API, an
offer
setup tool;
determining, by the payment processing computer, user access preferences in
response
to an input from the external partner system via a partner registration API;
granting, by the payment processing computer, access to the offer setup tool
for the
external partner system in response to the authorizing;
receiving, by the payment processing computer, an offer setup request via the
offer set
up tool;
parsing, by the payment processing computer, the offer setup request into a
plurality of
first offer parameters;
validating, by the payment processing computer, the first offer parameter
based on the
predefined business rules associated with the external user for creating an
offer;
approving, by the payment processing computer, the offer setup request in
response to
4b
CA 2874582 2019-10-02
the validating;
creating, by the payment processing computer, a first offer comprising the
first offer
parameter, wherein the first offer is associated with a reward program and
wherein the first
offer comprises a reward;
registering, by the payment processing computer and in response to the
creating, a
transaction account with a rewards program system;
linking, by the payment processing computer, the transaction account to a
reward
program identifier that indicates that the transaction account is associated
with the rewards
program system, in response to the registering the transaction account with
the rewards
program system, wherein the transaction account is accessed by the reward
program that is
configured to distribute offers from an offer database to the transaction
account;
authorizing, by an authorization server of the payment processing computer, a
transaction with a merchant system in response to a consumer system initiating
the transaction
with the merchant system using the transaction account, wherein the
authorization is based on
a first amount of credit associated with the transaction account;
reducing, by the payment processing computer, an amount of available credit
for the
transaction account by a transaction amount included with the authorization;
receiving, by the payment processing computer and in response to the
authorizing,
transaction information for the transaction from the merchant system for the
transaction
between the merchant system and the consumer system;
identifying, by the payment processing computer and in response to the
authorizing,
the merchant system as an identified merchant system based on the transaction
originating with
the merchant system;
accessing, by the payment processing computer and in response to the
authorizing, a
plurality of offers associated with a plurality of merchants;
selecting, by the payment processing computer and in response to the
accessing, a
subset of the plurality of offers associated with the identified merchant
system;
analyzing, by the payment processing computer and in response to the
selecting, the
transaction amount and a transaction date to determine that the transaction
information qualifies
for a reward in accordance with the first offer of the subset of offers;
determining, by the payment processing computer and in response to the
selecting, the
reward based on the offer parameters, an attribute of the transaction account,
the transaction
information, a type of the offer, lack of spend at a particular merchant,
spend at other merchants
and a rule;
converting, by the payment processing computer using a configuration table, a
calculated discount of the reward between a monetary credit and reward points,
based on
service fees and percent of a purchase price;
applying, by the payment processing computer, the reward as a credit to the
transaction
in the transaction account during a settlement operation;
adjusting, by the payment processing computer, the amount of the available
credit for
4c
CA 2874582 2019-10-02
=
the transaction account, in response to the applying the reward;
linking, by the payment processing computer, the reward with the transaction
information associated with the transaction and based on the registering the
transaction account
with the rewards program system;
generating, by the payment processing computer, a record of the reward
associated with
the transaction account used to conduct the transaction, wherein the record of
the reward is
associated with a charge associated with the transaction information
corresponding to the
transaction;
displaying, by the payment processing computer, an indicator of an amount of
the
reward on a statement in connection with the charge corresponding to the
transaction; and
processing, by the payment processing computer, a return transaction by
calculating a discount
reversal amount for an eligible return item based on a stock keeping unit
(SICII) associated with
the eligible return item, a date of a purchase of the eligible return item and
an amount of the
purchase of the eligible return item..
According to another embodiment, there is provided a system comprising:
a payment processing processor;
a tangible, non-transitory memory communicating with the processor; and
the processor, when executing a computer program, is capable of performing
operation
comprising:
receiving, by the payment processing processor and via an offer setup API,
partner
access preferences for an external partner system, wherein the offer setup API
is from a
plurality of APIs;
authorizing, by the payment processing processor and via the Offer Setup API,
the
external partner system based on the partner access preferences in response to
information from
the external partner system conforming with predefined business rules, wherein
partner access
preferences define that the external user is authorized to initiate an offer
setup request in
accordance with a business rule associated with the external partner system;
creating, by the payment processing processor and via the offer setup API, an
offer
setup tool;
determining, by the payment processing pi ocessor, user access preferences in
response
to an input from the external partner system via a partner registration API;
granting, by the payment processing processor, access to the offer setup tool
for the
external partner system in response to the authorizing;
receiving, by the payment processing processor, an offer setup request via the
offer
setup tool;
parsing, by the payment processing processor, the offer setup request into a
plurality of
first offer parameters;
validating, by the payment processing processor, the first offer parameter
based on the
predefined business rules associated with the external user for creating an
offer;
approving, by the payment processing processor, the offer setup request in
response to
4d
CA 2874582 2019-10-02
the validating;
creating, by the payment processing processor, a first offer comprising the
first offer
parameter, wherein the first offer is associated with a reward program and
wherein the first
offer comprises a reward;
registering, by the payment processing processor and in response to the
creating, a
transaction account with a rewards program system;
linking, by the payment processing processor, the transaction account to a
reward
program identifier that indicates that the transaction account is associated
with the rewards
program system, in response to the registering the transaction account with
the rewards
program system, wherein the transaction account is accessed by the reward
program that is
configured to distribute offers from an offer database to the transaction
account; authorizing,
by an authorization server of the payment processing processor, a transaction
with a merchant
system in response to a consumer system initiating the transaction with the
merchant system
using the transaction account, wherein the authorization is based on a first
amount of credit
associated with the transaction account;
reducing, by the payment processing processor, an amount of available credit
for the
transaction account by a transaction amount included with the authorization;
receiving, by the payment processing processor and in response to the
authorizing,
transaction information for the transaction from the merchant system for the
transaction
between the merchant system and the consumer system;
identifying, by the payment processing processor and in response to the
authorizing,
the merchant system as an identified merchant system based on the transaction
originating with
the merchant system;
accessing, by the payment processing processor and in response to the
authorizing, a
plurality of offers associated with a plurality of merchants;
selecting, by the payment processing processor and in response to the
accessing, a
subset of the plurality of offers associated with the identified merchant
system;
analyzing, by the payment processing processor and in response to the
selecting, the
transaction amount and a transaction date to determine that the transaction
information qualifies
for a reward in accordance with the first offer of the subset of offers;
determining, by the payment processing processor and in response to the
selecting, the
reward based on the offer parameters, an attribute of the transaction account,
the transaction
information, a type of the offer, lack of spend at a particular merchant,
spend at other merchants
and a rule;
converting, by the payment processing computer using a configuration table, a
calculated discount of the reward between a monetary credit and reward points,
based on
service fees and percent of a purchase price;
applying, by the payment processing processor, the reward as a credit to the
transaction
in the transaction account during a settlement operation;
adjusting, by the payment processing processor, the amount of the available
credit for
4e
CA 2874582 2019-10-02
the transaction account, in response to the applying the reward;
linking, by the payment processing processor, the reward with the transaction
information associated with the transaction and based on the registering the
transaction account
with the rewards program system;
generating, by the payment processing processor, a record of the reward
associated with
the transaction account used to conduct the transaction, wherein the record of
the reward is
associated with a charge associated with the transaction information
corresponding to the
transaction;
displaying, by the payment processing processor, an indicator of an amount of
the
reward on a statement in connection with the charge corresponding to the
transaction; and
processing, by the payment processing computer, a return transaction by
calculating a discount
reversal amount for an eligible return item based on a stock keeping unit
(SKU) associated with
the eligible return item, a date of a purchase of the eligible return item and
an amount of the
purchase of the eligible return item.
Brief Description of the Drawings
A more complete understanding of the present disclosure may be derived by
referring
to the detailed description and claims when considered in connection with the
Figures, wherein
like reference numbers refer to similar elements throughout the Figures, and:
FIG. 1 is a high level flow diagram of a process for providing loyalty
incentives to an
account holder customer in accordance with an embodiment;
FIG. 2 is a high level flow diagram showing data management flow of account
holder
customer information and participating merchant information for transaction
matching in the
process of FIG. 1;
FIG. 3 illustrates an exemplary output file of matched transactions with
corresponding
statements of credit to an account holder customer and debit to participating
merchants.
4f
CA 2874582 2019-10-02
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
FIG. 4 is a detailed high level flow diagram of the process of FIG. I, in
accordance
with an embodiment;
FIG. 5 is a high level flow diagram showing data flow of account holder
customer
information and participating merchant information for transaction matching,
in accordance
with an embodiment;
FIG. 6 is a flow diagram of a transaction matching process, in accordance with
an
embodiment;
FIG. 7 is a flow diagram illustrating the processes associated with individual
steps
shown in FIG. 6;
FIG. 8 is a flow diagram of transaction based data flow between a third party
loyalty
program provider and a transaction account provider, in accordance with an
embodiment;
FIG. 9 is a high level flow diagram of a process of providing loyalty
incentives to an
account holder customer using a transaction card issued by a third party
transaction account
provider;
FICT, 10 is another high level flow diagram of the process of FRI. 9,
providing an
exemplary credit statement of the third party transaction account provider, in
accordance
with an embodiment;
Fla 11 is a diagram of a method for determining whether a return relates to a
purchase for which a rebate credit was provided to the account holder
customer, in
accordance with an embodiment;
FIG. 12 is a diagram of another method for determining whether a return was
made
on a purchase in which the account holder received a discount credit, in
accordance with
another embodiment;
FIG. 13 is a block diagram of an exemplary computer system used for
implementing
an embodiment; and
FIG. 14 is a block diagram of an exemplary computer system used for
implementing
an embodiment.
Detailed Description
The present disclosure is directed to a system and method for providing
loyalty
incentives to an account holder customer and operating a loyalty incentive
program. The
present system is now described in more detail herein in terms of an exemplary
embodiment.
This is for convenience only and is not intended to limit the application of
the present
5
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
disclosure, While specific configurations and arrangements are discussed, it
should be
understood that this is done for illustrative purposes only. In fact, after
reading the
following description, it will be apparent. to one skilled in the relevant
art(s) how to
implement the following exemplary embodiments. A person skilled in the
pertinent art will
recognize that other configurations and arrangements can be used without
departing from
the spirit and scope of the present disclosure, It will be apparent to a
person skilled in the
pertinent art that this disclosure can also be employed in a variety of other
applications.
The terms "user," "end user," "consumer," "customer," "participant," and/or
the
plural form of these terms are used interchangeably throughout herein to refer
to those
persons or entities capable of accessing, using, being affected by and/or
benefiting from th,..1
tool that the present disclosure provides for the rewards program described
herein. This
includes both individual consumers and corporate Customers such as, for
example, small
businesses.
Furthermore, the terms "service provider," "service establishment," "business"
or
"merchant" may he used interchangeably with each other and shall mean any
person, entity,
distributor system, software and/or hardware that is a provider, broker and/or
any other
entity in the distribution chain of goods or services. For example, a service
provider may be
a retail store, a hotel company, an airline company, a travel agency, an on-
line merchant or
the like,
A "transaction account" as used herein refers to an account associated with an
open
account or a closed account system (as described below). The transaction
account may exist
in a physical or non-physical embodiment. For example, a transaction account
may be
distributed in non-physical embodiments such as an account number, frequent-
flyer account,
telephone calling account or the like. Furthermore, a physical embodiment of a
transaction
account may be distributed as a financial instrument.
A financial transaction instrument may be traditional plastic transaction
cards,
titanium-containing, or other metal-containing, transaction cards, clear
and/or translucent
transaction cards, foldable or otherwise unconventionally-sized transaction
cards, radio-
frequency enabled transaction cards, or other types of transaction cards, such
as credit,
charge, debit, pre-paid or stored-value cards, or any other like financial
transaction
instrument. A
financial transaction instrument may also have electronic and
communications functionality. Such functionality may be enabled, for example,
by: a
network of electronic circuitry that is printed or otherwise incorporated onto
or within the
6
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
transaction instrument (and typically referred to as a "smart card"); a fob
having a
transponder and an RFID reader; and/or near field communication (NFC)
technologies. For
more information regarding NFC, refer to the following specifications all of
which are
incorporated by reference herein: IS011EC 18092 / ECMA-340, Near Field
Communication
Interlace and Protocol-1 (NFCIP-1); IS011EC 21481 I ECMA-352, Near Field
Communication Interface and Protocol-2 (NFCIP-2): and EMV 4.2 available at
Intp://www.e vco.corn/default .a sp.&
"Open cards" are financial transaction cards that are generally accepted at
different
merchants. Examples of open cards include the American Express , Visa ,
MasterCard
and Discover cards, which may be used at many different retailers and other
businesses. In
contrast, "closed cards" are financial transaction cards that may be
restricted to use in a
particular store, a particular chain of stores or a collection of affiliated
stores. One example
of a closed card is a pre-paid gift card that may only be purchased at, and
only be accepted
at, a clothing retailer, such as the clothing retailer Gap , Inc,
Stored value cards are forms of transaction instruments associated with
transaction
accounts, wherein the stored value cards provide cash equivalent value that
may be used
within an existing payment/transaction infrastructure, Stored value cards are
frequently
referred to as gift, pre-paid or cash cards, in that money is deposited in the
account
associated with the card before use of the card is allowed. For example, if a
customer
deposits ten dollars of value into the account associated with the stored
value card, the card
may only be used for payments together totaling no more than ten dollars.
With regard to use of a transaction account, users may communicate with
service
providers in person (e.g., at the box office), telephonically, or
electronically (e.g., from a
user computer via the Internet). During the interaction, the service provider
may offer goods
and/or services to the user. The service provider may also offer the user the
option of
paying for the goods and/or services using any number of available transaction
accounts.
Furthermore, the transaction accounts may be used by the service provider as a
form of
identification of the user. The service provider may have a computing unit
implemented in
the form of a computer-server, although other implementations are possible.
In general, transaction accounts may be used for transactions between the user
and
service provider through any suitable communication means, such as, for
example, a
telephone network, Intranet, the global; public Internet, a point of
interaction device (e.g., a
7
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
point of sale (POS) device, personal digital assistant (PDA), mobile
telephone, kiosk, etc.),
online communications, off-line communications, wireless communications,
and/or the like.
An "account," "account number" or "account code," as used herein, may include
any
device, code, number, letter, symbol, digital certificate, smart chip, digital
signal, analog
signal, biometric or other identifier/indicia suitably configured to allow a
consumer to
access, interact with or communicate with a financial transaction system. The
account
number may optionally be located on or associated with any financial
transaction instrument
(e.g., rewards, charge, credit, debit, prepaid, telephone, embossed, smart,
magnetic stripe,
bar code, transponder or radio frequency card).
The account number may be distributed and stored in any form of plastic,
electronic,
magnetic, radio frequency (RF), NFC, wireless, audio and/or optical device
capable of
transmitting or downloading data from itself to a second device. A customer
account
number may be, for example, a sixteen-digit et-edit card number. Each credit
card issuer has
its own numbering system, such as the fifteen-digit numbering system used by
American
Express Company of New York, NY.
A merchant account number may be, for example, any number or alpha-numeric
characters that identifies a particular merchant for purposes of card
acceptance, account
reconciliation, reporting and the like.
It should be noted that the transfer of information in accordance with various
embodiments may be done in a format recognizable by a merchant system or
account issuer.
In that regard, by way of example, the information may be transmitted from an
RFID device
to an REED reader, or from the RFID reader to the merchant system in magnetic
stripe or
multi-track magnetic stripe format.
Because of the proliferation of devices using magnetic stripe format, the
standards
for coding information in magnetic stripe format were standardized by the
International
Organization for Standardization in ISO/EEC 7811-n (characteristics for
identification cards)
which are incorporated herein by reference. The ISO/IEC 7811 standards specify
the
conditions for conformance, physical characteristics for the card (warpage and
surface
distortions) and the magnetic stripe area (location, height and surface
profile, roughness,
adhesion, wear and resistance to chemicals), the signal amplitude performance
characteristics of the magnetic stripe, the encoding specification including
technique
(MFM), angle of recording, bit density, flux transition spacing variation and
signal
amplitude, the data structure including track format, use of error correction
techniques, user
8
CA 02874582 2014-11-24
WO 2012/170088 PCT/US2012/027810
data capacity thr ID-1, ID-2 and ID-3 size cards, and decoding techniques, and
the location
of encoded tracks.
Typically, maunetie stripe intbrmation is formatted in three tracks. Certain
industry
information must be maintained on certain portions of the tracks, while other
portions of the
tracks may have open data fields. The contents of each track and the
formatting of' the
information provided to each track is controlled by the ISO/IEC 7811 standard.
For
example, the information must typically be encoded in binary. Track 1 is
usually encoded
with user information (Le., name) in alphanumeric tbrmat. Track 2 is typically
comprised of
discretionary and nondiseretionary data fields. In one example, the
nondiscretionary field
may comprise 19 characters and the discretionary field may comprise 13
characters. "[rack 3
is typically reserved for financial transactions and includes enciphered
versions of the user's
personal identification number, country code, current units amount authorized
per cycle,
subsidiary accounts, and restrictions.
As such, where information is provided in accordance with an embodiment, it
may
be provided in magnetic stripe track format. For example, the counter values,
authentication
tags and encrypted identifiers may be forwarded encoded in all or a portion of
a data stream
representing data encoded in, for example, track 2 or track 3 format.
Persons skilled in the relevant arts will understand the breadth of the terms
used
herein and that the exemplary descriptions provided are not intended to be
limiting of the
generally understood meanings attributed to the foregoing terms.
It is noted that references in the specification to "one embodiment", an
embodiment", "an example embodiment", etc,, indicate that the embodiment
described may
include a particular feature, structure, or characteristic, but every
embodiment may not
necessarily include the particular feature, structure, or characteristic.
Moreover, such
phrases are not necessarily referring to the same embodiment. Further, when a
particular
feature, structure, or characteristic is described in connection with an
embodiment, it would
be within the knowledge of one skilled in the art to effect such feature,
structure, or
characteristic in connection with other embodiments whether or not explicitly
described.
In an embodiment and with references to FIG, 1, a flow diagram illustrates
operation
of system 1300. A transaction account provider (TAP) (such as American Express
Travel
Related Services Company, Inc., of New York, NY) operates a registered card
platform
(RCP) 130 to implement a reward or incentive program (sometimes referred to
herein a
registered card program), which does not require paper coupons for fulfillment
of merchant
9
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
offers to account holders. RCP 130 provides the capability to match merchant
(SE or
"service establishment") offers and account holder (CM) customer information
with card
transactions for an account holder customer's purchases or returns at a
merchant
participating in the registered card program. As a result of such matching
capability, RCP
130 allows TAP to fulfill a merchant's discount offer applicable to account
holder
customer's purchase by providing a rebate credit in accordance with the
discount offer on
the account holder customer's transaction account statement. In one
embodiment, RCP 130
includes or is accessible by a plurality of application programming interfaces
(APIs) that
enable a merchant, marketing partner, or other entity to define custom
applications that
interface with RCP 130 in order to define offers, rewards, offer eligibility,
etc. Embodiment
of such APIs will be disclosed below, If a return is made on a purchase for
which a rebate
credit was previously provided, RCP 130 also allows the TAP to debit the
account holder
customer the amount of the rebate credit and credit the same back to the
merchant.
TAP may collaborate with a loyalty program provider to produce the reward or
incentive program. While, as used herein, "loyalty program provider" (LPP)
refers to an
external, third-party provider of marketing packages that may be provided to
CIVIs in
accordance with various embodiments. TAP may internally administer loyalty
programs,
such as restaurant or travel marketing program. Therefore, to distinguish from
programs
provided by an LPP, TAPs internal loyalty programs will be referred to herein
as a "TAP
marketing program" or simply a "TAP program." In the figures, the service mark
"TailorMade" is used to refer to an example loyalty program offered by an LPP.
Accordingly, although embodiments will he described herein in the environment
of such
collaboration between a TAP and an LPP, one of skill in the pertinent art(s)
will recognize
that a registered card program can be implemented with or without a loyalty
program
provider or other types of providers without departing from the spirit and
scope of the
present disclosure.
As shown in FIG. 1, in step I, a merchant 102 enrolls and submits a discount
offer to
a loyalty program or other marketing program. These offers are compiled in an
offer
database 132. In step 2, an account holder customer (CM) 104 registers their
transaction
account managed by TAP, such that CM's account is "registered" to the
registered card
program, thereby permitting the registered CM to receive coupon-less discounts
in the form
of rebate credits (via CM's account statement). Information relating to CM's
now registered
card is compiled in enrollee database 134. When CM shops and makes purchases
(or
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
returns) at a merchant using their financial transaction card, TAP will
receive a record of
charge (ROC) for the transaction, which may be stored in a card transaction
database 136.
The ROC may be any information that can be used to identify a card
transaction. in step 3,
matching is performed by RCP 130. In the case of a CM purchase, the CM's
statement is
credited and the merchant's account is debited in accordance with the
merchant's offer, as
illustrated in step 140. Further description of providing a credit to the CM
and a debit to the
merchant in step 140 is described below with reference to FIG. 3,
FIG. 2 provides another high level flow diagram illustrating the steps of
solicitation
110 and enrollment 120 relative to transaction matching 130 (performed by the
registered
card platform), in accordance with an embodiment. Solicitation 110 of a CM may
include a
targeted invitation, such as by e-mail, from loyalty program provider(s) or
TAP, or by
simply making available to a CM a link on TAP's website prompting the CM to
enroll in
TAP's registered card program. During enrollment 120, the CM opts to register
their card
information to enable RCP 130 to perform future matching of transactions. Box
122 sets
forth exemplary fields of information stored by TAP for each enrolled CM. CM
information
is stored in database 134 (represented bore as an arrow 134), and the
information is provided
to a matching transaction processor 138 of RCP 130. Matching processor 138 is
shown and
described in the example embodiments presented using the term "registered card
engine"
(RCE). As shown, in FIG . 2, RCE 138 is provided with merchant transaction
information
from participating merchants (i.e., a daily, "business as usual" (BAU)
transaction file), This
transaction information may be stored in transaction database 136 (shown here
as an arrow
136). RCE 138 also receives participating merchant offers 132 (shown in FIG.
1) and
matches them with transactions 136 made by registered ClvIs (i.e,, via
information from
enrollee database 134). Matched transactions are provided in an output file
142.
FIG. 3 illustrates an exemplary output file and credit and debit statement for
the CM
and the merchant, in accordance with step 140 of MG. 1. Output file 142 from
RCE 138 (as
shown in FIG. 2) includes an itemization of a discount amount (i.e., incentive
payment) to
CM for a purchase made (i.e., ROC) at a participating merchant in which a
discount offer
was applicable. In this embodiment, upon enrollment in the registered card
program, the
registered accounts of the CM receive a registration identification (i.e.,
"registered
number"), which is also included in. output file 142. In this embodiment,
output file 142
includes marketing programs administered by TAP and marketing programs
administered by
a loyalty program provider. One of skill in the pertinent art(s) will
recognize that output file
11
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
142 may be configured in any number of ways and include less or more
information
represented in FIG. 3. For example, a separate output file may be provided for
each LPP or
TAP program, and for each loyalty program offered by the same LPP. Further,
the
transaction and discount information reflected therein may be provided
collectively or
separately for downstream processing of a CM credit statement 144 and a
merchant debit
statement 146.
As shown in FIG. 3, output file 142 is processed by TAP to provide line item
rebate
credits on CM statement 144 for each purchase subject to a discount offer
available pursuant
to a marketing program. For example, CM statement 144 includes a TailorMade
rebate
credit of $71, for an original charge amount of $355 at participating
merchant, Acme
Clothing, Similarly, a credit of $37 under IAP's restaurant marketing program
is provided
for an original charge amount of $370 at participating merchant, Acme Food.
Merchant
debit statement 146 includes line item debits in accordance with CM's rebate
credits also as
line items for each marketing program, 'File debit for the merchant may be
equal or unequal
to the rebate credit to CM, For example, for Acme Clothing, the merchant debit
of $71 is
equal to CM credit of $71, whereas the debit for Acme Food is $74,
corresponding to the
sum of the rebate credit to CM and a commission or service fee of 10% of the
original
charge amount imposed by TAP for performing the services described heroin.
Although not
shown here, a similar commission may be imposed by LPP and/or TAP on Acme
Clothing's
account and incorporated as part of a line item debit on its statement.
Alternatively, such
commission may be a separate line item from the line item for the merchant's
debit for
CM's rebate credit.
FIG, 4 is a detailed high level block diagram of the process of FIG. 1,
showing
processes for registration of a CM, calculation of a rebate credit to the CM
(or a negative
discount amount in ease of a return), and downstream settlement with the CM
and the
merchant relating to the rebate credit (or negative discount amount), in
accordance with an
embodiment, The CM registers with TAP to receive coupon-less discounts for
purchases
drawn on their transaction card/account. Generally, the registration process
begins with
solicitation 110 of the CM, followed by enrollment 120 of one or more
transaction cards
held by the CM. Description of exemplary embodiments of process for
solicitation 110 and
enrollment 120 will be provided further below. In order to enroll, each
transaction card and
corresponding customer information undergoes a validation process 410 to
determine
whether the CM's card is eligible for participation in TAP's registered card
program. This
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
registered card program may be made available to not only CMs holding
transaction cards
issued by TAP, but also to CMs holding cards issued by third party transaction
account
providers in a brand network. Third party transaction account providers are
referred to
herein collectively as Global Network Services (GNS). For example, "American
Express"
branded cards are available from both American Express Travel Related Services
Company,
inc (referred to herein as proprietary cards, or "Prop cards") as well as from
other issuers
(referred to herein as "GNS cards"), such as Citibank, N.A. of New York, NY,
Accordingly, validation process 410 may include validation of proprietary
cards and GNS
cards, For proprietary cards, customer information is validated by 'fAP's card
authorization
system (CAS) 412, and for GNS cards, CM information is validated by GNS's card
authorization system 414,
The CM may be provided the option to enroll more than one card and link each
second and additional card to a primary enrolled card, which is illustrated in
FIG. 4 as
linking 416. Linking 416 provides the capability to assign a single
registration identification
to the CM and provides the CM the flexibility to make a purchase on any of the
linked cards,
with discount payments appearing on the CM's statement for the primary card.
The linked
cards may be all Prop cards, all GNS cards, or a mixture of Prop and GNS
cards. Further,
the linked cards assigned to a single registration identification may be
corporate cards,
personal cards, or a mixture thereof. The registration process may also
include the
capability of batch enrollment 420 of a plurality of cards of one or more CMs
in a single
instance. Information relating to enrolled CMs are stored in enrollee database
134.
Information relating to linking 416 of a plurality of cards to the CM is also
contained
therein. Information from the enrollee database 134 may than be provided to
RCE 138, as
described above with reference to FIG. 2.
In the embodiment illustrated in PIG, 4, information on participating
merchants and
their offers are divided into separate databases, i.e., an offer database 452
and a merchant
database 454, and provided to RCF 138. As described above, TAP may collaborate
with a
loyalty program provider (LPP) 460 to deliver loyalty incentives to the CM in
the form of
coupon-less discounts. Accordingly, offer database 452 and merchant database
454 may be
populated by TAP and/or L.PP, with offers and merchants associated with TAP's
marketing
programs and LPP's marketing programs, respectively. TAP may screen merchants
participating in LPP's marketing programs prior to accepting and storing them
in merchant
database 454. TAP's program administrator (not shown) may upload merchants and
offers
13
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
to the respective databases along with other information associating merchants
and offers
with one or more marketing programs. In one embodiment, as discussed below,
TA1"s
program administrator may specify offers and programs, reward criteria,
eligibility criteria,
reporting options, tracking options, triggered alerts, etc. via AP1's of RCP
130,
For marketing programs administered by TAP, registered card engine ("RCE") 138
may include its own calculation of discount 432 for purchases made by
registered CMs with
merchants participating in TAP's marketing program, Further. LPP 460 may be
responsible
for calculation of discount 462 for purchases made at merchants participating
in marketing
programs administered by LPP 460. A merchant may be a participating merchant
for a
plurality of externally administered and/or internally administered marketing
programs.
Therefore, these offer and merchant databases may include a Held identifying
each offer and
merchant to one or more marketing programs, as further described below with
reference to
FIG. 5,
Another input to R.CE 138 are merchant ROCs 436, which may be compiled as a
daily transaction file and stored in transaction database 136 (shown in FIGs.
1 and 2), RCE,
138 performs transaction matching of merchant ROCs 436 with enrolled CM
information
from enrollee database 134 and participating merchant and offer information
from respective
databases 454 and 452. Further detail regarding this matching will be
described below with
reference to FIGs. 5 through 7. Matched transactions relating to loyalty
programs
administered by loyalty program provider 460 are provided as an output file
444 to LPP 460
for discount calculation 462, whereby LPP 460 returns an output tile
(represented here as
arrow 442), which includes the discount amount, or rebate credit, similar to
the incentive
payment field in output file 142 described above with reference to FIG. 3,
This process of
discount calculation by LPP 460 and exchange of information thereof with RCE
138 is
discussed below with reference to FIG. 8.
A problem to be overcome in implementing a loyalty incentive program as
described
herein is how to deal with returns. For example, assume an account holder
makes a
purchase for $100 and receives a 10% discount (also called a rebate or
incentive) on his or
her account. If the account holder then returns the purchased goods to the
merchant, it is
desirable to be able to ascertain whether the purchase involved an incentive
so that a return
credit can be made in the appropriate amount. This problem is solved by
providing a
mechanism for dealing with returns. In the embodiment of FIG, 4, RCE 138 has
the
capability to process returns 456 on purchases for which a registered CM may
have been
14
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
provided a rebate credit pursuant to a marketing program. if a rebate credit
had been
previously provided, then processing of returns 456 includes providing a
credit to the
merchant for the earlier debited amount of the rebate credit provided to the
CM and
providing a corresponding debit to the CM of the earlier rebate credit.
Processing of returns
is similar to the transaction processing of purchases and is described in
greater detail below
with reference to Wis. 6 and 7, Accordingly, output file 444 from RCP. 438 may
include
return transactions, whereby loyalty program provider 460 calculates a
negative discount, or
a discount reversal amount, 464 for each eligible return. Eligible returns may
be identified
based on a stock keeping unit (SKL1) associated with the purchase or based on
the date of the
purchase and the amount of the purchase (i.e., "backtrack discounts"). Logic
associated with
matching prior purchases with returns by means other than SKlis is described
in further
detail with reference to F1Gs. 11 and 12.
RCE 138 has the capability to convert the discount amount to an equivalent of
membership reward points which may be redeemable in accordance with membership
rewards program, Typically, a membership rewards program offers goods or
travel
packages in exchange for membership reward points. Moreover, the discount
amount may
be a combination of a monetary credit and an equivalent of reward points. To
implement
such conversions, as well as to support service fee calculation, etc. RCE 138
may include a
configuration table 434. Configuration table 434 may include fields for each
marketing
program and corresponding information for converting the calculated discount
(i.e., the
rebate credit) between a monetary credit and/or an equivalence in membership
rewards
points (shown as "CM (%, $, Pts)"). Further, since a discount offer may be
represented in
units of monetary amount off or percent off a purchase price, or in terms of
membership
rewards points, then for internally calculated discounts 432, RCE uses
configuration table
434 to match program, merchant, and conversion terms (shown as "SE (%, $)) to
convert
the offer terms to the desired units for discount calculation. Configuration
table 434 may
also have a field for TAP's 'service fees for each program and participating
merchants, and
service fees may be in units such percent of purchase or monetary amount
(shown as "TAP
$)"). Further, since a merchant may be submitting the same offer for more than
one
marketing program., configuration table includes a "priority" field that is
used to identify
repeated offers and ensure that the CM receives only a single rebate credit on
a purchase that
is eligible to receive a discount pursuant to multiple marketing programs.
CA 02874582 2014-11-24
WO 2012/170088 PCT/US2012/027810
The calculated discount (or discount reversal, if relating to a return) is
provided to
TAP settlement systems 470 for transactions on Prop registered cards, or to GM
settlement
systems 480 for transactions on GNS registered cards. An AR system of TAP
settlement
systems 470 processes the discount amount and provides the rebate credit (as a
monetary
credit or an equivalence in reward points, or both) on CM's credit statement.
If the rebate
credit includes membership reward points, then information relating the rebate
credit is also
provided to membership rewards 472 for appropriate record keeping for that CM.
AP
systems of TAP settlement systems 470 processes the merchant debit in
accordance with
CM's rebate credit, as well as any service fee charged by TAP for providing
the services
described herein. Further detail regarding processing of matched transactions
via TAP
settlement systems is described below with reference to FIG, 8. GNS settlement
systems
480 includes U.S. submissions 482, global clearing and settlement 484, and one
or more
issuers 486. Global clearing and settlement 484 may be considered a repository
for RCE
138s matched transactions associated with GM cards so as to permit each G-NS
issuer 486
to retrieve their respective ONS card transaction information, including
information of the
discount and any service fees charged by TAP, GNS issuers 486 may then use
this
information to provide a rebate credit to CMs accounts managed by issuers 486
and to
provide a debit to participating merchants in a similar manner as described
above with
reference to FIG, 2, Further details regarding application of the registered
card program to
CMS registered cards is described below with reference to FIGs. 9 and 10,
RCE 138 may further have the capability to provide TAP with reporting 490,
which
may include a marketing analysis or monitoring of the success of various
marketing
programs and information relating to account holder participation therein.
Reporting 490
thereby permits 'TAP to target CMs and deliver merchant offers that are
desirable to its
registered CMs and/or merchants.
Offer DB 452 may comprise a plurality of offers. in an embodiment, the offers
may
be predetermined offers and/or offers based on merchant criteria, The offers
may be
configured to be delivered electronically through reporting 490. The
electronic delivery
may include delivery via email, text messaging, instant messaging and/or
social networking
distribution (e.g., via Facebook, Twitter, Myspace, Linked-in). The electronic
delivery may
be automatic or require a manual input. The offers may be accessible by RCE
138. These
offers may be based upon specific parameters which define at least one of a
reward, a
merchant and/or class of merchants, characteristics of a targeted CM, a
predetermined
16
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
qualification threshold, and the like. RCE 138 may analyze the parameters to
identify
intended recipients of the offers. RCE 138 may also analyze the parameters to
determine
characteristics for a CM population. This capability allows the merchant to
quickly and
inexpensively target the CM with customized marketing and/or offers. This
capability also
allows the merchant to provide an offer to targeted CMs before a target list
is pulled.
in an embodiment, reporting 490 may be configured to deliver of to CMs
with
particular behaviors and/or patterns (e.g., spending behaviors, reward usage
behaviors, etc).
RCE 138 may be configured to define a particular CM population based on
merchant
targeted marketing efforts. CM spending patterns, CM demographic data and/or
the like.
For example, RCE 138 may identify a CM population that spends a predetermined
amount
of money on electronics in a predetermined period of time. Further, RCE 138
may identify
a merchant who offers electronics for purchase, but does not capture
significant spending
from the identified CM population. In other words, the CMs who spend a
predetermined
amount on electronics are not spending significant amounts on electronics with
the
identified merchant. RCE 138 may analyze the CM spending to compare the total
amount
of spending on a particular class of items (e.g., electronics). RCE 138 may
also analyze
such CM spending based on merchants that receive the CM spend, to determine
the
proportions of spending at a particular merchant, class of merchants, and/or
the like. Such
information may be compared to a predetermined threshold spending amount or
proportions
of spending at particular merchants and/or classes of merchants. The
comparison allows, for
example, a merchant to target CMs that do not typically spend significant
amounts with a
particular merchant or class of merchant, but the CMs buy the types of
products and/or
services offered by the merchant or class of merchants.
CM populations may be initially created based on, for example, historical
data. The
historical data accessible to a financial processor, such as spend level data,
is leveraged
using various data clustering and/or data appending techniques. The CM
populations may
also be created based on, for example, current spending patterns. The current
spend patterns
available to a financial processor (e.g., current authorized transactions,
posted transactions,
and the like) may be leveraged using various data clustering and/or data
appending
techniques. Associations may be established among entities (e.g. CMs), among
merchants,
and between entities and merchants. in an embodiment, RCE 138 may receive
passively
collected spend level data for a transaction of a plurality of CMs, aggregate
the collected
17
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
spend level data for a plurality of CMs, and cluster the CMs into subsets of
the plurality of
CMs, based on the aggregated spend level data.
The collection of the spend level data may be passive. For instance, passively
collecting spend level data of a CM includes acquiring the spend level data in
response to a
transaction by a CM. with a merchant, In an embodiment, the spend level data.
may be
integral to information processed in a transaction for goods and/or services
with a merchant.
For instance, a survey and/or survey responses are not needed to capture spend
level data,
but such data may be used to supplement the data discussed herein. Collecting
the spend
level data may include acquiring the spend level data from a merchant. in an
embodiment,
passively collecting the spend level data of a CM includes collecting the
spend level data
from a transaction database. in yet another embodiment, passively collecting
the spend level
data includes reconciling the spend level data, transferring the spend level
data to a host,
organizing spend level data. into a format, saving the spend level data to a
memory,
gathering the spend level data from the memory, and/or saving the spend level
data to a
database. For instance, if a CM performs a transaction (such as by using a
transaction
account), spend level data (such as transaction data and/or consumer account
data) related to
the transaction may be captured and stored in a memory, database, and/or
multiple
databases. Spend level data (such as transaction data and/or consumer account
data) may be
stored locally with the merchant, remotely by the merchant and/or transmitted
to a remote
host (e.g., financial processor) for storing and processing.
In one embodiment, aggregating the collected spend level data includes
combining a
selectable range of collected spend level data. The selectable range may be a
period of time
(e.g., time range) and/or from a particular geographic region. The period may
be any
suitable period and/or periods such as a minute, an hour, a period of hours,
one day, one
week, one month, a period of days, a period of months, one year, or more than
one year.
The periods may be consecutive or non-consecutive. in an embodiment, the
selectable range
may be a value, such as values of spend exceeding a pre-selected threshold.
The selectable
range may also include frequency, such as spend level data occurring at a
particular
frequency.
in an embodiment, the 'spend level data may he segmented by a gender of the
entity
(e.g., male or female), such that only data collected from merchants in
transactions with men
are processed by RCE 138. This data may be aggregated, clustered, assigned a
weighed
percentile and analyzed in accordance with the previous descriptions. Using
this exemplary
18
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
embodiment of the system, preferences, attributes, and inferences of a
selected demographic
may be obtained, in one embodiment, spend level data segmented geographically
(e.g., zip
code) or by other regions can reveal which regions are most compelling to a
merchant and/or
marketer.
Any demographic included within the characteristic data may be selected for
pre-
segmenting the spend level data. In an embodiment, the spend level data may be
segmented
by an attribute (e.g., homeowner designation), and data collected from
merchants in
transactions with entities that are homeowners may be processed by RCE 138.
This data
may be aggregated, clustered, assigned a weighed percentile and analyzed in
accordance
with the previous descriptions. From this procedure, a holistic picture of
homeowners
segmented into different clusters may be created. More than one demographic or
attribute
may be selected and the spend level data may he pre-segmented any suitable
number of
times in any suitable order. Additionally, in one embodiment, a particular
demographic may
be selected to be removed from the larger set of all available spend level
data. For instance,
the spend level data of very high income entities may be selected for removal
and data
collected from merchants in transactions with very high income entities may he
excluded
from processing by RCE 138, The remaining data may be aggregated, clustered,
assigned a
weighed percentile and analyzed in accordance with the previous descriptions.
Using this
embodiment, outliers may be removed from the results. Additional details
regarding
combining elVis into populations are disclosed in, for example, U.S.
Application Serial No.
12/690,669, entitled "System And Method For Clustering a Population Using
Spend level
Data" and filed on January 20, 2010, which is hereby incorporated by reference
in its
entirety,
The CM populations may he established based on historical data or on current
spending patterns, as discussed above, and in one embodiment are modified
based on current
spending habits. For example, spend level data may be actively captured and
used to modify
CM populations. As CM spending habits change, the groups are modified to
provide greater
accuracy for delivering rewards, merchant offers and the like. For example, a
CM may be
placed in a population of CMs whose spend level data suggests that they attend
public
entertainment events (e.g. movies, concerts, and the like). As time passes,
the system may
analyze a shift in the spend level data which suggests that the CM (possibly
due to a having
a new baby) attends less public entertainment events and spends more for home
entertainment items, such as for example, home electronics equipment. In
response to the
19
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
shift in spend level data, RCE 138 may associate the CM with a new CM
population which
receives rewards offers for electronics. Further, RCE 138 may also remove a CM
from a
particular CM population based on current spend level data, wherein the CM was
originally
placed in a CM population based on historical spend level data, but no longer
exhibits
spending behavior consistent with the historical spend level data.
in one embodiment, in response to the determination that the CM population is
spending on electronics, but not with a particular identified merchant,
reporting 490 may
send the CM population a reward offer from the identified merchant, The
rewards offer may
be designed to encourage the CM population to buy electronics from the
identified
merchant, with whom the CM population had not previously conducted significant
business.
The terms of a rewards offer may define a trigger event, such as a threshold
spending
amount at a particular merchant or class of merchants, or for a class of
items. The reward
offer may be provided electronically to the CM population based on a trigger
event (e.g., in
real time), A trigger event may be any action identified by the merchant or
the account
issuer. The trigger event may be based on spend data, geographic region spend,
CM
population size, time of year, or any other event. The event may be identified
by the
merchant, CM and/or account issuer. For example, the trigger event may be
based on spend
data, in response to a CM population reaching a predetermined spend level on a
class of
products (e.g. electronics), the rewards offer may be sent to the CM
population via e-mail.
Similarly, the trigger event may be based on a CM population size. In response
to the CM
population reaching a predetermined level, a rewards offer is sent to the CM
population. in
another example, the merchant and a product supplier or manufacturer may
create a joint
offer, which provides a reward offer if a CM buys a particular item (e.g. a
particular model
laptop computer) or class of items (e.g. any Sony television).
in an embodiment, a merchant may wish to market rewards offers to CM
populations
based on (.7.1Vis spending at other merchants. For example, a merchant that
sells home
improvement items (e.g. Home Depot) may wish to market its products and
services to a
CM population that spends a predetermined amount on electronics. The merchant
may
formulate a set of criteria to develop a CM population based on spend data for
electronics
purchases (e.g. televisions) and/or spend data at particular electronics
merchants (e.g. Best
Buy). Thereafter, rewards offers from the merchant are provided to the CM
population in
response to a trigger event.
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
In an embodiment, the identified merchant offer is provided in conjunction
with an
existing rewards program. For example, the CM may be eligible for a reward
based on the
CM's pre-existing participation in a rewards program. The reward offer is
provided in
addition to the existing reward. For example, a CM is provided with a credit
based on a
particular transaction at a particular merchant. The transaction may also
result in the CM
becoming a member of a particular CM. population that is provided with a
rewards offer (e.g.
an additional discount with the identified merchant based on the loyal
spending behavior).
As such, the CM receives the pre-existing reward and the reward offer based on
the CM
becoming a member of a CM population.
in an embodiment, a CM is automatically enrolled in a program to receive e-
mail
rewards based on criteria determined by a merchant or account issuer. In an
embodiment, a
CM may be invited to join a CM population that is eligible to receive rewards
offers. The
CM may receive a notification which indicates that the CM is eligible to
receive rewards
offers. The notification may provide tbr an opt-out period during which the CM
can request
that the CM is not sent the rewards oilers based on the CM's inclusion in a CM
population.
The notification may also provide that the CM register to receive the rewards
offers by
taking some affirmative action, such as for example, registering the CM's
account via a
webpage and/or contacting the account issuer and requesting to be included in
the CM
population associated with the rewards offers,
RCE 138 may be configured to administer rewards associated with a prepaid
transaction account. Such configuration may occur directly or via API's that
are included in
RCP 130. The prepaid transaction account may comprise embedded rewards,
including for
example, credits to the prepaid transaction account, merchant specific rewards
(e.g.
merchant gift cards), discounts, and the like. The rewards may be customized
by a
merchant. The rewards may be offered in conjunction the pre-paid transaction
cards (e,g,
American Express Gift Cards, Home Depot Gift Card), Offers may be customized
by an
individual merchant or a group of merchants, This ability to customize offers
allows local
and regional merchants to offer rewards to customers that were previously
unavailable
because of the cost and complexity of administering a rewards program.
Further, providing
rewards with a prepaid transaction account allows those who are not credit
card users to
participate in rewards programs traditionally reserved for credit card account
holders.
In an embodiment, a prepaid transaction account has an embedded reward which
is
configured by an offering merchant. For example, a merchant may configure a
reward
21
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
which provides a credit on purchases of certain products and/or services (e.g.
dry cleaning
services) at the merchant or within a group of cooperating merchants, The
reward may also
be based on transactions conducted in a geographic or other region. in one
embodiment, the
reward may be limited or restricted for use in a similar or other geographic
region. The
rewards may he offered through a prepaid account, such as a prepaid
transaction card,
available for purchase through the offering merchant. The prepaid transaction
account may
be used with any merchant who accepts transaction accounts from the account
issuer
associated with the prepaid transaction card. Further, the prepaid transaction
account may
be configured with pre-determined reward criteria from the offering merchant.
For example,
when seventy percent of the total value of the prepaid card is spent with the
offering
merchant, a reward is issued. The reward may be issued in the form of a credit
to the
prepaid transaction account, or may be provided in some other fashion
another gift card
from the offering merchant).
In an embodiment, participation in the rewards program associated with the
prepaid
transaction account may be automatic or may require registration. Registration
may be
provided by accessing a webpage and providing identifying information.
Registration may
also be achieved by contacting an account issuer and requesting that a
particular prepaid
transaction account be associated with a rewards program.
In an embodiment, any prepaid transaction account associated with an account
issuer
may participate in any rewards program offered by the account issuer. The
transaction
account may be registered with the account issuer for a particular rewards
program selected
by a prepaid transaction account owner. Where the activities associated with
the transaction
account conform to the rules governing the rewards program, a reward is
provided to the
prepaid transaction account owner.
Cancellations 440 of registered accounts by enrolled CMs are communicated to
loyalty program provider 460 as well as to enrollment 120 so as to maintain
enrollee
database 134 with up-to-date enrolled CM information. Cancellations 440 may
arise, for
example, from a CM reporting a lost or stolen card or a CM requesting TAP to
deregister
one or more of its registered cards from the registered card program. In an
embodiment,
enrollee database 134 may be provided with timely and consistent updates to
reflect lost and
stolen cards. Cancellations 440 may also include deregistration of a CM from
one or more
particular marketing programs administered by TAP or LPP 460.
22
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
Further description will now be provided with respect to solicitation ii 0 and
enrollment 120, As noted above with reference to FIG, 2, CM may be solicited
to join an
incentive program offered by TAP via an email invitation from LPP 460, in this
instance, a
CM may receive a solicitation email providing a link to a loyalty program's
website landing
page, whereby the CM may begin an enrollment process. The enrollment may
include, for
example, the steps of agreeing to the incentive program's terms and
conditions, setting up a
username and password and selecting marketing preferences, etc. Moreover, such
an
incentive program website may be hosted by LPP 460 and branded by TAP. As
such, the
enrollment process may further include providing TAP with the CM's email
address, such as
when the account holder clicks on the link of the solicitation email to start
the enrollment
process. TAP may use CM's email address to validate the CM prior to enrollment
120 via
validation process 410, Further, the incentive program's website may provide
registered
CMs with a customized home page where they may be presented with personalized
offers
(such as those identified based on their selected marketing preferences), as
well as being
able to engage in online shopping of goods and services offered by merchants
participating
in the particular marketing program(s) in which the account holder enrolls. If
a CM receives
an email solicitation but is already enrolled in TAF's registered card
program, then by
clicking on the link provided in the solicitation email, the already enrolled
CM may be
prompted to log in to their customized homepage. As noted above, a CM may be
solicited
indirectly simply by being provided with access to a website link to the
enrollment v,iebpage
and/or TAP's enrollment webpage for the registered card program. Further,
enrollment in
TAP's registered card program via a TAP-hosted website link may allow for
enrollment in
TAT's marketing programs as well as a marketing program offered in
collaboration with one
or more loyalty program providers.
Solicitation 110 may further include a pm-solicitation process prior to
sending a
solicitation email to a targeted CM, The pre-solicitation process may involve
determining
which CMs should be targeted and which offer clusters and particular marketing
programs
the CM may be eligible to participate in pursuant to the registered card
program.
Accordingly. TAP may collaborate with LPP 460 to identify appropriate CMs for
email
solicitation based on TAPcs data on a CM's spending preferences and the LaPP's
clusters of
merchant offers. These identified, targeted CMs may then reviewed so as to
exclude
solicitation of any targeted CMs having opted out of receiving direct
marketing materials
from TAP or LPP 460. TAP then provides LPP 460 with a marketing list of
targeted CMs
23
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
and associated identifying information (such as salutation, name, gender, and
zip code). The
marketing list may further he provided to LPP 460 with a given effective
period during
which solicitation mails may be sent, since the list should be updated
periodically to
exclude CMs from the list that have since opted out of receiving marketing
materials. Upon
receipt of the marketing list from TAP, loyalty program provider sends out
email invitations
to the targeted CMs.
Enrollment 120 may provide an option to the CM to participate in the
registered card
program as a preferred enrollee. For example, during enrollment an account
holder may
choose to be eligible for "premium" offers in exchange for paying an
enrollment fee.
Alternatively, the CM may wish to forego payment of any enrollment fee and he
eligible for
"evelyday" offers, Preferred (i,e, premium) customers may also be eligible for
everyday
offers. TAI"s registered card program may therefore offer tiers of offer
packages
corresponding to the "premium" and "everyday" tiers of enrolled account
holders,
Accordingly, RCE 138, during transaction matching, may consider whether an
enrolled CM
is registered as a premium account holder or an everyday account holder so as
to identify
CM purchases that qualify for a premium offer and/or an everyday offer.
An embodiment, the TAP collaborates with loyalty program provider 460 will now
be described in greater detail with reference to FIGs. 5 through 8. FIG. 5
illustrates
transaction-based data flow between databases at TAP during transaction
matching by RCE
138. As shown, CM enrollee database 134 may include such data as a CM's
registration
identification (RCnumber ID) for one or more registered transaction cards
linked together in
accordance with linking step 416, described above; a list of account nurribers
for these
linked cards; indication of whether the CM is a premium account holder; and
whether the
CM and/or their registered transaction card(s) are active or canceled pursuant
to
cancellations 440 (shown in FIG. 4). A second enrollee database (i.e.,
database identified as
"LPPnumber 2") and other additional enrollee databases may be provided for
enrollees of
each distinct loyalty program or program provider. Alternatively, a single
enrollee database
134 may be provided for all enrollees of the registered card program, with
another data field
provided which identifies the one or more loyalty program providers the CM is
associated
with. Likewise, separate merchant database may be provided for each loyalty
program or
program provider, or a single database may be provided with a data field
identifying the
merchant with the program(s) or provider(s). Merchant database 454 may include
a
24
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
merchant ID, its SE number, as well as whether the merchant is actively or
inactively
enrolled in the registered card program.
Merchant offer database 452 may include an offer ID, a corresponding merchant
ID,
a start and end date for the particular offer, a description, and whether the
offer is a premium
offer, as described above. Since TAP and, LPP may each administer marketing
programs,
and since there may be multiple loyalty program providers, merchant offer
database 452
may also include a field identifying each TAP or LPP marketing program to
which the offer
belongs. PICi. 5 also shows exemplary data contained in output file 444
provided to the
loyalty program provider(s) for discount calculation (or discount reversal
calculation, in the
case of return), as described above with reference to FIG. 4. in this figure,
"Tx" represents
the term "transaction." As shown, output file 444 includes: transaction ID,
transaction date,
merchant ID and offer ID, account holder's registration identification
(RCnumber),
transaction amount, as well as Whether the transaction type is a credit
(return) or a debit
(purchase).
In this embodiment, output file 444 includes CNN Renumber as a substitute thr
the
CM's actual transaction account number. Output file 444 is provided to LPP for
discount
calculation, and the level of security associated with Li-'Ps network may
prohibit allowing
LPP using the actual account number as a means to identify the transaction for
discount
calculation. However, it should be understood that for internally calculated
discounts 432
(described in FIG. 4) or in instance where secure networks exists with the
loyalty program
provider(s), then output file may contain the particular transaction account
number
associated with the transaction. As such, the discount calculated by LPP may
be directly
matched with the card number and may also be provided on the statement for a
secondary
card, rather than appearing on the statement of the primary card, which may
occur when
several linked cards are associated with CM's registration identification
(Renumber).
PIOs. 6 and 7 show in greater detail the process of transaction matching by
RCE 138
when a registered CM shops at a participating merchant. FIG. 8 shows in detail
an
embodiment of a process for calculation (via LPP) of CM discount credits and
discount
reversal debits and their subsequent processing so as to appear on CM and
merchant
statements. The processes of FiGs. 6 through 8 are shown to incorporate both
CM
purchases and their returns. Accordingly, the output file provided to LPP and
an input .file
from LPP to TAP (as shown and later described in step 814 in FIG. 8), as well
as creation of
a file of merchant credit-debit and account holder credit/debit (as shown in
step 822 of FIG,
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
8), are described to include information relating to both purchases and
returns. It should be
understood, however, that individual files at the noted steps may be provided,
one for
processing of discounts for purchases and another for processing discount
reversals for
returns. Further description of methodologies for identifying whether a return
is on a
purchase for which a CM received a discount will be described with reference
to Wis. 11
and 12.
FIG. 6 shows steps in a process from the point when the account holder makes a
purchase or return at a particular participating merchant to when an output
tile is provided to
an LPP for discount calculation (or discount reversal calculations). In step
610, TAP
receives daily ROCs from merchants via its financial capture system (FinCap).
In step 620,
TAP creates a consolidated daily ROC file of all merchants associated with
TAP. As part of
the consolidation, TAP may monitor ROC submissions for return ROCs, i.e., ROCs
having a
negative amount for the transaction amount, and/or for which the transaction
type is
identified as a credit, whereby the transaction may be subject to additional
processing to
determine whether a negative discount (i.e,, discount reversal) is due prior
to including the
transaction on the output file provided to the LPP for discount reversal
calculation. in step
640, TAP receives the list of participating merchants and offers from LPP.
Participating
merchants and offers are stored in merchant database 454 and merchant offer
database 452,
respectively. At step 650, merchants are matched to offers, and at step 660,
ROCs are
extracted for only those participating merchants that have unexpired offers.
Also extracted
are credit ROCs (i.e., ROCs for returns),
Once TAP identifies credit ROCs from participating merchants, TAP may compare
them to transaction debits stored in transaction database 136 (see FI(i. 8)
over a given time
period (e.g., the last 60 days, or the last 90 days) to determine whether
there exists a. debit
ROC with the same merchant as the credit ROC, for the same registered card. If
found,
TAP further checks to see if the previous transaction was eligible for a
rebate credit and the
amount of the rebate credit that was provided to the CM. If the previous
transaction is
eligible for a rebate credit, then a debit corresponding to the amount of the
rebate credit in
full (corresponding to full returns) or in part (corresponding to partial
returns) is charged to
the account holder. These debits thereby adjust the net return credit to equal
the original
purchase price less the rebate credit. The merchant is reimbursed for the
amount of the
debited rebate credit, and the merchant's reimbursement appears as a credit on
the
merchant's account. The determination of the discount reversal amount (i.e.,
amount of the
26
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
debited rebate credit) is based on the CM's rebated credit on the original
purchase rather
than the debit received by the merchant, since the merchant's previous debit
for the CPA's
rebate credit may include an associated service fee imposed by TAP and/or UR
As noted
above, in one embodiment, stock keeping units (SKEYs) of purchased
goods/services are
used to match purchases with returns and determine the discount reversal
amount. In
another embodiment, certain assumptions are made in accordance with a return
logic policy
to do the matching. Exemplary return logic policy is described below with
reference to
FIC3s. 11 and 12.
At step 670, CM information in enrollee database 134 is used to match
registered
GNU with ROCs extracted in step 660, and each matched transactions is provided
with a
transaction ID. In step 680, output file 444 is created of transactions
matched in step 670.
At step 690, output file 444 is provided to loyalty program provider for
discount/discount
reversal calculation.
FIG. 7 shows in greater detail the matching processes of steps 650 and 670 and
the
process of extraction step 660 of FIG. 6, in accordance to an embodiment. Step
650, for the
matching of merchants to offers, may include steps 652, 654, 656 and 658. In
step 652, the
list of merchants from merchant database 454 is compared with the list of
offers in merchant
offer database 452, In step 654, offers are checked to be either premium or
everyday offers.
In step 656, offers are selected for inclusion in a master file in step 658 if
the offers are
currently in effect as determined by the offer start and end dates, and in
step 658, a master
file is created which includes the merchant SEnumber, the offer ID, the offer
end date, and
the offer type (premium or everyday). Extraction step 660 receives the ROC
extraction file
from step 630 (see FIG, 6) as well as the master file of step 658. In this
embodiment,
extraction step 660 includes steps 662, 664, 666 and 668. In step 662,
merchant SEnumbers
are compared to the ROC extract file of step 660 and master file of step 658,
and in step 654,
ROCs for merchants participating in TAP's registered card program are
selected. Of the
selected ROCs for participating merchants, the ROCs are extracted if (in step
666) the
transaction date is less than the offer end date reflected in the master tile
or if (in step 668)
the ROC is a credit ROC. These extracted ROCs are an input to matching step
670 that
includes steps 672, 674, 676 and 678. In step 672, CM account/card numbers
from the
extracted ROC file are matched with the registered accounts stored in enrollee
database 134.
In step 674, those ROCs corresponding to the registered accounts of C.Ms are
selected. If
the registered CM is a premium CM then at step 676, all ROCs are extracted for
the CM;
27
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
otherwise, at step 678 only .R.00s that apply to everyday offers are extracted
for the CM.
These extracted ROCs are provided to step 680 of FIG. 6 for creation of output
file 444.
As shown in FIG. 8, the EPP receives output file 444 from TAP at step 810. In
step
812, the LPP calculates the discount or negative discount (i.e., discount
reversal) amount for
each purchase and return transaction, respectively. In stop 814, a file
including a discount or
discount reversal calculation (such as file 442 provided to RCE 138, described
above in FIG,
4) is provided to TAP. TAP uses this file at step 820 to update its
transaction database with
discount amounts or negative discount amounts, whereby the original ROC
transaction is
matched with these discounts or negative discounts. At step 822, TAP creates a
file of CM
credits and corresponding merchant debits for discounts associated with a
purchase.
Further, TAP may include CM debits and merchant credits for negative discounts
associated
with returns. In step 824, TAP's SPP (shopping portal processor) platform is
used to create a
FinCa.p file which is provided to FinCap, and in step 826, FinCap processes CM
discounts
(Le., rebate credits) and CM discount reversals. In particular, as described
above in FIG. 4,
RCE 138 provides TAP's AP (accounts payable) system with information on
merchant
debits and credits for processing at step 828 and provides TAP's AR (accounts
receivable)
system with information on account holder debits and credits for processing at
step 830.
Pursuant to step 828, a merchant's account is debited for the CM's rebated
credit, may be
further debited a service fee, and is credited a CM's discount reversal amount
in the case of
an eligible return. Pursuant to step 840, a CM's account (or monthly
statement) shall show a
credited amount in accordance with any rebate credit and a debited amount in
accordance
with any discount reversal arising from an eligible return.
Methodologies unique to processing of account holder returns by means of a
return
logic policy in accordance with an embodiment are now described with reference
to EEGs,
11 and 12. In these figures ".1M tx" represents CM transactions which were
eligible for a
rebate credit in accordance with the TailorMadesm registered card program
described herein.
FIG. II provides examples of actions taken in response to returns. For
exarnple, in line I of
FIG, 11, a $1,000 return is made on September 1, 2006. In response to this
return, TAP will
take no action with respect to debiting any rebate credit, because there were
no transactions
made in the prior 60 days to correspond to the $1,000 return. In line 2, for
the same return,
it is determined that there was a $1,000 purchase within the prior 60 days
along with a $100
statement credit. Therefore, it is assumed that the $100 statement credit was
a rebate credit
that must be debited. in line 3, a $400 return is made. In this ease, a
proportional $40 debit
28
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
is made to correspond to the portion of the rebate credit on the $400 purchase
that was
returned, Additional examples and assumptions/rationales are provided in FIG.
11.
FIG. 12 provides additional examples of return policy logic in which a CM may
be
debited for identified rebate credit(s) on TM (TailorMadesm)transactions. As
shown in FIG.
12, if the CM is debited for identified rebate credit(s), and if the CM
disputes the credit and
claims that the return is part of a non-TM transaction (i.e., a transaction in
which the CM did
not receive a rebate credit), then the rebate credit is written off of CMs
account. For
example, in the line I of FIG. 12, a return is made for $1000, and it assumed
that the return
is associated the first exact transaction in the past 60 days for that is the
same amount as the
return, In this example, transaction "6" is the first transaction of $1000,
and the return is
associated with transaction "6." Since transaction "6" was discounted 10%,
whereby the
CM received a rebate credit of $100, then the CM is debited the $100. If the
CM disputes
the debit, such as by claiming, that the return is in fact part of transaction
"4," then the debit
is written off, since transaction "4" was not subject to a discount.
If in line 1 there is no exact matched transaction identified with the return,
then, in
line 2, the first transaction in the past 60 days which is greater than the
amount of the return
is identified with the return. As shown in line 2, transaction "6" for $5000
is the first
matched transaction having an amount greater than the return. Since
transaction "6" was not
discounted, then no action is taken with regard to debiting CM. If CM claims
that the return
is part of transaction "5" and "2", then a debit from the GM's account is made
in the amount
of the rebate credits (15% and 15%) for those transactions. If there is no
transaction
matched in lines or 2, then in line 3, if the sum of the return is equal or
smaller than the
sum of all transactions in the past 60 days, then it is assumed that the
return refers to TM
transactions up to $1000, and a debit to CM's account is provided in
accordance with the
discounts on Tivl transactions 2 and 5,
FIGs. 9 and 10 show high level flow diagams of a process for transaction
matching:
(via RCE 138) of registered (INS cards. As shown in FIG. 9, transactions
deserving of
discounts or discount reversals as well as any service fees are provided to
U.S. Submissions
482 which is placed at global clearing and settlement 484, which is a
repository for
collection by GNS issuers 486 for processing of credits and debits on GNS
cards held by
registered CMs (referred to as "GNS CMs"). Global clearing and settlement 484
is also a
repository for daily ROC data that is submitted to RCE 138 for transaction
matching.
Although not shown here, GNS issuers 486 provide TAP with information on GNS
accounts
29
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
held by registered CMs to permit transaction matching, and also to permit
enrollee database
134 to be updated according to cancellations 440 (as described above with
reference to FIG.
4), In an embodiment shown in FIG. 9, card authorization system 414 may
involve a one
dollar authorization by which the CM's card is validated at enrollment. As
shown in FlGs. 9
and 10. U.S. submissions 42 receives discount, returns, and service fee
information from
RCE 138 that is used by GNS issuers 486 to settle with merchants and (INS CMs.
U.S.
submissions 482 passes a two line message to GNS issuers 486, which appears on
the
respective issuer's credit statement. A similar two line message may be
provided on GNS
CM's account statement, thereby providing transparency of the settlement of
transactions
made pursuant to TAI'`.3 registered card program to both GNS CMs and CMs
holding cards
issued by TAP, such as in the manner described above with reference to FIG. 2.
The present system or any part(s) or function(s) thereof may be implemented
using
hardware, software or a combination thereof and may be implemented in one or
more
computer systems or other processing systems. However, the manipulations
performed by
embodiments were often referred to in terms, such as matching or selecting,
which are
commonly associated with mental operations performed by a human operator. No
such
capability of a human operator is necessary, or desirable in most cases, in
any of the
operations described herein. Rather, the operations may be machine operations.
Useful
machines for performing the various embodiments include general purpose
digital
computers or similar devices.
In fact, in one embodiment, the embodiments are directed toward one or more
computer systems capable of carrying out the funetionality described herein.
An example of
a computer system 1300 is shown in FIG. 13.
The computer system 1300 includes one or more processors, such as processor
1304.
-25 The
processor 1304 is connected to a communication infrastructure 1306 (e.g., a
communications bus, cross-over bar, or network). Various software embodiments
are
described in terms of this exemplary computer system. After reading this
description, it will
become apparent to a person skilled in the relevant art(s) how to implement
various
embodiments using other computer systems and/or architectures.
Computer system 1300 can include a display interface 1302 that forwards
graphics,
text, and other data from the communication infrastructure 1306 (or from a
frame buffer not
shown) for display on the display unit 1330.
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
Computer system 1300 also includes a main memory 1308, such as for example
random access memory (RAM), and may also include a secondary memory 1310. The
secondary memory 1310 may include, for example, a hard disk drive 1312 and/or
a
removable storage drive 1314, representing a floppy disk drive, a magnetic
tape drive, an
optical disk drive, etc. The removable storage drive 1314 reads from and/or
writes to a
removable storage unit 1318 in a well known manner. Removable storage unit
1318
represents a floppy disk, magnetic tape, optical disk, etc. which is read by
and written to by
removable storage drive 1114. As will be appreciated, the removable storage
unit 1318
includes a computer usable storage medium having stored therein computer
software and/or
data.
In alternative embodiments, secondary memory 1310 may include other similar
devices for allowing computer programs or other instructions to be loaded into
computer
system 1100, Such devices may include, for example, a removable storage unit
1318 and an
interface 1320. Examples of such may include a program cartridge and cartridge
interface
(such as that found in video game devices), a removable memory chip (such as
an erasable
programmable read only memory (EPROM), or programmable read only memory
(PROM))
and associated socket, and other removable storage units 1318 and interfaces
1320, which
allow software and data to be transferred from the removable storage unit 1318
to computer
system 1300.
Computer system 1300 may also include a communications interface 1324.
Communications interfhce 1324 allows software and data to be transferred
between
computer system 1300 and external devices. Examples of communications
interface 1324
may include a modem, a network interface (such as an Ethernet card), a
communications
port, a Personal Computer Memory Card International Association (PCMCIA) slot
and card,
etc. Software and data transferred via communications interface 1324 are in
the form of
signals 1328 which may be electronic, electromagnetic, optical or other
signals capable of
being received by communications interface 1324. These signals 1328 are
provided to
communications interface. 1324 via a communications path (e.g., channel) 1326.
This
channel 1326 carries signals 1328 and may be implemented using wire or cable,
fiber optics,
a telephone line, a cellular link, a radio frequency (RF) link and other
communications
channels,
in this document, the terms "computer program medium" and "computer usable
medium" are used to generally refer to media such as removable storage drive
1314 and a
31
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
hard disk installed in hard disk drive 1312. These computer program products
provide
software to computer system 1300.
Computer programs (also referred to as computer control logic) are stored in
main
memory 1308 and/or secondary memory 1310. Computer programs may also be
received
via, communications interface 1324. Such computer programs, when executed,
enable the
computer system 1300 to perform the features as discussed herein. In
particular, the
computer programs, when executed, enable the processor 1304 to perform the
features of
various embodiments. Accordingly, such computer programs represent controllers
of the
computer system 1300.
Trl an embodiment, software may be stored in a computer program product and
loaded into computer system 1300 using removable storage drive 1314, hard
drive 1312 or
cornrr3un ications interface 1324. The control logic (software), when executed
by the
processor 1304, causes the processor 1304 to perform the functions of various
embodiments
as described herein.
In another embodiment, hardware components such as application specific
integrated
circuits (ASICs). Implementation of the hardware state machine so as to
perfsrm the
functions described herein will be apparent to persons skilled in the relevant
art(s).
One skilled in the art will appreciate that system 1300 may employ any number
of
databases in any number of configurations. Further, any databases discussed
herein may be
any type of database, such as relational, hierarchical, graphical, object-
oriented, and/or other
database configurations. Common database products that may be used to
implement the
databases include DB2 by IBM (White Plains, NY), various database products
available
from Oracle Corporation (Redwood Shores, CA), Microsoft Access or Microsoft
SQL
Server by Microsoft Corporation (Redmond, Washington), or any other suitable
database
product. Moreover, the databases may be organized in any suitable manner, for
example, as
data tables or lookup tables. Each record may be a single file, a series of
files, a linked
series of data fields or any other data structure. Association of certain data
may be
accomplished through any desired data association technique such as those
known or
practiced in the art. For example, the association may be accomplished either
manually or
automatically. Automatic association techniques may include, for example, a
database
search, a database merge, GREP, AGREP, SQL, using a key field in the tables to
speed
searches, sequential searches through all the tables and files, sorting
records in the file
according to a known order to simplify lookup, and/or the like. The
association step may be
32
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
accomplished by a database merge function, for example, using a "key field" in
pre-selected
databases or data sectors.
More particularly, a "key field" partitions the database according to the high-
level
class of objects defined by the key field, For example, certain types of data
may be
designated as a key field in a plurality of related data tables and the data
tables may then be
linked on the basis of the type of data in the key field. The data
corresponding to the key
field in each of the linked data tables is preferably the same or of the same
type. However,
data tables having similar, though not identical, data in the key fields may
also be linked by
using AGM?, for example. In accordance with one aspect of system 1300, any
suitable data
storage technique may be utilized to store data without a standard format.
Data sets may be
stored using any suitable technique, including, for example, storing
individual files using an
ISO/IEC'. 7816-4 file structure; implementing a domain whereby a dedicated
file is selected
that exposes one or more elementary files containing one or more data sets;
using data sets
stored in individual files using a hierarchical filing system; data sets
stored as records in a
single file (including compression, SQL accessible, hashed via one or more
keys, numeric,
alphabetical by first taple, etc); Binary Large Object (BLOB); stored as
ungrouped data
elements encoded using 1S0/1EC '7816-6 data elements; stored as ungrouped data
elements
encoded using ISO/IEC Abstract Syntax Notation (ASN.1) as in ISOIIEC 8824 and
8825;
and/or other proprietary techniques that may include fractal compression
methods, image
compression methods, etc.
In one embodiment, the ability to store a wide variety of information in
different
formats is facilitated by storing the information as a BLOB. Thus, any binary
information
can be stored in a storage space associated with a data set. As discussed
above, the binary
information may be stored on the financial transaction instrument or external
to but affiliated
with the financial transaction instrument. The BLOB method may store data sets
as
ungrouped data elements formatted as a block of binary via a fixed memory
offset using
either fixed storage allocation, circular queue techniques, or best practices
with respect to
memory management (e.g., paged memory, least recently used, etc.). By using
BLOB
methods, the ability to store various data sets that have different formats
facilitates the
storage of data associated with system 1300 by multiple and unrelated owners
of the data
sets. For example, a first data set which may be stored may be provided by a
first party, a
second data set which may be stored may be provided by an unrelated second
party, and yet
a third data set which may be stored, may be provided by an third party
unrelated to the first
33
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
and second party. Each of these three exemplary data sets may contain
different information
that is stored using different data storage formats and/or techniques.
Further, each data set
may contain subsets of data that also may be distinct from other subsets.
As stated above, in various embodiments of system 1300, the data can he stored
without regard to a common format. However, in one exemplary embodiment, the
data set
(e.g., BLOB) may be annotated in a standard manner when provided tbr
manipulating the
data onto the financial transaction instrument. The annotation may comprise a
short header,
trailer, or other appropriate indicator related to each data set that is
configured to convey
information useful in managing the various data sets. For example, the
annotation may be
called a "condition header", "header", "trailer", or "status", herein, and may
comprise an
indication of the status of the data set or may include an identifier
correlated to a specific
issuer or owner of the data, in one example, the first three bytes of each
data set BLOB may
be configured or configurable to indicate the status of that particular data
set; e.g.,
LOADED, INITIALIZED, READY, BLOCKED, REMOVABLE, or DELETED.
Subsequent bytes of data may be used to indicate for example, the identity of
the issuer,
user, transaction/membership account identifier or the like. Each of these
condition
annotations are further discussed herein.
The data set annotation may also he used for other types of status information
as well
as various other purposes. For example, the data set annotation may include
security
information establishing access levels. The access levels may, for example, be
configured to
permit only certain individuals, levels of employees, companies, or other
entities to access
data sets, or to permit access to specific data sets based on the transaction,
merchant, issuer,
user or the like. Furthermore, the security information may restrict/permit
only certain
actions such as accessing, modifYing, and/or deleting data sets. In one
example, the data set
annotation indicates that only the data set owner or the user are permitted to
delete a data
set, various identified users may be permitted to access the data set for
reading, and others
are altogether excluded from accessing the data set. However, other access
restriction
parameters may also he used allowing various entities to access a data set
with various
permission levels as appropriate.
The data, including the header or trailer may be received by a stand-alone
interaction
device configured to add, delete, modify, or augment the data in accordance
with the header
or trailer. As such, in one embodiment, the header or trailer is not stored on
the transaction
device along with the associated issuer-owned data but instead the appropriate
action may be
34
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
taken by providing to the transaction instrument user at the stand-alone
device, the
appropriate option for the action to be taken, System 1300 contemplates a data
storage
arrangement wherein the header or trailer, or header or trailer history, of
the data is stored on
the transaction instrument in relation to the appropriate data.
One skilled in the art will also appreciate that, for security reasons, any
databases,
systems, devices, servers or other components of system 1300 may consist of
any
combination thereof at a single location or at multiple locations, wherein
each database or
system 1300 includes any of various suitable security features, such as
.firewalls, access
codes, encryption, decryption, compression, decompression, and/or the like.
In addition to those described above, the various system components discussed
herein may include one or more of the following: a host server or other
computing systems
including a processor for processing digital data; a memory coupled to the
processor for
storing digital data; an input digitizer coupled to the processor for
inputting digital data; an
application program stored in the memory and accessible by the processor for
directing
processing of digital data by the processor; a display device coupled to the
processor and
memory for displaying information derived from digital data processed by the
processor;
and a plurality of databases. Various databases used herein may include:
client data;
merchant data; financial institution data; and/or like data useful in the
operation of the
present system. As those skilled in the art will appreciate, user computer may
include an
operating system (e.g., Windows NT, 95/98/2000, 052, UNIX, Linux, Solaris,
MacOS, etc.)
as well as various conventional support software and drivers typically
associated with
computers. The computer may include any suitable personal computer, network
computer,
workstation, minicomputer, mainframe or the like. User computer can be in a
home or
business environment with access to a network. In an exemplary embodiment,
access is
through a network or the Internet through a commercially-available web-browser
software
package.
As used herein, the term "network" includes any cloud, cloud computing system
or
electronic communications system or method which incorporates hardware and/or
software
components. Communication among the parties may be accomplished through any
suitable
communication channels, such as, for example, a telephone network, an
extranet, an
intranet. Internet, point of interaction device (point of sale device,
personal digital assistant
(e.g.. iPhone0, Palm Pilot , Blackberry ), cellular phone, kiosk, etc.),
online
Communications, satellite communications, off-line communications, wireless
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
communications, transponder communications, local area network (LAN), wide
area
network (WAN), virtual private network (VPN), networked or linked devices,
keyboard,
mouse and/or any suitable communication or data input modality. Moreover,
although the
system is frequently described herein as being implemented with TCP/IP
communications
protocols, the system may also be implemented using IPX, Appletalk, -IP-6,
NetBIOS, OSI,
any tunneling protocol (e.g, IPsec, SSI-1), or any number of existing or
future protocols. If
the network is in the nature of a public network, such as the Internet, it may
be advantageous
to presume the network to be insecure and open to eavesdroppers. Specific
information
related to the protocols, standards, and application software utilized in
connection with the
Internet is generally known to those skilled in the art and, as such, need not
be detailed
herein. See, for example, DLIT NAIK, INTERNET STANDARDS AND PROTOCOLS (1998);
JAvA
2 COMPLETE, various authors, (Syhex 1999); DEBORAH RAY AND ERIC RAY, MASTERING
HTML 4,0 (1997); and LOSHIN, TCP/IP CLEARLY EXPLAINED (1997) and DAVID GOURLEY
AND BRIAN Torrv, HTTP, THE DEFINITIVE GUIDE (2002), the contents of which are
hereby
incorporated by reference.
"Cloud" or "Cloud computing" includes a model for enabling convenient, on-
demand network access to a shared pool of configurable computing resources
(e.g.,
networks, servers, storage, applications, and services) that can be rapidly
provisioned and
released with minimal management effort or service provider interaction. Cloud
computing
may include location-independent computing, whereby shared servers provide
resources,
software, and data to computers and other devices on demand. For more
information
regarding cloud computing, see the MST's (National Institute of Standards and
Technology)
definition of cloud computing at http://esre.nist.govtgroups/SNS/cloud-
computingicloud-
def-v15,doc (last visited February 4, 2011), which is hereby incorporated by
reference in its
entirety.
The disclosure may be described herein in terms of functional block
components,
screen shots, optional selections and various processing steps, it should he
appreciated that
such functional blocks may be realized by any number of hardware and/or
software
components configured to perform the specified functions. For example, system
1300 may
employ various integrated circuit components, e.g, memory elements, processing
elements,
logic elements, look-up tables, and/or the like, which may carry out a variety
of functions
under the control of one or more microprocessors or other control devices.
Similarly, the
software elements of system 1300 may be implemented with any programming or
scripting
36
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
language such as C, C++, Java, COBOL, assembler, .PERL, Visual Basic, SQL
Stored
Procedures, extensible markup language (XML), with the various algorithms
being
implemented with any combination of data structures, objects, processes,
routines or other
programming elements. Further, it should be noted that system 1300 may employ
any
number of conventional techniques for data transmission, signaling, data
processing,
network control, and/or the like, Still further, system 1300 could be used to
detect or
prevent security issues with a client-side scripting language, such as
Java.Seript, VBScript or
the like. For a basic introduction of cryptography and network security, see
any of the
following references: (1) "Applied Cryptography: Protocols, Algorithms, And
Source Code
In C," by Bruce Schneier, published by John Wiley & Sons (second edition,
1995); (2) "Java
Cryptography" by Jonathan Knudson, published by O'Reilly & Associates (1998);
(3)
"Cryptography & Network Security: Principles & Practice" by William Stallings,
published
by Prentice Hall; all of which are hereby incorporated by reference.
These software elements may be loaded onto a general purpose computer, special
purpose computer, or other programmable data processing apparatus to produce a
machine,
such that the instructions that execute on the computer or other programmable
data
processing apparatus create means for implementing the functions specified in
the flowchart
block or blocks. These computer program instructions may also be stored in a
computer-
readable memory that can direct a computer or other programmable data
processing
apparatus to function in a particular manner, such that the instructions
stored in the
computer-readable memory produce an article of manufacture including
instruction means
which implement the function specified in the flowchart block or blocks. The
computer
program instructions may also be loaded onto a computer or other programmable
data
processing apparatus to cause a series of operational steps to be performed on
the computer
or other programmable apparatus to produce a computer-implemented process such
that the
instructions which execute on the computer or other programmable apparatus
provide steps
for implementing the functions specified in the flowchart block or blocks.
Accordingly, functional blocks of the block diagams and flowchart
illustrations
support combinations of means for performing the specified functions,
combinations of
steps for perfbrming the specified functions, and program instruction means
for performing
the specified functions. It will also be understood that each functional block
of the block
diagrams and flowchart illustrations, and combinations of functional blocks in
the block
diagrams and flowchart illustrations, may be implemented by either special
purpose
37
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
hardware-based computer systems which perform the specified functions or
steps, or
suitable combinations of special purpose hardware and computer instructions.
Further,
illustrations of the process flows and the descriptions thereof may make
reference to user
windows, web pages, web sites, web forms, prompts, etc. Practitioners will
appreciate that
the illustrated steps described herein may comprise in any number of
configurations
including the use of windows, web pages, web forms, popup windows, prompts
and/or the
like. It should be further appreciated that the multiple steps as illustrated
and described may
be combined into single web pages and/or windows but have been expanded for
the sake of
simplicity. In other cases, steps illustrated and described as single process
steps may be
separated into multiple web pages and/or windows but have been combined for
simplicity.
Practitioners will appreciate that there are a number of methods for
displaying data
within a browser-based document. Data may he represented as standard text or
within a
fixed list, scrollable list, drop-down list, editable text field, fixed text
field, pop-up window,
and/or the like. Likewise, there are a number of methods available for
modifying data in a
web page such as, for example, free text entry using a keyboard, selection of
menu items,
check boxes, option boxes, and/or the like.
in one embodiment, RCP 130 includes application programming interfaces that
enable third parties to create, configure, manage, modify, update, delete,
report on, and
enhance reward offers and marketing programs. For example, a program provider
(e.g., an
LPP or TAP) may wish to create a custom application ("partner application")
that serves as a
front-end or interface to RCP 130. The partner application accesses RCP 130
via various
application programming interfaces (APIs). In one embodiment, the APIs may
include a
partner registration API, an offer set-up AK an enrollment API, a transaction
API, a trigger
API, a partner registration API, a reporting API and a marketing channel API.
RCP 130 is a
robust extensible platform that enables, in various embodiments, a variety of
APIs for
accessing a variety of functions. While some APIs may correspond directly to a
function
that may be desired by a partner, others may provide access to core
functionality such as, for
example, APIs for accessing workflow functionality or for accessing database
query
functionality.
Fig, 14 includes one embodiment of RCP 130 and a plurality of API's. As shown,
RCP 130 may be configured to communicate with (or execute computer programs
for) an
approval portal, a workflow engine and a number of internal and external
databases.
38
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
Partner registration API 1405 may enable a marketing partner to access RCP 130
in
order to register with and configure access to RCP 130, In one embodiment, a
developer
portal provides an interface to partner users and a registration request is
sent via partner
registration API 1405 to RCP 130, RCP 130 validates the registration request
and executes
a workflow to provision a partner user identification code ("user id") and an
API access
code. RCP 130 saves a partner profile in the partner database 1410. in one
embodiment,
RCP 130 allocates memory, databases, file structure and/or other system
resources to be
used by partner users in testing and in production. In an embodiment, based
upon a
workflow and/or predefined business rules, RCP 130 executes logic to approve
the
registration request. The process to approve the registration request may be
completely
automated and/or may comprise steps whereby RCP administrators provide a
manual
approval. RCP 130 sends the registration information (e.g., user id and access
code) to the
partner user. A partner user and/or a RCP administrator may also access RCP
130 via
partner registration API 1405 in order to update partner details, and
terminate the partner if
needed,
Offer setup API 1415 may allow a partner to build their own offer set up tool,
may
provide access to their own internal users, and/or may allow the partner to
open up the tool
to external users of their application or service (e.g., a user base of
merchants or a company
representing merchants). In one embodiment, offer setup API 1415 enables
receiving a offer
setup request; parsing the offer set up request into offer parameters;
validating the offer
setup request and/or the offer parameters; notifying a first approver of the
offer setup
request; receiving from the first approver, an approval of the offer set up
request; saving an
offer comprising the first offer parameters; associating the offer associated
with a marketing
program; and determining a first population of transaction accounts that
comply with first
offer criteria.
In one embodiment, the parsing includes applying logical and/or business rules
to a
request to divide, reorganize, translate and/or augment the data associated
with a request. In
various embodiments, parsing may be accomplished as part of the data
validation process
and/or as part of populating the data in a database. Data validation includes
applying logical
and/or business rules in order to ensure that data is received in, for
example, an expected
format and/or structure and that the data conforms in content to business
rules that govern
the data. Business rules used to parse the data may be based upon, for
example, a partner,
an offer, a product, an industry, a promotion, a program, a transaction
processor, an issuer or
39
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
any combination of these or other factors. Data that fails validation may
cause an error to be
sent to the system that sent the data and/or may cause RCP 130 administrator
staff to
examine and or modify the data.
Thus, a RCP 138 user (e.g., a partner) may use offer setup API 1415 to
configure
marketing programs and offers and to determine a population of transaction
accounts that
may be eligible for a program. Such data may be useful to a marketing partner
in analyzing
and targeting a particular promotion. Offer setup API 1415 may also enable a
partner to
specify criteria (e.g., define qualifying transactions, behaviors, events or
thresholds) that
qualify for a reward The offer criteria may include any combination of a
customer
identifier, a customer demographic, a customer location, spend frequency, a
spend threshold,
a spend history, an award cap, a tiered reward requirement, a product
identifier, a product
category, a stock-keeping unit (SKU), a universal product code (UPC), a OR
code, a
merchant, a merchant type, an industry, a merchant location. Thus, offer set
up API 1415
enables a partner to enter, maintain, analyze reward eligibility and configure
RCP 130 to
execute the offer. These constructs may enable highly targeted marketing
promotions
tailored to the specific needs of the partner, or the partner's user base. Any
or all of these
factors may also be used to exclude transaction accounts that may participate
in an offer
and/or provide criteria for excluding or withholding a reward.
In various embodiments, offer setup API also enables a partner to configure
how
offer costs are collected from a participating service establishment (e.g.,
merchant). For
example, offer costs can be debited from the merchant account associated with
where the
qualifying transaction actually occurred (e,g., where a customer transacted),
or from a single
merchant specified by the partner. Offer setup AN also enables a partner to
configure the
amount, currency and manner in which rewards are distributed. For example, in
addition to
fulfilling via statement credits, output files can be generated and passed to
the partner to
enable new types of fulfillment such as social currency. In an embodiment, RCP
130
determines that a qualifying transaction (and or event) has occurred and
calculates a reward
for a member or transaction account. Distributing the reward may include
crediting a first
transaction account, crediting a second transaction account, crediting a
rewards account
associated with the first transaction account, performing a currency
conversion, crediting a
social networking currency and sending reward data to a third party, where the
third party
applies the reward based upon the reward data.
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
Enrollment API 1420 may enable RCP 130 to capture enrollments from programs
set
up through the offer set up APT, It may enable a partner to build their own
enrollment
functionality and embed the feature into their application. For example, a
partner may
design a rewards program and wish to solicit participation and enable
enrollment in the
program using a variety of different methods such as via an email message, a
link, a uniform
resource locator (LAO, a customized web page, a web page hosted by the
automated
marketing system, a social networking web site, an app, a text message and a
mobile
application. Thus, the partner may define, via the enrollment API, that a web
page be
generated and hosted via RCP 130 and used to receive and process enrollments
in a
program. in an embodiment, the partner may define, via the enrollment API, a
custom web
page (or URL) by which enrollment may occur and, optionally, may define a
access
requirements (e.g., user id/password) for enrolling in a program.
The partner may use (e.g., via a custom application or website) enrollment API
1420
to enter and configure enrollment parameters in RCP 130, Enrollment parameters
may
include defining an enrollment process, instructions for generating a hosted
enrollment page,
a referral uniform resource locator (UR1,), a user id, a password, a passcode,
an enrollment
timefraine, and an enrollment cap, and enrollee (e.g., offer or program
participant) tracking
data requirements. The enrollee tracking requirements may include a user id,
email address,
password, product code, and transaction location; thus, the enrollment API is
useful in
defining how a transaction account or member may enroll in a program and
defining data
and events by which the partner may track a member's activity. Thus, a
partner, program
provider or issuer may capture the user ID/e-mail/phone number/password,
product
category, or other unique identifier(s) (QR code or marketing channel
information) and/or
may track this information during a program in order to enable additional
reporting metrics,
specific product opt-ins, and/or the trigger API functionality (discussed
below).
Reporting API 1425 may enable real-time, or near real-time, results to an
interfacing
system (e.g., partner system). Using reporting API 1425, the partner can also
define reports
and data to be distributed to third parties such as, for example, program
participants
(merchants and customer), news sites, social media networks, etc. Reporting
API may
provide the ability to define and/or access a wide range of cumulative and
incremental
metrics. The metrics may include, for example, number of enrollments, CV, avg.
ROC,
number discounts, money discounts (or alternate fulfillment method). The
partner and the
partner's users will also have the ability to opt-in for in--depth pre/post-
campaign metrics.
41
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
Additional fields captured during enrollment can also be appended to reporting
data and
passed back to the partner.
Transaction API 1430 may enable a partner to define transactions and/or events
that
trigger data to be shared with a third party. For example, a transaction
account issuer may
allow their customers (e.g., transaction account owners) to opt-in to
triggered data sharing so
that when a customer initiates a transaction, data regarding that transaction
is posted to a
user's social networking account. For example, a customer swipes a transaction
account
card at a local florist when purchasing flowers, RCP 138 receives transaction
details from
the transaction account authorization process, and details regarding the
transaction (e.g.,
merchant name, location, transaction amount, product, product type, time of
transaction,
etc.) are sent via transaction API to the Facebook account of the consumer.
Thus, in one
embodiment, RCP 138 leverages the transaction account authorization process to
provide a
new capability which allows customers to share transaction information in real-
time,
Transaction API 1430 may enable a real-time service allowing customers to
automatically share their spend behavior with social networks, smartphone
applications, and
other 3rd party destinations. in one embodiment, customers opt-in for this
service, and
select criteria for their spend intbrination will be shared (e.g. only share
transactions at
restaurants, but never share transactions at jewelry stores.")
In one embodiment, RCP 138 receives, via transaction API 1430, a data sharing
opt-
in associated with the first transaction account, wherein the data sharing opt-
in defines data
sharing transactions for which the first user authorizes personal data
sharing. RCP 138
obtains transaction notification data for a transaction authorization request
associated with
the first transaction account and determines that the transaction
authorization request
qualifies as a data sharing transaction. RCP 130 sends data associated with
the transaction
authorization request to at least one of a web site, a social networking site,
a social
networking application, a third party, an individual, and a social networking
account of a
friend.
Trigger API 1435 may enable a partner to define conditions and/or events that
trigger
a message or data ("alerts") to be sent passed to the partner or other 3rd
patties. In one
embodiment, trigger AP1 1435 enables a partner to configure and manage managed
alerts, or
alerts for its users who are merchants (or representing merchants). The
partner may
configure trigger alerts based on any data accessible to RCP 138 (e.g.,
customer, merchant
42
CA 02874582 2014-11-24
WO 2012/170088 PCT/US2012/027810
or product specific data), any calculation or business rule associated with
the data (e.g., a
counter, accumulation or threshold)
In an embodiment, RCP 130 receives, via a trigger API, a triggered event
request
defining triggered alert parameters for triggered offer alerts, wherein the
triggered event
parameters define offer alerts based upon at least one of: a number of
enrollments for an
offer; a number of authorization requests associated with an offer, a number
of authorization
requests associated with a transaction account, an award cap, an award
threshold, a tiered
reward requirement, a product identifier, a product category, a stock-keeping
unit (SKU), a
QR code, a universal product code (UPC), a merchant, a merchant type, an
industry, a
merchant location, and an marketing program result, In an embodiment, RCP 130
receives,
via a trigger API, a triggered event request defining triggered alert
parameters for triggered
customer alerts, wherein the triggered event parameters define customer alerts
based Upon at
least one of: offer progress, program progress, authorization requests
associated with an
offer, spend associated with an offer, spend associated with a program, spend
associated
with a merchant, a cross promotion, a second offer, an offer achievement and a
customized
message. RCP 138 monitors its databases and event logs for criteria for which
a trigger is
defined, formats a trigger alert and distributes the alert according to
distribution criteria.
defined by the particular trigger parameters.
Marketing channel API 1440 may enable a partner to query offer database 452
and/or other data sources. For example, via offer setup API 1415 a restaurant
oilers for 5%
credit for all meals purchased on Sundays and offers I% of the transaction
value to
marketing partners that sign up customers. A marketing channel partner (e.g.,
Groupon)
uses marketing channel APE 1440 to query the database, find this offer and opt-
in to
promoting the offer through the marketing channel. The marketing channel
partner uses
marketing channel API to determine merchant name, offer details (logo, Is &
Cs, dates
etc.), offer construct, merchant location (address and longitude/latitude) for
use in the
promotion.
In one embodiment, RCP 130 receives, from a requestor and via a marketing
channel
API, a marketing channel request for a list of at least one of marketing
channels, offers and
programs, RCP 130 sends, via the marketing channel API, the list to the
requester
associated with the marketing channel request The list includes a merchant
name, program
details, offer details, offer terms and conditions, an advertisement, a logo
and/or a merchant
location. RCP receives, via the marketing channel API, a marketing channel opt-
in request
43
CA 02874582 2014-11-24
WO 2012/170088
PCT/US2012/027810
associates the requester with at least one of a marketing channel, a program
and an offer
associated with the opt-in request.
The detailed description of exemplary embodiments herein makes reference to
the
accompanying drawings and pictures, which show the exemplary embodiment by way
of
illustration and its best mode. While these exemplary embodiments are
described in
sufficient detail to enable those skilled in the art to practice the
disclosure, it should be
understood that other embodiments may be realized and that logical and
mechanical changes
may be made without departing from the spirit and scope of the disclosure.
Thus, the
detailed description herein is presented for purposes of illustration only and
not of
limitation. For example, the steps recited in any of the method or process
descriptions may
be executed in any order and are not limited to the order presented. Moreover,
any of the
functions or steps may be outsoureed to or pertiarmed by one or more third
parties.
Furthermore, any reference to singular includes plural embodiments, and any
reference to
more than one component may include a singular embodiment.
1.5 Benefits,
other advantages, and solutions to problems have been described herein
with regard to specific embodiments. However, the benefits, advantages,
solutions to
problems, and any elements that may cause any benefit, advantage, or solution
to occur or
become more pronounced are not to be construed as critical, required, or
essential features
or elements of the disclosure. The scope of the disclosure is accordingly to
be limited by
nothing other than the appended claims, in which reference to an element in
the singular is
not intended to mean "one and only one" unless explicitly so stated, but
rather "one or
more." Moreover, where a phrase similar to at least one of A, B, or C is used
in the claims
or specification, it is intended that the phrase be interpreted to mean that A
alone may be
present in an embodiment, B alone may be present in an embodiment, C alone may
be
present in an embodiment, or that any combination of the elements A, B and C
may be
present in a single embodiment; for example, A and B. A and C, B and C, or A
and B and C.
All structural, chemical, and functional equivalents to the elements of the
above-described
exemplary embodiments that are known to those of ordinary skill in the art are
expressly
incorporated herein by reference and are intended to be encompassed by the
present claims.
Further, a list of elements does not include only those elements but may
include other
elements not expressly listed or inherent to such process, method, article, or
apparatus.
44
