Tailored messaging

References to related applications

No. 14/329,602 entitled "Coordinated Messaging," filed on July 11, 2014; U.S. Provisional Patent Application No. 61/845,613 entitled ``Systems and Methods for Dynamically Distributing Market Data Across Multiple Devices in an Electronic Trading Environment,'' filed on July 10, 2014; Claims priority to U.S. Provisional Patent Application No. 62/022,736 entitled ``Systems and Methods for Dynamically Delivering''. The entire contents of each of these US applications are incorporated herein by reference for all purposes.

TECHNICAL FIELD This disclosure relates to coordinated messaging.

Electronic devices exchange data messages, for example, to provide up-to-date information regarding the status of the devices. In some systems, multiple recipients desire to receive updates from the data source. Techniques such as broadcast or multicast messaging are used by data sources to provide these updates over certain types of networks. In other systems, recipients use point-to-point connections to communicate with data sources, e.g. due to network constraints, communication preferences (e.g., reliability of delivery, ordering), and/or security requirements. .

Some recipients wish to receive updates from the same data source at different rates. Providing updates at different rates while minimizing the transmission of unwanted messages to recipients limits the usefulness of broadcast or multicast messaging techniques, and also allows receivers with different update rate preferences. As the number of users increases, point-to-point connections become more effective. However, point-to-point connections require a message to be generated for each recipient. Additionally, some recipients desire to receive different levels or hierarchies of data in their updates. When customizing messages based on different levels or hierarchies of data, a different message needs to be generated for each level or hierarchy. As the number of recipients with different preferences grows, accommodating different update rates as well as different levels or tiers becomes cumbersome, especially for time-sensitive information where increased latency in receiving data is unacceptable. becomes.

Embodiments are disclosed with reference to the following drawings.

<figref num="1">Block diagram of an exemplary computing device capable of implementing certain embodiments</figref><figref num="2">Block diagram of an example system for transmitting tailored messages to one or more receiving devices</figref><figref num="3">2 is a block diagram of an example subscription control module used to send snapshots and delta snaps to one or more receiving devices; FIG.</figref><figref num="4">Data flow diagram showing an example of using snapshot technology</figref><figref num="5">Data flow diagram showing an example of using the delta technique</figref><figref num="6">Data flow diagram showing an example of using the delta snap technique</figref><figref num="7A">Block diagram showing example data levels</figref><figref num="7B">Block diagram showing example data levels</figref><figref num="8A">Block diagram illustrating an example of tailored messages based on snapshots and delta snaps</figref><figref num="8B">Block diagram illustrating an example of tailored messages based on snapshots and delta snaps</figref><figref num="9">Dataflow diagram showing an example of using the adjusted delta snap technique</figref><figref num="10">Diagram showing an example of tunable messages in a buffer</figref><figref num="11">Data flow diagram showing the connection between the receiving device and the subscription control module</figref><figref num="12">Flow diagram of a method representing executable machine-readable instructions to implement the subscription control module of Figures 2 and 3</figref><figref num="13">A flow diagram of a method representing executable machine-readable instructions to implement the data formatting portion of Figure 3.</figref><figref num="14">A flow diagram of a method representing executable machine-readable instructions to implement the data formatting portion of Figure 3.</figref><figref num="15">Flow diagram of a method representing executable machine-readable instructions to implement the message sender of Figure 3</figref><figref num="16">Flow diagram of a method representing executable machine-readable instructions to implement the message sender of Figure 3</figref><figref num="17">Flow diagram of a method representing executable machine-readable instructions to implement the message sender of Figure 3</figref><figref num="18">Block diagram of an electronic trading system in which embodiments can be adopted</figref><figref num="19">Block diagram of an electronic trading system in which embodiments can be adopted</figref><figref num="20A">Diagram showing an example of tunable messages for snapshots and delta snaps to provide market data at a large number of data levels in market depth</figref><figref num="20B">Diagram showing an example of tunable messages for snapshots and delta snaps to provide market data at a large number of data levels in market depth</figref>

Certain embodiments are better understood when read in conjunction with the drawings, which are provided by way of example. However, it is to be understood that the embodiments are not limited to the arrangements and instrumentalities shown in the accompanying drawings.

TECHNICAL FIELD The disclosed embodiments generally relate to techniques for coordinating messages for network communications. More specifically, embodiments of the disclosure relate to systems and methods that efficiently provide customized information updates based on recipient preferences. The recipient may, for example, wish to receive updates less frequently than the system generates updates, and/or may wish to receive different data levels within the updates. Some embodiments provide a delta snap technique that allows for more efficient adjustment of the rate at which update messages are provided. Some embodiments provide segmentation techniques that allow for more efficient coordination of update message content. In some embodiments, a delta snap technique is provided in combination with a partitioning technique that allows for more efficient adjustment of the rate and content of update messages.

Data messages provide information to recipients in a variety of situations. Some recipients wish to receive updates at a different rate than other recipients. The first recipient may e.g. be at a first rate (which may be the rate at which updates are generated), such as a rate up to once every 1 millisecond. The second recipient would like to send updates at a lower rate, such as twice every second, due to bandwidth constraints. The third recipient, due to bandwidth constraints, wants to ensure that it receives updates at whatever rate it can without receiving stale data or experiencing large gaps due to connection resets. Additionally, in some systems, data sources provide different levels or hierarchies of data within an update. For example, each successive level includes values indicating more detail or additional information beyond the detail provided in the previous level. Some recipients wish to receive different numbers of data levels within an update from a data source. For example, a first recipient wishes to receive updates regarding the values of the first five levels. The second recipient wishes to receive updates of the values of the first two levels. Messages are tailored according to recipient preferences to provide different levels of data. Current systems require unique message formatting based on the source data for each recipient to accommodate recipient preferences such as different update rates and/or different numbers of data levels.

Although the detailed description discloses embodiments that include software running on hardware, among other components, these embodiments are illustrative only and should not be construed as limiting. For example, any or all of these hardware and software components may be exclusively hardware, software, firmware, or hardware, software, and/or firmware. It may be implemented in any combination. Accordingly, embodiments may be practiced or implemented in other ways.

I. BRIEF DESCRIPTION OF EMBODIMENTS Example methods, systems, and computer-readable media for coordinating messages for network communications are disclosed. An example method for coordinating messages includes generating, by a computing device, a first snapshot message representing a state of a data source at a first point in time. A first snapshot message is sent to a first recipient. The example method includes: generating, by the computing device, a first deltasnap message representing a difference between a state of the data source at a first time and a state of the data source at a second time; and transmitting, by the computing device, a first delta snap message to the first receiver.

The example method includes generating, by a computing device, a first snapshot representing a first set of data acquired at a first time. The method further includes transmitting, by the computing device, the first version of the first snapshot to the first participating device. wherein the first version is adjusted based on a first preference of the first participating device. The method further includes generating, by the computing device, a first delta snap representing a difference between the first set and the second set of data. Here, the second set represents data generated at a second time after the first time. The method further includes transmitting, by the computing device, the first version of the first delta snap to the first participating device. wherein the first version is adjusted based on a first preference of the first participating device.

An exemplary computer-readable storage medium has instructions that, when executed, cause a machine to perform at least the following steps. Specifically, the method includes generating a first snapshot message representing a state of the data source at a first point in time. Further included is the step of sending the first snapshot message to the first recipient. Further included is the step of generating a first delta snap message representing a difference between a state of the data source at a first time and a state of the data source at a second time. Further included is the step of transmitting a first delta snap message to the first receiver.

II. Exemplary Computing Device FIG. 1 depicts a block diagram of an exemplary computing device 100 that can be used to implement certain embodiments. Computing device 100 includes a communication network 110, a processor 112, a memory 114, an interface 116, an input device 118, and an output device 120. Computing device 100 may include additional, different, or fewer components. For example, multiple communication networks, multiple processors, multiple memories, multiple interfaces, multiple input devices, multiple output devices, or any combination thereof may be provided. As another example, computing device 100 may not include input device 118 or output device 120.

As shown in FIG. 1, computing device 100 includes a processor 112 connected to a communications network 110. Communication network 110 may include a communication bus, channel, electrical or optical network, circuit, switch, fabric, or other mechanism for communicating data between components within computing device 100. Communication network 110 is coupled to enable communication and transfer of data between any components within computing device 100.

Processor 112 may be any suitable processor, processing unit, or microprocessor. Processor 112 includes, for example, one or more general purpose processors, digital signal processors, application specific integrated circuits, field programmable gate arrays, analog circuits, digital circuits, programmed processors, and/or combinations thereof. It will be done. Processor 112 may be a single device or a combination of devices, such as one or more devices associated with a network or distributed processing. Optional processing strategies may include multiprocessing, multitasking, parallel processing, and/or remote processing. Processing may be local or remote, and may move from one processor to another. In some embodiments, computing device 100 is a multi-processor system and may include one or more additional processors communicatively coupled to communication network 110.

Processor 112 may be operable to execute logic or other computer readable instructions encoded in one or more tangible media, such as memory 114. As used herein, logic encoded on one or more tangible media includes instructions executable by processor 112 or a different processor. The logic may be stored as part of software, hardware, integrated circuits, firmware, and/or microcode, for example. Logic may be received from an external communication device via a communication network, such as network 140. Processor 112 may execute logic to implement the functions, acts, or tasks illustrated in the figures or described herein.

Memory 114 may be one or more tangible media, such as, for example, a computer readable storage medium. Computer-readable storage media may include, for example, random access memory, read-only memory, programmable read-only memory, electrically programmable read-only memory, electrically erasable read-only memory, flash memory, any combination thereof, or the like. Various types of volatile and non-volatile storage media may be included, including any tangible data storage device. As used herein, non-transitory or tangible computer-readable medium is expressly defined to include any type of computer-readable medium but excludes propagated signals. Memory 114 includes any desired type of mass storage device, including hard disk drives, optical media, magnetic tape or disks, and the like.

Memory 114 may include one or more memory devices. For example, memory 114 may include local memory, mass storage devices, volatile memory, non-volatile memory, or combinations thereof. Memory 114 may be located proximate to, provided as part of, programmed into, networked with, and/or remote from remote processor 112; Data stored in 114 may be read and processed by processor 112, for example. Memory 114 may store instructions executable by processor 112. The instructions may be executed to perform one or more of the acts or functions described herein or illustrated in the figures.

Memory 114 may store applications 130 for performing the disclosed techniques. In some embodiments, applications 130 are accessible from or stored in different locations. Processor 112 may access application 130 stored in memory 114 to execute computer readable instructions contained in application 130.

In some embodiments, applications may be transferred from input device 118 and/or network 140 to memory 114 during the installation process. When computing device 100 is executing or preparing to execute trading application 130 , processor 112 may read instructions from memory 114 via communication network 130 .

III. Subscription Control Module FIG. 2 shows an example system 200 that includes a subscription control module 201 and a data source 202. III. In the illustrated example, data source 202 provides data to subscription control module 201. Subscription control module 201 receives data, e.g., as sent by data source 202, periodically (e.g., at configured time intervals), when updates are detected, and/or in response to trigger events. and/or otherwise obtain. Subscription control module 201 converts the data into tailored messages. The tailored message 204 is sent to one or more receiving devices 206 (e.g., a smartphone) via a communication link (e.g., point-to-point connection, unicast channel, Transmission Control Protocol (TCP) socket, WebSocket connection, etc.). , tablet, server, personal computer, etc.). One or more preferences are defined for the receiving device (eg, update rate, number of data levels, etc.). In some cases, electronic device 206 communicates preferences to subscription control module 201. For example, for subscription control module 201 that generates updates every 100 milliseconds, receiver 206 sets a preference to receive updates only as frequently as every 500 milliseconds. In some cases, preferences for electronic device 206 are determined by subscription control module 201. For example, the subscription control module 201 may set the update rate to only 3 data levels per second based on the latency during connection processing with the electronic device 206. In some cases, subscription control module 201 adjusts the update rate based on the throughput of the network link. For example, if a previous update is still being sent, the subscription control module 201 delays sending the next update. In such an example, if a more recent update occurred during the delay, the subscription control module 201 may send the more recent update instead. Subscription control module 201 provides wired and/or wireless connections (e.g., cable/DSL/satellite connections, cellular connections, Long Term Evolution (LTE) connections, etc.) through networks (e.g., the Internet, wide area networks, etc.). It communicates with the receiving unit 206 via.

FIG. 3 is a diagram illustrating an example of the subscription control module 201 of FIG. 2. Subscription control module 201 receives and/or otherwise obtains data from data source 202 and sends a tailored message (e.g., tailored message 204 shown in FIG. 2) to one or more electronic devices 206. do. The subscription control module 201 in the illustrated example includes a data source receiving section 302, a data formatting section 304, a primary buffer 306, a secondary buffer 308, and a message transmitting section 310. Data source receiver 302 receives and/or otherwise obtains data from data source 202.

In the example shown in Figure 3, data source 202 updates dynamically (e.g., asynchronously as new information becomes available, or periodically in response to a period of inactivity). . To receive and process data and send messages to receiver 204, data source receiver 302 determines the state of data source 202 (e.g., via data source receiver 302 of FIG. 3) at discrete points in time. Get it with. In some cases, data source receiver 302 obtains the state of data source 202 when data source 202 provides updates about changes in its state. In some cases, the data source receiver 302 obtains the status of the data source 202 at set time intervals (eg, if the data source updates frequently). For example, the data source receiving unit 302 obtains the status of the data source 202 every 100 milliseconds. In some cases, data source receiver 302 obtains the state of data source 202 in response to detecting an update (eg, if the data source updates sporadically). Data source receiver 302 can establish a base update rate. The base update rate is the rate at which subscription control module 201 produces updates available to receiving devices 206. In some cases, a base update rate is established periodically (eg, when data source 202 updates frequently). In some cases, the base update rate is established at irregular intervals (eg, when data source 202 is updated infrequently). In some cases, the base update rate changes depending on the frequency of changes in data source 202.

In the example of FIG. 3, data formatting unit 304 formats (eg, organizes, translates, standardizes, systematizes) data from data source 202. Data formatter 304 converts the data into tailored messages for storage in primary buffer 306 and/or secondary buffer 308. The primary buffer 306 and/or the secondary buffer 308 store data formatted by the data formatter 304. In some cases, data stored in primary buffer 306 and/or secondary buffer 308 is accessed by data formatter 304 and compared with subsequent data from data source 202. Primary buffer 306 includes, for example, adjustable snapshot messages. The data formatter 304 then sends the data to the secondary buffer 308 by comparing the data from the data receiver 302 with the adjustable snapshot message in the primary buffer 306 using techniques described in more detail below. Adjustable delta snap messages can be generated.

In the illustrated example, message transmitter 310 manages connections with one or more recipient electronic devices 206. Message transmitter 310 uses the tailored messages stored in primary buffer 306 and/or secondary buffer 308 to transmit data as tailored message 204 to recipient electronic device 206. In some cases, message transmitter 310 receives preferences from recipient electronic device 206. Preferences include, for example, preferences regarding update rate and/or preferences regarding number of levels of data. In such examples, message transmitter 310 is configured to transmit adjustable messages stored in primary buffer 306 and/or secondary buffer 308 to receiver electronic device 206 based on the received preferences. Adjust to. To adjust the adjustable message, message transmitter 310 calculates which portion (eg, in bytes) of the adjustable message to send based on the received preferences. For example, if the adjustable message is 100 bytes, message transmitter 310 calculates to send only the first 56 bytes to recipient electronic device 206 based on the received preferences. This method eliminates the need to retranslate the message for each receiver. The data formatting unit 304 formats the adjustable message so that it can be transmitted in an abbreviated form. In some cases, message transmitter 310 delays or discards messages to device 206 when message transmitter 310 detects that the connection with recipient electronic device 206 is congested.

IV. Current Techniques for Communicating Data Source Updates Current techniques for updating changes in the state of data sources include snapshots and deltas, for which exemplary techniques are further described below. .

A. Snapshot Technology A snapshot represents the state of a data source at a particular point in time. Snapshots can be used to communicate updates to receiving devices. Exemplary snapshot techniques communicate the state of a data source by sending snapshot messages for each update to one or more receiving devices. Since the snapshot technology transmits the entire state of the data source at a specific point in time to the receiving unit, the state of the data source at time t can be determined as shown in equation (1) below.

Equation (1): Current state (t)=StSt represents the snapshot sent most recently at time t.

Figure 4 shows how discrete time (e.g., time T₀, time T₁, time T₂) is a data flow illustrating an example of the use of snapshot technology including a first state 400a, a second state 400b, and a third state 400c for a data source. In the example of Figure 4, the first state 400a is at time T₀is obtained in The first state 400a is snapshot S₀formatted and stored in a buffer. Snapshot S₀is transmitted to the receiving section. Time T₁, a second state 400b is captured and a snapshot S₁formatted and sent to the receiving unit. Time T₂At , data 400c is acquired and snapshot S₂formatted and sent to the receiving unit.

Snapshots contain all the data needed to know the current state of a data source, so the impact of missing a snapshot can be reduced or minimized (e.g. by waiting for the next update). can. However, since the data from the data source changes only slightly between intervals, sending snapshots may unnecessarily use valuable data bandwidth. As a result, receivers that receive messages from frequently updating data sources, or receivers that receive messages from many different data sources, and/or receivers that have limited bandwidth (e.g., cellular network (e.g., mobile devices using the connection), message congestion and/or loss may occur.

B. Delta Technology Delta represents the difference between the most recent state and the current state of a data source. The most recent state is the latest snapshot adjusted by all intervening deltas. Delta technology uses periodic snapshots separated by one or more deltas to communicate updates to receiving devices. Exemplary delta techniques provide data processing by sending snapshots to the receiver periodically (e.g., at set time intervals) and/or aperiodically (e.g., after a certain number of updates). Communicate source status. Between snapshots, deltas are sent to the receiver periodically and/or aperiodically. Therefore, the current state of the data source at time t can be determined as shown in equation (2) below.

Equation (2): Current state (t)=S_R+Δ₁+Δ₂+...+Δ_tS_Ris the snapshot sent most recently at time t, and Δ₁-Δ_tis the delta sent since the most recent snapshot.

Figure 5 shows time T₀, time T₁, time T₂2 is a data flow illustrating an example delta technique including a first state 400a, a second state 400b, and a third state 400c for a data source 202 in FIG. In the example in Figure 5, time T₀, a first state 400a is captured and a snapshot S₀formatted and sent to the receiving unit. Time T₁At , a second state 400b is obtained and compared with the first state 400a. delta Δ₁is generated based on the "difference", for example. delta Δ₁is then transmitted to the receiver. Time T₂In , a third state 400c is obtained and compared with the second state 400b, and based on the difference delta Δ₂generate. delta Δ₂is then transmitted to the receiver. In the example shown in Figure 4, delta (e.g., deltaΔ₁and delta Δ₂) is an instruction 500 (for example, add (A), change (C), delete (R)), an index 502 that indicates which part of the data is to be changed, and a value that indicates how the data is to be changed. 504 (for example, value 1, value 2). For example, delta instructs the receiver to change (C) the value at index 1 (value 1, value 2) by (0, -50). In some cases, snapshots (e.g. snapshot S₀) is flagged as a snapshot and does not contain instruction 500.

According to the delta technique, only changed portions of updates are communicated to the receiver between snapshots, thereby reducing bandwidth usage. However, because deltas only communicate a portion of updates, if deltas are not received in a timely manner (e.g., due to congestion, connection interruptions, message loss, etc.), the data at the receiving end may be corrupted. Otherwise, the receiver needs to wait until a new snapshot is sent. This requires that all subsequent deltas received so far be ignored.

V. Delta Snap Technique and Message Rate Adjustment Certain embodiments use a technique referred to herein as a delta snap technique to change the state of a data source (e.g., data source 202) to one or more receiver devices. (eg, one or more electronic devices 206). Delta snap technology can utilize bandwidth more effectively compared to snapshot technology and also provides higher resiliency to data loss compared to delta technology. Additionally, delta snap technology reduces redundant data sent using snapshot technology alone, and reduces the complexity and storage required by delta technology while providing efficient message rates and throttling levels. provide a number.

The delta snap includes the current state of the data source that is sent to the receiver (e.g., receiver 206 in FIGS. 2 and 3) and the data source that is to be included in the update (e.g., the data source in FIGS. 2 and 3). 202) and the current state. An exemplary delta snap technique involves sending snapshots to a receiver periodically and/or non-periodically (e.g., at set time intervals, after a certain number of updates, with a trigger condition). , communicate the state of the data source. The snapshot is sent to all receivers. Furthermore, the latest snapshot is sent in response to a new connection. Preferably, snapshots are transmitted using a communication technology that ensures reliable delivery of snapshots. Snapshots can be generated, for example, in a manner similar to the snapshot techniques described above. Additionally, one or more delta snaps are typically generated between snapshots. Delta snaps may be generated at a base update rate (e.g., at the rate at which data source 202 provides updates to subscription control module 201 of FIGS. (by update rate preference). In some cases, receiving device 206 may subscribe to receive delta snaps at a less frequent update rate than the base update rate. For example, if the base update rate of subscription control module 201 is 25 ms, the receiver may desire to receive delta snaps every 100 ms (i.e., at or below the base update rate). every 4th delta snap if updates occur at a fast rate). Delta snaps are generated in a manner similar to deltas in the delta technique described above, except that delta snaps are performed with respect to the most recently sent snapshot, but not with respect to the state represented by the most recently sent delta. can do. When a delta snap is being generated, the display of the delta snap can be larger than its equivalent snapshot, depending on the extent of the changes since the previous snapshot. In such a situation, in some embodiments, the generation of the delta snap is discarded and a new snapshot is generated and sent instead. Using the delta snap technique, the state of the data source 202 at time t can be determined as shown in equation (3) below.

Equation (3): Current state (t)=S_R+ΔS_tS_Ris the most recently sent snapshot at time t, and ΔS_tis the delta snap sent most recently at time t.

Figure 6 shows time T₀, time T₁, time T₂2 is a data flow illustrating an example delta technique including a first state 400a, a second state 400b, and a third state 400c for a data source 202 in FIG. In the example shown in FIG. 6, the first state 400a is obtained by the data source receiver 302 (FIG. 3) and the snapshot S₀and placed in the primary buffer 306 (FIG. 3). The message transmitter 310 (Fig. 3) sends the snapshot S₀is transmitted to the receiving unit 206 (FIG. 3). Time T₁, the second state 400b is obtained by the data source receiving unit 302. In the illustrated example, the data formatter 304 stores the snapshot S in the primary buffer 306.₀is compared with the second state 400b. Based on the difference, the data format unit 304 creates a delta snap ΔS₁generate. Delta snap ΔS₁is stored in secondary buffer 310 (FIG. 3). Delta snap ΔS₁is then transmitted by message transmitter 310 to receiver 206 according to the respective receiver's update rate preference.

As shown in the example in Figure 6, time T₂, the data source receiving unit 302 obtains the third state 400c of the data source 202. The data format unit 304 stores the snapshot S stored in the primary buffer 306.₀and the third state 400c, and based on that difference the delta snap ΔS₂generate. Delta snap ΔS₂is stored in secondary buffer 308. Delta snap ΔS₂is then transmitted by message transmitter 310 to receiver 206 according to the respective receiver's update rate preference. In the example shown in Figure 6, the delta snap ΔS₁, ΔS₂is generated with an action 600, an indication 602 of which part of the data is affected, and/or a change in value 604 (eg, value 1, value 2).

Because a delta snap contains information about one or more updates to data in data source 202 that have occurred since the last snapshot, the delta snap technique allows for different update rate preferences at a number of base update rates. It becomes possible to send updates to the receiving unit 206 that has the following information. For example, if snapshots are generated every 2 minutes and delta snaps are generated every second between snapshots, the first receiver sets a preference to receive delta snaps every 5 seconds, and the second The receiver may set a preference to receive delta snaps every 10 seconds. Each snapshot is sent to all receivers. Once the delta snap is generated, it is sent to the receiver according to the set preferences. In this way, not all delta snaps are sent to each receiver. Since delta snaps represent changes with respect to the most recently sent snapshot, a particular receiver does not need to receive all delta snaps to determine the latest updates to a data source.

Because delta snaps contain some of the information about updates to data source 202, delta snap techniques generally require less bandwidth than snapshot techniques.

In some cases, delta snap technology requires more bandwidth than delta technology. For example, if a data source 202 is modified and then not modified for some time, the delta snap will include the repeating changes, but the delta will not include the changes. However, using the delta snap technology, subscribing to data sources and recovering from lost messages is easier to manage compared to the delta technology. For example, the receiving device 206 uses delta snap technology to connect to the snapshot-to-snapshot subscription control module 201 and become updated by receiving the latest snapshot and the latest delta snap.

VI. Dividable Data Level Techniques and Data Level Coordination (i.e., Assembling) Certain embodiments use techniques referred to herein as divisible data level techniques to adjust the state of data source 202 to one or more states. provides an improved communication technique for communicating with a receiving device 206. Dividable data levels refer to organizing data within an update into levels or hierarchies. In the example shown in Figures 7A and 7B, data 700 received from a data source (data source 202 in Figures 2 and 3) is organized into data levels 702a-702f by a data formatter (data formatter 304 in Figure 3). ing. In some cases, data levels 702a-702f are organized in order of importance (e.g., first level 702a containing the most requested data, second level 702b containing the second most requested data). . Additionally or alternatively, each data level 702a-702f represents a level of detail of information. Data levels 702a-702f can be split down from data level 702 (e.g., first data level 702a is used to generate tailored message (assembled message) 204 of FIG. data level 702a and a second data level 602b are used to generate the tailored message 204). That is, the data is ordered according to level or hierarchy (from the first data level 702a to the preferred data level) such that the receiver can specify a preference to receive only a subset of multiple levels. For example, some receivers may wish to receive the first three data levels (levels 702a-702c), while other receivers may wish to receive only the first data level (702a). Also, some receivers may only desire information contained in the fifth data level (level 702e), whereas based on divisible data level techniques, some receivers may wish to have information contained in only the fifth data level (level 702e), whereas based on divisible data level techniques, some receivers may wish to have information contained in only the fifth data level (level 702e); If so, you would like to receive up to levels 702a-702d).

In the example shown in FIG. 7B, data level 702 includes multiple data values 704. In the illustrated example, data values 704 within data level 702 cannot be split. For example, if receiving device 206 requests a particular value 704 included in first data level 702a, receiving device 206 accepts the entire first data level 702a. For example, data source 202 provides Twitter hashtags and their publication rates. The data formatting section organizes Twitter hashtags in descending order of their publication rate. The topmost hashtag is the first data level (e.g., data level 702a), the second to tenth hashtag is the second data level (e.g., data level 702b), and the 11th to The 100th hashtag is the third data level (eg, data level 702c). If the receiver wishes to receive only the topmost hashtag, it receives the first data level. If the receiving unit wishes to receive the 10th hashtag from the top, it receives the first data level and the second data level.

The splittable data level provides tunable messages (e.g., receiver 206 in FIG. 3) that allow customization of messages to multiple receiving devices (e.g., receiver 206 in FIG. 3) without reorganizing the data into message buffers for each receiver. The generation of composable messages) is facilitated. For example, if a subscription control module (e.g., subscription control module 201 in FIGS. 2 and 3) is connected to thousands of receiving devices (e.g., receiving device 206 in FIGS. 2 and 3), the receiving device 206 Update messages may be sent with different levels of importance and/or detail for each of the senders, and the sender does not need to organize data regarding all update messages for each receiver.

8A and 8B illustrate adjustable messages generated by a message formatter (e.g., message formatter 304 of FIG. 3) and placed in a buffer (e.g., primary buffer 306 and/or secondary buffer 308 of FIG. 3). Here is an example. After being placed in the buffer, the message transmitter (e.g., message transmitter 310 of FIG. 3) places the buffer in the buffer for transmission as a conditioned message 204 to a receiving device (e.g., receiving device 206 of FIGS. 2, 3). Use some of the tunable messages within. Figure 8A shows the snapshot (Snapshot S in Figures 4, 5, and 6)₀) shows an example of a tunable message 800 based on . In the example shown in FIG. 8A, tunable message 800 includes one or more headers 802 and one or more data levels 804. Header 802 includes bookkeeping information (e.g., number of data levels 804, precision level, timestamp, etc.) necessary for processing tunable message 800 by a message sender (e.g., message sender 310 of FIG. 3). , transmission information.

Data level 804 includes a splittable data level (eg, data level 702 of FIGS. 7A, 7B) that is splittable at one or more split points 806. In some cases, each data level 804 includes multiple values 808. In some cases, to send the tailored message 204, the message transmitter 310 uses a portion of the tailored message 800 from the buffer up to at most one of the split points 806. In the example shown in FIG. 8A, each data level 804 includes a plurality of states representing states of the data source 202 (e.g., first state 400a of FIGS. 4, 5, 6) that correspond to a level of detail and/or importance. Contains the value 808. For example, if tunable message 800 includes eight data levels 804, receiving device 206 selects to receive only the first two data levels 804 by setting a preference. In such an example, message transmitter 310 uses header 802 and first two data levels 804 to transmit to receiving device 206. In some embodiments, socket write calls that reference buffers and appropriate lengths are used to include the desired number of data levels for each receiver.

Figure 8B shows the delta snap (e.g., the delta snap ΔS in Figure 6).₁) shows an example tunable message 810 based on FIG. In the example shown in FIG. 8B, adjustable message 810 includes one or more headers 802 and one or more updates 812. In the illustrated example, update 812 includes action 814. In some cases, each update 812 includes one or more actions 814. In the illustrated example, action 814 includes information regarding changes to data source 202 since the last snapshot. Data update 812 may be a splittable data level that is splittable at split point 806 (eg, data level 702 in FIGS. 7A, 7B). In some cases, to send the tailored message 204, the message transmitter 310 sends the tailored message up to at most one of the split points 806 from a buffer (e.g., primary buffer 306, secondary buffer 308, etc.) Use part of 810. In some cases, the adjustable message 810 does not include updates 812 corresponding to the respective data level 804 (eg, the data at that particular data level 804 has not changed since the last snapshot).

In the example shown in FIG. 8B, action 814 includes an action reference 816, an index 818, and one or more parameters 820. Action reference 816 identifies which action (eg, action 600 of FIG. 6) to perform to update data level 804 identified by index 814. Parameter 820 identifies the magnitude of the change to the identified data level 804 value (eg, value 808). An exemplary action reference 814 is shown in Table 1 below.

<tables><img file="JP7436588B2_D0001.tif" /></tables>

An exemplary "add" action adds a new data level (e.g., data level 704 in FIG. 702a-702f). An example "relative add" action is to perform a "relative addition" action after the data level specified at index 814 has the value of the data level specified at index 814 modified (e.g., added, subtracted) by the value identified by parameter 820. , adding new data levels. The exemplary "add to top" action adds a new data level before the first data level with the value specified by parameter 820. An exemplary "Modify Nth Value" action (e.g., "Modify 1st Value (MV1)") modifies the Nth value at the data level specified by index 814 to the value specified by parameter 820. Modify it so that it is correct. The exemplary "Modify All" action modifies the value at the data level specified by index 814 as specified by parameter 820. An exemplary "delete" action deletes the data level specified by index 814. An exemplary "no change" action produces a duplicate of the data level specified by index 814 before the data level specified by index 814.

Adjustable message 810 can include an update 812 that adds a new data level 804 (e.g., using an "add" action, "relative add" action, and/or "add to top" action) . Additionally or alternatively, the adjustable message 810 includes an update 812 that deletes the existing data level 804 (eg, using a "delete" action). When data level 804 is deleted, lower data levels are shifted upward. For example, tunable message 800 includes data level 1, data level 2, and data level 3. If data level 2 is deleted during the next update of data source 202, data level 3 will be shifted to become data level 2. However, in such an example, if receiving device 206 receives only two data levels in adjusted message 204, receiving device 206 has no information regarding data level three. That is, when receiving device 206 received the last snapshot, reconciled message 204 did not include information regarding data level 3. To facilitate the receiving device 206 having accurate and up-to-date information regarding the current state of the data source 202, the data formatting unit 304 may be configured to update the upwardly shifted data level when the deleted data level 804 is detected. Includes an action 814 (eg, a "no change" action) that provides a level 804 (eg, data levels 1, 3). In some cases, a receiving device 206 that already has a data level 804 receives a "no change" action 814 ignored.

FIG. 9 is a diagram illustrating an example data flow in which a data level (eg, data level 804 of FIG. 8A) has been removed. In the illustrated example, with respect to the state of data source 202 (Figs. 2 and 3), time T₀The first state 900a at and time T₁A second state 900b is shown in FIG. The first state 900a and the second state 900b are organized into a first data level 902a, a second data level 902b, a third data level 902c, a fourth data level 902d and a fifth data level 902e. There is. The data formatter (FIG. 3) generates snapshot-based tunable messages (eg, tunable message 800 of FIG. 8A). Time T₀In , the receiving device 206 (Figures 2, 3) has set a preference for three data, so the adjusted snapshot S has three data levels.₀is sent to receiving device 206. Time T₁At , the second data level 902b is deleted. In the illustrated example, third data level 902c, fourth data level 902d, and fifth data level 902e are shifted upward. When generating a delta snap-based tunable message (eg, tunable message 810 of FIG. 8B), data formatter 304 includes an "no change" action. Adjusted delta snap ΔS₁is sent to the receiver with a "no change" action.

FIG. 10 shows an example tunable message 1000 (e.g., snapshot-based tunable message 800 of FIG. 8A and/or delta of FIG. 8B) within a buffer (e.g., primary buffer 306 or secondary buffer 308 of FIG. 3). Snap-based tunable message 810). Adjustable message 1000 includes one or more headers 1002 and one or more divisible data levels 1004 (eg, data level 804 in FIG. 8A or update 812 in FIG. 8B). In the illustrated example, while formatting the adjustable message, the data formatter 304 (FIG. 3) calculates the location of the split point 1006 within the buffer. In some cases, the data formatter 304 generates a splittable table 1008 that stores the location (eg, byte offset) of the split point 10006 within the buffer. In such examples, partition table 1008 may be stored at the beginning or end of tunable message 1000. In some cases, partition table 1008 is used by message transmitter 310 (FIG. 3) when transmitting tailored message 204 (FIG. 2). In this method, when transmitting the tailored message 204, the message transmitter 310 determines the size of the tailored message 100 required for use according to the preferences of the receiving device 206 (e.g., the amount of bytes in the buffer). can be determined quickly.

VII. Coordination Messaging Using Delta Snaps and Dividable Data Levels Certain embodiments communicate the state of data source 202 to one or more receiving devices 206 using a combination of delta snaps and divisible data level techniques. Provide improved communication technology to communicate.

FIG. 11 shows an example data flow diagram 1100 representing an example first connection 1102a between an example receiving device A 1104a and the subscription control module 201 of FIGS. 2 and 3. Diagram 1100 shows an example second connection 1102b between an example receiving device B 1104b and a subscription control module 201. Subscription control module 201 generates snapshots 1106 at a snapshot threshold rate (e.g., every minute, every two minutes, etc.) and generates delta snaps 1108a-1108g at a base update rate (e.g., every second, etc.) . In the illustrated example, subscription control module 201 sends snapshot 1106 and delta snaps 1108a-1108g to first connection 1102a and second connection 1102b.

In the example shown in FIG. 11, the first connection 1102a has a congested period 1110 and a non-congested period 1112 over time. In the illustrated example, receiving device A 1104a determines the update rate to be received (e.g., the rate at which delta snaps 1108a-1108g are sent to first connection 1102a) and/or the number of data levels (e.g., each snapshot 1106 and Set preferences for how many data levels each delta snap 1108a-1108g contains. In the illustrated example, the update rate set by receiving device A 1104a is equal to the base update rate (eg, the rate at which delta snaps 1108a-1108g are generated by subscription control module 201). For example, if the base update rate is 1 second, receiving device A 1104a receives delta snaps 1108a-1108g at 1 second intervals. In some cases, subscription control module 201 detects a busy period 1110. For example, the send socket of the subscription control module 201 indicates that the send buffer is full and/or the first connection 1102a is busy. In some cases, the subscription control module 201 delays sending the delayed delta snap 1108b until the first connection 1102a is no longer congested. If the congestion period 1110 is longer than the preference update rate by the receiving device 206, the subscription control module 201 deletes the pending delta snap 1108d and sends the next delta snap 1108e in its place.

In the example shown in FIG. 11, the second connection 1102b has a connection period 1113 and a disconnection period 1114 over time. In the illustrated example, the update rate set by receiving device B 1104b is set to be less frequent than the base update rate. For example, if the base update rate is 100 ms, the update rate of receiving device B 1104b is 200 ms. In the illustrated example, when the connection 1102b is established between the subscription control module 201 and the receiving device B 1104b, the subscription control module 201 sends the latest snapshot 1106 and the latest delta snaps 1108b, 1108f. Additionally or alternatively, if disconnection period 114 is short (eg, lower than the current update rate), subscription control module 201 simply sends delta snap 1108f.

12 is executed to cause the subscription control module 201 of FIGS. 2 and 3 to generate snapshots and delta snaps when establishing a connection with a data source (e.g., data source 202 of FIGS. 2 and 3). FIG. 12 is a flow diagram of an example method 1200 representing possible example machine-readable instructions. First, at block 1202, subscription control module 201 receives data transmitted from data source 202. In some cases, subscription control module 201 obtains data at set time intervals. Additionally or alternatively, subscription control module 201 obtains data in response to detecting and/or triggering updates to data source 202. At block 1204, the subscription control module 201 determines whether a threshold rate of snapshots has been exceeded. The snapshot threshold rate is, for example, the minimum time between generating a snapshot and generating the next snapshot. In some cases, the snapshot threshold is based on how much the data source 201 changes each update (eg, the more the data source changes, the shorter the snapshot threshold).

If the snapshot threshold has not been exceeded, program control continues to block 1206. Otherwise, if the snapshot threshold is exceeded, program control proceeds to block 1208. At block 1206, subscription control module 201 generates a snapshot (eg, snapshot 1106 of FIG. 11). Program control returns to block 1202. At block 1208, subscription control module 201 generates delta snaps (delta snaps 1108a-1108g of FIG. 11). Program control then returns to block 1202. Machine readable instructions 1200 are executed until subscription control module 201 is disconnected from data source 202.

FIG. 13 shows an example machine executable for causing the data formatting section of FIG. 3 to generate a snapshot (e.g., snapshot 1106 of FIG. 11) from data retrieved by the data source retrieval section 302 of FIG. 13 is a flow diagram of a method 1300 for representing readable instructions. FIG. Initially, at block 1302, after receiving data from the data source retrieval unit 302, the data formatting unit 304 stores one or more headers (e.g., header 802 of FIG. 8A or Add header 1002). At block 1304, the data formatter 304 organizes the data into divisible data levels (eg, divisible data levels 702a-702f of FIGS. 7A and 7B). In some cases, data is organized into levels of importance and/or detail. At block 1306, data formatter 304 formats the organized data into a tunable message (eg, tunable message 800 of FIG. 8A or tunable message 1000 of FIG. 10). Adjustable messages are placed in primary buffer 306. At block 1308, data formatter 304 calculates the location of the adjustable message's splittable point (eg, splittable 806 in FIG. 8A or splittable point 1000 in FIG. 10) within primary buffer 306. In some cases, data formatter 304 creates a partitioned table (eg, partitioned table 1008 of FIG. 10) and appends it to the beginning or end of the adjustable message in primary buffer 306. The program 1300 then ends.

FIG. 14 shows an executable method for causing the data formatting section 304 of FIG. 3 to generate delta snaps (e.g., delta snaps 1108a-1108g of FIG. 11) from the data retrieved by the data source searching section 302 of FIG. FIG. 14 is a flow diagram of a method 1400 representing example machine-readable instructions. Initially, at block 1302, after receiving data from the data source retrieval unit 302, the data formatting unit 304 stores one or more headers (e.g., header 802 of FIG. 8B, 10 headers 1002) are added. At block 1404, the data formatter 304 organizes the data into divisible data levels (eg, divisible data levels 702a-702f of FIGS. 7A and 7B).

At block 1406, starting with the first data level organized at block 1402, the data formatting unit determines the current data level and the corresponding data level stored in the adjustable message in the primary buffer 306 (FIG. 3). Determine the difference between At block 1408, data formatter 304 determines which actions (eg, action 814 of FIG. 8B) are involved in updating the snapshot with changed data. In some cases, if there is no difference between the current data level and the corresponding data level stored in the adjustable message in primary buffer 306, no action is generated for that level. At block 1410, data formatter 304 adds the action determined at block 1408 to the tunable message in secondary buffer 308 (eg, tunable message 810 of FIG. 8B, tunable message 1000 of FIG. 10). At block 1412, data formatter 304 determines whether some of the delta snaps in secondary buffer 308 are larger than the snapshots in primary buffer 306. If the delta snap in secondary buffer 308 is greater than the snapshot, program control proceeds to block 1414. Otherwise, if the delta snap in secondary buffer 308 is not greater than the snapshot, program control proceeds to block 1416.

At block 1414, generation of the delta snap is aborted and the data formatter instead generates a snapshot. The program 1400 then ends. At block 1416, data formatter 304 determines whether another data level exists to compare with the snapshot. If another data level exists to compare with the snapshot, program control returns to block 1406. Otherwise, if there is not another data level to compare to the snapshot, program control proceeds to block 1418. At block 1418, data formatter 304 calculates the location in secondary buffer 308 of a splittable point (eg, partition table 806 of FIG. 8B or splittable point 1000 of FIG. 10) of the adjustable message. In some cases, data formatter 304 creates a partitioned table (eg, partitioned table 1008 of FIG. 10) and appends it to the beginning or end of the adjustable message in secondary buffer 308. The program 1400 then ends.

FIG. 15 is of an example method 1500 representing example machine-readable instructions executable to cause message transmitter 310 of FIG. 3 to update a receiver (e.g., receiving device 206 of FIGS. 2, 3). It is a flow diagram. At block 1502, message transmitter 310 establishes a connection (eg, first connection 1102a in FIG. 11) with a receiver. In some cases, the message sender 310 requests and/or receives the receiver's preferences. Additionally or alternatively, the message sender 310 maintains and/or has access to the receiver's preferences (eg, from a subscription database). At block 1504, the message transmitter 310 transmits the latest snapshot (eg, snapshot 1106 of FIG. 11) to the receiver. In some cases, the message sender 310 adjusts the snapshot according to the receiver's preferences (eg, using a portion of the adjustable message in the primary buffer 306 of FIG. 3).

At block 1506, message sender 310 determines whether there are more recent delta snaps (eg, delta snaps 1108a-1108g of FIG. 11) in secondary buffer 308 (FIG. 3). If message sender 310 determines that there is a more recent delta snap, program control proceeds to block 1508; otherwise, program 1500 ends. At block 1508, the message sender 310 sends the latest delta snap to the receiver. In some cases, the message sender 310 adjusts the delta snap depending on the receiver's preferences (eg, using a portion of the adjustable message in the secondary buffer 306 of FIG. 3). Program 1500 then ends.

FIG. 16 shows that the receiving device 206 (FIGS. 2, 3) connected to the subscription control module 201 of FIGS. 4 is a flow diagram of a method 1600 representing example machine-readable instructions executable to cause the message sender 310 of FIG. 3 to send eleven delta snaps 1108a-1108g). First, at block 1602, a new snapshot in primary buffer 306 (FIG. 3) or a new delta snap in secondary buffer 308 (FIG. 3) is detected and/or triggered. If there are new snapshots or delta snaps, program control continues to block 1604. Otherwise, program control returns to block 1602. At block 1604, message transmitter 310 determines whether the update rate of receiving device 206 is met. In some cases, the receiver sets preferences received by the message sender 310 when the connection is established and/or maintained by the message sender 310. In some cases, receiving device 206 does not set preferences. In such examples, the update rate defaults to the rate at which subscription control module 201 generates snapshots and delta snaps (eg, the base update rate). If the update rate of the receiving device 206 is met, program control proceeds to block 1606. Otherwise, if the update rate of the receiving device 206 is not met, program control returns to block 1602.

At block 1606, message transmitter 310 determines whether the message can be transmitted to receiving device 206. In some cases, message transmitter 310 detects congestion (eg, congestion period 1112 in FIG. 3). If the message can be sent to receiving device 206, program control continues to block 1608. Otherwise, if the message cannot be sent to receiving device 206, program control returns to block 1602. At block 1608, message transmitter 310 determines whether to transmit the snapshot or delta snap to receiving device 206. If the snapshot is to be sent to receiving device 206, program control continues to block 1610. If a delta snap is to be sent, program control continues to block 1612. At block 1610, message transmitter 310 transmits the snapshot to receiving device 206. In some cases, the message sender 310 adjusts the snapshot according to the receiver's preferences (eg, using a portion of the adjustable message in the primary buffer 306 of FIG. 3). Program control returns to block 1602. At block 1612, the message transmitter 310 transmits the delta snap to the receiver. In some cases, the message sender 310 adjusts the delta snap depending on the receiver's preferences (eg, using a portion of the adjustable message in the secondary buffer 306 of FIG. 3). Program control returns to block 1602. Instructions 1600 are executed until the receiver disconnects from subscription control module 201.

FIG. 17 shows that the message sender 310 of FIG. Exemplary example methods executable to cause snapshots (e.g., snapshot 1106 of FIG. 11) and/or delta snaps (e.g., delta snaps 1108a-1108g of FIG. 11) to be adjusted without reordering (e.g., snapshot 1106 of FIG. 11) FIG. 17 is a flow diagram of a method 1700 for representing machine-readable instructions. First, at block 1702, the message transmitter 310 determines the data level to transmit (eg, data levels 702a-702f in FIGS. 7A, 7B) as indicated in the receiver's preferences. At block 1704, message transmitter 310 determines the size of the portion of the buffer to transmit to receiving device 206 based on the number of data levels determined at block 1702. In some cases, a partitioned table (for example, partitioned table 1008 in FIG. 10) is added to the beginning or end of the buffer. In such an example, message transmitter 310 searches on partition table 1008 for the required buffer size. At block 1706, the message transmitter 310 transmits the portion of the buffer determined at block 1704 to the receiving device 206. The program 1700 then ends.

VIII. Examples of Electronic Trading Systems The embodiments described above are useful in electronic trading systems. For example, communicating market information, including quantities available at various price levels, can benefit from message coordination. For example, internal market data and market depth data for tradable objects may be organized into divisible data levels (eg, divisible data levels 702a-702f). Additionally, updates to internal market data and market depth data can be communicated to subscribers of those tradeable objects' exchanges using delta snap technology.

FIG. 18 shows a block diagram representing an example electronic trading system 1800 in which certain embodiments may be employed. System 1800 includes a trading device 1810, a gateway 1820, and an exchange 1830. Trading device 1810 communicates with gateway 1820. Gateway 1820 communicates with exchange 1830. The term "communication" herein encompasses direct communication and/or indirect communication through one or more intermediate components. Trading device 1810, gateway 1820 and/or exchange 1830 may include one or more computing devices 100 shown in FIG. The example electronic trading system 1800 shown in FIG. 18 may communicate with additional components, subsystems, and elements that provide additional functionality and performance without departing from the teachings and disclosures herein. .

In operation, trading device 1810 receives market data from exchange 1830 via gateway 1820. A user uses trading device 1810 to monitor this market data and/or to make decisions to send order messages to exchange 1830 to buy or sell one or more tradeable objects.

Market data includes data regarding the market for tradable objects. For example, market data includes internal market, market depth, last traded price ("LTP"), last traded quantity ("LTQ"), or a combination thereof. The internal market (which changes over time) is the highest bid price (best bid) and lowest available ask price (best ask or best offer) in the market for a particular tradable object at a point in time. Market depth refers to the quantity available at price levels that include the internal market and away from the internal market. Market depth may have "gaps" due to prices that do not have quantity based on orders within the market.

Price levels related to internal markets and market depth can also be provided as price levels that can include not only prices but also extracted and/or calculated representations for certain values. For example, the value level is displayed as a net change from the opening price. As another example, a value level is provided as a value calculated from prices in two other markets. In another example, the value level includes an aggregate price level.

A tradeable object is any object that is traded. For example, a particular quantity of a tradeable object can be bought or sold at a particular price. Tradable objects include, for example, financial instruments, stocks, options, bonds, futures, currencies, warrants, fund derivatives, securities, commodities, swaps, interest rate products, index-based products, trading events, goods, or combinations thereof. . Tradeable objects include exchange-listed and/or managed products, user-defined products, combinations of real or synthetic products, or combinations thereof. Note that there may be synthetic tradable objects that correspond to and/or resemble real tradable objects.

An order message is a message that includes a trading order. A trading order may be, for example, a command to buy or sell a tradeable object, a command to initiate the management of an order according to a defined trading strategy, a command to change, modify or cancel an order, or an electronic exchange associated with the order. It may be an instruction to or a combination thereof.

Trading device 1810 may include one or more electronic computing platforms. For example, trading device 1810 may be a desktop computer, handheld device, laptop, server, portable computing device, trading terminal, embedded trading system, workstation, algorithmic trading system (a "black box" or "gray box"). ''), a cluster of computers, or any combination thereof. As another example, transaction device 1810 may include a memory or other storage medium configured to accessably store one or more computer programs, applications, libraries or computer readable instructions, etc., executed by a processor. It may include a single or multi-core processor for communicating.

As used herein, the term "configured to, adapted to" refers to an element, structure, or device that has been modified, arranged, changed, etc. so as to perform a particular function or a particular purpose. Including cases where

Illustratively, trading device 1810 is a personal computer running a copy of X_TRADER®, an electronic trading platform provided by Trading Technologies International, Inc. (hereinafter referred to as "Trading Technologies") of Chicago, Illinois. It may be implemented as As another example, the trading device 1810 may be a server running a trading application that provides automated trading tools such as ADLR(TM), AUTOSPREADER(R), and/or AUTOTRADER(TM) from Trading Technologies, Inc. Good too. In yet another example, trading device 1810 may include a trading terminal in communication with a server, where the trading terminal and server collectively constitute trading device 1810.

Transaction device 1810 is typically owned, operated, controlled, programmed, configured, or otherwise used by a user. The term "user" as used herein includes, but is not limited to, a human being (e.g., a trader), a trading group (e.g., a group of traders), or an electronic trading device (e.g., an algorithmic trading system) - one or more Multiple users may be involved in, for example, ownership, operation, control, programming, configuration, or other use.

Trading device 1810 includes one or more trading applications. A transaction application herein is an application that enables or improves electronic commerce. A trading application provides one or more electronic trading tools. For example, a trading application stored on a trading device is executed to place and display market data in one or more trading windows. In another example, the trading application includes an automated spread trading application that provides spread trading tools. In yet another example, a trading application includes an algorithmic trading application that automatically processes algorithms to perform certain actions (such as placing an order, modifying an existing order, deleting an order, etc.). In yet another example, a trading application provides one or more trading screens. A trading screen may provide one or more trading tools that can interact with one or more markets. For example, trading tools allow users to obtain and view market data, set order entry parameters, send order messages to exchanges, deploy trading algorithms, and/or while implementing various trading strategies. , position monitoring can be performed. Electronic trading tools provided by a trading application may be available at all times, or may only be available in certain settings or modes of operation of the trading application.

The trading application is implemented using computer readable instructions stored on a computer readable medium and executable by a processor. Computer-readable media may include, for example, random access memory, read-only memory, programmable read-only memory, electrically programmable read-only memory, electrically erasable read-only memory, flash memory, any combination thereof, or any other memory. Various types of volatile and non-volatile storage media are included, such as tangible data storage devices. The term non-transitory or tangible computer-readable medium is expressly defined herein to include any type of computer-readable storage medium, but excludes propagated signals.

One or more components or modules of a trading application may be loaded onto the computer-readable medium of trading device 1810 from another computer-readable medium. For example, a trading application (or an update to a trading application) may be stored on one or more CDs or DVDs by the manufacturer, developer, or publisher and subsequently loaded onto the trading device 1810, or Trading device 1810 may be loaded onto a server for reading trading applications. As another example, trading device 1810 may receive trading applications (or trading application updates) from a server, such as via the Internet or an internal network. Trading device 1810 receives trading applications or updates thereof when requested by trading device 1810 (e.g., "pull delivery") and/or when not requested by trading device 1810 (e.g., "push delivery"). You can.

Trading device 1810 may be configured to send order messages. For example, an order message is sent to exchange 1830 via gateway 1820. As another example, trading device 1810 is configured to send order messages to a simulated exchange in a simulated environment that does not affect actual trading.

Order messages may be sent at the user's request. For example, a trader may utilize trading device 1810 to send an order message or manually enter one or more parameters regarding a trading order (eg, price and/or quantity of the order). As another example, an automated trading tool provided by a trading application calculates one or more parameters regarding a trading order and automatically sends an order message. In one example, an automated trading tool creates a message for sending but does not actually send it without confirmation from the user.

The order message is sent in one or more data packets or via a shared memory system. For example, an order message is sent from trading device 1810 to exchange 1830 via gateway 1820. Transaction device 1810 may be connected to, for example, a local area network, a wide area network, a wireless network, a virtual private network, a cellular network, a peer-to-peer network, a T1 line, a T3 line, an Integrated Services Digital Network ("ISDN") line, a point of presence, or the Internet. , a shared memory system, and/or a proprietary network such as TTNET provided by Trading Technologies, Inc. to communicate with the gateway 1820.

Gateway 1820 may include one or more electronic computing platforms. For example, the gateway 1820 may be one or more desktop computers, handheld devices, laptops, servers, portable computing devices, trading terminals, embedded trading systems, workstations with single/multi-core processors, "black boxes", etc. or may be implemented as an algorithmic trading system such as a "grey box", a cluster of computers, or any combination thereof.

Gateway 1820 may facilitate communications. For example, gateway 1820 performs protocol conversion of data communicated between trading device 1810 and exchange 1830. Gateway 1820 , for example, processes order messages received from trading device 1810 into a data format that can be determined by exchange 1830 . Similarly, gateway 1820 , for example, converts market data received from exchange 1830 in an exchange-specific format into a format understandable by trading device 1810 .

Gateway 1820 may include transaction applications that facilitate or enhance electronic transactions, similar to those described above. For example, gateway 1820 may have a trading application that tracks orders from trading device 1810 and updates the status of the orders based on fill confirmations received from exchange 1830. As another example, gateway 1820 may have a trading application that combines data from trading market 1830 and provides it to trading device 1810. In yet another example, gateway 1820 may include a trading application that provides risk processing, calculates implieds, handles order processing, handles market data processing, or a combination thereof.

In some embodiments, the gateway 1820 is, for example, a local area network, a wide area network, a wireless network, a virtual private network, a cellular network, a peer-to-peer network, a T1 line, a T3 line, an ISDN line, a point of presence, the Internet, a shared memory system. and/or communicate with Exchange 1830 using a proprietary network such as TTNET provided by Trading Technologies, Inc.

Exchange 1830 may be owned, operated, controlled, or used by an entity at the exchange. Exemplary exchange entities include CME Group, London International Financial Futures and Options Exchange, Intercontinental Exchange, and Eurex. Exchange 1830 may include, for example, an electronic matching system, such as a computer, server, or other computing device configured to enable the buying and selling of tradeable objects offered for trading by the exchange. Exchange 1830 may have separate entities, some of which list and/or manage tradeable objects and others which receive and match orders. Exchange 1830 includes, for example, an electronic communications network ("ECN").

Exchange 1830 may be an electronic exchange. Exchange 1830 is configured to receive order messages and match opposing trading orders to buy or sell tradeable objects. Trade orders that are not matched are listed by the exchange 1830 for later trading. Once an order to buy or sell a tradeable object is received and confirmed by an exchange, the order is considered an active order until filled or canceled. If only a portion of the order's quantity is matched, the partially matched order remains an active order. Trading orders may include, for example, trading orders received from trading device 1810 or from other devices in communication with exchange 1830. For example, exchange 1830 typically communicates with various devices (which may be similar to trading device 1810) that provide trading orders to be matched.

Exchange 1830 is configured to provide market data. Market data may be provided in one or more messages or data packets or via a shared memory system. Exchange 1830 exposes data feeds to contract devices, such as trading device 1810 or gateway 1820, for example. Data feeds include market data.

System 1800 may include additional, different, or fewer components. For example, system 1800 includes multiple trading devices, gateways, and/or exchanges. In another example, system 1800 may include other communication devices, such as middleware, firewalls, hubs, switches, routers, servers, exchange-specific communication equipment, modems, security managers, and/or encryption/decryption equipment. good.

IX. Extended Electronic Trading System Example FIG. 19 depicts a block diagram of another exemplary electronic trading system 1900 in which certain embodiments may be employed. In this example, trading device 1910 communicates with gateway 1920 and exchange 1930 utilizing one or more communication networks. For example, trading device 1910 utilizes network 1902 to communicate with gateway 1920, and gateway 1920 utilizes networks 1904, 1906 to communicate with exchange 1930. As used herein, networks facilitate or enable communication between computing devices such as trading devices 1910, gateways 1920, and exchanges 1930.

The following description generally focuses on trading device 1910, gateway 1920, and exchange 1930. However, the trading device 1910 may have "n" additional gateways (individually identified as gateways 1920a-1920n and may be similar to gateway 1920) and "n" additional gateways (individually identified as exchanges 1930a-1930n and exchange 1930). network 1902 (or other similar network) with "n" additional exchanges (which may be similar to "n"). Utilizes additional gate networks (individually identified as networks 1904a-1904n, 1906a-1906n, which may be similar to each of networks 1904, 1906) for communication between additional gateways and additional exchanges. Good too. The communication between trading device 1910 and each of the additional exchanges 1930a-1930n need not be the same as the communication between trading device 1910 and exchange 1930. Generally, each exchange has its own preferred technology and/or format for communicating with trading devices, gateways, users, or other exchanges. A one-to-one mapping between gateways 1920a-1920n and exchanges 1930a-1930n is not necessarily required. For example, a particular gateway may communicate with multiple exchanges. As another example, multiple gateways may communicate with the same exchange. Such a configuration may, for example, allow one or more trading devices 1910 to trade on multiple exchanges (and/or provide redundant connections to multiple exchanges). .

Additional trading devices 1910a-1910n (which may be similar to trading device 1910) may be connected to one or more of gateways 1920a-1920n and one or more of exchanges 1930a-1930n. For example, trading device 1910a communicates with exchange 1930a via gateway 1920a and networks 1902a, 1904a, 1906a. In another example, trading device 1910b communicates directly with exchange 1930a. In another example, trading device 1910c communicates with gateway 1920n via an intermediate device 1908, such as a proxy, remote host, or WAN router.

Trading device 1910 (which may be similar to trading device 1810 shown in FIG. 18) may include a server 1912 that communicates with trading terminal 1914. Server 1912 may be located geographically closer to gateway 1920 than transaction terminal 1914 to reduce latency. During operation, trading terminal 1914 may provide trading screens to the user and send commands to server 1912 for further processing. For example, trading algorithms may be deployed to server 1912 for execution based on market data. Server 1912 may execute the trading algorithm without further input from the user. In another example, server 1912 may include a trading application that provides automated trading tools and again communicates with trading terminal 1914. Transaction device 1910 may include additional, different, or fewer components.

In operation, network 1902 may be a multicast network to enable trading device 1910 to communicate with gateway 1920. Data on network 1902 may be logically divided according to items such as price, order, or contract, for example. As a result, server 1912 and trading terminal 1914 can contract and receive data (eg, data related to prices, orders, or fills) according to their individual needs.

Gateway 1920 (which may be similar to gateway 1820 shown in FIG. 18) includes a price server 1922, an order server 1924, and a fill server 1926. Gateway 1920 may include additional, different, or fewer components. Price server 1922 processes price data. Price data includes data related to the market for one or more tradable objects. Order server 1924 processes order data. Order data is data related to a user's trading order. For example, order data may include order messages, confirmation messages, or other types of messages. The contract server collects and provides contract data. Fill data includes data related to one or more fills of a trading order. For example, fill server 1926 provides a record of filled and unfilled trading orders routed through server 1924. Servers 1922, 1924, 1926 may be executed on the same machine or on separate machines. Multiple instances of price server 1922, order server 1924, and/or fill server 1926 may exist for gateway 1920. In some embodiments, each of the additional gateways 1920a-1920n includes an instance of a server 1922, 1924, 1926 (individually identified as a server 1922a-1922n, 1924a-1924n, 1926a-1926n).

Gateway 1920 communicates with exchange 1930 using one or more communication networks. As shown in FIG. 19, for example, there may be two communication networks connecting gateway 1920 and exchange 1930. Network 1904 may be used to communicate market data to price server 1922. In one example, exchange 1930 includes such market data in a data feed published to subscribing devices. Network 1906 may be used to communicate order data to order server 1924 and fill server 1926. Network 1906 may be used to communicate order data from order server 1924 to exchange 1930.

Exchange 1930 (which may be similar to exchange 1830 shown in FIG. 18) includes an order book 1932 and a matching engine 1934. Exchange 1930 may include additional, different, or fewer components. Order book 1932 is a database containing data related to the quantity of trade orders submitted to exchange 1930 but not matched. For example, order book 1932 includes data related to the market for the tradable object, such as the internal market, market depth at various price levels, last traded price, and last traded quantity. Matching engine 1934 matches pending opposing bids and offers in order book 1932. For example, matching engine 1934 may perform one or more matching algorithms to match opposing bids and offers. A sell order is an order that is opposed to a buy order at the same price. Similarly, a buy order is an order relative to a sell order of the same price. Matching algorithms, for example, match opposing bids and offers of the same price. In some embodiments, each of the additional exchanges 1930a-1930n includes an order book (individually identified as order book 1932a-1932n and matching engine 1934a-1934n, which may be similar to each of order book 1932 and matching engine 1934). and matching engine. Different exchanges may use different data structures and algorithms to track data related to orders and match orders.

In operation, exchange 1930 may provide price data from order book 1932 to price server 1922 and order data and/or fill data from matching engine 1934 to order server 1924 and/or fill server 1926. good. Servers 1922, 1924, 1926 may process and communicate these data back to transaction device 1910. Trading device 1910 processes this data using, for example, a trading application. The data may be displayed to the user, for example. In another example, a trading algorithm utilizes the data to determine whether to submit a trading order to the exchange 1930. Trading device 1910 may prepare and send an order message to exchange 1930.

In some embodiments, gateway 1920 is part of transaction device 1910. For example, components of gateway 1920 may be part of the same computing platform as trading device 1910. As another example, the functions of gateway 1920 may be performed by components of transaction device 1910. In some embodiments, gateway 1920 is not present. Such a configuration may occur, for example, when trading device 1910 does not need to utilize gateway 1920 to communicate with exchange 1930, such as when trading device 1910 is configured to communicate directly with exchange 1930. .

X. Coordinated Messaging Including Market Data The message coordination techniques described herein utilize market data (e.g., internal market, market depth, implied (e.g., internal market, market depth, implied)) to a trading device (e.g., trading device 1810 of FIG. 18) through a gateway (e.g., gateway 1820 of FIG. 18) or server that handles communications between the device and other components in the trading system. may be used. For example, the subscription control module (eg, subscription control module 201 of FIGS. 2, 3) may be a component of gateway 1820 or an edge server to a distributed trading environment. Trading device 1810 reconstructs the current state of the market for the tradable object by using the most recently received snapshot as a base and by applying the actions contained in the most recently received delta snap.

A data source receiver 302 (FIG. 3) of subscription control module 201 receives or otherwise obtains market data from exchange 1830 regarding tradeable objects. Data formatting unit 304 (FIG. 3) organizes market data into data levels (eg, data levels 702a-702f in FIGS. 7A and 7B). The data levels include the internal market of the tradable object at the first data level (e.g. containing the highest bid and/or lowest ask) and the internal market of the tradable object at the first data level (e.g. containing the highest bid and/or the second highest ask). (including) the first level of market depth at the second data level. In some cases, data formatting unit 304 configures the implied market for tradable objects at the data level.

When subscription control module 201 is generating a snapshot (e.g., snapshot 1106 in FIG. 11), data formatting unit 304 generates a header (e.g., header 802 in FIG. 8A) and converts the header into a market depth Add to the beginning of the data level. In some cases, the data formatter adds an implied market data level after the market depth data level. In some cases, the data format portion includes implied market data values that include corresponding market depth data levels. The results are then placed in a primary buffer (eg, primary buffer 306 in FIG. 3). In some cases, the data formatter generates a partitioned table (eg, partitioned table 1008 of FIG. 10) for storage in primary buffer 306 or another memory.

When subscription control module 201 is generating a delta snap (e.g., delta snap 1108a in FIG. 11), data formatter 304 generates a header and stores the header in a secondary buffer (e.g., secondary buffer 308). The data formatter compares the market depth level stored in the primary buffer 306 (including the most recently generated snapshot) with the current market data level and takes actions that reflect the difference (e.g., the action in Figure 8B). 814). Actions 814 are added to the buffer as they are generated. In some cases, after adding an action, the data formatter checks whether the message in secondary buffer 308 is larger than the message in primary buffer 306. If the message in secondary buffer 308 is large, data formatter 304 generates a snapshot instead. In some cases, data formatting unit 304 generates actions regarding implied market data levels. Additionally, the data formatter generates a partition table 1008 for storage in secondary buffer 308 or another memory.

20A, 20B illustrate example adjustable messages for snapshots and delta snaps to provide market data at a large number of data levels for market depth. FIG. 20A shows an example adjustable snapshot message 2000 for providing market data at a large number of data levels regarding market depth. Adjustable snapshot message 2000 includes a header 2002 and market depth data level 2018. In some cases, adjustable snapshot message 2000 also includes implied market data levels. In the illustrated example, implied market data level 2020 is combined with market depth data level 2018 (e.g., first market depth, first implied market depth, second market depth, second implied market depth). Interlaced. By interlacing, the implied market data level 2020 can be truncated to the same level as the market depth data level 2018. Interlacing requires sending the implied market data level 2020 with the adjusted message 204 even if the particular recipient does not request it. Alternatively, in some cases, the implied market data level 2020 can be organized at the end of the adjustable snapshot message 2000. In such an example, market depth data level 2018 and implied market data level 2020 are not separately truncatable.

In the illustrated example, the header 2002 includes a size parameter 2008, an implied parameter 2010, an ask depth parameter 2012a, a bid depth parameter 2012b, an implied ask depth parameter 2014a, and an implied bid depth parameter 2014b. Size parameter 2008 provides the size of tunable snapshot message 2000 within a buffer (eg, primary buffer 306, secondary buffer 308). If the partitioned table 1008 is added at the end of the adjustable snapshot message 2000, the size parameter 2008 can be used to determine the starting point of the partitioned table 1008.

In the example shown in FIG. 20A, the implied parameter 2010 indicates whether the adjustable snapshot message 2000 includes an implied market data level 2020. Ask depth parameter 2012a indicates the number of market depth data levels 2018 that include ask level 2017a in adjustable snapshot message 2000. Bid depth parameter 2012b indicates the number of market depth data levels 2018 that include bid level 2017b in adjustable snapshot message 2000. In some cases, the ask depth parameter 2012a and the bid depth parameter are not equal. For example, the market for a tradable object may be asymmetric with more bid levels 2017b than ask levels 2017a (or vice versa). Implied ask depth parameter 2014a indicates the number of implied market data levels 2020 included in adjustable snapshot message 2000, including ask level 2017a. Implied bid depth parameter 2014b indicates the number of implied market data levels 2020 included in adjustable snapshot message 2000, including bid level 2017b. If Implied Parameters 2010 indicates that Adjustable Snapshot Message 2000 does not include Implied Market Data Level 2020, then Implied Ask Depth Parameter 2014a and Implied Bid Depth Parameter 2014b are not included in Header 2002 There are cases.

In the example shown in Figure 20A, depth data level 2018 includes a price and quantity (also referred to as size) for bid level 2017a and/or a price and quantity (also referred to as size) for ask level 2027a (e.g., market depth is (not symmetrical; there are more ask levels than bid levels, and vice versa). For example, the first depth data level 2018 has both the ask level 2017b and the bid level 2017b, while the second depth data level 2018 only includes the ask level 2017a because the market regarding tradable objects is asymmetric. There are cases. For efficiency, depth data levels 2018 after the first depth data level are offset by price offsets such as ask offset 2019a and bid offset 2019c (e.g. the price of the bid/ask level is included in the previous depth data level 2018). It may also include quantities (also called sizes) such as ask size 2019b and bid size 2019d. Since a price value can be represented by a 64-bit (8 byte) value, the data that needs to be sent is 8 bits (1 byte), which is a relative offset to identify the subsequent price value. The amount can be reduced.

In the illustrated example, implied depth data level 2020 includes price and size for implied market depth. Additionally or alternatively, implied depth data level 2020 has a size and price offset similar to that described above with respect to depth data level 2018 (e.g., the price is relative to the price contained in the previous implied depth data level 2020). ). The message sending portion 310 (FIG. 3) of the subscription control module 201 connects (e.g., the first connection of FIG. 1102a, second connection 1102b in FIG. 11) can be established. Message transmitter 310 receives preferences from trading device 1810. Exemplary preferences include the number of market depth levels to receive, and/or a preferred transmission rate (eg, how often to send delta snaps). If the receiving device 206 sets a preference for any level of the implied market while the implied market data level 2020 is not interlaced with the market depth data level 2018, the receiving device 206 sets a preference for any level of the implied market. receive.

To send a tailored snapshot message (eg, tailored message 204 of FIG. 2), message transmitter 310 uses a portion of tailored snapshot message 2000 from primary buffer 306. In some cases, the message sender retrieves a portion of the adjustable snapshot message 2000 for use on the partitioned table 1008. Message transmitter 310 then transmits adjusted message 204 to trading device 1810

In some cases, to determine the amount to truncate the adjustable snapshot message 2000 to achieve a desired number level for the receiver, the message sender 310 reduces bytes of the primary buffer 306 for transmission to the trading device 1810. Calculate the number. In such an example, the number of bytes to send can be calculated by Equation (4), Equation (5), and Equation (6) below.

Formula (4):B_L=(MD₁+AB_B×n)×2(1+I)where, B_Lis an upper bound on the length in bytes of an adjustable message in the buffer that should be sent, MD₁is the size of the difference in bytes between the first market depth data level 2018 and the next market depth data level 2018 (if the next market depth data level utilizes a price offset), and AB_Bis the size in bytes of the next market depth data level 2018, n is the number of desired levels of market depth, and I is the implied parameter 2010 (e.g., I=0 means the implied market data (I=1 indicates that one implied market data is included).

Formula (5):B_R=AB_B×(min(0, nb)+min(0, na)+min(0, n-ib)+min(0, n-ia)) where BR is when the bid/ask levels are asymmetric. ABB is the number of bytes to reduce to, and ABB is the number of bytes to be reduced to for the next (i.e. not the first) market depth data level 2018 (which is different from the first market depth data level 2018 if a price offset is used). is the size of bytes, n is the number of desired levels in the market depth, b is the bid depth parameter 2012b, a is the ask depth parameter 2012a, and ib is the implied bid depth parameter 2014b. , and ia is the implied ask depth parameter 2014a.

Formula (6):B_S=B_L-B_RHere, Bs is the number of bytes to send out of the adjustable level portion of the adjustable snapshot message 2000. For example, to determine the size of the message from the beginning of the buffer holding adjustable snapshot message 2000 containing header 2002, an additional byte for that header is appended to Bs to determine the total number of bytes to send. be done. Message transmitter 310 then transmits an adjusted message 204 containing the calculated number of bytes from adjustable snapshot message 2000 to trading device 1810.

FIG. 20B shows an example adjustable delta snap message 2022 for providing updates to market data at many data levels in market depth. Adjustable delta snap message 2022 includes a header 2002 and market depth data level update 2026. In some cases, the adjustable delta snap message 2022 further includes implied market depth update data levels. In the illustrated example, implied market depth update data level 2028 is interlaced with market depth data level update 2026. Alternatively, the adjustable delta snap message 2022 is placed with the implied market depth update data level 2028 at the end of the message (e.g., the implied market depth update data level 2020 is placed at the end of the adjustable snapshot message 2000. case).

In the illustrated example, the header 2002 includes a size parameter 2008, an implied parameter 2010, an ask depth parameter 2012a, a bid depth parameter 2012b, an implied ask depth parameter 2014a, and an implied bid depth parameter 2014b. Size parameter 2008 provides the size of adjustable delta snap message 2022 within a buffer (eg, primary buffer 306, secondary buffer 308). If the partitioned table 1008 is appended to the end of the adjustable delta snap message 2022, the size parameter 2008 can be used to determine the starting point of the partitioned table 1008.

In the example shown in FIG. 20B, implied parameter 2010 indicates whether an implied market data level update 2028 is included in adjustable delta snap message 2022. Ask update parameter 2023a indicates the number of market depth data level updates 2026 that include ask values 2017a within adjustable delta snap messages 2022. Bid update parameter 2023b indicates the number of market depth data level updates 2026 that include the bid value 2017b within adjustable delta snap message 2022. Implied ask update parameter 2024a indicates the number of implied market data level updates 2028 that include ask value 2017a within adjustable delta snap message 2022. Implied bid update parameter 2024b indicates the number of implied market data level updates 2028 that include bid value 2017b within adjustable delta snap message 2022. In the example where implied parameters 2010 indicate that implied market data level update 2028 is not included within adjustable delta snap message 2022, implied ask depth parameter 2024a and implied bid depth parameter 2024b are included in header 2002. There may be no.

In the example shown in Figure 20B, when the internal market or each market depth's ask price, ask size, bid price, and/or bid size has changed since the last snapshot, the market Includes depth data level update 2026. For example, if the internal market and the first market depth are not changing, and the second market depth's bid size is changing, then the adjustable delta snap message 2022 indicates the market depth data level for the second market depth. Including update 2026. In some cases, implied market data within an adjustable delta snap message 2022 when the respective implied market depth ask price, ask size, bid price and/or bid size has changed since the last snapshot. Includes level update 2028.

In the example shown in FIG. 20B, market depth data level update 2026 and/or implied market depth data level update 2028 included in adjustable delta snap message 2022 includes one or more actions 2030. Action 2030 may include action reference 2032, index 2034, offset 2036, price 2038, and/or size 2040. The action reference 2032 identified in the action for the trading device 1810 is the one that performs the implementation of the respective update. Index 2034 identifies the data level at which the action is performed. Offset 2036 specifies the amount to change the specified value. For example, for a corrective price action, offset 2036 specifies the quantity by which the price should be adjusted. The price 2038 specifies the value to which the data level price is set. Size 2040 identifies the value to which the data level size is set. An example of Action Reference 2030 is listed in Table 2 below.

<tables><img file="JP7436588B2_D0002.tif" /></tables>

To send an adjusted delta snap message (e.g., adjusted message 204 of FIG. 2) to trading device 1810, message transmitter 310 uses a portion of adjusted delta snap message 2022 from secondary buffer 308. . In some cases, the message sender retrieves portions of the adjustable delta snap message 2022 for use in the partitioned table 1008. Message transmitter 310 then transmits adjusted message 204 to trading device 1810.

In some cases, to truncate the adjustable delta snap message 2022, the message transmitter 310 calculates the number of bytes in the secondary buffer 308 to send to the trading device 1810. To calculate the number of bytes, market depth data level update 2026 and implied market depth data level update 2028 are traversed and the calculated position within secondary buffer 308 is determined. Up to the depth limit (N) set by the preferences of the receiving device 206, with respect to the action 2030 with index 2034, the number of action references 2032 with a "delete" action (D) is counted, and the number of action references 2032 with an "add" action ( For example, the number of add references 2932 with "add", "add to top", "relative add") is counted. The actions 2030 in the secondary buffer 308 are traversed up to the end of the last action 2030 corresponding to the N+DA index. This location is a calculated location. Message transmitter 310 then transmits adjusted message 204 including the number of bytes indicated by the calculated position from adjustable delta snap message 2022 to trading device 1810.

Some of the drawings depict example block diagrams, systems, and/or flow diagrams that can be used to implement all or a portion of certain embodiments. One or more components, elements, blocks and/or functions in an example block diagram, system and/or flow diagram may include, for example, hardware, firmware, computer readable instructions stored on a tangible computer readable medium. ), and/or any combination thereof, alone or in combination.

Exemplary block diagrams, system and/or flow diagrams include, for example, any application specific integrated circuit (ASIC), programmable logic device (PLD), field programmable logic device (FPLD), discrete logic, hardware and/or firmware. This is achieved using a combination of Also, some or all of the example methods may be performed, for example, manually or in combination with the techniques described above.

Example block diagrams, systems and/or flow diagrams may be implemented using, for example, one or more processors, controllers and/or other processing devices. For example, the example may be executed using coded instructions, such as computer-readable instructions stored on a tangible computer-readable medium. Tangible computer readable media may include, for example, random access memory (RAM), read only memory (ROM), programmable read only memory (PROM), electrically programmable read only memory (EPROM), electrically erasable read only memory (EEPROM) , various types of volatile and non-volatile storage media, such as flash memory, hard disk drives, optical media, magnetic tape, file servers, any other tangible data storage device, or any combination thereof. Tangible computer-readable media are non-volatile.

Additionally, although example block diagrams, systems, and/or flow diagrams have been described with reference to the drawings, other implementations are possible. For example, the order of execution of the components, elements, blocks and/or functions may be changed and/or some of the described components, elements, blocks and/or functions may be modified, deleted, subdivided or combined. Good too. Furthermore, any or all of the components, elements, blocks and/or functionality may be implemented in series and/or in parallel, eg, by separate processing threads, processors, devices, discrete logic and/or circuits.

Although multiple embodiments have been disclosed, various modifications and equivalents may be substituted. Additionally, many modifications may be made to adapt a particular situation or material. Thus, the disclosed technology is not intended to be limited to certain disclosed embodiments, but is intended to encompass all embodiments falling within the scope of the appended claims.