Automated trading exchange system having integrated quote risk monitoring and integrated quote modification services

- Cboe Exchange, Inc.

An automated trading exchange having integrated quote risk monitoring and quote modification services. An apparatus is implemented using at least one computer, having memory, and a processor. The computer is configured to receive orders and quotes, wherein specified ones of the quotes are contained in a quote group, and have associated trading parameters such as a risk threshold. Not all received quotes are required to have trading parameters as described herein. Preferably, the quote group contains all the quotes, or a subset of quotes, belonging to an individual market-maker for a given class of options contracts, or possibly the quotes of two or more market-makers that have identified themselves as belonging to a group for the purposes of risk monitoring and quote modification. The computer typically generates a trade by matching the received orders and quotes to previously received orders and quotes, and otherwise stores each of the received orders and quotes if a trade is not generated. The computer then determines whether a quote within the quote group has been filled as a result of the generated trade, and if so, determines a risk level and an aggregate risk level associated with said trade. The computer then compares the aggregate risk level with the market-maker's risk threshold, and if the threshold is exceeded, automatically modifies at least one of the remaining quotes in the quote group. The computer may also automatically regenerate quotes that have been filled.

Skip to: Description  ·  Claims  ·  References Cited  · Patent History  ·  Patent History
Description
CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No. 13/572,195, filed Aug. 10, 2012, pending, which is a continuation of U.S. application Ser. No. 13/178,289, filed Jul. 7, 2011, now U.S. Pat. No. 8,266,044, which is a continuation of U.S. application Ser. No. 12/035,996, filed Feb. 22, 2008, now U.S. Pat. No. 7,980,457, which is a continuation of U.S. application Ser. No. 09/475,534, filed Dec. 30, 1999, now U.S. Pat. No. 7,356,498, wherein the entirety of each of the aforementioned applications is hereby incorporated herein by reference.

A. FIELD OF THE INVENTION

The present invention relates to financial trading systems. More specifically, it is directed to a method and device for market-maker risk management through automatic quote risk monitoring and quote modification in an automated trading system.

B. DESCRIPTION OF THE RELATED ART

1. Option Trading

Option contracts are traded publicly on many exchanges throughout the world. These securities, referred to generally as “options,” convey certain rights to buy or sell an underlying stock, commodity, or other security at a fixed price for a specific period of time—until expiration for an American-style option or at expiration for a European-style option. All option contracts that trade on U.S. securities exchanges are issued, guaranteed and cleared by the Options Clearing Corporation (OCC). OCC is a registered clearing corporation with the SEC.

The potential loss to the buyer of an option can be no greater than the initial premium paid for the contract, regardless of the performance of the underlying stock. This allows an investor to control the amount of risk assumed. On the contrary, the seller of the option, in return for the premium received from the buyer, assumes the risk of being assigned the obligation to buy or sell the underlying security if the contract is exercised. Therefore, writing options can lead to large potential exposure.

Further background information may be obtained from the book “OPTIONS, Special Concepts and Trading Strategies,” The Options Institute, The Educational Division of the Chicago Board Options Exchange, Second Edition, McGraw Hill (1995), the contents of which are incorporated herein by reference.

2. Open Outcry Trading and Automated Exchanges

Many trading systems utilize what is known as an open outcry method of trading. In the open outcry system, market-makers are required to make a two-sided market by providing a bid and offer quote in all option series. The market-makers typically communicate verbally or visually with contra traders indicating their willingness to buy and sell various quantities of securities. Because the market-makers have personal control over the types and number of contracts traded, they can adjust their trading strategies as their positions change. In this way, the market-makers can manage their exposure, or risk, associated with their holdings by adjusting their quotes to favor trades that would tend to hedge away unwanted exposure.

In an automated trading environment, a certain amount of control is lost when a market-maker has issued quotes in a large number of option series. The quotes are typically recorded in the automated and computer-based trading system, and matched up automatically with orders that enter the system electronically. With the proliferation of computer trading systems and increased communication speeds, the rate at which trades may be executed by an automated system far surpass the rate of trades that occur in, an open outcry system. The speeds are such that the rapidity of trades may exceed the market-maker's ability to adapt his or her position. Specifically, one disadvantage of automated trading systems is that a number of automatic trades may occur within a very short time that result in an unacceptable risk being assumed by a market-maker. That is, the trades may occur so rapidly that the market-maker is unable to withdraw or modify his quotes in a timely manner.

There exist software tools that can analyze stock and option portfolios in close to real time. Market data is provided to the software analysis tools and used to evaluate the risk associated with stock and option portfolios. In addition, the tools may provide recommendations for trades and quotes and automated submission of those trades and quotes. However, even if a market-maker utilizes such a computer-implemented automated position analysis tool to revise or cancel quotes, the software tools may be unable to act in time given the speed at which an automated trading exchange system is capable of executing incoming orders. In particular, one aspect of existing exchange systems is that transactions are received and processed in the order received. Thus, even if a market-maker responds immediately using an automated software tool, the exchange may have a message queue containing additional orders that will be processed before the exchange system receives and processes the market-maker's quote cancellation request.

The result is that a market-maker who is willing to take on a predetermined level of risk must limit the number of quotes or the depth (quantity) of each quote to ensure that rapid trades do not result in an unacceptable aggregate risk, rather than issuing quotes having greater depth and breadth (where the filling of a single quote might reach the market-maker's risk limit). Thus, a market-maker's limited control over risk management may have the undesirable effect of hindering the liquidity of the market.

It would therefore be desirable to have a trading exchange system and method for automatically canceling, regenerating, or modifying quotes under certain trading conditions.

SUMMARY OF THE INVENTION

A method and apparatus for an automated trading exchange having integrated quote risk monitoring and quote modification services is provided. In accordance with a first aspect of the invention, an apparatus is implemented using at least one computer, having memory, a processor, and a communication port. The computer is configured to receive orders and quotes, wherein specified ones of the quotes are contained in a quote group, and have associated trading parameters such as a risk threshold. Note that not all received quotes are required to have trading parameters as described herein. Preferably, the quote group contains all the quotes belonging to an individual market-maker for a given class of options contracts, or possibly the quotes of two or more market-makers that have identified themselves as belonging to a group for the purposes of risk monitoring and quote modification. The computer typically generates a trade by matching the received orders and quotes to previously received orders and quotes, and otherwise stores each of the received orders and quotes if a trade is not generated. The computer then determines whether a quote within the quote group has been filled as a result of the generated trade, and if so, determines a risk level and an aggregate risk level associated with said trade. The computer then compares the aggregate risk level with the market-maker's risk threshold, and if the threshold is exceeded, automatically modifies at least one of the remaining quotes in the quote group. The computer may also automatically regenerate quotes, that is, automatically issue new quotes when trades have occurred against previous quotes.

BRIEF DESCRIPTION OF THE DRAWINGS

The objects, features and advantages of the present invention will be more readily appreciated upon reference to the following disclosure when considered in conjunction with the accompanying drawings, in which:

FIG. 1 depicts a preferred embodiment of the quote modification trading system;

FIGS. 2A, 2B, 2C, and 2D show the interconnection of various software modules associated with the quote risk monitoring and modification trading system;

FIG. 3 shows a sequence diagram of a preferred embodiment of the quote modification system; and

FIG. 4 shows a flowchart depicting the method of modifying quotes.

 DETAILED DESCRIPTION OF THE PRESENTLY PREFERRED EMBODIMENT(S)

With reference to FIG. 1, a preferred embodiment of the system 100 utilized for trading and quote modification is described. The system 100 (also referred to herein as a screen-based trading system, or SBT system) includes a plurality of computers, which may be one or more workstations, servers, mainframes, or other computer hardware platforms that provide sufficient resources to meet the desired trading volume and desired transaction-processing rate. In the preferred embodiment shown in FIG. 1, the system includes a number of computer clusters such as cluster 102 (although only one is depicted in FIG. 1), where each cluster 102 handles trading for a number of securities, such as one or more classes of options. In the preferred embodiment, each cluster 102 is made up of two servers 104, 106. The servers 104, 106 are preferably multiprocessor SUN 4500 servers available from SUN Microsystems of Palo Alto, Calif. SUN Enterprise™ servers or Starfire™ servers are a preferable alternative.

The servers 104 and 106 in cluster 102 communicate with a plurality of client servers 110, 112 that are typically located at remote locations, such as at a brokerage house, but may also be located in the same facility as the clusters 102. Network 108 facilitates communication between the clusters 102 and the client servers 110, 112. The network 108 is preferably a private LAN/WAN configuration, but a public network may be utilized, provided sufficient redundancies and message security are provided. Two such client servers 110, 112 are shown in FIG. 1. Each client server 110, 112 may be provided with a predetermined message throughput rate into network 108, where the throughput rate may be a maximum rate determined by various parameters, including the volume of orders sent by the client server 110, 112, the volume of quotes sent by the client server 110, 112, the number of option series for which quotes are provided, communication/connection fees paid by the brokerage house or other entity utilizing the client server 110, 112, the overall capacity of the trading system 100, etc. The client servers 110, 112 preferably communicate with other elements of the automated exchange system using a client application server module 210, as further described below, running on client servers 110, 112.

Each client server 110, 112 is capable of serving a number of clients, shown as terminals 114, 116, 118, 120, 122, and 124 in FIG. 1. The client terminals 114-124 may be “dumb” terminals, stand alone computing devices (PCs or workstations), or even portable wireless terminals. The client servers 110, 112 may communicate with the client terminals 114-124 using a proprietary protocol or one of many standard public domain protocols. The client servers 110, 112 may include a web server or connect to a separate web server for processing tcp/ip, http, html, java, and the like, and provide access to client terminals 114-124 over the Internet in addition to (or as an alternative to) private LAN/WAN or Virtual Private Network access. For embodiments that include a webserver, the web server preferably utilizes common gateway interface scripts (cgi) to interface with the client application server 210. In addition to cgi scripts, or as an alternative to cgi, other web server interfaces and server extensions may be utilized to provide communication between the web server and the application server 210. The client servers 110, 112 communicate with the users of terminals 114-124 by way of secure Internet communication protocols or by private LAN/WAN or VPN communication links. Thus the client terminals 114-124 may run dedicated proprietary software to communicate with the client server 110, 112, or may interface with client servers 110, 112 via a standard web browser. The web browser may operate using built-in java scripts, or may also include specialized browser modules that are provided to the client terminals.

The automated exchange system 100 is comprised of the following five logical software modules: Presentation Services Graphical User Interface (GUI) 130 (FIG. 2A); Application Services 210 (Client Application Server, Gateway) (FIG. 2A); Business Services 132 (FIG. 2B); External Integration Services 133 (FIG. 2C); and, Infrastructure Services 134 (FIG. 2D).

With reference to FIG. 2A, the Presentation Services GUI module 130 is constituted by applications that interact with the exchange system 100 via the Member Interface (MI) API 135. There are two types of client applications, those that provide a GUI to allow user interaction with the system directly and applications that automate trading functions.

An SBT (screen-based trading) GUI module 131 is responsible for displaying the contents of a particular model to the screen and updating the display if the model's contents change. This module 131 contains several GUI applications, one for each of the major classes of human actors that use the system 100: traders, market-makers, clearing firm brokers, and system operators. The Trader GUI is used by regular traders. It consists of several GUI's for displaying and entering orders, and market data. The Market-Maker GUI is an extension of the Trader GUI and is used by market-makers. It consists of several GUI's for displaying and entering orders, quotes, and market data. The Clearing Firm Broker GUI is an extension of the Trader GUI and used by clearing firm brokers. It consists of several GUI's for forcing the logout of a market-maker and for setting a maximum order quantity for the quotes and orders of the clearing firm's market-makers. The system operation GUI is used by system operators and help desk operators. The autoquote system 161 runs on the market-maker's work station and is used by the market-maker to generate quotes for various option series.

The Application Services module 210 contains subordinate modules that forward requests initiated by human or automated actors, to be executed by the appropriate Business Services module(s) 132. These applications submit requests to Business Services components 132, notify clients of business events, and maintain user-specific views of information in the Business Services 132. This module also encompasses a Member Interface (MI) API 135 that provides a single entry point to the system exposing the applications in the Application Services Module 210 (i.e., Trader, Market-Maker). In addition, the Application Services Module 210 maintains instantaneously updated views that reflect the prevailing state of each actor's information in the Business Services module 132.

The Trader Application module 136 has the following specific responsibilities: submit, cancel, update, and cancel/replace orders; submit requests for quotes; present the current status of the trader's orders; present fill and cancel reports; present Market Best Bids and Offers for selected products; set the trader's defaults and preferences; present Book Depths for selected products; and, present underlying quotes/last sales and news alerts.

The Market-Maker module 137 inherits the Trader App module's 136 responsibilities and adds the following: submit and modify market-maker quotes; present requests for quotes; set the market-maker's defaults and parameters; set autoquote parameters; submit autoquotes.

The Clearing Firm Broker module 138 inherits the Trader App module's 136 responsibilities and adds the following: assume control of a trader's privileges. A Clearing Firm Broker can force the logout of a market-maker; set a maximum order quantity for quotes and orders of the clearing firm's market-makers.

The BackOffice application 139 is responsible for reporting order status information. This can include fill reports, cancel reports and new order notifications. The Operations application 140 has the following responsibilities: start and shutdown the SBT system; start and stop trading of a product; change the status of a product's market (pre-open, open, close, halt, etc.); present logged system events; maintain SBT-specific trader information; maintain SBT-specific product information; maintain trading parameters (quote width, minimum market-maker order default size, required percent of responses to a request for quote (RFQ), maximum response time to an RFQ, etc).

The functionality of the Trader 136, Market-Maker 137, Clearing Firm Broker 138, and Back Office 139 modules is exposed by a façade, the Member Interface (MI) Application Programming Interface (API) 135. The Member Interface 135 exposes different subsets of functionality depending on the user that logged on to the system. The intention behind sharing a common API among the different trader classes is to allow workstations to service all of them. Separate API's may alternatively be used for the different user classes.

The Member Interface API 135 supports both SBT client applications and external applications owned by members. Members use the Member Interface API to link their existing computer systems to the exchange system 100, to submit orders electronically and to automate trading. Likewise, market-makers use the API to submit autoquotes employing their proprietary systems, instead of the default autoquote application 161 provided by SBT.

The following system functions are preferably accessible through the API: session logon and logoff; market state inquiry and change notification; connection status inquiry and change notification; order entry, cancellation, and replacement; quote entry, cancellation, and replacement; RFQ notification; order status inquiry and fill notification; subscription to product markets; best market quotes notification; book “depth” inquire and change notification.

Referring now to FIG. 2B, the Business Services module 132 contains the core functionality of the automated exchange system 100. It includes components that correspond to the key business object model entities of the automated trading system such as members, orders, books, products, quotes, et cetera. In addition, it includes components to administer and operate the system 100.

The Order Handling Service module 220 maintains the current state of all orders persistently. Specific operations may be exposed directly by Order objects 141, bypassing the Order Handling Service 220. Logically, Orders are components of this module. Specifically, the Order Handing Service 220 and Order components are responsible for: receiving and storing incoming orders (from SBT clients or TPF 156 (FIG. 2C)); forwarding incoming orders to the Broker module for execution; receiving order state change notifications from the Broker and Order Book modules and updating stored orders with this information (the functionality is provided by exposing Orders, allowing the Broker and Order Book components to directly update the orders); sending fill reports to originating traders upon receiving fill notifications from the Broker and Order Book modules; receiving order cancellation requests and forwarding them to the Broker and Order Book modules (upon confirmation of a cancellation, notifying the originating trader of the result of the request and updating the stored state of the order); and receiving order cancellation/replacement requests and forwarding them to the Broker and Order Book modules (upon confirmation of the cancellation/replacement, notifying the originating trader of the result of the request and updating the stored state of the order).

The Broker Service module 230 is responsible for executing the following types of orders: limit, market, all or none, fill or kill, immediate or cancel, stop, stop limit, and spread. Upon trade execution, the Broker Service 230 is responsible for notifying the Trade Service module 143 of all the orders matched (all parties to the trade) in the trade. It is also responsible for notifying the Order Handling Service (i.e. Orders) 220 and Market-Maker Quote Service (i.e. Quotes) 240 of the fills.

The responsibilities of the Order Book Service module 142 are: cooperate with the Broker Service 230 in calculating the opening price during a product's pre-opening period; acknowledge that an order was accepted by publishing an event consumed by the Trader application 136 which originated the order; cancel and cancel/replace resting orders; upon changes to the top of the book, publish the new Book Best Bid Offer (BBBO) and last sale.

The responsibilities of the Trade Service module 143 are: receive trade notifications from the Broker Service 230; format trade reports; store trade reports; and forward trade reports to trade match (via TPF 156).

The Market-Maker (MM) Quote Service module 240 is responsible for: receiving requests for quotes (RFQs) from traders; submitting RFQs to market-makers assigned to the product for which the quote was requested (by publishing in the RFQ event channel); receiving and logging market-maker responses to RFQs (market-maker quotes); upon receiving a market-maker quote, saving it persistently and submitting them to the Broker Service module 230 for execution; sending fill reports to originating market-makers upon receiving fill notifications from the Broker and Order Book modules; canceling or updating a Market-Maker quote upon receiving a request from the originating market-maker by submitting the request to the Broker/Order Book; canceling or updating or regenerating Market-Maker quotes upon receiving a fill report; upon inquiry, providing the history of the quotes submitted by a market-maker.

The Product Service module 144 maintains all product-related information. In order to perform its responsibilities, the Product Service module 144 downloads, and preferably caches, product information from TPF 156 and TIPS 157. The User Service module 260 maintains all user-related information, both specific to SBT and contained in the Membership System. It provides a unified interface to SBT components accessing user information, hiding the actual location of the maintained data, thus simplifying client logic.

The User Service module 260 maintains the information of traders, market-makers, clearing firm brokers, operators, help desk personnel, back-office personnel. In one embodiment, the data is cached for performance reasons and the data is synchronized from the TPF 156 source.

The Trading Session Service module 145 maintains all business day and trading session-related information and manages the different states of a trading session, e.g. open, closed, and halted. Products that are processed/traded in each trading session are also kept at this service. In order to perform these responsibilities, the Product Service module 144 downloads trading session and product information from TPF 156, as well as monitor events that affect products traded within a session.

The Product State Service 146 is responsible for coordinating product state changes for all products, e.g. pre-opening, opening, trading, halting, closing, and post-closing. It works closely with the Broker Service 230 to insure that state changes occur in a timely fashion. The service 146 monitors events that affect products traded, such as monitoring the underlying market to detect when the primary exchange opens, closes or halts trading a product. The Product Configuration Service 147 is responsible for providing the location of where a product is processed/traded. This information is primarily used to route product-specific requests (e.g. orders) for processing. The Order Status Service 148 provides subscription and notification services related to orders (i.e., fill reports, cancel reports, order accepted by book, etc.).

The Quote Status Service module 149 provides subscription and notification services related to quotes (i.e. fill reports, deletion reports, etc.) The service 149 preferably replaces the use of event channels for quote status reporting, providing a more secure mechanism for status delivery. The Market Data Service 150 maintains a current snapshot of market data, in addition to publishing market summary data. The module also provides an interface to clients to query historical market data.

The Best Quote module 151 is responsible for calculating the market best (aggregate quantities of buy and sell orders at the best price) for each product and sending them to TPF 156 (which in turn forwards them to the Options Price Reporting Authority) for public dissemination. In addition, it is responsible for calculating and disseminating the National Best Bid Offer (NBBO). In order to provide this information, the Best Quote module 151 subscribes to the event channel referred to herein as the Best of the Rest channel to obtain the current best quote from competing exchanges. The Best Quote module 151 then determines the source of the NBBO, whether it is from the present exchange or a competitor, and publishes the results to the Best Quote event channel, of which the TPF Adapter 152 is a subscriber.

Referring now to FIG. 2C, the External Integration Services module 133 includes adapters 152, 153, 154, and 155, that map the interaction paradigms of external systems to the ones in the system 100 architecture. The adapter modules “adapt” (or “wrap”) the native legacy interfaces to interfaces appropriate in the SBT environment. The TPF (Transaction Processing Facility) module 152 contains the adapter to allow SBT and TPF 156 to interact. TPF data is received, remoduled, and broadcast/delivered to the appropriate components within SBT. Conversely, SBT data is received, either through direct invocation or event consumption, remoduled, and sent to TPF 156 using its native interface.

The Membership Adapter 154 translates requests for member information received from SBT components into requests to the Membership System 159 and returns the results after re-formatting.

The TIPS Adapter 155 subscribes to TIPS 157 to receive the external market data needed in the SBT environment, including underlying market data and the Best of the Rest of options listed in SBT. The Events Service (FIG. 2D) notifies the TIPS Adapter 155 of consumer subscriptions so that it can propagate these subscriptions back to TIPS 157. Once subscribed, the TIPS Adapter 155 reformats the market data received from TIPS 157 and publishes it for consumption by SBT components. Another responsibility of this adapter 155 is to publish underlying product state events when external markets change their states, for instance when they open, halt, close, etc.

The Trade Match Adapter 153 receives SBT data and forwards it to TM 158. The TM Adapter 153 handles the following data flows: Trade Report (SBT to TM)—SBT reports all the parties to a trade to TM 158.

Referring now to FIG. 2D, the Infrastructure Services module 134 contains commercial “off-the-shelf” software and extended infrastructure services that provide enterprise-wide support to various other external systems. One mechanism by which the SBT system components interact with each other is by supplying and consuming events, implemented as a publish/subscribe pattern. The following list provides a brief description of the event flows/notification services (messaging services) shown in FIG. 2D.

RFQ—the Market-maker (MM) Quote Service supplies RFQ events consumed by the Market-Maker Application.

BBBO—the Order Book supplies Book Best Bid Offer (BBBO) events consumed by the Best Quote Service.

NBBO—the Best Quote Service supplies National Best Bid Offer (NBBO) events consumed by the Trader Application, and Market Data Service.

Current Market—the Best Quote Service supplies Current Market Best events, containing a product's best quote, consumed by the Market Data Service and Trader Application. The best quote indicates if the exchange has the best quote.

Best of the Rest—the TIPS Adapter component supplies best-of-the-rest events consumed by the Best Quote Service.

Last Sale—the Trade Service supplies last sale events consumed by the Market Data Service 150 and TPF Adapter 152.

Last Sale Summary—the Market Data Service 150 component supplies last sale summary events consumed by the Trader application:

Logging—the Logging Service Proxy component supplies Log Service events consumed by the Log Service component.

System Management—the Foundation Framework supplies System Management events consumed by the System Management component.

Instrumentation—the Instrumentation Service component supplies Instrumentation events consumed by both the System Management component and the Log Service component.

Underlying Ticker—the TIPS Adapter supplies Underlying ticker events (prices, quotes, last sales, news alerts) consumed by the Trader Application and the Product Service.

Underlying Recap—the TIPS Adapter supplies Underlying summary events (high and low prices, volume) consumed by the Market Data Service and Trader Application.

Trade Report—the Trade Service supplies Trade Report events consumed by the TPF Adapter 152.

Product Status—the Product Service 144 and Product State Service 146 supply Product Status events (State, Price Adjustment, and Update) events consumed by the Trader application, Order Handling Service 220, and TPF Adapter 152.

Trading Session Status—the Trading Session Service 145 supplies Trading Session State events consumed by the Operations Application 140 and Help Desk application 160.

End of Session Summary—the Trading Session Service supplies End of Trading Session Status events.

Opening Price—The Broker Service module 230 supplies Opening Price events consumed by the Trader Application 136.

Control—the Operations 140 and Help Desk 160 applications supply Control events, possibly through the System Management component, consumed by Business Services 132 and External Integration Services 133 components.

Order Status—the Order Handling Service 220 (Order) supplies Fill Report, Cancel Report, Updated Order, New Order, and Order Accepted by Book events consumed by the Order Status Service 148, and TPF Adapter 152.

Quote Status—the MM Quote Service 240 (Quote) supply Fill Report, and Delete Report events consumed by the Quote Status Service 149.

In accordance with a preferred embodiment, there are four major tiers of the application software. The business services 132 handle all the SBT order matching, execution and reporting functionality. It provides the repository for all SBT information data. The application services 210 handle the application presentation and act as the application front end to the business services. Different views of the business services 132 and collaboration of business objects are grouped together and are presented to the user based on logon authentication and authorization level. The two tiers communicate to each other by two supported tiers: the infrastructure services 134 and external integration services 133. The infrastructure services 134 provide a seamless integration between the application services 210 and business services 132. The external integration services 133 provide the access to the external system.

With reference to FIG. 3, a sequence diagram 200 for a preferred embodiment of the automated exchange system 100 is shown. The system 100 includes a client application server 210, an order handling service module 220, a broker service module 230, a quote service module 240, a user service module 260, and quote objects 250 and 252. The service modules 220, 230, 240, 260 and objects 250, 252 are preferably software modules running on clusters 102, or on one or more interconnected computers. The software modules are preferably written in an object-oriented programming language and are compiled to run on the clustered computers 102. Preferably, the software utilizes the C++ language, the Java programming language, or other object-oriented language. Alternatively, any suitable software language may be used to implement the system, as will be understood by one of ordinary skill in the art. The modules also interact with a database program used for storing data and other system and user information. In the preferred embodiment an Oracle database system is used.

The client application server 210, as discussed above, runs on client servers 110, 112, and provides an interface to one or more clients. The client server 110, 112 may include one or more application modules, depending upon the intended users of the servers 110, 112. For example, the client servers 110, 112 preferably include at least one of a market-maker application, a trader application, a back-office application, or a member interface. The client servers 110, 112 also preferably utilize a user authentication and role-based security model to control access to the various application modules.

The client server 110, 112 may also include modules such as a help desk application, an operations application, and a Clearing Firm Broker (CFB) module. The CFB module may be configured to allow a Clearing Firm to set maximum volume limits on a per-class basis. The Help Desk module is preferably enabled for use on client servers that provide connectivity to exchange management personnel. The Help Desk provides a utility to force a user to logout of the system.

The order handling service 220 forwards orders to the appropriate broker service module 230 that handles the class of options to which the individual orders relate. If the broker service module 230 cannot execute the order immediately, it routes it to the order book service module, which maintains the current state of all pending orders and quotes. The order handling service module 220 receives order information from various sources, including brokers, traders, market-makers, etc. The orders may enter the system from a client application server 210 or through an alternative interface such as TFP adapter 152, which is a connection that allows a pre-existing automated order handling system such as TPF system 156, to access the present system.

The broker service module 230 is responsible for executing various types of orders, including limit, market, all or none, fill or kill, immediate or cancel, stop, stop limit; and spread orders. Preferably, there are numerous broker service modules 230 running on the exchange server 104, or on the interconnected computers in the cluster 102, where each broker service module 230 handles trades for a subset of products offered by the exchange. For example, there is preferably a broker service module 230 for each class of option contracts. The broker service module 230 thus matches incoming orders to other orders or to quotes supplied by market-makers to complete a trade, indicated by line 282 in FIG. 3.

The broker service module 230 also receives quotes from the quote service 240, discussed below. The broker service module 230 attempts to execute a trade 282 by matching incoming quotes to orders or to other quotes stored by the order book service module 142 in the order book. Note that for purposes of trade execution 282, quotes are treated by the exchange system 100 as if they were orders. Thus, when the broker service module 230 receives a quote that it cannot match to an existing order or quote, it sends the quote to the order book for storage with other unfilled quotes and orders. Preferably, quotes differ from regular orders in that a quote may be two sided, having a bid and an offer price, and that each market-maker may only have one quote per product in the system.

To facilitate the order matching process of trade execution 282, the broker service module 230 has direct access to orders stored in the order book by the order book service module 142. Preferably, when the incoming order is matched to an existing quote supplied by the quote service module 240, the broker service module 230 provides the quote service module 240 with details of the trade.

The quote service module 240 manages the quotes supplied by market-makers via client application service module 210. The quote service module 240 submits the quotes to the broker service module 230 for execution. The quote service module 240 ensures that each individual market-maker has only one quote per product in the system at any given time. When a market-maker enters a new quote on a product for which he already has an outstanding quote, the quote service module preferably determines whether there is already an existing quote in the system for that market-maker and, if so, informs the broker service module 230 that the pre-existing quote is to be cancelled. The quote service module 240 submits the new quote to the broker service module 230 only after it has received acknowledgement from the broker service module 230 that the pre-existing quote has been cancelled.

The broker service module 230 issues fill reports to notify various other modules, and ultimately the trading entities, that the trade was executed. Upon notification of a fill 284 from the broker service module 230 (or the order book module), the quote service module 240 informs the quote object 250. In turn, the market-maker is notified of the fill via the exchange's reporting system. The quote service module 240 also cancels or updates a market-maker quote upon receiving a request from the originating market-maker by submitting the request to the broker service 230. The quote service module performs this by first informing broker service module 230 that the pre-existing quote has been cancelled. The broker service module 230 then removes the quote from the order book and confirms to the quote service 240 that the quote has been cancelled. The quote service 240 then submits the new quote (if one exists) to the broker service module 230.

With respect to FIG. 3, a preferred sequence of events and messages will be described. Market-Makers log into a client application server module 210 and access the user service module 260. The market-maker communicates with the user service module 260 through a terminal, such as a workstation or wireless handheld unit. As shown by line 270, trading parameters, or quote parameters, are sent to the user service module 260. Upon initialization of the quote service, or upon login of a new market-maker, various trading parameters are provided to the quote service module 240 as shown by line 271. The trading parameters may include a risk threshold, a quote regeneration indicator, a quote regeneration increment, a quote modification indicator, and a quote modification increment. The parameters may include numerous sets of thresholds, indicators, and increments, preferably one such set for each class for which the market-maker is providing quotes.

The quote service module 240 receives quotes from market-makers as shown by line 272, and provides these quotes to the quote objects 250, 252, as shown by update lines 273, 274, and to the broker service module 230 as shown by line 276. As mentioned above, the quote service module 240 will not forward updated quotes (as opposed to new quotes) to the broker service module 230 before first canceling old quotes.

Orders received by the client application server 210 are routed to the order handling service 220 as shown by line 278. The order is then forwarded to the appropriate broker service 230 as shown by line 280. The broker service module 230 attempts to execute every order or quote received with the best order (or quote) in the book as shown by line 282. When a trade is executed, a fill report is issued to the quote service module 240 as shown by line 284. The quote service module 240 then analyzes the trade and determines whether the market-maker's risk threshold has been exceeded, as shown by line 286. The threshold test will be described in further detail below. A fill report is sent to the quote object 250 as shown by line 288. The quote object 250 then informs market-maker of the fill through the use of a trade report service module (not shown).

In addition, at steps 286 and 287, the quote service module may modify quotes in response to the trade in accordance with the market-maker's trading parameters, as discussed below. The quote service module then reports the new quotes to the broker service module 230 as shown by line 290. The broker service 230 acknowledges the quote updates as shown by line 292. If the broker service 230 has already processed additional trades against the original quote, then the broker service module 230 would respond with a “too late to cancel” message. Once the update acknowledge has been received, the quote service module 240 updates the quote objects 250, 252, as shown by lines 294, 296. The quote objects then inform the market-maker that its quotes have been updated.

Risk Measurements and Risk Thresholds

In a preferred embodiment of the automated trading system 100 having integrated order modification and quote risk monitoring, the aggregate risk of a market-maker's recent trades is calculated after each trade. The measurement preferably includes either calculating an equivalent stock position, i.e., a net delta (by, for example, summing delta values for all contracts traded by the market-maker associated with the option series in the class), or calculating a net gamma, theta, or vega.

In particular, the aggregate risk measurement is preferably the net delta of all the trades for a specific market-maker or a designated group of market-makers in a given class in a given period of time. The quotes in a given class submitted by a market-maker (or a group of market-makers) are referred to herein as a quote group. The rules for delta calculations are as listed below:

Calls (delta value Δ is positive)

    • Market-maker selling
    • Market-maker position will be Negative Delta
    • Market-maker buying
    • Market-maker position will be Positive Delta
      Puts (delta value Δ is negative)
    • Market-maker selling
    • Market-maker position will be Positive Delta
    • Market-maker buying
    • Market-maker position will be Negative Delta

The aggregate risk net delta is defined as:

Δ NET = ∑ i ⁢ S i · Δ i · U i · K i , ( 1 )
which is the summation for i trades of the product of S, the sign of the trade, where S is positive when a market-maker buys and negative when a market-maker sells, Δ (delta), which is rate of change of the price of the individual series with respect to the stock, and ranges from −1.0 to 0 for puts and 0 to 1.0 for calls, U, which is the unit of trade, i.e. the number of shares, and K, the number of contracts traded by the market-maker.

The aggregate risk measurement is preferably based on the net delta ΔNET for the entire class of options, which is the sum of all the deltas for a given market-maker's trades in all series of a class. The delta contribution for each trade is calculated every time a trade occurs for any series in the class. The aggregate risk is then calculated by summing delta contributions from only the most recent trades. The values for the theoretical deltas Δi are preferably obtained by an autoquote system (not shown) associated with the exchange system 100, and more particularly with the business services package 132.

Autoquote systems provide pricing information, and specifically theoretical delta values Δi, using well-known algorithms that utilize standard parameters, as is understood to those of skill in the art. Most of the parameters associated with calculating an individual series delta value are objective data, such as the date, strike price, the price of the underlying security, etc. Other autoquote parameters have acceptable default values that may be used, such as using the broker loan rate for the interest rate, etc. One parameter that may be more subjective among individual market-makers is the volatility parameter. Thus, the system 100 may be designed such that each quote submitted by a market-maker includes a volatility field to be used by the system in determining the individual theoretical delta value Δi. The theoretical delta value Δi may then be calculated either as part of the threshold, test, or may be periodically updated at a rate sufficient to provide a fairly accurate delta value Δi. In this way, the system 100 provides the market-maker with further control over the quote risk monitoring system.

Because the exchange quote modification service is intended to address increased risks associated with a rapid sequence of trades, older trades need not be included because the market-maker has had an opportunity to manually intervene and modify his quotes. Thus, the aggregate risk measurement may be based on the last N trades, where N is a trading parameter specified by the market-maker, or may be based on trades occurring within a specific time frame. The duration of the time frame may be specified by the market-maker by providing a time window parameter tK, which is included as a trading parameter. Alternatively, a default value for tK may be used.

Alternatively, the risk threshold and risk measurement may include an aggregate gamma measurement. Gamma is known to those of skill in the art to be the rate of change of the delta parameter with respect to the rate of change of the underlying security, such as the stock. An aggregate gamma measurement provides an indication of the rate at which an aggregate delta measurement will change. Net gamma values are negative when a market-maker is a net seller of contracts, and positive when a market-maker is a net buyer of contracts. As a further alternative, either theta, which is the rate at which option prices change over time, or vega, which is the change in an option contract that results from, a change in its volatility, may be included.

The market-maker may provide a single threshold ΔNETMAX such that if the absolute value of the aggregate risk exceeds the threshold, then the quotes are modified according to the rules set forth below. The market-maker may also provide positive and negative thresholds Δ+NETMAX and Δ−NETMAX to accommodate a market-maker's pre-existing risk bias.

In an alternative preferred embodiment, the market-maker's risk is determined by calculating the net contract volume traded within a specified time. The net contract volume KNET may be calculated by using equation (1) above, with the exception that the delta value is replaced by the sign of Δ, or ±1, where calls are positive 1, and puts are negative 1:

K NET = ∑ i ⁢ S i · sign ⁡ ( Δ i ) · U i · K i , for ⁢ ⁢ each ⁢ ⁢ trade , i . ( 2 )

The result is that the volume of each trade is treated as a positive or negative value, depending upon the nature of the trade—selling calls and buying puts have negative contributions, and buying calls and selling puts have positive contributions. The sum of the trades is then calculated to provide a net difference between the number of short calls plus long puts and long calls plus short puts. Thus, the market-makers may specify a threshold in terms of a maximum net contract volume offset, KNETMAX (or positive and negative thresholds K+NETMAX and K−NETMAX to accommodate a market-maker's pre-existing risk bias). As stated above, the system may be configured to also allow the market-makers to specify a time window parameter tK that specifies which trades should be included in the risk calculation. Thus, only the contracts K that have been executed within the previous t seconds will be included in equation 2. Alternatively, the system may be configured to specify i, the number of previous trades to include in the risk calculation.

In still further embodiments, the aggregate risk measurement may be simplified by calculating the total number of put or call contracts (or deltas) that have been sold or bought within a given time frame or within that last N trades. Thus, for example, when a market-maker has just sold a put, the quote service module 240 may calculate the total number of puts sold (or the delta due to all the puts sold) within the given trading window and compare it to a threshold. If the next trade is a call purchase, then the system would calculate the contracts or deltas for the calls purchased. Thus, if any of the four aggregate volume quantities (buying calls, selling calls, buying puts, selling puts) exceeds a threshold (within a certain time period, or certain number of trades), the quote modification module 340 modifies the quotes appropriately. Alternatively, the quote service module 240 may calculate the total calls bought plus puts sold, and the total calls sold plus puts bought, and notify the quote modification module 340 if either of these aggregate values exceeds the threshold. As a further alternative, the quote service module may use a weighting scheme to calculate aggregate values described above. Specifically, in-the-money options (options with intrinsic value) may be weighted more heavily than at-the-money or out-of-the-money options. In one preferred method, the in-the-money options are weighted with a factor of two, at-the-money options are weighted with a factor of one, and out-of-the-money options are weighted by a factor of one half. These simplified risk measurement and threshold tests perform adequately due to the nature of trading activities that typically result in large risk exposure.

It should also be noted that the market-makers may be grouped together for purposes of risk exposure analysis. That is, the total risk may be calculated based on the trades of one or more market-makers. The market-makers provide a group identification parameter(s) indicating which other market-makers' trades should be included in the risk calculation. In this manner, market-makers acting in concert on behalf of a single organization may coordinate their quote modification.

Automatic Quote Modification

The quote service module 240 of the exchange system 100 includes a quote modification service module 340. The quote modification service module 340 may be implemented as part of the quote service module 240, or may be a separate service module. It may also take the form of a separate quote factory module for generating new instantiations of quote objects. The quote modification service module 340 performs quote modification by preferably automatically revising, canceling, or regenerating quotes. The quote modification service module 340 resides on the exchange system computer 104, 106, or computer cluster 102. The quotes are modified by the exchange system in an automatic manner that does not require further input from the market-maker in the form of quote cancellation requests and submission of new quotes by the market-maker or his computer. In this way, the exchange system performs quote modification immediately and without the transmission delays inherent in communication systems and without delays associated with processing queued cancellation requests received from a remote location.

If the quote service module 240 determines that the threshold(s) have been exceeded, the quote service module 240 determines revised quotes and forwards them to the broker service module 230 and the quote objects 250, 252. The revised quotes can take numerous forms. In a first embodiment, the quote service module 240 revises quotes by canceling all outstanding quotes in the class, thereby preventing any further trades from executing and giving the market-maker time to provide revised quotes. In this embodiment, the quote service module 240 sends quote update messages 290 in the form of cancellation messages to the broker service module 230. The broker service 230 then removes those quotes from the electronic book. Because the threshold test is performed by the exchange system 100 after each trade, the cancellation messages are therefore preferably processed before any further trades can be executed. This is possible because the cancellation requests are not sent from a remote node on a wide area network, such as a market-maker's computing platform, but are generated by the exchange system 100. This provides the advantage of eliminating a cancellation message queue, as would be used when sending cancellation requests from a remote node, thereby improving quote update times and providing risk management.

In a second embodiment, the quote service module 240 revises quotes by reducing the quantity associated with the existing quotes in the class thereby reducing the amounts of potential further trades and reducing the market-maker's exposure to more risk. The market-maker may specify the amount of the volume decrease by way of an increment value. In this embodiment, the quote service module 240 sends quote updates 290 by first sending quote cancellation messages to the broker service module 230, and after acknowledgment, sending the revised quotes to the broker service module 230 for execution or booking. Again, because the threshold test is performed by the exchange system 100 after each trade, the cancellation messages are therefore preferably processed before any further trades can be executed. As above, this is possible because the cancellation requests are not sent from a remote node on a wide area network, such as a market-maker's computing platform, but are generated by the exchange system 100.

In a third embodiment, the quote service module 240 revises quotes by decreasing the bid and offer values of some quotes and increasing others in an attempt to cancel some of the risk already assumed by the market-maker. The quote service 240 does this by automatically adjusting quotes to favor trades that will tend to provide offsetting risk. Specifically, if the threshold (KNETMAX or ΔNETMAX) has been exceeded by a high positive-valued net delta (or K), then the net delta (or K) may be offset by trades having a negative delta (or K). As set forth above, those trades would include selling calls and buying puts. Similarly, if the threshold has been exceeded by a high negative-valued net delta (or K), then the aggregate risk may be offset by trades having a positive delta (or K), or by selling puts and buying calls. Of course, to produce the desired trades, the lowering of offer values of quotes will tend to result in more selling activity by the market-maker, and the raising of bid values will result in more buying activity by the market-maker. In this embodiment, the modification increment is specified by an increment value. As in the previous embodiment, the quote service module 240 sends quote updates 290 by sending quote cancellation messages to the broker service module 230, and after acknowledgment, sending the revised quotes to the broker service module 230 for execution or booking. Again the automated risk monitoring system and quote modification service of system 100 provides advantages in that the market-maker need not cancel previous quotes and submit new quotes while still being exposed to the possibility of further trades being executed.

The quote service 240 may also modify quotes by regenerating the just-filled quote. This may be performed even if the market-maker's risk threshold has not been exceeded. The market-maker is able to specify quote regeneration parameters via client application server 210 that are stored in the user service module 260. The parameters specify which products are enabled for quote regeneration, and the extent to which the quotes are to be regenerated. The market-maker may therefore specify, on a product-by-product basis, how many times the quotes are to be regenerated after each quote has been filled. This is referred to herein as the regeneration number parameter. The market-maker may also specify whether the regenerated quotes are to have the same bid and offer values, or are to be backed-off from the previous trade. This parameter is referred to herein as the regeneration increment. That is, for a two-sided quote, if the market-maker has just sold a quantity of contracts at his offer price, the regenerated quote may have a higher offer value. Preferably the bid value is also raised accordingly to maintain a desired or required spread in bid and offer quotes. If, on the other hand, the market-maker has just bought a quantity of contracts at his bid price, the regenerated quote may have a lower bid value. The market-maker also has the option of specifying on a per-class basis the values of the regeneration number parameter and the regeneration increment parameter. The quote regeneration is preferably not performed if the market-maker risk threshold has been exceeded, unless the market-maker has specifically selected quote revision in the event the risk threshold has been exceeded.

With reference to FIG. 4, the method of quote modification 300 will be described. Upon execution of a trade at step 310, the quote service module 240 at step 320 checks to see whether the individual market-maker's risk threshold has been exceeded. As mentioned above, the risk measurement and threshold test may be performed using a variety of methods, and certain market-makers' trading activities may be combined for the purposes of risk exposure. If the threshold has not been exceeded, then at step 330 the quote service module 240 preferably checks to see whether the market-maker whose quote has been executed has indicated the desire to have his quotes regenerated. If not, then the process has completed. In the event that the result of either inquiry 320, 330 is affirmative, then the quote service 240 modifies the quotes with the quote modification module 340 as described above.

Quote modification module 340 includes quote regeneration module 350 and cancel or revise quote module 360. As mentioned above, the quote modification module 340 may be integral to quote service module 240, or may be included in a quote factory module, or may be a separate service module. The quotes are regenerated, cancelled, or revised, for example as described above, and submitted as shown in step 370 to the broker service module 230 for execution.

Preferred embodiments of the present invention have been described herein. It is to be understood, of course, that changes and modifications may be made in the embodiments without departing from the true scope of the present invention, as defined by the appended claims. The present embodiment preferably includes logic to implement the described methods in software modules as a set of computer executable software instructions. A Central Processing Unit (“CPU”), or microprocessor, implements the logic that controls the operation of the transceiver. The microprocessor executes software that can be programmed by those of skill in the art to provide the described functionality.

The software can be represented as a sequence of binary bits maintained on a computer readable medium including magnetic disks, optical disks, and any other volatile or (e.g., Random Access memory (“RAM”)) non-volatile firmware (e.g., Read Only Memory (“ROM”)) storage system readable by the CPU. The memory locations where data bits are maintained also include physical locations that have particular electrical, magnetic, optical, or organic properties corresponding to the stored data bits. The software instructions are executed as data bits by the CPU with a memory system causing a transformation of the electrical signal representation, and the maintenance of data bits at memory locations in the memory system to thereby reconfigure or otherwise alter the unit's operation. The executable software code may implement, for example, the methods as described above.

It should be understood that the programs, processes, methods and apparatus described herein are not related or limited to any particular type of computer or network apparatus (hardware or software), unless indicated otherwise. Various types of general purpose or specialized computer apparatus or computing device may be used with or perform operations in accordance with the teachings described herein.

It should be understood that a hardware embodiment may take a variety of different forms. The hardware may be implemented as an integrated circuit with custom gate arrays or an application specific integrated circuit (“ASIC”). Of the course, the embodiment may also be implemented with discrete hardware components and circuitry. In particular, it is understood that the logic structures and method steps described herein may be implemented in dedicated hardware such as an ASIC, or as program instructions carried out by a microprocessor or other computing device.

The claims should not be read as limited to the described order of elements unless stated to that effect. In addition, use of the term “means” in any claim is intended to invoke 35 U.S.C. §112, paragraph 6, and any claim without the word. “means” is not so intended. Therefore, all embodiments that come within the scope and spirit of the following claims and equivalents thereto are claimed as the invention.

Claims

1. An electronic trading system configured to automatically bypass message queue delays and communication delays for certain trading messages, the electronic trading system comprising:

means for receiving and processing trading messages, the trading messages comprising quote messages, quote modification messages, and orders messages transmitted electronically through an electronic communications network from computers geographically remote from the means for receiving and processing trading messages;
wherein the electronic trading system further comprises a message queue through which quote messages, quote modification messages, and order messages pass when received by the means for receiving and processing trading messages from the geographically remote computers;
the means for receiving and processing trading messages further comprising: storage means for electronically storing received quote messages and order messages, wherein the quote messages belong to a quote group having an associated risk threshold; matching and execution means for matching received quote messages with received order messages and, upon the creation of a match, executing a trade based on the match; quote modification means for automatically and locally generating an exchange quote modification message for bypassing processing of quote messages, quote modification messages, and order messages received from the geographically remote computers, and inserting for immediate processing the exchange quote modification message upon identification of a quote modification event; wherein, upon the execution of the trade based on the match, the quote modification means determines a risk level corresponding to the trade and an aggregate risk level corresponding to the trade and other trades belonging to the quote group, compares the aggregate risk level to the risk threshold of the quote group, and identifies the quote modification event when the aggregate risk level exceeds the risk threshold of the quote group; and
wherein the means for receiving and processing trading messages is further configured to process the exchange quote modification message by cancelling the received quote messages belonging to the quote group that are stored electronically in the storage means.
Referenced Cited
U.S. Patent Documents
3581072 May 1971 Nymeyer
3766322 October 1973 Moffett et al.
3967250 June 29, 1976 Senda et al.
4412287 October 25, 1983 Braddock, III
4502139 February 26, 1985 Matsufuji
4554418 November 19, 1985 Toy
4591983 May 27, 1986 Bennett et al.
4598367 July 1, 1986 DeFrancesco et al.
4674044 June 16, 1987 Kalmus et al.
4677552 June 30, 1987 Sibley, Jr.
4722055 January 26, 1988 Roberts
4727343 February 23, 1988 Stone
4734564 March 29, 1988 Boston et al.
4751640 June 14, 1988 Lucas et al.
4752877 June 21, 1988 Roberts et al.
4774663 September 27, 1988 Musmanno et al.
4799156 January 17, 1989 Shavit et al.
4823265 April 18, 1989 Nelson
4874935 October 17, 1989 Younger
4903201 February 20, 1990 Wagner
4947028 August 7, 1990 Gorog
4980826 December 25, 1990 Wagner
5007049 April 9, 1991 Ohtsuka
5038284 August 6, 1991 Kramer
5063507 November 5, 1991 Lindsey et al.
5077665 December 31, 1991 Silverman et al.
5101353 March 31, 1992 Lupien et al.
5126936 June 30, 1992 Champion et al.
5128861 July 7, 1992 Kagami et al.
5132899 July 21, 1992 Fox
5136501 August 4, 1992 Silverman et al.
5148365 September 15, 1992 Dembo
5161103 November 3, 1992 Kosaka et al.
5168445 December 1, 1992 Kawashima et al.
5168446 December 1, 1992 Wiseman
5183142 February 2, 1993 Latchinian et al.
5237620 August 17, 1993 Deaton et al.
5243331 September 7, 1993 McCausland et al.
5297031 March 22, 1994 Gutterman et al.
5297032 March 22, 1994 Trojan et al.
5305200 April 19, 1994 Hartheimer et al.
5315634 May 24, 1994 Tanaka et al.
5339392 August 16, 1994 Risberg et al.
5353326 October 4, 1994 Jung
5361199 November 1, 1994 Shoquist et al.
5420405 May 30, 1995 Chasek
5463547 October 31, 1995 Markowitz et al.
5481647 January 2, 1996 Brody et al.
5508913 April 16, 1996 Yamamoto et al.
5557517 September 17, 1996 Daughterty, III
5557780 September 17, 1996 Edwards et al.
5612606 March 18, 1997 Guimarin et al.
5623601 April 22, 1997 Vu
5644727 July 1, 1997 Atkins
5664115 September 2, 1997 Fraser
5689652 November 18, 1997 Lupien et al.
5694546 December 2, 1997 Reisman
5704045 December 30, 1997 King et al.
5727165 March 10, 1998 Ordish et al.
5729700 March 17, 1998 Melnikoff
5732400 March 24, 1998 Mandler et al.
5774873 June 30, 1998 Berent et al.
5774877 June 30, 1998 Patterson, Jr. et al.
5787402 July 28, 1998 Potter et al.
5793301 August 11, 1998 Patterson, Jr. et al.
5794207 August 11, 1998 Walker et al.
5797002 August 18, 1998 Patterson, Jr. et al.
5799285 August 25, 1998 Klingman
5799286 August 25, 1998 Morgan et al.
5806048 September 8, 1998 Kiron et al.
5806050 September 8, 1998 Shinn et al.
5809483 September 15, 1998 Broka et al.
5819237 October 6, 1998 Garman
5832462 November 3, 1998 Midorikawa et al.
5845266 December 1, 1998 Lupien et al.
5848400 December 8, 1998 Chang
5857176 January 5, 1999 Ginsberg
5870456 February 9, 1999 Rogers
5873071 February 16, 1999 Ferstenberg et al.
5884286 March 16, 1999 Daughtery, III
5903633 May 11, 1999 Lorsch
5913202 June 15, 1999 Motoyama
5915209 June 22, 1999 Lawrence
5915245 June 22, 1999 Patterson, Jr. et al.
5920630 July 6, 1999 Wertheimer et al.
5924082 July 13, 1999 Silverman et al.
5924083 July 13, 1999 Silverman et al.
5924108 July 13, 1999 Fein et al.
5930762 July 27, 1999 Masch
5946666 August 31, 1999 Nevo et al.
5950176 September 7, 1999 Keiser et al.
5950177 September 7, 1999 Lupien et al.
5953423 September 14, 1999 Rosen
5963923 October 5, 1999 Garber
5970479 October 19, 1999 Shepherd
5978778 November 2, 1999 O'Shaughnessy
5978780 November 2, 1999 Watson
5987419 November 16, 1999 Hachino et al.
5987440 November 16, 1999 O'Neil et al.
5995947 November 30, 1999 Fraser et al.
6012046 January 4, 2000 Lupien et al.
6014627 January 11, 2000 Togher et al.
6014643 January 11, 2000 Minton
6016483 January 18, 2000 Rickard et al.
6021397 February 1, 2000 Jones et al.
6021398 February 1, 2000 Ausubel
6023708 February 8, 2000 Mendez et al.
6029146 February 22, 2000 Hawkins et al.
6029154 February 22, 2000 Pettitt
6039688 March 21, 2000 Douglas et al.
6058379 May 2, 2000 Odom et al.
6061662 May 9, 2000 Makivic
6064985 May 16, 2000 Anderson
6072870 June 6, 2000 Nguyen
6078904 June 20, 2000 Rebane
6085169 July 4, 2000 Walker et al.
6085192 July 4, 2000 Mendez et al.
6092057 July 18, 2000 Zimmerman et al.
6098051 August 1, 2000 Lupien et al.
6112189 August 29, 2000 Rickard et al.
6115709 September 5, 2000 Gilmour
6119103 September 12, 2000 Basch et al.
6119105 September 12, 2000 Williams
6119596 September 19, 2000 Fletcher et al.
6131087 October 10, 2000 Luke et al.
6134535 October 17, 2000 Belzberg
6141653 October 31, 2000 Conklin et al.
6148293 November 14, 2000 King
6154879 November 2000 Pare, Jr. et al.
6167378 December 26, 2000 Webber, Jr.
6173270 January 9, 2001 Cristofich et al.
6175552 January 16, 2001 Parry et al.
6175824 January 16, 2001 Breitzman et al.
6175918 January 16, 2001 Shimizu
6192354 February 20, 2001 Bigus et al.
6195647 February 27, 2001 Martyn et al.
6199050 March 6, 2001 Alaia et al.
6226623 May 1, 2001 Schein
6233566 May 15, 2001 Levine et al.
6247000 June 12, 2001 Hawkins et al.
6253115 June 26, 2001 Martin et al.
6263321 July 17, 2001 Daughtery, III
6269346 July 31, 2001 Cristofich et al.
6272474 August 7, 2001 Garcia
6278982 August 21, 2001 Korhammer et al.
6282521 August 28, 2001 Howorka
6285989 September 4, 2001 Shoham
6289319 September 11, 2001 Lockwood
6290646 September 18, 2001 Cosentino et al.
6301471 October 9, 2001 Dahm et al.
6304858 October 16, 2001 Mosler et al.
6311166 October 30, 2001 Nado et al.
6317727 November 13, 2001 May
6317728 November 13, 2001 Kane
6321212 November 20, 2001 Lange
6328766 December 11, 2001 Long
6330544 December 11, 2001 Walker et al.
6334133 December 25, 2001 Thompson et al.
6343278 January 29, 2002 Jain et al.
6360210 March 19, 2002 Wallman
6377940 April 23, 2002 Tilfors et al.
6385730 May 7, 2002 Garrison
6393423 May 21, 2002 Goedken
6405180 June 11, 2002 Tilfors et al.
6408282 June 18, 2002 Buist
6418419 July 9, 2002 Nieboer et al.
6421653 July 16, 2002 May
6430562 August 6, 2002 Kardos
6442525 August 27, 2002 Silverbrook
6493682 December 10, 2002 Horrigan et al.
6505174 January 7, 2003 Keiser et al.
6505175 January 7, 2003 Silverman et al.
6507818 January 14, 2003 Fishman et al.
6539362 March 25, 2003 Patterson, Jr. et al.
6539396 March 25, 2003 Bowman-Amuah
6553350 April 22, 2003 Carter
6564192 May 13, 2003 Kinney, Jr. et al.
6571282 May 27, 2003 Bowman-Amuah
6594643 July 15, 2003 Freeny, Jr.
6594692 July 15, 2003 Reisman
6601627 August 5, 2003 Kasai et al.
6618707 September 9, 2003 Gary
6629081 September 30, 2003 Cornelius et al.
6647374 November 11, 2003 Kansal
6658393 December 2, 2003 Basch et al.
6662357 December 9, 2003 Bowman-Amuah
6691094 February 10, 2004 Herschkorn
6721715 April 13, 2004 Nemzow
6732161 May 4, 2004 Hess et al.
6741992 May 25, 2004 McFadden
6785661 August 31, 2004 Mandler et al.
6826690 November 30, 2004 Hind et al.
6850643 February 1, 2005 Smith, II et al.
6850907 February 1, 2005 Lutnick et al.
6856964 February 15, 2005 Sadler
6937990 August 30, 2005 Walker et al.
6938022 August 30, 2005 Singhal
6968318 November 22, 2005 Ferstenberg et al.
7003489 February 21, 2006 Dixon, III et al.
7035819 April 25, 2006 Gianakouros et al.
7080033 July 18, 2006 Wilton et al.
7080050 July 18, 2006 Himmelstein
7099839 August 29, 2006 Madoff et al.
7165041 January 16, 2007 Guheen et al.
7165045 January 16, 2007 Kim-E
7167860 January 23, 2007 Black
7171386 January 30, 2007 Raykhman
7177833 February 13, 2007 Marynowski et al.
7181424 February 20, 2007 Ketchum et al.
7181425 February 20, 2007 Cha
7181427 February 20, 2007 DeFrancesco et al.
7206755 April 17, 2007 Muralidhar
7209896 April 24, 2007 Serkin et al.
7212999 May 1, 2007 Friesen et al.
7219080 May 15, 2007 Wagoner et al.
7246093 July 17, 2007 Katz
7249080 July 24, 2007 Hoffman et al.
7249108 July 24, 2007 Walmsley
7251629 July 31, 2007 Marynowski et al.
7287006 October 23, 2007 Kratka
7321872 January 22, 2008 Kaminsky et al.
7340432 March 4, 2008 Lundberg et al.
7356498 April 8, 2008 Kaminsky
7373324 May 13, 2008 Engin et al.
7389262 June 17, 2008 Lange
7392395 June 24, 2008 Ginter
7403922 July 22, 2008 Lewis et al.
7415436 August 19, 2008 Evelyn et al.
7430516 September 30, 2008 Blair
7451105 November 11, 2008 Doyle
7464052 December 9, 2008 Coppola, III
7487123 February 3, 2009 Keiser et al.
7523194 April 21, 2009 Strohwig et al.
7529704 May 5, 2009 Breslow
7536335 May 19, 2009 Weston et al.
7571136 August 4, 2009 May
7617144 November 10, 2009 Madoff et al.
7627516 December 1, 2009 Gianakouros et al.
7636683 December 22, 2009 Mills et al.
7672889 March 2, 2010 Brooks
7720742 May 18, 2010 Mauro
7774260 August 10, 2010 Howorka et al.
7797227 September 14, 2010 Fraser
7801795 September 21, 2010 Nunes et al.
7908203 March 15, 2011 Shapiro et al.
7921055 April 5, 2011 Kaminsky et al.
7980457 July 19, 2011 Kaminsky et al.
8010438 August 30, 2011 Waelbroeck et al.
8010441 August 30, 2011 Brouwer
8095413 January 10, 2012 Beaven
8108229 January 31, 2012 Ika et al.
8239303 August 7, 2012 Martyn et al.
8266044 September 11, 2012 Kaminsky et al.
8296221 October 23, 2012 Waelbroeck et al.
8478687 July 2, 2013 Marynowski et al.
9026470 May 5, 2015 Nunes et al.
20010056393 December 27, 2001 Tilfors et al.
20020019795 February 14, 2002 Madoff et al.
20020091611 July 11, 2002 Minton
20020138390 September 26, 2002 May
20040024690 February 5, 2004 Satow et al.
20040030634 February 12, 2004 Satow et al.
20080071667 March 20, 2008 Himmelstein
Foreign Patent Documents
1194416 September 1998 CN
1238052 December 1999 CN
1325516 December 2001 CN
0 411 748 June 1989 EP
0 388 162 September 1990 EP
0 399 850 November 1990 EP
0 434 224 June 1991 EP
0 512 702 November 1992 EP
0 388 162 March 1993 EP
0 542 298 May 1993 EP
0 686 926 December 1995 EP
0 762 304 March 1997 EP
0 790 568 August 1997 EP
0 825 544 February 1998 EP
0 752 135 February 1999 EP
0 952 536 October 1999 EP
1 008 072 October 1999 EP
1 006 472 June 2000 EP
0 873 549 August 2001 EP
0 745 961 November 2001 EP
1 662 418 July 2006 EP
1 770 628 April 2007 EP
1 431 864 August 2012 EP
3-68067 March 1991 JP
6-28384 February 1994 JP
6-236383 August 1994 JP
H06-236383 August 1994 JP
9-81640 March 1997 JP
H09-81640 March 1997 JP
H10-320494 December 1998 JP
11-259559 September 1999 JP
H11-259559 September 1999 JP
90/10910 September 1990 WO
91/14231 September 1991 WO
94/28496 December 1994 WO
95/06918 March 1995 WO
95/26005 September 1995 WO
96/12242 April 1996 WO
96/18160 June 1996 WO
97/08640 March 1997 WO
97/22072 June 1997 WO
97/30407 August 1997 WO
97/43727 November 1997 WO
97/45802 December 1997 WO
98/12659 March 1998 WO
98/21667 May 1998 WO
98/26363 June 1998 WO
98/52133 November 1998 WO
98/59307 December 1998 WO
99/01983 January 1999 WO
99/17224 April 1999 WO
99/19821 April 1999 WO
99/41687 August 1999 WO
99/56232 November 1999 WO
00/16232 March 2000 WO
00/21013 April 2000 WO
00/26745 May 2000 WO
00/28449 May 2000 WO
00/28449 May 2000 WO
00/28449 May 2000 WO
00/28450 May 2000 WO
00/48053 August 2000 WO
00/48053 August 2000 WO
00/54191 September 2000 WO
00/65510 November 2000 WO
00/70506 November 2000 WO
00/70506 November 2000 WO
01/02930 January 2001 WO
01/08063 February 2001 WO
01/22263 March 2001 WO
01/22263 March 2001 WO
01/22269 March 2001 WO
01/22269 March 2001 WO
01/22313 March 2001 WO
01/22313 March 2001 WO
01/22315 March 2001 WO
01/22315 March 2001 WO
01/22332 March 2001 WO
01/22332 March 2001 WO
01/41006 June 2001 WO
01/50378 July 2001 WO
01/88808 November 2001 WO
01/88808 November 2001 WO
01/98959 December 2001 WO
01/98959 December 2001 WO
01/98962 December 2001 WO
01/98962 December 2001 WO
01/98965 December 2001 WO
01/98965 December 2001 WO
Other references
  • Amihud, Yakov et al., A New Approach to the Regulation of Trading Across Securities Markets, New York University Law Review, Dec. 1996, vol. 71, No. 6 (56 pages).
  • Andrei, Mihnea et al., Automating the Precision Trading System, Worcester Polytechnic Institute, May 26, 2013 (134 pages).
  • Assaf, Ata, Automation, Stock Market Volatility and Risk-Return Relationship: Evidence from “CATS”, Investment Management and Financial Innovations, Mar. 2005 (10 Pages).
  • ASX The Australian Sharemarket, Understanding Options Trading, Feb. 2013 (44 pages).
  • Australian Patent Office Examination Report issued in Singapore patent application No. SG 200105226-5, dated Mar. 30, 2006 (4 pages).
  • Australian Patent Office Search Report issued in Singapore patent application No. SG 200105226-5, dated Mar. 30, 2006 (4 pages).
  • Baird, Allen Jan, Option Market Making—Trading and Risk Analysis for the Financial and Commodity Option Markets, © 1993 (211 pages).
  • Banatre, Jean-Pierre et al., The Design and Building of Enchere, a Distributed Electronic Marketing System, Institut de Recherche en Informatique et Systèmes Aleatoires, Oct. 1984 (39 pages).
  • Bangia, Anil et al., Modeling Liquidity Risk, With Implications for Traditional Market Risk Measurement and Management, The Wharton School, Dec. 21, 1998 (18 pages).
  • Bansal, Arun et al., Financial risk and financial Risk Management Technology (RMT), Elsevier Science Publishers B.V., 1993 (16 pages).
  • Benhamou, Eric et al., On the Competition between ECNs, Stock Market and Market Makers, Dec. 1999 (29 pages).
  • Berkman, Henk, Large Option Trade, Market Makers, and Limit Orders, The Review of Financial Studies, Fall 1996, vol. 9, No. 3, pp. 977-1002 (26 pages).
  • Biais et al., “An Emperical Analysis of the Limit Order Book and the Order Flow in the Paris Bourse,” Dec. 1995, Journal of Finance, vol. 50, No. 5, pp. 1655-1690.
  • Bollerslev, Tim, Some Effects of Restricting the Electronic Order Book in an Automated Trade Execution System, vol. XIV Addison-Wesley 1993 (17 pages).
  • Burns, Joseph M., Electronic Trading in Futures Markets, Financial Analysts Journal, vol. 38, No. 1, Jan.-Feb. 1982, pp. 33-41 (10 pages).
  • Case CBM2013-00049 (7,356,498), Corrected Petition to Institute a Post-Grant Review Trial dated Sep. 16, 2013 (75 pages).
  • Case CBM2013-00049 (7,356,498), Patent Owner's Preliminary Response dated Dec. 11, 2013 (78 pages).
  • Case CBM2013-00050 (7,980,457), Corrected Petition to Institute a Post-Grant Review Trial dated Sep. 16, 2013 (55 pages).
  • Case CBM2013-00050 (7,980,457), Patent Owner's Preliminary Response dated Dec. 11, 2013 (78 pages).
  • Case CBM2013-00051 (8,266,044), Corrected Petition to Institute a Post-Grant Review Trial dated Sep. 16, 2013 (56 page).
  • Case CBM2013-00051 (8,266,044), Patent Owner's Preliminary Response dated Dec. 11, 2013 (78 pages).
  • Case IPR2014-00097 (7,356,498), Institution Decision, dated May 22, 2014 (29 pages).
  • Case IPR2014-00097 (7,356,498), International Securities Exchange, LLC's Petition to Institute an Inter Partes Review under 37 C.F.R. § 42.100 et seq. dated Nov. 12, 2013 (65 pages).
  • Case IPR2014-00097 (7,356,498), Patent Owner's Preliminary Response, dated Feb. 25, 2014 (60 pages).
  • Case IPR2014-00098 (7,980,457), Institution Decision, dated May 22, 2014 (20 pages).
  • Case IPR2014-00098 (7,980,457), International Securities Exchange, LLC's Petition to Institute an Inter Partes Review under 37 C.F.R. § 42.100 et seq. dated Nov. 12, 2013 (51 pages).
  • Case IPR2014-00098 (7,980,457), Patent Owner's Preliminary Response, dated Feb. 25, 2014 (45 pages).
  • Case IPR2014-00099 (8,266,044), Institution Decision, dated May 22, 2014 (14 pages).
  • Case IPR2014-00099 (8,266,044), International Securities Exchange, LLC's Petition to Institute an Inter Partes Review under 37 C.F.R. § 42.100 et seq. dated Nov. 12, 2013 (52 pages).
  • Case IPR2014-00099 (8,266,044), Patent Owner's Preliminary Response, dated Feb. 25, 2014 (46 pages).
  • Chavez, Anthony, A Real-Life Experiment in Creating an Agent Marketplace, Software Agents and Soft Computing Towards Enhancing Machine Intelligence Lecture Notes in Computer Science, vol. 1198, 1997, pp. 160-179 (20 pages).
  • Chow, Edward H. et al., Trading mechanisms and trading preferences on a 24-hour futures market: A case study of the Floor/GLOBEX switch on MATIF, Journal of Banking and Finance, 1996 (19 pages).
  • Clemons, Eric K., Restrucring Institutional Block Trading: An Overview of the OptiMark System, 1998 IEEE (10 pages).
  • Cliff, Dave et al., Less Than Human: Simple adaptive trading agents for CDA markets, 1997 (6 pages).
  • Cliff, Dave et al., Shop 'Til You Drop I: Market Trading Interactions as Adaptive Behavior, Hewlett-Packard Company, 1998 (12 pages).
  • Cliff, Dave et al., Simple Bargaining Agents for Decentralized Market-Based Control, Hewlett-Packard Company, 1998 (9 pages).
  • Cliff, Dave, Minimal-Intelligence Agents for Bargaining Behaviors in Market-Based Environments, School of Cognitive and Computing Sciences, University of Sussex, Jun. 1997 (134 pages).
  • Coppejans, Mark et al., Automated Trade Execution and Open Outcry Trading a First Look at the GLOBEX Trading System, Feb. 1997 (55 pages).
  • Curcio, Riccardo et al., Do Technical Trading Rules Generate Profits? Conclusions from the Intra-Day Foreign Exchange Market, Jun. 1997 (27 pages).
  • Dasgupta, Prithviraj et al., MAgNET: Mobile Agents for Networked Electronic Trading, IEEE Transactions on Knowledge and Data Engineering, vol. 11, No. 4, Jul./Aug. 1999 (17 pages).
  • De Bel, Jan, Automated Trading Systems and the Concept of an “Exchange” in an International Context Proprietary Systems: A Regulatory Headache!, U. Pa. J. Int'l Bus. L., 1993 (43 pages).
  • Decision on Refusal issued in Japanese patent application No. 2001-550665, dispatch date: Dec. 6, 2005 (5 pages).
  • Demarchi, Marianne et al., Equity Trading Systems in Europe—A survey of recent changes, Feb. 1998 (54 pages).
  • Dittmar, Thomas et al., SIMBA An Electronic Trading System for Internal Markets in Banks , Nov. 1998 (31 pages).
  • Domowitz, Ian et al., Automation, Trading Costs, and the Structure of the Securities Trading Industry, Department of Economics and Institute for Policy Research, 1997 (30 pages).
  • Domowitz, Ian et al., Automation, Trading Costs, and the Structure of the Securities Trading Industry, Brookings-Wharton Papers on Financial Services: 1999 (60 pages).
  • Domowitz, Ian, Automating the Price Discovery Process: Some International Comparisons and Regulatory Implications, Journal of Financial Services Research 305-326, 1992 (22 pages).
  • Examiner's first report on Australian patent application No. 22765/01, dated Nov. 20, 2002 (1 page).
  • Fan, Ming et al., A Web-Based Financial Trading System, IEEE 1999 (7 pages).
  • Foreign Exchange Risk Management—A primer on protecting and increasing profits in international transactions and investments, Currency Risk Management, LLC, 2012 (27 pages).
  • Frankel, Jeffrey A. et al., The Microstructure of Foreign Exchange Markets, University of Chicago Press, Jan. 1996, pp. 41-72 (32 pages).
  • Frankel, Jeffrey A. et al., The Microstructure of Foreign Exchange Markets, University of Chicago Press, Jan. 1996, pp. 107-182 (76 pages).
  • Freedman, Roy S. et al., Market Analysis for Risk Management and Regulation: An Artificial Intelligence Approach, 1995 (11 pages).
  • Freund, William C. et al., Market Efficiency Before and After the Introduction of Electronic Trading at the Toronto Stock Exchange, Review of Financial Economics, 1997, vol. 6, No. 1, pp. 29-56 (28 pages).
  • Frino, Alex et al., The liquidity of automated exchanges: new evidence from German Bund futures, Journal of International Financial Markets, Institutions and Money, Aug. 31, 1998 (17 pages).
  • Furst, Karen et al., Special Studies on Technology and Banking, Technological Innovation in Banking and Payments: Industry Trends and Implication for Banks, Quarterly Journal, vol. 17, No. 3, Sep. 1998 (9 pages).
  • Gibson, Michael S., Information Systems for Risk Management, Board of Governors of the Federal Reserve System International Finance Discussion Papers, No. 585, Jul. 1997 (29 pages).
  • Gibson, Michael, Information systems for risk management, Federal Reserve Board, Mar. 1997 (18 pages).
  • Hailpern, Brent et al., An Architecture for Dynamic Reconfiguration in a Distributed Object-Based Programming Language, Sep. 20, 1991 (32 pages).
  • Hamao, Yasushi et al., Securities Trading in the Absense of Dealers: Trades and Quotes on the Tokyo Stock Exchange, Working Paper No. 90, Nov. 1994 (46 pages).
  • Harris, Lawrence E., Circuit Breakers and Program Trading Limits: What Have We Learned?, Brookings-Wharton Papers on Financial Services, Dec. 9, 1997 (34 pages).
  • Harris, Lawrence et al., Market vs. Limit Orders: The SuperDOT Evidence on Order Submission Strategy, Feb. 19, 1996 (31 pages).
  • Hawawini, Gabriel et al., The Integration of EEC Equity Markets: Analysis and Implications for Switzerland, 1990 (18 pages).
  • Hellström, Thomas, A Random Walk through the Stock Market, Dec. 10, 1998 (127 pages).
  • Inagaki, Toshiyuki, Adaptive Automation: Sharing and Trading of Control, Chapter 8 of the Handbook of Cognitive Task Design, pp. 147-169, 2003 (34 pages).
  • J.P. Morgan/Reuters, RiskMetrics™—Technical Document, Fourth Edition, 1996 (210 pages).
  • Ju, Xiogwei et al., Using Value-at-Risk to Control Risk Taking: How to Wrong Can You Be?, OFOR Paper No. 98-08, Oct. 1998 (33 pages).
  • Katsoris, Constantine N., New Rules and Regulations, 1998 (31 pages).
  • Kirkland, J. Dale et al., The NASD Regulation Advanced-Detection System (ADS), Artificial Intelligence Magazine, vol. 20, No. 1, Spring 1999 (14 pages).
  • Levecq, Hugues et al., Electronic Markets and Floor Markets: Competition for Trading Volumes in Futures and Options Exchanges, STERN #IS-95-20, Jun. 15, 1995 (20 pages).
  • Levecq, Hugues et al., Electronic Trading Systems: Strategic Implications of Market Design Choices, STERN #IS-95-19, Mar. 3, 1995 (30 pages).
  • Lo, Andrew W., The Industrial Organization and Regulation of the Securities Industry, pp. 93-124, Jan. 1996 (32 pages).
  • Management of Operational Risks in Foreign Exchange, The New York Foreign Exchange Committee, Apr. 1996 (42 pages).
  • Marphatia, Arjun C. et al., Risk Management in the Financial Services industry: An Overview, TATA Consultancy Services, 2004 (20 pages).
  • Marshall, Christopher et al., Value at Risk: Implementing a Risk Measurement Standard, The Wharton School, Jun. 1996 (34 pages).
  • Massimb, Marcel N., Electronic Trading, Market Structure and Liquidity, Financial Analysis Journal, Jan.-Feb. 1994 (12 pages).
  • Matringe, Olivier, An Integrated Approach to the Management of Production and Marketing Risks in the Primary Sector of the Developing Countries, United Nations Conference on Trade and Development, Nov. 26, 1997 (90 pages).
  • Maynard, Therese H., What is an “Exchange?”—Proprietary Electronic Securities Trading Systems and the Statutory Definition of an Exchange, Washington and Lee Law Review, vol. 49, Iss. 3, Art. 3, Jun. 1, 1992 (81 pages).
  • Moody, John et al., Performance Functions and Reinforcement Learning for Trading Systems and Portfolios, Journal of Forecasting, vol. 17, pp. 441-470, 1998 (36 pages).
  • Muranaga, Jun et al., Market microstructure and market liquidity, Bank of Japan, 1999 (29 pages).
  • Muranaga, Jun et al., Measurement of liquidity risk in the context of market risk calculation, Institute for Monetary and Economic Studies, Bank of Japan, 1996 (22 pages).
  • Niemeyer, Jonas et al., An Empirical Analysis of the Trading Structure at the Stockholm Stock Exchange, Stockholm School of Economics, Working Paper No. 44, Jan. 1995 (40 pages).
  • Niemeyer, Jonas et al., Tick Size, Market Liquidity and Trading Volume: Evidence from the Stockholm Stock Exchange, Dec. 14, 1994 (32 pages).
  • Notice of Reasons for Refusal issued in Japanese patent application No. 2001-550665, dispatch date: Aug. 24, 2004 (18 pages).
  • NYSE Rulemaking: Order Approving Proposed Rule Change by the New York Stock Exchange, Inc. Relating to Amendments to Rule 80A, Release No. 34-41041, File No. SR-NYSE-98-45, Feb. 11, 1999 (6 pages).
  • Oesterle, Dale A., The SEC's Assault on Electronic Trading, Regulation vol. 21, No. 3, 1998 (7 pages).
  • Open outcry and electronic trading in futures exchanges, Bank of Canada Review, Spring 1999 (19 pages).
  • Oracle® Purchasing User's Guide, Release 11, vol. 1, Mar. 1998 (910 pages).
  • Pardo, Robert, Design, Testing, and Optimization of Trading Systems, John Wiley & Sons, Inc., © 1992 (174 pages).
  • Parikh, Satu S. et al., Electronic futures markets versus floor trading: Implications for interface design, 1995 (13 pages).
  • Parlour, Christine A., Price Dynamics in Limit Order Markets, The Review of Financial Studies, vol. 11, No. 4, pp. 789-816, 1998 (29 pages).
  • Preist, Chris, Economic Agents for Automated Trading, Hewlett-Packard Company, Apr. 1998 (8 pages).
  • Ramchandran, Asish et al., Brokerages: E*Trade vs. Charles Schwab, Center for Research on Information Technology and Organizations, Nov. 1999 (35 pages).
  • Remolona, Eli M., The Recent Growth of Financial Derivative Markets, FRBNY Quarterly Review, Winter 1992-1993 (16 pages).
  • Reuters Limited, OptiMark system eyes derivatives after equities, Feb. 23, 1998 (3 pages).
  • Rickard, John T. et al., Theory of Optimal Transaction Implementation, © 1998 IEEE (8 pages).
  • Risk Management for FX Option Dealers, FX Bridge Technologies Corporation, (20 pages).
  • Robinson, William N., Electronic Brokering for Assisted Contracting of Software Applets, Proceedings of the 30th Annual Hawaii International Conference on Systems Sciences, 1997 (11 pages).
  • Rust, John et al., Characterizing effective trading strategies—Insights from a computerized double auction tournament, Journal of Economic Dynamics and Control, 1994 (36 pages).
  • Sarkar, Asani et al., Electronic Trading on Futures Exchanges, Federal Reserve Bank of New York, Current Issues in Economics and Finance, vol. 4, No. 1, Jan. 1998 (6 pages).
  • Schmidt, Rodney, A Feasible Foreign Exchange Transactions Tax, Jul. 1999 (22 pages).
  • Stambaugh, Fred, Risk and Value at Risk, European Management Journal, vol. 14, No. 6, pp. 612-621, Dec. 1996 (10 pages).
  • Streltchenko, Olga et al., Multi-Agent Simulation of Financial Markets, 2005 (23 pages).
  • Summons to Attend Oral Proceedings issued in European patent application No. 00986543.7, dated Jan. 20, 2009 (5 pages).
  • The Bermuda Stock Exchange, BEST Automated Trading Rules, Nov. 30, 1998 (37 pages).
  • Trading System—HKATS, © 2010 Hong Kong Exchanges and Clearing Limited (8 pages).
  • U.S. Securities and Exchange Commission, Market Oversight Surveillance System Description and Justification, 1980 (32 pages).
  • Understanding Stock Options, © 1994 The Options Clearing Corporation (27 pages).
  • Venkataraman, Kumar et al., The Value of the Designated Market Maker, Journal of Financial and Quantitative Analysis, vol. 42, No. 3, Sep. 2007, pp. 735-758 (24 pages).
  • Weber, Bruce, Screen-Based Trading in Futures Markets: Recent Developments and Research Propositions, Proceedings of the 32nd Hawaii International Conference on System Sciences 1999 (10 pages).
  • Weinhardt, Christof et al., Agent-Mediated Off-Exchange Trading, 1999 (6 pages).
  • Zellweger, Paul, Web-based Sales: Defining the Cognitive Buyer, 1997 (7 pages).
Patent History
Patent number: 9928550
Type: Grant
Filed: Mar 25, 2015
Date of Patent: Mar 27, 2018
Patent Publication Number: 20160048915
Assignee: Cboe Exchange, Inc. (Chicago, IL)
Inventors: Ross G. Kaminsky (Chicago, IL), Richard A. Angell (Evanston, IL), Gordon D. Evora (Chicago, IL)
Primary Examiner: Andrew Joseph Rudy
Application Number: 14/668,359
Classifications
Current U.S. Class: Having Movable Element (333/232)
International Classification: G06Q 40/00 (20120101); G06Q 40/04 (20120101); G06Q 40/02 (20120101); G06Q 40/06 (20120101); G06Q 40/08 (20120101);