WO2011068912A2 - System and method for remotely conducting and managing money transfers - Google Patents

Abstract

A method for performing financial transactions includes the steps of receiving a payment request to a processor from a first user; transmitting a confirmation request from the processor to the first user; receiving a confirmation to the processor from the first user; transferring funds from the first user to a second user via the processor; and transmitting a message to the first user and the second user that the funds transfer has been completed.

Description

[0001] TITLE

[0002] SYSTEM AND METHOD FOR REMOTELY CONDUCTING AND

MANAGING MONEY TRANSFERS [0003] CROSS-REFERENCE TO RELATED APPLICATIONS

[0004] This application claims the benefit of U.S. Provisional Patent Application

Serial No. 61/265,581, filed December 1, 2009 and U.S. Provisional Patent Application Serial No. 61/318,054, filed March 26, 2010, both of which are incorporated herein by reference as if fully set forth.

[0005] BACKGROUND OF THE INVENTION

[0006] Society has become increasingly less dependent on cash and more dependent on electronic transfers to effectuate sale/purchase transactions. While many commercial transactions are performed with credit or debit cards, the use of such cards requires the card holder to carry these cards in order to make purchases. It would be beneficial to be able to make cashless purchases without having to carry credit or debit cards.

[0007] BRIEF SUMMARY OF THE INVENTION

[0008] In one respect, the invention comprises a method of executing a financial transaction between a first financial account held by a first financial institution and a second financial account held by a second financial institution via a payment service, the method comprising: (a) withdrawing a transaction amount from the first financial account; (b) depositing the transaction amount in a first system account maintained by the payment service and held by a first financial institution; (c) withdrawing the transaction amount from a second system account maintained by the payment service and held by the second financial institution; (d) depositing the transaction amount into the second financial account; and (e) reconciling the first and second system accounts after step (d) has been performed.

[0009] In another respect, the invention comprises a method for performing cashless financial transactions comprising the steps of: (a) receiving a payment request to a processor from a first user to pay a value of a bill generated by a second user; (b) transmitting a message from the processor to the first user to input an identification code; (c) confirming the identification code and electronically transferring the value from the first user to the second user; and (d) transmitting an electronic message to the first user and the second user that the funds transfer has been completed.

[0010] In yet another respect, the invention comprises a method for executing a financial transaction between first and second users of a payment system, comprising the steps of: (a) providing a first temporary identification code to the first user in response to a request for the temporary identification code generated from a mobile device; (b) linking the first temporary identification code with a user account associated with the first user; and (c) executing a financial transaction in response to a transaction request initiated by a second user, the transaction request including the first temporary identification code.

[0011] In yet another respect, the invention comprises a method of executing financial transactions via a payment system: (a) receiving an SMS message from a mobile phone containing instructions to process a financial transaction involving a first user wallet; (b) sending an SMS message to the mobile phone containing instructions to confirm the financial transaction; and (c) executing the financial transaction only if a second SMS message containing a correct PIN for the first user wallet is received from the mobile phone. [0012] BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The foregoing summary, as well as the following detailed description of the invention, will be better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, there are shown in the drawings certain embodiments of the present invention. It should be understood, however, that the invention is not limited to the precise arrangements and instrumentalities shown. In the drawings, the same reference numerals are employed for designating the same elements throughout the several figures. In the drawings:

[0014] FIG. 1 is a schematic drawing of a remote money management system according to a first exemplary embodiment of the present invention;

[0015] FIG. 1 A is a schematic drawing showing examples of data stored by the core shown in FIG 1 ; [0016] FIG. 2 is an exemplary embodiment of a graphical user interface (GUI) used to access the money management system of the present invention from a computer;

[0017] FIG. 3 is an exemplary embodiment of a GUI for a sign-up to use the system of FIG. 1;

[0018] FIG. 4 is an exemplary embodiment of a GUI for selecting a PIN to use the system of FIG. 1;

[0019] FIG. 5 is an exemplary embodiment of a GUI for illustrating a user's account information stored in the system of FIG. 1;

[0020] FIG. 6 is an exemplary GUI of an interface displaying user information for a user of the system of FIG. 1 ;

[0021] FIG. 7 is an exemplary embodiment of a flowchart for making a purchase using the system of FIG. 1;

[0022] FIG. 8 is an exemplary embodiment of a flowchart for a user identifying specific addressees in a response;

[0023] FIG. 9 is an exemplary embodiment of a flowchart for the system according to the present invention transmitting a payment to a newly registered user of the system;

[0024] FIG. 10 an exemplary embodiment of a flowchart illustrating a method of multiple payees sending a payment to a non-registered user using the system of FIG. 1;

[0025] FIG. 11 is an exemplary embodiment of a flowchart illustrating a method of paying a bill using the system of FIG. 1;

[0026] FIG. 12 is a schematic drawing of an exemplary embodiment of multiple users sharing an account in the system of FIG. 1;

[0027] FIG. 13 is a schematic drawing of an exemplary embodiment of multiple users sharing accounts in the system of FIG. 1;

[0028] FIG. 14 is an exemplary embodiment of a flowchart illustrating operation of the system of FIG. 1 using the shared accounts illustrated in FIG. 13;

[0029] FIG. 15 is an exemplary embodiment of a flowchart illustrating a method for looking up an account balance in the system of FIG. 1;

[0030] FIG. 16 is an exemplary embodiment of a flowchart illustrating a method for anonymously paying a bill using the system of FIG. 1 ;

[0031] FIGS. 17A-B are an exemplary embodiment of a flowchart illustrating method of using an escrow account to complete a transaction between two account users of the system of FIG. 1;

[0032] FIG. 18 is an exemplary embodiment of a flowchart illustrating a method of purchasing an item on-line using the system of FIG. 1;

[0033] FIG. 19 is an exemplary embodiment of a flowchart illustrating a method of purchasing a song via an on-line link using the system of FIG. 1;

[0034] FIG. 20 is an exemplary embodiment of a flowchart illustrating a method of loading money into an account for using the system of FIG. 1;

[0035] FIG. 21 is an exemplary embodiment of a flowchart illustrating a method of making a financial donation using the system of FIG. 1;

[0036] FIG. 22 is an exemplary embodiment of a flowchart illustrating a method of paying a bill using the system of FIG. 1;

[0037] FIG. 23 is an exemplary embodiment of a flowchart illustrating a method of transmitting money to another account holder using the system of FIG. 1;

[0038] FIG. 24 is an exemplary embodiment of a flowchart illustrating a method of transmitting money to a non-account holder using the system of FIG. 1;

[0039] FIG. 25 is an exemplary embodiment of a flowchart illustrating a method of generating and using a sales promotion using the system of FIG. 1;

[0040] FIG. 26 is an exemplary embodiment of a flowchart illustrating a method of generating and making a charitable donation using the system of FIG. 1;

[0041] FIG. 27 is an exemplary embodiment of a flowchart illustrating a method of generating and using a gift card using the system of FIG. 1;

[0042] FIG. 28 is an exemplary embodiment of a flowchart illustrating a method of using a photo of a system user to provide security for using the system of FIG. 1;

[0043] FIG. 29 is an exemplary embodiment of a flowchart illustrating a method of locking/unlocking a phone to secure/allow use of the system of FIG. 1;

[0044] FIG. 30 is an exemplary embodiment of a flowchart illustrating a method of a user requesting that another user transfer money to the user using the system of FIG. 1 ; and

[0045] FIG. 31 is an exemplary embodiment of a flowchart illustrating a method of a user using the system of FIG. 1 with a social network to transfer funds to another user. [0046] DETAILED DESCRIPTION OF EXEMPLARY EMBODIMENTS

[0047] In describing the embodiments of the invention illustrated in the drawings, specific terminology will be used for the sake of clarity. However, the invention is not intended to be limited to the specific terms so selected, it being understood that each specific term includes all technical equivalents operating in similar manner to accomplish similar purpose. It is understood that the drawings are not drawn exactly to scale. In the drawings, similar reference numbers are used for designating similar elements throughout the several figures.

[0048] In the claims, letters are used to identify claimed steps (e.g. (a), (b),(c), etc.). These letters are used to aid in referring to the method steps and are not intended to indicate the order in which claimed steps are performed, unless and only to the extent that such order is specifically recited in the claims. Reference numerals that are introduced in the specification in association with a drawing figure may be repeated in one or more subsequent figures without additional description in the specification in order to provide context for other features.

[0049] The following describes particular embodiments of the present invention. It should be understood, however, that the invention is not limited to the embodiments detailed herein. Generally, the following disclosure refers to a system and method for remotely conducting and managing money transfers. The inventive system allows a user to make a payment to another user via a remote or a mobile device, such as, for example, a personal computer, an iTouch, an iPad, a mobile phone, a personal data assistant (PDA), or any other electronic device that is capable of transmitting and receiving electronic information. The remote device may operate wirelessly or, alternatively, the remote device may operate via a hard wire connection, such as through the Internet.

[0050] FIG. 1 illustrates an example of a remote money transfer system 100 according to the present invention. System 100 is a payment services provider that enables users, represented in FIG. 1 by User A and User B, to execute electronic payment transactions using mobile devices (represented by mobile devices 109a, 109b in FIG. 1) and/or computers (represented by computers 109c, 109d in FIG. 1). The mobile devices 109a, 109b each preferably include short message service ("SMS") capability and may optionally also include Internet connectivity. The computers 109c, 109d could be any type of computer that is connectable to the network, including desktop computers, laptop computers, personal digital assistants, tablet computers, point of sale terminals and the like.

[0051] System 100 includes a core 192, on which user information, user account data, and financial institution account data is stored. An SMS gateway 194 facilitates SMS-based communications between the system 100 and a mobile device 109a credit card / ACH gateway 198 facilitates communication between the system 100 and a credit card / ACH processor 119.

[0052] In this example, the system 100 is communicates with a computer 109c, the SMS aggregator 196 and the credit card / ACH processor 119 via communication networks 191, which preferably includes an Internet-based communication network. Similarly, the credit card / ACH processor 119 communicates with a financial institution 106 via the communication networks 191.

[0053] In this example, SMS-based communications between the system 100 and mobile device 109a are transmitted through an SMS aggregator, which communicates with mobile device 109a via the communications networks 191 and, more specifically, via the mobile communication network associated with the mobile device 109a. Any suitable network alternatively communication platform could be used to transmit SMS messages. In the event that the mobile devices 109a include Internet communication capabilities (e.g., WiFi), the mobile devices 109a could communicate with the system 100 via an Internet-based communication network.

[0054] As will be described in greater detail herein, the system 100 is preferably configured to communicate with at least one financial institution, such as financial institution A 106, financial institution B 116 and/or financial institution C 107. In addition, reconciliation of some accounts involved in system 100 transactions may involve the use of a credit card / ACH processor 119.

[0055] Referring to FIG. 1A, the system 100 uses one or more virtual accounts, or "wallets," dedicated to each user. The terms "account" and "wallet" are used interchangeably throughout this application. In this exemplary embodiment, a user wallet A 104 is associated with User A and a user wallet B 114 is associated with User B . In the example shown in FIG. 1A, all of the money handled by the system 100 is deposited into and withdrawn from master system account 105a. For example, if User A funds user wallet A 104 with $ 100 from an external funding source (discussed in greater detail herein), the $100 is deposited into the master system account 105a. Similarly, if User B elects to withdraw $50 from user wallet B 114, the $50 will be withdrawn from the master system account 105 a and transferred to user account B 114a (or another account designated by User B) via an ACH reconciliation through the credit card / ACH processor 119. Thus, in the example shown in FIG. 1A, the financial institution C that holds system master account 105 a is the only financial institution with which the system 100 has direct integration. This is commonly referred to in the industry as a "closed" system.

[0056] System 100 is preferably integrated with other financial institutions so that users can easily transfer funds to and from accounts held at the financial institutions and so that mobile banking and payments services can be offered to users through the system 100, enabling the system 100 to function much like an automated teller machine network or a bank branch.

[0057] Referring to FIG. IB, the system 100 is shown with direct integration to financial institution A 106 and financial institution B 116. A system account (in this example, system account A 108a and system account B 188b) is created at each financial institution with which the system 100 has direct integration. Direct integration with a financial institution enables the system 100 to access information and perform transactions on accounts held by that financial institution that have been linked by a user to a user wallet on the system 100. In this example, user wallet A 104 is linked to user account A 104a at financial institution A 106. Accordingly, User A will be able to access information concerning user account A 104a and perform financial transactions involving user account A 104a. Similarly, user wallet B 114 is directly linked to user account B 114a.

[0058] If User A executes a transaction using the system 100 consisting of a payment of $100 to User B, the $100 is immediately withdrawn from user account A 104a and deposited into system account A 108a. $100 is immediately withdrawn from system account B 118b and deposited into user account B 114a. System account A 108a and system account B 118b are later reconciled using an ACH transaction via the credit card / ACH processor 119. In the case of a transaction via the system 100 involving two user accounts at a the same directly integrated financial institution, the payment could be transferred directly from the payor's account to the payee's account (i.e., without involving the system account at that financial institution).

[0059] The amount of money (if any) transferred between system account A 108a and system account B 118b during reconciliation will consist of the net total of all system 100 transactions between accounts at financial institution A 106 and financial institution B 116. For example, if the transaction in the previous paragraph was the only applicable transaction since the last reconciliation, $ 100 would be transferred from system account A 108a and system account B 118b at reconciliation. If User B also paid $25 via the system 100 to another account holder at financial institution A 106 since the last reconciliation, $75 would be transferred from system account A 108a to system account B 118b at reconciliation. The use of a "system account" at each directly integrated financial institution enables user accounts to be immediately credited for transactions executed using the system 100.

[0060] As described above, each system account serves as a "clearing house" for all system 100 transactions involving accounts held at a particular financial institution and preferably contains sufficient funds to cover average daily payments due to that financial institution based on transactions involving that financial institution executed via the system 100.

[0061] As shown in FIG. IB, the master system account 105a is preferably maintained if the system 100 is configured with direct links to multiple financial institutions. This enables users (such as User A and User B) to execute transactions via the system 100 with users whose user wallets are not linked to an account at a financial institution that is directly integrated with the system or with third parties who are not users of the system 100.

[0062] A system, such as system 100, having direct access to user's bank accounts held by financial institutions is commonly referred to in the industry as an "open" system. In an open system, the user wallets effectively function as a "terminal," which enables the user to access financial information and execute transactions involving the linked account.

[0063] System 100 requires users to have access to a computer 109c, 109d with a web browser such as Microsoft Internet Explorer or Mozilla Firefox, as well as the ability to receive and review e-mail communications. Mobile devices 109a, 109b are optional, but enhance the use of system 100.

[0064] In the exemplary transactions discussed herein, the designations User A and User B will be used to identify different parties to a transaction. Depending upon the nature of the transaction, User A may be a buyer, seller, payor, or payee and User B may be a buyer, seller, payor, or payee. In some exemplary transactions, additional parties to a transaction may be identified as User 122, User 132, User 142, User 152, User 162 and User 172.

[0065] A user, such as User A, may sign up to use system 100 by providing identifying and financial information including, but not limited to, name, address, date of birth, e-mail address, remote (mobile) phone number, and/or financial account information. If a user, such as User B, is a business, User B may sign up to use system 100 by providing a taxpayer identification number, financial account information, or other identifying information.

[0066] In order to sign up to user system 100, User A logs on to a system website, represented by an exemplary graphical user interface (GUI) 200 illustrated in FIG. 2. User A clicks on button 202 to register for an account. When button 202 is clicked, GUI 210, illustrated in FIG. 3 , is provided to allow User A to sign up. Block 212 provides for User A to input required personal information and block 212 provides for User A to input financial information. User A also provides a password in block 216 that User A will use to access his/her user account.

[0067] After User A has provided all of the required information and clicks on the "ENTER" button 218, system 100 establishes the user account (in this case, user wallet A shown in FIG. 1 A) and an exemplary GUI 220 illustrated in FIG. 4 is presented. GUI 220 provides a Personal Identification Number (PIN) that User A will use to complete all transactions using system 100. A PIN generated by system 100 is provided in block 222. System 100 allows User A to change the PIN by providing his/her own desired PIN in block 224. Block 226 requests User A to confirm the PIN to ensure that User A has provided the PIN that he/she desires. After User A has provided his/her PIN, User A clicks on "ENTER" button 228. When button 228 is clicked, an exemplary GUI 230, illustrated in FIG. 5, is provided. GUI 230 provides information 103 regarding user wallet A. After User A has finished, User A clicks on "ENTER" box 238 to logout from system 100.

[0068] Referring again to FIG. 2, after User A has opened user wallet A, User A can enter his/her account number in box 204 and password in box 206, then click on "ENTER" button 208, which generates exemplary GUI 230 illustrated in FIG. 5.

[0069] To protect against fraud, the end of each message transmitted by system 100 to User A may include a unique message identification. If User A suspects that a message might be fraudulent, User A can verify the authenticity of the message via the Internet or his/her mobile device. To use the Internet, User A can access user account 104 via GUI's 200, 230 (FIGS. 2 and 5) and enter the message identification number ("message ID") into the "Verify Message" box 240 on GUI 230 and submit the message identification number to system 100. If the message is valid, system 100 replies with a message that the message is valid.

[0070] Alternatively, if User A uses his/her mobile device 109a, User A can verify message authenticity by sending the following text message "verify <message ID>" to system 100. User A may be able to communicate directly to system 100 via phone 109a using a Common Short Code (CSC). An exemplary CSC for User A to transmit a message to system 100 is 56624.

[0071] Optionally, again to FIG. 1 , system 100 may include a feature such as a white list 121, which lists parties who are eligible to send/receive money, as well as a black list 123, which lists parties who are not eligible to send/receive money. When User A (or any other user) attempts to conduct a transaction with another party, the name of the party that User 102 inputs is checked against white list 121 and black list 123. If the party's name is on white list 121, system 100 allows the transaction to be processed. If, however, the party's name is on black list 123, system 100 informs User A that the transaction will not be allowed to be processed. [0072] In an exemplary transaction in which User A wishes to make a purchase from User B, User B enters identifying information about User A (i.e., username, mobile phone number, anonymous identification, etc.) and information concerning the transaction (e.g., the purchase amount) into an interface 600 (shown in FIG. 6) that is provided by computer 109d (shown in FIG. 1). The computer 109d transmits transaction information to the system 100. The system 100 generates a text message to mobile phone 109a, asking User A to confirm payment by replying with his/her PIN. User A sends a text message from mobile phone 109a to the system 100, providing the correct PIN. The system 100 then notifies both User A (via mobile phone 109a) and User B (via computer 109d) that the transaction is complete and the transaction amount is then transferred from user wallet A to user wallet B. After the transaction is completed, system 100 preferably transmits a message to mobile phone 109a, requesting that User A erase the message that contains User A's PIN from the "sent" messages directory of mobile phone 109a. This type of message preferably sent by system 100 any time a user provides personal or confidential information via a text message.

[0073] FIG. 7 is a flowchart showing the steps of the exemplary payment transaction discussed in the previous paragraph in greater detail, including several optional steps. In Step 702, User B asks User A for identifying information (i.e., User A's username, mobile phone number, anonymous identification, etc.). User A provides identifying information, which User B enters into block 602 on interface 600 (FIG. 6), along with the cost of the transaction, which User B inputs into block 604 (step 703). If User A desires to leave a tip, User B inputs the tip amount into block 606. Additionally, if User A is paying a bill that has an associated ticket or invoice number such as, for example, a restaurant bill, User B can input the ticket number into block 608.

[0074] User B then sends a payment request to system 100 (step 704), which includes User A's identifying information and transaction information. User B can send the payment request by clicking on "CHARGE" in block 610. The system 100 then sends a personal identification number (PIN) confirmation request to User A (step 706). Step 708 is User A deciding whether he/she wants to continue with the transaction. If User A desires to continue with the transaction, step 710 includes User A transmitting his/her PIN to confirm the transaction. Alternatively, if User A desires to cancel the transaction, step 712 includes User A transmitting a cancellation message, such as, for example "N" (for "No") to cancel the transaction. Further, if User B desires to cancel the transaction, User B can click on "CLEAR" in block 614. Also, if, for some reason, User B desires to refund the charge to User A such as, for example, if User B inadvertently inputs an incorrect charge, User B can refund the charge to User A by clicking on the "REFUND" block 616.

[0075] If step 710 is selected, step 714 makes the payment and both User A and User B receive confirmation messages. If step 712 is selected, step 716 cancels the transaction and both User A and User B receive messages confirming the cancellation. A tally of transactions performed by User B can be displayed on interface 600 in blocks 620- 646, which may list the identification of each User A who made a purchase, the amount of each purchase, the ticket (or invoice number), and the date/time of each transaction.

[0076] Optionally, before the payment is made to User B, step 718 transfers the payment from user account 104 of User A to an escrow account 120 and system 100 transmits a confirmation e-mail to User A. The payment is not forwarded to user account 114 of User B until User B confirms the transaction by accepting the transaction after logging in to system 100 in step 720 via the Internet. By User B accepting the transaction via the Internet, User B generates a login trail with an IP address that enables one to determine from where User B accepted the transaction. This feature can be used to assist in identifying User B if fraud is suspected.

[0077] Alternatively, as shown in a flowchart 800 in FIG. 8, User A may transmit a payment request to User B in step 802. Then, in step 804, a third user (in this example, User C 122) may transmit a payment request to User B before User B has had a chance to response to User A. In step 806, User B has received multiple payment request before responding to previous requests. In order to allow User B to identify whether he/she is responding to User A or to User C 122, system 100 may require User B to include the Username of the other User when responding to a payment request. By way of example only, when User B receives payment requests from both User A and User C 122, User B may reply to User A in step 810 with "N User A" to deny the transaction with User A and reply to User C 122 in step 812 with "PIN User C" to execute the transaction with User C 122. [0078] In another example, as shown in a flowchart 900 in FIG. 9, in step 902, if User A requests to transmit a payment to a third party who is a non-registered user (in this example non-registered User 132), system 100 will transmit a message to non- registered User 132 informing non-registered User 132 of the proposed payment. The message transmitted to the non-registered User 132 could be an e-mail and/or text message, depending upon the information provided by User A. The amount of the proposed payment is preferably debited against User A's user wallet upon receipt of the payment request. The proposed payment could be credited to the master system wallet 105 (see FIG. 1 A) until the payment is executed or cancelled Alternatively, the proposed payment could be held in the escrow wallet 120.

[0079] In step 904, non-registered User 132 must decide whether or not to register with system 100. In step 906, if non-registered User 132 decides to register with system 100, in step 907, non-registered User 132 creates an account within a predetermined time period, such as, for example, 14 days of receipt of the notification, in order to receive the payment from User A.

[0080] Non-registered User 132 can create his/her account in the same manner that User A created account as described above. In step 908, if non-registered User 132 does not register within the predetermined time period, the payment will be cancelled and, in step 910, the payment amount will be refunded to User A. Until non-registered User 132 registers with system 100, non-registered User 132 has no right, title, or interest to any funds sent via a payment from User A.

[0081] In an alternative embodiment of the use of system 100, as shown in a flowchart 1000 in FIG. 10, if more than one registered user, such as, for example, User A and User B, each attempt to provide a payment to non-registered User 132 in step 1002 and step 1004, respectively, the sum total of both payments from User A and User B will appear in the user wallet of non-registered User 132 when non-registered User 132 registers. In step 1006, system 100 determines whether non-registered User 132 registers within a predetermined period of tine. In step 1008, if non-registered User 132 does not register within the predetermined time period, the payments will be cancelled and each respective payment amount will be refunded to UserA and User B. In step 1010, ifnon- registered User 132 does register within the predetermined time period, the payments will be applied to User 132's user wallet.

[0082] While it may sometimes be beneficial to automatically pay a bill through an electronic transfer from a User's financial institution, there may be circumstances in which the User does not want the bill to be paid without his/her input. Such circumstances may be, for example, when the user wallet (or linked financial account) that will be used to pay the bill is low on funds. System 100 may be used to alert the User that it is time for the bill to be paid, and provide a mechanism to effect payment of the bill.

[0083] In an exemplary embodiment, as shown in a flowchart 1100 in FIG. 11 , when a bill, such as, for example, a recurring bill, needs to be paid, in step 1102, system 100 transmits a message, such as, for example, a text message, to User A, informing User A that the bill needs to be paid and how much the bill is. Optionally, in step 1104, system 100 may also display the balance in the user wallet that will be used to pay the bill. In step 1106, User A may then direct system 100 to pay the bill by typing "Yes" and the appropriate PIN and sending the message through carrier 107a to system 100.

[0084] In an alternative embodiment of the present invention, illustrated in FIG. 12, a user account account may be shared among multiple Users. User A may set up a shared, account, or trusted wallet, 144 with another (secondary) User 142 so that both Users 102, 142 have access to trusted wallet 144. User 142 receives access to trusted wallet 144 as an "other" account. While FIG. 12 illustrates a secondary User 142, those skilled in the art will recognize that more than one secondary User may be added to trusted wallet 144. System 100 does not limit the number of users that can be added to trusted wallet 144.

[0085] Shared accounts may be set up as a joint account in which all Users have full access to trusted wallet 144. An exemplary scenario may involve secondary User 142 being the spouse of User A, with secondary User 142 having full access to trusted wallet 144.

[0086] Alternatively, user account 104 may be a limited access account in which secondary User 142 does not have full access to trusted wallet 144, but may have one or more of the following privileges:

View access - secondary User 142 may only view data involving trusted wallet 144 and cannot deposit or withdraw funds associated with trusted wallet 144.

Deposit access - secondary User 142 may only be able to receive payments, but cannot view balance information or account history. An exemplary secondary User 142 may be delivery personnel who receive payments upon delivery of goods from a payor, such as, in this example, User B, such as, for example, pizza.

Withdraw access - secondary User may only be able to transfer payments to Payees, but cannot view balance information or account history. An exemplary secondary User 142 may be a purchasing agent who is required to purchase goods, such as, for example, supplies for an office.

Transfer access - secondary User 142 may only be able to transfer funds between trusted wallet 144 and an external fund 148.

[0087] By way of example only, User A may also set up sharing protocols with multiple secondary users in which one secondary user is granted only VIEW access, while another secondary user is granted VIEW and DEPOSIT access.

[0088] In an exemplary embodiment, illustrated in FIG. 13, a shared account 154 may include User A being a parent and a child being child User 152. Child User 152 may desire to transfer funds to a peer, such as peer User 162. Peer User 162 has a peer parent 172, who is the primary User on a shared account 174 with peer User 162.

[0089] Referring to the flowchart 1400 in FIG. 14, step 1402 includes child User 152 sending a message to pay peer User 162. Step 1404 is child User 152 receiving a PIN confirmation from peer User 162. Step 1406 is child User 152 replying with his/her PIN. Step 1408 is User A receiving a message notifying him/her of the transaction and step 1409 is User A determining whether or not to authorize the transaction. If User A decides to authorize the transaction, step 1410 is User A replying with his/her PIN to authorize the transaction.

[0090] Step 1412 is peer User 162 receiving a message notifying him/her of child User' s 152 payment. Step 1414 is peer User 162 replying to message with PIN to accept payment. Step 1416 is peer parent 172 receiving message notifying him/her of child User's 152 payment to peer User 162 and step 1417 is peer parent 172 determining whether or not to authorize the transaction. If peer parent 172 decides to authorize the transaction, step 1418 is peer parent 172 replying with his/her PIN to authorize the transaction. Step 1420 executes the transaction and transfers funds from shared account 154 to shared account 174. Step 1422 notifies User 102, child User 152, peer User 162, and peer parent 172 that the transaction has been executed. In either of steps 1409 or 1417, an "N" reply instead of a PIN results in the cancellation of the transaction.

[0091] As discussed above, SMS is a stateless protocol, making it suitable for initiating and receiving payments through system 100. It is contemplated, however, that system 100 may be used such that a transaction may require several messages to be passed back and forth to User A. An exemplary transaction may be for a non- financial transaction, illustrated in flowchart 1500 in FIG. 15. User A may desire to do a balance lookup on user account 104. In step 1502, User A goes to GUI 210, illustrated in FIG. 3, in order to click on "BALANCE LOOKUP" 221.

[0092] In step 1504, the first time that User 102 performs this function, he is required to authenticate himself by providing his PIN. In step 1506, system 100 verifies the PIN. In step 1508, UserA clicks on box 221 to look up account balance. In step 1510, balance information for user account 104 of User A is sent by system 100 to User A. In step 1512, User A may decide to check the balance of another account, such as, for example, checking account 106. In step 1514, system 100 determines whether User A is making this check within a predetermined amount of time, such as, for example, five (5) minutes. If so, in step 1516, system 100 may recognize that User A has already been authenticated and system 100 may provide User A with the balance for checking account 106 rather than ask User A for his/her PIN again. If not, in step 1518, system 100 requests User A to re-enter his/her PIN before User A can proceed.

[0093] System 100 includes an SMS session that allows a user's phone number to act as a tracking "cookie." System 100 recognizes User's phone number as a unique identifier of User A. Using the phone number as a key, system 100 tracks the last time that User A was authenticated by system 100. Referring to step 1514, if the time is less than a predetermined time period, in step 1516, User A can initiate any non-financial transaction without re-authenticating himself/herself. If the time exceeds the predetermined time period, in step 1518, system 100 prompts User A to resend his/her PIN. Exemplary non-financial transactions may include balance lookups, account history, getting/setting account settings. As a security measure, all financial transactions may optionally require a PIN authorization even if the User has been previously authenticated within the predetermined time period.

[0094] In an exemplary embodiment illustrated in the flowchart 1600 of FIG. 16, a temporary anonymous identification may be requested. An exemplary transaction between User A and User B, wherein both User A and User B desire to remain anonymous, begins in step 1602 when User A agrees to sell an item to User B for $X.xx. In step 1604, User A texts a command to system 100 and in step 1606, User A receives a unique identification <zl2345>. In step 1608, User A then asks User B to send $X.xx to <zl2345>. In step 1610, User B transmits the command "payanon z 12345 $X.xx" to system 100. In step 1612, system 100 then transmits a message to User B asking for his PIN and notifying User B of the unique identification number assigned to him/her for this transaction as "z67890." In step 1614, User B transmits his PIN to system 100 to verify the transaction. In step 1616, system 100 completes the transaction, moving $X.xx from user account 114 of User B to user account 104 of User A. In step 1618, system 100 transmits a message to both User A and User B, using the respective temporary anonymous identifications, verifying the completed transaction.

[0095] In the event that User A and/or User B desire to remain anonymous, such as, for example, for User A to make an on-line purchase from an individual User B, such as, for example, via www.Craigslist.org, either party may request an instant alias prior to initiating or accepting a transaction. A temporary anonymous identification is a unique identification that is created on demand and has the lifespan of only the current transaction. Further, the temporary anonymous identification is only active for a predetermined period of time (i.e., fifteen (15) minutes). If the transaction is not completed during the predetermined period of time, the anonymous participant(s) must request a new unique identification from system 100.

[0096] In an alternative embodiment of a use for system 100, illustrated in the flowchart 1700 of FIG. 17, it may be desirable for User A to make a payment for an item, but to have the payment held until User B actually delivers the item being sold. System 100 addresses this issue by using escrow account 120.

[0097] In an exemplary transaction, in step 1702, User A agrees to purchase an item from User B for $X.xx. In step 1704, User A authorizes system 100 to make the payment using a "hold" command: "hold seller $X.xx." Alternatively, User A and User B may conduct the transaction anonymously, as discussed above, in which case, in step 1706, User A would use a hold command such as "holdanon" to indicate to system 100 that User A desires to remain anonymous. In step 1708, system 100 transmits a message to User A, asking User A to authenticate the transaction by sending his/her PIN to system 100.

[0098] In step 1710, User A authenticates transaction by transmitting PIN to system 100. In step 1712, system 100 transfers $X.xx from user account 104 of User A to escrow account 120 for a predetermined period of time and in step 1714 notifies User B that the payment has been made and is being held in escrow account 120. In step 1716, system 100 also transmits a transaction identification number (transaction id>) to both User A and User B to allow both users to track the status of the transaction. In step 1720, User B then ships the purchased item to User A.

[0099] Upon receipt of the purchased item, in step 1722, User A transmits a "release" command to system 100, such as, for example "release transaction id>". In step 1724, system 100 determines if the predetermined period of time has expired. If not, in step 1726, if system 100 releases the payment from escrow account 120, in step 1728, system 100 deposits the payment into user account 114 of User B, and in step 1730, system 100 notifies both User A and User B that the funds for payment have been released. In step 1724, if system 100 determines that the funds have not been released within the predetermined number of days, in step 1732, system 100 "locks" the funds in a "lock" account 125 until, in step 1734, an agent for system 100 determines whether the item has been delivered to User A. If so, in step 1736, the agent releases the funds to User B if the item has been delivered to User A or, if not, in step 1738, the agent releases the funds to User A.

[0100] In an alternative embodiment of a use for system 100, illustrated in the flowchart 1800 of FIG. 18, system 100 provides a method of purchasing an item from a retail merchant without having to physically go to the retail merchant's store to purchase the item. Merchant (User B in this example) is registered with system 100 and must have items in its inventory mapped to unique character codes, along with a unique system username. If User A desires to purchase an item that he/she sees advertised in a magazine and the item is associated with item number X125Y9 and sold by Amazon.com (User B), in step 1802, User A transmits a message to system 100 "order amazon X125Y9." In step 1804, system 100 then transmits a confirmation message to User A to confirm the purchase. In step 1806, User A receives the confirmation message and, in step 1807, replies with his/her PIN. In step 1808, system 100 transfers the value of the purchase from user account 104 of User A and to user account 114 of User B. In step 1810, system 100 places an order with User B. In step 1812, User B then transmits a tracking number to system 100. In step 1814, system 100 transmits a message to each of User A and User B confirming the order with the tracking number.

[0101] Alternatively, in another exemplary embodiment of a use for system 100, illustrated in the flowchart 1900 of FIG. 19, User A can use system 100 to purchase a song heard on the radio that is associated with a purchase code announced by the disc jockey. For example, in step 1902, if User A desires to purchase a song from iTune (User B in this example), User A may send a message to system 100 to "order itune u2bl0", wherein "u2bl0" is the song code provided by the disc jockey. In step 1904, system 100 then transmits a confirmation message to User A to confirm the purchase. In step 1906, User A receives the confirmation message and, in step 1907, replies with his/her PIN. In step 1908, system 100 transfers the value of the purchase from user account 104 of User A and to user account 114 of User B . In step 1910, User B transmits an Internet link to system 100, which in turn transmits the link to User A in step 1911. In step 1912, User A clicks on the link to download the purchased song.

[0102] In an alternative embodiment of a use for system 100, illustrated in the flowchart 2000 of FIG. 20, system 100 provides a method of loading money into user account 104 of User A if User A does not have an account at a financial institution. In step 2002, User A may contact a participating merchant (User B in this example), such as, for example, a convenience store, to load user account 104 of User A. In step 2004, User B may charge a separate fee for performing this transaction, or may be credited part of the amount that is loaded into user account 104 of User A. Alternatively, in step 2006, system 100 may charge User A and credit User B for User B's participation in the transaction. [0103] To load account 104, in step 2008, User A hands a desired amount of money to User B (in this example, $50) along with User A's system username (<username>), phone number, and/or other identifying information. In step 2010, User B accesses system 100 via a web or mobile interface, and transmits the equivalent of the command "load <username> $50." In step 2012, system 100 adds $50 to user account 104 of User A. In step 2014, User B forwards the $50 to the operator of system 100, along with payments from other users, on a periodic basis.

[0104] Alternatively, the loading process may be performed at an unattended kiosk, wherein, in optional step 2009, User A inserts cash into the kiosk and enters his/her identification information into the kiosk. The kiosk then operates as User B in the example described above.

[0105] In an alternative embodiment of a use for system 100, illustrated in the flowchart 2100 of FIG. 21, system 100 provides a method of providing money to organizations. The organizations may be non-profit, such as, for example, the Red Cross, for-profit, or political organizations. In this example, the organization receiving the money is User B. User B must be a member of system 100 and can advertise in all known advertising media that User A can donate by sending a message equivalent to "donate redcross $X.xx" to make a donation. If there are multiple causes to which User A can donate, in step 2102, User A can specify which cause to direct the donation by adding the cause in the message, such as, for example "donate redcross $X.xx tsunami." Similar to transactions described above, in step 2104, system 100 transmits a message to User A to input his/her PIN. In step 2105, User A transmits his/her PIN to system 100, and in step 2106, system 100 transfers $X.xx from user account 104 of User A to user account 114 of User B. In step 2108, User A may optionally run a transaction history report to determine how much he/she donated to charities and non-profits for tax purposes.

[0106] In an alternative embodiment of a use for system 100, illustrated in the flowchart 2200 of FIG. 22, system 100 provides a method of paying bills. In step 2202, a billing entity, such as, for example, an electric company (in this example, User B), can sign up to system 100 as a payee. In STEP 2203, User A can identify the electric company and account number by using a key word as a nickname, such as, for example, "elec". To pay a bill, in step 2204, User A transmits an equivalent of the message "paybill elec $X.xx", where "$X.xx" is the amount that User A desires to pay on his/her electric bill. In step 2206, system 100 transmits a message to User A to input his/her PIN. In step 2207, User A transmits his/her PIN to system 100, and in step 2208, system 100 transfers $X.xx from user account 104 of User A to user account 114 of User B. In step 2210, User A receives a confirmation message from system 100 that the bill has been paid. The confirmation message may include a confirmation number to which User A can refer to provide evidence of the date and amount of the payment. Used in conjunction with the cash loading feature described above, the bill payment embodiment described herein provides users with a mechanism to pay bills without the need for a bank account at a financial institution.

[0107] In an alternative embodiment of a use for system 100, illustrated in the flowchart 2300 of FIG. 23, system 100 provides a method of transferring money from one individual to another in a third party remittance transaction. Similar to the bill pay feature described above and illustrated in the flowchart of FIG. 22, in step 2302, User A can identify the payee as a nickname, such as, for example, "juan". To transmit money to Juan (User B in this example), in step 2304, User A transmits an equivalent of the message "remit juan $X.xx", where "$X.xx" is the amount that User A desires to remit to User B. In step 2306, system 100 transmits a message to User A to input his/her PIN. In step 2308, User A transmits his/her PIN to system 100. In step 2310, after User A transmits his/her PIN to system 100, system 100 transfers $X.xx from user account 104 of User A to a user account 114 of User B. In step 2312, User A receives a confirmation message from system 100 that that the money has been transferred to User B. The confirmation message may include a confirmation number to which User A can refer to provide evidence of the date and amount of the transfer.

[0108] In another alternative embodiment of a use for system 100, illustrated in the flowchart 2400 of FIG. 24, in the event that the payee has not signed up to use system 100, in step 2402, User A can designate a User B, proximate to the payee, where the payee can go to pick up the money. For example, User B may be a convenience store located near the payee. In step 2404, system 100 transmits a message to User A to input his/her PIN. In step 2406, User A transmits his/her PIN to system 100. In step 2408, after User A transmits his/her PIN to system 100, system 100 transfers $X.xx from user account 104 of User A to a user account 114 of User B. In step 2410, system 100 sends a message to User B that money has been sent to user account 114 of User B for the payee, and in step 2412, provides a confirmation number to User B for the transaction. In step 2414, User A receives a confirmation message with the confirmation number that the money is in user account 114 of User B and, in step 2416, User A can contact the payee with the confirmation number. In step 2418, the payee can then go to the convenience store, provide proof of identity and the confirmation number, and pick up the money.

[0109] In another alternative embodiment of a use for system 100, illustrated in the flowchart 2500 of FIG. 25, a vendor (in this example, User B) may offer a promotion to provide a discount to a consumer (in this example, User A) to purchase User B's goods or services. In step 2502, User B creates the promotion and designates himself as the MERCHANT. While creating the promotion, User B can designate the time duration of the promotion, the value of the promotion, and the number of times that any particular customer can use the promotion. In step 2504, system 100 generates a promotion code for which User B is responsible for disseminating to his customers. Alternatively, system 100 may be directed to disseminate the promotion to all of the users of system 100. In step 2506, when User A makes a purchase, User A presents the promotion code for that particular promotion to User B, who, in step 2508, enters the code into his system interface. In step 2510, system 100 validates the promotion, issues a credit to User A for the amount of the promotion, and withdraws the amount of the promotion from user account 114 of User B. Optionally, in interface 600 (shown in FIG. 6), User B may input promotion information into "PROMO" block 619 in order to track how, when, and by whom the promotion is used.

[0110] Alternatively, when User A is initiating a payment to User B, in step 2512, User A can initiate a text message to pay User B and include the amount of the purchase with the promotion code. An exemplary text may be "pay User B 3.45 -p X12345", where the designation "-p" indicates a promotion and "X12345" indicates the promotion code.

[0111] In another alternative embodiment of a use for system 100, illustrated in the flowchart 2600 of FIG. 26, a promotion may be set up as a donation or a pledge to a charity. In step 2602, User B creates a promotion as discussed above with respect to FIG. 25 and designates a desired charity as the MERCHANT. In step 2604, system 100 generates a promotion code, such as, for example, X67890, which User B disseminates to potential participants, such as, for example, User A. If User A decides to participate in donating to the charity, when User A uses system 100 for a purchase, in step 2606, User A adds the promotion code "-p X67890 $X.xx" to his/her text authorizing the purchase, and in step 2608 the amount $X.xx is transferred from user account 104 of User A to the charity's account.

[0112] In another alternative embodiment of a use for system 100, illustrated in the flowchart 2700 of FIG. 27, system 100 may be used to generate and transmit gift cards. The generation of gift cards is a special type of shared account (See FIG. 12) for which the main user is the merchant for whose store the gift card is valid and the recipient of the gift card only has View and Withdrawal access.

[0113] By way of example only, User B may desire to purchase a gift card for User A for use at a particular merchant. While an actual "card" is not generated, the term "gift card" is being used to designate a gift that one person can give to another for use at a particular merchant.

[0114] In step 2702, User B purchases the gift card from a GUI interface on website 200 (shown in FIG. 2). Alternatively, User B, in step 2704, may generate an exemplary text "gift merchant $X.xx User A". In this example, User B is purchasing a $X.xx gift card for User A to be used at merchant's store (User 142). User A need not necessarily be registered to use system 100 in order to receive the gift card, but User A must register with system 100 before User B can use the gift card.

[0115] In step 2706, when User B purchases the gift card, payment is made from user account 114 of User B to the account of merchant 142 for the amount of the gift. In step 2708, a shared account 142' is generated that is owned by User 142 and to which User A is given View and Withdraw access. The View access allows User A to see all transactions made on shared account 142' as well as available balance in account 142'. The Withdraw access allows payments from account 142' only to the account of User 142. [0116] In step 2710, system 100 generates a gift code that is associated with account 142'. In step 2712, system 100 transmits a message to User A notifying him/her that User B purchased a gift card in the amount of $X.xx to be used at merchant (User 142). The text message also includes the gift code that is to be used to redeem the gift card when User A is making a purchase.

[0117] In step 2714, when User A checks out with his/her purchase, User A provides the gift code to the salesperson, who, in step 2716, validates the gift code to confirm the identity of User A and that the gift card is valid for User 142. In step 2718, system 100 withdraws the value of the transaction from account 142' to the account for User 142.

[0118] Alternatively, in step 2720, User A may initiate a transaction to User 142 by texting an exemplary text, such as, for example "pay User 142 $X.xx -g X13579" where User 142 is the merchant, "$X.xx" is the amount to be used on the gift card, "-g" indicates that a gift card is being redeemed, and "XI 3579" is the gift code.

[0119] If User A is a non-registered user, in step 2722, User B enters User A's mobile number in the text, such as, for example "gift User 142 $X.xx 2155551212." User A then receives a text message letting him/her know that User B has sent him/her a gift card and that User A must register with system 100 to accept the gift card. In step 2724, User A registers with system 100 and, in step 2726, shared account 142' is generated and the amount of $X.xx is transferred from user account 114 of User B to shared account 142 ' .

[0120] In step 2728, if User A does not register with system within a predetermined time (i.e. 14 days), the amount of the gift card is refunded to user account 114 of User B.

[0121] Optionally, when registering with system 100, User A may be required to upload a security image, such as a photo, that may be used to verify the identity of User A when User A uses system 100 to make a purchase at a vendor, such as, for example, User B. Referring again to FIGS. 3 and 6A, as well as to the flowchart 2800 in FIG. 28, when User A inputs his/her personal information into system 100 in block 212, block 212 may include an optional step 2802 to upload a photo from User A's computer 109c (shown in FIG. 1). After User A submits his/her identification information (i.e., mobile phone number) to User B to make a purchase in step 703 (illustrated in FIG. 7) in any in- person transaction involving system 100, in step 2804, system 100 uploads the photo of User A for User B to view in block 614 in FIG. 6. In step 2806, User B compares the photo to User A and in step 2808 confirms that User A is the person in the photo. The confirmation may be the action of hitting a "CONFIRM IDENTITY" button on User B's computer 109d. After User B confirms User A's identity, User B processes the transaction as per step 704 described above with respect to FIG. 7. If User B cannot confirm User A's identity, User B can cancel the transaction as per step 716 described above with respect to FIG. 7.

[0122] In an exemplary embodiment of the use of system 100, if a sale transaction is a face-to-face purchase by a consumer (User A) from a merchant (User B) and User A desires to remain anonymous, in step 2830, User A texts an <anon> command to system 100 and in step 2832, User A receives a unique identification code <zl2345>. In step 2834, User A provides User B with the identification code <zl2345>. In step 2836, User B inputs the identification code <zl2345> into system 100, and system 100 generates User A's photo. The transaction then continues according to step 2806.

[0123] If User A desires to not upload a photo, system 100 provides a warning to User A on User A's computer 109c that system 100 will not be responsible for any loss due to fraud and that system 100 limits the maximum value of money available in user account 104 of User A, such as, for example, $50.00. Further, User B may require the photo identification or be subject to exclusion from any available merchant fraud protection if User B 12 processes a transaction without confirming the identity of User A.

[0124] An additional security feature of system 100 is the ability of User A (or any other user) to "lock" his/her mobile phone 109a to prevent transactions using system 100 from being executed. For example, User A may desire to lock phone 109a while he/she is away on vacation, when he/she lends phone 109a to another person, when he/she is in a potentially hostile environment where there may be a high risk of theft.

[0125] As illustrated in the flowchart 2900 in FIG. 29, to lock phone 109a, in step 2902, User A texts the message "lock" to system 100. To unlock phone 109a, in step 2904, User A must log in to system 100 using personal computer 109c and PIN and transmit an "unlock" message to system 100. In step 2906, when system 100 verifies User A through the proper PIN, system 100 unlocks phone 109a. [0126] In another alternative embodiment of a use for system 100, illustrated in the flowchart 3000 of FIG. 30, system 100 may be used to request money from another party. For example, User A may be a student who is requesting money from User B, who may be User A's parent. In step 3002, User A "pings" User B by transmitting an exemplary message "ping User B $X.xx" to system 100. In step 3004, system 100 transmits a message to User A requesting that User A transmit his/her PIN to authenticate himself/herself to system 100. In step 3006, User A transits his/her PIN to system 100. In step 3008, system 100 requests User B to transmit his/her PIN to system 100 to confirm that he/she agrees to transmit the requested amount of money to User A. In step 3009, User B transits his/her PIN to system 100. In step 3010, system 100 confirms the transaction to each ofUser A and User B. In step 3012, User A logs into system 100 via personal computer 109c and accepts the payment. In step 3014, system 100 transfers the requested amount of money from user account 114 of User B to user account 104 of User A.

[0127] In an alternative embodiment of a use for system 100, illustrated in the flowchart 3100 of FIG. 31 , system 100 may be accessed via a social networking system, such as, for example "Twitter" (http://www.twitter.com). System 100 may be accessed by using Twitter's "direct message" (DM) feature to send and receive private messages. Initially, several conditions must be met before USER A can use Twitter to access system 100. In step 3102, User A opens both a user A account 104 and a Twitter account 104T. System 100 has its own Twitter system account 101 which enables system 100 to communicate with the Twitter system. Still in step 3102, User A adds his/her Twitter credentials with system 100 in block 212, illustrated in FIG. 3.

[0128] In step 3104, to send a payment using Twitter, User A sends a DM to system 100 with a command such as, for example, "xip <XIP ID> <amount>" where "XIP ID" is the recipient's system identification or mobile phone number. If XIP ID is prefixed with "@", then it will be assumed to be the recipient's Twitter ID, in which case the recipient must also have a system account whose Twitter credentials are registered with system 100. Using Twitter's application programming interface (API), system 100 will essentially be logged in to Twitter waiting for direct messages to arrive. In step 3105, when the message arrives, system 100 checks the sender's credentials and tries to match it to any of its registered Twitter users. In step 3106, if no matches are found, an error will be "tweeted" back to the sender (i.e. User A). In step 3108, if a match is found, system 100 runs through its security checks for User A (command access, account access, etc.) and sends a request for User A's PIN. This request can be sent through Twitter or the mobile phone depending on User A's settings. In step 3110, User A replies with his/her PIN (either through Twitter or SMS). In step 3112, system 100 checks the PIN and runs through its normal checks and if everything passes, in step 3114, system 100 transfers the funds to the payee (i.e. User B). In step 3116, User B receives a text message from system 100 notifying him/her of the payment. In step 3118, a confirmation message is sent back to User A (either through Twitter or SMS) notifying him/her of the payment completed successfully.

[0129] While the principles of the invention have been described above in connection with preferred embodiments, it is to be clearly understood that this description is made only by way of example and not as a limitation of the scope of the invention.

Claims

CLAIMS:

1. A method of executing a financial transaction between a first financial account held by a first financial institution and a second financial account held by a second financial institution via a payment service, the method comprising:

(a) withdrawing a transaction amount from the first financial account;

(b) depositing the transaction amount in a first system account maintained by the payment service and held by a first financial institution;

(c) withdrawing the transaction amount from a second system account maintained by the payment service and held by the second financial institution;

(d) depositing the transaction amount into the second financial account; and

(e) reconciling the first and second system accounts after step (d) has been performed.

2. The method of claim 1, wherein step (e) comprises reconciling the first and second system accounts based on all transactions executed via the payment service and between accounts held by the first financial institution and accounts held by the second financial institution since the last time step (e) was performed.

3. A method for performing cashless financial transactions comprising the steps of:

(a) receiving a payment request to a processor from a first user;

(b) transmitting a confirmation request from the processor to a second user;

(c) receiving a confirmation to the processor from the second user;

(d) transferring funds from the second user to the first user via the processor; and

(e) transmitting an electronic message to the first user and the second user that the funds transfer has been completed.

4. The method according to claim 3, wherein step (a) is performed wirelessly.

5. The method according to claim 3, wherein step (d) comprises transferring the funds to an escrow account prior to transferring the funds to the first user.

6. The method according to claim 3, wherein step (b) further comprises the processor transmitting an image of the second user to the first user.

7. The method according to claim 3, wherein step (d) comprises the step of electronically directing the funds into a third party account.

8. The method according to claim 6, further comprising the step of:

(f) transmitting a message from the processor to a third user informing the third user that the funds are available for the third user in the third party account.

9. The method according to claim 3 , further comprising the processor preventing the first user from transferring funds to another user.

10. A method for performing cashless financial transactions comprising the steps of:

(a) receiving a payment request to a processor from a first user to pay a value of a bill generated by a second user;

(b) transmitting a message from the processor to the first user to input an identification code;

(c) confirming the identification code and electronically transferring the value from the first user to the second user; and

(d) transmitting an electronic message to the first user and the second user that the funds transfer has been completed.

11. The method according to claim 9, wherein step a) further comprises the first user transmitting a key word to the processor to identify the second user.

12. The method according to claim 9, further comprising, prior to step a), the step of the processor transmitting a message to the first user to pay the bill.

13. A method for executing a financial transaction between first and second users of a payment system, comprising the steps of:

(a) providing a first temporary identification code to the first user in response to a request for the temporary identification code generated from a mobile device;

(b) linking the first temporary identification code with a user account associated with the first user; and

(c) executing a financial transaction in response to a transaction request initiated by a second user, the transaction request including the first temporary identification code.

14. The method according to claim 13, further comprising:

(d) transmitting a photograph of the first user to the second user; (e) proceeding with step (c) only if, after step (d) has been performed, the second user transmits a message authorizing execution of the transaction.

15. A method of executing financial transactions via a payment system:

(a) receiving an SMS message from a mobile phone containing instructions to process a financial transaction involving a first user wallet;

(b) sending an SMS message to the mobile phone containing instructions to confirm the financial transaction;

(c) executing the financial transaction only if a second SMS message containing a correct PIN for the first user wallet is received from the mobile phone.

16. The method of claim 15, wherein step (c) comprises executing the financial transaction only if a second SMS message containing a correct PIN for the first user wallet is received from the mobile phone within a predetermined period of time.