KR20010079626A - A method and an apparatus for a universal trading market design and deployment system - Google Patents

Abstract

The present invention includes a general purpose auction including a market specification console 110 comprising a script generator 121 that combines a set of TPs into a time protocol script representing a particular auction specification and a network accessible set of trading primitives (“TPs”). It relates to a specification system. The system further includes a programmable auction server 140 having multiple modules, each module having a TP.

Description

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

Simple auctions that do not require complex calculations are now prevalent on the Internet. Onsale.com, eBay.com and Priceline.com represent such auctions. The software is not easily modified or deployed in other business relationships.

The toolkit implemented in the software provided by Opensite and Bonsai can be used to build and run simple auctions. However, customization of auctions by the toolkit is limited. For example, market designers can describe the duration of an auction or choose a simple auction format. But other variables in setting up auctions cannot be transformed without considerable labor. Although IBM has developed an auction toolkit that allows a fairly large degree of auction customization through subclassing devices from a library of software products, it is not a broad market design and deployment system. In addition, the system is limited to auctions for single unit purchasers only.

Moai, Inc. (Moai) has software that represents products rather than auction products. Moai offers a software solution that implements auction technology. Moai builds software to create Internet auction solutions for manufacturers or resellers who want to sell surplus products and surplus inventory. Moai's software solutions can be tailored to consumer needs, but the auction type and mechanism are limited to specific auction types.

Michigan Internet AuctionBot, another Internet service, allows parties to create and manage auctions (eg, approve bid prices, notify bidders of auction results, etc.). AuctionBot supports a wider set of auctions than other services, but with limitations. In particular, AuctionBot cannot support the kind of activity rules that occur in industrial markets such as FCC spectrum auctions and the California Power Exchange. Nor does it provide a modular structure to extend the range of system formation.

In short, market designers of Internet auctions have two choices: developing software or using limited toolkits. Thus, it is desirable to have a means for defining and deploying a broad internet auction market without involving long-term software development.

The present invention relates to the use of networked computer systems for the design and deployment of marketing markets. More specifically, the present invention relates to an auction engine composed of modular elements representing the scale of an auction design.

1A is a system block diagram showing elements of a preferred embodiment.

1B is a diagram illustrating a programmable auction server of the system.

2 and 3 schematically illustrate one embodiment of the invention in which a bid is received and confirmed.

4 shows a data flow diagram of one embodiment of the present invention.

5 illustrates a three layer specific embodiment of the present invention.

Methods and apparatus are developed for designing and deploying interactive, real-time, global trading markets on the Internet. One embodiment of the present invention is directed to a general purpose auction specification system having a programmable auction server. The programmable auction server has a plurality of auction specification modules in which at least one auction specification module matches at least one function of an auction variable selected from the group consisting of process bidding, information disclosure and approval.

Other aspects and methods of the present invention are described in detail below with reference to the following figures in conjunction with devices formed using the method.

The present invention relates to a method and apparatus for designing and deploying a universal, interactive, real-time, trading market system that assists merchants communicating over the Internet and similar networks. The general system for specifying and deploying trading market systems such as auctions is newer than the limited systems known in the art. One embodiment of the invention relates to a general purpose auction specification system having a programmable auction server (PAS). The programmable auction server has a plurality of auction specification modules in which at least one auction specification module matches at least one of auction functions, such as bid processing, auction information disclosure, and auction approval.

In the following detailed description, numerous specification items are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced without the above specification items. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.

1A and 1B illustrate a market specification console (“MSC”) 110, a general sales console (“UTC”) 120, a general supervisory console (“USC”) 130, a market Various embodiments of the invention are shown which may include various elements such as management console (“MAC”) 150, PAS 140 and communication network 160, and various link elements 161. The elements may be stored or operated in a single computer system or in multiple computer systems connected by a network.

Overview of system modules

MSC 110 consists of a computer running a computer program that allows market designers to specify any limited number of possible market protocols. Thereafter, the market defined by the market protocol is passed to or uploaded to the PAS 140 for execution. The market can be as simple as an English or Dutch auction with some parameters dictated by the market designer. Optionally, the market designer can develop any auction using very complex calculations.

Although markets can be organized in many ways, they are generally organized in sequential steps. Each step includes the interval (s) in which the activity is governed by relatively fixed rules specified by the market designer. The time flow of the market consists of a series of market stages specified by the market designer. To specify the time flow, the market designer must identify the steps. Steps are identified and sequential relationships (eg, end condition, conditional branching between steps, etc.) are displayed by manipulating the step display on the graphical user interface (GUI) of the MSC 110. One step may be defined as a time period, a limit, a condition (eg, a stop condition, a concurrent condition, a subsequent condition, etc.), an exception, an exclusion, or a clue. The market designer may specify criteria such as how to choose the next stage (if any) at the end of the stage (e.g., a specified time period, first 100 bids received, etc.) and other applicable limits. Can be.

To specify rules, such as market rules that govern a particular step, the market designer selects options that specify the behavior of the elements of the PAS 140 (herein referred to as primitives ("TPs")). The MSC 110 may provide a menu and other means for selecting options and may provide guidance to market designers in view of the legal coalition of the options or may recommend choices related to specification design purposes.

UTC 120 is comprised of a computer running a computer program that allows a trader (e.g., a seller, a consumer, a seller, or a consumer's agent) to trade on any market protocol running on PAS 140. UTC 120 presents the information to the trader in a way that is automatically adjusted to the particular market protocol it is executing.

USC 130 consists of a computer running a computer program that can allow a supervisory system, such as a regulatory body or an independent auditor, to monitor the market's behavior on PAS 140. This function determines whether the execution of the auction is in compliance with the norm and allows the market to intervene when deviations are detected.

The MAC 150 consists of a market operator, a computer program housing a PAS 140 and operating a computer program that allows an entity responsible for the operation of the PAS to monitor the execution of various markets operating on the PAS 140. The MAC 150 also manages registration transactions, such as the process by which traders verify themselves with the system (eg, providing their name and credentials). In addition, MAC 150 allows the market operator to adjust the system in real time.

PAS 140 may accept multiple market protocols belonging to the computer from MSC 110 and implement multiple market protocols (e.g., start auction, approve or reject bids, settle prices, traders of market stocks). Notification and auction termination) includes a computer running a computer program. More specifically, PAS 140 uses several modules to control market operations. Modules such as Bid Proofer, Release Manager, and Clearer process incoming bids, answer questions, maintain market status (eg, bid tracking, etc.), and deliver results to traders and optionally non-sellers. Help to manage the market by reporting Through this module, bid verification (e.g., authenticating a bid from a trader as a "bid"), release of information (e.g., showing all current bids), clearing (e.g., Various transactions may be performed, such as clearing a price or bid, registration of information (eg, the seller's name and phone number). In a preferred embodiment, the various devices are organized into a complete system through a three-layer structure separated by a double firewall as shown in FIG. 1A.

Market Specification Console (MSC)

The MSC 110 makes available to the market designer a full spectrum of rules that define a market protocol in an orthogonal form. The rules can be modified by the market designer. Combinations of rules that participate in and operate the market constitute market protocols. Market protocols that can be specified through the MSC range from simple auctions such as English, Dutch, and sealed bid auctions to highly complex auctions, such as those managed on financial exchanges and trading limits of the California Power Exchange.

Table 1 provides some types of auction examples that can be specified through the MSC 110 for the placement of the PAS 140. As shown below, the auction types can be arranged in layers that the market designer will use as part of the market specification process. The described sublayer is just one of several possible arrangements.

Table 1: Example of auction classification

1) a single item type a) in case of service (for example, buyer bid only) ⅰ) English (raise price) ii) Dutch (lower price) ⅲ) sealed bid b) in bilateral case (buyer and seller bid) Consecutive double auctions ii) Calling market 2) Multiple commodity types a) Simultaneous rising prices b) Combination

Table 1 shows the multiple grades of auctions. The table includes auctions for one or multiple items. Single articles are auctioned by single or double auctions. Types of partial auctions are English, Dutch, and secret bid auctions. The English auction (in the case of buyer bidding) operates in the general form, in which trader A bids on goods. Trader B will then bid higher than the bid submitted by Trader A. The highest bidder wins the buy-in English auction. In a Dutch Dutch auction, on the contrary, the price will start at a high level and fall until the trader proposes a bid. Secret tender auctions involve holding information until the bidder is collected from the traders and closed. At the end time, the highest bid wins.

A bilateral auction marks another class of auction. In a bilateral auction, both buyers and sellers bid. One example of such a rating is a continuous double auction. Successive double auctions collect buyer and seller applications. If the purchase application and the sale application are correct, the sale is completed. The calling market operates similarly, except that bids are collected over time and matched in a periodic manner. Trading generally occurs at a flat price that matches all matched bids.

As indicated above, multiple items may be auctioned. This relates to a number of items filed by a single company, government agency or some other entity. Auctioning at the same time involves auctions in progress for other items. Combination (bundle bidding) auctions involve bidder bidding for combination items, such as a trader, who proposes a bundle of bids consisting of item A, item B, and item C.

In general, market designers can define a market in one of two ways. One method is to select a predefined market protocol in parameterized form and enter the values of its extra parameters. For example, a market designer can specify a minimum increment and start time in an English auction. Another approach is to have the market designer define any market protocols that are appropriate for any given situation.

Although there is no limit to the number of market protocols, certain general rules apply. First, all auctions are associated with a set of entities that allow called traders to participate. Traders enter the market by submitting bids that apply to buy or sell auction items at specified prices (eg, the price and amount required for bidding). As a result of the bid, some information may be disclosed to traders about the state of the market. Under the conditions specified in the market protocol, the auction wins and the final transaction is determined. The auction ends if the termination conditions are met.

Because of the above general factors, it is possible to define TPs that indicate specific choices for the types of market protocols applicable through a range of auction types. For example, a single TP may be used if an auction is a partial (e.g., buyer or seller bid), a bilateral (e.g., buyer and seller bid), a secret bid, or a "public auction" (e.g., all bidders Exposed to them). TPs can also define when significant events such as winning bids or information disclosures occur. Further examples of TPs and the methods in which they are used to specify an auction run are shown in the section describing the PAS 140 below.

Each stage of the auction is defined by specifying the containing TPs or a time schedule for the application of the TPs. One common way to specify a time schedule is to trigger a scripting language with a control structure for sequencing and iteration, access to internal auction events and daily time clocks, and the possibility of calling TPs. This role can be fulfilled by standard scripting languages such as TCL / TK, JavaScript, full-fledged programming languages such as specially designed auction scripting language, Java, any other scripting or any programming language. A preferred embodiment of the present invention utilizes a script generator 121 to generate a script in a language generically referred to as CommerceScript. Commerce scripts are tentative protocol scripts that display auction listings.

The potential nature of commerce scripts provides a more convenient level in market specification. Rather than being a market designer limited to text scripting, the present invention provides market designers with a visual scripting option. The visual scripting option allows the market designer to graphically plot a time schedule and place several TPs along the time schedule. Each TP may be annotated with several pieces of information, such as the market entity that executes the TP, whether the implementation is mandatory or acceptable, whether conditions should precede or occur after the step, and whether the prerequisites must match. The output of the visual specification element is similar to the output of the text specification element. Although various visual programming tools exist in the art, these tools have not been applied to the formation of marketing market specifications. One novel aspect of visual specification element annotation relates to processing steps such as "essential" or "acceptable" that are unique to commercial applications.

Programmable Auction Server (PAS)

PAS 140 is scalable and flexible. The PAS contains a commerce script and an interpreter for modules that form the functions defined by the TPs referenced in the script. In general, the range of acceptable market protocols other than the practical limits of PAS 140 in the sense of computer memory and other computer resources is not bound.

Market protocols may follow distinct market entities for various permissions to perform operations such as some form of bidding or some form of retrieval of information. The authorization is based on the registered trader and the auction characteristics captured by the MAC 150 registration process. One form of PAS 140 is a general method of handling permissions irrespective of the particular market protocol executed. Each step in the execution of the protocol is initiated by a type of market activity, a specific example (ie, the value of the specified inputs) and the entity wishing to implement it. The liquidity tolerance management presented by the present invention is generally important for industrial applications that require safety measures such as defense against malicious intruders and ineligible market entities.

To improve error tolerance, PAS 140 generates an audit trail by logging all actions that occur on the system, including bidding, other trader actions, market winning results, and other similar actions. In addition, the trading management module records the trading and securities generated by each participant. For example, the sales management module may record that trader A and the buyer applied for a bid of $ 100 for an item such as a book. Since the bid reflects the highest bid received, Seller B sold his book to Buyer A for $ 100. The sales management module will record that Buyer A has a debt paying $ 100 in exchange for Seller B's book.

PAS 140 consists of several modules that can be added or customized for different market protocols. The modules form market functions based on the TPs specified by the market designer as discussed below. PAS 140 uses script translator 141 to execute market protocols and provides application program interface 510 and surrogate bidder 109 for extensibility and access to other auction system elements.

1. Script Translator

PAS 140 uses a comprehensive script translator 141 that can recognize and translate commerce scripts, other types of scripts, or any programming language. In addition, the script translator 141 can be modified to suit the new scripting language.

2. Bid Validator

The bid verifier 151 tests each incoming bid according to bid rules formed by the market designer. "Bidding" is defined as a representation of an action that can transform a bidding state. A bid includes various actions, such as indicating a buyer's intention to purchase an item at a price or giving up a previous bid. Changing a bid qualifies as a new bid. If verified as a qualifying bid, the bid is approved on the order book. Otherwise, the bid is rejected. There are many possible bid rules that can be specified in the TP via the MSC 110. Examples of bid rules provided below are illustrative only.

In one embodiment, bid verifier 151 operates to compare incoming bids to bids referred to as base bids. The base bid may refer to the seller's own bid, all bids or some brief (eg, price quotes) as determined through applying bid rules. For example, suppose a bid rule requires a bid to be eligible, and the bid must meet the following requirements.

Bidding received highest bid + x

x is $ 20 and the highest bid received is estimated at $ 100, where the highest bid is the highest bid received for an auction in any time period. The highest bid indicates the default bid. In the above example, the base bid is replaced with a higher bid. The higher bid is hereinafter referred to as the base bid. Incoming bids must be at least $ 120 to enter the order book.

Another example of a bidding rule may limit the types of traders eligible for bidding, or may limit the bids applied by multiple traders. Bidding rules may also specify whether cancellation or replacement of a bid is allowed. Restrictions may also generally be placed on the frequency of the action or bid. Certain bidding rules may be specified by the market designer to apply throughout the auction or for a specified time period (eg, stage or round). Floating bid rules based on bid order may also be used. For example, rising (or falling) limits require that a replacement bid be exceeded by some base bid as discussed above. The limitations may apply to only one side of the sale or to both purchase or sale.

In other ways, bidding rules serve to define which applications may appear. For example, the rules may specify whether a bid can only refer to a single unit of article for allowing bidding on multiple units. Additionally, if multiple units are allowed, bid rules may specify that the application can include only a single price point, multiple price points, or an amount at a given price. Other examples of representational limitations include separate applications, such as serial applications, price monotonicity, divisibility (all but abandonment), interpolation / extrapolation, and so on.

Representable bidding terms may also be used in bidding rules to limit bidding at an auction. For example, expressible bidding conditions include the minimum amount of the item being bid or the minimum bid amount that must be satisfied. In the context of a multi-dimensional auction, combinations may be considered to be acceptable in bundles. "Securities" bidding may also be acceptable. A bundle constraint specification of the highest complexity may also be included.

Bidding rules that consider eligibility may also be specified. Eligibility for traders or specific bids can be specified in a number of ways. For example, eligibility for a trader or bid may be specified in terms of previous auction history related to the auction but including the history of other auctions. This is usually the case for the restrictions referred to as the general rules of activity for complex auction scenarios.

Auction rules may also relate to payments, such as payment of fees, to allow participants to participate in a sale. For example, an initial bid may require an entry fee (non-refundable or non-refundable), or withdrawal may be allowed under payment of a breach of contract. The foregoing represents some of the bidding rules that can be used in an auction. By executing bid rules as indicated above, a "bid state" is formed. The "bid state" is the state of bidding from various traders. The state of the bid is maintained in a form known in the art. The bid status may also include historical data of several bids. For example, a graphical representation of a bid may be displayed to traders on a trading interface displayed to traders. Through the trader interface, the trader can enter and receive information from the entire auction system. Information can be communicated to the entire auction system via a keyboard, touch screen display or voice activation system.

3. Bidding transducer

The bid modifier 155 forms a differentiated allocation market protocol that can generate several economic prices. Differentiated allocation market protocols may be based on the identity of the trader applying for the bid (“seller's identity”), the amount allocated to the trader's identity, or some other condition specified by the market designer. The seller's identity may be associated with individual sellers or established groups (eg, certified merchants, registered customers, specific credit rating holders).

In a preferred embodiment, each applied bid belongs to a bid modifier 155 that applies a differentiation policy to the bid. For example, if a particular trader, such as trader A, can receive a 20% discount, the applied price is increased by an amount such that the reduction is equal to the original bid by 20%. Thus, the bid of $ 10 by trader A is transformed into $ 12.5. The modified bid of $ 12.5 is then compared with bids received by other traders.

Another example relates to the price applied for the quantity of goods above a certain threshold (or a service such as the stated task quantity). The quantity of goods may be valued at a "fine" percentage which causes the allocation to the trader (s) to be biased. After the bid is modified by the bid modifier 155, the modified bid is passed to the bid verifier 151.

An alternative method to the preferred method involves forming a differentiated allocation policy using the winners 154. In this method, the bid is not modified. Instead, the winning calculation is modulated to form a differentiation allocation policy. For example, if the differentiated allocation policy prescribes that a trader won't win more than half of the quota, the winning algorithm will maximize the means of restraint that the quota does not exceed.

4. Information manager

The information manager 152 controls the information disclosed by the auction for the participants during the bidding process. As a result, the question is rated in terms of the bid status that the auction can handle and the bid and sale history. Unprocessed questions generate a null response.

The mechanism can distinguish between the information available through active and passive means. Traders can actively request publicly available information through specified questions. The information is disclosed to manual access by defining a price quote operation. The price quote generally specifies the result of a home auction, but is also a specific form of an auction status brief specifying some other salient information (eg, the highest purchase bid received). Price quotes can be calculated and captured at public time so that information is made available without questions and obvious questions do not cause complex calculations. For a single commodity auction, one form of price quote is "bid demand spread" which can be regressed at a single price. The bid quote indicates the price at which the manager must apply for a sale for a successful sale or less (assuming no other changes occur in the auction state). The request quotes indicate a matching price for the request quotes. An auction may define a number of price quote actions used for other classes of traders or other situations in which the grade may be characterized in the seller's identity or bidding status.

The market designer defines the behavior of the information manager 152 by listing the list of explicit questions to be processed as well as selecting TPs that list and adjust the time of the price quote (MSC 110). Similar to other auction events, information disclosure can be timed according to a fixed schedule or by events (eg, auction, bidding, inactivity intervals, etc.).

In addition to the bid status reflected in the order book 154, the information manager 152 may also control the disclosure of other relevant auction status information. For example, the auction status may include qualified traders to form additional bids or other market information that affects the trader's prediction.

The information disclosure policy formed by the information manager 152 can have a significant impact on the nature of the auction. In addition, at one extreme, all information about bid status information can be published as in an auction. At the other extreme, however, if a secret bid auction is used, information about the bids of other traders is not disclosed.

5. Order ledger / successful bidder

The order book / winner 154 (“winner”) determines the allocation of the items and the exchange based on the bid history and auction rules. Allocation generally corresponds to a set of trades between auction participants. Once the sale is determined, the results are reported to the traders and, optionally, to the non-sellers. The successful bidder 154 uses the bid status indicated by the order book to derive the transaction determined by the auction rules in the given status. The bidder also allows the trading manager module to control notification and execution of the trading.

The successful bidder 154 is generated according to the temporary flow TPs specified in the MSC. Other TPs specify how to determine allocation. The allocation policy may be specified by specifying an algorithm that forms a function from the auction state to the allocation, or by defining a complete set of criteria for selecting among the possible allocations (eg, allocations that match the applications indicated by the bid). Can be.

The winning bidder 154 may use the generic rating of the allocation policy, which may be defined by translating the application specified in the bids and maximizing the final redundancy, as indicative of the value function. However, the maximization is generally not unique because call transfer is a fruitless operation. For example, in a secret auction of a single unit of one item, the first price auction maximizes the total residual and then allocates as much as possible to the seller. The second price auction allocates the remaining amount to buyers. A k double auction may split the residue fractionally according to parameter k. In general, the rules are not clear, as there may be a choice between buyers (or sellers) to allocate a positive residual. Methods of selecting among the remaining equivalent bids may be based on forms such as bid time, amount or random selection. This criterion is often referred to as a rule of balance.

The successful bidder 154 may use another type of successful bidding policy that determines transactions based on chronological order. For example, a continuous double auction (“CDA”) matches buyers and sellers while receiving compatible applications. The release of information about the transaction may be delayed. In contrast, the calling market collects bids over time before determining allocation. As the bid gap in the calling market is reduced, an approximate CDA is determined.

The successful bidder 154 may use a discriminatory or non-uniform price auction that may assign the same items to traders at different prices. For example, in a bid-paying auction, one successful trader trades exactly the amount they bid, regardless of the price of the other successful traders.

Regardless of the stated allocation policy, the present invention may be realized either by specifying a TP available to market designers to supplement the policy or by integrating a completely new device into the PAS 140.

6. Proxy bidder

Bids applied by the trader may be entered by direct bidding or proxy bidding. In direct bidding, the bidder selects the auction and enters the bid using a computer keyboard and mouse (interface provided by UTC 120). In proxy bidding, a user defines a script that priced his or her profit in one or more auctions running on PAS 140. As part of surrogate bidding, the trader also sees whether the script is run within trader console UTC 120 (e.g., surrogate bidder 508) or sent to PAS 140 to operate there (e.g., surrogate). Bidder 509 is specified.

The proxy bidder 509 may be further optimized to take advantage of the fact that it operates within the PAS. Specifically, when there are proxy bids from multiple traders, proxy bidder 509 can directly resolve the competition between the bids, eliminating the need to repeatedly apply for increasing bids on the order book.

7. Application program interface

PAS 140 has a set of application program interfaces ("APIs") 510 that provide a means to extend PAS to integrate replacement or additional modules. The purpose of the APIs is to turn a closed system into an open system. Closed systems require that the system be fully used or ahead using the closed system. In an open system, the elements can be fully integrated into the existing elements. For example, the APIs may be: (1) legacy software for registration or transaction management, (2) auditing or monitoring of authorization agents, (3) programs forming new winning algorithms, and (4) review below. Allow the integration of the PAS 140 with the program to carry out the trade through the UTC 120.

Universal Trading Console (UTC)

UTC 120 has at least two functions (display of information and bid entry). Examples of information displayed to the user include operations on PAS 140 and additional information. PAS 140 operation is primarily events logged by PAS 140, such as the start of an auction, placed bids and winning prices. The actual information displayed may vary from one market to another, reflecting different market designs. In particular, the amount of information displayed may vary. For example, two concurrently bidding auctions may change the disclosure policy to one auction disclosure information after each round and bid of that round, such as the full list of bidders, while another auction may include bidder specification information. Only collect bids that are supplied without can be disclosed. Incidental information may be any information involved in making a trading decision, but it is not inherent in market activity. For example, energy markets and many other future market weather forecasts can be important information for traders.

There are variations in the formats of dissemination and bid collection between different types of auctions. In a preferred embodiment, the diversity is accommodated by introducing a database layer between PAS 140 and UTC 120. For each auction type, several specification database schemes should be introduced. PAS 140 resides in a database and specific data is automatically displayed in UTC 120 using dynamic HTML. The form of the design is that while the database tables in the PAS 140 must be formed for a particular auction, UTC 120 does not require modification.

2 and 3 schematically illustrate one embodiment of the invention in which several modules are shown. Here, a bid (eg, $ 100) is applied by trader A in operation 600. The bid is passed to the bid verifier 151 in operation 610. The bid verifier 151 uses the bid by receiving the bid and incorporating the bid in the TPs set by the market designer. In operation 610, the bid verifier determines whether the bid is acceptable. If the bid meets the minimum criteria for an acceptable bid formed by the market designer, the bid is verified as an acceptable bid and placed in order book / winner 154 in operation 640. If the bid does not meet the minimum criteria, the bid is rejected and Trader A is informed that his bid is not approved. The information manager 152 notifies the trader A by sending a rejection to the trader A in operation 625. Similarly, proxy bidder 509 may also apply for bidding to bid verifier 151. The bid goes through the same process as listed above.

Universal Surveillance Console (USC)

The professional marketing market is generally associated with one or more surveillance systems, such as the SEC, FCC, FERC, the California Public Utility Commission (CCP), internal monitoring bureaus of transactions, and external private audit agencies. Surveillance systems monitor trading activity and ensure that trading activity follows specified criteria. Following the rules promotes credit in the market. USC 130 provides information to the monitoring station in the market. USC 130 does not provide a way to trade in the market, but does not provide market control that is not provided to traders. Examples of such control are broadcast messages and stop trading activity appearing on UTC 120.

Three layer structure of the preferred embodiment

The system of the present invention is designed to adapt to the needs 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 the market for a few users and thousands of users. The system can be field modulated to handle an increasing number of users as market requirements mature and change.

4 shows a data flow of one embodiment of the invention. Market 700 includes auction 710. Although the market may include multiple steps, only one step is shown in operation 720. For many steps, one of ordinary skill in the art can replace one step auction statement with another step auction statement by methods known in the art. The bid requested by the trader is passed to the bid verifier in operation 730. The bid verifier determines whether the bid conforms to certain rules specified by a market designer or other party that can control one side of the auction. Thereafter, the approved bid is passed to the bid modulator in operation 740. In the above operation, the bid is modulated to reflect the differentiation policy that may increase and decrease the bid or some other modulation to reflect the status that has been approved for a particular trader or a particular item. In operation 750, the bid is applied to the bid for which rules are approved and processed so that the best bid wins. The best bid does not have to be the best bid. Rather, it is the bid that reflects the differentiation allocation policy applied. The bid is then submitted to the order book in operation 760. In this operation, rules to balance may be applied, alignment criteria may be used, and any other criteria specified by the market designer may be formed. In operation 770, the bid is submitted to the successful bidder to which the successful bidding operation applies. In operation 780, the bid is submitted to the sales manager for further processing. The information manager may operate continuously and provide information to traders on the continuous basis at step 790.

5 supports scalability such that a system structure with a different three-layer structure is formed. The first layer 110 includes a predecessor database 112 and a web application running on the web server (s) 111 that form the interface between the user 114 and the back 116 of the system. Authenticated users can access the system through a web browser. The GUI can run as either a Java applet or plain HTML (depending on the user's choice and browser version). Java and HTML programming languages are known to those skilled in the art. To protect the system, the web application is protected by a firewall 122 in a demilitarized zone (DMZ) that prevents it from passing through the application server (s) 120. The logic of the application constitutes the second layer 115. The middleware 130 environment is a foundational device that allows for high utility and scalability. The third tier 133 includes a database 136 and an interface 138 to the market operator's legacy system. Since the output of the auction process is polled by the legacy system, the overall security of the legacy environment is always guaranteed.

Accordingly, a method and apparatus for designing and deploying a universal, interactive, real-time, trading market system serving traders communicating over the Internet are presented. Although the present invention has been described with reference to specific exemplary embodiments, it will be apparent to those skilled in the art that various modifications and additions may be made without departing from the broader spirit and scope of the invention as set forth in the following claims.

Claims (21)

A general purpose auction system having a programmable auction server, The programmable auction server, Wherein the at least one auction module comprises a plurality of auction modules according to at least one function of the auction selected from the group consisting of a bid verifier, an information manager, a successful bidder, a registration manager and an alternate bidder. The program of claim 1, wherein the at least one auction specification module further comprises an auction module for performing at least one transaction selected from the group comprising a bid verification transaction, an information management transaction, a winning transaction and a registration transaction. Possible auction server. The method of claim 1, Set of marketing primitives; A script translator for translating the time protocol script representing the auction specification, the script including criteria for at least a portion of the set of sale primitives; And And means for switching one stage of the auction specification with another stage of the auction specification. 4. The programmable auction server of claim 3, wherein at least one auction module in one step is replaced with at least one auction module in another step. The method of claim 1, wherein the at least one step comprises: spacing at least one transaction selected from the group comprising: submitting a bid, approving a bid, canceling a bid, and replacing a bid. A programmable server comprising a. 6. The programmable auction server according to claim 5, wherein said step is terminated by a condition. 7. The programmable auction server of claim 6, wherein the condition is a time period. Marketing primitives; A script generator for modulating the trading primitives into time protocol scripts; Script translator for script protocol; And A general purpose auction system comprising a market specification console adapted to support multiple market protocols. 10. The general purpose auction system of claim 8 wherein the market specification console further comprises a plurality of rules wherein at least one rule is user changeable. 10. The general purpose auction system of claim 9 wherein the rules include market protocols. 10. The system of claim 8, wherein a market specification console is coupled to a programmable auction server, wherein the programmable auction server is adapted to receive market protocols from a market specification console having the market specification console, a graphical user interface (GUI). A general purpose auction system. 12. The general purpose auction system of claim 11 wherein the trader interface is connected to one network. 13. The general purpose auction system of claim 12 wherein the trader interface is used by a trader to submit a bid. Means for specifying a number 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. Generating, by the at least one auction module, a plurality of auction modules according to at least one function of the auction selected from the group consisting of a bid verifier, an information manager, a successful bidder and a registration manager; Specifying a plurality of rules in which the transaction includes at least one rule; And Forming at least one transaction comprising bid verification, dissemination of information, auction, and registration of information. 16. The method of claim 15, further comprising displaying the rule to a market designer. 16. The method of claim 15, further comprising modulating at least one rule. 16. The method of claim 15, further comprising translating the scripted rules. 16. The method of claim 15, further comprising generating a scripted rule. 16. The method of claim 15, further comprising sending a rule to a programmable auction server. 16. The method of claim 15, further comprising maintaining a state of bids.