Although there are several types of orders that have established meaning in the state of the art, the term"order"refers generally to a request or directive to buy or sell securities. For example, a"market order"is an offer to buy or sell a security at the best price currently available. A"limit order"is an offer to buy or sell a security at a price equal to or better than an investor's specified price, which may be more or less than the best price currently available. A"day order"is an offer to buy or sell a security, which if not executed, expires the day the order was entered. A"good until cancelled" (GTC) or"open order"is an offer to buy or sell a security, and remains in effect until the order is executed or canceled. An"Immediate or Cancel"or IOC order is an order to buy or sell a security immediately,. in which the order is to be immediately cancelled if it cannot be immediately executed. A"stop order"is an order to buy or sell a security at the market price once the security has traded at a specified price called the stop price. Executable orders, therefore, as shown by these examples, may be contingent on market price, specified price limits, and specified time limits.

There are two primary auction markets in the United States : the New York Stock Exchange (NYSE) and the American Stock Exchange (AMEX). Both NYSE and AMEX require member firms to purchase"seats."A"seat"permits the member firms to trade orders on the trading floor as principal or as agent for others. In addition to

manual trading, both the NYSE and AMEX accommodate electronic order processing.

Only seated firms may send trading orders electronically through the NYSE Super Designated Order Turnaround System (SuperDot). SuperDot transmits member firms' market and day limit orders, up to specified sizes in virtually all listed stocks, through the common message switch to the proper trading floor workstation. A"specialist"is the agent for all SuperDot (electronically routed) orders, and assumes the same fiduciary responsibilities as a broker. Specialists receiving orders through SuperDot execute them on the trading floor at their posts, as quickly as market interest and activity permit, and return reports to the originating firm's offices via the same electronic circuit that brought them to the trading floor.

In a similar vein, AMEX orders destined for execution on the AMEX are routed to the AMEX's trading floor by the member firm entering the order into the Common Message Switch (CMS). After performing specific validation checks, CMS passes the order on to the AMEX Order File (AOF). AOF's main function is to retain order details and route orders to the appropriate AMEX order processing application. After the AMEX order processing application, a specialist attempts to execute the transaction on the trading floor exactly like the previously mentioned NYSE specialist.

Unlike the auction markets, the National Association of Securities Dealers Automated Quotation system (Nasdaq@) is a market having no central auction location. Nasdaq is an'over the counter' (OTC) trading association, as opposed to an auction market, that broadcasts quotes and orders to more than 500, 000 computer terminals worldwide. Introduced as the world's first electronic stock market, Nasdaq has no single specialist through which transactions pass. Nasdaq orders are paired and executed on a computer network. Accordingly, Nasdaq's market structure allows multiple market participants to execute trades electronically around the world.

Market participants include market makers and electronic communications networks (ECNs). The market makers are brokers or dealers registered to trade in a particular security on the Nasdaq. Market makers compete for orders by broadcasting quotes over computers networked with the Nasdaq market. ECNs are virtual places to execute real trades on the Nasdaq market. When a market maker uses an ECN to represent an order, the order is first routed through the ECN to check for matches, and then is electronically posted on Nasdaq as an ECN quote. The posted ECN quote can then be executed on Nasdaq or matched with a new order directly through the ECN itself.

Traders commonly follow market activity and place their orders based on stock quotes. Quotes consist of bid and ask prices for any given security. The highest price a buyer is willing to pay for a security is called the"bid."The lowest price a seller is willing to accept for a security is called the"ask."Two quote formats are generally used to depict relevant market information : Level I Quotes and Level II Quotes.

Level I Quotes show the last trade, the net change, the size (volume) of the last trade and the high/low for the day. Level II Quotes show all market makers and ECNs that are bidding to buy a stock, and all market makers and ECNs that are offering to sell a stock, as well as how many shares and at what price.

In the present state of the art, although Level II Quotes purport to update in real-time, there is a lag in updating quotes, which is especially noticeable during peak market times. The lag time between a stock's actual market price and the quoted market price can be as much as five seconds. A highly volatile stock, i. e. very bullish or bearish, may fluctuate in price dramatically in a five second period.

Because an investor may trade electronically, the Internet becomes an ideal platform to initiate orders. In order to trade online, the investor uses an online trading account and places the order electronically with an online brokerage. Like dealing directly

with ECNs or market makers, an online investor may place market orders, limit orders, currently-existing Nasdaq trading systems. SOESO is an automatic execution system for trades of one thousand shares or less, and all Nasdaq market makers must participate in SOES. SOES will direct the order to the market maker currently offering the best bid price and execute the order with that market maker. Even if a market maker does not wish to fill the complete order, the market maker must fill a fixed percentage of the order, and then the remainder of the order will pass to another market maker within seventeen seconds. Eventually, market makers fill a SOES order if the stock is available, but many market makers may contribute to the order, which extends the full order's execution time.

In the Nasdaq systems as they currently exist, investors can send certain orders over SelectNet@ to market makers. Market makers receiving these orders may accept, reject or counter them. After the parties have agreed to the terms of a trade, SelectNet will affirm the trade details for clearance and settlement and simultaneously generate a trade report. SelectNet represents a possibly time consuming method of filling an order. The stock price can vacillate dramatically during the time required to execute an order through SelectNet. SelectNet has the additional disadvantage that an investor may not cancel an order for the first ten seconds after initiating the order, thereby substantially disabling the investor's ability to react to a fast-moving market.

It is worthwhile to note that on January 18, 2000, the Securities and Exchange Commission (SEC) approved a Nasdaq proposal to modify its execution services.

Nasdaq filed a proposal with the SEC in February 1999 seeking to reconfigure SelectNet as a non-liablity system for purposes of order delivery and negotiation only.

Nasdaq proposed, and the SEC approved, establishing a new automatic execution system for Nasdaq National Market O (NNM) securities to be known as the Nasdaq National Market Execution System (NNMS). Implementation is currently scheduled for mid-April 2000.

"Best execution"is a fiduciary duty the broker owes the investor in executing a trading order. In order to comply with the best execution requirement, many brokers rely on Level II Quotes. However, as previously mentioned, the present state of the art has inherent time delays between order initiation and order execution. If an online investor's order flow is directed to a market participant based on latent Level II Quotes, then the investor may be"chasing"stock."Chasing"means repeatedly ordering a stock at a price that is no longer available because of the delay between the change in the actual quote price and the display of the quote price from which the investor determines the order price. An investor who"chases"stock is attempting to buy or sell stock at an order price that in fact is no longer available in the market.

Some other market participant or investor already bought or sold the stock at the displayed price, and the actual quote price has changed. The latency in updating the quotes results in a display of a stock price that is no longer available. Chased orders remain unexecuted.

Broker-dealers generally aggregate investors'orders and then direct them to a favored source of execution in return for payment for order flow. This practice is tolerated on the theory that allowing broker-dealers payment for order flow helps lower transaction costs for investors. There is considerable concern, however, that the availability of payment for order flow could represent a conflict of interest for broker- dealers. Broker-dealers might feel pressured to direct orders to sources of payment for order flow rather than to sources providing current best execution. This concern is highlighted by the fact that best execution tends to be an aggregate determination rather than a determination on the quality of individual orders. Indeed, in an environment where orders are so generally aggregated for execution, it seems almost natural to analyze best execution in the aggregate. Many investors, however, are pointedly concerned with quality of execution for their particular orders. Such investors are not satisfied by the circumstance that their individual orders received good quality of execution when viewed in aggregation with other orders.

Broker-dealers are under an affirmative fiduciary duty to provide best execution of orders. The duty of best execution requires a broker-dealer to seek the most advantageous terms reasonably available under the circumstances for a customer's transaction. The duty originated in common law agency principles and fiduciary obligations. The duty is now part of the rules governing the Self-Regulated Organizations (SROs) comprising stock trading markets in the United States. The duty is set forth for example in the NASD Manual at Rule 2320 and in the NYSE Constitution and Rules at Rule 123. 41. In addition to payment for order, other factors can influence the direction of order execution in ways that raise questions of conflicts of interest, including for example the practice of'internalization,'in which a broker- dealer making a market in a stock can simply execute customer orders out of the broker-dealer's own inventory.

The SEC has taken the position that internalization and payment for order flow can be reconciled with the broker-dealer's duty of best execution as long as the broker-dealer conducts a regular and rigorous evaluation of the execution quality of the different markets trading a security. To the extent that opportunities for price improvement become reasonably available, they must be taken into account in the determination of best execution. Internalizing or routing order flow for execution at the national best bid or offer (NBBO) does not necessarily satisfy the duty of best execution, especially if opportunities for price improvement are available.

A principal effect of order aggregation is delay. Orders submitted to brokers are queued. Orders entered on-line from customers'homes or over the Internet typically are treated the same as orders phoned to brokers in the traditional way. All such orders are placed in queues for periodic transmission to markets, ECNs, or market makers. No single order is guaranteed immediate execution or even prompt execution. Subject to the time in force stated in the order, when a particular inarketable order will be executed is simply unknown from the customers'point of view.

Delay affects different investors differently. Viewed according to their interest in speed and quality of execution, investors can be classified in three broad categories.

First, there are traditional investors. Traditional investors trade approximately once a month. Traditional investors are interested in long term investment. Traditional investors may have very little concern with quality of execution because traditional investors, intending to hold the stock for months or years, may be perfectly happy with any price in the stock's daily trading range.

The second category of investors is hyperactive investors. Hyperactive investors are serious hobbyists or enthusiasts rather than professional investors. They do not earn their living exclusively from investing. They have other professions or occupations, but they are focally interested in the process of investing. Hyperactive investors trade approximately once daily, about twenty times more often than traditional investors.

Hyperactive investors are often interested in popular stocks in which they may remain invested for relatively short periods of time, perhaps only a few days or hours.

Hyperactive investors increasingly therefore need a high quality of execution, including access to the inside price, speed, and available price improvement.

The third category of investors is day traders. Day traders are full-time, individual, professional securities traders. Day traders generally may make thirty to fifty trades a day, perhaps fifty times as many trades as hyperactive investors and a thousand times as many as traditional investors. Day traders probably account for about fifteen percent of the trading volume on Nasdaq. For day traders, quality of execution is a matter of financial survival, crucially important. A delay in execution of even a few seconds can cause a loss for a day trader because markets can change so quickly. Day traders cannot tolerate traditional aggregation, internalization, or payment for order flow. When a day trader enters an order, the order must be executed as quickly as possible, at or near the displayed quote price, regardless of delay between changes in actual quote price and the resulting display. Day traders have no time to wait for

aggregation or direction to the broker's currently favored market maker. Day traders have no tolerance for the effects of internalization on price improvement.

Systems have begun to appear that give day traders the ability to transmit orders through brokers'systems directly to market makers selected by the day traders themselves. Such systems may provide day traders information, such as latency and transaction costs for each market, that is helpful in deciding how to select markets.

Such systems do address the problems of speed of execution. Day traders are still relying on their natural human reaction times to perceive market trends, estimate price changes in markets moving so quickly that the eye cannot follow price changes on the display, and chase stocks with orders entered by hand through a keyboard.

Many market makers or ECNs accept limit orders only. As a stock becomes more volatile, it becomes increasingly difficult to purchase for a limit price. By the time the day trader reads the quote on his screen and gets his finger to the keyboard to press the'buy'button, the shares offered at the inside price already have been sold.

By the time the trader selects another market and enters another order at a higher limit price, those share can already have been sold, and so on.

Thus there is a need for a trading system, a brokerage system for routing orders from a trader customer to a market, a market maker, or an ECN, a system that operates order-by-order rather than through aggregation, a system that operates with impartiality regarding markets rather than internalizing or preferencing for payment, a system that operates at very high rates of speed, providing confinnation of execution or cancellation within seconds after an order is entered, a system that can therefore often, if not always, obtain for the customer execution of the customer's order at or near the price the customer sees quoted on the customer's computer display.

SUMMARY The present invention provides high speed execution of orders by quickly selecting electronic market participants ("markets") to receive orders, quickly routing the orders to the selected markets, and quickly making the markets'responses available to the broker/dealers originating the orders for quick delivery to customers' workstations. The invention functions by ordering markets according to some criteria, such as transaction cost or latency, and then automatically sending orders to the market best meeting the criteria, for example, the market quoting the inside price and having the lowest transaction cost or the lowest latency. The invention is capable of limiting eligible markets to ECNs with inside quotes to the extent that ECNs are routinely faster than routing to Nasdaq market makers through SOES or SelectNet.

Rather than stopping the execution process if an order fails to fill in the first market selected, the invention is capable of continuing to try to fill the order. The invention can first check the quote to determine whether a lower-cost market has quoted inside since the order was routed and rejected, and if one has, route the order there. If there is no new low-cost market quoting the inside price, the invention is capable of automatically selecting the next higher-cost market and routing the order to that market, and to the next one, and so on, until the order times out, is cancelled by the trader, or is rejected by all available markets or ECNs on the inside price. To the extent that markets include ECNs, the invention can route orders directly to ECNs with no need to post the orders to Nasdaq through SOES or SelectNet. If an order is rejected by all ECNs before cancellation or time-out, the order generally can still be posted on Nasdaq through SOES or SelectNet. Orders that cannot be executed promptly at the inside price through ECNs, through Nasdaq, or elsewhere, can be rejected with appropriate notification to the customer.

The present invention is capable of selecting markets according to market information from Nasdaq Level II Quotes or according to market information received directly

from ECNs. The invention is also capable of selecting markets strictly upon historical or statistical information regarding speed and cost of execution, with no requirement that the selected market presently quotes the inside price. In this aspect of the invention, ECNs are ranked according to some objective criteria, and all orders for a stock are submitted as IOC limit orders to each ECN in turn beginning with the first ranked ECN and proceeding down the ranking. In this procedure, the quote is checked to see whether the inside price has moved after each submission that fails to complete execution of the order. If the inside price has moved, the order price is changed to the new inside price (if it is still within the customer's limit), the ECN to whom the invention is currently routing is marked, and the order is submitted to the next ranked ECN. Marking the current ECN allows the system to rotate through all ECNs and return to the current ECN, therefore being assured of submitting to all ECNs at the current inside price, even if the inside price changes before the order times out.

For increased speed, the invention is capable of detecting and responding to marketability of orders. Orders are marketable generally if the order price is equal to or better than the inside price. More specifically, a buy order is marketable if the order price is greater than or equal to the inside ask price. A sell order is marketable if the order price is less than or equal to the inside bid price. Non-marketable orders are not subjected to the algorithm of repeated submission to ECNs, which procedure would be a waste of time. Instead, non-marketable orders are immediately submitted on the customer's original terms, including the remaining time in force, to the first- ranked ECN, where the orders will either time out or be executed if quoted price changes return the orders to marketability.

In this aspect of the invention, customer market orders are converted to IOC limit orders at the inside price. To the extent that chasing can occur, the invention is generally much more successful than the customer would be without the invention because the chasing occurs at electronic speeds instead of human reaction speeds.

In this aspect of the invention, customer limit orders bearing limit prices worse than the current inside price are converted to IOC limit orders with prices at the inside price. These orders are then attempted at the inside price for best execution, then raised or lowered in price, according to the order side, only as needed to fill the order, subject to the customer's price limit.

In the present invention, ECNs can be ranked according to any criteria supportive of execution quality. For example, ECNs can be ranked according to transaction cost, according to latency, or according to a combination of latency and transaction cost.

ECNs can be ranked also according to the quantity of shares presently quoted by them, using that quantity alone or in various combinations with transaction cost and latency.

Finally, in summary, it is useful to note that although the invention is sometimes described as administering orders for stocks, in fact, the invention is also to be applied to other kinds of securities.

DRAWINGS Figure 1 is a general overview block diagram of the invention.

Figure 2 is a block diagram of the principal classes and member methods of a smart executor and an associated market service.

Figure 2a illustrates overall data and control flow among the principal class objects comprising the invention.

Figure 3 is an example data structure representing an order.

Figure 4 is an illustration of scaling market services.

Figure 5 is an illustration of startup constructor calls for the smart executor and its associated market service.

Figure 6 is an illustration of part of the startup control flow.

Figure 7 is an illustration of part of the startup control flow.

Figure 8 is an illustration of the shutdown control flow.

Figure 9 is illustrates a typical cycle of market selection for a smart order.

Figure 10 illustrates detail of operation of the smart executor.

Figure 11 illustrates a typical data structure for a quote.

Figure 12 illustrates order router operations.

Figure 13 illustrates a typical packet data structure.

Figure 14 shows a data structure for use in the hello union of the packet data.

Figure 15 shows a data structure for use in the order union of the packet data.

Figure 16 shows a market-specific structure for use in the union for markets in the structure for the order union.

Figure 17 shows example C-style defines for use as header codes in packet data.

Figure 18 shows example marketID codes to identify markets to receive orders.

Figure 19 shows example action codes for order data.

Figure 20 shows an example data structure to represent router data communications connections.

Figure 21 illustrates typical router operations.

Figure 22 illustrates mirror storage of router packet queues in persistent data storage.

Figure 23 illustrates router startup processing.

Figure 24 illustrates markets associated with latency.

Figure 25 illustrates markets associated with latency and transaction cost.

Figure 26 illustrates markets associated with latency, transaction cost, and quantity of shares.

DETAILED DESCRIPTION Definitions : The following terms are used as defined :

"API"stands for Application Programming Interface, the data communications protocol layer just above the transport layer in a data communications hierarchy, that is, typically just above the transmission control protocol, tcp. Examples of APIs are Windows-Intel winsock, Berkeley sockets, and System V's Transport Layer Interface or TLI.

"Cancellation"is termination of an order, or partial termination of an order, by the customer or by the software comprising the invention. In addition, markets can cancel orders, or parts of orders, for example, in response to an IOC order.

"ECN"abbreviates"Electronic Communications Network,"referring to an order matching service that provides liquidity only by matching orders rather than by maintaining inventory. In the context of the invention, ECNs are considered markets.

In order to avoid confusion with data communications networks, ECNs are referred to as either"ECNs"or as"markets."All ECNs have their own data communications protocols which must be followed by all systems submitting orders to ECNs. The ECNs'data communications protocols are public and well-known. Current ECNs, their symbols and names, are listed below. Obviously the number of ECNs can change at any time.

Example List of ECNs MMID Name ARCA Archipelago ATTN Attain BRUT Brass Securities BTRD Bloomberg Trade Book INCA Instinet ISLD Island MWSE Midwest Stock Exchange NTRD NexTrade REDI Speer Leeds STRK Strike TNTO Terranova

"Executed,"in reference to an order, means that shares have been either bought or sold according to the side of the order.

"Filled"means fully executed. That is, all shares in the order have been executed, bought or sold according to the side of the order. If an order is subject to partial fulfillment, then the order can be partly filled and partly rejected or cancelled, in which case the order will never be considered filled. Processing of an order can therefore be completed through some combination of cancellation, rejection, killing, and partial execution without the order's ever being filled. Processing of an order is said to be complete when all the shares in the order, share by share, have been executed, cancelled, rejected, or killed.

"Floating"is an order status in which the order has been routed to a market and has not yet been executed, rejected, cancelled, or killed."Pending"and"floating"are synonyms.

"IOC"abbreviates"Immediate or cancel,"an order type description meaning that the market to which the order is directed is to fill the order immediately, with available price improvement, if any, or cancel it.

"IOC markets a market supporting IOC orders, including price improvement for such orders. Examples of markets currently known to be IOC markets are Island, Archipelago, and Instinet. Of course the number and the identities of markets accepting IOC orders can change.

"IOC order"is an order designated as IOC,"Immediate Or Cancel,"that is, to be filled immediately or cancelled. If price improvement is available in the market to which the order is directed, IOC orders are to receive such price improvement.

"Inside price"means, as appropriate, the highest bid price or the lowest ask price for a particular security. For buy orders, the inside price is the lowest ask price. For sell orders, the inside price is the highest bid price.

"Kill"refers to partial or complete termination of an order by a market."Kill" contrasts with"cancel"in which an order is terminated by action of the customer.

"Latency"means a measure of the speed with which the markets respond to orders and cancellations. Latency in most embodiments of the invention can be determined as the difference between the time when a response to an order is received and the time when the corresponding order was routed to the market. Latency can be measured from normal orders or from test orders. Some markets support test orders as such. For markets in which test orders as such are not supported, test orders can be implemented by use of unmarketable orders immediately followed by cancellations.

For markets receiving orders regularly, latency can be tracked from normal orders, without the need for test orders. For aspects of the invention in which eligibility of markets to receive orders is based upon latency, test orders can be used to determine whether ineligible markets have become eligible.

"Limit orders"are orders to be executed at the limit price or better. A limit price is the price stated with a limit order and included as part of the limit order. A limit order for a sale of securities is to be executed at or above the limit price for the order. A limit order for purchase of securities is to be executed at or below the limit price for the order.

"Marketable"means limit orders for which the inside price is equal to or better than the order price. That is, Marketable buy orders have order prices equal to or higher than the inside ask price. Marketable sell orders have order prices equal to or lower than the inside bid price. It is helpful to note that the concept of marketability is generally most useful regarding limit orders That is, market orders as such are inherently marketable, because market orders have no limiting price against which the inside price can be meaningfully compared.

"Market,""electronic market,""market participant,""electronic market participant," "marketing network,"and electronic marketing network"are all used as synonyms for services accessible through electronic communications networks capable of executing orders for securities by accepting from broker/dealers buy orders and sell orders, matching or failing to match buy orders with sell orders, and communicating the results to the broker/dealers. Generally the term"market"is used to refer to these entities. All"markets,"as the term is used, are either ECNs or market makers. All available markets have names and symbols as described under the definitions of "ECN"and"market maker." "Market maker"means a broker/dealer providing order matching and liquidity in a stock by maintaining an inventory of the stock traded through a national market.

Currently active market makers, their symbols and names, are listed below.

Obviously the number and identity of market makers can change at any time.

Example List of Market Makers MMID. Name BEST Bear, Steams & Co., Inc.

BTAB Alex, Brown & Sons, Inc.

GSCO Goldman, Sachs & Co.

HMQT Hambrecht & Quist, LLC

HRZG Herzog, Heine, Geduld, Inc.

JANY Janney Montgomery Scott, Inc.

LEHM Lehman Brothers, Inc.

MADF Bernard L. Madoff Merrill Lynch, Pierce, Fenner & MLCO Smith Inc.

MOKE Morgan, Keehan & Co., hic.

Nationsbanc Montgomery Securities, MONT LLC MSCO Morgan Stanley & Co., Inc.

NITE Knight Securities, L. P..

OLDE Olde Discount Corporation OPCO CIBC Oppenheimer Corporation PIPR Piper Jaffray Inc.

PRUS Prudential Securities, Inc.

PWJC Paine Webber, Inc.

RAJA Raymond James & Associates, Inc.

SBSH Smith Barney, Inc.

SHRP Sharpe Capital, Inc.

SHWD Sherwood Securities Corporation "Market orders"are orders to be executed at the inside price at the time of execution.

A market order does not include a price as part of the order because the price is set by the market.

"MMID"abbreviates Market Maker ID, a code identifying a market maker. All Nasdaq traders, including ECNs, are assigned MMIDs.

"Nasdaq Level II Quotes"are provided in a stream of data directly from Nasdaq.

Nasdaq Level II Quotes includes market information for markets offering to buy or

sell stocks. The market information provided in a Level II Quote includes price, side, quantity, and market identification for each market offering to buy or sell a stock listed on Nasdaq.

"National market"means Nasdaq, the New York Stock Exchange, and the American Stock Exchange. SOES and SelectNet are national-level stock trading services provided through Nasdaq.

"Non-IOC markets"do not support IOC orders. Examples of Non-IOC markets include SOES and SelectNet.

"Normal orders"are orders not designated for automatic market selection, automatic routing, and automatic execution.

"Orders"are electronic orders for purchase or sale of securities.

"Pending"is an order status in which the order has been routed to a market and has not yet been executed, rejected, cancelled, or killed."Pending"and"floating"are synonyms.

"Price improvement"means price reductions in the case of buy orders and price increases for sell orders.

"Quotes"are aggregates of information regarding securities traded in markets.

Quotes include for securities listed for sale or purchase, symbols identifying the securities, price, side, quantities, and market identifications or MMIDs. Quotes can come from Nasdaq or directly from markets. A"Nasdaq Level II Quote"includes market information for all markets offering to buy or sell a particular security.

Obtaining quotes directly from markets is typically faster than obtaining it from Nasdaq.

"Rejection"refers to partial or complete termination of an order by a market or by action of the invention."Rejection"contrasts with"cancel"in which an order is terminated by action of the customer.

"Securities"are any agreement for investment. Stocks are the securities most often addressed in described embodiments of the invention. The invention, however, is applicable to many kinds of securities including, for example, options, commodities, and bonds.

"SelectNet"is a Nasdaq system for indirect submission to market makers and to ECNs of electronic orders for stocks listed on Nasdaq. SelectNet implements orders broadcast to many markets or directed to particular selected markets. SelectNet orders for selected markets require MMIDs as parameters, the MMIDs being derived from quotes for the stock in the order. The operations of SelectNet are well-known.

"Side"refers to which side of the market is represented by an order or a quote. Side indicates whether the quote or order is to buy or sell, bid or ask."Bid"indicates the buy side."Ask"indicates the sell side. The present invention functions equally for either side of a transaction. Therefore we attempt to speak in neutral terms regarding side. We speak of execution rather than buying or selling. We use the term"price improvement"to indicate both price reductions for buy orders and price increases for sell orders.

"Smart orders"are orders designated by a customer for automatic market selection, that is, for processing through the smart executor of the present invention. Note that the present invention can conduct automatic routing and automatic execution regardless for all orders, whether smart or normal.

"SOES"abbreviates"Small Order Execution System,"a Nasdaq system for indirect submission to market makers of electronic orders for national stocks. Unlike SelectNet, SOES always operates by automatically selecting a market maker or ECN to receive an order. In contrast with SelectNet, therefore, SOES orders never require an MMID parameter. Like SelectNet, the details of SOES operations and procedures are public and well-known.

"SQL"abbreviates"Structured Query Language,"a known standard database query language.

"SQL database"or"SQL server database"means a database accessible through SQL.

"STL"abbreviates"standard template library,"referring to the ANSI/ISO Standard Template Library."STL"is used generally to refer to standard container templates.

"tcp"stands for transmission control protocol, the data communications protocol layer located in standard communication hierarchies just above the internet protocol or"ip." References to the transmission control protocol are often phrased as"tcp/ip." "Transaction cost"means a market's published price or cost for broker/dealers to execute orders in the market.

Processing Description According to one embodiment of the invention, a system is provided for selecting markets for smart orders and routing smart orders to the selected markets. Figure 1 shows an overview of this embodiment of the invention. Customer workstations (102) are connected electronically through a data communications network (136) to order managers (105). The order managers (105) are connected electronically through data communications networks (138) to market services (108). Each operative market

service (108) has associated with it a smart executor (116). The system of Figure 1, in some embodiments of the invention, implements multiple market services (108) and therefore multiple smart executors (116). Orders entered through customer workstations (102) are verified in order managers (105) and communicated across the networks (136, 138) to the market services (108) which pass the orders to the smart executors (116) for working storage in the order databases (118).

In the embodiment of Figure 1, each instantiation of a smart executor (116) has associated with it an order database (118). Although the order databases are referred to as"databases,"a term that sometimes implies persistent disk storage, in fact, many embodiments of the invention will utilize order databases formed from STL container class objects maintained in high-speed, volatile memory such as random access memory or RAM, or other in-memory storage mechanisms.

A smart executor (116) also typically has access to a quote server library (124) of quotes kept current by a quote server (122) which obtains a constant stream of current quotes through data communications connections to markets (114) or to Nasdaq (126).

The smart executors (116) utilize the market information from the quote server library (124) to select a market (114) for an order. The smart executor then communicates to a market service (108) the identity of the market selected, and the market service (108) sends the order through a network (130) to the order router (112). The order router (112) sends the order across a network (132) to the order port (128) that services the particular market selected to receive the order. In the illustrated embodiment, one order port (128) is provided for each electronic market (114) to which orders can be sent.

The order ports (128) also receive from markets (114) responses to orders. Responses are communicated through networks (134, 132, 130, 138, 136) from the order ports

(128) to the router (112), back to the market service (108), to the smart executors (116), which store in the order database (118) status information received in responses, back to the order managers (105), and back to the customer workstations (102) to provide to customers indications of order status.

The customer workstations, useful according to the present invention, comprise any configuration of computer workstation capable of inputting orders for securities and sending them in machine-readable form through a data communications network. The customer workstations, in some embodiments, day trader workstations in a broker/dealer office connected to a broker/dealer's internal network. In other embodiments, the workstations comprise home computers connected to an internet.

In other embodiments, the workstations comprise office computers connected to an internet.

The data communications networks (130, 132, 134, 136, 138) in some embodiments comprise in-house networks within a broker/dealer's office. In other embodiments of the inventions, the data communications networks are internets, intranets, extranets, or any appropriate and useful data communications network arrangement. The networks (130, 132, 134, 136, 138) comprise any data communications networks capable of receiving and sending orders and notifications in electronic form among the customer workstations (102), the order managers (105), the market services (108), the order router (112) the order ports (128), and the markets (114). In the embodiment of Figure 1, the networks (130, 132, 134, 136, 138) comprise separate data communications networks. In other embodiments, some or all of the networks comprise a single network.

Although they will appear in many embodiments, certain of the network connections are optional, depending on which embodiment of the invention is used. In certain embodiments of the invention, for example, the customer workstations (102) is directly connected to an order manager (105). Such direct connections are used, for

example, in a broker/dealer office where day trading workstations are directly connected to the broker/dealer's order manager (105).

The order manager (105) comprises a computer capable of providing order management services in some embodiments. Examples of order management services include the usual known needs for administration of customer orders at the account level, including for example, customer logins, verifications of orders according to account codes, checking of customer credit eligibility for purchases and short orders, and regular business accounting. Order managers useful in accordance with the present invention are not required to provide each of these services, and, order managers will, in some embodiments, perform further services. The order manager (105) is any computer and software system capable of verifying orders and communicating them in a standard format to the market services (108).

It is noteworthy that the customer workstations, in some embodiments, belong to customers having accounts with the same broker/dealer running the market services 108), while, in other embodiments, they do not. The order managers (105) in some embodiments are run by the same broker/dealer running the market services (108).

Other broker/dealers, however, in other embodiments, also, or even exclusively, make the market service available to their customers through a subscription arrangement with a broker/dealer running market services (108) or smart executors (116).

Customers (102) can gain access to the market service by opening accounts with a broker/dealer who runs market services on its own computers or by opening accounts with broker/dealers who subscribe to the market services run by others. From the perspective of the market services, it makes no difference whether orders originate from customers of the broker/dealer running the market services or from some other broker/dealers, so long as the orders arrive at the market services in a prescribed format intelligible to the market services. One embodiment of such an intelligible order format is shown in Figure 3, which is further described below.

Continuing with reference to Figure 1 : The order manager (105) validates customer orders and then communicates them through data communications network (138) to a market service (108). In one embodiment, the market service (108) comprises a computer system, a combination of computing machinery and software, in which the software elements comprise a server which functions by continuously requesting, receiving from order managers (105), and sending to smart executors messages.

Examples of the types of messages include orders and cancellations of orders. In some embodiments, messages include requests for other services such as symbol lists, refreshing pending order lists, or recovery services generally. Not all such message types are required, nor is this list of message types exhaustive.

In the illustrated embodiment, each market service (108) has associated with it a smart executor (116). The market service (108) starts its associated smart executor (116).

While the smart executor is running, throughout the trading day, the market service (108) provides to the smart executor (116) an interface communicating orders, cancellations, and responses to and from the smart executor (116), the order managers (105), and the order router (112). In other embodiments, each market service has more than one smart executor, the number of smart executors being scaled according to a principle. In some embodiments the scaling principle is that one smart executor is assigned orders with symbols beginning with letters in the range a.. m, and a second smart executor is assigned orders with symbols beginning with letters in the range n.. z. In other embodiments, other ordering principles are used.

The smart executor (116) comprises a software system installed and running on a computer, capable of maintaining an organized list of markets (114), receiving incoming orders (106) from the customer workstations (102) and the order managers (105), deciding automatically in response to programmed criteria which markets (114) ought to receive the orders, and sending the outgoing orders to the order router (112).

The smart executor (116) is also capable of storing pending orders in an order database (118). Pending orders stored in the order database (118) have, for example,

the structure shown in Figure 3, although alternative structures will occur to those of skill in the art without departing from the present invention..

The order router (112) comprises in some embodiments a computer system, a combination of computing machinery and software, capable of maintaining lists of routing connections, using the lists to select the best electronic route to a market, receiving from the market service outgoing orders in the form shown in Figure 3, and transmitting the outgoing orders through the selected route to a market (114).

The quote server (122), in the example illustrated in Figure 1, establishes and maintains electronic connections to markets (114) through which the quote server (122) receives quotes and other market information. The electronic connections to markets (114), in the illustrated example, include Nasdaq (126) feeds as well as direct connections to ECNs and other markets (114).

After orders are routed to markets, the order router (112) receives from the markets (114) responses, including confirmations of orders, notifications of executions of orders, and notifications of cancellations. Responses to order are generally communicated back through the order router (112) to the market service (108), to the smart executor (116), to the order manager (105), and to the customer workstations (102).

Quotes from Nasdaq or Direct from Markets As illustrated in Figure 1, orders for stock are originated on customer workstations (102), transmitted across electronic network connections (136, 138) and through the market service (108) to the smart executor (116). The market service (108) and its associated smart executor (116) are generally installed and running on at least one broker/dealer computer, although other configurations are within the scope of the present invention.

Figure 10 illustrated in more detail one embodiment of the smart executor of the present invention. In the embodiment illustrated in Figure 10, the smart executor (116) selects a market for receipt of an order by referring to a quote (1300) for the stock ordered. The quote (1300) is typically structured as shown in Figure 11. The fields or data elements comprising a quote are typically those shown in Figure 11, having the meanings described below. Quotes typically contain multiple sets or records comprising the fields Side (1320), Quantity (1322), MMID (1324), and Price (1326), which together represent offers to buy or sell the stock, the offers being displayed by markets, that is, ECNs or market makers. MMIDs (1324) or"market maker identifiers"are used as identity codes for ECNs as well as market makers. Field Description Symbol (1302) the symbol for the stock or other security whose market information comprises the quote. LastTradePrice the price of the stock in its last trade. (1304) ClosePrice (1306) the price of the stock in its last trade before closing in the previous trading day. NetChange (1308) the difference between LastTradePrice (1304) and ClosePrice (1306). NationalMarket the national market of the stock's last trade. (1310) TypicalQuantity the usual quantity in which the stock trades. (1312) TickDirection whether the current LastTradePrice (1304) is (1314) higher or lower than the LastTradePrice of the quote for the stock's most recent previous trade. High (1316) the stock's highest price in the current session. Low (1318) the stock's lowest price in the current trading session. Side (1320) whether a displayed offer is a bid or ask. Quantity (1322) the number of shares represented in a displayed offer. MMID (1324) the market symbol for the ECN or market maker displaying an offer. Price (1326) the share price in a displayed offer. Cost (1328) the transaction cost for purchases and sales of

stock in the market identified by the corresponding MarketSymbol (1324). IOC (1330) a Boolean indication whether the market accepts IOC orders, yes or no, true or false.

In this embodiment of the invention, quotes comprise Nasdaq Level II Quotes. Other embodiments utilize quotes received through direct feeds from ECNs or other markets, or from a combination of Nasdaq Level II Quotes and direct feeds from ECNs or other markets.

As shown on Figure 10 for this embodiment, the smart executor identifies from the Price fields (1326) in the quote (1300) the markets, identified by the MMID fields (1324), that are quoting the inside price. In this embodiment, the smart executor then identifies, by use of the IOC fields (1330), which of the markets with the inside price will accept IOC orders. The process of identifying the markets with inside quotes willing to accept IOC orders is the process of generating the eligible market list (1202) as shown on Figure 10. In some embodiments, the smart executor gathers the markets quoting the inside price and willing to accept IOC orders, that is, the list of eligible markets (1206), into a data structure such as an array, linked list, or an STL container. Other embodiments use other means for implementing the list of eligible markets, all within the scope of the invention.

After generating the eligible market list (1202, 1206), the smart executor selects a market (1214) to receive the order. In this embodiment, if there is more than one eligible market, then the market having the lowest transaction cost is selected. If there is only one eligible market on the list (1206), then that market is selected. If there are no eligible markets, then this embodiment of the smart executor selects, for example, from among all IOC markets, the one having the lowest transaction cost. Other embodiments have other methods of selecting a market when no markets meet eligibility criteria.

If the quote (1300) changes after a market is selected, then this embodiment of the invention selects a new market. The market selection process (1214) detects changes while an order is pending by examining (1226) updated quotes (1224). Changes to be detected in the quote include, for example, changes in the inside price and changes in the number of markets quoting the inside price. If any such change occurs, the market is reselected by again generating the eligible market list (1202, 1206) and again selecting a market (1214) according to the content of the list.

After a market is selected, this embodiment of the smart executor (116) routes the order to the selected market by sending the order (1216) to the order router (112).

During the period when the order has been routed to a market but has not yet been executed, cancelled, rejected ; or killed, the order is said to be"pending"or"floating." If the inside price improves while the order is pending, this embodiment of the smart executor responds by canceling (1218) the order. The cancellation process (1218) detects improvements in inside price by examining (1228) updated quotes (1224) from the quote server library (124).

Orders routed to markets are received (1230) by the markets (114). Markets receiving orders (114) transmit responses (1232) back through the router (112) to the smart executor (1234, 1220). Responses include confirmations of receipt and notifications of execution, cancellation, rejection, and killings.

Some embodiments of the smart executor include a control loop in which the steps of selecting a market according to the content of the signal (1214), routing the order to the selected market (1216), canceling the order if the inside price improves (1218), and receiving responses (1220) are repeated (1222, 1236) until the order is either filled, times out, or is cancelled, killed, or rejected.

Additional Aids of Execution Quality : Latency and Quantity of Securities Quoted An alternative embodiment of the smart executor uses latency to select a market.

According to this aspect of the smart executor, as shown on Figure 24, each market in a multiplicity of markets is assigned a latency (2404). Figure 24 is an example of an array in which latency (2404) is associated with markets identified by MMIDs (2402).

Latency is a measure of the speed with which markets respond to orders. An example of a measure of latency is the difference between the time when a response is received from a market and the time when a corresponding order was routed to the market.

In this aspect of the invention, an array similar to the example in Figure 24 is the eligible market list (1206) generated (1202) by the smart executor, as shown on Figure 10. That is, the list of eligible markets (1206) includes the additional element of latency for each market. The step of selecting a market (1214) therefore is effected based on latency of the eligible markets. If the eligible market list (1206) identifies more than one eligible market, in one embodiment, for example, the step of selecting is carried out by selecting the eligible market having the lowest latency.

Alternative embodiments can combine latency with other parameters to select the market for the order. For example, as shown in Figure 25, in some embodiments markets identified by MMIDs (2402) are associated with transaction costs (2406) in addition to latency (2404). If the eligible market list contains more than one eligible market, the market to receive the order is, in these embodiments, selected by use of a combination of latency (2402) and transaction cost (2406), or by use of latency (2404) or transaction cost (2406) alone. For example, the step of selecting a market (1214) in some embodiments comprises selecting the market having the smallest product of latency multiplied by transaction cost.

Alternative embodiments can combine latency and transaction cost with other parameters to select the market for the order. For example, as shown in Figure 26, in some embodiments of the invention markets identified by MMIDs (2402) are associated with quantity of shares quoted (2408) in addition to transaction cost (2406) and latency (2404). If the eligible market list (1206 on Figure 10) contains more than one eligible market, in these embodiments, the market to receive the order is selected by use of a combination of latency, transaction cost, and quantity of shares. For example, in some embodiments, the selection comprises the market having the lowest quotient of quantity of shares offered for purchase or sale divided by transaction cost for execution of customer orders and further divided by latency.

Eligibility Not Limited To Inside Quote In some embodiments of the invention, markets eligible for receiving orders are not limited to markets quoting the inside price. In such embodiments, the list of eligible markets is generated dependent upon one or more of latency, transaction cost, quantity of shares quoted, whether markets accept IOC orders, or other factors. In such embodiments, for example, the list of eligible markets is configured as an array that includes at least one of : latency, transaction cost, or quantity of shares quoted, as shown in figures 24, 25, and 26.

In some embodiments in which the list of eligible markets is not limited to markets quoting the inside price, the list of eligible markets is generated dependent upon coefficients whose values in turn depend upon some combination of latency, transaction cost, quantity of shares quoted, or other factors. The list of eligible markets in some embodiments, for example, is configured as an array that includes a coefficient whose values depends upon some combination of latency, transaction cost, quantity of shares quoted, or other factors. The list of eligible markets in such embodiments, is, for example, stored in a data container comprising an array, a linked list, a C-style data structure, a linked list of arrays, a linked list of data structures, an

array of data structures, an STL template, a file, a database, or any other machine manipulable form.

Generating the eligible market list in this aspect of the invention optionally excludes from the eligible market list those markets having weighted coefficients above, equal to, or below a coefficient threshold, the coefficient threshold being calculated dependent upon some combination of quantity of securities quoted by the market, the market's transaction cost, and the market's latency. In some embodiments, generating the eligible market list includes ranking the markets in the list according to some ranking principle, such as, for example, latency or transaction cost, or a coefficient comprising the product of latency multiplied by transaction cost.

In the example embodiment illustrated in Figure 10A, selecting a market includes selecting (1240) a default market (1248). The default market (1248) in some embodiments is selected from among all available markets (1244). In other embodiments, the default markets is selected among eligible markets (1242). The default market (1248) in most embodiments is selected according to default market selection criteria (1246) which include, for example, transaction cost, latency, quantity of shares quoted, whether markets accept IOC orders, and other criteria.

In the example embodiment shown in Figure 10B, selecting a market includes configuring (1252) the order to comprise a limit order (1254) with time-in-force set to "IOC"and an order price set to an inside price, determining whether the order is marketable (1256), determining whether the order has been filled (1258), determining whether the order has been cancelled (1260), determining whether the order has been killed (1262), and determining whether the order has been rejected by all eligible markets (1264.

In the illustrated embodiment, the smart executor determines marketability (1256) by comparing the inside price with the order price. If the order price is better than the

inside price on the quote, the order is not marketable. If the order price is equal to or worse than the inside price on the quote, the order is marketable.

In the embodiment of Figure 1 OB, if the order is marketable, not cancelled, not filled, and not rejected at the inside price by all eligible markets (1270), the method can include continuing to repeatedly select markets to receive the order by selecting the next eligible market (1268). In this aspect of the invention, upon the first routing of the order,'the next market'is taken as the first eligible market in the eligible market list (1242). After routing the order to the last eligible market,'the next market'is again the first eligible market.

In this embodiment of the invention, the smart executor will redetermine (1272) after each routing (1274) whether the order remains marketable (1256), not filled (1258), not cancelled (1260), not killed (1262), and not rejected at the inside price by all eligible markets (1264). In this embodiment, the smart executor continues to route the order to the next eligible market (1268, 1274) until market responses (1276) indicate that the order is either filled, cancelled, rejected at the inside price by all eligible markets, or the order becomes unmarketable.

If, in the embodiment shown in Figure 1 OB, the order is determined to be not marketable (1276), the order is then reconfigured (1278) to comprise the order's original price and the order's remaining time-in-force. Then order is routed (1280) to a default market (1248).

If, in the embodiment of Figure 10B, the order is determined to have been rejected at the inside price by all eligible markets (1282) and there exists at least one available markets not on the eligible market list (1288), the smart executor then selects (1284) an available market among the markets not on the eligible market list according to available-market selection criteria. The order is then routed to the selected available market (1286). Available-market selection criteria include, in this embodiment, for

example, sending orders for national stocks to SOES and sending small-cap orders to SelectNet.

As shown on Figure 1OB, the smart executor determines whether the order has been filled or cancelled by receiving (1276) from markets (114) responses to routed orders.

The responses include, for example, notifications of execution, notifications of cancellation, notifications of rejections, and notifications of killings.

This aspect of the invention, as shown on Figure 1 OB, optionally includes the step of determining whether the inside price has changed (1296). If the inside price has changed, this embodiment of the smart executor will reconfigure the order to the new inside price (1292), and then continue the determinations of marketability (1256), fill (1258), cancellation (1260), killing (1262), rejection (1264), selection of the next eligible market (1268), and so on.

Determining whether the inside price has changed (1296), in certain embodiments, includes marking the market where the order was pending when the inside price changed and continuing processing until the order is again routed to that market at the new inside price. Alternatively, other embodiments of the invention utilize a counter variable, count routings, reset the counter to zero when the inside price changes, and continue repeatedly determining marketability (1256), fill (1258), cancellation (1260), killing (1262), rejection (1264), selection of next market (1268), routing to next market (1276), and so on, until the counter value is equal to the number of eligible markets.

In this aspect of the smart executor, the core process of selecting markets to receive orders, in embodiments where the eligible list of markets is not limited to markets quoting the inside price, including the method of repeated selection of the next eligible market, functions generally as shown in the following example pseudocode :

Int SmartExecute. RequestCreateOrder (Order) Order points to the subject order record (Order *) Order ; //MarketList [] is an array of MMIDs representing eligible markets ranked //according to some ranking principle //Assume first entry in sorted list is preferable default market... although other criteria //often will be used to select a default int DefaultMkt = MarketList [l], //Int MaxMkts = the current total number of eligible markets, II i. e., the array size of MarketList [] Int EndMIÇT = MaxMkts ;//set initially to max, so //if the market does not change, //then the loop will submit the //order once to all IOC markets Int TryMkt = 1 ; Double TryPrice = CurrrentPrice = CIP (Symbol, Side)/* Current Inside Price */ // continue to submit the order to eligible markets //until the order is filled, cancelled, killed, or // rejected by all eligible markets at the inside price while (Marketable (Order->Side, CIP, TryPrice) && (Order->RemainingShares ! = 0) && (Order->CancelRequested ! = true) && (Order->TryMkt ! = MaxMkts))

//index to the next eligible market or to the first eligible market if (++TryMkt > MaxMkts) TryMkt = 1 ; //submit order to current selected market OrderIDMkt = ifMarket->CreateOrder (MarketList [TryMkt], TryPrice, IOC) //wait for the entire order to be administered in the current markets, //i. e., entirely executed, cancelled, killed, or rejected while (Order->FloatingShares ! = 0)/* blocking wait */; if the inside price changes while order is pending in //the current market, mark the current market, so //that the loop will try all eligible markets at the //new inside price if ( (CurrentPrice = CIP (Symbol, Side)) ! = TryPrice) { EndMkt= TryMkt-1 ; TryPrice = CurrentPrice ; }//end while (Marketable) // Order is now filled, cancelled, or unmarketable : // if order not filled and not cancelled, submit to default market //that is, if presently unmarketable, submit to default market if (!order_filled (OrderData) && ! order_cncel_requested (OrderData) submitorder (DefaultMkt, OrderData. Price, OrderData. time-in-force) ; }//end RequestCreateOrder

Marketable (side, CurrentPrice, TryPrice) { if (side = buy) return (TryPrice >= CurrentPrice) ; if (side = sell) return (TryPrice <= CurrentPrice) ; Example Classes and Member Methods In some embodiments of the invention, the core function and structure of the invention is implemented in three modules, a market service, a smart executor, and an order router. Class structures for object-oriented implementation of the market service and smart executor of such embodiments are illustrated in Figure 2. In such embodiments, the market service generally provides an interface between the smart executor (116) and the order managers (105) and the order router (112), as shown on Figure 1. The smart executor (116) performs the decision-making regarding where to route orders. The order router (112) administers the delivery of orders and cancellations to markets (114) and the receipt of responses from markets (114).

The market service (108) receives from order managers (105) and passes to the smart executor (116) by calls to ifSmartExecutorRequest. RequestCreateOrder (), a member method shown at reference number 212 on Figure 2, messages representing new orders in which the message data structures comprise the following fields, having the meanings and usages described, and illustrated on Figure 3. It should be noted that some embodiments of the invention utilize the same data structure, by altering the contents of pertinent fields, for both messages comprising orders and cancellations, as well as responses to orders to be communicated back from the market services to the order managers. Other embodiments utilize separate structures for different message types.

OrderIDMgr (302), a field containing a unique identifier for the order, assigned by the front-end, customer-level software that originated the order or by the order manager that sent the order to the receiving market service ; this field is unique among orders sent by the originating order manager ; ManagerID (304), an identification code for the order manager originating the order ; note that this field in combination with OrderIDMgr comprises a completely unique identifier for the order ; AccountID (306), the customer's account number ; Action (307), an indication of the processing to be performed in response to the order ; this field identifies, for example, whether the message containing it is to be treated as an order, a cancellation, or a response ; Symbol (308), the trading symbol identifying the stock or other security to be administered in response to the message, to be sold, sold short, purchased, cancelled, or responded to ; Side (310), an indication whether an order is to buy, sell, or sell short.

Quantity (310), the original quantity of securities to be sold or purchased ; Minimum (312), related to Quantity, the minimum number of shares to execute, in which"0"as a code can indicate that any quantity is acceptable, and entry in this field of an amount equal to Quantity can mean that no partial fulfillment is allowed, that is, all of the Quantity is to be sold or purchase, or none of it.

Price (316), in which"0"can be treated as a code indicating a market order, and non-zero can indicate a limit order ; Time-in-force (318), sometimes abbreviated as"TIF,"an integer indicating the number of seconds the order is to remain in force, can be coded so in the range 0 through 99999,"0"can be treated as indicating an IOC order ; MarketID (320), the market identifier code, generally an MMID, except when specifying SelectNet.

Parameters (322), for smart orders this field can contain the customer's price/speed preference ; for orders directed to SelectNet, this field contains an MMID ; Sequence Number (324), a sequentially incremented number for transaction tracking between an order manager and a market service, this field helps guard against failure in the order manager, the market service, or the connecting network, after which failure both the market service and the order manager can exchange the most recent Sequence Number received by either and if there's a gap, fill it in.

Visibility (326), an indication whether the market to receive the order should display in a quote the order's price, symbol, and quantity ; this field can be coded with the following values : HIDDEN means no display, SUBSCRIBER means display only to the market's direct subscribers, NORMAL means display according to the market's usual rules for display.

The smart executor (116) intelligently decides where to route orders, but the smart executor of the present invention does not verify orders. The smart executor assumes that orders it receives have already been verified. In describing the overall operation of the smart executor, we refer to order validation functions as residing in an order manager (105). Any order manager (105), however, can be used with the present invention so long as the order manager (105) is capable of (1) establishing a telecommunications link with the market service of the present invention by use of data communications procedures and (2) transmitting and receiving through the telecommunications link in established formats messages comprising orders, cancellations of orders, and responses regarding orders.

The smart executor, in embodiments of the kind illustrated on Figure 2, comprises three principal object-oriented classes, ifSmartExecutorRequest (202) and ifMarketEventSink (208), and SmartExecutor (210). In describing the kind of

embodiment shown on Figure 2, the term"smart executor"is used to refer generally to the structure and function of these three classes. The small"if'on the front of several of the class names on Figure 2 denotes classes generally functioning as interfaces. The term"sink"which sometimes appears in class names denotes classes generally functioning to process responses or outputs. In the kind of embodiment illustrated on Figure 2, ifMarketEventSink (208) provides member functions generally oriented to administer responses from markets. The class IfSmartExecutorRequest (202) generally provides the input side of the interface to the smart executor.

Market services in the kind of embodiment shown on Figure 2 generally comprise three principal object-oriented classes, ifDrderEventSink (207), ifMarket (204), and ifExecutorEventSink (206). In describing such embodiments, the term"market service"is used to refer generally to the structure and function of these three classes.

The class ifOrderEventSink (207) provides member methods generally designed to administer inputs from order managers, including requests for orders, cancellations, and recovery support. ifExecutorEventSink (206) provides member functions generally oriented to administer output from the smart executor. The class ifMarket (204) generally provides the interface between the smart executor and the markets.

These embodiments of the invention generally will create and use multiple if Market class objects, one for each market to which orders may be directed. Although particular names are used for clarity in describing the structure and operation of the classes comprising such embodiments, obviously the names of object-oriented classes comprising embodiments of the invention have no effect on the structure, function, or scope of the invention.

In the illustrated embodiment, ifMarketEventSink (208) and ifSmartExecutorRequest (202) are abstract classes containing one or more pure virtual member methods required to be implemented by derived classes, if any. In the illustrated embodiment of the invention, only one class object will be derived from these abstract classes, the class called SmartExecutor (210). In this embodiment, a class called SmartExecutor

(210) is derived from both ifMarketEventSink (208) and ifSmartExecutorRequest (202), and therefore there would be no class objects ofifMarketEventsink and ifSmartExecutorRequest in such implementations.

In the illustrated embodiment, class objects of ifExecutorEventSink (206) and if Market (204) are associated with the SmartExecutor (210) class object by aggregation, that is, by stored pointers. Member method names fully referenced would usually begin with the term"SmartExecutor,"as in the example, "SmartExecutor. MethodNumberOne." In the descriptions below, however, for clarity, member methods implemented in the derived class SmartExecutor (210) are named according to their base classes.

Because we use the term"smart executor"is used to refer generally to the three related interface classes shown on Figure 2, that is, the member methods of ifMarketEventsink (208) and ifSmartExecutorRequest (202) are referred to by their base class names, as in the examples,"ifMarketEventsink. MethodNunberOne ()" and "ifSmartExecutorRequest. MethodNumberTwo ()." In the illustrated embodiment, there is only one SmartExecutor class object for each market service. The illustrated embodiment of the invention, using only one market service, comprises only one SmartExecutor class object. Some embodiments of the invention use multiple instantiations of the SmartExecutor class in which each SmartExecutor class object is assigned responsibility for orders with symbols beginning with subsets of the subset of the alphabet administered by their associated market service.

General data flows among the principal classes of the market service and the smart executor are illustrated in Figure 2a. Order managers (105) generally send messages (294) requesting orders, cancellations, and services that are received by member methods in ifOrderEventSink (207), an interface of the market service (108).

IfOrderEventSink (207) methods generally interface (295) with the smart executor (116) by calling member methods in ifSmartExecutorRequest (202).

IfSmartExecutorRequest (202) in turn passes (296) orders and other requests to ifMarket (204) methods back in the market service (108). IfMarket (204) sends (297) market responses (297, 298) back through ifMarketEventSink (208) to ifExecutorEventSink (206) and then (299) back to the originating order managers (105).

In addition to the principal classes mentioned above, the illustrated embodiment, as shown on Figure 1A, also provides a container class called OrderDatabase (150) in which to store representations of orders. The invention provides representations of orders through a class called Order (152). The OrderDatabase (150) typically comprises three STL containers (152, 154, 156), two of them (154, 156) used to encapsulate indexes into the third (152) which is used to hold data structures representing orders. In this embodiment, the first index (154) will sort according to the fields OrderIDMgr (191) and ManagerID (193), to allow quick access to orders according to the identification from the order manager side of the system. The second index (156) therefore will generally sort according to the field OrderIDMkt (192), allowing quick access to orders according to the identification of the order in the market to which the order is submitted.

The OrderDatabase, in the illustrated embodiment, as shown on Figure 1B, is a class providing the following member methods which function generally as described : OrderDatabase. find (OrderIDMgr, ManagerID) (172) is a member method that returns an order given as an input the unique combination of order ID assigned by an order manager plus the identification code for the order manager (105) through which the order originated.

OrderDatabase. find (OrderIDMkt) (174) is a member method that returns an order given as an input the unique identification of the order in the market where the order is pending. In such embodiments, the member

method OrderDatabase. find0 is typically overloaded to function both with OrderIDMgr and managerID and also with OrderIDMkt.

OrderDatabase. newOrder (OrderMessage *) (176) is a member method that allocates space for a new order record.

OrderDatabase. indexOrder (OrderIDMgr, ManagerID) (178) is an overloaded member method for inserting the pertinent order fields into the first index.

OrderDatabase. indexOrder (OrderIDMkt) (180) is an overloaded member method for inserting the OrderIDMkt into the second index.

OrderDatabase. freeOrder (OrderIDMgr, ManagerID) (182) is a member method that deletes an order from the database given as an input the identification of the order to be deleted. OrderDatabase. freeOrder () is typically overloaded (184) in such embodiments to function also with the OrderIDMkt field.

Order class objects represent orders internally within the smart executor. In the illustrated embodiment, as shown on Figure 1C, the Order class contains the member data elements described immediately below. One Order class object is instantiated for each order pending in the smart executor.

Order. Price (162) is the original limit price of the order or 0 for market order.

Order. TIF (164) is the order's time-in-force stated in seconds.

Order. Quantity (166) stores the original quantity of securities requested for sale or purchase.

Order. RemainingShares (168) is the quantity of securities, out of the original quantity stored in Order. quantity, remaining to be sold or purchased. If the order is subject to partial fulfillment, Order. remainingshares can be less than Order. quantity. When an order is fully executed, that is, "fulfilled,"Order. remainingshares is set to zero.

Order. CancelRequested (186) is a Boolean flag set when the order is requested to be cancelled.

Order. FloatingMarket (188) is the identification of the market where the order is pending. In this context,"floatingmarket"is an MMID identifying the market where the order is pending.

Order. Parameters (190) is used for orders directed to SelectNet, typically will contain an MMID ; Order. OrderIDMkt (192) is the identification code of the order in the market where the order is pending.

Order. FloatingShares (194) is the number of shares on a floating order. If the order is subject to partial fulfillment, Order. floatingshares can be less than Order. quantity. If the order is subject to partial fulfillment and is in fact partially executed, Order. FoatingShares will be less than Order. Quantity. After an order has been submitted to a market, the fact that the order is finished processing in that market is indicated by Order. FloatingShares --0, because all shares on the order at that point have been either executed, cancelled, killed, or rejected.

Order. FloatingPrice (196) stores the price on a pending order.

Order. FloatingIOC (198) is a Boolean flag set to specify that the order was sent to market as an IOC order and therefore will not require a cancellation to be sent to the market.

Order. TryMarket (197) stores the index in the array OrderedMarkets of the market where the order is currently pending. In smart orders, this field is maintained by the smart executor. In normal orders, this field identifies the market selected by the customer.

Order. ScannedMarkets (195) stores the current count of the number of markets to which the order has already been submitted at the inside price.

Order. IsSmart (193) is a Boolean identifier of smart orders, orders for which automatic market selection has been requested.

Order. OrderIDMgr (191) is an identification code for an order, this code being assigned by the originating order manager or software operating on the customer workstation.

Order. ManagerID (193) is an identification code for the order manager that originated the order. ManagerID (193) and OrderIDMgr (191) together comprise a unique key for an order in the order database.

The list of eligible markets (MMIDs, reference 352), in some embodiments, is stored in an array called OrderedMarkets (350), as shown on Figure 1D. Some embodiments of the invention also allocate an array dimension for weighted coefficients (354). In some embodiments, within OrderedMarkets (350), markets represented by MMIDs (352) are sorted according to the weighted coefficients (354). Weighted coefficients, in some embodiments, are calculated with some combination of market transaction costs, market latency, or quantity of shares quoted.

The SmartExecutor Class (reference 210 on Figure 2) As mentioned above, in this embodiment of the invention, the SmartExecutor class (210) implements through inheritance the classes ifSmartExecutorRequest (202) and ifMarlcetEventSinlc (208), shown on Figure 2. In addition to the member methods defined in those classes, the SmartExecutor class (210) generally also implements the three private functions described below.

SmartExecutor. smartNewOrder (Order *) (reference 216 on Figure 2) In the illustrated embodiment, smartNewOrder () (216) is called from ifSmartExecutorRequest. RequestCreateOrder () (212) to initialize the order fields for initial processing and pass the order to smartContinueOrder () (220), as shown on Figure 9. (The order is actually created in ifSmartExecutorRequest. RequestCreateOrder () (212).) More specifically, in

the illustrated embodiment, smartNewOrder () (216) functions in accordance with the following pseudocode : SmartExecutor. smartNewOrder (Order *) //initialize order fields for smart processing Order->TryMkt = 0 ; Order->ScannedMkts = 0 ; Order->floatingPrice = CIP (Symbol, Side) ;//current inside price smartContinueOrder (Order) ; SmartExecutor. smartCancelOrder (Order *) (reference 218 on Figure 2) In the illustrated embodiment, this method marks orders as having been requested to be cancelled. More specifically, smartCancelOrder () functions in accordance with the following pseudocode : SmartExecutor. smartCancelOrder (Order *) { Order->cancelRequested = true ; //remember no need to cancel a pending IOC order If (not Order->floatingIOC) IfMarket->CancelOrder (Order) ; SmartExecutor. smartContinueOrder ( (Order*) Order) (reference 220 on Figure 2) In the illustrated embodiment, this method decides which market is to receive a smart order. This method is called on every response from markets

regarding smart orders and from SmartExecutor. newOrder (), reference 220 on Figure 9. This method is not called if there are no remaining shares to be executed on the order, that is, if Order->RemainingShares = 0. See the description of ifSmartExecutorRequest. NotifyOrderExecuted0.

The following example implementation can be compared with the one set forth above for SmartExecute. RequestCreateOrder (Order). In comparison, this implementation uses no blocking waits while orders are pending, because, in this embodiment, the call to sendToMarket () represents a handoff to a background or parallel process. In high-volume environments, blocking waits may actually be preferred, especially if a handoffs to parallel processes requires context switches. Nevertheless, many embodiments within the scope of the invention do not use blocking waits. More specifically, smartContinueOrder (), in this example embodiment, functions in accordance with the following pseudocode : SmartExecutor. smartContinueOrder ((Order *) Order) //first, wait until the pending order is //finished processing in the current market, //i. e., until fully executed or rejected if (Order->floatingshares ! = 0) return ; if (Order->CancelRequested) ifExecutorEventSink->NotifyOrderCancelled (Order) ; OrderDatabase. freeOrder (Order) ; Return ;

if (timed out (Order)) NotifyUserRej ected (timeoutasreason) ; OrderDatabase. freeOrder (Order)} Return ; if (marketable (Order)) if (Order->FloatingPrice ! = CIP (Symbol, Side)) { //price changed will need to restart count Order. FloatingPrice = CIP (Symbol, Side) ; Order->ScannedMarkets = 0 ; if (Order->ScannedMarkets < arraysize (OrderedMarkets)) //send to current market with IOC as TIF and //floating price as limit price //increment market cycle back to beginning : sendToMarket (Order, IOC, OrderedMarkets [Order->TryMarket]) ; //point to next market Order->TryMarket += 1 mod array_size ; else finished scan of all markets on eligible list, //still marketable, // mark as not smart anymore, normal order, and send to SOES or SelectNet Order->FloatingPrice-Order->Price ;

Quote* quote-QuoteServer. getQuote (Order- >Symbol) ; If (quote->NationalMarket="N") sendToMarket (Order, remainingTIF (Order. TIF), "SODS"); else // if small cap { Order->Parameters ="SNET PREF =" + quote. topMMID ; S endToMarket (Order, remainingTIF (Order. TIF), "SNET") end elseif small cap }//end if (Order->scannedMarkets) }//end if marketable else//non marketable { //send to default market with remaining timeout // and at the original order price // and marked as a normal, non-smart order Order->FloatingPrice = Order->Price ; sendToMarket (Order, remainingTIF (Order. TIF), DefaultMarket) ; }// end else } // end smartContinueOrder() sendToMarket ( (Order *) Order, RemainingTIF, MarketPtr) Order->floatingShares = Order->RemainingShares ;

Order->TIF = RemainingTIF ; MarketPtr = ifMarket->CreateOrder (Order) ; The ifOrderEventSink Class (reference 207 on Figure 2) The ifOrderEventSink class provides the member methods for interface between the order managers and the smart executor. The member methods of ifOrderEventSink, described below and identified on Figure 2, are Startup () (290), ReceiveOrderMessage () (292), and Shutdown () (293).

Startup () (reference 290 on Figure 2) In the illustrated embodiment, ifOrderEventSink. Startup () is called from the operating system as an executable to begin operation of the entire market service and smart executor. At startup time, as shown on Figure 5, a market service (108), that is, the member method ifOrderEventsink. Startup () (290), first can call (512, 516, 520, 524, 528, 532) constructors (502, 504, 506, 508, 510) for ifMarlcetEventSink, ifSmartExecutorRequest, SmartExecutor, ifExecutorEventSink, and Market.' In the illustrated embodiment, only one class object is instantiated for ifMarketEventSink, ifSmartExecutorRequest, SmartExecutor, and ifExecutorEventsink. In embodiments in which the class SmartExecutor is implemented by inheritance from ifMarketEventSink and ifSmartExecutorRequest, then the market service starts up by calling only the constructor for SmartExecutor instead of the constructors for ifMarketEventSink and ifSmartExecutorRequest. In typical embodiments, one class object for ifExecutorEventsink is created.

In the illustrated embodiment, multiple specializations or derived instances of if Market are constructed (510), one for each market that can receive orders.

The specializations of if Market are derived class objects, one for each market, each containing private member methods designed to work with a particular market. More specifically, the specializations of if Market each implement the requirements of the well-known communications protocol of a particular market.

In the illustrated embodiment, the constructors (502, 504, 506, 508, 510) all return pointers to the class objects constructed (514, 518, 522, 526, 530, 534) for storage in the market service (108). The constructor call (516) to ifSmartExecutorRequest () passes as a parameter for storage in ifSmartExecutorRequest the pointer to the ifMarketEventSink class object.

After constructing the class objects for the smart executor, in the embodiment illustrated, ifOrderEventSink. Startup () (290) makes multiple calls (602) to if SmartExecutorRequest->RegisterMarketO (222) as shown on Figure 6, one such call for each ifMarket class object constructed.

Finally, ifOrderEventSink. Startup () uses known means to open a socket for data communications to be dedicated to messages to and from order managers.

Startup () then registers ifOrderEventSink. ReceiveOrderMeassage () as the event-driven call-back function for messages received on the socket.

ReceiveOrderMessage () (reference 292 on Figure 2) In the illustrated embodiment, this method is registered by ifOrderEventSink. Startup () with the data communications API as the call-back for messages received on a socket dedicated to handling messages to and from order managers. IfOrderEventSink. ReceiveOrderMessage () is always

available to receive messages from order managers.

IfOrderEventSink. ReceiveOrderMessage () functions by calling member methods in ifSmartExecutorRequest.

IfOrderEventSink. ReceiveOrderMessage0 determines according to the Action code in messages which member method to call in ifSmartExecutorRequest.

That is, if the Action code indicates that a message from an order manager represents a new order, if OrderEventSink. ReceiveOrderMessageO calls ifSmartExecutorRequest. RequestCreateOrder (). If the Action code indicates that a message from an order manager represents a cancellation, ifOrderEventSink. ReceiveOrderMessage () calls ifSmartExecutorRequest. RequestCancelOrder ().

Shutdown () (reference 293 on Figure 2) In the illustrated embodiment, this method is the endpoint for the entire system of the market service and smart executor. This method, like ifOrderEventSink. Startup () (290), is called from the operating system from an executable to begin operation of the entire market service and smart executor.

This method functions, as shown on Figure 8, by calling (802) ifSmartExecutorRequest. shutdown () (226).

The ifSmartExecutorRequest Class (reference 202 on Figure 2) The principal inputs to the smart executor are the member methods of ifSmartExecutorRequest which function as described below. As shown on Figure 9, the smart executor functionality in the illustrated embodiment is generally invoked by a call from the market service, that is, from if OrderEventSink. ReceiveOrderMessageO (292), to the member method ifSmartExecutorRequest. RequestCreateOrderQ (212) or to RequestCancelOrder () (214).

RequestCreateOrder (OrderMessage *) (reference 212 on Figure 2) In the illustrated embodiment, this method is called by ifOrderEventSink. ReceiveOrderMessage () (292) when a create order request message is received from the order manager (105). This method reserves a record for the new order in the order database, sends normal orders to the market identified in the order, and sends smart orders to SmartExecutor. smartNewOrder (). More specifically, RequestCreateOrder () functions as shown in the following pseudocode : RequestCreateOrder (OrderMessage *) { (Order *) Order = OrderDatabase. newOrder (OrderMessage *) ; If (is_smart (Order)) smartNewOrder () ; else sendToMarket (Order, TIF, Order->TryMarket) ; RequestCancelOrder (CancelMessage *) (reference 214 on Figure 2) Called by ifOrderEventSink. ReceiveOrderMessage () (292), this method is used in the illustrated embodiment to cancel an order previously placed into the smart executor. More specifically, RequestCancelOrder () functions as shown in the following pseudocode : RequestCancelOrder (OrderID, ManagerID) { Order* Order = OrderDatabase. find (OrderID, ManagerId) ; If (is smart (Order)) smartCancelOrder (Order) ; else

Market* MarketPtr ; //load MarketPtr with a pointer to the market //where the order is pending MarketPtr = Markets (Order->FloatingMarket) ; //and then cancel the order in the market MarketPtr->CancelOrder (Order->OrderIDMkt) ; RegisterMarket (Market *) (reference 222 on Figure 2) In the illustrated embodiment, the market service startup function ifOrderEventSink. Startup () (290), at startup time, constructs multiple specializations of if Market, one for each available market, and retains in storage pointers to those ifMarket class objects. ifOrderEventSink. Startup () then calls RegisterMarket () once for each market, passing as a parameter a pointer to each ifMarket class object in turn.

RegisterMarket (ifMarket*) (222) functions, as shown on Figure 6, by calling ifMarket->MarketName () (234) which returns the name or MMID of the market served by the called specialization of ifMarket. RegisterMarket () (222) then stores the market name and the pointer in a lookup container such as a table, arrray, or linked list. Finally, RegisterMarket () calls ifMarket->RegisterMarketEventSink (pMarketEvenSink) passing a pointer to the ifMarketEventSink object so that each ifMarket object can direct calls to member methods within the ifMarketEventSink class object.

Startup () (reference 224 on Figure 2)

In the illustrated embodiment, this method is called from ifOrderEventSink. Startup () (290) to initialize the smart executor. Called after RegisterMarketQ so that the smart executor now possesses pointers to the if Market class objects, if SmartExecutorRequest. Startup0, illuskated on Figure 6, functions as follows.

First, ifSmartExecutorRequest. StartupO calls (904) ifMarket->Startup once for each existing ifMarket class object.

Second, ifSmartExecutorRequest. Startup () calls (906) ifExecutorEventSinlc. NotifyStartup () to notify the order manager (105) that the smart executor is operative, ready to receive orders.

RegisterExecutorEventSillk (ifExecutorEventSink *) (reference 228 on Figure 2) As shown on Figure 7, this method (228) is called (916) by ifOrderEventsink. Startup () (290) at startup time to pass to the ifSmartExecutorRequest class object a pointer to the ifExecutorEventSink class object so that member methods in ifSmartExecutorRequest can call member methods in ifExecutorEventSink.

Shutdown () (reference 226 on Figure 2) In the illustrated embodiment, ifSmartExecutorRequest. Shutdown () (226) is called by ifOrderEventSink. Shutdown () (293), as shown on Figure 8. ifSmartExecutorRequest. Shutdown () will cleanly shut down the smart executor by reading through the pending orders (1006) in the order database (118), canceling (1008) all pending orders, and rejecting (1002) all new orders that might arrive during shutdown processing. If markets fail to respond to cancellations within some set period of time, shutdown processing will

continue regardless. ifSmartExecutorRequest. Shutdown () continues shutdown processing by calling (1018) ifMarket->Shutdown (), one call for each specialization of if Market. After if SmartExecutorRequest. ShutdownO has been called, ifSmartExecutorRequest. Startup () must be called before any additional orders will be processed by this implementation of the smart executor.

The if Market Class (reference 204 on Figure 2) Derived specializations of if Market class objects provide smart executor interfaces to markets. By use of if Market class objects, all class objects derived from if Market, one for each available market, present the same interface to the smart executor. The if Market member methods function as described below. There will exist generally one specialization class object of if Market for each market capable of receiving orders from the smart executor.

CreateOrder (OrderData *) (reference 230 on Figure 2) In the illustrated embodiment, this method is called by ifSmartExecutorRequest. RequestCreateOrder () (212) to enter an order in a market. This method assigns a completely unique identification code OrderIDMkt (192 on Figure 1C). When orders are received by the smart executor, they are uniquely identified by the combination of OrderID and ManagerID (191, 189 on Figure 1C). The identification code on the market side, however, must comply with the individual market protocols, be completely unique across all orders in the order database, and fit into one field. Therefore, CreateOrder () assigns a new unique code to each order, uses the new code in the order message sent through the router to the market, and stores the code in the field Order->OrderIDMkt (192).

After assigning the new identification code, this method CreateOrder () (230), as shown on Figure 9, then converts the order data into the form required by the specific market protocol for the market to which the order is directed and transmits the order in the form of a message through a data communications connection, such as, for example, a tcp/ip connection, to the order router (112).

CancelOrder (pOrderData *) (reference 232 on Figure 2) In the illustrated embodiment, this method is used to cancel an order pending in a market. This method is called by ifSmartExecutorRequest. RequestCancelOrder () (214) to cancel an order in a market. This method functions by sending to the router a cancellation message with two pertinent elements, the OrderIDMkt code (192 on Figure 1C) identifying the order to cancel and an Action code set to"Cancel."The cancellation is sent in the form of a message through a data communications connection, such as, for example, a tcp/ip connection, to the order router (112).

MarketName () (reference 234 on Figure 2) In the illustrated embodiment, this method is called by ifSmartExecutorRequest. RegisterMarket () (222), as shown on Figure 6, to obtain the market name for the market administered by a if Market class object specialization. The market name is a character string such as"SNET"or "BTRD."There is one specialization object of the if Market class assigned to each market. This method marketName () (234) returns a string containing or pointing to the market name for the market.

RegisterMarketEventSink (ifMarketEventSink *) (reference 236 on Figure 2) In the illustrated embodiment, ifSmartExecutorRequest. RegisterMarket () (610) calls ifMarket->RegisterMarketEventSink (ifMarketEventSink*) (236), as shown on Figure 6, passing a pointer (612) to the ifMarketEventSink class object so that ifMarket class specializations can store the pointer and use it to direct calls to member methods within the ifMarketEventSink class object (reference 208 on Figure 2). In this embodiment, the only function of ifMarket->RegisterMarketEventSink (ifMarketEventSink*) (236) is to receive and store the pointer (612) to the class object ifMarketEventSink (208 on Figure 2) passed to it as a parameter from ifSmartExecutorRequest. RegisterMarket () (222).

Startup () (reference 238 on Figure 2) Called by ifSmartExecutorRequest. Startup () (224) to establish a data communications connection to the order router (112), in the illustrated embodiment, this method Market. Startup () (238) initializes the router connection. In some embodiments, after establishing the router connection, this method ifMarket. StartupO (238) calls ifMarketEventSink. NotifyMarketConnected () (288) to notify the smart executor that its associated market is available for orders. In some embodiments, Market. Startup () calls ReceiveMarketMessage () to establish either an event-driven receipt of a market response, or a blocking receive for a market response.

In some embodiments, in the process of establishing the data communications link with the router, if Market->Startup () determines and stores in a member data element the data communications parameters needed by all the member

functions of if Market specializations for them to communicate with the router.

If, for example, the data communications technology in use is tcp/ip, then ifMarket->Startup () will retain in storage the pertinent socket identification for the router.

ReceiveMarketMessage () (reference 233 on Figure 2) In the illustrated embodiment, this method is called by ifMarket. Startup () at startup time and thereafter runs generally continuously, in those embodiments using blocking waits, using the previously stored data communications parameters, by repeatedly requesting to receive and subsequently receiving data communications packets (914) from the order router (112), as shown on Figure 7.

In embodiments designed for event-driven function, ReceiveMarketMessageO is registered by ifMarket. Startup () with the data communications API or middleware as a callback function for a router socket. In such embodiments, the API or middleware calls ReceiveMarketMessage () when receiving responses back through the order router from markets. Packets returning from the router to be received by. ReceiveMarketMessage () represent responses to orders and cancellations.

The data communications API or middleware, in many embodiments, can call ReceiveMarketMessageO when the data communications connections to the router fails for any reason. That is, for example, a call to receive (socket) returns an ERROR code. In blocking embodiments, the call from ReceiveMarketMessage () to the API will return an error code. In event-driven embodiments, the API or middleware can support a callback to ReceiveMarketMessageO passing an error message. In most embodiments, however, ReceiveMarketMessage0, upon being informed of a failure of its

data communications connection to the router, calls if NotifyMarketDisconnected (Market* this) (288 on Figure 2) to alert the smart executor that the associated market is not available for orders and then calls ifMarket->Startup () to reestablish the market service connection to the router.

Shutdown () (reference 240 on Figure 2) In the illustrated embodiment, this method is called (1018) by ifSmartExecutorRequest. Shutdown () (226), as shown on Figure 8. This method functions by simply closing its data communications connection to the order router. If, for example, the data communications are effected through winsock or Berkeley sockets, this method simply closes the pertinent socket.

This method then calls ifMarketEventSinlc. NotifyMarketDisconnected (Market* this) (288).

The ifMarketEventSink Class (reference 208 on Figure 2) The ifMarketEventSinlc class provides member methods generally oriented to administer responses from markets. The class member methods in the illustrated embodiment function generally as described below.

NotifyOrderConfirmed (OrderConflrmedData *) (reference 274 on Figure 2) In the illustrated embodiment, this method is called when a market confirms an order, as shown on Figure 9. This method is called by Market. ReceiveMarketMessage () (233) and in turn calls smartContinueOrder () or ifExecutorEventSink. NotifyOrderConfirmed ().

More specifically, this method functions as shown in the following pseudocode : NotifyOrderConfirmed (OrderConfirmedData*) Order* Order = OrderDatabase. find (OrderConfirmedData- >OrderIDMkt) ; if (Order->IsSmart) smartContinueOrder (Order) ; else ifExecutorEventSink->NotifyOrderConfirmed (Order) ; NotifyOrderRejected (OrderRejectedData *) (reference 276 on Figure 2) In the illustrated embodiment, this method is called when a market rejects an order. This method is called by If Market. ReceiveMarketMessageO (233) and in turn calls ifMarketEventSink. NotifyOrderRejected (). This method functions as shown in the following pseudocode : NotifyOrderRejected (OrderRejectedData *) Order* Order = OrderDatabase. find (OrderRejectedData->OrderIDMkt) ; Order->FloatingShare-= OrderRejectedData->RejectedShares ; if (Order->IsSmart) smartContinueOrder (Order) ; else ifExecutorEventSink->NotifyOrderRejected (Order) ; NotifyOrderExecuted (OrderExecutedData *) (reference 278 on Figure 2)

In the illustrated embodiment, this method is called when the market executes an order, as shown on Figure 9. This method is called by IfMarket. ReceiveMarketMessage () (233) and in turn calls ifMarketEventSink. NotifyOrderExecuted0. This method in the embodiment illustrated compares the number of shares ordered with the number of shares executed, and, if there are no shares remaining for execution, the method releases the order record from the order database. In the illustrated embodiment, this method functions generally as shown in the following pseudocode : NotifyOrderExecuted (OrderExecutedData*) { Order* Order = OrderDatabase. find (OrderExecutedData- >OrderIDMKT) ; IfExecutorEventSink->NotifyOrderExecuted (Order) ; Order->RemainingShares-= OrderExecutedData->ExecutedShares ; if (Order->RemainingShares == 0) OrderDatabase. freeOrder (Order) ; else if (Order->IsSmart) Order->FloatingShares-= OrderExecutedData->ExecutedShares ; smartContinueOrder (Order) ; NotifyExecutionReport (ExecutionReportData *) (reference 280 on Figure 2)

In the illustrated embodiment, this method is called as a supplement to NotifyOrderExecuted () when a market executes an order. The purpose is to provide additional information to the order manager (105). The additional information is the execution price and the counterparty. This additional step is needed because the additional information is generally not provided by the markets immediately upon execution, but is often provided later. Markets can take many seconds, a long time to wait when a stock is active, to provide price and counterparty. The execution notification is provided in two stages, therefore, so that customers are not required to wait for the second response to learn of their executions. IfMarket. ReceiveMarketMessage () calls if MarketEventSink. NotifyExecutionReport0, which in turn calls ifExecutorEventSink. NotifyExecutionReport (), which creates and sends a data communications message to the originating order manager.

NotifyExecutionReport () would not generally call smartContinueOrder0 because NotifyOrderExecuted () already made that call.

NotifyOrderCancelled (OrderCancelledData *) (reference 282 on Figure 2) In the illustrated embodiment, this method is called when the market cancels an order. This method is called by IfMarket.ReceiveMarketMesage() (233) and in turn calls smartContinueOrder () (220) or. ifMarketEventSink. NotifyOrderCancelled () (282). This method functions as shown in the following pseudocode : NotifyOrderCancelled (OrderCancelledData *) { Order* Order = OrderDatabase. find (OrderCancelledData- >OrderIDMkt) ;

Order->FloatingShares-= OrderCancelledData- >CancelledShares ; if (Order->IsSmart) smartContinueOrder (Order) ; else ifExecutorEventsink->NotifyOrderCancelled (Order) ; NotifyOrderKilled (OrderKilledData *) (reference 284 on Figure 2) In the illustrated embodiment, this method is called when the market terminates an order before the order is executed or cancelled. This method is called by If Market. ReceiveMarketMessageO (233) and in turn calls smartContinueOrder () (220) or ifMarketEventSink. NotifyOrderKilled () 284).

This method in the illustrated embodiment functions generally as shown in the following pseudocode : NotifyOrderKilled (OrderKilledData*) Order* Order = OrderDatabase. find (OrderKilledData->OrderIDMkt) ; Order->FloatingShares-= OrderKilledData->KilledShares ; if (Order->IsSmart smartContinueOrder (Order) ; else ifExecutorEventSink->NotifyOrderKilled (Order) ; NotifyMarketConnected (MarketConnectedData*) (reference 286 on Figure 2) In the illustrated embodiment, this method is called by if Market. StartupO when a specialization of if Market is connected for data communications to the order router. NotifyMarketConnected () (286) functions by setting to TRUE a member Boolean field, called for example"MarketConnected."

NotifyMarketDisconnected 0 (reference 288 on Figure 2) In the illustrated embodiment, this method is called by ifMarket->ReceiveMarketMessage () when the data communications connection to the order router is lost. If, for example, the data communications connection to the router is effected through a winsock socket, this method is called by ifMarket->ReceiveMarketMessage () (233) when the socket is closed unexpectedly. In some embodiments, this method is also called by ifMarket->ShutdownQ when ifMarket->Shutdown () intentionally closes the data communications connection with the router.

NotifyMarketDisconnected () functions in the illustrated embodiment by resetting to FALSE a member Boolean field, called for example "MarketConnected".

The ifExecutorEventSink Class (reference 206 on Figure 2) The ifExecutorEventSink class provides member methods generally oriented to administer output from the smart executor. The class member methods function generally as described below.

NotifyOrderConfirmed (NotifyOrderConfirmedData *) (reference 242 on Figure 2) In the illustrated embodiment, this method is called from ifMarketEventSink. NotifyOrderConfirmed0 (274) when an order has been confirmed by a market. The market gave notification by sending a message back through the order router eventually received by Market. ReceiveMarketMesssage () which then called iflVIarketEventSink. NotifyOrderConfirmedU.

IfExecutorEventSink. NotifyOrderConfirmed () (242) operates by sending through a data communications network a message notifying the originating order manager (105) of order confirmation.

NotifyOrderRejected (NotifyOrderRejectedData *) (reference 244 on Figure 2) This method is called by ifMarketEventSink. NotifyOrderRejected () (276) when a market rejects an order. Market. ReceiveMarketMessage () (233) calls ifMarketEventSink. NotifyOrkderRejected() (276), which in turn calls ifExecutorEventSink. NotifyOrderRejectedO (244), which operates by sending through a data communications network a message notifying the originating order manager (105) of the rejection.

NotifyOrderExecuted (NotifyOrderExecutedData *) (reference 246 on Figure 2) In the illustrated embodiment, this method is called by if MarketEventSink. NotifyOrderExecuted0 (278) when a market executes an order. Market. ReceiveMarketMessageO (233) calls if MarketEventSink. NotifyOrderExecutedO (278), which in turn calls ifExecutorEventSink. NotifyOrderExecuted () (246), which operates by sending through a data communications network a message notifying the originating order manager (105) of the execution.

NotifyOrderCancelled (NotifyOrderCancelledData *) (reference 250 on Figure 2) In the illustrated embodiment, this method is called by ifMarketEventSink. NotifyOrderCancelled () (282) when a market cancels an order. IfMarket. ReceiveMarketMessage () (233) calls ifMarketEventSink. NotifyOrderCancelledO (282), which in turn calls ifExecutorEventSink. NotifyOrderCancelledO (250), which operates by

sending through a data communications network a message notifying the originating order manager (105) of the cancellation.

NotifyOrderKilled (NotifyOrderKilledData *) (reference 252 on Figure 2) In the illustrated embodiment, this method is called by ifMarketEventSink. NotifyOrderKilled () (284) when a market kills an order.

Market. ReceiveMarketMessageO (233) calls ifMarketEventSink. NotifyOrderKilled () (284), which in turn calls ifExecutorEventSink. NotifyOrderKilled () (252), which operates by sending through a data communications network a message notifying the originating order manager (105) of the killing.

NotifyExecutionReport (NotifyExecutionReportData *) (reference 248 on Figure 2) In the illustrated embodiment, this method NotifyExecutionReport () (248) is called as a supplement to NotifyOrderExecutedO (246) when a market executes an order. The purpose is to provide additional information to the order manager (105). The additional information is the execution price and the counterparty. This additional step is needed because the additional information is not provided by the market immediately upon execution, but is provided later. The execution notification is provided in two stages, however, so that users have a quick response. Markets can take many seconds, that is, a very long time, to provide price and counterparty. ifMarket. ReceiveMarketMessage () (233) calls ifMarketEventSink. NotifyExecutionReport ( (280), which in turn calls ifExecutorEventSink. NotifyExecutionReport () (248), which operates by sending through a data communications network a message notifying the originating order manager (105) of the execution price, number of shares executed, and the counterparty.

NotifyShutdownBegins 0 (reference 268 on Figure 2) Called by ifSmartExecutorRequest. Shutdown () (226) which was called by ifOrderEventSink. Shutdown () (293), in the illustrated embodiment, this method provides notification to order managers that the smart executor is shutting down and that no new messages will be processed. New order messages from order managers are to be rejected and new cancellation messages from order managers are to be ignored. Originating order managers (105) will be notified of orders executed before shutdown is completed.

In the illustrated embodiment, this method, ifExecutorEventSink. NotifyShutdownBegins0, operates by sending through a data communications network a message to notify connected order managers (105) to send no new order requests. The only substantive data elements in the message are the Action field (signifying beginning market shutdown) and the market service ID (comprising the range of initial letters served by the market service and smart executor being shut down).

NotifyShutdownComplete () (reference 270 on Figure 2) In the illustrated embodiment, this method provides notification to order managers that the smart executor has completed shutdown and that no more messages will be generated by it. Called by ifSmartExecutorRequest. Shutdown () (226), this method NotifyShutdownComplete () (270) operates by sending through a data communications network to order managers (105) a message that the market service is now completely disconnected from the markets, i. e., there will be no further executions of pending orders. (NotifyShutdownBegins 0 (268) already stopped delivery of new orders.) The only substantive data elements in the

message are the Action field (signifying market shutdown completion) and the market service ID (comprising the range of initial letters served by the market service being shut down).

Smart Executor Startup Procedure At startup time, as shown on Figure 5, a market service (108), that is, the member method ifOrderEventsink. Startup () (290), first can call (512, 516, 520, 524, 528, 532) constructors (502, 504, 506, 508, 510) for ifMarketEventSink, ifSmartExecutorRequest, SmartExecutor, ifExecutorEventSink, and ifMarket.

Only one class object is instantiated for ifMarketEventSink, ifSmartExecutorRequest, SmartExecutor, and ifExecutorEventsink. If the class SmartExecutor is implemented by inheritance from ifMarketEventSink and ifSmartExecutorRequest, then the market service may start up by calling only the constructor for SmartExecutor instead of the constructors for ifMarketEventSink and ifSmartExecutorRequest. One class object for ifExecutorEventsink is created.

Multiple specializations or derived instances of if Market are constructed (510), one for each market that can receive orders. The specializations of if Market are derived class objects, one for each market, each containing private member methods designed to work with a particular market. More specifically, the specializations of if Market each implement the requirements of the well-known communications protocol of a particular market.

The constructors (502, 504, 506, 508, 510) all return pointers to the class objects constructed (514, 518, 522, 526, 530, 534) for storage in the market service (108).

The constructor call (516) to ifSmartExecutorRequest () passes as a parameter for storage in ifSmartExecutorRequest the pointer to the ifMarketEventSink class object.

After constructing the class objects for the smart executor, the ifOrderEventSink. Startup () (290) makes multiple calls (602) to ifSmartExecutorRequest->RegisterMarket () (222) as shown on Figure 6, one such call for each ifMarket class object constructed. That is, ifOrderEventSink. Startup0 (290) makes one RegisterMarket () (222) call for each market that can receive orders. Each RegisterMarket () (222) call passes as a parameter a pointer (610) to one of the constructed ifN4arlcet class objects.

Each time it is called, the method RegisterMarket () calls (606) Market- >MarketName () (234) receiving as a return the name of the market stored in the subject ifMarket class object, thus allowing ifSmartExecutorRequest to retain a list of pointers and names for all ifMarket class objects in existence. In addition to calling MarketNameO (234), each time RegisterMarket () (222) is called, it also calls (608) ifMarket->RegisterMarketEventSink () (236) passing as a parameter the pointer (612) to the ifMarketEventSink class object, the pointer being retained in storage in each if Market class object so that the if Market class objects can call member methods in ifMarketEventSink to report results of operations within each if Market class object.

At this point in startup processing, the market service has created the class objects for the smart executor, connected them with pointers, and named the if Market objects.

Next the market service will officially begin smart executor operation by use of a call to ifSmartExecutorRequest->Startup (), as shown on Figure 7.

As shown in Figure 7, IfSmartExecutorRequest->Startup () (224) is called (902) from a market service (108), ifOrderEventSink. Startup () (293), to initialize smart executor operation. ifSmartExecutorRequest->Startup () is called after RegisterMarket () (222 on Figures 2 and 6) so that the smart executor object ifSmartExecutorRequest now possesses pointers to all ifMarket class objects, one for each available market.

ifSmartExecutorRequest. Startup () functions by first issuing multiple calls (904) to ifMarket->Startup () (238), one such call for each existing ifMarket class object. Each instance of ifMarket->Startup () establishes and maintains a data communications link (910) with the order router (112), whose operations and structure are described below.

In the process of establishing the data communications link with the router, Market- >Startup () determines and stores in a member data element the data communications parameters needed by all the member functions of if Market for them to communicate with the router. If, for example, the data communications technology in use is tcp/ip, then ifMarket->Startup () will retain in storage the destination socket parameters for the router.

In certain embodiments, ifMarket->Startup () in calls (912) Market. ReceiveMarketMessage () (233). ReceiveMarketMessage0 (233) then, in blocking embodiments, can run generally continuously, in foreground or background, using the previously stored data communications parameters, by repeatedly requesting to receive and subsequently receiving data communications packets (914) from the order router (112). In embodiments which use, as an alternative to blocking waits for messages, non-blocking data communications calls, ifMarket. ReceiveMarketMessage () is identified by ifMarket. Startup () as a callback function for receipt of messages from a data communications API.

Packets returning from the router to be received by ReceiveMarketMessage () represent responses to orders and cancellations. Upon startup, therefore, there are no packets to be received from the router because no orders or cancellations have yet been sent to the router. ReceiveMarketMessage (), however, in this kind of embodiment, is now prepared to receive responses as soon as orders begin to flow.

After calling each existing specialization of ifMarket->Startup (), ifSmartExecutorRequest. Startup () calls ifExecutorEventSink. NotifyStartup () to notify

(908) the order managers (105) that the smart executor is fully operational, ready to receive orders.

Smart Executor Example Operations Referring generally to Figure 9 : In a typical cycle of order operation for a smart order, processing begins when ifOrderEventSink. ReceiveOrderMessage () receives a message from an order manager (105), of the form shown in Figure 3, in which the Action field contains a type code indicating that the message comprises a new order. ifOrderEventSink. ReceiveOrderMessage () calls ifSmartExecutorRequest. RequestCreateOrder () passing as a parameter a pointer to the order.

RequestCreateOrder () stores the order in the order database and calls smartNewOrder0. smartNewOrderO initializes the Order->TryMarket index field to indicate the first market in the OrderedMarket array. The OrderedMarket array stores the eligible market identifiers in sequence, sorted according to a chosen sorting principle. smartNewOrderQ then sets the number of scanned markets to zero, Order- >ScaimedMarkets = 0. Many implementations of the invention will keep track of the number of markets to which an order has been submitted. That number is typically stored in Order. ScannedMarkets. smartNewOrder () sets the order price to the current inside price and calls smartContinueOrder ()., smartContinueOrder () contains the algorithms for deciding which market is to receive the order. smartContinueOrder () implements in this aspect of the invention an acyclic opportunity for the order to be submitted repeatedly to markets until the order times out, is cancelled, is submitted to all IOC markets at the inside price, or becomes unmarketable. If the order becomes unmarketable, smartContinueOrder () sends the order to a default market with the order's remaining time in force and original price.

If the order is eventually submitted to all IOC markets at the inside price without

being filled, the order is then submitted to a non-IOC market, such as SOES or SelectNet, again with the order's remaining time in force and original price.

Smart Executor Shutdown Procedure IfSmartExecutorRequest->Shutdown () (226) is called by the market service (108), as shown on Figure 8. Shutdown () will cleanly shut down the smart executor by canceling all pending orders and rejecting all new orders. When there are no outstanding orders in a market, Shutdown () will disconnect from each market. If a market fails to respond to cancellations after 30 seconds, Shutdown () will disconnect regardless. After shutdown has been performed, Startup () must be called before any additional orders may be processed. Shutdown () functions as described below.

First, Shutdown calls (1002) ifExecutorEventSink. NotifyShutdownBegins () (268) to notify (1004) the order managers (105) to send no new order requests. Order managers (105) and the market services may continue to receive executions of pending/floating orders until shutdown is completed.

Second, Shutdown () loops (1006) through the order database (118), and issues cancellations by calling (1008) ifMarket->CancelOrder () (232) for each order with Order. isFloating = true.

Third, Shutdown () waits for a set period of time to allow markets time to confirm cancellations. Confirmations of cancellations will be effected by calls from the router (112) to ifMarket->ReceiveMarketMessage () (233), which will in turn call ifMarketEventSink. NotifyOrderCancelled () (282), one such call for each order cancelled. It is still possible to execute an order during this period if the order is executed in a market before the market receives the cancellation. Notifications from markets of orders executed is through calls (1016) to

ifMarketEventSink. NotifyOrderExecuted () (278). Either result is acceptable so long as the orders are no longer floating.

Fourth, Shutdown () calls (1018) ifMarket->Shutdown () (240) once for each existing ifMarket class object to disconnect from all of markets.

Fifth, Shutdown () calls (1020) ifExecutorEventSink. NotifyShutdownComplete () (270) to tell the order managers (105) that the market service is now completely disconnected from the markets, i. e., there will be no further executions of pending orders.

At this point the market service (108) or the order managers (105) can be shut down, but whether they are shut down or not, the smart executor is now inoperative, no new orders coming in or going out, no pending orders executed or cancelled.

Order Router Detailed Structure The order router functions primarily by receiving and administering data structures referred to as"router packets."We refer to the order router as"the order router"or "the router."The router includes two principal software processes and two principal data structures. The two principal processes include one process called the"router message processor"or"RMP"for receiving and sending router packets. The second principal process, called the"router SQL processor"or"RSP", is for storing data representations of orders in a SQL database, a method of creating an audit trail or a transactions log.

The two principal data structures include one data structure for order packets and another data structure, called a"router connection"or"RCT,"to represent and store data describing data communications connections from the router to the market services and order ports. Although data communications connections are established

in certain embodiments of the inventions by use of any generally available technology, the embodiments described in detail here generally implement communications connections implemented with tcp/ip and the Windows-Intel API known as"winsock."User skilled in the art will recognize that other embodiments utilize other APIs including for example Berkeley sockets and the System V API known as the"Transport Layer Interface"or"TLI."Users skilled in the art will recognize that other embodiments of the invention utilize data communications protocols other than tcp/ip. User skilled in the art will recognize that other embodiments of the invention utilize data communications middleware.

The router sends and receives router packets to and from market services and to and from order ports. In all uses of router packets, the router packets utilize the same overall data structure. Order ports are additional software modules used to convert conventional data structures representing orders into the exact structure required for each market. The invention implements one order port for each market utilized by the smart executor.

There are two principal types of router packets. One type of router packet is used to establish a connection between the order router and market services or order ports and is referred to as a"hello packet."The second order packet type represents orders and is referred to as an"order packet."The same router packet data structure is used for both sending and receiving orders and responses to and from market services and to and from order ports.

An example of data structure for router packets is shown in Figure 13. The packet header (5002) stores indications of source or destination, type, and action. These three kinds of information in some embodiments of the invention are structured as separate variables if the header were implemented as a structure. Alternatively, the three kinds of information in some embodiments of the invention are bit-mapped into the single variable shown as the header (5002) in Figure 13 by performing a logical

'or'on three sets of numbers arranged as shown in Figure 17. In Figure 17, the C- style defines indicated by reference numbers 5400-5408 are used in some embodiments to denote the action represented by the packet, such as, for example, hellos, errors, rejections, confirmations, and so on. The defines indicated by reference numbers 5409-5416 are used in some embodiments to denote the packet type, such as, for example, orders or cancellations. The defines indicated by reference numbers 5417-5432 are used in some embodiments to denote the source or destination of the packet, such as, for example, market services or order ports associated with markets such as SOES, SelectNet, Island, and so on.

The router packet data structure (5000), shown in Figure 13, also contains a C-type union (5008) used to store an additional structure representing data for hellos or for orders. The hello structure (5004) is further illustrated in Figure 14. Hellos contain a connection identification code called a Registration (5102) indicating whether the new connection is for a market service or an order port, Service codes (5104) which indicate for order ports the identity of the market served by the order port, and a ClientID field (5106) containing a short nickname for order ports and an indication of the range of symbols administered for market services.

Additional detail for the order union in the router packet structure (5006 on Figure 13) is shown in Figure 15. Figure 62 shows an example structure that can comprise the union referenced as 5006 on Figure 13. The order structure (5006) as illustrated in Figure 15 includes the following fields used as described below : Date (5202)-the entry date of the order ; Time (5204)-the entry time for the order ; MarketID (5206)-the identification code for the market to which the order is directed ; example values for the MarketID field are shown in Figure 18 ;

Action (5208)-an indication of the action represented by the packet ; example values for the Action field are shown in Figure 19 ; BrSeq (5210)-representing"Branch Sequence,"a unique identifier for the order ; this identifier will be used in all packets representing changes or responses related to the same order ; Side (5212)-representing Sell, Buy, or Sell Short ; Symbol (5214)-the market symbol for the security or stock to be bought or sold through the order ; Quantity (5216)-the quantity of shares affected by the action of the packet ; that is, the original quantity ordered if the packet action is an original order, the quantity bought or sold if the packet action is an execution, the quantity of shares rejected if the packet action is a rejection, and so on ; Remaining (5218)-the quantity of shares not affected by the action of the packet ; that is, if the original quantity was 100 shares on the sell side of an order packet, and the current packet action shows an execution with quantity set to 60, Remaining will be set to 40 ; Price (5220)-contains the order price for limit orders,"MKT"or"0"for market orders ; Union (5228)-a union reserving memory storage space for order detail specific to particular markets, the invention including separate union structures defined for each market connected to the router, example names for typedefs and structure names for actual markets being illustrated at reference numbers 5230-5250 and 5254-5274 on Figure 15 with a general representative example (5254, 5276) illustrated in further detail on Figure 16.

Figure 16 shows a general example called example market order (5302), directed to an example market rather than any particular actual market, of the detail structure of the packet union used to store the order detail needed for particular markets. Included

in Figure 16 is an example C-style typedef (5314) illustrating how the example data structure (5252) is defined for use in a union. The example (5302) includes the following fields used as described below : Minimum (5304)-the minimum number of share to be executed, zero indicating that any number is allowed, an amount equal to the order quantity indicating that the execution is to be all or nothing ; TIF (5306)-time in force, the period stated in seconds for which the order remains valid ; Display (5308)-instructions to the destination market for public display of the order, typical values being"HIDDEN,""SUBSCRIBER,"and "NORMAL ;" Reference (5310)-unique order identification code assigned by the market in which the order is pending ; Contra (5312)-identification code for the party on the other side of an order.

An example of the router connection data structure (5702) is shown in Figure 20. The router connection data structure in the example (5702) includes the following fields used as described below : Socket (5704)-the socket identification returned by the API or operating system when the related data communications socket is created.

Registration (5708)-an indication whether the connection is for a market service or an order port.

Service (5710)-for connections to order ports, this field contains an identification code for the market associated with the order port ; the codes in certain embodiments, for example, are those shown in Figure 17, reference numbers 5417-5426.

ClientID [5] (5712)-for connections to market services, an array of characters indicating the range of securities symbols administered by the market service.

Packets (5712)-a pointer to the packet queue associated with the RMP associated with a router connection data structure (5702).

In one embodiment, the router is implemented as shown on Figure 21 with multiple instances of router message processors (5814, 5838) running in multiple threads, each of the router message processors (5814, 5838) having associated with it one router connection data structure or RCT (5844, 5846), each router message processor (5814, 5838) being instantiated to serve and being associated with one particular market service (5802) or order port (5830). In addition, each router message processor (5814, 5838) has associated with it a queue (5820, 5822) implemented as a linked list containing packets waiting to be sent to the particular market service (5802) or order port (5830) associated with the router message processor (5814, 5838).

Order Router Operations Bearing in mind the overall structure just described, the general operation of an RMP is described for one embodiment of the invention, shown on Figure 21, as looping repeatedly through the following steps : receiving (5812, 5834) across a data communication network (5804, 5832) a packet from the market service (5802) or order port (5830) with which the RMP (5814, 5838) is associated ; attaching (5818, 5842) that packet to the end of the packet queue (5820, 5822) associated with the RMP (5814, 5838) for the destination market service

(5802) or order port (5830) identified in the packet, if the associated packet queue (5820, 5822) exists ; attaching (5854) that packet to the end of the queue associated with the source market service (5856) for return to the market service (5856) and setting the Action field in the packet data structure to an error code, if the packet is to be routed to a destination order port (5830) and the associated packet queue (5822) for the order port does not exist ; attaching (5852) that packet to the end of a default queue (5856), if the packet is to be routed to a destination market service (5802) and the associated packet queue (5820) does not exist ; attaching (5816, 5840) a copy of the packet to the end of the SQL database queue (5824) ; retrieving (5848, 5850) a packet from the packet queue (5820, 5822) associated with the RMP (5814, 5838) ; sending (5836, 5812) across a data communication network (5804, 5832) the retrieved packet to the market service (5802) or order port (5830) with which the RMP (5814, 5838) is associated ; checking (5848, 5850) the packet queue (5820, 5822) associated with the RMP (5814, 5838) to determine whether it contains a packet to be sent to the associated market service (5802) or order port (5830) ; sending (5836, 5812) the first waiting packet, if there is one, from the associated packet queue (5820, 5822) to the market service (5802) or order port (5830) associated with the RMP (5838, 5814) ; and

removing the sent packet from the packet queue (5820, 5822).

An associated packet queue (5820, 5822) might not exist if, for example, its associated RMP (5814, 5838) were not running, had not been started, or had failed for some reason, any reason. Attaching market service packets to the default queue (5852) is robust because each RMP for a market service upon startup, in addition to the processing described above, also scans the default queue (5860) to determine whether the default queue contains packets waiting for the startup RMP (5814), and, if there are any such packets, transfers them to the RMP's associated queue (5820).

Moreover, to increase robustness, as illustrated in Figure 22, the default queue (5856), in some embodiments, as shown on Figure 22, is implemented as a persistent queue mirrored in background so that even computer crashes cannot lose the default queue.

That is, a parallel mirror process or thread (5902) can periodically read the entire default queue (5906) and write (5910) it to disk (5904). Upon restart following a failure, the mirror process (5902) can read from the disk (5904) the packets comprising the default queue (5912) and write them back to the default queue in volatile memory (5908). The same mirror process or thread (5902) is used in this embodiment also, as shown on Figure 22, to backup (5916, 5910) and restore (5912, 5914) the SQL database queue (5824).

In this embodiment of the invention, as shown in Figure 21 and Figure 22, in summary, it can be seen that no packet is ever lost for any reason. If a packet's destination queue does not presently exist for any reason, the packet is attached to the default queue (5856) or returned rejected with an error message (5854). While attached to the default queue (5856), packets are robustly protected from loss (5902, 5904). When a packet's destination queue comes again into existence, the packet is transferred to the destination queue and continues on its way (5860). All packets are copied to a SQL database (5862, 5826, 5828). The packet queue for the SQL database is robustly mirrored to persistent storage (5902, Figure 22), assuring that all

packets eventually find their way to the SQL database. The SQL database forms a complete transactions log from which all transactions can be recovered in the event of a failure. The particular transactions recovery procedure to be employed can be any of a number of known methods. The embodiment illustrated on Figure 21 and 22 uses a SQL database to implement persistant storage of a log of transactions. Other embodiments use other means of implementing persistant storage of a log of transactions.

Referring again to Figure 21 : The steps of receiving (5812, 5834) and sending (5836, 5812) packets across data communications networks (5804, 5832) are accomplished through the use of known API calls. For increased efficiency, for embodiments of the invention using the winsock API, the step of receiving a packet (5812) is preceded by a call to the winsock select () function which will return an indication whether there are any packets waiting to be received. The advantage of including this step is that select () typically returns control to the calling process much faster than the winsock functions associated with actual retrieval of tcp/ip messages. Similar efficiencies may be available from analogous calls supported by other APIs.

Referring again to Figure 21, the operation of RSP (5826), the router SQL processor, the second principal process in the router, is described as follows. The RSP is a single-instance thread or process having a persistent connection to a SQL server database (5828). The only purpose of the RSP (5862) is to retrieve packets from its queue (5824) and write them to a SQL database (5828). The RSP operates in a continuous loop in which it first checks for the presence of a packet in its queue (5824) and, if there is a packet present in the queue, retrieves the packet and writes it to the SQL database (5828). The RSP then loops back to check the queue again, and so on. In this embodiment of the invention, the RSP is implemented as a separate thread or process because writing orders to a SQL database is relatively slow compared to the speeds needed for order routing. Implementing the RSP in parallel

with the other router functions minimizes the impact of SQL database storage on the quickness of the order routing operations.

Figure 21 illustrates the overall flow of normal order routing operations. An order packet is received (5810) from a market service (5802) by an RMP (5814). The order packet field MarketID (5206 on Figure 15) identifies the order port (5838) to which the order packet is to be routed. (Figure 21 illustrates for purposes of explanation only two sets of queues and RMPs, one each for a market service and an order port.

In actual implementations of the invention, however, there will be multiple queues and RMPs for order ports and for market services.) Assuming for illustration of normal operation that the queue for the order port exists, the packet is attached (5818) to the end of the queue (5822). When the packet works its way to the top of the order port queue (5822), the RMP for the order port (5838) removes the packet from the queue (5850) and sends it 5836) to the order port (5830). The order port formulates an order according to its associated market protocol and sends the order to the market, eventually in normal course of processing receiving a response. The response is fashioned by the order port into a responsive order packet. In this case the order packet action field will indicate that the responsive packet represents an order execution. The order port (5830) sends (5834) the order packet back to the RMP (5838) for the order port. The order port's RMP reads the destination market service from the packet header and attaches (5842) the packet to the end of the queue (5820) for the destination market service (5802). When the packet works its way to the top of the queue, the RMP (5814) for the market service removes the packet from the queue (5820) and sends (5812) it to the market service (5802), thus completing one typical operational cycle of routing for a packet representing an order and a market response to the order.

Order Router Startup

The router in the embodiment under discussion is started by use of a continuously looping process called a"comiection processor."The connection processor (6004) functions, as shown on Figure 23, by requesting (6010) by known means a tcp/ip connection from an API (6006). When a connection is available, the API notifies (6012) the connection processor of the connection, and at the same time passes the connection processor the socket identification for the connection. The connection processor then creates (6014) an RCT (6008), a router connection data structure, at the same time storing the socket identification in the RCT (reference number 5704 on Figure 20) and retaining (6016) a pointer to the RCT. The connection processor then starts (6018) an RMP (6002), a router message processor, passing the RMP the pointer to the RCT, thus enabling the RMP to make API calls using the socket identification stored in the RCT. The connection processor then returns to the first step, requesting (6010) a connection from the API (6006).

At startup, therefore, the connection processor will continue to request connections and establish RCTs and RMPs until one RCT and one RMP has been established for each market service and for each order port seeking to connect to the router. Using this procedure at startup will promptly connect all of the market services and order ports intended to function with the router. By continuing throughout the trading day to seek connections, the connection processor also will promptly connect any market service or order port that is temporarily disconnected for any reason. The connection processor also will promptly connect any new market service or order port, not present at startup, that comes on-line during the trading day.

In this aspect of the invention, the market service and order port are programmed to transmit hello packets as their first transmissions after startup. As shown in Figure 14, a hello packets identifies for the RMP receiving it the registration (5102), the service (5104), and the clientID (5106) for the market service or order port to which the RMP is connected. The RMP reads the registration (5102), service (5104), and clientID (5106) from the hello packet and writes the contents of those fields to the

parallel fields in the router connection data structure (5702), references 5708, 5710, and 5712 respectively on Figure 20. In summary, the startup process as described establishes a connection to a market service or order port, creates a data structure to represent the connection, starts an RMP thread or process to administer the connection, advises the RMP whether the RMP is connected to a market service or an order port, and further advises the RMP how to identify that market service or order port for purposes of data communications. The latter step of identification for purposes of data communications, in the example tcp/ip protocol, means recording a socket identification (5704) in the field reserved for it.

Order Port Operations In one aspect of the invention, as shown on Figure 1, the order ports are connected through data communications networks (132, 134) to an order router (112) and a market (114). Each order port (128) is responsible for communications of orders, cancellations, and responses between one order router (112) and one market (114), as shown on Figure 12, although, an order router (112) can administer orders, cancellations, and responses to and from multiple order ports (128).

Upon startup, the order port registers with its associated order router by sending the router a hello message in the form shown in Figure 13, which by union includes the structure shown in Figure 14. The order port also establishes through known means a data communications connection to the market with which the order port will be associated. Recall that each order port connects to only one market.

During normal operations, the order port (128) functions by receiving order and cancellation messages from the order router (112) in the form shown in Figure 13, which by union includes the structure shown in Figure 15. The order port (128) will also receive response messages from the market in the form dictated by the particular protocol in use by the market with which the order port is associated. Market

communications protocols are well-known public information. Upon receiving an order or cancellation message, the order port (128) converts the structure of the message into the form of order or cancellation required by the particular market protocol of the market to which the order port is connected and sends the order or cancellation to the market (114). Upon receipt of a response from the market (114), the order port converts the response into the form shown in Figure 13, which by union includes the form shown in Figure 15, and sends the response to the order router (112).

Data Communications Middleware and Data Communications Frameworks The example embodiments described in detail above, generally implement data communications by use of direct calls to APIs such as winsock or Berkeley sockets.

Other embodiments of the inventions replace direct calls to APIs with calls to installations of data communications middleware. Data communications middleware is a software layer forming a programming interface designed to operate the applications programming interface ("API") layer of data communications networks by providing a generic interface to them. In an internet network, for example, the middleware operates just above the layer comprising the API, which in turn is layered just above the transport layer known as the transmission control protocol,"tcp"or "tcp/ip." One advantage of middleware is that middleware provides a common programming interface for use software applications for data communications, regardless of the underlying communications API. That is, in embodiments of the invention utilizing middleware installed in the Windows Intel environment, middleware provides an interface to Microsoft's"winsock."When embodiments of the invention originally implemented for Windows Intel are subsequently implemented on Unix systems, the middleware is reconfigured to interface with any Unix-oriented API, including for example Berkeley sockets or the System V API known as the Transport Layer

Interface or TLI. Persons skilled in the art will realize that the reconfiguration from Windows Intel to Unix, using middleware, require no changes in the applications layer. The only changes required are in the underside of the middleware, changing winsock calls to, for example, Berkeley sockets calls. Embodiments using third-party middleware products already ported from Windows Intel to Unix, require no additional programming to port such embodiments from the Windows Intel environment to Unix or to other environments or platforms.

Some embodiments of the invention are configured for message-oriented middleware.

Although message-oriented middleware is generally expected to be faster than remote procedure calls, some embodiments of the invention are implemented by use of remote procedure calls. Similarly, the data communications aspects of the invention in some embodiments are implemented using communications middleware object request brokers developed under the Common Object Request Broker Architecture or "CORBA,"the standard for interoperability developed by the nonprofit organization known as the Object Management Group of Framingham, Massachusetts. In addition to a programming interface, middleware, in some embodiments of the invention, also provides transactions logging in support of functional fault tolerance and robustness.

In addition to data communications by means of networks as described above, data communications among elements of the invention in some embodiments is implemented by use of electronic or optical transmissions of data, local area networks, wide area networks, intranets, internets, dedicated lines, satellite links, optical links, and other types of communications. Moreover, although data communications among the customer workstations, order managers, market services, order routers, and order ports in some embodiments is implemented through data communications links, an approach having certain advantages with respect to extensibility, robustness, and scalability, other embodiments of the invention achieve data communications among elements by other means including, for example, implementation of, for example, market services and order routers on the same computer utilizing compilation against

shared libraries or dynamically linked libraries supporting shares data structures and direct calls among functions, subroutines, and member methods, with no need for intervening tcp/ip data communications links or other kinds of intervening data communications links.