WO2000072209A9 - Multiparty trading system - Google Patents
Multiparty trading systemInfo
- Publication number
- WO2000072209A9 WO2000072209A9 PCT/US2000/014069 US0014069W WO0072209A9 WO 2000072209 A9 WO2000072209 A9 WO 2000072209A9 US 0014069 W US0014069 W US 0014069W WO 0072209 A9 WO0072209 A9 WO 0072209A9
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- items
- item
- transaction
- trade
- user
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
Definitions
- 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.
- 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.
- U.S. Patent No. 5,963,923 discloses a system and method for linking a Rolling Spot Currency contract with a Principle Market Maker program.
- 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.
- 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.
- 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.
- a system that conducts and facilitates complex trades between multiple parties by matching traders with items for which the traders wish to trade.
- 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 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.
- Fig. 1a 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;
- Web World Wide Web
- 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;
- 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.
- a system that conducts and facilitates complex trades between multiple parties by matching traders with items for which the traders wish to trade.
- 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 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.
- Chain a group of potential trades.
- Chain length the number of user parties in a string of transactions.
- 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.
- 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. 1 c 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.
- 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.
- the system 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.
- 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.
- Table A The ideal objectives of the trading model are summarized in Table A, herein below.
- 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 .
- an implementation of the model should allow an administrator to select desired parameters to optimize and the desired set of constraints.
- 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.
- 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.
- 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.
- 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.
- 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.
- the transaction is not completed. That is, no transaction is made, and the algorithm is terminated.
- 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.
- 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.
- 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.
- step 3 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.
- 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.
- step 8 with a proposal that is not on the proposal list until all valid proposals have been placed on the "proposal list".
- step 13 If no completed chains exist, go to step 13. If completed chains exist, calculate optimization scores of all completed chains by invoking optimization function.
- 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.
- the transaction is not completed. That is, no transaction is made, and the algorithm is terminated.
- 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.
- 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.
- 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:
- TQ - A qualified transaction which is a transaction wherein every PAi
- the preferred algorithm is as follows:
- steps 1-3 above 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.
- 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.
- 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.
- 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.
- the minimum length of a chain is highly correlated with PMINi and can therefore be controlled by adjusting PMINi.
- the minimum value of G for a given Pi is equal to CV(Ri-PMINi) rounded up to the nearest positive integer, wherein the minimum is 1 if a system item is traded.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- An item is added to a chain when a user selects the item at the tail of the chain.
- 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 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.
- 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.
- 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.
- 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.
- 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)
- 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)
- User 3 ships an item to User 1 (222).
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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 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.
- the system handles both a seeded approach or an unseeded approach, depending on business needs.
- the system chooses the last item in order to close the chain.
- 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.
- 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.
Abstract
L'invention concerne un système qui régit et facilite des échanges complexes entre plusieurs parties en établissant une correspondance entre des négociants et des articles que ces négociants souhaitent échanger. Dans un mode de réalisation, les négociants entrent les articles qui les intéressent dans le système et identifient d'autres articles qu'ils souhaiteraient recevoir en échange dans le système. Celui-ci examine alors tous les articles entrés et toutes les préférences des négociants, c'est-à-dire ce qu'ils aimeraient recevoir en échange, puis crée un système de correspondances et de chaînes multiples entre les négociants et les articles entrés dans le système. Le système peut fermer des chaînes commerciales en remplissant la fonction d'un négociant actif, à l'aide d'articles implantés, à savoir des articles présélectionnés qui sont entrés dans le système par un opérateur système, ou peut laisser des chaînes se refermer sur elles-mêmes, cas auquel tous les négociants d'une chaîne donnée sélectionnent des articles. Les négociants peuvent demander des articles spécifiques et/ou soumettre des descriptions générales et laisser le système leur proposer des articles. Le système offre des chariots d'échange permettant aux utilisateurs de choisir les articles souhaités, une fonctionnalité d'optimisation nouvelle et exclusive, et des modèles prédictifs et non prédictifs. Il propose également des échanges </= plusieurs contre un >/= et </= un contre plusieurs >/= , et un service de courtage hors ligne, les courtiers faisant des propositions au nom des négociants et fournissant des rapports de sortie à partir du système aux négociants. Ceux-ci ont ainsi la possibilité de décider de l'exécution ou non de chaînes données.The invention relates to a system that governs and facilitates complex exchanges between several parties by establishing a correspondence between traders and articles that these traders wish to exchange. In one embodiment, traders enter the items of interest into the system and identify other items that they would like to receive in exchange in the system. This then examines all of the items entered and all of the merchants' preferences, that is, what they would like to receive in return, and then creates a system of multiple matches and chains between the merchants and the items entered in the system. The system can close trade chains by performing the function of an active trader, using implanted items, i.e. preselected items that have entered the system through a system operator, or may allow chains to close on themselves, in which case all traders in a given chain select items. Traders can request specific items and / or submit general descriptions and let the system offer them items. The system offers exchange carts allowing users to choose the desired items, a new and exclusive optimization functionality, and predictive and non-predictive models. It also offers </ = many against one> / = and </ = one against many> / = exchanges, and an offline brokerage service, with brokers making proposals on behalf of traders and providing exit reports from from system to traders. These thus have the possibility of deciding on the execution or not of given strings.
Description
Claims
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
AU51536/00A AU5153600A (en) | 1999-05-21 | 2000-05-22 | Multiparty trading system |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13523499P | 1999-05-21 | 1999-05-21 | |
US60/135,234 | 1999-05-21 |
Publications (3)
Publication Number | Publication Date |
---|---|
WO2000072209A2 WO2000072209A2 (en) | 2000-11-30 |
WO2000072209A8 WO2000072209A8 (en) | 2001-11-22 |
WO2000072209A9 true WO2000072209A9 (en) | 2002-06-20 |
Family
ID=22467162
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2000/014069 WO2000072209A2 (en) | 1999-05-21 | 2000-05-22 | Multiparty trading system |
Country Status (2)
Country | Link |
---|---|
AU (1) | AU5153600A (en) |
WO (1) | WO2000072209A2 (en) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
USRE47908E1 (en) | 1991-12-23 | 2020-03-17 | Blanding Hovenweep, Llc | Ergonomic man-machine interface incorporating adaptive pattern recognition based control system |
USRE48056E1 (en) | 1991-12-23 | 2020-06-16 | Blanding Hovenweep, Llc | Ergonomic man-machine interface incorporating adaptive pattern recognition based control system |
KR20020050669A (en) * | 2000-12-21 | 2002-06-27 | 홍승돈 | A messaging system and method based on match between sending condition and receiving condition |
-
2000
- 2000-05-22 AU AU51536/00A patent/AU5153600A/en not_active Abandoned
- 2000-05-22 WO PCT/US2000/014069 patent/WO2000072209A2/en active Application Filing
Also Published As
Publication number | Publication date |
---|---|
WO2000072209A2 (en) | 2000-11-30 |
AU5153600A (en) | 2000-12-12 |
WO2000072209A8 (en) | 2001-11-22 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20190172139A1 (en) | Method and apparatus for automated trading of equity securities using a real time data analysis | |
US8635147B2 (en) | System, method and program for agency cost estimation | |
JP5538582B2 (en) | Method and system for pricing options | |
US7177831B1 (en) | System and method for selecting and purchasing stocks via a global computer network | |
US8214283B2 (en) | Computer implemented and/or assisted methods and systems for providing rapid execution of, for example, listed options contracts using toxicity and/or profit analyzers | |
US8438068B2 (en) | Reputation in on-line consumer markets | |
AU2001292891B2 (en) | Communication network based system and method for auctioning shares on an investment product | |
US20050187858A1 (en) | Fixed income security offerings management techniques and related applications | |
US20020046154A1 (en) | Systems and methods for developing and administering investment trusts | |
US20050015323A1 (en) | Machine learning automatic order transmission system for sending self-optimized trading signals | |
Wurman | Dynamic pricing in the virtual marketplace | |
CA2396011A1 (en) | Automated batch auctions in conjunction with continuous financial markets | |
US7299204B2 (en) | System for winning investment selection using collective input and weighted trading and investing | |
US10269068B1 (en) | System and method for matching users in a wireless communication system | |
WO2007021876A2 (en) | Systems and methods for providing investment opportunities | |
US20110137787A1 (en) | Trading system and method | |
US20050049954A1 (en) | Portfolio compliance managing techniques | |
Yan et al. | Supplier's capacity investment strategy with factoring finance | |
US20040133503A1 (en) | Method and system for auctioning shares of an investment product | |
CN110678894A (en) | System for performing selections from dynamically generated electronic databases | |
AU2008262367A1 (en) | System, method and program for agency cost estimation | |
US8463675B1 (en) | System and method for operating an exchange traded fund that makes distributions from sources including capital in the fund to provide a stable or minimum distribution | |
WO2000072209A9 (en) | Multiparty trading system | |
Weber | Trade execution costs and disintermediated order crossing systems on the London Stock Exchange | |
Bitsaki et al. | An E-marketplace for Auctions and Negotiations in the Constructions Sector |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A2 Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG US UZ VN YU ZA ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A2 Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
DFPE | Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101) | ||
AK | Designated states |
Kind code of ref document: C1 Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG US UZ VN YU ZA ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: C1 Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG |
|
D17 | Declaration under article 17(2)a | ||
REG | Reference to national code |
Ref country code: DE Ref legal event code: 8642 |
|
AK | Designated states |
Kind code of ref document: C2 Designated state(s): AL AM AT AU AZ BA BB BG BR BY CA CH CN CU CZ DE DK EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT UA UG US UZ VN YU ZA ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: C2 Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG |
|
COP | Corrected version of pamphlet |
Free format text: PAGES 1/4-4/4, DRAWINGS, REPLACED BY NEW PAGES 1/4-4/4; DUE TO LATE TRANSMITTAL BY THE RECEIVING OFFICE |
|
32PN | Ep: public notification in the ep bulletin as address of the adressee cannot be established |
Free format text: COMMUNICATION PURSUANT TO RULE 69 EPC (EPO FORM 2524 OF 260203) |
|
122 | Ep: pct application non-entry in european phase | ||
NENP | Non-entry into the national phase in: |
Ref country code: JP |