Method and apparatus for a fair exchange

IS 2 598 152 T3

DESCRIPTION

Method and apparatus for a fair stock market

Background of the invention

The present invention relates to electronic stock markets and, more particularly, to the reduction of potential inequalities when trading through an electronic stock market.

Many stock markets around the world implement electronic commerce to a greater or lesser degree to trade one or more negotiable objects, where a negotiable object simply refers to anything that can be traded. Tradable items may include, but are not limited to, all types of financial products that are traded, such as, for example, stocks, options, bonds, futures, currencies, and warrants, as well as funds, derivatives, and collections of the foregoing, and all types of raw materials, such as cereals, energy and metals. A negotiable object can be real, such as products that are listed by a stock market for trading, or synthetic, such as a combination of real products that is created by the trader. E-commerce has made it easier for more people with many different trading strategies to participate in the market at any given time. The increase in the number of potential operators has led to, among other things, a more competitive market, greater liquidity, and rapidly changing prices. The speed and the assimilation of the information is of great importance, otherwise the risk of loss could increase substantially.

Stock markets that implement e-commerce are generally based on centralized computers (host), one or more networks, and computers of stock market participants (client). In general, the host forms the electronic heart of the fully computerized e-commerce system. Host operations typically cover order matching, order portfolio and position maintenance, price information, and day trading database management and update online, as well as batch execution by the night. The host is also typically equipped with external interfaces that maintain seamless online contact with listing vendors and other pricing information systems.

In general, operators can link to the host through one or more networks, in which a network can include a direct data line between the host and the customer, 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 operators to the host.

Regardless of the way a connection is established, the teams of the participants in the stock market allow traders to participate in the market. They use software that creates specialized interactive trading screens on traders' desks. Trading screens allow traders to enter and execute orders, obtain market quotes, and track positions. The variety and quality of features available to operators on their screens varies depending on the specific software application running.

Each market normally supplies the same information to and requires the same information from each operator. Supply, quantities demanded and prices make up the primary market data and everyone who has accessed the trade can receive this information if a stock market is offered. Similarly, each stock market generally requires that you include certain information in each order. For example, operators typically supply information such as product name, quantity, restrictions, price, and multiple other variables. Without all this information, the stock market cannot accept the order. In general, this input and output of information is the same for all operators.

In general, many market participants follow the same rules for decision making. Given the same inputs (for example, prices, market conditions, external indicators), a significant population often reaches the same decision regarding the possibility of buying or selling a certain negotiable object at a certain price . Internal market prices and stock market order book information are often factors considered in the decision to place an order to the market.

The electronic stock market typically awards priority order based on a first-in, first-out (FIFO) basis. In these stock markets, orders received earlier are given a higher priority, regardless of when the orders actually ship. This means that there is no race, and at least a perceived advantage, to be first in line. The same is true for suppressing resting orders as well as unmatched limit orders in the stock market order book. Therefore, the poor performance of the network can cause a double disadvantage for any participant in the market. In first

ES 2 598 152 T3 instead, a trader or automated trading system (ATS) will receive Stock Market Information later and secondly, the trader or ATS sent orders to the stock market will have a longer delay.

Having faster connections to the stock market is therefore the main 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 the other group, this will tend to create an unfair environment, where one or a few participants would make huge profits, while that the ability to compete of others would be hampered. Similarly, an unfair environment would be created if certain groups of operators were given preferential access given to a stock market. For equity markets, this could lead to a situation where many liquidity providers who cannot get preferred access will not compete.

One solution to this problem is to create a unified access system and policy architecture. For example, everyone can receive the same connection to the stock market (eg access speed and number of access routers / hops / servers). This concept can work to access specific points where all participants are in the same geographic area using private data networks (lines) with stable and predictable transmission speed and latency. However, as soon as a stock market wants to bring participants outside of a controlled environment into its market, access will no longer be the same for each participant. Communication times between continents can vary significantly and the use of other (cheaper) distribution channels such as the Internet and highly shared communication channels (such as Burst Frame Relay) will cause unpredictable (usually higher) latency and lower speed. access of a number of market participants. Traders who are disadvantaged will probably not take as much risk and will not actively participate in the market either. To create a very successful market, each participant must have equivalent access speed and latency. This encourages competition and will lead to a fair and well balanced market.

Another solution is to place the synchronized clocks in each of the client devices, as disclosed in United States Patent Published Application No. 20002/0026321 A1, published February 28, 2002. For data sent from the host device to client devices, the data is sent with a predetermined time (chosen by the operator) to display the data. Synchronized clocks on each of the client devices allow simultaneous data viewing at predetermined times. Similarly, data sent from client devices to the host device is time-logged by synchronized clocks on client devices before being sent. The use of the solution proposed in the United States Patent Published with Application No. 20002/0026321 A1 reduces some of the inequalities when receiving or transmitting data; however, there are several problems with this solution. First, installing synchronized clocks on each of the client devices is expensive to implement. Second, since the synchronized clocks are on the client devices, this creates security problems. Clocks can be tampered with because client devices are not controlled. This is especially a problem in the context of negotiation. Trading normally occurs in a worldwide environment, where there are a number of people trading in all kinds of uncontrolled places. Third, this solution, while possibly tailored to the periodic nature of games or contests, is not feasible for close constant trading requirements where thousands of transactions take place every day.

US5953708 describes a transaction control system having a time delay adjustment transmission mechanism. In one example, the time setting is done at the terminal devices. In another example, the time setting is done on a central computer.

The advantages and features of the invention will be apparent to one of ordinary skill in the art from the following detailed description, drawings, and appended claims.

Summary of the invention

In accordance with the present invention, there is provided a method and a system in accordance with the appended claims

Brief description of the drawings

Figure 1 is a schematic representation of an exemplary electronic stock market network system of a preferred aspect

Figure 2 is an example of a packet with time data.

Figure 3 is a flow chart illustrating an exemplary process for formulating data with time information and sending data from a host device to a network device.

Figure 4 is a flow chart illustrating an exemplary process for receiving data with time information and managing the data based on the time information.

Figure 5 is a flow chart illustrating an exemplary process for determining when to transmit data stored in a client device based on time information.

IS 2 598 152 T3

Figure 6 is a flow chart illustrating an exemplary process for managing data using time information sent from a client device for final presentation to a matching engine. Figure 7 is a flow chart illustrating an exemplary process for determining when to transmit stored data to a matching engine based on time information.

Figure 8 is a flow chart illustrating a process for determining when to transmit data to a plurality of client devices based on time information in accordance with one embodiment.

Figure 9 is a flow chart illustrating an alternative exemplary process for sorting data on a host device by time information.

Detailed description

Trading on an electronic stock market requires fairness for all participants. Any inequality (or even perceived inequity) will reduce one's incentive to participate. A level playing field for all should lead to greater participation in the competition. The negotiating context has several inequalities that are, in effect, a barrier to entry for someone who could participate in another way. As described in the background section, decision making in trading is largely based on current market conditions. A stock market system would typically add a central order book and send a broadcast message to all end nodes with the current best aggregated prices, as well as, in some cases, order book information (depth of market). The stock market also sends trading information and updated order book information when matches occur. Since all of this data is particularly important when making trading decisions, any speed advantage / disadvantage would give a significant advantage / disadvantage to a single participant or group of participants. Reducing or eliminating these inequalities would thus promote participation and competition.

The preferred aspects, referred to herein the fair stock market, are provided to reduce the possible inequalities in electronic commerce in a practical way. The following description is presented to enable one 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. It can be used with any electronic stock market or matching system for trading any type of negotiable object. While the examples set forth herein refer to an electronic stock market, the present invention can be applied to other hot transmissions on a network. Examples of these urgent applications include, but are not limited to: (1) news or other financial information that is disseminated to operators; (2) auctions of goods (such as airline tickets, concert tickets, or any other type of property) that involves making a competitive price offer among numerous bidders; and (3) game competitions between various competitors.

Referring to Figure 1, a block diagram of an exemplary network configuration of a preferred aspect, the fair stock market, is shown. The stock market host system 10 includes a matching engine 11, a central order book 12, central communication servers 18, 26, and a clock 24. The central order book 12 can be implemented using known techniques on a processor 14 and a memory device 16. Processor 14 may comprise a microprocessor, a microcontroller, or any device that performs arithmetic, logic, or control operations. Memory device 16 can include non-volatile memory devices such as ROM and / or volatile memory devices such as RAM. The matching engine 11 can also be implemented using known techniques on a separate server or processor and on the memory device (not shown). Alternatively, the corresponding engine 11 can be integrated with the central order book 12. In an alternative aspect, instead of having a central matching engine 11, the matching engine can be distributed among the different remote and / or local devices. .

The central order book 12 is connected to one or more central communication servers. In the example of Figure 1, two central communication servers, 18 and 26 are illustrated. The central communication servers 18, 26 may include a processor 20, 28 and a memory device 22, 30. The processors 20, 28 can be a microprocessor, a microcontroller, or any device that performs arithmetic, logic or control operations and the memory devices 22, 30 can be a volatile or non-volatile memory. As shown in Figure 1, the central communication servers 18, 26 are communication servers located in the host system of the stock market 10, for example via a LAN connection, which would manage connections from, for example, multiple deployed communication servers locally, such as by local communication servers 38, 46.

In Figure 1, the host system 10 includes a clock 24. The clock 24 can send its clock signal to the central communication servers 18, 26. In the alternative aspect, the clock signal 24 can be supplied to the wallet. Central 12 stock market host orders as well.

Central communication servers 18, 26 can be connected to networks 32, 34. A network is a group of two or more computers connected to each other. 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 usually

ES 2 598 152 T3 be composed of a wide 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 aspect described herein.

As shown in Figure 1, local communication servers 38, 46 can be connected to host system 10 over networks 32, 34. Although the preferred embodiment is described herein with reference to local communication servers 38, 46 in communication with the central communication servers 18, 26 through networks 32, 34, these connections can be established in any way, including by a direct connection, such as a T1 or ISDN line. Networks 32 and 34 do not need to be different. Rather, they can be the same network or overlap to any degree.

Local communication servers 38, 46 are preferably local reference points 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 stock market, for example, a local communication server 38 can be located at and serving traders in a large metropolitan area, such as New York or Chicago, and a local communication server 46 can be located at and served to operators in London. The local communication servers 38, 46 are preferably controlled by the stock market or some other trusted entity. However, the preferred aspects are not limited whereby the entity controls the local communication servers 38, 46. The local communication servers 38, 46 may include a processor 40, 48 and the memory device 42, 50. The processors 40, 48 can be a microprocessor, a microcontroller, or any device that performs arithmetic, logic or control operations and the memory devices 42, 50 can be volatile or non-volatile memory. As shown in Figure 1, local communication servers 38, 46 are connected to clocks 36, 44. Clocks 24, 36 and 44 are used by the servers in one example, to control the timing of the transmission of the information. Apart from controlling the timing of the information transmission, the servers 18, 26, 38, 46 are used for the distribution of data to and from the end nodes.

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

Clocks 24, 36, 44 can be any synchronized clock. Various methods of applying a reliable synchronized clock are known to those of ordinary skill in the art. In a preferred example, the clocks are high precision reference clocks that are synchronized with an atomic clock (such as one maintained by the Colorado National Institute of Standards and Technology) via radio waves. In another preferred example, the clocks are synchronized to a reference clock via the Network Time Protocol (NTP). As is known to those of ordinary skill in the art, NTP is a widely used protocol on the Internet and other networks to synchronize computer clocks with a national (or international) reference time. In another example, 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 mode of clock synchronization or the frequency at which clocks are synchronized. Clocks can be accessible by any device in the system, such as the host system, devices within the network, or client devices. In one aspect, a watch is incorporated into a device within the system. Alternatively, a clock can be a separate unit that can be accessible by a device within the system. Although the example described herein refers to separate clocks located at each local communication server and at the host, it is possible that some or all of these devices remotely reference a time source and do not use a local clock.

Figure 1 merely illustrates an exemplary architecture for the fair stock market. Figure 1 does not necessarily disclose all the components that could be used in this type of system. For example, this type of e-commerce system may include gateways that convert market-specific protocols into client device-specific protocols. In a preferred example, clients 52, 54 connect to local communication servers 38, 46 through gateways. Alternatively, the local communication servers 38, 46 could include gateways. For example, Figure 1 illustrates two central communication servers 18, 26. More or fewer communication servers can be used. Furthermore, Figure 1 illustrates two networks 32, 34. A single network, such as a wide area network, can be used. Moreover, various networks, including different types of networks (eg, LAN, WAN, etc.), can be used. On the other hand, Figure 1 illustrates two local communication servers 38, 46; however, more or fewer communication servers can be used.

IS 2 598 152 T3

An electronic stock market normally supplies to, and requires the same information from each operator. For example, the central order book 12 of the stock market host may send market data information to client devices 52, 54 regarding supply and quantities demanded and / or prices in the market. Business applications running on client devices 52, 54 can receive, process, and display market data information. In the same way, the interested parties will be able to send, through the client devices 52, 54, orders to the host system of the stock market 10. Every stock market normally requires that certain information be included in each order. For example, traders must generally send information to the stock market, such as their identification, the name of the negotiable object, quantity, restrictions, price and other information. Once the market receives the transaction, the matching engine 11 attempts to match the buy orders with the sell orders.

Order status data and market information, which can be in packet form, can be sent from host system 10 to client devices 52, 54 through central communication servers 18, 26, networks 32, 34 and local communication servers 38, 46. Similarly, data can be sent from client devices 52, 54 to host system 10 via local communication servers 38, 46, networks 32, 34 and central communication servers 18, 26.

Examples of information that can be sent to client devices 52, 54 from host system 10 include internal market information and depth of market information. Internal market information, as used herein, means the highest bid price and the lowest sell price. Market depth information, as used herein, means information associated with all or a portion of the current bid and ask amounts as represented in the order book 12. Other information about the market that can be sent to client devices 52, 54 from host system 10 can include the last negotiated quantity (LTQ), the last negotiated price (LTP), the total negotiated quantity (TTQ), and so on. The host system 10 typically determines what market information, including what portion of the depth of market, is sent to the client devices 52, 54.

The fair stock market preferentially reduces the inequalities described in the background section above. For example, one aspect of the fair stock market may cause data sent from the host system to client devices to be displayed almost simultaneously on client devices. Another aspect of the fair stock market can make data sent from client devices take priority at the host based on when the data has been sent from a local communication server that a group of client devices have more or less equivalent access (instead of relying solely on when the data is received at the host). More details on these aspects are described below.

Data sent from the host system to client devices

In a preferred aspect, the market data can be sent to the client devices 52, 54 of the local communication servers 38, 46 simultaneously or almost simultaneously, so that the display on the client devices 52, 54 is almost simultaneous. The time at which the market information is sent to the client devices can be determined by the host system 10, the actual release being controlled by the local communication servers 38, 46.

In one aspect, the time the data is released from the local communication servers 38, 46 can be included in the packet sent from the host system. Referring to Figure 2, an example of a packet 64 is shown with the time data 68. The packet 64 may include information from the client device 66 that indicates the address or an identification for a client device or group of client devices so that the packet can be routed to the client device or devices. Alternatively, the packets that are sent from the stock market host may not include any destination information and routing or multicast techniques known to those of ordinary skill in the art can be implemented to ensure that the data is sent to the appropriate location. Package 64 further includes data 70 (eg, market information) that can be formatted for display on the client device. The timing data 68 preferably refers to controlling the timing of the transmission of the packet 64 over the network. For example, the time data can comprise a shipping time. As we will see later, the send time can be a predetermined time after the moment when the packet 64 is sent from the host device. This sending time can instruct the local communication servers 38, 46 to send the packet when the current time equals the sending time. Local communication servers 38, 46 may compare the send time to a local time, as predicted by clocks 36, 44, to determine when to release packet 64.

Referring to Figure 3, a flow chart illustrates the exemplary steps that a host system, of one aspect, would have to perform to send a packet containing time information to local communication servers 38, 46. As shown in At block 72, the data travel times from the host system 10 to each of the local communication servers 38, 46 are determined. There are many ways to determine data travel times. Various exemplary techniques are described below.

IS 2 598 152 T3

As shown at block 74, the travel times can be examined to determine the longest travel time, referred to as the delta. The time the packet is sent from the host system 10 is determined (host_send_time ), as shown in block 76. Next, the time data 68 (shown in Figure 2) is determined. In one aspect, the time data 68 instructs the local communication servers 38, 46 to send the market data to the client devices 52, 54 at a predetermined time, time_to_release. As shown in block 78, the time, time_to_release, can be calculated as a time that is greater than or equal to the time_send_host + delta (as determined in block 74). A packet is formulated with the data from the host and the time data 68, time_to_release, as shown in block 80. The packet is then sent to the local communication server 38, 46, as shown in block 82. Alternatively, the data can be time-logged to the host and the packet can include the host_shipping_time. In this alternative aspect, the time_to_release is calculated at the local communication servers 38, 46.

Referring to Figure 4, a flow chart illustrates an example of steps of a device or program at the local communication server 38, 46 of one aspect of controlling the release of a packet at the client devices 52, 54. A packet with the time data is received by the local communication server, as shown in block 84. The server preferentially analyzes the packet for the time data (time_to_release). In one aspect, as shown in Figure 1, processors 40, 48 analyze the packet to determine timing data. In addition, the software can be accessed by the processor 40, 48 of the memory device 42, 50. Any other technique known to those skilled in the art for reading packet time data can be used as an alternative. The local communication server 38, 46 can then access the clock 36, 44 to compare the clock time with the time_to_release, as shown in block 86. 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 in block 88. If the clock time is not greater than or equal to time_to_release, the packet is placed in a queue, as shown in block 90. Packets are preferably sorted in the queue starting with the packet with the first time_to_release. As is known to those of ordinary skill in the art, the different operators (eg, greater than, less than, less than or equal to, etc.) are a function of how time is measured.

Referring to Figure 5, a flow chart illustrates an example of steps of a device or program in the local communication server of one aspect of controlling the sending of packets, which have been queued. The software views the first packet in the queue as shown in block 92. The local communication server can then access its clock to determine if the current time is greater than or equal to the time_to_release as shown in block 94. If so, then the packet is forwarded to the client device as shown in block 96. If it is not, the algorithm repeats, for example, returns to step 92. The software is preferably programmed to repeatedly check the first packet. in the queue every time a time interval has elapsed.

The flow charts shown in Figures 3, 4 and 5 provide only an example of one aspect and it should be understood that more or fewer stages can be used or that the stages can occur in one or more orders that are different from the order of stages. shown in Figures 3, 4 and 5, without departing from the spirit of the fair stock market invention. For example, instead of comparing the clock to the time_to_delivery before putting a packet in the queue (as shown in block 86 of Figure 4), the software could alternatively place all received packets immediately in a queue. and then follow the flow chart shown in Figure 5. There are many other alternatives that will become apparent to those skilled in the art upon review of this detailed description.

Using a concrete example, if the data travel time from host system 10 to local communication server 38 is 0.05 seconds and if data travel time from host system 10 to local communication server 46 is 0.15 seconds, the host system 10 may determine that, in order to present the data to the client devices 52, 54 simultaneously (or nearly simultaneously), the local communication servers 38,46 will send the data to the client devices 0.15 seconds after the host 10 sends the data. Specifically, if the data is sent from the host in t = 0 seconds, then the time_to_release = 0.15 seconds. In this way, the inequalities due to the differences in the data travel time will be reduced because the data packets are kept in the local communication servers 38, 46 to consider the network path that is slower. To ensure that data is sent from client servers almost simultaneously to time_to_release, local communication servers 38, 46 can access clocks (and preferably clocks that are synchronized with each other as described above) to compare the time of the release. clock with time_to_release and send the data to time_to_release.

Alternatively, instead of a time_to_release, local communication servers 38, 46 may be instructed to wait a certain time to wait before sending data to client devices. In the example used above, the host system 10 may instruct the local communication server 38 that the client devices 52 wait for a 0.10 second timeout and may instruct the local communication server 46 for the client device 54 to wait. a timeout of 0 seconds. This

In this way, wait times can reduce the disparity caused by differences in data travel times. Alternatively, the lead times or time_to_release can be adjusted to accommodate a period of time longer than the longest shipping time to provide more room for an error or computer processing time. For example, in the example above, the local communication servers 38, 46 can be programmed to send data to the client devices 0.20 seconds after the host sends the data.

Data sent from client devices to the host system

As described in the background section, an important issue in electronic stock market networks is the order of trading events / data sent from traders. Operators transmit the data, for example a purchase or sale or other transaction, from client devices, for example 52, 54, to the host system 10. In fairness, the data sent should be classified based, at least in part, on when the data is sent from the client device (or sent from a node near the client device). Inequalities can result if the electronic stock market queues the transaction based solely on when the transactions are actually received in the stock market (or host system).

In a preferred aspect, the fair stock market uses a system of synchronized clocks near, but not on, the client devices and the host of the stock market. In a preferred aspect, clocks 36, 44 are placed on local communication servers 38, 46 and clock 24 is placed on stock market host system 10. The transactions would then be recorded in time near the originator (client device) on the local communication servers 38, 46. If the location of the local communication servers 38, 46 is collected wisely, the use of this time stamp as the basis of prioritization in the host system 10 it will result in a fairer ordering of transactions in the host system of the stock market in a practical way. In the host system 10 or the matching engine 11, transactions are queued in the order of their timestamp, rather than the current arrival sequence preferred by the participant with the least latency to the central system or the system. of coincidence. To allow the slowest participant to have greater equality of opportunity, in a preferred aspect all transactions are held in the arrival queue until a transaction from the slowest participant can arrive. This leads to the problem of determining what the timeout should be, since slowing down transaction processing excessively can cause overall performance degradation. Therefore, it is important to have as low an arrival queue delay as possible. In particular, delays in processing transactions sent to the host system 10 should be kept to a minimum.

In a preferred aspect, clocks 36, 44 are placed on a network device geographically close to client devices, 52, 54, such as local communication servers 38, 46. In this way, when client devices send data to the system host 10 and data is routed through local communication servers 38, 46, local communication servers 38, 46 time-record the data using synchronized clocks 36, 44. The system 10 can then compare the timestamps of the data to approximate when the data is sent from the client devices 52, 54.

Referring to Figure 6, there is shown a flow chart of how data is sent from client devices 52, 54 to host system 10 and how data is prioritized in host system 10 in a preferred aspect of the fair stock market. Data is sent from client devices 52, 54 to host system 10, as shown in block 118. The data is received at a point in the network (such as, for example, local communication servers 38,46 of Figure 1) and the data is recorded in time, as shown in block 120. In the example of Figure 1, the processor 40, 48 can access the clocks 36, 44 to record the data in time. The data is then received by host system 10, as shown in block 122. The data is analyzed to determine whether the current time is greater than or equal to the time stamp plus the longest previously determined drive time (hereinafter delta) as shown in block 124. This time may be referred to as time_to_release. Alternatively, the local communication servers 38, 46 can calculate the time_to_release and store that value in the data packet being sent.

Host system 10 preferably accesses clock 24 to obtain the current time. If the answer is yes, the data (which in this example represents an order or operation) is transmitted to the central matching engine 11, as shown in block 126. If the answer is no, the data is queued, as shown in block 128. The data is preferably sorted in a queue based on the timestamps, from the earliest timestamp to the last.

Referring to Figure 7, a flow chart of how the host system 10 can manage the inbound transaction queue is shown, referenced in step 128 of Figure 6, in a preferred aspect. The method looks for the first packet in the queue as shown in block 130. The host system 10 can then access its clock to determine if the current time is greater than or equal to the time_to_release, as shown in block 132. If the answer is yes, the transaction is sent to the matching engine as shown in block 134. If no, the method returns to step 130. The method is preferably programmed to repeatedly check the first packet in the queue every once a preset time interval has elapsed.

IS 2 598 152 T3

The flow charts shown in Figures 6 and 7 provide only an example of one aspect and it should be understood that more or fewer stages may be used or that the stages may occur in one or more different order of the order of stages shown. in Figures 6 and 7. For example, instead of comparing the clock with the time_to_release before putting a packet on the queue (as shown in block 124 of Figure 6), the method can alternatively place all received data immediately in a queue and then , follow the flow chart shown in Figure 7. There are many other alternatives that will become apparent to those skilled in the art upon review of this detailed description.

Determine travel times

There are various techniques known to those of ordinary skill in the art for determining the travel time between two devices on a network. The present invention is not limited to any particular technique. In one aspect, the travel time is controlled by using packets containing time records from the originating node which are then compared to the clock time at the arrival node to determine the slowest end node. In this regard, a packet is sent from the central communication servers 18, 26 to the local communication servers 38, 46 including a time stamp provided by the clock 24. The local communication servers 38, 46 can determine the time of travel of that packet by calculating the difference between the time stamp and the time the packet is received at the local communication server 38, 46 by accessing the clocks 36, 44. The local communication servers 38, 46 can communicate the calculated travel time to the host 10. After receiving the travel times from the various local communication servers, the host can then determine the slowest travel time by comparing of the different travel times. This slower travel time can then be used as the longest delivery time (delta) as described above.

In an alternative aspect, travel times can be measured using a ping approach. This technique consists of the central communication servers 18, 26 pinging the local communication servers 38, 46. The central communication servers 18, 26 keep track of the time a ping 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 the local communication servers ping, the host can determine the slowest round trip time. The longest travel time (delta) can be calculated as the slowest round trip time divided by two.

Regardless of the technique used, the system can periodically determine and adjust the longest travel time. These measurement techniques can be performed automatically or activated manually. In the case of network problems, the travel time could be excessively high for a node causing significant slowdown of all market participants. To overcome this problem, an administrative delta can be enforced based, for example, on network knowledge, such as the average delay of all participants, or based on a select number of pings.

Alternatively, other measures can be used. For example, the longest ride time can be set anywhere that levels the playing field to some extent, while still encouraging market share.

The components used to measure delays or assign time stamps are preferably under the control of the host system or some trusted third party. This minimizes the risk of someone biasing the measurements, for example by modifying packages that are designed to measure travel times. Therefore, local communication servers 38, 46, which are preferably under the control of the host system, are better suited for measuring travel times or assigning time stamps compared to client devices 52, 54. When it is necessary to measure delays or assign time stamps on a device that is not under the control of the stock market or a trusted entity, one should carefully monitor the system when using any method to determine the delay of the local line.

Due to the large differences in data travel times that occur between the central communication servers 18,26 and the local communication servers 38, 46 (due, for example, to transcontinental lines, frame retransmission, etc.) The greatest benefit in reducing time differences comes from the synchronization of the local communication servers 38, 46 with the central communication servers 18, 26. Therefore, from a practical point of view, the use of local communication servers 38, 46 to measure delays and allocate time records reduces the largest inequalities in the system.

In an alternative aspect, synchronized clocks can be placed on or connected to devices on the network path farthest (eg, geographically or based on the network path) from client devices. For example, instead of placing clocks on local communication servers 38, 46, devices such as access servers, routers, gateways, or the like within networks 32, 34 can be modified to include or work with synchronized clocks. Similar to local communication servers 38, 46, that device can delay the transmission of data to client devices until a predetermined time.

ES 2 598 152 T3 or you can delay the release for a predetermined time. In the same way, these network devices can record in time the data sent from the client devices 52, 54 to the host system 10.

In one embodiment, to achieve simultaneous or near-simultaneous display of data on client devices, the operation of host system 10 can be modified to send data to client devices 52, 54 through local communication servers 38, 46 to different moments. In determining how to modify the operation of the host system 10, at least a portion of the travel times of the data from the host system 10 to each of the client devices 52, 54 can be determined. For example, the round trip time (from host system 10 to local communication servers 38, 46 back to host system 10) can be determined. Alternatively, the travel time from host system 10 to local communication servers 38, 46 can be determined. As described above, there are a multitude of methods for determining data travel time.

Based on the travel times, the host system 10 can send data to each of the client devices 52, 54 through the local communication servers 38, 46 at different times. In this way, the sending of data from the host system 10 to the client devices 52, 54 is staggered based on the data travel times in the parts of the network where a travel time disparity is most likely and based on in measurements that are more reliable because the components being measured can be more reliably controlled. Based on this staggered sending, data must be received by client devices 52, 54 at, or near the same time. Referring to Figure 1, at least one component in host system 10 can be modified. For example, either the central order book 12 of the stock market host or the central communication servers 18, 26 can be modified to stagger the sending of the data. Specifically, processor 14 in central command book 12 can access memory 16 to access software for staging the sending of data. Alternatively, the processor 20, 28 in the central communication servers 18, 26 can access the memory 22, 30 to access the software for staging the sending of data.

Referring to Figure 8, a flow chart of a host system sending data to client devices at different times is shown. The flow chart can be implemented by processor 14 through software in memory 16 (as shown in Figure 1). At block 98, the data travel times from the host system to each of the local communication servers are determined. The local communication servers can then be arranged in a look-up table in the order of longest to shortest travel time, as shown in block 100. The look-up table may be contained in a memory device 16 (Figure 1). A pointer is placed on the local communication server with the longest travel time, as shown in block 102. The time is set to zero, as shown in block 104. The data is then sent to the local communication server with the longest travel time, as shown in block 106. The flowchart then loops, with the pointer incrementing to the next local communication server in the table. query, as shown in block 108. The difference (dt) in travel time is then determined, between the local communication server at the pointer and the previous local communication server, as shown in block 110. The system then waits for the difference (dt), as shown in block 112. The data is then sent to the local communication server at the pointer, as shown in block 114. The loop runs until the pointer points to the last local communication server in the lookup table, as shown in block 116.

In the specific example used above (with the travel time difference equal to 0.1 seconds), the host system 10 can stagger the sending of data (sending data first to the client devices 54 through the communication server local 46, wait a predetermined time, and then send the data to client devices 52 through local communication server 38). In the present example, the host system 10 may first send the data to the local communication server 46 (and, therefore, to the client devices 54), wait 1 second (based on the difference in travel times), and then sending the data to the local communication server 38 (and therefore to the client devices 52). Thus, the client devices 52 and the client devices 54 should receive the data at approximately the same time. The central stock market system preferably includes or has access to a clock 24, so that the host system 10 can wait the predetermined necessary time.

In another alternative aspect, the operation of the host system 10 can be modified to prioritize transactions based on the time data received by the host 10 and based on the different travel times of the local communication servers 38, 46. In In one aspect, the data travel times from each of the local communication servers 38, 46 to the host system 10 can be determined. In this way, when data is received in the host system 10, it can be recorded in time. The system 10 can then determine when the data is sent from the local communication servers 38, 46 based on the time stamp and travel times.

Specifically, this alternative is based on an arrival queue with time-based ordering. The main difference is that this system can impose delays in a penalty system based on the times of

ES 2 598 152 T3 average distance measured. If a connection were very fast, the delay Tax would be greater than for a slower connection.

Referring to Figure 9, a flow chart of the operation of the host system 10 in this alternate aspect is shown in which the data is ordered based on the time when the local communication servers 38; 46 send the data. The data travel time from each of the local communication servers 38, 46 to the host system 10 is determined, as shown in block 136. The travel time can be determined by processor 14, as shown in Figure 1, and stored in a look-up table in memory device 16. Host system 10 then receives data from client devices to via local communication servers 38, 46, as shown in block 138. Data is recorded in time after being received by host system 10, as shown in block 140. The packets can be recorded in time by evaluating the clock 24, as shown in Figure 1. The host system 10 can then calculate the approximate time that the packets have been sent from the local communication servers 38, 46, by subtracting the travel time (determined in block 136) from the time register of the data t, as shown in block 142. The data is then sorted, based on the calculated time, from earliest to latest, as shown in block 144. For example, processor 14, in Figure 1, can determine the calculated time by accessing the time of traversing the look-up table in the memory device 16 and sorting the data based on the calculated time. In this way, the data is not sorted immediately after being received by the host system 10. Rather, the data can be held temporarily for a predetermined period of time (delay).

The delay can be determined in a variety of ways. The delay can be the longest data travel time 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 can be based on the difference between the longest data travel time of any local communication server on the host system and the data travel time from the local communication server specific to the host system, as follows:

tmax: maximum network delay (round trip time) tn: network delay for participant n (round trip) delay = tmax / 2 - tn / 2

This delay calculation could alternatively be based on round trip times measured as described above. In either case, the travel times are preferably averaged over a number of samples. In yet another alternative aspect, the delay can be preselected.

Using a concrete example, if the travel time from the local communication server 38 and the local communication server 46 to the host device is 0.05 and 0.15, respectively, and the time registration data from a local communication server 38 and local communication server 46 are 0.3 and 0.35, respectively, the host system 10 can determine which data was sent first. In this example, calculating the time that the data is sent from each local communication server is as follows:

time stamp - travel time = time data sent from local communication server

In the present example, for the first local communication server 38, the time the data is sent is 0.25 (0.3-0.05). For the local communication server 46, the time that the data is sent is 0.2 (0.35 0.15). Therefore, the host device can determine that the data has actually been sent for the first time from the second local communication server 46 instead of from the first local communication server 38, even though the data from the first communication server local 38 were first received by the host. Therefore, the data from the first local communication server 38 is not processed at the time it is received by the host system device 10 (in the example, 0.3); rather, the data can be retained for a predetermined period until it is processed. For example, data can be held for 0.15 seconds, based on the longest time data traveled from any local communication server to the host device. Alternatively, the data can be held for 0.1 second, based on the difference of the longest drive time (0.15 seconds) and the drive time for the data (0.05 seconds).

By using the apparatus and methods described above, trading an electronic stock market may be more fair to those who participate. Data sent from a host system to client devices can be displayed simultaneously or almost simultaneously. Similarly, the electronic stock market can order data sent from client devices based, at least in part, on when the client device sends the data or an approximation thereof. Therefore, electronic stock market trading can be more equitable.

The preferred embodiments and aspects of the present invention have been described herein. It is of course to be understood that changes and modifications can be made to the embodiments without departing from the

ES 2 598 152 T3 true scope of the present invention, as defined by the appended claims. The present embodiment preferably includes logic for implementing the methods described in the software modules as a set of computer-executable software instructions. A processor implements the logic that controls the operation of at least one of the devices in the system, including the host system 10, one, some, or all of the network devices, and / or the client devices. The processor runs software that can be programmed by those skilled in the art to provide the described functionality.

The software can be represented as a sequence of binary bits held on a computer-readable medium described above, for example, as memory devices 16, 22, 30, 42, 50 in Figure 1. The computer-readable medium can include disks Magnets, optical discs, and any other volatile (eg, random access memory (RAM)), non-volatile (eg, read-only memory (ROM)) storage system readable by the processor. The memory locations where the data bits are held 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 representation of the electrical signal, and the maintenance of the data bits in memory locations in the memory system to reconfigure this manner or otherwise alter the operation of the unit. Executable software code can implement, for example, the methods as described above.

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

It should further be understood that a hardware embodiment could take a variety of different forms. The hardware can be implemented as an integrated circuit with custom gate arrays or as an application specific integrated circuit (ASIC). The embodiment can also be implemented with hardware components and discrete circuits. In particular, it is understood that the logical structures and procedural steps described in the flowcharts can be implemented in dedicated hardware, such as an ASIC, or as program instructions carried out by a microprocessor or other computing device.

The claims should not be construed as limited to the described order of elements unless indicated to that effect. Therefore, all embodiments are within the scope of the invention as defined by the following claims.