Note: Descriptions are shown in the official language in which they were submitted.
Docket No. 107US
Request For Time Slot Specific Geo-Fenced Offers
Incented By Donation to Charity
REFERENCE TO RELATED APPLICATIONS
[0001] This US utility patent application claims priority to US Provisional
Application Serial
No. 62/947,661, titled "Request For Time Slot Specific Geo-Fenced Offers
Incented By
Donation to Geo-Fenced Charity," filed on December 13, 2019, which is
incorporated herein
by reference. This US utility patent application is related to US Utility
Patent Application
Serial No. 14/647,119, titled "Customer Voice Order Triggered Mutual Affinity
Merchant
Donation," filed on November 29, 2013, now US Patent No. 10,445325 issued on
October 15,
2019, and to US Utility Patent Application Serial No. 13/748,459, titled
"Authorized
Transaction Incented By Merchant Donation", filed on January 23, 2013, both of
which are
incorporated herein by reference.
FIELD
[0002] Embodiments described herein generally relate to a request for offers
from a plurality
of merchants to supply a good and/or service at a specific time and location,
where each
merchant's response to the request is an offer to supply the good and/or
service at the specific
time and location, where each merchant's offer includes an incentive for the
merchant to make
a merchant-defined donation to a requestor-selected charity.
BACKGROUND
[0003] Merchants may use techniques to prompt consumers into making a
particular
purchase. These techniques may be in the form of monetary incentives, relying
on the
principle that a lower price will result in increased sales. Merchants may
employ these
techniques, for example, to help clear inventory before a new season's
merchandise is
released, to ease the release of a new product, to increase sales near the end
of the fiscal year,
to compete with a competitor over particular products, or to generally spur
sales. Monetary
incentives may come in the form of a "sale" (i.e., temporary reduction in
price at the register),
a discount coupon, a mail-in rebate (i.e., a refund of part or the entire
purchase price by mail),
or a store credit (i.e., credit that can be applied to another store
purchase). These incentives
may only apply to a particular product and have a time component. For example,
a sale may
only apply to a particular brand of dishwasher purchased on a particular
holiday weekend and
a rebate may only be valid for computers purchased within two weeks before the
start of
classes at a university. Although consumers are typically incented to make
purchases by a
form of price reduction, non-monetary reasons may also motivate consumers to
make
purchases with a merchant, for instance where the consumers believes that the
merchant is a
1
CA 3102709 2020-12-11
Docket No. 1.07US
force for good and thus the consumers are non-monetarily incented to do
business with the
merchant who they deem worthy of such support. There exists a need for
platforms, systems,
methods, devices that may provide a non-monetary incentive motivate a consumer
to conduct
a transaction with a merchant, or at least an alternative.
[0004] Another problem for merchants, especially small to mid-sized merchants,
may be that
an increasing number of transactions are conducted online instead of inside
brick and mortar
stores. Online transactions conducted with larger merchants can represent a
loss in sales to
traditional small and medium size merchants whose main business method to
attract sales may
be a traditional retail, brick and mortar store environment, instead of mail
orders, telephone
orders, and/or electronic commerce (e-commerce) transactions. The loss of the
in-store
purchase may be a lost opportunity for the local merchant and local customer
to get to know
each other, personally, and a lost opportunity for the local customer to
become a live
advertisement for the merchant's retail store and its wares. Online sales also
prohibit the
traditional brick and mortar merchant from an opportunity to sell customers in
a retail
environment best understood by the merchant. 'I'he loss of in-store purchases
to online sales
may cause economic problems for traditional small and medium size merchants
and the
communities they serve. In some neighborhoods, the number of small retail
shops may
dramatically decline, leaving community commercial areas in a state of blight
and disuse. In
addition to economic downturn sensitivities, small, family-owned stores also
face extinction
threats from sophisticated online retailers, with resultant losses to local
community retail
diversity and neighborhood health with the death of the neighborhood 'morn-and-
pop' store.
Neighborhood streets can seem vacant during the day and open only after 5 p.m.
to serve the
interests of only one demographic, namely young urban professionals with
disposable income.
Previously successful businesses have been closing when e-commerce competition
from
online auctions and retailers attract previously loyal neighbors.
[0005] There exists a need for platforms, systems and methods that may shift
sales revenue
towards neighborhood merchants away from electronically competing merchants.
There exists
a need for platforms, systems and methods that may shift sales tax revenue
towards
neighborhood authorities that would otherwise be lost to e-commerce
transactions, or at least
alternatives. There exists a need for platforms, systems and methods that
incents local
merchants in the community to receive foot traffic from customers that are
incidentally doing
in-person shopping with other brick and mortar merchants, or at least
alternatives. There exists
a need for platforms, systems and methods that provides an incentive to a
customer, who
would have otherwise only window-shopped a product at the brick and mortar
store of a local
2
CA 3102709 2020-12-11
Docket No. 107US
merchant but then buy that product on-line from an electronic competitor
merchant, to buy
that product at the brick and mortar store of the local merchant.
SUMMARY
[0006] Implementations disclosed pertain to a holder of an account issued by
an issuer. The
account holder is a member of a loyalty program who submits a request for
multiple offers
from local merchants to supply a product or service within a particular time
frame. Each offer
complies with the specifics of the request and will also include an incentive
to the member to
accept the offer from the merchant who will make a merchant-defined donation
to a local
charity of the member's choice as specified in the member's request. Upon
receipt of the
member's request, one or more online accessible databases are queried to
identify which
merchants and charities have a physical presence within the member's community
and to
confirm that the charity specified by the member also has a physical presence
in the member's
community. Merchants in the member's community are further scrutinized for
relevance to the
requested product or service. Confirmation of the member's community is by
assessment of
mode-specific navigational transportation travel times between the merchant
and the member
during the particular time frame. Upon validation of the member's request, the
request is
electronically forwarded to each of the identified and vetted local merchants.
Each forwarded
request also prompt's the merchant to submit a compliant offer within a
predetermined time
frame. Upon receipt of a plurality of merchant offers within the predetermined
time frame,
each offer is validated for compliance with the specifics of the member's
request. Also, within
the predetermined time frame, a data payload is created so as to contain all
compliant offers as
received from the merchants. Upon creation, the data payload is forwarded to a
logical
address corresponding to the member. After the data payload is received, the
member can
compare offers to assess the highest and the lowest amount of the donation
that each merchant
will make to the local charity of the member's choice. The member can also
access an online
database to review information about each merchant who made an offer. This
information can
include merchant-provided information such the merchant's webpage and a
description of the
merchant's business. This inthrmation can also include crowd-sourced
information about the
merchant such as member reviews and ratings with respect to price, quality,
responsiveness,
punctuality, and professionalism. Optionally, the online database may also
calculate an
average rating from the crowd-sourced ratings as given to the merchant from
its transacting
members. Preferably, a predetermined time frame will be set for: (i) receiving
multiple offers
from multiple merchants; (ii) sending multiple offers to the requesting
member; and (iii)
receiving an acceptance from the requesting member of one or more of the
merchant offers. At
a predetermined time after the performance of each offer that had been
accepted, a survey will
3
CA 3102709 2020-12-11
Docket No. 107US
be forwarded to a logical address corresponding to: (i) the requesting member
along with an
incentive-bearing request for the member to assess the merchant's performance,
where the
incentive can be a further donation to the charity of the member's choice,
etc.; and (ii) the
merchant so that the merchant can assess the transaction with the member. Upon
receipt of the
survey results, online databases are updated with the survey results so as to
be accessible to all
members and merchants, and each member survey is forwarded to the
corresponding merchant
for use in evaluating customer service, etc.
[0007] Variations on the foregoing implementations as described herein further
relate to a
holder of an account issued by an issuer to a member of a loyal program who
submits a
request for multiple offers from local merchants to supply a product or
service within a
particular time frame. Each requested offer must comply with the specifics of
the request and
will also include an incentive to the member to accept the offer from the
merchant. The
incentive will preferably be a merchant-defined donation to a local charity of
the member's
choice. The charity may be specified in the member's request or may be stored
and retrieved
in a member-related database.
[0008] Upon receipt of the member's request, one or more online accessible
databases are
queried to identify which merchants and charities have a physical presence
within the
member's community and to confirm that the charity specified by the member
also has a
physical presence in the member's community. Merchants in the member's
community are
further scrutinized for relevance to the requested product or service.
Confirmation of the
member's community, as well as that of the member's designated charity, may be
by an
assessment of mode-specific navigational transportation travel times between
the merchant's
physical presence in the community and the member's physical presence in the
community
during the particular time frame in which goods and/or services as to be
supplied by the
merchant to the member.
[0009] Upon validation of the member's request, the request is electronically
forwarded to
each of the identified and vetted local merchants. Each forwarded request also
prompt's the
merchant to submit a compliant offer within a predetermined time frame. Upon
receipt of a
plurality of merchant offers within the predetermined time frame, each offer
is validated for
compliance with the specifics of the member's request. Also, within the
predetermined time
frame, a data payload is created so as to contain all compliant offers as
received from the
merchants. Upon creation, the data payload is forwarded to a logical address
corresponding to
the member.
[0010] After the data payload is received, the member can compare offers to
assess the
highest and the lowest amount of the donation that each merchant will make to
the local
4
CA 3102709 2020-12-11
Docket No. 107US
charity of the member's choice. The member can also access an online database
to review
information about each merchant who made an offer. This information can
include merchant-
provided information such the merchant's webpage and a description of the
merchant's
business. This information can also include crowd-sourced information about
the merchant
such as member reviews and ratings with respect to price, quality,
responsiveness, punctuality,
and professionalism. Optionally, the online database may also calculate an
average rating from
the crowd-sourced ratings as given to the merchant from its transacting
members.
[0011] Preferably, a predetermined time frame will be set for: (i) receiving
multiple offers
from multiple merchants; (ii) sending multiple offers to the requesting
member; and (iii)
receiving an acceptance from the requesting member of one or more of the
merchant offers.
[0012] After a completion of a transaction pertaining to an offer that was
accepted, and/or
after a predetermined time after the performance of the accepted offer, a
survey will be
forwarded to a logical address corresponding to: (i) the requesting member
along with an
incentive-bearing request for the member to assess the merchant's performance,
where the
incentive can be a further donation to the charity of the member's choice,
etc.; and (ii) the
merchant so that the merchant can assess the transaction with the member. Upon
receipt of the
survey results, online databases are updated with the survey results so as to
be accessible to all
members and merchants. Also, each completed member survey is forwarded to the
corresponding merchant for use in evaluating customer service, etc.
[0013] It will be appreciated that the foregoing summary merely describes
exemplary,
illustrative and non-limiting implementations.
BRIEF DESCRIPTION OF THE DRAWINGS
[0014] Non-limiting and non-exhaustive aspects are described with reference to
the following
figures, wherein like reference numerals refer to like parts throughout the
various figures
unless otherwise specified.
[0015] FIG. 1 is a schematic illustrating an exemplary request by a member for
offers from a
plurality of merchants in the member's community, where the request is for a
carpet cleaning
service of three rooms that is to be performed on Thursday, December 31, 2020,
where the
request is forwarded from a web access device to an Internet Server hardware
system, and
where offers are sent back to the member from merchants in the member's
community;
[0016] FIG. 2 is a flowchart illustrating an exemplary process that that
allows a member to
request an offer for goods and/or services from merchant in the member's
community, where
offers are sent by the member in response to the request, where each offer
from each merchant
includes an incentive to the member that obligates the merchant to make a
donation to an
CA 3102709 2020-12-11
Docket No. 107US
affinity entity of the member's choice, where the affinity entity also has a
physical presence
in the member's community;
[0017] FIGS. 3a and 3b illustrate screen shots characterizing exemplary user
interfaces (UIs)
for a merchant and a member, respectively, to designate one or more affinity
entities to whom
contributions by the merchant are to be made incident to each transaction
there between,
where each merchant or customer specified affinity entity provides goods or
services to a
community in common to both the merchant and the customer;
[0018] FIG. 4 is a flowchart illustrating an exemplary process by which a
member requests
offers from merchants in the member's community to supply goods and/or
services to the
member at specified a date and time, where offers are sent to the member in
response to the
request, where each offer includes an incentive from the merchant to the
member to make an
audited donation to an affinity entity of the member's choice, and where the
affinity entity is
associated with the member's community;
[0019] FIG. 5 illustrates an exemplary system in which the processes of FIGS.
1, 2, 4 and 6
may be performed by use of and access to an acquired account payment
processing system,
where the system provides functionality for processing transactions conducted
by merchants
with customers who are members, wherein, for each transaction, there is a
provision of a
service or good by the merchant to the customer for the transaction, where the
customer pays
for the service or good by conducting a transaction on an account issued to
the customer, and
there is an affinity entity, selected by the customer, to which a contribution
is made by the
merchant as a condition of the transaction;
[0020] FIG. 6 is a flowchart illustrating an exemplary process by which a
transaction in
which goods and/or services are provided at a predetermined date, time, and
place by a
merchant to a customer obligates the merchant to make an audited donation to
an affinity
entity selected by the customer, where the merchant, customer and affinity
have a community
in common;
[0021] FIG. 7 illustrates an exemplary open loop payments processing system in
which the
processes of FIGS. 1, 2, 4 and 6 can be performed, where the system processes
transactions
conducted by merchants with account holders, wherein, for each transaction,
there is a
provision of a service and/or good by the merchant to the account holder for
the transaction
which is conducted on an account issued to the account holder by an issuer,
there is an
authorizing and remunerating of an electronic payment by the account holder in
conducting
the transaction on the account with the merchant, and there are one or more
charitable
contributions by the merchant that are made to respective affinity entities
selected by the
account holder incident to the transaction;
6
CA 3102709 2020-12-11
Docket No. 107US
[0022] FIG. 8 illustrates exemplary systems housed within an interchange
center to provide
online and offline transaction processing for transactions conducted using the
open loop
payments processing system illustrated in FIG. 7; and
[0023] FIG. 9 illustrates further exemplary details of the systems illustrated
in FIG. 8.
[0024] FIGS. 10 to 13 illustrates other exemplary systems in which the
processes of FIGS. 1,
2, 4 and 6 may be performed by use of and access to an acquired account
payment processing
system.
[0025] FIG. 14 illustrates an example flowchart of a method according to
embodiments
described herein.
[0026] Implementations will become more apparent from the detailed description
set forth
below when taken in conjunction with the drawings.
DETAILED DESCRIPTION
[0027] The embodiments of the systems and methods described herein may be
implemented
in hardware or software, or a combination of both. These embodiments may be
implemented
in computer programs executing on programmable computers, each computer
including at
least one processor, a data storage system (including volatile memory or non-
volatile memory
or other data storage elements or a combination thereof), and at least one
communication
interface. For example, and without limitation, the various programmable
computers may be a
server, network appliance, set-top box, embedded device, computer expansion
module,
personal computer, laptop, personal data assistant, cellular telephone,
smartphone device,
IJMPC tablets and wireless hypermedia device or any other computing device
capable of
being configured to carry out the methods described herein.
[0028] Program code is applied to input data to perthrin the functions
described herein and to
generate output information. The output information is applied to one or more
output devices,
in known fashion. In some embodiments, the communication interface may be a
network
communication interface. In embodiments in which elements of the invention are
combined,
the communication interface may be a software communication interface, such as
those for
inter-process communication. In still other embodiments, there may be a
combination of
communication interfaces implemented as hardware, software, and combination
thereof
[0029] Each program may be implemented in a high level procedural or object
oriented
programming or scripting language, or a combination thereof to communicate
with a
computer system. However, alternatively the programs may be implemented in
assembly or
machine language, if desired. The language may be a compiled or interpreted
language. Each
such computer program may be stored on a storage media or a device (e.g., ROM,
magnetic
disk, optical disc), readable by a general or special purpose programmable
computer, for
7
CA 3102709 2020-12-11
Docket No. 107US
configuring and operating the computer when the storage media or device is
read by the
computer to perform the procedures described herein. Embodiments of the system
may also be
considered to be implemented as a non-transitory computer-readable storage
medium,
configured with a computer program, where the storage medium so configured
causes a
computer to operate in a specific and predefined manner to perform the
functions described
herein.
[0030] Furthermore, the systems and methods of the described embodiments are
capable of
being distributed in a computer program product including a physical, non-
transitory computer
readable medium that bears computer usable instructions for one or more
processors. The
medium may be provided in various forms, including one or more diskettes,
compact disks,
tapes, chips, magnetic and electronic storage media, volatile memory, non-
volatile memory
and the like. Non-transitory computer-readable media may include all computer-
readable
media, with the exception being a transitory, propagating signal. The term non-
transitory is
not intended to exclude computer readable media such as primary memory,
volatile memory,
RAM and so on, where the data stored thereon may only be temporarily stored.
The computer
usable instructions may also be in various forms, including compiled and non-
compiled code.
[0031] Throughout the following discussion, numerous references will be made
regarding
servers, services, interfaces, portals, platforms, or other systems formed
from computing
devices. It should be appreciated that the use of such terms is deemed to
represent one or more
computing devices having at least one processor configured to execute software
instructions
stored on a computer readable tangible, non-transitory medium. For example, a
server can
include one or more computers operating as a web server, database server, or
other type of
computer server in a manner to fulfill described roles, responsibilities, or
functions. One
should further appreciate the disclosed computer-based algorithms, processes,
methods, or
other types of instruction sets can be embodied as a computer program product
comprising a
non-transitory, tangible computer readable media storing the instructions that
cause a
processor to execute the disclosed steps. One should appreciate that the
systems and methods
described herein may involve the execution of transaction and transfer of
value between
merchants and consumers to provide economic and commercial benefits. One
should
appreciate that the systems and methods described herein may involve
particular configuration
of computer hardware components to provide incentives to consumers and
transfer value
between consumers, merchants, card issuers, and affinity entities. One should
appreciate that
the systems and methods described herein may involve an interconnected network
of
computer hardware for transferring electronic data signals and executing
transactions.
8
CA 3102709 2020-12-11
Docket No. 107US
[0032] The following discussion provides many example embodiments of the
inventive
subject matter. Although each embodiment represents a single combination of
inventive
elements, the inventive subject matter is considered to include all possible
combinations of the
disclosed elements. Thus, if one embodiment comprises elements A, B, and C,
and a second
embodiment comprises elements B and D, then the inventive subject matter is
also considered
to include other remaining combinations of A, B, C, or D, even if not
explicitly disclosed.
[0033] As used herein, and unless the context dictates otherwise, the term
"coupled to" is
intended to include both direct coupling (in which two elements that are
coupled to each other
contact each other) and indirect coupling (in which at least one additional
element is located
between the two elements). Therefore, the terms "coupled to" and "coupled
with" are used
synonymously.
[0034] Referring now to FIG. 1, a method 100 includes steps 102-128 in which
network
communications are conducted between a member of a loyalty system, a plurality
of -
merchants, and an Internet Server Hardware System. At step 102, a process
begins in which
the member requests offers from merchants in the member's community. The
request 106 by
the member is for a carpet cleaning service to clean three rooms between the
hours of 2:30 PM
and 5:00 PM on Thursday, December 31, 2020. The request 106 is transmitted
from a web
access device to the Internet Server Hardware System.
[0035] At step 108, the Internet Server Hardware System accesses one or more
databases to
identify merchants in member's community that are eligible to provide
requested carpet
cleaning service at the specified date and time. Retrieved information will
determine those
merchant that perform carpet cleaning services, and will also offer the member
an incentive
such that the offer from the merchant will also agree to make a donation to a
community
charity of the member's choice, which choice is identified and its eligibility
determined from
information accessed and retrieved from the one or more databases.
[0036] At step 110, the Internet Server Hardware System sends the member's
request to the
merchants identified at step 108. A deadline may be used to ensure timely
response to the
member's request.
[0037] At step 112, the Internet Server Hardware System receives eligible
offers for the
requested carpet cleaning service from identified merchants, where each offer
includes a
monetary amount corresponding to a merchant-defined donation to member's
charity. Each
offer must be received by a deadline to ensure timely response to the member's
request.
[0038] At step 114, the Internet Server Hardware System assembles a data
payload with
eligible merchant offers. The data payload may include, for each merchant,
merchant-
provided information such the merchant's webpage and a description of the
merchant's
9
CA 3102709 2020-12-11
Docket No. 107US
business. This information can also include crowd-sourced information about
the merchant
such as member reviews and ratings with respect to price, quality,
responsiveness, punctuality,
and professionalism. Optionally, this information may also include a
calculation of an average
rating from the crowd-sourced ratings as given to the merchant from other
transacting
members. The date payload in thereafter transmitted by the Internet Server
Hardware System
to member's logical address by a deadline to ensure timely response to the
member's request.
[0039] At step 116, the member receives the response to the member's request
offers, where
each offer from a merchant in the member's community. In particular, the
response includes
the assembled data payload. The member can then compare each merchant's offer
and can
optionally select one such offer based upon the monetary amount that the
merchant is willing
to donate to the community charity of the member's choice. The member
thereafter sends an
acceptance of the selected eligible merchant offer to the Internet Server
Hardware System by
deadline to ensure a timely response to the member's acceptance.
[0040] At step 118, the Internet Server Hardware System receives the member's
acceptance
of one of the merchant's offers and then sends notice to the selected merchant
by deadline to
ensure a timely confirmation of the offer with the selected merchant.
[0041] At step 120, the member receives the confirmation of the member's
selected offer.
The confirmation is sent by a deadline to ensure timely communications with
the member.
[0042] At step 122, the Internet Server Hardware System receives data
corresponding to a
transaction that has been conducted between the member and the selected
merchant for the
carpet cleaning service, where the transaction corresponds to offer selected
the member.
[0043] At step 124, the Internet Server Hardware System sends the member a
survey
requesting a review of the selected merchant's performance of the accepted
offer, such as a
review and/or rating with respect to price, quality, responsiveness,
punctuality, and
professionalism. The survey may also include an additional incentive such
that, when the
completed survey is received back from the member, the member's community
charity of
choice will receive an additional donation.
[0044] At step 126, the member receives, completes, and returns the survey to
the Internet
Server Hardware System by a deadline to ensure a timely review of the
performance of the
offer by the selected merchant.
[0045] At step 128, the Internet Server Hardware System received the completed
survey and
forwards data from the completed survey to the selected merchant by a deadline
to ensure the
merchant's timely review of its performance of the offer to the member.
[0046] Referring now to FIG. 2, an environment 200 is depicted for a global
acquired
account payment processing system 205, as shown. Environment 200 includes a
member who
CA 3102709 2020-12-11
Docket No. 107US
is a resident of a community and operates a web access device that can
receives a request for
offers from merchants in the community to provide goods and/or services to the
member.
Each request includes a requirement that the requested goods and/or services
be provided at a
specific date and time, and that the offer also include a donation by the
merchant to a
community charity of the member's choice. Stated otherwise, the member
solicits offers from
a plurality of merchants each having a physical presence in the community
where the member
resides. Each such request offer must include terms and conditions that
obligate the merchant-
offeror to make a donation to a local affinity entity of the member's choice
if the member
conducts a timely financial transaction corresponding to the merchant's offer.
As such, the
member, as a community resident, is incentivized to buy from the merchant by
the merchant's
agreement to make a donation to an affinity entity also located in and
providing goods and/or
services to the local community where the member resides.
[0047] By way of example, the affinity entity may be a charitable organization
that provides
a good and/or service to residents of the community in which both the member
and merchant
residence --such as by their common geographic location. This affinity entity
may provide
food and clothing to needy families in their common community. This affinity
entity may
provide teaching and demonstrations of entrepreneurial skills to community's
unemployed.
Another affinity entity may provide venues where sports education can be
provided to local
competing teenagers. Yet another affinity entity may provide care and feeding
to abandoned
pets. The affinity entity may also cultivate good citizenship and public
policy. An affinity
entity may be either a for-profit or non-profit organization providing a good
or a service to a
local community to which both merchants and customers in the same community
have an
affinity, by their common location, to advance and/or promote.
[0048] Within environment 200, the community resident sends the request for
offers to an
Internet Server Hardware System. Responsive to the member's request as
received by a
Donation Audit Web Service 214, an Offer Group (e.g., a group of different
offers from
different merchants in the community) is transmitted back to the requesting
member.
[0049] Each merchant's offer in the Offer Group may identify the affinity
entity to whom the
merchant-offer will make a donation to an affinity entity. To identify the
affinity entity, the
member' ID may be transmitted in the request as received by a Donation Audit
Web Service
214, which may look up the community where the member and where the merchant-
offer has
a physical presence and/or a brick and mortar store. Alternatively or
additionally, the user web
access device may have a location detection mechanism to provide a current
location of the
member. The member's location may be used to generate an Offer Group of
offer's close or
11
CA 3102709 2020-12-11
Docket No. 107US
proximate to the member's location. Alternatively, the affinity entity may
have been pre-
designed by the member and/or included in the member's request for offers.
[0050] As shown by steps 204-212, Donation Audit Web Service 214 uses metadata
included
with the transmissions of the commands received from the member's web access
device to
determine whether the merchant and its customer have the same local community.
By way of
example, meta data in the transmission can include an identifier for the
customer, and a
database of merchants and their respective merchant-offers can include
geographic location
information. This geographic location information will be matched against
which the
geographic location information for the residence of the member. Merchant and
member
identifiers can be assigned to the merchant and its customer during or prior
to any transaction,
such as when each are registered with or otherwise sign up for participation
with the Donation
Audit Web Service 214. This registration process will include the collection
of physical and
logical addresses for each. Alternatively or additionally, merchant profiles
may be associated
with one or more geographic locations that may be compared to the member's
current location
or route to determine offers for merchants that are close or proximate to the
user. As will be
described herein, offers may be recommended based on attributes of the member,
historical
data regarding the member, and so on.
[0051] Once physical address information the merchant-offeror and its
potential customer
(e.g., member) is known, the local community of each of the merchant and its
customer can be
determined. The local community determination can be made on any of several
different
methods, or combinations thereof. Once such method is political in that the
merchant's place
of business is determined to be in the same political or legal division as
that of its customer's
residence, such as the same province, state, county, prefecture, city, city-
state, borough, etc.
Another such comparison can be whether the merchant's place of business has a
governmentally issued postal code that is the same or within a predetermined
proximity as that
of its customer's residence.
[0052] Yet another such comparison can be whether the merchant's place of
business and its
customer's residence are physically proximate within a predetermined factor by
any of a
variety of measures or combinations thereof. For example, latitude and
longitude coordinates
might be known for both the merchants place of business and the residence of
its customer (or
the location of the smart phone). These coordinates can be used to determine
whether the
linear distance there between is within a predetermined distance to ascertain
whether or not
the merchant and its customer share the same local community.
[0053] Alternatively, a navigation algorithm, using any of various different
travel methods
(e.g., walking, automobile, bicycle, mass transit, etc.), may be used to
determine whether the
12
CA 3102709 2020-12-11
Docket No. 107US
time, using one or more travel methods, is within a predetermined time limit
to ascertain
whether or not the merchant and its customer share the same local community.
By way of
example the merchant and its customer might be determined to be within the
same local
community if the automobile drive time, as determined from one or more
databases of
contemporary cartographic road system information, to navigate between the
merchant's brick
and mortar store and the customer's residence is less than a predetermined
time threshold (e.g.,
17 minutes).
[0054] A further alternative implementation may identify the population
density of both the
merchant's brick and mortar store and the customer's residence. If the
population density
.exceeds a predetermined density, then the merchant and its customer might be
determined to
be within the same local community if the time to walk, bicycle or take public
transportation
between the merchant's brick and mortar store and the customer's residence, as
determined
from one or more databases of contemporary topographic, mass transit, and/or
pedestrian
cartographic system information, is less than a predetermined time threshold
(e.g., 55
minutes).
[0055] Still another such comparison can be whether the merchants place of
business and its
customer's residence are proximate according to voting, electoral, or
political districts. The
district use can be determined by an official method, an unofficial method, or
a combination
of method. By way of example, measurements known within the political
gerrymander
sciences can be used, including but not limited to a minimum district to
convex polygon ratio,
shortest split line algorithm, minimum isoperimetric quotient, etc.
[0056] The local community corresponding to that of the merchant and its
customer, and
separations there between (if any), can be determined from any combination of
linear distance,
mode-specific navigational transportation travel time, political separation,
postal designation,
and/or hybrid algorithm that takes into considers geographic barrier features
such as rivers,
cliffs, and highways, cultural features such as boundaries of identified
people groups (e.g.,
tribes, first nation people, etc.), land ownership such as subdivisions,
housing projects,
cooperatives, planned communities, military installations, governmental owns
and leased
properties, etc. Given the foregoing, a community module (of e.g. donation
utility 26 of FIG.
10) might determine that the merchant and its customer are members of the same
community,
not members of the same community, or are both members of more than one of the
same
communities as determined by the algorithm.
[0057] Similar or different techniques may be used to determine the respective
local
community of the merchant and its customer can also be used to determine the
local
community of an affinity entity such as that shown on FIG. 2 at reference
numeral 224, or as
13
CA 3102709 2020-12-11
Docket No. 107US
that shown as an Affinity Entity (k) 596 in FIG. 5, or as shown by Affinity
Entity (k) 796 in
FIG. 7, each of which is discussed herein below. An Affinity Entity may be
associated with an
affinity system 60 (FIG. 11) to connect to the environment 200.
[0058] If the local community of the merchant, its customer/member, and an
affinity entity
that has been selected by the member are the same, then the business rule
selected by the
merchant may determine the amount of the donation that the merchant will make
to the
affinity entity selected the customer. In some implementations, the affinity
entity to whom a
merchant is to make a donation may only be selected by the customer, and not
the merchant.
In such implementations, tensions between the goals or purposed of an affinity
entity, if any,
between merchant and customer may be reduced by allowing the identity of the
affinity entity
to be unknown to the merchant while being selected by the customer. As such,
the merchant
may need not be told or be given any notice, directly or indirectly, as to the
identity of the
affinity, entity selected the customer with whom the merchant is conducting a
transaction.
Rather, the merchant may be told or be given notice to make a single payment
of, or period
payments to, a single affinity entity that may thereafter make respective
disbursements for all
registered merchants accordingly to those affinity entities that had been
selected by those
customers with whom those merchants had conducted transactions. A merchant
who, by force
of reason or conscience, does not want to make a donation to a particular
affinity entity need
not do so directly, as any and all merchant donations are made blindly through
the single
affinity entity that make all disbursements to all affinity entities (via e.g.
affinity system 60 of
FIG. 11). Accordingly, each merchant may have notice of its total periodic
donations without
knowing the identity of the intended recipients, thereby leaving direction of
donations fully
within the discretion of the merchant's customers, limited only by the
restriction that the
merchant's donation must be made to an affinity entity serving the local
community of both
the merchant and its customer, while leaving the actual amount of the
merchant's donation
fully within the discretion of the merchant.
[0059] Referring again to FIG. 2, Donation Audit Web Service 214 may use
respective
identifiers for the merchant and its customer to access and retrieve
geographic information for
each, then applies an algorithm to the retrieved geographic information to
determine the
respective local communities of the merchant and its customer, as discussed
above.
Alternatively or additionally, Donation Audit Web Service 214 may obtain a
current location
for a user via location detection module on the user's web access device (e.g.
GPS, Wi-Fi,
satellite, etc.). As shown in FIG. 2, the local community may be progressively
granular in
nature, such as first the United States of America as shown at reference
numeral 204, then the
state of New York as shown at reference numeral 206, then the portion of New
York called
14
CA 3102709 2020-12-11
Docket No. 107US
"Long Island" as shown at reference numeral 208, then the county of Nassau
shown at
reference numeral 210a, then a portion of the Nassau County called North
Hempstead as
shown at reference numeral 210b, and then the specific geographic location of
"Port
Washington" as shown at reference numeral 210c. This final level of geographic
granularity
indicates a community in which both merchant and customer are members,
neighbors,
residents, and/or the like.
[0060] The final level of geographic granularity may be used to perform a look-
up against
one or more databases to which Donation Audit Web Service 214 has access. This
access and
lookup may be used by Donation Audit Web Service 214 to identify: (i) the
affinity entity or
charity for that community which, as shown at reference numeral 212, is the
Port Washington
Food Bank, has been specified by the customer; and (ii) the respective
identifier of the
merchant's business rule (and/or the customer's business rule) that is to be
used to make a
calculation of the donation that the merchant to make to the affinity entity
or charity for that
community. The business rule(s) that may be used with the currency amount of
the customers
payment to calculate the donation that is to be made by the merchant to the
affinity entity or
charity for that community. Note that the donation may be directed to a
plurality of affinity
entities for the local community according to directions that had been
previously specified by
the customer (and distributed via affinity system 60 of FIG. 11). For example,
the customer
may have specified that each merchant donation is to be split evenly, or in
specified portions,
between five (5) local community affinity entities, for example: (i) a local
youth sports team
cooperative; (ii) a local charter junior high school; (iii) a local house of
worship; (iv) a local
political party; and (v) a local for-profit college specializing business
entrepreneurialism.
[0061] Given the foregoing, an affinity entity may be assigned to each
merchant-offer in the
Offer Group made by each merchant. The Offer Group may also be generated based
on one or
more recommendations from e.g. recommendation engine 30 (FIG. 10) based on
user
attributes, historical data regarding user, merchant trends (e.g. off-peak
time, slow sales) and
so on.
[0062] At step 216, various processes are facilitated by the Internet Service
Hardware System
and web access device of the member and merchants in the member's community.
These
processes include: (A) The sending by the member of the request for the time
slot specific
geo-fenced offers from community merchants, which offers will each include a
incented
donation, as described herein, by a charity that is also located in the
member's community;
(B) the sending of the member's request to identified eligible merchants; (C)
the receiving of
eligible offers from the identified eligible merchants; (D) an assembling and
sending of a data
payload corresponding to the eligible offers from the identified eligible
merchants to the
CA 3102709 2020-12-11
Docket No. 107US
requesting member; (E) the receiving back the member's selection of one of the
eligible offers
from the identified eligible merchants; (F): the receiving of transaction data
corresponding to
the performance of the member's selected offer by the corresponding community
merchant;
and (G) the sending and receiving of the post-performance transaction
corresponding to the
member's selected offer. The completed survey will include the member' review
of the
transaction on an account issued by an issuer to the member to pay for the
transaction and buy
the goods and/services 218 received by the member.
[0063] Note that terms and conditions of the transaction offer may differ from
that of the
accepted offer presented by the community resident at the local merchant's
brick and mortar
store. As such, the merchant's offer to donate may not be specific to a
particular good or
service, but rather may be specific to the entire transaction between the
merchant and its
customer. By way of example as to this type of offer specificity, the offer
may obligate the
merchant to make a donation of a certain percentage of the entire currency
amount of
transaction, or the offer may obligate the merchant to make a donation only if
the transaction
is conducted at a certain time of day or on a particular day of the week, or a
combination of
the foregoing. Although some terms of the offer may differ from some tenns of
the subsequent
transaction between the merchant and its customer, nevertheless, the
merchant's offer to make
a donation to a local affinity entity (e.g., a local charity) fundamentally
provided an incentive
that caused, at least in part, the local community resident to navigate to the
local merchant's
brick and mortar store, come into the store, and ultimately conduct a
transaction that brought
revenue to the local merchant. Advantageously, the absence of specificity in
the offer as to a
particular good or service allow many implementations to operate without
modification to the
merchant's input of data about the transaction at a Point of Service terminal
(POS) seen at
reference numeral 220, without modifications to the POS 220 itself, and
without modifications
to software executing on POS 220.
[0064] The merchant inputs data about the transaction into a Point of Service
terminal (POS)
seen at reference numeral 220. The POS, for example, can be a cash register or
a web enable
mobile device (e.g., a tablet computing device). The POS may be integrally
part of a merchant
computing system 40 (FIG. 10) or connected thereto. The .POS 220 transmits the
input data to
an Acquired Account Payment Processing System (z) 105. The Acquired Account
Payment
Processing System (z) 105 sends a signal, as shown at reference numeral 222,
to Donation
Audit Web Service 214 indicating that a transaction on the community
resident's account was
approved for being conducted by the community resident with the merchant whose
offer was
selected by the community residence. Optionally, the data input into POS 210
can include
additional monies received from the customer by the merchant that are also to
be donated, via
16
CA 3102709 2020-12-11
Docket No. 107US
the merchant, to the affinity entity or charity for that community. Upon
receipt of the signal, a
donation to the community affinity entity by the user's selected merchant may
be calculated
according terms and conditions specified by the merchant.
[0065] The Donation Audit Web Service 214 may retain the derived donation for
subsequent
audit purposes to insure compliance by each community merchant in its donation
commitments to each of the one or more affinity entities or charities for each
community that
the merchant and/or its customers is a member. The Donation Audit Web Service
214 also
may transmit a message containing notice of a donation, or the particularly
derived donation,
for the customer's transaction, as shown at reference numerals 224, 226, and
228, respectively
to logical addresses of the affinity entity or charity for that community, the
community
resident and the merchant.
[0066] Referring now to FIGS. 3a-3b and 5, a screen shot 302 features input
and displays
fields by which a Merchant (m) 510, or agent thereof; can input terms and
conditions under
which the Merchant (in) 510 is willing to become obligated to make a donation
to an Affinity
Entity (k) 596.
[0067] At the top of screen shot 302, identifiers corresponding to the
Merchant (m) 510 as
shown, including a merchant identifier, a merchant community identifier, and
an identifier for
the goods and/or services that the merchant can provide in offers to members
of the
merchant's community.
[0068] Each row in screen shot 302 represent all or a portion of twenty-four
(24) hour day of
the 356 calendar days of one (1) year. Columns in each row of the table seen
in screen shot
302 are, from left to right, as follows: 1st: the numerical calendar day of
the year; 2nd-3rd: the
hyphenated starting and ending of a time period within the calendar day; 4th:
a percentage of a
currency amount of any one (1) transaction that the Merchant (m) 510 may
commit to make to
an Affinity Entity (k) 596; 5th: the minimum currency amount of the
transaction before the
commitment by the Merchant (m) 510 to make the donation will arise; 6th: the
maximum
amount of donation that the Merchant (m) 510 may be willing to make for any
one (1)
transaction; and 7th: an identifier for the Affinity Entity (k) 596 to whom
the Merchant (m)
510 may make the donation as described in the row.
[0069] The bottom of screen shot 302 allows specification inputs for the
Merchant (in) 510 as
to its maximum donation across all Affinity Entities 596 for any one day,
month, quarter of a
year, or year.
[0070] By way of example, and not by way of limitation, the data input by the
Merchant (m)
510, or agent thereof, for display on screen shot 302 may obligate a donation
to be made to an
affinity entity that is higher at some days and times of the calendar year,
and lower at other
17
CA 3102709 2020-12-11
Docket No. 107US
days and times of the calendar year. As such, it may be advantageous for the
Merchant (m)
510 to provide a higher donation incentive for typical slow business calendar
days and a lower
donation incentive for typically busier business calendar days. These are
examples of
merchant trends that me be used to generate or recommend offers or incentives
for Offer
Group.
100711 Data input in the user interface depicted by screen shot 302 may be
stored in one or
more of the Merchant DBs 580, data storage device 50 (FIG. 10) or other
location logically
accessible, via one or more networks or otherwise, to Donation Audit Web
Service 514. These
data can also be automatically pre-loaded for Merchant (m) 510 via an
automatic initiating
service (e.g., an data auto-boarding operation) that allows the Merchant (m)
510 to be
automatically entered as a participant in a local community charitable
donation program that is
incentivizes increased local resident foot traffic each store location of the
Merchant (m) 510 in
the local community.
[0072] As seen in FIG. 3a, each offer input by the merchant to make a donation
to a local
affinity entity is not be specific to a particular good or service that the
merchant will provide
to its customer in a transaction. Rather, the offer is specific to the entire
transaction between
the merchant and its customer. By way of example as to this type of offer
specificity, the offer
may obligate the merchant to make a donation of a certain percentage of the
entire currency
amount of transaction, or the offer may obligate the merchant to make a
donation only if the
transaction is conducted at a certain time of day or on a particular day of
the week, or a
combination of the foregoing. Although some terms of the offer may differ from
some terms
of the transaction, nevertheless, the merchant's offer to make a donation to a
local affinity
entity (e.g., a local charity) has the goal of fundamentally providing an
incentive that causes,
at least in part, the local community resident to navigate to the local
merchant's brick and
mortar store as new foot traffic, and ultimately to conduct a transaction that
brings revenue to
the brick and mortar store of the local merchant.
[0073] Referring now to FIG. 3b, a screen shot 304 features input and displays
fields by
which an Account Holder (p) 508, or agent thereof, can direct a third party
donor, such as a
Merchant (m) 510 with whom the Account Holder (p) 508 is conducting a
transaction, to be
obligated to make a donation to an Affinity Entity (k) 596. The fields
provided by screen shot
302 allow the customer to specify one or more affinity entities in their local
community to
which donations are to be made by merchants with whom the customer conducts
transactions.
In such implementations, each merchant is given notice of its total periodic
donations. Such
notice, however, can optionally be given without providing the merchant with
any notice or
knowledge as to the specific identity of those affinity entities that are to
be the recipients of its
18
CA 3102709 2020-12-11
Docket No. 107US
donations. The donation mechanism can be set up such that the merchant makes
blind
donations, either directly or indirectly, to affinity entities in the local
community of both the
merchant and its customer who selects those local community affinity entities.
Accordingly,
the donation mechanism may leave direction of merchant's donations fully
within the
discretion of the merchant's customers, limited only by the restriction that
the customer can
only select from among those affinity entities that serve the local community
that is in
common to both the merchant and the customer, while leaving the actual amount
of the
merchant's donation fully within the discretion of the merchant as shown in
FIG. 3a.
[0074] Optionally, a further limitation on those local community affinity
entities that may be
selected by the customer may include control logic that accesses a rating,
and/or that derives a
rating, for an affinity entity. The control logic may use one or more ratings
given by one or
more charity rating organizations, where the control logic result is used to
determine whether
or not the affinity entity is eligible for participation in the implementation
as a registered
affinity entity that is selectable by local community customers. This may be
used by
recommendation module 30 (FIG. 10) to generate the Offer Group and the
affinity entities
associated with the various merchants and offers. The ratings may be retrieved
by Donation
Web Service 214 by its access to one or more databases (e.g. data storage
device 50 of FIG.
10) where such ratings are input and maintained. Example of charity rating
organizations
which provide one or more ratings that could be used for various disclosed
implementations
include Guide Star, Charity Navigator, Give Well, Evangelical Council for
Financial
Accountability (ECFA), the Better Business Bureau Wise Giving Alliance
Standards for
Charity Accountability of the Council of Better Business Bureaus, Inc., and
the like that now
exist or may exist in the further. Moreover, other mechanisms for assessing
local community
affinity entities may be used to determine whether or not affinity entities
are eligible for
participation in the disclosed implementations as registered affinity entities
that are selectable
by local community customers and/or local merchants.
[0075] Each row in screen shot 304 of FIG. 3b may represent a different
Affinity Entity (k)
596 in the local community of the customer for which there is a specific code
(e.g., 999(i)(j),
Community Identifier (e.g., ZZZ999), and Affinity Name as shown in FIG. 3b. A
pull down
menu of selectable affinity entities (not shown) can be used to provide
selectable input to the
fields corresponding to affinity' entities shown on screen shot 304.
[0076] By way of example, the Affinity Entity and/or the Community 11.) might
identify a
specific Affinity Entity (k) 596 that is located in, and provide goods and
services to, the
borough of Greenwich Village at the southern portion of the geographical
island of Manhattan
in the city of New York of the State of New York, in the USA. By way of
example, and not by'
19
CA 3102709 2020-12-11
Docket No. 107US
way of limitation, the Affinity Entity Code 105(064) (q2e) could have an
interpretation where
'105' represents the United States of America, the index '064' represents the
state of New
York, "q" represents the City of New York, "2" represents the combined
boroughs of
Manhattan, and "e" represents the borough of Greenwich Village at the southern
portion of the
geographical island of Manhattan in the city of New York of the State of New
York. The
name of the specific Affinity Entity (k) 596 represented the code 105(064)
(q2e) can be the
Washington Square Food Bank, which may be located in, and provide goods and
services to,
the borough of Greenwich Village at the southern portion of the geographical
island of
Manhattan in the city of New York of the State of New York, in the USA. Note
that the
Account Holder (p) 508 can use screen shot 302 to specify multiple community
Ds each
representing a geographic location where the Account Holder (p) 508 either has
a residence or
operates a business in the geographic location. Also note that, for each such
community ID
specified by the Account Holder (p) 508, the second column of the rows of
screen shot 304 in
FIG. 3b may add up to 100%, thereby provide a percentage the donation made by
the
Merchant (m) 510 with whom the Account Holder (p) 508 conducting a
transaction.
100771 For screen shots 302-304, input and selection of data for each Affinity
Entity may be
via a typical user experience including but not limited to keyboard data
entry, pull down
menus, pictograph optical scanning with a cellular telephony device as read
from print or
electronic media rendering, etc. Horizontal 318 and vertical 320 panning can
be user activated
to move that portion of the display being rendered horizontally and
vertically, respectively.
The data may be stored in data storage device 50 (FIG. 10)
[0078] The Account Holder (p) 508 and the Merchant (m) 510 may change or
disable a
donation commitment at any time by accessing a server that serves web pages
rendering
screen shots 302, 304, respectively. Thus, charitable donation commitments can
be easily and
instantly, and both enabled or disabled, using the real time user interface.
By way of example,
and not by way of limitation, one or more of such servers may be hosted by the
Donation
Audit Web Service 514 seen in FIG. 5.
[0079] Referring now to FIGS. 4-5, a Method 400 is illustrated by the
flowchart shown in
FIG. 4. Reference may also be made to FIGS. 10-14 and system components
thereof which
may be used to implement Method 400. Method 400 allow a member's web access
device to
request offers from merchant's in the member's community to supply goods
and/or service
within a specified time period.
[0080] At step 402 of Method 400, an account holder identifier is received and
along with a
request for offers from a member who is the account holder and corresponds to
the account
holder identifier. The request is for offers from a plurality of merchants,
where each said offer
CA 3102709 2020-12-11
Docket No. 107US
from each said merchant is to: (i) supply a good and/or service to the account
holder at a
specific time; and (ii) the merchant to make a monetary donation to a
community charity of
the member's choice.
[0081] At step 404 of Method 400, access is established for the retrieving of
information
from one or more databases, using the account holder identifier and the
request for offers, to
retrieve:
for the account holder: (i) a physical address; and (ii) an identifier for a
charitable entity
designed by the account holder to which the monetary donation is to be made.
Thereafter the
retrieved information is used to derive, using the geographic address for the
account holder
and the request for offers, merchant identifiers for each of a plurality of
merchants, wherein
each of the merchants: (i) is associated with information in the one or more
databases
confirming that the merchant will accept a request for an offer to supply the
good and/or
service; and (ii) has a physical address from which a travel time at the
specific time to the
physical address for the account holder does not excel a first predetermined
time threshold.
The travel time takes into consideration historical real time traffic
conditions for each of one
or more routes via one or more transportation modes between the respective
physical
addresses of the merchant and the account holder
[0082] At step 406 of Method 400, a transmission of the member's request is
made at a time
that does not exceed a predetermined time threshold from the time of the
receipt of the
request. The transmission of the member's request is sent to a logical address
corresponding to
each merchant in the plurality of merchants identified in step 404.
[0083] At step 408 of Method 400, offers are received back from the plurality
of merchants
within a time that does not exceed a predetermined time threshold from the
time of the receipt
of the request.
[0084] At step 410 of Method 400, the received offers are transmitted to a
logical address
corresponding to the account holder, the transmission occurs at a time that
does not exceed a
predetermined time threshold from the time of the receipt of the request.
[0085] At step 412 of Method 400, data is received from the account holder,
which data
includes a selection of one of said received offers. The selection of the
offer must be received
before the expiration of a time that does not exceed a predetermined time
threshold from the
time of the receipt of the request.
[0086] At step 414 of Method 400, an acknowledgement is received of: (i) an
authorization
request for a transaction between the account holder and the merchant
corresponding to the
selection of one of said received offers; and (ii) an authorization response
to the authorization
request sent from the account issuer corresponding to the account holder to
the merchant
21
CA 3102709 2020-12-11
Docket No. 107US
acquirer corresponding to the selection of one of said received offers. Note
that the
acknowledgement must be received at a time that does not exceed a
predetermined time
threshold from the date and time that were specified in the offer that was
accepted by the
member.
[0087] At step 416 of Method 400, for each transaction for which the
authorization response
includes an indicator that the transaction has been authorized by the account
issuer
corresponding to the account holder, a message is transmits containing the
monetary donation
to be made to the charitable entity designed by the account holder by the
merchant
corresponding to the selection of the received offer by the account holder.
[0088] Method 400 receives information that confirms such a timely transaction
between the
customer and the merchant at step 416 by way of receiving information derived
from an
authorization response for the transaction. As more fully described herein
with respect to FIG.
7, the information in the authorization response may be typically generated by
an Issuer (j)
704 who issued an account to the Account Holder (p) 708 (e.g., the customer or
mobile device
user) on which the timely transaction with the Merchant (m) 710 was conducted.
A positive
authorization response reflects the Issuer (j) 704's approval of the
transaction on the account
issued to Account Holder (p) 708.
[0089] As shown in FIG. 5, Donation Audit Web Service 514 receives the
information that
was derived from the authorization response from Acquired Account Payment
Processing
System (z) 105, where each of the Issuer (j) 704, the Account Holder (p) 708,
and the
Merchant (in) 710 operate in Acquired Account Payment Processing System (z)
105.
[0090] Once confirmation has been received by Donation Audit Web Service 514
that a
timely transaction has taken place been the merchant in the 3rd set of
Merchant who made the
offer and the customer who selected and confirmed that offer, Method 400 moves
to step 418
where a calculation is made of an amount of a donation that is to be made by
the merchant-
offeror according to terms of the offer. By way of example, the terms of the
offer to make the
donation to the community Affinity Entity may have been previously input for
storage in
Merchant DBs 580 (at data storage device 50 or merchant system 40) by way of
the
merchant's user interface provided by an application executing on a computing
device, such as
in conjunction with a screen shot 302 seen in FIG. 3a as described above. To
give notice of the
donation obligation that now has arisen, the calculated donation can be sent
in one or more
transmissions from Donation Audit Web Service 514 to one or more logical
addresses such as:
(i) the Merchant in the third set who transacted with the customer; (ii) the
Affinity Entity
corresponding to the Residential Community. Optionally, information that
identifies the
Affinity Entity; and/or (iii) the Customer can be included in any such
transmission.
22
CA 3102709 2020-12-11
Docket No. 107US
[0091] Where the Affinity Entity to which the merchant is to obligated by the
timely
transaction to make a donation is specified by the customer, (e.g., such as by
use of a user
interface having a screen shot 304 seen in FIG. 3b as described above), the
identity of the
Affinity Entity need not be communicated to the merchant. Rather, the merchant
can make a
blind donation of the calculated amount to a third party for distribution to
the Affinity Entity
in the customer's residential community. By such blind, albeit obligatory,
donations, conflicts
and disagreements between customer and merchant as to right and proper objects
of charity to
the community can be avoided. As such, the customer may transact with
community
merchants by way of incentives from the community merchants that they will
donate to the
customer's favorite community charity (e.g., Affinity Entity), though the
charity may not be
the merchant's favorite charity, or even a desirable charity, in that
community. Nevertheless,
the merchant has received the benefit of a first set of customers' foot
traffic inside the local
brick and mortar store, as well as the benefit of a sub-set of the first set
of customers that also
conduct a transaction with the merchant, where each such benefit is realized
by the merchant's
offer to make a donation to the customer's favorite local charity(ies) if a
timely transaction
occurs subsequent to the offer.
[0092] After a predetermined audit time period, an audit can be made between
calculated
donations to community Affinity Entities that have been paid by the merchant
and that are as-
yet still unpaid. Notice regarding any calculations of the as-yet unpaid
donations may be
transmitted by the Donation Audit Web Service 514 to one or more logical
addresses such as:
(i) the Merchant in the 3rd set who transacted with the customer and has
outstanding
donations to community Affinity Entity(ies) in arrears; (ii) the Affinity
Entity corresponding
to the Residential Community to whom the merchant has outstanding donation(s)
payable, and
optionally information that identifies the Affinity Entity; and/or (iii) the
Customer to whom
the merchant made the obligation to make the community Affinity Entity
donation(s).
[0093] Referring now to FIG. 5, by way of explanation for the nomenclature of
reference
numerals used and described in the specification, a lower case letter in
parenthesis is intended
to mean an integer variable having a value from 1 to the capital case of the
lower case letter,
which value can be large (i.e., approaching infinity). Thus '(b)' is intended
to mean that the
integer 'b' can have a value from 1 to B, and '(c)' is intended to mean that
the integer 'c' can
have a value from 1 to C. etc. As such, drawing elements 505, 508a-c, 510, 576-
590 and 596
in FIG. 5 are illustrated with a block, but indicate that one or more elements
can be present.
For example, Affinity Entity (k) 596 is one of a possible plurality of
affinity entities, where k
may range from 1 to a large integer 'K'.
23
CA 3102709 2020-12-11
Docket No. 107US
[0094] The diagram of FIG. 5 depicts an exemplary environment 500 for
operation of
Acquired Account Payment Processing System (z) 505. Alternative environments
are shown
in FIGS. 7, 10 to 13. Although different references may be used to refer to
the various system
components, the components of FIG. 5 may relate to the components shown in
FIGS. 7, 10 to
13. Different system configurations may also be used, and the various system
configurations
shown in the Figures are illustrative examples.
[0095] In environment 500, an account holder (p) 508a uses a web access device
(q) 508b
and its Network Communication Carrier (r) 508 to request offers from local
merchants in the
Account Holder (p) 508a's residential community. The merchants may be
proximate to the
current location of the mobile device, or along a common route taken by the
mobile device
(e.g. route between home and office), or within a general area of the account
holders' home or
office, and so on.
[0096] Donation Audit Web Service 514, by use of information retrieved by
access to one or
more databases 578-596 (stored at e.g. data storage device 50), uses the
requested offers by
transmitting them over one or more of Network Communication Carriers (r) 508
for selection
from among the offers by Account Holder (p) 508a. The offers may be stored as
part of
merchant accounts 54, for example, or as separate accounts but linked to
merchants via a
merchant identifier, location identifier, and so on.
[0097] After Account Holder (p) 508a selects and confirms one or more such
offers, such as
described above with respect to Method 400 of FIG. 4, Account Holder (p) 508a
navigates to
the brick and mortar store of the selected merchant-offeror (Merchant (m) 510)
in the
residential community of Account Holder (p) 508a to conduct a financial
transaction with the
Merchant (m) 510. In some embodiments, a digital file containing the merchant
address or
directions may be transmitted to the web access device for provision to
account holder. The
digital file may be used by a navigation system to direct the account holder
to the merchant
store, for example.
[0098] The transaction may be conducted on an account issued by an issuer of
such accounts
within Acquired Account Payment Processing System (z) 105, or other such as
system as
provided by the environment 700 illustrated in FIG. 7. Confirmation of the
transaction may be
received by Donation Audit Web Service 514 from Acquired Account Payment
Processing
System (z) 105. This confirmation obligates Merchant (m) 510 to make a
donation to Affinity
Entity (k) 596 according to the terms and conditions of the offer made by
Merchant (m) 510
that was selected and confirmed by Account Holder (p) 508a. Stated otherwise,
the Account
Holder (p) 508a's financial transaction with the merchant (m) 510 may have
been incentivized
by the Merchant (m) 510's agreement to make a donation to an Affinity Entity
(k) 596 in their
24
CA 3102709 2020-12-11
Docket No. 107US
shared local community as provided by the offer that had been previously
specified by the
Merchant (m) 510 to the Account Holder (p) 508a.
[0099] To conduct the transaction that triggers the donation by merchant (m)
510 to Affinity
Entity (k) 596, as shown in FIG. 5, Account holder (p) 508 may present its
issued account to a
Merchant (m) 510 as tender for a financial transaction such as a purchase of
goods and/or
services. As part of the transaction, the Account Holder (p) 508a may offer a
physical or virtue
token bearing an identifier with which the Account Holder (p) 508 is
associated. The token
can be a credit, debit, pre-paid, or gift card. The token can also be a school
or government
identification card, social security number card, driver's license, credit
card, debit card,
prepaid card, cellular telephone number, etc. The token can be read by a
reader operated by
the Merchant (m) 510, which as a reader associated with a Point of Service
terminal (POS).
For example, the reader might read the identifier for the Account Holder (p)
508a from a
magnetic strip on a plastic card, a computer chip or computer readable medium
on a card, a
rendering on a display screen of a cellular telephone or Personal Digital
Assistant (PDA), a
Near Field Communication (NFC) transmission for a card (e.g., a Visa Pay Wave
card) or
from smart phone, etc.
[00100] Also shown in FIG. 5 are one or more affinity Entities (k) 596 and a
Donation Audit
Web Service 594 that may implement processes for the auditing of donations to
the one or
more Affinity Entities (k) 596 from various donors, for instance, the Merchant
(m) 510 and
the Account Holder (p). The Donation Audit Web Service 594 may have access to
information
resources within the following databases: one or more Account Holder Databases
(0 578,
where '(0' is an integer from 1 to 'F', that stores information about each
Account Holder (p)
508, one or more Merchant Databases (b) 580, where '(b)' is an integer from 1
to 'B', that
stores information about each Merchant (m) 510, one or more Transaction
Databases 582,
where '(a)' is an integer from 1 to 'A', that stores information about
transactions between each
Merchant (m) 510 and each Account holder (p) 508, and one or more Geographic
Databases
(c) 584, where '(c)' is an integer from 1 to 'C', that stores information
about local
communities with which the Account Holders 508 and the Merchants 510 and the
Affinity
Entities 596 can be associated through any of several different associations.
By way of
example, and not by way of limitation, construction of such associations
(e.g., local
communities) can include factors such as geographic, political, demographics,
local
transportation modes, navigational algorithms for geopolitical regions,
cartographic data,
planned communities, population density, cultural divides, racial population
constituencies,
census statistics, socio-economic factors, and combinations thereof.
CA 3102709 2020-12-11
Docket No. 107US
1001011Also seen in FIG. 5 are one or more Affinity Entity Databases 590,
where '(i)' is an
integer from 1 to 'I', to store information about each Affinity Entity (k)
596, one or more
Affinity Entity Donations Payable Databases 586, where '(d)' is an integer
from 1 to 'D', to
store information about currency amounts of donations that are obligations
that are to be paid
by specific donors to each Affinity Entity (k) 596, and one or more Affinity
Entity Donations
Paid Databases 588, where '(e)' is an integer from 1 to 'E', to store
information about
currency amounts of donations that have been made by donors to each Affinity
Entity (k) 596
from each Merchant (m) 510. Affinity Entity Databases may be stored at data
storage device
50 or at affinity system 60 (FIGS. 10 to 13), for example.
[00102] Databases 578-596 (e.g. at data storage device 50) can be connected by
one or more
private or public networks, virtual private networks, the Internet, or by
other means known to
those skilled in the art. Moreover, not every entity seen in FIG. 5 at
reference numerals 508,
510, and 594 must necessarily have real time, uninterrupted access to any or
all of the
Databases 578-590. Each such Databases 578-590 can assign, read, write, and
query
permissions as appropriate to the various entities. For example, a Merchant
(m) 510 may have
read-only access to the Transactions Database (a) 582.
[00103] Each of the one or more Transactions Databases (a) 582 can be used to
store some or
all of the transaction data originating at the Merchants (n) 510 for each
transaction conducted
between an Account holder (p) 508a and the Merchant (m) 510. The transaction
data can
include information associated with an identifier for the Account holder (p)
508a and the date
and time of the transaction, among other more specific information including
the amount of
the transaction. The database can be searched using identifiers for the
Account holder (p) 508a
and the Merchant (m) 510, date and time (or within proximity thereof), or by
any other field
stored in the database.
[00104] Transactions Database (a) 582 can be designed to store information
about each
Merchant (in) 510, where the information can include a unique identification
of each
Merchant (in) 510, an identifier for each point of sale device in use by the
Merchant (m) 510,
and a physical geographic location of each store of the Merchant (in) 510.
Also included in the
Transactions Database (a) 582 is an identifier for Account holder (p) 508a,
its Mobile Device
(q) 508b, its Carrier (r) 508c, as well the name of an account holder who is
registered to
participate in a system in which donations can be made to each Affinity Entity
(k) 596 as per
rules stored in at least one of the Account Holder DB (f) 578 and Merchant DB
(b) 580. This
information may also be stored in various configurations, such as part of
records 42, 54, 56, 58
at data storage device 50.
26
CA 3102709 2020-12-11
Docket No. 107IJS
[00105] After registering to participate in the donation system, an Account
holder (p) 508
initiates a qualifying purchase transaction with a Merchant (m) 510 by
presenting a token
bearing an identifier for the Account Holder (p) 508 to the Merchant (m) 510.
The token can
include both an identifier for an account issued to the Account Holder (p)
508a. The offer
from the Merchant (m) 510 to the Account Holder (p) 508 can also be presented,
where the
offer has an expiration against which the time of the transaction can be
compared to determine
the validity of the offer. The token can be presented at the Point Of Service
terminal (POS),
such as POS 220 seen in FIG. 2, where the POS is capable of reading data on
the token.
Certain transaction information is transmitted from the POS in route to the
Donation Audit
Web Service 594. The transaction information can include a transaction time
stamp, respective
Merchant (m) 510, Account Holder (p) 508a, and offer identifiers, as well as
indicia that
payment for the transaction was made on an account issued to the Account
Holder (p) 508a.
1001061 The Donation Audit Web Service 594 may use the respective merchant and
account
holder identifiers to access and retrieve respective merchant and account
holder geographic
locations from one or more of the Geographic Databases 584. For each
transaction,
determinations are made, using the respective merchant and account holder
geographic
locations, whether the Merchant (m) 510 and the Account Holder (p) 508 have a
local
community in common, and whether the transaction is being conducted within a
predetermined time period using the time of the transaction time stamp and the
offer identifier.
Note that the expiry of the offer may be retrieved from one or more of the
Merchant DBs 580
assessable to the Donation Audit Web Service 594, which contains offers, their
terms, and
their corresponding offer identifiers.
[00107] For each transaction that is conducted within the predetermined time
period after
which the offer will expire and where the Merchant (m) 510 and the Account
Holder (p) 508
have a local community in common, the Donation Audit Web Service 594 retrieves
a
merchant donation business rule for the Merchant (m) 510. Note that the
merchant donation
business rule can be retrieved from one or more of the Merchant DBs 580 (at
data storage
device 50, or merchant system 30) assessable to the Donation Audit Web Service
514, which
contains merchant business rules and their corresponding merchant identifiers.
[00108] From the foregoing, a determination is made by the Donation Audit Web
Service 514
that the Merchant (in) 510 is to make a donation to Affinity Entity (k) 596
which has been
determined to have the same local community as that of the Account Holder (p)
508a and
Merchant (in) 510. Note that the Affinity Entity (k) 596 can be retrieved from
one or more of
the Affinity Entity DBs 590 assessable to the Donation Audit Web Service 594
which contains
27
CA 3102709 2020-12-11
Docket No. 107US
information about Affinity Entity (k) 596 indexed by its corresponding
affinity entity
identifier.
[00109] The donation to be made by the Merchant (m) to the Affinity Entity (k)
596 may be
derived using the merchant's donation business rule retrieved from one or more
of Merchant
DBs 580. Donation Audit Web Service 514 transmits a message containing the
donation to be
made by the Merchant (m) to the Affinity Entity (k) 596 for the predetermined
time period to
one or more logical addresses, including a logical address of the Merchant (m)
510, a logical
address of the Account Holder (p) 508a, and a logical address of the Affinity
Entity (k) 596. It
is advantageous to send the donation to the logical address of the Account
Holder (p) 508a to
confirm the obligation of the Merchant (m) 510's commitment to donate. It is
advantageous to
send the donation to the logical address of the Affinity Entity (k) 596 to
inform the same of
the Merchant (m) 510's commitment to donate so that planning for responsible
use of the
donation can be made. Alternatively, for reasons stated herein, while it is
advantageous to
send the amount of the donation to the logical address of the Merchant (m) 510
to inform the
same of its commitment to donate, it might not be advantageous to send the
identity of the
donee to the donor who may object to the donation on the basis of the donee's
identity,
purpose and/or goals. Accordingly, a message sent to the logical address of
the Merchant (m)
510 need not identify the Affinity Entity (k) 596, and can instead simply send
the amount of
the donation to the logical address of the Merchant (m) 510.
1001101After a predetermined audit time period for each offer's validity, for
each of the
merchant identifiers to which transactions pertain as described above, for
each Affinity Entity
(k) 596 to whom a donation was to be made by the Merchant (m) 510 for the
predetermined
time period - either directly or through a blind donation distribution service
as discussed
elsewhere herein, the Donation Audit Web Service 514 determines a difference
between the
sum of the currency amounts of the donation receipts that were transmitted to
the logical
address of the Merchant (m) 510 for the Affinity Entity (K) 596, and the sum
of the currency
amounts of the donation receipts that were received for the Affinity Entity
(K) 596 for the
Merchant (m) 510 for the predetermined time period. Any such difference can
then be
transmitted to a logical address that is one or more of the logical address of
the merchant, the
logical address of the account holder, and the logical address of the affinity
entity. It is
advantageous to send confirmation of the sum of its donations to the logical
address of the
Merchant (m) 510 to confirm compliance with its prior commitments to donate.
It may be
advantageous to send a summary of donations made by merchants with whom the
Account
Holder (p) 508a has transacted in order to confirm to the Account Holder (p)
508 the
community advantages of doing business with community merchants, where such a
summary
28
CA 3102709 2020-12-11
Docket No. 107US
of merchant donations can be sent to the logical address of the Account Holder
(p) 508,
thereby informing the same of the integrity of the community merchant's
commitment to
donate to the community. It may be advantageous to send the summary of
donations to the
logical address of the Affinity Entity (k) 596 to inform the same as to the
completion, or
absence of completion, as to obligations made by community merchants regarding
their
respective commitments to donate to the local community of the Merchant (m)
510 and
Account Holder (p) 508a.
[00111] A computed and unacceptably high difference that is sent to the
logical address of the
Merchant (m) 510 can be used the Merchant (m) 510 to make up the difference by
a payment
made by the Merchant (m) 510 directly to the Affinity Entity (k) 596 owed.
Alternatively, the
difference payment may be made indirectly to a blind donations disbursement
agency for
subsequent payment of the difference to the Affinity Entity (k) 596 to whom
the Merchant (m)
510 made a commitment, albeit a blind commitment, to contribute.
[00112] Referring to FIG. 6, a flowchart illustrates a Process 600 that can be
performed by a
system (e.g. FIGS. 5, 7, 10-13), such as Donation Audit Web Service
214/514/714, for using
local merchants commitments to make charitable contributions to local
charities as incentives
to local residents to conduct transactions with the local merchants. Prior to
step 602 of Process
600, as discussed above with respect to FIGS. 1-5, a registered local
community resident
conducts a transaction on an account issued to the resident at a brick and
mortar store of a
local community merchant. Prior to this transaction, as discussed above with
respect to FIGS.
1-5, the registered local community resident uses a web access device (or
other computing
device, such as navigation system, tablet, and so on) to request offers from
community
merchants, and then select and confirm one or more such offers.
[00113] At step 602, information is received as derived from a positive
authorization response
originating from an issuer of an account upon which the transaction was
conduct by mobile
device user with the merchant who made an offer that was accepted by the
member as
describe above with respect to FIGS. 1-5. Data from this information can be
extracted at step
604 by a POS, including, by way of example and not by way of limitation, the
current date
and time, a total currency amount paid on the customer's account to the
merchant, respective
identifiers for the customer, the local affinity entity to whom the local
merchant if to make the
obligatory donation, etc.
[00114] Identifiers retrieved at steps 602-604 can be used to access one or
more databases (at
data storage device 50) at step 606. The current date and time for the offer
selected and
confirmed by the customer may have been received by the local merchant in a
transmission
such as has been described with respect to step 418 of Method 400. As such,
the non-
29
CA 3102709 2020-12-11
Docket No. 107US
expiration of the offer selected and confirmed by the customer is assessed in
a query at step
608. While an invalid offer determination ends Process 600 at step 636,
Process 600 proceeds
to step 610 when the offer is valid as determined at query 608.
[00115] At step 610, rules for calculating a donation to be made by the
merchant to the local
affinity entity may be retrieved using data acquired in steps 602-604. This
calculation can
include steps to access one or more databases as shown at reference numerals
612-614,
including transmitting to and/or storing the calculated donation to merchant
donor 612 and/or
one or more merchant donations payable databases 614.
[00116] Subsequent to the acquired transaction on the resident's account as
processed in steps
602-614 of Process 600, the local merchant makes the calculated donation to
the local affinity
entity as shown at step 615. The local affinity entity, as shown at step 616,
sends notice of the
donation's receipt for storage in one or more databases (e.g. at data storage
device 50) as
shown at step 618.
[00117] After a predetermined audit time period as passed as determined by a
query at step
620, an audit is conducted to ensure compliance by each community merchant in
its donation
commitments to each of the one or more affinity entities or charities for each
community that
the merchant and/or its customers is a member. This audit can include adding
up all required
donations for each local merchant to each local affinity entity or charity as
shown at step 622.
The donation summation for each local merchant to each local charity derived
at step 624 is
compared to information in one or more databases 626 to ascertain compliance
of each
merchant with its donation obligations. Stated otherwise, the local merchant
has a certain
amount of time after a predetermined audit period, as determined at step 628,
by which to
make all of the merchant's donation obligations to local affinity entities.
[00118] Differences between donations paid and donations still payable by each
local
merchant are calculated at step 630, which differences are subjected to an
audit threshold
query at step 632. If a local merchant's donations paid is non-compliant with
donations still
payable, as may be determined by the audit threshold query at step 632, then
Process 600
moves to step 634 to notify the local merchant accordingly of its deficiency.
Otherwise,
affirmative results at query 632 causes Process 600 to terminate at step 636
which may also
include notice of compliance being transmitted to each such complaint local
merchant, its
customers, and/or each of the local affinity entities, either by way of
summary report,
donations to respective affinity entities by the merchant, and variations
thereof.
[00119] To summarize Process 600 in various implementations thereof, data is
extracted from
information derived incident to a positive authorization response for an
acquired transaction
conducted on a local resident's account, such as chronological information
pertaining to the
CA 3102709 2020-12-11
Docket No. 107US
transaction including date and time, a currency amount of the transaction, and
any other data
desired to assist in a proper calculation of the merchant's obligatory
donation to a local
Affinity Entity. By way of example, an identifier for the merchant can be
extracted, as well as
an identifier for the local community resident as offered to the merchant by
the same. The
account number, by way of non-limiting example, can be a Primary Account
Number (PAN)
including a Bank Identifier Number or BIN code for a credit or debit card that
is kept by the
merchant in a 'card-on-file' database
100120] Note the business rules can be set and used such that obligatory
donations to local
Affinity Entities can be made by one or more of the following participants in
a payment
processing system: the account holder, the account holder's issuer, the
merchant, the
merchant's acquirer, and the transaction handler. Via access to one or more
databases at step
606, and by using the merchant and/or account holder identifiers extracted
from the
information derived from the positive authorization response, more information
can be
retrieved. Thereafter, database access can retrieve business rules used to
calculate one or more
donations that are to be made to the charity or affinity entities by one or
more donors
respectively corresponding to the account holder, the account holder's issuer,
the merchant, the
merchant's acquirer, and the transaction handler. Stated otherwise, the
donation can be a
function of the amount of the transaction and the retrieved business rule(s).
[00121] Donations, per extracted donor IDentifier (ID), may be made for those
transactions
that occur during a predetermined time period and within a predefined
geographic location as
determined by a query (not shown). If the result of geographic query is
affirmative, process
600 moves to step 610 where the donations that are to be made by the donors
are calculated as
a function of the respective business rules. Otherwise, no donation is made
and process 600
terminates at step 636. Stated otherwise, Process 600 is intended to obligate
a local merchant
to make a donation to a local affinity entity (e.g., a local charity) when a
local resident
conducts a transaction at the local merchant's brick and mortar store in the
same community
where the local resident resides. Note that the terms 'local', 'resident',
'residential', and
'community' can be alternatively defined as described elsewhere herein.
1001221 Donations calculated at step 610 may be communicated to the local
merchant donor at
step 612 and stored in a donations payable database 614. Thereafter, donations
615 may be
received at affinity entities at step 615 from donors identified by either
respective donor Ms,
which can be the identifier for the merchant. Donations received are stored in
donation
receipts database 618. Data from donations that are made by donors via
communication to
affinity entities during an audit period, as determined at query 620, is
extracted at step 622.
The donation related data that is extracted at step 622 can include the donor
ID, and the
31
CA 3102709 2020-12-11
Docket No. 107US
currency amount of the donation. During the audit period, a sum of donations
to each affinity
entity made by each local merchant donor for the audit period is calculated
and stored in a
donor-Affinity Entity donation paid database 626 (e.g. at data storage device
50). After a
predetermined time period, an audit period begins, as determined by query 628.
During the
audit time period, differences in donations paid are compared to donations
payable for each
donor at step 630. Differences exceeding a predetermined audit threshold, as
determined by
query 632, are communicated to the respective local merchant donors at step
634. Of course,
the charitable audit functions, such as have been described above, can be
performed by an
agent of any donor and/or of a loyalty system organization charged with
implementing all or
portions of process 600. Such an auditing agent can be, by way of non-limiting
example, a
certified public accountancy agency, a non-government regulatory agency, a
governmental
agency, and the like.
[00123] As further discussed above with respect to various implementations, a
donation
mechanism can be set up such that the Merchant-Donor 634 makes blind
donations, either
directly or indirectly, to a single donation disbursement entity who in turn
disburses the
donations to those affinity entities selected by the customers of the Merchant-
Donor 634. This
donation mechanism provides neither knowledge nor notice to Merchant-Donor 634
as to the
identities of its donation recipients, thereby avoiding circumstances that
force a merchant, by
virtue of its prior commitment, to make a donation to a local community
affinity entity whose
role, or purpose is inimical or otherwise repugnant to the Merchant-Donor 634.
As such, the
donation mechanism leaves the direction of the donations fully within the
discretion of the
customers, limited only by the restriction that the customer can only select
from among those
affinity entities that serve the local community that is in common to both the
customer and the
Merchant-Donor 634, while leaving the actual amount of the donation fully
within the
discretion of the Merchant-Donor 634.
[00124] The diagram of FIG. 7 depicts an exemplary process 700 of a particular
financial
transaction system, such as may be described as an open loop system, in which
an account
holder (p) 708 conducts a financial transaction with a Merchant (m) 710. By
way of example,
the Account Holder (p) 708's financial transaction with the Merchant (m) 710
may have been
incentivized by the Merchant (m) 710's agreement to make a donation to an
Affinity Entity (k)
795 in the local community as defined by the Merchant (m) 710 through an ad
incentive which
is communicated in an audible rendering to Account Holder (p) 708 instigated
by a request for
the same, preferably by use of a web access device as described above with
respect to
illustrations in FIGS. 1-6, and as referred to in FIGS. 10 to 13 as customer
device 48.
32
CA 3102709 2020-12-11
Docket No. 107US
[00125] In FIG. 7, by way of explanation for the nomenclature of reference
numerals used and
described in the specification, a lower case letter in parenthesis is intended
to mean an integer
variable having a value from 1 to the capital case of the lower case letter,
which value can be
large (i.e., approaching infinity). Thus '(b)' is intended to mean that the
integer 'b' can have a
value from 1 to B, and '(c)' is intended to mean that the integer 'c' can have
a value from 1 to
C, etc. As such, drawing elements 704-710 and 776-790, and 796 in FIG. 7 are
illustrated with
a block, but indicate one or more elements can be present. For example, Issuer
(j) 704 is one
of a possible plurality of issuers, where j may range from 1 to a large
integer 'J'.
[00126] Account Holder (p) 708 presents an electronic payment device (i.e.; a
credit card) to a
Merchant (m) 710 as tender for a financial transaction such as a purchase of
goods and
services. Other financial transactions and instruments other than credit cards
may also be used,
including, but not limited to, a prepaid card, a gift card, a debit card, a
token equivalent of an
account as communicated via cellular telephony, near field communications, and
the like. For
purposes of illustration and explanation, however, reference will be made to a
credit card.
[00127] As part of the transaction, the Account Holder (p)'s 708 payment
device can be a
credit card, debit card, prepaid card, cellular telephone, Personal Digital
Assistant (PDA), etc.
The payment device is read by a reader operated by the Merchant (m) 710,
whereupon account
information is read from the payment device and a request for authorization is
transmitted to
the Merchant (m) 710's Acquirer (i) 706. Each Acquirer (i) 706 is a financial
organization that
processes credit card transactions for businesses, for example merchants, and
is licensed as a
member of a Transaction Handler 702 such as a credit card association (i.e.,
Visa Inc.,
MasterCard, etc.) As such, each Acquirer (i) 706 establishes a financial
relationship with one
or more Merchants (n) 710.
[00128] The Acquirer (i) 706 transmits the account information to the
Transaction Handler
702, who in turn routes the authorization request to the account holder's
issuing bank, or Issuer
(j) 704. The Issuer (j) 704 returns information via an authorization response
to the Transaction
Handler 702 who returns the information to the Merchant (m) 710 through the
Acquirer (i)
706. The Merchant (m) 710, now knowing whether the Account Holder (p) 708's
credit card
account is valid and supports a sufficient credit balance, may complete the
transaction and the
Account holder (p) 708 in turn receives goods and/or services in exchange.
Most credit card
associations instruct merchants that, after receiving an affirmative
authorization response, the
detailed credit card account information obtained by a point of service
terminal (e.g., such as
via a magnetic stripe scanner) must be deleted.
[00129] To reconcile the financial transactions and provide for remuneration,
information
about the transaction is provided by the Merchant (m) 710 to Acquirer (i) 706,
who in turn
33
CA 3102709 2020-12-11
Docket No. 107US
routes the transaction data to the Transaction Handler 702 who then provides
the transaction
data to the appropriate Issuer (j) 704. The Issuer (j) 704 then provides
funding for the
transaction to the Transaction Handler 702 through a settlement bank. The
funds are then
forwarded to the Merchant's (n) 710 Acquirer (i) 706 who in turn pays the
Merchant (m) 710
for the transaction conducted at step 762 less a merchant discount, if
applicable. The Issuer (j)
704 then bills the Account holder (p) 708, and the Account holder (p) 708 pays
the Issuer 704
with possible interest or fees.
[00130] Also shown in FIG. 7 are one or more Affinity Entities (k) 796 and a
Donation Audit
Web Service 714 that implements processes by which donations to the one or
more Affinity
Entities (k) 796 from various donors, for instance, any Issuer (j) 704, an
Merchant (m) 710,
any Acquirer (i) 706, and the Transaction Handler 702. Other system
configurations may be
used, such as the illustrative examples shown in FIGS. 10 to 13. Donation
Audit Web Service
714 implementations processes for the auditing of donations to the one or more
Affinity
Entities (k) 796. The Donation Audit Web Service 714 has access to information
resources
within the following databases: Account Holder DBs 778; Merchant DBs 780;
Transaction
Databases 782; and Geographic Databases 784. These databases may be
persistently stored at
data storage device 50.
[00131] By way of example, and not by way of limitation, construction of
local, geographic,
residential or community associations between merchants and their customers
can include
factors such as geographic, political, demographics, local transportation
modes, navigational
algorithms for geopolitical regions, cartographic data, planned communities,
population
density, cultural divides, racial population constituencies, census
statistics, socio-economic
factors, and combinations thereof.
[00132] Also seen in FIG. 7 are Affinity Entity DBs 790; Affinity Entity
Donations Payable
DBs 786; and Affinity Entity Donations Paid DBs 788. Databases 778-790 can be
connected
by one or more private or public networks, virtual private networks, the
Internet, or by other
means. These databases may be persistently stored at data storage device 50.
Moreover, not
every entity seen in FIG. 7 at reference numerals 708, 710, and 796 must
necessarily have real
time, uninterrupted access to any or all of the Databases 778-790 at data
storage device 50.
Each such Databases 778-790 can assign, read, write, and query permissions as
appropriate to
the various entities. For example, a Merchant (m) 710 may have read access to
the
Transactions Database (a) 782.
[00133] The Transactions Database (a) 782 can be designed to store some or all
of the
transaction data (e.g. transaction data 58 at data storage device 50)
originating at the
Merchants (n) 710 that use a payment device for each transaction conducted
between an
34
CA 3102709 2020-12-11
Docket No. 107US
Account holder (p) 708 and the Merchant (m) 710. The transaction data can
include
information associated with the account of an Account holder (p) 708, date,
time, and an
identifier sufficient to determine a physical geographic location where the
transaction took
place, among other more specific information including the amount of the
transaction. The
database can be searched using account information, date and time (or within
proximity
thereof), or by any other field stored in the database.
[00134] The Transactions Database (a) 782 is also designed to store
information about each
Merchant (m) 710, where the information can include a unique identification of
each
Merchant (m) 710, an identifier for each point of sale device in use by the
Merchant (m) 710,
and a physical geographic location of each store of the Merchant (m) 710.
[00135] Also included in the Transactions Database (a) 782 is account
information for
payment devices associated with Account holder (p) 708, such as part or all of
an account
number, unique encryption key, account information, and account name of an
account holder
who is registered to participate in a system in which donations can be made to
each Affinity
Entity (k) 790 as per rules stored in Donations Biz Rule Database (b) 780.
After registering to
participate in the donation system, an Account holder (p) 708 initiates a
qualifying purchase
transaction with a Merchant (in) 710 by presenting a payment device at step
758 to the
Merchant (m) 710. The payment device is typically presented at the Point Of
Service terminal
(POS) at which data thereon is read. Certain transaction information is
transmitted from the
POS in route to the Merchant's (n) 710 Acquirer (i) 706. The transaction
information can
include account information, account name, transaction balance, transaction
time, transaction
date, and transaction location. Sensitive information includes information
such account
number and account holder name that identify and associate a particular
account with a
particular account holder. This transaction information may be transmitted via
a less secure
communication medium. In addition, a transmission of transaction data may
occur with weak
or no encryption between two or more points from the point of origin, such as
the point of sale
device at the Merchant (m) 710, and the ultimate destination, such as the
Acquirer (i) 706.
These points can include, without limitation, from the reader at the POS, the
POS at the
Merchant (m) 710 and a network router or computer that is connected to a
network but is
housed and maintained by the Merchant (m) 710 and between the Merchant (m) 710
and the
Acquirer (i) 706. The communication channel could be Ethernet, wireless
internet, satellite,
infrared transmission, or other known communication protocols. Some or all of
the
transmission may also be stored for record keeping, archival or data mining
purposes with
little or no encryption. For example, the Merchant (m) 710 may store
transaction data,
CA 3102709 2020-12-11
Docket No. 107US
including certain account information in the Merchant's (n) 710 accounts on
file database for
reuse later.
[00136] During a transaction conducted by Merchant (m) 706 on an account
issued by Issuer
(j) 704 to Account Holder (p) 708, information relating to the qualifying
purchase may be
retrieved from the POS at Merchant (m) 706. The transaction information is
comprised of
account information together with other information about the transaction
itself: time, date,
location, value, etc. Certain of the transaction information are considered
sensitive information
including, without limitation, account number, credit card verification
number, and account
name.
[00137] To pay the donation to each Affinity Entity (k) 796 so specified in
screen shot 304,
the Account Holder (p) 708's Issuer (j) 704 can pay the Affinity Entity (k)
786 and place a
debit in that currency amount on the Account Holder (p) 708's periodic
revolving credit
statement. The Account Holder (p) 708, upon receipt of the statement, can
thereafter make a
total payment to the Issuer (j) 704 of the currency amount of the donation
that appears as a
debit on the statement along with the other credit charges that also appear on
the Account
Holder (p) 708's statement.
[00138] Both the Account Holder (p) 708 and the Merchant (in) 710 can change
or disable a
donation commitment at any time by accessing a server that serves web pages
rendering
screen shots 302, 304, respectively. Thus, charitable donation commitments can
be easily and
instantly enabled or disabled using the real time user interface. By way of
example, and not by
way of limitation, such servers can be hosted by the Donation Audit Web
Service 214, 514,
and 714 seen in FIGS. 2, 5 and 7, respectively.
[00139] Referring again now to FIG. 7, further illustrations are seen of a
telecommunications
network that may make use of any suitable telecommunications network and may
involve
different hardware, different software and/or different protocols then those
discussed below.
FIG. 7 is a global telecommunications network that supports purchase and cash
transactions
using any bankcard, travel and entertainment cards, and other private label
and proprietary
cards. The network also supports ATM transactions for other networks,
transactions using
paper checks, transactions using smart cards and transactions using other
financial
instruments. These transactions are processed through the network's
authorization, clearing
and settlement services. Authorization occurs when an issuer approves or
declines a sales
transaction before a purchase is finalized or cash is dispersed. Clearing
occurs when a
transaction is delivered from an acquirer to an issuer for posting to the
customer's account.
Settlement is the process of calculating and determining the net financial
position of each
36
CA 3102709 2020-12-11
Docket No. 1071US
member for all transactions that are cleared. The actual exchange of funds is
a separate
process.
[00140] Transactions can be authorized, cleared and settled as either a dual
message or a
single message transaction. A dual message transaction is sent twice-the first
time with only
information needed for an authorization decision, an again later with
additional information
for clearing and settlement. A single message transaction is sent once for
authorization and
contains clearing and settlement information as well. Typically,
authorization, clearing and
settlement all occur on-line.
[00141] Referring now to FIGS. 7-9, FIG. 7 includes access points 730, 732
between
Transaction Handler 702 and each Acquirer (i) 706 and Issuer (j) 704. Other
entities such as
drawee banks and third party authorizing agents may also connect to the
financial; network
through an access point (not shown). An interchange center has systems, such
as those seen at
reference numeral 840 see in FIG. 8, so as to be a data processing center that
may be located
anywhere in the world. Each interchange center houses the computer system that
performs the
network transaction processing. The interchange center serves as the control
point for the
telecommunication facilities of the network, which comprises high-speed leased
lines or
satellite connections, for instance as may be based on IBM SNA protocol.
Preferably, the
communication lines that connect an interchange center (Transaction Handler
702) to remote
entities use dedicated high-bandwidth telephone circuits or satellite
connections, for instance
as may be based on the IBM SNA-LIJO communication protocol. Messages are sent
over
these lines using any suitable implementation of the ISO 8583 standard.
[00142] Access points 730, 732 may be made up of small computer systems
located at a
processing center that interfaces between the center's host computer and the
interchange center
system 840. The access point facilitates the transmission of messages and
files between the
host and the interchange center supporting the authorization, clearing and
settlement of
transaction. Telecommunication links between the Acquirer (i) 796 and its
access point 732,
and between the access point 730 and Issuer (j) 704 are typically local links
within a center
and use a proprietary message format as preferred by the center.
[00143] A data processing center (such as is located within an acquirer,
issuer, or other entity)
houses processing systems that may support merchant and business locations and
maintain
customer data and billing systems. Preferably, each processing center may be
linked to one or
two interchange centers. Processors may be connected to the closest
interchange, and if the
network experiences interruptions, the network may automatically route
transactions to a
secondary interchange center. Each interchange center is also linked to all of
the other
interchange centers. This linking enables processing centers to communicate
with each other
37
CA 3102709 2020-12-11
Docket No. 107US
through one or more interchange centers. In addition, processing centers can
access the
networks of other programs through the interchange center. Further, the
network ensures that
all links have multiple backups. The connection from one point of the network
to another is
not usually a fixed link; instead, the interchange center chooses the best
possible path at the
time of any given transmission. Rerouting around any faulty link occurs
automatically.
[00144] FIG. 8 illustrates systems 840 housed within an interchange center to
provide on-line
and off-line transaction processing. For dual message transaction,
authorization system 842
provides authorization. Authorization system 842 supports on-line and off-line
functions, and
its file includes internal systems tables, a customer database and a merchant
central file. The
on-line functions of system 842 support dual message authorization processing.
This
processing involves routing, account holder and card verification and stand-in
processing, and
other functions such as file maintenance. Reporting includes authorization
reports, exception
file and advice file reports, POS reports and billing reports. A bridge from
system 842 to a
Single Message System (SMS) 846 makes it possible for issuers and acquirers to
use system
842 to communicate with other issuers and acquirers using system 546 and
access the SMS
gateways to outside networks.
[00145] Clearing and settlement system 844 clears and settles previously
authorized dual
message transactions. System 844 collects financial and non-financial
information and
distributes reports between members. It also calculates fees, charges and
settlement totals and
produces reports to help with reconciliation. A bridge forms an interchange
between system
844 processing centers and system 848 processing centers. Data from system 800
may be
stored as part of transaction data 58 (at data storage device 50 of FIG. 10)
[00146] Single message system 846 processes full financial transactions and
can also process
dual message authorization and clearing transactions, as well as communicate
with system 842
using a bridge and accesses outside networks as required. System 846 processes
cashless
issued account-based acquired transactions, for instance Visa, Plus,
Interlink. Maestro, Cirrus,
and others. By way of example, SMS files comprise internal system tables that
control system
access and processing, and an account holder database, which contains files of
account holder
data used fur Personal IDentifier (PIN) verification and stand-in processing
authorization.
System 846 has on-line functions that perform real-time account holder
transaction processing
and exception processing for authorization as well as full financial
transactions. System 846
also accumulates reconciliation and settlement totals. System 846 also has off-
line functions
that process settlement and funds transfer requests and provide settlement and
activities
reporting. Settlement service 848 consolidates the settlement functions of
system 844 and 846
38
CA 3102709 2020-12-11
Docket No. 107US
for cashless issued account-based acquired transactions into a single service
for all products
and services. Clearing continues to be performed separately by system 844 and
system 846.
[00147] FIG. 9 illustrates another view of components of FIG. 8 in a
telecommunications
network 900. Integrated payment system 960 is the primary system for
processing all on-line
authorization and financial request transactions. System 960 reports both dual
message and
single message processing. In both cases, settlement occurs separately. The
three main
software components are the common interface function 962, authorization
system 942 and
single message system 946.
[00148] Common interface function 962 determines the processing required for
each message
received at an interchange center. It may choose the appropriate routing,
based on the source
of the message (system 942, 944 or 946), the type of processing request and
the processing
network. This component may perform initial message editing, and, when
necessary, parses
the message and ensures that the content complies with basic message
construction rules.
Common interface function 962 routes messages to their system 942 or system
946
destinations.
[00149] Referring again now to FIGS. 2, 5, and 7-9, further illustrations are
seen of a
telecommunications network that may make use of any suitable
telecommunications network
and may involve different hardware, different software and/or different
protocols then those
discussed below. FIGS. 2, 5, and 7-9 include a global telecommunications
network that
supports purchase and cash transactions using any bankcard, travel and
entertainment cards,
and other private label and proprietary cards. The network also supports ATM
transactions for
other networks, transactions using paper checks, transactions using smart
cards and
transactions using other financial instruments. These transactions are
processed through the
network's authorization, clearing and settlement services. Authorization
occurs when an issuer
approves or declines a sales transaction before a purchase is finalized or
cash is dispersed.
Clearing occurs when a transaction is delivered from an acquirer to an issuer
for posting to the
customer's account. Settlement is the process of calculating and determining
the net financial
position of each member for all transactions that are cleared. The actual
exchange of funds is a
separate process. The telecommunications network may also connect the
components shown
in FIGS. 10 to 13.
[00150] In at least some implementations, the system may include one or more
processors
(e.g., digital signal processors, microprocessors, etc.), each being adapted
to execute
instructions to perform at least some of the methods, operations, and
processes described
herein with respect to the figures. Such instructions may be stored or held in
storage media as
instructions.
39
CA 3102709 2020-12-11
Docket No. 10715S
[00151] The methodologies described herein may be implemented in different
ways and with
different configurations depending upon the particular application. For
example, such
methodologies may be implemented in hardware, firmware, and/or combinations
thereof,
along with software. In a hardware implementation, for example, a processing
unit may be
implemented within one or more application specific integrated circuits
(ASICs), digital signal
processors (DSPs), digital signal processing devices (DSPDs), programmable
logic devices
(PLDs), field programmable gate arrays (FPGAs), processors, controllers, micro-
controllers,
microprocessors, electronic devices, other devices units designed to perform
the functions
described herein, and/or combinations thereof.
[00152] By way of example, a member may use a network access device to send a
request for
offer 102 as seen in FIG. 1 to communicate with a server, for example,
Donation Audit Web
Service 214 seen in FIG. 2. This may also extend to customer device 48 which
may
communicate with Donation Audit Web Service 214/514/714 seen in FIGS. 5, 7, 10
to 13.
While the latter may be programmed using server-client coding methodologies,
an application
executing on the former can be a thin client mobile web browser or an
application specific to
perform implementations described herein. Such a specific application can be
coded to
execute on a network access device running an open source operating system.
[00153] Referring now to FIGS. 10 to 13, there is shown various system
configurations in
accordance with embodiments described herein. The components of systems shown
in FIGS.
to 13 may correspond to one or more components shown in FIGS. 2, 5, 7.
[00154] Loyalty system 20 interacts with merchant system 40, data storage
devices 50, an
affinity system 60, and a card issuer system 80 to process information
relating to offers,
process transaction, collect data regarding offers, transactions, merchants,
customers, affinity
entities, process donations, transfer funds, and so on.
[00155] Loyalty system 20 may be implemented using a server and data storage
devices 50
configured with database(s) or file system(s), or using multiple servers or
groups of servers
distributed over a wide geographic area and connected via a network. Loyalty
system 20 may
be connected to a data storage device 50 directly or via to a cloud based data
storage device
interface via network. Loyalty system 20 may reside on any networked computing
device
including a processor and memory, such as a personal computer, workstation,
server, portable
computer, mobile device, personal digital assistant, laptop, tablet, smart
phone, WAP phone,
an interactive television, video display terminals, gaming consoles,
electronic reading device,
and portable electronic devices or a combination of these. Loyalty system 20
may include one
or more microprocessors that may be any type of processor, such as, for
example, any type of
general-purpose microprocessor or microcontroller, a digital signal processing
(DSP)
CA 3102709 2020-12-11
Docket No. 107US
processor, an integrated circuit, a programmable read-only memory (PROM), or
any
combination thereof Loyalty system 20 may include any type of computer memory
that is
located either internally or externally such as, for example, random-access
memory (RAM),
read-only memory (ROM), compact disc read-only memory (CDROM), electro-optical
memory, magneto-optical memory, erasable programmable read-only memory
(EPROM), and
electrically-erasable programmable read-only memory (EEPROM), or the like.
Loyalty
system 20 may include one or more input devices, such as a keyboard, mouse,
camera, touch
screen and a microphone, and may also include one or more output devices such
as a display
screen and a speaker. Loyalty system 20 has a network interface in order to
communicate with
other components, to serve an application and other applications, and perform
other
computing applications by connecting to network (or multiple networks) capable
of carrying
data including the Internet, Ethernet, plain old telephone service (POTS)
line, public switch
telephone network (PSTN), integrated services digital network (ISDN), digital
subscriber line
(DSL), coaxial cable, fiber optics, satellite, mobile, wireless (e.g. Wi-Fi,
WiMAX), SS7
signaling network, fixed line, local area network, wide area network, and
others, including any
combination of these. Although only one loyalty system 20 is shown for
clarity, there may be
multiple loyalty systems 26 or groups of loyalty systems 26 distributed over a
wide
geographic area and connected via e.g. network. Loyalty system 20 may be
connected to the
Internet or other network in order to interact and connect with merchant
system 40, customer
device 48 and affinity system 60.
[00156] Loyalty system 20 includes a cardholder benefits (e.g. incentives)
processing utility
32. A cardholder may be a customer of merchant and a member of the loyalty
program to
receive incentives to for cash payments at a brick and mortar store. The
loyalty program may
be associated with a card issuer system 80. In one example of an
implementation, the
cardholder benefits processing utility 32 may be a software component of a web
utility that
provides a loyalty engine. Accordingly, cardholder benefits processing utility
32 may be
referred to as a loyalty engine. The cardholder benefits processing utility 32
may be
programmed to configure the data storage device database 32 with benefits
accounts 52 of the
various cardholders who are members of the loyalty program. The benefits
accounts may
comprise a record of incentives for the member, along with details of
transactions associated
with incentives and customer attributes and preferences (such as e.g. location
data, preferred
affinity entity data),
[00157] The loyalty system 20 may be programmed to configure the data storage
device 50
with merchant accounts 54 of the various merchants who are registered with
loyalty system 20
to provide loyalty programs and offer incentives or benefits to encourage cash
payments and
41
CA 3102709 2020-12-11
Docket No. 107US
in-store transactions through donations to affinity entities. As described
herein, the merchant
accounts 54 may include a variety of information and attributes regarding
different merchants,
including locations, goods and services, offers, transactions, donations, and
so on.
[00158] The loyalty system 20 may be programmed to configure the data storage
device 50
with card or member accounts 56 who are registered with loyalty system 20 or
with card
issuer system 80 to provide loyalty cards to cardholders for loyalty programs.
The loyalty
cards may be physical cards with computer readable indicia to identify the
cardholder and may
also be an electronic card for storage on storage device of mobile device or
smart phone of
cardholder. The loyalty card may be associated with a value account thr the
merchant for
payment of transactions with merchant. The card issuer system 80 may operate a
loyalty
program (via points and reward program utility 82) in conjunction with a
loyalty program
offered by loyalty system 20. Loyalty system 20 may provide a bridge between
points and
reward program utility 82 and merchant systems 40 and affinity systems 60.
Cardholder
registration utility 84 may enable a cardholder to register with card issuer
system 80, where
data regarding the cardholder may be stored as member accounts 56 at data
storage device 50.
[00159] Access to different aspects and account records of the data storage
device 50 may be
provided by an administration utility (not shown) that enables hierarchical
access to the data
storage device 50, depending on permissions assigned by the operator of the
loyalty system, to
each of members, and merchants. The purpose of providing this access is to
provide
transparency to the benefits being provided to members who are cardholders by
operation of
the loyalty system 20.
[00160] Loyalty system 20 further includes a reporting utility or transaction
data reporting tool
38, which may be further linked to the cardholder benefits processing utility
32 and data
storage device 50 to provide various reports of interest to merchants and
cardholders. For
example, transaction data reporting 36 may permit merchants to generate
reports on measured
performance of benefits or incentives provided to them by the loyalty system
20 in their
sphere of interest. Merchant system 40 may receive the report via merchant
interface 28 and
merchant reporting tool 46. One of the purposes of the reporting utility 36 is
to enable the
organizations linked to the loyalty system 20 to calibrate their involvement
(e.g. by merchants
calibrating the benefits that they provide) targeted to cardholders, and to
review the results of
their loyalty programs management by loyalty system 20. Card issuer system 80
may similarly
use a card issuer reporting tool 86 to access reports generated by loyalty
system 20. Card
issuer system 86 may provide cardholder and transaction data 88 to loyalty
system 20
regarding transactions and members for processing by data scrub utility 36 and
storage by data
storage device 50 as benefit accounts 52, member accounts 56, and transaction
data 58.
42
CA 3102709 2020-12-11
Docket No. 107US
[00161] Loyalty system 20 may include loyalty program module 22 which may be a
hardware
and software tool to manage the various loyalty programs managed by loyalty
system 20.
Loyalty programs may be particular to one or more merchants. A loyalty program
may be
used to provide incentives or offers to the customer or members.
[00162] In example embodiments described herein, merchant system 40 may be
provided with
tools to design and implement their own loyalty programs, design and implement
their own
benefits or incentives, including cross-promotional programs in conjunction
with other
merchants in the same community for example. The merchant system 40 may design
and
implement loyalty programs and incentives using merchant interface 28.
Merchant system 40
may transmit merchant data (e.g. parameters for reports) to loyalty system 20
via merchant
interface 28. Merchant system 40 may transmit customer and transaction data 44
(e.g. data
regarding transactions and customers) to loyalty system 20 via merchant
interface 28.
[00163] Similarly, in example embodiments described herein, card issuer system
80 may be
provided with tools to design and implement their own loyalty programs, design
and
implement their own benefits or incentives, including cross-promotional
programs in
conjunction with other merchants in the same community for example. For
example, points
and rewards program utility 82 may interact with loyalty system 20 to manage
loyalty
programs for card issuers. Cardholder registration utility 84 may enable
registration of
cardholders directly with card issuer system 80 or via loyalty system 20.
[00164] Each customer may be associated with a market or demographic, which
may be used
by merchant system 40 and loyalty system 20 to recommend customer incentives
and offers.
A loyalty program incentive may be used to target particular consumer needs.
Loyalty system
20 may recommend incentives via recommendation engine 30 tailored to segments
of
customers, where the recommendation may be based attributes of customers, such
as spending
habits, interests, needs, wants, charities, social habits, current location
etc. Loyalty' system 20
may recommend affinity entities based on customer attributes or merchant
attributes, such as
location, partnerships, goods and services, spending trends, interests, needs,
wants, charities,
social habits, etc.
[00165] The loyalty system 20 is operable, via the Internet for example, to
engage in real time
data communications with a merchant system 40, card issuer system 80, and also
customer or
member devices 28 (e.g. electronic device, smart phone, mobile device, laptop,
tablet,
navigation system, WI devices, or other computing device). Accordingly,
seamless data flows
between these systems can be established in order to enable the capture of
financial
transactions and cardholder data, and also the accrual of benefits or
incentives based on data
provided to the loyalty system 20 the merchant system 40.
43
CA 3102709 2020-12-11
Docket No. 107LJS
[00166] Loyalty system 20 is operable to provide system tools for the affinity
system 60 to
receive payments from the merchant systems 40 and card issuer systems 60 in
connection with
transactions between the merchants and the cardholders registered with the
loyalty system 20.
The reporting facility provides visibility to the affinity entity, the
cardholders, the card issuers,
and the merchant in regard to the amounts accrued and subsequently paid as
donations at the
end of the measurement period.
[00167] The loyalty system 20 may pre-determine the conditions under which
this occurs.
Typically, incentives or offers are associated with conditional transactions
with merchants
(e.g. the purchase of a particular good or service is required in order to
receive the special
offer or prize, cash payments, in-store transactions). This encourages
cardholders to conduct
transactions with merchants. When a registered cardholder enters into such a
transaction with
a merchant in connection with the loyalty system 20, a transaction amount is
recorded. At the
end of the reporting period the system aggregates the amounts for reporting
purposes, and for
calculating donations. Funds may distribute to the respective affinity systems
60.
[00168] Loyalty system 20 may recommend incentives particularly tailored to
targeted
segments of cardholders and potentially cardholders to further increase
particular transactions.
The recommended incentives and associated transactions are likely to be of
interest to the
targeted segment based on data mining and correlations of cardholder (and
potential customer
and cardholder) attributes. For example, the location of customer device 48
may be used to
recommend incentives or offers as part of Offer Group to customer. The
historical spending
habits of a customer may also be used to recommend incentives or offers as
part of Offer
Group to customer. As a further example, merchant trends may also be used to
recommend
incentives or offers as part of Offer Group to customer. As an additional
example, key words
provided by customer in a request for offers may be used to recommend
incentives or offers as
part of Offer Group to customer. The recommendations for Offer Group may be
generated by
recommendation engine 30 by process data records in data storage device 50.
[00169] The end result may be the accrual of benefits and incentives the to
the benefits
account 34, which then in is disbursed on a periodic basis to the applicable
parties.
[00170] Loyalty system 20 provides for a linkage of a data between merchant
systems 40, card
issuer systems 80, affinity systems 60, and cardholders (via customer device
48). Although
only one merchant system 40 is shown in FIG. 2 for simplicity, there may be
multiple
merchant systems 40 connected to loyalty system 20. Although only one card
issuer system 80
is shown in FIG. 2 for simplicity, there may be multiple card issuer systems
80 connected to
loyalty system 20.
44
CA 3102709 2020-12-11
Docket No. 107US
[00171] Loyalty and customer acquisition programs may be required to
continually acquire
new members, preferably at a low cost, e.g. through organic growth or through
a partnership
with various customer sources. Loyalty system 20 may retain cardholder
databases of
transaction information and other cardholder benefits, which may include data
from other
participating merchants. Loyalty system 20 may access the cardholder databases
to detect
cardholder and member attributes in order to recommend incentives via
recommendation
engine 30. Benefit accounts 52 may include records of offers for various
merchants, as
described herein.
[00172] Transaction data 58 may include (1) customer name; (2) payment method;
(3) date of
transaction; (4) merchant ID; (5) amount of purchase; and (6) goods and
services. Other
information may also be accessible such as demographic and geographic
information relating
the cardholder. This information may be stored in data storage devices 50 and
accessed by
loyalty system 20.
[00173] Loyalty system 20 enables each of the merchants and members to track
the accrual of
benefits by means of transactions that in connection with the loyalty system
20 result in the
accrual of loyalty benefits (e.g. incentives). The transaction data may be
collected by card
issuer systems 80 for example, such as when customer uses an acquired account
(e.g. credit
card, debit card) for payment. The transaction data may be provided to loyalty
system 20 via
transaction data 58 at data storage device 58.
[00174] Loyalty system 20 is operable to store the data items mentioned above
(and other
similar data items) to the data storage device 50 and apply same against
transactions between
participating members and participating merchants. Loyalty system 20 may use
the data items
to recommend incentives or affinity entities, and corresponding transactions.
[001751A point conversion utility (not shown) enables enhancement of loyalty
programs
based upon points or donations as cardholder benefits created by cardholder
use in connection
with a loyalty program and provided by incentives offered to cardholder. The
point conversion
utility may allow the merchant to reward their cardholders in form of
donations by converting
loyalty program points to donation amounts. These points, donations, and
rewards are
examples of incentives. For example, point conversion utility may calculate
100 points for a
transaction and record the transaction information and related conversion
amount 100 points
as cardholder attributes in storage device 50. The point conversion utility
may also convert
points from loyalty programs for specific card issuers to points for
corresponding loyalty
programs managed by loyalty system.
[00176] An example process in connection with the generation of reports based
on the
contents of data storage device 50 will now be described. A system
administrator of the
CA 3102709 2020-12-11
Docket No. 107US
operator of the loyalty system 20 may access certain reports in connection
with merchant
activity in connection with customer demographics. Similar processes and
system
implementations may be used to generate other reports of information
accessible to merchants,
or members. The loyalty system 20 is operable to generate reports for
merchants to track the
use and monitor the results.
[00177] Loyalty system 20 may enable a merchant to target incentives to
particular sub-groups
of cardholders, depending on their interest (e.g. cardholder attributes) to
merchant.
[00178] After a cardholder transaction has been completed the transaction data
may be relayed
to the loyalty system 20. The loyalty system 20 defines in accordance with a
particular loyalty
program a set of rules to complement loyalty programs by processing the
transaction data (e.g.
identified merchant, amount of transaction, date of transaction, time of
transaction) to convert
the transaction into points in connection with parameters set by each
participating merchant.
For instance, the system 20 may convert transaction incentives or prizes
within the loyalty
program to points to the cardholder based on a pre-determined formula. The
loyalty system 20
would for example convert a $100.00 spent by a cardholder under a loyalty
program into 100
points if the transaction was completed between the hours of 00:00:00 and
12:00:00 Monday
through Friday and 50 points at any other time for the particular card used at
a particular
merchant.
[00179] As previously stated, a merchant belonging to the loyalty system 20
may choose to
offer rewards/incentives/offers based upon time of day and date. The
incentives may also be
based on a particular good or service. The merchant provides selected
information relating to
particular demographics, affinity entities, transactions, dates and times
(e.g. attributes). The
loyalty system identifies the merchant, the time of day and the date and
applies differential
incentives through the loyalty system. The incentives may relate to a donation
to an affinity
entity as managed by donation utility 26.
1001801 Benefits, offers, or incentives may be accrued on behalf of members
(including
members who are cardholders) in a number of ways. The benefits themselves can
vary. For
example, pre-set benefit application or payment rates are associated with
particular
transactions associated with the loyalty system 20.
[00181] Within the loyalty system 20, merchants may be motivated to develop
new and
innovative loyalty programs (through the use of recommended incentives) that
will
automatically be accessible to cardholders. Loyalty system 20 may provide a
means of
generating financial transactions and/or customers for merchants.
[00182] Loyalty system 20 may provide flexibility in the arrangements made by
the
merchants, as it relates to the benefits provided to cardholders who become
members. These
46
CA 3102709 2020-12-11
Docket No. 107US
arrangements can define the pre-determined benefits associated with particular
transactions,
e.g. a per transaction benefit to the cardholder.
[00183] Other configurations and extensions may be implemented by loyalty
system 20. For
example, various security methods and technologies for restricting access to
resources of the
loyalty system 20 to those authorized to do so by the operator of the loyalty
system 20 may be
used. Loyalty system 20 may use various existing and future technologies to
process payments
by operation of the transaction utility. Loyalty system 20 may provide various
tools and
interfaces for interacting with the loyalty system. The system 20 may also
allow for robust
reporting which may include comparative reports of member affinity or of
transaction history
with participating merchants. In other words, member transaction history may
be different for
differing groups of members based on member affinity.
[00184] Data storage device 50 maintains benefits accounts 52, merchant
accounts 54,
member accounts 56, transaction data 58 for storing attributes regarding
offers/incentives,
merchants, cardholders and transactions. Data storage device 50 may provide a
persistent store
for the various databases described herein. The attributes may be used to
determine incentives
for Offer Group in relation to various loyalty' programs, and affinity
entities to provide
donations to. For example, data scrub utility 36 may retrieve data from data
storage device 50
for provision to recommendation engine 30 to recommend offers involving
donations to
affinity entities, offers for merchants proximate to a location related to the
customer (current
location of customer device 48, location of customer's workplace, location of
customer's
home, and so on). Data scrub utility 36 may normalize, scrub, convert and
perform other
operations on data received from other systems (e.g. merchant system 40,
affinity system 60,
card issuer system 80).
[00185] Cardholder registration 24 may enable cardholders to register for
loyalty programs.
Cardholder registration 24 may populate cardholder and transaction data 56, 58
based on data
collected from registration. The Merchant reporting tool 46 may generate
reports based on
cardholder and transaction data 58 and data maintained by loyalty system 20 as
part of data
storage device 50. Data storage device 50 may maintain a copy of cardholder
and transaction
data 58, or may contain separate data. Loyalty program module 22 may be used
to create and
manage various loyalty programs for merchant system 40.
[00186] Loyalty system 20 may include a merchant interface 28 for interacting
with merchant
system 40 and generating various interfaces for display on merchant system 40.
The merchant
interface 28 may provide a mechanism for merchant system 40 to create,
customize, and
manage loyalty programs and incentives. Data scrub utility 36 may normalize,
scrub, convert
and perform other operations on data received from merchant system 40. Data
scrub utility' 36
47
CA 3102709 2020-12-11
Docket No. 107US
may normalize, scrub, convert and perform other operations on data received
from card issuer
system 80.
[00187] Merchant system 40 may be configured with various computing
applications, such as
merchant reporting tool 46 for generating reports regarding loyalty programs
and for
displaying interfaces received from merchant interface 28 to create,
customize, and manage
loyalty programs and incentives, and view donation results for affinity
entities, and so on. A
computing application may correspond to hardware and software modules
comprising
computer executable instructions to configure physical hardware to perform
various functions
and discernible results. A computing application may be a computer software or
hardware
application designed to help the user to perform specific functions, and may
include an
application plug-in, a widget, instant messaging application, mobile device
application, e-mail
application, online telephony application, java application, web page, or web
object residing,
executing, running or rendered on the merchant system 40. Merchant system 40
is operable to
authenticate merchants (using a login, unique identifier, and password for
example) prior to
providing access to applications and loyalty system 40. Merchant system 40 may
be different
types of devices and may serve one user or multiple merchants. Although
merchant system 40
is depicted with various components in FIG. 1 as a non-limiting illustrative
example, merchant
system 40 may contain additional or different components, such as point of
sale system or
other transaction processing system.
[00188] Merchant system 40 may include one or more input devices, such as a
keyboard,
mouse, camera, touch screen and a microphone, and may also include one or more
output
devices such as a display screen and a speaker. Merchant system 40 has a
network interface in
order to communicate with other components, to serve an application and other
applications,
and perform other computing applications by connecting to network (or multiple
networks)
capable of carrying data including the Internet, Ethernet, plain old telephone
service (POTS)
line, public switch telephone network (PSTN), integrated services digital
network (ISDN),
digital subscriber line (DSL), coaxial cable, fiber optics, satellite, mobile,
wireless (e.g. Wi-Fi,
WiMAX), SS7 signaling network, fixed line, local area network, wide area
network, and
others, including any combination of these. Although only one merchant system
40 is shown
for clarity, there may be multiple merchant systems 40 or groups of merchant
systems 40
distributed over a wide geographic area and connected via e.g. network.
1001891 Merchant system 40 includes data storage devices storing merchant data
42 particular
to the merchant, such as geographic location, inventory records, historical
records, and the
like. Data storage devices may also store customer and transaction data 44
such as customer
48
CA 3102709 2020-12-11
Docket No. 107IJS
names, addresses, contact information, target potential customers, transaction
details, and so
on.
[00190] Merchant system 40 may also include a kiosk or customer interface
device to receive
data from customers and determine location of customers (e.g. a customer is
present in-store).
This data may be used as the location identifier for the customer. This data
may also be used
to trigger the incentive and donation, as the kiosk or customer interface
device provides a
mechanism to verify that the customer is present at the brick and mortar
store. Merchant
system 40 may also include near field communication (NFC) technology to detect
that
customer device 48 is present in a brick and mortar store of merchant to
trigger donations and
incentives.
[00191] Card issuer system 80 may be configured with various computing
applications, such
as card issuer reporting tool 86 for generating reports regarding loyalty
programs and for
displaying interfaces received from loyalty system 20 to create, customize,
and manage
loyalty programs and incentives, and view donation results for affinity
entities, and so on. A
computing application may correspond to hardware and software modules
comprising
computer executable instructions to configure physical hardware to perform
various functions
and discernible results. A computing application may be a computer software or
hardware
application designed to help the user to perform specific functions, and may
include an
application plug-in, a widget, instant messaging application, mobile device
application, e-mail
application, online telephony application, java application, web page, or web
object residing,
executing, running or rendered on the merchant system 40. Card issuer system
80 is operable
to authenticate users (using a login, unique identifier, and password for
example) prior to
providing access to applications and loyalty system 20. Card issuer system 80
may be
different types of devices and may serve one user or multiple card issuers.
Although card
issuer system 80 is depicted with various components in FIGS. 12-13 as a non-
limiting
illustrative example, card issuer system 80 may contain additional or
different components,
such as point of sale system or other transaction processing system.
[00192] Card issuer system 80 may include one or more input devices, such as a
keyboard,
mouse, camera, touch screen and a microphone, and may also include one or more
output
devices such as a display screen and a speaker. Card issuer system 80 has a
network interface
in order to communicate with other components, to serve an application and
other
applications, and perform other computing applications by connecting to
network (or multiple
networks) capable of carrying data including the Internet, Ethernet, plain old
telephone service
(POTS) line, public switch telephone network (PSTN), integrated services
digital network
(ISDN), digital subscriber line (DSL), coaxial cable, fiber optics, satellite,
mobile, wireless
49
CA 3102709 2020-12-11
Docket No. 107US
(e.g. Wi-Fi, WiMAX), SS7 signaling network, fixed line, local area network,
wide area
network, and others, including any combination of these. Although only one
card issuer
system 80 is shown for clarity, there may be multiple card issuer systems 80
or groups of card
issuer systems 80 distributed over a wide geographic area and connected via
e.g. network.
[00193] Card issuer system 80 includes data storage devices storing merchant
data 42
particular to the merchant, such as geographic location, inventory records,
historical records,
and the like. Data storage devices may also store customer and transaction
data 44 such as
customer names, addresses, contact information, target potential customers,
transaction
details, and so on.
[00194] Customer device 48 may include processor and data storage devices.
Customer device
48 may include one or more input devices, such as a keyboard, mouse, camera,
touch screen
and a microphone, and may also include one or more output devices such as a
display screen
and a speaker. Customer device 48 has a network interface in order to
communicate with other
components, to serve an application and other applications, and perform other
computing
applications by connecting to network (or multiple networks) capable of
carrying data
including the Internet, Ethernet, plain old telephone service (POTS) line,
public switch
telephone network (PSTN), integrated services digital network (ISDN), digital
subscriber line
(DSL), coaxial cable, fiber optics, satellite, mobile, wireless (e.g. Wi-Fi,
WiMAX), SS7
signaling network, fixed line, local area network, wide area network, and
others, including any
combination of these. Although only one customer device 48 is shown for
clarity, there may
be multiple merchant systems 40 or groups of customer device 48 distributed
over a wide
geographic area and connected via e.g. network. Customer device 48 is
configured with GPS,
NFC or other location detection hardware to determine location of customer
(e.g. location
identifier) and to verify if the customer is present in a brick and mortar
store of merchant.
[00195] Customer device 48 may be implemented using a mobile phone, mobile
computing
device, tablet, laptop, desktop, wearable device, IVI device, navigation
system and so on.
FIGS. 10 to 13 illustrate an example customer device 48 integrated with or
located within a
vehicle. This may illustrate a customer who is driving the vehicle, for
example. The customer
device 48 may also be carried by a customer who is not associated with a
vehicle.
[00196] Loyalty system 20 (and in particular donation utility 26) may interact
with an affinity
system 60 to provide charitable incentives (e.g. an incentive involving a
donation by the
merchant to an affinity entity). Affinity system 60 may include a data storage
device with
donor data 68. Affinity system 60 may include a loyalty interface 62 for
generating interfaces
populated with data from loyalty system 20.
CA 3102709 2020-12-11
Docket No. 107US
[00197] For example, a correlation may be made between donor data 68 and
benefits accounts
52 or card holder data 58 to determine whether any donors are also
cardholders. If so, then
recommendation engine 30 may recommend an incentive with a donation portion to
the
affinity entity associated with affinity system 60.
1001981 Affinity system 60 may include a registration tool 64 to register
users to become
donors, and potentially cardholders of a loyalty program created by loyalty
system 20. The
registration tool 64 provides a mechanism to collect attributes regarding
donors.
[00199] Affinity system 60 or affinity utility 70 is operable to identifying
donors associated
with an affinity entity. The donors may be cardholders or potential
cardholders for a loyalty
program provided by loyalty system 20. The donors are associated with
attributes, such as the
example attributes described herein in relation to cardholders.
[00200] Affinity system 60 or affinity utility 26 is operable to determine
which donors are
cardholders and which are not. Affinity system 60 or affinity utility 26 is
operable to invite
those donors which are not cardholders to participate in a loyalty program
offering incentives
that include donations to the affinity entity. These may be recommended
incentives based on
their past donations.
[00201] Affinity system 60 or affinity utility 26 is operable to identify a
merchant and a
transaction. Affinity system 60 may contact a merchant upon detecting that a
subset of donors
are also customers, potential customers, or cardholders to arrange for an
incentive provided by
merchant that includes a donation to the affinity entity. The transaction may
identify a good or
service of interest to the donors based on the attributes.
[00202] Affinity system 60 or affinity utility 70 is operable to select an
incentive based on the
affinity entity, the attributes, the merchant, and the transaction. The
incentive defines a benefit
provided by the merchant to the affinity entity upon the occurrence of a
transaction involving
the merchant and one or more donors. In this way, a donor is motivated to
transact with the
merchant due to the donation provided to their preferred affinity entity.
Affinity system 60 or
affinity utility 70 may contact donors encouraging them to transact with a
merchant, as this
may result in an increase in donations to the affinity entity. The merchant
may have access to
a new set of potential customers via affinity system 60. The loyalty system 20
may consider
the buying patterns of donors to recommend incentives with a donation
component. This also
allows merchants to see what customers are also donors to charities in a local
community and
tailor incentives accordingly.
[00203] Affinity system 60 may be used to manage events and the attendee list
may also
receive the recommended incentive. This may increase transactions for
merchants, as well as
increase donations if there is an additional incentive offered by merchants.
The merchant and
51
CA 3102709 2020-12-11
Docket No. 107US
charity may set a donation rate which may be a fixed or proportional amount.
For example, a
percentage of the transaction amount may be given as a donation.
[00204] Referring now to FIG. 14 there is shown a Method 1400 in accordance
with example
embodiments. The Method 1400 may be implemented similar to method steps
described in
relation to FIGS. 1 and 4. That is Method 1400 may correspond to one or more
steps as
described in relation to FIGS. 1 and 4.
[00205] At step 1402 of Method 1400, a request is made by a member for time
slot specific
geo-fenced offers from community merchants, where each offer will include an
incentive from
the merchant that the merchant will make a donation to a community charity of
the member's
choice.
100206] At step 1402 of Method 1400, the loyalty system 20 (e.g. via donation
audit web
service 214/514/714) receives a transmission from customer device 28 that
includes attributes
and the request for offers. The attributes may include an identifier for the
geo-location of a
transmitter of the transmission (e.g. customer device 48), an identifier for a
customer, and
other data relating to offers, such as a specific time period during which
identified goods
and/or services are to be provided by the merchant to the member, and so on.
[00207] For example, a customer may be driving home from work and interested
in
immediately purchasing food for dinner that is to be delivered to the
customer's residence.
The customer device 48 may in a transmission of the request for offers an
identifier that can
be used to identify the location of the customer's residence at which the food
is to be
delivered.
[00208] At step 1404 of Method 1400, the loyalty system 20 sends the request
for offers to
identified eligible merchants in the member's community. Note that the loyalty
system 20 is
operable to process the request to locate merchants who can supply a goods
and/or service as
specified in the request for offers, where each such merchant are located
proximate to the
customer's residence and/or in the customer's community. A customer account 56
may also
store historical data regarding transactions, affinity entities, and offers
related to the customer
for use by recommendation engine 30 to determine offers for Offer Group. The
customer
account 56 may include favorites and a profile for use by recommendation
engine 30 to
determine offers for Offer Group. The customer profile may be maintained by
card issuer
system 80 based on transaction data collected in relation to customers. The
customer may
need to opt-in to loyalty system 20 to permit sharing of transaction data in
customer profile.
[00209] In some example embodiments, instead of process 1000 initiating with a
customer
offer request, an alternative process may initiate with an offer alert by one
or more merchants.
That is, system may detect that customer is proximate to one or more merchants
and send
52
CA 3102709 2020-12-11
Docket No. 107US
alerts regarding offers (e.g. Offer Group) without receiving an offer request.
An alert may also
be transmitted to a merchant to notify the merchant that a customer is
proximate merchant
location (or located within the store) and recommend one or more offers for
the customer.
[00210] The loyalty system 20 can access one or more databases stored at data
storage device
50, using identifiers for the keywords, the customer, and the geo-location of
the transmitter of
the transmission, to look-up information corresponding to offers. The
recommendation engine
30 may generate recommendations for offers for Offer Group based on the
location, keywords
in the request for offers, historical data for the customer, merchant trends,
time of day, day of
the week, season, affinity entity and so.
[00211] The offers may relate to a residential community of the customer,
merchants having a
physical address in the residential community of the customer, merchants
having an attribute
matching the identifier for the keyword (e.g. merchants offering a good or
service referred to),
merchants having an unexpired offer to make a donation to an affinity entity
having a physical
address in the residential community of the customer. For each merchant,
loyalty system 20
may calculate navigation data using the identifier for the geo-location of the
customer device
48 and the physical address of the merchant. Loyalty system 20 uses the
keywords in the
request for offers to identify offers for the Offer Group. Each offer may be
associated with a
timestamp to link the offer to relevant times for the merchant (e.g. off peak
times) or to
relevant times for the customer (e.g. dinner time). The offers may be
associated with
donations to affinity entities and may include details regarding the amount of
the donation and
so on. This may assist the customer in selecting the offer (e.g. the highest
donation to charity).
[00212] At step 1406 of Method 1400, the loyalty system 20 received offers
from the eligible
merchants, and then, at step 1408, assembles and send the eligible offers back
to the member
device in response to the member's request for offers. By way of example, and
not by way of
limitation, loyalty system 20 can transmit the offers for the Offer Group to
the customer
device 48.
[00213] At step 1410, loyalty system 20 receives a selected offer in response
to the
transmission of the offers. The selected offer will include an identifier for
one of the
merchants corresponding to the selected offer in the Offer Group. Information
pertaining to
the selected offer can be derived, including the identifier for the merchant
corresponding to
the selected offer. Also, at step 1410, confirmation notices of the accepted
offer are sent to the
merchant and the requesting member.
[00214] The loyalty system 20 may transmit a logical address for the merchant,
an identifier
for the customer, the navigation data, the corresponding unexpired offer to
make the donation
53
CA 3102709 2020-12-11
Docket No. 107US
to the affinity entity having the physical address in the residential
community of the customer,
and so on, to the merchant system 40, the customer device 48, or other
systems.
[00215] The selected offer may be provided as a token to customer device 48
(e.g. bar code,
token, QR code, file, identifier) for provision to merchant to redeem the
offer. The transaction
may be completed remotely using the customer device 48. The loyalty system 20
may provide
soft alerts and reminders regarding unused selected offers.
[00216] At step 1412 of Method 1400, information is received that a
transaction has been
conducted between the member and the merchant, where the transaction
corresponds to the
offer that was accepted by the member.
[00217] At step 1414 of Method 1400, a survey is sent to the member requesting
the member's
evaluation of the transaction with the merchant. The completed survey is sent
by the member
and thereafter shared with all members so to allow crow-sharing of the
merchant evaluation
process. The completed survey can also be sent oto the merchant to assist the
merchant in
evaluating its customer service.
[00218] The navigation data, as described herein, may be used to populate a
mapping
application with location identifiers for each offer in the Offer Group. For
example, little heart
symbols may be used to mark a map with corresponding merchants that will make
donations
based on offers in the Offer Group. The navigation data may be used to
populate a real time
navigation system in a vehicle device or other customer device 48. A mapping
interface may
also be used by the customer to provide location information such as an area
of interest for
offers, a perimeter for offer locations, specific sections of the map for
offer locations, and so
on. The offers may be related to a street on a map, or several proximate
streets to give
customer a number of offers for a particular location of interest.
[00219] The herein described databases for storage media may comprise primary,
secondary,
and/or tertiary storage media. Primary storage media may include memory such
as random
access memory and/or read-only memory, for example. Secondary storage media
may include
a mass storage such as a magnetic or solid-state hard drive. Tertiary storage
media may
include removable storage media such as a magnetic or optical disk, a magnetic
tape, a solid-
state storage device, etc. In certain implementations, the storage media or
portions thereof may
be operatively receptive of, or otherwise configurable to couple to, other
components of a
computing platform, such as a processor. Data storage device 50 may provide a
persistent
store for databases described herein.
[00220] In at least some implementations, one or more portions of the herein
described storage
media may store signals representative of data and/or information as expressed
by a particular
state of the storage media. For example, an electronic signal representative
of data and/or
54
CA 3102709 2020-12-11
Docket No. 107US
information may be "stored" in a portion of the storage media (e.g., memory)
by affecting or
changing the state of such portions of the storage media to represent data
and/or information
as binary information (e.g., ones and zeros). As such, in a particular
implementation, such a
change of state of the portion of the storage media to store a signal
representative of data
and/or information constitutes a transformation of storage media to a
different state or thing.
[00221] Some portions of the preceding detailed description have been
presented in terms of
algorithms or symbolic representations of operations on binary digital
electronic signals stored
within a memory of a specific apparatus or special purpose computing device or
platform. In
the context of this particular specification, the term specific apparatus or
the like includes a
general-purpose computer once it is programmed to perform particular functions
pursuant to
instructions from program software. Algorithmic descriptions or symbolic
representations are
examples of techniques used by those of ordinary skill in the signal
processing or related arts
to convey the substance of their work to others skilled in the art. An
algorithm is here, and
generally, is considered to be a self-consistent sequence of operations or
similar signal
processing leading to a desired result. In this context, operations or
processing involve
physical manipulation of physical quantities. Typically, although not
necessarily, such
quantities may take the form of electrical or magnetic signals capable of
being stored,
transferred, combined, compared or othenvise manipulated as electronic signals
representing
information. It has proven convenient at times, principally for reasons of
common usage, to
refer to such signals as bits, data, values, elements, symbols, characters,
terms, numbers,
numerals, information, or the like. It should be understood, however, that all
of these or
similar terms are to be associated with appropriate physical quantities and
are merely
convenient labels.
[00222] Unless specifically stated otherwise, as apparent from the following
discussion, it is
appreciated that throughout this specification discussions utilizing terms
such as "processing,"
"computing," "calculating,", "identifying", "determining", "establishing",
"obtaining", and/or
the like refer to tangible actions or processes of a specific apparatus, such
as a special purpose
computer or a similar special purpose electronic computing device that
generate discernible
results. In the context of this specification, therefore, a special purpose
computer or a similar
special purpose electronic computing device is capable of manipulating or
transforming
signals, typically represented as physical electronic or magnetic quantities
within memories,
registers, or other information storage devices, transmission devices, or
display devices of the
special purpose computer or similar special purpose electronic computing
device. In the
context of this particular patent application, the term "specific apparatus"
may include a
CA 3102709 2020-12-11
Docket No. 107U S
general-purpose computer once it is programmed to perform particular functions
pursuant to
instructions from program software.
[00223] Reference throughout this specification to "one example", "an
example", "certain
examples", or "exemplary implementation" means that a particular feature,
structure, or
characteristic described in connection with the feature and/or example may be
included in at
least one feature and/or example of claimed subject matter. Thus, the
appearances of the
phrase "in one example", "an example", "in certain examples" or "in some
implementations"
or other like phrases in various places throughout this specification are not
necessarily all
referring to the same feature, example, and/or limitation. Furthermore, the
particular features,
structures, or characteristics may be combined in one or more examples and/or
features.
[00224] While there has been illustrated and described what are presently
considered to be
example features, various other modifications may be made, and equivalents may
be
substituted, without departing from claimed subject matter. Additionally, many
modifications
may be made to adapt a particular situation to the teachings of claimed
subject matter without
departing from the central concept described herein. Therefore, embodiments
may not be
limited to the particular examples disclosed but may also include all aspects
falling within the
scope of appended claims, and equivalents thereof
[00225] The various steps or acts in a method or process may be performed in
the order shown
or may be performed in another order. Additionally, one or more process or
method steps may
be omitted, or one or more process or method steps may be added to the method
and
processes. An additional step, block, or action may be added in the beginning,
end, or
intervening existing elements of the methods and processes. Based on the
disclosure and
teachings provided herein, a person of ordinary skill in the art will
appreciate other ways
and/or methods for various implements. Moreover, it is understood that a
functional step of
described methods or processes, and combinations thereof can be implemented by
computer
program instructions that, when executed by a processor, create means for
implementing the
functional steps. The instructions may be included in non-transitory computer
readable
medium that can be loaded onto a general-purpose computer, a special purpose
computer, or
other programmable apparatus.
[00226] In the preceding detailed description, numerous specific details have
been set forth to
provide a thorough understanding of embodiments described herein. However,
some
embodiments may be practiced without these specific details. In other
instances, methods and
systems that would be known by one of ordinary skill have not been described
in detail so as
not to obscure claimed subject matter.
56
CA 3102709 2020-12-11
