U.S. patent application number 12/495030 was filed with the patent office on 2009-10-22 for systems and methods for time variable financial authentication.
This patent application is currently assigned to Bank One, Delaware, National Association. Invention is credited to Glenn Cobourm EVERHART.
Application Number | 20090265275 12/495030 |
Document ID | / |
Family ID | 43617382 |
Filed Date | 2009-10-22 |
United States Patent
Application |
20090265275 |
Kind Code |
A1 |
EVERHART; Glenn Cobourm |
October 22, 2009 |
SYSTEMS AND METHODS FOR TIME VARIABLE FINANCIAL AUTHENTICATION
Abstract
The systems and methods of the invention provide a technique for
authenticating a finance related transaction. The method may
include providing a token which contains a token counter, the token
counter periodically advancing to generate a changing token value,
the token counter being synchronized to a base counter that
generates an authenticating value; transforming the token value
into a token output sequence using logic; and outputting at least
part of the token output sequence to an authenticating authority,
the authenticating authority having access to the authenticating
value. Further, the method includes the authenticating authority
verifying the validity of the transaction based on the token output
sequence and the authenticating value, from which the
authenticating authority obtains a verification sequence using the
logic, the verifying the validity including the authenticating
authority comparing the token output sequence to the verification
sequence to determine if there is a match between the token output
sequence and the verification sequence.
Inventors: |
EVERHART; Glenn Cobourm;
(Smyrna, DE) |
Correspondence
Address: |
HUNTON & WILLIAMS LLP;INTELLECTUAL PROPERTY DEPARTMENT
1900 K STREET, N.W., SUITE 1200
WASHINGTON
DC
20006-1109
US
|
Assignee: |
Bank One, Delaware, National
Association
Wilmington
DE
|
Family ID: |
43617382 |
Appl. No.: |
12/495030 |
Filed: |
June 30, 2009 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10419107 |
Apr 21, 2003 |
|
|
|
12495030 |
|
|
|
|
10105471 |
Mar 25, 2002 |
|
|
|
10419107 |
|
|
|
|
Current U.S.
Class: |
705/44 |
Current CPC
Class: |
G06Q 20/40 20130101;
G06Q 99/00 20130101; G06Q 20/40975 20130101; G06Q 20/341 20130101;
G06Q 20/401 20130101; G07F 7/1016 20130101; G06Q 20/388 20130101;
G06Q 20/0855 20130101; G06Q 20/00 20130101; G07F 7/1008 20130101;
G06Q 20/10 20130101; G06Q 20/382 20130101; G06Q 20/3674 20130101;
G06Q 20/08 20130101 |
Class at
Publication: |
705/44 |
International
Class: |
G06Q 20/00 20060101
G06Q020/00 |
Claims
1-29. (canceled)
30. A system comprising: a credit card providing a dynamically
generated number for authenticating a financial transaction; and a
device for reading the dynamically generated number from the credit
card and transmitting the dynamically generated number to an
authenticating authority for authenticating the financial
transaction.
31. The system of claim 30, further comprising: a token counter,
the token counter periodically advancing to generate a changing
token value, the token counter being synchronized to a base counter
that generates an authenticating value, wherein the dynamically
generated number is based at least in part on the token value.
32. The system of claim 30, further comprising communicating the
dynamically generated number wirelessly to the device.
33. The system of claim 30, further comprising communicating the
dynamically generated number to the device via a magnetic stripe of
the credit card.
34. The system of claim 30, wherein the credit card comprises a
battery.
35. The system of claim 30, wherein the credit card comprises a
processor for providing the dynamically generated number.
36. The system of claim 30, wherein the dynamically generated
number comprises at least a portion of a credit card number.
37. The system of claim 30, wherein the dynamically generated
number comprises an authentication code
38. The system of claim 30, wherein the credit card comprises a
clock, the clock used to enable generation of the dynamically
generated number.
39. The system of claim 38, wherein the clock is synchronized with
a clock of the authenticating authority.
40. The system of claim 30, wherein the credit card further
comprises a manual switch.
41. A method comprising: providing on a payment card a dynamically
generated number; displaying on a display of the payment card the
dynamically generated number; and a device for reading the
dynamically generated number from the credit card and transmitting
the dynamically generated number to an authenticating authority for
authenticating a transaction.
42. A machine readable medium, executable by a machine, that
includes program logic imprinted thereon for performing the method
comprising: providing on a payment card a dynamically generated
number; displaying on a display of the payment card the dynamically
generated number; and a device for reading the dynamically
generated number from the credit card and transmitting the
dynamically generated number to an authenticating authority for
authenticating a transaction.
Description
[0001] This application is a continuation-in-part application (CIP)
of U.S. application Ser. No. 10/105,471 filed Mar. 25, 2002, which
is incorporated herein by reference in its entirety.
BACKGROUND OF THE INVENTION
[0002] The present invention relates to systems and methods to
perform authentication of a transaction between a requesting
entity, in particular a customer, and an authenticating
authority.
[0003] Since the ancient invention of money, problems of
counterfeiting have existed. These problems have led to ever more
sophisticated measures to make the injection of false tokens,
representing value, from successfully being used in a transaction.
When in much more recent times credit cards were introduced, such
measures were incorporated. For example, in earlier times, only a
check digit formed by a secret algorithm was used to validate card
numbers, the number space being very sparsely occupied so that the
chance of finding a valid card number was relatively low. Then
thieves learned how to forge this digit. As a result secret
cryptography-based codes were added to the cards and checked by the
card issuer when charges to an account were made. These measures
have been useful in reducing fraud until recently.
[0004] However, with the practice of merchants storing card
numbers, including some of the codes, insecurely on the Internet,
there have been enough thefts of these numbers so that fraud is
becoming an increasingly difficult problem. Such fraud often occurs
in cases where the cards are not physically present. Fraud is
reduced somewhat where the card is physically present. That is,
credit cards contain fraud avoidance devices like holograms which
make counterfeiting of physical cards more difficult than
counterfeiting numbers off the cards.
[0005] Further, rules designed to prohibit storing the secret codes
have been ignored, even by large issuers and as a result a new way
to prevent fraudulent card use for remote customers is becoming
necessary. Smart cards using public key encryption have been
introduced, but these have met with little acceptance, due to their
need for gadgetry to read them, which is not widely available.
[0006] Known techniques in the area of time based codes reach back
to ancient times, when the password of the day was common in
military camps. The notion of using widely synchronized times to
control functions dates at least to the philosophy of Gottfried
Liebniz (coinventor of the calculus and a contemporary of Isaac
Newton). During World War II, codebooks valid for a particular day
were used by both sides. The use of time stamps in computer
communication is almost as old as computing. An example of their
use in authentication can be found in the Kerberos system (MIT,
1987). Financial transactions have been timestamped to avoid replay
problems also.
[0007] However, known techniques fail to provide an approach to
effectively use the advance of time as an effective authentication
mechanism. The present invention addresses the above, as well as
other problems, that are present in known techniques.
BRIEF SUMMARY OF THE INVENTION
[0008] The systems and methods of the invention provide a technique
for authenticating a finance related transaction. The method may
include providing a token which contains a token counter, the token
counter periodically advancing to generate a changing token value,
the token counter being synchronized to a base counter that
generates an authenticating value; transforming the token value
into a token output sequence using logic; and outputting at least
part of the token output sequence to an authenticating authority,
the authenticating authority having access to the authenticating
value. Further, the method includes the authenticating authority
verifying the validity of the transaction based on the token output
sequence and the authenticating value, from which the
authenticating authority obtains a verification sequence using the
logic, the verifying the validity including the authenticating
authority comparing the token output sequence to the verification
sequence to determine if there is a match between the token output
sequence and the verification sequence.
BRIEF DESCRIPTION OF THE DRAWINGS
[0009] The present invention can be more fully understood by
reading the following detailed description together with the
accompanying drawings, in which like reference indicators are used
to designate like elements, and in which:
[0010] FIG. 1 is a diagram showing a token in accordance with one
embodiment of the invention;
[0011] FIG. 2 is a block diagram showing a processing system in
accordance with one embodiment of the invention;
[0012] FIG. 3 is a block diagram showing an authenticating
authority in accordance with one embodiment of the invention;
[0013] FIG. 4 is a flowchart showing a "customer initiates
transaction" process in accordance with one embodiment of the
invention;
[0014] FIG. 5 is a flowchart showing the "perform authentication
process" in accordance with one embodiment of the invention;
[0015] FIG. 6 is a flowchart showing the "perform verification
process on the transaction" step of FIG. 5 in accordance with one
embodiment of the invention;
[0016] FIG. 7 is a flowchart showing the "calculate `verification
sequence` based on device number and time of transaction" process
of FIG. 6 in accordance with one embodiment of the invention;
[0017] FIG. 8 is a flowchart showing the "perform alternative
processing to further process authorization" step of FIG. 6 in
accordance with one embodiment of the invention;
[0018] FIG. 9 is a diagram showing a token in a flashlight in
accordance with one embodiment of the invention; and
[0019] FIG. 10 is a block diagram showing a token using a
twenty-four hour clock in accordance with one embodiment of the
invention.
DETAILED DESCRIPTION OF THE INVENTION
[0020] Hereinafter, features in accordance with various embodiments
of the invention will be described. As used herein, any term in the
singular may be interpreted to be in the plural, and alternatively,
any term in the plural may be interpreted to be in the
singular.
[0021] The present invention supplies a display on a consumer
device, in accordance with one embodiment of the invention. The
display displays an authentication code that varies with time. The
"time" is synchronized to a known base time. An authenticating
authority, such as the issuer for credit cards for example, can
determine whether the correct code is being sent to it for a
particular consumer device and for a particular transaction time.
The time variability is obscured by a secret process on the
consumer device to prevent those not in possession of the secret
process from figuring out the code sequence. As a result, the
authenticating authority can decide whether the requested
transaction comes from a valid source. Because the display number
is variable, it cannot be recorded on the Internet or elsewhere in
a form useful for theft, save for very limited durations. Further
such recorded numbers cannot be used to aid in impersonating a
holder of a consumer device, e.g., a credit card, for purposes of
identity theft. Widespread use of this invention will make
telephone, network, or other remote commerce safer for all
involved.
[0022] The token, in accordance with one embodiment of the
invention, may be issued by an authenticating authority. An
"authenticating authority" as used herein means either a central
authority or a distributed authority, for example. The
authenticating authority is capable of deciding whether to
authorize transactions where a token is provided as a way to check
the validity of authorizations, i.e., to permit them. The
authenticating authority possesses authority to perform
transactions in the scope of the invention including authority to
effect a payment or authorize some other financial or
financial-related transaction
[0023] In accordance with one embodiment of the invention, the
invention uses what might be characterized as a token. The token is
used to indicate authority to perform transactions. The token
includes a token clock or token counter that can maintain
synchronization with a reference clock, i.e., a base counter,
during the lifetime of the token. This synchronization might be
maintained to within one or a few times the interval between
changes of identifier. In accordance with one embodiment of the
invention, this might include a counter which "ticks", i.e.,
changes value, one or a few times per day, for example.
[0024] Further, the token also includes a device or mechanism for
performing a secret transform on the clock value. In accordance
with one embodiment of the invention, this transformation might
also involve some other separately observable attribute of the
token, such as the credit card number or a cellular phone number.
The token uses the secret transform, which is not available to the
token holder, but that is reproducible by an authenticating
authority. Further, the secret may be different for every such
token so that if one is lost, only its secret is lost and other
tokens remain secure. The result of this transform, or part of the
result of the transform, is displayed by the token in such a way
that the displayed number can be read by a person or device, i.e.,
whatever might read the token, and transmitted to an authenticating
authority. Optionally, such an authority might demand that
additional memorized digits or some other identifying indicia be
supplied. This other indicia would further preclude use of a stolen
token. That is, the token as described herein may be used with any
other known authentication technique, as desired.
[0025] In accordance with one embodiment of the invention, the
invention may be in the form so as to resemble a credit card. In
addition to the existing credit card fields, i.e., such as magnetic
stripe, for example, the card in accordance with one embodiment of
the invention is provided with a small processor and battery.
Further, the card includes a display that is visible on the card.
The display shows a few digits computed by a secret process on the
card. One such implementation might take a secret master key known
to the issuer and encrypt the card account number and expiration
with this master key. This diversified key then gets stored on the
card. Further, it is noted that the diversified key may be
different for each card.
[0026] As noted above, a clock computes a value that is transformed
and then displayed on the token. That is, the token first reads the
clock. The clock may be in the form of a counter of some type. For
example, the clock for a certain batch of credit cards might
advance based on the "hours since midnight on Jan. 1, 2001".
Further, the credit cards might be synchronized when issued. In
accordance with one embodiment of the invention, the initial value
generated by the clock is encrypted with the diversified key.
[0027] Further, only the low three decimal digits of the result are
displayed on the display, for example, in accordance with one
embodiment of the invention. Of course, it is appreciated that any
number of digits or selection of digits may be used, as is desired.
Physically, the invention will not pose a problem since there
currently exists flexible numeric displays much thinner than credit
cards. Should power be limited to drive such a display all the time
for a few years, a pushbutton or other switch might be present to
conserve power.
[0028] When the credit card holder of the token of the invention
makes a phone purchase or a net purchase, for example, he or she
then reads the display, and possibly recites some other digits she
is given to retain or memorize, in accordance with one embodiment
of the invention. For example, such other digits might be the fixed
CVV code (card validation value) on the back of the credit card.
The credit card holder then furnishes such information to a
merchant. The merchant then sends the information to the issuer, or
some other authenticating authority, for validation.
[0029] The authenticating authority receives the card number,
timestamp of the transaction, the token value and any added data.
The authenticating authority then derives the diversified key from
the card number and the master secret the particular card holds
and/or reads such information from storage. Further, the
authenticating authority checks the timestamp supplied for sanity,
i.e., performs a crude reasonableness test, and uses the timestamp
to derive the expected on-card clock value. The authenticating
authority then encrypts this clock value with the diversified key
and compares with the value supplied by the customer.
[0030] So as to avoid clock drift problems, the authenticating
authority may compare adjacent timeslot values for the comparison
operation. The authenticating authority then treats these adjacent
timeslot values as matches if one of them produces the same code as
was reported. The exact number of these comparisons depends on
expected maximum clock drift on card over the card lifetime, i.e.,
two to three years, for example, and may be varied as desired. For
example if it is expected the clock might drift under an hour, and
the clock changes value at midnight, then transactions after 11 PM
might be compared also with the next day's code, and similarly
transactions before 1 AM might be compared with the prior day's
code. In this way the card user never sees any effects of the clock
changing during his transaction.
[0031] In accordance with further aspects of the invention, as
noted above, a variety of other values may be supplied to a token
holder for use in authenticating transactions. These other values
can be recorded by the authenticating authority, or alternatively,
can be computed by such an operation as encrypting the card number
with a second secret key and using part of such resulting number.
This additional number is entered when making a transaction, along
with the displayed number, by the cardholder. Such added
information makes a token less useful to someone who stole the
token, as they would have to guess the correct check digits or
digits to fool the authenticating authority.
[0032] Further, it may be desirable for the values, which the token
displays, to be related mathematically to some separate observable
about the token, e.g., such as a cellular phone number. For
example, a second identifier built into the token may be used
mathematically for computation of the value displayed by the
display on the token. For tokens of the nature of credit cards, the
preferred implementation encrypts the card number. For tokens like
cell phones, there is a phone ID number which could be used. Such
practice would make it harder to forge tokens and will be found to
be of particular use for tokens in which the internal state cannot
be hidden well from users, i.e., the internal state meaning a cell
phone number, for example. In those cases where the internal state
cannot be hidden, it may be desired to use other identifiers, in
addition to the token value described herein, in order to gain the
added protection against fraud.
[0033] As described herein, one embodiment of the invention uses a
token resembling a credit card. However, any of a wide variety of
tokens may be used. Accordingly, as used herein a "token" means a
device which is presented or which bears information which is
presented by someone to set up a payment or similarly authorize
some financial or financial-related transaction. Accordingly, a
token of the invention may be in a wide variety of forms including
a token in the form of a credit card, or a gasoline-buying
"speedpass," for example. Accordingly, the token in the invention
may be in the form of credit card or debit card type device
possessing a display to be read by the cardholder, a credit card
type device having a magnetic strip, a radio frequency generating
device, an infrared signal generating device, an audio signal
generating device, a magnetic pattern generating device, and/or
other devices for outputting a data signal, i.e., such as a PDA
(personal digital assistance) outputting a data signal to a
computer or to a cashier, for example.
[0034] Further, as described herein, the token of the invention
generates a "display." As used herein, a "display" means whatever
sends information off the token for authentication checks. For
credit card type tokens, the display might be some visible display.
For other types of tokens, the display might be a radio or audio
signal, or magnetic patterns, for example. Accordingly, a "display"
in a token of the invention may illustratively be an LED (light
emitting diode), an LCD (liquid crystal display), a magnetic strip,
a radio frequency signal, an infrared signal, an audio signal, a
magnetic pattern, any other data signal, or any other technique
that may be used to convey information from the token to the
merchant, and in turn to the authenticating authority, for example.
As is appreciated, interim steps may be needed such as a human
cardholder reading the token output sequence and inputting the
token output sequence into a computer via a keyboard or to a human
merchant verbally, for example.
[0035] As described in various examples herein, the token of the
invention may be used in an interaction between a customer and a
merchant. However, the token of the invention may be used in a
variety of other situations between any of a wide variety of
entities. For example, the treasurer of a corporation might use the
token described herein to validate instructions to a bank, i.e.,
regarding a desired transaction, for example. Accordingly, the
token of the invention might be used in conjunction with
transactions between two banks or between any other institutions or
entities, for example.
[0036] The checking is preferably done off the token, although a
central authority's processing might be replaced in some cases by
some combination of other processing with perhaps other tokens
whose trust is established in other ways, e.g., such as biometrics,
for example, to allow local checking of such tokens for
authenticity. That is, the token of the invention may well be used
in conjunction with other authentication checks, such as simply a
credit card number, for example; and the authenticating authority
may be made up of separate portions so as to collectively perform
the verification process.
[0037] Hereinafter, further aspects of the systems and methods of
the invention will be described with reference to the drawings.
FIG. 1 is a diagram showing a token 100 in accordance with one
embodiment of the invention. As shown in FIG. 1, the token 100
includes a device number 110. While the token 100 is shown in FIG.
1 as being similar to a credit card, it is appreciated that the
token 100 may be in any of a wide variety of shapes and sizes.
[0038] As shown in FIG. 1, the token 100 also includes a magnetic
strip 120. Further, the token 100 includes a token output sequence
130, i.e., a number, that is presented by a display 132. The token
output sequence 130 is generated by the token 100 based on the
progression of a clock, as described above, for example. In order
to conserve energy of the token 100, the token output sequence 130
might not be displayed at all times. That is, the holder of the
token 100, in accordance with one embodiment of the invention,
presses the power display button 140 to display the token output
sequence 130. Such action results in a token output sequence being
displayed and visible to the holder. As shown in FIG. 1, the token
100 may also include a signature panel 150 to provide further
verification of the veracity of the holder.
[0039] To explain further, the token output sequence 130 is
generated using a token counter 160. The token counter 160
generates a token value. This token value is output within a token
100 to an encryption portion 170. The encryption portion 170
provides logic to process the token value to result in the token
output sequence 130. Both the progression of the token counter 160
as well as the logic used in the encryption portion 170 is known
and simulated by a verification or authenticating authority so as
to verify a transaction by the holder of the token 100.
[0040] The embodiment of FIG. 1 utilizes a display 132 to display
the token output sequence 130. However, is appreciated that the
token output sequence 130 may be displayed using a variety of
techniques, as is further described below. For example, the token
output sequence 130 might be input into the magnetic strip 120,
i.e., so as to be output to a merchant, for example.
[0041] FIG. 2 is a block diagram showing a processing system 10 in
accordance with one embodiment of the invention. As shown in FIG.
2, the processing system 10 includes a customer token 100. Further,
the processing system 10 includes a merchant entity 200 and an
authenticating authority 300.
[0042] In accordance with one embodiment of the invention, the
customer token 100 takes the form of the device shown in FIG. 1.
Further, the merchant entity 200 may be in any of a wide variety of
forms such as merchant disposed in a physical merchant store, an
internet entity, a receiver such as on a toll road device, a
telephone entity, as well as a wide variety of other arrangements,
as should be appreciated. Further, as shown in FIG. 2, the token
100 may be disposed in a variety of devices, such as in a
flashlight, key chain, cellular phone, a personal digital
assistant, and/or a watch, for example.
[0043] FIG. 3 is a block diagram showing in further detail the
authenticating authority 300. The authenticating authority 300
includes a general processing portion 310 and a general memory
portion 320. The general processing portion 310 controls overall
operations of the various components disposed in the authenticating
authority 300. Further, the general memory portion 320 provides a
wide variety of memory resources to the authenticating authority
300.
[0044] The authenticating authority 300 further includes an input
portion 330. The input portion 330 inputs information necessary to
verify a transaction performed using the token 100. Illustratively,
the input portion 330 inputs a device number from a token, the time
the transaction, as well as a token output sequence. The
authenticating authority 300 further includes a base counter 350.
The base counter 350 outputs an authenticating value based on the
transaction time, which is received from the token 100. This
authenticating value is created using processing performed in
parallel to the token counter 160. Specifically, the base counter
350 simulates the output that the token counter 160 would have
generated at the time of the transaction.
[0045] Further, the authenticating authority 300 includes an
encryption portion 360. The encryption portion 360 calculates a
verification sequence in the same secret logic as in the token 100.
In the authenticating authority 300, the encryption portion 360
operates in conjunction with the secret logic memory portion 370 to
generate the verification sequence. For example, the secret logic
memory portion might use the device number to determine which logic
to apply to the verification sequence, e.g., using a look-up table,
for example.
[0046] In accordance with one embodiment of the invention, it is
noted that the logic might use the device number in mathematical
processing of the authenticating value, or, in the token, the logic
might use the device number in mathematical processing of the token
value.
[0047] Further, the authenticating authority 300 includes a
comparison portion 380. The comparison portion 380 uses the
verification sequence, which is generated within the authenticating
authority 300, and compares such verification sequence with the
input "token output sequence," which is input from the token
100.
[0048] FIG. 4 is a flow chart showing a customer process in
accordance with one embodiment of the invention. As shown in FIG.
4, the process starts in step 500 in which the customer initiates a
transaction. After step 500, the process passes to step 510. In
step 510, the customer reads, or in some other manner conveys, the
device number to the merchant. Then, in step 520, with reference to
the embodiment of the invention shown in FIG. 1, the customer
presses the power display button. As a result, the token output
sequence is displayed for viewing by the customer. Accordingly, in
step 530, the customer reads the token output sequence to the
merchant. In conjunction with step 530, the customer device, i.e.,
the token 100, for example, calculates the token output sequence
based on a token value generated in the token, i.e., based on the
progression of the clock in the token. After step 530 of FIG. 4,
the process passes to step 540. In step 540, the customer input to
the transaction is completed.
[0049] FIG. 5 is a flow chart showing an authenticating authority
process in accordance with one embodiment of the invention. As
shown in FIG. 5, the process starts in step 600 and passes to step
610. In step 610, the authenticating authority obtains the device
number from the customer. Then, in step 620, the authenticating
authority obtains the token output sequence number from the
customer. After 620, the process passes to step 630. In step 630,
the authenticating authority also inputs the time of the
transaction, i.e., which may be obtained from the merchant in
accordance with one embodiment of the invention. Accordingly, each
of the items of information input in steps 610, 620 and 630 are
obtained from the customer and/or the merchant and may typically be
transmitted from the customer through the merchant so as to be
input by the authenticating authority.
[0050] Returning to FIG. 5, after step 630, the process passes to
step 640. In step 640, the authenticating authority performs a
verification process on the transaction. FIG. 6 is a flowchart
showing in further detail step 640. After step 640 of FIG. 5, the
process passes to step 800. In step 800, the verification process
is completed.
[0051] As noted above, FIG. 6 is a flowchart showing in further
detail the "perform verification process on the transaction." As
shown in FIG. 6, the process starts in step 640 and passes to step
650. In step 650, the process, i.e., performed by the
authenticating authority, calculates a "verification sequence"
based on the device number and the time of transaction, which has
been input. Then, in step 660, the authenticating authority
compares the "token output sequence" input from the customer with
the "verification sequence". After step 650, the process passes to
step 670.
[0052] In step 670, as shown in FIG. 6, the process determines
whether the token output sequence that is input from the customer
matches with the verification sequence that is generated within the
authenticating authority. If yes, i.e., there is a match, then the
process passes to step 672. In step 672, the transaction is
authorized. After step 672, the process passes to step 699.
[0053] Alternatively, it may be the situation that in step 670, the
token output sequence does not match with the verification
sequence. As a result, the processes passes from step 670 to step
680. In step 680, an initial determination is made that the
transaction is not authorized. However, this is merely an initial
determination. That is, after step 680, the process passes to step
690. In step 690, the process performs alternative processing to
further consider the authorization. That is, the process performs
further processing to ascertain whether the transaction was indeed
a valid transaction. FIG. 8 is a flowchart showing in further
detail step 690. After 690 of FIG. 6, the process passes to step
699
[0054] In step 699, the process may perform a supplemental
transaction validation, as is necessary or desired. That is, it is
appreciated that there may be other criteria that makes an
authenticator decide to allow the transaction or not. For example
suppose a transaction is coming supposedly from Seattle and the
authenticating authority experienced a transaction, with the same
token, from New York 10 minutes ago. The authenticating authority
might want to decline this transaction even if the authorization
number appeared to be correct. Likewise even if the transaction is
not authorized, maybe the issuer will determine the electronics
have glitched and he may use other information, ask the merchant
for other information, or just warn the merchant and let the
merchant decide whether to go ahead anyway, i.e., since the
merchant will bear any loss. After step 699, the process passes to
step 700. In step 700, the process returns to step 800 of FIG.
5.
[0055] FIG. 7 is a flowchart showing in further detail step 650 of
FIG. 6 "calculate verification sequence based on device number and
time of transaction." After the sub-process of FIG. 7 starts, the
process passes from step 650 to step 652. In step 652, the process
determines the "authenticating value" based on the time of
transaction. Then, in step 654, the process determines the "secret
logic" based on the device number. That is, it is appreciated that
different logics may be used for different devices. The device
number, or some other identifying indicia that may be associated
with a particular device, may be used to determine which logic
should be applied by the authenticating authority. After step 654,
the process passes to step 656. In step 656, the process proceeds
with applying the secret logic to the "authenticating value" to
determine, in turn, the "verification sequence". After step 656,
the process passes to step 658. In step 658, the process returns to
step 660 of FIG. 6.
[0056] FIG. 8 is a flowchart showing in further detail the "perform
alternative processing to further process authorization" step 690
of FIG. 6. In particular, the process of FIG. 8 relates to the
situation where clock drift has occurred between the clock in the
authenticating authority as compared with the clock in the token
100. Such drift between the clocks may result in an initial finding
that a transaction is not valid. However, the process of FIG. 8
addresses a potential incorrect finding of an invalid
transaction.
[0057] To explain, the process of FIG. 8 starts in step 690 and
passes to step 692. In step 692, the process determines whether the
time of transaction is near the beginning of a clock interval,
i.e., is the time of the transaction near the time that the clock
in the authenticating authority experienced a change. If yes in
step 692, then the process passes to step 693. In step 693, the
process recalculates the verification sequence based on the
previous base counter setting. After step 693, the process passes
to step 697.
[0058] Alternatively, in step 692, the process may have determined
that the time of the transaction is not at the beginning of a clock
interval. As a result, the process passes to step 694. In step 694,
the process, as illustratively performed by the authenticating
authority, determines whether the time of the transaction is near
the end of a clock interval. If yes, then the process passes from
step 694 to step 695. In step 695, the process recalculates the
"verification sequence" based on the next base counter setting.
Then, the process passes to step 697.
[0059] In step 697, the process determines whether the token output
sequence input by the customer matches with the recalculated
verification sequence. That is, step 697 checks whether the
previous or the next clock setting of step 693 and step 695,
respectively, result in a match between the token output sequence
and the verification sequence. If yes, then the process passes to
step 698. That is, if there is indeed a match then the transaction
is authorized. After step 698, the process passes to step 698'.
Alternatively, in step 697, there may still not be a match between
the token output sequence input by the customer and the
recalculated verification sequence. As a result, the process passes
to step 697' and the transaction is not authorized. After step
697', the process passes to step 698'.
[0060] As noted above, in step 694 of FIG. 8, the process
determines whether the time of the transaction is near the end of a
clock interval. Further, step 692 determined if the transaction is
near the beginning of a clock interval. If neither of the
situations is present, then the process passes to step 696. In step
696, the process determines that the transaction is indeed not
authorized. As a result, the process passes to step 698'. However,
it is appreciated that more then the immediately adjacent intervals
may be considered. For example if the clock advances relatively
quickly, this results in a potential for substantial clock drift.
As a result, it may be desired to check three, for example, (or as
many as desired) intervals before the initially considered
interval, as well as three subsequent intervals, for example.
[0061] In step 698', the process returns to step 699 and then to
step 700 of FIG. 6. As noted above, in step 700 of FIG. 6, the
process returns to step 800 of FIG. 5 in which the verification
process is terminated.
[0062] In accordance with a further embodiment of the invention,
FIG. 9 is a diagram showing a token 100' disposed in a flashlight
700. The token 100' may operate in a similar manner to the token
100, as shown in FIG. 1. The flashlight 700 may include batteries
702. In accordance with one embodiment of the invention, the
batteries 702 may power operations of the token 100'. As described
above, the token 100' generates a token output sequence, and
transmits the token output sequence to a merchant 200. This
transmission may be in a variety of forms, as is shown in FIG. 9.
In turn, the merchant 200 outputs the token output sequence, as
well as a time stamp and a token device number, which is also
obtained from the token, to the authenticating entity 300.
[0063] In accordance with a yet further embodiment of the
invention, FIG. 10 is a block diagram showing a token 800 that may
operate in a similar manner to the token 100. The token 800
includes an encryption portion 870 and a display 880. The
encryption portion 870 provides the logic to convert the token
value into the token output sequence, as described above. This
logic may take on a variety of forms so as to manipulate the token
value, as is desired, i.e., such as a mathematical manipulation of
the token value, for example. The token counter of the embodiment
of FIG. 10 includes a clock 862 and a tick reduction portion 864.
The clock may be a standard twenty-four hour clock, but may
preferably be a digital clock, i.e., such that a digital output may
be output to the tick reduction portion 864.
[0064] The tick reduction portion 864 works off the advancement of
the clock 862 to generate the token values. However, the tick
reduction portion 864 advances at a much slower rate. For example,
for every 12 hours that the clock 862 advances, the tick reduction
portion 864 may only advance once. As is noted above, such reduced
advancement reduces the effects of clock drift between the token
and the authenticating authority.
[0065] In accordance with further aspects of the invention, it is
appreciated that the token value, the token output sequence, the
authenticating value, and the verification sequence, for example,
may be numbers, letters, symbols, punctuation and/or any other
character set, for example. However, the particular composition of
the token value, as well as the corresponding authenticating value,
should be such that such values may advance in a routine
manner.
[0066] As described above, the systems and methods of the invention
rely upon time stamping in accordance with embodiments of the
invention. Accordingly, a variety of techniques may be used to
address different time zones. For example, one time zone may be
designated as a standard and all time stamps converted to this
standard.
[0067] As described above, methods and systems are disclosed which
permit tokens used for finance to be checked for authenticity by
having the tokens display an authentication code that varies with
time, yet can be validated by the token validation authority.
Because the authentication code changes, such codes may not readily
be stored and stolen, as is a problem in existing codes. The
invention reduces fraud for all involved where there is risk that a
token might be a forgery.
[0068] It will be readily understood by those persons skilled in
the art that the present invention is susceptible to broad utility
and application. Many embodiments and adaptations of the present
invention other than those herein described, as well as many
variations, modifications and equivalent arrangements, will be
apparent from or reasonably suggested by the present invention and
foregoing description thereof without departing from the substance
or scope of the invention.
[0069] Accordingly, while the present invention has been described
here in detail in relation to its exemplary embodiments, it is to
be understood that this disclosure is only illustrative and
exemplary of the present invention and is made to provide an
enabling disclosure of the invention. Accordingly, the foregoing
disclosure is not intended to be construed or to limit the present
invention or otherwise to exclude any other such embodiments,
adaptations, variations, modifications and equivalent
arrangements.
* * * * *