JP6464348B2

JP6464348B2 - 理想レイテンシフロア

Info

Publication number: JP6464348B2
Application number: JP2017525504A
Authority: JP
Inventors: ポールメルトン，ヘイデン
Original assignee: トムソンロイターズ（ジーアールシー）インコーポレイテッド
Priority date: 2014-07-25
Filing date: 2014-12-30
Publication date: 2019-02-06
Anticipated expiration: 2034-12-30
Also published as: CA2956079C; CA2956079A1; WO2016018453A1; EP3186769A1; EP3186769A4; SG11201700613XA; AU2014402295A1; JP2017522683A; CN106688008B; CN106688008A; AU2018220100A1

Description

関連出願の相互参照
本出願は、2014年7月25日に申請され“An Ideal Latency Floor”と題された米国仮特許出願第62/029,042号と、“Ideal Latency Floor”と題された米国非仮出願第14/533,543号とに対する優先を主張し、上記の内容はその全体を本明細書において参照により援用される。

本発明は、電子取引現場にレイテンシフロア（時にランダム化とも呼ばれる）を提供するシステム及び方法に関する。

多数の電子取引現場が世界中で運用されている。こうした大規模な電子取引現場の多くは、注文の処理に関して、時間優先ルールで動作している。換言すると、上記現場は、市場参加者により送信されるメッセージ（例えば、注文、取り消し、差し替え）を、これらが受信される時間的順序で処理する。このため、こうした現場において、「最も速い」市場参加者がその活動において価格形成及び価格受容の双方の点で有利にされ、このことは、Farmer，J.D.、Skouras，S.、Review of the benefits of a continuous market vs. randomized stop auctions and of alternative Priority Rules (policy options 7 and 12)、Paper for UK Govt Office for Science、2012年3月28日に記載されるとおりであり、上記の内容はその全体を本明細書において参照により援用される。上記の文脈において、「最も速い」は、何らかの刺激（しばしば、市場データアップデート）に応答して最小量の時間後に、電子取引現場に注文（又は、他のメッセージ）を送信できることを意味する。

過去の数年において、高頻度又はアルゴリズム取引（high frequency or algorithmic trading）（本明細書において、単に“ＨＦＴ”）に関与する市場参加者が、上記電子取引現場で取引される取引ボリュームの増加する割合を担っている。ＨＦＴが（例えば、よりタイトなスプレッドをとおして）向上した流動性の提供を結果としてもたらしていると特定の調査が示しており、このことは、Jones，CM.、What do we know about high-frequency trading?、Working Paper，Columbia Business School、Version 3.4: 2013年3月20日に記載されるとおりであり、上記の内容はその全体を本明細書において参照により援用されるが、他の調査がＨＦＴについてのいくつかの否定的な影響を識別しており、このことは、Budish，E.、Cramton，P.、Shim，J.、The High-Frequency Trading Arms Race: Frequent Batch Auctions as a Market Design Response、Working Paper、2013年12月23日に記載されるとおりであり、上記の内容はその全体を本明細書において参照により援用される。

取引現場のオペレータと、こうした取引現場における市場参加者であるその顧客とは、ＨＦＴの隆盛により大幅に影響されている。いくらかの市場参加者は、最も速い参加者に遅れずついていくのに必要とされる最先端テクノロジーにおいて、進行中の、重要な、及び、時に運用的にリスクのある投資をする余裕をもはや有することができないと述べている。上記のことの結果、メッセージの処理に対して時間優先ルールを有する多くの現場において、価格形成及び受容における競争力の決定において結果的に速度が役割を果たす場合に、効果的に競争することができる参加者はより少なくなり、現場における全体としての競争はＨＦＴによって外見的には低減される。このことは、ほぼ間違くなく「悪い」ことであり、なぜならば、健全な市場は、「包括性」をとおして、すなわち、より狭い組でなくより広い組の参加者が価格形成及び受容において競争することを可能にすることにより、競争を促すものであり得るからである。

電子取引現場のオペレータはオペレータ自身、ＨＦＴの隆盛により影響されている。市場参加者がより速くなるとき、現場におけるレイテンシの変動のより小さいことが、価格を形成し又は受容する能力においていずれの参加者が最も成功するかの決定において、ますます重要になってきている。コンピュータハードウェア及びソフトウェアの性質（並びに、究極的には物理学の法則）は、電子取引現場におけるすべてのレイテンシ変動を完全に消去することを不可能にするが、市場オペレータがより小さくなりつつあるレイテンシ変動を監視し及び制御することは、ますます困難及び高価になっている。さらに、市場オペレータは、自身の現場が「公正」であること、すなわち、現場におけるレイテンシ「ジッタ」の特定の兆候の結果として価格形成及び受容活動において１人の参加者がシステム的に有利にされない（又は、不利にされない）ことを確保するために、上記のようにすることを義務付けられる。

レイテンシフロア（Latency Floor）（さらに、ランダム化（Randomization）とも呼ばれ、このことは、Harris，L.、What to Do about High-Frequency Trading、Financial Analysts Journal、2013年3月/4月、Vol.69、No.2: 6-9、及び、Szalay，E.、Life in the slow lane、Automated Trader Magazine Issue 30 Q3 2013に記載されるとおりであり、上記の双方はその全体を本明細書において参照により援用される）は、電子取引現場が実装する時間優先ルールに対する限られた例外と考えることができる。中央指値注文ブック（central limit order book）（ＣＬＯＢ）を運用する現場でレイテンシフロアメカニズムを展開するとその結果、短い時間スケールでは、メッセージは一般にＣＬＯＢに対して、該メッセージが受信される時間的順序において処理されないことになる（上記処理は、例えば、ＣＬＯＢに挿入される、ＣＬＯＢ内で他の注文に対してマッチされる、ＣＬＯＢから削除される等）。しかしながら、より長い時間スケールでは、より早く受信されたメッセージが依然として、より後で受信されるメッセージの前にＣＬＯＢに対して処理される。このことが暗に示すのは、短い時間スケールを長い時間スケールから区別するレイテンシフロアに関連付けられた時間パラメータが存在することである。上記の同じ時間パラメータは時にレイテンシフロアの「値」と呼ばれる。

レイテンシフロアメカニズムは、フロアの値の範囲内に受信されたメッセージを、これらメッセージがＣＬＯＢに到達する前にまとめて「バッチにする（batching）」ことと、バッチ内のメッセージのリストをシャッフルしてリストに新しい（少なくともいくらか）ランダムな順序付けを与えることと、それから最後、これらメッセージをその新しいランダムな順序付けに従ってＣＬＯＢに対して処理することとによって機能することができる。こうして、メッセージがＣＬＯＢに対して処理される順序は、メッセージが受信された時間的順序によって完全に決定されるわけではなくなる。代わって、他のこうしたメカニズムが、各メッセージが受信されたときに該メッセージがＣＬＯＢに対して処理され得る前に上記メッセージに対して０と（フロア）値との間のランダムな遅延を追加することと、これにより新しいさらなるランダムなメッセージの順序付けをさらに引き起こすこととによって機能してもよく、このことは、Harris，L.、What to Do about High-Frequency Trading、 Financial Analysts Journal、2013年3月/4月、Vol.69、No.2: 6-9に記載されるとおりである。

従来のレイテンシフロアメカニズムは、フロアの値より速く応答できることの利点を完全に消去してはいないことが観察される。換言すると、従来のレイテンシフロアメカニズムを実装する電子取引現場には、フロアの値より少ない時間内に（すなわち、より速く）応答することができ、実際に絶対的に最も速い上記現場の市場参加者に対して、インセンティブが依然として存在する。例えば、１つのこうした従来メカニズムにおいて、フロアの値が２ミリ秒（ｍｓ）であり、より速い参加者がより遅い参加者の１．８ｍｓ前に応答する場合、より速い参加者のメッセージは、より遅い参加者のメッセージの前にＣＬＯＢに対して処理されることについて、９０％より大きい機会を依然として有することになる。結果として、従来のレイテンシフロアを用いると、メッセージの厳密な時間優先処理を用いるよりもより少ない度合ではあるが、絶対的な最も高速の参加者であるためにテクノロジーに投資するインセンティブが依然として存在し、市場オペレータは依然として、増加した精度レベルで現場レイテンシを監視し及び制御する必要がある。上記の問題及び他の難点が、従来のレイテンシフロアにより経験される。

上記及び他の難点に対処する本発明は、電子取引現場において自然に発生し、該現場における市場参加者間の価格形成及び受容活動に属する個々の「レース」を、検出し及び区別するシステム及び方法に関する。現場で取引する商品についてＣＬＯＢを運用する該現場には、２つのタイプの価格受容レースがあり、すなわち、ビッドを受容する（又は、同等に「ヒットする（hit）」、又は「仕掛ける（aggress）」、又は「上げる（lift）」）レース、及び、オファーを受容するレースである。同様に、こうした現場には、価格形成レースがあり、価格形成レースの各タイプは、形成者注文のサイド（買い又は売り）と指し値とのペアにより一意に識別されることができる。本発明の重要な一特性（本明細書において、「理想レイテンシフロア」）は、任意の所与のレースのインスタンスにおいて、そのレースにおいて競争し、フロアの値の範囲内に応答することができるすべての参加者が、レースに勝つ実質的に等しい機会を全面的に有することである。

高いレベルにおいて、理想レイテンシフロアは、（１）特定タイプのレースにおける第１のメッセージを、これが現場により受信される時間に検出することと、（２）上記第１のメッセージの検出においてタイマを開始することと、（３）第１のメッセージを、同様に上記レースタイプに属し、タイマが所定値（典型的に、フロアの値）に到達する前に現場により受信される他のメッセージと一緒に、「バッチにする」ことと、（４）バッチ内のメッセージを参加者（又は、他の同様のエンティティ）単位でグループ化し、そうすることにおいて、レースに関与した参加者のリストを作成することと、（５）参加者の上記リストをシャッフルしてランダムな順序付けに達することと、（６）上記のシャッフルされた参加者のリストを、所定の「排出」ストラテジに対する入力として使用することであって、上記ストラテジは、レースのタイマがその値に到達したとき、レースタイプを所与として参加者に対して公正である仕方及びシーケンスにおいてＣＬＯＢに対して処理するようにバッチからメッセージを削除する、ことと、によって機能する。所与の商品について、複数のレースが任意の所与の時間に「アクティブ」であることがあり、上記レースの各々がその独自のメッセージセット、その独自のバッチ、及びその独自のタイマなどを有し、レースは、上記で明記されたステップ（１）乃至（６）において、上記商品における他のアクティブなレースについてのこれらステップの処理とは独立して、処理されることができる。

一実装において、システムは、構成可能なパラメータに基づいて、レースのすべてのタイプ又はレースのタイプのサブセットについて、理想レイテンシフロアを実施するかどうかを決定することができる。例えば、システムを用いて、ユーザ、例えば市場オペレータなどが、価格受容者レースのみが理想レイテンシフロアメカニズムの影響下であるべきであり、他タイプの市場レース、例えば価格形成者レースなどはそうあるべきでないと指定することができる。上記構成において、受容者レースにおけるメッセージは、バッチ化及び遅延の影響下であることになり、一方、形成者レースに属するメッセージは、ＣＬＯＢに対して「リアルタイムで」、該メッセージが受信された時間的順序付けにおいて（あるいは、現場がレイテンシフロアのない場合にこれらメッセージを通常処理するであろう仕方において）、処理される見込みがあることになる。こうして、ユーザは、市場レースのうちいずれのレースが理想レイテンシフロアメカニズムの影響下であることになるかを定義することができる。

一実装において、システムは、構成可能なパラメータに基づいて、いずれの特定メッセージがバッチ期間をトリガする（又は同等に開始する、あるいはその中の第１のメッセージである）ことができるかを決定することができる。例えば、システムを用いて、ユーザ、例えば市場オペレータなどが、ブックのトップを「横断する」注文（例えば、現場における最良の（最も低い）普及しているアスク価格より大きいか又は等しい指し値を有する買い注文）がバッチ期間をトリガし、ブックの反対サイドにおいてブックのトップに存在する注文の取り消し要求もトリガすると双方を指定することができる。あるいは、現場オペレータは、受容者レースについてバッチ期間の開始をトリガするメッセージタイプとして上記取り消しを除外することを選び、受容者注文のみが上記バッチ化をトリガすることを可能にしてもよい。こうして、ユーザは、理想レイテンシフロアメカニズムにおいていずれのメッセージがいずれのタイプのレースをトリガするかを定義することができる。

一実装において、及び、上記のバッチのトリガから独立して、システムは、バッチが最初に作成された後（すなわち、少なくとも１つのメッセージがバッチ内に置かれた後）、いずれの特定メッセージがバッチに含まれることに適格であるかを決定することができる。例えば、システムを用いて、ユーザ、例えば市場オペレータなどが、バッチが作成された後、そのタイマがその値に到達する前に限り、売り注文における取り消しが買うための受容者レースのバッチに含まれることになると指定することができる。別法として、ユーザは、こうした取り消しが買うための受容者レースに決して出現しなくてよいと指定することができる。こうして、ユーザは、理想レイテンシフロアメカニズムにおいてバッチがトリガされた後（すなわち、バッチが作成された後だが、そのタイマが値に到達する前）、いずれのメッセージがバッチに含まれるかを定義することができる。

一実装において、システムは、バッチ期間の間に受信されたメッセージを、これらメッセージを生成した市場参加者（又は、同様のエンティティ）単位でグループ化することができる。注文の各グループの範囲内で、システムは、グループの中のメッセージが受信された時間的順序付けを保有することができる。例えば、バッチ期間の間に第１の市場参加者から受信されたすべてのメッセージが、これらが受信された時間的順序において第１の市場参加者からの第１のメッセージセットに一緒にグループ化されることができる。同様に、バッチ期間の間に第２の市場参加者から受信されたすべてのメッセージが、これらが受信された時間的順序において第２の市場参加者からの第２のメッセージセットに一緒にグループ化されることができ、以下同様である。上記実装において、システムは、注文に関連付けられた市場参加者のリストを作成し、この市場参加者のリストをシャッフルすることができ、そのため、結果として生じるシャッフルされた市場参加者のリストにおいて、各市場参加者は、シャッフルされたリスト内の各位置に出現する等しい確率を有することになる。システムは、それから、下記で説明されるとおり、市場参加者のシャッフルされたリストの順序付けとメッセージのグループの順序付けとを使用して、ＣＬＯＢに対して処理するメッセージを「排出する」ことを開始できる。こうして、所与の市場参加者が複数のメッセージを提出することによって利益を得ることはできない。

メッセージが市場参加者に基づいてグループ化される実装において、システムは、複数の区別可能なストラテジを採用して、ＣＬＯＢに対して処理するためにバッチからメッセージを排出することができる。１つのこうしたストラテジにおいて、バッチ内に残されたメッセージがなくなるまで、参加者のシャッフルされたリストは、ＣＬＯＢに対して処理するために各参加者の１つのメッセージを削除し、その後、バッチ内に残っているメッセージを有する次の参加者に進むことを、繰り返し反復される。別のこうしたストラテジにおいて、バッチ内の参加者のリストは１回反復されることができ、一参加者のメッセージすべてがＣＬＯＢに対して処理するためにバッチから削除され、その後、次の参加者に進む。さらに別のこうしたストラテジにおいて、バッチ内に出現する注文は、より小さい「子」注文に分割される影響下にあり、これにおいて、子注文の数量の和はバッチ内の「親」注文の合計数量に等しく、（親注文でなく）子注文がＣＬＯＢに対して処理される。有利なことに、上記ストラテジにおいて、各参加者により提出されるすべての注文にわたる合計数量のうちの少量が、ラウンドロビン方式でＣＬＯＢに対して処理され、これにより、特定数量のための複数の小さい注文か又はその同じ数量のための単一の大きい注文かのいずれかを提出することによって他の排出ストラテジにおいて参加者が得る可能性がある利点を、消去することができる。

本明細書に開示されるシステム及び／又は方法についての上記及び他の目的、特徴、及び特性と、構造の関連要素の動作方法及び機能、並びに製造の部品の組み合わせ及び経済性とが、下記の説明と別記の請求項とを添付図面を参照して検討するとより明らかになるであろう。上記図面のすべてが本明細書の一部を形成し、様々な図面において、同様の参照番号は対応するパートを指定する。しかしながら、図面は単に例示及び説明の目的のものであり、本発明の限定の定義としては意図されないことが明白に理解されるべきである。本明細書及び請求項において使用されるとき、単数形式の“ａ”、“ａｎ”、及び“ｔｈｅ”は、文脈が他の方法で明示的に指図しない限り、複数の指示物を含む。

本発明の一実装に従う、理想レイテンシフロアメカニズムを提供するシステムを例示する。本発明の一実装に従う、理想レイテンシフロアメカニズムを提供する処理の例示的な図を表す。本発明の一実装に従う、理想レイテンシフロアメカニズムを提供する処理の処理フロー図を表す。本発明の一実装に従う、理想レイテンシフロアメカニズムなどの遅延メカニズムの様々な状態を例示する例示的な図を表す。

図１は、本発明の一実装に従う、理想レイテンシフロアメカニズム（ideal latency floor mechanism）を提供するシステム１００を例示している。システム１００は、本発明の一実装に従い、市場レースを容易にすることができ、上記市場レースにおいて、レース内で（例えば、価格を形成し又は受容するために選ぶことにより）競争し、レイテンシフロアの値の範囲内で応答することができる市場参加者が、各市場参加者が市場レースに勝つことの等しい確率を有するバッチに追加される。本明細書において使用されるとき、用語「市場レース（market race）」及び「レース（race）」は、全体をとおして交換可能に使用され得る。同様に、用語「市場参加者」及び「参加者」は、全体をとおして交換可能に使用され得る。さらに、用語の中央指値注文ブック（又は、ＣＬＯＢ）は、全体をとおして使用されるとき、限定であることは意図されず、実際、理想レイテンシフロアメカニズムは、現場（venue）により実装される他のこうした構造（例えば、売り注文と買い注文をマッチングする目的に使用される構造、現場で取引される商品の供給と需要とのビューを提供することに使用される構造など）に等しく適用されてもよい。

本明細書において全体をとおして使用される様々な例が、理想レイテンシフロアメカニズムの例を参照することがあるが、システム１００の他の使用及び実装が企図され、本明細書における開示を用いた当業者に明らかになるであろう。システム機能のいくつかの高レベルの概要を説明したが、次に、上記及び他の機能を容易にする様々なシステムコンポーネントに注意が向けられる。

システムコンポーネント
システム１００は、コンピュータシステム１０４、１つ以上のデータベース１３２、１つ以上の市場参加者１４２、電子注文ブック１４４、及び／又は他のコンポーネントを含み得る。上記及び他の機能を容易にするために、コンピュータシステム１０４は、１つ以上のコンピューティング装置１１０を含んでもよい。各コンピューティング装置１１０は、１つ以上のプロセッサ１１２、１つ以上の記憶装置１１４、及び／又は他のコンポーネントを含み得る。プロセッサ１１２は、１つ以上のコンピュータプログラム命令によりプログラムされることができ、上記コンピュータプログラム命令は、記憶装置１１４に記憶されることができる。１つ以上のコンピュータプログラム命令は、制限なく、理想レイテンシフロアアプリケーション１２０を含んでもよい。

理想レイテンシフロアメカニズム

理想レイテンシフロアアプリケーション１２０は、理想レイテンシフロアメカニズムを実行することができ、上記メカニズムにおいて、レース内で（例えば、価格を形成し又は受容するために選ぶことによって）競争し、レイテンシフロアの値の範囲内で応答することができる市場参加者１４２は、各市場参加者が市場レースに勝つことの等しい確率を有するバッチに追加される。簡便さのため、理想レイテンシフロアメカニズムが、動作を実行するものとして説明されるが、実際には、理想レイテンシフロアアプリケーション１２０が、１つ以上のプロセッサ１１２（及び、したがってコンピュータシステム１０４）をプログラムして動作を実行する。

一実装において、理想レイテンシフロアメカニズムは、コンピュータネットワークからメッセージを受信するソケットと、こうしたメッセージが最終的に処理されるためのＣＬＯＢ１４４との間に存在することができる。メッセージがＣＬＯＢ１４４に対して処理される前、及び、該メッセージがソケットから引き抜かれた後、このメッセージは理想レイテンシフロアメカニズムによって処理されることができる。市場参加者１４２は、市場データアップデート内のＣＬＯＢ１４４の状態のみ見ることができ、理想レイテンシフロアメカニズム内の任意のバッチに含まれるメッセージを見ることはできない。

レースタイプ、及び、レースタイプが理想レイテンシフロアメカニズムにより扱われる方法

レースは２つのカテゴリ、すなわち、形成者（maker）レースと受容者（taker）レースとに一般に該当し得る。個々の受容者レースは、注文のサイドにより一意に識別されることができ、事実、注文価格は、ブックを「横断する（crosses）」（すなわち、価格に基づいてＣＬＯＢ１４４の現在又は直近の状態に対して満たす（fill）ことになる）。例えば、買い注文が、その指し値（limit price）がＣＬＯＢ内の最良の（最も低く価格設定された）普及している売り注文（オファー）より大きいか又は等しい場合、「ブックを横断する」と言われることがある。個々の形成者レースは、注文のサイドと注文の指し値とのペアによって一意に識別されることができる。形成者レースにおける注文は、ブックを横断しない（すなわち、価格と場合により信用（credit）とに基づいて、ＣＬＯＢ１４４の現在又は直近の状態において存在する反対サイドの注文に対してマッチされることがない）。

表１は、レースタイプと、理想レイテンシフロアメカニズムがレースタイプを如何にして扱うことができるかとの、非限定的な例を示す。下記の表は、本開示の態様を単に例示するために含まれる。

構成パラメータ

表２は、所与のレースタイプが本明細書に説明される理想レイテンシフロアメカニズムの影響下にあることになるかどうかの観点、構成可能パラメータ、及び概略説明の、非限定的な例を示す。例えば、理想レイテンシフロアメカニズムは、下記の表２に示されるとおり、下記の観点に沿って商品ごとに構成可能であってもよい。下記の表は、本開示の態様を単に例示するために含まれる。

理想レイテンシフロアメカニズムの動作

理想レイテンシフロアメカニズムは、様々なタイプの市場レース（例えば、表１に記載されるものなど）において、様々な構成可能パラメータ（例えば、表２に記載されるものなど）に基づいて動作することができる。動作において、理想レイテンシフロアメカニズムは、市場レース内の第１の注文を検出し、その特定の市場レースのための「バッチ（batch）」を作成することができる。理想レイテンシフロアメカニズムは、タイマを開始することができ、該タイマは、満了され又はその他の方法で特定値に到達するときに、バッチの終わりを示す。同じ市場レースについてさらなる注文が検出されるとき、バッチのタイマが満了する前は、さらなる注文はバッチ内に置かれる。バッチのタイマが満了したとき、注文はシャッフルされ、シャッフリングから結果として生じる順序付けが、注文がＣＬＯＢ１４４に対して処理される順序である。

理想レイテンシフロアメカニズムの一実装の疑似コード及び付随説明が、具体的にレース内の第１の注文を検出することとこうした注文をタイマが満了する時間などまでバッチにすること（batching）とに関して、限定でなく例示として下記で説明される。理想レイテンシフロアメカニズムの他の実装が、本明細書において提供される開示に基づいて同様に使用されてもよい。

1: Qを、所与の商品に対して到来する注文のキューとする;
2: 各注文を、これら注文が所与の商品における市場参加者から受信される時間的順序で、Qの最後の位置に追加する;
3: Cを、所与の商品のためのCLOBとする;
4: Mを、キーとしての［注文サイド，注文価格］のペアと所与の商品のための値としての注文のリストとを有するマップとする
5: Fを、レイテンシフロアの値とする。例えば、F=2ms
6: while (true) {
7: for (Entry E in M) {
8: Orders os = E.getValue();
9: Order o = os.getFirst();
10: if (current_time() >= o.getTimestamp() + F) {
11: shuffleAndProcess (E.getKey(),os,C);
12: M.remove(E.getKey());
13: }
14: }
15: for (int i = Q.size(); i>0; i--) {
16: Order o = Q.removeFirst();
17: Price p = o.getPrice(); //注文の指し値
18: Side s = o.getSide(); //サイドは一般に「買い(buy)」又は「売り(sell)」である
19: if (p >= C.getBestAskPrice() && s is buy) {
20: p = +infinity;
21: } else if (p <= C.getBestBidPrice() && s is sell) {
22: p = -infinity;
23: }
24: Orders os = M.getOrPutEmptyListIfKeyAbsent([s,p]);
25: os.addLast(o);
26: }
27: }

行１〜３は、コード内に説明されるとおりであるが、さらに詳細に述べると、行１のキューＱは、所与の商品に対して市場参加者により提出される（submitted）注文によって断続的に補充される。行２は、注文がキューの終わりに置かれることを示し、ゆえに、キューの順序付けは、注文が受信される時間的順序を反映する。行３は、所与の商品のためのＣＬＯＢＣを定義する。ＣＬＯＢは、買い及び売り形成者注文を一般に含み、ＣＬＯＢが含む注文は、ＣＬＯＢが関係する商品についてメッセージを市場参加者が毎回提出するたび一般に変化する。

行４は、マップＭを定義し、マップＭは、キーを値にマッピングするための標準の、広く使用されるデータ構造である。マップのキーは、各レースタイプを一意に識別し、マップの値は、市場レースに参加している注文である。

行５は、フロアの値Ｆを宣言し、このＦは、何らかの時間の単位、例えばミリ秒（ｍｓ）において、レイテンシフロアの長さを定義する整数定数であり得る。

行６は、「無限の」whileループであり、このループは、電子取引現場が動作している（注文／メッセージを受け入れている）間、実行される。

行７〜１４は、アクティブな市場レース内でタイマが鳴った（tolled）（例えば、満了した）とき、注文のバッチを排出すること（draining）に関する。

行７は、forループであり、このループは、マップ内のすべてのエントリＥにわたり反復する。エントリは、マップ内のキーと値とのペアである。

行８は、所与のレースにおける値、すなわち、注文のリストｏｓを返す。

行９は、所与のレースにおける第１の注文ｏ、すなわち、タイマを開始させる注文を取得するが、これをリストｏｓから削除することはしない。

行１０は、市場レースについてタイマが鳴ったかを、第１の注文が受信されたときのタイムスタンプ（o.getTimestamp()）とコンピュータのクロック又は他の時間ソースにより決定されるとおりの現在のウォールクロックタイム（current_time()）とを比較することによって、確かめるように確認する。現在の時間が、注文のタイプスタンププラスフロアの値Ｆの後である場合、タイマは実際鳴っており、注文はシャッフルされ、ＣＬＯＢに対して処理されるべきである。注文のリストｏｓのシャッフリングの正確な実装は疑似コード内に示されておらず、ＣＬＯＢＣに対する注文の処理も示されていないが、行１１におけるメソッドshuffleAndProcess(…)の本体が、上記のシャッフリング及び処理を実行することになる。shuffleAndProcess(…)メソッドが動作する具体的な仕方が、下記で「バッチのシャッフリング及びシャッフルされたバッチからの注文の処理」と題されたセクションにおいて説明されるとおり実装されることができる。

行１２において、市場レースのためのエントリ（キー及び値の双方）が削除され、ゆえに、上記マップの値における注文は、Ｃに対して２回以上処理されない。行１２は、アクティブな市場レース、すなわちタイマが鳴っていない市場レースのみが、外側のwhileループの１回の反復からその次へとＭの中にとどまることをさらに確保する。

行１５〜２６は、所与のタイプの市場レースの開始を検出し、市場レースがすでに始まっていた場合にはその市場レースのリスト又は注文のバッチに注文を追加する。

行１５はforループであり、このループは、外側のwhileループの最後の反復から後に受信されたすべての注文が処理される（排出される）ことを確保する。

行１６は、現在Ｑ内にある第１の注文を削除する。

行１７及び１８は、注文の価格及びサイドを獲得する。上記の例について、すべての注文が指し値を有することと（ここでは、定義により指し値を有さないいわゆる「成り行き注文（market orders）」は、ないと仮定する）、すべての注文が買い又は売りのいずれかである１つのサイドだけ有することとを仮定する。買うための「成り行き注文」が＋無限大（+infinity）の指し値を有するとみなされ、売るための「成り行き注文」が−無限大（-infinity）の指し値を有するとみなされる場合、上記コードは、指値注文だけでなく、成り行き注文も備えて書かれたものとして機能することになる。

行１９〜２３は、市場の外から流動性を「仕掛ける（aggress）」又は「受容する（take）」レースを扱う。この行範囲の中のＣに対するメソッドgetBestBidPrice()及びgetBestAskPrice()は、これらメソッドがコールされる瞬間にＣＬＯＢ内に存在する最も高く価格設定された買い注文の価格と上記ブック内に存在する最も低く価格設定されたアスク注文の価格とを返す。市場を受容し又は仕掛けるためのレース内の注文は、そのレース内で競争するために互いと同じ指し値を有する必要がないため、こうした注文の指し値は、ｐ内に記憶されるとき、代わって２つの特別な値＋無限大及び−無限大にそれぞれ調整される。この調整は、キーが、アスクブックを仕掛けるためにレースするすべての注文について同じであり、ビッドブックを仕掛けるためにレースするすべての注文について別個であることを確保する。最大で、アクティブな１つの買い受容者レースと１つの売り受容者レースとが存在することになる。

行２４において、レースに参加している注文のリストが、M.getOrPutEmptyListIfKeyAbsent([s,p])に対するコールを介して取得される。getOrPutEmptyListstIfKeyAbsent()の実装は示されていないが、キー［ｓ，ｐ］がマップ内に存在する場合、その値は既に初期化されており、レースにおける注文のリストｏｓである上記値が返されることが理解されるべきである。そうでない場合、注文の新しい空のリストｏｓが、Ｍに対する上記メソッドにより上記キー［ｓ，ｐ］のための値として作成され、その後、第１の注文が、行２５で上記空のリストに追加されることになる。

行２５は、注文ｏをリストｏｓの終わりに追加する。

行２７は、外側のwhileループを閉じる。

疑いを避けるために、上記Ｍ内のキーは、各レースタイプを一意に識別することができる。代替的な一実装において、市場オペレータは、特定タイプのレース、例えば価格を受容するレースのみなどについて、理想レイテンシフロアを確立することに焦点を合わせてもよい。上記の受容者のみのレースの実装において、マップＭは、一挙に最大で２つのキー（ビッドを仕掛けるためにレースする注文、及び、オファーを仕掛けるためにレースする注文）のみ含むことができ、すべての他の注文は、リアルタイムで、又は、現場が理想レイテンシフロアのないときに動作することになる仕方で、ＣＬＯＢに対して処理されることができる。このことは、下記に示されるコードセクション１５〜２６のわずかな変更によってすべて達成されることができる。このコードにおいて、C.process(o)は、本文献において第１の疑似コードリスト内に説明されるのと同じ意味を有する。“continue”は、ループに関する、Ｊａｖａ（登録商標）プログラミング言語と同じセマンティクスのキーワードである。行２５は、注文ｏをリストｏｓの終わりに追加する。

15: for (int i = Q.size(); i>0; i--) {
16: Order o = Q.removeFirst();
17: Price p = o.getPrice(); //注文の指し値
18: Side s = o.getSide(); //サイドは一般に「買い(buy)」又は「売り(sell)」である
19: if (p >= C.getBestAskPrice() && s is buy) {
20: p = +infinity;
21: } else if (p <= C.getBestBidPrice() && s is sell) {
22: p = -infinity;
23: } else {
C.process(o);
continue;
}
24: Orders os = M.getOrPutEmptyListIfKeyAbsent([s,p]);
25: os.addLast (o);
26: }

バッチのシャッフリング及びシャッフルされたバッチからの注文の処理

理想レイテンシフロアメカニズムが所与のレースにおける注文の「バッチ」をシャッフルし得る仕方は、下記のとおりである。理想レイテンシフロアメカニズムは、市場参加者１４２による注文を（例えば、注文を提出した市場参加者に基づいて）グループ化することができる。各市場参加者の注文が受信される時間的順序付けが、保有されることができる。理想レイテンシフロアメカニズムは、バッチ内の注文に関連付けられた市場参加者のリストを生成することができる。理想レイテンシフロアメカニズムは、それから、バッチ内の市場参加者のリストをシャッフルすることができ、したがって、各市場参加者は、市場参加者のリスト内の各位置に出現することの等しい機会を有する。それから、参加者のリストにわたり繰り返し反復し、一度に１つの参加者から１つの注文を削除することによってか、又は、１回だけ参加者のリスト全体にわたり反復し、次へと移る前に各参加者からのすべてのメッセージを削除する（及び、ＣＬＯＢに対して処理する）ことによってかのいずれかで、注文がＣＬＯＢ１４４に対する処理のためにバッチから排出される。

ラウンドロビン排出

ラウンドロビン排出動作において、システムは、バッチにされた（batched）市場参加者の中から勝ちの市場参加者をランダムに選択し、その第１の注文（例えば、勝った市場参加者から受信された第１の注文）を可能な程度まで満たすことができる。さらなる注文が満たされるよう利用可能である場合、システムは、バッチにされた市場参加者の中から次の市場参加者（例えば、選択されるべき第２の市場参加者）をランダムに選択し、その第１の注文（例えば、上記次の市場参加者から受信された第１の注文）を可能な程度まで満たすことができ、以下同様である。いったん最後の市場参加者が選択されると、システムは、各市場参加者の第２の注文について処理を繰り返すことができ、すべての注文が満たされるか、又は満たされるよう利用可能なさらなる注文がなくなるまで、以下同様である。当然ながら、市場参加者のランダム選択は、個々に、又は市場参加者のランダムに割り当てられた順序付けに基づいて、行われてもよい。

理想レイテンシフロアアプリケーション１２０により実行されるラウンドロビン排出動作の一実装の疑似コード及び付随説明が、限定でなく例示として下記で説明される。排出動作の他の実装が、本明細書において提供される開示に基づいて同様に使用されてもよい。

1: Map<Participant,LinkedList<Order>> m = … //mはバッチ内の参加者の注文を含む
2: LinkedList<Participant> ps = new
LinkedList<Participant> (m.keySet());
3: Collections.shuffle(ps);
4: int remainingOrders;
5: do {
6: remainingOrders = 0;
7: for (Participant p : ps) {
8: LinkedList<Order> os = m.get(p);
9: if (os.size() > 0) {
10: Order o = os.removeFirst();
11: processAgainstClob(o);
12: remainingOrders += os.size();
13: }
14: }
15: } while (remainingOrders > 0);

行１は、バッチ（レース）の影響下にあった注文（メッセージ）に対する市場参加者１４２のマップである。

行２は、マップ内のキーである参加者のコピーを作る。

行３は、あらゆる参加者がリスト内の各位置に出現する実質的に等しい機会を有するように、参加者の（順序付けられた）リストをシャッフルする。

行４は、残りの注文のカウントを保持することになる変数であり、do-whileループの各反復が行５で始まる。

行６は、残りの注文の数をゼロに設定する。

行７で始まるforループは、ラウンドロビン排出動作に参加者のリストにわたり反復させ、各反復において各参加者の注文リストから１つの注文（又は、同等にメッセージ）を削除する。各注文が削除されるとき、この注文は行１１でＣＬＯＢに対して処理される。上記参加者の注文リスト内に残っている（すなわち、まだ処理されていない）注文の数が取得され、行１２において残りの注文の合計数を増分する。

do-whileループの終了条件は、注文が残っていないこと（すなわち、すべての注文がＣＬＯＢに対して処理されたこと）である。非限定的な一例が、限定でなく例示として提供される。バッチが、参加者Ａからの注文ａ１、ａ２、及びａ３と、参加者Ｂからの注文ｂ１と、参加者Ｃからの注文ｃ１及びｃ２とを含む場合、マップは、下記のとおり表現されることができ、これにおいて、“->”はキーから値へのマッピングを示し、“;”はキーと値とのペアを区切り、“{”及び“}”はマップの内容の始めと終わりとの境界をそれぞれ画定する：
{A->[a1,a2,a3];B->[b1];C->[c1,c2]}

マップのキー（すなわち、参加者）のシャッフリングが、順序付けられたリスト［Ｃ，Ａ，Ｂ］を結果としてもたらす場合、メッセージがＣＬＯＢに対して処理されることになる順序は、下記のとおりである：
[c1,a1,b1,c2,a2,a3]

参加者ごと一挙排出

参加者ごと一挙（participant-at-once）排出動作において、システムは、バッチにされた市場参加者の中から勝ちの市場参加者をランダムに選択し、その注文のすべてを可能な程度まで満たすことができる。さらなる注文が満たされるよう利用可能である場合、システムは、バッチにされた市場参加者の中から次の市場参加者（例えば、選択されるべき第２の市場参加者）をランダムに選択し、その注文のすべてを可能な程度まで満たすことができ、以下同様である。当然ながら、市場参加者のランダム選択は、個々に、又は市場参加者のランダムに割り当てられた順序付けに基づいて、行われてもよい。

理想レイテンシフロアアプリケーション１２０により実行される参加者ごと一挙排出の一実装の疑似コード及び付随説明が、限定でなく例示として下記で説明される。排出動作の他の実装が、本明細書において提供される開示に基づいて同様に使用されてもよい。

1: Map<Participant,LinkedList<Order>> m = … //mはバッチ内の参加者の注文を含む
2: LinkedList<Participant> ps = new
LinkedList<Participant> (m.keySet());
3: Collections.shuffle(ps);
4: for (Participant p : ps) {
5: for (Order o : m.get(p)) {
6: processAgainstClob(o);
7: }
8: m.get(p).clear();
9: }

行２は、マップｍ内のキーである市場参加者１４２のコピーを作る。

行４は、forループを開始し、このループは、市場参加者１４２がシャッフルされた順序に基づいて、市場参加者１４２にわたり反復する。

行５は、市場参加者の注文にわたり反復する。

行６は、ＣＬＯＢに対して市場参加者の注文を処理する。

行８は、市場参加者に関連付けられた注文のリストをクリアする（注文が処理された後にリストから実際に削除される、前のラウンドロビン排出例と一貫性があるためだけの理由であっても）。

非限定的な一例が、限定でなく例示として提供される。バッチが、参加者Ａからの注文ａ１、ａ２、及びａ３と、参加者Ｂからの注文ｂ１と、参加者Ｃからの注文ｃ１及びｃ２とを含む場合、マップｍは、下記のとおり表現されることができる：
{A->[a1,a2,a3];B->[b1];C->[c1,c2]}

マップのキー（すなわち、参加者）のシャッフリングが、順序付けられたリスト［Ｃ，Ａ，Ｂ］を結果としてもたらす場合、メッセージがＣＬＯＢに対して処理されることになる順序は、下記のとおりである：
[c1,c2,a1,a2,a3,b1]

公正数量レース排出

公正数量レース（equitable quantity race）排出動作において、システムは、一度に各参加者の注文から所定量の数量を処理し、ＣＬＯＢに対して処理されるべき残っている数量が参加者すべてについてゼロになるまで参加者にわたり繰り返し反復することができる。例えば、所定量の数量が所与の外国為替商品における基準通貨の１Ｍである場合（これは現場における最小取引サイズ及び最小増分に対応してもよく、注文サイズは変化し得る）、第１の参加者の第１の注文の１ＭがＣＬＯＢに対して処理されることになり、それから、第２の参加者の第１の注文の１ＭがＣＬＯＢに対して処理されることになり、いずれの参加者の注文においても残りの数量がなくなるまで、以下同様である。

理想レイテンシフロアアプリケーション１２０により実行される公正形成者レース排出動作の一実装の疑似コード及び付随説明が、限定でなく例示として下記で説明される。排出動作の他の実装が、本明細書において提供される開示に基づいて同様に使用されてもよい。

1: Map<Participant,LinkedList<Order>> m = … //mはバッチ内の参加者の注文を含む
2: LinkedList<Participant> ps = new
LinkedList<Participant>(m.keySet());
3: Collections.shuffle(ps);
4: int remainingOrders;
5: final int splitSize = 1;
6: do {
7: remainingOrders = 0;
8: for (Participant p : ps) {
9: LinkedList<Order> os = m.get(p);
10: if (os.size() > 0) {
11: Order o = os.removeFirst();
12: o.qty -= splitSize;
13: processAgainstClob(new Order(o,splitSize));
14: if (o.qty > 0) {
15: os.addFirst(o);
16: }
17: remainingOrders += os.size();
18: }
19: }
20: } while (remainingOrders > 0);

上記疑似コードは、レース内の参加者について、その数量が提出された注文の数にかかわらず、レース内で提出される合計数量に関してより公正な結果に達するようにサイズ（数量）又は注文を認識するやり方で注文を排出する方法を例示する。排出ストラテジとして、このことは、レース内のすべての参加者が時間的なキューの最前部（front）の近くにおけるいくらかの数量か又はＣＬＯＢ内の各価格レベルにおける注文かを獲得することを確保する形成者レースにおいてと、すべての参加者がビッド又はオファー注文の（有限）数量のシェアを引き上げられることを確保するよう試みる受容者レースにおいてとの双方で、分別よく使用されることができる。

行２は、マップｍ内のキーである市場参加者のコピーを作る。

行５は、注文の分割サイズを定義する。その値は分別よく、取引現場における最小注文サイズか、又は何らかの他の「小さい」値であってもよい。この例を目的として、上記値は１であるように仮定され、すべての注文は、厳密に０より大きい数量を有し、数量は整数である（小数でない）と仮定される。

行６〜２０は、行８で始まるforループが公正数量レース排出動作に、各参加者の注文リストがサイズゼロに低減されるまで参加者のリストにわたり繰り返し反復させる点で、ラウンドロビン排出動作の疑似コードの例と構造的に同様である。しかしながら、重要な差は、注文を削除しそれを処理することに代わって、公正数量レース排出動作は代わりに注文を削除し、その数量を分割サイズだけ減分し、分割サイズに等しい数量を有する「子」注文を作成し、子注文のすべての他の属性は、その「親」から継承されることである。親注文数量の減分は、子注文のサイズ（数量）の和が親の注文サイズに等しいことを確保し、このことは、行１２で実行される。「子」注文は、行１３においてＣＬＯＢに対して処理され、「親」注文がＣＬＯＢに対して処理されないことに留意する。行１４は、親注文が該注文上に残りの数量を有するかどうかを確かめるように確認する。そうである場合、上記親注文は、該注文が事前に削除された参加者の注文のリストの最前部に再追加される（行１５において）。親注文の数量が枯渇した場合（すなわち、その数量が厳密にゼロより大きくない）、該注文はリストに再追加されず、なぜならば、それは、すべてがサイズ“splitSize”の子注文へ完全に分割されているからである。第１の手法で、公正数量レース排出動作は、行１７において、do-loopの各反復の後にリスト内に残っている注文の数の記録をつける。

1: class Order {
2: int qty = 0;
3: Order parent;
4: Order(Order parent, int qty) {
5: this.parent = parent;
6: this.qty = qty;
7: }
8: //… 必要に応じた注文に対する追加メソッド／フィールド
9: }

上記の９行の疑似コードは、上記で説明された公正形成者レース排出動作の例において使用されるOrderクラスの部分的な一実装である。行２のqtyフィールドは、注文の数量（サイズ）を記憶する。行３の（任意的な）parentフィールドは、親注文を記憶する。上記文脈において、親注文は、この排出メカニズムにおける分割の影響下にあった注文である。行４で始まるコンストラクタは、フィールドに値を割り当てる。行８は、Orderクラスの完全な実装が指値、時間強制（time-in-force）などの情報を記憶するさらなるフィールドを含む見込みがあることを示すコメントである。

分割サイズが１であり、市場参加者Ａが注文ａ１：２、ａ２：１を提出し、市場参加者Ｂが注文ｂ１：２を提出し、市場参加者Ｃが注文ｃ１：４を提出し（これにおいて、コロン“：”に続く数字は、注文のサイズである）、シャッフリングの結果が順序付け［Ｂ，Ａ，Ｃ］である場合、ＣＬＯＢに対して処理されることになる「子」注文の、結果として生じる順序付けは：
[b1:1,a1:1,c1:1,b1:1,a1:1,c1:1,a2:1,c1:1,c1:1]
である。

理想レイテンシフロアメカニズムにおける差し替えメッセージに関する注文の扱い

取り消し・差し替え（Cancel-Replace）要求（本明細書において、単に「差し替え」又は「差し替えメッセージ」）が、多くの電子取引現場において市場参加者によって広く使用されている。差し替えメッセージは、１つの原子動作において、ＣＬＯＢ内の既存の注文を取り消し、その取り消しの成功を条件として、新しい要求された価格レベル及び新しい要求された数量における新しい注文を作成する。古い注文と、差し替え要求内の新しい注文とは、同じサイドを有することになる（例えば、買い注文は、売り注文で差し替えられることはできない）。差し替えメッセージは、該差し替えメッセージがこれを送信した市場参加者とこれを受信した取引現場との間を「飛行中（in flight）」であった間に古い注文が満たされた場合、拒否されることになる（すなわち、新しい注文が作成されない）。理想レイテンシフロアメカニズムは、様々な方法でこうした差し替えメッセージを扱うことができる。

差し替えメッセージの、取り消しメッセージ及び新規注文メッセージへの分割

一実装において、理想レイテンシフロアメカニズムは、該メカニズム内部で差し替えメッセージを２つの部分（取り消しメッセージ及び新規注文メッセージ）に分割することにより差し替えメッセージを扱い、これらの各々を上記メカニズム内で別個に扱うことができる。そのようにするのに、理想レイテンシフロアメカニズムは、取り消しが失敗した場合、新しい注文がＣＬＯＢに提出されないことを確保しなければならない。さらに、理想レイテンシフロアメカニズムは、差し替えから「抽出された」取り消しメッセージが、差し替えから同様に「抽出された」新しい注文の前にＣＬＯＢに対して常に処理されることを確保しなければならない。さらに、理想レイテンシフロアメカニズムは、新しい注文のオープン（open）数量が、古い注文（すなわち、差し替えの影響下にある既存の注文）が取り消された時点までに該古い注文において発生したいかなるフィル（fills）も反映することを確保しなければならない。

理想レイテンシフロアメカニズム内部で差し替えメッセージを分割することの１つの利点は、このメカニズムが、表２につきバッチ（レース）に関して取り消し及び新しい注文を扱う方法を説明する構成パラメータを有することができる点であり、ただし、差し替えそれ自体を扱う方法の明示的な構成パラメータはない。こうした既存のパラメータは、差し替えから抽出された新しい注文と取り消しとに適用されることになり、ただし、取り消しが新しい注文の前に処理されなければならないとの但し書きを伴う。ゆえに、理想レイテンシフロアメカニズムは、取り消しが新しい注文の前に処理されることを確保しなければならないことになる（及び、２つのバッチ／レースインスタンスの間におけるある程度の通信を必要とする可能性がある）。さらに、理想レイテンシフロアメカニズムがＣＬＯＢと通信するためのインターフェースは、取り消しが新しい注文の前に処理される仕方でインターフェースが動作することを同様に確保しなければならないことになる。

差し替えの、取り消し及び新しい注文への分割をサポートするために、理想レイテンシフロアメカニズムにより使用されるＣＬＯＢに対するインターフェース上にメソッドが含まれて、取り消しメッセージを下記のとおり処理することができる：
Order processCancel(Msg cxl)

上記メソッドにおいて、Orderオブジェクトは、取り消しメッセージがＣＬＯＢにより処理されるとき、ＣＬＯＢから返される。返された注文のオープン数量がゼロであるか、又は注文オブジェクトそれ自体がヌルである場合、このことは、差し替えから抽出された新しい注文がＣＬＯＢに送信されるべきでないと示すことができる。さらに、ＦＩＸプロトコルの差し替えメッセージ（replace message）内で参照される数量が、（注文の「オープン数量」でなく）注文の「元の数量」に典型的に関係するため、注文の「オープン数量」と「累積数量」との和が、差し替えメッセージ内に指定される新しい「元の数量」より小さい場合、このことは、差し替えが拒否されることか、又は元の注文が新しい注文の送信なしに取り消されることを引き起こす。上記の状況において何が起こるかは、特定の現場が上記の個別の状況を如何にして扱うかに依存する（いくつかの現場は、差し替えを完全に拒否する可能性があり、いくつかの現場は、新しい注文が入力されるのを許容することなく元の注文を単に取り消す可能性がある）。

「差し替え」メッセージを取り消し及び新しい注文に分割することの別の利点は、理想レイテンシフロアの構成パラメータがリアルタイムに取り消しを処理する、すなわち取り消しをバッチに全く含まないように設定される場合、取り消しが遅延されないことになる点である。市場形成者は、遅延なくＣＬＯＢ内の自身のビッド及びオファーを取り消しできることを一般により好む。

差し替えメッセージの自然な扱い

一実装において、理想レイテンシフロアメカニズムは、差し替えメッセージを分割することなく、差し替えメッセージを「自然に（natively）」扱うことができる。その代わり、差し替えメッセージは、最も長い（時間的な）遅延を有するバッチ／レースに置かれる可能性がある（そのバッチがすでにアクティブであるか、又は、新しく、差し替えがその中の第１のメッセージであることを意味するか）。しばしば、差し替えメッセージが置かれ得る２つのバッチについての選択が存在することになり、すなわち、差し替えの取り消し部分に起因する受容者レースバッチか、又は、差し替えメッセージ内の新しい指し値により識別される形成者レースバッチかのいずれかである。上記２つのうちで選択があるとき、差し替えメッセージは、タイマがより後で鳴る（満了する）バッチに置かれ得る。

上記実装において、差し替えメッセージの扱いは、依然として、少なくとも部分的に、理想レイテンシフロアメカニズムの構成パラメータによって指示されることができる。例えば、上記メカニズムは、（形成者レースでなく）受容者レースのみに対して有効にされ、差し替え内に指定される注文の新しい指し値がブックを横断する場合、この注文は、買い又は売り受容者バッチに入ることになる。より古い注文の取り消しは、受容者バッチがＣＬＯＢに対して処理されるまで発生しないことになり、このことは、取り消しのメカニズムに対する構成にかかわらず、差し替えのうち取り消し部分が遅延されることを意味する。しかしながら、差し替え内に指定される指し値がブックを横断しない場合、差し替え動作全体がリアルタイムに起こる可能性がある。別の例において、形成者レースと受容者レースとの双方がメカニズム内で有効にされ、新しい指し値がブックを横断しない場合、差し替えは、サイドと価格レベルとに対する形成者バッチに入るべきである。しかしながら、取り消しが上記メカニズム内でさらに有効にされる場合、差し替えは、２つのバッチ、すなわち形成者バッチ又は受容者バッチのいずれかのうち、より長いもの（さらに遠い将来に満了することになるバッチ）に入り得る。

自然のアプローチのいくつかの利点は、市場参加者が「市場の外」でない点であり（すなわち、差し替えが処理される間のどの時点でもＣＬＯＢ内に注文を有さず、なぜならば、注文がアトミックに処理されるためである）、このことは、理想レイテンシフロアのあまり複雑でない実装を結果としてもたらすことができる。

理想レイテンシフロアメカニズムからのデータ収集

データが理想レイテンシフロアメカニズムから収集されて、該メカニズムが正しく動作しており、正しく実装されていることを確保することができる。データは、ファイルシステム又はデータベース、例えばデータベース１３２などに記憶されるべきである。詳細に、各メッセージについて、下記が記憶されるべきである（タイムスタンプが、少なくともマイクロ秒精度であるべきである）：１．（メッセージがメカニズム又はＣＬＯＢに至る前に）メッセージが受信されたタイムスタンプ、２．（メッセージがメカニズム又はＣＬＯＢに至る前に）メッセージが受信された合計の順序付けを反映する整数、３．メッセージがＣＬＯＢに対して処理されたタイムスタンプ、４．メッセージがＣＬＯＢに対して処理された合計の順序付けを反映する整数、５．メッセージがバッチの影響下にあった場合に、そのバッチ内のすべてのメッセージを一緒に関連付け、バッチ自体を一意に識別することができる一意ｉｄ、６．メッセージがバッチの影響下にあった場合に、メッセージがバッチに挿入されたタイムスタンプ、７．各バッチについて、その構成パラメータの全体（バッチが割り当てられた遅延期間、受容者レース又は形成者レースかどうか）、８．注文が属すると見なされた市場参加者（この市場参加者は、市場参加者である事務所が別の事務所を買収し、又は別において所有権を譲渡するとき、時間とともに変化する可能性があることに留意する）、９．シャッフリングの後及び排出の前にリスト内で割り当てられた市場参加者の位置、及び／又は、理想レイテンシフロアメカニズムが正しく動作しており、正しく実装されていることを確保するために該メカニズムから収集され得る他の情報。

理想レイテンシフロアアプリケーション１２０はそれ自体、種々の命令セットを含むことができ、上記命令セットは各々、プロセッサ１１２（及び、したがってコンピュータシステム１０４）をプログラムする。例えば、理想レイテンシフロアアプリケーション１２０は、注文受信エンジン１２２、トリガ検出エンジン１２４、バッチエンジン１２６、グループ化エンジン１２８、ランダム化エンジン１３０、注文処理エンジン１３２、及び／又はコンピュータシステム１０４をプログラムする他の命令を含むことができる。本明細書において使用されるとき、簡便さのため、様々な命令が動作を実行するものとして説明されるが、実際には、様々な命令がコンピュータシステム１０４をプログラムして動作を実行する。

一実装において、理想レイテンシフロアアプリケーション１２０は、所定基準又は事象（例えば、第１の注文が受信されるなど）によりトリガされるバッチ期間（batching period）内にシステムに対して注文を送信した市場参加者に、市場レースに勝つ等しい確率を提供することができる。

一実装において、理想レイテンシフロアアプリケーション１２０は、１つ以上の市場参加者から金融商品のための１つ以上の注文を受信することができる。理想レイテンシフロアアプリケーション１２０は、トリガ事象に応答して、バッチ期間について市場参加者から受信した注文をバッチにすることができる。例えば、理想レイテンシフロアアプリケーション１２０は、所与の商品のための注文を、（ｉ）注文（又は、メッセージ）がレースタイプをトリガするとき、及び（ｉｉ）注文がバッチ期間内に入力され、上記レースタイプに適するときに、バッチにすることができる。別の一実装において、理想レイテンシフロアアプリケーション１２０は、バッチにされた注文を市場参加者でソートし、バッチ期間の間に送信された注文に対応する市場参加者の、結果として生じるリストを提供してもよい。

一実装において、理想レイテンシフロアアプリケーション１２０は、市場参加者の上記結果リストをランダムにシャッフルして、処理順序を生成することができる。理想レイテンシフロアアプリケーション１２０は、本明細書に説明される様々な排出動作に基づいて、ランダムにシャッフルされた処理順序における市場参加者のリストから注文を排出することができる。

市場参加者からの注文の受信

一実装において、注文受信エンジン１２２は、１つ以上の市場参加者から金融商品のための１つ以上の注文を受信することができる。市場参加者は、これらに限られないが、顧客、市場形成者、ブローカ／ディーラシステム、電子通信ネットワーク（electronic communication networks）（ＥＣＮ）、及び他の交換であり得る。例えば、市場形成者には、同じ商品に対して同時にビッド及びオファー双方の注文を提出し及び／又は維持する任意の個人又は事務所が含まれてもよい。顧客は、システム１００を介して取引活動に関与し、市場形成者でない任意のエンティティ、例えば、個人、個人のグループ、又は事務所などであり得る。例えば、顧客は、個人投資家、投資家のグループ、機関投資家であってもよい。一実装において、市場参加者は、理想レイテンシフロアアプリケーション１２０に注文を入力する処理を含んでもよい。

市場参加者は、理想レイテンシフロアアプリケーション１２０を介して様々な取引注文を出して金融商品を取引することができ、金融商品は、例えば、株式又は他の持分証券、債券、ミューチュアルファンド、オプション、先物、デリバティブ、通貨などである。こうした取引注文は、ビッド（若しくは買い）注文、アスク若しくはオファー（若しくは売り）注文、又は双方を含むことがあり、理想レイテンシフロアアプリケーション１２０により管理され得る任意タイプの注文であってよく、限定でなく例えば、成り行き注文、指値注文、損切り注文（stop loss orders）、当日限り注文（day orders）、オープン注文（open orders）、ＧＴＣ（「取り消しまで有効の（good till cancelled）」）注文、「有効期限付き」注文（“good through” orders）、「全か無かの」注文（“all or none” orders）、「任意部分」注文（“any part” orders）などである。一実装において、市場参加者は、金融商品に対して単一の注文を入力することができる。一実装において、市場参加者は、金融商品に対して複数の注文を入力することができる。用語の注文は、本明細書において使用されるとき、市場参加者から電子取引現場が受信するメッセージのすべての形式を広く参照することが意図され、上記形式には、これらに限られないが、取り消し要求、差し替え要求、新規注文要求などが含まれる。

１つ以上の市場参加者が、金融商品について、該金融商品の特定の市場ポジションの利点を生かす注文を提出する場合、商品の注文は、市場レースにおいて競争するように定義され得る。市場レースは、２つのカテゴリ、すなわち受容者レース及び形成者レースに一般に該当する。受容者レースは、注文のサイドと、注文価格がブックを「横断する」（すなわち、価格に基づいて市場の現在の状態に対して満たすことになる）こととによって識別されることができる。形成者レースは、注文のサイドと注文の指し値とのペア（すなわち、市場の現在の状態において存在する反対サイドの注文に対してマッチしない注文）によって識別されることができる。本発明は、受容者及び形成者レースについて理想レイテンシフロアメカニズムを単に作成することを超える適用可能性を有し得ることが十分理解されるべきであり、そのようなものとして、システム及び手法が、そのより広い適用可能性を可能にするようにパラメータ化される。

トリガ基準又は事象の検出

一実装において、トリガ検出エンジン１２４は、市場レースの開始を示し得る１つ以上のトリガ事象を検出することができる。例えば、トリガ検出エンジン１２４は、１つ以上の所定基準又は事象（例えば、市場データアップデート、又は、第１の注文が金融商品について受信されることなど）を検出することができ、上記基準又は事象が、本明細書に説明されるとおり、市場参加者間の市場レースをトリガする。

バッチ期間内の注文のバッチ化

本発明の一態様に従い、バッチエンジン１２６は、検出されたトリガ事象からバッチ期間内に受信された、市場参加者から受信された１つ以上の注文をバッチにすることができる。バッチ期間は、トリガ事象に基づいてトリガされることができ、境界の範囲内（例えば、０．９ｍｓ〜１．１ｍｓ）でランダムに選択されることができる。例えば、バッチエンジン１２６は、所定基準を満足する第１の注文が金融商品に対して受信された後、１．１ミリ秒以内に受信された該金融商品のための注文を、所与のレースタイプについて一緒にグループ化することができる。

一実装において、バッチ期間は、レイテンシフロアの値の範囲内に応答する市場参加者が価格を形成し又は受容するための市場レースに勝つ等しい機会を有する時間の期間を参照し得る。むしろ、注文は、バッチにする時間期間にわたり一緒にバッチにされることができ、このバッチにする時間期間の終わりで、バッチ期間内に注文を提出した市場参加者がランダム化されて、市場参加者注文が処理される順序が提供される。上記の場合、バッチ期間の値の範囲内に注文を提供する市場参加者は、自身が競争するよう選ぶレースに勝つ等しい機会を有することができる。一実装において、バッチ期間は、必ずではないが典型的に、小さい数、例えば２ミリ秒（ｍｓ）などに設定されることができる。バッチ期間の値は、電子取引システムのオペレータによって設定されることができる。例えば、バッチ期間（２ｍｓ）内に所定基準又は事象（例えば、市場データアップデート、又は、第１の注文が金融商品について受信されることなど）に対して応答することができる市場参加者が、そのレースに勝つ実質的に等しい機会を有することができる。一実装において、バッチエンジン１２６は、市場参加者から受信される、バッチ期間内に受信された１つ以上の注文を、一緒にグループ化することができる。

一実装において、バッチエンジン１２６は、トリガ事象に応答してバッチ期間を開始し、あるいはトリガすることができる。バッチ期間の間、バッチエンジン１２６は、バッチ期間内に受信された金融商品の１つ以上の注文を一緒にグループ化して、バッチを形成することができる。一実装において、注文が受信される時間的順序が、保有されることができる。上記の場合、バッチエンジン１２６は、金融商品のための最初の注文と、その第１の注文が受信された後のバッチ期間に受信される同じ金融商品のためのすべての他の注文とを、注文が受信された時間的順序においてバッチにすることができる。バッチエンジン１２６は、１つ以上の注文を、（ｉ）注文がすべて、レースされている商品との価格適合性がある（price-compatible）とき、及び（ｉｉ）注文がバッチ期間内に入力されたときに、一緒にグループ化することができる。一実装において、注文取り消し要求が、バッチ期間内に受信される場合、バッチの中にさらに含まれることがある。取り消しが含まれる可能性があり、そのため、より速い形成者は、すべての受容者注文がバッチ期間の影響下にある間、自身の注文を取り消すことができない可能性がある。一実装において、バッチ期間外に受信される注文は、一緒にグループ化されず、これら注文が受信される時間的順序において記憶されることができる。差し替え注文に関して、バッチエンジン１２６は、差し替え注文を取り消しメッセージと新規注文メッセージとに分割することができ、上記取り消しメッセージ及び新規注文メッセージは、バッチエンジン１２６により別個に処理される。

例えば、最初の市場状態Ｔ＝ｔミリ秒において、市場における商品のアスク価格が５５であり、その価格において、上記商品の１００万単位が取引されることがある。Ｔ＝ｔ＋１ミリ秒において、市場参加者間の市場レースを引き起こし得る新しいパッシブ注文（passive order）が、スプレッド（spread）の内側に入力される。この新しいパッシブ注文は、市場において商品に対して５３のアスク価格を含み、商品の１００万単位がその価格で取引される。Ｔ＝ｔ＋１．５ミリ秒において、参加者Ａが、商品の１００万単位について価格５３で、即時又は取り消しの買い注文（immediate or cancel buy order）を送信する。Ｔ＝ｔ＋１．６ミリ秒において、参加者Ｂが、商品の１００万単位について価格５４で、即時又は取り消しの買い注文を送信する。Ｔ＝ｔ＋１．７ミリ秒において、参加者Ｃが、商品の１００万単位について価格５４で、即時又は取り消しの買い注文を送信する。Ｔ＝ｔ＋１．８ミリ秒において、参加者Ｄが、商品の１００万単位について価格５３で、取り消しまで有効の買い注文（good until cancel buy order）を送信する。Ｔ＝ｔ＋３ミリ秒において、参加者Ｅが、商品の１００万単位について価格５４で、即時又は取り消しの買い注文を送信する。レースのバッチ期間が１ｍｓであり、このバッチ期間が参加者Ａからの最初の買い注文からトリガされた場合、参加者Ａ、Ｂ、Ｃ、及びＤからの注文はバッチとして一緒にグループ化される。なぜならば、これら注文がすべて、レースされているパッシブ注文との価格適合性があり、これら注文がすべて、バッチ期間内に入力されたからである。参加者Ｅはバッチ期間内に注文を送信しなかったので（Ｔ＝ｔ＋３ミリ秒）、その注文は他の市場参加者とのバッチの中にグループ化されないことになる。

一実装において、バッチ（「レース」）の複数のインスタンスが単一の商品に所属することがある。いずれの所与の注文もただ１つの上記インスタンスに入るように、ケアが行われなければならない。このことは、バッチ期間をトリガする条件をより具体的にすることによって、及び、注文がバッチ期間にグループ化される条件をより具体的にすることによって達成されることができる。一般に、上記条件は、バッチの異なるインスタンス間において相互排他的であって、バッチのいずれのインスタンスに注文又はメッセージが入るかに関する曖昧さを回避することができる。例えば、同時に又は時間においてわずかに重なって発生している２つのレースがある状況、すなわち、詳細には、オファーを仕掛けるレースとビッドを仕掛ける別個のレースとが双方、単一の商品に対してある状況において、バッチの２つのインスタンスが存在し得る。アスクアグレッサ（ask-aggressor）レースのバッチ期間をトリガする条件は、ブックを横断する買い注文であり得る。バッチ期間内であるときに注文がバッチにグループ化される条件は、ブックを横断する買い注文と、場合により、売り注文の取り消し要求とであることになる。ビッドアグレッサ（bid-aggressor）インスタンスについて、アスクアグレッサインスタンスと比較されると、注文及び取り消し要求のサイドが反転されることができる。こうして、時間においてインタリーブする別個のレースが、これらレースにおけるすべての参加者がレースに勝つ等しい機会を有することができる特性を有し続けることができる。バッチエンジン１２６は、異なるサイドの形成者注文（すなわち、ビッド又はアスクブックに挿入される注文）を処理する商品ごとのバッチ期間のさらなるインスタンスを含んで、商品における形成者レースを扱うようにさらに構成されることができる。

市場参加者のグループ化及びランダム化

本発明の一態様に従い、グループ化エンジン１２８は、バッチ期間内に受信される注文を市場参加者でソートすることができる。例えば、グループ化エンジン１２８は、受信した注文を市場参加者単位でソートし、注文を市場参加者単位でバケットに入れる（bucket）ことができる。一例として、グループ化エンジン１２８は、市場参加者により提出される注文を、市場参加者に関連付けられたバケットに置くことができる。ゆえに、バッチ期間に受信された各注文が、市場参加者で関連付けられ、グループ化されることができる。

一実装において、グループ化エンジン１２８は、バッチ期間内に注文を提出した市場参加者の、結果として生じるリストを生成することができる。市場参加者の上記結果リストは、市場参加者と、そのそれぞれの、バッチ期間内に提出された注文とを含むことができる。一実装において、各市場参加者の注文は、市場参加者がその注文を提出した時間的順序において記憶されることができる。例えば、バッチエンジン１２６は、各参加者（Ａ〜Ｄ）に関連付けられたバケットのリストを提供することができ、上記バケットには、バッチ期間の間に受信された各市場参加者の注文が含まれる。各バケットは、その個別の市場参加者のそれぞれの注文で満たされることができる。各バケット内の注文の順序付けは、注文が受信された時間的順序のままであってもよい。

一実装において、ランダム化エンジン１３０は、市場参加者の上記結果リストをランダムにシャッフルして、市場参加者についての処理順序を生成することができる。例えば、ランダム化エンジン１３０は、バッチ期間内に注文を提出した市場参加者について、ランダムな処理順序を生成する。この処理順序が利用されて、バッチ期間内に受信された市場参加者の注文が処理される順序を決定することができる。例えば、ランダム化エンジン１３０は、バケットの結果リストをシャッフルすることができ、したがって、統計的にあらゆる参加者（又は、同等にバケット）が、処理順序において各位置に置かれることの実質的に等しい機会を有する。バケットは、それから、結果として生じるバケットのリストを生成することができ、上記リストは、処理のランダムな順序付けを反映することができる。

ゆえに、複数の信用コード若しくは複数のユーザを有し、又は複数の注文を提出する市場参加者は、参加者に対する利点を与えることができない。一実装において、市場参加者はランダム化であり、したがって、各市場参加者は市場レースに勝つ等しい機会を有する。例えば、４つの市場参加者がレースする市場レースにおいて、各市場参加者は、どれほど多くの注文を各市場参加者が提出したとしても、市場レースに勝つ２５％の機会を有する。

市場参加者注文の処理

本発明の別の態様に従い、注文処理エンジン１３２は、市場参加者の処理順序に従って注文を処理することができる。一実装において、注文処理エンジン１３２は、ランダム化エンジンにより生成されたランダムな処理順序に従って、市場参加者からの注文を処理することができる。

処理が発生する具体的な仕方は、パラメータ化されることができる。アグレッサレースについて、注文は、処理順序において次の参加者へと移る前に、参加者の注文が各参加者から受信された時間的順序付けにおいて処理されることができる。形成者レース注文は、別様に、例えば、ラウンドロビン方式で処理されることができ、したがって、第１の参加者からの第１の注文が処理され、それから、第２の参加者の第１の注文が処理され、それから、第３の参加者の第１の注文が処理され、やがて、もし存在すれば第１の参加者の第２の注文に戻り、注文のすべてが処理されるか又は金融商品の数量が枯渇するまで以下同様である。各参加者注文が処理され得る仕方にかかわらず、各注文（又は、他のシナリオにおいて取り消し要求／メッセージ）が処理されるときに、注文は、マッチング処理（価格適合性確認、信用確認、ＴＩＦ確認、ＭＱＬ確認等）を通じてＣＬＯＢに対してマッチされる／処理される。上記文脈において、「ＣＬＯＢに対して処理される」は、形成者注文としてＣＬＯＢに挿入されることか、受容者注文として既にＣＬＯＢにある注文に対してマッチされることか、又は既存の形成者注文の価格若しくは数量を修正することか、又は既存の形成者注文を取り消し、これにより該注文をＣＬＯＢから削除することかのいずれかを一般に意味する。疑いを避けるために、「形成者注文」はＣＬＯＢに対して流動性を追加し又は提供し、受容者注文はＣＬＯＢから流動性を消費する。

一実装において、注文処理エンジン１３２は、市場参加者間で金融商品の数量を分け合うことができる。上記の場合において、レースされる数量が５Ｍである場合、１Ｍ（又は、現場における最小取引サイズ）を処理順序上で第１の市場参加者による注文に対してマッチさせるよう試みることができ、その次の１Ｍを第２の市場参加者に、その次の１Ｍを第３の市場参加者にと続き、以下同様である。初回に市場参加者を処理した後、さらなる数量がある場合、市場参加者からの注文が、再度同じ仕方の順序で処理される。例えば、形成者数量の各「スライス」が、市場参加者からの注文のリストに対して、該スライスがマッチできる注文が見つかるまで、時間的順序においてマッチされる。注文が見つからない場合、その数量は、次の参加者の注文に対して試行される。市場参加者間における形成者数量の分配は、すべての形成者数量が枯渇した（マッチされた）とき、又は信用不適合のために市場参加者注文に対してさらにマッチさせることができないときに、完了する。有利なことに、上記実装は、レースされる数量を市場参加者間でより公正に分け合う。実際面で、レース勝者とレースされる数量との間に相関がおそらくないため、長い時間的水平線にわたり、同じ数のレースを勝ち取ることは、さらに、同じ数のレースされる数量を勝ち取ることと同等であることになる。

一実装において、注文処理エンジン１３２は、バッチ期間外に受信した注文を、時間的順序において処理することができる。例えば、注文処理エンジン１３２は、バッチ期間外に受信した注文を、注文が受信された順序において処理してもよい。注文処理エンジン１３２は、バッチ内の注文が処理されるまで、バッチ期間外に受信した注文を処理しなくてもよいことが十分理解されるべきである。

システムアーキテクチャ及び構成の例

種々のシステムアーキテクチャが使用されることができる。例えば、理想レイテンシフロアアプリケーション１２０の全部又は一部分が、サーバ装置上で実行されてもよい。換言すると、例示されるコンピューティング装置１１０は、ユーザにより操作されるユーザ装置からユーザ要求を取得するサーバ装置を含んでもよい。理想レイテンシフロアアプリケーション１２０の全部又は一部分がサーバ装置上で実行される実装において、サーバ装置は、理想レイテンシフロアアプリケーション１２０の機能性を実行することができる。

図１において単一のコンポーネントとして例示されているが、コンピュータシステム１０４は、本明細書に説明される機能のうち少なくともいくらかを各々プログラムされた複数の個々のコンポーネント（例えば、コンピュータ装置）を含んでもよい。こうして、十分理解されるであろうとおり、コンピュータシステム１０４のいくつかのコンポーネントがいくつかの機能を実行することができ、他のコンポーネントが他の機能を実行することができる。１つ以上のプロセッサ１１２は、コンピュータプログラム命令によりプログラムされた１つ以上の物理プロセッサを各々含むことができる。本明細書に説明される様々な命令は、単に例示である。プロセッサ１１２が本明細書に説明される機能を実行するようプログラムされる限り、他の構成及び数の命令が使用されてもよい。

さらに、様々な命令が図１において単一の処理ユニット内に同じ場所に配置されるように例示されているが、プロセッサ１１２が複数の処理ユニットを含む実装において、１つ以上の命令が他の命令からリモートで実行されてもよい。

本明細書において説明される種々の命令により提供される機能性の説明は、例示目的であり、限定であることは意図されず、命令のうち任意のものが、説明されるよりもより多くの又はより少ない機能性を提供してもよい。例えば、命令のうち１つ以上が消去されてもよく、その機能性のうちいくつか又はすべてが上記命令のうちの他の命令によって提供されてもよい。別の例として、プロセッサ１１２は、本明細書において命令の１つに起因する機能性のうちいくつか又はすべてを実行することができる１つ以上のさらなる命令によってプログラムされてもよい。

本明細書に説明される様々な命令は、記憶装置１１４に記憶されることができ、記憶装置１１４は、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、及び／又は他のメモリを含んでもよい。記憶装置は、プロセッサ１１２により実行されるコンピュータプログラム命令（例えば、前述の命令）と、プロセッサ１１２により操作され得るデータとを記憶することができる。記憶装置は、フロッピーディスク、ハードディスク、光学ディスク、テープ、又は、コンピュータ実行可能命令及び／又はデータを記憶する他の記憶媒体を含んでもよい。

図１に例示される様々なコンポーネントは、ネットワークを介して少なくとも１つの他のコンポーネントに結合されることができ、ネットワークには、例えば、インターネット、イントラネット、ＰＡＮ（パーソナルエリアネットワーク）、ＬＡＮ（ローカルエリアネットワーク）、ＷＡＮ（ワイドエリアネットワーク）、ＳＡＮ（ストレージエリアネットワーク）、ＭＡＮ（メトロポリタンエリアネットワーク）、ワイヤレスネットワーク、セルラー通信ネットワーク、公衆交換電話網、及び／又は他のネットワークのうち、任意の１つ以上を含んでもよい。図１及び他の図面において、描かれているのとは異なる数のエンティティが使用されてもよい。さらに、様々な実装に従い、本明細書に説明されるコンポーネントは、ハードウェア、及び／又は、ハードウェアを構成するソフトウェアにおいて実装されてよい。

本明細書に説明される様々なデータベース１６０は、例えば、Ｏｒａｃｌｅ社により商業的に販売されるＯｒａｃｌｅ（登録商標）リレーショナルデータベースを含み、あるいはこれに対してインターフェースをとってもよい。他のデータベース、例えばＩｎｆｏｒｍｉｘ（登録商標）、ＤＢ２（Ｄａｔａｂａｓｅ２）など、又は、ファイルベース若しくはクエリのフォーマット、プラットフォーム、若しくはリソースを含む他のデータストレージ、例えばＯＬＡＰ（オンライン分析処理）、ＳＱＬ（構造化問い合わせ言語）、ＳＡＮ（ストレージエリアネットワーク）、Ｍｉｃｒｏｓｏｆｔ（登録商標）Ａｃｃｅｓｓ若しくはその他などが、さらに使用され、組み込まれ、あるいはアクセスされてもよい。データベースは、１つ以上の物理装置に及び１つ以上の物理的場所に存在する１つ以上の上記のデータベースを含んでもよい。データベースは、複数のタイプのデータ及び／又はファイルと、関連するデータ若しくはファイル説明、管理情報、又は任意の他のデータとを記憶することができる。

図２は、本発明の一実装に従う、理想レイテンシフロアメカニズムを提供する処理の例示的な図２００を表す。図２に（及び、他の図面に）表される様々な処理動作及び／又はデータフローが、ここでより詳細に説明される。説明される動作は、上記で詳細に説明されたシステムコンポーネントうちいくつか又はすべてを用いて達成されることができ、いくつかの実装において、様々な動作が異なるシーケンスで実行されてもよく、様々な動作が省略されてもよい。追加的な動作が、表されるフロー図に示される動作のうちいくつか又はすべてと共に実行されてもよい。１つ以上の動作が、同時に実行されてもよい。したがって、例示される（及び、下記でより詳細に説明される）動作は本質的に例示であり、そのようなものとして、限定としてみられるべきではない。

一例示的な実施として、特定の金融商品に対するクライアントＡの注文が、所与の市場レースタイプにおける第１の注文であり得る（例えば、市場を仕掛ける、ブックのトップのビッド、ブックのトップのオファーをくぎ付けにする（peg）等）。クライアントＡの注文がいったん受信されると、バッチ期間（すなわち、注文が処理されるまでの２ミリ秒の期間）が開始されることができ、クライアントＡの注文がバッチに追加されることができる［Ａ］。上記金融商品に対するクライアントＢの注文が、バッチ期間の開始の後、ｔ＝１．７ミリ秒において受信され得る。クライアントＢの注文がバッチ期間内であるため、クライアントＢの注文は、クライアントＡの注文と共にバッチに追加されることができる［Ａ，Ｂ］。バッチ期間の開始の後、ｔ＝１．９９ミリ秒において、クライアントＣの注文が上記金融商品に対して受信され得る。クライアントＣの注文がバッチ期間内であるため、クライアントＣの注文は、クライアントＡ及びＢの注文と共にバッチに追加されることができる［Ａ，Ｂ，Ｃ］。ｔ＝２ｍｓにおいて、上記金融商品のバッチ期間が閉じられ得る。一実装において、バッチ内の注文［Ａ，Ｂ，Ｃ］は、処理される等しい機会を与えられることができる。例えば、バッチがランダムにシャッフルされることができ、下記のランダム順序のうち１つにおいて処理されることができる：B(Process_Order(A, B, C))、B(Process_Order(A, C, B))、B(Process_Order(B, A, C))、B(Process_Order(B, C, A))、B(Process_Order(C, A, B))、又はB(Process_Order(C, B, A))。クライアントＡ、Ｂ、及びＣは、バッチ期間内に応答したので、クライアントＡ、Ｂ、及びＣは、最初に処理される等しい機会を有する。図２の参照を続けると、クライアントＤの注文はｔ＝２．１ミリ秒において受信され、バッチ期間の外側であったため、クライアントＤの注文は、クライアントＡ、Ｂ、及びＣの注文の後、処理されることになる。一実装において、バッチ期間の外側で受信されたいかなる注文も、これらが受信された順序において、又は全体に新しいバッチの影響下で処理されることができる。

図３は、本発明の一実装に従う、理想レイテンシフロアメカニズムを提供する処理の処理フロー図３００を表す。図３に（及び、他の図面に）表される様々な処理動作及び／又はデータフローが、ここでより詳細に説明される。説明される動作は、上記で詳細に説明されたシステムコンポーネントうちいくつか又はすべてを用いて達成されることができ、いくつかの実装において、様々な動作が異なるシーケンスで実行されてもよく、様々な動作が省略されてもよい。追加的な動作が、表されるフロー図に示される動作のうちいくつか又はすべてと共に実行されてもよい。１つ以上の動作が、同時に実行されてもよい。したがって、例示される（及び、下記でより詳細に説明される）動作は本質的に例示であり、そのようなものとして、限定としてみられるべきではない。

動作３０２において、第１の市場参加者に関連付けられた第１の注文セットが受信される。用語の注文は、本明細書において使用されるとき、市場参加者から電子取引現場が受信するメッセージのすべての形式を広く参照するよう意図され、上記形式には、これらに限られないが、取り消し要求、差し換え要求、新規注文要求などが含まれる。

動作３０４において、第２の市場参加者に関連付けられた第２の注文セットが受信される。

動作３０６において、第１の注文セットが受信された後、第２の注文セットがバッチ期間内に受信されたかが決定される。

第２の注文セットが、第１の注文セットが受信された後、バッチ期間内に受信された場合、第１の注文セットと第２の注文セットとのうち１つが、動作３０８においてランダムに選択される。バッチ期間は、所定基準又は事象（例えば、市場データアップデート、又は、第１の注文が金融商品について受信されることなど）に基づいてトリガされることができ、境界の範囲内（例えば、０．９ｍｓ〜１．１ｍｓ）でランダムに選択されることができる。

動作３１０において、第１の注文セットと第２の注文セットとのうち選択された１つが処理される。結果として生じるバケットのリストがシャッフルされることができ、したがって、統計的にあらゆる参加者（又は、同等にバケット）が、処理順序において各位置に置かれる等しい機会を有することが十分理解されるべきである。

第２の注文セットが、第１の注文セットが受信された後、バッチ期間内に受信されなかった場合、第１の注文セットは、動作３１２において第２の注文セットの前に処理される。

本発明の他の実装、使用、及び利点が、本明細書の考慮と本明細書に開示される発明の実施とから当業者に明らかになるであろう。本明細書は単に例示とみなされるべきであり、したがって、本発明の範囲は下記の請求項によってのみ制限されることが意図される。

図４は、本発明の一実装に従う、遅延メカニズム、例えば理想レイテンシフロアメカニズムなどの、様々な状態を示す例示的な図を表す。

遅延メカニズムは、システムにおいて構成される様々なソフトウェアモジュールにより処理されるいくつかの状態を有することができる。メカニズムの状態は、その振る舞いを決定する。メカニズムの異なるインスタンスが互いから独立して動作し、一般に、商品ごとにメカニズムの複数のインスタンスが存在し得る。上記で説明された理由のため、メカニズムは、下記の各々に対してパラメータ化される：（１）メカニズムに遅延（DELAY）状態に入らせる条件、（２）メカニズムが遅延状態にあるときに受け入れるメッセージ、すなわち、注文、取り消し、差し換え等、及び（３）排出（DRAIN）状態において市場参加者バケットが排出される仕方。

所与の商品に対してインスタンス化されるとき、メカニズムは、「通常（NORMAL）」状態に初期化される。システムが通常状態にあり、所与の条件に合致する注文（又はメッセージ）が受信されるとき、メカニズムは「遅延」状態に入る。アグレッサレースについて、メカニズムが遅延状態に入るのに実装する特定の条件は、ブックを横断する注文が受信されること、すなわち、信用を問わず、市場の反対サイドに対してマッチされる（仕掛ける）ことができるように価格設定された注文が受信されることである。ブックを横断する注文の時間強制は重要でない可能性があり、すなわち、それはＩＯＣか又は普通のＧＴＣ注文であってもよく、重要な観察は、注文が、中央指値注文ブックの現在の状態に基づいて、（選別されていない（unscreened））市場を仕掛けることになるように出されることである。（現在の状態は、市場データアップデートにおいて現場から最後に送信されたものでなく、中央指値注文ブックの「真の」状態であり得る）

遅延状態において、所与の基準又は条件に合致する最初の注文とすべての他の注文（又はメッセージ）とが、第１の注文が受信された後のＸミリ秒（ｍｓ）の期間についてこれら注文が受信される順序においてキューに入れられる。Ｘは、典型的に小さい数であってもよく、整数又は小数であってもよい。Ｘは、いくらかの変動を有する「レイテンシフロア」を確立することが所望される場合、いくらかの境界の範囲内（例えば、０．９ｍｓ〜１．１ｍｓ）でランダムにさらに変動してもよい。このことにかかわらず、いったんＸｍｓが報じられる（tolled）と、メカニズムは次に「ランダム化（RANDOMIZATION）」状態に入る。アグレッサレースについて、遅延状態において収集するメッセージの基準は、これらが選別されていないブックをさらに横断する注文であることと、場合により、すべての注文取り消し要求である。取り消しを含むことの理由づけは、我々が、すべての受容者注文が遅延期間の影響下にある間、最も速い形成者がその注文を取り消せるようにしたくないことであり得る。取り消しを除外することの理由づけは、取り消し要求が、現場の先在の実施における注文メッセージにわたり優先権を既に獲得している可能性があることである。

ランダム化状態において、注文（又はメッセージ）のキューは市場参加者単位でバケットに入れられ、ゆえに、市場参加者の注文はすべて（ユーザ、信用コード等にかかわらず）、そのクライアントのための単一のバケットに入る。一実施形態において、（市場）参加者は、組織、例えば、銀行又は主要仲介（prime-brokerage）クライアントなどであり、特定のユーザ（人間）又は信用コードでない。こうして、複数の信用コード若しくは複数のユーザを有すること、又は複数の注文を提出することは、参加者に対する利点を与えない。それから、結果として生じるバケットのリストがランダムにシャッフルされ、この結果、システムは「排出」状態に入る。ランダムなシャッフリングは、統計的にあらゆる参加者（又は、同等にバケット）がバケットの結果リスト内で各位置に行き着く等しい機会を有するように、実施されることができる。所与の参加者についての、上記遅延の影響下であった注文（又はメッセージ）の順序付けは、これらがクライアントのバケットに置かれるとき、保たれる。

排出状態において、システムは、バケット順序付けにより決定された順序において、バケットから注文を排出する。排出が発生する具体的な仕方は、パラメータ化される。上記アグレッサレースについて、すべての注文が、リスト内の次の参加者に移る前、参加者の注文が受信された時間的順序付けにおいて、各参加者のバケットから排出される。有利なことに、このメカニズムは他の場所に使用されてもよく、例えば形成者レースについて、注文（メッセージ）が別様に、例えばラウンドロビン方式で、又は公正数量方式で排出されることができる。各クライアント注文がバケットから削除される仕方にかかわらず、各注文（又は、他のシナリオにおいて取り消し要求／メッセージ）が削除されるときに、注文は、マッチング処理（価格適合性確認、信用確認、ＴＩＦ確認、ＭＱＬ確認等）を通じて中央指値注文ブックに対してマッチされる／処理される。すべてのバケットがいったん排出されると、メカニズムは通常状態に立ち戻る。

付録Ａは、表２に説明されるパラメータに従って理想レイテンシフロアメカニズムを実装するのに使用される命令の一例を含み、この例は、限定でなく例示として提供される。本明細書における開示に基づいて明らかであるとおり、他の命令セットが同様に使用されてもよい。

import java.util.ArrayList;
import java.util.Collections;
import java.util.HashMap;
import java.util.Iterator;
import java.util.LinkedHashMap;
import java.util.LinkedList;
import java.util.List;
import java.util.Map;

public class IdealLatencyFloor {

public static void main(String[] args) throws Throwable {

//Maker_Races:Boolean
boolean makerRaces = false;
//Taker_Races:Boolean
boolean takerRaces = false;

//Cancels_In_Batching:Boolean
boolean cancelsInBatching = true;

//Cancels_Trigger:Boolean
boolean cancelsTrigger = false;

//Floor_Upper:double
double floorUpper = 2.0;
//Floor_Lower:double
double floorLower = 2.0;

//Maker_At_Once:Boolean
boolean makerAtOnce = false;

//Taker_At_Once:Boolean
boolean takerAtOnce = true;

//これは、商品に対するインバウンドメッセージのキューである
//通常、このキューは、ソケット又は同様のものからのスレッドフレーミング
//メッセージによって埋められることになる
final Queue<Msg> inboundMsgs = new Queue<Msg>();

//これは、現在アクティブであるレースのマップであり、すなわち、
//このマップ内のバッチは、まだシャッフル及び排出されていない
final LinkedHashMap<PriceSide,Batch> activeRaces = new LinkedHashMap<PriceSide,Batch>();

//これは、商品の中央指値注文ブックである
//各商品は、すべてのその形成者注文を記憶するこのオブジェクトの
//１つのインスタンスを有することになる
final CLOB clob = new CLOB();

//市場がオープンしている間、我々はこのループ内でスピンする。「スピンする
//こと」は、行うべき最も効率の良いことではないが、ここでの我々の目的は
//簡素な一実装を伝えることであり、必ずしも最も効率の良いものではない
while (true) {

//システム内のすべてのアクティブなレースにわたり反復する。activeRacesは
//意図的にLinkedHashMapであることが留意され、ゆえに、複数のタイマがすべて
//「一挙に」満了したとき、我々はバッチをその作成日付に基づいて処理する --
//複数が「同時に」満了したとき、より早く作成されたバッチ／レースが、
//より後に作成されたものより前に処理されることになる。
for (Iterator<PriceSide> it = activeRaces.keySet().iterator(); it.hasNext();) {

//これは、レース／バッチを識別するキーである
PriceSide key = it.next();

//これはバッチ自体であり、実装により非ヌルであることを保証される
Batch batch = activeRaces.get(key);

//この式が真である場合、バッチのタイマが満了しており、我々はそのバッチを
//排出しなければならない。前に述べられたとおり、我々がこのforループの
//内側であるとき、複数のバッチが満了していることがあり、その場合、我々は、
//バッチ内の第１の注文／メッセージが受信された時間によって、これらを
//意図的に処理することになる。ゆえに、複数のバッチがすべて「一挙に」
//満了したとき、最も古い注文を含むバッチが最初に処理されることになる。
if ((batch.startTimeMillis + batch.periodMillis) <= System.nanoTime() / 1000000.0) {

//キューを排出する方法について、２つの別個の構成パラメータがある。
//１つは受容者レースに関し、１つは形成者レースに関する。我々は、
//Batch内に記憶されたレースタイプに基づいて、ここで正しい物を選ぶ
boolean drainAtOnce = batch.isTakerRace ? takerAtOnce : makerAtOnce;

//バッチを排出する、すなわち、特定レースタイプにおける注文のランダム化
//を行うロジックが、Batchクラスの内部に存在する。
batch.shuffleAndDrain(clob,drainAtOnce);

//ここに該当した場合、我々はこのバッチからの注文の排出を完了しており、
//このバッチ（及びそのキー）をアクティブレースのリストから削除する。
//ゆえに、我々はそれを再度処理せず、ゆえに、activeRacesマップのサイズを
//小さく保つ
it.remove();
}

}

//特定の商品を扱うソケットからのインバウンドメッセージがある場合、これらを、
//メッセージのすべてを一挙に排出することによって処理する。いかなるインバ
//ウンドメッセージもない場合、このwhileループの反復は、このメソッドが
//ノンブロッキングである、すなわち、空のメッセージリストを返すと仮定する。
//ＮＢ：我々はここで新しいメッセージの待機をブロックすることはできず、
//なぜならば、上記forループ内で、バッチ期間／アクティブレースが満了した／
//報じられたことについて、絶えず確認する必要があるからである。
for (Msg msg : inboundMsgs.drain()) {

//この式が真である場合、メカニズムは全体的に無効にされる。ゆえに我々は
//すべてのメッセージをリアルタイムで、受信されたとおりに処理する
if (!takerRaces && !makerRaces) {
clob.process(msg);
continue;
}

//この式が真である場合、取り消しがバッチメカニズムに含まれず、
//ゆえに、リアルタイムで、受信されたとおりに処理されるべきで
//ある
if (!cancelsInBatching && msg.isCancel()) {
clob.process(msg);
continue;
}

//これは、２つ組としての注文の指し値及びサイドである。
//取り消しメッセージについて、これは、取り消される注文の価格及び
//サイドである。変数priceSideは、activeRacesマップ内のレースを
//識別する「キー」であることになる
PriceSide priceSide = msg.priceSideKey();

//取り消しがメカニズムにより処理されるとき、受容者注文と共にグループ化
//されるため、取り消しのキーは、その価格をヌルに設定される必要がある。
//さらに、ビッドを取り消すレースが、そのビッドに至る売り注文と競争する
//ため、取り消しのサイドが、レースタイプによりグループ化することになる
//とき、反転される。
//こうした「補正物」をこのブロック内における取り消しのキーにする
if (msg.isCancel()) {
priceSide.price = null;
priceSide.isBuy = !priceSide.isBuy;
}

//このコードブロックは、注文メッセージがブックを「横断する」か否か、すな
//わち、注文が「リアルタイム」ブックに対してエントリ上でマッチすることに
//なるか（ｃｆ．合成された市場データブック）を決定し、信用を無視する
boolean orderCrossesBook = false;
if (!msg.isCancel()) {
orderCrossesBook = (priceSide.isBuy && priceSide.price >= clob.getAskPrice())
|| (!priceSide.isBuy && priceSide.price <= clob.getBidPrice());

//注文がエントリ上でマッチすることになると思われる場合、２つ組のprice
//フィールドをヌルに設定し、したがって、最終的にすべての受容者注文が、
//価格によってでなく、サイドのみによってバッチにされることになる
if (orderCrossesBook) {
priceSide.price = null;
}

}

//この式が真である場合、メカニズムは受容者レースについて無効にされ、
//我々はすべての取り消し及び受容者注文を、これらが受信される順序において、
//リアルタイムで処理するべきである
if (!takerRaces && (orderCrossesBook || msg.isCancel())) {
clob.process(msg);
continue;
}

//この式が真である場合、メカニズムは形成者レースについて無効にされ、
//我々は、すべての形成者注文をリアルタイムで処理するべきであり、しかし
//ここで、取り消しを処理するべきではなく、なぜならば、取り消しは受容者
//レースに含まれる可能性があるからである
if (!makerRaces && !orderCrossesBook && !msg.isCancel()) {
clob.process(msg);
continue;
}

//ここで、我々は、特定レースインスタンスのための
//メッセージのBatchを取得している
Batch batch = activeRaces.get(priceSide);

//この式が真である場合、このレースは現在アクティブでなく、なぜならば、
//まだトリガされていないからである。このブロックの内側のロジックは、
//レースが実際にトリガされているか否かを決定する。
if (batch == null) {

//この式が真である場合、我々はレースをトリガしておらず、なぜならば構成
//パラメータが、取り消しがレースをトリガできないと指定しているからであ
//る。したがって、取り消しをリアルタイムで、受信されたとおりに処理する
if (!cancelsTrigger && msg.isCancel()) {
clob.process(msg);
continue;
}

//我々は、レースがいつトリガされたか、形成者レースか受容者レースか、
//その実際の遅延期間は何か等、大量の情報を記憶する必要があり、
//バッチオブジェクトのフィールド内に上記のすべてを行う。
batch = new Batch();

if (msg.isCancel()) {
//我々がここに該当した場合、cancelsTriggerと命名された構成パラメータ
//は、真であるべきである。

//cancelsTriggerが真であるときでさえ、我々は、特定の取り消しがブック
//のトップにおける注文についてあったときに限り、レースを開始したい
boolean cancelAtTob = (msg.isBuy() && msg.getPrice() == clob.getBidPrice())
|| (!msg.isBuy() && msg.getPrice() == clob.getAskPrice());

//取り消しが、ブックのトップにおける注文についてでなかった場合、
//それをリアルタイムで、受信されたとおりに処理する
if (!cancelAtTob) {
clob.process(msg);
continue;
}

//我々がここに該当する場合、取り消しは、受容者レースを実際開始して
//いる。
batch.isTakerRace = true;

} else {

//我々は、ここに該当する場合、取り消しメッセージでなく注文メッセージ
//を有することをわかっている。前のロジックから、この注文が受容者又は
//形成者レースについてかを判別できる。さらに、事前にヌル価格を有する
//ようにキーを設定しており、ゆえに、このことを再度行う必要はない
batch.isTakerRace = orderCrossesBook;
}

//これは、我々が注文をシャッフルしＣＬＯＢに対して排出する前、バッチの
//タイマが稼働することになる時間の長さを設定する。すべて、double演算に
//注意しながらである。Math.random()のjavadocが、我々に、我々が所望
//する属性 -- [0,1)間における一様の連続的な分布を、与えていることに
//留意する。上記分布を、我々は、floorLowerとfloorUpperとの間で適宜
//スケール変更する。
batch.periodMillis = Math.max(
floorLower,
(Math.random() * (floorUpper-floorLower)) + floorLower
);

//これは、バッチ内の第１の注文が受信された時間を設定し、この時間は、
//タイマを「開始する」のに使用される
batch.startTimeMillis = msg.getReceiveTimestamp();

//このバッチを他のアクティブなレースと共に記憶する。実装が、
//activeRaces.get(priceSide)==nullが真であること、すなわち、我々が
//既存のバッチに上書きしていなことを保証する。この上書きはとてもとても
//悪いことになり、なぜならば、我々がそれをする場合、そのバッチの注文が
//排出されない（ＣＬＯＢに対して処理されない）ことになるからである
activeRaces.put(priceSide,batch);
}

//我々がここに該当する場合、バッチオブジェクトは作成されているか又は
//既に存在しており、我々はバッチにメッセージを追加する必要がある。
batch.add(msg);

}

}

}

static class CLOB {

//スタブ：このメソッドは、メッセージ（取り消し又は注文）を中央指値注文
//ブックに対して即時処理させる。疑いを避けるために、「ＣＬＯＢに対して処理する
//こと」は、あり得るマッチについて市場の反対サイドを価格確認すること、
//あり得るマッチについて信用確認すること、ブックに注文を挿入すること、注文を
//マッチングすること、ブックから注文を削除することなどによって、ＣＬＯＢに
//対してメッセージを適用することを意味する。
void process(Msg msg) {}

//スタブ：このメソッドは、ブックビッド価格のトップを、それがホスト内に
//出現するとき、返すことになる（ｃｆ.最後の市場データアップデート）
Double getBidPrice() {return null;}

//スタブ：このメソッドは、ブックアスク価格のトップを、それがホスト内に
//出現するとき、返すことになる（ｃｆ.最後の市場データアップデート）
Double getAskPrice() {return null;}
}

static class Queue<T> {

//スタブ：このメソッドは、商品について蓄積したメッセージのリストを返す。
//これはノンブロッキングであり、ゆえに、メッセージが蓄積されていない場合、
//空のリストを返す
List<T> drain() {return null;}
}

static class Msg {

//スタブ：このメソッドは、取り消しについて真を、
//注文について偽を返す
Boolean isCancel() {return null;}

//スタブ：このメソッドは、２つ組の｛価格，サイド｝を返し、
//これにおいてサイドは、買いについて真、売りについて偽である。
//取り消しメッセージについて、このメソッドは、
//取り消される注文のサイドと価格とを返す
PriceSide priceSideKey() {return null;}

//スタブ：このメソッドは、ホストがメッセージを受信した
//タイムスタンプを、マイクロ秒又はより良好な正確さで返す
Double getReceiveTimestamp() {return null;}

//スタブ：このメソッドは、メッセージを送信した組織
//（別称、参加者／事務所）を表すオブジェクトを返す
Object getOrganization() { return null; }

//スタブ：このメソッドは、注文の価格、又は、
//取り消しメッセージが適用される注文を返す
Double getPrice() {return null;}

//スタブ：このメソッドは、注文のサイド、又は、取り消しメッセージ
//が適用される注文を返す。真が買いに関し、偽が売りに関する。
Boolean isBuy() {return null;}
}

static class Batch {

//バッチに割り当てられることになる次ｉｄを記憶する
private static int nextBatchId = 0;

//実際のバッチのｉｄ
final int batchId;

//これは、フロアの継続時間である
Double periodMillis;

//これは、レース／バッチ期間の開始時間である
Double startTimeMillis;

//これは、レースが形成者レースか受容者レースかを指定する
boolean isTakerRace;

//このマップは、組織から、そのorgが送信したメッセージのリストにである
final Map<Object,List<Msg>> orgToMsgs = new HashMap<Object,List<Msg>>();

Batch() {
//我々は、レース又はバッチのインスタンスとその中のすべての注文とを
//一意に識別することができる必要がある。ゆえに、バッチオブジェクト
//が作成されるたび、バッチオブジェクトは一意ｉｄを割り当てられる。
batchId = nextBatchId++;
}

void add(Msg msg){
//メッセージは、組織単位でグループ化されなければならず、
//それが、下記のコード内で起こっていることである。
//マップのキーは組織であり、マップの値はその組織からの
//注文のリストである。ＮＢ：組織＊内における＊注文の
//順序付けは、このコードで目的を持って保有される。
List<Msg> msgs = orgToMsgs.get(msg.getOrganization());
if (msgs == null) {
msgs = new LinkedList<Msg>();
orgToMsgs.put(msg.getOrganization(),msgs);
}

//このメソッドは、javadocにより、リストの終わりにmsgを追加し、
//これにより、所与の組織内における時間的順序付けを保有する
msgs.add(msg);

}

void shuffleAndDrain(CLOB clob, boolean drainAtOnce) {
//我々は、このレース内の組織のリストを、再順序付けすることができる
//形式で記憶する必要がある。hashmapの（キー）セットが我々のために
//それをすることはないので、我々はここでコピーを作る。
List<Object> orgs = new ArrayList<Object>(orgToMsgs.keySet());

//次に、我々は、クライアント組織の上記リストをシャッフルし、したがって、
//Collections.shuffle()のjavadocにより、各組織は、リストの各位置に出現
//する等しい確率を有する
Collections.shuffle(orgs);

if (drainAtOnce) {
//我々は、ここに該当する場合、組織のメッセージのすべてを、
//次の組織のメッセージに移る前に、排出する。
//ＮＢ特定の組織のメッセージが排出される順序は、
//その組織がこれらメッセージを送信したのと同じ順序
//である。
for (Object org : orgs) {
for (Msg msg : orgToMsgs.get(org)) {
clob.process(msg);
}

//リストをクリアして、
//２つの排出ストラテジ間における実装の一貫性を保つ
//（この実装と下記の実装）
orgToMsgs.get(org).clear();
}
} else {
//我々は、ここに該当する場合、組織にわたり、‘org’の
//順序付けにおいて、一度に組織から１つのメッセージを
//とって、残りの組織がなくなるまで、繰り返し反復する
//必要がある。再びになるが、所与の組織内における
//メッセージの相対的順序付けは、これらメッセージが
//受信された順序付けと同じである。
while (orgs.size() > 0) {
for (Iterator<Object> it = orgs.iterator(); it.hasNext();) {
Object org = it.next();
List<Msg> msgs = orgToMsgs.get(org);

//この組織のための次の注文を削除し、処理する
clob.process(msgs.remove(0));

if (msgs.size() == 0) {
//我々がここに該当する場合、組織は、排出すべき
//残りの注文を有さない。ゆえに我々は、もはや
//この組織を訪問し続ける必要が無い。

it.remove();
}
}
}
}

}

}

static class PriceSide {
Double price;
boolean isBuy;

//hashCode()及びequals()は実装されていないが、
//双方の価格が等しく、双方のサイドが等しい場合、
//２つのPriceSideオブジェクトは等しくなる
}

}

Claims

競争メッセージの公平処理のための方法であって、当該方法はコンピューティング装置により実行され、
第１の時間に商品の第１の送信者に関連付けられた第１のメッセージを受信することと、
前記第１のメッセージの受信に応答して、前記商品に関連付けられた第１の競争枠をトリガすることと、
前記第１のメッセージが受信される前記第１の時間と所定長の時間とに基づいて前記第１の競争枠のバッチ期間を定義することと、
前記バッチ期間内の第２の時間に前記商品の第２の送信者に関連付けられた第２のメッセージを受信することと、
前記第１のメッセージ及び前記第２のメッセージに基づいて、バッチにされたメッセージセットを生成することと、
前記バッチ期間の間に１つ以上のメッセージが受信された送信者のリストを生成することであって、前記送信者のリストは、前記第１の送信者及び前記第２の送信者を少なくとも含む、ことと、
前記送信者のリストをシャッフルして前記送信者のランダムな順序付けを作成することと、
前記バッチ期間の終わりが生じたと決定することと、
前記バッチ期間の終わりが生じたとの前記決定に応答して、前記送信者のランダムな順序付けに基づきさらなる処理のために前記バッチにされたメッセージセットから１つのメッセージを選択することと、
を含む方法。
当該方法は、
第３の時間に前記商品の第３の送信者に関連付けられた第３のメッセージを受信することと、
前記第３のメッセージのメッセージタイプに基づき、前記第３のメッセージが前記第１の競争枠とは異なる前記商品に関連付けられた第２の競争枠をトリガすべきであると決定することと、
前記第３のメッセージが前記第２の競争枠をトリガすべきであるとの決定に応答して、前記商品に関連付けられた前記第２の競争枠をトリガすることと、
をさらに含む、請求項１に記載の方法。
前記第２の競争枠は、前記第１の競争枠の少なくとも一部分と前記第２の競争枠の少なくとも一部分とが同時にアクティブであるように前記バッチ期間の間にトリガされる、請求項２に記載の方法。
前記第１の競争枠は、第１のタイプであり、前記第２の競争枠は、前記第１のタイプとは異なる第２のタイプである、請求項３に記載の方法。
当該方法は、
前記バッチ期間の満了まで前記第１のメッセージ又は前記第２のメッセージを記憶すること、
をさらに含む、請求項１に記載の方法。
当該方法は、
前記バッチ期間内の第３の時間に前記商品の前記第１の送信者に関連付けられた第３のメッセージを受信することと、
前記第１のメッセージ及び前記第３のメッセージに基づいて第１の送信者からの第１のメッセージセットを生成することと、
前記第２のメッセージに基づいて第２の送信者からの第２のメッセージセットを生成することと、
前記第１のメッセージセット又は前記第２のメッセージセットの中から１つのメッセージをランダムに選択することと、
をさらに含む、請求項１に記載の方法。
前記メッセージが前記第１のメッセージセット又は前記第２のメッセージセットの中からランダムに選択されるか否かが、前記第１の競争枠のタイプに基づいて決定される、請求項６に記載の方法。
前記第１のメッセージセットは第１の所定条件を満足し、前記第２のメッセージセットは第２の所定条件を満足する、請求項６に記載の方法。
前記第２のメッセージは、前記第１の競争枠に関連付けられる、請求項１に記載の方法。
競争メッセージの公平処理のためのシステムであって、
コンピューティング装置
を含み、
前記コンピューティング装置は、
第１の時間に商品の第１の送信者に関連付けられた第１のメッセージを受信し、
前記第１のメッセージの受信に応答して、前記商品に関連付けられた第１の競争枠をトリガし、
前記第１のメッセージが受信される前記第１の時間と所定長の時間とに基づいて前記第１の競争枠のバッチ期間を定義し、
前記バッチ期間内の第２の時間に前記商品の第２の送信者に関連付けられた第２のメッセージを受信し、
前記第１のメッセージ及び前記第２のメッセージに基づいて、バッチにされたメッセージセットを生成し、
前記バッチ期間の間に１つ以上のメッセージが受信された送信者のリストを生成することであって、前記送信者のリストは、前記第１の送信者及び前記第２の送信者を少なくとも含み、
前記送信者のリストをシャッフルして前記送信者のランダムな順序付けを作成し、
前記バッチ期間の終わりが生じたと決定し、
前記バッチ期間の終わりが生じたとの前記決定に応答して、前記送信者のランダムな順序付けに基づきさらなる処理のために前記バッチにされたメッセージセットから１つのメッセージを選択する
ように構成される、システム。
コンピューティング装置に請求項１乃至９のうちいずれか１項に記載の方法を実行させるコンピュータプログラム。
競争メッセージの公平処理のための、コンピュータにより実施される方法であって、当該方法は、コンピュータプログラム命令でプログラムされた１つ以上の物理プロセッサを有するコンピューティング装置において実施され、前記コンピュータプログラム命令は、前記１つ以上の物理プロセッサにより実行されるときに、前記コンピューティング装置に請求項１乃至９のうちいずれか１項に記載の方法を実行させる、方法。