RU2520410C2 - Methods and systems for financial transactions in mobile communication environment - Google Patents

Abstract

FIELD: radio engineering, communication.

SUBSTANCE: invention relates to means of conducting financial transactions in a mobile communication environment using a mobile device. The method employs a mobile financial transaction system (MFTS) which stores user and transaction information. The MFTS receives information on bills to pay and information corresponding to payment sources of a user. Said information is transmitted to the user via a wireless network which generates a mobile payment instruction which includes a payment and a payment source. The instruction is transmitted to the MFTS, where an instruction is generated for the payment instruction recipient to make a payment to an identified payment recipient. The mobile device is configured to implement the method.

EFFECT: safer financial operations in a mobile environment using a card with a set limit of funds.

32 cl, 42 dwg

Description

CROSS REFERENCE TO RELATED APPLICATIONS

This application is related to and includes in the materials of this application by reference the following applications for the grant of US patents:

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

Application No. 11/428859, entitled "Methods and Systems for Making a Payment via a Paper Check in a Mobile Environment", registered on July 6, 2006;

Application No. 11/428860, entitled “Methods and Systems for Making a Payment via a Stored Value Card in a Mobile Environment”, registered on July 6, 2006 of the year,

Application No. 11/428861, entitled “Methods and Systems for Viewing Aggregated Payment Obligations in a Mobile Environment”, registered on July 6, 2006,

Application No. 11/428864, entitled “Methods and Systems for Providing a Payment in a Mobile Environment”, registered on July 6, 2006,

Application No. 11/428866, entitled “Methods and Systems for Managing Payment Sources in a Mobile Environment”, registered on July 6, 2006,

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

Application No. 11/428874, entitled "Methods and Systems for Distribution of a Mobile Wallet for a Mobile Device" ("Methods and systems for distributing a mobile wallet for a mobile device"), registered July 6, 2006,

Application No. 11/428876, entitled "Methods and Systems for Indicating a Payment in a Mobile Environment", registered on July 6, 2006,

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

FIELD OF THE INVENTION

The present invention generally relates to financial transactions, and more specifically, relates to methods and systems for conducting financial transactions in a mobile communication environment using a mobile device, such as a mobile phone (cell phone), or a wirelessly connected personal digital assistant (PDA) .

BACKGROUND OF THE INVENTION

Active consumers in mobile communities seek to maximize the use of their time. Electronic devices such as personal digital assistants (“PDAs”) and mobile phones (“cell phones”) portend a more efficient use of time, providing the ability to connect with other people and organizations wherever the user goes. One of the specific requirements of mobile consumers is the best ability to manage their financial condition, such as bank balances, credit cards, other sources of funds, etc., and quickly but efficiently fulfill financial obligations, such as paying bills, transferring money. funds to third parties and family members, etc. Several useful World Wide Web and personal computer (PC) programs of financial services are available to consumers and businesses. These include the popular QUICKEN ™ product from Intuit, a legal entity, MICROSOFT MONEY from Microsoft, and others.

However, these World Wide Web and PC-based solutions for financial management of payments and money require that users have access to a networked PC. A PC may not always be easily accessible to a mobile consumer when he or she needs to pay a bill. But a mobile device, such as a phone or PDA, is more likely to be available. (Modern mobile devices are so ubiquitous that the average consumer will find out in about 6 minutes if he has lost his cell phone, but about 18 minutes before he realizes that he has lost his traditional wallet).

Consumers in mobile communities tend to wear a variety of personal items such as keys, wallets, cards, and electronic devices. Currently widely used electronic devices include mobile phones, PDAs, MP3 players, or other types of music players (e.g. APPLE iPOD ™) and personal video players (also APPLE iPOD ™). Such electronic devices come close in terms of functionality, but the average consumer of the mobile community has a tendency to wear too many other personal property, such as a wallet, checkbook, numerous credit cards, membership cards, discount (storage) cards, keys, etc. Further consolidation and convergence of electronic and mobile communications devices is expected in the future to mitigate some of the clutter of personal property, but the current communications and financial services infrastructure is still lacking in the need for efficient mobile financial transactions and a decrease in clutter of personal property.

Unfortunately, the modern technology of mobile devices and the infrastructure of financial services do not provide convenient, safe and quick service of the financial needs of a person in a mobile environment. In order to enable a mobile device, such as a cell phone or PDA, to be successfully used for mobile financial transactions, certain transaction-specific functionality is important. A person’s financial payment obligations arise from many sources - paying bills and mortgages, sending money, making purchases at the point of sale (POS) of a retailer, etc. Such obligations may involve dozens (or more) of different entities. Different entities may require different forms of payment. Mobile financial transaction systems that are attractive to mobile consumers would provide for the aggregation and consolidation of payment obligations and would provide a choice of payment media such as checks, direct money transfers, use of a credit card account, etc. (SV) cards with a pledged limit of funds are an increasingly popular payment option in some communities, especially the so-called “non-bank” ones (that is, people who may not have an open bank account and want to do business in cash).

Similarly, a person can have multiple sources of payments and cash - credit cards, demand type bank accounts and savings, debit cards, etc. People often have preferences regarding which sources of funds should be used to pay for certain payment obligations. A bank account may be required for some payments, while a credit card may be required for other transactions, for many reasons, such as participating in loyalty programs such as frequent user programs. Before using a specific source of funds for payment, the consumer often has a need or wants to receive information about the available cash balance or credit balance. Some form of request for an account balance and, possibly, updating information about the balance in real time from a mobile device is desirable. In addition to information about balances, it is advisable to call up other operations of financial institutions while moving around. Such other operations include the transfer of funds between accounts, the selection of different sources of payments or accounts from a specific financial institution, money transfer and payment, request and repayment of loans, and the like, anytime, anywhere, without requiring a personal appearance in a banking service building or at a PC terminal with the ability to connect to the Internet.

Some online financial services providers, such as CheckFree , offer a service known as “bill aggregation” or “bill invoice”, whereby multiple payment obligations are collected in a centralized data center and presented to the consumer as a list. For example, US Pat. No. 6,289,322 to Kitchen and others describes a method for electronically presenting billing information that may be used in connection with “online billing for payment”. This method includes receiving billing information for payment associated with a plurality of different billing providers for payment, different portions of which represent billing for different people (as payers). Billing information for payment is consolidated for each registered user or payer. Individual consumers can go to the Internet site to register an invoice, add information about invoicing providers to pay, add information about financial institutions, and pay bills online. However, the system described in US Pat. No. 6,289,322 is intended for users with access via a PC and the Internet, and has several drawbacks for use in a mobile communication environment. One of the specific drawbacks is that the Internet-based user interface actually provides too much information about the user’s accounts and the details of the bill for payment, and is difficult to view and navigate on small mobile devices. Another drawback is the lack of integration of interactive bill payment using numerous and conveniently selected different payment sources.

Published application No. 20050086164 for the grant of a US patent for Kim and others describes a method for using a mobile phone to pay for the costs of goods or services executed by permission of a mobile telephone network. First of all, the buyer uses his or her mobile phone to join the payment transaction server. The identification code (for each) of the buyer and the “trading warehouse”, and the invoice for payment for goods or services is transmitted to the payment transaction server. The payment transaction server checks the data received from the mobile phone and determines the permission based on the balance corresponding to the customer’s identification code. When permitted, a notice of permission is sent to the terminal at the warehouse. After confirmation from the notice of permission at the commercial warehouse, the buyer receives goods or services.

The system, as described in the publication of Kim and others , depends on the presence of a predefined balance on the prepaid account opened by the buyer with mobile phone networks. Moreover, the method includes delivering voice prompts to a user via a mobile phone and receiving a user-selected menu item by activating buttons on a keypad of the mobile phone. Despite the fact that such a device and system are undoubtedly one of the ways that financial transactions can be carried out using a mobile phone, the well-known method of voice prompts for entering data from the keypad is slow and inconvenient to use, and is a well-known source of customer dissatisfaction. . Moreover, modern devices are more than just a telephone — many of these devices now include display devices, controls and keypads, and provide more ways to communicate wirelessly than voice messages and invitations.

Mobile devices and systems have already advanced far beyond the limitations of voice prompts, as well as entering data and selecting menu items from the telephone keypad. The first generation (1G) of mobile telephony systems was limited to analog voice broadcasting, and was surpassed by second-generation (2G) systems, which provide features for transmitting digital signals and utilize great functionality. Real communication systems for mobile devices (in excess of 2G) are now fully digital and use data channels to carry voice signals, as well as other information signals. Signs involved in the transmission of digital data include messages of the short messaging system (SMS) for exchanging text messages, downloading ringtones for the phone, and other signs. Consumer-oriented mobile communication systems are now moving beyond advanced second-generation (2.5G) technologies to third-generation (3G) technologies that provide high-speed broadband data connections for mobile devices. New 3G systems and devices allow for features such as the full use of the Internet on mobile devices, the ability to exchange SMS messages, direct call to a specific subscriber, the direct download of content such as ringtones, music and video, and many other signs.

Significantly, modern mobile devices now include the extremely close capabilities of the PDA and the phone. The new mobile devices feature color display devices, touch screens, abundant telephone capabilities, as well as music, streaming video, storage memory (for example, memory cards), wireless headsets, infrared data connections, and many other features. A system that facilitates convenient, safe and fast mobile financial transactions will invariably take advantage of the available operating frequency band of the communication channel and the features of devices in modern 2.5G and 3G networks and their devices. However, prior to the present invention, there was no effective attempt to identify the generalized methods and signs of use that the consumer wants — those that provide convenient, safe and fast mobile financial transactions, in some way that are consumer-friendly and provide an opportunity to reduce the clutter of personal property.

In particular, consumers require strict security when using their devices. They require a quick, convenient check if used at a point of sale (POS) retailer. They should be able to “Pay Anyone,” at any given time, in any number of different ways. They should be supplied with the information that they need to conduct - and only with the information that is needed - and this information should be up to date. Similarly, financial institutions require strong security, which includes authentication, for transactions initiated in a mobile communication environment. There should be a prospect for revenue opportunities as well as user retention. There should be an opportunity to reduce customer service costs through the use of automation. For retailers and entities that send invoices for payment, there should be a quick payment. Any POS transactions must be paid quickly. Credit card and debit card costs must be authenticated and quickly covered - preventing and suppressing fraud is paramount for financial institutions, as well as for invoicing entities and other payees. Facilitation, or at least compatibility with consumer loyalty programs, is highly desirable.

All of these requirements — some of which are only desirable and some absolutely necessary — present a challenge for today's mobile communications and financial services infrastructure. Prior to the present invention, no system has been made that meets all these characteristics, goals and needs of a mobile-based financial transaction system in a satisfactory manner.

Therefore, there is a need for a comprehensive solution that provides consumers using mobile devices with the opportunity to consolidate their bills and other payment obligations, pay such bills and other obligations anytime, anywhere, anywhere, using any selectable available funds, in respect of retailers for goods and services, or in relation to any or any other designated entity, with knowledge of the amounts to be paid and available Inventory of cash balances. And, of course, all of this should be convenient, safe and fast.

As will be described in more detail and explained below, the authors of the present invention have come up with various systems and methods for performing financial transactions in a mobile communication environment that satisfy these and other requirements for an effective, rational, reliable, safe and convenient solution.

SUMMARY OF THE INVENTION

The briefly described present invention relates to methods and systems for conducting financial transactions in a mobile communication environment using a mobile device, such as a mobile phone or wirelessly connected personal digital assistant, which communicates with a mobile financial transaction system that stores user information and information about the transaction. In particular, the present invention relates to methods and systems for payment transactions in a mobile communication environment.

Aspects of the invention are embodied in mobile devices, in software for mobile devices (for example, in the form of computer-implemented methods), in a mobile financial transaction system (MFTS), in software for mobile financial transaction systems (for example, in the form of computer-implemented methods), in systems that combine aspects of mobile devices and mobile financial transaction systems, and in software for such systems (for example, in the form of software for mobile devices and related systems that implement computer-implemented methods).

In one of the main aspects, the present invention relates to a method for making mobile financial payments using a mobile device connected to exchange information with a wireless network. The method comprises the steps of: (i) preparing a mobile financial transaction system (MFTS); (ii) receiving payment information for production at the MFTS corresponding to a payment to be made by the user to the payee; (iii) generating summary information about payments for production in the MFTS based on information about payments for production; (iv) wirelessly transmitting payment summary information for production from MFTS to a user mobile device via MCSP; and (v) displaying information corresponding to one or more selectable payments for production on a user mobile device. Such selectable payments for production include summary information about payments for production associated with the payee. The method further comprises the steps of: (vi) on a user mobile device, receiving user input corresponding to the selection of a payment for production and selecting a payment source for making a payment; (vii) on a user’s mobile device, in response to user input, generating a mobile payment order containing information corresponding to the selected payment for production and the selected payment source for the payment corresponding to the selected payment for production; and (viii) wirelessly transmitting the mobile payment order from the user mobile device to the MFTS.

According to this aspect of the invention, the method further comprises the steps of: (ix) in the MFTS and in response to receiving the mobile payment order, extracting information from the MFTS database corresponding to the identified payee to receive the payment indicated by the mobile payment order, and information corresponding to the selected account at the selected financial service provider identified in the mobile payment order. The method further comprises the steps of: (x) in the MFTS, generating the MFTS payment order to the recipient of the payment order; and (xi) transmitting the MFTS payment order from the MFTS to the selected recipient of the payment order. The recipient of the payment order, in response to receiving the payment order of the MFTS, makes a payment to the identified payee.

In a preferred embodiment, the MFTS is connected, for exchanging information, with a user's mobile device using a mobile service provider (MCSP). MFTS, moreover, is associated, for the exchange of information, with one or more recipients of a payment order, which can make a payment to the payee on behalf of the user. The MFTS includes an MFTS database for storing user information, payment information for production, associated with one or more recipients of the payment order and / or payment recipients, and information about the sources of payments associated with at least one account, associatively associated with at least one financial service provider. In one aspect, the payment information for the production comprises an invoice for payment, and the payee is the invoicing entity. In yet another aspect, the recipient of a payment order is one of a financial services provider, a billing aggregator, or a separate billing entity.

Another aspect of the invention includes preparing a Mobile Wallet application on a user mobile device. The Mobile Wallet application is a mobile device application that provides functionality for viewing and selecting accounts to be paid, or other payments for making, viewing and selecting payment sources for making such payments, viewing balances, etc. In one aspect, the Mobile Wallet application provides for displaying on a mobile device selectable commands, including one or more of the View Bills command, the View Payment Sources command, the Pay Bill command (a) (Pay Bill) and Pay Anyone teams. In an exemplary aspect, the View invoice for payment command provides the user with a means to view and / or select a payment for production. The selected View billing team prompts MFTS to retrieve billing information from the billing system and transfer the billing summary information to the mobile device after receiving such information from the billing system.

In a related aspect, the View Payment Sources command provides the user with a means to view and / or select a payment source for making a payment. The selection of a payment source for making a payment includes the selection of a financial services provider and the selection of a specific account associated with the selected financial services provider for making a payment. The team to review payment sources also prompts the MFTS to retrieve current account information from one or more financial service providers and transmit current account information to a mobile device after receiving such information from one or more financial service providers.

In a related aspect, the Pay Bill (a) command provides the user with the means to pay the bill or other payment to another entity for which the user has a financial obligation, such as a mortgage payment. In yet another related aspect, the Pay Any command provides a user of a mobile device with a means to make a payment to any person, regardless of the previous payment invoice or other information supplied to the MFTS, for example, by entering the name of the payee and / or mobile number of the payee.

According to yet another aspect of the invention, payment information for production is supplied to the MFTS by an external source. An external source may be one or more of a billing system that delivers billing information from a plurality of billing entities or a separate billing entity. Information can be entered by the user through an Internet accessible website accessible to the user, or via a mobile device to enter payment information for production and information about payment recipients.

According to yet another aspect, the payment information for the production comprises information corresponding to one or more of the following: a periodic bill payable, a bill payable from a bill billing aggregator, a bill payable from a separate billing company, and / or payment "pay anyone." According to an aspect of the invention, information corresponding to one or more payments for production displayed on a user mobile device is provided in response to a user activating the function “View invoices for payment”. This display of information occurs in response to a text message from the MFTS received on the mobile device. Such a display of information includes a summary of invoices payable from MFTS. Summary information about payments for production includes a predetermined selected subset of information about payments for production.

In yet another aspect, an MFTS payment order includes information identifying a selected account with a selected financial service provider, an amount, and information corresponding to an identified payee. The identified payee may be a billing entity that transmitted the billing information to the MFTS, or another entity that may be billed. In one embodiment, the summary payment information for production transmitted to the mobile device consists of the payee ID, amount and due date, so that only minimal information is transmitted from the MFTS to the mobile device. In this aspect, the mobile device uses the payee identifier in the payment summary information for production and retrieves the payee name information from the local memory of the mobile device corresponding to the identified payee and displays the payee name information to the user.

In one embodiment, the MFTS database also stores transaction information corresponding to a user's financial transactions. Transaction information includes information about payments for production, in addition to other information used to track the status of payments for production, along with one or more of the following information elements: user ID number, transaction ID, date of payment accepted, payment due date invoice for payment, amount, financial service provider identifier, account identifier, payee identifier and / or flag sign of waiting / completion.

In one embodiment, the method further comprises the step of transmitting a payment confirmation message from the recipient of the payment order to the MFTS in response to the completion of a predetermined stage when making a payment. In yet another embodiment, the method further comprises the step of sending the payment confirmation message to the mobile device in response to receiving the payment confirmation message from the recipient of the payment order.

Another aspect of the invention relates to the selection of a payment method for making a payment. According to this aspect, the method further comprises the steps of receiving user input corresponding to the selection of a payment method for making a payment on a user mobile device, and includes information in a mobile payment order corresponding to the selected method for making a payment on a user mobile device in response to the user input. Selectable payment methods include the method determined by the recipient, in which the recipient determines the method of receiving payment, money transfer ACH (automatic clearing house), a paper check and a card with a fixed limit of funds (SV).

According to yet another aspect, the MFTS is furthermore connected, for electronic exchange of information, with a user's computer via a data network such as the Internet. The method according to this aspect comprises the steps of: (i) preparing an Internet application in association with the MFTS, (ii) receiving user information through an Internet application corresponding to financial service providers, accounts of financial service providers and payees, and (iii) storing user information entered through the Internet application in the MFTS database for use in connection with payments initiated by the user mobile device. In yet another embodiment, the method further comprises the steps of retrieving and displaying transaction information corresponding to transactions conducted through a user’s mobile device, through an Internet application, to a user through a user's computer.

In one embodiment, a mobile financial payment may include transferring a balance from one account associatively associated with a user to another account associatively associated with the same user.

Another aspect of the invention relates to real-time updating of account information on a user's mobile device. The method according to this aspect comprises the steps of: (i) storing a cached account balance in a mobile device representing a balance in at least one user account as of a specific date, (ii) exchanging information with a financial service provider to obtain updated information about balances on account balances, (iii) wirelessly transmitting updated account balance information from MFTS to a user’s mobile device, and (iv) in response to receiving updated account balance information from MFTS, display updated information on account balances corresponding to the account to the user via a mobile device.

According to yet another aspect, the present invention relates to a system for making mobile financial payments using a mobile device connected to exchange information with a wireless network. In another aspect, the present invention relates to a method for making mobile financial payments using a mobile device connected to exchange information with a wireless network. In yet another aspect, the present invention relates to a mobile device for making mobile financial payments over a wireless network. In yet another aspect, the present invention relates to a computer-implemented method for a mobile financial transaction system (MFTS) to facilitate mobile financial payment initiated by a mobile device connected to exchange information with a wireless network. In yet another aspect, the present invention relates to a mobile financial transaction system (MFTS) for facilitating mobile financial payment initiated by a user mobile device connected to exchange information with a wireless network. In yet another aspect, the present invention relates to a method for making a financial payment to a payee via a paper check using a mobile device connected to exchange information over a wireless network.

Another aspect of the invention relates to methods and systems for making a financial payment to a payee using a paper check using a mobile device. The mobile device wirelessly communicates with the mobile financial transaction system (MFTS), which stores user information and transaction information. The user enters information through a mobile device that identifies the payee and indicates the method of payment by paper check. The mobile device generates a mobile payment order, which includes information corresponding to the identified payee and indicating the method of payment by paper check. The mobile payment order is transmitted to the MFTS wirelessly. The MFTS generates an MFTS payment order to the recipient of the payment order, which can issue a paper check. MFTS transfers the MFTS payment order to the recipient of the payment order, which prepares the payment for the identified payee by printing and mailing a paper check to the payee.

Another aspect of the invention relates to methods and systems for making a financial payment to a payee by means of a card with a pledged limit of funds (SV) using a mobile device. The mobile device wirelessly communicates with the mobile financial transaction system (MFTS), which stores user information and transaction information. The user enters information through a mobile device that identifies the payee and indicates the method of payment by card with a set limit on funds. The mobile device generates a mobile payment order, which includes information corresponding to the identified payee and indicating the method of payment by card with a fixed limit of funds. The mobile payment order is transmitted to the MFTS wirelessly. MFTS generates an MFTS payment order to the recipient of the payment order, who can issue a new card with a pledged limit of funds and / or reload funds to a previously existing card with a pledged limit of funds. MFTS transfers the MFTS payment order to the payee who prepares the payment for the identified payee by issuing a new card with a pledged limit or transferring funds to a pre-existing card with a pledged limit.

Another aspect of the invention relates to methods and systems for viewing aggregated financial liabilities using a mobile device. The mobile financial transaction system (MFTS) is connected for wireless information exchange with a user's mobile device. MFTS is also connected for electronic exchange of information with an aggregator, which collects information from a variety of payment recipients with whom the user has a financial relationship. MFTS accepts payment information for production from the aggregator, corresponding to the payment that must be made by the user to the payee. MFTS generates summary information about payments for production containing a predetermined selected subset of information about payments for production received from the aggregator. MFTS wirelessly transmits summary payment information for production to a user's mobile device. The payment summary is then displayed on the user's mobile device.

Another aspect of the invention relates to methods and systems for making a financial payment to a payee using a mobile device. The user enters information into the mobile device identifying the payee, the payment source for the payment, and the payment method. The mobile device generates a mobile payment order containing information corresponding to the identified payee, payment source and payment method, and wirelessly transfers the mobile payment order to the mobile financial transaction system (MFTS). MFTS generates an MFTS payment order to the recipient of the payment order. The MFTS payment order includes information identifying the source of payment, the amount, information corresponding to the identified payee, and information indicating the method of payment. MFTS transfers the MFTS payment order to the recipient of the payment order. In response to receiving the MFTS payment order, the payee receives the payment to the identified payee without any action required by the payee.

Another aspect of the invention relates to methods and systems for selecting a payment source for use in the manufacture of a mobile financial payment using a mobile device. The system of mobile financial transactions (MFTS) is connected, for electronic exchange of information, with one or more financial service providers with which the user supports one or more accounts, as well as for wireless exchange of information with mobile devices. The mobile device displays information corresponding to the accounts available to the user as a payment source for use in connection with making a payment using the mobile device. The user selects a payment source to make a payment. The mobile device generates a mobile payment order containing information relevant to the payment and the selected payment source. The mobile payment order is transmitted to the MFTS wirelessly. MFTS generates an MFTS payment order, which includes the amount, information corresponding to the identified payee, and information indicating the selected source of payment. The MFTS payment order is transmitted to the recipient of the payment order, which makes the payment using the selected payment source.

Another aspect of the invention relates to methods and systems for obtaining real-time account balance information for multiple financial accounts maintained with one or more financial service providers using a mobile device. The mobile financial transaction system (MFTS) is connected, for wireless exchange of information, with the user's mobile device, and is also connected, for electronic exchange of information, with one or more financial service providers in which the user supports one or more accounts. The mobile device stores a cached account balance, representing the balance in each account as of a specific date. MFTS liaises with financial service providers to obtain updated account balance information for user accounts. Updated account balance information is wirelessly transmitted 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 a plurality of user accounts.

Another aspect of the invention relates to methods and systems for distributing a mobile device application for use in the manufacture and receipt of payments using a mobile device. The downloadable mobile device application, when installed on a compatible mobile device, is operational for exchanging information with the Mobile Financial Transaction System (MFTS), which facilitates the production and receipt of payments via wireless mobile devices. The downloadable mobile device application is delivered through a download system that downloads the application to mobile devices according to download procedures suitable for a particular type of mobile device. When a payment is made to a payee having a mobile device, the system transmits a message to the payee’s mobile device, which reports that the payment has been made and informs the payee about the downloaded mobile device application. If the user / payee of the mobile device downloads and installs the mobile device application on his or her mobile device and provides registration information, the interaction between the MFTS user / payee of the mobile device is allowed, and the payment is delivered to the user of the mobile device as the user / payee.

Another aspect of the invention relates to methods and systems for making mobile financial payment using a mobile device. The mobile financial transaction system (MFTS) is connected, for wireless exchange of information, with the user's mobile device, and is also connected, for electronic exchange of information, with one or more recipients of payment orders, which can make a payment to the payee on behalf of the user. The mobile device provides for the selection of a pre-existing payee or entering information about the payee. The user provides input on a mobile device with the choice of the payee for the payment and the source of payment for the payment. A mobile payment order containing information corresponding to a payment for production and a payment source for payment is wirelessly transmitted to the MFTS. MFTS generates and transfers the MFTS payment order to the recipient of the payment order, which includes information identifying the selected account with the financial services provider, the amount, and information corresponding to the identified payee. The recipient of the payment order then pays the identified payee.

Another aspect of the invention relates to methods and systems for receiving financial payments facilitated by the use of a mobile device. The system of mobile financial transactions (MFTS) is connected, for wireless exchange of information, with the mobile device of the user / payee, and is also connected, for electronic exchange of information, with the recipient of the payment order, which makes payments in various ways. The system delivers the information corresponding to the accepted payment to the mobile device of the user / payee. The user / recipient of the payment displays information corresponding to the plurality of selectable payment methods available to receive payment. The user / payee provides the input on his / her mobile device corresponding to the choice of payment method for receiving payment. The mobile device generates a mobile payment order indicating the selected payment method, and wirelessly transfers the mobile payment order to the MFTS. MFTS generates and transfers the MFTS payment order, which includes the amount of the identified payee and the selected payment method, to the payee. The recipient of the payment order, in response to receiving the payment order MFTS, pays the user / payee using the selected payment method.

From the foregoing, those skilled in the art will understand and take into account that, with its various aspects for a mobile device, mobile financial transaction system, Internet interface and a combination of functionality, a system designed in accordance with aspects of the invention provides mobile device users unprecedented convenience and flexibility in controlling accounts payable for payment and other payments for production, information on current account balances, supplying real-time, and other improved functionality for users of mobile devices that were previously not possible at reasonable economic costs and convenience.

These and other aspects, features and advantages of the present invention (s) will become apparent from the subsequent detailed written description of the preferred embodiments, in combination with the following drawings, although variations and modifications may be made without departing from the spirit and scope of the novelty of the disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a high-level overview of exemplary aspects for a mobile financial transaction system (MFTS) that embodies aspects of the present invention.

FIG. 2 is a more detailed overview of an exemplary mobile financial transaction system (MFTS) according to an exemplary aspect of the invention.

FIG. 3 consisting of FIG. 3A and FIG. 3B is a computer software architecture diagram illustrating various modules of a computer program that comprise the steps of a computer-implemented method for applying a cell phone or mobile device (FIG. 3A) and the steps of a computer-implemented method for operating the MFTS system (FIG. 3B), in accordance with exemplary aspects of the invention.

FIG. 4 is a flowchart of a method of a main program of a mobile financial transaction system (MFTS) constructed in accordance with exemplary aspects of the present invention.

FIG. 5 is a flowchart of a method of a main program of a mobile financial transaction system (MFTS) constructed in accordance with exemplary aspects of the present invention.

FIG. 6 illustrates exemplary database schemas (data table formats) for a user database of a mobile financial transaction system (MFTS) according to an exemplary aspect of the invention.

FIG. 7 illustrates an exemplary database schema (data table format) for a transaction database of a mobile financial transaction system (MFTS) in accordance with exemplary aspects of the invention.

FIG. 8 is a flowchart illustrating steps of a computer-implemented computer program program embodying operations of a communication interface of a mobile device for MFTS, in accordance with exemplary aspects of the invention.

FIG. 9 is a flowchart illustrating steps of a computer-implemented method of a computer program embodying the operations of a financial service provider (FSP) communication interface for MFTS, in accordance with exemplary aspects of the invention.

FIG. 10 is a flowchart diagram illustrating the steps of a computer-implemented method of a computer program embodying the operations of an I / O interface of an Internet application for MFTS, in accordance with exemplary aspects of the invention.

FIG. 11 is a flowchart illustrating the steps of a computer-implemented method of a computer program embodying the operation of an Internet application for registering a new user, in accordance with exemplary aspects of the invention.

FIG. 12 is a flowchart illustrating the steps of a computer-implemented method of a computer program embodying the operation of an Internet application for a registered user in accordance with exemplary aspects of the invention.

FIG. 13 shows a sequence of screen displays of a mobile device for viewing selectable payment sources and account balances according to an exemplary aspect of the invention.

FIG. 14 shows a flow chart illustrating the steps of a computer-implemented method for viewing payment sources and account balances according to an exemplary aspect of the invention.

FIG. 15 shows a sequence of screen displays of a mobile device for viewing bills according to a preferred embodiment and an alternative embodiment of the present invention.

FIG. 16 is a flow chart illustrating the steps of a computer-implemented method for viewing invoices for payment according to a preferred embodiment and an alternative embodiment of the present invention.

FIG. 17 shows a screen sequence of a mobile bill payment device according to an exemplary aspect of the invention.

FIG. 18A is a flow chart illustrating the steps of a computer-implemented method for paying bills according to a preferred embodiment of the present invention, and FIG. 18B is a flow chart illustrating the steps of a computer-implemented method for paying bills according to an alternative embodiment of the present invention.

FIG. 19 is a sequence of screen images of a mobile device from the perspective of the payer, while the user uses the “Pay to anyone” payment menu item, selects a name from the list, and uses the “recipient-defined” payment method according to an exemplary aspect of the invention.

FIG. 20 is a sequence of screen images of a mobile device from the perspective of the payee “Pay to anyone” using the “payee determined” menu item according to an exemplary aspect of the invention.

FIG. 21 shows a sequence diagram illustrating a computer-implemented method from the perspective of the payer, while the user uses the “Pay to anyone” payment menu item, selects the payee, and selects the payment method according to an exemplary aspect of the invention.

FIG. 22 shows a flow chart illustrating a computer-implemented method from the perspective of the payee, while the user uses the pay to pay menu item, selects the "payee-specific" payment method and accepts the payment, according to an exemplary aspect of the invention.

FIG. 23 shows a sequence of screen images of a mobile device, from the point of view of the payer, of the payment sign “Pay to anyone” with the choice of the ACH payment method, according to an exemplary aspect of the invention.

FIG. 24 shows a sequence of screen images of a mobile device, from the perspective of the payee, of the payment sign “Pay to anyone” in the ACH payment method, according to an exemplary aspect of the invention.

FIG. 25 is a flow chart illustrating the steps of a computer-implemented method for a payment sign “Pay to anyone” in an ACH payment method according to an exemplary aspect of the invention.

FIG. 26 shows a sequence of screen images of a mobile device from the perspective of the payer, while the user uses the payment sign “Pay to anyone” and selects the payment method by paper check, according to an exemplary aspect of the invention.

FIG. 27 shows a sequence of screen images of a mobile device, from the perspective of the payee, of the payment sign “Pay to anyone” when paying by paper check, according to an exemplary aspect of the invention.

FIG. 28 is a flow chart illustrating the steps of a computer-implemented method for a payment sign “Pay to anyone,” including a paper check payment method according to an exemplary aspect of the invention.

FIG. 29 shows a sequence of screen images of a mobile device from the perspective of the payer, while the user uses the payment attribute “Pay to anyone” and selects a payment method with a card with a set limit of funds (SV), according to an exemplary aspect of the invention.

FIG. 30 shows a sequence of screen images of a mobile device from the perspective of the payee, the payment sign “Pay to anyone”, when the method of payment is a card with a set limit of funds (SV), according to an exemplary aspect of the invention.

FIG. 31 is a flow chart illustrating the steps of a computer-implemented method for a “Pay to Any” payment method, including the use of a card with a cash-in limit (SV) card, according to an exemplary aspect of the invention.

FIG. 32 shows a sequence of screen images of a mobile device while a user transfers funds or account balances according to an exemplary aspect of the invention.

FIG. 33 is a sequence diagram illustrating the steps of a computer-implemented method for transferring funds or transferring balances between accounts of payment sources according to an exemplary aspect of the invention.

FIG. 34 shows a sequence of screen images of a mobile device that illustrates the receipt of a payment for a payee with a mobile device, optionally installing the mobile device application on the mobile device of the payee, according to an exemplary aspect of the invention.

FIG. 35 is a flow chart illustrating the steps of a computer-implemented method whereby a payee downloads and installs a mobile device application from the MFTS system as part of a viral financial commerce system, according to an exemplary aspect of the invention.

FIG. 36 is a sequence of screen images of a mobile device from a user's perspective by changing a personal identification number (PIN), according to an exemplary aspect of the invention.

FIG. 37, consisting of FIG. 37A-37D, comprises screen displays of an Internet application input / output interface illustrating how a user is registered to use a mobile financial transaction system through a user website of an Internet application according to a preferred embodiment of the present invention.

FIG. 38, consisting of FIG. 38A-38D, comprises screen displays of an Internet application I / O interface illustrating how a user manages financial accounts of a mobile financial transaction system through a user site of an Internet application according to a preferred embodiment of the present invention.

FIG. 39, consisting of FIG. 39A-39D includes screen displays of an Internet application input / output interface illustrating how a user controls payment recipients of a mobile financial transaction system through a user site of an Internet application according to a preferred embodiment of the present invention.

FIG. 40 is a display screen for a billing summary of an Internet application in accordance with alternative exemplary aspects of the invention.

FIG. 41 is a screen for displaying details of a billing subject of an Internet application in accordance with alternative exemplary aspects of the invention.

FIG. 42 is a screen for displaying details of payment sources of an Internet application in accordance with alternative exemplary aspects of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Before a detailed description of the invention (s), the following definitions are given as an aid to understanding the subject matter and terminology of aspects of the present invention (s) are exemplary and not necessarily limiting the invention (s) as expressed in the claims. Whether the term is printed in capital letters is not considered to be determining or limiting the meaning of the term. As used herein, a capitalized term will have the same meaning as a term not capitalized unless the context of use indicates otherwise that a more restrictive meaning is used for a capitalized term. A capitalized term within the vocabulary of special terms indicates that the term capitalized has a separate definition within the vocabulary of special terms. However, the use of capital letters or its absence within the remainder of this document is not necessarily necessarily limiting, unless the context clearly indicates that such a limitation is implied.

DEFINITIONS / DICTIONARY OF SPECIAL TERMS

ACH : Acronym for Automatic Clearing House, an electronic banking network that processes credit and debit transaction volumes in accordance with the procedural rules and regulations established by the National Clearing House Association (NACHA) and the US Federal Reserve (Fed).

Application: a computer program that runs in a computer system, for example, but not limited to, a computer program that is run within the MFTS, or a computer program that runs within a cell phone or mobile device (mobile application). Additional application examples include programs that search the database, receive and store information in the temporary memory of a mobile device, display selected information on a mobile device, etc., and virtually any other type of program that generates transactions or is transactional responsive.

Information on accounts payable: information supplied by the billing entity or the billing aggregator related to or corresponding to the invoice to be paid; typically consists of all the information supplied by the billing entity that appears in the invoice to be paid and delivered to the billing user or aggregator. (See “summary of invoice due”).

Billing entity: payee: an individual, a business, or an entity that issues a bill that can be paid to the user. The term usually includes any payee whether or not an invoice is sent to remind you of a payment, although the invoicing entity may be deemed to be delivering a document or message (invoice for payment) indicating the amount due to the invoicing entity, a payee of the type “pay to anyone”, while generally considered to be an invoicing entity for the purposes of aspects of the invention, may not necessarily require an invoice for payment prior to sending the payment.

Billing Aggregator (Billing): an entity that provides a service for collecting information related to invoices for payment or other payment obligations, an entity with which the user or consumer maintains financial relations, and, in the context of the invention, delivers information about one or more invoices for payment to the mobile financial transaction system, designed as described in the materials of this application, and, optionally, serves as a financial services provider that processes the payment of the invoice for payment to the user.

Presentation of invoice for payment: Submission or presentation of one or more payment obligations of the entity (such as invoices for payment or payments for production), for example, by an aggregator of accounts for payment, and electronic transmission of one or more of these payment obligations of the entity to view and prepare payment orders. Presentation of invoices for payment may be provided on the basis of an invoice for payment with an invoice for payment, or may be a grouping or aggregation of invoices for payment by means of a billing aggregator that provides a collection service for paying an entity.

Consumer: an individual or other entity that accesses or uses a mobile device to perform certain functions of a mobile financial transaction system (MFTS), in accordance with exemplary aspects of the inventions. In a general sense, synonymous withby userbelow.

DBMS : database management system.

Company : An organization or business entity that uses the present invention. An enterprise may be a commercial enterprise, government organization, person, or, in fact, any other organization that conducts business transactions reflecting its business activities.

Subject: anything that has a separate and distinct existence or abstract reality outside of the present invention. One example is a billing entity that sends billing information about a payment obligation.

Financial Service Provider (FSP) : An entity that provides financial services on behalf of its customers, such as a bank, a company selling goods on credit cards, a credit union, a company selling goods on debit cards, a company working with gift notices, a payment service company or other financial institution, and, mainly thus serves as a Source of Payment (PS). As used in the materials of this application, the FSP is an entity that delivers financial services on behalf of users via mobile devices, in accordance with exemplary aspects of the invention. FSP can also be the recipient of a payment order and make a payment.

I / O : input / output.

LAN : local network, a set of computers that are connected, for electronic exchange of information, typically located geographically close to each other (that is, in the same building).

Mobile Service Provider (MCSP) (usually synonymous with a wireless service provider): An entity that provides mobile services for mobile devices with respect to MFTS and, possibly, with other network-connected entities. For example, a cellular telephone service provider typically can serve as an MCSP.

Mobile client (usually synonymous with a mobile application): a computer program that runs on a mobile device to provide services and operations, as described in this document, in accordance with exemplary aspects of the invention.

Mobile device : any device used for communication via wireless networks, such as a cell phone, walkie-talkie, personal digital assistant (PDA), pager, smartphone or any combination thereof. Mobile devices operating in the present invention typically execute a software-implemented mobile client program to implement the functionality described herein. As a rule, it is a synonym and is used interchangeably with a mobile phone, but the mobile device does not need to be a telephone type device.

Mobile Financial Transaction System (MFTS) : A system designed as described in this document that facilitates financial transactions through the use of mobile devices.

Payment order MFTS (MFTSPI) : a type of Payment Order (PI) (see below) that contains a message initiated by the MFTS and transmitted to the recipient of the payment order, such as a financial institution, to issue an order for the institution to pay the identified selected entity.

Mobile Payment Order (MPI) : a type of Payment Order (PI) (see below) that is generated and delivered from a mobile device in accordance with exemplary aspects of the invention.

Mobile wallet : the name given to the mobile device application, which provides functionality for viewing and selecting accounts to be paid, or other payments for making, viewing and selecting payment sources for making such payments, viewing balances, etc., in accordance with exemplary aspects of the invention.

Pay anyone : a feature of the aspects of the present invention that enables a user to pay to a person having a wirelessly connected mobile device, regardless of whether such person is physically present, mainly by sending messages to the wireless device of the payee, requesting orders, and determining a preferred method for receiving payment by the payee payment.

Payee : person or entity receiving the payment. The payee may also be the recipient of the payment order.

Payer : the person or entity making the payment. The payer is also the person or entity sending the payment order.

Payment order (PI) : a collection of information that typically includes one or more selected payments for production, at least one payment source for use in making a payment, and other information. A mobile payment order (MPI) is first generated and delivered from a mobile device in accordance with exemplary aspects of the invention. The MFTS Payment Order (MFTSPI) is a message initiated by the MFTS and transmitted to the recipient of the payment order to issue an order for the recipient to make a payment to the identified entity.

Recipient of a payment order (PIR) : the entity to whom a payment order is issued for the purpose of making a payment; the recipient of a payment order may make a payment on its own, or may order another entity to make a payment, such as a financial services provider. For example, the recipient of a payment order may be a financial services provider, an aggregator of invoices for payment, or a billing entity (for example, a company that has the authority from the payer to withdraw funds from the account for payment directly from the payer's bank).

Payment method : the manner in which the payment is delivered to the payee by the payee or his agent, that is, a financial instrument of some kind provided to the payee; payment can be made by various means, including, but not limited to, a paper check, a card with a pledged limit of funds, ACH money transfer, credit card account credit, wire transfer, money transfer, credit to PayPal or other interactive financial system accounts, another type of financial instrument, etc. In accordance with aspects of the invention, the payment method may be selected by the payer in certain embodiments, or may be selected by the payee in other embodiments. The payment source differs from the payment method in that the payment source provides funds for the instrument of the selected payment method.

Payment for Production (PM) : A payment obligation of a user of a mobile device for which an order is being executed to make a payment using aspects of the invention. Such obligations include any bills that a person or family accepts on a regular basis, such as water bills, electricity bills, gas bills, mortgage payments, car payments, insurance payments, bills payable by telephone and / or mobile phone, bills payable by credit card, etc. These payment obligations also include any payments that a person needs to make from time to time, such as buying gasoline, cinema tickets, any cash-only purchases, as well as payments to any individuals.

Source of payment (PS) : cash or money available to a person or family, usually through an account that can be accessed through aspects of the present invention. These sources include credit card accounts, debit card accounts, demand accounts and / or savings accounts, department store credit card accounts, and the like.

Information about the sources of payments : information related to the source of payment, which is stored in the MFTS, and a portion of which (summary information about the sources of payments) is transmitted to the user's mobile device.

Protocol : A set of formal rules that describe how to transmit data, especially over a network. Low-level protocols determine the electrical and physical standards that must be followed, the order of bits and bytes, and the transmission of the detection and correction of bitstream errors. High-level protocols deal with data formatting, including message syntax, terminal communication with a computer, character sets, message ordering, etc.

Card with a pledged limit of funds (SV) : a payment card that typically includes a magnetic strip or other electrical, magnetic or electronic information transfer medium that is approved as a form of payment by certain commercial / commercial enterprises; money can be “downloaded” to a card with a pledged limit of funds SV through various mechanisms and systems, and then can be used to pay bills for payment, purchase goods, etc. A card with a pledged limit of funds (SV) is not a debit card or a credit card, although an SV card bears certain physical similarities with these types of cards.

Billing Summary : A reduced subset of billing information that is displayed to the user through the user's mobile device.

Summary of Payment Sources : an abbreviated subset of information related to the account and / or financial institution that is displayed to the user through the user's mobile device.

Transaction : a set of system actions that result in a completed business transaction, for example, exemplary transactions are as follows: transfer of a certain amount of money (money) from one person to another; debiting a credit card account of one person (for example, a payer) and corresponding lending to a bank account of another person (for example, a payee); repayment of a bill; issuing an order to issue a card with a pledged limit on funds (SV).

SMS : short message service, a text transfer service available on many digital mobile devices or telephones that enables the sending of short messages (also known as text messages, messages or, in a more colloquial style, text messages, texts or even text messages) between mobile devices or phones.

User : an individual or other entity that accesses or uses a mobile device to perform certain functions of a mobile financial transaction system. Also see Consumer. As used in the materials of this application, these terms, in a general sense, are synonyms. The user can also use the web interface to access the MFTS for configuration and use, as described in the materials of this application.

User / payee : A user of the MFTS system and also a payee who accepts payments.

User / Payer : A user of the MFTS system and also a payer who makes payments.

User ID (user ID) : a code used to identify a user in relation to the MFTS or in relation to a financial services provider, or in relation to another component that requires information identifying the user for some purpose in connection with the invention.

UI : User interface. Typically means a software application with which the user interacts for the purpose of entering information, obtaining information, or invoking functions of an associated system for execution; includes the user interface of a mobile device.

Wan : global networks, a collection of computers that is a connection for electronic information exchange, typically where computers are much further away than on the LAN, and connected by telephone lines, fiber optic cables, artificial satellite transmission of the earth, or radio waves.

WLAN : a wireless local area network, for example, a technology that is used to connect devices, including mobile devices, travel computers, desktop computers, entertainment equipment, etc., via a wireless radio signal. Examples include well-known WiFi and WiMAX data transfer standards.

SYSTEM OVERVIEW

In the best embodiment contemplated by the inventors, aspects of the present invention are preferably implemented using mobile devices connected to electronically (preferably wirelessly) exchange information with a mobile financial transaction system (MFTS). Mobile devices include products such as cell phones and PDAs that are attached to transmit data over a wireless network to the MFTS. MFTS, in turn, is connected to provide remote network access (for example, access to the Internet) by users to set up accounts, configure, edit, control transactions, etc. As will be well known to those skilled in the art, such mobile devices are essentially small handheld computing devices that include features such as microphones and speakers (to enable telephone use), a wireless signal path, such as a digital radio station , a microprocessor as a central processing unit (CPU), a color or other display device, a keyboard or keypad, a writing pen, a scroll wheel, keys and the control, Bluetooth wireless signaling, the transmission of data signals in the infrared spectrum, etc. MFTS is similar to a general-purpose computing device comprising one or more processors and / or central processing units (CPUs), data storage in the form of drives and random access memory (RAM), communication interfaces such as LAN connections, WAN connections, Internet connections, Ethernet connections, etc.

Accordingly, it will be understood that the various embodiments of the present invention described herein are preferably implemented as a special purpose or general purpose computer including various computer hardware, as discussed in more detail below. Embodiments within the scope of the present invention also include computer-readable media for transferring or containing computer-executable instructions 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 downloaded onto a mobile device via wireless networks. By way of example, and not limitation, such machine-readable media may include physical storage media such as RAM, ROM (read-only memory, ROM), flash memory, EEPROM (electrically erasable programmable ROM, CD-ROM (ROM) on a CD), DVD (multi-function digital disk), or other optical disk drive, magnetic disk drive, or other magnetic storage devices, any type of removable non-volatile memory such as Secure Digital (SD) format, flash memory, memory card , etc., whether any other medium which can be used to carry or store computer control program in the form of computer-executable instructions or data structures and which can be subjected to access a general purpose computer or a special purpose or a mobile device.

When information is transferred or delivered through a network or other communication connection (cabled, wireless, or a combination of cabled or wireless) to a computer, the computer essentially considers the connection as a machine-readable medium. Thus, any such connection is, in fact, called and is considered a computer-readable medium. Combinations of the above should also be included within the scope of computer-readable media. Machine-executable instructions, for example, contain instructions and data that cause a general-purpose computer, special-purpose computer, or special-purpose processing device, such as a mobile device processor, to perform one specific function or group of functions.

Those skilled in the art will understand the features and aspects of a suitable computing environment in which aspects of the invention may be implemented. Although not required, inventions will be described in the general context of computer-executable instructions, such as program modules, being executed by computers in network environments. Such program modules are often reflected and illustrated by flowcharts, cyclograms, exemplary screen displays and other technologies used by those skilled in the art to communicate how such computer program modules should be created and used. Typically, program modules include procedures, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types within a computer. Machine-executable instructions, associated data structures, and program modules provide examples of a control program for performing the steps of the methods disclosed herein. A particular sequence of such executable instructions or associated data structures provides examples of appropriate actions for implementing the functions described in such steps.

Those skilled in the art will appreciate that the invention can be practiced in networked computing environments with other types of computer system configurations, including personal computers, handheld devices, microprocessor-based multiprocessor systems, or programmable consumer electronics integrated into a PC network , minicomputers, universal computers, and the like. The invention can also be practiced in wireless computing environments where tasks are performed by local and remote processing devices that are connected (cabled communication lines, wireless communication lines, or a combination of cabled or wireless communication lines) through a communication network. In a distributed computing environment, program modules can be located in both local and remote memory storage devices.

An exemplary system for implementing inventions, which is not illustrated, includes a general-purpose computing device in the form of a traditional computer, including a processor device, system memory, and a system bus that connects various components of the system, including system memory, to the processor device . A computer will typically include one or more hard disk drives (also referred to as a “data storage device” or “data store” or other names) for reading from and writing to. Drives and their associated machine-readable media provide non-volatile storage of machine-executable instructions, data structures, program modules and other computer data. Although the exemplary environment described in the materials of this application uses a magnetic hard disk, a removable magnetic disk, removable optical disks, other types of machine-readable media for storing data, including magnetic tapes, flash memory cards, digital video discs ( DVD), Bernoulli cartridges, RAM, ROM, and the like.

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

A central computer that implements many aspects of the inventions will typically operate in a network environment using logical connections to one or more remote computers or data sources, which are further described below. Remote computers may be a personal computer, a server, a router, a network PC, a peer device, or another common network node, and typically include many or all of the elements described above with respect to a central computer system in which the inventions are embodied. Logical connections between computers include a local area network (LAN) and wide area network (WAN), which are presented here as an example and not limitation. Such network environments are common in office or corporate computer networks, intranets (local networks based on Internet technologies) and the Internet.

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

CONSOLIDATION OF PAYMENT OBLIGATIONS

With the above implementation architecture in mind, please refer further to FIG. 1, which gives an overview of the mobile financial transaction system (MFTS) 18 and some features according to an exemplary aspect of the invention. The user 12 of the mobile device 15 (such as a cell phone or wireless PDA) accesses the MFTS 18 to select payments for production (“PM”) and to select payment sources (“PS”) for making such payments, in some way, which will be described . The main input in MFTS 18 contains payments for production, 20 (hereinafter “PM”), and sources of 30 payments (hereinafter “PS”).

PAYMENT FOR PRODUCTION (PM): A payment for production (PM), 20, contains any or all payment obligations and / or orders by virtue of which money or loans are transferred from one person or entity to another. These obligations include invoices that are paid on a regular basis by a person or family, such as invoices for water, electricity bills, gas invoices, mortgage payments, car payments, insurance payments, bills payable by phone and / or mobile phone, credit card bills, etc. These payment obligations may also include any payments that the person or family initiates, such as gasoline purchases, movie theater tickets, any cash-only purchases, other retail payments at the point of sale, as well as payments to the individual. Accordingly, PM can occur according to the presentation of the invoice for payment by the invoicing entity, or in response to user initiation.

Certain PM 20s that make up household billing accounts can be transferred to the MFTS via the MFTS billing channel. In accordance with an exemplary aspect of the invention, regular household billing accounts are transferred to the MFTS at a predetermined interval or at the user's request by exchanging information with an electronic billing aggregator, such as CheckFree Corporation, which electronically provides a “billing” service.

PM 20, which constitute “occasional” purchases (for example, at retailers) or payments to individuals, are typically initiated by the user, as opposed to being delivered in the first case to the MFTS by an aggregator or a separate billing entity. Such user-initiated transactions are typically sent to the MFTS via wireless devices thanks to mobile network services (not shown in this figure). Such PMs can be characterized as “Pay to anyone” transactions, since they involve making a payment to any identified entity, including an individual, as well as a commercial entity, at the user's initiation.

Generally speaking, the information associated with the PM 20 typically includes the name (s) of the account holder (s) (i.e., the person who is responsible for making the payment, if a typical household account is payable), the mobile phone number associated with with an account and / or account holder, account numbers, account balances, due date, minimum payments, electronic payment account numbers, addresses of invoicing entities, etc. This information is usually the same whether the PM is the result of invoice payment or user initiated.

SOURCES OF PAYMENTS (PS): Sources of payments (PS), 30, contain any and all funds available to a person or family for use in making payments. These sources of funds include credit card accounts, debit card accounts, bank accounts on demand and / or savings accounts, credit card accounts of department stores, and the like. This money is usually divided into two main categories: in the form of a bank account and a credit account. Entities that provide and / or service such cash are typically financial service providers (FSPs), which are often financial institutions (FIs). Bank accounts usually include demand accounts and / or savings accounts, where money available to a person or family is held. Credit accounts usually include all sources of credit available to a person or family.

Generally speaking, information associated with a source of payment (PS) 30 includes the name (s) of the account holder (s) (i.e., the person who owns or controls the funds), account numbers, account balances, cash loan and credit limits for a credit card or other sources of lending, the available cash loan amount, the names of authorized users or co-owners of the account, special personal identification numbers (PIN), restrictions on the use of the account, etc.

Still referring to FIG. 1, the main output from the MFTS 18 contains a subset of information related to one or more payments for production (PM), a subset of information related to one or more payment sources (PS), each of which is delivered from MFTS 18 individually the mobile device 15 and is displayed and / or presented to the user 12 for response and response. In response to the PM submission (or PM initiation), the mobile device 15 issues the payment order to the recipient of the payment order, such as a financial service provider or financial institution, to make a payment in accordance with the information in the payment order.

A complete generalized method for making a payment in accordance with exemplary aspects of the invention includes seven main steps: Interactions between MFTS 18 and mobile devices 15 are established through communication services provided by a mobile service provider (MCSP, not shown in FIG. 1), and include the first four stages of the generalized method. The seven main steps are as follows:

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

2. The second stage is intended for the user 12 of the mobile device 15 to view available payments for production (stage 2 shown in the triangle) and payment sources (stage 2 shown in the square) available for use in making selected payments, as shown in stage 2.

3. The third stage is intended for the user to activate the function of paying the bill for payment, as one example, using the mobile device application on the mobile device 15, which results in the preparation of a mobile payment order (MPI) based on the information entered by the user 12, as shown in step 3.

4. The fourth step is to transfer the mobile payment order (MPI) from the mobile device 15 to the MFTS for processing, as shown in step 4.

5. The fifth stage in a complete generalized way, but which does not involve a mobile device or communication with the MCSP, is the preparation of the MFTS payment order using information from the mobile payment order and the transfer of the MFTS payment order to the recipient of the payment order, as shown in step 5.

6. The sixth step in the full generalized method of the invention is to transfer funds to the selected payee by the payee, typically through a financial service provider, using the selected payment source, as shown in step 6.

7. The seventh step in the complete generalized method of the invention is for the financial service provider to send a payment confirmation message back to the MFTS after successfully processing the MFTS payment order.

Further details will be given regarding these steps.

As for step 1, the information actively delivered to the mobile device includes a subset of payment information for production, as shown in step 1 (PM), and / or a subset of information about payment sources, as shown in step 1 (PS). Actively delivered information does not include all available information accepted by the MFTS from a payment for production and / or payment sources. More preferably, an abbreviated subset of payment information for production and / or information about payment sources is actively delivered to a mobile device to facilitate viewing mobile payments or payment sources. In accordance with exemplary aspects of the invention, information is reduced in order to provide faster and more concise information to the user, which facilitates the decision to make a payment and which source of funds should be used. With regard to invoices for payment, this abbreviated information typically includes only the name (s) of the invoicing entities, the due balance or payment due, and the due date for the payment to be made. For payment sources, the name (s) of the account, current balance, available funds, consumer, etc. will be shown.

As for step 2, the user 12 of the mobile device 15 looks at payments for production, as shown in step 2 (PM), and looks at payment sources for use in making a payment, as shown in step 2 (PS). According to an exemplary aspect of the invention, the mobile device user 12 is notified via text message (SMS) when a new payment for production is received by the MFTS 18 and / or the update is received by the MFTS from a financial institution in an account associated with the mobile device via another means of communication. According to another exemplary aspect, the mobile device 15 retrieves information from the MFTS relating to new payments for production, or updated information about financial accounts after activating selected functions on the mobile device, such as “view bills for payment”, “pay bills”, as will be described in detail in the materials of this application in connection with various functional modules of the software.

According to another exemplary aspect of the invention, when a user 12 of a mobile device is ready to view payments for production, he / she can run a “mobile wallet” application that runs on a mobile device to view PM and PS. PM is viewed through the function “View invoices for payment” (also called “View payments for production”), and PS is viewed through the function “View payment sources”. An exemplary screen for displaying information displayed through these functions is shown in FIG. 1. With the function “View invoices for payment”, a user of a mobile device can view invoices for payment accepted to date and decide which invoice (s) to pay and at what time. Thanks to the function “View payment sources”, the user of the mobile device can see and decide which source (s) of funds to use to pay bills of his / her choice. The selection made at this stage is not transferred to the MFTS until the function "Pay bills" is activated. It should be understood that viewing payments for production and sources of payments does not necessarily require the user to select a payment account for payment, although this is one of the main intended functions of the invention.

As for step 3, the user calls the function "Pay bills" in the application of the mobile device on the mobile device 15 to select a payment for production and the corresponding payment source, which prompts the mobile application to create a mobile payment order (MPI). This step includes selecting a payment for production, selecting a payment source, and creating a mobile payment order. A mobile payment order typically includes information about the billing entity, the amount to be paid, the date and / or time for payment, and the selected payment source for this payment.

As for step 4, the mobile application issues a mobile payment order (MPI) via a wireless connection from a mobile device to the MFTS for processing.

With respect to step 5, the MFTS processes the MPI and creates the MFTS payment order to the recipient of the payment order, which, in some cases, is the selected financial service provider or financial institution associated with the selected payment source. A completed MFTS payment order typically includes information contained in a mobile payment order, along with selected other information stored in an MFTS database associated with mobile device users, such as a mobile device user account number, an appropriate account to use for payment , amount of payments, date and / or time for payment, account credentials, etc.

As for step 6, the recipient of the payment order makes a payment by various means, for example, he can make a payment on his own, or issue orders to the selected financial institution to use the selected payment source (PS), identified in the MFTS payment order, to transfer funds to the account, or other payment instrument of an identified entity associated with payment for production (PM).

With respect to step 7, the financial service provider (FSP) transmits a confirmation message back to the MFTS after successfully processing the payment order MFTS.

Particularly, it should be taken into account that, since the information delivered to the mobile device is a selected and abbreviated subset of information that is typically associated with a financial transaction for making an electronic payment using the selected payment source, the user of the mobile device sees only the minimum required information that he or she needs to decide to make a specific payment, and which source to use. The more detailed and comprehensive information required to complete the transaction is stored in the MFTS, transparent to the user, but is extracted and used to make a payment using the selected payment source. Advantageously, the user is provided with the required, but limited, information necessary to make payments quickly, concisely and reasonably, using his or her mobile device, at the place and during his or her opportunity. In addition, all transaction details are preferably recorded and stored by the MFTS, and can be accessed and viewed by users at its convenience, for example, via the Internet interface, as will be described in more detail later.

Further details on the implementation of these milestones will be given below.

Next, with reference to FIG. 2, a system 200 in accordance with aspects of the invention includes MFTS 18, a mobile service provider (MCSP) 110, a communication network 120 such as the Internet or a private network, a billing system 190, a web interface for users 140, mobile device (s) 15, connections or interfaces with billing / payment entities 180 and payment sources 30, and other components for specific purposes.

The MFTS 18 includes a computer system comprising a database 158, long-distance communication interfaces 152, and software. MFTS 18 supports the main communication interfaces or methods: Financial Service Provider (FSP) communication interface 156, wireless or mobile device (mobile client) interface 152, and the World Wide Web (WWW) or Internet user interface (UI). As is known to those skilled in the art, an “interface” is a means or method for interacting between machines, devices, computer programs, or other complex tools, and a user interface (UI) is a means or method through which a user interacts with a particular machine, device, a computer program or other complex tool. The user interface provides an input means (enabling the user to send information to the system, such as the MFTS) and an output means (allowing the MFTS system to display information to the user). This input and output is transported over the Internet and viewed by users using a web browser program such as Netscape Navigator, Internet Explorer, Firefox, or any other web browser. According to aspects of the invention, users provide personal information for registering for a service, enter personal and financial information into the MFTS, and verify such information through a display device in a user's computer system.

A financial service provider (FSP) communication interface 156 is an interface with financial entities 30 that provide payment sources (PS), and a billing interface 155 with billing / payment entities 180 for payments for production (PM). The MFTS computer system is connected to the computer systems of financial entities through various types of computer networks, such as a dedicated channel 160 with a secure structure, local area networks (LAN), wide area networks (WAN), etc., as well as the well-known Internet 120.

The interface 152 of wireless or mobile devices (mobile clients) provides connections to the mobile device 15 of the user. The MFTS computer system has many interfaces for exchanging information with users' mobile devices through various wireless long-distance service providers providing voice / data services with CDMA (Code Division Multiple Access), GSM (Global System for Mobile Communications), GPRS (General Service) services Packet Radio Broadcast), other 2G wireless services (2nd generation) and the newly emerging 3G wireless services (3rd generation). As is well known by those skilled in the art, in addition to the standard voice function of a mobile phone, many mobile devices support numerous additional services, such as SMS for text messaging, packet switching for Internet access and MMS (multimedia messaging service) for sending and receiving photos, sound, music and / or video. System 18, respectively, preferably includes an SMS driver 151 for generating SMS messages. Mobile device communication interfaces 150 provide users with the ability to receive financial and other information wherever they are (provided that they are within the coverage area of their MCSP), interact with MFTS 18, and perform various financial transactions.

The user interfaces (UIs) of the World Wide Web (WWW) or the Internet include one or more Internet applications 154 so that the user can access the MFTS for registration for maintenance, configuration and setting up accounts, supporting accounts, viewing payments for production, as well as sources and payment status, etc. Preferably, the financial information about the user accounts could be submitted to the MFTS from registration for the service, for example, through a commercial agreement with a selected financial institution that has a relationship with the MFTS operator. Alternatively, the user can also use the user interface of the Internet to enter financial information about the user’s accounts.

Still referring to FIG. 2, in certain aspects of the invention, the MFTS 18 communicates with a user 12 through his or her mobile device (s) 15 and / or his or her associated computer 140, a mobile service provider 110, a data network such as the Internet 120 a secure dedicated network channel 160, financial service providers (FSPs) 30 that provide payment sources 30 that bill billing entity 180, and / or billing system 190.

Mobile devices 15 communicate with the MFTS 18 through a wireless connection (illustrated as antenna 112) using a wireless service provided by a mobile service provider (MCSP) 110. Mobile devices 15 comprise any devices that are connected, for data transmission, to a mobile communication network via MCSP 110. Such devices 15 may include a pager 15a, a personal digital assistant (PDA) 15b, a cell or mobile phone 15c, or any other electronic a device that includes the functionality of a PDA or mobile phone, with the ability to receive information via a wireless communication line, receives user input and transmits data (eg, a payment order) to the MFTS.

The present invention will be described in terms applicable to the various types of mobile services provided by the MCSP 110. Those skilled in the art will understand and appreciate that the invention is not limited to any type of mobile or wireless communication standard, but can be implemented using any the number of different but functionally equivalent wireless data transmission standards. Currently, in the United States, digital telephone networks are mainly based on two underlying standards: GSM (Global System for Mobile Communications) and CDMA (Code Division Multiple Access). Some MCSPs use GSM, while others use CDMA. In addition, others use a standard called PCS (Personal Communication Systems), which is based on CDMA but uses different frequencies. Moreover, the so-called "broadband" wireless data standards, known as WiFi and WiMAX, which are currently used for WLAN implementations, are also usable for implementing embodiments of the invention, but such standards are currently not widely used in handhelds. mobile devices.

These and other, maybe even not yet created, standards for wireless data transmission can be applied in the construction of embodiments of the inventions described in the materials of this application, without undue experimental work, as specialists in the art will understand how to apply such technology in creating embodiments of the inventions.

It will also be understood that the current proposed upgrades in relation to both mobile wireless standards, GSM and CDMA, as well as upgrades in relation to other data transfer standards, will be useful in constructing embodiments of the inventions. For example, to better handle data streams (in addition to voice streams), many GSM networks now operate using a standard called GPRS (General Packet Radio Service), which can carry data up to 56 kbit / s - approximately the same speeds, like a dial-up connection of a telephone line - together with GSM signals that carry the voice traffic. Later, networks that use GSM added an enhancement called EDGE (the development of the GSM standard with an increased data rate), which increases the data rate to 144 kbps. CDMA networks have also increased their data rates using a standard known as 1xRTT (Radio Transmission Technology), which defines bandwidth at 144 kbps. A further recent enhancement for CDMA networks is the 1xEV-DO (High Speed CDMA Packet Speech Exchange - Data Only), which can deliver data at a theoretical maximum of several megabits per second - as fast as today's DSL (Digital Subscriber Line) connections ) or cable Internet. In addition, some MCSPs are now providing a service called UMTS (Universal Mobile Telecommunications System), an improvement on GSM networks, which increases the connection speed to a maximum of 384 kbps and provides simultaneous speech and data, a desirable sign that users make and receive voice calls along with the simultaneous use of information services, such as the use of a wireless travel computer.

It is expected that as the need for wireless data transfer increases, MCSPs will introduce even faster standards and enhancements to their networks. For example, the proposed EV-DO Rev A (Modifications A) will increase the speed of EV-DO networks up to 1.8 Mbit / s upstream and 3.1 Mbit / s downstream, and HSDPA (High Speed Downlink Packet Access) , an upgrade to UMTS, which promises speeds of 1.8 Mbps and also provides for simultaneous speech and data.

In addition, it should be understood that technologies for exchanging short messages (eg, SMS) are typically implemented using the above-described data transmission technologies for delivering text messages. Such wireless data technologies are also used to support features such as wireless Internet browsing on mobile devices; downloading music, ringtones for your phone, video, photos; and protocol support for wireless applications (e.g., mobile applications created as described in this document).

Accordingly, those skilled in the art will understand that numerous equivalents for elements of the invention that provide a wireless connection between mobile devices 15 and MFTS 18, to support a mobile application and facilitate transactions described in the materials of this application, are intended to be used in the construction of embodiments inventions.

A data network 120, which includes the well-known Internet, offers the ability to access the MFTS 18 via wired or wireless connections. Users 12 can access the Internet 120 through their home / office connections, as well as through their mobile devices 15. The user's computer, shown at 140, is connected to the Internet 120 via their home / office connections, or wirelessly connected through a service provider mobile communications. According to aspects of the invention, users have the flexibility to access billing information and payment information using a computer interactively with access to web presentations, or via mobile device 15 with mobile presentations.

It will be appreciated that, in general, a mobile presentation will provide less information to a user than a web presentation, since mobile devices typically have smaller display screens (to facilitate mobile use), and users often require the quick and efficient use of certain basic functionality in a mobile environment, provided that they receive more detailed information available through another medium at a later time. However, the present invention in particular considers modes of operation where further details about the transaction can be obtained thanks to the function of the mobile device, as well as through web presentations using the connection of the computer 140 to use the Internet.

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

The mobile device communication interfaces 152 are preferably an HTTP Remote Procedure Call (RPC) interface that provides mobile clients with access to the financial services available to the MFTS. The mobile client interface is preferably intended to facilitate the exchange of information between the MFTS 18 and mobile users, including all data transmissions and receptions, as well as SMS transmissions and receptions through the SMS shaper 151. The SMS shaper is a software component that receives messages for transmission to a mobile device and converts the message to SMS, which is usually purely textual information, and transmits the message to the MCSP in the SMS format specified by MCSP. Details of the required SMS format for a particular MCSP can be obtained by querying the applicable MCSP.

Internet applications 154 are located on the MFTS server and contain one or more of the following main components: user site 153 and administration site 157 (Admin).

User site 153 is an Internet application (HTML) whose purpose is to enable users to register or sign up for services provided by MFTS 18, manage their mobile clients, and perform other user-related functions, such as account maintenance, adding new payee, checking account information for sources of payments or payments for production, etc. The user site 153 is used to register the user to receive services, supplying appropriate information, such as name, address, mobile number, etc., to obtain a username and password for security purposes, and to provide the MFTS 18 with detailed information about billing entities of the user and their sources of payments, such as account number, access / authentication methods, etc.

Administration site 157 is an application (typically Internet or HTML) used by MFTS production operations personnel to administer the system. It is typically used by information technology (IT) administrators from MFTS 18 to troubleshoot, answer questions, maintain accounts, view transaction history, monitor overall system control, etc.

MFTS 18 also contains multiple interfaces 156 connecting financial service providers with partner financial service providers (FSPs) 30, which are entities that provide functions such as detailing payment sources, aggregating billing accounts or linking payments between billing accounts, or entities to which, on behalf of the user, payment orders are sent. The financial service provider communication interface 156 facilitates the transfer of electronic data transfer information between the MFTS and individual financial service providers such as bank accounts, credit accounts, and the like. The technical requirements for these interfaces vary within their implementation and may need to be modified according to customer requirements to fit each individual financial services institution. Such interfaces are typically implemented as real-time Internet service interfaces or batch file transfer protocols, depending on the capabilities and requirements of participating partner financial service providers. Details of the data transfer requirements of individual FSPs can be obtained directly from the FSP.

A dedicated secure dedicated network channel 160, such as a frame relay, private network, virtual private area network (VPN), or Internet service, is preferably used to transfer data between the MFTS 18 and various FSPs to ensure protection of financial information transmission. Details of specific types of protection, protocols, requirements, etc., will be established between MFTS 18 and each financial institution that participates in the system and methods described in the materials of this application.

Still referring to FIG. 2, a user database 158 associated with MFTS 18 stores information related to all users, financial service providers that service users, invoicing entities, payees and how to make payments, and other related information. Details of the information stored in the user data base 158 are provided in connection with FIG. 6 and an associated description.

As described earlier, FSPs that provide 30 payment (PS) sources include banking entities such as banks, credit unions, savings and loan partnerships, brokerage firms that provide savings / demand / cash market accounts, and others financial institutions; credit entities, such as credit card companies, banks and / or department stores, gasoline companies, etc .; and any other financial institutions with which MFTS users conduct business. Payment sources 30 provide payments 194 to selected billing entities 180 in a manner described in the materials of this application.

Billing entities 180 include service industries that serve users, such as gas suppliers 185, water, electricity 181, telephony / cellular telephony 183, satellite / cable / Internet, credit card companies, and any other entities that send an invoice to the user for purchased products or services rendered. As will be appreciated, many invoicing entities 180 send invoices 192 for payment on a regular basis (often monthly). Invoices can also come from invoicing entities that provide services to users, such as insurance companies, homeowners associations, garbage collection, pest control, car repair, garden and lawn processing, landscaping, cleaning, etc. Some entities send invoices for payment not on a monthly basis, but on a semi-annual, quarterly or annual basis, or on demand when a service is provided. Sometimes, people need to pay for the services of others personally, such as colleagues, friends, family members, etc. All of these payment obligations on accounts payable or not on accounts payable are referenced as payment for production (PM).

According to one exemplary aspect of the invention, billing system 190 may be used to receive bills from billing entities 180 and aggregate them into a package for presentation to the user, electronically or otherwise. Billing system 190 may be a service or component of MFTS 18, or an independent service entity. For example, CheckFree Corporation in Nokros, Georgia provides a billing aggregation and billing aggregation service. The billing system extracts bills from one or more separate billing entities and submits bills to the MFTS; Information related to the collected / extracted invoices for payment is stored in the database 158 of the data of users of MFTS 18.

It will be understood and taken into account that the billing aggregator and MFTS 18 can be created as separate systems, used by the same or different entities, or can be created as an integrated system in which the aggregator functions and the MFTS functions are performed as complementary and computer processes communicating with each other. Thus, although FIG. 2 shows MFTS 18 and billing aggregator / system 190 as separate entities, those skilled in the art will understand that such functionality may be provided in an integrated system.

According to an exemplary aspect of the invention, mobile devices 15 may be configured to work in conjunction with a billing entity, such as a retailer, by accepting a payment for production (PM) from a radio frequency identification (RFID) device 187. Various types of RFID-based payment terminals are now becoming available in the field of commerce. As is known to those skilled in the art, RFID-based payment terminals are operable to detect the presence of an RFID electronic circuitry, possibly contained in a mobile device, in the vicinity of an RFID-based payment terminal, and automatically transmit wirelessly (WiFi, Bluetooth, infrared, and etc.) a signal corresponding to payment information in response to an associated device. It is contemplated that the mobile device 15 can be configured to receive a payment obligation (PM) from a merchant at a point of sale (POS) via wireless communication directly, and thereby provide the user with the ability and ability to pay the billing entity for goods provided or services as described herein.

Also in FIG. Figure 2 shows the special financial services provider 175 (FSP), which provides a special interim storage account on behalf of MFTS 18, for the purpose of interim storage of funds in connection with transactions on a temporary or provisional basis. The FSP 175 interim custody account provides an FDIC (Federal Bank Deposit Insurance Corporation) insured account for interim storage of funds in connection with escrow transactions in which an authorization to use payment to invoice 180 is carried out for some event, such as delivery of specific goods or services, or special authorization from the user, or other purposes. FSP 175 interim storage accounts can be used in the following approximate way: after a user selects a payment source (PS) to make a payment, the selected payment source can be instructed, by payment order, to transfer funds to the intermediate storage account 175, where such funds will be stored on behalf of the user prior to the use authorization event (for example, delivery of goods, fulfillment of a contract or other predetermined event), at which time the account 175 is intermediate The custodian will transfer the funds to the specified invoice for payment or payment entity.

GENERAL WORK MFTS

Before discussing the software architecture of the preferred embodiments, the general operation of the disclosed MFTS 18 will be briefly described. As will be appreciated, most of the functionality of the embodiments of the invention is implemented in computer software and includes user interaction with his or her mobile device, creation specific data records, the exchange of information between mobile devices and the MFTS 18, and the exchange of information between the MFTS 18 and various other and the parties involved and their systems, such as financial institutions, invoice for payment entities, the person to whom payments are made, etc. Still, in this regard, with reference to FIG. 2, the overall operation of the MFTS 18 according to certain aspects of the invention includes the following exemplary steps:

1. First, the consumer or user 12 registers with the MFTS 18 and creates an account using the MFTS service. This registration is performed through the user site interface 154 through a computer 140 connected to the Internet, or through a mobile device 15 that has Internet access capabilities. The owner (user) of the account selects or is endowed with a username and password for security and authentication purposes. A user profile is created for the account, and the necessary information, such as the identification number or telephone number of the mobile device associated with the account, is entered and stored in the database of 158 users in the user record. All billing entities with regard to payments for production (PM) that the user wishes to service MFTS are entered by the user into the user database, including the account number, name and address of the account holder, billing cycles and any other relevant information. Similarly, one or more payment sources (PMs) are also entered into the user database, including the bank code (s) assigned by the American Banking Association and the account number (s), name (s) and address (s) of the holder (s) ) accounts, access codes, such as PIN, access methods, credit card number (s), credit card (s) expiration date (s), etc. Alternatively, FI information may be actively delivered to the MFTS via the FSP communication interface 156.

2. According to one exemplary aspect of the invention, user 12 downloads a mobile client (also called a mobile application or “Mobile wallet”) to his / her mobile device 15a from the MFTS main site, as shown under 215. The downloadable mobile application may (a) be downloaded to a user's computer 140 for later synchronization with and / or download to a mobile device, for situations where the software of the mobile device should be downloaded from a PC, or (b), alternatively, directly downloaded I am through a wireless network to a mobile device, for situations where the mobile device is capable of directly downloading applications. 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. It should be understood that, according to a preferred exemplary aspect of the invention, since the mobile client is an application that runs independently on the mobile device and does not require an active communication connection with the MFTS 18, it can operate offline where and when the mobile device is out of range service using a local storage device in a mobile device. The ability to use local storage on devices provides the ability to cache data, which increases the speed of end-user interactions, and the ability to queue user-initiated transactions until connectivity is restored. Additionally, offline support provides for the elimination of intermittent signal activity that could affect the user experience observed in today's market based on WAP (Wireless Application Protocol) solutions.

3. At predetermined intervals, the MFTS sends requests to the billing aggregator for payment (for example, billing system 190 for billing) or billing entities 180 to extract bills 192 for payment by MFTS users. Alternatively, the MFTS may accept bills from billing entities with certain billing cycles, from a billing aggregator, or directly from a billing entity.

4. MFTS accepts invoices for payment and notifies the user of the invoice due for payment by SMS (in accordance with one aspect). The user then launches the mobile client software on the mobile device 15, which communicates with the communication interface 152 of the mobile device to see the bill payable. The SMS message preferably contains only brief and abbreviated information, as simple as the name of the invoice for payment of the subject and the amount payable; additional information can be obtained by the mobile device (see the next step).

5. The user opens the Mobile Wallet application on his / her mobile device (s) in order to view the accepted account (s) for payment by request to all applicable billing entities.

6. If the user decides to pay the bill, the user can select one of the available payment sources (PS) and select one of the possible set of billing accounts (PM) to make the payment. A payment order is generated by the user by selecting PM and selecting PS for PM.

7. The user is preferably provided with a confirmation screen on a mobile device that provides basic information about the invoice for payment, the timing of payment transactions, cash balances, etc., before the payment is ordered to the system. If the user confirms the payment, the mobile device 15 sends an abbreviated mobile payment order to the MFTS 18.

8. In response to receiving a mobile payment order from a mobile device, MFTS 18 adds other relevant information to form a complete payment order (MFTS payment order), which instructs the selected financial services provider to make a payment transaction by transferring funds from the selected PS to the payee using a payment method that has been pre-selected or selected as part of the PM and PS selection process.

Additional details about the special exchange of information between the mobile device 15, MFTS 18, FSP with payment sources 30 billing entities 180, billing system 190, etc., are given in various flowcharts of methods and charts elsewhere in this document.

SOFTWARE ARCHITECTURE

The software architecture of the mobile financial transaction system (MFTS) is shown in FIG. 3. According to one embodiment of the present invention, the MFTS software comprises two main components: a mobile device application 400 (“Mobile Wallet”) and 500 MFTS software. The mobile device application 400 resides on a mobile device and is accessed by the owner of the mobile device. The 500 MFTS software application is located on a server computer connected to the Internet, and it is accessed by a user through his Mobile Wallet application and web browsers.

Next, with reference 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 includes: a basic mobile device program 335 for managing the operation of the mobile device application 400; a mobile device I / O interface 331 for displaying messages, receiving user selections and input, and facilitating user experience; security manager 333 for security measures for wireless communications; a mobile device storage interface 337 for storing and retrieving data to / from a local storage device 341, such as a non-volatile memory device, within the mobile device; and a mobile device communication interface 339 for exchanging information with mobile device radio communication hardware 343 on the mobile device, which in turn communicates with mobile communication service providers (MCSPs) 110 according to their specific protocols.

FIG. 3A also illustrates a number of procedures or functions 301, 303, 305, 307, 309, 311, 313, 315 and 321 that are provided by the mobile device software or the mobile wallet application 400. Such procedures or functions provide user functionality on the mobile device as shown. Procedure 301 View payment sources involves displaying payment sources on a user's mobile device; details of this procedure are shown in FIG. 13 and 14. Procedure 302 View invoices for payment involves displaying invoices for payment or payments for production on a user's mobile device; details of this procedure are shown in FIG. 15 and 16. Procedure 305 Pay bills involves the selection of bills for payment or payments for production on the user's mobile device; details of this procedure are shown in FIG. 17 and 18. Procedure 307 Pay to anyone by name involves making a payment to a person by name on the user's mobile device; details of this procedure are shown in FIG. 19-22 and 26-28. Procedure 309 Pay anyone by mobile number provides for payment to the person by mobile number on the user's mobile device; details of this procedure are shown in FIG. 23-25 and 29-31. Procedure 311 Transfer balances provides for the transfer of funds between the user’s accounts through the user's mobile device; details of this procedure are shown in FIG. 32 and 33. Procedure 313 Download the application provides for downloading the Mobile Wallet application to the user’s / payee’s mobile device from the MFTS in connection with the receipt of payment in order to enable the user to use aspects of the invention by payment recipients in connection with the payment; details of this procedure are shown in FIG. 34 and 35. Procedure 315 Change PIN allows the user to change his or her personal identification number (PIN) through a mobile device; details of this procedure are shown in FIG. 36. The procedure 321 SMS (text message) receipt provides for sending a text message (SMS) to the payee to notify the payee that the payment has been received; details of this procedure are shown in FIG. 15 and 20.

Next, with reference to FIG. 3B, a diagram of a software architecture 500 MFTS according to one embodiment of the present invention is shown. 500 MFTS software contains: 350 MFTS main program; an MFTS mobile communication interface 150 for communicating with mobile service providers 110; an interface 154 of Internet applications for entering into a user registry, registering, extracting and updating information through a user site via the Internet 120; 375 P2P service to facilitate interpersonal financial transactions; a storage / database (DB) interface 377 for storing and retrieving data to / from the database 158 of the MFTS user data; 379 financial account service to facilitate user authentication; a financial service provider (FSP) communication interface 156 for communicating with financial service providers 30, as well as a bank account 175 of MFTS interim storage (if applicable); and a billing interface 155 for accepting bills from various billing entities 180 through a billing system 190.

The main MFTS 350 program interacts with and coordinates the other modules and services in the MFTS, and acts as a “traffic controller” for information routed between the various storage and communication interfaces.

The preferred Internet application input / output interface 154 provides users with the ability to register or register with the MFTS system, add / edit / view / delete mobile clients, add / edit / view / delete credit card accounts / bank accounts, and add / edit / view / remove payees or billing entities. The Internet application interface 154 further provides the user with the ability to initialize a mobile client and unlock a locked mobile device after a series of failed logins. Exemplary mappings associated with the preferred Internet application interface 154 are shown and described in connection with FIG. 10-12.

The preferred interface 154 of Internet applications provides a number of functions or procedures for users to access via an Internet connection (World Wide Web), if required. It will be appreciated that users may prefer to carry out certain types of functions, such as registration, adding a payee, changing transaction configurations, and the like, via an Internet web interface instead of a mobile communication interface. For example, and in accordance with aspects of the invention, functions that are provided in a preferred embodiment via a web interface include registration, 351 (for example, see FIG. 37); editing mobile client 353 (for example, see Fig. 37B, 37D); editing credit card accounts and / or bank accounts, 355 (for example, see Fig. 38A-38D); editing or adding a payee, 357 (for example, see Fig. 39A, 39B); initialization of the mobile client, 359 (for example, see Fig. 37A, 37C); and unlocking the mobile client, 361 (for example, see Fig. 37A); Details of preferred software system procedures are provided in connection with the referenced figures.

The preferred I / O interface 154 may be replaced by an alternative embodiment of the interface 154 ', which provides other functionality and display of the web user interface, as described in connection with FIG. 40-42.

MOBILE DEVICE SOFTWARE

FIG. 4 is a flowchart of a main program 335, which is one of the software modules of a mobile device, or Mobile Wallet software 400 that runs on a mobile device 12, in accordance with aspects of the invention. From FIG. 3A, it will be understood that the main program 335 of the mobile device, in the disclosed embodiment, is the main program cycle of the mobile wallet software 400, which coordinates the operations of other program modules of the mobile device, including the mobile device I / O interface 331, the dispatcher module 333 security, module 337 storage of the mobile device and module 339 of the communication interface of the mobile device.

In a typical application, the user of the mobile device turns on his / her mobile device, scans for any recent text messages (in some embodiments), navigates to or “launches” the mobile device application 400, initiating the operation of the main mobile device program 335, and views the displays generated program, and interacts with the program to provide commands and input data, for example, to view an invoice for payment or to select a source of payment, or to odit payment. In accordance with aspects of the invention, a user may launch a mobile device application 400 in response to receiving a text message indicating that there is a new bill payable to be paid (or another message from the MFTS), or may independently launch the mobile device application, to call up the function of viewing the invoice for payment, paying the invoice, etc.

In FIG. 4, the first step 405 comprises a mobile device checking whether a text message (SMS) has been received. For example, according to an aspect of the invention, a text message is sent by the MFTS to the mobile device to inform the user that a new bill has been accepted and can be paid, or that a payment has been received from another user. See FIG. 15 and 20 in this regard.

It will be understood that the received text message may or may not be associated with the MFTS or some of its functions. However, any unrelated text messages here will be ignored for the purpose of discussion, and it is assumed that all received messages are related to the MFTS and its operations. It will also be understood that in some mobile devices, text messages are received by an independent process or module and stored in memory for access by other processes, while receiving and processing a text message, optionally, could be combined as an integrated function within the software providing 400 mobile devices. If a text message related to the MFTS function has been received, by an independent process on the mobile device or completely inside the application, at step 460 the user can open a text message and decide what should be done in response to the message.

At step 470, the user may prefer to download the software of the mobile device (for example, download the software of the Mobile wallet) if he is not currently a registered user. The user will be provided with information on how to access and download the software application. Additional registration information is provided elsewhere in this document. The user would need to download the Mobile Wallet software and run it on his / her mobile device before any of the other functionality in FIG. four.

After step 460, the program loops to step 490 to wait for a command or exit event (completion), and can return to the beginning of the loop at step 405 in a continuous loop and repeat the operation.

Returning to step 405, if no message has been received, program control proceeds to step 410, where the user may prefer to activate the mobile wallet software 400 and use the functions provided therefor. If not (that is, there is no user command to enter the mobile wallet software application at step 410), the control returns to the beginning of the cycle to check for text messages and / or activate the mobile wallet software.

If, at step 410, the user started the mobile wallet software 400, control proceeds to step 415, where the user can select from a list of functions provided by the software on the mobile device. Such functions will be described below. The program is continuously executed in a loop, waiting for user input of the selected function, which includes the “exit” command, as shown in step 490.

In accordance with one embodiment of the invention, at step 415, the user may prefer to call or run the following functions provided by the main program 335 of the mobile device:

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

2. View invoices for payment as shown in step 425 (see FIGS. 15 and 16 for further discussion);

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

4. Call the function "Pay to anyone", as shown in step 435 (see Figs. 19-31 for further discussion);

5. Request a transfer of account balances as shown in step 440 (see FIGS. 32 and 33 for further discussion); and

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

Other functions are also provided according to an aspect of the invention, if provided with the function of an “inbox” and “outbox” for viewing incoming and outgoing payments:

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

8. View the outgoing mailbox payments as shown in step 455.

It should be understood that the functions of viewing payments of an inbox (step 450) and viewing payments of an outbox (step 455) are optional functions for an embodiment where compiling a list of incoming payments from other users (payments of an inbox) is supported on a mobile device , and / or making a list of outgoing payments that have been generated and sent from the mobile wallet software application is supported on the mobile device, while the payment is located pending, for independent monitoring of mobile wallet software.

Still referring to FIG. 4, after the user invokes a specific function, the appropriate control program commands for performing these functions are executed by the mobile device. Exemplary mappings and discussion of such functions are provided in connection with the referenced figures in FIG. 4, and the reader is referred to these discussions elsewhere. After each function is completed, the mobile device application proceeds to step 490 and either returns to the beginning of the cycle to verify the input of another user function, or terminates. The user can continue further work of the mobile device application or complete the application. If the user decides to continue, the mobile device application returns to step 405 to control text messages or continue the mobile wallet application.

FIG. 5 is a flowchart of a main MFTS program 350, which is one of the MFTS software modules 500 that operates in a computer system or server in MFTS 18, in accordance with aspects of the invention. The main program 350 coordinates other programs and functions of the MFTS, as shown in FIG. 2, for example, the MFTS mobile communication interface 150, the SMS driver 151, the Internet applications 153, the FSP communication interface 156, the billing interface 155, accessing and maintaining the user database 158, etc. From FIG. 3B, it will be appreciated that the main MFTS program 350, in the disclosed embodiment, is the main program cycle of the MFTS software modules 500, which coordinates the operation of other program modules associated with forming part of the MFTS 18.

In typical use, the MFTS 18 operates continuously to control input from various sources. The initial input comes from user registration, where the user enters information to create an account or relationship with the operator of the MFTS system, from mobile devices, while users view and pay bills for payment, from exchanging information with billing entities, financial institutions and / or the FSP to receive invoices for payment, issue payment orders to such institutions and partners, and receive information such as account balances and confirmation payments. Those skilled in the art will understand that software 500 is preferably built to run on a computer server in a multi-threaded, multi-tasking, endowed with web feeds, secure, working in real time 24 hours a day and 7 days a week (24/7) A computing environment that is controlled by messages from various entities with which the system communicates.

In FIG. 5, the flowchart for the main MFTS program 350 begins with determining that input from an associative entity (e.g., a user via a mobile device, a user through a web interface, FSP, etc.) has been received and should be processed. The system determines, at step 505, whether input has been received from the mobile device communication interface 152, at step 510, whether input has been received from the Internet application 154, at step 515, whether input has been received from the billing system interface 155 to billing, and at step 520, whether input has been received from the interface of the financial service provider (FSP) 156. At step 530, the program 350 then branches off to or performs the appropriate procedure or interface to perform a specific function associated with the incoming message. More specifically, in accordance with aspects of the invention, such procedures or interfaces comprise (a) processing the exchange of information and messages with billing services via billing interface 155; (b) processing the exchange of information and messages with the user or administrator accessing the Internet via the Internet application interface 154; (c) processing messaging and messages with mobile devices via the mobile device communication interface 152; (d) processing the exchange of information and messages related to the payment of interpersonal (P2P) type through the service 375 interpersonal payments; (e) processing the exchange of information and messages related to the user's financial accounts through the 545 financial account service; and (f) processing the exchange of information and messages related to financial service providers (FSPs) via the FSP communication interface 156.

As briefly described above in connection with FIG. 3B, a user of a mobile device may wish to register as a registered member of the MFTS, after receiving payment from a registered user, or of his / her own free will. The user can access the site designated by the MFTS using his / her computer connected to the Internet and a web browser to use the Internet application. The site may contain information related to the services and benefits provided by MFTS, and a special page for registering the user. If the user decides to sign up, then he / she accesses the Internet application, which is executed by the Internet application interface 154, and selects a function to execute.

As generally shown in FIG. 3B, typical Internet application features provided to a user include the following:

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

2. Editing a mobile client, including adding, editing, viewing, and deleting a mobile client (see Fig. 37B and 37D for a preferred embodiment and Fig. 40 for an alternative embodiment);

3. Editing mobile card accounts and / or bank accounts, including adding, editing, viewing and deleting mobile card accounts and / or bank accounts (see Fig. 38A-D for a preferred embodiment and Fig. 42 for an alternative implementation);

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

5. Initializing a mobile client, including downloading software to a designated mobile device, setting a password, and activating the mobile device (see FIGS. 37A and 37C for the preferred embodiment); and

6. Unlocking the mobile client after the mobile device is blocked (perhaps by accident or to prevent fraud) through a predetermined number of failed logins (see FIG. 37A for the preferred embodiment).

Returning to FIG. 5, after each function is completed, the main MFTS program 350 continues to run, returning to the beginning of the loop to check for new input in steps 505, 510, 515 and 520.

DATABASE AND USER SCHEMES

Although not specifically shown as an independent step or process in FIG. 5, but shown in FIG. 3B, those skilled in the art will understand that the MFTS 18 includes a storage / database (DB) interface 377 for storing and retrieving data to and from the MFTS user database 158. This database 158 stores two main categories of data: user data and transaction data. User data contains information about individual users of the system, including their respective payees, financial institutions and accounts. Transaction data contains information that is specific to a particular transaction of a particular user, for example, when a user instructs the system to pay a specific bill. Transaction information is a record of each transaction that is initiated by the user. Both transaction data and user data are stored in tables in the database 158 of user data in a specific format or scheme, in accordance with aspects of the invention.

FIG. 6 illustrates database schemas (data table formats) for user database 158 in a mobile financial transaction system (MFTS) according to an exemplary aspect of the invention. The user database 158 contains several data tables that are related: a table of 610 main users, a table of 620 financial accounts of users, a table of 630 financial service providers and a table of 640 payees. These tables store data associatively associated with users, user accounts, financial service providers (sources of payments) associatively associated with users, and payees associatively associated with users. As is known to those skilled in the art, database tables typically contain a plurality of records, each record containing one or more fields or data elements that are associated. In addition, those skilled in the art will understand that a “record”, in a database language, is a single instance or data item, usually consisting of a set of one or more fields or sub-elements of information, each field or sub-element typically has a field identifier in a circuit, which identifies what the information in the field represents; An array or set of multiple records is often referred to as a “table” or “database”. Databases or tables often include one or more index fields or items that provide quick access to a specific record, so that the record can be identified, retrieved, and used in a transaction or updated with new information as necessary.

The main user table 610 contains a set of information (record) for each registered MFTS user. In one aspect of the invention, as shown in FIG. 6, the set of information contains a user identifier or user ID, a name (for example, a full user name), a user name (for example, a registration name associated with the user) and other information that provides a specific user of the system with the opportunity to be identified as registered to use the system . Additional information that may be included in the user table 610 contains an account number (for example, a user account number with an entity that operates the MFTS), user contact information such as a mailing address, community telephone number and mobile phone number, telephone number for a mobile device associated with the MFTS, email address and password, etc. As will be appreciated, the mobile device will typically supply a user ID in some form to the MFTS when the user logs in to enable the system to authenticate the user in order to use the system to make payments, view bills for payment, receive account balances in real time, etc., in accordance with various aspects of the invention.

The set of information in table 610 of the main users preferably additionally contains pointers to subjects in table 620 of financial accounts of users, table 630 of financial service providers and table 640 payees associated with the user. As is known to those skilled in the art, a “pointer” in a database is information that provides a computer program module with the ability to localize and retrieve related information in another table in the database.

In accordance with an aspect of the invention, each user may have multiple financial accounts and multiple financial service providers for such accounts. For each user, table 620 of financial accounts of users contains information about one or more user accounts with at least one financial institution or financial services provider (FSP), which information includes the account number of the user with a specific financial institution, the type of financial account (for example , on demand, savings, credit card, currency, etc.), the user's account number in his / her financial institution, an index or pointer to a specific financial institution (shown as as “FSP ID” (provider number)) or a provider in table 630 of financial service providers, etc. Other information relating to the identification and / or use of the user's financial accounts may also be stored and assumed.

Table 630 of financial service providers contains information corresponding to one or more financial service providers associated with the user. For each occurrence of the financial service provider in table 630, the table includes information including, but not limited to, a serial number and / or identifier (ID) associated with an associative financial account in table 620 of the financial accounts of users, the name and / or pseudonym of the provider, the type of service provided (for example, billing, bank, credit source, etc.), the account number of the financial services provider (not shown), an associated password (n shown), the contact information of the account holder, the inspection data, etc. Other information related to the identification and / or use of the user's financial services providers may also be stored and assumed.

Information about payees is stored in table 640 payees. Information about payees is information that is necessary to identify the specific payee to whom the payment was sent or can be sent, and how such a payee should be paid. Multiple payees can be configured for each MFTS user. Payees can be billing entities that provide services such as water, gas, electricity, communications services such as local telephone or mobile phone services, mortgages, credit cards, and / or other companies issuing monthly bills or otherwise issuing invoices for payment on a regular basis. On the other hand, recipients of payments can also be an individual (for example, a person of the same circle with the user, colleague, acquaintance, relative, etc.), in relation to whom the user may have a payment obligation that happens from time to time. Payee table 640 contains information relating to or associating a particular user with one or more payees, including an account number or identifier associative with an MFTS user that associates that payee with a specific user, payee number or identifier (e.g. , Payee ID), which identifies the payee, account number associated with the payee, payment deadlines, permission on the board Well, etc. Other information relating to the identification and / or use of the recipients of the user's payments may also be stored and assumed. In accordance with aspects of the invention, a specific payee associated with the user is identified in the payee table 640 by providing information to the MFTS via a mobile payment order that prompts the MFTS to access the table 640 to obtain information about the payee, so that the payment may be made to such payee.

Next, with reference to FIG. 7, a transaction table 710 is maintained in a transaction database 705 for storing information related to mobile transactions, such as requests for balances in payment sources, requests for payments for production, and payments made by a user. Specialists in the art will understand that each payment or each request transaction from a mobile device results in the creation of at least one record, which is stored in the transaction table, in order to create an audit trail, dated transaction records and facilitate database commit and rollback operations . Each transaction record contains information including, but not limited to: transaction identifier (unique identifier), date and time stamp for start and end, user name or ID, or both selected one or more financial institution related transactions , their names or pseudonyms, or coded identifiers, the selected account, transaction type, timers for synchronized responses, the amount of balances for each account related to the request, the amount of the debit balance having about Wearing a request accounts payable, the name or identifier of a coded payee, or both, phone number, payee, amount paid, the flag state relating to the payment as pending / completed. It will be appreciated that a transaction is typically initiated on a mobile device, but can also be started by user 12 using an Internet application. The transaction is sent to the MFTS. The MFTS processes the request or payment, creates a transaction record 715 corresponding to the transaction in the transaction table 710 of the transaction database 705, creates the MFTS payment order (MFTSPI) for the selected specific financial institution or payment source (PS), and transfers the MFTSPI to such financial institution or PS. After completing the payment by PS and receiving the payment confirmation message back from PS, the corresponding transaction record 715 in table 710 is updated to indicate that the payment has been completed, for example, by changing the status flag from pending to completed. According to one embodiment of the present invention, the record for the completed transaction is transferred to the event log, according to its completion time, for the archive. Other information related to transactions and their status can also be stored and assumed.

MOBILE APPLICATION SEQUENCE BLOCK DIAGRAMS

The flowcharts of mobile application applications are shown in FIG. 8-9 according to embodiments of the present invention. In FIG. 3A, the mobile device communication interface 339 is used to facilitate communication between the main mobile device program 335 and the mobile device radio communication hardware 343. The mobile device communication interface 339 communicates with the MFTS mobile communication interface 150 in the MFTS 18 by wirelessly exchanging information through the MCSP 110.

A flowchart of an MFTS mobile communication interface 150 is shown in FIG. 8. It will be understood that this process 150 on the MFTS side communicates with similar processes on the mobile device via the mobile device communication interface 339 on the mobile device. In this flowchart, the MFTS mobile device communication interface 150 first establishes a communication line with a mobile service provider (MCSP) to which the user has subscribed, at step 805. The mobile device communication interface is configured between the mobile device and the MCSP, and the interface receives the transmission data on both sides. The mobile device communication interface 150 comprises a continuous loop, shown in block 810, to check whether any message has been received from the MCSP or the mobile device. If no message is received, the loop continues until a new message is received. When the mobile communication interface 150 receives a message, it checks at step 815 to determine where the message is coming from by checking the sender / receiver information. If the message arrives from a mobile device that requests information from the MFTS server, the mobile device application proceeds to step 840 to add the task to the processing queue and set a timer to wait for a response from the MFTS server through the MCSP, at step 845. The communication interface of the mobile device waits until as long as it does not receive a response from the MFTS server or the timer expires, whichever comes first. If the communication interface of the mobile device receives a response within a predetermined time limit period, a message is sent to the mobile device at step 850. Otherwise, if the communication interface 150 of the mobile MFTS devices does not receive any response in time, an error message is sent to the mobile device notifying the user of failure that occurred. Both, step 850 and step 820 converge at step 825 to extract a subset of the information from the message or response received from the MCSP. The information extracted in step 825 is sent to the user's mobile device for display in step 830. After the message is displayed, the communication interface of the mobile device returns to the previous state to wait for the next message in step 860 until the user turns off the mobile device and does not complete the mobile device application.

MOBILE CLIENT SECURITY ASPECTS

In order to use the MFTS 18, a user 12 with a suitable mobile device 15 must register for service with a person who operates the MFTS 18 constructed in accordance with exemplary aspects of the invention. The sequence of registration operations necessarily includes entering and saving important personal and financial information about the user manually or through an external system. The safety and security of personal and financial information makes it mandatory for MFTS 18 to provide guarantees and security measures from MFTS administrators. According to an exemplary aspect of the invention, the disclosed MFTS 18 implements strict security measures at both ends of the mobile communications: (1) in the mobile client, and (2) in the MFTS server system itself. In accordance with exemplary aspects of the invention, one or more of the following security measures are implemented in the MFTS 18 regarding communication with mobile devices:

Secure delivery of a mobile client: In accordance with one aspect of the invention, a mobile application is delivered (eg, via download) to a mobile device using a secure wireless delivery method. In accordance with this aspect, a mobile application is created as a wirelessly delivered or downloadable application or “applet” that is downloaded to a mobile phone from a central site, for example, from the MFTS 18. Those skilled in the art will understand that there is currently a number of different, but generally equivalent, programming environments to develop applications for various types of mobile phones and wireless data technologies.

One well-known secure delivery methodology is the BREW ™ Wireless Content Delivery Platform for CDMA Communications Technologies, supplied by Qualcomm. Details of the application development and delivery methodology for Qualcomm-compatible mobile devices are available for purchase from the manufacturer.

Another delivery method is through a JAVA ™ archive file, also called a JAR, a platform for which is available from Sun Microsystems. In this case, the mobile application is created as a downloadable JAVA ™ application, which is downloaded to a JAVA-compatible mobile phone. Those skilled in the art will understand that the Java programming environment for portable devices (J2ME) can be used to develop applications for certain types of mobile phones (e.g. Motorola). Such applications are also called “applets” or “midlets,” but they are essentially computer programs that operate within the specific operating environment of a particular type of mobile phone. Details about the J2ME application development environment are available from the manufacturer.

Preferably, the JAR file used to distribute the mobile client application is digitally signed with a program digital signature key issued by the MFTS 18 authentication process, for example, a digital key process supplied by VeriSign. This enables users to verify the authenticity of the mobile device application. Details on VeriSign’s mobile security technologies are available in the VeriSign literature and website.

SSL data transmission to the MFTS server: Those skilled in the art will understand the importance of security for the exchange of information between users and the MFTS 18 through a mobile device or through a web interface. Accordingly, preferably, all HTTP information transfers to the server in MFTS 18 are via HTTPS (secure HTTP), that is, they are protected using the well-known Secure Sockets Layer (SSL) protocol. As will be known to those skilled in the art, SSL is a protocol developed by Netscape Communications Corporation for transmitting private legal documents over the Internet. SSL uses a cryptographic system that uses two keys to encrypt data - a public key known to everyone, and a private or 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 can be implemented for wireless communications by using the well-known transport layer security protocol for wireless communications (WTLS). However, it will be understood that WTLS may not be as secure as the SSL protocol, as it uses weaker encryption algorithms, and several protocol applications have been identified. In addition, data transmitted using WTLS is decrypted at the WAP gateway and re-encrypted via SSL for the destination host, which provides for the possibility of compromising the WAP gateway in order to intercept delicate data transfers.

The MFTS mobile client application preferably creates a direct SSL connection to the MFTS server and is not so susceptible to security issues that plague WTLS and WAP applications. Therefore, it will be appreciated that if HTTPS is used for all interactions between the mobile client and the MFTS server, the underlying mobile data technology, such as GPRS and CDMA, between the mobile device and the MFTS should not have any significant negative impact on the provision of data security for transactions.

Digital keys on the client: According to another exemplary aspect of the invention, a unique digital key is issued to each client (mobile device) for use in digitally signing all messages to the MFTS server. This strictly authenticates the mobile client in relation to the server and discourages attempts to imitate or carry out unauthorized access on behalf of the mobile client. It will be appreciated that such a methodology provides more powerful security than online banking sites that require only a username and password for access, which are much easier to compromise than digital keys. It is assumed that using the MFTS mobile client to access financial services is equivalent, if not more secure, than browser-based online banking systems that require only a password for authentication.

PIN required to unlock the client: According to another aspect of the invention, additional security for the mobile device 15 is provided by requiring the user to enter a PIN to unlock the mobile client each time it starts. This prevents the use of the application if the phone is stolen or “borrowed”. PIN locking is also preferably implemented in the mobile client, so that the client will limit functionality after several failed login attempts and prevent further attempts until the client is unlocked by a user who is in contact with support or logging into the MFTS system (for example, via the Internet application) and the caller to unlock the mobile client. This prevents attempts to use “brute force” to unravel the PIN. It will be appreciated that the combination of a PIN and a digital certificate creates a two-factor authentication mechanism for using mobile wallet software 400 on a mobile device.

Decommissioning the mobile client in the event of theft or loss: If the user's mobile device is stolen or lost, the user can access the MFTS 18 through the Internet application to disable the mobile client. This will prevent further information exchange between the mobile client and the MFTS and remove all demographic information from the mobile client about the user's mobile wallet.

Encryption of data located in the local storage device: All data placed in the local storage device on the mobile device 15 is preferably encrypted. This ensures that if the mobile device is lost or stolen, the data stored in the mobile client in the local storage device is unreadable. However, it will be taken into account that, since the mobile device does not store complete information regarding accounts, banks, account numbers, etc., of the user, but stores only an abbreviated set of information represented by codes, the risk of compromising user confidential information is reduced . For example, the mobile device only stores information indicating that the user has an account, for example, My on demand or xxxxxx2125), but the user account number is stored in MFTS 18, and not in the mobile device. This aspect is intended to be a specific advantage of the architecture of the mobile financial transaction system constructed in accordance with the present invention - providing and storing a reduced subset of information in a mobile device, with more complete information stored on a secure server, improves overall security for mobile transactions.

Verification of ownership of a phone number: In accordance with yet another aspect, additional security is ensured by verifying that a payment order is generated from a specific mobile number associated with the user. This security measure is implemented in the disclosed embodiment by providing the mobile number associated with the mobile device as part of the mobile payment order (MPI) in the MFTS 18, preferably encrypted with other MPI information. MFTS is MPI responsive for parsing a mobile number and determining whether a payment order has been generated from a mobile number that is compatible with both, an account identified as a payment source (PS), and the name of the payee as already entered and saved in the table of payees in the user database.

According to another exemplary aspect of the invention, during the registration process, an SMS message containing a predefined verification code is sent to the phone number entered when setting up the mobile client. This code must be entered by the user, interactively, in the Internet application 153 of the user site in order to successfully initialize the mobile client for work. This protects a person from registering a phone number that he does not own, with the intent of fraud.

One-time password used to initialize the mobile client: In addition, additional security is provided by the requirement to enter the initialization code or password the first time the mobile client is launched to initiate the formation and installation of a digital client certificate. This initialization code is a one-time expiring one-time password that is given to the user in the user site’s Internet application 153 during the initialization sequence for the mobile client. This sequence of operations establishes a difficult to fake connection between the user account and the mobile client instance on the user's mobile device.

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

1. A user with a computer accessible via the Internet (for example, computer 140 in FIG. 2) navigates to the Internet application 153 of the user site accessible via the Internet in his browser and fills out the registration form displayed by the Internet application. (Not shown.) The user provides the requested information by entering information in the appropriate fields in the displayed data entry form. Alternatively, the registration could be implemented by a third party registration system with which the MFTS system operator maintains relationships, for example, with an associated financial service provider.

2. When the registration is completed, the user accesses the mobile client management section of the user site’s Internet application 153 and adds a new mobile client. Alternatively, the addition of a new mobile client could be implemented by a process provided by a third party with which the MFTS system operator maintains a relationship, for example, an associate financial service provider or a mobile service provider.

3. The user then enters the phone number of the mobile device on which he / she wishes to install the mobile client and clicks the initialization button.

4. Another step includes the formation of a verification code to activate the mobile client on the mobile device:

(a) In accordance with one exemplary aspect of the invention, the MFTS 18 sends an SMS to a predetermined phone number; This SMS contains a verification code. The user is then invited by the mobile application to enter the verification code to activate the mobile client for transactions.

(b) In accordance with another aspect, the user views the verification code in SMS and enters the verification code into the browser reconciliation screen in the Internet application 153 of the user site. Presumably, a mobile phone with a verification code will be in the direct ownership of the user during registration. The user then clicks on the “verify” button to activate the mobile application.

5. Another step includes generating the initialization code and downloading the mobile application to the mobile device (for a new installation of the mobile device software):

(a) According to one exemplary aspect of the invention, a user with Internet access to an Internet application of a user site is then provided with an initialization code for a mobile client. This initialization code is later entered into the mobile device (see below) at the invitation to activate the mobile client.

(b) According to another exemplary aspect of the invention, on a mobile device, the MFTS 18 sends a second SMS to the mobile device that contains a click-activated hyperlink to download the mobile client. The user then clicks on the hyperlink and downloads the application to the mobile device.

6. After the mobile client is completed downloading to the device and activated by the user, it can present a screen with an invitation for the initialization code. The user will then enter the initialization code into the mobile client.

7. The initialization code is then transmitted from the mobile device 15 to the MFTS 18 to be used to authenticate the device and the mobile client. When a valid initialization code is received by the MFTS 18, a unique digital key is placed in the mobile client.

8. After receiving the digital certificate from MFTS 18, the mobile client then invites the user to enter and confirm the PIN.

9. After the PIN is accepted and saved, the mobile device is ready for use and displays the main menu screen, which provides the ability to enter billing entities, payment sources, view account balances that were previously entered by the user through the Internet application 153 user site, etc.

MFTS SERVER SECURITY ASPECTS

In accordance with exemplary aspects of the invention, various security measures are implemented in MFTS 18 by various software procedures for various entities with which the MFTS communicates. One or more of the following security measures are implemented in the preferred MFTS 18:

Internet applications require SSL: Preferably, externally accessible Internet applications that run on MFTS 18 (for example, Internet applications 154, including user site 153 and administration site 157) only allow secure SSL connections. If the user tries to initiate a simple HTTP connection with one of the Internet applications, he will be redirected to the HTTPS connection.

Password complexity requirements: Passwords for logging into the Internet application system should preferably satisfy the most stringent complexity requirements. Password protection can be implemented at various stages of work.

Account Lockout and Password Reset: Preferably, but not necessarily, the accounts will be blocked after several failed attempts to enter the user’s website’s Internet application 153. Users whose accounts have been locked will be forced to activate the Unlock account feature provided on user site 153 and enter the correct answer to the password reset question that he set during registration to unlock the client and reset his password. If the user is not able to remember the correct answer, he will have to make contact with the consumer service channel (website, representative, etc.) in order to get his account unlocked and his password reset.

Securing FSP Interfaces : Interfaces in an FSP are preferably protected by mechanisms consistent with the nature of the interface and / or required by a particular FSP. Any interface that uses the public Internet to transmit data is preferably protected by encryption and authentication requirements that are acceptable in the financial services industry. Details of the security requirements for exchanging information with specific FSPs should be obtained from the FSP.

From the foregoing, it will be understood and taken into account that various mechanisms may be used, singly or in combination, to guarantee security in the same way as described above for exchanging information with MFTS 18, via mobile devices 15 or via user site 153. Other measures and safety technologies are apparent to those skilled in the art, while remaining within the scope of the invention.

MFTS INTERFACE SOFTWARE PROCEDURES

As described in connection with FIG. 3B and FIG. 5, the MFTS software 500 comprises various program modules, including the main program 350 (FIG. 5) and various communication interfaces for processing messages and functions associated with various entities involved in a system constructed in accordance with the disclosed aspects of the invention . Other software or program modules include an MFTS mobile communication interface 150, an Internet application interface 154, a financial service provider communication interface 156, and a billing interface 155. Additional software system procedures include the 375 P2P service, the SMS shaper 151, and the financial account service 379.

Next, refer to FIG. 8 for describing a software or procedure 150 for a MFTS mobile communications interface in accordance with an aspect of the invention. The MFTS Mobile Device Interface software 150 preferably operates as a continuous, independent process on the MFTS server computer asynchronous to other processes, and provides for the processing of information and message exchange between the MFTS 18 and user mobile devices. When using the term “interface”, we mean a computer program or procedure 150 and associated hardware such as communication components or a storage element that are controlled by the program. The interface 150 manages the exchange of messages between the various processes in the MFTS 18 and mobile devices, for example, when the user on the mobile device generates the command “View invoices for payment” or “Pay bills”, such a command is received via a wireless network and processed by the interface 150 for communicating with mobile devices MFTS, as described herein, to cause the MFTS 18 to perform functions in accordance with the invention.

Starting at step 805, the first step taken is for the interface to communicate with the mobile communication network, that is, with specific mobile service providers (MCSPs), so that communication can be established between the MFTS 18 and mobile devices that subscribe to services with specific networks. Essentially, this is an initialization process that includes identifying the appropriate protocols for exchanging information with an individual MCSP and establishing contact with the MCSP through messaging in some way appropriate to the communication protocol. After establishing a connection, the interface checks, at 810, to receive a message coming from a mobile device or from another process within the MFTS 18, for example, if a billing entity or a billing system delivers information about a new account to payment for a specific user.

At 815, the interface determines whether the incoming message is a task-initiating message (e.g., from a mobile device in an attached mobile network) or is a message from another MFTS process (e.g., a response message from FSP interface 156). If the incoming message is a task-initiating message, the flow proceeds to block 840, where a new processing task is created and added to the processing queue for interface 150. For example, the processing task output from the incoming message of the mobile device may be a mobile payment order (MPI) , or the command “View invoices for payment”, or “Transfer balances” or other of the various functions of a mobile wallet. Typically, the processing task will generate a new transaction record, which is stored in the transaction table in the user database 158. Thus, at step 842, a new transaction record (if predefined for the incoming message) is created and stored in the transaction database.

At step 845, the interface sets a timer (a predetermined time period) suitable for a particular task and process, and initiates a time cycle. Control then proceeds to block 850, where the interface checks for the expiration of a predetermined period of time. If the timer expired, a malfunction occurred (the task added to the queue was not processed in time properly), and, at step 855, an error message is generated and sent to the mobile device of the user who initiated the task.

If the appropriate response from the queued task is received within a predetermined time, control proceeds from block 850 to block 860, where the transaction record created in conjunction with the incoming message is updated with any information that results from processing the queued task. For example, if the task involved making a payment using a specific source of payment to a specific payee, and the payment was accepted and processed on time by the selected financial service provider, the transaction record is updated to indicate confirmation of payment.

After the transaction record is updated (if applicable), control proceeds to step 870, and the corresponding message related to the task initiating message is sent to the requesting user’s mobile device or other task initiating process. For example, if a payment order was received from a mobile user, and such a payment order was processed on time and properly, a payment confirmation message is sent to the user's mobile device.

Returning to step 815 in FIG. 8, if the MFTS mobile communication interface 150 determines that an incoming message originates from another MFTS process (eg, a response message or another non-initiating message), control proceeds to block 820 where the message is processed. For example, a message from another MFTS process might be a message delivered by a billing system that a new invoice for payment was accepted for a particular user, or a message delivered by a financial services provider with information regarding balances available on specific accounts for a specific user. In accordance with aspects of the invention, communication from various other processes and associated entities may include information that is not required by the mobile device interface, that is, only a reduced set of information should be delivered to the mobile device. More precisely, the financial services provider (FSP) 30 can deliver information about a user's financial accounts that is more comprehensive (i.e., “redundant”) than that required for display and processing on a mobile device, because all of the information is from FSP is optional and not desirable for display on a mobile device. In such cases, an abbreviated set of information suitable for display on a mobile device, as shown in various exemplary displays of a mobile device shown elsewhere in this document, is prepared for sending to the mobile device as a message. In this case, at step 825, a subset of the information that was received and / or stored in the MFTS is prepared for transmission to the mobile device of the selected user.

Control proceeds from step 825 to step 860, where any relevant transaction records associated with the message (if any) are updated with information from the MFTS process message. Then, at step 870, a proper message to the mobile device corresponding to the information in the message being processed (step 810) is prepared for transmission to the mobile device. The sequence of operations 150 returns to the beginning of the cycle to process any other messages that may have arrived.

After block 870, the process flow 150 returns to the beginning of the loop at block 810 to process other incoming messages. From the foregoing, those skilled in the art will understand and take into account how the MFTS mobile communications interface 150 is valid for processing messages from mobile devices or from other MFTS processes, transmitting relevant information as tasks for processing by other MFTS processes, and updating any relevant transactions or user database entries and / or the transmission of appropriate returned messages to the user's mobile device or other message-delivering source .

Next, refer to FIG. 9 to describe software or procedure 156 of a financial service provider interface (FSP) in accordance with an aspect of the invention. The Financial Service Provider Interface (FSP) 156 preferably operates as a continuous, independent process on the MFTS server computer asynchronous to other processes, and provides for processing information and message exchanges between the MFTS 18 and user financial service providers.

Although FIG. 9 shows exemplary steps of an interface for exchanging information between MFTS 18 and one or more FSP 30, it should be understood that a similar methodology is used for billing interface 155, financial account service 379 (for third party user authentication), P2P service 375. All are similar continuous, independent asynchronous computer-implemented processes that receive messages from another MFTS process, or from a third party connected to exchange information with the MFTS, process such messages, determining the appropriate destination (for example, storing data in a 158 database users to update user information, or to create and update transaction records, transfer to a mobile device, etc.) and sending processed information to such destinations. Accordingly, a discussion of FIG. 9 will be understood as generally applicable to other processes of communication interfaces, except when it is protested.

Starting at step 905, the first step taken is for the interface 156 to communicate with the financial services provider 30 (FSP), so that communication can be established between the MFTS 18 and the FSP. Essentially, this is an initialization process that includes identifying the appropriate protocols for exchanging information with a particular FSP and establishing contact with the FSP through messaging in some way appropriate to the communication protocol. After establishing a connection, the interface checks, at 910, to receive a message coming from a mobile device (via the MFTS mobile device communication interface 150) or from another process within the MFTS 18, for example, if a user initiated a transaction via the Internet application interface 154 .

At step 915, the interface determines whether the incoming message is a task-initiating message or a return / response message from the FSP 30. The task-initiating message is a message that causes the interface to begin transmitting data to a specific FSP 30, for example, from a mobile device (mobile device communication interface 150 MFTS) or from another MFTS process, such as a payment order initiated by an Internet application. If the incoming message is a task-initiating message, the process proceeds to step 940, where a new processing task is created and added to the processing queue for the interface 156. For example, the processing task output from the incoming message of the mobile device may be a mobile payment order (MPI) , or the command “Pay bill”, or “Transfer balances” or “View transaction sources”, or others from various functions of a mobile wallet. For the FSP communication interface 156, a typical new processing task is in the form of an MFTS payment order (MFTSPI), which is transmitted to the selected FSP 30 in order to order such an FSP to make a payment on behalf of the user, using the selected account as the payment source (PS) .

As mentioned in connection with FIG. 8, and in accordance with an exemplary aspect of the invention, the processing task derived from the incoming message of the mobile device generates a new transaction record, which is stored in the transaction table in the user database 158. It will be understood that the information from this transaction record is used in the processing task for the queue in the interface 156, for example, when compiling the information required for the MFTSPI by the selected FSP 30. In addition, it will be clear that the transaction record is updated, if necessary, with information from the FSP according to receiving an answer.

At step 945, the interface sets a timer (a predetermined time period) suitable for a particular task and process, and initiates a time cycle. Control then proceeds to step 950, where the interface checks for the expiration of a predetermined period of time. If the timer expired, a malfunction occurred (the task added to the queue was not processed in time properly), and, at step 955, an error message is generated and sent to the process that initiated the task.

If the appropriate response from the queued task is received within a predetermined time (for example, a response from the FSP containing information about the balance in the user’s account, payment confirmation, or other information), control proceeds from step 950 to step 960, where the transaction record created in connection with the incoming message is updated with any information that is a consequence of processing the queued task. For example, if the task involved making a payment using a specific source of payment to a particular payee, and the payment was accepted and processed on time by the selected financial service provider, the transaction record may be updated to indicate confirmation of payment. As discussed in connection with FIG. 8, the MFTS mobile communication interface 150 may be responsible for updating the corresponding transaction record, but it will be appreciated that other circumstances may require the FSP communication interface to update the transaction record. Other information associated with the task and received from the FSP may also result in updating other entries in the user data base 158, for example, adding a new user account to the selected FSP will require adding an entry in table 620 of the financial user accounts (Fig. 6), or the closed account status of a specific FSP with the user will require updating (or deleting) the entries in the table 630 of financial service providers (Fig. 6).

After the transaction record or other user database table is updated (if applicable) at step 960, control proceeds to step 970, and the corresponding message related to the response from the FSP is sent to the process that initiated the communication, for example, to a mobile device the requesting user. For example, if a payment order was received from a mobile user, and such a payment order was processed by the selected FSP on time and appropriately, a payment confirmation message is sent to the user's mobile device. In accordance with an exemplary aspect of the invention, messages of this type, such as a confirmation message, are in the form of a message sent to the communication interface 150 of the mobile MFTS devices.

Returning to step 915 in FIG. 9, if the FSP communication interface determines that the incoming message originates from the FSP (as opposed to the mobile device communication interface or another task triggering interface), control proceeds to block 820, where the message is processed, and any response information from the FSP is received. After step 920, control proceeds to step 970, where information corresponding to the message from the FSP is sent to the scheduled destination, for example, to the mobile device communication interface or the Internet application interface that initiated the payment order.

After step 970, the sequence of operations 156 returns to the beginning of the cycle at step 910 to process other incoming messages. From the foregoing, those skilled in the art will understand and take into account how the FSP communication interface 156 is operational for processing messages from various MFTS processes (such as from the MFTS mobile communication interface 150), transmitting relevant information to selected FSPs, and receiving a response messages, updates to any relevant transactions or user database entries and / or the transmission of appropriate returned messages to the user's mobile device or other message delivery sources nicks.

Then, referring to FIG. 10 to describe software or an Internet application interface procedure 150 in accordance with an aspect of the invention. The Internet application interface 154 preferably operates as a continuous independent process on the MFTS server computer, asynchronous to other processes, and provides for the processing of information and message exchange between the MFTS 18 and users who access the MFTS via the Internet 120 using a web browser on the computer 140 (FIG. 2), as opposed to a mobile device. As will be understood by those skilled in the art, the Internet application interface serves as the main program cycle for displaying a web page accessible on the Internet (such as the user site shown in FIG. 37) for user access to the MFTS 18 via the Internet, to conduct transactions, view account history, add payees, add financial institutions and accounts, etc. It will be recalled from FIG. 3B that, in accordance with exemplary aspects of the invention, the Internet application interface 154 provides several basic functions available on the Internet, including registering a new user, editing a mobile client, editing a credit card or bank account, adding a new payee, or editing information about the payee, initializing the mobile client, unlocking the mobile client and other operations.

Starting in FIG. 10 from step 1005, the first step undertaken by the Internet application interface software 154 is to initialize the interface so that it is ready to communicate with users via the Internet. Those skilled in the art will understand that such initialization operations entail the initialization of any associated hardware so that they can send and receive TCP / IP packets (Transmission Control Protocol / Internet Protocol), which are traditional for Internet communications. . The control then proceeds to step 1010, where the sequence of operations loops, waiting for the TCP / IP packet (s) to be received from the web browser of the user or intended user who is navigating to the user site. In response to receiving the packet (s), control proceeds to step 1015, where the packets are received and parsed to determine their content.

After step 1015, control proceeds to step 1020 of the request, at which a request is made whether the user sending the packets has been authenticated and if the communication session has been established. If not, control proceeds to block 1025, where a login operation is performed (i.e., user authentication and session establishment), in a manner that is known to those skilled in the art. If the user cannot be authenticated, other sequences of operations (not shown) are performed to enable the new user to sign up or register, or the person trying to exchange information with the MFTS is denied access (i.e., the packet (s) are ignored or discarded). If at step 1020 the user was previously authenticated in a previous operation and the session was established, or after the login / authentication step 1025, control proceeds to step 1030 to display the appropriate information corresponding to the current session state.

At 1030, the Internet application interface 154 delivers returned packets to the user corresponding to the display of the 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 traditional user login screen is displayed for entering a username and password (not shown). As another example, if a user is in the process of managing information about his mobile device, a user site screen is displayed, as shown in FIG. 37A. As another example, if a user adds or edits information about a mobile device, a user site screen is displayed, as shown in FIG. 37B.

After display step 1030, control proceeds to step 1040, where the interface receives and processes any packet (s) that includes information entered by the user in response to the displayed web page. Subsequently, at step 1045, the interface stores any received information from the user and generates some message (s) that would be required for delivery to other processes or interfaces in MFTS 18. For example, user input may require updates with respect to certain tables in the database 158 user data, or may require the formation of a payment order or the command “View invoices for payment”, which requires the transfer of 30 financial services to the provider.

Control then proceeds to step 150, where the interface determines whether any messages have been received from any process or interfaces in the MFTS. For example, if user input required the formation of a payment order or the “View invoices for payment” command, which required transfer to FSP, as a result, a returned or response message containing the requested information will be returned to the Internet application interface. If such a message is received, control proceeds to block 1055, where the message is processed, which may include updating the web page with any information in the received message. From step 1050 (if no message was received from another process) or from step 1055 (after processing any message), control returns to step 1010 to wait for further user interaction of the Internet application, that is, to receive additional packets.

From the foregoing, those skilled in the art will understand and take into account how the Internet application interface 154 is valid for processing Internet interactions from a user via the Internet or from other MFTS processes.

From the discussion above, the interface 154 of Internet applications provides several functions available on the Internet, such as registering a new user, editing a mobile client, editing a credit card or bank account, adding a new payee or editing information about a payee, initializing a mobile client unlocking mobile client and other operations. One of these exemplary functions is the registration of a new user, that is, the person must register or register to use the services provided by the MFTS operator. According to an aspect of the invention, a new user can access the MFTS 18 via the Internet and deliver information to the system for recording service.

Turning now to FIG. 11 to discuss an Internet application 1100 regarding registering a new user to use the MFTS 18 in accordance with exemplary aspects of the invention. The new user Internet application 1100 is exemplary regarding a process that is a child of the main user interface 154 of the Internet application of FIG. 10, for the reason that the process of FIG. 11 uses the web interface 154 to interact with the user over the Internet, but the steps of FIG. 11 are specific to the process of registering a new user. More specifically, it will be understood that the new user will not go through the authentication step in FIG. 10, and typically, a “new user” web page will be provided to him, which includes controls that enable the user to enter personal information and configure an account.

Starting at step 1105 in FIG. 11, the MFTS generates a “register a new user” web page (not shown) that includes the information required by the new user and provides controls and data entry fields for entering information required by the MFTS to register a new user. At step 1110, the new user enters the information indicated on the "register a new user" web page, for example, name, address, phone number, email address, and other information. A registering user must also enter certain information about billing entities (i.e., payees), financial institutions or financial service providers (FSPs) 30 with whom the new user maintains relationships and accounts, and information about specific accounts served by such financial institutions or FSP, which can be selected as a source of payment. At step 1115, the system checks the user command to edit the information about the invoice for payment to the subject or source of payment. If the team is associated with the billing entity, the control branches to block 1120, where the system checks the command to enter a new billing entity or edit information about an existing billing entity (for example, if one or more billing entities payable entities have already been introduced during this registration a new user at this stage during processing).

At step 1120, if a command has been received to enter information about the new billing entity, the control proceeds to step 1125 to receive and store information about the new billing entity or payee. It will be understood that information about the subject of the invoice for payment is stored in the payee table in the user data base 158 (see FIG. 6). If no command has been received to enter information about the new billing entity, the control proceeds to step 1130 to check for a command to edit the existing billing entity. At step 1130, if a command has been received to edit information about an existing billing entity, control proceeds to step 1135 to receive and save editable information about an existing billing entity or payee. Upon completion of the input or editing of any invoice for payment by the subject, the control proceeds to step 1160 and returns to the beginning of the cycle to step 1115 or checks for the user's exit from the system.

Returning to step 1115, the system checks for the user command to edit the information about the invoice for payment to the subject or source of payment. If the team is associated with a payment source, such as a financial institution or financial services partner, the control branches to block 1140, where the system checks the command to enter a new payment source or edit information about an existing payment source (for example, if one or more payment sources a new user has already been introduced during this registration at this stage during processing).

At step 1140, if a command was received to enter information about the new payment source, control proceeds to step 1145 to receive and store information about the new payment source. It will be understood that information about the source of payment is stored in the table of user financial accounts and / or the table of financial service providers in the database 158 of user data (see Fig. 6). If no command is received to enter information about the new payment source, control proceeds to step 1150 to check for a command to edit an existing payment source. At step 1150, if a command was received to edit information about an existing payment source, control proceeds to step 1155 to receive and save editable information about an existing payment source. Upon completion of the input or editing of any payment source, the control proceeds to step 1160 and returns to the beginning of the cycle to step 1115 or checks for the user's exit from the system.

Next, refer to FIG. 12 to discuss an Internet application of 1200 registered users, which provides a registered or recorded user with the ability to access and use the MFTS 18 in accordance with exemplary aspects of the invention. The Internet application 1200 of registered users is exemplary regarding a process that is a child of the main user interface 154 of the Internet applications of FIG. 10, for the reason that the process of FIG. 12 uses an interface 154 for interacting with a user over the Internet. However, the steps of FIG. 12 are specific to the process by which a registered user uses the Internet to add or edit information on billing entities or payees, and / or information on payment sources. More precisely, it will be understood that the registered user will be logged in and authenticated at the authentication step in FIG. 10, and typically, he will be provided with a registered user’s web page, which includes controls that enable the user to enter and edit information about billing entities and payment sources. Thus, at step 1205, the registered user first of all enters the system into the Internet application and provides information about his or her registration name and password, and is provided with a “registered user” web page containing billing specific information payable to entities and sources of payments associated with such a registered user.

From a view of FIG. 11 and 12, it will be appreciated that the general structures 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 those in FIG. 11, and do not need to be further discussed in the materials of this application.

MOBILE DEVICE OPERATION

FIG. 13 and the figures that follow, followed by a discussion of exemplary display screens generated on the mobile device 15 by the mobile client application in connection with viewing payment sources and account balances, in accordance with exemplary aspects of the invention. Before setting forth exemplary sequences of screen images of the mobile device 15, it should be noted that in the drawings that follow, the payer's view is depicted with a rectangular screen image with four rounded corners, while the payee view is depicted with a rectangular screen image with four right angles. The presentation of the payee is given in connection with certain sequences and methods of payments in aspects of the invention, for example, certain types of payments “Pay to anyone” include sending a message to a mobile phone user (second user, a user other than the user who makes the payment), text display messages, and (if selected) downloading the mobile application to the second user's mobile device. Such representations of the payee have rectangular corners in the drawings.

It will be understood that different mobile devices typically have different screen displays, different screen sizes, different screen layouts and fonts, etc. However, the main messages for display are presented in the following drawings. The display of texts, fonts, text message lines may vary depending on mobile devices. Alternative embodiments will become 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.

Also, from the following description, it will be understood that various methods for selecting a payee (for example, selecting a payee by name, selection by mobile phone number, etc.), it is assumed in various aspects of the invention that various methods for conveying the fact of payment to the payee (for example, by text message, by displaying the message on the mobile device of the payee / user, etc.), it is contemplated in various aspects of the invention that there are various methods for making a payment (e.g. measures, a paper check, ACH transfer, stored value card with funds, etc.) are assumed in the various aspects of the invention and that various payment methods (e.g., that the payer selects, payee selects which) are supposed in the various aspects of the inventions. Those skilled in the art will therefore understand and take into account that the various aspects set forth above can be combined in various ways to provide flexibility and choice in identifying and selecting a payee, as well as choosing a payment method, as will be described in connection with various exemplary user on-screen displays. images of a mobile device for various embodiments and aspects of the invention.

MOBILE DEVICE OPERATION - VIEWING SOURCES OF PAYMENTS AND BALANCE ON ACCOUNTS

Next, with reference to FIG. 13, a sequence of user screen images 1300 of a mobile device while a user is browsing through payment sources (PS) is presented according to an exemplary aspect of the invention. Typically, the user is presented with a selection screen on his mobile device, with respect to an exemplary screen 1302, which makes it possible to select an application to run on the mobile device. As shown in screen image 1302, “Mobile Wallet” is one of the application menu items. The user can use a stylus, multifunction key, jog wheel or other navigation input device or control to highlight the selection, or use the numeric keypad to make selections through digital input. For example, a user can use the arrow buttons on a mobile device to navigate and highlight the “Mobile wallet” and press the “Select” button to enter the “Mobile wallet” application. Alternatively, the user can press the number 1 button to directly enter the Mobile Wallet application.

It should be understood that a similar input and selection mechanism, as described for selecting an application, is used to select data items on various display screens of a mobile device in several discussed images. These details will not be repeated in order to avoid excessive repetition.

In response to the selection of the Mobile Wallet application, a login screen 1304 is displayed on the screen 1302. On this screen, the user is invited to enter a predefined number of digits as a PIN or passcode to enter the Mobile Wallet as a security measure. In alternative embodiments, the login screen 1304 or equivalent functionality may be located elsewhere on the screen or in other situations where the user turns on the mobile device, selects applications, selects “Mobile wallet”, views bills for payment, pays bills or other appropriate place and / or circumstance. In the descriptions of other drawings of other payment scenarios, the application selection screen 1302 and the login screen 1304 are omitted, but it will be understood that such functionality may be provided if required.

In response to entering a valid registration name or PIN, the screen 1306 is displayed on the mobile device. This screen 1306 preferably contains a menu of available menu items of the Mobile Wallet application according to an exemplary aspect of the invention. In this embodiment, the available applications include: (1) View sources of payments, (2) View invoices for payment, (3) Pay bills, (4) “Pay to anyone,” (5) Transfer balances and (6 ) Change PIN. Other functions may also be provided herein for selecting various embodiments or implementations.

When the user highlights the menu item “View payment sources” and presses the “Select” key or enters “1”, a new screen image 1308 is displayed showing one or more registered payment sources available to the user. A scroll bar (not shown) can be included in the screen if the screen is not large enough to display all payment sources. The user activates the navigation tool to highlight the payment source and clicks “Select” to select a specific payment source. The choice of a specific source of payment results in the display of information 1310 related to the selected source of payment, for example, the balance (s) of various user accounts. For example, screen 1310 shows the current balance, available credit, and available cash loan amount for the user, in conjunction with the logo of the financial services provider to facilitate brand recognition. Displaying the logo of a financial institution is optional; mobile devices of some models may not have graphic capabilities and may rather display only the name of the payment source than the logo.

Screen 1310 also shows exemplary Back or Next buttons or keys on the screen image that can be used to navigate available payment sources. When the “Next” button is pressed, other images of payment sources, for example, screens 1312, 1314 and 1316, are displayed one after another until the “Select” button is pressed. In this example, the Discover Card is displayed as a selectable payment source, as shown in screen image 1312. Other selectable payment sources are Georgia Savings & Loans (Georgia Savings & Loans Bank) and Bank of USA ) are displayed in screen images 1314, 1316, respectively. Account balances and other related information about these payment sources are also displayed using these on-screen images.

According to an exemplary aspect of the invention, the balances available to the user are retrieved from the MFTS 18 during a communication session between the MFTS 18 and the mobile device 15, so that real-time account balances (when the mobile device is within the range of the wireless service) are displayed to the user, The last known remainder stored in the memory of the mobile device. It will be appreciated that as the user views the payment sources and their account balances on various screens of the payment sources 1300, the mobile device 15 communicates with the MFTS 18 and receives information about the balances in real time from the respective financial institutions. According to another exemplary aspect of the invention, if the wireless signal is not available to the mobile device or the MFTS 18 is not able to communicate with a specific financial service provider / payment source 30, the latest (most up-to-date) balance information will be actively delivered from the mobile device 15, essentially the information is cached in the local memory of the mobile device. In case the mobile client retrieves the remainder from the storage device offline, the date / time of the last successful server request will be displayed.

Still referring to FIG. 13, in accordance with an exemplary aspect of the invention, the mobile client application is configured so that one particular payment source is automatically selected as the default payment method, for use by the user automatically and by default, until changed. Screen 1318 reflects the selection of a particular payment source (eg, US bank) as the default payment source. Thus, when the “Select” button is pressed, as shown in the screen image 1316, the user selects the individual payment source displayed on the screen as the default payment method. On screen 1316, the selected default payment source is "Bank of the United States." Screen 1318 preferably displays a “Use as default payment source?” Prompt message for user confirmation. Other payment sources, such as different credit cards, are also available as the default payment source. Preferably, the selected payment source will remain by default until it is changed by the user the next time you use screen 1308 View payment sources. According to an embodiment of this aspect, the system also includes code for a mobile application and / or a user site that provides the user with the ability to change the default payment method on the fly.

According to an aspect of the invention, the selection and activation by the user of the command View payment sources in the Mobile Wallet application causes the formation of a mobile payment order in MFTS, which responds with a request for updated information on account balances in real time from payment sources available to the user, and delivers such an updated balance (i) on the account on the user's mobile device. It will be taken into account that such updated information on account balances includes all types of payment sources, including bank accounts, credit cards, credit unions or any other financial account that may be accessed by the system and using methods as described in the materials of this application.

FIG. 14 is a flow chart illustrating a method 1400 for viewing payment sources and account balances according to one exemplary aspect of the invention. In FIG. 14 and other sequence diagrams, it will be understood that the elongated objects at the top of the drawing depict subjects who electronically exchange information through the exchange of signals, messages, data packets, TCP / IP, etc .; that the rectangles along a line stretching vertically downward from the subject exchanging information depict the steps taken by such a subject; that the lines with arrows extending between the rectangles depict messages directed from one subject to another subject; and that time goes from top to bottom in the figure. This arrangement is used in all cyclograms illustrating embodiments and aspects of the invention, unless otherwise indicated.

Several subjects are illustrated in FIG. 14: user mobile device 15, MFTS server 18, and various financial institutions (FI) with which user 12 (not shown) has business relationships such as (FI-1) 30A and (FI-N) 30N. Typically, the exchange of information between the mobile device 15 and the MFTS 18 is provided by the owner network of wireless communication channels, not shown separately in the drawing. The exchange of information between the MFTS 18 and the payee or the financial institutions of the payee, or any third party service providers, is typically provided by a long-distance network, an Internet service provider, a dedicated communication channel or any other secure communication networks that are available, although not shown separately in the drawing.

Starting in FIG. 14 from step 1402, the user opens the Mobile Wallet application on the mobile device 15; he / she preferably needs to log in by providing a password or PIN for verification, as indicated in step 1404. The password or PIN is entered by the user, locally validated, and signed encrypted messages are sent to the MFTS for authentication via authentication message 1406 (AM). At 1408, the MFTS 18 verifies the validity of the login and allows the Mobile Wallet application to be executed, for example, by sending a confirmation or authentication message (ACM) 1410 to the mobile device 15, which includes a signal or validation code that provides the application The ability to run a mobile wallet on a mobile device 15. If a user enters an incorrect password or PIN a predetermined number of times in a row, it is preferable to open him / her It is called in service, and the mobile device is blocked. In this case, the user is required to take steps (not shown) to access the user site 153 or to 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 informs the mobile device 15 that the login is valid and launches the Mobile Wallet application on the mobile device 15, as shown in step 1412. At step 1414, the user is provided a screen (for example, Fig. 13), which allows you to view and select sources of payments and account balances.

In addition, at step 1412, the user can make a selection on screen 1306 (as shown in FIG. 13) to View payment sources. According to one exemplary aspect of the invention, MFTS 18 automatically retrieves account balances for various payment sources (and retrieves invoices that must be paid) after logging in at 1412. According to another exemplary aspect of the invention, MFTS retrieves such information in the response to the individual activation of the corresponding function, for example, the selection View payment sources (screen 1306 in Fig. 13) sends a message to the MFTS to cause the extraction of information about payment sources, such as account balances etax, and the option Display invoices for payment (also screen 1306) sends a message to invoke the withdrawal of payments for production.

In an exemplary embodiment, the mobile device 15 transmits a request for viewing payment sources and account balances in the MFTS 18, and the MFTS, respectively, interacts with the available payment sources to retrieve their respective account information, as shown in step 1418, by sending requests 1420A or 1420B to their respective financial institutions 30A or 30B. In accordance with a preferred embodiment of some inventions, real-time information about all payment source accounts available to the user is collected and sent back to the MFTS, as shown in steps 1422 and 1424, via messages 1426 and 1428. Although only two financial institutions are shown in FIG. 14 for purposes of illustration, it will be understood that the system is operable to exchange information with some or all of the available and registered financial institutions associated with the user.

At step 1430, the 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 the mobile device 15. According to one aspect of some inventions, collection of information on account balances is accumulated and transmitted to a mobile device in a single message. According to another aspect, information about account balances for a particular financial institution is transmitted to the mobile device as quickly as possible after it is accepted, while the various systems of financial institutions are independent and operate asynchronously with other systems.

At step 1434, upon receipt of account balances from financial institutions, information about all registered accounts is provided to the user for viewing. He / she can then use the navigation controls to view selected payment sources and account balances. The user can also perform other functions, such as selecting a default payment method, as described in connection with FIG. 13.

According to an exemplary aspect of the present invention, after a user enters a valid password or PIN, the login is declared by the valid MFTS system 18. At this point, MFTS may begin to collect information for the user before selecting any Mobile Wallet menu items. In one embodiment, the MFTS system 18 sends requests for part balances to all billing entities of a user to retrieve up to minute information about balances from these billing entities. In another embodiment, the MFTS system 18 sends requests for information about the payment sources of a part or all of the user's financial services providers to retrieve up to minute information on balances (in real time) from these entities. These operations are performed even before the user begins to carry out any options for choosing a Mobile wallet. Information extracted from billing entities and financial service providers is stored (cached) in a temporary database or memory on a user's mobile device and / or cached in the MFTS system. The user probably needs to make some choice of mobile wallet operation after he / she enters the mobile wallet system. When he / she makes any choice of a mobile wallet operation, such as viewing billing accounts, viewing payment sources, etc., the user will immediately receive updated information from a temporary database or cache in the MFTS system. Therefore, the MFTS gives the user an immediate response with information received before the user selects a mobile wallet operation. It will be taken into account that the advantage of this approach is the quick response and updating of information on account balances, practically “in real time” on the user's mobile device.

VIEW PAYMENT ACCOUNTS

FIG. 15 is a sequence of user screen images 1500 of a mobile device while a user views bills for payment, in accordance with aspects of the invention. The user has at least two ways to view his / her payable accounts in accordance with such aspects. The first method 1500a begins with the activation of the Mobile Wallet application by the user, and the second method 1500b begins with the receipt of an SMS text message from MFTS 18.

The first method 1500a starts on screen 1502. When a user uses the Mobile Wallet application to view bills for payment, he / she selects the Mobile Wallet menu item from the screen image 1502 of the mobile device and is provided with a screen image 1504 of the login. After the user logs in and provides a valid password (or is authenticated differently with respect to the mobile device 15), he / she is provided with a number of options, as shown on screen 1506, for example, View payment sources, View invoices for payment, Pay bills, etc., “Pay to anyone”, Transfer balances, Change PIN, etc. In accordance with this exemplary aspect of the invention, the user selects the menu item “View invoices for payment” or presses the numeric button “2”. In response to the selection of the menu item View invoices for payment in any way, the user is presented with a screen 1512 View invoices for payment.

According to another aspect, the second method 1500b includes receiving an SMS text message, instead of responding to a user activating a mobile wallet application. Screen 1522 shows an example text message display screen that includes a number of text messages that the user has received, for example, an Electricity bill payable, Get milk and juice, a Gas bill payable, A phone bill payable, etc. In this example, several of the SMS messages on the user's text message display screen are related to bill payment, but not all messages are related to bill payment. As you know, the user can receive a number of different text messages related to a number of different subjects. In accordance with some aspects of the invention, receiving an SMS message relating to payment of a bill of payments may invite the user to activate the Mobile Wallet application, or reading an SMS message containing predetermined codes may automatically activate the Mobile Wallet application under certain predetermined conditions.

In accordance with one exemplary aspect of the invention, an invoice aggregator (for example, an operator of a invoice system 190, shown in FIG. 2) accepts a number of invoices for payment on behalf of a user and provides information regarding such invoices for payment to a user a text message, so that the user is notified that a new invoice has been accepted and can receive additional information about the invoice, or may activate the Mobile Wallet application to to pay the bill. In accordance with this exemplary aspect of the invention, when a new invoice for payment is received on the MFTS server from the invoice system for payment, the user is notified with a short text message. This short message is preferably concise and only informs the user that a new invoice has arrived for payment. In one embodiment, the message is limited to the name of the invoicing entity (eg, an electricity producer, gas company, etc.), the total amount payable, and the due date. Other information may be delivered in an SMS message, if required, but, in accordance with this exemplary aspect of the invention, the information is limited to the above information, so that the user can be quickly and efficiently notified only of the most important information.

In the example of FIG. 15, suppose that the user has selected the Electricity Bill payable message as shown on screen 1524. When the Read button is clicked, in accordance with this exemplary aspect of the invention, a text message related to the bill for payment (for example, “Bill for XXX payable ”) is automatically detected by the mobile application as being related to the payment invoice and launches the Mobile Wallet application on the mobile device. In response to the launch of the Mobile Wallet application, the user is presented with a login screen 1526 to enable the user to enter a password or PIN. After the user logs into the system and issues a valid password (or is otherwise authenticated against the mobile device 15), he / she is presented with a screen 1512 View bills for payment.

Any of the methods 1500a, 1500b leads to the screen 1512 View invoices for payment. Due to the limited screen size of the mobile device, it will be clear that the contents of the “View invoices for payment” screen are not as detailed as the paper version of invoices for payment that the user regularly receives. However, in accordance with exemplary aspects of the invention, some or all of the following information is displayed in some embodiments of the invention: (1) the name of the billing entity; (2) the date the invoice was received, (3) the amount payable, and (4) the due date. Other related information, such as minimum payment amount, unpaid balance, billing cycle, amount and date of last payment, etc., may also be displayed depending on the screen size of the mobile device. An optional scroll bar can be added for a larger display device.

Display screens 1512, 1514, 1516 illustrate the sequence of different billing accounts that the user sees when using navigation controls (eg, Next keys) to invoke the display of billing accounts that can be paid in accordance with exemplary aspects of the invention. When the user clicks the Next button, as shown in the screen image 1512 of the mobile device, the next bill for payment is shown in the next screen image 1514 of the mobile device. The user can use the “Back” and “Next” buttons to view each individual invoice for payment until the “Select for payment” button is pressed, as shown in the screen image 1516 of the mobile device.

FIG. 16 is a flow chart illustrating a method 1600 for viewing invoices for payment according to an exemplary aspect of the invention. The method or sequence 1600 of operations includes the exchange of information or messages between mobile device 15, MFTS 18 and at least one billing entity. In accordance with the currently contemplated best embodiment, the billing system 190 accepts bills from a number of billing entities on behalf of a user, and outputs information to MFTS 18 regarding a plurality of billing bills from a plurality of billing payable to entities. FIG. 16, therefore, illustrates this course of action or embodiment, but it will be understood and taken into account that MFTS 18 can exchange information with billing entities separately and independently, without requiring that all billing or payments for production be delivered by the system 190 billing for payment.

In one preferred embodiment, the user views the billing accounts by opening the menu item of the mobile wallet of his / her mobile device, as shown in step 1612. In accordance with an alternative exemplary aspect of the invention, the billing subject issues information to the billing system 190 payable, as shown in step 1602. The billing system 190 sends a message 1606 to the MFTS 18, as shown in step 1604. At step 1608, the MFTS 18 sends a short text message 1610 (SMS) to zhaschee the selected abbreviated information to the user via the driver 151 SMS (FIG. 2) and wireless network 110 provider services. As discussed earlier, the user opens the Mobile Wallet or reads a text message when he / she is comfortable, as shown in step 1612. He / she is invited to log in, and the password or PIN is checked for validity, step 1614. In response to the check by the mobile by the user application using the password login name or through another means of authentication, the mobile application sends an authentication message (AM) 1616 to the MFTS 18. At step 1618, the MFTS 18 validates the registration name from the message authentication message 1616 and transmits an Authentication Confirmation (ACM) message 1620 back to the mobile device 15, which allows the Mobile Wallet application to run. At step 1622, the mobile device opens the Mobile Wallet application, which allows the user to view more detailed account information for payment and or payment for production. At step 1624, the user selects the menu item "View invoices for payment" (shown and described in connection with Fig. 15). At step 1626, the user selects one invoice for payment to view. In response to selecting a payable account to view, the mobile device 15 transmits a request message 1628 to the MFTS 18 to request information related to the selected payable account.

At step 1630, the MFTS 18 receives a request for information related to the selected invoice for payment, and generates a message 1632 to the billing system 190 for payment. At step 1634, the billing system retrieves information related to the selected billing account (or, optionally, for one or more billing accounts associated with a particular user) and retrieves detailed billing information. Therefore, preferably, all billing accounts associated with the user are forwarded to the MFTS via message 1636. At step 1638, the MFTS 18 receives detailed billing information from the billing system 190 and stores the detailed billing information to payment in the MFTS database in the table for billing details for payment (see Fig. 6). The MFTS 18 then prepares a message 1639 with the selected abbreviated information suitable for the mobile device (i.e., a subset of billing details) and forwards the message containing a subset of the billing details to the user’s mobile device 15. At step 1640, the user views his / her due bills through screens, as shown in FIG. fifteen.

Although FIG. 16 shows a sequence of steps for obtaining information about invoices for payment from a billing system, it will be understood that the steps are similar for independently receiving information from an invoice for payment entity. From the foregoing, it will be appreciated that an aspect of the present invention includes a method for obtaining selected abbreviated information related to payments for production (invoices for payment), and this information is obtained from one or more billing entities independently, or from billing system 190.

PAYMENT OF BILLS

FIG. 17 is a sequence of user screen images 1700 of a mobile device that relate to a user paying his / her bill (s) for payment. As in other aspects of the invention described elsewhere, the user is preferably required to activate the Mobile Wallet application on his mobile device and authenticate (i.e. log in) to use the application on such a specific mobile device. Thus, screen 1702 shows a number of selectable applications, such as Mobile Wallet, Download Music, Games, etc., and screen 704 shows a login screen that is formed upon initial execution of the Mobile Wallet application after selection on screen 1702. After the user enters the Mobile Wallet application, as shown as screens 1702, 1704, the Mobile Wallet screen 1706 is displayed. In accordance with exemplary aspects of the invention, the Mobile Wallet screen includes a number of selectable menu items that provide various functions related to viewing, controlling and paying for mobile financial transactions. For example, screen 1706 shows the menu items View payment sources, View invoices for payment, Pay bills, Pay to anyone, Transfer balances and Change PIN. In accordance with the aspect of paying bills, the menu item Pay bills is shown highlighted (selected), indicating that the user has chosen to activate the function Pay bills of the mobile application. The user can activate this function by choosing Pay bills from the menu on the screen 1706 or can press the button “3” on the keypad. In response, the Mobile Wallet application presents a Pay Bills display screen, as shown in 1708.

In accordance with exemplary aspects of the invention, a Pay Bills screen 1708 provides a list of select pending bills for payment. In one embodiment, the list may be arranged such that the most recent bill for payment is included in the list at the top, and the oldest bill for payment is listed in the bottom, as shown in screen image 1708. Other options may also be implemented. layouts, such as the oldest billing accounts, that are listed first. According to one exemplary aspect of the invention, and as shown on screen 1708 when the “Pay bills” function is selected, the oldest bill payable is automatically highlighted so that the user pays first, for example, “Phone bill payable 11/17/05 $ 34.45 ". In this, as in other exemplary aspects of the invention, the user navigates the list using the up and down navigation controls and selects the one that he / she wishes to pay by pressing the “Select” button when the appropriate payment account is highlighted.

In response to the selection of a particular invoice for payment, information about the selected invoice for payment is displayed to the user, as shown on screen 1710. In accordance with exemplary aspects of the invention, selected information related to the selected invoice is displayed, for example, the name of the subject of the invoice for payment, date when the invoice has been accepted for payment, the amount of the invoice for payment, optionally, the minimum payment and due date, as shown in the screen image 1710. Optionally, but not shown on the screen 1710, the total balance due may be shown ok on the account. The exemplary screen 1710 preferably also includes the Pay, Back, and Next keys as navigation controls that enable you to view other payable accounts in a sequential list of payable accounts. As will be taken into account, the Pay button or control is used to pay the bill currently displayed.

According to exemplary aspects of the invention, when the “Pay” button is clicked, the Mobile Wallet application provides a screen image 1712 that allows the user to select the amount to pay. In a preferred embodiment, the user is offered the following options: (1) pay the minimum amount payable; (2) pay the full amount payable; or (3) pay the amount set by the user. The first two choices are self explanatory and lead to proper payment based on the information in the record. The third option provides the user with the flexibility to set the desired amount. If the third option is selected, the Mobile Wallet application displays a screen image (not shown) that allows you to enter the required amount for payment. The exemplary screen 1712 preferably also includes the Pay, Back, and Next keys as navigation controls that enable you to view other payable accounts in a sequential list of payable accounts or resume payment on a selected payable account. As will be taken into account, the Pay button or control is used to pay the amount currently selected.

Continuing with the screen 1712, when the user made a choice of the amount to pay and the "Pay" button was pressed, a screen image 1714 is displayed that shows the default payment source (Bank of the USA, in this case) and its associated information. On the sample screen 1714, the default payment source, the Bank of the United States has three selectable accounts, for example, Savings Balance, Demand Balance, and Other (for example, a short-term money market account or maybe a loan account). According to an exemplary aspect, a specific invoice is shown highlighted by default (for example, a demand balance) to indicate to a user that a demand account for this payment source is the default payment source that will be used if the user has not changed it by another means.

According to an exemplary aspect of the invention, screen 1714 further includes text prompting the user to confirm the default payment source currently displayed, for example, the test reads “Pay by default payment source?” If the user clicks the Select button on the screen image 1714, indicating confirmation that the current account for payment must be paid by the default payment source, the Mobile Wallet application generates a screen image 1716, which includes information, Confirming payment and updating information on sources of payments. At this point, the user can press the “Done” key to complete the mobile payment transaction, or click “Next” to make other payments. In accordance with exemplary aspects of the invention, the amount of the current payment ($ 34.45 in the example shown) is deducted from the balance shown in the default payment source (Balance on demand), so that the information on the user's payment sources is instantly updated to reflect the payment (i.e., Balance on-demand decreases by $ 34.45, as shown between screens 1714 and 1716). This occurs in exemplary embodiments, even if the invoice amount has not yet been actually debited from the user's bank account.

FIG. 18A is a flow chart illustrating a method 1800 for paying a bill, according to a preferred embodiment of the present invention. A method or sequence of operations 1800 includes exchanging information or messages between a mobile device 15, MFTS 18, at least one billing entity (e.g., a billing system 190 or a separate billing entity) and a selected financial institution 30, which serves as the selected payment source (PS). In this example, the default financial institution 30A (FI) of the user is described as the selected payment source.

In FIG. 18A, it is assumed that the user has previewed payment sources and account balances, and has selected a specific invoice to be paid. Thus, the initial step in the sequence of operations 1800 is step 1802, where the user has received information about all accounts for payment and is ready to select a specific account for payment, for example, via screen 1708 in FIG. 17. When the user is ready to pay the bill, at step 1804, he / she selects a specific bill to pay. As shown in exemplary screen images 1712 and 1714, the user selects the payment source and selects / enters the amount to be paid at step 1806. In response to entering the amount to be paid, the message 1808 of the mobile payment order (MPI) is transmitted from the mobile device 15 to the MFTS 18 , which includes the required amount and identifies the financial institution selected for the payment. At step 1810, the MFTS 18 receives the MPI message and prepares the MFTS Payment Order Message (MFTSPI) 1812 to the selected financial institution 30A. MFTSPI message 1812 is preferably a request message to a financial institution to check whether the selected payment source has sufficient cash to make a payment and / or an order to make a payment if sufficient cash is available.

In addition, at step 1814, the MFTSPI message 1812 is transmitted to the financial institution 30A and received at step 1814. If sufficient funds are not available to cover the payment, FI 30A generates and transmits a response message 1816 '(not shown) to the MFTS 18 to notify that the funds are not available, and, in turn, the MFTS sends a confirmation message (not shown) to the user that the requested payment has failed. Otherwise, FI prepares an available cash (FAM) message 1816 indicating that sufficient cash is available and sends this message to the MFTS. At step 1818, the MFTS 18 receives a message about available cash and prepares a corresponding message 1820 about available cash to the mobile device 15, which enables the Mobile Wallet application to resume generating a payment order message. This message about available funds is received in the mobile device at step 1822, where the Mobile Wallet application resumes payment processing. Step 1822 includes actions, such as generating a payment confirmation display for the user, for example, screen 1714 (FIG. 17), which asks the user to confirm “Pay by default payment source?” Of course, it will be appreciated that the user could to reject the payment with the default payment source and use the navigation controls to select a different payment source, in which case, additional and accordingly appropriate messages from the Mobile wallet application are formed and returned to MFTS 18.

In response to the user confirming the payment source, for example, by confirming the default payment source, the Mobile Wallet application generates and transmits a message 1824 indicating the payment confirmation to the MFTS 18. A payment confirmation message from the mobile device 15 is received in the MFTS 18 at step 1826. At at step 1826, the MFTS 18 receives the confirmed payment order from the mobile device 15 and generates a payment source message 1828 of the payment source. According to an exemplary aspect of the invention, as shown in FIG. 18A, message 1828 of a payment order payment source is transmitted to a billing system 190. In the case of using the billing system 190, at step 1830, the system 190 receives the payment order 1828 of the payment source, generates the corresponding message 1832 of the payment order to the financial institution 30A, and processes the payment internally, for example, by clearing the account payable from the queue of unpaid user accounts .

At step 1834, the financial institution 30A receives the payment source’s payment order from the billing system 190 and accordingly responds. As will be taken into account, the financial institution takes a step inside to withdraw funds or enter a debit on behalf of the user from the selected account, and generates an appropriate payment document for the invoice subject for payment. The formation of a suitable and selected payment order, for example, a paper check, ACH money transfer, card with a pledged limit of funds, is described elsewhere in the materials of this application.

Upon completion of the appropriate steps for generating and transferring the payment to the billing entity at step 1834, a payment confirmation message 1836 is generated by the financial institution 30A and transmitted to the billing system 190. At step 1831, the billing system 190 receives the payment confirmation message, clears the account for payment in the record, generates a mobile payment confirmation message 1837, and transmits this message 1837 to the MFTS 18, as shown in step 1838. The MFTS 18 receives the confirmation message 1837 and forwards another confirmation message 1840 to the mobile device 15. At step 1842, the mobile device 15 receives the mobile payment confirmation message 1840 and displays the confirmed payment information, for example, the display screen 1716 in FIG. 17.

Next, with reference to FIG. 18B, an alternative embodiment of the present invention is shown. Here, the steps / messages from 1802 to step 1826 and the step / message after 1838 are identical or similar to the steps / messages shown in FIG. 18A. At step 1826, the MFTS 18 receives the confirmed payment order from the mobile device 15 and generates a payment source payment order message 1828 ′. Message 1828 'of the payment order of the payment source is transmitted to the invoice system 190 for payment. In the case of using the billing system 190, at step 1830 ′, the system 190 receives the payment source order 1828 ′, generates a corresponding payment order message 1832 ′ to the financial institution 30A, and processes the payment internally, for example, removing the bill to be paid from the queue unpaid user bills.

At step 1834 ′, the financial institution 30A receives the payment source’s payment order from the billing system 190 and accordingly responds. Upon completion of the appropriate steps for generating and transferring the invoice payment to the subject at step 1834 ′, the payment confirmation message 1836 ′ is generated by the financial institution 30A and transmitted to the MFTS 18.

From the foregoing, it will be appreciated that variations in the above described flow of operations will be apparent to those skilled in the art.

PAYMENT METHOD FOR PAYING ANYWHERE

FIG. 19 and FIG. 20 illustrate exemplary display screens on the mobile device 15 of the user / payer and the second user / payee, respectively, in connection with the “Pay to anyone” payment process. The pay to pay sequence is a payment method for payment to an entity other than previously registered billing entities or user service providers. Examples include making payments at the point of sale, with the identity of the payee determined at the time the payment was made; making a payment to an individual who owns a mobile device capable of executing a Mobile application (but maybe not yet downloaded and not working); making a payment to an individual or other entity that does not own a mobile device, but requests a certain type of payment, such as a paper check, electronic money transfer, a card with a fixed limit of funds, etc. Numerous options for the “Pay to anyone” payment method will be apparent when considering the following display screens and steps in the flow of operations.

Thus, it will be taken into account that some options for choosing the payment method “Pay to anyone” involve payment to an entity that is registered with MFTS 18, while other options involve payment to an entity that has not previously been registered. The payment method "Pay to anyone" provides users with the ability to send other payments to registered or unregistered people as an alternative to cash payment. The method also involves making payments anywhere, anywhere - at a point of sale, locally, across the country, and across national borders (of course, within the applicable money circulation standards) without physically manipulating cash or checks. The method also involves receiving a payment by the recipient and the relatively fast (almost instantaneous) availability of funds.

Key issues in the Pay to Any payment method include (1) the identification of the payee and (2) the course of action and / or form of payment. According to one exemplary aspect of the invention, a user is given an alternative to select a payee from a list provided by the MFTS via a mobile device, or select / enter a payee by entering / selecting a mobile phone number associated with the payee. Similarly, according to an exemplary aspect of the invention, there are several different ways for a payee to receive payments. For example, a user / payer may choose a payment method from the following payment methods: (1) “Defined by the recipient”, (2) “Bank draft” (or ACH wire transfer), (3) “Paper check” and (4) “Card with pledged limit of funds. " The “Defined by the Recipient” method allows the recipient of the payment to choose one of the three remaining methods, that is, “Bank draft”, “Paper check” and “Card with a pledged limit of funds”.

It should be noted that the choice of the payee and the choice of payment method are completely independent. The following descriptions of the preferred embodiments of “Pay to Anyone” illustrate that various payee choices and payment method choices are intended as an exemplary aspect of the inventions. For example, in FIG. 19 and FIG. 26, the payee is selected by selecting a name from the list, while, in FIG. 23 and FIG. 29, the payee is selected by entering the mobile phone number of the payee. In FIG. 19 - FIG. 31, all four different payment methods are discussed. Any combination of the choice of the payee and the choice of payment method is possible in the light of the following doctrine. The description of exemplary embodiments of the invention has been presented for purposes of illustration and description only, and is not intended to be exhaustive or limiting to the exact disclosed forms.

Pay by any payee-specific payment method: FIG. 19 shows a sequence of screen images 1900 of a payer’s mobile device, while the user uses the menu item “Pay to anyone”, selects a name from the list, and uses the “Recipient-Defined” payment method according to an exemplary aspect of the invention. The screens 1902, 1904, 1906 are exemplary screens for displaying selected applications, logging in and selecting Mobile Wallet applications, which have been described elsewhere in the materials of this application and will not be repeated. However, on the screen 1906 it will be seen that one of the selectable menu items is the menu item "Pay to anyone", shown highlighted and, therefore, selected. In response to the selection of the menu item “Pay Anyone” on the screen 1906, in accordance with one exemplary aspect of the invention, the user is provided with a short menu shown on the screen image 1908 to enable the payment recipient to be selected by name or mobile phone. In accordance with this, the user can select the name of the payee from the list, or select / enter the mobile phone number of the payee.

In this example, suppose the user selects the Pay by Name menu item from the menu. In response to the selection of this menu item, a screen is displayed on the mobile device containing a list of previously entered payees, for example, screen 1910 with the names Jane Bennet, John Dow, Robert Johnson, Carol Jones, etc. As shown on screen 1910, the payee name John Dow is shown highlighted, and therefore, selected for the action. Information related to the names in the list on the screen 1910 may be stored locally on the mobile device and / or in the user database of the MFTS 18.

Although not discussed in connection with FIG. 19, it will be understood that the user can select the menu item "Pay by mobile phone" on the screen 1908 and enter the mobile phone number for another form of payment, as discussed elsewhere in the materials of this application.

As with the other screen displays of the mobile device described in the materials of the present application, the scroll bar navigation control to the right of the display screen indicates that the list of names is larger than the mobile device can display, and allows the list to scroll down. Similarly, the user can activate the "Back" or "Next" buttons, or the navigation control to navigate the list of names, and the payee is selected in the list by using the "Select" button.

Continuing with an example, in response to the selection of a particular payee on screen 1910 (e.g., John Dow), a screen 1912 is presented that allows the user to enter the amount to be paid. In the example, the user entered $ 123.45. The user then presses the “Next” key, which results in a display screen 1914 that asks for confirmation of the default payment source. At this moment, the user can also use the "Back" button to make additional changes, or click the "Cancel" button to refuse to pay.

In response to a user entering a payment amount, the Mobile Wallet application presents an example screen image 1914, which, as in the previous examples, allows the user to select an account from several available default payment source accounts. As in the previous example, the US Bank account is shown as the default payment source, and the demand account is shown selected / highlighted as the default account to use. After selecting a specific account, the user clicks the “Select” button to continue the sequence of operations for making a payment.

In response to selecting an account on the screen 1914 and according to one exemplary aspect of the invention, a user is provided with a display screen 1916 that enables the selection of one or a plurality of different payment tools or methods for making a payment to the payee. In this example, there are four choices: (1) Defined by the recipient, (2) ACH (bank draft), (3) Paper check and (4) Card with a fixed limit of funds. The user can use the "Back" and "Next" buttons to navigate the menu and use the "Select" button to select a specific payment method or tool. In this example, the “Recipient Defined” method of payment is selected, that is, the recipient can select a method of receiving payment when the information related to the payment is received by the recipient of the payment. The selection by the payee of the payment instrument is described in connection with other figures, for example, see FIG. 20. As will be seen in FIG. 20, the payee is given an alternative to choosing from ACH, Paper Check or Card with a pledged limit of funds; such steps and displays for the payee / payee are discussed in connection with FIG. twenty.

Continuing with FIG. 19, in response to a user selecting a payment method or tool, the Mobile Wallet application generates a display screen 1918 that provides the ability to confirm payment by the user. According to an exemplary aspect of the invention, the screen image 1918 displays the payment confirmation and the cash balance of the payment source used in this transaction, for example, the default balance of the payment source is debited to the payment amount of $ 123.45 from that shown on the screen 1914. At this point, the user can press the “Done” key to complete the “Pay anyone” application, or the “Next” key to start another transaction.

Next, refer to FIG. 20 to discuss the presentation of a payee-defined payment method of a payee. It should be understood that the display screens shown in FIG. 20, it is assumed that the payee / payee owns a mobile device that is adapted to run the Mobile Wallet application, is configured to work with the system and methods described in the materials of this application, and is a registered user of MFTS 18. In the event that the payee / the recipient is not configured and not registered in this way, he or she can receive a text message (SMS) indicating that the payer wants to make a payment, and with instructions to the payee / recipient regarding how to download and execute the Mobile Wallet application on his or her mobile device, or to take another action to receive payments. A discussion of such operations and features for an unregistered payee / payee is given elsewhere in the materials of this application.

Typically, and according to one exemplary embodiment of the invention, on the payee side, the payee receives an SMS text message from the SMS MFTS generator 151 (FIG. 2). If the payee has the Mobile Wallet application installed on his / her mobile device, he / she can directly call the application when reading the SMS text message to receive the payment. Accordingly, FIG. 20 shows a sequence of 2000 screen images of the user's / payee’s mobile device in response to receiving messages and exchanging information generated by the user / payer who called the menu item “Pay to anyone”, selects a name from the list, and uses the “Recipient-Defined” payment method.

The display screen 2002 is an exemplary display of a mobile device that the payee sees in response to receiving a message from the MFTS 18, for example, an SMS message or a message in a format specially adapted for communication between the MFTS 18 and the Mobile Wallet application. As shown on screen 2002, the payee is shown information indicating that the person with the identified mobile number (for example, 404-404-4040) sends the payee / payee a payment in the amount of $ 123.45, and invites the payee / recipient to choose a payment method from a list of several different payment methods. According to an exemplary aspect of the invention, a message from MFTS 18 (a) automatically launches the Mobile Wallet application, or (b) invites the payee / recipient to activate the Mobile Wallet application. In any case, the payee is notified that someone (with a name or phone number) has sent the payment and the payment amount. The payee is requested / invited to select a payment method from the list of possible payment delivery methods: ACH, Paper check or Card with a fixed limit of funds. The payee will then make the selection as directed, as shown in screen image 2002.

ACH: In response to the payment recipient choosing the ACH method, according to one exemplary aspect of the invention, the Mobile Wallet application provides a display screen 2010 for implementing this method. In accordance with this aspect, the payee is shown a default ACH account with a bank code assigned by the American Banking Association and a default account number, as shown in the 2010 screen image. The screen preferably includes controls to Confirm, Change Account, and Cancel. The Confirm control confirms the default payment method displayed. If the payee confirms the default payment method, another 2012 screen is displayed that informs the payee that the ACH transfer has been completed. On the other hand, the payee is able to replace with another ACH account by selecting the Change Account control, which displays a separate display screen (not shown) for entering a new bank code and account number assigned by the American Banking Association. The Mobile Wallet application then preferably displays a different screen, similar to that of 2010, after entering alternative bank code assigned by the American Banking Association and account number, followed by a confirmation, such as a 2012 screen image, after the transaction is completed and confirmed.

Paper check: In response to a payment recipient selecting a method of receiving a paper check payment from a screen 2002, according to one exemplary aspect of the invention, the Mobile Wallet application provides a display screen 2020 for implementing this method. In accordance with this aspect, screen image 2020 displays the default mailing address to which the paper receipt should be mailed. The sample screen also includes the Confirm, Change Address, and Cancel controls that are selectable. The screen, in fact, invites the payee to confirm the displayed default mailing address, which is stored in MFTS 18. If the payee confirms the default mailing address by pressing the “Confirm” control, an approximate screen image 2022 is displayed to inform the payee that the paper check will sent by mail to the default mailing address. On the other hand, the payee is able to change to a different mailing address by entering a new mailing address by selecting the Change address control, which displays a separate display screen (not shown) for entering another mailing address. The Mobile Wallet application then preferably displays another screen, similar to that of 2020, after entering an alternative mailing address followed by a confirmation, such as screen image 2022, after the transaction is completed and confirmed.

Card with a pledged limit of funds: In response to a payment recipient choosing a method of receiving a payment with a Card with a pledged limit of funds from a screen 2002, according to one exemplary aspect of the invention, the Mobile Wallet application provides a display screen 2030 for implementing this method. In accordance with this aspect, the screen image 2030 displays a card account with a default pledged cash limit on which funds would be deposited. The sample screen also includes the Confirm, Change Invoice, and Cancel controls that are selectable. The screen, in fact, invites the payee to confirm the displayed card account with the default funds limit set, which is stored in MFTS 18. If the payee confirms the default card account with the default funds limit by pressing the “Confirm” control, an approximate screen image 2032 is displayed to inform the payee that the indicated amount will be placed on the card account with a default limit on funds. On the other hand, the payee has the opportunity to replace the card with a pledged limit of funds to another account by entering a new account by selecting the Change account control, which displays a separate display screen (not shown) for entering another card account with a pledged limit of funds. The Mobile Wallet application then preferably displays another screen, similar to that of 2030, after entering an alternative card account with a set limit of funds, followed by a confirmation, such as a screen image 2032, after the transaction is completed and confirmed.

According to one exemplary alternative aspect of the invention, the payee / recipient is not required to have the Mobile Wallet application installed on their mobile device, especially for options for choosing a paper check and a pledged cash limit. In accordance with this aspect of the invention, one or more text messages (SMS) containing information essentially as shown in FIG. 20, can be generated by MFTS 18 and transmitted to the mobile device available to the payee / recipient, with instructions to the payee / recipient to return a text message (SMS) containing the specified information, for example, to confirm the default mailing address for a paper check or invoice with a pledged limit of funds, or the provision of an alternative postal address or account with a pledged limit of funds. Thus, it will be appreciated that aspects of the invention can be easily created using SMS messaging technologies for recipients of payments with mobile devices that do not have the Mobile Wallet application installed, or where the payee has not decided to use and launch the Mobile application wallet.

FIG. 21 is a flow chart illustrating a method 2100 for a Pay to Any payment method according to an exemplary aspect of the invention. The method or sequence 2100 of operations includes the exchange of information or messages between the mobile device 15 and the MFTS 18 and allows the user to select a specific form of payment to make a payment to a person identified during interaction with the system. This sequence of operations is in contrast to the previously described method for making a payment to a pre-identified invoicing entity.

Beginning at step 2102, the user activates the Mobile Wallet application and logs into the system or otherwise provides authentication information at step 2104. An authentication (AM) message 2106 is generated and transmitted to the MFTS 18, which, at step 2108, authenticates the user. After user authentication with the MFTS in step 2108, the authentication confirmation message (ACM) 2110 returns the MFTS 18 to the mobile device 15, which enables the Mobile Wallet application to run on the mobile device, as shown in step 2112. According to one exemplary aspect of the invention, in step 2112, MFTS 18 also retrieves a predetermined payee list associated with the user from the user database and sends this payee list to the user back to the mobile device, where it is displayed to the user (see the example screen in Fig. 19).

After the Mobile Wallet application is opened at step 2112, suppose the user selects the menu item “Pay Anyone” at step 2114. He / she then selects the name of a predefined list of payees or enters a mobile number to select the payee, as shown in step 2116, and enters the amount in dollars and cents for payment, at step 2118. At step 2120, the user selects one of the available payment methods, for example, Defined by the recipient, ACH, Paper check or Card with a mortgage limit of funds, as shown in FIG. 19. In this example, suppose that the user has preferred to pay by the Recipient-specific payment method. Information corresponding to the selected payment method is provided in message 2122 of the mobile payment order (MPI) and sent to the MFTS 18 for further processing by the MFTS 18 and other related parties, as shown in step 2124.

FIG. 22 is a flow chart illustrating a payee-determined Pay-to-Any method 2200 according to an exemplary aspect of the invention. The method or sequence 2200 includes the exchange of information or messages between a user / payer mobile device 15 (not shown here), MFTS 18, a payee mobile device 2202, a user / payer financial institution 30A, a payee financial institution 2260, a payee 2270 and a card issuer with a pledged limit on funds by the company 2280. In this example, suppose that in FIG. 21, the user selected the Recipient-defined payment method in step 2120, and this decision was transferred to the MFTS 18. According to one exemplary aspect of the invention, the MFTS sends a text message 2206 (SMS) to the payee, such as that shown on the screen 2002 of FIG. 20, as indicated in step 2204. This message 2206 informs the payee that the payment of a certain amount is pending and that the payee must choose from a list of selected payment methods, as shown in step 2208. The payee preferably uses his / her mobile device 2202 to make a choice of the three payment methods proposed at step 2210. Such a choice can be made by a returned text message, or by using the Mobile Wallet application, if installed o on the payee’s mobile device. In any case, the message 2212 mobile payment order (MPI), including information related to the selected payment method, is returned to the MFTS 18, for example, message 2212A to select the payment method ACH, message 2212B to select a paper check or message 2206C to select card payment method with a fixed limit of funds.

ACH payment method: If the payee selects the ACH payment method, the payment method select message 2212A, including the payee ACH account information and the payment amount, is sent to the MFTS 18 through the networks of the wireless communication channel owners, as shown in step 2214. The corresponding request 2220A is then sent to the financial institution 30A (source of payment) of the user / payer for payment to the specified bank account of the payee from the account specified by the user, as indicated in step 2222. As soon as the financial institution User / payer 30A verifies that the user has sufficient funds to cover the payment, the payer's financial institution sends the ACH bill to the designated account of the financial institution 2260 of the payee, as indicated in step 2226.

Paper check payment method: if the payee selects the paper check payment method, payment method selection message 2212B, including information about the payee's mailing address and payment amount, is sent to the MFTS 18 through the networks of the wireless communication channel owners, as shown in step 2216. The corresponding request 2220B is then sent to the financial institution 30A of the user / payer to generate a paper check, borrowed from the specified user / payer account, and mail such receipt the payment body, as indicated in step 2222. As soon as the user / payer financial institution 30A makes sure that the user has sufficient funds to cover the payment, the payer financial institution sends by mail the check 2224B to the payee, the receipt of which by the payee is indicated at step 2228.

Method of payment with a pledged limit of funds: if the payee chooses a payment method with a card with a pledged limit of funds, message 2212C choosing a payment method, which includes information about a card account with a pledged limit of funds of the payee and the payment amount, is sent to MFTS 18 via the network of wireless channel owners communication, as shown in step 2218. The corresponding request 2220C is then sent to the financial institution 30A of the user / payer to credit the identified card account with a pledged limit funds borrowed from the specified user / payer account, as indicated in step 2222. As soon as the financial institution 30A of the user / payer makes sure that the user has sufficient funds to cover the payment, the payer financial institution credits the identified card account with a pledged limit of funds (during 2224C) in the assigned amount, the receipt of which by the payee is indicated at step 2230. It should be understood that step 2230 indicating receipt of a loaded card with a pending limit of funds, reflects both, (a) crediting an account of a pre-existing card with a pledged limit of funds associatively associated with the payee, or (b) issuing a new loaded card with a pledged limit of funds for the payee, for example, by providing the payee with information indicating the place , in which a loaded card with a set limit of funds can be received, as well as providing information, such as a validation code, which would give the payee the opportunity to submit hydrochloric card into a terminal or representative, in order to "load" the card payment amount. Such details of loading and delivering cards with a set limit of funds to individuals are known to those skilled in the art and do not form a separate part of the invention.

It will be understood that for these payments these three methods can be used independently or combined so that the payee can gain the flexibility of placing part of the payment using ACH, and the remaining part of the payment on a paper check and / or card with a fixed limit of funds.

PAY ANYONE BY PHONE NUMBER

FIG. 23 shows a sequence of screen images 2300 of a payer's mobile device for the “Pay to anyone by phone number” payment method according to an exemplary aspect of the invention. In this particular method, the payer / user selects / enters the phone number of the mobile device to identify the payee. More specifically, an “ACH” payment method according to an exemplary aspect of the invention is illustrated. It will be understood that the payer, in the alternative, may choose the payment method by paper check or card with a pledged limit of funds, and that the specific payment method described is only exemplary.

As in the embodiments and aspects described previously, the user first selects the Mobile Wallet application on the screen 2302, provides authentication information (e.g., login name) via the screen 2304, and authenticates through the MFTS before being provided with payment options on the screen 2306. Assume that on the screen 2306 the user selects the menu item "Pay to anyone." In response to this choice, the user is provided with a short menu of menu items, as shown in screen image 2308, to select the payee by name or mobile phone number. According to this exemplary aspect of the invention, in response to selecting the menu item “Pay by mobile phone” by entering the number “2” or by activating the Select control, the user is presented with a screen 2310 for entering the mobile number of the payee / payee.

According to this exemplary aspect of the invention, an exemplary payee phone number 404-555-2121 is entered, as shown on screen 2310. Screen 2310 further includes Next, Back, and Cancel controls that act in some way, as described previously to continue the flow of operations , return to the previous screen or cancel the transaction. In response to the user activating the control next, after entering the phone number of the payee, the user is presented with a screen 2312 for inputting the amount of payment to enter the amount for payment. The user then enters the amount to pay. In this example, the user entered $ 123.45. As in other example screens, the sum entry screen 2312 includes Next, Back, and Undo controls. In response to the user activating the Next control, the user is presented with a screen 2314 that displays the default payment source (e.g., Bank of the USA), the available default account balances of the default payment source, and prompts the user to confirm the selected default values. As in the previous examples, the user can activate the "Select" control to select the default account and payment source, or to navigate to an alternative payment source.

After selecting and / or confirming the source of payment through the screen 2314, the user is presented with a screen 2316, which allows you to select the payment method. The user uses the “Back” and “Next” buttons to navigate the menu and uses the “Select” control to make a selection. In this example, the payment method "ACH" is shown highlighted, and therefore selected. In response to the activation of the Select control on the screen 2316, the user is presented with a screen 2318 that displays the payment confirmation, the selected payment method and the cash / updated balance of the payment source used in this transaction. At this point, the user can activate the Done control to complete the Pay Any application, or the Next control to start another transaction.

FIG. 24 shows a sequence of screen images 2400 of a mobile device from the perspective of the payee, using the payee’s mobile device, for the “Pay to Any” option, where the user selects / enters the mobile phone number and uses the “ACH” payment method according to an exemplary aspect of the invention. As in other embodiments and aspects, the displayed information may be presented to the payee by a sequence of text messages (SMS) or by displays generated by the Mobile Wallet application, if downloaded and activated on the payee’s mobile device.

As shown on screen 2402, an SMS text message is received from the SMS driver 151, or similar information, is generated by the Mobile Wallet application running on the payee’s mobile device. In accordance with this message, the payee is notified that someone with the phone number 404-404-4040 sent a payment in the amount of $ 123.45 for delivery via ACH money transfer. According to one exemplary aspect of the invention, the message to the payee includes a default payment method, for example, to be placed in a predefined bank (which is identified by the bank code assigned by the American Banking Association) and on the account. If configured by the Mobile Wallet application, the screen 2402 preferably includes a Confirm control, a Change Account control, and a Cancel control. By activating the Confirm control, the payee / recipient can confirm that the bank code assigned by the American Banking Association and the ACH account number stored in the MFTS database are valid for payment. On the other hand, the payee has the opportunity to replace with another ACH account by entering a new account number or a bank code assigned by the American Banking Association by activating the “Change Account” control. As in other examples, if the payee activates the “Change Account” control on the screen image 2402, a separate screen (not shown) is displayed on which the payee is given the opportunity to enter other bank code assigned by the American Banking Association and account number.

If the payee confirms the payment delivery method by activating the Confirm control on screen 2402, a screen image 2404 is displayed that invites the payee to confirm the placement to the identified ACH account. Screen 2404 preferably also includes a Done control, a Change Account control, and a Cancel control. The Change Account control works in the manner described elsewhere. Activating the Done control brings up a screen 2406 that invites 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 the screen 2406, then the ACH account information is by default sent back to the MFTS 18 to be saved in connection with other information related to this particular payee. Otherwise, the ACH score does not change by default.

After confirming 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, a screen 2408 is displayed, which invites the payee / recipient to confirm the payment is placed on the selected currently bill. The “Yes” and “No” controls are provided to confirm or reject the placement on the account. If the answer is “Yes”, the response of the payee is sent to MFTS 18 for further processing of the transaction. In response to processing the transaction by making an ACH payment, according to one exemplary aspect of the invention, the payee receives a confirmation message or display 2410 indicating that the payment received will be deposited to the ACH account that the payee specified earlier. At this point, the payee can activate the Completed control to complete the payment, or the Next control to process another transaction, if applicable.

FIG. 25 is a sequence diagram of a Pay to Any payment method using ACH or a flowchart 2500 according to an exemplary aspect of the invention, showing interactions between a payer / user mobile device 15, a payer mobile device 2521, MFTS 18, a third-party payment provider 2560, and a payee financial institution 2580 . The third party payment provider 2560, as in the previous aspect, is the recipient of the payment order that makes the payment to the payee, in this case, by transferring funds to the financial institution 2580 payee.

As in the previous methods described elsewhere, steps 2502, 2504 include authenticating the user / payer to the MFTS 18 via message 2506, authentication via the MFTS 18 at step 2508, and sending the authentication confirmation message 2510 and the user payee list to mobile device 15 user. In response to authentication, the user opens the Mobile Wallet application at 2502 and enters the password or PIN at 2504, the MFTS authenticates the registration name and sends the current list (2510) of the user's payment recipients to the user's mobile wallet of his / her mobile device at step 2508. This action provides the user is able to resume using the Mobile Wallet application at step 2512. The user then selects "Pay Anyone" at step 2514 and selects the name of the payee from the list of payees atezhey received during logon, or enters a phone number to set the payee, in step 2516. The user then enters the amount of payment using a mobile device in step 2518 and chooses way of ACH payments during 2520.

In response to the above steps, a Mobile Payment Order (MPI) message 2522 is generated by the Mobile Wallet application and transmitted to MFTS 18. MPI 2522 will typically include a payment amount, a payment method (in this case, ACH payment), and information about payment recipients, Including the payee’s phone number. At step 2524, the MFTS 18 checks the payment order and generates a message 2526 to the payee’s mobile device 2521 to require the payee to set or confirm the ACH method for the payment. This message 2526 is sent to the payee’s mobile device and received at step 2528. According to an exemplary aspect of the invention, the payee can receive message 2526 through one or more text messages or by exchanging information that activates the proper application process of the Mobile application (not shown separately). At step 2528, the payee selects the account on which the funds should be deposited. A returned payment account selection message 2530 is generated (for example, a returned text message or transmitted data from the Mobile Wallet on the device of the payee), which indicates the account to which the payee wishes to place the payment. This return payment account selection message 2530 is transmitted back to MFTS 18 and received at block 2532.

At step 2532, the MFTS 18 receives the payment account selection message 2530 and determines the identity of the third party payment provider (i.e., the recipient of the payment order) that generates the ACH payment transaction. Payment order 2534 MFTS (MFTSPI) is generated and transmitted to the supplier of 2560 third-party payments. This MFTSPI 2534 is received at step 2536. At step 1562, a third party payment provider generates an ACH funds transfer (2538) and electronically transfers it to the financial institution 2580 of the payee in a known manner by ACH funds transfer. The ACH money transfer recipient at the financial institution of the payee is shown at step 2540. The payment confirmation message (not shown) is preferably generated by the payee financial institution 2580 or the third-party payment provider 2560 and issued back to the MFTS 18, so that the data records are associated with with this payment, may be updated, and any appropriate payment confirmation messages delivered to the payee’s mobile device and / or payer’s mobile device.

PAY ANYTHING BY NAME (PAPER CHECK)

FIG. 26 shows a sequence of screen images 2600 of a payer mobile device for the “Pay 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. More specifically, a paper check payment method according to an exemplary aspect of the invention is illustrated. It will be understood that the payer, in the alternative, may choose an ACH payment method (as described above) or a card payment method with a pledged limit of funds, and such a specific payment method described is only exemplary.

As in the embodiments and aspects described previously, the user first selects the Mobile Wallet application on the screen 2602, provides authentication information (e.g., login name) via the screen 2604, and authenticates through the MFTS before being provided with payment options on the screen 2606. Assume that on screen 2606 the user selects the menu item "Pay to anyone." In response to this choice, the user is provided with a short menu of menu items, as shown in screen image 2608, to select the payee, by name or by mobile phone number. According to this exemplary aspect of the invention, in response to selecting the menu item “Pay by Name” by entering the number “1” or by activating the Select control, the user is presented with a screen 2610 containing a list of selectable previously entered payees.

According to this exemplary aspect of the invention, the name “John Dow” of the exemplary payee is shown highlighted on screen 2610 and therefore selected. Screen 2610 further includes Select, Up, and Down controls that control the selection of a specific name or navigation through a list of previously entered names. In response to the user activating the Select control after the name of the specific payee, the user is presented with a screen 2612 for entering payment amount data to enter an amount for payment. The user then enters the amount to pay. In this example, the user entered $ 123.45. As in other example screens, the sum entry screen 2612 includes Next, Back, and Undo controls. In response to the user activating the Next control, the user is presented with a screen 2614 that displays the default payment source (e.g., Bank of the USA), the available default account balances of the default payment source, and prompts the user to confirm the selected default values. As in the previous examples, the user can activate the "Select" control to select the default account and payment source, or to navigate to an alternative payment source.

After selecting and / or confirming the source of payment through the screen 2614, the user is presented with a screen 2616, which allows you to select the payment method. The user uses the "Back" and "Next" buttons to navigate the menu and uses the "Select" control or the numeric button to make a selection. In this example, the “Paper Check” payment method is shown highlighted and therefore selected. In response to activating the Select control on screen 2616, the user is presented with a screen 2618 that asks for payment information and the selected payment method, for example, "Send a paper check to Mr. John Dow's default address?" At this point, the user can select the Yes, No, or Cancel control. In response to the selection of the “Yes” control, a screen 2618 appears, the user is presented with a screen 2620, which asks for confirmation of the transaction and includes transaction information including the name and mailing address of the payee. Screen 2618 includes the Pay, Change Address, and Next controls, which act to confirm a payment or change the address of the payee.

In response to the selection of the Pay control indicating payment confirmation, screen 2622 is displayed. Screen 2622 displays confirmation information that the payment in the specified amount of $ 123.45 will be made to John Dow by paper check, together with updated information on the account balance reflecting the deduction of the payment amount from the balance on the account, which is reflected in the records of MFTS 18. At this point, the user can activate the “Done” control to complete the “Pay to anyone” application, or the “Next” control to read another transaction.

FIG. 27 shows a sequence of screen images 2700 of a mobile device from the perspective of the payee, through the payee’s mobile device, for the Pay to Any payment method, where the user selects / enters the name of the payee and uses the paper check payment method according to an exemplary aspect of the invention. As in other embodiments and aspects, the displayed information may be presented to the payee by a sequence of text messages (SMS) or by displays generated by the Mobile Wallet application, if downloaded and activated on the payee’s mobile device.

As shown on screen 2702, an SMS text message is received from the SMS driver 151, or similar information generated by the Mobile Wallet application running on the payee’s mobile device. In accordance with this message, the payee is notified that someone with the phone number 404-404-4040 sent a payment in the amount of $ 123.45 by means of a paper check sent to the specified address. According to one exemplary aspect of the invention, the message to the payee includes a default payment address for sending the check by mail. If configured by the Mobile Wallet application, the screen 2702 preferably includes a Confirm control, a Change Address control, and a Cancel control. By activating the “Confirm” control, the payee / recipient can confirm that the displayed name and address stored in the MFTS database are correct for sending the check by mail. On the other hand, the payee has the ability to change the mailing address by activating the “Change Address” control. As in other examples, if the payee activates the “Change account” control on the screen image 2702, a separate screen (not shown) is displayed on which the payee is given the opportunity to enter an alternative address.

If the payee confirms the payment delivery method by activating the “Confirm” control on the screen 2702, a screen image 2704 is displayed that invites the payee to confirm the mailing address. Screen 2704 preferably also includes a Done control, a Change Address control, and a Cancel control. The Change Address control works as described elsewhere. Activating the Done control causes a screen 2706 to be displayed, which prompts 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, then the default address information is sent back to the MFTS 18 for storage in connection with other information related to that particular payee. Otherwise, the default address does not change.

After confirming the mailing address by activating the “Yes” control or by activating the “No” control to leave the identified address intact, screen 2708 is displayed, which invites the payee / recipient to confirm the mailing of the check to the address currently displayed . The Yes and No controls are provided to confirm or reject mailing to the specified address. If the answer is “Yes”, the response of the payee is sent to MFTS 18 for further processing of the transaction. In response to the processing of the transaction, in preparation for sending the check by mail, according to one exemplary aspect of the invention, the recipient receives a confirmation message or display 2710 indicating that payment by paper check will be sent by mail to the address that the payee asked earlier. At this point, the payee can activate the Done control to end with this function, or the Next control to process another transaction, if applicable.

FIG. 28 is a flow chart of a “Pay Any” payment method or sequence 2800 of paper payments according to an exemplary aspect of the invention, showing interactions between the payee’s mobile device 2801, MFTS 18, third party address provider 2840, third party payment provider 2860 and payee 2880. According to an exemplary to an aspect of the invention, the payee's mailing address is detected by: (1) retrieving default address information associated with the payee, stored th in the MFTS database, (2) entered by the user (payer), or (3) entered by the payee, or (4) through a third-party address provider. If the address information is not available at the time when the user requested payment by paper check, the MFTS sends a request to the third party address provider to search for the address.

As in the previous methods described elsewhere, this method 2800 includes the steps (not shown) of authenticating the user / payee to the MFTS 18, authentication via the MFTS 18, and sending the authentication confirmation message and the payee list of the user’s payments to the mobile device 15 user. In response to authentication, the user opens the Mobile Wallet application and enters a password or PIN, MFTS authenticates the registration name and sends the current list of payment recipients to the user's mobile wallet of his / her mobile device. This action provides the user with the ability to resume using the Mobile Wallet application. The user then selects "Pay to anyone" and selects the name of the payee from the list of payees accepted at the time of logging in, or enters the name of the payee. The user then enters the payment amount using a mobile device and selects the payment method by paper check. Similar steps have been described in detail elsewhere and should not be repeated here.

In response to the above steps, a message (not shown) of the mobile payment order (MPI) is generated by the user's Mobile Wallet application and transmitted to the MFTS 18. The MPI will typically include the payment amount, the payment method (in this case, paper check payment) and information about the payee. An MPI is received at MFTS 18 and processed to initiate a paper check payment method according to this aspect of the invention.

From step 2804, the MFTS 18 checks the payment order and generates a message 2806 to the third party address provider to obtain the payee address. According to one exemplary aspect of the invention, information about the addresses of payees is stored in the table of the database 158 of user data (FIG. 2), indexed by mobile phone number, name or other information. Alternatively, message 2806 is transmitted to an independent address provider 2840, which provides address information in response to the provision of a telephone number.

At step 2810, the requested address information is supplied from the third-party address provider 2840 via message 2810. The message 2810 is received by the MFTS 18 at step 2812 and is processed into message 2814, including the payee address information, which is transmitted to the payee’s mobile device 2802 . A display such as that shown on screen 2702 in FIG. 27, is formed by the payee, as indicated by 2802. It will be understood that the payee can receive an SMS message with this information, or the Mobile Wallet application running on the payee’s mobile device can provide this information to the payee.

At step 218, the payee confirms the submitted address via screens, as shown in FIG. 27. A confirmation message 2820 is generated and returned to MFTS 18. At step 2822, the MFTS formulates the MFTS payment order message (MFTSPI) 2824 and transmits this message to the third party payment provider 2860. The third party payment provider receives the message at step 2826 and processes the MFTSPI message 2828 to generate a paper check, which is sent by mail to the payee, at the address indicated in the messages. At step 2830, the payee 2880 receives the payment by paper check by mail.

PAY ANYWHERE - CARD WITH LOAN LIMIT FOR FUNDS

FIG. 29 shows a sequence of screen images 2900 of a payer mobile device for the “Pay to anyone by phone number” payment method according to an exemplary aspect of the invention. In this particular method, the payer / user selects / enters the phone number of the mobile device to identify the payee, although it will be understood that other methods are contemplated for identifying the payee. More precisely, a payment method is illustrated, including the use of a card with a pledged limit of funds (SV) according to an exemplary aspect of the invention. It will be understood that the payer, in the alternative, may choose the payment method by ACH or paper check, and that the specific payment method described is only an example of a payment using a card with a fixed limit of funds.

Those of ordinary skill in the art will appreciate that a card with a limit on funds (SV) limit includes a payment transaction infrastructure that does not form part of the present invention, but is traditional and is in widespread use. More precisely, a payment order created as described in the materials of this application is delivered by the system to the recipient of the payment order, which has the ability to issue a new card with a pledged limit of funds or to add value to a previously existing card with a pledged limit of funds. It will be taken into account that various entities can serve as the recipient of a payment order regarding the issue of a card with a pledged limit of funds, including a financial services provider or a billing aggregator for payment (separately or in conjunction with another entity that deals with an SV card), the issuer cards with a pledged limit of funds or a retailer that works with cards with a pledged limit of funds.

As a rule, making a payment on a card with a set limit of funds typically involves the acquisition by the payee of a “bank” or “unloaded” magnetic stripe card or electronic microprocessor card from an SV card provider, accompanied by a “loading” of the card at a cost (that is, a payment loan, which can be used) by presenting the card to an SV card provider with a terminal that can read information from magnetic tape or other electronic storage device Twas the data on the map. The provider then downloads the card, returning the information back to the system of the documentation processing department, indicating the amount of credit or payments available for use on the card, and returning the card to the card holder. The cardholder can then use the card in some way similar to other payment cards (debit cards, credit cards), except that the card must be presented to an entity who can read the card and determine the available funds “downloaded” to the card by accessing the electronic system card provider payments. According to one exemplary aspect of the invention, cash can be downloaded to a traditional card with a pledged limit of funds from a mobile device (a new card with a pledged limit of funds that is issued to the payee, or by loading or reloading a previously existing card with a pledged limit of funds), by shown and described in the materials of this application.

As in the embodiments and aspects described previously, the user first selects the Mobile Wallet application on the screen 2902, provides authentication information (e.g., login name) via the screen 2904, and authenticates through the MFTS before being provided with payment options on the screen 2906. Assume that on screen 2906 the user selects the menu item "Pay to anyone." In response to this choice, the user is provided with a short menu of menu items, as shown in screen image 2908, to select the payee, by name or by mobile phone number. According to this exemplary aspect of the invention, in response to selecting the menu item “Pay by mobile phone” by entering the number “2” or by activating the Select control, the user is presented with a screen 2910 for entering the mobile number of the payee / payee.

According to this exemplary aspect of the invention, an exemplary payee phone number 404-555-2121 is entered, as shown on screen 2910. Screen 2910 further includes Next, Back, and Cancel controls that act in some way, as described previously to continue the flow of operations , return to the previous screen or cancel the transaction. In response to the user activating the Next control after entering the payee’s phone number, the user is presented with a payment amount data input screen 2912 for entering a payment amount. The user then enters the amount to pay. In this example, the user entered $ 123.45. As in other example screens, the sum entry screen 2912 includes Next, Back, and Undo controls. In response to the user activating the Next control, the user is presented with a screen 2914 that displays the default payment source (e.g., Bank of the USA), the available default account balances of the default payment source, and prompts the user to confirm the selected default values. As in the previous examples, the user can activate the "Select" control to select the default account and payment source, or to navigate to an alternative payment source.

After selecting and / or confirming the source of payment through the screen 2914, the user is presented with a screen 2916, which allows you to select the payment method. The user uses the Back and Next buttons to navigate the menu and uses the Select button to make a selection. In this example, the method of payment by the Card with the pledged limit of funds is shown highlighted, and therefore, is selected. In response to the activation of the Select control on the screen 2916, the user is presented with a screen 2918 that displays the payment confirmation and the selected payment method. According to an aspect of the invention, an exemplary screen 2918 displays a card number with a pledged limit on funds for a pre-existing card of the payee (previously saved) and provides the Pay, New card, and Cancel keys. The choice of the Pay button has the effect of making a payment through a pre-existing card with a pledged limit of funds, while the choice of the New card key has the consequence of issuing a new card with a pledged limit of funds. Of course, it will be clear that the card number with the limit on the funds of the pre-existing payee card is pre-stored on the user's / payee’s mobile device or somewhere else in order to enable payment by this method. Choosing the Pay key would then cause a 2922 screen to appear, which indicates that the payment of $ 123.45 was made to a card with a set limit of funds, using the number of a pre-existing card.

According to one exemplary aspect of the invention, when a user selects the New Card key, a display screen 2920 is displayed indicating the location at which a new and “loaded” card with a set limit of funds can be received. For example, screen 2920 shows “Please pick up your new card with a pledged limit of funds at the CVS store, which is 123 on Main Street,” plus the transaction ID. After this screen, screen 2922 is displayed, as in other embodiments, and displays a confirmation screen that notifies the payer that the payment in the indicated amount ($ 123.45 in this example) has been paid by the identified mobile number to the indicated card account with a fixed limit of funds. In addition, preferably, the account balance of the source of payment used is updated and displayed to reflect a decrease in available funds.

FIG. 30 shows a sequence of screen images 3000 of a mobile device from the perspective of the payee using the payee’s mobile device for the Pay to Any option, where the user selects / enters the phone number of the mobile device and uses the card limit payment method according to an exemplary aspect of the invention . As in other embodiments and aspects, the displayed information may be presented to the payee by a sequence of text messages (SMS) or by displays generated by the Mobile Wallet application, if downloaded and activated on the payee’s mobile device.

As shown on screen 3002, an SMS text message is received from the SMS driver 151, or similar information generated by the Mobile Wallet application running on the payee’s mobile device. In accordance with this message, the payee is notified that someone with the phone number 404-404-4040 sent a payment in the amount of $ 123.45 for delivery by card with a pledged limit. According to one exemplary aspect of the invention, a message to a payee includes a default payment method, for example, to place a card with a set limit on funds on a predefined account. If configured by the Mobile Wallet application, the screen 3002 preferably includes a Confirm control, a Change Card control, and a Cancel control. By activating the “Confirm” control, the payee / recipient can confirm that the displayed card account number with the set limit of funds stored in the MFTS database is correct for the payment. On the other hand, the payee has the opportunity to replace the card with a set limit of funds to another account by entering a new account number after activating the “Change card” control.

If the payee activates the Change Card control on the screen image 3002, a separate screen 3004 is displayed, which asks the user / payee if he wants to receive a new card. The available controls on this screen are Yes, No, and Done.

If the user selects "Yes", he will be invited, on the screen image 3006, to enter and Confirm the zip code to purchase the card. The available controls on this screen image are Confirm, Back, and Done.

After entering a valid zip code and selecting the “Confirm” control, the user will be presented, on the screen image 3008, with the storage location for acquiring a new card. The available controls on this screen are Confirm, Back, and Cancel.

In response to processing a transaction by making a payment, according to one exemplary aspect of the invention, the payee receives a confirmation message or display 3010 indicating that the received payment will be placed on a newly issued card with a set limit of funds after the user / payee has withdrawn the payment. At this point, the payee can activate the Completed control to complete the payment, or the Next control to process another transaction, if applicable.

FIG. 31 shows a flow chart for a “Pay to Any” payment method 3100, including the use of a cash limit card payment method, according to an exemplary aspect of the invention. This sequence diagram shows the interactions between the following parties: the mobile device 3102, the payee, MFTS 18, the provider 3140 of cards with a pledged limit of funds of a third party and the payee of 3160. Generally speaking, in this example, the user / payer chooses a method of payment by card with a pledged limit of funds, as shown in step 3104 and transmits this solution to the MFTS 18 through the MFTSPI 3106. The MFTS sends a request to the card provider with a set third party funds limit to create a transaction and transaction ID, as shown in step 310 8. The payment amount is debited from the payment source of the user (payer), and the card provider with a pledged limit of funds of a third party configures the card account with a pledged limit of funds on behalf of the payee at step 3112 using message 3110. The payee receives the transaction ID in an SMS message and is informed about the places where a card with a pledged limit of funds has been acquired, as shown in step 3116. The payee can then pick up a card with a pledged limit of funds from a retail location associated with a card provider with a pledged limit of funds and receive the card “loaded”, as shown in step 3118. Message 3120 is sent to the card provider with a pledged limit of funds of a third party to provide a transaction ID, card number and phone number, etc., at the stage 3122.

Starting from step 3104, it is first assumed that the user / payer has already selected a payment method with a pledged cash limit, in some way, as described elsewhere, and provided the MFTS 18 with a mobile payment order (MPI) indicating the payment amount and the selected method payment. MFTS 18 receives MPI and generates the corresponding message 3106 of the MFTS payment order containing the information required by the supplier or manufacturer of 3140 prepaid cards (with a pledged limit of funds) of a third party, and if necessary, transfers funds to the card provider, spending the selected payment source of the user / payer . MFTSPI 3106 is handed to a third party pledged card provider 3140 and received at block 3108. According to one exemplary aspect of the invention, the MFTSPI will include a zip code provided by a payee or payer to facilitate the location of one or more retail locations, in which the recipient can receive an unloaded SV card (or can reload an existing SV card). At step 3108, a third party pledged credit card provider 3140 generates a transaction identifier (ID) and searches for a zip code to locate one or more nearby retail locations so that the payee picks up and / or downloads a pledged credit card. According to one exemplary aspect of the invention, the card provider maintains a transaction ID that should be used for authentication purposes when the payee requests that the card is replenished with payment.

In addition, at step 3108, the third party card provider 3140 generates a message 3110 back to the MFTS 18 to inform the system that the cash limit card account is configured and ready for use. According to one exemplary aspect of the invention, this message 3110 includes information that provides the payee with the opportunity to identify places where an unloaded card with a set limit of funds can be received, and then loaded, and the transaction ID number. At step 3112, the MFTS 18 receives message 3110 and generates a message 3114 to the payee’s mobile device 3102, notifying that the payment has been made, the places where the card can be received and / or downloaded at certain retail locations associated with the card manufacturer , and the transaction ID that is required to authenticate the card with respect to the payee. Exemplary screens, in this regard, as shown in FIG. thirty.

At step 3116, the payee’s mobile device 3102 receives a message 3114 and displays (via SMS text message or through the Mobile Wallet application, if installed) information informing the payee that the payment is pending according to the method of payment with a card with a set limit of funds and information in regarding potential acquisition points for receiving and / or downloading a card with a set limit on funds. At step 3118, and according to one exemplary aspect of the invention, the payee physically goes to the location identified in the message and receives a card with a set limit of funds, typically not yet loaded. In addition, at step 3118, the payee with the card with a pledged limit of funds presents the card to a retail outlet or terminal associated with a third party card provider 3140 in order to download the card for use.

At step 3122, the third party card provider 3140, the payee is provided with a card with a set limit of funds with a request to activate and / or load the card with payment. A third-party card provider, typically at this point in time, requires authentication information to activate and / or load a card with a set limit of funds. In this case, the authentication information contains one or more of the following information elements: transaction ID number, card number, mobile phone number and, optionally, other information such as name, address, etc.

After the payee submits the required information to the third party card provider 3140, at step 3124, the card provider downloads the card in cash previously provided from the user / payer. At step 3128, the card with the pledged limit of funds, again loaded with payment, is returned to the payee 3160 due to transaction 3126, which can then use the card in places that allow a particular type of card with the pledged limit of funds, as a form of payment.

According to an exemplary aspect of the invention, if the payee already has a card with a pledged limit of funds, he / she can come into contact with a provider of 3140 cards with a pledged limit of funds of a third party to claim a payment using an existing card with a pledged limit of funds, and follow the steps, starting at 3122.

It will be appreciated that the above payment method, including the use of a card payment method with a pledged limit of funds, is useful for making payments to subscribers / users of MFTS 18, as well as non-subscribers, since the payee only needs to be provided with the transaction ID number and type cards with a fixed limit of funds in order to receive a payment. According to an exemplary aspect of the invention, not described in detail, information corresponding to a card with a pledged limit of funds can be displayed, in the first case, to the payee, for a message (for example, by means of a note or letter) to the payee who does not have a mobile device that can receive SMS -Messages or run the Mobile Wallet application, or does not have a mobile device at all. As soon as the initial card account with a pledged limit of funds has been created on behalf of a specific payee, the user / payer can upload additional funds to the card account with a pledged limit of funds associated with the payee, while the name of the payee will be stored in MFTS 18 , as described above, and therefore, can be quickly and easily reused to provide additional cash to the selected payee.

RESIDUES TRANSFER

FIG. 32 shows a sequence of 3200 screen displays of a mobile device corresponding to a menu item of a financial transaction “Transfer of balances” according to an exemplary aspect of the invention. Transfer of balances is a financial transaction, including the transfer of funds between different accounts of the same user. Transferring balances allows the MFTS user to use his or her mobile device to receive control information related to the user's financial accounts and transfer funds from one account to another.

As in the embodiments and aspects described previously, the user first selects the Mobile Wallet application on the screen 3202, provides authentication information (eg, login name) through the screen 3204, and authenticates through the MFTS before being provided with the selection options for making a payment (or transferring balances ) on the screen 3206. Assume that on the screen 3206 the user selects the menu item "Transfer balances". In response to this choice, the user is provided with a screen 3208 transfer balances, which provides the ability to choose the transfer of funds from one of the many selectable accounts. As shown on screen 3208 as an example, a user may prefer to transfer funds from a MasterCard ™ account, VISA ™ account, Discover ™ account, GaSL account or a US Bank account as payment sources used to transfer balances. Corresponding balances associated with such accounts are preferably also displayed in accordance with this aspect of the invention. The screen 3208 preferably further includes “Select,” “Back,” and “Next” controls for navigation and selection, similar to those of other functions. Screen 3208 shows the US Bank account highlighted, and therefore, selected.

In response to the user activating the “Select” control on the screen 3208 with a selection of available accounts in the list, an example screen for the selected account, for example, the Bank of the USA, is displayed as screen 3210. Screen 3210 displays several different accounts associated with a particular the source of payment, the Bank of the United States, namely, the savings balance, demand balance and others (for example, a money market deposit account). Screen 3210 preferably further includes Select, Back, and Next controls for navigation and selection, similar to those of other functions. Screen 3210 shows the demand account highlighted, and therefore selected.

In response to activating the “Select” control on screen 3210 with a selection of available accounts (that is, the balance of demand in the example shown) in the list, screen 3212 is displayed. Screen 3212 presents a list of available accounts / payment sources similar to that at screen 3208, except as shown for translating to as opposed to translating from. Screen 3212 preferably further includes Select, Back, and Next controls for navigation and selection, similar to those of other functions. Screen 3212 shows the GaSL score highlighted, and therefore selected.

In response to the user activating the “Select” control on screen 3212 with a selection of available accounts in the list, an example screen for the selected account, for example, GaSL, is displayed as screen 3214. Screen 3214 displays several different accounts associated with a specific account , the destination of the transfer of balances, GaSL, namely, a savings balance, a demand balance and others (for example, a money market deposit account). Screen 3214 preferably further includes Select, Back, and Next controls for navigation and selection, similar to those of other functions. Screen 3214 shows the demand account highlighted, and therefore selected.

In response to the user activating the “Select” control on screen 3214 with a selection of available accounts, for example, the balance of demand in GaSL, from the list, a screen 3216 confirming the transfer of balances is displayed. According to one exemplary aspect of the invention, the balance transfer confirmation screen 3216 provides a data entry area for user input of a money transfer amount, for example, $ 2,000 is shown. Screen 3216 preferably further includes Translate, Back, and Next controls for navigation and selection, similar to those of other functions. In response to the user activating the Transfer control, a balance transfer confirmation screen 3218 is displayed containing information indicating that the balance has been transferred. In the example shown, a transfer of balances of $ 2,000 is transferred from the US Bank's demand account to the GaSL demand account. Preferably, in addition, screen 3218 includes a display of the current balances of each of the accounts involved in the transfer of balances, updated to reflect the transfer of balances.

FIG. 33 is a flow chart of a method or sequence 3300 of a balance transfer payment transaction according to an exemplary aspect of the invention, showing interactions between the payee / 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. Balance transfers are carried out between the two financial institutions 30A and 30B.

As in the previous methods described elsewhere, the initial steps 3302, 3304, 3307 and 3309 in the remittance transfer method include receiving the authentication message 3306 from the user / payee, authentication via the MFTS 18, and sending the authentication information message 3308 to the mobile device 15 user. In response to authentication, the user opens the Mobile Wallet application at step 3302 and enters the password or PIN at 3304, the MFTS authenticates the registration name and sends, activates the Mobile wallet of the user of his / her mobile device at step 3307. This action allows the user to resume using the Mobile application wallet at step 3309. The user then selects the menu item Transfer balances at step 3310. At step 3312, the mobile device formulates a message 3314 mobile payment order (MPI) and transmits this message to MFTS 18. According to one exemplary aspect of the invention, MPI message 3320 includes information identifying the source of payment account, destination account, and balance transfer amount, so that the MFTS can draw up the proper MFTS payment orders in selected and identified financial institutions.

At step 3316, the MFTS 18 receives the MPI message 3314 and compiles the proper MFTS payment order message (MFTSPI) 3318 for transmission to the first or financial source 30A. At step 3320, the first or financial institution 30A of the source of payment receives the message 3318 MFTSPI and debit the selected account for the specified amount of money. The first or financial institution 30A of the source of payment then takes action in accordance with its own procedures for transferring this money to the selected second financial institution 30B via message 3322, as indicated at step 3320. At step 3324, the second or financial institution 30B of the destination updates its entries to indicate receipt of funds. According to one exemplary aspect of the invention, the first and second financial institutions 30A and 30B deliver the balance transfer confirmation messages indicated by messages 3330A, 3330B back to the MFTS 18, so that the MFTS 18 can update its local record of funds available in each account, in each of the financial institutions.

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

RECEIPT OF PAYMENT ON MOBILE DEVICE OF PAYMENT RECEIVER BY INSTALLING MOBILE PAPER

From the discussion above that aspects of the present invention include a payee, (1) receiving and sending a sequence of SMS messages (text messages) in order to interact with the MFTS to select a payment method, or (2) establish and use Mobile wallet application on the payee’s mobile device in order to interact with MFTS to select a method of receiving a payment and / or be given the opportunity to conduct transactions (make payments) as TBE MFTS user. The payee, therefore, does not need to have the Mobile Wallet application installed on his or her mobile device in order to take advantage of certain aspects of the invention. However, the payee with the most modern types of mobile devices available is given the opportunity to download, install and use the Mobile Wallet in accordance with some features and aspects of the invention. Thus, and according to an exemplary aspect of the invention, the person to whom the user wishes to make a payment may be provided with the ability to download the Mobile Wallet application and receive the benefits of both receiving payments and indicating payment receipt options in accordance with the described aspects of the invention, as well as the use of services mobile payments provided by MFTS 18.

In order to “extend” the benefits of Mobile Wallet to payees (who are the intended MFTS users after installing and activating the Mobile Wallet application), the present invention includes aspects for informing the payee about the ability to download and use the Mobile Wallet application, and register at as a MFTS user, provides a mobile wallet machine program via wireless download, activates the payee hedgehog to become a user of MFTS services and use the Mobile Wallet application as a user.

Turning in this respect to FIG. 34 to discuss a method for a payee to receive payment from a user of MFTS 18 and, moreover, download and install the Mobile Wallet application. FIG. 34 shows a sequence of screen images 3400 of a mobile device from the perspective of the payee, by the payee’s mobile device, for the method of receiving the payment, which includes the steps of providing the payee with the ability to download and install the Mobile Wallet application, register for service with MFTS, and, in by virtue of this, becoming ourselves users of MFTS services. Advantageously, the method provides the possibility of the so-called “viral spread” of the advantages of the Mobile Wallet application and the use of MFTS, by supplying payment recipients who receive payments from users who are already participants in the MFTS system with the ability to easily and quickly download and use the Mobile Wallet application, by becoming new users of MFTS, and, in turn, consistently distributing benefits to the payee of new MFTS users. Such new recipients of user payments, in turn, are likewise empowered to join and participate.

As in other embodiments and aspects, with respect to a payee who does not have a Mobile Wallet application installed on his mobile device, the displayed information will be presented to the payee with a sequence of text messages (SMS).

As shown on the screen or message 3402, the payee typically receives a text (SMS) message that indicates that the user has sent the payee a payment, notifying the payee of how the payment should be received. For example, a screen or message 3402 states that "404-404-4040 sent you a payment of $ 123.45." In addition, in accordance with this exemplary aspect of the invention, the screen or message 3402 includes the text “Your mobile device does not have the required application to receive payment, would you like to download the application?” The “Yes” control and the “Cancel” control are also preferred are provided so that the user may prefer to accept the download of the application or receive payment without installing the mobile application. If the user decides not to install the mobile device application, or the mobile device is not capable of installing the mobile device application, the user is given other options to receive payment. A screen is displayed if the user selects the Cancel button, as shown in the screen image 3402. The screen image (not shown in Fig. 34) provides the user with other options, such as receiving payment by paper check, through an ACH transaction or a card with a fixed limit of funds . The user can respond to the payment with a text (SMS) message back to the payer and inform the payer how he / she would like to receive the payment without installing the mobile device application. These user responses sent to the payer may include a method of receiving payment, as well as information about the addresses of the user, or information about accounts or any other related information.

If the payee selects the Yes control, the message bearing the name of the creator, the model number of the mobile device is sent back to the MFTS via MCSP. The MFTS identifies the type of mobile device owned by the payee, and the proper Mobile Wallet application that is executable on the mobile device of the payee is sent to the mobile device, and the self-installation process starts on the mobile device after the Mobile Wallet application is downloaded to the mobile device. A text message may be displayed indicating that the installation operation has begun, as illustrated in the screen image 3404. A traditional progress bar may be displayed as part of the installation process, as shown on the screen or message 3404, to notify the payee of the installation progress. Optionally, a “Cancel” control is provided so that the payee can complete the installation operation if required.

After the download of the Mobile Wallet application is completed, a screen or completion message 3406 is displayed according to one embodiment of the invention. This completion screen 3406 preferably indicates that the installation of the Mobile Wallet application has been completed. According to one exemplary aspect of the invention, the Mobile Wallet application is then executed and displays the screens (or messages) that it generates. At this stage, preferably, the Mobile Wallet application can optionally invite the payee to enter a PIN to use the application and / or the payee account maintained by the MFTS operator. Preferably, the Next, Back, and Undo controls are also provided for their specified functions. In response to the payment recipient selecting the Next control on the screen or message 3406, the PIN confirmation screen 3408 is then preferably displayed to invite the payment recipient to re-enter the PIN for confirmation. Similarly, the Next and Undo controls are preferably provided.

In response to the payment recipient selecting the Next control, the 3410 Received Payments screen is displayed. This screen preferably repeats the text that “404-404-4040 sent you a payment of $ 123.45,” and additionally includes a text inviting the payee to choose one of the many possible ways to receive payment. On an exemplary screen 3410, the payee is provided with menu items for receiving payment by ACH, paper check or card with a set limit of funds (SV). The methods, screen displays, and operations for such payment methods have been described elsewhere in this document and are not required to be repeated here. By way of example, and not limitation, the method of payment by paper check is shown highlighted on screen 3410, and therefore, is selected. MFTS is able to obtain the user's mailing address based on the phone number through a third-party address provider. If the user decides to receive a paper receipt at a different address, the user selects the “Change Address” key on the screen image 3412. Many screen images can follow to provide the user with the ability to change, edit and confirm the new mailing address. These screen images will be understood by those skilled in the art and are not described in detail here.

Preferably, a screen 3412 is displayed requesting information about the mailing address, etc., 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 then preferably displayed as described elsewhere in more detail.

At this point, the payee downloaded and installed the Mobile Wallet application and is empowered for further use after providing additional registration information, such as providing account information to configure payment sources that can be used so that the payee (now, the user) makes payments billing entities and other entities in accordance with previously described aspects of the invention. Although the user's mobile device is currently registered and involved in MFTS, the user still needs to visit the MFTS user site to add, enter information related to the payment source, billing entities, etc. This input will be discussed later in this document.

FIG. 35 is a flow chart of a Mobile Wallet installation by a method or sequence of operations of a payee 3500 according to an exemplary aspect of the invention, showing interactions between the payee / prospective user’s mobile device 3501, the MFTS 18 and a third party payment provider 30P, to enable the payee to receive payment, download and install the Mobile Wallet application on the mobile device of the payee 3501, and, therefore, be involved as a user ovatelya MFTS. It will be understood that the steps of method 3500 are typically performed after the user instructs the MFTS 18 to make a payment to a particular payee by mobile number or name, and the MFTS contacts the payee with one or more messages to notify the payee that the payment is awaiting. The steps in method 3500, therefore, typically occur at the time the payment delivery method is determined by the payee.

Starting from step 3502, the first step undertaken is the receipt by the payee, not the subscriber, with respect to the services of the MFTS 18 operator, of message 3503 indicating that the user has made the payment to the payee. According to one exemplary aspect of the invention, this message is a text message (SMS) delivered to a payee’s mobile device. At step 3502, the non-subscriber / payee sees the message, as shown in the screen image 3402 of FIG. 34, and determines whether he / she wishes to download and install the Mobile Wallet application for his or her mobile device, for example by selecting the “Yes” control on the screen 3402 of FIG. 34. Message 3506 is returned to MFTS 18 confirming the download and installation of the mobile wallet application, as well as the model and assembly number or serial number of the mobile device. At 3508, the MFTS downloads the appropriate Mobile Wallet application to the designated mobile device and installs the downloaded Mobile Wallet application, as indicated by message 3510. At 3512, the user is notified that the download and installation operations are completed and the payee / prospective user is invited to create a registration name (or PIN or password, as predefined) and becomes the MFTS user. After the authentication name / password / PIN authentication sequence (see FIG. 34), at step 3516, the payee / user is provided with a payment received screen including payment details and requesting a choice of payment method. At step 3518, the user selects the desired payment method (for example, ACH, by paper check or card with a pledged limit of funds), and at step 3520, provides details about the applicable account, necessary for the payee / user to receive the payment. This account setup information is transmitted to the MFTS 18 via one or more electronic messages 3520.

At 3522, the MFTS 18 receives the account setup information and stores the account information in association with the identification information corresponding to the payee / user in the MFTS user database. In addition, at step 3522, the MFTS 18 transmits the message 3523 of the MFTS payment order (MFTSPI) to the selected third party payment provider 30 or to the financial institution 30 (for example, an ACH payment formulator, or issuing a paper check, or a card manufacturer with a pledged limit of funds) to cause the selected payment form to be issued to the payee, as shown in step 3524. After providing this MFTSPI to the selected payment provider, also in step 3522, the MFTS 18 issues a confirmation message 3526 to the payee / user via it / Her mobile device 3501. At step 3528, the payee / user receives the payment confirmation that the payment has been sent for processing.

Following the above steps, and as indicated at step 3530, the payee (now a registered user of the MFTS services) is given the authority and the ability not only to accept further payments through the installed Mobile Wallet application, but also to register the invoicing entities for payments, as well as payment sources of the payee / user. The payee / user can now also facilitate the distribution of the Mobile Wallet application and the convenient use of MFTS and associated services by making payments to others that may not have a Mobile Wallet, and thereby distribute the use of the systems and methods of the present invention. According to an exemplary aspect of the invention, the new user is preferably provided with information identifying the MFTS website and inviting the new user to access the Internet application (FIGS. 37-42) to enter and provide detailed information related to billing entities, entities for payment, payment sources, invoices, viewing transaction details, default payment methods and receiving methods, etc.

Next, with reference to FIG. 36, a sequence of screen images 3600 is shown for a registered user to change the login PIN when such an action is necessary, according to one embodiment of the present invention. Screen images 3602 and 3604 have been explained elsewhere in this document and are not described here. On the screen image 3606, the user lights up and selects the “Change PIN” menu item from the menu provided on the screen image. For security reasons, this action requires the user to enter the current PIN code for verification in the screen image 3608. The user is requested to enter a new PIN in the screen image 3610 and to re-enter the PIN, again for verification purposes in the screen image 3612. According to one of the embodiments of the present invention, the PIN contains six digits for easy storage and can expand to any acceptable length. In another embodiment, the PIN contains alphanumeric characters if the mobile device has a full keyboard. In one embodiment, the PIN comprises case-sensitive alphanumeric characters. In one embodiment, the PIN comprises case-insensitive alphanumeric characters. In one embodiment, the implementation of the PIN has a fixed length. In another embodiment, the PIN has a variable length with a predetermined minimum length and maximum length.

A message is sent to the MFTS to notify the MFTS of a PIN change and to save the changed PIN in the MFTS user database. The MFTS sends a confirmation message back to the user's mobile device to inform the user that the PIN has been successfully changed, and this message is displayed in the screen image 3614. Here, the "Main menu" selection button leads the user to the screen image 3616 of the main menu of the mobile wallet application.

Then, referring to FIG. 37, consisting of FIG. 37A-37D, for discussing a user interface comprising screen displays of an Internet application I / O interface illustrating aspects of user registration for using a mobile financial transaction system (MFTS) through an Internet application user site, in accordance with an aspect of the present invention. FIG. 37 is an illustrative screen display of an Internet application 154, in particular an Internet application 153 of a user site (FIG. 2). In particular, FIG. 37A illustrates aspects of user registration for using the services provided by the MFTS 18. FIG. 37B, 37C, and 37D illustrate aspects of adding or editing mobile devices, and editing aspects of a mobile device.

In accordance with an aspect of the present invention, the Internet application provides a user site screen display 3701, which includes a first area 3705 including a plurality of selectable hyperlinks or keys for predetermined functions, a second data entry area 3710 and a plurality of user controls 3715 for providing special functionality. In the first area 3705, selectable hyperlinks are provided labeled “Mobile Devices”, “Accounts”, “Payees” and “Logout”. The user selection of the Mobile Devices hyperlink gives a display, as shown in 3701, which enables the user to control Mobile Devices for use in connection with the MFTS according to an aspect of the invention. User activation of the Account hyperlinks provides a display, which will be discussed in connection with FIG. 38. User activation of the Payee hyperlink provides a user display, as shown in FIG. 39, which will be described below.

The second data entry area 3710 displays the mobile numbers of any mobile devices that were previously registered by the present user for use with the MFTS 18. The second area 3710 shows a single mobile device number (404) 505-6060, which is an exemplary mobile device number.

A selectable user control element 3715 provides commands for implementing functions in conjunction with the registered mobile number (s). According to an aspect of the invention, the presently considered and preferred embodiment, the user control 3715 comprises a Add device key 3717, Initialize key 3720, Edit device key 3725, Lost device key 3730, Unlock key 3735 device ”and key 3740“ Delete device ”.

These functions are self explanatory and will be understood by those skilled in the art. In one embodiment, the “Lost device” function is to shut down the reported lost mobile device to protect the user. The “Unlock Device” function is to re-launch a disconnected mobile device or re-activate a mobile device after several consecutive failed system logins. The function "Delete device" is to remove the registered mobile device from the service of the mobile financial transaction system.

The user activating the Add Device key 3717 or the Edit Device key 3725 prompts the MFTS Internet application to display a screen display 3701B, as shown in FIG. 37B. The display screen 3701B includes a data entry area 3745 for entering a telephone number of a mobile device into which a user can enter a number. The “Submit Request for Review” key 3750 is provided for prompting the Internet application to use the number entered in the data entry area 3745 and enter / retrieve user information corresponding to the number of the mobile device so that information can be entered for use in connection with the MFTS 18 , or so that the properties or information related to the previously entered number can be edited. Key 3717 "Add device" and key 3725 "Edit device" provide the user with the ability to enter account information related to the mobile device. Information related to the mobile device includes: username, mailing address, billing address for payment, username and password for accessing the Internet.

FIG. 37C illustrates a user site display screen 3701C that is displayed to a user after entering a new mobile device number in order to configure the mobile device for use with the MFTS 18, in accordance with aspects of the invention. According to one embodiment of the present invention, after receiving the newly entered mobile device number for use in the system, a text (SMS) message is transmitted to the mobile device with the mobile device number entered. This SMS message, in accordance with an aspect of the invention, provides information to a user on a mobile device for downloading and installing a mobile device application in order to configure the mobile device for use in connection with the system. Guidance information, such as that shown on 3760, is preferably displayed to the user, reporting the transmission of a text message and order. Additionally, and in accordance with an aspect of the invention, an initialization code is provided for a mobile device for security purposes, prompting a user to enter initialization by code after launching a mobile device application on a mobile device.

FIG. 37D displays a display screen 3701D containing a message 3765 displayed in response to a user activating the “Delete device” key 3740 in FIG. 37A.

FIG. 38 illustrates various exemplary user site display screens 3801 that are displayed by an Internet application 154 in response to a user activating an Account hyperlink or button in a control area 3705. In FIG. 38A, the display screen 3801A is initially issued in response to the actuation of the “Accounts” key. The display screen 3801A includes an information display area 3805 containing a list of one or more accounts associative with a user currently interacting with the MFTS 18, an information display area 3810 displaying specific and detailed information regarding the selected account shown highlighted in the area 3805, and a plurality of control keys 3815 for implementing functions with respect to the selected account. For example, the Kyle Demand account is shown highlighted in area 3805, and specific information regarding the selected account, such as the bank code assigned by the American Banking Association, account number, account alias, etc., is displayed in the information display area 3810.

In accordance with an aspect of the invention, user control elements 3815 include a drop-down menu 3817 "Add Account", a button 3820 "Edit Selected" and a button 3825 "Delete Selected". The user selection of menu 3817 Add Account or activation of the Edit Selected key 3820 leads to a display screen such as that shown in FIG. 38B as a 3801B screen.

FIG. 38B illustrates aspects of an Internet application for editing information related to a selected account. The display screen 3801A includes exemplary data entry areas 3830 for displaying and editing certain information related to the selected account. For example, in accordance with an aspect of the invention, an area is provided for entering and editing an American Banking Association identification code, 3832, entering and editing an account number, 3835, entering and editing an account type, 3840, and entering and editing an alias for an account, 3845. Key 3850 “Offer” is provided for updating and saving information, and the “Cancel” key 3855 is provided as acting in some way known to specialists in this field of technology.

FIG. 38C is an example user site display screen 3801C that is displayed by the Internet application 154 in response to user input of an account in area 3805 (FIG. 38A), which is a card type account, for example, a credit card or a card with a set limit of funds, as opposed to a bank an account such as that shown in FIG. 38B. The display 3801C includes an information display area 3860 for information related to the card type account. As shown in FIG. 38C, the display areas include a card number display area 3862 and an alias area 3865 for entering a short name for the account to facilitate memorization. The “Next” key 3870 moves to another account or a plurality of accounts stored and maintained by the MFTS 18, and the “Cancel” key 3875 acts in a known manner.

FIG. 38D illustrates an example display screen 3801D that is displayed in response to a change by the user of information related to a card account, for example, if the user changes some information related to a card account, such as in FIG. 38C. The display screen 3801D includes an information display area 3880 for displaying a card number of an account that has been selected for input or editing, and a personal identification number (PIN) data input area 3885 for entering a PIN associated with the card account for security purposes. Key 3890 "Offer" and key 3895 "Cancel" are provided and are valid in a known manner.

IDENTIFICATION INFORMATION

FIG. 39 illustrates a display screen 3901 that is displayed in response to a user activating a hyperlink or the “Payee” button in area 3705 to manage payee to receive payments in accordance with an aspect of the invention. In FIG. 39A, the “Manage Payee” display screen 3901A includes an area 3905 for displaying information regarding payees that were previously entered by the user in the MFTS 18 through the Internet application 154, or, as appropriate, by logging into the mobile device application . As shown in FIG. 3901A, at least information related to the name of the payee and the mobile number of the payee are displayed. In accordance with another aspect of the invention, the payee in the system has other information stored in association with him, including the payee address (if available), default payment method, preferred account number for one or more methods payments available to a particular payee, and other identification information. As shown in FIG. 39A, a particular payee may be highlighted or displayed with specific information and is intended for operations such as editing or deleting. In addition, in FIG. 39A shows the control keys for the Add Payee button 3910, the Edit Selected button 3915, and the Delete Selected button 3920. The user selection of the key 3910 “Add payee” or key 3915 “Edit selected” gives a display, such as shown in FIG. 39B.

FIG. 39B is an example screen 3901B for displaying a user’s site that is displayed in response to a user of an Internet application who has decided to add a payee or edit a selected payee. An exemplary display screen 3901b includes a data input and display area 3925 that displays information related to a particular payee that has been selected in FIG. 39A, and provides the ability to enter or update information. In this embodiment, a First Name field 3927, Last Name field 3930, and Phone Number field 3935 are provided. In accordance with yet another aspect of the invention, address information, account number information, default selection for a payment method field, and other information are also provided. The Proposal key 3940 and the Cancel key 3945 are provided and are valid in a known manner.

Those skilled in the art will understand and take into account from viewing FIG. 37-39, that an Internet application input / output interface 154 is available over the Internet, which provides users with the ability to enter and edit information related to “Mobile Devices”, “Accounts” and “Payees” in order to provide functionality as described elsewhere in this document.

FIG. 40 is an alternative embodiment of user display screens generated by an I / O interface 154 of an Internet application, a structure in accordance with an alternative aspect of the invention. FIG. 40-42 offer an alternative way for user interaction with the Internet application, with a somewhat different way of displaying information and receiving user interaction regarding selected accounts, mobile devices, invoicing entities and payment sources.

FIG. 40 illustrates an example display screen 4001 provided by an Internet account management application. A display screen 4001 is provided by the Internet application for managing accounts. The display screen 4001 includes three selectable bookmarks, tab 4005 “Summary of invoices”, tab 4010 “Billing entities for payment” and tab 4015 “Sources of payments”. In FIG. 40 shows the selected tab 4005 "Summary of accounts". The information associated with the Account Summary tab 4005 includes information related to a particular user, including an account number, a mobile number associatively associated with a user's mobile device, and other identification information, as shown. Other relevant information pertaining to the user, such as address information, registration date information, and other information related to billing entities and payment sources, is preferably provided in a display area 4035. The “Edit” key 4020 is provided for editing the displayed information, while the “New” key 4025 is provided for creating a data input display screen that would enable the input of information, as shown in FIG. 40.

FIG. 41 is an exemplary alternative display screen 4101 that is displayed in response to a user activating bookmark 4010 Billing Entities. The information displayed on the display screen 4101 includes information identifying an individual account or mobile device number for the current user, as well as a display area 4120 that displays information regarding a plurality of “invoicing vendors” or invoicing entities, or people who can be paid, for example, the payee and the pay-to-pay scenario, as described elsewhere in this document. The “Edit” key 4020 and the “New” key 4025 are provided and are valid in some way described above, and which is known to those skilled in the art.

Supplier billing data area 4120, as shown in FIG. 41 includes selectable bookmarks for a plurality of billing providers, 4105, 4110 and 4115. Activating the New 4025 key adds a new bookmark and a new page for a new “billing vendor”. An exemplary bookmark 4110 is shown as selected and displays information related to a particular billing provider for which information was previously entered. In the example shown in FIG. 41, an exemplary billing entity George Electricity Company is shown along with the corresponding invoice number, address, and other identification information required to enable MFTS 18 to accept billing from the billing entity and formulate a payment to this billing entity. payment to the subject, in accordance with aspects of the invention.

In addition, on the screen 4101, there is provided a current balance data display area 4125 that displays information related to the current account balance with respect to the identified and selected billing provider, for example, “Billing the supplier 2” shown on tab 4110.

FIG. 42 is an exemplary alternative display of an Internet application in the form of a display screen 4201 displayed in response to a selection of bookmark 4015 of payment sources. An exemplary display screen 4201 includes information identifying an account that is being viewed, such as an account number, mobile number, etc., as in the previous screen, and also includes an “Edit” key 4020 and a “New” key 4025, acting as described elsewhere and in a known manner.

Bookmark 4015 "Sources of payments" also includes an area 4220 display information for displaying information related to the selected account. Many selectable bookmarks for special accounts available to the user are provided in the sample selectable bookmarks 4205, 4210, 4215, which are identified as "Bank 1", "Bank 2" and "Bank 3". In FIG. 42 shows “Bank 2” 4210 selected. The display area 4220 thus displays information associatively associated with the selected payment source, which, in this case, identifies a separate financial institution and a separate account associatively associated with the selected financial institution. For example, the information preferably includes the name of the source of payment, for example, “Georgia Best Bank,” and the corresponding account number, account type, address, and other identification information. In addition, an information display area 4225 is preferably provided for displaying a current balance associated with the selected account.

From the foregoing, those skilled in the art will understand and appreciate that the Internet application input / output interface 154 may alternatively include display screens and controls, such as those shown in FIG. 40-42 to provide the ability to user input data and edit payment sources invoicing entities or other payees, in accordance with aspects of the invention.

The exemplary embodiments of the invention set forth above were presented for purposes of illustration and description only and are not intended to be the exact or disclosed forms that are exhaustive or limiting the invention. Many modifications and variations are possible in light of the above doctrines.

Embodiments were selected and described in order to clarify the principles of the invention and their practical application in order to give other specialists in the art the opportunity to use the invention and various embodiments, and with various modifications that are suitable for the intended use. Alternative embodiments will become apparent to those skilled in the art to which the present invention relates, without departing from the spirit and scope. Accordingly, the scope of the present invention is more likely to be determined by the appended claims than by the foregoing description and exemplary embodiments described herein.

Claims (32)

1. A method of making a financial payment to a payee using a card with a pledged limit of funds (SV) using a mobile device connected to exchange information via a wireless network, the mobile device being connected via a wireless network to a mobile financial transaction system (MFTS), which is functionally connected to the recipient of the payment order, providing the possibility of issuing an SV card to the payee, the method comprising the steps of:
displaying a plurality of selectable payment methods on a mobile device corresponding to a payment to be made to an identified payee, the plurality of selectable payment methods including a method of card payment with a set limit of funds (SV);
form a mobile payment order containing information corresponding to the identified payee and indicating payment according to the method of the SV card; and
wirelessly transfer the mobile payment order from the mobile device to the MFTS, whereby the MFTS is functionally connected to the recipient of the payment order enabling the issuance of the SV card to the identified payee, and the MFTS transfers the payment order to the recipient of the payment order, and the recipient of the payment order makes the payment to the identified payee by card SV by issuing a new SV card to an identified payee or adding value tee on the pre-existing SV card identified payee. 2. The method according to claim 1, further comprising preparing a Mobile Wallet application on a user mobile device. 3. The method according to claim 2, in which the Mobile Wallet application provides for displaying selectable commands on the mobile device, including the Pay Any command, the Payment Source selection command, and the Payment Method selection command. 4. The method according to claim 3, in which the activation by the user of the payment source selection command causes the MFTS to retrieve the current account information from the selected financial service provider and wirelessly transmit the current account information to the mobile device after receiving such information from the selected financial service provider. 5. The method according to claim 3, further comprising the step of accepting a user input corresponding to the choice of a payment source for making a payment, in response to the display of a command to select a Payment Source via Mobile Wallet. 6. The method according to claim 3, in which the selection of the source of payment for the payment includes the selection of a financial services provider and the selection of a specific account associated with the selected financial services provider for making a payment. 7. The method according to claim 1, further comprising the step of displaying the account number of the previously existing payee SV card to the user to confirm that the payment should be made by crediting the previously existing payee SV card. 8. The method according to claim 1, in which the recipient of the payment order is one of the financial services provider, aggregator of billing for payment, card issuer with a pledged limit of funds, a retailer that works with cards with a pledged limit of funds. 9. The method according to claim 1, in which the mobile device is one of a cell phone, personal digital assistant (PDA), pager, smartphone, navigation device, laptop computer with a wireless connection or line. 10. A mobile device for making a financial payment to a payee using a card with a pledged limit of funds (SV), and the mobile device is connected via a wireless network to a system of mobile financial transactions (MFTS), which is functionally connected to the payee of the payment order, which allows issuing an SV card to the payee payment containing:
a display device for displaying information relating to a plurality of selectable payment methods for making a payment to a payee, the plurality of selectable payment methods including a method of card payment with a set limit of funds (SV);
a wireless communication component for communicating with (MFTS) via a wireless network; and
mobile device processor, functioning for:
displaying a plurality of selectable payment methods on a mobile device corresponding to a payment to be made to an identified payee, the plurality of selectable payment methods including a method of card payment with a set limit of funds (SV);
generating a mobile payment order containing information corresponding to the identified payee and indicating the payment according to the method of the SV card; and
wirelessly transfer the mobile payment order from the mobile device to the MFTS, whereby the MFTS is operatively connected to the recipient of the payment order enabling the issuance of the SV card to the identified payee, and the MFTS transfers the payment order to the recipient of the payment order, and the recipient of the payment order makes the payment to the identified payee via the SV card by issuing a new SV card to an identified payee or adding value to previously existing SV card of the identified payee. 11. The mobile device of claim 10, in which the processor of the mobile device further functions to prepare the Mobile wallet application on the user mobile device. 12. The mobile device according to claim 11, in which the Mobile Wallet application provides for displaying selectable commands on the mobile device, including the Pay Any command, the Payment Source selection command, and the Payment Method selection command. 13. The mobile device of claim 12, wherein the user activating the Payment Source selection command causes the MFTS to retrieve the current account information from the selected financial service provider and wirelessly transmit the current account information to the mobile device after receiving such information from the selected financial service provider. 14. The mobile device according to item 12, in which the processor of the mobile device further operates to receive user input corresponding to the choice of the source of payment for the payment, in response to the display of the command to select the Source of payment through the Mobile wallet. 15. The mobile device of claim 12, wherein selecting a payment source for making a payment includes selecting a financial services provider and selecting a specific account associated with the selected financial services provider for making a payment. 16. The mobile device of claim 10, wherein the mobile device processor further functions to display the account number of a previously existing payee card SV to the user to confirm that the payment must be made by crediting a previously existing payee card SV. 17. The mobile device of claim 10, wherein the recipient of the payment order is one of the financial services provider, billing aggregator for payment, card issuer with a pledged limit of funds, a retailer that works with cards with a pledged limit of funds. 18. The mobile device of claim 10, in which the mobile device is one of a cell phone, personal digital assistant (PDA), pager, smartphone, navigation device, laptop computer with wireless connection or line. 19. A mobile device for making a financial payment to a payee using a card with a pledged limit of funds (SV), and the mobile device is connected via a wireless network to a system of mobile financial transactions (MFTS), which is functionally connected with the payee of the payment order, which allows issuing an SV card to the payee payment containing:
means for displaying a plurality of selectable payment methods on a mobile device corresponding to a payment to be made to an identified payee, the plurality of selectable payment methods including a method of card payment with a set limit of funds (SV);
means for generating a mobile payment order containing information corresponding to the identified payee and indicating payment according to the method of the SV card; and
means for wirelessly transferring the mobile payment order from the mobile device to the MFTS, wherein the MFTS is operatively connected to the recipient of the payment order enabling the issuance of the SV card to the identified payee, and the MFTS transfers the payment order to the recipient of the payment order, and the recipient of the payment order makes a payment to the identified payee by SV cards by issuing a new SV card to an identified payee or adding the cost of the previously existing SV card of the identified payee. 20. The mobile device according to claim 19, further comprising means for preparing the Mobile Wallet application on the user mobile device. 21. The mobile device according to claim 20, in which the Mobile Wallet application provides for displaying selectable commands on the mobile device, including the Pay to anyone command, the Payment Source selection command, and the Payment Method selection command. 22. The mobile device according to item 21, in which the activation by the user of the payment source selection command causes the MFTS to retrieve the current account information from the selected financial services provider and wirelessly transmit the current account information to the mobile device after receiving such information from the selected financial services provider. 23. The mobile device according to item 21, further containing a means for receiving user input corresponding to the choice of the source of payment for making a payment, in response to the display of the command to select the Source of payment through the Mobile wallet. 24. The mobile device according to item 21, in which the choice of the source of payment for the payment includes the selection of a financial services provider and the selection of a specific account associated with the selected financial services provider for making a payment. 25. The mobile device according to claim 19, further comprising means for: displaying the account number of the previously existing payee SV card to the user to confirm that the payment should be made by crediting the previously existing payee SV card. 26. A computer-used medium having a computer-readable program code stored on it, the computer program code being adapted for execution on a computer and prompting the computer to perform a method of making a financial payment to the payee using a card with a set limit of funds (SV) using a mobile device, connected to exchange information via a wireless network, the mobile device being connected via a wireless network to a mobile financial transaction system s (MFTS), which is operably linked to a payment instruction recipient, providing the possibility of release of SV card to the payee, the method comprising:
instructions for displaying a plurality of selectable payment methods on a mobile device corresponding to a payment to be made to an identified payee, the plurality of selectable payment methods including a method of card payment with a set limit of funds (SV);
instructions for generating a mobile payment order containing information corresponding to the identified payee and indicating payment according to the method of SV card; and
instructions for wirelessly transferring the mobile payment order from the mobile device to the MFTS, wherein the MFTS is operatively connected to the recipient of the payment order enabling the issuance of the SV card to the identified payee, and the MFTS transfers the payment order to the recipient of the payment order, and the recipient of the payment order makes the payment to the identified payee by SV cards by issuing a new SV card to an identified payee or added I value in the pre-existing SV card identified payee. 27. The medium of claim 26, further comprising instructions for preparing a Mobile Wallet application on a user mobile device. 28. The medium of claim 27, wherein the Mobile Wallet application provides for displaying selectable commands on a mobile device, including Pay to anyone, Payment source selection commands, and Payment method selection commands. 29. The medium of claim 28, wherein the user activating the Payment Source selection command causes the MFTS to retrieve current account information from the selected financial service provider and wirelessly transmit current account information to the mobile device after receiving such information from the selected financial service provider. 30. The medium of claim 28, further comprising instructions for receiving user input corresponding to the selection of a payment source for making a payment, in response to displaying a command to select a Payment Source via the Mobile Wallet. 31. The medium of claim 28, wherein selecting a payment source for making a payment includes selecting a financial service provider and selecting a specific account associated with the selected financial services provider for making a payment. 32. The medium of claim 26, further comprising instructions for displaying an account number of a previously existing payee SV card to a user to confirm that payment must be made by crediting a previously existing payee SV card.

Images