Method and apparatus for a fair exchange

BACKGROUND OF THE INVENTION

p-0002The present invention relates to electronic exchanges and, more particularly, to reducing potential inequities when trading using an electronic exchange.

p-0003Many exchanges throughout the world implement electronic trading in varying degrees to trade one or more tradeable objects, where a tradeable object refers simply to anything that can be traded. Tradeable objects may include, but are not limited to, all types of traded financial products, such as, for example, stocks, options, bonds, futures, currency, and warrants, as well as funds, derivatives and collections of the foregoing, and all types of commodities, such as grains, energy and metals. A tradeable object may be “real,” such as products that are listed by an exchange for trading, or “synthetic,” such as a combination of real products that is created by the trader. Electronic trading has made it easier for a larger number of people with many different trading strategies to participate in the market at any given time. The increase in the number of potential traders has led to, among other things, a more competitive market, greater liquidity, and rapidly changing prices. Speed and assimilation of information is of great importance, otherwise the risk of loss can be substantially increased.

p-0004Exchanges that implement electronic trading are generally based on centralized computers (host), one or more networks, and the exchange participants' computers (client). In general, the host forms the electronic heart of the fully computerized electronic trading system. The host's operations typically cover order-matching, maintaining order books and positions, price information, and managing and updating the database for the online trading day as well as nightly batch runs. The host typically is also equipped with external interfaces that maintain uninterrupted online contact to quote vendors and other price information systems.

p-0005Typically, traders can link to the host through one or more networks, where a network can include a direct data line between the host and the client, or where a network can also include other common network components such as high-speed servers, routers, gateways, and so on. For example, a high-speed data line can be used to establish direct connections between the client and the host. In another example, the Internet can be used to establish a connection between the client and the host. There are many different types of networks, and combinations of network types, known in the art that can link traders to the host.

p-0006Regardless of the way in which a connection is established, the exchange participants' computers allow traders to participate in the market. They use software that creates specialized interactive trading screens on the traders' desktops. The trading screens enable traders to enter and execute orders, obtain market quotes, and monitor positions. The range and quality of features available to traders on their screens varies according to the specific software application being run.

p-0007Each market typically supplies the same information to and requires the same information from every trader. The bid and ask quantities and prices make up the primary market data and everyone logged on to trade can receive this information if the exchange provides it. Similarly, every exchange typically requires that certain information be included in each order. For example, traders typically supply information like the name of the commodity, quantity, restrictions, price and multiple other variables. Without all of this information, the exchange may not accept the order. In general, this input and output of information is the same for every trader.

p-0008In general, many market participants follow the same rules for decision-making. Given the same inputs (e.g., prices, market conditions, external indicators), a significant population will often come to the same decision regarding whether to buy or sell a certain tradeable object at a certain price. Inside market prices and the exchange order book information are often factors considered in a decision to send an order to the market.

p-0009Electronic exchanges typically award order priority based upon a first-in-first-out (FIFO) basis. At these exchanges, orders that are received earlier get a higher priority regardless of when the orders were actually sent. This means that there is a race, and at least a perceived advantage, to be the first in line. The same is true for deleting resting orders, as well such as unmatched limit orders in the exchange order book. Thus, poor network performance can cause a double disadvantage for any market participant. First, a trader or an automated trading system (ATS) will receive market information from the exchange later and, second, orders sent from the trader or ATS to the exchange will have a longer delay.

p-0010Having a faster connection to the exchange is therefore of foremost urgency for a large population of traders. However, if one group of traders has faster access to market data and the ability to send transactions faster than another group, this will tend to create an unfair environment, where one or a few participants will turn huge profits while others' ability to compete will be hampered. Similarly, an unfair environment would be created if certain groups of traders were given preferred access to an exchange. For exchanges, this could lead to a situation where many liquidity providers that cannot get preferred access will not compete.

p-0011One solution to this problem is to create a unified access policy and system architecture. For example, everyone may receive the same connection to the exchange (e.g., access speed and number of routers/hops/access servers). This concept may work for localized access where all participants are in the same geographic area using private networks (data lines) with stable and predictable transmission speed and latency. However, as soon as an exchange wishes to bring its market to participants outside of a controlled environment, access will no longer be the same for every participant. Communication times between continents may differ appreciably and using other (cheaper) distribution channels like the Internet and highly shared communication channels (such as Frame Relay with Burst) will cause unpredictable (typically higher) latency and lower access speed for a number of market participants. Traders that have a disadvantage will likely not take as much risk and also not participate actively in the market. To make a market really successful, every participant should have equivalent access speed and latency. This furthers competition and will lead to a fair and well-balanced market.

p-0012Another solution is to place synchronized clocks at each of the client devices, as disclosed in published U.S. patent application No. US 2002/0026321 A1, published on Feb. 28, 2002. For data sent from the host device to the client devices, the data is sent with a predetermined time (chosen by the operator) to display the data. The synchronized clocks at each of the client devices allow the simultaneous display of data at the predetermined time. Similarly, data sent from the client devices to the host device is time-stamped by the synchronized clocks at the client devices prior to being sent. Using the solution proposed in published U.S. Patent Application No. US 2002/0026321 A1 reduces some of the inequities when receiving or transmitting data; however, there are several problems with this solution. First, installing synchronized clocks at each of the client devices is costly to implement. Second, since the synchronized clocks are at the client devices, this creates security issues. The clocks may be tampered with since the client devices are uncontrolled. This is especially an issue in the context of trading. Trading typically occurs in a worldwide environment where there are a number of people trading in all sorts of uncontrolled locations. Third, this solution, while possibly suited to the periodic nature of games or contests, is not feasible for the near constant requirements of trading where thousands of transactions are consummated every day.

p-0013The advantages and features of the invention will become apparent to one of skilled in the art from the following detailed description, drawings, and appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

p-0014<figref idrefs="DRAWINGS">FIG. 1</figref> is a schematic representation of an example electronic exchange network system of a preferred embodiment.

p-0015<figref idrefs="DRAWINGS">FIG. 2</figref> is one example of a packet with timing data.

p-0016<figref idrefs="DRAWINGS">FIG. 3</figref> is a flow chart illustrating an example process for formulating data with timing information and sending the data from a host device to a network device.

p-0017<figref idrefs="DRAWINGS">FIG. 4</figref> is a flow chart illustrating an example process for receiving data with timing information and managing the data based on timing information.

p-0018<figref idrefs="DRAWINGS">FIG. 5</figref> is a flow chart illustrating an example process for determining when to forward stored data to a client device based on timing information.

p-0019<figref idrefs="DRAWINGS">FIG. 6</figref> is a flow chart illustrating an example process for managing data using timing information sent from a client device for ultimate submission to a matching engine.

p-0020<figref idrefs="DRAWINGS">FIG. 7</figref> is a flow chart illustrating an example process for determining when to forward stored data to a matching engine based on timing information.

p-0021<figref idrefs="DRAWINGS">FIG. 8</figref> is a flow chart illustrating an alternative example process for determining when to forward data to a plurality of client devices based on timing information.

p-0022<figref idrefs="DRAWINGS">FIG. 9</figref> is a flow chart illustrating an alternative example process for ordering data at a host device using timing information.

DETAILED DESCRIPTION OF THE PRESENTLY PREFERRED EMBODIMENT(S)

p-0023Trading in an electronic exchange necessitates fairness for all who participate. Any inequity (or even a perceived inequity) will reduce one's incentive to participate. Leveling the playing field for all should result in greater participation in the competition. The trading context has several inequities that are, in effect, a barrier to entry for some who might otherwise participate. As discussed in the background section, decision-making in trading is largely based on current market conditions. An exchange system would normally aggregate a central order book and send out a broadcast to all end nodes with the current aggregated best prices as well as, in some instances, order book information (market depth). The exchange also sends out trade information and updated order book information when matches occur. Since all this data is particularly important when making trade decisions, any speed advantage/disadvantage would give a significant advantage/disadvantage to a single participant or group of participants. Reducing or eliminating these inequities will thereby promote participation and competition.

p-0024The preferred embodiments, referred to herein as the “fair exchange,” are provided to reduce potential inequities in electronic trading in a practical manner. The following description is presented to enable a person of ordinary skill in the art to make and use the invention, and is provided in the context of a particular application and its requirements. Various modifications to the preferred embodiment will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the invention. Thus, the present invention is not intended to be limited to the embodiment shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein. The fair exchange can be used with any electronic exchange or matching system for the trading of any type of tradeable object. While the examples set forth herein relate to an electronic exchange, the present invention may be applied to other time-sensitive transmissions in a network. Examples of those time-sensitive applications include, but are not limited to: (1) news or other financial information being disseminated to traders; (2) auctions of property (such as airline tickets, concert tickets, or any other type of property) involving competitive price bidding among numerous bidders; and (3) game competitions among multiple competitors.

p-0025Referring to <figref idrefs="DRAWINGS">FIG. 1</figref>, there is shown a block diagram of one example network configuration of a preferred embodiment of the fair exchange. The exchange host system <b>10</b> includes a matching engine <b>11</b>, a central order book <b>12</b>, central communication servers <b>18</b>, <b>26</b> and a clock <b>24</b>. The central order book <b>12</b> may be implemented using known techniques on a processor <b>14</b> and a memory device <b>16</b>. The processor <b>14</b> may comprise a microprocessor, a microcontroller, or any device that performs arithmetic, logic or control operations. The memory device <b>16</b> may include non-volatile memory devices such as a ROM and/or volatile memory devices such as a RAM. The matching engine <b>11</b> may also be implemented using known techniques on a separate server or processor and memory device (not shown). Alternatively, the matching engine <b>11</b> may be integrated with the central order book <b>12</b>. In an alternate embodiment, rather than having a central matching engine <b>11</b>, the matching engine may be distributed among different local and/or remote devices.

p-0026The central order book <b>12</b> is connected to one or more central communication servers. In the example of <figref idrefs="DRAWINGS">FIG. 1</figref>, two central communication servers, <b>18</b> and <b>26</b> are illustrated. The central communication servers <b>18</b>, <b>26</b> may include a processor <b>20</b>, <b>28</b> and a memory device <b>22</b>, <b>30</b>. The processors <b>20</b>, <b>28</b> may be a microprocessor, a microcontroller, or any device which performs arithmetic, logic or control operations and the memory devices <b>22</b>, <b>30</b> may be a volatile or non-volatile memory. As shown in <figref idrefs="DRAWINGS">FIG. 1</figref>, the central communication servers <b>18</b>, <b>26</b> are communication servers located in the exchange host system <b>10</b>, for example using a LAN connection, which would handle connections from, for example, multiple locally deployed communication servers, such as by local communication servers <b>38</b>, <b>46</b>.

p-0027In <figref idrefs="DRAWINGS">FIG. 1</figref>, the host system <b>10</b> includes a clock <b>24</b>. The clock <b>24</b> may send its clock signal to the central communication servers <b>18</b>, <b>26</b>. In the alternative embodiment, the signal from the clock <b>24</b> may be supplied to the exchange host central order book <b>12</b> as well.

p-0028The central communication servers <b>18</b>, <b>26</b> may be connected to networks <b>32</b>, <b>34</b>. A network is a group of two or more computers linked together. There are many types of networks such as local area networks and wide area networks. Networks can also be characterized by topology, protocol, and architecture. Networks are often comprised of a variety of direct connections and network components such as high-speed servers, routers, gateways, and so on. An example of a network is the Internet. However, any type of network configuration can be used with the preferred embodiment described herein.

p-0029As shown in <figref idrefs="DRAWINGS">FIG. 1</figref>, the local communication servers <b>38</b>, <b>46</b> may be connected to the host system <b>10</b> by the networks <b>32</b>, <b>34</b>. While the preferred embodiment is described herein with reference to local communication servers <b>38</b>, <b>46</b> in communication with central communication servers <b>18</b>, <b>26</b> via networks <b>32</b>, <b>34</b>, these connections may be established in any manner, including by a direct connection such as a T1 or ISDN line. It is not necessary that the networks <b>32</b> and <b>34</b> be distinct. Rather, they may be the same network or overlap to any degree.

p-0030Local communication servers <b>38</b>, <b>46</b> are preferably local points of reference whose location is chosen to be geographically close to a concentration of client devices, such as in the same city or country. For a European exchange for example, a local communication server <b>38</b> may be located in and serve traders in a major metropolitan area, such as New York or Chicago, and a local communication server <b>46</b> may be located in and serve traders in London. The local communication servers <b>38</b>, <b>46</b> are preferably controlled by the exchange or some other reliable entity. The preferred embodiments, however, are not limited by what entity controls the local communication servers <b>38</b>, <b>46</b>. The local communication servers <b>38</b>, <b>46</b> may include a processor <b>40</b>, <b>48</b> and memory device <b>42</b>, <b>50</b>. The processors <b>40</b>, <b>48</b> may be a microprocessor, a microcontroller, or any device which performs arithmetic, logic or control operations and the memory devices <b>42</b>, <b>50</b> may be a volatile or non-volatile memory. As shown in <figref idrefs="DRAWINGS">FIG. 1</figref>, the local communication servers <b>38</b>, <b>46</b> are coupled to clocks <b>36</b>, <b>44</b>. The clocks <b>24</b>, <b>36</b> and <b>44</b> are utilized by the servers in one embodiment, to control the timing of the sending of information. Aside from controlling the timing of the sending of information, the servers <b>18</b>, <b>26</b>, <b>38</b>, <b>46</b> are used for data distribution to and from the end nodes.

p-0031Client devices <b>52</b>, <b>54</b>, which are used by participants in the electronic exchange, are connected to the local communication servers <b>38</b>, <b>46</b>. These connections can be achieved in many different ways that are well known by those of ordinary skill in the art. For example, the connections can be direct or over a network as described above. In one embodiment, the client devices <b>52</b>, <b>54</b> include a processor <b>56</b>, <b>60</b> and at least one memory device <b>58</b>, <b>62</b>. The processors <b>56</b>, <b>60</b> may be a microprocessor, a microcontroller, or any device which performs arithmetic, logic or control operations and the memory devices <b>58</b>, <b>62</b> may be a volatile or non-volatile memory. The client devices <b>52</b>, <b>54</b> are not limited to any particular hardware and/or software, but rather maybe any device that is capable of communicating with host system <b>10</b>. For example, the client devices <b>52</b>, <b>54</b> may be personal computers, workstations, personal digital assistants (“PDAs”) smart phones, or any other wired or wireless communication devices.

p-0032The clocks <b>24</b>, <b>36</b>, <b>44</b> can be any synchronized clock. Various methods of implementing a reliable synchronized clock are known to those of ordinary skill in the art. In one preferred embodiment, the clocks are high precision reference clocks that synchronize with an atomic clock (such as one maintained by the National Institute of Standards and Technology in Colorado) via radio waves. In another preferred embodiment, the clocks are synchronized to a reference clock via the Network Time Protocol (NTP). As known to those of ordinary skill in art, the NTP is a widely used protocol in the Internet and in other networks to synchronize computer clocks to a national (or international) reference time. In another embodiment, the clock may incorporate a global positioning system (GPS) receiver to provide synchronization with a reference clock. The invention is not limited to any particular way of synchronizing the clocks or to the frequency at which the clocks are synchronized. The clocks may be accessible by any device within the system, such as the host system, devices within the network or the client devices. In one aspect, a clock is incorporated within a device within the system. Alternatively, a clock may be a standalone unit which may be accessible by a device within the system. Although the embodiments discussed herein reference separate clocks located at each local communication server and at the host, it is possible for some or all of these devices to remotely reference a time source and not use a local clock.

p-0033<figref idrefs="DRAWINGS">FIG. 1</figref> illustrates merely one example architecture for the fair exchange. <figref idrefs="DRAWINGS">FIG. 1</figref> does not necessarily disclose all of the components that could be used in this type of system. For example, this type of electronic trading system may include gateways that convert exchange specific protocols to client device specific protocols. In a preferred embodiment, clients <b>52</b>,<b>54</b> connect to the local communication servers <b>38</b>, <b>46</b> via gateways. Alternatively, the local communication servers <b>38</b>, <b>46</b> could include gateways. For example, <figref idrefs="DRAWINGS">FIG. 1</figref> illustrates two central communication servers <b>18</b>, <b>26</b>. Fewer or more communication servers may be used. In addition, <figref idrefs="DRAWINGS">FIG. 1</figref> illustrates two networks <b>32</b>, <b>34</b>. A single network, such as a wide area network, may be used. Alternatively, multiple networks, including different types of networks (e.g., LAN, WAN, etc.), may be used. Moreover, <figref idrefs="DRAWINGS">FIG. 1</figref> illustrates two local communication servers <b>38</b>, <b>46</b>; however, fewer or more communication servers may be used.

p-0034An electronic exchange typically supplies to, and requires the same information from, every trader. For example, exchange host central order book <b>12</b> may send market data information to the client devices <b>52</b>, <b>54</b> regarding the bid and ask quantities and/or prices in the market. Trading applications running on the client devices <b>52</b>, <b>54</b> may receive, process and display the market data information. Similarly, traders may send, via the client devices <b>52</b>, <b>54</b>, orders to the exchange host system <b>10</b>. Every exchange typically requires that certain information be included in each order. For example, traders must generally send to the exchange information like their identification, the name of the tradeable object, quantity, restrictions, price and other information. Once the market receives the transaction, the matching engine <b>11</b> attempts to match buy orders with sell orders.

p-0035Order status and market information data, which may be in the form of packets, may be sent from host system <b>10</b> to client devices <b>52</b>, <b>54</b> via central communication servers <b>18</b>, <b>26</b>, networks <b>32</b>, <b>34</b> and local communication servers <b>38</b>, <b>46</b>. Likewise, data may be sent from the client devices <b>52</b>, <b>54</b> to the host system <b>10</b> via the local communication servers <b>38</b>, <b>46</b>, the networks <b>32</b>, <b>34</b> and the central communication servers <b>18</b>, <b>26</b>.

p-0036Examples of information that may be sent to the client devices <b>52</b>, <b>54</b> from the host system <b>10</b> include inside market information and market depth information. Inside market information as used herein means the highest bid price and the lowest ask price. Market depth information as used herein means information associated with all or any part of the current bid and ask quantities as represented in the order book <b>12</b>. Other market information that maybe sent to the client devices <b>52</b>, <b>54</b> from the host system <b>10</b> may include the last traded quantity (LTQ), the last traded price (LTP), the total traded quantity (TTQ), and so on. The host system <b>10</b> typically determines which market information, including what portion of the market depth, is sent to the client devices <b>52</b>, <b>54</b>.

p-0037The fair exchange preferably reduces the inequities discussed in the background section above. For example, one embodiment of the fair exchange may cause data sent from the host system to the client devices to be displayed nearly simultaneously at the client devices. Another embodiment of the fair exchange may cause data sent from the client devices to be prioritized at the host based on when the data was sent from a local communication server to which a group of client devices have roughly equivalent access (as opposed to being based only on when the data is received at the host). More detail on these embodiments and other embodiments are described below.

h-0004Data Sent from the Host System to the Client Devices

p-0038In a preferred embodiment, market data may be sent to the client devices <b>52</b>, <b>54</b> from the local communication servers <b>38</b>, <b>46</b> simultaneously or nearly simultaneously so that the display on the client devices <b>52</b>, <b>54</b> is nearly simultaneous. The time at which the market information is to be sent to the client devices may be determined by the host system <b>10</b>, with the actual release being controlled by the local communication servers <b>38</b>,<b>46</b>.

p-0039In one embodiment, the time that data is to be released from the local communication servers <b>38</b>, <b>46</b> may be included in the packet sent from the host system. Referring to <figref idrefs="DRAWINGS">FIG. 2</figref>, there is shown one example of a packet <b>64</b> with timing data <b>68</b>. The packet <b>64</b> may include client device information <b>66</b> that indicates the address or an identification for a client device or group of client devices so that the packet may be routed to the client device(s). Alternatively, the packets being sent from the exchange host may not include any destination information and routing or multicasting techniques known to those of ordinary skill in the art can be employed to ensure that data is forwarded to the appropriate location. The packet <b>64</b> further includes data <b>70</b> (such as market information) that may be formatted for display at the client device. The timing data <b>68</b> preferably relates to the control of the timing of the transmission of the packet <b>64</b> through the network. For example, the timing data may comprise a “send time.” As discussed below, the “send time” may be a predetermined time later than when the packet <b>64</b> is sent from the host device. This “send time” may instruct the local communication servers <b>38</b>, <b>46</b> to send the packet when the actual time equals the “send time.” The local communication servers <b>38</b>, <b>46</b> may compare the “send time” to a local time, as provided by the clocks <b>36</b>, <b>44</b>, to determine when to release the packet <b>64</b>.

p-0040Referring to <figref idrefs="DRAWINGS">FIG. 3</figref>, a flow chart illustrates example steps that a host system of one embodiment would take to send a packet containing timing information to the local communication servers <b>38</b>, <b>46</b>. As shown at block <b>72</b>, the travel times of the data from the host system <b>10</b> to each of the local communication servers <b>38</b>, <b>46</b> is determined. There are many ways to determine travel times for the data. Several example techniques are discussed below.

p-0041As shown at block <b>74</b>, the travel times may be examined to determine the longest travel time, referred to as “delta.” The time when the packet is sent from the host system <b>10</b> is determined (time_send_host), as shown at block <b>76</b>. Then, the timing data <b>68</b> (shown in <figref idrefs="DRAWINGS">FIG. 2</figref>) is determined. In one embodiment, the timing data <b>68</b> instructs the local communication servers <b>38</b>, <b>46</b> to send the market data on to the client devices <b>52</b>, <b>54</b> at a predetermined time, time_to_release. As shown at block <b>78</b>, the time, time_to_release, may be calculated as a time that is greater than or equal to the time_send_host+delta (as determined at block <b>74</b>). A packet is formulated with the data from the host and the timing data <b>68</b>, time_to_release, as shown at block <b>80</b>. The packet is then sent to the local communication server <b>38</b>, <b>46</b>, as shown at block <b>82</b>. Alternatively, the data can be time stamped at the host and the packet can include the time_send_host. In this alternative embodiment, the time_to_release would be calculated at the local communication servers <b>38</b>, <b>46</b>.

p-0042Referring to <figref idrefs="DRAWINGS">FIG. 4</figref>, a flow chart illustrates example steps of a device or program within the local communication server <b>38</b>, <b>46</b> of one embodiment controlling the release of a packet to the client devices <b>52</b>, <b>54</b>. A packet with timing data is received by the local communication server, as shown at block <b>84</b>. The server preferably parses the packet for the timing data (time_to_release). In one embodiment, as shown in <figref idrefs="DRAWINGS">FIG. 1</figref>, the processors <b>40</b>, <b>48</b> parse the packet to determine the timing data. Further, software may be accessed by the processor <b>40</b>, <b>48</b> from the memory device <b>42</b>, <b>50</b>. Any other technique known to those skilled in the art for reading the packet's timing data may alternatively be used. The local communication server <b>38</b>, <b>46</b> may then access the clock <b>36</b>, <b>44</b> to compare the clock time to time_to_release, as shown at block <b>86</b>. The packet is sent to the client device from the local server when the clock time is greater than or equal to time_to_release, as shown at block <b>88</b>. If the clock time is not greater than or equal to time_to_release, the packet is placed in a queue as shown at block <b>90</b>. The packets are preferably ordered in the queue starting with the packet with the earliest time_to_release. As known to those of ordinary skill in the art, different operators (e.g., greater than, less than, less than or equal to, etc.) depending on how time is being measured.

p-0043Referring to <figref idrefs="DRAWINGS">FIG. 5</figref>, a flow chart illustrates example steps of a device or program within the local communication server of one embodiment controlling the sending of packets, which have been placed in the queue. The software looks to the first packet in the queue as shown at block <b>92</b>. Then, the local communication server may access its clock to determine if the current time is greater than or equal to time_to_release as shown at block <b>94</b>. If it is, then the packet is forwarded to the client device as shown at block <b>96</b>. If it is not, the algorithm repeats itself, e.g. returns to step <b>92</b>. The software is preferably programmed to repeatedly check the earliest packet in the queue every time a time interval has elapsed.

p-0044The flow charts shown in <figref idrefs="DRAWINGS">FIGS. 3</figref>, <b>4</b> and <b>5</b> provide only an example of one embodiment and it should be understood that more or fewer steps may be utilized or the steps may occur in one or more orders which are different from the order of steps shown in <figref idrefs="DRAWINGS">FIGS. 3</figref>, <b>4</b> and <b>5</b> without departing from the spirit of the fair exchange invention. For example, rather than comparing the clock to time_to_release before placing a packet in the queue (as shown at block <b>86</b> of <figref idrefs="DRAWINGS">FIG. 4</figref>), the software could alternatively place all received packets immediately into a queue and then follow the flow chart shown in <figref idrefs="DRAWINGS">FIG. 5</figref>. There are many other alternatives that will be apparent to those skilled in the art upon review of this detailed description.

p-0045Using a specific example, if the travel time of data from the host system <b>10</b> to local communication server <b>38</b> is 0.05 seconds and if the time of travel of data from the host system <b>10</b> to local communication server <b>46</b> is 0.15 seconds, the host system <b>10</b> may determine that, in order to present the data at the client devices <b>52</b>, <b>54</b> simultaneously (or nearly simultaneously), the local communication servers <b>38</b>, <b>46</b> will send the data to the client devices 0.15 seconds after the host <b>10</b> sends the data. Specifically, if the data is sent from the host at t=0 seconds, then the time_to_release=0.15 seconds. In this manner, inequities due to differences in data travel time will be reduced because the data packets are held at the local communication servers <b>38</b>, <b>46</b> to account for one of the network paths being slower. To ensure that the data is sent from the client servers nearly simultaneously at the time_to_release, the local communication servers <b>38</b>, <b>46</b> may access clocks (and preferably clocks which are synchronized with one another as discussed above) to compare the clock time with time_to_release and to send the data at time_to_release.

p-0046Alternatively, instead of a time_to_release, the local communication servers <b>38</b>, <b>46</b> may be instructed to wait for a predetermined “wait time” before sending the data to the client devices. In the example used above, the host system <b>10</b> may instruct the local communication server <b>38</b> for client devices <b>52</b> to wait for a “wait time” of 0.10 seconds and may instruct the local communication server <b>46</b> for client device <b>54</b> to wait for a “wait time” of 0 seconds. In this manner, the wait times may reduce the disparity caused by differences in data travel times. Alternatively, the wait times or the time_to_release can be set to accommodate a period of time longer than the longest send time to provide more room for error or computer processing time. For instance, in the example above the local communication servers <b>38</b>, <b>46</b> can be programmed to send data to the client devices 0.20 seconds after the host sends the data.

h-0005Data Sent from the Client Devices to the Host System

p-0047As discussed in the background section, one important issue in electronic exchange networks is the ordering of trading events/data sent from traders. The traders send data, for example a buy or sell order or other transaction, from the client devices, e.g. <b>52</b>, <b>54</b>, to the host system <b>10</b>. For fairness, the data sent should be ranked based, at least in part, on when the data was sent from the client device (or sent from a node close to the client device). Inequities may result if the electronic exchange queues the transaction based only on when the transactions are actually received at the exchange (or host system).

p-0048In a preferred embodiment, the fair exchange uses a system of synchronized clocks close to, but not at, the client devices and at the exchange host. In a preferred embodiment, the clocks <b>36</b>, <b>44</b> are placed at local communication servers <b>38</b>, <b>46</b> and the clock <b>24</b> is placed at the exchange host system <b>10</b>. Transactions would then be time stamped close to the originator (client device) at the local communication servers <b>38</b>, <b>46</b>. If the location of the local communication servers <b>38</b>, <b>46</b> is picked wisely, using this timestamp as the basis of prioritization at the host system <b>10</b> will result in a fairer ordering of transactions at the exchange host system in a practical manner. At the host system <b>10</b> or matching engine <b>11</b>, transactions are queued in the order of their timestamp, instead of the current sequence of arrival that prefers the participant with the lowest latency to the host system or matching system. To allow the slowest participant to have relatively equal chances, in a preferred embodiment all transactions are held in the arrival queue until a transaction from the slowest participant could have arrived. This leads to the problem of determining what the wait time needs to be, since slowing down the transaction processing too much may cause overall performance degradation. Thus, it is important to have the arrival queue delay as low as possible. In particular, the delays in processing transactions sent to the host system <b>10</b> should be kept to a minimum.

p-0049In a preferred embodiment, the clocks <b>36</b>, <b>44</b> are placed at a network device geographically near the client devices, <b>52</b>, <b>54</b> such as the local communication servers <b>38</b>, <b>46</b>. In this manner, when the client devices send data to the host system <b>10</b> and the data is routed through the local communication servers <b>38</b>, <b>46</b>, the local communication servers <b>38</b>, <b>46</b> time-stamp the data using synchronized clocks <b>36</b>, <b>44</b>. The host system <b>10</b> may then compare the time-stamps of the data to approximate when the data was sent from the client devices <b>52</b>, <b>54</b>.

p-0050Referring to <figref idrefs="DRAWINGS">FIG. 6</figref>, there is shown a flow chart for how data is sent from the client devices <b>52</b>, <b>54</b> to the host system <b>10</b> and how that data is prioritized at the host system <b>10</b> in a preferred embodiment of the fair exchange. The data is sent from the client devices <b>52</b>, <b>54</b> to the host system <b>10</b>, as shown at block <b>118</b>. The data is received at a point in the network (such as, for example, local communication servers <b>38</b>, <b>46</b> in <figref idrefs="DRAWINGS">FIG. 1</figref>) and the data is time-stamped, as shown at block <b>120</b>. In the example of <figref idrefs="DRAWINGS">FIG. 1</figref>, processor <b>40</b>, <b>48</b> may access the clocks <b>36</b>, <b>44</b> to time-stamp the data. The data is then received at the host system <b>10</b>, as shown at block <b>122</b>. The data is analyzed to determine if the current time is greater than or equal to the time stamp plus the previously determined longest travel time (referred to as “delta”) as shown at block <b>124</b>. This time can be referred to as time_to_release. Alternatively, the local communication servers <b>38</b>, <b>46</b> can calculate the time_to_release and store that value in the data packet being sent.

p-0051The host system <b>10</b> preferably accesses the clock <b>24</b> to obtain the current time. If the answer is yes, the data (which in this example represents an order or transaction) is forwarded to the central matching engine <b>11</b> as shown at block <b>126</b>. If the answer is no, the data is placed in a queue as shown at block <b>128</b>. The data is preferably ordered in a queue based on the time-stamps, from earliest to latest time-stamps.

p-0052Referring to <figref idrefs="DRAWINGS">FIG. 7</figref>, there is shown a flow chart for how the host system <b>10</b> may manage the incoming transaction queue, referenced at step <b>128</b> in <figref idrefs="DRAWINGS">FIG. 6</figref>, in a preferred embodiment. The method looks to the first packet in the queue as shown at block <b>130</b>. Then, the host system <b>10</b> may access its clock to determine if the current time is greater than or equal to the time_to_release, as shown at block <b>132</b>. If it is, the transaction is forwarded to the matching engine as shown at block <b>134</b>. If it is not, the method returns to step <b>130</b>. The method is preferably programmed to repeatedly check the earliest packet in the queue every time a preset time interval has elapsed.

p-0053The flow charts shown in <figref idrefs="DRAWINGS">FIGS. 6 and 7</figref> provide only an example of one embodiment and it should be understood that more or fewer steps may be utilized or the steps may occur in one or more orders which are different from the order of steps shown in <figref idrefs="DRAWINGS">FIGS. 6 and 7</figref>, without departing from the spirit of the present invention. For example, rather than comparing the clock to the time_to_release before placing a packet in the queue (as shown at block <b>124</b> of <figref idrefs="DRAWINGS">FIG. 6</figref>), the method may alternatively place all data received immediately into a queue and then follow the flow chart shown in <figref idrefs="DRAWINGS">FIG. 7</figref>. There are many other alternatives that will be apparent to those skilled in the art upon review of this detailed description.

h-0006Determining Travel Times

p-0054There are various techniques known to those of ordinary skill in the art to determine the travel time between two devices in a network. The present invention is not limited to any particular technique. In one embodiment, travel time is monitored by using packets that contain time stamps from the originating node which are then compared with the clock time on the arrival node to determine the slowest end node. In this embodiment, a packet is sent from the central communication servers <b>18</b>, <b>26</b> to the local communication servers <b>38</b>, <b>46</b> that includes a time stamp provided by the clock <b>24</b>. The local communication servers <b>38</b>, <b>46</b> can then determine the travel time of that packet by calculating the difference between the time stamp and the time the packet is received at the local communication server <b>38</b>, <b>46</b> by accessing the clocks <b>36</b>, <b>44</b>. The local communication servers <b>38</b>, <b>46</b> may communicate the calculated travel time to the host <b>10</b>. After receiving travel times to the various local communication servers, the host may then determine the slowest travel time by comparing the different travel times. This slowest travel time can then be used as the longest send time (delta) as described above.

p-0055In an alternative embodiment, travel times can be measured using a “pinging” approach. This technique involves the central communication servers <b>18</b>, <b>26</b> pinging the local communication servers <b>38</b>, <b>46</b>. The central communication servers <b>18</b>, <b>26</b> track the time that a pinging message is sent. When a reply message is received, the central communication server can calculate the round trip time by subtracting the time the message was sent from the time the reply message was received. After pinging the local communication servers, the host can determine the slowest round trip travel time. The longest travel time (delta) may be calculated as the slowest round trip travel time divided by two.

p-0056Regardless of which technique is utilized, the system may periodically determine and adjust the longest travel time. These measurement techniques may be performed automatically or triggered manually. In the case of network problems, travel time could be excessively high for one node causing significant slow down for all market participants. To overcome this issue, an administrative delta may be imposed based, for example, on knowledge of the network, such as on average delays for all participants, or based on a select number of pings.

p-0057Other measures may alternatively be used. For example, the longest travel time may be set at any value that levels the playing field to a certain extent, while still encouraging participation in the market.

p-0058The components that are used to measure delays or assign timestamps are preferably under control of the host system or some reliable third party. This minimizes the risk of someone skewing the measurements by, for example, modifying packets that are designed to measure travel times. Therefore, the local communication servers <b>38</b>, <b>46</b>, which are preferably under the control of the host system, are better suited to measure travel times or assign timestamps than the client devices <b>52</b>, <b>54</b>. When it is necessary to measure delays or assign timestamps on a device that is not under control of the exchange or a reliable entity, one should carefully monitor the system when using the any method to determine the local line delay.

p-0059Because the largest differences in data travel times occur between the central communication servers <b>18</b>, <b>26</b> and the local communication servers <b>38</b>, <b>46</b> (due, e.g., to transcontinental lines, frame relay, etc.) the largest benefit in reducing time differences comes from synchronizing the local communication servers <b>38</b>, <b>46</b> with the central communication servers <b>18</b>, <b>26</b>. Therefore, from a practical standpoint, using the local communication servers <b>38</b>, <b>46</b> to measure delays and assign timestamps reduces the largest inequities in the system.

h-0007Additional Alternative Embodiments

p-0060In an alternative embodiment, synchronized clocks may be placed in or connected to devices in the network path further away (for example, geographically or based on network path) from the client devices. For example, rather than positioning the clocks at local communication servers <b>38</b>, <b>46</b>, devices such as access servers, routers, gateways or the like within the networks <b>32</b>, <b>34</b> may be modified to include or work with synchronized clocks. Similar to the local communication servers <b>38</b>, <b>46</b>, that device may delay transmission of the data to the client devices until a predetermined time or may delay the release for a predetermined time. Likewise, these network devices may timestamp the data sent from the client devices <b>52</b>, <b>54</b> to the host system <b>10</b>.

p-0061In another alternative embodiment, to achieve simultaneous or nearly simultaneous display of data at the client devices, the operation of the host system <b>10</b> may be modified to send data to the client devices <b>52</b>, <b>54</b> via local communication servers <b>38</b>, <b>46</b> at different times. In determining how to modify the operation of the host system <b>10</b>, at least a portion of the travel times of data from the host system <b>10</b> to each of the client devices <b>52</b>, <b>54</b> may be determined. For example, the round trip travel time (from host system <b>10</b> to local communication servers <b>38</b>, <b>46</b> back to host system <b>10</b>) may be determined. Alternatively, the travel time from the host system <b>10</b> to the local communication servers <b>38</b>, <b>46</b> may be determined. As discussed above, there are a multitude of methods of determining time of travel of data.

p-0062Based on the travel times, the host system <b>10</b> may send data to each of the client devices <b>52</b>, <b>54</b> via the local communication servers <b>38</b>, <b>46</b> at different times. In this manner, the sending of data from the host system <b>10</b> to the client devices <b>52</b>, <b>54</b> is staggered based on the travel times of data in the parts of the network in which a disparity of travel time is most likely and based on measurements that are more reliable because the components being measured can be more reliably controlled. Based on this staggered sending, the data should be received by the client devices <b>52</b>, <b>54</b> at, or nearly at, the same time. Referring to <figref idrefs="DRAWINGS">FIG. 1</figref>, at least one component in the host system host <b>10</b> may be modified. For example, either the exchange host central order book <b>12</b> or the central communications servers <b>18</b>, <b>26</b> may be modified to stagger the sending of the data. Specifically, the processor <b>14</b> in the central order book <b>12</b> may access memory <b>16</b> to access software to stagger the sending of data. Alternatively, the processor <b>20</b>, <b>28</b> in central communication servers <b>18</b>, <b>26</b> may access memory <b>22</b>, <b>30</b> to access software to stagger the sending of data.

p-0063Referring to <figref idrefs="DRAWINGS">FIG. 8</figref>, there is shown a flow chart of a host system sending data to client devices at different times. The flow chart may be implemented by processor <b>14</b> using software in memory <b>16</b> (as shown in <figref idrefs="DRAWINGS">FIG. 1</figref>). At block <b>98</b>, the travel times of data from the host system to each of the local communication servers is determined. The local communication servers may then be arranged in a look-up table in the order of longest to shortest travel times, as shown at block <b>100</b>. The look-up table may be contained in memory device <b>16</b> (<figref idrefs="DRAWINGS">FIG. 1</figref>). A pointer is set to the local communication server with the longest travel time, as shown at block <b>102</b>. The time is set to zero, as shown at block <b>104</b>. Data is then sent to the local communication server with the longest travel time, as shown at block <b>106</b>. The flow chart then enters a loop, with the pointer being incremented to the next local communication server in the look-up table, as shown at block <b>108</b>. The difference (d_t) in travel times is then determined between the local communication server at the pointer and the previous local communication server, as shown at block <b>110</b>. The system then waits the different (d_t), as shown at block <b>112</b>. Next, the data is then sent to the local communication server at the pointer, as shown at block <b>114</b>. The loop is executed until the pointer is pointing to the last local communication server in the look-up table, as shown at block <b>116</b>.

p-0064In the specific example used above (with the difference in travel time equal to 0.1 seconds), the host system <b>10</b> may stagger the sending of data (sending data first to client devices <b>54</b> via local communication server <b>46</b>, wait a predetermined time then send the data to client devices <b>52</b> via local communication sever <b>38</b>). In the current example, the host system <b>10</b> may first send data to local communication server <b>46</b> (and, thereby, client devices <b>54</b>), wait 0.1 seconds (based on the difference in travel times), and then send the data to local communication server <b>38</b> (and, thereby, client devices <b>52</b>). In this manner, client devices <b>52</b> and client devices <b>54</b> should receive the data at approximately the same time. The exchange host system preferably includes or has access to a clock <b>24</b> so that the host system <b>10</b> may wait the predetermined necessary time.

p-0065In another alternative embodiment, the operation of the host system <b>10</b> may be modified to prioritize transactions based on the time the data is received by the host <b>10</b> and based on the various travel times from the local communication servers <b>38</b>, <b>46</b>. In one aspect, the travel times of data from each of local communication servers <b>38</b>, <b>46</b> to the host system <b>10</b> may be determined. In this manner, when data is received at the host system <b>10</b>, it may be time-stamped. The host system <b>10</b> may then determine when the data was sent from the local communication servers <b>38</b>, <b>46</b> based on the time-stamp and the travel times.

p-0066Specifically, this alternative is based on an arrival queue with time-based ordering. The major difference is that this system may impose delays in a penalty scheme based on measured average travel times. If a connection were very fast, the imposed delay would be higher than for a slower connection.

p-0067Referring to <figref idrefs="DRAWINGS">FIG. 9</figref>, there is shown a flow chart of the operation of the host system <b>10</b> in this alternative embodiment in which data is ordered based on the time the local communication servers <b>38</b>, <b>46</b> send the data. The time of travel of data from each of the local communication servers <b>38</b>, <b>46</b> to the host system <b>10</b> is determined, as shown at block <b>136</b>. The time of travel may be determined by processor <b>14</b>, as shown in <figref idrefs="DRAWINGS">FIG. 1</figref>, and stored in a look-up table in memory device <b>16</b>. The host system <b>10</b> then receives the data from the client devices via the local communication servers <b>38</b>, <b>46</b>, as shown at block <b>138</b>. The data is time-stamped upon receipt by the host system <b>10</b>, as shown at block <b>140</b>. The packets may be time-stamped by assessing the clock <b>24</b>, as shown in <figref idrefs="DRAWINGS">FIG. 1</figref>. The host system <b>10</b> may then calculate the approximate time when the packets were sent from the local communication servers <b>38</b>, <b>46</b> by subtracting the time of travel (determined at block <b>136</b>) from the time-stamp of the data t, as shown at block <b>142</b>. The data is then ordered based on the calculated time, from the earliest to the latest, as shown at block <b>144</b>. For example, processor <b>14</b>, in <figref idrefs="DRAWINGS">FIG. 1</figref>, may determine the calculated time by accessing the time of travel in the look-up table in memory device <b>16</b> and order the data based on the calculated time. In this manner, the data is not ordered immediately upon receipt at the host system <b>10</b>. Rather, the data may be held temporarily for a predetermined time period (delay).

p-0068The delay may be determined in a variety of ways. The delay may be the longest travel time of data from a local communication server to the host system. Alternatively, the delay may depend on which local communication server the data is sent from. For example, the delay for data from a specific local communication server may be based on the difference between the longest travel time of data from any local communication server to the host system and the travel time of the data from the specific local communication server to the host system as follows:

p-0069tmax: maximum network delay (round trip travel time)

p-0070tn: network delay for participant n (round trip) <br />delay=<i>t</i>max/2−<i>tn/</i>2<br /> This delay calculation could alternatively be based on a measured one way travel times as discussed above. In any event, the travel times are preferably averaged over a number of samples. In still another alternate embodiment, the delay may be preselected.

p-0071Using a specific example, if the time of travel from local communication server <b>38</b> and local communication server <b>46</b> to the host device is 0.05 and 0.15, respectively, and the time stamped data from local communication server <b>38</b> and local communication server <b>46</b> is 0.3 and 0.35, respectively, the host system <b>10</b> may determine which data was sent first. In this example, calculating the time when the data was sent from each local communication server is as follows: <br />time-stamp−time of travel=time data sent from local communication server<br /> In the present example, for first local communication server <b>38</b>, the time the data was sent is 0.25 (0.3−0.05). For local communication server <b>46</b>, the time the data was sent is 0.2 (0.35−0.15). Therefore, the host device may determine that the data was actually sent first from second local communication server <b>46</b> rather than first local communication server <b>38</b>, even though the data from first local communication server <b>38</b> was received at the host first. Thus, the data from the first local communication server <b>38</b> is not processed at the time it was received at the host system <b>10</b> device (in the example, 0.3); rather, the data may be held for a predetermined period until it processed. For example, the data may be held for 0.15 seconds, based on the longest travel time of data from any local communication server to the host device. Alternatively, the data may be held for 0.1 seconds, based on the difference of the longest travel time (0.15 seconds) and the travel time for the data (0.05 seconds).

p-0072In using the apparatuses and methods described above, trading in an electronic exchange may be fairer for those who participate. Data sent from a host system to client devices may be displayed simultaneously or nearly simultaneously. Likewise, the electronic exchange may order data sent from client devices based, at least in part, on when the client device sent the data or an approximation thereof. Thus, electronic exchange trading may be more equitable.

p-0073Preferred embodiments of the present invention have been described herein. It is to be understood, of course, that changes and modifications may be made in the embodiments without departing from the true scope of the present invention, as defined by the appended claims. The present embodiment preferably includes logic to implement the described methods in software modules as a set of computer executable software instructions. A processor implements the logic that controls the operation of the at least one of the devices in the system, including the host system <b>10</b>, one, some or all of the devices in the network, and/or the client devices. The processor executes software that can be programmed by those of skill in the art to provide the described functionality.

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

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

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

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