JP2016164805A - 分配型サーバ側デバイスアーキテクチャ - Google Patents

Abstract

【課題】電子取引方法を提供する。【解決手段】取引戦略デバイスにおいて、顧客デバイスから複数の呼び値のレッグを有する親取引戦略を備える取引戦略注文を受信する工程と、取引戦略注文を複数の子注文に分割する工程と、子注文における呼び値のレッグを約定するように構成された交換システムに対して、複数の子注文のそれぞれを提出する工程とを含む。それぞれの子注文は、単一の、又は親取引戦略と比較して低減された数の呼び値のレッグを有する子取引戦略を備える。子取引戦略は、呼び値のレッグとされるレッグの数を除き、親取引戦略と同じである。この方法は、顧客デバイスと複数のサーバ側デバイスとの間に配置された取引戦略デバイスによって実施されても良い。【選択図】図４Ａ

Description

本出願は、２０１０年７月１４日に出願された米国特許出願第１２／８３６４９０号に対して優先権を主張する。この米国特許出願の内容は、参照することによりその全体が本明細書に組み込まれる。

本出願書類は電子取引に関する。特に、組織化された電子取引システム内における証券や商品といった取引可能オブジェクトの取引あるいは交換に関する。

取引可能オブジェクトを電子的に売り買いするために、電子取引システム（「取引システム」）が用いられる場合がある。取引可能オブジェクトは単に、取引されうる全てものである。取引可能オブジェクトは例えば、これらに限らないが、デリバティブや前述の収集物（collections of the foregoing）と同様に、株、オプション、債券（bond）、先物、通貨、契約（contract）、ワラント、現金（funds）および商品など、あらゆる種類の取引品であっても良い。

典型的には、取引システムは電子交換システムを備える。電子取引プロセスの間、ユーザ（例えば、取引デバイスを使用するトレーダ）は、取引可能オブジェクトのための取引注文を電子取引所に提出する。電子取引所は、取引注文（又はその一部）が１つ以上の反対側（contra-side）の取引注文と照合されるようにして、注文のマッチングを行う。例えば、売り注文は同じ価格の買い注文と反対側にある。同様に、売り注文は同じ価格の買い注文と反対側にある。取引注文が照合され又は交換注文一覧（exchange order book）から取り除かれるまで、照合されていない取引注文は交換注文一覧内に保持される。

取引注文のマッチングに加えて、電子取引所は一般的に、市場データおよび取引確認データを契約している取引デバイスへ提供するように構成される。市場データには、内部市場、市場深度、又は以前の若しくは係属中の取引可能オブジェクトのための取引に関する情報が含まれても良い。内部市場は、ある特定の時点での市場における最も低い売り価格かつ最も高い買い価格である。市場深度とは、ある特定の価格の取引可能オブジェクトのために出された取引注文の数をいう。

本明細書に記載された発明には、これらに限らないが、様々なデバイス、システム、方法およびコンピュータプログラム製品が含まれる。この欄では、発明のごく一部が要約されている。

例示的な電子取引システムにおいて、取引戦略デバイスは、顧客デバイスおよび複数（例えば、２つ以上）のサーバ側デバイスに通信するようにして顧客デバイスと複数のサーバ側デバイスとの間に配置される。それぞれのサーバ側デバイスは、注文を１つ以上の電子交換システムとともに取り扱うように構成される。注文の取り扱いには、これらに限らないが、注文の生成、注文の提出、注文の再値付け、注文のキャンセル、注文の送信、注文の管理又はこれらのあらゆる組み合わせが含まれても良い。

運転中において、取引戦略デバイスは、顧客デバイスから１つ以上の取引戦略注文を受信する。取引戦略注文は例えば、取引戦略を売る又は買う命令の１つ以上の側面を定義する。例として、取引戦略注文などの取引注文には、これらを必ず含む必要はないが、コンフィギュレーションデータ、価格データ、数量データ又はこれらのあらゆる組み合わせが含まれても良い。コンフィギュレーションデータは例えば、取引されるべき取引可能オブジェクトや取引戦略若しくは実行されるべき動作（例えば、売り又は買い）の種類を定義するデータ、又はその他のコンフィギュレーションデータである。取引可能オブジェクトは単に、取引可能な全てのものである。例えば、取引可能オブジェクトは、これらに限らないが、デリバティブや前述の収集物と同様に、株、オプション、債券、先物、通貨、契約、ワラント、現金および商品など、あらゆる種類の取引品であっても良い。取引戦略は例えば、取引される２つ以上の取引可能オブジェクト間の関係を定義する。価格データは例えば、取引される取引可能オブジェクトや取引戦略のための価格や価値を定義する。数量データは例えば、取引される１単位の取引可能オブジェクトや取引戦略の数や数量を定義する。例えば、数量データは、売られる又は買われる契約の数を定義する。

取引戦略注文が受信されると、取引戦略デバイスはデータを処理するとともに、取引戦略が複数の呼び値のレッグを有するかどうかを識別する。取引戦略が複数の呼び値のレッグを有する場合には、取引戦略デバイスは複数の取引戦略子注文（「子注文」）を生成して、１つ以上のサーバ側デバイスへ送る。それぞれの子注文は、単一の又は（例えば取引戦略注文と比較して）低減された数の呼び値のレッグを有する子取引戦略に関連付けられる。さらに子取引戦略は、呼び値のレッグとされるレッグの数を除き、取引戦略注文に関連付けられる取引戦略と同一又は類似する。子注文のサーバ側デバイスへのルートは、例えば待ち時間、１つ以上のサーバ側デバイスや１つ以上の交換システムの物理的位置、トレーダの好み、交換能力、その他の基準、あるいはこれらのあらゆる組み合わせに基づき、知的に決定されても良い。例えば、子注文を、最も近くに配置されたサーバ側デバイスや、子注文を約定するよう構成された電子交換システムへの待ち時間が最も短いサーバ側デバイスへ送るようにしても良い。子注文に基づき、サーバ側デバイスは呼び値の注文を生成する。呼び値の注文はそれぞれの交換システムに提出されても良い。それぞれの交換システムは、呼び値の注文のマッチングを行うことができる。

例示的な方法においては、コンピューティングデバイスが、複数の呼び値のレッグを有する取引戦略のための取引戦略注文を受信する。コンピューティングデバイスは、取引戦略注文が複数の呼び値のレッグを有する取引戦略のためのものであることを決定する。取引戦略注文が複数の呼び値のレッグを有する取引戦略のためのものであるとの決定に応じて、コンピューティングデバイスは複数の子注文を生成する。それぞれの子注文は、取引戦略注文よりも少ない数の呼び値のレッグを有する。コンピューティングデバイスは、複数の子注文を１つ又は２つ以上のサーバ側デバイスへ提出しても良い。

例示的なコンピュータ読み取り可能媒体においては、コンピュータ読み取り可能媒体は、プロセッサによって実行可能な命令が内部に保存されている。その命令は、複数の呼び値のレッグを有する取引戦略に関連付けられる取引戦略注文を受信し、取引戦略が複数の呼び値のレッグを有する取引戦略に関連付けられていることを決定し、複数の子注文を生成し、取引戦略注文よりも少ない数の呼び値のレッグをそれぞれが有する子注文を複数生成し、マッチングのために複数の子注文を提出するようにして、実行可能である。それぞれの子注文は、取引戦略注文よりも少ない数の呼び値のレッグを有する。

別の例示的な方法においては、 取引戦略デバイスは、複数の呼び値のレッグを有する取引戦略による取引戦略注文を受信する。取引戦略デバイスは、取引戦略注文を複数の子注文に分割する。それぞれの子注文は、単一の呼び値のレッグを有する子取引戦略に関連付けられる。子取引戦略は、呼び値のレッグとされるレッグの数を除き、親取引戦略と同じである。取引戦略デバイスは、子注文における呼び値のレッグを約定するように構成された交換システムに対して、複数の子注文のそれぞれを提出する。

図面は例を示すものと理解されるべきである。したがって、本明細書に記載の各種発明は、図面に示された装置や手段に限るべきではない。さらに、同じ参照番号を有する図面は、同じ要素を示す。
電子取引システムの一例を示す図 取引戦略の一例を示す図 例示的な電子取引システムを用いた電子取引プロセスの一例を示す図 例示的な電子取引システムを用いた電子取引プロセスの一例を示す図 図１の電子取引システムを用いた電子取引プロセスの別の例を示す図 図１の電子取引システムを用いた電子取引プロセスの別の例を示す図 取引戦略注文の分割の一例を示す図 取引戦略注文の分割の別の例を示す図 取引戦略注文の分割のさらに別の例を示す図 取引戦略デバイスの一例を示す図 電子取引環境での取引のための例示的な方法のフローチャートを示す図 取引戦略注文のための注文を分割する例示的な方法のフローチャートを示す図

本明細書では、電子取引に関する多くの実施形態が示される。特に、多くの実施形態は、分配型サーバ側デバイスのアーキテクチャを用いた複数の呼び値のレッグを有する、取引戦略のための注文（「取引戦略注文」とも呼ばれる）に関する。顧客デバイスと複数のサーバ側デバイスとの間に配置された取引戦略デバイスは、取引戦略注文を、複数の子取引戦略注文に分けることができる。これらの子取引戦略注文は「子注文」とも呼ばれる。それぞれの子注文は、単一の又は少ない数の呼び値のレッグを有した小取引戦略にしたがう（例えば、最初の取引戦略注文）。子取引戦略は、呼び値のレッグの数を除くと、取引戦略注文における取引戦略と同じ又は実質的に同じである。したがって、それぞれの子注文は、単一の呼び値のレッグ又は取引戦略注文よりも少ない数の呼び値のレッグに関連する場合がある。取引戦略デバイスは、注文を交換システムとともに働かせるように構成されるサーバ側デバイスに子注文を送ることができる。サーバ側デバイスは子注文を受けて、子注文におけるそれぞれの呼び値のレッグ用の呼び値の注文を作り、その呼び値の注文を提出する。呼び値の注文は提出されて、交換システムとともに働く。

これから説明する前に、様々な発明はその応用として、前述又は後述の詳細な説明や図面に示される構成要素の設計や配置の詳細に限定されないことをここに再度記す。代わりに、前述又は後述の詳細な説明および図面は、独立している、あるいは互いに又は他の実施形態に組み合わされ得る各種発明の主な概念に着目する。

Ｉ． 電子取引システムの典型例について
図１は、電子取引システム（取引システム）１００のブロック図を示す。取引システム１００は、１つ以上の顧客システム１１０と、１つ以上のサーバ側デバイス１２０と、１つ以上の交換システム１４０とを備える。より詳細には図１に示すように、取引システム１００は、顧客システム１１０に加えて、サーバ側デバイス１２０ａ、サーバ側デバイス１２０ｂ、ゲートウェイ１３０ａ、ゲートウェイ１３０ｂ、交換システム１４０ａおよび交換システム１４０ｂを備える。顧客システム１１０は、顧客デバイス１１２と、取引戦略デバイス１１４とを備える。他の取引システムにおいては、付加的な、異なる、あるいは少ない数の構成要素が設けられる。システム１００は例えば、「Ｎ」個の顧客システム、「Ｎ」個のサーバ側デバイス、「Ｎ」個のゲートウェイ、「Ｎ」個の交換システム、あるいはこれらの任意の組み合わせを備えても良い。すなわち、システム１００は複数のシステムや構成要素を備えるように、拡大縮小可能である。

顧客システムについて
顧客システム１１０は、サーバ側デバイス１２０、ゲートウェイ１３０、交換システム１４０あるいはこれらの組み合わせと、例えば１つ以上の通信ネットワーク１０２を介して通信を行う。例えば図１に示すように、顧客システム１１０は、通信ネットワーク１０２ａを介してサーバ側デバイス１２０ａおよびゲートウェイ１３０ａと接続され通信を行う。同様に、顧客システム１１０は、通信ネットワーク１０２ｂを介してサーバ側デバイス１２０ｂおよびゲートウェイ１３０ｂと接続され通信を行う。通信ネットワークには例えば、１つ以上の通信バス、Ｔ１回線、Ｔ３回線、サービス総合デジタル網（ＩＳＤＮ）回線、有線ネットワーク、無線ネットワーク、ＰＯＰネットワーク、ローカルネットワーク、遠隔ネットワーク、インターネット、あるいはこれらの任意の組み合わせが含まれる。

「接続」との用語には、直接的に接続される場合や、１つ以上の中間構成要素を介して間接的に接続される場合が含まれる。またそのような中間構成要素には、ハードウェア（例えばサーバ、ルータ、ゲートウェイ、スイッチなど）、ソフトウェア（例えば取引アプリケーションや通信アプリケーションなど）、付加的な通信ネットワーク、あるいはこれらの任意の組み合わせが含まれる。

顧客システム１１０の全て又はそのいくつかは、１つ以上のサーバ側デバイス１２０、ゲートウェイ１３０、交換システム１４０、あるいはこれらの組み合わせと物理的に同じ場所に配置されても良く、あるいは異なる場所に配置されても良い。例えば、ウィスコンシン州のミルウォーキー郡にあるオフィスビルに、顧客システム１１０の全体を物理的に配置しても良い。しかしながら、サーバ側デバイス１２０ａ、ゲートウェイ１３０ａおよび交換システム１４０ａを物理的にイリノイ州のシカゴやその周辺に配置し、サーバ側デバイス１２０ｂ、ゲートウェイ１３０ｂおよび交換システム１４０ｂを物理的に日本の東京に配置するようにしても良い。別の例では、分配型の顧客システム１１０および顧客デバイス１１２がウィスコンシン州のミルウォーキー郡にあるオフィスビルに物理的に配置され、取引戦略デバイス１１４がイリノイ州のシカゴやその周辺に配置される場合を示す。

上述のように、顧客システム１１０は、顧客デバイス１１２と取引戦略デバイス１１４とを備える。顧客システム１１０は、サーバ、ゲートウェイ、ルータ、スイッチ、コンピュータ、顧客デバイス、取引戦略デバイス、アプリケーションあるいはその他の通信デバイスなど、付加的な、異なるあるいは少ない数の構成要素を備えても良い。例えば、顧客デバイスが複数あっても良い。複数の顧客デバイスの全て又はそのいくつかが同じ取引戦略デバイスを使用するようにしても良い（例えば、顧客デバイスと取引戦略デバイスとが多対一）。別の例においては、顧客デバイスが複数設けられる一方で、それぞれの顧客デバイスが単一の取引戦略デバイスを使用している（例えば、顧客デバイスと取引戦略デバイスとが一対一）。

顧客デバイスについて
顧客デバイス１１２は、携帯用デバイス、ラップトップコンピュータ、デスクトップコンピュータ、サーバ、パソコン、通信エンドポイント、電子取引ワークステーション、コンピュータ・デバイス、ポータブル取引デバイス、アルゴリズム取引システム又は「ブラックボックス」システム、組込型取引システム、自動取引ツール、あるいはこれらの任意の組み合わせであっても良い。顧客デバイス１１２は、ユーザによって所有、操作、制御、プログラム、設定あるいはそれ以外の使用がされても良い。「ユーザ」との用語には、これらに限定されないが、人間（例えば、トレーダー）や電子取引デバイス（例えば、プロセッサとメモリあるいはアルゴリズム取引システムなどが含まれる）が含まれても良い。１以上のユーザが所有、操作、制御、プログラミング、設定あるいはその他の使用に従事しても良い。

顧客デバイス１１２は、市場データを受信し又は表示し、あるいは受信するとともに表示しても良い。市場データは、交換システム１４０ａ又は交換システム１４０ｂなどの交換システムから受信されても良い。市場データには、共通して１つ以上の取引可能オブジェクトに関する情報を有する市場情報が含まれても良い。市場データには、呼び値のデータ（例えば、買い／売りの呼び値データ、買い／売りの数量データ、市場深度データなど）、取引データ（例えば、最終売りデータ、最終数量データ、最終量データ）、確認（コンファメーション）データ（例えば、約定確認、取引確認など）、その他の交換関連データ、あるいはこれらの任意の組み合わせが含まれても良い。市場データには、これらに限定されないが、各種取引可能オブジェクトの価格、様々な所定の時間における取引可能オブジェクトの買いの量、どのような量および／又は価格のときに何の取引が生じたかを示す取引確認、あるいは取引が約定されたことを示す約定確認が含まれても良い。

市場データには例えば、場内市場を示すデータが含まれても良い。場内市場は、ある特定の時点における一番安い売り値又は売り出し価格（「一番安い指値価格（best ask）」ともいう）並びに、ある特定の時点における一番高い買い値又は入札価格（「一番高い指値価格(best bid)」ともいう）である。市場データには市場深度データが含まれても良い。市場深度は、ある時点におけるある価格の取引可能オブジェクトに対する取引注文の数のことをいう。交換システム１４０によって顧客システム１１０又は異なるシステムのいずれかからの取引注文が受信されるときに、市場深度は変化する場合がある。ある実施形態では、市場深度は全ての価格レベルにおいて存在するが、他の実施形態では、それよりも少ない数の価格レベルにおいて存在する。市場データには、最終取引価格（ＬＴＰ）、最終取引数量（ＬＴＱ）およびその他の約定情報等が含まれても良い。

顧客デバイス１１２は１つ以上の入力部を備えても良い。入力部は例えば、入力デバイスやネットワークインタフェース、あるいはその両方であっても良い。入力部は、市場データ、ユーザ入力データ、市場データとユーザ入力データの両方、その他の取引データ（例えば、識別、パスワード、アルゴリズムなど）、あるいはこれらの組み合わせを受信するようにしても良い。ユーザ入力データには、１つ以上の取引可能オブジェクトの定義などのユーザからの受信データが含まれても良い。

例示的な入力デバイスは例えば、マウス、キーボード、トラックボール、タッチスクリーン、ジョイスティック、タッチパッド、ユーザインタフェース、マイクロホン、ボタン、ノブ、スライダ、これらの組み合わせ、あるいはその他の現在知られた又は最近開発されたユーザ入力デバイスを備える。例えば、入力デバイスは、ユーザインタフェースである。ユーザインタフェースは、ユーザによる取引画面との接触を可能にするアプリケーション・プログラミング・インタフェースであっても良い。ユーザインタフェースは、取引アプリケーションにおけるテキスト又はグラフィカルのインタフェースをユーザに表示する１つ以上の表示デバイスに関連付けられても良い。表示デバイスは、コンピュータモニタ、ハンドヘルドデバイス表示装置、プロジェクタ、および／又はテレビであっても良い。ある例では、ユーザインタフェースは市場データを表示し、別の例では、ユーザインタフェースは、自動化された取引戦略を構築するためにブロックや接続線を用いて取引戦略をプログラミングするシステムをユーザがソースコードを理解していなくとも簡単に使用できるようにしている。さらに別の例では、ユーザインタフェースは、ユーザが取引アプリケーションを用いて注文に関するパラメータを特定又は検討するために用いられる。ネットワークインタフェースには、配線で接続された又は無線のネットワークインタフェースが含まれても良い。万能非同期送受信機（ＵＡＲＴ）、パラレルデジタルインタフェース、ソフトウェアインタフェース、イーサネット、あるいは既に知られている又は最近開発されたソフトウェアインタフェースおよびハードウェアインタフェースを各種組み合わせたものを用いても良い。ネットワークインタフェースは、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、インターネット、および仮想プライベートネットワーク（ＶＰＮ）を含む各種ネットワークにリンクされても良い。

顧客デバイス１１２は１つ以上の取引可能オブジェクトを売る又は買うために用いられても良い。取引可能オブジェクトは「実際」あるいは「合成」のものであっても良い。実際の取引可能オブジェクトは、交換によってリストされる製品である。合成の取引可能オブジェクトは、ユーザによって定義され、交換によってはリストされない製品である。例えば、合成の取引可能オブジェクトには、トレーダによって顧客デバイス１１２を用いて作り出された合成スプレッドなどの実際（又はその他の合成）の製品を組み合わせたものも含まれる。合成の取引可能オブジェクトは、例えば１つ以上の実際の取引可能オブジェクトから暗示される取引可能オブジェクトのように、暗示されても良い。

顧客デバイス１１２は１つ以上の電子コンピューティングプラットフォームを備えても良い。一般的な電子コンピューティングプラットフォームは、プロセッサと、プロセッサによって実行される命令を保存するコンピュータ読み取り可能媒体とを備える。その他の電子ンピューティングプラットフォームには、コンピューティングデバイスや処理コンポーネントなどが用いられても良い。

取引の目的に応じて、顧客デバイス１１２は１つ以上の取引アプリケーションを備えても良い。取引アプリケーションは例えば、取引およびチャートのウィンドウに市場データを配列および表示することで、市場データを処理しても良い。例えば、取引アプリケーションを用いることで、ユーザは取引可能オブジェクトを定義するとともに、定義された取引可能オブジェクトに対する注文を提出することができる。この処理はユーザの好みに基づいても良い。１つ以上の取引アプリケーションはコンピュータ読み取り可能媒体に保存された１つ以上の命令を有しても良い。電子コンピューティングプラットフォームは、本明細書に説明、例示又は図示される１つ以上の機能を行うように取引アプリケーションを実行しても良い。

取引アプリケーションは自動取引ツールを備えても良い。一例として、顧客デバイス１１２は、イリノイ州シカゴのＴｒａｄｉｎｇ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｉｎｔｅｒｎａｔｉｏｎａｌ社が提供する電子取引プラットフォームであるＸ＿ＴＲＡＤＥＲ（登録商標）のコピーを実行するワークステーションであっても良い。別の例として、顧客デバイス１１２は、同じくＴｒａｄｉｎｇ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｉｎｔｅｒｎａｔｉｏｎａｌ社が提供するＡｕｔｏｓｐｒｅａｄｅｒ（登録商標）などの自動取引ツールを実行するサーバであっても良い。

取引戦略デバイスについて
取引戦略デバイス１１４は、ハンドヘルドデバイス、ラップトップコンピュータ、デスクトップコンピュータ、サーバ、パソコン、エンドポイント、電子取引ワークステーション、コンピューティングデバイス、携帯取引デバイス、アルゴリズム取引システム又は「ブラックボックス」システム、組込型取引システム、自動取引ツール、あるいはこれらの任意の組み合わせであっても良い。取引戦略デバイス１１４は例えば、管理デバイス、モニタデバイス、分割デバイス、もしくは注文エントリデバイスともいう。

取引戦略デバイス１１４は顧客デバイス１１２と物理的に同じ場所又は異なる場所に配置されても良い。例えば、取引戦略デバイス１１４は顧客デバイス１１２と物理的に同じオフィス又は同じビルに配置されても良い。図１に示すように、顧客デバイス１１２および取引戦略デバイス１１４は異なるデバイスであっても良い。しかしながら、他の例では、顧客デバイス１１２および取引戦略デバイス１１４は、単体のユニットとして機能する同一のデバイスであっても良い。例えば、取引戦略デバイス１１４は顧客デバイス１１２に組み込まれても良い。「組み込まれ」との用語には、同一のプロセッサ、メモリ、又はその両方を用いることや、同一の筐体又は接続された筐体を有すること、それ以外に互いに結合又は操作されることが含まれる。

しかしながら、取引戦略デバイス１１４の物理的な位置は取引システム１００に応じて変更しても良い。例えば、各種実施形態では、取引戦略デバイス１１４は、１つ以上のサーバ側デバイス１２０、ゲートウェイ１３０、交換システム１４０、あるいはこれらの組み合わせと物理的に同一の場所又は異なる場所に配置される。例えば、取引戦略デバイス１１４はサーバ側デバイス１２０に組み込まれても良い。別の例では、取引戦略デバイス１１４は、交換システム１４０と通信するゲートウェイ１３０に組み込まれても良い。

取引戦略デバイス１１４は１つ以上の電子コンピューティングプラットフォームを備えても良い。電子取引の目的に応じて、取引戦略デバイス１１４は１つ以上の取引アプリケーションを備えても良い。１つ以上の電子コンピューティングプラットフォームは、顧客デバイス１１２が本明細書に説明、例示又は図示される１つ以上の機能を実施するように、１つ以上の取引アプリケーションを実行するようにしても良い。例えば、取引アプリケーションは、図４、９、１０に示される行為のうち１つ、いくつか又は全てを実施するように実行されても良い。

取引戦略デバイス１１４は、１つ以上の取引注文を送信および受信しても良い。例えば、取引戦略デバイス１１４は顧客デバイス１１２から取引戦略注文を受け取るとともに、１つ以上の子取引戦略注文をサーバ側デバイス１２０に送信しても良い。

取引戦略注文又は子取引戦略注文などの取引注文は、あらゆるコンフィギュレーションデータ、価格データ、数量データ、又はこれらのあらゆる組み合わせを含んでも良い。取引注文は、呼び値の注文を行うのに必要な情報の全て、その情報の全てよりも少ない情報、その情報の全てよりも多い情報、あるいはこれらの組み合わせを含んでも良い。取引注文内の情報量は例えば、情報を受信するコンポーネント、呼び値の注文をするのに必要な情報量、すでに送信された情報量、これらの組み合わせ、あるいはその他の事項に依存するようにしても良い。

例えば、いくつかの実施形態では、取引注文は価格データおよび数量データを含むが、必ずしもコンフィギュレーションデータを含まない。すなわち、コンフィギュレーションデータは例えば、最初に取引戦略デバイス又はサーバ側デバイスに送信される価格データおよび数量データとともに、又はそれらに先立って送信されても良い。コンフィギュレーションデータは例えば、取引戦略デバイス又はサーバ側デバイスに保存されても良い。コンフィギュレーションデータがすでに取引戦略デバイス又はサーバ側デバイスにある場合、次の価格データおよび数量データをコンフィギュレーションデータと組み合わせても良く、あるいはコンフィギュレーションデータとともに用いても良い。コンフィギュレーションデータに変化が生じた場合、その変化の直後の取引注文の価格データおよび数量データに先立って又はそれらとともに、アップデートされたコンフィギュレーションデータが送信されても良い。その他の実施形態では、取引注文は価格データを含むが、必ずしも質量データを含まない。すなわち、例えば、価格データは、質量データに先立って、質量データとともに、あるいは質量データよりも後に送信されても良い。

取引戦略デバイス１１４は１つ以上の顧客デバイス１１２を管理するよう構成される。例えば、取引戦略デバイス１１４は、複数の顧客デバイス１１２に接続されることが可能である。顧客デバイス１１２は、取引戦略デバイス１１４に注文を送信しても良い。取引戦略デバイス１１４は、注文を受信するとともに注文の提出を管理するよう構成されても良い。注文の管理には、注文の提出に関する取扱い（working）、操作、移動、支配、制御、完遂への試み、完遂への成功が含まれても良い。後で詳細に説明するように、管理には、顧客デバイス１１２から受信した注文の分割が含まれても良い。

サーバ側デバイスについて
サーバ側デバイス１２０は、サーバ、ゲートウェイ、パソコン、その他の現在知られている又は最近開発された通信デバイス、あるいはこれらの組み合わせであっても良い。例えば、サーバ側デバイスは、Ｔｒａｄｉｎｇ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｉｎｔｅｒｎａｔｉｏｎａｌ社が提供するＡｕｔｏｓｐｒｅａｄｅｒ（登録商標）などの自動取引ツールを実行するサーバであっても良い。自動取引ツールは顧客デバイス１１２用いて制御されても良いが、サーバは交換システム１３０に、その周囲に、又はその近辺に物理的に配置されても良い。

通信の目的に応じて、サーバ側デバイス１２０ａは取引戦略デバイス１１４および交換システム１４０ａに接続される。サーバ側デバイス１２０ｂは取引戦略デバイス１１４および交換システム１４０ｂに接続される。例えば、サーバ側デバイス１２０は、交換システム１４０と通信するゲートウェイを有しても良く、あるいはそのゲートウェイに接続されても良い。ゲートウェイはプロトコル変換を実行しても良い。

サーバ側デバイス１２０は交換システム１３０に、その近辺に、あるいはその中に物理的に配置される。サーバ側デバイスは、呼び値の注文を取り扱う交換システムに、その近辺に、あるいはそれぞれの交換システムの中に配置されても良い。すなわち、分配型サーバ側デバイスのアーキテクチャは、異なる交換システムに２つ以上のサーバ側デバイスが分配されたシステム又は環境である。単一のサーバ側デバイスが複数の交換システムにおいて呼び値の注文を取り扱う必要がないように、サーバ側デバイスは交換システムとともに呼び値の注文を取り扱う。

サーバ側デバイス１２０は、Ｔｒａｄｉｎｇ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｉｎｔｅｒｎａｔｉｏｎａｌ社が提供する自動取引ツールであるＡｕｔｏｓｐｒｅａｄｅｒ（登録商標）を実行する自動取引サーバであっても良い。自動取引サーバは、金融情報交換（Ｆｉｎａｎｃｉａｌ Ｉｎｆｏｒｍａｔｉｏｎ ｅＸｃｈａｎｇｅ（ＦＩＸ））ゲートウェイなどのゲートウェイを介して交換システム１４０と通信しても良く、あるいは交換システムと直接通信するようにしても良い。自動取引サーバおよびＦＩＸゲートウェイは、例えば電子取引の速度および効率を増やすために、交換システムの近傍の場所に配置されても良い。

サーバ側デバイス１２０は、取引戦略デバイス１１４からの１つ以上の取引可能オブジェクトを売買する注文を受信するとともに、注文を約定させるための交換システムにその注文を提出するようにしても良い。したがって、サーバ側デバイスは、交換システムとともに注文を取り扱うよう構成されても良い。注文の取り扱いには、注文の提出、注文の再値付け、注文のキャンセル、ヘッジ注文の送信、未処理注文の管理、あるいはこれらのあらゆる組み合わせが含まれても良い。未処理注文とは、交換システムに提出されたものの未だ約定していない注文のことである。すなわち、交換システムは、未処理注文のうちの全て又はそのいくつかを反対側（contra-side）の注文とマッチング（照合）することを試みる。未処理注文の管理には例えば、顧客デバイスへの報告、市場最新情報の追跡、それ以外にも、１つ以上の取引機能の実行が含まれる。

交換システムについて
交換システム１４０は、同一の又は異なる金融取引所（例えば、シカゴマーカンタイル取引所およびシカゴ商品取引所）によって所有、操作、制御又は使用されても良い。以降で詳細に説明するように、交換一ステムは注文を受信および約定するために用いられても良い。交換システム１４０は、同一の又は異なる交換の一部であっても良い。

交換システムは、注文をマッチングするよう構成される。例えば、交換システムは、マッチングエンジンを備えても良い。マッチングエンジンは注文をマッチングするように構成されても良い。特に、マッチングエンジンは、買い値および売り出し価格をマッチングするように構成される。マッチングエンジンは、買いおよび売り出しをマッチングするための１つ以上のアルゴリズムを実行するソフトウェアで動作されても良い。交換システム１３０は、注文が約定したときに約定確認を提供するように構成されても良い。約定確認は例えば、サーバ側デバイス１２０に提供されても良い。

交換システム１３０は、付加的な、異なる又は少数のコンポーネントを備えても良い。例えば、取引を識別する情報および取引の説明を保存するために、取引データベースが備えられても良い。取引データベースは、取引が生じた時間と約定価格を識別する情報を保存しても良い。最新の買い値および売り出し価格を計算あるいは決定するために、注文一覧モジュールが備えられても良い。市場データを収集し、ユーザへの送信用データを準備するために、市場データモジュールが備えられても良い。ユーザの明確な危険閾値に関して、ユーザのリスク利用を計算および決定するために、リスク管理モジュールが備えられても良い。注文一覧モジュールおよびマッチングエンジンによる処理用として、変化しやすい金融派生商品を分解するとともに注文の種類を集計するために、注文処理モジュールが備えられても良い。

交換システム１３０は市場データを提供するよう構成されても良い。市場データは、例えば１つ以上のゲートウェイを介して、顧客デバイス１１２へ提供されても良い。別の例では、交換システム１３０は市場最新情報を提供する。市場最新情報には、市場における変化（例えば、価格の変化）、部分的な約定（partial fills）、又は未処理の注文に影響する可能性があるその他の最新情報が含まれても良い。市場最新情報は例えば、サーバ側デバイス１２０又は未処理の注文を管理するその他のデバイスに提供されても良い。

注文が約定すると、交換システム１３０は、例えば約定確認を送信することで約定を知らせても良い。約定確認はサーバ側デバイス１２０に送信されても良い。例えば、交換システム１４０ａが注文をマッチングする場合に、約定確認をサーバ側デバイス１２０ａに送信しても良い。次に、約定確認はその他のコンポーネントに送信される。例えば、約定確認は顧客デバイス１１２および／又は取引戦略デバイス１１４に送信されても良い。あるいは、又は、さらに、約定確認は取引戦略デバイス１１４又は顧客デバイス１１２に送信されても良い。

明確化のために図示していないが、システム１００は、ミドルウェア、ファイアウォール、ハブ、スイッチ、ルータ、ゲートウェイ、交換に特化した通信装備、モデム、セキュリティマネージャ、および又は暗号化／復号化デバイスなどの通信アーキテクチャに固有な他のデバイスを備えても良い。

戦略取引
ユーザは、１つの取引可能オブジェクトの売りおよび／又は買いに加えて、取引戦略に基づいて１つよりも多くの取引可能オブジェクトを取引するように、顧客デバイス１１２を利用しても良い。取引戦略は、取引される２つ以上の取引可能オブジェクト間の関係を定義する。取引戦略の一部として取引されるそれぞれの取引可能オブジェクトは、取引戦略のレッグ又はアウトライト市場とも呼ばれる。１つの共通な取引戦略はスプレッドであり、スプレッドによる取引はスプレッド取引と呼ばれる。スプレッド取引は、取引戦略内の取引可能オブジェクト間の関係の変化又は移動から利益を得ることを目指すものである。

取引戦略が買われるときには、取引戦略における定義が、それぞれのレッグに対応するどの取引可能オブジェクトを買う又は売るべきかを特定する。同様に、取引戦略が売られるときには、その定義が、それぞれのレッグに対応するどの取引可能オブジェクトを買う又は売るべきかを特定する。例えば、取引戦略を買うことに、レッグＡの第１の取引可能オブジェクトを１単位買うことと、レッグＢの第２の取引可能オブジェクトを１単位売ることが含まれるように、取引戦略が定義されても良い。取引戦略を売ることには、それぞれのレッグに対して反対の行為を実行することが通常含まれる。

さらに、取引戦略における定義は、取引戦略のそれぞれのレッグに関連するスプレッド比率を特定しても良い。スプレッド比率は、レッグの注文サイズとも呼ばれる。スプレッド比率は、他のレッグに関連してそれぞれのレッグの数量を示す。例えば、取引戦略を買うことに、レッグＡの第１の取引可能オブジェクトを２単位買うことと、レッグＢの第２の取引可能オブジェクトを３単位買うことが含まれるように、取引戦略が定義されても良い。スプレッド比率の符号を用いることで、取引戦略を買うときにどのレッグを買う（スプレッド比率がプラス）又は売る（スプレッド比率がマイナス）べきか示すようにしても良い。上述の例では、レッグＡに関連するスプレッド比率は「２」でレッグＢに関連するスプレッド比率は「−３」である。いくつかの例では、スプレッド比率は暗示されても良く、又は暗示的であっても良い。例えば、取引戦略のレッグのスプレッド比率は明確に特定しなくても良く、むしろ「１」または「−１」であることが暗示、またはこれらにデフォルトされても良い。

さらに、取引戦略における定義は、取引戦略のそれぞれのレッグに関連する乗数を規定しても良い。乗数は、スプレッドの価格を決定するための特定のレッグの価格を調整するために用いられる。それぞれのレッグの乗数はスプレッド比率と同じであっても良い。例えば、上述の例では、レッグＡに関連する乗数は「２」で、レッグＢに関連する乗数は「−３」であって、両方の乗数がそれぞれのレッグの対応するスプレッド比率にマッチングしている。あるいは、１つ以上のレッグに関連する乗数は、それらのレッグの対応するスプレッド比率と異なっても良い。例えば、レッグの価格を共通通貨に変換するために、乗数の値を選択しても良い。

以降の議論においては、特に指定のない限り、それぞれのレッグのスプレッド比率および乗数が同じであるものとする。さらに、以降の議論においては、特定のレッグにおけるスプレッド比率および乗数の符号は同じとするが、そうでない場合には、乗数の符号は特定のレッグが取引戦略のどちら側にあるかを決定するために用いられる。

図２は、例示的な取引戦略２１０のブロック図を示す。取引戦略２１０は「Ｎ」個のレッグ２２０を有する。レッグは、取引可能オブジェクト、取引可能オブジェクトの注文、取引可能オブジェクトの潜在注文、取引可能オブジェクトに関連する取引の一部分を指す。そのため、レッグはアウトライトとも呼ばれる。

取引戦略２１０は、それぞれのレッグ２２０に関連するスプレッド比率２２４および乗数２２６を用いて、各レッグ２２０の取引可能オブジェクト２２２間の関係を定義する。定義されると、取引戦略２１０中の取引可能オブジェクト２２２は定義された関係に基づいて互いに取引される。

以降の議論においては、特に指定のない限り、それぞれのレッグのスプレッド比率２２４および乗数２２６が同じであるものとする。さらに、以降の議論においては、特定のレッグにおけるスプレッド比率２２４および乗数２２６の符号は同じとするが、そうでない場合には、乗数２２６の符号は特定のレッグが取引戦略のどちら側にあるかを決定するために用いられる。

ある例証（本明細書では「上述の例証」と呼ぶ）において、取引戦略２１０は２つのレッグ２２０を有するスプレッドである。レッグ１は取引可能オブジェクトＡに対応し、レッグ２は取引可能オブジェクトＢに対応する。レッグ１およびレッグ２に関連するスプレッド比率２２４および乗数２２６はそれぞれ「１」および「−１」であっても良い。スプレッド２１０は、スプレッド２１０が買われるときに、取引可能オブジェクトＡが１単位買われ（スプレッド比率がプラスかつ方向がスプレッドと同じ）、取引可能オブジェクトＢが１単位売られる（スプレッド比率がマイナスかつ方向がスプレッドと反対）ように定義されても良い。スプレッド取引においては、定義の反対のものが通常、適用される。例えば、スプレッド２１０は、スプレッド２１０が売られるときに、取引可能オブジェクトＡが１単位売られ（スプレッド比率がプラスかつ方向がスプレッドと同じ）、取引可能オブジェクトＢが１単位買われる（スプレッド比率がマイナスかつ方向がスプレッドと反対）ように定義される。

取引戦略２１０の価格は、取引戦略の提議に基づいて決定されても良い。取引戦略２１０の価格は通常、取引戦略２１０のそれぞれのレッグ２２０において取引可能オブジェクト２２２に乗数２２６を掛けて合計したものである。

上述の例証では、ユーザが取引可能オブジェクトＡの価格は通常、取引可能オブジェクトＢよりも１０高いと考えている場合においては、両オブジェクトの価格差が１０より小さい場合に常にユーザがスプレッドの買いを希望する場合があり、また両オブジェクトの価格差が１０より大きい場合に常にユーザが常にスプレッドの売りを希望する場合もある。一例として、取引可能オブジェクトＡが価格４５で、取引可能オブジェクトＢが価格４０であっても良い。現行のスプレッド価格は、（１）（４５）＋（−１）（４０）＝５となり、これは典型的なスプレッド１０より少ない。したがって、トレーダはスプレッドの１単位を買ってもよく、結果的に、取引可能オブジェクトＡの１単位が価格４５で買われ、かつ取引可能オブジェクトＢの１単位が価格４０で売られる。この通常の価格差が、取引可能オブジェクトＡの価格が４２、かつ取引可能オブジェクトＢの価格が３２等となって回復されれば、スプレッドの価格は１０になる。よって、スプレッドの１単位を売ってそのポジションを手仕舞えば（例えば、取引可能オブジェクトＡの１単位を売って、取引可能オブジェクトＢの１単位を買う）、総取引で利益が得られる。特に、トレーダは取引可能オブジェクトＡを価格４５で買いかつ４２で売って３の損失を出す一方で、取引可能オブジェクトＢを価格４０で売りかつ３２で買って利益８を得ている。このように、トレーダはスプレッドの売買により利益５を得ている。

なお上述の例証では、取引可能オブジェクトを市場価格にて、概ね所望の時間に売り買いすることができるという十分な流動性および安定性があるものとする。これにより、トレーダはスプレッド２１０の所望の価格を得ることができる。しかしながら、より一般的には、ユーザが特定の取引戦略を売り又は買いする際の所望の価格を決定する。自動取引ツールを用いると、例えば、レッグを適切な価格にて売り買いすることで、ユーザは所望の価格を得るように試みても良い。例えば、ユーザが取引戦略２１０を所望の価格にて売り若しくは買いする注文を入力すると、自動取引ツールは、取引戦略２１０の取引可能オブジェクト２２２のうちの１つが取引戦略における所望の価格（所望の戦略価格、所望のスプレッド価格、および／又は目標価格ともいう）を達成するように、自動的に注文を出すようにしても良く、これは、注文の値付け（quoting）ともいう。

注文が出されるレッグは呼び値のレッグともいう。その他のレッグは依存レッグ（lean leg）又はヘッジレッグともいう。呼び値のレッグが値付けされる価格は、注文がヘッジレッグにて約定されうる最良の価格に基づいている。最良の価格は、典型的には、売りの場合は最良の買い呼び値であり、買いの場合は最良の売り呼び値である。ヘッジレッグにおける最良の価格は、非依存価格（leaned on price）、依存価格（lean price）または依存レベルとしても知られる。非依存価格が変化すると、所望の戦略価格を維持するように、呼び値のレッグにおける注文のための価格も変化しても良い。呼び値のレッグが約定されると、ヘッジレッグにおける注文を提出し、戦略を完了しても良い。この注文は反対注文又はヘッジ注文ともいい、通常は、非依存価格にて値付けされる。非依存価格の注文が約定されない（あるいは所望の戦略価格を十分に達成できない）場合、トレーダは取引戦略の定義による所望の戦略関係を達成していないため、トレーダは「レッグドアップ（legged up）」した、と言われる。

取引戦略に応じて、値付けされるレッグの価格が、その他のレッグのうちの全て若しくはそのうちのいくつかに基づいても良い。別の例として、値付けされるレッグにおける注文の注文パラメータは、最終取引価格（ＬＴＰ）、最終取引数量（ＬＴＱ）、理論値、場内市場により近い数量等の複数数量、又は他の何らかの基準点等のように、他のレッグにおけるその他のタイプの市況に依存しても良い。

取引戦略は、複数（例えば、２つ以上、いくつか、又は全て）のレッグにおいて値付けされてもよい。このような状況では、値付けされるそれぞれのレッグは、他のレッグが呼び値のレッグであっても、依然として他のレッグに依存している。値付けされたレッグのうちの１つが約定されると、値付けされた他のレッグにおける注文は通常、キャンセルされるとともに、約定されたレッグが基づく非依存価格に基づいて、適切なヘッジ注文が出される。

取引戦略の売り買いを行うとき、ユーザは一般的に、取引戦略における目標価格の達成を望む。すなわち、トレーダは結果として特定の戦略価格を実現するために、取引戦略の定義に基づいて取引戦略の取引可能オブジェクトの売り買いを希望する。

取引戦略における目標価格を達成するために、市場の流動につれて、ヘッジレッグの流動価格に基づき１つ以上の呼び値のレッグを再値付けする必要がある可能性がある。例えば、第１の取引所にて取引されているヘッジレッグの価格が変動する場合に、第２の取引所にて呼び値のレッグにおける注文をキャンセルするとともに、呼び値のレッグの代わりの定義を有する代替注文により置換しても良い。呼び値のレッグの代わりの定義は通常、ヘッジレッグにおける新たな価格に基づく呼び値のレッグにおける新たな価格を示す。

図３Ａは、ヘッジレッグの流動価格に基づいて呼び値のレッグにおける注文を取り扱う一例を示す。注文を取り扱うために、図１のシステム１００における１つ以上の構成要素を有する場合がある取引システム３００が用いられる。取引システム３００は、交換システム１４０ａに、交換システム１４０ａの近くに、又は交換システム１４０ａ内にサーバ側デバイス１２０ａを備える。しかしながら、サーバ側デバイスは、交換システム１４０ｂに、交換システム１４０ｂの近くに、又は交換システム１４０ｂ内には配置されない。代わりに、サーバ側デバイス１２０ａは、交換システム１４０ａおよび交換システム１４０ｂの両方において呼び値の注文を取り扱うように構成される。取引システム３００は取引戦略デバイス１１４を備えていない。したがって、顧客デバイス１１２はサーバ側デバイス１２０ａに対して注文を提出する。

システム３００は、呼び値の注文を取り扱うために単一のサーバ側デバイス１２０ａが用いられるように構成される。この構成によれば、サーバ側デバイス１２０ａは、全ての呼び値の注文に対する中心として機能することができる。すなわち、サーバ側デバイス１２０ａは、それぞれの交換システムにおける状態および注文の変化に基づいて、それぞれの注文を管理する。

取引システム３００は、取引戦略に基づく売り又は買いの注文の電子取引を促進するよう構成される。その注文は取引戦略注文３１０といわれる。この例では、レッグＡおよびレッグＢの両方が呼び値のレッグとされている。図３Ａに示すように、サーバ側デバイス１２０ａは、顧客デバイス１１２から取引戦略注文３１０を受信する。取引戦略注文３１０は、レッグＡおよびレッグＢを含んだ取引戦略に関連している。レッグＡは、交換システム１４０ａにて電子取引される取引可能オブジェクトＡに関するものであり、レッグＢは、交換システム１４０ｂにて電子取引される取引可能オブジェクトＢに関するものである。交換システム１４０ａは交換システム１４０ｂとは異なっている。

取引戦略注文３１０が受信されると、サーバ側デバイス１２０ａが交換システム１４０ａに対して呼び値の注文３１２を提出する。呼び値の注文３１２は、例えば交換システム１４０ｂによって要求されるプロトコルに従うよう構成された、レッグＡにおける注文であっても良い。同様に、サーバ側デバイス１２０ａは交換システム１４０ｂに対して呼び値の注文３１４を提出する。呼び値の注文３１４は、例えば交換システム１４０ａによって要求されるプロトコルに従うよう構成された、レッグＢにおける注文であっても良い。呼び値の注文３１２は、交換システム１４０ｂにて取引されている取引可能オブジェクトＢに依存する。同様に、呼び値の注文３１４は、交換システム１４０ａにて取引されている取引可能オブジェクトＡに依存する。

呼び値の注文３１２、３１４を受信すると、交換システム１４０ａ、１４０ｂはサーバ側デバイス１２０ａに注文確認３１６、３１８を送信することで、呼び値の注文３１２、３１４の受領を知らせる。さらに交換システムは、呼び値の注文を、交換システムによって既に受信された又は将来的に受信される反対側の注文とマッチングさせ始める。

市場最新情報３２０が交換システム１４０ａからサーバ側デバイス１２０ａに対して送信される。市場最新情報３２０は、取引戦略に関連する価格の変動を含んでいる。例えば、市場最新情報には、レッグＢが依存する取引可能オブジェクトＡにおける価格が交換システム１４０ａにて変動したことが示される。したがって、取引戦略における目標価格を達成するために、最初に顧客デバイスによって定義されたように、サーバ側デバイス１２０ａは交換システム１４０ｂに対して変動注文３２２を提出する。変動注文３２２は、注文一覧内のある呼び値のレッグに関連する価格を変動させる。変動後の価格評価は、市場最新情報３２０に示される価格の変化に基づいている。交換システム１４０ｂはサーバ側デバイス１２０ａに変動注文確認３２４を送信することで、変動注文３２２の受領を知らせる。なお、交換システム１４０ｂが変動注文をサポートしない場合には、例えば、サーバ側デバイス１２０ａが、注文一覧内の注文をキャンセルして置換するための１つのキャンセル／置換注文、又は２つの別々のコマンドを送信するようにしても良い。

変動注文確認３２４を受信する前に、サーバ側デバイス１２０ａは、例えば取引戦略の価格化に影響する別の価格変動を示す別の市場最新情報３２６を受信する。しかしながら、いくつかの例では、変動注文確認３２４が受信されるまで（例えば、時間間隔３２８の間）、サーバ側デバイス１２０ａは変動注文３３０を送信することができない。すなわち、サーバ側デバイス１２０ａが変動注文３２２に関連する注文のための識別子を受信していないので、変動注文３３０は送信されるべきではないということである。注文を変化させる、置換する、又はキャンセルするときに、サーバ側デバイス１２０ａが正しい注文を参照できるように、交換システム１４０ｂは前記識別子を変動注文確認３２４に付けている。この識別子がないと、サーバ側デバイス１２０ａは正しく注文を参照することができない。したがって、交換システム１４０ｂは、正しい注文を識別するとともに適切なアクションをとることができなくなる。さらにその他の例では、サーバ側デバイス１２０ａは、取引所において注文が正しく受信されて注文一覧に置かれることを確保するために、変動注文確認３２４を待たなければならない。加えて、変動がすでに約定しているという可能性もある。これにより、変動注文確認が受信される前に変動注文３３０が送信された場合、トレーダは二重約定の可能性がある。

時間間隔３２８の間、サーバ側デバイス１２０ａは、市場が変化したものの変動注文を出すことはできないということを認知している。交換システム１４０ｂができるだけ早く変動注文３３０を受信できるように、この時間間隔をできるだけ短くすることで有利になる場合もある。

さらに図３Ｂに示すように、システム３００においては、トレーダが長期間、レッグド（legged）、二重約定、又はレッグドと二重約定の両方を被る可能性がある。システム３００は、図３Ａのシステム３００と同一又は類似するものである。しかしながら、市場最新情報３２６の代わりに、変動注文確認３２４を受信する前に、サーバ側デバイス１２０ａは約定確認３３２を受信する。約定確認３３２には、交換システム１４０ａが呼び値の注文３１２のマッチングを行ったことが示される。約定確認３３２の受信に反応して、サーバ側デバイス１２０ａは交換システム１４０ｂに対して、ヘッジ注文３３６およびキャンセル注文３３８の送信を試みる。ヘッジ注文３３６は、呼び値のレッグＡが依存していたレッグに関連する取引可能オブジェクトへの注文を出す。キャンセル注文３４０は、呼び値のレッグＢにおける取引可能オブジェクトへの置換注文（例えば、変動注文３２２の結果として出された注文）をキャンセルする。

ヘッジ注文３３６は、例えば約定の後などいつでも出すことができる。例えば図３Ｂに示すように、約定確認３３２の受信後かつ変動注文確認３２４の前に、ヘッジ注文３３６を出すこともできる。しかしながら、他の実施形態では、変動注文３３８が受信されてキャンセル注文３３８が送信されるまで、ヘッジ注文３３６が出されない場合もある。

しかしながら、サーバ側デバイス１２０ａは、変動注文確認３２４を受信するまでキャンセル注文３３８を出すことができない。これは、サーバ側デバイス１２０ａが変動注文３２２をキャンセル可能となるために、変動注文確認３２４内に確認の情報を必要とするためである。すなわち、サーバ側デバイス１２０ａは、上述したように識別子がなければ取引所１３０ｂにおいて変動注文３２２を識別することができないため、時間間隔３３４の間はキャンセル注文３３８を出すことができない。これにより、ヘッジ注文３３０、キャンセル注文３４０、又はその両方を出す際に遅延が生じるおそれがある。図３Ｂに示すように、ヘッジ注文３３６が遅延していなくとも、キャンセル注文３３８に遅延が生じて、結果的にユーザが二重約定又はレッグドを被る可能性がある。

このようなレッグドを被るリスクは、取引戦略を達成するのに必要な価格が利用できなくなったときに生じる。例えば、トレーダはレッグＡにて約定された後にレッグドを被ると考えられ、取引戦略価格を満足する価格におけるレッグＢでの約定が不可能となる。例えば、取引戦略価格が「５」でレッグＡが価格「１０」にて約定されたと仮定する。取引戦略価格はレッグＡの価格からレッグＢの価格を引いたものに等しいため、トレーダはレッグＢにおいて価格「５」を得る必要があると推定される。しかしながら、レッグＡが約定された後又はレッグＡが約定されている間に、市場がトレーダに反して移動する場合には（例えば、レッグＢの価格が「５」から「４」に落ちる）、取引戦略価格「５」が利用できなくなるため、トレーダはレッグドを被ってしまったと考えられる。さらに、交換システム１４０ｂにおいて変動注文３２２およびヘッジ注文３３６の両方が取引されているときには、トレーダは二重約定を被るリスクがある。すなわち、取引戦略価格を得るために、約定確認３２６が受信されるときに交換システム１４０ｂに対してヘッジ注文３３６が送信される。しかしながら、サーバ側デバイス１２０ａは既に変動注文確認３２４を受信しているため、変動注文３２２はキャンセルされていない。したがって、交換システム１４０ｂにおいて２つの注文が取り扱われている。これにより、トレーダには二重約定を被るリスクが残される。

例示的な電子取引プロセスについて
図４Ａは、図１の取引システム１００を用いた例示的な取引プロセスを示す。顧客デバイス１１２は、取引戦略定義を受信するように構成される。取引戦略定義は、買う又は売られるべき取引戦略を定義する。取引戦略定義には例えば、あらゆる価格データ、数量データおよびコンフィギュレーションデータ、又はこれらのあらゆる組み合わせが含まれても良い。取引戦略定義は顧客デバイス１１２から受信されても良い。例えば、取引戦略定義は、自動又はトレーダによる手動で顧客デバイス内に入力されても良い。別の例では、取引戦略定義のうちの全て又はそのいくつかが同じ又は異なる時間に受信されても良い。例えば、トレーダは取引戦略を定義する（例えば、スプレッドを定義する）とともに、取引戦略デバイス１１４又はサーバ側デバイスに対してコンフィギュレーションデータを送信するようにしても良い。その後、取引セッションの間に、例えば価格軸に沿って価格および数量を選択することで、価格および数量の情報を定義しても良い。

顧客デバイス１１２は、例えば取引戦略定義に基づいて、取引戦略注文４１０を生成するようにしても良い。注文が生成されると、顧客デバイス１１２は取引戦略デバイス１１４に取引戦略注文４１０を送信しても良い。取引戦略注文４１０はユーザからのリクエスト（例えば「送信」ボタンのクリック）により、又は自動的に送信されても良い。例えば、トレーダは取引戦略注文を出すために、電子取引ワークステーションを利用しても良い。別の例では、自動取引ツールが注文のための１つ以上のパラメータを計算するとともに、その注文を自動的に送信する場合もある。いくつかの例では、自動取引ツールは送信される注文を準備するが、ユーザからの確認がないと実際にはその注文を送信しない場合もある。

いくつかの実施形態では、顧客デバイス１１２は、例えば取引戦略デバイス１１４に割り当てられたアドレスや通信経路を用いて、取引戦略注文４１０の受信体として取引戦略デバイス１１４を指定する場合もある。しかしながら、他の実施形態では、取引戦略注文４１０が、取引戦略注文４１０を取引戦略デバイス１１４に送る別のデバイスに送信される場合もある。

取引戦略注文４１０を、複数の呼び値のレッグを有する取引戦略に関連付けても良い。例えば、取引戦略注文４１０を、レッグＡおよびレッグＢを有するスプレッドに関連付けても良い。レッグＡは交換システム１４０ａにて取引される取引可能オブジェクトＡに関連し、レッグＢは交換システム１４０ｂにて取引される取引可能オブジェクトＢに関連する。例えば、取引戦略が顧客デバイス１１２を用いて定義されるときに、レッグＡおよびレッグＢの両方が呼び値のレッグとして示される。したがって、レッグＡは取引可能オブジェクトＢに依存し、レッグＢは取引可能オブジェクトＡに依存する。付加的な呼び値のレッグおよび／又は呼び値でないレッグを、取引戦略注文４１０に関連する取引戦略にて定義しても良い。交換システム１４０ａは交換システム１４０ｂと異なっても良い。

取引戦略デバイス１１４は取引戦略注文４１０を受信しても良い。取引戦略注文４１０を受信する工程には、取引戦略注文４１０を受信、要請、読み出し又はその他の獲得を行う工程が含まれても良い。

図４Ａに示すように、各種実施形態においては、取引戦略デバイス１１４を顧客デバイス１１２と、サーバ側デバイス１２０のうちの１つ、いくつか又はその全てとの間に配置しても良い。したがって、取引戦略デバイス１１４はサーバ側デバイス１２０のうちの１つ、いくつか又はその全てよりも前に又は同時に、取引戦略注文４１０を受信しても良い。例えば、取引戦略デバイス１１４が顧客システム１１０内に配置される場合に、取引戦略デバイス１１４がサーバ側デバイス１２０ａおよびサーバ側デバイス１２０ｂよりも前に取引戦略注文を受信しても良い。しかしながら、取引戦略デバイス１１４がサーバ側デバイス１２０ａの一部である場合には、取引戦略デバイス１１４がサーバ側デバイス１２０ｂよりも前に、取引戦略注文４１０を受信しても良い。

一旦受信されると、取引戦略デバイス１１４は、取引戦略注文４１０を複数の子取引戦略注文４１４，４１６に分割４１２しても良い。したがって、取引戦略注文４１０は例えば、最初の注文、オリジナル注文、受信注文、又は親注文と呼ばれる。子注文４１４、４１６は例えば、下位注文、分割注文、又はデリバティブ注文と呼ばれる。

以下で詳細に説明するように、取引戦略注文４１０の分割４１２には、複数の呼び値のレッグにしたがって取引戦略を分類、複数の子取引戦略の定義、複数の子取引戦略注文の生成、複数の子取引戦略注文の提出、あるいはこれらのあらゆる組み合わせが含まれても良い。なお、分割４１２は上述の行為に限らない。取引戦略注文を分割する際に、付加的な、異なる、又は少数の行為を実行しても良い。

取引戦略デバイス１１４は、複数の呼び値のレッグを有する取引戦略を識別するように構成される。複数の呼び値のレッグを有する取引戦略に関連する取引戦略注文４１０は、取引戦略に、呼び値のレッグとして表示された複数のレッグが含まれることを認識、計算あるいは決定することを含んでも良い。例えば、取引戦略デバイス１１４が取引戦略注文４１０内のそれぞれのレッグを分析し、それぞれのレッグが呼び値のレッグか呼び値以外のレッグかを決定し、呼び値のレッグとされたレッグの数を数えるようにしても良い。別の例では、顧客デバイス１１２は、例えば取引戦略注文を生成するときに、取引戦略注文４１０における呼び値のレッグの数を示すために指定されたフィールドにおける呼び値のレッグの数を示す。したがって、取引戦略デバイス１１４がそのフィールドを読み込んで、分析しても良い。

複数の呼び値のレッグを有する取引戦略に関連する取引戦略注文４１０の識別に反応して、取引戦略デバイス１１４は複数の子取引戦略を定義しても良い。値付けされているレッグの数を除き、子取引戦略は取引戦略注文４１０に関連する取引戦略と同じである。すなわち、子取引戦略において呼び値のレッグとされたレッグの数は、取引戦略注文４１０に関連する取引戦略において呼び値のレッグとされたレッグの数と異なる（例えば、小さい）。例えば、子取引戦略には、単一の呼び値のレッグ、又は（例えば、取引戦略注文４１０における呼び値のレッグの数に比較して）減少された数の呼び値のレッグが含まれても良い。子取引戦略は取引可能オブジェクトに関連付けられる。例えば、図４Ａに示すように、第１の子取引戦略は取引可能オブジェクトＡに関連付けられ、第２の子取引戦略は取引可能オブジェクトＢに関連付けられる。第１の子取引戦略において、レッグＡは呼び値のレッグとされる。同様に、第２の子取引戦略において、レッグＢは呼び値のレッグとされる。

定義された子取引戦略の数は例えば、取引戦略注文４１０における呼び値のレッグの数に依存する。それぞれの子取引戦略が単一の呼び値のレッグを有しても良い。別の例では、複数の呼び値のレッグが単一の子取引戦略内に含まれても良い。呼び値のレッグは、呼び値のレッグのマッチングを行うよう構成された交換システムに基づきグループ化されても良い。例えば、同じ交換システムにて取引された呼び値のレッグが、同じ子取引戦略に含まれても良い。しかしながら、ともにグループ化された場合であっても、子注文における呼び値のレッグの数は取引戦略注文４１０における呼び値のレッグの数よりも少ない。

なお、現在のシステムは、取引戦略注文を分割することなく取引戦略注文の取り扱いをサポートする。例えば、取引戦略デバイス１１４は複数の呼び値のレッグを有する取引戦略のための取引戦略注文４１０を受信し、その取引戦略注文４１０をサーバ側デバイス１２０ａに送信しても良い。すなわち、取引戦略デバイス１１４は、取引戦略注文４１０を分割するかどうかを、例えば、待ち時間（latency）、１つ以上の交換システムの物理的位置、取引環境を最適化する１つ以上の他の留意事項、あるいはこれらの組み合わせに基づき決定しても良い。

それぞれの子取引戦略は呼び値のレッグを有さないか、１つあるいはそれより多くの呼び値のレッグを有する。子取引戦略における呼び値のレッグの数は、最初の注文の取引戦略における呼び値のレッグの数よりも少ない。一例として、取引戦略注文４１０に定められるように取引戦略が２つの呼び値のレッグを有する場合、取引戦略デバイス１１４は、単一の呼び値のレッグを有する第１の取引戦略および単一の呼び値のレッグを有する第２の取引戦略を定義しても良い。別の例では、取引戦略注文４１０に定められるように取引戦略が２２の呼び値のレッグを有する場合、取引戦略デバイス１１４は、単一の呼び値のレッグを有する第１の取引戦略、単一の呼び値のレッグを有する第２の取引戦略、および２０の呼び値のレッグを有する第３の取引戦略を定義しても良い。

子取引戦略のうちの１つ、いくつか又はその全てが定義されると、取引戦略デバイス１１４は複数の子取引戦略注文（「子注文」）４１４、４１６を生成する。それぞれの子注文４１４、４１６は、単一の又は（例えば、顧客デバイス１１２から受信された取引戦略注文における呼び値のレッグの数に比較して）減少された数の呼び値のレッグを有する子取引戦略を備えても良い。例えば、取引戦略注文４１０における取引戦略の複雑さに基づき、あらゆる数（例えば、２あるいは３以上）の子注文を生成しても良い。例えば、取引戦略デバイス１１４は、取引戦略注文４１０に関連付けられる取引戦略におけるそれぞれの値付けされたレッグのための子注文を生成しても良い。別の例では、例えば、子取引戦略をグループ化することで、取引戦略デバイス１１４が生成されるべき子注文の数を最小化する場合もある。レッグ若しくは取引戦略は、例えば、待ち時間、サーバ側デバイス、交換システム若しくはゲートウェイの物理的位置、トレーダの好み、交換能力、その他の既知の若しくは最近開発された基準、又はこれらのあらゆる組み合わせに基づきグループ化されても良い。これにより、電子取引システム１００を通じて伝達される子注文のボリュームを低減することができる。

子注文におけるレッグのうちの全て、いくつか又は１つが呼び値のレッグであっても良く、全てが呼び値のレッッグでなくても良い。子注文は、あらゆる数の呼び値でないレッグおよび／又はあらゆる数の呼び値のレッグを有して良い。子注文の数は例えば、取引戦略におけるレッグの数、呼び値のレッグの数、待ち時間、交換能力、又はこれらのあらゆる組み合わせに依存しても良い。子注文における呼び値でないレッグおよび呼び値のレッグの数は、それぞれ同じであっても異なっていても良い。呼び値でないレッグおよび呼び値のレッグの数は、子注文間において変化しても良く、変化しなくても良い。例えば、子注文において、呼び値のレッグが他の呼び値のレッグ又は呼び値でないレッグと混合されていても良い。しかしながら、単一の呼び値でないレッグおよび呼び値のレッグが、代替的に又は付加的に、独立であっても良い。取引戦略デバイス１１４は、子注文の数、それぞれの子注文における呼び値でないレッグの数若しくは呼び値のレッグの数、又はこれらの組み合わせを、例えば子注文を提出する際の待ち時間に基づいて決定する。取引戦略デバイス１１４は子注文を提出する際にかかる時間を最小化しても良い。

図５−７は、複数の呼び値のレッグを有する１つの注文を分割する例を示す。図５−７に示す例は、いずれも非網羅的である。以下で詳細に説明するように、図５は、２つのレッグを有する取引戦略に関連する取引戦略を、それぞれ単一の呼び値のレッグを有する２つの子注文に分割することを示す。図６は、４つのレッグを有する取引戦略に関連する取引戦略を、それぞれ単一の呼び値のレッグを有する２つの子注文に分割することを示す。図７は、５つのレッグを有する取引戦略に関連する取引戦略を、複数の呼び値のレッグを有する１つの子注文と単一の呼び値のレッグを有する１つの子注文との２つの子注文に分割することを示す。本願明細書等の範囲には、例えば異なる取引戦略のための他の例も含まれるものとする。

図５は、２つの呼び値のレッグ５２０ａ、５２０ｂを有する取引戦略５１０のための取引戦略注文５００を示す。すなわち、注文５００は複数の呼び値のレッグ５２０ａ、５２０ｂを有する。取引戦略デバイス１１４は、例えば顧客デバイスから注文５００を受信しても良い。取引戦略デバイス１１４は、注文５００を分析するとともに、注文５００に複数の又は１つよりも多くの呼び値のレッグが含まれることを識別しても良い。識別には、呼び値のレッグとされるレッグの数の計算が含まれても良い。

図５において、取引戦略デバイス１１４は、注文５００が２つの呼び値のレッグを有するということを決定しても良い。複数の呼び値のレッグの識別に応じて、取引戦略デバイス１１４は、第１の子注文５３０および第２の子注文５４０を生成しても良い。この例では、第１の子注文５３０はレッグ５２０ａおよびレッグ５２０ｂの両方を含むが、レッグ５２０ａのみが呼び値のレッグとされる。レッグ５２０ｂは呼び値でないレッグである。すなわち、第１の子注文５３０を生成する際に、取引戦略デバイス１１４は、第２のレッグ５２０ｂを呼び値のレッグから呼び値でないレッグに変えても良い。同様に、第２の子注文５４０はレッグ５２０ａおよびレッグ５２０ｂの両方を含むが、レッグ５２０ｂのみが呼び値のレッグである。レッグ５２０ａは呼び値でないレッグである。すなわち、第２の子注文５４０を生成する際に、取引戦略デバイス１１４は、第１のレッグ５２０ａを呼び値のレッグから呼び値でないレッグに変えても良い。第１の子注文５３０はサーバ側デバイス１２０ａに提出しても良い。第２の子注文５４０は第２のサーバ側デバイス１２０ｂに提出しても良い。

サーバ側デバイス１２０は、子注文におけるそれぞれの呼び値のレッグのための呼び値の注文を、呼び値のレッグのための注文がマッチングおよび約定される交換システムに送信しても良い。この例では、第１の交換システムが第１のレッグ５２０ａのための注文を約定し、第２の交換システムが第２のレッグ５２０ｂのための注文を約定する。図示されるように、第１の子注文５３０および第２の子注文４３０は、互いに関連する注文―キャンセル―注文（ＯＣＯ）型の注文とされても良く、そこでは、子注文における呼び値のレッグを完全に約定すると、次に他の子注文をキャンセルする。ＯＣＯ行為は、呼び値のレッグが約定された子注文における約定又はレッグドされた量に基づいて、他の子の量を低減しても良い。これによりトレーダは、呼び値のレッグの両方が１つの場所から管理されるときでも生じる可能性のある飛行中の状態に起因する二重約定を、飛行中（in flight）の状態を除き被らないということが確保される。

図６は、２つの呼び値のレッグ６２０ａ、レッグ６２０ｃおよび２つの呼び値でないレッグ６２０ｂ、６２０ｄを有する取引戦略６１０のための取引戦略注文６００を示す。取引戦略デバイス１１４は、例えば顧客デバイスから注文６００を受信しても良い。取引戦略デバイス１１４は、注文６００を分析するとともに、注文６００に複数の又は１つよりも多くの呼び値のレッグが含まれることを識別しても良い。識別には、呼び値のレッグとされるレッグの数の計算が含まれても良い。

取引戦略デバイス１１４は、注文６００が２つの呼び値のレッグ６２０ａ、６２０ｃを有するということを決定しても良い。複数の呼び値のレッグの識別に応じて、取引戦略デバイス１１４は、第１の子注文６３０および第２の子注文６４０を生成しても良い。この例では、第１の子注文６３０はレッグ６２０ａ−６２０ｄを含むが、レッグ６２０ａのみが呼び値のレッグとされる。レッグ６２０ｂ―ｄは第１の子注文６３０における呼び値でないレッグである。第２の子注文６４０はレッグ６２０ａ―６２０ｄを含むが、レッグ６２０ｃのみが呼び値のレッグとされる。レッグ６２０ａ、６２０ｂ、６２０ｄは呼び値でないレッグとされる。呼び値のレッグ６２０ａのための注文は第１の交換システム１４０ａにて約定されるため、第１の子注文３３０は第１のサーバ側デバイス１２０ａに提出しても良い。呼び値のレッグ６２０ｃのための注文は第２の交換システム１４０ｂにて約定されるため、第２の子注文３４０は第２のサーバ側デバイス１２０ｂに提出しても良い。図示されるように、第１の子注文６３０および第２の子注文６３０は、注文―キャンセル―注文（ＯＣＯ）型の注文とされても良く、そこでは、呼び値のレッグを約定すると、次に他の注文をキャンセルする。

図７は、３つの呼び値のレッグ７２０ａ、７２０ｃ、７２０ｅおよび２つの呼び値でないレッグ７２０ｂ、７２０ｄを有する取引戦略７１０のための取引戦略注文７００を示す。この例では、呼び値のレッグ７２０ａ、７２０ｅは、同じ交換システムにてマッチングおよび約定される。したがって、取引戦略デバイス１１４は、同じ子注文において呼び値のレッグ７２０ａ、７２０ｅを有する。図７に示すように、取引戦略デバイス１１４は、例えば顧客デバイスから注文７００を受信しても良い。取引戦略デバイス１１４は、注文７００を分析するとともに、注文７００に複数の又は１つよりも多くの呼び値のレッグが含まれることを識別しても良い。識別には、呼び値のレッグとされるレッグの数の計算が含まれても良い。

取引戦略デバイス１１４は、注文７００が２つの呼び値のレッグ７２０ａ、７２０ｃを有するということを決定しても良い。複数の呼び値のレッグの識別に応じて、取引戦略デバイス１１４は、第１の子注文７３０および第２の子注文５４０を生成しても良い。この例では、第１の子注文７３０はレッグ７２０ａ−７２０ｄを含むが、レッグ７２０ａ、７２０ｅが同じ交換システムにて約定されるため、レッグ７２０ａ、７２０ｅのみが呼び値のレッグとされる。レッグ７２０ｂ―７２０ｄは第１の子注文７３０における呼び値でないレッグとされる。第２の子注文５４０はレッグ７２０ａ―７２０ｄを含むが、レッグ７２０ｃのみが呼び値のレッグとされる。レッグ７２０ａ、７２０ｂ、７２０ｄ、７２０ｅは呼び値でないレッグとされる。呼び値のレッグ７２０ａ、７２０ｅは第１の交換システム１４０ａにて約定されるため、第１の子注文７３０は第１のサーバ側デバイス１２０ａに送信されても良い。呼び値のレッグ４２０ｃは第２の交換システム１４０ｂにて約定されるため、第２の子注文３４０は第２のサーバ側デバイス１２０ｂに提出しても良い。図示されるように、第１の子注文７３０および第２の子注文７３０は、注文―キャンセル―注文（ＯＣＯ）型の注文とされても良く、そこでは、呼び値のレッグを約定すると、次に他の注文をキャンセルする。

図７の例の別のものとして、取引戦略デバイス１１４は、２つの子注文とは反対に、３つの異なる子注文を生成しても良い。それぞれの子注文は、取引可能オブジェクトに関連付けられる可能性のある単一の呼び値のレッグを有しても良い。例えば、第１、第２および第３の子注文はそれぞれ、第１、第２および第３の取引可能オブジェクトに関連付けられても良い。第１および第２の取引可能オブジェクトは第１の交換システムにて取引され、第３の取引可能オブジェクトは第２の交換システムにて取引されても良い。したがって、異なる注文である第１および第２の子注文は第１の交換システムに送信され、第３の子注文は第２の交換システムに送信されても良い。

子注文は、複数の交換システムにおいて値付けされる複数の呼び値のレッグを有しても良い。以下で説明するように、子注文を提出するために一連の取引戦略デバイス１１４を用いても良い。例えば、第１の取引戦略デバイス（例えば、シカゴに配置される）は、１つの取引戦略注文（例えば、ミルウォーキーに配置された顧客デバイスにより生成される）を第１および第２の子注文に分割しても良い。第１の子注文は、（例えば、ヨーロッパに配置された）第１の交換システムにおいて取引される第１の取引可能オブジェクトに関連付けられる第１の呼び値のレッグと、（例えば、日本に配置された）第２の交換システムにおいて取引される第２の取引可能オブジェクトに関連付けられる第２の呼び値のレッグとを有しても良い。第２の子注文は、（例えば、シカゴに配置された）第３の交換システムにおいて取引される第３の取引可能オブジェクトに関連付けられる第３の呼び値のレッグを有しても良い。第１の取引戦略デバイスは、第１の子注文を（例えば、ヨーロッパに配置された）第２の取引戦略デバイスに送り、第２の子注文を第３の交換システムに関連付けられるサーバ側デバイスに提出用として送信するようにしても良い。第２の取引戦略デバイスは、第１の子注文を第４および第５の子注文に分割しても良い。第４および第５の子注文は、それぞれの交換システムに関連付けられるサーバ側デバイスに送信しても良い。

サーバ側デバイス１２０が複数の取引所と取引するとともに、子注文における２つ以上の呼び値のレッグが異なる取引所で取引される呼び値の注文を有するようにしても良い。例えば、１つの子注文が、第１の取引所で取引される第１の呼び値のレッグと第２の取引所で取引される第２の呼び値のレッグとに関連付けられても良い。サーバ側デバイス１２０は、それぞれの注文が異なる取引所で取引されていても、第１および第２の呼び値のレッグのための注文の両方を取り扱っても良い。

図４Ａに戻ると、ともに呼び値のレッグであるレッグＡおよびレッグＢを取引戦略注文４１０が有するとの決定に応じて、取引戦略デバイス１１４は、レッグＡを含む第１の子取引戦略とレッグＢを含む第２の子取引戦略とを定義しても良い。次に、取引戦略デバイス１１４は、第１の子取引戦略のための子注文４１４と第２の子取引戦略のための子注文４１６とを生成しても良い。したがって、子注文４１４は呼び値のレッグとされるレッグＡを有し、子注文４１６は呼び値のレッグとされるレッグＢを有する。

取引戦略デバイス１１４は複数の子注文４１４、４１６の送り先を知的に決定しても良い。例えば、子注文をサーバ側デバイス１２０に送信しても良く、そのサーバ側デバイス１２０は、子注文における呼び値のレッグを約定するよう構成されたそれぞれの交換システム１４０にて子注文を取引するよう構成されている。子注文を取引するよう構成されたサーバ側デバイス１２０が複数存在する場合には、取引戦略デバイス１１４は、交換システム１４０に最も近いサーバ側デバイス１２０に子注文を送信しても良い。例えば、図示のように、子注文４１４を交換システム１４０ａに最も近いサーバ側デバイス１２０ａに送信し、子注文４１６を交換システム１４０ｂに最も近いサーバ側デバイス１２０ｂに送信しても良い。

さらに、取引戦略デバイス１１４は、子注文を送信するための通信経路を待ち時間に基づいて選択しても良い。待ち時間には、サーバ側デバイス１２０や交換システム１４０などの受信デバイスが取引戦略デバイス１１４から子注文を受信するために必要とされる時間が含まれても良い。取引戦略デバイス１１４は、例えば、取引戦略デバイス１１４と交換システムとの間における遅延が最も小さい若しくは低減された通信経路を経由して子注文を送信することにより、待ち時間を低減又は最小化することができる。通信経路は、取引戦略デバイス１１４と交換システムとを接続しても良い。一例では、通信経路に、取引戦略デバイス１１４に遅延を報告する通信ノード、ルータ、サーバなどの通信デバイスが含まれても良い。取引戦略デバイス１１４は、最適な（例えば、待ち時間が最も小さくなるように）通信経路を決定するためにその情報を分析しても良い。

図４Ａは単一の取引戦略デバイス１１４を有する取引戦略注文４１０の分割について示しているが、取引戦略注文４１０の分割のために一連の（例えば、２つ、３つ又はそれよりも多くの）取引戦略デバイスを用いても良い。一連の取引戦略デバイスは、取引システム１００における様々な層又は場所で取引戦略注文を分割しても良い。複数層、複数場所又は複数層および複数場所の両方における分割は、１つ以上の取引戦略デバイス１１２によって実施されても良い。例えば、取引戦略デバイス１１４などの第１の取引戦略デバイスは、取引戦略注文４１０を第１および第２の子注文に分割しても良い。複数の呼び値のレッグを有する第１の子注文を再度分割するために、第２の異なる取引戦略デバイスに送信しても良い。

子注文が受信されると、サーバ側デバイス１２０は、呼び値のレッグのマッチングを行うよう構成された交換システムに、１つ以上の呼び値のレッグのための注文（「呼び値の注文」）を提出しても良い。呼び値の注文における１つ以上の呼び値のレッグは、子注文において定義された呼び値のレッグであっても良い。例えば、図４に示すように、第１の子注文４１４の受信に応じて、サーバ側デバイス１２０ａは交換システム１４０ａに呼び値の注文４１８を提出しても良い。呼び値の注文４１８は第１の呼び値のレッグQ１を有しても良い。第２の子注文４１６の受信に応じて、サーバ側デバイス１２０ｂは交換システム１４０ｂに呼び値の注文４２０を提出しても良い。呼び値の注文４２０は、第２の呼び値のレッグQ２を有しても良い。

交換システム１３０ａ、１３０ｂは、注文確認４２２および注文確認４２４を送信することにより、呼び値の注文４１８および呼び値の注文４２０の受領をそれぞれ知らせても良い。注文確認４２２、４２４は、サーバ側デバイス１２０ａ、１２０ｂによる呼び値の注文４１８、４２０の取り扱いを可能とする確認情報をそれぞれ含んでも良い。例えば、確認情報には、サーバ側デバイス１２０ａがキャンセル注文やヘッジ注文などの次の注文をする際に呼び値の注文３１２、３１４を識別することが可能となる識別情報が含まれても良い。確認情報がないと、サーバ側デバイス１２０ａ、１２０ｂは、呼び値の注文４１８、４２０についてのキャンセル、置換、又はその両方を行うことができない場合がある。

サーバ側デバイス１２０ａ、１２０ｂは、呼び値の注文４１８、４２０をそれぞれ取り扱うよう構成されても良い。上述したように、注文の取り扱いには、注文の再値付け、注文のキャンセル、ヘッジ注文の送信、未処理注文の管理、あるいはこれらのあらゆる組み合わせが含まれても良い。

例えば、図４Ａに示すように、サーバ側デバイス１２０ｂは交換システム１４０ａから市場最新情報４２６を受信しても良い。市場最新情報４２６は、呼び値の注文４２０が依存しているレッグの価格変化を示しても良い。したがって、取引戦略注文４１０で定義されるように、取引戦略のための目標価格を達成するために、サーバ側デバイス１２０ｂは変動注文を提出しても良い。変動注文４２８は、呼び値の注文４２０が修正された価格価値を有するようにして呼び値の注文４２０を変動させる。修正された価格価値は市場最新情報に示される価格変化に基づくとともに、市場が流動するときでも取引戦略のための目標価格が達成されることを確保する。交換システム１４０ｂは、サーバ側デバイス１２０ｂに変動注文確認４３０を送信することにより、変動注文４２８の受領を知らせるようにしても良い。

しかしながら、サーバ側デバイス１２０ｂが変動注文確認４３０を受信する前に、サーバ側デバイス１２０ｂは交換システム１４０ａから別の市場最新情報４３２を受信する。市場最新情報４３２は市場最新情報４２６とは異なる。例えば、市場最新情報４３２は取引可能オブジェクトＡのためのさらに別の価格変動を示す。サーバ側デバイス１２０ｂが変動注文４２８のための変動注文確認４３０を受信するまで、呼び値の注文４２０のための価格価値を修正する変動注文４３４を送信することができない。しかしながら、サーバ側デバイス１２０ｂは交換システム１４０ｂに、その中に又はその近傍に配置されているため、例えば、図３Ａに示すように変動注文確認４３０をサーバ側デバイス１２０ａまで遡って送信する必要がないので、サーバ側デバイス１２０が待機する必要のある時間間隔４３８は低減される。

図４Ｂは、取引戦略注文４１０を取り扱うために用いられる取引システム１００を示す。しかしながら、市場最新情報４３２をサーバ側デバイス１２０ｂに送信しない代わりに、取引戦略注文４１０を行う工程は図４Ａの場合と同様であり、交換システム１４０ａは呼び値の注文４１８をマッチングするとともに約定確認４４０を送信する。しかしながら、別の例では、呼び値の注文４１８は市場最新情報４２６よりも前又はそれと同時にマッチングされても良い。呼び値の注文４１８の約定に応じて、図４の例に示すように交換システム１４０ａはサーバ側デバイス１２０ａに約定確認４４０を送信し、呼び値の注文４１８がマッチングされたことを知らせる。その代わりに又は付加的に、約定確認４３２を、顧客デバイス１１２、取引戦略デバイス１１４、サーバ側デバイス１２０ｂ、あるいはこれらの組み合わせに送信しても良い。

約定確認４３２の受信に応じて、サーバ側デバイス１２０ａはサーバ側デバイス１２０ｂにヘッジ注文４４４およびキャンセル注文４４４を送信する。ヘッジ注文４４２は、レッグＡが依存していたレッグのための取引注文を行う。ヘッジ注文４４２はキャンセル注文４４４の前に又はその後に提出されても良い。キャンセル注文４４４はレッグＢのための呼び値の注文４２０をキャンセルする。図４Ｂには別のメッセージとして示されるが、ヘッジ注文４４２およびキャンセル注文４４４は単一の注文メッセージであっても良い。

いくつかの実施形態では、例えばサーバ側デバイス１２０ａ、１２０ｂが互いに通信しないときに、ヘッジ注文４４２およびキャンセル注文４４４を、例えばサーバ側デバイス１２０ｂへのルーティングのために取引戦略デバイス１１４に送信しても良い。その代わりに又は付加的に、例えばサーバ側デバイス１２０ａ、１２０ｂが互いに通信するときに、サーバ側デバイス１２０ａは、サーバ側デバイス１２０ｂにヘッジ注文４４２およびキャンセル注文４４４を送信しても良い。

ヘッジ注文４４２がサーバ側デバイス１２０ｂに受信されると、サーバ側デバイス１２０ｂは交換システム１４０ｂにヘッジ注文４４６を送信する。ヘッジ注文は、例えば、変動注文確認４３０が受信される前、キャンセル注文４４４の前後、サーバ側デバイス１２０ｂが変動注文確認４３０を受信した後、あるいはそれ以外のときなど、いかなるときに行っても良い。

変動注文確認４３０を受信する前に、サーバ側デバイス１２０ｂはキャンセル注文４４４を受信する。しかしながら、キャンセル注文４４４が受信されるときに、サーバ側デバイス１２０ｂは確認情報を有した変動注文確認４３０を受信していないため、どの注文をキャンセルすべきか認識しておらず、変動注文４２８をキャンセルすることができない。したがって、サーバ側デバイス１２０ｂは、変動注文確認４３０を受信するまでキャンセル操作を実施することができない。結果的にトレーダは、キャンセル注文４４４の受信と変動注文４３０の受信との間の時間を含んだ時間間隔４５０の間、リスクにさらされる。しかしながら、以下で説明するように、この時間間隔は、キャンセル注文４４８を送信する前に変動注文確認４３０をサーバ側デバイス１２０ａまで遡って送信する必要がある場合よりもかなり短い。変動注文確認４３０が受信されると、サーバ側デバイス１２０ｂはキャンセル注文４４８を提出する。キャンセル注文４４８は変動注文４２８をキャンセルする。確認情報は必要ないので、時間間隔４５０の間にヘッジ注文４４６を提出しても良い。

図４Ｂに示すように、取引戦略注文を分割するとともに、交換システム１３０のうちの全て、いくつか若しくは１つに、又はその近く、若しくはその中にあるサーバ側デバイス１２０に子注文を送信することで、トレーダがレッグド（legged）、二重約定、又はレッグドと二重約定の両方を被る可能性がある時間を減らすことができる。すなわち、サーバ側デバイス１２０ｂは、交換システム１４０ｂから変動（あるいは変動がサポートされていない場合にはキャンセル／置換）注文確認を受信するとすぐにキャンセル注文４３４を提出することができる。サーバ側デバイス１２０ｂおよび交換システム１４０ｂは、サーバ側デバイス１２０ａおよび交換システム１４０ｂよりも互いに近くに位置しているため、確認４３０のための待ち時間（すなわち時間間隔４５０）は、確認３２４のための待ち時間（すなわち時間間隔３３４）よりも短い。加えて、変動注文確認４３０が移動する距離は、変動注文確認３２４が移動する距離よりも短い。さらに、キャンセル注文４４８が移動する距離は、キャンセル注文３３８が移動する距離よりも短い。時間に関しては、短い距離ほど移動時間は短くなり、その方がユーザにとっても非常に有益である。

子注文が交換システムに提出される前後において、サーバ側デバイス１２０は、例えば、注文をキャンセル、注文を変動、交換の問い合わせ、又はこれらのあらゆる組み合わせを行っても良い。注文のキャンセルには、交換システムへの提出が予定されていた又は予定されている注文のうちの全てあるいはそのいくつかをキャンセルすることが含まれても良い。例えば、交換システム１４０が呼び値の注文の一部を約定することしかできない場合には、交換システム１４０は、注文の全体が約定されるまで待つ代わりに、約定可能な部分のみ取引を行うとともにサーバ側デバイス１２０に部分的な約定注文を送信する。これに応じて、サーバ側デバイス１２０は部分的なキャンセル注文および部分的なヘッジ注文を送信しても良い。これにより、取引戦略の全体が完全に約定されるまで、継続的又は断続的な約定を行うことができる。

さらに、注文の変動には、例えば、注文パラメータの変動、注文フォーマットの変動（例えば、金融情報交換（ＦＩＸ）プロトコルなどのプロトコルの変動）、注文の提出時間の変動、提出用通信経路の変動、又はこれらのあらゆる組み合わせが含まれても良い。交換の問い合わせには、市場データやその他のデータといった情報の要求が含まれても良い。

子取引戦略は、呼び値のレッグとされるレッグの数を除くと親取引戦略と同一である。すなわち、第１の子注文４１４および第２の子注文４１６の約定は、取引戦略注文４１０の約定と同一である。例えば、子注文のうちの１つの約定によって、顧客デバイス１１２からの取引戦略注文４１０の約定と同一又は略同一の結果をもたらしても良い。ここでの「略」との用語には、例えば、１つ以上の注文の約定にかかる時間を変化（例えば、増加又は減少）させることで生じる価格変動など、電子取引システム１００における小さな変更が考慮されている。価格は急速に流動する。したがって、子注文は顧客デバイス１１２からの注文よりも少ない時間にて提出されても良いので、顧客デバイス１１２からの注文の約定における価格は、子注文の約定における価格と異なっても良い。しかしながら、価格は変動する可能性があるものの、顧客デバイス１１２からの注文の約定あるいは子注文２３０、２４０のうちのうちの１つ、いくつかあるいはその全ての組み合わせの約定によって、同一の取引戦略が実行される。なお、交換システムに近いサーバ側デバイスを有することで、呼び値のレッグでの約定の可能性が増加する。さらに、（単一のサーバ側方式の場合に比べて、）ヘッジ注文の方が早く交換システムに到着する可能性が高い。加えて、第２の呼び値の注文が早く取り除かれる（飛行中の時間が最小限に低減される）ため、二重約定の可能性を少なくすることができる。

図４Ｂに示す例では、交換システム１４０ｂよりも前に第１の子注文４１４を約定させた交換システム１４０ａは、第２の子注文４１６を約定させることができた。しかしながら、その他の例では、交換システム１４０ｂは、第１の子注文２３０が約定される前に第２の子注文４１６を約定させても良い。したがって、Ｑ１注文４１８をキャンセル又は置換するように、その工程が予約されても良い。

例示的な取引戦略デバイス
図８は、取引戦略デバイス１１４の一例を示す。取引戦略デバイス１１４は、１つ以上の電子コンピューティングプラットフォームを備える。例えば、図８に示すように、取引戦略デバイス１１４は、プロセッサ８１０とメモリ８２０とを有する電子コンピューティングプラットフォームを備えても良い。プロセッサ８１０は、メモリ８２０と通信可能に接続してメモリ８２０に保存された命令を実行しても良い。取引戦略デバイス１１４は、付加的な、異なる又は少ない数のコンポーネントを備えても良い。

プロセッサ８１０は、汎用プロセッサ、デジタルシグナルプロセッサ、特定用途向けＩＣ、フィールドプログラマブルゲートアレイ、アナログ回路、デジタル回路、これらの組み合わせ、又はその他の既に知られている若しくは最近開発されたプロセッサであっても良い。プロセッサ８１０は、ネットワークや分散プロセッシングなどに関連付けられる単一のデバイスあるいは組み合わせのデバイスであっても良い。マルチプロセッシング、マルチタスキング、パラレルプロセッシングなど、あらゆる各種処理戦略を用いても良い。プロセッシングは、リモートに反してローカルであっても良い。しかしながら、プロセッシングをリモートで行っても良い。プロセッシングは１つのプロセッサから別のプロセッサへと移動されても良い。プロセッサ８１０は、接触媒体内に符号化された論理回路（logic）に反応しても良い。論理回路は、ソフトウェア、ハードウェア、ＩＣ、ファームウェア、マイクロコードなどの一部として保存されても良い。

メモリ８２０はコンピュータ読み取り可能な保存媒体であっても良い。コンピュータ読み取り可能な保存媒体には、ランダムアクセスメモリ、読み出し専用メモリ、プログラマブル読み出し専用メモリ、電子プログラマブル読み出し専用メモリ、電子消去可能読み出し専用メモリ、フラッシュメモリ、磁気テープ、磁気ディスク、光媒体などを含め、これらに限らないが、様々な種類の揮発性又は非揮発性の保存媒体が含まれても良い。メモリ８２０は、単一のデバイス又は組み合わせのデバイスであっても良い。メモリ８２０は、プロセッサ８１０に近接しても、プロセッサ８１０の一部であっても、プロセッサ８１０にプログラムされても、プロセッサ８１０とネットワークで結ばれても、および／又はプロセッサ８１０と離れていても良い。

プロセッサ８１０は、メモリ８２０などの１つ以上の接触型媒体に符号化された論理回路を実行するように操作可能であっても良い。１つ以上の接触型媒体に符号化された論理回路は、プロセッサによって実行可能であるとともにコンピュータ読み取り可能な保存媒体、メモリ、あるいはこれらの組み合わせに設けられた命令であっても良い。プロセッサ８１０は、論理回路にプログラムされ、論理回路を実行する。図面や本明細書に記載された機能、行為、あるいはタスクは、コンピュータ読み取り可能な保存媒体の中に又はその上に保存された１セット以上の論理回路又は命令に応じて実行されても良い。機能、行為、あるいはタスクは、特定の種類の命令セット、保存媒体、プロセッサ又はプロセッシング戦略とは独立するとともに、ソフトウェア、ハードウェア、ＩＣ、ファームウェア、マイクロコードなどによって単独であるいは組み合わされながら実行されても良い。

一例では、図８に示すように、メモリ８２０は、取引戦略注文８２２を受信するように実行される命令（以降、「命令８２２」）、取引戦略注文を複数の子注文８２４に分割するように実行される命令（以降、「命令８２４」）、および複数の子注文８２６を提出するように実行される命令（以降、「命令８２６」）を備える。メモリ８２０は、付加的な、異なる又は少ない数の命令を備えても良い。

命令８２２は、複数の呼び値のレッグ、１つ以上の呼び値でないレッグ又はこれらの組み合わせを有する取引戦略のための取引戦略注文を受信するように実行されても良い。例えば、取引戦略は第１および第２の呼び値のレッグを備えても良い。命令８２４は、取引戦略が複数の呼び値のレッグを有することを決定又は識別するように実行される命令を有しても良い。さらに、命令８２４は子取引戦略を定義しても良く、および／又は複数の子注文を生成する命令を定義しても良い。それぞれの子注文は、単一の又は最初の取引戦略注文よりも少ない数の呼び値のレッグを有しても良い。命令８２６は、複数の子注文を例えば２つ以上の交換システムに提出するように実行される命令を有しても良い。それらの交換システムは、同一の交換システムであっても異なる交換システムあっても良い。複数の子注文の提出には、呼び値の注文を約定するよう構成された交換システムに対して呼び値のレッグのための呼び値の注文を提出するよう構成されたサーバ側デバイスに子注文を送信することが含まれても良い。サーバ側デバイスは交換システムに、その周囲に、又はその中に物理的に配置されても良い。例えば、第１の子注文は第１の交換システムにてマッチングおよび約定され、第２の子注文は第２の交換システムにてマッチングおよび約定されても良い。

例示的な電子取引のための方法
図９は、取引戦略注文を電子的に取引するための例示的な方法９００を示す。行為は、図示された注文あるいはそれ以外の注文にて実行されても良い。方法９００は、複数の呼び値のレッグ９１０を有する取引戦略注文を受信する工程９１０と、その取引戦略注文を複数の子注文に分割する工程９２０と、電子取引を完了させる工程９３０とを含む。付加的な、異なる又は少ない数の行為が方法９００にて実行されても良い。

行為９１０において、取引戦略デバイスは複数の呼び値のレッグを有する取引戦略を有する取引戦略注文を受信しても良い。受信には、要請、引出し（pulling）、傍受あるいは獲得が含まれても良い。

各種実施形態では、方法９００は、例えば行為９１０の前に、例えば取引戦略定義に基づく取引戦略注文を生成する工程を含んでも良い。取引戦略定義は、顧客デバイスから受信しても良い。例えば、取引戦略は顧客デバイスを使用するユーザによって定義されても良い。取引戦略の定義付けには、１つ以上の取引可能オブジェクトの定義付けが含まれても良い。取引可能オブジェクトは、呼び値のレッグ又は呼び値でないレッグといったレッグであっても良い。取引戦略定義は、自動的に又はトレーダによって手動的に顧客デバイスに入力されても良い。別の例では、取引戦略定義のうちの全て又はそのいくつかが、同時又は異なるときに受信されても良い。例えば、トレーダは、取引戦略を定義する（例えば、スプレッドを定義する）とともに、コンフィギュレーションデータを取引戦略デバイス又はサーバ側デバイスに送信しても良い。そして、取引セッションの間において、例えば価格軸に沿って価格および数量を選択することにより、価格および数量の情報が定義されても良い。

一旦生成されると、顧客デバイスは取引戦略デバイス１１４へ取引戦略注文を送信しても良い。取引戦略注文は、ユーザからのリクエスト（例えば「送信」ボタンのクリック）により又は自動的に送信されても良い。例えば、トレーダは電子取引ワークステーションを利用しても良い。別の例では、自動取引ツールが注文のための１つ以上のパラメータを計算するとともにその注文を自動的に送信しても良い。いくつかの例では、自動取引ツールは送信すべき注文を準備するが、ユーザからの確認がないと実際には送信しない場合もある。

いくつかの実施形態では、例えば取引戦略デバイスに割り当てられたアドレス又は通信経路を利用することにより、取引戦略デバイスを取引戦略注文の受信体として指定する。しかしながら、その他の実施形態では、取引戦略注文を取引戦略デバイスに向かわせる別のデバイスに取引戦略注文を送信する場合もある。

上述のように、取引戦略注文は複数の呼び値のレッグを有する取引戦略に関連付けられても良い。すなわち、取引戦略は、呼び値のレッグとされる複数のレッグを有しても良い。呼び値のレッグとされるレッグは、取引戦略におけるレッグのうちのいくつか又はそのすべてであっても良い。

行為９２０において、取引戦略デバイスは取引戦略注文を分割する。図１０は、行為９２０の一例を示す。図１０に示すように、分割には、複数の呼び値のレッグを有する取引戦略に関連付けられる取引戦略注文の識別１０１０、子取引戦略の定義付け１０２０および子取引戦略のための子注文の生成１０３０が含まれても良い。分割は上述の行為には限らない。取引戦略注文の分割には、付加的な、異なる又は少ない数の行為が含まれても良い。

行為１０１０において、取引戦略デバイスは、複数の呼び値のレッグを有する取引戦略に関連付けられる取引戦略注文を識別する。識別には、取引戦略注文における呼び値のレッグの数のカウント、把握、計算、若しくは決定、並びに呼び値のレッグの数が２つ以上かどうかの決定が含まれても良い。例えば、取引戦略デバイスは、取引戦略注文におけるそれぞれのレッグを分析し、それぞれのレッグか呼び値のレッグか呼び値でないレッグかを決定し、呼び値のレッグとされるレッグの数をカウントしても良い。別の例では、顧客デバイスは、例えば取引戦略注文を生成するときに、取引戦略注文における呼び値のレッグの数を表示するために指定されたフィールドにおける呼び値のレッグの数を表示する。したがって、取引戦略デバイスはそのフィールドの読み取りおよび分析を行っても良い。

行為１０２０において、取引戦略デバイスは子取引戦略を定義する。例えば、複数の呼び値のレッグを有する取引戦略に関連付けられる取引戦略注文の識別に応じて、取引戦略デバイスは複数の子取引戦略を定義する。子取引戦略は、値付けされているレッグの数を除き、取引戦略注文に関連付けられる取引戦略と同一である。すなわち、戦略（例えば、取引可能オブジェクトの売りおよび／又は買い）が同一であっても、子取引戦略における呼び値のレッグとされるレッグの数は、取引戦略注文に関連付けられる取引戦略における呼び値のレッグとされるレッグの数と異なる（例えば少ない）。例えば、子取引戦略は、単一の又は（例えば取引戦略注文における呼び値のレッグの数に比べて）低減された数の呼び値のレッグを有しても良い。

上述のように、定義された子取引戦略の数は例えば、取引戦略注文における呼び値のレッグの数に依存する。それぞれの子取引戦略は単一の呼び値のレッグを有しても良い。しかしながら、別の例では、複数の呼び値のレッグが単一の子取引戦略の中に含まれる、又はグループ化されても良い。呼び値のレッグは、呼び値のレッグのマッチングを行うように構成された交換システムに基づきグループ化されても良い。例えば、同一の交換システムにて取引される呼び値のレッグが、同一の子取引戦略に含まれても良い。しかしながら、ともにグループ化される場合であっても、子注文における呼び値のレッグの数は、取引戦略注文における呼び値のレッグの数よりも少ない。

それぞれの子取引戦略は呼び値のレッグを有さないか、１つ以上の呼び値のレッグを有する。例えば、子取引戦略における呼び値のレッグの数は、最初の注文の取引戦略における呼び値のレッグの数よりも少ない。

行為１０３０において、子取引戦略注文が生成されても良い。それぞれの子注文は子取引戦略のうちの１つを有しても良い。子取引戦略のうちの１つ、いくつかあるいはすべてが定義されると、行為１０２０に示すように、取引戦略デバイスは複数の子取引戦略注文を生成する。それぞれの子注文は、単一の又は低減された数の呼び値のレッグを有する子取引戦略を有する。例えば、取引戦略注文における取引戦略の複雑さに基づいて、あらゆる数（例えば、２又はそれよりも多く）の子注文を生成しても良い。例えば、子取引戦略の生成には、取引戦略注文に関連付けられる取引戦略におけるそれぞれの値付けされたレッグのための子注文の生成が含まれても良い。別の例では、子取引戦略の生成には、例えば子取引戦略をグループ化することにより、生成する必要がある子注文の数を最小化することが含まれても良い。レッグ又は取引戦略は、例えば、待ち時間、サーバ側デバイス、交換システム若しくはゲートウェイの物理的位置、トレーダの好み、交換能力、その他の既知の若しくは最近開発された基準、又はこれらのあらゆる組み合わせに基づきグループ化されても良い。

子取引注文を生成する際には、子注文におけるレッグの全て、いくつか又は１つが呼び値のレッグであっても良く、あるいは呼び値のレッグがなくても良い。すなわち、子注文は、あらゆる数の呼び値でないレッグおよび／又は呼び値のレッグを有しても良い。子注文の数は、例えば取引戦略におけるレッグの数、呼び値のレッグの数、待ち時間、交換能力又はこれらのあらゆる組み合わせに依存しても良い。子注文における呼び値でないレッグおよび呼び値のレッグの数は、同一であっても異なっても良い。子注文における呼び値でないレッグおよび呼び値のレッグの数は、子注文の間で変化しても変化しなくても良い。例えば、子注文において、呼び値のレッグは他の呼び値のレッグ又は呼び値でないレッグと混合されても良い。しかしながら、単一の呼び値でないレッグおよび呼び値のレッグが、代替的に又は付加的に独立しても良い。取引戦略デバイスは、子注文の数、それぞれの子注文における呼び値でないレッグの数若しくは呼び値のレッグの数、又はこれらの組み合わせを、例えば子注文を提出する際の待ち時間に基づいて決定しても良い。取引戦略デバイスは子注文を提出する際にかかる時間を最小化しても良い。

図９に戻ると、行為９３０において、取引戦略デバイスは取引トランザクションを完了しても良い。取引トランザクションの完了には、１つ以上のサーバ側デバイスへの子取引戦略注文の送信が含まれても良い。取引戦略デバイスは複数の子注文の送り先を知的に決定しても良い。例えば、子注文をサーバ側デバイスに送信しても良く、そのサーバ側デバイスは、子注文における呼び値のレッグを約定するよう構成された交換システムにて子注文を取引するよう構成されている。子注文を取引するよう構成されたサーバ側デバイスが複数存在する場合には、取引戦略デバイスは、交換システムに最も近いサーバ側デバイスに子注文を送信しても良い。例えば、図示のように、子注文を交換システムに最も近いサーバ側デバイスに送信し、子注文を交換システムに最も近いサーバ側デバイスに送信しても良い。

さらに、取引戦略デバイスは例えば、待ち時間に基づき子注文を送信するための通信経路を選択しても良い。待ち時間には、サーバ側デバイスや交換システムなどの受信デバイスが取引戦略デバイスからの子注文を受信するのに必要な時間が含まれる。取引戦略デバイスは、例えば取引戦略デバイスと交換システムとの間の遅延時間が最も少ない又は低減されている通信経路を介して子注文を提出することにより、待ち時間を低減又は最小化しても良い。通信経路は取引戦略デバイスと交換システムとを接続しても良い。一例では、通信経路には、取引戦略デバイスに遅延を報告する通信ノード、ルータ又はサーバなどの通信デバイスが含まれても良い。取引戦略デバイスは最適な（例えば、待ち時間が最も少ない）通信経路を決定するために情報を解析しても良い。

いくつかの実施形態では、方法９００には、子注文に関連付けられる呼び値の注文の提出が含まれても良い。呼び値の注文は、例えば交換システムによって必要とされるように構成された注文であっても良い。したがって、子注文は、呼び値の注文であっても良く、呼び値の注文と異なっても良い。すなわち、子注文は交換システムによって必要とされるように構成されても、そのように構成されなくても良い。サーバ側デバイスは呼び値の注文を提出する。

さらに、行為９３０には、ヘッジ注文の提出、部分的な約定注文の受信、部分的なヘッジ注文の提出、キャンセル注文の提出（例えば、注文が注文をキャンセルする）、取引戦略が実行されることの確保が含まれても良い。当然、呼び値の注文を取り扱う際にその他の行為が実施されても良い。

例示的な例証
次の例証は、分配型サーバ側デバイス環境の概念および利点のいくつかを示す。次の例証は、各種実施形態のうちのいくつかについて説明するのみであり、全ての実施形態を開示するものとして解釈されるべきではない。

トレーダは、ニューヨークに物理的に配置された顧客デバイスを用いるとともに、東京商品取引所（ＴＯＣＯＭ）およびシカゴマーカンタイル取引所（ＣＭＥ）にて取引される原油のスプレッド取引を行っている。本例証では、東京で取引される原油を「ＣＯＴ」とし、シカゴで取引される原油を「ＣＯＣ」とする。ニューヨークおよび取引所のある町の距離が長いことにより、以下で説明するように、分配型サーバ側環境を使用することの特別な利点が生じる。

取引セッションの間、トレーダは顧客デバイスを用いてスプレッド（例えば、ＣＯＴ−ＣＯＣ）のための取引注文を提出する。本例証では、スプレッドは２つのレッグを有する。第１のレッグはＣＯＴの購入に関連し、第２のレッグはＣＯＣの購入に関連する。トレーダは、例えば取引画面上の１つ以上のボックスをチェックすることで、両方のレッグが値付けされるべきであることを表示していても良い。したがって、スプレッドは複数の呼び値のレッグを有する。特に、スプレッドは２つの呼び値のレッグを有する。一旦受信されると、取引戦略は、スプレッドが２つの呼び値のレッグを有していることを識別する。これに応じて、取引戦略デバイスは、第１の子取引戦略注文を第１のサーバ側デバイスに送信し、第２の子取引戦略注文を第２のサーバ側デバイスに送信する。第１および第２のサーバ側デバイスは異なるサーバ側デバイスである。

第１のレッグのみが第１の子取引戦略注文にて値付けされ、第２のレッグのみが第２の子取引戦略注文にて値付けされることを除き、第１および第２の子取引戦略注文は、オリジナルの取引注文と同じ取引戦略に関連付けられる。

本例証では、取引戦略デバイスは顧客デバイスに又はその近傍に物理的に配置される。したがって、第１のサーバ側デバイスはＴＯＣＯＭに、その中に又はその近傍に配置され、第２のサーバ側デバイスはＣＭＥに、その中に又はその近傍に配置されるので、取引戦略デバイス（ニューヨーク）と第１のサーバ側デバイス（東京）との距離は約６７３５マイルであり、取引戦略デバイス（ニューヨーク）と第２のサーバ側デバイス（シカゴ）との距離は約７１１マイルである。したがって、取引戦略デバイスから第１のサーバ側デバイスへ又はその逆に送られるデータは約２２０ミリ秒かかり、取引戦略デバイスから第２のサーバ側デバイスへ又はその逆に送られるデータは約３０ミリ秒かかる。

第１のサーバ側デバイスがＴＯＣＯＭに、その中に又はその近傍に存在するので、第１のサーバ側デバイスからＴＯＣＯＭまでデータを転送する際にかかる時間は、概ね１０ミリ秒である。同様に、第２のサーバ側デバイスがＣＭＥに、その中に又はその近傍に存在するので、第２のサーバ側デバイスからＣＭＥまで又はその逆にデータを転送する際にかかる時間は、概ね１０ミリ秒である。これらの数字については単なる例である。

更なる説明の前に、本例証におけるそれぞれの値（例えば、時間や距離など）は例示の目的のみによるものであることに再度留意すべきである。これらの値のうちの１つ、いくつか又は全ては様々な理由により変更しても良く、将来的に変化しても良い。

第１および第２の子取引戦略が定義されると、取引戦略デバイスは、第１の子取引戦略注文を、ＴＯＣＯＭに、その中に又はその近傍にある第１のサーバ側デバイスに送信し、第２の子取引戦略注文を、ＣＭＥに、その中に又はその近傍にある第２のサーバ側デバイスに送信する。第１のサーバ側デバイスは、第１の子取引戦略注文にて値付けされた唯一のレッグである第１のレッグを取り扱うように構成され、第２のサーバ側デバイスは、第２の子取引戦略注文にて値付けされた唯一のレッグである第２のレッグを取り扱うように構成される。

注文の取り扱いの一部として、第１のサーバ側デバイスは第１の呼び値の注文を生成するとともに、第１の呼び値の注文をＴＯＣＯＭに提出する。第１のサーバ側デバイスは第２の呼び値の注文を生成するとともに、第２の呼び値の注文をＣＭＥに提出する。

呼び値の注文を取り扱う分配型サーバ側デバイスの利点の１つは、サーバ側デバイスと取引所との間におけるデータ転送が、複数の取引所にて複数の呼び値の注文を取り扱う単一のサーバ側デバイスの場合よりも小さいということである。すなわち、第１および第２の子取引戦略注文をＴＯＣＯＭにある単一のサーバ側デバイスが取り扱っていたとすると、その単一のサーバ側デバイスはＣＭＥからのデータを約２５０ミリ秒待つ必要があると予想される。第２のサーバ側デバイスが待つ必要のある約１０ミリ秒と比較すると、利点は非常に顕著である。

結論
本明細書は数多くの発明を含む。各種発明はそれらの適用が、要約書若しくは明細書に記載され又は図面に図示された構成要素の設計および配置の詳細に限定されない。それらの発明は他の実施形態も可能であり、あるいは様々な方法によって実験又は実行されても良い。なお、各種変形例を作成しても良く、均等物によって代用されても良く、および／又は多くの修正を施しても良い。発明が限定されないことを目的としている。

Claims (20)

1. 複数の呼び値のレッグを有する取引戦略による取引戦略注文を受信する工程と、
   取引戦略注文が複数の呼び値のレッグを有することを決定する工程と、
   取引戦略注文が複数の呼び値のレッグを有するとの決定に応じて、それぞれが取引戦略注文よりも少ない数の呼び値のレッグを有する複数の子注文を生成する工程と、
   マッチングのために複数の子注文を提出する工程とを、コンピューティングデバイスを用いて実行する工程を含む方法。
2. 複数の子注文は、マッチングのために第１の交換システムに提出される第１の子注文と、マッチングのために第２の交換システムに提出される第２の子注文とを含み、第１の交換システムは第２の交換システムと異なる、請求項１に記載の方法。
3. 第１の子注文は第１の呼び値のレッグのみを含み、第２の子注文は第２の呼び値のレッグのみを含む、請求項２に記載の方法。
4. 第１の子注文又は第２の子注文のマッチングは取引戦略注文のマッチングと同じである、請求項２に記載の方法。
5. マッチングのために子注文を提出する工程は、第１の交換システムに、その近傍に又はその中に物理的に配置される第１のサーバ側デバイスに第１の子注文を送る工程と、第２の交換システムに、その近傍に又はその中に物理的に配置される第２のサーバ側デバイスに第２の子注文を送る工程とを含み、第１のサーバ側デバイスは第２のサーバ側デバイスと異なる、請求項２に記載の方法。
6. 第１のサーバ側デバイスは第１の交換システムにて第１の子注文を取り扱い、第２のサーバ側デバイスは第２の交換システムにて第２の子注文を取り扱う、請求項５に記載の方法。
7. マッチングのために複数の子注文を提出する工程は、待ち時間に基づいてマッチングを行うために複数の子注文を提出する工程を含む、請求項１に記載の方法。
8. プロセッサによって実行可能な命令が内部に保存されたコンピュータ読み取り可能媒体であって、その命令は、
   複数の呼び値のレッグを有する取引戦略を備える取引戦略注文を受信し、
   取引戦略注文が複数の呼び値のレッグを有することを決定し、
   取引戦略注文が複数の呼び値のレッグを有するときに、それぞれが取引戦略注文よりも少ない数の呼び値のレッグを有する複数の子注文を生成し、
   マッチングのために複数の子注文を提出するように、実行可能である、コンピュータ読み取り可能媒体。
9. 複数の子注文は、マッチングのために第１の交換システムに提出される第１の子注文と、マッチングのために第２の交換システムに提出される第２の子注文とを含み、第１の交換システムは第２の交換システムと異なる、請求項８に記載のコンピュータ読み取り可能媒体。
10. 複数の子注文を生成するように実行可能な命令は、第１の呼び値のレッグのみを有する第１の子注文と第２の呼び値のレッグのみを有する第２の子注文とを生成するように実行可能な命令を含む、請求項９に記載のコンピュータ読み取り可能媒体。
11. 第１の子注文又は第２の子注文のマッチングは取引戦略注文のマッチングと同じである、請求項９に記載のコンピュータ読み取り可能媒体。
12. マッチングのために子注文を提出するための命令は、第１の交換システムに、その近傍に又はその中に物理的に配置される第１のサーバ側デバイスに第１の子注文を送り、第２の交換システムに、その近傍に又はその中に物理的に配置される第２のサーバ側デバイスに第２の子注文を送るように実行可能な命令を含み、第１のサーバ側デバイスは第２のサーバ側デバイスと異なる、請求項８に記載のコンピュータ読み取り可能媒体。
13. 第１のサーバ側デバイスは第１の交換システムにて第１の子注文を取り扱い、第２のサーバ側デバイスは第２の交換システムにて第２の子注文を取り扱う、請求項１２に記載のコンピュータ読み取り可能媒体。
14. マッチングのために複数の子注文を提出するように実行可能な命令は、待ち時間に基づくマッチングのために複数の子注文を提出するように実行可能な命令を含む、請求項８に記載のコンピュータ読み取り可能媒体。
15. 複数の呼び値のレッグを有する親取引戦略を備える取引戦略注文を受信する工程と、
    取引戦略注文を、単一の呼び値のレッグを有する子取引戦略をそれぞれが有する複数の子注文に分割する工程であって、子取引戦略は、呼び値のレッグとされるレッグの数を除き、親取引戦略と同じである工程と、
    子注文における呼び値のレッグを約定するように構成された交換システムに対して、複数の子注文のそれぞれを提出する工程とを、取引戦略デバイスを用いて実行する工程を含む方法。
16. 分割する工程は、取引戦略注文が複数の呼び値のレッグを有するかどうかを決定する工程を含む、請求項１５に記載の方法。
17. 分割する工程は、子取引戦略を定義して複数の子注文を生成する工程を含み、それらの子注文は、１つ以上の子取引戦略のためのものである、請求項１６に記載の方法。
18. １つ以上の交換システムは、第１の交換システムと第２の交換システムとを備える、請求項１５に記載の方法。
19. 最初の注文の分割は、最初の注文が第１の交換システムに送られる前に１つ以上の交換システムにおいて生じる、請求項１５に記載の方法。
20. 提出する工程は待ち時間に基づく、請求項１５に記載の方法。

Images