特許 5871619 金融市場深度データの高速処理のための方法および装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5871619

(24)【登録日】2016年1月22日

(45)【発行日】2016年3月1日

(54)【発明の名称】金融市場深度データの高速処理のための方法および装置

(51)【国際特許分類】

   G06Q 40/04 20120101AFI20160216BHJP

【ＦＩ】

   G06Q40/04 100

【請求項の数】101

【全頁数】52

(21)【出願番号】特願2011-540957(P2011-540957)

(86)(22)【出願日】2009年12月14日

(65)【公表番号】特表2012-512466(P2012-512466A)

(43)【公表日】2012年5月31日

(86)【国際出願番号】US2009067935

(87)【国際公開番号】WO2010077829

(87)【国際公開日】20100708

【審査請求日】2012年12月13日

(31)【優先権主張番号】61/122,673

(32)【優先日】2008年12月15日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】513192524

【氏名又は名称】アイ・ピー・リザブワー・エル・エル・シー

(74)【代理人】

【識別番号】110001173

【氏名又は名称】特許業務法人川口國際特許事務所

(72)【発明者】

【氏名】テイラー，デイビツド・イー

(72)【発明者】

【氏名】パーソンズ，スコツト

(72)【発明者】

【氏名】ワトリー，ジエレミー・ウオルター

(72)【発明者】

【氏名】ブラツドリー，リチヤード

(72)【発明者】

【氏名】ギヤング，クワメ

(72)【発明者】

【氏名】デウルフ，マイケル

【審査官】 山本 雅士

(56)【参考文献】

【文献】 国際公開第２００７／０１６０７８（ＷＯ，Ａ２）

【文献】 特開２００２−１１７２３２（ＪＰ，Ａ）

【文献】 国際公開第２００７／１４９３７８（ＷＯ，Ａ２）

【文献】 国際公開第２００８／０６３９７３（ＷＯ，Ａ２）

【文献】 国際公開第２００８／０３６１９７（ＷＯ，Ａ２）

【文献】 国際公開第２００７／０７４９０３（ＷＯ，Ａ１）

【文献】 特許第４１８０６４４（ＪＰ，Ｂ１）

【文献】 國友 義久 YOSHIHISA KUNITOMO，データベース 初版，日本，株式会社日科技連出版社 田中 健，２００８年 ６月２８日，第1版，p174-175

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｑ １０／００ − ５０／３４

(57)【特許請求の範囲】

【請求項1】

金融市場深度データから複数の注文ブックを更新する方法であって、
複数の金融商品に対する複数の独立した組の注文レコードを表すメモリ内の複数のデータ構造を保持するステップであって、注文レコードが（１）複数の金融商品に対する複数の指値注文を表す複数の指値注文レコードと、（２）複数の指値注文に対する複数の価格ポイントレコードを含む、ステップと、
それぞれ取引所での金融商品に対する指値注文に関係があり複数のデータフィールドを含む複数の指値注文イベントを受信するステップと、
処理された指値注文イベントに基づきデータ構造内部で独立して指値注文レコードおよび価格ポイントレコードを構築し更新するために複数の指値注文イベントを処理するステップとを含み、
処理するステップが、再構成可能論理回路デバイス、グラフィックスプロセッシングユニット（ＧＰＵ）、およびチップマルチプロセッサ（ＣＭＰ）からなるグループのメンバーにより実行され、
メンバーが処理モジュールを含み、処理モジュールが注文エンジンおよび価格エンジンを含み、処理するステップが、（１）注文エンジンが指値注文イベントに基づきメモリ内の指値注文レコードを更新するステップと、（２）価格エンジンが指値注文イベントに基づきメモリ内の価格ポイントレコードを更新するステップとを含み、注文エンジンおよび価格エンジンが、互いにそれらそれぞれの更新するステップを並列に実行する、方法。

【請求項2】

複数の指値注文イベントのデータフィールドが、指値注文イベントが追加イベントであるか、修正イベントであるか、または削除イベントであるかを示すデータ値で埋められる追加／修正／削除（ＡＭＤ）データフィールドを含み、処理するステップが、メンバーが（１）指値注文イベントのＡＭＤデータフィールドを読み出し（２）読み出されたＡＭＤデータフィールドに従って少なくとも部分的に指値注文イベントデータフィールドに基づき指値注文レコードを構築するステップを含む、請求項１に記載の方法。

【請求項3】

受信するステップが、メンバーが指値注文イベントを受信するステップを含み、処理するステップが、メンバーが（１）受信された指値注文イベントの読み出されたＡＭＤデータフィールドに応答して受信された指値注文イベントが追加イベントであるか、修正イベントであるか、削除イベントであるかを決定するステップと、（２）受信された指値注文イベントが追加イベントであるという決定に応答して、メモリ内に新しい指値注文レコードを生成するステップと、（３）受信された指値注文イベントが修正イベントであるという決定に応答して、（ｉ）受信された指値注文イベントの少なくとも１つのデータフィールドに基づきメモリから指値注文レコードを取り出すステップ、および（ｉｉ）受信された指値注文イベントの少なくとも１つのデータフィールドに基づき取り出された指値注文レコードを更新するステップと、（４）受信された指値注文イベントが削除イベントであるという決定に応答して、受信された指値注文イベントに対応する指値注文レコードを削除するステップとを含む、請求項２に記載の方法。

【請求項4】

複数のデータ構造がハッシュテーブルとして編成され、処理するステップが、メンバーが（１）受信された指値注文イベント内の少なくとも１つのフィールドに基づきハッシュキーを生成するステップと、（２）生成されたハッシュキーを使用してメモリ内の指値注文レコードを特定するステップと、（３）特定された指値注文レコードを取り出すステップと、（４）受信された指値注文イベントの少なくとも１つのデータフィールドに基づき取り出された指値注文レコードを更新するステップとを含む、請求項１から３のいずれか一項に記載の方法。

【請求項5】

指値注文イベントデータフィールドが金融商品記号フィールドを含み、ハッシュキーを生成するステップが、メンバーが少なくとも記号フィールドに基づきハッシュキーを生成するステップを含む、請求項４に記載の方法。

【請求項6】

指値注文イベントデータフィールドが注文識別子フィールドを含み、ハッシュキーを生成するステップが、メンバーが少なくとも注文識別子フィールドに基づきハッシュキーを生成するステップを含む、請求項４または５のいずれか一項に記載の方法。

【請求項7】

各価格ポイントレコードが、複数のデータフィールドを含み、特定の価格での金融商品に対する指値注文の集計を表し、方法が、メンバーがレベル２市場データフィードからの入力ストリームとして指値注文イベントを受信するステップをさらに含み、処理するステップが、メンバーが少なくとも部分的に指値注文イベントデータフィールドに基づき価格ポイントレコードを構築し更新するステップを含む、請求項１から６のいずれか一項に記載の方法。

【請求項8】

金融市場深度データから複数の注文ブックを更新する方法であって、
複数の金融商品に対する複数の独立した組の注文レコードを表すメモリ内の複数のデータ構造を保持するステップであって、注文レコードが（１）複数の金融商品に対する複数の指値注文を表す複数の指値注文レコードと、（２）複数の指値注文に対する複数の価格ポイントレコードを含み、各価格ポイントレコードが、複数のデータフィールドを含み、特定の価格での金融商品に対する指値注文の集計を表す、ステップと、
それぞれ取引所での金融商品に対する指値注文に関係があり複数のデータフィールドを含む複数の指値注文イベントをレベル２市場データフィードからの入力ストリームとして受信するステップと、
少なくとも部分的に指値注文イベントデータフィールドに基づきデータ構造内部で独立して指値注文レコードおよび価格ポイントレコードを構築し更新するために複数の指値注文イベントを処理するステップとを含み、
処理するステップが、再構成可能論理回路デバイス、グラフィックスプロセッシングユニット（ＧＰＵ）、およびチップマルチプロセッサ（ＣＭＰ）からなるグループのメンバーにより実行され、
受信するステップが、メンバーが指値注文イベントを受信するステップを含み、受信された指値注文イベントが価格データフィールドを含み、処理するステップが、メンバーが（１）受信された指値注文イベントに関連する価格ポイントレコードが少なくとも部分的に価格データフィールドに基づきメモリ内に存在するかどうかを決定するステップと、（２）受信された指値注文イベントに関連する価格ポイントレコードがメモリ内に存在するという決定に応答して、（ｉ）メモリから価格ポイントレコードを取り出すステップ、および（ｉｉ）受信された指値注文イベントの少なくとも１つのデータフィールドに基づき、取り出された価格ポイントレコード内のデータフィールドの少なくとも１つを更新するステップと、（３）指値注文イベントに関連する価格ポイントレコードがメモリ内に存在しないという決定に応答して、（ｉ）受信された指値注文イベントに基づき新しい価格ポイントレコードを生成するステップ、および（ｉｉ）メモリ内に生成された新しい価格ポイントレコードを記憶するステップとを含む、方法。

【請求項9】

価格ポイントレコードが、複数の地域価格ポイントレコードおよび複数の複合価格ポイントレコードを含み、各地域価格ポイントレコードが所与の取引所での特定の価格での金融商品に対する指値注文の集計を表し、各複合価格ポイントレコードが複数の異なる取引所にわたる特定の価格での金融商品に対する指値注文の集計を表す、請求項８に記載の方法。

【請求項10】

指値注文レコードおよび価格ポイントレコードが、同じ物理メモリ内に記憶される、請求項１から９のいずれか一項に記載の方法。

【請求項11】

処理するステップが、注文エンジンおよび価格エンジンが同じ物理メモリへのそれらのアクセスをインタリーブするステップをさらに含む、請求項１０に記載の方法。

【請求項12】

指値注文レコードおよび価格ポイントレコードが、異なる物理メモリ内に記憶される、請求項１１に記載の方法。

【請求項13】

処理するステップが、注文エンジンおよび価格エンジンが異なる物理メモリへのそれらのアクセスをインタリーブするステップをさらに含む、請求項１２に記載の方法。

【請求項14】

価格ポイントレコードが、複数の地域価格ポイントレコードおよび複数の複合価格ポイントレコードを含み、各地域価格ポイントレコードが所与の取引所での特定の価格での金融商品に対する指値注文の集計を表し、各複合価格ポイントレコードが複数の異なる取引所にわたる特定の価格での金融商品に対する指値注文の集計を表す、請求項１から１３のいずれか一項に記載の方法。

【請求項15】

複数の指値注文レコードが第１のハッシュテーブルとしてメモリ内に記憶され、複数の価格ポイントレコードが第２のハッシュテーブルとしてメモリ内に記憶され、モジュールが、注文エンジンの上流の注文ハッシュ構成要素および価格エンジンの上流の価格ハッシュ構成要素をさらに含み、処理するステップが、（１）注文ハッシュ構成要素が指値注文イベントの第１のハッシュキーを指値注文イベントの注文参照番号フィールドまたは記号識別子フィールドから生成するステップと、（２）注文エンジンが生成された第１のハッシュキーに基づき第１のハッシュテーブル内で指値注文レコードを特定するステップと、（３）価格ハッシュ構成要素が指値注文イベントの第２のハッシュキーを指値注文イベントの記号識別子フィールド、広域取引所識別子フィールド、および価格フィールドから生成するステップと、（３）価格エンジンが生成された第２のハッシュキーに基づき第２のハッシュテーブル内で価格ポイントレコードを特定するステップとをさらに含む、請求項１から１４のいずれか一項に記載の方法。

【請求項16】

価格ポイントレコードが、複数の地域価格ポイントレコードおよび複数の複合価格ポイントレコードを含み、各地域価格ポイントレコードが所与の取引所での特定の価格での金融商品に対する指値注文の集計を表し、各複合価格ポイントレコードが複数の異なる取引所にわたる特定の価格での金融商品に対する指値注文の集計を表す、請求項１から１３のいずれか一項に記載の方法。

【請求項17】

金融市場深度データから複数の注文ブックを更新する方法であって、
複数の金融商品に対する複数の独立した組の注文レコードを表すメモリ内の複数のデータ構造を保持するステップであって、注文レコードが（１）複数の金融商品に対する複数の指値注文を表す複数の指値注文レコードと、（２）複数の指値注文に対する複数の価格ポイントレコードを含む、ステップと、
それぞれ取引所での金融商品に対する指値注文に関係があり複数のデータフィールドを含む複数の指値注文イベントを受信するステップと、
処理された指値注文イベントに基づきデータ構造内部で独立して指値注文レコードおよび価格ポイントレコードを構築し更新するために複数の指値注文イベントを処理するステップとを含み、
処理するステップが、再構成可能論理回路デバイス、グラフィックスプロセッシングユニット（ＧＰＵ）、およびチップマルチプロセッサ（ＣＭＰ）からなるグループのメンバーにより実行され、
複数の指値注文イベントのそれぞれが属性フラグを含み、属性フラグが指値注文イベントが一時的地域注文（ＥＲＯ）に関係があるかどうかを示し、複数の指値注文レコードが注文属性フィールドを含み、処理するステップが、メンバーが指値注文イベントの属性フラグに基づき指値注文レコード内の注文属性フィールドを埋めて、それにより指値注文レコードがＥＲＯに関係があるかどうかを示すステップを含む、方法。

【請求項18】

複数の価格ポイントレコードが価格属性ベクトルを含み、処理するステップが、メンバーが指値注文イベントの属性フラグに基づき価格ポイントレコード内の価格属性ベクトルを埋めて、それにより価格ポイントレコードがＥＲＯを含むかどうかを示すステップをさらに含む、請求項１７に記載の方法。

【請求項19】

価格属性ベクトルが、価格ポイントレコードに対するＥＲＯの出来高を示す出来高フィールドおよび価格ポイントレコードに対するＥＲＯのカウントを示すカウントフィールドを含む、請求項１８に記載の方法。

【請求項20】

金融市場深度データから複数の注文ブックを更新する方法であって、
複数の金融商品に対する複数の独立した組の注文レコードを表すメモリ内の複数のデータ構造を保持するステップであって、注文レコードが（１）複数の金融商品に対する複数の指値注文を表す複数の指値注文レコードと、（２）複数の指値注文に対する複数の価格ポイントレコードを含む、ステップと、
それぞれ取引所での金融商品に対する指値注文に関係があり複数のデータフィールドを含む複数の指値注文イベントを受信するステップと、
処理された指値注文イベントに基づきデータ構造内部で独立して指値注文レコードおよび価格ポイントレコードを構築し更新するために複数の指値注文イベントを処理するステップとを含み、
処理するステップが、再構成可能論理回路デバイス、グラフィックスプロセッシングユニット（ＧＰＵ）、およびチップマルチプロセッサ（ＣＭＰ）からなるグループのメンバーにより実行され、
複数の指値注文イベントのそれぞれが属性フラグを含み、属性フラグが指値注文イベントが暗黙の流動性に関連するかどうかを示し、複数の指値注文レコードが注文属性フィールドを含み、処理するステップが、メンバーが指値注文イベントの属性フラグに基づき指値注文レコード内の注文属性フィールドを埋めて、それにより指値注文レコードが暗黙の流動性に関連するかどうかを示すステップを含む、方法。

【請求項21】

複数の価格ポイントレコードが価格属性ベクトルを含み、処理するステップが、メンバーが指値注文イベントの属性フラグに基づき価格ポイントレコード内の価格属性ベクトルを埋めて、それにより価格ポイントレコードが暗黙の流動性に関連するかどうかを示すステップをさらに含む、請求項２０に記載の方法。

【請求項22】

価格属性ベクトルが、価格ポイントレコードに対する暗黙の流動性の出来高を示す出来高フィールドおよび価格ポイントレコードに対する暗黙の流動性に関連する注文のカウントを示すカウントフィールドを含む、請求項２１に記載の方法。

【請求項23】

金融市場深度データから複数の注文ブックを更新する方法であって、
複数の金融商品に対する複数の独立した組の注文レコードを表すメモリ内の複数のデータ構造を保持するステップであって、注文レコードが（１）複数の金融商品に対する複数の指値注文を表す複数の指値注文レコードと、（２）複数の指値注文に対する複数の価格ポイントレコードを含む、ステップと、
それぞれ取引所での金融商品に対する指値注文に関係があり複数のデータフィールドを含む複数の指値注文イベントを受信するステップと、
処理された指値注文イベントに基づきデータ構造内部で独立して指値注文レコードおよび価格ポイントレコードを構築し更新するために複数の指値注文イベントを処理するステップとを含み、
処理するステップが、再構成可能論理回路デバイス、グラフィックスプロセッシングユニット（ＧＰＵ）、およびチップマルチプロセッサ（ＣＭＰ）からなるグループのメンバーにより実行され、
複数の指値注文イベントのそれぞれが属性フラグを含み、属性フラグが指値注文イベントが一時的地域注文（ＥＲＯ）に関係があるかどうかおよび指値注文イベントが暗黙の流動性に関連するかどうかを示し、複数の指値注文レコードが注文属性ベクトルを含み、処理するステップが、メンバーが指値注文イベントの属性フラグに基づき指値注文レコード内の注文属性ベクトルを埋めて、それにより指値注文レコードがＥＲＯに関係があるか、暗黙の流動性に関連するかを示すステップを含む、方法。

【請求項24】

複数の価格ポイントレコードが価格属性ベクトルを含み、処理するステップが、メンバーが指値注文イベントの属性フラグに基づき価格ポイントレコード内の価格属性ベクトルを埋めて、それにより価格ポイントレコードがＥＲＯを含むか、暗黙の流動性に関連するかを示すステップをさらに含む、請求項２３に記載の方法。

【請求項25】

価格属性ベクトルが、（１）価格ポイントレコードに対するＥＲＯの出来高を示すＥＲＯ出来高フィールド、（２）価格ポイントレコードに対するＥＲＯのカウントを示すＥＲＯカウントフィールド、（３）価格ポイントレコードに対する暗黙の流動性の出来高を示す暗黙の流動性出来高フィールドおよび（４）価格ポイントレコードに対する暗黙の流動性に関連する注文のカウントを示す暗黙の流動性カウントフィールドを含む、請求項２４に記載の方法。

【請求項26】

メンバーが再構成可能論理回路デバイスを含み、再構成可能論理回路デバイスが処理するステップを実行する、請求項１から２５のいずれか一項に記載の方法。

【請求項27】

再構成可能論理回路デバイスが、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）を含み、ＦＰＧＡが処理するステップを実行する、請求項２６に記載の方法。

【請求項28】

メンバーがＧＰＵを含み、ＧＰＵが処理するステップを実行する、請求項１から２５のいずれか一項に記載の方法。

【請求項29】

メンバーがＣＭＰを含み、ＣＭＰが処理するステップを実行する、請求項１から２５のいずれか一項に記載の方法。

【請求項30】

方法ステップがチッカ装置内部で実行される、請求項１から２９のいずれか一項に記載の方法。

【請求項31】

メンバーがコプロセッサである、請求項１から３０のいずれか一項に記載の方法。

【請求項32】

金融市場深度データから複数の注文ブックを更新するためのシステムであって、
複数の金融商品に対する複数の独立した組の注文レコードを表す複数のデータ構造を記憶するためのメモリであって、注文レコードが（１）複数の金融商品に対する複数の指値注文を表す複数の指値注文レコードと、（２）複数の指値注文に対する複数の価格ポイントレコードとを含む、メモリと、
再構成可能論理回路デバイス、グラフィックスプロセッシングユニット（ＧＰＵ）、およびチップマルチプロセッサ（ＣＭＰ）からなるグループのメンバーであって、（１）それぞれ取引所での金融商品に対する指値注文に関係があり複数のデータフィールドを含む複数の指値注文イベントを受信し、（２）処理された指値注文イベントに基づきデータ構造内部で独立して指値注文レコードおよび価格ポイントレコードを構築し更新するように構成されるメンバーとを含み、
メンバーが処理モジュールを含み、処理モジュールが注文エンジンおよび価格エンジンを含み、注文エンジンが指値注文イベントに基づきメモリ内の指値注文レコードを更新するように構成され、価格エンジンが指値注文イベントに基づきメモリ内の価格ポイントレコードを更新するように構成され、注文エンジンおよび価格エンジンが、互いにそれらそれぞれの更新する動作を並列に実行するように構成される、システム。

【請求項33】

複数の指値注文イベントのデータフィールドが、指値注文イベントが追加イベントであるか、修正イベントであるか、または削除イベントであるかを示すデータ値で埋められる追加／修正／削除（ＡＭＤ）データフィールドを含み、メンバーが、（１）指値注文イベントのＡＭＤデータフィールドを読み出し（２）読み出されたＡＭＤデータフィールドに従って少なくとも部分的に指値注文イベントデータフィールドに基づき指値注文レコードを構築するようにさらに構成される、請求項３２に記載のシステム。

【請求項34】

メンバーが、（１）受信された指値注文イベントの読み出されたＡＭＤデータフィールドに応答して受信された指値注文イベントが追加イベントであるか、修正イベントであるか、削除イベントであるかを決定し、（２）受信された指値注文イベントが追加イベントであるという決定に応答して、メモリ内に新しい指値注文レコードを生成し、（３）受信された指値注文イベントが修正イベントであるという決定に応答して、（ｉ）受信された指値注文イベントの少なくとも１つのデータフィールドに基づきメモリから指値注文レコードを取り出し、および（ｉｉ）受信された指値注文イベントの少なくとも１つのデータフィールドに基づき、取り出された指値注文レコードを更新し、（４）受信された指値注文イベントが削除イベントであるという決定に応答して、受信された指値注文イベントに対応する指値注文レコードを削除するようにさらに構成される、請求項３３に記載のシステム。

【請求項35】

複数のデータ構造がハッシュテーブルとして編成され、メンバーが、（１）受信された指値注文イベント内の少なくとも１つのフィールドに基づきハッシュキーを生成し、（２）生成されたハッシュキーを使用してメモリ内の指値注文レコードを特定し、（３）特定された指値注文レコードを取り出し、（４）受信された指値注文イベントの少なくとも１つのデータフィールドに基づき取り出された指値注文レコードを更新するようにさらに構成される、請求項３２から３４のいずれか一項に記載のシステム。

【請求項36】

指値注文イベントデータフィールドが金融商品記号フィールドを含み、メンバーが、少なくとも記号フィールドに基づきハッシュキーを生成するようにさらに構成される、請求項３５に記載のシステム。

【請求項37】

指値注文イベントデータフィールドが注文識別子フィールドを含み、メンバーが、少なくとも注文識別子フィールドに基づきハッシュキーを生成するようにさらに構成される、請求項３５または３６のいずれか一項に記載のシステム。

【請求項38】

各価格ポイントレコードが、複数のデータフィールドを含み、特定の価格での金融商品に対する指値注文の集計を表し、メンバーが、（１）レベル２市場データフィードからの入力ストリームとして指値注文イベントを受信し、（２）少なくとも部分的に指値注文イベントデータフィールドに基づき価格ポイントレコードを構築し更新するようにさらに構成される、請求項３２から３７のいずれか一項に記載のシステム。

【請求項39】

金融市場深度データから複数の注文ブックを更新するためのシステムであって、
複数の金融商品に対する複数の独立した組の注文レコードを表す複数のデータ構造を記憶するためのメモリであって、注文レコードが（１）複数の金融商品に対する複数の指値注文を表す複数の指値注文レコードと、（２）複数の指値注文に対する複数の価格ポイントレコードとを含み、各価格ポイントレコードが、複数のデータフィールドを含み、特定の価格での金融商品に対する指値注文の集計を表す、メモリと、
再構成可能論理回路デバイス、グラフィックスプロセッシングユニット（ＧＰＵ）、およびチップマルチプロセッサ（ＣＭＰ）からなるグループのメンバーであって、（１）それぞれ取引所での金融商品に対する指値注文に関係があり複数のデータフィールドを含む複数の指値注文イベントをレベル２市場データフィードからの入力ストリームとして受信し、（２）少なくとも部分的に指値注文イベントデータフィールドに基づきデータ構造内部で独立して指値注文レコードおよび価格ポイントレコードを構築し更新するように構成されるメンバーとを含み、
メンバーが、（１）価格データフィールドを含む指値注文イベントを受信し、（２）受信された指値注文イベントに関連する価格ポイントレコードが少なくとも部分的に価格データフィールドに基づきメモリ内に存在するかどうかを決定し、（３）受信された指値注文イベントに関連する価格ポイントレコードがメモリ内に存在するという決定に応答して、（ｉ）メモリから価格ポイントレコードを取り出し、および（ｉｉ）受信された指値注文イベントの少なくとも１つのデータフィールドに基づき、取り出された価格ポイントレコード内のデータフィールドの少なくとも１つを更新し、（４）指値注文イベントに関連する価格ポイントレコードがメモリ内に存在しないという決定に応答して、（ｉ）受信された指値注文イベントに基づき新しい価格ポイントレコードを生成し、および（ｉｉ）生成された新しい価格ポイントレコードをメモリ内に記憶するようにさらに構成される、システム。

【請求項40】

価格ポイントレコードが、複数の地域価格ポイントレコードおよび複数の複合価格ポイントレコードを含み、各地域価格ポイントレコードが所与の取引所での特定の価格での金融商品に対する指値注文の集計を表し、各複合価格ポイントレコードが複数の異なる取引所にわたる特定の価格での金融商品に対する指値注文の集計を表す、請求項３９に記載のシステム。

【請求項41】

メモリが、指値注文レコードおよび価格ポイントレコードが記憶される単一の物理メモリを含む、請求項３２から４０のいずれか一項に記載のシステム。

【請求項42】

注文エンジンおよび価格エンジンが、単一の物理メモリへのそれらのアクセスをインタリーブするようにさらに構成される、請求項４１に記載のシステム。

【請求項43】

メモリが、指値注文レコードが記憶される第１の物理メモリおよび価格ポイントレコードが記憶される第２の物理メモリを含む、請求項３２から４０のいずれか一項に記載のシステム。

【請求項44】

注文エンジンおよび価格エンジンが、第１および第２の物理メモリへのそれらのアクセスをインタリーブするようにさらに構成される、請求項４３に記載のシステム。

【請求項45】

価格ポイントレコードが、複数の地域価格ポイントレコードおよび複数の複合価格ポイントレコードを含み、各地域価格ポイントレコードが所与の取引所での特定の価格での金融商品に対する指値注文の集計を表し、各複合価格ポイントレコードが複数の異なる取引所にわたる特定の価格での金融商品に対する指値注文の集計を表す、請求項３３から４４のいずれか一項に記載のシステム。

【請求項46】

複数の指値注文レコードが第１のハッシュテーブルとしてメモリ内に記憶され、複数の価格ポイントレコードが第２のハッシュテーブルとしてメモリ内に記憶され、モジュールが、注文エンジンの上流の注文ハッシュ構成要素および価格エンジンの上流の価格ハッシュ構成要素をさらに含み、
注文ハッシュ構成要素が、指値注文イベントの第１のハッシュキーを指値注文イベントの注文参照番号フィールドまたは記号識別子フィールドから生成するように構成され、
注文エンジンが、生成された第１のハッシュキーに基づき第１のハッシュテーブル内で指値注文レコードを特定するようにさらに構成され、
価格ハッシュ構成要素が、指値注文イベントの第２のハッシュキーを指値注文イベントの記号識別子フィールド、広域取引所識別子フィールド、および価格フィールドから生成するように構成され、
価格エンジンが、生成された第２のハッシュキーに基づき第２のハッシュテーブル内で価格ポイントレコードを特定するようにさらに構成される、請求項３２から４５のいずれか一項に記載のシステム。

【請求項47】

価格ポイントレコードが、複数の地域価格ポイントレコードおよび複数の複合価格ポイントレコードを含み、各地域価格ポイントレコードが所与の取引所での特定の価格での金融商品に対する指値注文の集計を表し、各複合価格ポイントレコードが複数の異なる取引所にわたる特定の価格での金融商品に対する指値注文の集計を表す、請求項４６に記載のシステム。

【請求項48】

金融市場深度データから複数の注文ブックを更新するためのシステムであって、
複数の金融商品に対する複数の独立した組の注文レコードを表す複数のデータ構造を記憶するためのメモリであって、注文レコードが（１）複数の金融商品に対する複数の指値注文を表す複数の指値注文レコードと、（２）複数の指値注文に対する複数の価格ポイントレコードとを含む、メモリと、
再構成可能論理回路デバイス、グラフィックスプロセッシングユニット（ＧＰＵ）、およびチップマルチプロセッサ（ＣＭＰ）からなるグループのメンバーであって、（１）それぞれ取引所での金融商品に対する指値注文に関係があり複数のデータフィールドを含む複数の指値注文イベントを受信し、（２）処理された指値注文イベントに基づきデータ構造内部で独立して指値注文レコードおよび価格ポイントレコードを構築し更新するように構成されるメンバーとを含み、
複数の指値注文イベントのそれぞれが属性フラグを含み、属性フラグが指値注文イベントが一時的地域注文（ＥＲＯ）に関係があるかどうかを示し、複数の指値注文レコードが注文属性フィールドを含み、メンバーが、指値注文イベントの属性フラグに基づき指値注文レコード内の注文属性フィールドを埋めて、それにより指値注文レコードがＥＲＯに関係があるかどうかを示すようにさらに構成される、システム。

【請求項49】

複数の価格ポイントレコードが価格属性ベクトルを含み、メンバーが、指値注文イベントの属性フラグに基づき価格ポイントレコード内の価格属性ベクトルを埋めて、それにより価格ポイントレコードがＥＲＯを含むかどうかを示すようにさらに構成される、請求項４８に記載のシステム。

【請求項50】

価格属性ベクトルが、価格ポイントレコードに対するＥＲＯの出来高を示す出来高フィールドおよび価格ポイントレコードに対するＥＲＯのカウントを示すカウントフィールドを含む、請求項４９に記載のシステム。

【請求項51】

金融市場深度データから複数の注文ブックを更新するためのシステムであって、
複数の金融商品に対する複数の独立した組の注文レコードを表す複数のデータ構造を記憶するためのメモリであって、注文レコードが（１）複数の金融商品に対する複数の指値注文を表す複数の指値注文レコードと、（２）複数の指値注文に対する複数の価格ポイントレコードとを含む、メモリと、
再構成可能論理回路デバイス、グラフィックスプロセッシングユニット（ＧＰＵ）、およびチップマルチプロセッサ（ＣＭＰ）からなるグループのメンバーであって、（１）それぞれ取引所での金融商品に対する指値注文に関係があり複数のデータフィールドを含む複数の指値注文イベントを受信し、（２）処理された指値注文イベントに基づきデータ構造内部で独立して指値注文レコードおよび価格ポイントレコードを構築し更新するように構成されるメンバーとを含み、
複数の指値注文イベントのそれぞれが属性フラグを含み、属性フラグが指値注文イベントが暗黙の流動性に関連するかどうかを示し、複数の指値注文レコードが注文属性フィールドを含み、メンバーが、指値注文イベントの属性フラグに基づき指値注文レコード内の注文属性フィールドを埋めて、それにより指値注文レコードが暗黙の流動性に関連するかどうかを示すようにさらに構成される、システム。

【請求項52】

複数の価格ポイントレコードが価格属性ベクトルを含み、メンバーが、指値注文イベントの属性フラグに基づき価格ポイントレコード内の価格属性ベクトルを埋めて、それにより価格ポイントレコードが暗黙の流動性に関連するかどうかを示すようにさらに構成される、請求項５１に記載のシステム。

【請求項53】

価格属性ベクトルが、価格ポイントレコードに対する暗黙の流動性の出来高を示す出来高フィールドおよび価格ポイントレコードに対する暗黙の流動性に関連する注文のカウントを示すカウントフィールドを含む、請求項５２に記載のシステム。

【請求項54】

金融市場深度データから複数の注文ブックを更新するためのシステムであって、
複数の金融商品に対する複数の独立した組の注文レコードを表す複数のデータ構造を記憶するためのメモリであって、注文レコードが（１）複数の金融商品に対する複数の指値注文を表す複数の指値注文レコードと、（２）複数の指値注文に対する複数の価格ポイントレコードとを含む、メモリと、
再構成可能論理回路デバイス、グラフィックスプロセッシングユニット（ＧＰＵ）、およびチップマルチプロセッサ（ＣＭＰ）からなるグループのメンバーであって、（１）それぞれ取引所での金融商品に対する指値注文に関係があり複数のデータフィールドを含む複数の指値注文イベントを受信し、（２）処理された指値注文イベントに基づきデータ構造内部で独立して指値注文レコードおよび価格ポイントレコードを構築し更新するように構成されるメンバーとを含み、
複数の指値注文イベントのそれぞれが属性フラグを含み、属性フラグが指値注文イベントが一時的地域注文（ＥＲＯ）に関係があるかどうかおよび指値注文イベントが暗黙の流動性に関連するかどうかを示し、複数の指値注文レコードが注文属性ベクトルを含み、メンバーが、指値注文イベントの属性フラグに基づき指値注文レコード内の注文属性ベクトルを埋めて、それにより指値注文レコードがＥＲＯに関係があるか、暗黙の流動性に関連するかを示すようにさらに構成される、システム。

【請求項55】

複数の価格ポイントレコードが価格属性ベクトルを含み、メンバーが、指値注文イベントの属性フラグに基づき価格ポイントレコード内の価格属性ベクトルを埋めて、それにより価格ポイントレコードがＥＲＯを含むか、暗黙の流動性に関連するかを示すようにさらに構成される、請求項５４に記載のシステム。

【請求項56】

価格属性ベクトルが、（１）価格ポイントレコードに対するＥＲＯの出来高を示すＥＲＯ出来高フィールド、（２）価格ポイントレコードに対するＥＲＯのカウントを示すＥＲＯカウントフィールド、（３）価格ポイントレコードに対する暗黙の流動性の出来高を示す暗黙の流動性出来高フィールドおよび（４）価格ポイントレコードに対する暗黙の流動性に関連する注文のカウントを示す暗黙の流動性カウントフィールドを含む、請求項５５に記載のシステム。

【請求項57】

メンバーが、再構成可能論理回路デバイスを含む、請求項３２から５６のいずれか一項に記載のシステム。

【請求項58】

再構成可能論理回路デバイスが、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）を含む、請求項５７に記載のシステム。

【請求項59】

メンバーがＧＰＵを含む、請求項３２から５６のいずれか一項に記載のシステム。

【請求項60】

メンバーがＣＭＰを含む、請求項３２から５６のいずれか一項に記載のシステム。

【請求項61】

メモリおよびメンバーがチッカ装置内部に存在する、請求項３２から６０のいずれか一項に記載のシステム。

【請求項62】

メンバーがコプロセッサである、請求項３２から６１のいずれか一項に記載のシステム。

【請求項63】

再構成可能論理回路デバイス、グラフィックスプロセッシングユニット（ＧＰＵ）、およびチップマルチプロセッサ（ＣＭＰ）からなるグループのメンバーであって、メモリと通信するためのメンバーを含む装置であって、メンバーが、複数の金融商品に対する複数の指値注文イベントに関係があるストリーミングデータを処理するためにメンバー上に導入されるモジュールを有し、モジュールが、
少なくとも部分的に指値注文イベントに基づき注文ハッシュキーを生成するように構成される注文ハッシュモジュールと、
（１）生成された注文ハッシュキーに少なくとも部分的に基づきメモリ内に存在するデータ構造から指値注文レコードを取り出し、（２）少なくとも部分的に指値注文イベントに基づき、取り出された指値注文レコードを更新するように構成される注文エンジンモジュールと
少なくとも部分的に指値注文イベントに基づき価格ハッシュキーを生成するように構成される価格ハッシュモジュールと、
（１）生成された価格ハッシュキーに少なくとも部分的に基づきメモリ内に存在するデータ構造から価格ポイントレコードを取り出し、（２）少なくとも部分的に指値注文イベントに基づき、取り出された価格ポイントレコードを更新するように構成される価格エンジンモジュールとを含む、装置。

【請求項64】

価格エンジンモジュールが、更新された価格ポイントレコードに少なくとも部分的に基づき複数のデータフィールドで指値注文イベントを強化するようにさらに構成される、請求項６３に記載の装置。

【請求項65】

注文ハッシュモジュール、注文エンジンモジュール、価格ハッシュモジュール、および価格エンジンモジュールが、メンバーモジュール内部でパイプラインの形に配置される、請求項６３または６４のいずれか一項に記載の装置。

【請求項66】

メモリが外部メモリ装置を含み、メンバーモジュールが、注文エンジンモジュールおよび価格エンジンモジュールからの複数のメモリアクセス要求を調整するためのアービタモジュールをさらに含む、請求項６３から６５のいずれか一項に記載の装置。

【請求項67】

メモリ装置が指値注文レコードを記憶するための第１のメモリ装置、および価格ポイントレコードを記憶するための第２のメモリ装置を含む、請求項６６に記載の装置。

【請求項68】

メンバーモジュールが、取り出された指値注文レコードをキャッシュするための、注文エンジンモジュールと通信状態にあるキャッシュをさらに含む、請求項６３から６７のいずれか一項に記載の装置。

【請求項69】

メンバーモジュールが、取り出された価格ポイントレコードをキャッシュするための、価格エンジンモジュールと通信状態にあるキャッシュをさらに含む、請求項６３から６８のいずれか一項に記載の装置。

【請求項70】

メンバーモジュールが、指値注文イベント内の価格フィールドを正規化するように構成される、注文エンジンから上流にある価格正規化モジュールをさらに含む、請求項６３から６９のいずれか一項に記載の装置。

【請求項71】

メンバーモジュールが、注文エンジンモジュールと通信状態にある作業ＦＩＦＯモジュールをさらに含む、請求項６３から７０のいずれか一項に記載の装置。

【請求項72】

メンバーモジュールが、注文エンジンモジュールと通信状態にあるリフレッシュ待ち行列モジュールをさらに含む、請求項６３から７１のいずれか一項に記載の装置。

【請求項73】

メンバーモジュールが、価格エンジンモジュールと通信状態にある作業ＦＩＦＯモジュールをさらに含む、請求項６３から７２のいずれか一項に記載の装置。

【請求項74】

メンバーモジュールが、価格エンジンモジュールと通信状態にあるリフレッシュ待ち行列モジュールをさらに含む、請求項６３から７３のいずれか一項に記載の装置。

【請求項75】

メンバーモジュールが、（１）指値注文イベントデータのストリームを受信し、（２）メンバーモジュール内部で処理するためにストリーミングデータから指値注文イベントの複数のフィールドを抽出するように構成されるエクストラクタモジュールをさらに含む、請求項６３から７４のいずれか一項に記載の装置。

【請求項76】

メンバーモジュールが、強化された指値注文イベントの出力ストリームを生成するように構成される、エクストラクタモジュールおよび価格エンジンモジュールと通信状態にあるブレンダモジュールをさらに含む、請求項７５に記載の装置。

【請求項77】

メンバーが再構成可能論理回路デバイスを含む、請求項６３から７６のいずれか一項に記載の装置。

【請求項78】

メンバーモジュールがファームウェア内に実装される、請求項６３から７７のいずれか一項に記載の装置。

【請求項79】

再構成可能論理回路デバイスが、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）を含む、請求項７７または７８のいずれか一項に記載の装置。

【請求項80】

メンバーがＧＰＵを含む、請求項６３から７６のいずれか一項に記載の装置。

【請求項81】

メンバーがＣＭＰを含む、請求項６３から７６のいずれか一項に記載の装置。

【請求項82】

メンバーがチッカ装置内部に存在する、請求項６３から８１のいずれか一項に記載の装置。

【請求項83】

メンバーがコプロセッサである、請求項６３から８２のいずれか一項に記載の装置。

【請求項84】

再構成可能論理回路デバイス、グラフィックスプロセッシングユニット（ＧＰＵ）、およびチップマルチプロセッサ（ＣＭＰ）からなるグループのメンバーであって、メモリと通信するためのメンバーを含む装置であって、メンバーが、複数の金融商品に関係がある注文ブックデータのストリームビューを含むストリーミングデータを処理するためにメンバー上に導入されるモジュールを有し、ストリームビューが複数の更新イベントを含み、各更新イベントが指値注文イベントデータおよび関連する注文ブックデータを含み、モジュールが、
それぞれ（１）注文ブック内のレコードのソートされたリストを示す、メモリ内に存在するデータ構造からデータを取り出し、（２）少なくとも部分的に各更新イベントに基づき、取り出されたデータに対するソートされたリストを更新するように構成される複数の並列ソーティングエンジンモジュールを含む、装置。

【請求項85】

メンバーモジュールが、（１）各更新イベントに対してソーティングエンジンモジュールを選択し、（２）各更新イベントを各更新イベントのために選択されたソーティングエンジンモジュールに配布するように構成されるディスパッチャモジュールをさらに含む、請求項８４に記載の装置。

【請求項86】

メモリが外部メモリ装置を含み、メンバーモジュールが、ディスパッチャモジュールおよびソーティングエンジンモジュールからの複数のメモリアクセス要求を調整するためのアービタモジュールをさらに含む、請求項８５に記載の装置。

【請求項87】

メンバーモジュールが、ディスパッチャモジュールと通信状態にあるキャッシュをさらに含む、請求項８５または８６のいずれか一項に記載の装置。

【請求項88】

メンバーモジュールが、ディスパッチャモジュールをソーティングエンジンモジュールとインタフェースで接続するように構成されるディスパッチャバッファをさらに含む、請求項８５から８７のいずれか一項に記載の装置。

【請求項89】

メンバーモジュールが、ディスパッチャモジュールおよびソーティングエンジンモジュールと通信状態にあるメモリマネージャモジュールをさらに含む、請求項８５から８８のいずれか一項に記載の装置。

【請求項90】

メンバーモジュールが、ディスパッチャモジュールと通信状態にある作業ＦＩＦＯモジュールをさらに含む、請求項８５から８９のいずれか一項に記載の装置。

【請求項91】

メンバーモジュールが、ディスパッチャモジュールと通信状態にあるリフレッシュ待ち行列モジュールをさらに含む、請求項８５から９０のいずれか一項に記載の装置。

【請求項92】

メンバーモジュールが、取り出されたデータをキャッシュするための、ソーティングエンジンモジュールと通信状態にある複数のキャッシュをさらに含む、請求項８４から９１のいずれか一項に記載の装置。

【請求項93】

メンバーモジュールが、（１）更新イベントのストリームを受信し、（２）メンバーモジュール内部で処理するためにストリーミング更新イベントから複数のフィールドを抽出するように構成されるエクストラクタモジュールをさらに含む、請求項８４から９２のいずれか一項に記載の装置。

【請求項94】

メンバーモジュールが、ソート順序データで強化されたイベントの出力ストリームを生成するように構成される、エクストラクタモジュールおよびソーティングエンジンモジュールと通信状態にあるブレンダモジュールをさらに含む、請求項９３に記載の装置。

【請求項95】

メンバーモジュールが、ソーティングエンジンモジュールと通信状態にある複数の作業ＦＩＦＯモジュールをさらに含む、請求項８４から９４のいずれか一項に記載の装置。

【請求項96】

メンバーモジュールが、ソーティングエンジンモジュールと通信状態にある複数のリフレッシュ待ち行列モジュールをさらに含む、請求項８４から９５のいずれか一項に記載の装置。

【請求項97】

メンバーが再構成可能論理回路デバイスを含む、請求項８４から９６のいずれか一項に記載の装置。

【請求項98】

再構成可能論理回路デバイスが、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）を含む、請求項９７に記載の装置。

【請求項99】

メンバーがＧＰＵを含む、請求項８４から９６のいずれか一項に記載の装置。

【請求項100】

メンバーがＣＭＰを含む、請求項８４から９６のいずれか一項に記載の装置。

【請求項101】

メンバーがコプロセッサである、請求項８４から１００のいずれか一項に記載の装置。

【発明の詳細な説明】

【技術分野】

【0001】

本出願は、開示全体が参照により本明細書に組み込まれる、「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｈｉｇｈ−Ｓｐｅｅｄ Ｐｒｏｃｅｓｓｉｎｇ ｏｆ Ｆｉｎａｎｃｉａｌ Ｍａｒｋｅｔ Ｄｅｐｔｈ Ｄａｔａ」と題する、２００８年１２月１５日に出願された米国特許出願第６１／１２２，６７３号明細書の優先権を主張する。

【0002】

本出願は、それぞれの開示全体が参照により本明細書に組み込まれる、（１）米国特許出願公開第２００９／０１８２６８３号明細書として公開された、「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｌｏｗ Ｌａｔｅｎｃｙ Ｂａｓｋｅｔ Ｃａｌｃｕｌａｔｉｏｎ」と題する、２００８年１月１１日に提出された米国特許出願第１２／０１３，３０２号明細書、（２）米国特許出願公開第２００８／０２４３６７５号明細書として公開された、「Ｈｉｇｈ Ｓｐｅｅｄ Ｐｒｏｃｅｓｓｉｎｇ ｏｆ Ｆｉｎａｎｃｉａｌ Ｉｎｆｏｒｍａｔｉｏｎ Ｕｓｉｎｇ ＦＰＧＡ Ｄｅｖｉｃｅｓ」と題する、２００７年６月１９日に提出された米国特許出願第１１／７６５，３０６号明細書、（３）米国特許出願公開第２００７／０２９４１５７号明細書として公開された、「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｈｉｇｈ Ｓｐｅｅｄ Ｏｐｔｉｏｎｓ Ｐｒｉｃｉｎｇ」と題する、２００７年６月８日に提出された米国特許出願第１１／７６０，２１１号明細書、および（４）米国特許出願公開第２００７／００７８８３７号明細書として公開された、「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｐｒｏｃｅｓｓｉｎｇ Ｆｉｎａｎｃｉａｌ Ｉｎｆｏｒｍａｔｉｏｎ ａｔ Ｈａｒｄｗａｒｅ Ｓｐｅｅｄｓ Ｕｓｉｎｇ ＦＰＧＡ Ｄｅｖｉｃｅｓ」と題する、２００６年１１月２０日提出された米国特許出願第１１／５６１，６１５号明細書に関する。

【背景技術】

【0003】

以下の節は本明細書で使用される様々な用語に対するいくつかの定義を提供する。これらの節はまた、これらの用語に関係する予備知識も提供する。

【0004】

金融商品：本明細書で使用されるように、「金融商品」は、典型的には契約が売りに出せる、企業体または政府機関に関係する株式所有権、負債、または信用貸しを表す契約を指す。金融商品の例が株式、債券、オプション、商品、通貨市場で売買される通貨などを含むが、これらの品目が金融取引市場の外でどのように使用されるかという意味で現金または小切手を含まない（すなわち、現金または小切手を使用して食料雑貨店で食料雑貨類を購入することは、本明細書で使用されるような「金融商品」という用語により取り扱われない。同様に、デビットカードを使用して現金自動預け払い機から現金で１００ドル引き出すことは、本明細書で使用されるような「金融商品」という用語により取り扱われない）。

【0005】

金融市場データ：本明細書で使用されるように、「金融市場データ」という用語は、金融商品を買うまたは売る新しい申込み、金融商品の販売完了の指示、金融商品の以前に報告された販売の訂正の通知、そのような取引に関係する管理メッセージなどを個々に表す一連のメッセージ内に含まれるデータ、またはそれらのメッセージから得られるデータを指す。金融市場データを含むメッセージのフィードがいくつかの情報源から利用でき、様々なフィードタイプで、たとえば、本明細書で議論されるようなレベル１フィードおよびレベル２フィードの形で存在する。

【0006】

バスケット：本明細書で使用されるように、「バスケット」という用語はそれぞれ１つまたは複数の値を有する複数の要素を含む集合を指す。集合は、集合内の複数の要素の値から得られる１つまたは複数の正味価値（ＮＶ）を割り当てられることがある。たとえば、バスケットが様々な科学実験からのデータポイントの集合でもよい。各データポイントは関連付けられた値、たとえばサイズ、質量などを有することがある。サイズの加重和を計算することによりサイズＮＶが、質量の加重和を計算することにより質量ＮＶなどが得られることがある。バスケットの別の例が、以下に説明されるような金融商品の集合である。

【0007】

金融商品バスケット：本明細書で使用されるように、「金融商品バスケット」という用語は、要素が金融データを含むバスケットを指す。金融商品バスケットは、バスケット内の要素の価値から得られる１つまたは複数の純資産価値（ＮＡＶ）を割り当てられることがある。バスケット内に含まれることがある金融商品の例が有価証券（株式）、債券、オプション、ミューチュアルファンド、上場投資信託などである。金融商品バスケットは標準インデックス、上場投資信託（ＥＴＦ）、ミューチュアルファンド、個人のポートフォリオなどを表すことがある。バスケット内の金融商品のそれぞれに対する最終販売価格の加重和を計算することにより最終販売ＮＡＶ、バスケット内の金融商品のそれぞれに対する現在の最高入札価格の加重和を計算することにより買い呼値ＮＡＶなどが得られることがある。

【0008】

ＧＰＰ：本明細書で使用されるように、「汎用プロセッサ」（またはＧＰＰ）という用語は、従来の中央処理装置（ＣＰＵ）が一般的な例である、固定した形態を有し、かつ命令取り出しおよびそれらの命令の実行により規定される可変機能のハードウェア機器を指す。ＧＰＰの例示的実施形態がＩｎｔｅｌのＸｅｏｎプロセッサ、およびＡＭＤのＯｐｔｅｒｏｎプロセッサを含む。

【0009】

再構成可能論理回路：本明細書で使用されるように、「再構成可能論理回路」という用語は、形態および機能が製造後に現場で大きく変えられる（すなわち、再構成される）ことができる任意の論理回路技術を指す。この再構成可能論理回路は、機能が製造後に変えられることができるが形態は製造で固定されるＧＰＰと対比されるべきである。

【0010】

ソフトウェア：本明細書で使用されるように、「ソフトウェア」という用語は、ＧＰＰまたは別の処理機器上に導入されるデータ処理機能を指し、ソフトウェアは、ソフトウェアがロードされる機器の形態を変更させるまたは規定するために使用されることができない。

【0011】

ファームウェア：本明細書で使用されるように、「ファームウェア」という用語は、再構成可能論理回路または別の処理機器上に導入されるデータ処理機能を指し、ファームウェアは、ファームウェアがロードされる機器の形態を変更させるまたは規定するために使用されることがある。

【0012】

コプロセッサ：本明細書で使用されるように、「コプロセッサ」という用語は、メインプロセッサを有する計算システム内の別の構成要素と共に動作するように設計される計算エンジンを指す（メインプロセッサ自体が、マルチコアプロセッサアーキテクチャにおけるように多数のプロセッサを含むことがある）。典型的には、コプロセッサが特定の１組のタスクを実行するように最適化され、システム性能を最適にするために、メインプロセッサ（典型的にはＧＰＰである）からタスクを肩代わりさせるために使用される。コプロセッサにより実行されるタスクの範囲は、コプロセッサのアーキテクチャに応じて固定されることも、可変のこともある。固定コプロセッサアーキテクチャの例が、広範なタスクを実行するグラフィックプロセッサユニット、および比較的限られた１組のタスクを実行する浮動小数点数値演算コプロセッサを含む。再構成可能コプロセッサアーキテクチャの例が、再構成可能論理回路デバイスたとえば多種多様な固定したまたはプログラム可能な計算エンジンを実現するように再構成されることがあるフィールドプログラマブルゲートアレイ（ＦＰＧＡ）を含む。コプロセッサの機能は、ソフトウェアおよび／またはファームウェアを介して規定されることがある。

【0013】

ハードウェアアクセラレーション：本明細書で使用されるように、「ハードウェアアクセラレーション」という用語は、処理タスクに対する処理待ち時間をメインプロセッサに比べて低減するために、メインプロセッサから１つまたは複数の処理タスクを肩代わりさせるためにコプロセッサ上に実装されるソフトウェアおよび／またはファームウェアの使用を指す。

【0014】

バス：本明細書で使用されるように、「バス」という用語は、機器および位置がアドレスによりアクセスされる任意の物理的相互接続を包含する論理バスを指す。本発明を実施する際に使用されることができるバスの例が、ＰＣＩファミリーのバス（たとえば、ＰＣＩ−ＸおよびＰＣＩ−Ｅｘｐｒｅｓｓ）およびＨｙｐｅｒ Ｔｒａｎｓｐｏｒｔバスを含むがそれらに限定されるものではない。

【0015】

パイプライン化：本明細書で使用されるように、「パイプライン」、「パイプラインシーケンス」、または「チェーン」という用語は、１つのアプリケーションモジュールの出力が次のアプリケーションモジュールの入力に順次接続されるアプリケーションモジュールの配置を指す。このパイプライン化する配置により、各アプリケーションモジュールが、各アプリケーションモジュールが所与のクロックサイクル中に受け取る任意のデータに対して独立に動作し、次に、別のクロックサイクル中に次の下流アプリケーションモジュールに順次各アプリケーションモジュールの出力を渡すことができるようになる。

【0016】

金融商品を売買する処理は、図１に示されるようなサイクルを通して処理するものとして広く考えられることがある。サイクルの最上部では、金融商品を買うおよび売る申込みを組み合わせることに責任がある取引所がある。取引所は市場情報、たとえば新しい売り／買いの申込み、ならびに売買取引の出現を市場データフィードとして知られているイベントのストリームとして広める。売買する企業が、売買するときに様々な取引所から市場データを受け取る。多数の取引所の状態を多くのトレーダが監視することを余儀なくさせる商品の多様なポートフォリオを多くのトレーダが管理することに留意されたい。取引所のフィードから受信されるデータを利用して、売買システムが売買の決定を行い、金融取引所に買い／売りの注文を出す。注文は取引所の中に流れ込み、取引所では注文が注文のソートされた「ブック」の中に挿入され、市場データフィードに対して１つまたは複数のイベントの発行を引き起こす。

【0017】

取引所は、注文ブックとして知られている、各金融商品に対する指値注文のソートされたリストを保有する。本明細書で使用されるように、「指値注文」は、所与の金融商品の指定された数の株式を指定された価格で売るまたは買う申込みを指す。指値注文は取引所特有の規則に従って価格、量、および時間に基づきソートされることができる。多くの取引所が、注文の追加、修正、および削除のイベントとして注文ブック更新を広める市場データフィードを発行する。これらのフィードはレベル２データフィードとして知られているフィードのクラスに属する。各取引所が、データがフィードでいつ発行されるか、およびフィードでイベントを発行するとき取引所がどれくらいの正規化を行うかに関して少し違いがあるが、レベル２フィードでの正規化の量がレベル１フィードに対して最小となることが期待されることが公正であることが理解されるべきである。これらのフィードは、２つの標準データモデル、すなわち完璧な注文深度、または価格集計深度の１つを典型的には利用する。図２ａに示されるように、完全な注文深度のフィードが、取引所マッチングエンジンにより使用される注文ブックを反映させる注文ブックを受信者が構築することができるようにするイベントを含む。このことは市場において特定の注文の状態の知識を必要とする売買戦略に対して有用である。

【0018】

図２ｂに示されるように、価格集計深度フィードが、所与の金融商品に対する価格全体の流動性の分布（利用できる株式）を報告する注文ブックを受信者が構築できるようにするイベントを含む［図２ｂは価格ビューブックの中へ注文ビューイベントを挿入することを実際には示している。入力イベントには注文参照番号がある（および注文カウントがない）ことに留意されたい。この例を変えて多くの言い表し方に容易に適合させることができる）。

【0019】

注文ブックフィードは市場動力学への最も早く最も深い洞察と一般に考えられるものを提供するので、注文ブックフィードは電子的売買にとって価値がある。現在の１組の注文ブックフィードは、株式、株式オプション、および商品の注文ブックに対するフィードを含む。いくつかの取引所がデリバティブ商品たとえば株式オプションに対する新しい注文ブックフィードを提供する計画を公表した。過去数年にわたるデリバティブ商品の爆発的成長を考慮すると、デリバティブ商品売買は現在の市場データトラフィックの最大部分を担う。オプション価格報告機関（ＯＲＰＡ）フィードがデリバティブ市場報告の最も重要な情報源であり、「レベル１」フィードとして知られているフィードのクラスに属する。レベル１フィードは相場、売買、売買取り消しおよび訂正、ならびに様々な要約イベントを報告する。所与の金融商品について、最高の買値および最低の売値が、相場として公示される「最良気配」（ＢＢＯ）を含む。取引所のソートされた注文ブックリストが注文実行、修正、または取り消しにより変わるので、取引所は新しい相場を公表する。最良気配価格が取引所の注文ブックで一致するとき、取引所は売買を実行し、売買取引を取引所のレベル１市場データフィードで公示する。指値注文を処理して、注文ブックを構築し、かつ売買または相場が生成されるべきかどうかを識別するときに、公表者のコンピュータシステムにより負わされる待ち時間のために、相場または売買のイベントを公表する前にある程度の量の処理が必要とされることに留意されたい。したがって、取引所または別のプロバイダからのレベル１データフィードには、注文ブックフィードで「未処理の」注文イベントを見るのに対して固有の待ち時間がある。未処理の指値注文データのフィードが、「レベル２」フィードとして知られているフィードのクラスに属する。

【0020】

総システム待ち時間を最小にするために、多くの電子的に売買する企業が、市場データフィードを、指値注文の市場データフィードを含み、金融取引所から企業自身のコンピュータシステムの中に直接収集する。一部の厳密でない標準が機能しているが、大部分の取引所が取引所の市場データを広めるための独自のプロトコルを規定している。このことにより、取引所は、市場動力学、規制管理、および新しい資産クラスの導入の変化に適応するために必要に応じてプロトコルを修正することができるようになる。チッカ装置はプラットフォームの先頭に存在し、市場データメッセージの正規化、キャッシング、フィルタリング、および公表の責任を負う。チッカ装置は、典型的には１組の下流の売買アプリケーションに購読（ｓｕｂｓｃｒｉｂｅ）インタフェースを提供する。異種の取引所および資産クラスからのデータを正規化することにより、チッカ装置は売買アプリケーションに対して整合性のあるデータモデルを提供する。購読インタフェースにより、各売買アプリケーションが必要とする情報だけを含むカスタムの正規化されたデータフィードを各売買アプリケーションが構築することができるようになる。このことは、チッカ装置で購読に基づくフィルタリングを行うことにより達成される。

【先行技術文献】

【特許文献】

【0021】

【特許文献1】米国特許出願公開第２００９／０１８２６８３号明細書

【特許文献2】米国特許出願公開第２００８／０２４３６７５号明細書

【特許文献3】米国特許出願公開第２００７／０２９４１５７号明細書

【特許文献4】米国特許出願公開第２００７／００７８８３７号明細書

【特許文献5】米国特許出願公開第２００７／０１７４８４１号明細書

【非特許文献】

【0022】

【非特許文献1】Ｋｒｉｓｈｎａｍｕｒｔｈｙら「Ｂｉｏｓｅｑｕｅｎｃｅ Ｓｉｍｉｌａｒｉｔｙ Ｓｅａｒｃｈ ｏｎ ｔｈｅ Ｍｅｒｃｕｒｙ Ｓｙｓｔｅｍ」、Ｐｒｏｃ．ｏｆ ｔｈｅ ＩＥＥＥ １５ｔｈ Ｉｎｔ’ｌ Ｃｏｎｆ．ｏｎ Ａｐｐｌｉｃａｔｉｏｎ−Ｓｐｅｃｉｆｉｃ Ｓｙｓｔｅｍｓ、Ａｒｃｈｉｔｅｃｔｕｒｅｓ ａｎｄ Ｐｒｏｃｅｓｓｏｒｓ、Ｓｅｐｔｅｍｂｅｒ ２００４、ｐｐ．３６５〜３７５

【発明の概要】

【発明が解決しようとする課題】

【0023】

本発明者らに知られている従来の市場データプラットフォームでは、チッカ装置が注文ブックフィードに対して何らかの正規化タスクを実行することがあるが、注文ブックのソートされたビューおよび／または価格集計ビューを構築するタスクは、典型的には市場データプラットフォームの下流構成要素に押しつけられる。本発明者らは、そのような売買プラットフォームアーキテクチャが処理待ち時間、および注文ブックフィードを処理するために必要とされる別個のシステムの数を増大させると確信している。そのような構成に対する１つの改善として、本明細書で開示される本発明の一実施形態は、加速され一体化された方法で注文フィード処理（たとえば、正規化、価格集計、ソーティング）をチッカ装置が実行することができるようにし、それにより、システム性能を増大させ、処理待ち時間を低減する。例示的実施形態では、チッカ装置は注文ブックの構築を加速するオフロードエンジンの役を果たすコプロセッサを利用する。チッカ装置の中にフィードで受け取られる金融市場データが、高速処理のためにコプロセッサにストリーミングに基づき転送されることができる。

【課題を解決するための手段】

【0024】

したがって、本発明の例示的実施形態によれば、本発明者らは、（１）複数の金融商品に対する複数の注文ブックを表すデータ構造を保持するステップと、（２）データ構造内部の注文ブックを更新するために複数の金融市場深度データメッセージの処理をハードウェアで加速するステップとを含む、金融市場深度データから注文ブックビューを生成する方法を開示する。好ましくは、ハードウェアで加速するステップは、チッカ装置内部のコプロセッサにより実行される。本発明者らはまた、（１）複数の金融商品に対する複数の注文ブックを表すデータ構造をソートするためのメモリと、（２）データ構造内部の注文ブックを更新するために複数の金融市場深度データメッセージを処理するように構成されるコプロセッサとを含む、金融市場深度データから注文ブックビューを生成するためのシステムを開示する。

【0025】

これらの注文ブックを使用して、方法およびシステムはまた、関心がある購読者へ最終的に届けるためにこれらの注文ブックのビューを生成することができる。本発明者らは様々な例示的実施形態により生成されることができるブックビューの２つの一般的クラス、すなわち、ストリームビュー（ソートされていない、キャッシュされていない）および要約ビュー（ソートされ、キャッシュされる）を規定する。ストリームビューは、指値注文に対する更新、または指定された地域記号、複合記号、もしくはフィード送信元（取引所）に対し集計された価格ポイント（ｐｒｉｃｅ−ｐｏｉｎｔ）の正規化されたストリームをクライアントアプリケーションに提供する。要約ビューは、ブックの多数のソートされたビューを、多数の市場にわたる複合ビュー（「バーチャル注文ブック」としても知られている）を含み、クライアントアプリケーションに提供する。

【0026】

例示的実施形態では、ストリームビューは指値注文に対する更新、または指定された地域記号、複合記号、もしくはフィード送信元（取引所）に対して集計された価格ポイントの正規化されたストリームを含む。ストリーム購読の生成に続いて、チッカ装置が指値注文または価格ポイント更新を含む正規化されたイベントのストリームをクライアントアプリケーションに提供するように構成されることができる。ストリーム購読はソーティングを提供しないので、ストリームビューデータが、１つまたは複数の指定された取引所からの正規化されたイベントストリームからクライアントアプリケーション自体のブックビューまたはジャーナルを構築するクライアントアプリケーションにより採用されることが期待される。

【0027】

様々な実施形態により生成されることができるストリームビューの一例が注文ストリームビューである。注文ストリームビューは、１つまたは複数の指定された地域記号に対する正規化された指値注文更新イベントのストリームを含む。正規化されたイベントは、フィールドたとえば更新のタイプ（追加、修正、削除）、注文価格、注文量、取引所タイムスタンプ、および注文識別子（取引所により提供される場合）を含む。注文ストリームビューの別の例が、１つもしくは複数の指定された取引所、または取引所内部の商品のクラスタに対する正規化された指値注文更新イベントのストリームを含む注文取引所ストリームビューである。正規化されたイベントは、フィールドたとえば更新のタイプ（追加、修正、削除）、注文価格、注文量、取引所タイムスタンプ、および注文識別子（取引所により提供される場合）を含む。

【0028】

様々な実施形態により生成されることができるストリームビューの別の例が価格ストリームビューである。価格ストリームビューは、１つまたは複数の指定された地域記号に対する正規化された価格水準更新イベントのストリームを含む。正規化されたイベントは、フィールドたとえば更新のタイプ（追加、修正、削除）、集計価格、集計価格での注文出来高、および集計価格での注文カウントを含む。価格ストリームビューの別の例が価格取引所ストリームビューである。価格取引所ストリームビューは、１つもしくは複数の指定された取引所、または取引所内部の商品のクラスタに対する正規化された価格水準更新イベントのストリームを含む。正規化されたイベントは、フィールドたとえば更新のタイプ（追加、修正、削除）、集計価格、集計価格での注文出来高、および集計価格での注文カウントを含む。

【0029】

様々な実施形態により生成されることができるストリームビューの別の例が集計ストリームビューである。集計ストリームビューは、１つまたは複数の指定された複合記号に対する正規化された価格水準更新イベントのストリームを含む。正規化されたイベントは、フィールドたとえば更新のタイプ（追加、修正、削除）、（バーチャル）集計価格、集計価格での（バーチャル）注文出来高、および集計価格での（バーチャル）注文カウントを含む。

【0030】

上記で参照され組み込まれた、米国特許出願公開第２００８／０２４３６７５号明細書で説明されているように、地域記号が特定取引所で売買される金融商品を識別するのに役立つのに対して、複合記号が、複合記号が売買する取引所のすべてで全体として金融商品を識別するのに役立つ。本明細書で開示される本発明の実施形態が、金融商品が多数の取引所で売買される状況で、同じ金融商品に対する地域レコードと複合レコードの両方を記憶するように構成されることがあることが理解されるべきである。

【0031】

要約ビューが流動性の洞察を提供し、本発明者らは、極めて少ない待ち時間でそのような流動性の洞察を得ることが非常に好ましいと確信している。本明細書で開示される一実施形態によれば、クライアントアプリケーションからかなりの量のデータ処理をチッカ装置に肩代わりさせることにより、チッカ装置はクライアント処理資源を解放し、それにより、それらのクライアント資源が、先発者利益を保持する、より洗練された売買アプリケーションを実現することができるようにする。

【0032】

様々な実施形態により生成されることができる要約ビューの一例が注文要約ビューである。注文要約ビューは、単一フィード送信元により広められる未処理の指値注文データの一次流動性のビューを表す。本発明者らは、所与の取引所での所与の金融商品に対する複数の個々の指値注文を含むソートされたリストである注文要約ビューを規定する。ソート順序は、好ましくは価格による、次に時間による（または、次に、一部の取引所の量（ｓｉｚｅ）による）。注文要約ビューの一例が図３に示されている。

【0033】

様々な実施形態により生成されることができる要約ビューの別の例が価格要約ビューである。価格要約ビューは、単一フィード送信元により広められる未処理の指値注文データの二次流動性ビューを表す。本発明者らは、所与の取引所での所与の金融商品に対して、それぞれその取引所からの同じ価格の注文の集計を表す複数の価格水準を含むソートされたリストである価格要約ビューを規定する。要約ビュー内の価格水準タイムスタンプが、その取引所からのその価格水準での最も新しいイベントのタイムスタンプを報告することが好ましい。価格要約ビューの一例が図４ａに示されている。本明細書で開示される一実施形態により生成される価格要約ビューが、ブックの最上部から始まりユーザにより指定された数の価格ポイントに限定されることがあることに留意されたい。

【0034】

様々な実施形態により生成されることができる要約ビューの別の例が、接合された価格要約ビューである。接合された価格要約ビューは、多数のフィード送信元により広められる未処理の指値注文データの二次の全市場流動性ビューを表す。本発明者らは、各価格水準が唯一の寄与する取引所からの同じ価格の注文の集計を表すすべての寄与する取引所全体にわたり所与の金融商品に対して複数の価格水準を含むソートされたリストである接合された価格要約ビューを規定する。接合された価格要約ビュー内の価格水準タイムスタンプが、指定された取引所に対するその価格水準での最も新しいイベントのタイムスタンプを報告することが好ましい。接合された価格要約ビューの一例が図４ｂに示されている。本明細書で開示される一実施形態により生成される接合された価格要約ビューが、ブックの最上部から始まりユーザにより指定された数の価格ポイントに限定されることがあることに留意されたい。

【0035】

様々な実施形態により生成されることができる要約ビューの別の例が集計価格要約ビューである。集計価格要約ビューは、多数のフィード送信元により広められる未処理の指値注文データの三次の全市場流動性ビューを表す。本発明者らは、所与の金融商品に対して、それぞれすべての寄与する取引所からの同じ価格の注文の集計を表す複数の価格水準を含むソートされたリストである集計価格要約ビューを規定する。集計価格要約ビュー内の価格水準タイムスタンプが、任意の寄与する取引所からのその価格水準での最も新しいイベントのタイムスタンプを報告することが好ましい。集計価格要約ビューの一例が図４ｃに示されている。本明細書で開示される一実施形態により生成される集計価格要約ビューが、ブックの最上部から始まりユーザにより指定された数の価格ポイントに限定されることがあることに留意されたい。

【0036】

本発明者らは、金融取引所が競争し、かつより効果的な市場を提供するために、革新を続けてきたことをさらに指摘する。そのような革新の一例が、公示の前に特定の注文を見る機会を地域市場関係者に提供する、いくつかの株式市場での一時的地域注文（たとえば、ＮＡＳＤＡＱでのＦＬＡＳＨ注文、ＢＡＴＳでのＢＯＬＴ注文）の導入である。そのような革新の別の例が、価格が別のデリバティブ商品から得られる総合注文に対して市場関係者が売買することができるようにするいくつかの商品市場（たとえばＣＭＥ、ＩＣＥ）での暗黙の流動性である。注文ブックでこのタイプの注文および価格の水準を捕捉し区別するために、本発明者らは属性の概念を規定し、この概念を本明細書で開示される様々な実施形態により利用されるデータ構造に適用する。注文ブックまたは価格ブック内の各項目が１つまたは複数の属性を有することがある。概念的には、属性はそれぞれの注文ブックまたは価格ブックの項目に関連付けられることがあるフラグのベクトルである。デフォルトで、あらゆる注文価格水準または集計価格水準が「明示的」であり、市場関係者により入力される関連する金融商品を買うまたは売る指値注文を表す。一部の株式市場では、注文または価格の水準が一時的地域注文（ＥＲＯ）に関連するかどうかを示すために属性を使って、注文または価格の水準が本明細書で開示される様々な実施形態を使用してフラグを立てられることがある。同様に、一部の商品市場では、注文または価格の水準が暗黙の流動性に関連するかどうかを示すために本明細書で開示される様々な実施形態を使用して注文または価格の水準がフラグを立てられることがある。

【0037】

例示的実施形態により利用されるデータ構造内でそのような属性を捕捉することにより、これらの属性が、上に述べたように本明細書で開示される様々な実施形態が生成するブックビューのタイプに別の次元を提供することを本発明者らは指摘する。たとえば、１つの商品売買アプリケーションが、暗黙の流動性を省く価格集計ブックを見たいと望むことがあり、別の商品売買アプリケーションが、明示的および暗黙の価格水準が独立に示される（接合されたビュー）価格集計ブックを見たいと望むことがあるのに対して、別の商品売買アプリケーションが、明示的および暗黙の項目が価格により集計された価格集計ブックを見たいと望むことがある。属性に基づくブックビューのこれら３つの例がそれぞれ図５、図６、および図７に示されている。

【0038】

したがって、例示的実施形態によれば、本発明者らは、属性を備える項目を含むブックに対するブックビューを生成する際にオプションの範囲を捕捉するための属性フィルタリングおよび価格水準併合の使用を開示する。属性フィルタリングにより、アプリケーションがどの項目がブックビューに含まれるか、および／またはブックビューから除外されるべきかを指定することができるようにする。価格水準併合により、同じ価格を共有するが属性の異なる項目が単一の価格水準に集計されるべきかどうかをアプリケーションが指定することができるようにする。

【0039】

本発明者らはまた、コプロセッサが注文ブックデータを、すなわち本明細書で開示されるようなストリームビュー注文ブックデータと要約ビュー注文ブックデータの両方を使って金融商品に関係がある指値注文イベントのストリームを強化するために使用されることができるいくつかの実施形態を開示する。

【0040】

本発明のこれらおよび別の特徴および有利な点が、以下に本明細書で当業者に説明される。

【図面の簡単な説明】

【0041】

【図1】金融商品を売買するための例示的処理サイクルを描く。

【図2a】例示的指値注文イベント、および指値注文イベントの完全な注文深度ブックとの関係を描く。

【図2b】例示的指値注文イベント、および指値注文イベントと価格集計深度注文ブックとの関係を描く。

【図3】例示的買い注文および売り注文の要約ビューを描く。

【図4a】例示的買い呼値および売り呼値の要約ビューを描く。

【図4b】例示的買いおよび売りの接合された価格要約ビューを描く。

【図4c】集計価格要約ビューを描く。

【図5】暗黙の属性がフィルタで除かれた例示的価格ブックビューを描く。

【図6】例示的価格ブックビューを、接合された属性ビューを含み描く。

【図7】例示的価格ブックビューを、価格が併合された属性ビューを含み描く。

【図8a】市場深度データを処理するために適したプラットフォームの例を描く。

【図8b】市場深度データを処理するために適したプラットフォームの例を描く。

【図9a】コプロセッサとして使用するための例示的プリント回路基板を描く。

【図9b】コプロセッサとして使用するための例示的プリント回路基板を描く。

【図10】ファームウェアパイプラインが多数の再構成可能論理回路デバイス全体にどのように導入されることができるかの一例を描く。

【図11a】指値注文データを処理するための処理モジュールの実施形態を描く。

【図11b】指値注文データを処理するための処理モジュールの実施形態を描く。

【図11c】指値注文データを処理するための処理モジュールの実施形態を描く。

【図12a】注文ブックのストリームビューを生成するためのパイプラインの実施形態を描く。

【図12b】注文ブックのストリームビューを生成するためのパイプラインの実施形態を描く。

【図12c】注文ブックのストリームビューを生成するためのパイプラインの実施形態を描く。

【図13】記号マッピングのためのハッシュキーを生成するために使用される圧縮関数の例示的実施形態を描く。

【図14】記号マッピングのためのハッシュ関数の例示的実施形態を描く。

【図15】記号マッピングのための広域取引所識別子（ｇｌｏｂａｌ ｅｘｃｈａｎｇｅ ｉｄｅｎｔｉｆｉｅｒ、ＧＥＩＤ）を生成するための例示的実施形態を描く。

【図16】正規化および価格集計データを使って指値注文イベントを強化するように構成されるモジュールの例示的実施形態を描く。

【図17】指値注文レコードおよび価格ポイントレコードを記憶しそこにアクセスするための、そのようなレコードが共有メモリ内に記憶される例示的実施形態を描く。

【図18】指値注文レコードおよび価格ポイントレコードを記憶しそこにアクセスするための、そのようなレコードが多数の物理メモリ全体に分割される別の例示的実施形態を描く。

【図19】例示的指値注文イベントを描く。

【図20】例示的指値注文レコードを描く。

【図21a】例示的地域価格ポイントレコードを描く。

【図21b】例示的複合価格ポイントレコードを描く。

【図22】例示的な強化された指値注文イベントを描く。

【図23】注文正規化および価格集計（ＯＮＰＡ）モジュールに対する例示的アーキテクチャを描く。

【図24】クライアントアプリケーション内のＡＰＩが、チッカ装置により提供される注文ブックのストリームビューから注文ブックのソートされたビューを生成するように構成される例示的実施形態を描く。

【図25a】注文ブックの要約ビューを生成するためのパイプラインの実施形態を描く。

【図25b】注文ブックの要約ビューを生成するためのパイプラインの実施形態を描く。

【図25c】注文ブックの要約ビューを生成するためのパイプラインの実施形態を描く。

【図25d】注文ブックの要約ビューを生成するためのパイプラインの様々な実施形態を描く。

【図26】Ｂ＋木の一例を描く。

【図27】モジュールがデータ構造内部のソートされた注文ブックデータにアクセスするにはどのように構成されることができるかの一例を描く。

【図28】ソートされたビュー更新（ＳＶＵ）モジュールに対する例示的アーキテクチャを描く。

【図29】ＳＶＵモジュールにより生成される総合相場イベントに対して動作する価値キャッシュ更新（ＶＣＵ）モジュールを含む例示的パイプラインを描く。

【図30】ＳＶＵモジュールにより生成される総合相場イベントにより部分的に駆動されるバスケット計算エンジン（ＢＣＥ）モジュールを含む例示的パイプラインを描く。

【図31】金融商品深度データを処理するように構成されるパイプラインが利用されることができる例示的チッカ装置アーキテクチャを描く。

【発明を実施するための形態】

【0042】

本発明の例示的実施形態を実現するための適切なプラットフォームの例が図８ａおよび図８ｂに示されている。図８ａは、金融市場深度データを処理するためにコプロセッサ８４０を介してハードウェアで加速するデータ処理能力を利用するシステム８００を描く。システム８００内部には、コプロセッサ８４０が（ネットワークインタフェース８１０を介して）ネットワーク８２０からシステム８００の中に流れ込むデータを受け取るように配置される。好ましい実施形態では、システム８００は、金融市場指値注文データを受け取り、かつ金融市場深度データを処理するために利用される。したがって、ネットワーク８２０は、システム８００がレベル２金融データに対する送信元たとえば取引所自体（たとえば、ＮＹＳＥ、ＮＡＳＤＡＱなど）またはサードパーティのプロバイダ（たとえば、エキストラネットプロバイダたとえばＳａｖｖｉｓまたはＢＴ Ｒａｄｉａｎｓ）にアクセスできるネットワークを含むことが好ましい。そのような入力データは、一連の金融市場データメッセージ、すなわち、イベントを表すたとえば金融商品に関連する指値注文を表すメッセージを含むことが好ましい。これらのメッセージは当技術分野で知られているいくつかの書式の任意の形で存在することができる。

【0043】

プロセッサ８１２およびＲＡＭ８０８により規定されるコンピュータシステムは、当業者により理解されるような任意の市販のコンピュータシステムとすることができる。たとえば、コンピュータシステムはＩｎｔｅｌのＸｅｏｎシステムでも、ＡＭＤのＯｐｔｅｒｏｎシステムでもよい。したがって、プロセッサ８１２は、システム８００のための中央処理装置またはメインプロセッサの役割を果たすが、ＧＰＰを含むことが好ましい。

【0044】

好ましい実施形態では、コプロセッサ８４０は再構成可能論理回路デバイス８０２を含む。好ましくは、データはシステムバス８０６を経由して再構成可能論理回路デバイス８０２の中へ流れ込むが、別の設計アーキテクチャが可能である（図９ｂ参照）。好ましくは、再構成可能論理回路デバイス８０２はフィールドプログラマブルゲートアレイ（ＦＰＧＡ）であるが、これがその事例である必要はない。システムバス８０６はまた再構成可能論理回路デバイス８０２をＲＡＭ８０８だけでなくプロセッサ８１２にも相互接続することができる。好ましい実施形態では、システムバス８０６はＰＣＩ−ＸバスでもＰＣＩ−Ｅｘｐｒｅｓｓバスでもよいが、これがその事例である必要はない。

【0045】

再構成可能論理回路デバイス８０２は、再構成可能論理回路デバイスの機能を規定する、再構成可能論理回路デバイス上に導入されるファームウェアモジュールを有する。ファームウェアソケットモジュール８０４は再構成可能論理回路デバイスとの間でやりとりするデータ移動要件（コマンドデータもターゲットデータも）を処理し、それにより、再構成可能論理回路デバイス上にも導入されるファームウェアアプリケーションモジュール（ＦＡＭ）チェーン８５０への整合性のあるアプリケーションインタフェースを提供する。ＦＡＭチェーン８５０のＦＡＭ８５０ｉは、ファームウェアソケットモジュール８０４からチェーン８５０を通って流れる任意のデータに対して、指定されたデータ処理動作を行うように構成される。本発明の好ましい実施形態に従って再構成可能論理回路上に導入されることができるＦＡＭの例が以下に説明される。

【0046】

ＦＡＭにより行われる特定のデータ処理動作は、ＦＡＭがファームウェアソケットモジュール８０４から受け取るコマンドデータにより制御される／パラメータ化される。このコマンドデータはＦＡＭ特有とすることができ、コマンドを受け取ると、ＦＡＭは受信されたコマンドにより制御されるデータ処理動作を実行するようにそれ自体を構成する。たとえば、データとキーの間の正確な一致動作を行うように構成されるＦＡＭの内部では、ＦＡＭの正確な一致動作は、正確な一致動作が行われるキーを規定するようにパラメータ化されることができる。この方法では、正確な一致動作を行うように構成されるＦＡＭが、そのＦＡＭの１つまたは複数の別のキーに対して新しいパラメータをロードするだけで異なる正確な一致動作を行うように容易に再構成されることができる。バスケットに関係がある別の例として、バスケットとの間でやりとりする１つまたは複数の金融商品を追加／削除するようにバスケット計算エンジンを作り上げる１つまたは複数のＦＡＭにコマンドが発行されることができる。

【0047】

ひとたびＦＡＭが、受信されたコマンドにより指定されるデータ処理動作を行うように構成されると、そのＦＡＭは、ＦＡＭがファームウェアソケットモジュールから受け取るデータストリームに対してＦＡＭが指定されたデータ処理動作を実行する準備ができている。したがって、ＦＡＭが、指定された方法でデータの指定されたストリームを処理するように適切なコマンドにより構成されることができる。ひとたびＦＡＭがＦＡＭのデータ処理動作を完了すると、ＦＡＭに別のコマンドにより行われるデータ処理動作の特質を変えるように自分を再構成させる別のコマンドがそのＦＡＭに送信されることができる。ＦＡＭがハードウェアの速度で動作するだけでなく（それにより、ＦＡＭによりデータの高スループットを提供する）、ＦＡＭはＦＡＭのデータ処理動作のパラメータを変えるように柔軟に再プログラムされることもできる。

【0048】

ＦＡＭチェーン８５０は、パイプライン化された順序で構成される複数のファームウェアアプリケーションモジュール（ＦＡＭ）８５０ａ、８５０ｂ、・・・を含むことが好ましい。しかしながら、ファームウェアパイプライン内部では、ＦＡＭ８５０ｉの１つまたは複数の並列経路が利用されることができることに留意すべきである。たとえば、ファームウェアチェーンは第１のパイプライン化経路で構成される３つのＦＡＭ（たとえば、ＦＡＭ８５０ａ、８５０ｂ、８５０ｃ）、および第２のパイプライン化経路で構成される４つのＦＡＭ（たとえば、ＦＡＭ８５０ｄ、８５０ｅ、８５０ｆ、および８５０ｇ）を含むことがあり、この場合、第１および第２のパイプライン化経路は互いに並列である。さらに、ファームウェアパイプラインは既存のパイプライン経路から分岐された１つまたは複数の経路を有することができる。本発明の実行者は、所与のアプリケーションの処理の必要性に基づきＦＡＭチェーン８５０のためのＦＡＭの適切な構成を設計することができる。

【0049】

通信経路８３０が、ファームウェアソケットモジュール８０４をパイプライン化ＦＡＭの第１の１つ８５０ａの入力と接続する。第１のＦＡＭ８５０ａの入力はＦＡＭチェーン８５０の中への入口点の役割を果たす。通信経路８３２はパイプライン化ＦＡＭの出力の最後の１つ８５０ｍの出力をファームウェアソケットモジュール８０４と接続する。最後のＦＡＭ８５０ｍの出力はＦＡＭチェーン８５０からの出口点の役割を果たす。通信経路８３０も通信経路８３２もマルチビット経路であることが好ましい。

【0050】

システム８００により使用されるソフトウェアおよびハードウェア／ソフトウェアインタフェースの特質が、特にファームウェアソケットモジュールとの間でやりとりするデータフローに関連して、開示全体が参照により本明細書に組み込まれる、米国特許出願公開第２００７／０１７４８４１号明細書でより詳細に説明されている。

【0051】

図８ｂはシステム８００に対する別の例示的実施形態を描く。図８ｂの例では、システム８００は、ディスクコントローラ８１４を介してバス８０６と通信状態にあるデータストア８４２を含む。したがって、コプロセッサ８４０を通って流されるデータはまた、データストア８４２から出ることがある。データストア８４２は任意のデータ記憶装置／システムとすることができるが、何らかの形態の大容量記憶媒体であることが好ましい。たとえば、データストア８４２は磁気記憶装置たとえばＳｅａｇａｔｅのディスクのアレイとすることができる。

【0052】

図９ａは、図８ａから図８ｂの実施形態の任意に対してシステム８００内のコプロセッサ８４０として使用するための、市販のコンピュータシステムのＰＣＩ−ＸバスまたはＰＣＩ−ｅバス８０６に接続されることができるプリント回路基板またはカード９００を描く。図９ａの例では、プリント回路基板は、メモリ装置９０２およびＰＣＩ−Ｘバスコネクタ９０４と通信状態にあるＦＰＧＡ８０２（たとえばＸｉｌｉｎｘのＶｉｒｔｅｘ ５ ＦＰＧＡ）を含む。好ましいメモリ装置９０２はＳＲＡＭおよびＤＲＡＭのメモリを含む。好ましいＰＣＩ−ＸまたはＰＣＩ−ｅのバスコネクタ９０４は標準的カードエッジコネクタである。

【0053】

図９ｂはプリント回路基板／カード９００に対する代わりの構成を描く。図９ｂの例では、バス９０６（たとえばＰＣＩ−ＸバスまたはＰＣＩ−ｅバス）、１つまたは複数のディスクコントローラ９０８およびディスクコネクタ９１０もプリント回路基板９００上に取り付けられる。任意の市販のディスクインタフェース技術が当技術分野で理解されるようにサポートされることができる。この構成では、ファームウェアソケット８０４はまた、プライベートＰＣＩ−Ｘバス９０６を介して接続される任意のディスクへの通常のアクセスをプロセッサ８１２に提供するためのＰＣＩ−ＸからＰＣＩ−Ｘへブリッジの役割を果たす。図９ｂに示されるディスクコントローラおよびディスクコネクタに加えてまたはその代わりにネットワークインタフェースが使用されることができることに留意すべきである。

【0054】

図９ａまたは図９ｂのいずれの構成でも、ファームウェアソケット８０４はメモリ９０２をバス８０６にアクセスできるようにすることができ、そのことが、それにより、バスへのアクセスを使ってデータソースからＦＡＭへ転送するためのバッファとして、メモリ９０２をＯＳカーネルにより使用するために利用できるようにすることは指摘する価値がある。単一のＦＰＧＡ８０２が図９ａおよび図９ｂのプリント回路基板上に示されているが、多数のＦＰＧＡが、プリント回路基板９００上に２つ以上のＦＰＧＡを含むことにより、またはシステム８００内に２つ以上のプリント回路基板９００を取り付けることにより、サポートされることができることが理解されるべきであることも指摘する価値がある。図１０は単一パイプライン内に数多くのＦＡＭが多数のＦＰＧＡ全体に導入される一例を描く。

【0055】

図１１ａから図１１ｃは、指値注文イベントを処理するためにコプロセッサ８４０内部で利用されることができる処理モジュール１１００の例を描く。図１１ａの処理モジュール１１００は、処理された指値注文データのストリームビューを生成するように構成される。図１１ｂの処理モジュール１１００は、処理された指値注文データの要約ビューを生成するように構成され、図１１ｃの処理モジュール１１００は、処理された指値注文データのストリームビューと要約ビューの両方を生成するように構成される。

【0056】

図１２ａから図１２ｃの例示的実施形態では、処理された指値注文データのストリームビューを生成するためのデータ処理モジュール１１００が、パイプライン１２００を介して実現されることができる。図１２ａの例では、パイプラインは未処理メッセージ１２０２を受け取るメッセージ構文解析（ＭＰ）モジュール１２０４を含む。これらのメッセージ１２０２は、金融市場データイベントのストリームを含み、そのストリームの少なくとも複数が指値注文イベントを含む。ＭＰモジュール１２０４から下流に記号マッピング（ＳＭ）モジュール１２０６があり、ＳＭモジュール１２０６の下流に注文正規化および価格集計（ＯＮＰＡ）モジュール１２０８がある。ＯＮＰＡモジュール１２０８は、以下で説明されるように、指値注文イベント内に含まれる指値注文データのストリームビューを生成するように構成される。

【0057】

ＭＰモジュール１２０４は、未処理メッセージ１２０２の入力ストリームを、下流モジュールにより理解されることができるデータフィールドを有する複数の構文解析されたメッセージに構文解析するように構成される。そのようなＭＰモジュールのための例示的実施形態が、上記で参照され組み込まれた、米国特許出願公開第２００８／０２４３６７５号明細書で説明されている。したがって、ＭＰモジュールは、入力の未処理メッセージ１２０２を処理して、下流モジュールにより理解されることができる指値注文イベントを生成するように構成される。

【0058】

ＳＭモジュール１２０６は、基本の金融商品に対する一意の記号識別子、および受信されたイベントに対する関連する市場センタを解決する。入力イベントは、基本の金融商品を一意に識別する記号フィールドを含むことがある。この場合、記号マッピング段階が入力記号フィールドから記号識別子への１対１変換を行い、記号識別子は、金融商品に対する関連する状態情報の効果的探索に備える最小サイズのバイナリタグであることが好ましい。したがって、ＳＭモジュール１２０６は構文解析されたメッセージで規定されるような金融商品（または１組の金融商品）に対する知られている記号をプラットフォーム内部の記号表示法にマッピングするように動作する（たとえば、ＩＢＭ株式に対する記号を内部記号「１２３４５」にマッピングする）。好ましくは、内部プラットフォーム記号識別子（ＩＤ）は０〜Ｎ−１までの範囲の整数であり、ここでＮは記号インデックスメモリ内の項目の数である。また、記号ＩＤは、サイズＭ＝ｌｏｇ_２（Ｎ）ビットのバイナリ値として書式を設定されることがある。入力取引所メッセージ内の金融商品記号の書式は、異なるメッセージフィードおよび金融商品タイプに対して変わる。典型的には、記号は可変長のＡＳＣＩＩ文字列である。記号表記法ＩＤは、メッセージ内の記号ストリングの書式を一意に識別する内部制御フィールドである。図１３に示されるように、記号ストリング書式は典型的には所与の入力フィード上のすべてのメッセージにより共有されるので、記号表記法ＩＤは、フィードハンドラにより割り当てられ、かつすべての入力メッセージ内に存在することが好ましい。

【0059】

ＳＭモジュール１２０６の例示的実施形態が、それぞれの一意の記号文字列をサイズＭビットの一意のバイナリ数にマッピングする。そのような例示的実施形態では、記号マッピングＦＡＭは、記号の書式特有の圧縮を行って、サイズＫビットのハッシュキーを生成し、ここで、Ｋは記号インデックスメモリ内の項目のサイズである。記号表記法ＩＤは、入力記号に対して使用されるべき記号圧縮技法を識別するキーコードを探索するために使用されることがある。好ましくは、記号マッピングＦＡＭは、書式特有の圧縮エンジンを使用して記号を圧縮し、キーコードを使用して正しい圧縮された記号出力を選択する。また、キーコードは、ハッシュキーを形成するために、圧縮された記号と連結されることができる。そうする際、各圧縮技法が、可能なハッシュキーの範囲のサブセットを割り当てられる。このことが、記号を圧縮するために使用される圧縮技法にかかわらず、ハッシュキーが一意となることを保証する。金融商品に対するＡＳＣＩＩ記号が複数の異なる圧縮操作（たとえば、英数字チッカ圧縮、ＩＳＩＮ圧縮、および商品の圧縮）により並列に圧縮される一例が図１３に示されている。異なる記号表記法に対する圧縮技法が、実行者により望まれるように特別な基準で選択されるおよび／または得られることができる。実行者が、所与の記号表記法に適合するような異なる圧縮技法を自由に選択する。キーコードの値に基づき、ＳＭモジュールは、ハッシュキーとして使用するためにマルチプレクサからの出力としてキーコードと圧縮結果の連結の１つを渡す。

【0060】

あるいは、書式特有の圧縮エンジンが、プログラム可能なプロセッサ内に実装されることがある。この場合、キーコードは、記号がどのように圧縮されるべきかを指定する命令のシーケンスを取り出すために使用されることがある。

【0061】

ひとたびハッシュキーが生成されると、ＳＭモジュール１２０６は、０〜Ｎ−１の範囲で記号インデックスメモリ内の一意のアドレスにハッシュキーをマッピングする。記号インデックスメモリは、「オンチップ」メモリ内に（たとえば、再構成可能論理回路デバイス内部に）、または「オフチップ」の高速メモリデバイスたとえば再構成可能論理回路デバイスにアクセスできるＳＲＡＭおよびＳＤＲＡＭ内に実装されることがある。好ましくは、このマッピングはハッシュ関数により行われる。ハッシュ関数が、入力ハッシュキーを見つけるための探査、すなわちテーブル探索の数を最小にしようとする。多くの応用例では、追加のメタデータがハッシュキーと関連付けられる。例示的実施形態では、記号インデックスメモリ内のハッシュキーの位置は金融商品に対する一意の内部記号ＩＤとして使用される。

【0062】

図１４は、知られているハッシング法の新規な組合せを表すこのマッピングを行うハッシュ関数の例示的実施形態を示す。図１４のハッシュ関数はほぼ完全なハッシングを使用して一次ハッシュ関数を計算し、次に、オープンアドレス法（ｏｐｅｎ−ａｄｄｒｅｓｓｉｎｇ）を使用して衝突を解決する。ハッシュ関数Ｈ（ｘ）は以下のように示される：

【数1】

オペランドｘは、前に説明された圧縮段階により生成されたハッシュキーである。関数ｈ１（ｘ）は一次ハッシュ関数である。値ｉは反復回数である。反復回数ｉはゼロに初期化され、衝突をもたらす各ハッシュ探査に対して増分される。第１のハッシュ探査では、ハッシュ関数Ｈ（ｘ）＝ｈ１（ｘ）であり、したがって、一次ハッシュ関数が第１のハッシュ探査を決定する。本明細書で開示される好ましいハッシュ関数は、ハッシュキーが第１のハッシュ探査で探し出される確率を最大にしようとする。ハッシュ探査が衝突をもたらす場合、ハッシュスロット内に記憶されるハッシュキーはハッシュキーｘと一致せず、反復回数が増分され、第１のハッシュ探査位置からのオフセットを生成するために二次ハッシュ関数ｈ２（ｘ）と結合される。モジュロＮ操作は、最終結果が０〜Ｎ−１の範囲内にあることを保証し、ここでＮは記号インデックスメモリのサイズである。二次ハッシュ関数ｈ２（ｘ）は、二次ハッシュ関数の出力がＮに対して素数となるように設計される。ｉを増分しＨ（ｘ）を再計算する処理は、入力ハッシュキーがテーブル内で探し出される、または空のテーブルスロットに遭遇するまで続く。衝突を解決するこの技法はオープンアドレス法として知られている。

【0063】

一次ハッシュ関数ｈ１（ｘ）は以下のように計算される。結果が０〜Ｑ−１の範囲内にあるハッシュ関数Ｂ（ｘ）を計算する。Ｂ（ｘ）関数の結果を使用して、Ｑ変位ベクトルを含むテーブルＴ内で変位ベクトルｄ（ｘ）を探索する。好ましくは、変位ベクトルｄ（ｘ）のビットサイズはＭに等しい。結果がＭビットサイズのハッシュ関数Ａ（ｘ）を計算する。Ａ（ｘ）とｄ（ｘ）のビットごとの排他的論理和、すなわち

【数2】

を計算する。これは、クエリストリームの開始前に知られている１組のハッシュキーの間の衝突を解決するために変位ベクトルが使用されるほぼ完全なハッシングの一例である。典型的には、これは所与の日の商品売買に対する記号の大多数が知られているストリーミング金融データとよく適合する。変位テーブル項目を計算する方法は当技術分野で知られている。

【0064】

二次ハッシュ関数ｈ２（ｘ）は、結果が常にＮに対する素数である単一ハッシュ関数Ｃ（ｘ）を計算することにより計算される。ハッシュ関数Ａ（ｘ）、Ｂ（ｘ）、およびＣ（ｘ）は、有利なランダム化特性を有する知られているハッシュ関数の本体から選択されることがある。好ましくは、ハッシュ関数Ａ（ｘ）、Ｂ（ｘ）、およびＣ（ｘ）はハードウェア内に効果的に実装されることができる。１組のＨ３ハッシュ関数がよい候補である（開示の全体が参照により本明細書に組み込まれる、Ｋｒｉｓｈｎａｍｕｒｔｈｙら「Ｂｉｏｓｅｑｕｅｎｃｅ Ｓｉｍｉｌａｒｉｔｙ Ｓｅａｒｃｈ ｏｎ ｔｈｅ Ｍｅｒｃｕｒｙ Ｓｙｓｔｅｍ」、Ｐｒｏｃ．ｏｆ ｔｈｅ ＩＥＥＥ １５ｔｈ Ｉｎｔ’ｌ Ｃｏｎｆ．ｏｎ Ａｐｐｌｉｃａｔｉｏｎ−Ｓｐｅｃｉｆｉｃ Ｓｙｓｔｅｍｓ、Ａｒｃｈｉｔｅｃｔｕｒｅｓ ａｎｄ Ｐｒｏｃｅｓｓｏｒｓ、Ｓｅｐｔｅｍｂｅｒ ２００４、ｐｐ．３６５〜３７５参照）。

【0065】

ひとたびハッシュ関数Ｈ（ｘ）が、項目が入力ハッシュキーに等しいアドレスを生成すると、アドレスは金融商品を参照するためにチッカ装置により内部で使用される新しい記号ＩＤとして渡される。図１４に示されるように、ハッシュキー比較関数の結果が、記号ＩＤ出力のための正しい信号として使用されることがある。

【0066】

ハッシュキーは、取引所メッセージが、システム初期化時に未知であった記号を含むときにテーブルに挿入される。ハッシュキーは、金融商品がもはや売買されないときにテーブルから削除される。あるいは、金融商品に対する記号が１組の知られている記号から削除されることがあり、ハッシュテーブルがクリアされ、再計算され、初期化されることがある。そうすることにより、一次ハッシュのほぼ完全なハッシュ関数として使用される変位テーブルが最適化されることがある。典型的には、金融市場は営業時間外の処理または夜通しの処理を考慮する取引時間を確立した。オープンアドレス法が衝突を解決するために使用される、ハッシュテーブルからハッシュキーを挿入および削除するための一般手順は、当技術分野でよく知られている。

【0067】

例示的実施形態では、ＳＭモジュール１２１０はまた、図１５に示されるように、取引所メッセージ内の取引所コードおよび国コードのフィールドを０〜Ｇ−１の範囲の整数にマッピングする広域取引所識別子（ＧＥＩＤ）を計算するように構成されることができる。金融商品に対する記号フィールドと同様に、取引所コードおよび国コードのフィールドは、取引所メッセージの送信元を一意に識別する。したがって、広域取引所識別子（ＧＥＩＤ）は、メッセージが該当する特定の取引所を一意に識別するバイナリタグを含むことが好ましい。Ｇの値は、システムの所与のインスタンスに対して入力メッセージを生成している送信元（金融取引所）の総数よりも大きくなるように選択されるべきである。ハッシングは国コードおよび取引所コードをＧＥＩＤにマッピングするために使用されることができる。あるいは、「直接アドレス指定」手法が国コードおよび取引所コードをＧＥＩＤにマッピングするために使用されることができる。たとえば、取引所コードおよび国コードは、それぞれ２文字コードにより表されることができ、この場合、文字は８ビットの大文字ＡＳＣＩＩ英字である。次に、これらのコードは、これらのコードの２６の一意の値だけが必要とされる実施形態では、５ビット文字に短くされることができる。各コードに対して、これらの短くされた値が、圧縮された中間値を段階１のテーブル内で探索するために使用される１０ビットアドレスを生成するために連結される。次に、取引所コードおよび国コードに対する圧縮された中間値が段階２の探索のためのアドレスを生成するために連結されることができる。段階２の探索の結果がＧＥＩＤである。中間値および段階２のアドレスのサイズは、一意の国の数、および任意の１つの国の中の取引所の最大数に依存し、取引所の最大数は、異なる国の中で開かれる新しい取引所として調節されることができる。

【0068】

次に、ＯＮＰＡモジュール１２０８が、図１６に示されるように入力指値注文イベント１６００のストリームを受け取る。ＯＮＰＡモジュールは、（１）受信された指値注文イベントを考慮してデータ構造を更新する方法を、および（２）追跡された注文ブックとの指値注文イベントとの関係を考慮して指値注文イベントを強化する方法を決定するために、システムにより追跡される様々な注文ブックを含むデータ構造を記憶するメモリ１６０２にアクセスする。ＯＮＰＡモジュール１２０８からの出力は、強化された指値注文イベント１６０３の出力ストリームである。

【0069】

図１９は、例示的指値注文イベント１６００を描く。例示的データフィールドとして、指値注文イベントは記号フィールド１９０２およびＧＥＩＤフィールド１９０４（ＳＭモジュール１２０６によりマッピングされる）を含む。イベントはまた、典型的には特定の指値注文を識別するためにイベントの発行者により割り当てられる参照番号フィールド１９０６を含むことがある。イベント１６００のための追加のデータフィールドが、指値注文が買値または売値に関係があるかどうかを識別するためのフラグ１９０８、指値注文に対する価格を識別するためのフィールド１９１０、指値注文に対する量（たとえば株式カウント）を識別するためのフィールド１９１２、およびタイムスタンプフィールド１９０４を含む。さらにイベント１６００は、１つまたは複数の属性がイベントに適用できるかどうかを識別する１つまたは複数のフラグ１９１６を含むことが好ましい。たとえば、上記で議論されたように、属性フラグフィールド１９１６の値は、指値注文が一時的地域注文（たとえば、ＮＡＳＤＡＱでのＦＬＡＳＨ注文またはＢＡＴＳでのＢＯＬＴ注文）に関係があるかどうか、および指値注文が暗黙のものであるかどうかを識別することができる。最後に、指値注文イベント１６００は、指値注文イベントが追加イベント、修正イベント、または削除イベントであるかどうかを識別するための１つまたは複数のフラグ１９１８を含むことがある。したがって、追加、修正、削除（ＡＭＤ）フラグフィールド１９１８は、ＯＮＰＡモジュール１２０８が、受信された指値注文が新しい指値注文（追加フラグ）、以前から存在する指値注文に対する修正（修正フラグ）、または以前から存在する指値注文の削除（削除フラグ）を表すかどうかを決定することができるようにする。

【0070】

フィールドの数および／またはフィールドのタイプに違いがあろうとも、多くの指値注文イベント１６００が図１９の例に示される同じフィールドを有するわけではないことを理解すべきである。たとえば、多くの指値注文イベントが、ＡＭＤフィールド１９１８の値に基づき変わるフィールドを有する。別の例として、一部の指値注文イベント１６００が、記号フィールド１９０２を含まない。そのようなインスタンスでは、記号マッピングタスクは、ＳＭモジュール１２０６ではなくＯＮＰＡモジュール１２０８により行われる。そのような状況の一例として、データ伝送リンクの帯域幅を節約するために、いくつかの市場センタが、発行済み指値注文に関する「静的」情報を一度だけ送信することによりイベントメッセージのサイズを最小にする。典型的には、新しい指値注文の追加を公示する最初のメッセージが、注文に対する参照番号だけでなくすべての関連する情報（たとえば記号、送信元識別子、価格、および注文の量など）を含む。注文の修正または削除を報告するその後のメッセージは、注文を一意に識別する参照番号だけを含むことがある（したがって、イベントから記号フィールドを省く）。好ましい実施形態では、ＯＮＰＡモジュール１２０８にとっての役割の１つが、完全な注文情報をイベントメッセージの下流の消費者に渡すことである。指値注文イベントメッセージについては、ＯＮＰＡモジュール１２０８は、すべての望まれるフィールドが通常の書式で存在し、かつメッセージが市場イベントを継続して伝達することを保証することによりメッセージを正規化する。たとえば、市場センタが、注文修正イベントを使用してすべてのイベントを公示するように選択することがある。そのようなシナリオでは、好ましい実施形態では、イベントが新しい注文の追加、既存の注文の修正、または既存の注文の削除となるかどうかを決定することが、ＯＮＰＡモジュール１２０８の責任である。実際には、市場センタには、指値注文イベントを伝達するための別個のデータモデルがある。すなわち、ＯＮＰＡモジュール１２０８は、整合性のあるデータモデルが下流の処理ブロックおよび売買アプリケーションに提示されることを保証する。すべての出力イベントが、各フィールドがよく規定されたタイプを有する整合性のある１組のフィールドを含む。たとえば、一部の取引所は削除イベントで注文参照番号だけを送信することがある。ＯＮＰＡモジュール１２０８は、欠けたフィールドたとえば削除される注文の価格および量を埋める。

【0071】

記号フィールドを欠く入力イベントに対する記号識別子を解決するために、ＯＮＰＡモジュール１２０８は、別の識別フィールド（たとえば注文参照番号）を使用することができる。この場合、ＯＮＰＡモジュール１２０８は、所与の金融商品を買うまたは売る多くの発行済み注文があることがあるので、記号識別子を解決するために多対１変換を行う。この多対１マッピングは、所与の記号識別子にマッピングする動的な１組の項目を保持する必要があり、項目は、注文が市場センタに入り実行されるときに、いつでも１組から追加される、修正される、または削除されることがあることに留意することが重要である。

【0072】

注文正規化問題を解決するためのいくつかの実行可能な手法があるが、好ましい方法は、１組の入力市場データフィードにより公示されるあらゆる発行済み指値注文に対するレコードを保持することである。そのような指値注文レコード２０００の一例が図２０に示されている。新しい指値注文の生成を報告するイベントが記号フィールドを含まなければならず、したがって、イベントがＯＮＰＡモジュール１２０８に到着するとき、イベントは記号マッピング段階により解決される記号識別子を含む。イベントが、その後のメッセージサイズを最小にするために注文参照番号を使用する市場センタからのものである場合、イベントはまた注文参照番号を含む。ＯＮＰＡモジュール１２０８は、注文レコードへのマップを保持し、この場合、レコード２０００は、市場センタにより提供される記号識別子、注文参照番号、価格、量、および別のフィールドを含むことがある。好ましくは、ＯＮＰＡモジュール１２０８はまた、別のシステム構成要素により注文レコードを直接アドレスするために使用されることがある一意の内部注文識別子２００２を割り当てる。

【0073】

図２０の例では、指値注文レコード２０００は複数のフィールドを、たとえば以下を含む：
本明細書で指摘されたような一意の内部識別子フィールド２００２。

【0074】

本明細書で指摘されたような記号フィールド２００４。

【0075】

本明細書で指摘されたようなＧＥＩＤフィールド２００６。

【0076】

本明細書で指摘されたような参照番号フィールド２００８。

【0077】

本明細書で指摘されたような買い／売りフィールド２０１０。

【0078】

本明細書で指摘されたような価格フィールド２０１２。

【0079】

本明細書で指摘されたような量フィールド２０１４。以下に説明されるように、レコード２０００でのこのフィールドの値は、注文修正イベントが受信されたとき、時間がたつにつれ更新されることがある。

【0080】

本明細書で指摘されたようなタイムスタンプフィールド２０１６
第１の属性（Ａ０）（たとえば、注文が一時的地域注文に関係があるかどうかを識別するため）に対するフラグフィールド２０１８
第２の属性（Ａ１）（たとえば、注文が暗黙の注文かどうかを識別するため）に対するフラグフィールド。Ａ０およびＡ１のフラグは一緒に、指値注文レコード２０００内部の注文属性ベクトル２０３０として特徴付けられることができる。

【0081】

対象の指値注文に関心がある下流の購読者を識別するのに役立つ関係者（ｉｎｔｅｒｅｓｔ）ベクトルフィールド２０２２。任意選択で、このベクトルは、どの購読者がどの指値注文に関心があるかを識別するだけでなく、各指値注文レコード内のどのフィールドに各購読者が関心があるかも識別するように構成されることができる。

【0082】

しかしながら、この場合も、指値注文レコード２０００はより多くのまたはより少ないデータフィールドを、および／または異なるデータフィールドを有するように構成されることができることに留意すべきである。

【0083】

好ましくは、平均して一定した時間アクセス性能を達成するために、指値注文レコード２０００への受信された指値注文イベント１６００のマッピングはハッシングを使用して行われる。ハッシュキーは、注文参照番号、記号識別子、または別の一意に識別するフィールドから構築されることがある。ハッシュキーのタイプは、市場センタのデータフィードのタイプにより決定される。イベントの事前正規化を行う上流のフィードハンドラが、取引所がどのタイプのプロトコルを使用するか、および一意のハッシュキーを構築するためにどのフィールドが利用できるかに関してＯＮＰＡモジュールに通知するフラグをイベント内にセットする。たとえば、この情報はＧＥＩＤフィールド２００６内、または指値注文イベント１６００の何らかの別のフィールド内に符号化されることがある。ＯＮＰＡモジュールにより使用されることができる様々なハッシュ関数がある。好ましい実施形態では、ＯＰＡは、上記で議論されたような、上記で参照され組み込まれた、米国特許出願公開第２００８／０２４３６７５号明細書のＨ３ハッシュ関数を、Ｈ３ハッシュ関数の効率性および並列ハードウェア実装に対するなじみやすさのために利用する。ハッシュ衝突はいくつかの方法で解決されることがある。好ましい実施形態では、衝突はチェーニングを介して、すなわち同じハッシュスロットにマッピングする項目の連結リストを生成することにより解決される。連結リストが、１組の変化でいくつかの項目としてメモリが動的に割り当てられるようにすることができる簡単なデータ構造となる。

【0084】

ひとたびレコードが探し出されると、ＯＮＰＡモジュールはレコード内のフィールドを更新し、レコードからメッセージにフィールドをコピーし、出力メッセージを正規化するために必要な欠けたフィールドを埋める。ＯＮＰＡモジュールが市場イベントの結果と整合性があるようにメッセージのタイプを修正することがあるのがこのステップ中である。たとえば、入力メッセージが、１００の株式が注文から引かれるべきである（市場センタでの部分的実行による）ことを指定する修正イベントであり、発行済み注文が１００の株式のためのものである場合、ＯＰＡは、市場センタの規則に従って、メッセージのタイプを削除イベントに変える。市場センタは、規則たとえばゼロの量の注文が注文ブックに残っているかどうかを規定することがあることに留意されたい。別のシナリオでは、処理済み注文が１５０の株式のためのものである場合、ＯＮＰＡモジュールは指値注文レコードの量フィールド２０１４を更新して、１５０の値を、注文から１００の株式の削除を反映する５０に置換する。一般にＯＮＰＡモジュールは市場データイベントの最も事実に基づき整合性のあるビューを提示しようとする。ＯＮＰＡモジュール内部のハードウェア論理回路がこれらの更新および正規化のタスクを提供するように構成されることができる。

【0085】

注文メッセージを正規化することに加えて、ＯＮＰＡモジュールは注文ブックの価格集計ビューをサポートするために価格集計をさらに行うことがある。好ましくは、ＯＮＰＡモジュールは、独立した１組の価格ポイントレコードを保持する。このデータ構造では、注文ブック内のそれぞれの一意の価格ポイントに対してレコードが保持される。最低で１組の価格ポイントレコードが価格、出来高（その価格での注文量の総計、価格出来高として参照されることができる）、および注文カウント（その価格での注文の総数）を含むことが好ましい。注文追加イベントは出来高および注文カウントのフィールドを増大させ、注文削除イベントは出来高および注文カウントのフィールドなどを低減させる。価格ポイントレコードは、注文イベントがブックに対して新しい価格ポイントを追加するときに生成される。同様に、価格ポイントレコードは、注文イベントがブックから所与の価格ポイントを有するレコードだけを削除するときに削除される。好ましくは、ＯＮＰＡモジュールは、イベントがブック内の価格項目の追加、修正、または削除をもたらしたかどうかを指定する強化された指値注文イベント１６０４内のＡＭＤフラグを更新する（図２２の価格ＡＭＤフィールド２２２６参照）。この情報は、下流のソーティングエンジンを最適化するために使用されることがある。好ましくは、ＯＮＰＡモジュールはまた、別のシステム構成要素により価格レコードを直接アドレスするために使用されることがある各価格レコードに一意の内部価格識別子を割り当てる。

【0086】

指値注文イベント１６００を価格ポイントレコードにマッピングすることも、多対１マッピング問題であることに留意されたい。好ましくは、１組の価格ポイントレコードが、注文レコードに類似するハッシュマッピングを使用して保持される。注文イベントに関連する価格ポイントレコードを探し出すために、ハッシュキーがフィールドからたとえば記号識別子、広域取引所識別子、および価格から構築される。好ましくは、ハッシュ衝突は注文レコードデータ構造と同様のチェーニングを使用して解決される。別のデータ構造が１組の注文レコードおよび価格ポイントレコードを保持するために適していることがあるが、ハッシュマップは、（平均して）一定の時間アクセスという有利な特性を有する。

【0087】

効果的属性フィルタリング、および下流のブックビューでの価格水準併合をサポートするために、ＯＮＰＡモジュールは、価格ポイントレコードの一部として価格属性ベクトルを保持することが好ましく、この場合、価格属性ベクトルはまた、各価格ポイントレコードの出来高および価格カウントのベクトルを含む。たとえば、価格ポイントレコードは、以下のフィールド、すなわち価格、出来高（総株式、またはこの価格でのロット）、注文カウント（この価格での総注文）、属性フラグ、属性出来高０（属性０に対するこの価格での総株式またはロット）、注文カウント０（属性０に対するこの価格での総注文）、属性出来高１、属性注文カウント１などを含むことがある。そのような価格ポイントレコードの例が図２１ａおよび図２１ｂに示されている。一般に、所与の金融商品に対する一意の属性の数は少ないと予想される。好ましくは、ＯＮＰＡモジュールは、可能な属性の数が所与の金融商品に対して動的に規定されることができるようにするように構成できる。

【0088】

ＯＮＰＡモジュールは、強化された指値注文イベント１６０４を生成するとき、イベントに出来高、注文カウント、および価格属性を付加することがある。好ましくは、ＯＮＰＡモジュールは、任意の下流のアプリケーションまたは構成要素が価格集計情報および／または属性情報を必要としているかどうかを指定する価格関係者ベクトルを保持する。さらに、ＯＮＰＡモジュールは、属性により規定されるブック内の価格項目の追加、修正、または削除をイベントがもたらしたかどうかを指定するイベント内のフラグを更新することが好ましい。（図２２の価格ＡＭＤフィールド２２２６参照）。

【0089】

価格ポイントレコードを記憶するために使用されるデータ構造は、指値注文に対する地域価格ポイントレコード２１００および複合価格ポイントレコード２１５０を別個に保持することが好ましい。地域価格ポイントレコード２１００が、特定の地域取引所で売買される金融商品に関係がある指値注文に対する価格ポイント情報を記憶する。複合価格ポイントレコード２１５０が、多数の取引所にわたり売買される金融商品に関係がある指値注文に対する価格ポイント情報を記憶する。地域価格ポイントレコードの一例が、図２１ａに示され、複合価格ポイントレコードの一例が図２１ｂに示されている。

【0090】

例示的地域価格ポイントレコード２１００が多数のフィールドを、たとえば以下のようなフィールドを含む：
対象の価格ポイントレコードに関して内部識別子を提供するための一意の内部（ＵＩ）地域価格識別子フィールド２１０２。

【0091】

本明細書で指摘されたような記号フィールド２１０４。

【0092】

本明細書で指摘されたようなＧＥＩＤフィールド２１０６。

【0093】

本明細書で指摘されたような買い／売りフラグフィールド２１０８。

【0094】

本明細書で指摘されたような価格フィールド２１１０。

【0095】

価格フィールド２１１０内で識別される価格で、地域取引所（ＧＥＩＤフィールド２１０６参照）での金融商品（記号フィールド２１０４）に対するすべての指値注文にわたる株式の出来高を識別する出来高フィールド２１１２。

【0096】

どれだけの指値注文が出来高２１１２を作り上げているかのカウントを含むカウントフィールド２１１４。

【0097】

上記で指摘されたようなタイムスタンプフィールド２１１６（対象の価格ポイントレコードに更新をもたらした最も新しい指値注文イベント１６００に対するタイムスタンプ１９１４を表すことが好ましい）。

【0098】

上記で指摘されるような、好ましくは任意の属性が、対象の価格ポイントレコードを作り上げる出来高の少なくとも一部に適用できるかどうかフラグを立てるだけでなく、出来高の内訳および各属性のカウントも提供する地域価格属性ベクトル２１４０。たとえば、属性Ａ０に対する出来高２１２０およびカウント２１２２と一緒に、属性Ａ０が適用できるかどうかを示すフラグ２１１８、ならびに属性Ａ１に対する出来高２１２６およびカウント２１２８と一緒に、属性Ａ１が適用できるかどうかを示すフラグ２１２４。

【0099】

対象の価格ポイントレコードに関心がある下流の購読者を識別するのに役立つ関係者ベクトルフィールド２１３０。任意選択で、このベクトルは、どの購読者が地域価格ポイントレコードに関心があるかを識別するだけでなく、各地域価格ポイントレコードのどのフィールドに各購読者が関心を有するべきかをも識別するように構成されることができる。

【0100】

例示的複合価格ポイントレコード２１５０が複数のフィールドを、たとえば以下を含む：
対象の価格ポイントレコードに関して内部識別子を提供するための一意の内部（ＵＩ）複合価格識別子フィールド２１５２。

【0101】

本明細書で指摘されたような記号フィールド２１５４。

【0102】

本明細書で指摘されたような買い／売りフィールド２１５６。

【0103】

本明細書で指摘されたような価格フィールド２１５８。

【0104】

複合価格ポイントレコードで一緒に集計されるすべての地域価格ポイントレコードに対する出来高フィールド２１１２の総計を本質的に含む出来高フィールド２１６０。

【0105】

複合価格ポイントレコードに一緒に集計されるすべての地域の価格ポイントレコードに対するカウントフィールド２１１４の総計を本質的に含むカウントフィールド２１６２。

【0106】

上記で指摘されたようなタイムスタンプフィールド２１６４（対象の価格ポイントレコードに更新をもたらした最も新しい指値注文イベント１６００に対するタイムスタンプ１９１４を表すことが好ましい）。

【0107】

上記で指摘されるような、任意の属性が対象の価格ポイントレコードを作り上げる出来高の少なくとも一部に適用できるかどうかのフラグを立てるだけでなく、各属性に対する出来高およびカウントの内訳も提供することが好ましい複合価格属性ベクトル２１８０。たとえば、属性Ａ０に対する出来高２１６８およびカウント２１７０と一緒に、属性Ａ０が適用できるかどうかを示すフラグ２１６６、ならびに属性Ａ１に対する出来高２１７４およびカウント２１７６と一緒に、属性Ａ１が適用できるかどうかを示すフラグ２１７２。

【0108】

対象の価格ポイントレコードに関心がある下流の購読者を識別するのに役立つ関係者ベクトルフィールド２１７８。任意選択で、このベクトルは、どの購読者が複合価格ポイントレコードに関心があるかを識別するだけでなく、各複合価格ポイントレコード内のどのフィールドに各購読者が関心があるべきかをも識別するように構成されることができる。

【0109】

しかしながら、この場合も、地域価格ポイントレコード２１００および複合価格ポイントレコード２１５０が、より多くのもしくはより少ないデータフィールド、および／または異なるデータフィールドを有するように構成されることができることに留意すべきである。

【0110】

好ましい実施形態では、並列エンジンが注文および価格の集計データ構造を並列に更新し保持する。一実施形態では、データ構造が同じ物理メモリ内に保持される。この場合、１つまたは複数の注文エンジン、および１つまたは複数の価格エンジンが、メモリへのこれらのエンジンのアクセスをインタリーブし、メモリ技術のメモリアクセス待ち時間を消し、システムのスループットを最大にする。メモリインタリーブのための多様な知られている技法がある。一実施形態では、エンジンコントローラブロックが、各エンジンが一定間隔でメモリへのアクセス権を与えられるタイムスロット方式を利用する。別の実施形態では、メモリ調停ブロックが共有インタフェース上の発行済みメモリ要求をスケジュールし、発行済みメモリ要求がいつ満たされるかをエンジンに通知する。好ましくは、メモリ技術が高速ダイナミックメモリたとえばＤＤＲ３ ＳＤＲＡＭである。別の実施形態では、注文および価格のデータ構造は、別個の物理メモリ内に保持される。単一メモリアーキテクチャのように、多数のエンジンがメモリアクセス待ち時間を消し、スループットを最大にするためにメモリへのエンジンのアクセスをインタリーブすることがある。

【0111】

図１７は、単一共有メモリが、注文正規化、地域価格集計、および複合価格集計をサポートするためにどのように分割され得るかの一例を示す。この例では、各ハッシュテーブルがメモリ空間の一部を割り当てられる。ハッシュ衝突はチェーニングにより、すなわち同じハッシュスロットにマッピングする項目の連結リストを生成することにより解決される。すべての３つのハッシュテーブルに対する連結リスト項目が、共通のメモリ空間から動的に割り当てられる。図１８は、ＯＮＰＡモジュールデータ構造が多数の物理メモリ全体にどのように分割されることがあるかの一例を示す。この具体的例では、正規化データ構造が一方の物理メモリ内に記憶されるのに対して、地域価格および複合価格の集計データ構造が第２の物理メモリ内に記憶される。このアーキテクチャによりメモリアクセスが並列に行われることができるようになる。

【0112】

したがって、ＯＮＰＡモジュール１２０８は、指値注文イベント１６００の受信すると、（１）指値注文イベント１６００内のデータを処理して、メモリ１６０２（多数の物理メモリでもよい）にアクセスし、必要に応じて指値注文レコード２０００、地域価格ポイントレコード２１００、および複合価格ポイントレコード２１５０を取り出し、（２）指値注文イベント内のデータおよび取り出されたレコードを処理して、必要に応じてレコードを更新し、（３）新しい情報で指値注文イベント１６００を強化して、強化された指値注文イベント１６０４を生成する。そのような強化された指値注文イベント１６０４の一例が図２２に示されている。好ましくは、ＯＮＰＡモジュールは指値注文イベント１６００に対して、下流の購読者に市場深度に関する価値のある情報を提供するいくつかのフィールドを付加する。図２２の例では、強化された指値注文イベント１６０４はフィールドたとえば以下のようなフィールドを含む：
一意の内部（ＵＩ）識別子のためのフィールド２２０２（たとえばＵＩ ＩＤ ２００２、ＵＩ地域価格ＩＤ ２１０２、およびＵＩ複合価格ＩＤ ２１５２）。

【0113】

本明細書で指摘されたような記号フィールド２２０４。

【0114】

本明細書で指摘されたようなＧＥＩＤフィールド２２０６。

【0115】

本明細書で指摘されたような参照番号フィールド２２０８。

【0116】

本明細書で指摘されたような買い／売りフラグフィールド２２１０。

【0117】

本明細書で指摘されたような価格フィールド２２１２。

【0118】

本明細書で指摘されたような量フィールド２２１４。

【0119】

本明細書で指摘されたようなタイムスタンプフィールド２２１６。

【0120】

地域出来高フィールド２２１８および地域カウントフィールド２２２０。ＯＮＰＡモジュール１２０８は、その指値注文イベントに関係がある取り出された地域価格ポイントレコードに対する更新された出来高およびカウントの値に基づき、指値注文イベントに対して地域出来高フィールド２２１８および地域カウントフィールド２２２０を付加するように構成されることが好ましいことに留意すべきである。

【0121】

複合出来高フィールド２２２２および複合カウントフィールド２２２４。ＯＮＰＡモジュール１２０８は、その指値注文イベントに関係がある取り出された複合価格ポイントレコードに対する更新された出来高およびカウントの値に基づき、指値注文イベントに対して複合出来高フィールド２２２２および複合カウントフィールド２２２４を付加するように構成されることが好ましいことに留意すべきである。

【0122】

指値注文が追加、修正、または削除（ＡＭＤ）に関係があるかどうかを識別するためのフィールド２２２６（指値注文イベントに関係がある指値注文レコードに対して指値注文イベントの内容に基づきＯＮＰＡモジュールが更新することがあるフィールド）。

【0123】

指値注文イベントが地域価格ポイントレコードおよび／または複合価格ポイントレコードから追加、修正、または削除をもたらしたかどうかを識別するための価格ＡＭＤフィールド２２２８。ＯＮＰＡモジュールは、地域価格ポイントレコードおよび複合価格ポイントレコードが、受信された指値注文レコード１６００の内容に応答してどのように処理されたかに基づき、指値注文に対して価格ＡＭＤフィールド２２２８を付加することができる。

【0124】

ＯＮＰＡモジュールが、指値注文イベントに関係がある地域価格ポイントレコードおよび複合価格ポイントレコードに対する更新された属性ベクトル２１４０および２１８０の強化として指値注文イベントに付加することができる強化された属性ベクトル２２５０。この強化された属性ベクトルはまた、関係がある指値注文レコードからの注文属性ベクトル２０３０を含むことができる。したがって、強化された属性ベクトル２２５０は、注文属性ベクトルフィールド２２３０、地域価格属性ベクトルフィールド２２３２、および複合価格属性ベクトルフィールド２２３４を含むことがある。

【0125】

強化された指値注文イベント内に見つけられるデータに関心を有する下流の購読者を識別するのに役立つ関係者ベクトルフィールド２２３６。ＯＮＰＡモジュールは、指値注文イベントに関係がある指値注文レコード、地域価格ポイントレコード、および複合価格ポイントレコードに対する関係者ベクトル２０２２、２１３０、および２１７８の強化として関係者ベクトルを付加することができる。

【0126】

しかしながら、この場合も、ＯＮＰＡモジュールはより多いおよびより少ないデータフィールド、ならびに／または異なるデータフィールドを使って指値注文イベントを強化するように構成されることができることに留意すべきである。

【0127】

したがって、出力される強化された指値注文イベント１６０４は、非常に少ない待ち時間でＯＮＰＡモジュール１２０８により生成されることができる処理された指値注文データ１２１０のストリームビューの役割を果たす。

【0128】

ＯＮＰＡモジュール１２０８に対する例示的実施形態のブロック図が図２３に示されている。

【0129】

エクストラクタモジュールは、ＯＮＰＡモジュール内部のモジュールの残りにより必要とされるフィールドを入力市場イベントから抽出し、それらのフィールドを下流のモジュールに並列に提示する責任がある。エクストラクタはまた、メッセージ再構成のためにブレンダモジュールにイベントを転送する。

【0130】

価格ノーマライザモジュールは、不定に入力された価格を正規化された固定サイズの価格（たとえば、６４ビット値）に変換する。好ましい実施形態では、新しい価格は１０億分の１または２５６分の１の単位である。２のべき乗の価格変換は単なるシフトにより行われることがある。１０のべき乗の価格変換はシフトおよび加算のパイプラインで行われる。

【0131】

好ましい実施形態では、ハッシュモジュールが以下を行う責任がある：
注文ハッシュモジュール−記号、取引所識別子、および注文参照番号をハッシュして、所望の注文を含むまたは含むことになる連結リスト内の第１の項目を含むメモリの静的注文領域へのアドレスオフセットを生成する。

【0132】

価格ハッシュモジュール−記号、取引所識別子、および価格をハッシュして、所望の価格水準を含むまたは含むことになる連結リスト内の第１の項目を含むメモリの静的価格領域（地域価格レコードと複合価格レコードの両方）へのアドレスオフセットを生成する。

【0133】

ヘッダハッシュモジュール−記号および取引所識別子をハッシュして、注文リフレッシュリストと価格リフレッシュリストの両方の第１の項目へのポインタを含む静的ヘッダ領域へのアドレスオフセットを生成する。

【0134】

そのようなリフレッシュリストに関して、本発明者らは、リフレッシュイベントがクライアントアプリケーションに提供されるブックビューを初期化するために使用されることができることを指摘する。したがって、レベル２処理パイプラインの責任の１つが、クライアントアプリケーション初期化のためのブックスナップショット生成することとすることができる。購読時に、リフレッシュイベントが時間の特定の瞬間でのブックのスナップショットを提供する。関係者ベクトル内の該当するビットが適切なデータ構造でセットされるのがこの時点である。リフレッシュイベントに続き、ブックのクライアントアプリケーションのビューを更新するために、増分更新イベントがクライアントアプリケーションに届けられる。リフレッシュイベントは、ＦＡＭパイプライン内で増分更新イベントと共にインライン処理されることがある。ブックスナップショットを生成するオーバヘッドを最小にするために、リフレッシュイベントは非同期で処理されることがある。ブックのスナップショットが最も新しい更新のイベントシーケンス番号を記録する原子的なイベントである限り、スナップショットはすべての増分更新トラフィックに対して同期して処理される必要がない。クライアントＡＰＩ内のバッファを同期させることは、リフレッシュイベントの受信前に受信された増分更新をバッファに入れるために使用されることがある。リフレッシュイベントが受信されたとき、同期バッファ内の増分更新が処理される。リフレッシュイベントに示されるシーケンス番号以下のシーケンス番号を有する更新が捨てられる。

【0135】

注文エンジンモジュールは以下の責任がある：
指値注文レコードに対するハッシュ連結リストを詳しく検討する。

【0136】

リフレッシュに対するリフレッシュ連結リストを詳しく検討する。

【0137】

指値注文レコードに対する追加、修正、および削除を行う。

【0138】

連結リストに必要な保守を行う。

【0139】

価格エンジンモジュールは以下に責任がある：
地域価格ポイントレコードおよび複合価格ポイントレコードでの価格水準に対するハッシュ連結リストを詳しく検討する。

【0140】

リフレッシュに対するリフレッシュ連結リストを詳しく検討する。

【0141】

地域価格ポイントレコードおよび複合価格ポイントレコードに対して所与の価格水準での注文の追加、修正、および削除に対する集計タスクを行う。

【0142】

データ構造から必要に応じて価格水準を追加および削除する。

【0143】

連結リストに必要な保守を行う。

【0144】

キャッシュモジュールは、最も新しくアクセスされたレコードを高速のオンチップメモリ内に保持することにより性能を最適化する。キャッシュモジュールは以下に責任がある：
高速で古くなっていないアクセスのために指値注文レコード、価格ポイントレコード、およびヘッダノードを記憶する。

【0145】

どのＳＤＲＡＭアドレスがキャッシュされるかについて常に知っている。

【0146】

注文エンジンまたは価格エンジンにより要求されたときにキャッシュされていないデータをＳＤＲＡＭから取り出す。

【0147】

ＳＤＲＡＭアドレスが必要とされるときに直接アクセスのためのローカルのオンチップメモリアドレスを提供する。

【0148】

作業ＦＩＦＯモジュールは以下に責任がある：
パイプライン休止状態中に操作データを記憶する。

【0149】

自動アドレス転送のために削除中に注文エンジンおよび価格エンジンからの次のポインタ情報を監視する。

【0150】

リフレッシュ待ち行列モジュールは、別のリフレッシュが現在処理されている間に、受信されたリフレッシュを記憶するように構成される。ブレンダモジュールは、同時発生のリフレッシュの数を制限しながら、一度に１つの注文リフレッシュおよび１つの価格リフレッシュしか調べることができないことがある。ＳＤＲＡＭアービタモジュールは、注文エンジンおよび価格エンジンから２つのＳＤＲＡＭインタフェースへのアクセスを調停する。ブレンダモジュールはまた、元のイベント、ならびに注文エンジンおよび価格エンジンにより生成される様々なフィールド（図２２参照）を使用して、出力される強化され正規化されたイベントを構築する。ブレンダモジュールはまた、リフレッシュからのマイクロイベントを合体させて、出力される要求されたリフレッシュイメージを生成する。ブレンダモジュールはまた、リフレッシュとイベントストリームの間の不一致を正常化するように構成されることが好ましい。

【0151】

実行者により望まれる場合、ＯＮＰＡモジュールのストリームビュー出力１２１０は、強化された指値注文イベントを含むが、適切なストリームビュー購読でクライアントに直接送信されることがある。関係者および資格フィルタリング（ＩＥＦ）モジュール１２１０が、図１２ｂおよび図１２ｃに示されるようにＯＮＰＡモジュールから下流に配置されることができる。ＩＥＦモジュール１２１０は、上記で参照され組み込まれた、米国特許出願公開第２００８／０２４３６７５号明細書で説明されているように、所与の強化された指値注文イベントに対して１組の関心があり資格が与えられたクライアントを解決するためにマッピングされた記号インデックスを利用するように構成されることができる。また、関係者ベクトルフィールド２２３４を含む強化された指値注文イベント１６０４に対して、ＩＥＦモジュール１２１０はまた、関心があり資格が与えられたクライアントを識別するためにそのような関係者ベクトルを利用することができる。ＩＥＦモジュールのフィルタリングアスペクトは、クライアントアプリケーションにより指定されるブックビューのタイプに基づき、強化された指値注文イベント１６０４から特定のフィールドをフィルタリングするように拡張されることがある。たとえば、ソートされた注文ビューは、価格集計出来高フィールドおよび注文カウントフィールドを必要とせず、ＩＥＦモジュール１２１０は、ソートされた注文ビューを望むクライアントのために、強化された指値注文イベントから価格集計出来高フィールドおよび注文カウントフィールドを削除するように構成されることができる。イベント伝送待ち時間が低減されることができ、下流のネットワーク帯域幅は更新イベントから価格集計出来高フィールドおよび注文カウントフィールドを省くことにより節約されることができる。

【0152】

図１２ｃに示されるように、メッセージフォーマッティング（ＭＦ）モジュール１２１２は、関心があり資格がある購読者行きの出力される強化された指値注文イベントをそれらの購読者により期待されるメッセージ書式に設定するために、ＩＥＦモジュール１２１０から下流に導入されることができる。ＭＦモジュール１２１２の例示的実施形態が、上記で参照され組み込まれた、米国特許出願公開第２００８／０２４３６７５号明細書で説明されている。

【0153】

上記で指摘されたように、一部のクライアントが、注文ブックデータの自分自身のソートされた構造を構築するので、強化された指値注文イベントを含むストリームビューを受け取ることを好むことがある。したがって、本発明の一実施形態では、図１２ａから図１２ｃに示されるパイプライン１２００の出力は、図２４に関連して示されるように、その出力がチッカ装置に関連するアプリケーションプログラミングインタフェース（ＡＰＩ）により処理される消費システム（クライアントマシン）に送信されることができる。ＡＰＩはソーティングを行い、クライアントアプリケーションにデータの要約ビューを提示する。ソーティングタスクは、当技術分野で知られている様々な技法を使用して行われることがある。

【0154】

しかしながら、別のクライアントが、チッカ装置自体から要約ビューを受け取ることを好むことがある。本発明の追加の実施形態として、本発明者らは、注文データの要約ビューを生成するためにチッカ装置コプロセッサ内部に実装されるパイプライン１２００内に導入されることができるソーティング技法を開示する。しかしながら、これらのソーティング技法はまた、実行者により望まれる場合、図２４に示されるようなＡＰＩで実行されることができることに留意すべきである。

【0155】

図２５ａから図２５ｄは、ソートされたビュー更新（ＳＶＵ）モジュール２５００が、強化された指値注文イベントから注文ブックの要約ビュー２５０２を生成するために含まれるパイプライン１２００の例示的実施形態を描く。図２５ｂから図２５ｄの例では、パイプライン１２００が、関心のあるクライアントへのストリームビュー１２１０も、関心のあるクライアントへの要約ビュー２４０２も提供するように構成されることに留意すべきである。

【0156】

ＳＶＵモジュール２５００はいくつかの技法の任意を介してソーティング機能を提供するように構成されることができるが、好ましい実施形態では、ＳＶＵモジュールは、各注文ブックのそれぞれの側（買いおよび売り）を独立に保持するためにソーティングエンジンを利用する。入力の注文イベントおよび価格イベントは注文ブックの片側にしか影響を及ぼさないので、ブックのそれぞれの側に独立にアクセスすることは、アクセスされなければならない可能性のある項目の数を低減し、ブックの両側への並列アクセスに備える。ブックのそれぞれの側は、物理メモリ中にソートされた注文の中に保持される。ブックは、ブックのためのメモリ割り当ての最下部に「つなぎ留められる」、すなわち、最後の項目がメモリ割り当てにおける最後のアドレスで常に記憶されることが好ましい。その結果、ブックの「最上部」（最初の項目）の位置は、注文ブックの構成が変化するにつれて、変わる。ブックの最上部を探し出すために、ＳＶＵモジュール２５００は、ブックを説明することがある別のメタデータだけでなく、ブックの買いおよび売りの側の最上部へのポインタを含むレコードも保持する。レコードは、記号マップインデックスを使用することにより直接探し出されることがある。ブックの中に項目を挿入することが、挿入位置の上の項目を１メモリ位置上に移動させることに留意されたい。ブック内の項目を削除することが、挿入位置の上の項目を１メモリ位置下に移動させる。これらの動作は多数のメモリコピーをもたらすことがあるが、注文ブック取引の大多数が注文ブック内の最上部の位置に影響を及ぼすので、性能は典型的にはよい。強化された指値注文イベント１６０４内の価格ＡＭＤフィールド２２２６が、価格項目が挿入されたかまたは削除されたかどうかを指定するので、ＳＶＵモジュール２５００内部のソーティングエンジンはこの情報を利用して、ソートされたメモリアレイを通る単一パスを作ることができる。さらに、ＯＮＰＡモジュール内部の価格集計エンジンは価格ポイントレコード内の各価格項目に対するすべての出来高、注文カウント、および属性情報を保持するので、ＳＶＵデータ構造での項目はソーティングに必要とされる値しか記憶する必要がない。

【0157】

地域注文要約ビューについては、ＳＶＵモジュールは、各取引所が売買する、各取引所での各記号に対する１対の買いおよび売りのブックを保持することが好ましい。各ブック内の項目は１つの取引所からのものである。ＯＮＰＡモジュール内部の注文エンジンは注文に関連するすべての情報を保持するので、ＳＶＵデータ構造はソーティングに必要なフィールド、およびＯＮＰＡモジュールにより割り当てられる一意の注文識別子だけを保持する必要がある。場合によっては、価格およびタイムスタンプだけがソーティングのために必要とされる。

【0158】

価格要約ビューについては、ＳＶＵモジュールは、各記号に対して１対の接合された買いおよび売りのブックを保持することが好ましい。各ブック内の項目は、記号が売買するあらゆる取引所からのものである。ＯＮＰＡモジュール内部の価格集計エンジンは、価格水準に関連するすべての情報を保持するので、ＳＶＵデータ構造は、ソーティングに必要なフィールド（すなわち価格）、およびＯＮＰＡモジュールにより割り当てられる一意の価格識別子だけを保持する必要がある。価格ブックの複合ビュー、接合ビュー、および地域ビューが、この単一の接合されたブックから合成されることがある。価格ブックの属性でフィルタリングされたビューおよび価格併合ビューが、同じ方法で合成されることがある。ＳＶＵモジュール内の価格ブックソーティングエンジンが、多数の地域項目を集計することにより所望のビューを計算して複合項目および位置を生成する、および不要な地域価格項目をフィルタにかけて地域項目および位置を生成する。各ブックの内容がメモリからエンジンを通って流されるときに、これらの計算が行われる。各更新イベントのために消費されるメモリ帯域幅を最小にするために、エンジンは、典型的には注文ブック全体よりもサイズが小さいメモリのチャンクを要求する。典型的には、デフォルトのメモリチャンクサイズはシステム構成時に指定される。エンジンは、ブックの最上部を取り出すためにデフォルトのチャンクサイズを要求する。追加のブック項目がアクセスされなければならない場合、エンジンは次のメモリチャンクを要求し、前のチャンクの終わりのアドレスを基準として次のアドレスで拾い上げる。メモリのチャンクを読み出す、処理する、およびメモリの次のチャンクを要求する待ち時間を消すために、多数のエンジンがメモリへの多数のエンジンのアクセスをインタリーブする。ＯＮＰＡモジュール内部のように、インタリーブは、多数のエンジンに対してメモリ処理をスケジュールするメモリ調停ブロックを使用することにより達成される。タイムスロットメモリコントローラも使用されることがあることに留意されたい。エンジンは、データの正しさに影響を及ぼすことなく一意の記号に対して並列に動作することがある。

【0159】

ソートされたビュー更新モジュールの別の実施形態では、ブックのそれぞれの面が階層型多分木として編成される。多分木の深度は、各ノードから分かれる子分岐の数により規定される。Ｂ＋木が、木の中のすべての項目が同じレベルで、すなわち葉のレベルで記憶される多分木の一例である。典型的には、木の中の葉ノードに、すなわち所望の項目に到達するために訪問されなければならないノードの数を最小にするために、多分木の高さは最小にされる。Ｂ＋木の一例が図２６に示されている。木の内容全体が、最も左の子に誘導し次の子ノードへのポインタに従うことによりアクセスされ得るように、葉ノードが連結リストとして編成されることがあることに留意されたい。この特徴は、新しく購読したクライアントを初期化するために、注文ブックの内容全体のスナップショットであるリフレッシュイベントを即座に生成するために、ＳＶＵモジュール内で利用されることができる。さらに、最も左の子への直接のポインタが、記憶されたブックの最上部への高速アクセスを提供するために、ルートノードと一緒に記憶されることがある。

【0160】

図２６は、Ｂ＋木を使用してソートされた１組の正整数の簡単な例を示す。記憶された整数のすべてが葉ノードに記憶されることに留意されたい。当技術分野で知られているが、Ｂ＋木ノードは、木の分岐因子により規定される最小サイズおよび最大サイズのしきい値の間でサイズが変わる。記憶された注文全体を取り出すために迅速に横断されることがある葉ノードの連結リストを生成するために、「次のポインタ」が各葉ノード内に記憶されていることに留意されたい。内部の木ノードは、子コードを記憶される範囲を規定する整数を含む。たとえば、７以下のすべての整数が、ルートノードの左の部分木内に記憶される。

【0161】

ＳＶＵモジュールは、階層型Ｂ＋木を利用して、様々なブックビューを更新するために必要とされるメモリアクセスの数を最小にするように構成されることができる。図２７に示されるように、ＳＶＵモジュールは、複合ブック木および地域ブック木のルートへのポインタを含むヘッダレコードを保持するように構成されることができる。ルート木は価格集計木である。価格集計木の各葉は、所与の価格ポイントでの注文のソートを保持するＢ＋木へのポインタを含む。そのような実施形態では、ＳＶＵモジュールがブックの複合ビューおよび各地域ビューに対する階層型Ｂ＋木を保持することが好ましい。ブックのそれぞれの側（買いおよび売り）が階層型Ｂ＋木に対応することに留意されたい。階層型Ｂ＋木はまた、クライアントマシン上のＡＰＩによりソーティングが行われる実施形態で使用されることがあることに留意されたい。さらに、ソーティングの一部がクライアントマシン上のＡＰＩに肩代わりさせられることがあることに留意されたい。たとえば、ブックの接合されたビューの構築が、すべての地域ブックの要約ビューを購読することによりＡＰＩに肩代わりさせられることがある。

【0162】

前の実施形態における挿入ソーティングエンジンと同様に、並列の１組の木横断エンジンが並列に動作し、そのエンジンのアクセスをメモリにインタリーブすることができる。さらに、ＳＶＵモジュールは任意選択で、メモリ読み出し待ち時間をさらに低減するために、オンチップメモリ内に最近アクセスされた木ノードをキャッシュすることがある。

【0163】

図２８は、ＳＶＵモジュール２５００に対する例示的実施形態を描く。ＯＮＰＡモジュールのように、図２８のＳＶＵモジュール２５００は、機能上のパイプラインを利用して、ディスパッチングエンジンとソーティングエンジンの間の並列処理を達成する。ＳＶＵモジュール２５００はまた、利用できるメモリ帯域幅を完全に利用してメッセージスループット性能を最大にするために、データ並列処理を使用して、多数のソーティングエンジンをインスタンス生成する。

【0164】

エクストラクタモジュールは、ＯＮＰＡモジュールに関連して説明されたような処理のために必要なフィールドを抽出する同じサービスを提供し、エクストラクタモジュールはディスパッチャにそれらのフィールドをさらに伝える。エクストラクタモジュールはまた、ブレンダモジュールに完全なイベントを伝えることが好ましい。

【0165】

ディスパッチャモジュールは、複合ブック木および地域ブック木へのポインタを含むヘッダレコードを取り出す責任がある。ディスパッチャモジュールとＳＤＲＡＭアービタモジュールの間に配置されるキャッシュが、最近アクセスされたヘッダレコードへの迅速なアクセスを提供する。作業ＦＩＦＯモジュールがイベントフィールドおよび動作状態を記憶するのに対し、ディスパッチャモジュールはメモリ動作が完了するのを待っている。このことが、ディスパッチャモジュールが多数のイベントに対して並列に動作することができるようにする。

【0166】

ブックポインタがメモリから受信されたとき、ディスパッチャモジュールはイベントフィールドおよびブックポインタをいくつかの並列ソーティングエンジンモジュールの１つに渡す。所与の記号に対するすべてのイベントが、同じソーティングエンジンモジュールにより処理されることが好ましいが、異なる記号に対するイベントが、異なるソーティングエンジンモジュールにより並列に処理されることがある。ディスパッチャモジュールは、当技術分野でよく知られている様々な技法を使用して、並列ソーティングエンジン全体で作業負荷のバランスを保つことがある。たとえば、本発明者らは、ソーティングエンジン全体への記号のランダムな分配が、平均でほぼ均等な負荷バランスを提供することを見いだした。ディスパッチャバッファモジュールがディスパッチャモジュールとソーティングエンジンの間に存在することに留意されたい。このバッファは、各ソーティングエンジンに対する保留イベントの別個の待ち行列を保持する。このバッファは、単一のソーティングエンジンが未処理のまま保留されたとき、行頭ブロッキングの確率を低減する。そのエンジンに対する保留イベントは、バッファに入れられるが、別のソーティングエンジンに対してスケジュールされたイベントは、関連するソーティングエンジンが準備できたときに処理されることがある。ソーティングエンジンは、修正挿入ソート、または上記で説明されたＢ＋木ソーティングデータ構造を利用することがある。好ましい実施形態では、Ｂ＋木ソーティングデータ構造が使用される。ソーティングエンジンは以下の責任がある：
ソートされたデータ構造から価格水準を挿入するおよび削除する
ソートされたリスト内のソートされた価格水準から注文を挿入するおよび削除する
価格水準の相対位置を識別する
注文の相対位置を識別する
ソーティングエンジンは、出力イベント内の相対的な価格および注文の位置を含む。たとえば、ソーティングエンジンは、データ構造により保持される様々なブック内部の注文および／または価格に対するソート位置を識別するデータフィールドを、ソーティングエンジンが処理する注文イベントに対して付加するように構成されることができる。したがって、ＳＶＵモジュールは、ＳＶＵモジュールが受け取る指値注文イベントをパイプラインにより保持される１つまたは複数のブックに対するソート位置情報でさらに強化することにより要約ビューを生成することができる。この位置情報はスカラ位置（たとえば第３の価格水準）の形式、または前の項目へのポインタ（たとえば前の価格水準へのポインタ）の形式でもよい。各ソーティングエンジンは関連するキャッシュ、作業ＦＩＦＯ、およびリフレッシュＦＩＦＯを有する。キャッシュは最近アクセスされたメモリブロックへの高速アクセスを提供し、そのことが、同じ注文ブックの最上部に対する連続動作に対する待ち時間性能を最適化する。各ソーティングエンジンは、ソーティングエンジンの作業ＦＩＦＯ内の処理中のフィールドおよび状態をソーティングすることにより多数のイベントに対して並列に動作することがある。ソーティングエンジンは、同じデータ構造ノードへのアクセスに対して監視することにより、正しさおよびデータ構造の一貫性を保証することに留意されたい。同様に、ソーティングエンジンは、リフレッシュイベントを増分的に処理して、ＯＮＰＡモジュールと同様にリフレッシュ待ち行列を利用することにより新しいクライアントの購読に役立てる。

【0167】

各ソーティングエンジンの出力はブレンダモジュールに渡され、ブレンダモジュールは、エクストラクタモジュールにより渡されるイベントフィールドとソーティングエンジンからの位置情報を混合することにより正規化された出力イベントを構築する。ブレンダは、保留イベントフィールドを記憶する待ち行列を各ソーティングエンジンに対して保持することに留意されたい。

【0168】

チッカ装置からのレベル２更新が、クライアントＡＰＩにより提示される１つまたは複数のブックビューの状態を更新する別個のイベントの形でクライアントアプリケーションに届けられることがある。要約ビューについては、ＡＰＩはＳＶＵモジュールに対するミラーデータ構造を保持することが好ましい。たとえば、ＳＶＵモジュールがＢ＋木を利用する場合、ＡＰＩはＢ＋木を保持することが好ましい。これにより、ＳＶＵモジュールは更新イベント内の親／子ポインタを含むことができるようになる。具体的には、ＳＶＵモジュールは所与のブックビューに対してＢ＋木内の各ノードに対してローカルに一意の識別子を割り当てる。ＳＶＵモジュールは更新イベントをこれらの識別子で強化して、データ構造内の影響を受けるノードに対する保守動作を指定する。たとえば、更新イベントは、所与の価格識別子が所与のノードに追加されることを指定することがある。これにより、ＡＰＩが直接アドレス指定を使用して所与のノードのデータ構造に対して一定時間の更新を行うことができるようになり、木探索動作の必要性を阻止する。

【0169】

チッカ装置からのレベル２更新はまた、クライアントアプリケーションにブックビューの最上部のＮ段階のスナップショットの形で届けられることがあり、ここで、Ｎは典型的には１０以下のオーダである。Ｎはチッカ装置または購読しているアプリケーションにより指定されることがある。ブックビューがＳＶＵモジュールによりそのままの状態で保持される場合、記憶されるデータ構造内の最初のＮ項目を読み出すだけでスナップショットが容易に生成される。Ｂ＋木が使用されるとき、スナップショットが単一のメモリ読み出しで生成されるような大きさにノードが作られることがある。ＳＶＵモジュールがブックビュー（たとえば複合ビューまたは属性がフィルタにかけられたビュー）を合成する場合、ＳＶＵは、合成されたビューでＮ項目を生成するために、基になるソートされたビューから十分な数の項目を読み出すことが好ましい。チッカ装置からのスナップショット送付は、指定されたブックビューを生成するためにＡＰＩによりクライアントシステム上で必要とされる処理の量を大きく低減する。ＡＰＩは単にスナップショットをメモリアレイの中にコピーし、クライアントアプリケーションにビューを提示する。

【0170】

別の実施形態によれば、パイプライン１２００は相場メッセージを生成するパイプラインの有望な能力を活用することができ、その後、その相場が取引所により公表されるレベル１フィードで出現する。図２９に示されるように、パイプライン１２００は、総合相場イベントをＳＶＵモジュールからレベル１トラフィックを処理する価値キャッシュ更新（ＶＣＵ）モジュール２９００に渡すように増強されることができる。図２９の実施形態では、ＳＶＵモジュールは、注文ブック更新イベントまたは価格ブック更新イベントがブックの最上部（最高の入札または申込み）をいつ修正するか（たとえば、新しい価格、量、またはタイムスタンプ）を検出するための論理回路を使って構成される。そのようなイベントの検出に応答して、ＳＶＵモジュールは関連する記号に対するブックの所与の地域ビューおよび／または複合ビューに対して、新しい買い呼値または売り呼値、およびその価格での集計注文量を含む総合相場イベントを生成する。ＶＣＵモジュール２９００はこの総合相場イベントを受け取り、記号に対する関連するレベル１レコードを含む最終価値キャッシュ（ＬＶＣ）データ構造を更新し、関心があり資格が与えられる購読者にレベル１相場メッセージを送信する。ＬＶＣデータ構造でのレコードは、市場での金融商品の現在の状態を表す。上記で示されたように、ＯＮＰＡモジュールおよびＳＶＵモジュールにより提供される極端に少ない待ち時間のために、ＳＶＵモジュールは、注文イベントがブックの最上部にいつ影響を及ぼすかを認識することができ、その後、その状況が取引所からの従来のレベル１フィードに反映されることが期待される。したがって、総合相場イベントを認識しＶＣＵモジュール２９００に届けることにより、本発明者らは、図２９のパイプライン１２００が、有利な小さな待ち時間でレベル２イベントのフィードからレベル１イベントを生成するように構成されることを確信する。

【0171】

ＶＣＵモジュール２９００に対する例示的実施形態が、上記で参照され組み込まれた、米国特許出願公開第２００８／０２４３６７５号明細書（たとえば、その明細書中の図１５ａおよび図１５ｂ参照）で説明されていることに留意すべきである。

【0172】

さらに別の例示的実施形態では、図２９のパイプライン１２００は、ＶＣＵモジュール２９００から下流のバスケット計算エンジン（ＢＣＥ）モジュール３０００を含むようにさらに構成されることができる。ＢＣＥモジュール３０００の例示的実施形態が、上記で参照され組み込まれた、米国特許出願公開第２００９／０１８２６８３号明細書で説明されている。ＢＣＥモジュール３０００は、少ない待ち時間のレベル２データからの金融商品のバスケットに対する純資産価値（ＮＡＶ）計算を効果的に駆動する総合相場イベントに起因するレベル１イベントに対して動作するように構成されることができる。本発明者らは、総合相場生成およびバスケット計算のこのチェーニングが、指数裁定を含むいくつかの売買戦略に対してかなりの速さの利点を提供することができることを確信している。

【0173】

パイプライン１２００の前述の実施形態は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、チップマルチプロセッサ（ＣＭＰ）、特定用途向け集積回路（ＡＳＩＣ）、グラフィックスプロセッシングユニット（ＧＰＵ）、およびマルチコアスーパスカラプロセッサを含む様々な並列処理技法で実現されることがある。さらに、そのようなパイプライン１２００は、図３１に示されるようにチッカ装置プラットフォーム３１００のコプロセッサ８４０上に導入されることがある。本明細書で開示されるパイプラインは、売買する企業内に存在するチッカ装置内だけでなく、取引所自体の注文ブックを生成し保持する取引所の能力を促進するために取引所自体内部に存在するチッカ装置内にも実装されることができることにも留意すべきである。そのようなチッカ装置プラットフォーム３１００に関する追加の詳細が、上記で参照され組み込まれた、米国特許出願公開第２００９／０１８２６８３号明細書および第２００８／０２４３６７５号明細書で得られることができる。要約すると、取引所からの金融市場データがプロセッサ８１２上のカーネル空間内で実行されるＯ／Ｓにより供給されるプロトコルスタック３１０２で受信される（図８ａから図８ｂ参照）。ｕｐｊｅｃｔドライバ３１０４が、プロセッサ８１２上のユーザ空間内で実行されるマルチスレッドのフィード前処理ソフトウェア３１１２にこの取引所データを届ける。次に、これらのスレッドは、カーネル空間内で実行されるハードウェアインタフェースドライバソフトウェア３１０６に、コプロセッサ８４０行きのデータを伝達することがある。

【0174】

クライアントアプリケーションからの命令も、コプロセッサ８４０上でインスタンス生成されるパイプライン１２００を適切に構成するようにコプロセッサ８４０に最終的に届けるために、ハードウェアインタフェースドライバ３１０６に伝達されることがある。そのような命令が、Ｏ／Ｓにより供給されるプロトコルスタック３１１０に到着し、プロトコルスタック３１１０からそのような命令が要求処理ソフトウェアモジュール３１１６に届けられる。その後、バックグラウンドおよび保守処理ソフトウェアモジュール３１１４が、クライアントアプリケーションがそのような命令を発行する適切な資格を有するかどうかを決定する。そのような資格がある場合、バックグラウンドおよび保守処理ブロック３１１４は、パイプライン１２００を適切に更新するコプロセッサに届けるためにコマンド命令をハードウェアインタフェースドライバ３１０６に伝達して、任意の適切な命令を反映させる。

【0175】

次に、ハードウェアインタフェースドライバ３１０６が、コプロセッサ８４０により消費するためにコプロセッサ８４０に金融市場データおよびコマンドのインタリーブされたストリームを届けることができる。このストリーム転送に関する詳細が、上記で参照され組み込まれた、米国特許出願公開第２００７／０１７４８４１号明細書で説明されている。コプロセッサ８４０からの出力データがハードウェアインタフェースドライバ３１０６に戻り、出力データは、ハードウェアインタフェースドライバ３１０６から（プロトコルスタック３１１０を介して）クライアント接続へ届けるために、および／またはバックグラウンドおよび保守処理ブロック３１１４に届けるために、ＭＤＣドライバ３１０８に供給されることができる。

【0176】

本発明が本発明の好ましい実施形態に関して上記で説明されたが、依然として本発明の範囲内に入る様々な修正が、好ましい実施形態に対して行われることがある。本発明に対するそのような修正は、本明細書の教示の検討によって認識できるであろう。したがって、本発明の完全な範囲は、添付の特許請求の範囲およびその法的均等物によってのみ規定されるべきである。

【図1】

【図2a】

【図2b】

【図3】

【図4a】

【図4b】

【図4c】

【図5】

【図6】

【図7】

【図8a】

【図8b】

【図9a】

【図9b】

【図10】

【図11a】

【図11b】

【図11c】

【図12a】

【図12b】

【図12c】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21a】

【図21b】

【図22】

【図23】

【図24】

【図25a】

【図25b】

【図25c】

【図25d】

【図26】

【図27】

【図28】

【図29】

【図30】

【図31】