"複数の呼び値のレッグを有する取引戦略による取引戦略注文を受信する工程と、取引戦略注文が複数の呼び値のレッグを有することを決定する工程と、取引戦略注文が複数の呼び値のレッグを有するとの決定に応じて、それぞれが取引戦略注文よりも少ない数の呼び値のレッグを有する複数の子注文を生成する工程と、マッチングのために複数の子注文を提出する工程とを、コンピューティングデバイスを用いて実行する工程を含む方法。複数の子注文は、マッチングのために第1の交換システムに提出される第1の子注文と、マッチングのために第2の交換システムに提出される第2の子注文とを含み、第1の交換システムは第2の交換システムと異なる、請求項1に記載の方法。第1の子注文は第1の呼び値のレッグのみを含み、第2の子注文は第2の呼び値のレッグのみを含む、請求項2に記載の方法。第1の子注文又は第2の子注文のマッチングは取引戦略注文のマッチングと同じである、請求項2に記載の方法。マッチングのために子注文を提出する工程は、第1の交換システムに、その近傍に又はその中に物理的に配置される第1のサーバ側デバイスに第1の子注文を送る工程と、第2の交換システムに、その近傍に又はその中に物理的に配置される第2のサーバ側デバイスに第2の子注文を送る工程とを含み、第1のサーバ側デバイスは第2のサーバ側デバイスと異なる、請求項2に記載の方法。第1のサーバ側デバイスは第1の交換システムにて第1の子注文を取り扱い、第2のサーバ側デバイスは第2の交換システムにて第2の子注文を取り扱う、請求項5に記載の方法。マッチングのために複数の子注文を提出する工程は、待ち時間に基づいてマッチングを行うために複数の子注文を提出する工程を含む、請求項1に記載の方法。プロセッサによって実行可能な命令が内部に保存されたコンピュータ読み取り可能媒体であって、その命令は、複数の呼び値のレッグを有する取引戦略を備える取引戦略注文を受信し、取引戦略注文が複数の呼び値のレッグを有することを決定し、取引戦略注文が複数の呼び値のレッグを有するときに、それぞれが取引戦略注文よりも少ない数の呼び値のレッグを有する複数の子注文を生成し、マッチングのために複数の子注文を提出するように、実行可能である、コンピュータ読み取り可能媒体。複数の子注文は、マッチングのために第1の交換システムに提出される第1の子注文と、マッチングのために第2の交換システムに提出される第2の子注文とを含み、第1の交換システムは第2の交換システムと異なる、請求項8に記載のコンピュータ読み取り可能媒体。複数の子注文を生成するように実行可能な命令は、第1の呼び値のレッグのみを有する第1の子注文と第2の呼び値のレッグのみを有する第2の子注文とを生成するように実行可能な命令を含む、請求項9に記載のコンピュータ読み取り可能媒体。第1の子注文又は第2の子注文のマッチングは取引戦略注文のマッチングと同じである、請求項9に記載のコンピュータ読み取り可能媒体。マッチングのために子注文を提出するための命令は、第1の交換システムに、その近傍に又はその中に物理的に配置される第1のサーバ側デバイスに第1の子注文を送り、第2の交換システムに、その近傍に又はその中に物理的に配置される第2のサーバ側デバイスに第2の子注文を送るように実行可能な命令を含み、第1のサーバ側デバイスは第2のサーバ側デバイスと異なる、請求項8に記載のコンピュータ読み取り可能媒体。第1のサーバ側デバイスは第1の交換システムにて第1の子注文を取り扱い、第2のサーバ側デバイスは第2の交換システムにて第2の子注文を取り扱う、請求項12に記載のコンピュータ読み取り可能媒体。マッチングのために複数の子注文を提出するように実行可能な命令は、待ち時間に基づくマッチングのために複数の子注文を提出するように実行可能な命令を含む、請求項8に記載のコンピュータ読み取り可能媒体。複数の呼び値のレッグを有する親取引戦略を備える取引戦略注文を受信する工程と、取引戦略注文を、単一の呼び値のレッグを有する子取引戦略をそれぞれが有する複数の子注文に分割する工程であって、子取引戦略は、呼び値のレッグとされるレッグの数を除き、親取引戦略と同じである工程と、子注文における呼び値のレッグを約定するように構成された交換システムに対して、複数の子注文のそれぞれを提出する工程とを、取引戦略デバイスを用いて実行する工程を含む方法。分割する工程は、取引戦略注文が複数の呼び値のレッグを有するかどうかを決定する工程を含む、請求項15に記載の方法。分割する工程は、子取引戦略を定義して複数の子注文を生成する工程を含み、それらの子注文は、1つ以上の子取引戦略のためのものである、請求項16に記載の方法。1つ以上の交換システムは、第1の交換システムと第2の交換システムとを備える、請求項15に記載の方法。最初の注文の分割は、最初の注文が第1の交換システムに送られる前に1つ以上の交換システムにおいて生じる、請求項15に記載の方法。提出する工程は待ち時間に基づく、請求項15に記載の方法。本明細書では、電子取引に関する多くの実施形態が示される。特に、多くの実施形態は、分配型サーバ側デバイスのアーキテクチャを用いた複数の呼び値のレッグを有する、取引戦略のための注文取引戦略注文とも呼ばれるに関する。顧客デバイスと複数のサーバ側デバイスとの間に配置された取引戦略デバイスは、取引戦略注文を、複数の子取引戦略注文に分けることができる。これらの子取引戦略注文は子注文とも呼ばれる。それぞれの子注文は、単一の又は少ない数の呼び値のレッグを有した小取引戦略にしたがう例えば、最初の取引戦略注文。子取引戦略は、呼び値のレッグの数を除くと、取引戦略注文における取引戦略と同じ又は実質的に同じである。したがって、それぞれの子注文は、単一の呼び値のレッグ又は取引戦略注文よりも少ない数の呼び値のレッグに関連する場合がある。取引戦略デバイスは、注文を交換システムとともに働かせるように構成されるサーバ側デバイスに子注文を送ることができる。サーバ側デバイスは子注文を受けて、子注文におけるそれぞれの呼び値のレッグ用の呼び値の注文を作り、その呼び値の注文を提出する。呼び値の注文は提出されて、交換システムとともに働く。これから説明する前に、様々な発明はその応用として、前述又は後述の詳細な説明や図面に示される構成要素の設計や配置の詳細に限定されないことをここに再度記す。代わりに、前述又は後述の詳細な説明および図面は、独立している、あるいは互いに又は他の実施形態に組み合わされ得る各種発明の主な概念に着目する。I.電子取引システムの典型例について図1は、電子取引システム取引システム100のブロック図を示す。取引システム100は、1つ以上の顧客システム110と、1つ以上のサーバ側デバイス120と、1つ以上の交換システム140とを備える。より詳細には図1に示すように、取引システム100は、顧客システム110に加えて、サーバ側デバイス120a、サーバ側デバイス120b、ゲートウェイ130a、ゲートウェイ130b、交換システム140aおよび交換システム140bを備える。顧客システム110は、顧客デバイス112と、取引戦略デバイス114とを備える。他の取引システムにおいては、付加的な、異なる、あるいは少ない数の構成要素が設けられる。システム100は例えば、N個の顧客システム、N個のサーバ側デバイス、N個のゲートウェイ、N個の交換システム、あるいはこれらの任意の組み合わせを備えても良い。すなわち、システム100は複数のシステムや構成要素を備えるように、拡大縮小可能である。顧客システムについて顧客システム110は、サーバ側デバイス120、ゲートウェイ130、交換システム140あるいはこれらの組み合わせと、例えば1つ以上の通信ネットワーク102を介して通信を行う。例えば図1に示すように、顧客システム110は、通信ネットワーク102aを介してサーバ側デバイス120aおよびゲートウェイ130aと接続され通信を行う。同様に、顧客システム110は、通信ネットワーク102bを介してサーバ側デバイス120bおよびゲートウェイ130bと接続され通信を行う。通信ネットワークには例えば、1つ以上の通信バス、T1回線、T3回線、サービス総合デジタル網ISDN回線、有線ネットワーク、無線ネットワーク、POPネットワーク、ローカルネットワーク、遠隔ネットワーク、インターネット、あるいはこれらの任意の組み合わせが含まれる。接続との用語には、直接的に接続される場合や、1つ以上の中間構成要素を介して間接的に接続される場合が含まれる。またそのような中間構成要素には、ハードウェア例えばサーバ、ルータ、ゲートウェイ、スイッチなど、ソフトウェア例えば取引アプリケーションや通信アプリケーションなど、付加的な通信ネットワーク、あるいはこれらの任意の組み合わせが含まれる。顧客システム110の全て又はそのいくつかは、1つ以上のサーバ側デバイス120、ゲートウェイ130、交換システム140、あるいはこれらの組み合わせと物理的に同じ場所に配置されても良く、あるいは異なる場所に配置されても良い。例えば、ウィスコンシン州のミルウォーキー郡にあるオフィスビルに、顧客システム110の全体を物理的に配置しても良い。しかしながら、サーバ側デバイス120a、ゲートウェイ130aおよび交換システム140aを物理的にイリノイ州のシカゴやその周辺に配置し、サーバ側デバイス120b、ゲートウェイ130bおよび交換システム140bを物理的に日本の東京に配置するようにしても良い。別の例では、分配型の顧客システム110および顧客デバイス112がウィスコンシン州のミルウォーキー郡にあるオフィスビルに物理的に配置され、取引戦略デバイス114がイリノイ州のシカゴやその周辺に配置される場合を示す。上述のように、顧客システム110は、顧客デバイス112と取引戦略デバイス114とを備える。顧客システム110は、サーバ、ゲートウェイ、ルータ、スイッチ、コンピュータ、顧客デバイス、取引戦略デバイス、アプリケーションあるいはその他の通信デバイスなど、付加的な、異なるあるいは少ない数の構成要素を備えても良い。例えば、顧客デバイスが複数あっても良い。複数の顧客デバイスの全て又はそのいくつかが同じ取引戦略デバイスを使用するようにしても良い例えば、顧客デバイスと取引戦略デバイスとが多対一。別の例においては、顧客デバイスが複数設けられる一方で、それぞれの顧客デバイスが単一の取引戦略デバイスを使用している例えば、顧客デバイスと取引戦略デバイスとが一対一。顧客デバイスについて顧客デバイス112は、携帯用デバイス、ラップトップコンピュータ、デスクトップコンピュータ、サーバ、パソコン、通信エンドポイント、電子取引ワークステーション、コンピュータデバイス、ポータブル取引デバイス、アルゴリズム取引システム又はブラックボックスシステム、組込型取引システム、自動取引ツール、あるいはこれらの任意の組み合わせであっても良い。顧客デバイス112は、ユーザによって所有、操作、制御、プログラム、設定あるいはそれ以外の使用がされても良い。ユーザとの用語には、これらに限定されないが、人間例えば、トレーダーや電子取引デバイス例えば、プロセッサとメモリあるいはアルゴリズム取引システムなどが含まれるが含まれても良い。1以上のユーザが所有、操作、制御、プログラミング、設定あるいはその他の使用に従事しても良い。顧客デバイス112は、市場データを受信し又は表示し、あるいは受信するとともに表示しても良い。市場データは、交換システム140a又は交換システム140bなどの交換システムから受信されても良い。市場データには、共通して1つ以上の取引可能オブジェクトに関する情報を有する市場情報が含まれても良い。市場データには、呼び値のデータ例えば、買い/売りの呼び値データ、買い/売りの数量データ、市場深度データなど、取引データ例えば、最終売りデータ、最終数量データ、最終量データ、確認コンファメーションデータ例えば、約定確認、取引確認など、その他の交換関連データ、あるいはこれらの任意の組み合わせが含まれても良い。市場データには、これらに限定されないが、各種取引可能オブジェクトの価格、様々な所定の時間における取引可能オブジェクトの買いの量、どのような量および/又は価格のときに何の取引が生じたかを示す取引確認、あるいは取引が約定されたことを示す約定確認が含まれても良い。市場データには例えば、場内市場を示すデータが含まれても良い。場内市場は、ある特定の時点における一番安い売り値又は売り出し価格一番安い指値価格bestaskともいう並びに、ある特定の時点における一番高い買い値又は入札価格一番高い指値価格ともいうである。市場データには市場深度データが含まれても良い。市場深度は、ある時点におけるある価格の取引可能オブジェクトに対する取引注文の数のことをいう。交換システム140によって顧客システム110又は異なるシステムのいずれかからの取引注文が受信されるときに、市場深度は変化する場合がある。ある実施形態では、市場深度は全ての価格レベルにおいて存在するが、他の実施形態では、それよりも少ない数の価格レベルにおいて存在する。市場データには、最終取引価格LTP、最終取引数量LTQおよびその他の約定情報等が含まれても良い。顧客デバイス112は1つ以上の入力部を備えても良い。入力部は例えば、入力デバイスやネットワークインタフェース、あるいはその両方であっても良い。入力部は、市場データ、ユーザ入力データ、市場データとユーザ入力データの両方、その他の取引データ例えば、識別、パスワード、アルゴリズムなど、あるいはこれらの組み合わせを受信するようにしても良い。ユーザ入力データには、1つ以上の取引可能オブジェクトの定義などのユーザからの受信データが含まれても良い。例示的な入力デバイスは例えば、マウス、キーボード、トラックボール、タッチスクリーン、ジョイスティック、タッチパッド、ユーザインタフェース、マイクロホン、ボタン、ノブ、スライダ、これらの組み合わせ、あるいはその他の現在知られた又は最近開発されたユーザ入力デバイスを備える。例えば、入力デバイスは、ユーザインタフェースである。ユーザインタフェースは、ユーザによる取引画面との接触を可能にするアプリケーションプログラミングインタフェースであっても良い。ユーザインタフェースは、取引アプリケーションにおけるテキスト又はグラフィカルのインタフェースをユーザに表示する1つ以上の表示デバイスに関連付けられても良い。表示デバイスは、コンピュータモニタ、ハンドヘルドデバイス表示装置、プロジェクタ、および/又はテレビであっても良い。ある例では、ユーザインタフェースは市場データを表示し、別の例では、ユーザインタフェースは、自動化された取引戦略を構築するためにブロックや接続線を用いて取引戦略をプログラミングするシステムをユーザがソースコードを理解していなくとも簡単に使用できるようにしている。さらに別の例では、ユーザインタフェースは、ユーザが取引アプリケーションを用いて注文に関するパラメータを特定又は検討するために用いられる。ネットワークインタフェースには、配線で接続された又は無線のネットワークインタフェースが含まれても良い。万能非同期送受信機UART、パラレルデジタルインタフェース、ソフトウェアインタフェース、イーサネット、あるいは既に知られている又は最近開発されたソフトウェアインタフェースおよびハードウェアインタフェースを各種組み合わせたものを用いても良い。ネットワークインタフェースは、ローカルエリアネットワークLAN、ワイドエリアネットワークWAN、インターネット、および仮想プライベートネットワークVPNを含む各種ネットワークにリンクされても良い。顧客デバイス112は1つ以上の取引可能オブジェクトを売る又は買うために用いられても良い。取引可能オブジェクトは実際あるいは合成のものであっても良い。実際の取引可能オブジェクトは、交換によってリストされる製品である。合成の取引可能オブジェクトは、ユーザによって定義され、交換によってはリストされない製品である。例えば、合成の取引可能オブジェクトには、トレーダによって顧客デバイス112を用いて作り出された合成スプレッドなどの実際又はその他の合成の製品を組み合わせたものも含まれる。合成の取引可能オブジェクトは、例えば1つ以上の実際の取引可能オブジェクトから暗示される取引可能オブジェクトのように、暗示されても良い。顧客デバイス112は1つ以上の電子コンピューティングプラットフォームを備えても良い。一般的な電子コンピューティングプラットフォームは、プロセッサと、プロセッサによって実行される命令を保存するコンピュータ読み取り可能媒体とを備える。その他の電子ンピューティングプラットフォームには、コンピューティングデバイスや処理コンポーネントなどが用いられても良い。取引の目的に応じて、顧客デバイス112は1つ以上の取引アプリケーションを備えても良い。取引アプリケーションは例えば、取引およびチャートのウィンドウに市場データを配列および表示することで、市場データを処理しても良い。例えば、取引アプリケーションを用いることで、ユーザは取引可能オブジェクトを定義するとともに、定義された取引可能オブジェクトに対する注文を提出することができる。この処理はユーザの好みに基づいても良い。1つ以上の取引アプリケーションはコンピュータ読み取り可能媒体に保存された1つ以上の命令を有しても良い。電子コンピューティングプラットフォームは、本明細書に説明、例示又は図示される1つ以上の機能を行うように取引アプリケーションを実行しても良い。取引アプリケーションは自動取引ツールを備えても良い。一例として、顧客デバイス112は、イリノイ州シカゴのTradingTechnologiesInternational社が提供する電子取引プラットフォームであるX_TRADER登録商標のコピーを実行するワークステーションであっても良い。別の例として、顧客デバイス112は、同じくTradingTechnologiesInternational社が提供するAutospreader登録商標などの自動取引ツールを実行するサーバであっても良い。取引戦略デバイスについて取引戦略デバイス114は、ハンドヘルドデバイス、ラップトップコンピュータ、デスクトップコンピュータ、サーバ、パソコン、エンドポイント、電子取引ワークステーション、コンピューティングデバイス、携帯取引デバイス、アルゴリズム取引システム又はブラックボックスシステム、組込型取引システム、自動取引ツール、あるいはこれらの任意の組み合わせであっても良い。取引戦略デバイス114は例えば、管理デバイス、モニタデバイス、分割デバイス、もしくは注文エントリデバイスともいう。取引戦略デバイス114は顧客デバイス112と物理的に同じ場所又は異なる場所に配置されても良い。例えば、取引戦略デバイス114は顧客デバイス112と物理的に同じオフィス又は同じビルに配置されても良い。図1に示すように、顧客デバイス112および取引戦略デバイス114は異なるデバイスであっても良い。しかしながら、他の例では、顧客デバイス112および取引戦略デバイス114は、単体のユニットとして機能する同一のデバイスであっても良い。例えば、取引戦略デバイス114は顧客デバイス112に組み込まれても良い。組み込まれとの用語には、同一のプロセッサ、メモリ、又はその両方を用いることや、同一の筐体又は接続された筐体を有すること、それ以外に互いに結合又は操作されることが含まれる。しかしながら、取引戦略デバイス114の物理的な位置は取引システム100に応じて変更しても良い。例えば、各種実施形態では、取引戦略デバイス114は、1つ以上のサーバ側デバイス120、ゲートウェイ130、交換システム140、あるいはこれらの組み合わせと物理的に同一の場所又は異なる場所に配置される。例えば、取引戦略デバイス114はサーバ側デバイス120に組み込まれても良い。別の例では、取引戦略デバイス114は、交換システム140と通信するゲートウェイ130に組み込まれても良い。取引戦略デバイス114は1つ以上の電子コンピューティングプラットフォームを備えても良い。電子取引の目的に応じて、取引戦略デバイス114は1つ以上の取引アプリケーションを備えても良い。1つ以上の電子コンピューティングプラットフォームは、顧客デバイス112が本明細書に説明、例示又は図示される1つ以上の機能を実施するように、1つ以上の取引アプリケーションを実行するようにしても良い。例えば、取引アプリケーションは、図4、9、10に示される行為のうち1つ、いくつか又は全てを実施するように実行されても良い。取引戦略デバイス114は、1つ以上の取引注文を送信および受信しても良い。例えば、取引戦略デバイス114は顧客デバイス112から取引戦略注文を受け取るとともに、1つ以上の子取引戦略注文をサーバ側デバイス120に送信しても良い。取引戦略注文又は子取引戦略注文などの取引注文は、あらゆるコンフィギュレーションデータ、価格データ、数量データ、又はこれらのあらゆる組み合わせを含んでも良い。取引注文は、呼び値の注文を行うのに必要な情報の全て、その情報の全てよりも少ない情報、その情報の全てよりも多い情報、あるいはこれらの組み合わせを含んでも良い。取引注文内の情報量は例えば、情報を受信するコンポーネント、呼び値の注文をするのに必要な情報量、すでに送信された情報量、これらの組み合わせ、あるいはその他の事項に依存するようにしても良い。例えば、いくつかの実施形態では、取引注文は価格データおよび数量データを含むが、必ずしもコンフィギュレーションデータを含まない。すなわち、コンフィギュレーションデータは例えば、最初に取引戦略デバイス又はサーバ側デバイスに送信される価格データおよび数量データとともに、又はそれらに先立って送信されても良い。コンフィギュレーションデータは例えば、取引戦略デバイス又はサーバ側デバイスに保存されても良い。コンフィギュレーションデータがすでに取引戦略デバイス又はサーバ側デバイスにある場合、次の価格データおよび数量データをコンフィギュレーションデータと組み合わせても良く、あるいはコンフィギュレーションデータとともに用いても良い。コンフィギュレーションデータに変化が生じた場合、その変化の直後の取引注文の価格データおよび数量データに先立って又はそれらとともに、アップデートされたコンフィギュレーションデータが送信されても良い。その他の実施形態では、取引注文は価格データを含むが、必ずしも質量データを含まない。すなわち、例えば、価格データは、質量データに先立って、質量データとともに、あるいは質量データよりも後に送信されても良い。取引戦略デバイス114は1つ以上の顧客デバイス112を管理するよう構成される。例えば、取引戦略デバイス114は、複数の顧客デバイス112に接続されることが可能である。顧客デバイス112は、取引戦略デバイス114に注文を送信しても良い。取引戦略デバイス114は、注文を受信するとともに注文の提出を管理するよう構成されても良い。注文の管理には、注文の提出に関する取扱いworking、操作、移動、支配、制御、完遂への試み、完遂への成功が含まれても良い。後で詳細に説明するように、管理には、顧客デバイス112から受信した注文の分割が含まれても良い。サーバ側デバイスについてサーバ側デバイス120は、サーバ、ゲートウェイ、パソコン、その他の現在知られている又は最近開発された通信デバイス、あるいはこれらの組み合わせであっても良い。例えば、サーバ側デバイスは、TradingTechnologiesInternational社が提供するAutospreader登録商標などの自動取引ツールを実行するサーバであっても良い。自動取引ツールは顧客デバイス112用いて制御されても良いが、サーバは交換システム130に、その周囲に、又はその近辺に物理的に配置されても良い。通信の目的に応じて、サーバ側デバイス120aは取引戦略デバイス114および交換システム140aに接続される。サーバ側デバイス120bは取引戦略デバイス114および交換システム140bに接続される。例えば、サーバ側デバイス120は、交換システム140と通信するゲートウェイを有しても良く、あるいはそのゲートウェイに接続されても良い。ゲートウェイはプロトコル変換を実行しても良い。サーバ側デバイス120は交換システム130に、その近辺に、あるいはその中に物理的に配置される。サーバ側デバイスは、呼び値の注文を取り扱う交換システムに、その近辺に、あるいはそれぞれの交換システムの中に配置されても良い。すなわち、分配型サーバ側デバイスのアーキテクチャは、異なる交換システムに2つ以上のサーバ側デバイスが分配されたシステム又は環境である。単一のサーバ側デバイスが複数の交換システムにおいて呼び値の注文を取り扱う必要がないように、サーバ側デバイスは交換システムとともに呼び値の注文を取り扱う。サーバ側デバイス120は、TradingTechnologiesInternational社が提供する自動取引ツールであるAutospreader登録商標を実行する自動取引サーバであっても良い。自動取引サーバは、金融情報交換FinancialInformationeXchangeFIXゲートウェイなどのゲートウェイを介して交換システム140と通信しても良く、あるいは交換システムと直接通信するようにしても良い。自動取引サーバおよびFIXゲートウェイは、例えば電子取引の速度および効率を増やすために、交換システムの近傍の場所に配置されても良い。サーバ側デバイス120は、取引戦略デバイス114からの1つ以上の取引可能オブジェクトを売買する注文を受信するとともに、注文を約定させるための交換システムにその注文を提出するようにしても良い。したがって、サーバ側デバイスは、交換システムとともに注文を取り扱うよう構成されても良い。注文の取り扱いには、注文の提出、注文の再値付け、注文のキャンセル、ヘッジ注文の送信、未処理注文の管理、あるいはこれらのあらゆる組み合わせが含まれても良い。未処理注文とは、交換システムに提出されたものの未だ約定していない注文のことである。すなわち、交換システムは、未処理注文のうちの全て又はそのいくつかを反対側contrasideの注文とマッチング照合することを試みる。未処理注文の管理には例えば、顧客デバイスへの報告、市場最新情報の追跡、それ以外にも、1つ以上の取引機能の実行が含まれる。交換システムについて交換システム140は、同一の又は異なる金融取引所例えば、シカゴマーカンタイル取引所およびシカゴ商品取引所によって所有、操作、制御又は使用されても良い。以降で詳細に説明するように、交換一ステムは注文を受信および約定するために用いられても良い。交換システム140は、同一の又は異なる交換の一部であっても良い。交換システムは、注文をマッチングするよう構成される。例えば、交換システムは、マッチングエンジンを備えても良い。マッチングエンジンは注文をマッチングするように構成されても良い。特に、マッチングエンジンは、買い値および売り出し価格をマッチングするように構成される。マッチングエンジンは、買いおよび売り出しをマッチングするための1つ以上のアルゴリズムを実行するソフトウェアで動作されても良い。交換システム130は、注文が約定したときに約定確認を提供するように構成されても良い。約定確認は例えば、サーバ側デバイス120に提供されても良い。交換システム130は、付加的な、異なる又は少数のコンポーネントを備えても良い。例えば、取引を識別する情報および取引の説明を保存するために、取引データベースが備えられても良い。取引データベースは、取引が生じた時間と約定価格を識別する情報を保存しても良い。最新の買い値および売り出し価格を計算あるいは決定するために、注文一覧モジュールが備えられても良い。市場データを収集し、ユーザへの送信用データを準備するために、市場データモジュールが備えられても良い。ユーザの明確な危険閾値に関して、ユーザのリスク利用を計算および決定するために、リスク管理モジュールが備えられても良い。注文一覧モジュールおよびマッチングエンジンによる処理用として、変化しやすい金融派生商品を分解するとともに注文の種類を集計するために、注文処理モジュールが備えられても良い。交換システム130は市場データを提供するよう構成されても良い。市場データは、例えば1つ以上のゲートウェイを介して、顧客デバイス112へ提供されても良い。別の例では、交換システム130は市場最新情報を提供する。市場最新情報には、市場における変化例えば、価格の変化、部分的な約定partialfills、又は未処理の注文に影響する可能性があるその他の最新情報が含まれても良い。市場最新情報は例えば、サーバ側デバイス120又は未処理の注文を管理するその他のデバイスに提供されても良い。注文が約定すると、交換システム130は、例えば約定確認を送信することで約定を知らせても良い。約定確認はサーバ側デバイス120に送信されても良い。例えば、交換システム140aが注文をマッチングする場合に、約定確認をサーバ側デバイス120aに送信しても良い。次に、約定確認はその他のコンポーネントに送信される。例えば、約定確認は顧客デバイス112および/又は取引戦略デバイス114に送信されても良い。あるいは、又は、さらに、約定確認は取引戦略デバイス114又は顧客デバイス112に送信されても良い。明確化のために図示していないが、システム100は、ミドルウェア、ファイアウォール、ハブ、スイッチ、ルータ、ゲートウェイ、交換に特化した通信装備、モデム、セキュリティマネージャ、および又は暗号化/復号化デバイスなどの通信アーキテクチャに固有な他のデバイスを備えても良い。戦略取引ユーザは、1つの取引可能オブジェクトの売りおよび/又は買いに加えて、取引戦略に基づいて1つよりも多くの取引可能オブジェクトを取引するように、顧客デバイス112を利用しても良い。取引戦略は、取引される2つ以上の取引可能オブジェクト間の関係を定義する。取引戦略の一部として取引されるそれぞれの取引可能オブジェクトは、取引戦略のレッグ又はアウトライト市場とも呼ばれる。1つの共通な取引戦略はスプレッドであり、スプレッドによる取引はスプレッド取引と呼ばれる。スプレッド取引は、取引戦略内の取引可能オブジェクト間の関係の変化又は移動から利益を得ることを目指すものである。取引戦略が買われるときには、取引戦略における定義が、それぞれのレッグに対応するどの取引可能オブジェクトを買う又は売るべきかを特定する。同様に、取引戦略が売られるときには、その定義が、それぞれのレッグに対応するどの取引可能オブジェクトを買う又は売るべきかを特定する。例えば、取引戦略を買うことに、レッグAの第1の取引可能オブジェクトを1単位買うことと、レッグBの第2の取引可能オブジェクトを1単位売ることが含まれるように、取引戦略が定義されても良い。取引戦略を売ることには、それぞれのレッグに対して反対の行為を実行することが通常含まれる。さらに、取引戦略における定義は、取引戦略のそれぞれのレッグに関連するスプレッド比率を特定しても良い。スプレッド比率は、レッグの注文サイズとも呼ばれる。スプレッド比率は、他のレッグに関連してそれぞれのレッグの数量を示す。例えば、取引戦略を買うことに、レッグAの第1の取引可能オブジェクトを2単位買うことと、レッグBの第2の取引可能オブジェクトを3単位買うことが含まれるように、取引戦略が定義されても良い。スプレッド比率の符号を用いることで、取引戦略を買うときにどのレッグを買うスプレッド比率がプラス又は売るスプレッド比率がマイナスべきか示すようにしても良い。上述の例では、レッグAに関連するスプレッド比率は2でレッグBに関連するスプレッド比率は-3である。いくつかの例では、スプレッド比率は暗示されても良く、又は暗示的であっても良い。例えば、取引戦略のレッグのスプレッド比率は明確に特定しなくても良く、むしろ1または-1であることが暗示、またはこれらにデフォルトされても良い。さらに、取引戦略における定義は、取引戦略のそれぞれのレッグに関連する乗数を規定しても良い。乗数は、スプレッドの価格を決定するための特定のレッグの価格を調整するために用いられる。それぞれのレッグの乗数はスプレッド比率と同じであっても良い。例えば、上述の例では、レッグAに関連する乗数は2で、レッグBに関連する乗数は-3であって、両方の乗数がそれぞれのレッグの対応するスプレッド比率にマッチングしている。あるいは、1つ以上のレッグに関連する乗数は、それらのレッグの対応するスプレッド比率と異なっても良い。例えば、レッグの価格を共通通貨に変換するために、乗数の値を選択しても良い。以降の議論においては、特に指定のない限り、それぞれのレッグのスプレッド比率および乗数が同じであるものとする。さらに、以降の議論においては、特定のレッグにおけるスプレッド比率および乗数の符号は同じとするが、そうでない場合には、乗数の符号は特定のレッグが取引戦略のどちら側にあるかを決定するために用いられる。図2は、例示的な取引戦略210のブロック図を示す。取引戦略210はN個のレッグ220を有する。レッグは、取引可能オブジェクト、取引可能オブジェクトの注文、取引可能オブジェクトの潜在注文、取引可能オブジェクトに関連する取引の一部分を指す。そのため、レッグはアウトライトとも呼ばれる。取引戦略210は、それぞれのレッグ220に関連するスプレッド比率224および乗数226を用いて、各レッグ220の取引可能オブジェクト222間の関係を定義する。定義されると、取引戦略210中の取引可能オブジェクト222は定義された関係に基づいて互いに取引される。以降の議論においては、特に指定のない限り、それぞれのレッグのスプレッド比率224および乗数226が同じであるものとする。さらに、以降の議論においては、特定のレッグにおけるスプレッド比率224および乗数226の符号は同じとするが、そうでない場合には、乗数226の符号は特定のレッグが取引戦略のどちら側にあるかを決定するために用いられる。ある例証本明細書では上述の例証と呼ぶにおいて、取引戦略210は2つのレッグ220を有するスプレッドである。レッグ1は取引可能オブジェクトAに対応し、レッグ2は取引可能オブジェクトBに対応する。レッグ1およびレッグ2に関連するスプレッド比率224および乗数226はそれぞれ1および-1であっても良い。スプレッド210は、スプレッド210が買われるときに、取引可能オブジェクトAが1単位買われスプレッド比率がプラスかつ方向がスプレッドと同じ、取引可能オブジェクトBが1単位売られるスプレッド比率がマイナスかつ方向がスプレッドと反対ように定義されても良い。スプレッド取引においては、定義の反対のものが通常、適用される。例えば、スプレッド210は、スプレッド210が売られるときに、取引可能オブジェクトAが1単位売られスプレッド比率がプラスかつ方向がスプレッドと同じ、取引可能オブジェクトBが1単位買われるスプレッド比率がマイナスかつ方向がスプレッドと反対ように定義される。取引戦略210の価格は、取引戦略の提議に基づいて決定されても良い。取引戦略210の価格は通常、取引戦略210のそれぞれのレッグ220において取引可能オブジェクト222に乗数226を掛けて合計したものである。上述の例証では、ユーザが取引可能オブジェクトAの価格は通常、取引可能オブジェクトBよりも10高いと考えている場合においては、両オブジェクトの価格差が10より小さい場合に常にユーザがスプレッドの買いを希望する場合があり、また両オブジェクトの価格差が10より大きい場合に常にユーザが常にスプレッドの売りを希望する場合もある。一例として、取引可能オブジェクトAが価格45で、取引可能オブジェクトBが価格40であっても良い。現行のスプレッド価格は、145-140=5となり、これは典型的なスプレッド10より少ない。したがって、トレーダはスプレッドの1単位を買ってもよく、結果的に、取引可能オブジェクトAの1単位が価格45で買われ、かつ取引可能オブジェクトBの1単位が価格40で売られる。この通常の価格差が、取引可能オブジェクトAの価格が42、かつ取引可能オブジェクトBの価格が32等となって回復されれば、スプレッドの価格は10になる。よって、スプレッドの1単位を売ってそのポジションを手仕舞えば例えば、取引可能オブジェクトAの1単位を売って、取引可能オブジェクトBの1単位を買う、総取引で利益が得られる。特に、トレーダは取引可能オブジェクトAを価格45で買いかつ42で売って3の損失を出す一方で、取引可能オブジェクトBを価格40で売りかつ32で買って利益8を得ている。このように、トレーダはスプレッドの売買により利益5を得ている。なお上述の例証では、取引可能オブジェクトを市場価格にて、概ね所望の時間に売り買いすることができるという十分な流動性および安定性があるものとする。これにより、トレーダはスプレッド210の所望の価格を得ることができる。しかしながら、より一般的には、ユーザが特定の取引戦略を売り又は買いする際の所望の価格を決定する。自動取引ツールを用いると、例えば、レッグを適切な価格にて売り買いすることで、ユーザは所望の価格を得るように試みても良い。例えば、ユーザが取引戦略210を所望の価格にて売り若しくは買いする注文を入力すると、自動取引ツールは、取引戦略210の取引可能オブジェクト222のうちの1つが取引戦略における所望の価格所望の戦略価格、所望のスプレッド価格、および/又は目標価格ともいうを達成するように、自動的に注文を出すようにしても良く、これは、注文の値付けquotingともいう。注文が出されるレッグは呼び値のレッグともいう。その他のレッグは依存レッグleanleg又はヘッジレッグともいう。呼び値のレッグが値付けされる価格は、注文がヘッジレッグにて約定されうる最良の価格に基づいている。最良の価格は、典型的には、売りの場合は最良の買い呼び値であり、買いの場合は最良の売り呼び値である。ヘッジレッグにおける最良の価格は、非依存価格leanedonprice、依存価格leanpriceまたは依存レベルとしても知られる。非依存価格が変化すると、所望の戦略価格を維持するように、呼び値のレッグにおける注文のための価格も変化しても良い。呼び値のレッグが約定されると、ヘッジレッグにおける注文を提出し、戦略を完了しても良い。この注文は反対注文又はヘッジ注文ともいい、通常は、非依存価格にて値付けされる。非依存価格の注文が約定されないあるいは所望の戦略価格を十分に達成できない場合、トレーダは取引戦略の定義による所望の戦略関係を達成していないため、トレーダはレッグドアップleggedupした、と言われる。取引戦略に応じて、値付けされるレッグの価格が、その他のレッグのうちの全て若しくはそのうちのいくつかに基づいても良い。別の例として、値付けされるレッグにおける注文の注文パラメータは、最終取引価格LTP、最終取引数量LTQ、理論値、場内市場により近い数量等の複数数量、又は他の何らかの基準点等のように、他のレッグにおけるその他のタイプの市況に依存しても良い。取引戦略は、複数例えば、2つ以上、いくつか、又は全てのレッグにおいて値付けされてもよい。このような状況では、値付けされるそれぞれのレッグは、他のレッグが呼び値のレッグであっても、依然として他のレッグに依存している。値付けされたレッグのうちの1つが約定されると、値付けされた他のレッグにおける注文は通常、キャンセルされるとともに、約定されたレッグが基づく非依存価格に基づいて、適切なヘッジ注文が出される。取引戦略の売り買いを行うとき、ユーザは一般的に、取引戦略における目標価格の達成を望む。すなわち、トレーダは結果として特定の戦略価格を実現するために、取引戦略の定義に基づいて取引戦略の取引可能オブジェクトの売り買いを希望する。取引戦略における目標価格を達成するために、市場の流動につれて、ヘッジレッグの流動価格に基づき1つ以上の呼び値のレッグを再値付けする必要がある可能性がある。例えば、第1の取引所にて取引されているヘッジレッグの価格が変動する場合に、第2の取引所にて呼び値のレッグにおける注文をキャンセルするとともに、呼び値のレッグの代わりの定義を有する代替注文により置換しても良い。呼び値のレッグの代わりの定義は通常、ヘッジレッグにおける新たな価格に基づく呼び値のレッグにおける新たな価格を示す。図3Aは、ヘッジレッグの流動価格に基づいて呼び値のレッグにおける注文を取り扱う一例を示す。注文を取り扱うために、図1のシステム100における1つ以上の構成要素を有する場合がある取引システム300が用いられる。取引システム300は、交換システム140aに、交換システム140aの近くに、又は交換システム140a内にサーバ側デバイス120aを備える。しかしながら、サーバ側デバイスは、交換システム140bに、交換システム140bの近くに、又は交換システム140b内には配置されない。代わりに、サーバ側デバイス120aは、交換システム140aおよび交換システム140bの両方において呼び値の注文を取り扱うように構成される。取引システム300は取引戦略デバイス114を備えていない。したがって、顧客デバイス112はサーバ側デバイス120aに対して注文を提出する。システム300は、呼び値の注文を取り扱うために単一のサーバ側デバイス120aが用いられるように構成される。この構成によれば、サーバ側デバイス120aは、全ての呼び値の注文に対する中心として機能することができる。すなわち、サーバ側デバイス120aは、それぞれの交換システムにおける状態および注文の変化に基づいて、それぞれの注文を管理する。取引システム300は、取引戦略に基づく売り又は買いの注文の電子取引を促進するよう構成される。その注文は取引戦略注文310といわれる。この例では、レッグAおよびレッグBの両方が呼び値のレッグとされている。図3Aに示すように、サーバ側デバイス120aは、顧客デバイス112から取引戦略注文310を受信する。取引戦略注文310は、レッグAおよびレッグBを含んだ取引戦略に関連している。レッグAは、交換システム140aにて電子取引される取引可能オブジェクトAに関するものであり、レッグBは、交換システム140bにて電子取引される取引可能オブジェクトBに関するものである。交換システム140aは交換システム140bとは異なっている。取引戦略注文310が受信されると、サーバ側デバイス120aが交換システム140aに対して呼び値の注文312を提出する。呼び値の注文312は、例えば交換システム140bによって要求されるプロトコルに従うよう構成された、レッグAにおける注文であっても良い。同様に、サーバ側デバイス120aは交換システム140bに対して呼び値の注文314を提出する。呼び値の注文314は、例えば交換システム140aによって要求されるプロトコルに従うよう構成された、レッグBにおける注文であっても良い。呼び値の注文312は、交換システム140bにて取引されている取引可能オブジェクトBに依存する。同様に、呼び値の注文314は、交換システム140aにて取引されている取引可能オブジェクトAに依存する。呼び値の注文312、314を受信すると、交換システム140a、140bはサーバ側デバイス120aに注文確認316、318を送信することで、呼び値の注文312、314の受領を知らせる。さらに交換システムは、呼び値の注文を、交換システムによって既に受信された又は将来的に受信される反対側の注文とマッチングさせ始める。市場最新情報320が交換システム140aからサーバ側デバイス120aに対して送信される。市場最新情報320は、取引戦略に関連する価格の変動を含んでいる。例えば、市場最新情報には、レッグBが依存する取引可能オブジェクトAにおける価格が交換システム140aにて変動したことが示される。したがって、取引戦略における目標価格を達成するために、最初に顧客デバイスによって定義されたように、サーバ側デバイス120aは交換システム140bに対して変動注文322を提出する。変動注文322は、注文一覧内のある呼び値のレッグに関連する価格を変動させる。変動後の価格評価は、市場最新情報320に示される価格の変化に基づいている。交換システム140bはサーバ側デバイス120aに変動注文確認324を送信することで、変動注文322の受領を知らせる。なお、交換システム140bが変動注文をサポートしない場合には、例えば、サーバ側デバイス120aが、注文一覧内の注文をキャンセルして置換するための1つのキャンセル/置換注文、又は2つの別々のコマンドを送信するようにしても良い。変動注文確認324を受信する前に、サーバ側デバイス120aは、例えば取引戦略の価格化に影響する別の価格変動を示す別の市場最新情報326を受信する。しかしながら、いくつかの例では、変動注文確認324が受信されるまで例えば、時間間隔328の間、サーバ側デバイス120aは変動注文330を送信することができない。すなわち、サーバ側デバイス120aが変動注文322に関連する注文のための識別子を受信していないので、変動注文330は送信されるべきではないということである。注文を変化させる、置換する、又はキャンセルするときに、サーバ側デバイス120aが正しい注文を参照できるように、交換システム140bは前記識別子を変動注文確認324に付けている。この識別子がないと、サーバ側デバイス120aは正しく注文を参照することができない。したがって、交換システム140bは、正しい注文を識別するとともに適切なアクションをとることができなくなる。さらにその他の例では、サーバ側デバイス120aは、取引所において注文が正しく受信されて注文一覧に置かれることを確保するために、変動注文確認324を待たなければならない。加えて、変動がすでに約定しているという可能性もある。これにより、変動注文確認が受信される前に変動注文330が送信された場合、トレーダは二重約定の可能性がある。時間間隔328の間、サーバ側デバイス120aは、市場が変化したものの変動注文を出すことはできないということを認知している。交換システム140bができるだけ早く変動注文330を受信できるように、この時間間隔をできるだけ短くすることで有利になる場合もある。さらに図3Bに示すように、システム300においては、トレーダが長期間、レッグドlegged、二重約定、又はレッグドと二重約定の両方を被る可能性がある。システム300は、図3Aのシステム300と同一又は類似するものである。しかしながら、市場最新情報326の代わりに、変動注文確認324を受信する前に、サーバ側デバイス120aは約定確認332を受信する。約定確認332には、交換システム140aが呼び値の注文312のマッチングを行ったことが示される。約定確認332の受信に反応して、サーバ側デバイス120aは交換システム140bに対して、ヘッジ注文336およびキャンセル注文338の送信を試みる。ヘッジ注文336は、呼び値のレッグAが依存していたレッグに関連する取引可能オブジェクトへの注文を出す。キャンセル注文340は、呼び値のレッグBにおける取引可能オブジェクトへの置換注文例えば、変動注文322の結果として出された注文をキャンセルする。ヘッジ注文336は、例えば約定の後などいつでも出すことができる。例えば図3Bに示すように、約定確認332の受信後かつ変動注文確認324の前に、ヘッジ注文336を出すこともできる。しかしながら、他の実施形態では、変動注文338が受信されてキャンセル注文338が送信されるまで、ヘッジ注文336が出されない場合もある。しかしながら、サーバ側デバイス120aは、変動注文確認324を受信するまでキャンセル注文338を出すことができない。これは、サーバ側デバイス120aが変動注文322をキャンセル可能となるために、変動注文確認324内に確認の情報を必要とするためである。すなわち、サーバ側デバイス120aは、上述したように識別子がなければ取引所130bにおいて変動注文322を識別することができないため、時間間隔334の間はキャンセル注文338を出すことができない。これにより、ヘッジ注文330、キャンセル注文340、又はその両方を出す際に遅延が生じるおそれがある。図3Bに示すように、ヘッジ注文336が遅延していなくとも、キャンセル注文338に遅延が生じて、結果的にユーザが二重約定又はレッグドを被る可能性がある。このようなレッグドを被るリスクは、取引戦略を達成するのに必要な価格が利用できなくなったときに生じる。例えば、トレーダはレッグAにて約定された後にレッグドを被ると考えられ、取引戦略価格を満足する価格におけるレッグBでの約定が不可能となる。例えば、取引戦略価格が5でレッグAが価格10にて約定されたと仮定する。取引戦略価格はレッグAの価格からレッグBの価格を引いたものに等しいため、トレーダはレッグBにおいて価格5を得る必要があると推定される。しかしながら、レッグAが約定された後又はレッグAが約定されている間に、市場がトレーダに反して移動する場合には例えば、レッグBの価格が5から4に落ちる、取引戦略価格5が利用できなくなるため、トレーダはレッグドを被ってしまったと考えられる。さらに、交換システム140bにおいて変動注文322およびヘッジ注文336の両方が取引されているときには、トレーダは二重約定を被るリスクがある。すなわち、取引戦略価格を得るために、約定確認326が受信されるときに交換システム140bに対してヘッジ注文336が送信される。しかしながら、サーバ側デバイス120aは既に変動注文確認324を受信しているため、変動注文322はキャンセルされていない。したがって、交換システム140bにおいて2つの注文が取り扱われている。これにより、トレーダには二重約定を被るリスクが残される。例示的な電子取引プロセスについて図4Aは、図1の取引システム100を用いた例示的な取引プロセスを示す。顧客デバイス112は、取引戦略定義を受信するように構成される。取引戦略定義は、買う又は売られるべき取引戦略を定義する。取引戦略定義には例えば、あらゆる価格データ、数量データおよびコンフィギュレーションデータ、又はこれらのあらゆる組み合わせが含まれても良い。取引戦略定義は顧客デバイス112から受信されても良い。例えば、取引戦略定義は、自動又はトレーダによる手動で顧客デバイス内に入力されても良い。別の例では、取引戦略定義のうちの全て又はそのいくつかが同じ又は異なる時間に受信されても良い。例えば、トレーダは取引戦略を定義する例えば、スプレッドを定義するとともに、取引戦略デバイス114又はサーバ側デバイスに対してコンフィギュレーションデータを送信するようにしても良い。その後、取引セッションの間に、例えば価格軸に沿って価格および数量を選択することで、価格および数量の情報を定義しても良い。顧客デバイス112は、例えば取引戦略定義に基づいて、取引戦略注文410を生成するようにしても良い。注文が生成されると、顧客デバイス112は取引戦略デバイス114に取引戦略注文410を送信しても良い。取引戦略注文410はユーザからのリクエスト例えば送信ボタンのクリックにより、又は自動的に送信されても良い。例えば、トレーダは取引戦略注文を出すために、電子取引ワークステーションを利用しても良い。別の例では、自動取引ツールが注文のための1つ以上のパラメータを計算するとともに、その注文を自動的に送信する場合もある。いくつかの例では、自動取引ツールは送信される注文を準備するが、ユーザからの確認がないと実際にはその注文を送信しない場合もある。いくつかの実施形態では、顧客デバイス112は、例えば取引戦略デバイス114に割り当てられたアドレスや通信経路を用いて、取引戦略注文410の受信体として取引戦略デバイス114を指定する場合もある。しかしながら、他の実施形態では、取引戦略注文410が、取引戦略注文410を取引戦略デバイス114に送る別のデバイスに送信される場合もある。取引戦略注文410を、複数の呼び値のレッグを有する取引戦略に関連付けても良い。例えば、取引戦略注文410を、レッグAおよびレッグBを有するスプレッドに関連付けても良い。レッグAは交換システム140aにて取引される取引可能オブジェクトAに関連し、レッグBは交換システム140bにて取引される取引可能オブジェクトBに関連する。例えば、取引戦略が顧客デバイス112を用いて定義されるときに、レッグAおよびレッグBの両方が呼び値のレッグとして示される。したがって、レッグAは取引可能オブジェクトBに依存し、レッグBは取引可能オブジェクトAに依存する。付加的な呼び値のレッグおよび/又は呼び値でないレッグを、取引戦略注文410に関連する取引戦略にて定義しても良い。交換システム140aは交換システム140bと異なっても良い。取引戦略デバイス114は取引戦略注文410を受信しても良い。取引戦略注文410を受信する工程には、取引戦略注文410を受信、要請、読み出し又はその他の獲得を行う工程が含まれても良い。図4Aに示すように、各種実施形態においては、取引戦略デバイス114を顧客デバイス112と、サーバ側デバイス120のうちの1つ、いくつか又はその全てとの間に配置しても良い。したがって、取引戦略デバイス114はサーバ側デバイス120のうちの1つ、いくつか又はその全てよりも前に又は同時に、取引戦略注文410を受信しても良い。例えば、取引戦略デバイス114が顧客システム110内に配置される場合に、取引戦略デバイス114がサーバ側デバイス120aおよびサーバ側デバイス120bよりも前に取引戦略注文を受信しても良い。しかしながら、取引戦略デバイス114がサーバ側デバイス120aの一部である場合には、取引戦略デバイス114がサーバ側デバイス120bよりも前に、取引戦略注文410を受信しても良い。一旦受信されると、取引戦略デバイス114は、取引戦略注文410を複数の子取引戦略注文414,416に分割412しても良い。したがって、取引戦略注文410は例えば、最初の注文、オリジナル注文、受信注文、又は親注文と呼ばれる。子注文414、416は例えば、下位注文、分割注文、又はデリバティブ注文と呼ばれる。以下で詳細に説明するように、取引戦略注文410の分割412には、複数の呼び値のレッグにしたがって取引戦略を分類、複数の子取引戦略の定義、複数の子取引戦略注文の生成、複数の子取引戦略注文の提出、あるいはこれらのあらゆる組み合わせが含まれても良い。なお、分割412は上述の行為に限らない。取引戦略注文を分割する際に、付加的な、異なる、又は少数の行為を実行しても良い。取引戦略デバイス114は、複数の呼び値のレッグを有する取引戦略を識別するように構成される。複数の呼び値のレッグを有する取引戦略に関連する取引戦略注文410は、取引戦略に、呼び値のレッグとして表示された複数のレッグが含まれることを認識、計算あるいは決定することを含んでも良い。例えば、取引戦略デバイス114が取引戦略注文410内のそれぞれのレッグを分析し、それぞれのレッグが呼び値のレッグか呼び値以外のレッグかを決定し、呼び値のレッグとされたレッグの数を数えるようにしても良い。別の例では、顧客デバイス112は、例えば取引戦略注文を生成するときに、取引戦略注文410における呼び値のレッグの数を示すために指定されたフィールドにおける呼び値のレッグの数を示す。したがって、取引戦略デバイス114がそのフィールドを読み込んで、分析しても良い。複数の呼び値のレッグを有する取引戦略に関連する取引戦略注文410の識別に反応して、取引戦略デバイス114は複数の子取引戦略を定義しても良い。値付けされているレッグの数を除き、子取引戦略は取引戦略注文410に関連する取引戦略と同じである。すなわち、子取引戦略において呼び値のレッグとされたレッグの数は、取引戦略注文410に関連する取引戦略において呼び値のレッグとされたレッグの数と異なる例えば、小さい。例えば、子取引戦略には、単一の呼び値のレッグ、又は例えば、取引戦略注文410における呼び値のレッグの数に比較して減少された数の呼び値のレッグが含まれても良い。子取引戦略は取引可能オブジェクトに関連付けられる。例えば、図4Aに示すように、第1の子取引戦略は取引可能オブジェクトAに関連付けられ、第2の子取引戦略は取引可能オブジェクトBに関連付けられる。第1の子取引戦略において、レッグAは呼び値のレッグとされる。同様に、第2の子取引戦略において、レッグBは呼び値のレッグとされる。定義された子取引戦略の数は例えば、取引戦略注文410における呼び値のレッグの数に依存する。それぞれの子取引戦略が単一の呼び値のレッグを有しても良い。別の例では、複数の呼び値のレッグが単一の子取引戦略内に含まれても良い。呼び値のレッグは、呼び値のレッグのマッチングを行うよう構成された交換システムに基づきグループ化されても良い。例えば、同じ交換システムにて取引された呼び値のレッグが、同じ子取引戦略に含まれても良い。しかしながら、ともにグループ化された場合であっても、子注文における呼び値のレッグの数は取引戦略注文410における呼び値のレッグの数よりも少ない。なお、現在のシステムは、取引戦略注文を分割することなく取引戦略注文の取り扱いをサポートする。例えば、取引戦略デバイス114は複数の呼び値のレッグを有する取引戦略のための取引戦略注文410を受信し、その取引戦略注文410をサーバ側デバイス120aに送信しても良い。すなわち、取引戦略デバイス114は、取引戦略注文410を分割するかどうかを、例えば、待ち時間latency、1つ以上の交換システムの物理的位置、取引環境を最適化する1つ以上の他の留意事項、あるいはこれらの組み合わせに基づき決定しても良い。それぞれの子取引戦略は呼び値のレッグを有さないか、1つあるいはそれより多くの呼び値のレッグを有する。子取引戦略における呼び値のレッグの数は、最初の注文の取引戦略における呼び値のレッグの数よりも少ない。一例として、取引戦略注文410に定められるように取引戦略が2つの呼び値のレッグを有する場合、取引戦略デバイス114は、単一の呼び値のレッグを有する第1の取引戦略および単一の呼び値のレッグを有する第2の取引戦略を定義しても良い。別の例では、取引戦略注文410に定められるように取引戦略が22の呼び値のレッグを有する場合、取引戦略デバイス114は、単一の呼び値のレッグを有する第1の取引戦略、単一の呼び値のレッグを有する第2の取引戦略、および20の呼び値のレッグを有する第3の取引戦略を定義しても良い。子取引戦略のうちの1つ、いくつか又はその全てが定義されると、取引戦略デバイス114は複数の子取引戦略注文子注文414、416を生成する。それぞれの子注文414、416は、単一の又は例えば、顧客デバイス112から受信された取引戦略注文における呼び値のレッグの数に比較して減少された数の呼び値のレッグを有する子取引戦略を備えても良い。例えば、取引戦略注文410における取引戦略の複雑さに基づき、あらゆる数例えば、2あるいは3以上の子注文を生成しても良い。例えば、取引戦略デバイス114は、取引戦略注文410に関連付けられる取引戦略におけるそれぞれの値付けされたレッグのための子注文を生成しても良い。別の例では、例えば、子取引戦略をグループ化することで、取引戦略デバイス114が生成されるべき子注文の数を最小化する場合もある。レッグ若しくは取引戦略は、例えば、待ち時間、サーバ側デバイス、交換システム若しくはゲートウェイの物理的位置、トレーダの好み、交換能力、その他の既知の若しくは最近開発された基準、又はこれらのあらゆる組み合わせに基づきグループ化されても良い。これにより、電子取引システム100を通じて伝達される子注文のボリュームを低減することができる。子注文におけるレッグのうちの全て、いくつか又は1つが呼び値のレッグであっても良く、全てが呼び値のレッッグでなくても良い。子注文は、あらゆる数の呼び値でないレッグおよび/又はあらゆる数の呼び値のレッグを有して良い。子注文の数は例えば、取引戦略におけるレッグの数、呼び値のレッグの数、待ち時間、交換能力、又はこれらのあらゆる組み合わせに依存しても良い。子注文における呼び値でないレッグおよび呼び値のレッグの数は、それぞれ同じであっても異なっていても良い。呼び値でないレッグおよび呼び値のレッグの数は、子注文間において変化しても良く、変化しなくても良い。例えば、子注文において、呼び値のレッグが他の呼び値のレッグ又は呼び値でないレッグと混合されていても良い。しかしながら、単一の呼び値でないレッグおよび呼び値のレッグが、代替的に又は付加的に、独立であっても良い。取引戦略デバイス114は、子注文の数、それぞれの子注文における呼び値でないレッグの数若しくは呼び値のレッグの数、又はこれらの組み合わせを、例えば子注文を提出する際の待ち時間に基づいて決定する。取引戦略デバイス114は子注文を提出する際にかかる時間を最小化しても良い。図5-7は、複数の呼び値のレッグを有する1つの注文を分割する例を示す。図5-7に示す例は、いずれも非網羅的である。以下で詳細に説明するように、図5は、2つのレッグを有する取引戦略に関連する取引戦略を、それぞれ単一の呼び値のレッグを有する2つの子注文に分割することを示す。図6は、4つのレッグを有する取引戦略に関連する取引戦略を、それぞれ単一の呼び値のレッグを有する2つの子注文に分割することを示す。図7は、5つのレッグを有する取引戦略に関連する取引戦略を、複数の呼び値のレッグを有する1つの子注文と単一の呼び値のレッグを有する1つの子注文との2つの子注文に分割することを示す。本願明細書等の範囲には、例えば異なる取引戦略のための他の例も含まれるものとする。図5は、2つの呼び値のレッグ520a、520bを有する取引戦略510のための取引戦略注文500を示す。すなわち、注文500は複数の呼び値のレッグ520a、520bを有する。取引戦略デバイス114は、例えば顧客デバイスから注文500を受信しても良い。取引戦略デバイス114は、注文500を分析するとともに、注文500に複数の又は1つよりも多くの呼び値のレッグが含まれることを識別しても良い。識別には、呼び値のレッグとされるレッグの数の計算が含まれても良い。図5において、取引戦略デバイス114は、注文500が2つの呼び値のレッグを有するということを決定しても良い。複数の呼び値のレッグの識別に応じて、取引戦略デバイス114は、第1の子注文530および第2の子注文540を生成しても良い。この例では、第1の子注文530はレッグ520aおよびレッグ520bの両方を含むが、レッグ520aのみが呼び値のレッグとされる。レッグ520bは呼び値でないレッグである。すなわち、第1の子注文530を生成する際に、取引戦略デバイス114は、第2のレッグ520bを呼び値のレッグから呼び値でないレッグに変えても良い。同様に、第2の子注文540はレッグ520aおよびレッグ520bの両方を含むが、レッグ520bのみが呼び値のレッグである。レッグ520aは呼び値でないレッグである。すなわち、第2の子注文540を生成する際に、取引戦略デバイス114は、第1のレッグ520aを呼び値のレッグから呼び値でないレッグに変えても良い。第1の子注文530はサーバ側デバイス120aに提出しても良い。第2の子注文540は第2のサーバ側デバイス120bに提出しても良い。サーバ側デバイス120は、子注文におけるそれぞれの呼び値のレッグのための呼び値の注文を、呼び値のレッグのための注文がマッチングおよび約定される交換システムに送信しても良い。この例では、第1の交換システムが第1のレッグ520aのための注文を約定し、第2の交換システムが第2のレッグ520bのための注文を約定する。図示されるように、第1の子注文530および第2の子注文430は、互いに関連する注文―キャンセル―注文OCO型の注文とされても良く、そこでは、子注文における呼び値のレッグを完全に約定すると、次に他の子注文をキャンセルする。OCO行為は、呼び値のレッグが約定された子注文における約定又はレッグドされた量に基づいて、他の子の量を低減しても良い。これによりトレーダは、呼び値のレッグの両方が1つの場所から管理されるときでも生じる可能性のある飛行中の状態に起因する二重約定を、飛行中inflightの状態を除き被らないということが確保される。図6は、2つの呼び値のレッグ620a、レッグ620cおよび2つの呼び値でないレッグ620b、620dを有する取引戦略610のための取引戦略注文600を示す。取引戦略デバイス114は、例えば顧客デバイスから注文600を受信しても良い。取引戦略デバイス114は、注文600を分析するとともに、注文600に複数の又は1つよりも多くの呼び値のレッグが含まれることを識別しても良い。識別には、呼び値のレッグとされるレッグの数の計算が含まれても良い。取引戦略デバイス114は、注文600が2つの呼び値のレッグ620a、620cを有するということを決定しても良い。複数の呼び値のレッグの識別に応じて、取引戦略デバイス114は、第1の子注文630および第2の子注文640を生成しても良い。この例では、第1の子注文630はレッグ620a-620dを含むが、レッグ620aのみが呼び値のレッグとされる。レッグ620b―dは第1の子注文630における呼び値でないレッグである。第2の子注文640はレッグ620a―620dを含むが、レッグ620cのみが呼び値のレッグとされる。レッグ620a、620b、620dは呼び値でないレッグとされる。呼び値のレッグ620aのための注文は第1の交換システム140aにて約定されるため、第1の子注文330は第1のサーバ側デバイス120aに提出しても良い。呼び値のレッグ620cのための注文は第2の交換システム140bにて約定されるため、第2の子注文340は第2のサーバ側デバイス120bに提出しても良い。図示されるように、第1の子注文630および第2の子注文630は、注文―キャンセル―注文OCO型の注文とされても良く、そこでは、呼び値のレッグを約定すると、次に他の注文をキャンセルする。図7は、3つの呼び値のレッグ720a、720c、720eおよび2つの呼び値でないレッグ720b、720dを有する取引戦略710のための取引戦略注文700を示す。この例では、呼び値のレッグ720a、720eは、同じ交換システムにてマッチングおよび約定される。したがって、取引戦略デバイス114は、同じ子注文において呼び値のレッグ720a、720eを有する。図7に示すように、取引戦略デバイス114は、例えば顧客デバイスから注文700を受信しても良い。取引戦略デバイス114は、注文700を分析するとともに、注文700に複数の又は1つよりも多くの呼び値のレッグが含まれることを識別しても良い。識別には、呼び値のレッグとされるレッグの数の計算が含まれても良い。取引戦略デバイス114は、注文700が2つの呼び値のレッグ720a、720cを有するということを決定しても良い。複数の呼び値のレッグの識別に応じて、取引戦略デバイス114は、第1の子注文730および第2の子注文540を生成しても良い。この例では、第1の子注文730はレッグ720a-720dを含むが、レッグ720a、720eが同じ交換システムにて約定されるため、レッグ720a、720eのみが呼び値のレッグとされる。レッグ720b―720dは第1の子注文730における呼び値でないレッグとされる。第2の子注文540はレッグ720a―720dを含むが、レッグ720cのみが呼び値のレッグとされる。レッグ720a、720b、720d、720eは呼び値でないレッグとされる。呼び値のレッグ720a、720eは第1の交換システム140aにて約定されるため、第1の子注文730は第1のサーバ側デバイス120aに送信されても良い。呼び値のレッグ420cは第2の交換システム140bにて約定されるため、第2の子注文340は第2のサーバ側デバイス120bに提出しても良い。図示されるように、第1の子注文730および第2の子注文730は、注文―キャンセル―注文OCO型の注文とされても良く、そこでは、呼び値のレッグを約定すると、次に他の注文をキャンセルする。図7の例の別のものとして、取引戦略デバイス114は、2つの子注文とは反対に、3つの異なる子注文を生成しても良い。それぞれの子注文は、取引可能オブジェクトに関連付けられる可能性のある単一の呼び値のレッグを有しても良い。例えば、第1、第2および第3の子注文はそれぞれ、第1、第2および第3の取引可能オブジェクトに関連付けられても良い。第1および第2の取引可能オブジェクトは第1の交換システムにて取引され、第3の取引可能オブジェクトは第2の交換システムにて取引されても良い。したがって、異なる注文である第1および第2の子注文は第1の交換システムに送信され、第3の子注文は第2の交換システムに送信されても良い。子注文は、複数の交換システムにおいて値付けされる複数の呼び値のレッグを有しても良い。以下で説明するように、子注文を提出するために一連の取引戦略デバイス114を用いても良い。例えば、第1の取引戦略デバイス例えば、シカゴに配置されるは、1つの取引戦略注文例えば、ミルウォーキーに配置された顧客デバイスにより生成されるを第1および第2の子注文に分割しても良い。第1の子注文は、例えば、ヨーロッパに配置された第1の交換システムにおいて取引される第1の取引可能オブジェクトに関連付けられる第1の呼び値のレッグと、例えば、日本に配置された第2の交換システムにおいて取引される第2の取引可能オブジェクトに関連付けられる第2の呼び値のレッグとを有しても良い。第2の子注文は、例えば、シカゴに配置された第3の交換システムにおいて取引される第3の取引可能オブジェクトに関連付けられる第3の呼び値のレッグを有しても良い。第1の取引戦略デバイスは、第1の子注文を例えば、ヨーロッパに配置された第2の取引戦略デバイスに送り、第2の子注文を第3の交換システムに関連付けられるサーバ側デバイスに提出用として送信するようにしても良い。第2の取引戦略デバイスは、第1の子注文を第4および第5の子注文に分割しても良い。第4および第5の子注文は、それぞれの交換システムに関連付けられるサーバ側デバイスに送信しても良い。サーバ側デバイス120が複数の取引所と取引するとともに、子注文における2つ以上の呼び値のレッグが異なる取引所で取引される呼び値の注文を有するようにしても良い。例えば、1つの子注文が、第1の取引所で取引される第1の呼び値のレッグと第2の取引所で取引される第2の呼び値のレッグとに関連付けられても良い。サーバ側デバイス120は、それぞれの注文が異なる取引所で取引されていても、第1および第2の呼び値のレッグのための注文の両方を取り扱っても良い。図4Aに戻ると、ともに呼び値のレッグであるレッグAおよびレッグBを取引戦略注文410が有するとの決定に応じて、取引戦略デバイス114は、レッグAを含む第1の子取引戦略とレッグBを含む第2の子取引戦略とを定義しても良い。次に、取引戦略デバイス114は、第1の子取引戦略のための子注文414と第2の子取引戦略のための子注文416とを生成しても良い。したがって、子注文414は呼び値のレッグとされるレッグAを有し、子注文416は呼び値のレッグとされるレッグBを有する。取引戦略デバイス114は複数の子注文414、416の送り先を知的に決定しても良い。例えば、子注文をサーバ側デバイス120に送信しても良く、そのサーバ側デバイス120は、子注文における呼び値のレッグを約定するよう構成されたそれぞれの交換システム140にて子注文を取引するよう構成されている。子注文を取引するよう構成されたサーバ側デバイス120が複数存在する場合には、取引戦略デバイス114は、交換システム140に最も近いサーバ側デバイス120に子注文を送信しても良い。例えば、図示のように、子注文414を交換システム140aに最も近いサーバ側デバイス120aに送信し、子注文416を交換システム140bに最も近いサーバ側デバイス120bに送信しても良い。さらに、取引戦略デバイス114は、子注文を送信するための通信経路を待ち時間に基づいて選択しても良い。待ち時間には、サーバ側デバイス120や交換システム140などの受信デバイスが取引戦略デバイス114から子注文を受信するために必要とされる時間が含まれても良い。取引戦略デバイス114は、例えば、取引戦略デバイス114と交換システムとの間における遅延が最も小さい若しくは低減された通信経路を経由して子注文を送信することにより、待ち時間を低減又は最小化することができる。通信経路は、取引戦略デバイス114と交換システムとを接続しても良い。一例では、通信経路に、取引戦略デバイス114に遅延を報告する通信ノード、ルータ、サーバなどの通信デバイスが含まれても良い。取引戦略デバイス114は、最適な例えば、待ち時間が最も小さくなるように通信経路を決定するためにその情報を分析しても良い。図4Aは単一の取引戦略デバイス114を有する取引戦略注文410の分割について示しているが、取引戦略注文410の分割のために一連の例えば、2つ、3つ又はそれよりも多くの取引戦略デバイスを用いても良い。一連の取引戦略デバイスは、取引システム100における様々な層又は場所で取引戦略注文を分割しても良い。複数層、複数場所又は複数層および複数場所の両方における分割は、1つ以上の取引戦略デバイス112によって実施されても良い。例えば、取引戦略デバイス114などの第1の取引戦略デバイスは、取引戦略注文410を第1および第2の子注文に分割しても良い。複数の呼び値のレッグを有する第1の子注文を再度分割するために、第2の異なる取引戦略デバイスに送信しても良い。子注文が受信されると、サーバ側デバイス120は、呼び値のレッグのマッチングを行うよう構成された交換システムに、1つ以上の呼び値のレッグのための注文呼び値の注文を提出しても良い。呼び値の注文における1つ以上の呼び値のレッグは、子注文において定義された呼び値のレッグであっても良い。例えば、図4に示すように、第1の子注文414の受信に応じて、サーバ側デバイス120aは交換システム140aに呼び値の注文418を提出しても良い。呼び値の注文418は第1の呼び値のレッグQ1を有しても良い。第2の子注文416の受信に応じて、サーバ側デバイス120bは交換システム140bに呼び値の注文420を提出しても良い。呼び値の注文420は、第2の呼び値のレッグQ2を有しても良い。交換システム130a、130bは、注文確認422および注文確認424を送信することにより、呼び値の注文418および呼び値の注文420の受領をそれぞれ知らせても良い。注文確認422、424は、サーバ側デバイス120a、120bによる呼び値の注文418、420の取り扱いを可能とする確認情報をそれぞれ含んでも良い。例えば、確認情報には、サーバ側デバイス120aがキャンセル注文やヘッジ注文などの次の注文をする際に呼び値の注文312、314を識別することが可能となる識別情報が含まれても良い。確認情報がないと、サーバ側デバイス120a、120bは、呼び値の注文418、420についてのキャンセル、置換、又はその両方を行うことができない場合がある。サーバ側デバイス120a、120bは、呼び値の注文418、420をそれぞれ取り扱うよう構成されても良い。上述したように、注文の取り扱いには、注文の再値付け、注文のキャンセル、ヘッジ注文の送信、未処理注文の管理、あるいはこれらのあらゆる組み合わせが含まれても良い。例えば、図4Aに示すように、サーバ側デバイス120bは交換システム140aから市場最新情報426を受信しても良い。市場最新情報426は、呼び値の注文420が依存しているレッグの価格変化を示しても良い。したがって、取引戦略注文410で定義されるように、取引戦略のための目標価格を達成するために、サーバ側デバイス120bは変動注文を提出しても良い。変動注文428は、呼び値の注文420が修正された価格価値を有するようにして呼び値の注文420を変動させる。修正された価格価値は市場最新情報に示される価格変化に基づくとともに、市場が流動するときでも取引戦略のための目標価格が達成されることを確保する。交換システム140bは、サーバ側デバイス120bに変動注文確認430を送信することにより、変動注文428の受領を知らせるようにしても良い。しかしながら、サーバ側デバイス120bが変動注文確認430を受信する前に、サーバ側デバイス120bは交換システム140aから別の市場最新情報432を受信する。市場最新情報432は市場最新情報426とは異なる。例えば、市場最新情報432は取引可能オブジェクトAのためのさらに別の価格変動を示す。サーバ側デバイス120bが変動注文428のための変動注文確認430を受信するまで、呼び値の注文420のための価格価値を修正する変動注文434を送信することができない。しかしながら、サーバ側デバイス120bは交換システム140bに、その中に又はその近傍に配置されているため、例えば、図3Aに示すように変動注文確認430をサーバ側デバイス120aまで遡って送信する必要がないので、サーバ側デバイス120が待機する必要のある時間間隔438は低減される。図4Bは、取引戦略注文410を取り扱うために用いられる取引システム100を示す。しかしながら、市場最新情報432をサーバ側デバイス120bに送信しない代わりに、取引戦略注文410を行う工程は図4Aの場合と同様であり、交換システム140aは呼び値の注文418をマッチングするとともに約定確認440を送信する。しかしながら、別の例では、呼び値の注文418は市場最新情報426よりも前又はそれと同時にマッチングされても良い。呼び値の注文418の約定に応じて、図4の例に示すように交換システム140aはサーバ側デバイス120aに約定確認440を送信し、呼び値の注文418がマッチングされたことを知らせる。その代わりに又は付加的に、約定確認432を、顧客デバイス112、取引戦略デバイス114、サーバ側デバイス120b、あるいはこれらの組み合わせに送信しても良い。約定確認432の受信に応じて、サーバ側デバイス120aはサーバ側デバイス120bにヘッジ注文444およびキャンセル注文444を送信する。ヘッジ注文442は、レッグAが依存していたレッグのための取引注文を行う。ヘッジ注文442はキャンセル注文444の前に又はその後に提出されても良い。キャンセル注文444はレッグBのための呼び値の注文420をキャンセルする。図4Bには別のメッセージとして示されるが、ヘッジ注文442およびキャンセル注文444は単一の注文メッセージであっても良い。いくつかの実施形態では、例えばサーバ側デバイス120a、120bが互いに通信しないときに、ヘッジ注文442およびキャンセル注文444を、例えばサーバ側デバイス120bへのルーティングのために取引戦略デバイス114に送信しても良い。その代わりに又は付加的に、例えばサーバ側デバイス120a、120bが互いに通信するときに、サーバ側デバイス120aは、サーバ側デバイス120bにヘッジ注文442およびキャンセル注文444を送信しても良い。ヘッジ注文442がサーバ側デバイス120bに受信されると、サーバ側デバイス120bは交換システム140bにヘッジ注文446を送信する。ヘッジ注文は、例えば、変動注文確認430が受信される前、キャンセル注文444の前後、サーバ側デバイス120bが変動注文確認430を受信した後、あるいはそれ以外のときなど、いかなるときに行っても良い。変動注文確認430を受信する前に、サーバ側デバイス120bはキャンセル注文444を受信する。しかしながら、キャンセル注文444が受信されるときに、サーバ側デバイス120bは確認情報を有した変動注文確認430を受信していないため、どの注文をキャンセルすべきか認識しておらず、変動注文428をキャンセルすることができない。したがって、サーバ側デバイス120bは、変動注文確認430を受信するまでキャンセル操作を実施することができない。結果的にトレーダは、キャンセル注文444の受信と変動注文430の受信との間の時間を含んだ時間間隔450の間、リスクにさらされる。しかしながら、以下で説明するように、この時間間隔は、キャンセル注文448を送信する前に変動注文確認430をサーバ側デバイス120aまで遡って送信する必要がある場合よりもかなり短い。変動注文確認430が受信されると、サーバ側デバイス120bはキャンセル注文448を提出する。キャンセル注文448は変動注文428をキャンセルする。確認情報は必要ないので、時間間隔450の間にヘッジ注文446を提出しても良い。図4Bに示すように、取引戦略注文を分割するとともに、交換システム130のうちの全て、いくつか若しくは1つに、又はその近く、若しくはその中にあるサーバ側デバイス120に子注文を送信することで、トレーダがレッグドlegged、二重約定、又はレッグドと二重約定の両方を被る可能性がある時間を減らすことができる。すなわち、サーバ側デバイス120bは、交換システム140bから変動あるいは変動がサポートされていない場合にはキャンセル/置換注文確認を受信するとすぐにキャンセル注文434を提出することができる。サーバ側デバイス120bおよび交換システム140bは、サーバ側デバイス120aおよび交換システム140bよりも互いに近くに位置しているため、確認430のための待ち時間すなわち時間間隔450は、確認324のための待ち時間すなわち時間間隔334よりも短い。加えて、変動注文確認430が移動する距離は、変動注文確認324が移動する距離よりも短い。さらに、キャンセル注文448が移動する距離は、キャンセル注文338が移動する距離よりも短い。時間に関しては、短い距離ほど移動時間は短くなり、その方がユーザにとっても非常に有益である。子注文が交換システムに提出される前後において、サーバ側デバイス120は、例えば、注文をキャンセル、注文を変動、交換の問い合わせ、又はこれらのあらゆる組み合わせを行っても良い。注文のキャンセルには、交換システムへの提出が予定されていた又は予定されている注文のうちの全てあるいはそのいくつかをキャンセルすることが含まれても良い。例えば、交換システム140が呼び値の注文の一部を約定することしかできない場合には、交換システム140は、注文の全体が約定されるまで待つ代わりに、約定可能な部分のみ取引を行うとともにサーバ側デバイス120に部分的な約定注文を送信する。これに応じて、サーバ側デバイス120は部分的なキャンセル注文および部分的なヘッジ注文を送信しても良い。これにより、取引戦略の全体が完全に約定されるまで、継続的又は断続的な約定を行うことができる。さらに、注文の変動には、例えば、注文パラメータの変動、注文フォーマットの変動例えば、金融情報交換FIXプロトコルなどのプロトコルの変動、注文の提出時間の変動、提出用通信経路の変動、又はこれらのあらゆる組み合わせが含まれても良い。交換の問い合わせには、市場データやその他のデータといった情報の要求が含まれても良い。子取引戦略は、呼び値のレッグとされるレッグの数を除くと親取引戦略と同一である。すなわち、第1の子注文414および第2の子注文416の約定は、取引戦略注文410の約定と同一である。例えば、子注文のうちの1つの約定によって、顧客デバイス112からの取引戦略注文410の約定と同一又は略同一の結果をもたらしても良い。ここでの略との用語には、例えば、1つ以上の注文の約定にかかる時間を変化例えば、増加又は減少させることで生じる価格変動など、電子取引システム100における小さな変更が考慮されている。価格は急速に流動する。したがって、子注文は顧客デバイス112からの注文よりも少ない時間にて提出されても良いので、顧客デバイス112からの注文の約定における価格は、子注文の約定における価格と異なっても良い。しかしながら、価格は変動する可能性があるものの、顧客デバイス112からの注文の約定あるいは子注文230、240のうちのうちの1つ、いくつかあるいはその全ての組み合わせの約定によって、同一の取引戦略が実行される。なお、交換システムに近いサーバ側デバイスを有することで、呼び値のレッグでの約定の可能性が増加する。さらに、単一のサーバ側方式の場合に比べて、ヘッジ注文の方が早く交換システムに到着する可能性が高い。加えて、第2の呼び値の注文が早く取り除かれる飛行中の時間が最小限に低減されるため、二重約定の可能性を少なくすることができる。図4Bに示す例では、交換システム140bよりも前に第1の子注文414を約定させた交換システム140aは、第2の子注文416を約定させることができた。しかしながら、その他の例では、交換システム140bは、第1の子注文230が約定される前に第2の子注文416を約定させても良い。したがって、Q1注文418をキャンセル又は置換するように、その工程が予約されても良い。例示的な取引戦略デバイス図8は、取引戦略デバイス114の一例を示す。取引戦略デバイス114は、1つ以上の電子コンピューティングプラットフォームを備える。例えば、図8に示すように、取引戦略デバイス114は、プロセッサ810とメモリ820とを有する電子コンピューティングプラットフォームを備えても良い。プロセッサ810は、メモリ820と通信可能に接続してメモリ820に保存された命令を実行しても良い。取引戦略デバイス114は、付加的な、異なる又は少ない数のコンポーネントを備えても良い。プロセッサ810は、汎用プロセッサ、デジタルシグナルプロセッサ、特定用途向けIC、フィールドプログラマブルゲートアレイ、アナログ回路、デジタル回路、これらの組み合わせ、又はその他の既に知られている若しくは最近開発されたプロセッサであっても良い。プロセッサ810は、ネットワークや分散プロセッシングなどに関連付けられる単一のデバイスあるいは組み合わせのデバイスであっても良い。マルチプロセッシング、マルチタスキング、パラレルプロセッシングなど、あらゆる各種処理戦略を用いても良い。プロセッシングは、リモートに反してローカルであっても良い。しかしながら、プロセッシングをリモートで行っても良い。プロセッシングは1つのプロセッサから別のプロセッサへと移動されても良い。プロセッサ810は、接触媒体内に符号化された論理回路logicに反応しても良い。論理回路は、ソフトウェア、ハードウェア、IC、ファームウェア、マイクロコードなどの一部として保存されても良い。メモリ820はコンピュータ読み取り可能な保存媒体であっても良い。コンピュータ読み取り可能な保存媒体には、ランダムアクセスメモリ、読み出し専用メモリ、プログラマブル読み出し専用メモリ、電子プログラマブル読み出し専用メモリ、電子消去可能読み出し専用メモリ、フラッシュメモリ、磁気テープ、磁気ディスク、光媒体などを含め、これらに限らないが、様々な種類の揮発性又は非揮発性の保存媒体が含まれても良い。メモリ820は、単一のデバイス又は組み合わせのデバイスであっても良い。メモリ820は、プロセッサ810に近接しても、プロセッサ810の一部であっても、プロセッサ810にプログラムされても、プロセッサ810とネットワークで結ばれても、および/又はプロセッサ810と離れていても良い。プロセッサ810は、メモリ820などの1つ以上の接触型媒体に符号化された論理回路を実行するように操作可能であっても良い。1つ以上の接触型媒体に符号化された論理回路は、プロセッサによって実行可能であるとともにコンピュータ読み取り可能な保存媒体、メモリ、あるいはこれらの組み合わせに設けられた命令であっても良い。プロセッサ810は、論理回路にプログラムされ、論理回路を実行する。図面や本明細書に記載された機能、行為、あるいはタスクは、コンピュータ読み取り可能な保存媒体の中に又はその上に保存された1セット以上の論理回路又は命令に応じて実行されても良い。機能、行為、あるいはタスクは、特定の種類の命令セット、保存媒体、プロセッサ又はプロセッシング戦略とは独立するとともに、ソフトウェア、ハードウェア、IC、ファームウェア、マイクロコードなどによって単独であるいは組み合わされながら実行されても良い。一例では、図8に示すように、メモリ820は、取引戦略注文822を受信するように実行される命令以降、命令822、取引戦略注文を複数の子注文824に分割するように実行される命令以降、命令824、および複数の子注文826を提出するように実行される命令以降、命令826を備える。メモリ820は、付加的な、異なる又は少ない数の命令を備えても良い。命令822は、複数の呼び値のレッグ、1つ以上の呼び値でないレッグ又はこれらの組み合わせを有する取引戦略のための取引戦略注文を受信するように実行されても良い。例えば、取引戦略は第1および第2の呼び値のレッグを備えても良い。命令824は、取引戦略が複数の呼び値のレッグを有することを決定又は識別するように実行される命令を有しても良い。さらに、命令824は子取引戦略を定義しても良く、および/又は複数の子注文を生成する命令を定義しても良い。それぞれの子注文は、単一の又は最初の取引戦略注文よりも少ない数の呼び値のレッグを有しても良い。命令826は、複数の子注文を例えば2つ以上の交換システムに提出するように実行される命令を有しても良い。それらの交換システムは、同一の交換システムであっても異なる交換システムあっても良い。複数の子注文の提出には、呼び値の注文を約定するよう構成された交換システムに対して呼び値のレッグのための呼び値の注文を提出するよう構成されたサーバ側デバイスに子注文を送信することが含まれても良い。サーバ側デバイスは交換システムに、その周囲に、又はその中に物理的に配置されても良い。例えば、第1の子注文は第1の交換システムにてマッチングおよび約定され、第2の子注文は第2の交換システムにてマッチングおよび約定されても良い。例示的な電子取引のための方法図9は、取引戦略注文を電子的に取引するための例示的な方法900を示す。行為は、図示された注文あるいはそれ以外の注文にて実行されても良い。方法900は、複数の呼び値のレッグ910を有する取引戦略注文を受信する工程910と、その取引戦略注文を複数の子注文に分割する工程920と、電子取引を完了させる工程930とを含む。付加的な、異なる又は少ない数の行為が方法900にて実行されても良い。行為910において、取引戦略デバイスは複数の呼び値のレッグを有する取引戦略を有する取引戦略注文を受信しても良い。受信には、要請、引出しpulling、傍受あるいは獲得が含まれても良い。各種実施形態では、方法900は、例えば行為910の前に、例えば取引戦略定義に基づく取引戦略注文を生成する工程を含んでも良い。取引戦略定義は、顧客デバイスから受信しても良い。例えば、取引戦略は顧客デバイスを使用するユーザによって定義されても良い。取引戦略の定義付けには、1つ以上の取引可能オブジェクトの定義付けが含まれても良い。取引可能オブジェクトは、呼び値のレッグ又は呼び値でないレッグといったレッグであっても良い。取引戦略定義は、自動的に又はトレーダによって手動的に顧客デバイスに入力されても良い。別の例では、取引戦略定義のうちの全て又はそのいくつかが、同時又は異なるときに受信されても良い。例えば、トレーダは、取引戦略を定義する例えば、スプレッドを定義するとともに、コンフィギュレーションデータを取引戦略デバイス又はサーバ側デバイスに送信しても良い。そして、取引セッションの間において、例えば価格軸に沿って価格および数量を選択することにより、価格および数量の情報が定義されても良い。一旦生成されると、顧客デバイスは取引戦略デバイス114へ取引戦略注文を送信しても良い。取引戦略注文は、ユーザからのリクエスト例えば送信ボタンのクリックにより又は自動的に送信されても良い。例えば、トレーダは電子取引ワークステーションを利用しても良い。別の例では、自動取引ツールが注文のための1つ以上のパラメータを計算するとともにその注文を自動的に送信しても良い。いくつかの例では、自動取引ツールは送信すべき注文を準備するが、ユーザからの確認がないと実際には送信しない場合もある。いくつかの実施形態では、例えば取引戦略デバイスに割り当てられたアドレス又は通信経路を利用することにより、取引戦略デバイスを取引戦略注文の受信体として指定する。しかしながら、その他の実施形態では、取引戦略注文を取引戦略デバイスに向かわせる別のデバイスに取引戦略注文を送信する場合もある。上述のように、取引戦略注文は複数の呼び値のレッグを有する取引戦略に関連付けられても良い。すなわち、取引戦略は、呼び値のレッグとされる複数のレッグを有しても良い。呼び値のレッグとされるレッグは、取引戦略におけるレッグのうちのいくつか又はそのすべてであっても良い。行為920において、取引戦略デバイスは取引戦略注文を分割する。図10は、行為920の一例を示す。図10に示すように、分割には、複数の呼び値のレッグを有する取引戦略に関連付けられる取引戦略注文の識別1010、子取引戦略の定義付け1020および子取引戦略のための子注文の生成1030が含まれても良い。分割は上述の行為には限らない。取引戦略注文の分割には、付加的な、異なる又は少ない数の行為が含まれても良い。行為1010において、取引戦略デバイスは、複数の呼び値のレッグを有する取引戦略に関連付けられる取引戦略注文を識別する。識別には、取引戦略注文における呼び値のレッグの数のカウント、把握、計算、若しくは決定、並びに呼び値のレッグの数が2つ以上かどうかの決定が含まれても良い。例えば、取引戦略デバイスは、取引戦略注文におけるそれぞれのレッグを分析し、それぞれのレッグか呼び値のレッグか呼び値でないレッグかを決定し、呼び値のレッグとされるレッグの数をカウントしても良い。別の例では、顧客デバイスは、例えば取引戦略注文を生成するときに、取引戦略注文における呼び値のレッグの数を表示するために指定されたフィールドにおける呼び値のレッグの数を表示する。したがって、取引戦略デバイスはそのフィールドの読み取りおよび分析を行っても良い。行為1020において、取引戦略デバイスは子取引戦略を定義する。例えば、複数の呼び値のレッグを有する取引戦略に関連付けられる取引戦略注文の識別に応じて、取引戦略デバイスは複数の子取引戦略を定義する。子取引戦略は、値付けされているレッグの数を除き、取引戦略注文に関連付けられる取引戦略と同一である。すなわち、戦略例えば、取引可能オブジェクトの売りおよび/又は買いが同一であっても、子取引戦略における呼び値のレッグとされるレッグの数は、取引戦略注文に関連付けられる取引戦略における呼び値のレッグとされるレッグの数と異なる例えば少ない。例えば、子取引戦略は、単一の又は例えば取引戦略注文における呼び値のレッグの数に比べて低減された数の呼び値のレッグを有しても良い。上述のように、定義された子取引戦略の数は例えば、取引戦略注文における呼び値のレッグの数に依存する。それぞれの子取引戦略は単一の呼び値のレッグを有しても良い。しかしながら、別の例では、複数の呼び値のレッグが単一の子取引戦略の中に含まれる、又はグループ化されても良い。呼び値のレッグは、呼び値のレッグのマッチングを行うように構成された交換システムに基づきグループ化されても良い。例えば、同一の交換システムにて取引される呼び値のレッグが、同一の子取引戦略に含まれても良い。しかしながら、ともにグループ化される場合であっても、子注文における呼び値のレッグの数は、取引戦略注文における呼び値のレッグの数よりも少ない。それぞれの子取引戦略は呼び値のレッグを有さないか、1つ以上の呼び値のレッグを有する。例えば、子取引戦略における呼び値のレッグの数は、最初の注文の取引戦略における呼び値のレッグの数よりも少ない。行為1030において、子取引戦略注文が生成されても良い。それぞれの子注文は子取引戦略のうちの1つを有しても良い。子取引戦略のうちの1つ、いくつかあるいはすべてが定義されると、行為1020に示すように、取引戦略デバイスは複数の子取引戦略注文を生成する。それぞれの子注文は、単一の又は低減された数の呼び値のレッグを有する子取引戦略を有する。例えば、取引戦略注文における取引戦略の複雑さに基づいて、あらゆる数例えば、2又はそれよりも多くの子注文を生成しても良い。例えば、子取引戦略の生成には、取引戦略注文に関連付けられる取引戦略におけるそれぞれの値付けされたレッグのための子注文の生成が含まれても良い。別の例では、子取引戦略の生成には、例えば子取引戦略をグループ化することにより、生成する必要がある子注文の数を最小化することが含まれても良い。レッグ又は取引戦略は、例えば、待ち時間、サーバ側デバイス、交換システム若しくはゲートウェイの物理的位置、トレーダの好み、交換能力、その他の既知の若しくは最近開発された基準、又はこれらのあらゆる組み合わせに基づきグループ化されても良い。子取引注文を生成する際には、子注文におけるレッグの全て、いくつか又は1つが呼び値のレッグであっても良く、あるいは呼び値のレッグがなくても良い。すなわち、子注文は、あらゆる数の呼び値でないレッグおよび/又は呼び値のレッグを有しても良い。子注文の数は、例えば取引戦略におけるレッグの数、呼び値のレッグの数、待ち時間、交換能力又はこれらのあらゆる組み合わせに依存しても良い。子注文における呼び値でないレッグおよび呼び値のレッグの数は、同一であっても異なっても良い。子注文における呼び値でないレッグおよび呼び値のレッグの数は、子注文の間で変化しても変化しなくても良い。例えば、子注文において、呼び値のレッグは他の呼び値のレッグ又は呼び値でないレッグと混合されても良い。しかしながら、単一の呼び値でないレッグおよび呼び値のレッグが、代替的に又は付加的に独立しても良い。取引戦略デバイスは、子注文の数、それぞれの子注文における呼び値でないレッグの数若しくは呼び値のレッグの数、又はこれらの組み合わせを、例えば子注文を提出する際の待ち時間に基づいて決定しても良い。取引戦略デバイスは子注文を提出する際にかかる時間を最小化しても良い。図9に戻ると、行為930において、取引戦略デバイスは取引トランザクションを完了しても良い。取引トランザクションの完了には、1つ以上のサーバ側デバイスへの子取引戦略注文の送信が含まれても良い。取引戦略デバイスは複数の子注文の送り先を知的に決定しても良い。例えば、子注文をサーバ側デバイスに送信しても良く、そのサーバ側デバイスは、子注文における呼び値のレッグを約定するよう構成された交換システムにて子注文を取引するよう構成されている。子注文を取引するよう構成されたサーバ側デバイスが複数存在する場合には、取引戦略デバイスは、交換システムに最も近いサーバ側デバイスに子注文を送信しても良い。例えば、図示のように、子注文を交換システムに最も近いサーバ側デバイスに送信し、子注文を交換システムに最も近いサーバ側デバイスに送信しても良い。さらに、取引戦略デバイスは例えば、待ち時間に基づき子注文を送信するための通信経路を選択しても良い。待ち時間には、サーバ側デバイスや交換システムなどの受信デバイスが取引戦略デバイスからの子注文を受信するのに必要な時間が含まれる。取引戦略デバイスは、例えば取引戦略デバイスと交換システムとの間の遅延時間が最も少ない又は低減されている通信経路を介して子注文を提出することにより、待ち時間を低減又は最小化しても良い。通信経路は取引戦略デバイスと交換システムとを接続しても良い。一例では、通信経路には、取引戦略デバイスに遅延を報告する通信ノード、ルータ又はサーバなどの通信デバイスが含まれても良い。取引戦略デバイスは最適な例えば、待ち時間が最も少ない通信経路を決定するために情報を解析しても良い。いくつかの実施形態では、方法900には、子注文に関連付けられる呼び値の注文の提出が含まれても良い。呼び値の注文は、例えば交換システムによって必要とされるように構成された注文であっても良い。したがって、子注文は、呼び値の注文であっても良く、呼び値の注文と異なっても良い。すなわち、子注文は交換システムによって必要とされるように構成されても、そのように構成されなくても良い。サーバ側デバイスは呼び値の注文を提出する。さらに、行為930には、ヘッジ注文の提出、部分的な約定注文の受信、部分的なヘッジ注文の提出、キャンセル注文の提出例えば、注文が注文をキャンセルする、取引戦略が実行されることの確保が含まれても良い。当然、呼び値の注文を取り扱う際にその他の行為が実施されても良い。例示的な例証次の例証は、分配型サーバ側デバイス環境の概念および利点のいくつかを示す。次の例証は、各種実施形態のうちのいくつかについて説明するのみであり、全ての実施形態を開示するものとして解釈されるべきではない。トレーダは、ニューヨークに物理的に配置された顧客デバイスを用いるとともに、東京商品取引所TOCOMおよびシカゴマーカンタイル取引所CMEにて取引される原油のスプレッド取引を行っている。本例証では、東京で取引される原油をCOTとし、シカゴで取引される原油をCOCとする。ニューヨークおよび取引所のある町の距離が長いことにより、以下で説明するように、分配型サーバ側環境を使用することの特別な利点が生じる。取引セッションの間、トレーダは顧客デバイスを用いてスプレッド例えば、COT-COCのための取引注文を提出する。本例証では、スプレッドは2つのレッグを有する。第1のレッグはCOTの購入に関連し、第2のレッグはCOCの購入に関連する。トレーダは、例えば取引画面上の1つ以上のボックスをチェックすることで、両方のレッグが値付けされるべきであることを表示していても良い。したがって、スプレッドは複数の呼び値のレッグを有する。特に、スプレッドは2つの呼び値のレッグを有する。一旦受信されると、取引戦略は、スプレッドが2つの呼び値のレッグを有していることを識別する。これに応じて、取引戦略デバイスは、第1の子取引戦略注文を第1のサーバ側デバイスに送信し、第2の子取引戦略注文を第2のサーバ側デバイスに送信する。第1および第2のサーバ側デバイスは異なるサーバ側デバイスである。第1のレッグのみが第1の子取引戦略注文にて値付けされ、第2のレッグのみが第2の子取引戦略注文にて値付けされることを除き、第1および第2の子取引戦略注文は、オリジナルの取引注文と同じ取引戦略に関連付けられる。本例証では、取引戦略デバイスは顧客デバイスに又はその近傍に物理的に配置される。したがって、第1のサーバ側デバイスはTOCOMに、その中に又はその近傍に配置され、第2のサーバ側デバイスはCMEに、その中に又はその近傍に配置されるので、取引戦略デバイスニューヨークと第1のサーバ側デバイス東京との距離は約6735マイルであり、取引戦略デバイスニューヨークと第2のサーバ側デバイスシカゴとの距離は約711マイルである。したがって、取引戦略デバイスから第1のサーバ側デバイスへ又はその逆に送られるデータは約220ミリ秒かかり、取引戦略デバイスから第2のサーバ側デバイスへ又はその逆に送られるデータは約30ミリ秒かかる。第1のサーバ側デバイスがTOCOMに、その中に又はその近傍に存在するので、第1のサーバ側デバイスからTOCOMまでデータを転送する際にかかる時間は、概ね10ミリ秒である。同様に、第2のサーバ側デバイスがCMEに、その中に又はその近傍に存在するので、第2のサーバ側デバイスからCMEまで又はその逆にデータを転送する際にかかる時間は、概ね10ミリ秒である。これらの数字については単なる例である。更なる説明の前に、本例証におけるそれぞれの値例えば、時間や距離などは例示の目的のみによるものであることに再度留意すべきである。これらの値のうちの1つ、いくつか又は全ては様々な理由により変更しても良く、将来的に変化しても良い。第1および第2の子取引戦略が定義されると、取引戦略デバイスは、第1の子取引戦略注文を、TOCOMに、その中に又はその近傍にある第1のサーバ側デバイスに送信し、第2の子取引戦略注文を、CMEに、その中に又はその近傍にある第2のサーバ側デバイスに送信する。第1のサーバ側デバイスは、第1の子取引戦略注文にて値付けされた唯一のレッグである第1のレッグを取り扱うように構成され、第2のサーバ側デバイスは、第2の子取引戦略注文にて値付けされた唯一のレッグである第2のレッグを取り扱うように構成される。注文の取り扱いの一部として、第1のサーバ側デバイスは第1の呼び値の注文を生成するとともに、第1の呼び値の注文をTOCOMに提出する。第1のサーバ側デバイスは第2の呼び値の注文を生成するとともに、第2の呼び値の注文をCMEに提出する。呼び値の注文を取り扱う分配型サーバ側デバイスの利点の1つは、サーバ側デバイスと取引所との間におけるデータ転送が、複数の取引所にて複数の呼び値の注文を取り扱う単一のサーバ側デバイスの場合よりも小さいということである。すなわち、第1および第2の子取引戦略注文をTOCOMにある単一のサーバ側デバイスが取り扱っていたとすると、その単一のサーバ側デバイスはCMEからのデータを約250ミリ秒待つ必要があると予想される。第2のサーバ側デバイスが待つ必要のある約10ミリ秒と比較すると、利点は非常に顕著である。結論本明細書は数多くの発明を含む。各種発明はそれらの適用が、要約書若しくは明細書に記載され又は図面に図示された構成要素の設計および配置の詳細に限定されない。それらの発明は他の実施形態も可能であり、あるいは様々な方法によって実験又は実行されても良い。なお、各種変形例を作成しても良く、均等物によって代用されても良く、および/又は多くの修正を施しても良い。発明が限定されないことを目的としている。"