Note: Descriptions are shown in the official language in which they were submitted.
DEMANDE OU BREVET VOLUMINEUX
LA PRESENTE PARTIE DE CETTE DEMANDE OU CE BREVET COMPREND
PLUS D'UN TOME.
CECI EST LE TOME 1 DE 2
CONTENANT LES PAGES 1 A 127
NOTE : Pour les tomes additionels, veuillez contacter le Bureau canadien des
brevets
JUMBO APPLICATIONS/PATENTS
THIS SECTION OF THE APPLICATION/PATENT CONTAINS MORE THAN ONE
VOLUME
THIS IS VOLUME 1 OF 2
CONTAINING PAGES 1 TO 127
NOTE: For additional volumes, please contact the Canadian Patent Office
NOM DU FICHIER / FILE NAME:
NOTE POUR LE TOME / VOLUME NOTE:
SYSTEMS AND METHODS FOR PROXY CARD AND/OR WALLET
REDEMPTION CARD TRANSACTIONS
CROSS-REFERENCE TO RELATED APPLICATION
[00011
This application claims priority to: U.S. Provisional Patent Application
Serial No.
61/776,594. filed March 11, 2013 and entitled "Systems and Methods for Proxy
Card and/or Wallet
Redemption Card Transactions" and U.S. Provisional Patent Application Serial
No. 61/779,334,
filed March 13,2013 and entitled "Systems and Methods for Proxy Card and/or
Wallet Redemption
Card Transactions;" this application is a continuation-in part of U.S. Patent
Application No.
14/147,330, filed January 3,2014, and entitled "System and Method for
Providing a Security Code"
which claims priority to U.S. Provisional Patent Application Serial No.
61/748,679, filed January
3, 2013 and entitled "System for Managing CVV Information in Electronic
Wallet" and U.S.
Provisional Patent Application Serial No. 61/799,500, filed March 15, 2013 and
entitled "System
and Method for Providing a Security Code;" U.S. Patent Application No.
14/147,330 is a
continuation-in part of U.S. Patent Application No. 13/483,711, filed May 30,
2012, and entitled
"System for Payment via Electronic Wallet" which claims priority to U.S.
Provisional Patent
Application Serial Nos. 61/491,791 and 61/491,813, both filed May 31, 2011 and
entitled "A
System for Payment via Electronic Wallet;" and U.S. Provisional Patent
Application Serial Nos.
61/496,397 and 61/496,404, both filed June 13, 2011 and entitled "System,
Method, and Apparatus
for Creating and Distributing a Transaction Credit" additionally, U.S. Patent
Application No.
13/483,711 is a continuation-in-part of International Application Serial No.
PCT/US11/40055,
filed June 10, 2011 and entitled, "Efficient Stored-Value Card Transactions"
which claims priority
to U.S. Provisional Patent Application Serial Nos. 61/354,469, filed June 14,
2010, 61/354,470,
tiled June 14,2010, and 61/360,327, filed June 30, 2010; U.S. Patent
Application No. 13/483,711
is also a continuation-in-part of International Application Serial No.
PC1/1JS1 I /20570, filed
January 7, 2011 and entitled "A System for Processing, Activating and
Redeeming Value Added
Prepaid Cards," which claims priority to U.S. Provisional Patent Application
Serial No.
61/293,413, filed January 8,2010; U.S. Patent Application No. 13/483,711 also
is a continuation-
in-part of International Application Serial No. PC171.1S11/49338, filed August
26, 2011 and
entitled "Prepaid Card with Savings Feature," which claims priority to U.S.
Provisional Patent
Application Serial No. 61/377,800, filed August 27, 2010.
1
Date Recue/Date Received 2023-05-17
100021
BACKGROUND
100031 The disclosure generally relates to the use of electronic stored-
value cards in electronic
transactions.
100041 The electronic transaction market is currently filled with many
types of credit cards,
debit cards, stored value cards, and loyalty cards, all of which may be
offered by different issuers,
vendors, and providers. Some of the cards are tailored to be redeemed from a
retailer while others
may be redeemed by financial institutions. Other cards have promotions
attached to them, e.g.,
loyalty cards. However, the increasing quantity and complexity of the cards
makes organization
and redemption increasingly difficult, thus potentially hindering the growth
of the market. For
example, a user may not know or remember that the user has a stored value card
for a specific store
during a purchase at that store because the user has too many stored value
cards. Also, a user may
not understand the various types of promotions available to him using a card
in combination with
a loyalty card, and as such, may not benefit from promotions applicable to the
user's purchase.
=
2
=
Date Regue/Date Received 2023-05-17
Historically, cards have been embodied in a tangible medium such as plastic,
and thus are
susceptible to loss, Ilia, or simply being lefl at home when needed. With the
continued growth in
card-based transactional offerings provided to consumers, many consumers are
faced with the
burdensome task of organiii ng, managing, tracking, transporting, and storing
all of thei r credit,
debit, stored-value, loyalty, and other types of merchant, vendor, and
provider issued cards. What
today's consumers need is a more efficient, secure, and effective way of
accessing and using their
card-related assets.
SI JMMARY
[00051 A computer implemented method may comprise receiving authentic au
oninfonnation
of a proxy card, and associating the proxy card with an el eetronic wallet,
wherein associa ti ng the
proxy card with the electronic wallet allows secure access to the electronic
wallet and the sources
of value stored within the electronic wallet when the proxy card is presented
at a point of sale. The
proxy card may also be used to provide access to sources of value stored
within a second electronic
wallet stored within the first electronic wallet.
[00061 A system may comprise a proxy card comprising authentication
information, and an
electronic wallet associated with the proxy card, wherein the association of
the electronic wallet
with the proxy card allows secure access to the electronic wallet when the
proxy card is presented
at a point of sale.
[00071 A wallet redemption card may comprise a rewriteahic magnetic
stripe, a smart chip, a
wireless communicator operably connected to the wallet redemption card or the
smart chip thereon
(e.g., NFC), and an interface operably connected between the rewriteable
magnetic stripe and the
smart chip.
BR I El: DESCRIIY FIONOFTHE DRAWINGS
[00081 Figure 1 is a flowchart depicting an embodiment of a method for
providing a security
code.
[00091 Figure 2 is a flowchart depicting another embodiment of a method
for providing a
securitycode.
100101 Figure 3 is a schematic illustration of an embodiment of a system
for providing a
se un tveode
[0011] Figures 4A, 5A, 5B, and 5C are schematic representations of an
electronic value token
transaction processing system in accordance with at least one embodiment.
3
Date Recue/Date Received 2023-05-17
[0012j Figure 4B illtsstrates an exemplary embodiment of an electronic
wallet
100131 Figures 6A, 6B, and6C arc front perspective views of
representative individual proxy
cards in accordance with atleast one embodiment.
[0014j Figure 6D is front perspective view of representative individual
wallet redemption card
in accordance with at least one embodiment.
[00151 Figure 6E is a front perspective view of a representative user
device in accordance with
at least one embodiment
[00161 Figure 7A is a flowchart depicting exemplary processes utilized by
an electroni c value
token transac ti on computer for creating an electronic wallet or
adding/redccming value tokens
to/from the electronic wallet in accordance with at least one embodiment.
[00171 Figure 713 i s a flowchartdepieting exemplary processes utilized
by an electronic value
token transaction computer for creating an electronic sub-wallet or
adding/redeeming value tokens
to/from the electronic sub-wallet in accordance with at least one embodiment.
100181 Figure 8 illustrates a particular machine suitable for
implementing the several
embodiments of the disclosure.
[00191 Figures 9A-D illustrates a series fuser interface screens and prompts
in accordance with
at least one embodiment.
DETAILEIDESCRIPTION
[00201 Disclosed herein are systems and methods for using stored-value
cards, such as
electroniestored-value cards (he rei nafter "eSVC" or"eSVCs"). Particularly,
the systems and
methods disclosed herein may provide security codes necessary for payments
transactions
without violating any rules (e.g., laws, regulations, guidelines, or
combinations thereof)
prohibiting the storage of a security code for a card (e.g., an cSVC).
Embodiments for the
provision of a security code as disclosed herein may also be included in
methods and systems for
distributing open loop eSVCs. Additionally, the disclosed systems and methods
may provide
electronic stored-value card users a guided process for registering electronic
stored-val ue cards
into existing and new electronic wallets, andthe use of value tokens in the
electronic wallet(s)
for electronic transactions.
[0021] Acquisition and/or purchase of a stored-value card (e.g., an
electronic stored-value
card) may involve an account vendor, a redeeming merchant, and an account
issuer. In various
embodiments, the account vendor, redeeming merchant and account issuer may be
the same,
4
Date Recue/Date Received 2023-05-17
different, or related entities. The point of sale where the electronic stored-
value card is
purchased and/or acquired is referred to herein as the account vendor or
simply vendor. An
entity that will accept value contained in the electronic stored-value card
for business
transactions, for example, as tender for a purchase, is referred to as a
redeeming merchant. An
entity that provides the financial backing andior payment processing accessed
via use of the
electronic stored-value card is referred to as the account issuer, or simply,
issuer. Account issuers
may include direct issuers of electronic stored-value cards such as store-
branded cards (e.g.,
Macy's, Target), and in some embodiments the account vendor may also be the
account issuer
and/or the redeeming merchant Account issuers also may include banks,
financial institutions,
and processors such as VISA, Mastercard, American Express, etc., and
electronic stored-value
cards issued by such institutions may be readily accepted by a number of
redeeming merchants
to conduct transactions such as purchases. Account issuers may be in various
industries, such as
the entertainment, health, medical, pharmaceutical industries. For example,
the account issuer
may be a pharmaceutical company utilizing promotional electronic stored-value
cards for
pharmaceutical products. In some instances, an electroni c stored-value card
may be sold and/or
issued at the same or different account vendor (e.g., account vendor is Store
X or a different or
unrelated Store Z). In such instances, the Store X branded electronic stored-
value card may be
issued by Store X, by Store Z, or by a third party such as bank or financial
institution.
[0022] Under
current rules (e.g., the VISA U .S.A. Cardholder Information Security Program
Payment Application Best Practices and the Payment Card Industry Payment
Application Data
Security Standard) the needed security code may not be readily available to
certain parties in a
transaction. For example, when a user converts a physical card to an eSVC and
discards the
physicaleard, or when a user obtains an eSVC via other means described herein,
the security
code may be unavailable to the user, to the merchant, to an electronic wallet
provider, to the
eSVC processor, or combinations thereof when the user makes a transaction. As
such, parties to
a payment transaction, i.e., entities such as the processor o fan eSVC, the
merchant, the user, or
any other entity which is prohibited from storing a security code may be
dependent upon the
availability of the security code from the issuer of the eSVC. The disclosed
systems and
methods allow for the calculation and provision of the security code of the
eSVC by entities
prohibited from storing and retaining the security code.
Date Recue/Date Received 2023-05-17
100231 As used herein, "electronic-stored value card" or "cSVC" refers to
an electronic
embodiment of an account that may be used to transact business with a merchant
willing to
accept a value (e.g., points, miles, dollars, or any other measure of value
such as a value token
described hetet nbelow), for example as lender for a purchase or discount for
a purchase. As used
herein, "electronic stored-value card" or "cSVC" may additionally or
alternatively refer to an
electronic embodiment of an account used for promotional and/or marketing
purposes. The
accounts may comprise credit accounts, debit accounts, gift accounts,
telephone accounts, loyalty
accounts, membership accounts, ticket accounts, entertainment accounts, sports
accounts,
prepaid accounts, discount accounts, healthcare accounts, the like, or
combinations thereof.
Such accounts may be associated with corresponding physical cards, including
credit cards, debit
cards, gift cards, telephone cards, loyalty cards, membership cards, ticket
cards, entertainment
cards, sports cards, prepaid cards, discount cards, healthcare cards, the
like, or combinations
thereof. Such accounts may additionally or alternatively comprise electronic
accounts, such as
electronic credit accounts, electronic debit accounts, electronic gift
accounts, electronic
telephone accounts, electronic loyalty accounts, electronic membership
accounts, electronic
ticket accounts, el ectronic entertai nine ntaccounts, electronic sports
accounts, electronic prepaid
accounts, electronic discount accounts, electronic healthcare accounts, the
like, or combi nati ons
thereof. In embodiments, the value of an electronic stored-value card may be
embodied as an
"electronic value token" or "value token," both of which are described in
detail hereinbelow.
100241 As used herein, "card information" refers to information
associated with an electronic
stored-value card, associated with the account from which the electronic
stored-value card is
based, associated with the physical card with which the account is associated,
or combinations
thereof. The card information is used for an electronic transaction with a
merchant using the
electronic stored-value card. In embodiments, card information may comprise a
cardholder
name, card name, an account number (e.g., primary account number), a service
code, a UPS, a
phone number, an identification number (e.g., driver's license number,
passport number, visa
number, social security number, IP address), an expiration date, a billing
address, or
combi nations thereof.
100251 As used herein, a "security code" refers to a security code of a
physical card or eSVC
which is subject to the rules against storage and retention of such codes. In
embodiments a
security code may comprise a series of three or four digits which have been
associated with a
6
Date Recue/Date Received 2023-05-17
physical card or eSVC by the issuer. In embodiments a security code may
comprise a series
digits, letters, symbols, or combinations thereof In embodiments, a security
code is in addition
to a caid account number which is embossed or printed on the card and is also
in addition to a
personal i de nti fi cation number or password associated with the card. In
embodiments, e.g.,
when the stored-value card (e.g., eSVC) is not present for physical inspection
by a receiving
merchant (e.g., an online or telephonic transaction), a security code serves
to verify that a
requested stored-value card (e.g., eSVC) transaction is a valid and/or
authorized transaction
request by a cardholder (e.g., a person rightfully possessing the card andior
authorized to request
a transaction). In embodiments, a security code may comprise a card security
cock (CSC), a card
verification value (CVV or CVV2), a card verification value code (CVVC), card
verification
code (CVC or CVC2), verification code (V-code or V code), card code
verification (CCV),
credit cardID(CID or CCID), or combinations thereof.
W261 Disclosed herein are embodiments of methods for providing a
security code of an
electroniestored-value card. The various steps of the methods may be omitted,
substituted, and
rearranged except where specified hereinbelow. The methods described hereinbel
ow are
applicable for open-loop stored-value cards and for closed-loop stored-value
cards.
[0027] Figure I shows a flow chart of an embodiment of a method disclosed
herein. The
embodiment of the method shown in Figure 1 begins at block 20.
100281 At block 20, an eSVC (e.g., eSVC El of Figure 3) may be obtained,
for example, by a
user or consumer. The user or consumer may comprise a person or an automated
device
configured to make purchases under various conditions. The cSVC may be
obtained by
converting a physical card (e.g., credit cards, debit cards, gift cards,
telephone cards, loyalty
cards, me mbership cards, ticketcards, ente rtai tun e nt cards, sports cards,
pre pa icleard s, discount
cards, healthcare cards, the like, or coin bi nations thereof) to a digital
format (e.g., by submission
of card information to an electronic wallet provider). Additionally or
alternatively, the electronic
stored-value card maybe obtained (e.g., sent, received, delivered, fetched,
acquired, presented,
or combinations thereof) via various communication means, including S MS,
email, video (e.g.,
YouTube, Vimeo, Skype, video message, or combinations thereof), instant
message, a website,
anoni inc storage medium, a cloud storage system, other means for
electronically obtaining the
electronic stored-value card, or combinations thereof. For example, in an
embodiment the eSVC
may be an eGi ft delivered as a unithnn re source locator ("URL") to a user
through email or any
7
Date Recue/Date Received 2023-05-17
other channel (e.g., SMS, Facebook wall post, and Twitter), the URL refers to
an HTML page
that displays the e Gi ft with appropriate logo, terms and conditions,
redemption instructions, card
number, security code (CVV2) and expiration date. In an embodiment the eSVC
may be an
eCode delivered directly to the user (e.g., via SMS, Instant Message, and
email) and includes a
primaryaccount numbeasecurity information,and an expiration date. In an
embodiment, the
eSVC may be directly provisioned to a user's el ea troni owalle t. In
embodiments, a user of the
eSVC may use the obtained eSVC, for example, by clicking on a link to redeem
the eSVC (e.g.,
in the form of a e-gift, discount, credit, promotional offer, or combinations
thereof, etc.) at a
merchant online transaction portal, by accessing the eSVC in an electronic
wallet provided by an
electronic wallet provider and stored by the electronic wallet provider, by
using an eSVC
identifier (e.g., number, promo code, discount code) via a transaction portal
(e.g., of a merchant),
or om bi nati on s thereof.
100291 In
embodiments, before the user obtains (e.g., receives, activates, redeems, or
combi nations there of) the eSVC, the eSVC provider, the e-wallet provider,
the cS VC processor,
the eSVC issuer, the merchant, or combinations thereof may provide fraud
mitigation. In an
embodiment, providing fraud mitigation may comprise blocking access to an eSVC
before a user
views the eSVC, blocking access to an eSVC before a user activates the eSVC,
or both. In an
additional or alternative embodiment, providing fraud mitigation may comprise
determining a
digital finaerprint of a user device (e.g., user device )4), at the time a
user attempts to view an
eSVC to determine the risk associated with the user, the eSVC, or both. In an
additional or
alternative ernbodi me nt, providing fraudmitigation mayoom pri se withholding
the providing of
the eSVC (e.g., withholding the delivery of redemption information for the
eSVC). In an
additional or alternative embodiment, providing fraud mitigation may comprise
determining a
geographic location of the eSVC and/or user and pausing the providing of the
eSVC fora period
of time determined by the geographic location. For example, the providing of
the eSVC may be
held for a longer period of time in geographic locations known or determined
to be of high risk
of fraud, and the providing of the eSVC may be held for a short period of time
or for a period of
time comprising zero in geographic locations known or determined to be of low
or no risk of
fraud.
8
Date Reeue/Date Received 2023-05-17
[00301 In embodiments, before the user obtains (e.g., receives,
activates, redeems, or
combinations thereof') thee S VC, the eSVC provider, the c- wallet provider,
the c S VC processor,
the eSVC issuer, the merchant, or combinations thereof may not associate an
account and/or
value with the eSVC until the user takes an affirmative step to purchase the
eSVC. For example,
an account and/or value for the eSVC may not be associated with the eSVC until
a user clicks on
a URL, responds to an email, responds to an SMS, a voicemail, other
notification, or
combinations thereof to obtain the eSVC.
[0031] Various registration, authentication, allocation, and provisioning
techniques may be
performed prior to use of the eSVC which would be recognized by one skilled in
the art with the
aid of this disclosure. For example, the user may register the eSVC in one or
more electronic
wallets (e.g., electronic wallet 10 of Figure 3). As used herein, an
"electronic wallet" (also
referred to as "e-wallet") may include an electronically maintained data file
(e.g., maintained on
a computer device of a provider of the electronic wallet) which may comprise
an electronic
stored-value card( s), authentication information, rules for use, sub-wallets
(e.g., for separately
maintainingelec troni estored-value card-related information), and electronic
value tokens (e.g.,
electronic representations of the monetary and/or other value associated with
the electronic
stored-value card-related information contained in the e-wallet/sub-wallet).
In certain
embodiments (e.g., as reflected in Figures 9A-D) a user may create an e-wall
ei, e stablish rules
for the e-wallet, provision the e-wallet, and access the e-wallet to
facilitate electronic
transactions. Suitable processes for registering the eSVC are disclosed in
International
Application Serial No. PCT/US13/26501; filed on February 15, 2013, and
entitled "System and
Method of Registering Stored-Value Cards Into Electronic Wallets." Examples of
techniques for
authenticating, allocating, and provisioning an cSVC are described
hereinbelow.
[00321 To use the obtained eSVC, the user may be required to supply a
security code of the
eSVC. Because the eSVC is a virtual card, the user may not have the security
code (e.g., the
CVV2).
100331 At block 22 a request for a security code is received. The
security code provider
and/or a computer device of a security code provider inay receive the request
for a security code,
e.g., from a user of the cSVC, from a merchant, from an electronic wallet
provider, or
combinations thereof. For example, the user of the eSVC may send a request for
a security code
in order to use the eSVC for a purchase of a good or service from a merchant
(e.g., in an open
9
Date Recue/Date Received 2023-05-17
loop transaction network). To request the needed security code, the user may
utilize a user
device (e.g., user device 14 of Figure 3) to contact a computer device (e.g.,
computer device 12,
13, 18, or 19 of Figure 3) of the security code provider. In another example,
a merchant (c .g.,
which is not also the eSVC issuer and cannot store the security code) may send
a request for a
security code in order to accept the eSVC for the purchase of a good or
service by the user. To
request the needed security cock, the merchant may utilize a computer device
(e.g., merchant
computer device 16 of Figure 3)to contact a computer device (e.g., computer
device 12, 13, 18,
or 19 of Figure 3) of the security code provider. In another example, a
provider of an eSVC
and/or a user's electronic wallet (e.g., which is not also the eSVC issuer and
cannot store the
security code) may send a request for a security code, e.g., as an
intermediary between the user
of the eSVC and the security code provider. To request the needed security
code, the electronic
wallet provider may utilize a computer device (e.g., provider computer device
12 of Figure 3) to
contact a computer device (e.g., computer device 13, 18, or 19 of Figure 3) of
the security code
provider. Before sending a request for the security code, the electronic
wallet provider may
identify the brand of the issuer of the eSVC. contact the issuer of the eSVC
(e.g., via an issuer
computer device 19 of Figure 3), receive a card token from the issuer of the e
SVC, and associate
the card token with the request for a security code of the eSVC. A "card
token" may comprise a
fraud-prevention identifier, such as a temporary code or access key to the
computer device of the
issuer. In an embodiment, an entity (e.g., merchant, processor of the eSVC,
provider of the
eSVCandiore-wallet) which needs to request the security is also the security
code provider. In
such an embodiment, the entity would internally request the security code,
e.g., from a security
code unit on the computer device of such an entity.
[0034] In
embodiments, the security code provider may comprise an entity separate from a
processor of the eSVC, the eSVC issuer, the electronic wallet provider, and
the merchant. In
alternative embodiments, the security code provider may comprise a party which
is the provider
of the user's electronic wallet, the merchant, the issuer of the cSVC, the
processor of the eSVC,
or combinations thereof. In embodiments. the security code provider may
comprise a party
which is: the processor of the eSVC; alternatively, the issuer of the eSVC;
alternatively, the
electronic wallet provider; alternatively, the merchant; alternatively, the
electronic wallet
provide rand the merchant; alternatively, the electronic wallet provider and
the processor of the
eSVC; alternatively, the electronic wallet provider and the eSVC issuer;
alternatively, eSVC
Date Recue/Date Received 2023-05-17
issuer and the eSVC processor; alternatively, the eSVC issuer and the
merchant; alternatively,
the cS VC processor and the merchant; alternatively, the electronic wallet
provider, the c SVC
issuer, and the e S VC processor; alternatively, the electronic wallet
provider, eSVC processor,
and the merchant; alternatively, the electronic wallet provider, the eSVC
issuer, and the
merchant; alternatively, the merchant, the eSVC issuer, and thc cSVC
processor; alternatively,
the electronic wallet provider, the eSVC issuer, the eSVC processor, and the
merchant. In
embodiments where the security code provider is also the eSVC issuer, rules
may allow the
entity to store and/or retain a security code; however. such an entity may
also choose to calculate
the security code according to the present disclosure or delegate such
calculating responsibilities
to an agent of the security code provider. In an embodiment, the security code
provider is an
entity which calculates the security code to provide the security code but
does not store or retain
the security code (or versions thereof, e.g., received-calculated security
code, recalculated
security code, etc.).
100351 At block 24, the security code is calculated (e.g., by the
security code provider). man
embodiment where the security code provider comprises the providerofthe
electronic wallet, the
electmnic wallet provider's computer device (e.g., computer device 12 of
Figure 3) may calculate
the security code upon receiving a request for the security code (e.g., from
the user device 14 of
Figure 3). In an embodiment where the security code provider comprises the
processor of the
eS VC, the processor's computer de vi cc (e.g., computer device 18 of Figure
3) may calculate the
security code upon receiving a request for the security code (e.g., from the
electronic wallet
provider's computer device 12 or from the user device 14 of Figure 3).
[00361 In embodiments, calculating the security code by the security code
provider may
comprise calculating the security code using the card information of the eSVC,
wherein the card
infbnnation comprises a primary account number, an expiration dab", and a
security information of
the eSVC. In embodiments where a party (e.g., the electronic wallet
serviceprovider) is allowed
under regulations and laws to store the security code, the providercomputer
device 12 may store
the calculated security code, e.g., in an electronic wallet.
[00371 At block 26, the calculated security code is provided. In an
embodiment, the electronic
wallet provider (e.g., via a computer device 12 of Figure 3) may provide
(e.g., send) the calculated
security c ode to user (e.g., via user device 14 of Figure 3) (e.g., without
communication with an
eSVC processor). That is, in embodiments, the electronic wallet provider
(e.g., via provider
11
Date Recue/Date Received 2023-05-17
computer device 1201 Figure 3) may receive a calculated security code from the
sec uritycode
provider (e.g., via security code provider computer device 13 of Figure 3, for
example, in
embodiments where the electronic wallet provider and security code provider
are different entities)
and provide the calculated security code to the user (e.g., via user device 14
of Figure 3)without
communication with the processor of the eSVC (e.g., via processor computer
device 18of Figure
3), or the electronic wallet provider may calculate the security code (e.g.,
via provider computer
device 12 of Figure 3, for example, in embodiments where the security code
provider comprises
the electronic wallet provider) and provide the calculated security code to
the user (e.g., via user
device 14 ofFigure 3) without communication with the processor of the eSVC
(e.g., via processor
computer device 18 of Figure 3). In additional or alternative embodiments, the
processor ofthe
eSVC
viitoomputer device 18 of Figure 3) may provide (e.g., send) the calculated
security
codetotIn provider like electronic wall et (e.g., computer device 12 of
Figure 3), to the user (e.g.,
via user device 14 of Figure 3), to the merchant (e.g., via merchant computer
device 16 of Figure
3), or combinations thereof. Ifthe electronic wallet provider receives the
calculated securitycode
from the processor of-the eSVC, the electronic wallet provider may then
provide (e.g., send) the
calculated security code to the user (e.g., via user device 14 of Figure 3),
to the merchant (e.g., via
merchant computer device 16 of Figure 3, or both. In embodiments, providing
the security code
may include displaying the security code to the user (e.g., via a display on
the user device 14 of
Figure 3), to the merchant (e.g., via merchant oomputer device 16 of Figure
3), or both. In
embodiments, sending the securitycode may include various communication means,
including
SMS, email, video (e.g., YouTube, Vimeo, Skype, video message, or combinations
thereof),
instant message, a wcbsite, an online storage medium, a aloud storage system,
other means for
electronically obtaining the electronic stored-value card, or combinations
thereof.
10038] At
block 28, the calculated security code iseliminated from databases of the
security
code provider. As used herein, the term "eliminate" includes the lack of
retention and/or storage of
a security code, a calculated security code, a received-calculated security
code, a recalculated
security code, or combinations thereof. Additionally or alternatively, the
term "eliminate" include
the erasure of a security code, a calculated security code, a received-
calculated security code, a
recalculated security code, or combinations thereof. In an embodiment where
the electronic wallet
provider is the security code provider, the electronic wallet provider may
eliminate the calculated
security code from databases of the electronic wallet provider. In an
additional or alternative
12
Date Recue/Date Received 2023-05-17
cmboditnent where the processor of the cS VC is the security code provider,
the processor may
eliminate the calculated security code from databases of the processor. In
embodiments, the step of
eliminating is performed by an entity which is not also the issuer of the
eSVC.
[0039] Once the user or merchant receives the calculated security code,
the user and/or
merchant may then use the calculated security code in a transaction.
[0040] Figure 2 shows a flow chart of another embodiment of a method
disclosed herein.
The embodiment of the method of Figure 2 may be used in addition to or in the
alternative to the
method of Figure 1. Moreover, any of the steps of the method of Figure 2 may
be used in
combination or in the alternative with any of the steps of the method of
Figure 1, and vice versa.
The embodiment of the method shown in Figure 2 begins at block 30.
[0041] At block 30, a calculated security code is received (e.g.,
calculated according to block
24 o f the method in Figure 1). In the embodiments disclosed herein, the
calculated security code
which is received may be referred to as a "received-calculated security code."
The calculated
security code may be received by an electronic wallet provider, the issuer of
the eSVC, the
processor of the eSVC, the merchant, or combinations:thereof. In an
embodiment, the electronic
wallet provider may receive the calculated security code. For example, a
merchant (e.g., via
merchant computer device 16 of Figure 3), processor of the eSVC (e.g., via
computer device 18),
or both, may contact the electronic wallet provider and/or e SVC provider
(e.g., via the computer
device 12 of Figure 3) to complete a transaction with a consumer or user and
requiring the
calculated security code of the eSVC. In an additional or alternative
embodiment the processor of
the cSVC (e.g., via the computer device 18) may receive the calculated
security code. For example,
a merchant (e.g., merchant computer device 16 of Figure 3), electronic wallet
provider and/or
eSVC provider ( e .g., via computer device 12 of Figure 3), or combinations
thereof, may contact
the processor (e.g., via the computer device 18 of Figure 3) to complete a
transaction with a
consumer or user and requiring the calculated security code oldie eSVC.
10042] In embodiments, a reque St to process a payment transaction may be
associated with or
comprise the received-calculated security code, and the provider of the e-
wallet and/or provider of
the eSVC (e.g., via computer device 12), the processor of the eSVC (e.g., via
computer device 18)
may receive a TCCILIGSt to process a payment transaction associated with the
received-calculated
security code. In embodiments where a party (e.g., an entity which includes
the issuer of the
13
Date Recue/Date Received 2023-05-17
eSVC) is allowed under rides, regulations andlor laws to store the security
code, the party may
store the received-calculated sec tuity code ma database.
[00431 At
block 32, the security code is recalculated (e.g., by an entity which is the
security
code provider or by an entity which is not the security code provider). In
embodiments, the
provider of the e-wallet and/or eSVC (e.g., via computer device 12 of Figure
3), the processor
(e.g., via computer device 18), the merchant (e.g., via merchant computer
device 16), or
combinations thereof may recalculate the security code upon receiving a
request to process a
transaction with the eSVC (e.g., from the user, processor, merchant, or
combinations thereof).
[00441 In
embodiments, recale ulati ngthe security code by the security code provider
may
comprise recalculating the security code using the card information ofthe
SVC, wlwreintlus card
information comprises a primary account number, an expiration date, a security
information, a
serviceemle, orcombi nations thereof oldie eSVC. In embodiments where a party
(e.g., an entity
which is also the issuer of the eSVC) is allowed to store the security code,
the recalculated security
code may be stored.
[0045] At
block 34, a determination is made whether thereceived-calculatedseeuritycode
matches the recalculated security code_ In embodiments, the provider of the
eSVC and/or e-wallet,
the eSVC processor, the merchant, or combinations thereof; may determine
whether the received-
calculated security code matches the recalculated security code. Ifthe
received-calculated security
code matchesthe roe alculated security code, then the payment transaction may
be processed, e.g.,
as in b1ock36; additionally or alternatively, the codes may he eliminated,
e.g., as in block 38, after
tran sac tionprocessing, before transaction processing, concurrently with
transaction proc easing, or
combinations thereof. If the received-calculated security code does not match
the recalculated
security code, then a party may be notified, e.g., as in block 39.
100461 The
step at block 34 is an example ofa fraud mitigation technique performed before
the user uses (e.g., redeems) a value on the eSVC for a payment transaction.
In embodiments,
before the user uses the eSVC, the eSVC provider, the e-wal let provider, the
eSVC processor,
the eSVC issuer, the merchant or combinations thereof may provide fraud
mitigation. In an
additional or alternative embodiment, providing fraud mitigation may comprise
determining a
digital fingerprint of a user device user
device 14 of Figure 3), at the time a user attempts to
use a calculated security oode to determine the risk associated with the user
and/or user devi e e,
the eSVC, or both. In an additiomti of al te mative embodiment, providing
fraud mitigationmay
14
Date Recue/Date Received 2023-05-17
comprise determining a risk score associated with an eSVC and/or an e-wallet,
wherein the risk
score is based on, for example, metadata of a payment transaction request,
transaction frequency,
transaction type, transaction amount, number of transactions, transaction
location (e.g., via
geocoding techniques), or other risk assessment information known to one
skilled in the art with
the aid of this disclosure. In an additional or alternative embodiment
providing fraud mitigation
maycomprise withholding the processing of the payment transaction (e.g.,
withholding the
redemption for the eSVC). In an additional or alternative embodiment,
providing fraud
mitigation may comprise determining a geographic location ofthe eSVC and/or
user and pausing
the processing of the payment transaction for a period of time determined by
the geographic
location. For example, the processing of the payment transaction may be held
for a longer period
of time in geographic locations known or determined to be of high risk of
fraud, and the
processing of the payment transaction may be held for a short period of time
or for a period of
dine comprising zero in geographic locations known or determined to be of low
or no risk of
fraud.
[0047] At
block 36, the payment transaction is processed. In an embodiment, the payment
transaction may be processed by the provider of the eSVC and/or e-wallet
(e.g., via computer
device 12 of Figure 3), by the merchant (e.g., via computer device 16 of
Figure 3), by the processor
(e.g., via computer device 18 of Figure 3), or combinations thereof. For
example, the payment
transaction may be processed by applying a value of the eSVC (e.g., currency,
discount,
promotion, points, rewards, a value token or electronic value token as
described for the value token
transaction processing systems described hereinbelow) to complete the
transaction. In an
embodiment, to process the payment transaction, authentication infonnati on of
the request to
process a payment transaction may he identified, a value associated with the
eSVC (e.g., embodied
as a value token, described below) may be identified, at least a portion of
the value of the eSVC
(e.g., value token) may be applied to at least a portion of a request to
process a payment
transaction, or combinations thereof. man embodiment, identifying
authentication information
may comprise the method steps discussed for blocks 32, 34, and 38. In
embodiments, processing
the payment transaction may further comprise processing at least a portion of
the request to process
a payment transaction in a primary wallet of an c-wallet (e.g., electronic
wallet 10 of Figure 3),
processing at least a portion of the request to process a payment nunsaction
in a sub-wallet of an c-
wallet (e.g., of electronic wallet 10 of Figure 3), or both. In embodiment, a
notification may be
Date Reeue/Date Received 2023-05-17
sent to the user, merchant, processor, and or provider that the payment has
been processed, the
received-calculated security code has been accepted, or both.
100481 At block 38, the received-calculated security code and the
recalculated sec urity code
are eliminated from databases of the security code provider. Elimination of
the security codes may
take place before processing of the payment transaction, after processing of'
the payment
transaction, concurrent with the processing of the payment transaction, or
combinations thereof In
an embodiment where the provider of the eS VC anclior c-wallet receives
thecalculatedsecurity
code andior recalculates the security code, the provider may eliminate the
received-calculated
security code and/or recalculated security code from data base s o f the
provider (e.g., in computer
device 12 of Figure 3). In an embodiment where the processor receives the
calculated security
code and/or recalculates the security code, the processor may eliminate the
received-calculated
security code and/or recalculated security cock from databases of the proces
sor (e. g., in computer
device 18 of Figure 3). In an embodiment where the merchant receives the
calculated security
code and/or recalculates the security code, the merchant may el imi nate the
received-calculated
security code and/or recalculated security code from databases of the
merchant.
[0049] At block 39, a notification is sent. For example, the user (e.g.,
via user device 14 of
Figure 3) and the merchant (e.g., via merchant computer device 16 of Figure 3)
may be notified
that the received-calculated security code is invalid. In an embodiment where
a determination is
made that the received-calculated security code does not match the
recalculated security code, a
notification may be sent, e.g.. as a fraud prevention means.
[0050] Figure 3 is a schematic illustration of an embodiment of a system
according to the
disclosure. As shown in Figure 3, an embodiment of the disclosed system for
providing a
security code may comprise a user device 14 (e.g., of a user), a merchant
computer device 16
(e.g., of a mere hunt), a provider computer device 12 (e.g., ofan electronic-
wallet provider and/or
eSVC provider), a see urity code provider computer device 13 (e.g., of a
security code provider),
a processor computer device 18 (e.g., of an electronic stored-value card
processor), an issuer
computer device 19 (e.g., of an issuer of the eSVC), or combinations thereof.
[0051] While Figure 3 shows one embodiment of a system according to the
disclosure, it
should be understood many system embodiments are disclosed. For example, many
system
embodiments may accomplish the embodiments of the methods for providing a
security code
disclosed here inabovc depending upon whether the security code provider
computer de vice 13
16
Date Recue/Date Received 2023-05-17
comprises the same or different computer device as the provider computer
device 12, merchant
computer device 16, processor computer device 18, or issuer computer device
19.
[0052] In
embodiments, the security code provider computer device 13 may comprise a
device separate from the user device 14, the processor computer device 18, the
issuer computer
device 19, the provider computer device 12, and the merchant computer device
16. In alternative
embodiments, the security code provider computer device 13 may comprise a
device which is
same device as merchant computer device 16, the provider computer device 12,
the issuer of the
GS VC computer device 19, the processor of the eSVC computer device 18, or
combinations
thereof. I n embodiments, the security code provider computer device 13 may
comprise a device
which is: the processor computer device 18; alternatively, the issuer computer
device 19;
alternatively, the provider computer device 12; alternatively, the merchant c
omputer device 16;
alternatively, the provider computer device 12 and the merchant computer
device 16;
alternatively, the provider computer device 12 and the processor computer
device 18;
alternatively, the provider computer device 12 and the issuer computer device
19; alternatively,
issuer computer device 19 and the processor computer device 18; alternatively,
the issuer
computer device 19 and the merchant computer device 16; alternatively, the
processor computer
device 18 and the merchant computer device 16; alternatively, the provider
computer device 12,
the issuer computer device 19, and the processor computer device 18;
alternatively, the provider
computer device 12, the processor computer device 18, and the merchant
computer device 16;
alternatively, the provider computer device 12, the issuer computer device 19,
and the merchant
corn pute r device 16; alternatively, the merchant computer device 16, the
issuer computer device
19, and the processor computer device 18; alternatively, the provider computer
device 18, the
issuer computer device 19, the processor computer device 18, and the merchant
computer device
16. In embodiments where the security code provider is also the eSVC issuer,
rules may allow
the entity to store and/or retain a security code; however, such an entity may
also choose to
calculate the security code according to the present disclosure or delegate
such calculating
responsibilities to an agent of the security code provider. In an embodiment,
the security code
provider is an entity which calculates the security code to provide the
security code but does not
store or retain the security code (or versions thereof, e.g.. received-
calculated sec uri ty cock,
recalculated security code, etc.).
17
Date Recue/Date Received 2023-05-17
[00531 The components of the system of Figure 3 may be operably connected
via one or
more networks (e.g., broadband, optical, Wi-Fl, Blue tooth, NFC, cellular,
satellite, cloud, card
processing network, banking network, a local area network, the World Wide Web
for Internet,
non-cellular mobile phone network, a land-line network, Public Switched
Telephone Network
(PS TN), a dedicated c ornmuni c ati online, other networks for transferring
electronic information,
or combinations thereon. Particularly, the user device 14 may be operably
connected to the
provider computer device 12, the security code provider computer device 13,
the merchant
computer device 16, the processor computer device 18, the issuer computer
device 19, or
combinations thereof, via the network the merchant computer device 16 may be
operably
connected to the user device 14, the security code provider computer device
13, the processor
computer device 18, the provider computer device 12, the issuer computer
device 19, or
combinations thereof, via the network the provider computer device 12 may be
operably
connected to the user device 14, the merchant computer device 16, the security
code provider
computer device 13, the processor computer device 18, the issuer computer
device 19, or
combinations thereof via the network; the processor computer device 18 may be
operably
connected to the user device 14, provider computer device 12, security code
provider computer
device 13, the merchant computer device 16, the issuer computer device 19, or
combinations
thereof via the network; or combinations thereof. When any of the computer
devices 13, 14, 16,
18, or 19 of the system is operably connected to the provider computer device
12, said devices
13, 14, 16, 18, or 19 may additionally be operably connected to an e-wallet on
the provider
computer device 12.
100541 The security code provider computer device 13 may comprise one or
more computer
devices (e.g., a computer, a tablet, a smartphone, a cloud computing system, a
server, or
combinations thereof), which is suitable for performing the functions
described herein.
[0055] In embodiments, the security code provider computer device 13 may
be configured to
receive a request for a security code of an e SVC (e.g., from the provider
computer device 12, the
user device 14, the merchant computer deviee 16, the processor computer device
18, the issuer
computer device 19, or combinations thereon; to calculate the security code
(e.g., using at least a
portion of the card information of the eSVC); to provide (e.g., send, display,
etc.) the calculated
security code in response to the request for a security code (e.g., to the
provider computer device
12, the user device 14, the merchant computer device 16, the processor
computer device 18, the
18
Date Recue/Date Received 2023-05-17
issuer computer device 19, or combinations thereof); to eliminate the
calculated security code
from the security code provider computer device 13 (e.g., from any
database/datastore of the
security code provider computer device 13); to receive the calculated security
code (e.g., from
the provider computer device 12, the user device 14, the processor computer
device 18, the
merchant computer device 16, the issuer computer device 19, or combinations
thereof), for
example, as part of a request to process a payment transaction; to recalculate
the security code of
the eSVC (e.g., eSVC 11); to determine whether the received-calculated
security code (e.g.,
received from the provider computer device 12, the user device 14, the
merchant computer
device 16, the processor computer device 18, the issuer computer device 19, or
combinations
thereof) matches the recalculated security code; to eliminate the received-
calculatcdsecurity
code and recalculated security code from the security code provider computer
device 13 (e.g.,
from any database/datastore of the security code provider computer device 13);
to receive (e.g.,
from the provider computer device 12, the user device 14, merchant computer
device 16,
processor computer device 18, issuer computer device 19, or combinations
thereat) a request to
process a payment transaction (e.g., against an eSVC 11, for example, in e-
wallet 10); to identify
authentication information of the request to process a payment transaction; to
identify a value
(e.g., value token, currency, rewards, points, discount, promotion,
combinations thereof, etc.)
associated with the cSVC; to apply at least a portion of the value to at least
a portion of the
request to process the payment transaction; to provide fraud mitigation; to
block access to an
eSVC before a user views the eSVC; to block access to an eSVC before a user
activates the
eSVC, to determine a digital fingerprint of a user device (e.g., user device
14), at the time a user
attempts to view an eSVC to determine the risk associated with the user, the
eSVC, or both; to
withhold the providing of the eSVC (e.g., withholding the delivery of
redemption information for
the eSVC); to determine a geographic location of the eSVC and/or user; to
pause the providing
of the eSVC for a period of lime determined by the geographic location, or
combinations thereof.
[00561 In
additional embodiments, in order to calculate andior recalculate the security
code,
the security code provider computer device 13 may use a primary account
number, an expiration
date, a service code, a security information (e.g., magnetic stripe security
code), or combinations
thereof, of the eSVC (e.g., eSVC 11). In embodiments, the security code
provider computer
device 13 may be configured to process at least a portion of a request to
process a payment
transaction via a primary wallet of an electronic wallet 10, the security code
provider computer
19
Date Recue/Date Received 2023-05-17
device 13 may be configured to process at least a portion of a request to
process a payment
transaction via a sub-wallet of an electronic wallet 10, or both (primary
wallets and sub-wallets
am discussed licreinbelow).
100571 The user device 14 may comprise a personal computer, a tablet, a
smartphone, a
cloud computing system, a server, or combinations thereof. The device used by
the user or
consumer to transact business with the merchant computer device 16 may be the
same or
different device from the user device 14. In embodiment, the user or consumer
may transact
business using the user device 14; alternatively, the user or consumer may use
the user device 14
to request and receive a calculated security code and use other means (e.g., a
computer device
separate from the user device 14) to transact business, e.g., with a merchant
via merchant
computer device 16). In an embodiment, the user device 14 may be used to
convey transaction
information to the provider computer device 12, security code provider
computer device 13,
merchant computer device 16, processor computer device 18, issuer computer
device 19, or
combinations thereof. In embodiments, a user or consumer may interact (e.g.,
use the eSVC) via
the user device 14 with the provider computer device 12, for example, to add
or remove eSVCs
(e.g., in an e-wallet 10), add value to an eSVC (e.g., e SVC 11), manage an
eSVC embodied as a
value token (described hereinbelow, register an eSVC, activate an eSVC,
transfer or exchange an
eSVC for another eSVC (e.g., in an embodiment where the provider computer
device 12 is also a
merchant computer device 16), transfer eSVCs to an e-wallet or a primary
wallet or a sub-wallet,
or combinations thereof. In embodiments, a user or consumer may interact
(e.g., use an obtained
eSVC) via the user device 14 with a transaction portal (i.e., online merchant
portal to redeem a
gift, discount, credit, reward, points, etc.) without interaction with an e-
wallet hosted by an e-
wallet provider. Embodiments of the disclosed system may further comprise an
interface (e.g.,
associated with the user device 14) through which a viewer may access one or
more eSVCs (e.g.,
eSVC 11). In an embodiment, a user may interact via the user device 14 with
the electronic
wallet 10 to obtain a security code of the eSVC 11 in the electronic wallet
10.
100581 In embodiments, the security code provider computer device 13 may
comprise the
user device 14. In such embodiments, the user device 14 may be configured to
receive a request
for a security code of an eSVC (e.g., from the provider computer device 12,
the merchant
computer device 16, the processor computer device 18, the issuer computer
device 19, or
combinations thereof); to calculate the security code (e.g., using at least a
portion of the card
Date Recue/Date Received 2023-05-17
information of the eSVC); to provide (e.g., send, display, etc.) the
calculated security code in
response to the request for a security code (e.g., to the provider computer
device 12, the
merchant computer device 16, the processor computer device 18, the issuer
computer device 19,
or combinations thereof); to cl im mate the calculated sec uti ty code from
the user device 14 (e.g.,
from any database/datastore of the user device 14); to receive the calculated
security code (e.g.,
from the provider computer device 12, the processor computer device 18, the
merchant computer
device 16, the issuer computer device 19, or combinations thereof), for
example, as part of a
request to process a payment transaction; to recalculate the security code of
the eSVC (e.g.,
eSVC 11); to determine whether the received-calculated security code (e.g.,
received from the
providereornputer device 12, the merchant computer device 16, the processor
computer device
IS, the issuer computer device 19, or combinations thereof) matches the
recalculated security
cock; to eliminate the received-calculated security code and recalculated
security code from the
user device 14 (e.g., from any database/datastore of the user device 14); to
receive (e.g., from the
provider computer device 12 merchant computer device 16, processor computer
device 18,
issuer computer device 19, orcombinations thereof) arequest to process a
payment transaction
(e.g., against an eSVC 11, for example, in e-wallet 10); to identity
authentication information of
the request to process a payment transaction; to ickntify a value (e.g., value
token, currency,
rewards, points, discount, promotion, combinations thereof, eta.) associated
with the eSVC; to
apply at least a portion of the value to at least a portion of the request to
process the payment
transaction; to provide fraud mitigation; to block access to an eSVC before a
user views the
eSVC; to block access to an eSVC before a user activates the eSVC; to
determine a digital
fingerprintofa userdevice (e.g., user device 14), at the time a user attempts
to view all eSVC to
determine the riskassociated with the user, the eSVC, or both; to withhold the
providing of the
eSVC(e.g., withholding the &livery of redemption information for the eSVC); to
determine a
geographic location of the eSVC and/or user; to pause the providing ofthe eSVC
for a peri od of
time determined by the geographic locale% or combinations thereoE
[0059] In
additional embodiments, in order to calculate and/or recalculate the security
code,
the user device 14 may use a primary account number, an expiration date, a
service code, a
security infonnati on (e .g., magnetic stripe security node), or combinations
thereof, of the eSVC
(e.g., eSVC 11).
21
Date Recue/Date Received 2023-05-17
[00601 The merchant computer device 16 may comprise a computer device
(e.g., a point-of-
sale device) of a merchant. The merchant computer device 16 may have any
suitable
configuration for performing the functions disclosed herein (e.g., a personal
computer, a tablet, a
smartphone, a cloud computing system, a server, or combinations thereof). In
embodi me nts,the
merchant computer device 16 may perform transactions with a computer device
(e.g., user device
14) of a consumer, for example, in a transaction (e.g., online,
telephonically, or both) requiring
the security code for an eSVC. The merchant computer device 16 may communicate
with the
processor computer device to complete a transaction with a user or consumer.
100611 In embodiments, the security code provider computer device 13 may
comprise the
merchant computer device 16. In such embodiments, the merchant computer device
16 may be
confi gure d to receive a request for a security code of an eSVC (e.g., from
the provider computer
device 12, the user device 14, the processor computer device 18, the issuer
computer device 19,
or combinations thereof); to calculate the security code (e.g., using at least
a portion of the card
information of the eSVC); to provide (e.g., send, display, etc.) the
calculated security code in
response to the request for a security code (e.g., to the provider computer
device 12, the user
device 14, the processor computer device 18, the issuer computer device 19, or
combinations
thereof); to eliminate the calculated security code from the merchant computer
device 16 (e.g.,
from any databaseidatastore of the merchant computer device 16); to receive
the calculated
security code (e.g., from the provider computer device 12, the user device 14,
the processor
computer device 18, the issuer computer device 19, or combinations thereof),
for example, as
part of a request to process a payment transaction; to recalculate the
security code of the eSVC
(e.g., eSVC 11); to determine whether the received-calculated security code
(e.g., received from
the provider computer device 12, the user device 14, the processor computer
device 18, the issuer
computer device 19, or combinations thereof) matches the recalculated security
code; to
eliminate the received-calculated security code and recalculated security code
from the merchant
computer device 16 (e.g., from any database/datastore of the merchant computer
device 16); to
receive (e.g., from the provider computer device 12, the user device 14,
processor computer
device 18, issuer computer device 19, or combinations thereof) a request to
process a payment
transaction (e.g., against an eSVC 11, for example, in e-wallet 10); to
identify authentication
information of the request to process a payment transaction; to identify a
value (e.g., value token,
currency, rewards, points. di scount, promotion, combinations thereof, etc.)
associated with the
22
Date Recue/Date Received 2023-05-17
eSVC; to apply at least a portion of the value to at least a portion of the
request to process the
payment transaction; to provide fraud mitigation; to block access to an eSVC
before a user views
the eSVC; to block access to an eSVC before a user activates the eSVC; to
determine a digital
fingerprintof a userdevice (e.g., user device 14), at the time a user attempts
to view an eSVC to
determine the risk associated with the user, the eSVC. or both; to withhold
the providing of the
e SVC (e.g., withholding the delivery ofredemption information for the eSVC);
to determine a
geographic location of the eSVC and/or user; to pause the providing of the
eSVC for a period of
time determined by the geographic location; or combinations thereof.
100621 In additional embodiments, in order to calculate and/or
recalculate the security code,
the merchant computer device 16 may use a primary account number, an
expiration date, a
service code, a security information (e.g., magnetic stripe security code), or
combinations
thereof, of the eSVC (e.g., eSVC 11). In embodiments, the merchant computer
device 16 may be
configured to process at least a portion of a request to process a payment
transaction via a
primary wallet of an electronic wallet 10, the merchant computer device 16 may
be configured to
process at least a portion of a request to process a payment transaction via a
sub-wallet of an
electronic wallet 10, or both (primary wallets and sub-wallets are discussed
hereinbelow).
[0063j The provider computer device 12 may be a computer device of a
provider of one or
more electronic wallets (e.g., electronic wallet 10), a provider of an eSVC
(e.g., eSVC 11), or
both. The provider computer device 12 may have any suitable configuration for
performing the
functions disclosed herein (e.g., a personal computer, a tablet, a smartphone,
a cloud computing
system, a server, or combinations thereof). Figure 3 shows the provider
computer device 12 may
comprise an electronic wallet 10. In embodiments, the provider computer device
12 may further
comprise an electronic value token transaction processing system, for example,
of an
embodiment described in Figures 4A-B, mid 5A-C hereinbelow. In embodiments,
the provider
computer dev icc 12 may further comprise a database (e.g., database/datastore
180 as described
for the figures hereinbelow) to store one or inure eSVCs (e.g., eSVC 11), one
or more electronic
wallets (e.g., electronic wallet 10), at least a portion of the card
information associated with each
eSVC, or combinations thereof
100641 Figure 3 shows an embodiment of the system comprising one
electronic wallet 10.
In alternative embodiments, the system may comprise a first electronic wallet
and a second
electronic wallet. In additional or alternative embodiments, the electronic
wallet 10 may
23
Date Recue/Date Received 2023-05-17
comprise any number of sub-wallets as described herein below. Electronic
wallets (e.g.,
electronic wallet 10) may oflbr a variety of services, including storing,
managing, and facilitating
the redemption ofvalue (e.g., monetary, discount, promotional, value tokens,
rewards, etc.) of
eSVCs. One or more electronic stored-value cards (hereinafter "eSVC" or
"eSVCs") (e.g., eSVC
11) may be associated (e.g., registered) with the one or more electronic
wallets. For example, a
first eSVC (e.g., eSVC 11) and a second eSVC may be registered in electronic
wallet 10.
Alternatively, a first eSVC (e.g., eSVC 11) may be registered in a first
electronic wallet and a
second cS VC may be registered in a second electronic wallet. In additional or
alternative
embodiments, one or more eSVCs may be associated (e.g., registered) in a sub-
wallet of an
electronic wall et (re gistration techniques, methods, and processes are
discussed hereinbelow).
mbodi ments of the electronic wallet 10 are described in detail here i nbelow,
for example, in the
discussion for Figure 4B.
[0065] In embodiments, the security code provider computer device 13 is the
provider computer
device 12. In such embodiments, the provider computer device 12 may be
configured to receive
a request for a security code of an c SVC (e.g., from the user device 14, the
merchant computer
device 16, the processor computer device 18, the issuer computer devioe 19, or
combinations
thereof); to calculate the security code (e.g., using at least a portion of
the card information of the
eSVC); to provide (e.g., send, display, etc.) the calculated security code in
response to the
request for a security code (e.g., to the user device 14, the merchant
computer device 16, the
processor computer device 18, the issuer computer device 19, or combinations
thereof); to
eliminate the calculated security code from the provider computer device 12
(e.g., from any
database/datastore of the provider computer device 12); to receive the
calculated security code
(e.g., from the user device 14, the processor computer device 18, the merchant
c omputer device
16, the issuer computer device 19, or combinations thereof), for example, as
part of a requestto
process a payinenttransaction; to recalculate the security code of the eSVC
(e.g., eSVC 11); to
determine whe the r the received-calculated sec uri ty code (e.g., received
from the user device 14,
the merchant computer device 16, the processor computer device 18, the issuer
computer device
19, or combinations thereof) matches the recalculated security code; to
eliminate the received-
calculated security code and recalculated security code from the provider
computer device 12
(e.g., from any databe.seldatastore of the provider computer device 12); to
receive (e.g., from the
user device 14, tnerchant computer device 16, processor computer device 18,
issuer computer
24
Date Recue/Date Received 2023-05-17
device 19. or combinations thereof) a request to process a payment transaction
(e.g., against an
eSVC 11, for example, in e-wallet 10); to identify authentication information
of the request to
process a payment transaction; to identify a value (e.g., value token,
currency, rewards, points,
discount, promotion, combinations thereof, etc.) associated with the eSVC; to
apply at least a
portion of the value to at least a portion of the request to process the
payment transaction; to
provide fraud mitigation; to block access to an cSVC before a user views the
cSVC; to block
access to an eSVC before a user activates the eSVC; to determine a digital
fingerprint of a user
device (e.g., user devi ce 14), at the time a user attempts to view an e S VC
to determi ne the risk
associated with the user, the cSVC, or both; to withhold the providing of the
eSVC (e.g.,
withholding the deli very of redemption information for the cSVC); to
determine a geographic
location of the eSVC and/or user; to pause the providing of the eSVC for a
period of time
determined by the geographic location; or combinations thereof.
[00661 In additional embodiments, in order to calculate and/or
recalculate the security code,
the provider computer device 12 may use a primary account number, an
expiration date, a
service code, a security information (e.g., magnetic stripe security code), or
combinations
thereof, of the eSVC (e.g., eSVC 11). In embodiments, the provider computer
device 12 may he
configured to process at least a portion of a request to process a payment
transaction via a
primary wallet of an electronic wallet 10, the provider o omputer device 12
may be configured to
process at least a portion of a request to process a payment transaction via a
sub-wallet of an
electronic wallet 10, or both (primary wallets and sub-wallets are discussed
hcreinbelow).
[0067] The processor computer device 18 may comprise a computer device of
a processor of
an electronic stored-value card (e.g., eSVC 11). The processor computer device
18 may have
any suitable configuration for performing the functions disclosed herein
(e.g., a personal
computer, a tablet, a srnartphone, a cloud computing system, a server, or
combinations thereof).
[0068] In embodiments, the security code provider computer device 13 is
the processor
computer device 18. In such embodiments, the processor computer device 18 may
be configured
to receive a request for a security code of an eSVC (e.g., from the provider
computer device 12,
the user device 14, the merchant computer device 16, the issuer computer
device 19, or
combinations thereof); to calculate the security code (e.g., using at least a
portion of the card
infbrmation of the eSVC); to provide (e.g., send, display, etc.) the
calculated security code in
response to the request for a security code (e.g., to the provider computer
device 12, the user
2$
Date Recue/Date Received 2023-05-17
device 14. the merchant computer device 16, the issuer computer device 19, or
combinations
thereof); to eli ini nate the calculated security code from the processor
computer device 18 (e.g.,
from any database/datastore of the processor computer device 18); to receive
the calculated
security code (e.g., from the provider computer device 12, the user device 14,
the merchant
computer device 16, the issuer computer device 19, or combinations thereof),
for example,as
part of a request to process a payment transaction; to recalculate the
security code of the e SVC
(e.g., eSVC 11); to determine whether the received-calculated security code
(e.g., received from
the provider computer device 12, the user device 14, the merchant computer
device 16, the issuer
computer device 19, or combinations thereof) matches the recalculated security
code; to
eliminate the received-calculated security code and recalculated security code
from the processor
computer device 18 (e.g., from any databasedatastorc of the processor computer
device 18); to
receive (e.g., from the provider computer device 12, the user device 14,
merchant computer
device 16, issuer computer device 19, or combinations thereof) a request to
process a payment
transaction (e.g., against an eSVC 11, for example, in e-wallet 10); to
identify authentication
information of the request to process a payment transaction; to identify a
value (e.g., value token,
currency, rewards, points, discount, promotion, combinations thereof, etc.)
associated with the
eSVC; to apply at least a portion of the value to at least a portion of the
request to process the
payment transaction; to provide fraud mitigation; to block access to an eSVC
before a user views
the eSVC; to block access to an eSVC before a user activates the cSVC; to
determine a digital
fingerprintora userdevice (e.g., user device 14), at the time a user attempts
to view aneSVC to
determine the riskassociated with the user, the eSVC, or both; to withhold the
providing of the
eS VC (e.g., withholding the delivery of rede m pti o n information for the
eSVC); to determine a
geographic location of the eSVC and/or user, to pause the providing of the
eSVC for a period of
time determined by the geographic location; or combinations thereof:
[00691 In
additional embodiments, in order to calculate and/or recalculate the security
code,
the processor computer device 18 may use a primary account number, an
expiration date, a
service code, a security information (e.g., magnetic stripe security code), or
combinations
thereof, of the eSVC (e.g., eSVC 11). In embodiments, the processor computer
device 18 may
be configured to process at least a portion of a request to process a payment
transaction via a
primary wallet of an electronic wallet 10, the processor computer device 18
may be configured to
26
Date Recue/Date Received 2023-05-17
process at least a portion of a request to process a payment transaction via a
sub-walletof an
electronic wallet 10, or bath (primary wallets and sub-wallets arc discussed
hercinbclow).
100701 In embodiments, the processor computer dev ice 18 may comprise a
database (e.g., the
databasedatastore 180 described herein below) to store at least a portion of
the card information
associated with each eSVC.
[0071] The issuer computer device 19 may comprise a computer device of an
issuer of an
electronicstored-value card (e.g., eSVC 11). The issuer computer device 19 may
have any
suitable configuration for performing the functions disclosed herein (e.g., a
personal computer, a
tablet, a smartplione, a cloud computing system, a server, or combinations
thereof).
[0072] In embodiments, the security code provider computer device 13 is
the issuer
computer device 19. In such embodiments, the issuer computer device 19 may be
configured to
receive a request for a security code of an eSVC (e.g., from the provider
computer device 12, the
user device 14, the merchant computer device 16, the processor computer device
18, or
combinations thereof); to calculate the security code (e.g., using at least a
portion of the card
information of the eSVC); to provide (e.g., send, display, etc.) the
calculated security code in
response to the request for a security code (e.g., to the provider computer
device 12, the user
device 14, the merchant computer device 16, the processor c ompute r device
18, or combinations
thereof); to eliminate the calculated security code from the issuer computer
device 19 (e.g., from
any database/datastore of the issuer computer device 19); to receive the
calculated security code
(e.g., from the provider computer device 12, the user device 14. the processor
computer device
18, the Merchant computer device 16, or combinations thereof), for example, as
part of a request
to process a payment transaction; to recalculate the security code of the eSVC
(e.g., eSVC 11); to
determine whether the received-calculated security code (e.g., received from
the provider
computer device 12, the user device 14, the merchant computer device 16, the
processor
computer device 18, or combinations thereof) matches the recalculated security
code; to
eliminate the received-calculated security code and recalculated security code
from the issuer
computer device 19 (e.g., from any databaseklatastore of the issuer computer
device 19); to
receive (e.g., from the provider computer device 12, the user device 14,
merchant computer
device 16, processor computer device 18, or combinations thereof) a request to
process a
payment transaction (e.g., against an eSVC 11, for example, in e-wallet 10);
to identify
authentication information of the request to process a payment transaction; to
identify a value
27
Date Recue/Date Received 2023-05-17
(e.g., value token, currency, rewards, points, discount, promotion,
combinations thereof, etc.)
associated with the eSVC; to apply at least a portion of the value to at least
a portion of the
request to process the payment transaction; to provide fraud mitigation; to
block access to an
eSVC before a user views the eSVC; to block access to an eSVC before a user
activates the
eSVC; to determine a digital fingerprint ofa user device (e.g., user device
14), at the time a user
attempts toview aneSVC to determine the risk associated with the user, the
eSVC, or both; to
withhold the provicing of the eSVC (e.g., withholding the delivery of
redemption information for
the eSVC); to determine a geographic location of the eSVC and/or user, to
pause the providing
of the eSVC for a period of time determined by the geographic location; or
combinations thereof.
[0073] In additional embodiments, in order to calculate and/or
recalculate the security code,
the issuer computer device 19 may use a primary account number, an expiration
date, a service
code, a security information(e.g., magnetic stripe security code), or
combinations thereof, o f the
eSVC (e.g., eSVC 11). In embodiments, the issuer computer device 19 may be
configured to
process at least a portion of a request to process a payment transaction via a
primary wallet of an
electronic wallet 10, the issuer computer device 19 may be configured to
process at least a
portion of a request to process a payment transaction via a sub-wallet of an
electronic wallet 10,
or both (primary wallets and sub-wallets are discussed hereinbelow).
[0074i An exemplary system for providing a security code for an
electronic stored-value card
is depicted in Figure 3. A user having user device 14 may obtain an eSVC from
the provider
computer device 12, for example, via an e-wallet of the user stored on the
provider computer
device 12 which is accessible by a device (e.g., the user device 14) of the
user, or via a delivery
of the eSVC to the user device 14 (e.g., by SMS, email, video (e.g., YouTube,
Vimeo, Skype,
video m e s sage , or combinations thereof), instant message, a we bsi te, an
online storage medium,
a cloud storage system, other means for electronically obtaining the
electronic stored-valuecard,
or combinations thereof). Before the eSVC is obtained, the provider computer
device 12,
security code provider computer device 13, merchant computer device 16,
processor computer
device 18, i ssuer computer device 19, or combi nations thereof may provide
fraud mitigation. In
embodiments, fraud mitigation may comprise blocking access to an eSVC before a
user views
the eSVC, e.g., on user device 14; blocking access to an cSVC before a USCI"
activates the eSVC;
determining a digital fingerprint of a user device (e.g., user device 14), at
the ti me a user
attempts to view an eSVC to determine the risk associated with the user, the e
SV('.,, or both;
28
Date Recue/Date Received 2023-05-17
withholding the providing of the eSVC (e.g., withholding the delivery of
redemption information
forthe eSVC); determining a geographic location of the eSVC and/or user;
pausing the providing
of the eSVC for a period of ti me determined by the geographic location;
orcombinatiorasthereof.
Farm A user or consumer having an eSVC may obtain a security code, e.g., a
CVV2, for
the eSVC in a number of ways. For example, if the user received the cSVC as a
URL,, e.g., in an
email as an ail ft, the user may select/salivate the URL which opens a webpage
hosted by the
eSVC provider. The URI, may contain an identifier of the eSVC for the provider
webpage
which facilitates a display of relevant data, e.g., logo, terms and
conditions, redemption
instructions, card number, security information, and expiration date, etc.,
for the eSVC. The
webpage may then communicate with an API of the eSVC provider to retrieve the
security code,
e.g., CVV2, for the webpage-displayed eSVC. As such, upon receipt of the eSVC,
the user may
initiate a process for acquiring the eSVC's security code necessary for future
transactions.
Similarly, ifthe eSVC user/consumer Ito ei ved the e SVC as an eCode, e.g.,
delivered directly to
the user (e.g., via SKS. Instant Message, and email) the eCock message may
provide the user
with link or instructions for accessing the eSVC provider's system for
obtaining the eSVC's
security code in a manner similar to the manner described concerning the above-
eGifl
embodiment. Further, man embodiment wherein the eSVC is directly provisioned
to the user's
clectronicwallet, the e-wall et provisioning action may induce the e-wallet to
provide the user
with link or instructions for accessing the eSVC provider's system for
obtaining the eSVC's
security code in a manner similar to the manner described concerning the above-
ellift
embodiment.
[00761 In
another example, when a user desires a transaction with a merchant device 16
(e.g.,
a website, Internet portal, or other transaction point described herein or
known to those skilled in
the art with the aid of this disclosure), and the user has not yet received
the eSVC's security
code, the user may use the user device 14 to request a security code for the
eSVC by contacting
the provider computer device 12 or the security code provider computer device
13 (e.g., in
embodiments where provider computer device 12 is not of the security code
provider). If the
user uses the user device 14 to request the security code forthe eSVC by
contacting the provider
computer device 12 the provider computer device 12 may calculate the security
code (e.g., in
embodiments where the provider computer device 12 is of the security code
provider), or the
provider computer device 12 may forward the request or make a request for the
security code of
29
Date Recue/Date Received 2023-05-17
the eSVC by contacting the security code provider computer device 13 (e.g.,
which can be the
computer device o f an independent entity, of the merchant, o f the eSVC
processor, of the eSVC
issuer, or combinations thereof). As di sc ussed above, the di sc losure co
nte mpl ate s embodiments
where the merchant computer device 16, processor computer devi ce 18, and/or
issuer computer
device 19 make a request for the security code of the eSVC which the user uses
for the
transaction.
[00771 After the security code request is received, the security code
provider computer
device 13 calculates the security code of the eSVC, for example, using the
primary account
number, expiration date, service code, available security information (e.g.,
from the magnetic
stripe of the physical card of the eSVC), or combinations thereof. In an
embodiment, a CVV2
may be calculated by encrypting the primary account number, the expiration
date, and security
code with encryption keys. The security code provider computer device 13 then
sends the
calculated security code to the provider computer device 12 (e.g., in
embodiments where the user
request was forwarded to the security code provider computer device 13 by the
provider
computer device 12) or sends the calculated security code to the user device
14. In embodiments
where the provider computer device 12 receives the calculated security code,
the provider
computer device 12 then sends the calculated security code to the user device
14.
100781 The security code provider computer device 13 may c liminatc the
calculated seaurity
code from some, selected, or all databases of the security code provider
computer device 13.
The provider computer device 12 may eliminate the calculated security code
from some,
selected, or all databases of the provider computer device 13.
[0079] After the user device 14 receives the calculated security code the
calculated security
code may be used in the transaction with the merchant computer device 16. The
merchant
computer device 16 may require various inputs to capture eSVC information from
the user
device 14. For example, the merchant computer device 16 may require an account
number,
billing address, expiration date, and the calculated security code of the
eSVC. The merchant
compute r device 16 may establish a secure communication with the eSVC
processing system on
processor computer device 18 and request to process the payment transaction.
The
communication between the merchant computer dev i cc 16 and the processor
computer device 18
may be encrypted for security. The processor computer device 18 may comprise a
transaction
routing service, an internal card processing service, a settlement service, a
product master catalog
Date Recue/Date Received 2023-05-17
service, and an inventory management service. The transaction routing service
of the processor
computer device 18 may communicate with the merchant computer device 16 as
well as third
party card processors. The transaction routing service may receive the
collected eSVC
infonnation(i.e., account number, expiration date, name (int& eSVC, calculated
security code)
from the merchant computer device 16 and determine whetherto forward the
request to process a
payment transaction to a third party processor (e.g., to forward the request)
or to process the
request to process the payment transaction for the eSVC 11, for example, by
comparing an
information of the cSVC 11 to information in a master catalog service to
determine whether the
eSVC 11 is a product for which the processor computer device 18 acts as the
processor. Thus,
for example, lithe eSVC is a stored-value card processed by the processor
computer device 18,
then the transaction routing service may forward the request to process a
payment transaction to
the internal card processing service withinthe processor computer device 18 or
is one processed
by a third party eSVC processor. If the eSVC 11 is processed by a third party
processors, the
transaction routing service routes the activation request to the third party
processor for payment
processing. The transaction routing service of the processor computer device
18 may receive a
payment response from the appropriate third party processors and may transmit
the payment
response back to the merchant computer device 16.
[00801 If the
transaction routing service determines that the eSVC ills one that is
processed
by the processor computer device 18 (and not merely a request to process a
payment for which
the processor computer device 18 serve sas a routing service), the processor
computer device 18
may transfer the request to process a payment transaction from the merchant
computer device 16
to the internal card processing service of the processor computer device 18
which uses the
infonnati on contained in the request (e.g., account number, name on the eSVC,
expiration date,
the received-calculated security code) to determine whether to process the
eSVC 11. For
example, the processor computer device 18 may recalculate the security code of
the eSVC 11
and determine whether the recalculated security code matches the received-
calculatedsecurity
code. If the recalculated security code of the eSVC 11 matches the received-
calculatedsecurity
code of the eSVC 11, the internal card processing service of the processor
computer device 18
may contact the i ssuer computer device 1910 process the payment transaction.
I I pon processing
of the payment transaction, the processor computer device 18 may transmit a
successful payment
response to the merchant computer device 16 via the transaction routing
service of the processor
31
Date Reeue/Date Received 2023-05-17
computer device 18. The internal card processing service may also update a
database/datastore
of payment status to indicate that the eSVC 11 has been used for a payment
transaction. The
internal card processing service may also eliminate the received-calculated
security code and
recalculated security code from databases/datastores ofthe processor computer
device 18. The
internal card processing service of the processor computer device 18 may also
compare the
eSVC type to types of cards issued by the issuer of the eSVC in the product
master catalog
service to help verify thatthe eSVC is authentic.
100811 The transaction routing service may also route the request to
process a payment
transaction to the settlement service of the processor computer device 18. The
settlement service
may allocate appropriate portions of value paid for the payment transaction
among the various
entities involved in the transaction (i.e., provider computer device 12,
issuer computer device 19,
etc.). This amount may be a percentage of the amount of the value of the
payment transaction.
The settlement service ofthe processor computer device 18 may also allocate
amounts received
forthe payment transaction to the eSVC issuer (e.g., via issuer computer
device 19), the eSVC
processor (e .g., via processor computer device 18), the provider of the eSVC
(e.g., via provider
computer device 12, combinations thereof; etc.).
100821 Reference to the calculation of a recalculated security code
should include
embodimentswhere the security code is calculated by one entity while the
recalculated security
code is calculated by another entity. Reference to the calculation of the
recalculated sec linty code
should al so include embodiments where the security code is calculated and
recalculated by the
same entity.
[0083] In embodiments disclosed herein, the security code which is
calculated or
recalculatedaccording to the embodiments disclosed herein may comprise a
security code used
for transactions which do not utilize the magnetic stripe security code or
smart chip security code
of a physical card, for example, a security code suitable for a transaction
where a physical card is
not swiped or read (e.g., via NFC, Bluetooth, Wi-Fi, radio, or any other
frequency), such as a
digital (e.g., online) transaction or a telephonic transaction. In additional
or alternative
embodiments, the security code may be embodied as a calculated security code,
a received-
calculated security code, a recalculated security code, or combinations
thereof (discussed
he rei nbe low). In embodiments, the security code, calculated security code,
received-calculated
security code, recalculated security code, or combinations thereof, may
comprise a CVV2.
32
Date Recue/Date Received 2023-05-17
[00841 According to the disclosed systems and methods, the security code
provider has the
ability to provide a security code without storing the security code in order
to comply with rules
governing security codes. As such, the SeClafi ty codc provider may observe
rules which prohibit
the storage and/or retention of security codes while serving customers or
users with mechanisms
for making payment transactions when such security codes are needed.
Additionally, the
systems and methods disclosed herein provide redundancy to ensure calculated
security codes
and recei ved-calculated security codes are accurate and/or correct without
storing the security
codes.
ROW The embodiments described herein also provide fraud mitigation
techniques which
have various advantages. The fraud mitigation techniques help to protect eSVC
providers as
well as eSVC distributers from fraud associating with redeeming eSVCs. It has
been found that
performing a fraud mitigation step before a user obtains the eSVC affects the
ability of a user to
obtain the eSVC by fraudulent means. The fraud mitigation techniques provide
an ability for the
disclosed method and system embodiments to withhold or "soft void" an eSVC
before a user
obtains the eSVC which prevents loss due to fraud. The fraud mitigation
techniques also provide
improved customer service. For example, if a user claims they never received
or lost their eSVC
(e.g., email or text notification was deleted), the embodiments disclosed
herein allow for
withholding the processing of payment transaction, blocking the eSVC from
being obtained,
issuance of a replacement eSVC, or combinations thereof. The fraud mitigation
techniques
disclosed herein help protect eSVC providers, e-wallet providers, eSVC
processors, eSVC
issuers, merchants, and eSVC distribution partners from fraud before and after
purchase of the
eSVC.
[1:10861 The embodiments for provision of a security code as described
herein above may be
included in systems and method for distributing open loop eSVCs. For example,
a computer
device (e.g., one or more of the computer devices described herein above) may
receive an open
loop eSVC distribution request, provide the open loop eSVC in response to the
open loop eSVC
request, notify a recipient or user of the open loop eSVC provided in response
to the open loop
eSVC distribution request; allow the open loop eSVC to be associated with an
electronic wallet;
and enable the open loop eSVC for a transaction (e.g., redemption, purchase,
reload, registration,
or combinations thereof) as disclosed herein. The open loop eSVC may be
provided via any
embodi me ntdisclosed herein (e.g., eGift, eCode, di rectly to an electronic
wallet, or combinations
33
Date Recue/Date Received 2023-05-17
thereof). Additionally or alternatively, the open loop eSVC may be delivered
as a uniform source
locator ("URL"), forexample, via email, short message service ("SMS"), social
media post, other
electronic channel, or combinations thereof. In embodiments, the open loop
eSVC is delivered
directly to the recipient via any mechanism disclosed herein. Any URI, may
reference a
HyperText Markup Language ("tamL") page. and in such embocfiments, the HTML
page may
provide information concerning the embodiment by which the eSVC is provided
(e.g., eGitt,
c Code, electronic wallet, or combi nations the reof). The provided
information may include terms
and conditions, redemption instructions, reload instructions, an
identification number ofthe open
loop eSVC, a security code, an expiration date, or combinations thereof. When
the provided
information includes a security code, the security code may comprise an
embodiment or a
combination of the embodiments disclosed herein. Moreover, the se curity code
may be obtained
dynamically by a computer device (e.g., of an issuer of the eSVC). The
computer device may not
store the securitycode and instead the computer device may calculate the
securitycode (e.g., as
discussed he rein above; additionally or alternatively, in a particular
embodiment, a CVV2 is
calculated by encrypting PAN, the expiration date, andthe security code with
encryption keys) in
order to provide or facilitate provision of the security code. In embodiments,
the security code
may be calculated in real time.
10087] Also
disclosed herein (e.g., as shown in Figures 4A, 5A-B, and 7A-B), an electronic
value token transaction processing system provides users, merchants, vendors,
issuers, providers,
and other interested parties an efficient, secure, and effective system for
facilitating the
organization, management, transportation, storage, and use of the
aforementioned e-wall ets and
electronic value tokens in financial transactions. As described herei nbe low,
there are certain basic
concepts and functions employed by e-wallets and e-wallet enabled systems.
These concepts
include the creation of an e-wallet, provisioning the e-wallet (e.g.,
converting tangible cards into
electronic vol tie tokens and associating the electronic value tokens to an e-
wal let or requesting an
electronic value token be associated with the e-wall et), ac cessing the e-
wallet.. andestabl i sling
rules for the e-wallet' s use. Moreover, as will be more fully detailed
herein, the e-wal let maybe
used in a system wheirin the e-wallet provider manages the entirety of the e-
wallet's contents (e.g.,
the primary e -wallet, any sub-wallets or secondary wallets, and associated
electronic value tokens
therein). Alternatively, the e-wallet may be used in a system wherein the e-
walletprovider
manages only a portion of the e -w al I et' s co ntents (e.g. the primary e-
wallet and clue tonic value
34
Date Recue/Date Received 2023-05-17
tokens therein) and delegates the management of one or more (or all) sub-
walletsorsecondary
wallets to a third-party's electronic value token transaction processing
system. As will be further
detailed herein, either of the two described management systems may be
configured to allow the
systems' user to fully manage the functionalities of the user's e-wallet;
participate in value
added/bonus programs offered by issuers, vendors, and/or other electronic
value token-related
parties; participate in card exchange activities (e.g., wherein a user
exchanges an electronic value
token maintained in its e-wallet for an electronic value taken not in the e-
wallet); and participate in
savings programs offered by issuers, vendors, and/or other electronic value
token-related parties,
[00881 Figure 4A illustrates an exemplary electronic value token
transaction processing system
100. Specifically, Figure 4A illustrates an electronic value token transaction
computer 150
configured for communication with point of sale devices 111, one or more
authorization systems
160 (e.g., retailer, bank, and credit curd), and datastore 180. Moreover,
Figure 4A illustrate s that
the point of sale devices 111 are in communication with a proxy card 200
(which will be shown
below to represent an embodiment of a means for a user to access an e-wallet)
and that the
datastore 180 comprises an e-wallet unit 199, which in turn comprises 0-
wallets 10. The customer
may interact through a mobile application or the web user interface (UI)
portal to configure the
proxy card to be used as a valid payment instrument inside and outside of a
user's ewallet account.
[00891 In some embodiments, an e-wallet user may start using their e-
wallet to pay for goods
and services even when merchants do not support an c-wallet as a form of
payment through use of
a physical or virtual proxy card enabling the customer to make in-person or
online payments by
generation of a virtual stored value number generated in the e-wallet to
access the actual payment
instrument in the customer's e-wallet.
[00901 Figure 4B illustrates an electronic wallet 10 in accordance with
one embodiment, and it
is to be understood that the details of e-wallet 10 may be employed in any of
the various
embodiments disclosed herein (e.g., as e-wallet 10 of Figs. 4A, 5A, and 513)
and the maintenance
of said c- wallet 10 may be wholly performed by a single e-wallet system
(e.g., electronic value
token transaction processing system 100) or may distributed across multiple e-
wallet systems (e.g.,
electronic value token transaction processing systems 1 100 and 1200 and E-Wal
I etAggre gator
System 1000). Specifically, Figure 4B illustrates an electronic wallet 10
comprising authentication
information 801, rules 802, electronic value tokens 804, sub-wallet 807 for
credi t card electronic,
value tokens, sub-wallet (with corresponding rules 817 and electronic value
tokens 827), sub-
Date Recue/Date Received 2023-05-17
wallet 808 for debit card electronic value tokens (with corresponding rules
818 and el ectronic
value tokens 828), and sub-wallet 809 for stored-value card electronic value
tokens (with
corresponding rules 819 and electronic value tokens 829). Figures 4A and 413
may be further
understood from the below discussion,
10091] In order to eliminate the increasing complexity in organization,
transport, security, and
redemption, transaction cards are stored electronically as value tokens in
electronic wallets. As
used herein, a value token refers to an electronic i dent' fie r that may be
used to transact business
with a party willing to accept the electronic value token, for example as
tender for a purchase.
Examples of such value tokens include electronic representations of, or
associated with, stored
value cards (also referred to as prepaid cards) and other physical
representations of value of a
variety of types such as credit cards, debit cards, gift cards, prepaid
telephone cards, loyalty cards,
membership cards, tickets or ticket cards, entertainment cards, sports cards,
prepaid cards,
coupons, admission passes, prepaid or pre-purchased goods or services, and the
like. In an
embodiment, a value token includes cash or currency. In an embodiment, the
electronic value
token includes a credit or debit card or account. In an embodiment, a value
token includes a
preexisting account such as a merchant account, bank account, etc. In an
embodiment, a value
token includes a merchant-issued and/or accepted credit, points, coupon or
promotional value. In
an embodiment, a value token is associated with a prepaid card or account, and
unless otherwise
indicated it is to be understood that the various embodiments described herein
may be carried out
in the context of a prepaid card or account such as a merchant gift card.
[0092] A physical credit card, debit card, stored-value card, or ot her
physical representations
of value may be converted into a value token to be added to the electronic
wallet. For example,
physical gift cards or other physical representations of value may be
transformed into value tokens
in a user's electronic wallet via a point-of-sale device, cellular phone, a
computer, short messaging
service ("SMS"), and the like. Once so transformed, the electronic value
tokens may be redeemed
by the user, after authentication, without possession of the physical
representation such as gift
cards by accessing the user's electronic wallet during purchase. In this way,
the use of the term
value token herein refers to electronic representations and physical
representations that can be
transformed into electronic representations. In at least one etnbodiment, the
physical gift card is
inoperative after transformation. In an alternative embodiment, the physical
gift card is inoperative
after redemption of the electronic value token using the electronic wallet or
the physical gift card
36
Date Recue/Date Received 2023-05-17
[0093] Consumer use of value tokens typically involves a vendor, a
redeeming merchant or
retailer, and an issuer. In various embodiments, the vendor, redeeming
merchant, and issuer may
be the same, different, or related entities. The point of sale where value
tokens are purchased or
otherwise made available for inclusion in an electronic wallet may be referred
to as the vendor.
Thus, the vendor sells the electronic value tokens themselves although the
electronic value tokens
may be redeemed at another place of business. An entity that will accept a
value token for
business transactions, for example as tender for a purchase, may be referred
to as a redeeming
merchant or retailer. For example, a grocery store may sell the electronic
value token of an apparel
store. The grocery store is the vendor and the apparel store is the redeeming
merchant or retailer.
An entity that provides the financial bacicing and/or payment processing for a
given value token
such as a prepaid card or account may be referred to as the issuer. Issuers
include direct issuers of
value tokens such as store-branded value tokens (e.g., store branded prepaid
cards or tokens issued
directly by the merchant, someti mes referred to as closed-loop prepaid
cards), and in some
embodiments the vendor may also be the issuer and/or the redeeming merchant
(e.g., a prepaid
card or token issued, sold, arid redeemed by the same merchant). Issuers al so
include financial
institutions such as banks, VISA, MasterCard, American Express, etc., and
value tokens issued by
such institutions may be readily accepted by a number of redeeming merchants
to conduct
transactions such as purchases (sometimes referred to as open loop prcpaid
cards or tokens since
they may be redeemed at a number of different merchants). Issuers may also be
the providers of
branded electronic wallets such as Google, Facebook. Twitter, and the like,
and in some
embodiments such branded wallet contains val ue tokens associated with the
issuer (e.g., Google
"cash" or credits, Pay Pal currency, Facebook electronic currency, etc.) and
may contain or be
associated with a sub-wallet containing gift card-related value tokens, a sub-
walletcontaining
credit card-related value tokens, a sub-wallet containing debit card-related
value tokens, or a
combination thereof
[00941 Generally, an electronic value token transaction computer 150
credits or debits (or takes
other actions of the type described herein) the accounts associated with the
electronic value tokens
contained within an electronic wallet or sub-wallet, The electronic value
token transaction
computer 150 may generate or forward messages to authorization systems 160 so
that the
authorization systems 160 can credit or debit (or take other action of the
type described herein) the
accounts associated with the electronic value tokens. Confirmation messages
are returned to the
37
Date Recue/Date Received 2023-05-17
electronic value token transaction computer 150 and POS device 111, anclthe
electronic wallet 10
or a sub-wallet is updated as necessary.
[0095] In at least one embodiment, transaction information is separate
from authentication
information. For example, information about a purchase item, purchase price,
purchase location,
etc. is considered transaction information and is separate from authentication
information such as
an authentication token, PIN, account number, etc. Among other things, keeping
the information
separate allows for separate proce ssing and routing, allowing for greater
efficiency and privacy.
For example, in applying the electronic value tokens according to the
configurable rule, the priority
may be based on a transaction information variables such as physical location
of a retailer
originating the electronic wallet request; transaction amount; type ofrctai
ler, time of day; day of
week; week of month; month of year, department of retailer originating the
electronic wallet
request; lane ofretailer originating the electronic wallet request;
identification ofchecker; parent
company of a retailer originating the electronic wallet request; value of val
us tokens; and type of
the electronic wallet request in various embodiments. Such transaction and/or
authentication
information may be used by the systems described herein in conjunction with
rules based decision
making (e.g., checking such transaction data to validate and apply a promotion
associated with the
transaction), for security purposes (e.g., checking such transaction data
against pre-determined
profiles to assist with fraud detection), and the like. The customer may
configure fraud prevention
parameters for security purposes, for example, by restricting purchase
transactions based on
parameters such as transaction time, velocity limits on number of transactions
(e.g., maximum of
transactions per day), velocity purchase amounts over a designated period of
time (e.g.,
maxi mum of S500/day or maximum of $100 per transaction), type of transaction,
geo-location
parameters, blocked merchant purchases, and the like. In response to a vi
olation of security, the
consumer may entirely and permanently block the transaction or configure a
release of the
transaction bawd on a parameter, such as permission or time.
[00961 In at least one embodiment, the wallet provider stands in for the
purchaser, and
redemption ofthe electronic value token occurs after the purchase. However,
this time mismatch
creates a discrepancy in the retailer's records. Specifically, the retailer
records a transaction
between the retailer and the wallet provider. The retailer records a later
redemption via value
token, seemingly for no purchase. In these instances, a third party
administrator is required that
can connect the redemption with the transaction.
38
Date Recue/Date Received 2023-05-17
[00971 There can be many ways to provision or add value tokens to an
electronic wallet. For
example, a user may pay the vendor for a value token, and the vendor may
insert the electronic
value token into the user's wallet. Alternatively, the user mayobtain a
physical representation of
the electronic value token from the vendor (e.g., a card, chit, printed
receipt, etc.) and may
subsequently add the value to the electronic wallet (for example, via a phone
or intemet accessed
user interface). The user may have a choice of many different retailers
affiliated withtlic vendor.
In other words, a given vendor may offer a plural ity of tokens associated
with di tTerentretailers.
For example, a retailer may offer promotions to compete for the user's
business when purchasing a
value token such as a prepaid account.
[0098] Each retailer may mandate a specific format for value tokens. For
example, one retailer
may regal rc a 16 digit card number plus a 4 digit month/year expiration date.
Other retailers may
require pin numbers, access numbers, card verification value numbers, card
security code numbers,
and the like. Each piece of information for di fferent retailers may have a
different format as well
as a different name. As such. an electronic wallet provider or host (for
example, a primary c-wallet
provider) would benefit by allowing third party administration for electronic
representations of
value tokens have a variety of formats such as stored value cards, credit
cards, debit cards, loyalty
and promotion cards, and other subsets of value tokens for which
administration by the primary wallet provider provider would be more
expensive.
[0099] In an embodiment, value tokens associated with prepaid cards or
accounts may be
associated with a sub-wallet within the electronic wallet (for example, a sub-
wallet of a primary,
branded electronic wallet such as a (ioogle electronic wallet), and a third
party may administer the
sub-wallet on behalf of the primary/principal electronic wallet host or
provider. For example,
during a transaction involving value tokens associated with prepaid cards or
accounts (e.g.,
electnanic or virtual stored value cards), the provider of the electronic
wallet allows a sub-wallet
associated with such value tokens to take control of a portion of the
transaction, sometimes referred
to as a sub-transaction. In an embodiment, a sub-transaction comprises a
transaction associated
with an electronic prepaid card or account such as redemption, value addition
(e.g., topping up),
activation, closure, fraud detection, etc. Specifically, the third party
administrator can quickly and
cheaplyadminister the transaction, including but not limited to determining
and/or providing the
proper formatting for the sub-transaction, and further execute the sub-
transactionindupendently
and/or in cooperation with the primary electronic wallet host or provider.
Such formatting may
39
Date Recue/Date Received 2023-05-17
relate to the particulars of information/data contained upon or associated
with a given value token
(e.g., type of card number, security code, etc.) and/or the formatting of
information or data
associated withaparticular transaction (c .g ., the characteristics,
organization, packaging, etc. of
data such as card type, transaction type, security code, etc . into messaging
fields or other data
formats for receipt/transmission while processing a transaction). For example,
the third party
administration can pass the proper transaction formatting template to the
primary wallet provider.
In at least one embodiment, the third party admi nistrator determines from the
request, or requests
from the Wier, the identity of the retailer associated with the transaction.
Preferably, the third Forty
administrator maintains a database of a plurality of transaction formats
associated with a plurality
of retai lers . After determining the identity of the retailer associated with
the transaction, the third
party administrator identifies the associated transactio n format for the
identified retailer using the
format database and all subsequent processing is performed using the retailer-
specifictransaction
format and vocabulary. In an embodiment, a user may wish to add a value token
to an electronic
wallet using a physical stored value card. The user is requested to identify
the retailer associated
with the stored value card, for example via a user interface located at a
point of sale (including, in
an embodiment, a point of sale associated with a personal computer such as on-
line shopping via
websites). In another einbodiment, the user provides information associated
with the stored value
token via a web-based or personal digital assistant interface (e.g., a mobile
phone app).
Accordingly, based upon the user provided data, the appropriate format may be
referenced from
the database and the user may be shown a pictorial representation or other
mockup representation
of the physical stored value card with the specific input information
highlighted on the mockup.
As such, the user knows exactly which inputs are required to add the
electronic value token to the
electronic wallet. The user inputted information derived from the mockup will
be in the proper
format and/or may be further modified, packaged, etc. by the third party
administrator to meet
further formatting requirements. While the example described is simple, more
complex
transactions are also possible. As will be described more fully herein,
transactions relating to (i)
using value tokens in primary and/or sub-wallets for portions of transactions
is similarly handled as
is (ii) exchanging value tokens in primary and/or sub-wallets for other types
of value tokens or
val ue token s assoe i ate d with other retailers. For example, a user may
wish to exchange a value
token associated with a retailer the user does not frequent for a value token
associated with a
retailer that the user does frequent. Moreover, the third party administrator
may use the transaction
Date Recue/Date Received 2023-05-17
format associated with the i de nti tied retailer for financial reconciliation
of the transaction or sub-
transaction (e.g., debiting and crediting a prepaid account). In this
instance, use of the proper
transaction format is not only convenient but often required.
[00100] As indicated above, an electronic sub-wallet is a specifically defined
portion of an e-
wal let located in or associated with a specific e-wallet (e.g., a primary or
principal wallet). A sub-
wallet may be administered/maintained by the primary or principal e-wall et'
sadministrator,
processor, and/or provider or may be administered by another party, system,
processor, subroutine,
or server. The separate administration of the electronic sub-wallet allows the
primary e -wallet
provider and user to take advantage of economies of scale. For example, all
electronic value
tokens may be stored in one sub-wallet while credit and debit cards are stored
in the primary e-
wal let or a separate electronic sub-wallet. As such, the provider of the
primary e-wallet may
admini stratel pc rfo rm transactions concerning val ue tokens associated with
c redi tand de bit cards
residing in the primary e-wallet while allowing a third party to
administrate/perform transactions
concerning value tokens associated with electronic value tokens residing in an
electronic sub-
wallet, freeing the third party from costly banking and credit regulations.
Moreover, the third party
administrator may use the economics of scale to receive payment for its
services via arbitrage,
commission, pay per transaction, or the like.
[00101] Via the separate administration of a sub-wallet, the third party
administrator (e.g.,
administrator of an electronic sub-wallet associated with electronic prepaid
accounts) provides
convenience to both the user and the primary electronic wallet provider.
Often, the third party
administrator is the only entity with the knowledge and expertise (e.g., a
database of required
transaction formats) to process financial reconciliations or other
transactions associated with an
electronic prepaid account associated with a given issuer. For example, a
third party administrator
may be the only entity capable of matching a particular transaction on the
retailer's book to a
particular use of a value token or electronic wallet. As discussed in more
detail herein, in some
embodiments, the third Fart), administrator carries out, implements, and/or is
responsible for all or
a portion ofthe functionality described in conjunction with the electronic
value token transaction
computer 150, for example in the context of administering one or more
electronic sub-wallets (e.g.,
an electronic sub-wallet associated witheleetronic prepaid accounts such as
closed loop accounts
issued on behalf of one or more merchants) for the primary host or provider of
an electronic wallet
such as a branded electronic wallet.
41
Date Recue/Date Received 2023-05-17
1001021 Access to the electronic wallet may be gated or protected by an
authentication token or
other means for securely accessing an electionic wallet, examples of which
include a proxy card or
a personal digital assistant or mobile device such as a smart phone. Other
embodiments for access
to the electronic wallet include cardless access such as a number/password
combination, a number
without a password, and the like. Diomctric information may also be used for
authcnticationand
access purposes, e.g. a fingerprint or iris print. Near field communication
technology may also be
used to implement authentication tokens. Near field communication technology
may be
implemented at a physical point of sale or in association with an online
transaction. In either
context, the near field communication technology may be implemented by a user
via a proxy card
(e.g., 200, 201, or 203), personal computer, personal digital assistant, smart
phone 204, or other
online transaction-related device. Thus, the authentication token may be
tangible, intangible, or a
combination thereof In an embodiment, the authentication token may be
generated, created,
and/or formed at the initiation of an electronic transaction to uniquely
identify theelectronic
transaction. In an embodiment, the uniquely generated authentication token may
comprise
elements of an electronic wallet identifier, a merchant identifier, a point of
sale identifier, an
electronic value token identifier, an electronic val ue token issuer
identifier, an electronic value
token transaction processor identifier, or combinations thereof. In another
embodiment, the
uniquely generated authentication token maybe wholly unique and not comprise
any portion of
anyprc viousidentifier,
[00103] A proxy card may be provided by a proxy card provider, for example, at
authorized
physical locations (c .g Et t a merchant's location) or via i nternet
websites. A proxy card provider
may be an entity independent of the merchant, of the c SVC processor, of the
eSVC issuer, or
combi nations thereof; alternatively, the proxycard provider may be an entity
which is the same as
one or more of the merchant of the eSVC processor, of the eSVC issuer, or
combinations thereof.
In embodiments, a user may acquire a proxy card at the authorized physical
location, via an e-
wallet application, or both. Proxy cards, in some embodiments herein, may be
virtual proxy cards
(vPC) displayed or enabled through identification information associated with
the vPC.
[00104] Inembodinaents, the proxy card provider may associate the proxy card
with one or
more electronic wall et(s) of the user (which are provisioned with one or more
eS VCs as described
herein). For example, the user may log into the user's electronic wallet and
enter an authentication
information of the proxy card (e.g., a PIN, identifying number, QItcode,
barcode, magnetic stripe,
42
Date Recue/Date Received 2023-05-17
NFC chip, or combinations thereof) via a keypad, keyboard, voice recognition
device, scanning
device, swiping dev ice, NI-C communication device, Bluctooth communication
device, Wi-Fi, or
combinations thereof. The authentication information may be received by the
proxy card provider,
the e-wallet provider, or both. The authentication information enables
association of the user's
proxy card with the user's electronic wallet. Once the proxy card is
associated with the user's
electronic wallet, the user may present the proxy card for secure access to
the electronic wallet
when the proxy card is presented at a point of sale. The association of the
proxy card with the
electronic wallet permits use of one or more eSVCs in the user's electronic
wallet to purchase
goods or services at a point-of-sale where the proxy card is presented. In an
embodiment, the
association of the proxy card with the electronic wallet may be stored in a
datal-eise.
1001051 A proxy card associated with a user's electronic wallet may comprise
an embodiment
of the means for securely accessing the user's electronic wallet described
herein. In such
embodiments, the proxy card, one or more eSVCs in the electronic wallet, or
combinations thereof
maybe used as a payment instrument for a transaction. For example, a user may
present a proxy
card or vPC which has previously been associated with the user's electronic
wallet at a point of
sale for the purchase of goods or services. Presentation of the proxy card for
purchase may be
made by communication of information (e.g., identifying information, security
information, or
both) of the proxy card via the techniques disclosed herein (e.g., swipe of
magnetic stripe, scan of
barcode or QR code, NFC communication, Bluetooth communication, virtually,
etc., or
combinations thereof). The 0-wallet provider may receive the information of
the proxy card,
retrieve the stored association, verify the proxy card is associated with the
electronic wallet, make
value of one or more eSVCs in the e-wallet available as the payment instrument
for the tran.saction,
or combinations thereof
[901061 Presentation of the proxy card may be made alone or in combination
with use of other
=arts for securely accessing the user's electronic wallet, e.g., identifying
information (e.g., an
account identifier such us a user id, email, phone number, or combinations
thereof), a security code
or security information (e.g., a P1N), or combinations thereof.
[00107] Examples of proxy cards 200, 201, 202, and 203 are depicted in Figures
6A, 6B, 6C,
and 6D. Figure 6A depicts a proxy card 200 in which the authentication
information is encoded on
the card 200 by means of a barcode 211 capable of being read by a barcode
scanner. Figure 69
depicts a proxy card 201 in which the authentication information is encoded on
a magnetic stripe
43
Date Recue/Date Received 2023-05-17
213 located on the card 201. Figurc 6C depicts a proxy card 203 in which the
authentication
information is encoded on a near field communication chip 215 on the card 203.
The
authentication information of the proxy cards 200, 201, and 203 may comprise,
for example an
account number, serial number, authorization code, digital signature,
electronic key or key code,
RFID chip/data, or combinations thereof, corresponding to and/or associated
with an e-walIct.
This same information may be used to enable the use of a vPC. The proxy
cardauthentication
information is unique to the proxy card and associates the proxy card to an
electronic wallet, and in
an embodiment such association is stored in a database accessible by an
administrator and/or
provider of the e-wallet. Additionally or al ternatively, the authentication
infbrmation of a proxy
card disclosed herein may comprise a series of numerals, a series of letters,
or a combination
thereof. The proxy cards 200, 201, and 203 may also be fashioned with personal
identification
numbers, or PINs, that may be a telephone number (or other combinations of
numbers) associstrii
with the proxy card user and/or that associated with the electronic wallet, to
be entered during the
course of the transaction, that correspond to the authentication information
and allows access
and/or use (Atha electronic wallet. In an embodiment, the RN may be encoded in
a her code 211,
a magnetic stripe 213, a NFC chip 215, a series of numerals, a series of
letters, ora combination
thereof. In an embodiment, the PIN may be obscured from view by packaging, by
an obscuring
material such as a scratch-off strip or peel-off label, or combinations
thereof. In some
embodiments, the proxy card may comprise a card security code (CSC), a card
verification value
(CVV or CV2), a card verification value code (CVVC), card verification coda
(CVC), verification
code (V-code or V code), card code yeti fic ati on (CCV), credit card ID
(CCID), or combinations
thereof, and such codes (along with any other authentication data or token
described herein) may
be employed in an authorization or authentication transaction, for example
initiated at a point of
sale in conjunction with an e-wallet payment for a purchase transaction.
1001081 In some embodiments, the proxy card may have two of a magnetic stripe,
a NH'. chip,
and a bar code (or a plurality of magnetic stripes and/or bar codes), and one
or more of such may
oontain the authentication information.
[00109] The proxy cards 200, 201, and 203 are fabricated from a suitable first
material, such as
plastic, paper, a plastic-coated paper, laminates, or combinations thereof The
proxy cards 200,
201, and 203 are typically made in a thickness range of from about 0.005 to
about 0.040 inch.
44
Date Recue/Date Received 2023-05-17
[001101 In proxy card embodiments comprising a bar code (e.g.. bar code 211),
such as a UPC
code (e.g., a GS1-128 or UCC/EAN-128), the bar code may be positioned on the
proxy card (e.g.,
proxy card 200) so that it can be scanned by well-known bar code reading
equipment. Encoded in
the bar code on the proxy card is a representation of the authentication
information.
100111] In proxy card embodiments comprising a magnetic stripe (e.g., magnetic
stripe 213 of
proxy card 201), the magnetic stripe may be made of conventional construction.
For example, a
magnetic stripe may be deposited from a slurry, positioned on the proxy card
so that it can be
scanned in magnetic stripe reading equipment such as a Tranz terminal made by
Verifone. The
magnetic stripe may comprise iron-based magnetic particles having high-
coercivity, low-
coercivity, or combinations hereof. In embodiments, the magnetic stripe may
comprise one, two or
three tracks for storage of at least a portion of the authentication
information. For additional
security, the authentication information may also be subjected to an
encryption algorithm pri or to
encoding on the magnetic stripe.
[001121 In proxy card embodiments comprising near field communication
technology, radio
frequency identification (REED) tags, microprocessors, andior microchips may
be placed on the
proxy card to be interpreted by spcci fic al ly c onfigured devices. Thc RFID
tag s, microprocessors,
and/or microchips may be used in addition to or in place of the bar code 211
on proxy card 200 and
magnetic stripe 213 on proxy card 201, or may be used in combination with
these or other means
ofencoding the authentication information on the proxy card. Alternatively,
such RFID or other
means such as near field, Bluetooth, etc. may be employed by a user operated
device (e.g., a
personal digital assistant such as a smart phone) to provide electronic wallet
access and/or
authorization functionality.
[00113] In additional or alternative embodiments, series of numerals, series
of letters, or
combinations thereof, may be placed on the proxy card to be read or
interpreted by a human or a
device, i.e. optical character recognition device, configured to interpret a
series of shapes
corresponding to the package identifier.
[00114] In an embodiment, the proxy card may comprise an authentication
device. The proxy
card's similar appearance to a credit card, debit card, and/or stored-value
card will help adoption of
and access to electronic wallets because consumers know how to use electronic
value tokens. As
such, consumers may come to think of proxy cards as multiple cards rolled into
one or sitnply
think of a proxy card as an electronic wallet itself, despite being a physical
representation.
Date Recue/Date Received 2023-05-17
1001151 Figure 6D depicts a proxy card 202 which comprises a rewriteable
magnetic stripe 210,
a smart chip 209, a wireless communicator 206, and an interface 208. The
wireless communicator
206 may be operably connected to the smart chip 209. The interface208 may be
operatively
connected between the smart chip 209 and the rewriteable magnetic stripe 210.
As can be seen in
Figure 6D, the proxy 'card 202 may be operably connected with a computer
device 212, a
programming devi ce 214, a point-of-sale device (POS ) 216, or combinations
thereof. The proxy
card 202 may be referred to herein as a "wallet redemption card"
[00116] The wallet redemption card 202 may be associated with an electronic
wallet as
previously described for the disclosed proxy cards (e.g., via presentation of
authentication
information of the proxy card).
[001171 The rewriteable magnetic stripe 210 may comprise iron-based magnetic
particles
having high-coercivity,low-coercivity, or combinations hereof. hi embodiments,
the magnetic
stripe 210 may comprise one, two or three tracks for storage of at least a
portion of the payment
information of at least one payment account. Generally, payment information
may be written to,
erased, and re-written to the rewriteable magnetic stripe 210. In an
embodiment, the payment
information is written to the rewriteable magnetic stripe 210 after the proxy
card 202 is associated
with an electronic wallet. The rewriteable magnetic stripe 210 may be
configured to: i) receive
paprontinformation, ii) store payment information, or iii) combinations
thereof.
[00118] As used herein, "payment information" refers to information associated
with a payment
account. The payment information is used for a transaction with a merchant. In
embodiments,
payment information may comprise an account number, UPS, security information,
e.g., a card
security code (CSC), a card verification value (CVV or CV2), a card
verification value code
(CVVC), card verification code (CVC), verification code (V-code or V code),
card code
verification (CCV), credit card ID (CCID), a phone number, an identification
number (e.g., PIN,
driver's license number, passportnumber, visa number, social security number),
expirationdate,
account issuer identification number, billing address, or combinations
thereof.
1001191 As used herein, "payment account" refers to an account that may be
used to transact
business with a merchant willing to accept a value in the account (e.g.,
points, miles, dollars, or any
other measure of value), for example as tender for a purchase or discount for
a purchase. As used
herein, "payment account" may additionally or alternatively refer to an
account used for
promotional and/or marketing purposes. Examples of such payment accounts
include credit
46
Date Recue/Date Received 2023-05-17
accounts, debit accounts, gift accounts, telephone accounts, loyalty accounts,
membership
accounts, ticket accounts, entertainment accounts, sports accounts, prepaid
accounts, discount
accounts, healthcare accounts and the like. Such accounts may be associated
with corresponding
card products, including credit cards, debit cards, gift cards, telephone
cards, loyalty cards,
membership cards, ticket cards, entertainment cards, sports cards,
prepaidcards, discount cards,
healthcare cards and the like.
1001201 In an embodiment, the rewriteable magnetic stripe 210 maybe configured
to receive
paymentinformation from the smart chip 209, for example, via interface 208. In
an embodiment,
only a portion of the payment information for a payment account is received by
the rewriteable
magnetic stripe 210 from the smart chip 209. In additional or alternative
embodiments, the entire
payment information for a payment account is received by the rewriteablc
magnetic stripe 210
from the smart chi p 209. In embodiments, at least a portion of payment
information for more than
one payment account (e.g., a first payment account and a second payment
account) is received by
the rewriteable magnetic stripe 210 from the smart chip 209.
1001211 In an additional or alternative embodiment, the rewriteable magnetic
stripe 210 may be
configured to receive payment information from a programming device 214 (e.g.,
a magnetic stripe
encoder). In an embodiment, only a portion ofthe payment information for a
payment account is
received by the rewriteable magnetic stripe 210 from the programming device
214. In additional or
alternative emboditnents, the entire payment information for a payment account
is received by the
rewriteable magnetic stripe 210 from the programming device 214. In
embodiments, at least a
portion of payment information for more than one payment account (e.g., a
first payment acvount
and a second payment account) is received by the rewriteable magnetic stripe
210 from the
programming device 214.
100122] In an embodiment, the rewriteable magnetic stripe 210 may be
configured to store any
type of payment information described hereinabove, for example, as chosen by
an account issuer.
The payment information may be stored on the first track, the second track,
the third track, or
combinations thereof, of the magnetic stripe 210. In an embodiment, only a
portion of the payment
information for a payment account is stored on the rewriteable magnetic stripe
210. In additional or
alternative embodiments, the entire payment information for a payment account
is stored on the
rewriteable magnetic stripe 210. In embodiments, at least a portion of payment
information for
more than one payment account (e.g., a first payment account and a second
payment account) is
47
Date Recue/Date Received 2023-05-17
stored on the rcwriteable magnetic stripe 210. The rewriteable magnetic stripe
210 may store
payment information received from the smart chip 209, from the programming
device 214, or both.
1001231 In embodiments, the smart chip 209 may comprise a memory. In
additional or
alternative eml-iodiments, the smart chi p209 may comprise an integrated
circuit having a memory
associated therewith. The smart chip 209 may be configured to: i ) receive
payment information, ii)
fetch payment information, iii) store payment information, iv) read payment
information, v) write
payment information, vi) erase payment information, vii) send payment
information, or viii)
combinations thereof. The smart chip 209 may be positioned on the surface of
the wallet
redemption card 202; additionally or alternatively, the smart chip 209 may be
embedded within the
wallet redemption card 202.
1001241 In an embodiment, the smart chip 209 may be configured to receive
payment
information from a computer device 212 (e.g., via wireless communicator 206).
In an embodiment,
only a portion of the payment information for a payment account is received by
the smart chip 209
from the computer device 212. In additional or alternative embodiments, the
entire payment
information for a payment account is received by the smart chip 209 from the
computer device
212. In emixdiments, at least a portion of payment information for more than
one payment account
(e.g., a first payment account and a second payment account) is received by
the smart chip 209
from the computer device 212.
1001251 In an embodiment, the smart chip 209 may be configured to store
payment information
in a memory of the smart chip 209. In an embodiment, only a portion of the
payment information
for a payment account is stored on the smart chip 209. In additional or
alternative embodiments,
the entire payment information for a payment account is stored on the smart
chip 209. In
embodiments, at least a portion of payment information for more than one
payment account (e.g., a
first payment account and a second payment account) is stored on the smart
chip 209. The smart
chip 209 may store payment information re cei N'ed from the re w ri teable
magnetic stripe 210, the
computer device 212, or both.
[00126] In an embodiment, the smart chip 209 may be configured to read payment
information
from a memory of the smart chip 209. In an embodiment, only a portion of the
payment
information for a payment account is read by the smart chip 209 from the
memory of the smart
ohip 209. In additional or alternative embodiments, the entire payment
information for a payment
account is read by the smart chip 209 from the memory of the smart chip 209.
In embodiments, at
48
Date Recue/Date Received 2023-05-17
least a portion of payment information for more than one payment account
(e.g., a first payment
account and a second payment account) is read by the smart chip 209 from the
memory of the
smart chip 209.
1001271 In an embodiment, the smart chip 209 may be configured to write
payment information
to the memory of the smart chip 209. In an embodiment only a portion of the
payment information
for a payment account is written by the smart chip 209 to the memory of the
smart chip 209. In
additional or al ternative embodiments, the entire payment information for a
payment account is
written by the smart chip 209 to the memory of the smart chip 209. In
embodiments, at least a
portion of payme nt information for more than one payment account (e.g., a
first payment account
and a second payment account) is written by the smartchip 209 to the memory of
the smart chip
209.
[001281 In an embodiment. the smart chip 209 may be configured to erase
payment information
from the magnetic stripe 210. For example, the smart chip 209 is configured to
erase payment
informationfrom the magnetic stripe 210 after using the wallet redemption card
202 (e.g., the
re A.vri teable magnetic stripe 210 or the smart chip 209 of the wallet
redemption. card 202) for a
payment transaction (c .g., purchase, redemption, discount, or c om hi nations
thereof). The smart
chip 209 may additionally or alternatively be configured to erase payment
information from the
magnetic stripe 210 less than about 30, 25,20, 15, 10,9, 8, 7,6, 5, 4, 3, 2,
1, 0.1, 0.01 or less
minutes after the payment information is wriften to the re write able magnetic
stripe 210. The smart
chip 209 may additionally ur alternatively be configured to erase payment
information from the
magnetic stripe 210 less than about 30, 25, 20, 15, 10, 9, 8, 7, 6, 5, 4, 3,
2, 1, 0.1, 0.01 or less
minutes after receiving the payment information from a programming device 214.
The smart chip
209 may additionally or alternatively be configured to erase payment
information from the
magnetic stripe 210 less than about 30, 25, 20, 15, 10, 9, 8, 7, 6, 5, 4, 3,
2, 1, 0.1, 0.01 or less
minutes after payment information is written to the memory of the smart chip
209.
[00129] In embodiments, at least a portion of the payment information for one
or more payment
accounts (e.g., a sole payment account, a first payment account and a second
payment account,
etc.) is erased by the smart chip 209 from the magnetic stripe 210. In an
embodiment, the smart
chip 209 may erase only a portion of the payment information for a payment
account contained on
the magnetic stripe 210 (e.g., contained on the first track, second track,
third track or combinations
thereof). In additional or alternative etnboditnents, the smart chip 209 may
erase only a portion of
49
Date Recue/Date Received 2023-05-17
the payment information for a first payment accotuit and only a portion of the
payment information
of a second payment aceount contained on the magnetic stripe 210. In
additional or alternative
embodiments, the smart chip 209 may erase the entire payment information of
one or more
payment accounts contained o n the magnetic stripe 210. In additional or
alternative embodiments,
the smart chip 209 may erase the entire payment i nforrnati on of a first
payment account contained
on the magnetic stripe 210 and only a portion of the payment information of a
second payment
account contained on the magnetic stripe 210.
[00130] In an additional or alternative embodiment, the smart chi p209 may be
configured to
erase payment information from a memory of the smart chip 209. For example,
the smart chip 209
is configured to erase payment information from the memory after using the
wallet redemption
card 202 (e.g., the rewriteable magnetic stripe 210 or the smart chip 209
ofthe wallet redemption
card 202) for a payment transaction (e.g., purchase, redemption, discount, or
combinations
thereof).The smart chip 209 may additionally or alternatively be configured to
erase payment
information from the memory less than about 30, 25, 20, 15, 10, 9, 8, 7, 6, 5,
4, 3, 2, 1, 0.1, 0.01 or
less minutes after the payment information is written to the memory. The smart
chip 209 may
additionally or al ternatively be configured to erase payment information from
the memory after
receiving the payment information from a computer device 212. The smart chip
209 may
additionally or alternatively be configured to erase payment information from
the memory less
than about 30, 25, 20, 15, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0.1, 0.01 or less
minutes after reading and/or
receiving the payment information from the rewriteable magnetic stripe 210.
The smart chip 209
may addi tional ly or alternatively be configured to erase payment information
from the memory
less than about 30, 25, 20, 15, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0.1, 0.01 or
less minutes after the payment
information is written to the rewriteable magnetic stripe 210.
1001311 In embodiments, at least a portion of the payment information for one
or more payment
accounts (e.g., a sole payment account, a first payment account and a second
payment account,
etc.) is erased by the smart chip 209 from the memory of the smart chip209. In
an embodiment,
the smart chip 209 may erase only a portion of the payment information for a
payment account
contained on the memory. In additional or alternative embodiments, the smart
chip 209 mayerase
only a portion of the payment information for a first payment account and only
a portion of the
payment information of a second payment account contained on the memory. In
additional or
alternativeembodiments.the smart chip 209 may erase the entire payment
information of one or
Date Recue/Date Received 2023-05-17
more payment accounts contained on the memory. In additional or alternative
embodiments, the
smart chip 209 may erase the entire payment information of a first payment
account contained on
the memory and only a portion of the payment information of a second payment
account contained
on the memory.
[00132J In an embodiment, the smart chi p 209 may be configured to send
payment information
to a point-of-sale (POS) device 216.1n an embodiment, only a portion of the
payment information
fora payment account is sent from the smart chip 209 to the POS device 216. In
additional or
alternative embodiments, the entire payment information for a payment account
is sent by the
smart chip 209 to the POS device 216. In embodiments, at least a portion of
payment information
for mom than one payment account (e.g., a first payment account and a seoond
payment account) is
sent by the smart chip 209 to the POS device 216. For example, the smart chip
209 maysend
payment information for a first payment account to the POS device 216 for a
first portion of a
transaction (e.g., a first partial payment by currency, a discount, or other
transaction value (e.g.,
points, miles, or any other measure of value)), and the smart chip 209 may
send payment
information for a second payment account to the POS device 216 for a second
portion of the
transaction (e.g., a second partial payment by eminency, a discount, or other
transaction value (e.g,
points, miles, or any other measure of value)). In embodiments, the smart chip
209 may send
payment information for a plurality of payment accounts to cover a plurality
of portions of the
transaction so as to accomplish a complete transaction.
[00133] In an additional or alternative embodiment, the smart chip 209 may be
configured to
send payment information to the rewritcable magnetic stripe 210 via the
interface 208. In m
embodiment, only a portion of the payment information for a payment account is
sent from the
smart chip 209 to the rewriteable magnetic stripe 210 via the interface 208.
In additional or
alternative embodiments, the entire payment information for a payment account
is sent by the
smart chip 209 to the rewritcable magnetic stripe 210 via the interface 208.
In embodiments, at
least a portion of payment information for more than one payment account
(e.g., a first payment
account and a second payment account) is sent by the smart chip 209 to
interface 208. For
example, the smart chip 209 may send payment information for a first payment
account to the
rewritcable magnetic stripe 210 via the interface 208 for a first portion of a
transaction (e.g., a first
partial payment by currency, a first discount, or other transaction value
(e.g., points, miles, or any
other measure of value)), and the smart chip 209 may send payment information
for a second
51
Date Regue/Date Received 2023-05-17
payment account to the rewriteable magnetic stripe 210 via the interface 208
for a second portion
of the transaction (e.g., a second partial payment by currency, a second
discount, or other
transaction value (e.g., points, miles, or any other measure of value)). In
embodiments, the smart
chip 209 may send payment information for a plurality of payment accounts to
cover a plurality of
portions of the transaction so as to accomplish a complete transaction.
[00134] In embodiments, the smart chip 209 may send payment information for a
first payment
accountto the rewriteable magnetic stripe 210 via the interface 208 for a
first portion of a
transaction (e.g., a first partial payment by currency, a first discount, or
other transaction value
(e.g., points, miles, or any other measure of value)), and the smart chip 209
may send payment
information for a second payment account to the POS device 216 via the
wireless communicator
206 fora second portion of the transaction (e.g., a second partial payment by
currency, a second
discount, or other transaction value (e.g., points, miles, or any other
measure of value)). In
embodiments, the smart chip 209 may send payment information for a plurality
of payment
accounts to cover a plurality of portions of the transaction so as to
accomplish a complete
transaction via both the rewriteable magnetic stripe 210 via the interface 208
and the wireless
communicator 206.
[00135] In embodiments where at least a portion of payment information is
erased from the
rewriteable magnetic stripe 210, the smart chip 209 may be configured to
resend payment
information to the rewriteable magnetic stripe 210 via the interface 208. In
an embodiment, only a
portion of the payment information for a payment account is resent by the
smart chip 209 to the
rewriteable magnetic stripe 210 via the interface 208. In additional or
alternative embodiments, the
entire payment information for a payment account is resent by the smart chip
209 to the rewriteable
magnetic stripe 210 via the interface 208. In embodiments, at least a portion
of payment
information for more than one payment account (e.g., a first payment account
and a second
payment account) is resent by the smart chip 209 to the rewriteable magnetic
stripe 210 via the
interface 208.
[00136] In embodiments where at least a portion of payment information is
erased from the, the
smart chip 209 may be configured to rewrite payment information to the memory
of the smart chip
209. In an embodiment, only a portion of the payment information for a payment
account is
rewritten by the smart chi p 209 to the memory of the smart chip 209. In
additional or al temative
embodiments, the entire payment information bra payment account is rewritten
by the smart chip
52
Date Recue/Date Received 2023-05-17
209 to the memory of the smart chip 209. In embodiments, at least a portion of
payment
information fOr more than one payment account (e.g., a first payment account
and a second
payment account) is rewritten by the smart chip 209 to the memory of the smart
chip 209.
[00137] The wireless communicator 206 may comprise a transmitter, a receiver,
or
c ombi nations there f (e.g., atranseeiveror transrni tter-receiver). I n an
embodiment, the wireless
communicator 206 may comprise an antenna. The wireless communicator 206 may be
positioned
on the surface of the wallet redemption card 202; additionally or
alternatively, the wireless
communicator 206 may be embedded within at least a portion of the wallet
redemption card 202.
In embodiments, the wireless communicator 206 may be separate with the smart
chip 209;
alternatively, the wireless c,omin unicator 206 may be integral with the smart
chip 209.
[0013811 In embodiments, the wireless communicator 206 may be configured to
communicate
payment information via Bluetooth communication, near field communication
(NFV), Wi-Fi
communication, satellite communication eel lul ar communicati on, orcombi
nations thc reo& e.g.,
from a computer device 212 to the smart chip 209. In an embodiment, only a
portion of the
payment information tor a payment account iscommunicaled by the wireless comm
uni cator 206
from the computer device 212 to the smart chip 209. In additional or
alternative embodiments, the
entire payment information for a payment account is communicated by the
wireless communicator
206 from the computer device 212 to the smart chip 209. In embodiments, at
least a portion of
payment information for more than one payment account (e.g., a first payment
account and a
second payment account) is communicated by the wireless communicator 206 from
the computer
device 212 to the smart chip 209.
1001391 In additional or alternative embodiments, the wireless communicator
206 may be
configured to communicate payment information via Bluetooth communication,
near field
communi c ati on (NFC), VV i-F i co min uni cat io n, satellite communication,
cellul a rcommuni cati on,
or combinations thereof, e.g., from the smart chip 209 to a point-of-sale
(PUS) device 216. In an
embodiment, only a portion of the payment information for a payment account is
communicated
by the wireless communicator 206 from the smart chip 209 to the POS device
216. In additional or
alternative embodiments, the entire payment information fora payment account
is communicated
by the wireless communicator 206 from the smart chip 209 to the POS device
216. In
embodiments, at least a portion of payment information for more than one
payment account (e.g., a
53
Date Recue/Date Received 2023-05-17
first payment account and a second payment account) is communicated by the
wireless
communicator 206 from the smart chip 209 to the POS device 216.
[00140] The interface 208 may comprise a device capable of reading and/or
writing magnetic
data from and/or to the rewriteable magnetic stripe 210. Such device may
include a magnetic read
head, a magnetic write head, both, or a combination thereof. The magnetic read
and/or magnetic
write head(s) may be configured to read and/or write one track, two tracks, or
three tracks on the
magnetic stripe 210. The interface 208 may be positioned on the surface ofthe
wallet redemption
card 202; additionally or alternatively, the interface 208 may he embedded
within at least a portion
of the wallet redemption card 202. In embodiments, the interface 208 may be
separate from the
smart chip 209; alternatively, the interface 208 may be integral with the
smart chip 209. In
embodiments, the interface 208 may be movable (e.g., automated or manual) over
the magnetic
stripe 210 for reading and writing operations by the interface 208 and movable
(e.g., automated or
manual) away from the magnetic stripe 210 for reading and writing operations
by a programming
device 214 and/or POS device 216. In additional or alternative embodiments,
the interface 208
may be configured to: i) convert magnetic data to digital data and vice versa,
ii) read payment
information, iii) write payment information, or iv) combinations thereof.
[00141] In an embodiment., the interface 208 may be configured to receive
payment information
represented as digital data from the smart chip 209. In an embodiment, only a
portion of the
payment information for a payment account is received by the interface 208
from the smart chip
209. In additional or alternative embodiments, the entire payment information
for a payment
account is received by the interface 208 from the smart chip 209. In
embodiments, at least a
portion of payme nt information for more than one payment account (e.g., a
first payment account
and a second payment account) is received by the interface 208 from the smart
chip 209.
[00142] In an embodiment, the interface 208 may be configured to convert
payment information
represented as magnetic data contained on the rewriteable magnetic stripe 210
to payment
information represented as digital data for use and/or storage by the smart
chip 209. In an
additional or alternative embodiment, the interface 208 may be configured to
convert payment
information represented as digital data used and/or stored on the smart chip
209 to payment
information represented as magnetic data contained on the rewriteable magnetic
stripe 210. The
magnetic data may comprise at least a portion of payment information of a
payment account. The
digital data may comprise at least a portion of payment information of a
payment account.
54
Date Recue/Date Received 2023-05-17
[001431 In an embodiment, the interface 208 may be configured to read payment
information
from the magnetic stripe 210 (for example, via interface 208). Payment
information read by the
interface 208 may be stored by the smart chip 209 as described herein. In an
embodiment, only a
portion of the payment information for a payment account is read by the
interface 208 from the
magnetic stripe 210. In additional or alternative embodiments, the entire
payment information for a
payment account is read by the interface 208 from the magnetic stripe 210. In
embodiments, at
least a portion of payment information for more than one payment account
(e.g., a first payment
account and a second payment account) is read by the interface 208 from the
magnetic stripe 210.
[0014-1] In an embodiment, the interface 208 may be configured to write
payment information
to the rewriteable magnetic stripe 210. Payment information written to the
magnetic stripe 210 may
be stored by the rewriteable magnetic stripe 210. In an embodiment, only a
portion of the payment
information fbr a payment account is written by the interface 208 to the
magnetic stripe 210. In
additional or alternative embodiments, the entire payment information fora
payment account is
written by the interface 208 to the magnetic stripe 210. In embodiments, at
least a portion of
payment information for more than one payment account (e.g., a first payment
account and a
second payment account) is written by the interface 208 to the magnetic stripe
210.
[00145] The computer device 212 may comprise a smartphone, a laptop, a tablet,
a PC, a cloud
computing system, a satellite, a cellular network, or combinations thereof.
The computer device
212 may comprise a computer device disclosed herein above or may be a computer
device separate
of the computer devices disclosed he rei nabove. The computer device 212 may
include a payment
account application which contains the payment information which a user of the
system can
transfer to the wallet redemption card 202. The payment account application
may have a user
interface which allows a user of the computer device to select one or more
payment accounts and
suitable payment information associated with the payment account( s) for
communication to the
wallet redemption card 202 and/or the programming device 214. Alternatively,
the payment
account application may automatically choose one or more payment accounts and
suitable payment
information associated with the onc or more payment accounts for eommunication
to the wallet
redemption card 202 and/or the programming device 214.
[00146] The programming device 214 may comprise any device suitable for
programming the
rewriteable magnetic stripe 210 of the disclosed wallet redemption card 202.
For example, the
Date Recue/Date Received 2023-05-17
programming device 214 may comprise a magnetic stripe encoder. The programming
device 214
may be configured to write the payment information to the rewriteable magnetic
stripe 210.
1001471 The POS device 216 may comprise any device or terminal suitable for
accomplishing a
transaction with the smart chip 209 and/or magnetic stripe 210 of the wallet
redemption card 202.
Additionally, the POS device 216 may comprise any POS device or point of sale
device described
herein_ The PUS device 216 may be located at a vendor and/or redeeming
merchant or retailer, but
alternatively located at a kiosk or at a user's home or office where a
personal computer is
configured to act as a point of sale, for example during an on-line
transaction. The POS device
may be configured to read the payment information from the rewriteable
magnetic stripe 210 of the
wallet redemption card 202.
1001481 The computer device 212, programming device 214, and POS device 216
may operably
connect to the wallet redemption card 202 in any suitable sequence or
simultaneously. For
example, an operable connection may be established between the computer device
212 and the
wallet redemption card 202, and the wallet redemption card 202 may receive
payment information
from the computer device 212. An operable connection optionally may then be
established
between the programming device 214 and the wallet redemption card 202, and the
wallet
redemption card 202 may receive payment information from the programming
device 214. The
wallet redemption card 202 may then establish an operable connection with a
POS device 216 for a
transaction. In another example, an operable connection may be established
between the
programming device 214 and the wallet redemption card 202, and the wallet
redemption card 202
may receive payment information from the programming device 214. An operable
connection
optionally may then be established between the computer device 212 and the
wallet redemption
card All, and the wallet redemption card 202 may receive payment information
from the computer
device 212. The wallet redemption card 202 may then establish an operable
connection with a POS
device 216 for a transaction. Generally, an operable connection is established
between the wallet
redemption card 202 and the POS device 216 after payment information is
received by the wallet
redemption card 202 from the computer device 212 and/or programming device
214.
100149] Payment information associated with a payment account may be
communicated from
the computer device 212 to the wallet redemption card 202. The smart chip 209
mayreceive the
payment information via the wireless communicator 206. Upon receipt of the
payment
information, the smart chip 209 may send payment information to the
rewriteable magnetic stripe
56
Date Recue/Date Received 2023-05-17
210 via the interface 208, may write payment information to the memory of the
smart chip 209,
may send payment information to the POS device 216 via the wireless
communicator 206, or
combinations thereof. The wireless communicator 206 may be configured to
communicate wireless
signals (e.g., Bluetooth, Wi-H, near field communication, or combinations
thereof) between the
computer device 212 and the smart chip 209.
1001501 When the smart chip 209 sends payment information to the magnetic
stripe 210 via the
interface 208, the payment information is in a digital data format. The
interface 208 may receive
the payment information in a digital data format and may convert the payment
information from a
digital data format to a magnetic data format. The interface 208 may then
write the payment
information (represented in magnetic data format) to the rewriteable magnetic
stripe 210. The
rewriteable magnetic stripe 210 may store the payment infonination in magnetic
data format. The
rewriteable magnetic stripe 210 may then be used for a payment transaction,
for example, by
swiping the rewriteable magnetic stripe 210 on the POS device 216. In an
embodiment, the
rcwriteablemagnclic stripe 210 may also have the dual functionality of storing
payment
information without using the rewriteable magnetic stripe 210 for a payment
transaction. In such
an embodiment, the rewriteable magnetic stripe 210 may serve only as a storage
medium rather
than as a mechanism for using the wallet redemption card 202 in a payment
transaction. For
example, the rewriteable magnetic stripe 210 may serve as a storage medium for
later retrieval of
the payment information by the smart chip 209 via the interface 208 (e.g., in
locations where smart
chip data security is more of a. concern than magnetic strip data security).
Storage of payment
information on the rewriteable magnetic stripe 210 may occur indefinitely or
for a storage period,
for example, for less than about 30, 25, 20, 15, 10,9, 8, 7,6, 5, 4, 3,2, 1,
0.1, 0.01 or less minutes.
1001511 Whenthe smart chip 209 writes payment information to the memory of the
smart chip
209, the smart chip 209 may serve the function of storing the payment
information. Storage of
payment information on the memory of the smart chip 209 may occur indefinitely
or for a storage
period, for example, for less than about 30, 25, 20, 15, 10, 9, 8, 7, 6, 5,4,
3, 2, 1, 0.1, 0.01 or less
minutes. The smart chip 209 may take no further notion during storage of the
payment information,
or the smart chip 209 may perform other actions during storage. For example,
the smart chip 209
may send payment information to the magnetic stripe 210 via interface 208, may
send the payment
information to the POS device 216, or combinations thereof
57
Date Recue/Date Received 2023-05-17
[00152] When the smart chip 209 sends payment information to the POS device
216 via the
wireless communicator 206, a payment transaction may occur between the smart
chip 209 and the
POS device 216. After a payment transaction occurs, the smart chip 209 may
take no action. In
such a scenario, the smart chip 209 may wait to receive payment information or
may wait to again
send the payment information to a POS device (e.g., POS device 216). After a
payment
transaction occurs, the smart chi p209 may perform other actions, for example,
the smart chip 209
may send the payment information to the rewriteable magnetic stripe 210 via
the interface 208 as
described above (e.g., i f the payment information is not already on the
magnetic stripe 210), the
smart chip 209 may write payment information to the memory of the smart chip
209 as described
above (e.g., if not already done, if the payment information is different
(e.g., a second payment
information or a different portion), or if the payment information was
erased), the smart chip 209
may erase payment information from the rewriteable magnetic stripe 210, the
smart chip 209 may
erase payment information from the memory of the smart chip 209, the smart
chip 209 may again
receivepayment information (the same as before or different, e.g., a second
payment information
or a different portion of the payment accounting information).
[00153] As described hereinabove, the smart chip 209 may erase payment
information from the
rewriteable magnetic stripe 210, the memory of the smart chip 209, or both.
After payment
information is erased from the rewri table magnetic stripe 210, the smart chip
209 may resend
payment i nformati on to the rewriteable magnetic stripe 210, whereafter the
interface 208 convert
the data and writes the payment information to the rewriteable magnetic
stripe, as described above.
After payment information is erased from the memory of the smart chip 209, the
smart chip 209
may re-write payment information to the memory.
[00154] In embodiments, a programming device 214 may write the payment
information
associated with a payment account to the re wri teable magnetic stripe 210.
After the payment
information is received (e.g., written to) the rewriteable magnetic stripe 210
from the programming
device 214, the rewriteable magnetic stripe 210 may store the payment
information in magnetic
data format. The re write able magnetic stripe 210 may then be used for a
payment transaction, for
example, by swiping the rewriteable magnetic stripe 210 on the POS device 216.
In an
embodiment, the rewri te able magnetic stripe 210 may also have the dual
functionality of storing
payment information without using the rewriteable magnetic stripe 210 for a
payment transaction.
In such an embodiment, the rewriteable magnetic stripe 210 may serve only as a
storage medium
58
Date Recue/Date Received 2023-05-17
rather than as a mechanism for using the wallet redemption card 202 in a
payment transaction. For
example, the rewriteable magnetic stripe 210 may serve as a storage medium for
later retrieval of
the payment information by the smart chip 209 via the interface 208 (e.g., in
locations where smart
chip data security is more of a concern than magnetic strip data security).
Storage of payment
information on the rewriteable magnetic stripe 210 may oocur indefinitely or
for a storage period,
for example, for less than about 30, 25, 20, 15, 10,9, 8, 7,6, 5, 4, 3, 2, 1,
0.1, 0.01 or less minutes.
[001551 In embodiments, the smart chip 209 and the rewriteable magnetic stripe
210 may
receive the payment information from the corn [niter device 212 (e.g., the
smart chip 209 sends the
payment information received from the computer device 21210 the magnetic
stripe 210 via the
interface 208), or the smart chip 209 may receive payment information (e.g.,
from the computer
device 212) and the rewriteable magnetic stripe 210 may receive payment
information (e.g., from
the programming device 214). The smart chip 209 may receive payment
information (e.g., from
the computer device 212) and the rewriteable magnetic stripe 210 may receive
payment
information (e.g., from the programmi ng device 214) independently, or the
computer device 212
may be used to control the transfer of payment information from the program
mingdevice 214 to
the rewriteable magnetic stripe 210 of the wallet redemption card 202.
[00156J Embodiments of methods for operating the wallet redemption card 202
may also utilize
multiple payment information associated with multiple payment accounts. For
example, a first
payment information may be associated with a first payment account (e.g., a
credit account, debit
account, gift account, or rewards account) and a second payment information
may be associated
with a second payment account (e.g., a credit account, debit account, gift
account, or rewards
account different from the first payment account), and the wallet redemption
card 202 may utilize
both the first payment information and the second payment information for one
or more payment
transactions.
1001571 In an embodiment, the smart chip 209 may receive the first payment
information and
the second payment information according to methods disclosed hercinabove
(e.g., from the
computer device 212 via the wireless communicator 206). The smart chip 209 may
then write
either or both the first payment intimation and the second payment information
to the memory of
the smart chip209. Alternatively or additionally, the smart chip 209 may send
either or both the
first payment inform ati on and the second payment information to the
rewriteable magnetic stripe
210 via the interface 208, wherein the interface 208 writes either or both the
first payment
59
Date Recue/Date Received 2023-05-17
information and second payment information to the rewriteable magnetic stripe
210. The smelt
chip 209 may write both the first payment information and the second payment
information to the
memory of the smart chip; alternatively or additionally, the smart chip 209
may send (and the
interface 208 may write) both the first payment information and the second
payment information to
the magnetic stripe 210 via the interface 208; alternatively, the smart chip
209 may send the first
payment information to the magnetic stripe 210 and may write the second
payment information to
the memory of the smart chip 209; alternatively, the smart chip 209 may send
the second payment
information to the magnetic stripe 210 and may write the first payment
information to the memory
of the smart chip 209. The smart chip 209 may erase either or both the first
payment information
and the second payment information from either or both of the rewriteable
magnetic stripe 210 and
the memory of the smart chip 209 according tothe erasing conditions described
hereinabove. The
first paymait information and the second payment information may be resent to
the rewritcable
magnetic stripe 210 and rewritten to the memory of the smart chip 209
according tothe methods
described hereinabove.
[00158] In an embodiment, the smart chi p 209 may receive the first payment
information (e.g.,
via the computer device 212) and the rewriteable magnetic stripe 210 may
receive the second
payment information (e.g., via the programming device 214). In such an
embodiment, the second
payment information does not reach the smart chip 209 unless the smart chip
209 later receives the
second payment information from the computer device 212. The rewriteable
magnetic stripe 210
mayreceive the first payment information from the smart chip 209 according to
the methods
described hereinabove (e.g., via the interface 208). The smart chip 209 may
enase the first payment
information (alternatively, also the second payment information if the second
payment information
is later received from the computer device 212) from the memory of the smart
chip 209. The smart
chip 209 may erase the second payment information from the rewriteable
magnetic stripe 210
(alternatively, also the first payment information if thc smart chip 209 sends
the first payment
information to the magnetic stripe 210). The first payment information may be
resent to the
rewriteable magnetic stripe 210, the first payment information may be
rewritten to the memory of
the smart chip 209, the second payment information may be rewritten to the
rewriteable magnetic
stripe 210, or combinations thereof.
[00159] In an embodiment, the rewriteable magnetic stripe 210 may receive the
first payment
information and the second payment information from the programming device
214. The first
Date Recue/Date Received 2023-05-17
payment informati on andfor the second payment information written on the
rewrite able magnetic
stripe 210 may then be used for a payment transaction. The smart chip 209 may
erase either or both
the first payment information and the second payment information from the
rewri te able magnetic
stripe 210 according to the methods disclosed herei nabove. The first payment
information and the
second payment information may be rewritten to the re writeable magnetic
stripe 210 according to
the methods described hereinabove.
[00160] Embodiments of methods for operating the wallet redemption card 202
may also utilize
a payment information comprising a first portion and a second portion. For
example, the first
portion may comprise certain information of the payment account (e.g., an
account number, UPS, a
card security code (CSC), a card verification value (CVV or CV2), a card
verification value code
(CVVC), card verification code (CVC), verification code (V- code or V code),
card code
verification (CCV), credit card ID (CCID), a phone number, an identification
number (e.g., PIN,
driver's license number, passport n umber, visa number, social security
number)), and the second
portion may comprise certain other information of the payment account (e.g.,
an account number,
UPS, a card security code (CSC), a card verification value (CVV or CV2), a
card verification value
code (CVVC), card verification code (CVC), verification code (V-code or V
code), card code
verification (CCV), credit card ID (CCID), a phone number, an identification
number (e.g., PIN,
driver's license number, paasport number, visa number, or social security
number different than the
first portion)). The wallet redemption card 202 may utilize both the first
portion and the second
portion for one or more payment transactions.
[00161] In an embodiment, the smart chip 209 may receive the first portion and
the second
portion aocording to methods disclosed hereinahove (e.g., from the computer
device 212 via the
wireless communicator 206). The smart chip 209 may then write either or both
the first portion and
the second portion to the memory of the smart chip 209. Alternatively or
additionally, the smart
chip 209 may send either or both the first portion and the second portion to
the rewriteable
magnetic stripe 210 via the interface 208, wherein the interface 208 writes
either or both the first
portion and second portion to the rewriteable magnetic stripe 210. The smart
chip 209 may write
both the first portion and the second portion to the memory of the smart chip;
alternatively or
additionally, the smart chip 209 may send (and the interface 208 may write)
both the first portion
and the second portion to the magnetic stripe 210; alternatively, the smart
chip 209 may send the
first portion to the magnetic stripe 210 and may write the second portion to
the memory of the
61
Date Recue/Date Received 2023-05-17
smart chip 209; alternatively, the smart chip 209 may send the second portion
to the magnetic
stripe 210 and may write the first portion to the incmory of the smart chip
209. The smart chip 209
may erase either or both the first portion and the second portion from either
or both of the
rewriteable magnetic stripe 210 and the memory of the smart chip 209 according
to the erasing
conditions described hereinabove. The first portion and the second portion may
be resent to the
rewriteable magnetic stripe 210 and rewritten to the memory of the smart chip
209 according to the
methods described hereinabove.
[00162] In an embodiment, the smart chip 209 may receive the first portion
(e.g., via the
computer device 212) and the rewriteable magnetic stripe 210 may receive the
second portion (e.g.,
via the programming device 214). In such an embodiment, the second portion
does not reach the
smart chip 209 unless the smart chip 209 later receives the second portion
from the computer
device 212. The rewriteable magnetic stripe 210 may:receive the first portion
from the smart chip
209 according to the methods described hereinabove (e.g., via the interface
208).
[00163] The smart chip 209 may erase the first portion (alternatively, also
the second portion if
the second portion is later received from the corn puter device 212) from the
memory of the smart
chip 209.
[00164] The smart chip 209 may erase the second portion from the rewriteable
magnetic stripe
210 (alternatively, also the first portion if the smart chip 209 sends the
first portion to the magnetic
stripe 210). The first portion may be resent to the rewriteable magnetic
stripe 210, the first portion
may be rewritten to the memory of the smart chip 209, the second portion may
be rewritten to the
rewriteable magnetic stripe 210, or combinations thereof
[00165] In an embodiment, the rewriteable magnetic stripe 210 may receive the
first portion and
the second portion from the programming device 214. The first portion and/or
the second portion
written on the rewriteable magnetic stripe 210 may then be used for a payment
transaction. The
smart chip 209 may erase either or both the first portion and the second
portion from the
rewriteable magnetic stripe 210 according to the methods disclosed
hereinabove. The first portion
and the second portion may be rewritten to the rewriteable magnetic stripe 210
according to the
methods described hereinabove_
[00166] The disclosed wallet redemption card 202 provides multiple mechanisms
for
accomplishing a payment transaction: swiping the magnetic stripe 210, using
the smart chip 209,
or transactions involving both. In locations where information security of a
magnetic stripe 210 is
62
Date Recue/Date Received 2023-05-17
of a high concern, payment information may be used on the smart chip 210 of
the wallet
redemption card 202. In locations where information security of a smart chip
209 is of high
concern, payment information may be used on the rewriteable magnetic stripe
210 of the wallet
redemption card 202.
[00167] The wallet redemption card 202 allows a user the versatility of making
payment
transactions with merchants having a point of sale device which only utilizes
the smart chi p 209
and with merchants having a point of sale device which only utilizes the
rewriteable magnetic
stripe 210. Such versatility can be usefill when travelling in locations in
which a user is not aware
which payment methods are most accepts (e.g., the magnetic stripe 210 or the
smart chip 209).
[00168] The wallet redemption card 202 further allows a user the versatility
of using different
payment accounts from issuers which only issue accounts (e.g., for security
reasons, or for reasons
related to the issuer's payment system) for use with the magnetic stripe 210
or for use with the
smart chip 209.
[00169] The erasing embodiments described herein may provide automatic
deletion of payment
information from the wallet redemption card 202. Such automatic deletion may
provide theft
deterrence as well as fraud prevention measures for users ofthe disclosed
wallet redemption card
202.
[00170] With the erasing features described herein, an original user's payment
information does
not remain on the wallet redemption card 202. The wallet redemption card 202
is thus reusable by
a single use r or by multi pie users without unauthonzed exposure of payment
information among
multiple different users. In a scenario where a wallet redemption card 202 is
lost, the finder may
use the wallet redemption card 202 for his or her payment information without
having access to the
previous user's payment information.
[00171] It is believed the versatility of the wallet redemption card 202 may
be enhanced with
the use of multiple payment informations (e.g., a first payment information
and a second payment
information). First, two traditional card products (e.g., two of a credit
card, debit card, gift card, or
rewards card) may be replaced with the wallet redemption card 202 disclosed
herein. Second, with
the erasingirese ndingire writi lig features described herein, an unlimited
number of card products
may be replaced with the wallet redemption card 202 disclosed herein because
the payment
information for any card product may be written to the smart chip 209 or
magnetic stripe 210 and
subsequently erased for repeat use of the same or different payment
information.
63
Date Recue/Date Received 2023-05-17
1001721 It is believed that information security may be enhanced when using
the payment
information divided in multiple portions (e.g., a first portion and a second
portion) because the
location of payment information is decentralized within the wallet redemption
card 202. When
decentralized, unauthorized users of the wallet redemption card 202 may not be
able to use the card
because all payment information is unavailable in a single payment mechanism
(e.g., in the
magnetic stripe 210 or in the smart chip 209). Only when all portions are
gathered at the smart chip
209 and/or rewriteable magnetic stripe 210 may a payment transaction occur.
The amount of time
in which the portions are gathered all in either the smart chip 209 or
magnetic stripe 210 relates
closely to the amount of time needed for a payment transaction because of the
erasing mechanisms
described herei 'ahoy e .
[001731 Reconciliation of transactions made (e.g., on an open loop network) by
presenting a
proxy card as disclosed hereinabove may be accomplished according to the
reconciliation
techniquesand embodiments disclosed herein. Transactions utilizing a proxy
card may be
processed via a processing switch. Transaction level reports may be generated
and provided
which differentiate between transactions made by presenting a proxy card and
transaction made by
other means of accessing the electronic wallet_
[00174] Authentication tokens may take and/or be associated with tangible or
intangible
embodiments such as a mobile device, a personal identification number, a phone
number plus a
personalidentification number, a password, a usemame plus password, biometTic
identifier, and
the like. Authentication tokens contain, provide and/or are associated with
authentication
information (e.g., electronic authentication data or information),
whichassociates a user with an
electronic wallet. As such, multiple value tokens contained in the electronic
wallet (or a sub-wallet
thereof) are associated with the user.
[00175] Any suitable authentication token as described herein such as virtual
or cardless
authentication tokens, mobile phones, etc. may be employed in the various
embodiments described
herein. Juan embodiment, the authentication token is associated with a
personal digital assistant
such as a smart phone 204, as depicted in Figure 6E. For example, an
electronic wallet stored in
and/or accessed via a phone may include an authentication token, or the phone
itsel f may contain
hardware and/or unique electronic data (e.g., authentication data such as
serial number, MAC
address, SIM card, digital signature, electronic key, user ID, phone number,
passoode, etc.) that
serves as the authentication token. Such a phone may use near field
communication to
64
Date Recue/Date Received 2023-05-17
communicate data associated with the authentication token with a point of sale
device for
authentication and transaction purposes. For example, the phone may be passed
near the point of
sale device and transfer u.ser and/or wallet information and authentication
information to the point
of sale device using near field communication protocol. The phone may transfer
all or a portion of
the wallet and/or authentication infbnnation, leaving the point of sale device
to determine which
portions are applicable to the current transaction, or the phone may transfer
only presently
applicable portions of information, i.e. information to be used during the
current transaction, to the
point of sale device. That is, logic as to the transfer of wallet and/or
authentication information
to/from the authentication token (e.g., phone) and the point of sale device
may reside on the
authentication device, on the point of sale device, or both. in an
emlxadiment, the phone may
provide hardware and/or software for authenticating a user, for example a
camera or scanner and
associated application for confirmina biometrie data associated with the user,
and upon
authenticating the user, the phone would convey the successful authentication
to the point of sale
device. The point of sale device rnay communicate with the wallet host or
provider (e.g., a primary
c-wall et host) and any sub-wallet hosts or providers, e.g., third party
administrators. In another
example, the point of sale device may communicate with only the wallet host or
provider (e.g., a
primary c-wallet host), and the wallet host or provider may communicate with
third party
administrators, for exampl e a sub-wallet host or administrator. Despite
multiple confi g urations to
enable communication, the transaction may still occur in real time with no
delay to the customer
because the parties use scalable architecture.
[001761 Returning to Figure 4A, an electronic value token transaction computer
150 accesses
electronic wallets 10 from datastore 180. The prepaid or stored value card
electronic value tokens
may include electronic representations of gi El cards, loyalty cards,
promotions, and the like. The
POS device 111 obtains authentication i nfonnati on from an e-wal let use r vi
a an authentication
token such as a smart phone or the proxy card 200 and sends the authentication
information (and is
some instances, rules for allocating the contents of the e-wallet for the
requested transaction) to the
electronic value token transaction computer 150 along with purchase
information and/or value
token information as part of a transaction request. The electronic value token
transaction computer
150 uses the authentication information to locate the correct electronic
wallet 10 or sub-wallet in
the datastore 180 and acts upon the electronic value token (e.g., adds a value
token to a primary
wallet or sub-wallet, activates a value token, debits a value token, tops-off
a value token, checks
Date Recue/Date Received 2023-05-17
the balance of a value token, etc.) or examines rules (received with the
request, associated with the
e-wallet by the electronic value token transaction processing system 100,
1100, 1200, or a
combination thereof) in light of the request's information. For example, for a
purchase transaction
the el c ctron i c value token transaction computer 150 selects the electronic
value tokens that cover
the purchase based on the rules, for example rules associated with the order
or priority in which to
apply or redeem value tokens to cover the purchase price.
[001771 As shown in Figures 5A and 511, the electronic value token transaction
computer 150
comprises a rules unit 159. The rules unit 159 provides processing,
management, associating, and
implementingfunctionalities for e-wallet (and sub-wallet) rules as provided,
selected, and/or
required by e-wallet users, e-wallet providers, e-wallet accepting merchants,
electronic value token
issuers, e-wal let transaction system administrators, andeombinations thereof.
The rules unit 159
may function to associate provided, selected, and/or require d rule s with e-
wallets and sub-wallets
maintained in the database 180 and/or e-wallet unit 199. The rules unit 159
may comprise a rules
engine for deriving rules to be applied to a transaction in the absence of (or
in place of) any
particular rule provided or selected by any other rule assigning entity. The
rules unit 159 may
taovide for e-vvallet/sub-wallet rules data to be populated via (i) e-wallet
user input (e.g., via kiosk,
smart phone, personal digital assistant, and internet accessible user
interface); e-walletprovi der
input; (iii) e-wallet system administrator's input; (iv) or any combination
thereof. For example, an
e-wallet user may, via kiosk 189 interfacing, provide the electronic value
token transaction
computer 150 with specific, customized rules detailing the manner in which
electronic value
tokens contained in the e-wallet should be prioritized for use in satisfying
transactions.
Alternatively, the same e-wallct user could simply select the types of rules
applicable to the e-
wallet from a list of options provided by the kiosk's 189 display. In
addition, there may be
instances, e.g., in a savings context, wherein certain laws, regulations,
and/or policies require that
an e-wallet be limited to a given number of selected transactions per period
(e.g., transfers from a
savings-dedicated e-wallet).
[00178] In an embodiment, the rules can be created and configured by the user
as a flowchart
For selection of value tokens based on purchase information. For example, a
rule may comprise
selection of a closed loop-related (Store X branded) value token for a Store X
purchase of any
amount, with any remaining purchase balance to result in selection of an open
loop-related(Credit
Card Y) value token to fund such remainder. Alternatively, the user may invoke
a rule that
66
Date Recue/Date Received 2023-05-17
preseribes that open loop-related electronic value tokens should not be used
to satisfy balances for
closed loop-related electronic value token purchase, but rather debit card-
relatedelectronieval uc
tokens residing in the e-wallet should be utilized to satisfy the balance
instead. As such, a user
may access and apply multiple value tokens with the efficiency ()fusing one
authentication token
(e.g., one proxy card or smart phone). For example, the user may use an
electronic gift card, an
electronic coupon, and two electronic credit cards from an electronic wallet
or sub-wallet all in the
time it takes to use only one physical card such as a prepaid, debit, or
credit card. The user, the
retailer, issuers, vendors, merchants, advertisers, and other parties benefit
from the time saved; the
ready access to multiple sources of value (e.g., multiple accounts associated
with the various value
tokens), promotional opportunities, transaction tracking and data mining
regarding customer
purchasing behavior, promotional and advertising efficacy, real-time/point of
product selecti on or
purchase proms ei onal opportunities, etc.
[00179] In another embodiment, the rules may be established by the e-wall
etsystem provider
(e.g., a primary and/or secondary e-wallet provider or host). The e-wallet
system provider may
establish a rule concerning e-wallet allocations when there is no user
established rule available (or
if under the terms of a user's e-wallet use agreement the system's rules take
precedent in
designated transaction activities). For example, thee-wallet system may put a
rule in place that
directs the electronic value token transaction computer 150 to first apply an
c-wallet system
provider's own branded electronic value token residing in the user's e-wal let
to satisfy the
requested transaction when the transaction concerns, relates, or involves an
affiliate andior
contractually-related entity of the e-wall et system provider. As such, this
type of rule could allow
for the e-wallet system provider and its affiliates andior contractually-
related entities to maximize
revenues or other business objectives based on use of the e-wallet system and
other synergistic
effects.
[00180] In a further embodiment, the e-wallet's rules maybe fashioned to
automatically direct
electronic value token exchange activities (electronic value token exchange
will be discussed in
more Complete detail herein). For example, the e-wallet user may manage the e-
wallet (as will be
described in more detail herein, e.g., in relation to Figures 9A-D) so that
upon the occasion when
the user presents the e-wallet to satisfy a transaction at retail
establishment, e.g., Retailer Q, and the
e-wall et contains no Retailer Q branded electronic value tokens, the e-
walletwillautomatical I y,
and in real time, initiates an electronic value token exchange process wherein
the e-wallet
67
Date Recue/Date Received 2023-05-17
communicates a request for electronic value token exchange to the electronic
value token
transaction computer 150. Additionally or alternatively, the user may be
presented in real-time
with a promotion to obtain a retailer-specific value token (e.g., a real-time
offer for a store branded
value token such as a credit account). In this example, the e-wallet user may
mange the e-wallet sx)
that all electronic value tokens associated with prepaid services (giftcard-
typeelectronicvalue
tokens) are located in a designated sub-wallet and each of said electronic
value tokens may be
placediordereeltdesignated in the sub-wallet via a preferential ranking
system, e.g., most preferred
electronic value tokenor token type (e.g., #1) to least preferred electronic
value token or token type
(e.g., 422, if there are 22 types of electronic value tokens in the sub-
wallet). For example, Retailer
M branded electronic value tokens may be designated as most preferred and
Retailer L branded
electronic value tokens may be designated as least preferred. Further in the
example, the c-wallet
also has been provided with rules by the user that directs the e-wallet, in
circumstances wheixii n the
e-wall et has been presented to facilitate a transaction at a retailer in
which the e-walletcontains
none of said retailer's electronic value tokens (the e-wallet will recognize
the retailer based on
information exchanged between the e-wallet and the retailer's communication
devices at the onset
of the original transaction), such as the Retailer Q scenario described above,
the e-walletrules
direct the c-wall et to initiate an electronic value token exchange request
and to include in said
request the exchange of the least preferrcdcicctronic value token residing in
the e-wallet, i.e., the
Retailer L branded electronic value token (422) and ifnecessary preferred
electronic value token
#21, p20, etc., for a Retailer Q electronic value token in an amount
sufficient to meet the original
transaction's amount. The electronic val tie token transaction computer 150,
upon receipt of the
electronic value token exchange request, comm unicate s with an electronic
value token exchange
program 2000 (which is part of the overall electronic value token transaction
processing system
100, 1100, or 1200) to effectuate the requested electronic value token
exchange. The requested
electronic value token exchange is performed, the e-wallet receives the
requested Retailer Q
branded electronic value token, which is coincidentally used in conducting the
original transaction,
and the c-wallet surrenders (or makes unavailable for use and only available
for modification) the
Retailer L branded electronic value token to the electronic value token
transaction computer 150,
which in this case was actually valued in excess of the requested Retailer Q
branded electronic
value token. As such, the electronic value token transaction computer 150,
modifies the value of
the Retailer L branded electronic value token (either internally or via
communication with the
68
Date Recue/Date Received 2023-05-17
Retailer L branded electronic value token's issuing system) to reflect the
value reduction based on
the provided Retailer Q branded electronic value token, extracts the exchange
rate for the exchange
ofthe Retailer Q branded electronic value token for the Retailer L branded
electronic value token
(as will be discussed more fully herein), communicates the transactional
information to all
interested parties, and returns (or makes available agai n) the value-modified
Retailer L branded
value token to the user's e-wallet. In an alternate embodiment, the e-wallef
selectronievalue
token exchange rules could have provided that the e-wallet query the
electronic value token
transaction computer 150 regarding the best available exchange rate for the
electronic value tokens
residing in the e-wallet and make the exchange based on the best exchange rate
rather than the
ranking Elbe electronic value tokens.
[001811 Figure 5A illustrates an exemplary electronic value token transaction
processing system
100 in accordance with one embodiment. As shown, the electronic value token
transaction
processing system comprises: (a) at least one point of sale device 111; (b)
anelectronic wallet
processing system, e.g., electronic value token transaction computer 150; (c)
a datastore 180
containing an electronic wallet unit 199 storing electronic value tokens,
e.g., 804, 827, 828, and
829, such as account numbers, electronic wallet account information, value
added award
conditions (herein "value added award" i s synonymous with "value added
bonus," "value added
bonus award," "value added award bonus," and "value differentiation"), and
other information
related to adding, redeeming, and managing the electronic value tokens; (d) at
least one individual
issuers' authorization system 160, and (e) any other unit included in the
system by the electronic
value token transaction computer administrator 151. In one embodiment, the
electronic value
token transaction computer 150 comprises a value added determination unit 153,
a point-of-sale
("MS") interface 152, a message modification unit 154, a reconciliation unit
155, an issuer system
interface 156, an authorization unit 157, and a sorting unit 198. In an
embodiment, the electronic
value token transaction computer 150 (or a unit thereof such as sorting unit
189) further comprises
token exchange interface, which may communicate with electronic value token
exchange program
2000. The POS Interface 152 provides a means for the electronic value token
transaction computer
150 to communicate with the point of sale device 111 via, for example, the
Internet, a Public
Switched Telephone Network ("PSTN"), or an i ridependent dedicated network.
Likewise, the
electronic value token transaction computer 150 may communicate via issuer
system interface 156
with the issuers' authorization system 160 via, for example, the Internet, a
Public Switched
69
Date Recue/Date Received 2023-05-17
Telephone Network (PSTN), or an i iide pc tide n t dedicated network.
Communications 106, 107
between the POS interface 152 and the point of sale device 111 and
communications 109, 110
between the issuer system interface 156 and the issuers' authorization systems
160 may be
e ncryptedforadded se c urity and/or may utilize a virtual private network
("VPN"). The sorting
unit 198 may sort the communications into various types for routing in various
ways. For
example, the sorting unit 198 may identify and sort electronic wallet and/or
sub-wallet requests
(e.g., upon receipt of authorization information with a transaction request,
the sorting unit 198 can
route the requested transaction to a specific electronic wallet maintained by
the system and/or to a
specific sub-wallet or sub-walletsasscxiiated with an electronic wallet),
balance inquiry requests,
registration requests, activation requests, redemption requests, and
management requests for
routing to the various units of Figure 5A. The electronic value token
transaction computer 150 or
sorting unit 198 may also generate messages based on the requests for similar
routing.
1001821 As can be seen in Figure 5A, at the point of sale device 111
(typically located at a
vendor and/or redeeming merchant or retailer, but alternatively located at a
kiosk 189 or at a user's
home or office where a personal computer is configured to act as a point of
sale, for example
during an on-line transaction), the authentication token is interpreted by a
point of sale
interpretation unit 101 (e.g., a card re a der). The point of sale
interpretation unit 101 can comprise
a human, a bar code scanner, magnetic strip reader, optical character
recognition device, biometric
device, numerical keyboard (e.g., for entering a token identification number)
or other device
configured to interrogate, interpret, capture, or input the data encoded in or
on the authentication
token.
1001831 About contemporaneously with (or, alternatively, prior or subsequent
to) the
interpretation of the authentication token, a reque st for an electronic
wallet transaction by a point
of sale transaction unit 104 is made. The point of sale transaction unit 104
can comprise a human,
an electronic input device, a register or terminal, a computer processing unit
("CPU"), a personal
computer, a personal digital assistant (e.g., smart phone) or other means of
requesting or messaging
interpreted by the point of sale interpretation unit 101 and/or point of sale
processing unit 105. In
some embodiments, the actions performed by the point of sale interpretation
unit 101 and the point
of sale transaction unit 104 may be performed by one unit capable of
performing both actions that
would be performed by the individual units, for example a point of sale
register/terminal or a
personal computer during an on-line, web-based transaction.
Date Recue/Date Received 2023-05-17
1001841 The point of sale interpretation unit 101 and the point of sale
transaction unit 104
communicate with the point of sale processing unit 105. The point of sale
processing unit 105 can
comprise a CPU or other type of processing device accepted for use in the
industry. The point of
sale interpretation unit 101 communicates authentication information 102 to
the point of sale
processing unit 105. The point of sale transaction unit 104 communicates the
request 103 for an
electronic wallet transaction to the point of sale processing unit 105. The
point of sale processing
unit 105 may combine this information to communicate with the electronic value
token transaction
computer 150 (e.g., transmits a message requesting an electronic wallet
transaction along with the
associated transaction and/or authentication data). In an embodiment, the
point of sale processing
unit 105 stores and/or receives from the electronic value token transaction
computer 150 (or a sub-
administrator or unit associated therewith, such as a sub-wallet
administrator) a transaction format
associated with the POS retailer andlor associated with a given transaction
type and/or value token,
and such transaction format may be used to format the transaction request or
message, to prompt
the user for further information, or for other data gathering or
transmit/receive features at the point
of sale. For example, a user making a purchase at a retailer operates a card
reader. A card reader
may a display with an input device and a bareode reader or magnetic strip
scanner. The card
reader may be touch sensitive and may have various buttons used for input.
Following the card
reader prompts, the user sees the options "Debit," "Credit," and "E-Wallet."
The user selects"E-
Wallet." The user then sees the options "Purchase," "Add Token" and "Delete
Token." The user
selects "Purchase." Following additional prompts (which in an embodiment
relate to a transaction
format specific to the particular retailer of the point of sale), the user
enters a PIN number. In some
embodiments, the actions performed by the point of sale interpretation unit
101, the point of sale
transaction unit 104, and the point of sale processing unit 105 may all be pet
formed by olio unit
(e.g., an integrated PS device such as a computerized register) capable of
perfonning all the
actions that would be performed by the individual units.
190185] The point of sale processing unit 105 is connectable to the
electronic. value token
transaction computer 150 via a suitable network, such as the Internet, the
public switched
telephone network (PS TN), or an independent dedicated network. Each point of
sale processing
unit 105 has an associated identifier (e.g., a terminal identifier or serial
number) that may be
transmitted to the electronic value token transaction computer 150 during the
oourse of connecting
the point of sale processing unit 105 to the electronic value token
transaction computer 150. Each
71
Date Recue/Date Received 2023-05-17
point of sale processing unit 105 may include multiple point of sale
transaction units corresponding
to individual terminals each with its own terminal identification, for example
present within a
given store location.
[00186] As depicted in Figure 5A, the electronic value token transaction
computer 150 is
configured to: (a) form a secure connection with the retailer/merchant and/or
vendor (e.g.. via the
point of sale device Ill, customer intentet access, or kiosk 189), the
issuers' authorization systems
160, and any other entities 190 authorized to access the electronic value
token transaction
computer 150 by the electronic value token transaction computer administrator
151; (b) to
communicate with issuers' authorization systems 160 to request and receive
redemption or
addition of value tokens into electronic wallets; (c) to communicate with
issuers' authorization
systems 160 to redeem all or a portion of the electronic value tokens
associated with the electronic
wallet; (d) generate and maintain a transaction log 170 of all activities
performed; (e) generate and
mai ntai n an error log 175 of all activities unsuccessfully completed and
reasons therefore; (0
communicate to the retailer/merchant and/or vendor (e.g., via the POS unit
111) the redemption or
addition of value tokens into electronic wallets and any information
concomitant with the
redemption or addition of value tokens into electronic wallets; and (g)
communicate to the
retailer/merchant and/or vendor (e.g., via the POS unit 111) any reasons why
transactions cannot
not be completed.
[00187] The electronic value token transaction computer 150 may comprise a
singular
processing unit (e.g., a centralized server), a plurality of processing units
(e.g., a distributed
computing system with various units distributed and in communication with each
other), or
combinations thereof, with concomi tant storage capabilities, each capable of
or designated for:
accessing the datastore 180; creating a transaction log170; creating and
maintaining an error log
175; communicating with retailers/merchants and/or vendors, e.g., at a point
of sale, including via
the internet for on-line transactions; communicating with the individual
issuers' authorization
systems 160; processing individual value token and electronic wallet requests;
processing
redemption requests; processing value added functions to add additional cash
value or add an
electronic redemption coupon for a specific product(s) or service(s);
processing redemption request
for electronic redemption coupons for specific product( s) and/or service(s);
and communicating
with other systems 190 capable of and authoriz ed to communicate with the
electronic value token
transaction computer 150.
72
Date Recue/Date Received 2023-05-17
[00188] Datastore 1.80 maintains records of accounts associated with each
electronic wallet
indicating: (a) whether each individual value token has been added or
redeemed, (b) whether the
authentication token has been registered, (c) records and details of each
individual redemption
request, (d) the amount remaining on the electronic value tokens, (e) rules
required for redeeming
the electronic value tokens, (f) identity of the issuers of the electronic
value tokens, (f) value added
bonus awards, (g) niles for redeeming value added bonus awards, and (h) any
combination thereof.
The datastore may al so maintain records of rules required for granting a
value added bonus award
to an electronic wallet or value token.
[00189] Datastore 180 also maintains records associated with each electronic
wallet and/or sub-
wallet indicating: (a) timing of, and other infon-nation related to,
registration activities; (b) timing
of, and other information related to, management activities; (c) timing of,
and other information
related to, transaction activities; (e) rules applicable; (1) identity of the
issuers electronic value
tokens therein; (f) identity of sub-wal lets associated therewith; (h) any
other records requested by
issuers, merchants, vendors, advertisers, users, or other interested parties;
and (i) any combination
thereof. While a single datastore 180 is shown, it should be understood that a
plurality of
datastores may be employed, and relevant data divided among the datastores in
any suitable
manner to meet the various processes and objectives described herein. Also,
the various data may
be associated with one or more datastores closely coupled to and/or located in
proximity to one or
more sub-units, sub-processors, third party processors, and the like
associated with the electronic
value token transaction computer 150, and such datastores preferably have data
used by such sub-
units, sub-processors, and third party processors.
[00190J The electronic value token transaction computer 150 is also configured
to generate and
maintain a transaction log 170 of all activity involving the electronic value
token transaction
c,omputer 150. The transaction log may comprise a detailed summary of
transaction types such as:
(a) requested value token additions; (b) requested value token sales; (e)
requested value token
redemptions, (d) requested value token exchanges; (e) the monetary amount
ascribed to value
token additions; (1) the monetary amount ascribed to value token redemptions;
(g) the monetary
value ascribed to value token exchanges; (h) the value added amounts,
products, or services
additions; (i) the value added amounts, products, or services redemptions; (j)
the time the
electronic value tokens were added; (k) the time the electronic value tokens
were redeemed; (1) the
transaction or communication performed with the issuer for adding value tobtu%
(n) the
73
Date Recue/Date Received 2023-05-17
transaction or communication performed withthe issuer for redeeming value
tokens; (n) the PIN
communicated to the vendor in response to a request to add a value token
requiring thc input of a
PIN for use; (o) e-wallet registration; (p) e-wallet set-up activities; (q) e-
wallettransaction
activities; (r) e-wallet savings activities; (s) e-wallet management
activities; (t) any other
information the electronic value token transaction computer administrator 151
directs the
electronic value token transaction computer 150 to maintain as a log entry;
and (u) any
combination thereof.
[00191] The information contained in the transaction log 170 may be used for
data mining
purposes, e.g., to generate reconciliation reports, settlement reports,
payment reports, audit reports,
e-wallet registration reports, e-wallet management reports, e-wallet usage
reports, e-wallet savings
reports, electronic value token purchase reports, electronic value token
redemption reports,
electronic value token exchange reports, electronic value token sale reports,
or other forms of
information aggregation for the benefit of, use by, or for provision to, the
electronic value token
transaction administrator 151, the datastore administrator 181, vendors,
issuers, issuers'
authorization systems 160, redeeming merchants, or other interested parties.
For example, the
transaction log 170 contains information about each transaction performed by
electronic value
token transaction computer 150 (and any sub-components thereof) and may be
utilized by the
reconciliation unit 155 when reconciling accounts belonging to various
vendors, merchants, issuers
and the electronic value token transaction processing system administrator(s).
Additional data
mining considerations that may be recorded, analyzed, and/or provided
interested parties (e.g.,
vendors, merchants, issuers, advertisers, etc.) include data about: (i) the
purchase habits of e-wallet
users; (ii) electronic value token purchases, sales, redemptions, and
exchanges; (iii), special offer
and/or value added activities; (iv) loyalty-related activities; and (v)
savings-related activities, all of
which can be used for marketing, inventory, and other purposes.
[00192] Oversight and maintenance of the electronic value token transaction
computer is
performed by the electronic value token transaction computer administrator
151. Although not
required, in an alternative embodiment, the electronic value token transaction
computer
administrator 151 may also function as the da.tastoir administrator 181. The
electronic value token
transaction computer 150 is configured to generate and maintain an error log
of all transactions that
were not completed and reasons therefore. In some embodiments, the error log
is administered by
the electronic value token transaction computer administrator 151.
74
Date Recue/Date Received 2023-05-17
[00193] The electronic value token transaction computer 150 is also configured
to communicate
with other entities 190 authorized to access the electronic value token
transaction processing
system and specifically auth ori zed to access the electronic value token
transacti on computer 150.
These other entities may comprise third party payment management systems,
third party audit
system s,issuer affiliated entities, vendor affiliated entities, redeeming
merchants or redeeming
merchant affil iated entities, financial institutions such as banks, credit
card agencies, or credit
unions, or any other entity provided access by the electronic value token
transac tion computer
administrator 151 or other entity having authority to grant access.
1001941 The transaction request from the point of sale device 111, or other
access point,
associated with an e-wallet may contain one or more of the following pieces of
information: (a)
authentication information. (b) point of sale terminal identification, (c)
amount to be credited or
debited, (d)the time of the request, (e) the date ofthe request, (f)
identification of the issuer, (g)
identification of the vendor, (h) location of vendor, (i) identification of
the product(s) and/or
service(s) being purchased, (,j) an activation or deactivation request, (k) a
wallet management
function such as addition of a value token, deletion of a value token,
exchange of a value token,
changing management or processing rules associated with one or more value
tokens, partitioning a
wallet into sub-wallets or vice-versa, etc., (1) and any combination thereof'.
however, the
information contained within the request is not limited to the enumerated list
but may comprise
other items in addition to the items enumerated or in place of the items
enumerated above.
[00195] Upon receipt of the electronic wallet transaction request from the
point of sale, and
identification and sorting as such by the sorting unit 198, the electronic
value token transaction
computer 150 accesses the electronic wallet unit of datastore 180. The
electronic value token
transaction computer 150 processes the information contained in the datastore
180 and
communicates 109, 110 with the individual issuers' authorization systems 160
to effectuate
management of the electronic value tokens and corresponding accounts. The
message
modification unit may adjust the messages and requests so that multiple units,
sub-
oomponentsi processors, orthird-party administrators can recognize and
correctly interpret the
messages. For example, afte r the electronic value token transaction computer
150 determines the
individual issuers' authorization systems 160 associated with the request, the
message modification
unit 154 accesses the database 180 to determine the appropriate transaction
messaging formats for
each individual issuers' authorization systems 160 and then formats the
subsequent
Date Recue/Date Received 2023-05-17
communications to said individual issuers' authorization systems 160 using the
individual issuers'
authorization systems 160 sped i fied/pre fe rred tran sae ti on format and
vocabulary. The electronic
value token transac tion com pute r' s 150 comm uni catio n with the
individual issuers' authorization
systems 160 may occur simultaneously. or independently. The electronic value
token transaction
computer 150 is connectable to the individual issuers' authorization systems
as via a suitable
network, such as the PSTN, the Internet, or an independent dedicated network.
The electronic
value token transaction computer 150 is configured to send and/or receive corn
munication 110
from the issuers' authorization systems 160 concerning the status of the
electronic value tokens.
[00196] The reconciliation unit 155 reconciles the accounts of vari ous
issuers, selling vendors,
and/or redeeming merchants, to credit and debit appropriate merchants,
vendors, the electronic
value token transaction processing system administrator, and issuers with the
value of various
tra nsactionsto re flee t which entiti es received value from which other
entities. For example, if a
vendor A sells a value token issued by issuer 13 for a specified amount and
receives payment from
a user who adds the electronic value token to the user's electronic wallet,
the selling vendor
receives a percentage (e.g., retains a percentage) of the purchase amount
and/or a predetermined
amount the electronic value token system administrator receives a percentage
of the purchase
amount and/or predetermined amount for processing the transaction, and the
issuer receives the
remainder. If a value token issued by issuer Y is redeemed at merchant X to
purchase items, then
the amount redeemed is debited to the issuer Y and credited to the merchant X,
sometimes minus a
transaction fee collected by the issuer and/or a transaction or processing fee
collected by the
electronic value token transaction processing system administrator.
[00197] Authorization unit 157 is utilized when the electronic value token
transaction computer
150 is also the authorizing system such that the electronic value token
transaction computer 150
authorizes electronic wallet requests rather than transmitting the request to
the issuers'
authorization systems 160 for authorization. The authorization unit 157 may
perform the same
and/or different functions as described for authorization systems 160 and vice-
versa.
[00198] The authorization unit 157 will validate the formatti ng of the c-
wallettransaotion
request (e.g., primary or sub-wallet) received from the POS processor 105 (or
other transaction
originating device/component/processor). In other words, the authorization
unit 157 will check the
data fields in the request to confirm that the fields are populated with data
and that the data is in the
correct format (e.g., length, alphanumeric format). If the request is
improperly formatted, the
76
Date Recue/Date Received 2023-05-17
authorization unit 157 will reject the request, or in some embodiments may
retrieve the proper
format (e.g., from a format database) and modify the transaction request to
comply with the proper
format. The authorization unit 157 also performs various validation checks on
the request. The
authorization unit 157 verifies card-related transaction information based on
an analysis of several
criteria, such as: 1) determining that the UPC code for the product is present
in the datastore 180
(or other database such as an issuer's database) for the electronic value
token transaction
processing system 100; 2) determining that the value amount of the requested
transaction
corresponds to the customer's payment for the subject transaction request,
e.g., whether the UPC
information identifies the card as a $25.00 card and that the corresponding
transaction request
includes a $25.00 payment by the customer; 3) determining that the UPC
information identifies the
card as being a type of card available for processing by the requesting
merchant; and 4)
determining that the Rank Identification Number ("BIN") of the card (i.e., the
first six digits of the
can's identification number), which identifies the card issuer, corresponds to
the UPC information
identifying the card issuer.
1001991 The authorization unit 157 may also verify transactions based on other
criteria such as
transaction velocity (number/amount per unit time). For example, if a card
processor is concerned
that multiple void transactions are indicative offraudulent activity, the card
processor could ask
that the electronic value token transaction processing system 100 monitor the
number of void
transactions reque sled and reject transactions from termi nal s that exceed a
pre-selected amount of
void transactions per unit time. Lastly, the authorization unit 157 may be
configured to reject
transaction requests in the event that the information received by the
authorization unit 157 is
[00200] If the request is properly formatted and is validated as described
above, the electronic
value token transaction computer 150 may transmit details of transactions to
the issuers'
authorization systems rather than authorization requests. Also, in some
embodiments, the issuer,
time authorizing system (e.g., authorization unit 157), and the transaction
computer are part of the
same entity and, in such an embodiment, there would be no issuers'
authorization systems 160 or
the issuers' authorization systems 160 would be under common control with the
other units of the
electronic value token transaction computer 150 (for example, a commonly owned
and operated
computing system, that may be centralized (e.g., part of a centralized data
center) and/or
distributed within a commonly owned or controlled system or network).
Furthermore, it should be
77
Date Recue/Date Received 2023-05-17
noted that although units associated with the electronic value token
transaction computer 150 (e.g.,
units 152-157) are depicted as various units within a single data processing
system for illustration
and conceptual purposes, one or more of units 152-157 could be implemented on
separate
computers systems, or servers in a distributed data processing environment.
[00201] An exe mpl ary process utilized by an electronic value token
transaction computer 150
for facilitating a purchase using an electronic wallet in accordance with a
primary e-wallet
transaction processing embodiment is depicted in Figure 7A. Such an embodiment
may be
exemplified by the c-wall et transaction processing request being both
initially received by and
subsequently performed by the electronic value token transaction processing
system 100. The
actions depicted can be performed in the order shown or in a different order,
and two or more of
the actions can be performed in parallel.
[00202] In block 302, the electronic value token transactioncomputer 150
receives a request or
multiple requests from a point of sale terminal. In at least one embodiment
the requests may
comprise an electronic wallet transaction request, a balance inquiry request,
a registration request,
an activation request, or a redemption request, a wallet management request,
and contains one or
more of the following: (a) identity of the terminal, (b) authentication
information, (c) the amount of
the purchase, (d) the identity of the electronic value token issuer, (e) the
identity of the vendor, (I)
the identity of the location, (g) the time of the request, (h) the date of the
request, (i) information
expressly identifying the request as an e-wallettranseiction request (e.g.,
transaction type data); (j)
information identifying a primarye-wallet, sub-wallet(s), or a combination
thereof; (k) any other
transaction and/or authentication data described herein., and (1) any
combination thereof. The
request at block 302 may comprise other information, requests or functions,
for example of the
types described herein, in addition to or in place of the above enumerated
items. In at least one
embodiment, the authentication information is based on an authentication token
selected from the
group consisting of proxy card and cellular phone. Using the identity of the
electronic value token
issuer, transactions maybe correctly formatted for communication with the
electronic value token
issuer.
[00203] Using infonnation contained within the electronic wallet transaction
received from the
point of sale device ill and/or from information obtained from datastore 180,
in block 304, the
electronic value token transaction computer 150 de term i nes whether the
request is an electronics
wallet request containing valid authentication information and whether the
request is for
78
Date Recue/Date Received 2023-05-17
redemption of a value token(s), addition of a value token(s), deletion of a
value token(s), or
management of the electronic wallet. The electronic wallet request may
comprise a bank
identification number ("BIN") located on the proxy card as part of the
authentication information.
The sorting urn t may decode the BIN number or otherwise verify that the
request is an electronic
wallet request.
(00204j Usinginformationcontai tied vi thin the electronic wallet transaction
received from the
point of sale device 111 and/or from information obtained from datastore 180,
in block 324, the
electronic value tokentransaction computer 150 ide nti fi e s/de te r mi ne s
t he primary e-wallet, sub-
wallet( s), and/or locations of said e-wallet or sub-
wallet(s)indicateclinecemarytoeffectuate the
received e-wal let transaction request. If the authorization information
received indicates the
requestede-wall et transaction involves a primaty e-wallet, sub-wallet,
orcombi nations thereof
maintained by the electronic value token transaction computer 150, the
electronic value token
transaction computer 150 may (i) apply its own logic to the request, (ii)
apply rules stored in a
pri mary wallet (e.g., rules established by the electronic value to
kentransactionprocessi ng system
administrator, the primary e-wallet user, or a combination thereof); (iii)
apply rules stored in a sub-
wallet (e.g., rules established by the electronic value token transaction
processing system
administrator, the sub-wallet user, or a combination thereof) (iv) apply rules
received with the
request from the point of sale 111 (e.g., contemporaneous rules submitted with
the request by the
user of the primary e-wallet/ sub-wallet); (v) or any combination thereof.
1002051 For example, an embodiment may include the electronic value token
transaction
computer 150 determi ning that the entire request is related to value tokens
contained in a primary
c-wallet. Upon receipt of the request, the electronic value token transaction
computer 150 will
query its authorization unit 157 (as described more fully herein), its
datastore 180, the E-wallet
unit 199, and any other necessary unit to determine whether the primary e-
walletcomprisesvalue
tokens capable of meeting the subject request (e.g., whether the primary e-
wallet co nta.i ns v al ue
tokens associated with vendors, merchants, and/or issuers related to the
requested transaction).
Such determination may be performed by comparing electronic value token
identifications, user
IDs, requested transaction types. The electronic value token transaction
computer 150 will
subsequently evaluate the manner in which the electronic value tokens
available in the primary e-
wal let corresponding to the request will be applied under the primary e-
wallet' s nil es andior rules
79
Date Recue/Date Received 2023-05-17
received with the request, and perform or refuse to perform the requested
transaction and/or
transactions.
[00206] Another embodiment may include the electronic value token transaction
computer 150
determining that the entire request is related to value tokens contained in a
sub-wallet. Upon
receipt of the request, the electronic value token transaction computer 150
will query its
authorization unit 157 (as described more fully herein), its datastore 180,
the E-Wallet unit 199,
and any other necessary unitto determine whether the sub-wallet comprises
value tokens c apabl
of meeting the subject request (e.g., whether the sub-wallet contains value
tokens as sociate d with
vendors, merchants, and/or issuers related to the requested transact on). Such
determinationmay
be performed by comparing electronic value token identifications, user IDs,
requested transaction
types. The electronic value token transaction computer 150 will subsequently
evaluate the manner
in whie lithe electronic value tokens available in the sub-wallet
corresponding to the request will be
applied under the sub-wallet's rules and/or rules received with the request
and perform or refuse to
perform the requested transaction and/or transactions.
po2071 In
another example, an embodiment may include the electronic value token
transaction computer 150 determining that a portion ofthe entire transaction
request is related to
electronic value tokens residing in a primary e-wallet while a portion of the
transaction request is
related to electronic value tokens residing in a sub-wallet(s). Such
determination may be made by
evaluating the requested transaction type, the electronic value token
identification, or any other
methods fordetennining transaction allocation. The electronic value token
transactioncomputer
150 will evaluate the manner in which the electronic value tokens available in
the primary e-wallet
corresponding to the request will be applied under the primary e-wallet's
rules (as those rule may
affect payment methods to be employed which are located in the primary e-
wallet), the electronic
value token transaction computer 150 will evaluate the manner in which the
electronic value
tokens available in any applicable sub-wallet corresponding to the request
will be applied under
such sub-wallet's rules and/or rules received with the request, and perform or
refuse to perform the
requested transaction and/or transactions.
[00208] In an exemplary embodiment, at block 324, the electronic value token
transaction
computer 150 may identify, in response to a received transaction request, one
or more value tokens
in a primary e-wallet and one or more electronic value tokens in a sub-wallet
that, when used
together, will cover the entirety of the requested e-wallettransaction.
Moreover, one of the
Date Recue/Date Received 2023-05-17
electronic; value tokens located in the primary e-wallet or sub-wallet may be
an electronic
representation of a loyalty card and another electronic value token located in
either the same or
different location of said loyalty card value token may be an electronic
representation of a retailer's
gift card. In such an example, the electronic value token transaction computer
150 can effectuate
the coincidental use of the "loyalty card" token and the "retailer's gift
card" token, regardless of
the tokcns' locations in the primaty e-wallet and/or sub-wallet(s) to allow
for an enhanced user
benefit as opposed to not coincidentally applying the value of the "retailer's
gift card" token and
the "loyalty card" token for the transaction, e.g., a 5% increase in the value
of the "retailer's gi ft
card" token or loyalty point bonus applied to the "loyalty card" token for the
use of the "retailer's
gift card" token.
1002091 A value token may be associated with a closed loop account or open
loop account. A
closed loop account typically expires after the funds in the account have been
depleted, e.g. a gi ft
card account. An open loop account does not typically expire. Rather, there is
typically an
ongoing obligation for various entities to credit and debit the account, e.g.
a branded credit card
account or debit card account such as Visa or Mastercard. Closed loop accounts
are often
associated directly with retailers while open loop accounts are often
associated with financial
institutions (e.g., Chase or Citi issued Visa). In at least one embodiment,
the electronic value
tokens comprise closed loop account numbers and open loop account numbers. The
closed loop
account numbers are associated with retailers able to debit or credit closed
loop accounts
associated with the closed loop account number. The open loop account numbers
are associated
with financial institutions able to debit or credit open loop accounts
associated with the open loop
account numbers. The electronic value token may have an expiration date or
specified dates of use
that are different from any other value tokens. Furthermore, the electronic
value tokens may
identify specific merchants, locations, and/or products with which the
electronic value tokens may
be utilized.
100210] If the
request is for value token addition, then in block 306, the electronic wallet
is
created (if not already created) and the electronic value token is added to
the electronic wallet. The
following Tables include c le tne nts, parameters, and information included
inc -wal le ttransaction
communi eationsand used by the electronic, value token transaction processing
system 100 to
facilitate andeffectuate e-wallet transactions.
81
Date Recue/Date Received 2023-05-17
1002111 Table IA illustrates request parameters requested to create a wallet
in at least one
embodiment. Table 1B illustrates response parameters requested to create a
wallet in at least one
embodiment.
Table IA
Request Parameters
Element Data Suggested Description
Type
Length
accounttype String 200 Account Type
loadamt decimal N/A Amount to be loaded
into the wallet
account
loadruntourrency string 3 Denomination Type.
txn-uniqueidenti tier string 12 Unique transaction
id.
Table 1I1
ResponseParameters
Element Data Type Description
accountid string Unique identifier for a account
acc,ounttype string Type of the aceount
currency string Denomination Type.
balance decimal Balance available in the account
uniqueidenfifier string (numeric) The unique identifier identifies a
transaction.
code string The Status of the requested transaction.
description string The Status description of the requested
transaction.
100212] The electronic value token transaction computer 150 preferably
allocates memory for
the electronic wallet and value token( s) and associates the account number
with the electronic
wallet and/or authentication information stored in the electronic wallet unit
199 by storing the
pieces of information in a data structure on the datastore 180. Table 2
illustrates the parameters for
a gift card value token in at least one embodiment.
82
Date Recue/Date Received 2023-05-17
Table2
Element and Description Data Type Suggested
Length
statusinfo.status.code String 7
statusinfo.status.description String 500
cardsetailerid Integer 11
String
card.retailer.rnme String 100
card,number StritE _______ ci
card.sec uritycocie String fk)
card.mpiryclate Integer String 6
card.activationdate Date String 20
card.initialbalance Decimal String 10
card.currentbalance Decimal String 10
card.currentbalanceasof Date String 20
card.customerservice. String 20
phone
card.customerservice. String 256
website
card. currency String 3
[002131 Table 3 illustrates more detailed parameters for a gift card
electronic value token in an
alternative embodiment, including the de signation of associated wall et(s)
and/or sub-wa] let(s).
Table 3
Element and Description Data Type Suggested
Length
cardietsiler.id Integer 11
String
cardietailetname String 100
carcl.number String , 50
cardsectiritycode String 50
card.expiryclate Integer Strim 6
cardregisteredto String 10
card.activationdate I)ate String 20
cardinitialbalance Decimal 10
Stritg
card. islookedwinitialbalame Stint 1
card.ctmentbalance -Decimal 10
String
cantislookedupcurientbalame String 1
cardoustamerservice. String 20
83
Date Recue/Date Received 2023-05-17
Element and Deseripdon Data Type Suggested
Length
_phone
card.customeraervice. String 256
website
caretnotes String 500
cardnickname String 100
canicurreney String
card, LIM r. firstname suing
card MC r. I astname String 50
card.user.aidress.linel String 50
eard.usw. address.line2 String 50
card useraddress.city String 50
card.use Laddress. state String 50
_ _
card.useraddress.zip String , 5
card.user. phone .number String 10
card.useremail.address String 128
¨
card.addifionalinfol String 300
eard.additionalinfo2 String 300
eard.additionalinfo3 String 300
walletid Integer String 10
Colkctioncifolders
walletfolder.11 d IntegerString 10
wallet.folder.l.name String 100
Integer String 10
wallet.fdder.Znarrn String 100
f... More folders]
[00214] The request, however, may be modified for other reasons unrelated to
the add token
decision and forwarded to the appropriate one of the issuers' authorization
systems 160 as part of
the reconciliation process, for example the request could conee rn redemption,
deletion, reloading
value, added value, balance inquiry, or a combination thereof, each of which
would be
communicated to the issuers' authorization systems 160 for reconciliation.
[00215] Table 4 illustrates formatting for authentication communication.
Table4
EleanentandDesaiption Data Type
client_ref id String
signature String
timestarnp String(in the format
yyMMddHHnunssSSSz )
84
Date Recue/Date Received 2023-05-17
ElementandDeseription Data Type
nonce String
encryption_type String
useitoken String
uuid
user ________________________________ LStrhs ________________
channel String
1002161 Each request is authenticated using the signature, a user is
authenticated with
uscrname/password or open id, the session isvalidated using the user token.
Aclient may send
client ref id, timestamp, nonce, encryption_type, channel, user_ip, signature,
optionally usertolcen
with each request to be able to validate each message.
100217) Table 5 illustrates the parameters used to retrieve a user's wallet.
Table 5
Element Data Type Descripdnn
accountid string IJnique identifier for a account
accourrttype string Type of the account
currency string Denomination Type.
balance dee i mal I-3a la nce available in the account
code string The Status of the requested
transaction.
description string The Status description of the requested
transact on.
[002181 Table 6A illustrates the request parameters used to redeem value from
a token in the
wallet.
Table6A
Request Parameters
Element Data Suggested Description
TYPe Length
aecountid String 100 Unique identifier for the account
mdzunt decimal N/A Amount to redeem from the account
redaniteurrency string 3 Amount Type.
bm-uniqueidentifier string 12 Unique transaction id.
Date Reeue/Date Received 2023-05-17
Element Data Suggested Description
Type Length
txn- bool N/A 0, if it is not a reversal of any
istimeoutreversal transaction type 1, if it is a reversal
transaction.
100219] Table 613 illustrates the response parameters used to redeem value
from a token in the
wallet.
Table6B
Re sponseParameters
Suggested
Element Data Type Description
Length
accountid string 100 Unique identifier for a account
accioinittype string 50 Type of the account.
Latency= string 3 Denomination Type.
balance decimal N/A Balance available in the account
uniquoidentifier string 12 Unique identifier for the
tran.sacti on.
code string 7 The Status of the requested
transaction,
description string 500 The Status description of the
requested
___________________________________________ transaction.
[00220] Table 7A illustrates the terpost parameters used ID load a value token
into the wallet.
Table7A
Request Parameters
Data ggested
Element Su Description
Type Length
-
accountid string 100 Unique identifier for a account
amount decimal N/A Amount to load on the account
amountourioney string 3 Amount Type.
bm- bool N/A 0, if it is not a reversal of any
istitneoutreversal transaction type 1, if it is a
reversal
transaction.
_
txn-uniqueidentifier string 12 Unique transaction id.
86
Date Recue/Date Received 2023-05-17
1002211 Table 7B illustrates the response parameters used to load a value
token into the wallet.
Table 713
Re sponseParameters
Element Data Type Suggested Description
Length
_
accountid string 100 Unique identifier for a account
accounttype string 50 Type of the account.
balance decimal NIA Balance available in the account
uniqueidentifier string (numeric 12 Unique identifier for the
transaction.
values [0-9] only)
code string 7 The Status of the requested
transaction.
description string 500 1. he Status description of the
requested transaction.
currency string 3 Denomination Type.
[00222] If thc request is for value token redemption, then in block 308, the
electronic value
token transaction computer 150 accesses the electronic wallet previously
determined to be
associated with the authentication information and examines the rules
associated with the
electronic wallet. In at least one embodiment, examining the rules comprises
examining priorities
of value tokens configurable by the user. For example, the user may prefer to
use any closed loop
value tokens corresponding to the retailer originating the purchase request.
If none is found or if
the token will not cover the purchase. then the user may prefer to use an open
loop value token for
the remainder. As a result of these preferences, the closed loop value tokens
may all have higher
priority than the open loop value tokens. Among the open loop value tokens,
one may have
priority over another. For example, the user prefers to pay for any remainder
with a credit card
rather than a debit card. In at least one embodiment, the user may configure
these rules via the
Internet or mobile application and save the priorities as default preferences.
In an alternative
embodiment, the user selects the electronic value tokens to apply to the
electronic wallet request at
the POS device, for example at a vendor or retailer location such as a check-
out lane, customer
service counter, Or kiosk. As such, selecting the electronic value tokens
comprises selecting value
tokens with the highest priority that, when used together, will cover the
purchase amount. As can
be seen in the example, one purchase transaction has been split into two
redemptions without
87
Date Recue/Date Received 2023-05-17
compromising efficiency of the purchase. Similarly, one or more electronic
wallet transactions can
be split into two or more transactions without compromising efficiency. In an
embodiment, at least
one of the electronic value tokens is associated with a closed loop prepaid
account (e.g., an
electronic prepaid, gift, or stored value card)and the rules associated with a
primary wallet invoke
a sub-transaction processed by a third party administrator associated with a
sub-wallet.
[00223] In at least one embodiment, examining the rules comprises examining
percentages of
the electronic wallet request to which different value tokens should be
applied and wherein
applying the electronic value tokens comprises applying the electronic value
tokens to the
electronic wallet request in according to the percentages. In block 310, the
electronic value token
transaction computer 150 then selects, based on the rules, value tokens in the
electronic wallet that,
when used together, will cover the electronic wallet request. For example, the
user may configure
the rules such that each purchase is split evenly between two credit cards. As
such, selecting the
electronic value tokens comprises selecting two open loop tokens between which
to split the
purchase amount. Similar to the above example, efficiency is preserved because
where a single
authorization token (e.g., only the proxy card or a mobile device) was used at
the point of sale, not
the two credit cards corresponding to the electronic value tokens. Other rules
can be implemented,
and the rules can be used in various combinations and permutations with each
other. The
electronic value token transacti on proc e ssing system can also implement "
if-the n" rules based on
the information transmitted in the electronic wallet request. For example, a
purchase at a gas
station can result in a gas credit card value token selection, and the like.
In such am embodiment,
the electronic value token computer 150 may query the rule(s) 802, 817, 818,
and 819 of the
suN ecte-wallet 10 and/or sub-wallets 807 (e.g., for credit card-type
electronic value tokens), 808
(e.g., for debit card-typeelectronic value tokens), and 809 (e.g., for stored
value-typozlectronic
value tokens) and determine, based on transaction request information which
includes a transaction
type, e.g., purchase at a gas station, that rule(s) established for the
subject e-wallet 10 and/or sub-
wallets 807, 808, and 809 require that the transaction type request be first
satisfied with a first
electronic value token type, e.g. a gas card-related electronic value token
829, and upon the
occasion that the subject e-wallet 10 and/or sub-wallet(s) 807, 808, and 809
do not comprise a
sufficient amount of the first value token type to satisfy the entire
transaction request, the electronic
value token computer 150 may satisfy the remainder of the transaction request
with a second
electronic value token type, e.g., a debit card-related electronic value token
828.
88
Date Recue/Date Received 2023-05-17
[0022.11 The electronic value token transaction computer 150 also applies the
electronic value
tokens to the electronic wallet request. In applying the electronic value
tokens to the request, the
electronic value token transaction computer 150 can generate and send debit
andcredit messages
to be performed on the accounts administered by the retailers and financial
institutions using the
appropriate account numbers, or the electronic value token transaction
computer 150 can creditor
debit the accounts directly if the electronic value token transaction computer
has such
administrative authority.
[00225] In at least one embodiment, the electronic value token transaction
computer 150
modifies the request (e.g., applies a required format) and forwards the
modified request to the
appropriate one of the issuers' authorization systems 160, which receives the
modified request and
acts upon same, for example authorizing andior processing the request to
redeem the electronic
value token and updating a datastore accordingly. The authorization system 160
is not at the same
location from where the electronic wallet request was received in at least one
embodiment. For
example, if the electronic wallet request was received from a retail store,
the authorization system
may be owned and operated by the retailer, but will not be at the retail
store. Rather, the
authorization system may be located at a data center for example. As such,
neither the retail store
nor the retailer in general need be aware of some or all the contents of the
wallet. In at least one
embodiment, the retail store is unaware of even the presence of the electronic
wallet, as it merely
recognizes that some transaction authorizing action has been communicated to
its point of sale
(e.g., swipe of a proxy card, digital personal assistant interaction with
point of sale device, entry of
a PIN at a keypad at point of sale, or other authorizing activity). In other
words, access and use of
the e-wall et at the point of sale is seamless and does not require any
special or custom actions in
order to process the transaction in comparison to traditional physical tender.
The issuers'
authorization systems 160 sends a response mevinge back to the electronic
value token transaction
computer 150. In an alternative embodiment where the electronic value token
transaction
computer 150 performs the functions of the issuers' authorization systems 160,
the method may
proceed directly from block 306 or 31010 block 314.
1002261 The electronic value token transaction computer 150 receives the
confirmation message
from the appropriate one of the issuers' authorization systems 160 in block
312. At block 314, the
electronic value token transaction computer 150 updateselectronie wallet in
the electronic wallet
unit 199 and datastore 180 to reflect that the electronic wallet is activated
and to reflect any debit,
89
Date Recue/Date Received 2023-05-17
credit, addition, or deletion to/of the electronic value token(s). Figures 9A-
13 illustrate a series of
user interface screens and prompts in at least one embodiment. For example,
the user may see the
illustrated prompts when managing the user's electronic wallet via a computer
connected to the
Internet, and/or kiosk 189.
1002271 A transaction log 170 may he updated by the electronic value token
transaction
computer 150 in block 316 to record the details about the transaction. The
details recorded in the
transaction log may include (a) the type, time and date of the transaction,
(b) whether the electronic
wallet was activated, (c) the reason electronic wallet was not activated if
the request was denied,
(d) the credit, debit, addition, or deletion to/of the electronic value
token(s), (e) a change in rules
associated with the electronic value token(s), (f) the identity ofthe vendor,
(g) the identity of the
issuer, (h)the location of the vendor, (i) the identity of the terminal adding
the electronic value
token, (I) the identity of the entity granting the electronic value token, and
(k) any combination
thereof. The transaction log may include other information (e.g., transaction
and/or authentication
data) in addition to or in place of the items enumerated above.
[00228] The electronic value token transaction computer 150, in block 318,
then forwards the
confirmation message to the point of sale device 111. The electronic value
token transaction
computer 150, prior to forwarding the confirmation message to the point of
sale device 111, may
modify the confirmation message, for example us necessary to include
information that may be
printed on a receipt for the customer and/or presented on a display to the
store clerk operating the
point of sale device 111. At block 320, the electronic value token transaction
computer 150
reconciles the accounts of the various vendors, merchants, issuers, the
electronic value token
transaction processing system administrator, and other entities involved with
issuing, selling,
redeeming, and marketing the electronic value tokens to debit and credit
appropriate accounts and,
in some embodiments, initiates funds transfers between appropriate bank
accounts belonging to the
various entities. Alternatively, reconciliation of accounts may be performed
periodically (e.g.,
daily, weekly, monthly, etc.) rather than after each transaction. In such an
embodiment, the
information from the transaction log 170 may be utilized to reconcile the
various entities involved
with the sale or redemption of various value tokens thus requiring fewer funds
transfers to be
initiated. In an embodiment, i nformati on in transaction log 170 is used to
match transactions and
the like. For example, grouping all transactions from a given location or a
given merchant, or
grouping transaction types (e.g., credit, debit, etc.). In various
embodiments, the sequence of
Date Recue/Date Received 2023-05-17
events depicted in may be varied, and thus may be carried out in any desired
order, sequentially or
simultaneously.
l002291 Figure 5B illustrates an exemplary electronic value token transaction
processing system
1100 in accordance with an embodiment wherein the electronic wallet processing
system
comprises the electronic value token transaction computer 150, functioning as
an electronic sub
-
wallet transaction processor, integrated with a primary electronic wallet
transaction processor such
as depicted by E-Wallet Aggregator System 1000. E-Wallet Aggregator System
1000 may be
further understood to have the same functionaliti es, capabilities, database
access, networked
connections, and operative components as the herein described electronic value
token transaction
computer 150, and in some embodiments an electronic value token transaction
computer 150 and
its associated components (e.g., el ectronic value token transaction
processing system 100) may
serve as, or be substituted for, the E-Wallet Aggregator System 1000. In an
embodiment, the E-
Wallet Aggregator System 1000 may be controlled, maintained, operated, owned,
and/or otherwise
managed by a common entity or entities which control, maintain, operate, own,
and/or otherwise
manage the electronic value token transaction computer 150. i.e., the
primaryelectroniewallet
transaction processor and the electronic sub-wallet transaction processor
share a common
controller, maintainer, operator, owner, and/or manager. In an embodiment, the
E-Wallet
Aggregator System 1000 may be controlled, maintained, operated, owned, and/or
otherwise
managed by an entity or entities that are separate, distinct, and/or unrelated
to the entity and/or
entities which control, maintain, operate, own, and/or otherwise manage the
electronic value token
transaction computer 150, i.e., the primary electronic transaction processor
and the electronic sub-
wallet transaction processor do not share a common controller, maintainer,
operator, owner, and/or
manager. As shown, when functioning in an electronic sub-wallet transaction
processing capacity,
the electronic value token transaction proc es sing system 1100c ompri se s:
(a) an el ectroni c value
token transaction computer 150; (b) an E-Wallet Aggregator System interface
1052; (e) a datastore
180 containing an electronic wallet unit 199 storing electronic value tokens,
e.g., 804, 827, 828,
and 829, suoh as account numbers, electronic wallet account information, value
added award
conditions (here in "value added award" is synonymous with "value added
bonus," "value added
bonus award,- -value added award bonus," and "value di ffe re nti ati on"),
and other information
related to adding, redeeming, and managing the electronic value tokens, as
described in detail
herein; (d) at least one individual issuers' authorization system 160, and (e)
any other unit included
91
Date Recue/Date Received 2023-05-17
in the system by the electronic value token transaction computer administrator
151. In one
embodiment, the electronic value token transaction computer 150 comprises a
value added
determination unit 153, an E-Wal le t Aggre gator System interface 1052, a
message modification
unit 154, a reconciliation unit 155, an issuer system interface 156, an
authorization unit 157, and a
sorting unit 198. The E-Wall et Aggregator System interface 1052 provides a
means for the
electronic value token transaction computer 150 to communicate with the E-Wal
letAggre gator
System 1000 via, for example, the Internet, a Public Switched Telephone
Network ("PSTN"), or an
independent dedicated network. Likewise, the electronic value token
transaction computer 150
may communicate via issuer system interface 156 with the issuers'
authorization system 160 via,
for example, the Internet, a Public Switched Telephone Network (PSTN), or an
independent
dedicated network. Communications 116, 117 between the E-
WalletAggregatorSysteminterface
1052 and the E-Wallet Aggregator System 1000 and communications 109, 110
between the issuer
system interface 156 and the issuers' authorization systems 160 may be
encrypted for added
security and/or may utilize avirtual private network ("VPN"). The sorting unit
198 may sort the
communications into various types for routing in various ways. Forexample, the
sorting unit 198
may identify and sort sub-wallet requests (e.g., upon receipt of authoriz ati
on information with a
transaction request, the sorting unit 198 can route the requested transaction
to a specific electronic
sub-wallet maintained by the system and/or to a specific section or sections
maintained within the
electronic sub-wallet), balance inquiry requests, registration requests,
activation requests,
redemption requests, and management requests for routing to the various units
of Figure 5B. The
electronic value token transaction computer 150 or sorting unit 198 may also
generate messages
Erased on the requests for similar routing.
[002301 As can be seen in Figure 5B, at the point of sale device 111
(typically located at a
vendor and/or redeeming merchant or retailer. but alternatively located at a
kiosk 189 or at a user's
home or office where a personal computer is configured to act as a point of
sale, for example
during an on-line transaction), the authentication token is interpreted by a
point of sale
interpretation unit 101 (e.g., a card reader). The point of sale
interpretation unit 101 can comprise
a human, a bar code scanner, magnetic strip reader, optical character
recognition device, biometrie
device, numerical keyboard (e.g., for entering a token identification number)
or other device
configured to interrogate, interpret, capture, or input the data encoded in or
on the authentication
token.
92
Date Recue/Date Received 2023-05-17
[00231] About contemporaneously with (or, alternatively, prior or subsequent
to) the
interpretation of the authentication token, a request for an electronic wallet
transaction by a point
of sale transaction unit 104 is made. The point of sale transaction unit 104
can comprise a human,
an electronic input device, a register or terminal, a computer processing unit
("CPU"), a personal
computer, a personal digital assistant, smart phone, or other means of
requesting or inessaging
interpreted by the point of sale interpretation unit 101 and/or point of sale
processing unit 105. In
some embodiments, the actions performed by the point of sale interpretation
unit 101 and the point
of sale transaction unit 104 may be performed by one unit capable of
performing both actions that
would be performed by the individual units, for example a point of sale
register/terminal or a
personal c(xnputer during an on-I i ne, web-based transaction.
[002321 The point of sale interpretation unit 101 and the point of sale
transaction unit 104
communicate with the point of sale processing unit 105. The point of sale
processing unit 105 can
comprise a CPU or other type of processing device accepted for use in the
industry. The point of
sale interpretation unit 101 communicates authentication information 102 to
the point of sale
processing unit 105. The point of sale transaction unit 104 communicates the
request 103 for an
electronic wallet transaction to the point of sale processing unit 105. The
point of sale processing
unit 105 may combine this information to communicate with the E-
WalletAggregatorSystem
1000 (e.g., transmits a message requesting an electronic wallet transaction
along with the
associated transaction and/or authentication data). In an embodiment, the
point of sale processing
unit 105 stores and/or receives from the F-Wallet Aggregator System 1000 (or a
sub-administrator
or unit associated therewith, such as a sub-wallet administrator, e.g.,
electronic value token
transactioncomputer 150)a transaction format associated with the POS retailer
and/or associ tiled
with a given transaction type and/or value token, and such transaction format
may be used to
format the transaction request or message, to prompt the user for further
information, or for other
data gathering or transmit/receive features at the point of sale. For example,
a user making a
purchase at a retailer operates a card reader. A card reader may a display
with an input device and
a baroode reader or magnetic strip scanner. The card reader may be touch
sensitive and may have
various buttons used for input. Following the card reader prompts, the user
sees the options
-Debit," "Credit," and"E-Wallet." The user selects "F-Wallet." The user then
secs the options
"Purchase," "Add Token," and "Delete Token." The user selects "Purchase."
Following
additional prompts (which in an embodiment relate to atransaction format
specific to the particular
93
Date Recue/Date Received 2023-05-17
=
retailer of the point of sale), the user enters a PIN number. In some
embodiments, the actions
performed by the point of sale interpretation unit 101, the point of sale
transaction unit 104, and the
point of sale processing unit 105 may all be performed by one unit (e.g., an
integrated POS device
such as a computerized register) capable of performing all the actions that
would be performed by
the individual units.
[00233] The point of sale processing unit 105 is connectable to the E-Wallet
Aggregator System
1000 via a sui table network, such as the Internet, the public switched
telephone network (PSIN ),
or an independent dedicated network. Each point of sale processing unit 105
has an associated
identifier (e.g., a terminal identifier or serial number) that may be
transmitted to the E-Wallet
Aggregator System 1000 during the course ofeonnecting the point of sale
processing unit 105 to
the E-Wallet Aggregator System 1000. Each point of sale processing unit 105
may include
multiple point of sale transaction units corresponding to individual terminals
each with its own
terminal identification, for example present within a given store location.
[002341 As depicted in Figure 53, the E-Wall et Aggregator System 1000 is
configured to: (a)
form a secure connection with the retailerimerchant and/or vendor (e.g., via
the point of sale device
111), the electronic value token transaction computer 150, and the issuers'
authorization systems
160; (b) to communicate with issuers' authorization systems 160 to request and
receive redemption
or addition of val uc tokens into electronic wallets; (c) to communicate with
issuers' authorization
systems 160 to redeem all or a portion of the electronic value tokens
associated with the electronic
(d) communicate with the electronic value token transaction computer 150 to
facilitate
transactions concerning value tokens residing in an electronic sub-wallet
maintained by the
electronic value token transaction processing system 1100;(e) communicate to
the
retailer/merchant and/or vendor (e.g., via the POS unit 111) the redemption or
addition of value
tokens into electronic wallets and any information concomitant with the
redemption or addition of
value tokens into electronic wallets and/or sub-wallets; and (0 communicate to
the
retailer/merchant and/or vendor (e.g., via the POS unit 111) any reasons why
transactions cannot
not be completed.
1002351 The electronic value token transaction computer 150 may comprise a
singular
processing unit (e.g., a centralized server), a plurality of processing units
(e.g., a distributed
computing system with various units distributed and in communication with each
other), or
combinations thereof, with concomitant storage capabilities, each capable of
or designated for:
94
Date Recue/Date Received 2023-05-17
accessing the datastore 180; creating a transaction log 170; creating and
maintaining an error log
175; communicating with the E-WatIct Aggregator System 1000; communicating
with the
individual issuers authorization systems 160; processing individual value
token and electronic:
wallet. requests; processing redemption requests, processing value added
functions to add
additional cash value or add an electronic redemption coupon for a specific
product(s) or
service(s), processing redemption request for electronic redemption coupons
for specific product(s)
and/or service(s), and communicating with other systems 190 capable of and
authorized to
communicate with the electronic value token transaction computer 150.
1.00236,1 13atastore 180 maintains records of accounts associated with each
electronic sub-wallet
indicating: (a) whether each individual value token has been added or
redeemed, (b) whether an
authentication token for an individual value token has been registered, (c)
records and details of
each individual redemption request, (d) the amount remaining onthe electronic
value tokens, (c)
rules required for redeeming the electronic value tokens, (f) identity of the
issuers of the electronic
value tokens, (g) value added bonus awards, (h) rules for redeeming value
added bonus awards,
and (i) any combination thereof. The datastore may also maintain records of
rules required for
granting a value added bonus award to an electronic wallet or value token.
[00237] Datastore 180 also maintains records associated with each electronic
wallet and/or sub-
wallet indicating: (a) timing of, and other information related to,
registration activities; (b) timing
of, and other information related to, management activities; (c) timing of,
and other information
related to, transaction activities; (d) rules applicable; (e) identity of the
issuers electronic value
tokens therein; (1) identity of sub-wallets a ssoc i ated therewith; (g) any
other records requested by
issuers, merchants, vendors, advertisers, users, or other interested parties;
and (h) any combination
thereof While a single datastore 180 is shown, it should be understood that a
plurality of
datastores may be employed, and relevant data divided among the datastores in
any suitable
manner to meet the various processes and objectives described herein. Also,
the various data may
be associated with one or more datastores closely coupled to and/or located in
proximity to one or
more sub-units, sub-processors, third party processors, and the like
associated with the electronic
value token transaction computer 150, and such datastores preferably have data
used by such sub-
units, sub-processors, and third party processors.
P02381 The electronic value token transaction computer 150 is also configured
to generate arid
maintain a transaction log 170 of all activity involving the electronic value
token transaction
Date Recue/Date Received 2023-05-17
computer 150. The transaction log may comprise a detailed summary of
transaction types such as:
(a)requested value token additions; (b) requested value token sales; (c)
requested value token
redemptions; (d) requested value token exchanges; (e) the monetary amount
ascribed to value
token additions; (f) the monetary amount ascribed to value token redemptions;
(g) the monetary
value ascribed to value token exchanges; (h) the value added amounts,
products, or services
additions; (i) the value added amounts, products, or services redemptions; (j)
the time the
electronic value tokens were added; (k) the time the electronic value tokens
were redeemed; (1) the
transaction or communication performed with the issuer for adding value
tokens; (m) the
transaction or communication performed with the issuer for redeeming value
tokens; (n) the PIN
communicated to the vendor in response to a request to add a value token
requiring the input of a
PIN for use; (o) e-wallet registration; (p) e-wallet set-up activities; (q) e-
wallettransaction
activities; (r) e-wallet savings activities; (s) e-wallet management
activities; (t) any other
information the electronic value token transaction computer administrator 151
directs the
electronic value token transaction computer 150 to maintain as a log entry;
and (u) any
combination thereof
[00239] The information contained in the transaction log 170 may be used for
data mining
purposes, e.g., to generate reconciliation reports, settlement reports,
payment reports, audit reports,
e-wallet registration reports, c-wallet management reports, e-wallet usage
reports, c-wallet savings
reports, electronic value token purchase reports, electronic value token
redemption reports,
electronic value token exchange reports, electronic value token sale reports,
or other forms of
information aggregation for the benefit of, use by, or for provision to, the
electronic value token
transaction administrator 151, the datastore administrator 181, the E-
WalletAggregatorSystern
1000 (e.g., for communication to vendors or other purposes), vendors, issuers,
issuers'
authorization systems 160, redeeming merchants, orother interested parties.
For example, the
transaction log 170 contains information about each transaction performed by
electronic value
token transaction computer 150 (and any sub-components thereof) and may be
utilized by the
reconciliation unit 155 when reconciling accounts belonging to various E-
WalletAggregator
System 1000 associated vendors, merchants, issuers, as well as vendors,
merchants, and issuers not
associated with the E-Wall et Aggregator System 1000, and also the electronic
value token
transaction processing system administrator 151. Additional data mining
considerations that may
be recorded, analyzed, and/or provided interested parties (e.g., vendors,
merchants, issuers,
96
Date Recue/Date Received 2023-05-17
advertisers, etc.) include data about: (i) the purchase habits of e-
walletusers; (ii) electronic value
token purchases, sales, redemptions, and exchanges; (iii), special offer
and/or value added
activiti es;(iv)loyalty-related activities; and (v) savi ngs-re latcd
activitie s, all of which can be used
for marketing, inventory, and other purposes.
[00240] Oversight and maintenance of the electronic value token transaction
computer is
performed by the electronic value token transaction computer administrator
151. Although not
required, in an alternative embodiment, the electronic value token transaction
computer
administrator 151 may also function as the datastore administrator 181. The
electronic value token
transaction computer 150 is configured to generate and maintain an error log
of all transactions that
were not completed and reasons therefore. In some embodiments, the error log
is administered by
the electronic value token transaction computer administrator 151.
[00241] The electronic value token transaction computer 150 is also configured
to communicate
with other entities 190 authorized to access the electronic value token
transaction processing
system and specifically authorized to access the electronic value token
transaction computer 150.
These other entities may comprise E-Wallet Aggregator System 1000, third party
payment
managementsystems, third party audit systems, issuer affiliated entities,
vendor affiliated entities,
redeeming merchants or redeeming merchant affiliated entities, financial
institutions such as bank,
credit card agencies, or credit unions, or any other entity provided access by
the electronic value
token transaction computer administrator 151 or other entity having authority
to grant access.
[00242] In an embodiment, the transaction request from the E-WalletAggregator
Syste in 1000
may contain one or more of the following pieces of information: (a)
authentication information, (b)
point of sale terminal identification, (c) amount to be credited or debited,
(d) the time of the
request (e) the date of the request, (1) identification of the issuer, ( g)
identification of the vendor,
(b) loo ati on of vendor, (i) identification of the product( s) andror
service(s) being purchased, (j) an
activation or deactivation request, (k) a wallet management function such as
addition of a value
token, deletion of a value token, exchange of a value token, changing
management or processing
rules associated with one or more value tokens, partitioning a wallet into sub-
wallets or vice-versa,
etc., (1) and any combination thereof. However, the information contained
within the request is not
limited to the enumerated list but may comprise other items in addition to the
items enumerated or
in place of the items enumerated above.
97
Date Recue/Date Received 2023-05-17
1002431 Upon receipt of the electronic wallet transaction request from the E-
WalletAggregator
System 1000, and identification and sorting as such by the sorting unit 198,
the electronic value
tot.= transaction computer 150 accesses the electronic wallet unit of
datastore 180. The electronic
value token transaction computer 150 processes the information contained in
the datastore 180 and
communicates 109, 110 with the individual issuers' authorization systems 160
to effectuate
management of the electronic value tokens and corresponding accounts. The
message
modification unit may adjust the messages and requests so that multiple units,
sub-
components/processors, or third party administrators can recognize and
correctly intei p t the
messages. For example, after the electronic value token transaction computer
150 determines the
individual issuers' authorization systems 160 associated with the request, the
message modification
unit 154 accesses the database 180 to determine the appropriate transaction
messaging formats for
each individual issuers' authorization systems 160 and then formats the
subsequent
communications to said individual issuers' authorization systems 160 using the
individual issuers'
authorization systems 160 speci fled/pre fe rred tran sacti on format a nd voc
abulary. The electronic
value token transaction computer 150 can also provide the appropriate
messaging formatting
information, e.g., a template, to the E-Wall et Aggregator System 1000 to fac
itate that system' s
processing of information related to the request. The electronic value token
transaction computer's
150 communication with the individual issuers' authorization systems 160 may
occur
simultaneously or independently. The electronic value token transaction
computer 150 is
connectable to the individual issuers' authorization systems as via a suitable
network, such as the
PSTN, the Internet, or an independent dedicated network. The electronic value
token transaction
computer 150 is configured to send and/or receive communication 110 from the
issuers'
authorization systems 160 concerning the status of the electronic value
tokens.
[00244J The reconciliation unit 155 reconciles the accounts of various
issuers, selling vendors,
and/or redeeming merchants, to credit and debit appropriate merchants,
vendors, the electronic
value token transaction processing system administrator, and issuers with the
value of various
transactions to reflect which entities received value from which other
entities. For example, if a
vendor A sells a value token issued by issuer B for a specified amount and
receives payment from
a user who adds the electronic value token to the user's electronic wallet,
the selling vendor
receives a percentage (e.g., retains a percentage)of the purchase amount
andiora predetermined
amount, the E-Wallet Aggregator System 1000 and/or the electronic value token
system
98
Date Recue/Date Received 2023-05-17
administrator receives a percentage of the purchase amount and/or
predetermined amount for
processing the transaction, and the issuer receives the remainder. If a value
token issued by issuer
Y is redeemed at merchant X to purchase items, then the amount redeemed is
debited to the issuer
Y and credited to the merchant X, sometimes minus a transaction fee collected
by the issuer and/or
a transaction or processing fee collected by the electronic value token
transaction processing
system administrator.
1002451 Authorization unit 157 is utilized when the electronic value token
transaction computer
150 is also the authorizing system such that the electronic value token
transaction computer 150
authorizes electronic sub-wallet requests rather than transmitting the request
to the issuers'
authorization systems 160 for authorization. The authorization unit] 57 may
perform the same
and/or di trerent functions as described fo r authorizati on systcms 160 and
vice-versa.
1002461 The authorization unit 157 will validate the formatting ofthe wallet
(e.g., primary or
sub-wallet)transaction request received from the F-Wallet Aggregator System
1000. In other
words, the authorization unit 157 will check the data fields in the request to
confirm that the fields
are populated with data and that the data is in the correct format (c.a.,
length, alphanumeric
format). If the request is improperly formatted, the authorization unit 157
will reject the request, or
in some embodiments may retrieve the proper format (e.g., from a format
database) and modify the
transaction request to comply with the proper format. The authorization unit
157 also performs
various validation cheeks on the transaction request. The authorization unit
157 verifies card-
related transaction information based on an analysis of several criteria, such
as: 1 )determining
that the UPC code for the product is present in the ciatastore 180 (or other
datastore such as an
issuer's database) for the electronic value token transaction processing
system 1100; 2)
determining that the value amount of the requested transaction corresponds to
the customer's
payment for the subject transaction request, e.g., whether the UPC information
identifies the card
as a $25.00 card and that the corresponding transaction request includes a
$25.00 payment by the
customer; 3) determining that the UPC information identifies the card as being
a type of card
available for processing by the requesting merchant; and 4) determining that
the Bank
Identification Number ("BIN") of the card (i.e., the first six digits of the
card's identification
number), which identifies the card issuer, corresponds to the UPC information
identifying the card
issuer.
99
Date Recue/Date Received 2023-05-17
[002471 The authorization unit 157 may also verify transactions based on other
criteria such as
transaction velocity (numberfamount per unit time). For example, if a card
processor is concerned
that multi pie void transactions are indicative of fraudulent activity, the
card processor could ask
that the electronic value token transaction processing system 1100 monitor the
number of void
transactions requested and reject transactions from termi nals that exceed a
pre-selected amount of
void transactions per unit time. Lastly, the authorization unit 157 may be
configured to reject
transaction requests in the event that the information received by the
authorization unit 157 is
[00248J I f the request is properly formatted and is validated as descri bed
above, the electronic
value token transaction computer 150 may transmit details of transactions to
the issuers'
authorization systems rather than authorization requests. Also, in some
embodiments, the issuer,
the authorizing system 9e.g., authorization unit 157), and the transaction
computer are part of the
same entity and, in such an embodiment, there would be no issuers'
authorization systems 160 or
the issuers' authorization systems 160 would be under common control with the
other units of the
electronic value token transaction computer 150 (for example, a commonly owned
and operated
computing system, that may be centralized (e.g., part of a centralized data
center) and/or
distributed within a commonly owned or controlled system or network).
Furthermore, it should be
noted that although units associated with the electronic value token
transaction computer 150 (e.g.,
units 152-157) are depicted as various units within a single data processing
system for ill ustrati on
and conceptual purposes, one or more of units 152-157 could be implemented on
separate
computers, systems, or svrvers in a distributed data processing environment.
[002491 An exemplary process utilized by an electronic value token transaction
computer 150
for facilitating a purchase using an electronic wallet in accordance with an e-
wallettransaction
mpri sing an el ectroni c sub-wallet maintained by a third party electronic
value token transaction
computer which maintains the sub-wallet as part of a relationship with a
primary e-walletsystem
provider, e.g., the E-Wallet Aggregator System 1000, embodiment is depicted in
Figure 7B. Such
an embodiment may be exempl i lied by the e-wallettransac ti on processing
request being initially
received by the E¨Wallet Aggregator System 1000 and performed in part by the
eke tronicvalue
token computer 150. The actions depicted can be performed in the order shown
or in a different
order, and two or more of the actions can be performed in parallel.
100
Date Recue/Date Received 2023-05-17
1002501 In block 301, the E-Wallet Aggregator System 1000 receives a request
or multiple
requests from the point of sale 111. In at least one embodiment the requests
may comprise an
electronic wallet transaction request, a balance inquiry request, a
registration request, an activation
request, or a redemption request, a wallet management request, and contains
one or more of the
following: (a) identity of the terminal, (b) authentication information, (c)
the amount of the
purchase, (d) the identity of the electronic value token issuer, (e) the
identity of the vendor, (f) the
identity of the location, (g) the time of the request, ( h) the date of the
request, (i) information
expressly i dentifyi ng the request as an e-wallet transaction request (e.g.,
transaction type data); (j)
information identifying a primarye-wallet, sub-wallet(s), or a combination
thereof; (k) any other
transaction and/or authentication data described herein; and (I) any
combination thereof. The
request at block 301 may comprise other information, requests or functions,
for example of the
types described herein, in addition to or in place o f the above enumerated
items. In at least one
embodiment, the authentication information is based on an authentication token
selected from the
group consisting of proxy card and cellular phone.
[002511 Continuing with the process of block 301, the E-WalletAggregator
System 1000 may
determine that a portion of the requested e-wallet transaction may be
processed via the E-Wallet
Aggregator System 1000 while another portion of the requested e-
wallettransactionimplicatesa
sub-wallet which is maintained by a third party administrator, e.g.,
electronic value token
transaction computer 150. I f the electronic wallet transaction request
information received by the
E-Wallet Aggregator System 1000 indicates that the transaction request will
require/involve a sub-
wallet maintained by a third party administrator's system to fully effectuate
a response to the
transaction request, and the rules applicable to the associated primary e-wall
et maintained by the
E- Wallet Aggregator System 1000 so dictate, the E-Wallet Aggregator System
1000 processes the
original request, generates a new request, generates a sub-request, or
modifies the original request,
to send to the sub-wallet which is maintained in association with the primary
electronic wallet, e.g.,
the primary electronic wallet sends the original request, the new request, the
sub-request, or the
modified on ginal request to the electronic value token transaction computer
150, which maintains
the indicated sub-wallet. In processing the original request, generating the
new request, generating
the sub-request, or modifying the original request to send to the sub-wallet,
the E-Wallet
Aggregator System 1000 may (i) apply its own logic to the e-wallet transaction
request; (ii) apply
rules stored in the primary wallet (e.g., rules formulated by the primary e-
wallet provider, the
101
Date Recue/Date Received 2023-05-17
primary e-wallet user, or a combination thereof); (iii) apply rules received
with the transaction
request from the point of sale 111 (e.g., contemporaneous rules submitted with
the request by the
user of the primary electronic wallet and/or electronic sub-wallet); (iv) or
any combination thereof
[002521 In block 303, the electronic value token transaction computer 150
receives a request or
multiple requests from the E-Wall et Aggregator System 1000. In at least one
embodiment the
requests may comprise an electronic sub-wallet request, a balance inquiry
request, a registration
request, an activation request, or a redemption request, a sub-wallet
management request, and
contains one or more of the following: (a) identity of the terminal, (b)
authentication information,
(c) thc amount of the purchase, (d) the identity of the electronic value token
issuer, (e) the identity
of the vendor, (f) the identity of the location, (g) the time of the request,
(h) the date of the request,
(i) information expressly identifying the request as an c-wallet transaction
request (e.g., transaction
type data); (j ) information identifying a primarye-wallet, sub-wallet(s), or
a combi nati on the mot',
(k) any other transaction and/or authentication data described herein; and (1)
any combination
thereof. The request at block 303 may comprise other information, requests or
functions, for
example of the types described herein, in addition to or in place of the above
enumerated items. In
at least one embodiment, the authentication information is based on an
authentication token
selected from the group consisting of proxy card and cellular phone. Using the
identity of the
proxy card and/or cellular phone, embedded transactions may be correctly
formatted for
communication with the pertinent electronic value token issuers of the subject
transaction request.
1002531 Using information received from the E-Wallet Aggregator System 1000
pursuant to the
transaction request and from information obtained from datastore 180, in block
304, the electronic
value token transaction computer 150 determines whether the request is an
electronic sub-wallet
requestcontaining valid authentication information and whether the request is
for redemption of a
value token( s), addition of a value token(s), deletion of a value token(s),
or other management of
the electronic sub-wallet. The electronic sub-wallet request may comprise a
bankidenti fie ation
number ("BIN-) as part of the authentication information. The sorting unit may
decode the BIN
number or otherwise verify that the request is an electronic sub-wallet
request concerning an
electronic value token residing in the indicated sub-wallet.
[002541] Using i nfonnation contained within the electronic wallet transaction
received from the
E-wallet Aggregator System 1000, and/or from information obtained from
datastore 180, in hl ock
324, the electronic value token transaction computer 150 identifies/determi
nesthesub-wallet(s),
102
Date Recue/Date Received 2023-05-17
and/or locations of said sub-wallet(s) indicated/necessary to effectuate the
received e-wallet
transaction request. If the authorization information received indicates the
requested e-wallet
transaction involves a sub-wallet maintained by the electronic vat ue token
transaction computer
150, the electronic value token transaction computer 150 may (i) apply its own
logic to the request;
(ii) apply rules stored in a sub-wallet (e.g., rules established by the
electronic value token
transactionprocessing system administrator, the sub-wallet user, or a
combination thereof); (iii)
apply rules stored in a sub-alb-wallet (e.g., rules established by the
electronic value token
transaction processing system administrator, the sub-sub-wallet user, or a
combination thereof)
(iv) apply rules received with the request from the point of sale 111 (e.g.,
contemporaneous rules
submitted with the request by the user of the pritnarye-wallet/sub-wallet);
(v) or any combination
thereof.
[00255] For example, an embodiment may include the electronic value token
transaction
computer 150 determining that the entire request received from the E-
WalletAggregatorSystem
1000 is related to value tokens contained in a singular sub-wallet. Upon
receipt of the request, the
electronic value token transaction computer 150 will query its authorization
unit 157 (as described
more fully herein), its datastore 180, the E-Wallet unit 199, and any other
necessary unit to
determine whether the sub-wall etcomprisesvalue tokens capable of meeting the
subject request
(e.g., whether the sub-wallet contains value tokens associated with vendors,
merchants, and/or
issuers related to the requested transaction). Such determination may be
performed by comparing
electronieval tie token identifications, user Ins, requested transaction
types. The electronic value
token transaction computer 150 will subsequently evaluate the manner in which
the electronic
value tokens available in the sub-wallet corresponding to the request svill be
applied under the sub-
wallet's rules and/or rules received with the request, and perform or refuse
to perform the
requested transaction and/or transactions.
[00256] Another emboditnent may include the electronic value token transaction
computer 150
determining that the entire request received from the E-Wal le t Aggregator
System 1000 is related
to value tokens contained in a sub-sub-wallet. Upon receipt of the request,
the electronic value
token transaction computer 150 will query its authorization unit 157 (as
described more fully
herein), its datastore 180, the E-Wallet unit 199, and any other necessary
unit to determine whether
the sub-sub-wallet comprises value tokens capable of meeting the subject
request (e.g., whether the
sub-sub-svalletcontains value tokens associated with vendors, merchants,
and/on i ssucrs related to
103
Date Recue/Date Received 2023-05-17
the requested transaction). Such determination may be performed by comparing
electronic value
token identifications, user IDs, requested transaction types. The electronic
value token transaction
computer 150 will subsequently evaluate the manner in which the electronic
value tokens available
in the sub-sub-wallet corresponding to the request will be applied under the
sub-sub-wall et's rules
and/or rules received with the request, and perform or refuse to perform the
requested transaction
and/or transactions.
[002571 In
another example, an embodiment may include the electronic value token
transaction computer 150 determining that a portion of the request received
from the E-Wallet
Aggregator System 1000 is related to electronic value tokens residing in a sub-
wallet while another
portion of the request is related to electronic value tokens residing in a sub-
sub-wallet. Such
determination may be made by evaluating the requested transaction type, the
electronic value token
identification, or at-1y other methods for determining transaction allocation.
The cleetroni c value
token transaction computer 150 will evaluate the manner in which the
electronic value tokens
available in the sub-wallet corresponding to the request will be applied under
the sub-wallet's rules
(as those rule may affect payment methods to be employed which are located in
the sub-wallet),
the electronic value token transaction computer 150 will evaluate the manner
in which the
electronic value tokens available in any applicable sub-sub-wallet
corresponding to the request will
be applied under such sub-sub-wallet's rules and/or rules received with the
request, and perform or
refuse to perform the requested transaction and/or -transactions.
[00258] In an exemplary embodiment, at block 324, the electronic value token
transaction
computer 150 may identify, in response to a received transaction request, one
or more value tokens
in a sub-wallet and one or more electronic value tokens in a sub-sub-wallet
that, when used
together, will cover the entirety of the requested e-wallettransaction.
Moreover, one of the
electronic value tokens located in the sub-walletor sub-wallet may be an
electroni c representation
of a loyalty card and another electronic value token located in either the
same or different location
of said loyalty card value token may be an electronic representation of a
retailer's gift card. In
such an example, the electronic value token transaction computer 150 can
effectuate the
coincidental use of the "loyalty card" token and the "retailer's gift card"
token, regardless of the
tokens' locations in the sub-wallet and/or sub-sub-wallet(s) to allow for an
enhanced user benefit
as opposed to not coincidentally applying the value of the "retailer's gift
card" token and the
"loyalty card" token for the transaction, e.g., a 5% increase in the value of
the "retailer's gift card"
104
Date Recue/Date Received 2023-05-17
token or loyalty point bonus applied to the "loyalty card" token for the use
of the "retailer's gift
card" token.
[00259] Anelectronic value token may be associated with a closed loop account
or open loop
account. A closed loop account typically expires after the funds in the
account have been depleted,
e.g. a gift card account. An open loop account does not typically expire.
Rather, there is may be
an ongoing obligation for various entities to credit and debit the account,
e.g. a branded credit card
account or debit card account such as Visa or Mastercard. Closed loop accounts
are often
associated directly with retailers while open loop accounts are often
associated with financial
institutions (e.g., Chase or Citi issued Visa). In at least onc embodiment,
the electronic value
tokens comprise closed loop account numbers and open loop account numbers. The
closed loop
account numbers are associated with retailers able to debit or credit closed
loop accounts
associated with the closed loop account number. The open 'cop account numbers
are associated
with financial institutions able to debit or credit open loop accounts
associated with the open loop
account numbers. The electronic value token may have an expiration date or
specified dates of use
that are different from any other value tokens. Furthermore, the electronic
value tokens may
identify specific merchants, locations, and/or product s with which the
electronic value tokens may
be utilized
1002601 If the request is for electronic value token addition, then in block
306, the electronic
sub-wallet is created (if not already created) and the electronic value token
is added to the
electronic sub-wallet. The following Tables include elements, parameters, and
information
included in e-wallet transaction communications and used by the electronic
value token transaction
computer 150 to facilitate and effectuate electronic sub-wallettransactions as
part of an
coincidental primary e-wallet transaction being processed by a pri 'nary e-
wallettransaction
processing system, e.g. the E-Wallet Aggregator System 1000.
[00261.1 Table 8A illustrates request parameters requested to create a sub-
wallet in at least one
embodiment. Table 88 illustrates response parameters requested to create a sub-
wallet in at least
one embodiment
105
Date Recue/Date Received 2023-05-17
"fable 8A
Request Paranoters
- _________________________________
Elanent Data Suggested Description
Type Length
primaryewalletauth string variable Authorization/ID of
primary e-wallet
provide i(c.g.,
Google or PayPal)
acc,ounttype String 200 Account Type
loadamt &mime] N/A Amount to bc loaded
into the wallet
account
loadamtcturenoy string 3 Denomination Type.
hat-uniqueidentifier string 12 Uniquetransaction
Table 8B
ResponsePartuneters
Element Data Type Description
accountid string Unique identifier for a account
accotuttype string Type of the account.
currency string Denomination Type.
balance decimal Balance available in the account
uniqueidenfifier string (numeric) The unique identifier identifies a
transaction.
code string The Status of the requested transaction.
description string The Status description of the requested
transaction.
1002621 The electronic value token transaction computer 150 preferably
allocates memory for
the electronic sub-wallet and value token(s) and associates the account number
with the electronic
sub-wallet and/or authentication information stored in the electronic wallet
unit 199 by storing the
pieces of infonnation in a data structure on the datastore 180. Table 9
illustrates the parameters for
a gift card value token in at least one embodiment.
106
Date Recue/Date Received 2023-05-17
Table 9
Thment Desettpdon Data Type &iggtNall
Length
statusinfo.statmeocie String 7
sIntusinfo.stattradesetiption String 500
card.retailer.id Integer 11
String
card.ratailermarne String , 100
card.nurnber String 50
eard.seeurityaode String 50
card.expirydate Integer String 6
card.activationciate Date String 20
card.initialbalance Decimal String 10
card.currentbalance Decimal String 10
card.currentbalanceasof Date String 20
card.customerservice. String 20
phone
card.customerservice. String 256
website
card.currency String 3
1002631 Table 10 illustrates more detailed parameters for a gift card
electronic value token in an
alternative embodiment, including the designation of associated sub-wallet(s)
and/or sub-sub-
wallet(s).
107
Date Recue/Date Received 2023-05-17
Table10
Element said Deserlpien Data Type Suggetned
Length
card.retailer.id Integer 11
String
card.retailer.narne String 100
caninumber String 50
____________________ card.securitycode String 50
card.expirydate IntegerString 6
card.registere,dto String 10
cardactivationdatc Date String 20
oardinitialbalance Decimal 10
String
cardislookedupinitialbalance String 1
card.currentbalance Decimal 10
String
card.isloolcedupc urrentbalance String 1
card.oustoinerservice. String 20
_______________________ Phone
cardoustomerserviee. String 256
website
eardnotes String 500
card.nickname String 100
etaxl.eurrenoy String 3
earciuser.fintnnnw String 50
eard.userlastname String 50
card.user.addresalinel String 50
card.user.address.linc2 String 50
card.user.ackiress.city String 50
eard.user.address.state String 50
card.user.address.zip String 5
card.user.phone.numbm- String 10
card.user.email.address Siring 128
canladditionalinfol Siring 300
card.additionalirifo2 String 300
card.additionalinfo3 Sting 300
_
wallet.id Intcser &rim 10
Collection offolders
wallet.folderlid Integer String 10
wallet.folder.1.name String 100
walletfolder2.id Integer String 10
walletfo1der2.name String 100
More folders]
108
Date Recue/Date Received 2023-05-17
1002641 The request, however, may be modified for other reasons unrelated
to the add token
decision and forwarded to the appropriate one of the issuers' authorization
systems 160 as part of
thereconeiliation process, for example the request couldconcemredemption,
deletion, reloading
value, added value, balance inquiry, or a combination thereof, each of which
would be
communicated to the issuers' authorization systems 160 for reconciliation.
101:12651 Table 11 illustrates formatting for authentication communication.
Table 11
ElementandDesariptim Data Type
client ref _ _id String
signature String
tirnestamp Stringinthe format
yyMIvIddHHnunssSSSz)
nonce String
encryption_type String
usertoken String
uuid String
user ip String
channel String
[002661 Each request is authenticated using the signature, a user is
authenticated with
usemamerpass word or open id, the session isvalidated using the user token.
Aclient may send
client ref id, timestamp, nonce, encryption type, channel, user ip, signature,
optionally use rtoken
with each request to be able to validate each message.
[00267] Table 12 illustrates the parameters used to retrieve a user's wallet.
Table 12
Element Data Type Description
accountid string Unique identifier for a account
accounttype string Type of the account.
currency string Denomination Type.
balance decimal Balance available inthe account
code string The Status of the requested
transaction.
description string The Status description of the requested
transaction.
109
Date Recue/Date Received 2023-05-17
1002681 Table 13A illustrates the request parameters used to redeem value from
a token in the
sub-wallet.
Table 13A
Request Parameters
Element Data Suggested Desert p a on
TYPe Length
accountid String 100 Unique identifier for the account
redamt decimal N/A Amount to redeem from the account
redaintourrenoy string 3 Amount "I ype.
txn-uniqueidentifier string 12 Unique transaction id.
txn- bool N/A 0, if it is not a reversal of any
istimeoutreversal transaction type 1, if it is a reversal
transaction.
100269,1 'fable 13B illustrates the response parameters used to redeem value
from a token in the
sub-wallet.
'Fable 13B
ResponseParameters
Element Data Type Sliggegied Description
Length
accountid string 100 Unique identifier for a account
accounttype string 50 Type of the account.
currency string 3 Denomination Type.
balance decimal N/A Balance available in the account
uniqueidentifier string 12 Unique identifier for the
transaction.
code string 7 The Status of the requested
transaction.
description string 500 The Status description of the
requested
transaction.
1002701 Table 14A illustrates the request parameters used to load a value
token into the sub-
xxallet.
110
Date Recue/Date Received 2023-05-17
Table 14A
Request Parameters
Type
Data
Element Sugge4ted Dem:ripdon
Length
accountid string 100 Unique identifier for a account
amount decimal WA Amount to load on the account
amountcurreney string 3 Amount Type.
txn- bool N/A 0, if it is not a reversal of any
istimeoutreversal transaction type 1, if it is a reversal
transaction.
txn-uniqueidentifier string 12 Unique transaction id.
1002711 Table 14B illustrates the response parameters used to load a value
token into the sub-
wallet.
Table 14B
Re sponseParameters
Element Data Type Suggested Description
Length
accountid string 100 Unique identifier for a account
aecounttype string 50 Type of the account
balance decimal Balance available in the account
uniqueidentifier string (numeric 12 Unique identifier for the
transaction.
values [0-91 only)
code string 7 The Status of the requested
transaction.
description string 500 The Status description of the
requested transaction.
currency string 3 Denomination Type.
[1:102721 Ifthe request is for electronic value token redemption, then in
block 308, the electronic
value token transaction computer 150 accesses the electronic sub-wallet
previously associated with
the authentication information and examines the rules associated with the
electronic sub-wallet. In
at least one embodiment, examining the rules comprises examining priorities of
value tokens
111
Date Recue/Date Received 2023-05-17
configurable by the user. For example, the user may prefer to use any closed
loop value tokens
corresponding to the retailer originating the purchase request. If none is
found or if the token will
not cover the purchase, then the user may prefer to use an open loop value
token for the remainder.
As a result of these preferences, the closed loop value tokens may all have
higher priority than the
open loop value tokens. Among the open loop value tokens, one may have
priority over another.
For example, the user prefers to pay for any remainder with a credit card
rather than a debit card.
In at least one embodiment, the user may configure these rules via the
Internet or mobile
application and save the priorities as default preferences. In an al ternative
embodiment, the user
selects the electronic value tokens to apply to the electronic wallet request
in at the POS device, for
example at a vendor or retailer location such as a check-out lane, customer
service counter, or
kiosk. As such, selecting the electronic value tokens comprises selecting
value tokens with the
highest priority that, when used together, will cover the purchase amount. As
can be seen in the
example, one purchase transaction has been split into two redemptions without
compromising
efficiencyofthe purchase. Similarly, one or more electronic wallet
transactions can be split into
two or more transactions without compromisingefliciency.
[002731 In at least one embodiment, examining the rules comprises examining
percentages of
the electronic sub-wallet request to which different electronic value tokens
should be applied and
wherein applying the electronic value tokens comprises applying the electronic
value tokens to the
electroniesub-wall et request in according to the percentages. In block 310,
the electronic value
token transaction computer 150 then selects, based on the rules, value tokens
in the electronic sub-
wallet that, when used together, will cover the electronic sub-wallet request
For example, the user
may configure the rules such that each purchase is split evenly between two
credit cards. As such,
selecting the electronic value tokens comprises selecting two open loop tokens
between which to
split the purchase amount. Si milarto the above example, efficiency is
preserved because where a
single authorization token (e.g., only the proxy card or a mobile device) was
used at the point of
sale, not the two credit cards corresponding to the electronic value tokens.
Other rules can be
implemented, and the rules can be used in various combinations and
permutations with each other.
The electronic value token computer 150 can also implement "if-then" rules
based on the
information transmitted in the electronic sub-wall etreq uest. For example, a
purchase at a gas
station can result in a gas credit card value token selection, and the like.
In such am embodiment,
the electronic value token computer 150 may query the rule(s) 802, 817, 818,
and 819 of the
112
Date Recue/Date Received 2023-05-17
sulj ecte-wal let 10 and/or sub-wallets 807 (e.g., for credit card-type el
ectroni e value tokens), 808
(e.g., for debit card-type electronic value tokens), and 809 (e.g., for stored
value-typcelectronic
value tokens) and determine, based on transaction request information which
includes a transaction
type, e.g., purchase at a gas station, that rule(s) established for the
subject e-wallet 10 and/or sub-
wallets 807, 808, and 809 require that the transaction type request be first
satisfied with a first
electronic value token type, e.g. a gas card-related electronic value token
829, and upon the
occasion that the subject e-wallet 10 and/or sub-wallet(s) 807, 808, and 809
do not comprise a
sufficient amount of the first value token type to satisfy the entire
transaction request, the electronic
value token computer 150 may satisfy the remainder of the transaction request
with a second
electronic value token type, e.g., a debit card-related electronic value token
828.
[002741 The electronic value token transaction computer 150 also applies the
electronic value
tokens to the electronic sub-wallet request. In applying the electronic value
toke ns to the request,
the electronic value token transaction computer 150 can generate and send
debit and credit
messages to be performed on the accounts administered by the retailers and
financial institutions
using the appropriate account numbers, or the electronic value token
transaction computer 150 can
credit or debit the accounts directly if the electronic value token
transaction computer has such
administrative authority.
1002751 In at least one embodiment. the electronic value token transaction
computer 150
modifies the request and forwards the modified request to the appropriate one
of the issuers'
authorization systems 160, which receives the modified request and acts upon
same, for example
authorizing and/or processing the request to redeem the electronic value token
and updating a
datastore accordingly. The authorization system 160 is not at the same
location from where the
electronicsub-wallet request was received in at least one embodiment. For
example, if the
electronicsub-wallet request was received from a retail store, the
authorization system may be
owned and operated by the retailer, but will not be at the retail store.
Rather, the authorization
system may be located at a data center for example. As such, neither the
retail store nor the retailer
in general need be aware of some or all the contents of the sub-wallet. In at
least one embodiment,
the retail store is unaware of even the presence of the electronic wallet, as
it merely recognizes that
some transae lion authorizing action has been communicated to its point of
sale (e.g., swipe of a
proxy card, digital personal assistant interaction withipoint of sale device,
entry of a PIN at a
keypad at point of sale, or other authorizing activity). The issuers'
authorization systems 160
113
Date Recue/Date Received 2023-05-17
sends a response message back to the electronic value token transaction
computer 150. In an
alternative embodiment where the electronic value token transaction computer
150 performs the
functions of the issuers' authorization systems 160, the method may proceed
directly from block
306 or 310 to block 314.
[00276] The electronic value token transaction computer 150 receives the
confirmation meesnee
from the appropriate one of the issuers' authorization systems 160 in block
312. At block 314, the
electronic value token transaction computer 150 updates electronic sub-wallet
in the electronic
wallet unit 199 and datastore 180 to reflect that the electronic sub-wallet is
activated and to reflect
any debit, credit, addition, or deletion to/of the electronic value token(s).
Figures 9A-D illustrate a
series of user interface screens and prompts in at least one embodiment. For
example, the user
may see the illustrated prompts when managing the user's electronic wallet via
a computer
connected to the Internet, and/or kiosk 189.
1002771 A transaction log 170 may be updated by the electronic value token
transaction
computer 150 in block 316 to record the details about the transaction. The
details recorded in the
transaction log may include (a) the time and date of the transaction, (b)
whether the electronic sub-
wallet was activated, (e) the reason electronic sub-wallet was not activated
if the request was
denied, (d) the credit, debit, addition, or deletion to/of the electronic
value token(s), (e) a change in
rules associated with the electronic value token(s), (f)the identity of the
vendor, (g) the identity of
the issuer, (h) the location of the vendor, (i) the identityofthe terminal
adding the electronic value
token, (j)the identity of the entity granting the electronic value token, (k)
identity ofthe E-Wallet
Aggregator System 1000 from which the sub-wallet request was received, (1)
communications
between the electronic value token transaction computer 150 and the E-
WalletAggregator System
1000, and (m) any combination thereof. The transaction log may include other
information in
addition to or in place of the items enumerated above.
[00278] The electronic value token transaction computer 150, in block 319,
then forwards the
sub-wallet transaction results and associated information in the form of a
confirmation message to
the E-Wallet Aggregator System 1000. The electronic value token transaction
computer 150, prior
to forwarding the confirmation message to the E-Wal let Aggregator System
1000, may modify the
confirmation message as necessary to incl ode information that may be printed
on a receipt for the
customer and/or presented on a display to the store clerk operating the point
of sale device 111. At
block 320, the electronic value token transaction computer 150 reconciles the
accounts of the
114
Date Recue/Date Received 2023-05-17
various vendors, merchants, issuers, the electronic value token transaction
processing system
administrator, and other entities involved with issuing, selling, and
marketing the electronic value
tokens involved in the sub-wallet request to debit and credit appropriate
accounts and, in some
embodiments, initiates funds transfers between appropriate bank accounts
belonging to the various
entities. Alternatively, reconciliation of accounts may be performed
periodically (e.g., daily,
weekly, monthly, etc.) rather than after each transaction. In such an
embodiment, the information
from the transaction log 170 may be utilized to reconcile the various entities
involved with the sale
or redemption of various value tokens thus requiring fevver funds transfers to
be initiated. In
various embodiments, the sequence of events depicted in may be varied, and
thus may be carried
out in any desired order, sequentially or simultaneously.
[002791 Figure SC illustrates an embodiment of the electronic value token
transaction
processing system 1200 wherein the electronic value token transaction computer
150
communicates with both the point of sale 111 and the E-Wallet Aggregator
System 1000. Thus,
the electronic value token transaction computer 150 may function as both a
primary electronic
wallet transaction processor and an electronic sub-wallet transaction
processor as descri bcd in
detail above with respect to Figures 5A and 5D.
[002801 Electronic wallet management may be carried out via a variety of user
interfaces such
as smart phone application, personal computer applications, website based
applications, point of
sale terminals, dedicated terminals at stores or other locations, such as
kiosks.
[00281] In at least one embodiment, a user can perform numerous functions via
the World Wide
Web from a computer or mobile phone such as electronic wallet management
functions (e.g.,
balance inquiry, managing loyalty and/or other bonus-type programs); exchange
of value tokens
such as (i) replace value token in c-wallet with value token not currently
present in e-wallet, (ii)
exchange between different wallets (such as placing an electronic value token
from a sub-wallet
configured to allow redemption activities into a sub-wallet configuredfor
savings activities with
limited redemption possibil i ties), and (i ) exchange with another user;
purchase electronic value
tokens to be placed in e-wallet; opt in or opt out of receiving targeted
promotional offers and
materials; and payment functions such as splitting the tender of payment
between available
electronic value tokens in the e-wallet
[00282] Regarding possible exchange possibilities, a user may exchange a value
token
associated with a retailer that the user is unli kely to frequent with a value
token associated with a
115
Date Recue/Date Received 2023-05-17
retailer that the user is likely to frequent. Similarly, users may swap, sell,
gift, or re-gift value
tokens or bundles of value tokens to each other.
1002831 Via e-wallet management functionalities, a user can: (i) determine the
amount of value
associated with each value token such as reward points, dollar amounts, etc.;
(ii) check expiration
dates on value tokens, purchase value tokens for others as gifts, and receive
notifications from
speci lie retailers; ( i ) create, regi ster, and delete thei r electronic
wall et or specific value tokens iii
their electronic wallet; (iv) request that the e-wallet provide or make
available a physical
representation of an electronic value token in the user's electronic wallet
(e.g., in an embodiment,
a print-on-demand service is provided to allow the user to print out a chit,
coupon, check, or other
physical representation of an electronic value token at a kiosk 189 or other
accessible printer); and
(v) allow the e-wallet to send the user specific value tokens, e.g., by using
a GPS service in the
user's mobile phone, or via integration with the user's SMS services.
[00284] In at least one embodiment, the user's electronic wallet is integrated
with the user's
social network services such as Facebook and Twitter. Accordingly, the user
can perform
management functions via social network platforms or receive value tokens via
social network
platforms. Full or partial information about the user's electronic wallet can
be made available to
the user's social network contacts as well,
[00285] As depicted in Figure 9A, a user may access the e-wallet system, e.g.,
electronic value
token transaction processing system 100 or E-Wal let Aggregator System 1000,
via such systems'
interactive display pages/screens (wherein the interactive di splay page s/sc
mons are accessed v ia a
user's oomputer, a user's personal digital assistant or smart phone, point of
sale terminal, kiosk
189, or other device. As Figure 9A depicts, a user may create and/or register
an e-wall et or sub-
wallet by providing certain requested infmnation and agreeing to certain terms
and conditions.
[00286] As depicted in Figure 9B, a user may manage its e-wallet by inputting
certain card
specific information into the e-wallet systems interactive display
page/screen. In an embodiment, a
user may register a gift card by inputting the gill card's brand, card number,
expiration date, CVV2
code, and card nickname and selecting the "Add Gift Card to MyWallet" button
on the semen.
1002871 As shown in Figure 9C, a user is provided many options for managing an
e-wallet and
its contents. For example, as shown, a user may review the specific details
associated with the
electronic value tokens (depicted as gift cards in Figure 9C) present in the e-
wallet and/or sub-
wallet. Moreover, the user could request that the electronic value tokens he
presented as: (i) "I ,ast
116
Date Recue/Date Received 2023-05-17
added" (as shown iii Figure 9C); (ii) as contained in various "S ulrwallets"
(sub-wallets could be
categorized or nicknamed, such as`13ining,""l-lome Improvemen" "Debit,"
"Credit "Loyalty,"
etc.); (iii) as in highest to lowest remaining value; or (iv) as ranked in
regards to preference for use.
[002881 As is also shown in Figure 9C, the user has the ability to "Add a Gift
Card," "Add
Value," "Redeem Card," and "Sell Card."
[01.12391 The "Add a Gift Card" functionality enables a user to place an
electronic value token
into the e-wallet. The "Add a Gi ft Carr!" selection provides at least two
different methods for the
user to add an electronic value token to the e-wallet. First, an electronic
value token representing a
physical card possessed by the user may be added to the e-wallet. As described
in reference to
Figure 9B, by selecti neAdda Grift Card" and the subsequent manner of such
addition, the screen
displayofFigure 9B maybe presented to the user. Accordingly, the user may add
a "gift earcl" to
the e- wallet by inputting the gift card's brand, card number, expiration
date, CVV2 code, and card
nickname and selecting the "Add Gift Card to MyWallet" button on the screen.
Alternatively, the
user may have access to a card reader (e.g., mag stripe reader and/or bar code
reader), such as a
device attached to a user's computer, personal digital assistant or smart
phone, and utilize such
device to read information from a physical card, in conjuncti on with the
user's computer, personal
digital assistant or smart phone, to enter the card's information into the e-
wallet system for
conversion into an electronic value token. Second, an electronic value token
representing a
physical card not already possessed by the user may be added to the e-wallet.
In such an
embodiment, when the user selects this option, the user may be presented a
display screen
informing the user of all the different typos and value amounts of electronic
value tokens that are
available for purchase. The availability of electronic value tokens
forpurchase can be ascribed to
the e-wallet system's (e.g., the electronic value token transaction processing
system's 100)
relationships with card issuers, merchants, vendors, and/or processors (e.g.,
aGiftCard Mall web-
based application as provided by BlacicHawk Network which provides users with
the ability to
select from a variety of different types of gift cards (and varying
denominations) and have the
cards selected delivered to the user (or to a user's identified recipient) in
either tangible form (via
mail or other courier) or delivered electronical ly (e.g., via the electronic
value token transaction
processingsystem))or may be ascribed to the e-wallet system's (e.g., the
electronic value token
transaction processing system' s 100) ability to access an electronio value
token exchange program
2000, as will be described more fully below-
117
Date Recue/Date Received 2023-05-17
[00290] The "Add Value" functionality enables a user to select an
electronic value token and
increase the value of said token. Such "reloading," "topping off," or
"recharging" of an electronic
value token may be performed as is described in International Application
Serial No.
PCT/USI 1/40055. For example, when the e- wall et user desires to
reload/recharge/top off a
telecom-related electronic value token residing in the e-wallet, the user can
select "Add Value" on
the display screen which will prompt the system to transmit the
reload/recharge/top-up request to
the electronic value token computer 150.
[00291] In a first embodiment of the reload/recharge/top-up scenario, the
electronic value token
computer 150 approves the request if the telecom-related electronic value
token is activated and
associated with a phone number. The electronic value token computer 150
determines the telecom
account associated with the phone number and adds the requested
reload/recharge/top-up amount
to the account. The electronic value token computer 150 sends a response to
the request (e.g.,
indicating that the reload/recharge/top-up amount has been added to the
associated account). The
electronic value token computer 150 transmits a reload/recharge/top-up
transaction request to the
phone number's associated telecom carrier. Upon receiving approval of the
reload/recharge/top-up
transaction request from the telecom carrier, the electronic value token
computer 150 modifies the
value of the telecom-related electronic value token to reflect the
reload/recharge/top-up amount.
The electronic value token computer 150 will cause the display accessed by the
user to reflect the
modification of the electronic value token's value, or if the
reload/recharge/top-up transaction
request was not approved, the electronic value token computer 150 will cause
the display to inform
the user as to that result. While the "Add Value" functionality has been
described in relation to
telecom-related electronic value tokens, the "Add Value" functionality is
equally applicable and
functionable for reloading/recharging/topping-up electronic value tokens
associated with debit
cards, prepaid services cards, gift cards, etc.
[00292] The "Redeem Card" functionality enables a user to select an
electronic value token and
use that token to satisfy a purchase, or other transaction. In the "Redeem
Card" scenario, if the
whole value of the electronic value token is not used in the redemption
transaction, the system will
modify/reduce the remaining value of the token and cause the display to inform
the user of the
"new" reduced value of the token, while also informing all interested parties
as to the redemption
transaction and recording and adjusting any pertinent logs accordingly.
Alternatively, when an e-
wallet is used in a point of sale-type of transaction context, rather than the
above described e-wallet
= 118
Date Recue/Date Received 2023-05-17
management context, the "Redeem Card" functionality may be automatically
invoked via
transactional information conveyed from a point of sale and thus, the can be
based on
predetermined rules.
1002931 The "Sell Card" functionality enables a user to select an electronic
value token to
monetize via offering the card for sale .1 (i) another e-wallet user, (ii)the
e-wallet (or sub-wallet)
system provider, or (iii) an electronic value token exchange program 2000 (as
more fully described
herein). In the "Sell Card" scenario, a user will inform the e-wal let system
as to the electronic
value token it desires to sell, select the forum for such sale from a list of
available forums, instruct
the system as to how the proceeds from the sale should be remitted to the e-
wallet (e.g., in the form
of e-wall et system branded electronic val tic token, value added to other
selecte d el eetroni c value
token(s), anti/or delivery of a hard/tangible form of receipt that the user
may present for tender,
(e.g., chit, coupon, check, or combination thereof)) and, if applicabl e,
instruct the system as to a
threshold value for the sale of the electronic value token that the user is
not willing to go below
e.g., set a reserve price. The system will execute the desired sale
transaction, and cause the display
to inform the user of the results of the sale of the electronic value token,
while also informing all
interested parties as to the sale transaction arid recording and adjusting any
pertinent logs
accordingly.
1002941 As is further shown in Figure 9C, a user may choose to manage "My
Rewards" which
would bring up a screen showing the user options available due to the user's
receipt of loyalty or
other types of rewards for using the e-wallet andior electronic value tokens.
The user may also
selee t"Speci al Offers" which would bring up a screen showing the user any
promotional-type
offerings available to the user via the e-wallet. The user may also select
"Exchange" which would
bring up a screen showing the user options available for electronic value
token exchange via the wallet.
[00295] [00295] In similar fashion as described in reference to the above
available e-wallet management
abilities and functionalities, a kiosk 189 may be coupled tothe electronic
value token transaction
computer 150 in at least one embodiment and function as a user's interface
with an e-wallet
transaction system to allow the user to access e-wallet management
functionalitics.
[00296] The kiosk 189 may be placed in a high-truffle area such As a shopping
mall, and may
perform any electronic wallet management function. For example, users may
create, delete, and
alter their electronic wallets or sub-wallets. Users may alsoehec k the
balances of electronic value
119
Date Recue/Date Received 2023-05-17
tokens residing in the e-wallet, add, remove, reload, recharge, print, and
exchange value tokens in
their electronic wallets or sub-wallets. The kiosk 189 may mirror transactions
available through an
electronic wallet management vvebsite in at least one embodiment, or the
functionality of an e-
wallet enabled personal digital assistant and/or smart phone. Users may employ
a print-on-demand
function with their value tokens if a particular retailer does not accept
electronic wallet
transactions. For example, a user may select a value token to print, and a
printer connected to the
kiosk 189 will print a physical representation of the selected value token,
for example a receipt
having a scannable bar code linked to the electronic value token. The physical
representation may
be a gill card with a magnetic stripe, a paper receipt or coupon with a
bareode or matrix code (e.g.,
QR code), and the like. In an embodiment, kiosk 189 may print a physical card,
for example for an
additional printing fee. The user may also provision and/or partition(e.g.,
create sub-wallets)an
electronic wallet using the kiosk 189. For example, after authentication of
the user and
identification of the electronic wallet associated with the user, the user may
insert the user's
physical stored value cards into the kiosk 189, for example a machine operated
kiosk similar to an
automatic teller machine or al to mati vely a manned kiosk having appropriate
card readers and the
like. The kiosk 189 may convert the physical stored value cards into
electronic value tokens in the
user's electronic wallet. Afterwards, the physical stored val ue card may be
retained or destroyed
by the kiosk 189 or returned to the user. In one embodiment, the physical
stored value card is not
usable by the user after the conversion. In another embodiment, the user may
have the option to
use the electronic value token or the physical stored value card. In other
words, both will be
"active" and available for use. The user may also purchase value tokens to
provision a wallet
directly from the kiosk 189.
[002971 In at least one embodiment, a user is associated with multiple
electronic wallets. In
order to identify one wallet out of multiple wallets associated with a user,
each of the multiple
wallets is associated with a unique wallet identification ("ID"). A database
or lookup table, for
example, may be used to access wallet identifications. In at least one
embodiment, the wallet ID is
customizable by the user.
100298] As referenced with respect to both the primary e-wallet and sub-
walletembodiments
described above, the disclosed e-wallet and sub-wallet methods and systems
provide users with the
ability to add value to electronic value tokens residing in an e-wallet and/or
sub-wallet. In an
embodiment, similar value-added capabilities and funeti ona I i tie s of the
instantly described
120
Date Recue/Date Received 2023-05-17
electronic value token transaction processing system 100 are detailed and
described in International
Application Serial No. PCT/US11/20570, such similar value-added capabilities
and functi onah ti es
may be adapted from the context described in International Application Serial
No. PCT/US11/20570
to be applied in the instant e-wallet/electronic value token context.
1002991 Customers may be offered incentives to purchase and/or redeem a value
token(s) via
value differentiation between the purchase and redemption values of said value
token(s).
1003001 In an embodiment, a value token with a face value of $25 may be
purchased by a
customer for $25, but the electronic value token may be added to the
electronic wallet in the amount
of $30¨ the $25 purchase price plus an additional $5 added as an incentive to
purchase the electronic
value token. Alternatively, rather than adding cash value to the electronic
value token, the electronic
value token may be encoded with a redemption coupon code for a specific
product or service. For
example, a $15 value token to a coffee house may have an electronic redemption
coupon code for a
free shot of the customer's syrup of choice to be added to any coffee
purchased at the coffee house.
The free shot of syrup may be redeemed in connection with redeeming a portion,
or all, of the
electronic value token amount or the free shot of syrup may be redeemed
separately.
1003011 In another embodiment, a value token vendor is able to offer customers
incentives to
redeem a value token by adding value in addition to the value of the
electronic value token at the
time the customer redeems the electronic value token. For example, a merchant
could run a
promotion in which it offers customers an additional $5 credit when the
customer uses a value token
for a purchase at one of the merchant's retail stores during a specified
period of time.
1003021 As noted above, the electronic value token transaction computer 150
communicates with
the datastore 180 and/or the issuers' authorization systems 160. The
electronic value token
transaction computer 150 may compare one or more of the card identification,
the terminal
identification, vendor identification, and the time and date of the activation
request contained within
the transaction request to data contained in the datastore 180 to determine
whether the electronic
value token to be added/redeemed is eligible for a value added award. For
example, a vendor may
run a promotion to encourage customers to purchase a value token, wherein
value tokens purchased
within a specified period of time may be purchased for a price less than the
value designated by the
electronic value tokens description or metadata. Thus, a customer could
121
Date Recue/Date Received 2023-05-17
purchase a $25 value token for some amount less than $25, e.g., $20. In either
of the above
examples, the value di fferentiators, e.g., bonus added to a redemption value
of a value token and
reduction of purchase price for a designated value of a value token, may be
applicable to bundled
value token packages and the value differentiators distributed amongst and/or
across the electronic
value tokens, either equally or disproportionately. Similarly, retailers
cancollaborate forcross-
promotions by honoring other retailer's value tokens in full, in part, or for
specific products or
promotions. By selecting to use an electronic wallet at the point of sale, the
user may even receive
the benefits of promotions of which the user was unaware. Furthermore, by
configuring the rules,
the user can be assured of getting the best promotions at various retailers
without comparison
shopping. As such, retailers can implement and change promotions at a rapid
pace and cross-
promote with other retailers on a daily or even hourly basis without spending
advertising resources
to make sure that the user is aware of the promotion and without requiring the
user to perform the
legwork involved in traditional redemption models such as cutting coupons,
inputting various
promotional rMes, and the like. Moreover, retailers can finely tune promotions
to various market
segments in order to strengthen relationships by providing for the segment's
particular needs.
[00303] The message modification unit 154 modifies the messages 106 and 110 to
add value
added information into the messages. For example, if it is determined by the
value added
determination unit 153 that a value token to be added is eligible for a value
added bonus, the
message 106 received from the point of sale device 111 is modified by the
message modification
unit 154 to include the determined value added bonus and is then forwarded as
message 10910 the
appropriate issuers' authorization system 160 for authorizing the request for
the amount specified
in the activation request plus the value added bonus. As another example, if
it is determined that
the electronic value token is eligible to be purchased at a discount, the
message 106 received from
the point of sale device 111 is modified by the message modification unit 154
(and forwarded as
message 109) to indicate to the appropriate issuers' authorization system 160
that the electronic
value token will be added to the electronic wallet for one amount, but that
the customer will be
charged a lesser amount reflecting the discount associated with the electronic
value token.
1003041 In Eui embodiment, the message modification unit 154 also modifies
messages 110 from
the issuers' authorization systems 160 intended for the point of sale device
111 to include any
information regarding value added to the electronic value token that may be
printed on the receipt
generated for the customer as well as information that may be presented to a
cashier on a terminal
122
Date Recue/Date Received 2023-05-17
101 or 104 that the cashier may communicate to the customer, and such modified
messages are
forwarded as messages 107 to the point of sale device 111.
1003051 As referenced with respect to both the primary e-wallet and sub-
walletembodiments
described above, the disclosed e-wallet and sub-wallet methods and systems
provide users with the
ability to exchange an electronic value token residing in the user's e-wallet
or sub-walletwith/for
an electronic value token not presently residing in the user's e-wallet or sub-
wallet, but made
available via the e-wallet' s or sub-wallet' stransaction system( s).
1003061 The electronic value token computer's 150 owner and'or operator may
earn revenue via
arbitrage-typeactiviti es. That is, electronic value token computer's 150
owner and/or operator
may keep the difference in going rates between two electronic value tokens,
e.g., a first electronic
value token being traded/exchanged and a second electronic value token being
desired/obtai ned.
In at least one embodiment, the electronic value token transaction computer
150 may charge the
user transaction fee forthe exchange instead. The transaction fee may be flat
or based on the size
of the exchange.
1003071 The electronic value token transac ton corn peter 150 may also charge
either or both of
the issuers and/or retailers associated with the exchange a flat transaction
fee or one based on the
amount of the exchange. These fees may be minimal but generated in high
volume. All parties
may benefit because the user is receiving value tokens the user will use in
exchange for value
tokens the user would not use. Moreover, one issuer and/or retailer is
eliminating the debt or
inventory liability associated with the exchanged value token, thus freeing up
capital for other uses.
Also, the other issuer and/or retailer may be gaining a customer, retaining a
loyal customer, or
increasing revenue if the customer spends more than the amount of the
electronic value token.
[003081 As referenced with respect to both the primary c-wall et and sub-
walletem bodiments
described above, the disclosed e-wallet and sub-wallet methods and systems
provide users with the
ability to exchange electronic value tokens located in e-wallets andlor sub-
wallets for other
electronic value tokens not located in said e-wallets or sub-wallets. Such
value token exchange
may be initiated (1) by an e-wallet user (i) at a point of sale, (ii) at a
kiosk,(iii) via a user's personal
digital assistant or smart phone, (iv) via web access to the user's e-wallet,
(v) or any other method
of accessing the user's e-wallet; or (2) by an application of an e-wallet rule
by an e-wallet
processing system, wherein the rule is established by (i) the e-wallet user,
(ii) the e-wallet provider,
(iii) or a combination thereof.
123
Date Recue/Date Received 2023-05-17
[00309] In at least one embodiment, exchanging a first value token associated
with a first
retailer located in the e-wallet for a second value token associated with a
second retailer not located
in the e-wallet requires an exchange rate be applied. This exchange rate may
be applied against the
value of the second value token being sought in the exchange, thus reducing
the face value of the
second value token is relation to the value of the first value token for which
it is exchanged or the
exchange rate may be applied against some other valued asset located in the e-
wallet (as prescribed
by any pertinent rules or directives). The exchange rate may be realized by
the e-wallet processing
system and/or shared with designated vendors, merchants, and issuers.
[00310] The exchange rate may established via an ongoing valuation program
operated by the
e-wallet processing system or affi I i ated entity compri si ng the tracking
of the use of and interest in
electronic value tokens, gift cards (or other similar instruments), the
acquisition of such electronic
value tokens, gift cards (or other similar instruments) from other e-wallet
users or other sources,
and the establishment of dynamically varying values for all such electronic
value tokens and gift
card-type instruments available to the e-wallet processing system for
incorporation into an
electronic value token exchange program.
[00311] The above-described electronic value toke n exchange program may be
exemplified by
the following discussion. An e-wallet user can approach an e-wallet associated
kiosk 189 at
Retailer A's establishment. The e.-wallet user interfaces with the kiosk 189
and provides the kiosk
with e-walletidentifying information (e.g., as described in Table 1 herein
"accountid"). The
provision of identifying information may be made via manual input by the
kiosk's user or may be
made automatically via communication betwe en the e -wal let user' s personal
digital assistant (or
proxy card 200) and the kiosk 189. The e-wallet user may then use the kiosk
189 to access thee-
wallet's electronic value token exchange program and the kiosk 189 may be
further used to
facilitate and complete any reque ste d electronic, value token exchange. In
an embodiment, thee-
wallet user may wish to exchange an electronic value token issued and/or
accepted by Retailer B
contained in the user's e-wallet (or a sub-wallet thereof) for an electronic
value token issued and/or
accepted by Retailer A. The e-wallet user interfacing with kiosk 189 can
result in the e-wallet user
being presented with a screen display such as is depicted in Figure 9C.
Besides providing thee-
wallet user with the ability to review the contents of the e-wall et, the
display allows the e-wall at
user to select an "Exchange" tab from the available ftmetionalities. The
"Exahringe" tab will then
present the e-wallet user with the options available for electronic value
token exchange. As
124
Date Recue/Date Received 2023-05-17
depicted in Figure 9D, such options can comprise: (1) view a selection of
electronic value token(s)
available for acquisition; (2) view the selection of electronic value token(s)
presently residing in e-
wallet; (3) view the various exchange rates for the identified electronic
value token(s) for
acquisition as calculated in view of the electronic value tokens selected for
removal (exchange)
from the e-wallet (exchange rates may vary based on types/retailers of
electronic value tokens
selected for exchange); (4) view options for satisfying exchange rate (e.g.,
(i) reduction in value of
electronic value token selected for acquisition to meet the exchange rate or
(ii) application of the
amount of the exchange rate to some other asset residing in the e-wallet such
as a credit card value
token or a debit card value token); (5) view a selection of options for
delivery of the electronic
value token selected for acquisition such as (i) delivery into the e-wallet
(or sub-wallet), (ii)
delivery via email, SMS, social media, or other electronic method to a
personal digital assistant or
computer, (iii) print out of a tangible version of the electronic value token
(e.g., via print on receipt-
type capability as described in U.S. Patent Application Serial No. 12/719,741)
at the kiosk or other
user-selected print device. The user may make its desired selections in
response to the information
provided in each of the above- describe screens, as each of the described
screen view options
include functionality allowing for selection of the displayed options. In this
example, the user
selects that the Retailer B $25.00 electronic value token residing in the e-
wallet is to be exchanged
for a Retailer A electronic value token. As a result, the electronic value
token exchange program
prompts the kiosk 189 to display that the requested exchange will result in
the user acquiring a
Retailer A electronic value token in the amount of $24.75 if the user selects
that the exchange rate
be applied against the value of the Retailer A electronic value token (the
exchange rate will vary
from transaction to transaction, the exchange rate could be any value, e.g.,
$0.001 to $10.00, or any
values below, within, or above this range). The user makes such selection. The
electronic value
token exchange program prompts the kiosk 189 to display the available delivery
methods and the
user selects delivery into the e-wallet. The electronic value token exchange
program prompts the
kiosk 189 to display another screen similar to Figure 9C, but indicating that
the e-wallet now
contains a Retailer A electronic value token in the amount of $24.75.
100312] As a
result of the above "Exchange" transaction, the e-wallet user received its
desired
Retailer A electronic value token and the electronic value token exchange
program received a
Retailer B $25.00 electronic value token. As part of the above-described
transaction, the electronic
125
Date Regue/Date Received 2023-05-17
value token exchange program contactedthe electronic value token issuing
entity of Retailer A
electronic value tokens (e.g., in an embodiment issuing entity of Retailer A
electronic value tokens
could be the electronic value token exchange program 2000) and requested a
Retailer A $24.75
electronic value token be provided to meet the e-wallet user' s re que s1
alternatively, the electronic
value token exchange program modi fled a Retailer A electronic value token it
al ready controlled,
e.g, modified a Retailer A $25.00 electronic value token to only be worth
$24.75 and informed the
issuing entity of Retailer A electronic value tokens that it could reduce its
liability associated with
said card by $0.25. Further, the electronic value token exchange program 2000
will contact the
Retailer 13 electronic value token issuer and provide the issuer with the
appropriate Retailer B
$25.00 electronic value token identification so that the issuer can remove
that Retailer B S25.00
electronic value token from its list of liabilities. Thus, as an end result,
the electronic value token
exchange program's activities have resulted in a $0.25 value (the exchange
rate, i.e., difference in
value of electrotie value taken acquired by requesting user and electronic
value token surrendered
by requesting user as part of the exchange) that may be allocated to
interested parties per
established contractual obligations.
1003131 In an alternative scenario, if the e-wallet requesting user selects
the exchange rate to be
satisfied by another asset residing in the e-wallet or sub-wallet, such as a
credit card electronic
value token or a debit card electronic value token, the c-wallet user would be
provided with a
$25.00 Retailer A electronic value token matching the $25.00 Retailer A
electronic value token
surrendered in the transaction and the exchange rate of S0.25 would be
realized from charging
against the credit card electronic value token or debiting against the debit
card electronic value
token Such actions would be transacted with communications between the
electronic value token
exchange program and the credit card electronic value token or the debit card
electronic value
token requesting that the $0.25 exchange rate value be paid to the electronic
value token exchange
program. Thus, again as an end result, the electronic value token exchange
program's activities
would have resulted in a $0.25 value (the exchange rate) that may be allocated
to interested parties
per established contractual obligations.
[003141 The above-described electronic value token exchange transaction (or
any described
variation thereof), although described in the kiosk 189 context, could also be
pert brined at point of
sale, via a personal digital assistant with a-wallet functionality, or via a
computer with access the
user's e-wallet
126
Date Recue/Date Received 2023-05-17
[00315] In an alternative electronic value token exchange embodiment, as
discussed previously,
the e-wallet may automatically direct electronic value token exchange
activities. For example, the
e-wallet user may manage the e-wallet so that upon the occasion when the user
presents the e-
wallet to satisfy a transaction at retail establishment, e.g., Retailer Q, and
the e-wallet contains no
Retailer Q branded electronic value tokens, the c-wallet will automatically,
and in real time, initiate
an electronic value token exchange process wherein the e-wallet communicates a
request for
electronic valuetoken exchange to the electronic value token transaction
computer 150. In this
example, the e-wallet user has managed the e-wallet so that all electronic
value tokens associated
with prepaid services (gift card-type electronic value tokens) are located in
a designated sub-wallet
and each of said electronic value tokens were placed/ordered/designated inthe
sub-wallet via a
preferential ranking system, e.g., most preferred electronic value token or
token type (e.g., #1) to
least preferred electronic value token or token type (e.g., #22, if there are
22 types of electroni
value tokens in the sub-wallet. For example, Retailer M branded electronic
value tokens may be
designated as most preferred and Retailer L branded electronic value tokens
maybe designated as
least preferred. Further in the example, the e-wallet also has been provided
with rules by the user
that directs the e-wallet, in circumstances wherein the e-wallet has been
presented to facilitate a
transaction at a retailer in which the e-wallet contains none of said
retailer's electronic value tokens
(the c-wal let willrecognize the retailer based on information exchanged
between the e-wallet and
the retailer's communication devices at the onset of the original
transaction), such as the Retailer Q
scenario described above, the e-wallet rules direct the e-wallet to initiate
an electronic value token
exchange request and to include in said request the exchange of the least
preferred electronic value
token residing in the e-wallet, i.e., the Retailer L branded electronic value
token (422) and if
necessary preferred electronic value token #21, #20, etc., for a Retailer Q
electronic value token in
an amount sufficient to meet the original transaction's amount. The electronic
value token
transaction computer 150, upon receipt of the electronic value token exchange
request,
communicate s with an electronic value token exchange program 2000, e.g., an
electronic value
token distributor, (which is part of the overall electronic value token
transaction processing system
1(X)) to effectuate the requestedelectronic value tokenexchange. The requested
electronic value
token exchange is performed, the e-wall et receives the requested Retai ler Q
branded electronic
value token, which is coincidentally used in conducting the original
transaction, and thee-wallet
surrenders (or makes unavailable for use and only available for modification)
the Retailer L
127
Date Recue/Date Received 2023-05-17
DEMANDE OU BREVET VOLUMINEUX
LA PRESENTE PARTIE DE CETTE DEMANDE OU CE BREVET COMPREND
PLUS D'UN TOME.
CECI EST LE TOME 1 DE 2
CONTENANT LES PAGES 1 A 127
NOTE : Pour les tomes additionels, veuillez contacter le Bureau canadien des
brevets
JUMBO APPLICATIONS/PATENTS
THIS SECTION OF THE APPLICATION/PATENT CONTAINS MORE THAN ONE
VOLUME
THIS IS VOLUME 1 OF 2
CONTAINING PAGES 1 TO 127
NOTE: For additional volumes, please contact the Canadian Patent Office
NOM DU FICHIER / FILE NAME:
NOTE POUR LE TOME / VOLUME NOTE:
