JP6924792B2 - 充足率に基づく取引 - Google Patents

Description

関連出願の相互参照
本出願は、２０１４年３月３１日に出願された国際出願第ＰＣＴ／ＵＳ／２０１４／０３２４３３号、件名「外国為替取引（Ｆｏｒｅｉｇｎ Ｅｘｃｈａｎｇｅ Ｔｒａｄｉｎｇ）」の国内段階出願である、２０１４年４月１日に出願された米国特許出願第１４／３４８，９１９号の一部継続出願であり、２０１３年１１月７日に出願された米国特許仮出願第６１／９０１，４３８号（ヤコブ・ラブレス）の利益を主張するものであり、これらの開示は参照によって全内容が本明細書に組み込まれている。

幾つかの実施形態が、アイテムのマッチング及び／又は取引に関する。

システムは、ユーザ間でのアイテムの電子マッチング及び／又は電力取引に使用されてよい。

本発明は、背景技術の課題を解決するためのものである。

様々な例示的実施形態によれば、装置が、特定の取引者のワークステーションに関連付けられた少なくとも１つのプロセッサと、命令が格納された少なくとも１つのメモリと、を含んでよく、命令は、少なくとも１つのプロセッサによって実行された場合に、少なくとも１つのプロセッサに対し、様々なステップを実施するように更に指示する。命令は、少なくとも１つのプロセッサに対し、アイテムに対する、第１の充足率及び第１の応答時間に関連付けられた第１の注文を受信するステップを指示してよい。命令は、少なくとも１つのプロセッサに対し、第１の注文を受信した後に、アイテムに対する、第２の充足率及び第２の応答時間に関連付けられた第２の注文を受信するステップを指示してよい。命令は、少なくとも１つのプロセッサに対し、特定の取引者の注文帳において、第１の注文に関連付けられた第１の充足率及び第１の応答時間と、第２の注文の第１の充足率及び第１の応答時間と、に少なくとも部分的に基づいて、第２の注文を、第１の注文より優先して注文するステップを指示してよい。命令は、少なくとも１つのプロセッサに対し、注文帳において、第２の注文を、第１の注文より優先して注文することに応答して、第１の注文に対抗する、特定の取引者のいかなる注文のいかなる執行よりも前に、特定の取引者の注文を、第２の注文に対抗して執行されるようにするステップを指示してよい。

実施形態によっては、第１の注文を受信するステップは、第１の充足率を受信することを含んでよい。実施形態によっては、第２の注文を受信するステップは、第２の充足率を受信することを含んでよい。

実施形態によっては、第１の充足率は、第１の注文のプロバイダにルーティングされた注文が第１の注文のプロバイダによって応じられた回数と、第１の注文のプロバイダにルーティングされた注文が第１の注文のプロバイダによって応じられなかった回数と、の比較に基づいて決定されてよい。

実施形態によっては、第１の充足率は、第１の注文のプロバイダにルーティングされた、アイテムに対する注文が第１の注文のプロバイダによって応じられた回数と、第１の注文のプロバイダにルーティングされた、アイテムに対する注文が第１の注文のプロバイダによって応じられなかった回数と、の比較に基づいて決定されてよい。

実施形態によっては、第１の充足率は、第１の注文のプロバイダにルーティングされ、第１の注文のプロバイダによって応じられた総量と、第１の注文のプロバイダにルーティングされ、第１の注文のプロバイダによって応じられなかった総量と、の比較に基づいて決定されてよい。

実施形態によっては、第１の充足率は、第１の注文のプロバイダにルーティングされ、第１の注文のプロバイダによって応じられた、アイテムの総量と、第１の注文のプロバイダにルーティングされ、第１の注文のプロバイダによって応じられなかった、アイテムの総量と、の比較に基づいて決定されてよい。

実施形態によっては、第１の充足率は、第１の注文のプロバイダにルーティングされた、アイテムに対する特定の量の範囲の注文が第１の注文のプロバイダによって応じられた回数と、第１の注文のプロバイダにルーティングされた、アイテムに対する特定の量の範囲の注文が第１の注文のプロバイダによって応じられなかった回数と、の比較に基づいて決定されてよい。

実施形態によっては、第２の注文は第１の応答時間に関連付けられてよく、命令は、少なくとも１つのプロセッサに対し、第２の注文を受信するより先に、アイテムに対する第３のユーザからの第３の注文を少なくとも１つのサーバにより受信するステップであり、第３の注文は、価格が第２の注文の価格と等しく、第３の注文は、第１の応答時間より長い第２の応答時間に関連付けられている、上記ステップと、少なくとも１つのサーバにより、注文帳において、第２の注文に関連付けられた第１の応答時間より長い、第３の注文に関連付けられた第２の応答時間に少なくとも部分的に基づいて、第２の注文を、第３の注文より優先して注文するステップと、を更に指示してよく、少なくとも１つのサーバにより取引コマンドを第２のユーザまで伝達する上記ステップは、少なくとも１つのサーバにより、アイテムに関するいかなる取引コマンドを第３のユーザに伝達するステップよりも先に行われ、上記伝達するステップは、注文帳において第２の注文が第３の注文より優先して注文されることに応答して行われる。

実施形態によっては、命令は、少なくとも１つのプロセッサによって実行された場合に、少なくとも１つのプロセッサに対し、第３の注文及び第４の注文を受信するステップと、第３の注文の少なくとも一部分が、第１の注文の少なくとも一部分から独立していない確率を求めるステップと、求められた、第３の注文の少なくとも一部分が、第１の注文の少なくとも一部分から独立していない確率に少なくとも部分的に基づいて、注文帳に記載されている第３の注文及び第４の注文を注文するステップと、を更に指示してよい。

実施形態によっては、第１の充足率は、単位時間当たりの応じる確率を含んでよく、第２の充足率は、単位時間当たりの応じる確率を含んでよい。

本明細書では、上述の実施形態に対し、対応する方法及び機械可読媒体も考えられている。

一例示的実施形態によれば、方法が、アイテムに対する第１の注文及び第２の注文を受信するステップであって、第１の注文は第１のユーザに関連付けられており、第２の注文は第２のユーザに関連付けられており、第１及び第２の注文は、関連付けられている価格が同じであり、第１の注文は、第２の注文より先に受信され、第１の注文には充足率が関連付けられ、第２の注文には充足率が関連付けられる、上記ステップと、アイテムを買うか売る為のコマンドを受信するステップであって、このコマンドは、それに関連付けられた閾値を有する、上記ステップと、第１の注文に関連付けられた充足率が閾値未満であると判定するステップと、第１の注文に関連付けられた充足率が閾値未満であると判定したことの結果として、第１の注文を無視し、第２の注文に関連付けられた充足率を閾値と比較するステップと、第２の注文に関連付けられた充足率が閾値以上であると判定するステップと、第２の注文に関連付けられた充足率が閾値以上であると判定したことの結果として、取引コマンドを第２のユーザに伝達するステップと、第２のユーザに取引コマンドを伝達することに応答して、第２のユーザが取引コマンドに対抗する取引をしようとしているという通知を受信するステップと、を含んでよい。本明細書では、対応するシステム及び機械可読媒体も考えられている。

様々な例示的実施形態によれば、方法が様々なステップを含んでよい。少なくとも１つのサーバが、アイテムに対する第１の注文及び第２の注文を受信してよい。第１の注文は第１のユーザに関連付けられてよく、第２の注文は第２のユーザに関連付けられてよい。第１及び第２の注文は、関連付けられている価格が同じであってよい。第１の注文は、前記第２の注文より先に受信されてよい。第１の注文には第１の充足率が関連付けられてよく、第２の注文には第２の充足率が関連付けられてよい。少なくとも１つのサーバが、アイテムを買うか売る為のコマンドを受信してよい。コマンドは、それに関連付けられた閾値を有してよい。少なくとも１つのサーバが、第１の注文に関連付けられた第１の充足率が閾値未満であると判定してよい。第１の注文に関連付けられた充足率が閾値未満であると判定したことの結果として、少なくとも１つのサーバは、第１の注文を無視し、第２の注文に関連付けられた充足率を閾値と比較してよい。少なくとも１つのサーバは、第２の注文に関連付けられた第２の充足率が、第１の注文に関連付けられた第１の充足率より大きいと判定してよい。第２の注文に関連付けられた第２の充足率が、第１の注文に関連付けられた第１の充足率より大きいと判定した結果として、少なくとも１つのサーバは、いかなる取引コマンドを第１のユーザに伝達するよりも先に、取引コマンドを第２のユーザに伝達してよい。第２のユーザに取引コマンドを伝達することに応答して、第２のユーザが取引コマンドに対抗する取引をしようとしているという通知が受信されてよい。本明細書では、対応するシステム及び機械可読媒体も考えられている。

様々な例示的実施形態によれば、方法が、少なくとも１つのサーバにより、アイテムに対する第１の注文及び第２の注文を受信するステップであって、第１の注文は第１のユーザに関連付けられており、第２の注文は第２のユーザに関連付けられており、第１及び第２の注文は、関連付けられている価格が同じであり、第１の注文は、第２の注文より先に受信され、第１の注文には第１の充足率が関連付けられ、第２の注文には第２の充足率が関連付けられる、上記ステップと、少なくとも１つのサーバにより、アイテムを買うか売る為のコマンドを受信するステップであって、このコマンドは、それに関連付けられた条件を有する、上記ステップと、少なくとも１つのサーバにより、第１の注文に関連付けられた第１の充足率が閾値を満たさないと判定するステップと、第１の注文に関連付けられた第１の充足率が閾値を満たさないと判定したことの結果として、少なくとも１つのサーバにより、第１の注文を無視し、第２の注文に関連付けられた第２の充足率が条件を満たすかどうかを判定するステップと、少なくとも１つのサーバにより、第２の注文に関連付けられた第２の充足率が条件を満たすと判定するステップと、第２の注文に関連付けられた第２の充足率が条件を満たすと判定したことの結果として、少なくとも１つのサーバにより、第１の注文に関連するいかなる取引コマンドを伝達するよりも先に、第２の注文に関連付けられた取引コマンドを第２のユーザに伝達するステップと、第２のユーザに取引コマンドを伝達することに応答して、第２のユーザが取引コマンドに対抗する取引をしようとしているという通知を受信するステップと、を含んでよい。本明細書では、対応するシステム及び機械可読媒体も考えられている。

様々な実施形態によれば、非過渡的コンピュータ可読媒体が命令を格納しており、命令は、少なくとも１つのプロセッサによって実行された場合に、少なくとも１つのプロセッサに対し、様々なステップを実施するように指示してよい。命令は、プロセッサに対し、アイテムに対する、第１の充足率及び第１の応答時間に関連付けられた第１の注文を受信するステップを指示してよい。命令は、プロセッサに対し、第１の注文を受信した後に、アイテムに対する、第２の充足率及び第２の応答時間に関連付けられた第２の注文を受信するステップを指示してよい。命令は、プロセッサに対し、特定の取引者の注文帳において、第１の注文に関連付けられた第１の充足率及び第１の応答時間と、第２の注文の第１の充足率及び第１の応答時間と、に少なくとも部分的に基づいて、第２の注文を、第１の注文より優先して注文するステップを指示してよい。命令は、プロセッサに対し、注文帳において、第２の注文を、第１の注文より優先して注文することに応答して、少なくとも１つのプロセッサにより、第１の注文に対抗する、特定の取引者のいかなる注文のいかなる執行よりも前に、特定の取引者の注文を、第２の注文に対抗して執行されるようにするステップを指示してよい。本明細書では、対応するシステム及び方法も考えられている。

上述の利点及び特徴は、代表的な実施形態のものであるに過ぎず、本発明の理解を支援する為にのみ示されている。これらは、特許請求の範囲によって定義される本発明に対する限定であると見なされるべきではない。以下の説明、図面、及び特許請求の範囲から、本発明の実施形態の更なる特徴及び利点が明らかになるであろう。

幾つかの実施形態による一例示的分散型マッチングエンジンを示す図である。 幾つかの実施形態による、平均スプレッドと推定充足率との関係を示す一例示的グラフである。 幾つかの実施形態による、平均スプレッドと推定充足率との関係を示す一例示的グラフである。 幾つかの実施形態による一例示的フローチャートである。

図１を参照すると、一例示的実施形態によるシステム例１００が示されている。システム１００は、１つ以上のコンピューティングシステム（例えば、サーバ）１０１〜１０６を含んでよい。コンピューティングシステム１０１〜１０６は、本明細書では説明の為にサーバと称されてよい。しかしながら、サーバという用語の使用は非限定的であること、並びに、他のタイプのコンピューティングシステムが使用されてよいことを理解されたい。

各サーバ１０１〜１０６は、１つ以上のプロセッサと１つ以上のメモリとを含んでよく、１つ以上のデータベースを含んでよい。各サーバは、ネットワーク用のハードウェア／ソフトウェア／ファームウェアをベースとするインタフェースであって、サーバがネットワーク１１０に接続してネットワーク１１０経由の通信を行うことを可能にするインタフェースを１つ以上含んでよい。ネットワーク１１０は、パブリックネットワーク及び／又はプライベートネットワークを含んでよく、任意のタイプの技術をベースとする有線ネットワーク及び／又は無線ネットワークであってよい。ネットワーク１１０は又、バス式及び／又はバックプレーン式のアーキテクチャを含んでよい。ネットワーク１１０は、ルータ、スイッチ等を含む１つ以上の要素を含んでよい。ネットワーク１１０は、サーバ１０１〜１０６の少なくともそれぞれが互いに通信することを可能にするように構成されてよい。ネットワーク１１０は又、サーバ１０１〜１０６が、ネットワーク１１０上にあってよい、又は、図１に示されていないがネットワーク１１０経由のアクセスが可能である他のネットワーク上にあってよい、他のコンピューティングシステム（例えば、コンピューティングシステム１５０）と通信することを可能にするように構成されてよい。一例として、ネットワーク１１０は、例えば１つ以上のルータ、スイッチ等を介して、１つ以上の他のプライベートネットワーク及び／又はパブリックネットワークとインタフェースされるプライベートネットワークであってよく、これによって、例えば、サーバ１０１〜１０６のいずれかが、そのような他のネットワーク上の他のコンピューティングシステムと通信することが可能になる。サーバ１０１〜１０６のうちの１つ以上とネットワーク１１０とが、ユニキャスト通信、ブロードキャスト通信、及び／又はマルチキャスト通信をサポートするように構成されてよい。マルチキャスト通信はＩＰマルチキャストを含んでよいが、他のタイプのマルチキャストが使用されてもよい。マルチキャストは、信頼できるマルチキャストであっても、信頼できないマルチキャストであってもよい。当業者であれば理解されるように、サーバ１０１〜１０６及びネットワーク１１０について上述されたことは例に過ぎず、追加及び／又は他のサーバ／ネットワーク構成及び機能性が使用されてもよい。例えば、ネットワーク１１０に加えて、サーバ１０１〜１０６のうちの１つ以上が、追加のネットワーク用のハードウェア／ソフトウェア／ファームウェアをベースとするインタフェースであって、図１に示されていない１つ以上の他のパブリックネットワーク及び／又はプライベートネットワークにサーバが接続し、これらのネットワークを介して通信を行うことを可能にするインタフェースを１つ以上含んでもよい。

システム１００内のサーバ１０１〜１０６のうちの１つ以上が、ハードウェア（例えば、プロセッサ構成、プロセッサ数、プロセッサ速度、メモリサイズ、メモリ速度等）、及び／又はシステムソフトウェア（例えば、オペレーティングシステム）、及び／又はネットワークインタフェース速度の観点において、同一の構成であってよく、且つ／又は、ほぼ同一の構成であってよい。同様に、サーバ１０１〜１０６のうちの１つ以上の、ネットワーク１１０経由で他の任意のサーバと通信する能力が同じであってよい。サーバ１０１〜１０６のうちの１つ以上が、同一ラック内、同一室内、同一建物内等に配置されてよい。更に、ネットワーク１１０を構成するネットワーク要素も、サーバ１０１〜１０６と同じ場所に配置されてよい。ここでも、追加及び／又は他の構成も可能である。例えば、各サーバは、性能が異なってよい。

システム１００は、クラウドコンピューティングシステムと称されてよい。システム１００は、システム１００のリソースを１人以上の他のユーザ／カスタマ、例えば、ユーザＡ〜Ｆにリース又はレンタルする１つ以上のエンティティによって、所有されてよく、且つ／又は一部所有されてよく、且つ／又は保守／運用されてよい。ユーザＡ〜Ｆは、個々の人及び／又は会社であってよく、例えば、銀行、投資ファンド、商社等であってよい。代替及び／又は追加として、ユーザＡ〜Ｆのうちの１人以上が、システム１００のリソースを所有してよい。一例として、サーバ１０１は、ユーザＡにリースされるか、ユーザＡが所有してよく、サーバ１０２は、ユーザＢにリースされるか、ユーザＢが所有してよく、サーバ１０３は、ユーザＣにリースされるか、ユーザＣ所有してよく、サーバ１０４は、ユーザＤにリースされるか、ユーザＤが所有してよく、サーバ１０５は、ユーザＥにリースされるか、ユーザＥが所有してよく、且つ／又は、サーバ１０６は、ユーザＦにリースされるか、ユーザＦが所有してよい。一般に、各サーバ１０１〜１０６は、そのサーバのリソースにアクセスできる特定のユーザに割り当てられてよい。任意のユーザが、システム１００内で、複数のサーバに関連付けられてよく、複数のサーバをリースされてよく、複数のサーバを所有してよい。一例によれば、システム１００は、追加サーバがシステムに追加されてよいという点で拡張可能であってよく、それらのサーバは、ユーザＡ〜Ｆ及び／又は新規ユーザにリースされるか、所有されてよい。システム１００は、１つ以上のサーバの追加及び／又は除去が他のユーザに影響しないように構成されてよい。別の例として、任意のサーバが、互いに関連付けされていない異なる複数のユーザにリース／レンタルされてよい。サーバは、ユーザのうちの１人によるサーバの使用が他のユーザに影響しないように、且つ、他のユーザによるサーバの使用がその１人のユーザに影響しないように構成されてよい。

一例によれば、システム１００は、取引システム又はマッチングシステム、特に分散取引／マッチングシステムとして動作してよく、且つ／又は、そのように構成されてよく、これらのシステムは、ユーザＡ〜Ｆなどのユーザが互いに１つ以上のアイテムの取引及び／又は売買をすることを可能にする。システム１００上で取引されるアイテムは、システムのユーザＡ〜Ｆのうちの１人以上が所有するものであってよい。代替及び／又は追加として、ユーザＡ〜Ｆのうちの１人以上が、本人及び／又は仲介業者及び／又は（例えば、アイテムを所有しうるエンティティの代わりに行動する）代理人であってよい。取引されるアイテムは、有形アイテム及び／又は無形アイテムを含んでよい。一例によれば、システム１００は、例えば確定利付証券、普通株、外国為替等を含む、１つ以上の金融商品を取引するように構成されてよい。従って、各ユーザＡ〜Ｆは、システム１００を使用して、システムの１人以上の他のユーザと、１つ以上の金融商品を取引することが可能である。当業者であれば理解されるように、不動産（例えば、土地、家屋、及び／又は建物）、消費者製品（例えば、自動車、電子機器）、チケット（例えば、航空券、コンサートチケット）等のような、他のタイプのアイテムも、システム１００を介して取引及び／又は売買されてよい。当業者であれば理解されるように、取引システム又はマッチングシステムに対する追加及び／又は代替として、システム１００は、他のタイプのシステムとして動作してよく、構成されてよい。

又、サーバ１０１〜１０６のうちの１つ以上が、そのサーバ上で実行される１つ以上のアプリケーション１２０ａ〜ｆを含んでよい（例えば、メモリ内に格納済みであってよい）。一例として、アプリケーション１２０ａ〜ｆは、本明細書ではマッチングエンジンと称されてよい。ただし、他のタイプ、及び／又は追加のタイプのアプリケーションも可能である。マッチングエンジン１２０ａ〜ｆは、ユーザＡ〜Ｆが互いの間でアイテムの売買取引を行うことを可能にしてよい。マッチングエンジン１２０ａ〜ｆは、サーバ１０１〜１０６上で実行される、ソフトウェア及び／又はファームウェア及び／又はハードウェアをベースとするアプリケーションであってよい。各サーバは、１つ及び／又は複数のマッチングエンジンを含んでよい。各サーバは、追加アプリケーション及び／又は他のアプリケーションを含んでよい。各サーバ１０１〜１０６のマッチングエンジンは、同一且つ／又はほぼ同一のアプリケーションであってよく、異なるアプリケーションであってもよい。例えば、各マッチングエンジンは、同様のマッチングアルゴリズムを実行してよい。別の例として、マッチングエンジンが異なれば、実行されるマッチングアルゴリズムも異なってよい。マッチングエンジン１２０ａ〜ｆは、システム１００を所有／運用するエンティティによって開発／保守されてよい。又、そのようなエンティティは、各サーバで実行される他のアプリケーション及び／又は追加のアプリケーションも開発／保守してよい。

又、各サーバは、ユーザＡ〜Ｅなどのユーザに関連付けられて各サーバ上で実行される１つ以上のアプリケーション１２２ａ〜ｅを含んでよい（例えば、メモリ内に格納済みであってよい）。一例として、アプリケーション１２２ａ〜ｅは、本明細書では取引アプリケーションと称されてよい。ただし、他のタイプ、及び／又は追加のタイプのアプリケーションも可能である。別の例によれば、１つ以上の取引アプリケーション（例えば、アプリケーション１２２ｆ）がサーバ１０１〜１０５上で実行されなくてよい。その代わりに、このアプリケーションは、サーバ（例えば、サーバ１０６）に接続されたコンピューティングシステム（例えば、コンピューティングシステム１３０）上で実行されてよい。コンピューティングシステム１３０は、サーバ１０６及び／又は他のシステム１００の要素と同じ場所に配置されてもされなくてもよい。コンピューティングシステム１３０とサーバ１０６は、１つ以上のプライベートネットワーク及び／又はパブリックネットワーク１３１を介して通信してよい。別の例として、コンピューティングシステム１３０とサーバ１０６は、ネットワーク１１０を介して通信してよい。一例によれば、コンピューティングシステム１３０は、システム１００を所有及び運用するエンティティが所有及び運用してよい。別の例によれば、コンピューティングシステム１３０は、このコンピューティングシステムが接続されているサーバに関連付けられたユーザ（ここではユーザＦ）が所有及び運用してよい。当業者であれば理解されるように、これらの構成は例に過ぎず、他の構成、及び／又は追加の構成も可能である。例えば、各サーバ１０１〜１０５／コンピューティングシステム１３０は、１つ及び／又は複数の取引アプリケーションを含んでよい。各サーバ１０１〜１０５／コンピューティングシステム１３０は又、ユーザＡ〜Ｆなどのユーザに関連付けられた追加のアプリケーション及び／又は他のアプリケーションを含んでもよい。

一例によれば、各取引アプリケーション１２２ａ〜ｆは、それぞれのマッチングエンジン１２０ａ〜ｆと相互通信することにより、システム１００のユーザＡ〜Ｆがアイテムを取引することを可能にするように構成されてよい。各取引アプリケーション１２２ａ〜ｆは、取引ストラテジを実行することにより、（例えば、それぞれのユーザＡ〜Ｆの代理として）取引注文（例えば、ビッド、オファー、ヒット、テイク）を生成する自動取引アルゴリズムであってよい。任意のサーバにおける各取引アプリケーションが、１つ以上のアイテムを取引するように構成されてよい。各取引アプリケーション１２２ａ〜ｆは、ソフトウェア及び／又はファームウェア及び／又はハードウェアをベースとするアプリケーションであって、サーバ１０１〜１０５／コンピューティングシステム１３０のそれぞれにおいて実行されるアプリケーションであってよい。各取引アプリケーションは、他の取引アプリケーションと異なるものであってよく、それぞれのサーバが割り当てられているユーザが開発してよい。例えば、ユーザＡは、取引アプリケーション１２２ａを開発し、このアプリケーションを（例えば、管理アプリケーションを用いて）サーバ１０１にロードするか、ロード済みにし、サーバ１０１でこのアプリケーションを実行してよい。同様に、ユーザＢは、取引アプリケーション１２２ｂを開発し、このアプリケーションを（例えば、管理アプリケーションを用いて）サーバ１０２にロードするか、ロード済みにし、サーバ１０２でこのアプリケーションを実行してよい。更に、且つ／又は別の例として、取引アプリケーション１２２ａ〜ｆは、システム１００を所有／運用するエンティティから提供される汎用アプリケーション（ＡＰＩなど）であってよい。各インスタンスでは、それぞれのユーザＡ〜Ｆが、各自のニーズを満たす為に、（例えば、それぞれのサーバから離れているコンピューティングシステムを介するか、管理アプリケーションを介するか、且つ／又は、それぞれのサーバに接続されたユーザインタフェース装置（キーボード、マウス等）を介するなどしてユーザがインタフェースするＡＰＩを用いて）それぞれのアプリケーションをカスタマイズしてよい。当業者であれば理解されるように、これらの構成は例に過ぎず、他の構成、及び／又は追加の構成も可能である。例えば、取引アプリケーション１２２ａ〜ｆが、取引ストラテジを実行する自動取引アルゴリズムである代わりに、取引アプリケーション１２２ａ〜ｆのうちの１つ以上が、それぞれのユーザがシステム１００にインタフェースして注文を生成することを可能にしてよい。例えば、それぞれのユーザが（離れているコンピューティングシステムを介するか、且つ／又は、それぞれのサーバに接続されたユーザインタフェース装置（キーボード、マウス等）を介するなどして）サーバのそれぞれのマッチングエンジンに対して注文を手動でサブミットすることが可能であってよい。

前述のように、各サーバにおいて、マッチングエンジン１２０ａ〜ｆは、それぞれの取引アプリケーション１２２ａ〜ｆと共に、ユーザＡ〜Ｆが互いにアイテムを取引することを可能にしてよい。一例として、マッチングエンジンの１つのインスタンスが、ある特定のアイテム（例えば、１０年債）を取引するように構成されてよい。従って、任意のユーザＡ〜Ｆが異なる複数のアイテム（例えば、５年債と１０年債）を取引しようとする場合、それぞれのサーバにおいてマッチングエンジン１２０の複数のインスタンスが実行されてよく、各インスタンスは、それぞれの取引アプリケーション１２２の１つ以上のインスタンスと通信する。別の例として、それぞれの取引アプリケーションの１つ以上のインスタンスと通信するマッチングエンジンの１つのインスタンスが、複数のアイテムを取引するように構成されてよい。当業者であれば理解されるように、これらは例に過ぎず、他の構成、及び／又は追加の構成も可能である。例えば、或るサーバが異なる複数のユーザによって使用されている場合、このサーバは、同じアイテムの取引を異なる複数のユーザと行うように構成された、マッチングエンジンの複数のインスタンスを有してよい。説明の都合上に過ぎないが、マッチングエンジン１２０は、１つのアイテムの取引を可能にするものとして説明される。

一例によれば、或るアイテムを取引しようとする或るユーザＡ〜Ｆに対しては、それぞれのサーバのマッチングエンジン１２０ａ〜ｆが、そのサーバ上で、そのアイテムに関する注文帳１２４ａ〜ｆを保守してよく、又は保守するように構成されてよい。一例として、それぞれのサーバのメモリ内で、それぞれの注文帳が保守されてよい。例えば、ユーザＡ〜Ｅのそれぞれが或るアイテムを取引しようとする場合、各サーバ１０１〜１０５は、そのアイテムに関する注文帳１２４ａ〜ｅを有してよい。ユーザＦがそのアイテムを取引しようとしないのであれば、サーバ１０６は、そのアイテムに関する注文帳を有さなくてよい。このようにして、或るアイテムに関する注文帳が複数のサーバにまたがって分散又は非集中化されてよい。同様に、ユーザＡ〜Ｅのそれぞれが第２のアイテムも取引しようとする場合は、それぞれのサーバ１０１〜１０５のマッチングエンジン１２０ａ〜ｅも、そのサーバ上で、第２のアイテムに関する第２の注文帳を保守してよい。当業者であれば理解されるように、追加及び／又は他の注文帳構成も可能である。

更なる例によれば、システム１００を介して取引されてよいアイテムごとに、ネットワーク１００上のポート（例えば、インターネットプロトコル（ＩＰ）ポート）又はチャネル等が割り当てられてよい。例えば、第１のアイテムにポート「ｘ」が割り当てられてよく、第２のアイテムにポート「ｙ」が割り当てられてよく、以降も同様であってよい。ここで詳述されるように、第１のアイテムに関する、ネットワーク１１０経由のサーバ１０１〜１０６間の通信の一部又は全てがポート「ｘ」を介して行われてよく、同様に、第２のアイテムに関する、ネットワーク１１０経由のサーバ１０１〜１０６間の通信の一部又は全てがポート「ｙ」を介して行われてよい。更なる例によれば、或るユーザ、例えばＡが第１のアイテム及び第２のアイテムを取引しようとする場合は、サーバ１０１／マッチングエンジン１２０ａが、メッセージ／コマンド／情報／データの送信及び／又は受信（及び／又はリスン、モニタリング等）を、ポート「ｘ」及びポート「ｙ」において行うように構成されてよい。このようにして、ユーザＡは、（例えば、取引アプリケーション１２２ａを用いて）２つのアイテムに関する情報／データの送信／受信を行ってよい。同様に、例えば、ユーザＡが第１のアイテムを取引しようとするが第２のアイテムを取引しない場合は、サーバ１０１／マッチングエンジン１２０ａが、メッセージ／コマンド／情報／データの送信及び／又は受信（及び／又はリスン、モニタリング等）を、ポート「ｘ」において行い、ポート「ｙ」においては行わないように構成されてよい。このようにして、例えば、サーバ１０１／ユーザＡは、関心の対象ではない第２のアイテムに関するメッセージ／コマンド／情報／データを受信しないことを選択してよい。同様に、ユーザＡが（例えば、取引アプリケーション１２２ａを用いて）第２のアイテムに関する情報を後で受信しようとする場合は、サーバ１０１／マッチングエンジン１２０ａが、メッセージの送信及び／又は受信（及び／又はリスン、モニタリング等）をポート「ｙ」において行うように構成されてよい。一例によれば、取引アプリケーション１２２ａ〜ｆが（おそらくはユーザ制御により）どのアイテムが取引され、且つ／又は、どのアイテムが取引されないかを判定してよく、このようにして、例えば、どのポートがモニタリングされるか、並びに、どのアイテムに関して注文帳が保守されるかについて、それぞれのサーバ／マッチングエンジンの構成を制御してよい。別の例として、ユーザが（例えば、それぞれのサーバから離れているコンピューティングシステムを介するか、管理アプリケーションを介するか、且つ／又は、それぞれのサーバに接続されたユーザインタフェース装置（キーボード、マウス等）を介するなどしてユーザがインタフェースするＡＰＩを用いて）どのポートがモニタリングされるか、並びに、どのアイテムに関して注文帳が保守されるかについて、それぞれのサーバ／マッチングエンジンの構成を制御してよい。

システム１００の一動作例によれば、或るユーザ／取引アプリケーション、例えば、ユーザＡ／取引アプリケーション１２２ａが、或るアイテム、例えば、アイテム「ｗ」を取引することに関心がある場合、ユーザＡ／取引アプリケーション１２２ａは、アイテム「ｗ」に対するビッド注文又はオファー注文を生成してよい（この注文は価格及び／又はサイズを含んでよい）。取引アプリケーション１２２ａは、この注文をマッチングエンジン１２０ａに転送してよく、マッチングエンジン１２０ａは、この注文を注文帳１２４ａ（即ち、サーバ１０１にある、アイテム「ｗ」に関する注文帳）に記載してよい。この注文は、図１では、注文帳１２４ａ内の注文１４０として示されている。システム１００の一動作例によれば、ユーザＡが注文１４０を生成したので、マッチングエンジン１２０ａが、注文１４０に対抗する注文の執行の管理（例えば、注文１４０に対抗する逆注文（ｃｏｎｔｒａ−ｏｒｄｅｒｓ）のマッチング）を行う役割であってよい。システム１００の更なる動作例によれば、マッチングエンジン１２０ａは、注文１４０を、アイテム「ｗ」に対して割り当てられたポートからネットワーク１１０経由でマルチキャストしてもよい。マルチキャストされる注文は、この注文がユーザＡ／取引アプリケーション１２２ａ／マッチングエンジン１２０ａ及び／又はサーバ１０１から発せられたことを意味する何らかの明示（ｄｅｓｉｇｎａｔｉｏｎ）を含んでよい。システム１００上の他のユーザ／サーバのそれぞれがアイテム「ｗ」に対して関心を有してよく、従って、そのアイテムに関するポート上での受信を行うように構成されている場合は、それぞれのマッチングエンジンが注文１４０を受信し、この注文を、そのアイテムに関するそれぞれの注文帳に記載してよい。例えば、ユーザＢ／取引アプリケーション１２２ｂ及びユーザＣ／取引アプリケーション１２２ｃがアイテム「ｗ」に対して関心を有してよく、従って、マッチングエンジン１２０ｂ及び１２０ｃが、注文１４０を受信し、この注文を（図１において１４０’及び１４０”として示されている）それぞれの注文帳１２４ｂ及び１２４ｃに記載するように構成されてよい。同様に、マッチングエンジン１２０ｂ及び１２０ｃは、この注文がユーザＡ／取引アプリケーション１２２ａ／マッチングエンジン１２０ａ及び／又はサーバ１０１から発せられたことを意味する何らかの明示を記録してよい。それぞれのマッチングエンジン１２０ｂ及び１２０ｃも、注文１４０に関する情報を、それぞれの取引アプリケーション１２２ｂ及び１２２ｃ及び／又はユーザＢ及びＣに転送してよい。注文１４０はユーザＢ〜Ｃ／取引アプリケーション１２０ｂ〜ｃに知られることになってよいが、この注文の出所（即ち、ユーザＡの身元）は、システム１００が匿名のマッチングシステムかどうかに応じて、知られることになってもならなくてもよい。

同様に、ユーザＢ／取引アプリケーション１２２ｂがアイテム「ｗ」に対する注文を生成する場合、取引アプリケーション１２２ｂは、この注文をマッチングエンジン１２０ｂに転送してよく、マッチングエンジン１２０ｂは、この注文を注文帳１２４ｂ（即ち、サーバ１０２にある、アイテム「ｗ」に関する注文帳）に記載してよい。この注文は、図１では、注文帳１２４ｂ内の注文１４２として示されている。ユーザＢが注文１４２を生成したので、マッチングエンジン１２０ｂが、注文１４２に対抗する注文の執行の管理（例えば、注文１４０に対抗する逆注文のマッチング）を行う役割であってよい。マッチングエンジン１２０ｂは、注文１４２を、アイテム「ｗ」に対して割り当てられたポートからネットワーク１１０経由でマルチキャストしてもよい。マルチキャストされる注文は、この注文がユーザＢ／取引アプリケーション１２２ｂ／マッチングエンジン１２０ｂ及び／又はサーバ１０２から発せられたことを意味する何らかの明示を含んでよい。システム１００上の他のユーザ／サーバのそれぞれがアイテム「ｗ」に対して関心を有してよく、従って、そのアイテムに関するポート上での受信を行うように構成されている場合は、それぞれのマッチングエンジンが注文１４２を受信し、この注文を、そのアイテムに関するそれぞれの注文帳に記載してよい。例えば、前述のように、ユーザＡ／取引アプリケーション１２２ａ及びユーザＣ／取引アプリケーション１２２ｃがアイテム「ｗ」に対して関心を有している為、マッチングエンジン１２０ａ及び１２０ｃは、注文１４２を受信し、この注文を（図１において１４２’及び１４２”として示されている）それぞれの注文帳１２４ａ及び１２４ｃに記載してよい。同様に、マッチングエンジン１２０ａ及び１２０ｃは、この注文がユーザＢ／取引アプリケーション１２２ｂ／マッチングエンジン１２０ｂ及び／又はサーバ１０２から発せられたことを意味する何らかの明示を記録してよい。それぞれのマッチングエンジン１２０ａ及び１２０ｃも、注文１４２に関する情報を、それぞれの取引アプリケーション１２２ａ及び１２２ｃ及び／又はユーザＡ及びＣに転送してよい。

システム１００の更なる動作例によれば、ユーザＡ／取引アプリケーション１２２ａは、注文１４０の全て又は一部を後で取り消す場合には、この注文に対する取り消しコマンドを生成してよく、このコマンドはマッチングエンジン１２０ａに転送されてよい。そのマッチングエンジン１２０ａは、この注文を自身の注文帳１２４ａから取り消してよく、又、取り消しコマンドを、アイテム「ｗ」に対して割り当てられたポートからネットワーク１１０経由でマルチキャストしてもよい。取り消しコマンドは、取り消しコマンドがどの注文まで参照するかを他のサーバが知ることができるように、取り消しコマンドがユーザＡ／取引アプリケーション１２２ａ／マッチングエンジン１２０ａ及び／又はサーバ１０１から発せられたことを意味する何らかの明示を含んでよい。他のユーザ／サーバのそれぞれがアイテム「ｗ」に対して関心を有してよく、従って、そのアイテムに関するポート上での受信を行うように構成されている場合は、それぞれのマッチングエンジンが取り消しコマンドを受信し、それぞれの注文を、そのそれぞれの注文帳から取り消してよい。例えば、マッチングエンジン１２０ｂ〜ｃは、取り消しコマンドを受信し、注文１４０を注文帳１２４ｂ〜ｃから取り消してよい。マッチングエンジン１２０ｂ〜ｃは又、注文１４０が無効になったことを取引アプリケーション１２２ｂ〜ｃ及び／又はユーザＢ及びＣに通知してよい。

Ａからのビッド／オファー注文１４０が取り消されていないと仮定すると、ユーザＢ／取引アプリケーション１２２ｂは、この注文に対抗する取引コマンド／逆注文／反対注文、例えば、ヒット／テイクを生成してよい（ヒット／テイクコマンドは価格及びサイズを含んでよい）（別の例として、取引コマンドは、（例えば、特定の価格で）注文１４０とクロス／マッチするビッド又はオファーであってよい）。取引アプリケーション１２２ｂは、取引コマンドをマッチングエンジン１２０ｂに転送してよく、マッチングエンジン１２０ｂは、自身の注文帳１２４ｂにおいてマッチする注文を検索してよく、且つ、このコマンドが少なくともユーザＡからの注文１４０とマッチすることを認識／判定してよい（マッチングエンジン１２０ｂは、注文１４２がユーザＢから発せられたことを認識していれば、注文１４２に対して取引コマンドをマッチングさせようとしなくてよい）。これに対して、マッチングエンジン１２０ｂは、取引コマンドを、アイテム「ｗ」に対して割り当てられたポートからネットワーク１１０経由でマルチキャストしてよい。この取引コマンドが、例えば、ユーザＢ／取引アプリケーション１２２ｂ／マッチングエンジン１２０ｂ／及び／又はサーバ１０２から発せられたことを意味する何らかの明示を追加することに加えて、取引コマンドは、ユーザＡ／取引アプリケーション１２２ａ／サーバ１０１／及び／又はマッチングエンジン１２０ａに対して明確にタグ付け／指定／仕向けされてよく、これは、前述のように、マッチングエンジン１２０ａが、ユーザＡ／サーバ１０１から発せられる注文に対抗する執行の役割であってよい為である。当業者であれば理解されるように、マッチングエンジン１２０ａが対抗する執行の役割であってよい注文に取引コマンドが対抗していることを、マッチングエンジン１２０ａに通知する為に、他の手段が用いられてよい。システム１００の一動作例によれば、他のサーバ／マッチングエンジン（例えば、アイテム「ｗ」に対して割り当てられたポートにおいてリスンしているサーバ／マッチングエンジン）は、マルチキャストされた取引コマンドを受信してよく、ユーザＡ／取引アプリケーション１２２ａ／サーバ１０１／及び／又はマッチングエンジン１２０ａが指定されていると認識されたコマンドは無視してよい。システム１００の別の動作例によれば、そのようなサーバ／マッチングエンジンは、マルチキャストされた取引コマンドを受信し、取引の可能性をそれぞれの取引アプリケーション及び／又はユーザに通知してよい。一例によれば、実際の取引コマンドは暗号化されてよい。

更なる例によれば、ユーザＢのものではない追加注文が注文帳１２４ｂにあり、ユーザＢ／取引アプリケーション１２２ｂからの取引コマンドが、注文１４０を超えるサイズであり、且つ／又は、従って、これらの他の注文と対抗する場合、マッチングエンジン１２０ｂは、（それらの追加注文を担当するサーバ等に対してタグ付けされた）追加の取引コマンドを、アイテム「ｗ」に対して割り当てられたポートからネットワーク１１０経由でマルチキャストしてもよい。別の代替として、マッチングエンジン１２０ｂは、ユーザＡ／取引アプリケーション１２２ａ／サーバ１０１／及び／又はマッチングエンジン１２０ａに対してタグ付けされた同じ取引コマンドを使用してよく、更に、この取引コマンドを、追加注文を担当するサーバ等に対してタグ付けしてよい。当業者であれば理解されるように、他の変形も可能である。

サーバ１０１／マッチングエンジン１２０ａは、取引コマンドを受信した時点で、そのコマンドがサーバ１０１／マッチングエンジン１２０ａに対してタグ付けされていることを認識することになる。マッチングエンジン１２０ａは、次に、注文１４０がまだ使用可能かどうか（例えば、取り消されていないかどうか、且つ／又は、他のユーザによって対抗して執行されていないかどうか、まだ注文帳１２４ａに記載されているかどうか）を判定してよい。注文１４０がまだ使用可能であれば、マッチングエンジン１２０ａは、注文１４０を自身の注文帳１２４ａから削除することにより（又は、注文１４０の全てに対抗して執行されるわけではない場合には、注文帳における注文１４０の使用可能量を減らすことにより）、注文１４０に対抗する取引コマンドを執行してよい。マッチングエンジン１２０ａは又、取引アプリケーション１２２ａ及び／又はユーザＡと通信して、注文１４０に対抗して執行されたことを通知してもよい。更に、マッチングエンジン１２０ａは、取引確認メッセージを、アイテム「ｗ」に対して割り当てられたポートからネットワーク１１０経由でマルチキャストしてよい。確認メッセージは、実際に対抗して執行された注文１４０の量に関する通知を含んでよい。確認メッセージは、ユーザＢ／取引アプリケーション１２２ｂ／マッチングエンジン１２０ｂ／及び／又はサーバ１０２に対して明確にタグ付けされてよい。マッチングエンジン１２４ｂは、確認メッセージを受信した時点で、注文１４０（又はその一部）を自身の注文帳１２４ｂから削除してよく、又、マッチした注文を、ユーザＢ及び／又は取引アプリケーション１２２ｂに通知してよい。ユーザＢに加えて、アイテム「ｗ」に対して関心を有する他の全てのユーザ／サーバ／マッチングエンジンが、確認メッセージを受信してよく、このことは、それぞれのマッチングエンジンが注文１４０（又はその一部）を自身の注文帳から削除することを引き起こす。又、そのようなマッチングエンジンは、マッチした注文を、それぞれのユーザ及び／又は取引アプリケーションに通知してよい。従って、マッチングエンジン１２０ｃは、注文１４０を自身の注文帳１２４ｃから削除してよく、又、取引アプリケーション１２２ｃ及び／又はユーザＣに通知してよい。別の例及び／又は追加の例によれば、マッチングエンジン１２０ａは、確認メッセージをマルチキャストすることに加えて、他の何らかのコマンド（取り消しコマンドなど）をマルチキャストすることにより、（エンジン１２０ｃのような）他のマッチングエンジンが注文１４０を自身の注文帳から削除することを引き起こしてよい。当業者であれば理解されるように、他のコマンドシーケンス及び／又は追加のコマンドシーケンスが使用されてよい。

別の例として、マッチングエンジン１２０ａが、上述のように、ユーザＢから取引コマンドを受信した時点で、注文１４０が使用可能のままではない（例えば、取り消されているか、且つ／又は、既に他のユーザによって対抗して執行されている）と判定した場合、マッチングエンジン１２０ａは、注文１４０に対する取り消しメッセージ、及び／又は、取引の未確認を明確に示すメッセージ、及び／又は、取引が失敗したこと、及び／又は、取引が完了しなかったこと等をマルチキャストしてよい（これらは、ユーザＢ／取引アプリケーション１２２ｂ／マッチングエンジン１２０ｂ／及び／又はサーバ１０２に対して明確にタグ付けされてよい）。いずれにせよ、メッセージは、注文１４０をそれぞれの注文帳から削除することに適用可能な全てのマッチングエンジンに対して作用するものであってよい。ここでも、それぞれの取引アプリケーション及び／又はユーザに対しては、それぞれのマッチングエンジンから、コマンド１４０がもはや使用可能ではないことが通知されてよい。取引アプリケーション１２２ｂ及び／又はユーザＢに対しては、取引が失敗したことが明確に通知されてよい。

別の例によれば、マッチングエンジン１２０ａが、上述のように、注文１４０がまだ使用可能であると判定してよく、その後、マッチングエンジン１２０ａは、最初に取引アプリケーション１２２ａ及び／又はユーザＡと通信して、注文１４０に対抗する執行の要求がまだあるかどうかを判定してよい。もしあれば、マッチングエンジン１２０ａは、確認メッセージを生成すること等に関して上述のように処理を進めてよい。別の例として、取引アプリケーション１２２ａ及び／又はユーザＡは、注文１４０に対抗する執行の要求がまだあることを通知してよいが、その要求が注文１４０の使用可能サイズより小さい（即ち、取引コマンドが要求するサイズより小さい）サイズに対する要求であることを通知してよい。ここでも、マッチングエンジン１２０ａは、確認メッセージを生成すること等に関して上述のように処理を進めてよく、メッセージは、例えば、対抗して執行された注文１４０のサイズを通知する。代替として、ユーザＡ及び／又は取引アプリケーション１２２ａが注文１４０に対抗する執行の要求をもはや有してない場合、マッチングエンジン１２０ａは、注文１４０を自身の注文帳１２４ａから削除してよく、その後、取り消しメッセージ及び／又は未確認メッセージを生成することに関して上述のように処理を進めてよく、結果として注文１４０は他の注文帳から削除される。ここでも、他のサーバにおけるそれぞれの取引アプリケーション／ユーザに対しては、それぞれのマッチングエンジンから、コマンド１４０がもはや使用可能ではないことが通知されてよい。これらに対しては又、注文１４０がペンディングである間、この注文のそれぞれの発信者（即ち、ユーザＡ）がもはやその注文に対抗する執行を要求していないことが通知されてよい。当業者であれば理解されるように、注文１４０に対抗する執行又は不執行に関する他のメッセージフロー及び／又は追加のメッセージフローも可能である。

上述の動作例の更なる態様によれば、例えば、ユーザＣ／取引アプリケーション１２２ｃが、ここで論じられているユーザＢ／取引アプリケーション１２２ｂとほぼ同じタイミングで注文１４０に対抗する取引コマンドを生成した場合、マッチングエンジン１２０ｃは、マッチングエンジン１２０ｂと同様の方法で、取引コマンドをネットワーク１１０経由でマルチキャストしてよい。そのようなイベントにおいては、マッチングエンジン１２０ａは、注文１４０に対抗する２つの取引コマンドを（１つはユーザＢから、１つはユーザＣから）受信する可能性があり、それぞれは必然的に、いずれが先にサーバ１０１に到達するかに応じて、一方が他方より先に待ち行列に入ることになる。ここでも、マッチングエンジン１２０ａは、ユーザＡ／サーバ１０１から発せられる注文（ここでは、例えば、注文１４０）に対抗する執行を管理する役割であってよい為、マッチングエンジン１２０ａは、（ユーザＢ及びユーザＣの両方が注文１４０のフルサイズを執行しようとしたと仮定すれば）いずれが先にサーバ１０１に到達したかに応じて、ユーザＢ及びユーザＣのうちのいずれか一方にのみ対抗して注文１４０を執行してよい。マッチングエンジン１２０ａは、例えば、他の取引コマンドに対抗する未確認を送信してよい。別の例として、ユーザＢ及びユーザＣの取引コマンドは、注文１４０が両方に応じるのに十分なサイズではない場合は、一方の取引コマンドがフルに執行されてよく、他方の取引コマンドが一部のみ執行されてよい。当業者であれば理解されるように、他の変形も可能である。

当業者であれば理解されるように、システム１００の上述の動作例は一例であり、他の動作例及び／又は追加の動作例も可能である。例えば、或るアイテムに対し、ネットワーク１００上の複数のポート又はチャネル等が割り当てられてよい。例えば、或るアイテムに対し、１つのポートが、そのアイテムに対するビッドのみをマルチキャストすることに使用されてよく、別のポートが、そのアイテムに対するオファーのみをマルチキャストすることに使用されてよく、別のポートが、そのアイテムに対する取引コマンド／逆注文／反対注文（例えば、ヒット／テイク）のみをマルチキャストすることに使用されてよく（或いは、１つのポートがヒットに、別のポートがテイクに使用されてよく）、別のポートが、そのアイテムに対する取引確認メッセージをマルチキャストすることに使用されてよく（或いは、例えば、１つのポートがヒットに対抗する取引確認に、別のポートがテイクに対抗する取引確認に使用されてよく）、別のポートが、そのアイテムに対する取引未確認メッセージをマルチキャストすることに使用されてよく（或いは、例えば、１つのポートがヒットに対抗する未確認に、別のポートがテイクに対抗する未確認に使用されてよく）、別のポートが、そのアイテムに対するビッドの取り消しメッセージをマルチキャストすることに使用されてよく、且つ／又は、別のポートが、そのアイテムに対するオファーの取り消しメッセージ等をマルチキャストすることに使用されてよく、これには、他のメッセージの為のポートを含む、これらの他の任意の組み合わせが含まれてよい。ここでも、他の変形も可能である。

更なる例示的特徴によれば、システム１００は、ドロップコピーの生成を不要にしてよい。例えば、ここで説明されたように取引確認メッセージを生成するマッチングエンジン１２０ａにおいて、例えば、他のマッチングエンジン１２０ｂ〜ｆが、場合によっては、このメッセージを受信し、それぞれの注文帳１２４ｂ〜ｆを更新することに加えて、ネットワーク１１０に接続された（コンピューティングシステム１５０として示されている）他のコンピューティングシステムもこれらのメッセージを受信してよい。これらの他のコンピューティングシステムは、システム１００を使用してアイテムを取引しようとするユーザ／カスタマに関連付けられても関連付けられなくてもよい。例えば、コンピューティングシステム１５０は、本明細書に記載のユーザＡとユーザＢとの間のトランザクション例のように、トランザクションをクリアできるクリアリングハウスに関連付けられてよい。

システム１００の更なる例示的特徴によれば、例えば、取引アプリケーション（例えば、アプリケーション１２２ｅ）が、例えば、或るアイテムに対して市場外価格でのビッド及び／又はオファーのサブミットを開始した為、取引アプリケーション１２２ｅを停止して、場合によってはそれらのビッド及びオファーを市場から除去することが必要である場合には、サーバ１０５をオフラインにしてよい。サーバ１０５をオフラインにすることは、例えば、（管理者からのコマンドによるなどして）サーバ全体をオフラインにすること、マッチングエンジン１２０ｅをシャットダウン／停止／一時停止すること、マッチングエンジン１２０ｅ／サーバ１０５が、そのアイテムに関連付けられたポートでのリスン／受信／送信をもう行わないようにすること等を含んでよい。特に、各アクションは、取引アプリケーション１２２ｅが注文のサブミットをもう行えないようにしてよい。同様に、マッチングエンジン１２０ｅは、取引アプリケーション１２２ｅからサブミットされた注文に対抗する取引コマンドの執行を管理する役割である為、上述の各アクションは、マッチングエンジン１２０ｅがそのようなことをもう行えないようにする。例えば、マッチングエンジン１２０ｅ／サーバ１０５が、そのアイテムに関連付けられたポートでのリスン／受信をもう行わないようにすると、マッチングエンジン１２０ｅは、取引コマンドを受信しなくなる。当業者であれば理解されるように、これらは例に過ぎず、システム１００の他の例示的特徴及び／又は追加の例示的特徴も可能である。

外国為替取引

外国為替（「ＦＸ」）の取引では、市場が複数のユーザで構成されると見なされてよく、それらのユーザのうちの１人以上が流動性プロバイダ（「プロバイダ」）と見なされてよく、それらのユーザのうちの１人以上が流動性テイカー（「テイカー」）と見なされてよい。当業者であれば理解されるように、ユーザは、プロバイダとテイカーの両方であってよい。プロバイダは、ＦＸ商品に対する１つ以上の注文、例えば、ＦＸ商品に対するビッド及び／又はオファーをサブミット又はストリーミングすることにより、１つ以上のＦＸ商品に対する１つ以上の取引に応じてよく、各注文は、例えば、価格及びサイズを有する。各注文は、１人以上のテイカーに対して示されるか使用可能にされてよい。これに対して、テイカーは、買い取引コマンド又は売り取引コマンド、例えば、オファーのテイク又はビッドのヒットをサブミットすることにより、注文に対抗する執行を試みてよい（別の例として、テイカーは、ビッド又はオファー等をサブミットすることにより、注文に対抗する執行を試みてよい）。取引コマンドは、指定された価格及びサイズを含んでよい。取引コマンドのサイズは、対抗する執行がなされる、対応する注文と同じサイズであってよく、或いは、より小さいサイズに対してであってもよい。注文に対抗する取引コマンドがサブミットされると、このコマンドは、注文をサブミットしたプロバイダに送信／ルーティングされてよい。以下では、「セカンドルック」と称されてよいプロセスが行われてよい。セカンドルックに従って、注文がまだ使用可能であれば、その注文に対抗して取引コマンドを執行するよりむしろ、その注文をサブミットしたプロバイダに、取引をまだ行うかどうかを決定するセカンドチャンスを与えられてよい。プロバイダは、取引コマンドを受信したら、「済み（ｄｏｎｅ）」コマンドで応答してよく、これは、例えば、サブミットされた注文に従ってプロバイダが応じた取引に対してプロバイダがまだ取引を行うことを意味する。「済み」コマンドはサイズを含んでよく、これは、取引コマンドのサイズに対応してよく、或いは、より小さいサイズに対してであってもよい。「済み」コマンドの結果として、注文に対抗して取引コマンドが執行されてよく、それによって、対応するプロバイダとテイカーとの間で取引が執行されてよい。別の代替として、プロバイダは、テイカーの取引コマンドに対して「否／中止（ｎｏ／ｎｏｔ ｄｏｎｅ）」コマンドで応答してよく、これは、例えば、注文で指定されたようにプロバイダが応じた取引に対してプロバイダがもう取引を行わないことを意味する。この場合、取引コマンドは注文に対抗して執行されなくてよく、対応するプロバイダとテイカーとの間で取引が執行されなくてよい。第３の代替として、プロバイダは、取引コマンドに対して全く応答しなくてよく、或いは、取引コマンドに（「済み」又は「中止」コマンドで）応答することに時間をかけすぎてよい。ここで、テイカーは、取引コマンドを撤回するか取り消してよい。プロバイダが「済み」コマンドで応答する前に取引コマンドが撤回されたと仮定すると、取引コマンドは、注文に対抗して執行されなくてよく、対応するプロバイダとテイカーとの間で取引が執行されなくてよい。最後の２つのケースでは、テイカーは、まだ取引を執行しようとするのであれば、別の注文に対抗する別の取引コマンドを再度サブミットする必要がある。

本明細書に記載の一例によれば、システム１００は、１つ以上の外国為替（「ＦＸ」）商品の取引に使用されてよい。例えば、本明細書に記載の方法によれば、システム１００上の或るプロバイダ（例えば、ユーザＡ、及び／又はユーザＡの代理で執行する取引アプリケーション１２２ａ）が、ＦＸ商品に対する１つ以上の注文、例えば、ビッド及び／又はオファーをサブミット又はストリーミングすることにより、ＦＸ商品の取引に応じてよく、各注文は、例えば、価格及びサイズを有する。ここで論じられているように、例えば、各注文は、プロバイダのサーバ（例えば、ユーザＡのサーバ１０１）から他の１つ以上のサーバにルーティングされてよい。サーバ、例えば、ユーザＢのサーバ１０２がＦＸ商品に対する注文を受信するように構成されていると仮定すると、対応する、サーバ１０２のマッチングエンジン、例えば、エンジン１２０ｂが、その注文を受信し、それぞれの注文帳１２４ｂに記載してよい。その後、マッチングエンジンは、情報を受信順にユーザＢ／及び／又は取引アプリケーション１２２ｂに転送してよい。ユーザＢ及び／又は取引アプリケーション１２２ｂは、注文を受信したら、例えば、その注文に対抗する取引コマンドをサブミットすることにより、その注文に対抗する執行を試みてよい（それによって、テイカーになってよい）。取引コマンドは、指定された価格及びサイズを含んでよい。ここで論じられているように、例えば、注文に対抗する取引コマンド／注文に対抗してマッチングされているコマンドがサブミットされたら、このコマンドは、サーバ１０１及びマッチングエンジン１２０ａに送信／ルーティングされてよい。セカンドルックに従って、（注文がまだ使用可能であると仮定して）マッチングエンジン１２０ａが注文に対抗する取引コマンドを執行するよりむしろ、マッチングエンジン１２０ａは、最初に取引アプリケーション１２２ａ及び／又はユーザＡと通信して、注文によって指定されるように取引を維持する要求がまだあるかどうかを判定してよい。取引アプリケーション１２２ａ及び／又はユーザＡがまだ注文を維持しようとしていると仮定すると、取引アプリケーション１２２ａ及び／又はユーザＡからマッチングエンジン１２０ａに「済み」コマンドが伝達されてよく、これによって、その後、（例えば、「済み」コマンドで指定されるサイズに対する）注文に対抗する取引コマンドが執行されてよく、その後、ここで論じられているように、確認メッセージ等が生成されてよい。代替として、取引アプリケーション１２２ａ及び／又はユーザＡが注文によって指定されるように取引を維持することをもう行わないと仮定すると、「否／中止」コマンドが、取引アプリケーション１２２ａ及び／又はユーザＡからマッチングエンジン１２０ａに伝達されてよい。そして、そのマッチングエンジン１２０ａが、例えば、ここで論じられているように、注文に対する取り消しメッセージ、及び／又は、取引の未確認を明確に示すメッセージ、及び／又は、取引が失敗したこと、及び／又は、取引が完了しなかったこと等を伝達してよい。別の代替として、取引アプリケーション１２２ａ及び／又はユーザＡが注文によって指定されるように取引を維持することをもう行わないと仮定すると、取引アプリケーション１２２ａ及び／又はユーザＡが、マッチングエンジン１２０ａに対して何もメッセージを伝達しなくてよい。更に別の代替として、ユーザＢ／取引アプリケーション１２２ｂが取引コマンドを撤回してよく、そのような要求を、例えば、マッチングエンジン１２０ｂに伝達してよく、そのマッチングエンジン１２０ｂが、その撤回要求を、例えば、少なくともサーバ１０１及びマッチングエンジン１２０ａに伝達してよく、そのサーバ１０１及びマッチングエンジン１２０ａは、その取引コマンドに関するその後のアクションを無視してよい。当業者であれば理解されるように、外国為替取引に関するシステム１００の上述の動作例は一例であり、他の動作例及び／又は追加の動作例も可能である。

ここで論じられている別の例によれば、例えば、３人のプロバイダ、ユーザＡ、Ｃ、及びＤのそれぞれが、商品の注文を同じ価格でサブミットすると仮定し、例えば、Ａの注文のサイズが１０、Ｃの注文のサイズが５、Ｄの注文のサイズが５であると仮定する。更に、ここで論じられているように、各注文がユーザＢのサーバ１０２にルーティングされ、注文帳１２４ｂに記載されると仮定する。更に、例えば、Ａの注文がＣの注文より時間的に優先され、Ｃの注文がＤの注文より時間的に優先されると仮定する。ユーザＢ及び／又は取引アプリケーション１２２ｂは、注文を受信したら、商品に対する取引コマンドを、それら３つの注文の価格で、且つ、サイズを２０として、サブミットしてよい。ここで論じられている一例によれば、マッチングエンジン１２０ｂは、サイズを５として取引コマンドをサーバ１０１／マッチングエンジン１２０ａに転送してよく（それによって、Ａの注文に対抗して執行してよく）、サイズを１０として別の取引コマンドをサーバ１０３／マッチングエンジン１２０ｃに転送してよく（それによって、Ｃの注文に対抗して執行してよく）、且つ、サイズを５として第３の取引コマンドをサーバ１０４／マッチングエンジン１２０ｄに転送してよい（それによって、Ｄの注文に対抗して執行してよい）。マッチングエンジン１２０ｂは、それら３つの取引コマンドをほぼ同時に転送してよい。例えば、マッチングエンジン１２０ｂは、ユーザＡのサーバ１０１からの確認又は未確認メッセージを待たずに、ユーザＣ及びＤのサーバ１０３及び１０４のそれぞれに取引コマンドを転送してよい。別の例によれば、ユーザＡがサイズを１０未満として「済み」コマンドで応答するか、「中止」コマンドで応答すると仮定すると、サーバ１０２のマッチングエンジン１２０ｂは、そのような応答の通知をサーバ１０１から受信したら、ユーザＣ又はユーザＤに向けて、未充足サイズに対する別の取引コマンドを転送することによって、自動的にユーザＢの取引コマンドに応じたままにしようとしてよい。別の代替として、サーバ１０２のマッチングエンジン１２０ｂは、ユーザＣ及びユーザＤのそれぞれに向けて、未充足サイズのそれぞれの部分に対する別の取引コマンドを転送することによって、自動的にユーザＢの取引コマンドに応じたままにしようとしてよい。別の例として、ユーザＡ、Ｃ、及びＤからの注文に加えて、ユーザＥからサイズ１０に対する別の注文があると仮定する。ここで、マッチングエンジン１２０ｂがユーザＣ及び／又はユーザＤを介してユーザＢの取引コマンドに応じようとすることよりむしろ（或いは、これに加えて）、マッチングエンジン１２０ｂは、ユーザＥに向けて、未充足サイズ又はその一部に対する別の取引コマンドを転送することにより、自動的にユーザＢの取引コマンドに応じようとしてよい。ここでも、当業者であれば理解されるように、上記はシステム１００の一動作例であり、他の変形も可能である。

テイカーの観点からすれば、プロバイダが取引コマンドに「中止」コマンドで応答すること、或いは、プロバイダが取引コマンドに応答することに時間をかけすぎること、或いは、全く応答しないことは望ましいことではない。 これらは、両方とも、テイカーが取引コマンドを撤回することになりかねない。これらのケースでは、結果として、テイカーが所望の取引を執行しないか、テイカーが他の注文に対抗して執行することによって、取引相手となる他のプロバイダを捜し出す為に、そのような取引は時間がかかりすぎる。

一例によれば、或るプロバイダの、「済み」コマンド及び「中止」コマンドの応答、及び／又は応答がないこと、及び／又は応答が遅れたことを評価することによって、そのプロバイダの充足率が算出されてよい。或るプロバイダの充足率は、例えば、プロバイダに対して送信されて、プロバイダが受け入れる能力がある取引コマンドの総数に対する、プロバイダに対して送信されて、プロバイダが受け入れて取引の執行につなげた取引コマンドの数の比率であると見なされてよい。充足率は、例えば、プロバイダに対して送信され、プロバイダが受け入れて取引の執行につなげた取引コマンドの数を測定し、これを、プロバイダに対して送信され、プロバイダが受け入れる能力がある取引コマンドの総数で割ることによって、決定されてよい。結果として得られる値は、０及び１を含む、０から１までの値であってよく、パーセント値で（即ち、１００を乗ぜられて）表されてよい。例えば、１０個の取引コマンドがプロバイダに送信され、プロバイダが１０個全ての取引コマンドに対し「済みコマンド」で応答し、それぞれが取引の執行につながる場合、プロバイダの充足率は１００％ということになる。別の例として、１０個の取引コマンドがプロバイダに送信され、プロバイダが７個の取引コマンドに対して「済み」コマンドで応答し、それぞれが取引の執行につながり、３個の取引コマンドに対して「中止」コマンドで応答する場合、プロバイダの充足率は７０％ということになる。別の例として、１０個の取引コマンドがプロバイダに送信され、プロバイダが３個の取引コマンドに対して「済み」コマンドで応答し、それぞれが取引の執行につながり、４個の取引コマンドに対して「中止」コマンドで応答し、別の１つの取引コマンドに対しては応答せず、別の１つの取引コマンドに対しては「済み」コマンドで応答するものの時間がかかりすぎ、別の１つの取引コマンドに対しては「済み」コマンドで応答するものの、テイカーが撤回コマンドをサブミットした後であった場合、プロバイダの充足率は３０％ということになる（これは、１０個の取引コマンドのうちの３個だけが取引の執行につながる為である）。別の例として、或る注文に対抗する取引コマンドがプロバイダに送信され、その注文がプロバイダによって取り消されるか、且つ／又は、取引コマンドの受信の前に対抗して執行される場合、そのような未執行の取引コマンドは、プロバイダの決定済み充足率に悪影響を及ぼさないと考えられる。当業者であれば理解されるように、充足率は、別の方法で定義及び決定されてもよい。

別の例及び／又は追加の例によれば、充足率は、取引コマンドに対するプロバイダの応答の全履歴が考慮されるように、時間によらず、プロバイダに対して決定及び更新されてよい。別の例及び／又は追加の例によれば、充足率は、指定された継続時間、例えば、指定された時間数、指定された日数等にわたって、プロバイダに対して決定及び更新されてよい。例えば、継続時間は、市場が開いている取引前日であってよい。従って、充足率は、各取引日の最後に、例えば、その日の取引コマンドに対するプロバイダの応答だけを考慮して、決定／更新されてよい。別の例として、継続時間は、最後のｘ時間のような、動いている継続時間にわたって測定されてよい。従って、充足率は、最後のｘ時間の取引コマンドを考慮して、１時間ごとに決定／更新されてよい。当業者であれば理解されるように、充足率は、ここで論じられた方法に対して追加の方法及び／又は異なる方法で定義及び決定されてよい。例えば、プロバイダが、取引コマンドで指定されるサイズより小さいサイズに対して、取引コマンドに「済み」で応答する場合、この不完全な充足は充足率に悪影響を及ぼす可能性があり、言い換えると、充足率が、取引コマンドで指定されるサイズと同じサイズに対して「済み」の応答がなされる場合より小さい値になる可能性がある。所与の市場では、各プロバイダは、それぞれの充足率が同じ方法で決定されてよく、或いは、プロバイダが異なれば、それぞれの充足率の決定方法も異なってよい。当業者であれば理解されるように、他の変形も可能である。

別の例及び／又は追加の例によれば、充足率は、例えば、或る期間での、例えば、或る取引商品についての、充足量と未充足量との比較に基づいて決定されてよい。適切な期間として、履歴期間（例えば、過去２取引週間）があってよく、又、応答時間（例えば、執行要求の数ミリ秒以内に典型的に注文に応じられるパーセンテージ）もあってよい。実施形態によっては、応じられた、又は応じられなかった様々な注文の数が不適切な場合があり、その代わりに、応じられた総量と応じられなかった総量との対比が適切な場合がある。例えば、或る取引者に対して執行の為にルーティングされた特定取引商品の総量の半分にしか、その取引者が応じなかった場合、その取引者は、その取引商品に対する充足率が５０％であると計算されてよい。この例では、応じられた５０％が注文数の８０％を表していたとしても、計算される充足率は５０％であってよい（例えば、これは、応じられた注文の数が応じられなかった注文の数より小さくなる傾向があった場合に、或いは、取引者が様々な注文に部分的に応じた場合に起こりうる）。

別の例及び／又は追加の例によれば、或るプロバイダが、或るインスタンスにおいて、１つ以上の充足率を有してよい。例えば、プロバイダは、プロバイダが取引に応じるＦＸ商品ごとに、１つ以上の決定済み充足率を有してよい。例えば、或るＦＸ商品に対し、取引コマンドのソース（即ち、テイカー）によらず、プロバイダがどのように取引コマンドに応答するかに基づく単一の充足率をプロバイダが有してよい。別の例及び／又は追加の例として、或るＦＸ商品に対し、プロバイダが複数の充足率を有してよく、それぞれが各テイカーに対応し、例えば、そのテイカーからの取引コマンドにプロバイダがどのように応答するかに基づく充足率である。別の例及び／又は追加の例として、或るＦＸ商品に対し、プロバイダが応答する全てのテイカーとは限らない複数のテイカーからの取引コマンドにプロバイダがどのように応答するかに基づく充足率をプロバイダが有してよい。別の例及び／又は追加の例として、プロバイダは、複数のＦＸ商品にまたがって決定される充足率を有してよい。当業者であれば理解されるように、プロバイダが異なれば、決定済み充足率の数も異なることを含め、他の変形も可能である。例えば、各プロバイダは、ソース（即ち、テイカー）によらず、プロバイダがどのように取引コマンドに応答するかに基づく単一の充足率を有してよく、１人以上のプロバイダが、指定されたテイカーに関連付けられた充足率を有してもよい。

別の例及び／又は追加の例によれば、或るプロバイダの充足率は、手動で、且つ／又は電子的に決定されてよい。例えば、システム１００を例として参照すると、サーバ、例えば、サーバ１０１〜１０６のうちのいずれかが、そのサーバに関連付けられたユーザ／取引アプリケーションによって生成された注文を監視してよく、又、そのような注文に対抗する取引コマンドも監視してよい。そのような測定から、サーバは充足率を決定してよい。言い換えると、或るプロバイダに割り当てられた／関連付けられたサーバは、そのプロバイダの充足率を決定してよい。一例として、サーバ上で実行されるアプリケーション、例えば、マッチングエンジン１２０は、そのような測定を実施して充足率を決定してよい。別の例及び／又は追加の例として、サーバ、例えば、サーバ１０１〜１０６のうちのいずれかが、そのサーバに関連付けられたユーザ／取引アプリケーションによって生成された取引コマンドを監視してよく、又、そのような取引コマンドが対抗して発行される注文を監視し、そのような測定から充足率を決定してもよい。言い換えると、或るテイカーに割り当てられた／関連付けられたサーバは、プロバイダの充足率を決定してよい。一例として、サーバ上で実行されるアプリケーション、例えば、マッチングエンジン１２０は、そのような測定を実施して充足率を決定してよい。別の例及び／又は追加の例として、ユーザに関連付けられていない、システム１００のサーバ、例えば、サーバ１５０は、注文、取引コマンド等を監視して、システム１００のプロバイダの充足率を決定してよい。別の例及び／又は追加の例として、システム１００の任意の１つ以上のサーバが、注文、取引コマンド等を監視してよい。その後、例えば、管理者が、システム１００のプロバイダの充足率を手動で決定してよい。当業者であれば理解されるように、充足率は、他の方法及び／又は追加の方法で決定されてよい。

別の例及び／又は追加の例によれば、或るプロバイダの充足率が、システム１００の他のサーバ（言い換えると、或るプロバイダに関連付けられたサーバ以外のサーバ、及び／又は、或るプロバイダに関連付けられたサーバに加えられたサーバ）も使用できるようにされてよい。例えば、システム１００の管理者が充足率を決定する場合、管理者は、そのような充足率を、システム１００の１つ以上のサーバが使用できるように構成してよい。別の例及び／又は追加の例として、システム１００の或るサーバ、例えば、サーバ１５０が充足率を決定する場合、このサーバは、システム１００の１つ以上のサーバに充足率を伝達してよい。別の例及び／又は追加の例として、或るプロバイダに関連付けられたサーバがそのプロバイダの充足率を決定する場合、このサーバは、システム１００の他の１つ以上のサーバに充足率を伝達してよい。一例として、或るプロバイダの充足率は、そのプロバイダが生成する注文に含められてよい。当業者であれば理解されるように、充足率は、他の方法及び／又は追加の方法で伝達されてよい。

別の例及び／又は追加の例によれば、或るプロバイダの複数の充足率が、異なる複数の量に対して決定されてよく、例えば、特定の取引商品に対して決定されてよい。例えば、１００以下、（１０１及び１０００を含む）１０１と１０００の間、（１００１及び５０００を含む）１００１と５０００の間、５００１と１００００の間等の量に対して、充足率が決定されてよい。このことは特に、例えば、プロバイダが小さな量に対して高い充足率を有し、大きな量に対して低い充足率を有する場合に有用である。例えば、或るプロバイダにおいて、１Ｍと２Ｍとの間のユーロダラー量に対して計算された充足率が３０％であって、１００，０００と５００，０００との間のユーロダラー量に対する充足率が８５％であってよい。

別の例及び／又は追加の例によれば、充足率が、取引のどちらの側かに基づいて決定されてよく、例えば、プロバイダが特定のアイテムに対して買い側か売り側かに基づいて決定されてよい。例えば、特定のアイテムの取引において、何人かのプロバイダが、売り手としてよりも買い手として注文に応じる可能性がより高くてよい。従って、プロバイダが買い手（又は売り手）である場合、プロバイダの充足率は、そのプロバイダが買い手（又は売り手）であったときにそのプロバイダによって応じられた注文の数（又は量等）と、そのプロバイダが買い手（又は売り手）であったときにそのプロバイダによって応じられなかった注文の数（又は量）との対比に基づいて計算されてよい。

別の例及び／又は追加の例によれば、充足率がスプレッドに基づいて決定されてよく、例えば、全米最良気配（ｎａｔｉｏｎａｌ ｂｅｓｔ ｂｉｄ ａｎｄ ｏｆｆｅｒ）（ＮＢＢＯ）の価格間のスプレッドに基づいて決定されてよい。例えば、何人かの取引者が、スプレッドが特定の閾値又は範囲を満たす場合に注文に応じる可能性がより高くてよく、それは、例えば、スプレッドが１ドルより小さい場合、或いはスプレッドがその平均スプレッドより小さい場合、或いはスプレッドが、取引日の開始からの取引商品の平均スプレッドの下側の１標準偏差より小さい場合、或いはスプレッドが、０．１０ドルより大きく（且つ／又は０．１０ドルに等しく）、且つ、０．２０ドルより小さい（且つ／又は０．２０ドルに等しい）場合である。従って、特定のプロバイダの充足率は、充足率の計算の対象であるアイテムに対する現在のスプレッドに依存してよい。

実施形態によっては、充足率は、本明細書に記載の様々な要因に基づいて決定されてよく、そのような要因として、例えば、全ての取引商品の総量の、応じられたものと応じられなかったものとの対比、特定の取引商品の総量の、応じられたものと応じられなかったものとの対比、全てのソースからの注文の総数の、応じられたものと応じられなかったものとの対比、特定の取引商品に対する注文の数の、応じられたものと応じられなかったものとの対比、特定の注文と同じ量及び範囲の注文の数の、応じられたものと応じられなかったものとの対比等がある。例えば、充足率（例えば、正味充足率）は、ここで論じられているように計算された２つ以上の充足率値の単純平均又は重み付き平均として計算されてよい。例えば、特定の取引者の注文帳にある、特定の取引商品に対する特定の取引者の注文を注文することに使用されてよい、或るプロバイダについて計算される充足率は、（１）全てのパーティについての全ての取引商品を考慮した、そのプロバイダの計算された総充足率、（２）その特定の取引者に対抗する全ての取引商品についての、そのプロバイダの計算された充足率、及び（３）特定の取引商品についての、その特定の取引者に対抗する、そのプロバイダの計算された充足率の平均として計算されてよい。

実施形態によっては、充足率は、応答時間に少なくとも部分的に基づいて決定されてよい。例えば、プロバイダが、応答時間が異なれば充足率も異なるように決定されてよい。例えば、プロバイダが、典型的には、１０ミリ秒以内であれば平均的注文の７０％に応じ、２０ミリ秒以内であれば平均的注文の８５％に応じるように計算されてよい。

実施形態によっては、充足率は、単位時間あたりの応じる確率として表されてよく、これは、（本明細書の様々な例において計算されるような）充足率と応答時間との両方を反映する。

別の例及び／又は追加の例によれば、プロバイダの充足率がサーバに伝達され、サーバで使用可能にされると、充足率は、例えば、そのサーバのマッチングエンジンに通知されてよいが、そのサーバの取引アプリケーション及び／又はユーザには通知されなくてよい。別の例及び／又は追加の例によれば、充足率は、サーバの取引アプリケーション及び／又はユーザに通知されてよい。別の例及び／又は追加の例によれば、受信された注文がマッチングエンジンによってそれぞれの取引アプリケーション／ユーザに伝達される場合、その注文を生成したプロバイダの充足率も、取引アプリケーション／ユーザに伝達されてよい。

これも当業者であれば理解されるように、ここで規定される充足率の決定及びその使用は、システム１００のような分散アーキテクチャに限定されない。例えば、充足率の使用は、集中型注文帳にも当てはまってよい。ここで、例えば、集中型取引システム（例えば、注文帳及び注文の受信を管理し、そのような注文に対抗する取引コマンドの執行を管理する中央サーバ）が、プロバイダの充足率を決定してよい。そのようなサーバは、エンドユーザが使用するコンピュータシステムに充足率を伝達してもよい。

別の例によれば、例えば、３人のプロバイダ、ユーザＡ、Ｃ、及びＤのそれぞれが、商品の注文を同じ価格でサブミットすると仮定し、例えば、Ａの注文のサイズが１０、Ｃの注文のサイズが５、Ｄの注文のサイズが５であると仮定する。更に、ここで論じられているように、各注文がユーザＢのサーバ１０２にルーティングされ、注文帳１２４ｂに記載されると仮定する。更に、例えば、Ａの注文がＣの注文より時間的に優先され、Ｃの注文がＤの注文より時間的に優先されると仮定する。更に又、ユーザＡの充足率が７０％であり、ユーザＣの充足率が８０％であり、ユーザＤの充足率が９０％であると仮定する。ユーザＢ及び／又は取引アプリケーション１２２ｂは、注文を受信したら、商品に対する取引コマンドを、それら３つの注文の価格で、且つ、サイズを１０として、サブミットしてよい。一例によれば、マッチングエンジン１２０ｂは、注文帳１２４ｂにおいて、価格と、次に、注文が市場にサブミットされる時間とに基づいて、ユーザＡ、Ｃ、及びＤの注文に優先順位を付けてよい。従って、ユーザＡの注文はユーザＣの注文より優先されてよく、ユーザＣの注文はユーザＤの注文より優先されてよい。ここで、マッチングエンジン１２０ｂは、ユーザＢからの取引コマンドに応答して、取引コマンドを、サイズを１０として、サーバ１０１／マッチングエンジン１２０ａに転送してよい（これによってＡの注文に対抗する執行がなされてよい）。これは、ユーザＡの注文が最高優先度を有する為である。別の例によれば、マッチングエンジン１２０ｂは、注文帳１２４ｂにおいて、価格と、次に、充足率とに基づいて、ユーザＡ、Ｃ、及びＤの注文に優先順位を付けてよい（即ち、２つ以上の注文が同じ価格と関連付けられた充足率とを有さない限り、時間には基づかない）。従って、ユーザＤの注文はユーザＣの注文より優先されてよく、ユーザＣの注文はユーザＡの注文より優先されてよい。ここで、マッチングエンジン１２０ｂは、ユーザＢからの取引コマンドに応答して、取引コマンドを、サイズを５として、サーバ１０４／マッチングエンジン１２０ｄに転送してよい（これによってＤの注文に対抗する執行がなされてよい）。これは、ユーザＤの注文が最高優先度を有する為である。更に、マッチングエンジン１２０ｂは、ユーザＤとの取引コマンドの残りサイズの５に応じようとしてもよい。代替として、マッチングエンジン１２０ｂは、取引コマンドを、残りサイズを５として、サーバ１０３／マッチングエンジン１２０ｃに転送してもよい（これによってＣの注文に対抗する執行がなされてよい）。これは、ユーザＣの注文が、（例えば、注文帳において）次に高い優先度を有する為である。ここでも当業者であれば理解されるように、上記はシステム１００の一動作例であり、他の変形も可能である。

別の例によれば、例えば、３人のプロバイダ、ユーザＡ、Ｃ、及びＤのそれぞれが、商品の注文を異なる価格でサブミットすると仮定し、例えば、Ａの注文の価格がＣの注文の価格より優位であり、Ｃの注文の価格がＤの注文の価格より優位であると仮定する（優位である、とは、例えば、ビッドの場合には価格がより高いことを意味し、オファーの場合には価格がより低いことを意味する）。更に、ここで論じられているように、各注文がユーザＢのサーバ１０２にルーティングされ、注文帳１２４ｂに記載されると仮定する。更に、例えば、Ａの注文がＣの注文より時間的に優先され、Ｃの注文がＤの注文より時間的に優先されると仮定する。更に又、ユーザＡの充足率が７０％であり、ユーザＣの充足率が８０％であり、ユーザＤの充足率が９０％であると仮定する。一例によれば、マッチングエンジン１２０ｂは、注文帳１２４ｂにおいて、充足率と、次に、価格とに基づいて、ユーザＡ、Ｃ、及びＤの注文に優先順位を付けてよい（ここでも、時間は、２つ以上の注文の充足率が同じである場合に追加の要因として使用されてよい）。従って、ユーザＤの注文はユーザＣの注文より優先されてよく、ユーザＣの注文はユーザＡの注文より優先されてよい。この例によれば、ユーザＢ及び／又は取引アプリケーション１２２ｂは、取引コマンドが応じられる価格よりも、取引コマンドが応じられることにより関心があってよい。従って、ユーザＢ及び／又は取引アプリケーション１２２ｂが、注文を発したプロバイダのそれぞれの充足率を認識していない場合でも、或る注文が、異なる価格の別の注文より優先されていることがわかっていれば、ユーザは、価格に対して優位な充足率であるとユーザが見なすものを選択することが可能であってよい。

別の例及び／又は追加の例によれば、注文は、価格及び充足率の重み付き平均に従って注文されてよい。例えば、実施形態によっては、或る注文が、価格が０．０９ドル劣位であって充足率が５％優位である注文より優先して注文されるように、充足率の５％の差に、０．１０ドルの価格差と同じ重みが付けられてよい。応答時間は、重み付きで考慮されてもよい。実施形態によっては、特定の取引者が、例えば特定の取引商品について、その特定の取引者の注文帳において、充足率、応答時間、価格などの様々な要因の重み付けを指定してよい。例えば、ユーザは、価格差に等しい充足率のパーセンテージを指定してよく、例えば、応答時間に等しい充足率のパーセンテージを指定してよい。例えば、特定の取引者の注文帳を注文する目的で、その特定の取引者は、１価格単位（即ち、特定の取引者にとって１単位だけ優位である価格）が、充足率の３％の改善、及び応答時間の２．５ミリ秒の改善に等しいように指定してよい。この例では、第１の売り注文の価格が１２．２５ドルであり、関連付けられた充足率が８０％であり、関連付けられた応答時間が１３ミリ秒であり、第２の売り注文の価格が１２．２６ドル（１２．２５ドルより１単位だけ劣位）であり、関連付けられた充足率が８６％であり、関連付けられた応答時間が１５．５ミリ秒であると、第１の売り注文と第２の売り注文は優先度が等しいと見なされてよく、これらの注文は両方とも、価格が１２．２５ドルであり、応答時間が８０％であり、応答時間が１５．５ミリ秒である第３の注文より優先して注文されてよい。

別の例及び／又は追加の例によれば、システム１００の１人以上のユーザが、そのユーザが取引コマンドのサブミット時に達成したい最小充足率に対応する規定閾値を有してよい。言い換えると、システム１００の或るユーザがテイカーとして働く場合には、そのユーザは、取引コマンドのサブミット時に達成したい最小充足率を規定してよい。或るユーザが、取引を望む全ての金融商品に適用される単一の閾値を有してよい。別の例として、或るユーザが、取引を望む各商品にそれぞれが対応する複数の閾値を有してよい。ユーザが異なれば、各ユーザが有する規定閾値も異なってよく、規定閾値の数も異なってよい。一例によれば、システム１００のユーザ／取引アプリケーション／管理者が、ユーザの閾値を使用して、そのユーザに関連付けられたそれぞれのサーバを構成してよく、例えば、閾値を有する、それぞれのマッチングエンジンを構成してよい。別の例及び／又は追加の例によれば、ユーザ／取引アプリケーションがそれぞれのマッチングエンジンに取引コマンドをサブミットする場合、注文は閾値を含んでよい。例えば、ユーザＢ及び／又は取引アプリケーション１２２ｂが、或る注文に対抗する取引コマンドをそのマッチングエンジン１２０ｂにサブミットする場合、この取引コマンドは閾値を含んでよい。当業者であれば理解されるように、他の変形も可能である。

実施形態によっては、充足率が高いほど、関連して、価格が劣位になり、スプレッドが高くなる可能性があり、これは、カウンタパーティが一般に、自身にとってより好ましい価格で注文に応じる可能性がより高い為である。（例えば、或る取引商品に対する現在の最良のビッド／オファーが５．００ドル／５．５０ドルである場合、或る取引者は４．７５ドルよりも５．５０ドルでビッドに応じる可能性がより高く、或る取引者は５．５０ドルよりも５．７５ドルでオファーに応じる可能性がより高い。）従って、ユーザが最小充足率を指定することを可能にすることにより、様々な実施形態が、ユーザが充足率と価格との間のトレードオフを表現することを可能にする。例えば、ユーザは、高い充足率を、しかしながら典型的には、より劣位の価格で指定してよく、或いは、より低い充足率を、典型的には、より優位の価格で指定してよい。

図２及び図３は、幾つかの実施形態による、平均スプレッドと推定充足率との関係を示す例示的グラフである。図２は、取引注文サイズが１，０００，０００に等しい場合の例示的グラフを示す。図３は、取引注文サイズが５，０００，０００である場合の例示的グラフを示す。例示的モデルＡ及び例示的シフトブックの両方についてのこれらのグラフに示されるように、推定充足率は平均スプレッドと共に増加する傾向がある。図２及び図３の例示的グラフは又、グラフ化されたデータセットについての、これらの変数間の非線形関係も示しており、例えば、推定充足率は、スプレッドが低いところでは、スプレッドが高いところよりも急激に増加する。

別の例及び／又は追加の例によれば、テイカー（例えば、ユーザＢ及び／又は取引アプリケーション１２２ｂ）が、プロバイダ（例えば、ユーザＡ及び／又は取引アプリケーション１２２ａ）からサブミットされた、テイカーの注文帳１２４ｂにある注文に対抗する取引コマンドをサブミットすると、マッチングエンジン１２０ｂは、例えば、ユーザＢの規定閾値をユーザＡの決定済み充足率と比較し、ユーザＡの充足率がユーザＢの閾値より大きい場合（又はユーザＢの閾値以上の場合）のみ、その注文に対抗する取引コマンドの潜在的執行の為に、取引コマンドをユーザＡのサーバ１０１に伝達してよい。そうでない場合、マッチングエンジン１２０ｂは、その注文に対抗する取引コマンドを執行しようとしなくてよい。別の例及び／又は追加の例によれば、注文帳１２４ｂに、例えば、２つの注文が記載されていて、それぞれが別々のプロバイダからであり、それぞれが同じ価格であり、例えば、市場にサブミットされた時点に基づいて、第１の注文が第２の注文より優先されていると仮定する。ここで、マッチングエンジン１２０ｂは、ユーザＢ及び／又は取引アプリケーション１２０ｂから取引コマンドを受信した時点で、まず、ユーザＢの規定閾値を、第１の注文をサブミットしたプロバイダの決定済み充足率と比較し、充足率がユーザＢの閾値より大きい場合（又はユーザＢの閾値以上の場合）のみ、その注文に対抗する取引コマンドの潜在的執行の為に、取引コマンドをそのプロバイダのサーバに伝達してよい。そうでない場合、マッチングエンジン１２０ｂは、第１の注文を飛ばし／無視し、ユーザＢの規定閾値を、第２の注文をサブミットしたプロバイダの決定済み充足率と比較してよい。ここでも、マッチングエンジン１２０ｂは、充足率がユーザＢの閾値より大きい場合（又はユーザＢの閾値以上の場合）のみ、第２の注文をサブミットしたプロバイダのサーバに、取引コマンドを潜在的執行の為に伝達してよい。より一般的には、マッチングエンジン１２０ｂは、ユーザＢ及び／又は取引アプリケーション１２０ｂから取引コマンドを受信した時点で、注文帳１２４ｂにある注文の充足率が、例えば、ユーザＢの規定閾値より小さい場合には、それらの注文を飛ばして／無視してよい。ここでも、充足率をこのように使用することは、集中型取引システムにも適用されてよい。当業者であれば理解されるように、充足率をこのように使用することは、注文帳が価格、充足率の順で優先順位付けされるか、充足率、価格の順で優先順位付けされている場合にも適用されてよい。

別の例及び／又は追加の例によれば、或るプロバイダがシステム１００に注文をサブミットし、その注文が他の複数のサーバ、及びそれらのサーバのそれぞれのマッチングエンジンに伝達された場合、マッチングエンジンによっては、その注文をそれぞれの注文帳に自動的に記載しなくてよい。例えば、ユーザＡ及び／又は取引アプリケーション１２２ａがシステム１００に注文をサブミットし、その注文がユーザＢのサーバ１０２において受信されたと仮定する。マッチングエンジン１２０ｂは、その注文を受信したら、ユーザＢの規定閾値を、ユーザＡの決定済み充足率と比較してよい。この充足率がユーザＢの閾値より大きい場合（又はユーザＢの閾値以上の場合）に、マッチングエンジンは、その注文を注文帳１２４ｂに記載してよい（場合によっては、その注文に関する情報をユーザ及び／又は取引アプリケーション１２２ｂに転送してよい）。代替として、充足率がユーザＢの閾値より小さい場合（又はユーザＢの閾値以下の場合）、マッチングエンジンは、その注文を注文帳１２４ｂに記載しなくてよい（そして、その注文に関する情報をユーザＢ及び／又は取引アプリケーション１２２ｂに転送しなくてよい）。このように、ユーザＢ／取引アプリケーション１２４ｂは、或る一定の閾値を満たす関連付けられた充足率を有する注文のみが与えられる（そして、それによって、その注文に対抗する取引を行う機会を有する）。ユーザからは、そのユーザの規定閾値を満たさない関連付けられた充足率を有する注文が見えない（従って、そのユーザは、その注文に対抗する取引を行う機会を有しない）。更に、この例によれば、システム１００における別々のユーザが、異なる閾値を有してよく、且つ／又は、それぞれのプロバイダごとに異なる充足率を使用してよい為、或る商品に対する、各サーバにおける注文帳は異なってよい（即ち、市場の現在の表現が異なってよい）。当業者であれば理解されるように、充足率をこのように使用することは、注文帳が価格、充足率の順で優先順位付けされるか、充足率、価格の順で優先順位付けされている場合にも適用されてよい。

別の例及び／又は追加の例によれば、注文帳が、応答時間に少なくとも部分的に基づいて注文されてよい。応答時間は、応じる応答又は応じない応答を受信するのに（例えば、平均的に）かかる時間を含んでよい。応答時間は、システム構成要素間、時刻間、ユーザ間等でばらついてよい。例えば、システムにおいて互いに非常に近接する２つのノードが、非常に小さい応答時間を有してよく、ノード同士が離れていれば応答時間が長くなってよい。又、応答時間は、ネットワークトラフィックが重い時間帯には長くなる可能性がある。いずれにせよ、応じるメッセージ及び応じないメッセージの応答時間は、追跡及び測定されてよい。充足率と同様に、応答時間は、様々な時間帯及び状況に対して測定されてよい。具体的には、応答時間は、特定のメッセージ経路について計算されてよく（例えば、プロバイダ＃２が（例えば、過去３取引日にわたって）取引者＃３に応答する応答時間）、又、特定の取引エンティティについて計算されてもよい（例えば、プロバイダ＃２から他の全ての取引エンティティへの、全ての応じるメッセージ及び応じないメッセージにわたる平均応答時間）。

場合によっては、応答時間が長ければ（例えば、１００ミリ秒）、取引者が単一のプロバイダから単一の応答を取得することが期待できる時間に、応答時間が短ければ（例えば、０．１〜１ミリ秒）、取引者は、複数のプロバイダから複数の応答を受信することを期待できる。例えば、１０００単位の注文に応じようとする取引者は、その取引者の注文帳に以下の反対注文を有してよい。（１）プロバイダ＃１の注文。量は１０００。応答時間は１ミリ秒。充足率は４０％。（２）プロバイダ＃２の注文。量は１２００。応答時間は５ミリ秒。充足率は５０％。（３）プロバイダ＃３の注文。量は１２００。応答時間は１０ミリ秒。充足率は６０％。及び、（４）プロバイダ＃３の注文。量は２０００。応答時間は４０ミリ秒。充足率は９０％。特に、取引者は、応じる応答又は応じない応答をプロバイダ＃１から、（注文が＃１によって完全には応じられなかった場合には）プロバイダ＃２から、（注文が＃１及び＃２によって完全には応じられなかった場合には）プロバイダ＃３から取得することが可能であり、これら全てが順々に、プロバイダ＃４から応答を取得するのにかかるであろう時間より短い時間（１６ミリ秒）で可能である。注文＃４が最良の充足率を有しうる間に、取引者は、注文を（必要に応じて）プロバイダ＃１、＃２、及び／又は＃３に送信することによって、注文に（しかも、より迅速に）応じる可能性がより高い。

実施形態によっては、或る注文が同じプロバイダに複数回ルーティングされてよい。例えば、或る注文がプロバイダ＃１に複数回ルーティングされてから、プロバイダ＃４からの応答が受信されてよい。プロバイダ＃１への１回のルーティングに対して応じる確率は４０％と計算されうる一方、プロバイダ＃１への５回の注文のルーティングに対して応じる確率は、４０％より著しく高い可能性がある。そのような確率の１つの計算は、（プロバイダ＃１への５回のルーティングの後の）応じる確率＝１−（１−０．４）＾５＝９２．２２４％であってよく、これは、１回のルーティングの後のプロバイダ＃４が応じる確率より高い。しかしながら、複数回のルーティングの後の応じる確率は、このようには増加しない可能性があり、それは、同じプロバイダへの個々のルーティングが数学的に独立した事象ではない可能性がある為である。逆に、プロバイダが応じる確率は、そのようなプロバイダが注文に応じないたびに減少する可能性がある。これらの値も追跡及び測定されてよい。例えば、充足率が５０％であるプロバイダが、以前にそのプロバイダにルーティングされて応じられなかった注文に対して３０％の充足率を有するであろうこと、並びに、そのプロバイダが２回拒否した注文に対して１０％の充足率を有するであろうことが決定されてよい。いずれにせよ、何回かのルーティングの後の全体充足率が、１回のルーティングの場合の充足率より高くなることが決定されてよい。

従って、実施形態によっては、充足率を高くする為には（且つ／又は、価格を多少優位にする為には、或いは、量を多少増やす為には）、応答時間を減らすことが好ましい場合がある。

別の例及び／又は追加の例によれば、（例えば、流動性プロバイダによる）拒否率（例えば、プロバイダが或る注文又は注文のタイプを拒否する率。ある意味で充足率の逆）同士に高い相関性があってよい。例えば、複数の流動性プロバイダからの注文の後ろに単一の注文があってよい。例えば、ユーザＡが１０００単位を買おうとする場合、流動性プロバイダ＃１、＃２、及び＃３の全員が、それらの単位を取得してユーザＡに得る為に、１０００単位に対する売り注文を出してよい。注文帳は１０００単位に対する３つの別々の注文を反映してよいが（これは総量が３０００単位であるように見える）、実際に必要なのは１０００単位だけである。或る流動性プロバイダが１０００単位を取得してユーザＡの買い注文を満たした場合、他の流動性プロバイダからの、１０００単位に対する他の売り注文は消滅する可能性が高い。この例では、取引者＃１が２０００単位を買おうとしてよく、取引者＃１の注文帳には、流動性プロバイダ＃１、＃２、及び＃３からの１０００単位の注文が７５％、８０％、及び９０％の充足率で示されてよい。このシナリオでは、取引者＃１は、１０００単位の取引をプロバイダ＃３と行ってよく、その後、プロバイダ＃１及びプロバイダ＃２が取引者の残り１０００個の注文に応じないことが判明してよい。この場合、プロバイダ＃１及び＃２の充足率は相関性が高くなる。

従って、実施形態によっては、２つ（以上）の注文が独立か非独立かの確率が、例えば、履歴取引情報（例えば、１つの対応する注文が（例えば一定期間内に）応じられた後に、例えば、全て又は一部の注文を取り消す２つのパーティの間の相関）、量の類似性、及び時間の類似性（例えば、同時又はほぼ同時に入力されたこと）などに基づいて決定されてよい。例えば、プロバイダＡ及びＢからのよく似た２つの注文（例えば、それらの注文が同じ又はほぼ同じ価格及び量であって、例えば、同時又はほぼ同時に入力されたという理由でよく似ている注文）が、同じ商品に対するよく似た注文がプロバイダＡ及びＢから入力されたという最後の４つのインスタンスのうちの３つにおいて、それらの注文のうちの１つが、応じられている他の注文から３ミリ秒以内に取り消された場合には、重複である可能性が高いと判定される可能性がある。

実施形態によっては、拒否率は、示されたサイズの関数であってよい。例えば、プロバイダらが示す同じ注文量が多いほど、それらの拒否率同士が相関する可能性が高くなる。（例えば、これは、それらの注文が、サードパーティからの同じ潜在量に基づいていて、同じ潜在注文の重複量を反映している為であってよい）。実施形態によっては、拒否率は、微細構造の関数であってよい。充足率及び拒否率の相関は、追跡及び測定されてよい。

実施形態によっては、２つ以上の注文の間の流動依存性は、例えば、充足率及び拒否率の相関に基づいて推定されてよい。例えば、サーバは、２つ（以上）の注文が互いに独立であるか、互いに（全体又は一部が）重複している可能性の高さを判定、計算、又は他の方法で推定してよい。例えば、システムは、完全に異なる流動性を有する２つの注文が独立である可能性が高く、従って、一方の注文に応じることが他方において利用可能な量に影響せず、従って、両方の注文が（例えば、それらの全量において）ヒットすることが可能であると判定してよい。システムは、別の３つの注文が少なくとも部分的に、互いに重複している可能性が高く、従って、いずれかのパーティが３つの注文全てに、それらの全量においてヒットしうる可能性が低いと判定してよい。例えば、システムは、３つの注文が８０％重複しており、従って、１つの注文が応じられた後に、他の２つの注文が、それぞれの量のうちのまだ取引可能な２０％を有するのみになると判定してよい。実施形態によっては、流動依存性を推定する為に、ルータが各カウンタパーティ間のリンク状態を検出してよい。実施形態によっては、システムは、流動非依存性を推定する為にグレンジャー因果関係を検出してよい。

図４は、本発明の様々な実施形態による一例示的フローチャートを示す。

ブロック４０５では、取引者が、量及び価格を含む取引商品に対する注文を受信してよい。これらの注文は、買い取引／売り取引の特定の側を含んでよく、例えば、ビッド（又はオファー）を含んでよい。各注文は量を含んでよい。幾つかの注文は、他の注文より先に受信されてよい。

ブロック４１０では、注文、及び注文のプロバイダに関する情報が決定されてよく、例えば、充足率、応答時間、流動非依存性（又は依存性）、及び他の条件が決定されてよい。当然のことながら、ブロック２１０で決定される情報は、いかなる特定の時点でも、或いは、フローチャート内の他のブロックから見た相対的な、いかなる特定の時点でも、決定されなくてよい。

ブロック４１５では、取引者は、注文に関連する情報を受信してよく、例えば、ブロック２１０で決定された情報を受信してよい。この情報は、充足率、応答時間、流動非依存性（又は依存性）に関する情報、及び他の情報を含んでよい。

ブロック４２０では、取引者は、取引者プレファレンスをサブミットするよう促されてよく、例えば、閾値充足率、閾値応答時間、最小ボリューム要件、及び／又は他の取引条件をサブミットするよう促されてよい。取引者は、条件及び／又はユーザプレファレンスを入力してよく、例えば、（例えば、特定の取引商品に関する）目標充足率、閾値応答時間、最小ボリューム要件、及び／又は他の取引条件を入力してよい。例えば、ユーザは、最小ボリューム要件として１０００単位、最小充足率として７０％、最大期待応答時間として２０ミリ秒を指定してよい。

ブロック４２５では、取引者は取引コマンドを入力してよく、例えば、取引商品に対する、或る量の注文に、例えば、指定された価格で（又は最良の価格で）応じる為に、取引コマンドを入力してよい。取引コマンドは、目標充足率、最小ボリューム要件などの条件に関連付けられてよい。取引コマンドは、注文帳及び条件に従って注文に応じることの指示であると解釈されてよく、例えば、条件に基づく（例えば、条件を満たす）取引者の注文帳にある逆注文に対抗する、取引者の注文仕様に応じることによって、注文に応じることの指示であると解釈されてよい。例えば、このコマンドは、最小時間で、良好な（又は最良の）価格で、様々な条件を満たす逆注文に対抗して、注文に応じることの指示であると解釈されてよい。

ブロック４３０では、取引者からの１つ以上の注文指示（例えば、執行要求）が、（例えば、取引者の注文帳及び条件に従って）注文の１人以上のプロバイダにルーティングされてよい。例えば、注文帳の先頭にある１つ以上の注文を執行することの指示が、それらの注文のプロバイダにルーティングされてよい。それらの注文は、それらの価格、量、充足率、応答時間、流動非依存性、及び／又は他の要因に基づいて選択されてよい。プロバイダのうちの１人以上に、要求された注文に応じるかどうかを決定する為の「セカンドルック」が与えられてよい。

ブロック４３５では、取引者の注文帳に記載された１つ以上の注文が執行されてよく、例えば、１人以上の流動性プロバイダによって執行されてよい。執行に関する情報が、取引者にルーティングされてよく、取引者の注文帳（及びその中での注文）は、取引を反映するように更新されてよい。例えば、注文帳の先頭付近にある応じられない注文が、注文帳の最後部に移動させられてよく、これは、（例えば、ブロック４３０で）応じられた流動性が、応じられない注文の量だけ重複している可能性が高く、これは、応じられない注文が対抗して執行される可能性が低くなることを意味する、という判定に基づいて行われてよい。

ブロック４４０では、取引者の所望の量の一部が応じられないままである場合、１つ以上の注文指示（例えば、執行要求）が、取引者の更新された注文帳及び条件に従って、それらの注文の１人以上のプロバイダにルーティングされてよい。更新された注文帳に記載されている注文のうちの１つ以上が、それに対する応答として執行されてよい。

ブロック４４５では、応じること、応じないこと、及び応答時間に関する情報が追跡されてよい。そのような情報は、充足率、応答時間、及び他の、注文帳及びルーティングに関連する情報の推定値を決定及び更新する為に使用されてよい。

特定の実施形態及び一般的に関連付けられる方法の観点から本開示を説明してきたが、これらの実施形態及び方法の変更及び置換は、当業者であれば明らかであろう。例えば、当然のことながら、ＦＸ商品に関連して様々な特徴が説明されているが、そのような特徴は、他の商品及び取引商品（例えば、株式、債券、小売商品、及び他の商品及びサービス）にも当てはまってよい。従って、上述の、例示的実施形態の説明は、本開示を限定しない。他の変更、置換、及び改変も、本開示の趣旨及び範囲から逸脱しない限り、可能である。

以下の項は、本明細書を解釈する上での指針を提供する。

Ｉ．用語
「製品」という用語は、その他特に明示的に記載のない限り、マシン、製造、および／または物の組成を意味する。

「プロセス」という用語は、その他特に明示的に記載のない限り、プロセス、アルゴリズム、方法等を意味する。

各プロセス（方法、アルゴリズム、または他で呼ばれるかに関わらず）は本質的に、１つ以上のステップを含み、したがって、プロセスの「ステップ」（単数または複数）へのあらゆる参照は、プロセスの単なる説明、または「プロセス」等の用語の単なる記述において本質的な先行根拠を有する。したがって、請求項におけるプロセスの「ステップ」（単数または複数）への参照は、十分な先行根拠を有する。

「発明」等の用語は、その他特に明示的に記載のない限り、「本明細書において開示される１つ以上の発明」を意味する。

「ある実施形態」、「実施形態」、「実施形態（複数）」、「該実施形態」、「該実施形態（複数）」、「１つ以上の実施形態」、「いくつかの実施形態」、「所定の実施形態」、「一実施形態」、「別の実施形態」等の用語は、その他特に明示的に記載のない限り、「発明の１つ以上の（しかし全てではない）実施形態」を意味する。

本発明の「変形」という用語は、その他特に明示的に記載のない限り、本発明の実施形態を意味する。

「指標」という用語は、極めて広い意味で使用される。事柄の「指標」は、事柄を決定するために使用され得る任意のものを含むことを理解されたい。

事柄の指標は、事柄を特定する電子メッセージを含んでもよい（例えば、ウィジェットに取り付けられたシリアル番号によるウィジェットの特定、ウィジェットの１つ以上の特性によるウィジェットの特定）。事柄の指標は、事柄を計算および／または参照するために使用され得る情報を含み得る（例えば、ウィジェットが、ウィジェットを決定するために使用され得る一部であるマシンを特定する情報）。事柄の指標は、事柄に関連する事柄を指定し得る（例えば、事柄の特性、事柄の名称、事柄に関連する事柄の名称）。事柄の指標は、事柄に関連する事柄を指定しない場合がある（例えば、「ある（ａ）」という文字は、文字「ある（ａ）」を解釈してウィジェットを特定するように構成されるコンピュータシステムのウィジェットの指標であり得る）。事柄の指標は、事柄のサイン、兆し、および／またはトークンを含み得る。指標は、例えば、コード、参照、実施例、リンク、信号、および／または識別子を含み得る。事柄の指標は、事柄を表し、説明し、および／またはその他特に事柄に関連付けられた情報を含み得る。

事柄の指標の変換は、事柄の指標であり得る（例えば、事柄の暗号化された指標は、事柄の指標であり得る）。事柄の指標は、事柄それ自体、事柄のコピー、および／または事柄の一部を含み得る。事柄の指標は、指標を理解するように構成されない事柄に対して無意味なものである場合がある（例えば、ある人は、文字「ある（ａ）」がウィジェットを示すが、コンピュータシステムが文字「ある（ａ）」からウィジェットと判定し得るため、それがそれでもなおウィジェットの指標であり得ることを理解しない場合がある）。事柄の指標は、事柄が、事柄または任意のものが決定されることを意味しないと決定するように使用され得る事実を理解されたい。事柄の指標は、その他特に指定されない限り、事柄の任意の数の指標を含み得る。事柄の指標は、他の事柄の指標（例えば、多くの事柄を示す電子メッセージ）を含んでもよい。（指標は、特許請求の範囲の言語において非常に広い用語として使用され得る。例えば、金融商品の指標を受信すること。）

「表す」という用語は、（１）単語、記号、同様のものが行うように、表現する、指定する、表象する、または示すように機能すること、（２）いくつかの用語、文字、記号、同様のものによって表現するまたは指定すること、（３）写真が行うように、そのものを描く、または描写、または提示すること、または（４）サインまたは記号そのものとして機能すること、を意味する。

実施形態を説明する際の「別の実施形態」への参照は、その他特に明示的に記載のない限り、参照された実施形態が別の実施形態（例えば、参照された実施形態の前に記載された実施形態）と相互に排他的であることを暗示しない。同様に、２つ（以上）の実施形態が参照されるという単なる事実は、これらの実施形態が相互に排他的であることを暗示しない。

本発明の一実施形態は、本発明の２つ以上の他の実施形態を含み得るかまたは網羅し得るかまたは包括し得る。例えば、要素ａ、ｂ、およびｃを含む第１の実施形態は、要素ａ、ｂ、ｃ、およびｄを含む第２の実施形態、ならびに要素ａ、ｂ、ｃ、およびｅを網羅する第３の実施形態を網羅し得る。同様に、第１、第２、および第３の実施形態の各々は、要素ａ、ｂ、ｃ、ｄ、およびｅを含む第４の実施形態を網羅し得る。

「含む」、「備える」という用語およびそれらの変形は、その他特に明示的に記載のない限り、「含むが、必ずしも限定されない」ことを意味する。このため、例えば、「マシンは、赤いウィジェットおよび青いウィジェットを含む」という文は、マシンが赤いウィジェットおよび青いウィジェットを含むが、可能性として１つ以上の他のアイテムも同様に含み得ることを意味する。

「〜からなる」という用語およびその変形は、その他特に明示的に記載のない限り、「〜を含み、かつまた〜に限定される」ことを意味する。このため、例えば、「マシンは、赤いウィジェットおよび青いウィジェットからなる」という文は、マシンが赤いウィジェットおよび青いウィジェットを含むが、その他には何も含まないことを意味する。

「構成する」という用語およびその変形は、その他特に明示的に記載のない限り、「その成分、その構成部分、またはその要素を作り上げる」ことを意味する。このため、例えば、「赤いウィジェットおよび青いウィジェットはマシンを構成する」という文は、マシンが、赤いウィジェットおよび青いウィジェットを含むことを意味する。

「排他的に構成する」という用語およびその変形は、その他特に明示的に記載のない限り、「その成分を排他的に作り上げる、その構成部分のみである、またはその要素のみである」ことを意味する。このため、例えば、「赤いウィジェットおよび青いウィジェットはマシンを排他的に構成する」という文は、マシンが、赤いウィジェットおよび青いウィジェットだけ（すなわち、他には何もない）からなることを意味する。

「ある」、「一」、「１つ」および「その」（「ａ」、「ａｎ」および「ｔｈｅ」）という用語は、その他特に明示的に記載のない限り、「１つ以上」を指す。このため、例えば、「ウィジェット」という語句は、その他特に明示的に記載のない限り、「１つ以上のウィジェット」を意味する。同様に、「ウィジェット」という語句を記した後、「ウィジェット」という語句の連続の記述は、「１つ以上のウィジェット」を意味する。したがって、「前記・その（ｔｈｅ）」という単語は、先行根拠を有する特定の用語も指し得ることを理解されたい。例えば、段落に、「ある特定の単一の特徴」と記され、次いで、「前記特徴」を指す場合、そのとき「前記特徴」という語句は、先に記された「特定の単一の特徴」を指すことを理解されたい（「ある特定の単一の特徴」中の「ある」という用語は、「１つ」の特定の単一の特徴を指し、「１つ以上の」特定の単一の特徴ではないことを理解されたい）。

「複数」という用語は、その他特に明示的に記載のない限り、「２つ以上」を意味する。

「本明細書において」という用語は、その他特に明示的に記載のない限り、「参照によって組み込まれてもよい任意の事柄を含む、本明細書において」を意味する。

「のうちの少なくとも１つ」という語句は、このような語句が複数の事柄（事柄の列挙リスト）を修飾する場合、その他特に明示的に記載のない限り、それらの事柄の１つ以上の任意の組み合わせを意味する。例えば、「ウィジェット、車、ハンドルのうちの少なくとも１つ」という語句は、（ｉ）ウィジェット、（ｉｉ）車、（ｉｉｉ）ハンドル、（ｉｖ）ウィジェットおよび車、（ｖ）ウィジェットおよびハンドル、（ｖｉ）車およびハンドル、または（ｖｉｉ）ウィジェット、車、およびハンドルのいずれかを意味する。「のうちの少なくとも１つ」という語句は、このような語句が複数の事柄を修飾する場合、複数の事柄「の各々の１つ」を意味しない。例えば、「ウィジェット、車、ハンドルのうちの少なくとも１つ」という語句は、「１つのウィジェット、１つの車、および１つのハンドル」を意味しない。

「１つ」、「２つ」等の数値用語は、何らかの数量を示すために基数として使用される場合（例えば、１つのウィジェット、２つのウィジェット）、その数値用語によって示される数量を意味するが、少なくともその数値用語によって示される数量、を意味しない。例えば、「１つのウィジェット」という語句は、「少なくとも１つのウィジェット」を意味せず、したがって、「１つのウィジェット」という語句は、例えば、２つのウィジェットを網羅しない。

「基づく」という語句は、その他特に明示的に記載のない限り、「のみに基づく」ことを意味しない。すなわち、「基づく」という語句は、「のみに基づく」および「少なくとも基づく」の両方を網羅する。「少なくとも基づく」という語句は、「少なくとも部分的に基づく」という語句と同等である。例えば、「要素Ａは、要素Ｂおよび要素Ｃに基づいて算出される」という語句は、要素ＡがＢ掛けるＣの積として算出される（すなわち、Ａ＝Ｂ×Ｃ）実施形態、Ａが、Ｂ足すＣの和として算出される（すなわち、Ａ＝Ｂ＋Ｃ）実施形態、Ａが、Ｂ掛けるＣ掛けるＤの積として算出される実施形態、Ａが、Ｂ足すＣ足すＤ掛けるＥの平方根の和として算出される実施形態等を網羅する。

「表す」等の用語は、その他特に明示的に記載のない限り、排他的ではない。例えば、「表す」という用語は、その他特に明示的に記載のない限り、「のみを表す」ことを意味しない。例えば、「データがクレジットカード番号を表す」という語句は、「データがクレジット番号だけを表す」および「データがクレジットカード番号を表し、データは他の何らかも表す」の両方を網羅する。

「それにより」という用語は、本明細書において、「それにより」という用語の前に明示的に記された何かの意図された結果、目的、または帰結のみを表現する節または他の単語セットに先行するようにのみ使用される。したがって、「それにより」という用語が特許請求の範囲内で使用される場合、「それにより」という用語が修飾する節または他の単語は、特許請求の範囲の特定の更なる制限を確立せず、または特許請求の範囲もしくは意味を制限しない。

「例えば」、「等」という用語および同様の用語は、「例を挙げれば」を意味し、したがって、それらが説明する用語または語句を制限しない。例えば、「コンピュータはインターネットを介してデータ（例えば、命令、データ構造）を送信する」という文では、「例えば」という用語は、「命令」が、コンピュータがインターネットを介して送信することができる「データ」の一例であることを説明すると共に、「データ構造」が、コンピュータがインターネットを介して送信することができる「データ」の一例であることも説明する。しかし、「命令」および「データ構造」は両方とも、「データ」の単なる例にすぎず、「命令」および「データ構造」以外の他の物事も「データ」であり得る。

「それぞれ」という用語および同様の用語は、「個々に」を意味する。したがって、２つ以上の物事が特性を「それぞれ」有する場合、このような各物事はそれ自体の特性を有し、これらの特性は互いに異なってよいが、互いに異なる必要はない。例えば、「２つのマシンの各々がそれぞれの機能を有する」という語句は、２つのマシンのうちの第１のものが機能を有し、２つのマシンのうちの第２のものも同様に機能を有することを意味する。第１のマシンの機能は、第２のマシンの機能と同じであってもよく、または同じでなくてもよい。

「すなわち」という用語および同様の用語は、「つまり」を意味し、したがって、それが説明する用語または語句を制限する。例えば、「コンピュータはインターネットを介してデータ（すなわち命令）を送信する」という文では、「すなわち」という用語は、「命令」が、コンピュータがインターネットを介して送信する「データ」であることを説明する。

数値範囲は、その他特に明示的に記載のない限り、その範囲における整数および非整数を含む。例えば、範囲「１〜１０」は、１〜１０の整数（例えば、１、２、３、４、．．．９、１０）および非整数（例えば、１．００３１４１５９２６、１．１、１．２、．．．、１．９）を含む。

２つ以上の用語または語句が同義語である場合（例えば、用語または語句が同義語であるという明示的な記載のため）、１つのこのような用語または語句の事例は、別のこのような用語または語句が異なる意味を有さなければならないことを意味しない。例えば、ある文が、「含む」という意味が「含むが、限定されない」と同義であると示す場合、「含むが、限定されない」という語句の単なる使用は、用語「含む」が「含むが、限定されない」以外を意味することを意味しない。

ＩＩ．決定する
「決定する（ｄｅｔｅｒｍｉｎｉｎｇ）」という用語およびその文法的変形（例えば、価格の決定、値の決定、ある特定の基準を満たすオブジェクトの決定）は、極めて広い意味で使用される。「決定する」という用語は、広範囲の動作を包含するため、「決定する」は、算出する、計算する、処理する、導出する、検査する、参照する（例えば、テーブル、データベース、または別のデータ構造を参照する）電子フォーマットまたはデジタル表現にレンダリングする、特定する等を含むことができる。「決定する」は、受信すること（例えば、情報を受信すること）、アクセスすること（例えば、メモリ内のデータにアクセスすること）等も含むことができる。また、「決定する」は、解決すること、選択すること、選ぶこと、確立すること等も含むことができる。

「決定する」という用語は、確実性または絶対的な正確さを含意せず、したがって、「決定する」は、推定すること、推断すること、予測すること、推測すること、平均化すること等を含むことができる。

「決定する」という用語は、数学的処理を実施しなければならないことを含意せず、数値的方法を使用しなければならないことを含意せず、かつアルゴリズムが使用されることを含意しない。

「決定する」という用語は、特定の任意のデバイスを使用しなければならないことを含意しない。例えば、コンピュータが決定することを実施する必要は必ずしもない。

「決定する」という用語は、「算出する」ことを含んでもよい。「算出する」という用語は、１つ以上の算出を実施することを含むと理解されるべきである。算出することは、計算すること、処理すること、および／または導出することを含んでもよい。算出することは、コンピューティングデバイスによって実施され得る。例えば、事柄を算出することは、コンピュータプロセッサによってアルゴリズムをデータに適用すること、およびプロセッサの出力として事柄を生成することを含み得る。

「決定する」という用語は、「参照する」ことを含んでもよい。「参照する」という用語は、１つ以上の参照を、例えば、事柄に対してなすことを含むと理解されるべきである。参照することは、問い合わせること、アクセスすること、選択すること、選ぶこと、読み出すこと、および／または検索することを含み得る。参照する作動は、コンピューティングデバイスによって実施され得る。例えば、事柄を参照することは、事柄がプロセッサによって記憶されるメモリ場所を読み出すことを含んでもよい。

「決定する」という用語は、「受信する」ことを含んでもよい。例えば、事柄を受信することは、事柄を取り込むことを含んでもよい。いくつかの実施形態では、受信することは、事柄が通って取り込まれるネットワークインターフェースを動作すること等の事柄を取り込むように実施された作動を含んでもよい。いくつかの実施形態では、受信することは、ダイレクトメモリ書き込みまたはハードワイヤード回路等において事柄を取り込むように実施された作動なしに実施されてもよい。事柄を受信することは、事柄を算出した可能性があるリモート情報源から事柄を受信することを含んでもよい。

ＩＩＩ．文章の形態
第１の請求項の制限が、特徴の１つならびに特徴のうちの２つ以上を包含し（例えば、「少なくとも１つのウィジェット」等の制限は、１つのウィジェットならびに２つ以上のウィジェットを包含する）、第１の請求項に従属する第２の請求項において、第２の請求項が、その制限を指すために定冠詞「前記（ｔｈｅ）」を使用する場合（例えば、「前記ウィジェット（ｔｈｅ ｗｉｄｇｅｔ）」）、この単なる使用は、第１の請求項が特徴のうちの１つのみを包含することを含意せず、第２の請求項が特徴のうちの１つのみを包含することを含意しない（例えば、「前記ウィジェット」は、１つのウィジェットおよび２つ以上のウィジェットの両方を包含することができる）。

序数（「第１の」、「第２の」、「第３の」等）が用語の前に形容詞として使用される場合、その序数は（その他特に明示的に記載のない限り）、単に、特定の特徴を同じ用語または同様の用語で説明される別の特徴と区別するため等の特定の特徴を示すために使用されるが、その序数は、任意の他の意味または限定効果を有しない、単に便宜上の名称である。例えば、「第１のウィジェット」は、単に、例えば「第２のウィジェット」から区別するためにそのような名称を有し得る。したがって、「ウィジェット」という用語の前に単に序数「第１の」および「第２の」を使用することは、２つのウィジェットの他のいかなる関係も示さず、同様に、いずれかまたは両方のウィジェットの他のいかなる特性も示さない。例えば、「ウィジェット」という用語の前に単に序数「第１の」および「第２の」を使用することは、（１）いずれかのウィジェットの順序または場所が他の任意のウィジェットの前または後にくることを示さず、（２）いずれかのウィジェットが、他の任意のウィジェットの時間的に前または後に発生するか、または作動することを示さず、かつ（３）いずれかのウィジェットが、重要性または品質において他の任意のウィジェットよりも上または下にランクされることを示さない。単なる序数の使用は、序数を使用して識別される特徴に対する数値的制限を定義しない。例えば、「ウィジェット」という用語の前の序数「第１の」および「第２の」の単なる使用は、ウィジェットが厳密に２個存在することを示さない。

単一のデバイス、物品、または他の製品が本明細書において述べられる場合、別の実施形態では、代替として、説明される単一のデバイスまたは物品に代えて２つ以上のデバイスまたは物品を（連携するか否かに関わりなく）使用してもよい。したがって、別の実施形態では、デバイスによって処理されると説明される機能は、代替として、２つ以上のデバイスまたは物品によって所有されてもよい（連携するか否かに関わりなく）。

同様に、２つ以上のデバイス、物品、または他の製品が本明細書において述べられる場合（連携するか否かに関わりなく）、別の実施形態では、代替として、述べられている２つ以上のデバイスまたは物品に代えて、単一のデバイスまたは物品を使用してもよい。例えば、複数のコンピュータベースのデバイスを単一のコンピュータベースのデバイスで置き換えてもよい。いくつかの実施形態では、このような複数のコンピュータベースのデバイスは、グリッドコンピューティングシステムにおいて一般的であるようなプロセスの１つのステップを実施するように一緒に動作し得る。いくつかの実施形態では、複数のものが、クラウドコンピューティングシステムにおいて一般的であるようなプロセスの１つのステップを実施するように動作し得るように、このような複数のコンピュータベースのデバイスは、互いに追加された機能性を動作し得、且つ提供し得る。（逆に、単一のコンピュータベースのデバイスは、互いに連携して動作する複数のコンピュータベースのデバイスで置き換えてもよい。例えば、単一のコンピューティングデバイスは、インターネットを介して互いに通信しているサーバおよびワークステーションで置き換えてもよい。）したがって、２つ以上のデバイスまたは物品によって処理されると述べられる様々な機能は、代替として、単一のデバイスまたは物品によって所有されてもよい。

述べられる単一のデバイスの機能および／または特徴は、別の実施形態では、代替として、述べられているが、このような機能または特徴を有するものとして明示的に述べられていない１つ以上の他のデバイスで実施してもよい。したがって、他の実施形態は、述べられたデバイス自体を含む必要はなく、むしろ、これら他の実施形態において、このような機能または特徴を有する１つ以上の他のデバイスを含んでもよい。

ＩＶ．開示される例および用語は非制限的である
名称（本明細書の第１のページの先頭に記載）も要約（本明細書の最後に記載）も決して、開示される発明の範囲を限定すると解釈されてはならず、任意の請求項の意味を解釈する際に使用されてはならず、任意の請求項の範囲を限定する際に使用されてはならない。要約は、３７．Ｃ．Ｆ．Ｒ．の１．７２（ｂ）下で必要であることを理由としてのみ、要約は本明細書に含まれる。

本願に提供される項の見出しは便宜を図るためのみであり、本開示を制限するものとして決して解釈されるべきではない。

多くの実施形態が本願において説明され、例示のみを目的として提示される。説明される実施形態は、決して制限せず、決して制限を目的としない。開示される発明は、本開示から容易に明らかなように、多くの実施形態に対して広く適用可能である。当業者ならば、構造的、論理的、ソフトウェアの、および電気的な修正等の様々な修正および変更を加えて、開示される発明を実施してもよいことを理解するであろう。開示される発明の特定の特徴を、１つ以上の特定の実施形態および／または図面を参照して説明することがあるが、このような特徴が、その他特に明示的に記載のない限り、参照して説明される１つ以上の特定の実施形態または図面内の使用法に制限されないことを理解されたい。

一実施形態は、いくつかの特徴を含むとして開示されてもよいが、本発明の他の実施形態は、全てのこのような特徴よりも少ない特徴を含んでもよい。このため、例えば、一請求項は、開示される実施形態において、全体の組の特徴よりも少ない特徴に関してもよく、このような請求項は、請求項が明示的に記載するそれらの特徴以外の特徴を必要とするとして解釈されることはない。

本願において説明される方法ステップまたは製品要素の実施形態は、本明細書においてそのように明示的に記述されるか、または（特許請求の範囲およびその特許請求の範囲によって定義される本発明に関して）その特許請求の範囲内で明示的に記載される場合を除き、本明細書において請求される本発明を構成せず、本明細書において請求される本発明にとって必須ではなく、または本明細書において請求される本発明と同一の広がりを持たない。

法定分類以外の任意のものを記す特許請求の範囲の任意のプリアンブルは、請求される本発明の目的、利点、および可能な使用法を記すと解釈されるものとし、このようなプリアンブルは、請求される本発明を制限するように解釈されるものとしない。

本開示は、本発明の全ての実施形態の文字通りに正確な説明ではない。また、本開示は、全ての実施形態に存在することが必要である、本発明の特徴の列挙ではない。

全ての開示される実施形態は必ずしも請求項によって網羅されない（全ての保留、変更、公開、および取り消された請求項を含む場合であっても）。加えて、開示される実施形態は、いくつかの請求項によって網羅されてもよい（しかし、必ずしも網羅される必要はない）。したがって、一請求項（保留、変更、公開、または取り消しに関わりなく）が特定の実施形態に関する場合、これは、他の請求項の範囲もその実施形態に関係するということはないという証拠ではない。

互いに通信するものとして説明されるデバイスは、その他特に明示的に記載のない限り、互いに連続して通信する必要はない。逆に、このようなデバイスは、必要または所望に応じて互いに伝送する必要があるだけであり、実際には、大半の時間においてデータを交換しなくてもよい。例えば、インターネットを介して別のマシンと通信するマシンは、長期間（例えば、１度に数週間）にわたって他のマシンにデータを伝送しなくてもよい。これに加えて、互いに通信するデバイスは、直接通信してもよく、または１つ以上の媒介物を通して間接的に通信してもよい。デバイスは、それらが互いに少なくとも一方向の通信ができている場合、互いに通信している。例えば、第１のデバイスは、第１のデバイスが第２のデバイスに情報を伝送できている場合、第２のデバイスと通信している。同様に、第２のデバイスは、第２のデバイスが第１のデバイスから情報を受信できている場合、第１のデバイスと通信している。

いくつかの構成要素または特徴を有する一実施形態の説明は、このような構成要素または特徴の全てまたは任意のものが要求されることを含意しない。逆に、本発明の広範囲の可能な実施形態を示すために、様々な任意選択的な構成要素が説明される。別段の明示的な定めがない限り、構成要素または特徴は必須ではなく、または要求されない。

プロセスステップ、アルゴリズム等は、特定の逐次順で説明または請求されることがあるが、このようなプロセスは異なる順序で働くように構成することが可能である。
換言すれば、明示的に説明または請求され得るステップのいかなる順序または順番も、ステップをその順番で実施するという要件を必ずしも示すものではない。本明細書において説明されるプロセスのステップは、可能な任意の順番で実施することができる。更に、（例えば、あるステップが他のステップの後に説明されるため）同時に行われるものとして説明または含意されていないにもかかわらず、いくつかのステップを同時に実施してもよい。更に、図面内の説明によるプロセスの例示は、例示されたプロセスが他の変形および変更を除外することを含意せず、例示されたプロセスまたはそのステップの任意のものが本発明にとって必要であることを含意せず、かつ例示されたプロセスが好ましいことを含意しない。

プロセスを複数のステップを含むものとして説明することがあるが、それは、ステップのうちの全てまたは任意のものが好ましい、必須である、または要求されることを含意しない。本発明の範囲内の多様な他の実施形態は、記載のステップのうちのいくつか、または全てを省略する他のプロセスを含む。その他特に明示的に記載のない限り、どのステップも必須または必要ではない。

プロセスを単独で、すなわち他の製品または方法を参照せずに説明し得るが、一実施形態では、プロセスは他の製品または方法と相互作用してもよい。例えば、このような相互作用は、あるビジネスモデルを別のビジネスモデルにリンクすることを含み得る。このような相互作用は、プロセスの柔軟性または望ましさを向上させるために提供することができる。

製品は、複数の構成要素、態様、数量、特性、および／または特徴を含むものとして説明され得るが、それは、これら複数のうちのいくつかまたは全てが好ましい、必須である、または要求されることを示さない。記載される本発明の範囲内の他の様々な実施形態は、説明される複数のうちのいくつかまたは全てを省いた他の製品を含む。

アイテム（付番されているものもあれば、ないものもある）の列挙リストは、その他特に明示的に記載のない限り、アイテムのうちの任意のものまたは全てが相互に排他的であることを含意しない。同様に、アイテム（付番されているものもあれば、ないものもある）の列挙リストは、その他特に明示的に記載のない限り、アイテムのうちの任意のものまたは全てが任意のカテゴリを包括するものであることを含意しない。例えば、列挙リスト「コンピュータ、ラップトップ、およびＰＤＡ」は、そのリストの３つのアイテムのうちの任意のもの又は全てが相互に排他的であることを含意せず、そのリストの３つのアイテムのうちの任意のものまたは全てが任意のカテゴリを包括することを含意しない。

アイテム（付番されているものもあれば、ないものもある）の列挙リストは、アイテムのうちの任意のものまたは全てが、互いに等価である、または互いに容易に置換されることを含意しない。

全ての実施形態は例示的であり、場合によっては、本発明またはあらゆる実施形態が作成または実施されたことを含意しない。

Ｖ．コンピューティング
本明細書において説明する様々なプロセスは、例えば、適宜プログラムされた汎用コンピュータ、専用コンピュータ、およびコンピューティングデバイスによって実施してもよいことを当業者ならば容易に理解するであろう。通常、プロセッサ（例えば、１つ以上のマイクロプロセッサ、１つ以上のマイクロコントローラ、１つ以上のデジタル信号プロセッサ）は、命令を受け取り（例えば、メモリまたは同様のデバイスから）、それら命令を実施し、それにより、命令によって定義される１つ以上のプロセスを実行する。命令は、例えば、１つ以上のコンピュータプログラム、１つ以上のスクリプトで実施することができる。

「計算」という用語は、ソフトウェアアルゴリズムに関してプロセッサを使用することを決定することを意味するものとする。

「プロセッサ」は、アーキテクチャ（例えば、チップレベルマルチプロセッシングまたはマルチコア、ＲＩＳＣ、ＣＩＳＣ、インターロックパイプラインステージを有さないマイクロプロセッサ、パイプライン構成、同時マルチスレッド、統合型グラフィックス処理装置付きマイクロプロセッサ（ｍｉｃｒｏｐｒｏｃｅｓｓｏｒ ｗｉｔｈ ｉｎｔｅｇｒａｔｅｄ ｇｒａｐｈｉｃｓ ｐｒｏｃｅｓｓｉｎｇ ｕｎｉｔ）、ＧＰＧＰＵ）に関わりなく、１つ以上のマイクロプロセッサ、中央演算処理装置（ＣＰＵ）、コンピューティングデバイス、マイクロコントローラ、デジタル信号プロセッサ、グラフィックス処理装置（ＧＰＵ）、同様のデバイス、またはこれらの任意の組み合わせを意味する。

「コンピューティングデバイス」は、アーキテクチャ（例えば、チップレベルマルチプロセッシングまたはマルチコア、ＲＩＳＣ、ＣＩＳＣ、インターロックパイプラインステージを有さないマイクロプロセッサ、パイプライン構成、同時マルチスレッド）に関わりなく、１つ以上のマイクロプロセッサ、中央演算処理装置（ＣＰＵ）、コンピューティングデバイス、マイクロコントローラ、デジタル信号プロセッサ、グラフィックスカード、モバイルゲームデバイス、同様のデバイス、またはこれらの任意の組み合わせを意味する。

したがって、プロセスの説明は同様に、プロセスを実施するための装置の説明でもある。プロセスを実施する装置は、例えば、プロセッサおよびプロセスの実施に適した入出力デバイスを含むことができる。例えば、プロセスの説明は、プロセッサと、プロセッサによって実行されたとき、プロセッサに方法を実施するように指示する命令を含むプログラムを記憶するメモリと、を備える装置の説明である。

プロセスを実施する装置は、プロセスを実施するために一緒に稼働する複数のコンピューティングデバイスを含むことができる。コンピューティングデバイスのうちのいくつかは、プロセスの各ステップを実施するために一緒に稼働し得、プロセスの別個のステップについて稼働し得、プロセスの実施を容易にし得るその他のコンピューティングデバイスに基礎となるサービスを提供し得る。このようなコンピューティングデバイスは、中央権限の命令下で作動し得る。別の実施形態では、このようなコンピューティングデバイスは、中央権限の命令なしで作動し得る。このような方法のうちのいくつかまたは全てにおいて動作し得る装置のうちのいくつかの実施例は、グリッドコンピュータシステム、クラウドコンピュータシステム、ピアツーピアコンピュータシステム、サービスとしてソフトウェアを提供するように構成されるコンピュータシステム等を含み得る。例えば、装置は、ＶＭｗａｒｅソフトウェアを実行するコンピュータシステム等の、その処理ロードのバルクをリモートサーバ上で実行するが、ローカルユーザコンピュータに表示情報を出力し、ローカルユーザコンピュータからユーザ入力情報を受信するコンピュータシステムを含み得る。

更に、このような方法を実施するプログラム（ならびに他の種類のデータ）は、様々な媒体（例えば、コンピュータ可読媒体）を使用していくつかの様式で記憶し伝送することができる。いくつかの実施形態では、様々な実施形態のプロセスを実施することができるソフトウェア命令のうちのいくつかまたは全てに代えて、またはそれと組み合わせて、ハードワイヤード回路またはカスタムハードウェアを使用してもよい。したがって、ソフトウェアのみに代えて、ハードウェアおよびソフトウェアの様々な組み合わせを使用してもよい。

「コンピュータ可読媒体」という用語は、コンピュータ、プロセッサ、または同様のデバイスにより読み取り可能な、データ（例えば、命令、データ構造）の提供に関与する任意の非一時的媒体、複数の同じ媒体、または異なる媒体の組み合わせを指す。このような媒体は、不揮発性媒体、揮発性媒体、および伝送媒体を含むがこれらに制限されない多くの形態をとり得る。不揮発性媒体は、例えば、光ディスク、磁気ディスク、および他の永久メモリを含む。揮発性媒体は、通常、メインメモリを構成するダイナミックランダムアクセスメモリ（ＤＲＡＭ）を含む。伝送媒体は、プロセッサに結合されるシステムバスを構成する線を含め、同軸ケーブル、銅線、および光ファイバを含む。伝送媒体は、音波、光波、および無線周波（ＲＦ）および赤外線（ＩＲ）データ通信中に生成されるような電磁波（ｅｌｅｃｔｒｏｍａｇｎｅｔｉｃ ｅｍｉｓｓｉｏｎ）を含むか、または伝達することができる。コンピュータ可読媒体の一般的な形態としては、例えば、フロッピー（登録商標）ディスク、フレキシブルディスク、ハードディスク、磁気テープ、他の任意の磁気媒体、ＣＤ−ＲＯＭ、ＤＶＤ、他の任意の光学媒体、パンチカード、紙テープ、パターンになった穴を有する他の任意の物理媒体、ＲＡＭ、ＰＲＯＭ、ＥＰＲＯＭ、フラッシュＥＥＰＲＯＭ、他の任意のメモリチップまたはカートリッジ、後述する搬送波、またはコンピュータが読み取り可能な他の任意の媒体が挙げられる。

「有形のコンピュータ可読媒体」という用語は、光学または磁気ディスク等のハードウェア構成要素を備える「コンピュータ可読媒体」を指す。

様々な形態のコンピュータ可読媒体が、データ（例えば、命令シーケンス）のプロセッサへの搬送に関与し得る。例えば、データは、（ｉ）ＲＡＭからプロセッサに送出され、（ｉｉ）無線伝送媒体を介して搬送され、（ｉｉｉ）イーサネット（登録商標）（またはＩＥＥＥ８０２．３）、それらがＷｉＦｉ Ａｌｌｉａｎｃｅによって承認されたかどうかのＩＥＥＥ８０２．１１仕様書によって定義される無線ローカルエリアネットワーク通信、ＳＡＰ、ＡＴＰ、Ｂｌｕｅｔｏｏｔｈ（登録商標）、およびＴＣＰ／ＩＰ、ＴＤＭＡ、ＣＤＭＡ、および３Ｇ等の多くの形式、規格、またはプロトコルに従ってフォーマットされおよび／または伝送され、および／または（ｉｖ）当分野において周知の様々な方法のうちの任意の方法で暗号化されて、プライバシーを確保し、不正を阻止することができるものであることとしてもよい。

「データベース」という用語は、検索可能な形式で記憶されるデータの任意の電子記憶されるコレクションを指す。

「データ構造」という用語は、コンピュータ等のハードウェアマシン内のデータベースを指す。

「ネットワーク」という用語は、通信経路によって相互接続される一連のポイントまたはノードを意味する。例えば、ネットワークは、１つ以上の有線および／または無線通信経路によって相互接続される複数のコンピュータまたは通信デバイスを含み得る。ネットワークは、他のネットワークと相互接続し得、サブネットワークを含み得る。

「所定の」という用語は、例えば、現在時刻または現在の動作前に、予め決定されていることを意味する。例えば、「所定の値を表示する」という語句は、表示の作動前に決定された値を表示することを意味する。

「条件」という用語は、（１）合意の履行に基づく前提、または（２）何らかの出現または発生に必要不可欠な何か、を意味する。

「トランザクション」という用語は、（１）商品、サービス、または基金の交換または転送、または（２）相互に影響をおよぼすかまたは互いに影響しあう２つの組織または事柄を含む通信動作または活動を意味する。

したがって、プロセスの説明は同様に、プロセスを実施するためのプログラムを記憶するコンピュータ可読媒体の説明でもある。コンピュータ可読媒体は、方法の実施に適したプログラム要素を（任意の適切な形式で）記憶することができる。例えば、プロセスの説明は、プロセッサによって実行されたとき、プロセッサに方法を実施するように指示する命令を含むプログラムを記憶するコンピュータ可読媒体の説明である。

プロセスの様々なステップの説明が、説明される全てのステップが要求されることを示さないのと同様に、装置の実施形態は、説明されたプロセスのうちのいくつか（であるが、必ずしも全てである必要はない）を実行するように動作可能なコンピュータまたはコンピューティングデバイスを含む。

同様に、プロセスの様々なステップの説明が、説明される全てのステップが要求されることを示さないのと同様に、プログラムまたはデータ構造を記憶するコンピュータ可読媒体の実施形態は、実行されると、説明されたプロセスのうちのいくつか（であるが、必ずしも全てである必要はない）をプロセッサに実施させることができるプログラムを記憶するコンピュータ可読媒体を含む。

データベースが説明される場合、（ｉ）説明された構造に対する代替のデータベース構造を容易に利用することができ、かつ（ｉｉ）データベース以外の他のメモリ構造も容易に利用することができることを当業者ならば理解するであろう。本明細書において提示される任意のデータベースサンプルのいかなる例示または説明も、記憶された情報表現の例示的な構成である。例えば、図面または他の場所で示されるテーブルによって示唆されるもの以外の任意の数の他の構成を利用してもよい。同様に、データベースの例示されるいかなるエントリも、例示的な情報を表すにすぎず、エントリの数および内容は、本明細書において説明されるものと異なってよいことを当業者ならば理解するであろう。更に、テーブルとしてのデータベースの任意の説明にもかかわらず、本明細書において説明されるデータ型を記憶し操作するために、他の形式（関係データベース、オブジェクトベースモデル、および／または分散データベースを含む）を使用してもよい。同様に、データベースのオブジェクトの方法または挙動を使用して、本明細書において説明されるような様々なプロセスを実施することができる。これに加えて、データベースは、またはこのようなデータベース内のデータにアクセスするデバイスにローカルまたはリモートに既知の様式で記憶することができる。

様々な実施形態は、１つ以上のデバイスと（例えば、通信ネットワークを介して）通信するコンピュータを含むネットワーク環境で動作するように構成することができる。コンピュータは、有線または無線媒体（例えば、インターネット、ＬＡＮ、ＷＡＮ、またはイーサネット、トークンリング、電話回線、ケーブル回線、無線チャネル、光通信回線、商業オンラインサービスプロバイダ、電子掲示板システム、衛星通信リンク、上記の任意の組み合わせ）を介して直接または間接的にデバイスと通信することができる。各デバイスは、それ自体、コンピュータと通信するように構成された、インテル（Ｉｎｔｅｌ）（登録商標）、ペンティアム（Ｐｅｎｔｉｕｍ）（登録商標）、またはセントリノ（Ｃｅｎｔｒｉｎｏ）（商標）、アトム（Ａｔｏｍ）（商標）、またはコア（Ｃｏｒｅ）（商標）プロセッサに基づくようなコンピュータまたは他のコンピューティングデバイスを含むことができる。任意の数および種類のデバイスがコンピュータと通信状態であってもよい。

一実施形態では、サーバコンピュータまたは中央権限は必要なくてもよいか、または望ましくない場合がある。例えば、本発明は、一実施形態では、中央権限なしで１つ以上のデバイス上で実施してもよい。このような一実施形態では、サーバコンピュータによって実施されるものとして本明細書において説明されるいかなる機能またはサーバコンピュータに記憶するものとして説明されるデータは、サーバコンピュータに代えて、このような１つ以上のデバイス上で実施してもよいか、または記憶してもよい。

プロセスが説明される場合、一実施形態では、プロセスは一切のユーザ介入なしで動作することが可能である。別の実施形態では、プロセスは、何らかの人的介入を含む（例えば、ステップが、人間により、または人間の支援により実施される）。

本明細書に使用されるとき、「暗号化」という用語は、情報が特別な知識なしに容易に理解可能とならないように、情報を隠蔽または隠匿するためのプロセスを指す。暗号化のプロセスは、プレーンテキストと呼ばれる未加工の情報を暗号化された情報に変換できる。暗号化された情報は、暗号文と呼ばれてもよく、プレーンテキストを暗号文に変換するためのアルゴリズムは、暗号化法として称され得る。暗号化法は、暗号文をプレーンテキストに戻して変換する逆の動作を実施するためにも使用され得る。暗号化法の例としては、換字式暗号化法、転置式暗号化法、およびロータマシンを使用して実装される暗号化法が挙げられる。

種々の暗号化の方法では、暗号化法は、キーと呼ばれる情報の追加片を必要とし得る。キーは、例えば、ビットのストリングからなり得る。キーは、プレーンテキストを暗号化するための暗号化法と合わせて使用され得る。キーはまた、暗号文を解読するための暗号化法と合わせて使用され得る。対称キーアルゴリズムと呼ばれる暗号化法の分類では（例えば、秘密キー暗号法）、同じキーが、暗号化と解読化のいずれにも使用される。暗号化される情報の不可侵性は、したがって、秘密が明らかにされないキーに応じて様々であり得る。対称キーアルゴリズムの例は、ＤＥＳおよびＡＥＳである。非対称キーアルゴリズムと呼ばれる暗号化法の分類では（例えば、公開キー暗号法）、異なるキーが、暗号化および解読化に使用される。非対称キーアルゴリズムでは、公衆の任意のメンバが、プレーンテキストを暗号文に暗号化するために第１のキー（例えば、公開キー）を使用し得る。しかしながら、第２のキー（例えば、秘密キー）の保持者のみが、暗号文をプレーンテキストに戻して解読することができるであろう。非対称キーアルゴリズムの例は、ＲＳＡアルゴリズムである。

ＶＩ．継続出願
本開示は、いくつかの実施形態および／または発明の実施可能要件の説明を当業者に提供する。これら実施形態および／または発明のうちのいくつかは、本願において請求されないかもしれないが、それでもやはり、本願の優先権の恩恵を主張する１つ以上の継続出願において請求され得る。

出願は、本願において開示され、実施可能要件が提示されたが請求されなかった趣旨について特許を請求するために、追加の出願を提出することを意図する。

ＶＩＩ．米国特許法１１２条、第６段落
請求項において、「のための手段」という語句または「のためのステップ」という語句を含む請求項の制限は、米国特許法１１２条、第６段落が、その制限に適用されることを意味する。

請求項において、「のための手段」という語句または「のためのステップ」という語句を含まない請求項の制限は、その制限が、その機能を実施するための構造、材料、または作動の記載を含めずに、機能を記載しているかどうかに関わらず、米国特許法１１２条、第６段落が、その制限に適用されないことを意味する。例えば、請求項において、その請求項または別の請求項の１つ以上のステップを参照する際の「のステップ（複数可）」という語句の単なる使用は、米国特許法１１２条、第６段落がそのステップ（複数可）に適用されることを意味しない。

米国特許法１１２条、第６段落に従って特定の機能を実施するための手段またはステップに関して、本仕様書、およびその同等物に記載される対応する構造、材料、または作動は、追加の機能、ならびに指定された機能を実施することができる。

コンピュータ、プロセッサ、コンピューティングデバイス、および同様な製品は、広範囲の機能を実施することができる構造物である。このような製品は、その製品のメモリデバイスまたはその製品がアクセスするメモリデバイスに記憶されたプログラム等、１つ以上のプログラムを実行することによって、指定された機能を実施するように操作可能であり得る。その他特に明示的に記載のない限り、そのようなプログラムは、本明細書に開示されるかもしれない、任意の特定のアルゴリズム等、任意の特定のプログラムに基づく必要はない。当業者には、指定された機能は、異なるアルゴリズムを介して実装されてもよいこと、いくつかの異なるアルゴリズムのうちのいずれかは、指定された機能を実行するための単なる設計選択肢であることが周知である。

したがって、米国特許法１１２条、第６段落に従って特定の機能を実施するための手段またはステップに関して、指定された機能に対応する構造物は、指定された機能を実施するようにプログラムされた任意の製品を含む。このような構造物は、このような製品が、（ｉ）機能を実施するための開示されたアルゴリズム、（ｉｉ）開示されたアルゴリズムに類似のアルゴリズム、または（ｉｉｉ）機能を実施するための異なるアルゴリズムを用いてプログラムされているかに関わらず、機能を実施する、プログラムされた製品を含む。

方法である機能を実施するための手段が記載されている場合、この方法を実施するための構造物は、その機能を実施するために、適切なハードウェアを用いてプログラムおよび／または構成されるコンピューティングデバイス（例えば、汎用コンピュータ）を含む。

また、当業者によって理解されるであろう他のアルゴリズムを介してその機能を実施するように、適切なハードウェアを用いてプログラムおよび／または構成されるコンピューティングデバイス（例えば汎用コンピュータ）も含まれる。

ＶＩＩＩ．放棄
特定の実施形態への多くの参照は、追加の異なる実施形態の放棄または否認を示さず、同様に、全て特定の特徴を含む実施形態の説明への参照も、その特定の特徴を含まない実施形態の放棄または否認を示さない。本願における明確な放棄または否認は、「含まない」という語句または「実施できない」という語句によって前置きされるであろう。

ＩＸ．参照による援用
本明細書において参照されるあらゆる特許、特許出願、または他の文献は、本開示の一部として本特許出願に参照により援用されるが、米国特許法第１１２条第１項による書面での説明および米国特許法第１１２条第１項による実施可能要件のためにのみであり、このような参照による援用がなければ通常の意味を当業者が確認できなかったという場合ではない限り、本願のいかなる用語の制限、定義、または解釈にも決して使用されるべきではない。したがって、当業者は、参照により提供されるいかなる実施形態によっても決して制限される必要はない。逆に、本明細書に提供される定義は、参照により本明細書に組み込まれるいずれの文書のいずれの用語も限定、定義、または別段に解釈されるように使用されるべきではない。本明細書に明示的に記載される定義は、定義（複数可）と矛盾し得る特定の実施形態の説明にかかわらず統制している。

参照による援用はいずれもそれ自体は、本特許出願において別段の明示的な定めがない限り、援用されるいかなる特許、特許出願、または他の文献に含まれるいかなる記述、意見、議論、または特徴のいかなる裏書き、承認、または黙認も含意しない。

Ｘ．審査経過
（特許請求の範囲を含む）本願を解釈するに際して、当業者は、本願に関連すると考えられる他の特許出願があるか否かに関わりなく、また本願と優先権の主張を共有する他の特許出願があるか否かに関わりなく、任意の他の特許または特許出願の経過履歴ではなく、本願の審査経過を参照する。

〔付記１〕
特定の取引者のワークステーションに関連付けられた少なくとも１つのプロセッサと、
命令が格納された少なくとも１つのメモリと、を備え、前記命令は、前記少なくとも１つのプロセッサによって実行された場合に、前記少なくとも１つのプロセッサに対し、
アイテムに対する、第１の充足率及び第１の応答時間に関連付けられた第１の注文を受信するステップと、
前記第１の注文を受信した後に、前記アイテムに対する、第２の充足率及び第２の応答時間に関連付けられた第２の注文を受信するステップと、
前記特定の取引者の注文帳において、前記第１の注文に関連付けられた前記第１の充足率及び前記第１の応答時間と、前記第２の注文の前記第１の充足率及び前記第１の応答時間と、に少なくとも部分的に基づいて、前記第２の注文を、前記第１の注文より優先して注文するステップと、
前記注文帳において、前記第２の注文を、前記第１の注文より優先して注文することに応答して、前記第１の注文に対抗する、前記特定の取引者のいかなる注文のいかなる執行よりも前に、前記特定の取引者の注文を、前記第２の注文に対抗して執行されるようにするステップと、を更に指示する、
装置。
〔付記２〕
前記第１の注文を受信する前記ステップは、前記第１の充足率を受信することを含み、前記第２の注文を受信する前記ステップは、前記第２の充足率を受信することを含む、付記１に記載の装置。
〔付記３〕
前記第１の充足率は、前記第１の注文のプロバイダにルーティングされた注文が前記第１の注文の前記プロバイダによって応じられた回数と、前記第１の注文の前記プロバイダにルーティングされた注文が前記第１の注文の前記プロバイダによって応じられなかった回数と、の比較に基づいて決定される、付記１に記載の装置。
〔付記４〕
前記第１の充足率は、前記第１の注文のプロバイダにルーティングされた、前記アイテムに対する注文が前記第１の注文の前記プロバイダによって応じられた回数と、前記第１の注文の前記プロバイダにルーティングされた、前記アイテムに対する注文が前記第１の注文の前記プロバイダによって応じられなかった回数と、の比較に基づいて決定される、付記１に記載の装置。
〔付記５〕
前記第１の充足率は、前記第１の注文のプロバイダにルーティングされ、前記第１の注文の前記プロバイダによって応じられた総量と、前記第１の注文の前記プロバイダにルーティングされ、前記第１の注文の前記プロバイダによって応じられなかった総量と、の比較に基づいて決定される、付記１に記載の装置。
〔付記６〕
前記第１の充足率は、前記第１の注文のプロバイダにルーティングされ、前記第１の注文の前記プロバイダによって応じられた、前記アイテムの総量と、前記第１の注文の前記プロバイダにルーティングされ、前記第１の注文の前記プロバイダによって応じられなかった、前記アイテムの総量と、の比較に基づいて決定される、付記１に記載の装置。
〔付記７〕
前記第１の充足率は、前記第１の注文のプロバイダにルーティングされた、前記アイテムに対する特定の量の範囲の注文が前記第１の注文の前記プロバイダによって応じられた回数と、前記第１の注文の前記プロバイダにルーティングされた、前記アイテムに対する前記特定の量の範囲の注文が前記第１の注文の前記プロバイダによって応じられなかった回数と、の比較に基づいて決定される、付記１に記載の装置。
〔付記８〕
前記第２の注文は第１の応答時間に関連付けられ、前記命令は、少なくとも１つのプロセッサによって実行された場合に、前記少なくとも１つのプロセッサに対し、
前記第２の注文を受信するより先に、前記アイテムに対する第３のユーザからの第３の注文を前記少なくとも１つのサーバにより受信するステップであり、前記第３の注文は、価格が前記第２の注文の価格と等しく、前記第３の注文は、前記第１の応答時間より長い第２の応答時間に関連付けられている、前記ステップと、
少なくとも１つのサーバにより、前記注文帳において、前記第２の注文に関連付けられた前記第１の応答時間より長い、前記第３の注文に関連付けられた前記第２の応答時間に少なくとも部分的に基づいて、前記第２の注文を、前記第３の注文より優先して注文するステップと、を更に指示し、
少なくとも１つのサーバにより前記取引コマンドを前記第２のユーザまで伝達する前記ステップは、前記少なくとも１つのサーバにより、前記アイテムに関するいかなる取引コマンドを前記第３のユーザに伝達するステップよりも先に行われ、前記伝達するステップは、前記注文帳において前記第２の注文が前記第３の注文より優先して注文されることに応答して行われる、
付記１に記載の装置。
〔付記９〕
前記命令は、前記少なくとも１つのプロセッサによって実行された場合に、前記少なくとも１つのプロセッサに対し、
第３の注文及び第４の注文を受信するステップと、
前記第３の注文の少なくとも一部分が、前記第１の注文の少なくとも一部分から独立していない確率を求めるステップと、
前記求められた、前記第３の注文の少なくとも一部分が、前記第１の注文の少なくとも一部分から独立していない確率に少なくとも部分的に基づいて、前記注文帳に記載されている前記第３の注文及び前記第４の注文を注文するステップと、を更に指示する、
付記１に記載の装置。
〔付記１０〕
前記第１の充足率は、単位時間当たりの応じる確率を含み、前記第２の充足率は、単位時間当たりの応じる確率を含む、付記１に記載の装置。
〔付記１１〕
少なくとも１つのサーバにより、アイテムに対する第１の注文及び第２の注文を受信するステップであって、
前記第１の注文は第１のユーザに関連付けられており、前記第２の注文は第２のユーザに関連付けられており、
前記第１及び第２の注文は、関連付けられている価格が同じであり、
前記第１の注文は、前記第２の注文より先に受信され、
前記第１の注文には第１の充足率が関連付けられ、
前記第２の注文には第２の充足率が関連付けられる、前記ステップと、
少なくとも１つのサーバにより、前記アイテムを買うか売る為のコマンドを受信するステップであって、前記コマンドは、それに関連付けられた条件を有する、前記ステップと、
少なくとも１つのサーバにより、前記第１の注文に関連付けられた前記第１の充足率が前記閾値を満たさないと判定するステップと、
前記第１の注文に関連付けられた前記第１の充足率が前記閾値を満たさないと判定したことの結果として、少なくとも１つのサーバにより、前記第１の注文を無視し、前記第２の注文に関連付けられた前記第２の充足率が前記条件を満たすかどうかを判定するステップと、
少なくとも１つのサーバにより、前記第２の注文に関連付けられた前記第２の充足率が前記条件を満たすと判定するステップと、
前記第２の注文に関連付けられた前記第２の充足率が前記条件を満たすと判定したことの結果として、少なくとも１つのサーバにより、前記第１の注文に関連するいかなる取引コマンドを伝達するよりも先に、前記第２の注文に関連付けられた取引コマンドを前記第２のユーザに伝達するステップと、
前記第２のユーザに前記取引コマンドを伝達することに応答して、前記第２のユーザが前記取引コマンドに対抗する取引をしようとしているという通知を受信するステップと、
を含む方法。
〔付記１２〕
前記第１の注文を受信する前記ステップは、前記第１の充足率を受信することを含み、
前記第２の注文を受信する前記ステップは、前記第２の充足率を受信することを含み、
前記第１の充足率は、単位時間当たりの応じる確率を含み、
前記第２の充足率は、単位時間当たりの応じる確率を含み、
前記条件は、充足率閾値を含み、
前記第２の充足率が前記条件を満たすと判定する前記ステップは、前記第２の充足率が前記閾値より大きいと判定することを含む、
付記１１に記載の方法。
〔付記１３〕
前記第１の充足率は、前記第１のユーザにルーティングされた注文が前記第１のユーザによって応じられた回数と、前記第１のユーザにルーティングされた注文が前記第１のユーザによって応じられなかった回数と、の比較に基づいて決定され、
前記条件は、充足率閾値を含み、
前記第１の充足率が前記条件を満たさないと判定するステップは、前記第１の充足率が前記閾値より小さいと判定することを含む、
付記１１に記載の方法。
〔付記１４〕
前記第１の充足率は、前記第１のユーザにルーティングされた、前記アイテムに対する注文が前記第１のユーザによって応じられた回数と、前記第１のユーザにルーティングされた、前記アイテムに対する注文が前記第１のユーザによって応じられなかった回数と、の比較に基づいて決定される、付記１１に記載の方法。
〔付記１５〕
前記第１の充足率は、前記第１のユーザにルーティングされ、前記第１のユーザによって応じられた総量と、前記第１のユーザにルーティングされ、前記第１のユーザによって応じられなかった総量と、の比較に基づいて決定される、付記１１に記載の方法。
〔付記１６〕
前記第１の充足率は、前記第１のユーザにルーティングされ、前記第１のユーザによって応じられた前記アイテムの総量と、前記第１のユーザにルーティングされ、前記第１のユーザによって応じられなかった前記アイテムの総量と、の比較に基づいて決定される、付記１１に記載の方法。
〔付記１７〕
前記第１の充足率は、前記第１のユーザにルーティングされた、前記アイテムに対する特定の量の範囲の注文が前記第１のユーザによって応じられた回数と、前記第１のユーザにルーティングされた、前記アイテムに対する前記特定の量の範囲の注文が前記第１のユーザによって応じられなかった回数と、の比較に基づいて決定される、付記１１に記載の方法。
〔付記１８〕
前記第２の注文は第１の応答時間に関連付けられ、
前記第２の注文を受信するより先に、前記アイテムに対する第３のユーザからの第３の注文を前記少なくとも１つのサーバにより受信するステップであり、前記第３の注文は、価格が前記第２の注文の価格と等しく、前記第３の注文は、前記第１の応答時間より長い第２の応答時間に関連付けられている、前記ステップと、
少なくとも１つのサーバにより、前記注文帳において、前記第２の注文に関連付けられた前記第１の応答時間より長い、前記第３の注文に関連付けられた前記第２の応答時間に少なくとも部分的に基づいて、前記第２の注文を、前記第３の注文より優先して注文するステップと、を更に含み、
少なくとも１つのサーバにより前記取引コマンドを前記第２のユーザまで伝達する前記ステップは、前記少なくとも１つのサーバにより、前記アイテムに関するいかなる取引コマンドを前記第３のユーザに伝達するステップよりも先に行われ、前記伝達するステップは、前記注文帳において前記第２の注文が前記第３の注文より優先して注文されることに応答して行われる、
付記１１に記載の方法。
〔付記１９〕
第３の注文及び第４の注文を受信するステップと、
前記第３の注文の少なくとも一部分が、前記第１の注文の少なくとも一部分から独立していない確率を求めるステップと、
前記求められた、前記第３の注文の少なくとも一部分が、前記第１の注文の少なくとも一部分から独立していない確率に少なくとも部分的に基づいて、前記注文帳に記載されている前記第３の注文及び前記第４の注文を注文するステップと、
を更に含む、付記１１に記載の方法。
〔付記２０〕
命令が格納された非過渡的コンピュータ可読媒体であって、前記命令は、特定の取引者のワークステーションの少なくとも１つのプロセッサによって実行された場合に、前記少なくとも１つのプロセッサに対し、
アイテムに対する、第１の充足率及び第１の応答時間に関連付けられた第１の注文を受信するステップと、
前記第１の注文を受信した後に、前記アイテムに対する、第２の充足率及び第２の応答時間に関連付けられた第２の注文を受信するステップと、
前記特定の取引者の注文帳において、前記第１の注文に関連付けられた前記第１の充足率及び前記第１の応答時間と、前記第２の注文の前記第１の充足率及び前記第１の応答時間と、に少なくとも部分的に基づいて、前記第２の注文を、前記第１の注文より優先して注文するステップと、
前記注文帳において、前記第２の注文を、前記第１の注文より優先して注文することに応答して、前記第１の注文に対抗する、前記特定の取引者のいかなる注文のいかなる執行よりも前に、前記特定の取引者の注文を、前記第２の注文に対抗して執行されるようにするステップと、を指示する、
非過渡的コンピュータ可読媒体

Claims (19)

1. 特定の取引者のワークステーションに関連付けられた少なくとも１つのプロセッサであって、複数のコンピュータと電子通信ネットワークを介して電子通信する前記少なくとも１つのプロセッサと、
   命令が格納された少なくとも１つのメモリと、を備える装置であって、
   前記命令は、前記少なくとも１つのプロセッサによって実行された場合に、前記少なくとも１つのプロセッサに対し、
   アイテムに対する、第１の充足率及び第１の応答時間に関連付けられた第１の注文を、第１のコンピュータから受信するステップと、
   前記第１の注文を受信した後に、前記アイテムに対する、第２の充足率及び第２の応答時間に関連付けられた第２の注文を、第２のコンピュータから受信するステップであって、前記第１の充足率及び前記第２の充足率の少なくとも１つは、少なくとも１日の間の指定された継続時間における単位時間当たりの応じる確率として表されているステップと、
   前記特定の取引者の注文帳の電子データベースにおいて、前記第１の注文に関連付けられた前記第１の充足率及び前記第１の応答時間と、前記第２の注文に関連付けられた前記第２の充足率及び前記第２の応答時間と、に少なくとも部分的に基づいて、前記第２の注文を前記第１の注文より優先して注文するステップと、
   前記注文帳において前記第２の注文を前記第１の注文より優先して注文することに応答して、前記第１の注文に対抗する、前記特定の取引者のいかなる注文のいかなる執行よりも前に、前記特定の取引者の注文を、前記第２の注文に対抗して執行されるようにするステップと、
   特定のトレーダーの注文に対する取引コマンドの実行に関する通信のルーティングを、前記電子通信ネットワークのポートに割り当てるステップと、
   前記電子通信ネットワークの割り当てられたポートを介して通信をルーティングするため、特定のトレーダーの注文に対する取引コマンドの実行のための電子信号を生成するステップと、
   を実行させる、
   装置。
2. 前記第１の注文を受信するステップは、前記第１の充足率を受信することを含み、前記第２の注文を受信するステップは、前記第２の充足率を受信することを含み、
   前記第１の応答時間は、前記第１の注文を送信した第１のトレーダーによって数量の少なくとも一部が満たされるのにかかる時間量を表す第１の値を含み、
   前記第２の応答時間は、前記第２の注文を出した第２のトレーダーによって数量の少なくとも一部が満たされるのにかかる時間量を表す第２の値を含む、
   請求項１に記載の装置。
3. 前記第１の充足率は、前記第１の注文のプロバイダにルーティングされた注文が前記第１の注文の前記プロバイダによって応じられた回数と、前記第１の注文の前記プロバイダにルーティングされた注文が前記第１の注文の前記プロバイダによって応じられなかった回数と、の比較に基づいて決定される、請求項１に記載の装置。
4. 前記第１の充足率は、前記第１の注文のプロバイダにルーティングされた、前記アイテムに対する注文が前記第１の注文の前記プロバイダによって応じられた回数と、前記第１の注文の前記プロバイダにルーティングされた、前記アイテムに対する注文が前記第１の注文の前記プロバイダによって応じられなかった回数と、の比較に基づいて決定される、請求項１に記載の装置。
5. 前記第１の充足率は、前記第１の注文のプロバイダにルーティングされ、前記第１の注文の前記プロバイダによって応じられた総量と、前記第１の注文の前記プロバイダにルーティングされ、前記第１の注文の前記プロバイダによって応じられなかった総量と、の比較に基づいて決定される、請求項１に記載の装置。
6. 前記第１の充足率は、前記第１の注文のプロバイダにルーティングされ、前記第１の注文の前記プロバイダによって応じられた、前記アイテムの総量と、前記第１の注文の前記プロバイダにルーティングされ、前記第１の注文の前記プロバイダによって応じられなかった、前記アイテムの総量と、の比較に基づいて決定される、請求項１に記載の装置。
7. 前記第１の充足率は、前記第１の注文のプロバイダにルーティングされた、前記アイテムに対する特定の量の範囲の注文が前記第１の注文の前記プロバイダによって応じられた回数と、前記第１の注文の前記プロバイダにルーティングされた、前記アイテムに対する前記特定の量の範囲の注文が前記第１の注文の前記プロバイダによって応じられなかった回数と、の比較に基づいて決定される、請求項１に記載の装置。
8. 前記命令は、少なくとも１つのプロセッサによって実行された場合に、前記少なくとも１つのプロセッサに対し、
   前記第２の注文を受信するより先に、前記アイテムに対する第３のユーザからの第３の注文を前記少なくとも１つのプロセッサにより受信するステップであって、前記第３の注文は、前記第１の応答時間より長い第３の応答時間に関連付けられているステップと、
   少なくとも１つのサーバにより、前記注文帳において、前記第２の注文に関連付けられた前記第２の応答時間より長い、前記第３の注文に関連付けられた前記第３の応答時間に少なくとも部分的に基づいて、前記第２の注文を、前記第３の注文より優先して注文するステップと、
   少なくとも１つのサーバにより取引コマンドを第２のユーザまで伝達するステップと、を更に実行させ、
   前記伝達するステップは、前記少なくとも１つのサーバにより、前記アイテムに関するいかなる取引コマンドを前記第３のユーザに伝達するよりも先に行われ、
   前記伝達するステップは、前記注文帳において前記第２の注文が前記第３の注文より優先して注文されることに応答して行われ、
   前記第２の注文の価格は、前記第３の注文の価格と同じである、
   請求項１に記載の装置。
9. 前記命令は、前記少なくとも１つのプロセッサによって実行された場合に、前記少なくとも１つのプロセッサに対し、
   第３の注文及び第４の注文を受信するステップと、
   前記第３の注文の少なくとも一部分が、前記第１の注文の少なくとも一部分から独立していない確率を求めるステップと、
   前記求められた、前記第３の注文の少なくとも一部分が、前記第１の注文の少なくとも一部分から独立していない確率に少なくとも部分的に基づいて、前記注文帳に記載されている前記第３の注文及び前記第４の注文を注文するステップと、を更に実行させる、
   請求項１に記載の装置。
10. 少なくとも１つのサーバにより、アイテムに対する第１の注文を、第１のコンピュータから第１の時間に受信するステップであって、前記少なくとも１つのサーバは、複数のコンピュータと電子通信ネットワークを介して電子通信するステップと、
    前記少なくとも１つのサーバにより、前記アイテムに対する第２の注文を、第２のコンピュータから前記第１の時間より後の第２の時間に受信するステップであって、
    前記第１の注文は第１のユーザに関連付けられており、前記第２の注文は第２のユーザに関連付けられており、
    前記第１及び第２の注文は、関連付けられている価格が同じであり、
    前記第１の注文が受信された前記第１の時間において、前記第１の注文には第１の充足率が関連付けられており、
    前記第２の注文が受信された前記第２の時間において、前記第２の注文には第２の充足率が関連付けられており、
    前記第１の充足率及び前記第２の充足率の少なくとも１つは、少なくとも１日の間の指定された継続時間における単位時間当たりの応じる確率として表されているステップと、
    少なくとも１つのサーバにより、前記アイテムを買うか売る為のコマンドを受信するステップであって、前記コマンドは、それに関連付けられた条件を有するステップと、
    少なくとも１つのサーバにより、前記第１の注文に関連付けられた前記第１の充足率が前記条件を満たさないと判定するステップと、
    前記第１の注文が受信された前記第１の時間において前記第１の注文に関連付けられた前記第１の充足率が前記条件を満たさないと判定したことの結果として、少なくとも１つのサーバにより、前記第１の注文を無視し、前記第２の注文が受信された前記第２の時間において前記第２の注文に関連付けられた前記第２の充足率が前記条件を満たすかどうかを判定するステップと、
    少なくとも１つのサーバにより、前記第２の注文が受信された前記第２の時間において前記第２の注文に関連付けられた前記第２の充足率が前記条件を満たすと判定するステップと、
    前記第２の注文が受信された前記第２の時間において前記第２の注文に関連付けられた前記第２の充足率が前記条件を満たすと判定したことの結果として、少なくとも１つのサーバにより、前記第１の注文に関連するいかなる取引コマンドを伝達するよりも先に、前記第２の注文に関連付けられた取引コマンドを前記第２のユーザに伝達するステップと、
    前記第２のユーザに前記取引コマンドを伝達することに応答して、前記第２のユーザが前記取引コマンドに対抗する取引をしようとしているという通知を受信するステップと、
    特定のトレーダーの注文に対する取引コマンドの実行に関する通信のルーティングを、前記電子通信ネットワークのポートに割り当てるステップと、
    前記電子通信ネットワークの割り当てられたポートを介して通信をルーティングするため、特定のトレーダーの注文に対する取引コマンドの実行のための電子信号を生成するステップと、
    を含む方法。
11. 前記第１の注文を受信するステップは、前記第１の充足率を受信することを含み、
    前記第２の注文を受信するステップは、前記第２の充足率を受信することを含み、
    前記条件は、充足率閾値を含み、
    前記第２の充足率が前記条件を満たすと判定する前記ステップは、前記第２の充足率が前記充足率閾値より大きいと判定することを含む、
    請求項１０に記載の方法。
12. 前記第１の充足率は、前記第１のユーザにルーティングされた注文が前記第１のユーザによって応じられた回数と、前記第１のユーザにルーティングされた注文が前記第１のユーザによって応じられなかった回数と、の比較に基づいて決定され、
    前記条件は、充足率閾値を含み、
    前記第１の充足率が前記条件を満たさないと判定するステップは、前記第１の充足率が前記充足率閾値より小さいと判定することを含む、
    請求項１０に記載の方法。
13. 前記第１の充足率は、前記第１のユーザにルーティングされた、前記アイテムに対する注文が前記第１のユーザによって応じられた回数と、前記第１のユーザにルーティングされた、前記アイテムに対する注文が前記第１のユーザによって応じられなかった回数と、の比較に基づいて決定される、請求項１０に記載の方法。
14. 前記第１の充足率は、前記第１のユーザにルーティングされ、前記第１のユーザによって応じられた総量と、前記第１のユーザにルーティングされ、前記第１のユーザによって応じられなかった総量と、の比較に基づいて決定される、請求項１０に記載の方法。
15. 前記第１の充足率は、前記第１のユーザにルーティングされ、前記第１のユーザによって応じられた前記アイテムの総量と、前記第１のユーザにルーティングされ、前記第１のユーザによって応じられなかった前記アイテムの総量と、の比較に基づいて決定される、請求項１０に記載の方法。
16. 前記第１の充足率は、前記第１のユーザにルーティングされた、前記アイテムに対する特定の量の範囲の注文が前記第１のユーザによって応じられた回数と、前記第１のユーザにルーティングされた、前記アイテムに対する前記特定の量の範囲の注文が前記第１のユーザによって応じられなかった回数と、の比較に基づいて決定される、請求項１０に記載の方法。
17. 前記第２の注文は第１の応答時間に関連付けられ、
    前記第２の注文を受信するより先に、前記アイテムに対する第３のユーザからの第３の注文を前記少なくとも１つのサーバにより受信するステップであって、前記第３の注文は、価格が前記第２の注文の価格と等しく、前記第３の注文は、前記第１の応答時間より長い第２の応答時間に関連付けられているステップと、
    少なくとも１つのサーバにより、注文帳において、前記第２の注文に関連付けられた前記第１の応答時間より長い、前記第３の注文に関連付けられた前記第２の応答時間に少なくとも部分的に基づいて、前記第２の注文を、前記第３の注文より優先して注文するステップと、を更に含み、
    少なくとも１つのサーバにより前記取引コマンドを前記第２のユーザまで伝達するステップは、前記少なくとも１つのサーバにより、前記アイテムに関するいかなる取引コマンドを前記第３のユーザに伝達するよりも先に行われ、前記伝達するステップは、注文帳において前記第２の注文が前記第３の注文より優先して注文されることに応答して行われる、
    請求項１０に記載の方法。
18. 第３の注文及び第４の注文を受信するステップと、
    前記第３の注文の少なくとも一部分が、前記第１の注文の少なくとも一部分から独立していない確率を求めるステップと、
    前記求められた、前記第３の注文の少なくとも一部分が、前記第１の注文の少なくとも一部分から独立していない確率に少なくとも部分的に基づいて、注文帳に記載されている前記第３の注文及び前記第４の注文を注文するステップと、
    を更に含む、請求項１０に記載の方法。
19. 命令が格納された非一時的コンピュータ可読媒体であって、前記命令は、特定の取引者のワークステーションの少なくとも１つのプロセッサであって、複数のコンピュータと電子通信ネットワークを介して電子通信する前記少なくとも１つのプロセッサによって実行された場合に、前記少なくとも１つのプロセッサに対し、
    アイテムに対する、第１の充足率及び第１の応答時間に関連付けられた第１の注文を第１のコンピュータから受信するステップと、
    前記第１の注文を受信した後に、前記アイテムに対する、第２の充足率及び第２の応答時間に関連付けられた第２の注文を第２のコンピュータから受信するステップであって、前記第１の充足率及び前記第２の充足率の少なくとも１つは、少なくとも１日の間の指定された継続時間における単位時間当たりの応じる確率として表されているステップと、
    前記特定の取引者の注文帳の電子データベースにおいて、前記第１の注文に関連付けられた前記第１の充足率及び前記第１の応答時間と、前記第２の注文に関連付けられた前記第２の充足率及び前記第２の応答時間と、に少なくとも部分的に基づいて、前記第２の注文を前記第１の注文より優先して注文するステップと、
    前記注文帳において前記第２の注文を前記第１の注文より優先して注文することに応答して、前記第１の注文に対抗する、前記特定の取引者のいかなる注文のいかなる執行よりも前に、前記特定の取引者の注文を、前記第２の注文に対抗して執行されるようにするステップと、
    特定のトレーダーの注文に対する取引コマンドの実行に関する通信のルーティングを、前記電子通信ネットワークのポートに割り当てるステップと、
    前記電子通信ネットワークの割り当てられたポートを介して通信をルーティングするため、特定のトレーダーの注文に対する取引コマンドの実行のための電子信号を生成するステップと、
    を実行させる、
    非一時的コンピュータ可読媒体。

Images