(57)【特許請求の範囲】
【請求項１】
少なくとも１つのクライアントと通信するための通信モジュールと、
口座と関連付けられると共に、前記クライアントによって特定された取引注文を処理するためのサーバとを備え、
前記サーバが、複数のパイプラインと、１つ以上のスレッドを実行する１つ以上のプロセッサとを備えると共に、
１つ以上のパイプラインが、前記口座ごとに異なるパイプライン待ち行列を備えることによって、前記取引注文を処理するように構成され、
前記サーバが、
口座と関連付けられる前記取引注文を前記パイプライン待ち行列に入れて列に並ばせる手段と、
実行可能なスレッドを前記パイプライン待ち行列内の前記取引注文に割り当てると共に、前記実行可能なスレッドを１つのパイプラインに割り当てる手段と、
前記パイプラインを通して前記取引注文を処理する手段と
を有し、
各パイプラインでは、一度に単一の前記スレッドが１つのパイプラインに割り当てられ、２つの前記スレッドが同じパイプライン待ち行列から前記取引注文を処理することが防止される
ことを特徴とするシステム。
【請求項２】
１つ以上のパイプラインが、それぞれ前記取引注文のサブタスクを処理するように構成された少なくとも１つのイベントプロセッサを備える
ことを特徴とする請求項１に記載のシステム。
【請求項３】
１つ以上のパイプラインがそれぞれ複数のイベントプロセッサを備えて、１つ以上のイベントプロセッサがそれぞれ前記取引注文のサブタスクを処理するように構成されると共に、
前記複数のイベントプロセッサが、各サブタスクを順次に連続して処理するように順番に配置される
ことを特徴とする請求項１に記載のシステム。
【請求項４】
前記パイプラインが、前記パイプラインを通して連続して前記取引注文を処理するように構成される
ことを特徴とする請求項３に記載のシステム。
【請求項５】
１つ以上のイベントプロセッサが、前記パイプラインを通して連続して前記取引注文を動かすために、それぞれ一時中断フラグまたは失敗フラグを前記サブタスクに割り当てるように構成される
ことを特徴とする請求項４に記載のシステム。
【請求項６】
前記取引注文が、オーダキャンセルオーダ（ＯＣＯ）、オーダセンドオーダ（ＯＳＯ）、一括売買注文、及びバスケット注文の内の少なくとも１つを含む
ことを特徴とする請求項１に記載のシステム。
【請求項７】
少なくとも１つのクライアントと通信するための通信モジュールと、口座と関連付けられると共に、前記クライアントによって特定された取引注文を処理するためのサーバとを備えたシステムにおいて、前記取引注文を処理する方法であって、
前記サーバが、複数のパイプラインと、１つ以上のスレッドを実行する１つ以上のプロセッサとを備えると共に、
１つ以上のパイプラインが、前記口座ごとに異なるパイプライン待ち行列を備えることによって、前記取引注文を処理するように構成され、
前記方法は、
前記サーバが、口座と関連付けられる前記取引注文を前記パイプライン待ち行列に入れて列に並ばせる段階と、
前記サーバが、実行可能なスレッドを前記パイプライン待ち行列内の前記取引注文に割り当てると共に、前記実行可能なスレッドを１つのパイプラインに割り当てる段階と、
前記サーバが、前記パイプラインを通して前記取引注文を処理する段階と
を有し、
各パイプラインでは、一度に単一の前記スレッドが１つのパイプラインに割り当てられ、２つの前記スレッドが同じパイプライン待ち行列から前記取引注文を処理することが防止される
ことを特徴とする方法。
【請求項８】
１つ以上のパイプラインが、それぞれ前記取引注文のサブタスクを処理するように構成された少なくとも１つのイベントプロセッサを備える
ことを特徴とする請求項７に記載の方法。
【請求項９】
１つ以上のパイプラインがそれぞれ複数のイベントプロセッサを備えて、１つ以上のイベントプロセッサがそれぞれ前記取引注文のサブタスクを処理するように構成されると共に、
前記複数のイベントプロセッサが、各サブタスクを順次に連続して処理するように順番に配置される
ことを特徴とする請求項７に記載の方法。
【請求項１０】
前記取引注文が、前記サーバにより前記パイプラインを通して連続して処理される
ことを特徴とする請求項９に記載の方法。
【請求項１１】
前記イベントプロセッサの内の１つ以上が、前記パイプラインを通して連続して前記取引注文を動かすために、それぞれ一時中断フラグまたは失敗フラグを前記サブタスクに割り当てるように構成される
ことを特徴とする請求項１０に記載の方法。
【請求項１２】
前記取引注文が、オーダキャンセルオーダ（ＯＣＯ）、オーダセンドオーダ（ＯＳＯ）、一括売買注文、及びバスケット注文の内の少なくとも１つを含む
ことを特徴とする請求項７に記載の方法。
【請求項１３】
少なくとも１つのクライアントと通信するための通信モジュールと、口座と関連付けられると共に、前記クライアントによって特定された取引注文を処理するためのサーバとを備えたシステムにおいて、前記取引注文を処理するために、コンピュータ実行可能な命令を有するコンピュータプログラムであって、
前記サーバが、複数のパイプラインと、１つ以上のスレッドを実行する１つ以上のプロセッサとを備えると共に、
１つ以上のパイプラインが、前記口座ごとに異なるパイプライン待ち行列を備えることによって、前記取引注文を処理するように構成され、
前記命令が、コンピュータ上で実行されたときに、
口座と関連付けられる前記取引注文を前記パイプライン待ち行列に入れて列に並ばせる段階と、
実行可能なスレッドを前記パイプライン待ち行列内の前記取引注文に割り当てると共に、前記実行可能なスレッドを１つのパイプラインに割り当てる段階と、
前記パイプラインを通して前記取引注文を処理する段階と
を有する方法を前記コンピュータに実行するように指示し、
各パイプラインでは、一度に単一の前記スレッドが１つのパイプラインに割り当てられ、２つの前記スレッドが同じパイプライン待ち行列から前記取引注文を処理することが防止される
ことを特徴とするコンピュータプログラム。
【請求項１４】
１つ以上のパイプラインが、それぞれ前記取引注文のサブタスクを処理するように構成された少なくとも１つのイベントプロセッサを備える
ことを特徴とする請求項１３に記載のコンピュータプログラム。
【請求項１５】
１つ以上のパイプラインがそれぞれ複数のイベントプロセッサを備えて、１つ以上のイベントプロセッサがそれぞれ前記取引注文のサブタスクを処理するように構成されると共に、
前記複数のイベントプロセッサが、各サブタスクを順次に連続して処理するように順番に配置される
ことを特徴とする請求項１３に記載のコンピュータプログラム。
【請求項１６】
前記取引注文が、前記パイプラインを通して連続して処理される
ことを特徴とする請求項１５に記載のコンピュータプログラム。
【請求項１７】
前記イベントプロセッサの内の１つ以上が、前記パイプラインを通して連続して前記取引注文を動かすために、それぞれ一時中断フラグまたは失敗フラグを前記サブタスクに割り当てるように構成される
ことを特徴とする請求項１６に記載のコンピュータプログラム。
【請求項１８】
前記取引注文が、オーダキャンセルオーダ（ＯＣＯ）、オーダセンドオーダ（ＯＳＯ）、一括売買注文、及びバスケット注文の内の少なくとも１つを含む
ことを特徴とする請求項１３に記載のコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、認定ユーザが、リアルタイムで様々なタイプの証券（例えば、株式（stok）、公債（bond）、先物（future）、オプション（option）、派生商品（derivative）等）の取引に関する注文を出して、実行することを可能にすることができる証券取引注文管理システムに関係する。更に特に、本発明は、取引のためのリアルタイム金融市場データ、及びリアルタイム金融市場アクセスを組み込むためのそのような注文管理システムの操作方法を対象とする一方、更に、ユーザの投資ポートフォリオ（investment portfolio）の値を保護するために、重要な取引前（pre-trade）演算操作及び取引後（post-trade）演算操作を同様に提供する。
【背景技術】
【０００２】
この出願は、参照によってここに組み込まれた、２００６年４月２８日に出願された米国仮特許出願番号第60/796,083号、及び２００７年４月２６日に出願された米国特許出願番号第11/740,609号の利益を主張する。
【０００３】
高速データ送受信接続が利用できる前は、仲買人及び取引業者は、彼らの証券取引活動を独占的に金融為替（financial exchange）市場フロアに制限するように強要された。最も確かに効果的取引を妨げるであろう遅い接続時間のために、その時に利用可能であったインターネット上のリモートサイト取引に従事することは可能ではなかった。しかしながら、その上でリアルタイムで十分にデータを送受信することが可能である高速データ通信回線の利用可用性が増加することによって、電子取引を実行することが更に実行可能になった。これは、金融証券取引分野における彼らのために、遠隔為替市場における証券取引に参加することの全ての新しい特殊性に対するドアを開いた。
【０００４】
インターネットに基づく電子証券取引を可能にする多くの管理システムが存在する。例えば、米国特許番号第6,014,643号は、ユーザの通信ネットワークと接続される対話型証券取引システムを対象とする。取引システムは、ある証券を販売するという申し出を発行する第１のユーザを、その特定の証券を買うことを要求した第２のユーザと適合させる。一度、第２のユーザが契約価格で買う意向を伝達したならば、第１のユーザは、受け入れる選択権を有すると共に、もし受け入れた場合、その場合に、資金は、第２のユーザの銀行口座から自動的に引き出され、第１のユーザの銀行口座に振り込まれる。本発明は、直接的なネットワーク環境を作成することによって買い手と売り手とを適合させるための有益なシステムを提供するが、しかしながら、それは、証券を買うか、もしくは売るというユーザの決定を援助するために、あらゆる種類のリスク分析を実行するという能力に欠ける。
【０００５】
利用可能なデータ接続の純粋な速度に加えて、更に迅速で、効率的な注文処理を援助するであろう使い易いユーザインタフェースを備えることは、注文管理システムには不可欠である。一例として、米国特許第6,766,304号は、１つのタイプのユーザインタフェースである、電子為替取引環境にアクセスするためにユーザに提供されたグラフィックウィンドウ目視インタフェース（graphical window viewing interface）を対象とする。使い易さを達成する効率的なユーザインタフェースを提供する一方、この発明は、リスクのグレードを決定するために、ユーザの取引に関してリスク分析を実行する能力にまだ欠けると共に、ユーザのポートフォリオから次の可能な取引を提案するための取引後（post-trade）分析を全く実行しない。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
高速のインターネット接続の導入が証券の電子取引の新しい時代において必須であったと同時に、それは、これらの電子システムのリアルタイムに近い速度を最大限に利用すると共に、同時に多くの注文を達成することを試みる証券会社と貿易会社との間の増加した量の競争に同様に帰着した。従来技術の現状は、この観点において、単一の注文管理に制限されることが不足していると共に、複数の複雑な取引注文を同時に処理する能力を備えていない。
【０００７】
本発明は、複数の部分から構成される注文管理を扱うための取引前演算操作と、ユーザの最も最近の投資ポートフォリオの状態を更新するための取引後リスク分析とを統合することによって、従来技術の欠点を克服することができる注文管理システムである。
【課題を解決するための手段】
【０００８】
本発明の特徴によれば、各スレッドが口座と関連付けられている、口座中心（account-centric）のパイプライン構造を備える略リアルタイムの取引サーバが開示される。口座中心のパイプライン構造は、２つのスレッドが同時に同じ待ち行列（queue）から注文を処理することを防止する内部の割付けルーチン（allocator）を含む。この制限は、レコードロッキング（record locking）の必要性、及びレコードコンテンション（record contention）によって引き起こされた遅延を消去する。
【０００９】
本発明の更なる特徴は、合成値幅（synthetic spread）を作成するために使用され得る複数の部分から構成される注文タイプを開示する。複数の部分から構成される注文タイプは、複数の部分から構成される注文を作り上げる全てのサブ注文（副次的な注文：suborder）のための集約ポイントとして機能する。各サブ注文は、他のサブ注文とは無関係に処理され得ると共に、実行のために異なる取引所（exchange）に送られ得る。
【００１０】
本発明の１つの特徴において、ユーザが、その上で彼が取引する資格を与えられている金融為替システムにアクセスすることだけを許可するための許可システムを利用することによって、ユーザのアクセス権を認証する段階と、ユーザの取引命令が金融為替サーバに入力される前に実行される取引前操作を開始する段階と、最適な金融為替市場（financial exchange market）にアクセスすることによって、ユーザの取引命令を実行する段階と、ユーザの取引履歴と注文管理システムの口座に格納された現在の投資ポートフォリオに基づいてユーザの口座のリスク分析（risk analysis）スキャンを実行することができる取引後操作を開始する段階とを含む注文管理システムの操作方法が開示される。
【００１１】
本発明の更なる特徴は、クレジットアットリスク（Credit at Risk：ＣａＲ）、及びバリューアットリスク（Value at Risk：ＶａＲ）の計算に関与する取引前操作を有する。これらの２つの要素は、ユーザによる近い将来の取引の意志決定と関連付けられたリスク要因を決定するために使用される。その場合に、ユーザは、計算されたリスク要因に基づいて、金融為替市場に実行のための取引を発行することをやり通すかどうかを決定し得る。
【００１２】
本発明の更なる特徴において、取引後操作は、近い将来に、値が増加するか、または減少するかのどちらにも著しく潜在的に変わるとみなされる保有証券を探し求めて、口座を通してユーザの現存するポートフォリオを照会する能力を有する。これは、ユーザが、利益を拡張するか、もしくは損失を緩和することになる潜在的な先物取引に付加された見識を有することを可能にする。
【００１３】
全ての市場に、ほぼリアルタイムのデータの供給及び注文の実行を提供することが、本発明の更にもう一つの特徴である。証券の価格が著しく変わる前に取引が実行され得るように、ほぼリアルタイムという言葉によって、現実のリアルタイムに十分に近いということが意味されるが、しかし、注文管理システムが実行されるコンピュータシステムの操作を制圧するか、もしくは過度に減速するほどには速くはない。これは、世界中の様々な金融市場の取引所と接続されるように、高速データ通信接続に接続されるプラットフォームに注文管理システムを組み込むことによって達成され得る。
【００１４】
本発明の追加の機能及び利点は、以下の記述において示されることになると共に、一つには記述から明白であり、または本発明の実践によって学習され得る。本発明の目的、及び他の利点は、添付された図と同様に、これに関する明細書及び請求項において特に指摘された構造によって、実現し、かつ達成されることになる。
【００１５】
これらの利点及び他の利点を達成するために、そして本発明の目的に従って、広く具体化されて示されたように、システムは、少なくとも１人のクライアントと通信するための通信モジュールと、口座と関連付けられると共に、前記クライアントによって特定されたタスクを処理するためのサーバとを備え、前記サーバが、複数の口座中心のパイプラインを備えると共に、１つ以上の口座中心のパイプラインが、それぞれ前記タスクを処理するように構成されることを特徴とする。
【００１６】
別の特徴において、方法は、口座と関連付けられるタスクをパイプライン待ち行列に入れて列に並ばせる段階と、実行可能なスレッドを前記パイプライン待ち行列内の前記タスクに割り当てると共に、前記実行可能なスレッドを１つの口座中心のパイプラインに割り当てる段階と、前記口座中心のパイプラインを通して前記タスクを処理する段階とを有することを特徴とする。
【００１７】
更にもう一つの特徴において、その上に格納されたコンピュータ実行可能な命令を有するコンピュータ読み取り可能な媒体を含むコンピュータプログラム製品であって、コンピュータ上で実行されたときに、口座と関連付けられるタスクをパイプライン待ち行列に入れて列に並ばせる段階と、実行可能なスレッドを前記パイプライン待ち行列内の前記タスクに割り当てると共に、前記実行可能なスレッドを１つの口座中心のパイプラインに割り当てる段階と、前記口座中心のパイプラインを通して前記タスクを処理する段階とを有する方法をコンピュータに実行するように指示することを特徴とする。
【００１８】
前述の概要と、以下の詳細な説明の両方が、代表的で、説明的で、そして請求項に記載された本発明の更なる説明を意図しているということが理解されるべきである。
【発明を実施するための最良の形態】
【００１９】
本発明は、その図面と連係して、好ましい実施例、及び代替の実施例の参照によって説明されることになる。
【００２０】
図１は、本発明の実施例の構成要素の図である。ゲートウェイ要素１２０は、クライアント要素１１０からのメッセージを翻訳して正しい取引サーバ１３０に送信する。クライアント要素１１０は、取引業者が、取引注文を注文管理システム（order management system：ＯＭＳ）に送信すると共に、ＯＭＳから更新及び注文確認を受信することを可能にする。クライアント要素１１０は、好ましくはクライアントのリモートコンピュータにインストールされたソフトウェア要素である。インストールされた要素は、ブラウザと同じくらい簡単であり得るか、もしくはＯＭＳに対してカスタマイズされたフロントエンドであり得る。クライアント要素１１０は、ＯＭＳの取引実行機能だけを必要とするクライアントからＯＭＳにＦＩＸ（Financial-Information-eXchange）メッセージを送信する単純なＦＩＸ変換装置（FIX translator）であり得る。
【００２１】
クライアント要素１１０とゲートウェイ要素１２０との間のメッセージのコピーは、実行された取引の決算（clearing）または決済（settlement）のための決算インタフェース１２５に送信され得る。決算インタフェース１２５は、メッセージを標準のＦＩＸプロトコルに変換するＦＩＸレポータ（FIX reporter）であり得る。ＦＩＸメッセージは、その場合に、そのクライアントに関する決済を扱う第三者（third-party）決算アプリケーションに送信され得る。いくつかの実施例において、任意の清算アプリケーションは、直接ゲートウェイ要素１２０と接続されていると共に、実行された取引に関する決済を提供し得る。
【００２２】
口座データベース１４０は、各口座の口座プロファイルを保持する。口座プロファイルは、規則、許可、制限、及び口座の優先度を含む。
【００２３】
取引サーバ１３０は、例えば、各口座に関するポジション（position）、バランス（balance）、及びルール（rule）のような、各口座の状態を管理する。取引サーバは、各口座注文が、必要とされるバランスを有していると共に、その口座に関する全てのルールを満たすことを確認する。口座注文が許可されることを、取引サーバ１３０が決定するとき、取引サーバ１３０は、注文を状態なし注文ハンドラ（stateless order handler）１８０に送信する。ハンドラ１８０は、注文と関連付けられた特定の送り先取引所（destination exchange）によって注文を読みやすい形式に変換すると共に、変換された注文を送り先取引所に送信する。
【００２４】
市場監視手段１９０は、取引サーバ１３０からの命令に従って市場を監視すると共に、要求された市場情報を中継して取引サーバ１３０に戻す。市場監視手段１９０は、取引サーバ１３０が市況に基づく取引命令を実行することを可能にする。
【００２５】
アーカイブデータベース（archive database）１７５は、歴史的な、もしくは法律上の目的のために保持されなければならない取引サーバ１３０によって生成された取引イベントを保持する。取引スタッファ（trade stuffer）１７３は、取引サーバ１３０からアーカイブデータベース１７５に接続するインターフェースを提供する。アーカイブデータベース１７５に対して書き込むことは、通常は遅い操作であると共に、取引イベントが取引サーバにバックアップ（back up）された状態になるので、取引サーバ１３０において障害を引き起こし得る。好ましい実施例において、ＸＭＬパブリッシャ（XML publisher）１７０は、取引サーバ１３０から取引イベントを受信する大きなバッファを提供すると共に、それらをＸＭＬに変換し、そして取引スタッファ（trade stuffer）１７３が取引イベントをアーカイブデータベース１７５に書き込むことができるまで、取引イベントを中間記憶装置に保存する。ＸＭＬパブリッシャ（XML publisher）１７０によって提供されたバッファは、より遅いアーカイブデータベース１７５によって引き起こされる遅延なしで、取引サーバ１３０が取引注文を処理することを可能にする。
【００２６】
“ｌｔａｓｋ（logical task）”モジュール１５０は、取引サーバ１３０に、冗長性、及びクラッシュ回復を提供する。“ｌｔａｓｋ”モジュールは、取引サーバ１３０におけるプロセッサの内の１つが機能しなくなる場合に口座状態情報の損失を防止する、取引サーバ１３０のインメモリコピー（in-memory copy）を保持する。口座状態のインメモリコピーを保持することは、更に障害迂回（fail-over）プロセッサのために急速な回復を可能にする。
【００２７】
注文マネージャ１５５は、システムマネージャまたはヘルプデスク人員（help desk personnel）が、口座の現在の取引状態を見ることを可能にする。
【００２８】
帳簿（ledger）サーバ１６０は、“ｌｔａｓｋ”モジュール１５０が提供する全ての取引イベント及び口座状態の履歴を保持する帳簿データベース１６５を管理する。帳簿データベース１６５における情報は、“ｌｔａｓｋ”モジュール１５０が機能しなくなる場合に、口座状態が障害迂回（fail-over）“ｌｔａｓｋ”モジュールに回復され得るように、バックアップを“ｌｔａｓｋ”モジュール１５０に提供する。シンボルデータベース１６３は、全ての取引された証券のマスターリスト（master list）を保持すると共に、各取引所に関するシンボル（symbol）の別名（alias）を含む。
【００２９】
好ましい実施例において、取引サーバ１３０は、１つ以上のプロセッサを備えると共に、各プロセッサは、１つ以上のスレッドを実行している。図１を参照すると、取引サーバ１３０は、“ＴＳ１  １３３”から“ＴＳｎ  １３７”までのプロセッサを備えると共に、ここで“ｎ”は取引サーバ１３０におけるプロセッサの数である。各プロセッサは、同じ取引サーバソフトウェア要素を実行するが、他のプロセッサとは独立して動作する。図１において示された構成の利点は、取引サーバ１３０が容易に拡張可能であるということである。更に多くの口座が活動的になるので、他の口座の処理によって引き起こされる容易に感知できる遅延を各口座が全く経験しないように、追加のプロセッサが加えられ得る。
【００３０】
同様に、“ｌｔａｓｋ”モジュール１５０は、取引サーバ１３０のプロセッサのインメモリコピーを維持する１つ以上のプロセッサを備える。“ｌｔａｓｋ”モジュール１５０におけるプロセッサの数は、取引サーバ１３０におけるプロセッサの数と同じ数を有していない。例えば、図１において、取引サーバ１３０は、ｎ個のプロセッサを有していると共に、“ｌｔａｓｋ”モジュール１５０は、ｍ個のプロセッサを有している。
【００３１】
注文のほぼリアルタイムの処理は、取引サーバ１３０における口座中心（account-centric）のパイプラインの使用を通して達成され得る。一般的な従来技術のシステムにおいて、ＣＰＵが市場供給システム（market feed）または外部データベースのような外部ソースのデータを待つ間、ＣＰＵサイクルの最高７０％が浪費される。スレッドは、ＣＰＵに、外部データのための待ち時間を減少させる傾向がある更に小さな増加量で注文処理を可能にさせる能力がある。しかしながら、実時間システムにおいて、遅延の有意の供給源は、２つ以上のスレッドが、データベースにおける同じ記録（レコード）にアクセスしようと試みるか、またはメモリにおける同じコンテナ／構造にアクセスしようと試みると共に、１つを除いて全てがアクセスを直列化するために阻止されなければならない場合のような、共用資源のコンテンションによって引き起こされる。本発明の新奇な特徴は、口座中心のパイプラインを作成することによって、コンテンション状況の可能性を取り除く。口座中心のパイプラインにおいて、各実行可能なスレッドは、口座と関連付けられると共に、同時に２つのスレッドが同じ口座を処理しないように、検査が実行される。これは、取引処理からの全てのロッキング（locking）及びロックチェッキング（lock checking）の除去を可能にすると共に、それによって現実の取引処理のための余分のＣＰＵサイクルを解消する。
【００３２】
図２は、本発明の好ましい実施例における取引サーバ１３０によって使用されるパイプライン／スレッディング（pipeline/threading）構造の図である。図２において、入力（inbound）Ｉ／Ｏ処理は、入力（inbound）ソケットメッセージを取得する。オペレーティングシステムによって信号が送信されたとき、そのＩ／Ｏは完全であると共に、メッセージは十分に受信され、メッセージはスタティックオーダーコンテナ（StaticOrder container）に復号化され、メッセージに関連付けられた口座が判定される。好ましい実施例において、ホストマシンがプロセッサを備えているので、ＩＯ完了ポート（IO completion port）は、２倍多くのスレッドを有する。
【００３３】
内部スレッドプール（internal thread pool）は、パイプライン待ち行列（queue）として機能する。スレッドプールは、スレッドを、パイプラインスレッド待ち行列において待つ固定的な注文メッセージの処理に割当てる。内部の割付けルーチン（allocator）は、たとえ他の待ち行列が待っていないとしても、２つのスレッドが同時に同じ待ち行列からの固定的な注文を処理することを防止するためのインターロックを備えている。
【００３４】
各パイプラインスレッドは、イベントプロセッサに含まれる一連の論理ステップを通して注文メッセージを処理する。注文処理は、全てのメッセージに関して、線形であると共に同じである。パイプラインスレッドは、全ての口座状態及びその口座に関する構成情報に対して、排他的なアクセスができる。
【００３５】
固定的な注文が全てのイベントプロセッサを通じて処理を完了した後で、固定的な注文の現在の状態、及び親注文、口座残高、そしてポジションに対するあらゆる変更に関して、出力メッセージが作成される。これらのメッセージは、１つの出力待ち行列に配置される。
【００３６】
単一のスレッドによって、出力待ち行列は、正確な注文を保証するように機能する。メッセージは、待ち行列から抽出されると共に、ゲートウェイ要素１２０、“ｌｔａｓｋ”モジュール１５０、データベース１７５、及びハンドラ１８０のような他の構成要素に送信される。
【００３７】
注文／イベントの口座中心のパイプライン処理は、定義されたシーケンスにおいて連続して遂行される論理の多くのステップによって実行される。論理ユニットの集合は、全て標準インタフェースを実装すると共に、それらは、総合的な親取引サーバから別々にコンパイルされ得る。パイプラインの種目、及びパイプラインの順番は、ランタイムに定義され得る。同じパイプラインが、種類に関係なく全ての注文／イベントのために使用される。パイプラインは、好ましくはジャンプ、中断、または反復せずに、順繰りに処理される。
【００３８】
各イベントプロセッサは、標準のベースインターフェースを実装する。各イベントプログラムの結果は、継続するか、もしくは一時中断するかどうかを示す。その場合に、もしその注文が一時中断されるならば、それに対して一時中断フラグがセットされるが、しかしその注文はパイプラインを通して継続する。大部分がそれを無視するであろうが、他のイベントプロセッサがそれを任意に処理し得る。非同期価格／時間イベントのような一時中断の原因が取り除かれたとき、後で、同じ注文が、再度パイプラインを通して還流し得る。
【００３９】
もし注文が処理イベントを失敗するならば、そのイベントに関連付けられた注文に対して失敗フラグがセットされるが、しかしその注文のパイプライン処理は継続する。次のイベントプロセッサは、既に失敗した注文に何もしない可能性があるが、しかし他のイベントプロセッサが、それをまだ処理し得る。失敗した注文は、最終の“spewPrep”イベントハンドラにおいて、新しいクラーク拒否（clerk reject）イベントが生成され、イベントと共に送信される原因となり、例えばもしマージンチェック（margin check）段階において注文が受信されて、しかし失敗である場合に、その場合に、その注文は失敗したとして印が付けられる（“STATE_DELETED”にセットされる）が、しかしほとんどのイベントプロセッサが失敗したイベントを無視するにもかかわらず、処理は継続する。“spewPrep”ステージにおいて、クラーク拒否（clerk reject）は、注文の失敗を示すために生成される。
【００４０】
口座情報がいくつかのイベントプロセッサによって必要とされ得る。イベントプロセッサを別々にコンパイルされたユニット（ｄｌｌ）に分割するために、口座及び内在するポジションデータに対する抽象化された（abstracted）インタフェースが、“ｄｌｌ”そのものに実装される。
【００４１】
いくつかのイベントプロセッサは、“ITradesrvEnvironment”インターフェースにおけるホッパ基準（hopper ref）の存在に従って、新しいイベントを同期的（例えば販売員が無効の注文を拒否する）もしくは非同期的（逆指値トリガ機能）にホッパ（hopper）に加える能力を必要とする。
【００４２】
“IAccount”及び“ITradesrvEnvironemn”は、口座に対する、そしてに非パイプラインＴＳ３環境（ホッパ（hopper）及びスピューオブジェクト（spew object））に対する抽象的インタフェース（abstract interface）である。バーチャルな方法と、抽象的観念基準のクラスまたはテンプレートが、これらのオブジェクトを性能要件に応じて実装するために使用され得る。
【００４３】
イベントプロセッサは、口座、処理されたイベント、及び口座によって所有されるあらゆる親注文または他の注文に対する自由なアクセスを仮定し得る。他のデータ構造に対するロッキング（locking）は、効率性のために最小限に留められる。イベントプロセッサは、ブロッキング（blocking）なしで完全にイベントを処理し続けるが、しかし、これが可能ではないならば、処理を中断する（例えば、“evtSuspended”を返す）と共に、待ち時間の後で、イベントを処理するために、内部スレッドまたはイベントコールバックスレッドを利用し、次に、イベントをホッパに示すことによって処理を再開する。
【００４４】
注文が一時中断されるとき、一時中断されたイベントプロセッサは、いくらかの後の時間に再開できるように、注文に対する参照を保持する。もし注文を再開するイベントがパイプライン（例えば、価格供給システムかタイマのいずれか）に非同期であるならば、その場合に、注文を再開するために、特別なイベント“ACTION_RESUME_SUSPENDED_ORDER”がホッパに配置される。このイベントは、再開されるべきイベントの注文ＩＤ及び口座番号を含む（すなわち、このイベントは、再開されるイベントの親である）。このイベントは、パイプラインに参加すると共に、正常な順序で各イベントプロセッサによって処理される。そのイベントの親に格納された一時中断したイベントプロセッサ名を照合することによって発見された、イベントの親を一時中断したイベントプロセッサに到達すると、一時中断された注文は、再開されたイベントに取って代わり、従ってイベントプロセッサのパイプラインの残りを伝ってフローを再開し得る。
【００４５】
“ConditionalOrder”イベントプロセッサは、ストップ（stop）注文、ストップリミット（stop limit）注文、トレーリングストップ（trailing stop）注文、及びより一般的な物価条件付注文（price conditional order）を扱う。ストップ（stop）注文、ストップリミット（stop limit）注文、トレーリングストップ（trailing stop）注文は、全て、注文に対する基準のインデックス付きストア、必要とされたシンボルの“ウォッチリスト（watch list）”、及び価格供給システム（price feed）に対する接続を使用して動作する。ストップ注文が処理されるとき、それは、シンボルのその時のストップ価格（stop price）に基づいてインデックスに格納される。シンボルは、基準カウント済みウォッチリスト（reference counted watch list）に加えられる。(もしそうでなければ既に存在する。)挿入は、価格供給システム（ＴＡ＿ＳＲＶ再結合器（TA_SRV recombiner））に対する助言（要求ではない）を誘起する。ストップ（stop）注文は、この時パイプラインにおいて更に処理されず、“イベントプロセッサ（eventProcessor）”コールの“イベント結果（EvtResult）”は、“イベント一時中断（evtSuspend）”になる。価格供給システムからのコールバックは、コールバックスレッドを用いて扱われる。シンボルのインデックスが発見されると共に、インデックスは、あらゆる誘起されたストップ注文を発見するために、通り相場で始まることが検討される。誘起されたストップ注文は、基準として誘起されたストップ注文のＩＤを含むと共に、ホッパに配置される“ORDER_TRIGGERED”イベント（例えば、“ACT1ON_RESUME_SUSPENDED_ORDER”イベント）に帰着する。ストップイベントプロセッサにおけるこのメッセージの処理は、インデックスからその注文を取り除くと共に、それがパイプラインを通じて継続することを可能にする。すなわち、オリジナルの注文は、更なる処理における“ORDER_TRIGGERED”イベント(例えば、“ACTION_RESUME_SUSPENDED_ORDER”イベント)
にとって代わる。誘起されたストップ注文は、更に、ウォッチリストにおけるシンボルの基準カウント（ref count）を減少させると共に、もしゼロならば、そのシンボルは取り除かれる。
【００４６】
“TimedOrder”イベントプロセッサは、時限注文（timed order）を扱うと共に、ウォッチリストが単にイベントの順序付けられた待ち行列であり、タイマが価格供給システムに取って代わることを除いて、ストップ注文と同じ方法で動作する。待ち行列における第１のイベントの時間を誘起するためにタイマが準備され、最初に“ORDER_TRIGGERED”イベント（例えば、“ACTION_RESUME_SUSPENDED_ORDER”イベント）を送信すると共に、誘発されたあらゆる次の注文を送信するように、待ち行列を誘発することが検討される。これらの注文は、その場合に待ち行列から除去される。タイマは、その場合に、再度待ち行列において第１のイベントを誘起するようにセットされる。新しい時限注文が受け取られるとき、ウォッチリスト待ち行列の先頭への挿入は、タイマをリセットすることを必要とする。ある時間から有効であると共にある時間まで有効である注文は、それらの２つの時間に関して、待ち行列に２つの入力を有することになる。
【００４７】
“ChronosEvent”イベントプロセッサは、注文を前もって処理すると共に、価格タイプ（price type）、満期タイプ（例えば期日（Day））に関するユーザ入力、ユーザ入力の時期、口座の下で維持される安定した時期（firm times）、そしてルート規則（route rule）、ルート構造（route structure）において維持されるルートセッション（route session）時期に基づいて、固定的な注文を内部の“effectiveGoodFrom”時間フィールド及び“effectiveGoodTo”時間フィールドに投入する。
【００４８】
組織化されない取引業者（non-institutional trader）が提供する口座に関する取引前マージニング（margining）検査が可能になるように、市場タイプの注文は、現在の一般価格情報を必要とすることになる。ゲートウェイ１２０に接続するために使用されるクライアントソフトウェアに応じて、この情報（例えば、終値（last price）、競り値（bid price）、売り呼値（ask price））は、注文と共に送信され得るが、しかし、常に注文の一部であることを保証されることができない。既に注文の中にある価格データ、及び取引前マージニング（margining）を必要としない口座タイプを考慮することによって、そのようなサーバの検索を必要とすることを回避するために、全ての努力が行われるべきである一方、いくらかの市場タイプの注文に関して、その価格は検索されなければならない。価格検索イベントプロセッサは、条件つきで誘起されるよりむしろ、価格データが戻されたときに注文がいつでも誘起されることを除いて、ストップ注文イベントプロセッサと同じ方法で動作する。
【００４９】
いくらかのクラスの注文タイプは、同様に、例えばオプションに関する基層（underlayer）のような、他の証券の情報を必要とし得る。例えば、このイベントプロセッサは、更に、例えば、証券のタイプ、注文の取引所及びルート（route）の要求に基づいて、そのようなデータを挿入し得る。
【００５０】
ハンドラ割り当てイベントプロセッサ（handler assigner event processor）は、連結されたハンドラの集合、及びルート許可データの集合を使用する。起動時に全ての許可は事前に読み込まれる（プリロードされる）が、しかし対応するルートは許可なしでは承認されることができないので、ルート許可オブジェクトは、接続されていないルートのために存在し得る。ハンドラ割り当てイベントプロセッサは、特定のハンドラに事前割り当てすることによって注文を処理するか、またはルーティング不可能（unroutable）として注文を拒絶する。ルートに対して１つより多いハンドラが存在する場合、基礎的ラウンドロビン（round-robin：総当たり戦）、または別の負荷バランシング戦略が使用される。その事前割り当ては、“RoutableOrderReroute”イベントプロセッサによるあらゆる必要な内部の再ルーティングを反映する“reroute_exit_vehicle”フィールドに基づいている。注文は、“claimed_by_clerk”フィールドを特定のハンドラのユーザ領域値にセットすることによって、事前割り当てされる。キャンセル、変更のような注文に関するイベントは、親注文の事前割り当てをコピーすると共に、このモジュールによって無視される。
【００５１】
“RoutableOrder Reroute”イベントプロセッサは、多くの入力引数に基づいて、注文に関する可能な新しい出口媒体（exit vehicle）を決定するために、再ルーティングルール（rerouting rule）の現存する“OrdRoute”メモリキャッシュを使用する。その結果は、注文の“reroute_exit_vehicle”フィールドに入れられる。
【００５２】
“Blotter Order”イベントプロセッサは、ブロッター注文（blotter order）を扱うと共に、それは１つのタイプの複数の注文の間で共通の関係を有する。ブロッター注文（blotter order）の例は、段階的な注文（stage order）、ＯＣＯ（オーダキャンセルオーダ：order-cancel-orders）、及びＯＳＯ（オーダセンドオーダ：order-send-orders）を含む。例えば、段階的な注文（staged order）において、その関係は親注文と子注文との間にある。段階的な注文（staged order）プロセッサは、もし口座がそれらを入力する許可を与えられるならば、段階的な注文を受け入れることになると共に、“ticket_id”に関して、あらゆる“普通の”注文を段階的な注文の親のタイプと照合することになる。段階的な注文の識別された子注文は、適合シンボル、サイド（side）、支払可能価格（もし親が限界であるならば）等に関して認証される。量制御を達成するために、（要求が満たされた、または存続する（filled or live））全ての子注文量の合計は、親の段階的な注文の量を超えることはできない。
【００５３】
“Handler Reconnect”イベントプロセッサは、特別なイベントタイプ“ROUTE_RECONNECT”を処理する。ハンドラの再接続に関して、取引サーバは、そのルート上の全ての係属中の注文に関してキャンセルを送信しなければならず、これは遠隔の取引所に届いたが、しかしハンドラの機能停止のために受諾されたと報告されなかったあらゆる注文をキャンセルすることになる。ハンドラの機能停止のために遠隔の取引所に届いていない注文に関するキャンセル拒否は、それらの注文の状態を係属中（pending）から終了（dead）に変換することになる。ハンドラの再接続は、各口座に関する“ROUTE_RECONNECT”に帰着し、それは、出口媒体（exit vehicle）及び特定のハンドラを識別する“claimed_by_clerk”フィールドだけを含む。このイベントプロセッサは、好ましくは、イベントにおいて詳述されたハンドラに関してあらゆる係属中の注文に対する口座注文帳簿（account order book）を検索し、そして、それらの注文に関するキャンセルを作成し、そして、それらをホッパに入力する。
【００５４】
“SystemCommand”イベントプロセッサは、原簿サーバから口座を再読み込み（リロード）する、口座のアクセス権（account perms）を再読み込み（リロード）する、マージン規則（margin rules）を再読み込み（リロード）する等のような口座中心の管理コマンドを許容する。
【００５５】
“StaticValidation”イベントプロセッサは、そのタイプ及び状態に基づいて注文／イベントに関する固定的なサニティーチェック（sanity check）を実行する。このイベントプロセッサが“eventProcessor”インターフェースに適合し、従って口座情報を有する一方、イベントプロセッサはそれを使用しない。妥当性検査（Validation）は、例えば“order_id”が存在するか？、“USER_SUBMIT_ORDER”は価格タイプを有しているか？等のような注文を分析する固定的な規則を使用して実行される。
【００５６】
“AccountEventAHowed”イベントプロセッサは、イベントが許可されるかどうかを決定するために、口座のアクセス権（account permissions ("perms")）を使用する。
【００５７】
“AccountCheckMargin”イベントプロセッサは、“user_submit_order”及び“user_submit_change”に関して動作する。口座が（制度上の）マージンチェックを必要としないならば、イベントプロセッサは何もしない。もし注文がクライアントの初期段階のアプリケーション（front-end application）から供給されるならば、マージンチェックは、グローバルな構成設定に基づいて任意である。もしマージンチェックが必要とされるならば、その注文は、委託保証金（margin requirement）を得るために、口座のマージン規則に適用される。これは、最も悲観的なアプローチを用いて、現在の利用可能な余分の口座の純粋価値（equity）から、口座に対する以前に受け入れられた、係属中であるか、もしくは存続している全ての注文の委託保証金を差し引いた額と照合される。マージンを必要とする係属中の注文は考慮されるが、マージンをリリース（release）する注文は考慮されない。同じ理由のために、ストップ注文及び時限注文は、入力されたときにマージンチェックされるが、誘起されたときにはマージンチェックされない。もし十分なマージンがあるならば、その注文は受け入れられると共に、必要とされるマージンが注文に記載される。
【００５８】
市場タイプ注文は、マージンをプリチェック（precheck）するために、競り値（bid price）／売り呼値（ask price）の情報を必要とする。情報は、クライアントによって供給されるか、もしくは“PriceSecuritylnfoRequired”イベントプロセッサにおいて供給される。
【００５９】
マージン計算器（margin calculator）に供給される出来高（volume）が、注文に関して既に処理された何らかの部分的なフィル（fill）によって縮小されることを除いて、注文と同じ方法で、変更内容が考察される。口座に対する以前に受け入れられた、係属中であるか、もしくは存続している全ての注文の委託保証金を合計するときに、変更されたオリジナルの注文は考慮されない。もし変更を可能にするのに十分なマージンがあるならば、オリジナルの注文の“marginRequired”フィールドは、変更された委託保証金の新しく計算された値に変更される。
【００６０】
利用可能なマージンをチェックしているとき、値幅の傾向（足：leg）を形成すると共に、更に低い全体の委託保証金に帰着するべきである注文のセットの反対売買（offsetting）の効果が考慮され得る。
【００６１】
“AccountAdjustMargin”イベントプロセッサは、“exchange_trade”及び“exchange_bust”に関して動作する。口座が（制度上の）マージンチェックを必要としないならば、イベントプロセッサは何もしない。もしマージンチェックが必要とされるならば、フィル（fill）（または、バスト（bust））が、委託保証金（または、既得権利の返還）を得るために、口座のマージン規則に適用される。その場合に、これは、利用可能な余分の口座の純粋価値（equity）を減少させる（または、増加させる)。
【００６２】
注文における貸付残高量（outstanding quantity）の委託保証金が公正であるように、部分的フィルに関して、オリジナルの注文の“marginRequired”フィールドは、ちょうど口座の余分の純粋価値を取り除いたマージンの量だけ削減される。合計のフィルに関して、オリジナルの注文の“marginRequired”フィールドはゼロに合わせられる。
【００６３】
“AccountAdd Position”イベントプロセッサは、“exchange_trade”及び“exchange_bust”に関してだけ動作すると共に、取引またはバスト（bust）を反映するために、口座のポジション収集を修正する。ポジション及び経常収支（積立金（Deposit））に対する変更は、スピュー待ち行列（spew queue）に即座に入れられる“TAL”ブロックを作成することによって、“ITask3”及びゲートウェイに送信される。
【００６４】
“UpdateOrderState”イベントプロセッサは、為替中止イベント（exchange kill event）が注文状態を削除に変更する場合のように、現在のイベントを受け入れると共に、固定的な規則に基づいて、オリジナルの注文の状態を更新する。“Exchange Trade”、“Exchange Kill”、“Exchange Bust”、“(変更の)Exchange Accept”、“Clerk Accept”、“Clerk Reject”は、全てオリジナルの注文状態に影響を与える。このステージでは、もしイベントの中に前から存在していなければ、注文からイベントに、固定換算（fix translation）のために必要とされる特定のフィールドがコピーされる。これらは、平均価格、取引量等を含む。
【００６５】
“FeesAndCommissions”イベントプロセッサは、“exchange_trade”及び“exchange_bust”に関してだけ動作する。それは、余分の口座の純粋価値に影響を及ぼす、料金（fee）、手数料（commission）、及び利幅（markup）を計算することになる。もし利幅があるならば、“T_PRICE_MARKUP”が利幅量によってセットされ、一方価格は、利幅を含む総額であるように調節される。クライアントは、利幅を提示されないかもしれないが、しかし他のシステムは、それを必要とし得ると共に、従って、正味価格が計算され得る。
【００６６】
“Suitability”イベントプロセッサは、“user_submit_orders/changes”に関して、ルートに関する規則、及び口座の構造において保持された総計に基づいて、適合性チェックを実行する。
【００６７】
“PositionRequest”イベントプロセッサは、新しいタイプの“USER_POSITION_REQUEST”を有するダミー注文を処理する。その要求は、“ＴＱＬ”を理由フィールドに含む。口座ポジション、口座バランスは、（恐らくは複数列の）応答ブロック内に生成され、応答ブロックは、要求側ゲートウェイだけに送信されるように、即座にスピュー（spew）に入れられる。応答ブロックは、標準のフォーマットである“CMessage”にフォーマットされる。
【００６８】
ゲートウェイは、クライアントコンポーネントからのポジション要求を受信すること、及び、取引サーバが要求を扱う必要がないように、要求をちょうどあらゆる他の注文／イベントと同じように取引サーバに送信される“USER_POSITION_REQUEST”イベントに変化させることに関与する。
【００６９】
他のイベントプロセッサは、“USER_POSITION_REQUEST”を無視すると共に、それらは、“ITask”及び“XML”ライタ（XML writer）に送信されない。
【００７０】
“SpewPrep”イベントプロセッサは、入力イベントを受け入れると共に、スピュー処理によって接続された通話上で取引サーバに送信され得るブロック出力を生成する。このイベントプロセッサは、必然的に、パイプラインにおける最後のものになる。もしイベントが失敗しなかったならば、それは、処理された注文、及びその関連するオリジナルの注文（もしあるならば）を取得し、それらをブロックに導く。このブロックは、“OutputMessage”（以前は、“CMessage”）の中に置かれると共に、“OutputMessage”の出口媒体及びハンドラマシン（handler machine）は、イベントの出口媒体及びハンドラマシンからセットされる。“OutputMessage”は、それからスピュー待ち行列に加えられる。もし処理された入力イベントが失敗したと前のイベントプロセッサによって示されるならば、入力イベント内の理由テキストを使用すると共に、入力イベントの注文ｉｄを参照して、口座注文帳簿にクラーク拒否イベント（clerk reject event）が生成される。この新しいイベントは、入力イベントと共にブロックに導かれると共に、“OutputMessage”に挿入される。“OutputMessage”は、それからスピュー待ち行列に加えられる。
【００７１】
既知の注文タイプに加えて、本発明の実施例は、複数の部分から構成される注文を処理することができる。複数の部分から構成される注文は、取引所によって１つのシンボルとして実施されない合成の値幅を作成して、実行するために使用され得る。値幅は、２つの足がある値幅、または蝶のように更に複雑な複数の足がある値幅であり得る。合成の値幅を作成して、実行することに加えて、複数の部分から構成される注文は、オーダキャンセルオーダ（Order-Cancels-Order：ＯＣＯ）、オーダセンドオーダ（Order-Send-Order：ＯＳＯ）、カバードコール（Covered Call）、及びバスケット注文（Baskets）を実行するために使用され得る。複数の部分から構成される注文タイプは、複数の部分から構成される注文を作り上げる全てのサブ注文のための集合ポイントとして機能する。各サブ注文は、複数の部分から構成される注文に対する結合タイプ（linkage type）及びキャンセルタイプ（cancellation type）によって特徴付けられる。結合タイプ（linkage type）は、例えば合成の値幅のような、複数の部分から構成される注文のタイプを定義する。キャンセルタイプ（cancellation type）は、複数の部分から構成される注文における他のサブ注文がサブ注文のキャンセルによってどのように影響を受けるかを特性化する。“一括売買（All-or-None）”タイプにおいて、もし複数の部分から構成される注文の任意のサブ注文がキャンセルされるか、もしくは取り消されるならば、取引サーバは、複数の部分から構成される注文の他の全てのサブ注文をキャンセルしようと試みることになる。“アトミック（Atomic）”タイプにおいて、サブ注文のキャンセル及び取り消しは、複数の部分から構成される注文の他のサブ注文に影響を及ぼさない。“自律状態（Autonomous State）”において、サブ注文のキャンセル及び取り消しは、複数の部分から構成される注文の他のサブ注文に影響を及ぼさないと共に、もし全てのサブ注文がキャンセルされたとしても、複数の部分から構成される注文は消滅せずに維持されることになる。“自律状態（Autonomous State）”の複数の部分から構成される注文は、存続する一方、新しいサブ注文の追加を許可すると共に、複数の部分から構成される注文の明白なキャンセルによってのみキャンセルされ得る。各サブ注文は、他のサブ注文とは無関係に処理されると共に、実行のために異なる取引所に送信され得る。
【００７２】
本発明の好ましい実施例において、注文管理システムは、ユーザが、例えばパーソナルデスクトップコンピュータ（ＰＣ）、またはラップトップコンピュータ上に実装されると共に表示されたグラフィカルインタフェースを通じて相互に作用するために利用可能である。しかしながら、他の実施例は、例えば単独型（stand-alone）ワークステーション、または更にハンドヘルド装置（hand held device）のような、グラフィカルインタフェースをユーザに提供するための代替えの手段を備え得る。
【００７３】
更に、本発明の好ましい実施例において、注文管理システムは、許可システムを首尾よく通過した後のユーザによってのみアクセスされる。許可システムは、ユーザが、彼または彼女が取引する権限を与えられるそれらの金融為替市場にだけアクセスすることができるということを保証する。仲買人のようなユーザにとって、別のものではなく、１つの金融為替市場において安全な取引を行う権限を与えられることが可能であるので、この特徴は、本発明において取引されるために利用可能な金融為替市場の完全性を保証するのに必要とされる。
【００７４】
本発明のシステムは、伝統的な取引所、電子的な取引所、及び代替えの取引所における取引に使用され得る。参考までに、表１は、本発明によって支援された北米の取引所及び外国の取引所の代表的なリストを表示する。本発明の実施例が、表１において示された取引所のリストによって制限されないと共に、他の取引所の支援が本発明の範囲内にあるということが理解されるべきである。
【００７５】
【表１】
0005414520.tif 000002
【００７６】
外国電子為替市場において証券を取引することは、注文管理システムによって支援され、ユーザは、デフォルトの自国通貨を国内市場と関連付けるようにセットできる。システムは、デフォルトの通貨と調和させるために、全ての外貨の変換を行うための通貨変換器（currency converter ）を備える。代替案として、注文管理システムは、外国為替または外貨において取引される全ての証券に証拠金を追加するように構成され得る。
【００７７】
首尾よく所望の電子為替市場に対するアクセス許可を得た後で、ユーザは、グラフィカルユーザインタフェースを形成して、パーソナル化（個人化）することができる。例えば、グラフィカルユーザインタフェースは、ユーザ定義されたフィールドをスクリーンに例示する多くのウィンドウを表示する。グラフィカルインタフェースに関するデータフィールドは、ストリーミングデータプロバイダを通じて接続されることによって提供される。金融取引所からのストリーミングデータは、定期的に、例えば終日にわたって毎分、グラフィカルインタフェースのデータフィールドに対して更新される。グラフィカルインタフェース上で表示され得るデータフィールドのいくらかの例は、ティッカー（ticker）の最新情報、取引された証券に関する現在の相場（quote）、所望のニュースソースからの金融市場最新ニュース、統合されたウェブブラウザ、金融研究ツール、及びユーザに市場の高値及び安値の警報を出すアラームスクリーンを表示する表示ウィンドウを含む。
【００７８】
更に、本発明のグラフィカルインタフェースは、ユーザが下記のような機能を遂行することを可能にすることによって適応性がある。ユーザは、“シンボルガイド（Symbol Guide）”または現存するウィンドウからシンボルをドラッグ（drag）し、それを“ツールバーボタン（Toolbar button）”上にドロップ（drop）し、即座にその道具（instrument）に関する新しいウィンドウを作成することにより、１回のマウスクリックで新しいウィンドウを作成することができる。ユーザは、ティッカー、チャート、及び他の利用可能なプラグイン機能／道具に道具を追加するか、もしくはティッカー、チャート、及び他の利用可能なプラグイン機能／道具の間で道具を移動させるために、ドラッグアンドドロップ（drag-and-drop）することができる。ユーザがシンボルを加える調査報告書（study）またはスクリーンは、新しい道具の情報によって即座に更新されることになる。ユーザは、最も使用されるウィンドウに関する準備プロセスを回避するために、“お気に入り（Favorite）”を使用できる。ユーザは、調査報告書（study）を単に“お気に入り（Favorite）”としてセーブし、その後、シングルクリックによって、別のページで、ユーザの好みの色、レイアウト、テクニカル分析等を含んで、再形成する（recreate）ことができる。ユーザは、“ホットキー（HotKey）と呼ばれるユーザ定義のショートカットキーによって、ページの間を迅速に移動することができる。ユーザは、同時に様々なウィンドウの内容を変更することができる。“ウィンドウトゥウィンドウ（window-to-window）”連結によって、ユーザが１つのウィンドウにおいてシンボルを変更するとき、同じページの全ての連結されたウィンドウのシンボル選択は、従って変わることになる。ユーザは、無制限のカスタマイズされたページを作成すると共に、全てのフォント及び色を制御することができる。
【００７９】
ユーザは、いつでも、証券取引の実行の前もしくは証券取引の実行の後で、グラフィカルインタフェースを更新すると共に変更することができる。グラフィカルユーザインタフェース変更処理は、好ましくは取引の実行の前に行われる。
【００８０】
ユーザが所望のフィールドを表示するためのグラフィカルインタフェースのセットアップを終了した場合に、注文管理システムは、グラフィカルユーザインタフェースを通していつでもユーザが入力した証券取引を受理することができる。普及している慣例と同様に一度に１つの注文のみを管理する代りに、複数の部分から構成される証券取引注文を扱うことができるという点で、本発明は独特である。この追加された複数の部分から構成される注文管理能力は、システムが拡張された範囲のタイプの複合的な注文スキームを扱うことを可能にする。特に、追加された複数の部分から構成される注文を実行する能力に関して、注文管理システムは、オーダキャンセルオーダ（Order Cancel Order：ＯＣＯ）、オーダセンドオーダ（Order Send Order：ＯＳＯ）、一括売買注文（All or None order）、及びバスケット注文（Basket order）のような、複合的な注文スキームを処理することができる。
【００８１】
オーダキャンセルオーダ（Order Cancel Order：ＯＣＯ）は、一緒に出される注文のグループであり、グループの中から注文の１つが実行される場合に、注文の残りはキャンセルされる。このタイプの注文は、連結されない個々の複数の部分から構成される注文に関して、最高の委託保証金を有している。
【００８２】
オーダセンドオーダ（Order Send Order：ＯＳＯ）は、一緒に出される注文のグループであり、１つの注文が“稼働”状態になると考えられている。その場合、“稼働”状態の注文が実行され、そして別の注文を誘発するようにセットされる。その場合に、グループの残っている別の注文は、“稼働”状態であるとタグを付けられると共に、それが実行されるとき、全ての指定された注文が実行されるまで、残っている別の注文等を誘発する。このタイプの注文は、全ての連結された連続する複数の部分から構成される注文に関して、最高の委託保証金を有している。
【００８３】
一括売買注文（All or None order）は、実行のために出される注文のグループであって、それらは、“ＯＣＯ”または“ＯＳＯ”戦略に従うか、または値幅注文（spread order）であるか、またはバスケット注文（basket order）であろう。しかしながら、一括売買の属性は、１つの注文がキャンセルされるか、もしくは取り消された状態になるならば、全てのその他の注文が自動的にキャンセルされることになるということを意味する。このタイプの注文に関する委託保証金は、グループに関する全体の委託保証金である。
【００８４】
バスケット注文（Basket Order）は、一緒に出される独立した注文のグループであり、その場合に、委託保証金はそれらが順々に出されたかのように計算される。しかしながら、ユーザの口座の購買力が不十分であるならば、全体のバスケットが拒絶される。好ましくは、バスケット注文の部分的な提出は許可されない。
【００８５】
従来技術において知られているように、注文管理システムは、全ての他のタイプの複合的で、及び／または複数の部分から構成される証券取引注文を扱うことが可能である。
【００８６】
ユーザ定義の取引が金融取引システムにおいて実行される前に、ユーザの口座のポートフォリオをスキャンすると共に、潜在的リスクをユーザに通告するために、注文管理システムの一部としてリスクマネージャが提供される。リスクは、クレジットアットリスク（Credit at Risk：ＣａＲ）、及びバリューアットリスク（Value at Risk：ＶａＲ）という２つの成分の計算により、リスクマネージャによって決定される。
【００８７】
“ＣａＲ”は、口座の純粋価値（equity）レベルと口座の負債レベルとの間の相対的な状況を比較することによって、ユーザの（例えば、仲買人の）口座信用リスク（account credit risk）を監視する、十分にリアルタイムの報告ツールである。機能として、クレジットアットリスク（Credit at Risk：ＣａＲ）は、注文管理システムによって、委託保証金より少ないユーザの口座の口座総合残高（Net Liquidation）の値として計算される。
【００８８】
“ＣａＲ”は、リスクマネージャがユーザに関する信用購買力（credit buying power）を決定することを可能にする。一度信用購買力が決定されれば、その値は、ユーザのプリセットされた金融政策と比較される。リスクマネージャは、その場合に、ユーザに対して、彼または彼女の金融政策がユーザの潜在的な取引決定によって違反されることになるときに警告し得る。リスクマネージャは、潜在的な証拠金請求、及び／またはユーザのポートフォリオにおけるポジションの強制破産のような、ユーザの金融政策のあらゆる妨害を緩和するための提案を提供することができる。
【００８９】
“ＶａＲ”は、特定のレベルの信頼によって、一定期間にわたって金融資産（金融ポートフォリオ）が失うかもしれない金の量である。例えば、（１００ドル、１日、９５％）によって表された“ＶａＲ”は、１日の期間の間に１００ドル以上失わないことの９５％の確率を有するポートフォリオを示す。米国の金融市場において、“１日間、９５％”の標準の報告様式は、“ＶａＲ”を報告することに関する支配的な基準として知られている。しかしながら、ヨーロッパにおいて、その標準の報告様式は、更に保守的な“１０日間、９９％”の報告様式となる。現在の注文管理システムが、米国の市場及びヨーロッパの市場の両方を含む世界市場のためのものであるので、それは、他の所望の形式と同様に、“１日間、９５％”と、“１０日間、９９％”の両方の標準書式を計算し得る。
【００９０】
“ＶａＲ”を計算する際、興味のある主要な歴史的なデータは、ユーザのポートフォリオにおける各証券に関するヒストリカルボラティリティ（historical volatility）情報である。ボラティリティ（予想変動率）を推定するための多くの既知の業界の慣行があると共に、その最もポピュラーなものは“単純移動平均（Simple Moving Average）”、“指数加重移動平均（Exponentially Weighted Moving Average）”であり、更に一般的なものは“GARCH方法”である。好ましい実施例において、本発明の発注管理システムは、ボラティリティ（予想変動率）を推定するために、高値−安値範囲（High-Low range）のボラティリティのパーキンソンの方法（Parkinson's method）を使用する。パーキンソンの方法は、取引日の間中、他の方法より金融市場取引の変遷の型（dynamics）の更に良い理解を提供すると共に、分散の変化に対して更に敏感であると考えられている。ボラティリティを推定するためにパーキンソンの数値（Parkinson Numbers）を使用することの利点は、所定の精度におけるボラティリティを推定するために、回帰ベースの伝統的方法を使用することで必要になるデータ量と比べて少ないデータが必要とされることである。所定の精度におけるボラティリティを迅速に推定する能力は、取引日の間重要であり得る。
【００９１】
パーキンソンの高値−安値範囲（High-Low range）のボラティリティは、あらゆる特別な期間における高値、安値を使用して、ランダムウォークに対する収益（return）のボラティリティを推定する。一般的に、パーキンソンの高値−安値ボラティリティの数値は、以下の数式のとおりに計算される。
【００９２】
【数１】
0005414520.tif 000003
【００９３】
ここで、“Ｈｔ”は期間の高値、及び“Ｌｔ”は期間の安値であり、“ｎ”は、所定の量の時間にボラティリティが計算された回数の数値を表す。
【００９４】
取引所で証券を取り引きするという状況において、“Ｖ”は、特定の証券に関する収益の標準偏差の推定値である。収益率“Ｒ”は、以下の式のとおりに定義される、期間の間の継続的な複利率（compound rate）である。
【００９５】
【数２】
0005414520.tif 000004
【００９６】
ここで、“Ｐ１”期間１における終値であり、“Ｐ０”は過年度（前期）の終値である。
【００９７】
注文管理システムのリスクマネージャは、全ての収益率を継続的に毎日の百分率（パーセンテージ：percentage）に標準化する。ボラティリティが取引日の間の毎日の高値及び安値に基づく毎日の収益率の測定値であるので、この数値は単に推定され得る。追加された測定値が可能な限りの最も良い推定値を提供するように、リスクマネージャは、単に、そのボラティリティの推定を、所定の時間、例えば取引日が始まって１時間で始めることになり、それは、市場における偶然要因の影響を最小限にすることを援助することになる。パーキンソンの方法を使用する日内のボラティリティの推定は、以下の式のとおりである。
【００９８】
【数３】
0005414520.tif 000005
【００９９】
ここで、“Ｈ”及び“Ｌ”は、それぞれ取引日の開始から現在の時間までの高値及び安値であり、“ＴＤ”及び“Ｔ０”は、それぞれ取引日の期間及びその日証券がその取引を始めた以後の期間である。この推定値は、資産価格が、対数正規分布すると共に、連続した独立性を有すると推測する。
【０１００】
上述の日内のボラティリティの推定は、取引時間の間にボラティリティを獲得するが、更に、情報分散と関連付けられたボラティリティのような、かなり異常な短期のボラティリティを含む。この問題に取り組むために、本発明の発注管理システムは、約１０日〜１５日に値する過去におけるパーキンソンのボラティリティの推定値を格納するための記憶装置手段に対するアクセスを有している。以下の式のとおりに、過去の取引日の日内の数値に関する２乗された平均値は、“ＶａＲ”の数値を計算するために使用される最終のボラティリティの数値である。
【０１０１】
【数４】
0005414520.tif 000006
【０１０２】
一般的に、“ＶａＲ”値を獲得するために包含される計算は、計算的に集中的であると共に、金融派生商品が包含されるときには、更に集中的である。金融派生商品を取引する方法を扱っているときに処理を管理できる状態にするための、産業において知られているいくらかのアプローチがある。１つのアプローチは、オプション理論値（option theoretical value）を計算するために、デルタ−ガンマ推定（delta-gamma estimation）を使用することである。このアプローチにおける欠点は、その方法が、原資産（すなわち、選択権付契約（option contract）または転換証券（convertible security）の実行に関する交付に支配される証券または商品；例外は、交付されることができず、従って現金において処理される株価指数オプション、及び先物を含む。）の動きが比較的小さいときの状況にだけ対処し得ると共に、従って、不安定な証券に対する金融派生商品のリスクを過小評価することに帰着することである。“ＳＰＡＮ”及び“ＴＩＭＳ”のような他の方法は、十分な評価モデルを使用し、更に正確なリスク評価を可能にするが、しかし大部分のシステムリソースを消費する。計算の増加量のせいで負担する時間を制限することを目的として、“ＳＰＡＮ”及び“ＴＩＭＳ”システムは、夜間のバッチ処理においてサーバ側で大部分の複雑な計算を実施すると共に、その結果生じる理論上のデータをリスクアレイ（risk array）に格納する。このような方法で、リスクマネージャプログラムは、リスクアレイからデータをフェッチ（fetch）することだけを必要とし、処理時間を著しく減少させ得るリスクレポートを作成しているときには簡単な演算を計算する。
【０１０３】
本発明の発注管理システムの好ましい実施例は、２分毎に日内のボラティリティを推定しリスク分析を実施することによって、“ＳＰＡＮ”及び“ＴＩＭＳ”方法を改良することに関して、更に一歩先を行くと共に、それは、パーキンソンの方法の簡素性によって可能にされる。リスク分析を２分毎に更新することは、リスクマネージャが、可能な限りの総合的なリスクの警報を提供するために、最新の市場データを利用することを可能にする。
【０１０４】
表２は、株式（stok）、公債（bond）、先物（future）のような線形の証券モデルに関する理論値を決定するときにリスクマネージャによって作成されたリスクアレイに対応する。表２において示されたリスクアレイは、１９個の配列要素に、現在の取引価格と比較した物価指数を格納する。中央位置は“１”として初期設定されており、価格そのものを表していると共に、他の位置は、異なるシナリオに基づく現行価格に対する比率としての理論価格である。
【０１０５】
【表２】
0005414520.tif 000007
【０１０６】
表２のリスクアレイにおいて、株式は“２．５％”の毎日のボラティリティを有していると共に、“Ｚ”は標準の正常な確率変数であると仮定される。例えば、“−５”のポジションで、株式の理論値は、現行価格の“０．９６”倍である。この点において、“Ｚ＝−１．６５”であるので、株式価格がこの数値より下であろうという“Ｎ（Ｚ＜−１．６５）＝５％”の見込みがあり、ここで、Ｎ（ｘ）は、標準の正常な累積分布である。１日の予測に関して、ポジション“−６〜６”は十分である。しかしながら、その予測が１０日に拡張されるとき、“√Ｔ”公式が適用されなければならない。（すなわち、Ｔ＝１０のとき“δ１０＝√Ｔ×δ”である）。“値＝ｅＺδ”であるので、“Ｚ”に“√Ｔ”公式を適用することと同等である。従って、１０日間の予測のために、ポジション“−９”、ポジション“−８”、ポジション“８”、及びポジション“９”が使用される。
【０１０７】
今までのところ、株式（stok）、公債（bond）、先物（future）のような線形の取引モデルの“ＶａＲ”を決定することに関する説明が論じられた。しかしながら、金融派生商品のような非線型モデルに関しては、更に複雑な計算手段が通常必要とされる。本発明の注文管理システムは、安全金利（risk free interest rate）を使用すると共に、理論上の計算を援助するために原資産のボラティリティを計算する取引前リスクマネージャを備えることによって、金融派生商品を扱う。いくつかの実施例において、リスクマネージャは、処理を単純化するために、保有期間にかかわらず“５％”の安全金利を使用すると共に、原資産のボラティリティを計算するために、ブラックショールズモデル（Black-Scholes model）が使用される。
【０１０８】
表３は、金融派生商品の証券に対応するリスクアレイを表示する。リスクアレイのためのフォーマットは、表２の線型モデルのフォーマットと類似している。差異は、ボラティリティ及び“Ｚ”の値が、金融派生商品それ自身の代わりに、原資産を代表すると共に、それらの値は、より簡単なパーキンソンのモデルの代わりに、より複雑な非線形のブラックショールズモデルに基づいている。
【０１０９】
【表３】
0005414520.tif 000008
【０１１０】
ブラックショールズモデルは、以下のとおりに使用される。ここで、Ｐ＝オプション価格（Option Price）は、ブラックショールズの関数を用いて決定され、“Ｐｕ＝原資産価格”、“Ｒｆ＝安全金利”、“Ｔ＝満期までの時間”、及び“Ｖ＝原資産ボラティリティ”に関して、“Ｐ＝ブラックショールズ（Black-Scholes）（Ｐｕ、Ｒｆ、Ｔ、Ｖ）”となる。
【０１１１】
本発明のシステムは、ニュートンラプソン推定（Newton-Raphson estimation）を使用してインプライドボラティリティ（implied volatility：予想変動率）（Ｖｏ）を求めるために、現在のオプション価格を使用する。以下の式によるリスクアレイは、オプションに関して計算されると共に、ここで“ｉ＝−９、−８、．．．、０、．．．、８、９”であり、“Ｒｕｉ”は原資産に関するリスクアレイである。
【０１１２】
【数５】
0005414520.tif 000009
【０１１３】
シミュレートされた物価指数ポイントは、原資産の物価指数ポイントと同じ可能性を有する。これは、システムが、同じ原資産を有するポジションのグループに関して、市場価値のリスクアレイを容易に組み立てることを可能にする。
【０１１４】
リスクマネージャは、財政的な裏付けのある注文（financially sound order）を発行する際に、補助としてユーザに対して他の値を計算して中継する。例えば、以下の変数は、オプションタイプの取引に関して計算され得る。しかしながら、それらは、全てのタイプの証券取引に適用され得る。デルタは、原資産の単価変化当たりのオプション価格の変化であると共に、ブラックショールズ公式（Black-Scholes formula）の一次導関数である。ガンマは、原資産の単価変化当たりのデルタの変化であると共に、ブラックショールズ公式（Black-Scholes formula）の二次導関数である。ベガは、原資産の年換算の予想変動率（volatility）の百分率変化（percentage change）当たりのオプション価格の変化である。シータは、残余期間（time-to-expiration）における１日の減少当たりのオプション価格の変化である。ラムダは、原資産における１パーセント変化当たりのオプション価格の百分率変化である。
【０１１５】
口座のポートフォリオにおける各ポジションに関して、市場価値のリスクアレイは、以下の式のとおりに計算され、ここで、“Ｒｉ”は、証券に関するリスクアレイである。
“ｍｖｉ＝価格（price）×出来高（volume）×Ｒｉ”
その結果、ポートフォリオは、原資産グループ（すなわち、同じ原資産を有するポジションのグループ）に分割される。その場合に、市場価値のリスクアレイは、以下の式のとおりに総計を求められる。
“ＵＭＶｉ＝Σｍｖｉ”
原資産グループにおける全てのポジションが同じ原資産を有するので、それらの市場価値の変動は相互に関連付けられる。リスクアレイの各ポジションが原資産の変動の１つの可能なシナリオを表すので、原資産グループの市場価値（underlier group market value）のリスクアレイは、各シナリオに関してグループの可能な市場価値を含む。各シナリオの“Ｚ”値及び累積確率は、原資産のリスクアレイと同じである。
【０１１６】
従って、表２及び表３で提示されたような１８個のシナリオは、デルタ変数及びラムダ変数の推定を可能にさせる。リスクマネージャは、ユーザの取引決定に基づいて、ユーザのポートフォリオに対する潜在的な財政面での影響を認識すると共に、救済策を提案することができる。リスク、それらの施策、及び適切な救済策のタイプの例は、以下の表４において要約される。
【０１１７】
【表４】
0005414520.tif 000010
【０１１８】
特にポートフォリオが複数のタイプの資産及び金融派生商品を含むとき、ポートフォリオに関する“ＶａＲ”値を総計する完璧な方法はない。総計の“ＶａＲ”を推定するために、リスクマネージャは、以下の表５に示された単純化された仮定を立てる。
【０１１９】
【表５】
0005414520.tif 000011
【０１２０】
注文管理システムは、以下の式を適用することによって標準偏差を推定するために、原資産グループの市場価値のリスクアレイを使用すると共に、ここで、“Ｐ（ｘ）”は、値“ｘ”の確率であり、“ｕ”は、算術平均である。
【０１２１】
【数６】
0005414520.tif 000012
【０１２２】
ポートフォリオが多様的であるとみなされるので、全ての原資産グループの市場価値の和としてのポートフォリオの市場価値は、一般的に分散する。従って、ポートフォリオの市場価値の標準偏差は、次式のように計算され、ここで、“δｉ”は、原資産グループの市場価値の標準偏差であり、“ρｉｊ”は、原資産グループ“ｉ”と原資産グループ“ｊ”との間の相関係数である。
【０１２３】
【数７】
0005414520.tif 000013
【０１２４】
従って、“ＶａＲ”値は、ポートフォリオの市場価値の正規分布の仮定に基づいて次式のように計算される。
【０１２５】
【数８】
0005414520.tif 000014
【０１２６】
代わりに、数値として“ＶａＲ”値を表示するために、注文管理システムは、ポートフォリオ内の現金等価物を含むポートフォリオの純資産価値のパーセンテージとして“ＶａＲ”を提供し得る。これは、リスクレベルを明瞭に記録しないかもしれない数値よりむしろ、彼らのリスクレベルの更に良い感覚を得るために“ＶａＲ”を彼らのポートフォリオのパーセンテージと見なす方を好み得るそれらのユーザを支援するために提供される。
【０１２７】
本発明の注文管理システムの別の特徴は、取引前リスクマネージャの一部分であるポートフォリオマネージャ演算操作である。ポートフォリオマネージャは、ユーザが、“ＶａＲ”計算及び“ＶａＲ”報告と関連付けられた“ｗｈａｔ−ｉｆ”シナリオを分析するための手段として使用されるべきポートフォリオを任意に作成することを可能にする。従って、“ＶａＲ”レポートは、ユーザが、異なるポートフォリオ上でリスク資産総額を比較するか、もしくはユーザによって提案された特定の取引アクティビティの影響を評価するために仮説のポートフォリオを作成することを可能にする複数のポートフォリオを含み得る。
【０１２８】
数値形式か、またはパーセンテージ形式かにかかわらず、“ＶａＲ”値について報告することは、グラフィカルインタフェースを通じて提供された単純な集計表（spreadsheet）のようなデータグリッドに基づいている。ユーザは、更に、ポートフォリオを任意に定義し、ＶａＲ測定セットを選択し、そして報告階層（reporting hierarchy）を検索する（navigate through）自由を有する。
【０１２９】
注文管理システムに関する“ＶａＲ”レポートは、ポートフォリオ、原資産（underlier）グループ、及びポジションという３つのレベルを有している。レポートは、上述されたように、集計表（spreadsheet）形式であると共に、ユーザが報告階層（reporting hierarchy）を検索する（navigate through）ことを可能にする。
【０１３０】
注文管理システムが望まれたように動作するために、特定のレベルの市場効率が設計理念において仮定されなければならないということが理解できる。１番目に、“０”の短期的成長期待を有する、株式（stok）、公債（bond）、外国為替（foreign exchange）、及び先物（future）のような基本の証券は、ランダムウォーク（random walk）を示すと推測されている。従って、これらの基本的証券の価格は、対数正規（デルタノーマル）分布（log normal (delta-normal) distribution）を示す。２番目に、短期における価格の変動は連続して独立している（すなわち、時間自己相関は“０”に接近する）と推測されている。従って、これらの証券の利益率は、独立して完全に同じように正規分布する（すなわち、“iind”）。３番目に、派生商品の価格は、在庫費用に関する市場の期待（無リスク金利）、保有期間の間の原資産（underlier）のボラティリティ、及び時間手数料（time premium）（期限前行使（early exercise）なし）の合理性を十分に獲得すると推測されている。従って、ブラックショールズモデル（Black-Scholes model）が派生商品の理論値を計算する際に有効である。
【０１３１】
リスクマネージャによって評価されたリスクのタイプに応じて、ユーザは、プリセットされたユーザ定義の方針違反が原因で、提案された取引に関与することを厳重に禁止され得るか、またはリスクマネージャは、取引所に対する注文を作成しているとき、考慮するように十分な警告をユーザに与え得る。
【０１３２】
更なるリスク削減手段として、リスクマネージャは、段階的な注文（staged order）を支援する。段階的な注文は、ユーザの取引を、それが実行され得る前に、人員の少なくとも１つの他のレベルが再検討すると共に正当性を立証することを保証するので、安全性を追加する。注文は、その場合に、ユーザによって委任されたものとして、注文管理システムによって、ストリーミングリアルタイムデータプロバイダを使用して取引所に発行される。知られているように、いろいろなそのようなプロバイダが存在すると共に、十分なリアルタイムデータストリーミングが提供されるならば、それらの内の１つが本発明の注文管理システムと統合され得る。
【０１３３】
選択した金融為替市場への取引の実行の後で、本発明の注文管理システムは、更に取引後リスク分析演算操作を提供することによってユーザを援助する。リスクアナライザ（risk analyzer）は、ユーザの過去の口座アクティビティを再検討すると共に、値が増加または縮小しそうであるとアナライザが予測する証券に関して、ユーザのポートフォリオを検索し得る。好ましい実施例において、リスクアナライザは、ストリーミングリアルタイムデータプロバイダを通じて、リアルタイムの為替市場データを受信する。更に、リスクアナライザは、好ましくはキャッシュサーバの形の記憶装置手段へアクセスすることができると共に、１秒間に３０回のスロットル制限された（throttle-limited）速度で為替市場データを更新する。制限された速度は、有意義な計算を提供するのに十分に速いが、しかしシステムの動作を過度に減速するほどには速くない。これは、リスクアナライザが、どのユーザの口座ポートフォリオにおける証券が増加する可能性を有するかを判定する際に、市場状態に関するリアルタイムの更新を使用することを可能にする。
【０１３４】
本発明が、機能及び特徴の特定の配置を有する特定の実施例を参照して説明されたが、その記述は、注文管理システムの全ての可能な特徴及び使用を徹底的に究明することを意図していない。実際には、当業者によって解明可能な発明の範囲内に維持しながら、追加の手段によって注文管理システムを構成すると共に、既存の特徴を変更することが実現可能であろう。
【図面の簡単な説明】
【０１３５】
【図１】本発明の実施例の構成要素の図である。
【図２】本発明の好ましい実施例における取引サーバ１３０によって使用されるパイプライン／スレッディング（pipeline/threading）構造の図である。
【符号の説明】
【０１３６】
１１０    クライアント要素
１２０    ゲートウェイ要素
１２５    決算インタフェース
１３０    取引サーバ
１３３    ＴＳ１
１３７    ＴＳｎ
１４０    口座データベース
１５０    “ｌｔａｓｋ”モジュール
１５１    ＩＴ１
１５５    注文マネージャ
１５７    ＩＴｍ
１６０    帳簿サーバ
１６３    シンボルデータベース
１６５    帳簿データベース
１７０    ＸＭＬパブリッシャ
１７３    取引スタッファ
１７５    アーカイブデータベース
１８０    状態なし注文ハンドラ
１９０    市場監視手段
【図１】
0005414520.tif 000015
【図２】
0005414520.tif 000016