(57)【要約】  殆どの資産トレーディングトランザクションを特徴付ける、複数のよりハイレベルのトレーディングプロトコルをサポートする、「ジェスチャ」と呼ばれる、プロトコル独立型基本資産トレーディングメッセージのカタログを使用する、インターネットなどの、相互接続コンピュータネットワーク上でトレードを実行するためのシステム及び方法。プロトコル依存ワークフローを必要とするトレーディングトランザクションは、ジェスチャのカタログから選択され、次いでオンライン資産トレーディングサーバに一度にひとつずつ渡される、プロトコル独立型ジェスチャから構成される。オンライン資産トレーディングサーバは、現在の状態、受信する選択されたプロトコル独立型ジェスチャ、及び１組の状態遷移規則に基づき、一連の互いに異なる状態により、保留中の見積り及びトレードを遷移し、これにより、よりハイレベルのプロトコル依存ワークフローを実施する。
2008503794.tif 000002
【特許請求の範囲】
【請求項１】
トレーディングトランザクションを処理するためのコンピュータネットワークであり、
顧客トレーディングアプリケーションを備える顧客トレーディングシステムと、
プロバイダトレーディングアプリケーションを備えるプロバイダトレーディングシステムと、
トレーディングエンジンとメモリとを備えるオンライントレーディングサーバと、
前記オンライントレーディングサーバを前記顧客トレーディングシステムに接続する第１のデータ通信リンクと、
前記オンライントレーディングサーバを前記プロバイダトレーディングシステムに接続する第２のデータ通信リンクと、を備えるコンピュータネットワークであって、
前記オンライントレーディングサーバが、前記第１のデータ通信リンクを介して、プロトコルに従って見積り又はトレードを処理するよう前記顧客トレーディングシステムから要求を受信し、前記メモリ内に前記見積り又はトレードの現在の状態を格納し、前記第２のデータ通信リンクを介して前記プロバイダトレーディングシステムに前記要求を送信し、
前記プロバイダトレーディングアプリケーションが、前記要求用のプロトコル依存ワークフローを選択し、前記プロトコル依存ワークフローが、プロトコル独立型ジェスチャの定義済みのシーケンスを備え、前記オンライントレーディングサーバに前記定義済みシーケンス内のそれぞれのプロトコル独立型ジェスチャを連続的に伝送し、
前記定義済みシーケンス内の前記それぞれのプロトコル独立型ジェスチャを受信したことに応答して、前記トレーディングエンジンが、前記見積り又はトレードの新しい状態を反映するよう前記メモリを更新し、前記新しい状態が、前記現在の状態、受信された前記それぞれのプロトコル独立型ジェスチャ、及び状態遷移規則に基づいて判断されるコンピュータネットワーク。
【請求項２】
前記新しい状態と前記現在の状態とが同じである、請求項１に記載のコンピュータネットワーク。
【請求項３】
前記トレーディングエンジンが、
受信された前記それぞれのプロトコル独立型ジェスチャに応答して、復帰プロトコル独立型ジェスチャを生成し、
前記復帰プロトコル独立型ジェスチャを前記プロバイダトレーディングシステムに伝送するよう構成される、請求項１に記載のコンピュータネットワーク。
【請求項４】
前記プロバイダトレーディングアプリケーションが、
プロトコル独立型ジェスチャのカタログから１つ以上のプロトコル独立型ジェスチャを選択し、前記カタログ内のそれぞれのプロトコル独立型ジェスチャが、前記プロトコルをサポートする基本資産トレーディングメッセージを備え、
さらに、前記選択された１つ以上のプロトコル独立型ジェスチャを前記定義済みシーケンス内に配置し、これにより、前記プロトコル依存ワークフローを作成する、請求項１に記載のコンピュータネットワーク。
【請求項５】
前記プロバイダトレーディングシステムが、プロトコル独立型ジェスチャの前記定義済みシーケンスを前記オンライントレーディングサーバに伝送する、前記プロバイダトレーディングアプリケーション及び前記第２のデータ通信リンクに結合された、プロバイダアプリケーションインターフェースをさらに備える、請求項１に記載のコンピュータネットワーク。
【請求項６】
前記顧客トレーディングアプリケーションが、前記要求用の第２のプロトコル依存ワークフローを選択し、前記第２のプロトコル依存ワークフローが、プロトコル独立型ジェスチャの第２の定義済みシーケンスを備え、前記オンライントレーディングサーバに前記第２の定義済みシーケンス内のそれぞれのプロトコル独立型ジェスチャを連続的に伝送し、
前記トレーディングエンジンが、前記第２の定義済みシーケンス内の前記それぞれのプロトコル独立型ジェスチャを受信したことに応答して、前記見積り又はトレードの第２の新しい状態を反映するよう前記メモリを改変し、前記第２の新しい状態が、前記現在の状態、受信された前記それぞれのプロトコル独立型ジェスチャ、及び第２の状態遷移規則に基づいて判断される、請求項１に記載のコンピュータネットワーク。
【請求項７】
前記顧客トレーディングアプリケーションが、
プロトコル独立型顧客ジェスチャのカタログから、１つ以上のプロトコル独立型顧客ジェスチャを選択し、前記カタログ内のそれぞれのプロトコル独立型顧客ジェスチャが、前記プロトコルをサポートする基本資産トレーディングメッセージを備え、
前記第２の定義済みシーケンス内に前記選択された１つ以上のプロトコル独立型顧客ジェスチャを配置し、これにより、前記第２のプロトコル依存ワークフローを作成する、請求項６に記載のコンピュータネットワーク。
【請求項８】
前記顧客トレーディングシステムが、プロトコル独立型顧客ジェスチャの前記第２の定義済みシーケンスを前記オンライントレーディングサーバに伝送する、前記顧客トレーディングアプリケーション及び前記第２のデータ通信リンクに結合された、顧客アプリケーションインターフェースをさらに有する、請求項７に記載のコンピュータネットワーク。
【請求項９】
前記トレーディングエンジンが、
状態機械プロセッサと、
状態遷移規則のコレクションと、を備え、前記コレクション内のそれぞれの状態遷移規則が、前記定義済みシーケンス内の前記それぞれのプロトコル独立型ジェスチャの少なくとも１つを受信した後の状態を識別するよう構成されるコンピュータネットワークであって、
前記状態機械プロセッサが、前記コレクションから前記状態遷移規則を検索する、請求項１に記載のコンピュータネットワーク。
【請求項１０】
前記第１のデータ通信リンクが、メッセージ伝達サブシステムを備える、請求項１に記載のコンピュータネットワーク。
【請求項１１】
前記第２のデータ通信リンクが、メッセージ伝達サブシステムを備える、請求項１に記載のコンピュータネットワーク。
【請求項１２】
前記プロバイダトレーディングシステムが、プロトコル独立型ジェスチャの前記定義済みシーケンスを一連の財務情報交換メッセージに変換し、前記第２のデータ通信リンクを介して前記財務情報交換メッセージを前記オンライントレーディングサーバに伝送する、前記プロバイダトレーディングアプリケーション及び前記第２のデータ通信リンクに結合された、財務情報交換エンジンをさらに備える、請求項１に記載のコンピュータネットワーク。
【請求項１３】
前記第２のデータ通信リンクが、財務情報交換トランスポートサブシステムを備える、請求項１２に記載のコンピュータネットワーク。
【請求項１４】
前記オンライントレーディングサーバが、
前記プロバイダトレーディングシステムから前記一連の財務情報交換メッセージを受信する、前記第２のデータ通信リンクに結合された、第２の財務情報交換エンジンと、
前記一連の財務情報交換メッセージをプロトコル独立型ジェスチャの前記定義済みシーケンスに変換する財務情報交換メッセージトランスレータと、をさらに備える、請求項１３に記載のコンピュータネットワーク。
【請求項１５】
オンライントレーディングサーバが、
顧客トレーディングシステムから、プロトコルに従って見積り又はトレードを処理するための要求を受信し、前記要求をプロバイダトレーディングシステムに送信するよう構成されたネットワークインターフェースと、
前記見積り又はトレードの現在の状態を格納するよう構成されたメモリと、
前記プロバイダトレーディングシステムから、前記ネットワークインターフェースを介して、前記見積り又はトレード用のプロトコル独立型ジェスチャの定義済みシーケンスを受信し、前記定義済みシーケンス内のそれぞれのプロトコル独立型ジェスチャを受信したことに応答して、前記見積り又はトレードの新しい状態を反映するよう前記メモリを更新するトレーディングエンジンと、を備え、
前記新しい状態が、前記現在の状態、受信された前記それぞれのプロトコル独立型ジェスチャ、及び状態遷移規則に基づいて判断されるオンライントレーディングサーバ。
【請求項１６】
前記トレーディングエンジンが、
状態機械プロセッサと、
状態遷移規則のコレクションと、を備え、前記コレクション内のそれぞれの状態遷移規則が、前記定義済みシーケンス内の前記それぞれのプロトコル独立型ジェスチャの少なくとも１つを受信した後の状態を識別するよう構成されたオンライントレーディングサーバであって、
前記状態機械プロセッサが、前記コレクションから前記状態遷移規則を検索する、請求項１５に記載のオンライントレーディングサーバ。
【請求項１７】
前記新しい状態と前記現在の状態とが同じである、請求項１５に記載のオンライントレーディングサーバ。
【請求項１８】
前記トレーディングエンジンが、
受信された前記それぞれのプロトコル独立型ジェスチャに応答して、復帰プロトコル独立型ジェスチャを生成し、
前記復帰プロトコル独立型ジェスチャを、前記ネットワークインターフェースを介して、前記プロバイダトレーディングシステムに伝送するよう構成された、請求項１５に記載のオンライントレーディングサーバ。
【請求項１９】
プロバイダトレーディングシステムとオンライントレーディングサーバとを備えるコンピュータネットワークにおいて、トレーディングトランザクションを処理する方法が、
前記オンライントレーディングサーバで、プロトコルに従って見積り又はトレードを処理するよう顧客トレーディングシステムから要求を受信することと、
前記オンライントレーディングサーバで、メモリ内に前記見積り又はトレードの現在の状態を格納することと、
前記要求を前記プロバイダトレーディングシステムに送信することと、
前記プロバイダトレーディングシステムにおいて、前記要求用のプロトコル依存ワークフローを選択することと、を含み、前記プロトコル依存ワークフローが、プロトコル独立型ジェスチャの定義済みシーケンスを備え、
さらに、前記プロバイダトレーディングシステムから前記オンライントレーディングサーバに、前記定義済みシーケンス内のそれぞれのプロトコル独立型ジェスチャを連続的に伝送することと、
前記オンライントレーディングサーバにおいて、前記定義済みシーケンス内の前記それぞれのプロトコル独立型ジェスチャを受信したことに応答して、前記見積り又はトレードの新しい状態を反映するよう前記メモリを更新することと、を備え、前記新しい状態が、前記現在の状態、受信された前記それぞれのプロトコル独立型ジェスチャ、及び状態遷移規則に基づいて判断される方法。
【請求項２０】
プロトコル独立型ジェスチャのカタログを定義することをさらに含み、前記カタログ内のそれぞれのプロトコル独立型ジェスチャが、非常に多くのプロトコルをサポートする基本資産トレーディングメッセージを備える、請求項１９に記載の方法。
【請求項２１】
前記プロトコルをサポートする前記カタログから、１つ以上のプロトコル独立型ジェスチャを選択することと、
前記選択された１つ以上のプロトコル独立型ジェスチャを前記定義済みシーケンス内に配置し、これにより、前記プロトコル依存ワークフローを作成することと、をさらに備える、請求項２０に記載の方法。
【請求項２２】
前記オンライントレーディングサーバに状態遷移規則のコレクションを格納することを備え、前記コレクション内のそれぞれの状態遷移規則が、前記定義済みシーケンス内の前記それぞれのプロトコル独立型ジェスチャの１つを受信した後の状態を識別するよう構成され、
さらに、前記コレクションから前記状態遷移規則を検索することを備える、請求項１９に記載の方法。
【請求項２３】
前記新しい状態と前記現在の状態とが同じである、請求項１９に記載の方法。
【請求項２４】
受信された前記それぞれのプロトコル独立型ジェスチャに応答して、復帰プロトコル独立型ジェスチャを生成することと、
前記復帰プロトコル独立型ジェスチャを前記プロバイダトレーディングシステムに伝送することとをさらに備える、請求項１９に記載の方法。
【請求項２５】
顧客トレーディングシステムとオンライントレーディングサーバとを有するコンピュータネットワークにおいて、トレーディングトランザクションを処理する方法が、
プロトコルに従って見積り又はトレードを処理するために、前記オンライントレーディングサーバで、前記顧客トレーディングシステムから要求を受信することと、
前記オンライントレーディングサーバで、メモリ内に前記見積り又はトレードの現在の状態を格納することと、
前記要求をプロバイダトレーディングシステムに送信することと、
前記顧客トレーディングシステムにおいて、前記要求用のプロトコル依存ワークフローを選択することとを備え、前記プロトコル依存ワークフローが、プロトコル独立型ジェスチャの定義済みシーケンスを備え、
さらに、前記顧客トレーディングシステムから前記オンライントレーディングサーバに、前記定義済みシーケンス内のそれぞれのプロトコル独立型ジェスチャを連続的に伝送することと、
前記オンライントレーディングサーバにおいて、前記定義済みシーケンス内の前記それぞれのプロトコル独立型ジェスチャを受信したことに応答して、前記見積り又はトレードの新しい状態を反映するよう前記メモリを更新することとを備え、前記新しい状態が、前記現在の状態、受信された前記それぞれのプロトコル独立型ジェスチャ、及び状態遷移規則に基づいて判断される方法。
【請求項２６】
プロトコル独立型ジェスチャのカタログを定義することをさらに備え、前記カタログ内のそれぞれのプロトコル独立型ジェスチャが、多数のプロトコルをサポートする基本資産トレーディングメッセージを有する、請求項２５に記載の方法。
【請求項２７】
前記プロトコルをサポートする前記カタログから、１つ以上のプロトコル独立型ジェスチャを選択することと、
前記選択された１つ以上のプロトコル独立型ジェスチャを前記定義済みシーケンス内に配置し、これにより、前記プロトコル依存ワークフローを作成することとをさらに備える、請求項２６に記載の方法。
【請求項２８】
前記オンライントレーディングサーバにおいて、状態遷移規則のコレクションを格納することを備え、前記コレクションのそれぞれの状態遷移規則が、前記定義済みシーケンス内の前記それぞれのプロトコル独立型ジェスチャの少なくとも１つを受信した後の状態を識別するよう構成され、
さらに、前記コレクションから前記状態遷移規則を検索することを備える、請求項２５に記載の方法。
【請求項２９】
前記新しい状態と前記現在の状態とが同じである、請求項２５に記載の方法。
【請求項３０】
受信された前記それぞれのプロトコル独立型ジェスチャに応答して、復帰プロトコル独立型ジェスチャを生成することと、
前記復帰プロトコル独立型ジェスチャを前記顧客トレーディングシステムに伝送することと、をさらに備える、請求項２５に記載の方法。
【請求項３１】
オンライントレーディングサーバにおいてトレーディングトランザクションを処理する方法であって、
顧客トレーディングシステムから、ネットワークインターフェースを介して、プロトコルに従って見積り又はトレードを処理するための要求を受信することと、
メモリ内に前記見積り又はトレードの現在の状態を格納することと、
前記要求を、前記ネットワークインターフェースを介して、プロバイダトレーディングシステムに送信することと、
前記プロバイダトレーディングシステムから、前記ネットワークインターフェースを介して、前記見積り又はトレード用のプロトコル独立型ジェスチャの定義済みシーケンスを受信することと、
前記定義済みシーケンス内のそれぞれのプロトコル独立型ジェスチャを受信したことに応答して、前記見積り又はトレードの新しい状態を反映するよう前記メモリを更新することとを備え、前記新しい状態が、前記現在の状態、受信された前記それぞれのプロトコル独立型ジェスチャ、及び状態遷移規則に基づいて判断される方法。
【請求項３２】
状態遷移規則のコレクションを格納することをさらに備え、前記コレクション内のそれぞれの状態遷移規則が、前記定義済みシーケンス内の前記それぞれのプロトコル独立型ジェスチャの少なくとも１つを受信した後の状態を識別するよう構成され、
さらに、前記コレクションから前記状態遷移規則を検索することを備える、請求項３１に記載の方法。
【請求項３３】
前記新しい状態と前記現在の状態とが同じである、請求項３１に記載の方法。
【請求項３４】
受信された前記それぞれのプロトコル独立型ジェスチャに応答して、復帰プロトコル独立型ジェスチャを生成することと、
前記復帰プロトコル独立型ジェスチャを前記顧客トレーディングシステムに伝送することとをさらに備える、請求項３１に記載の方法。
【請求項３５】
受信された前記それぞれのプロトコル独立型ジェスチャに応答して、復帰プロトコル独立型ジェスチャを生成することと、
前記復帰プロトコル独立型ジェスチャを前記プロバイダトレーディングシステムに伝送することとをさらに備える、請求項３１に記載の方法。
【請求項３６】
オンライントレーディングサーバにおいてトレーディングトランザクションを処理する方法であって、
相手方からネットワークインターフェースを介して、プロトコルに従って見積り又はトレードを処理するための要求を受信することと、
メモリ内に前記見積り又はトレードの現在の状態を格納することと、
前記要求を、前記ネットワークインターフェースを介して、向こうの相手方に送信することと、
前記相手方又は前記向こうの相手方又はその両方から、前記見積り又はトレード用のプロトコル独立型ジェスチャの定義済みシーケンスを受信することと、
前記定義済みシーケンス内のそれぞれのプロトコル独立型ジェスチャを受信したことに応答して、前記見積り又はトレードの新しい状態を反映するよう前記メモリを改変することとを備え、前記新しい状態が、前記現在の状態、受信された前記それぞれのプロトコル独立型ジェスチャ、及び状態遷移規則に基づいて判断される方法。
【請求項３７】
状態遷移規則のコレクションを格納することをさらに備え、前記コレクション内のそれぞれの状態遷移規則が、前記定義済みシーケンス内の前記それぞれのプロトコル独立型ジェスチャの少なくとも１つを受信した後の状態を識別するよう構成され、
さらに、前記コレクションから前記状態遷移規則を検索することを備える、請求項３６に記載の方法。
【請求項３８】
前記新しい状態と前記現在の状態とが同じである、請求項３６に記載の方法。
【請求項３９】
オンライントレーディングサーバが、
相手方から、プロトコルに従って見積り又はトレードを処理するための要求を受信するための要求受信手段と、
前記要求受信手段に応答して、前記見積り又はトレードの現在の状態を格納するための格納手段と、
前記要求を向こうの相手方に送信するための伝送手段と、
前記相手方又は前記向こうの相手方又はその両方から、前記見積り又はトレード用のプロトコル独立型ジェスチャの定義済みシーケンスを受信するためのジェスチャ受信手段と、
前記ジェスチャ受信手段に応答して、前記見積り又はトレードの新しい状態を識別するための状態遷移手段とを備え、
前記格納手段が、前記ジェスチャ受信手段及び前記状態伝送手段に応答して、前記現在の状態を前記新しい状態に変更するよう構成されたオンライントレーディングサーバ。
【請求項４０】
前記状態伝送手段が、
状態遷移規則のコレクションを格納する手段を備え、前記コレクション内のそれぞれの状態遷移規則が、前記定義済みシーケンス内の前記それぞれのプロトコル独立型ジェスチャの少なくとも１つを受信した後の状態を識別するよう構成され、
さらに、前記コレクションから前記状態遷移規則を検索する手段を備える、請求項３９に記載のオンライントレーディングサーバ。
【請求項４１】
前記新しい状態と前記現在の状態とが同じである、請求項３９に記載のオンライントレーディングサーバ。
【請求項４２】
前記ジェスチャ受信手段に応答して、復帰プロトコル独立型ジェスチャを生成する手段と、
前記復帰プロトコル独立型ジェスチャを前記相手方に伝送する手段とをさらに備える、請求項３９に記載のオンライントレーディングサーバ。
【請求項４３】
前記ジェスチャ受信手段に応答して、復帰プロトコル独立型ジェスチャを生成する手段と、
前記復帰プロトコル独立型ジェスチャを前記向こうの相手方に伝送する手段とをさらに備える、請求項３９に記載のオンライントレーディングサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、自動オンライン資産トレーディングシステム、より詳細には、相手方が、ハイレベルコンピュータソフトウェアアプリケーションプログラム、アプリケーションプログラミングインターフェース、及びグラフィカルユーザインターフェースを使用して、中間又は集中オンライントレーディングサーバからのサポート又はこのサーバの制御により、資産トレーディングトランザクションを起動し、交渉し、及び実行する、自動オンライン資産トレーディングシステムに関する。
【背景技術】
【０００２】
たとえば外国為替（「ＦＸ」）及び金融市場を含む、資産トレーディングビジネスにおいては、顧客が、「リクイディティプロバイダ」又は単に「プロバイダ」と呼ばれる、資産ディーラー（通常は、銀行又は銀行業務機関）を通じてトレードを実行する。代表的なシナリオにおいては、ある量の資産を購入する、売る、貸し出す、又は借入することを望む顧客が、（「ＲＦＱ」と呼ばれる）価格見積り要求を１つ以上のプロバイダに送信することにより、トレーディングトランザクションを提案する。プロバイダは、提案されたトランザクションに対する価格見積りを返すことによって応答する。この提案されたトランザクションは、プロバイダが喜んで資産を売りたい（又は貸し出したい）と思う価格と同様、プロバイダが喜んで資産を購入したい（又は借入れたい）と思う価格を示している。顧客が、価格見積りを気に入り、送信したプロバイダと契約することを望むと、顧客は、価格見積りに記載されている価格用のトレード資産オファー（このオファーは、通常、「取引オファー」と呼ばれる）をプロバイダに伝送する。プロバイダが顧客の取引オファーを受信した時に、価格見積りがまだ利用可能である（即ち、まだ時間切れでない）と、またプロバイダが、多量注文及び提案決済日などの、ＲＦＱの他の条件に満足し得ると、プロバイダは、通常、取引オファーを受け入れ、提案されたトランザクションは、契約され実行される。やや異なるシナリオにおいては、プロバイダは、価格見積りに特有のＲＦＱを受け取らず、価格見積りを顧客に実質的に連続して流し続けることがあり、顧客が、ストリーム内の１つ以上の価格見積りに対する取引オファーを送信することにより、トランザクションを起動することがある。
【０００３】
顧客とプロバイダとの間の、より速く、より効率的な、また監査のためにより追跡可能な、トレーディングトランザクションを促進するための、自動資産トレーディングシステムが導入されてきた。通常、これらのシステムは、ユーザから入力を受信し、かつプロバイダのコンピュータシステム（又はネットワーク）上を動作する１つ以上のハイレベルトレーディングアプリケーションプログラムに電子トレーディング命令を送信する、顧客のコンピュータシステム（又はネットワーク）上を動作する、ハイレベルトレーディングアプリケーションプログラム（又は場合によっては、一式のハイレベルトレーディングアプリケーションプログラム）、又はグラフィカルユーザインターフェースを有する。顧客のコンピュータシステム及びプロバイダのコンピュータシステムは、インターネット、専用ワイドエリアネットワーク（ＷＡＮ）、又は企業内イントラネットなどの、相互接続コンピュータネットワークにおいて確立された１つ以上のデータ通信チャネルを介して一連のメッセージを交換することにより互いに対話する。通常、ハイレベルトレーディングアプリケーションプログラム及びグラフィカルユーザインターフェースは、メッセージを作成し、これを、サブルーチン及び関数呼出しの定義済みコレクション又はライブラリにアクセスすることにより、コンピュータネットワークを経由して伝送する。サブルーチン及び関数呼出しのコレクション又はライブラリは、アプリケーションプログラミングインターフェース（「ＡＰＩ」）と呼ばれる。
【０００４】
ＡＰＩの補助により、コンピュータネットワーク内のデータ通信リンクを経由して見積り及びトレーディング命令を伝えるメッセージは、これも相互接続コンピュータネットワークに接続されている中間又は集中オンライントレーディングサーバ（又は「ポータル」）を通じて運ばれることがある。通常、中間オンライントレーディングサーバは、顧客及びリクイディティプロバイダの代わりに、メッセージを調整し、比較し、突き合せ、エラーチェックし及び／又は記録し、並びに当事者に応答をリアルタイムで通信するよう構成される。場合によっては、オンライントレーディングサーバは、第三者によって管理され操作される。ニューヨーク州、ニューヨーク市のＦＸ  Ａｌｌｉａｎｃｅ，ＬＬＣ（ＦＸａｌｌ）は、ＦＸ市場用のオンライントレーディングサーバのサードパーティオペレータの一例である。
【０００５】
既存のトレーディングアプリケーションプログラムは、しばしば、（入札及びオファー価格、資産量、提案決済日、トレーディングプロトコル、売買勘定などの）トレーディングトランザクションに関連する多量のデータをユーザに表示し、表示されたデータに応答して特有のトレーディング命令及びセレクションをユーザから受信するよう構成されたグラフィカル又はテキストベースのユーザインターフェースを含む。命令及びセレクションは、通常、たとえば、キーボード、コンピュータマウス、トラックボール、図形タブレット、及びスタイラスペンなどのコンピュータ分野において良く知られているパーソナルコンピュータ入力装置を使用し操作することによって生成される。
【０００６】
資産トレーディングビジネスにおいては、特に、サポートしなければならない絶えず増加し続けるトレーディングプロトコルの数及び複雑さについて、オンライン資産トレーディングシステムに関連する製品及びサービスを改良し、拡張し、アップグレードし及び／又は修理するという、途方もないプレッシャがある。顧客の期待を満足させ、競争力を持ち続けるためには、アプリケーションソフトウェア開発者及びプログラマ同様、オンライントレーディングシステム及びオンライントレーディングポータルのオペレータ及び管理者は、新規かつ改良したソフトウェアをかなり頻繁に開発し、提供していかなければならない。しかし、主として、多数の互いに関係し共働するソフトウェアプログラム及びモジュールは、特定のプログラム又はモジュールの著しい変更により悪影響を受ける恐れがあるため、改良品、アップグレード品、又は修正品をリリースするためには、かなりの時間、努力及びリソースが必要であることが分かっている。たとえば、新しいトレーディングプロトコルをサポートするために、オンライントレーディングサーバ上の重要なオペレーティングコンポーネント（たとえば、プロセッサ、アルゴリズム、又はソフトウェアモジュール）を変更し又は取り替えるには、通常、そのオンライントレーディングサーバと相互作用する遠隔顧客及びプロバイダコンピュータシステムに常駐しており、かつこの上で動作する、すべての又はかなりの数のトレーディングアプリケーションプログラム、グラフィカルユーザインターフェース、及びＡＰＩを変更し又は取り替える必要がある。このような多くの遠隔システムがある場合には、特定のオペレーティングコンポーネントのための変更品、改良品、又は修正品を提供するためには、通常、変更品、改良品、又は修正品により影響を受ける可能性のある遠隔サイトのすべてのプログラム及びライブラリを設置、試験、及び再保証しなければならないという途方もない作業が必要となる。しかも、オンライントレーディングシステムに著しい変更又は改良を加えるには、通常、追加又は改訂トレーニング資料及びシステム文書を作成するための時間及び金を費やさなければならない。
【０００７】
したがって、オンライントレーディング業界においては、変更され、アップグレードされ、又は修正されたコンポーネントが相互作用する他のすべてのコンポーネントを必ずしも変更、アップグレード、又は修正する必要することなく、あるコンポーネントを変更、アップグレード、又は修正できるように、互いに協働するよう構築されているが、なお独立して動作するコンポーネントを組み込んだオンライントレーディングシステム又はネットワークが必要である。このようなシステムにより、たとえば、プロバイダ、顧客、及びオンライントレーディングサーバオペレータが、非常に新しい機能及びアップグレード品を開発する、試験する、及び展開する、及びオンラインに入ってきた新しいトレーディングプロトコルをサポートすることが、はるかにより速く、より廉価、より容易となる。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
発明の概要
本発明は、ほとんどの資産トレーディングトランザクションを特徴付ける複数のハイレベルトレーディングプロトコル（即ち、「ワークフロー」）をサポートするが、このようなプロトコルから独立して動作する、基本資産トレーディングメッセージの定義済みセット（又は「カタログ」）を使用する、インターネットなどの相互接続コンピュータネットワーク上でトレードを実行するためのシステム及び方法を提供することにより、上述した必要性に対処するものである。これらのプロトコル独立型基本資産トレーディングメッセージは、「ジェスチャ」と呼ばれる。見積り及びトレードのためのプロトコル依存ワークフローが、その見積り及びトレード用のプロトコル独立型ジェスチャのシーケンスに変換及び配置され、このジェスチャは、ジェスチャのカタログから選択され、次いで、オンライン資産トレーディングサーバに一度にひとつずつ渡される。オンライントレーディングサーバは、現在の状態、受信する選択されたプロトコル独立型ジェスチャ、１組の状態遷移規則に基づいて、一連の互いに異なる状態により保留中の見積り及びトレードを遷移させ、これにより、よりハイレベルのプロトコル依存ワークフローを実施する。顧客トレーディングシステム又はプロバイダトレーディングシステムから受信されたそれぞれのプロトコル独立型ジェスチャを処理した（必要な場合には、見積り又はトレードの状態を変更した）後に、オンライントレーディングサーバは、通常、復帰プロトコル独立型ジェスチャを生成し、復帰プロトコル独立型ジェスチャを顧客及びプロバイダトレーディングシステムの１つ又はその両方に伝送する。このようにして、オンライントレーディングサーバは、頑強であり、極めて適応可能かつ効率的に、きわめて多様かつ複雑な、よりハイレベルのプロトコル依存トランザクションを行うことができる。
【課題を解決するための手段】
【０００９】
一般に、本発明の一態様は、顧客オンライントレーディングシステム上で動作する顧客トレーディングアプリケーションと、プロバイダトレーディングシステム上で動作するプロバイダトレーディングアプリケーションと、トレーディングエンジン及び（「保留中の見積り及びトレード」データベースなどの）メモリ記憶領域を備えたオンライントレーディングサーバとを備える、トレーディングトランザクションを処理するためのコンピュータネットワークを提供することである。コンピュータネットワークは、オンライントレーディングサーバを顧客トレーディングシステムに接続する第１のデータ通信リンクと、オンライントレーディングサーバをプロバイダトレーディングシステムに接続する第２のデータ通信リンクとを含む。オンライントレーディングサーバは、第１のデータ通信リンクを介して、特定のプロトコルに従って見積り又はトレードを処理するよう顧客トレーディングシステムから要求を受信する。後述されるように、通常、要求は、１つ以上のプロトコル独立型ジェスチャによりオンライントレーディングサーバに伝達される。サーバは、メモリ記憶領域内に見積り又はトレードの現在の状態を格納し、（別のプロトコル独立型ジェスチャを使用して）第２のデータ通信リンクを介してプロバイダトレーディングシステムに要求を送信する。
【００１０】
プロバイダトレーディングアプリケーションは、プロトコル独立型基本資産トレーディング命令の定義済みシーケンスである要求用のプロトコル依存ワークフローを選択し、定義済みシーケンス内のそれぞれのプロトコル独立型ジェスチャをオンライントレーディングサーバに連続的に伝送する。オンライントレーディングサーバでそれぞれのプロトコル独立型ジェスチャを受信すると、トレーディングエンジンは、見積り又はトレードの新しい状態を反映するようメモリを更新する。新しい状態は、現在の状態、受信されたプロトコル独立型ジェスチャ、及び状態遷移規則のコレクションから選択された１つの態遷移規則に基づいて判断される。場合によっては、また、いくつかのプロトコル独立型ジェスチャについては、見積り又はトレードのステータスは変更されず、この場合、新しい状態は、現在の状態と同じである。現在の状態を変更又は更新した後、オンライントレーディングサーバは、トレーディングアプリケーションが受信することを予想するプロトコル独立型ジェスチャをワークフローの一部として生成し伝送することにより、適切な確認、通知、受信通知、及び（たとえばそのトランザクションに特有な経済条件などの）他の情報を顧客トレーディングアプリケーションに又はプロバイダトレーディングアプリケーションに通信し戻す。特に、また以下に記述するように、あるプロトコル用のプロバイダトレーディングアプリケーションによって使用される及び同じプロトコル用の顧客トレーディングアプリケーションによって使用される、プロトコル依存ワークフロー及びプロトコル独立型ジェスチャは、互いに非常に異なっていることがある。
【００１１】
本発明の別の態様は、コンピュータネットワークではなく、ネットワークインターフェースと、メモリと、トレーディングエンジンとを有するオンライントレーディングサーバを提供することである。この態様においては、ネットワークインターフェースは、特定のプロトコルに従って見積り又はトレードを処理するための要求を受信し、遠隔プロバイダトレーディングシステムにその要求を送信する。メモリは、見積り又はトレードの現在の状態を格納し、トレーディングエンジンは、ネットワークインターフェースを介して、遠隔プロバイダトレーディングシステム又は遠隔顧客トレーディングシステムから見積り又はトレード用のプロトコル独立型ジェスチャの定義済みシーケンスを受信する。それぞれのプロトコル独立型ジェスチャを受信すると、オンライントレーディングサーバ上のトレーディングエンジンは、必要な場合には、現在の状態、受信されたそれぞれのプロトコル独立型ジェスチャ、及び状態遷移規則に基づいて見積り又はトレードの新しい状態を反映するよう、メモリを更新する。
【００１２】
本発明のさらに別の態様においては、（１）オンライントレーディングサーバで、特定のプロトコルに従って見積り又はトレードを処理するよう相手方から要求を受信するステップと、（２）オンライントレーディングサーバで、メモリ内に見積り又はトレードの現在の状態を格納するステップと、（３）向こうの相手方に要求を送信するステップと、（４）向こうの相手方のシステムにおいて、プロトコル独立型ジェスチャの定義済みシーケンスを有する、要求用のプロトコル依存ワークフローを選択する及び／又は作成するステップと、（５）オンライントレーディングサーバにワークフロー内のそれぞれのプロトコル独立型ジェスチャを連続して伝送し戻すステップと、（７）オンライントレーディングサーバにおいて、それぞれのプロトコル独立型ジェスチャを受信したことに応答して、見積り又はトレードの新しい状態を反映するようメモリを更新するステップとを有する、トレーディングトランザクションを処理する方法が提供される。本発明の他の態様と同様に、見積り又はトレードの新しい状態は、現在の状態、受信された特定のプロトコル独立型ジェスチャ、及び状態遷移規則に基づいて判断される。
【００１３】
本発明のトレーディングプロトコル独立型の態様は、たとえば、よりハイレベルのトレーディングアプリケーションプログラムによって使用されるよりハイレベルのトレーディングプロトコルから独立して、ジェスチャを正しく処理することができる顧客及び（特に）プロバイダサイトに配備するためのアプリケーションプログラミングインターフェースライブラリの開発を可能にし、サポートする。したがって、よりハイレベルのアプリケーションプログラム及びライブラリは、周囲のプログラムに影響を及ぼさずに、より容易に改変され更新され得る。
【００１４】
以下、例示的実施形態、したがって非限定的な実施形態を参照し、かつ本明細書の一部を構成し、例示的実施形態の記述を含む図面を用いて、本発明及び本発明の様々な態様、特徴、及び利点について詳細に説明する。
【発明を実施するための最良の形態】
【００１５】
以下、図１〜図１０を参照しながら、本発明の例示的実施形態の詳細な記述について説明する。特に、本発明は、当業者は本明細書を読むことにより明らかであろうが、ソフトウェア、ハードウェア、ファームウェア、又はこれらの任意の組合せを使用して実施される。以下、ＦＸａｌｌ複数プロバイダ資産トレーディングプラットフォームを参照しながら、ジェスチャの技術的な頑強性及び性能特性について詳細に記述する。しかし、ＦＸａｌｌプラットフォームは、本明細書に記述されている本発明がこれに基づいて機能するトレーディングプラットフォームの一例に過ぎない。本発明は、他の任意の１つのプロバイダ又は複数のプロバイダトレーディングプラットフォームに等しく適応可能であり、これらと共に効率的に動作するよう設計される。したがって、本文書及び図面において、ＦＸａｌｌのトレーディングプラットフォーム及びそのプロトコル及びコンポーネント（たとえば「ＱｕｉｃｋＦｉｌｌプロトコル」又は「ＦＸａｌｌサーバ」）を参照することは、単に例示のためであり、本発明の範囲及び適用可能性を限定するものと解釈されるべきではない。
【００１６】
アプリケーションプログラミングインターフェース（ＡＰＩ）
外国為替トランザクションなどのオンライントレーディングトランザクションを行うのに使用されるコンピュータネットワークにおいて、プロバイダ及び顧客は、通常、サブルーチン及び関数呼出しのライブラリを使用して、それらのトレーディングシステム（即ち、「レートエンジン」）とオンライントレーディングサーバとの間にインターフェースを構築する。ライブラリは、通常、通信（オンライントレーディングサーバへの及びこれとの接続の確立、維持及び破棄、並びにこの接続を経由したメッセージの送信及び受信）に関するクラスを含む。たとえば、オンラインサーバ及び相手の顧客トレーディングアプリケーションと通信するためにＡＰＩを使用するプロバイダトレーディングアプリケーションの代表的なライフサイクルは、以下の通りである。即ち、
＊  アプリケーションを開始する
＊  始動ハウスキーピング関数を遂行し、オンライントレーディングサーバとの接続を確立する
＊  見積り、トレード、及び情報要求に応答する
＊  遮断ハウスキーピング関数を遂行し、オンライントレーディングサーバとの接続を閉じる
＊  アプリケーションを遮断する
【００１７】
接続タイプ及び暗号化
【００１８】
本発明の実施形態においては、ＳＳＬ（セキュアソケットレイヤ）によって保護されている標準ＴＣＰ／ＩＰソケットを使用して、「直接接続」が確立される。セキュリティ上の理由により、これらのタイプの接続は、機関のファイアウォールによってブロックされる。ファイアウォール制限がある場合、直接接続には、通常、接続が確立できるようになる前に、ファイアウォール制限の除去又はＳＯＣＫＳプロキシの実施が必要となる。直接接続は、通常、最大の接続性能を提供する。標準ソケットが使用されるので、（サイズを増加させ、データ伝達の処理費用が必要となる）特別なデータフォーマティングがない。
【００１９】
本発明の実施形態はまた、通常のワールドワイドウェブ（「ＷＷＷ」）トラフィックを模倣する「トンネル接続」をサポートする。トンネル接続は、通常企業のファイアウォールによって阻止されない、通常のｈｔｔｐｓソケットによりＴＣＰ／ＩＰを使用する。双方向メッセージトラフィックは、ウェブプロキシを通過するためにｈｔｔｐパケットによって符号化される。この符号化に伴う追加のプログラム作業、及びこれに必要な追加データにより、トンネル接続は、一般に、直接接続より遅くなる。接続によって伝送されるデータは暗号化されることが好ましい。暗号化は、通常、ｈｔｔｐｓプロトコルで使用されるのと同様に、ＳＳＬ（「セキュアソケットレイヤ」）に適用される。
【００２０】
ＴＣＰ（インターネット又は仮想プライベートネットワークを経由するｈｔｔｐｓ及びソケット接続の基礎をなすネットワークトランスポート）は、よりハイレベルのアプリケーションコードを知らせることなく、脱落メッセージパケットを再伝送し、接続の経路を変更できるようにする、よりローレベルのパケット交換プロトコルに基づく。この基礎をなす頑強性は費用と相関する。つまり、いくつかの故障条件において断線したネットワーク接続を検出するのに、有限な（しばしば大きく分単位で測定される）時間がかかる。本発明は、この種の故障のためのより速い検出メカニズムをサポートする。具体的には、本発明のオンライントレーディングサーバ及びＡＰＩは、「生存」通知を交換する。顧客又はプロバイダシステム上で動作するハイレベルトレーディングアプリケーションには、これらの生存通知の伝達が通知されず、基礎をなすＡＰＩライブラリが、スケジュールされた生存通知が到達していないことを検出し、基礎をなすＴＣＰ接続が断線したことを報告する前に処置を講じるよう構成される。
【００２１】
本発明のコンピュータネットワークはまた、生存通知を使用して、顧客トレーディングシステムとプロバイダトレーディングシステムとの間の往復待ち時間を測定する。ネットワーク上の任意のコンピュータシステム用の待ち時間データは、収集され要約されて、そのコンピュータネットワークに結び付けられた他のコンピュータシステムのすべてにおいて利用可能となる。これらの待ち時間データの認識及び分布関数は、「LATENCY-AWARE ASSET TRADING SYSTEM（待ち時間認識資産トレーディングシステム）」という表題の、本明細書と同時に出願された、同時係属中の出願（出願番号              ）に記載の発明の構成要素であり、本出願の譲受人に譲渡され、参照によりその全体が本出願に組み込まれている。
【００２２】
トレーディングプロトコル、ワークフロー、及びプロトコル独立型ジェスチャ
【００２３】
トレーディングプロトコルとは、「ワークフロー」である。ワークフローは、トレーディングトランザクションを完了するためにシステム内の当事者間を流れるメッセージの１つ以上の有効なシーケンスを定義する。トレーディングアプリケーションプログラムは、通常、オンライントレーディングサーバ及び／又は向こうの相手方によってサポートされるトレーディングプロトコルの要件に従って、オンライントレーディングサーバと相互作用する。このため、ＡＰＩはまた、サポートされるトレーディングプロトコルをモデルとするサブルーチン及び関数呼出しのクラスを含む。本発明は、ＡＰＩによってサポートされる多様なトレーディングプロトコルを実施するために改良されたシステム及び方法を提供する。これらのプロトコルは、ＡＰＩ内のプロトコル独立型サブルーチン及び関数呼出しのシーケンスとして表現される、見積りの伝達及び取引の交渉用の有効なワークフローを定義する。
【００２４】
本発明においては、これらのトレーディングプロトコルをサポートするが、これらから独立して動作する基本資産トレーディングメッセージのカタログを定義し使用することにより、様々なトレーディングプロトコル（即ち、「プロトコル依存ワークフロー」）が実施される。図１は、多様なワークフローを構築するよう、本発明の実施形態において共に組み合わせられるプロトコル独立型ジェスチャのカタログの例を示す２つの表を含む。図１の左側の表は、トレーディング要求及び命令を伝えるメッセージをオンライントレーディングサーバと交換するために、プロバイダトレーディングアプリケーションによって使用されるプロトコル独立型ジェスチャ（ＡＰＩ関数呼出し）のコレクションを示す。プロバイダトレーディングアプリケーションは、図１の左側の表に示されているプロトコル独立型ジェスチャ（即ち、ＡＰＩ関数呼出し）をトランザクションに必要な特定のプロトコルに従ったシーケンスに配置することにより、プロトコル依存プロバイダワークフローを作成する。
【００２５】
図１の右側の表は、トレーディング要求及び命令を伝えるメッセージをオンライントレーディングサーバと交換するために顧客トレーディングアプリケーションによって使用されるプロトコル独立型ジェスチャ（ＡＰＩ関数呼出し）のコレクションを示す。プロバイダトレーディングアプリケーションのオペレーション及びプロバイダジェスチャの使用と同様に、顧客トレーディングアプリケーションは、図１の右側の表に示されているプロトコル独立型ジェスチャ（即ち、ＡＰＩ関数呼出し）をトランザクションに必要な特定のプロトコルに従ったシーケンスに配置することにより、プロトコル依存顧客ワークフローを作成する。
【００２６】
特に、ＡＰＩ関数呼出し同士は異なることがあるが、通常、プロバイダジェスチャと顧客ジェスチャとの間には強い相関関係がある。これは、プロバイダジェスチャ及び顧客ジェスチャが、表裏一体の如く共に作業するよう設計されているためである。たとえば、本発明の好ましい実施形態においては、プロバイダトレーディングシステム及び顧客トレーディングシステムの両方におけるＡＰＩは、「見積り」ジェスチャと呼ばれるジェスチャを含む（図１の５行参照）。プロバイダトレーディングアプリケーションは、プロバイダＡＰＩ内の関数「ＳｅｎｄＱｕｏｔｅ（）」を呼び出して、オンライントレーディングサーバに見積りを送信することにより、見積りジェスチャを呼出す。しかし、顧客トレーディングアプリケーションは、顧客ＡＰＩ内の関数「ＯｎＮｅｗＰｒｉｃｅ（）」を呼び出して、オンライントレーディングサーバからその見積りを検索する場合に、見積りジェスチャを呼び出す。したがって、プロバイダトレーディングアプリケーションは、見積りジェスチャを使用してデータを送信するが、顧客トレーディングアプリケーションは、見積りジェスチャを使用してデータを受信する。
【００２７】
ある場合には、プロバイダ及び顧客トレーディングアプリケーションプログラムによって作成されたプロトコル依存シーケンスは、トレーディング要求が起動又は受信される時に動的に作成される。他の場合には、プロバイダ及び顧客トレーディングアプリケーションプログラムは、指定されたプロトコル用のワークフローを提供するよう構成された、データ記憶装置又は別のアプリケーションプログラム又はプロセスから、ジェスチャの所望のシーケンスを検索する。さらに他の場合には、特定のプロトコル用のプロトコル独立型ジェスチャのプロトコル依存シーケンスは、プロバイダ又は顧客トレーディングアプリケーション内に「ハードコード」される。
【００２８】
トレーディングプロトコルは、通常、１つの又は２つの大規模な部分、即ち、見積り部分とトレード部分とからなる。これらの２つの部分は、制限された関係を有する。即ち、見積り部分が存在する場合には、トレード部分は、見積り部分が活動状態である間にのみ起動され得る。次に、図２Ａ、図２Ｂ、図３、図４、及び図５に示されている統一モデリング言語（ＵＭＬ）シーケンス図を参照しながら、以下、トレーディングプロトコルのいろいろな例の見積り部分及び様々な形態のトレード部分を構成するために、本発明の実施形態において使用されるプロトコル独立型ジェスチャのシーケンスについて記述する。これらのシーケンス図においては、垂直軸は、時間の経過（上から下に）を表し、水平軸は、それぞれの垂直軸、即ち、顧客、顧客トレーディングシステム、オンライントレーディングサーバ、及びプロバイダトレーディングシステムの先端にラベル付きの四角形内に示されている４つのオブジェクトの間のプロトコル独立型ジェスチャの経過を表す。任意の１つの図内の順序付けられたジェスチャ（メッセージ）のシーケンス全体は、プロトコル用のワークフローを表す。
【００２９】
見積り部分
図２Ａ及び図２Ｂに示されているＵＭＬシーケンス図は、トレーディングプロトコルワークフローを実施するよう本発明の実施形態においてアセンブルされるプロトコル独立型ジェスチャのシーケンスを示している。図２Ａ及び図２Ｂに示されるように、見積り部分は、通常、いくつかの異なるプロバイダに関連する。最初の組のプロバイダは、顧客が見積り部分を開始した時に作成される。プロバイダは、（顧客に見積りを送信することを拒否することにより）見積りプロセスから自分自身で除去し得る。また、顧客により個々に除去される、又は（プロトコルによっては）勝者側のプロバイダとして選択された場合に顧客によって除去される。見積り上のプロバイダの数が許容最大限より小さい場合、顧客の要求により、追加のプロバイダが保留中の又は「空中の」見積りに追加されることがある。見積りに残っているプロバイダがない場合には、終了し、顧客に知らされる。
【００３０】
ある見積り部分は、永続的なものとして表され、再始動されることがある。このファシリティは、一般に、（以下に記述する）ＱｕｉｃｋＦｉｌｌプロトコルトランザクションに使用されるものなどの、非時間制約型見積り部分にのみ適用される。プロバイダ及び見積り部分の条件は、サーバに永続的に格納され、先のものが終了した後に、プロバイダに再提出される。好ましい実施形態においては、プロバイダによる又はサーバによる見積り部分の終了は、常に、顧客への「見積り終了」ジェスチャとなる。このことは、見積りの終了が、顧客がトレードを完了した結果にも当てはまる。このことにより、見積り部分がクリーンに、かつトレーディング部分とは別個に保たれる。
【００３１】
トレード部分
（見積り部分の有無は別として）トレーディングプロトコル間の主要な差は、プロトコルのトレード（又は「交渉」）部分の行動から生じる。顧客及びプロバイダによってとられるアクションは、ほとんどのトレーディングプロトコルにおいて非常に似通っている。当事者によって知覚される差は、トランザクションの当事者が決定を行う場合の、オンライントレーディングサーバのトレーディングエンジンのアクションの差による。通常、これらのアクションは、以下の表１に示されている、非常に小さい組の可能性から導き出される。
【００３２】
【表１】
2008503794.tif 000003
【００３３】
以下、本発明と共に実施される、あるプロトコルのトレード部分の例について論ずる。
【００３４】
ＲＦＱプロトコル
典型的なＲＦＱプロトコル内には、見積り部分及び最大１つのトレード部分がある。見積り部分は、サーバが顧客の取引オファーを処理した時に終了する。通常、見積り部分の持続時間のタイマがある。タイムアウト時間の終わりまでにプロバイダが応答しない場合、このことが顧客に知らされる。プロトコルは、この時点では終了しない。即ち、プロバイダは、処理される完了メッセージ（たとえば、「拒否条件」又は「取引が実行された」メッセージ）をまだ生成することがある。
【００３５】
図３は、本発明の実施形態に従って、ＲＦＱプロトコルトランザクションの見積り及びトレード部分を実施するのに使用されるプロトコル独立型ジェスチャのシーケンスを示すＵＭＬシーケンス図である。トレード部分は、上述した典型的なＲＦＱプロトコルに基づくが、見積り部分は、勝者側のプロバイダがトランザクションの条件を受け入れるまで終了しない。Offer to Deal(取引オファー）において選択されたプロバイダが見積り部分から直ちに除去され、それぞれのプロバイダは、ＲＦＱ取引を実行するための最大１つの機会を有する（図３のシーケンス図のオンライントレーディングサーバ軸上の「見積り上のプロバイダを非活動化する」アクション及び「関連見積りを終了する」ジェスチャを参照）。この結果、プロバイダの拒否条件メッセージは、プロバイダが見積り部分内の唯一のプロバイダでない限り、顧客がトレードを完了することを妨げない。
【００３６】
ＱｕｉｃｋＦｉｌｌプロトコル
ＱｕｉｃｋＦｉｌｌプロトコルは、トレードを実行するよう互いに競争している複数のプロバイダからの見積りのストリームを示す顧客トレーディングシステム上の、長命の顧客トレーディングウィンドウ（又は「パネル」）をサポートする。ＱｕｉｃｋＦｉｌｌストリーミングプロトコル、及び顧客トレーディングシステム上のプロトコルと合わせて使用される好ましいユーザインターフェースは、「QUICK-FILLING CUSTOMER ASSET TRADING SYSTEM（急速充填顧客資産トレーディングシステム）」（出願番号              ）という表題の、本明細書と同時に出願された、同時係属中の出願に開示され記載されている本発明の構成要素であり、本出願の譲受人に譲渡され、参照によりその全体が本出願に組み込まれている。
【００３７】
ＱｕｉｃｋＦｉｌｌプロトコルを用いて、顧客は、見積りストリームを示す多くのウィンドウを作成し得るが、本発明のいくつかの実施形態においては、１つの顧客と通貨との対について、１つのみのウィンドウが存在する。これらのウィンドウは、顧客がトレードをプロバイダと直接実行する（即ち、中間トレーダ、仲介業者、又はトレード管理者がいない）トレーディングの非公開モデルを示す。非公開モデルは、顧客及びプロバイダに、彼らが完了する取引に関する可能な最大のプライバシを与えるものである。
【００３８】
ＱｕｉｃｋＦｉｌｌプロトコルは、プロバイダと顧客との間の「エンドツーエンド」の関係をサポートする。プロバイダは、複数の顧客に対して同じ通貨の対の見積り用の多くの同時ストリームを有することがある。プロバイダは、見積りを取得し（ストリームは、プロバイダによりいつでも一方的に終了され得る）、かつ取引を完了する（顧客取引オファーは拒絶され得る）、顧客の能力に対して完全な制御を保持する。個々の取引オファーの受入れも拒絶も見積りストリームを終了するものではない。即ち、プロバイダは、見積りストリームが顧客又はプロバイダによりはっきりとした形で終了されるまで、見積りを伝達し続けることがあることに留意されたい。したがって、図３のシーケンス図のオンライントレーディングサーバ軸に示されている「見積り上のプロバイダを非活動化する」アクション及び「関連見積りを終了する」ジェスチャは、図４のオンライントレーディングサーバ軸には現れない。
【００３９】
顧客は、見積りのストリームを確立すると、提案された１組の条件を提出する。この条件は、取引規模を除き、そのストリームに基づいて完了したすべての取引に適用される。顧客がストリームを要求する時に提示する規模は、最大オーダー規模である。ストリームに基づいて行われる取引は、最大オーダー規模以下の任意の規模を有する。プロバイダは、ＱｕｉｃｋＦｉｌｌプロトコルを指定する要求に応答して、任意の規模の見積りを伝達する。プロバイダが、最大オーダー規模より大きい規模の見積りを送信すると、オンライントレーディングサーバは、その見積り規模を最大オーダー規模に減少させるよう構成され得る。プロバイダは、それぞれの見積りメッセージ上で見積られた規模を変え得る。顧客がストリーム内の見積りに基づく取引オファーを送信した場合には、それが提示し得る最大規模は、最大オーダー規模及び見積りの規模より小さい。つまり、より小さい規模を提示する。
【００４０】
本発明の好ましい実施形態においては、ＱｕｉｃｋＦｉｌｌプロトコルは、見積り部分と１対多数のトレード部分とから構成される。したがって、上記のＲＦＱプロトコルのものより、このプロトコルの見積り部分とトレード部分との間には、はるかに弱い関係がある。このプロトコルのトレード部分は、図４のＵＭＬシーケンス図に示されている。ＱｕｉｃｋＦｉｌｌプロトコルにおいては、図４に示されているように、トレーディングアクションによるプロバイダの除去も見積り部分の終了もない。
【００４１】
休止オーダープロトコル
ＦＸａｌｌによって提供される休止オーダープロトコルは、トレード部分から構成され、見積り部分がない。図５は、このプロトコルを実施するのに使用されるプロトコル独立型ジェスチャのタイミング及びシーケンスを示すＵＭＬシーケンスである。図５に示されているように、プロトコルは、顧客がトレードの全条件を提出することによって開始される。これは、サーバ内に記録され、プロバイダに伝達される（１つのみが指定され得る）。プロバイダは、３つのうちの１つの方法で、即ち、オーダーを拒絶する、オーダーを実行する、又は後に実行するためにオーダーの条件を受け入れることにより、直ちに応答する。通常、このプロトコルにはタイマ警報があるが、この最初の応答がプロバイダから受信されるまでである。この時点以降、受け入れられたが実行されていないオーダーが、長時間、プロバイダの所で「休止している」ことがある。休止オーダープロトコルにおいては、顧客が、未決済のオーダーを取り消すことがある。他のプロトコルにおいては、オーダーが直ちに満たされると予想され、顧客が取引要求を取り消す時間がない。
【００４２】
オンライントレーディングサーバのオペレーション
【００４３】
本発明に従って動作するよう構成されたオンライントレーディングサーバが、ネットワークインターフェースと、メモリ記憶領域（データベースなどの）と、状態機械プロセッサ及び状態遷移規則のコレクションを有するトレーディングエンジンとを備える。顧客トレーディングシステム及びプロバイダトレーディングシステムと同じコンピュータネットワークに接続されたネットワークインターフェースは、特定のプロトコルに従って顧客トレーディングシステムから見積り又はトレード処理するための要求を受信し、プロバイダトレーディングシステムにその要求を送信するよう構成される。オンライントレーディングサーバはまた、メモリ記憶領域内に見積り又はトレードの現在の状態を格納する。顧客トレーディングシステムが、たとえばＲＦＱプロトコルで見積りのための要求を送信すると、見積り用のオンライントレーディングサーバによって格納された最初の現在の状態が、「見積り中」状態となる。
【００４４】
プロバイダトレーディングシステム上のプロバイダトレーディングアプリケーションは、オンライントレーディングサーバから要求を受信し、（プロトコル依存ワークフローに従って）その見積り又はトレード用のプロトコル独立型ジェスチャの定義済みシーケンスを作成する。次いで、プロバイダトレーディングアプリケーションは、図１に示されているジェスチャのカタログから選択された一連のジェスチャ（即ち、ＡＰＩ呼び出し）を実行することにより、ネットワークインターフェースを介してオンライントレーディングサーバに、定義済みシーケンス内のそれぞれのプロトコル独立型ジェスチャを連続的に送信し戻す。
【００４５】
オンライントレーディングサーバ上のトレーディングエンジンが、プロバイダトレーディングアプリケーションからプロトコル独立型ジェスチャのそれぞれ１つを受信し、これに応答して、（必要な場合には）見積り又はトレードの新しい状態を反映するようメモリ記憶領域を更新する。新しい状態は、前記現在の状態、受信されたプロトコル独立型ジェスチャ、及び状態遷移規則のコレクションから選択された１つの状態遷移規則に基づいて判断され、このそれぞれが、プロバイダ又は顧客トレーディングシステムから有効なプロトコル独立型ジェスチャを受信した後の新しい状態を識別する。好ましい実施形態においては、トレーディングエンジンは、状態遷移規則のコレクションから適切な状態遷移規則を選択するようプログラムされた状態機械プロセッサ（たとえば、コンピュータマイクロプロセッサ）を含む。状態遷移規則のコレクションは、このために設計された又は状態機械プロセッサ内に直接ハードコードされた、メモリ記憶領域又はデータベース内に物理的に格納されることがある。好ましい実施形態においては、コレクションは、（新しいプロトコルをサポートするために）オンライントレーディングサーバに新しい状態遷移規則を追加することをサポートするために別々に格納され、状態機械プロセッサを変更又は改変する必要がない。特に、プロトコル独立型ジェスチャのすべてが、状態を変更するわけではない。以下で論じる状態図のいくつかに示されているように、プロトコル独立型ジェスチャのいくつかは、見積り又はトレードの現在の状態に影響を及ぼさない。
【００４６】
状態遷移規則
【００４７】
図６、図７、及び図８は、本発明の原理に従って動作するよう構成されたオンライントレーディングサーバが、それぞれ、ＲＦＱ、ＱｕｉｃｋＦｉｌｌ、及び休止オーダープロトコルで、見積り又はトレードを処理するよう使用される、様々な状態、状態遷移、及びプロトコル独立型ジェスチャを示すＵＭＬ状態図である。これらのいくつか状態図においては、条件「銀行」は、条件「プロバイダ」の代わりに使用されているが、この条件は、互いに交換可能であると考えるべきである。
【００４８】
ＵＭＬ状態図においては、角が丸いラベル付きの四角形のボックスが、特定の状態を表している。それぞれの状態のボックス（以下、状態名又はラベル）内に、現在の状態に関連するプロトコル独立型ジェスチャ又は活動のリストが設けられるが、通常、これにより、現在の状態が新しい状態に変更されることはない。矢印の付いたラインが、プロトコル独立型ジェスチャを受信すると、どのような可能な状態遷移が発生し得るかを示す、状態のボックスに接続する。１つのボックスに至る又は１つのボックスから別のボックスに至るそれぞれのライン及び矢印には、示された状態を入力する又は特定の遷移を発生させるために受信しなければならないジェスチャを示すよう注釈が付いている。
【００４９】
潜在的に３つまでの部分を有する、これらの注釈の構文は、以下の通りである。即ち、Gesture[Guard]■Responseである。ラインの注釈内の「ジェスチャ」は、たとえば、状態遷移を発生させる、図１の表に示されているプロバイダ及び顧客プロトコル独立型ジェスチャの１つなどの、有効なプロトコル独立型ジェスチャを示す。２つの状態の間のラインの注釈内に「ガード」があると、このガードは、状態遷移制御論理を遂行する。ガードＩが遷移ラインの隣に示されている場合、状態遷移は、このガードの式が真でない場合には発生し得ない。ジェスチャ及び任意選択のガードがキャレット記号（「■」）及び「応答」の後に続く場合には、これは、ジェスチャを受信したことに応答して、（状態を変更することに加えて）追加のアクションがオンライントレーディングサーバによってとられることを示す。もちろん、このような１つのアクションは、いくつかのタイプの応答確認、確認、又はエラーメッセージを生成し、オンライントレーディングサーバにジェスチャを送信した当事者に送信し戻す。場合によっては、矢印の付いた１本のラインから太いバーに至り、次いで、これから矢印の付いた２本のラインを有する。これは、２つのプロセス又は活動が同時に行われることを意味する、処理分岐又は「フォーク」を表す。矢印の付いた２本のラインから、矢印の付いた１本のラインを有する、太いバーに至る。これは、２つのプロセスが１つのプロセス又は活動に併合することを意味する。
【００５０】
この構文を使用すると、図６において、たとえば、見積り又はトレードの現在の状態が「見積り中」であり、オンライントレーディングサーバが、プロバイダトレーディングシステムから「見積りそうである」ジェスチャを受信すると、オンライントレーディングサーバは、「見積りそうである」ジェスチャを（顧客トレーディングシステムに）送信することによって応答することが分かる。しかし、プロバイダトレーディングシステムからの「見積りそうである」ジェスチャをサーバが受信しても、現在の状態は変更されない。したがって、トランザクションは、「見積り中」状態のままである。他方、サーバが、トランザクションが「見積り中」状態にあり、「勝者側の銀行」がある間に、顧客トレーディングシステムから「取引オファー」ジェスチャを受信すると、オンライントレーディングサーバは、勝者側の銀行に「取引オファー」ジェスチャを送信し、現在の状態を「交渉中」に変更する。「敗者側の銀行」があると、オンライントレーディングサーバはまた、「プロトコルを終了する」ジェスチャをその敗者側の銀行に送信する。
【００５１】
図２Ａ〜図８に示されている、上記で論じたＵＭＬシーケンス図及び状態図は、本発明の実施形態において使用される様々なタイプのプロトコル依存ワークフロー及び状態遷移を、単なる例として示すために設けられている。当業者には、この開示を読むことにより、多くの他の任意のワークフロー及び状態遷移が、本明細書において論じられたものの追加形態として又は代替形態として、本明細書に記述されている本発明の範囲から逸脱することなく、実質的な利益を達成するよう使用されることが明らかとなろう。実際のところ、これらの原理に従って動作するシステム内にワークフロー及び状態遷移を追加又は改変できることは、本発明の大きな利点の１つである。
【００５２】
図９は、本発明の実施形態に従って動作するよう構成されたコンピュータネットワークを示すハイレベルブロック図である。図９に示されているように、コンピュータネットワークは、オンライントレーディングサーバ９０１と、顧客トレーディングシステム９１０と、プロバイダトレーディングシステム９１５とを含み、これらは、（ワールドワイドウェブを経由する（直接セキュアソケットレイヤ（ＳＳＬ）接続又はｈｔｔｐｓトンネル接続などの）メッセージ伝達サブシステム９５５を介して互いに通信可能に接続される。代表的なシナリオにおいては、顧客トレーディングシステム９１０が、特定のプロトコルに従って見積り及びトレードを処理するために、ユーザからトレーディングトランザクション要求を受け入れるよう構成された顧客トレーディングアプリケーション９２５（これ自体が、グラフィカルユーザインターフェースを含むことがある）を含む。顧客トレーディングアプリケーション９２５は、要求されたプロトコル用のプロトコル依存ワークフローを認識する、導き出す、又は検索する、及びプロトコル依存ワークフローをモデルとするためにプロトコル独立型顧客ジェスチャのシーケンスを選択する及びアセンブルするよう構成される。プロトコル独立型顧客ジェスチャは、たとえば、図１の右側の表に示されているジェスチャのカタログから選択されることがある。次いで、顧客トレーディングアプリケーション９２５が、顧客アプリケーションインターフェース９４０を含むことによって利用可能となった一連のＡＰＩライブラリ関数呼出しを呼出すことにより、オンライントレーディングサーバ９０１にプロトコル独立型ジェスチャを送信する。ＡＰＩライブラリはまた、メッセージ伝達サブシステム９５５を経由する通信用の任意のネットワーク接続の発行を取り扱うよう構成された関数呼出しを含むことが好ましい。
【００５３】
オンライントレーディングサーバ９０１は、たとえば任意のワイヤード又はワイヤレスネットワークインターフェースアダプタを備えることがあり、かつ顧客トレーディングアプリケーション９２５からそれぞれのプロトコル独立型ジェスチャを受信する、ネットワークインターフェース９６０を有する。オンライントレーディングサーバ９０１はまた、トレーディングエンジン９７５とメモリ９８０とを有する。トランザクション要求を受信すると、オンライントレーディングサーバ９０１は、保留中の見積り及びトレードのステータスを保持するよう構成されたメモリ９８０内にトランザクションの現在の状態を格納する。次いで、オンライントレーディングサーバ９０１は、トランザクション要求を表すために自身のプロトコル独立型ジェスチャを生成し、プロバイダトレーディングシステム９１５にそのプロトコル独立型ジェスチャを送信する。
【００５４】
プロバイダトレーディングシステム９１５はまた、オンライントレーディングサーバ９０１からプロトコル独立型ジェスチャを受信し、これをプロバイダトレーディングアプリケーション９３０に渡すよう構成された、図９にプロバイダアプリケーションインターフェース９４５として示されている、関数呼び出しのＡＰＩライブラリを備える。顧客トレーディングアプリケーション９２５と同様に、プロバイダトレーディングアプリケーション９３０も、要求されたプロトコル用のプロトコル依存ワークフローを認識し、導き出し、又は検索する、プロトコル依存ワークフローをモデルとするためにプロトコル独立型プロバイダジェスチャのシーケンスを選択及びアセンブルする、モデルとされたワークフローによって定義された順序でオンライントレーディングサーバ９０１にこれらのプロバイダジェスチャを送信し戻すよう構成される。この場合、プロトコル独立型プロバイダジェスチャは、たとえば、図１の左側の表に示されているジェスチャのカタログから選択されることがある。
【００５５】
オンライントレーディングサーバ９０１上のトレーディングエンジン９７５は、現在の状態、受信されたプロトコル独立型ジェスチャ、及び状態機械規則９７０のコレクションから検索された１つの状態遷移規則に基づいて、トランザクション内の見積り又はトレードの現在の状態を新しい状態に変更するかどうかを判断する、状態機械プロセッサ９６５を含む。変更する場合には、オンライントレーディングエンジン９７５は、メモリ９８０に対して適切な改変を行って、現在の状態を更新し、通常、復帰プロトコル独立型ジェスチャにより、顧客トレーディングシステム９１０、プロバイダトレーディングシステム９１５、又はその両方に通知書を送信する。
【００５６】
オンライントレーディングサーバ９０１は、任意に、FinancialInformation eXchange（ＦＩＸ）通信規格に従って、フォーマットされ、オンライントレーディングサーバ９０１に伝送されたメッセージを受信し翻訳するよう構成された、修正エンジン９８５と修正メッセージトランスレータ９９０とを含む。インターネット上のｗｗｗ．ｆｉｘｐｒｏｔｏｃｏｌ．ｏｒｇで見つけられ得る、ＦＩＸメッセージ通信規格は、世界中の銀行、仲介業者／ディーラー、取引所、業界ユーティリティ及びアソシエーション、機関投資家、及び情報技術プロバイダの共同作業により開発された、一連のメッセージ通信仕様である。これらのＦＩＸコンポーネントが含まれていると、オンライントレーディングサーバ９０１は、それ自体が顧客トレーディングアプリケーション９２５及びプロバイダトレーディングアプリケーション９３０と同様にプロトコル認識プロバイダトレーディングアプリケーション９２０を使用する、プロバイダトレーディングシステム９０５から受信されたトレーディング要求を、プロトコルから独立して処理するようプログラムされることがある。したがって、プロバイダトレーディングアプリケーション９２０は、プロトコル独立型ジェスチャのシーケンスをアセンブルして、プロトコル依存ワークフローを形成し、修正エンジン９３５にプロトコル独立型メッセージを伝達し、ここで、ＦＩＸフォーマットに準拠するデータパケットに変換又はカプセル化され、次いで、修正トランスポートサブシステム９５０を介してオンライントレーディングサーバ９０１に伝送されるよう構成される。通常、必ずしも必要なものではないが、修正トランスポートサブシステム９５０は、メッセージ伝達サブシステム９５５と同様に、インターネットなどの公衆網を通じてデータ通信リンクを有する。実際のところ、図９には示されていないが、修正トランスポートサブシステム９５０及びメッセージ伝達サブシステム９５５は、実際には、同じコンピュータネットワークを構成することがある。
【００５７】
図１０は、図９のオンライントレーディングサーバ９０１などの、本発明の実施形態に従って動作するよう構成されたオンライントレーディングサーバによって遂行されるステップを示すハイレベルの流れ図である。第１のステップであるステップ１００５では、オンライントレーディングサーバは、特定のプロトコルに従って見積り又はトレードを処理するための要求を受信する。次に、見積り又はトレードの現在の状態が、オンライントレーディングサーバのメモリ内に格納され、この要求は、向こうの相手方に送られる（ステップ１０１０）。次いで、サーバは、ステップ１０１５で着信メッセージを監視し、指定された時間が時間切れとなる前に、有効なプロトコル独立型ジェスチャが受信されたかどうかを判断する。タイムアウトは、ＱｕｉｃｋＦｉｌｌなどの、いくつかの長命のプロトコルには適応可能でないことがある。タイムアウトが適応可能であり、タイムアウトの時間が時間切れとなる前にジェスチャが受信されていないと、又は受信されたジェスチャが無効であると、サーバは、当事者にエラーメッセージを送信する（ステップ１０２０）。
【００５８】
サーバが、ステップ１０１５で有効なジェスチャを受信すると、サーバ上の状態機械プロセッサが、状態遷移規則１０２５のコレクションを参照することにより、状態変更が必要かどうかを判断する（ステップ１０３０）。状態変更が必要であると、現在の状態を含むメモリ領域が、（ステップ１０３５で）更新されて、現在の状態を状態遷移規則１０２５に従った新しい状態に変更する。状態の変更が必要でない場合は、処理はステップ１０４０で継続し、サーバは、トランザクションが完了したかどうかを判断する。好ましい実施形態においては、オンライントレーディングサーバは、まだ保留中のトランザクションに対して、完了されたトランザクションの経済条件を格納するよう構成された、データベースなどの、別のメモリ領域を含む。このような実施形態においては、オンライントレーディングサーバは、ステップ１００５に戻る前に、この完了されたトランザクションデータベースを更新する（ステップ１０４５）よう構成されることがある。本プロセスは、このステップで再び初めから開始される。
【００５９】
本明細書において、その最も好ましい実施形態と考えられる実施形態について、本発明を開示し記述してきた。当業者は本明細書を読むことにより、変形形態及び等価物が起こり得ること、及びこのような変形形態及び等価物が本発明の範囲及び頭記の特許請求の範囲内に入ることに留意されたい。したがって、たとえば、当業者は、本発明が、外国為替のトランザクションに限定されるものではなく、上述した他のタイプのトランザクションにも有益に適用されることを理解されたい。
【図面の簡単な説明】
【００６０】
図面の簡単な説明
【図１】本発明の一実施形態において使用される、プロトコル独立型プロバイダ及び顧客ジェスチャのカタログ（即ち、基本資産トレーディングメッセージ）、及びこれに対応するＡＰＩ呼び出しの例を示す２つの表を含む。
【図２Ａ】本発明の実施形態における、ＲＦＱ、ＱｕｉｃｋＦｉｌｌ（即ち、「ストリーミング」）、及び休止オーダープロトコル用のプロトコル依存ワークフローの例を示す統一モデリング言語（ＵＭＬ）シーケンス図である。
【図２Ｂ】本発明の実施形態における、ＲＦＱ、ＱｕｉｃｋＦｉｌｌ（即ち、「ストリーミング」）、及び休止オーダープロトコル用のプロトコル依存ワークフローの例を示す統一モデリング言語（ＵＭＬ）シーケンス図である。
【図３】本発明の実施形態における、ＲＦＱ、ＱｕｉｃｋＦｉｌｌ（即ち、「ストリーミング」）、及び休止オーダープロトコル用のプロトコル依存ワークフローの例を示す統一モデリング言語（ＵＭＬ）シーケンス図である。
【図４】本発明の実施形態における、ＲＦＱ、ＱｕｉｃｋＦｉｌｌ（即ち、「ストリーミング」）、及び休止オーダープロトコル用のプロトコル依存ワークフローの例を示す統一モデリング言語（ＵＭＬ）シーケンス図である。
【図５】本発明の実施形態における、ＲＦＱ、ＱｕｉｃｋＦｉｌｌ（即ち、「ストリーミング」）、及び休止オーダープロトコル用のプロトコル依存ワークフローの例を示す統一モデリング言語（ＵＭＬ）シーケンス図である。
【図６】オンライントレーディングサーバから見た、それぞれ、ＲＦＱ、ＱｕｉｃｋＦｉｌｌ、及び休止オーダートレーディングプロトコルを実施するよう、本発明の実施形態において処理される、見積り及びトレードの様々な状態、状態遷移、及びプロトコル独立型ジェスチャを示す、統一モデリング言語（ＵＭＬ）状態図である。
【図７】オンライントレーディングサーバから見た、それぞれ、ＲＦＱ、ＱｕｉｃｋＦｉｌｌ、及び休止オーダートレーディングプロトコルを実施するよう、本発明の実施形態において処理される、見積り及びトレードの様々な状態、状態遷移、及びプロトコル独立型ジェスチャを示す、統一モデリング言語（ＵＭＬ）状態図である。
【図８】オンライントレーディングサーバから見た、それぞれ、ＲＦＱ、ＱｕｉｃｋＦｉｌｌ、及び休止オーダートレーディングプロトコルを実施するよう、本発明の実施形態において処理される、見積り及びトレードの様々な状態、状態遷移、及びプロトコル独立型ジェスチャを示す、統一モデリング言語（ＵＭＬ）状態図である。
【図９】本発明の実施形態に従って動作するよう構成されたコンピュータネットワークの主要関数コンポーネントを示すハイレベルブロック図である。
【図１０】たとえば図９に表されているオンライントレーディングサーバなどの、本発明の実施形態に従って動作するよう構成されたオンライントレーディングサーバ内で遂行されるステップを示すハイレベルの流れ図である。
【図１】
2008503794.tif 000004
【図２Ａ】
2008503794.tif 000005
【図２Ｂ】
2008503794.tif 000006
【図３】
2008503794.tif 000007
【図４】
2008503794.tif 000008
【図５】
2008503794.tif 000009
【図６】
2008503794.tif 000010
【図７】
2008503794.tif 000011
【図８】
2008503794.tif 000012
【図９】
2008503794.tif 000013
【図１０】
2008503794.tif 000014