U.S. patent application number 10/968401 was filed with the patent office on 2005-04-21 for method for customizing payment card transactions at the time of the transactions.
Invention is credited to Anderson, Roy L., Bryant, William R. JR., Wong, Jacob Y..
Application Number | 20050086177 10/968401 |
Document ID | / |
Family ID | 34427183 |
Filed Date | 2005-04-21 |
United States Patent
Application |
20050086177 |
Kind Code |
A1 |
Anderson, Roy L. ; et
al. |
April 21, 2005 |
Method for customizing payment card transactions at the time of the
transactions
Abstract
A user can customize use of a payment card, which can be an
electronic card, by selecting a customization variable for any
given transaction. The customization variable involves at least one
of the following steps: (1) customizing generation of a one-time
card number; (2) customizing a user identifier; or (3) inclusion of
a customization variable with information transmitted to a
verification agency for validation of the given use. Multiple
payment card transactions can be processed differently depending
upon which customization variable is chosen for a given
transaction. Different customization variables can be used for
different accounts, different types of transactions, or to classify
the transactions. A user can receive one bill, or multiple bills.
Different levels of privacy can be accorded to transactions that
use different customization variables. A user may pay the issuer
for increased security, or the user may be paid by the issuer to
allow transaction data to be distributed to third parties.
Inventors: |
Anderson, Roy L.; (Glendale,
CA) ; Bryant, William R. JR.; (Manasas, VA) ;
Wong, Jacob Y.; (Goleta, CA) |
Correspondence
Address: |
Roy L. Anderson, Esq.
LAW OFFICES OF ROY ANDERSON
1010 North Central Avenue
Glendale
CA
91202
US
|
Family ID: |
34427183 |
Appl. No.: |
10/968401 |
Filed: |
October 18, 2004 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10968401 |
Oct 18, 2004 |
|
|
|
09960714 |
Sep 21, 2001 |
|
|
|
6805288 |
|
|
|
|
09960714 |
Sep 21, 2001 |
|
|
|
09667081 |
Sep 21, 2000 |
|
|
|
09960714 |
Sep 21, 2001 |
|
|
|
09667089 |
Sep 21, 2000 |
|
|
|
09667089 |
Sep 21, 2000 |
|
|
|
09659434 |
Sep 8, 2000 |
|
|
|
09659434 |
Sep 8, 2000 |
|
|
|
09640044 |
Aug 15, 2000 |
|
|
|
09640044 |
Aug 15, 2000 |
|
|
|
09619859 |
Jul 20, 2000 |
|
|
|
09619859 |
Jul 20, 2000 |
|
|
|
09571707 |
May 15, 2000 |
|
|
|
6592044 |
|
|
|
|
Current U.S.
Class: |
705/64 |
Current CPC
Class: |
G06Q 20/3674 20130101;
G06Q 20/4093 20130101; G06K 19/06206 20130101; G06Q 20/105
20130101; G06Q 20/341 20130101; G06Q 20/10 20130101; G06Q 20/3415
20130101; G06Q 20/3576 20130101; G07F 7/1008 20130101; G06Q 20/382
20130101; G06K 19/06196 20130101; G06Q 20/206 20130101; G06Q 20/383
20130101 |
Class at
Publication: |
705/064 |
International
Class: |
H04L 009/00 |
Claims
What is claimed is:
1. A method for allowing customized use of an electronic card
having a card number that varies with each use, comprising the
steps of: (1) allowing a user to customize either generation of a
one-time card number or a user identifier; (2) generating a user
one-time card number through use of a card number generator; (3)
submitting the user one-time card number and the user identifier to
a verification agency for validation; and (4) verifying that the
one-time card number is valid.
2. A method as recited in claim 1, wherein the electronic card is a
payment card and the one-time card number is a one-time payment
card number.
3. A method as recited in claim 2, wherein the card number
generator generates a new card number by executing an algorithm
that uses a selected user key to generate the new card number.
4. A method as recited in claim 3, wherein the user can customize
generation of the one-time card number by choosing either a first
user key or a second user key as the selected user key, and wherein
the algorithm will generate a first one-time card number if the
selected user key is the first user key or a second one-time card
number if the selected user key is the second user key, the first
and the second one-time card numbers being different, but both
valid with the user identifier.
5. A method as recited in claim 3, wherein the electronic card is
comprised of: a card base; a computer affixed to the card; an input
mechanism; a magnetic storage medium affixed to the card that can
be read by a standard magnetic stripe reader; an encoder for
generating a data packet that is stored in a designated portion of
the magnetic storage medium and is readable by a standard magnetic
stripe reader; and a power source for supplying power to the
computer and the encoder; wherein the electronic card is sized such
that the magnetic storage medium can be read by the standard
magnetic stripe reader.
6. A method as recited in claim 5, wherein the magnetic storage
medium is a magnetic stripe.
7. A method as recited in claim 6, wherein the user identifier is
stored in the magnetic stripe.
8. A method as recited in claim 7, wherein the user identifier is
stored in a second track of the magnetic stripe with the user
one-time card number.
9. A method as recited in claim 8, wherein the data packet is
comprised of the user one-time card number.
10. A method as recited in claim 9, wherein the data packet is
further comprised of the user identifier.
11. A method as recited in claim 10, wherein the encoder generates
the data packet by creating flux reversals in ferromagnetic
particles contained in the magnetic stripe.
12. A method as recited in claim 5, wherein the user can change the
user identifier through use of a special function switch.
13. A method as recited in claim 5, wherein the user can change the
user identifier through use of a special function code input to the
computer.
14. A method for allowing customized use of an electronic card
having a card number that varies with each use, comprising the
steps of: (1) allowing a user to select a customization parameter
to customize a given use of the electronic card by at least one of
the following steps: (a) customizing generation of a one-time card
number; (b) customizing a user identifier; or (c) inclusion of a
customization variable with information transmitted to a
verification agency for validation of the given use; (2) generating
a user one-time payment card number through use of a card number
generator; (3) submitting the user one-time payment card number and
the user identifier to a verification agency for validation, and,
if the user has selected step (1)(c), including the customization
variable with the submission for the given use; and (4) verifying
that the one-time payment card number is valid for the given
use.
15. A method as recited in claim 14, wherein the electronic card is
comprised of: a card base; a computer affixed to the card; an input
mechanism; a magnetic storage medium affixed to the card that can
be read by a standard magnetic stripe reader; an encoder for
generating a data packet that is stored in a designated portion of
the magnetic storage medium and is readable by a standard magnetic
stripe reader; and a power source for supplying power to the
computer and the encoder; wherein the electronic card is sized such
that the magnetic storage medium can be read by the standard
magnetic stripe reader.
16. A method as recited in claim 15, wherein the magnetic storage
medium is a magnetic stripe.
17. A method as recited in claim 16, wherein the user identifier is
stored in the magnetic stripe.
18. A method as recited in claim 17, wherein the user identifier is
stored in a second track of the magnetic stripe with the user
one-time payment card number.
19. A method as recited in claim 18, wherein the data packet is
comprised of the user one-time payment card number.
20. A method as recited in claim 19, wherein the data packet is
further comprised of the user identifier.
21. A method as recited in claim 15, wherein the data packet is
further comprised of the customization variable.
22. A method as recited in claim 16, wherein the data packet is
further comprised of the customization variable.
22. A method as recited in claim 17, wherein the data packet is
further comprised of the customization variable.
22. A method as recited in claim 18, wherein the data packet is
further comprised of the customization variable.
23. A method for processing a plurality of payment card
transactions based upon a user's selection of a customization
variable for each of the transactions, comprising the steps of: (1)
establishing a plurality of handling options between a money source
and the user; (2) providing the user with a card number generator;
(3) allowing the user to complete a plurality of payment card
transactions within a time period in accordance with the following
steps: (a) allowing the user to select a customization parameter to
customize a given use of the card number generator by at least one
of the following steps: (i) customizing generation of a one-time
payment card number; (ii) customizing a user identifier; or (iii)
inclusion of a customization variable with information transmitted
to a verification agency for validation of the given use; (b)
generating a user one-time payment card number through use of the
card number generator; (c) verifying the validity of the given use
by submitting the user one-time payment card number and the user
identifier to a verification agency for validation, and, if the
user has selected step (3)(a)(iii), including the customization
variable with the submission; and (d) repeating steps (a) through
(c) at least once within the time period; and (4) processing each
of the plurality of payment card transactions in accordance with
one of the plurality of handling options based upon the
customization parameter selected for each of the plurality of
payment card transactions.
24. A method as recited in claim 23, wherein the card number
generator is included within an electronic payment card.
25. A method as recited in claim 24, wherein the electronic payment
card is comprised of: a card base; a computer affixed to the card;
a keypad for providing input to the computer, the keypad having ten
numeric keys and at least one special function key that are
touch-activated; a magnetic storage medium affixed to the card that
can be read by a standard magnetic stripe reader; an encoder
controlled by the computer for generating a data packet that is
stored in a designated portion of the magnetic storage medium; and
a power source for supplying power to the computer and the encoder;
wherein the electronic card is sized such that the magnetic storage
medium can be read by a standard magnetic stripe reader.
26. A method as recited in claim 23, wherein the first and the
second handling options are mechanisms to bill two separate
accounts.
27. A method as recited in claim 26, wherein the user is sent a
single bill for charges to the two separate accounts.
28. A method as recited in claim 27, wherein one of the accounts is
established with a first money source and the second account is
established with a second money source that is different from the
first money source.
29. A method as recited in claim 26, wherein one of the accounts is
a credit account and the second account is a debit account.
30. A method as recited in claim 26, wherein the user is sent a
first bill for the first account and a separate bill for the second
account.
31. A method as recited in claim 23, wherein the first and the
second handling options are a first and a second mechanism for
dealing with distribution of information concerning the plurality
of payment card transactions.
32. A method as recited in claim 31, wherein the first mechanism
restricts the distribution from the money source to a third party
of information relating to any payment card transaction in which
the user payment card number was generated by use of the first user
key.
33. A method as recited in claim 31, wherein the first mechanism
restricts the distribution from the money source to the second
entity of personal information of the user relating to any payment
card transaction in which the user payment card number was
generated by use of the first user key.
34. A method as recited in claim 32, wherein the user provides the
money source with consideration for use of the first mechanism.
35. A method as recited in claim 31, wherein the second mechanism
permits the distribution from the money source to a third party of
information relating to any payment card transaction in which the
user payment card number was generated by use of the second user
key.
36. A method as recited in claim 35, wherein the second mechanism
permits the distribution from the money source to the second entity
of personal information of the user relating to any payment card
transaction in which the user payment card number was generated by
use of the second user key.
37. A method as recited in claim 35, wherein the money source
provides the user with consideration for use of the second
mechanism.
38. A method as recited in claim 23, wherein the first and the
second handling options provide a mechanism for classifying the
nature of the plurality of payment card transactions.
39. A method as recited in claim 38, wherein the first handling
option is used for business transactions and the second handling
option is used for personal transactions.
40. A method as recited in claim 23, wherein the first and the
second handling options provide a mechanism for identifying either
a first user or a second user as the user.
41. A method as recited in claim 40, wherein approval of a payment
card transaction for the first user is subject to different
restrictions than approval of a payment card transaction for the
second user.
42. A method as recited in claim 23, wherein the first and the
second handling options provide a mechanism for controlling what
information is reported about the plurality of payment card
transactions in a billing statement.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] The present application is a continuation application of
U.S. patent application Ser. No. 09/960,714, filed Sep. 21, 2001,
which was a continuation-in-part application of U.S. application
Ser. Nos. 09/667,081 and 09/667,089, filed Sep. 21, 2000, which are
continuation-in-part applications of U.S. Ser. No. 09/659,434,
filed Sep. 8, 2000, which is a continuation-in-part of U.S. Ser.
No. 09/640,044, filed Aug. 15, 2000, which is a
continuation-in-part of U.S. Ser. No. 09/619,859, filed Jul. 20,
2000, which is a continuation-in-part of U.S. Pat. No. 6,592,044,
all of which disclosures are specifically incorporated herein by
reference. The present application is also related to U.S. patent
application Ser. Nos. 09/667,835, 09/667,089, and 09/667,082, all
of which were filed on Sep. 21, 2000, and all of which are
specifically incorporated herein by reference. The present
application continues the subject matter previously set forth in
U.S. Ser. No. 09/667,038.
FIELD OF THE INVENTION
[0002] The present invention is in the field of methods for making
payments through payment cards.
BACKGROUND OF THE INVENTION
[0003] Three forms of money in widespread use today throughout the
world are cash, checks and payment cards (debit or credit). Each
has distinct advantages, and distinct disadvantages. Cash is
readily accepted, easy to use and anonymous, but it does not earn
interest, it can be lost or stolen, and it is not always readily
accessible. Checks are not always accepted, but they offer many
advantages, since they do not have to be written until the time of
payment. However, they must be physically presented and they are
not anonymous. Payment cards are readily, but not always, accepted,
and they offer many advantages over checks. If the card is a credit
card, payment can be deferred, but the transaction is not
anonymous. If the card is a debit card, payment has usually been
made prior to its use, but it is anonymous. Accordingly, it is
apparent that different types of money have different advantages to
different persons in different situations. This may be one reason
why all these forms of money are still in widespread use, and are
even used by the same persons at different times.
[0004] As society and international commerce have become more
dependent upon electronic transactions, money has also become more
electronic. Many attempts have been made to come up with suitable
forms of electronic money that mimic the physical world, or even
create new forms of electronic money. However, despite the enormous
need for such money, and efforts by some of the best minds and most
successful companies in the world, electronic money has suffered
many setbacks and been far slower to materialize than many had
hoped or predicted. The reasons are many and varied, but some of
the obvious reasons are security, ease of use/operation, and
unwillingness of the public and/or commerce to make radical changes
or embrace new technology and/or procedures. As a result, many
efforts, including several potentially promising efforts, have met
with failure.
[0005] Even though new forms of electronic money have been slow to
develop or gain widespread acceptance, electronic payments have
still moved forward. Many banks now offer some form of electronic
checking. And payment cards have been used for electronic
transactions in e-commerce and m-commerce (mobile commerce). Still,
there is widespread concern about the safety of such transactions,
and recent news stories have uncovered widespread fraudulent
activity associated with use of traditional credit card numbers in
e-commerce over the Internet. In addition, there is growing concern
about consumer privacy, or lack thereof, due to widespread
electronic profiling of consumers who make electronic payments.
[0006] Although the media has been quick to cover fraud associated
with use of credit cards over the Internet, it is often overlooked,
at least by the public and the media (but not the credit card
companies), that the majority of fraudulent activity concerning
credit cards is not associated with e-commerce activity. Most fraud
occurs in the "brick and mortar" world, and the numbers are
daunting. Despite many attempts to combat unauthorized or
fraudulent use of credit cards, it is estimated that credit card
fraud now exceeds hundreds of millions, if not several billion,
dollars per year. And this does not even count the cost of
inconvenience to consumers, merchants and credit card
issuer/providers, or the emotional distress caused to victims of
such fraud, or the cost to society in terms of law enforcement and
preventative activities.
[0007] Accordingly, there is a very real, long-felt need to reduce
the amount of fraudulent activity that is associated with credit
cards, and this need has only grown more acute as consumers and
commerce search for better ways to purchase and sell goods and
services via e-commerce and m-commerce. However, any solution needs
to be something that is acceptable to the public at large. It
should be easy to use. It should not be complicated or expensive to
implement. Preferably, it should fit within the existing
infrastructure, and not be something that requires a great deal of
educational effort, or a radical change in behavior or habits of
consumers. In other words, it should be user friendly, readily
understandable and something that does not require a completely new
infrastructure, which is a reason suggested by some as to why smart
cards have not been widely accepted in the United States.
[0008] In addition, it is highly desirable that any solution to
such problems be capable of widespread use, in many different
platforms, for many different applications.
[0009] In U.S. Pat. No. 5,956,699 issued in September of 1999, Wong
and Anderson were the first to introduce the methodology of a
system for secure and anonymous credit card transactions on the
Internet. This patent introduced a system which used an algorithm
to use one's own selected Personal Identification Number or PIN as
one's own de facto digital signature. The algorithm instructs the
cardholder how to insert one's PIN into one's valid credit card
number before using it for any transactions on the Internet. The
resultant scrambled up credit card number, which is tailored by the
algorithm to having the same number of digits as before, is
rendered useless on the Internet because the PIN insertion
algorithm is changed automatically after every transaction. This
methodology is not only capable of drastically reducing credit card
fraud on the Internet, it is also capable of safeguarding one's
anonymity, and thus privacy, in credit card purchases on the
Internet.
[0010] Since the issuance of U.S. Pat. No. 5,956,699, Wong and
Anderson have also invented an anonymous electronic card for
generating personal Coupons useful in commercial and security
transactions, as well as a method for implementing anonymous credit
card transactions using a fictitious account name. The present
invention is an extension of these prior inventions that seeks to
provide new methods for allowing a user to customize the use of
one-time unique numbers that can be used in credit card
transactions in the brick and mortar world, e-commerce, m-commerce
and in many other applications. Because the methodology is well
suited for use in hardware and software applications, it has
widespread applicability to many different types of transactions.
In addition, the present invention allows a user to categorize
individual transactions. This new advantage can be used to simplify
accounting procedures and consolidate multiple accounts in a single
payment credit card. It also opens up many previously unknown
possibilities, such as allowing a user to sell data, or protect
data, relating to a given transaction.
SUMMARY OF THE INVENTION
[0011] The present invention is generally directed to a method for
customizing payment card transactions by allowing a user of a
payment card to select a customization variable for any given
transaction involving use of the payment card. The customization
variable is submitted with the payment card number and a user
identifier to a verification agency for validation. The
customization variable may be used in a method for processing a
plurality of payment card transactions based upon the user's
selection of various customization variables. The present invention
is particularly well suited for use with electronic cards, but it
can also be used in any method that uses a card number generator to
generate a one-time card number.
[0012] In a first, separate aspect of the present invention, the
customization variable may involve customization of the generation
of a one-time payment card number. An example of one way in which
this can be done is to allow the user to choose either a first or a
second user key as the key that will be used by an algorithm of a
card number generator to generate the one-time payment card number.
The customization variable may also involve customization of a user
identifier associated with the one-time payment card number. An
example of one way in which this can be done is to allow the user
to choose either a first or a second identifier. The customization
variable may also involve inclusion of a customization variable
with the one-time payment card number and the user identifier when
they are submitted to the verification agency for validation.
[0013] In another, separate aspect of the present invention, an
electronic card with a magnetic storage medium and an encoder is
used, and the card is sized such that a standard magnetic stripe
reader can read the magnetic storage medium. It is especially
preferred that the magnetic storage medium be a magnetic stripe.
The encoder can store the one-time payment card number, the user
identifier or the customization variable on the magnetic stripe,
including its second track.
[0014] In still another, separate aspect of the present invention,
a plurality of handling options provide numerous options for
processing payment card transactions. The handling options can
include billing two separate accounts. The user can be sent a
single bill for charges to the two separate accounts, even if the
accounts are established with different entities, such as different
credit card companies or banks, or the user can be sent a first
bill for the first account and a separate bill for a second
account. One of the accounts can be a credit account and another
account can be a debit account.
[0015] In yet another, separate aspect of the present invention,
the plurality of handling options can provide a mechanism for
classifying the nature of the payment card transactions, such as
using a first handling option for business transactions and a
second handling option for personal transactions. They can also
provide different mechanisms for controlling access to information
concerning payment card transactions. One mechanism can be used to
implement restrictions on distribution of information relating to
payment card transactions or restrictions on distribution of
personal information of the user to second entities. The user can
be charged consideration for use of this mechanism. Another
mechanism can be used to permit distribution of information
relating to payment card transactions to third parties or permit
distribution of personal information of the user to second
entities. The user can be given consideration to use this
mechanism.
[0016] Accordingly, it is a primary object of the present invention
to provide a method for allowing a user to customize a given use of
a payment card.
[0017] This and further objects and advantages will be apparent to
those skilled in the art in connection with the detailed
description of the preferred embodiments set forth below.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0018] The present invention is related to U.S. Pat. Nos.
5,913,203, 5,937,394 and 5,956,699, the disclosures of which are
all specifically incorporated herein by reference.
[0019] The preferred embodiments of the present invention provide
an unprecedented opportunity to customize use and processing of
payment card transactions through use of one or more customization
variables.
[0020] In the context of this description, a one-time payment card
number refers to a payment card number of either a credit or a
debit card, generated in accordance with the present invention,
that is useful in financial transactions in the same fashion as a
traditional payment card number.
[0021] Like a traditional payment card number, a one-time payment
card number should be capable of being read by a standard magnetic
stripe reader when it is part of a physical card used in
traditional face-to-face transactions in which a user presents the
physical card to a merchant for payment. However, like traditional
payment card numbers, a one-time payment card number should also be
capable of being used in a Mail Order Telephone Order ("MOTO")
credit card transaction between the user and a merchant. Thus, like
a traditional payment card number, the one-time payment card number
should fit within, and work with, present platforms and protocols
for financial transactions involving payment cards, such as
traditional credit cards. This versatility allows the one-time
payment card number to be used with electronic cards, software
programs used in network applications, or telephones (especially
telephones used in what is now being referred to as m-commerce, or
mobile commerce).
[0022] A traditional payment card number can be characterized as
having three parts. First, there is a set of fixed variables. This
contains numerals that represent certain specified data fields,
such as a bank identifier and a month and year expiration date for
a given payment card. (The "bank" may be any "money source" as that
term has been defined in U.S. Pat. No. 5,937,394.) Second, there is
a set of variable variables. This contains numerals that will vary
for different payment cards issued by the same money source. In
other words, this is the portion of the card number that will be
specific to an individual entity or account for a given issuing
money source. Third, there is a check sum digit. The value of the
check sum digit is dictated by the other numerals in the card
number.
[0023] In the context of the present invention, a user one-time
payment card number is akin to a traditional payment card number,
with certain exceptions. In a traditional payment card number,
there might be a set of six fixed variables, followed by a set of
nine variable variables, followed by a check sum digit and another
set of four fixed variables representing the month and year. When a
user uses this traditional payment card number to complete a given
financial transaction, the transaction is always completed by using
the same twenty digits for the payment card number. By contrast, if
the user uses a one-time payment card number to complete any such
given financial transaction, the transaction will not be completed
by always using the same twenty digits for the payment card number.
Instead, the twenty digits of the one-time payment card number will
vary, and the degree to which they vary may depend upon user
selection of a customization parameter. In addition, because the
one-time payment card number varies with successive usage, the
check sum digit will not necessarily be the same with successive
usage, although it may be. Thus, the check sum digit must be
recalculated for each new one-time payment card number, and this is
why it shall be referred to as a "check sum variable" in the
context of a one-time payment card number according to the present
invention.
[0024] Another difference between a traditional payment card number
and a one-time payment card number is the way that a given
transaction using either number is validated by a verification
agency, which may be a money source or an entity who processes
payment card transactions. When a transaction involving a one-time
payment card number is processed, the verification agency must
verify that the one-time payment card number is valid for the user
identifier for the particular given transaction, as opposed to any
given transaction involving the user identifier. (The verification
process must take into account how selection of the customization
parameter may affect what the verification agency will receive for
verification. Additional details regarding procedures that can be
used to verify a one-time card number that can be customized are
set forth in U.S. Pat. No. 6,609,654.) This difference is a reason
why use of the one-time payment card number provides greater
security and anonymity than can be obtained through use of a
traditional payment card.
[0025] A card number generator generates a one-time payment card
number. As already described, this could be hardware or software,
but, in either case, it will preferably include a customer random
number generator and a customer sequence number. It is especially
preferred that the card number generator be part of an electronic
card, and that the electronic card be of the type described in U.S.
application Ser. No. 09/571,707 filed May 15, 2000 for Anonymous
Electronic Card for Generating Personal Coupons Useful in
Commercial and Security Transactions, or in U.S. application Ser.
No. 09/667,835.
[0026] Several different methods that can be used to generate a
one-time payment card number are described in detail in the
applications that are identified in the Cross Reference to Related
Applications above, and which are incorporated herein by reference,
so the details of those methods will not be repeated here. No
matter what method is used to generate a one-time payment card
number, two successive one-time payment card numbers should be
different. This can be accomplished by using a sequence number that
is changed after each one-time payment card number is generated.
(The present invention does not require that all theoretical
possibilities will result in different one-time payment card
numbers. Instead, it is preferred that there be a low probability
of occurrence of identical one-time payment card numbers
attributable to convergence of two different inputs leading to the
same result due to operations performed on the inputs by the
algorithm.)
[0027] The preferred embodiments allow a user to customize use of
an electronic card having a card number that varies with each use
by selecting at least one customization parameter to customize a
given use of the electronic card. There are three general
customization parameters that can be used to customize a given
use.
[0028] First, the user can customize generation of the one-time
card number. This can be done many different ways. An example of
one way in which it can be done is to customize selection of a
selected user key that is used to generate the one-time card number
as is explained in U.S. Pat. No. 6,609,654. Another way in which it
can be done is to include a customization variable in the one-time
card number, or as an input into the algorithm used to generate the
one-time card number.
[0029] Second, the user can customize the user identifier that is
used to validate the one-time card number. This can be done many
different ways. One way is to choose one of two or more preselected
identifiers as a selected user identifier. Another way is to modify
the user identifier. Still another way is to add a customization
variable, such as a numeric character, to the user identifier at a
preselected location.
[0030] Third, the user can include a customization variable with
information transmitted to a verification agency for validation of
the given use. Unlike the first two customization parameters, this
parameter relies upon use of an additional field of data collected
as part of the validation process for a given transaction, and this
may require a change in established validation protocols. It is
especially preferred that any such change be technically feasible
within the confines of hardware that is being used to process
traditional payment card transactions. In the context of an
electronic card with a magnetic stripe, this means that it is
preferred that the additional customization variable be stored in
the magnetic stripe, and it is especially preferred that it be
stored in the second track of the magnetic stripe. Additional
details regarding inclusion of a customization variable in a
magnetic stripe are set forth in U.S. Ser. No. 09/667,089.
[0031] Once it is recognized that using one or more of the
foregoing customization parameters will customize a given
transaction involving use of a one-time payment card number, and
that such customization will seamlessly allow a user to transmit
additional information to the money source processing such
transaction, without loss of desired security or anonymity, the
options for using such customization are virtually limitless.
[0032] After a one-time payment card number is validated for a
given transaction, the money source can determine what
customization parameter(s) was selected by the user for the given
transaction, which allows the money source to determine what
handling option should be used for the transaction involving the
one-time payment card number. (It also allows the money source to
determine what sequence number is associated with the one-time
payment card number, so that its records can be synchronized as
part of the validation process.)
[0033] One use of multiple handling options is to allow the money
source to access multiple accounts. For example, a user might use
one account as a credit card, and another account as a debit or
checking card. By choosing which account should be used for a given
transaction, the user could determine, at the point of use, whether
to charge the transaction, or have it deducted from an existing
account balance. The same idea could be used for multiple credit
cards, whether they are from the same issuer or different issuers,
or even different cards, such as Visa.RTM., MasterCard.RTM.,
Diner's Card.RTM.), Discover.RTM. or American Express.RTM.. In
addition, the user might elect to have separate billing statements
for separate accounts, or have all billing consolidated in a single
statement.
[0034] Another use of multiple handling options is to allow
identification of the person completing a transaction, or to allow
multiple persons access to a single account, or place different
restrictions on multiple persons on a single account. For example,
a single account might be opened with an issuing bank, but an
entire family might be authorized to use the account. Thus, a
father and a mother might have their own customization parameter, a
teenage child might have another customization parameter and a
lower authorized spending limit, and a preteen child might have a
fourth customization parameter, but only be authorized to engage in
a certain limited number of transactions per time period with a
maximum spending limit for each transaction. All the members of
this family could use the same card number generator embedded
within a PDA or mobile phone, or on a computer or in an electronic
card. At the end of a specified billing cycle, all transactions
completed by any member of this family could be consolidated in a
single bill, and that bill could indicate who spent what when
during the billing cycle, and what it was spent on.
[0035] Still another use of multiple handling options is to allow a
user to classify the nature of a particular transaction at the time
it is completed. For example, suppose an individual uses a single
credit card for personal expenditures and business expenditures. By
assigning one customization parameter to personal transactions, and
a second customization parameter to business transactions, the user
can simplify accounting for such transactions without the necessity
of having and carrying two separate cards. If desired, the user
could even receive two separate statements for such expenditures so
that the personal expenditures would not be discernable from the
documentation associated with the business expenditures. Individual
transactions could also be classified according to a preselected
set of criteria, and such criteria could be used in various
financial programs. For example, a user might include a code
classification system used in a money management system to create
various reports that itemize categories of spending or assist in
budgeting of finances.
[0036] Yet another use of multiple handling options is to allow a
user to preselect how a particular transaction is treated in a
subsequent bill. For example, an individual user might not want a
billing statement to include information about the identity of
second entities who provide certain goods or services, or when
transactions with such entities take place, but still want to have
the billing statement include such information for other
transactions. By selecting two different customization parameters
with these two different handling options, the user has the option
of controlling what information it receives in billing statements
about individual transactions.
[0037] Multiple handling options can also be used to guard privacy,
or for commercial purposes that do not presently exist. For
example, the user and the money source might enter into an
agreement about how, and under what circumstances, the money source
can distribute information about transactions of the user,
depending upon which customization parameter is used in a given
transaction. The agreement might provide different levels of
confidentiality, and set up different levels or types of
compensation tied to transactions falling within the different
levels for a given time period.
[0038] One level of confidentiality might restrict distribution of
any information concerning a transaction by the money source to any
third party. For example, a user might want strict confidentiality
of any transaction involving medical services, and would not want
the money source to divulge that information to any party unless
legally required to do so. Or, maybe the user does not want any
third party to learn of any transaction that exceeds a certain
dollar amount, for fear of a potential deluge of unsolicited
advertising. A user might pay a monthly fee for use of this option,
a transaction based fee, or no fee at all.
[0039] A second level of confidentiality might permit distribution
of any information concerning a transaction by the money source to
any third party. Such information is potentially valuable for
purposes of advertising, and creating profiles for targeted
marketing, and the money source might even pay the user for the
right to sell such information.
[0040] Other levels of confidentiality might fall between those
already noted. For example, a third level might permit distribution
of certain information concerning a transaction (such as the payee,
the amount of purchase, the date of purchase, and a profile of the
user), but restrict distribution of other information concerning a
transaction (such as the identity of the user). Another level of
confidentiality might restrict distribution of information
concerning a transaction to any third party, but allow the money
source to use such information for its own marketing efforts
directed to the user.
[0041] Although the foregoing detailed description is illustrative
of preferred embodiments of the present invention, it is to be
understood that additional embodiments thereof will be obvious to
those skilled in the art. Further modifications are also possible
in alternative embodiments without departing from the inventive
concept.
[0042] Accordingly, it will be readily apparent to those skilled in
the art that still further changes and modifications in the actual
concepts described herein can readily be made without departing
from the spirit and scope of the disclosed inventions as defined by
the following claims.
* * * * *