JP2011510382A - 低遅延バスケット計算のための方法およびシステム - Google Patents

Abstract

バスケット計算エンジンがデータのストリームを受信し、かつそのデータに基づいてバスケット価値の計算を加速するために導入される。好ましい実施形態では、バスケット計算エンジンは金融市場データを処理して、金融商品バスケットの純資産価値（ＮＡＶ）を計算するために使用される。バスケット計算エンジンはコプロセッサ上に導入されることができ、パイプラインによって実現されることもでき、パイプラインはバスケット連関探索モジュール、およびバスケット価値更新モジュールを含むことが好ましい。コプロセッサは、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）などの再構成可能論理デバイスであることが好ましい。

Description

本発明は、ストリーミングデータに基づくバスケット計算業務を行う分野に関し、詳細にはストリーミング金融市場データに基づくバスケット計算業務を行う分野に関する。

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

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

金融市場データ：本明細書で使用される「金融市場データ」という用語は、金融商品を売買するための新しいオッファ、金融商品の販売完了の指示、以前に報告された金融商品の販売に対する訂正の通知、そのような取引に関連する管理メッセージなどを個々に表す一連のメッセージに含まれる、またはそれらから得られるデータを指す。

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

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

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

再構成可能論理回路：本明細書で使用される「再構成可能論理回路」という用語は、その形態および機能が製造後にフィールドで大幅に変更される（すなわち、再構成される）ことがある任意の論理回路技術を指す。これはＧＰＰとは対照的に、ＧＰＰの機能は製造後に変更することができるが、その形態は製造時点のままである。

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

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

コプロセッサ：本明細書で使用される「コプロセッサ」という用語は、主プロセッサを有する計算システム内の他の構成要素と協力して動作するように設計された計算エンジンを指す（主プロセッサ自体が、マルチコアプロセッサアーキテクチャなど、複数のプロセッサを含む場合がある）。一般に、コプロセッサは、特定の１組のタスクを実行するように最適化され、システム性能を最適化するために主プロセッサ（一般にＧＰＰである）からタスクを取り除くために使用される。コプロセッサにより実行されるタスクの範囲は、コプロセッサのアーキテクチャに応じて固定されることも、変更可能なこともある。固定されたコプロセッサアーキテクチャの例は、広範囲のタスクを実行するグラフィック処理装置、および比較的限られた１組のタスクを実行する浮動小数点数値コプロセッサを含む。再構成可能コプロセッサアーキテクチャの例は、広範囲な固定またはプログラム可能な計算エンジンを実装するように再構成されることがあるフィールドプログラマブルゲートアレイ（ＦＰＧＡ）などの再構成可能論理デバイスを含む。コプロセッサの機能は、ソフトウェアおよび／またはファームウェアにより定義されることがある。

ハードウェアアクセラレーション：本明細書で使用される「ハードウェアアクセラレーション」という用語は、主プロセッサから１つ以上の処理タスクを取り除くための、コプロセッサ上に実装されたソフトウェアおよび／またはファームウェアを使用して、主プロセッサに比べてこれらのタスクの処理遅延を低減することを指す。

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

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

売買および相場などの大量のイベントが常に起こっている取引日の間中の金融商品バスケットの価値を厳密に追跡する能力は、非常に困難な仕事である。金融商品バスケットの基になる金融商品のポートフォリオの一部となっている金融商品について行われるあらゆる売買が、そのバスケット価値に変化を引き起こす可能性がある。バスケット価値を計算するために使用される従来技術が、バスケット価値に影響を与える大量のイベントに遅れないようについていくことができず、それにより、従来技術では、現在の計算されたバスケット価値が、現在の市況ではなく、むしろ過去の数ミリ秒から数秒までの任意の時点に存在していた市況を反映しているために、市場の現在の状態に比べると、金融商品バスケット価値について不正確さを引き起こしていたと本明細書で本発明者は考える。

上述のように、金融商品バスケットは、標準インデックス、ＥＴＦ、ミューチュアルファンド、個人ポートフォリオなどを表すことがある。

インデックスが企業のグループのパフォーマンスを表す。ここで、グループは、時価総額（たとえば、Ｓ＆Ｐ５００）、工業（ダウジョーンズ工業平均株価（ＤＪＩＡ））などの様々な基準により決定されることができる。

ミューチュアルファンドは、専門的に管理された形の集合的投資であり、買い手が投資信託所有者に一定量の金銭を支払い、引き換えに投資信託の株式を受け取る。

ＥＴＦはミューチュアルファンドと非常に似ているが、ちょうど株式のように取引所で取引日の間中、売買されることができるという重要な違いがある。したがって、ＥＴＦの価格は、その基になるポートフォリオの変化によるだけでなく、ＥＴＦの株式自体に対する市場の供給と需要によっても変動する。したがって、ＥＴＦはミューチュアルファンドの多様性だけでなく株式の売買動力学も提供する。さらに、ＥＴＦは一般に、十分に確立した市場インデックスを追跡し、インデックスのリターンを再現しようとする。

個人ポートフォリオは、彼／彼女の個人投資目標について個人により定義される金融商品の集合体である。

金融商品バスケットは、基になる１組の金融商品により定義される。バスケットの定義はまた、バスケット内の金融商品ごとの加重を指定する。たとえば、Ｂで示される仮想バスケットについて考えてみる。バスケットＢは、記号Ｃ_ｉを有するＭ個の金融商品を含む。ここで、ｉ＝１、２、・・・、Ｍである。さらに、バスケット内の各金融商品ｉの加重が、ｗ_ｉにより示される。ここで、ｉ＝１、２、・・・、Ｍである。バスケットに関連付けられているのが、その純資産価値（ＮＡＶ）として知られるその金銭価値の尺度である。バスケットＢ内の各金融商品ｉのこの瞬間での価値がＴ_ｉ（ｉ＝１、２、・・・、Ｍ）と仮定すると、バスケットＢのＮＡＶが以下のように計算されることができる：

ここで、ｄはバスケットに関連付けられた除数であり、以下により詳細に説明される。したがって、式（１）は、バスケットのＮＡＶが、バスケット内の金融商品の価値の加重和であることを規定する。ここで、除数は正規化因子の働きをする。

Ｔの値は、金融商品の株式の価格を表す。価格は最終販売価格／最終売買価格（終値）、購入価格に対する最高のオファー（買い呼値）、販売価格に対する最高のオファー（売り呼値）、または売買に対する特定のオファー価格（指値注文）として表現されることができる。

ｗの値は、バスケットごとに別の仕方で定義されることができる。たとえば、時価総額加重インデックス（Ｓ＆Ｐ ５００など）では、金融商品の加重は、金商品の発行済み株式の数に「自由変動相場制」因子を乗算されたものとして定義されることができる。ここで、自由変動相場制因子は、０と１の間の数であり、金融商品の一定株式が公に売買に利用できないという事実を調整する。等加重インデックス（ＤＪＩＡなど）では、金融商品の加重は１に設定される。ＥＴＦおよび個人ポートフォリオでは、金融商品の加重は、バスケットの金融商品ごとに多くの株式を所有することが、そのＥＴＦまたは個人ポートフォリオの１株を所有することに等しいという事実を反映する指定された数値に等しく設定されることができる。したがって、バスケットＢの１つの株式を所有するためには、金融商品Ｃ_１のｗ_１株式、金融商品Ｃ_２のｗ_２株式など金融商品Ｃ_Ｍのｗ_Ｍ株式までを購入しなければならない。

ｄの値はまた、バスケットごとに別の仕方で定義されることができる。インデックスについては、除数は現在のインデックス除数に設定されることができる、この除数は、インデックス（たとえば、Ｓ＆Ｐ ５００については５００）での金融商品の数、または何らかの他の指定された数値とすることができる。ＥＴＦについては、除数は取引日の間に変化する可能性がある（除数はまたインデックスに対しても変化する可能性があるため）。

上記に示されるように、バスケットの基になる金融商品の１つの価値に変化があるときはいつも、そのバスケットに対するＮＡＶは、式（１）に従って計算されるべきである。しかしながら、取引所からの金融市場データメッセージが、高速でチッカ装置（ｔｉｃｋｅｒ ｐｌａｎｔ）などのプラットフォームに流れ込む。たとえば、オプション価格報告機関（ｏｐｔｉｏｎｓ ｐｒｉｃｅ ｒｅｐｏｒｔｉｎｇ ａｕｔｈｏｒｉｔｙ、ＯＰＲＡ）は、２００８年１月のこのメッセージ速度をほぼ８００，０００メッセージ／秒となると予想する。これらのメッセージはそれぞれ、潜在的に複数のＮＡＶ再計算を引き起こすことがある。さらに、同じ金融商品が複数のバスケットの構成要素となっていることがあるので、すべての金融市場データメッセージについてバスケットＮＡＶ値を追跡するためには、毎秒行われる必要があるＮＡＶ計算の数は、少なくとも１、０００万ＮＡＶ計算／秒のオーダになると本明細書で本発明者は見積もる。一度に１つの更新（システムが行う必要があり得る、バスケット計算に関連のない他のタスクを含む）だけを行わなければならない従来の解決策は、その順次的性質のためにこのような高い更新速度に遅れないようについていくことができないと本明細書で本発明者は考える。

金融トレーダが非常に高速にバスケットＮＡＶを計算することができることが非常に望ましいので、この欠点は問題である。一例がこの望ましさを実証する。上記で説明されたように、ＥＴＦは取引所で通常の株式のように売買されることができるバスケットである。ＥＴＦのポートフォリオは、取引日の始めに定義され、まれな出来事を除いては取引日の間中、固定されたままである。ＥＴＦの株式は、取引日の間中、以下のように動作する生成過程により生成されることができる。買い手が投資信託の所有者に、ＥＴＦを構成する金融商品の指定されたポートフォリオ、およびこれらの金融商品に対する配当支払いに等しい量の現金支払い（および、場合によっては取引手数料）を与える。次に、投資信託は買い手にＥＴＦの株式を発行する。ＥＴＦの株式はまた、同様の方法で基になる金融商品として償還されることができる。したがって、投資家は、投資信託所有者にＥＴＦの株式（および、場合によっては取引手数料としていくらかの現金）を与え、代わりに、投資家は、ＥＴＦを構成する金融商品のポートフォリオ、およびこれらの金融商品に対する配当支払いに等しい現金を受け取る。

取引日の間、ＥＴＦの株式の価格は、供給と需要に従って変動し、ＥＴＦのＮＡＶは、ＥＴＦのポートフォリオ内の金融商品の供給と需要に従って変化する。取引日の間に、ＥＴＦの売買価格がそのＮＡＶから外れることは、十分起こり得る。ＥＴＦの価格がＮＡＶよりも高い場合、ＥＴＦは「額面以上で」売買していると言われる。ＥＴＦの価格がＮＡＶよりも低い場合、ＥＴＦは「額面価格を割って」売買していると言われる。金融トレーダがＥＴＦ株式価格とＥＴＦ ＮＡＶの相違を検出すると、彼／彼女はその相違を利用して、裁定取引を介して利益を得ることができる。

１つのシナリオでは、Ｔ_ＥＴＦで示されるＥＴＦ株式価格が、ＥＴＦのＮＡＶより高いと仮定する。この場合、トレーダが以下のステップを実行することができる：
ＥＴＦのポートフォリオ内の金融商品の株式をＮＡＶにほぼ等しい総額で購入することによりバスケットを整理（ａｓｓｅｍｂｌｅ）する、
整理されたバスケットを投資信託所有者と交換することによりＥＴＦ株式を生成する、
Ｔ_ＥＦＴにほぼ等しい価格でＥＴＦを取引所で売る。

Ｔ_ＥＴＦとＮＡＶとの差が、取引手数料、および他の現金支払いを十分埋め合わせるほど大きい場合、トレーダは、これらの行為により利益を得ることができる。さらに、この利益はリスクのない裁定取引により実現される（これらのステップは即座に行われることができると仮定する）。

別のシナリオでは、Ｔ_ＥＴＦで示されるＥＴＦ株式価格が、ＥＴＦのＮＡＶより低いと仮定する。この場合、トレーダがＥＴＦ株式を購入し、それをポートフォリオ内の金融商品の株式に償還し、これらの金融商品株式を取引所で売ることができる。ここも、Ｔ_ＥＦＴとＮＡＶとの差が、取引手数料、および他の現金支払いを十分埋め合わせるほど大きい場合、トレーダは、実質的にリスクなしに利益を得ることができる。

ＥＴＦについてこのようなリスクのない裁定取引により利益を得る際の重要な要素は、ＥＴＦの株式価格とＥＴＦのＮＡＶとの差を検出することである。そのような相違を検出する最初のトレーダが、最大の利益を得る立場にあり、ＮＡＶ計算の遅延が重要になる。利益獲得機会の検出に向けた競争で競争相手に勝つためには、ＮＡＶ計算はできるだけ素早く行われるべきである。

上記で説明されたＥＴＦシナリオとは別に、バスケットＮＡＶ計算のもう１つの有用性が、バスケットのポートフォリオがどうなっているかの尺度をＮＡＶが提供することである。着実に上昇するＮＡＶが、そのようなバスケットにさらに投資することが利益になることがあることを示す。一方、下落するＮＡＶが、損失を避けるためにバスケットのポートフォリオを売ることが望ましいことがあることを示す。この戦略は、金融商品のポートフォリオ全体の多様化により、リスクを軽減することにより利益を提供するバスケットを有する特定の金融商品の株式を売買する場合に採用される戦略と似ている（すなわち、全体としてバスケットに上昇するＮＡＶがある場合、そのバスケットへの投資は、バスケット内の特定の金融商品のいずれかが如何に利益を生んでいるかとは望ましくは切り離される）。

当該技術分野における大容量低遅延バスケット価値計算に必要なことを満足させる取り組みにおいて、本明細書で本発明者は、高速データストリーム内のデータに基づいて、そのデータがプロセッサを通って流れるときに、１組のバスケットに対するバスケット価値を計算する手法を開示する。

本発明の好ましい実施形態の一様態によれば、本発明者は、コプロセッサがバスケット計算を行うために使用されるバスケット価値計算手法を開示する。バスケット計算の計算負荷をコプロセッサに肩代わりさせることにより、システムの主プロセッサが解放されて、別のタスクを実行することができる。コプロセッサハードウェアが、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）などの再構成可能論理回路を使用してバスケット計算を加速することが好ましい。そうする際に、好ましい実施形態が以下の特許および特許出願に開示された、基になるハードウェアアクセラレート技術を利用することが好ましい。これらは、「Ａｓｓｏｃｉａｔｅｄ Ｄａｔａｂａｓｅ Ｓｃａｎｎｉｎｇ ａｎｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｔｒｉｅｖａｌ」と題する米国特許第６，７１１，５５８号明細書、「Ａｓｓｏｃｉａｔｉｖｅ Ｄａｔａｂａｓｅ Ｓｃａｎｎｉｎｇ ａｎｄ Ｉｎｆｏｒｍａｔｉｏｎ Ｒｅｔｒｉｅｖａｌ ｕｓｉｎｇ ＦＰＧＡ Ｄｅｖｉｃｅｓ」と題する米国特許第７，１３９，７４３号明細書、「Ｉｎｔｅｌｌｉｇｅｎｔ Ｄａｔａ Ｓｔｏｒａｇｅ ａｎｄ Ｐｒｏｃｅｓｓｉｎｇ Ｕｓｉｎｇ ＦＰＧＡ Ｄｅｖｉｃｅｓ」と題する米国特許出願公開第２００６／０２９４０５９号明細書、「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｐｅｒｆｏｒｍｉｎｇ Ｂｉｏｓｅｑｕｅｎｃｅ Ｓｉｍｉｌａｒｉｔｙ Ｓｅａｒｃｈｉｎｇ」と題する米国特許出願公開第２００７／００６７１０８号明細書、「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｐｒｏｔｅｉｎ Ｓｅｑｕｅｎｃｅ Ａｌｉｇｎｍｅｎｔ Ｕｓｉｎｇ ＦＰＧＡ Ｄｅｖｉｃｅｓ」と題する米国特許出願公開第２００８／００８６２７４号明細書（２００７年８月１０日に提出され、米国出願通し番号１１／８３６，９４７号により公開された）、「Ｍｅｔｈｏｄ ａｎｄ Ｄｅｖｉｃｅ ｆｏｒ Ｈｉｇｈ Ｐｅｒｆｏｒｍａｎｃｅ Ｒｅｇｕｌａｒ Ｅｘｐｒｅｓｓｉｏｎ Ｐａｔｔｅｒｎ Ｍａｔｃｈｉｎｇ」と題する米国特許出願公開第２００７／０１３０１４０号明細書、「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ａｐｐｒｏｘｉｍａｔｅ Ｐａｔｔｅｒｎ Ｍａｔｃｈｉｎｇ」と題する米国特許出願公開２００７／０２６０６０２号明細書、「Ｆｉｒｍｗａｒｅ Ｓｏｃｋｅｔ Ｍｏｄｕｌｅ ｆｏｒ ＦＰＧＡ−Ｂａｓｅｄ Ｐｉｐｅｌｉｎｅ Ｐｒｏｃｅｓｓｉｎｇ」と題する米国特許出願公開第２００７／０１７４８４１号明細書、「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｈｉｇｈ Ｔｈｒｏｕｇｈｐｕｔ Ｂｌｏｃｋｗｉｓｅ Ｉｎｄｅｐｅｎｄｅｎｔ Ｅｎｃｒｙｐｔｉｏｎ／Ｄｅｃｒｙｐｔｉｏｎ」と題する米国特許出願公開第２００７／０２３７３２７号明細書、「Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｈｉｇｈ Ｓｐｅｅｄ Ｏｐｔｉｏｎｓ Ｐｒｉｃｉｎｇ」と題する米国特許出願公開第２００７／０２９４１５７号、および２００７年６月１９日に出願された「Ｈｉｇｈ Ｓｐｅｅｄ Ｐｒｏｃｅｓｓｉｎｇ ｏｆ Ｆｉｎａｎｃｉａｌ Ｉｎｆｏｒｍａｔｉｏｎ Ｕｓｉｎｇ ＦＰＧＡ Ｄｅｖｉｃｅｓ」と題する係属中の米国出願通し番号１１／７６５，３０６号であり、それぞれの開示全体が本明細書に参照により組み込まれる。

本発明の好ましい実施形態の別の様態によれば、本発明者は、そのようなバスケット計算に含まれる異なるタスクがパイプライン内の異なるモジュールに任せられることができることを開示する。たとえば、あるパイプラインモジュールが、ストリーム内の現在のデータイベントによりどのバスケットが影響を及ぼされるかを決定するように構成されることができる。別のパイプラインモジュールが、影響を及ぼされるバスケットに関する情報を受信し、かつこれらの影響を及ぼされるバスケットごとの新しいバスケット価値を示すデータを計算するように構成されることができる。これらのモジュールを一緒にパイプライン化することにより、２つのモジュールは、異なるメッセージおよび／またはバスケットを互いに並列に同時に処理することができる。

好ましい実施形態では、このパイプラインは、バスケット価値更新モジュールと通信するバスケット連関（ａｓｓｏｃｉａｔｉｏｎ）探索モジュールを含む。バスケット連関探索モジュールは、各データメッセージによりどのバスケットが影響を及ぼされるかを決定するように構成され、一方、バスケット価値更新モジュールは、データメッセージ内の情報に基づいて影響を及ぼされるバスケットごとに少なくとも１つの新しい価値を計算するように構成される（たとえば、金融市場データを処理する一実施形態では、この情報は、金融市場データメッセージ内の金融商品価格情報とすることができる）。

バスケット価値更新モジュールは、より詳細に以下に説明されるように、更新されるバスケット価値の計算に差分計算手法を利用することが好ましい。そのような手法を用いると、金融商品など、どれだけ多くの要素が所与のバスケットの構成要素であるかに関係なく、各バスケット価値を計算するのに必要な算術演算の数は変わらない。さらに、バスケット価値更新モジュールは、任意選択で、並列計算論理回路を使用して、同じバスケットに対する複数の異なる種別のバスケット価値を同時に計算するように構成されることがある。

バスケット連関探索モジュールは、バスケット価値計算のためにバスケット価値更新モジュールにより必要とされるデータの少なくとも一部を記憶するバスケットセット表にアクセスすることが好ましい。金融情報に関係する好ましい実施形態では、このデータは、金融商品に関係する新しいメッセージが受信されたときに、バスケット計算に必要とされる適切なデータが取り出されることができるように、金融商品により表内で間接的にインデックスされることができる。間接処理を提供するために、金融商品によりバスケットセット表内へのポインタをインデックスする第２の表が利用される。

さらに、パイプラインが再構成可能論理デバイスなどのコプロセッサ上に導入されたファームウェアパイプラインを含む一実施形態では、これらのモジュールの設計は、コプロセッサのハードウェア能力に適応されることができ、それにより、データストリームがラインの速度で処理されることができ、一方で主プロセッサが依然として他のタスクを自由に行うことができるように、バスケット計算を能率的にするというある水準の相乗効果を提供する。

本発明者はまた、パイプラインは、バスケット価値更新モジュールの下流の価格イベントトリガモジュールを利用することができることに注目する。価格イベントトリガモジュールは、更新されたバスケット価値のうち顧客により指定されたトリガ条件を満たすものがあるかどうかを決定するように構成されることができる。次に、顧客により指定されたトリガ条件を満たすどんな更新されたバスケット価値も、関係がある顧客（たとえば、特定のトレーダ、特定のアプリケーションなど）宛に転送されることができる。そうすることにより、顧客はバスケット計算パイプラインの低遅延の性質を利用して、間に合うことがある売買機会を知ることができる。

さらに、パイプラインは、価格イベントトリガモジュールの下流のイベント発生器モジュールを利用することができる。イベント発生器モジュールの役割は、価格イベントトリガモジュールにより誘発されるトリガに応答して、顧客に引き渡すためのメッセージイベントを生成することである。このメッセージイベントは、更新されたバスケット価値を含むことが好ましい。

その上さらに、バスケット連関探索モジュール（および、パイプライン内のその下流モジュール）により処理される金融市場データメッセージの量を制限するために、パイプラインは、バスケット連関探索モジュールの上流のメッセージ修飾子フィルタモジュールを利用することができる。メッセージ修飾子フィルタモジュールは、バスケット計算に関係しないメッセージを金融市場データメッセージストリームから捨てるように構成されることが好ましい。

本明細書に記載されたようなパイプラインは、本発明の一実施形態で使用されて、金融商品バスケット、および現在の市場の状況に関連して裁定取引条件（上記で論じられたＥＴＦ裁定取引シナリオなど）が発生するときに、それを特定することができる。低遅延バスケット計算パイプラインを介してこれらの裁定取引条件を即座に検出することにより、トレーダが、検出された裁定取引条件を利用する売買を１つ以上の取引所で行うことができるようになる。

以下の説明および図面を検討すれば、本発明のこれらおよび他の特徴および利点が、当業者には明らかである。

ハードウェアアクセラレートされたバスケット計算が行われることができるシステムの例示的実施形態を示す図である。 ハードウェアアクセラレートされたバスケット計算が行われることができるシステムの例示的実施形態を示す図である。 コプロセッサ１４０として使用するための例示的プリント回路基板を示す図である。 コプロセッサ１４０として使用するための例示的プリント回路基板を示す図である。 複数の再構成可能論理デバイスにわたりファームウェアパイプラインがどのように導入されることができるかの例を示す図である。 バスケット計算を行うためにコプロセッサがどのように使用されることができるかの高い階層の構成図である。 差分計算手法を使用して更新されたバスケット価格を計算するための例示的処理フローを示す図である。 本発明の一実施形態による例示的バスケット計算エンジンパイプラインを示す図である。 例示的バスケット連関探索モジュールを示す図である。 例示的バスケットセットポインタ表を示す図である。 例示的バスケットセット表を示す図である。 例示的バスケット価値更新モジュールを示す図である。 バスケット価値更新モジュール内のＮＡＶ計算論理回路の例示的実施形態を示す図である。 バスケット価値更新モジュール内のＮＡＶ計算論理回路の例示的実施形態を示す図である。 バスケット価値更新モジュール内のＮＡＶ計算論理回路の例示的実施形態を示す図である。 複数のＮＡＶ更新エンジンを利用するバスケット価値更新モジュールの例示的実施形態を示す図である。 本発明の別の実施形態による例示的バスケット計算エンジンパイプラインを示す図である。 例示的価格イベントトリガモジュールを示す図である。 価格イベントトリガモジュール内のＮＡＶ−トリガ比較論理回路の例示的実施形態を示す図である。 複数の顧客特有価格イベントトリガモジュールを利用する価格イベントトリガモジュールの例示的実施形態を示す図である。 本発明の別の実施形態による例示的バスケット計算エンジンパイプラインを示す図である。 例示的イベント発生器モジュールを示す図である。 本発明のさらに別の実施形態による例示的バスケット計算エンジンパイプラインを示す図である。 例示的メッセージ修飾子フィルタモジュールを示す図である。 本発明のさらに別の実施形態による例示的バスケット計算エンジンパイプラインを示す図である。 バスケット計算エンジンパイプラインが利用されることができる例示的チッカ装置アーキテクチャを示す図である。

図１ａは高速バスケット計算を行うように構成されるシステム１００の例示的実施形態を示す。システム１００は、コプロセッサ１４０によるハードウェアアクセラレートされたデータ処理能力を利用して、バスケット計算を行うことが好ましい。システム１００内には、コプロセッサ１４０が、（ネットワークインタフェース１１０を介して）ネットワーク１２０からシステム１００に流れ込むデータを受信するように配置される。好ましい実施形態では、システム１００は、金融商品データを受信し、かつ金融商品バスケットに対するバスケット計算を行うように利用される。したがって、ネットワーク１２０は、システム１００が、取引所自体（たとえば、ＮＹＳＥ、ＮＡＳＤＡＱなど）、またはサードパーティの提供業者（たとえば、ＳａｖｖｉｓまたはＢＴ Ｒａｄｉａｎｓなどのエクストラネット提供業者）などの金融データの情報源にアクセスすることができるネットワークを含むことが好ましい。そのような入力データは、金融商品に関連する売買および相場などのイベントを表すメッセージである一連の金融市場データメッセージを含むことが好ましい。これらのメッセージは、当該技術分野で知られているいくつかの形式のうちどれでも存在することができる。

プロセッサ１１２およびＲＡＭ１０８により定義されるコンピュータシステムは、当業者により理解されるどんな商品のコンピュータシステムでもよい。たとえば、コンピュータシステムはＩｎｔｅｌのＸｅｏｎシステムでも、ＡＭＤのＯｐｔｅｒｏｎシステムでもよい。したがって、プロセッサ１１２は、システム１００の中央プロセッサまたは主プロセッサの役を果たすが、ＧＰＰを含むことが好ましい。

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

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

ＦＡＭにより行われる特定のデータ処理操作は、ＦＡＭがファームウェアソケットモジュール１０４から受信するコマンドデータにより制御／パラメータ化される。このコマンドデータは、ＦＡＭに特有なものとすることができ、コマンドを受信すると同時に、ＦＡＭは受信されたコマンドにより制御されるデータ処理操作を実行するように自分を配列する。たとえば、データと鍵との間の完全一致操作を行うように構成されたＦＡＭ内で、ＦＡＭの完全一致操作は、完全一致操作が行われる鍵を定義するようにパラメータ化されることができる。この方法では、完全一致操作を行うように構成されたＦＡＭが、そのＦＡＭ内の１つ以上の異なる鍵に新しいパラメータをただロードすることにより、異なる完全一致操作を行うように容易に再配列されることができる。バスケットに関係する別の例として、１つ以上の金融商品をバスケットに追加する／そこから削除するバスケット計算エンジンを構成する１つ以上のＦＡＭにコマンドが発行されることができる。

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

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

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

具体的にはファームウェアソケットモジュールに入る、およびそこから出るデータフローに関連する、システム１００により使用されるソフトウェアおよびハードウェア／ソフトウェアインタフェースの性質は、上記で参照され組み込まれた米国特許出願公開第２００７／０１７４８４１号明細書でより詳細に記載されている。

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

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

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

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

図４ａは、新しい金融商品価格

の入力ストリームを受信し、受信されたストリームに応答してバスケット計算エンジン４００を使用して新しいバスケット価値ＮＡＶ^ｎｅｗを計算するコプロセッサ１４０を高い階層で示す。バスケット計算をコプロセッサ１４０に肩代わりさせることにより、システム１００は、新しい金融商品価格に応答して新しいバスケット価値を計算する遅延を大きく低減させることができる。

バスケット計算エンジン（ＢＣＥ）４００は、このエンジンによるＮＡＶ^ｎｅｗの計算結果を式（１）から導出することが好ましい。ＢＣＥ４００により式（１）を直接実行することは、Ｍ回の乗算、Ｍ−１回の加算、および１回の除算を含む。本発明の実行者は、式（１）のそのような直接使用をＢＣＥ４００内に実装することを選択することもあるが、ＢＣＥ４００の好ましい実施形態が、式（１）の関数を実現するために行われる必要のある算術演算の回数を低減する。バスケットに対するＮＡＶが更新されることになる根拠が、バスケットの基になる金融商品のうちの１つに対する新しい価格であることを考慮すると、バスケットのＮＡＶへの新しい金融商品価格と古い金融商品価格との差の寄与を計算すれば十分である。次に、この計算された寄与は、バスケットに対する古いＮＡＶ値に加算されて、更新されたＮＡＶ値を得ることができる。この処理は、本明細書ではＮＡＶに対する「差分計算」と呼ばれる。この差分計算手法についての根拠が以下に示され、式（１）から始まる。

ＮＡＶ^ｎｅｗ＝ＮＡＶ^ｏｌｄ＋Δｊ （２）
したがって、ＮＡＶ^ｎｅｗは、古いＮＡＶ価格ＮＡＶ^ｏｌｄとΔｊの和として計算されることができると理解されることができる。ここで、Δｊは、ＮＡＶへの新しい金融商品価格の差分寄与を表し、Δｊは以下の式で計算される：

したがって、差分計算手法は、新しいバスケット価値を計算するのに必要な計算回数を、Ｍ回の乗算、Ｍ−１回の加算、および１回の除算から、１回の減算、１回の乗算、１回の除算、および１回の加算だけに低減することができると理解されることができる。単一のバスケットが任意の数の金融商品を含むことがあるので、この低減が、計算効率の効果的な改善につながる可能性がある。バスケットの中には、Ｍの値がかなり大きいものがあることは留意されるべきである。たとえば、ほぼ６，３００の有価証券を含むインデックスであるＷｉｌｓｈｉｒｅ ５０００株式インデックスを計算するためにバスケットが使用されることがある。しかしながら、Ｗｉｌｓｈｉｒｅ ５０００株式インデックス内にそのような多数の有価証券が存在しても、そのようなバスケットのＮＡＶ計算は上記の式（２）に基づくので、差分計算手法を利用するＢＣＥ４００の計算遅延を増加させることにはならない。

図４ｂは、ＢＣＥ４００による、更新されたバスケット価値の計算の高い階層の処理フローを示す。ステップ４０２では、ＢＣＥが、バスケット価値への新しい金融商品価格

の差分寄与Δｊを計算する（式（３）を参照のこと）。ステップ４０４では、ＢＣＥが、計算された差分寄与から、更新されたバスケット価値ＮＡＶ^ｎｅｗを計算する（式（２）を参照のこと）。

図５は、ＢＣＥ４００を実現するための好ましいパイプライン５００を示す。パイプライン５００は、再構成可能論理デバイス１０２上にファームウェアパイプライン１５０として導入されることが好ましい。パイプライン５００は、バスケット連関探索モジュール５０２、および下流のバスケット価値更新モジュール５０４を含むことが好ましい。バスケット連関探索モジュール５０２は、金融市場データメッセージのストリームを受信し、各メッセージは、単一金融商品の買い呼値、売り呼値、および／または終値の変化を表す。各メッセージは、少なくとも記号識別子、広域取引所識別子、ならびに記号識別子に対応する金融商品に対する１つ以上の終値、買い呼値、および売り呼値を含むことが好ましい。記号識別子（または記号ＩＤ）は、特定の金融商品を一意に識別する２進数タグを含むことが好ましい。広域取引所識別子（ＧＥＩＤ）は、メッセージが関連する特定の取引所を一意に識別する２進数タグを含むことが好ましい。メッセージ内のデータタグは、メッセージ内の価格情報が金融商品に対する買い呼値／売り呼値／終値に関係するかどうか特定することが好ましい。また、メッセージフィールドは、メッセージがバスケット連関探索モジュール５０２に到着する時点以前に、異なるメッセージ源の間でそのように正規化されることが好ましい。

バスケット連関探索（ＢＡＬ）モジュール５０２は、入力メッセージごとに、そのメッセージの対象である金融商品を含む１組のバスケットを決定するように構成される。このバスケットセットは、複数のＱ個のバスケットを含むことがある（だが、バスケットセットの中にただ１つのバスケットしか存在しない可能性があることは留意されるべきである）。したがって、金融市場データメッセージごとにバスケット価値を追跡するという大量で厄介な性質は、各メッセージが少なくともＱ個のバスケット価値計算を必要とする（１：Ｑの増大）と理解されることができる。例示的実施形態では、Ｑの最大値は、１，０２４バスケットとなることがある。しかしながら、他の値が容易に使用されることがある。

図６は、例示的ＢＡＬモジュール５０２を示す。システム１００はあらゆる知られている金融商品のレコードを維持することが好ましく、各レコードは、その金融商品、リスト上の各バスケット内の金融商品の相対加重、ならびに金融商品に対する最新の買い呼値、売り呼値、および最終販売価格を含む、バスケットのリストを含むことが好ましい。これらのレコードは、バスケットセット表６０８に記憶されることが好ましい。システム１００はまた、バスケットセットポインタ表６０４を維持することが好ましい。表６０４は、バスケットセット表６０８内の該当するレコードの位置を示す１組のポインタおよび他の情報を含むことが好ましい。バスケットセット表６０８と組み合わせてバスケットセットポインタ表６０４を使用することにより、バスケットセット表６０８の内容を管理する融通性をより高めることが可能になる。図２ａおよび図２ｂに示されるような、コプロセッサがメモリ２０２を利用する一実施形態では、このメモリ２０２がＳＲＡＭメモリデバイスおよびＳＤＲＡＭメモリデバイスを含むことがある。バスケットセットポインタ表６０４はＳＲＡＭメモリデバイス内に記憶されることができ、一方、バスケットセット表６０８はＳＤＲＡＭメモリデバイス内に記憶されることができることが好ましい。しかしながら、１つ以上のＦＰＧＡチップが使用されるコプロセッサの一実施形態については、十分なメモリが利用できるならば、表６０４および６０８のいずれか、または両方が、利用できるオンチップメモリ内に記憶されることができることにも留意されるべきである。さらに、表６０４および６０８は、システム１００内、またはそれと通信できる他のメモリデバイスに記憶されることができる。

動作については、ＢＡＬモジュール５０２が、メッセージごとの記号ＩＤおよびＧＥＩＤ６００を使用して、バスケットセットポインタ表６０４での探索を行う。記号ＩＤおよびＧＥＩＤ６００に基づいて、バスケットセットポインタ６０６が表６０４から取り出され、ＢＡＬモジュール５０２がこのバスケットセットポインタ６０６を使用して、バスケットセット表６０８での探索を行う。バスケットセット表６０８での探索は、記号ＩＤにより特定される金融商品に対するバスケットセット６１０を特定し、かつその金融商品に対する記憶された終値／買い呼値／売り呼値６１２を特定するように動作することが好ましい。各バスケットセットは、その金融商品が構成要素となっている１つ以上のバスケットに対する識別子を含む。

図６に示されるように、減算器６１６が、現在のメッセージに含まれる新しい終値／買い呼値／売り呼値６０２から、取り出された終値／買い呼値／売り呼値６１２を減算して、それにより終値／買い呼値／売り呼値６１４の変化を計算するように動作することが好ましい。各メッセージは、対象の金融商品に対する１つ以上の価格フィールドを含むことがあることは留意されるべきである。メッセージ内に含まれないどの価格フィールドについても、結果として得られる価格変化はゼロとして取り扱われることが好ましい。したがって、メッセージが金融商品に対する最終販売価格を含まない場合、Δ終値はゼロとなる。

図７はバスケットセットポインタ表６０４の例示的実施形態をより詳細に示す。表６０４は複数のレコード７００を含み、各レコードは、１組のフラグ７０２に対応するビット列、ヘッダブロックポインタ７０４に対応するビット列、および異なるＧＥＩＤ７０６に対応する複数のビット列を含む。各レコード７００は、ＢＡＬモジュール５０２が現在のメッセージの記号ＩＤに対応する表６０４からレコード７００を取り出すことができるように記号ＩＤにより指示される。フラグ７０２は、レコード７００が有効であるかどうか（すなわち、対象の金融商品が少なくとも１つのバスケット内に含まれるかどうか）を示す。ヘッダブロックポインタ７０４は、記号ＩＤに対応する金融商品に対する、表６０８内のバスケット連関レコードへのポインタの役割を果たす。

また、所与の金融商品が複数の金融取引所で代替可能なことがある。所与の取引所（たとえば、ＮＹＳＥ）での金融商品の状態は、金融商品に対する地域見込みとして参照される。すべての取引所にわたるその金融商品の集計した状態は、その金融商品に対する複合見込みとして参照される。終値に対する複合価値は、任意の取引所での金融商品の最新販売価格であることが好ましい。買い呼値に対する複合価値は、その金融商品が売買される取引所のすべてにわたる、金融商品に対する買い呼値のうちの最高価格であることが好ましい。売り呼値に対する複合見込みは、その金融商品が売買される取引所のすべてにわたる、金融商品に対する売り呼値のうちの最高価格であることが好ましい。したがって、複合見込みにおける買い呼値および売り呼値は、一般に最高ビッドおよびオッファ（Ｂｅｓｔ Ｂｉｄ ａｎｄ Ｏｆｆｅｒ、ＢＢＯ）価格として参照される。表６０４および６０８により、バスケットが金融商品の地域見込みおよび／または複合見込みで定義されることができるようになる。たとえば、バスケットＡが、最大時価総額を有する１０の技術関連株の複合見込みを含むことがある。バスケットＢが、最大時価総額を有する１０の技術関連株のＮＹＳＥ地域見込みを含むことがある。バスケットＣが、１０の技術関連株に対する複合見込み、および１０の工業株に対するＮＹＳＥ地域見込みを含むことがある。

そのような融通性のあるバスケット定義に対応するためには、表６０４は、各レコード７００内の複数のＧＥＩＤフィールド７０６を利用することが好ましい。各ＧＥＩＤフィールド７０６は、関係する金融商品に対する該当する複合バスケット連関レコードおよび／または地域バスケット連関レコードを取り出すための表６０８へのインデックスの役割をさらに果たす。したがって、ＢＡＬモジュール５０２は、現在のメッセージのＧＥＩＤを使用して、レコード７００内の一致するＧＥＩＤフィールド７０６を特定する。ＧＥＩＤ_０に対応するフィールド７０６_０は、金融商品に対する複合見込みに対応する、表６０８内のどんなバスケット連関レコードも特定するために使用されることが好ましい。他のフィールド７０６は、金融商品に対する地域特有見込みに対応する、表６０８内のどんなバスケット連関レコードでも特定するために使用される。たとえば、ＧＥＩＤ_１が金融商品に対するＮＹＳＥ見込みに対応することがある一方で、ＧＥＩＤ_ｍが金融商品に対するＮＡＳＤＡＱ見込みに対応することがある。次に、一致するＧＥＩＤフィールド７０６が表６０８への追加のインデックスとして使用されて、金融商品の複合見込みと地域見込み両方に適用可能な、金融商品に対する１組のバスケット連関レコードを取り出す。

ＢＡＬモジュール５０２は、所与の金融商品に適用可能な複合ＧＥＩＤ_０フィールドを常に取り出すことが好ましい。さらに、金融商品に関する地域価格情報を有するメッセージについては、ＢＡＬモジュール５０２はまた、メッセージ内のＧＥＩＤフィールドと、その金融商品に対するレコード７００内のＧＥＩＤフィールド７０６を照合するように動作する。したがって、ＢＡＬモジュール５０２により使用されるバスケットセットポインタ６０６は、ヘッダブロックポインタ７０４、複合ＧＥＩＤインデックス７０６_０、および対象のメッセージに対する地域ＧＥＩＤインデックス７０６_１を含むことが好ましい。

図８は、バスケットセット表６０８の例示的実施形態をより詳細に示す。表６０８は、複数のバスケット連関レコードを含み、各レコードは、異なる金融商品に対するバスケット情報を含む。各レコードは、複数のヘッダブロック８００、および場合によっては１つ以上の拡張ブロック８２２を含むことが好ましい。各ヘッダブロック８００は、固定サイズであることが好ましいが、対象の金融商品および特定のＧＥＩＤに対応する。さらに、各ヘッダブロック８００は、そのブロックに対するＧＥＩＤフィールド８０２に対応するビット列、拡張ポインタ８０４に対応するビット列、カウントフィールド８０６に対応するビット列、１組の予約ビット８０８、対象の金融商品に対する最も新しく記憶された買い呼値８１０に対応するビット列、対象の金融商品に対する最も新しく記憶された売り呼値８１２に対応するビット列、対象の金融商品に対する最も新しく記憶された終値８１４に対応するビット列、および複数組のバスケット情報８１６に対応する複数のビット列を含むことが好ましい。

各ブロック８００は、対象の金融商品に対する複合バスケット連関情報または地域バスケット連関情報を含むことが好ましい。また、ブロック８００は、所与の金融商品に対する複合ブロックおよび地域ブロックが、連続したメモリアドレスに記憶されるようにメモリに配置されることが好ましい。この方法では、ヘッダブロックポインタ７０４は、金融商品の複合ブロック８００の位置を突き止めるために使用されることができ、一方、ＧＥＩＤインデックス７０６は、ヘッダブロックポインタ７０４で見つけられるアドレスへの増分として役立てることにより、金融商品に対する適用可能な地域ブロック８００の位置を突き止めるために使用されることができる。

表６０８内の各バスケット情報フィールド８１６は、バスケット識別子および加重の対（バスケットＩＤ、加重）を含むことが好ましい。バスケットＩＤは、特定のバスケットを特定するのに役立ち、一方、加重は、対象の金融商品に対する特定されたバスケットへの差分寄与を計算するときに使用される加重を特定するのに役立つ。

単一の金融商品がいくつかの異なるバスケット内に存在することがあることを考慮すると、所与の金融商品に必要な（バスケットＩＤ、加重）対の数が単一のブロック８００内に収まらない可能性がある。そのようなオーバフロー状況に対応するために、表６０８はまた、複数の拡張ブロックレコード８２２を有することが好ましい。各拡張ブロックレコード８２２は、固定サイズであり、拡張ポインタ８１８に対応するビット列、カウントフィールド８２０に対応するビット列、金融商品に必要とされる任意の１つ以上の（バスケットＩＤ、加重）対８１６を含むことが好ましい。金融商品に対する（バスケットＩＤ、加重）対８１６の数が単一の拡張ブロック８２２内に収まることができない場合、拡張ポインタ８１８は、追加の（バスケットＩＤ、加重）対８１６が見つけられる追加の拡張ブロック８２２のアドレスを特定するのに役立つ。したがって、複数の拡張ブロック８２２が、金融商品に関係する（バスケットＩＤ、加重）対８１６のすべてを包含するために必要とされることがあることは留意されるべきである。カウントフィールド８２０は、対象の拡張ブロック８２２内にどれだけの（バスケットＩＤ、加重）対８１６が存在するかを特定する。

ブロック８００内のカウントフィールド８０６は、そのブロック８００内にどれだけの（バスケットＩＤ、加重）対８１６が存在するかを特定するのに役立つ。

フィールド８１０、８１２、および８１４は、関係する取引所での対象の金融商品に対する最も新しく記憶された買い呼値／売り呼値／終値を含む。図６に示されるように、この価格情報は、差分寄与計算に関係のある価格変化値６１４（または差分価格）を計算するために使用される。

したがって、表６０４から取り出されたポインタ７０４およびＧＥＩＤインデックス参照７０６を使用して、ＢＡＬモジュール５０２は、対象のメッセージに関係のある複合情報に対応する、表６０８内のブロック８００（たとえば、「ＧＥＩＤ_０」とラベルが付けられて図８で示されるブロック８００）、および対象のメッセージに関係のある地域情報に対応する、表６０８内のブロック８００（たとえば、「ＧＥＩＤ_１」とラベルが付けられて図８で示されるレコード８００）にアクセスするように構成される。該当する地域ブロックを見つけるために、ＢＡＬモジュールは一致するＧＥＩＤフィールド７０６を使用して、関係する複合ブロックから該当する地域ブロックまでカウントダウンする。したがって、特定の金融商品に対する関係する地域ブロックが、レコード７００内の２番目のＧＥＩＤフィールド７０６（ＧＥＩＤ_２）と一致するＧＥＩＤ値を有するＮＹＳＥブロックである場合、ＢＡＬモジュールは、複合ブロックから２ブロック後の、表６０８内の該当するＮＹＳＥブロック８００を見つける。

図８の例では、図に示すように、地域情報にはオーバフロー状況があり、拡張ポインタ８０４が拡張ブロック８２２の位置を示す。これらの探索に基づき、ＢＡＬモジュール５０２は、金融商品の該当する地域見込みに対する買い呼値／売り呼値／終値および（バスケットＩＤ、加重）対だけでなく、金融商品の複合見込みに対する買い呼値／売り呼値／終値および（バスケットＩＤ、加重）対も取り出す。下流の計算が該当する値に基づいていることを保証するために、複合見込みに対する取り出された買い呼値／売り呼値／終値６１２が、複合見込みに対する取り出された（バスケットＩＤ、加重）対６１０のリストと関連付けられる必要があり、かつ地域見込みに対する取り出された買い呼値／売り呼値／終値６１２が、地域見込みに対する取り出された（バスケットＩＤ、加重）対６１０のリストと関連付けられる必要があることは留意されるべきである。この連関を維持するために、以下に説明される差分イベントが利用されることが好ましい。

ＢＡＬモジュール５０２はまた、表６０８内のレコードを各メッセージ内の新しい価格６０２で更新するように構成されることが好ましい。これは、表６０８の該当するフィールドへの書き込み動作を表す、図６の矢印６１８により示される。しかしながら、メッセージが、終値フィールドなどの特定の価格フィールドを含まない場合、ＢＡＬモジュール５０２は、関係するブロック８００内の終値フィールド８１４をその現状で維持することが好ましいことは留意されるべきである。

表６０４内の各レコード７００に対する一連のＧＥＩＤフィールド７０６は、簡単にするために固定サイズとなる場合があることは留意されるべきである。実行者が各レコード７００内のＧＥＩＤフィールド７０６にどれだけ多くのサイズを割り当てるかに応じて、金融商品が十分に多くの取引所で売買するので、金融商品の関係するＧＥＩＤを記憶するための十分に多くのフィールド７０６がない場合がある可能性がある。したがって、この状況が発生し、メッセージのＧＥＩＤ６００が表６０４の関係するレコード７００内のどのＧＥＩＤフィールド７０６にも一致を見いだせない場合、ＢＡＬモジュール５０２は、表６０８から該当する地域ブロックを取り出すために、その金融商品に対するレコード内の最終ヘッダブロック８００までインデックスし、ヘッダブロックのＧＥＩＤフィールド８０２の線形検索を行って、メッセージに関連するＧＥＩＤ６００との一致を見つけることが好ましい。

ＧＥＩＤ６００が、表６０８内の金融商品レコードに対するＧＥＩＤフィールド８０２のどれにも見つからない場合、このことは、ＧＥＩＤ６００に対応するその金融商品の地域見込みがどのバスケットにも含まれないことを意味することにも留意されるべきである。

金融商品に対する表６０８内のバスケット連関レコードへの（バスケットＩＤ、加重）対の追加、および／またはそこからの削除により、１日を通してバスケットが動的に変更されることがあることも留意されるべきである。

バスケットに金融商品を追加するには、システムは、該当する（バスケットＩＤ、加重）対を表６０８内のその金融商品のレコードに追加する。プロセッサ１１２などのＧＰＰ上で実行するソフトウェアで行われることが好ましい制御プロセスが、表６０４および６０８のコピーを維持し、表６０８（および、その金融商品に対するＧＥＩＤが、その金融商品に対するレコード７００のＧＥＩＤフィールド７０６内に存在しない場合には場合によっては表６０４）のどこに項目が追加される必要があるかを計算して、バスケットへの金融商品の追加を反映させることが好ましい。これらの決定は、追加される金融商品に対する記号ＩＤおよびＧＥＩＤを使用して行われることができる。次に、制御プロセスは、表６０４および６０８を更新するために有効な、ＢＡＬモジュール５０２により使うためのメモリ書き込みコマンドをパイプラインに送信して、対象の金融商品の追加をバスケットへ反映させることが好ましい。制御プロセスはまた、ＢＡＬモジュール５０２により使うための総合（ｓｙｎｔｈｅｔｉｃ）イベントをパイプラインに即座に送信するように構成されることもあり、このイベントは、関係のある金融商品に対する現在の価格を含む。この動作は、対象のバスケットに対するＮＡＶ値に差分更新を引き起こし、これらの差分更新は、ゼロを基準とする（したがって、全価格寄与が決定される）。しかしながら、制御プロセスは、単にその後の市場イベントがパイプラインに到着するのを待ち、そのときに差分更新が適用されるようにするように構成されることがあることにも留意されるべきである。

バスケットからの金融商品の削除は、一般に対象の金融商品に対する表６０８内のレコードから対象のバスケットに対する（バスケットＩＤ、加重）対を削除することを伴う。さらに、ＮＡＶ値を適切に更新して、バスケットからの金融情報の削除を反映させるためには、制御プロセスは、パイプラインに引き渡すための総合イベントを生成することが好ましく、対処の金融商品に対する価格情報はゼロである。これが、金融商品に対する差分価格値６１４に、表６０８内に記憶されたその金融商品に対する価格情報の負の値を生じさせ、したがって、その金融商品に対する対象のバスケットへの全価格寄与を取り除く。

システムにバスケット全体を追加するには、制御プロセスは当然、新しいバスケットの構成要素となっている金融商品のすべてに対する（バスケットＩＤ、加重）対を表６０８に追加する適切なメモリ書き込みコマンドをパイプラインに発行することができるということになる。制御プロセスはまた、上記に説明されたように、これらの構成要素となっている金融商品に対する現在の価格情報を反映させる、パイプラインに引き渡すための総合イベントを生成することもできる。さらに、以下の図９および図１３に関連して理解されることができるように、制御プロセスは、除数表、ＮＡＶ表、顧客ＮＡＶ表、および顧客トリガしきい値表への該当する項目の追加を開始して、システムに新しいバスケットの追加を反映させることができる。

システムからバスケット全体を削除するには、制御プロセスは、対象のバスケットの構成要素となっている金融商品のすべてに対する（バスケットＩＤ、加重）対の表６０８からの削除を開始するように構成されることができるということにもなる。同様に、図９および図１３に示される表内のレコードもまた、更新されて、削除されるバスケットのバスケットＩＤに関連するそれらのレコードを削除することができる。

ＢＡＬモジュール５０２からの出力は、差分イベントのストリームである。各差分イベントは、取り出された（バスケットＩＤ、加重）対６１０、およびその取り出された（バスケットＩＤ、加重）対６１０に対応する金融商品に対する少なくとも１つの計算された価格変化６１４を含むことが好ましい。本発明の一実施形態では、価格差分のうちの１つ以上（たとえば、Δ買い呼値）がゼロであっても、各差分イベントは価格差分すべてを含む。しかしながら、以下に指摘するように、これが実情である必要はない。

ＢＡＬモジュール５０２への入力で受信されるメッセージイベントごとに、受信されたメッセージの対象である金融商品が、複数のバスケットの構成要素となっている場合があるという事実により、ＢＡＬモジュール５０２の出力で複数の差分イベントが生成されることがあるということも理解されるべきである。このように増加することもあって、パイプライン５００の低遅延性質は、バスケット価値を更新するタスクが、異なる取引所からのイベントの流入に遅れないようについていけるようになるという点で特に有利である。

図５に戻ると、バスケット価値更新モジュール５０４は、ＢＡＬモジュール５０２により生成される差分イベントごとに新しいバスケット価値を計算するように構成される。図８は、例示的バスケット価値更新（ＢＶＵ）モジュール５０４を示す。

差分イベントバッファ９００が、ＢＡＬモジュール５０２により生成された差分イベントをバッファに入れる。バッファ９００から読み出された差分イベントごとに、ＢＶＵモジュール５０４は、除数表９０２での探索を行って、現在の差分イベント内のバスケットＩＤに対応するバスケットに対して、除数ｄに対する適切な値を式（３）から決定する。したがって、表９０２は、各除数値を除数の対応するバスケットに対するバスケットＩＤによりインデックスすることが好ましいことが理解されることができる。差分イベントバッファ９００および除数表９０２は、再構成可能論理デバイス１０２のための利用可能なオンチップメモリ内に位置することが好ましい。しかしながら、代わりに、バッファ９００および表９０２は、コプロセッサ１４０内またはそれにアクセス可能などんなメモリ資源上にでも記憶されることが可能であることは留意されるべきである。

次に、ＮＡＶ更新エンジン９５０は、入力として差分イベント情報（（バスケットＩＤ、加重）対６１０および差分買い呼値／売り呼値／終値６１４）に加えて、その差分イベントに対する除数値ｄを受信して、少なくとも１つの更新されたバスケット価値ＮＡＶ^ｎｅｗを計算する。ＮＡＶ更新エンジン９５０は、バスケットごとに複数の異なる種別のバスケットＮＡＶを計算するように構成されることが好ましい。たとえば、図９に示されるように、ＮＡＶ更新エンジン９５０は、買い呼値、売り呼値、終値、買い呼値−価格変動（Ｔｉｃｋ）値、および売り呼値＋価格変動値に基づく新しいＮＡＶ（それぞれ、買いＮＡＶ^ｎｅｗ、売りＮＡＶ^ｎｅｗ、最終ＮＡＶ^ｎｅｗ、買い−価格変動ＮＡＶ^ｎｅｗ、および売り＋価格変動ＮＡＶ^ｎｅｗ）を並列に計算するように構成されることができる。これらの例では、価格変動値は、金融商品価格の変化を測定するために関係する取引所により使用される最小増分として定義される。

デマルチプレクサ９０４は、差分イベント情報および除数値の部分を該当するＮＡＶ計算論理回路９１６にルーティングするように動作する。ＮＡＶ更新エンジンは、複数の並列計算経路を利用して、各種別のバスケットＮＡＶを計算することが好ましい。

買いＮＡＶ^ｎｅｗを計算するための計算経路は、バスケットＩＤ、加重、除数、およびΔ買い呼値で動作することが好ましい。ＢＶＵモジュール５０４は、バスケットＩＤに基づいて買いＮＡＶ表９０６での探索を行って、対象のバスケットに対する記憶された買いＮＡＶ値（買いＮＡＶ^ｏｌｄ）を取り出す。この買いＮＡＶ^ｏｌｄ値は、買いＮＡＶ^ｎｅｗ計算の間に式（２）中のＮＡＶ^ｏｌｄ値の役割を果たす。次に、ＮＡＶ計算論理回路９１６は、（ｉ）式（３）中のｄ項に除数値を、式（３）中のｗ_ｊ項に加重値を、および式（３）中の

項にΔ買いの値を使用して、式（３）に従って金融商品に対する差分寄与Δｊを計算し、（ｉｉ）その後、計算されたΔｊ、および買いＮＡＶ^ｏｌｄ値に基づき式（２）に従って買いＮＡＶ^ｎｅｗを計算する。

売りＮＡＶ^ｎｅｗを計算するための計算経路は、バスケットＩＤに基づき売りＮＡＶ表９０８での探索を行い、Δ買い呼値の代わりにΔ売り呼値を使用するが、買いＮＡＶ^ｎｅｗのための計算経路と同じ方法で動作することが好ましい。

最終ＮＡＶ^ｎｅｗを計算するための計算経路も、バスケットＩＤに基づき最終ＮＡＶ表９１０での探索を行い、Δ買い呼値の代わりにΔ終値を使用するが、買いＮＡＶ^ｎｅｗのための計算経路と同じ方法で動作することが好ましい。

同様に、買い−価格変動ＮＡＶ^ｎｅｗ値および売り＋価格変動ＮＡＶ^ｎｅｗ値を計算するための計算経路は、バスケットＩＤに基づきそれぞれ買い−価格変動ＮＡＶ表９１２および売り−価格変動ＮＡＶ表９１４での探索を行い、それぞれΔ買い呼値およびΔ売り呼値を使用するが、買いＮＡＶ^ｎｅｗのための計算経路と同じ方法で動作することが好ましい。

表９１２は、金融商品に対する価格に基づく、金融商品に対する以前の買い呼値から価格変動値を減算した、バスケットごとの以前に計算されたＮＡＶを記憶することができる。表９１４は、金融商品に対する価格に基づく、金融商品に対する以前の売り呼値に価格変動値を加算した、バスケットごとの以前に計算されたＮＡＶを記憶することができる。

表９０６、９０８、９１０、９１２、および９１４は、再構成可能論理デバイス１０２のための利用可能なオンチップメモリ内に記憶されることが好ましい。しかしながら、これらの表は、代わりにコプロセッサ１４０内、またはそれにアクセス可能などんなメモリ資源上にでも記憶されることができることは留意されるべきである。

したがって、ＮＡＶ更新エンジン９５０は、クロックサイクルごとに、更新バスケットイベントを出力するように構成されることが好ましいことが理解されることができる。ここで、各更新バスケットイベントは、そのバスケットに対するバスケットＩＤと共に、特定のバスケットに対する複数の異なる更新されたＮＡＶを含む。

ＢＶＵモジュールはまた、新しく計算されたＮＡＶ値を用いて表９０６、９０８、９１０、９１２、および９１４を更新するように構成されることが好ましい。したがって、所与のバスケットＩＤに対する新しく計算された買いＮＡＶ^ｎｅｗは、表９０６内のそのバスケットＩＤに対する項目にフィードバックされることができ、その結果、同じバスケットＩＤに関係する次の差分イベントが最新のＮＡＶ^ｏｌｄ値を取り出すことになる。表９０６、９０８、９１０、９１２、および９１４に対するメモリは、デュアルポートであることが好ましく、したがって、２つの読み出し／書き込み動作が各クロックサイクルで発生することができるようになる。ＢＶＵモジュールのための更新論理回路がパイプライン化されている場合、同じクロックサイクルでの読み出しおよび書き込みの動作の間に所与の表内の同じバスケットＩＤ項目に対する競合がまれになり、当該技術分野で知られる技術を使用して特定され、避けられことができることが期待され得る。

また、制御プロセスは、バスケットの除数に対する値変化のイベントの際に、ＢＶＵモジュールにより使うためのメモリ書き込みコマンドをパイプラインに発行して、除数表９０２内の項目を更新することができる。そのような制御プロセスは、プロセッサ１１２などのＧＰＰ上で実行するソフトウェアで行われることが好ましい。

図１０ａは、ＮＡＶ計算論理回路９１６の例示的実施形態を示す。乗算器１０００が、加重値および各差分イベントからの差分価格情報を使用して、式（３）の

部分を計算するように動作する。除算器１００２が、式（３）に従って

値をｄで除算して、それによりΔｊを計算するように動作する。その後、加算器１００４がΔｊをＮＡＶ^ｏｌｄ値に加算するために使用され、それにより式（２）に従ってＮＡＶ^ｎｅｗを計算する。

図１０ｂは、ＮＡＶ計算論理回路９１６の別の例示的実施形態を示す。図１０ｂの実施形態では、除算演算が最後に実行され、それにより図１０ａの実施形態と比較してＮＡＶ計算の精度を改善する。式（３）を介して式（２）に固有の除算演算が最後に実行されるように算術演算を再配列するために、図１０ｂの実施形態は、乗算器１００６を使用して乗算演算を追加することが好ましい。この乗算演算は、乗算器１０００により行われる乗算演算と並列に行われことができる。乗算器１００６は、ＮＡＶ^ｏｌｄ値にｄを乗算するように動作し、それにより値Ｓ^ｏｌｄが得られる。この実施形態では、金融商品の差分寄与は、図１０ｂの１０１２に示されるように、

と表されることができる。次に、加算器１００４がＳ^ｏｌｄと

の和を計算する。Ｓ^ｏｌｄはｄＮＡＶ^ｏｌｄに等しいことを考慮すると、

をｄで除算する動作が、式（２）および（３）に従ってＮＡＶ^ｎｅｗをもたらすことが容易に理解されることができる。

図１０ｃは、ＮＡＶ計算論理回路９１６のさらに別の例示的実施形態を示す。図１０ｃの実施形態では、図１０ｂの実施形態の精度改善が維持される一方で、乗算器１００６の必要性もなくする。そうするためには、図１０ｃのＮＡＶ計算論理回路９１６を利用するＢＶＵモジュールで、ＮＡＶ表９０６、９０８、９１０、９１２、および９１４が、ＮＡＶ^ｏｌｄ値の代わりにＳ^ｏｌｄ値を記憶することが好ましく、それにより、乗算器１００６の必要性をなくする。さらに、表９０６、９０８、９１０、９１２、および９１４を更新するために、次の差分イベントが処理されるときに、Ｓ^ｎｅｗがＳ^ｏｌｄの役を果たすように、Ｓ^ｎｅｗの値（

と同じである）が通信リンク１０１０を介して関連する表にフィードバックされる。

ＢＶＵモジュール５０４は、複数のＮＡＶ更新エンジン９５０を並列に利用して、それにより複数のバスケットに対する複数のバスケットＮＡＶ種別を同時に計算することができることは留意されるべきである。この一例が図１１に示されている。ここで、ＢＶＵモジュール５０４は、２つの並列なＮＡＶ更新エンジン９５０を含む。このような実施形態では、ＢＶＵモジュール５０４は、クロックサイクルごとにバッファ９００から２つの差分イベントを読み出す。差分イベントごとの該当する除数値を特定するために除数表９０２での探索が行われた後に、ルーティング論理回路１１００が、差分イベント情報およびそれに関連する除数値を該当するＮＡＶ更新エンジン９５０にルーティングする。そのようなルーティング論理回路１１００は、バスケットＩＤの範囲の異なる部分を各組の並列エンジン９５０に割り当てるように構成されることができる。

必要に応じて、ただ１組のＮＡＶ表９０６、９０８、９１０、９１２、および９１４が複数のＮＡＶ更新エンジン９５０により共用されることができることは留意されるべきである。ＮＡＶ更新エンジンの数がＮＡＶ表から読み出すために利用可能なポート数を超える場合、ＢＶＵモジュール５０４は、異なるＮＡＶ更新エンジンからのこれらの表へのアクセスをインタリーブするように構成されることができる。これらの表はまた、そのようなインタリーブを避けるように望まれる場合には、複製されることもできる。同じことが、除数表９０２に関して主張されることができる（図１１は、２つの除数表が利用される一実施形態を示すが、図１１では単一の除数表９０２が異なる経路により共用される場合があることは留意されるべきである）。

図１２は、パイプライン５００が、ＢＶＵモジュール５０４からの出力と通信する価格イベントトリガモジュール１２００を含む一実施形態を示す。価格イベントトリガ（ＰＥＴ）モジュール１２００は、ＢＶＵモジュール５０４により生成されるどの更新されたバスケット価値が、関心のある顧客に報告されるべきかを決定するように構成される。これらの決定は、任意の数の基準に基づいて行われることができる。顧客はバスケットの価値が一定量変化するときに彼／彼女が通知されるように要求した特定のトレーダのこともあり、または顧客は売買システム内の別のアプリケーションのこともある。顧客はまた、コプロセッサ１４０上に導入された別のモジュールのともある（パイプライン５００がＦＡＭパイプラインの場合の別のＦＡＭ１５０など）。

図１３は、ＰＥＴモジュール１２００の例示的実施形態を示す。ＰＥＴモジュール１２００は、ＢＶＵモジュール５０４により生成された、バスケットに対する各バスケット価値種別に対して並列に動作するように構成されることが好ましい。また、更新されたバスケット価値のうちどれが関心のある顧客に報告されるべきかを決定するために、ＰＥＴモジュール１２００は、各更新されたバスケット価値を顧客により定義されたトリガしきい値と比較することが好ましい。

ＰＥＴモジュール１２００は、異なるＮＡＶ種別に対応する複数の表にアクセスすることが好ましい。ここで、これらの表は、バスケットごとの顧客参照値を記憶する。これらの参照値は、新しいバスケット価値が、関心のある顧客に報告されるべきかどうかを判断するためにＰＥＴモジュール１２００により使用される。例示的実施形態では、参照値は、以前にその顧客に報告された対象のバスケットに対するＮＡＶ値である。したがって、顧客ＮＡＶ表は、ＢＶＵモジュール５０４により生成されるバスケット価値種別ごとに存在することが好ましい。すなわち、参照値表１３０２が、異なるバスケットに対する複数の顧客買いＮＡＶを記憶する。ここで、各顧客買いＮＡＶは、バスケット識別子によりインデックスされる。参照値表１３０４が、異なるバスケットに対する複数の顧客売りＮＡＶを記憶する（各顧客売りＮＡＶはバスケット識別子によりインデックスされる）。参照値表１３０６が、異なるバスケットに対する複数の顧客最終ＮＡＶを記憶する（各顧客最終ＮＡＶはバスケット識別子によりインデックスされる）。参照値表１３０８が、異なるバスケットに対する複数の顧客買い−価格変動ＮＡＶを記憶する（各顧客買い−価格変動ＮＡＶはバスケット識別子によりインデックスされる）。参照値表１３１０が、異なるバスケットに対する複数の顧客売り＋価格変動ＮＡＶを記憶する（各顧客売り＋価格変動ＮＡＶはバスケット識別子によりインデックスされる）。これらの表はそれぞれ、顧客に報告されるべき、それぞれの表のＮＡＶ種別の最新値を記憶することが好ましい。したがって、新しいバスケット価値により誘発されるトリガのうちの１つのイベントで、ＰＥＴモジュールが、顧客表内のＮＡＶ値を新しいバスケット価値で更新するように構成されることが好ましい。そのような更新論理回路は、トリガを誘発するそれらのＮＡＶ値のためだけに表を更新するように構成されることができる、または任意のＮＡＶ値がトリガを誘発するときには、表のすべてを更新するように構成されることができる。

また、顧客ＮＡＶトリガしきい値表は、ＢＶＵモジュール５０４により生成されるバスケット価値種別ごとに存在することが好ましい。したがって、表１３１４が、異なるバスケットに対する複数の顧客買いＮＡＶトリガしきい値を記憶する。ここで、各顧客買いＮＡＶトリガしきい値は、バスケット識別子によりインデックスされる。表１３１６が、異なるバスケットに対する複数の顧客売りＮＡＶトリガしきい値を記憶する（各顧客売りＮＡＶトリガしきい値は、バスケット識別子によりインデックスされる）。表１３１８が、異なるバスケットに対する複数の顧客最終ＮＡＶトリガしきい値を記憶する（各顧客最終ＮＡＶトリガしきい値は、バスケット識別子によりインデックスされる）。表１３２０が、異なるバスケットに対する複数の顧客買い−価格変動ＮＡＶトリガしきい値を記憶する（各顧客買い−価格変動ＮＡＶトリガしきい値は、バスケット識別子によりインデックスされる）。表１３２２が、異なるバスケットに対する複数の顧客売り＋価格変動ＮＡＶトリガしきい値を記憶する（各顧客売り＋価格変動ＮＡＶトリガしきい値は、バスケット識別子によりインデックスされる）。

表１３０２、１３０４、１３０６、１３０８、１３１０、１３１４、１３１６、１３１８、１３２０、および１３２２は、再構成可能論理デバイス１０２のための利用可能なオンチップメモリ内に記憶されることが好ましい。しかしながら、これらの表は、代わりにコプロセッサ１４０内、またはそれにアクセス可能などんなメモリ資源上にでも記憶されることができることは留意されるべきである。

また、顧客ＮＡＶ表および顧客ＮＡＶトリガしきい値表は、必要に応じて本発明のこの実施形態の実行者により任意選択で統合されることができることは留意されるべきである。そうする際には、各レコードが顧客買いＮＡＶおよび顧客買いＮＡＶトリガしきい値を含むように、顧客買いＮＡＶ表１３０２内のレコードが、顧客買いＮＡＶトリガしきい値表１３１４内のレコードと併合される。同様に、表１３０４は表１３１６と、表１３０６は表１３１８と、表１３０８は表１３２０と、および表１３１０は表１３２２と併合されることができる。

ＰＥＴモジュール１２００は、複数の並列計算経路を使用して、各バスケットイベント内のＮＡＶ種別のいずれかが顧客トリガを誘発するかどうかを決定することが好ましい。

第１の計算経路が、現在の更新バスケットイベントのバスケットＩＤに基づいて、顧客買いＮＡＶ表１３０２での探索、および顧客買いＮＡＶトリガしきい値表１３１４での探索を行って、それにより顧客買いＮＡＶおよび顧客買いＮＡＶトリガしきい値を取り出すように構成される。顧客買いＮＡＶは、更新バスケットイベント内の買いＮＡＶが比較されるトリガの役を果たす。次に、顧客買いＮＡＶトリガしきい値は、トリガが誘発されたかどうか判断する基準として利用される。次に、ＮＡＶ−トリガ比較論理回路１３１２がこの比較を行い、トリガが誘発されたかどうか決定するように動作する。ここで、買いＮＡＶトリガフラグがこの決定の結果を示す。

追加の計算経路が、更新バスケットイベントの売りＮＡＶ、最終ＮＡＶ、買い−価格変動ＮＡＶ、および売り＋価格変動ＮＡＶに対してこれらの操作を行って、図１３に示されるように、それぞれ売りＮＡＶ、最終ＮＡＶ、買い−価格変動ＮＡＶ、および売り＋価格変動ＮＡＶのトリガフラグを生成する。

トリガ検出論理回路１３２４が、計算経路により生成された異なるＮＡＶトリガフラグを受信する。この論理回路１３２４は、所与の更新バスケットイベントに対するトリガフラグのうちいずれかがハイの状態となっているかどうかを決定するように構成される。トリガ検出論理回路１３２４は、その更新バスケットイベントに対するフラグのうちいずれかがハイの状態にある場合、更新バスケットイベントを出力として渡すように構成されることが好ましい。したがって、ＰＥＴモジュール１２００は、顧客により定義された基準に従って注目に値すると思われる更新バスケットイベントを通過させるフィルタの役を果たすことが理解されることができる。

図１４は、比較論理回路１３１２の例示的実施形態を図示する。減算器１４００が、取り出された顧客ＮＡＶを更新バスケットイベントのＮＡＶ（ＮＡＶ^ｎｅｗ）から減算するように動作する。次に、比較器１４０４が、ＮＡＶ^ｎｅｗと顧客ＮＡＶとの差を、取り出された顧客トリガしきい値と比較して、ＮＡＶトリガフラグがセットされるべきかどうか決定する。差がしきい値を超える場合、比較器はＮＡＶトリガフラグをハイに設定することが好ましい。

したがって、顧客が、バスケット１４５の買いＮＡＶが０．０５ドルだけ変化したときはいつでも、バスケット１４５に対する売りＮＡＶが０．０３ドルだけ変化したときはいつでも、またはバスケット１４５に対する最終ＮＡＶが０．０２ドルだけ変化したときはいつでも、通知されたいと思う場合がある。このような例では、バスケット１４５に対する表１３１４内の顧客買いＮＡＶトリガしきい値が０．０５ドルに等しく設定されることができ、バスケット１４５に対する表１３１６内の顧客売りＮＡＶトリガしきい値が、０．０３ドルに等しく設定されることができ、バスケット１４５に対する表１３１８内の顧客最終ＮＡＶトリガしきい値が０．０２ドルに等しく設定されることができる。バスケット１４５に対する更新バスケットイベント内の新しい買いＮＡＶ値、売りＮＡＶ値、および最終ＮＡＶ値が、それぞれ２０．５０ドル、２０．４０ドル、および２０．２０ドルで、一方、バスケット１４５の顧客ＮＡＶに対する記憶された値が、それぞれ２０ドル、２０．４２ドル、および２０．１９ドルの場合、比較論理回路は、買いＮＡＶトリガフラグをハイに、売りＮＡＶトリガフラグをローに、および最終ＮＡＶトリガフラグをハイに設定するように動作する。

しかしながら、比較論理回路１３１２は、顧客トリガがいくつかの方法のうちどれかで誘発されたかどうかを決定するように構成されることができることは留意されるべきである。たとえば、顧客しきい値は、必要に応じて、パーセントに換算して表現されることができる（新しいＮＡＶと顧客ＮＡＶのパーセント差を計算するために、比較論理回路内で対応する調節を伴う）。また、トリガ条件は、対象のＮＡＶとは異なるトラッキング証券に基づくことができる。たとえば、所与のバスケットに対するトリガ条件が、ＤＪＩＡに対する記憶された価格に関連して定義されることができる。次に、顧客ＮＡＶ表は、そのバスケットに対するＤＪＩＡ価格を記憶し、そのバスケットのＮＡＶ価格が、取り出されたＤＪＩＡ価格と比較されて、トリガしきい値に到達されたかどうかを決定する。

ＰＥＴモジュール１２００は、顧客ＮＡＶ表および顧客トリガしきい値表を適切にポピュレートすることにより裁定取引条件を検出するように構成されることができる。たとえば、ＥＴＦについては、ＥＴＦ自体の現在の株価（Ｔ_ＥＴＦ）と共に顧客ＮＡＶ表がポピュレートされることができる。したがって、顧客買いＮＡＶ表は、ＥＴＦの株式に対する現在の買い呼値と共にポピュレートされることができ、顧客売りＮＡＶ表は、ＥＴＦの株式に対する現在の売り呼値と共にポピュレートされることができ、顧客最終ＮＡＶ表は、ＥＴＦの株式に対する最新の終値と共にポピュレートされることができるなどである。この方法で顧客ＮＡＶ表をポピュレートすることにより、ＰＥＴモジュールは、ＥＴＦの株価と、ＥＴＦの構成要素となっている金融商品の純資産価値の間に相違があるときを検出することができる。そのような相違は、以下に説明されるように、トレーダにより利用されることができる。

したがって、パイプラインによりＴ_ＥＴＦとＥＴＦのＮＡＶの相違について通知される顧客アプリケーションが、１つ以上の金融市場で１つ以上の売買を申し込んで、検出された裁定取引から利益を得ることができる。たとえば、ＥＴＦのＮＡＶが、ＥＴＦの株価よりも低い場合、顧客アプリケーションが、以下のステップを実行することができる：
ＥＴＦのポートフォリオ内の金融商品の株式をＮＡＶにほぼ等しい総費用で購入することによりバスケットを整理し、
整理されたバスケットを投資信託の所有者と交換することによりＥＴＦ株式を生成し、
取引所でＥＴＦをＴ_ＥＴＦにほぼ等しい価格で売る。

さらに、ＥＴＦのＮＡＶがＥＴＦの株価よりも大きい場合、顧客アプリケーションが上記のステップを逆に実行することができる。すなわち、トレーダが、対象のＥＴＦの１つ以上の株式を市場から購入し、ＥＴＦをその構成要素となっている金融商品の株式と交換し、次に、構成要素となっている金融商品のこれらの株式を市場で売ることができる。

顧客トリガしきい値表内のトリガしきい値は、以下に説明されるように、価格相違を利用するそのような売買を行う過程に含まれるどんな予想される取引費用も考慮する値と共にポピュレートされることができることも留意されるべきである。したがって、整理されたＥＴＦに対する販売価格が、バスケットを整理するために購入された金融商品株式の集計した価格、およびそうする際の関連する取引費用を超える（または構成要素となっている金融商品に対する販売価格が、ＥＴＦの購入価格、および関連する取引費用を超える）場合、顧客アプリケーションを使用するトレーダは、裁定取引を介して利益を生むことができる。そのような行為がうまくいくためには、本発明者は、時間が本質的であることに注目し、開示されたパイプラインの低遅延性質は、そのような裁定取引条件が絶えず変化する市場に現れるときに、そのような裁定取引条件を認識しそこから利益を得るトレーダの能力を大きく高めると思われる。

さらに、ＰＥＴモジュール１２００は、複数の異なる顧客に対する更新バスケットイベントをフィルタにかけることができることは留意されるべきである。この方法では、加入している各顧客は、それ自身の１組の参照値およびトリガしきい値を定義することができる。そのような機能を実現するためには、各更新バスケットイベントは、図１５に示されるように、複数の顧客特有ＰＥＴモジュール１５００を介して異なる顧客に対する複数の基準で並列に比較されることができる。顧客特有ＰＥＴモジュール１５００（それぞれが、図１３のＰＥＴモジュール１２００の顧客特有レプリカントである）は、直列に配置されることができる（ここで、各顧客特有ＰＥＴモジュールは、各更新バスケットイベントに顧客特有フラグを任意選択で追加して、それによりその顧客のトリガ基準が満たされたかどうかを示す）ことも留意されるべきである。さらに、顧客特有ＰＥＴモジュール１５００はまた、必要に応じて、混成の並列／直列配列に配列されることができる。

図１６は、パイプライン５００がＰＥＴモジュール１２００からの出力と通信するイベント生成器モジュール１６００を含む一実施形態を示す。イベント生成器モジュール１６００は、入力のトリガバスケットイベントをそれぞれ処理して、トリガバスケットイベント内に計算された新しいＮＡＶを含む正規化された出力メッセージイベントを構築するように構成される。

図１７は、イベント生成器モジュール１６００の例示的実施形態を示す。イベント生成器モジュール１６００は、各出力イベント１７０４にそのイベントに対する関係者一覧を定義するビット列を挿入するように構成されることが好ましい。ここで、関係者一覧は、イベントを通知されるべき各顧客を特定する。この関係者一覧は、各ビット位置が異なる顧客に対応するビットベクトルの形式をとることが好ましい。ハイ状態のどのビット位置についても、これは、そのビット位置に対応する顧客が通知されるべきであることを意味する。

関係者一覧表１７００は、バスケットごとにそのようなビットベクトルを記憶することが好ましい。イベント生成器モジュール１６００がＰＥＴモジュール１２００からトリガバスケットイベントを受信するとき、イベント生成器モジュール１６００は、トリガバスケットイベント内のバスケットＩＤに基づき関係者一覧表１７００での探索を行う。この探索の結果、そのバスケットＩＤに対する関係者一覧ベクトルが取り出される。その後、フォーマッタ１７０２が、図１７に示されるように、取り出された関係者一覧ベクトル１７０５、および受信されたトリガバスケットイベント内の情報から、出力メッセージイベント１７０４を組み立てる。フォーマッタ１７０２は、出力イベント１７０４が、出力イベント１７０４の顧客受信者（または複数の受信者）により適切に解釈されることができるように、出力イベント１７０４にヘッダ１７０８およびトレーラ１７１０を追加するように構成されることが好ましい。そのような出力イベントの形式は、知られていても（たとえば、ＦＡＳＴおよびＦＩＸ）独自でも、いくつかのメッセージングプロトコルのどれにも適合することができる。示されたように、出力イベント１７０４の関係者一覧ベクトル１７０６内のビット位置の値は、どの顧客がイベント１７０４の受信者になるべきかを定義する。

関係者一覧表１７００は、再構成可能論理デバイス１０２のための利用可能なオンチップメモリ内に配置されることが好ましい。しかしながら、表１７００は、代わりにコプロセッサ１４０内、またはそれにアクセス可能などんなメモリ資源上にでも記憶されることができることは留意されるべきである。また、フォーマッタ１７０２は、任意選択で出力イベント１７０４用の該当するフィールドを定義する１つ以上のデータ表（図示せず。オンチップまたはオフチップいずれか）にアクセスするように構成される場合があることも留意されるべきである。

イベント生成器モジュール１６００は、このモジュールが受信するトリガバスケットイベントの数、このモジュールが生成する出力イベントの数、およびトリガバスケットイベントごとの平均イベント間時間などの統計データを記憶するように構成されることがあることも留意されるべきである。

図１８は、パイプライン５００が、ＢＡＬモジュール５０２への入力と通信するメッセージ修飾子フィルタモジュール１８００を含む一実施形態を示す。メッセージ修飾子フィルタモジュール１８００は、入力メッセージイベントを処理し、かつＢＣＥにとって関心のないどんなメッセージイベントもフィルタにかけて取り除くように構成される。関心のあるメッセージは、一般にＮＡＶ価格に影響を及ぼすことがあるメッセージを含む。本発明のこの実施形態の実行者がフィルタにかけたいと思うことがあるメッセージの例が、金融商品に対する買い呼値、売り呼値、または終値を含まないメッセージである。たとえば、実行者が、前日の終値を訂正するだけのメッセージ、および日々の出来高に寄与しない売買に関連するメッセージをフィルタにかけて取り除きたいと望む場合がある。

図１９は、図１８のパイプライン５００で利用されることができる例示的メッセージ修飾子フィルタモジュール１８００を示す。表１９００が、複数の修飾子を記憶する。モジュール１８００は、各入力メッセージのうち１つ以上のフィールド（入力メッセージの相場および売買の修飾子フィールドなど）を、表１９００により記憶された別の修飾子と比較するように構成されることが好ましい。各メッセージ修飾子は、一般に条件を通知する小規模のバイナリコードである。表１９００内の各修飾子は、各アドレスに通過／放棄フラグを含む、表１９０２内の項目にマッピングすることが好ましい。したがって、表１９００からの修飾子［１］に関連するメッセージフィールドのどれかに一致が見つかった場合、この一致は表１９０２の位置ｎ−２内の項目へマッピングし、表１９０２の位置ｎ−２内のビット値が取り出され、ＡＮＤ論理回路１９０４への入力として提供される。表１９００からのメッセージ修飾子は、表１９０２内の項目に直接アドレスされることができる。しかしながら、表１９００のサイズが大きく増える場合、ハッシングが使用されて、修飾子を通過／放棄フラグにマッピングすることができることは留意されるべきである。

ＡＮＤ論理回路１９０４への入力のどれかがハイの場合、これが通過／放棄信号１９０６をハイとして続かせる。論理回路１９０８は、入力メッセージを出力に渡すかどうかを決定するときに、信号１９０６により制御されるように構成される。したがって、表１９００からの一致する修飾子のどれかが、表１９０２内のハイビットにマッピングする場合、この結果、対象のメッセージは、メッセージ修飾子フィルタモジュール１８００の出力に渡されることになる。

この方法では、修飾子表内の各修飾子が、入力メッセージ内に見つけられた場合、その入力メッセージがパイプライン５００の下流に渡される、またはそこへ伝えられるのをさえぎられるメッセージ基準を定義することがある。メッセージがさえぎられるべきことを示すために表１９００により記憶されることができるメッセージ修飾子の例が、メッセージを非企業相場、不利益な買い、撤回された相場、保持された売買、および順序が狂った売買のうちのどれでも特定する、メッセージ内の指標である。

表１９００および１９０２は、再構成可能論理デバイス１０２のための利用できるオンチップメモリ内に配置されることが好ましい。しかしながら、これらの表は、代わりにコプロセッサ１４０内、またはそこにアクセス可能などんなメモリ資源上でも記憶されることができることは留意されるべきである。

パイプライン５００への入力メッセージは、メッセージフィールドがパイプライン５００により期待される方法でフォーマットされているという点で、正規化されたメッセージであることが好ましいことも留意されるべきである。そのような正規化は、メッセージがパイプライン５００に到達する時点以前に任意選択で既に行われていたこともある。しかしながら、任意選択で、パイプライン５００は、図２０に示されるように、正規化機能を提供するメッセージ正規化モジュール２０００を含むこともある。そのような正規化は、記号ＩＤマッピング（ここでは、各メッセージが、メッセージの対象である金融商品を一意に特定する記号ＩＤ（固定サイズの２進数タグが好ましい）を割り当てられる）、およびＧＥＩＤマッピング（ここでは、各メッセージが、メッセージに対応する取引所を一意に特定するＧＥＩＤ（同様に、固定サイズの２進数タグが好ましい）を割り当てられる）などの機能を含むことが好ましい。そのような正規化機能を行うＦＡＭモジュールが、上記で参照され組み込まれた米国特許出願第１１／７６５，３０６号に記載されている。

ＢＣＥ４００の管理に関して、バスケットおよびトリガ条件が、いくつかの方法のうちのどれでも作成され、修正され、および／または削除されることができることに留意すべきである。たとえば、システム管理者および／または顧客アプリケーションが、バスケットおよび／またはトリガ条件を定義する能力を与えられることができる。

バスケットを作成および／または修正するためには、パイプライン５００に関連して本明細書に記載される様々な表内の新しい／修正されたバスケットについて、適切な登録および割当が必要とされる。システム管理者が、制御インタフェースを使用して、バスケット構成を追加／修正することがある。顧客アプリケーションが、そのローカル機器上で動作するアプリケーションプログラミングインタフェース（ＡＰＩ）を介してバスケット定義を提出することがある。

ＢＣＥパイプラインは、図２１に示されるように、チッカ装置プラットフォーム２１００のコプロセッサ１４０上に導入されることがある。そのようなチッカ装置プラットフォーム２１００に関連する追加の詳細が、上記で参照され組み込まれた米国特許出願第１１／７６５，３０６号明細書で得られることができる。要約すると、取引所からの金融市場データが、プロセッサ１１２上のカーネルスペースで実行する、Ｏ／Ｓにより供給されるプロトコルスタック２１０２で受信される（図１ａから図ｂを参照のこと）。ｕｐｊｅｔドライバ２１０４が、この取引所データをプロセッサ１１２上のユーザ空間で実行するマルチスレッドフィード処理ソフトウェア２１１２に引き渡す。次に、これらのスレッドは、コプロセッサ１４０宛のデータを、カーネル空間で動作しているハードウェアインタフェースドライバソフトウェア２１０６に伝達することがある。

顧客アプリケーションからの命令はまた、最終的にコプロセッサ１４０に引き渡すためにハードウェアインタフェースドライバ２１０６に伝達されて、コプロセッサ１４０上でインスタンスを生成されるＢＣＥパイプラインを適切に構成することがある。そのような命令は、Ｏ／Ｓにより供給されるプロトコルスタック２１１０に到着し、そこから要求処理ソフトウェアモジュール２１１６に引き渡される。その後、バックグラウンドおよび保守の処理ソフトウェアモジュール２１１４が、顧客アプリケーションがバスケットを追加／変更／修正する適切な資格があるかどうかを決定する。そのような資格がある場合、バックグラウンドおよび保守の処理ブロック２１１４は、以前上記で説明されたように、コプロセッサに運ぶためのコマンド命令をハードウェアインタフェースドライバ２１０６に伝達して、ＢＣＥパイプライン内の表項目を適切に更新して、追加／変更／修正されたバスケットを反映させる。ＢＣＥパイプラインからのトリガ条件の追加／修正／削除だけでなくバスケットの削除も、上記に示されるように、同様の過程で行われることができる。

次に、ハードウェアインタフェースドライバ２１０６は、金融市場データおよびコマンドのインタリーブされたストリームをコプロセッサ１４０により使うためにそこに運ぶことができる。コプロセッサ１４０からの出力データが、ハードウェアインタフェースドライバ２１０６に戻り、そこから、（プロトコルスタック２１１０を介して）顧客接続に引き渡すために、ならびに／またはバックグラウンドおよび保守の処理ブロック２１１４に引き渡すために、ＭＤＣドライバ２１０８に供給されることができる。

上記で説明されたように、ＥＴＦなどの一部の金融商品バスケットが、それに対して何らかの形の現金要素を有する場合がある。これらの現金要素は、いくつかの方法のうちのどれでもシステムにより考慮されることができる。

たとえば、現金要素をバスケットのＮＡＶに挿入するためには、制御プロセスが、パイプラインに引き渡すための総合イベントを生成するように構成されることができる。記号ＩＤが所与の現金勘定に割り当てられ、その複合記号ＩＤに対する価格は１ドルであり、その現金勘定に対する加重値ｗは、現金勘定の現金価値と等しく設定される。ＢＡＬモジュールにより使用される表は更新されて、この総合記号ＩＤを反映し、かつ現金勘定がバスケットに対するＮＡＶに影響を与えるようになる。より複雑なシナリオでは、現金勘定の価値が、外国為替市場での関係する通貨の価値で変動することができるように、パイプラインにイベントが引き渡されることができる。

バスケットの現金要素をシステムに導入する別の方法は、現金要素量が表１３１４、１３１６、１３１８、１３２０、および１３２２のトリガしきい値に組み込まれるように、トリガしきい値を定義することである。

また、ＢＡＬモジュール（またはＢＶＵモジュール）が、そのイベントに対する差分価格のすべてがゼロである場合に、イベントを捨てるように構成されることができることは留意されるべきである。

同様に、図９の実施形態では、ＮＡＶ更新エンジン９５０は、対応する差分価格がゼロであるＮＡＶ種別に対してさえも更新されたＮＡＶを計算するように構成されることは留意されるべきである。すなわち、ＢＶＵモジュールにより処理されている現在の差分イベントが、Δ買い呼値に対して０．０３ドルの値を含むが、Δ売り呼値およびΔ終値に対してゼロ値を含むことがある。したがって、図９の実施形態の場合は、古いＮＡＶに対して変化がない場合、並列経路の異なるＮＡＶ計算論理回路エンジン９１６の一部が、新しいＮＡＶを計算するために使用される（たとえば、所与の例については、売りＮＡＶ^ｎｅｗ、最終ＮＡＶ^ｎｅｗ、および売り＋価格変動ＮＡＶ^ｎｅｗの値は、これらの古い値に比べて変更されない）。パイプラインにより処理されるイベントの大部分が、相場活動を伴うことが予想されることを考慮すると、この構成は依然として有効な効率をもたらすと思われている。しかしながら、差分イベントにどんなゼロ差分イベントも含めず、ＮＡＶ更新エンジン９５０内のすべての利用可能な計算経路をより十分に利用するために、差分イベントをＮＡＶ更新エンジン９５０内の該当する計算経路に向ける動的スケジューラおよびメモリコントローラを含めることにより、ＢＶＵモジュールの効率を高めることを実行者が自由に選択することができる。

ＮＡＶ計算はまた、出来高加重平均価格（ＶＷＡＰ）などの導出された統計データに基づき、売買された出来高の差など、メッセージ内の利用可能なことがある他のフィールドを使用するように、論理回路がＢＶＵモジュールに追加されることができることも留意されるべきである。

本発明の一実施形態の実行者により望まれる場合、コプロセッサ１４０は、ＢＣＥの計算の他の計算を行うように構成されることができることにも留意されるべきである。たとえば、コプロセッサ１４０はまた、上記で参照され組み込まれた米国特許出願第１１／７６５，３０６号に記載されているように、最終価値キャッシング（ＬＶＣ）モジュールを利用することもできる。

本発明の一実施形態の実行者は、Δｊに対する値を計算するが、ＮＡＶ^ｎｅｗに対する値は計算しないように選択することがあることは留意されるべきである。この場合、ＢＶＵモジュールは、どんなＮＡＶ^ｎｅｗ値も生成する必要がない。そのような例では、ＰＥＴモジュール１２００により使用されるトリガ条件は、ＮＡＶ^ｎｅｗではなくΔｊの変動を中心に作り上げられることができる。そのような状況では、顧客は、任意選択でΔｊ値からＮＡＶ値自体を決定することができるが、実行者は、古いＮＡＶ値と実際に組み合わせて、新しいＮＡＶ値を見つけるほかに、Δｊ値自体に価値を見いだすことがある。

また、ＶＡＬモジュール５０２のための好ましい実施形態は、入力メッセージ内の終値／買い呼値／売り呼値に対する差分値を計算するように構成されるが、そのような差分値の計算は、ＢＡＬモジュール５０２から上流の１つ以上のモジュール、またはＢＣＥパイプライン全体により任意選択で行われることができることは留意されるべきである。したがって、ＢＣＥパイプライン５００への入力メッセージは、対象の金融商品に対するΔ買い呼値、Δ売り呼値、および／またはΔ終値を既に含むことがある。そのような例では、表６０８は、金融商品ごとの以前の買い呼値／売り呼値／終値を記憶する必要がなく、ＢＡＬモジュール５０２は、これらの差分価格を計算するために必要な論理回路を利用する必要がない。

さらに、本明細書で開示された好ましい実施形態では、コプロセッサ１４０は、ＦＰＧＡなどの再構成可能論理デバイス１０２を含むが、コプロセッサ１４０は他の処理デバイスを使用して実現されることができることは留意されるべきである。たとえば、コプロセッサ１４０は、グラフィックプロセッサユニット（ＧＰＵ）、汎用グラフィックプロセッサ、チップマルチプロセッサ（ＣＭＰ）、専用メモリデバイス、複合プログラム可能論理デバイス、特定用途向け集積回路（ＡＳＩＣ）、および他の入出力処理構成部品を含むことがある。さらに、システム１００は、直列および並列のマルチコプロセッサアーキテクチャのいずれか、または両方で、複数のコプロセッサ１４０を利用することがあることは留意されるべきである。

なおさらに、本明細書で開示されたパイプラインを使用して、金融情報を処理し、かつ金融商品バスケットに対する更新された値を計算することに関して特別な利点があると本発明者は思っているが、開示されたパイプラインはまた、バスケットに関係する非金融データを処理するときにも、遅延の利点を提供することを本発明者はさらに注目する。たとえば、バスケット計算エンジンは、多国籍小売企業により行われる在庫品の純資産価値を計算するように構成されることがある。したがって、パイプラインへの製品販売および／または製品出荷に対応する入力イベントが、製品ごとに記憶された値を更新するために使用されることができる。ここで、これらの記憶された値は、在庫品カウント値に対応する。製品ごとに割り当てられた加重は、製品に割り当てられた価格値に対応する。したがって、本明細書で開示されたパイプラインのようなパイプラインが、企業の製品の純棚卸評価額を正確に追跡するために使用されることができる。次に、棚卸評価額が所与のしきい値だけ上がるまたは下がるときに、経営者に通知するためにトリガが使用されることがある。

別の例が、ある種の科学実験によるデータ点の集合であるバスケットに関するものである。各データ点は、サイズ、質量などの関連する値を有することがあり、これらのデータ点は、１つ以上の監視場所からストリーミングデータとして時間をかけて到達することがある。パイプラインは、入力データ列からサイズの加重和を計算することによりサイズＮＡＶを、および／または入力データ列から質量の加重和を計算することにより質量ＮＡＶを導出するように容易に構成されることができる。

本発明はその好ましい実施形態に関して上記に説明されたが、それに対して本発明の範囲内に依然として収まる様々な修正が加えられてもよい。本発明に対するそのような修正は、本明細書の教示を検討することで知り得る。したがって、本発明の範囲全体が、添付の特許請求の範囲、およびその法的均等物のみにより定義されるものである。

Claims (99)

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. 更新されたバスケット価値を顧客に報告する装置であって、
    （ｉ）バスケットイベントを受信し、バスケットイベントがバスケットに対するバスケット識別子、およびバスケットに対する更新された純資産価値（ＮＡＶ）を含み、（ｉｉ）バスケット識別子に基づいてバスケットに対する参照値を取り出し、（ｉｉｉ）取り出された参照値と更新されたＮＡＶの相違点を決定し、（ｉｖ）バスケット識別子に基づいてバスケットに対するトリガしきい値を取り出し、（ｖ）取り出されたトリガしきい値と相違点を比較して、それにより、更新されたＮＡＶが顧客に報告されるべきかどうかを決定し、（ｖｉ）更新されたＮＡＶが顧客に報告されるべきであるという決定に応答して、更新されたＮＡＶを顧客に報告するように構成されるプロセッサを備える、装置。

Images