Patent Application
20150227931
The invention relates to a system and a method for authorizing a transaction.
Currently, users typically provide a non-confidential user identifier (e.g., a user ID) and a confidential personal identification number (PIN) to gain access to a system. In this way, the PIN is used to authenticate the user to the system. Upon receiving the user ID and PIN, the system retrieves a registered PIN (that is stored in the system) based on the user ID and compares the registered PIN with the received PIN. The user is granted access only if the received PIN matches the registered PIN number. PINs are commonly used for automated teller machines (ATMs) and at points of sale (POS) for debit cards and credit cards. However, this method of authentication requires that the user remembers his PIN. If the user forgets his PIN, he would not be able to complete the transaction. He would need to seek the system administrator's assistance to retrieve his PIN or reset his PIN.
A need therefore exists to provide a system and a method for authorizing a transaction that seeks to address at least the above-mentioned problems.
According to the first aspect of the invention, there is provided a system for authorizing a transaction, comprising: a biometric scanner configured to obtain biometric information from a user; a controller configured to receive the obtained biometric information from the biometric scanner and to generate a transaction code based on the obtained biometric information, the controller being further configured to receive account data relating to an account of the user; a server configured to receive the account data and the transaction code from the controller; a database in communication with the server and having stored thereon the account data in association with a registered code, the registered code having been generated based on pre-obtained biometric information of the user; and wherein the server is operable to use the account data to identify the registered code and to authorize the transaction based on a comparison of the registered code with the transaction code.
In an exemplary embodiment, the server may be operable to authorize the transaction if the transaction code corresponds with or matches the registered code; and the server may be operable to decline the transaction if the transaction code does not correspond with or match the registered code.
In an embodiment, the system may further comprise a first encryptor in communication with the controller, the first encryptor configured to encrypt the obtained biometric information such that the controller generates the transaction code based on the encrypted biometric information. The system may further comprise a second encryptor in communication with the controller, the second encryptor configured to encrypt the generated transaction code such that the controller sends the encrypted transaction code to the server.
In an embodiment, the biometric scanner may comprise a fingerprint scanner configured to generate a digital representation based on a fingerprint of the user, and the biometric information may comprise the digital representation.
In an embodiment, the biometric scanner may comprise an image capturing device configured to generate a digital representation based on an iris or retina of the user, and the biometric information may comprise the digital representation.
In an embodiment, the account data may comprise one or more of: an account number, a credit card number, a user's name.
In an embodiment, the database may store the account data in association with user information and the server may be further operable to provide the user information to the controller if the transaction is authorized.
In an embodiment, the server may be further operable to permit funds to be taken from the account if the transaction is authorized.
In an embodiment, the controller may be further configured to receive transaction data; and the server may be further configured to receive the transaction data from the controller; and wherein the server may be operable to authorize the transaction based on the transaction data.
In an embodiment, the transaction data may comprise a transaction amount and the database may store the account data in association with an amount of available funds in the account, wherein the server may be operable to use the account data to identify the amount of available funds in the account and to authorize the transaction only if the amount of available funds in the account is equal to or greater than the transaction amount.
In an embodiment, the controller may be configured to generate the transaction code and registered code by converting the biometric information of the user into alphanumeric, numeric or binary codes.
According to the second aspect of the invention, there is provided a method of authorizing a transaction, the method comprising: obtaining biometric information from a user; receiving account data relating to an account of the user; generating a transaction code based on the obtained biometric information; storing the account data in association with a registered code, the registered code having been generated based on pre-obtained biometric information of the user; using the account data to identify the registered code; and authorizing the transaction based on a comparison of the registered code with the transaction code.
In an embodiment, authorizing may comprise authorizing the transaction if the transaction code corresponds with or matches the registered code. In an embodiment, authorizing may also comprise declining the transaction if the transaction code does not correspond with or match the registered code.
In an embodiment generating may comprise: encrypting the obtained biometric information; and generating the transaction code based on the encrypted biometric information.
In an embodiment, the method may further comprise encrypting the generated transaction code.
In an embodiment, the method may further comprise the step of permitting funds to be taken from the account if the transaction is authorized.
In an embodiment, the method may further comprise receiving transaction data; and wherein authorizing the transaction is based on the transaction data.
In an embodiment, storing may comprise storing the account data in association with an amount of available funds in the account, wherein using may comprise using the account data to identify the amount of available funds in the account, wherein the transaction data may comprise a transaction amount, and wherein authorizing may comprise authorizing the transaction only if the amount of available funds in the account is equal to or greater than the transaction amount.
In an embodiment, the method may further comprise the step of generating the transaction code and registered code by converting the biometric information of the user into alphanumeric, numeric or binary codes.
Example embodiments of the invention will be better understood and readily apparent to one of ordinary skill in the art from the following written description, by way of example only, and in conjunction with the drawings, in which:
Embodiments of the present invention will be described, by way of example only, with reference to the drawings. Like reference numerals and characters in the drawings refer to like elements or equivalents.
Some portions of the description which follow are explicitly or implicitly presented in terms of algorithms and functional or symbolic representations of operations on data within a computer memory. These algorithmic descriptions and functional or symbolic representations are the means used by those skilled in the data processing arts to convey most effectively the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities, such as electrical, magnetic or optical signals capable of being stored, transferred, combined, compared, and otherwise manipulated.
Unless specifically stated otherwise, and as apparent from the following, it will be appreciated that throughout the present specification, discussions utilizing terms such as “scanning”, “calculating”, “determining”, “replacing”, “generating”, “initializing”, “outputting”, “obtaining”, “receiving”, “storing”, “using”, “authorizing” or the like, refer to the action and processes of a computer system, or similar electronic device, that manipulates and transforms data represented as physical quantities within the computer system into other data similarly represented as physical quantities within the computer system or other information storage, transmission or display devices.
The present specification also discloses apparatus for performing the operations of the methods disclosed herein. Such apparatus may be specially constructed for the required purposes, or may comprise a general purpose computer or other device selectively activated or reconfigured by a computer program stored in the computer. The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general purpose machines may be used with programs in accordance with the teachings herein. Alternatively, the construction of more specialized apparatus to perform the required method steps may be appropriate. The structure of a conventional general purpose computer will appear from the description below.
In addition, the present specification also implicitly discloses a computer program, in that it would be apparent to the person skilled in the art that the individual steps of the method described herein may be put into effect by computer code. The computer program is not intended to be limited to any particular programming language and implementation thereof. It will be appreciated that a variety of programming languages and coding thereof may be used to implement the teachings of the disclosure contained herein. Moreover, the computer program is not intended to be limited to any particular control flow. There are many other variants of the computer program, which can use different control flows without departing from the spirit or scope of the invention.
Furthermore, one or more of the steps of the computer program may be performed in parallel rather than sequentially. Such a computer program may be stored on any computer readable medium. The computer readable medium may include storage devices such as magnetic or optical disks, memory chips, or other storage devices suitable for interfacing with a general purpose computer. The computer readable medium may also include a hard-wired medium such as exemplified in the Internet system, or wireless medium such as exemplified in the GSM, GPRS, 3G or 4G mobile telephone systems. The computer program when loaded and executed on such a general-purpose computer effectively results in an apparatus that implements the steps of the preferred method.
The invention may also be implemented as hardware modules. More particular, in the hardware sense, a module is a functional hardware unit designed for use with other components or modules. For example, a module may be implemented using discrete electronic components, or it can form a portion of an entire electronic circuit such as an Application Specific Integrated Circuit (ASIC). Numerous other possibilities exist. Those skilled in the art will appreciate that the system can also be implemented as a combination of hardware and software modules.
Embodiments of the present invention relate to a system and a method for authorizing a transaction. With reference to
In an exemplary embodiment, the server 106 is operable to use the account data to identify the registered code in the database and to authorize the transaction based on a comparison of the registered code with the transaction code. In an example embodiment, the server 106 is operable to authorize the transaction if the transaction code corresponds with or matches the registered code. To allow for errors when obtaining the biometric data and/or generating the transaction code/registered code, an appropriate margin of error can be tolerated to authorize the transaction. For example, the errors may occur due to background noise or movement of the user whilst providing their biometric identifier. As such, it may not be necessary for the transaction code to exactly match the registered code. If there is an acceptable level of correspondence between the transaction code and the registered code, the transaction can be authorized. The level of correspondence can be determined by a system administrator. The server may also be operable to decline the transaction if the transaction code does not correspond with or match the registered code. For example, the system administrator can set an authorization threshold (for example “90%”) such that the server 106 is operable to authorize the transaction if the correspondence between the registered code and the transaction code is at or above the threshold. For example, the transaction code may have to be at least 90% the same as the registered code. In an embodiment, the server 106 is operable to decline the transaction if there is a less than 90% match between the transaction code and the registered code, i.e., the match is below the threshold. The matching (i.e., comparison) of the transaction code and the registered code can be performed by an appropriate matcher/comparator device or circuit as would be known to the person skilled in the art.
In an example embodiment, the system 100 may further comprise a first encryptor 114 in communication with the controller 104. The first encryptor 114 may be part of the controller 104 or may be separate to the controller 104. The first encryptor 114 is configured to encrypt the obtained biometric information such that the controller generates the transaction code based on the encrypted biometric information. The first encryptor 114 may encrypt the biometric information before it is delivered to the controller 104 such that the controller 104 never receives or stores the unencrypted biometric information. The obtained biometric information is preferably encoded so that unauthorized third parties cannot read it. For example, a malicious third party who gains unauthorized access to the controller 104 may be able to steal the encrypted biometric information, but will be unable to decrypt data to obtain the biometric information. The biometric information is encrypted using an encryption algorithm, using an encryption key, which specifies how the message is to be encoded. Authorized parties can decode the encrypted biometric information using a decryption algorithm.
In an example embodiment, the system 100 may further comprise a second encryptor 116 in communication with the controller 104. The second encryptor 116 may be part of the controller 104 or may be separate to the controller 104. The second encryptor 116 is configured to encrypt the generated transaction code such that the controller sends the encrypted transaction code to the server. That is, the encrypted transaction code is sent in place of the unencrypted transaction code. The second encryptor 116 may function in essentially the same way as the first encryptor 114. The generated transaction code is preferably encoded so that unauthorized third parties cannot read it. For example, a malicious third party who intercepts the encrypted transaction code in transit between the controller 104 and the server 106 will be unable to decrypt the data to obtain the biometric information. The generated transaction code is encrypted using an encryption algorithm, using an encryption key, which specifies how the message is to be encoded. Authorized parties can decode the encrypted biometric information using a decryption algorithm.
In another embodiment, a single encryptor may be used to encrypt both the obtained biometric information and the generated transaction code. That is, the functions of the first and second encryptors may be provided by a single encryptor.
In an example embodiment, the database 108 stores the account data (e.g., account number, a credit card number, a user's name) in association with user information (e.g., shipping address, billing address, user preferences, passwords, etc.) and the server 106 is further operable to provide the user information to the controller 104 if the transaction is authorized, for example, if the transaction code corresponds with or matches the registration code. In an exemplary embodiment, the user's information can be stored in an online payment wallet (a program or web service that allows users to store and control their online shopping information in one central place) and can be “unlocked” (i.e., the online shopping information can be accessed by the user and/or may be provided to the controller 104) if the transaction is authorized, for example, if the transaction code corresponds with or matches the registration code.
In an example embodiment, the server 106 is further operable to permit funds to be taken from the user's account if the transaction is authorized, for example, if the transaction code corresponds with or matches the registered code. For example, merchants can receive payment from the user for purchased goods and/or services. In an embodiment, the controller 104 may be permitted to take funds out of the account by the server 106. Additionally or alternatively, another entity may be permitted to take funds out of the account by the server 106. For example, the other entity may be an issuer (e.g., bank or financial institution) which administers an account of the merchant. Additionally or alternatively, the server 106 may transfer funds from the account to the controller 104 or the other entity.
In an example embodiment, the controller 104 is further configured to receive transaction data, and the server 106 is further configured to receive the transaction data from the controller 104. The server 106 can be operable to authorize the transaction based on the transaction data. In an embodiment, the transaction data comprises a transaction amount, for example, an amount of money to be exchanged for a good/service as part of the transaction. Also, the database 108 may store the account data in association with an amount of available funds in the account. For example, the account may be a credit card account and the amount of available funds may be the amount of available credit on the account. Alternatively, the account may be a checking account and the amount of available credit may be the amount of money held in the account. It is to be understood that the database will in this case store the account data in association with the amount of available funds in the account and with the above-described registered code. Further, the server 106 may be operable to use the account data to identify the amount of available funds in the account from the database and to authorize the transaction only if the amount of available funds in the account is equal to or greater than the transaction amount.
With reference to
The block 206 may further comprise:
In an embodiment, the obtained biometric information is encoded so that unauthorized third parties cannot read it. The biometric information is encrypted using an encryption algorithm, using an encryption key, which specifies how the message is to be encoded. Authorized parties can decode the encrypted biometric information using a decryption algorithm.
The method 200 may further include encrypting the generated transaction code. In an embodiment, the generated transaction code is encoded so that unauthorized third parties cannot read it. The generated transaction code is encrypted using an encryption algorithm, using an encryption key, which specifies how the message is to be encoded. Authorized parties can decode the encrypted biometric information using a decryption algorithm.
The method 200 may further comprise the step of permitting funds to be taken from the account if the transaction is authorized, for example, if the transaction code corresponds with or matches the registered code.
The method 200 may further comprise:
If the transaction data comprises a transaction amount, the block 208 may further include storing the account data in association with an amount of available funds in the account. Also, block 210 may further include using the account data to identify the amount of available funds in the account. Additionally, block 212 may include authorizing the transaction only if the amount of available funds in the account is equal to or greater than the transaction amount.
The enrollment phase 350 includes three initialization blocks (302, 304, and 306) which are performed prior to the verification phase 360. These three initialization blocks may only be performed once. After these three initialization blocks are completed, a user may only need to perform the blocks in the verification phase 360 to repeat or authorize the transaction.
The three initialization blocks of the enrollment phase 350 are: presentation block 302, generation block 304, and uploading block 306. At presentation block 302, a user presents his biometric identifier (e.g., fingerprint, DNA, face, iris, retina, etc.) and one or more types of account data associated with his account (e.g., an account number, a credit card number, a user's name). An appropriate biometric scanner is used to generate a digital representation based on a biometric identifier of the user. In this way, the user's unique biometric information (comprising the digital representation) may be obtained. This block is advantageously performed at a location (e.g., a bank) where the identity of the user can be verified (e.g., by bank tellers). In an embodiment, the biometric information may be encoded and/or encrypted so that if a malicious third party gains unauthorized access to the digital representation, the third party will not be able to identify the biometric information.
At generation block 304, a unique registered code is generated based on the user's unique biometric information which contains the digital representation obtained from the biometric scanner. For example, the registered code is generated by converting the biometric information of the user into an alphanumeric, numeric or binary code. As mentioned above, this biometric information may be encoded and/or encrypted. Additionally, the registered code may itself be encoded and/or encrypted to avoid malicious usage by third parties. As biometric identifiers are generally unique to each individual, it is expected that the registered code that is based on the biometric information is also generally unique to each user.
At uploading block 306, the user's account data and associated registered code are uploaded and stored on a database.
Once the three initialization blocks (302, 304, and 306) are performed, the enrollment phase 350 is complete. The verification phase 360 can commence and is performed whenever a user wishes to authorize a transaction.
The blocks in the verification phase 360 will be elaborated using the following example. In
At block 312, the merchant or acquirer (e.g., bank or financial institution that processes credit and/or debit card payments for products or services for a merchant) requests verification of the consumer in order to authorize the transaction (i.e., “authorization request 326”). Embodiments of the present invention are especially suited for “card not present” transactions (i.e., payment card transactions where the cardholder is not physically present with the card at the merchant or acquirer at the time the payment is effected). Such transactions are common in internet or online shopping scenarios. Thus, the authorization request 326 may request authorization to make a payment.
Optionally, at block 314, the authorization request 326 may request that an online payment wallet (e.g., a program or web service that allows users to store and control their online shopping information in one central place) is unlocked so that the online shopping information can be accessed. Thus, the authorization request 326 may request authorization to access an online payment wallet.
Although not shown in
At block 316, a payment gateway 316 receives the authorization request 326. The payment gateway 316 may be implemented on a server device or system. The payment gateway 316 can be configured to process and authorize payment transactions. For example, the payment gateway 316 can be configured to obtain the account data (e.g., account number) and transaction code for authorization of the transaction.
At block 318, the encrypted transaction code is decrypted and/or decoded. The transaction code is compared with the registered code that is stored at the database (see block 306). If the transaction code corresponds with or matches the registered code, as indicated by block 330, the transaction is authorized and the issuer is notified accordingly (block 320). In this instance, the approval flow 324 is initiated and the online payment wallet may be unlocked and the merchant/acquirer notified accordingly. Additionally or alternatively, a requested payment may be made when the approval flow 324 is complete.
If the transaction code does not correspond with or match the registered code, as indicated by block 332, the transaction is declined, i.e., not authorized. In this instance, the decline flow 322 is initiated and the online payment wallet may remain locked and the merchant/acquirer notified accordingly. Additionally or alternatively, a requested payment may not be made when the decline flow 322 is complete.
There may be one or more additional conditions for authorization, including sufficient funds in a debit/pre-paid account, or a credit limit of a credit account has been not been exceeded. For example, if the additional condition for authorization is the requirement for sufficient funds in a debit/pre-paid account, account data (comprising the account number) is obtained (e.g., at block 310). The payment gateway 316 checks with an issuer (e.g., a bank) 320 or financial services corporation if there are sufficient funds in the debit/pre-paid account identified by the account number. If there are sufficient funds, as indicated by 330, an approval flow 324 is initiated. On the other hand, if there are insufficient funds as indicated by 332, the decline flow 322 is initiated and the transaction is not completed.
Some embodiments of the present invention are suited for “card not present” transactions and advantageously do not require consumers to have their credit card with them at all times, nor remember both their credit card numbers and card security codes (i.e., card verification data (CVD), card verification number (CVN), card verification value (CVV or CVV2), card verification value code (CVVC), card verification code (CVC or CVC2), verification code (V-code or V code), card code verification (CCV), or signature panel code (SPC)) in order to complete transactions.
The method(s) and/or system(s) of the example embodiments can be at least partly implemented on a computer system 400, schematically shown in
The computer system 400 comprises a computer module 402, input modules such as a keyboard 404 and mouse 406 and a plurality of output devices such as a display 408, and printer 410.
The computer module 402 is connected to a computer network 412 via a suitable transceiver device 414, to enable access to e.g., the Internet or other computer networks and/or systems such as Local Area Network (LAN) or Wide Area Network (WAN).
The computer module 402 in the example includes a processor 418, a Random Access Memory (RAM) 420 and a Read Only Memory (ROM) 422. The computer module 402 also includes a number of Input/Output (I/O) interfaces, for example I/O interface 424 to the display 408, and I/O interface 426 to the keyboard 404.
The components of the computer module 402 typically communicate via an interconnected bus 428 and in a manner known to the person skilled in the relevant art.
The application program is typically supplied to the user of the computer system 400 encoded on a data storage medium such as a CD-ROM or flash memory carrier and read utilizing a corresponding data storage medium drive of a data storage device 430. The application program is read and controlled in its execution by the processor 418. Intermediate storage of program data may be accomplished using RAM 420.
It will be appreciated by a person skilled in the art that numerous variations and/or modifications may be made to the present invention as shown in the embodiments without departing from a spirit or scope of the invention as broadly described. The embodiments are, therefore, to be considered in all respects to be illustrative and not restrictive.
| Number | Date | Country | Kind |
|---|---|---|---|
| 2014012033 | Feb 2014 | SG | national |
