(57)【特許請求の範囲】
【請求項１】
市場データを受信し、取引アルゴリズムに基づいて電子取引を実行することが可能なクライアントデバイスであって、
受信された前記市場データを保持する第１保持部と、
複数の機能ブロックに基づく前記取引アルゴリズムの定義を受信する第１処理部と、
前記複数の機能ブロックを表示する第１表示部と、
受信された市場データを用いるとともに、前記第１処理部により受信された機能ブロックに基づいて、それぞれの機能ブロックに関連付けられた機能に基づく演算を行う第２処理部と、
前記複数の機能ブロックの内、選定された途中の機能ブロックにおける演算結果であるライブフィードバック値を保持する第２保持部と、
前記第２保持部により保持された前記ライブフィードバック値を、前記選定した機能ブロックに関連して表示するように前記第１表示部を制御する第３処理部と、
を含むクライアントデバイス。
【請求項２】
前記複数の機能ブロックは、利用可能な複数の機能ブロックからユーザによって選択される、請求項１に記載のクライアントデバイス。
【請求項３】
前記複数の機能ブロックによる配列は、前記複数の機能ブロックにおける１つまたは複数の機能ブロック間の１つまたは複数の接続を含む、請求項１に記載のクライアントデバイス。
【請求項４】
前記第２保持部により保持される前記ライブフィードバック値は、前記選定された途中の機能ブロックに続く次の機能ブロックの入力に関して決定される、請求項１に記載のクライアントデバイス。
【請求項５】
前記第２保持部により保持される前記ライブフィードバック値は、前記選定された途中の機能ブロックの出力に関して決定される、請求項１に記載のクライアントデバイス。
【請求項６】
前記市場データは電子取引所から受信される、請求項１に記載のクライアントデバイス。
【請求項７】
前記市場データはシミュレーション環境から受信される、請求項１に記載のクライアントデバイス。
【請求項８】
前記第２保持部により保持される前記ライブフィードバック値はさらに、前記選定された途中の機能ブロックに対応する機能を基礎とする、請求項１に記載のクライアントデバイス。
【請求項９】
不連続イベントの発生を検出する検出部をさらに備え、
前記第１表示部は、前記検出部で検出された前記不連続イベントの発生を表すインジケータを表示可能である、請求項１に記載のクライアントデバイス。
【請求項１０】
前記第１表示部は、前記発生される不連続イベントが提供される接続をフラッシュするように前記インジケータを表示する、請求項９に記載のクライアントデバイス。
【請求項１１】
前記第１表示部は、前記発生される不連続イベントが提供される出力のアニメーションを行うように前記インジケータを表示する、請求項９に記載のクライアントデバイス。
【請求項１２】
前記第１表示部は、前記発生される不連続イベントが提供される接続に対してアニメーションを行うように前記インジケータを表示する、請求項９に記載のクライアントデバイス。
【請求項１３】
前記第２保持部は、前記複数の機能ブロックの内、前記選定された途中の機能ブロックとは異なる機能ブロックまでの演算結果であるライブフィードバック値も保持する、請求項９に記載のクライアントデバイス。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願の相互参照
本出願は、２００９年１０月２０日に提出された「先物ランキングおよび発注ツール、価格レベルインジケータツールおよび市場変化可聴インジケータツールを用いる取引アプリケーション」と題する米国暫定特許出願第６１／２５３，３１５号、２００９年１０月２０日に提出された「ユーザ定義電子取引交換アルゴリズムを構築するためのシステムおよび方法」と題する米国暫定特許出願第６１／２５３，３２４号、２００９年１１月２０日に提出された「ユーザ定義電子取引交換アルゴリズムを構築するためのシステムおよび方法」と題する米国暫定特許出願第６１／２６３，３００号、２０１０年３月９日に提出された「自動取引アプリケーションを立ち上げるためのシステムおよび方法」と題する米国暫定特許出願第６１／３１２，００３号、２０１０年３月２９日に提出された「ユーザ定義電子取引交換アルゴリズムをバーチャル化するためのシステムおよび方法」と題する米国暫定特許出願第６１／３１８，６８５号、２０１０年４月１日に提出された「フィードバックベースのユーザ定義電子取引交換アルゴリズムを自動化するためのシステムおよび方法」と題する米国暫定特許出願第６１／３２０，０６１号、２０１０年１０月１４日に提出された「ユーザ定義電子取引アルゴリズム」と題する米国暫定特許出願第６１／３９３，３１３号、２０１０年１０月１５日に提出された「ユーザ定義電子取引アルゴリズム」と題する米国非暫定特許出願第１２／９０５，７０９号および２０１０年１０月１５日に提出された「ユーザ定義電子取引アルゴリズムのバーチャル化」と題する米国非暫定特許出願第１２／９０５，７２６号の出願の利益を主張するものである。これらの出願は各々、本参照によりその全体が開示に含まれる。
【背景技術】
【０００２】
本明細書に記述する技術は、電子取引システムに関する。より具体的には、所定の実施形態は、ユーザが定義する電子取引アルゴリズムに関する。
【０００３】
電子取引システムは、概して、クライアントデバイスのホストとして機能し得る電子取引所と通信するクライアントデバイスを含む。典型的には、電子取引システムは、取引可能なオブジェクトを売買する電子的に合致する注文が取引されるように図る。取引可能なオブジェクトは、取引され得るアイテムである。株式、オプション、先物契約、証券および商品は、取引可能なオブジェクトの幾つかの例である。
【０００４】
電子取引所は、クライアントデバイスへ市場データを送信する。市場データには、例えば、価格データ、市場の深さデータ、最終取引量データ、取引可能オブジェクトの市場関連データおよび／またはこれらの組合せが含まれる場合がある。クライアントデバイスは、電子取引所から市場データを受信する。
【０００５】
電子取引システムによっては、クライアントデバイスは市場データを受信しかつディスプレイデバイスに表示することなくこれらの市場データを処理する。例えば、「ブラックボックス」アルゴリズム取引システムは、自動的かつ市場データを表示することなく実行される場合がある。しかしながら、他の電子取引システムでは、クライアントデバイスは、処理される市場データをディスプレイデバイスに表示する。クライアントデバイスは、取引画面を作り出すソフトウェアを含む場合がある。概して、取引画面は、ユーザが電子取引セッションへ参加できるようにする。例えば、取引画面は、ユーザが市場データを見ること、電子取引所へ取引注文を出すこと、市場相場を入手すること、ポジションを監視すること、かつ／またはこれらを組み合わせて行うことを可能にする場合がある。
【０００６】
電子取引システムによっては、クライアントデバイスは電子取引所へ取引注文を送信する。しかしながら、他の電子取引セッションでは、サーバ側デバイス等の他のデバイスが電子取引所への１つまたは複数の取引注文の送信を担当する。取引注文を受信すると、電子取引所は交換注文帳へ取引注文を記入し、取引注文の量と１つまたは複数の相手側取引注文の量との整合を試みる。例として、売り注文は同額による買い注文に対する相手側である。同様に、買い注文は同額による売り注文に対する相手側である。整合しない取引注文量は、取引注文量が整合されるまで電子取引所によって交換注文帳に保持される。不整合の取引注文量は、クライアントデバイスまたは電子取引所の何れかによって取引注文がキャンセルされた場合にも注文帳から除外されることがある。取引注文量が整合すると、電子取引所はクライアントデバイスへ、取引注文量が整合されたという確認書を送信する場合がある。
【０００７】
電子取引所は、増大する数の参加者が市場において任意の所定の時間に活動できるようにしている。潜在的市場参加者数の増加は、効果的には、とりわけ、より競争的な市場およびより大きい資産流動性をもたらしている。電子取引のような、取引の機会を得るために一秒一秒または１秒の何分の１かが悉く重要である競争的環境においては、参加者が市場において効果的に競争する手助けをする、または参加者を他者より優位に立たせもするツールを提供することが望ましい。
【０００８】
現行システムの中には、市場情報の変化のより迅速な評価およびそれに対する対応を可能にするアルゴリズム取引システムを含むものがある。しかしながら、このようなシステムは、典型的には取引アルゴリズムを開発する熟練したプログラマーを必要とし、試験およびデバッグに何日も（または何か月も）かかり、かつトレーダが異なるアプローチを決定する、またはアルゴリズム論理の修正を望む際には、この開発およびデバッグプロセスが繰り返されなければならない。
【発明の概要】
【発明が解決しようとする課題】
【０００９】
本明細書に記述する実施形態は、様々なデバイス、システム、方法およびコンピュータ・プログラム・プロダクトを含むが、これらに限定されない。
【課題を解決するための手段】
【００１０】
所定の実施形態は、ビルディング・ブロック・ボタンおよびアルゴリズムを定義するアルゴリズムエリアを提供する。所定の実施形態は、単一の取引セッションの間であってもアルゴリズムのパラメータおよび論理の双方を迅速に調整することを見込んでいる。所定の実施形態は、アルゴリズムが定義されるにつれて式のライブ評価を提供する。所定の実施形態は、構文エラー、不明瞭な論理およびトレーダでないプログラマがトレーダにより指定される通りにアルゴリズムを開発する必要性等の伝統的にプログラムされるアルゴリズムのリスクを、ユーザによるプログラミングコードの書込みを減らす、またはなくすことによって低減する。所定の実施形態は、アルゴリズムの構築、デバッグおよび（実際の市場データを用いる）シミュレーションを全て同時に行うための単一のアプリケーションを提供する。さらに、この単一のアプリケーションは、アルゴリズムを用いる発注の開始にも備える場合がある。
【００１１】
所定の実施形態は、アルゴリズムを設計するための設計キャンバスエリアおよびブロックを提供する。所定の実施形態は、アルゴリズムで用いるための複雑な機能を有するブロックを提供する。所定の実施形態は、設計キャンバスエリア内に置かれる複数のブロックをグループ化することに備える。所定の実施形態は、アルゴリズムの一部の動的なインスタンス化が特定の不連続イベントを取り扱うことを可能にする仮想化されたグループブロックを準備する。所定の実施形態は、単一の取引セッションの間であってもアルゴリズムのパラメータおよび論理の双方を迅速に調整することを見込んでいる。所定の実施形態は、アルゴリズムが定義されるにつれてブロックのライブフィードバックを提供する。所定の実施形態は、アルゴリズムが設計される際の潜在的エラーを減らすための安全機能を提供する。所定の実施形態は、クライアントデバイスとアルゴリズムサーバとの接続が破断された場合のアルゴリズムの幾つかの部分または全ての部分の作動を準備する。所定の実施形態は、構文エラー、不明瞭な論理およびトレーダでないプログラマがトレーダにより指定される通りにアルゴリズムを開発する必要性等の伝統的にプログラムされるアルゴリズムのリスクを、ユーザによるプログラミングコードの書込みを減らす、またはなくすことによって低減する。所定の実施形態は、アルゴリズムの構築、デバッグおよび（実際の市場データを用いる）シミュレーションを全て同時に行うための単一のアプリケーションを提供する。さらに、この単一のアプリケーションは、アルゴリズムを用いる発注の開始にも備える場合がある。
【００１２】
所定の実施形態は、選択されたアルゴリズムによってある注文タイプとして管理されるべき発注の開始に備える。所定の実施形態は、値軸から選択されるユーザ定義取引アルゴリズムによって管理されるべき発注の開始に備える。所定の実施形態は、アルゴリズムがある注文を管理している間にアルゴリズムの変数を変更することに備える。所定の実施形態は、アルゴリズムによって管理されている注文を手動で修正することに備える。所定の実施形態は、非管理注文へその注文を管理するためのアルゴリズムを割り当てることに備える。所定の実施形態は、異なるユーザ定義取引アルゴリズムによって管理されている受付中の注文を値軸へ表示することに備える。
【００１３】
所定の実施形態は、ランキングツールを提供する。所定の実施形態は、発注に使用されるべき選択された取引可能オブジェクトのランキング表示を準備する。所定の実施形態は、ランキングを基礎として注文を開始するための実行戦略を選択することに備える。
【００１４】
以下、他の実施形態について述べる。さらに、記述される実施形態には、発明の精神または範囲を逸脱することなく修正が行われる場合がある。
【図面の簡単な説明】
【００１５】
本明細書では、下記の図面を参照して実施形態例について説明する。
【００１６】
【図１】所定の実施形態が使用され得る電子取引システムを示すブロック図である。
【００１７】
【図２Ａ】所定の実施形態による取引インタフェースを示す。
【００１８】
【図２Ｂ】所定の実施形態によるインスツルメント選択インタフェースを示す。
【００１９】
【図２Ｃ】所定の実施形態による、取引インタフェースでのアルゴリズム定義の構築を示す。
【図２Ｄ】所定の実施形態による、取引インタフェースでのアルゴリズム定義の構築を示す。
【図２Ｅ】所定の実施形態による、取引インタフェースでのアルゴリズム定義の構築を示す。
【図２Ｆ】所定の実施形態による、取引インタフェースでのアルゴリズム定義の構築を示す。
【図２Ｇ】所定の実施形態による、取引インタフェースでのアルゴリズム定義の構築を示す。
【図２Ｈ】所定の実施形態による、取引インタフェースでのアルゴリズム定義の構築を示す。
【図２Ｉ】所定の実施形態による、取引インタフェースでのアルゴリズム定義の構築を示す。
【００２０】
【図２Ｊ】所定の実施形態による取引インタフェースを示す。
【００２１】
【図３Ａ】所定の実施形態が使用され得る電子取引システムを示すブロック図である。
【００２２】
【図３Ｂ】所定の実施形態による取引インタフェースを示す。
【００２３】
【図３Ｃ】所定の実施形態による、取引インタフェースにおいて使用され得るブロックの例を示す。
【００２４】
【図３Ｄ−１】所定の実施形態によって生成されるプログラミングコードの例を示す。
【図３Ｄ−２】所定の実施形態によって生成されるプログラミングコードの例を示す。
【図３Ｄ−３】所定の実施形態によって生成されるプログラミングコードの例を示す。
【図３Ｄ−４】所定の実施形態によって生成されるプログラミングコードの例を示す。
【図３Ｄ−５】所定の実施形態によって生成されるプログラミングコードの例を示す。
【図３Ｄ−６】所定の実施形態によって生成されるプログラミングコードの例を示す。
【図３Ｄ−７】所定の実施形態によって生成されるプログラミングコードの例を示す。
【００２５】
【図３Ｅ】所定の実施形態による取引インタフェースを示す。
【図３Ｆ】所定の実施形態による取引インタフェースを示す。
【図３Ｇ】所定の実施形態による取引インタフェースを示す。
【図３Ｈ】所定の実施形態による取引インタフェースを示す。
【図３Ｉ】所定の実施形態による取引インタフェースを示す。
【図３Ｊ】所定の実施形態による取引インタフェースを示す。
【図３Ｋ】所定の実施形態による取引インタフェースを示す。
【図３Ｌ】所定の実施形態による取引インタフェースを示す。
【図３Ｍ】所定の実施形態による取引インタフェースを示す。
【図３Ｎ】所定の実施形態による取引インタフェースを示す。
【図３Ｏ】所定の実施形態による取引インタフェースを示す。
【図３Ｐ】所定の実施形態による取引インタフェースを示す。
【図３Ｑ】所定の実施形態による取引インタフェースを示す。
【図３Ｒ】所定の実施形態による取引インタフェースを示す。
【００２６】
【図４Ａ】所定の実施形態による取引インタフェースを示す。
【図４Ｂ】所定の実施形態による取引インタフェースを示す。
【図４Ｃ】所定の実施形態による取引インタフェースを示す。
【図４Ｄ】所定の実施形態による取引インタフェースを示す。
【図４Ｅ】所定の実施形態による取引インタフェースを示す。
【図４Ｆ】所定の実施形態による取引インタフェースを示す。
【００２７】
【図５】所定の実施形態によるランキングツールを示す。
【００２８】
【図６】所定の実施形態によるコンピューティングデバイスを示すブロック図である。
【００２９】
前述の発明の概要ならびに下記の詳細な説明は、所定の実施形態を示す諸図と関連させて読むことにより、さらによく理解されるであろう。
諸図は、所定の実施形態を例示するためのものであり、本発明が図面に示された配置および手段に限定されないことは理解されるべきである。
【発明を実施するための形態】
【００３０】
Ｉ．  電子取引システム例
【００３１】
図１は、所定の実施形態が使用され得る電子取引システム１００を示すブロック図である。システム１００は、クライアントデバイス１１０と、ゲートウェイ１２０と、電子取引所１３０とを含む。クライアントデバイス１１０は、ゲートウェイ１２０と通信している。ゲートウェイ１２０は、電子取引所１３０と通信している。
【００３２】
本明細書において「と通信している」という言い回しは、直接的な通信および１つまたは複数の中間コンポーネントを介する間接的通信を含む場合がある。
【００３３】
作動中、クライアントデバイス１１０は、取引可能オブジェクトを買う、または売るための注文を取引所１３０へ送ってもよい。例えば、ユーザは、クライアントデバイス１１０を利用して注文を送ってもよい。注文は、ゲートウェイ１２０を介して取引所１３０へ送られる。さらには、市場データが取引所１３０からゲートウェイ１２０を介してクライアントデバイス１１０へ送られる。また、ユーザは、クライアントデバイス１１０を利用してこの市場データを監視し、かつ市場データを基礎として取引可能オブジェクトに関する注文を送るように決定してもよい。
【００３４】
取引可能オブジェクトは、ある量および／または価格で取引されることが可能な任意のものである。例えば、株式、オプション、債券、先物、通貨、ワラント、ファンド派生商品、証券、商品、取引されるイベント、グッズおよびコレクションおよび／またはこれらの組合せ等の金融商品が取引可能オブジェクトであってもよい。取引可能オブジェクトは、「実物」であっても、「合成物」であってもよい。実物である取引可能オブジェクトには、取引所によってリストされている商品が含まれる。合成物である取引可能オブジェクトには、ユーザによって定義され、取引所によってリストされていない商品が含まれる。例えば、合成物である取引可能オブジェクトには、クライアントデバイス１１０を利用するトレーダによって作成される合成スプレッド等の実際の（または他の合成）商品の組合せが含まれてもよい。
【００３５】
クライアントデバイス１１０には、例えば、携帯デバイス、ラップトップ、デスクトップコンピュータ、シングルまたはマルチ・コア・プロセッサを有するワークステーション、複数のプロセッサを有するサーバおよび／またはコンピュータのクラスタ等の１つまたは複数の電子コンピューティングプラットフォームが含まれてもよい。例えば、クライアントデバイス１１０は、論理上は単一のデバイスとして表現されるが、取引する側の端末およびサーバが集合的にクライアントデバイス１１０である、サーバと通信する取引端末を含んでもよい。取引端末はユーザへ取引画面を提示してもよく、かつ取引画面を介する発注等のユーザ入力のさらなる処理に関するコマンドをサーバへ伝達してもよい。
【００３６】
クライアントデバイス１１０は、概して、ユーザにより所有され、操作され、制御され、プログラムされ、設定され、または別途使用される。本明細書において、「ユーザ」という言い回しは、人（例えば、トレーダ）または電子取引デバイス（例えば、プロセッサおよびメモリまたはアルゴリズム取引システムを含む）を含んでもよいが、これらに限定されない。一人または複数のユーザは、例えば、オーナーシップ、操作、制御、プログラミング、設定または他の用途に関係するものであってもよい。
【００３７】
クライアントデバイス１１０は、１つまたは複数の取引アプリケーションを含んでもよい。取引アプリケーションは、例えば、市場データを配列して取引ウィンドウおよびチャートウィンドウに表示することによって市場データを処理してもよい。市場データは、例えば取引所１３０から受信されてもよい。別の例として、市場データは、履歴データを提供しかつ／または交換をシミュレートするが実世界の取引は実行しないシミュレーション環境から受信されてもよい。この処理は、例えば、ユーザ選好を基礎とするものであってもよい。取引アプリケーションは、例えば、自動スプレッド取引ツール等の自動取引ツールを含んでもよい。１つまたは複数の取引アプリケーションは、クライアントデバイス１１０のコンピューティングデバイスのうちの１つまたはそれ以上に分散されてもよい。例えば、取引アプリケーションの所定のコンポーネントは取引ワークステーション上で実行されてもよく、かつ取引アプリケーションの他のコンポーネントはワークステーションと通信するサーバ上で実行されてもよい。
【００３８】
クライアントデバイス１１０は、例えば、電子取引ワークステーション、携帯用取引デバイス、「ブラックボックス」または「グレーボックス」等のアルゴリズム取引システム、内蔵式の取引システムおよび／または自動取引ツールを含んでもよい。例えば、クライアントデバイス１１０は、イリノイ州シカゴ所在のＴｒａｄｉｎｇ  Ｔｅｃｈｎｏｌｏｇｉｅｓ  Ｉｎｔｅｒｎａｔｉｏｎａｌ社によって提供される電子取引プラットフォームである、Ｘ＿ＴＲＡＤＥＲ（登録商標）のコピーを実行するコンピューティングシステムであってもよい。別の例として、クライアントデバイス１１０は、同じくＴｒａｄｉｎｇ  Ｔｅｃｈｎｏｌｏｇｉｅｓ  Ｉｎｔｅｒｎａｔｉｏｎａｌ社によって提供されるＡｕｔｏｓｐｒｅａｄｅｒ（登録商標）および／またはＡｕｔｏｔｒａｄｅｒ（商標）等の自動取引ツールを実行するコンピューティングデバイスであってもよい。
【００３９】
取引アプリケーションは、クライアントデバイス１１０のコンピュータ読取り可能媒体に格納されてもよい。所定の実施形態において、取引アプリケーションの所定のコンポーネントは取引ワークステーションに格納されてもよく、かつ取引アプリケーションの他のコンポーネントはワークステーションと通信するサーバに格納されてもよい。所定の実施形態において、取引アプリケーションの１つまたは複数のコンポーネントは、クライアントデバイス１１０のコンピュータ読取り可能媒体へ別のコンピュータ読取り可能媒体からロードされてもよい。例えば、取引アプリケーション（または取引アプリケーションの更新）は、製造業者、開発者または発行者によって１つまたは複数のＣＤまたはＤＶＤに格納されてもよく、前記ＣＤまたはＤＶＤは、次に、クライアントデバイス１１０へのアプリケーションのロードを担当する誰かへ、またはクライアントデバイス１１０が取引アプリケーションを検索する先のサーバへ提供される。別の例として、クライアントデバイス１１０は、取引アプリケーション（または取引アプリケーションの更新）をサーバから、例えばインターネットまたは内部ネットワークを介して受信してもよい。クライアントデバイス１１０は、取引アプリケーションまたは更新を、クライアントデバイス１１０が要求して受信する（「プル配信」）場合もあれば、クライアントデバイス１１０が要求しなくても受信する（「プッシュ配信」）場合もある。
【００４０】
クライアントデバイス１１０は、取引可能オブジェクトの買い注文または売り注文を送信するように適合化される。またクライアントデバイス１１０は、例えば、注文をキャンセルし、注文を変更しかつ／または交換を照会するように適合化されてもよい。別の例として、クライアントデバイス１１０は、実世界での取引を実行しないシミュレーション環境におけるシミュレートされた取引所へ注文を送信するように適合化されてもよい。
【００４１】
クライアントデバイス１１０によって送信される注文は、例えばユーザに要求されて送信される場合もあれば、自動的に送信される場合もある。例えば、トレーダは、電子取引ワークステーションを利用して特定の取引可能オブジェクトを発注し、その注文について、注文の価格および／または数量等の様々なパラメータを手動で提供してもよい。別の例として、自動取引ツールは、ある注文に関する１つまたは複数のパラメータを計算し、かつ自動的に注文を送信してもよい。インスタンスによっては、自動取引ツールは送信されるべき注文を準備する場合があるが、ユーザからの確認なしには実際には送信しない。
【００４２】
所定の実施形態において、クライアントデバイス１１０はユーザインタフェースを含む。ユーザインタフェースは、例えば、取引アプリケーションのテキストベースのインタフェースまたはグラフィカルインタフェースをユーザに提示するための１つまたは複数のディスプレイデバイスを含んでもよい。例えば、ディスプレイデバイスには、コンピュータモニタ、ハンドヘルドデバイスのディスプレイ、プロジェクタおよび／またはテレビが含まれてもよい。ユーザインタフェースは、取引アプリケーションを用いて注文に関するパラメータを指定する、または見直すために、ユーザによって用いられてもよい。ユーザインタフェースは、例えば、ユーザからの入力を受信するための１つまたは複数の入力デバイスを含んでもよい。例えば、入力デバイスには、キーボード、トラックボール、２つまたは３つボタン式マウスおよび／またはタッチスクリーンが含まれてもよい。ユーザインタフェースは、ユーザと相互に作用するための他のデバイスを含んでもよい。例えば、情報は、スピーカを介して聴覚的にユーザへ提供されても、かつ／またはマイクロホンを介して受信されてもよい。
【００４３】
所定の実施形態において、取引アプリケーションは、トレーダが１つまたは複数の市場と相互作用できるようにする１つまたは複数の取引画面を含んでもよい。取引画面は、例えば、トレーダが、様々な取引戦略を実装しながら市場情報を入手して視聴し、注文エントリパラメータを設定し、注文を出しかつキャンセルし、かつ／またはポジションを監視できるようにしてもよい。例えば、取引アプリケーションは、取引所１３０から情報（買い呼び値、買い数量、売り呼び値、売り数量、過去の販売に関する価格および数量および／または他の市場関連情報等）を受信してもよく、これらの情報は次に、クライアントデバイス１１０のユーザインタフェースによって表示されてもよい。受信される情報を基礎として、取引画面は、取引可能オブジェクトに関する一定範囲の価格レベルおよびその価格レベルの対応する売買数量を表示してもよい。トレーダに関連取引情報を提供するために、取引画面は、場内市場辺りの価格範囲（および対応する売買数量）を表示してもよい。情報は取引アプリケーションへ絶えず、または定期的に提供されてもよく、これにより取引アプリケーションは、取引画面を現行の市場情報で更新することができる。トレーダは取引画面を用いて、例えば、取引可能オブジェクトの買い注文および売り注文を出しても、別途、表示された情報を基礎として取引可能オブジェクトの取引を行ってもよい。
【００４４】
取引画面は、１つまたは複数の取引ツールを表示してもよい。取引ツールは、電子取引を可能にし、アシストしかつ／または容易にする電子ツールである。例示的な取引ツールには、チャート、取引ラダー、注文エントリツール、自動取引ツール、自動スプレッドツール、リスク管理ツール、注文パラメータツール、注文エントリシステム、市場格子、フィルウィンドウおよび市場注文ウィンドウ、これらの組合せ、取引、取引の準備または取引の管理に用いられる他の電子ツールが含まれるが、この限りではない。
【００４５】
所定の実施形態において、クライアントデバイス１１０はアルゴリズム取引アプリケーションを含む。例えば、クライアントデバイス１１０はブラックボックスまたはグレーボックス取引アプリケーションを含んでもよい。別の例として、クライアントデバイス１１０は、市場データをアルゴリズム的に処理する、但しユーザがアルゴリズム的処理を基礎として手動で発注すること、または自動的に行われた注文を操作することを可能にするユーザインタフェースを提供する取引アプリケーションを含んでもよい。アルゴリズム取引アプリケーションは、所定のアクションを実行するために自動的に処理されるアルゴリズムを含む取引アプリケーションである。即ち、取引アプリケーションは、定義されたアクションを実行するための自動化された一連の命令を含む。アクションは、例えば、市場データを特定の方法で処理すること、発注すること、既存の注文を修正すること、注文を削除すること、発注を控えること、どの取引可能オブジェクトに作用するかを選択すること、発注価格または修正注文価格を決定すること、発注する数量または注文を修正する数量を決定すること、注文が買い注文であるべきか、売り注文であるべきかを決定すること、およびアクションを一定期間遅らせることを含んでもよい。
【００４６】
本明細書において、アルゴリズム（取引アルゴリズムとも称される）は、取引に使用されるべきアルゴリズムを記述する論理式およびパラメータを含む定義によって指定される。論理式はパラメータ間の関係を指定し、かつさらなるパラメータを生成する場合がある。パラメータには、例えば、アルゴリズムの論理式への入力が含まれてもよい。アルゴリズムの定義は、アルゴリズム取引アプリケーションによって少なくとも部分的に指定されてもよい。例えば、アルゴリズム取引アプリケーションは、ユーザが使用されるべきパラメータを予め定義された論理式によってのみ指定できるようにしてもよい。別の例として、アルゴリズム取引アプリケーションは、ユーザが論理式の幾分か、または全て、およびパラメータの幾分か、または全てを指定できるようにしてもよい。論理式がユーザによって指定される取引アルゴリズムは、ユーザ定義取引アルゴリズムである。
【００４７】
所定の実施形態において、クライアントデバイス１１０からの注文はゲートウェイ１２０を介して取引所１３０へ送信される。クライアントデバイス１１０はゲートウェイ１２０と、例えばローカル・エリア・ネットワーク、広域ネットワーク、仮想専用ネットワーク、Ｔｌ回線、Ｔ３回線、ＩＳＤＮ回線、ポイント・オブ・プレゼンスおよび／またはインターネットを用いて通信してもよい。
【００４８】
ゲートウェイ１２０は、クライアントデバイス１１０および取引所１３０と通信するように適合化される。ゲートウェイ１２０は、クライアントデバイス１１０と取引所１３０との間の通信を容易にする。例えば、ゲートウェイ１２０は、クライアントデバイス１１０から注文を受信しかつこの注文を取引所１３０へ送信してもよい。別の例として、ゲートウェイ１２０は、取引所１３０から市場データを受信しかつこの市場データをクライアントデバイス１１０へ送信してもよい。
【００４９】
所定の実施形態において、ゲートウェイ１２０は、クライアントデバイス１１０と取引所１３０との間で通信されるデータの処理を実行する。例えば、ゲートウェイ１２０は、クライアントデバイス１１０から受信される注文を取引所１３０によって受容可能なデータフォーマットへと処理してもよい。同様に、ゲートウェイ１２０は、取引所１３０から受信される取引所固有フォーマットの市場データをクライアントデバイス１１０によって理解されるフォーマットへ変換してもよい。また、ゲートウェイ１２０による処理は、例えば、クライアントデバイス１１０からの注文を追跡し、かつ取引所１３０から受信される約定確認を基礎として注文の状況を更新することを含んでもよい。別の例として、ゲートウェイ１２０は取引所１３０からの市場データを融合し、かつこれをクライアントデバイス１２０へ提供してもよい。
【００５０】
所定の実施形態において、ゲートウェイ１２０は、クライアントデバイス１１０と取引所１３０との間で通信されるデータの処理以外のサービスを提供する。例えば、ゲートウェイ１２０はリスク処理を提供してもよい。
【００５１】
ゲートウェイ１２０には、例えば、携帯デバイス、ラップトップ、デスクトップコンピュータ、シングルまたはマルチ・コア・プロセッサを有するワークステーション、複数のプロセッサを有するサーバおよび／またはコンピュータのクラスタ等の１つまたは複数の電子コンピューティングプラットフォームが含まれてもよい。
【００５２】
ゲートウェイ１２０は、１つまたは複数のゲートウェイアプリケーションを含んでもよい。ゲートウェイアプリケーションは、例えば、注文の処理および市場データの処理を扱ってもよい。この処理は、例えば、ユーザの選好を基礎とするものであってもよい。
【００５３】
所定の実施形態において、ゲートウェイ１２０は取引所１３０と、例えばローカル・エリア・ネットワーク、広域ネットワーク、仮想専用ネットワーク、Ｔｌ回線、Ｔ３回線、ＩＳＤＮ回線、ポイント・オブ・プレゼンスおよび／またはインターネットを用いて通信してもよい。
【００５４】
概して、取引所１３０は、取引エンティティにより所有され、操作され、制御され、または使用されてもよい。例示的な取引エンティティには、ＣＭＥグループ、ロンドン国際金融先物オプション取引所（「ＬＩＦＦＥ」）、インターコンチネンタルエクスチェンジ（「ＩＣＥ」）およびユーレックスが含まれる。取引所１３０は、コンピュータ、サーバまたは、例えば取引所による取引用に提供される取引可能オブジェクトを買う、または売ることができるように適合化された他のコンピューティングデバイス等の電子マッチングシステムであってもよい。
【００５５】
取引所１３０は、取引可能オブジェクトの買い注文と売り注文とを整合させるように適合化される。取引可能オブジェクトは、取引所１３０による取引用にリストされてもよい。注文には、例えば、クライアントデバイス１１０から受信される注文が含まれてもよい。注文は、例えば、クライアントデバイス１１０からゲートウェイ１２０を介して受信されてもよい。さらに、注文は、取引所１３０と通信する他のデバイスから受信されてもよい。即ち、典型的には、取引所１３０は、同じく整合されるべき注文を提供する様々な他のクライアントデバイス（クライアントデバイス１１０に類似するものであってもよい）と通信し合う。
【００５６】
取引所１３０は、市場データを提供するように適合化される。市場データは、例えば、クライアントデバイス１１０へ提供されてもよい。市場データはクライアントデバイス１１０へ、例えばゲートウェイ１２０を介して提供されてもよい。市場データは、例えば、場内市場を表すデータを含んでもよい。場内市場は、ある特定の時点における一番安い売り値（「一番安い指値価格」とも称される）および一番高い買い値（「一番高い指値価格」とも称される）である。市場データは、市場の深さも含む場合がある。市場の深さは、場内市場における入手可能な量を指し、かつ場内市場以外での他の価格で入手可能な量も指す場合がある。したがって、場内市場は、第１の市場の深さレベルとされてもよい。場内市場以外での１ティックは、例えば、第２の市場の深さレベルとされてもよい。所定の実施形態において、市場の深さは、全ての価格レベルに関して規定される。所定の実施形態において、市場の深さは、全ての価格レベルに関して規定されるわけではない。例えば、市場の深さは、場内市場の内外で最初の５つの価格レベルに関してのみ規定されてもよい。また、市場の深さは、最終取引価格（ＬＴＰ）、最終取引数量（ＬＴＱ）および注文約定情報等の情報も含む場合がある。
【００５７】
所定の実施形態において、システム１００は、２つ以上のクライアントデバイス１１０を含む。例えば、先に論じたクライアントデバイス１１０に類似する複数のクライアントデバイスが、取引所１３０へ注文を送信するためにゲートウェイ１２０と通信していてもよい。
【００５８】
所定の実施形態において、システム１００は、２つ以上のゲートウェイ１２０を含む。例えば、先に論じたゲートウェイ１２０に類似する複数のゲートウェイが、クライアントデバイス１１０および取引所１３０と通信していてもよい。このような配置は、例えば、ゲートウェイ１２０が故障した場合に冗長性を与えるために用いられてもよい。
【００５９】
所定の実施形態において、システム１００は、２つ以上の取引所１３０を含む。例えば、ゲートウェイ１２０は、先に論じた取引所１３０に類似する複数の取引所と通信していてもよい。このような配置は、例えば、クライアントデバイス１１０が２つ以上の取引所でゲートウェイ１２０を介して取引できるようにしてもよい。
【００６０】
所定の実施形態において、システム１００は、２つ以上の取引所１３０および２つ以上のゲートウェイ１２０を含む。例えば、先に論じたゲートウェイ１２０に類似する複数のゲートウェイは、先に論じた取引所１３０に類似する複数の取引所と通信していてもよい。各ゲートウェイは、例えば１つまたは複数の異なる取引所と通信していてもよい。このような配置は、例えば、１つまたは複数のクライアントデバイス１１０が２つ以上の取引所で取引できるように（かつ／または、複数の取引所へ冗長な接続を提供できるように）してもよい。
【００６１】
所定の実施形態において、クライアントデバイス１１０は、１つまたは複数のコンピューティングデバイスまたは処理コンポーネントを含む。言い替えれば、クライアントデバイス１１０の機能は、２つ以上のコンピューティングデバイスによって実行されてもよい。例えば、１つのコンピューティングデバイスは、取引所１３０へ送信されるべき注文を生成してもよく、一方で別のコンピューティングデバイスはトレーダへグラフィカル・ユーザ・インタフェースを提供してもよい。所定の実施形態において、ゲートウェイ１２０は、１つまたは複数のコンピューティングデバイスまたは処理コンポーネントを含む。言い替えれば、ゲートウェイ１２０の機能は、２つ以上のコンピューティングデバイスによって実行されてもよい。所定の実施形態において、取引所１３０は、１つまたは複数のコンピューティングデバイスまたは処理コンポーネントを含む。言い替えれば、取引所１３０の機能は、２つ以上のコンピューティングデバイスによって実行されてもよい。
【００６２】
所定の実施形態において、ゲートウェイ１２０はクライアントデバイス１１０の一部である。例えば、ゲートウェイ１２０のコンポーネントは、クライアントデバイス１１０と同じコンピューティングプラットフォームの一部であってもよい。別の例として、ゲートウェイ１２０の機能は、クライアントデバイス１１０のコンポーネントによって実行されてもよい。所定の実施形態では、ゲートウェイ１２０が存在しない。このような配置は、例えば、クライアントデバイス１１０が取引所１３０との通信にゲートウェイ１２０を利用する必要がない場合、例えば、クライアントデバイス１１０が取引所１３０と直に通信するように適合化されている場合、に発生することがある。
【００６３】
所定の実施形態において、ゲートウェイ１２０は、物理的にクライアントデバイス１１０と同じ場所に位置決めされる。所定の実施形態において、ゲートウェイ１２０は、物理的に取引所１３０と同じ場所に位置決めされる。所定の実施形態において、クライアントデバイス１１０は、物理的に取引所１３０と同じ場所に位置決めされる。所定の実施形態において、ゲートウェイ１２０は、物理的にクライアントデバイス１１０および取引所１３０の双方から分離された場所に位置決めされる。
【００６４】
明瞭さを期して図示されていないが、所定の実施形態において、システム１００は他に、ミドルウェア、ファイアウォール、ハブ、スイッチ、ルータ、取引所固有の通信機器、モデム、セキュリティマネージャおよび／または暗号化／復号化デバイス等の通信アーキテクチャ固有のデバイスを含んでもよい。
【００６５】
先に論じたシステム１００のコンポーネント、エレメントおよび／または機能は、単独または組み合わせて、例えばハードウェア、ファームウェアおよび／またはソフトウェアにおける命令セットとしての様々な形式で実装されてもよい。所定の実施形態は、汎用コンピュータまたは他の処理デバイスで実行されるために、メモリ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤ、ＥＰＲＯＭおよび／またはファイルサーバ等のコンピュータ読取り可能媒体に存在する命令セットとして提供されてもよい。
ＩＩ．  アルゴリズム注文ビルダ
【００６６】
所定の実施形態は、ビルディング・ブロック・ボタンおよびアルゴリズムを定義するアルゴリズムエリアを提供する。所定の実施形態は、単一の取引セッションの間であってもアルゴリズムのパラメータおよび論理の双方を迅速に調整することを見込んでいる。所定の実施形態は、アルゴリズムが定義されるにつれて式のライブ評価を提供する。所定の実施形態は、構文エラー、不明瞭な論理およびトレーダでないプログラマがトレーダにより指定される通りにアルゴリズムを開発する必要性等の伝統的にプログラムされるアルゴリズムのリスクを、ユーザによるプログラミングコードの書込みを減らす、またはなくすことによって低減する。所定の実施形態は、アルゴリズムの構築、デバッグおよび（実際の市場データを用いる）シミュレーションを全て同時に行うための単一のアプリケーションを提供する。さらに、この単一のアプリケーションは、アルゴリズムを用いる発注の開始にも備える場合がある。
【００６７】
図２Ａは、所定の実施形態による取引インタフェース２００を示す。取引インタフェース２００は、アルゴリズム注文ビルダ（「ＡＯＢ」）と称されるアルゴリズム取引アプリケーションのための取引インタフェースである。ＡＯＢは、トレーダが、行われるべき注文のためのアルゴリズムを生成できるようにする。しかしながら、図示されている取引インタフェース２００のエレメントが他の取引インタフェースに組み込まれてもよいことは理解されるべきである。
【００６８】
取引インタフェース２００は、インスツルメント選択ボタン２０１と、市場格子２０２と、シミュレートされた参考注文の入力エリア２０３と、オートヘッジ・オプション２０４と、スクラッチ量２０５と、変数エリア２０６と、アルゴリズムエリア２１０と、ビルディング・ブロック・ボタン２１５とを含む。アルゴリズムエリア２１０は、価格エリア２１１と、数量エリア２１２と、条件付きエリア２１３とを含む。
【００６９】
動作中は、１つまたは複数のビルディング・ブロック・ボタン２１５を利用して価格エリア２１１、数量エリア２１２および／または条件付きエリア２１３に式を構築することにより、アルゴリズムエリア２１０においてアルゴリズムが定義される。アルゴリズムにおけるユーザ定義変数のデフォルト値は、変数エリア２０６を用いて指定されてもよい。アルゴリズムが定義されると、式の論理がどのように行動するかを表示するために、シミュレートされた参考注文の入力エリア２０３が使用されてもよい。次には、取引インタフェースを用いて、定義されたアルゴリズムに従って管理されるべき注文が開始されてもよい。
【００７０】
インスツルメント選択ボタン２０１は、行われるべき注文が関連するインスツルメント（即ち、取引可能オブジェクト）の選択を準備する。図２Ａに示されているように、インスツルメント選択ボタン２０１は、選択されたインスツルメントの名称がインスツルメント選択ボタン２０１に表示されているように、既にＧＥＨ１−ＧＥＭ１カレンダースプレッドを選択すべく使用されている。インスツルメントがまだ選択されていなければ、インスツルメント選択ボタン２０１は「インスツルメントを選択」と表示するか、インスツルメントがまだ選択されていない旨の他の何らかの表示を与える場合がある。
【００７１】
（例えば、ポインタを用いて選択すること、またはタッチスクリーンに接触することによって）インスツルメント選択ボタン２０１が起動されると、インスツルメントを選択できるようにするインスツルメント選択インタフェースが表示されてもよい。
【００７２】
図２Ｂは、所定の実施形態によるインスツルメント選択インタフェース２２０を示す。インスツルメント選択インタフェース２２０は取引可能な商品のリストを表示し、かつインスツルメントツリーを辿ることによって取引されるべき特定の取引可能オブジェクトをユーザが指定できるようにする。インスツルメントツリーは、ユーザが、例えばインスツルメント、インスツルメントのタイプ（例えば、スプレッドまたは先物）および表示されるべき特定の契約を選ぶことができるようにする。例えば、図示されているように、ＧＥＨ１−ＧＥＭ１カレンダースプレッドが選択されている。
【００７３】
再度、図２Ａを参照すると、市場格子２０２は、ある取引可能オブジェクトの市場情報を表示する。取引可能オブジェクトは、例えば、インスツルメント選択ボタン２０１で選択されたインスツルメントであってもよい。別の例として、取引可能オブジェクトはユーザが選択する別の取引可能オブジェクトであってもよい。市場格子２０２は、例えば、取引可能オブジェクトの買いおよび／または売り呼び値、買いおよび／または売り数量、最終取引価格および／または数量情報を表示してもよい。例えば、市場格子２０２は、選択されたインスツルメントの場内市場価格および数量を表示してもよい。
【００７４】
シミュレートされた参考注文の入力エリア２０３は、アルゴリズムエリア２１０において定義されるアルゴリズムの運用面を評価するためのフィードバックの生成に備える。ユーザは、式の論理がどのように行動するかを表示するために、シミュレートされた参考注文の入力エリア２０３を用いて選択されたインスツルメントの売り買いを仮想注文するシミュレーションを行ってもよい。同じくシミュレートされた参考注文の入力エリア２０３を用いて、仮想注文の価格および／または数量も指定される場合がある。さらに、所定の実施形態において、シミュレートされた参考注文の入力エリア２０３は、注文が定義されたアルゴリズムに従って管理される場合に、選択されたインスツルメントを売り買いする実際の注文の実行を（例えば、チェックボックスを選択することによって）開始するように設定されてもよい。
【００７５】
オートヘッジ・オプション２０４は、開始された注文が約定されると反対注文が行われる旨を指定することに備える。反対注文は、約定された注文が買い注文であれば売り注文であり、かつ約定された注文が売り注文であれば買い注文である。反対注文の量は、例えば約定された数量と同じであってもよい。反対注文は、まず、例えば約定された注文の価格から取引可能な１増分（取引所が規定するもの）等の利益のある出口価格で行われる。例えば、約定された注文が数量１０を価格１００で買ったとすれば、反対注文は、数量１０を価格１０１で売る注文であってもよい。別の例として、約定された注文が数量５を価格１００で売ったとすれば、反対注文は、数量５を価格９９で買う注文であってもよい。
【００７６】
スクラッチ量２０５は、オートヘッジ・オプション２０４によって用いられる。市場における反対注文の価格レベルでの数量が指定されたスクラッチ量２０５より下がると、反対注文の価格レベルは、対応する約定された注文の価格になるように変更される。この場合、約定された注文は「スクラッチされた」と言われ、その取引に利益はない。所定の実施形態において、反対注文は、損益に関わりなくポジションを閉じる価格で出されてもよい。
【００７７】
変数エリア２０６は、アルゴリズムエリア２１０で使用されるユーザ定義変数を指定しかつ修正することに備える。変数エリア２０６は、各変数の名称およびその値を表示する。変数エリアは、変数の名称および／またはその値を変更するために選択されてもよい。
変数は、アルゴリズムのパラメータと称される場合もある。
【００７８】
アルゴリズムエリア２１０は、注文を管理するためのアルゴリズムを定義することに備える。アルゴリズムエリア２１０は、価格エリア２１１と、数量エリア２１２と、条件付きエリア２１３とを含む。各エリアは、アルゴリズムの異なる態様に対応する。
【００７９】
ビルディング・ブロック・ボタン２１５は、アルゴリズムを定義すべくアルゴリズムエリア２１０において式を構築するために使用される。式は、アルゴリズムエリア２１０の各エリアの値を決定するために評価される。式は、ビルディング・ブロック・ボタン２１５によって指定される１つまたは複数の要素を含む。以下、ビルディング・ブロック・ボタン２１５の使用についてさらに詳しく述べる。
【００８０】
アルゴリズムエリア２１０においてアルゴリズムが定義されると、取引インタフェースによって買い注文または売り注文が開始されてもよい。例えば、仮想注文の開始に備えることに加えて、所定の実施形態では、シミュレートされた参考注文の入力エリア２０３もまた実際の注文を開始することに備える場合がある。別の例として、後述するものに類似する取引インタフェースが注文の開始に使用されてもよい。すると、開始された注文は、定義されたアルゴリズムに従って管理される。
【００８１】
価格エリア２１１は、管理されている注文の発注価格を決定するために評価される。価格エリア２１１は、価格を表す数字を評価する。価格エリア２１１が空白であれば、シミュレートされた参考注文の入力エリア２０３で指定された価格が使用される。価格エリア２１１が式を含んでいれば、シミュレートされた参考注文の入力エリア２０３で指定されている価格は無視されてもよい。価格エリア２１１は、市場データが変わるとき等の異なる時間に異なる値を評価する場合がある。そうであれば、管理されている注文は新しい価格で受け付けられるように変更される。これは、例えば、注文を削除しかつ新しい価格で新しい注文を出すことによって、またはキャンセル／置換コマンドを用いることによって達成されてもよい。
【００８２】
数量エリア２１２は、管理されている注文の発注数量を決定するために評価される。数量エリア２１２は、数量を表す数字を評価する。数量エリア２１２が空白であれば、シミュレートされた参考注文の入力エリア２０３で指定された数量が使用される。数量エリア２１２が式を含んでいれば、シミュレートされた参考注文の入力エリア２０３で指定されている数量は無視されてもよい。数量エリア２１２は、市場データが変わるとき等の異なる時間に異なる値を評価する場合がある。そうであれば、管理されている注文は新しい数量で受け付けられるように変更される。これは、例えば、注文を削除しかつ新しい数量で新しい注文を出すことによって、または注文数量変更コマンドを用いることによって達成されてもよい。数量エリア２１２が０を評価するのであれば、管理されている注文は、数量エリア２１２が非ゼロ値を評価するまで市場から取り除かれてもよい。これは、後述するように、条件付きエリア２１３が「偽」を評価することに類似する場合がある。
【００８３】
所定の実施形態では、アルゴリズムエリア２１０は数量エリア２１２を含まない。代わりに、数量は一定であるか、予め定義されている場合がある。例えば、ヘッジ注文を管理するための取引インタフェース（ヘッジ注文は、例えば取引戦略の取引可能オブジェクトのための別の注文が約定されると自動的に出される注文であり、これは、ヘッジ・マネージャ・インタフェースとも呼ばれることがある）は、他の注文の約定された数量を基礎とする、従ってアルゴリズムの観点から予め決められている数量を用いる場合がある。したがって、ヘッジ注文を機能させるためにアルゴリズムを使用できるようにする場合のあるこのような取引インタフェースにおけるアルゴリズムエリアは、数量値はアルゴリズムが利用される時点で予め決められることから指定する必要がないという理由で数量エリア２１２を含まなくてもよい。
【００８４】
条件付きエリア２１３は、そのアルゴリズムが機能すべきものであるかどうかを決定するために評価される。条件付きエリア２１３は、ブール値を評価する。条件付きエリア２１３が「真」と評価すれば、そのアルゴリズムは機能している。条件付きエリア２１３が「偽」と評価すれば、そのアルゴリズムは機能していない。条件付きエリア２１３が空白であれば、アルゴリズムは常時機能している。条件付きエリア２１３は、市場データが変わるとき等の異なる時間に異なる値を評価する場合がある。アルゴリズムが機能している場合、管理されている注文は市場へ入力され、かつ先に論じたように、決定された価格および数量によって機能される。アルゴリズムが機能していない場合、管理されている注文は市場から除去される。これは、例えば、注文を削除することによって達成されてもよい。
【００８５】
所定の実施形態では、アルゴリズムエリア２１０は条件付きエリア２１３を含まない。代わりに、アルゴリズムは、一旦注文が開始されると単に常時「機能して」いてもよい。例えば、ヘッジ・マネージャ・インタフェースにおいては、ヘッジ注文は可能な限り迅速に約定されることが望まれ得ることから、ヘッジ注文を管理するアルゴリズムは常時機能している場合がある。
【００８６】
価格エリア２１１、数量エリア２１２および／または条件付きエリア２１３における式が評価する値が適切なタイプ（価格エリア２１１、注文数量エリア２１２の場合は数字、条件付きエリア２１３の場合はブール値）でなければ、その式は無効である。式が無効であることを表示するために、特定エリアの背景は緑（有効な式を示す）から赤（無効な式を示す）へ変更されてもよい。アルゴリズムエリア２１０のエリアのうちの１つで式が無効であれば、注文を出すことはできない。
【００８７】
所定の実施形態では、背景色の他に（またはこれに加えて）他のインジケータが、アルゴリズムエリア２１０のエリア内の式が無効であることを表示するために用いられてもよい。例えば、異なる背景パターン、異なる境界色またはスタイル、「準備完了」または「無効」等のテキストメッセージおよび／または感嘆符のアイコンが用いられてもよい。
【００８８】
アルゴリズムに従って管理されている注文が約定されれば、先に論じたように、オートヘッジ・オプション２０４およびスクラッチ量２０５を基礎として反対注文が自動的に出されてもよい。
【００８９】
先に論じたように、ビルディング・ブロック・ボタン２１５は、アルゴリズムを定義すべくアルゴリズムエリア２１０において式を構築するために使用される。ビルディング・ブロック・ボタン２１５は、例えば、アイコン、可動アイコン、アイコンボタン、可動ボタンまたはユーザ・インタフェース・エレメントとも称される場合がある。式は要素（論理式およびパラメータ）を含み、かつアルゴリズムエリア２１０の各エリアの値を決定するために評価される。ビルディング・ブロック・ボタン２１５は、式を構築するために選択されてアルゴリズムエリア２１０の特定のエリアに配置されてもよい。例えば、ユーザは、１つまたは複数のビルディング・ブロック・ボタン２１５を、価格エリア２１１、数量エリア２１２および／または条件付きエリア２１３等のアルゴリズムエリア２１０のエリアのうちの１つまたはそれ以上へドラッグアンドドロップしてもよい。別の例として、ユーザはビルディング・ブロック・ボタン２１５を、例えばそれをクリックすることによって選択してもよく、選択されたボタン２１５は次に、最近に使用されたアルゴリズムエリア２１０に配置されてもよい。ビルディング・ブロック・ボタン２１５をアルゴリズムエリア２１０に配置すると、アルゴリズムエリア２１０内に構築されている式内に要素が配置される。後述するように、式内の所定の要素は、例えば部分式として作用する追加的な要素を含んでもよい。
【００９０】
ビルディング・ブロック・ボタン２１５のタイプには、インスツルメント、定数、算術演算子、論理演算子、演算子の優先順位、ｉｆ−ｔｈｅｎ−ｅｌｓｅ構成および変数が含まれる。インスツルメントのビルディング・ブロック・ボタンは、選択されたインスツルメントの、例えば買い呼び値および売り数量等の属性を指定する。定値のビルディング・ブロック・ボタンは、例えば、一定の数値およびブール値を指定する。算術演算子のビルディング・ブロック・ボタンは、加算（「＋」）、減算（「−」）、乗算（「＊」）および除算（「／」）等の算術演算を含む。さらに、算術演算子のビルディング・ブロック・ボタンは、（「＋／−」）等の注文側固有の算術演算を含んでもよく、これは、買い注文に関しては加算でありかつ売り注文に関しては減算である（または、ユーザが指定するように、売り注文に対しては加算でありかつ買い注文に関しては減算である）。論理演算子のビルディング・ブロック・ボタンは、例えば、ＡＮＤ、ＯＲおよびＮＯＴ等の論理演算、および、大なり（「＞」）、小なり（「＜」）、以上（「＞＝」）、以下（「＜＝」）および等号（「＝」）等の比較を含む。さらに、論理演算子のビルディング・ブロック・ボタンは、「＞／＜」等の注文側固有の論理演算を含んでもよく、これは、買い注文に関しては大なりでありかつ売り注文に関しては小なりである（または、ユーザが指定するように、売り注文に対しては大なりでありかつ買い注文に関しては小なりである）。演算子の優先順位のビルディング・ブロック・ボタンは、括弧（「（」および「）」）を含む。所定の実施形態において、演算子の優先順位のビルディング・ブロック・ボタンは、括弧内の要素から成る部分式を形成するために用いられてもよい。ｉｆ−ｔｈｅｎ−ｅｌｓｅ構成のビルディング・ブロック・ボタンは、例えば、条件付きの値を指定することを見込んでいる。ｉｆ−ｔｈｅｎ−ｅｌｓｅ構成のビルディング・ブロック・ボタンは、部分式が１つまたは複数の要素を用いて構築され得る部分を提供する。変数のビルディング・ブロック・ボタンは、例えば、先に論じたように、変数エリア２０６を用いてその値を変更している場合があるユーザ定義変数を指定する。
【００９１】
図２Ｃ−図２Ｉは、所定の実施形態による、取引インタフェース２００でのアルゴリズム定義の構築を示す。
【００９２】
図２Ｃに示されているように、インスツルメントのビルディング・ブロック・ボタン２３１が選択され、価格エリア２１１にインスツルメントのビルディングブロック２３２として配置されている。インスツルメントのビルディングブロック２３２は、選択されたインスツルメントのどの属性が使用されるべきかをユーザがリスト２３３から選択できるようにする。インスツルメントの買い呼び値は、既に選択されている。したがって、（インスツルメントの買い呼び値として指定された）インスツルメントのビルディングブロック２３２を含む価格エリア２１１は、市場における瞬間的なインスツルメントの買い呼び値を評価する。
【００９３】
選択されたインスツルメントの属性の例には、買い呼び値、売り呼び値、買い数量、売り数量、最終取引価格、最終取引数量、出来高、取引セッション高値、取引セッション安値、非黙示の売／買数量（実際の売／買数量とも称される）、精算値、取引可能な最小増分（ティックサイズとも称される）およびある価格における待ち行列内の注文数（ヘッドカウントとも称される）が含まれる。さらに、例えば、「買い呼び値＊」、「売り呼び値＊」、「買い数量＊」および「売り数量＊」等の特別な注文側固有の属性も指定される場合がある（不図示）。これらの特別な属性に関して、指定された値は買い注文に使用され、かつ指定された値の反対の値は売り注文に使用される。例えば、「売り呼び値＊」が選択されれば、式は買い注文の売り呼び値および売り注文の買い呼び値を評価する。
【００９４】
図２Ｄに示されているように、減算算術演算子のビルディング・ブロック・ボタン２４１が選択され、価格エリア２１１に減算のビルディングブロック２４２として配置されている。これで、価格エリア２１１内の式は、インスツルメントのビルディングブロック２３２と減算のビルディングブロック２４２とを含む。
【００９５】
しかしながら、価格エリア２１１内の式はこの時点で無効であり、よって評価はされ得ない（「買い呼び値、−」は、構文的に意味がない）。これは、先に論じたように、無効であるエリアタイプと同様に扱われてもよい。即ち、価格エリア２１１内の式が無効であることから、価格エリア２１１の背景は緑（有効な式を示す）から赤（無効な式を示す）へ変更される。
【００９６】
図２Ｅに示されているように、定数値のビルディング・ブロック・ボタン２５１が選択され、価格エリア２１１に定値のビルディングブロック２５２として配置されている。ユーザは、定値のビルディングブロック２５２が値「０．５」を有するべきであることを指定している。価格エリア２１１内の式は、これで再び有効となり（背景が赤から緑に変わっていることに注意）、マイナス０．５のインスツルメントの瞬間的買い呼び値を評価する。
【００９７】
図２Ｆに示されているように、ｉｆ−ｔｈｅｎ−ｅｌｓｅ構成のビルディング・ブロック・ボタン２６１が選択され、数量エリア２１２にｉｆ−ｔｈｅｎ−ｅｌｓｅ構成のビルディングブロック２６２として配置されている。ｉｆ−ｔｈｅｎ−ｅｌｓｅ構成のビルディングブロック２６２は、ＩＦ部分２６３と、ＴＨＥＮ部分２６４と、ＥＬＳＥ部分２６５とを含む。１つまたは複数の要素（ネスト化されたｉｆ−ｔｈｅｎ−ｅｌｓｅ構成のビルディングブロックを含む）の部分式は、ｉｆ−ｔｈｅｎ−ｅｌｓｅ構成のビルディングブロック２６２の各部分において構築されてもよい。ｉｆ−ｔｈｅｎ−ｅｌｓｅ構成のビルディングブロック２６２が評価される場合、その値は次のように決定される。ＩＦ部分２６３が、ブール値を決定するために評価される。ＩＦ部分２６３からの決定されたブール値が「真」を評価すると、ｉｆ−ｔｈｅｎ−ｅｌｓｅ構成のビルディングブロック２６２はＴＨＥＮ部分２６４における式の値を評価する。ＩＦ部分２６３からの決定されたブール値が「偽」を評価すると、ｉｆ−ｔｈｅｎ−ｅｌｓｅ構成のビルディングブロック２６２はＥＬＳＥ部分２６５における式の値を評価する。
【００９８】
ビルディング・ブロック・ボタン２１５は、ｉｆ−ｔｈｅｎ−ｅｌｓｅ構成のビルディングブロック２６２の部分において式を構築するためにも用いられる。図示されているように、ＩＦ部分２６３は、インスツルメントの買い数量が何かより多いかどうかを決定する比較を行うために部分的に構築された式を含む。しかしながら、この式は、構文的に意味を成さないことから無効である。必然的に、これを表示するために、ＩＦ部分２６３の背景は赤であって緑ではないことに留意されたい。さらに、ｉｆ−ｔｈｅｎ−ｅｌｓｅ構成のビルディングブロック２６２は有効でなく（そのＩＦ部分２６３が有効でないため）、数量エリア２１２内の式は有効でなく、よってこれも赤の背景を有する。
【００９９】
図２Ｇに示されているように、ｉｆ−ｔｈｅｎ−ｅｌｓｅ構成のビルディングブロック２６２は既にその部分の各々において有効な式を含み、よって、数量エリア２１２の式も有効である。
【０１００】
図２Ｈに示されているように、ｉｆ−ｔｈｅｎ−ｅｌｓｅ構成のビルディングブロックはネスト化されてもよい。ｉｆ−ｔｈｅｎ−ｅｌｓｅ構成のビルディングブロック２６２のＥＬＳＥ部分２６５は、別のｉｆ−ｔｈｅｎ−ｅｌｓｅ構成のビルディングブロック２６６を含む。図示されているように、ｉｆ−ｔｈｅｎ−ｅｌｓｅ構成のビルディングブロック２６６は、その部分の何れにおいても式を含んでいないことから評価されることができず、よって、ｉｆ−ｔｈｅｎ−ｅｌｓｅ構成のビルディングブロック２６２のＥＬＳＥ部分２６５において無効な式である。必然的に、ＥＬＳＥ部分２６５は、その式が無効であることを表示する赤い背景を有する。さらに、ＥＬＳＥ部分２６５は無効な式を有することから、ｉｆ−ｔｈｅｎ−ｅｌｓｅ構成のビルディングブロック２６２は有効な式を持たず、よって数量エリア２１２の背景は赤である。
【０１０１】
図２Ｉに示されているように、ｉｆ−ｔｈｅｎ−ｅｌｓｅ構成のビルディングブロック２６２のＩＦ部分２６３における式は、変数のビルディングブロック２７３、２７４、２７５および２７６を含む。変数のビルディングブロック２７３、２７４、２７５および２７６は、変数のビルディング・ブロック・ボタンを用いることによって、または定値のビルディング・ブロック・ボタンを用いる際に定値が変数でなければならないことを表示するオプションを選択することによって配置されてもよい。変数のビルディングブロック２７３は、変数の名称（「Ｍ＿ＴＨ＿１」）およびその値（「５０００」）を表示している。これは、例えば、最小しきい値を表してもよい。先に論じたように、変数エリア２０６は各変数名およびその値を表示する。図示されているように、変数エリア２０６は、変数のビルディングブロック２７３、２７４、２７５および２７６毎に入力を有する名前カラム２７１と、変数毎に対応するデフォルト値の入力を有するデフォルト値カラム２７２とを含む。ユーザは、デフォルト値カラム２７２内のデフォルト値入力を選択して個々の変数ビルディングブロックのデフォルト値を変えることができ、よって、数量エリア２１２における式の評価ではその新しいデフォルト値が使用される。同様に、ユーザは、名前カラム２７１内の名前入力を選択して個々の変数ビルディングブロックの名前を変えることができる。変数のビルディングブロック２７３、２７４、２７５および２７６は、例えば、ユーザがアルゴリズムのパラメータとして作用する変数の値を変えることによって、根本的な論理ではなくアルゴリズムの行動を操作できるようにしてもよい。
【０１０２】
取引インタフェース２００は、ライブ評価機能を提供する。ライブ評価機能は、図２Ｃ−図２Ｉに示されているように、ある式の評価値の表示を提供する。ライブ評価値は、例えば、定義されているアルゴリズムとして提供されてもよい。ライブ評価値は、例えば、評価されている式に関連して表示されてもよい。評価は、式が変わる毎に、または式内のビルディングブロックの値が変わる毎に実行されてもよい。また、評価は周期的に、または絶えず実行される場合もある。所定の実施形態において、ライブ評価値は部分式に関して提供されてもよい。所定の実施形態において、ライブ評価値は、式の個々の要素に関して提供されてもよい。
【０１０３】
図２Ｃに示されているように、インスツルメントの買い呼び値は、先に論じたようにインスツルメントのビルディングブロック２３２の属性として選択されている。価格エリア２１１のライブ評価２８１は「８．５」を表示しているが、これは、そのインスツルメントのカレント買い呼び値である（市場格子２０２にも示されている）。図２Ｄに示されているように、価格エリア２１１内の式は先に論じたように無効であり、よって、式を評価できないという理由でライブ評価は表示されていない。図２Ｅに示されているように、価格エリア２１１のライブ評価２８２は「８」を表示しているが、これは、インスツルメントの買い呼び値（８．５）から定値（０．５）をマイナスしたものである。
【０１０４】
価格エリア２１１、数量エリア２１２および条件付きエリア２１３のライブ評価に加えて、これらのエリア内の式についてもライブ評価が実行されてもよい。例えば、図２Ｇに示されているように、ライブ評価は、ｉｆ−ｔｈｅｎ−ｅｌｓｅ構成のビルディングブロック２６２の各部分について、ならびに数量エリア２１２自体についても提供される。ＩＦ部分２６３のライブ評価２８３は、インスツルメントの買い数量（８６３）が６０以上であることから「真」である。ＴＨＥＮ部分２６４のライブ評価２８４は、ＴＨＥＮ部分２６４内の式が単に定値２であることから２である。同様に、ＥＬＳＥ部分２６５のライブ評価２８５は、ＥＬＳＥ部分２６５内の式が単に定値１であることから１である。よって、数量エリア２１２のライブ評価２８６は「２」となるが、これは、ＩＦ部分２６３の評価が「真」であることからｉｆ−ｔｈｅｎ−ｅｌｓｅ構成のビルディングブロック２６２の評価がＴＨＥＮ部分２６４の値となるためである。
【０１０５】
取引インタフェース２００のビルディング・ブロック・ボタン２１５およびアルゴリズムエリア２１０は、トレーダまたは非プログラマ等のユーザがアルゴリズムの開発に要する時間およびリスクを減らすことを可能にする。これは、一部には、構文エラー（例えば、特定のプログラミング言語の複雑さに起因する）を減らす、またはなくすことによって、および構築されているアルゴリズムのライブ評価およびフィードバックを提供することによって（例えば、アルゴリズムが構築されている間にエラーをフラッグしかつ論理のデバッグを見込むことにより）達成される。
【０１０６】
アルゴリズムは、アルゴリズムエリア２１０において定義されると保存されてもよい。また、アルゴリズムには（例えば、アルゴリズムの構築中および／またはアルゴリズムが保存される際に）名前が与えられてもよい。よって、保存されたアルゴリズムは、後に取引インタフェース２００または別の取引インタフェースによって呼び出され、または参照されてもよい。例えば、保存されたアルゴリズムは、別の注文に関して編集または再使用され得るように取引インタフェース２００によってロードされてもよい。別の例として、保存されたアルゴリズムは、後述するように別の取引インタフェースから１つの注文タイプとして参照されてもよい。
【０１０７】
図２Ｊは、所定の実施形態による取引インタフェース２９０を示す。取引インタフェース２９０は、アルゴリズムがその注文用に特別に定義されている場合の、アルゴリズムによって管理される注文の開始に備えるように適合化された注文チケットである。
【０１０８】
取引インタフェース２９０は、アルゴリズムエリア２９９と、アルゴリズム注文ボタン２９４と、ビルディング・ブロック・ボタン２９５とを含む。アルゴリズムエリア２９９は、価格エリア２９１と、数量エリア２９２と、条件付きエリア２９３とを含む。価格エリア２９１は、先に論じた価格エリア２１１に類似する。数量エリア２９２は、先に論じた数量エリア２１２に類似する。条件付きエリア２９３は、先に論じた条件付きエリア２１３に類似する。ビルディング・ブロック・ボタン２９５は、先に論じたビルディング・ブロック・ボタン２１５に類似する。
【０１０９】
取引インタフェース２９０は、典型的な取引注文の実行を開始するために使用されてもよい。さらに、アルゴリズム注文ボタン２９４は、アルゴリズムエリア２９９を有効化するために選択されてもよい。有効化されると、アルゴリズム注文エリア２９９は、取引インタフェース２００に関して先に論じた方法と同様に価格エリア２９１、数量エリア２９２および条件付きエリア２９３を用いてアルゴリズムを定義することに備える。アルゴリズムは、アルゴリズムエリア２９９において定義されかつ開始されると、取引インタフェース２００に関して先に論じた方法と同様に、定義されたアルゴリズムに従って管理される。
【０１１０】
同様に、取引インタフェース２００および２９０におけるものに類似するアルゴリズムエリアおよびビルディング・ブロック・ボタンは、取引アプリケーションの他のコンポーネントに組み込まれる場合がある。例えば、ヘッジ・マネージャ・インタフェースは、アルゴリズムがヘッジ注文を管理するように定義されかつ指定され得るように、類似の機能を組み込むべく適合化されてもよい。
【０１１１】
先に論じた取引インタフェース２００および取引インタフェース２９０のコンポーネント、エレメントおよび／または機能は、単独または組み合わせて、例えばハードウェア、ファームウェアおよび／またはソフトウェアにおける命令セットとしての様々な形式で実装されてもよい。所定の実施形態は、汎用コンピュータまたは他の処理デバイスで実行されるために、メモリ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤ、ＥＰＲＯＭおよび／またはファイルサーバ等のコンピュータ読取り可能媒体に存在する命令セットとして提供されてもよい。
ＩＩＩ．  アルゴリズム設計ラボ
【０１１２】
所定の実施形態は、アルゴリズムを設計するための設計キャンバスエリアおよびブロックを提供する。所定の実施形態は、アルゴリズムで用いるための複雑な機能を有するブロックを提供する。所定の実施形態は、設計キャンバスエリア内に置かれる複数のブロックをグループ化することに備える。所定の実施形態は、アルゴリズムの一部の動的なインスタンス化が特定の不連続イベントを取り扱うことを可能にする仮想化されたグループブロックを準備する。所定の実施形態は、単一の取引セッションの間であってもアルゴリズムのパラメータおよび論理の双方を迅速に調整することを見込んでいる。所定の実施形態は、アルゴリズムが定義されるにつれてブロックのライブフィードバックを提供する。所定の実施形態は、アルゴリズムが設計される際の潜在的エラーを減らすための安全機能を提供する。所定の実施形態は、クライアントデバイスとアルゴリズムサーバとの接続が破断された場合のアルゴリズムの幾つかの部分または全ての部分の作動を準備する。所定の実施形態は、構文エラー、不明瞭な論理およびトレーダでないプログラマがトレーダにより指定される通りにアルゴリズムを開発する必要性等の伝統的にプログラムされるアルゴリズムのリスクを、ユーザによるプログラミングコードの書込みを減らす、またはなくすことによって低減する。所定の実施形態は、アルゴリズムの構築、デバッグおよび（実際の市場データを用いる）シミュレーションを全て同時に行うための単一のアプリケーションを提供する。さらに、この単一のアプリケーションは、アルゴリズムを用いる発注の開始にも備える場合がある。
【０１１３】
図３Ａは、所定の実施形態が使用され得る電子取引システム３００を示すブロック図である。システム３００は、１つまたは複数のクライアントデバイス３０１と、１つまたは複数のアルゴリズムサーバ３０２と、１つまたは複数の電子取引所３０３とを含む。各クライアントデバイス３０１は、１つまたは複数のアルゴリズムサーバ３０２と通信している。各アルゴリズムサーバ３０２は、１つまたは複数の取引所３０３と通信している。さらに、所定の実施形態では、図３Ａには示されていないが、クライアントデバイス３０１が１つまたは複数の取引所３０３と通信していてもよい。クライアントデバイス３０１および／またはアルゴリズムサーバ３０２による取引所との通信は、例えば、先に論じたゲートウェイ１２０に類似するゲートウェイを介して行われてもよい。
【０１１４】
クライアントデバイス３０１は、例えば、先に論じたクライアントデバイス１１０に類似するものであってもよい。所定の実施形態において、クライアントデバイス３０１はトレーダ端末と称される場合もある。取引所３０３は、例えば、先に論じた取引所１３０に類似するものであってもよい。
【０１１５】
所定の実施形態において、アルゴリズムサーバ３０２は、物理的に取引所３０３の近くへ、または取引所３０３に位置決めされる。所定の実施形態において、アルゴリズムサーバ３０２はクライアントデバイス３０１の一部である。
【０１１６】
動作に際して、電子取引のためのアルゴリズムは、クライアントデバイス３０１上に設計されてもよい。アルゴリズムは次に、アルゴリズムサーバ３０２へ伝達されてもよい。アルゴリズムサーバ３０２は、取引所３０３との電子取引を実行するためにアルゴリズムを実行する。市場データは、アルゴリズムによる使用のためにアルゴリズムサーバ３０２によって受信されてもよい。さらに、市場データは、アルゴリズムの設計に使用するためクライアントデバイス３０１によって受信されてもよい。市場データは、例えば取引所３０３から受信されてもよい。別の例として、市場データはシミュレータから、または格納された／履歴データから受信されてもよい。
【０１１７】
図３Ｂは、所定の実施形態による取引インタフェース３１０を示す。取引インタフェース３１０は、アルゴリズム設計ラボ（「ＡＤＬ」）と称されるアルゴリズム取引アプリケーションのための取引インタフェースである。ＡＤＬは、トレーダが電子取引のためのアルゴリズムを設計することを可能にする。しかしながら、図示されている取引インタフェース３１０のエレメントが他の取引インタフェースに組み込まれてもよいことは理解されるべきである。
【０１１８】
取引インタフェース３１０は、設計キャンバスエリア３１１と、ブロック・リスト・エリア３１２と、変数エリア３１３と、制御エリア３１４とを含む。所定の実施形態において、これらのエリアのうちの１つまたはそれ以上は別々のウィンドウ内またはツールバー内にあってもよい。例えば、ブロック・リスト・エリア３１２は、設計キャンバスエリア３１１とは分離されたウィンドウ内にあってもよい。
【０１１９】
動作中、アルゴリズムは、設計キャンバスエリア３１１において、ブロック・リスト・エリア３１２からの１つまたは複数のブロックを利用することにより定義される。アルゴリズムにおけるユーザ定義変数のデフォルト値は、変数エリア３１３を用いて指定されてもよい。アルゴリズムが定義されると、アルゴリズムは、制御エリア３１４内の制御を用いて、アルゴリズムの論理がどのように行動するかを示すようにシミュレートされてもよい。次には、取引インタフェースを用いて、定義されたアルゴリズムに従って管理されるべき注文が開始されてもよい。
【０１２０】
設計キャンバスエリア３１１は、アルゴリズムを定義することに備える。設計キャンバスエリア３１１は、ホワイトボードエリアとも称される場合がある。設計キャンバスエリア３１１は、アルゴリズムを設計するための視覚的なプログラミング環境を提供する。アルゴリズムの設計には、アルゴリズムを構築し、試験し、シミュレートしかつ／または評価することが含まれる。
【０１２１】
所定の実施形態において、設計キャンバスエリア３１１は取引アプリケーション３１０のためのインタフェースの主たる焦点であり、例えば大きな白い空間であってもよい。設計キャンバスエリア３１１では、ユーザの好みによってブロックが配列されてもよい。所定の実施形態において、設計キャンバスエリア３１１は、ブロックの配列に用いられてもよい格子線を提供する。所定の実施形態において、設計キャンバスエリア３１１は、多くのブロックを有する大規模アルゴリズムを介して誘導することに使用され得る総括表示またはマップを含む。所定の実施形態において、設計キャンバスエリア３１１は、ユーザがアルゴリズムを多少なりとも一度に見ることができるようにズームインまたはズームアウトされてもよい。
【０１２２】
設計キャンバスエリア３１１においてブロックは配置され、かつアルゴリズムを定義するために接続される。配置されるべきブロックは、ブロック・リスト・エリア３１２から選択されてもよい。ブロックは、配置されると、配置された他のブロックへ接続されてもよい。
【０１２３】
ブロック・リスト・エリア３１２は、選択されて設計キャンバスエリア３１１内に配置され得る１つまたは複数のブロックを含む。ブロックは、ユーザの好みによってアルゴリズムを構築するために組み合わされ得る異なる機能を表している。
【０１２４】
概して、ブロックは入力と出力とを有する。しかしながら、所定のブロックは入力だけを有する場合があり、かつ他のブロックは出力だけを有する場合がある。例えば、ポーズブロックは入力だけを有してもよい。別の例として、数字ブロックは出力だけを有してもよい。
【０１２５】
ブロックの入力および出力は、２つの主たるタイプ、即ち連続式または不連続式のうちの何れかである。連続タイプの入力／出力は、任意の特定の時刻において（故に、絶えず）値を有する。不連続タイプの入力／出力は、何らかの特別な時刻に発生する特有のアクション／イベントに対応して不連続のイベント（個々のメッセージ／オブジェクト）を受信／提供する。特有のアクション／イベントが発生すると、対応する不連続イベントが発生されてもよい。
【０１２６】
この主たるタイプの入力／出力に加えて、入力／出力は特別な値のタイプを有してもよい。例えば、連続式の入力は、ブール値、数値、整数値、浮動小数点数値またはインスツルメント値という値タイプを有する場合もある。別の例として、１つのブロックが２つの連続する変数値タイプの入力を有することがあり、この場合、２つの入力の値タイプは例えばブール値または数値であってもよいが、同一タイプでなければならない。２つの入力をとり、これらが等しいかどうかを表示するブール値を出力するために比較する等号ブロックは、例えばブール値または数値またはインスツルメント値を比較すべく使用され得るように変数入力を有してもよい。別の例として、不連続出力は、約定確認の値タイプを有する場合もある。即ち、不連続出力は、約定確認の不連続イベントを提供する場合もある。別の例として、不連続出力は、注文要求確認（注文が出されたことを表示する）、約定確認（注文が約定された、または部分的に約定されたことを表示する）、注文変更確認（価格または数量等の受付中の注文パラメータが変更されたことを表示する）、注文削除確認（受付中の注文が削除またはキャンセルされたことを表示する）または取引確認（取引が発生していることを表示する）等のアクションに関して、２つ以上のタイプの不連続イベントを提供する場合もある。別の例として、不連続イベントは、単にイベントが発生していることを示して空である場合もある。空の不連続イベントは、例えばタイマ、ブール値の変更によってトリガされてもよく、または、特定の時間（時刻または例えば所定の市場条件が満たされたとき等）にアルゴリズムの一部を起動するために用いられてもよい。ある特別なタイプの不連続イベントは、別のタイプの不連続イベントとは異なる情報を含んでもよい。例えば、注文確認は、注文識別子および／またはインスツルメント等の情報を含んでもよい。別の例として、約定確認の不連続イベントは、注文識別子、価格、数量、インスツルメントおよび／または約定時刻等の情報を含んでもよい。別の例として、注文削除確認は、注文識別子、インスツルメントおよび／または削除時刻を含んでもよい。別の例として、空の不連続イベントは如何なる情報も含まなくてもよい（または、イベントの発生時刻のみを含むことがある）。不連続イベントは、ユーザが定義する情報を含んでもよい。例えば、インスツルメントＡに関する約定された注文の約定確認の不連続イベントは、インスツルメントＡの約定時におけるインスツルメントＢの買い呼び値等のユーザが定義する市場情報を含んでもよい。
【０１２７】
所定の実施形態において、ブロックは、その入力／出力の主たるタイプのインジケータを含む。例えば、連続式の入力／出力は、特別な背景色、前景色、背景パターン、境界色、境界スタイル、形状、記号、数字、テキストおよび／またはフォントによって表示されてもよく、不連続式の入力／出力は、別の色、パターン、境界、形状、記号、数字、テキストおよび／またはフォントによって表示される場合もある。
【０１２８】
所定の実施形態において、ブロックは、その入力／出力の値タイプのインジケータを含む。例えば、特別な値タイプを有する入力／出力は、特別な背景色、前景色、背景パターン、境界色、境界スタイル、形状、記号、数字、テキストおよび／またはフォントによって表示されてもよく、異なる値タイプを有する入力／出力は、別の色、パターン、境界、形状、記号、数字、テキストおよび／またはフォントによって表示されてもよい。
【０１２９】
所定の実施形態では、カーソルがそのブロックの近くへ位置合わせされると、主たるタイプの、かつ／または値タイプの入力または出力がポップアップウィンドウに表示される。所定の実施形態では、カーソルがそのブロックの近くへ位置合わせされると、ブロックの設定に関する情報がポップアップ・ウィンドウに表示される。
【０１３０】
ブロックは、異なる機能を表現している。取引インタフェース３１０において、ブロックは４つの一般機能カテゴリ、即ち基本ブロック、取引ブロック、不連続ブロックおよびその他のブロックに分けられている。しかしながら、これらのグループ分けは編成およびユーザによる利用の便宜を図るためのものであって、ブロックはグループ化される必要はなく、ブロックのグループも特別な機能を必要としない。ブロックの中には、適宜２つ以上のカテゴリに当て嵌まるものもあり、またブロックの他の編成またはグルーピングが使用される場合もある。
【０１３１】
基本ブロックは、概して連続式の入力および出力を有し、かつ算術演算（例えば、加算、減算、乗算および除算）、論理演算（例えば、ＡＮＤ、ＯＲおよび等号、大なりおよび小なり等の比較）、定値（例えば、数値およびブール値）およびｉｆ−ｔｈｅｎ−ｅｌｓｅ構成を提供する。
【０１３２】
取引ブロックは、概して、注文操作（例えば、発注、既存の注文の修正または注文の削除）に関して、または注文関連情報（例えば、約定確認）に関して、より複雑な機能を提供する。取引ブロックは、連続式および不連続式双方の入力および出力を有してもよい。例えば、マーケットメーカ・ブロックは、インスツルメント、価格、数量および注文に値付けをするための条件を指定するための連続式入力を有してもよく、かつ受付中の数量の連続式出力および約定通知を提供するための不連続出力を有してもよい。取引ブロックは、プログラマでない者（トレーダ等）を含むユーザが、取引アルゴリズムを生成して配備するために視覚的設計環境（ＡＤＬにより提供されるもの等）を利用できるようにする。取引ブロックは、より少ないステップを有する典型的なプログラマよりも高速かつ正確な設計のアルゴリズム、または他の視覚的プログラミングプラットフォームよりも高速かつ正確な設計の命令を見込むものであってもよい。
【０１３３】
不連続ブロックは、概して不連続な入力および出力を有し、かつ不連続イベントの発生に基づいてオペレーションを提供する。例えば、ジェネレータブロックは、不連続イベントの発生を生成してもよい。別の例として、値抽出器ブロックは不連続イベントから値を抽出し、かつこれを連続値としてアルゴリズムの別の部分が利用できるようにしてもよい。別の例として、シーケンサブロックは、不連続イベントに応答して連続ブロックが処理されるシーケンスを制御するために用いられてもよい。所定の不連続ブロックは、後続時に参照されるべきデータを格納してもよい。例えば、値積算器ブロックは不連続イベントを受信し、かつこれからユーザ指定の値を抽出してもよい。抽出される値は、受信された各不連続イベントから抽出された値と共に累積されてもよい。
【０１３４】
その他のブロックは、必ずしも上述のカテゴリに当て嵌まらない場合がある様々な機能を提供する。例えば、これらのブロックは専用の、またはより複雑な計算を提供する場合もあれば、アルゴリズム自体の実行に追加的制御を加える場合もある。さらに、その他のブロックは、リスクを制御し、数値を取引可能な値に変換し、または時間（精確な時刻であれ経過時間であれ）を入力または変数として用いるためのより精確なツールを提供してもよい。
【０１３５】
図３Ｃは、所定の実施形態による、取引インタフェース３１０において用いられてもよいブロック３２０の例を示す。図中には、先に同定された各カテゴリからのブロック例が示されている。基本ブロック例は、加算ブロック３２１と、ｉｆ−ｔｈｅｎ−ｅｌｓｅブロック３２２とを含む。取引ブロック例は、マーケットメーカ・ブロック３２３と、条件付き売り／買いブロック３２４と、注文ハンドラブロック３２５とを含む。不連続ブロック例は、値抽出器ブロック３２６と、ブランチブロック３２７とを含む。その他のブロック例は、注記ブロック３２８と、ポーズブロック３２９とを含む。以下、これらのブロックの各々、並びに所定の実施形態に包含され得る他のブロック例についてさらに詳しく論じる。
【０１３６】
基本ブロックは、例えば、加算、減算、乗算、除算、大なり、小なり、以上、以下、ＡＮＤ、ＯＲ、等号、ＩＦ−ＴＨＥＮ−ＥＬＳＥ、数字、ブールおよび定数の各ブロックを含んでもよい。
【０１３７】
加算ブロックは、２つの連続式数値入力を合算して連続する１つの数値出力を生成してもよい。加算ブロックは、真ん中にプラス記号（「＋」）、左側に２つの連続式入力および右側に１つの連続式出力を備える三角形状を有してもよい。加算ブロックは、加算器ブロックと称される場合もある。
【０１３８】
減算ブロックは、１つの連続式数値入力（例えば、ボトム入力）を第２の連続式数値入力（例えば、トップ入力）から減算して１つの連続式数値出力を生成してもよい。減算ブロックは、真ん中にマイナス記号（「−」）、左側に２つの連続式入力および右側に１つの連続式出力を備える三角形状を有してもよい。
【０１３９】
乗算ブロックは、２つの連続式数値入力を乗算して連続する１つの数値出力を生成してもよい。乗算ブロックは、真ん中に乗算記号（「Ｘ」または「＊」）、左側に２つの連続式入力および右側に１つの連続式出力を備える三角形状を有してもよい。
【０１４０】
除算ブロックは、１つの連続式数値入力（例えば、トップ入力）を第２の連続する入力（例えば、ボトム入力）で除算して１つの連続式数値出力を生成してもよい。除算ブロックは、真ん中に除算記号（「／」または「÷」）、左側に２つの連続式入力および右側に１つの連続式出力を備える三角形状を有してもよい。
【０１４１】
大なりブロックは、２つの連続式数値入力を比較して、一方の入力（例えば、トップ入力）が第２の入力（例えば、ボトム入力）より大きいかどうかを決定してもよい。出力は、第１の入力が第２の入力より大きければ連続するブール出力「真」であり、その他の状況に関しては全て「偽」である。大なりブロックは、真ん中に大なり記号（「＞」）、左側に２つの連続式数値入力および右側に１つの連続式ブール出力を備える、左側が矩形で右側がアーチ形の形状を有してもよい。
【０１４２】
小なりブロックは、２つの連続式数値入力を比較して、一方の入力（例えば、トップ入力）が第２の入力（例えば、ボトム入力）より小さいかどうかを決定してもよい。出力は、第１の入力が第２の入力より小さければ連続するブール出力「真」であり、その他の状況に関しては全て「偽」である。小なりブロックは、真ん中に小なり記号（「＜」）、左側に２つの連続式数値入力および右側に１つの連続式ブール出力を備える、左側が矩形で右側がアーチ形の形状を有してもよい。
【０１４３】
以上ブロックは、２つの連続式数値入力を比較して、一方の入力（例えば、トップ入力）が第２の入力（例えば、ボトム入力）以上であるかどうかを決定してもよい。出力は、第１の入力が第２の入力以上であれば連続するブール出力「真」であり、その他の状況に関しては全て「偽」である。以上ブロックは、真ん中に以上記号（「＞＝」または「＞−」）、左側に２つの連続式数値入力および右側に１つの連続式ブール出力を備える、左側が矩形で右側がアーチ形の形状を有してもよい。
【０１４４】
以下ブロックは、２つの連続式数値入力を比較して、一方の入力（例えば、トップ入力）が第２の入力（例えば、ボトム入力）以下であるかどうかを決定してもよい。出力は、第１の入力が第２の入力以下であれば連続するブール出力「真」であり、その他の状況に関しては全て「偽」である。以下ブロックは、真ん中に以下記号（「＜＝」または「＜−」）、左側に２つの連続式数値入力および右側に１つの連続式ブール出力を備える、左側が矩形で右側がアーチ形の形状を有してもよい。
【０１４５】
ＡＮＤブロックは、第１の入力（例えば、トップ入力）が「真」でありかつ第２の入力（例えば、ボトム入力）が「真」であればブール出力が「真」であるように、２つの連続式ブール入力の論理積を実行してもよい。入力の何れかが「偽」であれば、出力値は「偽」である。ＡＮＤブロックは、真ん中にテキスト「ＡＮＤ」、左側に２つの連続式ブール入力および右側に１つの連続式ブール出力を備える、左側が矩形で右側がアーチ形の形状を有してもよい。
【０１４６】
ＯＲブロックは、入力の何れかが「真」であればブール出力は「真」であるように、２つの連続式ブール入力の論理和を実行してもよい。両方の入力が「偽」であれば、出力値は「偽」である。ＯＲブロックは、真ん中にテキスト（ＯＲ）、左側に２つの連続式ブール入力および右側に１つの連続式ブール出力を備える、左側が矩形で右側がアーチ形の形状を有してもよい。
【０１４７】
等号ブロックは、２つの連続する入力を比較して、一方の入力（例えば、トップ入力）が第２の入力（例えば、ボトム入力）に等しいかどうかを決定してもよい。入力は、各入力が同じタイプである限り、等式ブロックが数字、ブールまたはインスツルメント等の値を受け入れてもよいように、変数値タイプであってもよい。出力は、２つの入力が等しければ連続するブール出力「真」であり、その他の状況に関しては全て「偽」である。等号ブロックは、真ん中に等号（「＝」）、左側に２つの連続する変数入力および右側に１つの連続式ブール出力を備える、左側が矩形で右側がアーチ形の形状を有してもよい。等号ブロックは、等式ブロックと称される場合もある。
【０１４８】
ＩＦ−ＴＨＥＮ−ＥＬＳＥブロックは３つの連続式入力、即ち、ブールＩＦ入力、変数ＴＨＥＮ入力および変数ＥＬＳＥ入力を有してもよい。ＩＦ−ＴＨＥＮ−ＥＬＳＥブロックは、１つの連続式変数出力を有する。ＩＦ入力値が「真」であれば、出力はＴＨＥＮ入力の値である。ＩＦ入力値が「偽」であれば、出力はＥＬＳＥ入力の値である。ＩＦ−ＴＨＥＮ−ＥＬＳＥブロックは、真ん中に「？」記号、左側に１つの連続式ブールＩＦ入力および２つの連続式変数ＥＬＳＥ入力およびＴＨＥＮ入力および右側に１つの連続式変数出力を備える矩形形状を有してもよい。
【０１４９】
数字ブロックは、ユーザによって指定された数値を提供する１つの連続式数値出力を有してもよい。配置されると、ユーザは、数字ブロックに数値を入力するようにプロンプトされてもよい。あるいは、数字ブロックは、１等の既定値へデフォルトしてもよい。さらに、値は、注文チケット数量または注文チケット価格に指定されてもよい。そうであれば、数字ブロックの値は、注文がアルゴリズムを用いて管理されるように開始される際に指定される個々の値となる。指定された値は、アルゴリズムを設計する間に、ユーザにより、例えば、数字ブロックを選択しかつ値を入力すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。また、指定された値は、数字ブロックが可変であるように指定されていれば、後述する変数エリア３１３を用いて変更されてもよい。数字ブロックは、真ん中に指定された数字、および右側に１つの連続式数値出力を備える円形状を有してもよい。このブロックは、定数ブロックと称される場合もある。
【０１５０】
ブールブロックは、ユーザによって指定されたブール値を提供する１つの連続式ブール出力を有してもよい。配置されると、ユーザは、ブールブロックにブール値を入力するようにプロンプトされてもよい。あるいは、ブールブロックは、「真」等の既定値へデフォルトしてもよい。指定された値は、アルゴリズムを設計する間に、ユーザにより、例えば、ブールブロックを選択しかつ値を入力すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。また、指定された値は、ブールブロックが可変であるように指定されていれば、後述する変数エリア３１３を用いて変更されてもよい。ブールブロックは、真ん中に指定されたブール値がテキスト表示されかつ右側に１つの連続式ブール出力を備える円形状を有してもよい。このブロックは、定数ブールブロックと称される場合もある。
【０１５１】
所定の実施形態において、数字ブロックおよびブールブロックは、定数ブロック等の単一ブロックに合併されてもよい。定数ブロックは、ユーザによって指定された数値を提供する１つの連続式変数出力を有してもよい。配置されると、ユーザは、定値ブロックに値タイプおよび値を入力するようにプロンプトされてもよい。
あるいは、定数ブロックは、数字等の既定値タイプおよび１等の既定値へデフォルトしてもよい。さらに、値は、注文チケット数量または注文チケット価格に指定されてもよい。そうであれば、定数ブロックの値は、注文がアルゴリズムを用いて管理されるように開始される際に指定される個々の値となる。指定された値は、アルゴリズムを設計する間に、ユーザにより、例えば、定数ブロックを選択しかつ値を入力すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。また、指定された値は、定数ブロックが可変であるように指定されていれば、後述する変数エリア３１３を用いて変更されてもよい。定数ブロックは、真ん中に指定された値がテキスト表示されかつ右側に１つの連続式変数出力を備える円形状を有してもよい。所定の実施形態において、定数ブロックは、後述するインスツルメントブロックと同様に、インスツルメントを値に指定することもサポートする場合がある。
【０１５２】
取引ブロックは、例えば、インスツルメント、インスツルメント属性、マーケットメーカ、レガー、カスタムスプレッド、レスポンシブ売／買、条件付き売／買、注文ハンドラ、ＩＦ−ＴＨＥＮ−ＥＬＳＥインスツルメント、価格時インスツルメント属性、値幅、取引、注文、約定計算機および約定積算器の各ブロックを含んでもよい。
【０１５３】
インスツルメントブロックは、インスツルメント名を提供する１つの連続式インスツルメント出力を有してもよい。インスツルメント名は、例えば、取引所がリストするインスツルメントであっても、合成インスツルメントであってもよい。配置されると、ユーザは、インスツルメントブロックにそのインスツルメント名を指定するようにプロンプトされてもよい。インスツルメント名は、例えば、リストから選択されてもよい。あるいは、インスツルメントブロックは既定値へデフォルトしてもよい。指定された値は、アルゴリズムを設計する間に、ユーザにより、例えば、インスツルメントブロックを選択しかつ値を入力すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。また、指定された値は、インスツルメントブロックが可変であるように指定されていれば、変数エリア３１３を用いて変更されてもよい。
【０１５４】
インスツルメント属性ブロックは、連続式インスツルメント入力と、連続式数値出力とを有してもよい。インスツルメント属性ブロックは、インスツルメント名を採用しかつそのインスツルメントの指定される属性に値を出力してもよい。属性には、最良の買い数量、最良の買い呼び値、最良の売り数量、最良の売り呼び値、出来高、セッション高値、セッション安値、取引可能な最小増分、最終取引価格、最終取引数量、合計数量（新価格で取引が発生するまでの最終取引価格で取引された合計数量）、先行取引セッションからの精算値、実際の（非黙示）最良の買い数量、実際の（非黙示）最良の売り数量、買いヘッドカウント（最良の買い呼び値での市場における注文数）、売りヘッドカウント（最良の売り呼び値での市場における注文数）またはポジション（特別なインスツルメントにおけるユーザの総合インベンタ）が含まれてもよい。配置されると、ユーザは、インスツルメント属性ブロックによって提供されるべき属性を入力するようにプロンプトされてもよい。あるいは、インスツルメント属性ブロックは、買い数量等の既定値へデフォルトしてもよい。指定された属性は、アルゴリズムを設計する間に、ユーザにより、例えば、インスツルメント属性ブロックを選択しかつ属性を入力すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。また、指定された属性は、インスツルメント属性ブロックが可変であるように指定されていれば、後述する変数エリア３１３を用いて変更されてもよい。
【０１５５】
マーケットメーカ・ブロックは、条件連続式ブール入力が「真」である場合、連続式インスツルメント入力により指定される取引可能オブジェクトの売り注文または買い注文を２つの連続式数値入力により指定される価格および数量で提出してもよい。条件入力はオプションであり、入力が与えられなければ「真」へデフォルトする。マーケットメーカ・ブロックは、条件入力が「偽」である場合に注文を削除してもよい。マーケットメーカ・ブロックは、個々の価格および数量入力値が変われば、既存の注文の価格または数量を修正する場合もある。数量入力に指定される値は、先行する約定を考慮した希望される最大約定数量を表す。例えば、数量入力値５が与えられれば、マーケットに注文５が入力されてもよく、かつ数量３が約定されれば、価格入力が変わっても注文２は機能され続けることになる。数量入力が変われば、機能される注文は、指定される新規数量から既に約定された数量３を減じたものとなる。マーケットメーカ・ブロックは、約定確認および／または注文要求の不連続イベントを提供する１つまたは複数の不連続出力を提供してもよい。マーケットメーカ・ブロックは、アルゴリズムが削除され、中断され、停止され、または休止されても、マーケットメーカ・ブロックによって生成される注文は注文帳に留まるべきであることを指定するためのオプションを含んでもよい。この機能は、例えば、アルゴリズムのヘッジ部分に有益である場合がある。マーケットメーカ・ブロックは、マーケットメーカ・ブロックによって生成される注文が注文帳に表示される間はハングとしてマークされることを指定するためのオプションを含んでもよく、これは、（例えば、注文が注文帳に留まるものとは予想されていない場合でも）不適切に機能する、または不完全なアルゴリズムの識別をより容易にする場合がある。また、マーケットメーカ・ブロックは、例えば注文ウィンドウにおけるそれらの識別をより容易にするために、マーケットメーカ・ブロックによって配置される注文に関連づけられる色またはテキストフラグを指定するためのオプションも含む場合がある。
【０１５６】
レガーブロックは、カスタムスプレッドのレッグの取引可能オブジェクトに関して買い注文または売り注文を提出してもよく、この場合、各レッグの取引可能オブジェクトは連続式インスツルメント入力によって指定される。カスタムスプレッドに希望される価格および数量は、２つの連続式数値入力によって指定される。レガーブロックは、条件連続式ブール入力が「真」である場合に、スプレッドの個々の注文を起こす。条件入力はオプションであり、入力が与えられなければ「真」へデフォルトする。レガーブロックは、条件入力が「偽」である場合に注文を削除してもよい。レガーブロックは、価格および／または数量入力値が変われば、受付中の注文の価格および／または数量を修正する場合もある。数量入力に指定される値は、先行する約定を考慮したスプレッドの希望される最大約定数量を表す。例えば、数量入力値５が与えられれば、マーケットに注文５が入力されてもよく、かつ数量３が約定されれば、価格入力が変わっても注文２は機能され続けることになる。数量入力が変われば、機能される注文は、指定される新規数量から既に約定された数量３を減じたものとなる。レガーブロックは、スプレッド約定、注文要求および／またはレッグ約定の不連続イベントを提供する１つまたは複数の不連続出力を提供してもよい。スプレッドのレッグに関してインスツルメントが提供された後、レガーは、例えば、レガーブロックを選択しかつパラメータおよび設定値を指定すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって設定されてもよい。スプレッドの各レッグに指定され得るパラメータには、「倍数」（スプレッドレッグの係数）、「取引数量」（スプレッドの各レッグの数量、但し、正数は買いであり、負数は売りである）、「マーケットを働かせる？」（スプレッドのレッグが能動的に値付けをするかどうかトグルする）、「純変動」（カスタムスプレッド計算を価格ではなく純変動に変換するかどうかトグルする）、「ペイアップ・ティック」（カスタムスプレッドがリーンなレッグにリミット注文を入力する際の最小価格増分数、正数は成約に対してより積極的であることを意味し、負数は成約に対してあまり積極的でないことを意味する）および「リーンなレシオ」（呼び値のレッグに１数量単位を働かせるべくリーンなレッグ上に存在するために要求される数量単位、これは、例えば、２つのレッグ間の数量比である場合も、リーンなレッグにおけるしきい値数量である場合もある）が含まれる。指定され得る設定値には、「サイド」（カスタムスプレッドの買い手または売り手）、「常時場内市場を働かせる」（真であればレガーブロックは単に最良または場内市場に現出する個々のレッグ注文を働かせることと、所定の実施形態において、単に市場売／買サイズレシオを見て決定される通りに成約される可能性が高いレッグを働かせることをトグルする）、「「スナイピング」モードを無効化する」（レガーブロックは、希望されるスプレッド価格を達成することができれば、受付中のカレント注文を削除すると同時に、全てのレッグについて希望スプレッド価格で成約するように注文を出すデフォルト行動をトグルする。無効化されると、レガーブロックは、希望価格が瞬間的に利用可能となっても指定された「マーケットを働かせる？」レッグしか働かせない）、「クリップサイズ」（合計数量が規定されたスプレッド数量入力によって定義された通りに満たされるまで繰返し増大する、一度に機能されるべき数量）および「フラグ」（識別をより容易にするために、スプレッド約定の不連続イベントに関連づけられるユーザ定義のフラグを指定する）が含まれる。レガーブロックは、アルゴリズムが削除され、中断され、停止され、または休止されても、レガーブロックによって生成される注文は注文帳に留まるべきであることを指定するためのオプションを含んでもよい。レガーブロックは、レガーブロックによって生成される注文が注文帳に表示される間はハングとしてマークされることを指定するためのオプションを含んでもよく、これは、（例えば、注文が注文帳に留まるものとは予想されていない場合でも）不適切に機能する、または不完全なアルゴリズムの識別をより容易にする場合がある。また、レガーブロックは、例えば注文ウィンドウにおけるそれらの識別をより容易にするために、レガーブロックによって配置される注文に関連づけられる色またはテキストフラグを指定するためのオプションも含む場合がある。このブロックは、オートスプレッドブロックまたはスプレッダブロックと称される場合もある。
【０１５７】
カスタムスプレッド・ブロックは、カスタムスプレッドのレッグの取引可能オブジェクトに関して買い注文または売り注文を提出してもよく、この場合、カスタムスプレッドは外部アプリケーションからのインスツルメントとして提供される。カスタムスプレッドに希望される価格および数量は、２つの連続式数値入力によって指定される。カスタムスプレッド・ブロックは、条件連続式ブール入力が「真」である場合に、スプレッドの個々の注文を起こす。条件入力はオプションであり、入力が与えられなければ「真」へデフォルトする。カスタムスプレッド・ブロックは、条件入力が「偽」である場合に注文を削除してもよい。カスタムスプレッド・ブロックは、価格および／または数量入力値が変われば、受付中の注文の価格および／または数量を修正する場合もある。数量入力に指定される値は、先行する約定を考慮したスプレッドの希望される最大約定数量を表す。例えば、数量入力値５が与えられ、数量３が約定されれば、価格入力が変わっても注文２は機能され続けることになる。数量入力が変われば、機能される注文は、指定される新規数量から既に約定された数量３を減じたものとなる。カスタムスプレッド・ブロックは、オリジナルの注文数量をヘッジ・レッグに提示するように要求する代わりに、個々の注文のレッグの注文数量のダイナミックサイジングを有効化するためのブール入力をオプションとして含んでもよい。カスタムスプレッド・ブロックは、約定確認および／または注文要求の不連続イベントを提供する１つまたは複数の不連続出力を提供してもよい。配置されると、ユーザは、外部アプリケーションからカスタム設計インスツルメントを指定するようにプロンプトされてもよく、この場合、カスタム設計インスツルメントは、取引戦略を表現する合成市場データを提供する。あるいは、指定されるカスタム設計インスツルメントは、アルゴリズムを設計する間に、ユーザにより、例えば、カスタムスプレッド・ブロックを選択しかつ外部アプリケーションからカスタム設計インスツルメントを指定すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって指定され、かつ／または変更されてもよい。
さらに、アルゴリズムを設計する間、ユーザは、「「スナイピング」モードを無効化する」（カスタムスプレッド・ブロックは、希望されるスプレッド価格を達成することができれば、受付中のカレント注文を削除すると同時に、全てのレッグについて希望スプレッド価格で成約するように注文を出すデフォルト行動をトグルする。無効化されると、カスタムスプレッド・ブロックは、希望価格が瞬間的に利用可能となっても指定された呼び値のレッグしか働かせない）、および「クリップサイズ」（合計数量が規定されたスプレッド数量入力によって定義された通りに満たされるまで繰返し増大する、一度に機能されるべき数量）を含む場合のある設定値を指定してもよい。カスタムスプレッド・ブロックは、アルゴリズムが削除され、中断され、停止され、または休止されても、カスタムスプレッド・ブロックによって生成される注文は注文帳に留まるべきであることを指定するためのオプションを含んでもよい。カスタムスプレッド・ブロックは、カスタムスプレッド・ブロックによって生成される注文が注文帳に表示される間はハングとしてマークされることを指定するためのオプションを含んでもよく、これは、（例えば、注文が注文帳に留まるものとは予想されていない場合でも）不適切に機能する、または不完全なアルゴリズムの識別をより容易にする場合がある。また、カスタムスプレッド・ブロックは、例えば注文ウィンドウにおけるそれらの識別をより容易にするために、カスタムスプレッド・ブロックによって配置される注文に関連づけられる色またはテキストフラグを指定するためのオプションも含む場合がある。所定の実施形態において、カスタムスプレッド・ブロックは、外部アプリケーションからの指定されたカスタム設計インスツルメントを連続式インスツルメント出力として提供してもよい。所定の実施形態において、カスタムスプレッド・ブロックは、外部アプリケーションからの指定された数値またはブール値を連続式数値またはブール出力として提供してもよい。このブロックは、カスタム戦略ブロックまたはカスタム外部アプリケーションブロックと称される場合もある。
【０１５８】
レスポンシブ売／買ブロックは、不連続入力で不連続イベントが受信されると、連続式インスツルメント入力により指定されたインスツルメントの買い注文または売り注文の提出を開始してもよい。発注価格および／または数量は、連続式数値入力によって提供されてもよい。あるいは、価格および／または数量は、使用されるべき個々の価格または数量値を決定すべく評価されるユーザ定義の方程式によって指定されてもよい。所定の実施形態において、価格および数量の一方は連続式数値入力によって提供されてもよく、もう一方はユーザ定義の方程式を評価することによって提供されてもよい。指定された価格および／または数量の方程式（使用されれば）は、アルゴリズムを設計する間に、ユーザにより、例えば、レスポンシブ売／買ブロックを選択しかつ方程式を入力すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。方程式は、テキスト通りに、または例えば、先に論じたビルディング・ブロック・ボタン２１５に類似するビルディング・ブロック・ボタンを用いて入力されてもよい。レスポンシブ売／買ブロックが一旦発注を開始すると、注文は、提供される価格および／または数量値のその後の変化に基づいて更新されない。レスポンシブ売／買ブロックは、アルゴリズムが削除され、中断され、停止され、または休止されても、レスポンシブ売／買ブロックによって生成される注文は注文帳に留まるべきであることを指定するためのオプションを含んでもよい。レスポンシブ売／買ブロックは、レスポンシブ売／買ブロックによって生成される注文が注文帳に表示される間はハングとしてマークされることを指定するためのオプションを含んでもよく、これは、（例えば、注文が注文帳に留まるものとは予想されていない場合でも）不適切に機能する、または不完全なアルゴリズムの識別をより容易にする場合がある。また、レスポンシブ売／買ブロックは、例えば注文ウィンドウにおけるそれらの識別をより容易にするために、レスポンシブ売／買ブロックによって配置される注文に関連づけられる色またはテキストフラグを指定するためのオプションも含む場合がある。
【０１５９】
条件付き売／買ブロックは、条件連続式ブール入力が「真」である場合、連続式インスツルメント入力により指定されるインスツルメントの売り注文または買い注文の発注を２つの連続式数値入力により指定される価格および数量で開始してもよい。条件入力はオプションであり、入力が与えられなければ「真」へデフォルトする。条件付き売／買ブロックは、条件入力値が「偽」である場合でも注文を削除しない（但し、発注は、条件入力が「真」になるまで開始されない）。条件付き売／買ブロックは、一度に１つの注文だけを提出してもよい。所定の実施形態において、条件付き売／買ブロックは、注文が（例えば、アルゴリズムにおける別のブロックによって、またはユーザにより手動で）削除される場合でも、提供された当初の数量値を達成しようと注文（一度に１つの注文）を提出し続ける。条件付き売／買ブロックが一旦発注を開始すると、注文は、提供される価格および／または数量値のその後の変化に基づいて更新されない。条件付き売／買ブロックは、約定確認および／または注文要求の不連続イベントを提供する１つまたは複数の不連続出力を提供してもよい。条件付き売／買ブロックは、アルゴリズムが削除され、中断され、停止され、または休止されても、条件付き売／買ブロックによって生成される注文は注文帳に留まるべきであることを指定するためのオプションを含んでもよい。条件付き売／買ブロックは、条件付き売／買ブロックによって生成される注文が注文帳に表示される間はハングとしてマークされることを指定するためのオプションを含んでもよく、これは、（例えば、注文が注文帳に留まるものとは予想されていない場合でも）不適切に機能する、または不完全なアルゴリズムの識別をより容易にする場合がある。また、条件付き売／買ブロックは、例えば注文ウィンドウにおけるそれらの識別をより容易にするために、条件付き売／買ブロックによって配置される注文に関連づけられる色またはテキストフラグを指定するためのオプションも含む場合がある。
【０１６０】
注文ハンドラブロックは、不連続入力において注文イベントを受信し、かつ２つの連続式数値入力によって提供される価格および数量値を基礎として対応する注文を管理してもよい。連続式ブール入力において提供される値が「真」であれば、注文は削除される。注文ハンドラブロックは、約定確認、削除確認および／または変更確認の不連続イベントを提供する１つまたは複数の不連続出力を提供してもよい。注文ハンドラブロックは、受付中の数量および／または約定された数量を連続式数値出力へ提供してもよい。注文ハンドラブロックは、アルゴリズムが削除され、中断され、停止され、または休止されても、注文ハンドラブロックによって管理される注文は注文帳に留まるべきであることを指定するためのオプションを含んでもよい。
【０１６１】
ＩＦ−ＴＨＥＮ−ＥＬＳＥインスツルメントブロックは３つの連続式入力、即ち、ブールＩＦ入力、インスツルメントＴＨＥＮ入力およびインスツルメントＥＬＳＥ入力を有してもよい。ＩＦ−ＴＨＥＮ−ＥＬＳＥインスツルメントブロックは、１つの連続式インスツルメント出力を有する。ＩＦ入力値が「真」であれば、出力はＴＨＥＮ入力のインスツルメント値である。ＩＦ入力値が「偽」であれば、出力はＥＬＳＥ入力のインスツルメント値である。ＩＦ−ＴＨＥＮ−ＥＬＳＥインスツルメントブロックは、真ん中に「？」記号、左側に１つの連続式ブールＩＦ入力および２つの連続式インスツルメントＥＬＳＥ入力およびＴＨＥＮ入力および右側に１つの連続式インスツルメント出力を備える矩形形状を有してもよい。ＩＦ−ＴＨＥＮ−ＥＬＳＥインスツルメントブロックは、先に論じたＩＦ−ＴＨＥＮ−ＥＬＳＥブロックに類似するが、インスツルメント値に特化されている。
【０１６２】
価格時インスツルメント属性ブロックは、連続式インスツルメント入力と、連続式数値入力と、連続式数値出力とを有してもよい。価格時インスツルメント属性ブロックは、インスツルメント名（連続式インスツルメント入力によって提供される）および価格（連続式数値入力によって提供される）を採用しかつ指定価格におけるそのインスツルメントの指定される属性に値を出力してもよい。属性には、買い数量、売り数量、実際の（非黙示）買い数量、実際の（非黙示）売り数量、買いヘッドカウント（指定価格での市場における買い注文数）および売りヘッドカウント（指定価格での市場における売り注文数）が含まれてもよい。配置されると、ユーザは、価格時インスツルメント属性ブロックによって提供されるべき属性を入力するようにプロンプトされてもよい。あるいは、価格時インスツルメント属性ブロックは、買い数量等の既定値へデフォルトしてもよい。指定された属性は、アルゴリズムを設計する間に、ユーザにより、例えば、価格時インスツルメント属性ブロックを選択しかつ属性を入力すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。また、指定された属性は、価格時インスツルメント属性ブロックが可変であるように指定されていれば、後述する変数エリア３１３を用いて変更されてもよい。
【０１６３】
値幅ブロックは、２つの連続式インスツルメント入力と、１つの連続式インスツルメント出力とを有してもよい。値幅ブロックは、２つのインスツルメント名（例えば、一方は「フロントレッグ」入力から、他方は「バックレッグ」入力から）を採用し、かつ提供される２つのインスツルメントの取引所がリストするスプレッドに対応するインスツルメント名（例えば、「フロントレッグ−バックレッグ」）を出力してもよい。例えば、値幅ブロックは、「ＣＬＺ０」（２０１０年１２月原油）および「ＣＬＦ１」（２０１１年１月原油）等の異なる２つのインスツルメント間のスプレッドを参照するために用いられてもよい。これらの「レッグ」は各々、「フロントレッグ」および「バックレッグ」と称される場合がある。値幅ブロックの対応する出力は取引所がリストするスプレッドインスツルメントであり、本例では、取引所がリストするインスツルメント「ＣＬＺ０−ＣＬＦ１」（２０１０年１２月−２０１１年１月のスプレッド市場）である。このブロックは、インスツルメント間のスプレッドを正しく参照するプロセスのエラーを減らすべくプログラミングの安全性を高めるために用いられてもよい。例えば、入力される２つのインスツルメントは、アルゴリズムの実行中に変更が可能な変数、またはアルゴリズムによって管理されている異なる注文に対しては取引所がリストする異なるスプレッドであるように指定されることが可能な変数として表示されてもよい。値幅ブロックは、第３の変数を個々の２つのインスツルメント変数に整合するように設定または変更する必要なしに、リストされた「正しい」スプレッドインスツルメントを発見することによって安全を提供する。また、値幅ブロックは、取引所がリストする所定のスプレッドの存在を位置決めする、または探索するために用いられる場合もある。
【０１６４】
取引ブロックは、連続式インスツルメント入力に提供されるインスツルメントに関して、不連続イベント出力に不連続イベントにおける取引データを提供してもよい。不連続イベントは、各取引に関連づけられる取引価格値および取引数量値を含む。取引データは、例えば、取引所から受信されてもよい。取引価格および取引数量は、不連続イベントから、例えば値抽出器ブロック、値積算器ブロック、不連続最小ブロックおよび／または不連続最大ブロックによって抽出されてもよい。
【０１６５】
注文ブロックは、既存の注文（即ち、アルゴリズムの外部で既に発注されていて、しかも別のアルゴリズムによって管理されていない注文）を定義されたアルゴリズムに従って管理することができるようにする場合がある。例えば、注文ブロックは、ユーザによって手動で発注されている注文を制限する特定タイプのオートヘッジ・ルーチンを提供するために用いられてもよい。注文ブロックは、既存の注文に関連するインスツルメントの連続式インスツルメント出力、および既存の注文の数量、価格および実行された数量に関する連続式数値出力を提供する。また、注文ブロックは、注文に関連する約定確認等の注文不連続イベントに関して不連続出力も提供する。所定の実施形態では、定義されたアルゴリズムが注文ブロックを含んでいれば、このアルゴリズムは、例えば注文ウィンドウを含む取引インタフェースにおいて、既存の注文へ適用されるべき利用可能アルゴリズムのリスト内に提示されてもよい。別の例として、アルゴリズムが注文ブロック自体において実行される、または指定される場合には、注文識別子がアルゴリズムへ変数として提供されてもよい。既存の注文へ適用される場合、注文ブロックを含む定義されたアルゴリズムは、その注文をそのアルゴリズムに従って管理してもよい。
【０１６６】
約定計算機ブロックは、スプレッド約定の不連続イベントに関する不連続出力を提供してもよい。約定計算機ブロックは、アルゴリズムがカスタムスプレッドを、レガーブロックまたはカスタムスプレッド・ブロックを用いることなく買う／売る場合に用いられてもよい。約定計算機ブロックは、スプレッドの各取引実行（約定）レッグに関して複数の連続式インスツルメント入力と１つの不連続入力とを受信するが、前者はレッグのインスツルメントを提供しかつ後者は約定確認の不連続イベントを提供する。スプレッドのレッグに関してインスツルメントが提供された後、約定計算機ブロックは、例えば、約定計算機ブロックを選択しかつパラメータおよび設定値を指定すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって設定されてもよい。スプレッドの各レッグに指定され得るパラメータには、「倍数」（スプレッドレッグの係数）、「取引数量」（スプレッドの各レッグの数量、但し、正数は買いであり、負数は売りである）および「純変動」（カスタムスプレッド計算を価格ではなく純変動に変換するかどうかトグルする）が含まれる。指定され得る設定値には、「サイド」（約定計算機のカスタムスプレッドの買い手または売り手）および「フラグ」（識別をより容易にするために、スプレッド約定の不連続イベントに関連づけられるユーザ定義のフラグを指定する）が含まれる。
【０１６７】
積算器ブロックは、不連続入力において注文または約定の不連続イベントを受信し、かつ受信された不連続イベントの積算された数量を連続式数値出力に提供してもよい。例えば、積算器ブロックがマーケットメーカ・ブロックへ接続されていれば、積算器ブロックは、マーケットメーカ・ブロックから受信される部分的約定の不連続イベント毎にその連続式数値出力の値を増してもよい。このブロックは、例えば、約定総数を追跡するために用いられてもよい。積算器ブロックはパススルー・ブロックであってもよく、よって受信される各不連続イベントは対応する不連続出力を介して出される。積算器ブロックは、イベントを受信すると積算数量を０へリセットするリセット不連続入力を含んでもよい。積算器ブロックは、後述する値積算器ブロックに類似するものであってもよいが、約定された数量のみを積算することから、より限定的な機能を有する。
【０１６８】
不連続ブロックには、例えば、発生器、値抽出器、値積算器、値バケット、不連続移動平均、状態、ブランチ、マルチプレクサ、ファンネル、シーケンサ、不連続最小ブロックおよび不連続最大ブロックの各ブロックが含まれてもよい。
【０１６９】
発生器ブロックは、条件が「真」であればいつも不連続出力に不連続イベントを提供してもよい。条件は、条件入力が「真」になる度にイベントが発生されるように、連続式ブール入力によって提供されてもよい。あるいは、条件は、「開始時」（条件は、アルゴリズムの開始時には「真」であってその後は「偽」であり、よって、アルゴリズムの開始時に単一の不連続イベントが提供される）、「変更時」（条件は、連続式ブール入力値が変わるとき常に「真」であり、よって、「真」から「偽」へ、または「偽」から「真」への移行の双方が不連続イベントを発生させる）、「毎Ｘ」（条件は、指定された時間間隔毎に一度「真」となり、前記間隔は分、秒またはミリ秒単位で指定されてもよい）等のイベントであるように指定されてもよい。
【０１７０】
値抽出器ブロックは、不連続入力で不連続イベントを受信し、かつそのイベントからユーザ指定の値を抽出してもよい。あるいは、値抽出器ブロックは、不連続イベントが受信されると、抽出される値を決定するためにユーザ定義の方程式を評価してもよい。抽出された値は、次に、連続式出力へ提供されてもよい。出力の値タイプは、抽出された値のタイプに依存する。不連続イベントから抽出されるべき値を指定する際には、下記の式：「インスツルメント」（不連続イベントに関連づけられるインスツルメントを提供する）、「約定価格」（不連続イベントに関連づけられる約定価格を提供する）、「約定数量」（不連続イベントに関連づけられる約定数量を提供する）、「注文数量」（不連続イベントに関連づけられる注文数量を提供する）、「注文価格」（不連続イベントに関連づけられる注文価格を提供する）、「実行数量」（注文数量に関連する約定の累算を提供する）、「受付中の数量」（特定の注文価格における実行されない注文数量の累算を提供する）、「取引数量」（ある取引所で実行される取引の数量を提供する）、「取引価格」（ある取引所で実行される取引の価格を提供する）および「変数」（指定されたユーザ定義変数の値、またはアルゴリズムにおける、仮想化されたグループブロックの一部ではない他の任意のブロック出力の値を提供する）を利用可能である。所定の実施形態において、値抽出器ブロックは、別のブロックの出力からの値を参照してもよい。値は、例えば、先に論じた式「変数」を用いて参照されてもよく、または値は、値抽出器ブロックの連続式変数入力へ提供されてもよい。値抽出器ブロックはパススルー・ブロックであってもよく、よって受信される各不連続イベントは対応する不連続出力を介して出される。
【０１７１】
値積算器ブロックは、不連続入力で不連続イベントを受信し、かつ各不連続イベントの受信に伴ってイベントからユーザ指定の値を抽出し、値を積算してもよい。積算された値は、連続式数値出力へ提供される。不連続イベントから抽出されるべき値を指定する際には、下記の式：「約定価格」（不連続イベントに関連づけられる約定価格を提供する）、「約定数量」（不連続イベントに関連づけられる約定数量を提供する）、「注文数量」（不連続イベントに関連づけられる注文数量を提供する）、「注文価格」（不連続イベントに関連づけられる注文価格を提供する）、「実行数量」（注文数量に関連する約定の累算を提供する）、「受付中の数量」（特定の注文価格における実行されない注文数量の累算を提供する）、「取引数量」（ある取引所で実行される取引の数量を提供する）、「取引価格」（ある取引所で実行される取引の価格を提供する）および「変数」（指定されたユーザ定義変数の値、またはアルゴリズムにおける、仮想化されたグループブロックの一部ではない他の任意のブロック出力の値を提供する）を利用可能である。値積算器ブロックはパススルー・ブロックであってもよく、よって受信される各不連続イベントは対応する不連続出力を介して出される。値積算器ブロックは、イベントを受信すると積算価格を０へリセットするリセット不連続入力を含んでもよい。値積算器ブロックは、先に論じた積算器ブロックに類似するものであるが、どのような価格が積算されるかに関してさらにフレキシブルな設定をサポートする。
【０１７２】
値バケットブロックは、キー値ペアのテーブルを生成することに備える。このテーブルは、例えば、ハッシュテーブルであってもよい。値バケットブロックのテーブルのキーは、バケットホールと称される。テーブルの、特定のバケットホールに対応する値（即ち、テーブルのキー）は、バケット値と称される。値バケットブロックは、不連続入力で不連続イベントを受信する。不連続イベントが受信されると、テーブルにおける適切なエントリを決定するために、バケットホールに関するユーザ定義の方程式が評価される。バケット値に関するユーザ定義の方程式は、次に、テーブルにおける決定されたバケットホールに対応するエントリに関して新たなバケット値を決定するために評価される。後述するように、この新たなバケット値は、先行するバケット値と組み合わされても、これに取って代わってもよい。配置されると、ユーザは、バケットホールの式およびバケット値を入力するようにプロンプトされてもよい。あるいは、値バケットブロックは、バケットホール「０」およびバケット値「０」等の既定の方程式へデフォルトしてもよい。指定された方程式は、アルゴリズムを設計する間に、ユーザにより、例えば、値バケットブロックを選択しかつバケットホール方程式およびバケット値方程式の一方または双方を入力すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。方程式は、テキスト通りに、または例えば、先に論じたビルディング・ブロック・ボタン２１５に類似するビルディング・ブロック・ボタンを用いて入力されてもよい。方程式（ビルディング・ブロック・ボタンによって提供され得る）を指定する際に使用すべく利用可能な式には、「インスツルメント」（不連続イベントに関連づけられるインスツルメントを提供する）、「約定価格」（不連続イベントに関連づけられる約定価格を提供する）、「約定数量」（不連続イベントに関連づけられる約定数量を提供する）、「注文数量」（不連続イベントに関連づけられる注文数量を提供する）、「注文価格」（不連続イベントに関連づけられる注文価格を提供する）、「実行数量」（注文数量に関連する約定の累算を提供する）、「受付中の数量」（特定の注文価格における実行されない注文数量の累算を提供する）、「取引数量」（ある取引所で実行される取引の数量を提供する）、「取引価格」（ある取引所で実行される取引の価格を提供する）および「変数」（指定されたユーザ定義変数の値、またはアルゴリズムにおける、仮想化されたグループブロックの一部ではない他の任意のブロック出力の値を提供する）が含まれてもよい。値バケットの方程式を指定する一部として、ユーザは、新たなバケット値が先行するバケット値とどのように組み合わされるかも設定する場合がある。例えば、新たなバケット値は、先行するバケット値へ追加されてもよい（受信される不連続イベント毎に同じバケットホールに関して決定されるバケット値の加算を提供する）。別の例として、同じバケットホールに関して決定されるバケット値の平均が決定されてもよい。別の例として、新たなバケット値が先行するバケット値に取って代わってもよい（最新値を特定のバケットホールのバケット値として提供する）。値バケットは、例えば、特定のバケットホールに関するバケット値を合計することにデフォルトしてもよい。値バケットブロックはパススルー・ブロックであってもよく、よって受信される各不連続イベントは対応する不連続出力を介して出される。また、値バケットブロックは、提供されるバケットホールの対応するバケット値が値連続式数値出力において提供されるように、バケットホールとして使用されるべき値を提供するホール連続式数値入力も有する場合がある。値バケットブロックは、イベントを受信すると格納されたテーブルをリセットするリセット不連続入力を含んでもよい。
【０１７３】
不連続移動平均ブロックは、不連続入力において不連続イベントが受信される度に指定されたユーザ定義の方程式を評価することによって決定される値の移動平均を提供してもよい。移動平均を決定する際に使用されるべきデータポイントの数は、連続式数値入力によって指定される。移動平均は、連続式数値出力へ提供される。不連続移動平均ブロックは、対応する入力によって指定されたデータポイント数が達成されるまで、評価されたデータポイントのリストを保持してもよく、達成された時点で、最新のデータポイントがリストへ追加され、最も古いデータポイントがリストから外され、かつリスト内のデータポイントに渡って移動平均が計算されてもよい。配置されると、ユーザは、評価されるべき方程式を入力するようにプロンプトされてもよい。あるいは、不連続移動平均ブロックは、方程式に関して０等の既定値へデフォルトしてもよい。指定された方程式は、アルゴリズムを設計する間に、ユーザにより、例えば、不連続移動平均ブロックを選択しかつ方程式を入力すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。方程式は、テキスト通りに、または例えば、先に論じたビルディング・ブロック・ボタン２１５に類似するビルディング・ブロック・ボタンを用いて入力されてもよい。方程式（ビルディング・ブロック・ボタンによって提供され得る）を指定する際に使用すべく利用可能な式には、「インスツルメント」（不連続イベントに関連づけられるインスツルメントを提供する）、「約定価格」（不連続イベントに関連づけられる約定価格を提供する）、「約定数量」（不連続イベントに関連づけられる約定数量を提供する）、「注文数量」（不連続イベントに関連づけられる注文数量を提供する）、「注文価格」（不連続イベントに関連づけられる注文価格を提供する）、「実行数量」（注文数量に関連する約定の累算を提供する）、「受付中の数量」（特定の注文価格における実行されない注文数量の累算を提供する）、「取引数量」（ある取引所で実行される取引の数量を提供する）、「取引価格」（ある取引所で実行される取引の価格を提供する）および「変数」（指定されたユーザ定義変数の値、またはアルゴリズムにおける、仮想化されたグループブロックの一部ではない他の任意のブロック出力の値を提供する）が含まれてもよい。また、不連続移動平均ブロックは、リセット入力である不連続入力を採用する場合もある。リセット入力によって不連続イベントが受信されると、記録されたデータポイントは放棄される。これにより、移動平均の出力は結果的に０、または「非数」（ＮａＮ）になる場合がある。また、不連続移動平均ブロックは、移動平均を完全に計算するに足る数のデータポイントが記録されているかどうかを表示するＯＫの連続式ブール出力を提供する場合もある。ＯＫの出力は、必要とされる数のデータポイントが記録されるまでは「偽」であり、それ以後（リセットまで）は「真」である。例えば、入力されるデータポイント数が値２０を提供すれば、ＯＫ出力が「真」になるまでに２０個のデータポイント（即ち、各々不連続イベントの受信によってトリガされる、指定された方程式の２０個の評価）が記録される必要がある。また、不連続移動平均ブロックは、記録されているデータポイント数を表示するデータポイント数連続式数値出力を提供する場合もある。不連続移動平均ブロックはパススルー・ブロックであってもよく、よって受信される各不連続イベントは対応する不連続出力を介して出される。
【０１７４】
状態ブロックは、不連続入力において不連続イベントを受信し、かつその不連続イベントが不連続出力に提供されるべきかどうかを決定するために各不連続出力の条件文を評価してもよい。状態ブロックは、行動モデルである、例えば有限数の状態、これらの状態間の遷移およびアクションから成る状態マシンを設計するために用いられてもよい。複数の状態ブロックは、所定の条件が満たされた場合に論理が実行される様をユーザが調べ得る「フロー」グラフと同様に、互いに連結されてもよい。カレント状態は、過去の状態によって決定されることから、これは本質的には、過去に関する情報を記録してもよい。遷移は状態変化を表示し、かつ遷移を有効化するために満たされることが必要となる条件文によって記述される。状態ブロックは、ユーザが退出アクションおよび遷移を定義する条件文を定義できるようにする。例えば、各々が異なる状態遷移に対応する２つの不連続出力を提供する状態ブロックでは、ユーザはその各々について条件文を指定する。不連続イベントが受信された後、状態ブロックは、各遷移に関連づけられる条件文のうちの１つまたはそれ以上が「真」になるのを待つ（不連続イベントが受信された時点で、条件文の何れも「真」でなければ）。特定の状態遷移に関連づけられる条件文が「真」と評価されると、状態ブロックは、その特定の状態遷移に関連づけられる出力へ（受信以降保持されている）不連続イベントを提供する。条件文は、連続式ブール入力へ提供されてもよい。あるいは、条件文は、ブール値を評価する指定されたユーザ定義の方程式によって提供されてもよい。指定された方程式は、アルゴリズムを設計する間に、ユーザにより、例えば、状態ブロックを選択しかつ方程式を入力すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。方程式は、テキスト通りに、または例えば、先に論じたビルディング・ブロック・ボタン２１５に類似するビルディング・ブロック・ボタンを用いて入力されてもよい。状態ブロックは、非安値において複数の連続する取引が存在するかどうか等、市場におけるユーザ定義のパターンを評価するために用いられてもよい。これらの信号は、例えば、マーケットメーカ・ブロック等の取引ブロックへ入力される条件文として用いられてもよい。また状態ブロックは、例えば、不連続イベントが買いの約定メッセージであるか、売りの約定メッセージであるか等の情報を評価する可能性もある。方程式（ビルディング・ブロック・ボタンによって提供され得る）を指定する際に使用すべく利用可能な式には、「インスツルメント」（不連続イベントに関連づけられるインスツルメントを提供する）、「約定価格」（不連続イベントに関連づけられる約定価格を提供する）、「約定数量」（不連続イベントに関連づけられる約定数量を提供する）、「注文数量」（不連続イベントに関連づけられる注文数量を提供する）、「注文価格」（不連続イベントに関連づけられる注文価格を提供する）、「実行数量」（注文数量に関連する約定の累算を提供する）、「受付中の数量」（特定の注文価格における実行されない注文数量の累算を提供する）、「取引数量」（ある取引所で実行される取引の数量を提供する）、「取引価格」（ある取引所で実行される取引の価格を提供する）および「変数」（指定されたユーザ定義変数の値、またはアルゴリズムにおける、仮想化されたグループブロックの一部ではない他の任意のブロック出力の値を提供する）が含まれてもよい。
【０１７５】
ブランチブロックは、不連続入力において不連続イベントを受信しかつ条件文を評価してもよい。条件文が「真」であれば、不連続イベントは第１の不連続出力（「はい」経路）において提供され、条件文が「偽」であれば、不連続イベントは第２の不連続出力（「いいえ」経路）において提供される。条件文は、連続式ブール入力において提供されてもよい。あるいは、条件文は、ブール値を評価する指定されたユーザ定義の方程式によって提供されてもよい。指定された方程式は、アルゴリズムを設計する間に、ユーザにより、例えば、ブランチブロックを選択しかつ方程式を入力すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。方程式は、テキスト通りに、または例えば、先に論じたビルディング・ブロック・ボタン２１５に類似するビルディング・ブロック・ボタンを用いて入力されてもよい。ブランチブロックは、例えば、不連続イベントが買いの約定イベントであるか、売りの約定イベントであるかを評価するために用いられてもよい。このような方程式を構築するためには、「買い？」ビルディング・ブロック・ボタンが用いられてもよい。方程式（ビルディング・ブロック・ボタンによって提供され得る）を指定する際に使用すべく利用可能である他の式には、「インスツルメント」（不連続イベントに関連づけられるインスツルメントを提供する）、「約定価格」（不連続イベントに関連づけられる約定価格を提供する）、「約定数量」（不連続イベントに関連づけられる約定数量を提供する）、「注文数量」（不連続イベントに関連づけられる注文数量を提供する）、「注文価格」（不連続イベントに関連づけられる注文価格を提供する）、「実行数量」（注文数量に関連する約定の累算を提供する）、「受付中の数量」（特定の注文価格における実行されない注文数量の累算を提供する）、「取引数量」（ある取引所で実行される取引の数量を提供する）、「取引価格」（ある取引所で実行される取引の価格を提供する）および「変数」（指定されたユーザ定義変数の値、またはアルゴリズムにおける、仮想化されたグループブロックの一部ではない他の任意のブロック出力の値を提供する）が含まれてもよい。
【０１７６】
マルチプレクサブロックは、不連続入力において不連続イベントを受信し、かつこの不連続イベントを特定の不連続出力において提供してもよい。例えば、マルチプレクサブロックは、注文ハンドラブロックから不連続イベントを受信し、この不連続イベントのタイプ（例えば、約定、変更または削除）を基礎としてこれをマルチプレクサブロックの適切な不連続出力において提供してもよい。配置されると、ユーザは、どの不連続イベントタイプに関して出力が提供されるかを指定するようにプロンプトされてもよい。あるいは、マルチプレクサブロックは、あらゆる不連続イベントタイプに関して出力を提供する規定の設定へデフォルトしてもよい。出力が提供される指定された不連続イベントタイプは、アルゴリズムを設計する間に、ユーザにより、例えば、マルチプレクサブロックを選択しかつ不連続イベントタイプを指定すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。マルチプレクサブロックは、例えば、注文を管理するために注文ハンドラブロックと共に用いられてもよい。
【０１７７】
ファンネルブロックは、２つ以上の不連続入力において不連続イベントを受信し、かつこれらを単一の不連続出力において提供してもよい。ファンネルブロックは不連続イベントを保持せず、出力へと通過させる。ファンネルブロックは、例えば、複数の入力を必要とする状態ブロックと共に用いられてもよい。
【０１７８】
シーケンサブロックは、不連続イベントが出力を通過する注文を保証してもよい。シーケンサブロックは、１つの不連続入力と、２つ以上の不連続出力とを有してもよい。入力において不連続イベントが受信されると、シーケンサブロックは、この不連続イベントを各出力へ順番に提供する。即ち、受信された不連続イベントの処理において、シーケンサブロックは、まずこの不連続イベントを第１の出力へ提供し、次にはこの不連続イベントが第２の出力、等々へ提供されていく。これにより、ユーザは、アルゴリズムにおいて不連続入力を受信するどの注文ブロックが更新されるかを正確に決定できる場合がある。しかしながら、シーケンサブロックの同じ不連続出力へ複数のブロックが接続されていれば、これらのブロックが不連続イベントを受信する順番は指定されない。このブロックは、シーケンスブロックと称される場合もある。
【０１７９】
不連続最小ブロックは、２つの不連続入力を比較し、かつ指定された属性（例えば、取引価格、取引数量、他）の最小値の連続式数値出力を提供してもよい。一方の入力において不連続イベントが受信されると、このイベントから指定された属性値が抽出されかつ格納される。抽出された値は、他の不連続入力に関して最近に格納された値と比較されてどちらが小値であるかが決定され、その値が連続式数値出力において提供される。一方の入力で不連続イベントが受信されていなければ、他方の入力から抽出される値が常により大きい値として取り扱われてもよい。代替例として、特定の不連続入力の値は、単に０へデフォルトしてもよい。不連続最小ブロックはパススルー・ブロックであってもよく、よって受信される各不連続イベントは対応する不連続出力を介して出される。不連続最小ブロックは、イベントを受信すると、各不連続入力に関して格納された値をリセットしかつ相応して最小出力を更新するリセット不連続入力を含んでもよい。
【０１８０】
不連続最大ブロックは、２つの不連続入力を比較し、かつ指定された属性（例えば、取引価格、取引数量、他）の最大値の連続式数値出力を提供してもよい。一方の入力において不連続イベントが受信されると、このイベントから指定された属性値が抽出されかつ格納される。抽出された値は、他の不連続入力に関して最近に格納された値と比較されてどちらがより大きい値であるかが決定され、その値が連続式数値出力において提供される。一方の入力で不連続イベントが受信されていなければ、他方の入力から抽出される値が常により大きい値として取り扱われてもよい。代替例として、特定の不連続入力の値は、単に０へデフォルトしてもよい。不連続最大ブロックはパススルー・ブロックであってもよく、よって受信される各不連続イベントは対応する不連続出力を介して出される。不連続最大ブロックは、イベントを受信すると、各不連続入力に関して格納された値をリセットしかつ相応して最大出力を更新するリセット不連続入力を含んでもよい。
【０１８１】
その他のブロックには、例えば、最小、最大、丸め、１０進表示、ｎｏｔ、一度真、数字である、移動平均、条件付きｆ（ｘ）、数値ｆ（ｘ）、平均、タイマ、注記、乱数、平方根、対数および休止の各ブロックが含まれてもよい。
【０１８２】
最小ブロックは、２つの連続式数値入力を比較してどちらが小値であるかを決定し、かつこれを出力してもよい。最小ブロックは、真ん中にテキスト「ＭＩＮ」、左側に２つの連続式数値入力および右側に１つの連続式数値出力を備える三角形状を有してもよい。
【０１８３】
最大ブロックは、２つの連続式数値入力を比較してどちらがより大きい値であるかを決定し、かつこれを出力してもよい。最大ブロックは、真ん中にテキスト「ＭＡＸ」、左側に２つの連続式数値入力および右側に１つの連続式数値出力を備える三角形状を有してもよい。
【０１８４】
丸めブロックは、連続式数値入力によって提供される数字を連続式数値入力によって提供される最近の増分へと丸め、１つの連続式数値出力を生成してもよい。増分値が提供されていなければ、丸めブロックは最近の整数へ丸めてもよい。さらに、ユーザは、丸めブロックの３つのオプション、即ち正規丸め、常に切り上げ、および常に切り捨て、の中から１つを指定してもよい。正規丸めは、伝統的な丸め規則を使用する（例えば、０．５は１に切り上げられ、０．４９は０に切り捨てられる）。常に切り上げは、２つの増分間に存在する値をより高位の増分へと丸める（例えば、２．１は３に切り上げられ、２は２に丸められる）。常に切り捨ては、２つの増分間に存在する値をより低位の増分へと丸める（例えば、２．９は２に切り捨てられ、２は２に丸められる）。どのオプションも指定されなければ、丸めブロックは、例えば正規丸めへデフォルトしてもよい。丸めブロックは、真ん中にテキスト「丸め」、左側に２つの連続式数値入力および右側に１つの連続式数値出力を備える矩形形状を有してもよい。
【０１８５】
１０進表示ブロックは、連続式数値入力によって提供される数字および連続式インスツルメント入力によって提供されるインスツルメントを用いて１０進形式の数字を出力してもよい。例えば、１０進表示ブロックは、ユーザが、数字ブロックを用いて価格等の値をアルゴリズムの他の部分へ、その値を１０進形式で計算する必要なしに（恐らくは変数として）供給することを希望する場合に利用されてもよい。ユーザは、インスツルメントＺＮの価格が１１７１２５となっているのを見慣れているかもしれないが、これは、価格１１７および１２．５／３２ｎｄｓを表現している場合がある。１１７１２５は、１０進表示ブロックによってインスツルメントと共に入力として提供されてもよく、１０進表示ブロックはこの数字を、アルゴリズムの残りの部分が使用する適切な１０進フォーマット値（ここでは、１１７．３９０６２５）へ変換する。１０進表示ブロックは、真ん中にテキスト「Ｄ２Ｄｅｃ」、左側に１つの連続式インスツルメント入力および１つの連続式数値入力および右側に１つの連続式数値出力を備える矩形形状を有してもよい。
【０１８６】
ＮＯＴブロックは、入力値が「真」であれば出力は「偽」であり、かつ入力値が「偽」であれば出力は「真」であるように、連続式ブール入力の論理否定を実行してもよい。ＮＯＴブロックは、真ん中に否定記号（「！」または「−」）、左側に１つの連続式ブール入力および右側に１つの連続式ブール出力を備える、左側が矩形で右側がアーチ形の形状を有してもよい。
【０１８７】
一度真ブロックは、連続式ブール入力が「真」になると、アルゴリズムの寿命に渡って「真」の連続式ブール出力を提供してもよい。入力値が少なくとも一度「真」になるまでは、一度真ブロックの出力値は「偽」である。一旦、入力値が「真」になれば、一度真ブロックは、その後入力値が変わったとしても、常に値「真」を出力する。一度真ブロックは、真ん中にテキスト「Ｔ」、左側に１つの連続式ブール入力および右側に１つの連続式ブール出力を備える、左側が矩形で右側がアーチ形の形状を有してもよい。このブロックは、「一度真なら常に真」ブロックと称される場合もある。
【０１８８】
「数字である」ブロックは、連続式数値入力において提供される値が数字であれば「真」の連続式ブール出力を提供し、かつ提供される値が「非数」（ＮａＮ）であれば「偽」を出力してもよい。「数字である」ブロックは、真ん中にテキスト「ＩｓＮｕｍ？」、左側に１つの連続式数値入力および右側に１つの連続式ブール出力を備える、左側が矩形で右側がアーチ形の形状を有してもよい。
【０１８９】
移動平均ブロックは、連続式数値入力としてデータ値（価格または数量等、経時変化している場合がある）を、かつ連続式数値入力として分数値を採用し、かつ連続式数値出力として指定された分数に渡る移動平均を提供してもよい。移動平均ブロックは、データ値を毎秒記録してもよい。例えば、ユーザが１分間の移動平均を得ることを希望すれば、移動平均ブロックは６０個のデータポイントを記録し、これらを平均して出力する。また、移動平均ブロックは、入力されたデータ値が有効かどうかを表示する連続式ブール値を採用してもよい。この入力はオプションであり、「真」へデフォルトする。データ値が（１秒に一度のデフォルトによって）記録される予定であれば、移動平均ブロックは、その有効な入力が「真」であるかどうかを確認するチェックを行う。「真」であれば、データ値はデータポイントとして記録される。有効な入力が「偽」であれば、データ値はデータポイントとして記録されない。また、移動平均ブロックは、リセット入力である不連続入力を採用する場合もある。リセット入力によって不連続イベントが受信されると、記録されたデータポイントは放棄される。これにより、出力される移動平均は、記録されるデータ値に依存して結果的に０または「非数」（ＮａＮ）になる。また、移動平均ブロックは、移動平均を完全に計算するに足る数のデータポイントが記録されているかどうかを表示するＯＫの連続式ブール出力を提供する場合もある。ＯＫの出力は、必要とされる数のデータポイントが記録されるまでは「偽」であり、それ以後（リセットまで）は「真」である。例えば、入力される分数が値２０を提供すれば（２０分間の移動平均）、ＯＫ出力が「真」になるまでに１２００個のデータポイント（毎秒１データポイントで２０分間）が記録される必要がある。また、移動平均ブロックは、記録されているデータポイント数を表示するデータポイント数連続式数値出力を提供する場合もある。移動平均ブロックは、真ん中にテキスト「ＭｖｇＡｖｇ」、左側に４つの入力（２つの連続式数値入力、１つの連続式ブール入力および１つの不連続入力）および右側に３つの出力（２つの連続式数値出力および１つの連続式ブール出力）を備える矩形形状を有してもよい。
【０１９０】
条件付きｆ（ｘ）ブロックは、連続式ブール出力の値を提供するユーザ定義の方程式を評価してもよい。配置されると、ユーザは、評価されるべき方程式を入力するようにプロンプトされてもよい。あるいは、条件付きｆ（ｘ）ブロックは、「真」等の既定値へデフォルトしてもよい。指定された方程式は、アルゴリズムを設計する間に、ユーザにより、例えば、条件付きｆ（ｘ）ブロックを選択しかつ方程式を入力すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。方程式は、テキスト通りに、または例えば、先に論じたビルディング・ブロック・ボタン２１５に類似するビルディング・ブロック・ボタンを用いて入力されてもよい。所定の実施形態において、条件付きｆ（ｘ）ブロックは、別のブロックの出力からの値を参照してもよい。値は、ブロックおよび出力を指定するビルディング・ブロック・ボタン２１５を用いて参照される場合もあれば、条件付きｆ（ｘ）ブロックの連続式変数入力へ提供される場合もある。条件付きｆ（ｘ）ブロックは、真ん中にテキスト「ｆ（ｘ）」を有し、左側に入力がなく（値がユーザ定義の方程式において参照されない場合。この場合、各変数に対応する連続式入力が提供される）、右側に１つの連続式ブール出力を備えて、左側に矩形形状、および右側にアーチ形を有してもよい。
【０１９１】
数値ｆ（ｘ）ブロックは、連続式数値出力の値を提供するユーザ定義の方程式を評価してもよい。配置されると、ユーザは、評価されるべき方程式を入力するようにプロンプトされてもよい。あるいは、数値ｆ（ｘ）ブロックは、０等の既定値へデフォルトしてもよい。指定された方程式は、アルゴリズムを設計する間に、ユーザにより、例えば、数値ｆ（ｘ）ブロックを選択しかつ方程式を入力すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。方程式は、テキスト通りに、または例えば、先に論じたビルディング・ブロック・ボタン２１５に類似するビルディング・ブロック・ボタンを用いて入力されてもよい。所定の実施形態において、数値ｆ（ｘ）ブロックは、別のブロックの出力からの値を参照してもよい。値は、ブロックおよび出力を指定するビルディング・ブロック・ボタン２１５を用いて参照される場合もあれば、数値ｆ（ｘ）ブロックの連続式変数入力へ提供される場合もある。数値ｆ（ｘ）ブロックは、真ん中にテキスト「ｆ（ｘ）」を有し、左側に入力がなく（値がユーザ定義の方程式において参照されない場合。この場合、各変数に対応する連続式入力が提供される）、右側に１つの連続式数値出力を備えて、左側に矩形形状、および右側にアーチ形を有してもよい。
【０１９２】
所定の実施形態において、条件付きｆ（ｘ）ブロックおよび数値ｆ（ｘ）ブロックは、ｆ（ｘ）ブロック等の単一ブロックに合併されてもよい。ｆ（ｘ）ブロックは、連続式変数出力のブール値または数値の何れかを提供するユーザ定義の方程式を評価してもよい。配置されると、ユーザは、評価されるべき方程式を入力するようにプロンプトされてもよい。あるいは、ｆ（ｘ）ブロックは、０等の既定値へデフォルトしてもよい。指定された方程式は、アルゴリズムを設計する間に、ユーザにより、例えば、ｆ（ｘ）ブロックを選択しかつ方程式を入力すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。方程式は、テキスト通りに、または例えば、先に論じたビルディング・ブロック・ボタン２１５に類似するビルディング・ブロック・ボタンを用いて入力されてもよい。所定の実施形態において、ｆ（ｘ）ブロックは、別のブロックの出力からの値を参照してもよい。値は、ブロックおよび出力を指定するビルディング・ブロック・ボタン２１５を用いて参照される場合もあれば、ｆ（ｘ）ブロックの連続式変数入力へ提供される場合もある。ｆ（ｘ）ブロックは、真ん中にテキスト「ｆ（ｘ）」を有し、左側に入力がなく（値がユーザ定義の方程式において参照されない場合。この場合、各変数に対応する連続式入力が提供される）、右側に１つの連続式変数出力を備えて、左側に矩形形状、および右側にアーチ形を有してもよい。
【０１９３】
平均ブロックは、２つ以上の連続式数値入力の値を平均して１つの連続式数値出力を生成してもよい。例えば、平均ブロックは１０個の入力を有してもよい。別の例として、平均ブロックは１つの入力によって始まってもよく、かつ平均ブロック入力へ接続が行われる度に新たな入力が動的に提供されてもよい。入力の値は合計され、次に、値を提供する入力数で除算されて出力が提供される。平均ブロックは、真ん中にテキスト「ＡＶＥ」または「ＡＶＧ」、左側に２つ以上の連続式数値入力および右側に１つの連続式数値出力を備える矩形形状を有してもよい。
【０１９４】
タイマブロックは、時間、分および秒という時間の連続式数値出力を提供してもよい。例えば、タイムはカレントタイムであってもよい。カレント時間は、例えば、ユーザへ取引インタフェースを提供するコンピューティングデバイスにおける時間であっても、アルゴリズムサーバにおけるカレント時間であってもよい。別の例として、この時間は、アルゴリズムが実行を開始された時点からであってもよい。別の例として、この時間は、カレント取引セッションの開始以降の時間であってもよい。別の例として、この時間は、カレント取引セッションの１２ａｍＣＳＴからの時間であってもよい。別の例として、この時間は取引所によって提供される時間であってもよい。タイマブロックは、真ん中にテキスト「ＴＩＭＥＲ」またはクロック記号、および右側に３つの連続式数値出力を備える矩形形状を有してもよい。
【０１９５】
注記ブロックは、ユーザが設計されているアルゴリズムに関してコメントおよび注記を入力するためのテキストボックスを提供してもよい。注記ブロックは、入力または出力を持たなくてもよい。配置されると、ユーザは、注記ブロックにテキストを入力するようにプロンプトされてもよい。あるいは、注記ブロックは、「ここへ注記を追加」等の既定値へデフォルトしてもよい。指定された値は、アルゴリズムを設計する間に、ユーザにより、例えば、注記ブロックを選択しかつ値を入力すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。注記ブロックは、アルゴリズムの動作に影響を与えない。注記ブロックは、真ん中にテキスト値が表示される矩形形状を有してもよい。
【０１９６】
乱数ブロックは、連続式数値出力へ乱数を提供してもよい。乱数は、乱数ブロックが配置される、または後に設定される際に、整数または浮動小数点値であるように指定されてもよい。乱数ブロックは、整数値を提供することへデフォルトしてもよい。乱数は、連続式数値入力によって指定される最小値と、連続式数値入力によって指定される最大値との間であってもよい。最小入力が提供されていなければ、これは、例えば０へデフォルトしてもよい。最大入力が提供されていなければ、これは、整数出力に関してはコンピューティングデバイスによってサポートされる最大整数へ、または浮動小数点出力に関しては１へデフォルトしてもよい。また、乱数ブロックは、新たな乱数が提供されるべき時点をシグナリングするための不連続入力も有する場合がある。不連続入力が提供されていなければ、乱数ブロックは、例えば１秒毎に新たな乱数を提供してもよい。乱数ブロックはパススルー・ブロックであってもよく、よって受信される各不連続イベントは対応する不連続出力を介して出される。乱数ブロックは、真ん中に疑問符記号（「？」）またはテキスト（ＲＡＮＤ）、左側に２つの連続式数値入力および１つの不連続入力および右側に１つの連続式数値出力を備える正方形形状を有してもよい。
【０１９７】
平方根ブロックは、連続式数値入力において提供される値に関して、連続式数値出力において平方根値を提供してもよい。入力が負数であれば、出力は「非数」（ＮａＮ）であってもよい。平方根ブロックは、真ん中に平方根記号
0005485405.tif 000002
左側に１つの連続式数値入力および右側に１つの連続式数値出力を備える三角形状を有してもよい。
【０１９８】
対数ブロックは、連続式数値入力において提供される値に関して、連続式数値出力において対数値を提供してもよい。対数の底の値は、連続式数値入力において提供されてもよい。底の値が提供されていなければ、これは、例えば自然対数へデフォルトしてもよい。対数ブロックは、真ん中にテキスト「対数」、左側に２つの連続式数値入力および右側に１つの連続式数値出力を備える正方形形状を有してもよい。
【０１９９】
休止ブロックは、不連続入力において不連続イベントが受信されると、または連続式ブール入力において提供される値が「真」になると、アルゴリズム全体を休止してもよい。所定の実施形態では、ブール入力値が再び「偽」になれば、アルゴリズムは実行を再開してもよい。所定の実施形態では、アルゴリズムは、休止ブロックに起因して一旦休止されると、手動で再開されなければならない。休止ブロックは、背景が赤で真ん中にテキスト「停止」、左側に１つの連続式ブール入力および１つの不連続入力を備える八角形状であってもよい。
【０２００】
アルゴリズムを表現する命令または論理（本明細書ではプログラミングコードと称される）は、アルゴリズムの定義を基礎として生成される。所定の実施形態において、プログラミングコードは、続いてコンパイルされ得るソースコード（人間および／またはコンパイラによって読取り可能なテキスト）である。所定の実施形態において、プログラミングコードの言語は中間言語である。所定の実施形態において、プログラミングコードは機械実行可能命令を含む。所定の実施形態において、プログラミングコードの生成は、生成されたソースコードおよび／または中間言語コードのコンパイルを含む。所定の実施形態では、プログラミングコードの生成は生成されたソースコードおよび／または中間言語コードのコンパイルを含まず、このようなコンパイルは別個のプロセスである。
次に、（コンパイルの後、適切であれば）生成されたプログラミングコードは、定義されたアルゴリズムに従って取引するためにシミュレートされ、かつ／または使用されてもよい。本明細書において、プログラミングコードが実行され、遂行されかつ／またはシミュレートされるべく論考される場合、生成されたプログラミングコードは、実行され、遂行されかつ／またはシミュレートされることが適切であれば追加的なコンパイルを行われているものと想定されている。
【０２０１】
所定の実施形態において、プログラミングコードは、アルゴリズムが設計されるにつれて生成される。アルゴリズムが設計される間、アルゴリズムの定義は、ブロックおよび／または接続が追加され、修正されかつ／または除去されるにつれて変化していく場合があることに留意されたい。所定の実施形態において、プログラミングコードは、アルゴリズムの定義が変更される際に自動的に生成される。所定の実施形態において、プログラミングコードはユーザが要求する時点で生成される。
【０２０２】
所定の実施形態において、プログラミングコードは、クライアントデバイスにおいて取引インタフェース３１０のアルゴリズム取引アプリケーションのコンポーネントによって生成される。所定の実施形態において、プログラミングコードは、例えば、アルゴリズム生成デバイス、先に述べたアルゴリズムサーバ３０２に類似するアルゴリズムサーバおよび／または先に述べたゲートウェイ１２０に類似するゲートウェイ等の別のデバイスにおいて、アルゴリズム取引アプリケーションのコンポーネントによって生成される。所定の実施形態において、プログラミングコードは２つ以上のコンポーネントによって生成される。例えば、アルゴリズム取引アプリケーションの複数のコンポーネントは、コードを生成するために互いに機能してもよい。このようなコンポーネントは、例えば、プログラミングコードの異なる態様または機能を生成するように特化されてもよい。
【０２０３】
所定の実施形態において、プログラミングコードは２つ以上のデバイスによって生成される。例えば、プログラミングコードは、クライアントデバイスおよびアルゴリズムサーバによって生成されてもよい。アルゴリズムの定義を基礎として生成されるプログラミングコードは、どのコンポーネントまたはデバイスがこれを生成しているかに基づいて異なってもよい。例えば、クライアントデバイスにおいて生成されるプログラミングコードは、クライアントデバイスによる実行に合わせて最適化される場合があり、かつ／またはアルゴリズムサーバにおいて生成されるプログラミングコード（例えば、ユーザインタフェース関連機能を含まない場合がある）とは異なる機能（例えば、ユーザインタフェース関連機能）を含む場合がある。明確を期して、別段の指摘のない限り、以下の論考はクライアントデバイスにおけるプログラミングコードの生成に関して行うが、アルゴリズムサーバ等の別のデバイスにおいてプログラミングコードが生成される場合でも同様の措置が講じられることは理解されるべきである。
【０２０４】
所定の実施形態において、プログラミングコードは、Ｃ＃および．ＮＥＴ４．０フレームワーク等のプログラミング言語を用いてオブジェクト指向的に生成される。
【０２０５】
所定の実施形態において、プログラミングコードは、アルゴリズム定義における各ブロックおよび接続をトラバースすることによって生成される。プログラミングコードは、ブロック毎に生成される。プログラミングコードの生成に際しては、幾つかのブロックが原始変数になる場合がある。例えば、加算器ブロックは、その値が加算器ブロックの入力へ接続される出力の値の合計であるように設定される浮動小数点変数になる場合があり、前記合計は再帰的に決定されてもよい。さらに複雑な機能を有し得る他のブロックは、ベースクラスから導出されるサブクラスとして生成されてもよい。ベースクラスは、対応するブロックに関連づけられるコア機能を提供してもよい。生成されたサブクラスは、次に、プログラミングコードが生成されつつあるブロックに固有の値をベースクラスのコア機能へ提供するために、戻り値を有する仮想方法をオーバーライドしてもよい。例えば、設計キャンバスエリア３１１内に配置されるマーケットメーカ・ブロックは、ベース・マーケット・メーカ・クラスのサブクラスである生成されたプログラミングコードを有してもよい。サブクラスは、マーケットメーカ・ブロックの様々な入力に値を得るために、かつマーケットメーカ・ブロックが買いのために設定されたか、売りのために設定されたかを指定するために、仮想方法をオーバーライドしてもよい。先に論じた基本ブロックとは異なり、マーケットメーカ・ブロックは、より複雑な機能を提供する取引ブロックである。
【０２０６】
ブロック間の連続式接続は、接続される出力値と入力値とがどのように関係するかを指定する。上述の加算器の例を続けると、加算器ブロックの出力を表す浮動小数点値は、加算器ブロックの連続式入力へ接続される他の原始変数（他のブロック／出力を表す）の値の合計であるように設定されてもよい。所定の実施形態では、連続式接続を有する複数のブロック（原始変数を生成する）が複数の中間媒介変数を用いることなく１つの式へ凝縮され得るように、生成されたプログラミングコードが連続式接続を用いて扁平にされてもよい。
【０２０７】
ブロック間の不連続接続は、不連続イベントが生成されると適切な方法（ハンドラ）が呼び出されるように、イベント発生器およびイベントハンドラを生成するために用いられる。不連続イベントは、イベント発生器からイベントハンドラへ送られて処理される。
【０２０８】
実行に際して、アルゴリズムは、アルゴリズムの状態を変えさせるアクションに応答する。アクションには、市場イベント（例えば、価格更新、数量更新、注文確認、取引確認、約定確認または取引通知）等の外部イベントおよびタイマイベント（例えば、システムのクロックまたはアラームからの）が含まれてもよい。これらの外部イベントにより、結果的に、注文確認不連続イベント、取引確認不連続イベント、約定確認不連続イベントまたは取引通知不連続イベント等の不連続イベントが生成され、かつ／またはインスツルメントの価格値または数量値等の連続値が更新される場合がある。また、アクションには、アルゴリズム内のブロックまたは変化する連続値によって生成される不連続イベント等の内部イベントも含まれる場合がある。
【０２０９】
内部または外部不連続イベントが発生する（例えば、取引確認不連続イベントまたは発生器ブロックが不連続イベントを発生する）場合、アルゴリズム内の各関連ブロックは、そのブロックがイベントに関連づけられるその特化された機能を実行し得るようにイベントハンドラ方法を呼び出している。イベントハンドラは、不特定の順序で評価されてもよい。例えば、イベントハンドラは、アルゴリズム定義においてその個々のブロックが置かれている順番を基礎として評価されてもよい。イベントハンドラによる処理は、受信されるイベントを基礎としてブロックの機能を実行すること、連続式出力値を更新すること、および不連続イベントを発生してそれを接続された他のブロックへの出力へ提供することを含んでもよい。
【０２１０】
内部または外部連続値が変わる（例えば、市場データが更新される、またはシステムクロックの時間が変わる）場合、データソースに直接または間接的に接続される各関連ブロック（下流ブロック）は、新たなデータを反映してその値を更新している。幾つかのブロックの結果である原始変数は、例えば、新たな値を割り当てられる。
【０２１１】
連続式出力値が不連続イベントまたは連続値変化の何れかによって更新されれば、更新値を受信するために直接または間接的に接続される各ブロックが処理されるべきブロックのリストに追加される。外部イベントに関与しているブロックがその処理を完了すると、ブロックのリストは、これらのブロックが次には内部イベントに応答して行動し得るように処理される。内部イベントは、外部イベントと同様にして処理される。この処理は、次に、各ブロックの処理がアルゴリズムの状態に新たな変化を生み出すにつれて反復されてもよい。
【０２１２】
図３Ｄ−１から図３Ｄ−７は、所定の実施形態によって生成されるプログラミングコードの例を示す。図示されているプログラミングコードは、生成され得るプログラミングコードの単なる一部でありかつ例示を目的とするものであり、よって明確を期して所定の機能を強調するために単純化されていることに留意されたい。
【０２１３】
プログラミングコードは、図３Ｄ−１に示されているように、設計キャンバスエリア３１１にブロックが配置されていない場合でも生成される場合がある。生成されるプログラミングコードは、設計中のアルゴリズムを表す新たなクラス（「ＣｕｓｔｏｍＡｌｇｏｒｉｔｈｍ０」）を含む。この新たなクラスはアルゴリズムクラスのサブクラスであり、アルゴリズム取引アプリケーションを有するアルゴリズムを実行するための基本的なインタフェースおよび機能を提供する。ＣｕｓｔｏｍＡｌｇｏｒｉｔｈｍ０クラスは、設計中のアルゴリズムに固有の機能がアルゴリズム取引アプリケーションのフレームワークに組み込まれかつ実行され得るように、このアルゴリズムクラスの仮想方法をオーバーライドしてもよい。
【０２１４】
本例の説明を続けると、図３Ｄ−２に示されているように、設計キャンバスエリア３１１にブロックが配置されると、追加的なプログラミングコードが生成されてもよい。先に論じたように、幾つかのブロックは原始変数となる場合があり、これらの間の連続式接続は、これらがどのように関連しているかを表している。例えば、図示されているように、設計キャンバスエリア３１１には２つの定数ブロック（「ＣｏｎｓｔａｎｔＮｕｍｂｅｒＢｌｏｃｋ０」および「ＣｏｎｓｔａｎｔＮｕｍｂｅｒＢｌｏｃｋ１」）ならびに加算器ブロック（「ＡｄｄｅｒＢｌｏｃｋ０」）が配置されている。ブロック同士は、接続されていないことに留意されたい。生成されたプログラミングコードのマーキングされている部分は、これらの基本ブロックがプログラミングコードにおいて（「ダブル」タイプの）原始変数として表現されることを示す。
【０２１５】
図３Ｄ−３に示されているように、接続はＣｏｎｓｔａｎｔＮｕｍｂｅｒＢｌｏｃｋ０およびＣｏｎｓｔａｎｔＮｕｍｂｅｒＢｌｏｃｋ１からＡｄｄｅｒＢｌｏｃｋ０へ行われている。接続は、これらのブロック間の関係性を明示する。生成されたプログラミングコードのマーキングされている部分は、ＡｄｄｅｒＢｌｏｃｋ０の値がＣｏｎｓｔａｎｔＮｕｍｂｅｒＢｌｏｃｋ０の値とＣｏｎｓｔａｎｔＮｕｍｂｅｒＢｌｏｃｋ１の値との和に等しいことを示す。これは、加算器ブロックによって表される機能が２つの入力の値を加算することにあるためである。
【０２１６】
図３Ｄ−４に示されているように、設計キャンバスエリア３１１にマーケットメーカ・ブロックが配置されている。先に論じた基本ブロックとは異なり、マーケットメーカ・ブロックは、より複雑な機能を提供する取引ブロックである。生成されるプログラミングコードは、配置されている特定のマーケットメーカ・ブロックの機能を表す新たなクラス（「ＣｕｓｔｏｍＭａｒｋｅｔＭａｋｅｒ０」）を追加する。ＣｕｓｔｏｍＭａｒｋｅｔＭａｋｅｒ０はＭａｒｋｅｔＭａｋｅｒのサブクラスであり、マーケットメーカ・ブロックの基本機能を提供する。ＣｕｓｔｏｍＭａｒｋｅｔＭａｋｅｒ０クラスは、配置されたマーケットメーカ・ブロックに固有の機能がアルゴリズム取引アプリケーションのフレームワークに組み込まれかつ実行され得るように、ＭａｒｋｅｔＭａｋｅｒクラスの戻りタイプを有する仮想方法をオーバーライドしてもよい。この場合、ＣｕｓｔｏｍＭａｒｋｅｔＭａｋｅｒ０は、ＭａｒｋｅｔＭａｋｅｒベースクラスにおける論理によって呼び出される方法をオーバーライドして、マーケットメーカ・ブロックの様々な入力の値を取得する。図３Ｄ−５に示されているように、配置されたマーケットメーカ・ブロックの数量入力は、先に論じた加算器ブロックの出力へ接続されている。生成されたプログラミングコードのマーキングされている部分は、ＣｕｓｔｏｍＭａｒｋｅｔＭａｋｅｒ０クラスの仮想方法「ＧｅｔＱｔｙ」がＡｄｄｅｒＢｌｏｃｋ０の値を戻すためにオーバーライドされていることを示す。
【０２１７】
本例の説明を続けると、図３Ｄ−６に示されているように、不連続出力と不連続入力との間に接続が行われている。具体的には、接続は、マーケットメーカ・ブロックの不連続約定出力と、値積算器ブロックのリセット入力との間で行われた。値積算器ブロックは不連続ブロックであり、取引ブロックと同様に新たなクラス（「ＣｕｓｔｏｍＶａｌｕｅＡｃｃｕｍｕｌａｔｏｒ０」）が追加されている（不図示）。生成されたプログラミングコードのマーキングされている部分は、新たなサブクラス（「ＣｕｓｔｏｍＭａｒｋｅｔＭａｋｅｒ０」および「ＣｕｓｔｏｍＶａｌｕｅＡｃｃｕｍｕｌａｔｏｒ０」）がインスタンス化されること、およびＭａｒｋｅｔＭａｋｅｒＢｌｏｃｋ０のイベント「ＤｉｓｃｒｅｔｅＯｂｊｅｃｔＧｅｎｅｒａｔｅｄ」がＣｕｓｔｏｍＡｌｇｏｒｉｔｈｍ０（「ＩｎｔｅｒｃｅｐｔＯｒｄｅｒＭｅｓｓａｇｅ」）およびＶａｌｕｅＡｃｃｕｍｕｌａｔｏｒＢｌｏｃｋ０（「ＰｒｏｃｅｓｓＲｅｓｅｔＭｅｓｓａｇｅ」）のイベントハンドラと連結されることを示す。したがって、ＭａｒｋｅｔＭａｋｅｒＢｌｏｃｋ０が約定メッセージを有していれば、これがＤｉｓｃｒｅｔｅＯｂｊｅｃｔＧｅｎｅｒａｔｅｄイベントをファイアし、連結されている全てのハンドラに通知される。この場合、ＰｒｏｃｅｓｓＲｅｓｅｔＭｅｓｓａｇｅハンドラに通知が届けば、これは積算器の値を０にリセットする。
【０２１８】
本例の説明を続けると、図３Ｄ−７に示されているように、インスツルメントブロック（「ＳｉｍｐｌｅＩｎｓｔｒｕｍｅｎｔＢｌｏｃｋ０」）とインスツルメント属性ブロック（「ＩｎｓｔｒｕｍｅｎｔＦｉｅｌｄＢｌｏｃｋ０」）との間に接続が行われている。インスツルメントブロックは、インスツルメント「ＥＳＺ０」に関して受信される市場データを基礎としてその連続式出力を更新する「ＩｎｓｔｒｕｍｅｎｔＳｎａｐｓｈｏｔ」クラスのインスタンスであるように生成される。ＩｎｓｔｒｕｍｅｎｔＳｎａｐｓｈｏｔクラスは、インスツルメントのその属性の対応値を得るために参照され得る会員変数または特性を提供する。例えば、「ＳｅｔＡｌｌＶａｒｉａｂｌｅｓ」（アルゴリズム内の全ての値を設定する）または「ＨａｎｄｌｅＵｐｄａｔｅ」（特定の連続値の更新によって影響される値を設定する）が呼び出されると、インスツルメント属性ブロックは、その値をインスツルメントブロックの「．Ｂｉｄ」特性となるように設定する。
【０２１９】
図３Ｅは、所定の実施形態による取引インタフェース３１０を示す。所定のブロックは、「変数」であるように指定されてもよい。例えば、定数ブロック、定数ブールブロックおよびインスツルメントブロックは変数であるように指定されてもよい。
【０２２０】
変数エリア３１３は、変数ブロックの修正に備える。変数エリア３１３は、各変数のブロック名およびそのデフォルト値を表示する。変数エリアは、変数のブロック名および／またはそのデフォルト値を変更するために選択されてもよい。変数は、アルゴリズムのパラメータと称される場合もある。
【０２２１】
図示されているように、設計キャンバスエリア３１１は、変数として指定されている２つのブロック、即ちインスツルメントブロック３２１および定数ブロック３２２を含む。ブロックは、例えば、配置される際に、または配置された後に変数として指定されてもよい。例えば、ブロックはカーソルを用いて選択されてもよく、次に、変数にされるべきブロックを指定するためにメニュオプションが選択されてもよい。変数として指定されたブロックは、例えば、異なる色、縁、背景、パターンおよび／またはテキストによって示されてもよい。本図では、表示されたブロック名にテキスト「Ｖａｒｉａｂｌｅ」が付加されている。
【０２２２】
先に論じたように、変数エリア３１３は、変数ブロック３２１および３２２毎に入力を有する名前カラム３２３と、変数ブロック毎に対応するデフォルト値入力を有するデフォルト値カラム３２４とを含む。例えば、インスツルメントブロック３２１は「ＩｎｓｔｒｕｍｅｎｔＢｌｏｃｋ０」と名付けられてデフォルト値「ＥＳＺ０」を有し、かつ定数ブロック３２２は「ＣｏｎｓｔａｎｔＢｌｏｃｋ０」と名付けられてデフォルト値「５」を有する。
【０２２３】
ユーザは、カラム３２４内のデフォルト値入力を選択して変数ブロックのデフォルト値を変えることができ、よって、アルゴリズムの評価ではその新しいデフォルト値が使用される。同様に、ユーザは、名前カラム３２３内の名前入力を選択して個々の変数ブロックの名前を変えることができる。変数ブロック３２１および３２２は、例えば、ユーザが、アルゴリズムのパラメータとして作用する変数ブロックの値を変えることによって、根本的な論理ではなくアルゴリズムの行動を操作できるようにしてもよい。
【０２２４】
制御エリア３１４は、アルゴリズムの設計に際して用いるための制御を提供する。制御エリア３１４は、アルゴリズムのシミュレーションを開始しかつ休止するための再生ボタンと休止ボタンとを含んでもよい。アルゴリズムのシミュレーションは、アルゴリズムの論理がどのように行動するかを示すために用いられてもよい。さらに、制御エリア３１４は、アルゴリズムを基礎としてプログラミングコードを生成させる生成ボタン（不図示）を含んでもよい。生成ボタンは、アルゴリズムの変更に基づいてプログラミングコードが自動的には生成されていない場合に用いられてもよい。これは、設計中のアルゴリズムが複雑であり、かつアルゴリズムの各修正後のプログラミングコードの生成（および適当であれば、これに続くこのプログラミングコードのコンパイル）が望ましくなく長い時間を要する場合に望ましいことがある。所定の実施形態では、制御エリア３１４は、アルゴリズムを基礎として生成されたプログラミングコードをコンパイルさせるコンパイルボタン（不図示）を含んでもよい。コンパイルボタンは、アルゴリズムの変更に基づいてプログラミングコードが自動的には生成かつ／またはコンパイルされていない場合に用いられてもよい。これは、設計中のアルゴリズムが複雑であり、かつアルゴリズムの各修正後のプログラミングコードのコンパイルが望ましくなく長い時間を要する場合に望ましいことがある。
【０２２５】
図３Ｆ−図３Ｇは、所定の実施形態による取引インタフェース３１０を示す。取引インタフェース３１０は、ライブフィードバック機能を提供する。ライブフィードバック機能は、設計キャンバスエリア３１１内の特定のブロックに関して、この特定のブロックの値のディスプレイを提供する。例えば、そのブロックの１つまたは複数の入力および／または出力について、ライブフィードバック値が表示されてもよい。ライブフィードバック値は、例えば、そのブロックまたは対応する入力および／または出力に関連して表示されてもよい。ライブフィードバックは、ブロックの入力または出力の値が変わる度に更新されてもよい。あるブロックの出力の変化は、結果的にこの第１のブロックの出力を入力として得る別のブロックの出力を（直接または間接的に）変える場合があり、これにより両ブロックのライブフィードバックが更新される結果となることに留意されたい。
【０２２６】
図３Ｆに示されているように、設計キャンバスエリア３１１に様々なブロック３３１が配置されている。ブロック３３１の出力毎に、ライブフィードバック３３２が出力の値を示して提供されている。ブロック３３３は数字ブロックであり、出力値はブロック３３３自体のディスプレイに示されることから、ライブフィードバックは提供されないことに留意されたい。所定の実施形態において、ライブフィードバックは、配置された特定のブロックの１つまたは複数の入力に関して提供される。所定の実施形態において、ライブフィードバックは、配置された特定のブロックの入力および出力の双方に関して提供される。所定の実施形態において、ライブフィードバックは、設計キャンバスエリア３１１内の全てのブロックに関して提供される。
【０２２７】
インスツルメントブロックのライブフィードバックは、値「ＧＣＪ１」を表示している。買い数量を提供するように設定されるインスツルメント属性ブロックのライブフィードバックは値「３」を表示し、インスツルメントＧＣＪ１の買い数量が３であることを表現している。加算器ブロックのライブフィードバックは値１３を表示しているが、これは、２つの入力値３（インスツルメント属性ブロックから）および１０（第１の数字ブロックから）の合計である。除算ブロックのライブフィードバックは値６．５を表示しているが、これは、第１の入力値１３（加算器ブロックから）を第２の入力値２（第２の数字ブロックから）で除算した結果である。
【０２２８】
アルゴリズムがシミュレーション中でない限り、所定のブロックにはライブフィードバックが提供されない場合がある。例えば、図３Ｇに示されているように、マーケットメーカ・ブロック３３５の出力にはライブフィードバックが提供されていない。これは、アルゴリズムが実行中でない（例えば、シミュレーション中でない）限り、マーケットメーカ・ブロック３３５は動作せず、よって市場と相互に作用しないためである。したがって、マーケットメーカ・ブロック３３５は、その動作を基礎とする連続値を提供せず（動作していないため）、また不連続イベントを発生することもない（やはり、動作していないため）。また、ライブフィードバックは、値抽出器ブロック３３６の出力にも提供されない。これは、値抽出器ブロック３３６が不連続入力を有し、よってその出力が値を有するのは不連続イベントが受信される場合に限られるためである。しかしながら、アルゴリズムが実行中でない限り、不連続イベントは受信されない。
【０２２９】
表示されるべきライブフィードバック値は、アルゴリズム自体から提供される。例えば、設計中のアルゴリズムに関して生成されるプログラミングコードは、取引インタフェース３１０等の取引インタフェースのディスプレイを更新するための追加命令を含んでもよい。所定の実施形態において、アルゴリズムに関して生成されるプログラミングコードは、例えば、アルゴリズムサーバ３０２等には取引インタフェースが存在しない場合があることから、取引インタフェースのディスプレイを更新するための追加インスツルメントを含まない。図３Ｄ−２および図３Ｄ−３に示されているように、方法「ＳｅｔＡｌｌＶａｒｉａｂｌｅｓ」は、呼び出されると、方法「ＳｅｎｄＵｐｄａｔｅ」を呼び出す。方法ＳｅｎｄＵｐｄａｔｅはユーザインタフェースへ、更新対象であるブロックの識別、更新対象である特定の出力指数および値（この場合は、加算器ブロックの値）を提供する。したがって、ブロックの値が変わる度に、ライブフィードバックを更新すべくユーザインタフェースへ更新が提供される。また、方法ＳｅｎｄＵｐｄａｔｅは、ユーザインタフェースへ更新値を提供するために、導出クラスを生成するブロックのベースクラスによって呼び出される場合もある。同様に、図３Ｄ−６に示されているように、イベントハンドラ「ＩｎｔｅｒｃｅｐｔＯｒｄｅｒＭｅｓｓａｇｅ」は、イベント「ＤｉｓｃｒｅｔｅＯｂｊｅｃｔＧｅｎｅｒａｔｅｄ」が発生すると呼び出されるべく登録されている。方法ＩｎｔｅｒｃｅｐｔＯｒｄｅｒＭｅｓｓａｇｅは、ユーザインタフェースへ、対応する不連続イベントの通知を提供する。したがって、この不連続イベントが発生される度に、ユーザインタフェースはライブフィードバックを提供することができる。
【０２３０】
アルゴリズムの実行中（シミュレーション中等）、ライブフィードバックは、設計キャンバスエリア３１１内の全てのブロックに関して提供されてもよい。不連続イベントは特定の時点で発生することから、イベントが発生すると、不連続イベント発生のインジケータが表示されてもよい。例えば、不連続入力および／または出力は、その入力および／または出力において不連続イベントが発生するとフラッシュして色、サイズまたは形状を変えてもよい。別の例として、不連続入力と不連続出力との間の接続は、その接続を介して不連続イベントが提供されるとフラッシュして色、サイズまたは形状を変えてもよい。別の例として、不連続イベントが出力から接続に沿って入力へ提供されていることを表現するために、接続に沿ってアニメーションが提供されてもよい。アニメーションは、例えば、接続に沿って移動する赤い円等のアイコンであってもよく、または接続は脈動してもよい。
【０２３１】
ライブフィードバック機能は、アルゴリズムの設計中およびアルゴリズムの実行中にユーザへフィードバックを提供する。ライブフィードバックは、アルゴリズムの動作の安全性および完全性、一般的傾向および損／益の可能性を含み、アルゴリズム論理がどのように行動するかをユーザが評価できるようにしてもよい。
【０２３２】
図３Ｈ−図３Ｌは、所定の実施形態による取引インタフェース３１０を示す。取引インタフェース３１０は、アルゴリズムが設計される際の潜在的エラーを減らすための安全機能を提供する。
【０２３３】
図３Ｈに示されているように、設計キャンバスエリア３１１にはインスツルメントブロック３４１が配置されている。しかしながら、インスツルメントブロック３４１が配置された時点でインスツルメントは指定されていなかった。インスツルメントが指定されていなければ、インスツルメントブロックはインスツルメント名を出力できないことから、これは無効な設定である。インスツルメントブロック３４１の近くには、問題が存在することを示す警告インジケータ３４２（この場合は、赤い円内に感嘆符（「！」）が付されたアイコン）が表示され、カーソルをインスツルメントブロック３４１の近くへ置くと問題の説明３４３が表示される。所定の実施形態では、問題を示すために、例えば、設計キャンバスエリア３１１の背景が赤で薄く彩色される、および／または警告またはエラーメッセージがステータスバーに表示される、等の他の（または追加的な）インジケータが表示されてもよい。
【０２３４】
図３Ｉに示されているように、設計キャンバスエリア３１１にはインスツルメント属性ブロック３４４が配置されている。しかしながら、インスツルメントの最良の買い呼び値を提供するように設定されているインスツルメント属性ブロック３４４に、必要な入力、即ち、最良の買い呼び値を提供すべきインスツルメント名は提供されていない。即ち、インスツルメント属性ブロック３４４は、インスツルメントブロック（または、インスツルメント名を提供し得る他のブロック）へ接続されていない。従って、アルゴリズム定義は無効である。この場合も、図３Ｈの場合と同様に、警告インジケータおよび感嘆符が表示される。
【０２３５】
図３Ｊに示されているように、設計キャンバスエリア３１１にはインスツルメント属性ブロック３４４およびマーケットメーカ・ブロック３４５が配置されている。ユーザは、インスツルメント属性ブロック３４４の出力（数値タイプを伴う連続式出力）を、マーケットメーカ・ブロック３４５のインスツルメント入力（インスツルメント値タイプを伴う連続式入力）へ接続しようとしている。これらの入力および出力の値タイプは不適合であり、よって、結果としてアルゴリズム定義は無効となる。試行された接続ライン上には、接続が無効であることを示すインジケータ３４６（この場合は、スラッシュの入った円）が表示されている。さらには、説明３４７も表示される。連続式出力と不連続入力との間で接続が試行される場合にも、同様のフィードバックが提供されることがある。
【０２３６】
図３Ｋに示されているように、設計キャンバスエリア３１１には加算器ブロック３４８ａおよび加算器ブロック３４８ｂが配置されている。ユーザは、加算器ブロック３４８ｂの出力を加算器ブロック３４８ａの入力へ接続しようとしている。しかしながら、加算器ブロック３４８ａの出力が既に加算器ブロック３４８ｂへ入力として接続されている。試行されている接続を許容すれば、結果的に、生成されるプログラミングコードにおいて循環依存関係が生じることになる。具体的には、加算器ブロック３４８ａの値を決定するようにプログラミングコードを生成しようとすれば、結果的に無限ループが生じる。したがって、このようなアルゴリズム定義は無効であり、よって、図３Ｊで規定されたフィードバックと同様に、この接続は無効として示され、説明が表示される。
【０２３７】
図３Ｌに示されているように、設計キャンバスエリア３１１には発生器ブロック３４９ａ、ファンネルブロック３４９ｂ、値抽出器ブロック３４９ｃおよび値積算器ブロック３４９ｄが配置されている。ユーザは、値積算器ブロック３４９ｄの不連続出力をファンネルブロック３４９ｂの不連続入力へ接続しようとしている。しかしながら、ファンネルブロック３４９ｂ、値抽出器ブロック３４９ｃおよび値積算器ブロック３４９ｄは各々パススルー・ブロックであり、よって受信される各不連続イベントは対応する不連続出力を介して出される。したがって、発生器ブロック３４９ａ（同じくファンネルブロック３４９ｂへ接続されている）によって不連続イベントが提供されると、これは、各接続ブロックを通過していく。
試行されている接続を許容すれば、結果的に、生成されるプログラミングコードにおいて無限ループが生じることになる。具体的には、生成されるプログラミングコードは、発生器ブロックにより提供される不連続イベントの処理に際して、不連続イベントを次には処理されるべき各ブロックへと無限に送り、この場合、前記処理は不連続イベントをサイクル内の次のブロックへ提供することを含む。したがって、このようなアルゴリズム定義は無効であり、よって、図３Ｊで規定されたフィードバックと同様に、この接続は無効として示され、説明が表示される。
【０２３８】
所定の実施形態において、警告および／またはエラーメッセージは、取引インタフェース３１０の別々のエリアに提供されてもよい。これにより、ユーザは、例えば、各ブロックを個々に調べるのではなく、全ての際立った警告およびエラーを即座に見ることができる。
【０２３９】
図３Ｍ−図３Ｒは、所定の実施形態による取引インタフェース３１０を示す。取引インタフェース３１０は、例えば、クラッタを減らし、アルゴリズム部分の再使用を有効化し（アルゴリズム間で共用され得るモジュールの生成を含む）、仮想化機能を有効化することを可能にするグルーピング機能を提供する。クラッタの低減およびアルゴリズム部分の再使用は、アルゴリズム設計における間違いの可能性を減らすことから、アルゴリズムをより良くすることに繋がる場合がある。以下、仮想化機能の優位点について論じる。
【０２４０】
図３Ｍに示されているように、単純なスキャルピングアルゴリズムの定義が設計されている。大まかに言えば、スキャルピングアルゴリズムは、最良の買い呼び値で買い、次に約定価格より１つ上の取引増分で売って１単位の売り買いにつき１つの取引増分の利益を出す。より具体的には、本アルゴリズムは、買いマーケットメーカ・ブロック３５１と、売りマーケットメーカ・ブロック３５２とを含む。買いマーケットメーカ・ブロック３５１には、インスツルメントブロックによって指定された買うべきインスツルメント（「ＥＳＺ０」）が提供される。買いマーケットメーカ・ブロック３５１には、インスツルメントフィールド・ブロックによって指定される、そのインスツルメントにとって最良の買い呼び値を与える買い価格が提供される。買いマーケットメーカ・ブロック３５１には、数字ブロックによって指定される、買うべき固定数量１０が提供される。買いマーケットメーカ・ブロック３５１が、受付中の買い注文の約定確認を受信すると、不連続イベントが発生される。
【０２４１】
売りマーケットメーカ・ブロック３５２は、買いマーケットメーカ・ブロック３５１によって取られたポジションをカバーするように売り注文を働かせる。売りマーケットメーカ・ブロック３５２には、売るべき同じインスツルメント（「ＥＳＺ０」）が提供される。売りマーケットメーカ・ブロック３５２には、インスツルメントの最小価格増分（インスツルメントフィールド・ブロックにより提供される）を約定価格（値抽出器ブロックにより、約定確認が受信されると買いマーケットメーカ・ブロック３５１により発生される不連続イベントから提供される）へ加算する加算器ブロックによって指定される売り価格が提供される。売りマーケットメーカ・ブロック３５２には、買いマーケットメーカ・ブロック３５１により買われている積算数量を提供する加算器ブロックによって指定された売り数量が提供されるが、これは、買いマーケットメーカ・ブロック３５１により約定確認が受信されると発生される不連続イベントから抽出される。
【０２４２】
したがって、アルゴリズムの実行中、買いマーケットメーカ・ブロック３５１は、数量１０を最良の買い呼び値で購入し、数量１０を（恐らくは、複数の売り注文によって）約定価格プラス最小価格増分で売る。
【０２４３】
図３Ｎに示されているように、アルゴリズムの論理部分をカバーすることに関連づけられるブロックは、周囲にボックス３５３を描くことによって選択されている。ユーザにとって関心のあるブロックを選択するためには、例えば、シフトまたはコントロールキーを押すこととカーソルとの組み合わせによって選択すること等の他のユーザインタフェース技術が用いられてもよい。
【０２４４】
ブロックが選択されると、これらは、メニュアイテムの選択等のアクションによってグルーピングされてもよい。
【０２４５】
図３Ｏに示されているように、グルーピングされたブロックは、次に、グループブロック３５３内にブロックのサムネイル画像が内部に包含された状態で表示される。グループブロック３５３は、示されるブロックおよび接続の数を減らすことによって設計キャンバスエリア３１１のクラッタを減らす。さらに、グループブロックは、別のアルゴリズムにロードされて再使用され得るようにモジュールのライブラリに保存されてもよい。グループブロックは、グルーピングされたブロックと称される場合もある。グループブロック内のブロックは、例えば、定義されたアルゴリズムの一部、サブアルゴリズムまたはサブルーチンと称されてもよい。
【０２４６】
グループブロック３５３は、グループブロック３５３内のブロックの入力に対応する、グループブロック３５３内に存在しないブロックの出力によって値を提供される入力３５４を伴って生成されてもよい。例えば、図３Ｏに示されているように、グループブロック３５３は、連続式インスツルメント入力と、不連続入力とを有する。連続式インスツルメント入力は、売りマーケットメーカ・ブロック３５２および最小価格増分を決定するインスツルメントフィールド・ブロックの連続式インスツルメント入力に対応する。不連続入力は、加算器ブロックおよび値抽出器ブロックの不連続入力に対応する。
【０２４７】
グループブロック３５３は選択されてもよく、次に、メニュアイテムの選択またはダブルクリック等のアクションを用いて、グループブロック３５３に包含されるブロックが編集されてもよい。図３Ｐに示されているように、設計キャンバスエリア３１１に類似する設計キャンバスエリアを有する新たなウィンドウが表示され、かつ同様にして操作されてもよい。グループブロック３５３は、グループブロック３５３の入力に対応する新たな入力ブロック３５５および３５６を含む。入力ブロック３５５はグループブロック３５３の連続式インスツルメント入力に対応し、かつ入力ブロック３５６はグループブロック３５３の不連続入力に対応する。入力ブロック３５５および３５６は各々、グループブロック３５３の個々の入力へ提供される値を提供する単一の出力を有する。
【０２４８】
グループブロック３５３内のブロックは何れも、グループブロック３５３より外部のブロックへ接続される出力を持たないことから図３Ｐには示されていないが、グループブロックは出力ブロックを含む場合もある。先に論じた入力ブロックと同様に、出力ブロックはグループブロックの出力に対応する。出力ブロックへ接続される出力を有するグループブロック内のブロックは、グループブロックの対応する出力へ接続される、グループブロックより外部のブロックへ値を提供する。
【０２４９】
グループブロックの設計に際しては、入力ブロックおよび出力ブロックは、グループブロックの入力または出力を生成するように配置されてもよい。配置されると、ユーザは、入力または出力のタイプを指定するようにプロンプトされてもよい。あるいは、入力または出力ブロックは、連続数値等の既定タイプへデフォルトしてもよい。入力または出力ブロックのタイプは、アルゴリズムを設計する間に、ユーザにより、例えば、入力または出力ブロックを選択しかつタイプを入力すべくプロンプトされるべきメニュアイテムまたはダブルクリック等のアクションを使用することによって変更されてもよい。同様に、ユーザは、入力または出力ブロック（および延てはグループブロックの対応する入力または出力）の名前を指定する場合もある。
【０２５０】
グループブロックは、別のグループブロックを含んでもよい。グループブロックのこのネスティングは、クラッタが減少しかつアルゴリズムの様々な部分の再使用可能性が潜在的に高まることを見込んでいる。
【０２５１】
プログラムコードの生成に際して、グループブロックは、設計中のアルゴリズムの主要なＣｕｓｔｏｍＡｌｇｏｒｉｔｈｍ０クラス内にネスティングされるアルゴリズムクラスのサブクラスとして生成される。グループブロックが他のグループブロック内にネスティングされる場合、生成されるプログラミングコードも同様に生成される各サブクラスをネスティングする。さらに、非原始ブロックは何れも、その最近のグループブロック・ペアレントにおいて宣言されかつ定義される。よって、例えば、あるグループブロックがグループブロック３段階の深さまでネスティングされ、かつそれが内部にマーケットメーカ・ブロック（非原始ブロックの一例）を有していれば、マーケットメーカ・ブロックのサブクラスは３段階深度で派生されるアルゴリズムクラス内に存在する。
【０２５２】
先に論じたスキャルピングアルゴリズムに戻ると、図３Ｍに示されているように、このアルゴリズムは欠陥を有する。スキャルピングアルゴリズムの目的は、最良の買い呼び値で買い、次に約定価格より１つ上の取引増分で売って１単位の売り買いにつき１つの取引増分の利益を出すことにある点を想起されたい。買いマーケットメーカ・ブロック３５１が、行っている買い注文の総数量１０に対して単一の約定を受信すれば、アルゴリズムは意図された通りに動作する。しかしながら、２つ以上の約定確認が２つ以上の価格レベルで受信されれば、アルゴリズムは望み通りに機能しない。例えば、買いマーケットメーカ・ブロック３５１が最良の買い呼び値１１４１２５で数量１０の買い注文を出すものと仮定する。すると、数量３について、第１の約定確認が受信される（よって、第１の約定の対象は約定価格１１４１２５における数量３である）。この約定に対して、売りマーケットメーカ・ブロック３５２は、価格１１４１５０（１１４１２５（約定価格）＋２５（最小価格増分））で数量３の売り注文を出す。ここで、最良の買い呼び値が１１４１００に下がるものと仮定する。すると、買いマーケットメーカ・ブロック３５１は、数量７について、その受付中の注文を新たな（かつ今回はより安い）最良の買い呼び値に付け直す。すると、数量７について、第２の約定確認が受信される（したがって、第２の約定の対象は、約定価格１１４１００で数量７となった）。
したがって、スキャルピングアルゴリズムの行動としては、第１の売り注文を（第１の約定をカバーする）数量３に対して価格１１４１５０（１１４１２５＋２５）で行ない、かつ第２の売り注文を（第２の約定をカバーする）数量７に対して価格１１４１２５（１１４１００＋２５）で行なうというのが望ましい。
【０２５３】
しかしながら、図３Ｍに示されているアルゴリズムは、望ましい行動を達成すべく適切な発注をしない。第１の約定が受信されると、売りマーケットメーカ・ブロック３５２は、数量３を価格１１４１２５＋２５で売る第１のカバー注文を出す。しかしながら、第１のカバー注文が約定される前に第２の約定が受信されれば、加算器ブロック（数量１０が既に約定されていることを反映して更新される）からクオートするために新たな数量を受信する売りマーケットメーカ・ブロック３５２は、数量１０に対し価格１１４１００＋２５（最新の約定（第２の約定）価格プラス最小価格増分）でカバー注文を出す。必然的に、第１の約定は、所望される価格ではカバーされない（これは、意図されない、かつ／または望ましくない行動である）。この場合、カバー注文が完全に約定されれば、アルゴリズムの望ましい行動の対象が受信される各約定に特有の価格および数量で出されるべきカバー注文であるとしても、カバー注文の全体数量１０は同じ価格で約定される。
【０２５４】
取引アプリケーション３００の仮想化機能は、この種の問題に対処する。グループブロックが選択されてもよく、次に、メニュアイテムの選択等のアクションを用いて、グループブロックは仮想化されるものと指定されてもよい。図３Ｑに示されているように、グループブロック３５３は仮想化されていて、これがグループブロック３５３の境界を実線から破線に変えることによって示されている。所定の実施形態において、グループブロックは仮想化されていることを、例えばブロック名にテキストを付加する、境界色、背景色または背景パターンを変える、等の他の方法で示されてもよい。
【０２５５】
仮想化されたグループブロックのインスタンスは、仮想化されたグループブロックへ提供される不連続イベント毎に生成される。即ち、仮想化されたグループブロックにおいて不連続イベントが受信される度に、その不連続イベントを取り扱うべく仮想化されたグループブロックの新たなインスタンスが生成される。これは、先に論じた、各不連続イベントはその不連続イベントに特有の情報を基礎としてグループブロックの論理によって扱われる、という望ましい行動に対処するものである。上述の例の説明を続けると、但し、グループブロック３５３が仮想化されることに特化して言えば、約定のために買いマーケットメーカ・ブロック３５１によって発生される各不連続イベントにより、結果的に、仮想化されたグループブロック３５３の新たなインスタンスがその特定の不連続イベントを扱うために生成される。
【０２５６】
したがって、新たなインスタンスを生成させるものが仮想化されたグループブロックへ不連続イベントを知らせるものであることから、仮想化されるべきグループブロックは悉く不連続イベント入力を持たなければならない。仮想化されたグループブロックが一旦インスタンス化されると、その特定のインスタンスはそれ以後、その範囲の外から（即ち、仮想化されたグループブロック内に存在しないブロックから）不連続イベントを受信しない。代わりに、仮想化されたグループブロックの範囲外からのこれに続く不連続イベントは何れも、仮想化されたグループブロックの新たなインスタンスを生成させることになる。しかしながら、不連続イベントは依然として発生されて仮想化されたグループブロック内のブロックによって処理される場合があり、よって、仮想化されたグループブロック内部で発生される不連続イベントは仮想化されたグループブロックの不連続入力へ提供される場合がある。図３Ｒは、買いマーケットメーカ・ブロック３５１によって３つの不連続イベントが発生されている場合に、アルゴリズム論理がどのように機能するかを概念的に示している。グループブロック３５３の３つのインスタンスは、買いマーケットメーカ・ブロック３５１からの３つの不連続イベントの各々に応答してインスタンス化されている。表示されているアルゴリズムは、事実上単に図３Ｑに示されているような単一の仮想化されたグループブロック３５３を示すだけであること、および図３Ｒに示されている３つのインスタンスは単にグループブロック仮想化の概念を表すために示されていることに留意されたい。所定の実施形態において、グループブロックのインスタンスの数は表示されてもよい。例えば、インスタンスの数は、図３Ｒに示されているものに類似する方法でグラフィカルに、仮想化されたグループブロックの積層を示すことによって表示されてもよく、この場合、積層のサイズがインスタンス化されている仮想化されたグループブロックのインスタンス数を表す。別の例として、インスタンスの数は、グループブロック内（角等）に表示される、インスタンス化されている仮想化されたグループブロックのインスタンス数の計数として表現される数字によって示されてもよい。
【０２５７】
さらに、連続式出力のような出力の値は意味論的に定義されないことから、仮想化されたグループブロックは連続式出力を有することができない（但し、不連続出力を有することはできる）。これは、仮想化されたグループブロックのインスタンスは２つ以上存在する場合があり（または、そのための不連続イベントがまだ受信されていなければ、インスタンスが存在しない可能性もある）、よって、このような連続式出力は異なる値を同時に有する可能性も、場合もある（または、全く値が存在しない）ことに起因する。さらに、変数は仮想化されたグループブロックがインスタンス化されるまでは「存在」しないはずであることから、仮想化されたグループブロックは、変数として指定されるブロックを含まない場合もある。
【０２５８】
仮想化されたグループブロックは、先に論じたようにグループブロックがネスティングされ得るのと同様に、別のグループブロックまたは別の仮想化されたグループブロックを包含してもよい。
【０２５９】
プログラミングコードの生成に際して、仮想化されたグループブロックは、先に論じたような非仮想化グループブロックと同様にアルゴリズムクラスのサブクラスとして生成される。しかしながら、当初は空である仮想化されたグループブロックのサブクラスのリストである主たるＣｕｓｔｏｍＡｌｇｏｒｉｔｈｍ０クラスが保持されている場合、および仮想化されたグループブロックに対応するサブクラスへ不連続イベントが提供されることになっている場合にインスタンス化されるのではなく、仮想化されたグループブロックのサブクラスの新たなインスタンスが生成される。
【０２６０】
クライアントデバイスとアルゴリズムサーバとの間のネットワーク接続は、不意に切断されることがある。例えば、クライアントデバイスによってアルゴリズムサーバへ接続するために使用されるインターネット・サービス・プロバイダ（「ＩＳＰ」）はルータの故障または通信リンクの物理切断を経験することがあり、これにより、クライアントデバイスとアルゴリズムサーバとの間の通信が遮断される場合がある。別の例として、ネットワーク内の中間ノードは故障することがあり、同じくクライアントデバイスとアルゴリズムサーバとの間の通信が遮断される。別の例として、クライアントデバイスは機能停止することがあり、アルゴリズムサーバへの接続が遮断される。現行システムの場合、このような接続が遮断されると、アルゴリズムは停止するか、接続が遮断されていることを認識せずに実行を続ける。前者の場合、トレーダは、容易には（または、接続がダウンしていることから可能性としては全く）抜け出せないオープンポジションのままにされることがある。後者の場合、トレーダは、もはや正しく動作していない、または市場における状態変化にとって不相応であり得るアルゴリズムのパラメータの修正も、アルゴリズムのシャットダウンも、停止もできないことがある。しばしば、トレーダは、極めて危険であり得るアルゴリズムを実行し、よって即座にこれをオフにできる、またはパラメータを変更できるように望むかもしれない。
【０２６１】
所定の実施形態において、１つまたは複数のブロックは、クライアントデバイスとアルゴリズムサーバとの接続状態を認識するように指定されることが可能である。例えば、配置されると、ユーザは、クライアントデバイスとアルゴリズムを実行するアルゴリズムサーバとの接続が切断される場合でもブロックが実行を続けるように指定するオプションを提示されてもよい。また、このオプションは、ブロックを選択しかつメニュアイテムまたはキーボードのコマンド等のアクションを使用することによって指定される場合もある。デフォルトを使用すれば、アルゴリズムは、クライアントデバイスとアルゴリズムサーバとの接続が遮断されると休止または停止する場合がある。所定の実施形態において、アルゴリズム全体は、クライアントデバイスとアルゴリズムを実行するアルゴリズムサーバとの接続が切断されても実行を続けるように指定される。
【０２６２】
例えば、マーケットメーカ・ブロックは、クライアントデバイスとアルゴリズムサーバとの接続が遮断されても、マーケットメーカ・ブロックによって発生される注文を市場にキープするためのオプションを有する場合がある。アルゴリズムのヘッジングまたはカバー注文部分に使用されているマーケットメーカ・ブロックは、これらの注文を出すアルゴリズムの一部が接続の遮断に起因してもはや実行を止めていても、アルゴリズムの別の部分によってとられているポジションは望み通りにヘッジまたはカバーされるように、この方法で設定されてもよい。
【０２６３】
所定の実施形態では、クライアントデバイスとアルゴリズムサーバとの接続の状態を表す連続式ブール出力を提供する入力ブロックが、設計中のアルゴリズムへ追加されてもよい。ブロックは次に、この接続状態入力ブロックからの値を、その行動を制御するための入力として取得してもよい。例えば、接続状態入力ブロックは、接続状態が「真」である（接続されていることを表す）場合にのみマーケットメーカ・ブロックが注文を出すように、マーケットメーカ・ブロックの条件付き入力へ接続されてもよい。
【０２６４】
アルゴリズムは、取引インタフェース３１０において定義されると保存されてもよい。また、アルゴリズムには（例えば、アルゴリズムの構築中および／またはアルゴリズムが保存される際に）名前が与えられてもよい。よって、保存されたアルゴリズムは、後に取引インタフェース３１０または別の取引インタフェースによって呼び出され、または参照されてもよい。例えば、保存されたアルゴリズムは、別の注文に関して編集または再使用され得るように取引インタフェース３１０によってロードされてもよい。別の例として、保存されたアルゴリズムは、後述するように別の取引インタフェースから１つの注文タイプとして参照されてもよい。
【０２６５】
先に論じた取引インタフェース３１０のコンポーネント、エレメントおよび／または機能は、単独または組み合わせて、例えばハードウェア、ファームウェアおよび／またはソフトウェアにおける命令セットとしての様々な形式で実装されてもよい。所定の実施形態は、汎用コンピュータまたは他の処理デバイスで実行されるために、メモリ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤ、ＥＰＲＯＭおよび／またはファイルサーバ等のコンピュータ読取り可能媒体に存在する命令セットとして提供されてもよい。
ＩＶ．  アルゴリズムの立ち上げおよび管理
【０２６６】
所定の実施形態は、選択されたアルゴリズムによってある注文タイプとして管理されるべき発注の開始に備える。所定の実施形態は、値軸から選択されるユーザ定義取引アルゴリズムによって管理されるべき発注の開始に備える。所定の実施形態は、アルゴリズムがある注文を管理している間にアルゴリズムの変数を変更することに備える。所定の実施形態は、アルゴリズムによって管理されている注文を手動で修正することに備える。所定の実施形態は、非管理注文へその注文を管理するためのアルゴリズムを割り当てることに備える。所定の実施形態は、異なるユーザ定義取引アルゴリズムによって管理されている受付中の注文を値軸へ表示することに備える。
【０２６７】
図４Ａ−図４Ｆは、所定の実施形態による取引インタフェースを示す。図４Ａに示されているように、取引インタフェース４１０は、保存されたアルゴリズムが注文タイプとして選択されることを可能にする注文チケットである。保存されたアルゴリズムは、例えば、先に論じた取引インタフェース２００および３１０に類似する取引インタフェースを用いて保存されている場合もある。
【０２６８】
保存されたアルゴリズムは選択インタフェース４１５を用いて選択されてもよく、選択インタフェース４１５は、図示されているように、標準的な注文タイプ（リミットおよび成り行き等）並びに保存されたアルゴリズムの双方を含むドロップダウン・リストを提供する。所定の実施形態において、選択インタフェース４１５は、利用可能な保存されたアルゴリズムから選択するための他の要素を含む。例えば、選択インタフェース４１５は、特定のアルゴリズムについてブラウズするためにファイルナビゲータを開いてもよい。別の例として、選択インタフェース４１５は、アルゴリズムのタイプを基礎として階層に分類されている保存されたアルゴリズムのツリー表示を含んでもよい。
【０２６９】
取引インタフェース４２０は、やはり、保存されたアルゴリズムが選択インタフェース４１５により注文タイプとして選択されることを可能にする単純化された注文チケットである。
【０２７０】
注文が取引インタフェース４１０または４２０から開始され、かつ保存されたアルゴリズムが注文タイプとして選択されると、注文は選択されたアルゴリズムに従って管理される。選択されたアルゴリズムが取引インタフェースからパラメータ（注文チケット価格または数量等）を取得するように設定されていれば、取引インタフェース４１０または４２０において指定される値は、実行中のアルゴリズムへ提供される。
【０２７１】
図４Ｂ−図４Ｃに示されているように、選択インタフェース４１５を用いてアルゴリズム注文タイプが選択された後、取引インタフェース４３０（先に論じた取引インタフェース４１０に類似する注文チケットスタイル取引インタフェース）および取引インタフェース４４０（市場深さラダーまたは軸スタイル取引インタフェース）が示される。この場合、選択されたアルゴリズムは図２Ｉに示されているものに類似する。取引インタフェース４４０は、取引可能オブジェクトの価格レベルに対応する、またはこれを基礎とする値を含む値軸を含んでもよい。値は、例えば、取引可能オブジェクトの価格（価格軸におけるもの等）であってもよい。値軸沿いには、値軸内の値に対応する価格レベルで入手可能な数量等の取引可能オブジェクトに関連する情報も表示される場合がある。アルゴリズムの変数は各々変数エリア４３５および４４５に示され、かつ注文を開始する前に変更されてもよい。変数エリア４３５は、取引インタフェース４３０内へ同じウィンドウの一部として組み込まれる。変数エリア４４５は、取引インタフェース４４０へ別のウィンドウとして組み込まれる。変数エリア４３５および４４５における変数は、図２Ｉに示されているように、変数エリア２０６のデフォルト値カラム２７２に指定される値へデフォルトする。変更されると、開始された注文は、変更された変数値によって選択されたアルゴリズムに従って受け付けられる。
【０２７２】
図４Ｄに示されているように、取引インタフェース４５０は、市場において受け付けられている注文を示す注文帳である。ここでは、アルゴリズム（同じく、図２Ｉに示されているものに類似する）に従って受け付けられている注文４５１が選択される。アルゴリズムの変数は変数エリア４５５（変数エリア４３５および４４５に類似する）に示され、かつ変更されてもよい。変更され（かつこの変更が適用され）ると、アルゴリズムは、変更された変数値に従って実行を続ける。変数の変更は、アルゴリズムを休止または停止することなく有効となる。
【０２７３】
所定の実施形態において、取引インタフェース４５０は、アルゴリズムによって管理されている注文をユーザが手動で修正できるようにする。例えば、ユーザは、注文の価格または数量を変更しても、注文を削除してもよい。これに対して、注文を管理するアルゴリズムは、例えば、注文価格を変更してもよく、注文数量を変更してもよく、何もしなくてもよく、また、単にアルゴリズム定義に従って使用するために手動修正に基づく新たな情報またはしきい値を保有するだけで新たなアクションは実行しなくてもよい。
【０２７４】
所定の実施形態において、取引インタフェース４５０は、アルゴリズムによって管理されるものではない注文（例えば、手動入力される注文）を含んでもよい。この管理されない注文は選択されてもよく、かつこれにアルゴリズムが適用されてもよい。例えば、ユーザは管理されない注文を選択し、かつメニュアイテムまたはキーボードコマンド等のアクションを用いて選択された管理されない注文へ適用する利用可能なアルゴリズムのリストを提示されてもよい。利用可能なアルゴリズムのリストは、例えば、注文ブロックを含む保存されたアルゴリズムを含んでもよい。選択された管理されない注文へ適用されると、選択されたアルゴリズムは、次に、アルゴリズムに従って注文を管理してもよい。別の例として、ユーザは、管理されない「取り消すまで有効」（「ＧＴＣ」）注文を選択し、かつ将来の取引セッションに渡ってアルゴリズムが注文を管理し得るように、選択されたアルゴリズムをこの注文に適用してもよい。
【０２７５】
図４Ｅに示されているように、取引インタフェース４６０は、先に論じた取引インタフェース４４０に類似する市場深さラダーまたは軸スタイル取引インタフェースである。幾つかの注文が開始されていて、異なる価格レベルで受け付けられていることが示されている。注文４６１は第１のアルゴリズムによって管理されるように開始され、かつ注文４６２は第２のアルゴリズムによって管理されるように開始された。したがって、取引インタフェース４６０は、同じアルゴリズムに従って管理される複数の受付中の注文を表示する単一のインタフェースを用意する。さらに、取引インタフェース４６０は、複数のアルゴリズムに従って管理される受付中の注文を表示する単一のインタフェースも用意する。
【０２７６】
所定の実施形態において、特定のアルゴリズムに従って管理される受付中の注文は共通して識別される。例えば、第１のアルゴリズムに関連づけられる受付中の注文は各々、例えば、特定の背景色、前景色、背景パターン、境界色、境界スタイル、形状、記号、数字、テキストおよび／またはフォントによってグラフィックに識別されてもよい。次に、第２のアルゴリズムに関連づけられる受付中の注文は、例えば、異なる色、パターン、境界、形状、記号、数字、テキストおよび／またはフォントを用いて識別されてもよい。
【０２７７】
所定の実施形態において、特定のアルゴリズムに従って管理される受付中の注文は個々に識別される。例えば、同じアルゴリズムの異なるインスタンスに関連づけられる受付中の注文は各々、そのアルゴリズムの異なるインスタンスに関連づけられる他の受付中の注文から、色、パターン、境界、形状、記号、数字、テキストおよび／またはフォント等の識別子によって区別されてもよい。アルゴリズムの第１のインスタンスに従って管理される注文は、その受付中の注文インジケータの角に数字「１」を有してもよく、一方で、アルゴリズムの第２のインスタンスに従って管理される注文は、その受付中の注文インジケータの角に数字「２」を有してもよい。特定のアルゴリズムの異なるインスタンスによって管理される受付中の注文の表示は、先に論じた異なるアルゴリズムによって管理される受付中の注文の表示と組み合わせて適用されてもよい。
【０２７８】
図４Ｆに示されているように、取引インタフェース４７０はアルゴリズムマネージャである。また、取引インタフェース４７０は、コックピットまたはダッシュボードと称される場合もある。取引インタフェース４７０は、利用可能なアルゴリズムのリスト４７１を含む。リスト４７１からは、特定のアルゴリズムが選択されてもよい。アルゴリズムが選択されると、選択されたアルゴリズムのビューが表示エリア４７２に表示され、かつ選択されたアルゴリズムの実行中のインスタンスのリスト４７３も表示される。図示されているように、表示エリア４７２は、先に論じた取引インタフェース３１０に類似する取引インタフェースを用いて作成されたアルゴリズム定義を示してもよい。しかしながら、表示エリア４７２は、先に論じた取引インタフェース２００に類似する取引インタフェースを用いて定義されたアルゴリズムのビューも表示してもよい。選択されたアルゴリズムの実行中のインスタンスのリスト４７３は、実行中のインスタンスに関する、例えば、その開始時間、そのポジション、ステータス、損益、受付中の注文数、約定された注文数、最近に発注されかつ／または約定が受信されたインスツルメントおよび／または注文口座情報等の情報を含んでもよい。
【０２７９】
さらに、変数エリア４７４は、選択されたアルゴリズムの変数、および選択されたアルゴリズムの選択されたインスタンスに関するこれらの変数の値を表示する。変数エリア４７４は、先に論じた変数エリア４３５、４４５および４５５に類似する。選択されたアルゴリズムの選択されたインスタンスの変数は、変更されてもよい。変更され（かつこの変更が適用され）ると、アルゴリズムは、変更された変数値に従って実行を続ける。変数の変更は、アルゴリズムを休止または停止することなく有効となる。
【０２８０】
所定の実施形態において、取引インタフェース２００、２９０、３１０、４１０、４２０、４３０、４４０、４５０、４６０および／または４７０等の取引インタフェースは、アルゴリズムによって管理される注文が取引セッションのクローズにおいて約定されていない場合にユーザが行動を指定できるように適合化される。例えば、取引インタフェースは、アルゴリズムによって管理される約定されていない注文がキャンセルされてアルゴリズムが停止されることをユーザが指定できるようにしてもよい。別の例として、取引インタフェースは、アルゴリズムによって管理される約定されていない注文が、次の取引セッションの開始時において引き続き管理されることをユーザが指定できるようにしてもよい。別の例として、取引インタフェースは、アルゴリズムによって管理される約定されていない注文が、次の取引セッションの開始時において休止され、かつユーザにより休止されない場合は管理されることを再開するようにユーザが指定できるようにしてもよい。
【０２８１】
先に論じた取引インタフェース４１０、４２０、４３０、４４０、４５０、４６０および４７０のコンポーネント、エレメントおよび／または機能は、単独または組み合わせて、例えばハードウェア、ファームウェアおよび／またはソフトウェアにおける命令セットとしての様々な形式で実装されてもよい。所定の実施形態は、汎用コンピュータまたは他の処理デバイスで実行されるために、メモリ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤ、ＥＰＲＯＭおよび／またはファイルサーバ等のコンピュータ読取り可能媒体に存在する命令セットとして提供されてもよい。
Ｖ．  ランキングツール
【０２８２】
図５は、所定の実施形態によるランキングツール５００を示す。ランキングツール５００は、例えば、ヘッジオプションをランク付けするために用いられてもよい。先物取引において、最も一般的な戦略の１つは「スプレッド取引」をすることである。これは、あるインスツルメントに市場指向性のリスクエクスポージャを有するトレーダが、１つまたはそれ以上の同様のインスツルメントの取引を行うことにより、自らのリスクの変数を相殺し、最小限に抑え、または減らしてそのリスクを回避しようとする方法である。２つのポジションが開始される時点での２つの価格は、コンビネーション価格またはスプレッド価格を生成する。よってトレーダは、最終的に、オープンポジションを、好適には、ポジションを開始した価格から利益を生み出すスプレッド価格差でアンワインドする取引の実行を試行してもよい。
【０２８３】
幾つかの自動化された取引プログラムの場合、トレーダのリスクを自動的に回避するヘッジ技法を実行することができる。このヘッジ技法は、ある特定のインスツルメントにおいてヘッジするように自動化される場合もあれば、予めプログラムされた方法に従ってインスツルメントの複数の選択肢から選択するようにプログラムされる場合もある。しかしながら、カレントシステムは、インスツルメントの既定の選択肢に結びつけられないヘッジング取引を用意していない。
【０２８４】
特にマーケットメーカにとって、自動化されていないスプレッド取引ポジションを開始する困難さは、技術の速度利得に起因して、取引を最も効率的にヘッジする機会を得ることが極めて困難になっていることにある。市場において役割を果たすその流動資産の性質に起因して、マーケットメーカは、彼らが取引相手に流動資産を与えている（即ち、取引を実行されている）という認識または覚悟に気づかされないことが多い。突然にオープン取引ポジションを入手する場合のあるマーケットメーカまたは任意のトレーダにとって、スプレッドの最初のレッグが開始される時点と、トレーダがこの取引をヘッジできる時点との時間差は、効率的なヘッジングおよびリスク管理にとって重大な不利益となっている。取引を迅速にヘッジすることができないトレーダは、何百、何千、または何百万ドルさえも失う場合がある。トレーダは、ヘッジするにはどのインスツルメントが最良のインスツルメントであるかを決定するために時間を費やさなければならないだけでなく、ヘッジ取引も実行しなければならない。
【０２８５】
所定の実施形態は、スプレッドポジションを最適に生成するために（但し、生成に限定されない）取引の手動でのヘッジングにおいて２つの顕著な速度的優位点をもたらすランキングツール５００を提供する。第１の態様は、任意の特定の瞬間における売りまたは買いにとってどの契約が最も効果的なインスツルメントであるかを選好順に決定するために、予めプログラムされたパラメータ方法によって絶えず分析されるインスツルメントグループをユーザに事前選択させる。ある実施形態では、この技法は、プログラムが考察しているインスツルメントに関して、既存のスプレッド市場における様々な売り／買いレベルを分析するように実装されることが可能である。別の実施形態では、これは、トレーダの全体的リスクを最も下げることにおいてどのヘッジ取引がトレーダをアシストするかを決定するために、トレーダの取引在庫ポジションに注目する場合がある。実際には、システムの実行プロセスの背後には無限の方法が存在する。トレーダは、この情報を使用して、リスクヘッジの対象としてのインスツルメントを決定するために要する時間を省くことができる。
【０２８６】
どのインスツルメントが最適なヘッジを提供するかを自動的に分析する能力に加えて、ランキングツール５００の別の態様は、これを、前述の予めプログラムされたヘッジング方法に従って市場で利用可能な「最良の」ヘッジまたはヘッジグループを実行すべく売買注文または注文グループを事実上自動入力するために使用できることにある。トレーダに要求される唯一の潜在的アクションは、考慮対象のインスツルメントを予め選択し、希望数量を入力し（事前設定が可能）、かつ取引インタフェース上の売り、または買い実行ヘッディングをクリックすることである。この自動ヘッジャにより、トレーダには、トレーダが希望するランキング方法と整合する効果的なスプレッド価格で積算されるべき様々なヘッジされた取引在庫が残る。ランキングツール５００は、広範な市場環境下ではヘッジが困難となる可能性もある取引を実行するという危険を冒す全てのトレーダにとって有益である。
【０２８７】
ランキングツール５００は、分析用にユーザが識別または選択できる取引可能オブジェクトのリストを備える選択エリア５１０を含む。図示されている例では、取引可能オブジェクトとして様々な月例向けのユーロドル先物がリストされている。「最良」のカラム（最良買い５２０および最良売り５３０）は、選択されたインスツルメントをランク順に表示し、本例において買い５２０はカレント売り呼び値を基に、また売りはカレント買い呼び値を基にランク付けされている。
【０２８８】
ランキングツール５００の注文チケット部分５４０は、ユーザがランキングシステムに従って売り買いする数量を入力できるようにする。売り、買いボタンは、希望するインスツルメントの自動実行を可能にする。このシステムの場合、ユーザは、一位にランクされたインスツルメントのみを売り／買いする選択、選択されたインスツルメントを全て約定する選択、または必要に応じてループする選択を含む様々な選択肢５５０を有する。例えば、トレーダの希望数量が一位のインスツルメントで入手可能な数量では満たされない場合、ランキングツール５００は、そのインスツルメントのリミット注文を初期価格で出すことができる。さらに積極的なアプローチは、どんな量であれ一位のインスツルメントで入手可能な数量を実行し、かつ必要に応じて次の契約の自動ヘッジへ移行することである。自動実行は、単にリストの最後（本例では第５位）まで作用し、かつ、関連数量がまだ満たされていなければ、リストされている高位の全月例を通じて取引することによってリミット注文を出す。ランキングツール５００は、純粋な成り行き注文が存在する場合等、必要に応じてループすることができ、アプリケーションは、リスト上位で再び開始しながら利用可能な次の価格へと続く。
【０２８９】
先に論じたランキングツール５００のコンポーネント、エレメントおよび／または機能は、単独または組み合わせて、例えばハードウェア、ファームウェアおよび／またはソフトウェアにおける命令セットとしての様々な形式で実装されてもよい。所定の実施形態は、汎用コンピュータまたは他の処理デバイスで実行されるために、メモリ、ハードディスク、ＣＤ−ＲＯＭ、ＤＶＤ、ＥＰＲＯＭおよび／またはファイルサーバ等のコンピュータ読取り可能媒体に存在する命令セットとして提供されてもよい。
ＶＩ．  コンピューティングデバイス例
【０２９０】
図６は、所定の実施形態によるコンピューティングデバイス６００を示すブロック図である。クライアントデバイス１１０は、例えば、１つまたは複数のコンピューティングデバイス６００を含んでもよい。クライアントデバイス３０１は、例えば、１つまたは複数のコンピューティングデバイス６００を含んでもよい。アルゴリズムサーバ３０２は、例えば、１つまたは複数のコンピューティングデバイス６００を含んでもよい。ゲートウェイ１２０は、例えば、１つまたは複数のコンピューティングデバイス６００を含んでもよい。取引所１３０は、例えば、１つまたは複数のコンピューティングデバイス６００を含んでもよい。取引所３０３は、例えば、１つまたは複数のコンピューティングデバイス６００を含んでもよい。
【０２９１】
コンピューティングデバイス６００は、バス６１０と、プロセッサ６２０と、メモリ６３０と、ネットワークインタフェース６４０と、ディスプレイデバイス６５０と、入力デバイス６６０と、出力デバイス６７０とを含む。コンピューティングデバイス６００は、追加的な、異なる、またはこれより少ないコンポーネントを含んでもよい。例えば、複数のバス、複数のプロセッサ、複数のメモリデバイス、複数のネットワークインタフェース、複数のディスプレイデバイス、複数の入力デバイス、複数の出力デバイスまたはこれらの任意の組合せが設けられてもよい。別の例として、コンピューティングデバイス６００は、ディスプレイデバイス６５０から分離した出力デバイス６７０を含まなくてもよい。別の例として、コンピューティングデバイス６００はディスプレイデバイス６５０を含まなくてもよい。別の例として、コンピューティングデバイス６００は入力デバイス６６０を含まなくてもよい。代わりに、例えば、コンピューティングデバイス６００は、外部またはリモート入力デバイスによりネットワークインタフェース６４０を介して制御されてもよい。
【０２９２】
バス６１０は、コンピューティングデバイス６００内のコンポーネント間でデータを通信するための通信バス、チャネル、ネットワーク、回路、スイッチ、ファブリックまたは他の機構を含んでもよい。バス６１０は、コンピューティングデバイス６００の任意のコンポーネントと通信で結合されかつ前記任意のコンポーネントとの間でデータを転送してもよい。例えば、取引アプリケーションのインストールプロセスの間、プロセッサ６２０によって実行されるべき１つまたは複数のコンピュータ読取り可能命令が入力デバイス６６０および／またはネットワークインタフェース６４０からメモリ６３０へ転送されてもよい。コンピューティングデバイス６００がメモリ６３０に格納された取引アプリケーションを実行している、または実行する準備をしているとき、プロセッサ６２０は、メモリ６３０からバス６１０を介して命令を検索してもよい。
【０２９３】
プロセッサ６２０は、汎用プロセッサ、デジタル信号プロセッサ、特定用途向け集積回路、フィールド・プログラマブル・ゲートアレイ、アナログ回路、デジタル回路、プログラムプロセッサ、これらの組合せ、または現時点で既知である、または今後開発される他の処理デバイスを含んでもよい。プロセッサ６２０は、ネットワークまたは分散処理関連等の単一のデバイスであっても、デバイスの組合せであってもよい。処理戦略は、例えば、マルチ処理、マルチタスク、平行処理および／またはリモート処理等の任意のものが用いられてもよい。処理はローカルであってもリモートであってもよく、かつ１つのプロセッサから別のプロセッサへ移動されてもよい。
【０２９４】
プロセッサ６２０は、メモリ６３０等の１つまたは複数の有形媒体において、かつ／またはネットワークデバイス６４０を介して符号化された論理を実行する働きをしてもよい。本明細書において、１つまたは複数の有形媒体において符号化される論理は、プロセッサ６２０または異なるプロセッサによって実行され得る命令を含む。論理は、例えば、ソフトウェア、ハードウェア、集積回路、ファームウェアおよび／またはマイクロコードの一部として格納されてもよい。論理は、外部通信デバイスから、例えばインターネットへ接続される通信ネットワークを介して受信されてもよい。プロセッサ６２０は、図示されている、または本明細書に記述されている機能、行動またはタスクを実行するために論理を実行してもよい。
【０２９５】
メモリ６３０は、例えば、コンピュータ読取り可能記憶媒体等の有形媒体であってもよい。コンピュータ読取り可能記憶媒体には、ランダムアクセスメモリ、読取り専用メモリ、プログラム可能読取り専用メモリ、電気式プログラム可能読取り専用メモリ、電気式消去可能読取り専用メモリ、フラッシュメモリ、磁気テープまたはディスク、光媒体、これらの任意の組合せ、または現時点で既知である、または今後開発される他の有形データ記憶デバイスを含む、但しこれらに限定されない様々なタイプの揮発性および不揮発性記憶媒体が含まれてもよい。メモリ６３０は、単一のデバイスまたは複数のデバイスを含んでもよい。例えば、メモリ６３０は、ランダムアクセスメモリおよびハード・ドライブ・ストレージを含んでもよい。メモリ６３０は、プロセッサ６２０に隣接しても、これの一部であっても、これによってプログラムされても、これとネットワークで結ばれても、かつ／またはこれより遠隔であってもよく、よって、メモリ６３０に格納されるデータは、例えばプロセッサ６２０によって検索されかつ処理されてもよい。
【０２９６】
メモリ６３０は、プロセッサ６２０によって実行可能な命令を格納してもよい。命令は、本明細書に記述されている、または図示されている行動または機能のうちの１つまたはそれ以上を達成するために実行されてもよい。
【０２９７】
ネットワークインタフェース６４０は、一方向の通信カップリングであっても、双方向の通信カップリングであってもよい。したがって、ネットワークインタフェース６４０は、１つ、２つまたはそれ以上の通信ネットワークまたはデバイスを通信で接続してもよい。例えば、バス６１０は、ネットワークインタフェース６４０を介して先に論じたゲートウェイ１２０に類似するゲートウェイとカップリングされてもよく、よって、コンピューティングデバイス６００の１つ、幾つかまたは全てのコンポーネントはゲートウェイによってアクセス可能であり、またはゲートウェイと通信することができる。別の例として、ネットワークインタフェース６４０は、バス６１０を他の通信ネットワークとカップリングしてもよい。ネットワークインタフェース６４０は、例えば、データ通信接続を提供するための統合サービスデジタル網（ＩＳＤＮ）カードまたはモデムであってもよい。別の例として、ネットワークインタフェース６４０は、例えばインターネットへ接続される互換性ＬＡＮへデータ通信接続を提供するためのローカル・エリア・ネットワーク（ＬＡＮ）カードであってもよい。また、無線リンクも実装される場合がある。ネットワークインタフェース６４０は、例えば、様々なタイプの情報を表現するアナログまたはデジタル・データ・ストリームを伝送する電気的、電磁的または光学信号を送受信してもよい。
【０２９８】
ディスプレイデバイス６５０には、例えば、視覚的出力デバイス、陰極線管（ＣＲＴ）ディスプレイ、電子ディスプレイ、電子ペーパ、フラットパネル・ディスプレイ、発光ダイオード（ＬＥＤ）ディスプレイ、エレクトロルミネッセントディスプレイ（ＥＬＤ）、プラズマ・ディスプレイ・パネル（ＰＤＰ）、液晶ディスプレイ（ＬＣＤ）、薄膜トランジスタディスプレイ（ＴＦＴ）、有機発光ダイオードディスプレイ（ＯＬＥＤ）、表面伝導型電子放出素子ディスプレイ（ＳＥＤ）、レーザテレビ、カーボンナノチューブ、ナノ結晶ディスプレイ、ヘッドマウント・ディスプレイ、プロジェクタ、三次元ディスプレイ、透過型ディスプレイデバイスおよび／または現時点で既知である、または今後開発される他のディスプレイが含まれてもよい。
【０２９９】
ディスプレイデバイス６５０は、取引画面を表示するように適合化される。取引画面は、例えば、先に論じた取引画面に類似するものであってもよい。取引画面は、双方向性であってもよい。双方向性の取引画面は、例えば、１つまたは複数の取引アクションが取引画面を用いて実行されることを可能にしてもよい。例えば、双方向性の取引画面は、１つまたは複数の注文エントリパラメータが１つまたは複数の注文エントリアクションを用いて設定されかつ／または送信されることを可能にしてもよい。ディスプレイデバイス６５０および／または入力デバイス６６０は、例えば、取引画面と相互作用するために用いられてもよい。
【０３００】
入力デバイス６６０には、例えば、キーボード、マウス、マイクロホン、タッチスクリーン、トラックボール、キーパッド、ジョイスティックおよび／または入力を提供するための他のデバイスが含まれてもよい。入力デバイス６６０は、例えば、プロセッサ６２０へコマンドセレクションを提供するために用いられてもよい。例えば、入力デバイス６６０は、取引画面に表示されるカーソルを制御するために用いられるマウスであってもよい。マウスは、例えば、選択および制御用の１つまたは複数のボタンを含んでもよい。
【０３０１】
出力デバイス６７０には、例えば、キーボード、マウス、スピーカ、タッチスクリーン、トラックボール、キーパッド、触覚デバイスまたはシステム、ジョイスティックおよび／または出力を提供するための他のデバイスが含まれてもよい。例えば、出力デバイス６７０は、触覚信号または可聴信号等の１つまたは複数の信号をユーザへ出力するために用いられてもよい。
【０３０２】
所定の実施形態を参照して本発明を説明してきたが、当業者には、発明の範囲を逸脱することなく様々な変更が行われ、かつ同等物での置換が行われ得ることが理解されるであろう。さらに、特定の状況または材料に適応するために、本発明の教示内容には、その範囲を逸脱することなく多くの修正が行われてもよい。したがって、本発明は開示された特定の実施形態に限定されず、クレームの範囲内にある全ての実施形態を含むことが意図されている。
【図１】
0005485405.tif 000003
【図２Ａ】
0005485405.tif 000004
【図２Ｂ】
0005485405.tif 000005
【図２Ｃ】
0005485405.tif 000006
【図２Ｄ】
0005485405.tif 000007
【図２Ｅ】
0005485405.tif 000008
【図２Ｆ】
0005485405.tif 000009
【図２Ｇ】
0005485405.tif 000010
【図２Ｈ】
0005485405.tif 000011
【図２Ｉ】
0005485405.tif 000012
【図２Ｊ】
0005485405.tif 000013
【図３Ａ】
0005485405.tif 000014
【図３Ｂ】
0005485405.tif 000015
【図３Ｃ】
0005485405.tif 000016
【図３Ｄ−１】
0005485405.tif 000017
【図３Ｄ−２】
0005485405.tif 000018
【図３Ｄ−３】
0005485405.tif 000019
【図３Ｄ−４】
0005485405.tif 000020
【図３Ｄ−５】
0005485405.tif 000021
【図３Ｄ−６】
0005485405.tif 000022
【図３Ｄ−７】
0005485405.tif 000023
【図３Ｅ】
0005485405.tif 000024
【図３Ｆ】
0005485405.tif 000025
【図３Ｇ】
0005485405.tif 000026
【図３Ｈ】
0005485405.tif 000027
【図３Ｉ】
0005485405.tif 000028
【図３Ｊ】
0005485405.tif 000029
【図３Ｋ】
0005485405.tif 000030
【図３Ｌ】
0005485405.tif 000031
【図３Ｍ】
0005485405.tif 000032
【図３Ｎ】
0005485405.tif 000033
【図３Ｏ】
0005485405.tif 000034
【図３Ｐ】
0005485405.tif 000035
【図３Ｑ】
0005485405.tif 000036
【図３Ｒ】
0005485405.tif 000037
【図４Ａ】
0005485405.tif 000038
【図４Ｂ】
0005485405.tif 000039
【図４Ｃ】
0005485405.tif 000040
【図４Ｄ】
0005485405.tif 000041
【図４Ｅ】
0005485405.tif 000042
【図４Ｆ】
0005485405.tif 000043
【図５】
0005485405.tif 000044
【図６】
0005485405.tif 000045