Patent Application
20120095852
This invention relates to a mobile payment account system, and more particularly to an improved mobile payment application on a mobile device to enable more efficient and secured contactless payment at an electronic point of sale.
Mobile payment account systems are generally known, in which portable electronic devices are configured to provide payment from an electronic wallet. Typically, these portable electronic devices are configured to enable a contactless communication with a merchant Point Of Sale (POS) terminal to carry out a payment transaction, for example using near field communication (NFC) technology. As described in the Applicant's co-pending application U.S. Ser. No. 12/891,866, incorporated herein by reference in its entirety, activated mobile payment account data may be stored in the secure memory of the portable electronic device which can then be used to carry out transactions with the merchant electronic POS terminal via a NFC link.
However, conventional mobile payment systems typically involve a complicated process in order for a user to effect a secured payment transaction from an electronic wallet. For example, U.S. Pat. No. 7,707,113 to Sprint Communications Company L.P. discusses a method of a portable electronic device providing payment from an electronic wallet with different levels of security. In a first level of security, the method prompts for input of a personal identification number (PIN) after the wallet has been opened and providing payment from the wallet after receiving the PIN. However, in another level of security, no PIN is required thus enabling efficient but unsecured payment transactions to be made from the electronic wallet.
Additionally, when customers use such a payment product to conduct low dollar transactions over contactless interfaces, a signature may not be required at the point of sale, nor a challenge for a numeric passcode (PIN) or a password. In the United States for example, customers are able to wave their payment device and authorize the payment transaction without further interaction. For any theft of payment devices, the liability for these low dollar swipe transactions is placed upon the issuing bank, not the customer and not the merchant.
For payment accounts residing on mobile devices such as contactless payment capable mobile phones, the theft of a phone now becomes immediately available for low dollar purchases without consumer verification prior to a purchase. The perpetrator can make as many low dollar transactions without being challenged for authentication and access the payment account. All of these low dollar transactions will be the responsibility of the issuing bank under current payment association dispute rules. Customers may elect to always require a numeric passcode challenge for a purchase transaction regardless of the value, but this is not required.
What is desired is a more efficient mobile payment system and method which facilitates expedient and secured payment transactions from an electronic wallet, and improved prevention of fraudulent use of the electronic wallet.
In one aspect of the present invention, a method is provided of facilitating secured payment from an electronic wallet on a portable device, comprising storing, on the portable device, an electronic wallet comprising data for completing a payment transaction, wherein said data includes a passcode for enabling access to the electronic wallet and a flag indicating whether input of the passcode is required to access the electronic wallet; receiving a command from a device remote from the portable device to set the flag to indicate that input of the passcode is required to access the electronic wallet; and responsive to a request to conduct a payment transaction from the electronic wallet, prompting for input of a passcode if the flag indicates that input of the passcode is required, verifying the input passcode, and providing payment information to authorize the payment transaction.
In another aspect, the present invention provides a method is provided of facilitating payment from an electronic wallet on a portable device, comprising storing, on the portable device, wallet application software for accessing the electronic wallet, including executable code for facilitating access to data defining one or more mobile payment accounts in the electronic wallet and executable code for facilitating activation of a secure payment from a mobile payment account; storing, on the portable device, a further payment application software associated with the executable code in the wallet application software for facilitating activation; and receiving a user input selection of the second application software and in response, directly executing the associated executable code in the first application software to facilitate activation of a secure payment from the mobile payment account.
In yet another aspect, the present invention provides a graphical user interface for facilitating payment from an electronic wallet on a portable device, comprising a first icon associated with wallet application software for accessing the electronic wallet, including executable code for facilitating access to data defining one or more mobile payment accounts in the electronic wallet and for facilitating activation of a secure payment from a mobile payment account, a second icon associated with executable code for facilitating direct activation of a secure payment from a mobile payment account, and receiving user selection of the second icon and directly executing the application software for facilitating activation of a secure payment from a mobile payment account.
In yet a further aspect, there is provided a portable device and computer program arranged to carry out the above method when executed by a portable device.
There now follows, by way of example only, a detailed description of embodiments of the present invention, with references to the figures identified below.
a is a block diagram showing the main hardware and/or software elements of a mobile device shown in
b is a block diagram showing the main functional elements of the mobile device shown in
A specific embodiment of the invention will now be described for a process for conducting a payment transaction using a mobile device at a merchant's electronic point of sale terminal. Referring to
As shown in
The mobile device 3 also includes a payment account wallet application module 8 storing processing instructions used to control the operation of the mobile device 3, for example to facilitate creation and management of one or more mobile payment accounts on the mobile device 3 and to handle the process of conducting a transaction with a merchant via the electronic POS terminal 5 using a mobile payment account on the mobile device 3, to effectively transfer funds from the mobile payment account on the mobile device 3 or an associated payment account issuer 10 to the merchant. As those skilled in the art will appreciate, the payment account wallet application module 8 may be provided as one or more software components of an operating system running on the mobile device 3 or as one or more separate software applications installed on the mobile device 3. Such software applications may be configured to run as background applications on the mobile device 3 that monitor for and activate upon receipt of appropriate messages or events, or may be launched by the user, so as to carry out the above operations. Alternatively, the payment account wallet application module 8 may be stored in the secure memory 4, and may for example be loaded into a virtual machine of the mobile device 3 to provide the functionality of the present embodiment.
A secure mobile payment account provisioning and activation process may be carried out between the mobile device 3 and the account management system 7, as described in the Applicant's above referenced co-pending application U.S. Ser. No. 12/891,866. The activated mobile payment account data stored in the secure memory 4 of the mobile device 3 can then be used to carry out transactions with a merchant electronic POS terminal 5 via the contactless communication link 9, whereby a requested amount of funds can be transferred from the mobile payment account stored in the mobile device 3 to the merchant's bank 12. Techniques and protocols for implementing the authorization and transfer of funds between the merchant POS terminal 5, the merchant bank 12, and the payment account issuer 10, for example via the payment association network 17, are commonly known and will be apparent to those skilled in the art.
Account Management System
The account management system 7 in the mobile payment system 1 will now be described in more detail with reference to
As shown in
The communications server 13 may also include a separate TSM unit 15 for securely routing the data to the mobile device 3, as will be known to the skilled person. In the above example, the TSM unit 15 in the communications server 13 would not access any of the sensitive portions of the encrypted data that is routed to the mobile device 3 via the cellular telephone network interface 14.
Mobile Device
Software and data may be transferred via the cellular network interface 33 or via a different data communication link interface 71 for example in the form of signals 72, which may be electronic, electromagnetic, optical, or other signals capable of being received by the data communication link interface 71 via a communication path 73 that carries the signals 72 and may be implemented using wire or cable, fiber optics, a physical phone line, a wireless link, a radio frequency link, or any other suitable communication channel. For instance, communication path 73 may be implemented using a combination of channels. As those skilled in the art will appreciate, the communication path 73 may be linked or merged with the communication path from the cellular network interface 33 to the cellular telephone network 11.
As mentioned above, the mobile device 3 includes a secure memory 4. The mobile device 3 is operable to receive the payment account data 6 and activation request messages from and send validation messages to the account management system 7 via a cellular telephone network interface 33 and the cellular telephone network 11, and to store the received payment account data 6 in the secure memory 4. The mobile device 3 is also operable to receive transaction authorization request messages from and send authorization messages to the merchant's POS terminal 5 via a contactless communications link interface 37 and the contactless communications link 9. As those skilled in the art will appreciate, communication between a POS terminal 5 and the mobile device 3 may involve transmission of data in a single direction from the mobile device 3 to the POS terminal 5, depending on an implemented protocol (such as the well known protocol used by the Discover Zip cashless payment system).
The mobile device 3 also includes a payment account wallet application module 8 as mentioned above, which stores processing instructions used to control the operation of the mobile device 3 to perform the various mobile payment account processes, as will be described below. As schematically illustrated in
In this embodiment, the mobile device 3 further includes a payment shortcut module 19 that provides a shortcut to the payment feature within the mobile payment wallet application module 8. The shortcut may be implemented as processing instructions that link to the processing instructions of the transaction authorization sub-module. Alternatively, the payment shortcut module 19 may comprise separate processing instructions used to control the operation of the controller 21 to carry out and authorize a transaction in response to user input from the user interface 22. Provision of the payment shortcut module 19 advantageously enables an improved user interface for the transaction payment process that expedites the purchase process at a POS terminal 5 as the user avoids having to navigate through multiple wallet screens of the mobile payment wallet application module 8 to authorize a payment transaction from the electronic wallet.
In an embodiment, the mobile payment wallet application module 8 may facilitate user navigation from any one of the wallet screens 24 to the main menu wallet screen 26. As those skilled in the art will appreciate, such navigation to the main menu wallet screen 26 may be direct or via one or more intermediary wallet screens 24. In this way, even though a user may have accessed the payment features of the wallet application module directly using the wallet application payment shortcut module 19 of the present invention, the user may be able to navigate to any other wallet screen 24 of the mobile payment wallet application module 8.
Also schematically illustrated in the exemplary embodiment of
The mobile device 3 may also include one or more other third party application modules 44 stored in the secure memory 4, for example an application module related to third party loyalty scheme. The secure memory 4 may also stores a UICC applet 45 which is an application to manage and hold the mobile network operator's functionality and secure information, such as a network key and GSM PIN.
b is a block diagram showing the main functional elements of the mobile device when configured to execute processing instructions of the payment applet 40 and the authentication applet 46, according to an embodiment of the invention. As will be discussed in greater detail below, the mobile payment wallet application module 8 may call the payment applet instance 40 to conduct a payment transaction process for example when a user waves the mobile device 3 past the contactless communication interface of the POS terminal 5. As shown in
The authentication applet 46 maintains a PIN entry flag 101 for the state of PIN entry, a PIN risk flag 103, a security word 105, a PIN locked state 107 (from an issuer perspective) and a PIN-verified flag 109, which are stored securely as wallet application secure data 6 in the secure memory 4 of the mobile device 3. In this embodiment, the PIN risk flag 103 is provided as an indication that an incorrect PIN was previously entered on the handset and therefore advantageously facilitates prevention of fraud from the issuer perspective, because the customer can be forced to enter a PIN effectively by setting the PIN risk flag 103. The PIN risk flag 103 further allows for flexibility in not forcing a PIN for low dollar transactions while keeping control over the use of the mobile payment account. Transactions may be allowed to continue uninterrupted unless certain conditions arise requiring PIN verification, which may include for example:
An authorization message includes indication that incorrect PIN was previously entered and no correct PIN was provided for this transaction (as those skilled in the art will appreciate, this is possible for example with option 2 for dCVV); in such an instance, the middleware server 16 can choose to decline the payment transaction.
Built-in logic to prompt for PIN entry if PIN was previously entered incorrectly or a configurable number of times without a PIN.
Built in logic to detect remote set PIN entry required for next transaction.
For example, when the PIN risk flag 103 is set to true, the authentication applet 46 may cause the payment applet 40 to raise itself asking for PIN entry via a NFC push request. This condition would send an error to the payment applet 40 to not allow a transaction at this time. Upon successful PIN entry, the PIN risk flag may be reset since the customer has successfully entered the PIN and thereby allowing the transaction to be made by the next wave and invocation of the payment applet 40. In effect, the PIN entry flag would be communicated from the authentication applet 46 to the payment applet 40 and through a payment authorization request to a merchant payment transaction authorization system via the electronic POS terminal 5, as is commonly known. The merchant's authorization system would then send the PIN entry information to for example a fraud/risk assessment unit (not shown) of the middleware server 16 to reset the PIN risk flag 103, as will be described in more detail below.
As those skilled in the art will appreciate, as an alternative, the processing instructions and functionality of the payment applet 40 and the authentication applet 46 may instead be provided as a single applet within the secure element 4. As yet another alternative, a plurality of applets may be included within the secure element 4 providing the functionality of embodiments of the present invention according to any desired bundling or collection of the respective processing instructions.
Payment Transaction Process
A brief description has been given above of the components forming part of the mobile payment system 1 of this embodiment. A more detailed description of the operation of these components in this embodiment will now be given with reference to the flow diagrams of
As shown in
an “Always Required” mode, which results in no valid authorization request being transmitted from the mobile device 3 if a PIN is not entered. In this mode, the user will be required to successfully verify their PIN in order to process a valid transaction, regardless of whether the transaction value is high or low.
an “Only As Necessary” mode, which results in an authorization request that has indication of successful user PIN entry being generated and transmitted by the mobile device 3, and authorization decisioning may then be performed for example at the middleware server 16 based on other factors such as a transaction risk level (i.e. taking into consideration if the value of the payment transaction is above a threshold value, such as $50).
If the mobile device 3 determines that the PIN mode is set to “Always Required” at step S4-1, then at step S4-3, the mobile device 3 prompts the user for entry of a PIN. As schematically illustrated in
At step S4-5, the mobile device 3 checks if user input of an entered PIN has been received, for example via the wallet screen 55. As those skilled in the art will appreciate, the entered PIN in the password field 56 may be masked on the displayed screen with hidden characters as the user inputs each character or number. Additionally, the user's sensitive mobile payment account details, such as card numbers, expiration dates and CVV codes, are encoded in the wallet application module 8 and never displayed on-screen, thereby further reducing the risk of fraud. If the mobile device 3 determines at step S4-5 that no PIN has been entered, then at step S4-7, the mobile device 3 checks if the handset has been waved past the contactless communication link interface of a POS terminal 5 and if not, processing returns to step S4-3 for the user to enter a PIN. As those skilled in the art will appreciate, when the mobile device 3 and POS terminal 5 are within range, one of the contactless communication link interfaces will initiate communication, referred to herein as “device handshaking”, to establish the contactless communication link, illustrated as step S4-9. It is commonly known that such contactless communication link interfaces generally communicate under the guidelines of ISO 14443, whereby the reader at the POS terminal 5 emits a signal that is received and interpreted by the contactless link interface 37 in the mobile device 3.
In this case, the user has not entered a PIN although the mobile device 3 is expecting a PIN and has proceeded to present the mobile device 3 to the POS terminal 5 at step S4-7. This may be because the user has simply forgotten to input a PIN and therefore at step S4-11, the POS terminal may receive an error code, which the POS terminal 5 may output so that for example a store clerk may see the displayed error and communicate to the customer. In an embodiment, the mobile device 3 may be arranged to display a message to the user indicating the need to enter a PIN in order to activate the payment feature. Alternatively, the mobile device 3 may be configured to not perform any interaction between the handset and the POS terminal 5 without a user entered PIN, and consequently at step S4-11, the POS terminal 5 may not react to the presence of the mobile device 3 because no appropriate data or request has been transmitted. Processing then returns to step S4-3 where the user is again prompted to enter a PIN.
On the other hand, if the mobile device 3 determines at step S4-5 that a PIN has been entered, then at step S4-13, the mobile device 3 verifies if the user input PIN is valid by comparing the input PIN with the user's pre-defined PIN stored in the wallet application secure data 6. If the mobile device 3 determines at step S4-13 that the user input PIN is not correct, then at step S4-17, the wallet application module 8 updates a count of the number of incorrect PIN entry attempts. As those skilled in the art will appreciate, the wallet application module 8 may be configured to check, at step S4-19, if a PIN is successively entered incorrectly a defined number of times and if so, to lock the PIN at step S4-21 and to display an indication that the PIN is locked at step S4-23. Locking of the PIN effectively prohibits the payment feature for the mobile payment account until the user has unlocked the PIN for example via a PIN reset process as will be apparent to those skilled in the art. On the other hand, if the PIN has not been successively entered incorrectly a defined number of times, then processing returns to step S4-3 where the user may be prompted to re-enter a correct PIN.
When the mobile device determines at step S4-13 that a correct PIN has been entered, then at step S4-25 the authentication applet 46 resets the PIN risk flag 103. At step S4-27, the authentication applet 46 sets the PIN-verified flag 109 that will be included in the next transaction authorization request. In an embodiment, the mobile device 3 may also be arranged to display a wallet screen 50 for example as schematically illustrated in
The above procedure described the processing steps for the “Always Required” PIN mode. If at step S4-1, the mobile device 3 determines that the PIN mode is set to the “Only as necessary” mode, then step S4-4, the mobile device 3 checks if the PIN Risk flag 103 is set, thus requiring input of a passcode before a payment transaction can be authorized. If the PIN Risk flag 103 is set, then processing proceeds to step S4-3 as discussed above. However, if the PIN Risk flag 103 is not set, then processing proceeds directly to step S4-27 where the PIN verified flag 109 is set and the payment feature is activated without requiring user input of a PIN or passcode.
Thereafter, the POS terminal 5 may instruct a payment transaction from the user selected mobile payment account to the merchant bank in the normal manner, as will be briefly discussed with reference to
At step S4-54, the middleware server 16 of the account management system 7 may receive confirmation of the completed transaction from the payment processing system 10. In response, at step S4-55, the account management system 7 may optionally transmit confirmation of the completed transaction to the mobile device 3 via the cellular telephone network 11, for example. At step S4-57, the mobile device 3 receives the payment transaction confirmation from the account management system 7 and outputs, at step S4-59, confirmation of the payment transaction via a wallet screen 52, for example as schematically illustrated in
In an embodiment, the user selected mobile payment account may be linked to a checking account at a payment account issuer 10. The authorized account details transmitted to the POS terminal 5 via the contactless communication link 9 identifies the payment account as a checking account. Typically, the POS terminal 5 will then request additional input from the user before the payment transaction can be completed by the POS terminal 5. For example, the additional input may be in the form of a prompt to select a specific payment type such as credit or debit, and the user may be required to input a signature for example via a touch sensitive input screen of the POS terminal 5.
In an embodiment, the middleware server 16 may be additionally configured to receive details of the payment transaction, for example from the payment account issuer 10 after the payment has been transferred or from the merchant POS terminal 5 or merchant bank 12 directly. In response, the middleware server 16 may be further arranged to communicate additional confirmation of the payment to the mobile device 3, including for example details of the amount of funds that was transferred, the name of the target recipient, and the date of the payment transaction. The additional payment confirmation may be displayed by the mobile device 3 as a further payment confirmation wallet screen 61, for example as schematically illustrated in
In an embodiment of the present invention, the payment processing (authorization and fraud monitoring) system 10a may additionally be configured to offer additional tools to remotely set the PIN risk flag 103 stored securely on the mobile device 3 to force a challenge the next time the mobile device 3 is used to make a transaction attempt as described above. With the PIN risk flag 103 set on the mobile device 3, the customer will be always be asked to enter their passcode/PIN before another transaction, regardless of transaction amount, can be made on the mobile device in the manner described above. Once the passcode is entered on the mobile device 3, the risk flag 103 is unset on the secure element 4 to allow a transaction to the point of sale. Without the PIN risk flag 103, a thief may steal a phone and would be able to use that phone indefinitely for multiple low dollar transactions without ever being prompted for a PIN. With the facility to remotely set the PIN risk flag 103, the payment processing system 10a could be additionally configured with a set threshold of usage or to react to unusual purchase patterns or based upon a number of low dollar transactions since the PIN was entered last. Such an implementation can beneficially be used to efficiently monitor low dollar transactions. As is commonly known, such low dollar transactions are typically the payment issuer's liability and are not generally able to be charged back to the retailer. As discussed above, the information that a verified passcode or PIN entry has been made would be sent with the next transaction to inform the merchant and payment issuer systems that the customer has verified themselves. Even small dollar transactions could be blocked at the issuing bank until the customer verified themselves.
In order to set the risk flag remotely, the payment processing system 10a may be configured to detect unusual usage based upon a variety of predefined risk factors. The risk factors detect unusual behavior from a customer and can include a combination of attributes such as unusual merchant locations for the customer, time of day differences from normal usage patterns, a higher velocity of transaction attempts, or other proprietary models. Current issuing bank processes can shut off the payment capability of a payment account until the user verifies possession of the payment account to the bank, but this new process allows for a gentler interaction between the customer and the bank. The present embodiment advantageously allows for the customer to verify themselves in the act of payment when the customer wishes to make their next payment. This further reduces the number of bank resources required to contact customers and manage the fraud flags on accounts.
Current plastic card based contactless technologies can only be updated when in contact with a chip card reader. Some payment association specifications allow for account updates to contactless cards via these chip card readers, but these are rarely used since these payment accounts are typically waved over a reader versus inserted into a dedicated chip card reader. Adding the payment account to a mobile device allows for additional data fields to be sent over the air to the mobile device to effect payments.
A summary of the remotely set risk flag process in mobile device enabled payment transactions will now be provided.
In this embodiment, the process would detect the anomaly using current payment authorization processes and then communicate the new risk flag value to the mobile device 3, for example over the air via a Trusted Service Manager (TSM) and cellular communication networks. The updated risk flag value would be stored into the secure memory space 4 of the mobile device 3 where the PIN risk flag 103 resides, in control of the payment account issuer 10. This PIN risk flag 103 updating process may start for example with an issuing bank fraud detection system deciding the payment account is not to be trusted without further customer verification. The fraud detection system may elect to prevent any new transactions until the PIN risk flag 103 has been cleared. The bank fraud detection system would then send a message to the bank's payment processing system 10a with the specific customer account information and risk flag setting. In many cases, the issuing bank will have a TSM of their own that will broker communication to a mobile network operator's TSM which will talk to the phone. The bank's payment processing system 10a would communicate with the issuing bank TSM to logically and physically prepare the new risk flag data commands for the targeted mobile device 3. The issuing bank TSM communicates with the mobile network operator TSM to deliver the new risk flag 103 to the mobile device 3. Once received by the mobile phone 3, the new risk flag setting will be placed into the secure memory storage 4 for use in the next transaction as described above with reference to
As described above, on the mobile device 3, the transaction process can vary based upon user provided settings to either require a passcode prior to any transaction attempt, or provide a passcode only for high value transactions—for example any transactions above a threshold value between $25 and $50 based upon the issuing bank and payment association rules. Payments from mobile devices 3 as described above generally follow a process as follows. The mobile device is held near a point of sale (POS) reader. The reader emits a signal received and interpreted by the contactless link interface in the mobile device. The contactless reader interface is a near field communication (NFC) process generally communicating under the guidelines of ISO 14443 and further refined by payment association specifications for specifying the message values between the contactless reader interface of the POS terminal 5 and mobile device 3.
The contactless reader interface identifies the point of sale communication is a payment request. As configured in the mobile device 3, the PPSE application 41 may be called to provide a payment account instance within the secure element 4 processor subsystem. The PPSE 41 determines the payment account currently selected for use on the mobile handset and hands control to a payment association specific instantiation 40 of a payment application that ultimately provides the account information.
The payment application 40 within the secure element 4 of the mobile device 3 will determine if the passcode was required, entered and then pass that information along with the payment account information for use in the transaction. The payment application 40 can also access other data values stored within the secure element 4 such as the risk flag 103. The payment application 40 may also use local values to determine if the user preference for the passcode needing to be verified or other counters for allowing only so many transactions before a passcode to be entered. The remote setting of the risk flag 103 is one opportunity for issuing banks to allow multiple small dollar transactions within normal customer transaction operations and ask only for the passcode in case of unusual customer activity.
If the risk flag 103 is set to a value requiring user input, the payment application 40 may return an error value to the contactless reader interface as well as messaging to the mobile device to alerting the user that a passcode is required before a transaction can be made. Other reasons for passcode required entry are if the user has set their preference to always require passcode entry for any transaction. Otherwise, the payment application will allow the transaction.
If the payment application 40 allows the transaction to proceed, the specific payment account data is passed back to the POS terminal 5. The POS terminal 5 interprets the message and assembles the payment account data for a transaction request to the association payment network. The message is routed through the payment network to the payment account issuer 10.
The transaction request is received at the payment account issuer 10 and processed for approval based upon funds availability as well as fraud decision strategies. The setting of the value of the risk flag is kept at the issuer systems and the current value of the passcode verification is sent with each mobile transaction request to the payment account issuer 10 over the payment network authorization message. Among all other rules determining transaction success at the issuer's payment authorization system, the transaction will be denied if the passcode is not verified and the risk flag is set to a value on the mobile device. Additional risk and fraud strategies may be employed by the payment account issuer 10 to determine if this transaction will be allowed as per normal business processes.
If the risk flag 103 is set at the time of transaction attempt, and the passcode has been entered—passed in via the transaction request, this action will clear then the payment processing system 10a flags that the fraud check has been passed. This action will restart any low dollar risk checks for unusual usage and the risk flag 103 may be set again at some future point of time.
The remote setting of a risk flag 103 therefore allows customers to make a number of low dollar transactions without ever having to enter a passcode if the bank system sees the activity as normal use. The customer will not be forced to enter a passcode every set number of low dollar transactions if the bank feels the risk is low.
An addition to this process could be a remote setting of the number of low dollar transactions to be used before the next passcode verification is required. If a local counter mechanism for passcode verification is employed on the mobile handset 3, the counter could be set remotely by the payment account issuer 10 via the same TSM process described above. This could allow a flexible counter to be increased over time as usage patterns are determined by the issuing bank and customer habits are formed. Upon successful entry of the passcode, the counter is reset to the value.
A number of advantages will be understood from the above description of the embodiments of the present invention.
In particular, the remote setting of a risk flag can prevent monetary loss by the issuing bank for low dollar transactions made by a perpetrator.
The solution allows the customer to easily self correct any possession activity verification without requiring an outbound contact from the issuing bank. The customer simply enters their passcode prior to making their next transaction.
The issuing bank can set the risk flag ahead of any transaction attempt by the customer at a merchant. The merchant checkout does not have to communicate a declined transaction attempt to the customer. If the merchant were an unattended vending machine, this error could cause customer confusion and frustration. The customer is able to correct their risk setting locally as part of the transaction flow.
The transaction information process flow with merchant point of sale systems is unchanged requiring no additional work by a merchant.
The embodiments allow the bank to decide when a customer requires authentication of the payment account based upon flexible risk criteria.
The embodiments also allow for remote management of local passcode verification counters to allow the bank to automatically ask for passcode verification after a configurable number of low dollar transactions.
It will be understood that embodiments of the present invention are described herein by way of example only, and that various changes and modifications may be made without departing from the scope of the invention.
For example, in the embodiments described above, the mobile payment account is provisioned on a mobile handset which communicates with the account activation system via a cellular telephone network. As those skilled in the art will appreciate, instead of a mobile handset, other portable electronic devices configured for contactless payment with a merchant electronic POS and having suitable input and display means, may be adapted to carry out the functionality of real time provisioning and/or activation as described in the above embodiment. Additionally, those skilled in the art will appreciate that the portable electronic device may be configured to communicate with the account activation system via any other form of communication channel, such as a wired or wireless network connection, a Bluetooth connection, or the like. Alternatively, the mobile payment account data may be provisioned on the portable electronic device by means of data transfer for example via any suitable data communication path or by way of a computer readable medium.
In the embodiments described above, the mobile device is provisioned with a mobile payment account through secure transfer of data representing the mobile payment account, which data including data defining an amount of pre-paid funds transferred from the user's payment account issuer and/or data identifying a user's account at a payment account issuer from which funds can be transferred to a merchant bank to complete a transaction. As those skilled in the art will appreciate, the mobile device may instead or additionally be securely provisioned with data representing one or more other types of accounts, such as an insurance account, a loyalty and rewards scheme membership or the like, and the account activation system may be configured to conduct a secure data transfer to the mobile device of data representing such an account, for example including the account or membership number or any other type of secure reference number.
In the embodiments described above, the wallet application secure data stores a plurality of flags that are accessed and maintained by the payment and authentication applets. As those skilled in the art will appreciate, the flags are data values indicative of one of a plurality of predefined states of an associated variable. In the embodiments described above, separate flags are provided for the plurality of variables, each flag having a true or false state. Many alternative forms of representing the flags and variable states will be apparent to the skilled person.
In the embodiment described above, the mobile device stores a plurality of application modules (also referred to as computer programs or software) in memory, which when executed, enable the mobile device to implement embodiments of the present invention as discussed herein. As those skilled in the art will appreciate, the software may be stored in a computer program product and loaded into the mobile device using any known instrument, such as removable storage disk or drive, hard disk drive, or communication interface, to provide some examples.
In the embodiments described above, the account management system is described as a separate entity to the payment account issuer and the associated payment processing system. As those skilled in the art will appreciate, the account management system may be provided as an integral part or sub-system of the payment account issuer and/or payment processing system.
Alternative embodiments may be envisaged, which nevertheless fall within the scope of the following claims.
