U.S. patent application number 10/840253 was filed with the patent office on 2004-10-21 for method and system for performing purchase and other transactions using tokens with multiple chips.
This patent application is currently assigned to Bank One, National Association. Invention is credited to Freund, Peter C..
Application Number | 20040210498 10/840253 |
Document ID | / |
Family ID | 33162922 |
Filed Date | 2004-10-21 |
United States Patent
Application |
20040210498 |
Kind Code |
A1 |
Freund, Peter C. |
October 21, 2004 |
Method and system for performing purchase and other transactions
using tokens with multiple chips
Abstract
An embodiment of the present invention is directed to devices
with multiple chips for facilitating small purchase transactions
through a stored value account while also permitting other
transactions through a network as directed by the user. According
to an embodiment of the present invention, a method and system for
performing at least one transaction may involve identifying a token
used to perform a transaction wherein the token is read at a reader
associated with a service provider, the token comprising at least
two chips, a first chip associated with a first protocol accessing
a local system and a second chip associated with a second protocol
accessing a central controller via a network; identifying an
appropriate protocol for the transaction; routing the transaction
to the appropriate protocol; identifying at least one account for
funding the transaction; authenticating the transaction; and
funding the transaction through the at least one account.
Inventors: |
Freund, Peter C.; (New York,
NY) |
Correspondence
Address: |
HUNTON & WILLIAMS LLP
INTELLECTUAL PROPERTY DEPARTMENT
1900 K STREET, N.W.
SUITE 1200
WASHINGTON
DC
20006-1109
US
|
Assignee: |
Bank One, National
Association
|
Family ID: |
33162922 |
Appl. No.: |
10/840253 |
Filed: |
May 7, 2004 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10840253 |
May 7, 2004 |
|
|
|
10401749 |
Mar 31, 2003 |
|
|
|
60368155 |
Mar 29, 2002 |
|
|
|
60490530 |
Jul 29, 2003 |
|
|
|
Current U.S.
Class: |
705/30 ;
705/39 |
Current CPC
Class: |
G06F 21/35 20130101;
G06Q 40/12 20131203; G06Q 20/10 20130101; G06Q 30/06 20130101; G07F
17/42 20130101 |
Class at
Publication: |
705/030 ;
705/039 |
International
Class: |
H04L 009/00 |
Claims
1. A method for performing at least one transaction, the method
comprising the steps of: identifying a token used to perform a
transaction wherein the token is read at a reader associated with a
service provider, the token comprising at least two chips, a first
chip associated with a first protocol accessing a local system and
a second chip associated with a second protocol accessing a central
controller via a network; identifying an appropriate protocol for
the transaction; routing the transaction to the appropriate
protocol; identifying at least one account for funding the
transaction; authenticating the transaction; and funding the
transaction through the at least one account.
2. The method of claim 1, wherein the first protocol supports a
stored value account located on the first chip.
3. The method of claim 2, wherein the first protocol is associated
with a mass transit system.
4. The method of claim 1, wherein the second protocol supports
general purpose transactions through the network.
5. The method of claim 1, wherein the at least one account
associated with the second protocol comprises a plurality of
funding accounts for funding the transaction.
6. The method of claim 5, wherein the at least one account
comprises one or more of a stored value account, a debit account
and a credit card account.
7. The method of claim 1, further comprising the steps of:
collecting transaction data associated with the transaction; and
storing the transaction data in at least one database.
8. The method of claim 1, further comprising the step of: applying
one or more credits in association with one or more loyalty
programs associated with a user of the token.
9. The method of claim 1, further comprising the steps of:
collecting preference data associated with a user; and storing the
preference data in at least one database.
10. The method of claim 7, wherein the steps of collecting and
storing transaction data are performed at the central controller
and transmitted to the local system for use in transactions
associated with the first chip.
11. The method of claim 8, wherein the step of applying one or more
credits is performed at the central controller and transmitted to
the local system for use in transactions associated with the first
chip.
12. The method of claim 9, wherein the step of collecting and
storing preference data is performed at the central controller and
transmitted to the local system for use in transactions associated
with the first chip.
13. The method of claim 1, wherein identifying at least one account
for funding the transaction is based on at least one predetermined
account condition.
14. The method of claim 13, wherein the at least one predetermined
account condition comprises at least one of purchase amount limit,
merchant identity, type of merchant and type of purchase.
15. The method of claim 1, wherein the token further comprises an
audit chip for tracking activity of the first chip and the second
chip.
16. A system for performing at least one transaction, the system
comprising: a token for performing a transaction wherein the token
is read at a reader associated with a service provider, the token
comprising at least two chips, a first chip associated with a first
protocol accessing a local system and a second chip associated with
a second protocol accessing a central controller via a network;
where an appropriate protocol is identified for the transaction and
the transaction is routed to the appropriate protocol; and the
central controller for identifying at least one account for funding
the transaction, authenticating the transaction and funding the
transaction through the at least one account.
17. The system of claim 16, wherein the first protocol supports a
stored value account located on the first chip.
18. The system of claim 17, wherein the first protocol is
associated with a mass transit system.
19. The system of claim 16, wherein the second protocol is used to
make general purpose transactions through the network.
20. The system of claim 16, wherein the at least one account
associated with the second protocol comprises a plurality of
funding accounts for funding the transaction.
21. The system of claim 20, wherein the at least one account
comprises one or more of a stored value account, a debit account
and a credit card account.
22. The system of claim 16, further comprising: a track module for
collecting transaction data associated with the transaction; and a
database for storing the transaction data.
23. The system of claim 16, further comprising: a loyalty module
for applying one or more credits in association with one or more
loyalty programs associated with a user of the token.
24. The system of claim 15, further comprising: a profile module
for collecting preference data associated with a user; and a
database for storing the preference data.
25. The system of claim 22, wherein the tracking module is at the
central controller and the transaction data is transmitted to the
local system for use in transactions associated with the first
chip.
26. The system of claim 23, wherein the loyalty module is at the
central controller and loyalty data is transmitted to the local
system for use in transactions associated with the first chip.
27. The system of claim 24, wherein the profile module is at the
central controller and preference data is transmitted to the local
system for use in transactions associated with the first chip.
28. The system of claim 16, wherein identifying at least one
account for funding the transaction is based on at least one
predetermined account condition.
29. The system of claim 28, wherein the at least one predetermined
account condition comprises at least one of purchase amount limit,
merchant identity, type of merchant and type of purchase.
30. The system of claim 15, wherein the token further comprises an
audit chip for tracking activity of the first chip and the second
chip.
31. At least one processor readable carrier for storing a computer
program of instructions configured to be readable by at least one
processor for instructing the at least one processor to execute a
computer process for performing the method as recited in claim
1.
32. At least one signal embodied in at least one carrier wave for
transmitting a computer program of instructions configured to be
readable by at least one processor for performing at least one
transaction, the computer process comprising: token identifying
means for identifying a token used to perform a transaction wherein
the token is read at a reader associated with a service provider,
the token comprising at least two chips, a first chip associated
with a first protocol accessing a local system and a second chip
associated with a second protocol accessing a central controller
via a network; protocol identifying means for identifying an
appropriate protocol for the transaction; routing means for routing
the transaction to the appropriate protocol; account identifying
means for identifying at least one account for funding the
transaction; authenticating means for authenticating the
transaction; and funding means for funding the transaction through
the at least one account.
33. A method for performing at least one transaction, the method
comprising the steps of: identifying a token used to perform a
transaction wherein the token is read at a reader associated with a
service provider, the token comprising at least two chips, a first
chip associated with a first protocol and a second chip associated
with a second protocol; identifying an appropriate protocol for the
transaction; wherein the first protocol accesses a local system
stored value account associated with a mass transit system and the
second protocol accesses a central controller via a network for
general purpose transactions; routing the transaction to the
appropriate protocol; identifying at least one account for funding
the transaction based on at least one predetermined account
condition comprising at least one of purchase amount limit,
merchant identity, type of merchant and type of purchase;
authenticating the transaction; and funding the transaction through
the at least one account; wherein the at least one account
associated with the second protocol comprises a plurality of
funding accounts for funding the transaction, the at least one
account comprising one or more of a stored value account, a debit
account and a credit card account; and wherein the token further
comprises an audit chip for tracking activity of the first chip and
the second chip.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] The present application claims priority as a
continuation-in-part to U.S. patent application Ser. No.
10/401,749, filed on Mar. 31, 2003, which in turn claims priority
to U.S. Provisional Patent Application Serial No. 60/368,155, filed
on Mar. 29, 2002, which are hereby incorporated by reference herein
in their entirety.
[0002] The present application claims priority to U.S. Provisional
Patent Application No. 60/490,530, filed Jul. 29, 2003, which is
hereby incorporated by reference herein in its entirety.
FIELD OF THE INVENTION
[0003] The present invention relates generally to performing
purchase transactions and other functionality, and more
specifically to a token with multiple radio frequency
identification (RFID) and/or other types of chips associated with
multiple protocols for performing purchase transactions funded by
one or more accounts.
BACKGROUND OF THE INVENTION
[0004] The current domestic, legal, reported cash market is
reported to include 300 billion transactions totaling $1 trillion
per annum. According to some estimates, seventy-five percent (75%)
of those transactions involve payments of less than $20. Many
financial institutions, credit card companies, merchants and
consumers would prefer that these payments be made electronically.
However, other than for transit applications, electronic payments
for small value transactions have achieved minimal consumer
penetration.
[0005] Current credit/debit processes were optimized for larger
value payments. The level of service for larger value payments
cannot be supported by small value transactions. Since small value
payments cannot support the service levels normal for typical
credit/debit cards, there must be a means to communicate lower
service level expectations to consumers. It would be very hard to
educate consumers that the same card they have used for decades has
two different service levels. Therefore, use of a different token
may help consumers identify the difference.
[0006] Technologically new payments mechanisms have often been
frustrated by the `chicken or the egg` conundrum. Until there are
lots of consumers with the new devices, merchants are reluctant to
pay the cost of installing new readers for the technology.
Similarly, consumers are reluctant to carry new devices until there
are enough merchants to accept them. Despite increasing fraud
associated with criminals `stripping` the information from
magnetic-stripe cards, the card associations have failed to deploy
more secure alternatives. Smartcards are just one example of the
devices that have failed to gain traction.
[0007] RFID technology is very broadly used today. RFID are
currently used to identify cattle, packages, and owners of vehicles
and for some payments (e.g., the 5 MM active Exxon Mobil
SpeedPass.TM.). The technology is available in at least two forms,
active and passive RFID devices.
[0008] E-Z Pass.TM. is an example of an active RFID device. In
order to permit cars to be recognized at speeds up to 200 MPH, such
active RFID devices have a battery and in response to a signal from
readers, transmit a signal that can be recognized from a distance
(e.g., 40 meters) from the reader. At such distances, it is
important that only the intended vehicle is charged for the toll.
As a consequence, technology is focused on tracking a particular
vehicle within a specific lane of traffic.
[0009] Another implementation of RFID technology involves passive
devices. Passive RFID devices have no battery. These devices
contain chips and an antenna. When the passive RFID device is in
proximity of a reader, usually within inches but can be feet away,
the chip is activated by an RF signal sent by the reader. The
reader's broadcast RF signal is captured by the passive device's
antenna and generates sufficient electrical energy to activate the
chip. The passive RFID chip is hardwired to respond in a particular
way, to be recognized by the reader. Certain mass-transit cards are
an example of a passive RFID device.
[0010] Payments using RFID devices are beginning to emerge, though
there are several impediments. Merchants have balked at the
$5,000-15,000 cost of installing RFID readers, because there are
few RFID enabled consumers, and issuers are reluctant to distribute
tokens (at a cost of upwards of $8 each) unless there are enough
merchants to generate sizeable payments.
[0011] Other drawbacks may also be present.
SUMMARY OF THE INVENTION
[0012] Accordingly, one aspect of the invention is to address one
or more of the drawbacks set forth above.
[0013] According to an embodiment of the present invention, devices
(e.g., tokens) may include multiple chips associated with one or
more accounts. For example, a token may include a first chip
associated with a stored value account to facilitate small purchase
transactions and a second chip for permitting network based
transactions as directed by the user. For example, the first chip
having a stored value account may be associated with a mass-transit
system and/or other service providers (e.g., merchants, etc.) while
the second chip may be connected to multiple accounts via a
network. When the device interacts with a reader for a purchase
transaction, one or more of the plurality of accounts may be
accessed. Selection of an account may be based on the amount of the
purchase, the identity of the merchant, type of transaction,
predetermined rules, user selection as well as other criteria
and/or action.
[0014] According to one exemplary embodiment, method for performing
at least one transaction comprises the steps of identifying a token
used to perform a transaction wherein the token is read at a reader
associated with a service provider, the token comprising at least
two chips, a first chip associated with a first protocol accessing
a local system and a second chip associated with a second protocol
accessing a central controller via a network; identifying an
appropriate protocol for the transaction; routing the transaction
to the appropriate protocol; identifying at least one account for
funding the transaction; authenticating the transaction; and
funding the transaction through the at least one account.
[0015] In accordance with other aspects of this exemplary
embodiment, the first protocol supports a stored value account
located on the first chip; the first protocol is associated with a
mass transit system; the second protocol supports general purpose
transactions through the network; the at least one account
associated with the second protocol comprises a plurality of
funding accounts for funding the transaction; the at least one
account comprises one or more of a stored value account, a debit
account and a credit card account; the method comprises the steps
of collecting transaction data associated with the transaction and
storing the transaction data in at least one database; the method
comprises the step of applying one or more credits in association
with one or more loyalty programs associated with a user of the
token; the method comprises the steps of collecting preference data
associated with a user and storing the preference data in at least
one database; the steps of collecting and storing transaction data
are performed at the central controller and transmitted to the
local system for use in transactions associated with the first
chip; the step of applying one or more credits is performed at the
central controller and transmitted to the local system for use in
transactions associated with the first chip; the step of collecting
and storing preference data is performed at the central controller
and transmitted to the local system for use in transactions
associated with the first chip; wherein identifying at least one
account for funding the transaction is based on at least one
predetermined account condition; wherein the at least one
predetermined account condition comprises at least one of purchase
amount limit, merchant identity, type of merchant and type of
purchase; and wherein the token further comprises an audit chip for
tracking activity of the first chip and the second chip.
[0016] According to one exemplary embodiment, a system for
performing at least one transaction comprises a token for
performing a transaction wherein the token is read at a reader
associated with a service provider, the token comprising at least
two chips, a first chip associated with a first protocol accessing
a local system and a second chip associated with a second protocol
accessing a central controller via a network; where an appropriate
protocol is identified for the transaction and the transaction is
routed to the appropriate protocol and the central controller for
identifying at least one account for funding the transaction,
authenticating the transaction and funding the transaction through
the at least one account.
BRIEF DESCRIPTION OF THE DRAWINGS
[0017] FIG. 1 illustrates a system for performing purchase
transactions with a token with multiple chips according to an
embodiment of the present invention.
[0018] FIG. 2 illustrates a network system for performing purchase
transactions with a token according to an embodiment of the present
invention.
[0019] FIG. 3 is an exemplary flowchart for registering a token
according to an embodiment of the present invention.
[0020] FIG. 4 is an exemplary flowchart for enabling a user to make
a purchase transaction with a token according to an embodiment of
the present invention.
DETAILED DESCRIPTION OF THE INVENTION
[0021] A system and method for using a token with multiple chips
for performing purchase transactions are described. According to an
embodiment of the present invention, the system and method may make
use of existing tokens distributed for other purposes or for
purposes of payment, as well as newly distributed tokens, with
radio frequency identification chips and/or other types of chips,
to perform various purchase transactions. One technical effect of
the invention is to provide a system and method for performing
purchase transactions using a device (e.g., a token) with multiple
chips, as set forth in the Summary of the Invention, above and as
more fully described here in the Detailed Description of the
Invention. Various aspects and components of this system and
process are described below. While the present invention is
described in terms of tokens and radio frequency identification
chips in particular, it is recognized that other types of tokens
and chips may also be used.
[0022] According to an embodiment of the present invention, a
system and method for small value payments solutions may be faster
than cash and more cost efficient. For example, a token associated
with a mass transit system (or other system) may be used to
facilitate small value transactions and still permit larger
transactions as directed by a user. As current credit/debit
payments are often too slow and/or costly to be successful in many
small payment situations, an embodiment of the present invention
may be used for such transactions while offering payment to a mass
transit system (or other system) with which users are already
familiar. Such a token or device may enable merchants to accumulate
consumer transaction information, and be able to offer coupons
and/or other customer loyalty rewards. By using a token associated
with a system familiar to customers (e.g., a mass transit system,
etc.), an embodiment of the present invention may avoid aspects of
the classic `chicken or the egg` conundrum that often plagues new
payment systems. As mass transit systems have already installed
readers for their systems, an educated customer base has already
been established and merchants may avoid installing readers for new
payments with concern about whether there are enough consumers with
new payment tokens.
[0023] According to an embodiment of the present invention, transit
applications may employ a chip stored value purse (also referred to
as a "chip stored value account"), obviating use of a network to
authenticate payments. While such payments may be faster and
cheaper than network payments, they may also be less secure. A
transit authority's RFID (or other) implementation is likely to be
unique. According to an embodiment of the present invention, to
penetrate the transit business, one path may call for issuers of
general-purpose tokens to adopt wholesale the existing protocols of
the local transit authorities, thereby obviating any change in
transit readers or process. By way of example, tokens distributed
in Chicago may incorporate a chip purse with identical (or
substantially similar) logic and communication protocols as tokens
issued by Chicago Transit. According to an embodiment of the
present invention, the token may use exactly the same (or
substantially similar) chip as used by Chicago Transit
Authority.
[0024] An embodiment of the present invention relates to a system
and method by which an existing and large network of devices, as
well as newly distributed devices, may be used by consumers to
authenticate themselves and permits consumers to apply various
payments mechanisms. According to an exemplary implementation, an
existing broadly distributed network may involve active and/or
passive RFID devices as well as other devices or chip types held by
consumers.
[0025] While RFID chips are discussed in various exemplary
embodiments and applications, it is recognized that other types of
chips may also be used in accordance with the various embodiments
and applications of the present inventions. For example, the chips
may include various types of Central Processing Unit (CPU) chips.
CPU chips may include a memory function and an ability to
communicate with another device, such as a reader. Other chips that
communicate using different spectrums of frequencies may also be
used. Other types of chips using various communication media, such
as light, sound, vibration, tones, other frequencies and other
forms of communication may be implemented. Passive as well as
active chips may also be included. According to an embodiment of
the present invention, a single token may include multiple types of
chips. For example, a token may include a RFID chip, a CPU chip, a
passive chip (e.g., bar code, magnetic stripe, etc.) and/or other
types of chips. In another example, a token may include a smart
card chip, multiple RFID chips, and chips communicating on a
different spectrum. Various other combinations may be implemented.
Essentially any type of chip having a memory capability and ability
to communicate with another device (e.g., reader) may be used.
[0026] In addition, a token may include a variety of portable or
mobile devices, such as cards (e.g., transit card, ID card,
driver's license, etc.), wireless devices (e.g., cell phones,
etc.), personal digital assistants (PDAs), laptop, etc. The token
may be included in any portable device, including objects, such as
wallets, card holders, briefcases, watches, and/or other objects
that may be carried or used by a user.
[0027] FIG. 1 illustrates a system 100 for performing purchase
transactions with a token with multiple chips according to an
embodiment of the present invention. User 101 may use token 102 to
make various transactions at various points of purchase (e.g.,
merchants, mass transit, etc.). Token 102 may include multiple
chips, as shown by 104 and 106. Chip 108 may include an audit chip
for tracking the activity of chips 104 and 106. Each token and/or
each chip may have an associated unique identifier. Token 102 may
be used to make stored value account payments (e.g., chip purse
payments), network payments and/or other payments according to
various protocols. For example, a single token may support multiple
protocols, including a protocol (e.g., transit protocol, etc.) for
supporting chip purse transactions including stored value account
transactions, network protocols for supporting general purpose
transactions and a protocol for tracking payments. When placed in
the range of each different type of reader, the appropriate chip of
the token may respond and communicate appropriately. In another
example, the user may select a protocol, if more than one protocol
is available. General purpose payments may involve network access
where token 102 may be used to authenticate the user to a network,
such as Network 120. While one of each item is described for the
convenience of explanation, it is understood that multiple devices
and elements may be used within system 100 of FIG. 1. For example,
multiple Systems 114 and multiple associated Readers 110 may be
realized.
[0028] A merchant or other service provider may provide a reader
for reading token 102. In this exemplary embodiment, Reader 110 may
be linked to chip 104 and Reader 112 may be linked to chip 106.
Readers 110 and 112 may be located at various merchant locations,
service provider locations and/or other locations that may require
some form of purchasing action. For example, Reader 110 may be
located at mass transit locations, toll way locations, gasoline
pump locations, merchant locations, service provider locations,
etc. Reader 110 may be connected to System 114 to support system
transactions. Reader 112 may be located at merchant locations,
service provider locations, etc. Reader 112 may be connected to
Network 120 to support network transactions. In addition, system
transactions may receive data from Central Controller 130 through
Network 120 via 144 and 146, or directly via 142.
[0029] Reader 110 may support system transactions through System
114. For example, Reader 110 may be linked to System 114 which may
fund chip 104 through a stored value account 105--which may
function as a vault on the chip itself. System 114 may manage a
plurality of transaction records 116, 118 associated with one or
more chips. In this example, transaction record 116 may be
associated with chip 104. For example, a user may use multiple
forms of transportation during a commute. The user may drive to a
mass transit station via a toll road. This user may use a token
with a first chip associated with the toll road and a second chip
associated with a mass transit system (e.g., a subway). According
to another example, the Reader 110 may be located at a merchant,
such as a coffee shop, quick service restaurant or other
establishment. System transactions may be more common in
establishments where high throughput and quick turn-around time are
important. For quick service restaurants, each second delay results
in approximately 1% change in profit. Such merchants experience
highest volume during peak hours (e.g., breakfast, lunch, dinner).
As stored value accounts take very little time, system transactions
may be locally executed at merchants and service providers where
the speed of the transaction is a priority.
[0030] According to another embodiment, information may be
collected for system transactions. Such information can be stored
in and accessed from System 114, Transaction Record 116, 118,
Central Controller 130 or any combination thereof. For example,
information regarding the token may be collected, stored and used
to extract demographic, other information and/or for other purpose.
Information may include usage (e.g., twice a day, five times a
week, etc.). How much each chip spends or how often a chip is used
during a time period may also be determined (e.g., over $100 spent
each month, number of times a chip is read by the reader, etc.).
Other information may also be gathered.
[0031] Reader 110 may interact directly with chip 104, by simply
debiting the stored value account located on the chip directly, if
the available balance covers the transaction value. Reader 110 may
respond to chip 104 (and/or other chips) on token 102 in various
ways. For example, Reader 110 may simply approve most or all
transactions. In another example, Reader 110 may communicate with
System 114 where System 114 may approve the transaction if certain
conditions are met or not met. For example, if the token (or chip)
has not been reported lost or stolen, the transaction will be
approved. In another example, Central Controller 130 may update
System 114 (which may include Transaction Records 116, 118, etc.)
with data, which may be used to approve the transaction. Data may
include stored value balances, fraud alerts, predetermined
conditions and/or other information (e.g., promotions, loyalty
points, etc.). Updates from Central Controller 130 to System 114
may occur at predetermined intervals (e.g., each day, every other
day, every 4 hours, etc.), when predetermined conditions are met
(e.g., if balance reaches a certain level, etc.) or whenever there
is data to be updated.
[0032] Reader 112 may be linked to Network 120. A network
transaction may involve receiving authorization to make the
transaction. For example, the chip may be identified and
authorized. If the chip has been terminated, the transaction will
be denied. Fraud detection software may be activated to verify that
the chip is authentic and authorized for the transaction. In
addition, the transaction itself may be authorized based on amount,
type of transaction, merchant, etc. Suspicious patterns and/or
other indicia of fraud may be identified to prevent and/or stop
fraudulent activity. Network 120 may represent the Internet or
other type of network. Network 120 may be linked to a Central
Controller 130 for performing various network related functions.
Central Controller 130 may be funded via various accounts,
including network stored value accounts, an account at a financial
institution, debit account, credit card transaction and/or other
types of accounts or other means of funding a transaction. In
addition, user 101 may access Network 120 to gain data and/or
perform actions concerning the chip 106 as well as other chips on
token 102, as shown by 140.
[0033] The different systems may further communicate as well as
transmit and/or exchange data, as represented by 142 and via
Network 120, as shown by 144 and 146. Central Controller 130 may
communicate with multiple local systems, an exemplary system is
illustrated by 114. For example, Central Controller 130 may
distribute information to local merchants through systems. Common
(or general) information may be applicable to most or all entities
associated with a system, such as System 114. For example, each
merchant may have a corresponding system 114, which may receive
common data from Central Controller 130. Central Controller 130 may
inform local systems of a loyalty program promotion, coupon alert,
fraud alert and/or other information. In another example, Central
Controller 130 may send specific targeted information to a single
system or multiple systems. Further, system 114 may also post a
transaction (and/or other information, action, etc.) to Central
Controller 130.
[0034] Other information may be shared between a network chip
(e.g., chip 106) and a system chip (e.g., chip 104). Central
Controller 130 may authorize an action to be performed at System
114. For example, a system chip may be funded (e.g., top-up, etc.)
through an account associated with a network chip. Preference data
may be accessed by Central Controller 130 to perform the action at
System 114. For example, Reader 110 may recognize that chip 104 is
below a threshold of funds, or even out of funds. The user may
perform functions, such as adding funds (e.g., top up), through
Reader 110 or other device. System 114 may communicate with Central
Controller 130 to retrieve predefined top-up preferences specific
to the user, chip and/or token. In this example, Central Controller
130 may recognize that a top-up of $20 is authorized when funds are
low. This information may be transmitted to System 114. System 114
may then automatically add $20 to chip 104's stored value account
105. The user may confirm the action, without having to enter
specific instructions for the transaction. While dollar amounts may
be specified, other events, such as trips, may be added to a token.
For example, five trips may be added to mass transit stored value
account.
[0035] One or more chips of a token of an embodiment of the
invention may be associated with a number of different accounts
having different properties, thus enabling the combination of a
system payment (e.g., chip purse) and network payment solutions on
a single token. Additional payment solutions may be provided as
well. According to an embodiment of the present invention, the
token may be associated with an existing mass transit system to
ensure a certain level of deployment of token readers. A single
token may support multiple protocols (e.g., chip purse, network
stored value account, track payments, etc.). When placed in the
range of each different type of reader, the chip will respond and
communicate appropriately.
[0036] Various types of chip uses may be realized by various
embodiments of the present invention. RFID chips may include
proximity, vicinity and other chip types. Proximity chips may
involve bringing the RFID chip within a distance (e.g., 4 cm or
other range of distance) to perform an action, such as a
transaction, payment, etc. A number of vicinity chips may be
identified by a reader (or other device) for identifying quantity,
presence or other state of the chip. For example, vicinity chips on
items may identify the number of items within a single closed
container, without having to open the container. In store shelves,
vicinity chips may be placed on items for taking inventory and
warning of depleted supplies.
[0037] In another example, a vicinity chip may be used to identify
an individual within a distance of sensitive information, device or
other data. For example, a computer may automatically lock up (shut
off, fade to black, or perform other action to obscure or hide the
information) if an authorized person (e.g., senior executive)
leaves a workstation with sensitive information. The vicinity chip
may recognize that within a radius the intended person is or is not
physically present. The authorized person may wear a token with an
embedded chip, carry the token, etc.
[0038] According to another example, an employer may issue a token
to employees where the token may be unique to each employee. The
token may provide access to an office. The token may include
additional chips for various functions. For example, the token may
include a chip for making payments at a cafeteria (or other
establishment), a chip for making corporate payments (the payments
may be credit card, debit, stored value or other type of payment),
a chip for making payments through a flex benefit account (or other
employer sponsored account), a chip for using mass transit (which
may be subsidized by the employer), a chip for making parking
garage payments (another chip may be used to gain access to the
garage) and/or other chips for various other functions. Such tokens
may be personalized for each employer's needs and/or
preferences.
[0039] Other information may be embedded into each chip as well.
For example, an appropriate security protocol may be associated
with a chip, granting a level of security to the user for certain
functions. For example, a senior executive may have access to
information that a lower ranking employee will not. Certain actions
may be available to some users based on the security protocol. In
addition, a token may support multiple levels and/or types of
security by using different chips. For example, each level of
security may be associated with a different chip. Multiple
applications requiring similar security may be supported by one
chip with the appropriate level of security.
[0040] FIG. 2 illustrates a network system 200 for performing
purchase transactions with a token according to an embodiment of
the present invention. Central Controller 130 may provide various
functions and/or modules associated with transactions via a
network. Central Controller 130 may include Account Module 210,
Profile Module 212, Track Module 214, Loyalty Module 216,
Authenticate Module 218 and/or other Module 220. The modules of
Central Controller 130 may be further combined, duplicated and/or
separated. The modules of Central Controller 130 may also be
provided across multiple central controllers. Other implementations
may be realized.
[0041] Central Controller 130 may interact with data via various
sources, including various databases. For example, one or more
modules of Central Controller 130 may access Account Database 230,
Profile Database 232, History Database 234, Loyalty Database 236,
Authentication List 238, and/or other database 240. The databases
may be further combined, duplicated and/or separated.
[0042] Account Module 210 may debit and/or credit one or more
accounts identified by the user. The user may also identify a
default account for making purchases. For general purpose
purchases, the user may apply certain conditions for triggering one
or more accounts for payment. For example, for certain transactions
above a certain dollar limit (e.g., $20), a first account may be
used. For other transactions below a dollar limit, a second account
may be triggered. Account identification information, such as
account number, routing information, financial institution, credit
card number, debit card number, expiration dates, and/or other data
may be obtained for proper funds transfer. In addition, other
preference data may be associated with each account. For example, a
user may specify a frequency at which funds may be transferred to
an account (e.g., a predetermined amount each month, a
predetermined amount when a balance reaches a predetermined level
(e.g., below $10.00, etc.), and/or other account management
preferences). The accounts may be pre-funded or post-funded via
various forms of payment. A request for funding may be transmitted
to one or more sources of funds, after a predetermined time (e.g.,
each week, month, etc.), after transaction amounts reach a
predetermined level (e.g., $50, $100, etc.) or other event or
condition. In addition, certain transactions may be funded from two
or more identified accounts, if so desired. Data associated with
account management may be stored in Account Database 230.
[0043] Various types of accounts may be implemented. For example, a
network-based stored value account 250 may be used to fund
transactions. Stored value account 250 may be funded by cash, check
or other types of payment by the user, an authorized agent or
representative. In another example, a financial institution 252 may
fund transactions. Financial institution 252 may include one or
more banks, credit unions and/or other similar establishments.
Transactions may be funded by a direct deposit from an account at
financial institution 252. In addition, transactions may be funded
by a debit through an account at financial institution 252.
[0044] According to yet another example, transactions may be funded
by a credit card or other similar mechanism. Merchant acquirer 254
may fund the transaction and receive funds from a credit card
association 256 associated with Issuer 258. This transaction may
involve a standard interchange fee associated with credit card
transactions, which is paid by a merchant that accepts credit
cards. In addition, a card association may receive an assessment
fee and an issuer may receive a merchant bank fee. In this example,
Merchant Acquirer 254 may electronically collect information
related to the transaction (e.g., card number, purchase amount,
etc.) and pass this data to Card Association 256 to obtain
permission to authorize the transaction. Once Card Association 256
receives a purchase authorization request, Card Association 256
sends this data to Issuer 258, which may include a bank that issued
the credit card. Issuer 258 verifies that the transaction is within
the limits of the cardholder's account and sends a response back to
Card Association 256. Merchant Acquirer 254 may then receive
authorization.
[0045] According to an embodiment of the present invention, payment
may be made directly by a transfer of funds from the user of the
token to the merchant operating the reader, such as by a transfer
of funds from a financial account of the user to the financial
account of the merchant. Thus, a direct payment may be made with
relatively little time delay. Other accounts may be used to fund
transactions, including lines of credit, etc.
[0046] Profile Module 212 may access profile information of the
user (or other associated entity) identified by the corresponding
chip. Profile information may include user identification data
(e.g., name, address, contact information, etc.), account
conditions, loyalty programs and/or other preference data. For
example, a user may prefer to use one account for certain purchases
from a specific merchant, type of merchant (e.g., quick service
restaurants), purchases of a certain dollar amount (e.g., below
$20, above $20, etc.), and/or other conditions. The user may also
identify one or more loyalty programs for participation (e.g.,
frequent flyer, coupons, etc.). Other preference data may be stored
and accessed by Profile Module 212. Profile data may be stored in
Profile Database 232. Profile Module 212 may also include
preference data, including how to add funds when an account is
below a threshold.
[0047] Track Module 214 may obtain and store historical data
associated with the appropriate chip. Track Module 214 may also
obtain valuable consumer-related data. For example, data that may
be tracked may include purchase amounts, dates (and/or time) of
purchase, merchants, types (or categories) of merchants, etc. This
information may be stored and/or compiled in History Database 234.
The user may access historical data in various formats. For
example, historical data may be manipulated and presented in a
report form in various formats. This information may be available
to the user, merchant and/or other entity. In addition, Audit Chip
108 may track activity associated with one or more chips located on
Token 102. For example, audit chip data may be tracked by Track
Module 214. The activity tracked by Audit Chip 108 may include
frequency of user, type of user and/or other activity data.
[0048] Loyalty Module 216 may contain information concerning one or
more loyalty programs associated with the appropriate chip. Loyalty
programs may provide incentives to the user associated with the
appropriate chip for certain transactions. Exemplary loyalty
programs may include frequent flyer miles, coupons, bonus points,
credits, discounts and/or other incentives. Different loyalty
programs may be associated with certain transactions. For example,
a particular merchant may provide 5% credit towards a gift
certificate for every dollar spent at the merchant by a merchant
card. Purchases from the merchant and other participants may be
funded with the appropriate merchant card. Those purchases may be
credited to that specific loyalty program, regardless of the amount
of purchase. All other purchases may be funded by another
designated account, which may be associated with a different
loyalty program or other program. Data associated with loyalty
programs may be stored in Loyalty Database 236.
[0049] Authenticate Module 218 may authenticate the token, chip
and/or transaction. For example, a network transaction may involve
authenticating the user and/or authorizing the transaction. For
example, the chip may be identified and authorized. If the chip has
been terminated, the transaction will be denied. Fraud detection
functions may verify that the chip is authentic and authorized to
make the desired transaction. In addition, the transaction itself
may be authorized, based on amount, type of transaction, merchant,
etc. Suspicious patterns and/or other indications of potential or
on-going fraud may be identified to prevent and/or stop fraudulent
activity. Authenticate Module 218 may access information to
approve, deny and/or hold chip use. External information (e.g.,
police reports, bankruptcy checks, fraud alerts, etc.) may be
accessed. In addition, Authenticate Module 218 may access
Authentication List 238.
[0050] Authentication List 238 may determine if Reader 112 and/or
Token 102 is authentic and permitted to perform transactions.
Authentication list may be used as security to reduce the chances
of fraud. According to an embodiment of the present invention,
Token 102 may include information about the address (e.g., internet
address) of Central Controller 130. Reader 112 may then access
Central Controller 130 to perform the purchase transaction.
Authentication List 238 may be accessed to ensure that Token 102 is
allowed or authorized to perform a transaction. For example,
Authentication List 238 may contain a list of tokens that are in
good standing, delinquent or other condition. Other data may
include spending limits, warnings, unauthorized types of purchases
(e.g., inappropriate material, etc.) and/or other information.
While FIG. 2 illustrates Authentication List 238 in communication
with Central Controller 130, it is understood that Authentication
List 238 may be in communication with or resident on Reader 112
and/or other device. Authentication List 238 may also ensure that
Reader 112 is allowed to access Central Controller 130. According
to an embodiment of the present invention, Authentication List 238
may also include a list of authorized readers and register/readers
that are permitted to access Central Controller 130. Other types
and forms of authentication data may be maintained at
Authentication List 238.
[0051] A number of Quick Service Restaurants ("QSRs") (e.g.,
McDonalds.TM., Wendy's.TM., Taco Bell.TM., other fast food
restaurants, etc.) have indicated a willingness to use a new
payments solution that is quicker, as QSRs are generally throughput
constrained and their gross margin is about 80%, with each second
saved increasing profits as much as approximately 1%. Market
research shows consumers on average will buy 30% more when using a
token than when using cash. An embodiment of the present invention
provides a token with multiple chips for making quick transactions
that cost less per transaction and provides consumer data and a
conduit for loyalty rewards and coupons.
[0052] A purchase transaction token of an embodiment of the present
invention may reduce or eliminate chargebacks. Chargebacks are
generally known as transactions that are challenged by a card
holder or other entity (e.g., a card issuing bank) and is sent back
through interchange to the merchant bank for resolution. This often
results in the merchant's account being debited for the purchase
amount and funds being returned to the customer. Chargebacks
usually occur as a result of fraud, cardholder disputes over
merchant returns, processing or documentation errors and/or other
reasons. The costs of chargebacks can be significant to the
merchants. Typically, when a merchant receives a chargeback, it is
responsible for bank processing fees, cost of lost inventory and
interchange fees from the original transaction that cannot be
recovered. According to an embodiment of the present invention, by
using a token, small purchases may be treated as cash with a
corresponding responsibility left only between the merchant and the
customer. As a result, chargebacks associated with credit cards and
the costs incurred with processing these chargebacks may be
substantially reduced or eliminated.
[0053] According to an embodiment of the present invention, a
purchase transaction token may provide transaction level detail to
a user (e.g., customer) via an online connection, thereby reducing
or avoiding printed statements and the costs associated therewith.
The transaction level detail may be provided via a website. The
user may access the secure website via a password/PIN and login or
other authenticating mechanism. Transaction level detail may also
be provided by an electronic transmission (e.g., email, etc.) via
various devices (e.g., computer, PDA, mobile phone, wireless
device, etc.) or other communication to the user.
[0054] The purchase transaction token of an embodiment of the
present invention may be treated as cash, where the consumer bears
the risk if the token is lost. Thus, funds in a stored value
account, where a consumer has designated no access code, personal
identification number or other type of security, may be accessed by
unauthorized users if the token is lost or stolen. According to an
embodiment of the present invention, credit cards, financial
accounts and/or other accounts associated with a token may be
protected from unauthorized users through various security
mechanisms, such as consumer credit protections, personal
identification numbers, biometric information, etc.
[0055] The purchase transaction token of an embodiment of the
present invention may streamline transaction communications,
thereby adding speed, reducing costs and/or achieving other
efficiencies. The stored value account associated with the token
may simplify the necessary transaction communications where readers
interacting with the token do not need to process complex
transactions over a transaction network. As discussed above, chips
with stored value accounts provide for quick immediate
transactions. Complex transactions may be performed by a network
controller (e.g., central controller) and in some instances,
relevant information may be transmitted to a system by the network
controller.
[0056] Currently, many transportation fares are paid using physical
tokens, such as cash or magnetic stripe cards. However, for transit
authorities, tokens and cash are more expensive than magnetic
stripe cards. Newer transit tokens include RFID tokens, such as ISO
14443 RFID. RFID tokens are generally more secure and marginally
more costly than magnetic stripe cards. However, the cost to
maintain RFID readers may be substantially less (e.g., an average
annual cost to maintain a transit magnetic stripe reader is
approximately $360 versus an average annual maintenance cost of
approximately $75 l for RFID readers) as RFID readers are generally
contactless and may be completely sealed. As RFID technology is
growing rapidly, units costs are rapidly declining.
[0057] As recognized by an embodiment of the present invention, the
payment needs for transportation are different from those for QSRs
and/or other merchants and service providers. Speed is even more
critical for transit systems, as transactions need to be processed
almost instantaneously to allow commuters to access the transit
system (e.g., buses, subways, trains, etc.) in a timely manner.
Transit transaction costs are small because the transaction size is
smaller and margins lower than for QSRs. Further, many QSRs (and/or
other service providers) highly value consumer information and
consumer loyalty, rewards and coupon programs that may be of little
or no interest to some transit authorities. However, it is
understood that for tokens to be useful for higher value payments,
more security is required than for transit. Retailers that do not
require instantaneous response may prefer to maintain customer
loyalty and/or other data through a network. If time is of the
essence, a local system, such as System 114, can maintain customer
loyalty and/or other data, updated from a central controller, via a
network.
[0058] According to an embodiment of the present invention, a
simple stored value account may provide quick, cheap payments,
based on a purse held in the memory of the token. Read/write
capability permits the account to be credited and debited very
fast. In addition, each transit authority has special codes related
to more complex logic (e.g., unlimited use within a time window;
transfer capability; etc.). It is expected that large numbers of
commuters will be carrying transit tokens and that the tokens will
be easily accessible, and used, on average, at least twice a
day.
[0059] According to an embodiment of the present invention, for
more general purchases, a network stored value account may be used,
as discussed above in connection with FIG. 1 and FIG. 2. The token
may be used to authenticate a user to the network, such as Network
120. A network application may then access funds available from
various accounts, including stored value accounts associated with
the token, financial institution accounts, credit card accounts,
etc. Because of the network connection, transactions may be slower
than those transactions made using a chip purse (e.g., mass transit
transactions, etc.). However, network transactions may enable
collection of data connected with specific devices. Transaction
histories may be tracked and stored where consumer behavior may be
assessed. Further, coupons, loyalty rewards and/or other incentives
may be specifically targeted based upon the information collected.
Thus, as set forth in an embodiment of the present invention,
different payment scenarios (e.g., transit, general purpose, etc.)
may be funded using a single token. Additional chips, including
RFID and other chips, may be provided on the single token.
[0060] According to an embodiment of the present invention, a token
may be associated with a number of different accounts having
different properties, thus enabling the combination of a chip purse
and network payment solutions on a single token. Additional payment
solutions may be provided as well. Rapid and broad deployment of a
new payments solution in certain aspects may require that merchants
and consumers believe the new solution will become popular and
succeed. According to an exemplary embodiment of the present
invention, the token may be associated with an existing mass
transit system to ensure a certain level of deployment of token
readers. Card association support assists greatly in providing the
necessary clarity. A single token may support multiple protocols
(e.g., chip purse, network stored value account, track payments,
etc.). When placed in the range of each different type of reader,
the chip will respond and communicate appropriately.
[0061] According to an embodiment of the present invention,
general-purpose payments using a token may prefer network access.
For general-purpose payments, the token of an embodiment of the
present invention may be used as a means to authenticate the token
to a network. A personal preference profile may be established,
customized, and changed dynamically. Network tokens may be used for
many purposes, including, but not limited, to accessing stored
value accounts, transferring funds, aggregating points (e.g.,
loyalty points, etc.), instructing whether to opt-in or out of
loyalty rewards, coupons and/or other incentives, gathering store
(or other) transaction histories, enabling remote access of
accounts associated with the token, and single-sign-on and/or other
features. According to an embodiment of the present invention, for
general-purpose small payments, a network based stored value system
may be desired.
[0062] Current methods for funding a chip purse token involve
clumsy, multi-step processes for cash, credit or debit payments at
an electronic kiosk or with a person. In both cases, lines are
frequent. Naturally, tokens capable of a plurality of payments
(e.g., both chip purse and network payments), may be able to use an
ordinary transit authority funding means. However, funding a token
of an embodiment of the present invention may be easier, faster and
more convenient. According to an embodiment of the present
invention, consumers may establish a default payment method (e.g.,
a specific credit or debit account, etc.), avoiding the repetitive
swiping and personal identification number ("PIN") entries.
Automatic top-up may also be an option. The automatic top-up
transaction may be performed invisibly whenever the token is used
for a network payment, or it may be executed simply by touching the
token to a reader that is network connected.
[0063] Transit authorities may find it important to assure that
there are appropriate protections against counterfeit money.
According to an embodiment of the present invention, coordination
between the card association and the transit authority may be
useful to assist in preventing counterfeit tokens and/or
counterfeit funds within an account associated with the token.
According to an embodiment of the present invention, if transit
authorities are comfortable that issuers will transfer funds to
their account with each top-up, the transaction may be accomplished
directly by issuers. According to an alternative embodiment of the
present invention, a slight modification of the current
credit/debit funding mechanism may be used. A token holder may
request additional funds be added to the chip purse, either
directly, or by prior arrangement. The issuer may provide the
transit authority a payment authorization, exactly as would be
received at one of the electronic kiosks. After receiving payment
assurance from the issuer, the transit authority may deliver a
message to the token crediting the chip purse with additional
funds. This technique may be preferred by transit authorities, as
it would generally map to current protocols.
[0064] According to an embodiment of the present invention, by
enabling consumers to use a single token for transit, or other chip
purse applications, providers of network payments tokens may
increase the use and top-of-wallet presence for their own
applications. The expense of token fulfillment and customer service
may be reduced and commuters will be more satisfied. Broad scale
deployment of multi-purpose tokens may also reduce various staffing
needs.
[0065] According to an embodiment of the present invention, one
mechanism for small value payments is a stored value account (e.g.,
pre-pay or post-pay) that aggregates payments against infrequent
funding transactions. The issuers' funding transaction fees may be
reduced, and yet can support full interchange charges. It assists
in alleviating the transaction fees and acquirer charges that make
ordinary small value transactions uneconomical for merchants.
[0066] Further, the token of an embodiment of the present invention
may combine stored value transactions with conventional credit card
or debit card transactions. By way of an example, a chip, reader,
or other downstream switch or process, may route transactions based
on dollar amount, e.g., stored value for transactions of less than
$20, and normal credit/debit card process for transactions greater
than $20. The small value payments token may support both credit,
debit and/or other types of payments. For purchases larger than
$20, the checkout clerk or Point of Sale (POS) device may query the
customer as to which method to use or a method may be selected
based on predetermined rules. Consumers may be entitled to full
service for larger transactions. Alternatively, consumers may
designate which transactions will use the stored value account
based on the merchant, type of merchant and/or other predefined
criteria. Other systems and processes may also be implemented.
[0067] According to an embodiment of the present invention, though
the cash replacement market should be profitable, additional
benefits may accrue to issuers of tokens that can support the full
spectrum of payment sizes. Transportation tokens, which are also
broadly useful to make general small value payments, may be readily
accessible to consumers. According to an embodiment of the present
invention, those tokens may also support credit, debit and/or other
transactions, thereby providing issuers with added benefits.
Consumers who use tokens for multiple daily small value payments,
may also be likely to use the token for larger purchases out of
convenience and habit, providing issuers with a tremendous lift in
share-of-wallet.
[0068] In addition, tokens may be made more secure than magnetic
stripe cards, and in some embodiments, as secure as smart cards.
However, readers may be less costly to purchase and maintain than
smart card readers. By fielding tokens capable of large payments,
card associations and issuers may build protection against the time
when magnetic stripe cards are no longer secure from fraud.
[0069] Tokens having both small and large value tokens may increase
issuer protection against fraud. According to an embodiment of the
present invention, because consumers will take the risk of loss for
stored value, consumers will have strong inducement quickly to
report lost tokens, permitting issuers more quickly to limit their
liability. Further, there may be a tax incentive for employers to
provide employees with mass transit vouchers. A token of an
embodiment of the present invention may be an addition to a
pay-roll card offering, and/or for unbankables.
[0070] FIG. 3 is an exemplary flowchart for registering a token
according to an embodiment of the present invention. At step 310, a
user may initiate registration of a token. At step 312, one or more
protocols may be identified for one or more chips for supporting
various transactions made with the token. At step 314, one or more
protocol conditions may be identified. At step 316, one or more
funding accounts associated with the protocols may be identified.
At step 318, one or more funding conditions may be identified for
the funding account. At step 320, loyalty programs may be activated
and/or tracked. A user profile may be established for identifying
specific conditions, loyalty program details and/or other
preference data. At step 322, historical data may be tracked. While
the process illustrated in FIG. 3 discloses certain steps performed
in a particular order, it should be understood that the present
invention may be practiced by adding one or more steps to the
process, omitting steps within the process and/or altering the
order in which one or more steps are performed.
[0071] At step 310, a token may be registered or otherwise
activated. Activation of the token with multiple chips may include
transmitting a signal to a passive device, communicating with a
server, or activating the appropriate power source in an active
device. According to an embodiment of the present invention,
activation of the token, such as a RFID device, may occur when a
server recognizes the RFID device, thereby enabling purchase
transactions and other transactions to be performed. The token
and/or each individual chip may be associated with a unique
identifier.
[0072] At step 312, one or more protocols may be identified for one
or more chips. For example, a first protocol may involve a stored
value account associated with a mass transit entity. A second
protocol may involve a network based protocol for making
general-purpose purchases at various merchants or other designated
entities. Additional other protocols may be identified. At step
314, protocol conditions may be identified. Protocol conditions may
identify which transactions are routed to which protocols. For
example, mass transit purchases will be routed to the stored value
account. Merchant purchases may be routed to the network based
protocol. Other merchants or types of purchases may be routed to a
second network based protocol or other protocol.
[0073] At step 316, one or more funding accounts may be identified.
For the network protocol, a plurality of different funding accounts
may be established. For example, a stored value account, a
financial institution account, debit account, credit card account
and/or other types of accounts may be associated with the
appropriate chip or chips. The one or more funding accounts may be
associated with the chip or chips and the unique identifier. By
associating an account with the device and the unique identifier,
the account may be used to perform a purchase transaction.
[0074] At step 318, the terms/conditions of the funding accounts
may be established. Terms may include permissions to use the
account, the amount of the purchase transaction authorization for
the account, the priority of the account if more than one financial
account is associated with the chip, and/or other terms for
performing the purchase transaction. By way of illustrative
example, terms for a particular account may include authorizing
purchase transactions under a particular amount without requiring a
validation or confirmation. By way of another illustrative example,
certain accounts may not be valid at certain times of the day or
for certain merchants or types of merchants. By way of a further
illustrative example, one account may be set as a default, such
that unless otherwise selected by the user of the token, the
default financial account will be used to perform the purchase
transaction. Other terms may also be applied. By way of another
example, certain transaction types may be performed using a
specific account (e.g., under $50) or those made at specific
merchants or types of merchants (e.g., purchases at gas stations).
In addition, the account may be a chip purse stored value account
which may be used for small purchase transactions.
[0075] The information may be stored in a database, such as an
Account Database. Other optional information may be associated with
the chip or chips. For example, at step 320, one or more loyalty
programs may be activated and/or tracked. At step 322, historical
data may be tracked. For example, an audit chip resident on the
token may obtain activity information for the other chips.
[0076] FIG. 4 is an exemplary flowchart for enabling a user to make
a purchase transaction with a token according to an embodiment of
the present invention. At step 410, a transaction may be initiated
with a token. At step 412, the token may be read by a reader or
other device at the merchant location. At step 414, an appropriate
protocol may be identified based on predetermined conditions
associated with the transaction, user selection or other event. The
user may be authenticated. Depending on the transaction and/or
predetermined conditions, the transaction may be routed to an
appropriate protocol. For example, at step 416, the transaction may
be routed to a stored value account associated with a local system
when the transaction is performed at step 417. At step 418, the
transaction may be routed to a network. In addition, transactions
may be routed to other protocols, as illustrated by step 420. If
the transaction is routed to a network, an appropriate account may
be identified, at step 422. At step 424, a funding condition may be
identified. This information may be provided by a user profile. At
step 426, the transaction may be authenticated. At step 428, the
transaction may be funded by the appropriate account. At step 430,
various data may be collected. This data may be tracked for
historical data collection, consumer behavior, loyalty programs
and/or other purposes. At step 432, appropriate loyalty awards
and/or other incentives may be applied. While the process
illustrated in FIG. 4 discloses certain steps performed in a
particular order, it should be understood that the present
invention may be practiced by adding one or more steps to the
process, omitting steps within the process and/or altering the
order in which one or more steps are performed.
[0077] At step 410, a user may make a transaction with a token at a
merchant location, or other point of sale, including telephone
order, mail order, internet order, etc. At step 412, the token may
be scanned or otherwise read by a reader. Activation of an device
may include transmitting a signal to a passive device, activating
at a server or activating the appropriate power source in an active
device. In another example, a unique identifier associated with the
token may be conveyed or transmitted.
[0078] At step 414, the token may identify and/or authenticate the
user and determine an appropriate protocol for the transaction.
According to an embodiment of the invention, different readers may
operate on the same frequency, but use different protocols. Each
chip located on a token may be programmed in a specific protocol,
and the reader may be programmed to determine what protocol is
being used and process the information accordingly. The conditions
for routing a transaction to a specific protocol may be
predetermined or selected by the user at the point of purchase. For
example, the transaction may be routed to a stored value account
(e.g., mass transit, etc.), at step 416. At step 417, an
appropriate transaction may be performed, such as debiting a
purchase amount from the stored value account. Another transaction
may be routed to a network protocol, at step 418. Other protocols
may also process transactions, as shown by step 420.
[0079] For a network protocol transaction, one or more accounts for
funding the transaction may be identified, at step 422. The one or
more accounts may be associated with one or more chips located on
the token. Various types of accounts may be implemented, including
stored value accounts, financial institution accounts, debit
accounts, credit card accounts, lines of credit, etc. At step 424,
funding conditions may be applied. This information may be located
on a user profile associated with the appropriate chip. In
addition, the user may select an appropriate account at the point
of purchase. Other conditions and/or events may determine an
appropriate account. For certain transactions, an appropriate
funding account may be applied. Various conditions and/or terms may
be applied. For example, for transactions below a predetermined
purchase amount, a first account may be appropriate. In another
example, transactions from a particular merchant, group of
merchants, and/or merchant type may be funded from an identified
account. In another example, the transaction may be funded by
multiple accounts--where the first $20 is applied to a first
account and the remaining amount is applied to a second account.
Various other implementations may be realized.
[0080] At step 426, the purchase transaction may be authorized
and/or authenticated. The token of an embodiment of the present
invention may be used with or without authentication, such as PIN,
bio-metric, password or other confirmations. For lower value
transactions, a user may choose the convenience of not requiring
authentication. For larger transactions, the user may choose to
require some form of authentication. Other conditions may also be
defined for applying or not applying various forms of
authentication. Authentication may include inputting a PIN,
providing bio-metric information, inputting a password, or other
manner of authentication. Once authenticated, authorization may
include confirming that a purchase transaction has been approved.
According to an embodiment of the present invention, authorization
may be completed when the token is authorized at the server, such
as Central Controller 130. As described previously in reference to
FIG. 2, Authentication List 238 may determine if Reader 112 and/or
Token 102 is authentic and permitted to perform transactions. An
authentication list may be accessed to ensure that the token is
allowed to perform a transaction. The authentication list may also
ensure that the reader is allowed to access the central controller.
According to an embodiment of the present invention, the
authentication list may also include a list of authorized readers
and register/readers that are permitted to access the central
controller.
[0081] In the process of seeking authorization for a particular
transaction, the account specified to be debited may not have
adequate resources to cover the transaction. In that event, whether
the account was funded on a pre-pay or post-pay basis, the Central
Controller 130 may by prior arrangement, automatically top-up the
account with additional resources by seeking additional
credit/funds from a specified account, seek funds from any other
default funding/credit accounts, or reject the transaction. Other
processes may also be used.
[0082] At step 428, the transaction may be funded by the
appropriate account. Accounts associated with the chip may include
a financial account, a stored value account, a chip purse stored
value account, a credit card account or other type of account. If
only one account is associated with the device, the account is
charged for the purchase transaction. The account may be charged
using any conventional process, such as that used for credit card
and debit card transactions. Other manners for charging an account
may also be used.
[0083] At step 430, various data related to the transaction may be
collected. For example, historical transaction data may be stored
and compiled. Consumer behavior may be assessed through the
collection of data. At step 432, if the chip is associated with a
loyalty program or other incentive program, points or other credit
may be accumulated. Other options and personalized services may be
implemented.
[0084] At step 434, the purchase transaction is then finalized.
Finalizing the purchase transaction may include printing a receipt,
confirming that the transaction has been made, or other steps used
to finalize a transaction.
[0085] Various applications and implementations may be supported by
the various embodiments of the present invention. As discussed
above, a plurality of chips may be resident on a single token. For
example, two or more chips resident on a single token may operate
autonomously and independently. In this exemplary embodiment, any
deleterious interference between the two more chips may be
eliminated.
[0086] According to another exemplary embodiment, two or more chips
resident on a token may communicate and/or interact via a reader or
other similar device. For example, a token may have an associated
universal, network stored value account as well as proprietary
loyalty accounts. The reader may debit the stored value account and
further recognize the presence of the proprietary loyalty chip
where points or other credits may be applied.
[0087] According to another exemplary embodiment, two or more chips
resident on a token may communicate and/or interact over a network
connection, e.g. via a server link from a reader. In this example,
a transit reader may recognize that a transit chip purse is empty
(or at a predetermined low level or other condition). The transit
reader may address the network payment chip (or other account) and
further identify a top-up capability. The transit reader may then
launch a payment request to the appropriate network account. When
authorization is received, the reader may communicate with the
transit chip and refill the associated transit purse. Other actions
may be performed in a similar manner.
[0088] According to another exemplary embodiment, two (or more)
chips may be activated by a reader's transmissions, but communicate
directly, without involvement even with the reader. For example,
there are likely to be many untrustworthy readers that seek to
connect with tokens for transactions, tracking and/or other
activity. A token may include an audit chip that monitors activity
of the other chips on the token. For example, if activated by an
untrusted reader, the audit chip may record some or all
transactions between readers and chips on the token where such
transactions may be simply an unauthorized identification query. In
addition, the audit chip's record may be downloaded via a trusted
reader, transmitted to a network or other mechanism for
communicating information.
[0089] There may be circumstances that a user may use a generic
reader's transmissions to provide electrical power to permit a
passive chip to perform actions unrelated to the specific reader.
One example may include using a generic reader to permit a chip to
complete extensive computing required by public key infrastructure
(PKI). Other forms of computing or other actions may also be
performed.
[0090] A token will be accepted at any merchant that takes any type
of payments. In the simplest case, a consumer will simply bring the
token close to the reader at checkout. The reader will
automatically debit the payment account specified by the consumer.
Consumers may specify more than one payment mechanism for a
merchant. In that case, a merchant's payment wizard will select the
payment mechanism with the lowest merchant discount. If the
consumer has not specified a particular payment mechanism for a
merchant, the default payment method will be charged.
[0091] Online purchases may be possible when a computer is equipped
with a reader (e.g., RFID reader). The incremental cost of adding
that functionality to a personal computer ("PC") may be minimal.
With a widely deployed base of tokens, RFID enabled PCs can offer
very substantial benefits in addition to secure payments. PCs
equipped with readers (e.g., RFID readers) could be used to secure
data on the PC, to access secure networks, for VPNs, for remote
access, etc.
[0092] According to an embodiment of the invention, consumers may
be able selectively to impose additional security protections. A
PIN may be required for purchases at specific stores, or for
amounts larger than a specified ceiling. Consumers may also choose
to impose a daily or weekly maximum aggregate spending limit.
Subordinate tokens may be restricted to purchases from specific
stores, or for age appropriate materials (especially useful for
online purchases).
[0093] One aspect of the RFID functionality is their use for
personalization, as well as for heavier payments and
authorizations. Readers are not bound by the same constraints as
the passive RFID devices (size, cost, etc.). Typical RFID readers
will have some source of power and be connected to some device,
network, or system that takes advantage of the RFID validation,
e.g., POS, Electronic Point of Sale (EPoS), Electronic Cash
Register (ECR), fire wall, engine controller, physical lock to
premises, etc. The RFID reader may be equipped with an antenna
tuned to listen for faint signals at a specific frequency, e.g.,
134 kHz. More complex RF communications could simply be enabled
with software. The two-way, secure communication could use RF (with
the same frequency as the passive RFID device or a different one),
or other protocols such as Bluetooth or 802.11.
[0094] One manner for expanding the functionality of the passive
RFID device is to link its powers to an active device. Such devices
might include a wire line or cellular phone, computer, Blackberry,
PDA or other similar device (hereinafter also referred to as
"Active Communications Device"). Such Active Communications Devices
typically have power, or access to power, one or more
communications channels, a CPU that is much more powerful than the
passive RFID, memory that can be dynamically accessed, data entry
capability and a visual display. The passive RFID token that is
validated might be electrically connected to the Active
Communications Device; physically attached, but not electrically
connected, e.g. RFID chip embedded in the faceplate of a cell
phone; or, separate from the Active Communications Device. For
example, when an Active Communications Device is a mobile
telephone, an RFID device may be located in face plate of the
telephone. The RFID device may be a passive device, and the mobile
telephone may have an RFID reader. The mobile telephone then
communicates the necessary information. Alternatively, the RFID
device may be physically connected to the mobile telephone, such as
by electrical leads. The link between the RFID and the Active
Communications Device may be established at the manufacturer, or
later, by direct or indirect contact with registration authority,
or over a network. Other embodiments may also be used.
[0095] Once an authenticated passive RFID is recognized and
accepted by an RFID reader, the holder of the RFID device could
take advantage of that trusted authentication, to engage an active
device capable of more complex, secure communications. A key step
to achieve this result will be to transfer the passive RFID's
trusted validation, to a more capable communications device. There
are many different ways for that trust to be transferred, three
different examples are disclosed here.
[0096] While two examples for linking (e.g., by prior arrangement,
an authenticated passive RFID device to an Active Communications
Device) are disclosed below, it is understood that other examples
are also within the scope of an embodiment of the present
invention.
[0097] Just as a passive RFID device can be registered to enable
multiple payments modes (e.g., credit cards, debit and stored value
accounts, etc.), and other non-payment authorizations; RFID devices
can be securely linked to other devices, including Active
Communications Devices. By registering a passive RFID device with
an Active Communications Device's unique identifier, that Active
Communications Device can inherit all the authentication and
authorization capabilities of the passive RFID device. Thereafter,
the holder of a passive RFID device could use it wherever it is
convenient (e.g., where a merchant's POS is capable only of
recognizing a passive RFID device) and would also use the same set
of capabilities using his Active Communications Device to take
advantage of less limited reader capabilities where available.
[0098] To establish a link between a passive RFID device and an
Active Communications Device that can be trusted by RFID readers
may be somewhat more complex. The Active Communications Device may
securely share its secret with the passive RFID device in a manner
similar to the way automobile engine controllers instantiate tokens
and in a carefully controlled circumstance. The passive RFID device
subsequently may communicate to a reader both the RFID device's
unique identifier number and the secret shared with the Active
Communications Device. The RFID reader may then trust
communications with the Active Communications Device that
identified itself with the same RFID secret. Alternatively, the
Active Communications Device could be certified by a payment
authority entrusted to pass RFID information for payment
authorization.
[0099] The RFID reader validates and then trusts the authenticated
passive RFID device. The authenticated passive RFID device
separately communicates to the RFID reader a secret. The RFID
reader then can trust the Active Communications Device and knows
that the authenticated passive RFID device's secret. For example, a
controller may be activated only for `friendly` tokens that know
its secret. For example, controller A (the controller) shares its
secret with token B (the token). Because controller A controls
distribution of its secret, controller A will trust all token Bs
that know its secret. Based on the security model, the trust can be
time limited (e.g. where the RFID reader will recognize the Active
Communications Device only when the authenticated passive RFID
device and C are used contemporaneously), or not. In addition, the
reverse mechanism can also work, where the authenticated Active
Communications Device is linked to a passive RFID device. In a
manner similar to the engine controller, an Active Communications
Device might share its secret with the passive RFID device.
[0100] Linkage of a passive RFID device to an Active Communications
Device by prior arrangement may be useful when that linkage is
intended to be persistent. There are circumstances where such
persistence is not desirable. For example, suppose in the future a
driver rents a car and wishes to use his passive RFID token to pay
tolls. Rental cars are used by many different people, persistent
linkage of RFID devices personal to drivers present problems for
such temporary connections. One means to provide for payment of
tolls would be to take advantage of the driver's payment
capability, by simply using a car's transmitter to broadcast that
capability to the toll collectors. The system would work so long as
the car validates the drivers ability to pay and is trusted as a
payment agent or the transmitter can directly pass the driver's
credentials.
[0101] According to an embodiment of the invention, the systems and
processes described in this invention may be implemented on any
general or special purpose computational device, either as a
standalone application or applications, or even across several
general or special purpose computational devices connected over a
network and as a group operating in a client-server mode. According
to another embodiment of the invention, a computer-usable and
writeable medium having a plurality of computer readable program
code stored therein may be provided for practicing the process of
the present invention. The process and system of the present
invention may be implemented within a variety of operating systems,
such as a Windows.RTM. operating system, various versions of a
Unix-based operating system (e.g., a Hewlett Packard, a Red Hat, or
a Linux version of a Unix-based operating system), or various
versions of an AS/400-based operating system. For example, the
computer-usable and writeable medium may be comprised of a CD ROM,
a floppy disk, a hard disk, or any other computer-usable medium.
One or more of the components of the system or systems embodying
the present invention may comprise computer readable program code
in the form of functional instructions stored in the
computer-usable medium such that when the computer-usable medium is
installed on the system or systems, those components cause the
system to perform the functions described. The computer readable
program code for the present invention may also be bundled with
other computer readable program software. Also, only some of the
components may be provided in computer-readable code.
[0102] Additionally, various entities and combinations of entities
may employ a computer to implement the components performing the
above-described functions. According to an embodiment of the
invention, the computer may be a standard computer comprising an
input device, an output device, a processor device, and a data
storage device. According to other embodiments of the invention,
various components may be computers in different departments within
the same corporation or entity. Other computer configurations may
also be used. According to another embodiment of the invention,
various components may be separate entities such as corporations or
limited liability companies. Other embodiments, in compliance with
applicable laws and regulations, may also be used.
[0103] According to one specific embodiment of the present
invention, the system may comprise components of a software system.
The system may operate on a network and may be connected to other
systems sharing a common database. Other hardware arrangements may
also be provided.
[0104] Other embodiments, uses and advantages of the present
invention will be apparent to those skilled in the art from
consideration of the specification and practice of the invention
disclosed herein. The specification and examples should be
considered exemplary only. The intended scope of the invention is
only limited by the claims appended hereto.
[0105] While the invention has been particularly shown and
described within the framework of performing purchase transactions
using a token from an automobile, it will be appreciated that
variations and modifications can be effected by a person of
ordinary skill in the art without departing from the scope of the
invention. For example, one of ordinary skill in the art will
recognize that various types of tokens may be used to perform
purchase transactions and that other types of transactions may also
be performed using a token. Furthermore, one of ordinary skill in
the art will recognize that such processes and systems do not need
to be restricted to the specific embodiments described herein.
* * * * *