Granted Patent B1

US 12,541,795 · App. 19/260,613 · Granted Feb 3, 2026

Inventor: Jin Seok Yoon (Elmwood Park, NJ)

G06Q40/04G06F9/30038G06F9/3887G06F9/5022G06F9/546G06F2209/503G06F2209/548

Abstract

Claims (114)

1 . A high-speed matching engine for processing electronic trade orders with ultra-low latency, implemented as computer-executable instructions stored in non-transitory memory and executed by one or more processors, the matching engine comprising:

(a) a memory-management system configured to allocate a plurality of Data Holder Nodes and at least one Price Level Descriptor;

(b) wherein each Data Holder Node:

(i) is assigned a contiguous memory region that is physically contiguous or virtually contiguous via page mapping and aligned to cache-line boundaries;

(ii) stores a fixed, predetermined maximum number of order objects in contiguously addressable slots within said region, each order object including at least a price value and a quantity value; and

(iii) includes at least one priority-tracking bitmask that, for each price level represented in the node, indicates whether the node contains the lowest-priority order at that price level and, if present, the particular one of said contiguously addressable slots that holds that order;

(c) at least one ordered price-level index keyed by a price level value, the index comprising one or more Price Level Descriptors; and, for each Price Level Descriptor, storing:

(i) metadata for the price level; and

(ii) a reference to the Data Holder Node containing the lowest-priority order at that price level;

(d) at least one core-match unit, each operating in a single-threaded execution context for a financial instrument and configured to:

(i) receive incoming orders;

(ii) match each incoming order against opposite-side resting orders according to a predetermined priority rule;

(iii) execute trades;

(iv) insert any unfilled quantity of the incoming order into one of the Data Holder Nodes; and

(v) update affected Data Holder Nodes, including the at least one priority-tracking bitmask therein, and the at least one ordered price-level index after each execution, insertion, cancellation, modification, or relocation.

2 . The matching engine of claim 1 , wherein the memory-management system maintains per-core allocation arenas for Data Holder Nodes, and each core-match unit exclusively allocates and frees Data Holder Nodes from the allocation arena associated with the processor core on which it executes.

3 . The matching engine of claim 1 , wherein each order object stores, in a descriptor-handle field, a direct reference to the Price Level Descriptor for its price level, and wherein, during cancellation or modification processing, the core-match unit obtains the Price Level Descriptor using only the descriptor-handle field, without performing any key-based search or traversal of the ordered price-level index.

4 . The matching engine of claim 1 , wherein each update to the at least one priority-tracking bitmask sets or clears a bit at an index derived from a slot identifier of an affected order in a node-local bitmask field, without iterating over any other order stored in the node, and completes in time independent of a count of orders stored in the node.

5 . The matching engine of claim 1 , wherein the memory-management system enforces a node-capacity policy that specifies, for each depth measured from a head-of-book position, a maximum number of orders per Data Holder Node, the policy being monotone non-increasing with depth.

6 . The matching engine of claim 5 , wherein the node-capacity policy is maintained on a per-core basis, a per-non-uniform-memory-access (NUMA)-node basis, a global basis, or any combination thereof.

7 . The matching engine of claim 5 , wherein the memory-management system is further configured, in response to each revision of the node-capacity policy, to

(a) allocate additional pre-constructed Data Holder Nodes whose maximum capacities correspond to the revised policy; and

(b) retire or repurpose pre-constructed Data Holder Nodes whose capacities no longer conform to the revised policy,

thereby keeping node size classes aligned with real-time order-flow conditions.

8 . The matching engine of claim 1 , wherein the at least one core-match unit is configured to insert any unfilled quantity of the incoming order into a Data Holder Node using an Append operation or a Prepend operation, wherein:

(a) in an Append operation, the at least one core-match unit inserts the incoming order immediately after a point of reference;

(b) in a Prepend operation, the at least one core-match unit inserts the incoming order immediately before a point of reference; and

(c) for each such insertion, the at least one core-match unit determines the point of reference at the time of that insertion in accordance with the predetermined priority rule.

9 . The matching engine of claim 8 , wherein, upon determining that the insertion would exceed a capacity of a target Data Holder Node, the at least one core-match unit executes a relocation cascade comprising zero or more hops in a single direction, and:

(a) for an Append insertion, executes a Push Back cascade in which each hop relocates a lowest-priority order from a current Data Holder Node to an immediately succeeding Data Holder Node;

(b) for a Prepend insertion, executes a Push Forward cascade in which each hop relocates a highest-priority order from a current Data Holder Node to an immediately preceding Data Holder Node; and

(c) in either case, inserts the relocated order into the destination Data Holder Node at a position that preserves the predetermined priority ordering across all nodes, with a zero-hop case allocating a new Data Holder Node at a cascade boundary to accommodate the order.

10 . The matching engine of claim 1 , further comprising at least one lookup structure keyed by order identifiers and accessible to the at least one core-match unit, each entry storing a reference to the Data Holder Node that currently holds the corresponding order.

11 . The matching engine of claim 1 , wherein the memory-management system allocates memory in large contiguous blocks selected from 2 MB, 1 GB, or any hardware-supported huge-page sizes, thereby reducing translation lookaside buffer misses.

12 . The matching engine of claim 1 , wherein each Data Holder Node further includes metadata storing one or both of:

(a) a current count of orders in the node; and

(b) references to adjacent Data Holder Nodes in a doubly- or singly-linked structure.

13 . The matching engine of claim 1 , wherein each ordered price-level index is a balanced search tree keyed by a price level value, thereby providing logarithmic time insertion and search operations.

14 . The matching engine of claim 1 , further comprising at least one non-blocking queue having payload slots sized and aligned to a processor cache-line width, the queue operatively coupled between the at least one core-match unit and one or more other threads and configured to transport order-related messages including incoming orders, order acknowledgments, and trade confirmations, wherein enqueue and dequeue operations that execute when the queue is neither empty nor full proceed without acquiring a mutual-exclusion lock.

15 . The matching engine of claim 1 , further comprising a cache-warming logic configured to prefetch Data Holder Nodes, Price Level Descriptors, or order-related message objects into a processor's cache and to align memory accesses with hardware cache-line boundaries to minimize cache misses.

16 . The matching engine of claim 1 , wherein the at least one core-match unit is configured to execute vector-instruction copy operations implemented as single-instruction-multiple-data (SIMD) instructions to transfer cache-line-aligned blocks of data comprising contiguous sequences of order objects or order-related message objects, during one or more of the following operations:

(a) realignment of order objects within a Data Holder Node;

(b) copying or relocating one or more order objects, one or more Price Level Descriptor objects, or both;

(c) updating price-level metadata including an array of Price Level Pointers or a bitmask that encodes extremal slots; and

(d) moving order-related messages between threads in embodiments that employ inter-thread message movement;

thereby reducing memory-move latency.

17 . The matching engine of claim 5 , wherein the node-capacity policy is parameterized by a node-hit probability model comprising elements selected from the group consisting of:

(a) a parameterized analytic component configured to compute a hit probability as a function of node depth, one or more system parameters, and observed order-flow statistics;

(b) a machine-learning estimator configured to output the hit probability; and combinations thereof; wherein the machine-learning estimator is configured to provide at least one of:

(i) directly output the hit probability from input features;

(ii) estimate one or more of said system parameters for the analytic component;

(iii) provide a residual or calibration to the analytic component; or

(iv) produce an ensemble output with the analytic component.

18 . The matching engine of claim 17 , wherein parameters of the node-hit probability model are updated online by a stochastic-gradient algorithm executed with vector instructions.

19 . The matching engine of claim 1 , wherein:

(a) the at least one priority-tracking bitmask further indicates, for each price level represented in a Data Holder Node, whether the node contains the highest-priority order at that price level and, if present, identifies the particular one of said contiguously addressable slots that holds that order; and

(b) each Price Level Descriptor further stores a reference to the Data Holder Node containing the highest-priority order at that price level.

20 . The matching engine of claim 1 , further comprising an auxiliary hash map separate from the ordered price-level index, the hash map keyed by a price level value and mapping to a reference to the corresponding Price Level Descriptor, the matching engine being configured to update the hash map in synchrony with insertions and removals in the at least one ordered price-level index.

21 . A computer-implemented method for processing electronic trade orders with ultra-low latency in a high-speed matching engine, the method comprising:

(a) allocating, by a memory-management system executed by one or more processors, a plurality of Data Holder Nodes and at least one Price Level Descriptor;

(b) for each Data Holder Node:

(i) assigning a contiguous memory region, each said region physically contiguous or virtually contiguous via page mapping and aligned to cache-line boundaries;

(ii) storing, in contiguously addressable slots within said region, a fixed, predetermined maximum number of order objects, each order object including at least a price value and a quantity value; and

(iii) maintaining at least one priority-tracking bitmask that, for each price level represented in the node, indicates whether the node contains the lowest-priority order at that price level and, if present, identifies the particular one of said contiguously addressable slots that holds that order;

(c) constructing at least one ordered price-level index keyed by a price level value, the index comprising one or more Price Level Descriptors; and, for each Price Level Descriptor, storing:

(i) metadata for the price level; and

(ii) a reference to the Data Holder Node containing the lowest-priority order at that price level;

(d) operating at least one single-threaded core-match unit to:

(i) receive incoming orders;

(ii) match each incoming order against opposite-side resting orders according to a predetermined priority rule;

(iii) execute trades;

(iv) insert any unfilled quantity of the incoming order into one of the Data Holder Nodes; and

(v) update affected Data Holder Nodes, including the at least one priority-tracking bitmask therein, and the at least one ordered price-level index after each execution, insertion, cancellation, modification, or relocation.

22 . The method of claim 21 , wherein step (σ) further comprises maintaining, by the memory-management system, per-core allocation arenas for Data Holder Nodes; and for each core-match unit:

(a) allocating each Data Holder Node used by that core-match unit exclusively from the allocation arena associated with the processor core on which that core-match unit executes; and

(b) freeing each such Data Holder Node back to the same allocation arena, such that allocation and free operations for a given Data Holder Node are performed only via the allocation arena associated with that core-match unit.

23 . The method of claim 21 , further comprising decoupling the at least one core-match unit from one or more other threads by enqueueing incoming orders to, and dequeuing order acknowledgments and trade confirmations from, at least one non-blocking queue having payload slots sized and aligned to a processor cache-line width, the queue operating on an enqueue and dequeue fast path without acquiring a mutual-exclusion lock.

24 . The method of claim 21 , wherein step (σ) further comprises, for each core-match unit, allocating at least one contiguous memory page whose size is selected from a plurality of hardware-supported page sizes in accordance with an estimated memory requirement for that core-match unit, thereby reducing translation-look-aside-buffer misses and limiting unused memory space.

25 . The method of claim 21 , wherein operating the at least one single-threaded core-match unit comprises executing vector-instruction copy operations implemented as single-instruction-multiple-data (SIMD) instructions to transfer cache-line-aligned blocks of data comprising contiguous sequences of order objects or order-related message objects, during one or more of the following operations:

(a) realignment of order objects within a Data Holder Node;

(b) copying or relocating one or more order objects, one or more Price Level Descriptor objects, or both;

(c) updating price-level metadata including an array of Price Level Pointers or a bitmask that encodes extremal slots; and

(d) moving order-related messages between threads in embodiments that employ inter-thread message movement;

thereby reducing memory-move latency.

26 . The method of claim 21 , wherein inserting any unfilled quantity of the incoming order into one of the Data Holder Nodes is performed by an insertion primitive selected from the group consisting of:

(a) Append, which inserts the order immediately after a point of reference; and

(b) Prepend, which inserts the order immediately before a point of reference;

wherein, for each insertion, the point of reference is determined in accordance with the predetermined priority rule.

27 . The method of claim 26 , wherein, upon determining that the selected insertion would exceed a capacity of a target Data Holder Node, the operating core-match unit executes a relocation cascade comprising zero or more hops in a single direction, and wherein:

(a) for an Append insertion, the core-match unit executes a Push Back cascade in which each hop relocates a lowest-priority order from a current Data Holder Node to an immediately succeeding Data Holder Node;

(b) for a Prepend insertion, the core-match unit executes a Push Forward cascade in which each hop relocates a highest-priority order from a current Data Holder Node to an immediately preceding Data Holder Node; and

in either case, at each hop the relocated order is inserted within the destination Data Holder Node at a position that preserves the predetermined priority ordering across all nodes, with a zero-hop case assigning a new Data Holder Node at a cascade boundary to accommodate the order.

28 . The method of claim 21 , wherein the step of updating the at least one priority-tracking bitmask comprises:

(a) setting or clearing a bit at an index derived from a slot identifier of an affected order;

(b) performing the setting or clearing of the bit without iterating over any other order stored in the node; and

(c) completing the update in a time that is independent of a count of orders stored in the node.

29 . The method of claim 21 , wherein the step of updating further comprises:

(c) maintaining the at least one priority-tracking bitmask to further indicate, for each price level represented in the Data Holder Node, whether the node contains the highest-priority order at that price level and, if present, identify the particular one of said contiguous addressable slots that holds that order; and

(d) storing, in each Price Level Descriptor, a reference to the Data Holder Node containing the highest-priority order at that price level.

30 . A non-transitory computer-readable storage medium storing computer-executable instructions that, when executed by one or more processors, cause the processors to perform operations for processing electronic trade orders with ultra-low latency in a high-speed matching engine, the operations comprising:

(a) allocating, by a memory-management system executed by one or more processors, a plurality of Data Holder Nodes and at least one Price Level Descriptor;

(b) for each Data Holder Node:

(i) assigning a contiguous memory region, each said region physically contiguous or virtually contiguous via page mapping and aligned to cache-line boundaries;

(ii) storing, in contiguously addressable slots within said region, a fixed, predetermined maximum number of order objects, each order object including at least a price value and a quantity value; and

(iii) maintaining at least one priority-tracking bitmask that, for each price level represented in the node, indicates whether the node contains the lowest-priority order at that price level and, if present, identifies the particular one of said contiguously addressable slots that holds that order;

(c) constructing at least one ordered price-level index keyed by a price level value, the index comprising one or more Price Level Descriptors; and, for each Price Level Descriptor, storing:

(i) metadata for the price level; and

(ii) a reference to the Data Holder Node containing the lowest-priority order at that price level; and

(d) operating at least one single-threaded core-match unit to:

(i) receive incoming orders;

(ii) match each incoming order against opposite-side resting orders according to a predetermined priority rule;

(iii) execute trades;

(iv) insert any unfilled quantity of the incoming order into one of the Data Holder Nodes; and

(v) update affected Data Holder Nodes, including the at least one priority-tracking bitmask therein, and the at least one ordered price-level index after each execution, insertion, cancellation, modification, or relocation.

Continuity (1)

References Cited (50)