WO2000072209A2

WO2000072209A2 - Multiparty trading system

Info

Publication number: WO2000072209A2
Application number: PCT/US2000/014069
Authority: WO
Inventors: Prashant K. Bhatia; Dayal S. Gaitonde; Sameer Bhatia; Colin Weil
Original assignee: Monkeybin.Com, Inc.
Priority date: 1999-05-21
Filing date: 2000-05-22
Publication date: 2000-11-30
Also published as: AU5153600A; WO2000072209A9; WO2000072209A8

Abstract

A system is provided that conducts and facilitates complex trades between multiple parties by matching traders with items for which the traders wish to trade. In one embodiment, traders enter items that they are interested in trading into the system and identify other items in the system that they would be interested in receiving in return. The system then examines all entered items and all trader preferences, i.e. what traders are interested in receiving in return, and creates a system of multiple cross-linkages and chains between traders and items in the system. The system can close trading chains by acting as an active trader, using seeded items, i.e. pre-selected items that are entered into the system by a system operator, or the system can allow chains to close upon themselves, i.e. all traders in a particular chain are selecting items. Traders can request specific items and/or can submit general descriptions and have the system suggest items. The system provides trading cards that allow users to select desired items. The system provides novel and proprietary optimization functionality. The system provides both non-predictive and predictive models. The system provides for many-for-one and one-for-many trades. The system provides for brokerage usage in an offline mode, wherein brokers create proposals on behalf of traders, and wherein brokers provide output reports from the system to traders, thereby providing an opportunity for traders to decide whether or not to execute particular chains.

Description

Multiparty Trading System

BACKGROUND OF THE INVENTION

TECHNICAL FIELD

The present invention relates to bartering between multiple parties. More particularly, the present invention relates to a system for conducting and facilitating complex trades between multiple parties by matching traders with items for which the traders wish to trade.

DESCRIPTION OF THE PRIOR ART

Existing online bartering services use a two party trading model where a trade is negotiated and executed between two individuals or corporations. This model requires each party to have what the other party wants and vice-versa. The difficulty in locating such matching parties limits liquidity and success rate of barters. Alternate prior art models use a faux currency, which trading parties use to facilitate barter by buying and selling with this currency.

Kennedy; B. M., and Burchett; C. D., Framework for Negotiation and Tracking of Sale of Goods, U.S. Patent No. 6,055,519 (Apr 25, 2000) disclose a computer implemented system and process for negotiation and tracking of sale of goods. In this system and process, a negotiation engine operates to store data representing a current state of a negotiation between a seller and buyer. The negotiation engine stores the data within a framework for representing aspects of the negotiation between the seller and buyer. The framework includes a request object, a promise object and an acceptance object that can store a current description of a contract. The framework also includes a set of one or more delivery deals determined by the contract. Each delivery deal can have a delivery request object, a delivery promise object, and a delivery acceptance object that can store associated item deals and time periods for delivery of item deals. Each item deal can have an item request object, an item promise object and an item acceptance object that can store individual sales-order line-items. The negotiation engine thereby allows a user to monitor the current state of the negotiation over a range of prices, a range of dates, ranges of quantities of a set of goods, and a range of configurations of the goods in the set.

Togher; M., Dunne; M. F., and Hartheimer; R. Credit Management for Electronic Brokerage System, U.S. Patent No. 6,014,627 (Jan 11 , 2000) disclose an anonymous trading system that identifies the best bids and offers from those counterparties with which each party is currently eligible to deal, while maintaining the anonymity of the potential counterparty and the confidentiality of any specific credit limitations imposed by the anonymous potential counterparty. To that end, each bid or offer for a particular type of financial instrument is prescreened by the system for compatibility with limited credit information (for example, a one bit flag indicating whether a predetermined limit has already been exceeded) and an anonymous dealable price is calculated for each of the traders dealing with that particular financial instrument.

Garber; H. B., System and Method for Trading Having a Principal Market Maker, U.S. Patent No. 5,963,923 (Oct 5, 1999) discloses a system and method for linking a Rolling Spot Currency contract with a Principle Market Maker program. In one aspect of the invention, the system includes an electronic brokerage and trading network having at least one computer coupled to receive and transmit bids and offers for international currency trading; a display terminal and input; and a principal market maker computer coupled to the electronic brokerage and trading network wherein the principal market maker computer is operative to receive and transmit the bids and offers and execute international currency trades by maintaining a market for such currencies. In another aspect of the invention, the method includes the steps of receiving and transmitting bids and offers for publicly traded currencies; storing the received bids and offers in a memory; identifying and executing the matching bids and offers; and identifying unmatched bids and offers and providing a complementary trade to maintain a market for such currencies It would be advantageous to provide a multiparty trading model wherein barter, or a trade is executed by a group of two or more parties, and with a bartering system functioning as a market maker, i.e. as one of the trading party, if necessary to increase overall liquidity.

It would be advantageous to provide a maximum profit per trade and maximize profit per transaction, in order to provide a profitable and sustainable business model.

It would be advantageous to maximize the number of trades in a transaction given a set of potential transactions over a given period of time, in order to increase liquidity and user satisfaction.

It would be advantageous to minimize the number of items that expire without being traded, in order to increase user appeal. That is, the more successful trades a user has, the more times the user will use the trading method again.

It would be advantageous to provide an automated multiparty trading system that operates both online and offline.

It would be advantageous to provide a trading system that involves two or more users such that if a first user gives up an item A in exchange for receiving an item B from a second user, the system does not require that the second user receive item A in exchange for giving up item B, although this is a possible outcome.

It would be advantageous to provide a system wherein currency of any sort does not need to be a component of the system.

It would be advantageous to provide chains that are built and can close upon themselves.

It would be advantageous to allow users to select multiple items, any of which they are willing to receive for a given item. It would be advantageous to provide wish list functionality, wherein a user identifies items not already in the system and is notified by email when they are available in the system.

It would be advantageous to provide functionality that allows the system to find a match for a user's item, whereby a user specifies willingness to trade for particular items, items in particular categories or bins, or any items, and whereby the user receives email notification when such items complete a series of trades.

It would be advantageous to provide a trading cart that allows users to select items they are willing to accept in trade.

It would be advantageous to provide a feedback system for users of the system to communicate information, such as, for example, errors in delivery.

It would be advantageous to provide a system that stores relevant data, such as, for example, items available for transfer, proposals, users, and trading carts.

It would be advantageous to provide a system that conducts many-for-one and one-for-many trades.

It would be advantageous to provide a system for brokerage usage in an offline mode, wherein brokers create proposals on behalf of traders, and wherein brokers provide output reports from the system to traders, thereby providing an opportunity for traders to decide whether or not to execute particular chains.

SUMMARY OF THE INVENTION

A system is provided that conducts and facilitates complex trades between multiple parties by matching traders with items for which the traders wish to trade. In one embodiment, traders enter items that they are interested in trading into the system and identify other items in the system that they would be interested in receiving in return. The system then examines all entered items and all trader preferences, i.e. what traders are interested in receiving in return, and creates a system of multiple cross-linkages and chains between traders and items in the system. The system can close trading chains by acting as an active trader, using seeded items, i.e. pre-selected items that are entered into the system by a system operator, or the system can allow chains to close upon themselves, i.e. all traders in a particular chain are selecting items. Traders can request specific items and/or can submit general descriptions and have the system suggest items. The system provides trading carts that allow users to select desired items. The system provides novel and proprietary optimization functionality. The system provides both non-predictive and predictive models. The system provides for many-for-one and one-for-many trades. The system provides for brokerage usage in an offline mode, wherein brokers create proposals on behalf of traders, and wherein brokers provide output reports from the system to traders, thereby providing an opportunity for traders to decide whether or not to execute particular chains.

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 a is a diagram of a closed transaction chain according to one embodiment of the invention;

Fig. 1 b is a diagram of a closed transaction chain according to another embodiment of the invention;

Fig. 1c is a diagram of a closed transaction chain according to another embodiment of the invention;

Fig. 2a is a schematic diagram of the an embodiment, wherein a broker makes proposals on the World Wide Web (Web) on behalf of three users and receives reports showing that show chains from an algorithm according to the invention;

Fig. 2b is a flow diagram illustrating the three users of Fig. 2a shipping items and receiving items to and from one another according to the invention;

Fig. 3a is a schematic diagram of an embodiment, wherein three users make proposals on the Web and receive executed chains by an algorithm according to the invention;

Fig. 3b is a schematic diagram illustrating the three users of Fig. 3a shipping and receiving items from one another according to the invention;

Fig. 4a is a schematic diagram showing a many-for-one trade that is satisfied by having a one-for-many trade within a chain;

Fig. 4b is a schematic diagram showing a many-for-one trade that is satisfied by only using only one of the items and placing the other items in a pool for reserved items;

Fig. 4c is a schematic diagram showing a one-for-many trade that is satisfied by having a many-for-one trade within a chain; and

Fig. 4d is a schematic diagram showing a one-for-many trade that is satisfied by using an item from a pool of reserved items.

DETAILED DESCRIPTION OF THE INVENTION

Herein below is a glossary defining terminology as used in the invention.

Glossary.

Chain - a group of potential trades. Chain length - the number of user parties in a string of transactions.

Trade - a successful exchange for a single party, equivalent to a link in a chain.

Link - same as a trade.

Transaction - a set of successful trades between parties in a chain, wherein each party's request is fulfilled. A transaction must consist only of tradable items.

Tradable Item - an offered item that has a list of items to accept in return.

Seed Item - an item that is available for trade that was provided by the system.

Overview.

Existing online bartering services use a two party trading model wherein a trade is negotiated and executed between two individuals or corporations. This prior art model requires each party to have what the other party wants and vice-versa. The difficulty in locating such matching parties limits liquidity and success rate of barters. The invention herein uses a multiparty trading model, wherein barter is executed by a group of two or more parties. In one embodiment, the system functions as a market maker, i.e. as one of the trading party if necessary to increase overall liquidity.

Fig. 1 a is a diagram of a closed transaction chain according to one embodiment of the invention. Six trading parties (A-E) 1-6 and the system acting as a trader 7 are shown offering an item to one party and receiving an item from a different party. That is, the diagram illustrates the trading model in a seven party trade, whereby party A trades its item to B, B trade its item to the system and the system trades its item to party E, etc. Each party thus gets what it wants by trading with two other parties.

Fig. 1 b is a diagram of a closed transaction chain according to another embodiment of the invention. That is, the diagram illustrates the trading model 10, wherein the system allows proposals to be made to users, such as, for example, user 5, based on stated preferences, thus enhancing the user experience and broadening scope of potential matches.

Fig. 1c is a diagram of a closed transaction chain according to another embodiment of the invention. That is, the diagram illustrates the trading model 11 , wherein the system allows proposals to be made to users, such as, for example, user 5, based on past behaviors and/or stated preferences, thus enhancing the user experience and broadening scope of potential matches.

User Functional Model.

In a preferred embodiment of the multiparty trading system, a user engages in one or more of the following three scenarios:

Scenario 1. The user offers an item to trade by adding it to a pool of available items. The user selects an expiration period of 1 , 2, or 3 weeks for each item, the default being 2. An item that is not traded by the expiration date will be automatically removed from the pool. The user may re-enter the item back into the pool. This prevents the pool from having stale items.

Scenario 2. For each item offered, the user may select items that are in the pool of available items that the user is willing to accept in return. This list is called the accept list. Although the user is not required to specify such a list when an item is offered, the list must eventually be populated with items in order for the system to include the offered item in the list of potential trades. An offered item with at least one item on its accept list is called a tradable item.

Scenario 3. If the user wants types of items that are not currently available in the pool, the user may provide a description of such items. The description of an item can be rather specific, e.g. Pink Floyd Dark Side of the Moon CD, or quite general, e.g. any Pink Floyd CD. This list forms the wish list.

In the preferred embodiment, when an item that best matches any item in the wish list appears in the pool, the system will present the item as a proposal to the user to add to its accept list. The user will be able to view such proposals by login on to the system and/or, as an option, be notified via e-mail. The reason for having the user explicitly add a proposed item to its accept list rather than having the system do it automatically is to allow the user to confirm that the particular item is really what the user wants, e.g. the user may decide not to accept an item from a particular user.

In the preferred embodiment, if an item in an accept list or a proposal is traded away, the system highlights the item to allow a user to change selections promptly. Also, a user cannot remove an offered item before the expiration period.

Objectives.

The ideal objectives of the trading model are summarized in Table A, herein below. Table A

It is noted that the proprietary optimization algorithm used in the preferred embodiment of the system optimizes multiple parameters at once by calculating an overall optimization score based on a weighting of all the optimization components. As such an implementation of the model should allow an administrator to select desired parameters to optimize and the desired set of constraints.

Non-Predictive Model. Base Algorithm.

This section describes the algorithm of the preferred embodiment, whereby the algorithm selects transactions to be executed. Specifically, this algorithm traverses a list of proposals to determine all possible chains that can be executed. It then decides which of those chains to execute. The objectives that are used to determine which chains to select are summarized herein above in Table A.

In the preferred embodiment, the approach of this algorithm is to compute the optimization score for every possible chain, and then to select the chain with the highest optimization score. The function that is used to compute the optimization score is independent of the base algorithm, and can be adjusted over time to reflect the changing needs of a business.

The claimed invention herein comprises one such proprietary optimization functionality described herein below. Any optimization formula can be used, provided that the optimization score can be computed in an incremental manner. Specifically, this means that the optimization scores of each of the items in the accept list are known, then the optimization score of the current item can be computed without re-traversing the sub-chains.

The incremental computation of the optimization score limits the computational expense of the algorithm to be linearly proportional to the number of proposals in the chain. This is due to the fact that a sub-chain never needs to be traversed a second time.

Algorithm.

The preferred embodiment of the algorithm is described herein below. A list of all proposals is created. For every proposal in the list, an optimization score is computed in the following manner:

1. All items in the accept list must have their optimization scores calculated. If at any given time the optimization scores of one or more of the items in the accept list is not yet calculated, then the calculation of the score of the current item is put on hold while scores are calculated for those items in the accept list that do not yet have a score. This process is repeated in a recursive manner.

2. For each item in the accept list, an optimization score for the current item is computed by incrementally adjusting the optimization score of the item in the accept list according to the optimization formula.

3. Of n optimization scores calculated for the current item, i.e. corresponding to the n items in the accept list, a maximum score is chosen as the optimization score for the current proposal.

The optimization score of each proposal represents a value of starting a chain with that proposal. After an optimization score is calculated for each proposal, the chain with the highest score is selected. It is noted that the description of the process herein can use seed items as the last item in the chain. However, the process works for any end item, and in this case trading chains are built and close upon themselves because all trading parties in the chain make selections.

If the optimization score of the highest scoring chain is above a minimum acceptable optimization score, then a transaction is made. The corresponding proposals are removed from the pool of available proposals, and the corresponding items are made unavailable for future trades. The algorithm is then repeated.

If the optimization score is not above the minimum acceptable optimization score, the transaction is not completed. That is, no transaction is made, and the algorithm is terminated.

In one embodiment, for each chain of proposals having seed items that gets executed, the system receives one item in exchange for its seed item. This received item is marked as a seed item and will be made available as a tradable item as soon as the system receives that item physically from the associated user.

In the course of executing chains of proposals, proposals become dead proposals when all of the items in the associated accept lists get traded away to other proposals. That is, such proposals and their items are marked as dead and removed from the trading pool. Associated users are then notified so that they may select new lists of accept items and create new proposals.

Seeded/Seedless Base Algorithm. This section describes the algorithm of the preferred embodiment, whereby the algorithm selects transactions to be executed. Specifically, this algorithm traverses a list of proposals to determine all possible chains that can be executed and all chains that would not execute. It then decides which of those chains to execute. The objectives that are used to determine which chains to select are summarized herein above in Table A.

Algorithm.

The preferred embodiment of the algorithm is described herein below. A list of all proposals is created. The algorithm steps are as follows:

1. Identify all valid proposals in the system.

2. Select one proposal ("parent") and place its Have item on a "chain list" and place its proposal on a "proposal list".

3. For the "parent's" Have item, ask if it appears as part of a proposal's accept list.

4. If no and if this proposal does not appear on any accept lists whatsoever, mark chain as "open" and go to step 3. If no and if this proposal appears on at least one accept list and it is not on the proposal list, then go to step 3 for any other proposals where this proposal's Have item appears on an accept list; if it is on the proposal list, go to step 9. If yes, then select a proposal ("child") whose accept list it is on.

5. Check "child's" proposal to see if its Have item is on the list.

6. If yes, a complete chain has been identified; save this list and mark chain as complete; continue to step 8. If no, add this Have item to the "chain list" and the "child's" proposal to the "proposal list".

7. Repeat step 3-6 considering the "child" proposal to be a "parent" proposal. 8. Considering this "child" proposal to be a "parent" proposal, go to step 3 and execute for any other proposals where this proposal's Have item appears on accept list.

9. Repeat step 8 with a proposal that is not on the proposal list until all valid proposals have been placed on the "proposal list".

10. If no completed chains exist, go to step 13. If completed chains exist, calculate optimization scores of all completed chains by invoking optimization function.

11. Identify the chain with the highest optimization score and check if this score meets the minimum score required by the system. If yes, then communicate to all users whose items appear in the qualifying chain the accept item that has been matched with their Have item; mark all proposals in the qualifying chain as "traded" (not valid). If no, go to step 13.

12. Repeat steps 1-11.

13. For all open chains in system, check if first item on "chain list" is a seed item.

14. If no, terminate algorithm. If yes, create a system-generated proposal for all open chains where the Have item is the seed item identified above and the accept item is the last item in the "chain list"; mark these chains as "complete".

15. Repeat steps 10-13.

The claimed invention herein comprises one such proprietary optimization functionality described herein below.

Any optimization formula can be applied to the set of complete chains found by the algorithm. Specifically, this means that the optimization score of each chain must be calculated based on the items within its chain. The optimization score is calculated for each item. The sum of the optimization scores is summed together along with chain length. This summed total gives the optimization score for the entire chain. After the optimization score is calculated for each of the chains, the chain with the highest score is selected.

It is noted that the description of the process herein can use seed items as the last item in the chain. However, the process works for any end item, and in this case trading chains are built and close upon themselves because all trading parties in the chain make selections.

Optimization Function.

Following is a description of the preferred embodiment of the proprietary optimization function used in the invention here. The fundamental goal of the model is to achieve a minimum average net profit per item i, PMINi, while maximizing the overall profit from a pool of possible transactions. The average net profit per item, PAi, and other variables are defined as follows:

• PM - Value of item system gives up in a trade.

• PO - Value of item system accepts in a trade.

• PD = PM-PO, which usually is >= 0 but can be < 0 if user trades something of greater value for something of less value from system. This value can be used to capture difference in value due to, such as, but not limited to, quality, type of items, etc.

• S - Shipping and handling cost per transaction.

• G - Number of user parties in a transaction, i.e. does not include the system.

• C - Cost per transaction to the system = PD + S.

• Ri - Trading fee per trade for item i.

• Wi - Weighted average cost per trade for item i = (Ri ^* C)/Sum of All Ri in a transaction.

• PT - Profit per transaction = (Sum of all Ri in a transaction) - C.

• PAi - Average net profit per item traded = Ri - Wi.

To describe the preferred algorithm, we define the following: • TQ - A qualified transaction which is a transaction wherein every PAi

>= PMINi for every item in the transaction.

• PTMAX - Maximum PT among all TQ transactions when the algorithm is applied.

The preferred algorithm is as follows:

1. Determine the set of TQ's from all possible transactions from a given pool of possible transactions. 2. From this set of TQ's, the transaction with the largest PT is selected to execute successfully. In the case of a tie, the transaction with the largest value of G is selected to maximize the number of trades. Remove items from the pool that are in the transaction.

3. Repeat 1 and 2 until there are no more qualified trades.

The process described by steps 1-3 above is termed the algorithm process. This process is invoked periodically, typically configurable by a system administrator.

The algorithm described herein above is not guaranteed to maximize the total profit over all possible sequences of TQs selected by the algorithm process because each selection of a TQ reconfigures the set of TQs for the next iteration of the algorithm in the same algorithm process. An algorithm that accomplishes maximizing the total profit over all possible sequences of TQs selected by the algorithm process has to try all possible sequence of TQs and compare the total profit from each sequence. Such a problem is similar to the well-known traveling salesman problem and is computationally intensive.

It is noted that maximizing the total profit over all possible sequences of TQs selected by the algorithm process by trying all possible sequence of TQs and comparing the total profit from each sequence is obviously within scope of the claimed invention herein.

It is noted that the model described herein above is non-predictive in that it does not attempt to anticipate how the set of TQs might change in the future that could result in a larger PTMAX when the algorithm process is run again at a future time.

Chain Length.

In the preferred embodiment, the chain length is the number of user parties in a string of transactions and plays a role in maximizing a number of successful trades and is related to profit margin. The use of chain length is described in herein below. Maximizing Trade Count.

In the preferred embodiment, in a non-predictive model the number of trades that can be completed is inversely proportional to the minimum chain length that a transaction must have before it can be executed. Because minimum chain length is directly correlated to PMINi, decreasing PMINi will decrease minimum chain length and increase the number of trades that are executed each time the algorithm process is run. That is, the system completes more trades that are less profitable. Adjusting minimum chain length using PMINi is useful since it allows for trading profit margin for liquidity, which makes it easy, for example, to assess the impact of such changes to a business model.

It is worth studying the effects of modifying the algorithm to select the transaction with the largest value of G instead of largest value of PT from the set of qualified transactions to increase the number of trades. The modification described may appear to increase the number of trades in preference over increasing profits. However, this modification alone may not have the intended result because removing a set of items from the pool reconfigures the set of TQs for the next iteration which could result in a decrease or increase in the number trades for subsequent iterations. As in trying to maximize total profit in an algorithm process, the solution is to try all possible combination of sequences and solve it as a traveling salesman problem.

In most cases, trades are expected to occur between items of similar values. Because Ri is set as a function of the value of an item, a longer chain will have higher PT than a shorter chain. Thus selecting a chain with the highest PT is usually the same as selecting the longest chain.

Outliers.

According to the preferred embodiment, it is noted that a case contrary to the cases described herein above is best illustrated as follows. Take two chains A and B wherein chain A is longer than chain B and an overlap in the chains exists, such that selecting one chain will prevent the other chain from executing. Consider the case wherein value G of A is substantially larger than value G of B, but PT of A is lower than PT of B. Using the algorithm described herein above B is selected over A, whereby a significant number of trades may have been sacrificed. However, in order for the values of G to be substantially different between the chains, chain B will have to contain one or more trades wherein a user is trading an item that is of much higher value than the item the user wants. That is, the shorter chain otherwise cannot have a higher PT. Such trades should be considered rare and should not be allowed to complicate the model described herein by trying to optimize around such cases.

Relation To Profit Margin.

In the preferred embodiment, the minimum length of a chain is highly correlated with PMINi and can therefore be controlled by adjusting PMINi. In a homogenous set of tradable items where Ri, Pi and C are all a constant, the minimum value of G for a given Pi is equal to C/(Ri-PMINi) rounded up to the nearest positive integer, wherein the minimum is 1 if a system item is traded. Following are examples:

• Setting PMINi = Ri-C causes the system to execute every transaction with one party or more. The system makes money on every transaction if Ri-C > 0 and potentially loses money on transactions with small values of G otherwise.

• Setting PMINi = Ri -C/3 causes the system to execute only transactions that have a minimum of 3 parties and to make money on every transaction if Ri-C/3 >0.

Another way to view the relation to profit margin is that the fixed cost per transaction, C, amortized over all trades in a transaction that is weighted by trading fee for each item must be less than the trading fee per trade in order for the transaction to be profitable. Larger values of G allow the cost due to C to be amortized over larger number of trades to make the overall transaction profitable.

In the case wherein the system is not in the transaction, then C is equal to zero. In this case the minimum value of G is 2, which is the minimum number of parties to perform a trade. Every such trade will be profitable to the system, assuming Ri > 0.

Items with unegual value. In the preferred embodiment, consider a case wherein the system trades something of high value for something of low value, e.g. high quality for a low quality item, such as a CD for a videocassette. The model accounts for the value difference between items by using the value of PD. For example, if a user attempts to trade a CD for a videocassette, the value of PD can be set large enough to prevent such a transaction. A same approach can be taken to prevent trading a mint item for a poor quality item.

Setting Parameter Values.

Item Values In the preferred embodiment of the model, the value of an item depends on the type of item and the condition of the item. The values should be set based on average market values for each type and condition. In the future, the model can assign values based on other factors, possibly actual market values. Ri

Various ways to set trading fee for an item, Ri, are depicted herein below:

• As a percentage of the perceived value of the item. For example, a used CD is worth about $8. Using a 10% trading fee, the trading fee would be $0.80.

• As a function of the total costs to trade using the system verses to trade using other channels. For example a user can sell a CD to a store for $5 and purchase the CD the user wants for $8. The net cost to the user is $3. To be competitive, the total cost of trading a CD using the system as a trader should not exceed $3. Therefore, the maximum Ri for a CD should be $3 minus shipping and packaging cost.

PMINi PMINi is the minimum average profit per trade for an item i. Each type of item or trading bin should have its own PMINi, e.g. CD and Video Disk. Also, PMINi should not be set larger than Ri and could be considerably lower to account for fixed costs due to C. One method to set PMINi is to assume homogenous items in a typical transaction and set PMINi equal to Ri - C/Gmin, where Gmin is the minimum chain length desired over which to amortize the cost of C.

The model also allows PMINi to be set to a negative value during the introduction of the service to maximize the number of trades and provide good user experience. The value then becomes the MAXIMUM cost per trade to the system and becomes part of the cost of customer acquisition.

It is noted that when PMINi is set as described herein above, it is important that the system automatically keep a running total of such costs to make sure that the total does not exceed a certain budget.

Predictive Model.

In the preferred embodiment, a predictive model tries to guess how chains may evolve given the current and historical information available. Assuming guessing accurately, the algorithm is modified to include future possibilities to maximize PTMAX over multiple invocations of the algorithm process. This is similar to attempts to predict future stock prices using stochastic models, which is typically accepted to be a futile effort.

In order to have a basis for predictions, information must be selected to be used in forming the prediction. An item is added to a chain when a user selects the item at the tail of the chain. Thus the likelihood a chain is extended with one more item depends on the popularity of the item at the tail of the chain. It is noted that since a chain may branch off from any point in it. For example, it may be that the third item in a chain of five actually ends up being the most popular and that items 4 and 5 end up getting cut out from the final chain. Therefore, how to determine the popularity of an item at the tail is worth examining. One measure of popularity is the number of requests for a particular item over a period of time. This number can be gathered from historical data.

The purpose of the prediction is to maximize profit. Thus, the model needs to also calculate the expected PAi and PT of the hypothetical transaction. This calculation requires a calculation of the expected incremental trading fee and the expected transaction costs, i.e. C. When the required calculation is complete, the algorithm simply executes with hypothetical chains. It also puts back items from the hypothetical chains that are selected to be executed and after the algorithm process finishes.

The hypothetical chain can be extended by predicting the popularity of the item that will be added to the existing chain and repeating the above process. However, such second order predictions are not likely to yield better results.

Broker Application.

In another preferred embodiment, a broker creates deals in a manual fashion on behalf of users. That is, the broker creates proposals on behalf of traders. More specifically, broker facilitates barters between businesses.

It is noted that this embodiment of the claimed invention herein comprises, but is not limited to, the step of focusing effort on information gathering and performing the associated transactions in an offline mode.

In the broker application, the embodiment is customized as a broker tool, thereby enabling a broker to supply some or all of said items to the system, and enabling the broker to manage transactions according to business objectives.

Fig. 2a is a schematic diagram of an embodiment, wherein a broker makes proposals on the World Wide Web (Web) on behalf of three users and receives reports that show chains from an algorithm according to the invention. Three users (200-202) and a broker 203 communicate information (204-206) about what the users have to offer and what they want to receive by means of, but not limited to, the telephone, email, faxes, and the like. The broker 203 then makes proposals 207 on behalf of customers on, but not limited to, a Web by means of a typical browser or by means of a custom tool. The customer information is stored in a database 208. An algorithm 209, comprising in the preferred embodiment proprietary optimization functionality, retrieves proposals 210 from the database 208. The algorithm 209 also uses optimization parameters 211 to create output 212 comprising, for example, trading maps and generated reports that show the chains creates in the algorithm.

Fig. 2b is a flow diagram illustrating the three users of Fig. 2a shipping items and receiving items to and from one another according to the invention. User 1 ships an item to User 2 (220), User 2 ships an item to User 3 (221), and User 3 ships an item to User 1 (222).

Fig. 3a is a schematic diagram of another embodiment, wherein the three users make proposals on the Web and receive executed chains by an algorithm according to the invention. The three users (200-202) communicate information and make proposals (300-302) on, but not limited to, a Web by means of a typical browser. The information is stored in the database 208. The algorithm 209, comprising in the preferred embodiment proprietary optimization functionality, retrieves proposals 210 from the database 208. The algorithm 209 also uses optimization parameters 211 to create output 310 comprising, for example, trading maps and executed chains created by the algorithm 209.

Fig. 3b is a flow diagram illustrating the three users of Fig. 2a or Fig. 3a shipping items and receiving items to and from one another according to the corresponding embodiment of the invention. User 1 ships an item to User 2 (220), User 2 ships an item to User 3 (221), and User 3 ships an item to User 1 (222).

Many for One and One for Many.

In another embodiment of the invention, traders conduct many-for-one trades or one-for-many trades. A many-for-one trade is a trade wherein a trader offers two or more items for one item. A one-for-many trade is a trade wherein a trader offers one item for two or more items.

Fig. 4a is a schematic diagram showing a many-for-one trade that is satisfied by having a one-for-many trade within a chain. User 1 has two items, Item 1a and Item 1b (400 and 401) and wants one item 402, which is Item 2. User 2 has one item 402, Item 2 and wants two items, Item 3 and Item 4 (403 and 404). User 3 has one item 403, Item 3 and wants one item 400, Item 1a. User 4 has one item 404, Item 4 and wants one item 401 , Item 1b.

Fig. 4b is a schematic diagram showing a many-for-one trade that is satisfied by using only one of the items and placing the other items in a pool for reserved items. User 1 has two items, Item 1 a and Item 1 b (410 and 411) and wants one item 412, which is Item 2. User 2 has one item 412, Item 2 and wants one item 413, Item 3. User 3 has one item 413, Item 3 and wants one item 410, Item 1a. Item 1 b 411 is placed into a system reserve pool of items 414.

Fig. 4c is a schematic diagram showing a one-for-many trade that is satisfied by having a many-for-one trade within a chain. User 1 has one item 420, Item 1 and wants two items, Items 2a and Item 2b (421 and 422). User 2 has two items (421 and 422), Items 2a and 2b, and wants two items (423 and 424), Items 3a and 3b. User 3 has two items (423 and 424), Items 3a and 3b, and wants one item 420, Item 1.

Fig. 4d is a schematic diagram showing a one-for-many trade that is satisfied by using an item from a pool of reserved items. User 1 has one item 430 and wants two items (431 and 432), Items 2a and 2b. Item 2b is taken from the pool of reserved items 414. User 2 has two items (431 and 432), Items 2a and 2b, and wants one item 433, Item 3. User 3 has one item 433, Item 3 and wants one item 430, Item 1.

User Selected vs. General Description.

In the preferred embodiment, the general method of facilitating the transfer of ownership of items among two, three, or more users comprises the step of the user selecting wanted items, or by the user providing the system with a general description of wanted items and having the system select items for the user. In either case, the system receives from each user a list of items available for transfer. The system matches each user with an item, but not limited to a single item, owned by another user. The system then notifies each user of an item to be received for the item made available for transfer.

More specifically, a user conveys to the system a proposal specifying an item owned by another user that would be accepted for the first item. The items that the system selects from the items made available for transfer are not limited to being specified by said users. For example, the system then makes a proposal to a first user of at least one item from the available items for transfer from at least one other user such that the proposal is acceptable by the first user for a specific item owned by said first user. The first user conveys its acceptance of the proposal to the system.

It is noted that such transfers of ownership are not required to be reciprocal. For example, if a first user gives up item A in exchange for receiving item B from a second user, the system does not require that the second user receives item A in exchange for giving up item B, although this is a possible outcome.

The system receives from the user an indication of acceptable items that are not limited to items made available for transfer from other users. The indication of acceptable items can be, for example, a list of items, or a general description of acceptable items. The general description can comprise categories of items, such as, for example, CD's and videos. The general description can also specify all items available for transfer.

The system also notifies the user when an item from the general description is available.

In another embodiment, the system provides wish list functionality. That is, a user identifies items not already in the system and is notified by email when they are available in the system. The wish list can be entered in the list of wants portion of the trading cart described herein below.

Trading Cart. In the preferred embodiment, the system provides a trading cart that allows users to submit proposals. The trading cart has the following components: a list of haves, i.e. what a trader has to offer; a list of wants specifying items users desire to own; and an accept proposal indicator for users indicating interest in receiving said particular proposals. It is noted that the list of haves is required and that it specifies items users offer. For each have of the list of haves users must specify either a list of wants and/or specify the accept proposal indicator. Users add to the list of haves by posting an item, and add to a list of wants of browsing items available for transfer.

Seeded Items.

In the preferred embodiment, seeded items are items available for trade provided by the system. They serve various purposes described herein below.

Seeded items can be used as an initial set of items for first users of the system, giving the system time to build up a database of items. As more attractive items appear in the system over time, then using seeded items may not be as beneficial.

It has been observed that providing seeded items keeps the customer interest level up in the short term. That is, it is better to have more attractive items in the system. Trading volume has been observed to be higher.

In the preferred embodiment, the system handles both a seeded approach or an unseeded approach, depending on business needs. In the seeded approach, or sometimes referred to as the seeded system, the system chooses the last item in order to close the chain. In the unseeded approach, or sometimes referred to as the unseeded system, all trading parties within the system are selecting and the chains close said to close upon themselves. Other Features.

In another embodiment, a user feedback mechanism is provided to allow users to communicate feedback, such as, for example, errors in delivery. Currency of any sort does not need to be a component of the system. Users select multiple items, any of which they are willing to receive for a given item.

It is noted that the invention claimed herein this document is not limited to any online or offline environmental configuration and is limited only by an interested entity's technical environment's constraints.

Accordingly, although the invention has been described in detail with reference to particular preferred embodiments, persons possessing ordinary skill in the art to which this invention pertains will appreciate that various modifications and enhancements may be made without departing from the spirit and scope of the claims that follow.

Claims

1. A method for conducting and facilitating trades between multiple parties, said parties comprising traders, comprising the steps of: said traders specifying items to trade and specifying desired items; examining and using said specified items to trade and said specified desired items, and using said traders to create a plurality of multiple cross- linkages and multiple chains between said traders; and closing said multiple chains; wherein said multiple parties are matched with desired items, and wherein said desired items are items said multiple parties wish to trade for.

2. The method of Claim 1 , wherein said trades are complex.

3. The method of Claim 1 , wherein said closing of said multiple chains step further comprises the step of: using seeded items, wherein said seeded items are pre-selected items specified by a system operator; and wherein the step of closing said multiple chains further comprises said system acting as an active trader and said system using said seeded items.

4. The method of Claim 1 , wherein the step of specifying items to trade further comprises entering said specified items into a computer system; and wherein the step of specifying desired items further comprises identifying said items to receive, said items to receive residing in said computer system.

5. An apparatus for conducting and facilitating trades between multiple parties, said parties comprising traders, comprising: means for said traders specifying items to trade and specifying desired items; means for examining and using said specified items to trade and said specified desired items, and using said traders to create a plurality of multiple cross-linkages and multiple chains between said traders; and means for closing said multiple chains; wherein said multiple parties are matched with desired items, and wherein said desired items are items said multiple parties wish to trade for.

6. The apparatus of Claim 5, wherein said trades are complex.

7. The apparatus of Claim 5, wherein said means for closing of said multiple chains further comprises: using seeded items, wherein said seeded items are pre-selected items specified by a system operator; and wherein said means for closing said multiple chains further comprises said system acting as an active trader and said system using said seeded items.

8. The apparatus of Claim 5, wherein said means for specifying items to trade further comprises entering said specified items into a computer system; and wherein said means for specifying desired items further comprises identifying said items to receive, said items to receive residing in said computer system.

9. A method for a user of a multiparty trading system, comprising one or more of the following steps: offering an item to trade by adding it to a pool for available items and selecting an expiration period for said item; selecting an accept list of items from said pool that said user accepts in return, wherein said list must be nonempty in order for said offered item to be a tradable item; and providing a description of other items, wherein said other items are not available in said pool, thereby creating a wish list.

10. The method of Claim 9, wherein if said item is not traded by end of said expiration period, said item is automatically removed from said pool.

11. The method of Claim 10, further comprising the step of: re-entering said item back into said pool after said end of expiration period.

12. The method of Claim 9, wherein said description of another item from said items is not limited to being specific or general or anything in between.

13. The method of Claim 9, further comprising the step of: adding a proposal to said accept list, wherein said proposal is an item that best matches any wish list item.

14. The method of Claim 9, further comprising the step of: previously viewing said proposal before said adding step.

15. The method of Claim 14, wherein said proposal is viewed on a computer system

16. The method of Claim 9, further comprising the step of: promptly changing selections in said accept list when any item from said accept list or any proposal is traded away.

17. The method of Claim 9, wherein said offered item to trade is not removable from said pool prior to said end of expiration period.

18. A method for a trading system having a pool of items to be traded and having trading parties, said system to make transactions, wherein each transaction of said transactions is a number of successful trades between said trading parties, and wherein a request of each party of said trading parties is fulfilled, comprising any of, or any combination of, but not limited to, the steps of: providing a maximum profit of each trade of said successful trades; maximizing a profit of said each transaction; maximizing said number of trades in said each transaction; and minimizing a number of items from said pool of items that expire without being traded.

19. The method of Claim 18, further comprising the step of: allowing an administrator to select parameters to optimize and to select a set of constraints, wherein said optimizable parameters and said set of constraints further comprise parameters and constraints associated with any of said maximum trade profit, said maximum transaction profit, said maximum number of trades, and said maximum number of expired items.

20. The method of Claim 18, further comprising the step of providing a non-predictive method.

21. The method of Claim 18, further comprising the step of providing a predictive method.

22. The method of Claim 20, further comprising the steps of: determining all possible executable chains; and deciding a chain of said executable chains to execute, wherein a chain is a group of potential trades.

23. The method of Claim 22, further comprising the step of: computing an optimization score for each of said chains, wherein said deciding chain has a highest optimization score.

24. The method of Claim 23, further comprising the steps of: making a transaction, said transaction associated with said decided chain, when said decided chain's optimization score is above a minimum optimization score; and removing associated items from said pool of items.

25. The method of Claim 23, wherein the step of computing an optimization score uses an independent and/or adjustable optimization function, wherein said optimization function computes said score incrementally.

26. The method of Claim 25, wherein said independent and/or adjustable optimization function is a proprietary optimization function, and comprises the steps of: determining a set of all qualified transactions from all possible transactions from a given pool of possible transactions; selecting from said set of qualified transactions a transaction satisfying a predetermined set of parameters and set of constraints; removing items in said selected transaction from said pool of items; and repeating said steps herein above until no qualified trades exist.

27. The method of Claim 23, further comprising the step of: terminating when said decided chain's optimization score is not above a minimum optimization score.

28. The method of Claim 20, further comprising the steps of: receiving an item from said pool in exchange for a seed item; and marking said received item as a second seed item, thereby making said second seed item available as a tradable item.

29. The method of Claim 28, wherein said second seed item is available as a tradable item after being physically received from a user.

30. The method of Claim 20, further comprising the steps of: creating a dead proposal, wherein said dead proposal is a previously tradable item having acceptable items that have been traded away; removing said dead proposal from said pool; and notifying associated users of said dead proposal.

31. The method of Claim 20, further comprising the step of: adjusting a minimum chain length to allow a preference for more liquidity over a trade profit margin.

32. The method of Claim 20, wherein the step of maximizing said number of trades further comprises the step of: trying all possible combinations of sequences of said transactions.

33. The method of Claim 20, further comprising the step of: assuming trades, wherein a traded item is of substantially higher value than a desired item are rare; and deciding not to optimize around said rare trades.

34. The method of Claim 20, wherein a fixed cost per said each transaction amortized over all trades in said each transaction, said each transaction weighted by a trading fee for each item of said each transaction, must be less than a trading fee per trade of said all trades in said each transaction, in order for said each transaction to be profitable.

35. The method of Claim 20, further comprising either or both of the steps of: preventing a trade between a first two items, said first items having a substantial difference in value by setting a first parameter; and preventing a trade between a second two items, said second items having a substantial difference in quality by setting a second parameter, wherein said first parameter may be equal to said second parameter.

36. The method of Claim 20, wherein a maximum profit of trade is allowed to be negative, thereby providing good user experience.

37. The method of Claim 21 , further comprising the step of: predicting how a chain evolves using available current and historical information, wherein said chain is a group of potential trades or a transaction.

38. The method of Claim 37, further comprising the steps of: measuring a popularity of an item at a tail of said chain; calculating expected average net profit per item; calculating profit per transaction of each hypothetical transaction, further comprising the steps of:; calculating expected incremental trading fee; and calculating expected transaction costs; executing a non-predictive algorithm using said hypothetical chains; putting back items in said hypothetical chains, said items selected to be executed at end of said non-predictive algorithm.

39. The method of Claim 38, wherein said popularity is measured by numbering requests for said tail item over a period of time.

40. The method of Claim 18, wherein associated with said each trade are a first trading party, and a second trading party, whereby said first trading party fulfills a request by said second trading party, and whereby a first party's request is not required to be fulfilled by said second party.

41. The method of Claim 40, wherein either of said first or second party's request is fulfilled by offering one or more items and by receiving for said one or more offered items one or more acceptable items.

42. The method of Claim 18, further comprising the step of: configuring said system to be customized.

43. The method of Claim 42, further comprising the steps of: configuring said system as a broker tool; wherein said broker supplies some or all of said items to said system; wherein system configuration further comprises enabling said system to create transaction reports; and wherein said broker manages said transactions using said transaction reports according to business objectives.

44. A method of facilitating the transfer of ownership of items among three or more users, comprising the steps of: receiving from each user a list of items available for transfer; matching each user with an item owned by another user such that transfers are not limited to being reciprocal; and notifying each user of said matched item to be received for an item from said list of items made available for transfer.

45. The method of Claim 44, further comprising the step of: receiving from a first user a proposal specifying an item owned by a second user that would be accepted for an item owned by the first user.

46. The method of Claim 44, wherein the matching step further comprises the step of: selecting items from said items available for transfer, wherein said selected items are not limited to being specified by said users.

47. The method of Claim 44, wherein said matching step further comprises the step of: making a proposal to a first user of at least one item from said available items for transfer from at least one other users such that said proposal is acceptable by said first user for a specific item owned by said first user.

48. The method of Claim 47, wherein said matching step further comprises the step of: receiving said first user's acceptance of said proposal.

49. The method of Claim 44, wherein said matching step further comprises the step of: receiving from a first user an indication of acceptable items, wherein said acceptable items are not limited to said items available for transfer for a specific item owned by said first user.

50. The method of Claim 49, wherein said indication of acceptable items is a list of items.

51. The method of Claim 49, wherein said indication of acceptable items is a general description of said acceptable items.

52. The method of Claim 51 , wherein said general description comprises categories of items.

53. The method of Claim 51 , wherein said general description comprises all items available for transfer.

54. The method of Claim 49, further comprising the step of: notifying said first user when an item from said acceptable items not limited to items available for transfer is available.

55. The method of Claim 45, further comprising the step of: providing a trading cart to allow said first user to submit said proposal.

56. The method of Claim 44, further comprising the step of: providing a user feedback mechanism for allowing users to communicate feedback.

57. The method of Claim 44, further comprising the step of: providing a storage to store relevant data for efficiency purposes.

58. The method of Claim 57, wherein data stored comprises, but is not limited to said lists of items available for transfer, proposals, said users, and trading carts.

59. The method of Claim 55, wherein said trading cart comprises: a list of haves, wherein said list of haves is required and specifies items said first user is offering; a list of wants specifying items said first user desires to own, and an accept proposal indicator for said first user to indicate interest in receiving said proposal, wherein for each have of said list of haves said first user must specify either said list of wants and/or said accept proposal indicator.

60. The method of Claim 59, further comprising the steps of: said first user adding a new item to said list of haves by posting said item; and said first user adding a new item to said list of wants by browsing items available for transfer.

61. A multiparty trading system for conducting and facilitating trade between multiple trading parties comprising both a seeded version having seeded items and an unseeded version, wherein said seeded version uses said system to close a trading chain, and wherein said unseeded version has chains that close upon themselves.

62. The system of Claim 61 , wherein said seeded items are used as an initial set of items in said system.

63. The system of Claim 61 , wherein some or all of said seeded items are used as a short term solution to increase user interest level by providing said some or all of said seeded items as more attractive items to users.

64. The system of Claim 63, wherein said system alternately toggles between said seeded version when wanting to increase said user interest level, and said unseeded version when wanting said chains to close upon themselves.

65. A method for a multiparty trading system to allow a broker to make proposals on behalf of customers used for trading transactions, comprising the steps of: receiving proposals from said broker, wherein said proposals are from gathered trading information, said gathered trading information communicated to said broker from said customers; storing said proposals in a database; an algorithm receiving from said database said proposals and optimization parameters; said algorithm using said proposals and said parameters to create reports for said transactions.

66. The method of Claim 65, wherein said users and said broker communicate by means of telephone, email, facsimile, and the like.

67. The method of Claim 65, wherein proposals further comprise want items and have items, wherein said want items represent items customers wants and said have items represent items customers have.

68. The method of Claim 65, wherein said algorithm further comprises proprietary optimization functionality.

69. The method of Claim 65, wherein said transaction reports show chains and further comprise trading maps.

70. A method for a multiparty trading system, said system having a pool of items, for allowing users to make many-for-one and one-for-many trades, comprising the step of: fulfilling a request of a first trading party by said first trading party offering one or more items from said pool and by receiving for said one or more offered items one or more acceptable items from said pool.

71. The method of Claim 70, further comprising a many-for-one trade wherein said first trading party offers two or more items from said pool for only one different item from said pool.

72. The method of Claim 70, further comprising a one-for-many trade wherein said first trading party offers one item from said pool for two or more different items from said pool.

73. The method of Claim 71 , wherein said many-for-one trade is satisfied by having a one-for-many trade within an associated chain.

74. The method of Claim 71 , wherein said many-for-one is satisfied by using only one of said two or more items and placing remaining items of said two or more items in a pool for reserved items.

75. The method of Claim 72, wherein a one-for-many trade is satisfied by having a many-for-one trade within an associated chain.

76. The method of Claim 72, wherein said one-for-many trade is satisfied by using an item from a pool of reserved items.

77. A proprietary optimization method having variables, said method for achieving a minimum average net profit per tradable item while maximizing an overall profit from a pool of possible transactions in a multiparty trading system, wherein said variables are defined as:

PMINi = the minimum average net profit per item I; PAi = the average net profit per item; PM = the value of an item the system gives up in a trade; PO = the value of an item the system accepts in a trade; PD = PM-PO, which is < 0 if a user trades something of greater value for something of less value from system, and wherein said value captures a difference in value due to, but not limited to, quality, type of items, etc.; S = shipping and handling cost per transaction;

G = the number of user parties in a string of transactions, not including said system;

C = cost per transaction to the system = PD + S; Ri = trading fee per trade for item i;

Wi = weighted average cost per trade for item i = (Ri ^* C)/(sum of all Ri in a transaction); PT = profit per transaction = (sum of all Ri in a transaction) - C;

PAi = average net profit per item traded = Ri - Wi; TQ = a qualified transaction, said transaction wherein every PAi >= PMINi for every item in the transaction; and

PTMAX = maximum PT among all TQ when said method is applied; and wherein said method uses some or all of said defined variables, and comprising the steps of: determining a set of TQs from all possible transactions from a given pool of possible transactions; selecting from said set of TQs a transaction with the largest PT, said transaction to execute successfully, wherein in the case of a tie, a transaction with the largest value of G is selected to maximize the number of trades; removing items in said selected transaction from a pool of items; and repeating said steps herein above until no qualified trades exist.

78. The method of Claim 77, wherein said method is invoked periodically.

79. The method of Claim 77, wherein PMINi is highly correlated to minimum chain length, thereby adjusting PMINi adjusts minimum chain length and adjusts number of trades that are executed.

80. The method of Claim 79, wherein given a homogeneous set of tradable items, Ri, Pi, and C are constant, and the minimum value of G for a given Pi is equal to C/(Ri-PMINi) rounded up to the nearest positive integer, wherein the minimum is 1 if a system item is traded.

81. The method of Claim 79, wherein C, amortized over all trades in a transaction, said transaction weighted by a trading fee for each item, must be less than said trading fee per trade, thereby making said transaction profitable, and wherein larger values of G allow cost due to C to be amortized over larger numbers of trades.

82. The method of Claim 79, wherein when said system is not in said transaction, C = 0, the minimum value of G = 2, and said trade is profitable to said system assuming Ri > 0.

83. The method of Claim 77, a value difference or a quality difference between two tradable items is accounted for by using the value of PD, whereby setting PD substantially large prevents an associated transaction.

84. The method of Claim 77, wherein values of said items are based on, but not limited to, type and condition of said items.

85. The method of Claim 77, wherein Ri is a percentage of a perceived value of said item.

86. The method of Claim 77, wherein Ri is a function of total costs in using said system to trade.

87. The method of Claim 77, wherein each type of item or trading bin has its own PMINi, and PMINi is not set larger than Ri, and is set considerably lower than Ri to account for fixed costs due to C.

88. The method of Claim 77, wherein items in said transaction are assumed homogeneous, and PMINi is set equal to Ri - C/Gmin, wherein Gmin is minimum chain length desired over which to amortize the cost of C.

89. The method of Claim 77, wherein PMINi is set to a negative number during an introductory period of an associated service to maximize said number of trades and to provide good user experience, whereby said PMINi becomes a maximum cost per trade to said system and thereby part of customer acquisition cost.

90. The method of Claim 89, wherein said system automatically keeps a running total of said maximum costs to ensure said total doesn't exceed a certain budget.