Abstract:
The present invention is a control system and set of methods for providing and controlling a money payment transaction through a network. The methods comprise determining the values of several variables which influence the fee charged for the transaction by choices from an array of selections, and then charging a predetermined fee for the transaction based on the determined values of the selected variables. Alternatively, the methods comprise selecting a fee, and determining the allowable timing parameters for such a fee. Guarantees for settlement of the transaction within certain timing constraints are also provided. The benefits of this system and methods are that Users, instead of financial intermediaries such as banks or other transaction processors, can explicitly control the timing of a money payment transaction.

Description:
FIELD OF THE INVENTION  
       [0001]     The field of the invention is the payments business, also known as the money transfer business, wherein money belonging to one party is transferred or paid to another party.  
       BACKGROUND OF THE INVENTION  
       [0002]     Individuals or business entities commonly maintain bank accounts and other funds storage accounts in banks and other financial institutions. Control of these accounts, and the instructions for crediting or debiting funds is commonly achieved through a wide variety of interfaces, including teller operations, Automated Teller Machines (ATMs), and online interfaces such as through Web sites. Transfer of money from one account to another typically occurs by means of one party (the payor) instructing his financial institution to pay or transfer funds to another party (the payee) or to the payee&#39;s account. Such instructions may be by means of paper instruments, such as checks (demand notes), or through various electronic means. Depending on many factors, the availability of funds for the discretionary use of the payee may be immediate, but is commonly delayed some varying time (the “float time”, or “float”). This delay is a consequence of a variety of factors, including processing delays, and credit risk.  
         [0003]     The most important cause of payment delay is the credit risk associated with the payor&#39;s available cash balance at the time the payment is settled at the payee&#39;s bank. The problem is rooted in traditional payment processing methods used by banks, wherein many transactions involving many unrelated parties are batched together and settled as a group, all on a daily schedule, typically overnight. A payment initiated by a payor, for which sufficient funds are available at the time of initiation, may or may not have sufficient funds available for payment at the time of settlement. Thus additional checks and balances are required to verify the payor&#39;s funds. These processes introduce delays into the settlement of each individual payment, and historically led to the rise of long float times.  
         [0004]     Complete settlement of an individual transaction is relatively inefficient from an operational standpoint, hence expensive. Until recently, in most banking systems, immediate settlement of common transactions has not been commercially feasible. Thus the first motivation for use of float is to ensure that funds are really available for transfer at the time of settlement, and that all supporting documentation is available and correct, and located in the right place. Providing funds to a payee before actual settlement can lead to losses to the issuing bank.  
         [0005]     Financial institutions have a second motivation for use of float, however: profit from early clearing of funds. As electronic means of transferring funds and providing settlement services have evolved, they have enabled financial institutions to settle transactions faster than before, and withhold cleared (settled) funds from payees for some part of the administratively declared float time. During the time that funds have already been cleared, but have not yet been payed out to the payee, the financial institution can obtain interest on the funds by lending them out to other financial institutions. So-called overnight lending and other lending practices between financial institutions enables them to derive significant profits from delayed release of funds to payees.  
         [0006]     Specialized systems have been designed to provide faster clearing of transactions, such as private networks, like the one used by Western Union. Users typically pay fees on the order of ten to twenty-five percent surcharge to achieve rapid clearing, within a single financial institution.  
         [0007]     The development of Automated Clearing House (ACH) operations provided faster clearing of transactions through electronic means, as well as providing additional conveniences for the US government and other entities. ACH is used in so-called “direct deposit” payments, for payroll operations and other automated payment operations. The ACH system enables financial institutions to clear funds much faster and with much greater control than previously possible. But financial institutions have been slow to transfer the benefits of such systems to commercial or individual end users of such systems (payors and payees). As of year 2005, the development and implementation of software to handle fast or immediate clearing of funds in general commercial banking operations is underway, but it is being developed slowly. Within a few years, at most, financial institutions will be able to clear and settle most funds on a per-transaction basis at very low cost.  
         [0008]     Electronic funds transfer networks (EFTs) are already in use in the U.S. and world-wide to move money and make payments very quickly. Some of these networks are able to move the electronic representation of a transaction on a near-real-time or real-time basis (essentially immediately). The application of the use of these payment networks for the direct use and benefit of individuals and businesses is now beginning to be effected.  
         [0009]     So in principle, for most end-users, funds transfers are either slow, or expensive. Either way, the float used by the financial institutions is not within the control of either the payor or the payee, except in a very crude way.  
       SUMMARY OF THE INVENTION  
       [0010]     The present invention is a control system and set of methods for providing and controlling a money payment transaction through a network. The methods comprise determining the values of several variables which influence the fee charged for the transaction by choices from an array of selections, and then charging a predetermined fee for the transaction based on the determined values of the selected variables. Alternatively, the methods comprise selecting a fee, and determining the allowable timing parameters for such a fee. Guarantees for settlement of the transaction within certain timing constraints are also provided.  
         [0011]     The benefits of this system and methods are that Users, instead of financial intermediaries such as banks or other transaction processors, can explicitly control the timing of a money payment transaction. 
     
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0000]     Key of Numerals for the Figures  
         [0012]      201 : Contextual background of the user interface page  
         [0013]      203 : Buttons, clickable regions, or slider controls  
         [0014]      205 : Data entry areas  
         [0015]      207 : Calculated fields and replies to user entry  
         [0016]      FIG. 1 —Transaction Sequence  
         [0017]     Transaction sequence logic flow given from the viewpoints of the Payor and Payee.  
         [0018]      FIG. 2 —Transaction Interface Screen (Payor&#39;s Input Page)  
         [0019]     Settlement time selected, fee-returned logic.  
         [0020]      FIG. 3 —Transaction Interface Screen (Payor&#39;s Input Page)  
         [0021]     A variant of the format of  FIG. 2 , settlement time selected, fee-returned logic.  
         [0022]      FIG. 4 —Transaction Interface Screen (Payor&#39;s Input Page)  
         [0023]     Another variant of the format of  FIG. 2 , settlement time selected, fee-returned logic.  
         [0024]      FIG. 5 —Transaction Interface Screen (Payor&#39;s Input Page)  
         [0025]     Fee selected, settlement time returned logic.  
         [0026]      FIG. 6 —Transaction Interface Screen (Payor&#39;s Input Page)  
         [0027]     Settlement time subject to a guarantee selected, fee returned with guarantee logic.  
         [0028]      FIG. 7 —Transaction Interface Screen (Payor&#39;s Input Page)  
         [0029]     Settlement time selected subject to a probabilistic guarantee, fee returned with probabilistic guarantee logic.  
     
    
     DETAILED DESCRIPTION OF THE INVENTION  
       [0030]     The following description is presented to enable one of ordinary skill in the art to make and use the invention and is provided in the context of a patent application and its requirements. Various modifications to the preferred embodiment and the generic principles and features described herein will be readily apparent to those skilled in the art. Thus, the present invention is not intended to be limited to the embodiments shown but is to be accorded the widest scope consistent with the principles and features described herein.  
         [0031]     Process Logic of the System  
         [0032]     There are four principal parties to a money transfer: They are:  
         [0033]     1) Payor;  
         [0034]     2) Payor&#39;s financial institution (Payor&#39;s Bank), which holds Payor&#39;s money;  
         [0035]     3) Payee&#39;s financial institution (Payee&#39;s Bank), which can hold Payee&#39;s money; and  
         [0036]     4) Payee.  
         [0037]     In some implementations, parties 2) and 3) may be the same entity.  
         [0038]     There is also a broad spectrum of roles typically played by software in the modern banking system. We will here define one additional specific role that may be handled by the Payor&#39;s Bank, or the Payee&#39;s Bank, or broken out and controlled by a fifth entity. The role is that of the Transaction Processor. For convenience of description only, we will call the fifth entity itself the Transaction Processor, and consider it separate and distinct from the others.  
         [0039]     Outside the context of this invention, in a typical money transfer, Payor instructs Payor&#39;s Bank to transfer Payor&#39;s money held in Payor&#39;s account to Payee&#39;s Bank. Payor&#39;s Bank verifies availability of funds, and then transfers money to Payee&#39;s account in Payee&#39;s Bank. Payee&#39;s Bank makes these funds available to Payee, typically after some delay (float). Alternatively, such as in the process used by Western Union, Payor gives money (typically cash) to the Transaction Processor directly, which then makes an accounting entry in its private network, after which the Payee can withdraw the finds in another operating location of the Transaction Processor, and the Transaction Processor makes the corrsponding accounting entry noting the payment on its system.  
         [0040]     This invention modifies this process in several significant respects, by adding several steps, which efectively transfer control of the timing of the transaction to the Users (Payor or Payee, or both). Refer to the numbered Steps (e.g. “101”) in  FIG. 1 . The interface through which the display appears can be any machine diplay system, such as a computer screen, cell phone display, or other electronic display. Alternatively, the Users can operate the system remotely by means of a telephone discussion with a live person representing the user interface, or by means of a telephone discussion or telephone keypad input to a voice-recognition or machine reading system. In such latter cases, the Pages represented in the Figures are meant to describe the data capture mechanism of the system.  
         [0041]     1) Through the Payor&#39;s Input Page ( 101 ), the Payor proposes a money transfer, with specific transaction timing (float) criteria and/or guarantee criteria. The details of the selection choices of these criteria constitute key features of this system, as considered in greater detail below.  
         [0042]     2) By clicking “Next” ( 103 ) the proposed transaction is sent to the Transaction Processor, which assesses it against available float parameters (such as may be contained in an internal database), or sends it to Payor&#39;s and Payee&#39;s banks for confirmation, and sends the proposed transaction to the Payor&#39;s bank for verification of funds, (collectively  105 ).  
         [0043]     3) Upon completion of the assessment of the transaction by the Transaction Processor and/or the corresponding banks, a confirmation (or denial) of the transaction is sent to the Payor ( 107 ). If the transaction cannot proceed as originally requested by the Payor, but a similar transaction with modifications could in fact proceed, a proposal for such a modified transaction candidate may be sent back for consideration by the Payor, ( 109 ).  
         [0044]     4) The Payor may edit ( 111 ) the proposed transaction and resubmit it ( 103 ).  
         [0045]     5) Upon confirmation of the proposed transaction, either in its original form or in the modified form, by clicking “Next” ( 113 ) the Payor submits the transaction to the Transaction Processor for processing.  
         [0046]     6) The Transaction Processor in turn submits the transaction to the corresponding banks and transaction processing intermediaries for processing ( 115 ).  
         [0047]     7) Upon receipt of the submittal ( 117 ), the Payor and/or the Payee is/are sent a confirmation of the submittal ( 119 ,  121 ), and the transaction is considered to be in a pending status.  
         [0048]     8) The transaction is made between the Payor&#39;s Bank and the Payee&#39;s Bank through available banking processes, optionally including classical mechanisms, ACH transfer mechanisms, EFT mechanisms, etc., ( 123 ). The Transaction Processor selects the process most suitable for the timing requirements of the proposed transaction.  
         [0049]     8) Upon settlement, the Payee&#39;s Bank notifies the Transaction Processor of settlement and availability of funds to the Payee ( 125 ).  
         [0050]     9) The Transaction Processor in turn notifies the Payor and/or the Payee of the settlement of the transaction ( 127 , 129 ).  
         [0051]     10) The Payee may leave the funds in his bank account or collect the funds in hand through any usual means, such as through bank teller operations, or through an Automatic Teller Machine (ATM).  
         [0052]     Input Process Logic  
         [0053]      FIGS. 2 through 7  illustrate various user interfaces, which embody various methods of determining the values of input parameters, and resulting transaction processing conditions and fees.  
         [0054]      FIG. 2  illustrates the business process control logic in which the User selects ( 203 ,  205 ) either how soon the transaction must be completed (in elapsed time), or when the transaction must be completed (in calendar time), and the system returns ( 207 ) the amount of the fee. Selection is by filling values into input boxes ( 203 ,  205 ).  
         [0055]      FIG. 3  illustrates a variation of the interface shown in  FIG. 2 . User selects ( 203 ,  205 ) either how soon the transaction must be completed (in elapsed time), or when the transaction must be completed (in calendar time), and the system returns ( 207 ) the amount of the fee. Selection of transaction amount is by filling value into input box ( 205 ); time selection is by means of a slider bar ( 203 ) which depicts a transaction occurring sooner or later, with the system returning the speed of the transaction as text ( 207 ); or selection is by means of drop-down selection values specifying when the transaction must be completed in calendar time ( 203 ). The system reports ( 207 ) the fee for this transaction.  
         [0056]      FIG. 4  illustrates another variation of the interface shown in  FIG. 2 . User selects ( 203 ,  205 ) either how fast the transaction must be completed (in elapsed time), or when the transaction must be completed (in calendar time), and the system returns ( 207 ) the amount of the fee. Selection of transaction amount is by filling value into input box ( 205 ); time selection is by means of a slider bar ( 203 ) which depicts a transaction occurring faster or slower, with the system returning the speed of the transaction as text ( 207 ); or selection is by means of drop-down selection values ( 203 ) specifying when the transaction must be completed in calendar time. The system reports ( 207 ) the fee for this transaction.  
         [0057]      FIG. 5  illustrates an interface where the User selects ( 203 ,  205 ) an acceptable fee for the transaction, expressed as a percentage of the transaction amount. The system returns ( 207 ) fee amount expressed in dollars, as well as the time for the transaction, expressed as how soon the transaction can be completed (in elapsed time), and when the transaction can be completed (in calendar time). Selection of transaction amount is by filling value into input box ( 205 ); fee selection is by means of a drop-down box ( 203 ) containing selection values specifying possible fees.  
         [0058]      FIG. 6  illustrates an interface wherein the User selects ( 203 ,  205 ) either how soon the transaction must be completed (in elapsed time), or when the transaction must be completed (in calendar time), and the system returns ( 207 ) the amount of the fee. Selection of transaction amount is by filling value into input box ( 205 ); time selection is by means of a slider bar ( 203 ) which depicts a transaction occurring faster or slower, with the system returning ( 207 ) the speed of the transaction as text; or selection is by means of drop-down selection values ( 203 ) specifying when the transaction must be completed in calendar time. The system reports ( 207 ) the fee for this transaction. The user may select to receive a time-of-completion (settlement) guarantee for an additional fee, by marking a check box ( 203 ). The system returns ( 207 ) the fee for the guarantee.  
         [0059]      FIG. 7  illustrates an interface wherein the use of probabilistic estimates of the likelihood of settlement of the transaction, and corresponding guarantees are controlled.  
         [0060]     This is a variation of the format shown in  FIG. 6 . User selects ( 203 ,  205 ) either how soon the transaction must be completed (in elapsed time), or when the transaction must be completed (in calendar time), and the system returns ( 207 ) the amount of the fee. Selection of transaction amount is by filling value into input box ( 205 ); time selection is by means of a slider bar ( 203 ) which depicts a transaction occurring faster or slower, with the system returning ( 207 ) the speed of the transaction as text; or selection is by means of drop-down selection values ( 203 ) specifying when the transaction must be completed in calendar time. The system reports ( 207 ) the fee for this transaction. The user may select to receive a probabilistic time-of-completion (settlement) guarantee for an additional fee, by setting a slider bar ( 203 ) to request a level of certainty for the transaction within the required time. The system returns ( 207 ) the fee for the probabilistic guarantee.  
         [0061]     Required Additional Components  
         [0062]     Additional components are required for the functional completion of complete money transfer (transaction) processing system. The system which is described herein is intended to operate as a subsystem of complete money transfer (transaction) processing system. Accordingly, this invention does not address these additional components. It refers to these additional processing components only from the viewpoint of passing data out of and into the process components that are material to the invention itself. Thus, for example, the mechanisms whereby banks move funds, clear funds and verify settlement, etc., are not addressed.  
         [0063]     The user interfaces through which the Payor (and/or the Payee) conduct(s) the transaction are directly material to, and are components of, this system. However, additional supporting components are required in this context as well, but these supporting components, considered individually, are not unique to this invention. The combination of the primary components with these supporting components is unique to this invention. The supporting components required, for example, in a Payor&#39;s Input Page may include Payor&#39;s Name, Name of Payor&#39;s Bank (or other financial institution), Routing Number of Payor&#39;s financial institution, Payor&#39;s Account Number, Payee&#39;s Name, Name of Payee&#39;s Bank (or other financial institution), Routing Number for Payee&#39;s financial institution, Payee&#39;s Account Number, a unique Transaction Number, a Transaction Date and Time Stamp, and a digital signature of the Payor.  
         [0064]     For convenience of description of the primary components of the invention, these supporting components are omitted, but are understood to be required for the complete transaction processing system to function properly.  
         [0000]     Example Embodiment of the Invention #1  
         [0065]     In this embodiment, the Transaction Processor is an independent entity as described above. Thus the primary entities are the Payor, the Payee, the Payor&#39;s Bank, the Payee&#39;s Bank, and the Transaction Processor.  
         [0066]     The Transaction Processor is comprised of three key elements:  
         [0067]     a) A web site, by means of which Payor and Payee have access to the transaction process;  
         [0068]     b) Processing software, by means of which transaction requests are processed, and queries and replies are sent from Payor and/or Payee to Payor&#39;s Bank and/or Payee&#39;s Bank from Payor&#39;s Bank and/or Payee&#39;s Bank to Payor and/or Payee, and/or Transaction Processor.  
         [0069]     c) An internal database that holds business processing rules, float capabilities of correspondent financial institutions, and transaction records.  
         [0070]     The Payor may “go to” the Transaction Processor&#39;s web site (actually, obtain an Input Page from the web server), and interact with the Transaction Processor through the Input Page.  
         [0071]     The Transaction Processor services the input from the Payor and/or Payee, and sends replies back to the Payor and/or Payee through the same means.  
         [0072]     The Input Page(s) is/are in accordance with one or more of the variations described in  FIGS. 2 through 7 .  
         [0000]     Example Embodiment of the Invention #2  
         [0073]     This implementation is like Implementation #1, except that the Transaction Processor is one of either the Payor&#39;s financial institution (typically a bank) or the Payee&#39;s financial institution (also typically a bank). In its role as Transaction Processor, the financial institution maintains the business processing logic and related database as described above internally, or may outsource these services, obtaining some or all of the services from another entity.  
         [0074]     The transaction Input Page and other Pages are accessible to the Payor and/or Payee through the financial institution&#39;s own web site. The features of the transaction process may be explicitly provided as shown in  FIGS. 2 through 7 , or may be adapted and integrated into the bank&#39;s own interface, while providing the business process logic as described above.  
         [0075]     The web interface may be accessible through a computer, or mobile device such as a Personal Digital Assistant (PDA), or hybrid PDA/cell phone.  
         [0000]     Example Embodiment of the Invention #3  
         [0076]     This implementation is like Implementation #2, except that the Input Page interface is designed to be accessible through an Automatic Teller Machine.  
         [0000]     Example Embodiment of the Invention #4  
         [0077]     This implementation is like Implementation #1 or #2, except that the Input Page interface is not visible to the Users, but rather the input data is entered on a telephone keypad or other typed-input keypad, in response to audio instructions provided through a telephone. These instructions can be through a simple recorded-response audio system (uni-directional), or through a bi-directional voice-response system, or by means of a telephone conversation with a live individual person who is entering the data into the system on behalf of a User.  
         [0078]     Although the present invention has been described in accordance with the embodiments shown, one of ordinary skill in the art will readily recognize that there could be variations to the embodiments and those variations would be within the spirit and scope of the present invention. Accordingly, many modifications may be made by one of ordinary skill in the art without departing from the spirit and scope of the appended claims.