FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(See section 10, rule 13)
"METHOD AND SYSTEM FOR AUTHORIZING A TRANSACTION USING A DYNAMIC AUTHORIZATION CODE"
MASTERCARD INTERNATIONAL INCORPORATED,
an American Company of 2000 Purchase Street, Purchase,
NY 10577 (United States of America).
The following specification particularly describes the invention and the manner in which it is to be performed.

WO 2006/023839

PCT/US2005/029758

METHOD AND SYSTEM FOR AUTHORIZING A TRANSACTION USING A DYNAMIC AUTHORIZATION CODE
SPECIFICATION
5 RELATED APPLICATION
This application claims priority from U.S. provisional application No. 60/602,594 filed August 18, 2004 entitled "Method And System for Generating Authentication Codes For Use in Payment or Financial Transactions."
10 BACKGROUND OF INVENTION
The use of credit and debit cards for remote transactions is ever increasing. Whether over the telephone, through the mail, at retail outlets, or over the Internet, the need to perform transactions without face-to-face contact is a common one. A remote transaction, however, is less secure than a face-to-face transaction and
15 the likelihood of fraud is commensurately higher, particularly if a transaction card is lost or stolen.
One approach to minimizing fraud is through the use of a personal identification number, or PIN. In this approach, at the time of the transaction, the user's card is inserted or swiped in a card reader. The reader extracts certain data
20 from the card, such as an account number. The card reader then requests the user enter his or her PIN on a keypad. The PIN is encrypted or otherwise secured and the secure PIN data is transmitted to an authorization location, such as an authorization computer, where cardholder data is stored. At the authorization computer, the account identification data is used to lookup and retrieve account information, and the
25 retrieved information is used to verify that the PIN entered by the cardholder was correct. This approach minimizes fraud because the person in possession of the card must also know the secret PIN to complete the transaction. One disadvantage to this approach is that, because the PIN is static, a thief could intercept the PIN during a legitimate transaction and reuse it in a subsequent fraudulent transaction.
30 In another approach recently suggested by the inventor, the use of a
static PIN is replaced by a dynamic code that frequently changes. That approach is described in more detail in co-pending U.S. Patent Application No. 60/626,649 entitled "Method And System For Enabling The Use Of Dynamic Codes For
2

WO 2006/023839

PCT/US2005/029758

Authentication," which application is hereby incorporated by reference in its entirety. One aspect of this approach involves generating a dynamic code using a smart card and smart card reader. Smart cards are well known in the art and are typically credit card shaped cards that include a secure data storage area and processor. At the time
5 of a potential transaction, the smart card generates an application cryptogram using secret data stored in the secure memory of the smart card, as well as other data related to the potential transaction. The generation of application cryptograms is well known in the art and are explained in more detail, for example, in the well known smart card specifications entitled: "EMV Integrated Circuit Card Specifications for Payment
10 Systems" promulgated by EMVCo. LLC. available on the Internet at http://www.emvco.com, which specifications are hereby incorporated by reference in their entirety. This data, or a portion of it, is then transmitted as a dynamic code to an authorization computer. The authorization computer can verify, based on account information retrieved from a; athorization database associated with the account
1 5 number, whether the dynamic code was generated by the smart card associated with the account number being used to complete the transaction, or not.
One disadvantage to using smart cards to enhance the security of a transaction is that they are relatively expensive to manufacture compared to a more traditional magnetic stripe card. Additionally, smart cards require a smart card reader
20 to be used during each transaction, requiring an upgrade from existing point of sale terminals that are designed for magnetic stripe cards. Because of these and other reasons, smart cards and smart card readers have not been deployed widely in the United States.
25 SUMMARY OF THE INVENTION
The present invention permits transactions to be authorized in a more secure manner without the necessity for widely distributing smart cards and smart card readers. Instead, the processing capacity of a mobile consumer device, such as a PDA or cell phone, which a cardholder already possess, is employed to generate a
3 0 dynamic authorization code associated with a particular cardholder account. The mobile device will not contain data that could identify the particular account with which it is associated. The dynamic code, together with account identification data,

WO 2006/023839

PC17US2005/029758

are then transmitted to an authentication computer to verify the authenticity of a transaction.
In one exemplary embodiment of the present invention, a method is provided for authorizing a transaction. The method entails associating account secret
5 data with a unique financial account identifier in an authorization database and generating personalization data based at least in part on data associated with the account secret data. The personalization data is transmitted to a mobile processing device, such as a PDA or cellphone, that does not contain the unique financial account identifier, for storage therein. Subsequently, an authorization request is received at an
10 authorization location. The request includes the financial account identifier and a dynamic authentication code generated by the mobile processing device. A determination is then made as to whether the authentication code was generated by a mobile processing device containing personalization data that was generated at least in part based on data associated with the account secret data associated with the
15 financial account identifier in the authorization database. Finally, the transaction may be authorized or not authorized depending on the previous determination.
BRIEF DESCRIPTION OF THE DRAWINGS
For a more complete understanding of the present invention, reference
20 is made to the following detailed description of exemplary embodiments with reference to the accompanying drawings in which:
FIG. 1 is a flow chart of the steps of performing a transaction using a
generated authentication code and account identifying information in accordance with
one exemplary embodiment;
25 FIG. 2 is a block diagram of one exemplary system for generating an
authentication code; and
FIG. 3 is a block diagram of one exemplary embodiment of the present invention.
30 DETAILED DESCRIPTION OF THE EXEMPLARY EMBODIMENTS
i
FIG. 1 is a flow chart depiction of one exemplary embodiment of the present invention that entails performing a transaction using a generated dynamic authentication code 130 and account identifying information or a unique financial
4

WO 2006/023839

PCT7US2005/029758

account identifier 140. The following description will be based on a hypothetical transaction performed over a computer network, such as the Internet. However, it will be understood that the principles of the invention are not limited to transactions over a computer network, but could be easily adapted to other types of transactions, such as
5 transactions over a telephone, through mail, face-to-face, or in any other manner.
The hypothetical transaction begins with a user of a personal computer (PC) making a request to purchase a good or service from a merchant using a web browser or similar application running on the personal computer. It should be noted that any device, system or scheme for requesting or performing a transaction can be
10 used in place of the PC, including a mobile device such as a PDA or cellular telephone. The user's request then causes the merchant's computer to invoke an authorization request server to authenticate the user's identity and verify the transaction is legitimate. The authorization request server or authorization processor, which can be a mainframe or other computer with a processor, memory, and
15 communications link, prompts the user to provide a dynamic authorization code using his or her mobile processing device.
In step 101, the user activates his or her mobile processing device, such as a personal digital assistant (PDA) or cellular telephone, and invokes functionality to generate a dynamic authentication code. The mobile processing device, which is
20 discussed in further detail herein, includes software or circuitry for generating the dynamic codes. In a particular exemplary embodiment, the software or circuitry on the mobile device has substantially all of the functionality of a typical smart card, although without any data that can be directly used to uniquely identify a financial or payment account. In one embodiment, once the mobile device is activated, the user is
2 5 prompted to enter an identification PIN using a keypad, keyboard, or some other technique for receiving user input into the mobile processing device. It should be understood that the mobile processing device could be a laptop or other personal computer and could be the same personal computer as is being used to perform the hypothetical transaction being discussed. Typically however, the personal computer
30 on which the transaction is being performed and the mobile device will be separate devices. The mobile device then validates in step 103, whether the PIN is valid by comparing the PIN with data stored on the device. Notably, steps 101 and 103 are not required, but may be advantageously used to improve security of the authorization
5

WO 2006/023839

PCT7US2005/029758

system and deter fraud. Additionally, where a PIN is used, the PIN input process can be delayed until after other data relating to the transaction is entered by the user into the mobile device, as discussed herein in more detail.
In one! exemplary embodiment, the authorization processor may also
5 provide to the user a challenge number, or other unpredictable data that the user will enter into his or her mobile processing device, which will subsequently be used to generate the dynamic authentication code, typically in conjunction with other data such as an encryption key. The unpredictable data may be a random number, can be based on the current time, a one-way hash of the proposed transaction amount, some
10 combination thereof,, or any other data that can not be easily predicted before a transaction. The user may also be prompted to enter other data regarding the transaction into the mobile device, such as the transaction amount or currency type, and this data may be used by the device, together with other secret data, to generate a cryptogram that will become a dynamic authorization code as discussed in more detail
15 herein.
In step 110 the mobile processing device generates a dynamic authentication code 130 using a key 120, such as an encryption key. The key 120 may be a DES key, a private key, a public key, some combination thereof, or any other data used for encryption or generating a secure message for subsequent
20 authentication. The key may be stored, for example in application memory in the mobile processing device. If the mobile processing device includes secure or protected memory, (e.g. in a subscriber identity module (SIM) card inserted into a cellular phone or PDA), the key could advantageously be stored there instead. The key 120 may also be encrypted or held in a memory unit that is inaccessible to other
25 processes, programs or applications running on the mobile device. For example, the key could be encrypted by a second key, such as a user PIN, mobile device serial number, other data or a combination thereof. Notably, the presence of secure memory in the mobile device is not required.
The memory of the mobile device should contain no information that
30 would identify the account with which the key 120 corresponds. Specifically, the key 120, and the mobile device memory, should not contain the payment account number (PAN), card expiry date, card track data typically stored on a transaction card magnetic stripe, the account holder name, nor any other data that could uniquely
-6-

WO 2006/023839

PC1YUS2005/029758

identify the financial account. In this way, if the mobile device is stolen or compromised, the device could not be used to perform a transaction as there would be no data identifying the financial account to which the key 120 corresponds.
In one exemplary embodiment, key 120 is held within a chip
5 authentication program (CAP) data file 125, together with an application profile identifier, an application transaction counter, and other data. More details regarding chip authentication program formats and functionality can be found in MasterCard's Chip Authentication Program specifications, which are available for license from MasterCard International Incorporated in Purchase, New York and are hereby
10 incorporated by reference in their entirety. The CAP data file 125 may in one exemplary embodiment be encrypted, and subsequently decrypted using the PIN input by the user, a Mobile Device Identifier, such as a phone number or device serial number, gathered from the device on which the decryption occurs, or a combination of both. In this way, use of the CAP data file can be restricted to individuals who
15 know the PIN, devices that have been approved, or a combination of both. The transaction counter, which is optionally included in the data file 125, is in one exemplary embodiment a sequential counter that is incremented every time a dynamic authorization code is generated.
The generation of the authentication code of step 110 may be further
20 understood as including the generation of an application cryptogram 115 in step 112. The application cryptogram is generated from the key 120, and other data such as the transaction counter, using techniques well known in the art of smart card design or operation, for example in the manner EMV-compliant smart cards operate when provided with the GENERATE AC command. In the previously described exemplary
25 embodiment where the authorization processor provides unpredictable data to the user, the application cryptogram is generated based on the unpredictable data in addition to the key 120 and transaction counter. Other data regarding the transaction can also be used in calculating the application cryptogram, such as the transaction amount, transaction date/time, currency type, etc. For example^ in one embodiment,
30 the unpredictable data, transaction counter, and any other relevant data could be
concatenated together and encrypted using the key 120 to generate an application
i
cryptogram. The authentication processor and/or issuer bank can select which data should be used in calculating the application cryptogram for transaction accounts
7

WO 2006/023839

PCT/US2005/029758

maintained by the issuer bank. Accordingly, in this exemplary embodiment, the mobile device essentially becomes a "software smart card" functioning in a similar manner to that described by the CAP specifications for smart cards.
In one exemplary embodiment, the application cryptogram 115 is an
5 intermediate data format that may consist of the following data items expressed in binary form and concatenated from most to least significant as follows: cryptogram information data (8 bits), transaction counter (16 bits), cryptogram computed by the mobile processing device-(64 bits), and issuer application data (0-256 bits). The issuer application data is data selected by the financial institution that maintains the
10 cardholder's account and can be any data; however, for purposes of this invention, it is preferable that the issuer application data not include information that could be used to identify the cardholder or the financial account associated with the cardholder.
Because the output of this intermediate step could potentially result in a data value up to :43 bytes long (i.e. a value ranging from 0 up to 2344 or
15 approximately 3.6 x 10103), which would be far too large to present to a user as a decimal number, this data must be compressed or otherwise restricted before it is displayed to a user. Indeed, even the 64 bit cryptogram, which forms a part of the intermediate data, would be too long to display to a user in decimal numeric format, taking into consideration the possibility that the user may need to re-enter the
20 dynamic code into their web browser on the computer on which the transaction is being performed. Accordingly, in step 117, the intermediate data is reduced to a more manageable data size and presented to the user. In one exemplary embodiment, the intermediate cryptographic data is reduced to 8 numeric characters, resulting in possible values from 0 up to 99,999,999. This reduction is accomplished in one
25 exemplary embodiment through use of a bitmap that identifies which of the bits in the intermediate data form should be retained and used to compute the dynamic authentication code. For example, the bitmap could identify bits 1-15, 17-19, and 21-27 as the bits to retain from the intermediate calculation. The retained bits are then concatenated together and displayed in binary coded decimal format (BCD). Using
30 this approach, in order to ensure that the possible values displayed to the user does not exceed 8 digits, the maximum number of bits that can be retained is 26. The precise bits that are retained are subject to design choice depending on the particular application and circumstances; however, the algorithm used to select the bits to be

WO 2006/023839

PCT/US2005/029758

retained must be known to the authorization processor as well so that the authorization processor can verify the dynamic authentication code generated by the mobile processing device.
In one exemplary embodiment, the bits and data known to the
5 authorization processor, or data that the authorization processor can derive from other data known to it or provided in the dynamic authentication code is not included in the final dynamic authentication code that is generated. For example, if a transaction counter is used and the authentication processor maintains a copy of the transaction counter associated with the mobile device in an authorization database, the complete
10 transaction counter need not be included in the data used to generate the dynamic mode. For instance, it may only be necessary to include some of the least significant bits of that counter. In that way, even if the copy of the transaction counter stored in the authorization database gets out of synchronization with the counter on the mobile device, the authorization processor will be able to rebuild the transaction counter and
15 accurately compute its own version of the cryptogram using the partial data received regarding the counter from the mobile device in the dynamic authorization code.
Other bits of the intermediate data, including the calculated cryptogram, may also be excluded as long as a reasonable number of the bits are maintained to minimize the probability of an erroneous authentication, keeping in
20 mind that the authorization processor will calculate its own version of the cryptogram using the secret it shares with the mobile device (i.e. the secret key in the exemplary embodiment) as well! as the transaction specific data, such as the unpredictable number, transaction counter, etc. and will authorize the transaction if the processor determines that the cryptogram calculated by the mobile device, as evidenced by the
25 dynamic authorization code received from the mobile device, matches the cryptogram calculated by the authorization processor, after masking with the aforementioned bitmap.
The manner in which the cryptogram is computed can vary and are too numerous to recite here. In one embodiment, the cryptogram entails performing a
30 calculation based on data selected by the accountholder's issuer bank and encrypting the result of that calculation with the secret information stored on the card, such as an encryption key. The cryptogram generation step 110 however should produce a dynamic, not static, authentication code 130 that varies unpredictably even with

9

WO 2006/023839

PCT/US2005/029758

repeated transactions of the same type and amount. This will reduce the possibility that an eavesdropper could intercept and replay the dynamic authorization code in a subsequent attempted transaction that is not actually authorized by the cardholder associated with the financial account being used to perform the transaction.
5 Additionally, the calculation should demonstrate that the cardholder associated with the financial account being used to perform the transaction has authorized the transaction. In one preferred embodiment, this is accomplished by requiring the input of a PIN to the device before the dynamic authentication code is generated.
Although the authentication code is dynamic and frequently changes
10 based on various factors, such as particular transaction characteristics and other random and varying data, the generation step 110 may entail the creation of a particular authentication code more than once over time, without departing from the scope of the claimed invention. The generation step 110 may be performed on any mobile processing device, such as a PDA, mobile or cellular telephone, laptop
15 computer, or other device. The device should have a processor capable of performing
the steps necessary to generate the authentication code 130. The mobile processing
device may also be a smart card and the generation step 110 may be performed by the
smart card. ,
As shown in figure 2, the mobile device in one exemplary embodiment
20 includes data storage area 1030, such as RAM, flash, hard drive, or other memory, that contains data used to generate a dynamic authentication code, including data entered by user of the device. The device also includes an authentication code generator 1020, which may be a processor programmed to generate an authentication code in accordance with any of the techniques described herein and well-known to
25 persons of skill in the art. The generator 1020 generates a dynamic authentication code 130, previously! described, and provides the code to an output device 1010. This authentication code output device 1010 could present the resulting dynamic authentication code 130 to a user, such as through a LCD screen or other display, through synthesized speech techniques or audio sounds, or some other means.
30 Alternatively, or in addition, the device 1010 could transmit the authentication code 130 via wires, infrared, or radio frequency signals to another device, such as a personal computer or terminal on which a transaction is being performed, for subsequent transmission to an authorization location. In another exemplary
10

WO 2006/023839

PCT/US2005/029758

embodiment, the mobile device can communicate the dynamic authentication code directly to an authorization processor at an authorization location over a communication network, such as a wireless communications network, the Internet, or
a combination thereof.
i
5 Additionally, to assist in identifying the account for which the
i
authentication code 130 is generated (for example where the device is capable of
generating codes for a plurality of different accounts associated with the user or users
of the device), the authentication code output device 1010 could display or transmit a
promotional name, a graphical logo, or an identifying token to a user to assist the user
10 in interacting with the device to select the proper account for which a dynamic code is
to be generated. !
Returning now to Fig. 1, the account secret data, such as the encryption
key, is stored in an authorization database accessible by the authorization processor
(not shown). The secret data corresponds to a particular financial account (for i
15 example a credit or debit account) associated with the user of the mobile processing
device. The authorization database is preferably accessible only by the authorization
processor and/or the bank or financial institution that maintains the user's account,
typically referred to as the "issuer" bank by persons of skill in the art. If a mobile
device is stolen or compromised, a person possessing the device would not be able to
20 perform a transaction, because the authorization code 130 generated by the device cannot be used to authenticate a transaction without some other financial account identifier, such as a primary account number (PAN) that identifies the particular financial account to which the goods or services should be billed.
Accordingly, at the time of a transaction, the financial account
25 identifier 140 should be collected using various techniques well known to persons
skilled in the art. For example, the account identifier 140 may be stored on a
i
magnetic stripe card 145 or on a smart card, or collected through user input to a
i
device such as a keypad, keyboard, or other input device.
In step 150 the dynamic authorization code 130, along with financial
30 account identifier data 140, is transmitted to an authorization location, such as an
authorization processor. Depending on the response from the authorization location,
i in step 160, the transaction may be authorized in step 170 or declined in step 180.

WO 2006/023839

PC17US2005/029758

As described previously, the authorization process may entail calculating, at the authorization location, the dynamic authentication code using the same data and algorithm as performed by the mobile device, and comparing the calculated result to the received dynamic code to confirm that the calculated results
5 matches the received code. This process utilizes the secret data, such as the encryption key, associated with the financial account identifier provided with the transaction. In once embodiment, the dynamic code received at the authorization
location is analyzed!to determine if the code includes any data used by the mobile
i device to calculate the application cryptogram that is not known by the authorization
10 processor. For example, it is possible that the mobile device used a transaction counter to calculate the application cryptogram, in which case it is necessary to provide the counter to the authorization processor as well so that it can use the same data in calculating1 its version of the application cryptogram. As previously mentioned, although a copy of the transaction counter associated with a particular
15 account or mobile ; device may be stored in an authorization database, or at the authorization location, the stored copy of the counter may not be synchronized with the counter on the mobile device due to previous failed transactions that were not communicated to the authorization processor or authorization database. Accordingly, once the authorization processor extracts or recreates any necessary data from the data
20 provided in the dynamic authentication code, the authorization processor can calculate the dynamic authorization code using the techniques previously described, including performing a calculation with the relevant transaction data and secret account information, such as the encryption key associated with the account. This calculated code is then compared with the dynamic code received from the mobile device, as
25 previously described.
One exemplary technique to deploy the necessary programming and data to mobile processing devices entails a deployment server. In this embodiment, the user of the mobile device visits a website specified by the user's issuer bank and the user requests the dynamic authorization code generator application be installed on
30 the user's mobile device. The user is prompted for a PIN to be associated with the
application and the user's Mobile Device Identifier. The user may also be prompted
i
for his or her financial account identifier, or this data may be determined through some other approach. Account secret data, such as an encryption key or key pair, is

WO 2006/023839

PCT/US2005/02975S

generated and associated with the user's financial account identifier. At least a
portion of this secret data (for example the encryption key or one or more of the keys
in a key pair) is then stored in an authorization database record associated with the
user's financial account identifier.
5 Personalization data is then generated based on data associated with
the secret data previously generated. For example, the encryption key or one or more of the keys in a key pair may be encrypted, such as with triple-DES, using the PIN and a Mobile Device Identifier, previously entered by the user, as the temporary key to create the personalization data. The personalization data and any additional
10 executable program files are then communicated from the deployment server to the mobile device. The communication can occur via a direct connection between the . ;er's mobile device and another computer, such as a PC, or can occur using an Over The Air (OTA) server using a mobile or wireless data network. The application and personalization data are then placed into memory of the mobile device, where they
15 can be used to generate dynamic authentication codes as previously described herein.
i
The account secret data and any encrypted or personalization data are removed from the deployment server either after a predetermined amount of time or after the application and personalization data has been successfully installed. At least a portion of the secret;data remains stored in the authorization database however, for
20 use during subsequent authorization requests.
In one embodiment, the application is provided in the form of a Java applet executed by a Java Virtual Machine installed on the mobile processing device. The Java applet instructions may in one exemplary embodiment be obfuscated for further security, for example by using DashO from Preemptive Solutions of
25 Cleveland, OH. ;
Figure 3 shows a block diagram of an exemplary embodiment of the invention using the Java language 2090 and Java Virtual Machine (JVM) 2080. First, the mobile device user requests the dynamic authentication application be invoked using interface 2060,: such as a keypad or keyboard. The JVM 2080 then loads the M-
30 CAP jar Sandbox 2CJ20. The JVM 2080 prompts the user to enter a PIN, which is
i then received from the interface 2060. The CAP generator 2030 portion of the Java
i application then uses the CAP data 2040 to generate an eight-digit dynamic
authentication code (in accordance with the techniques previously described. The

WO 2006/023839
PCT/US2005/02978

eight-digit code is returned, through the JVM 2080, to the phone user interface 2060.
The CAP Data 2040 or the M-Cap Jar Sandbox 2020, residing in the phone memory
201 0, may be encrypted, for example by using the Bouncy Castle Crypto API for
J2N"IE from .
5 Although the present invention has been described with reference to
certain preferred embodiments, various modifications, alterations, and substitutions will be known or obvious to those skilled in the art without departing from the spirit and scope of the invention. Numerous other applications of the present invention will be apparent to one of ordinary skill in the art.

WO 2006/023839

PCT/US2005/029758

I claim:
1. A method for authorizing a transaction, comprising:
1 associating account secret data with a unique financial account
identifier in an authorization database;
5 generating personalization data based at least in part on data
associated with said account secret data;
transmitting said personalization data to a mobile processing deviceithat does not contain said unique financial account identifier, for storage therein;
10 receiving at an authorization location, an authorization request
i
to authorize a transaction, said request including said unique financial account identifier and a dynamic authentication code generated by said mobile processing device;
determining whether said dynamic authentication code was
15 generated by a mobile processing device containing personalization
data that was generated at least in part based on data associated with said account secret data associated with said unique financial account identifier in said authorization database; and
authorizing said transaction in response to said determining
20 step.
2. The method as in claim 1, further comprising:
prompting by said mobile processing device for input of an identification PIN; and
validating said identification PIN by said mobile processing
25 device before said dynamic authentication code is generated by said
i
mobile processing device.
3. The- method of claim 1, wherein said account secret data is an
encryption key.
4. The method of claim 3, wherein said data associated with said account
30 secret data is said encryption key.
5. The method of claim 3, wherein said encryption key is a private key
and wherein said data associated with said account secret data is a public key
associated with said private key.
15

WO 2006/023839

PCT/US2005/029758

6. The method of claim 1 wherein said dynamic authentication code
generated by said mobile processing device is based at least in part on a transaction
counter stored on said mobile processing device.
7. The method of claim 6 wherein a copy of said transaction counter is
5 maintained in said authorization database, further comprising the step of verifying
said transaction counter used to generate said dynamic authentication code matches said copy of said transaction counter.
8. The method of claim 6 wherein said transaction counter is incremented
when said dynamic authentication code is generated.
10 9. A system for authorizing a transaction, comprising:
an authorization database containing at least one unique financial account identifier and secret account data associated with said identifier;
a mobile processing device that does not contain said unique
15 financial account identifier thereon for generating a dynamic
authentication code;
a transmitter for transmitting personalization data to said
mobile processing device, said personalization data based at least in
part on data associated with said secret account data;
20 a receiver for receiving an authorization request to authorize a
transaction, said authorization request including said unique financial account identifier and said dynamic authentication code;
an authorization processor for determining whether said
dynamic authentication code was generated by a mobile processing
25 device containing personalization data that was generated at least in
part based on data associated with said account secret data associated with said financial account identifier in said authorization database, and forauthorizing said transaction in response to said determining.
10. The system of claim 9, wherein said account secret data is an
30 encryption key.
11. The system of claim 10, wherein said data associated with said account
secret data is said encryption key.

16

WO 2006/023839

PCT/US2005/029758

10

12. The system of claim 10, wherein said encryption key is a private key and wherein said data associated with said account secret data is a public key associated with said private key.
13. The system of claim 9 wherein said mobile processing device includes a transaction counter, and wherein said mobile processing device uses said transaction counter at least in part to generate said dynamic authentication code.
14. The system of claim 13 wherein said authorization database further
includes a copy of said transaction counter, and wherein said authorization processor
i
is further for verifying said transaction counter used to generate said dynamic authentication code matches said copy of said transaction counter.
15. The system of claim 13 wherein said transaction counter is
incremented when said dynamic authentication code is generated.

Dated this 13th day of March, 2007

ABSTRACT
"METHOD AND SYSTEM FOR AUTHORIZING A TRANSACTION USING A DYNAMIC AUTHORIZATION CODE"
"A method and apparatus for conducting a secure transaction involving generation of a dynamic authentication code on a mobile device, based on secret data which does not identify an account. The authentication code and financial account identifying information are transmitted to a validating entity, which shares information about the secret data, to authorize the transaction".
18