Asset Transaction Control System

SUMMARY OF THE INVENTION

[0001 ] The present invention is a method and system for controlling a transfer or delivery of an asset or information between two parties or entities. A transaction control system maintains data defining transaction assets and transaction parties. Transactions between parties are enabled by delivering a transaction code to a second party who seeks possession of an asset from a first party. Delivery to the first party, from the second party, of the transaction code is verified by the control system and the control system stores data evidencing the associated asset delivery. In the context of the inventive system, the asset susceptible to transfer or delivery may be a physical object, an intangible asset, information, data, evidence of an obligation or right to future performance, or other value or legal right.

DESCRIPTION OF THE DRAWINGS

[0002] Figures 1 to 5 are schematic illustrations of steps in one embodiment of the inventive system and method.

DETAILS OF EMBODIMENTS OF THE INVENTION

[0003] Figure 1 illustrates a system and method according to the invention. In the transaction illustrated there are two transaction parties P1 and P2, however the current methods are not so limited and the inventive method may be applied in like manner to transactions involving multiple simultaneous or sequential related or unrelated parties. The term "party" is used generically here to refer to a person or a legal entity including a person or equally an electronic device capable of carrying out the required transaction events.

[0004] The transaction is enabled by a control system 101 . The control system 101 includes electronic memory systems and communication systems enabling the following communications and actions. The control system 101 maybe embodied in one or more computers or computer controlled communication systems of devices, such as a mobile telephone device. The control system 101 should include a generally accessible communication system, or be connectable to the same, such as an internet based system or a cellular phone software application communication system.

[0005] In the following, the term "asset" is used to indicate a physical object, an intangible asset, information, data, evidence of an obligation or right to future performance, or other value or legal right. In use, an asset is something that one parties wishes to exchange to another.

[0006] In methods according to the invention, a first party P1 has an asset AS1 that P1 desires or requires to delivery to another party. The other party may be unknown or unidentified at an initial transaction time or may be known.

[0007] In Figure 1 , in a first step of the inventive method the first party P1 communicates with the control system 101 to provide transaction data TDA, which may include asset description data and exchange value data such as a monetary price.

[0008] In a second step illustrated in Figure 2, the control system 101 communicates to a second party P2 to provide to P2 at least sufficient transaction data TDA' to enable the transaction. This should include asset description and prices information. Other information may also be transmitted such as incidental transaction information such as a physical transaction location or other party identifying information. In this step (or in a separate event) P2 transmits to the control system 101 information or data enabling payment or other value exchange. This may include account information respecting the second party's financial accounts with third-party financial parties.

[0009] In a third step illustrated in Figure 3, which encompasses the physical transaction or exchange between the parties, the second party P2 transmits or communicates to the first party P1 , a receipt code RC or equally effective signal or evidence of completion of the exchange. This receipt code RC may have been previously provided to the second party P2 from the control system, as part of the transaction data transfer TDA', or may have been otherwise previously provided, or may be provided at the time of exchange - during the third step events. While the control system 101 may function as part of the exchange between the parties, this might also not be the case, and the exchange itself occurs independent of the control system 101 (hence the dashed communication lines to the control system 101 in this figure). The function of the receipt code RC is to provide the first party P1 with evidence of completion of the exchange and evidence that the second party P2 is in possession of the asset AS1 . This transmission or communication of the receipt code RC should occur slightly before, concurrent with, or right after exchange of AS1 , based on which party more needs to verify the performance of the other in a transaction prior to the code being exchanged. In general, the trusted party will perform last in the transaction between P1 and P2. The control system 101 can specify which party is the trusted party in a transaction pair and suggest or control when the receipt code RC is provided for P1 .

[0010] In the case of a physical asset, such as paper currency money, the exchange is a physical movement of the asset. However, in the case of intangible asset or information, the exchange may take many other forms including revealing through spoken word or visible exchange. The transmission or communication of the receipt code RC to the first party P1 evidences that the second party P2 is in satisfactory possession of the asset AS1 (ie. paper currency money, information, etc.).

[001 1 ] The receipt code RC may take any of a great variety of forms including alphanumeric, numeric, alphabetical electronic or visual signals, audio signals, video signals or combinations or hybrids of these or any other

communicable signal receivable through electronic means. The nature of the signal may be adjustable to the nature of the communication means and devices used by the parties. Preferably, the receipt code RC is unique as to the parties and the exchange or asset AS1 and may include specific data defining the parties and asset and other information specific to the exchange. Alternatively, the receipt code RC may be uniquely associated with such data stored within the control system 101 .

[0012] In a fourth step illustrated in Figure 4, the first party P1 transmits the receipt code RC to the control system 101 . Where a payment exchange is part of the transaction, receipt of the receipt RC by the control system 101 enables or authorizes the control system 101 to then transfer payment to the first party P1 and charge or debit the second party P2 as previously specified. Payment to the first party P1 may be via an electronic payment communication PX1 to the first party P1 or to a third-party manager of an account of the first party P1 . Payment from the second party P2 likewise may be through payment communication PX2 with the second party or a third-party. Alternatively, the control system 101 may function as an account manager for one or both of the parties, debiting and crediting accounts for each with respective to associated exchanges completed and thus the payment communications PX1 , PX2 would not occur external to the control system 101 . It should be clear that the events of the fourth step may be coincidental in time with the exchange events of the third step.

[0013] At the completion of the third step, the asset AS1 is in the possession of the second party P2 and data respecting this fact may be maintained as data within the control system 101 as a consequence of communication of the receipt code RC from the first party P1 to the control system 101 .

[0014] Alternatively, the exchange value received by the first party P1 may be other than monetary value (fiat money or account credit in monetary

denomination). Particularly where multiple parties are anticipated with multiple transactions with various different parties, both as "buyer" and "seller", a system of account credits 120 (Figure 5) may be a maintained element of the control system 101 . In this way, the exchange value transferred from the second party P2 (buyer) to the first party P1 (seller) may be an exchange value EX that is recorded entirely within the control system 101 . This exchange value EX may have denomination in recognized monetary units or may be unique.

[0015] Where the current system is used for exchanges involving multiple different classes of assets (money, objects, information, obligations) the control system 101 may maintain an exchange value registry containing specific asset identities and corresponding relative asset values respective of other assets. An exchange value EX in any particular transaction may take the form of a relative asset value RAV (in place of fiat money denomination amount).

[0016] The following is provided as one example of use of relative asset values RAV within the present method. A history of transactions between incidental prior parties may identify an accepted or average RAV representing one bicycle in exchange for four hours of manual labor. Similarly, other histories of transactions may identify an accepted RAV of a sports football for two hours of manual labor (embodied as a contractual right of satisfaction of obligation of performance as an asset). Using relative evaluation of these transactions and values, a RAV of two footballs for a bicycle may be arrived at. Using this, in a particular future subject transaction, a first party may have possession of a bicycle which a second party desires. The second party may authorize transfer of right of ownership of either four hours of manual labor or two footballs in exchange for possession of the bicycle. The exchange of possession for right of ownership may be carried out as previously described above. The ownership credit of four hours of manual labor or right of ownership for two footballs is recorded as an exchange value EX in the system of account credits 120. This mode of transaction may be considered a barter transaction as not necessarily requiring a monetary payment, but rather is an exchange of different forms of assets.

[0017] In one embodiment of the current invention, the control system 101 creates and maintains data or a registry of relative asset values or of prior transactions defining or evidencing relative asset values. In related embodiments of the inventive method, in particular transactions an unique exchange value is determined for exchange for a transaction associated asset by operating on known relative asset values.

[0018] Note that in the example above, the exchange value EX may be right of ownership without transfer of possession of a physical object. The second party in the transaction may, or might not, have possession of the physical object or right of ownership in a specific asset represented by the exchange value. What is critical is that the control system maintain data evidencing the exchange values given up and received by each party.

[0019] The present method of transaction control is particularly useful in the context of serial rentals where physical possesion of an asset may pass through to multiple "second parties" without returning to the asset owner (first party). This may include payment, or other asset transfer, to the owner. Each transaction, between owner and second party and also between subsequent parties receiving possession of the asset, is executed in the same manner as described above.

[0020] An illustration of such serial rental transactions is embodied in a proposed sequential car rental application. An owner or first party having an automobile (car) can deliver the keys to a second party along with other enabling information in a transaction such as described in Figures 1 to 3, to enable the second party to possess and use the car. At a later time, in a similar transaction the second party deliver's the keys and enabling information to a third party, thereby effectively enabling that party's use of the car. This may continue indefinitely enabling various party's possession and use of the car. The control system

maintains internal data describing possession of the car and carries out the necessary payment transfers, or other asset transfers associated with each car- delivery transaction.

[0021 ] The above description is that of current embodiments of the invention. Various alterations and changes can be made without departing from the spirit and broader aspects of the invention as defined in the appended claims, which are to be interpreted in accordance with the principles of patent law including the doctrine of equivalents. This disclosure is presented for illustrative purposes and should not be interpreted as an exhaustive description of all embodiments of the invention or to limit the scope of the claims to the specific elements illustrated or described in connection with these embodiments. For example, and without limitation, any individual element(s) of the described invention may be replaced by alternative elements that provide substantially similar functionality or otherwise provide adequate operation. This includes, for example, presently known alternative elements, such as those that might be currently known to one skilled in the art, and alternative elements that may be developed in the future, such as those that one skilled in the art might, upon development, recognize as an alternative. Further, the disclosed embodiments include a plurality of features that are described in concert and that might cooperatively provide a collection of benefits. The present invention is not limited to only those embodiments that include all of these features or that provide all of the stated benefits, except to the extent otherwise expressly set forth in the issued claims. Any reference to elements in the singular, for example, using the articles "a," "an," "the" or "said," is not to be construed as limiting the element to the singular.