JP6151234B2 - Method and system for financial transactions in a mobile environment - Google Patents

Description

CROSS REFERENCE TO RELATED APPLICATIONS This application is related to the following US patent applications and incorporates the following US patent applications by reference:

  Application No. 11 / 428,857, filed July 6, 2006, entitled “Methods and Systems for Payment Transactions in a Mobile Environment”.

  Application No. 11 / 428,859 entitled “Methods and Systems for Making a Payment via a Paper Check in a Mobile Environment” filed on July 6, 2006.

"Methods and Systems for Making a Payment via a Stored Value Card" filed July 6, 2006
No. 11 / 428,860, entitled “in a Mobile Environment”.

  Application No. 11 / 428,861 entitled “Methods and Systems for Viewing Aggregated Payments in a Mobile Environment” filed on July 6, 2006.

  Application 11 / 428,864, filed July 6, 2006, entitled “Methods and Systems for Providing a Payment in a Mobile Environment”.

  Application No. 11 / 428,866, filed July 6, 2006, entitled “Methods and Systems for Managing Payment Sources in a Mobile Environment”.

  Application No. 11 / 428,870 entitled “Methods and Systems for Real Time Account Balances in a Mobile Environment” filed on July 6, 2006.

  Application No. 11 / 428,874, filed July 6, 2006, entitled “Methods and Systems for Distribution of a Mobile Wall for a Mobile Device”.

  Application No. 11 / 428,876 entitled “Methods and Systems for Indicating a Payment in a Mobile Environment” filed on July 6, 2006.

“Methods and Systems for Payment Method Selection by a Payee in a” filed on July 6, 2006
Application No. 11 / 428,879, entitled “Mobile Environment”.

  The present invention relates generally to financial transactions, and more particularly to a mobile device such as a mobile telephone (cellphone) or a wirelessly connected personal digital assistant (PDA). ) For conducting financial transactions in a mobile environment.

Busy consumers in the mobile society seek to maximize their time use.
Electronic devices such as personal digital assistants (“PDAs”) and mobile phones (“cell phones”) are more capable of communicating with other people and other institutions wherever users go. Provide an efficient time use commitment. One specific requirement for mobile consumers is to securely manage their economic conditions, such as balances in bank accounts, credit cards, and other sources of funds, to pay bills, to third parties and families It is a better ability to fulfill financial debt quickly but efficiently, such as transferring funds. A number of useful web-based financial service programs and personal computer (PC) -based financial service programs are available to consumers and businesses. These are available from Intuit Inc. Popular QUICKEN ™ product from Microsoft Corp. Including MICROSOFT MONEY.

However, these web-based and PC-based solutions for money payment and cash management require the user to have access to a networked PC. The PC may not always be readily available to the mobile consumer when the mobile consumer needs to pay for the bill. However, mobile devices such as cell phones or PDAs are more likely to be available. (The average consumer knows if he has lost his cell phone within about 6 minutes, but it takes about 18 minutes to realize that he has lost his traditional wallet. It has become commonplace.)
In the mobile society, consumers tend to carry various personal assets such as keys, wallets, cards, and electronic devices. Currently popular electronic devices include mobile phones, PDAs, MP3 players or other types of music players (eg, APPLE iPOD ™), and personal video players (again, APPLE iPOD ™). While these electronic devices converge on functionality, the average consumer in the mobile society is too much like a wallet, checkbook, multiple credit cards, debit cards, membership cards, loyalty (point) cards, keys, etc. There is still a tendency to carry many other personal property. Although further integration and convergence of electronic and mobile communication devices is expected in the future to alleviate some of the messy personal assets, current communication and financial service infrastructures remain mobile financial Lack of the need to conduct transactions effectively and reduce messy personal property.

Unfortunately, current mobile device technology and financial services infrastructure does not provide a convenient, secure and rapid response to personal financial needs in a mobile environment. In order to allow mobile devices such as mobile telephony or PDAs to be successfully used for mobile financial transactions, some functionality related to transactions is important.
Personal monetary payment obligations arise from many sources, such as payments for invoices and mortgages, sending money, and checking out purchases at retail establishment points of sale (POS). Such debt may involve dozens (or more) different entities. Different entities may require different payment forms.
An attractive mobile financial transaction system for mobile consumers, providing payment obligation aggregation and integration, allowing you to select payment methods such as checks, direct funds transfers, and credit card accounts Will be. Value-storing (SV) cards are used by some organizations, especially so-called “unbanked” (ie people who do not have an open bank account and tend to do business with cash). Payment options are becoming increasingly popular.

  Similarly, an individual may have multiple payment sources and funding sources (credit cards, bank accounts with savings and check features, debit cards, etc.). People often have a preference as to which funding source should be used to pay some payment obligations. Bank accounts may be desired for some payments, while credit cards may be desired for other transactions for a number of reasons, including participation in loyalty programs such as the “regular user” program . Prior to using a particular funding source for payment, consumers often need or want to have information about available funds balances or credit balances. Some form of account balance inquiry from the mobile device, or in some cases, real-time balance information update is desired. In addition to balance information, the ability to start other financial institution operations in a moveable state is desired. Such other operations do not require any person to appear at a banking facility or appear in front of a PC terminal with internet connectivity anywhere at any time, transfer funds between accounts, certain financial Includes selection of different payment sources or payment accounts from institutions, remittances and payments, loan inquiries and payments, etc.

  Some online financial service providers (eg, CheckFree Corporation) have "invoice aggregation" whereby multiple payment obligations are collected in a centralized computing device and provided to consumers as a list. Or provide a service known as “Invoice Presentation”. For example, US Pat. No. 6,289,322 to Kitchen et al. Describes a method for electronically presenting billing information that can be used in connection with “online bill payments”. The method includes receiving billing information associated with a plurality of different bill creators, the different portions of which represent bills for different people (such as payers). Billing information is integrated for each registered user or payer. Individual customers can record an account, add information about the invoice creator, add information about the financial institution, and go to an internet website to pay online for the invoice. However, the system described in US Pat. No. 6,289,322 is intended for users with PC and Internet access and has some disadvantages for use in a mobile environment. One particular drawback is that the web-based user interface provides so much information about the user's account and bill details that it is difficult to browse and navigate on small mobile devices. It is. Another drawback is the lack of integration of online bill payments and the use of multiple conveniently selectable different payment sources.

US Published Patent Application No. 20050086164 to Kim et al. Describes a method for using a mobile phone for the purpose of paying a bill for goods or services provided via authorization of the mobile phone network. First, the buyer uses his mobile phone to connect to the payment transaction server. A buyer identification code and a “store” identification code (for each) and an invoice for the goods or services are sent to the payment transaction server.
The payment transaction server examines the data received from the mobile phone and determines transaction approval based on the balance corresponding to the buyer identification code. If approved, an approval notification is sent to the store terminal. After confirmation from the merchant approval notice, the buyer receives the goods or services.

  The system described in the Kim et al. Publication relies on having a pre-opened balance in a prepaid account opened by a buyer using a mobile telephone network. Further, the method involves delivering voice prompts to the user via the mobile phone and receiving the user's option selection by activation of a key on the mobile phone keypad. While such devices and systems are certainly one way in which financial transactions can be carried out using mobile phones, the well-known voice prompting method for keypad data entry is slow and cumbersome and well known. Is a source of consumer frustration. Furthermore, modern mobile devices are not just phones. Many such devices now include displays, controls, and keypads, providing more ways beyond voice messages and voice prompts for wireless interaction.

  Mobile communication devices and mobile communication systems have now advanced beyond the limits of voice prompts and telephone keypad data entry and option selection. First generation (1G) mobile phone systems are limited to analog wireless voice transmission and are superseded by second generation (2G) systems that allow greater functionality providing digital signal transmission features. Current mobile device communication systems (beyond 2G) are currently all digital and utilize data communication channels to carry voice signals as well as other data signals. Features enabled by digital data communication include short message system (SMS) messages for text messaging, ringtone download, and other features. Consumer-oriented mobile communication systems are now moving beyond advanced second generation (2.5G) technology to third generation (3G) technology that provides high-speed broadband data connectivity to mobile devices. I'm heading. New 3G systems and 3G devices include full Internet usage on mobile devices, SMS messaging capabilities, direct person-to-person calls, direct download of content such as ringtones, music, and video, and much more Allows abilities such as other features.

  It should be noted that modern mobile devices currently involve highly converged PDA and telephone capabilities. New mobile devices include color displays, touch screens, full phone capabilities and music playback, stream video, memory for data storage (eg memory cards), wireless headsets, infrared data connections, and many other features Own. Systems that facilitate convenient, secure, and rapid mobile financial transactions will always make good use of the communication bandwidth and device features available in modern 2.5G and 3G networks and their devices. . However, prior to the present invention, consumer-desired uses that enable convenient, secure, and quick mobile financial transactions in a way that is easy to use for consumers and allows for messy personal property reductions. There is no effective attempt to identify methods and usage characteristics.

  In particular, consumers require strong security when using their devices. When used at a retail point of sale (POS), consumers require a quick and convenient checkout. The consumer should be able to perform “PayAnyone” at any point in any of several different ways. The consumer must be provided with only the information necessary to carry out the transaction, such information that is necessary, and this information must be up to date. Similarly, financial institutions require strong security, including authentication, for transactions initiated in the mobile environment. There must be revenue opportunities as well as user retention opportunities. There must be an opportunity to reduce customer service costs through the use of automation. For retail stores and entities that send invoices, there must be a quick payment. Any POS transaction must be cleared quickly. Charges based on credit and debit cards must be quickly authenticated and cleared, and fraud prevention and reduction is the responsibility of financial institutions and billing entities and other payees. Major for both. Facilitating customer loyalty programs, or at least compatibility with those programs, is highly desirable.

  All of these requirements, some only desired, but some absolutely essential, present challenges to today's mobile communications and financial services infrastructure. Prior to the present invention, no system has been created that addresses all of these features, goals, and desires of mobile communication-based financial transaction systems in a satisfactory manner.

  Therefore, the amount and use of money that consumers using mobile devices will be paid using any selectable and available funds by integrating their bills and other payment obligations With the knowledge of possible balances, to such invoices and other obligations from any point at any time to a business partner for goods or services or to someone or any other specified entity There is a need for a comprehensive solution that allows you to pay for it. Of course, all of these must be convenient, safe and quick.

  As described and explained in detail below, the present invention is intended to complete financial transactions that meet these and other requirements for an efficient, effective, robust, secure and convenient solution in a mobile environment. Various systems and methods are being built.

  As briefly described, the present invention utilizes a mobile device, such as a mobile phone or wirelessly connected personal digital assistant, that communicates with a mobile financial transaction system that stores user information and transaction information. It relates to a method and system for conducting a transaction. In particular, the present invention relates to a method and system for payment transactions in a mobile environment.

  Aspects of the present invention are in the form of mobile devices, in the form of software for mobile devices (eg, in the form of computer-implemented methods), in the form of mobile financial transaction systems (MFTS), and in mobile finance. In the form of software for a trading system (eg, in the form of a computer-implemented method), in the form of a system that combines aspects of a mobile device and a mobile financial trading system, and in the form of software for such a system (eg, a computer-implemented method) Implemented in the form of software for mobile devices and related systems.

  In one main aspect, the present invention relates to a method for making mobile money payments using a mobile device connected for communication with a wireless network. The method includes (i) providing a mobile financial transaction system (MFTS) and (ii) receiving payment to make information corresponding to a payment to a payee performed by a user at the MFTS. And (iii) generating summary payment execution information (summarized payment to make information) based on the payment execution information in the MFTS, and (iv) transmitting the summary payment execution information from the MFTS to the user mobile device via the MCSP. Wirelessly communicating and (v) displaying information corresponding to one or more selectable payment executions at the user mobile device. Such selectable payment execution includes summary payment execution information associated with the payee. The method includes (vi) receiving user input corresponding to a payment execution selection and a payment source selection for performing payment at the user mobile device; and (vii) responding to the user input at the user mobile device. Generating a mobile payment instruction comprising information corresponding to the selected payment source and the selected payment source for performing the payment corresponding to the selected payment execution; (viii) Wirelessly communicating the mobile payment instruction from the user mobile device to the MFTS.

  In accordance with this aspect of the invention, the method corresponds to an identified payee at (ix) MFTS in response to receiving a mobile payment order for receiving a payment indicated by the mobile payment order. Further comprising retrieving from the MFTS database information and information corresponding to the selected account at the selected financial service provider identified in the mobile payment instruction. The method includes (x) generating an MFTS payment instruction for a payment instruction recipient at the MFTS, and (xi) communicating the MFTS payment instruction to a selected payment instruction recipient from the MFTS; Is further provided. The payment instruction recipient achieves payment to the identified payee in response to receiving the MFTS payment instruction.

In a preferred embodiment, the MFTS is coupled for wireless communication with a user's mobile device using a mobile communication service provider (MCSP). The MFTS is also coupled for electronic communication with one or more payment instruction recipients that can make payments to payees on behalf of the user. The MFTS is a payment source associated with user information, payment execution information associated with one or more payment instruction recipients and / or payees, and at least one account associated with at least one financial service provider. Contains an MFTS database for storing information. In one aspect, the payment execution information comprises a bill and the payee is a billing entity.
In another aspect, the payment order recipient is one of a financial service provider, a billing aggregator, or a separate billing entity.

  Another aspect of the invention involves providing a Mobile Wallet application on a user mobile device. The mobile wallet application provides functionality such as viewing and selecting invoices or other payment executions to be paid, viewing and selecting payment sources for performing such payments, viewing balances, etc. It is a mobile device application. In one aspect, the mobile wallet application may have a View Bills command, a View Payment Sources command, a Pay Bill (s) command (s) on the mobile device. , And a display of selectable commands including one or more of Pay Anyone commands. In an exemplary aspect, the view bill command provides a means for the user to view and / or select a payment execution. A select invoice view command causes the MFTS to retrieve invoice information from the bill presentment system and receive the summary invoice information upon receipt of such information from the invoice presentation system. To communicate.

  In a related aspect, the payment source view command provides the user with a means for viewing and / or selecting a payment source for performing payment. Selection of a payment source for performing payment includes selection of a financial service provider and selection of a particular account associated with the selected financial service provider for performing payment. The view payment source command also causes the MFTS to retrieve current account information from one or more financial service providers and to receive the current account information from the mobile device when receiving such information from one or more financial service providers. To communicate.

  In a related aspect, the bill payment command (s) provide the user with a means for paying the bill or other payment for another entity for which the user has a financial obligation, such as payment for a mortgage. provide. In another related aspect, the pay-anyone command may be, for example, the payee's name and / or payee's mobile number, regardless of prior invoices or other information provided to the MFTS. Is provided to the user of the mobile device to perform a payment for any individual by entering.

  According to yet another aspect of the invention, payment execution information is provided to the MFTS by an external source. The external source may be one or more of a plurality of billing entities, or a bill presenting system that provides bill information from individual billing entities. The information may be entered by the user via an internet-accessible website accessible by the user for entry of payment execution information and payee information, or via a mobile device.

According to yet another aspect, the payment execution information comprises information corresponding to one or more of the following. That is, a recurring bill, a bill from a billing aggregator, a bill from an individual billing company, and / or a “Pay Anyone” payment. According to an aspect of the present invention, information corresponding to one or more payment executions displayed on the user mobile device is provided in response to user activation of the “bill view” function. Such information display is in response to a text message from the MFTS received at the mobile device.
Such information display includes summary invoice information provided by the MFTS. The summary payment execution information includes a predetermined selected subset of payment execution information.

  According to another aspect, the MFTS payment instruction includes information identifying the selected account at the selected financial service provider, an amount, and information corresponding to the identified payee. The identified payee can be the billing entity that communicated the bill information to the MFTS, or another entity where payment can be performed. In one embodiment, the summary payment execution information communicated to the mobile device comprises a payee identifier, an amount, and a due date so that only minimal information is transmitted from the MFTS to the mobile device. In this aspect, the mobile device utilizes the payee identifier in the summary payment execution information, retrieves payee name information from the mobile device local memory corresponding to the identified payee, and sends the payee name information to the user. indicate.

  In one embodiment, the MFTS database also stores transaction information corresponding to the user's financial transactions. The transaction information includes payment execution information in addition to one or more of the following information items, as well as other information utilized to track the status of payment execution. That is, a user ID number, transaction identifier, invoice receipt date, invoice payment date, amount, financial service provider identifier, account identifier, payee identifier, and / or incomplete / resolved flag.

  In one embodiment, the method further comprises communicating a payment confirmation message from the payment instruction recipient to the MFTS in response to completion of the predetermined stage in performing the payment. In another embodiment, the method further comprises communicating the payment confirmation message to the mobile device in response to receiving the payment confirmation message from the payment instruction recipient.

  Another aspect of the present invention relates to the selection of a payment method for achieving payment. According to this aspect, a method receives user input corresponding to a selection of a payment method for performing payment at a user mobile device, and performs payment at the user mobile device in response to the user input. Including information corresponding to the selected method in the mobile payment instruction. The available payment methods are: recipient-defined method that determines how the recipient will receive payment, ACH funds transfer, paper check, stored value ( SV) card.

According to another aspect, the MFTS is further coupled for electronic communication with a user's computer via a data communication network such as the Internet. A method according to this aspect includes: (i) providing a web application in connection with MFTS; and (ii) user information corresponding to a financial service provider, an account at the financial service provider, and a payee via the web application. Receiving and (iii) storing user information input in a MFTS database via a web application for use in connection with payment initiated by the user mobile device.
In another embodiment, the method further comprises retrieving transaction information corresponding to a transaction performed via the user mobile device via a web application and displaying the information to the user via the user's computer. Prepare.

  In one embodiment, mobile monetary payments may include a balance transfer from one account associated with the user to another account associated with the same user.

  Another aspect of the invention relates to real-time updating of account information for a user's mobile device. A method according to this aspect includes: (i) storing a cached account balance on a mobile device representing a balance of at least one account of a user as of a particular date; (ii) updating an account Communicating with a financial service provider to obtain updated account balance information; (iii) wirelessly transmitting updated account balance information from the MFTS to the user mobile device; and (iv) updated from the MFTS. In response to receiving the account balance information, displaying updated account balance information corresponding to the account to the user via the mobile device.

  According to yet another aspect, the invention relates to a system for performing mobile monetary payments using a mobile device connected for communication with a wireless network. In another aspect, the invention relates to a method for performing mobile monetary payments using a mobile device connected for communication with a wireless network. In yet another aspect, the invention relates to a mobile device for performing mobile monetary payments over a wireless network. In yet another aspect, the invention relates to a computer-implemented method for facilitating mobile money payments initiated by a mobile device to which a mobile financial transaction system (MFTS) is connected for communication with a wireless network. In yet a further aspect, the present invention relates to a mobile financial transaction system (MFTS) for facilitating mobile money payments initiated by a user mobile device connected for communication with a wireless network. In another aspect, the present invention relates to a method for performing a financial payment to a payee by check utilizing a mobile device connected for communication via a wireless network.

  Another aspect of the present invention relates to a method and system for performing a financial payment to a payee by check utilizing a mobile device. The mobile device communicates wirelessly with a mobile financial transaction system (MFTS) that stores user information and transaction information. The user enters information identifying the payee and instructing a check payment method via the mobile device. The mobile device generates a mobile payment instruction that corresponds to the identified payee and includes information indicating a check payment method. Mobile payment instructions are communicated wirelessly to the MFTS. The MFTS generates an MFTS payment order for a payment order recipient that can issue a check. The MFTS communicates the MFTS payment order to the payment order recipient who arranges payment for the identified payee by printing a check and mailing it to the payee.

  Another aspect of the present invention relates to a method and system for performing monetary payments to payees with a stored value (SV) card utilizing a mobile device. The mobile device communicates wirelessly with a mobile financial transaction system (MFTS) that stores user information and transaction information. The user inputs information via the mobile device that identifies the payee and indicates the value storage card payment method. The mobile device generates a mobile payment instruction corresponding to the identified payee and including information indicating a stored value card payment method. Mobile payment instructions are communicated wirelessly to the MFTS. The MFTS generates an MFTS payment instruction for a payment instruction recipient that can issue a new value storage card and / or reload funds onto an existing value storage card. The MFTS communicates an MFTS payment order to a payment order recipient that arranges payment for the identified payee by issuing a new value storage card or reloading funds on an existing value storage card.

  Another aspect of the invention relates to a method and system for viewing aggregated financial debt utilizing a mobile device. A mobile financial transaction system (MFTS) is coupled for wireless communication with a user's mobile device. The MFTS is also coupled for electronic communication with an aggregator that collects information from multiple payees with which the user has a financial relationship. The MFTS receives payment execution information from the aggregator corresponding to the payment to the payee executed by the user. The MFTS generates summary payment execution information comprising a predetermined selected subset of payment execution information received from the aggregator. The MFTS communicates summary payment execution information wirelessly to the user's mobile device. The summary payment information is then displayed on the user's mobile device.

  Another aspect of the invention relates to a method and system for performing money payments to payees utilizing a mobile device. The user enters information into the mobile device that identifies the payee, the payment source for payment, and the payment method. The mobile device generates a mobile payment instruction comprising information corresponding to the identified payee, payment source, and payment method, and wirelessly communicates the mobile payment instruction to a mobile financial transaction system (MFTS). The MFTS generates an MFTS payment order for the payment order recipient. The MFTF payment instruction includes a payment source, an amount, information identifying information corresponding to the identified payee, and information indicating a payment method. The MFTS communicates the MFTS payment order to the payment order recipient. In response to receiving the MFTS payment instruction, the payment instruction recipient achieves payment to the identified payee without any required action by the payee.

  Another aspect of the invention relates to a method and system for selecting a payment source for use in performing mobile money payments utilizing a mobile device. A mobile financial transaction system (MFTS) is coupled for electronic communication with one or more financial service providers for which a user holds one or more accounts, and also for wireless communication with mobile devices. The The mobile device displays information corresponding to an account available to the user as a payment source for use in connection with performing payment using the mobile device. The user selects a payment source for performing the payment. The mobile device generates a mobile payment instruction comprising information corresponding to the payment and the selected payment source. Mobile payment instructions are communicated wirelessly to the MFTS. The MFTS generates MFTS payment information including an amount, information corresponding to the identified payee, and information indicating the selected payment source. The MFTS payment order is communicated to a payment order recipient that uses the selected payment source to accomplish the payment.

  Another aspect of the invention relates to a method and system for obtaining real-time account balance information for a plurality of financial accounts held at one or more financial service providers utilizing a mobile device. The Mobile Financial Trading System (MFTS) is also coupled for wireless communication with a user's mobile device and for electronic communication with one or more financial service providers where the user holds one or more accounts. Combined. The mobile device stores a cached account balance that represents the balance of each account as of a particular date. The MFTS communicates with the financial service provider to obtain updated account balance information for the user's account. The updated account balance information is transmitted wirelessly to the user's mobile device. In response to receiving updated account balance information from the MFTS, the mobile device displays updated account balance information corresponding to the plurality of user accounts.

  Another aspect of the invention relates to a method and system for delivering a mobile device application for use in making and receiving payments utilizing a mobile device. When installed on a compatible mobile device, a downloadable mobile device application is operable to communicate with a mobile financial transaction system (MFTS) that facilitates the execution and receipt of payments via a wireless mobile device It is. A downloadable mobile device application is provided via a download system that downloads the application to the mobile device according to a download procedure appropriate for the particular type of mobile device. If payment is made to a payee with a mobile device, the system notifies the payee that a payment has been made and instructs the payee about the downloadable mobile device application. Communicate to human mobile devices. When a mobile device user / payee downloads and installs a mobile device application on his / her mobile device to provide enrollment information, the interaction between the MFTS and the mobile device user / payee The action is allowed and payment is provided to the user of the mobile device as a user / payee.

  Another aspect of the invention relates to a method and system for performing mobile money payments utilizing a mobile device. A mobile financial transaction system (MFTS) is coupled with a user's mobile device for wireless communication with one or more payment instruction recipients that can perform payments to payees on behalf of the user. It is also coupled for electronic communication. The mobile device allows selection of an existing payee or input of payee information. The user provides input to select a payee for payment and a payment source for payment at the mobile device. Mobile payment instructions comprising information corresponding to payment execution and payment sources for payment are communicated wirelessly to the MFTS. The MFTS generates an MFTS payment order that includes information identifying the selected account at the financial service provider, the amount, and information corresponding to the identified payee and communicates it to the payment order recipient. The payment order recipient then achieves payment to the identified payee.

  Another aspect of the invention relates to a method and system for receiving monetary payments facilitated by a user of a mobile device. The Mobile Financial Transaction System (MFTS) is coupled for wireless communication with a user / payee's mobile device and also for electronic communication with a payment instruction recipient that achieves payment in various ways. . The system provides information corresponding to the received payment to the user / payee's mobile device. Information corresponding to a plurality of selectable payment methods available to receive payment is displayed to the user / payee. The user / payee provides input corresponding to the selection of a payment method for receiving payment on his mobile device. The mobile device generates a mobile payment instruction indicating the selected payment method and wirelessly communicates the mobile payment instruction to the MFTS. The MFTS generates an MFTS payment order that includes the amount, the identified payee, and the selected payment method and communicates it to the payment order recipient. In response to receiving the MFTS payment order, the payment order recipient uses the selected payment method to effect payment to the user / payee.

  From the foregoing description, those skilled in the art will recognize that a system constructed in accordance with aspects of the present invention, using its various aspects of mobile devices, mobile financial transaction systems, web interfaces, and functionality combinations, provides users of mobile devices. Unprecedented convenience and flexibility in monitoring invoices to be paid and other payment executions, information on current account balances provided in real time, and so far at reasonable economic costs and convenience It will be readily understood and appreciated to provide other improved functionality for mobile device users who have not.

  These and other aspects, features, and advantages of the present invention (s) will become apparent from the following detailed description of the preferred embodiments, taken in conjunction with the drawings, but with variations within the detailed description Modifications and alterations can be made without departing from the spirit and scope of the novel concepts of this disclosure.

FIG. 3 illustrates a high-level overview of an exemplary aspect relating to a mobile financial transaction system (MFTS) that implements aspects of the present invention. FIG. 2 shows a more detailed overview of an exemplary mobile financial transaction system (MFTS) according to an exemplary aspect of the invention. FIG. 3 is a computer software architecture diagram illustrating various computer program modules that provide computer-implemented method steps for a cell phone or mobile device application in accordance with exemplary aspects of the invention. FIG. 3 is a computer software architecture diagram illustrating various computer program modules that provide computer-implemented method steps for operation of an MFTS system, in accordance with exemplary aspects of the invention. 6 is a flow diagram illustrating the operation of a main program of a mobile financial transaction system (MFTS) constructed in accordance with exemplary aspects of the invention. 6 is a flow diagram illustrating the operation of a main program of a mobile financial transaction system (MFTS) constructed in accordance with exemplary aspects of the invention. FIG. 3 illustrates an example database schema (data table layout) for a mobile financial transaction system (MFTS) user database according to an example aspect of the invention. FIG. 3 illustrates an example database schema (data table layout) for a mobile financial transaction system (MFTS) transaction database according to an exemplary aspect of the invention. 6 is a flowchart illustrating computer-implemented method steps of a computer program for performing operations of a mobile device communication interface for MFTS in accordance with exemplary aspects of the invention. 6 is a flow diagram illustrating computer-implemented method steps of a computer program for performing operations of a financial service provider (FSP) communication interface for MFTS in accordance with exemplary aspects of the invention. 6 is a flow diagram illustrating computer-implemented method steps of a computer program that implements operation of a user web application input / output (I / O) interface for MFTS in accordance with exemplary aspects of the invention. 6 is a flow diagram illustrating computer-implemented method steps of a computer program for performing operations of a web application for enrolling new users in accordance with exemplary aspects of the invention. 6 is a flowchart illustrating computer-implemented method steps of a computer program for performing operations of a web application for a user recorded in accordance with exemplary aspects of the invention. FIG. 4 illustrates a series of mobile device screen displays for viewing selectable payment sources and account balances in accordance with exemplary aspects of the invention. FIG. 5 is a sequence diagram illustrating computer-implemented method steps for viewing payment sources and account balances in accordance with exemplary aspects of the invention. FIG. 6 shows a series of mobile device screen displays for viewing bills in accordance with preferred and alternative embodiments of the present invention. FIG. 7 is a sequence diagram illustrating computer-implemented method steps for viewing a bill according to preferred and alternative embodiments of the present invention. FIG. 4 illustrates a series of mobile device screen displays for paying for a bill in accordance with an exemplary aspect of the invention. FIG. 6 is a sequence diagram illustrating computer-implemented method steps for paying a bill according to a preferred embodiment of the present invention. FIG. 7 is a sequence diagram illustrating computer-implemented method steps for paying a bill according to an alternative embodiment of the invention. A series of mobile devices from the payer's perspective when the user uses the “Pay Anyone” payment option to select a name from a list and use the “Recipient Defined” payment method in accordance with exemplary aspects of the invention The figure which shows a screen view (screen view). FIG. 4 illustrates a series of mobile device screen views from the payee's view of a “pay anyone” payee using a “recipient-defined” payment option according to an exemplary aspect of the invention. FIG. 6 is a sequence diagram illustrating a computer-implemented method from the payer's perspective when a user uses the “Pay Anyone” payment option, selects a payee, and selects a payment method in accordance with exemplary aspects of the invention. A computer from a payee's perspective when a user selects a “recipient-defined” payment method, selects a payment method, and receives payment using a “pay anyone” payment option in accordance with exemplary aspects of the present invention. The sequence diagram which illustrates the implementation method. FIG. 6 illustrates a series of mobile device screen views from a payer's view of a “Pay Anyone” payment feature using an ACH payment method selection according to an exemplary aspect of the present invention. FIG. 6 illustrates a series of mobile device screen views from a payee's view of a “Pay Anyone” payment feature using an ACH payment method according to an exemplary aspect of the present invention. FIG. 6 is a sequence diagram illustrating computer-implemented method steps for a “Pay Anyone” payment feature using an ACH payment method according to an exemplary aspect of the invention. FIG. 4 illustrates a series of mobile device screen views from a payer's view when a user selects a check payment method using a “Pay Anyone” payment feature in accordance with an exemplary aspect of the present invention. FIG. 7 illustrates a series of mobile device screen views from a payee's view of a “Pay Anyone” payment feature using a check payment method according to an exemplary aspect of the present invention. FIG. 6 is a sequence diagram illustrating a computer-implemented method for a “Pay Anyone” payment feature with a check payment method according to an exemplary aspect of the present invention. FIG. 4 illustrates a series of mobile device screen views from a payer's view when a user selects a stored value (SV) card payment method using a “Pay Anyone” payment feature in accordance with exemplary aspects of the invention. FIG. 4 illustrates a series of mobile device screen views from a payee's view of a “pay anyone” payment feature using a stored value (SV) card payment method according to an exemplary aspect of the present invention. FIG. 5 is a sequence diagram illustrating computer-implemented method steps for a “pay anyone” payment method with use of a stored value (SV) card payment method according to an exemplary aspect of the invention. FIG. 4 illustrates a series of mobile device screen views when a user transfers funds or account balances according to an exemplary aspect of the present invention. FIG. 4 is a sequence diagram illustrating computer-implemented method steps for funds transfer or balance transfer between payer accounts according to exemplary aspects of the invention. FIG. 7 illustrates a series of mobile device screen views illustrating receipt of payments to a payee using a mobile device with installation of a mobile device application option for the payee's mobile device, according to an exemplary aspect of the invention. Figure. FIG. 6 is a sequence diagram illustrating computer-implemented method steps by which a payee downloads and installs a mobile device application from an MFTS system as part of a viral financial commerce system in accordance with exemplary aspects of the invention. FIG. 6 illustrates a series of mobile device screen views from a user's view of a personal identification number (PIN) change according to an exemplary aspect of the present invention. FIG. 6 is a screen display of a web application input / output interface illustrating how a user registers via a web application user site for use of a mobile financial transaction system in accordance with a preferred embodiment of the present invention. FIG. 6 is a screen display of a web application input / output interface illustrating how a user registers via a web application user site for use of a mobile financial transaction system in accordance with a preferred embodiment of the present invention. FIG. 6 is a screen display of a web application input / output interface illustrating how a user registers via a web application user site for use of a mobile financial transaction system in accordance with a preferred embodiment of the present invention. FIG. 6 is a screen display of a web application input / output interface illustrating how a user registers via a web application user site for use of a mobile financial transaction system in accordance with a preferred embodiment of the present invention. FIG. 2 is a screen display of a web application input / output interface illustrating how a user manages a mobile financial transaction system money account via a web application user site in accordance with a preferred embodiment of the present invention. FIG. 2 is a screen display of a web application input / output interface illustrating how a user manages a mobile financial transaction system money account via a web application user site in accordance with a preferred embodiment of the present invention. FIG. 2 is a screen display of a web application input / output interface illustrating how a user manages a mobile financial transaction system money account via a web application user site in accordance with a preferred embodiment of the present invention. FIG. 2 is a screen display of a web application input / output interface illustrating how a user manages a mobile financial transaction system money account via a web application user site in accordance with a preferred embodiment of the present invention. FIG. 5 is a screen display of a web application input / output interface illustrating how a user manages a payee of a mobile financial transaction system via a web application user site in accordance with a preferred embodiment of the present invention. FIG. 5 is a screen display of a web application input / output interface illustrating how a user manages a payee of a mobile financial transaction system via a web application user site in accordance with a preferred embodiment of the present invention. FIG. 6 illustrates a web application account summary display screen according to an alternative exemplary aspect of the present invention. FIG. 6 illustrates a web application billing entity details display screen according to an alternative exemplary aspect of the present invention. FIG. 6 illustrates a web application payer details display screen according to an alternative exemplary aspect of the present invention.

Detailed description

Prior to the detailed description of the invention (s), the following definitions are provided as an aid to understanding the subject matter, and the terminology of aspects of the invention (s) is illustrative. It is not necessarily to limit the invention (s) expressed in the claims. Whether a term is capitalized is not considered a determination or limitation of the meaning of the term.
As used in this document, capitalized terms are capitalized unless the usage details indicate a more specific meaning intended for capitalized terms. Should be synonymous with the term that is not. A capitalized term in a glossary typically indicates that a capitalized term has a separate definition within the glossary. However, capitalization or lack thereof in the remainder of this document is not necessarily intended to be limiting, unless the context clearly indicates that such limitation is intended.

Definition / Glossary ACH: “Automated Clearing House”, ie, a large amount of credit according to the rules and regulations established by the National Automated Clearing House Association (NACHA) and the Federal Reserve Board (Fed) An acronym for the Electronic Banking Network that handles transactions and debit transactions.

    Application: A computer program that runs on a computer system. Although not limited thereto, for example, a computer program operated in MFTS, or a computer program operated in a cell phone or a mobile device (mobile application). Further examples of applications include programs that perform searches in the database, receive information and store it in the mobile device's temporary memory, and display selected information on the mobile device, and in effect transactions Including any other type of program that generates or responds to transactions.

Invoice information: information about or corresponding to an invoice to be paid, provided by a billing entity, or bill aggregator, usually to be paid and to the user or billing aggregator Consists of all the information provided by the billing entity that will appear on the bill to be provided. (See “Summary Invoice Information”.)
Billing entity: An entity that provides a user with a payee, an individual, a company, or a bill that can be paid. This term usually includes any payee, regardless of whether or not the invoice is sent to facilitate payment, but the billing entity usually documents the amount to be paid to the billing entity. Or it can be expected to provide a message (invoice). On the other hand, a “Pay Anyone” type payee is usually considered a billing entity for the purposes of aspects of the present invention, but may not require a bill prior to sending a payment.

    Billing (invoice) aggregator: An entity that provides a service that collects information about bills or other payment obligations that a user or consumer has to pay to an entity holding a financial relationship, and for the context of the present invention As a financial service provider that provides information about one or more bills to be paid to a mobile financial transaction system constructed as described herein, and optionally processes bill payments for users Function.

    Invoice presentation: submission or presentation of one or more payment obligations of an entity (such as an invoice to be paid or payment execution) to an entity, for example, by a bill aggregator, for review and provision of payment orders, and one Or multiple such payment obligations electronic communication. Invoice presentation can be provided on a per-invoice basis from a billing entity, or can be a grouping or aggregator of invoices by a billing aggregator that provides the entity with a service to collect the invoices to be paid .

    Consumer: An individual or other entity that accesses or uses a mobile device to perform some functions of a mobile financial transaction system (MFTS) in accordance with exemplary aspects of the invention. Usually synonymous with lower user.

    DBMS: Database management system.

  Enterprise: An organization or company entity that uses the present invention. A company can be a company, government agency, individual, or virtually any other organization that conducts business transactions that reflect the company's activities.

    Entity: something that has an individual and identifiable presence or conceptual entity outside of the present invention. An example is a billing entity that sends billing information about a payment obligation.

    Financial Service Provider (FSP): providing financial services on behalf of its customers, such as banks, credit card companies, credit unions, debit card companies, gift card companies, payment service companies, or other financial institutions, In particular, an entity that functions as a payment source (PS). As used herein, an FSP is an entity that provides financial services on behalf of a user with a mobile device in accordance with an exemplary aspect of the invention. The FSP can also be a payment instruction recipient to accomplish payment.

    I / O: Input / output.

    LAN: A local area network, ie a collection of computers connected for electronic communication, usually located geographically close together (ie in the same building).

    Mobile communications service provider (MCSP) (usually synonymous with wireless service provider): An entity that provides communications services for mobile devices to MFTS and possibly other networked entities. For example, a cell phone service provider can typically function as an MCSP.

    Mobile client (usually synonymous with mobile application): A computer program executing on a mobile device to provide services and operations as described herein, according to an exemplary aspect of the invention.

    Mobile device: Any device used for communication over a wireless communication network, such as a mobile communication phone, transceiver, personal digital assistant (PDA), pager, smart phone, or any combination thereof. A mobile device operable in the present invention typically executes a mobile client software program to achieve the functionality described herein. Usually, it is synonymous with a mobile phone and is used interchangeably with a mobile phone, but a mobile device is not necessarily a phone-type device.

    Mobile Financial Transaction System (MFTS): A system built as described herein that facilitates financial transactions through the use of mobile devices.

    MFTS Payment Instruction (MFTSPI): A payment instruction (PI) that is initiated by the MFTS and sent to a payment instruction recipient such as that institution to instruct the financial institution to perform the payment to the selected selected entity. Format).

    Mobile Payment Instruction (MPI): A form of payment instruction (PI) (see below) generated and provided from a mobile device according to an exemplary aspect of the invention.

    Mobile wallet: in accordance with exemplary aspects of the invention, to view and select an invoice or other payment execution to be paid, to view and select a payment source for performing such payment, to view balances, etc. The name given to the mobile device application that provides the functionality of.

    Pay Anyone: Regardless of whether the individual is physically present or not, by primarily communicating the message to the payee's wireless device, asking for instructions, and determining the preferred method of receiving payment by the payee, A feature of an aspect of the present invention that allows a user to pay to an individual who has a wirelessly connected mobile device.

    Payee: An individual or entity that receives payment. The payee may also be a payment order recipient.

    Payer: An individual or entity that makes a payment. The payer can also be an individual or entity sending a payment order.

Payment Instruction (PI): A collection of information that typically includes one or more selected payment executions, at least one payment source for use in performing payments, and other information.
A mobile payment instruction (MPI) is initially generated and provided from a mobile device according to an exemplary aspect of the present invention. An MFTS payment instruction (MFTSPI) is a communication initiated by the MFTS and sent to an identified entity to instruct the payment instruction recipient to perform payment.

    Payment Order Recipient (PIR): An entity that is given a payment order for the purpose of making a payment. The payment instruction recipient itself can make the payment, or can provide an instruction to make the payment to another entity, such as a financial service provider. For example, the payment order recipient may be a financial service provider, bill aggregator, or billing entity (eg, a company with permission from the payer to collect payments directly from the payer's bank).

    Payment method: A method in which payment to a payee is provided by the payment order recipient or his agent, ie, some kind of financial instrument provided to the payee. Payments include checks, value-preserving cards, ACH funds transfers, credit card account credits, wire transfers, money orders, credit cards, paypal or other online money account credits, other types of financial instruments, etc. , Can be performed by various means without being limited thereto. According to aspects of the invention, the payment method can be selected by the payer in some embodiments, or can be selected by the payee in other embodiments. The payment source differs from the payment method in that the payment source provides funds to the means of the selected payment method.

    Payment Execution (PM): A payment obligation of a mobile device user on which instructions for performing payment using aspects of the present invention are executed. Such obligations include personal water bills, electricity bills, gas bills, mortgage payments, automobile payments, insurance payments, telephone and / or mobile phone bills, credit card bills, etc. Or include any bill that your family receives regularly. These payment obligations also include any payment that an individual needs to make from time to time, such as purchasing gasoline, watching a movie ticket, purchasing any cash only, and paying any individual.

    Payment Source (PS): Funds or money available to an individual or family, usually through an account that can be accessed by aspects of the present invention. These sources include credit card accounts, debit card accounts, check accounts and / or savings accounts, department store credit card accounts, and the like.

    Payment source information: information about the payment source that is stored in the MFTS and part of which (summary payment source information) is communicated to the user's mobile device.

    Protocol: A set of formal rules that specifically describe how data is transmitted across the network. The low level protocol defines the electrical and physical standards to be monitored, bit and byte ordering, transmission and error detection, and bit stream correction. High level protocols address data formatting including message syntax, terminals for computer interaction, character sets, message ordering, and the like.

    Value stored (SV) card: A payment card that includes a magnetic strip or other electrical, magnetic, or electronic information transmission medium that is usually accepted as a form of payment by a commercial company. Money can be “loaded” onto the SV Value Card via a variety of different mechanisms and systems, and then used to pay for invoices, purchase goods, and the like. A value storage (SV) card is not a debit card or a credit card, but an SV card may have some physical similarity to such other types of cards.

    Summary bill information: A reduced subset of bill information displayed to the user via the user's mobile device.

    Summary Payer Information: A reduced subset of information about accounts and / or financial institutions that is displayed to the user via the user's mobile device.

    Transaction: A set of system operations that result in a completed business activity, for example, the following is an exemplary transaction. That is, transfer of a certain amount of money (fund) from one individual to another, debiting one individual (eg, payer) credit card account and another individual (eg, paid) A person's bank account is credited, the bill is paid, and an order to issue a stored value (SV) card is issued.

    SMS: Short message service, ie it is possible to send short messages between mobile devices or mobile phones (also known as text messages, messages, or more colloquially, SMS, text or even txt) Text communication services available on many digital mobile devices or on many digital mobile phones.

    User: An individual or other entity that accesses or uses a mobile device to perform some functions of a mobile financial transaction system. See also “Consumer”. As used herein, these terms are generally synonymous. The user can also use the web interface to access the MFTS for configuration and use, as described herein.

    User / payee: The MFTS system user who receives the payment and is also the payee.

    User / payer: The MFTS system user who performs the payment, and is also the payer.

    User Identifier (User ID): To identify a user to an MFTS or to a financial service provider or to another component that requests information identifying the user for some purposes with respect to the present invention. The code used.

    UI: User interface. Usually refers to a software application that interacts for the purpose of a user entering information, obtaining information, or performing related system functions, including a mobile device user interface.

    WAN: A wide area network, ie a collection of computers connected for electronic communication, usually where the computers are further away from the LAN and are connected by telephone lines, fiber optic cables, satellite transmission, or radio waves.

    WLAN: A technology used to connect devices including wireless local area networks, such as mobile devices, laptops, desktop computers, entertainment devices, etc., via wireless communication signals. Examples include known WiFi data communication standards and WiMAX data communication standards.

System Overview In the best mode contemplated by the inventors, aspects of the invention are implemented using a mobile device coupled for electronic (preferably wireless) communication with a mobile financial transaction system (MFTS). It is preferable. Mobile devices include items such as cell phones and PDAs that are connected for data communication over a wireless network to the MFTS. The MFTS is connected to allow remote network access (eg, Internet access) by the user for account setup, configuration, editing, transaction monitoring, and the like. As will be known to those skilled in the art, such mobile devices basically consist of a microphone and speaker (to enable telephone use), a radio signal circuit such as a digital radio, a micro as a central processing unit (CPU). A small handheld computing device that includes features such as a processor, color or other display, keyboard or keypad, stylus, scroll wheel, control buttons, Bluetooth® wireless signaling, infrared data signaling, and the like. MFTS is similarly a data storage device in the form of one or more processors and / or central processing units (CPU), disk drives and random access memory (RAM), LAN connections, WAN connections, Internet connections, Ethernet (registration). A general-purpose computing device including a communication interface such as a trademark connection.

  Accordingly, the various embodiments of the invention described herein are preferably implemented as special purpose computers or general purpose computers, including various computer hardware, as described in more detail below. . Embodiments within the scope of the present invention also include computer-readable media for carrying or having computer-executable instruction structures or data structures stored thereon. Such computer-readable media can be any available media that can be accessed by a general purpose or special purpose computer, or can be downloaded to a mobile device via a wireless communication network. By way of example, and not limitation, such computer readable media can be RAM, ROM, flash memory, EEPROM, CD-ROM, DVD, or other optical disk storage device, magnetic disk storage device or other magnetic storage device, secure digital (secure). can be used to carry or store computer program code in the form of any type of removable non-volatile memory such as digital (SD), flash memory, memory stick, or computer-executable instructions or data structures And may comprise a general purpose or special purpose computer, or any other medium that can be accessed by a mobile device.

  When information is transferred or provided to a computer over a network or another communication connection (either wired, wireless, or a combination of wired or wireless), the computer properly regards the connection as a computer-readable medium. Thus, any such connection is properly referred to and considered a computer-readable medium. Combinations of the above should also be included within the scope of computer-readable media. Computer-executable instructions comprise, for example, instructions and data which cause a dedicated processing device, such as a general purpose computer, special purpose computer, or mobile device processor, to perform one specific function or group of functions.

  Those skilled in the art will appreciate suitable computing environment features and aspects in which aspects of the invention may be implemented. Although not required, the invention will be described in the general context of computer-executable instructions, such as program modules, being executed by computers in networked environments. Such program modules are often by flow diagrams, sequence diagrams, exemplary screen displays, and other techniques used by those skilled in the art to communicate how to make and use such computer program modules. Reflected and illustrated. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types within a computer. Computer-executable instructions, associated data structures, and program modules represent examples of program code for executing steps of the methods disclosed herein. A particular sequence of such executable instructions or associated data structures represents an example of a corresponding operation for performing the functions described in such steps.

  Those skilled in the art also recognize that the present invention includes personal computers, handheld devices, multiprocessor systems, microprocessor-based home appliances or programmable home appliances, networked PCs, minicomputers, mainframe computers, etc. It will also be appreciated that many types of computer system configurations can be used and implemented in a network computing environment. The present invention provides distributed computing in which tasks are performed by local and remote processing devices that are linked through a communication network (by wired links, by wireless links, or by wired links or combinations of wireless links). It can also be implemented in the environment. In a distributed computing environment, program modules can be located in local memory devices and in remote memory devices.

  An exemplary system for implementing the invention, not shown, is a general purpose computer in the form of a normal computer, including a processing unit, system memory, and a system bus that couples various system components including the system memory to the processing unit. Including computing devices. A computer will typically include one or more magnetic hard disk drives (also referred to as “data storage” or “data storage device” or other names) for reading from and writing to it. The drives and their associated computer readable media provide the computer with non-volatile storage of computer-executable instructions, data structures, program modules, and other data. The exemplary environment described herein uses a magnetic hard disk, a removable magnetic disk, a removable optical disk, but a magnetic cassette, flash memory card, digital video disk (DVD), Bernoulli cartridge, RAM, ROM. Other types of computer readable media may be used to store data, including and the like.

  Computer program code that implements most of the functionality described herein typically comprises one or more program modules that can be stored on a hard disk or other storage medium. The program code typically includes an operating system, one or more application programs, other program modules, and program data, as is known to those skilled in the art. A user can enter commands or information into the computer through a keyboard, pointing device, or other input device (not shown) such as a microphone, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing device via known electrical, optical, or wireless connections.

  A main computer that accomplishes many aspects of the invention will typically operate in a networked environment using logical connections to one or more remote computers or data sources as further described below. Become. The remote computer may be another personal computer, server, router, network PC, peer device or other normal network node, and usually many of the elements described above with respect to the main computer system in which the invention is implemented. Or include everything. Logical connections between computers include, but are not limited to, a local area network (LAN) and a wide area network (WAN) presented herein by way of example. Such networking environments are commonplace in office-range or enterprise-range computer networks, intranets and the Internet.

  When used in a LAN networking environment, the main computer system implementing aspects of the present invention is connected to the local network through a network interface or adapter. When used in a WAN networking environment, the computer may include a modem, a wireless link, or other means for establishing communications over a wide area network, such as the Internet. In a networked environment, program modules illustrated for a computer or portion thereof can be stored in a remote memory storage device. It will be appreciated that the network connections described and shown are exemplary and other means of establishing communications over a wide area network or over the Internet may be used.

Payment Debt Integration Considering the implementation architecture described above, reference is now made to FIG. 1, which provides an overview of mobile financial transaction system (MFTS) 18 and several features, in accordance with exemplary aspects of the present invention. The user 12 of the mobile device 15 (such as a cell phone or wireless PDA) selects a payment execution (“PM”) and selects a payment source (“PS”) for performing such payment, as described. To access the MFTS 18. Main inputs to the MFTS 18 include a payment execution 20 (hereinafter “PM”) and a payment source 30 (hereinafter “PS”).

  Payment Execution (PM): Payment Execution (PM) 20 is any and all payment obligations by which money or credit is transferred from one individual or one entity to another individual or one entity and / or Or with instructions. These obligations include water bills, electricity bills, gas bills, mortgage payments, automobile payments, insurance payments, telephone and / or mobile phone bills, credit card bills, etc. Includes invoices regularly received by individuals or families. These payment obligations may also include any payment initiated by an individual or family, such as gasoline purchases, movie tickets, any cash-only purchases, other retail payments at point of sale, and payments to individuals. Thus, a PM may be generated by the presentation of a bill by a billing entity or in response to an initiation by a user.

  Several PMs 20 that make up a home bill may be communicated to the MFTS via the MFTS billing channel. In accordance with exemplary aspects of the present invention, home bills are sent at predetermined intervals or by communication with an electronic bill aggregator, such as CheckFree Corporation, which electronically provides a “bill presentation” service. It is transmitted to the MFTS in response to a user request.

  The PM 20 that constitutes an “occasional” purchase (eg, at a retail store) or a payment for an individual is usually provided to the MFTS by the aggregator or by a specific billing entity in the first case. Initiated by the user. Transactions initiated by such users are typically sent to the MFTS via a wireless communication device via a service of a mobile communication network (not shown in this figure). Such a PM can be characterized as a “Pay Anyone” transaction because it contemplates making payments to any identified entity, including individuals as well as commercial enterprises, at the user's inception.

  In general, information related to the PM 20 is typically the account (s) of the account owner (s) (ie, the individual responsible for making the payment in the case of a regular home bill). Including name, account and / or mobile device number associated with the account holder, account number, account balance, due date, minimum payment amount, electronic payment account number, billing entity address, etc. This information is usually the same whether the PM is the result of a bill presentation or from user initiation.

  Payment Source (PS): The payment source (PS) 30 comprises any and all funds available to an individual or family for use in performing payments. These funding sources include credit card accounts, debit card accounts, bank checks and / or savings accounts, department store credit card accounts, and the like. These funds are usually divided into two main categories. That is, a bank entity and a credit entity. The entity that provides and / or holds such funds is usually a financial service provider (FSP), often a financial institution (FI). Bank entities typically include check accounts and / or savings accounts where money available to individuals or families is maintained. A credit entity typically includes all credit facilities available to individuals or families.

  In general, the information associated with the payment source (PS) 30 includes the name (s), account number (s) of the account owner (s) (ie, the individual who owns or manages the funds). , Account balances, available credit and credit limits for credit cards or other credit facilities, available cash advance payments, names of other authorized users or account co-owners, special personal identification numbers (PIN), account usage restrictions, etc.

  With continued reference to FIG. 1, the main outputs from the MFTS system 18 are both presented to the individual mobile device 15 from the MFTS 18 and displayed and / or presented to the user 12 for reaction and response. A subset of information regarding one or more payment executions (PM), as well as a subset of information regarding one or more payment sources (PS). In response to the presentation of the PM (or the start of PM), the mobile device 15 provides a payment instruction to perform payment to a payment instruction recipient, such as a financial service provider or financial institution, according to the information in the payment instruction. .

  The entire method for performing payment according to an exemplary aspect of the invention involves seven main steps. The interaction between the MFTS 18 and the mobile device 15 is established via a communication service provided by a mobile communication service provider (MCSP, not shown in FIG. 1) and involves the first four steps of the method. The seven main steps are as follows:

  1. The first step is to push PM information from the MFTS 18 to the mobile device 15 as shown in Step 1 (Step 1 shown in the triangle) and PS information (Step 1 shown in the square). It is.

  2. The second step, as shown in step 2, is used by the user 12 of the mobile device 15 to view the available payment executions (step 2 shown in the triangle) and perform the selected payment. Display available payment sources to do (step 2 shown in the square).

  3. The third step uses a mobile device application on the mobile device 15, as shown in step 3, where the user results in the construction of a mobile payment instruction (MPI) based on information input by the user 12, as an example. And activate the invoice payment function.

  4). The fourth step is communication of the mobile payment instruction (MPI) for processing from the mobile device 15 to the MFTS as shown in step 4.

  5. The fifth step in the overall method, without communication with the mobile device or MCSP, is the construction of an MFTS payment order utilizing information from the mobile payment order and its MFTS payment command communication.

  6). The sixth step in the overall method of the present invention is to use the selected payment source, as shown in step 6, to the selected payee, usually by the payment order recipient via the financial service provider. This is the transfer of funds.

  7). The seventh step in the overall method of the present invention is that the financial service provider sends a payment confirmation message back to the MFTS upon successful processing of the MFTS payment instruction.

  Further details regarding these steps are then provided.

  With respect to Step 1, the information pushed to the mobile device includes a subset of payment execution information as shown in Step 1 (PM) and / or a subset of payment source information as shown in Step 1 (PS). The information pushed out does not include all available information received by the MFTS from the payment execution and / or payment source. Rather, a reduced subset of payment execution information and / or payment source information is pushed to the mobile device to facilitate mobile payment or payment source display. In accordance with exemplary aspects of the present invention, the information is reduced to provide the user with faster and more accurate information that facilitates making a payment and determining what funding source to use. Is done. In the case of an invoice, this reduced information typically includes only the name (s) of the billing entity, the deficit or payable, and the due date for the payment execution. For the payment source, the consumer's account name (s), current balance, available funds, etc. will be shown.

  With respect to Step 2, the user 12 of the mobile device 15 views the payment execution as shown in Step 2 (PM) and pays for use in making the payment as shown in Step 2 (PS). Browse the source. In accordance with exemplary aspects of the present invention, the mobile device user 12 may receive an update from the financial institution regarding the account associated with the mobile device when a new payment execution is received by the MFTS 18 and / or via other communication means. Will be notified via text message (SMS). According to another exemplary aspect, the mobile device 15 may be configured as “bill view”, “bill payment”, “pay anyone” as described in detail herein with respect to various functional software modules. When the selected function is activated on the mobile device, information regarding the execution of a new payment or updated money account information is retrieved from the MFTS.

  According to another exemplary aspect of the present invention, when the mobile device user 12 is in a state of reviewing payment execution, the user 12 executes on the mobile device to review PM and PS. Can start. The PM is browsed via a “bill view” function (also referred to as “View Payment to Make”), and the PS is browsed via a “payment source view” function. An exemplary display screen for information displayed via these functions is shown in FIG. In the case of a “bill view” function, the mobile device user can review the bills received to date and decide at what point (s) to pay for which bill (s). . Via the “View Payment Source” feature, mobile device users can view and determine what (one or more) funding sources to use to pay for their selected bill It is. The selection made in this step is not sent to the MFTS until the “Bill Payment” function is activated. Although viewing the payment execution and payment source does not necessarily require the user to select an invoice to pay, this is one of the main functions contemplated by the present invention. I want you to understand.

  With respect to step 3, the user activates the “Bill Payment” function in the mobile device application on the mobile device 15 to select the payment execution and the corresponding payment source, which causes the mobile application to issue a mobile payment instruction (MPI). To build. This step includes selecting a payment execution, selecting a payment source, and constructing a mobile payment instruction. The mobile payment order typically includes billing entity information, the amount to be paid, the payment date and / or time, and the payment source selected for the payment.

  In step 4, the mobile application provides a mobile payment instruction (MPI) for processing from the mobile device to the MFTS via a wireless connection.

  In step 5, the MFTS processes the MPI to build an MFTS payment order for the payment order recipient, which is optionally a selected financial service provider or financial institution associated with the selected payment source. The complete MFTS payment instruction is typically the MFTS associated with the mobile device user, such as the mobile device user's account number, the appropriate account to use for payment, payment amount, payment date and / or payment time, account credentials, etc. Information included in the mobile payment order, along with other selected information stored in the database.

  In step 6, the payment instruction recipient accomplishes the payment by various means. For example, a payment order recipient can make a payment on his own, or within an MFTS payment order to transfer funds to an identified entity account or other payment instrument associated with the payment execution (PM) It is also possible to provide an instruction to the selected financial institution to use the selected payment source (PS) identified in.

  In step 7, upon successful processing of the MFTS payment instruction, the financial service provider (FSP) communicates a confirmation message back to the MFTS.

  Because the information provided to the mobile device is typically a selected and reduced subset of information related to financial transactions for performing electronic payments using the selected payment source, the mobile device user can: It should be particularly understood that only the minimum required information necessary to determine what payments to make and what sources to use will be seen. More detailed and comprehensive information required to complete the transaction is stored in the MFTS transparently to the user, but can be retrieved and used to perform the payment using the selected payment source. Is done. The user is presented with the required but limited information needed to make payments quickly, accurately, and efficiently using their mobile device at a convenient location and time And is advantageous. Moreover, as will be explained in more detail later, it is preferred that all details of the transaction be captured and stored by the MFTS and accessed and viewed by the user, for example via a web interface, for the user's convenience. .

  More details regarding the implementation of these general steps are provided below.

  Referring now to FIG. 2, a system 200 according to aspects of the present invention includes an MFTS 18, a mobile communications service provider (MCSP) 110, a communications network 120, such as the Internet or a private network, a bill presentation system 190, a user's Web interface 140, mobile device (s) 15, connection or interface to billing entity / payment entity 180 and payment source 30, and other components for certain purposes.

  The MFTS 18 includes a computer system comprising a database 158, a telecommunications interface 152, and software. The MFTS 18 supports three main interfaces or communication methods. A financial service provider (FSP) communication interface 156, a wireless or mobile device (mobile client) interface 152, and a World Wide Web (WWW) or Internet user interface (UI). As known to those skilled in the art, an “interface” is a means or method for interaction between machines, devices, computer programs or other complex tools, and a user interface (UI) is thereby A means or method by which a user interacts with a particular machine, device, computer program or other complex tool. The user interface provides input means (allowing the user to send information to a system such as MFTS) and output means (allowing the MFTS system to display information to the user). These inputs and outputs are transported over the Internet and viewed by the user using a web browser program such as Netscape Navigator, Internet Explorer, Firefox, or any other web browser. In accordance with aspects of the present invention, the user provides personal information to record about the service, enters the personal information and financial information into the MFTS, and confirms such information via a display on the user's computer system. .

  Financial service provider (FSP) communication interface 156 is an interface to financial entity 30 that provides payment source (PS) and bill presentment interface 155 to billing entity / payment entity 180 for payment execution (PM). MFTS computer systems are financed over various types of computer networks such as frame secured dedicated path 160, local area network (LAN), wide area network (WAN), etc., as well as the known Internet 120. Connect to the entity's computer system.

  A wireless device or mobile device (mobile client) interface 152 provides a connection to the user's mobile device 15. The MFTS computer system provides various voice / data services using CDMA, GSM (registered trademark), GPRS, other 2G wireless data communication services, and newly emerging 3G wireless data services. A plurality of interfaces for communicating with the user's mobile device via a wireless telecommunication service provider. As known to those skilled in the art, in addition to the standard voice capabilities of mobile phones, many mobile devices are SMS for text messaging, packet switching to access the Internet, and photos, voice, music, and Many additional services are supported, such as MMS for sending and receiving video. System 18 therefore preferably includes an SMS generator 151 for generating SMS messages. The mobile device communication interface 150 receives financial information and other information and interacts with the MFTS 18 wherever the user is (provided that the user is within the coverage area of his MCSP), Allows various financial transactions to be completed.

  The World Wide Web (WWW) or Internet User Interface (UI) is a one for users to access MFTS for service records, configuration and account setup, account maintenance, payment execution and payment source and status viewing, etc. One or more web applications 154 are provided. Preferably, user account financial information can be submitted to the MFTS from a service registration, for example, by a business arrangement with a selected financial institution having a relationship with the MFTS operator. Alternatively, the user can use a web user interface to enter user account financial information.

  Still referring to FIG. 2, in some embodiments of the present invention, the MFTS 18 may have its own mobile device (s) 15 and / or its associated computer 140, mobile communications service provider 110, the Internet, etc. The user 12 via the data communication network 120, the secure dedicated network path 160, the financial service provider (FSP) 30 providing the payment source 30, the billing entity 180, and / or the bill presentation system 190.

  Mobile device 15 communicates with MFTS 18 via a wireless connection (illustrated as antenna 112) using a wireless communication service provided by a mobile communication service provider (MCSP) 110. Mobile device 15 comprises any device connected for data communication with a mobile communication network via MCSP 110. Such a device 15 may be a pager 15a, a personal digital assistant (PDA) 15b, a mobile communication phone or mobile phone 15c, or any other including PDA or mobile phone functionality with the ability to receive information via a wireless link Electronic devices, can receive user input and send data (eg, payment instructions) to the MFTS.

  The present invention is described in terms generally applicable to various types of mobile communication services provided by MCSP 110. One skilled in the art will recognize that the present invention is not limited to any particular type of mobile or wireless communication standard and may be implemented using any of several different but functionally equivalent wireless data communication standards. The point will be understood and recognized. Currently, in the United States, digital cell phone networks are primarily based on two basic standards. GSM (pan-European digital mobile telephone system) and CDMA (Code Division Multiple Access). Some MCSPs use GSM, while other MCSPs use CDMA. In addition, other MCSPs are based on CDMA, but use a standard called PCS that uses different frequencies. In addition, so-called “broadband” wireless data communication standards, known as WiFi and WiMAX, currently used for WLAN implementations are also available to implement embodiments of the present invention, such standards are Currently, it is not widely deployed in handheld mobile devices.

  These and other wireless data communications that have not yet been created, without undue experimentation, may become known to those skilled in the art how to use such techniques in creating embodiments of the present invention. Standards can be used in constructing the embodiments of the invention described herein.

  It will also be appreciated that upgrades currently contemplated for both the GSM mobile radio standard and the CDMA mobile radio standard, as well as upgrades to other data communication standards, are useful in constructing embodiments of the present invention. For example, to better handle data traffic (in addition to voice traffic), many GSM networks currently have speeds up to 56 Kbps (approximately the same speed as dial-up connections), with GSM signals carrying voice traffic. It operates using a standard called GPRS (General Packet Radio Service) that can carry data. More recently, networks using GSM have added EDGE (Enhanced Data Rate for GSM Evolution), which increases the data transmission rate to 144 Kbps. CDMA networks also increased the data rate to 144 Kbps using a standard known as 1 × RTT (Radio Transmission Technology) measurement throughput. A more recent upgrade for CDMA networks that can carry data at a maximum of several megabits per second, as fast as current DSL or cable Internet connections, is 1xEV-DO (Evolution-Only Data Only)). Still further, some MCSPs currently accelerate connections to up to 384 Kbps and are desired to make and receive voice calls at the same time as users use data services such as wireless laptop usage. It provides a service called UMTS (Universal Mobile Communication System), which is an upgrade of the GSM network, which makes it possible.

  As demand for wireless data communication increases, MCSP is expected to introduce even faster standards and extensions to MCSP networks. For example, the intended Rev A EV-DO accelerates the EV-DO network to 1.8 Mbps upstream and 3.1 Mbps downstream to promise HSDPA (High Speed Down Packet Access), 1.8 Mbps speed, Upgrade to UMTS that also allows voice and data.

  Still further, it will be appreciated that techniques relating to short text messaging (eg, SMS) are typically implemented using the data communication techniques described above for carrying text messages. Such wireless data communication technologies include wireless Internet browsing on mobile devices, music, ringtones, videos, photo downloads, and protocol support for wireless applications (eg, mobile applications built as described herein). Also used to support functions.

  Accordingly, those skilled in the art will understand various equivalents of the elements of the present invention that support mobile applications as described herein and provide wireless connectivity between the mobile device 15 and the MFTS 18 to facilitate transactions. It will be appreciated that objects are contemplated for use in constructing embodiments of the present invention.

  The well-known data network 120, including the Internet, provides accessibility to the MFTS 18 via a wired or wireless connection. The user 12 can access the Internet 120 through his home / office connection as well as through his mobile device 15. The user's computer shown at 140 is connected to the Internet 120 via his home / office connection or wirelessly via a mobile communications service provider. According to aspects of the present invention, the user has the flexibility to access billing information and payment information using computer online with web view access or via mobile device 15 with mobile view.

  In general, mobile devices typically have a smaller display screen (to facilitate mobile use) and users often provide more detailed information that is later available to the user through other means. Given that we want to use some basic functionality quickly and efficiently in a mobile environment, mobile views will provide users with less information than web views. However, the present invention specifically contemplates modes of operation in which further transaction details can be obtained via the functionality of the mobile device as well as via a web view using a computer 140 connection for internet use.

  The MFTS 18 includes a number of software components that execute on a computer server associated with the MFTS, described in more detail later in this document. Such components include an SMS generator 151, an MFTS mobile device communication interface 150, one or more web applications 154, a plurality of partner financial service provider (FSP) interfaces 156, and a user database 158.

  The mobile device communication interface 152 is preferably an HTTP Remote Procedure Call (RPC) that provides mobile clients with access to financial services available on the MFTS. The mobile client interface is preferably designed to facilitate communication between the MFTS 18 and the mobile user, including all data transmission and reception, as well as SMS transmission and reception via the SMS generator 151. The SMS generator receives a message for transmission to the mobile device, converts the message to an SMS format, usually simply text information, and sends the message to the MCSP in the SMS format as specified by the MCSP. It is a software component. Details of the SMS format required for a particular MCSP can be obtained by querying applicable MCSPs.

  The web application 154 resides on the MFTS server and comprises one or more of the following main components: That is, a user site 153 and a management (Admin) site 157.

  The user site 153 has the purpose of enrolling or registering with respect to services provided by the MFTS 18 to manage their mobile clients, maintaining accounts, adding new payees, payers or A web application (HTML) that is capable of performing other user-related functions such as checking account information regarding payment execution. The user site 153 allows the user to obtain a username and password for security purposes and provide the MFTS 18 with detailed information about the payment entity's payment source, such as the user's billing entity and account number, access / authentication method, etc. Used to register for the purpose of receiving services by providing appropriate information such as name, address, mobile number, etc.

  Management site 157 is an application (usually web or HTML) used by MFTS production workers to manage the system. The management site 157 is typically used by MFTS 18 information technology (IT) administrators, problem solving, query answering, account maintenance, transaction history browsing, general system monitoring, and the like.

  The MFTS 18 also provides a plurality of partner financial service providers (FSPs) 30 that are entities that provide functions such as payment details, bill aggregation or bill payment connectivity, or entities to which payment instructions are sent on behalf of the user. A financial service provider communication interface 156 is provided. The financial service provider communication interface 156 facilitates electronic data communication information transfer between the MFTS and individual financial service providers such as bank entities, credit entities, and the like. The technical requirements for these interfaces vary in their implementation and may need to be customized to accommodate each individual financial service institution. Such an interface is typically implemented as a real-time web service interface or a batch mode file transfer protocol, depending on the capabilities and requirements of participating partner financial service providers. Details of the data communication requirements of a particular FSP can be obtained directly from the FSP.

  Special secure private network paths 160, such as frame relay, private network, internet virtual private network (VPN), or web service, are used with MFTS 18 to ensure the security of financial information transmission. It is preferably used for data communication between different FSPs. Details regarding specific types of security, protocols, requirements, etc. will be defined between the MFTS 18 and the respective financial institutions participating in the systems and methods described herein.

  Still referring to FIG. 2, the user database 158 associated with the MFTS 18 shows how payments are made to all users, financial service providers serving users, billing entities serving users, payees and payees. As well as other related information. Details regarding the information stored in the user database 158 are provided with respect to FIG. 6 and related discussion.

  As previously explained, FSPs that provide payment source (PS) 30 are banks, credit unions, savings companies and financial lending companies, consignment companies that provide savings / check accounts / financial market accounts, and other financial services. Includes banking entities such as institutions, credit card issuers, banks and / or department stores, credit entities such as oil companies, and any other financial institutions in which MFTS users operate. Payment source 30 provides payment 194 to selected billing entity 180 as described herein.

  Billing entity 180 may send a bill to the user regarding gas 185, water, electricity 181, telephone / cell phone 183, satellite / cable / Internet provider, credit card company, and purchased product or service provided. Includes service companies that provide services to users, such as other entities. As will be appreciated, many billing entities 180 send bills 192 on a regular basis (often monthly). Invoices may also come from billing entities that serve users, such as insurance companies, homeowners' associations, garbage collection, pest control, auto repair, lawn & garden, landscaping, cleaning, etc. Some entities do not send monthly invoices, but invoices on demand, every six months, every three months, or every year, or when service is provided. Occasionally people need to pay individually to others, such as colleagues, friends, and family. These invoice payment obligations or non-invoice payment obligations are all called payment execution (PM).

  In accordance with one exemplary aspect of the present invention, the bill presentation system 190 receives bills from the billing entity 180 and presents those bills electronically or otherwise for presentation to the user. It can be used to aggregate into a package. The bill presentation system 190 can be either a service or component of the MFTS 18 or an independent service entity. For example, CheckFree Corporation, Norcross, Georgia provides billing aggregation and billing services. The bill presentation system retrieves the bill from one or more individual billing entities and presents the bill to the MFTS system. Information about the collected / retrieved bills is stored in the user database 158 of the MFTS 18.

  The billing aggregator and MFTS 18 can be configured as separate systems and can be operated by the same entity or by different entities, or the aggregator function and the MFTS function run as complementary and intercommunication computer processes It will be understood and appreciated that it can be constructed as an integrated system. Thus, while FIG. 2 shows MFTS 18 and aggregator / invoicing system 190 as separate entities, those skilled in the art will appreciate that such functionality may be provided in an integrated system.

  In accordance with exemplary aspects of the invention, mobile device 15 is configured to operate with a billing entity, such as a retail store, upon receipt of a payment execution (PM) from a radio frequency identification (RFID) device 187. It is possible. Various types of RFID-based payment terminals are now available in the commercial field. As will be known to those skilled in the art, an RFID-based payment terminal is associated with a proximity to an RFID-based payment terminal, possibly detecting the presence of RFID electronic circuitry contained within a mobile device. It is operable to automatically transmit wireless (WiFi, Bluetooth, infrared, etc.) signals comprising payment information to the device. Mobile device 15 received payment obligations (PM) from a customer at a point of sale (POS) via wireless communication in a direct manner, thereby providing a user as described herein. It is contemplated that it may be configured to provide the ability and opportunity to pay for a billing entity for goods or services.

  FIG. 2 also shows a special financial service provider (FSP) 175 that provides a special holding account instead of the MFTS 18 for the purpose of temporarily or temporarily holding funds for the transaction. Holding account FSP 175 provides funds for escrow-type transactions where the release of payment to billing entity 180 is conditioned on a number of events, such as delivery of specific goods or services, specific permissions from users, or other purposes. Provide an FDIC-guaranteed account to hold. The holding account FSP 175 can be used in the following exemplary manner. That is, when a payment source (PS) is selected by the user to make a payment, the selected payment source funds the funds to the billing entity or payment entity to which the holding account 175 was currently directed. Use payment instructions to send funds to a holding account 175 that will be held for the user until a release event (e.g., delivery of goods, execution of a contract, or other predetermined event) Can be ordered.

General Operation of MFTS Prior to discussing the software architecture of the preferred embodiment of the present invention, the overall operation of the disclosed MFTS 18 will be briefly described. As will be appreciated, most of the functionality of embodiments of the present invention is implemented in computer software, user interaction with its mobile device, creation of data records, communication between the mobile device and the MFTS 18, and It involves communication between the MFTS 18 and various other parties and their systems, such as financial institutions, billing entities, individuals on which payments are made. Still referring to FIG. 2 in this regard, the overall operation of the MFTS 18 according to some aspects of the present invention includes the following exemplary steps.

  1. The customer or user 12 first records in the MFTS 18 and creates an account using the MFTS service. This recording is completed via the user website interface 154 via a computer 140 using an internet connection or via a mobile device 15 with internet accessibility. The account owner (user) selects a username and password for security and authentication purposes, or is given the username and the password. A user profile is created for the account and necessary information such as a mobile device identification number or a telephone number associated with the account is entered and stored in a user database 158 in the user record. All billing entities related to the payment execution (PM) that the user wants the MFTS to service are included by the user, including account number, account owner name and address, billing cycle, and any other relevant information. Entered into the user database. Similarly, one or more payment sources (PS) are the bank routing number (s) and account number (s), account owner (s) Name (s) and address (s), access code such as PIN, access method, credit card number (s), credit card (s) It is also entered into the user database, including the expiration date (s). Alternatively, FI information can be pulled into the MFTS via the FSP communication interface 156.

  2. In accordance with one exemplary aspect of the present invention, user 12 downloads a mobile client (also referred to as a mobile application or “mobile wallet”) from MFTS main website to his mobile device 15 as shown at 215. To do. The downloaded mobile application is (a) downloaded to the user's computer 140 for later synchronization and / or loaded using the mobile device if the mobile device software must be loaded from the PC Or (b) or can be downloaded directly to the mobile device over a wireless network in situations where the mobile device is capable of direct application download . The mobile client or application is configured and certified with respect to the brand and model of the mobile device 15 owned by the user 12. For example, the mobile application in the disclosed embodiment is an application that resides on the user's mobile device. In accordance with a preferred exemplary aspect of the present invention, the mobile client is an application that runs independently on the mobile device and does not require an active communication connection to the MFTS 18, so local storage on the mobile device. ) Allows the mobile client to operate in offline mode when or when the mobile device is outside its coverage area. The ability to utilize local storage on the device allows data caching to accelerate end-user interaction and the ability to queue user initiated transactions until connectivity is restored. In addition, offline support makes it possible to eliminate intermittent signal behavior that can affect the user experience found in WAP-based solutions in today's market.

  3. At predetermined intervals, the MFTS sends a request to retrieve the MFTS user's bill 192 to the billing aggregator (eg, bill presentation system 190) or to the billing entity 180. Alternatively, the MFTS can receive bills from a billing entity in a billing cycle, from a billing aggregator, or directly from a billing entity.

  4). The MFTS receives the bill and (in one aspect) notifies the user about the bill to be paid via SMS. The user then initiates the mobile client software on the mobile device 15 that communicates with the mobile device communication interface 152 to look up the bill to pay. The SMS message preferably includes only simple short and omitted information such as the name of the billing entity and the amount to be paid, additional information can be obtained by the mobile device (see next step) .

  5. A user can use a mobile wallet application on his / her mobile device (s) to view invoice (s) received via a request for all applicable billing entities. Start.

  6). If the user decides to pay for an invoice, the user selects one of the available payment sources (PS) and multiple invoices (PM) possible to perform the payment One of these can be selected. The payment order is formed by the user by selecting a PM and selecting a PS for PM.

  7). The user is preferably presented with a confirmation screen on the mobile device that displays basic information about the bill to be paid, timing of payment, available balance, etc. before making payment to the system. If the user confirms payment, the mobile device 15 sends the omitted mobile payment instruction to the MFTS 18.

  8). In response to receiving the mobile payment instruction from the mobile device, the MFTS 18 receives payment from the selected PS using a pre-selected or selected payment method as part of the PM and PS selection process. Other relevant information is added to form a complete payment order (MFTS payment order) that instructs the financial service provider selected to complete the payment transaction by transferring funds to the person.

  Further details regarding specific communications between the mobile device 15, the MFTS 18, the FSP 30 with payment source, the billing entity 180, the bill presentation system 190, etc. are provided in various flowcharts and diagrams elsewhere in this document.

Software Architecture The mobile financial transaction system (MFTS) software architecture is shown in FIG. According to one embodiment of the invention, the MFTS software comprises two main components. The mobile device application 400 (“mobile wallet”) and the MFTS software 500. The mobile device application 400 resides on the mobile device and is accessed by the mobile device owner. The MFTS software application 500 resides on a server computer connected to the Internet and is accessed by the user via the user's mobile wallet application and web browser.

  Referring now to FIG. 3A, a software architecture diagram of a mobile device application 400 (“Mobile Wallet”) according to one embodiment of the present invention is shown. The mobile device application 400 displays a mobile device main program 335 for controlling the operation of the mobile device application 400 and a message, receives a user selection or user input, and enters a mobile device for smoothing the user's operation. An output interface 331, a security manager 333 for providing security means for wireless communication, and data stored in and / or from a local storage device 341 such as a non-volatile memory device in a mobile device Mobile device storage interfaces 337 for retrieving and mobile devices on mobile devices that then communicate with a mobile communication service provider (MCSP) 110 according to their provider's specific protocol And a mobile device communication interface 339 for communicating with Le device radio hardware 343.

  FIG. 3A also illustrates some routines or functions 301, 303, 305, 307, 309, 311, 313, 315, and 321 provided by the mobile device software or mobile wallet application 400. Such routines or functions provide user functionality on the mobile device, as shown. The payment source browsing routine 301 realizes display of the payment source on the user's mobile device. Details of this routine are provided in FIGS. The invoice viewing routine 302 implements an invoice or payment execution display on the user's mobile device. Details of this routine are provided in FIGS. The bill payment routine 305 implements the selection of a bill or payment execution to be paid on the user's mobile device. Details of this routine are provided in FIGS. The pay-by-one routine by name 307 implements payment for an individual by name on the user's mobile device. Details of this routine are provided in FIGS. 19-22 and 26-28. The pay-any-one routine 309 by mobile number implements payment for an individual by mobile number on the user's mobile device. Details of this routine are provided in FIGS. 23-25 and 29-31. The balance transfer routine 311 realizes transfer of funds between the user's accounts via the user's mobile device. Details of this routine are provided in FIGS. The Download Application routine 313 performs mobile from the MFTS to the user / payee's mobile device with respect to receiving payment to enable the payee to use aspects of the invention with respect to receiving payment. Realize download of wallet application. Details of this routine are provided in FIGS. A Change PIN routine 315 allows a user to change their personal identification number (PIN) via the mobile device. Details of this routine are provided in FIG. The SMS (text message) receiving routine 321 implements sending a text message (SMS) to the payee to notify the payee that the payment has been received. Details of this routine are provided in FIGS.

  Referring now to FIG. 3B, a software architecture diagram of MFTS software 500 according to one embodiment of the present invention is shown. The MFTS software 500 receives MFTS main program 350, the MFTS mobile device communication interface 150 for communicating with the mobile communication service provider 110, and the user registration or record via the user website on the Internet 120 and retrieves the information. Web application interface 154 for updating, P2P service 375 for facilitating person-to-person financial transactions, and for storing data in and / or retrieving data from the MFTS user database 158 A storage / database (DB) interface 377, a money account service 379 for facilitating user authentication, a financial service provider 30, and Bill presentation for receiving bills from various billing entities 180 via a billing system 190 through a financial service provider (FSP) communication interface 156 for communicating with the MFTS bank holding account 175, if applicable And an interface 155.

  The MFTS main program 350 interacts and coordinates with other modules and services within the MFTS to function as a “traffic cop” for information routed between various storage and communication interfaces.

  A preferred web application input / output interface 154 is that the user registers or records in the MFTS system, adds / edits / views / deletes mobile clients, adds / edits / views / deletes credit cards / bank accounts, And add / edit / view / delete payees or billing entities. Web application interface 154 further allows a user to initiate a mobile client to unlock a locked mobile device after a series of failed logins. Exemplary displays associated with the preferred web application interface 154 are shown in FIGS. 10-12 and described with respect to FIGS.

  The preferred web application interface 154 provides several functions or routines for users to access via an internet (web) connection, if desired. It is understood that users may prefer to perform several types of functions through the Internet web interface instead of through the mobile interface, such as registering, adding payees, changing behavioral configurations, etc. Like. For example, according to aspects of the present invention, in a preferred embodiment, the functionality provided via the web interface includes registration 351 (see, eg, FIG. 37) and mobile client editing 353 (eg, FIG. 37B). 37D), credit card and / or bank account edit 355 (eg, see FIGS. 38A-38D) and payee edit or add 357 (eg, see FIGS. 39A, 39B). Mobile client initialization 359 (see, eg, FIGS. 37A, 37C) and mobile client unlock 361 (see, eg, FIG. 37A). Details of preferred software routines are provided with reference to the referenced figures.

  The preferred input / output interface 154 can be replaced with an alternative embodiment 154 'of the interface that provides different web user interface functionality and display, as described with respect to FIGS.

Mobile Device Software FIG. 4 is a flow diagram of a main program 335 that is one of the mobile device software modules executing on the mobile device 12 in accordance with an embodiment of the present invention, the “mobile wallet” software 400. From FIG. 3A, in the disclosed embodiment, the mobile device main program 335 includes a mobile device input / output interface 331, a security manager module 333, a mobile device storage module 337, and a mobile device communication interface module 339. It will be appreciated that this is the main program loop of the mobile wallet software 400 that coordinates the operation of the mobile device software module.

  In normal use, a mobile device user activates his mobile device to review the recent text message (in some embodiments) and initiate the operation of the mobile device main program 335 to the mobile device application 400. Navigate or “start” the mobile device application 400 to view the display generated by the program, eg, to view an invoice, to select a payment source, or to make a payment Interacts with programs for the purpose of providing commands and input. In accordance with aspects of the present invention, the user initiates the mobile device application 400 in response to receiving a text message (or other message from the MFTS) indicating that a new invoice is available for payment. The mobile device application can be started independently to activate functions such as viewing the bill, paying for the bill, etc.

  In FIG. 4, the first step 405 involves the mobile device confirming whether a text message (SMS) has been received. For example, according to an aspect of the invention, the text message is to notify the user that a new invoice has been received and can be paid, or that payment has been received from another user. To the mobile device by the MFTS. In this regard, see FIGS. 15 and 20.

  It will be appreciated that the received text message may or may not relate to MFTS or any of its functions. However, any irrelevant text message will be ignored for purposes of discussion herein, and all received messages are assumed to be related to MFTS and its operation. Also, in some mobile devices, text messages are received from independent processes or modules and stored in memory for access by other processes, while the receipt and processing of text messages is within mobile device software 400. It will also be understood that it can be optionally integrated as an integration function. If a text message related to the MFTS function is received, whether by an independent process in the mobile device or integrally in the application, in step 460 the user opens the text message and responds to the message. It is possible to decide what to do in order to do so.

  At step 470, if the user is not a currently registered user, the user may choose to download mobile device software (eg, download mobile wallet software). The user will be provided with information on how to access the software and how to download the software. More information about registration is provided elsewhere in this document. Before any of the other functionality in FIG. 4 can be activated, the user will be required to download the mobile wallet software and run the software on his mobile device.

  After step 460, the program can loop to step 490 to look for an exit (end) command or exit (end) event, loop back to step 405 in a continuous loop, and repeat the operation. .

  Returning to step 405, if no text message has been received, program control moves to step 410 where the user can activate the mobile wallet software 400 and choose to utilize the functionality provided thereby. . If not (ie, if there is no user command to enter the mobile wallet software at step 410), control loops back to test for text messages and / or to activate the mobile wallet software.

  If the user initiates operation of the mobile wallet software 400 at step 410, control passes to step 415 where the user can select from a list of functions provided by the software on the mobile device. Their functions are described below. The program continuously loops waiting for user input for the selected function, including an “exit” command as shown in step 490.

  According to one embodiment of the present invention, at step 415, the user may choose to activate or execute the following functions provided by the mobile device main program 335:

  1. View payment sources and balances as shown in step 420 (see FIGS. 13 and 14 for further discussion).

  2. Browse the bill as shown in step 425 (see FIGS. 15 and 16 for further discussion).

  3. Pay for the bill as shown in step 430 (see FIGS. 17, 18A and 18B for further discussion).

  4). Activate the “Pay Anyone” function as shown in step 435 (see FIGS. 19-31 for further discussion).

  5. Request an account balance transfer as shown in step 440 (see FIGS. 32 and 33 for further discussion).

  6). Change the personal identification number (PIN) as shown in step 445 (see FIG. 36 for further discussion).

  Where “inbox” and “outbox” functions are provided for viewing incoming and outgoing payments, other functions according to aspects of the present invention are also provided.

  7). View inbox payments as shown in step 450 (see FIGS. 20, 22-24 for further discussion).

  8). View the outbox payment as shown in step 455.

  The function for viewing inbox payments (step 450) and the function for viewing outbox payments (step 455) are used to receive incoming payments from other users (inbox payments) in order to independently view the operation of the mobile wallet software. ) List is maintained in the mobile device and / or the list of outgoing payments generated and sent from the mobile wallet software is maintained in the mobile device while the payment is incomplete. Please understand that.

  Still referring to FIG. 4, after the user activates certain functions, the appropriate program instructions to achieve those functions are executed by the mobile device. An exemplary display and discussion of such functionality is provided with respect to the drawing referenced in FIG. 4, and such discussion is presented to the reader elsewhere. After each function is performed, the mobile device application proceeds to step 490 and loops back or exits to test for the input of another user function. The user can continue further operation of the mobile device application or exit the application. If the user decides to continue, the mobile device application returns to step 405 to confirm the text message or continues operation of the mobile wallet application.

  FIG. 5 is a flow diagram of an MFTS main program 350 that is one of the MFTS software modules 500 executing on the computer system or server in the MFTS 18 in accordance with aspects of the present invention. This main program 350 includes, for example, MTFS mobile device communication interface 150, SMS generator 151, web application 153, FSP communication interface 156, bill presentation interface 155, user database access and maintenance 158, etc. as shown in FIG. Coordinate other programs and functions of MFTS. From FIG. 3B, in the disclosed embodiment, the MFTS main program 350 is the main program loop of the MFTS software module 500 that coordinates the operation of other software modules associated with and forming part of the MFTS 18. Let's understand the point.

  In normal use, the MFTS 18 operates continuously to monitor for input from various sources. The main input comes from the mobile device when the user views and pays the bill, and comes from communication with the billing entity, financial institution, and / or FSP to receive the bill to be paid, and the user has an account or MFTS system Resulting from user registration that establishes relationships with operators, provides payment instructions to such institutions and partners, and enters information to receive information such as account balances and payment confirmations. Those skilled in the art will appreciate that the software 500 is multi-threaded and multi-tasking web-enabled secure real-time 24/7 computing environment in which the system is message driven by various entities with which the system communicates. It will be appreciated that it is preferably constructed to run on a computer server.

  In FIG. 5, the process for the MFTS main program 350 is that input has been received and processed from related entities (eg, user via mobile device, user via web interface, FSP, etc.). Start by determining. The system determines whether input is received from the mobile device communication interface 152 at step 505, determines whether input is received from the web application 154 at step 510, and is charged at step 515. It is determined whether it is received from the document presentation system interface 155 and at step 520 it is determined whether input is received from the financial service provider (FSP) interface 156. At step 530, program 350 then branches to the appropriate routine or interface to perform the specific function associated with the incoming message or executes the appropriate routine or interface. In particular, according to aspects of the present invention, such routines or interfaces include: (a) processing communications and messages with the bill presentation service via the bill presentation interface 155; and (b) a web application interface. Processing communications and messages with a user or administrator having web access via 154; (c) processing communications and messages with mobile devices via the mobile device communication interface 152; ) Processing communications and messages related to person-to-person (P2P) type payments through the person-to-person payment service 375; and (e) Processing communications and messages related to the user's money account via the money account service 545 When (F) via the FSP communication interface 156 and a processing the communications and messages relating to financial service providers (FSP).

  As briefly described above with respect to FIG. 3B, the mobile device user wishes to register as a recorded member of the MFTS after receiving payment from the recorded user or at his own discretion. There is a case. Users can access websites designated by the MFTS using their computers connected to the Internet and web browsers to use web applications. The website may include information about the services and benefits offered by the MFTS and specific pages for user registration. If the user decides to register, the user then accesses the web application achieved by the web application interface 154 and selects a function for execution.

  As shown generally in FIG. 3B, typical web accessible features provided to the user include:

  1. Register the new mobile client with the MFTS (see FIG. 37A for the preferred embodiment and FIG. 40 for the alternative embodiment).

  2. Edit the mobile client, including adding, editing, viewing, and deleting mobile clients (see FIGS. 37B and 37D for the preferred embodiment and FIG. 40 for the alternative embodiment).

  3. Editing credit cards and / or bank accounts, including adding, editing, viewing, and deleting credit cards and / or bank accounts (FIGS. 38A-38D for the preferred embodiment and FIGS. 38A-38D for the alternative embodiment). 42).

  4). Editing payees, including adding, editing, viewing, and deleting payees (see FIGS. 39A-39B for a preferred embodiment and FIG. 41 for an alternative embodiment).

  5. Initialize the mobile client, including software download to the specified mobile device, password setup, and mobile device activation (see FIGS. 37A and 37C for preferred embodiments).

  6). Unlock the mobile client after a predetermined number of failed logins (possibly accidentally or to prevent fraud) after the mobile device locks (see FIG. 37A for preferred embodiment) ).

  Returning to FIG. 5, after each function is performed, the MFTS main program 350 continues to execute by looping back to test for new inputs at steps 505, 510, 515, and 520.

User Database and Schema Although shown in FIG. 3B, but not shown in detail as an independent step or process in FIG. It will be appreciated that a storage / database (DB) interface 377 is included. This database 158 stores two main data categories. That is, user data and transaction data. User data comprises information about individual users of the system, including each payee, financial institution, and account of the user. Transaction data comprises information specific to a particular user's particular transaction (eg, when the user provides instructions to the system to pay for a particular bill). Transaction information is a record of each transaction initiated by the user. Both transaction information and user data are stored in tables in a user database 158 organized in a specific format or schema in accordance with aspects of the present invention.

  FIG. 6 illustrates a database schema (data table layout) for a user database 158 in a mobile financial transaction system (MFTS) according to an exemplary aspect of the present invention. The user database 158 comprises a number of related data tables. That is, a master user table 610, a user money account table 620, a financial service provider (FSP) table 630, and a payee table 640. These tables store data associated with the user, the user's account, the financial service provider (payment source) associated with the user, and the payee associated with the user. As is known to those skilled in the art, a database table typically comprises a plurality of records comprising one or more fields or items of data with which each record is associated. Moreover, those skilled in the art will recognize that a “record” in data terminology is usually a single instance or single data item consisting of a collection of one or more fields or sub-items of information, The field or sub-item typically has a field identifier in the schema that identifies what the information in the field represents. An array or collection of records is often referred to as a “table” or “database”. Databases or tables are often specified in a specific way so that records can be identified, retrieved and used during a transaction, or can be updated with new information as needed. Contains one or more index fields or entries that allow quick access to the record.

  Master user table 610 comprises a set of information (records) about each recorded MFTS user. In one aspect of the invention as shown in FIG. 6, the set of information includes a user identifier or user ID, a name (eg, the user's name), a user name (eg, a login name associated with the user), and a system. Other information that identifies the particular user as being registered for system use. Additional information that may be included in the user table 610 includes account numbers (eg, user account numbers at the entity operating the MFTS), mailing address, residential telephone number and mobile telephone number, and mobile devices associated with the MFTS. Provide user contact information such as phone number, email address and password. As will be appreciated, according to various aspects of the present invention, a mobile device typically includes a system, such as a system for performing payments, viewing bills, obtaining real-time account balances, etc. The user identifier will be provided to the MFTS in some form when the user logs in to allow the user to be authenticated for use.

  The set of information in master user table 610 preferably further comprises pointers for entry in user financial account table 620, financial service provider table 630, and payee table 640 associated with the user. As known to those skilled in the art, a “pointer” in a database is information that allows a computer program module to locate and retrieve relevant information in another table of the database.

In accordance with aspects of the present invention, each user can have multiple financial accounts and multiple financial service providers for such accounts. For each user, the user monetary account table 620 comprises information about one or more accounts of a user having at least one financial institution or financial service provider (FSP), which information is for users at a particular financial institution. Account number, monetary account type (e.g., check, savings, credit card, financial market, etc.), user account number at the user's financial institution, ("FSP
It includes an index or pointer to a particular financial institution or provider in the financial service provider table 630 indicated as “ID” (provider number). Other information regarding the identification and / or use of the user's financial account can also be stored and contemplated.

  Financial service provider table 630 comprises information corresponding to one or more financial service providers associated with the user. For each financial service provider entry in table 630, the table is provided with an index number and / or identifier (ID), provider name and / or nickname associated with the associated money account in user money account table 620. Type of service (eg, billing service, bank, credit facility, etc.), financial service provider account number (not shown), associated password (not shown), account holder contact information, confirmation data Information including, but not limited to. Other information regarding the identity and / or usage of the user's financial service provider may also be stored and contemplated.

  The payee information is stored in the payee table 640. Payee information is the information required to identify the specific payee to whom payment is or can be sent and how the payee should be paid. Multiple payees may be set up for each user of the MFTS. Payees provide billing entities that provide services such as water, gas, electricity, local or mobile phone services, mortgages, credit cards, and / or monthly bills, Or, if not, it can be another company that provides invoices on a regular basis. On the other hand, the payee may also be an individual (eg, a user's associate, colleague, acquaintance, relative, etc.) from whom the user may sometimes have a payment obligation. Payee table 640 includes an account number or identifier associated with a user of the MFTS that associates the payee with a particular user, a payee number or payee identifier that identifies the payee (eg, payee Person ID), account number associated with the payee, payment period, payment authorization, etc., and information relating to or associating a particular user with one or more payees. Other information regarding the identity and / or usage of the user payee can also be stored and contemplated. In accordance with an aspect of the present invention, a particular payee associated with a user can send an MFTS to Table 640 to obtain information about the payee so that payment can be made to that payee. Identified in the payee table 640 by providing information to the MFTS via a mobile payment order to access.

  Referring now to FIG. 7, a transaction table 710 is maintained in the transaction database 705 to store information related to mobile transactions, such as payment source balance queries, payment execution queries, and payments performed by the user. . Those skilled in the art will recognize that each payment transaction or each query transaction from a mobile device results in an audit trail, ie a dated transaction record, and a database commit operation and rollback. It will be appreciated that for the purpose of facilitating operation, it results in the creation of at least one record stored in the transaction table. Each transaction record includes a transaction identifier (unique identifier), start and end dates and time stamps, user name or user ID or both, one or more selected financial institutions, their financial Institution name or nickname, or encoded identifier, selected account, nature of transaction, timer for synchronized response, balance amount for each account involved in query, shortage for invoice query , Payee name and / or payee encoded identifier, payee phone number, payment amount, status flag for payment as incomplete / complete, but not limited to. It will be appreciated that a transaction is typically initiated on a mobile device, but can also be initiated by a user 12 using a web application. Transactions are sent to the MFTS. The MFTS processes the query or payment to create a transaction record 715 corresponding to the transaction in the transaction table 710 of the transaction database 705, store the record in the transaction table 710, and select a particular financial institution or payment source ( Create an MTFTS payment order (MFTSPI) for PS) and send MFTSPI to that financial institution, PS. When payment by the PS is completed and upon receipt of the payment confirmation message returned from the PS, the corresponding transaction record 715 in Table 710 is completed by changing the status flag from incomplete to completed, for example. Updated to display what has been done. According to one embodiment of the present invention, records regarding completed transactions are moved to a log file according to their completion time for archiving. Other information regarding the transactions and their status can also be stored and contemplated.

Mobile Device Application Flow Diagrams Mobile device application flow diagrams according to embodiments of the present invention are shown in FIGS. In FIG. 3A, the mobile device communication interface 339 is used to facilitate communication between the mobile device main program 335 and the mobile device wireless hardware 343. The mobile device communication interface 339 communicates with the MFTS mobile device communication interface 150 in the MFTS 18 by wireless communication via the MCSP 110.

  A flow diagram of the MFTS mobile device communication interface 150 is shown in FIG. It will be appreciated that this process 150 on the MFTS side communicates with similar processes in the mobile device via the mobile device communication interface 339 in the mobile device. In this flow diagram, the MFTS mobile device communication 150 interface first establishes a communication link to the mobile communication service provider (MCSP) to which the user has subscribed in step 805. A mobile device communication interface is set up between the mobile device and the MCSP, and the interface receives data communication from both sides. The mobile device communication interface 150 comprises a continuous loop shown in step 810 to check whether any new messages have been received from either the MCSP or the mobile device. If no message is received, the loop continues until a new message is received. If the mobile device communication interface 150 receives the message, the mobile device communication interface 150 checks to determine where the message came from by checking the transmitter / receiver information at step 815. If the message comes from a mobile device requesting information from the MFTS server, the mobile device application proceeds to step 840 to add the task to the processing queue, and in step 845 the response from the MFTS server via the MCSP. Set a timer to wait. The mobile device communication interface waits until a response is received from the MFTS server or until the timer times out, whichever comes first. If the mobile device communication interface receives a response within a predetermined timeout period, a message is sent to the mobile device at step 850. Otherwise, if the MFTS mobile device communication interface 150 does not receive any response in a timely manner, an error message is sent to the mobile device notifying the user that a failure has occurred. Both step 850 and step 820 converge to step 825 to extract a subset of information from the message or response received from the MCSP. The information extracted at step 825 is sent to the user's mobile device for display at step 830. After the message is displayed, the mobile device communication interface returns to wait for the next message at step 860 until the user stops the mobile device and exits the mobile device application.

Aspects of Mobile Client Security In order to use the MFTS 18, a user 12 with a suitable mobile device 15 must record on service with an entity operating the MFTS 18 constructed according to the exemplary aspects of the present invention. This recording process necessarily involves entering and storing important personal and financial information about the user, either manually or via an external system. The security and security of personal and financial information requires MFTS 18 to provide security assurance and security measures from the MFTS administrator. In accordance with exemplary aspects of the present invention, the disclosed MFTS 18 implements strong security measures at both ends of mobile communications: (1) at the mobile client and (2) at the MFTS server system itself. In accordance with exemplary aspects of the invention, one or more of the following security measures are implemented in MFTS 18 for communication with a mobile device.

  Secure mobile client delivery: According to one aspect of the invention, mobile applications are delivered into mobile devices via a secure wireless delivery method (eg, by downloading). In accordance with this aspect, the mobile application is built as a wirelessly distributable or downloadable application or “applet” that is downloaded into the mobile phone from a central site (eg, from MFTS 18). Those skilled in the art will appreciate that there are currently several different but generally equal programming environments for developing applications for various types of mobile telephones and wireless data communication technologies.

  One known secure delivery method is Qualcomm, Inc. Is a BREW ™ wireless content distribution platform for CDMA communication technology provided by. Details of application development and delivery methods for Qualcomm compatible mobile devices are available from the manufacturer.

  Another delivery method is Sun Microsystems, Inc., also called JAR. JAVA (registered trademark) Archive file, which is a platform available from In this case, the mobile application is constructed as a downloadable JAVA application downloaded into a JAVA compatible mobile phone. Those skilled in the art will appreciate that the Java 2 Micro Edition (J2ME) programming environment can be used to develop applications for several types of mobile phones (eg, Motorola). Such an application, also called an “applet” or “midlet”, is essentially a computer program that runs within a specific operating environment of a particular type of mobile phone. Details of the J2ME application development environment are available from the manufacturer.

  The JAR file used to deliver the mobile client application contains a code signing digital key issued to the MFTS 18 by an authentication process (eg, a digital key process provided by VeriSign, Inc.). And is preferably digitally signed. This allows the user to verify the reliability of the mobile client application. Details of the mobile security technology provided by VeriSign can be found in VeriSign, Inc. Available in the documentation and on the website.

  SSL communication to the MFTS server: One skilled in the art will appreciate the importance of security for communication between the user and the MFTS 18 via a mobile device or via a web interface. Accordingly, all HTTP communication with the server in the MFTS 18 goes through HTTPS. That is, it is secured via the known secure socket layer (SSL) protocol. As will be known to those skilled in the art, SSL is a protocol developed by Netscape Communications Corporation for sending private documents over the Internet. SSL uses a cryptographic system that uses two keys to encrypt data. A public key known to everyone and a secret key known only to the recipient of the message. Details of the SSL security protocol are available from the manufacturer.

  Alternatively, a lower level of security may be implemented for wireless communication through the use of known wireless transport layer security (WTLS). However, it will be appreciated that WTLS may be less secure than the SSL protocol because WTLS uses a weaker encryption algorithm and several exploits have been identified for the protocol. In addition, data communicated using WTLS is decrypted at the WAP gateway and re-encrypted via SSL to the destination host. This provides an opportunity to put the WAP gateway at risk of interfering with sensitive transmissions.

  The MFTS mobile client application preferably makes a direct SSL connection to the MFTS server and is not susceptible to security issues that plague WTLS and WAP applications. Thus, when HTTPS is used for all communications between mobile clients and MFTS servers, the underlying mobile data transmission technologies between mobile devices and MFTS, such as GPRS and CDMA, are not significantly related to the security of data regarding transactions. You will understand what should be.

  Digital Key for Client: According to another exemplary aspect of the present invention, a unique digital key is issued to each client (mobile device) for use in digitally signing all communications to the MFTS server. The This strongly authenticates the mobile client to the server and discourages impersonation or impersonation of the mobile client. It will be appreciated that such a method provides stronger security than an online banking site that requires only a username and password for access, which is easier to compromise than a digital key. Using an MFTS mobile client to access financial services is considered equivalent, even if it is less secure than commonly used browser-based online banking systems that require only a password for authentication.

  PIN required to unlock the client: According to another aspect of the present invention, additional security for the mobile device 15 provides the PIN to unlock the mobile client each time the mobile client is initiated. Provided by requiring the user to enter. This prevents the use of the application if the phone is stolen or “borrowed”. The client locks down after several unsuccessful login attempts, and the user either contacts support (via a web application) or logs into the MFTS system and initiates a procedure to unlock the mobile client It is also preferred that the PIN lockout be implemented on the mobile client so that no further attempts will be allowed until the client is unlocked. This prevents attempts to use “brute force” to guess the PIN. It will be appreciated that the combination of PIN and digital certificate creates a two-factor authentication mechanism for using the mobile wallet software 400 on a mobile device.

  Mobile client deactivation in case of theft or loss: If the user's mobile device is stolen or lost, the user can access the MFTS 18 via a web application to deactivate the mobile client It is. This prevents further communication between the mobile client and the MFTS, and erases all demographic information about the user's mobile wallet from the mobile client.

  Encryption of data located in the local storage: All data located in the local storage on the mobile device 15 is preferably encrypted. This ensures that data stored on the mobile client in local storage cannot be read if the mobile device is lost or stolen. However, the mobile device does not store all information about the user's account, bank, account number, etc., only the reduced set of information represented by the code, thus risking the user's confidential information It will be appreciated that is reduced. For example, the mobile device only stores information indicating that the user has an account (eg, My Checking or xxxx2125), but the user's account number is stored in the MFTS 18 and not in the mobile device. This aspect is believed to be a particular advantage of the architecture of a mobile financial transaction system constructed in accordance with the present invention. That is, storing more complete information on a secure server to provide and store a reduced subset of information within the mobile device extends the overall security for mobile transactions.

  Confirmation of telephone number ownership: According to yet another aspect, additional security is provided by confirming that a payment order originated from a particular mobile number associated with the user. This security measure is implemented in the disclosed embodiment by providing an encrypted mobile number associated with the mobile device as part of a mobile payment instruction (MPI) to the MFTS 18, preferably with other information of the MPI. Is done. The MFTS analyzes the mobile number and both the account for which the payment order has been identified as the payment source (PS) and the name of the payee already entered and stored in the payee table in the user database. Respond to the MPI to determine if it originated from the matching mobile number.

  According to yet another exemplary aspect of the present invention, during the registration process, an SMS containing a predetermined verification code is sent to the telephone number entered when setting up the mobile client. This code must be entered by the user when online at the user site web application 153 for the purpose of successfully initializing the mobile client for operation. This prevents an individual from recording a phone that he does not own with the intention of cheating.

  Winetime password used to initialize the mobile client: by prompting for an initialization code or password when the mobile client is first run to trigger the generation and installation of the client's digital certificate Still further security is provided. This initialization code is a one-time expiring one-time password that is presented to the user at the user site web application 153 during the initialization process for the mobile client. This process establishes a difficult-to-forge link between the user account and the instance of the mobile client on the user's mobile device.

  Mobile Client Initialization: The following steps describe the best mode currently contemplated for the process of user registration and mobile client installation in a system constructed in accordance with exemplary aspects of the invention.

  1. A user with an internet-accessible computer (eg, computer 140 in FIG. 2) navigates to the internet-accessible user site web application 153 in his browser and fills out the registration form displayed by the web application. . (Not shown.) The user provides the requested information by entering the information in the appropriate fields in the displayed data format. Alternatively, registration may be performed by a third party registration system (eg, an associated financial service provider) maintained by the MFTS system operator.

  2. When registration is complete, the user accesses the mobile client management section of the user site web application 153 to add a new mobile client. Alternatively, the addition of a new mobile client may be performed by a process provided by a third party (eg, an associated financial service provider or mobile communications service provider) with which the MFTS system operator maintains a relationship.

  3. The user then enters the phone number of the mobile device he wishes to install the mobile client and clicks the initialize button.

  4). Another step involves generating a verification code for activating the mobile client on the mobile device.

  (A) According to one exemplary aspect of the invention, the MFTS 18 sends an SMS to the identified telephone number. This SMS contains a verification code. The user is then prompted by the mobile application to enter a confirmation code for activating the mobile client to perform the transaction.

  (B) According to another aspect, the user browses the confirmation code in the SMS and enters the confirmation code in the browser confirmation screen in the user site web application 153. Perhaps a mobile phone with a verification code would be the user's direct property during registration. The user then clicks a “confirm” button to activate the mobile application.

  5. Another step involves generating initialization code (for new installation of mobile device software) and downloading the mobile application into the mobile device.

  (A) According to an exemplary aspect of the present invention, a user with Internet access to a user site web application is then presented with an initialization code for the mobile client. This initialization code is later entered into the mobile device when prompted (see below) to activate the mobile client.

  (B) According to another exemplary aspect of the invention, on the mobile device, the MFTS 18 sends a second SMS containing a clickable link to the mobile device to download the mobile client. The user then clicks on the link to download the application into the mobile device.

  6). After the mobile client has finished downloading into the device and has been activated by the user, the mobile client will present a screen that prompts for an initialization code. The user will then key in the initialization code into the mobile client.

  7). The initialization code is then communicated from the mobile device 15 to the MFTS 18 for use in connection with device and mobile client authentication. If a valid initialization code is received by the MFTS 18, a unique digital key is placed on the mobile client.

  8). Upon receiving a digital certificate from the MFTS 18, the mobile client then prompts the user to enter and confirm a PIN.

  9. After the PIN has been received and stored, the mobile device is ready for use and can enter billing entities and payment sources, as well as account balances pre-entered by the user, such as via the user site web application 153. Displays the main menu screen that allows browsing.

Security Aspects of MFTS Server System In accordance with exemplary aspects of the present invention, various security measures are implemented in MFTS 18 by various software routines suitable for the various entities communicated by MFTS. One or more of the following security measures are implemented in the preferred MFTS 18.

  Web application requires SSL: All externally accessible web applications running on MFTS 18 (eg, web application 154 including user site 153 and administration site 157) preferably allow only SSL protected connections. . If the user attempts to initiate a simple HTTP connection to one of the web applications, the connection will be redirected to an HTTPS connection.

  Password complexity requirements: Passwords for web application logins should preferably meet stringent complexity requirements. Password protection can be implemented at various stages of operation.

  Account lockout and password reset: Optionally, the account will preferably be locked out after several unsuccessful login attempts to the user site web application 153. The user whose account is locked out activates the account unlock function provided at the user site 153 to unlock the client and reset his password, and the user establishes during registration You will have to enter an accurate response to the password reset question you have entered. If the user cannot remember the correct response, the user will have to contact a customer service facility (website, representative, etc.) to unlock their account and reset the password.

  FSP interface security: The interface to the FSP is preferably protected using mechanisms appropriate to the nature of the interface and / or required by a particular FSP. Any interface that uses the public Internet for data transmission is preferably protected by encryption and authentication requirements acceptable by the Financial Services Industry Association. Details of the security requirements for communication with a particular FSP should be obtained from the FSP.

  From the foregoing description, to ensure security in a manner corresponding to the manner described above for communication with the MFTS 18, whether via the mobile device 15 or via the user site 153. In addition, it will be understood and appreciated that various mechanisms may be used singly or in combination. Other security measures and techniques can emerge to those skilled in the art without yet exceeding the scope of the present invention.

MFTS Interface Software Routine As described above with respect to FIGS. 3B and 5, the MFTS software 500 handles communications and functions associated with various entities involved in a system constructed in accordance with the disclosed aspects of the present invention. For this purpose, various program modules including the main program 350 (FIG. 5) and various communication interfaces are provided. Other software or program modules include MFTS mobile device communication interface 150, web application interface 154, financial service provider communication interface 156, and bill presentation interface 155. Further software routines include a P2P service 375, an SMS generator 151, and a money account service 379.

  Reference is now made to FIG. 8 for a description of the MFTS mobile device communication interface software or routine 150 according to aspects of the present invention. The MFTS mobile device interface software 150 preferably runs as a continuous and independent process on the MFTS server computer that is asynchronous to the other processes and provides communication and message processing between the MFTS 18 and the user's mobile device. . By the use of the term “interface” we mean the associated hardware, such as a computer program or routine 150 and communication components or storage elements driven by the program. Interface 150 handles messaging between the various processes in MFTS 18 and the mobile device. For example, if a user generates a command for “bill view” or “bill payment” on a mobile device, the command is as described herein to cause the MFTS 18 to perform a function in accordance with the present invention. Received on the wireless network and processed by the MFTS mobile device communication interface 150.

  The first step taken, starting from step 805, is that the interface communicates with the mobile communication network, i.e. a specific, so that communication can be established between the MFTS 18 and the mobile device that subscribes to the specific network for the service. Establishing communication with a mobile communication service provider (MCSP). In essence, this is an initialization process that involves determining a suitable protocol for communication with a particular MCSP and establishing contact with the MCSP by exchanging messages in a manner corresponding to the communication protocol. . After establishing communication, the interface may receive an incoming message from the mobile device at step 810 or within the MFTS 18 if, for example, a billing entity or bill presentation system provides information about a new bill for a particular user. Test for receipt of an incoming message from another process.

  At step 815, the interface receives the incoming message is a task initiation message (eg, from a mobile device in the associated mobile network) or a message from another MFTS process (eg, a response message from FSP interface 156). To determine whether or not. If the incoming message is a task start message, the interface process proceeds to step 840 where a new processing task is created and added to the processing queue for interface 150. For example, a processing task arising from an incoming message on a mobile device can be a mobile payment instruction (MPI), or “bill view” instruction, or “balance transfer”, or various other functions of a mobile wallet. Typically, the processing task will generate a new transaction record that is stored in a transaction table in the user database 158. Thus, at step 842, a new transaction record is created (if appropriate for the incoming message) and stored in the transaction database.

  At step 845, the interface sets a timer (predetermined time) appropriate for the particular task and process and starts the timing loop. Control then proceeds to step 850 where the interface tests for expiration for a predetermined period of time. If the timer expires, an error condition has occurred (the task added to the queue has not been properly processed in a timely manner), and in step 855 an error message is generated and sent to the user's mobile device that triggered the task. It is done.

  If an appropriate response from a queued task is received within a predetermined period of time, control uses from step 850 any information that results from the transaction record created for the incoming message processing the queued task. Step 860 is updated. For example, if a task involves making a payment using a specific payment source for a specific payee, and the payment is accepted and processed in a timely manner by a selected financial service provider, the transaction record is paid Updated to display confirmation.

  After the transaction record has been updated (if applicable), control passes to step 870 and a corresponding message for the task start message is sent to the requesting user's mobile device or other task start process. For example, if a payment order is received from a mobile user and the payment order is processed formally and in a timely manner, a payment confirmation message is sent to the user's mobile device.

  Returning to step 815 in FIG. 8, if the MFTS mobile device communication interface 150 determines that the incoming message is from another MFTS process (eg, a response message or other non-task initiation message), the control Proceed to step 820 to be processed. For example, a message from another MFTS process is available in a message provided by a billing presentation system that a new invoice for payment has been received for a particular user, or in a particular account for a particular user It may be a message provided by a financial service provider with information about the correct balance. In accordance with aspects of the present invention, messages from various other processes and related entities may include information not required by the mobile device interface. That is, only a reduced set of information will be provided to the mobile device. Specifically, since all of the information from the FSP is not needed or desired for display on the mobile device, the financial service provider (FSP) 30 is more than required for display and processing on the mobile device. May provide more comprehensive (ie, “excessive”) information about the user's financial account. In this case, as shown in various exemplary mobile device displays shown elsewhere in this document, a reduced set of information suitable for display on the mobile device is prepared to be sent as a message to the mobile device. The In this case, at step 825, a subset of the information received and / or stored at the MFTS is prepared for transmission to the selected user's mobile device.

  Control transfers from step 825 to step 860 where any corresponding transaction record associated with the message (if any) is updated with information from the MFTS process message. Then, at step 870, an appropriate message for the mobile device corresponding to the information in the processed (step 810) message is prepared for transmission to the mobile device. Process 150 then loops back to process any other messages that may have arrived.

  After step 870, process 150 loops back to step 810 to process another incoming message. From the foregoing description, those skilled in the art will process messages from mobile devices or from other MFTS processes to communicate relevant information in the form of tasks for processing by other MFTS processes, and any corresponding Understand how the MFTS mobile device communication interface 150 is operable to update transaction records or user database records and / or communicate appropriate reply messages to the user's mobile device or other message distributor. And will be recognized.

  Reference is now made to FIG. 9 for a description of financial service provider (FSP) interface software or routine 156 in accordance with aspects of the present invention. The Financial Service Provider (FSP) interface 156 runs as a continuous and independent process on the MFTS server computer that is asynchronous to the other processes and provides communication and message processing between the MFTS 18 and the user's financial service provider. It is preferable.

  FIG. 9 illustrates exemplary steps of an interface for communication between the MFTS 18 and one or more FSPs 30, including a bill presentation interface 155, a monetary account service 379 (for third-party user authentication), P2P It should be understood that a similar method is used for service 375. All receive messages from another MFTS process or messages from third parties connected for communication with the MFTS and process those messages by determining the appropriate destination (e.g. update user information) Store data in user database 158 to create or update transaction records, communicate to mobile devices, etc.) and transfer processed information to such destinations, similar continuous, independent asynchronous Computer-implemented process. Accordingly, it will be appreciated that the discussion of FIG. 9 is generally applicable to other communication interface processes, except where noted.

  The first step taken, starting at step 905, is that the interface 156 establishes communication with the financial service provider (FSP) 30 so that communication between the MFTS 18 and the FSP can be established. In essence, this is an initialization process that involves determining a suitable protocol for communication with a particular FSP and establishing contact with the FSP by exchanging messages in a manner corresponding to the communication protocol. After establishing communication, the interface, in step 910, receives an incoming message from the mobile device (via MFTS mobile device communication interface 150) or, for example, if the user initiates a transaction via web application interface 154, Test for receipt of incoming message from another process in MFTS 18.

  In step 915, the interface determines whether the incoming message is a task start message or a reply / response message from the ESP 30. A task start message is a message that causes the interface to initiate communication to a particular FSP 30 from another MFTS process, for example, from a mobile device (MFTS mobile device communication interface 150) or a payment instruction initiated by a web application. . If the incoming message is a task start message, such as from a mobile device, the interface process proceeds to step 940 where a new processing task is created and added to the processing queue for interface 156. For example, processing tasks arising from mobile device incoming messages can include mobile payment instructions (MPI), or “invoice payment” instructions, or “balance transfer”, or “payment source view”, or any other variety of mobile wallet Can be a function. For the FSP communication interface 156, a typical new processing task was selected to instruct the FSP to perform payment on behalf of the user using the account selected as the payment source (PS). It is in the form of an MFTS payment instruction (MFTSPI) communicated to the FSP 30.

  As described with respect to FIG. 8, and in accordance with exemplary aspects of the present invention, processing tasks resulting from an incoming message on a mobile device generate a new transaction record that is stored in a transaction table in user database 158. . It will be appreciated that the information from this transaction record is utilized in processing tasks relating to queues in interface 156, for example, in gathering information required for MFTSPI for the selected FSP 30. Furthermore, it will be appreciated that if necessary, the transaction record is updated with information from the FSP when a response is received.

  At step 945, the interface sets a timer (predetermined time) that is appropriate for the particular task and process and starts the timing loop. Control then proceeds to step 950 where the interface tests for expiration for a predetermined period of time. If the timer expires, an error condition has occurred (the task added to the queue has not been properly processed in a timely manner), and in step 955 an error message is generated and sent to the user's mobile device that triggered the task. It is done.

  If an appropriate response from the waiting task (eg, a response from the FSP, including information about the user's account balance, payment confirmation, or other information) is received within a predetermined time period, control is received from step 950. Proceed to step 960 where the transaction record created for the message is updated with any information resulting from processing the waiting task. For example, if a task involves making a payment using a specific payment source for a specific payee, and the payment is accepted and processed in a timely manner by a selected financial service provider, the transaction record is paid Updated to display confirmation. As discussed with respect to FIG. 8, the MFTS mobile device communication interface 150 may be responsible for updating the corresponding transaction record, but other environments require the FSP communication interface to update the transaction record. You will understand that there are cases. Other information related to the task and received from the FSP may also cause other records in the user database 158 to be updated as a result. For example, the addition of a user's new account at the selected FSP will require the addition of a record in the user monetary account table 620 (FIG. 6), or the closed account status of a particular FSP associated with the user. Will request a record update (or deletion) in the financial service provider table 630 (FIG. 6).

  After the transaction record or other user database table is updated at step 960 (if applicable), control passes to step 970 and a corresponding message about the response from the FSP is sent to the process that initiated the communication (eg, request To the user's mobile device). For example, if a payment order is received from a mobile user and the payment order is processed formally and in a timely manner by the selected FSP, a payment confirmation message is sent to the user's mobile device. According to an exemplary aspect of the invention, this type of message, such as a confirmation message, is in the form of a message passed to the MFTS mobile device communication interface 150.

  Returning to step 915 of FIG. 9, if the FSP communication interface determines that the incoming message is from the FSP (rather than the mobile device communication interface or other task-driven interface), then control is passed to the message. The process proceeds to step 920 where any response information from the FSP is received. After step 920, control passes to step 970 where information corresponding to the message from the FSP is transferred to the intended destination (eg, to the mobile device communication interface or to the web application interface that initiated the payment instruction).

  After step 970, process 156 loops back to step 910 to process another incoming message. From the foregoing description, those skilled in the art will process messages from various MFTS processes (such as from the MFTS mobile device communication interface 150) to communicate relevant information to the selected FSP, receive response messages, and optionally How the FSP communication interface 156 is operable to update the corresponding transaction record or user database record of the user and / or communicate an appropriate reply message to the user's mobile device or other message distributor Will be understood and recognized.

  Reference is now made to FIG. 10 for a description of web application interface software or routine 154 according to an aspect of the present invention. The web application interface 154 runs as a continuous process on the MFTS server computer that is asynchronous to the other processes and uses the MFTS 18 and a web browser on the computer 140 (FIG. 2) rather than the mobile device. Preferably, communication and message processing between users accessing the MFTS via the Internet 120 is provided. As will be appreciated by those skilled in the art, the web application interface allows the user to conduct transactions, view account history, add payees, add financial institutions and accounts, etc. In order to access the MFTS 18 via, it functions as a main program loop for displaying internet accessible web pages (such as the user site shown in FIG. 37). From FIG. 3B, according to exemplary aspects of the present invention, the web application interface 154 can be used to register new users, edit mobile clients, edit credit card or bank accounts, add new payees or payees. It will be recalled that it provides several key web-accessible features, including editing information about, initializing the mobile client, unlocking the mobile client, and other actions.

  The first step taken by the web application interface software 154, starting in FIG. 10 at step 1005, is to initialize the interface so that the interface is in communication with the user over the Internet. One skilled in the art will appreciate that such initialization operations involve initializing any associated hardware so that normal TCP / IP packets can be sent and received for Internet communications. Control then passes to step 1010 where the process loops waiting to receive TCP / IP packets (s) from the user or the prospective user's web browser navigating to the user site. In response to receipt of the packet (s), control passes to step 1015 where the packets are received and analyzed to determine their content.

  After step 1015, control passes to an inquiry step 1020 where an inquiry is made as to whether the user sending the packet has been authenticated and established a communication session. Otherwise, control passes to step 1025 where a login operation (ie, user authentication and session establishment) is performed in a manner that will be known to those skilled in the art. If the user cannot be authenticated, other processes (not shown) are performed to allow the new user to register or record, or the entity attempting to communicate with the MFTS refuses access (Ie, the packet (s) are ignored or aborted). In step 1020, if the user has been previously authenticated in a previous action and established session, or after login / authentication step 1025, control proceeds to display appropriate information corresponding to the current status of the session. Move to 1030.

  In step 1030, the web application interface 154 provides the user with a reply packet corresponding to the display of a web page suitable for the state of the current session with the user. For example, if the user is initially logged in for authentication, a normal user login screen (not shown) is provided for entering a username and password. As another example, if the user is in the process of managing information about their mobile device, a user site screen as shown in FIG. 37A is displayed. As another example, when a user is adding or editing information related to a mobile device, a user site screen as shown in FIG. 37B is displayed.

  After the display step 1030, control passes to a step 1040 of receiving and processing any packet (s) containing information entered by the user in response to the web page on which the interface was displayed. Thereafter, in step 1045, the interface stores any information received from the user and any (one or more) that will be required for delivery to other processes or interfaces in the MFTS 18. Generate a message. For example, the user input may require updates to some tables in the user database 158 or request the generation of a payment instruction or “view invoice” command requesting communication to the financial service provider 30. there is a possibility.

  Control then moves to step 1050 where the interface determines whether any messages have been received from any process or interface in the MFTS. For example, if the user's input requests the generation of a payment instruction or “bill view” command requesting communication to the FSP, a reply message or response message containing the finally requested information is returned to the web application interface. become. If such a message is received, control passes to step 1055 where the message is processed (processing may include updating the web page with any information in the received message). From step 1050 (if no message has been received from another process) or from step 1055 (after processing any message), control waits for further user web application interaction (ie, receipt of additional packets). Therefore, the process returns to step 1010.

  From the foregoing description, those skilled in the art will understand and appreciate how the web application interface 154 can operate to handle web interactions from users over the Internet or from other MFTS processes.

  As recalled from the discussion above, the web application interface 154 can be used to register new users, edit mobile clients, edit credit card accounts or bank cards, add new payees or edit information about payees, Provides several web accessible features such as mobile client initialization, mobile client unlock, and other operations. One of these exemplary functions is new user registration. That is, the individual must be recorded or registered to use the service provided by the MFTS operator. According to aspects of the present invention, a new user can access the MFTS 18 via the Internet and provide information to the system for registration for services.

In this regard, reference is made to FIG. 11 for a discussion of web application 1100 for registering new users to use MFTS 18 in accordance with exemplary aspects of the present invention.
The process of FIG. 11 utilizes the web interface 154 for user interaction over the Internet, but the steps of FIG. 11 are specific to the process of registering a new user in that the new user's web. Application 1100 is an exemplary process complementary to the general web application user interface 154 of FIG. Specifically, the new user will not pass the authentication step of FIG. 10, and the new user typically includes controls that allow the user to enter personal information and configure an account. "A web page will be presented.

  Beginning at step 1105 in FIG. 11, the MFTS generates a “Register New User” web page (not shown) that includes information required by the new user and registers the new user with the MFTS. Provides control and data entry fields for the input of information required by. At step 1110, the new user enters information (eg, name, address, phone number, email address, and other information) prompted on the “Register New User” web page. Registering a user may be selected as a billing entity (ie, payee), some information about the financial institution or financial service provider (FSP) 30 in which the new user maintains relationships and accounts, and a payment source. Information about specific accounts maintained at such financial institutions or FSPs must also be entered. At step 1115, the system tests a user command to edit information about the billing entity or payment source. If the command is related to a billing entity, control is in effect for the system to enter a new billing entity or (for example, one or more billing entities already have this registration of new users at this point in processing. If entered, branch to step 1120 to test a command to edit information about an existing billing entity.

  If, at step 1120, a command has been received to enter information about the new billing entity, control passes to step 1125 for receiving and storing information about the new billing entity or payee. Note that information about the billing entity is stored in a payee table in the user database 158 (see FIG. 6). If a command to enter information about a new billing entity is not received, control passes to step 1130 for testing a command to edit an existing billing entity. If, at step 1130, a command to edit information about an existing billing entity has been received, control passes to step 1135 for receiving and storing the edited information about the existing billing entity or payee. Move. When the entry or editing of any billing entity is complete, control passes to step 1160 and loops back to step 1115 or tests for user logout.

  Returning to step 1115, the system tests for a user command to edit information about the billing entity or payment source. If the command is related to a payment source, such as a financial institution or financial service partner, control can be used by the system to enter a new payment source or (for example, one or more payment sources can be A branch is made to step 1140 where a command to edit information about an existing payment source (if already entered for this registration) is tested.

  If, at step 1140, a command has been received to enter information about the new payment source, control passes to step 1145 for receiving and storing information about the new payment source. It will be appreciated that information about the payment source is stored in a user monetary account table and / or financial service provider table in the user database 158 (see FIG. 6). If no command is received to enter information about the new payment source, control passes to step 1150 where the command to edit the existing payment source is tested. If, at step 1150, a command has been received to edit information about an existing payment source, control passes to step 1155 for receiving and saving the edited information about the existing payment source. When input or editing of any payment source is complete, control passes to step 1160 and loops back to step 1115 or tests for user logout.

  Next, FIG. 12 for a discussion of a recorded user web application 1200 that allows a recorded or registered user to access and use the MFTS 18 in accordance with exemplary aspects of the present invention. refer. The recorded user web application 1200 is complementary to the general web application user interface 154 of FIG. 10 in that the process of FIG. 12 utilizes the interface 154 for user interaction over the Internet. Process. However, the steps of FIG. 12 are specific to the process by which the recorded user uses the Internet to add or edit information about the billing entity or payee and / or information about the payment source. Specifically, the recorded user will be logged in and authenticated in the authentication step in FIG. 10, and typically allows the user to enter and edit information about the billing entity and the payment source. It will be appreciated that a recorded user web page containing will be presented. Thus, in step 1205, the recorded user first logs into the web application and provides his login information and password information, and the recorded user has a billing entity and payment source associated with the recorded user. A “recorded user” web page containing specific information is presented.

  From a review of FIGS. 11 and 12, it will be appreciated that the overall structure of processes 1100 and 1200 are similar. Accordingly, those skilled in the art will understand and appreciate that the remaining steps in FIG. 12 are similar to the steps in FIG. 11 and need not be discussed further herein.

Mobile Device Operation FIG. 13 and the subsequent figures illustrate exemplary display screens generated on the mobile device 15 by the mobile client application for viewing payment sources and account balances in accordance with exemplary aspects of the invention. Concerning the following discussion. Prior to presenting an exemplary sequence of screen views of mobile device 15, in the following drawings, the payer's view is represented by a rectangular screen view with four rounded corners, while the payee's view is four Note that it is represented by a rectangular screen view with right angles. Payee views are provided for several payment sequences and methods in aspects of the invention. For example, some types of “Pay Anyone” payments can send a message to a mobile phone user (a second user, ie, a user other than the user making the payment), display a text message, (If selected) with downloading the mobile application to the second user's mobile device. Such payee view has a right angle in the drawing.

It will be appreciated that different mobile devices typically have different screen appearances, different screen sizes, different screen layouts and fonts, and the like. However, the main message regarding the display is presented in the following drawings. Message text, fonts, and text display lines may vary depending on the mobile device. Alternative embodiments will be apparent to those skilled in the art.
Viewing, selecting a payment source, and viewing the account balance of each available account are the basic functionality of the MFTS mobile application.

  From the following description, various aspects of the present invention contemplate various methods for selecting payees (eg, selecting payees by name, selecting by mobile phone number, etc.). In various aspects of the invention, various methods are contemplated for communicating payment facts to a payer (eg, by text message, by displaying a message on a payee / user's mobile device, etc.) In various aspects of the invention, various methods of achieving payment (eg, check, ACH transfer, value storage card, etc.) are contemplated, and in various aspects of the invention, an applicable payment method is selected (eg, It will also be appreciated that various methods are contemplated for the payer to choose (payee chooses). Accordingly, as those skilled in the art will be described with respect to various exemplary mobile device user screen views relating to various embodiments and aspects of the present invention, the various aspects described above may identify and select payees and payment methods. It will be appreciated and appreciated that can be combined in a variety of ways to provide flexibility and options in the selection.

Mobile Device Operation: Viewing Payment Sources and Account Balances Referring now to FIG. 13, a series of user screen views 1300 of a mobile device when a user views a payment source (PS) in accordance with an exemplary aspect of the invention. Is presented. Typically, the user is presented with a selection screen (eg, screen 1302) on his mobile device that allows the application to be selected for execution on the mobile device. As shown in screen view 1302, “Mobile Wallet” is one of the application options. The user can use a stylus, multifunction button, track wheel, or other navigation input device or navigation input control to highlight the selection, or use the numeric keypad to make a selection by numeric input. It is also possible to use it. For example, the user can use the arrow keys on the mobile device to navigate and highlight the “mobile wallet” and press the “select” key to proceed to the “mobile wallet” application. Alternatively, the user can press the number “1” to go directly to the “Mobile Wallet” application.

  Understand that similar input and selection mechanisms are used to select applications for the selection of data items on various mobile device display screens within the several views discussed I want to be. These details are not repeated to avoid unnecessary repetition.

  In response to the selection of the mobile wallet application in screen 1302, a login screen 1304 is displayed. On this screen, the user is prompted to enter a predetermined number of digits, such as a PIN or passcode, to enter “Mobile Wallet” as a security measure. In an alternative embodiment, the login screen 1304 or equivalent functionality can be applied to the invoice when the user activates the mobile device, selects an application, selects “Mobile Wallet”, views an invoice, Can be placed elsewhere on the screen in other situations, such as when paying, or can be placed in other suitable locations and / or environments. In the description of other drawings for other payment scenarios, application selection screen 1302 and login screen 1304 will be omitted, but it will be understood that such functionality can be provided if desired.

  In response to a valid login or PIN entry, a screen 1306 is displayed on the mobile device. This screen 1306 preferably comprises a menu of available options for the mobile wallet application according to an exemplary aspect of the present invention. In this embodiment, the available applications are (1) payer view, (2) invoice view, (3) invoice payment, (4) “Pay Anyone”, (5) balance transfer, and (6) PIN. Including changes. Other functions may also be provided here for various embodiments or implementations.

New screen that displays one or more recorded payment sources available to the user when the user highlights the “View Payment Source” option and presses the “Select” button or enters “1” A view 1308 is shown. If the screen is not large enough to display all payment sources, a scroll bar (not shown) may be included on the screen. The user activates the navigation tool to highlight the payment source and presses “Select” to select a specific payment source. Selection of a particular payment source results in a display 1310 of information about the selected payment source (eg, the balance (s) of the user's various accounts). For example, screen 1310 shows the current balance for the user, available credit, and available prepaid cash amount along with a financial service provider logo to facilitate brand recognition.
The display of a financial institution logo is optional. Some model mobile devices may not have graphics capabilities and can only display the payer's name, not the logo.

  Screen 1310 also shows exemplary “back” and “forward” keys or buttons on the screen view that may be used to navigate through available payment sources. If the “forward” key is pressed, other payer views (eg, screens 1312, 1314, and 1316) are displayed in order until the “select” key is pressed. In this example, as shown in the screen view 1312, Discover Card is displayed as a selectable payment source. Other selectable payment sources “Georgia Savings & Loans” and “Bank of USA” are displayed in screen views 1314 and 1316, respectively. Account balances and other relevant information about these payment sources are also displayed using these screen views.

  According to an exemplary aspect of the invention, the balance available to the user is between MFTS 18 and mobile device 15 so that the real-time account balance is displayed to the user (if the mobile device is within wireless service range). The last known balance retrieved from the MFTS 18 and stored in the memory of the mobile device during the communication session can be displayed. As the user views payment sources and their account balances on the various payment source screens 1300, it will be appreciated that the mobile device 15 is in communication with the MFTS 18 and has received real-time balance information from the corresponding financial institution. According to another exemplary aspect of the present invention, if a wireless signal is not available to the mobile device or if the MFTS 18 is unable to communicate with a particular financial service provider / payment source 30, the last (recent ) Since the balance information is cached in the local memory of the mobile device, such information is extracted from the mobile device 15. If the mobile client retrieves the balance from offline storage, the date / time of the last successful request to the server will be displayed.

  Referring again to FIG. 13, according to an exemplary aspect of the present invention, the mobile client application may use one specific payment as the default payment method for automatic and default use by the user unless canceled. The source is configured to be automatically selected. Screen 1318 reflects the selection of a specific payment source (eg, Bank of USA) as the default payment source. Accordingly, when the “select” key is pressed as shown in the screen view 1316, the user selects a specific payment source displayed on the screen as the default payment method. On screen 1316, the selected default payment source is “Bank of USA”. Screen 1318 preferably provides a prompt message “Do you want to use as default payment source?” For confirmation by the user. Other payment sources, such as different credit cards, are also available for selection as default payment sources. Preferably, the selected default payment source will remain until it is changed by the user when executing a subsequent payment source viewing screen 1308. According to a variation of this aspect, the system also includes code for the mobile application and / or user site that allows the user to change the default payment method on the fly.

  According to aspects of the present invention, selection and activation of a user's payer view command on the mobile wallet application generates a mobile payment instruction for the MFTS, which is updated in real time available to the user from the payer. Providing such updated account balance (s) to the user's mobile device in response to requesting account balance information. Such updated account balance information may include bank accounts, credit cards, credit unions, or any other monetary account that can be accessed by the systems described herein and using the methods described herein. It will be understood that all types of payment sources are included.

  FIG. 14 is a sequence diagram illustrating a method 1400 for viewing payment sources and account balances in accordance with one exemplary aspect of the present invention. In FIG. 14 and other sequence diagrams, ellipse objects through the top of the figure represent entities that communicate electronically via exchanges of signals, messages, data packets, TCP / IP, etc., and downward from the communicating entity. A rectangular box extending vertically represents the steps taken by that entity, a line with an arrow extending between the rectangular boxes represents communication directed from one entity to another, and time is from the top of the drawing. You will understand that it goes down. This convention is utilized in all sequence diagrams illustrating embodiments and aspects of the present invention, unless otherwise stated.

  Several entities are illustrated in FIG. That is, various financial institutions (FI) with which the user 12 (not shown) has a business relationship, such as the user's mobile device 15, the MFTS server 18, and (FI-1) 30A and (FI-N) 30N. Usually, communication between the mobile device 15 and the MFS 18 is provided by a wireless carrier network and is not individually shown in the drawings. Although not individually shown in the drawings, communication between the MFTS 18 and the payee, or payee's financial institution, or any third party service provider is typically a telecommunications network, internet service provider, dedicated communication Provided by the road, or any other available secure communication network.

  Beginning at step 1402 in FIG. 14, the user starts a “mobile wallet” application on the mobile device 15. As displayed at step 1404, the user is preferably required to log in by providing a password or PIN for confirmation. The password or PIN is entered by the user, locally validated, signed, and the encrypted message is sent to the MFTS via an authentication message (AM) 1406 for authentication. In step 1408, the MFTS 18 validates the login, eg, a communication or authentication confirmation message (ACM) 1410 that includes a signal code or validation code that allows the mobile wallet application to execute on the mobile device 15. Is provided back to the mobile device 15 to allow the mobile wallet application to execute. If the user continuously enters an incorrect password or PIN a predetermined number of times, the user is preferably denied service and the mobile device is locked. In this case, the user is required to take steps (not shown) to access the user site 153 or contact a customer service representative to unlock the mobile device.

  If the password or PIN is entered correctly, the authentication confirmation message 1410 from the MFTS 18 notifies the mobile device 15 that the login is valid and “mobile wallet” is displayed on the mobile device 15 as shown in step 1412. "Start the application. At step 1414, the user is presented with a screen (eg, FIG. 13) that allows viewing and selection of payment sources and account balances.

  Again at step 1412, the user can make a selection for payment source viewing on screen 1306 (as shown in FIG. 13). According to one exemplary aspect of the present invention, MFTS 18 automatically retrieves account balances for various payment sources (and retrieves bills to be paid) when logging in at step 1412. According to another exemplary aspect of the present invention, the MFTS retrieves such information in response to a specific activation of the corresponding function (eg, payer view (screen 1306 in FIG. 13)) A message is sent to the MFTS to trigger the retrieval of payment source information and the selection of bill viewing (again, screen 1306), and a message to cause payment execution to be retrieved.

  In the exemplary embodiment, mobile device 15 communicates a request to view payment sources and account balances to MFTS 18, and the corresponding MFTS sends request 1420A or 1420B to their corresponding financial institution 30A or 30B. To interact with available payment sources to retrieve the respective account information as shown in step 1418. According to some preferred embodiments of the invention, real-time information of all payment source accounts available to the user is collected and sent to the MFTS via messages 1426 and 1428 as shown in steps 1422 and 1424. Returned. Although only two financial institutions are shown in FIG. 14 for illustrative purposes, it is understood that the system is operable to communicate with some or all available and recorded financial institutions associated with the user. Like.

  In step 1430, MFTS 18 collects and accumulates account balance information from various financial institutions associated with the user and sends one or more messages 1432 containing this information to mobile device 15. According to some aspects of the invention, a collection of account balance information is accumulated and transmitted to the mobile device in the form of a single communication. According to another aspect, because the various systems of financial institutions are independent and operate asynchronously with respect to other systems, account balance information for a particular financial institution is mobile as soon as possible after being received. Is transmitted to the device.

  At step 1434, upon receipt of the account balance from the financial institution, all recorded account information is provided to the user for viewing. The user can then use the navigation controls to view the selected payment source and account balance. The user can also perform other functions, such as selecting a default payment method, as described with respect to FIG.

  According to an exemplary aspect of the present invention, the login is validated by the MFTS system 18 after the user enters a valid password or PIN. At this point, the MFTS can begin collecting information for the user prior to selecting any mobile wallet operation. In one embodiment, the MFTS system 18 sends balance requests to some or all of those billing entities to retrieve from the user's billing entities to detailed balance information. In another embodiment, the MFTS system 18 sends a payment source information request to some or all of the user's financial service providers to retrieve everything from those entities to detailed (real-time) balance information. These operations are completed even before the user begins performing any mobile wallet selection. Information retrieved from the billing entity and financial service provider is stored (cached) in a temporary database or memory within the user's mobile device and / or cached in the MFTS system. The user can perform several selections of mobile wallet operations after he logs into the mobile wallet. If the user performs any selection of mobile wallet operations, such as invoice viewing, payment source viewing, the user will immediately receive updated information from a temporary database or cache in the MFTS system. Thus, the MFTS provides the user with a quick response with information received prior to the user's selection of mobile wallet operation. It will be appreciated that the advantages of this approach are a quick response on the user's mobile device and a virtually “real-time” update of the account balance information.

Browsing Bills FIG. 15 is a series of user screen views 1500 of a mobile device when browsing bills that a user should pay according to an aspect of the present invention. According to such an aspect, the user has at least two ways to view his bill. The first method 1500a begins with user activation of a “mobile wallet” application, and the second method 1500b begins with receipt of an SMS text message from the MFTS 18.

  The first method 1500a begins at screen 1502. When the user uses the “Mobile Wallet” application to view the bill, the user selects the “Mobile Wallet” option from the mobile device screen view 1502 and the user is presented with a login screen view 1504. After the user has logged in and provided a valid password (or otherwise authenticated to the mobile device 15), the user can see, for example, payer view, billing, as shown on screen 1506 Several options are presented, such as bill viewing, bill payment, "Pay Anyone", balance transfer, PIN change. In accordance with this exemplary aspect of the invention, the user selects the “View Bill” option or presses the numeric key “2”. In response to selection of the bill viewing option by either method, the user is presented with a bill viewing screen 1512.

According to another aspect, the second method 1500b involves receiving an SMS text message instead of responding to user activation of the mobile wallet application.
Screen 1522 shows an exemplary text message display screen that includes a number of text messages received by the user (eg, electricity bills to pay, buy milk & juice, gas fees to pay, phone charges to pay, etc.). In this example, some of the SMS messages in the user's text message display screen relate to bill payments, but not all messages are related to bill payments. As is known, a user can receive several different text messages for several different subjects. In accordance with some aspects of the present invention, receipt of an SMS message regarding payment for an invoice can prompt the user to activate a mobile wallet application or an SMS message regarding an invoice to be paid. Reading can activate the mobile wallet application, or receiving an SMS message containing a predetermined code can automatically activate the mobile wallet application under certain predetermined circumstances .

  In accordance with one exemplary aspect of the present invention, a bill aggregator (eg, an operator of the bill presentation system 190 as shown in FIG. 2) receives a number of bills to be paid on behalf of the user, Can activate the mobile wallet application to receive notification that a new invoice has been received and to obtain more information about that invoice or to pay for that invoice As such, information about those bills is presented to the user via a text message. In accordance with this exemplary aspect of the invention, when a new bill is received from the bill presentation system at the MFTS server, the user is notified by a short text message. This short message is preferably short and only informs the user that a new bill has arrived. In one embodiment, the message is limited to the name of the billing entity (eg, power company, gas company, etc.), total payment amount, and due date. Other information may be provided in the SMS message if desired, but according to this exemplary aspect of the invention, the user is notified quickly and efficiently only about the most important information. As possible, the information is limited to the information described above.

  In the example of FIG. 15, it is assumed that the user has selected the message “Electricity to be paid” as shown on the screen 1524. In accordance with this exemplary aspect of the present invention, when a “read” key is pressed, a text message about the bill to pay (eg, “XXX bill to pay”) is sent to the mobile application as to the bill to pay. To automatically detect and start the mobile wallet application on the mobile device. In response to the start of the mobile wallet application, the user is presented with a login screen 1526 to allow the user to enter a password or PIN. After the user logs in and provides a valid password (or otherwise authenticated against the mobile device 15), the user is presented with a bill view screen 1512.

  Either of the methods 1500a and 1500b results in a bill viewing screen 1512. It will be appreciated that due to the limited size of the mobile device screen, the content of the “bill view” screen is not as detailed as the paper bill that users regularly receive. However, according to exemplary aspects of the invention, in some embodiments of the invention, some or all of the following information is displayed. (1) the name of the billing entity, (2) the date the bill was received, (3) the payment amount, and (4) the due date. Depending on the size of the mobile device screen, other relevant information may also be displayed, such as minimum payments, accounts payable, billing cycle, last payment amount and date. An optional scroll bar can be added for a larger display.

  Display screens 1512, 1514, 1516 are a series for displaying bills that can be paid in accordance with exemplary aspects of the present invention that a user sees when using navigation controls (eg, forward buttons). Illustrate different bills. As shown in the mobile device screen view 1512, when the user presses the “forward” key, the next bill is shown in the next mobile device screen view 1514. The user may use the “back” and “forward” keys to view each individual invoice until the “select payment” key is pressed as shown in the mobile device screen view 1516. Is possible.

  FIG. 16 is a sequence diagram illustrating a method 1600 for viewing a bill according to an exemplary aspect of the invention. The method or process 1600 involves communication or messages between the mobile device 15, the MFTS 18, and at least one billing entity. According to the best mode presently contemplated, the bill presentation system 190 receives invoices from several different billing entities on behalf of the user, and sends information about the multiple bills from multiple billing entities to the MFTS 18. provide. Accordingly, FIG. 16 illustrates this mode or embodiment, but the MFTS 18 does not require that all invoices or payment executions be provided by the bill presentation system 19, individually and independently. It will be understood and appreciated that it is possible to communicate with.

In one preferred embodiment, as shown in step 1612, the user views the bill by initiating a mobile wallet option for his mobile device.
In accordance with an alternative exemplary aspect of the present invention, the billing entity provides information to the bill presentation system 190 as shown in step 1602. As shown at step 1604, the bill presentation system 190 communicates a message 1606 to the MFTS 18. At step 1608, the MFTS 18 sends a short text message (SMS) containing the selected omission information to the user via the SMS generator 151 (FIG. 2) and the wireless network service provider 110. As previously discussed, the user initiates a mobile wallet or reads a text message at his convenience, as shown in step 1612. At step 1614, the user is prompted to log in and the password or PIN is validated. In response to validation by the user's mobile application via password login or other authentication means, the mobile application sends an authentication message (AM) 1616 to the MFTS 18. In step 1618, the MFTS 18 validates the login from the authentication message 1616 and communicates back to the mobile device 15 an authentication confirmation message (ACM) 1620 that allows the mobile wallet application to execute. At step 1622, the mobile device initiates the mobile wallet application and allows the user to view more detailed information regarding the bill or payment execution to be paid. At step 1624, the user selects the “View Bill” option (as shown and described with respect to FIG. 15). At step 1626, the user selects one bill for viewing. In response to selecting a bill for viewing, the mobile device 15 communicates to the MFTS 18 a request message 1628 for requesting information regarding the selected bill.

  At step 1630, the MFTS 18 receives a request for information about the selected bill and generates a message 1632 to the bill presentation system 190. At step 1634, the bill presentation system retrieves information regarding the selected bill (or optionally regarding one or more bills associated with a particular user) to retrieve detailed billing information. Accordingly, all invoices associated with the user via message 1636 are preferably transferred to the MFTS. In step 1638, the MFTS 18 receives detailed billing information from the bill presentation system 190 and stores the detailed billing information in the MFTS database in the detailed billing information table (FIG. 6). The MFTS 18 then creates a message 1639 containing the selected reduced information (ie, a subset of detailed billing information) suitable for the mobile device, and that message containing the subset of detailed billing information. Transfer to the user's mobile device 15. At step 1640, the user views his bill of payment via a screen as shown in FIG.

  FIG. 16 shows a series of steps for obtaining bill information from the bill presentation system, but it will be understood that the steps are similar to obtaining information independently from the billing entity. From the foregoing description, aspects of the present invention involve a method for obtaining reduced information selected for payment execution (invoices to be paid), which can be independently or from the bill presentation system 190. It will be appreciated that it is obtained from one or more billing entities.

Paying for Bills FIG. 17 is a series of user screen views 1700 of a mobile device relating to a user paying for their bill (s). As with other aspects of the specification described elsewhere, a user activates a mobile wallet application on his mobile device and is authenticated for use of the application on that particular mobile device ( That is, it is preferable to log in). Accordingly, screen 1702 shows several selectable applications such as mobile wallet, music download, game, etc., and screen 704 is a login screen that is generated when the mobile wallet application is initially run when selecting on screen 1702. Indicates. As shown on screens 1702 and 1704, a mobile wallet screen 1706 is displayed after the user logs into the “mobile wallet” application. In accordance with exemplary aspects of the present invention, the mobile wallet screen includes a number of selectable options that provide various functions for viewing, monitoring, and paying for mobile financial transactions.
For example, screen 1706 shows options related to payer view, bill view, bill payment, “Pay Anyone”, balance transfer, and PIN change. In accordance with the aspect of paying for an invoice, the invoice payment option is shown highlighted (selected), indicating that the user has selected to activate the invoice payment function of the mobile device. It is. The user can activate this function by selecting bill payment from a menu on screen 1706 or can press the “3” key on the keypad. In response, the mobile wallet application displays a bill payment display screen as shown at 1708.

  In accordance with exemplary aspects of the invention, bill payment screen 1708 provides a list of selectable incomplete bills. In one embodiment, the list may be configured such that the most recent invoice is at the top and the oldest invoice is at the bottom, as shown in screen view 1708. Other configurations may be implemented, such as the oldest invoice listed first. In accordance with one exemplary aspect of the present invention and as shown on screen 1708, if the “Bill Payment” function is selected, the oldest bill is automatically highlighted for the user to pay first. (For example, “phone fee to be paid 11/17/05 $ 34.45”). As in the other exemplary aspects of the invention, in this case, the user has navigated the list using up and down navigation controls and the appropriate invoice is highlighted. If so, select the bill that the user wants to pay by pressing the “Select” key.

  In response to the selection of a particular bill, information about the selected bill is displayed to the user, as shown on screen 1710. In accordance with exemplary aspects of the present invention, as shown in screen view 1710, information selected about the selected invoice (eg, the name of the billing entity, the date the invoice was received, the invoice Amount, optional, minimum payment, and due date). Although not shown on screen 1710, optionally, the total deficit for the account may be shown. The example screen 1710 also preferably includes a payment button, a back button, and a forward button as navigation controls that allow viewing of other bills in a sequential list of bills. As will be appreciated, a payment button or payment control is used to pay for an invoice that is currently on the display.

  According to an exemplary aspect of the present invention, the mobile wallet application provides a screen view 1712 that allows the user to select a payment amount when the “payment” key is pressed. In the preferred embodiment, the user is provided with the following options: That is, (1) pay the minimum amount to be paid, (2) pay the full amount to be paid, or (3) pay the amount specified by the user. The first two options are self-explanatory and result in proper payment based on the information on the record. The third option provides the user with the flexibility to specify the desired amount. If the third option is selected, the mobile wallet application provides a screen view (not shown) that allows entry of the desired payment amount. The example screen 1712 displays a payment button, a back button, and a forward button as navigation controls that allow viewing other bills in a sequential list of bills or proceeding with payment for a selected bill. It is also preferable to contain. As will be appreciated, the payment button or payment control is used to pay the currently selected amount.

Continuing with screen 1712, if the user determines the payment amount and the “Payment” key is pressed, a screen view 1714 showing the default payment source (in this case, Bank of USA) and its associated information is displayed. The example screen 1714 shows the default payer Bank
of USA has three selectable accounts (e.g., savings balance, check balance, and others (e.g., financial market account or possibly borrowing account)). According to an exemplary aspect, a specific default account is used to indicate to the user that the check account for that payment source is the default payment source that will be used unless canceled by the user by other means. (E.g., check balance) is highlighted.

  In accordance with exemplary aspects of the invention, screen 1714 further includes text prompting the user to confirm the currently displayed default payment source (eg, the text is “pay using default payment source”). Is written? " If the user presses a “select” key in screen view 1714 that displays a confirmation that the current invoice will be paid using the default payment source, the mobile wallet application confirms the payment and displays the payment source information. A screen view 1716 including information to be updated is generated. At this point, the user can press the “Done” button to complete the mobile payment transaction, or press “Forward” to perform other payments. In accordance with an exemplary aspect of the present invention, the current payment amount ($ 34.45 in the example shown) is deducted from the balance shown on the default payment source ("check balance"), resulting in the user Payment source information is updated immediately to reflect payment (ie, “check balance” is reduced by $ 34.45, as shown between screens 1714 and 1716. In the exemplary embodiment, This occurs even if the invoice amount is not actually deducted from the user's bank account.

  FIG. 18A is a sequence diagram illustrating a method 1800 for paying a bill in accordance with a preferred embodiment of the present invention. The method or process 1800 includes the mobile device 15, the MFTS 18, at least one billing entity (e.g., the bill presentation system 190 or a separate billing entity), and a selected finance functioning as a selected payment source (PS). With communications or messages between agencies 30. In this example, the user's default financial institution (FI) 30A is described as the selected payment source.

  In FIG. 18A, it is assumed that the user has previously viewed the payment source and account balance and selected a particular invoice to be paid. Thus, the initial step of process 1800 is step 1802 in which the user receives information about all bills to be paid and is in the state of selecting a particular bill to pay, eg, via screen 1708 in FIG. . If the user is ready to pay for the bill, at step 1804, the user selects a specific bill to pay. As shown in the exemplary screen views 1712 and 1714, the user selects a payment source and determines / enters a payment amount at step 1806. In response to entering the payment amount, a mobile payment instruction (MPI) message 1808 containing the desired amount and identifying the financial institution selected to perform the payment is communicated from the mobile device 15 to the MFTS 18. In step 1810, the MFTS 18 receives the MPI message and creates an MFTS payment order (MFTSPI) message 1812 for the selected financial institution 30A. The MFTSPI message 1812 displays a query message to the financial institution to confirm whether the selected payment source has sufficient funds to perform the payment, and / or payment if sufficient funds are available. Preferably, the instruction is for execution.

  Further, at step 1814, the MFTSPI message 1812 is communicated to the financial institution 30A and received at step 1814. If sufficient funds are not available to cover the payment, FI 30A generates a response message 1816 '(not shown) to notify MFTS 18 to notify that funds are not available, and MFTS 18 notifies the user Send a response message (not shown) that the requested payment has failed. Otherwise, the FI creates a funds available message (FAM) 1816 indicating that sufficient funds are available and sends this message to the MFTS. At step 1818, the MFTS 18 receives the funds available message and creates a corresponding funds available message 1820 for the mobile device 15 that allows the mobile wallet application to continue generating payment order messages. This funds available message is received at the mobile device at step 1822 where the mobile wallet application continues to process payments. Step 1822 includes actions such as requesting the user to confirm “Pay using default payment source?”, Generating a payment confirmation display for the user (eg, screen 1714 (FIG. 17)), etc. . The user can refuse payment using the default payment source and use the navigation control to select a different payment source, in which case a further and corresponding appropriate message from the mobile wallet application It will of course be understood that it is generated and returned to the MFTS 18.

  For example, in response to a payment source user confirmation via default payment source confirmation, the mobile wallet application generates a message 1824 that displays a payment confirmation and sends it to the MFTS 18. A payment confirmation message from mobile device 15 is received at MFTS 18 at step 1826. In step 1826, MFTS 18 receives the confirmed payment instruction from mobile device 15 and constructs a payment source payment instruction message 1828. In accordance with exemplary aspects of the present invention, as shown in FIG. If the bill presentation system 190 is utilized, at step 1830, the system 190 receives the payment source payment instruction 1828 and generates a corresponding payment instruction message 1832 for the financial institution 30A, eg, from the user's outstanding invoice queue. Process payments internally by clearing the invoices to be paid.

  At step 1834, financial institution 30A receives the payment source payment instruction from bill presentation system 190 and responds accordingly. As will be appreciated, the financial institution takes steps internally to withdraw funds or enter a debit on behalf of the user from the selected account to generate an appropriate payment instruction for the billing entity. The generation of appropriate and selected payment instructions (eg, checks, ACH funds transfers, value storage cards, etc.) is described elsewhere herein.

  At step 1834, a payment confirmation message 1836 is generated by the financial institution 30A and sent to the bill presentation system 190 when the appropriate steps for generating and sending the payment for the billing entity are completed. At step 1831, the bill presentation system 190 receives the payment confirmation message, settles the recorded bill, generates a mobile payment confirmation message 1837, and communicates this message 1837 to the MFTS 18, as shown at step 1838. The MFTS 18 receives the confirmation message 1837 and forwards another confirmation message 1840 to the mobile device 15. In step 1842, mobile device 15 receives mobile payment confirmation message 1840 and displays the confirmed payment information (eg, display screen 1716 in FIG. 17).

  Referring now to FIG. 18B, an alternative embodiment of the present invention is shown. Here, the steps / messages from steps / messages 1802 through 1826 and after 1838 are the same or similar to the steps / messages shown in FIG. 18A. At step 1826, the MFTS 18 receives the confirmed payment instruction from the mobile device 15 and constructs a payment source payment instruction message 1828 '. The payer payment instruction message 1828 ′ is communicated to the bill presentation system 190. When utilizing the bill presentation system 190, at step 1830 ', the system 190 receives the payment source payment instruction 1828' and generates a corresponding payment instruction message 1832 'for the financial institution 30A, eg, for the user's outstanding invoice. Process payments internally by clearing the invoices to be paid from the queue.

  At step 1834 ', financial institution 30A receives a payment source payment instruction from bill presentation system 190 and responds accordingly. At step 1834 ', a payment confirmation message 1836' is generated by the financial institution 30A and sent to the MFTS 18 when the appropriate steps for generating and sending the payment to the billing entity are completed.

  From the foregoing description, it will be appreciated that variations on the above process will occur to those skilled in the art.

Pay Anyone Payment Method FIGS. 19 and 20 illustrate exemplary display screens on the user / payer and second user / payee mobile devices 15, respectively, for the “Pay Anyone” payment process.
A “Pay Anyone” payment process is a payment method for paying a user's pre-recorded recurring billing entity or an entity other than a service provider. An example could be to make a payment at a point of sale with the payee's identity determined at the time of making the payment and to run a mobile wallet application (but in some cases still downloaded Make payments to individuals who own mobile devices (and are not operational), and individuals who do not own mobile devices, but require some form of payment, such as checks, electronic funds transfers, and value storage cards Or making payments to other entities. Various variations on the “Pay Anyone” payment method will appear when considering the following display screens and process steps.

  Accordingly, it will be appreciated that some options of the “Pay Anyone” payment method contemplate payments for entities recorded in the MFTS 18 and other options contemplate payments for entities not previously recorded. The “Pay Anyone” payment method allows the user to send payments to other recorded or unrecorded people as an alternative to cash. The method also transcends national borders anywhere, ie at the point of sale, locally, throughout the country, and (of course within the applicable currency rules) without physically handling cash or checks It is also contemplated to make payments. The method also contemplates receipt of payments by the recipient and the availability of relatively fast (effectively immediate) funds.

  Important issues in the “Pay Anyone” payment method include (1) identification of the payee, and (2) the method and / or form of performing the payment. According to one exemplary aspect of the invention, the user selects a payee from a list provided by the MFTS via a mobile device or enters a mobile phone number associated with the payee / Selecting gives you the option of selecting / entering the payee. Similarly, and in accordance with exemplary aspects of the present invention, there are several different ways in which a payee receives payment. For example, the user / payer can select a payment method from the following payment methods. That is, (1) “recipient definition”, (2) “bank bill” (or ACH electronic transfer), (3) “check”, and (4) “value storage card”. The “recipient definition” method allows the payee to select one of the three remaining methods: “bank note”, “check” and “preserve value card”.

  Note that payee selection and payment method selection are completely independent. The following description of the preferred embodiment of “Pay Anyone” shows that various payee choices and payment method choices are contemplated as exemplary aspects of the invention. For example, in FIGS. 19 and 26, the payee is selected by selecting a name from the list, while in FIGS. 23 and 29, the payee is selected by entering the payee's mobile phone number. Is done. In FIGS. 19-31, all four different payment methods are discussed. In light of the following teaching, any combination of payee selection and payment method selection is possible. The description of the exemplary embodiments of the invention is presented for purposes of illustration and description only and is not intended to be exhaustive or to limit the invention to the same form as disclosed.

  Pay Anyone with Recipient Defined Payment Method: FIG. 19 illustrates the use of the “Recipient Defined” payment method where the user selects a name from the list using the “Pay Anyone” option, according to an exemplary aspect of the invention. A series of payer mobile device screen views 1900 are shown. Screens 1902, 1904, 1906 are exemplary screens for displaying selectable applications, logins, and selections for the mobile wallet application described elsewhere herein, and are not repeated. However, it will be appreciated that one of the options that can be selected on screen 1906 is highlighted and thus the selected “Pay Anyone” option. In response to selecting the “Pay Anyone” option on screen 1906, in accordance with one exemplary aspect of the present invention, the screen is used to allow the user to select a payee by name or by mobile phone. A short menu shown in view 1908 is presented. Accordingly, the user can either select a payee name from the list or select / enter the payee's mobile phone number.

  In this example, assume that the user selects the “Pay by Name” option from the menu. In response to selecting this option, a screen with a pre-filled list of payees (eg, screen 1910 with names such as Jane Bennett, John Doe, Robert Johnson, Carol Jones, etc.) is displayed on the mobile device. Is done. As shown on screen 1910, the payee's name John Doe is highlighted and thus selected for operation. Information about names on the list in screen 1910 may be stored locally in the mobile device and / or MFTS 18 user database.

  Although not discussed with respect to FIG. 19, as discussed elsewhere herein, the user selects the “Pay by Mobile Phone” option on screen 1908 and enters a mobile phone number for a different form of payment. You will understand that this is possible.

  Like other mobile device screen displays described herein, the scroll bar navigation control on the right of the display screen displays that the name list is larger than the mobile device can display and scrolls down the list. Enable. Similarly, the user can activate the “Back” or “Forward” key or navigation controls to navigate the name list, and use the “Select” key to pay on the list. A person is selected.

  Continuing with the example, in response to the selection of a particular payee (eg, John Doe) on screen 1910, a screen 1912 is presented that allows the user to enter a payment amount. In the example, the user entered $ 123.45. The user then presses a “forward” button that results in a display screen 1914 requesting confirmation of the default payment source. At this point, the user can also use the “Back” key to make further changes or press the “Cancel” key to abandon the payment.

  In response to user input of payment amount, the mobile wallet application allows the user to select one account from several available accounts of the default payment source, as in previous examples A simple screen view 1914 is presented. As in the previous examples, the Bank of USA account is shown as the default payment source and the check account is shown selected / highlighted as the default account for use. After selection of a particular account, the user presses the “Select” key to continue the process for performing the payment.

  Responsive to the selection of the account in screen 1914, and in accordance with one exemplary aspect of the present invention, the user can select one of a plurality of different payment means or methods of payment to perform payment to the payee. A display screen 1916 that allows selection is presented. In this example, four options are provided. (2) ACH (e.g., bank note), (3) “check”, and (4) value storage card. The user can use the “select” key to select a specific payment method, ie, payment instrument, using the “back” and “forward” keys to navigate the menu. In this example, the “recipient definition” payment method is selected. That is, the recipient can select a method of receiving payment when information regarding payment is received by the payee. The payment instrument selection by the payee is described with respect to other figures (eg, FIG. 20). As seen in FIG. 20, the payee is given the option to select from ACH, check, or value storage card. Such steps and displays for the recipient / payee are discussed with respect to FIG.

  Continuing with FIG. 19, in response to a user selection of a payment method or payment instrument, the mobile wallet application generates a display screen 1918 that allows user confirmation of payment. According to one exemplary aspect of the present invention, screen view 1918 displays payment confirmation and the remaining balance of the payment source used in this transaction. For example, the check balance of the default payment source is debited by the payment amount of $ 123.45 from the amount shown on the screen 1914. At this point, the user can also press the “Done” button to exit the “Pay Anyone” application, or press the “Forward” button to start another transaction.

  Reference is now made to FIG. 20 for discussion of the payee's view of the recipient-defined payment method. The display screen shown in FIG. 20 has a mobile device that allows a payee / payee to run a mobile wallet application, for operation using the systems and methods as described herein. It should be understood that it is assumed that this is a recorded user of MFTS 18. If the payee / recipient is not so configured and recorded, the payee / recipient will indicate that the payer wishes to make a payment and will be on the payee / recipient's mobile device. You can receive a text message (SMS) that provides instructions to the payee / recipient on how to download and run the mobile wallet application, or take other actions to receive payment . A discussion of such actions and features regarding unrecorded payees / recipients is provided elsewhere herein.

  In general, and according to one exemplary aspect of the present invention, on the payee side, an SMS text message is received by the payee from the MFTS SMS generator 151 (FIG. 2). If the payee has a mobile wallet application installed on his mobile device, the payee can start the application directly at the same time as reading the SMS text message to receive payment. . Accordingly, FIG. 20 illustrates one response in response to receiving a message / communication generated by a user / payee using the “Pay Anyone” option to select a name from the list and use the “Recipient Defined” payment method. FIG. 8 shows a continued user / payee mobile device screen view 2000.

The display screen 2002 is illustrative of what the payee sees in response to receiving a message from the MFTS 18 (eg, an SMS message or a message specifically adapted for communication between the MFTS 18 and the mobile wallet application). Mobile device display. As shown in screen 2002, an indication that the individual with the identified mobile number (eg, 404-404-4040) is sending a payment of $ 123.45 to the payee / recipient. , Information is displayed to the payee that prompts the payee / recipient to select a payment receipt method from a list of several different payment receipt methods.
In accordance with exemplary aspects of the present invention, the message from the MFTS 18 is either a payee / recipient to (a) automatically start the mobile wallet application or (b) activate the mobile wallet application. Prompt. In either case, the payee is notified (by name or phone number) that someone has sent the payment and the amount paid. The payee is requested / prompted to select a payment method from a list of possible payment delivery methods (ACH, check, or stored value card). The payee then selects according to the instructions as shown in screen view 2002.

  ACH: According to one exemplary aspect of the present invention, in response to a payee's selection of the ACH method, the mobile device application provides a display screen 2010 for accomplishing this method. According to this aspect, the payee is shown a default ACH account with a default bank routing number and account number, as shown in screen view 2010. The screen preferably includes controls for confirmation, account change, and cancellation. Confirmation control effectively validates the displayed default payment receipt method. If the payee confirms the default payment receipt method, another screen view 2012 is displayed informing the payee that the ACH transfer has been completed. On the other hand, the payee has the ability to change to another ACH account by selecting an account change control that displays a separate display screen (not shown) for entering a new bank routing number and new account number. . In that case, when the mobile wallet application enters an alternate bank routing number and account number, another screen similar to the screen in 2010, followed by a screen view 2012 etc. after the transaction is completed and confirmed It is preferable to display the confirmation.

  Check: In response to a payee's selection of a check payment receipt method from screen 2002, according to one exemplary aspect of the present invention, the mobile device application provides a display screen 2020 to accomplish this method. To do. According to this aspect, screen view 2020 displays a default mailing address to which checks should be mailed. The example screen also includes selectable controls for confirmation, address change, and cancellation. The screen effectively prompts the payee to confirm the displayed default mailing address stored in the MFTS 18. If the payee confirms the default mailing address by pressing the “confirm” control, an exemplary screen view 2022 to notify the payee that a check will be mailed to the default mailing address. Is displayed. On the other hand, the payee can enter a different mailing address by entering a new mailing address by selecting an address change control that displays a separate display screen (not shown) for entering a different mailing address. Has the ability to change. In that case, when the mobile wallet application enters an alternate mailing address, the mobile wallet application prompts for another screen similar to the screen in 2020, followed by confirmation such as screen view 2022 after the transaction is completed and confirmed. It is preferable to display.

  Stored value card: In response to a payee's selection of a stored value card payment receipt method from screen 2002, according to one exemplary aspect of the present invention, the mobile wallet application displays to achieve this method. A screen 2030 is provided. According to this aspect, screen view 2030 displays a default value storage card account where funds will be deposited. The exemplary screen also includes selectable controls for confirmation, account change, and cancellation. The screen effectively prompts the payee to confirm the displayed stored value card account stored in the MFTS 18. Example to notify payee that if the payee verifies the default value storage card account by pressing the “confirm” control, the displayed amount will be deposited in the default value storage card account A simple screen view 2032 is displayed. On the other hand, the payee enters another value storage card by entering a new account by selecting an account change control that displays a separate display screen (not shown) for entering a different value storage card account number. Have the ability to change to an account. In that case, when the mobile wallet application enters an alternate stored value card account, another screen similar to the screen of 2030, and then after the transaction is completed and confirmed, such as screen view 2032 It is preferable to display a confirmation.

  According to one exemplary alternative aspect of the present invention, payers / recipients are not required to install a mobile wallet application on their mobile devices, particularly with respect to check options and value storage options. According to this aspect of the invention, text containing information to be displayed, for example, to verify a default mailing address or value storage account on a check, or to provide an alternative mailing address or value storage account One or more text messages (SMS) are generated by the MFTS 18 containing the information shown in FIG. 20 with instructions to the payee / recipient to return the message (SMS). Can be communicated to the mobile device owned by the recipient. Accordingly, aspects of the present invention provide for SMS messaging for payees with mobile devices that do not have a mobile wallet application installed or if the payee has not chosen to use and execute the mobile wallet application. It will be appreciated that it can be easily constructed using technology.

  FIG. 21 is a sequence diagram illustrating a method 2100 for a “Pay Anyone” payment method according to an exemplary aspect of the invention. The method or process 2100 involves communication or messages between the mobile device 15 and the MFTS 18 and allows the user to select a specific form of payment to perform payment for the identified individual during interaction with the system. To. This process is in contrast to previously described methods of performing payments for a pre-identified billing entity.

  Beginning at step 2102, the user activates the mobile wallet application and, at step 2104, logs in or otherwise provides authentication information. An authentication message (AM) 2106 is generated and communicated to the MFTS 18, which authenticates the user at step 2108. Upon authentication of the user by the MFTS in step 2108, an authentication confirmation message (ACM) 2110 is returned by the MFTS 18 to the mobile device 15 to allow the mobile wallet application to run on the mobile device, as shown in step 2112. . In accordance with one exemplary aspect of the present invention, at step 2112 MFTS 18 also retrieves a predetermined payee list associated with the user from the user database, and the payee list for the user is displayed in the payee list. Is sent back to the mobile device displayed to the user (see exemplary screen in FIG. 19).

  Assume that after the mobile wallet application is started in step 2112, the user selects the “Pay Anyone” option in step 2114. The user then selects a name from a predetermined payee list or enters a mobile phone number to select a payee, as shown in step 2116, and the amount paid in step 2118 Enter in cents. At step 2120, the user selects one of the available payment methods (eg, recipient definition, ACH, check, or stored value card as shown in FIG. 19). In this example, it is assumed that the user has chosen to pay using a recipient-defined payment method. Information corresponding to the selected payment method is provided in the Mobile Payment Instruction (MPI) message 2122 and forwarded to the MFTS 18 for further processing by the MFTS 18 and other related parties, as shown in step 2124. .

FIG. 22 is a sequence diagram illustrating a recipient-defined “Pay Anyone” method 2200 according to an exemplary aspect of the invention. The method or process 2200 includes user / payee mobile device 15 (not shown here), MFTS 18, payee mobile device 2202, user / payee financial institution 30A, payee financial institution 2260, With communication or message between payee 2270 and value storage card issuing company 2280. In this example, it is assumed in FIG. 21 that the user has selected a recipient-defined payment method at step 2120 and this decision has been communicated to the MFTS 18. According to one exemplary aspect of the present invention, the MFTS sends a text message (SMS) 2206, such as the text message shown in the screen view 2002 of FIG. 20, to the payee, as displayed in step 2204. .
This message 2206 informs the payee that an amount of payment has not been completed, as shown in step 2208, and that the payee should select from the list of selected payment methods. The payee then preferably uses his mobile device 2202 to select from the three payment methods provided in step 2210. Such a selection may be made by returning a reply text message or by using a mobile wallet application if installed on the payee's mobile device. In either case, a mobile payment instruction (MPI) message 2212 containing information about the selected payment method (eg, message 2212A for selecting an ACH payment method, message 2212B for selecting a check, or stored value card payment) A message 2206C) for selecting a method is returned to the MFTS 18.

  ACH payment method: If the payee selects an ACH payment method, as shown in step 2214, a payment method selection message 2212A containing the payee's ACH account information and payment amount is sent to the MFTS 18 via the wireless carrier network. Transferred. The corresponding request 2220A is then displayed at step 2222 as the user / payer's financial institution 30A (payment source) for payment to the payee's specified bank account from the account specified by the user. Sent to. If the user / payer financial institution 30A confirms that the user has sufficient funds to cover the payment, then the payer financial institution provides the ACH bill as shown in step 2226. Send to specified account of institution 2260.

  Check Payment Method: If the payee selects a check payment method, as shown in step 2216, a payment method selection message 2212B containing the payee's mailing address information and payment amount is sent over the wireless carrier network to the MFTS 18 Forwarded to The corresponding request 2220B is then displayed to the user / payer for generation of the check drawn in the user / payer's specified account and mailing the check to the payee, as displayed in step 2222. To financial institution 30A. If the user / payer financial institution 30A confirms that the user has sufficient funds to cover the payment, the payer financial institution receives the check 2224B whose receipt by the payee is displayed in step 2228. Mail to payer.

  Preserved value payment method: If the payee selects the stored value card payment method, as shown in step 2218, a payment method selection message 2212C including the payee's stored value card account information and payment amount is sent to the wireless carrier. It is transferred to the MFTS 18 via the network. A corresponding request 2220C is then entered to credit the payee's identified stored value card account that was debited in the user / payer's identified account, as displayed in step 2222. Sent to the user / payer financial institution 30A. If the user / payer financial institution 30A confirms that the user has sufficient funds to cover the payment, the payer financial institution steps its receipt by the payee at a specified amount (by 2224C). Fill in the credit of the identified stored value card account displayed at 2230. The step 2230 of displaying receipt of the loaded value storage card, for example, by providing information to the payee that indicates where the unloaded value storage card can be obtained and using the payment amount It also provides information such as a validation code that will allow the payee to present the unloaded card to the terminal or representative so that the card can be "loaded" Understand that it reflects both (a) crediting an existing stored value card account associated with the payee, or (b) issuing a newly loaded stored value card to the payee I want to be. Such details of loading a value storage card and delivery of the value storage card to an individual are known to those skilled in the art and do not form a separate part of the present invention.

  With respect to payment, these three methods are independent or allow the payee to have the flexibility to assign an ACH to a part of the payment and assign a check and / or value storage card to the rest of the payment. It will be understood that they can be used in combination.

Pay Anyone by Phone Number FIG. 23 shows a series of payer mobile device screen views 2300 for a “Pay Anyone by Phone Number” payment method according to an exemplary aspect of the invention. In this particular method, the payer / user selects / enters a mobile device phone number to identify the payee. Illustrated in detail is an “ACH” payment method according to an exemplary aspect of the present invention. It will be appreciated that the payer can alternatively select a check payment method or a stored value card payment method, and the particular payment method described is exemplary only.

  As with the embodiments and aspects described so far, the user first selects a mobile wallet application on screen 2302 and provides authentication information (eg, login) via screen 2304 and pays on screen 2306. Authenticated by the MFTS before the option to perform is presented. In screen 2306, assume that the user selects the “Pay Anyone” option. In response to this selection, the user is provided with an optional short menu as shown in screen view 2308 to select payees by name or by mobile phone number. In accordance with this exemplary aspect of the invention, in response to the selection of the option “Pay by Mobile Phone” by activating the input of the number “2” or the selection control, the user is given the payee / user's A screen 2310 for entering a mobile phone number is presented.

  In accordance with this exemplary aspect of the present invention, as shown in screen view 2310, an exemplary payee telephone number 404-555-2121 is entered. Screen 2310 operates as previously described to continue the process, to return to the previous screen, or to cancel a transaction, control to proceed, control to return, and control to cancel And further including. In response to the user activation of the forward control after entering the payee's telephone number, the user is presented with a payment amount data entry screen 2312 for entering the payment amount. The user then enters the payment amount. In this example, the user entered $ 123.45. As in the other exemplary screens, the money input screen 2312 includes forward control, return control, and cancellation control. In response to the user's activation of the forward control, the user is shown the default payer (eg, Bank of USA) and the balance available in the default payer's default account, and the selected default A screen 2314 that prompts the user to confirm is displayed. As in previous examples, the user can activate the “select” control to select a default account and default payment source, or navigate to an alternative payment source.

After selection and / or confirmation of the payment source via screen 2314, the user is presented with a screen 2316 that allows selection of a payment method. The user uses the “Select” control to select, using the “Back” and “Forward” keys to navigate the menu.
In this example, the “ACH” payment method is shown highlighted and is therefore selected. In response to the activation of selection control on screen 2316, the user has a screen 2318 that displays the payment confirmation, the selected payment method, and the remaining balance / updated balance of the payment source used in this transaction. Presented. At this point, the user can activate the “Done” control to exit the “Pay Anyone” application, or can activate the “Forward” control to initiate another transaction. is there.

  FIG. 24 is a diagram illustrating a payment via a payee's mobile device for a “Pay Anyone” option where a user selects / enters a mobile device phone number and uses the “ACH” payment method in accordance with an exemplary aspect of the present invention. A series of mobile device screen views 2400 from the payer's view are shown. As in other embodiments and aspects, the information shown is generated by a series of text messages (SMS) or by a mobile wallet application when loaded and activated on the payee's mobile device The displayed information can be presented to the payee.

  As shown in screen 2402, an SMS text message is received from SMS generator 151 or similar information is generated by a mobile wallet application running on the payee's mobile device. Following this message, the payee is notified that someone with the phone number 404-404-4040 has sent a payment for an amount of $ 123.45 for delivery by ACH funds transfer. In accordance with one exemplary aspect of the present invention, the message to the payee includes a default payment receipt method (eg, deposit with a given bank (identified by a bank routing number)) and an account. When generated by the mobile wallet application, the screen 2402 preferably includes a “confirm” control, an “account change” control, and a “cancel” control. By activating the “confirm” control, the payee / recipient can confirm that the displayed ACH bank routing number and account number stored in the MFTS database are accurate for payment. On the other hand, the payee has the ability to change to another ACH account by entering a new account number and a new bank routing number by activating the “change account” control. As in other examples, if the payee activates the “change account” control in the screen view 2402, the payee can enter another ACH bank routing number and another account number. A separate screen (not shown) is displayed.

  If the payee confirms the payment delivery method by activating the “confirm” screen on screen 2402, a screen view 2404 prompting the payee to confirm the deposit to the identified ACH account is provided. Indicated. Screen 2404 also preferably includes a “Complete” control, an “Account Change” control, and a “Cancel” control. The “change account” control functions as described elsewhere. Activating the “Done” control causes a screen 2406 to prompt the user to set the currently selected bank account as the default ACH account for the payee. If the payee activates the “yes” control on screen 2406, the default ACH account information is sent back to MFTS 18 for storage associated with other information about this particular payee. Otherwise, the default ACH account is not changed.

  When checking the bank account as the default ACH account by activating the “Yes” control or by activating the “No” control to leave the identified account intact, deposit payments for the currently selected account. A screen 2408 is displayed that prompts the payee / recipient to confirm. “Yes” and “No” controls are provided to confirm or deny deposits to an account. If the response is “yes”, the payee's response is sent to the MFTS 18 for further processing of the transaction. In response to processing a transaction by performing an ACH payment, according to one exemplary aspect of the present invention, the payee receives the payment received in the ACH account that the payee has previously identified. A confirmation message indicating confirmation that the deposit is to be made, that is, a confirmation display 2410 is received. At this point, the payee can activate the “complete” control to end receipt of payment, or “proceed” to process another transaction, if applicable. It is possible to activate control.

  FIG. 25 is an illustration of the present invention illustrating the interaction between payer / user mobile device 15, payee mobile device 2521, MFTS 18, third party payment provider 2560, and payee financial institution 2580. FIG. 6 is a sequence diagram of “Pay Anyone” using an ACH payment method or ACH payment process 2500 according to an exemplary aspect. As in previous aspects, the third party payment provider 2560 is in this case a payment instruction recipient that achieves payment to the payee by transferring funds to the payee's financial institution 2580.

  As in previous discussions described elsewhere, steps 2502 and 2504 authenticate the user / payer to MFTS 18 via message 2506 and authenticate by MFTS 18 in step 2508. , Sending the authentication confirmation message 2510 and the user's payee list to the user's mobile device 15. In response to the authentication, the user starts the mobile wallet application at 2502, enters a password or PIN at 2504, and the MFTS authenticates the login at step 2508, and displays the user's current payee list (2510). Send to the user's mobile wallet on the user's mobile device. This action allows the user to proceed with the use of the mobile wallet application at step 2512. The user then selects “Pay Anyone” in step 2514 and selects a payee name from the payee list received during login or telephone in step 2516 to identify the payee. Enter the number. The user then enters the payment amount using the mobile device at step 2518 and selects an ACH payment method at step 2520.

  In response to the foregoing steps, a mobile payment instruction (MPI) message 2522 is generated by the mobile wallet application and communicated to the MFTS 18. The MPI 2522 will typically include a payment amount, a payment method (in this case, ACH payment), and payee information including the payee's phone number. At step 2524, the MFTS 18 examines the payment order and generates a message 2526 to the payee's mobile device 2521 to request the payee to identify or confirm the ACH method for payment. This message 2526 is sent to the payee's mobile device and received at step 2528. In accordance with exemplary aspects of the present invention, the payee receives message 2526 via one or more text messages or by communication activating the appropriate routine of the mobile wallet application (not separately shown). It is possible. At step 2528, the payee selects an account in which funds should be deposited. A reply payment account selection message 2530 (eg, a reply text message from the mobile wallet on the payee's device or reply communication) is generated that displays the account that the payee wishes to deposit payment into. This reply payment account selection message 2530 is sent back to the MFTS 18 and received at step 2532.

  At step 2532, MFTS 18 receives payment account selection message 2530 and determines the identity of the third party payment provider (ie, payment instruction recipient) that generates the ACH payment transaction. An MFTS payment instruction (MFTSPI) 2534 is generated and communicated to the third party payment provider 2560. This MFTSPI 2534 is received at step 2536. In step 1562, the third party payment provider generates an ACH funds transfer (2538) and electronically communicates it to the payee's financial institution 2580 using the known ACH funds transfer method. Receipt of this ACH funds transfer at the payee's financial institution is shown in step 2540. A payment confirmation message (such that the data record associated with this payment can be updated and any suitable payment confirmation message can be provided to the payee's mobile device and / or the payer's mobile device ( (Not shown) is preferably generated by either the payee's financial institution 2580 or a third party payment provider 2560 and provided back to the MFTS 18.

Pay anyone by name
FIG. 26 illustrates a series of payer mobile device screen views 2600 for a “Pay Anyone by Name” payment method according to an exemplary aspect of the invention. In this particular method, the payer / user selects / enters a name to identify the payee. Illustrated in detail is a “check” payment method according to an exemplary aspect of the present invention. It will be appreciated that the payer can select an ACH payment method or a stored value card payment method (as described above), and that the specific payment method described is merely exemplary. .

  As in the previously described embodiments and aspects, the user first selects a mobile wallet application on screen 2602, provides authentication information (eg, login) via screen 2604, and performs payment on screen 2606. Authenticated by the MFTS before the option to do so is presented. In screen 2606, assume that the user selects the “Pay Anyone” option. In response to this selection, the user is provided with an optional short menu for selecting payees by name or by mobile phone number, as shown in screen view 2608. In accordance with this exemplary aspect of the invention, in response to the selection of the option “Pay by Name”, either by entering the number “1” or activating the selection control, the user can select a prior A screen 2610 comprising a list of payees entered in is presented.

  In accordance with this exemplary aspect of the present invention, exemplary payee name “John Doe” is highlighted on screen 2610 and thus selected. Screen 2610 further includes controls for selection, top and bottom that operate to select a particular name or to navigate a list of pre-filled names. After the name of the particular payee, in response to the user activation of the selection control, the user is presented with a payment amount data entry screen 2612 for entry of the payment amount. The user then enters the payment amount. In this example, the user entered $ 123.45. As in the other exemplary screens, the monetary input screen 2612 includes forward control, return control, and cancellation control. In response to the user's activation of the forward control, the user is shown the default payment source (eg, Bank of USA) and the balance available in the default payment source's default account and confirms the selected default A screen 2614 for prompting the user is presented. As in previous examples, the user can activate the “select” control to select a default account and default payment source, or navigate to an alternative payment source.

  Following payment source selection and / or confirmation via screen 2614, the user is presented with a screen 2616 that allows the selection of a payment method. The user uses the “Back” and “Forward” keys to navigate the menu and uses the “Select” control or numeric keys to select. In this example, the “check” payment method is shown highlighted and is therefore selected. Responsive to the activation of selection control on screen 2616, screen 2618 prompts the user to confirm payment and confirmation of the selected payment method (eg, "Do you want to send a check to the default address of Mr. John Doe?") Is presented. At this point, the user can select “Yes” control, “No” control, or “Cancel” control. In response to selecting the “yes” control on screen 2618, the user is asked to confirm the transaction and is presented with a screen 2620 that includes information about the transaction, including the payee's name and mailing address. Screen 2618 includes a “payment” control that operates to confirm payment or change the payee's address, a “change address” control, and a “forward” control.

  In response to the payment control selection, a screen 2622 is displayed that displays a confirmation of payment. Screen 2622 shows the payment of the displayed amount of $ 123.45 to John Doe by check with updated account balance information reflecting the deduction of the payment amount from the account balance as reflected in the MFTS 18 record. Confirmation information is displayed. At this point, the user can activate the “Done” control to exit the “Pay Anyone” application, or activate the “Forward” control to initiate another transaction.

  FIG. 27 illustrates a “pay anyone” payment method in which a user selects / enters a payee's name and uses a check payment method according to an exemplary aspect of the present invention, via the payee's mobile device. A series of mobile device screen views 2700 from the payer's perspective are shown. In other embodiments and aspects, the indicated information was generated by a series of text messages (SMS) or by a mobile wallet application when loaded and activated on the payee's mobile device. The indication can be presented to the payee.

  As shown in screen 2702, an SMS text message is received from SMS generator 151 or similar information is generated by a mobile wallet application running on the payee's mobile device. Following this message, the payee is notified that someone with the phone number 404-404-4040 has sent a payment for the amount of $ 123.45 by check mailed to the displayed address. According to one exemplary aspect of the invention, the message to the payee includes a default payment address for mailing the check. When generated by the mobile wallet application, the screen 2702 preferably includes a “confirm” control, an “address change” control, and a “cancel” control. By activating the “Verify” control, the payee / recipient can confirm that the displayed name and address stored in the MFTS database is accurate for the check mailing. On the other hand, the payee has the ability to change the mailing address by activating the “change address” control. As in other examples, a separate screen (not shown) that allows the payee to enter an alternate address if the payee activates the “Change Address” control in screen view 2702 Is displayed.

  If the payee confirms the payment delivery method by activating the “confirm” control on screen 2702, a screen view 2704 is displayed that prompts the payee to confirm the mailing address. Screen 2704 preferably also includes a “complete” control, an “address change” control, and a “cancel” control. The “change address” control functions as described elsewhere. Activating the “Done” control causes a screen 2706 to prompt the user to set the currently displayed address as the default mailing address for the payee. If the payee activates the “yes” control on screen 2706, the default address information is sent back to MFTS 18 for storage associated with other information about this particular payee. Otherwise, the default address is not changed.

  Confirm mailing of checks against currently displayed address when confirming mailing address by activation of "Yes" control on screen 2706 or by activation of "No" control to leave the identified address intact Thus, a screen 2708 for prompting the payee / recipient is displayed. “Yes” and “No” controls are provided to confirm or reject mailing to the displayed address. If the response is “yes”, the payee's response is sent to the MFTS 18 for further processing of the transaction. In response to processing the transaction in preparation for the check mailing, according to one exemplary aspect of the present invention, the payer indicates that the check payment will be mailed to an address pre-specified by the payee. A confirmation message to be displayed, that is, a confirmation display 2710 is received. At this point, the payee can activate the “done” control to end this function, or “apply” control process to process another transaction, if applicable. Can be activated.

  FIG. 28 illustrates, according to exemplary aspects of the present invention, illustrating the interaction between payee's mobile device 2801, MFTS 18, third party address provider 2840, third party payment provider 2860, and payee 2880. FIG. 11 is a sequence diagram of “Pay Anyone” according to a check payment method or check payment process 2800. In accordance with exemplary aspects of the present invention, the payee's mailing address is: (1) by retrieving default address information associated with the payee stored in the MFTS database; ), (3) entered by the payee, or (4) located via a third party address provider. If the address information is not available when the user requests check payment, the MFTS sends a request to the third party address provider to perform an address search.

  As with previous methods described elsewhere, the method 2800 includes steps for authenticating a user / payee to the MFTTS 18 (not shown) and steps for authenticating by the MFTS 18 (see FIG. And a step (not shown) for sending an authentication confirmation message and a user payee list to the user's mobile device 15. In response to the authentication, the user starts the mobile wallet application and enters a password or PIN, and the MFTS authenticates the login and places the user's current payee list in the user's mobile wallet on the user's mobile device. send. This action allows the user to proceed with the use of the mobile wallet application. The user then selects “Pay Anyone” and selects a payee name from the payee list received during login or enters the payee name. The user then enters a payment amount using the mobile device and selects a check payment method. Similar methods are described in detail elsewhere and need not be repeated here.

  In response to the foregoing steps, a mobile payment instruction (MPI) message (not shown) is generated by the user's mobile wallet application and communicated to the MFTS 18. The MPI usually includes a payment amount, a payment method (in this case, check payment), and payee information. The MPI is received at the MFTS 18 and processed to initiate the check payment method in accordance with this aspect of the invention.

  Beginning at step 2804, the MFTS 18 examines the payment order and generates a message 2806 to the third party address provider to obtain the payee's address. According to one exemplary aspect of the present invention, payee address information is stored in a table in user database 158 (FIG. 2) indexed by mobile phone number, name, or other information. Is done. Alternatively, message 2806 is communicated to an independent address provider 2840 that provides address information in response to providing the telephone number.

  At step 2810, the requested address information is provided from the third party address provider 2840 via message 2810. The message 2810 is formulated into a message 2814 that is received by the MFTS 18 at step 2812 and includes the payee's address information that is communicated to the payee's mobile device 2802. 27 is generated for the payee so that the display as shown on the screen 2702 in FIG. The payee can receive an SMS message with this information, or a mobile wallet application running on the payee's mobile device can provide this information to the payee. Will be understood.

  In step 2818, the payee confirms the presented address via the screen as shown in FIG. A confirmation message 2820 is generated and returned to the MFTS 18. At step 2822, the MFTS organizes an MFTS Payment Order (MFTSPI) message 2824 and communicates this message to the third party payment provider 2860. The third party payment provider receives this message at step 2826 and processes the MFTSPI message 2828 to generate a check that is mailed to the payer at the address displayed in the message. At step 2830, payee 2880 receives the check payment by mail.

Pay Anyone: Save Value Card FIG. 29 shows a series of payer mobile device screen views 2900 for a “Pay Anyone by Phone Number” payment method according to an exemplary aspect of the invention. In this particular method, the payer / user selects / enters the mobile device phone number to identify the payee, but it will be appreciated that other methods for identifying the payee are contemplated. Like. Illustrated in detail is a payment method involving the use of a stored value (SV) card according to an exemplary aspect of the present invention. It will be appreciated that the payer can alternatively select an ACH payment method or a check payment method, and the particular payment method described is merely an exemplary payment using a stored value card.

  Those skilled in the art will understand and appreciate that payment by value stored (SV) card does not form part of the present invention, but requires a customary and widely used payment transaction infrastructure. Specifically, a payment order is issued to a payment order recipient having facilities for issuing a new value storage card or adding an amount to an existing value storage card by a system constructed as described herein. Provided. Various entities related to the issuance of value storage cards, including financial service providers, ie billing aggregators, value storage card issuers, or retail stores that process value storage cards (individually or together with another entity that processes SV cards) It will be understood that can serve as the payment order recipient.

  In general, performing a payment for a stored value card typically involves the payee obtaining a “blank” or “unloaded” magnetic strip or electronic smart card from the SV card vendor, and thereafter "Load" the card with the amount by presenting the card to an SV card vendor with a terminal capable of reading information from a magnetic strip on the card or other electronic data storage medium (ie, withdrawn) With payment credit). The vendor then provides the back office system with information indicating the credit amount or payment available for use on the card and loads the card by returning the card to the cardholder. The cardholder must be presented to an entity that can read the card and determine the available funds that are “loaded” onto the card by accessing the card vendor's electronic payment system. Then, it is possible to use the card in the same manner as other payment cards (debit card, credit card). According to one exemplary aspect of the present invention, funds are loaded from a mobile device onto a regular value storage card (issued to a payee) as shown and described herein. New value storage card, or existing value storage card can be loaded or reloaded).

  As in the previously described embodiments and aspects, the user first selects a mobile wallet application on screen 2902, provides authentication information (eg, login) via screen 2904, and performs payment on screen 2906. It is authenticated by the MFTS before the options are presented. In screen 2906, assume that the user selects the “Pay Anyone” option. In response to this selection, the user is presented with an optional short menu as shown in screen view 2908 to select a payee by name or by mobile phone number. In accordance with this exemplary aspect of the present invention, the user is charged in response to the selection of the option “Pay by Mobile Phone” by either entering the number “2” or activating the selection control. A screen 2910 for entry of the payer / recipient mobile phone number is presented.

  In accordance with this exemplary aspect of the present invention, as shown in screen view 2910, an exemplary payee telephone number 404-555-2121 is entered. Screen 2910 operates as previously described to continue the process, to return to the previous screen, or to cancel the transaction, control to proceed, control to return, and control to cancel And further including. In response to the user's activation of control that proceeds after the payee's telephone number is entered, the user is presented with a payment amount data entry screen 2912 for entry of the payment amount. The user then enters the payment amount. In this example, the user entered $ 123.45. As in the other exemplary screens, the monetary input screen 2912 includes a forward control, a return control, and a cancel control. In response to the user's activation of the forward control, the user is shown the default payment source (eg, Bank of USA) and the balance available in the default payment source's default account, and the selected default is displayed. A screen 2914 that prompts the user to confirm is presented. As in previous examples, the user can activate the “select” control to select a default account and default payment source, or can navigate to an alternative payment source.

Following payment source selection and / or confirmation via screen 2914, the user is presented with a screen 2916 that allows the selection of a payment method. The user uses “Select” to select, using the “Back” and “Forward” keys to navigate the menu. In this example, the stored value card payment method is shown highlighted and is therefore selected.
In response to the activation of selection control on screen 2916, the user is presented with a screen 2918 that displays payment and confirmation of the selected payment method. In accordance with aspects of the present invention, the exemplary screen 2918 displays a stored value card number for a payee's existing card (previously stored) and buttons for payment, new card, and cancellation. I will provide a. The selection of the payment button results in a payment with an existing value storage card, while the selection of a new card button results in the issuance of a new value storage card. It will be appreciated that in order to allow payment in this way, the payee's existing card value storage card number is pre-stored on the user / payee's mobile device or elsewhere. Selection of the “Payment” button then causes a screen 2922 to be displayed using the existing card number to indicate that $ 123.45 payment has been made on the value storage card.

  In accordance with one exemplary aspect of the present invention, a display screen 2920 is provided that displays where new and “loaded” value storage cards can be obtained in the event of a user selection of a new card button. For example, the screen 2920 shows the transaction ID “Please receive your new value storage card at the 123 Main St. CVS store”. After this screen, as in other embodiments, screen 2922 is displayed and the stored value displayed for the mobile number for which the payment of the displayed amount ($ 123.45 in this example) has been identified. Provide a confirmation screen to notify the payer that the card account has been paid. In addition, the account balance of the used payer is preferably updated and displayed to reflect the decrease in available funds.

  FIG. 30 illustrates, via a payee's mobile device, for a “Pay Anyone” option in which a user selects / enters a mobile device phone number and uses a stored value card payment method, according to an exemplary aspect of the invention. A series of mobile device screen views 3000 from a payee's view are shown. As in other embodiments and aspects, the information shown is generated by a series of text messages (SMS) or by a mobile wallet application when loaded and activated on a payee's mobile device. Can be presented to the payer.

  As shown in screen 3002, an SMS text message is received from SMS generator 151 or similar information is generated by a mobile wallet application running on the payee's mobile device. Following this message, the payee is notified that someone with the phone number 404-404-4040 has sent a payment for an amount of $ 123.45 for delivery via the stored value card. According to one exemplary aspect of the present invention, the message to the payee includes a default payment receipt method (eg, depositing into a predetermined value storage card account). When generated by the mobile wallet application, the screen 3002 preferably includes a “confirm” control, a “card change” control, and a “cancel” control. By activating the “Verify” control, the payee / recipient can confirm that the displayed stored value card account number stored in the MFTS database is accurate with respect to payment. On the other hand, the payee has the ability to change to another stored value card account by entering a new account number after activating the “card change” control.

  If the payee activates the “card change” control in the screen view 3002, a separate screen 3004 is shown asking the user / payee whether the user / payee wants to receive a new card. The controls available on this screen are “Yes”, “No”, and “Done”.

  If the user selects “Yes”, the user will be prompted on the screen view 3006 to enter and confirm a postal code to receive the card. The controls available on this screen view are “Confirm”, “Return”, and “Done”.

  When entering a valid zip code and selecting the “confirm” control, the user will be presented on the screen view 3008 with the location of the store to receive the new card. The controls available on this screen are “Confirm”, “Return”, and “Cancel”.

  In response to processing a transaction by performing a payment, according to one exemplary aspect of the present invention, the payee may receive the payment upon receipt by the user / payee. Then, a confirmation message, that is, a confirmation display 3010, is displayed to indicate that it will be deposited in the newly issued value storage card account. At this point, the payee can activate the “Done” control to finish receiving payments, or, if applicable, the “Proceed” control to proceed to another transaction. It is possible to activate.

  FIG. 31 shows a sequence diagram for a “Pay Anyone” payment method 3100 involving the use of a stored value card according to an exemplary aspect of the present invention. This sequence diagram shows the following interactions between the parties: That is, payee mobile device 3102, MFTS 18, third party value storage card provider 3140, and payee 3160. In general, in this example, the user / payor selects a stored value payment method and communicates this determination to the MFTS 18 via the MFTSPI 3106, as shown in step 3104. The MFTS sends a request to create a transaction and transaction ID to the third party value storage card provider, as shown in step 3108. The payment amount is withdrawn from the payment source of the user (payer) and the third party stored value card provider uses the message 3110 to configure the stored value card account on behalf of the payee in step 3112. The payee receives the transaction ID in the SMS message and is notified about the location of the stored value card, as shown in step 3116. The payee can then obtain a stored value card from the retail store location associated with the stored value card vendor and “load” the card, as shown in step 3118. At step 3122, message 3120 is sent to the third party value storage card provider to provide a transaction ID, card number, phone number, and the like.

  Beginning at step 3104, the user / payer first selects a stored value card payment method as described elsewhere, and generates a mobile payment instruction (MPI) MFTS 18 that displays the payment amount and the selected payment method. Assuming that The MFTS 18 receives this MPI and sends a corresponding MFTS payment instruction (MFTSPI) message 3106 including information required by the third party prepaid (preserved value) card provider or third party prepaid (preserved value) card vendor 3140. Generate and request funds transfer to the card provider by pulling on the user / payer's selected payment source, if required. The MFTSPI 3106 is communicated to the third party stored value card provider 3140 and received at step 3108. According to one exemplary aspect of the invention, the MFTSPI can obtain an SV card with the payee unloaded (or can reload an existing SV card). Or it may include a zip code provided by the payee or payer to facilitate locating multiple retail stores. At step 3108, the third party stored value card provider 3140 generates a transaction identifier (ID) and one or more nearby retail store locations for the payee to receive and / or load the stored value card. Perform a zip code search to find out. According to one exemplary aspect of the present invention, the transaction ID is used for authentication purposes when the payee requires that the card can be loaded with payment. Maintained by the provider.

  Further, at step 3108, the third party card provider 3140 generates a message 3110 back to the MFTS 18 to notify the system that the stored value card account is configured and ready for use. According to one exemplary aspect of the present invention, this message 3110 allows the payee to identify the location where the unloaded value storage card can be obtained and then loaded and the transaction ID. Contains information to make. At step 3112 MFTS 18 receives message 3110 and the payment has been made, where the card can be obtained and / or loaded at several retail locations associated with the card vendor, and the card for the payee. A message 3114 is sent to the payee's mobile device 3102 notifying the transaction ID required for authentication of the payee. An exemplary screen in this regard is shown in FIG.

  At step 3116, payee's mobile device 3102 receives message 3114 and waits for payment by the stored value card payment method (via SMS text message or, if installed, via mobile wallet application). Information that informs the payee that it is, and information about possible receiving locations for obtaining and / or loading the value storage card. At step 3118 and according to one exemplary aspect of the present invention, the payee physically goes to the location identified in the message and typically obtains a stored value card that has not yet been loaded. Further, at step 3118, the payee with the stored value card presents the card to a retail store location or terminal associated with the third party card provider 3140 so that the card can be loaded for use.

  At step 3122, the third party card provider 3140 is presented with a stored value card by the payee along with a request to activate and / or load the card with payment. The third party card provider typically requests authentication information at this point to activate and / or load the value storage card. In this case, the authentication information includes one or more of the following information items. That is, the transaction ID number, card number, mobile phone number, and optionally other information such as name, address.

  After the payee presents the required information to the third party card provider 3140, at step 3124, the card provider loads the card with the previously provided funds obtained from the user / payee. be able to. At step 3128, the stored value card loaded with the payment at this time is then sent to payee 3160 who can use the card at a location that accepts a particular type of stored value card as the payment form. Returned via transaction 3126.

  According to an exemplary aspect of the present invention, if the payee already has a stored value card, the payee may contact the third-party stored value card provider 3140 to request payment using the existing stored value card. It is possible to contact and follow the steps from 3122.

  The aforementioned payment method involving the use of a stored value card payment method requires that only the transaction ID number and the stored value card type be provided to the payee in order to receive payment, so that the subscriber / user of the MFTS 18, and It will be appreciated that it is useful for performing payments to non-subscribers. According to an exemplary aspect of the present invention not described in detail, the information corresponding to the stored value card does not have a mobile device capable of receiving an SMS message or executing a mobile wallet application, or a mobile device As a measure for payees who do not have any at all (by memo or document), it can be displayed to the payer first. When an initial value store card account is created on behalf of a particular payee, the payee's name will be stored in the MFTS 18 as described above, so that the user / payee will receive that payee. Additional funds can be loaded into the stored value card account associated with the payer and thus can be quickly and easily reused to provide additional funds to the selected payee.

Balance Transfer FIG. 32 shows a series of mobile device screen displays 3200 corresponding to the “Balance Transfer” financial transaction option, according to an exemplary aspect of the present invention. Balance transfer is a financial transaction involving transfer of funds between different accounts of the same user. Balance transfers allow MFTS users to use their mobile devices to obtain and monitor information about their money accounts and transfer funds from one account to another.

  As in the previously described embodiments and aspects, the user first selects a mobile wallet application on screen 3202, provides authentication information (eg, login) via screen 3204, and performs payment on screen 3206. Before the option (ie balance transfer) is presented by the MFTS. In screen 3206, assume that the user selects the “Balance Transfer” option. In response to this selection, the user is provided with a balance transfer screen 3208 that allows the user to select funds transfer from one of a plurality of selectable accounts. As shown on screen 3208 by way of example, the user may use a MasterCard ™ account, a VISA ™ account, a Discover ™ account, a GaSL account, or a Bank of USA account as a source of funds available for balance transfer. It is possible to choose to transfer funds. The corresponding balance associated with such an account is also preferably displayed according to this aspect of the invention. More preferably, the screen 3208 includes a “select” control for navigation and selection, a “back” control, and a “forward” control, similar to controls in other functions. Screen 3208 shows the Bank of USA account highlighted, so the Bank of USA account was selected.

  In response to user activation of the “Select” control on screen 3208 using a selection in the list of available accounts, an exemplary screen for the selected account (eg, Bank of USA) is displayed as screen 3210. Is done. Screen 3210 displays a number of different accounts, savings balances, check balances, and others (eg, financial market accounts) associated with a particular payment source (ie, Bank of USA). More preferably, screen 3210 includes a “select” control for navigation and selection, a “back” control, and a “forward” control, similar to controls in other functions. Screen 3210 shows the check balance highlighted, so that the check balance was selected.

In response to activating the “select” control on screen 3210 using a selection in the list of available accounts (ie, check balance in the example shown), screen 3212 is displayed. Screen 3212 presents a list of available accounts / payment sources that is similar to the list of available accounts / payment sources on screen 3208, except that it is displayed for the transfer destination rather than the transfer source.
More preferably, screen 3212 includes a “select” control for navigation and selection, a “back” control, and a “forward” control, similar to controls in other functions. Screen 3212 shows the GaSL account highlighted, so a GaSL account has been selected.

  In response to user activation of the “Select” control on screen 3212 using a selection in the list of available accounts, an exemplary screen for the selected account (eg, GaSL) is displayed as screen 3214. . Screen 3214 displays a number of different accounts associated with a particular account, balance transfer destination (ie, GaSL), savings balance, check balance, and others (eg, financial market accounts). More preferably, screen 3214 includes a “select” control for navigation and selection, a “back” control, and a “forward” control, similar to controls in other functions. Screen 3214 shows the check balance highlighted, so the check balance was selected.

In response to user activation of the “select” control on screen 3214 using a selection in the list of available accounts (eg, a GaSL check account), a balance transfer confirmation screen 3216 is displayed. According to one exemplary aspect of the present invention, the balance transfer confirmation screen 3216 provides a data input area for user input of the funds transfer amount (eg, $ 2000 is shown). More preferably, screen 3216 includes a “transfer” control for navigation and selection, a “return” control, and a “forward” control, similar to controls in other functions.
In response to the user activation of the transfer control, a balance transfer confirmation screen 3218 including information indicating that the balance transfer has been achieved is displayed. In the example shown, a balance transfer of $ 2000 is transferred from a Bank of USA check account to a GaSL check account. Screen 3218 also preferably includes a display of the current balance of each of the accounts associated with the balance transfer, updated to reflect the balance transfer.

  FIG. 33 shows the interaction between the payer / user mobile device 15, the MFTS 18, the first financial institution 30A associated with the user, and the second financial institution 30B associated with the user. FIG. 10 is a sequence diagram of a balance transfer payment method or balance transfer payment process 3300 according to an exemplary aspect. Balance transfer is performed between these two financial institutions 30A and 30B.

  As in previous methods described elsewhere, the initial steps 3302, 3304, 3307, and 3309 in the balance transfer method receive the authentication message 3306 from the user / payee and authenticate by the MFTS 18. And sending an authentication confirmation message 3308 to the user's mobile device 15. In response to the authentication, the user starts the mobile wallet application at step 3302, enters a password or PIN at 3304, and the MFTS authenticates the login at step 3307 to activate the user's mobile wallet on the user's mobile device. Turn into. This action allows the user to proceed with the use of the mobile wallet application at step 3309. The user then selects a balance transfer option at step 3310. In step 3312, the mobile device organizes a mobile payment instruction (MPI) message 3314 and sends this message to the MFTS 18. In accordance with one exemplary aspect of the present invention, the MPI message 3320 includes a payment source account, a destination account and a MFTS so that an appropriate MFTS payment order can be constructed for the identified financial institution. Contains information identifying the balance transfer amount.

  At step 3316, the MFTS 18 receives the MPI message 3314 and constructs an appropriate MFTS payment instruction (MFTSPI) message 3318 for communication to the first financial institution, the paying financial institution 30A. At step 3320, the first or paying financial institution 30A receives the MFTSPI message 3318 and debits the selected account for the displayed amount of funds. The first financial institution or payer financial institution 30A then follows its own procedure for transferring these funds to the selected second financial institution 30B via message 3322, as displayed in step 3320. Take action. At step 3324, the second financial institution, payee financial institution 30B, updates its record to indicate receipt of funds. According to one exemplary aspect of the present invention, the first and second financial institutions 30A and 30B may update their local records of funds available to the MFTS 18 in their respective accounts. The balance transfer confirmation message displayed by messages 3330A and 3330B is provided back to MFTS 18 so that it can.

  In step 3328, MFTS 18 receives balance transfer confirmation messages 3330A, 3330B and updates the user's record to reflect the balance transfer. Further, in step 3328, the MFTS 18 transmits a balance transfer confirmation message 3332 to the mobile device 15. At step 3334, mobile device 15 receives balance transfer confirmation message 3332 and updates its local storage of balances associated with the user's account and financial institution to reflect the completion of the balance transfer.

Receiving payments on the payee's mobile device by installing a mobile wallet From the above discussion, the reader should note that the aspect of the present invention is for the purpose of the payee to (1) interact with the MFTS to select a payment receipt method. MFTS to receive and send a series of SMS messages (text messages), or (2) to select a payment receipt method and / or to conduct a transaction (payment execution) as an MFTS user It will be noted that it involves either installing and using a mobile wallet application on the payee's mobile device for the purpose of interacting with the payee. Accordingly, the payee may not install a mobile wallet application on his mobile device to realize the benefits of some aspects of the present invention. However, payees with recently available types of mobile devices are presented with the opportunity to download, install and use a mobile wallet in accordance with some features and aspects of the present invention. Thus, and in accordance with exemplary aspects of the present invention, a user downloads a mobile wallet application to an individual who wishes to make a payment, receives payment according to the described aspects of the present invention, and provides a payment receipt option. The opportunity to receive both the benefits of choosing, as well as the benefits of using the mobile payment service provided by the operator of the MFTS 18 is provided.

  In order to “spread” the benefits of mobile wallets to payees (which are potential users of MFTS when installing and activating mobile wallet applications), the present invention downloads and uses mobile wallet applications Record as an MFTS user, provide codes for mobile wallets via wireless download, activate payees to become MFTS service users, and learn about the opportunity to use the mobile wallet application as a user. An aspect for notifying the payer is included.

  In this regard, reference is made to FIG. 34 for a discussion of a method for a payee to receive payment from a user of MFTS 18 and also download and install a mobile wallet application. FIG. 34 shows payment receipt including steps for downloading and installing a mobile wallet application and registering with the MFTS service, thereby providing the payee the opportunity for the payee to become the user of the MFTS service himself. With respect to the method, a series of mobile device screen views 3400 from a payee's view through the payee's mobile device is shown. The method provides a payee who receives payment from a user who is already a participant in the MFTS system with the ability to quickly and easily download and use the mobile wallet application, thereby enabling the payee to a new MFTS user. It is then advantageous to enable the so-called “viral spreading” of the benefits of mobile wallet applications and the benefits of using MFTS by then disseminating benefits to payees of new MFTS users . Such new user payees are similarly given the opportunity to register and participate.

  For payees who do not have a mobile wallet application installed on their mobile device, as in other embodiments and aspects, the information shown is sent to the payee by a series of text messages (SMS). Will be presented.

As shown in the screen or message 3402, the payee typically displays that the user has sent a payment to the payee, and text to inform the payee about how the payment is received (SMS). Receive a message. For example, the screen or message 3402 presents “404-404-4040 sent you a payment of $ 123.45”. Further in accordance with this exemplary aspect of the present invention, the screen or message 3402 includes the text “Your mobile device does not have an application required to receive payment. Do you want to download this application?” “Yes” and “cancel” controls are also preferably provided so that the user can choose to receive an application download or receive payment without installing a mobile device application. If the user decides not to install the mobile device application, or if the mobile device cannot install the mobile device application, the user is given other options to receive payment. When the user selects a “Cancel” button as shown in screen view 3402, a screen is displayed. The screen view (not shown in FIG. 34) provides the user with other options, such as using a check, receiving payment via an ACH transaction, or via a stored value card.
The user returns a payment response to the payer using a text (SMS) message to inform the payer how the user wants to receive the payment without the installation of the mobile device application. The response that the user sends to the payer may include the payment receipt method and the user's address information, or account information and any other relevant information.

  If the payee selects “Yes” control, a message with the manufacturer name and model number of the mobile device is sent back to the MFTS via the MCSP. The MFTS identifies the type of mobile device held by the payee, the appropriate mobile device application code executable on the payee's mobile device is sent to the mobile device, and the mobile wallet application code is After being downloaded to the mobile device, the self-installation process begins on the mobile device. As shown in screen view 3404, a text message may be displayed indicating that the installation operation has started. In order to notify the payee of the progress of the installation, a normal progress bar may be displayed as part of the installation process, as shown on the screen or message 3403. If desired, a “cancel” control is optionally provided so that the payee can finish the installation operation.

  According to one embodiment of the invention, when the mobile wallet application download is complete, a completion screen or completion message 3406 is displayed. This completion screen view 3406 preferably displays that the installation of the mobile wallet application has been completed. According to one exemplary aspect of the present invention, the mobile wallet application then executes and displays the screen (i.e., message) generated by the application. At this stage, the mobile wallet application can optionally prompt the payee to enter a PIN for use of the payee's account maintained by the application and / or MFTS operator. Is preferred. Preferably, a “forward” control, a “back” control, and a “cancel” control are also provided for those displayed functions. A PIN confirmation screen 3408 is then displayed to prompt the payee to re-enter the PIN for confirmation in response to the payee's selection of the "forward" control on the screen or message 3406. It is preferable. Similarly, “forward” and “cancel” controls are preferably provided.

  In response to the selection of the payee for the “forward” control, a payment receipt screen 3410 is displayed. This screen repeats the text "404-404-4040 sent you a payment of $ 123.45" and prompts the payee to select one of several possible payment receipt methods. Preferably it further includes text to prompt. In the exemplary screen 3410, the payee is presented with an option to receive payment via ACH, check, or stored value (SV) card. The methods, screen displays, and operations relating to such payment methods are described elsewhere in this document and need not be repeated here. By way of example and not limitation, screen 3410 shows a check payment method highlighted, and thus a check payment method is selected. The MFTS can obtain a user's mailing address based on a telephone number through a third party address provider. If the user decides to receive a check using a different address, the user selects the “Change Address” button on the screen view 3412. Multiple screen views may be followed to allow the user to change, edit, and confirm the new mailing address. These screen views will be understood by those skilled in the art and will not be described in detail here.

  The screen 3412 requesting confirmation of the mailing address or the like is preferably displayed as described in more detail elsewhere. A payment confirmation screen 3414 confirming the mailing address of the payment (or other selected payment method, if selected) is displayed next, as described in more detail elsewhere. Is preferred.

  At this point, the payee has now downloaded and installed the mobile wallet application and is responsible for making payments to the billing entity and other individuals in accordance with the previously described aspects of the present invention ( Further use is enabled when providing additional record information, such as providing account information to set up payment sources that may currently be used for the user). The user's mobile device is currently registered and enabled within the MFTS, but the user needs to visit the MFTS user website to add and enter information about payment sources, billing entities, etc. Still there. This information entry is discussed later in this document.

  FIG. 35 illustrates a payment to allow a payee to receive payment and download and install a mobile wallet application on the payee's mobile device 3501, thereby enabling it to operate as a user of the MFTS. Method line of payee mobile wallet installation or process 3500 according to an exemplary aspect of the present invention showing the interaction between a person / probable user's mobile device 3501, MFTS 18, and third party payment provider 30P. FIG. The steps of method 3500 typically direct the MFTS 18 to make a payment to a specific payee by mobile phone number or name, and to notify the payee that the payment is incomplete. Will be executed after contacting the payee by one or more messages. Accordingly, the steps in method 3500 typically occur at the time of determining a payment delivery method for the payee.

The first step taken, starting at step 3502, is the receipt of a message 3505 by the payee who is a non-subscriber of the service of the MFTS 18 operator indicating that the user has made a payment to the payee. According to one exemplary aspect of the invention, the message is a text message (SMS) delivered to the payee's mobile number. In step 3502, the non-subscriber / payee sees the message as shown in the screen view 3402 of FIG. 34 and selects the “Yes” control in the screen 3402 of FIG. 34, for example. Determine whether the payer / payee wants to download and install the mobile wallet application on his mobile device. A message 3506 is returned to the MFTS 18 with confirmation of the download and installation of the mobile wallet application and the manufacturer and model number or serial number of the mobile device. In step 3508, as displayed by message 3510, the MFTS downloads the appropriate mobile wallet application to the specified mobile device and installs the downloaded mobile wallet application. At step 3512, the user is notified that the download and installation operations are complete, and the payee / probable user creates a login (or PIN, or password, if necessary) to the MFTS user. You will be prompted. After the login / password / PIN authentication process (see FIG. 34), in step 3516, the payee / user is provided with a “payment receipt” screen that includes payment details and requests a payment method selection. The At step 3518, the user selects the desired payment method (eg, ACH, check, or stored value card), and at step 3520, the applicable payee / user is required to receive payment. Provide account details.
This account setup information is communicated to the MFTS 18 via one or more electronic messages 3520.

  In step 3522, the MFTS 18 receives the account setup information and stores the account information associated with the identification information corresponding to the payee / user in the MFTS user database. Again at step 3522, the MFTS 18 selects the MFTS Payment Order (MFTSPI) message 3523 to cause the payee to issue the selected form of payment, as shown at step 3524. Communicate to provider 30P or financial institution 30 (eg, ACH payment generator, or paper check issuing entity, or value storage card vendor). After providing this MFTSPI to the selected payment provider, again at step 3522, the MFTS 18 provides a payment confirmation message 3526 to the payee / user via the payee / user's mobile device 3501. At step 3528, the payee / user receives payment confirmation information that the payment has been sent for processing.

  Following the previous step and as displayed in step 3530, the payee (currently a registered user of the MFTS service) not only receives additional payments via the installed mobile wallet application, The billing entity on which the payment is made, as well as entitlement to register the payee / user's payment source, is also granted and enabled. Payee / current users can also promote the use of mobile wallet applications and the convenient use of MFTS and related services by making payments to others who may not have a mobile wallet. It can also be facilitated, thereby facilitating the widespread use of the system and method of the present invention. In accordance with exemplary aspects of the present invention, a new user is identified with an MFTS website and details regarding the billing entity, individual to pay, payment source, account, view transaction details, default payment method and receipt method, etc. Information is preferably provided that prompts a new user to access a web application (FIGS. 37-42) to enter and provide additional information.

  Referring now to FIG. 36, there is shown a continuous screen view 3600 for such operation when a registered user is required to change the login PIN, according to one embodiment of the present invention. Screen views 3602 and 3604 are described elsewhere in this document and are not described here. In screen view 3606, the user highlights and selects the “Change PIN” option from the menu provided on the screen view. For security purposes, this action requires the user to enter the current PIN number for confirmation in screen view 3608. The user is required to enter a new PIN in screen view 3610 and re-enter the PIN again for confirmation purposes in screen view 3612. According to one embodiment of the present invention, the PIN is provided with a 6-digit number for easy storage and can be extended to any reasonable length. In another embodiment, if the mobile device has a complete keyboard, the PIN comprises alphanumeric characters. In one embodiment, the PIN comprises alphanumeric characters that are case-sensitive. In another embodiment, the PIN comprises alphanumeric characters that are not case sensitive. In one embodiment, the PIN is a fixed length. In another embodiment, the PIN is a variable length with a predetermined minimum length and maximum length.

  A message is sent to the MFTS to notify the MFTS to change the PIN and save the changed PIN in the MFTS user database. The MFTS sends a confirmation message back to the user's mobile device to notify the user that the PIN has been successfully changed, and this message is displayed on the screen view 3614. Here, the optional button “Main Menu” takes the user to the main menu screen view 3616 of the mobile wallet application.

  Next, a discussion of a user interface with a screen display of a web application input / output interface illustrating an aspect of user registration for use of a mobile financial transaction system (MFTS) via a web application user site in accordance with aspects of the present invention. For this purpose, reference is made to FIG. 37, which consists of FIGS. FIG. 37 is an exemplary screen display of a web application 154, in particular, a user site web application 153 (FIG. 2). In particular, FIG. 37A illustrates a user registration aspect for use of services provided by the MFTS 18. 37B, 37C, and 37D illustrate aspects of adding or editing a mobile device and editing aspects of the mobile device.

  In accordance with an aspect of the present invention, the web application identifies a first area 3705 that includes a plurality of selectable links or buttons for predetermined functions, a second area 3710 for data entry, and a specific Provides a user site screen display 3701 including a plurality of user controls 3715 to provide the functionality of In the first area 3705, selectable links labeled “Mobile Device”, “Account”, “Payee”, and “Logout” are provided. The user selection of the mobile device link presents a display as shown at 3701 that allows the user to manage the mobile device for use with MFTS in accordance with aspects of the present invention. User activation of the account link provides the display described with respect to FIG. User activation of the payee link provides a display of the user as shown in FIG. 39, as described below.

  A second area 3710 of data entry displays the mobile number of any mobile device that is pre-registered by the current user for use with the MFTS 18. Second area 3710 shows a single mobile device number (404) 505-6060, which is an exemplary mobile phone number.

  Selectable user control 3715 provides commands for performing functions relating to the registered mobile number (s). In accordance with aspects of the present invention, that is, the presently preferred embodiment, user control 3715 includes an “add device” button 3717, an “initialize device” button 3720, an “edit device” button 3725, and a “lost device”. ”Button 3730,“ device unlock ”button 3735, and“ device delete ”button 3740.

  These functions are self-explanatory and will be understood by those skilled in the art. In one embodiment, the “lost device” feature is to disable a lost mobile device reported for user protection. The “device unlock” function is to re-enable a mobile device that has been disabled after several consecutive failed logins, or to reactivate the mobile device. The “device deletion” function is for removing the registered mobile device from the mobile financial transaction system service.

  User activation of either the “Add Device” button 3717 or the “Edit Device” button 3725 causes the MFTS web application to provide a screen display 3701B, as shown in FIG. 37B. Display screen 3701B includes a data entry area 3745 for entry of the mobile device phone number where the user can enter the number. The “Submit Query” button 3750 allows the web application to utilize the number entered in the data entry area 3745 so that information can be entered for use with the MFTS 18 or an attribute or Provided to allow user information corresponding to the mobile device number to be entered / retrieved so that the information can be edited. An “add device” button 3717 and an “edit device” button 3725 allow the user to enter detailed account information regarding the mobile device. Information about the mobile device comprises: That is, the user name, mailing address, payment request address, web access user name, and password.

  FIG. 37C illustrates a user site display screen 3701C displayed to the user when entering a new mobile device number for the purpose of configuring the mobile device for use with MFTS 18 in accordance with aspects of the present invention. According to one embodiment of the present invention, upon receiving a newly entered mobile device number for use in the system, a text (SMS) message is sent to the mobile device having the entered mobile device number. According to an aspect of the present invention, this SMS message provides the user with information on downloading and installing the mobile device application to the user so that the mobile device can be configured for use with the system. Instruction information such as that shown at 3760 is preferably displayed to the user to notify the transmission of text messages and instructions. In addition, and in accordance with an aspect of the present invention, the user is prompted to enter code initialization when executing a mobile device application on the mobile device, and the initialization code is sent to the mobile device for security purposes. Provided.

  FIG. 37D provides a display screen 3701D with a message 3765 that is displayed in response to user activation of the “Delete Device” button 3740 in FIG. 37A.

  FIG. 38 shows various exemplary user site display screens 3801 displayed by web application 154 in response to user activation of an account link or account button in controller area 3705. In FIG. 38A, the 3801A display screen is initially provided in response to activation of the “Account” button. Display screen 3801A includes an information display area 3805 comprising a list of one or more accounts associated with the user currently interacting with MFTS 18, and a specific and selected account that is highlighted in area 3805. It includes an information display area 3810 for displaying detailed information, and a plurality of control buttons 3815 for performing functions related to the selected account. For example, the account “Kyle's check” is shown highlighted in area 3805, and specific information about the selected account, such as routing number, account number, account nickname, etc., is shown in information display area 3810.

  In accordance with aspects of the present invention, user controls 3815 include an “Add Account” drop-down menu 3817, an “Edit Selection” button 3820, and a “Delete Selection” button 3825. Activation of a user selection or “edit selection” button 3820 of the “Add Account” menu 3817 results in a screen display as shown as screen 3801B in FIG. 38B.

  FIG. 38B illustrates aspects of a web application for editing information about a selected account. Display screen 3801A includes an exemplary data entry area 3830 for displaying and editing specific information regarding the selected account. For example, in accordance with aspects of the present invention, areas for routing and transmission number 3832, account number entry and editing 3835, account type entry and editing 3840, account nickname entry and editing 3845 are provided. A “Submit” button 3850 is provided to update and save the information, and a “Cancel” button 3855 is provided operable to be known to those skilled in the art.

  FIG. 38C illustrates the web application 154 in response to a user selection of an account in area 3805 (FIG. 38A), which is a card-type account (eg, a credit card or stored value card rather than a bank account as shown in FIG. 38B). This is an exemplary user site screen display 3801C displayed by Display 3801C includes an information display area 3860 for information regarding card type accounts. As shown in FIG. 38C, the display area includes a card number display area 3862 and a nickname area 3865 for entering a short name for the account to facilitate storage. The “Forward” button 3870 moves to another account of the plurality of accounts stored and maintained by the MFTS 18 and the “Cancel” button 3875 operates as known.

  FIG. 38D shows an exemplary screen display 3801D that is displayed in response to a user change of information about the card account (eg, when the user changes any information about the card account as in FIG. 38C). The display screen 3801D includes an information display area 3880 for displaying the card number of the account selected for input or editing, and a personal identification number (PIN) for inputting the PIN associated with the card account for security purposes. ) Data input area 3885. A “Submit” button 3890 and a “Cancel” button 3895 are provided and are operable as is known.

Identifying Information FIG. 39 is responsive to user activation of a “payee” link or “payee” button in area 3705 to manage a payee receiving payment in accordance with an aspect of the present invention. The user site display screen 3901 displayed as an example is illustrated. In FIG. 39A, a “payee management” display screen 3901A displays information about the payee that is pre-entered in the MFTS 18 by the user via the web application 154 or, if necessary, via the mobile device application input. A region 3905 to be used. As shown in FIG. 3901A, at least information about the payee's name and payee's mobile device number is displayed. In accordance with another aspect of the present invention, payees in the system can (if available) payee address, default payment method, one or more available to a particular payee. Has other information stored in connection with the payee, including preferred account numbers for payment methods, and other identifying information. As shown in FIG. 39A, specific payees can be highlighted or displayed for specific information and operations such as editing or deletion. Also shown in FIG. 39A are control buttons for an “payee addition” button 3910, a “select edit” button 3915, and a “select delete” button 3920. User selection of the “Add Payee” button 3910 or the “Edit Selection” button 3915 results in a display as shown in FIG. 39B.

  FIG. 39B is an exemplary user site display screen 3901B displayed in response to a user selection of a web application for adding a payee or editing a selected payee. The example display screen 3901b includes a data entry and display area 3925 that displays information about the particular payee selected in FIG. 39A, allowing the entry or update of information. In this embodiment of the invention, a “Name” field 3927, a “Last Name” field 3930, and a “Telephone Number” field 3935 are provided. According to another aspect of the invention, address information, account number information, default selection fields for payment methods, and other information are also provided. A “Submit” button 3940 and a “Cancel” button 3945 are provided and are operable as is known.

  From the review of FIGS. 37-39, one of ordinary skill in the art can enter information regarding the “mobile device”, “account”, and “payee” to provide functionality as described elsewhere in this document. It will be appreciated that an internet-accessible web application input / output interface 154 is provided that allows editing.

  FIG. 40 is an alternative embodiment of a user display screen generated by a web application input / output interface 154 configured in accordance with an alternative aspect of the present invention. FIGS. 40-42 show alternatives for user interaction with a web application using slightly different ways of displaying information and receiving user interaction for selected accounts, mobile devices, billing entities, and payment sources. Provide a way.

  FIG. 40 shows an exemplary display screen 4001 provided by a web application for managing accounts. Display screen 4001 is provided by a web application to manage accounts. Display screen 4001 includes three selectable tabs. That is, an “account summary” tab 4005, a “payment request entity” tab 4010, and a “payment source” tab 4015. Selected and shown in FIG. 40 is an “Account Summary” tab 4005. Information related to the “Account Summary” tab 4005 includes information about a particular user, including an account number, a mobile number associated with the user's mobile device, and other identifying information as shown. Other relevant information about the user is preferably provided in display area 4035, such as address information, recording date information, and other information about the billing entity and payment source. An “edit” button 4020 is provided to edit the displayed information, while a “new” button 4025 generates a data entry display screen that will allow entry of information as shown in FIG. Provided for.

  FIG. 41 is an exemplary alternative display screen 4101 displayed in response to user activation of the “billing entity” tab 4010. The information displayed on display screen 4101 includes information identifying a particular account or mobile device number for the current user, as well as multiple “invoice creators” or billing entities, or people from whom payments can be made (eg, It includes a display area 4120 that displays information about payees and “pay anyone” payment scenarios as described elsewhere in this document. An “Edit” button 4020 and a “New” button 4025 are provided and are operable as described above and as will be known to those skilled in the art.

  Invoice creator data area 4120 as shown in FIG. 41 includes selectable tabs for a plurality of invoice creators 4105, 4110, and 4115. Activation of the “New” button 4025 adds a new tab and a new page for the new “Bill Creator”. An exemplary tab 4110 is shown as selected and displays information about a particular bill creator for which information has been pre-filled. In the example shown in FIG. 41, required to enable the MFTS 18 to receive a bill from a billing entity and generate a payment for this fee-paying entity in accordance with the associated account number, address, and aspects of the invention. An exemplary billing entity, namely George Electricity Company, is shown along with other identifying information.

  Also provided in screen 4101 is current balance data that displays information about the current account balance for the identified and selected bill creator (eg, “Bill Creator 2” shown in tab 4110). This is a display area 4125.

  FIG. 42 is an exemplary alternative web application display in the form of a display screen 4201 that is displayed in response to selection of the payment source tab 4015. The exemplary display screen 4201 includes information identifying the account being viewed, such as account number, mobile number, etc., as in previous screens, and is operable as described and known elsewhere. An “Edit” button 4020 and a “New” button 4025 are also provided.

  The “Payment Source” tab 4015 also includes an information display area 4220 for displaying information about the selected account. In exemplary selectable tabs 4205, 4210, 4215, where multiple selectable tabs for a particular account available to a user are identified as “Bank 1”, “Bank 2”, and “Bank 3”. Provided. In FIG. 42, “Bank 2” 4210 is selected and shown. Thereby, display area 4220 displays information related to the selected payment source that in this case identifies the specific financial institution and the specific account associated with the selected financial institution. For example, the information preferably includes the name of the payment source (eg, George Best Bank) and the corresponding account number, account type, address, and other identifying information. Also preferably provided is an information display area 4225 for displaying the current balance associated with the selected account.

  From the foregoing description, those skilled in the art will recognize that the web application input / output interface 154, or in accordance with aspects of the present invention, allows user data entry and editing of a payment source, billing entity or other payee. In addition, it will be understood and appreciated that it is possible to provide a display screen and control as shown in FIGS.

  The foregoing descriptions of exemplary embodiments of the invention have been presented for purposes of illustration and description only and are not intended to be exhaustive or to limit the invention to the same form as disclosed. . Many modifications and variations are possible in light of the above teaching.

  The embodiments are not limited to the principles of the present invention and to allow others skilled in the art to utilize the invention and various embodiments with various modifications as appropriate for the particular use contemplated. Selected and explained to illustrate the practical application of. Alternative embodiments will become apparent to those skilled in the art to which this invention pertains without departing from the spirit and scope. Accordingly, the scope of the invention is defined by the appended claims rather than the foregoing description and the exemplary embodiments described herein.

Claims (97)

A method for making a financial payment to a payee via a connected user stored value by using the mobile device (SV) card for communicating over wireless network,
Receiving a mobile payment instruction in a mobile money transaction system (MFTS), the mobile payment instruction being executed by a payment source for payment and a stored value (SV) card payment method; Providing information identifying a person;
In the mobile money transaction system ( MFTS ) , in response to receiving the mobile payment instruction, information corresponding to the identified payee for receiving the payment, and payment by a stored value ( SV ) card payment method. Determining information to direct;
The mobile money transaction system ( MFTS ) includes a mobile money transaction system (MFTS) database for storing payment source information and user information associated with at least one account associated with at least one payment instruction recipient. ,
The determining step is responsive to receiving the mobile payment instruction including the payment source, the payment instruction recipient identified in the payment instruction from information pre-stored in the mobile money transaction system ( MFTS ) database. Further comprising retrieving information corresponding to the account selected in
Wherein the mobile financial transaction system (MFTS), and generating a mobile financial transaction system (MFTS) payment instruction to a payment instruction recipient that maintains a relationship with a stored value (SV) card entity Te I, the mobile financial A trading system ( MFTS ) payment order includes at least an amount, information corresponding to the identified payee, information corresponding to a potential payment by a stored value ( SV ) card payment method, and information corresponding to the account Including, steps,
Communicating the mobile money transaction system ( MFTS ) payment instruction from the mobile money transaction system ( MFTS ) to the payment instruction recipient to achieve payment to the identified payee by a stored value (SV) card And steps to
A method comprising: The method of claim 1, wherein the user information identifying a payee comprises identifying a payee from one of a plurality of pre-stored names.   The method of claim 1, wherein the user information identifying a payee comprises identifying the payee by a payee mobile number. The method of claim 1, wherein the payment instruction recipient is one of a financial service provider, a billing aggregator, a stored value (SV) card issuer, or a retailer that handles stored value (SV) cards. The method of claim 1, further comprising wirelessly communicating to the payee information notifying that payment by a stored value ( SV ) card is acceptable. The payment source for making a payment, financial service provider, and a specific mouth seat associated with the financial service provider for executing the payment method of claim 1. The mobile money transaction system ( MFTS ) retrieves current account information from the financial service provider and wirelessly communicates the current account information to the mobile device when such information is received from the financial service provider; The method of claim 6. The mobile money transaction system ( MFTS ) stores transaction information corresponding to a user's money transaction, and the transaction information includes payment information in addition to other information utilized to track the status of the payment. The method of claim 1 comprising.   The transaction information is one or more of the following information items: one or more of a user ID number, transaction identifier, amount, financial service provider identifier, account identifier, payee identifier, incomplete / completed flag. The method of claim 8 comprising: The method of claim 1, further comprising receiving a payment confirmation message from the payment instruction recipient at the mobile money transaction system ( MFTS ) in response to completion of a predetermined stage in performing the payment.   The method of claim 10, further comprising wirelessly communicating a payment confirmation message to the mobile device in response to receiving the payment confirmation message from the payment instruction recipient. The mobile money transaction system ( MFTS ) is further coupled for electronic communication with a user's computer via a data communication network such as the Internet;
Providing a web application associated with the mobile money transaction system ( MFTS ) ;
Receiving via the web application user information corresponding to a financial service provider, an account at the financial service provider, and a billing entity;
Storing the user information entered via the web application in a mobile money transaction system ( MFTS ) database for use in connection with payments initiated via a user mobile device;
The method of claim 1, further comprising:   The method of claim 12, further comprising retrieving transaction information corresponding to a transaction performed via the user mobile device via the web application and displaying to the user on the user's computer. Information corresponding to the payee's existing value storage ( SV ) card is stored in a mobile money transaction system ( MFTS ) database and is wirelessly transmitted to the user mobile device for display to the user and confirmation by a user command. 14. The method of claim 13, wherein the method is communicated. Payment may further comprise the step of wirelessly communicating a message to notify that it has been sent via the stored value (SV) card by the user to the payee to the payee's mobile device, according to claim 1 Method.   The method of claim 15, wherein the message to the payee's mobile device comprises a text message.   The method of claim 15, wherein the message to the payee's mobile device is provided via a mobile wallet application installed on the payee's mobile device. Wherein said selected manner payee can receive payment via a stored value (SV) card, fill the payment credited existing stored value (SV) card payee, and new The method of claim 15, comprising issuing a stored value ( SV ) card. In response to the instruction by the payee of receipt of payment via a new value storage ( SV ) card,
Displaying a data entry screen on the payee's mobile device for receiving input of information for identifying a new value storage ( SV ) card receiving location;
Receiving payee input of information for identifying a receiving location of the new value storage ( SV ) card;
Wirelessly communicating the location information to the mobile money transaction system ( MFTS ) ;
In response to a payee input of information identifying where to receive the new value storage ( SV ) card, information identifying a particular retail location where the new value storage ( SV ) card is available Communicating wirelessly to the payee;
The method of claim 18, further comprising: The stored value (SV) allows the card issuer to issue a card to the payee, a stored value (SV) the payee for retail facility is a stored value (SV) card receipt to pay the card 19. The method of claim 18, further comprising communicating card pickup information to the stored value ( SV ) card issuer that further enables verification of the identity of the card. 21. The method of claim 20, wherein the card receipt information comprises a transaction number provided by the mobile money transaction system ( MFTS ) associated with the payment, a card number, and a mobile telephone number associated with the payee. .   21. The method of claim 20, further comprising wirelessly communicating the card receipt information to the payee's mobile device. A system for a user to achieve a stored value (SV) card payment through the use of a mobile device connected for communication with a wireless network, comprising:
A mobile money transaction system (MFTS) coupled for wireless communication with one or more mobile devices of a user using a mobile communication service provider (MCSP), the mobile money transaction system ( MFTS ) comprising: Coupled for electronic communication with a payment instruction recipient that achieves payment via a stored value (SV) card, the mobile money transaction system ( MFTS ) is associated with at least one payment instruction recipient. A mobile money transaction system (MFTS) database for storing payment source information and user information associated with an account;
Receiving a mobile payment instruction, the mobile payment instruction comprising information identifying a payment source for payment and a payee for the payment performed by a stored value (SV) card payment method; Computer implementation steps;
A computer-implemented step of determining information corresponding to the identified payee to receive the payment and information indicating payment by a stored value ( SV ) card payment method in response to receiving the mobile payment instruction; ,
The determining step is responsive to receiving the mobile payment instruction including the payment source, the payment instruction recipient identified in the payment instruction from information pre-stored in the mobile money transaction system ( MFTS ) database. Further comprising retrieving information corresponding to the account selected in
Generating a mobile money transaction system ( MFTS ) payment instruction for a payment instruction recipient maintaining a relationship with a stored value ( SV ) card entity, wherein the mobile money transaction system ( MFTS ) payment instruction includes the amount, A computer-implemented step comprising at least information corresponding to the identified payee, information corresponding to a potential payment by a stored value ( SV ) card payment method, and information corresponding to the account;
A computer-implemented step of communicating the mobile money transaction system ( MFTS ) payment instruction from the mobile money transaction system ( MFTS ) to the payment instruction recipient;
A mobile money transaction system ( MFTS ) including mobile money transaction system (MFTS) software with program code for executing
A system whereby payment to the identified payee is accomplished by a stored value (SV) card.   24. The system of claim 23, wherein the user information identifying a payee comprises identifying a payee from one of a plurality of pre-stored names.   24. The system of claim 23, wherein the user information identifying a payee comprises identifying the payee by a payee mobile number. 24. The system of claim 23, wherein the payment instruction recipient is one of a financial service provider, a billing aggregator, a stored value (SV) card issuer, or a retailer that handles stored value (SV) cards. 24. The mobile money transaction system ( MFTS ) software is further operative to wirelessly communicate information to the payee notifying that a payment with a stored value ( SV ) card is acceptable. System.   24. The method of claim 23, wherein the selection of a payment source for performing a payment includes a selection of a financial service provider and a selection of a particular account associated with the selected financial service provider for performing the payment. The described system. When a payment source selection causes the mobile money transaction system ( MFTS ) to retrieve current account information from one or more financial service providers and receive such information from the one or more financial service providers 24. The system of claim 23, wherein the current account information is communicated wirelessly to the mobile device. The mobile money transaction system ( MFTS ) stores transaction information corresponding to a user's money transaction, and the transaction information includes payment information in addition to other information utilized to track the status of the payment. 24. The system of claim 23, comprising:   The transaction information is one or more of the following information items: one or more of a user ID number, transaction identifier, amount, financial service provider identifier, account identifier, payee identifier, incomplete / completed flag. 32. The system of claim 30, comprising: 24. The system of claim 23, wherein the mobile money transaction system ( MFTS ) receives a payment confirmation message from the payment instruction recipient in response to completion of a predetermined stage in performing the payment. 33. The mobile money transaction system ( MFTS ) software is further operative to wirelessly communicate a payment confirmation message to the mobile device in response to receiving the payment confirmation message from the payment instruction recipient. The system described in. The mobile money transaction system ( MFTS ) is further coupled for electronic communication with a user's computer via a data communication network such as the Internet, the mobile money transaction system ( MFTS ) software,
Provide web applications,
Receiving via the web application user information corresponding to a financial service provider, an account at the financial service provider, and a billing entity;
Storing the user information entered via the web application in a mobile money transaction system ( MFTS ) database for use in connection with payments initiated via a user mobile device;
24. The system of claim 23, further operating as follows. The mobile money transaction system ( MFTS ) software is further operable to retrieve transaction information corresponding to transactions executed via the user mobile device via the web application and display to the user on the user's computer. 35. The system of claim 34. Information corresponding to the payee's existing value storage ( SV ) card is stored in a mobile money transaction system ( MFTS ) database and is wirelessly transmitted to the user mobile device for display to the user and confirmation by a user command. 36. The system of claim 35, wherein the system is communicated. The mobile money transaction system ( MFTS ) software is
24. The method of claim 23, further operative to wirelessly communicate to the payee's mobile device a message notifying the payee that a payment has been sent by the user via a stored value ( SV ) card. System.   38. The system of claim 37, wherein the message to the payee's mobile device comprises a text message.   38. The system of claim 37, wherein the message to the payee's mobile device is provided via a mobile wallet application installed on the payee's mobile device. Wherein said selected manner payee can receive payment via a stored value (SV) card, fill the payment credited existing stored value (SV) card payee, and new 38. The system of claim 37, comprising issuing a stored value ( SV ) card. In response to the instruction by the payee of receipt of payment via a new value storage ( SV ) card,
The payee's mobile device displays a data entry screen for receiving input of information for identifying the location of receipt of the new value storage ( SV ) card;
Receiving payee input of information for identifying the receiving location of the new value storage ( SV ) card;
Wirelessly communicating the location information to the mobile money transaction system ( MFTS ) ;
A specific retailer in which the mobile money transaction system ( MFTS ) software is available to the new value storage ( SV ) card in response to a payee input of information identifying where to receive the new value storage ( SV ) card Wirelessly communicating information identifying the facility to the payee,
41. The system of claim 40. The mobile money transaction system ( MFTS ) software allows the value storage ( SV ) card issuer to issue a card to the payee, and the retail facility that provides the value storage ( SV ) card stores the value ( The SV ) further operates to communicate card receipt information to the stored value ( SV ) card issuer that further enables verification of the payee's identity for card receipt. system. 43. The system of claim 42, wherein the card receipt information comprises a transaction number provided by the mobile money transaction system ( MFTS ) associated with the payment, a card number, and a mobile phone number associated with the payee. . 43. The system of claim 42, wherein the mobile money transaction system ( MFTS ) software is further operative to communicate the card receipt information to the payee's mobile device. A method for making a financial payment to a payee via a connected user stored value by using the mobile device (SV) card for communicating over wireless network,
Receiving a mobile payment instruction in a mobile money transaction system (MFTS), the mobile payment instruction being executed by a payment source for payment and a stored value (SV) card payment method; Comprising information identifying a person, wherein said mobile money transaction system ( MFTS ) is coupled for communication with a payment instruction recipient capable of issuing a stored value ( SV ) card to a payee;
In response to receiving the mobile payment instruction, determining information corresponding to the identified payee to receive the payment and information indicating payment by a stored value ( SV ) card payment method; Prepared,
The mobile money transaction system ( MFTS ) includes a mobile money transaction system (MFTS) database for storing payment source information and user information associated with at least one account associated with at least one payment instruction recipient. ,
The determining step is responsive to receiving the mobile payment instruction including the payment source, the payment instruction recipient identified in the payment instruction from information pre-stored in the mobile money transaction system ( MFTS ) database. Further comprising retrieving information corresponding to the account selected in
Thereby, the mobile money transaction system ( MFTS ) communicates a payment order to a payment order recipient and achieves payment to the identified payee via a stored value (SV) card;
The payment instruction communicated to the payment instruction recipient by the mobile money transaction system ( MFTS ) includes an amount, information corresponding to the identified payee, and potential payment by a stored value ( SV ) card payment method. At least corresponding information and information corresponding to the account,
Method.   46. The method of claim 45, wherein the user information identifying a payee comprises identifying a payee from one of a plurality of names pre-stored on the mobile device.   46. The method of claim 45, wherein the user information identifying a payee comprises identifying the payee by a payee mobile number. 46. The method of claim 45, wherein the payment instruction recipient is one of a financial service provider, a billing aggregator, a stored value (SV) card issuer, or a retailer that handles stored value (SV) cards.   46. The method of claim 45, wherein the selection of a payment source for performing a payment includes a selection of a financial service provider and a selection of a particular account associated with the selected financial service provider for performing the payment. The method described. When a payment source selection causes the mobile money transaction system ( MFTS ) to retrieve current account information from one or more financial service providers and receive such information from the one or more financial service providers 46. The method of claim 45, wherein the current account information is communicated wirelessly to the mobile device. The information corresponding to the payee existing stored value (SV) card, are saved in a mobile financial transaction system (MFTS) database, wirelessly transmitted to the user mobile device for confirmation by the display and user commands to said user 46. The method of claim 45, wherein: Computer for a mobile financial transaction system to achieve a financial payment to a payee via a connected user stored value in response to a mobile device (SV) card for communicating over a wireless network (MFTS) An implementation method comprising:
Wirelessly receiving a mobile payment instruction from a mobile device, wherein the mobile payment instruction is information identifying a payee for payment performed by a stored value (SV) card payment method; A payment source, including at least information and an amount corresponding to the stored value (SV) card payment method;
In response to receiving the mobile payment instruction, determining information corresponding to the identified payee for receiving the payment, and information indicating payment by the stored value ( SV ) card payment method;
The mobile money transaction system ( MFTS ) includes a mobile money transaction system (MFTS) database for storing payment source information and user information associated with at least one account associated with at least one payment instruction recipient. ,
The determining step is responsive to receiving the mobile payment instruction including the payment source, the payment instruction recipient identified in the payment instruction from information pre-stored in the mobile money transaction system ( MFTS ) database. Further comprising retrieving information corresponding to the account selected in
Generating a mobile money transaction system ( MFTS ) payment instruction for a payment instruction recipient maintaining a relationship with a stored value ( SV ) card entity, wherein the mobile money transaction system ( MFTS ) payment instruction includes the amount, Including at least information corresponding to the identified payee, information corresponding to a potential payment by a stored value ( SV ) card payment method, and information corresponding to the account;
Communicating the mobile money transaction system ( MFTS ) payment instruction from the mobile money transaction system ( MFTS ) to the payment instruction recipient to achieve payment to the identified payee by a stored value (SV) card; When,
A method comprising: 53. The method of claim 52, wherein the mobile payment instruction includes information identifying a payee as one of a plurality of names pre-stored in the mobile money transaction system ( MFTS ) .   53. The method of claim 52, wherein the mobile payment instruction includes information identifying a payee by mobile number. 53. The method of claim 52, wherein the payment instruction recipient is one of a financial service provider, a billing aggregator, a stored value (SV) card issuer, or a retailer that handles stored value (SV) cards. 53. The method of claim 52, further comprising: wirelessly communicating to the payee information notifying that payment by a stored value ( SV ) card is acceptable.   53. The method of claim 52, wherein the selection of a payment source for performing a payment includes a selection of a financial service provider and a selection of a particular account associated with the selected financial service provider for performing the payment. The method described. When a payment source selection causes the mobile money transaction system ( MFTS ) to retrieve current account information from one or more financial service providers and receive such information from the one or more financial service providers 53. The method of claim 52, wherein the current account information is communicated wirelessly to the mobile device. The mobile money transaction system ( MFTS ) stores transaction information corresponding to a user's money transaction, and the transaction information includes payment information in addition to other information utilized to track the status of the payment. 54. The method of claim 52, comprising.   The transaction information is one or more of the following information items: one or more of a user ID number, transaction identifier, amount, financial service provider identifier, account identifier, payee identifier, incomplete / completed flag. 60. The method of claim 59, comprising: 53. The method of claim 52, further comprising receiving a payment confirmation message from the payment instruction recipient at the mobile money transaction system ( MFTS ) in response to completion of a predetermined stage in performing the payment.   62. The method of claim 61, further comprising: wirelessly communicating a payment confirmation message to the mobile device in response to receiving the payment confirmation message from the payment instruction recipient. The mobile money transaction system ( MFTS ) is further coupled for electronic communication with a user's computer via a data communication network such as the Internet;
Providing a web application associated with the mobile money transaction system ( MFTS ) ;
Receiving via the web application user information corresponding to a financial service provider, an account at the financial service provider, and a billing entity;
Storing the user information entered via the web application in a mobile money transaction system ( MFTS ) database for use in connection with payments initiated via a user mobile device;
53. The method of claim 52, further comprising:   64. The method of claim 63, further comprising retrieving transaction information corresponding to a transaction performed via the user mobile device via the web application and displaying to the user on the user's computer. Information corresponding to the existing stored value (SV) card payee are stored in a mobile financial transaction system (MFTS) database, is transmitted wirelessly to the user mobile device for confirmation by the display and user commands to said user 53. The method of claim 52. 53. The method of claim 52, further comprising wirelessly communicating a message to the payee's mobile device notifying the payee that a payment has been sent by a user via a stored value ( SV ) card. .   68. The method of claim 66, wherein the message to the payee's mobile device comprises a text message.   68. The method of claim 66, wherein the message to the payee's mobile device is provided via a mobile wallet application installed on the payee's mobile device. Wherein said selected manner payee can receive payment via a stored value (SV) card, fill the payment credited existing stored value (SV) card payee, and new 68. The method of claim 66, comprising issuing a stored value ( SV ) card. In response to the instruction by the payee of receipt of payment via a new value storage ( SV ) card,
Wherein in response to payee input of the new stored value (SV) information identifying the receiving location of the card, information identifying the new stored value (SV) particular retail facility card available the payee 70. The method of claim 69, further comprising: wirelessly communicating. The stored value (SV) allows the card issuer to issue a card to the payee, a stored value (SV) the payee for retail facility is a stored value (SV) card receipt to pay the card 70. The method of claim 69, further comprising: communicating card receipt information to the stored value ( SV ) card issuer that further enables verification of the identity of the card. 72. The method of claim 71, wherein the card receipt information comprises a transaction number provided by the mobile money transaction system ( MFTS ) associated with the payment, a card number, and a mobile phone number associated with the payee. .   72. The method of claim 71, further comprising wirelessly communicating the card receipt information to the payee's mobile device. A system for a user to achieve a stored value (SV) card payment in response to communication from a mobile device connected for communication with a wireless network, comprising:
A mobile money transaction system (MFTS) coupled for wireless communication with one or more mobile devices of a user using a mobile communication service provider (MCSP), the mobile money transaction system ( MFTS ) comprising: Coupled for electronic communication with a payment instruction recipient that achieves payment via a stored value (SV) card, the mobile money transaction system ( MFTS ) is associated with at least one payment instruction recipient. A mobile money transaction system (MFTS) database for storing payment source information and user information associated with an account;
Comprising: receiving a mobile payment instruction wirelessly from a mobile device, the mobile payment instruction includes information identifying a payee for a payment to be executed by a stored value (SV) card payment method, for the payment A computer-implemented step comprising at least a payment source, information and an amount corresponding to the stored value (SV) card payment method;
A computer-implemented step of determining information corresponding to the identified payee to receive the payment and information indicating payment by a stored value ( SV ) card payment method in response to receiving the mobile payment instruction; ,
The determining step is responsive to receiving the mobile payment instruction including the payment source, the payment instruction recipient identified in the payment instruction from information pre-stored in the mobile money transaction system ( MFTS ) database. Further comprising retrieving information corresponding to the account selected in
Generating a mobile money transaction system ( MFTS ) payment instruction for a payment instruction recipient maintaining a relationship with a stored value ( SV ) card entity, wherein the mobile money transaction system ( MFTS ) payment instruction includes the amount, A computer-implemented step comprising at least information corresponding to the identified payee, information corresponding to a potential payment by a stored value ( SV ) card payment method, and information corresponding to the account;
A computer-implemented step of communicating the mobile money transaction system ( MFTS ) payment instruction from the mobile money transaction system ( MFTS ) to the payment instruction recipient;
A mobile money transaction system ( MFTS ) , including mobile money transaction system ( MFTS ) software with program code for executing
A system whereby payment to the identified payee by a stored value (SV) card is achieved. 75. The system of claim 74, wherein the mobile payment instruction includes information identifying a payee as one of a plurality of names pre-stored in the mobile money transaction system ( MFTS ) .   75. The system of claim 74, wherein the mobile payment instruction includes information identifying a payee by mobile number. 75. The system of claim 74, wherein the payment instruction recipient is one of a financial service provider, a billing aggregator, a stored value (SV) card issuer, or a retailer that handles stored value (SV) cards. 75. The mobile money transaction system ( MFTS ) software is further operative to wirelessly communicate to the payee information notifying that a payment with a stored value ( SV ) card is acceptable. System.   75. The method of claim 74, wherein the selection of a payment source for performing a payment includes a selection of a financial service provider and a selection of a particular account associated with the selected financial service provider for performing the payment. The described system. The mobile money transaction system ( MFTS ) communicates with the financial service provider to obtain updated account balance information for the account;
The mobile money transaction system ( MFTS ) wirelessly communicates updated account balance information from the mobile money transaction system ( MFTS ) to a user mobile device;
Thereby, in response to receiving updated account balance information from the mobile money transaction system ( MFTS ) , the mobile device displays updated account balance information corresponding to the account to the user;
80. The system of claim 79. When a payment source selection causes the mobile money transaction system ( MFTS ) to retrieve current account information from one or more financial service providers and receive such information from the one or more financial service providers 80. The system of claim 79, wherein the current account information is communicated wirelessly to the mobile device. Information corresponding to the payee's existing value storage ( SV ) card is stored in a mobile money transaction system ( MFTS ) database and transmitted wirelessly to the user mobile device for display to the user and confirmation by a user command. 80. The system of claim 79. The mobile money transaction system ( MFTS ) stores transaction information corresponding to a user's money transaction, and the transaction information includes payment information in addition to other information used to track the status of the payment. 75. The system of claim 74, comprising:   The transaction information is one or more of the following information items: one or more of a user ID number, transaction identifier, amount, financial service provider identifier, account identifier, payee identifier, incomplete / completed flag. 84. The system of claim 83, comprising: 75. The mobile money transaction system ( MFTS ) software is further operative to receive a payment confirmation message from the payment instruction recipient in response to completion of a predetermined stage in performing the payment. The described system. 86. The mobile money transaction system ( MFTS ) software is further operative to wirelessly communicate a payment confirmation message to the mobile device in response to receiving the payment confirmation message from the payment instruction recipient. The system described in. The mobile money transaction system ( MFTS ) is further coupled for electronic communication with a user's computer via a data communication network such as the Internet;
Wherein a web application associated with a mobile financial transaction system (MFTS), financial services provider, operates the user information as received via the web application corresponding to the account, and billing entities in the financial service provider, A web application,
The mobile money transaction system ( MFTS ) software stores the user information entered via the web application in a mobile money transaction system ( MFTS ) database for use with payments initiated via a user mobile device. To work further,
75. The system of claim 74. The mobile money transaction system ( MFTS ) software is further operable to retrieve transaction information corresponding to transactions executed via the user mobile device via the web application and display to the user on the user's computer. 90. The system of claim 87. Wherein the mobile financial transaction system (MFTS) software, information the mobile corresponding to the account number of the existing stored value (SV) card of the payee in order to fill in the credit of the existing stored value (SV) card of the payee 75. The system of claim 74, further operative to receive from a device. The mobile money transaction system ( MFTS ) software is
75. The apparatus of claim 74, further operative to wirelessly communicate to the payee's mobile device a message notifying the payee that a payment has been sent by the user via a stored value ( SV ) card. System.   94. The system of claim 90, wherein the message to the payee's mobile device comprises a text message.   94. The system of claim 90, wherein the message to the payee's mobile device is provided via a mobile wallet application installed on the payee's mobile device. Wherein said selected manner payee can receive payment via a stored value (SV) card, fill the payment credited existing stored value (SV) card payee, and new 94. The system of claim 90, comprising issuing a stored value ( SV ) card. The mobile money transaction system ( MFTS ) software in response to an instruction by the payee to receive payment via a new value storage ( SV ) card;
Wherein in response to payee input of the new stored value (SV) information identifying the receiving location of the card, information identifying the new stored value (SV) particular retail facility card available the payee 94. The system of claim 93, further operative to communicate wirelessly. The mobile money transaction system ( MFTS ) software allows the value storage ( SV ) card issuer to issue a card to the payee, and the retail facility that provides the value storage ( SV ) card stores the value ( 94. The method of claim 93, further operative to communicate card receipt information to the stored value ( SV ) card issuer further enabling identification of the payee's identity for SV ) card receipt. system. 96. The system of claim 95, wherein the card receipt information comprises a transaction number provided by the mobile money transaction system ( MFTS ) associated with the payment, a card number, and a mobile phone number associated with the payee. . 96. The system of claim 95, wherein the mobile money transaction system ( MFTS ) software is further operative to wirelessly communicate the card receipt information to the payee's mobile device.

Images