A METHOD AND AN APPARATUS FOR A UNIVERSAL TRADING MARKET DESIGN AND DEPLOYMENT SYSTEM

Abstract: A universal auction specification system including a network-accessible set of trading primitives ("TPs") and a market specification console (110) that includes a script generator (121) for combining the set of TPs into a temporal protocol script representing a particular auction specification. The system further includes a programmable auction server (140) that has a plurality of modules wherein each module may have a TP.

Description: A METHOD AND AN APPARATUS FOR A UNIVERSAL TRADING MARKET DESIGN AND DEPLOYMENT SYSTEM Cross-Reference to Related Application The present application is a Continuation-In-Part of co-pending application serial no. 09/131,048 filed August 7, 1998 by applicant Yoav Shoham et al., entitled "A Universal On-Line Trading Market Design And Deployment System." FIELD OF THE INVENTION 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. BACKGROUND OF THE INVENTION Simple auctions that do not require complex computations are currently prevalent on the Internet. 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. Although 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. (Moai) 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.). Although 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. In sum, 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. SUMMARY OF THE INVENTION Methods and apparatuses for designing and deploying an interactive, realtime, universal trading market system on the Internet are disclosed. 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. Other aspects and methods of the present invention, as well as apparatuses formed using these methods, are described further below in conjunction with the following figures. BRIEF DESCRIPTION OF THE DRAWINGS 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. Figures 2 and 3 schematically show one embodiment of the invention wherein a bid is received and is verified. Figure 4 shows data flow of one embodiment of the invention. Figure 5 illustrates a three-tier specific embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT Methods and apparatuses are disclosed for designing and deploying a universal, interactive, real-time, trading market system serving traders communicating through the Internet and similar networks. This generic system for specifying and deploying trading market systems such as auctions is novel over the limited systems known in the art. 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. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be evident, however, to one of ordinary skill in the art that the present invention may be practiced without these specific details. In other instances, well known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention. Figures 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. These components may be stored or operated in a single computer system or in a plurality of computer systems connected by a network. Overview of System Modules 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. Although markets may be organized in various ways, markets generally consist of a sequence of phases. Each phase comprises an interval(s) wherein an activity is governed by a relatively fixed set of rules specified by the market designer. The temporal flow of a market consists of a series of market phases specified by the market designer. In order to specify this temporal flow, the market designer must identify the phases. 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. 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. In order to specify rules such as market rules governing a particular phase, the market designer selects options - referred to herein as trading primitives ("TPs") - that dictate the behavior of components in the PAS 140. 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. 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. does a bid from a trader qualify as a "bid" under the rules), release of information (e.g., show all the current bids), a clear (e.g. clear the prices or bids), registration of information (e.g. name and phone number of the trader), and a bid transformation. In the preferred embodiment, various components are organized into a complete system through a 3-tier architecture bounded by double firewalls 164 as shown in Figure 1A. The Market Specification Console (MSC) 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 : Example of Auction Classifications 1) Single good type a) One-sided (e.g., only buyers bid) i) English (ascending price) ii) Dutch (descending price) iii) Sealed-bid b) Two-sided (buyers and sellers bid) i) Continuous double auction ii) Call market 2) Multiple good types a) Simultaneous ascending price b) Combinatorial (bundle bidding) 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. Among the 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. In a buy-side Dutch auction, on the other hand, 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. As noted above, 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. Generally, 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. Although the number of market protocols is limitless, some universal principles apply. First, 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). As a result of the bids, some information may be released to traders about a market's status. Under conditions specified in the market protocol, the auction clears and the resulting exchanges are determined. The auction closes when a termination condition is met. Because of these universal elements, it is possible to define 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. Although various visual programming tools exist in the art, such tools have not been applied to the creation of a trading market specification. One novel aspect of the visual specification component annotation involves processing steps as "mandatory" or "permissible," which is unique to the commercial application. The Programmable Auction Server (PAS) 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. To promote fault tolerance, 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. In addition, 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. 1. Script Interpreter 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. 2. Bid Verifier 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. 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. In one embodiment, 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. Another example of a 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. In other ways, 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. For example, expressible bid conditions include minimum quantities of a good to be bid upon or a minimum bid amount that must be satisfied. In regard to multi-dimensional auctions, 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. The foregoing represents a portion of bidding rales that may be used in an auction. By executing of bidding rules such as those presented above, 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. 3. Bid Transformer 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). In the preferred embodiment, 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. In this approach, bids are not transformed. Instead, 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. 4. Information Manager 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. For single-good auctions, 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.) In addition to the bid state as reflected in the order book 154, the information manager 152 may also control release of other relevant auction state information. For example, 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. 5. Order Book/Clearer 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. Regardless of the allocation policy specified, 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. 6. Proxy Bidder Bids submitted by a trader may be entered by direct bidding or proxy bidding. In direct bidding, the bidder selects an auction and enters a bid using the computer keyboard and mouse (interface provided by UTC 120). In proxy bidding, the user defines a script that bids on his or her behalf in one or more auctions running on the PAS 140. As part of the proxy bid, 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. 7. Application Program Interfaces 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. 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. In an open system, components may be integrated seamlessly with existing components. For example, 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. In particular, the amount of information displayed may vary. For example, 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. Diversity exists in the format of both the information dissemination and the bid collection among different types of auctions. In the preferred embodiment, this diversity is accommodated by introducing a database layer between the PAS 140 and the UTC 120. For each auction type, several specific database schemas must be introduced. The PAS 140 populates the database with specific data and that data is displayed in the UTC 120 automatically using dynamic HTML. A feature of this design is that while the database tables in the PAS 140 must be created for the particular auction, the UTC 120 requires no modification. Figures 2 and 3 schematically show one embodiment of the invention in which several of the modules are shown. Here, 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. At operation 610, 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. Similarly, 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. The Universal Surveillance Console (USC) Professional trading markets are generally associated with one or more surveillance bodies such as the SEC, the FCC, FERC, California Public Utility Commission (CPUC), internal monitoring departments of exchanges, and external private audit agencies. A surveillance body monitors trading activities and ensures that trading activities comply with specified standards. Monitoring is essential to ensure that traders comply with laws or rules. Compliance with rules promotes faith in the market. USC 130 presents information from the marketplace to a surveillance agency. While the USC 130 does not provide ways in which to trade in the market, it does provide market controls that are not provided to traders. Examples of such controls are broadcasting messages that appear on UTCs 120 and halting trading activity. Three-Tier Architecture of the Preferred Embodiment 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. Figure 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. At this operation, 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. At operation 750, 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. At this operation, tie breaking rules may be applied, sort criteria may be used, and any other criteria designated by the market designer may be implemented. At operation 770, the bid is submitted to the clearer wherein a clearing operation is applied. At operation 780, 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. Figure 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. To secure the system, 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. 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. Thus, a method and apparatus for designing and deploying a universal, interactive, real-time, trading market system serving traders communicating via the Internet is disclosed. Although the present invention has been described with reference to specific exemplary embodiments, it will be apparent to those of ordinary skill in the art that various modifications and augmentations may be made to these embodiments without departing from the broader spirit and scope of the present invention as set forth in the following claims.

Claims: CLAIMS We claim: 1. A universal auction system having a programmable auction server, the programmable auction server comprising: a plurality of auction modules wherein at least one auction module corresponds to at least one function of an auction selected from the group consisting of a bid verifier, an information manager, a clearer, a registration manager, and a proxy bidder. 2. The programmable auction server as in claim 1, further comprising: auction modules wherein at least one auction specification module performs at least one transaction selected from the group comprising a bid verification transaction, an information management transaction, a clearing transaction, and a registration transaction. 3. The programmable auction server as in claim 1, further comprising: a set of trading primitives; a script interpreter for interpreting a temporal protocol script representing an auction specification, the script including references to at least a portion of the set of trading primitives; and means for switching an auction specification of one phase with an auction specification of another phase. 4. The programmable auction server as in claim 3, wherein at least one auction module of one phase is replaced with at least one auction module of another phase. 5. The programmable auction server as in claim 1, at least one phase comprising an interval in which at least one transaction occurs, the transaction is selected from the group comprising submitting a bid, admitting a bid, withdrawing a bid, and replacing a bid. 6. The programmable auction server as in claim 5, wherein the phase is terminated by a condition. 7. The programmable auction server as in claim 6, wherein the condition is a time period. 8. A universal auction system comprising: a trading primitive; a script generator for translating trading primitives to temporal protocol script; a script interpreter for interpreting script protocol; and a market specification console adapted to support a plurality of market protocols. 9. The universal auction system as in claim 8, the market specification console further comprising a plurality of rales wherein at least one rale is user- modifiable. 10. The universal auction system as in claim 9, wherein rales comprise market protocols. 11. The universal auction system as in claim 8, wherein the market specification console is coupled to a programmable auction server wherein said programmable auction server is adapted to receive market protocols from said market specification console, the market specification console having a graphic user interface (GUI). 12. The universal auction system of claim 11, wherein a trader interface is coupled to a network. 13. The universal auction system of claim 12, wherein the trader interface is used by a trader to submit a bid. 14. A market specification console comprising: means for specifying a plurality of market protocols; means for displaying at least one market protocol; and means for transmitting at least one market protocol to a programmable auction server. 15. A method of designing a universal auction system comprising: generating a plurality of auction modules wherein at least one auction module corresponds to at least one function of an auction selected from the group comprising of a bid verifier, an information manager, a clearer, and a registration manager; specifying a plurality of rales wherein a transaction comprises at least one rale; and implementing at least one transaction comprising a bid verification, information dissemination, clearing, and registration of information. 16. The method of claim 15 further comprising: displaying a rale to a market designer. 17. The method of claim 15 further comprising: modifying at least one rale. 18. The method of claim 15 further comprising: interpreting a scripted rale. 19. The method of claim 15 further comprising: generating a scripted rale. 20. The method of claim 15 further comprising: transmitting a rale to a programmable auction server. 21. The method of claim 15 further comprising: maintaining a status of bids.

Inventors: EPHRATI EITHAN, SHOHAM YOAV, WELLMAN MICHAEL, EPHRATI, EITHAN, SHOHAM, YOAV, WELLMAN, MICHAEL
Applicants: EPHRATI EITHAN, SHOHAM YOAV, TRADING DYNAMICS INC, WELLMAN MICHAEL, EPHRATI, EITHAN, SHOHAM, YOAV, TRADING DYNAMICS, INC., WELLMAN, MICHAEL
Application year: 1999
Main classification: G06F17
IPC codes: G06Q30, G06Q50