Abstract:
The present invention provides a method and system for pooling commitments. The commitments may be made by different persons from different locations at different times. The commitments are pooled and used to fund a transaction.

Description:
CLAIM OF PRIORITY 
       [0001]    This patent application claims the benefit of the filing date of U.S. Provisional Application Ser. No. 60/918,682 filed on Mar. 19, 2007. 
     
    
     FIELD OF THE INVENTION 
       [0002]    This invention relates generally to a system and apparatus for funding a transaction, and specifically to a system and apparatus for funding a transaction by a plurality of purchasers. 
       DESCRIPTION OF THE RELATED ART 
       [0003]    Benefactors often look to give a product or service as a gift for a third party. These individuals often find the gift that they are looking for on traditional ecommerce sites such as amazon.com or borders.com. Oftentimes, however, a benefactor does not have sufficient funds to purchase the desired gift. 
         [0004]    If a benefactor does not have sufficient funds, he can purchase a less expensive gift on the traditional ecommerce sites, but this option disappoints the purchaser, and may disappoint the recipient who may have been expecting the more expensive gift. 
         [0005]    The benefactor can also pool funds (which may or may not include the benefactor&#39;s own funds) with other purchasers to deliver the desired gift. The benefactor can pool in two ways. 
         [0006]    In the first type of pooling the benefactor collects funds from purchasers into his own account (which account may be in a bank, in the benefactor&#39;s pocket or elsewhere), and then uses that account in one way or another to purchase the desired gift. The traditional ecommerce sites provide no tools to facilitate this type of pooling. 
         [0007]    In the second type of pooling the benefactor collects commitments from purchasers, usually in the form of a credit card or debit card, and then uses those commitments to purchase the desired gift. Although traditional ecommerce sites provide tools to support this type of pooling, those tools have several limitations. First, as shown in  FIG. 1 , all commitments must be made at the same time because all commitments must be made submitted simultaneously. Second, as shown in  FIG. 2 , all commitments must be made at the same place because all commitments must be submitted from the same computer. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0008]    These and other features, aspects and advantages of the present invention will become better understood by referring to the following description, the appended claims, and accompanying drawings, where: 
           [0009]      FIG. 1  depicts traditional pooling where commitments are collected at the same time. 
           [0010]      FIG. 2  depicts traditional pooling where commitments are collected at the same time. 
           [0011]      FIG. 3  depicts a client connecting to a server across a network such as the internet. 
           [0012]      FIG. 4  depicts several clients connecting to a server from different locations and at different times. 
           [0013]      FIG. 5  depicts a pooling and transaction manager. 
           [0014]      FIG. 6  depicts a pooling and transaction manager. 
           [0015]      FIG. 7   a  depicts an execution component of a pooling and transaction manager. 
           [0016]      FIG. 7   b  depicts an execution component of a pooling and transaction manager. 
           [0017]      FIG. 8  is an example of an architecture diagram of a client, a server including a web server and a server side processor and a pooling and transaction manager. 
       
    
    
     SUMMARY OF THE INVENTION 
       [0018]    The object of this invention is to provide a method and system for pooling commitments without time and space limitations. 
       DETAILED DESCRIPTION OF THE INVENTION 
       [0019]    Using a client, a purchaser connects to a server across a network such as the internet as depicted in the physical architecture diagram of  FIG. 3 . The server may have components such as: (i) a web server to receive commitments and (ii) a server side processor to generate status and other information for transmission to a purchaser. It will also be appreciated by those skilled in the art that distinct physical architectures may be used. For example, the web server and the server side processor may be housed on the same machine, different machines, or partially on the same machine and partially on different machines. It will be appreciated by those skilled in the art that a plurality purchasers may connect to the server from different locations and at different times as depicted in  FIG. 4 . 
         [0020]      FIG. 5  depicts a pooling and transaction manager. The commitments are received from a web server and stored in memory by the pooling and transaction manager. It will be appreciated by those skilled in the art that a purchaser or benefactor may make multiple commitments in equal or unequal amounts. It will also be appreciated by those skilled in the art that different purchasers or benefactors may make commitments in equal or unequal amounts. The pooling and transaction manager also receives transaction information, which may include data such as gift identity and price, minimum commitment amount, and settings such as whether the commitments may be revocable or irrevocable. It will be appreciated by those skilled in the art that a gift may take many forms, such as tangible or intangible. 
         [0021]      FIG. 6  depicts components which may be included in the pooling and transaction manager. A commitment receiving component receives commitments. A management component receives transaction information. A database stores (i) the commitments and associated information such as credit card number, commitment amount and other relevant information and (ii) the transaction information. An execution component which, based on settings, individual commitments, aggregate commitments, and other information, issues an execution request to a credit card component. 
         [0022]    It will be appreciated by those skilled in the art that the pooling and transaction manager may include additional components. 
         [0023]    For example, an additional component in the pooling and transaction manager might be a gift selection receiving component. Such a component would receive gift selection information, and would be used for a gift recipient to select a gift when the transaction information includes more than one gift to which benefactors may make funding commitments. It will be appreciated by those skilled in the art that said gift selection information may also be received by the same management component used to receive transaction information, by the execution component, or by another component. It will be further appreciated by those skilled in the art that said gift selection information may or may not be stored in the database. 
         [0024]    As another example, an additional component in the pooling and transaction might be a termination request receiving component. Such a component would receive termination request information, and would be used to force the execution component to issue an execution request at a time different than it otherwise would have. It will be appreciated by those skilled in the art that said termination request information may also be received by the same management component used to receive transaction information, by the execution component, or by another component. It will be further appreciated by those skilled in the art that said termination request information may or may not be stored in the database. 
         [0025]      FIG. 7  depicts some factors which may determine when an execution request is issued as well as the contents of exemplary execution requests. Based on settings and rules, the execution component can issue an execution request on the happening of a variety of events, including but not limited to: (i) whenever a commitment is made, (ii) whenever the aggregate of commitments reaches a certain amount, (iii) at a certain time, (iv) or the happening of any combination of these or other events. Based on settings and rules, an execution request may include one request or a variety of requests, such requests including but not limited to: (i) a request to charge the credit cards of all purchasers in the full amount of the commitment made by each such purchaser; (ii) a request to charge the credit cards of only some of the purchasers; or (iii) a request to charge the credit cards of some or all purchasers in an amount less than the commitment made by each such purchaser. 
         [0026]      FIG. 8  is an example of an architecture diagram of a client, a server including a web server and a server side processor and a pooling and transaction manager.