WO2000008578A1 - Procede et appareil relatifs a un systeme universel de conception et de mise en oeuvre de marches d'echanges - Google Patents

Procede et appareil relatifs a un systeme universel de conception et de mise en oeuvre de marches d'echanges Download PDF

Info

Publication number
WO2000008578A1
WO2000008578A1 PCT/US1999/017248 US9917248W WO0008578A1 WO 2000008578 A1 WO2000008578 A1 WO 2000008578A1 US 9917248 W US9917248 W US 9917248W WO 0008578 A1 WO0008578 A1 WO 0008578A1
Authority
WO
WIPO (PCT)
Prior art keywords
auction
bid
market
programmable
universal
Prior art date
Application number
PCT/US1999/017248
Other languages
English (en)
Inventor
Yoav Shoham
Michael Wellman
Eithan Ephrati
Original Assignee
Trading Dynamics, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/131,048 external-priority patent/US6285989B1/en
Application filed by Trading Dynamics, Inc. filed Critical Trading Dynamics, Inc.
Priority to CA002349913A priority Critical patent/CA2349913A1/fr
Priority to AU52433/99A priority patent/AU5243399A/en
Priority to EP99937641A priority patent/EP1101180A4/fr
Priority to KR1020017001663A priority patent/KR20010079626A/ko
Priority to BR9912851-9A priority patent/BR9912851A/pt
Priority to JP2000564145A priority patent/JP2002526820A/ja
Publication of WO2000008578A1 publication Critical patent/WO2000008578A1/fr

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
    • G06Q30/08—Auctions
    • 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 the use of networked computer systems for the design and deployment of a trading market. More specifically, the invention relates to an auction engine organized around modular components representing dimensions of auction specifications.
  • Onsale.com, eBay.com, and Priceline.com are representative of such auctions.
  • Onsale, Inc. and Priceline, Inc. used customized software specific to their particular auction rules. This software is not easily modified or deployed in a different business context.
  • Toolkits embodied in software offered by Opensite and Bonsai may be used to construct and operate simple auctions. But customization of an auction by these tool kits is limited. For example, a market designer may specify the duration of the auction or select a simple auction format; however, other variables in establishing an auction may not be modified without significant labor.
  • IBM has developed an auction toolkit that allows a somewhat greater degree of customization of an auction through subclassing of elements from a library of software objects, it is not a comprehensive market design and deployment system. Additionally, this system is limited to single-unit buyer-only auctions.
  • Moai, Inc. has software that typifies products that are not auction products; rather, Moai provides software solutions that embody auction technology. Moai builds software for creating Internet auctioning solutions for manufacturers or resellers to sell surplus-goods and excess inventories. Although Moai's software solution may be tailored to meet the needs of a customer, the auction style and mechanism are limited to a specific auction type.
  • the Michigan Internet AuctionBot another Internet service, allows a party to create and manage an auction (e.g., accept bids, notify bidders of auction results, etc.).
  • AuctionBot supports a broader set of auctions than other services, it has limitations. In particular, AuctionBot cannot support activity rules of the sort encountered in industrial markets such as the FCC spectrum auction and the California Power Exchange. Nor does it provide a modular architecture for extending the range of configurability of the system.
  • a market designer of an Internet auction has two options—develop software or use limited toolkits. Therefore, it is desirable to have a means with which to define and deploy a wide range of Internet auction markets without engaging in lengthy software development.
  • One embodiment of the invention relates to a universal auction specification system having a programmable auction server.
  • the programmable auction server has a plurality of auction specification modules wherein at least one auction specification module corresponds to at least one function of an auction variable selected from the group consisting of a process bid, release information, and a clear.
  • at least one auction specification module corresponds to at least one function of an auction variable selected from the group consisting of a process bid, release information, and a clear.
  • Figure 1 A is a system block diagram showing the components of the preferred embodiment.
  • Figure IB is a diagram showing the programmable auction server of the system.
  • FIGS 2 and 3 schematically show one embodiment of the invention wherein a bid is received and is verified.
  • FIG. 4 shows data flow of one embodiment of the invention.
  • Figure 5 illustrates a three-tier specific embodiment of the present invention.
  • One embodiment of the invention relates to a universal auction specification system having a programmable auction server (PAS).
  • the programmable auction server has a plurality of auction specification modules wherein at least one auction specification module corresponds to at least one of the following auction functions: processing a bid, releasing auction information, and clearing the auction.
  • FIGS 1 A through IB show various embodiments of the invention in which a universal auction specification system of the invention may include a variety of components such as a Market Specification Console ("MSC”) 110, a Universal Trading Console (“UTC”) 120, a Universal Surveillance Console (“USC”) 130, a Market Administration Console (“MAC”) 150, PAS 140, and a communication network 160 and 161 linking various components.
  • MSC Market Specification Console
  • UTC Universal Trading Console
  • USB Universal Surveillance Console
  • MAC Market Administration Console
  • PAS 140 Public Access Security
  • communication network 160 and 161 linking various components.
  • These components may be stored or operated in a single computer system or in a plurality of computer systems connected by a network.
  • MSC 110 consists of a computer running a computer program in which a market designer may specify any of an infinite number of possible market protocols. Thereafter, the market defined by market protocols is submitted or uploaded to a PAS 140 for execution. Markets may be as simple as English or Dutch auctions with some parameters designated by a market designer. Alternatively, a market designer may develop an arbitrary auction that uses very complex computations.
  • phases are identified and sequencing relations (e.g., termination conditions, conditional branching among the phases, etc.) are designated by manipulating representations of the phases on the Graphical User Interface (GUI) of the MSC 110.
  • GUI Graphical User Interface
  • a phase may be defined by a time period, a limitation, a condition (e.g. condition precedent, condition concurrent, condition subsequent, etc.), exception, exclusion, or a proviso etc.
  • the market designer may designate criteria such as when the phase terminates (e.g., a specified time period, condition such as the first one hundred bids received, etc.), the method to choose a succeeding phase (if any), and any other applicable limitations.
  • MSC 110 provides menus and other means for choosing options and may provide guidance to the market designer regarding legal combinations of these options, or recommend choices associated with specified design goals.
  • UTC 120 consists of a computer running a computer program that enables a trader (e.g., seller, buyer, agent of a seller or buyer) to trade in any market protocol executing on the PAS 140.
  • UTC 120 presents information to the trader in a manner that automatically adapts to a specific market protocol that is executing.
  • USC 130 consists of a computer running a computer program that enables a surveillance body such as a regulatory agency or an independent audit firm to monitor the operation of the markets executing on the PAS 140. This function allows the surveillance body to determine whether the execution of an auction conforms to norms and, optionally, to intervene in the market when deviations are detected.
  • a surveillance body such as a regulatory agency or an independent audit firm to monitor the operation of the markets executing on the PAS 140. This function allows the surveillance body to determine whether the execution of an auction conforms to norms and, optionally, to intervene in the market when deviations are detected.
  • MAC 150 consists of a computer running a computer program that enables a market operator, an entity housing the PAS 140 and responsible for the operation of the PAS, to monitor the execution of various markets operating on the PAS 140. MAC 150 also administers registration transactions, such as the process whereby traders identify themselves to the system (e.g., providing their names and credentials). Additionally, MAC 150 allows market operators to troubleshoot the system in real time.
  • PAS 140 includes a computer that runs a computer program that may accept multiple market protocols submitted to it from an MSC 110 and execute multiple market protocols (e.g., opening auctions, admitting or rejecting bids, clearing prices, notifying traders of market events, and closing auctions). More specifically, PAS 140 employs several modules to control the market operation. Modules such as bid verifier, release information manager, and clearer assist in managing the market by processing incoming bids, responding to queries, maintaining market state (e.g., tracking bids, etc.), and reporting results to traders and optionally to non-traders. Through these modules, various transactions may be performed such as bid verification (e.g.
  • MSC 110 makes available to a market designer a full spectrum of rules for defining market protocols in an intuitive fashion. These rules may be modified by the market designer. Combinations of rules for participating in and operating a market constitute market protocols. Market protocols specifiable through MSC range from simple auctions such as English, Dutch, and sealed-bid auctions, to highly complex auctions such as those conducted on the trading floors of financial exchanges and the California Power Exchange.
  • Table 1 provides examples of some types of auctions that could be specified through MSC 110 for deployment in PAS 140. As shown below, auction types may be arranged in a hierarchy, which the market designer would use as part of the market specification process. Note that the partial hierarchy depicted is but one of many possible arrangements.
  • Table 1 shows multiple classes of auctions.
  • the table includes auctions for one good or multiple goods. Single goods may be auctioned by one-sided or two-sided auctions.
  • types of one-sided auction are English, Dutch, and sealed-bid auctions.
  • the English auction (in the case where buyers bid) operates in the typical fashion wherein Trader A makes a bid on a good. Trader B would then make a bid that is higher than the bid submitted by Trader A. The highest bidder prevails in the buy-side English auction.
  • prices start at a high level and decrease until a trader submits a bid.
  • the sealed-bid auction involves collects bids from traders and withholds information until the end. At clearing time, the best bids prevail.
  • Two-sided auctions represent another class of auction. In two-sided auctions, both buyers and sellers submit bids.
  • One example of this class is the continuous double auction.
  • a continuous double auction collects offers from buyers and sellers. If an offer to buy and an offer to sell match, a trade is consummated.
  • a call market operates similarly, except that bids are aggregated over time, and matched in a periodic manner. Trades typically occur at a uniform price consistent with all of the matched bids.
  • multiple goods may be auctioned. This involves multiple goods offered by a single company, a government agency, or some other entity. Simultaneous ascending price auctions involve multiple ongoing auctions for different goods. Combinatorial (bundle bidding) auctions involve traders bidding for combinations goods such as a trader submitting bids for the bundle consisting of good A, good B, and good C.
  • a market designer may define a market in one of two ways.
  • One method is to select a market protocol that has been predefined in parameterized form, and input the values of its free parameters. For example, a market designer may specify the minimum increment and start time in an English auction.
  • the other method is to allow a market designer to define arbitrary market protocols suited to any given situation.
  • Every auction is associated with a set of entities that are allowed to participate, called traders.
  • Traders participate in markets by submitting bids, which are offers to buy or sell the auction's goods at specified terms (e.g., prices and quantities dictated in the bid).
  • bids which are offers to buy or sell the auction's goods at specified terms (e.g., prices and quantities dictated in the bid).
  • specified terms e.g., prices and quantities dictated in the bid.
  • the auction clears and the resulting exchanges are determined. The auction closes when a termination condition is met.
  • TPs that represent particular choices for features of a market protocol, applicable across a range of auction types. For example, one TP might specify whether an auction is one-sided (e.g., buyer or seller bid), two-sided (e.g., buyer and seller bid), a sealed-bid or "open outcry" (e.g., bids are exposed to all traders). TPs may also dictate when important events, such as clears or information releases, are to occur. Further examples of TPs and how they are used to specify auction behavior are presented in the section describing the PAS 140 below.
  • Each phase of an auction is thus defined by specifying the TPs it comprises or the timeline for application of the TPs.
  • One general method of specifying a time line is to invoke a scripting language that has control constructs for sequencing and iteration, access to internal auction events and a time-of-day clock, and the capability to call the TPs.
  • This role may be filled by a specially designed auction scripting language, a standard scripting language such as TCL/TK, JavaScript, a full-fledged programming language such as Java, any other scripting, or any programming languages.
  • the preferred embodiment of the invention utilizes a script generator 121 to generate scripts in a language generically referred to as CommerceScript.
  • ComrnerceScript is a temporal protocol script that represents an auction specification.
  • the temporal nature of CommerceScript provides an additional level of convenience in market specification. Rather than restrict the market designer to textual scripting, the invention presents to the market designer a visual scripting option.
  • This visual scripting option allows the market designer to graphically draw a time line and place along the time line various TPs.
  • Each TP may be annotated with a variety of information such as the market entity executing the TP, whether this execution is mandatory or permissible, whether conditions must precede or occur after this step and temporal preconditions that must be met.
  • the output of the visual specification component is similar to that of a textual specification component.
  • PAS 140 is extensible and flexible. PAS comprises an interpreter for CommerceScript, and modules implementing the behaviors dictated by the TPs referenced in the script. In principle, there is no bound on the range of allowable market protocols, other than the pragmatic limitations of the PAS 140 in terms of computer memory and other computational resources.
  • a market protocol may accord to distinct market entities various permissions to perform activities such as bidding in certain ways or retrieving certain forms of information. Such permissions are based on registered trader and auction attributes as captured by the MAC 150 registration process.
  • One feature of the PAS 140 is its generic way of handling permissions regardless of the particular market protocol that is executed. Each step in the execution of the protocol is gated by the type of market activity, its particular instantiation (i.e., the value of specified inputs), and the entity attempting to execute it. Flexibility permission management offered by the invention is important in industrial applications that generally require security measures such as defenses against malicious infiltrators and incompetent market entities.
  • the PAS 140 creates an audit trail by logging every activity that takes place on the system, including bids, other trader actions, market clear results, and other similar actions.
  • a trade management module records trades and the obligations incurred by each participant. For example, the trade management module may record that Trader A, a buyer, submitted a bid of $100 for a good such as a book. Because this bid reflects the highest bid received, Seller B sold his book for $100 to buyer A. Trade management module will record that buyer A is obligated to pay Seller B $100 in exchange for Seller B's book.
  • PAS 140 is comprised of several modules that may be added or customized for different market protocols. These modules, discussed below, implement market functions based on TPs specified by the market designer. PAS 140 uses script interpreter 141 to execute the market protocol, and provides application program interface 510 and proxy bidder 509 for extensibility and connection with other auction system components.
  • PAS 140 uses a generic script interpreter 141 that is capable of recognizing and interpreting CommerceScript, other type of script, or any programming language. Additionally, script interpreter 141 may be modified to adapt to new scripting languages.
  • Bid verifier 151 tests each incoming bid for consistency with the bidding rules established by a market designer.
  • a "bid" is defined as an expression of an action that may modify a bid state. Bids include a variety of actions such as a buyer indicating a willingness to purchase a good at a certain price, or a withdrawal of a previous bid. Changing a bid qualifies as a new bid. If verified as an eligible bid, the bid is admitted to an order book; otherwise, the bid is rejected.
  • bidding rules There are many possible varieties of bidding rules that may be specified in TPs through the MSC 110. Examples of bidding rules provided below are for illustrative purposes only.
  • bid verifier 151 operates such that the incoming bid is compared to a bid referred to as a base bid.
  • the base bid may refer to the trader's own bid, to all bids, or to some summary (e.g., a price quote), as determined through applying the bid rules. For example, assume a bidding rule requires that in order for a bid to be eligible, a bid must meet the following requirement: bid • highest bid received + x wherein x equals $20 and the highest bid received is assumed to be $100 and it is the highest bid received for that auction at a certain period of time. The highest bid represents the base bid. In this example, the base bid is replaced with a higher bid. The higher bid is then referred to as the base bid. The incoming bid must be at least $120 to be entered into the order book.
  • bidding rule may restrict the type of traders who are eligible to bid or it may restrict the bids that different traders may submit. Bidding rules may also regulate whether withdrawals or replacement of a bid are allowed. Limits may also be placed on the frequency of such actions, or of bids in general. Any bidding rule may be designated by a market designer to apply over the entire course of the auction or for designated periods (e.g., stages or rounds). Dynamic bidding rules based upon bid content may also be used. For example, ascending (or descending) restrictions dictate that replacement bids must exceed or be exceeded by some base bid, as discussed above. These restrictions may apply to only one side of a trade or to both buying or selling.
  • bidding rules may serve to define what offers are expressible. For example, they can designate whether bids may refer to only a single unit of a good versus allowing bids for multiple units. Additionally, if multiple units are allowed, the bidding rules may designate that offers may include single price points, multiple price points, or only quantities at a given price. Other examples of expressivity restrictions include discrete offers versus continuous offers, price-quantity monotonicity, divisibility (all-or-none bidding), interpolations/extrapolations, etc.
  • Expressible bid conditions also may be used in bidding rules to restrict bids in an auction.
  • expressible bid conditions include minimum quantities of a good to be bid upon or a minimum bid amount that must be satisfied.
  • combinations may be deemed permissible in bundles.
  • "Portfolio" bidding may also be acceptable. Maximal complexity of bundle constraint specification may also be included.
  • Bidding rules regarding eligibility also may be specified. Eligibility of a trader or a particular bid may be specified in a variety of ways. For example, the eligibility of a trader or a bid may be specified in terms of previous auction history, including the history of auctions distinct from but related to the auction in question. This is typically the case for restrictions referred to as activity rules that are common in complex auction scenarios.
  • Bidding rules may also involve payments, such as a fee paid in order to allow a participant to engage in trading. For example, an initial bid may require an entry fee (refundable or not refundable), or withdrawals may be allowed on payment of a decommitment penalty.
  • a "bid state" is created.
  • a "bid state” is the status of the bids from the various traders. The status of bids is maintained in a fashion that is known in the art.
  • a bid state also may include historical data of the various bids. For example, a graphical representation of bids may be displayed to traders on a trade interface displayed to traders. Through the trader interface, a trader is capable of inputting and receiving information from the universal auction system. Information may be communicated to the universal auction system through a keyboard, a touch screen display, or voice activated system.
  • a bid transformer 155 implements discriminating allocation market protocols that may produce different effective prices. Discriminating allocation market protocols may be based upon the identity of the trader ("trader identity") submitting the bid, the quantities allocated to a trader identity, or any other condition that the market designer designates. Trader identity may be associated with individual traders or established groups (e.g., certified dealers, registered clients, holders of particular credit ratings).
  • each submitted bid is subjected to a bid transformer 155 that applies a discriminating policy to a bid. For example, if a particular trader such as Trader A is entitled to a discount of 20%, its offered price is increased by an amount such that reduction by 20% equals the original bid. Accordingly, a bid of $10 by Trader A is transformed to $12.50. This transformed bid of $12.50 is then compared to the bids received by other traders.
  • Another example relates to offered prices for quantities of goods (or services such as amounts of specified tasks) above a certain threshold amount. Quantities of goods may be assessed a "penalty" percentage to bias the allocation toward a trader(s). After the bids are transformed by bid transformer 155, the transformed bids are sent to the bid verifier 151.
  • One alternative method to the preferred method involves implementing a discriminating allocation policy using the clearer 154.
  • bids are not transformed.
  • the clearing calculation is modified to implement the discriminating allocation policy. For example, if the discriminating allocation policy dictates that no trader should receive more than half of the allocated quantity, the clearing algorithm would maximize its objective measure subject to the constraint that this quota is not exceeded.
  • Information manager 152 controls the information released by the auction to participants during the course of bidding. In effect, it dictates the class of queries regarding bid state and bidding and trading history that an auction may handle. Unhandled queries produce null responses.
  • Mechanisms may distinguish between information available through active and passive means.
  • Traders may actively request released information through explicit queries. Information is released to passive access by defining a price quote operation.
  • a price quote is a particular form of auction status summary that typically specifies a result of a hypothetical clear, but may also specify any other salient information (e.g., the highest buy bid received).
  • a price quote may be computed at a release time and cached so that information may be made available without querying and explicit queries do not induce a complex calculation.
  • one form of price quote is a "bid-ask spread" that may degenerate into a single price.
  • a bid quote represents a price at or below which an agent would have to offer to sell in order to successfully sell (assuming no other changes occur to the auction state).
  • An ask quote represents a corresponding price with respect to an ask quote.
  • Auctions may define multiple price quote operations to be employed in different situations or for different classes of traders, where class may be characterized in terms of trader identity or bid status.
  • the market designer defines the behavior of information manager 152 by selecting TPs (through MSC 110) specifying the content and timing of price quotes, as well as the class of explicit queries to be handled. Like other auction events, information releases may be timed according to fixed schedules or by events (e.g. clears, bids, inactivity intervals, etc.)
  • the information manager 152 may also control release of other relevant auction state information.
  • the auction state may include the eligibility of traders to make additional bids, or other market information that may affect trader's expectations.
  • the information release policy implemented by information manager 152 can have a significant influence on the nature of the auction. Moreover, at one extreme, all information about the bid state information may be revealed, as in an outcry auction. However, at the other extreme, if a sealed-bid auction is used, no information is revealed about other traders' bids.
  • Order Book/Clearer 154 (“clearer”) determines an allocation of goods and terms of exchange on the basis of bidding history and auction rules. An allocation typically corresponds to a set of trades among the auction participants. Once the trades are determined, it reports the results to traders and, optionally, non-traders. Clearer 154 uses the bid state as represented by the order book to derive the exchanges determined by auction rules in a given state. It may also invoke a trade manager module to control the notification and execution of these trades.
  • Clearer 154 is invoked according to the temporal flow TPs specified in the MSC. Other TPs dictate how it determines an allocation.
  • An allocation policy may be specified by naming the algorithm implementing the function from the auction state to allocations, or by defining a complete set of criteria for selecting among the possible allocations (e.g., allocations consistent with the offers represented by bids).
  • Clearer 154 may use a general class of allocation policies that may be defined by interpreting the offers specified in bids as if they represent value functions, and maximizing the resulting surplus. However, this maximization is generally not unique because monetary transfers are zero-sum operations. Thus, the rules may need to specify how to allocate surplus among traders. For example, in a sealed-bid auction of a single unit of a good, the lst-price auction maximizes total surplus and then allocates as much as possible to the seller. The 2nd-price auction allocates as much of the surplus to buyers. A k-double auction may divide this surplus fractionally according to parameter k. Typically, even these rules are not unambiguous, since there may be a choice among buyers (or sellers) to allocate a positive surplus. Methods for choosing among surplus- equivalent bids might be based on features such as time of bid, quantities, or even random selection. Such criteria are often referred to as tie-breaking rules.
  • Clearer 154 may use another type of clearing policy that determines exchanges based upon chronological priority. For example, the continuous double auction ("CD A") matches buyers and sellers instantaneously upon receiving compatible offers. The release of information about the exchange may be delayed. In contrast, a call market aggregates bids over time before determining an allocation. As the clearing interval of a call market is reduced, an approximate CDA is determined. Clearer 154 may use discriminatory or non-uniform-price auctions that may allocate identical goods to traders at different prices. For example, in pay- your-bid auctions, successful traders on one side exchange for exactly the amount they bid, regardless of terms for other successful traders.
  • CD A continuous double auction
  • Clearer 154 may use discriminatory or non-uniform-price auctions that may allocate identical goods to traders at different prices. For example, in pay- your-bid auctions, successful traders on one side exchange for exactly the amount they bid, regardless of terms for other successful traders.
  • the invention is capable of realizing each by allowing a market designer to specify an available TP or integrate an entirely new component into PAS 140 to supplement the policy.
  • Bids submitted by a trader may be entered by direct bidding or proxy bidding.
  • direct bidding the bidder selects an auction and enters a bid using the computer keyboard and mouse (interface provided by UTC 120).
  • proxy bidding the user defines a script that bids on his or her behalf in one or more auctions running on the PAS 140.
  • a trader also specifies whether the script is to run within the trader console UTC 120 (e.g., proxy bidder 508), or be transmitted to the PAS 140 and run there (e.g., proxy bidder 509).
  • the proxy bidder 509 may be further optimized to exploit the fact that it is running within the PAS. Specifically, when there are proxy bids from multiple traders, the proxy bidder 509 may resolve the competition among these bids directly, avoiding the need to iteratively submit progressively increasing bids to the order book.
  • PAS 140 has a set of Application Program Interfaces ("APIs") 510 that provide a means for extending the PAS to incorporate replacement or additional modules.
  • APIs Application Program Interfaces
  • the purpose of the APIs is to turn a closed system to an open system.
  • a closed system requires that the system be used in total or forego using the closed system.
  • components may be integrated seamlessly with existing components.
  • APIs allow integration of PAS 140 with (1) legacy software for registration or transaction management; (2) auditing or monitoring functions of accreditation agencies, (3) programs implementing novel clearing algorithms, and (4) programs performing trades which bypass the UTC 120 discussed below.
  • the Universal Trading Console (UTC)
  • the UTC 120 has at least two functions—display of information and bid input.
  • Examples of information displayed to a user include activities on the PAS 140 and ancillary information.
  • PAS 140 activities are, in principle, events logged by the PAS 140, such as the start of an auction, the bids placed, and the prices cleared.
  • Actual information displayed may vary from one market to another, reflecting the different market designs.
  • the amount of information displayed may vary.
  • two simultaneous ascending-bid auctions may vary the information disclosure policy with one auction releasing information after each round such as the entire list of bidders and their bid in that round, whereas another auction may release only the aggregate bids supplied with no bidder-specific information.
  • Ancillary information may be any information that is relevant to making trade decisions but that is not inherent in the market activity. For example, in energy markets and many other futures markets weather forecasts may be important information to a trader.
  • FIGS 2 and 3 schematically show one embodiment of the invention in which several of the modules are shown.
  • a bid (e.g. $100) is submitted by Trader A at operation 600.
  • the bid is sent to the bid verifier 151 at operation 610.
  • Bid verifier 151 receives the bid and uses the bid by incorporating the bid in the TPs set by the market designer.
  • the bid verifier determines whether the bid is acceptable. If the bid satisfies the minimum standards for an acceptable bid established by the market designer, the bid is verified as an acceptable bid and is placed into the order book/clearer 154 at operation 640. If the bid fails to meet these minimum standards, the bid is rejected and Trader A is notified that his bid is unacceptable.
  • Information manager 152 notifies Trader A by transmitting the rejection to Trader A at operation 625.
  • proxy bidder 509 may also submit a bid to the bid verifier 151. This bid undergoes the same process as listed above. The trader(s) who submitted the proxy bid is notified through the information manager 152 as to whether the proxy bid is acceptable or is unacceptable.
  • USB Universal Surveillance Console
  • the system of the present invention is designed to adapt to the needs of a variety of different types of trading markets. Operating on a wide range of hardware, from single-user personal computers (PCs) to integrated client/server based platforms, the system of the present invention is well suited to a small number of users and to a market with thousands of users. The system may be field-modified to handle an increasing number of users as market requirements mature and change.
  • PCs personal computers
  • client/server based platforms the system of the present invention is well suited to a small number of users and to a market with thousands of users.
  • the system may be field-modified to handle an increasing number of users as market requirements mature and change.
  • FIG. 4 shows data flow of one embodiment of the invention.
  • a market 700 comprises an auction 710. Although a market may include a plurality of phases, only one phase is shown in operation 720. With respect to a plurality of phases, one skilled in the art will appreciate that an auction specification of one phase may be replaced with an auction specification of another phase by methods known in the art.
  • a bid, submitted by a trader is sent to the bid verifier at operation 730. The bid verifier determines whether the bid meets certain rules that are specified by a market designer or another party who may control an aspect of the auction. Thereafter, an admitted bid is sent to the bid transformer at operation 740.
  • the bid is modified to reflect discrimination policies wherein the bid may be increased, decreased, or some other modification in order to reflect a status that has been granted to that particular trader or to a particular good.
  • the bid is processed wherein rules are applied to the accepted bids and the best bid prevails. Note that the best bid may not necessarily be the highest bid; rather, it is the bid that reflects the discrimination allocation policies that are applied.
  • the bid is then submitted to the order book at operation 760.
  • tie breaking rules may be applied, sort criteria may be used, and any other criteria designated by the market designer may be implemented.
  • the bid is submitted to the clearer wherein a clearing operation is applied.
  • the bids are submitted to the trade manager for further processing.
  • Information manager is continuously operating and may be providing information to traders on a continuous basis at operation 790.
  • FIG. 5 shows one embodiment of the invention wherein a three-tiered architecture supports scalability allowing other system architectures to be implemented.
  • a first tier 110 includes a front-end database 112 and Web applications running on Web server(s) 111 that constitute the interface between the users 114 and the back-end 116 of the system.
  • Authorized users may access the system through a Web browser.
  • GUI may be run either as a Java Applet or as a common HTML (depending on the user's choice and browser version). Java and HTML programming languages are well known to those of ordinary skill in the art.
  • the Web application is surrounded by a firewall 122 in a DMZ (Demilitarized Zone) configuration making it almost impossible to penetrate the application server(s) 120.
  • DMZ Demilitarized Zone
  • the application's logic constitutes the second tier 115.
  • the middleware 130 environment is component-based allowing high-availability and scalability.
  • the third tier 133 contains the database 136 and the interface 138 to a market administrator's legacy systems. Note that because the output of the auctioning process is being polled by a legacy system, the full security of the legacy environment is assured at all times.

Abstract

L'invention porte sur un système universel de spécification de ventes comportant un ensemble accessible par réseau de données initiales de transactions (TPs) et un pupitre de spécifications relatives au marché (110) incluant un générateur (121) transformant l'ensemble de données initiales de transactions (TPs) en un scénario de protocole temporel représentant une spécification particulière de vente. Le système comporte de plus un serveur programmable de vente (140) présentant plusieurs modules pouvant contenir chacun un TP.
PCT/US1999/017248 1998-08-07 1999-07-29 Procede et appareil relatifs a un systeme universel de conception et de mise en oeuvre de marches d'echanges WO2000008578A1 (fr)

Priority Applications (6)

Application Number Priority Date Filing Date Title
CA002349913A CA2349913A1 (fr) 1998-08-07 1999-07-29 Procede et appareil relatifs a un systeme universel de conception et de mise en oeuvre de marches d'echanges
AU52433/99A AU5243399A (en) 1998-08-07 1999-07-29 A method and an apparatus for a universal trading market design and deployment system
EP99937641A EP1101180A4 (fr) 1998-08-07 1999-07-29 Procede et appareil relatifs a un systeme universel de conception et de mise en oeuvre de marches d'echanges
KR1020017001663A KR20010079626A (ko) 1998-08-07 1999-07-29 범용 매매 시장 설계 및 배치 시스템을 위한 방법 및 장치
BR9912851-9A BR9912851A (pt) 1998-08-07 1999-07-29 Processo e aparelho para um projeto de bolsa de negócio universal e sistema de distribuição
JP2000564145A JP2002526820A (ja) 1998-08-07 1999-07-29 総合トレーディング・マーケットを設計および展開するシステムのための方法および装置

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US09/131,048 US6285989B1 (en) 1998-08-07 1998-08-07 Universal on-line trading market design and deployment system
US09/131,048 1998-08-07
US33932599A 1999-06-23 1999-06-23
US09/339,325 1999-06-23

Publications (1)

Publication Number Publication Date
WO2000008578A1 true WO2000008578A1 (fr) 2000-02-17

Family

ID=26829089

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1999/017248 WO2000008578A1 (fr) 1998-08-07 1999-07-29 Procede et appareil relatifs a un systeme universel de conception et de mise en oeuvre de marches d'echanges

Country Status (7)

Country Link
EP (1) EP1101180A4 (fr)
JP (1) JP2002526820A (fr)
KR (1) KR20010079626A (fr)
AU (1) AU5243399A (fr)
BR (1) BR9912851A (fr)
CA (1) CA2349913A1 (fr)
WO (1) WO2000008578A1 (fr)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6266651B1 (en) * 1995-04-26 2001-07-24 Mercexchange Llc (Va) Facilitating electronic commerce through two-tiered electronic markets and auctions
JP2001250017A (ja) * 2000-03-07 2001-09-14 Ntt Data Corp 見積合わせシステムおよび端末および方法およびそのプログラムを記録した記録媒体
NL1016192C2 (nl) * 2000-09-15 2002-03-18 Onroerendgoednet Com B V Systeem voor het verkopen van een object, in het bijzonder een onroerend goed.
US6671676B1 (en) 2000-05-04 2003-12-30 Metreo Markets, Inc. Method and apparatus for analyzing and allocating resources of time-varying value using recursive lookahead
US7155410B1 (en) 1999-08-03 2006-12-26 Woodmansey Robert J Systems and methods for linking orders in electronic trading systems
US7610217B1 (en) * 1996-09-04 2009-10-27 Hitachi, Ltd. Automatic auction method and system on server-client system
US7702540B1 (en) 1995-04-26 2010-04-20 Ebay Inc. Computer-implement method and system for conducting auctions on the internet
US7711640B2 (en) 2005-12-20 2010-05-04 Bgc Partners, Inc. Methods and apparatus for composite trading order processing
US7711644B2 (en) 2005-12-20 2010-05-04 Bgc Partners, Inc. Apparatus and methods for processing composite trading orders
US8255314B2 (en) 2004-09-13 2012-08-28 Bgc Partners, Inc. Electronic completion of cash versus futures basis trades

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8601373B1 (en) 1999-11-16 2013-12-03 Ebay Inc. Network-based sales system with customizable user interface
US7860776B1 (en) 2000-10-11 2010-12-28 Ebay Inc. Sales system with buyer price selection
WO2003009105A2 (fr) 2001-07-20 2003-01-30 Fairmarket, Inc. Gestion de listage automatique

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4789928A (en) * 1986-02-17 1988-12-06 Flex Japan Inc. Auction information transmission processing
US5835896A (en) * 1996-03-29 1998-11-10 Onsale, Inc. Method and system for processing and transmitting electronic auction information
US5844554A (en) * 1996-09-17 1998-12-01 Bt Squared Technologies, Inc. Methods and systems for user interfaces and constraint handling configurations software
US5890138A (en) * 1996-08-26 1999-03-30 Bid.Com International Inc. Computer auction system
US5905975A (en) * 1996-01-04 1999-05-18 Ausubel; Lawrence M. Computer implemented methods and apparatus for auctions

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4789928A (en) * 1986-02-17 1988-12-06 Flex Japan Inc. Auction information transmission processing
US5905975A (en) * 1996-01-04 1999-05-18 Ausubel; Lawrence M. Computer implemented methods and apparatus for auctions
US5835896A (en) * 1996-03-29 1998-11-10 Onsale, Inc. Method and system for processing and transmitting electronic auction information
US5890138A (en) * 1996-08-26 1999-03-30 Bid.Com International Inc. Computer auction system
US5844554A (en) * 1996-09-17 1998-12-01 Bt Squared Technologies, Inc. Methods and systems for user interfaces and constraint handling configurations software

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP1101180A4 *

Cited By (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7937312B1 (en) 1995-04-26 2011-05-03 Ebay Inc. Facilitating electronic commerce transactions through binding offers
US7702540B1 (en) 1995-04-26 2010-04-20 Ebay Inc. Computer-implement method and system for conducting auctions on the internet
US6266651B1 (en) * 1995-04-26 2001-07-24 Mercexchange Llc (Va) Facilitating electronic commerce through two-tiered electronic markets and auctions
US7610217B1 (en) * 1996-09-04 2009-10-27 Hitachi, Ltd. Automatic auction method and system on server-client system
US7848963B2 (en) 1996-09-04 2010-12-07 Hitachi, Ltd. Automatic auction method and system on server-client system
US7155410B1 (en) 1999-08-03 2006-12-26 Woodmansey Robert J Systems and methods for linking orders in electronic trading systems
US10055787B2 (en) 1999-08-03 2018-08-21 Bgc Partners, Inc. Systems and methods for linking orders in electronic trading systems
JP2001250017A (ja) * 2000-03-07 2001-09-14 Ntt Data Corp 見積合わせシステムおよび端末および方法およびそのプログラムを記録した記録媒体
US6671676B1 (en) 2000-05-04 2003-12-30 Metreo Markets, Inc. Method and apparatus for analyzing and allocating resources of time-varying value using recursive lookahead
NL1016192C2 (nl) * 2000-09-15 2002-03-18 Onroerendgoednet Com B V Systeem voor het verkopen van een object, in het bijzonder een onroerend goed.
US8571970B2 (en) 2004-09-13 2013-10-29 Bgc Partners, Inc. Electronic completion of cash versus futures basis trades
US8255314B2 (en) 2004-09-13 2012-08-28 Bgc Partners, Inc. Electronic completion of cash versus futures basis trades
US10387955B2 (en) 2004-09-13 2019-08-20 Bgc Partners, Inc. Electronic completion of cash versus futures basis trades
US11188982B2 (en) 2004-09-13 2021-11-30 Bgc Partners, Inc. Electronic completion of cash versus futures basis trades
US7921056B2 (en) 2005-12-20 2011-04-05 Bgc Partners, Inc. Processing composite trading orders
US7873565B2 (en) 2005-12-20 2011-01-18 Bgc Partners, Inc. Composite trading order processing
US8494952B2 (en) 2005-12-20 2013-07-23 Bgc Partners, Inc. System and method for processing composite trading orders
US7711644B2 (en) 2005-12-20 2010-05-04 Bgc Partners, Inc. Apparatus and methods for processing composite trading orders
US7711640B2 (en) 2005-12-20 2010-05-04 Bgc Partners, Inc. Methods and apparatus for composite trading order processing
US10692142B2 (en) 2005-12-20 2020-06-23 Bgc Partners, Inc. System and method for processing composite trading orders

Also Published As

Publication number Publication date
BR9912851A (pt) 2001-10-09
KR20010079626A (ko) 2001-08-22
EP1101180A1 (fr) 2001-05-23
EP1101180A4 (fr) 2002-07-03
JP2002526820A (ja) 2002-08-20
CA2349913A1 (fr) 2000-02-17
AU5243399A (en) 2000-02-28

Similar Documents

Publication Publication Date Title
US20080162331A1 (en) Method and apparatus for a trading market design and deployment system
US8015073B2 (en) Increasing market efficiency of ticket supply systems
US6285989B1 (en) Universal on-line trading market design and deployment system
US8433629B2 (en) Commission management system
US20160350777A1 (en) Automated system for adapting market data and evaluating the market value of items
US7558752B1 (en) Method and an apparatus for a trading market design and deployment system
US20060031082A1 (en) System and method for trading wireless spectrum rights
US7660762B1 (en) Method and system for efficiently matching long and short positions in securities trading and transacting a series of overnight trades for balance sheet netting
US20090259576A1 (en) Transaction processing with core and distributor processor implementations
JP2009527859A (ja) スペクトル権を取引するシステム
JP2005515516A (ja) 証券の交換からの経済的利益を交換および導出する方法およびシステム
EP1332459A2 (fr) Systeme commercial en temps reel
WO2001073659A2 (fr) Systemes et procedes servant a corriger des desequilibres entre l'offre et la demande dans des echangeurs a subdivisions multiples
US7330834B1 (en) System and method for electronic trading of assets
WO2002079904A2 (fr) Appel d'offres (rfq) et demandes de marches internes
WO2002042981A1 (fr) Systeme et procede pour vente aux encheres dynamique avec soumission a forfait
EP1101180A1 (fr) Procede et appareil relatifs a un systeme universel de conception et de mise en oeuvre de marches d'echanges
Wurman Online auction site management
US7970686B1 (en) System and method of interfacing for client application programs to access a data management system
WO2003038732A2 (fr) Procede et systeme de gestion des engagements, de reduction des erreurs de mesure et de presentations sures
US20220237722A1 (en) Anonymous price and progressive display execution apparatus, system and method
US20110131126A1 (en) Trade Management System For Reducing Securities Positions
Bichler et al. Matchmaking Mechanisms for Agent-Mediated Electronic Markets
CA2367456A1 (fr) Systeme et procede servant a realiser une transaction concernant un effet d'investissement

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE 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: A1

Designated state(s): GH GM KE LS MW SD SL SZ 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)
ENP Entry into the national phase

Ref document number: 2349913

Country of ref document: CA

Ref country code: CA

Ref document number: 2349913

Kind code of ref document: A

Format of ref document f/p: F

WWE Wipo information: entry into national phase

Ref document number: 1020017001663

Country of ref document: KR

Ref document number: 1020017001648

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 1999937641

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 1999937641

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWR Wipo information: refused in national office

Ref document number: 1020017001648

Country of ref document: KR

WWW Wipo information: withdrawn in national office

Ref document number: 1020017001648

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 1020017001663

Country of ref document: KR

WWW Wipo information: withdrawn in national office

Ref document number: 1020017001663

Country of ref document: KR