AU2020101952A4 - SMT- Voice Based Mobile Banking: SECURE MONEY TRANSFER USING VOICE BASED MOBILE BANKING - Google Patents

Abstract

Patent Title: SMT- Voice Based Mobile Banking: SECURE MONEY TRANSFER USING VOICE BASED MOBILE BANKING. ABSTRACT My Invention "SMT- Voice Based Mobile Banking: is a mobile payment platform and service provides a fast, easy way to make secure payments by users of 3-G,4-G,5-G mobile devices. The platform also interfaces with nonmobile channels and devices such as apps, twitter, e-mail, instant messenger, and Web. The invented technology the funds are accessed from an account holder's mobile device such as a mobile phone or a personal digital assistant to make or receive payments. The financial transactions may be conducted on a person-to-person (P2P) or person-to-merchant (P2M) or person-to person-to person (P2P2P) basis where each party is identified by a unique indicator such as a telephone number, voice input, bar code. The invented technology the transactions may be requested through any number of means including SMS messaging, Web, e-mail, instant messenger, a mobile client application, an instant messaging plug-in application or widget. The invention also the resident on the mobile device, simplifies access and performing financial transactions in a fast, secure manner. The invented technology is a financial transactions system including a consumer interface, connected to a network, including: a Web interface to handle transaction requests from a Web browser client. The mobile Internet browser interface to handle transaction requests from a mobile Internet browser on a mobile phone client. The SMS notification interface to handle transaction requests using SMS text messaging and a mobile client application interface to handle requests from a mobile client application executing on mobile phone client. 24 FOR Dr. J. Karthikeyan (Principal) Dr. Ruchi Rani Garg (Associate Professor) Dr. Amit Kumar Gupta (Associate Professor) Dr.Vikas Goel (Associate Professor) Dr. M Pandikumar (Associate Professor) Dr. Selvaraj. P (Principal) Dr. Ashish Kumar Chakraverti (Associate Professor) Dr. Shweta Choudhary (Assistant Professor) Dr. Sumit Sangwan (Associate Professor) Dr. Yashpal Singh (Professor) TOTAL NO OF SHEET: 07 NO OF FIG: 08 Cross Bank P2P Bank Padner"A" Comuner'A' Bank Partner"B Consumer1 $®Linked Like~d FIN rd Credit iUnked Uinked Debit Debit Obopay Obopay Obopay Obopay Working Member Worilkng Member capital Pooled Capital Pwced 1 Amcount Account Acount Account 1. ConsuaerAsends bopay pali on Wy'reques5t 2. Obopay trnsfersfunds fIrom poled amoountto working aocunt. abopay Statement Treoords for Consumer 3. Obopay transfers funds from worng W 1bSyste l A's0Obosay account account to pooled account. 4. Obopay updates T records in Obopay SOR. 5. Obopay notifes Consumer'Vof Pra-ud payment Del.ion Acount 6. Obopsy peodically seitles In in Statement T records for Consuner between Partner Banks. Obopay Platform Ob p aCCount FIGURE 7: IS A SHOWS A CROSS BANK PERSON-TO-PERSON PAYMENT.

Description

FOR Dr. J. Karthikeyan (Principal) Dr. Ruchi Rani Garg (Associate Professor) Dr. Amit Kumar Gupta (Associate Professor) Dr.Vikas Goel (Associate Professor) Dr. M Pandikumar (Associate Professor) Dr. Selvaraj. P (Principal) Dr. Ashish Kumar Chakraverti (Associate Professor) Dr. Shweta Choudhary (Assistant Professor) Dr. Sumit Sangwan (Associate Professor) Dr. Yashpal Singh (Professor) TOTAL NO OF SHEET: 07 NO OF FIG: 08

Cross Bank P2P Bank Padner"A" Comuner'A' Bank Partner"B Consumer1

$®Linked Like~d FIN rd Credit

iUnked Uinked Debit Debit

Obopay Obopay Obopay Obopay Working Member Worilkng Member capital Pooled Capital Pwced 1 Amcount Account Acount Account

1. ConsuaerAsends bopay pali on Wy'reques5t 2. Obopay trnsfersfunds fIrom poled amoountto working aocunt. abopay Statement Treoords forConsumer 3. Obopay transfers funds from worng W 1bSyste l A's0Obosay account account to pooled account. 4. Obopay updates T records in Obopay SOR. 5. Obopay notifes Consumer'Vof Pra-ud payment Del.ion Acount 6. Obopsy peodically seitles Inin Statement T recordsfor Consuner between Partner Banks. Obopay Platform Ob p aCCount

FIGURE 7: IS A SHOWS A CROSS BANK PERSON-TO-PERSON PAYMENT.

Australian Government IP Australia Innovation Patent Australia

Sr.no: IP-53: Patent Title: SMT- Voice Based Mobile Banking: SECURE MONEY TRANSFER USING VOICE BASED MOBILE BANKING.

Name and address of patentees(s):

Dr. J. Karthikeyan (Principal) Address: Mangayarkarasi College of Engineering, Paravai, Madurai-625402, Tamilnadu, India. Dr. Ruchi Rani Garg (Associate Professor) (Department of Applied Sciences) Address: Meerut Institute of Engineering and Technology, Meerut, Uttar Pradesh, India. Dr. Amit Kumar Gupta (Associate Professor) (Dept. of Computer Applications) Address: KIET Group of Institutions, Ghaziabad, Uttar Pradesh, India. Dr. Vikas Goel (Associate Professor) (Dept. of IT) Address: KIET Group of Institutions Ghaziabad, Uttar Pradesh, India. Dr. M Pandikumar (Associate Professor) (Department of Electrical and Electronics Engineering) Address: Sri Sivasubramaniya Nadar College of Engineering, Kalavakam-603110, Tamil Nadu, India. Dr. Selvaraj. P (Principal) Address: Chandy College of engineering, Tuticorin, Tamilnadu, India Dr. Ashish Kumar Chakraverti (Associate Professor) (Department of Informationt Technology) Address: S/O Phool Chandra Chakraverti, Near Kuwan Mandir, Bijali Khera, Banda UP 210001, India Dr. Shweta Choudhary (Assistant Professor) (Applied Science & Humanities) Address: ABES Engineering College, Ghaziabad UP India. Dr. Sumit Sangwan (Associate Professor) Address: H.No.-609, Sector-6, Bahadurgarh, Distt. -Jhajjar, Haryana, India Pincode 124507. Dr. Yashpal Singh (Professor) (Computer Science & Engineering) Address: Village & Post Office Bhalout, Tehsil and District Rohtak, Haryana, India 124401.

Complete Specification: Australian Government.

FIELD OF THE INVENTION My Invention "SMT- Voice Based Mobile Banking" is related to secure money transfer using voice based mobile banking.

BACKGROUND OF THE INVENTION

The invention related to systems and techniques for effectuating financial transactions via mobile devices, such as mobile or cellular phones, and more particularly to a mobile, individualized payment transfer infrastructure and method for transferring payment. Further, embodiments of the present invention relate to a financial transaction system and more particularly to a closed-loop financial transaction system for person-to-person and consumer to merchant transactions and methods for using the financial transaction system.

Historically, an account holder who wished to conclude a financial transaction to buy an item has relied on various financial instruments such as currency, checks, credit cards, or debit cards. Unfortunately, these types of financial instruments have certain security issues and fraud prevention is a significant drain on the payment industry's profitability. When cash is lost or stolen, there is usually no recourse but to accept the loss. With other financial instruments, loss is not a major issue but fraud causes significant losses for the payment industry. Indeed, credit card, debit card and check fraud have been and continues as a major problem for the industry.

One reason that check fraud is so common arises due to the need to physically present a check to the payer's bank. Thus, when a check is accepted in a financial transaction, the check is not guaranteed funds. Rather, the check is merely a piece of paper where the validity of the bank that it is drawn on must be verified together with the account that is used and the signature used to authorize the payment. With a credit or debit card, the user may not be authorized but may rack up considerable charges before the issuer can deactivate the account. Clearly, what is needed is a payment system where the receiver of funds in a financial transaction is able to easily verify the validity of the entity holding the funds, the account and the balance and the identity of the person with the phone. Further, what is needed is a more secure manner to access credit and debit cards to conclude financial transactions.

While each of the above listed financial instruments have functioned well in the past, it is clear that consumers desire a simple, secure method for concluding financial transactions. The increasing use of credit cards provide ample evidence that consumers prefer to use electronic payment systems rather than carry large amounts of cash or suffer the hassle of writing multiple checks for small purchases. Even with the wide spread adoption of electronic payment systems, it is clear that there is an increasing need for faster, cheaper and more convenient electronic payment systems for completing financial transactions. Further, there is a need for an electronic payment system that is more individualized such that financial transactions are easily concluded in a manner similar to cash transactions.

Despite the rising use of credit cards, there is still a huge global population of people who rely primarily on cash transactions and who still need a convenient and cost effective electronic payment system to send and receive money. This need has led to the growing use of prepaid debit cards. Unfortunately, debit cards are primarily designed so that a consumer can cash in the debit card at a merchant who has invested in a point of sale transaction terminal. It is difficult for an individual to transfer a portion of the amount stored on a prepaid debit card to another individual without involving an inconvenient trip to a bank or a merchant with a P5S terminal. What is needed is an electronic payment system that enables financial transactions to be concluded between individuals and without the need to directly involve a third party financial institution or an outside financial institution.

PRIOR ART SEARCH US9781105B22015-05-042017-10-03Ping Identity Corporation Fallback identity authentication techniques. US9436938B12015-05-132016-09-06Square, Inc. Transaction payment processing by multiple data centers. US10402790B12015-05-282019-09-03United Services Automobile Association (USAA)Composing a focused document image from multiple image captures or portions of multiple image captures. US10026062B12015-06-042018-07-17Square, Inc. Apparatuses, methods, and systems for generating interactive digital receipts. US10339517B2*2015-06-262019-07-02Mastercard International Incorporated System and methods for providing gratuity based on location. US10621567B22015-07-012020-04-14Mastercard International Incorporation Electronic grace period billing. US10311413B22015-07-012019-06-04Mastercard International Incorporated By-item bill payments. US10535067B22015-07-012020-01-14Mastercard International Incorporated Electronic incremental payment.

OBJECTIVES OF THE INVENTION

1. The objective of the invention is to a mobile payment platform and service provides a fast, easy way to make secure payments by users of 3-G,4-G,5-G mobile devices. The platform also interfaces with nonmobile channels and devices such as apps, twitter, e-mail, instant messenger, and Web. 2. The other objective of the invention is to the invented technology the funds are accessed from an account holder's mobile device such as a mobile phone or a personal digital assistant to make or receive payments. The financial transactions may be conducted on a person-to-person (P2P) or person-to-merchant (P2M) or person-to-person-to person (P2P2P) basis where each party is identified by a unique indicator such as a telephone number, voice input, bar code. 3. The other objective of the invention is to the invented technology the transactions may be requested through any number of means including SMS messaging, Web, e mail, instant messenger, a mobile client application, an instant messaging plug-in application or widget.

4. The other objective of the invention is to the invention also the resident on the mobile device, simplifies access and performing financial transactions in a fast, secure manner. The invented technology is a financial transactions system including a consumer interface, connected to a network, including: a Web interface to handle transaction requests from a Web browser client. 5. The other objective of the invention is to the mobile Internet browser interface to handle transaction requests from a mobile Internet browser on a mobile phone client. The SMS notification interface to handle transaction requests using SMS text messaging and a mobile client application interface to handle requests from a mobile client application executing on mobile phone client.

SUMMARY OF THE INVENTION

A mobile payment platform and service provides a fast, easy way to make payments by users of mobile devices. The platform also interfaces with nonmobile channels and devices such as e-mail, instant messenger, and Web. In an implementation, funds are accessed from an account holder's mobile device such as a mobile phone or a personal digital assistant to make or receive payments. Financial transactions may be conducted on a person-to-person (P2P) or person-to-merchant (P2M) basis where each party is identified by a unique indicator such as a telephone number or bar code. Transactions may be requested through any number of means including SMS messaging, Web, e-mail, instant messenger, a mobile client application, an instant messaging plug-in application or "widget." The mobile client application, resident on the mobile device, simplifies access and performing financial transactions in a fast, secure manner.

The invention provides a mobile payment system (MPS) or mobile person-to-person payment system that allows fast and easy money transactions. The mobile phone is becoming more and more ubiquitous around the world. Many people carry a mobile phone or similar portable communications device, even if they do not carry a wallet around with them as they go about their daily lives. Through the mobile payment system and their phones, users will be able to do what they can with a normal wallet and much, much more. Users will be able send and receive money, pay for services, pay for bills, pay for movie tickets, pay for groceries, pay a babysitter, pay for coffee and a newspaper, instantly pay back a friend, split a dinner bill, send money to children, get money from parents, get quick or emergency cash, send emergency cash, pay up or collect on a friendly wager, pay for fantasy football, pay for gardening services, pay for association dues, track purchases, check the balance, and more. As can be appreciated, the system of the invention provides many benefits.

The problems and needs that the invention addresses include: Cash can be stolen and cash transactions are not traceable. Need to encourage cash to reside in banks rather than consumer's pockets. Need for low-cost or small-deposit cash storage. Need for low cost electronic payments. Need for electronic payments to be available to everyone, any-place, any-time and in near-real-time. Need for electronic payments to result in an instantly usable form (companion prepaid debit card for example, or through a real-time link into a user's demand deposit account(DDA) at a bank). Need for electronic payments to be accessible to banked and unbanked consumers. Need for electronic payments to be able to be linked to existing financial instruments such as credit, debit, prepaid, payroll, and others. Need to be able to load to and unload from existing financial instruments in real time or near-real-time. Need for electronic payments to work across banks. Need for electronic payments to be accessible via mobile devices. Need for electronic payments to be accessible via consumer media devices such as PCs, POS payment terminals, TV cable boxes, digital video recorders (DVRs), satellite boxes, and others. Need for electronic payments to be accessible via person-to-machine devices such as vending machines, parking meters, kiosks, and others. Need for electronic payments to work across electronic networks such as mobile carriers, cable carriers, satellite carriers, and others.

Some of the benefits of the invention include MPS electronic payments encourage cash to stay in the bank (instead of consumer's pockets). MPS electronic payments are safe and traceable. MPS electronic payments occur in near-real-tinae. MPS electronic payments are accessible to any-one, any-time and any-place. MPS can provide an optional or not required companion prepaid debit card (e.g., MasterCard, Visa, or other) for instant funds accessibility. MPS electronic payments can be leveraged for person-2-person (P2P) as well as person-2-merchant (P2M) transactions. MPS funds are stored within distributed pooled partner bank accounts. "T" records for MPS consumer funds are managed within the MPS payment system of record (for low cost P2P and P2M transfer).

MPS facilitates manual or automated load functionality from existing financial instruments (e.g., credit, debit, other). MPS facilitates manual or automated unload functionality to existing financial instruments (e.g., credit, debit, other). MPS can optimize load or unload processing (i.e., performing load or unload within bank when possible). MPS facilitates electronic payments in a cross-bank manner. MPS facilitates electronic payments in a cross carrier or cross network manner. MPS facilitates electronic payments in a cross device or cross channel manner (i.e., mobile, e-mail, Web, instant messenger). MPS funds are electronic, PIN protected, and "live" in the bank.

Further, a closed-loop financial transaction system based, in part, on the use of a cell phone or a PDA to make or receive payments. Financial transactions may be conducted on a person-to-person basis where each party is identified by a unique indicator such as a telephone number, e-mail address, instant messaging identifier, or bar code or on a consumer-to-merchant basis. Fee structures are disclosed to facilitate wide spread adoption and to free people from having to cany cash. The invention is a financial transactions system including a consumer interface, connected to a network, including: a Web interface to handle transaction requests from a Web browser client; a mobile Internet browser interface to handle transaction requests from a mobile Internet browser on a mobile phone client; an SMS interface to handle transaction requests using SMS text messaging; and a mobile client application interface to handle requests from a mobile client application executing on mobile phone client.

The consumer interface may include an interactive voice response interface to handle requests from a telephone voice channel. The system may include a pooled account for newly registered users, where newly registered users may conduct transactions from registered users immediately after registration. The mobile client application interface may permit a send money transaction, loading account transaction, unload account transaction, and balance inquiry transaction. The consumer interface may further include an instant messenger interface to handle requests from an instant messenger client. The system may include: a financial partner interface; a merchant interface, where users through the consumer interface can access their money at a bank connected to the system through the financial partner interface and transfer money to merchants connected to the merchant interface. The system may include a system of record managed by the financial transaction system, recording transaction executed through the consumer interface. The system may include a pooled account managed by the financial transaction system, where a number of the clients accessing the system through the consumer interface have an account in the pooled account. A number of the clients may not have an account in the pooled account but instead have an account at a financial institution, which has access to the system.

The invention is a method including: providing an application program interface to conduct transactions with a first financial partner; providing an SMS messaging interface to receive requests to conduct transactions; and providing a mobile client application interface to receive requests to conduct transactions, where through the SMS messenger interface or the mobile client interface, a client may request a transfer money from a first account at the first financial partner to a second account at the second financial partner.

The method may further include providing an applications program interface to conduct transactions with a second financial partner, where through the SMS messenger interface or the mobile client interface, a client may request a transfer of money from an account at the first financial partner to an account at the second financial partner. The method may include providing a system of record to record transactions requested through the SMS messaging and mobile client interfaces.

The invention is a method including: displaying a first screen on a display of a mobile phone to show a number of options including a first option to pay money to another and a second option to request balance information; upon a user selecting the first option, displaying a second screen where the user enters a target phone number to which to send payment; after the user enters the target phone number, displaying a third screen where the user enters a transaction amount; after the user enters the phone number, displaying a fourth screen where the user enters a PIN code; and after the user enters the PIN code, wirelessly sending transaction information including the target phone number, transaction amount, and PIN code to a server for processing.

The method may include after the user enters the target phone number, displaying a fifth screen where the user enters an optional message. The method may include: upon the user selecting the second option, wirelessly sending a request for balance information to the server; receiving balance information from the server; and displaying the balance information in a fifth screen. The method may include where the first screen further provides a third option to request payment from another. The method may include where the second screen has a third option which upon selection by the user provides the user access to an address book from which the user may select an entry to use as the target phone number. The transaction information may include a sequence number generated by the mobile phone. In an implementation, the funds of the user are maintained at the server and not on the mobile phone.

BRIEF DESCRIPTION OF THE DIAGRAM

Figure 1:is a shows a block diagram of a system of the invention.

Figure 2: is a shows a software architecture for a specific of the invention.

Figure 3:is a shows an environment for implementing an of the invention.

Figure 4: is a shows an embodiment of the invention where value added services are provided in conjunction with payment services.

Figure 5: shows a system topology for mobile person-to-person payments.

Figure 6: shows an interbank person-to-person payment.

Figure 7: is a shows a cross bank person-to-person payment.

Figure 8: is a shows a linked account load.

DESCRIPTION OF THE INVENTION

Figure 1: shows a block diagram of a system of the invention for conducting value exchange transactions including in specific implementations, mobile person-to-person payments and transactions, mobile person-to-merchant payment transactions, and mobile banking. An applications server 107 is connected to a network 109. Although only one applications server is shown, there may be any number of applications servers in a system of the invention. Such applications servers may be executing on a singer server machine or a number of server machines. As the load on an applications server increases, typically more machines will be used to handle and respond to the increased load.

A merchant interface 112 and a customer interface 116 are also connected to the network. This network may be any network to carry data including, but not limited to, the Internet, Ethernet, plain old telephone service (POTS) line, public switch telephone network (PSTN), ISDN, DSL, coaxial cable, fiber optics, satellite, cellular, wired, wireless, fixed line, serial, parallel, and many others, and combinations of these. The customer interface may handle any number of customers such as customer A, customer B, and up to customer n, where n is any positive integer. The merchant interface is also connected to the applications server. Similar to the customer interface, there may be any number of merchants that connect to the application server.

On the applications server is a payment processor 119, which may also be connected the merchant interface. A financial institution interface 123 is connected to the applications server and payment processor. There may be any number of financial institutions connected to the applications server. The applications server may also include a database

127. Alternatively, the database may be on a separate server from the applications server and accessible to the applications server through a network or other connection. The financial institution is also connected to the database. The database may include a system of record 130 and virtual pooled accounts 134, which the applications server may manage. The financial institution may manage pooled accounts 138. Therefore, the system of record and virtual pooled accounts may be managed separately from the pooled accounts at the financial institution.

A system of the invention may include any number of the elements shown in the figure. The system may include other elements not shown. Some elements may be divided into separate blocks, or some elements may be incorporated or combined with other elements (e.g., two blocks combined into a single block). Additionally, some elements may be substituted with other elements not shown (e.g., replacing one block with a different block). In operation, the system of the invention facilitates financial transactions between customers and between a customer and a merchant. In an implementation, the customer initiating a transaction may be by using a mobile device, such as a mobile phone or smartphone. Also, the target of a transaction may be a person having a mobile device, which is capable of accessing the mobile payment system.

The funding source these financial transactions may be the owner or operator of the applications server (which may sometimes be referred to a mobile payment server or mobile payment service). Then, customers (and merchants) will be able to load or unload funds from the mobile payment service. These funds may be from any source including a cash, check, cash, on-line payment solution, wire funds transfer, checking account, savings account, certificates ol' deposit, reverse mortgage account, brokerage account, dividends, bonds, hedge fund account, credit card, debit card, or any financial instrument, or any combination of these. In other implementations, the funding source is a financial institution that is accessible by the user through the mobile payment server. Funds may be transferred between financial institutions if needed. For example, customer A may sent money to customer B or a merchant, where parties have money at different financial institutions. The mobile payment system will facilitate the transfer between the institutions and notify the parties appropriately.

Figure 2: shows a software architecture for a specific embodiment of the invention. This block diagram shows the layers for a specific architecture that may be implemented on the applications server. The layers include a consumer web application container 203, payment system container 206, persistence layer 209, and relational database management system (RDBMS) layer 212. In a specific implementation, the consumer web application container and payment system container may be based on WebLogic by BEA Systems, Inc. The persistence layer may be based on Hibernate. The relational database management system may use a Oracle database. However, in other specific implementations, other vendors, suppliers, or systems may be used. For example, a system of the invention may incorporate open source code.

In the consumer web application container is a presentation layer for interface for different types of clients. Some examples of the interfaces provided include SMS gateway, phone application gateway, web services gateway, web application pages' gateway, and web application framework gateway. The phone messaging codec converts the incoming or outgoing requests, or both, such as SMS or Phone into system or client specific messages. An architecture of the invention may be including any number of these interfaces. The payment system container includes connectors to external financial or security systems, mail servers, and messaging services. There is also a business logic interface and payment system business logic. Service clients can invoke the business services through business service gateway. The gateway implementation could use EJB or other technologies.

A system of the invention may include any number of the elements shown in the figure. The system may include other elements not shown. Some elements may be divided into separate blocks, or some elements may be incorporated or combined with other elements (e.g., two blocks combined into a single block). Additionally, some elements may be substituted with other elements not shown (e.g., replacing one block with a different block).

Payment System Infrastructure-Technology Environment

An aspect of the invention is a mobile payment system or service. This application discusses many specific embodiments and implementations of individual components and elements, variations and modifications of these, and combinations of these. A system of the invention may include any of the variations or specific implementations discussed, singly or in any combination. In this application, an example of a specific implementation of a mobile payment system is provided, and this specific implementation is the T-pay system. The T-pay system is merely an example of an implementation of a mobile payment system and is discussed to describe more easily various aspects of the invention. The invention encompasses many mobile payment system implementations and is not limited to the specific implementations described.

Figure 3: is a shows a specific implementation of the invention. Figure 3 shows a robust technology environment 300 in accordance with an embodiment of the present invention that comprises a mobile client server platform 302, a scalable hardware environment 304, and bank integration 306. Platform 302 is the heart of the payment system infrastructure offering security, communication, ledger, currency, fraud and reporting, and administration. A mobile client application (MCA) runs on a J2EE payment server, the technology favored by many banks. Incoming and outgoing transaction requests are processed by HTTP or Web Services commands. Fraud detection, transactional databases, and bank integration complete the picture. It will be appreciated that in view of the ubiquitous nature of the present invention platform 302 comprises many different implementations. For example, platform 302 may comprise a server farm with a plurality of servers coupled to a network of storage devices. In other embodiments, platform may be implemented as a plurality of data centers to provide load balancing and redundancy.

Payment System Infrastructure-Hardware Environment of Platform 302

The payment system infrastructure is based on a horizontally expandable, clustered, and scalable hardware environment that provides robust failover capability. The Linux-based operating system supports thin client applications-most notably browsers such as Microsoft@ Internet Explorer, Netscape, Opera, and Mozilla Firefox. The operating system also supports rich client applications. In an implementation, Java 2 Platform, Micro Edition (J2ME) and Microsoft .NET are used on the Mobile Client Platform. The architecture is easily configurable to allow for other rich client applications as necessary.

Examples of clients that may interface with the system include mobile phones, smartphones, personal digital assistant devices, notebook computer, desktop computers, and many others. The clients may connect through a communications network to the system. This network may be wireless or wired. In a specific implementation, the network is wireless and the client devices are mobile devices. The communication network may be made of many interconnected computer systems and communication links.

Communication links may be hard-wire links, optical links, satellite or other wireless communications links, wave propagation links, or any other mechanisms for communication of information. Various communication protocols may be used to facilitate communication between the various systems. These communication protocols may include TCP/IP, HTTP protocols, wireless application protocol (WAP), vendor specific protocols, customized protocols, and others. While in one embodiment, communication network is the Internet, in other embodiments, the communication network may be any suitable communication network including a local area network (LAN), a wide area network (WAN), a wireless network, an intranet, a private network, a public network, a switched network, SMS messaging network, mobile phone network, cellular phone network, Ethernet, and combinations of these, and the like.

The network may be a wired network (e.g., using copper), telephone network, packet network, an optical network (e.g., using optical fiber), or a wireless network, or any combination of these. For example, data and other information may be passed between the computer and components (or steps) of a system of the invention using a wireless network using a protocol such as Wi-Fi (IEEE standards 802.11, 802.11a, 802.11b, 802.11e, 802.11g, 802.11i, and 802.11n, just to name a few examples). In an user interfaces with the system through a portable computing device such as a smartphone or mobile phone. A computer system may include a display, enclosure, keypad, and pointing device. Within the enclosure, the may be familiar computer components such as a processor, memory, mass storage devices, and the like. There may be a single processor or multiple processors. The processor may be a multiple core processor.

Some examples of mass storage devices which may interface with a computing device include flash and other nonvolatile memory storage, flash drives, flash card (e.g., SD cards), mass disk drives, floppy disks, magnetic disks, optical disks, magneto-optical disks, fixed disks, hard disks, CD-ROMs, recordable CDs, DVDs, recordable DVDs (e.g., DVD-R, DVD+R, DVD-RW, DVD+RW, HD-DVD, or Blu-ray Disc), battery-backed-up volatile memory, tape storage, reader, and other similar media, and combinations of these. The invention is computer software that is executed by a computing device. The computing device may be a client device or a server device, or a combination of these. A computer implemented or computer-executable version of the invention may be embodied using, stored on, or associated with computer-readable medium. A computer-readable medium may include any medium that participates in providing instructions to one or more processors for execution. Such a medium may take many forms including, but not limited to, nonvolatile, volatile, and transmission media. Nonvolatile media includes, for example, flash memory, or optical or magnetic disks. Volatile media includes static or dynamic memory, such as cache memory or RAM. Transmission media includes coaxial cables, copper wire, fiber optic lines, and wires arranged in a bus. Transmission media can also take the form of electromagnetic, radio frequency, acoustic, or light waves, such as those generated during radio wave and infrared data communications.

For example, a binary, machine-executable version, of the software of the present invention may be stored or reside in RAM or cache memory, or on mass storage device. The source code of the software of the present invention may also be stored or reside on mass storage device (e.g., hard disk, magnetic disk, tape, or CD-ROM). As a further example, code of the invention may be transmitted via wires, radio waves, or through a network such as the Internet. For example, an application program of the invention may be downloaded and installed onto a phone. After installation, the user of the phone may run the application and send money to another user. Computer software products may be written in any of various suitable programming languages such as C, C++, C#, Pascal, Fortran, Perl, SAS, SPSS, JavaScript, AJAX, and Java. The computer software product may be an independent application with data input and data display modules. Alternatively, the computer software products may be classes that may be instantiated as distributed objects. The computer software products may also be component software such as Java Beans (from Sun Microsystems) or Enterprise Java Beans (EJB from Sun Microsystems).

An operating system for the system may be one of the Microsoft Windows@ family of operating systems (e.g., Windows 95,98, Me, Windows NT, Windows 2000, Windows XP, Windows XP x64 Edition, Windows Vista, Windows CE, Windows Mobile), Linux, HP-UX, UNIX, Sun OS, Solaris, Mac OS X, Alpha OS, AIX, IRIX32, or IRJX64. Other operating systems may be used. Microsoft Windows is a trademark of Microsoft Corporation. In an, with a Web browser executing on a device, a user accesses a system on the World Wide Web (WWW) through a network such as the Internet. The web browser is used to download web pages or other content in various formats including HTML, XML, text, PDF, and postscript, and may be used to upload information to other parts of the system. The web browser may use uniform resource identifiers (URLs) to identify resources on the web and hypertext transfer protocol (HTTP) in transferring files on the web.

Platform 302 comprises a server 308 that handles interaction with account holders and maintains transactions records. Server 308 also provides the link to value added services provided by merchant partners. Server 308 utilizes a transactional database 309 that preferably comprises a data storage network. Server 308 uses information (such as account numbers, balance information, etc) obtained from transactional database 309 to manage a payment processor 310 that communicates with merchant point of sale (POS) terminals 311. Merchants may use the POS terminals 311 for financial transactions such as adding funds to a debit card for an account holder. Merchants may also establish a separate link to payment server 302 for accounting purposes.

A settlement engine handles the transactions within the closed loop system which will settle on a real time basis. The user's account and the merchant's account will be updated simultaneously. Because most merchants may also serve as load agents, the merchants will carry a balance in their account. The settlement engine will be primarily used to sweep a preset dollar amount or a dollar amount over a minimum to an external bank account held by the merchant. The settlement engine facilitates person-to-person (P2P) transactions because of the ability to transfer funds from one enrolled account holder to another enrolled account holder. Platform 302 further comprises a fraud detection system 312 for tracking information distilled from each financial transaction. Such fraud detection systems are known and are often used to monitor for fraud when credit cards are used. Risk is controlled by a general rules engine (see Figure 3) that applies limits and determine the acceptability of requested transactions from a risk perspective.

The information collected for each financial transaction may be mined for use by merchant and consumer value added applications, by business monitoring applications, by system operations applications and security monitoring applications as indicated at 313. To illustrate, a marketing engine delivers coupons or discounts to account holders from participating merchants. This engine also controls the use of instant account credits to stimulate enrollment. A currency translation module facilitates foreign operation where the value measurement in the closed loop payment system needs to be translated to other currencies. The module will also be used to control foreign exchange exposure.

Viral engine provides the ability to send funds to an unenrolled user. This module allows the account holder to send the funds which will send a message to the receiver that the funds are being held for them provided that they enroll. A roaming feature provides a Peer to Merchant transaction environment where the merchant will use a mobile phone to receive the funds where the merchant does not have access to a terminal that would typically be used for credit or debit card acceptance. One advantage of the present invention arises from the security of not accepting cash and guaranteed funds versus a check and also provides instant verification which is not feasible with a credit card purchase without a terminal.

Banking Partner Integration

The transactional databases 308 integrate directly with a pooled bank account 306 maintained at a partner bank. All funds stay within this account, although merchants have the option of transferring their funds from their prepaid debit accounts to other accounts through ACH transfers or direct DDA integration through a direct API with their bank or through the ATM network. It will be appreciated that more than one partner bank may be set up such that each account may be linked to a pooled bank account at more than one bank. Since platform 302 knows the available balance for each account (regardless of the number of bank partners) there is no risk of funds not being available when interbank settlements occur.

Working with marketing partners, including mobile operators, nationally branded merchants and financial service providers, such as the major banks and credit unions, the payment system infrastructure takes advantage of the existing mobile infrastructure and messaging technology to offer low-cost, universally accessible financial services. In an implementation, the system of the invention provides interoperability between banks. There is also interoperability between pooled accounts and any card holder accounts that are held as individual accounts.

Mobile Service Providers Partners

Mobile service providers gain incremental revenue, as well as additional data traffic and a competitive advantage, by offering their subscribers a digital payment solution. Unlike other payment systems, the present invention can be offered to a provider's entire customer base, since it can use SMS or mobile Internet service (e.g., WAP) in addition to a downloadable application. In addition, account holders can either pay their bills or top-off minutes via their service account. This is especially useful for account holders who do not have other financial services available to them.

Merchant Partners

Various merchants who traditionally accept credit cards, debit cards, checks, and cash will accept the mobile individualized payment transfer infrastructure because of the low adoption cost. Merchants also have an opportunity to earn commissions for handling prepaid account transactions such as helping account holders add funds to their accounts. Most merchants may also provide small amounts of cash back, similar to the debit card model in use today. A specific embodiment of the mobile payment service of the invention has mobile P2M extensions and web services. These allow a merchant to easily accept payment from a user either from a mobile phone or website. They can also help the merchant lower their cost of accepting the transaction and increase their reach to their customers.

Bank Partners

Banks may now "mobilize" their existing customer base with instant access to their accounts and the ability to make account holder-to-account holder payments. Cross bank transactions are also possible. With this partnership, banks can also reach consumers previously too expensive to serve. Rather than incur the expense of establishing a bank and adhering to a heavy regulatory regime, pooled accounts at participating banks, handle the front ledgers, report net positions to or on behalf of its partner banks, and allow the banks to conduct the final settlement. This is to enable compliance with governmental regulations and allow active coexistence with the banking environment. By using partner banks and companion bank accounts, the payment system infrastructure is designed to enhance account holders' existing bank accounts whenever possible, yet act as a discrete account when necessary.

All funds represented by individual prepaid debit accounts will be maintained in commercial bank accounts held in trust for account holders. At the end of each business day, the aggregate balance of all the accounts will equal the bank balance. All transactions created within a twenty-four-hour period will be settled within that period. The accounts function like a wallet with cash where the balance changes immediately. In other words, the present invention does not function as a demand deposit in which instruments may be presented by a third party. For instance, account holders will not be able to issue demand instruments such as checks. As a result, there will be no pending transactions that settle at a future date. In a specific implementation of the invention, debit card accounts are not held in a pooled account by mobile payment service provider, but in individual debit card accounts at a direct bank partner. The mobile payment service provider holds money in a pooled account for customers without cards is held in trust at the bank.

Method of Operation:

The present invention, an account holder adds money to a prepaid debit account in advance of purchases. Money may be added to a prepaid debit account at a partner's location, by way of interactive voice response (IVR) using their mobile phone or another phone, via a website accessible over the Internet or by contacting a customer service representative. In an embodiment, a user may set up a direct deposit link or link an account to a bank account via the ACH or ATM networks. Money may be transferred from an existing account at a financial service provider partner (such as a banking institution) or by depositing cash or a check to the prepaid debit account (at a participating merchant or other third party). Account holders then have access to these funds through their mobile devices to make payments and they may receive payments to their account activity from others. In other embodiments, funds may be transferred from a designated credit card account into the prepaid debit account.

The funds from each account holder are pooled at a single financial institution and each account holder has an interest in the pooled account equal to the funds deposited, minus the funds transferred to another account plus the funds received from others. Account holders may withdraw some or all of their available funds from the pooled account. Each account holder may set up a prepaid debit account at any financial institution and access the account indirectly to transfer funds. Thus, account holders are not limited to a debit card with funds maintained in the pooled account at a particular financial institution. Rather, account holders may access a debit card account at a financial institution of their choosing.

A credit card account is designated as the primary account and a cash advance is moved to a prepaid debit card account whenever the funds in the debit card account drop to, or below, a selected amount. The financial transactions are conducted on a person-to-person basis where each party is identified by a telephone number and a password (e.g., a personal identification number of PIN. Alternatively, the financial transaction may be identified by a user name and password. In other embodiments, at least one party to a transaction is identified by a bar code. The bar code may be displayed on a display such as the screen of a mobile telephone and detected by the camera that is present on most modern mobile devices. The bar code may be printed on the device or may be otherwise attached to the mobile device.

In a software application, referred to as a mobile client application (MCA), resident on the mobile phone only requires account holders to have a mobile phone number and the prepaid debit account. Optionally, a credit card or a checking account may be accessed as a source of funding. Advantageously, no additional hardware such as a point of sale terminal or Internet access required. Once registered, a account holder sets up a unique account holder identification number (PIN) to verify all transactions. Upon registering, the account holder enters their mobile phone number and a server pushes the mobile client application to their phone. Once the mobile client application is installed, the account holder can begin using the mobile phone for concluding financial transactions. Another option is for the user to download the application by going to a specific URL using the user's mobile Internet browser (e.g., get.T-pay.com) which will start the download process for the mobile application.

Account holders may also choose to link their account to a debit or credit cards offered by financial institution and which can be used at the millions of merchant locations worldwide. In addition, it allows account holders to obtain cash from the prepaid debit account using an ATM should the need arise. To account holders, concluding a financial transaction is seamless. By simply sending a message from the mobile client application equipped mobile phone to a server. The payment server validates each transaction and transfers funds or responds to the account holder's request for account information.

Sending Transaction Requests to the Server

When an account holder makes a transaction request from their mobile phone, information is routed to the mobile operator, such as Cingular or Verizon or other mobile phone service provider. The information is then routed to the payment server through a secure Internet connection. In alternative embodiments, the information is routed over alternative networks, such as wireless networks, POTS, or other available network. This redundancy is important because the account holder is not limited to a single access path to control their account and conduct financial transactions. Depending on the account holder's location or other circumstances, one or more communications avenues may not be available. However, because of the system redundancy, there will likely be at least one communication avenue available and then the financial transaction will be allowed.

Financial transaction requests are transmitted in one of two ways, depending on the account holder's mobile phone. If the account holder has an application-enabled phone, which enables transmitting the financial request through a Web-based application (HTTP or HTTPS) or a mobile application, such asJ2ME, .NET, .NET CF, WAP, or SMS, or any combination of these, the transmission goes directly to the server. A request message is sent once MCA establishes a connection with the payment server. Since application enabled devices currently constitute a relatively small portion of the devices being used today, the payment server also transmits and receives through Short Message Service, also referred to as SMS text messaging or simply SMS, because nearly all devices support SMS. In this case, financial data is routed to the mobile operator, and then to an SMS aggregator who transmits messages to the payment server in real time.

A SMS mobile payment system avoids the expense and problems associated with having a chip added to the cell phone. In operation the SMS system, financial information is sent using SMS text messaging. While SMS text messaging works well with all types of cell devices and certain other types of mobile communication devices, such as portable digital assistants or PDAs, SMS exposes unencrypted passwords or personal identification numbers (PINs) as well as balance information or details about the most recent transaction. Since anyone in possession of the phone can read the SMS message file and immediately know how to access the account of another, the present invention. Accordingly, in one embodiment, the present invention provides for the initiation of the financial transaction by way of SMS text message.

The SMS message starts with a key word that provides the type of transaction requested

PAY, REQUEST PAYMENT, BALANCE, TRANSFER, or HELP. In an implementation, "PAY" is referred to as "SEND" and "REQUEST PAY" is referred to as "GET."

Where the SMS message contains the key word that indicates a desire to transfer funds from one account holder to another account holder, the key word would be either pay or request payment (or send or get). After the key word, the amount is entered with or without a decimal point. After the amount, the target telephone number (or short code, e mail address, license number, or other identifying information) is entered. This information may be obtained from the telephone directory of the mobile device. After the telephone number, the account holder may enter in a message for display to the other party. In some circumstances, this message may be a null message. In some embodiments, the account holder may enter a supplemental message for record keeping purposes.

Once the SMS message is sent to the payment server, the PIN is entered by the account holder and sent through a voice channel connection to the payment server to verify the SMS message. The PIN is entered in via the keyboard and may be any alphanumeric code. The PIN is then sent to the payment sever as a DTMF encoded message where DTMF refers to dual tone multi frequency, the signal a telephone company receives when a telephone's touch keys are pressed. At the server, the payment server receives the SMS message via the SMS text message communication path and the PIN through the voice channel. The call to the payment server may be made by the account holder or it may be initiated as a "call back" feature by the payment server in response to receipt of the SMS message. The PIN may be sent as a DTMF encoded message to maintain security, but in other embodiments, the PIN may be spoken by the account holder and converted by an interactive voice recognition software module operating on the payment server or another server (not shown) dedicated to the handling voice calls.

In mobile device includes the mobile client application. The mobile client application is invoked, either directly by the account holder or in response to activation of the SMS text messaging feature on the mobile device. The MCA determines the best method for sending the PIN. In one alternative embodiment, the PIN is encrypted by the mobile client application and included in a subsequent SMS message that is sent to the payment server. The payment server correlates the messages by matching the telephone number and the time each message was sent. If the PIN was sent in a message that was distant in time compared to the SMS message, the transaction may be rejected. If only one of the two messages are received, the transaction may be rejected. If, however, both the SMS message with the financial transaction details (minimum of at a keyword) and the PIN code are received and are verified, then the financial transaction is concluded.

Figure 4: shows another implementation of a system of the invention. Figure 4 shows one embodiment where value added service is used between two account holders. By way of example, if an account holder associated with mobile device 401 initiates a transfer to mobile device 402, the pay request is transferred to server platform 403 as indicated by reference arrow 404. The pay request may include an optional description of the payment. For example, the account holder may annotate the payment to denote that it was an expense account item. The description may be selected from a menu displayed on the mobile device 401. Alternatively, the description may be a voice or text message associated with the payment request.

Upon receipt of the payment request, server 403 transfers funds from the payer's account to an account for the account holder associated with mobile device 402. The financial institution that manages pooled account 405 is notified of the transaction as indicated by reference arrow 406. In this manner, money is added to the account associated with mobile device 402 and debited from the account associated with mobile device 401. The financial institution then sends a confirmation as indicated by reference arrow 407.

Server platform 403 also sends a notice of the payment to mobile device 402 as indicated by reference arrow 408. A second message is sent indicating that the payment had been made is sent to mobile phone 401, as indicated by reference arrow 409. If the user of mobile device 402 is not an account holder, a new account may be opened as indicated by reference arrow 410. Alternatively, the user may withdraw funds from a designated ATM or other facility associated with financial institution that manages the pooled funds. Server platform 403 then documents the transaction by sending the transaction amount and the description of the transaction to an accounting and record keeping service 411 as indicated by reference arrow 412. Thereafter, the account holder may access the information describing their purchases that is stored and organized by account and record keeping service 411 either via the mobile device 401 or by another Internet connection (not shown).

To further show how a bill payment gets into the accounts receivable system, consider a small business that uses an accounting program (which may be stored on a personal computer) to print out a paper invoice that it mails to its customer. The customer must then pay the small business, which is usually done by check. Because the paper invoice may not be sent with the check, the small business needs to associate the account number with the check. If not the account number is not written on the check, time is wasted trying to locate match the payment to a copy of the invoice. The small business then deposits the check to their bank and manually enters the data into their accounts receivable accounting program. Clearly this antiquated process is slow and expensive to support.

However, with the present invention, the small business need only select an invoicing option that puts the invoice from the accounting program into an OFX format, by way of example, or other import/export format readable by an accounting program. This electronic invoice is then sent to the payment platform (see figure 3). The payment platform creates a "Request Payment" message that is sent to the customer. When the customer approves payment of the invoice, the payment data is sent back to the account to accounting program via OFX and puts the money into the small business' account. The OF message posts the item to accounting program. Since the customer's accounts receivable identification is their phone number, tracking and record keeping is greatly simplified. It should be noted that funds are guaranteed all the way through and there are no bounced checks or other such problems.

For accounts payable transactions, accounting and record keeping service 411 sends an OFX message with, by way of illustration, an employee's expense reimbursement (T&E) payment. The money is transferred to the employee's account and notification is sent to their mobile device. Advantageously, the present invention eliminates the manual process of entering each transaction into the accounting program. Figure 5 shows a further implementation of system for mobile person-to-person payments. As discussed above, a specific embodiment of the invention allows users or clients to interface with the mobile payment system through the Web (e.g., through an Internet browser), WAP (e.g., through a mobile Internet browser on a mobile phone, smartphone, personal digital assistant device), SMS (e.g., text messaging through a mobile phone), IVR (e.g., interactive voice response system that understands a user's voice responses or tones from telephone key presses), WSDL (e.g., web services that may be accessible through a mobile device such as a smartphone).

The system may interface with wireless phones handle by any of multiple carriers, such as Verizon, Cingular (AT&T), Sprint, Nextel, Alltel, Virgin Mobile, Amp'd Mobile, U.S. Cellular, T-Mobile, and others. The service may also interface with prepaid phones. Some benefits for the mobile carrier include: a revenue share model based transmission or subscription basis. Promotes application download/purchase. Promotes network or data usage. Promotes SMS usage. "Off bill" payment solution which will help alleviate the surprise "big bill" problem.

The mobile payment system allows many different financial services for the user. Examples of some services includes credit card load, debit card load, Automated Clearing House (ACH) load, ACH unload, person-to-person (P2P) payment, remote pay (RPAY), viral, person-to-merchant (P2M), and referrals. Other services may include automated teller machine (ATM) network load and unload such as through the NYCE, PLUS, or STAR ATM system. The system may also include bill pay integration, where a user may pay bills such as a cable bill, electricity bill, Internet service bill, telephone bill, housekeeping service bill, and other bills.

Loading of an account refers to transferring of funds to an account on the mobile payment system where funds may be transacted. For example, a user may load funds from a checking account or credit card to the user's mobile payment system account, which may be managed by financial partner or managed by the operator of the mobile payment system. payment system to another account. For example, a user may unload funds from the user's mobile payment system account, which may be managed by financial partner or managed by the operator of the mobile payment system, to a checking account or credit card.

Loading and unloading may be performed in any of the ways discussed in this application including through ACH, ATM, or credit card or interchange. The ACH is generally the least expensive but ACH is usually not real time because funds get settled in a batch mode at the end of the day. So, when an ACH fund transfer is requested, the actual funds will not be transferred and made available to the mobile payment system until typically the end of the day. For ATM and credit cards, the money transfer is real time.

ATM is typically more expensive than ACH, but less expensive to use than credit cards. Note that both ATM and ACH may be used to access a checking account of a user. Credit cards are generally the most expensive of the three to use. In an implementation, the system of the invention allows load and unload from any of these networks. In another implementation, the system allows load and unload from only one or more of these, such as from ACH only, ACH and ATM only, credit card only, ATM only, ATM and credit card only, or ACH and credit card only.

The mobile person-to-person payment system further provides a platform for one or more financial partners. These partners may include an acquirer partner such as Pay by Touch (PBT), Verisign, or other; bank or other financial institutional partner such as a New York City, San Francisco, San Jose (California), London, Shanghai, Hong Kong, or Tokyo bank, electronic bank, NYCE; direct partner (such as co-branded prepaid cards); prepaid processing partner; and an ACH partner. The mobile payment system may also interface with point of sale (POS) systems. There may be any number and combination of partners and services discussed. For example, a system may have only a single partner, may have two partners, three partners, or more than three partners. A system may include a single banking partner providing a debit card only (i.e., no credit card) for access by the mobile clients. A system may include a single banking partner providing a debit card and a credit card for access by the mobile clients. A system may include a two or more banking partners, one providing a debit card and another providing a different debit card for access by the mobile clients.

A system may include a two or more banking partners, one providing a debit card and another providing a different debit card and a credit card for access by the mobile clients. A system may include a single banking partner providing a credit card only for access by the mobile clients. A system may include a single banking partner providing a credit card only for access by the mobile clients. For each type of partner (e.g., debit card), there may be multiple such partner entities that interface with the mobile payment system or network for example, the system may interface with two banks, bank A and bank B, or any number of banking partners. The system may have any combination of the partners described in this application. For example, the system may have a direct partner and bank partner, but not a prepaid processing partner. The system may have a prepaid processing partner only. The system may have a direct partner only. The system may have multiple bank partners.

Figure 6: shows an interbank person-to-person payment. This figure shows one consumer A sending money to another consumer B, where both consumers are members of the same bank partner, A. The mobile payment system of the invention will handle the transaction. A basic flow of the transaction is:

(1) Consumer A sends mobile payment system a pay request. This pay request may be provided by any one of the ways discussed in this patent.

(2) The mobile payment system updates the T or transaction records in mobile payment system system-of-record (SOR) to reflect the transaction. These transaction records are managed by the mobile payment system.

(3) The system (e.g., T-pay) notifies consumer B of payment. This may be by way of an electronic notification, e-mail, instant message, SMS message, or other notification.

Figure 7: shows a cross-bank person-to-person payment. This figure shows one consumer A sending money to another consumer B, where the consumers are members of different bank partners. Consumer A has bank A, and consumer B has bank partner B. The mobile payment system of the invention will handle the transaction.

A basic flow of the transaction is:

(1) Consumer A sends the mobile payment system pay request.

(2) Mobile payment system transfers funds from pooled account to working account.

(3) Mobile payment system transfers funds from working account to pooled account.

(4) Mobile payment system updates T records in mobile payment system system-of record.

(5) Mobile payment system notifies consumer B of payment.

(6) Mobile payment system periodically settles between partner banks.

This settlement may occur in any periodic time period. Instead of real time, the settlement may be performed in a batch mode. For example, this may be performed once every 24 hours. The periods do not necessarily have to be equal time periods, but may be different time periods.

Figure 8: shows a linked account load. This figure shows a consumer loading the user's mobile payment system account with funds from another source. For example, a user may want to transfer some funds into the user's mobile payment system account from a checking account or credit card.

A basic flow of this transaction is:

(1) Consumer A sends mobile payment system "load" request indicating linked credit or debit instrument.

(2) (a/b) Mobile payment system submits real-time credit card (CC)/DDA transaction (good funds).

(3) Mobile payment system transfers funds from working account to pooled account.

(4) Mobile payment system updates T records in mobile payment system system-of record.

(5) Mobile payment system periodically performs treasury management. This management may occur in any periodic time period. For example, this may be performed once every 24 hours. The periods do not necessarily have to be equal time periods, but may be different time periods.

A specific example of a credit card load. From the web, a user enters a credit card number to load $300 into the user's MPS card. The MPS obtains a $300 authorization from Pay-By Touch (PBT) for the credit card transaction. The MPS sends a message to the financial partner supporting the MPS card initiating a $300 person-to-person payment from the MPS credit card account to the user's debit card account. The user's account is immediately credited with funds. PBT settles the credit card transaction and send a $300 ACH to the MPS settlement account at MPS's bank handling the settlement account. The MPS sends $300 ACH to the MSP credit card master account to replenish the funds.

WE CLAIMS

1. My Invention "SMT- Voice Based Mobile Banking: is a mobile payment platform and service provides a fast, easy way to make secure payments by users of 3-G,4 G,5-G mobile devices. The platform also interfaces with nonmobile channels and devices such as apps, twitter, e-mail, instant messenger, and Web. The invented technology the funds are accessed from an account holder's mobile device such as a mobile phone or a personal digital assistant to make or receive payments. The financial transactions may be conducted on a person-to-person (P2P) or person to-merchant (P2M) or person-to-person-to person (P2P2P) basis where each party is identified by a unique indicator such as a telephone number, voice input, bar code. The invented technology the transactions may be requested through any number of means including SMS messaging, Web, e-mail, instant messenger, a mobile client application, an instant messaging plug-in application or widget. The invention also the resident on the mobile device, simplifies access and performing financial transactions in a fast, secure manner. The invented technology is a financial transactions system including a consumer interface, connected to a network, including: a Web interface to handle transaction requests from a Web browser client. The mobile Internet browser interface to handle transaction requests from a mobile Internet browser on a mobile phone client. The SMS notification interface to handle transaction requests using SMS text messaging and a mobile client application interface to handle requests from a mobile client application executing on mobile phone client. 2. According to claims# the invention is to a mobile payment platform and service provides a fast, easy way to make secure payments by users of 3-G,4-G,5-G mobile devices. The platform also interfaces with nonmobile channels and devices such as apps, twitter, e-mail, instant messenger, and Web. 3. According to claiml,2# the invention is to the invented technology the funds are accessed from an account holder's mobile device such as a mobile phone or a personal digital assistant to make or receive payments. The financial transactions may be conducted on a person-to-person (P2P) or person-to-merchant (P2M) or person-to-person-to person (P2P2P) basis where each party is identified by a unique indicator such as a telephone number, voice input, bar code. 4. According to claiml,2,3# the invention is to the invented technology the transactions may be requested through any number of means including SMS messaging, Web, e-mail, instant messenger, a mobile client application, an instant messaging plug-in application or widget. 5. According to claim,2,4# the invention is to the invention also the resident on the mobile device, simplifies access and performing financial transactions in a fast, secure manner. The invented technology is a financial transactions system including a consumer interface, connected to a network, including: a Web interface to handle transaction requests from a Web browser client. 6. According to claim,2,4,5# the invention is to the mobile Internet browser interface to handle transaction requests from a mobile Internet browser on a mobile phone client. The SMS notification interface to handle transaction requests using SMS text messaging and a mobile client application interface to handle requests from a mobile client application executing on mobile phone client.

Date: 23/8/2020

Dr. J. Karthikeyan (Principal) Dr. Ruchi Rani Garg (Associate Professor) Dr. Amit Kumar Gupta (Associate Professor) Dr. Vikas Goel (Associate Professor) Dr. M Pandikumar (Associate Professor) Dr. Selvaraj. P (Principal) Dr. Ashish Kumar Chakraverti (Associate Professor) Dr. Shweta Choudhary (Assistant Professor) Dr. Sumit Sangwan (Associate Professor) Dr. Yashpal Singh (Professor)

”Ǥ Ǥƒ”–Š‹‡›ƒȋ”‹ ‹’ƒŽȌ ”Ǥ— Š‹ƒ‹ ƒ”‰ȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥ‹–—ƒ” —’–ƒȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥ‹ƒ• ‘‡Žȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥƒ†‹—ƒ”ȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥ‡Ž˜ƒ”ƒŒǤȋ”‹ ‹’ƒŽȌ 24 Aug 2020

”Ǥ•Š‹•Š—ƒ”Šƒ”ƒ˜‡”–‹ȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”ǤŠ™‡–ƒŠ‘—†Šƒ”›ȋ••‹•–ƒ–”‘ˆ‡••‘”Ȍ ”Ǥ—‹–ƒ‰™ƒȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥƒ•Š’ƒŽ‹‰Šȋ”‘ˆ‡••‘”Ȍ ǣͲ͹ ǣͲͺ ͳǣ

Ǥ

”Ǥ Ǥƒ”–Š‹‡›ƒȋ”‹ ‹’ƒŽȌ ”Ǥ— Š‹ƒ‹ ƒ”‰ȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥ‹–—ƒ” —’–ƒȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥ‹ƒ• ‘‡Žȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥƒ†‹—ƒ”ȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥ‡Ž˜ƒ”ƒŒǤȋ”‹ ‹’ƒŽȌ 24 Aug 2020

”Ǥ•Š‹•Š—ƒ”Šƒ”ƒ˜‡”–‹ȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”ǤŠ™‡–ƒŠ‘—†Šƒ”›ȋ••‹•–ƒ–”‘ˆ‡••‘”Ȍ ”Ǥ—‹–ƒ‰™ƒȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥƒ•Š’ƒŽ‹‰Šȋ”‘ˆ‡••‘”Ȍ ǣͲ͹ ǣͲͺ

ʹǣ

Ǥ

”Ǥ Ǥƒ”–Š‹‡›ƒȋ”‹ ‹’ƒŽȌ ”Ǥ— Š‹ƒ‹ ƒ”‰ȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥ‹–—ƒ” —’–ƒȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥ‹ƒ• ‘‡Žȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥƒ†‹—ƒ”ȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥ‡Ž˜ƒ”ƒŒǤȋ”‹ ‹’ƒŽȌ 24 Aug 2020

”Ǥ•Š‹•Š—ƒ”Šƒ”ƒ˜‡”–‹ȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”ǤŠ™‡–ƒŠ‘—†Šƒ”›ȋ••‹•–ƒ–”‘ˆ‡••‘”Ȍ ”Ǥ—‹–ƒ‰™ƒȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥƒ•Š’ƒŽ‹‰Šȋ”‘ˆ‡••‘”Ȍ ǣͲ͹ ǣͲͺ

͵ǣ

Ǥ

”Ǥ Ǥƒ”–Š‹‡›ƒȋ”‹ ‹’ƒŽȌ ”Ǥ— Š‹ƒ‹ ƒ”‰ȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥ‹–—ƒ” —’–ƒȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥ‹ƒ• ‘‡Žȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥƒ†‹—ƒ”ȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥ‡Ž˜ƒ”ƒŒǤȋ”‹ ‹’ƒŽȌ 24 Aug 2020

”Ǥ•Š‹•Š—ƒ”Šƒ”ƒ˜‡”–‹ȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”ǤŠ™‡–ƒŠ‘—†Šƒ”›ȋ••‹•–ƒ–”‘ˆ‡••‘”Ȍ ”Ǥ—‹–ƒ‰™ƒȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥƒ•Š’ƒŽ‹‰Šȋ”‘ˆ‡••‘”Ȍ ǣͲ͹ ǣͲͺ

Ͷǣ

Ǥ

ͷǣ

ǦǦǤ

”Ǥ Ǥƒ”–Š‹‡›ƒȋ”‹ ‹’ƒŽȌ ”Ǥ— Š‹ƒ‹ ƒ”‰ȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥ‹–—ƒ” —’–ƒȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥ‹ƒ• ‘‡Žȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥƒ†‹—ƒ”ȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥ‡Ž˜ƒ”ƒŒǤȋ”‹ ‹’ƒŽȌ 24 Aug 2020

”Ǥ•Š‹•Š—ƒ”Šƒ”ƒ˜‡”–‹ȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”ǤŠ™‡–ƒŠ‘—†Šƒ”›ȋ••‹•–ƒ–”‘ˆ‡••‘”Ȍ ”Ǥ—‹–ƒ‰™ƒȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥƒ•Š’ƒŽ‹‰Šȋ”‘ˆ‡••‘”Ȍ ǣͲ͹ ǣͲͺ

͸ǣ

ǦǦǤ

”Ǥ Ǥƒ”–Š‹‡›ƒȋ”‹ ‹’ƒŽȌ ”Ǥ— Š‹ƒ‹ ƒ”‰ȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥ‹–—ƒ” —’–ƒȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥ‹ƒ• ‘‡Žȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥƒ†‹—ƒ”ȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥ‡Ž˜ƒ”ƒŒǤȋ”‹ ‹’ƒŽȌ 24 Aug 2020

”Ǥ•Š‹•Š—ƒ”Šƒ”ƒ˜‡”–‹ȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”ǤŠ™‡–ƒŠ‘—†Šƒ”›ȋ••‹•–ƒ–”‘ˆ‡••‘”Ȍ ”Ǥ—‹–ƒ‰™ƒȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥƒ•Š’ƒŽ‹‰Šȋ”‘ˆ‡••‘”Ȍ ǣͲ͹ ǣͲͺ

͹ǣ

ǦǦǤ

”Ǥ Ǥƒ”–Š‹‡›ƒȋ”‹ ‹’ƒŽȌ ”Ǥ— Š‹ƒ‹ ƒ”‰ȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥ‹–—ƒ” —’–ƒȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥ‹ƒ• ‘‡Žȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥƒ†‹—ƒ”ȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥ‡Ž˜ƒ”ƒŒǤȋ”‹ ‹’ƒŽȌ 24 Aug 2020

”Ǥ•Š‹•Š—ƒ”Šƒ”ƒ˜‡”–‹ȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”ǤŠ™‡–ƒŠ‘—†Šƒ”›ȋ••‹•–ƒ–”‘ˆ‡••‘”Ȍ ”Ǥ—‹–ƒ‰™ƒȋ••‘ ‹ƒ–‡”‘ˆ‡••‘”Ȍ ”Ǥƒ•Š’ƒŽ‹‰Šȋ”‘ˆ‡••‘”Ȍ ǣͲ͹ ǣͲͺ

ͺǣ

Ǥ