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.
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.
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.
The benefactor can also pool funds (which may or may not include the benefactor's own funds) with other purchasers to deliver the desired gift. The benefactor can pool in two ways.
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'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.
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
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:
a depicts an execution component of a pooling and transaction manager.
b depicts an execution component of a pooling and transaction manager.
The object of this invention is to provide a method and system for pooling commitments without time and space limitations.
Using a client, a purchaser connects to a server across a network such as the internet as depicted in the physical architecture diagram of
It will be appreciated by those skilled in the art that the pooling and transaction manager may include additional components.
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.
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.
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.
| Number | Date | Country | |
|---|---|---|---|
| 60918682 | Mar 2007 | US |