Data security system using mobile communications device

Embodiments of the invention provide systems and methods to unlock an account associated with a user for a limited period of time to enable the user conduct a transaction using funds from that account. In one embodiment of the invention, the user may select options relating to the transaction using a payment menu provided at a mobile communications device associated with the user. A notification message is received at the mobile communications device informing the user that the account is unlocked for a certain period of time and for a certain amount. After the transaction is complete, the user is notified and the account is locked again.

BACKGROUND

Embodiments of the invention relate to systems and method for improving the data security associated with financial transactions.

Financial institutions and other organizations are continuing to address problems relating to fraud in financial transactions. Examples of such transactions include merchant payment transactions, cash withdrawal and/or cash advances transactions, and person-to-person money transfer transactions. Fraudulent activities involving unauthorized access to financial accounts in most cases result in financial losses and unproductive use of resources (human and computing resources) for consumers, merchants and the financial institutions. Conventional data security methods can utlitize a number of steps and can utilize complex systems, however, fraudsters and hackers are still able to break the system and perform unwanted actions, if they get unauthorized access to a financial account number or a payment card.

Embodiments of the invention provide for improve methods for improving data security and reduce fraudulent transactions. Embodiments of the invention address these and other problems.

BRIEF SUMMARY

Embodiments of the invention provide systems and methods for unlocking a financial account associated with an authenticated user for a user specified unlock amount for a limited period of time in order to enable the user conduct a financial transaction using funds from that account. Some non-limiting examples of the transaction include withdrawing cash, sending money to a recipient, topping up an account, making payments, etc. By allowing limited access to a user's account, embodiments of the invention provide benefits, such as, reduction in fraudulent transactions and improved account security. A mobile payment application, in accordance with an embodiment of the invention, provides a convenient and easy user interface for conducting transactions in a secure manner.

One embodiment of the invention is directed to a method comprising sending to a server computer by a mobile communications device a request message to unlock an account associated with a user for conducting a transaction, providing to the server computer a passcode and an unlock amount specified by the user, receiving from the server computer a notification message at the mobile communications device that the account associated with the user is unlocked for a limited period of time if the passcode is verified, and generating by the mobile communications device an output message comprising the notification message.

Another embodiment of the invention is directed to a server computer comprising a processor and a non-transitory computer readable storage medium, comprising code executable by the processor for implementing a method comprising sending to a server computer a request message to unlock an account associated with a user for conducting a transaction, providing to the server computer a passcode specified and an unlock amount by the user, receiving from the server computer a notification message that the account associated with the user is unlocked for a limited period of time if the passcode is verified, and generating an output message comprising the notification message.

Another embodiment of the invention is directed to a method of receiving at a server computer from a mobile communications device, a request message to unlock an account associated with a user for conducting a transaction associated with the account, transmitting by the server computer to the mobile communications device a request for a passcode and an unlock amount, verifying by the server computer the passcode based on account information associated with the user stored in a database communicatively coupled to the server computer, and unlocking the account for a limited period of time to allow conducting the transaction using the account if the passcode is verified.

Another embodiment of the invention is directed to a server computer comprising a processor and a non-transitory computer readable storage medium, comprising code executable by the processor for implementing a method comprising receiving from a mobile communications device, a request message to unlock an account associated with a user for conducting a transaction associated with the account, transmitting to the mobile communications device a request for a passcode and an unlock amount, verifying the passcode based on account information associated with the user stored in a database communicatively coupled to the server computer, and unlocking the account for a limited period of time to allow conducting the transaction using the account if the passcode is verified.

These and other embodiments of the invention are described in further detail below with reference to the Figures and the Detailed Description.

DETAILED DESCRIPTION

Prior to discussing embodiments of the invention, description of some terms may be helpful in understanding embodiments of the invention.

A “payment menu” may include a menu with options related to payment for a financial transaction. For example, the payment menu may include options for withdrawing cash from an account, transferring money to another account, making a payment for a purchase, viewing account balance, paying bills, etc. The payment menu may be displayed on a screen of a device and an option from the payment menu may be selected by a user by entering a number associated with the option on a keypad, by touching the option on the screen, by saying the number or the option or using any other suitable way of communication with the device.

A “transaction” may include exchange of data and/or information between two entities. In one embodiment, a transaction may involve a financial account for activities such as, making a purchase, money transfer, cash withdrawal from a bank account, etc. In some embodiments, a transaction may be conducted at an automatic teller machine (ATM) or at an access device (e.g., point-of-sale (POS) terminal, personal computer, device reader, etc.). The transactions may be conducted using a portable device, such as, mobile communications device (phone, tablet, PDA, RFID tag) or a payment card (credit, debit, rewards or loyalty, gift card, etc.).

A “user” may include an entity, such as, an individual, capable of conducting a transaction. In some embodiments, the user may be able to use a portable device (payment card, mobile device, etc.) to conduct a transaction online, at an ATM or at an access device. In one embodiment, the user may be able to access a payment menu on a device so that an account associated with the user may be unlocked for a limited period of time to allow the user for conducting a transaction.

A “mobile communications device” may include an electronics device capable of receiving and sending data and information wirelessly. Some non-limiting examples of a mobile communications device include mobile phones, notebooks, laptops, tablets, PDAs, netbooks, etc. In some embodiments, a mobile communications device may be associated with financial accounts of a user that may be accessed by a mobile payment application for allowing the user to initiate financial transactions using the mobile communications device. In some embodiments, a mobile communications device may be used in association with a payment card (e.g., credit card, debit card, check card, etc.) for conducting financial transactions as well as for card-not-present transactions.

A “passcode” may include a personal code that may be provided by a user for authentication. In one embodiment, the passcode is setup by the user while registering a financial account with a mobile pre-paid service. The passcode may be a combination of digits, alphabets or alphanumeric characters. In some embodiments, the passcode may be of certain minimum length and may not exceed certain maximum length, e.g., the passcode may be 5-8 digits long. In one embodiment, a server computer may authenticate a user by verifying the passcode provided by the user in order to allow the user access to a financial account associated with the user for conducting a transaction.

A “notification message” may include a message that may be communicated to a mobile communications device associated with a user. In some embodiments, the notification may include a text message, an SMS (short message service), an email, a web post, a phone call or any other suitable form of communication. In one embodiment, the notification message may indicate the user that an account associated with the user is unlocked for a certain period of time. In one embodiment, the notification message may be related to a financial transaction conducted by the user, e.g., available balance in the user's financial account.

“Unlocked” may indicate that an account is not blocked or locked, i.e., the account may be accessible for conducting a transaction, such as, withdrawing money, transferring money to another account, paying bills, making a purchase, etc. When an account is blocked or locked, the account owner may not have access to that account or may not be able to conduct transactions using that account. In some embodiments, an account may be unlocked for a limited period of time, i.e., for 10 minutes. In some embodiments, the account may be locked again after the unlocking period expires.

An “unlock amount” may include an amount for a transaction specified by a user to allow for the transfer of funds into or out of an account associated with the user. The amount can be of any suitable magnitude, and can be less than the amount of funds within an account.

In some embodiments, an account may be locked by providing logic, in a central server computer, that declines requests for authorization for transactions above the unlock amount. Authorization requests for transactions below the unlock amount are approved.

As used herein, an “access device” may be any suitable device for communicating with a merchant computer or payment processing network, and for interacting with a payment device, a user computer apparatus, and/or a user mobile device. An access device may generally be located in any suitable location, such as at the location of a merchant. An access device may be in any suitable form. Some examples of access devices include POS devices, cellular phones, PDAs, personal computers (PCs), tablet PCs, hand-held specialized readers, set-top boxes, electronic cash registers (ECRs), virtual cash registers (VCRs), kiosks, security systems, access systems, Websites, and the like. An access device may use any suitable contact or contactless mode of operation to send or receive data from, or associated with, a payment device and/or a user mobile device. In some embodiments, where an access device may comprise a POS terminal, any suitable POS terminal may be used and may include a reader, a processor, and a computer-readable medium. A reader may include any suitable contact or contactless mode of operation. For example, exemplary card readers can include radio frequency (RF) antennas, optical scanners, bar code readers, or magnetic stripe readers to interact with a payment device and/or mobile device.

In one embodiment of the invention, a mobile payment application associated with a user's mobile communications device may be utilized to unlock a financial account for conducting a transaction. The user may be able to choose a type of transaction and an amount for the transaction using a payment menu provided by the mobile payment application. In some embodiments, the user may be able to select a financial account from a list of financial accounts associated with the user for a particular type of transaction. In some embodiments, the available balance for an account may be presented to the user before making a selection for the transaction. In some embodiments, a sub-list for the type of transactions may be presented after the user selects a type of transaction.

In some embodiments, the user may be prompted to enter a passcode to authenticate the transaction as well as an unlock amount. The prompts for the passcode and the unlock amount may be part of the same user interface or may be provided on separate interfaces. If the passcode is verified, the user may receive a notification message indicating that the account is unlocked, the current balance for that account and the length of time the account will be unlocked. The user then may be able to conduct a transaction using the funds from that account for the length of time the account is unlocked. However, the amount that the user is able to transfer from the account is less then or equal to the unlock amount. If the user desires to conduct an ATM transaction, the user may walk up to an ATM and enter a card linked to that account and conduct the transaction (e.g., withdraw cash, transfer money to another account, etc.). In some embodiments, a list of closest ATMs located near the user may be presented to the user based on the location of the user's mobile communications device. After the transaction is complete, the user may receive a notification message (e.g., an SMS) on the user's mobile communications device and the current balance. The user account may be locked again after the length of time is expired or the transaction is complete. The user may need to trigger the mobile payment application again for unlocking that account or another account to initiate another transaction.

FIG. 1illustrates certain elements of an exemplary system in which one or more embodiments of the invention may be implemented.

A user102may utilize a mobile communications device104to conduct transactions at an access device118, a client computer120, an agent mobile device124associated with an agent126or at an ATM128. The mobile communications device104may be a mobile phone, tablet, PDA, netbook, laptop, etc. In some embodiments, the mobile communications device104may be linked to a payment card (credit card, debit card, check card, prepaid card, etc.) associated with the user102for conducting financial transactions. In some embodiments, the user102may have one or more accounts numbers or payment tokens associated with the mobile communications device104(e.g., in a contactless chip or card) such that the user102may conduct a transaction with a device reader or an access device using a near field communications (NFC) capability, such as, RF, infrared or optical communications mechanism.

The mobile communications device104may be communicatively coupled to a mobile gateway108via a mobile communications network106. The mobile gateway108may be operably coupled to the mobile communications network106(e.g., a wireless cellular network) to a second network (such as Internet) coupled to a payment processing network110. The mobile gateway108may be configured to perform data processing operations by taking into consideration differences in network protocols between the two networks for transfer of data and information.

The payment processing network110may include data processing subsystems, networks, and operations used to support and deliver authorization services, and clearing and settlement services. An example of payment processing network110includes VisaNet®, operated by Visa®. The payment processing network110may include wired or wireless network, including the Internet. An acquirer computer112is typically a system for an entity (e.g., a bank) that has a business relationship with a particular merchant or other entity. Acquirer computer112may route an authorization request for a transaction initiated by the mobile communications device104at the merchant computer114to the issuer computer116via the payment processing network110.

The issuer computer116is typically a computer run by a business entity (e.g., a bank) that may have issued the payment (credit/debit) card, account numbers or payment tokens used for the purchase. Some systems can perform both issuer computer116and acquirer computer112functions. In some embodiments, an account associated with the user102may need to be unlocked so that the user102may have access to the funds associated with the account for conducting a transaction. When a transaction is initiated by the user102using a payment account associated with the issuer computer116, the issuer computer116verifies the user's account and responds with an authorization response message to the acquirer computer112that may be forwarded to the mobile communications device104. If the authorization is approved, the transaction may be completed and a notification message may be sent to the user102on the mobile communications device104.

In other embodiments of the invention, the issuer computer116, acquirer computer112, and the payment processing network110may be embodied by a single payment processing system.

In some embodiments, the user102may initiate a purchase transaction using the access device118or the client computer120. The access device118may be a point-of-sale (POS) terminal, a phone, a device reader, a computer or any such device capable of conducting a transaction. The client computer120may be a personal computer that may be used for card-not-present (CNP) transactions. The access device118and the client computer120may be communicatively coupled to a merchant computer114via a communications network122. The communications network122may be based on Internet Protocol (IP) technology (e.g., secure socket layers (SSL), hypertext transfer protocol secure (HTTPS), etc.), dial-up modem phone line or any other suitable communications network capable of performing secure exchange of data and information.

In some embodiments, the user102may conduct a cash withdrawal transaction at the ATM128or at the agent126. The agent mobile device124associated with the agent126and the ATM128may be communicatively coupled to an issuer computer (or a financial institution)116via a communications network130. The agent mobile device124may be a mobile phone, laptop, tablet, PDA, netbook or any such electronic device capable of executing the cash withdrawal transaction. The communications network130may be based on IP technology, dial-up modem or any other suitable communications network capable of performing secure exchange of data and information. In some embodiments, the communications network130may include gateways or other networks for providing proper communication between the issuer computer116and the ATM128or the agent mobile device124.

In some embodiments, the user102may also send money or perform a money transfer process with respect to a recipient132. The recipient may operate a recipient mobile device134. Once the money is transferred to an account associated with the recipient132, or once the transaction is otherwise authorized, the payment processing network110may send a notification message to the recipient mobile device134via the mobile communications network106informing of the transaction.

In one embodiment of the invention, Unstructured Supplementary Service Data (USSD) capabilities may be utilized to implement real-time sessions between the mobile communications device104and a USSD application platform that may be hosted on a server computer. In one embodiment of the invention, the server computer may be part of the payment processing network110. The user102may invoke the USSD service by entering a shortcode on the mobile communications device104, thus allowing the data transfer between the mobile communications device104and the USSD application platform until the service is complete. In one embodiment, the user102may enter a shortcode to launch a payment menu associated with a mobile payment application based on the USSD service. The mobile payment application may enable the user to perform financial transactions, such as, payments, money transfer, top-up, bill payments, cash withdrawal, etc. using the payment menu.

FIG. 2illustrates certain elements of an exemplary mobile communications device that may be used to implement embodiments of the invention.

As discussed with reference toFIG. 1, the mobile communications device104may be configured to execute, display and/or provide the user102one or more applications relating to financial transactions. An antenna202may be used to transmit and receive signals, exchange data or other information with other entities, such as, the mobile communications network106or the access device118. An10(input-output) interface204may be configured to interface with various entities such as keypad, display, mouse, track ball, touch screen, microphone, speaker, etc. A contactless element206may include a secure data storage element or a data transfer element. In some embodiments, user financial account information (e.g., Primary Account Number (PAN), payment tokens, Personal Identifier Number (PIN), etc.) may be stored on the contactless element206. In some embodiments, information (e.g., name, account number, phone number, email, etc.) relating to the recipients associated with the user102may be stored on the contactless element206. A memory210may be a non-volatile memory that can retain stored information when not powered, such as, Read Only Memory (ROM), Flash, or magnetic storage devices. A Global Positioning System (GPS) device222may be configured to determine the location of the mobile communications device104based on satellite ranging. In some embodiments, the location of the mobile communications device104may be determined based on cellular triangulation or using any location based service known in the art.

The mobile communications device104may include a processor208or processing elements that execute instructions or code in order to implement methods, processes or operations. The mobile communications device104may also include a Computer Readable Medium (CRM)212comprising code, executable by the processor208for implementing methods using embodiments of the invention. In some embodiments, the CRM212may comprise a mobile payment application for enabling the user102to conduct a financial transaction when a server computer unlocks an account associated with the user102for a certain period of time. In one embodiment, the mobile payment application may comprise a transmit-receive module214, a user interface module216, a message processing module218and a user information module220as part of the CRM212.

The mobile payment application may be configured to enable the user102to select a type of transaction and an amount for the transaction using a payment menu. In some embodiments, the payment menu may be provided in response to the user102entering a shortcode (e.g., #575#) on the mobile communications device104(e.g., using a touch screen or keypad or speaking into a microphone). The mobile payment application may also be configured to communicate with a server computer that may be associated with the payment processing network110such that an account associated with the user102may be unlocked for a limited period of time to allow the user102perform a transaction using that account (e.g., withdraw cash). The user may be able to provide a passcode for authentication and also receive messages from the server computer relating to the account balance and whether the transaction is successful or aborted using the mobile application application. In some embodiments, the communication between the mobile application application216and the server computer may be performed using USSD protocol.

The transmit-receive module214may be configured to transmit and receive data and information between the mobile communications device104and other entities (e.g., payment processing network, access device, etc.). In some embodiments, the transmit-receive module214may comprise a decoder and an encoder for decoding and decrypting received data and for encrypting and encoding data for transmission in order to ensure secure communication with other entities. In some embodiments, the transmit-receive module214may be configured to perform data formatting for compatability reasons.

The user interface module216may be configured to present a payment menu to the user102using the 10 interface204. For example, the payment menu may be presented on a display screen or on a speaker communicatively coupled to the 10 interface204. The user interface module216may also be configured to receive and process user input from the payment menu via the 10 interface204, for example, entries on a keypad, touchscreen or spoken into a microphone communicatively coupled to the IO interface204. Using the payment menu, the user102may select a type of transaction and an amount for the transaction. In some embodiments, the payment menu may be presented in response to a shortcode provided by the user102using a keypad, touchscreen or microphone associated with the mobile communications device104.

The message processing module218may be configured to generate a request message to unlock an account associated with the user102when the user102initiates a transaction using the payment menu. The request message may be properly formatted and transmitted by the transmit-receive module220to the payment processing network110. The message processing module218may also be configured to receive and process messages from the payment processing network110via the transmit-receive module220. For example, the message processing module218may receive a notification message when the account is unlocked and a confirmation message when the transaction is complete. The message processing module218may also receive a request for a passcode to authenticate the user before the account is unlocked. The message processing module218may process the received messages and generate output messages comprising the received messages for the user102that may be presented on a display screen or to a speaker through the user interface module216.

In some embodiments, the user may be validated based on the user information stored on the mobile communications device104. For example, the user's passcode or any other relevant information (e.g., account numbers, personal information, PIN, etc.) may be stored on the memory210that may be accessed by the user information module220to authenticate or validate the user102. For example, when the user102provides a passcode in response to a request received from the payment processing network110, the passcode provided by the user102may be received by the user interface module216and processed by the user information module220to determine if the passcode matches with the passcode previously stored in the contactless element206. If the passcode does not match, the user interface module216may transmit an error message to the payment processing network110informing that the user was not authenticated. In one embodiment, the user information module220may also be configured to access a list of recipients and their contact information associated with the user102stored in the memory210for performing money transfer transactions. In some embodiments, the user information and the recipients information is stored on the mobile communications device104when the user102registers for a mobile pre-paid service.

FIG. 3illustrates certain elements of an exemplary server computer for implementing one or more embodiments of the invention.

A server computer300may be part of the payment processing network110, the issuer computer116or a third party. The server computer300may include a processor308or processing elements that execute instructions or code in order to implement methods, processes or operations. The server computer300may also include a CRM310comprising code, executable by the processor308for implementing a method using embodiments of the invention. In one embodiment, the CRM310may include a communication module312, a payment menu interface module314, a message generator module316, a user authentication module318, a lock-unlock module320, and a transaction processing module322.

A network interface302may be configured to interface with other entities on the network, for example, the mobile gateway108, the acquirer computer112, the issuer computer116, and such. In some embodiments, the network interface302may be configured to support different networks associated with different entities. For example, the payment processing network110may communicate with the issuer computer116using one type of network (e.g., IP network) and with the mobile communications device104using another type of network (e.g., cellular network).

A memory304may be coupled to the processor308and may be a non-volatile memory that can retain stored information when not powered, such as, Read Only Memory (ROM), Flash, or magnetic storage devices. In some embodiments, the processor308may also be communicatively coupled to an external memory, e.g., hosted on a cloud server.

The server computer300may be configured to receive a request to unlock an account associated with the user102for conducting a transaction associated with the account. Some non-limiting examples of transactions include purchase transactions using the access device118or an online transaction using the client computer120, a cash withdrawal transaction at the agent126or at the ATM128, a money transfer transaction to a recipient132. The information related to user's account, such as, account numbers, passwords, account balance, user personal information, etc., and also the recipients may be stored in a database306that may be communicatively coupled to the processor308. In some embodiments, the access to the accounts may be locked by default unless an authenticated request to unlock the account is received. Also, the database306may also temporarily store the unlock amount received from a user's mobile communications device.

The communication module312may be configured to transmit and receive data and information for communicating with other modules or entities. For examples, the communication module312may transmit to and receive messages from the mobile communications device104. In some embodiments the messages received from external entities may have been encoded and encrypted for secure communication. The communication module312may decode and decrypt the message to determine whether the message is for a request to unlock an account, a type of transaction, an amount for the transaction, a passcode for authentication or any such message transmitted from the mobile communications device104. In some embodiments, the communication module312may also be configured to format, encode and encrypt the messages transmitted to other entities, such as, the mobile communications device104and/or the issuer computer116. The messages for transmitting to other entities may be generated by the message generator module316.

The payment menu interface module314may be configured to present a payment menu on the mobile communications device104associated with the user102. In some embodiments, the payment menu interface may be based on a USSD protocol to establish a real-time session with the mobile communications device104. The payment menu interface module314may provide options to the user102for initiating a transaction, selecting a type of transaction, an amount for the transaction, etc. In some embodiments, the payment menu may be presented to the mobile communications device104in response to receiving a certain shortcode from the mobile communications device104.

The message generator module316may be configured to generate messages that may be transmitted to external entities via the communication module312. For example, the message generator module316may generate a notification message that an account associated with the user102is unlocked for a limited period of time. The notification message may be generated in response to a request to unlock the account for conducting a transaction. The notification message may also include the account balance and how long the account may be unlocked. If the transaction involves withdrawing money from an ATM, the notification message may also include an indication for finding an ATM to withdraw cash within certain time limit. In some embodiments, a list of nearest ATMs may be displayed based on the location of the mobile device that initiated the transaction request. In another example, the message generator module316may also generate a message for the user102requesting for a passcode to authenticate the user102before an account associated with the user may be unlocked. In some embodiments, the message generator module316may also generate a message for a recipient (e.g., recipient132) when a money transfer transaction to the recipient is completed by the user102.

The user authentication module318may be configured to authenticate the user before processing the request to unlock the account. In one embodiment, when the communication module312receives a request to unlock an account for a type of transaction, the message generator module316may generate a message requesting the user102to provide a passcode for authentication. The user102may provide a passcode using the mobile communications device104that may be received using the payment menu interface module314. The user authentication module318may retrieve the previously stored passcode and any other relevant authentication information associated with the user102from the database306and compare to validate whether the user is an authorized user of the account. If the passcode is not verified, the payment menu interface module314may output an error message and send another request to enter the passcode or close the current session and go back to the main menu. If the passcode is verified, the account may be unlocked by the lock-unlock module320.

The lock-unlock module320may be configured to keep the accounts associated with the registered users locked, i.e., funds associated with the accounts may not be accessed for conducting transactions, unless there is an authenticated request to access the account for a transaction. If the request to unlock an account has been authenticated by the user authentication module318, the lock-unlock module may unlock the account for a limited period of time. The lock-unlock module320may contain code for denying authorization requests when the account to be accessed is in a locked state. It may also contain code for authorizing or passing on authorization requests to an issuer when the account is in an unlocked state and when the authorization request is for an amount that is less then the user specified unlock amount. The lock and/or unlocked state of a particular account may be designed in any suitable manner. For instance, a flag which has a state of “0” may indicate that the account is unlocked. A state of “1” may indicate that the account is in a locked state.

In some embodiments, the limited period of time may be determined based on a timer324. The timer324may be an electronic counter of certain length. The timer324may be pre-set or updated based on user requirement (i.e., configured in mobile payment application) or by an authorized entity, such as, the payment processing network110or the issuer computer116. In some embodiments, an unlock message may be sent to the issuer computer116for unlocking the associated account maintained by the issuer computer116. For example, for withdrawing cash from the ATM128, the issuer computer116unlocks the account associated with the user's ATM card or payment token to allow the user102access to the funds in that account.

The transaction processing module322may be configured to process the transaction once the account is unlocked and the user102initiates a transaction. The transaction processing module322may receive an authorization request message from the merchant computer114via the communication module312. The transaction processing module322may process the authorization request message and forward it to the issuer computer116for authorization. After the issuer computer116authorizes the transaction, the transaction processing module322may receive an authorization response message from the issuer computer116that may be forwarded to the merchant computer114via the acquirer computer112for completing the transaction. In some embodiments, the timer324may be programmed with a suitable value so that the account stays unlocked until the transaction is complete. Once the transaction is complete, the message generator module316may generate a confirmation message for the user102that may be output on the mobile communications device104via the user interface module216.

If the transaction selected by the user102involved sending money to the recipient132, the payment menu interface module314may receive information related to the recipient132provided by the user102. The recipient account information may be retreived from the database306and provided to the issuer computer116for the issuer computer116to transfer money to an account associated with the recipient132. The message generator module316may also generate a message for the recipient132indicating the money transfer that may be transmitted to the recipient device134.

A method implemeting embodiments of the invention and exemplary screen shots will be discussed with reference toFIGS. 4 and 5A-5H.

FIG. 4illustrates a process flow diagram implementing a method in one embodiment of the invention.

In step402, the user102enters a shortcode on the mobile communications device104to launch a payment application for conducting a transaction, and the shortcode is transmitted to the server computer300in the payment processing network110. In one embodiment, the user102may enter the shortcode (e.g., #575#) using a keypad associated with the mobile communications device104. The shortcode may be processed by the user interface module216and transmitted to the server computer300by the transmit-receive module214indicating that a particular application associated with the shortcode (e.g., a mobile payment application) needs to be launched on the mobile communications device104. As illustrated inFIG. 5A, a screen shot502displays a shortcode518(e.g., #575#) on a device screen (e.g., a screen associated with the mobile communications device104). A reply button520on the device screen may be selected by the user102to send a message to the server computer300. An exit button522may be selected by the user102to exit out of the application.

In response to receiving the shortcode from the mobile communications device104, the server computer300may launch a USSD service to initiate a realtime session with the mobile communications device104. In some embodiments, the USSD service may be associated with a mobile prepaid service in which the user102is registered. During the registration process, an acccount number (for a prepaid, credit, or debit account or device such as a card) associated with an issuer may be associated with a phone number, such that the server computer300can determine the account number from the phone number. As illustrated in an exemplary screen shot504inFIG. 5B, a welcome screen524may be displayed on the mobile communications device104indicating start of the prepaid service. In some embodiments, registering for the pre-paid service may involve associating a user's account and personal information and recipients information with the mobile communications device104.

In step404, a payment menu is transmitted from the server computer300to the mobile communications device104and is displayed on the mobile communications device104for the user102to make a selection. For example, the payment interface module314may launch a USSD menu on the mobile communications device104if the user102is registered with the prepaid service. As illustrated in an exemplary screen shot506inFIG. 5C, a payment menu526provides a list of options to choose from. For example, the user102may choose to cash out (option 1), send money (option 2), make payment (option 3), pay bills (option 4), top-up (option 5) or view account options (option 6). In some embodiments, when the user102makes a selection, a sub-list related to that option may be displayed to further narrow down the option. Note that the exemplary screen shot506illustrates that the user102may reply with a number from the list, however, it is understood that any suitable method of reply is acceptable, e.g., by keying in the number, by touching the option on a touch screen associated with the device using a finger or a stylus or by speaking the option in a microphone associated with the mobile communications device104.

In step406, the user102makes a selection for a type of transaction from the payment menu526and this selection is transmitted from the mobile communications device104to the server computer300. For example, to withdraw cash, the user102may select option 1 (cash out) on the payment menu526. In one embodiment of the invention, selecting a transaction option may generate a request to unlock an account. As discussed, embodiments enable the user to specify an unlock amount corresponding to-a maxmimum amount of cash that can be withdrawn while the account is unlocked. As illustrated in an exemplary screen shot508inFIG. 5D, selecting option 1 to withdraw cash may further present a sub-list528to the user102to select whether the cash out will be from an ATM (option 1) or from an agent (option 2). The user102may select option 1 to withdraw cash from an ATM, e.g., the ATM128.

In step408, the server computer300transmits a request message to the mobile communications device104for an ATM cash out amount. The user interface module216may output the current balance on the device screen and the user102may be prompted to enter an unlock amount for the transaction. As illustrated in a screen shot510inFIG. 5E, when the user102selects an option to withdraw cash from the ATM128, a current balance530of $681.04 is displayed on the screen and the user102is prompted to enter the ATM cash out amount532. The cash out amount532may be the unlock amount. The user102may withdraw an amount equal to or less than the unlock amount from the ATM128.

In step410, in response to entering an amount for withdrawing cash by the user102, the mobile communications device104transmits the unlock amount to the server computer300.

In step412, in response to receiving a request message to unlock an account associated with the user102, the server computer300in the payment processing network110transmits a request message to the mobile communications device104operated by the user102to provide a passcode to confirm the transaction. As illustrated in a screen shot512inFIG. 5F, for the ATM cash out amount534(or unlock amount in this case), the user102is prompted to reply with a passcode536to confirm the transaction.

In step414, the user102enters a passcode into the mobile communications device104when prompted, and the request to unlock the account may be transmitted by the mobile communication device104to the server computer300. In one embodiment of the invention, providing a passcode may generate a request to unlock an account by the message processing module218. The passcode may be of certain length and may be a combination of digits and/or alphanumeric characters. The passcode may have been setup by the user while registering for the prepaid service.

The server computer300verifies the passcode and unlocks the account for a certain duration if the passcode is verified. In some embodiments, for verifying the passcode, the user authentication module318may compare the passcode provided by the user102with a passcode associated with the user102retrieved from the database306storing relevant information relating to the users accounts registered in the prepaid service. If the passcode is verified, the lock-unlock module320may unlock the account associated with the user102for a duration of time based on the timer324.

In step416, the message generator module316may generate a notification message indicating to the user102that the account is unlocked. The message processing module218may process the notification message and generate an output message comprising the received message that may be presented on a display screen or to a speaker through the user interface module216. If the passcode does not match then an error message may be generated by the message generator module316. In some embodiments, the user may be prompted again to enter the passcode. In some other embodiments, the current transaction may be aborted and the home screen may be displayed for the user102to make another selection. The user102may proceed with the transaction after receiving the notification that the account is unlocked As illustrated in a screen shot514inFIG. 5G, a message538that the account is unlocked is displayed on the device screen. In some embodiments, current balance540may also be displayed on the device screen. A clock546may be displayed to indicate current time. A time542until the unlock is valid (e.g., time+10) may also be displayed. If the transaction was to withdraw cash from the ATM, a message544to go to an ATM within 10 minutes to withdraw cash may be displayed. The user may walk up to the nearest ATM and withdraw cash using a card linked to the unlocked account and by entering a PIN. In some embodiments, a list of nearest ATMs may be provided based on the location of the mobile communications device104that may be determined based on a known location based service, i.e., GPS, cellular triangulation, etc.

In step418, the server computer300may notify the issuer computer116that the account associated with the user102is unlocked so the issuer computer116may release the funds associated with the account. In some embodiments, only the transaction amount entered by the user102is unlocked, i.e., accessible for the transaction.

In step420, the user102provides a payment card or a token and a PIN to the ATM128. The payment card/token may be linked to the unlocked account so that the user102has access to the funds associated with the account for a limited period of time. In other embodiments, only the PIN may be needed (i.e., the payment card is not needed).

In step422, an authorization request may be transmitted to the issuer computer116in order to complete the cash withdrawal transaction. In some embodiments, the authorization request may be received by the payment processing network110, which forwards it to the issuer computer116.

In step424, the issuer computer116may approve the authorization for the cash withdrawal and transmit an authorization response message comprising an approval indicator to the ATM128.

An “authorization response message” may be an electronic message reply to an authorization request message generated by an account issuer, payment processing network, mobile payment processor, or a mobile network operator. The authorization response message may include, by way of example only, one or more of the following status indicators: Approval—transaction was approved; Decline—transaction was not approved; or Call Center—response pending more information, may call the toll-free authorization phone number. The authorization response message may also include an authorization code, which may be a code that an issuing bank or other entity (e.g. a mobile network operator or mobile payment processor) returns in response to an authorization request message in an electronic message (either directly or through the payment processing network) to the transaction apparatus (e.g. an ATM) that indicates approval of the transaction and completes the transaction. The code may serve as proof of authorization.

In step426, the user102may be able to withdraw cash from the ATM128. In some embodiments, the user102may be able to withdraw only the authorized unlock amount, e.g., the amount532entered by the user102inFIG. 5E. In other embodiments, the user102may be able to withdraw less than the unlock amount, but not more than the unlock amount.

In step428, the issuer computer116may transmit an authorization response to the payment processing network110. In some embodiments, the steps422and424may be the same or may overlap.

In step430, a confirmation message may be sent to the mobile communications device104indicating that the transaction was successful. The message processing module218may process the confirmation message and generate an output message comprising the confirmation message that may be presented on a display screen or to a speaker through the user interface module216. As illustrated in a screen shot516inFIG. 5H, a message548indicating that the ATM cash out was successful may be received by the mobile communications device104. A reference number550may be provided that may be used to track this particular transaction if needed. An amount552may indicate the transaction amount, e.g., the cash amount. A balance554may indicate the balance for the account after the cash withdrawal. A date and time indicator556may display the date and time of the transaction.

In step432, the server computer300may lock the account using the lock-unlock module320once the transaction is complete and communicate to the issuer computer116using the communications module312that the account is locked. In one embodiment, the user102may need to launch the payment menu again to initiate another transaction. In another embodiment, the home screen on the mobile communications device104may present an option to the user for conducting another transaction before locking the account. If the user102decides to conduct another transaction by selecting an option from the payment menu526, the timer324may be reset/updated for allowing a new time period for which the account stays unlocked. In some embodiments, the number of transactions that may be conducted while keeping the account unlocked may be pre-determined by the issuer or the user.

FIG. 6illustrates a process flow diagram implementing a method for unlocking an account for sending money in one embodiment of the invention. Exemplary screen shots for this method are illustrated inFIGS. 7A-7F.

Referring back toFIG. 6, the user102may enter a short code (step402) to launch a mobile payment application on the mobile communications device104and this short code may be transmitted to the server computer300in the payment processing network110. A payment menu may be displayed, by the mobile communications device104to the user102with options (step404).

In step602, the user102may select an option to send money, and this is transmitted to the server computer300. For example, the user may select option 2 (send) on the payment menu526inFIG. 5C. In response to selecting the option to send money, a list of recipients may be displayed on the mobile communications device104, as shown in a screen shot702inFIG. 7A.

In step604, the user102may select a recipient from the list of recipients, and this selection is transmitted from the mobile communications device104to the server computer300in the payment processing network110. As illustrated in the screen shot702, a list of recipients714is presented for send money option. The user102may choose any of the options 1 to 4 from the list714to select a recipient. In one embodiment, selecting option 5 may display a “feature unavailable” message. In some other embodiments, the user102may be able to add a recipient to the list714by selecting option 5. The user may select option “00” to return to the home screen. Each recipient in the list may be associated with an identifier which may be an account number (e.g., credit or debit card number), a phone number, or any other suitable identification. In one embodiment, the recipient information may be stored with the user information in a database, e.g., database306. In some embodiments, the recipient information may also include contact information for each recipient, such as, email address, phone number, billing address, etc. In some embodiments, the recipient information may be stored on the mobile communication device104, e.g., on the contactless element206. The message processing module218may generate a request to unlock an account associated with the user102once a recipient has been selected by the user102.

In step606, the server computer300may receive a request message to unlock the account for money transfer. The request message may be decoded by the communication module312and forwarded to the message generator module316so that a message with current balance may be generated that may be presented to the user102using the payment menu interface module314. The message may also include a request for the user to provide an amount for the money transfer. This may be equal to the unlock amount. As illustrated in a screen shot704inFIG. 7B, the user interface module216may provide a current balance716and prompt the user102to enter a send amount718.

In step608, the user102enters the send amount, and this may be transmitted from the mobile communications device104to the server computer300. As illustrated in a screen shot706inFIG. 7C, the user102may be prompted to enter a description or a note720for the recipient. As an example, the description may be a reference description or may be a note up to certain length for the recipient. In one embodiment, the user may leave the description blank. In some embodiments, if the amount718entered by the user102is more than the current balance716, an error message may be displayed and the user102may be prompted again or the home screen may be displayed.

In step610, the server computer300may receive a request message to unlock the account for money transfer if the request was not received in step606. As illustrated inFIG. 7D, a screen shot708may include a recipient722, an amount724, a note726, a prompt728for the passcode and option 730 to cancel the money transfer request. The note726may be the note provided by the user102inFIG. 7C.

In step612, the user102may provide a passcode when prompted for authentication. The user authentication module318may verify the passcode as discussed previously with reference toFIG. 4.

In step614, the passcode is verified by the server computer300. The lock-unlock module320may unlock the account associated with the user102for a duration of time based on the timer324. The message generator module316may generate a notification message indicating the user102that the send request is being processed. The message processing module218may process the notification message and generate an output message comprising the received message that may be presented on a display screen or to a speaker through the user interface module216. As illustrated in a screen shot710inFIG. 7E, a notification message732is presented to the user102. The user102may select an option 734 to return to the main menu.

In step616, the server computer300notifies the issue computer116that an account associated with the user102is unlocked for a certain duration of the time.

In step618, the server computer300may transmit an authorization request to the issuer computer116for transferring money to the recipient's account. In some embodiments, the steps616and618are combined. The authorization request may include the account information of the recipient to which the money should be transferred.

In step620, the issuer computer116may transmit an authorization response to the server computer300relating to the money transfer. The authorization response may include whether the authorization was approved or rejected.

In step622, if the authorization was approved, the server computer300may send a confirmation message to the user102. The message generator module316may generate a confirmation message indicating the user102that the account is unlocked. The message processing module218may process the confirmation message and generate an output message comprising the confirmation message that may be presented on a display screen or to a speaker through the user interface module216. As illustrated inFIG. 7F, a screen shot712includes a confirmation message736indicating “send successful”, a reference738, the recipient722, the amount724and a balance744. The balance744may be the current balance716less the amount724.

In step624, a confirmation message is also sent to the recipient device134associated with the recipient132after the transaction is complete. The recipient contact information may be stored along with the user information in the database306and/or the memory210.

In step626, the server computer300may lock the account once the transaction is complete and communicate to the issuer computer116that the account is locked. The user102may need to launch the payment menu again to initiate another transaction.

Embodiments of the invention solve a technical problem of unauthorized access of financial accounts associated with users that result in financial losses and unproductive use of resources (human and computing resources) by providing a secure method of conducting transactions using a mobile payment application. Embodiments of the invention provide a technical effect by unlocking a financial account associated with an authenticated user for a limited period of time and for a specified amount in order to enable the user conduct a financial transaction using funds from that account. By allowing limited access to a user's account, embodiments of the invention provide benefits, such as, reduction in fraudulent transactions and improved account security. The mobile payment application provides a convenient and easy user interface for conducting transactions in a secure manner. In addition, allowing the transaction based on the successful verification of the passcode provided by the user adds an extra layer of security for both the user and the account issuer.

The various participants and elements may operate one or more computer apparatuses (e.g., a server computer) to facilitate the functions described herein. Any of the elements in the figures may use any suitable number of subsystems to facilitate the functions described herein. Examples of such subsystems or components are shown inFIG. 8. The subsystems shown inFIG. 8are interconnected via a system bus810. Additional subsystems such as a printer818, keyboard826, fixed disk828(or other memory comprising computer readable media), monitor822, which is coupled to display adapter820, and others are shown. Peripherals and input/output (I/O) devices, which couple to I/O controller812, can be connected to the computer system by any number of means known in the art, such as serial port824. For example, serial port824or external interface830can be used to connect the computer apparatus to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection via system bus810allows the central processor816to communicate with each subsystem and to control the execution of instructions from system memory814or the fixed disk828, as well as the exchange of information between subsystems. The system memory814and/or the fixed disk828may embody a computer readable medium.

Further, while the present invention has been described using a particular combination of hardware and software in the form of control logic and programming code and instructions, it should be recognized that other combinations of hardware and software are also within the scope of the present invention. The present invention may be implemented only in hardware, or only in software, or using combinations thereof.

The present invention can be implemented in the form of control logic in software or hardware or a combination of both. The control logic may be stored in an information storage medium as a plurality of instructions adapted to direct an information processing device to perform a set of steps disclosed in embodiments of the present invention. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods to implement the present invention.