図1を参照すると、一例示的実施形態によるシステム例100が示されている。システム100は、1つ以上のコンピューティングシステム(例えば、サーバ)101〜106を含んでよい。コンピューティングシステム101〜106は、本明細書では説明の為にサーバと称されてよい。しかしながら、サーバという用語の使用は非限定的であること、並びに、他のタイプのコンピューティングシステムが使用されてよいことを理解されたい。
各サーバ101〜106は、1つ以上のプロセッサと1つ以上のメモリとを含んでよく、1つ以上のデータベースを含んでよい。各サーバは、ネットワーク用のハードウェア/ソフトウェア/ファームウェアをベースとするインタフェースであって、サーバがネットワーク110に接続してネットワーク110経由の通信を行うことを可能にするインタフェースを1つ以上含んでよい。ネットワーク110は、パブリックネットワーク及び/又はプライベートネットワークを含んでよく、任意のタイプの技術をベースとする有線ネットワーク及び/又は無線ネットワークであってよい。ネットワーク110は又、バス式及び/又はバックプレーン式のアーキテクチャを含んでよい。ネットワーク110は、ルータ、スイッチ等を含む1つ以上の要素を含んでよい。ネットワーク110は、サーバ101〜106の少なくともそれぞれが互いに通信することを可能にするように構成されてよい。ネットワーク110は又、サーバ101〜106が、ネットワーク110上にあってよい、又は、図1に示されていないがネットワーク110経由のアクセスが可能である他のネットワーク上にあってよい、他のコンピューティングシステム(例えば、コンピューティングシステム150)と通信することを可能にするように構成されてよい。一例として、ネットワーク110は、例えば1つ以上のルータ、スイッチ等を介して、1つ以上の他のプライベートネットワーク及び/又はパブリックネットワークとインタフェースされるプライベートネットワークであってよく、これによって、例えば、サーバ101〜106のいずれかが、そのような他のネットワーク上の他のコンピューティングシステムと通信することが可能になる。サーバ101〜106のうちの1つ以上とネットワーク110とが、ユニキャスト通信、ブロードキャスト通信、及び/又はマルチキャスト通信をサポートするように構成されてよい。マルチキャスト通信はIPマルチキャストを含んでよいが、他のタイプのマルチキャストが使用されてもよい。マルチキャストは、信頼できるマルチキャストであっても、信頼できないマルチキャストであってもよい。当業者であれば理解されるように、サーバ101〜106及びネットワーク110について上述されたことは例に過ぎず、追加及び/又は他のサーバ/ネットワーク構成及び機能性が使用されてもよい。例えば、ネットワーク110に加えて、サーバ101〜106のうちの1つ以上が、追加のネットワーク用のハードウェア/ソフトウェア/ファームウェアをベースとするインタフェースであって、図1に示されていない1つ以上の他のパブリックネットワーク及び/又はプライベートネットワークにサーバが接続し、これらのネットワークを介して通信を行うことを可能にするインタフェースを1つ以上含んでもよい。
システム100内のサーバ101〜106のうちの1つ以上が、ハードウェア(例えば、プロセッサ構成、プロセッサ数、プロセッサ速度、メモリサイズ、メモリ速度等)、及び/又はシステムソフトウェア(例えば、オペレーティングシステム)、及び/又はネットワークインタフェース速度の観点において、同一の構成であってよく、且つ/又は、ほぼ同一の構成であってよい。同様に、サーバ101〜106のうちの1つ以上の、ネットワーク110経由で他の任意のサーバと通信する能力が同じであってよい。サーバ101〜106のうちの1つ以上が、同一ラック内、同一室内、同一建物内等に配置されてよい。更に、ネットワーク110を構成するネットワーク要素も、サーバ101〜106と同じ場所に配置されてよい。ここでも、追加及び/又は他の構成も可能である。例えば、各サーバは、性能が異なってよい。
システム100は、クラウドコンピューティングシステムと称されてよい。システム100は、システム100のリソースを1人以上の他のユーザ/カスタマ、例えば、ユーザA〜Fにリース又はレンタルする1つ以上のエンティティによって、所有されてよく、且つ/又は一部所有されてよく、且つ/又は保守/運用されてよい。ユーザA〜Fは、個々の人及び/又は会社であってよく、例えば、銀行、投資ファンド、商社等であってよい。代替及び/又は追加として、ユーザA〜Fのうちの1人以上が、システム100のリソースを所有してよい。一例として、サーバ101は、ユーザAにリースされるか、ユーザAが所有してよく、サーバ102は、ユーザBにリースされるか、ユーザBが所有してよく、サーバ103は、ユーザCにリースされるか、ユーザC所有してよく、サーバ104は、ユーザDにリースされるか、ユーザDが所有してよく、サーバ105は、ユーザEにリースされるか、ユーザEが所有してよく、且つ/又は、サーバ106は、ユーザFにリースされるか、ユーザFが所有してよい。一般に、各サーバ101〜106は、そのサーバのリソースにアクセスできる特定のユーザに割り当てられてよい。任意のユーザが、システム100内で、複数のサーバに関連付けられてよく、複数のサーバをリースされてよく、複数のサーバを所有してよい。一例によれば、システム100は、追加サーバがシステムに追加されてよいという点で拡張可能であってよく、それらのサーバは、ユーザA〜F及び/又は新規ユーザにリースされるか、所有されてよい。システム100は、1つ以上のサーバの追加及び/又は除去が他のユーザに影響しないように構成されてよい。別の例として、任意のサーバが、互いに関連付けされていない異なる複数のユーザにリース/レンタルされてよい。サーバは、ユーザのうちの1人によるサーバの使用が他のユーザに影響しないように、且つ、他のユーザによるサーバの使用がその1人のユーザに影響しないように構成されてよい。
一例によれば、システム100は、取引システム又はマッチングシステム、特に分散取引/マッチングシステムとして動作してよく、且つ/又は、そのように構成されてよく、これらのシステムは、ユーザA〜Fなどのユーザが互いに1つ以上のアイテムの取引及び/又は売買をすることを可能にする。システム100上で取引されるアイテムは、システムのユーザA〜Fのうちの1人以上が所有するものであってよい。代替及び/又は追加として、ユーザA〜Fのうちの1人以上が、本人及び/又は仲介業者及び/又は(例えば、アイテムを所有しうるエンティティの代わりに行動する)代理人であってよい。取引されるアイテムは、有形アイテム及び/又は無形アイテムを含んでよい。一例によれば、システム100は、例えば確定利付証券、普通株、外国為替等を含む、1つ以上の金融商品を取引するように構成されてよい。従って、各ユーザA〜Fは、システム100を使用して、システムの1人以上の他のユーザと、1つ以上の金融商品を取引することが可能である。当業者であれば理解されるように、不動産(例えば、土地、家屋、及び/又は建物)、消費者製品(例えば、自動車、電子機器)、チケット(例えば、航空券、コンサートチケット)等のような、他のタイプのアイテムも、システム100を介して取引及び/又は売買されてよい。当業者であれば理解されるように、取引システム又はマッチングシステムに対する追加及び/又は代替として、システム100は、他のタイプのシステムとして動作してよく、構成されてよい。
又、サーバ101〜106のうちの1つ以上が、そのサーバ上で実行される1つ以上のアプリケーション120a〜fを含んでよい(例えば、メモリ内に格納済みであってよい)。一例として、アプリケーション120a〜fは、本明細書ではマッチングエンジンと称されてよい。ただし、他のタイプ、及び/又は追加のタイプのアプリケーションも可能である。マッチングエンジン120a〜fは、ユーザA〜Fが互いの間でアイテムの売買取引を行うことを可能にしてよい。マッチングエンジン120a〜fは、サーバ101〜106上で実行される、ソフトウェア及び/又はファームウェア及び/又はハードウェアをベースとするアプリケーションであってよい。各サーバは、1つ及び/又は複数のマッチングエンジンを含んでよい。各サーバは、追加アプリケーション及び/又は他のアプリケーションを含んでよい。各サーバ101〜106のマッチングエンジンは、同一且つ/又はほぼ同一のアプリケーションであってよく、異なるアプリケーションであってもよい。例えば、各マッチングエンジンは、同様のマッチングアルゴリズムを実行してよい。別の例として、マッチングエンジンが異なれば、実行されるマッチングアルゴリズムも異なってよい。マッチングエンジン120a〜fは、システム100を所有/運用するエンティティによって開発/保守されてよい。又、そのようなエンティティは、各サーバで実行される他のアプリケーション及び/又は追加のアプリケーションも開発/保守してよい。
又、各サーバは、ユーザA〜Eなどのユーザに関連付けられて各サーバ上で実行される1つ以上のアプリケーション122a〜eを含んでよい(例えば、メモリ内に格納済みであってよい)。一例として、アプリケーション122a〜eは、本明細書では取引アプリケーションと称されてよい。ただし、他のタイプ、及び/又は追加のタイプのアプリケーションも可能である。別の例によれば、1つ以上の取引アプリケーション(例えば、アプリケーション122f)がサーバ101〜105上で実行されなくてよい。その代わりに、このアプリケーションは、サーバ(例えば、サーバ106)に接続されたコンピューティングシステム(例えば、コンピューティングシステム130)上で実行されてよい。コンピューティングシステム130は、サーバ106及び/又は他のシステム100の要素と同じ場所に配置されてもされなくてもよい。コンピューティングシステム130とサーバ106は、1つ以上のプライベートネットワーク及び/又はパブリックネットワーク131を介して通信してよい。別の例として、コンピューティングシステム130とサーバ106は、ネットワーク110を介して通信してよい。一例によれば、コンピューティングシステム130は、システム100を所有及び運用するエンティティが所有及び運用してよい。別の例によれば、コンピューティングシステム130は、このコンピューティングシステムが接続されているサーバに関連付けられたユーザ(ここではユーザF)が所有及び運用してよい。当業者であれば理解されるように、これらの構成は例に過ぎず、他の構成、及び/又は追加の構成も可能である。例えば、各サーバ101〜105/コンピューティングシステム130は、1つ及び/又は複数の取引アプリケーションを含んでよい。各サーバ101〜105/コンピューティングシステム130は又、ユーザA〜Fなどのユーザに関連付けられた追加のアプリケーション及び/又は他のアプリケーションを含んでもよい。
一例によれば、各取引アプリケーション122a〜fは、それぞれのマッチングエンジン120a〜fと相互通信することにより、システム100のユーザA〜Fがアイテムを取引することを可能にするように構成されてよい。各取引アプリケーション122a〜fは、取引ストラテジを実行することにより、(例えば、それぞれのユーザA〜Fの代理として)取引注文(例えば、ビッド、オファー、ヒット、テイク)を生成する自動取引アルゴリズムであってよい。任意のサーバにおける各取引アプリケーションが、1つ以上のアイテムを取引するように構成されてよい。各取引アプリケーション122a〜fは、ソフトウェア及び/又はファームウェア及び/又はハードウェアをベースとするアプリケーションであって、サーバ101〜105/コンピューティングシステム130のそれぞれにおいて実行されるアプリケーションであってよい。各取引アプリケーションは、他の取引アプリケーションと異なるものであってよく、それぞれのサーバが割り当てられているユーザが開発してよい。例えば、ユーザAは、取引アプリケーション122aを開発し、このアプリケーションを(例えば、管理アプリケーションを用いて)サーバ101にロードするか、ロード済みにし、サーバ101でこのアプリケーションを実行してよい。同様に、ユーザBは、取引アプリケーション122bを開発し、このアプリケーションを(例えば、管理アプリケーションを用いて)サーバ102にロードするか、ロード済みにし、サーバ102でこのアプリケーションを実行してよい。更に、且つ/又は別の例として、取引アプリケーション122a〜fは、システム100を所有/運用するエンティティから提供される汎用アプリケーション(APIなど)であってよい。各インスタンスでは、それぞれのユーザA〜Fが、各自のニーズを満たす為に、(例えば、それぞれのサーバから離れているコンピューティングシステムを介するか、管理アプリケーションを介するか、且つ/又は、それぞれのサーバに接続されたユーザインタフェース装置(キーボード、マウス等)を介するなどしてユーザがインタフェースするAPIを用いて)それぞれのアプリケーションをカスタマイズしてよい。当業者であれば理解されるように、これらの構成は例に過ぎず、他の構成、及び/又は追加の構成も可能である。例えば、取引アプリケーション122a〜fが、取引ストラテジを実行する自動取引アルゴリズムである代わりに、取引アプリケーション122a〜fのうちの1つ以上が、それぞれのユーザがシステム100にインタフェースして注文を生成することを可能にしてよい。例えば、それぞれのユーザが(離れているコンピューティングシステムを介するか、且つ/又は、それぞれのサーバに接続されたユーザインタフェース装置(キーボード、マウス等)を介するなどして)サーバのそれぞれのマッチングエンジンに対して注文を手動でサブミットすることが可能であってよい。
前述のように、各サーバにおいて、マッチングエンジン120a〜fは、それぞれの取引アプリケーション122a〜fと共に、ユーザA〜Fが互いにアイテムを取引することを可能にしてよい。一例として、マッチングエンジンの1つのインスタンスが、ある特定のアイテム(例えば、10年債)を取引するように構成されてよい。従って、任意のユーザA〜Fが異なる複数のアイテム(例えば、5年債と10年債)を取引しようとする場合、それぞれのサーバにおいてマッチングエンジン120の複数のインスタンスが実行されてよく、各インスタンスは、それぞれの取引アプリケーション122の1つ以上のインスタンスと通信する。別の例として、それぞれの取引アプリケーションの1つ以上のインスタンスと通信するマッチングエンジンの1つのインスタンスが、複数のアイテムを取引するように構成されてよい。当業者であれば理解されるように、これらは例に過ぎず、他の構成、及び/又は追加の構成も可能である。例えば、或るサーバが異なる複数のユーザによって使用されている場合、このサーバは、同じアイテムの取引を異なる複数のユーザと行うように構成された、マッチングエンジンの複数のインスタンスを有してよい。説明の都合上に過ぎないが、マッチングエンジン120は、1つのアイテムの取引を可能にするものとして説明される。
一例によれば、或るアイテムを取引しようとする或るユーザA〜Fに対しては、それぞれのサーバのマッチングエンジン120a〜fが、そのサーバ上で、そのアイテムに関する注文帳124a〜fを保守してよく、又は保守するように構成されてよい。一例として、それぞれのサーバのメモリ内で、それぞれの注文帳が保守されてよい。例えば、ユーザA〜Eのそれぞれが或るアイテムを取引しようとする場合、各サーバ101〜105は、そのアイテムに関する注文帳124a〜eを有してよい。ユーザFがそのアイテムを取引しようとしないのであれば、サーバ106は、そのアイテムに関する注文帳を有さなくてよい。このようにして、或るアイテムに関する注文帳が複数のサーバにまたがって分散又は非集中化されてよい。同様に、ユーザA〜Eのそれぞれが第2のアイテムも取引しようとする場合は、それぞれのサーバ101〜105のマッチングエンジン120a〜eも、そのサーバ上で、第2のアイテムに関する第2の注文帳を保守してよい。当業者であれば理解されるように、追加及び/又は他の注文帳構成も可能である。
更なる例によれば、システム100を介して取引されてよいアイテムごとに、ネットワーク100上のポート(例えば、インターネットプロトコル(IP)ポート)又はチャネル等が割り当てられてよい。例えば、第1のアイテムにポート「x」が割り当てられてよく、第2のアイテムにポート「y」が割り当てられてよく、以降も同様であってよい。ここで詳述されるように、第1のアイテムに関する、ネットワーク110経由のサーバ101〜106間の通信の一部又は全てがポート「x」を介して行われてよく、同様に、第2のアイテムに関する、ネットワーク110経由のサーバ101〜106間の通信の一部又は全てがポート「y」を介して行われてよい。更なる例によれば、或るユーザ、例えばAが第1のアイテム及び第2のアイテムを取引しようとする場合は、サーバ101/マッチングエンジン120aが、メッセージ/コマンド/情報/データの送信及び/又は受信(及び/又はリスン、モニタリング等)を、ポート「x」及びポート「y」において行うように構成されてよい。このようにして、ユーザAは、(例えば、取引アプリケーション122aを用いて)2つのアイテムに関する情報/データの送信/受信を行ってよい。同様に、例えば、ユーザAが第1のアイテムを取引しようとするが第2のアイテムを取引しない場合は、サーバ101/マッチングエンジン120aが、メッセージ/コマンド/情報/データの送信及び/又は受信(及び/又はリスン、モニタリング等)を、ポート「x」において行い、ポート「y」においては行わないように構成されてよい。このようにして、例えば、サーバ101/ユーザAは、関心の対象ではない第2のアイテムに関するメッセージ/コマンド/情報/データを受信しないことを選択してよい。同様に、ユーザAが(例えば、取引アプリケーション122aを用いて)第2のアイテムに関する情報を後で受信しようとする場合は、サーバ101/マッチングエンジン120aが、メッセージの送信及び/又は受信(及び/又はリスン、モニタリング等)をポート「y」において行うように構成されてよい。一例によれば、取引アプリケーション122a〜fが(おそらくはユーザ制御により)どのアイテムが取引され、且つ/又は、どのアイテムが取引されないかを判定してよく、このようにして、例えば、どのポートがモニタリングされるか、並びに、どのアイテムに関して注文帳が保守されるかについて、それぞれのサーバ/マッチングエンジンの構成を制御してよい。別の例として、ユーザが(例えば、それぞれのサーバから離れているコンピューティングシステムを介するか、管理アプリケーションを介するか、且つ/又は、それぞれのサーバに接続されたユーザインタフェース装置(キーボード、マウス等)を介するなどしてユーザがインタフェースするAPIを用いて)どのポートがモニタリングされるか、並びに、どのアイテムに関して注文帳が保守されるかについて、それぞれのサーバ/マッチングエンジンの構成を制御してよい。
システム100の一動作例によれば、或るユーザ/取引アプリケーション、例えば、ユーザA/取引アプリケーション122aが、或るアイテム、例えば、アイテム「w」を取引することに関心がある場合、ユーザA/取引アプリケーション122aは、アイテム「w」に対するビッド注文又はオファー注文を生成してよい(この注文は価格及び/又はサイズを含んでよい)。取引アプリケーション122aは、この注文をマッチングエンジン120aに転送してよく、マッチングエンジン120aは、この注文を注文帳124a(即ち、サーバ101にある、アイテム「w」に関する注文帳)に記載してよい。この注文は、図1では、注文帳124a内の注文140として示されている。システム100の一動作例によれば、ユーザAが注文140を生成したので、マッチングエンジン120aが、注文140に対抗する注文の執行の管理(例えば、注文140に対抗する逆注文(contra−orders)のマッチング)を行う役割であってよい。システム100の更なる動作例によれば、マッチングエンジン120aは、注文140を、アイテム「w」に対して割り当てられたポートからネットワーク110経由でマルチキャストしてもよい。マルチキャストされる注文は、この注文がユーザA/取引アプリケーション122a/マッチングエンジン120a及び/又はサーバ101から発せられたことを意味する何らかの明示(designation)を含んでよい。システム100上の他のユーザ/サーバのそれぞれがアイテム「w」に対して関心を有してよく、従って、そのアイテムに関するポート上での受信を行うように構成されている場合は、それぞれのマッチングエンジンが注文140を受信し、この注文を、そのアイテムに関するそれぞれの注文帳に記載してよい。例えば、ユーザB/取引アプリケーション122b及びユーザC/取引アプリケーション122cがアイテム「w」に対して関心を有してよく、従って、マッチングエンジン120b及び120cが、注文140を受信し、この注文を(図1において140’及び140”として示されている)それぞれの注文帳124b及び124cに記載するように構成されてよい。同様に、マッチングエンジン120b及び120cは、この注文がユーザA/取引アプリケーション122a/マッチングエンジン120a及び/又はサーバ101から発せられたことを意味する何らかの明示を記録してよい。それぞれのマッチングエンジン120b及び120cも、注文140に関する情報を、それぞれの取引アプリケーション122b及び122c及び/又はユーザB及びCに転送してよい。注文140はユーザB〜C/取引アプリケーション120b〜cに知られることになってよいが、この注文の出所(即ち、ユーザAの身元)は、システム100が匿名のマッチングシステムかどうかに応じて、知られることになってもならなくてもよい。
同様に、ユーザB/取引アプリケーション122bがアイテム「w」に対する注文を生成する場合、取引アプリケーション122bは、この注文をマッチングエンジン120bに転送してよく、マッチングエンジン120bは、この注文を注文帳124b(即ち、サーバ102にある、アイテム「w」に関する注文帳)に記載してよい。この注文は、図1では、注文帳124b内の注文142として示されている。ユーザBが注文142を生成したので、マッチングエンジン120bが、注文142に対抗する注文の執行の管理(例えば、注文140に対抗する逆注文のマッチング)を行う役割であってよい。マッチングエンジン120bは、注文142を、アイテム「w」に対して割り当てられたポートからネットワーク110経由でマルチキャストしてもよい。マルチキャストされる注文は、この注文がユーザB/取引アプリケーション122b/マッチングエンジン120b及び/又はサーバ102から発せられたことを意味する何らかの明示を含んでよい。システム100上の他のユーザ/サーバのそれぞれがアイテム「w」に対して関心を有してよく、従って、そのアイテムに関するポート上での受信を行うように構成されている場合は、それぞれのマッチングエンジンが注文142を受信し、この注文を、そのアイテムに関するそれぞれの注文帳に記載してよい。例えば、前述のように、ユーザA/取引アプリケーション122a及びユーザC/取引アプリケーション122cがアイテム「w」に対して関心を有している為、マッチングエンジン120a及び120cは、注文142を受信し、この注文を(図1において142’及び142”として示されている)それぞれの注文帳124a及び124cに記載してよい。同様に、マッチングエンジン120a及び120cは、この注文がユーザB/取引アプリケーション122b/マッチングエンジン120b及び/又はサーバ102から発せられたことを意味する何らかの明示を記録してよい。それぞれのマッチングエンジン120a及び120cも、注文142に関する情報を、それぞれの取引アプリケーション122a及び122c及び/又はユーザA及びCに転送してよい。
システム100の更なる動作例によれば、ユーザA/取引アプリケーション122aは、注文140の全て又は一部を後で取り消す場合には、この注文に対する取り消しコマンドを生成してよく、このコマンドはマッチングエンジン120aに転送されてよい。そのマッチングエンジン120aは、この注文を自身の注文帳124aから取り消してよく、又、取り消しコマンドを、アイテム「w」に対して割り当てられたポートからネットワーク110経由でマルチキャストしてもよい。取り消しコマンドは、取り消しコマンドがどの注文まで参照するかを他のサーバが知ることができるように、取り消しコマンドがユーザA/取引アプリケーション122a/マッチングエンジン120a及び/又はサーバ101から発せられたことを意味する何らかの明示を含んでよい。他のユーザ/サーバのそれぞれがアイテム「w」に対して関心を有してよく、従って、そのアイテムに関するポート上での受信を行うように構成されている場合は、それぞれのマッチングエンジンが取り消しコマンドを受信し、それぞれの注文を、そのそれぞれの注文帳から取り消してよい。例えば、マッチングエンジン120b〜cは、取り消しコマンドを受信し、注文140を注文帳124b〜cから取り消してよい。マッチングエンジン120b〜cは又、注文140が無効になったことを取引アプリケーション122b〜c及び/又はユーザB及びCに通知してよい。
Aからのビッド/オファー注文140が取り消されていないと仮定すると、ユーザB/取引アプリケーション122bは、この注文に対抗する取引コマンド/逆注文/反対注文、例えば、ヒット/テイクを生成してよい(ヒット/テイクコマンドは価格及びサイズを含んでよい)(別の例として、取引コマンドは、(例えば、特定の価格で)注文140とクロス/マッチするビッド又はオファーであってよい)。取引アプリケーション122bは、取引コマンドをマッチングエンジン120bに転送してよく、マッチングエンジン120bは、自身の注文帳124bにおいてマッチする注文を検索してよく、且つ、このコマンドが少なくともユーザAからの注文140とマッチすることを認識/判定してよい(マッチングエンジン120bは、注文142がユーザBから発せられたことを認識していれば、注文142に対して取引コマンドをマッチングさせようとしなくてよい)。これに対して、マッチングエンジン120bは、取引コマンドを、アイテム「w」に対して割り当てられたポートからネットワーク110経由でマルチキャストしてよい。この取引コマンドが、例えば、ユーザB/取引アプリケーション122b/マッチングエンジン120b/及び/又はサーバ102から発せられたことを意味する何らかの明示を追加することに加えて、取引コマンドは、ユーザA/取引アプリケーション122a/サーバ101/及び/又はマッチングエンジン120aに対して明確にタグ付け/指定/仕向けされてよく、これは、前述のように、マッチングエンジン120aが、ユーザA/サーバ101から発せられる注文に対抗する執行の役割であってよい為である。当業者であれば理解されるように、マッチングエンジン120aが対抗する執行の役割であってよい注文に取引コマンドが対抗していることを、マッチングエンジン120aに通知する為に、他の手段が用いられてよい。システム100の一動作例によれば、他のサーバ/マッチングエンジン(例えば、アイテム「w」に対して割り当てられたポートにおいてリスンしているサーバ/マッチングエンジン)は、マルチキャストされた取引コマンドを受信してよく、ユーザA/取引アプリケーション122a/サーバ101/及び/又はマッチングエンジン120aが指定されていると認識されたコマンドは無視してよい。システム100の別の動作例によれば、そのようなサーバ/マッチングエンジンは、マルチキャストされた取引コマンドを受信し、取引の可能性をそれぞれの取引アプリケーション及び/又はユーザに通知してよい。一例によれば、実際の取引コマンドは暗号化されてよい。
更なる例によれば、ユーザBのものではない追加注文が注文帳124bにあり、ユーザB/取引アプリケーション122bからの取引コマンドが、注文140を超えるサイズであり、且つ/又は、従って、これらの他の注文と対抗する場合、マッチングエンジン120bは、(それらの追加注文を担当するサーバ等に対してタグ付けされた)追加の取引コマンドを、アイテム「w」に対して割り当てられたポートからネットワーク110経由でマルチキャストしてもよい。別の代替として、マッチングエンジン120bは、ユーザA/取引アプリケーション122a/サーバ101/及び/又はマッチングエンジン120aに対してタグ付けされた同じ取引コマンドを使用してよく、更に、この取引コマンドを、追加注文を担当するサーバ等に対してタグ付けしてよい。当業者であれば理解されるように、他の変形も可能である。
サーバ101/マッチングエンジン120aは、取引コマンドを受信した時点で、そのコマンドがサーバ101/マッチングエンジン120aに対してタグ付けされていることを認識することになる。マッチングエンジン120aは、次に、注文140がまだ使用可能かどうか(例えば、取り消されていないかどうか、且つ/又は、他のユーザによって対抗して執行されていないかどうか、まだ注文帳124aに記載されているかどうか)を判定してよい。注文140がまだ使用可能であれば、マッチングエンジン120aは、注文140を自身の注文帳124aから削除することにより(又は、注文140の全てに対抗して執行されるわけではない場合には、注文帳における注文140の使用可能量を減らすことにより)、注文140に対抗する取引コマンドを執行してよい。マッチングエンジン120aは又、取引アプリケーション122a及び/又はユーザAと通信して、注文140に対抗して執行されたことを通知してもよい。更に、マッチングエンジン120aは、取引確認メッセージを、アイテム「w」に対して割り当てられたポートからネットワーク110経由でマルチキャストしてよい。確認メッセージは、実際に対抗して執行された注文140の量に関する通知を含んでよい。確認メッセージは、ユーザB/取引アプリケーション122b/マッチングエンジン120b/及び/又はサーバ102に対して明確にタグ付けされてよい。マッチングエンジン124bは、確認メッセージを受信した時点で、注文140(又はその一部)を自身の注文帳124bから削除してよく、又、マッチした注文を、ユーザB及び/又は取引アプリケーション122bに通知してよい。ユーザBに加えて、アイテム「w」に対して関心を有する他の全てのユーザ/サーバ/マッチングエンジンが、確認メッセージを受信してよく、このことは、それぞれのマッチングエンジンが注文140(又はその一部)を自身の注文帳から削除することを引き起こす。又、そのようなマッチングエンジンは、マッチした注文を、それぞれのユーザ及び/又は取引アプリケーションに通知してよい。従って、マッチングエンジン120cは、注文140を自身の注文帳124cから削除してよく、又、取引アプリケーション122c及び/又はユーザCに通知してよい。別の例及び/又は追加の例によれば、マッチングエンジン120aは、確認メッセージをマルチキャストすることに加えて、他の何らかのコマンド(取り消しコマンドなど)をマルチキャストすることにより、(エンジン120cのような)他のマッチングエンジンが注文140を自身の注文帳から削除することを引き起こしてよい。当業者であれば理解されるように、他のコマンドシーケンス及び/又は追加のコマンドシーケンスが使用されてよい。
別の例として、マッチングエンジン120aが、上述のように、ユーザBから取引コマンドを受信した時点で、注文140が使用可能のままではない(例えば、取り消されているか、且つ/又は、既に他のユーザによって対抗して執行されている)と判定した場合、マッチングエンジン120aは、注文140に対する取り消しメッセージ、及び/又は、取引の未確認を明確に示すメッセージ、及び/又は、取引が失敗したこと、及び/又は、取引が完了しなかったこと等をマルチキャストしてよい(これらは、ユーザB/取引アプリケーション122b/マッチングエンジン120b/及び/又はサーバ102に対して明確にタグ付けされてよい)。いずれにせよ、メッセージは、注文140をそれぞれの注文帳から削除することに適用可能な全てのマッチングエンジンに対して作用するものであってよい。ここでも、それぞれの取引アプリケーション及び/又はユーザに対しては、それぞれのマッチングエンジンから、コマンド140がもはや使用可能ではないことが通知されてよい。取引アプリケーション122b及び/又はユーザBに対しては、取引が失敗したことが明確に通知されてよい。
別の例によれば、マッチングエンジン120aが、上述のように、注文140がまだ使用可能であると判定してよく、その後、マッチングエンジン120aは、最初に取引アプリケーション122a及び/又はユーザAと通信して、注文140に対抗する執行の要求がまだあるかどうかを判定してよい。もしあれば、マッチングエンジン120aは、確認メッセージを生成すること等に関して上述のように処理を進めてよい。別の例として、取引アプリケーション122a及び/又はユーザAは、注文140に対抗する執行の要求がまだあることを通知してよいが、その要求が注文140の使用可能サイズより小さい(即ち、取引コマンドが要求するサイズより小さい)サイズに対する要求であることを通知してよい。ここでも、マッチングエンジン120aは、確認メッセージを生成すること等に関して上述のように処理を進めてよく、メッセージは、例えば、対抗して執行された注文140のサイズを通知する。代替として、ユーザA及び/又は取引アプリケーション122aが注文140に対抗する執行の要求をもはや有してない場合、マッチングエンジン120aは、注文140を自身の注文帳124aから削除してよく、その後、取り消しメッセージ及び/又は未確認メッセージを生成することに関して上述のように処理を進めてよく、結果として注文140は他の注文帳から削除される。ここでも、他のサーバにおけるそれぞれの取引アプリケーション/ユーザに対しては、それぞれのマッチングエンジンから、コマンド140がもはや使用可能ではないことが通知されてよい。これらに対しては又、注文140がペンディングである間、この注文のそれぞれの発信者(即ち、ユーザA)がもはやその注文に対抗する執行を要求していないことが通知されてよい。当業者であれば理解されるように、注文140に対抗する執行又は不執行に関する他のメッセージフロー及び/又は追加のメッセージフローも可能である。
上述の動作例の更なる態様によれば、例えば、ユーザC/取引アプリケーション122cが、ここで論じられているユーザB/取引アプリケーション122bとほぼ同じタイミングで注文140に対抗する取引コマンドを生成した場合、マッチングエンジン120cは、マッチングエンジン120bと同様の方法で、取引コマンドをネットワーク110経由でマルチキャストしてよい。そのようなイベントにおいては、マッチングエンジン120aは、注文140に対抗する2つの取引コマンドを(1つはユーザBから、1つはユーザCから)受信する可能性があり、それぞれは必然的に、いずれが先にサーバ101に到達するかに応じて、一方が他方より先に待ち行列に入ることになる。ここでも、マッチングエンジン120aは、ユーザA/サーバ101から発せられる注文(ここでは、例えば、注文140)に対抗する執行を管理する役割であってよい為、マッチングエンジン120aは、(ユーザB及びユーザCの両方が注文140のフルサイズを執行しようとしたと仮定すれば)いずれが先にサーバ101に到達したかに応じて、ユーザB及びユーザCのうちのいずれか一方にのみ対抗して注文140を執行してよい。マッチングエンジン120aは、例えば、他の取引コマンドに対抗する未確認を送信してよい。別の例として、ユーザB及びユーザCの取引コマンドは、注文140が両方に応じるのに十分なサイズではない場合は、一方の取引コマンドがフルに執行されてよく、他方の取引コマンドが一部のみ執行されてよい。当業者であれば理解されるように、他の変形も可能である。
当業者であれば理解されるように、システム100の上述の動作例は一例であり、他の動作例及び/又は追加の動作例も可能である。例えば、或るアイテムに対し、ネットワーク100上の複数のポート又はチャネル等が割り当てられてよい。例えば、或るアイテムに対し、1つのポートが、そのアイテムに対するビッドのみをマルチキャストすることに使用されてよく、別のポートが、そのアイテムに対するオファーのみをマルチキャストすることに使用されてよく、別のポートが、そのアイテムに対する取引コマンド/逆注文/反対注文(例えば、ヒット/テイク)のみをマルチキャストすることに使用されてよく(或いは、1つのポートがヒットに、別のポートがテイクに使用されてよく)、別のポートが、そのアイテムに対する取引確認メッセージをマルチキャストすることに使用されてよく(或いは、例えば、1つのポートがヒットに対抗する取引確認に、別のポートがテイクに対抗する取引確認に使用されてよく)、別のポートが、そのアイテムに対する取引未確認メッセージをマルチキャストすることに使用されてよく(或いは、例えば、1つのポートがヒットに対抗する未確認に、別のポートがテイクに対抗する未確認に使用されてよく)、別のポートが、そのアイテムに対するビッドの取り消しメッセージをマルチキャストすることに使用されてよく、且つ/又は、別のポートが、そのアイテムに対するオファーの取り消しメッセージ等をマルチキャストすることに使用されてよく、これには、他のメッセージの為のポートを含む、これらの他の任意の組み合わせが含まれてよい。ここでも、他の変形も可能である。
更なる例示的特徴によれば、システム100は、ドロップコピーの生成を不要にしてよい。例えば、ここで説明されたように取引確認メッセージを生成するマッチングエンジン120aにおいて、例えば、他のマッチングエンジン120b〜fが、場合によっては、このメッセージを受信し、それぞれの注文帳124b〜fを更新することに加えて、ネットワーク110に接続された(コンピューティングシステム150として示されている)他のコンピューティングシステムもこれらのメッセージを受信してよい。これらの他のコンピューティングシステムは、システム100を使用してアイテムを取引しようとするユーザ/カスタマに関連付けられても関連付けられなくてもよい。例えば、コンピューティングシステム150は、本明細書に記載のユーザAとユーザBとの間のトランザクション例のように、トランザクションをクリアできるクリアリングハウスに関連付けられてよい。
システム100の更なる例示的特徴によれば、例えば、取引アプリケーション(例えば、アプリケーション122e)が、例えば、或るアイテムに対して市場外価格でのビッド及び/又はオファーのサブミットを開始した為、取引アプリケーション122eを停止して、場合によってはそれらのビッド及びオファーを市場から除去することが必要である場合には、サーバ105をオフラインにしてよい。サーバ105をオフラインにすることは、例えば、(管理者からのコマンドによるなどして)サーバ全体をオフラインにすること、マッチングエンジン120eをシャットダウン/停止/一時停止すること、マッチングエンジン120e/サーバ105が、そのアイテムに関連付けられたポートでのリスン/受信/送信をもう行わないようにすること等を含んでよい。特に、各アクションは、取引アプリケーション122eが注文のサブミットをもう行えないようにしてよい。同様に、マッチングエンジン120eは、取引アプリケーション122eからサブミットされた注文に対抗する取引コマンドの執行を管理する役割である為、上述の各アクションは、マッチングエンジン120eがそのようなことをもう行えないようにする。例えば、マッチングエンジン120e/サーバ105が、そのアイテムに関連付けられたポートでのリスン/受信をもう行わないようにすると、マッチングエンジン120eは、取引コマンドを受信しなくなる。当業者であれば理解されるように、これらは例に過ぎず、システム100の他の例示的特徴及び/又は追加の例示的特徴も可能である。
外国為替取引
外国為替(「FX」)の取引では、市場が複数のユーザで構成されると見なされてよく、それらのユーザのうちの1人以上が流動性プロバイダ(「プロバイダ」)と見なされてよく、それらのユーザのうちの1人以上が流動性テイカー(「テイカー」)と見なされてよい。当業者であれば理解されるように、ユーザは、プロバイダとテイカーの両方であってよい。プロバイダは、FX商品に対する1つ以上の注文、例えば、FX商品に対するビッド及び/又はオファーをサブミット又はストリーミングすることにより、1つ以上のFX商品に対する1つ以上の取引に応じてよく、各注文は、例えば、価格及びサイズを有する。各注文は、1人以上のテイカーに対して示されるか使用可能にされてよい。これに対して、テイカーは、買い取引コマンド又は売り取引コマンド、例えば、オファーのテイク又はビッドのヒットをサブミットすることにより、注文に対抗する執行を試みてよい(別の例として、テイカーは、ビッド又はオファー等をサブミットすることにより、注文に対抗する執行を試みてよい)。取引コマンドは、指定された価格及びサイズを含んでよい。取引コマンドのサイズは、対抗する執行がなされる、対応する注文と同じサイズであってよく、或いは、より小さいサイズに対してであってもよい。注文に対抗する取引コマンドがサブミットされると、このコマンドは、注文をサブミットしたプロバイダに送信/ルーティングされてよい。以下では、「セカンドルック」と称されてよいプロセスが行われてよい。セカンドルックに従って、注文がまだ使用可能であれば、その注文に対抗して取引コマンドを執行するよりむしろ、その注文をサブミットしたプロバイダに、取引をまだ行うかどうかを決定するセカンドチャンスを与えられてよい。プロバイダは、取引コマンドを受信したら、「済み(done)」コマンドで応答してよく、これは、例えば、サブミットされた注文に従ってプロバイダが応じた取引に対してプロバイダがまだ取引を行うことを意味する。「済み」コマンドはサイズを含んでよく、これは、取引コマンドのサイズに対応してよく、或いは、より小さいサイズに対してであってもよい。「済み」コマンドの結果として、注文に対抗して取引コマンドが執行されてよく、それによって、対応するプロバイダとテイカーとの間で取引が執行されてよい。別の代替として、プロバイダは、テイカーの取引コマンドに対して「否/中止(no/not done)」コマンドで応答してよく、これは、例えば、注文で指定されたようにプロバイダが応じた取引に対してプロバイダがもう取引を行わないことを意味する。この場合、取引コマンドは注文に対抗して執行されなくてよく、対応するプロバイダとテイカーとの間で取引が執行されなくてよい。第3の代替として、プロバイダは、取引コマンドに対して全く応答しなくてよく、或いは、取引コマンドに(「済み」又は「中止」コマンドで)応答することに時間をかけすぎてよい。ここで、テイカーは、取引コマンドを撤回するか取り消してよい。プロバイダが「済み」コマンドで応答する前に取引コマンドが撤回されたと仮定すると、取引コマンドは、注文に対抗して執行されなくてよく、対応するプロバイダとテイカーとの間で取引が執行されなくてよい。最後の2つのケースでは、テイカーは、まだ取引を執行しようとするのであれば、別の注文に対抗する別の取引コマンドを再度サブミットする必要がある。
本明細書に記載の一例によれば、システム100は、1つ以上の外国為替(「FX」)商品の取引に使用されてよい。例えば、本明細書に記載の方法によれば、システム100上の或るプロバイダ(例えば、ユーザA、及び/又はユーザAの代理で執行する取引アプリケーション122a)が、FX商品に対する1つ以上の注文、例えば、ビッド及び/又はオファーをサブミット又はストリーミングすることにより、FX商品の取引に応じてよく、各注文は、例えば、価格及びサイズを有する。ここで論じられているように、例えば、各注文は、プロバイダのサーバ(例えば、ユーザAのサーバ101)から他の1つ以上のサーバにルーティングされてよい。サーバ、例えば、ユーザBのサーバ102がFX商品に対する注文を受信するように構成されていると仮定すると、対応する、サーバ102のマッチングエンジン、例えば、エンジン120bが、その注文を受信し、それぞれの注文帳124bに記載してよい。その後、マッチングエンジンは、情報を受信順にユーザB/及び/又は取引アプリケーション122bに転送してよい。ユーザB及び/又は取引アプリケーション122bは、注文を受信したら、例えば、その注文に対抗する取引コマンドをサブミットすることにより、その注文に対抗する執行を試みてよい(それによって、テイカーになってよい)。取引コマンドは、指定された価格及びサイズを含んでよい。ここで論じられているように、例えば、注文に対抗する取引コマンド/注文に対抗してマッチングされているコマンドがサブミットされたら、このコマンドは、サーバ101及びマッチングエンジン120aに送信/ルーティングされてよい。セカンドルックに従って、(注文がまだ使用可能であると仮定して)マッチングエンジン120aが注文に対抗する取引コマンドを執行するよりむしろ、マッチングエンジン120aは、最初に取引アプリケーション122a及び/又はユーザAと通信して、注文によって指定されるように取引を維持する要求がまだあるかどうかを判定してよい。取引アプリケーション122a及び/又はユーザAがまだ注文を維持しようとしていると仮定すると、取引アプリケーション122a及び/又はユーザAからマッチングエンジン120aに「済み」コマンドが伝達されてよく、これによって、その後、(例えば、「済み」コマンドで指定されるサイズに対する)注文に対抗する取引コマンドが執行されてよく、その後、ここで論じられているように、確認メッセージ等が生成されてよい。代替として、取引アプリケーション122a及び/又はユーザAが注文によって指定されるように取引を維持することをもう行わないと仮定すると、「否/中止」コマンドが、取引アプリケーション122a及び/又はユーザAからマッチングエンジン120aに伝達されてよい。そして、そのマッチングエンジン120aが、例えば、ここで論じられているように、注文に対する取り消しメッセージ、及び/又は、取引の未確認を明確に示すメッセージ、及び/又は、取引が失敗したこと、及び/又は、取引が完了しなかったこと等を伝達してよい。別の代替として、取引アプリケーション122a及び/又はユーザAが注文によって指定されるように取引を維持することをもう行わないと仮定すると、取引アプリケーション122a及び/又はユーザAが、マッチングエンジン120aに対して何もメッセージを伝達しなくてよい。更に別の代替として、ユーザB/取引アプリケーション122bが取引コマンドを撤回してよく、そのような要求を、例えば、マッチングエンジン120bに伝達してよく、そのマッチングエンジン120bが、その撤回要求を、例えば、少なくともサーバ101及びマッチングエンジン120aに伝達してよく、そのサーバ101及びマッチングエンジン120aは、その取引コマンドに関するその後のアクションを無視してよい。当業者であれば理解されるように、外国為替取引に関するシステム100の上述の動作例は一例であり、他の動作例及び/又は追加の動作例も可能である。
ここで論じられている別の例によれば、例えば、3人のプロバイダ、ユーザA、C、及びDのそれぞれが、商品の注文を同じ価格でサブミットすると仮定し、例えば、Aの注文のサイズが10、Cの注文のサイズが5、Dの注文のサイズが5であると仮定する。更に、ここで論じられているように、各注文がユーザBのサーバ102にルーティングされ、注文帳124bに記載されると仮定する。更に、例えば、Aの注文がCの注文より時間的に優先され、Cの注文がDの注文より時間的に優先されると仮定する。ユーザB及び/又は取引アプリケーション122bは、注文を受信したら、商品に対する取引コマンドを、それら3つの注文の価格で、且つ、サイズを20として、サブミットしてよい。ここで論じられている一例によれば、マッチングエンジン120bは、サイズを5として取引コマンドをサーバ101/マッチングエンジン120aに転送してよく(それによって、Aの注文に対抗して執行してよく)、サイズを10として別の取引コマンドをサーバ103/マッチングエンジン120cに転送してよく(それによって、Cの注文に対抗して執行してよく)、且つ、サイズを5として第3の取引コマンドをサーバ104/マッチングエンジン120dに転送してよい(それによって、Dの注文に対抗して執行してよい)。マッチングエンジン120bは、それら3つの取引コマンドをほぼ同時に転送してよい。例えば、マッチングエンジン120bは、ユーザAのサーバ101からの確認又は未確認メッセージを待たずに、ユーザC及びDのサーバ103及び104のそれぞれに取引コマンドを転送してよい。別の例によれば、ユーザAがサイズを10未満として「済み」コマンドで応答するか、「中止」コマンドで応答すると仮定すると、サーバ102のマッチングエンジン120bは、そのような応答の通知をサーバ101から受信したら、ユーザC又はユーザDに向けて、未充足サイズに対する別の取引コマンドを転送することによって、自動的にユーザBの取引コマンドに応じたままにしようとしてよい。別の代替として、サーバ102のマッチングエンジン120bは、ユーザC及びユーザDのそれぞれに向けて、未充足サイズのそれぞれの部分に対する別の取引コマンドを転送することによって、自動的にユーザBの取引コマンドに応じたままにしようとしてよい。別の例として、ユーザA、C、及びDからの注文に加えて、ユーザEからサイズ10に対する別の注文があると仮定する。ここで、マッチングエンジン120bがユーザC及び/又はユーザDを介してユーザBの取引コマンドに応じようとすることよりむしろ(或いは、これに加えて)、マッチングエンジン120bは、ユーザEに向けて、未充足サイズ又はその一部に対する別の取引コマンドを転送することにより、自動的にユーザBの取引コマンドに応じようとしてよい。ここでも、当業者であれば理解されるように、上記はシステム100の一動作例であり、他の変形も可能である。
テイカーの観点からすれば、プロバイダが取引コマンドに「中止」コマンドで応答すること、或いは、プロバイダが取引コマンドに応答することに時間をかけすぎること、或いは、全く応答しないことは望ましいことではない。 これらは、両方とも、テイカーが取引コマンドを撤回することになりかねない。これらのケースでは、結果として、テイカーが所望の取引を執行しないか、テイカーが他の注文に対抗して執行することによって、取引相手となる他のプロバイダを捜し出す為に、そのような取引は時間がかかりすぎる。
一例によれば、或るプロバイダの、「済み」コマンド及び「中止」コマンドの応答、及び/又は応答がないこと、及び/又は応答が遅れたことを評価することによって、そのプロバイダの充足率が算出されてよい。或るプロバイダの充足率は、例えば、プロバイダに対して送信されて、プロバイダが受け入れる能力がある取引コマンドの総数に対する、プロバイダに対して送信されて、プロバイダが受け入れて取引の執行につなげた取引コマンドの数の比率であると見なされてよい。充足率は、例えば、プロバイダに対して送信され、プロバイダが受け入れて取引の執行につなげた取引コマンドの数を測定し、これを、プロバイダに対して送信され、プロバイダが受け入れる能力がある取引コマンドの総数で割ることによって、決定されてよい。結果として得られる値は、0及び1を含む、0から1までの値であってよく、パーセント値で(即ち、100を乗ぜられて)表されてよい。例えば、10個の取引コマンドがプロバイダに送信され、プロバイダが10個全ての取引コマンドに対し「済みコマンド」で応答し、それぞれが取引の執行につながる場合、プロバイダの充足率は100%ということになる。別の例として、10個の取引コマンドがプロバイダに送信され、プロバイダが7個の取引コマンドに対して「済み」コマンドで応答し、それぞれが取引の執行につながり、3個の取引コマンドに対して「中止」コマンドで応答する場合、プロバイダの充足率は70%ということになる。別の例として、10個の取引コマンドがプロバイダに送信され、プロバイダが3個の取引コマンドに対して「済み」コマンドで応答し、それぞれが取引の執行につながり、4個の取引コマンドに対して「中止」コマンドで応答し、別の1つの取引コマンドに対しては応答せず、別の1つの取引コマンドに対しては「済み」コマンドで応答するものの時間がかかりすぎ、別の1つの取引コマンドに対しては「済み」コマンドで応答するものの、テイカーが撤回コマンドをサブミットした後であった場合、プロバイダの充足率は30%ということになる(これは、10個の取引コマンドのうちの3個だけが取引の執行につながる為である)。別の例として、或る注文に対抗する取引コマンドがプロバイダに送信され、その注文がプロバイダによって取り消されるか、且つ/又は、取引コマンドの受信の前に対抗して執行される場合、そのような未執行の取引コマンドは、プロバイダの決定済み充足率に悪影響を及ぼさないと考えられる。当業者であれば理解されるように、充足率は、別の方法で定義及び決定されてもよい。
別の例及び/又は追加の例によれば、充足率は、取引コマンドに対するプロバイダの応答の全履歴が考慮されるように、時間によらず、プロバイダに対して決定及び更新されてよい。別の例及び/又は追加の例によれば、充足率は、指定された継続時間、例えば、指定された時間数、指定された日数等にわたって、プロバイダに対して決定及び更新されてよい。例えば、継続時間は、市場が開いている取引前日であってよい。従って、充足率は、各取引日の最後に、例えば、その日の取引コマンドに対するプロバイダの応答だけを考慮して、決定/更新されてよい。別の例として、継続時間は、最後のx時間のような、動いている継続時間にわたって測定されてよい。従って、充足率は、最後のx時間の取引コマンドを考慮して、1時間ごとに決定/更新されてよい。当業者であれば理解されるように、充足率は、ここで論じられた方法に対して追加の方法及び/又は異なる方法で定義及び決定されてよい。例えば、プロバイダが、取引コマンドで指定されるサイズより小さいサイズに対して、取引コマンドに「済み」で応答する場合、この不完全な充足は充足率に悪影響を及ぼす可能性があり、言い換えると、充足率が、取引コマンドで指定されるサイズと同じサイズに対して「済み」の応答がなされる場合より小さい値になる可能性がある。所与の市場では、各プロバイダは、それぞれの充足率が同じ方法で決定されてよく、或いは、プロバイダが異なれば、それぞれの充足率の決定方法も異なってよい。当業者であれば理解されるように、他の変形も可能である。
別の例及び/又は追加の例によれば、充足率は、例えば、或る期間での、例えば、或る取引商品についての、充足量と未充足量との比較に基づいて決定されてよい。適切な期間として、履歴期間(例えば、過去2取引週間)があってよく、又、応答時間(例えば、執行要求の数ミリ秒以内に典型的に注文に応じられるパーセンテージ)もあってよい。実施形態によっては、応じられた、又は応じられなかった様々な注文の数が不適切な場合があり、その代わりに、応じられた総量と応じられなかった総量との対比が適切な場合がある。例えば、或る取引者に対して執行の為にルーティングされた特定取引商品の総量の半分にしか、その取引者が応じなかった場合、その取引者は、その取引商品に対する充足率が50%であると計算されてよい。この例では、応じられた50%が注文数の80%を表していたとしても、計算される充足率は50%であってよい(例えば、これは、応じられた注文の数が応じられなかった注文の数より小さくなる傾向があった場合に、或いは、取引者が様々な注文に部分的に応じた場合に起こりうる)。
別の例及び/又は追加の例によれば、或るプロバイダが、或るインスタンスにおいて、1つ以上の充足率を有してよい。例えば、プロバイダは、プロバイダが取引に応じるFX商品ごとに、1つ以上の決定済み充足率を有してよい。例えば、或るFX商品に対し、取引コマンドのソース(即ち、テイカー)によらず、プロバイダがどのように取引コマンドに応答するかに基づく単一の充足率をプロバイダが有してよい。別の例及び/又は追加の例として、或るFX商品に対し、プロバイダが複数の充足率を有してよく、それぞれが各テイカーに対応し、例えば、そのテイカーからの取引コマンドにプロバイダがどのように応答するかに基づく充足率である。別の例及び/又は追加の例として、或るFX商品に対し、プロバイダが応答する全てのテイカーとは限らない複数のテイカーからの取引コマンドにプロバイダがどのように応答するかに基づく充足率をプロバイダが有してよい。別の例及び/又は追加の例として、プロバイダは、複数のFX商品にまたがって決定される充足率を有してよい。当業者であれば理解されるように、プロバイダが異なれば、決定済み充足率の数も異なることを含め、他の変形も可能である。例えば、各プロバイダは、ソース(即ち、テイカー)によらず、プロバイダがどのように取引コマンドに応答するかに基づく単一の充足率を有してよく、1人以上のプロバイダが、指定されたテイカーに関連付けられた充足率を有してもよい。
別の例及び/又は追加の例によれば、或るプロバイダの充足率は、手動で、且つ/又は電子的に決定されてよい。例えば、システム100を例として参照すると、サーバ、例えば、サーバ101〜106のうちのいずれかが、そのサーバに関連付けられたユーザ/取引アプリケーションによって生成された注文を監視してよく、又、そのような注文に対抗する取引コマンドも監視してよい。そのような測定から、サーバは充足率を決定してよい。言い換えると、或るプロバイダに割り当てられた/関連付けられたサーバは、そのプロバイダの充足率を決定してよい。一例として、サーバ上で実行されるアプリケーション、例えば、マッチングエンジン120は、そのような測定を実施して充足率を決定してよい。別の例及び/又は追加の例として、サーバ、例えば、サーバ101〜106のうちのいずれかが、そのサーバに関連付けられたユーザ/取引アプリケーションによって生成された取引コマンドを監視してよく、又、そのような取引コマンドが対抗して発行される注文を監視し、そのような測定から充足率を決定してもよい。言い換えると、或るテイカーに割り当てられた/関連付けられたサーバは、プロバイダの充足率を決定してよい。一例として、サーバ上で実行されるアプリケーション、例えば、マッチングエンジン120は、そのような測定を実施して充足率を決定してよい。別の例及び/又は追加の例として、ユーザに関連付けられていない、システム100のサーバ、例えば、サーバ150は、注文、取引コマンド等を監視して、システム100のプロバイダの充足率を決定してよい。別の例及び/又は追加の例として、システム100の任意の1つ以上のサーバが、注文、取引コマンド等を監視してよい。その後、例えば、管理者が、システム100のプロバイダの充足率を手動で決定してよい。当業者であれば理解されるように、充足率は、他の方法及び/又は追加の方法で決定されてよい。
別の例及び/又は追加の例によれば、或るプロバイダの充足率が、システム100の他のサーバ(言い換えると、或るプロバイダに関連付けられたサーバ以外のサーバ、及び/又は、或るプロバイダに関連付けられたサーバに加えられたサーバ)も使用できるようにされてよい。例えば、システム100の管理者が充足率を決定する場合、管理者は、そのような充足率を、システム100の1つ以上のサーバが使用できるように構成してよい。別の例及び/又は追加の例として、システム100の或るサーバ、例えば、サーバ150が充足率を決定する場合、このサーバは、システム100の1つ以上のサーバに充足率を伝達してよい。別の例及び/又は追加の例として、或るプロバイダに関連付けられたサーバがそのプロバイダの充足率を決定する場合、このサーバは、システム100の他の1つ以上のサーバに充足率を伝達してよい。一例として、或るプロバイダの充足率は、そのプロバイダが生成する注文に含められてよい。当業者であれば理解されるように、充足率は、他の方法及び/又は追加の方法で伝達されてよい。
別の例及び/又は追加の例によれば、或るプロバイダの複数の充足率が、異なる複数の量に対して決定されてよく、例えば、特定の取引商品に対して決定されてよい。例えば、100以下、(101及び1000を含む)101と1000の間、(1001及び5000を含む)1001と5000の間、5001と10000の間等の量に対して、充足率が決定されてよい。このことは特に、例えば、プロバイダが小さな量に対して高い充足率を有し、大きな量に対して低い充足率を有する場合に有用である。例えば、或るプロバイダにおいて、1Mと2Mとの間のユーロダラー量に対して計算された充足率が30%であって、100,000と500,000との間のユーロダラー量に対する充足率が85%であってよい。
別の例及び/又は追加の例によれば、充足率が、取引のどちらの側かに基づいて決定されてよく、例えば、プロバイダが特定のアイテムに対して買い側か売り側かに基づいて決定されてよい。例えば、特定のアイテムの取引において、何人かのプロバイダが、売り手としてよりも買い手として注文に応じる可能性がより高くてよい。従って、プロバイダが買い手(又は売り手)である場合、プロバイダの充足率は、そのプロバイダが買い手(又は売り手)であったときにそのプロバイダによって応じられた注文の数(又は量等)と、そのプロバイダが買い手(又は売り手)であったときにそのプロバイダによって応じられなかった注文の数(又は量)との対比に基づいて計算されてよい。
別の例及び/又は追加の例によれば、充足率がスプレッドに基づいて決定されてよく、例えば、全米最良気配(national best bid and offer)(NBBO)の価格間のスプレッドに基づいて決定されてよい。例えば、何人かの取引者が、スプレッドが特定の閾値又は範囲を満たす場合に注文に応じる可能性がより高くてよく、それは、例えば、スプレッドが1ドルより小さい場合、或いはスプレッドがその平均スプレッドより小さい場合、或いはスプレッドが、取引日の開始からの取引商品の平均スプレッドの下側の1標準偏差より小さい場合、或いはスプレッドが、0.10ドルより大きく(且つ/又は0.10ドルに等しく)、且つ、0.20ドルより小さい(且つ/又は0.20ドルに等しい)場合である。従って、特定のプロバイダの充足率は、充足率の計算の対象であるアイテムに対する現在のスプレッドに依存してよい。
実施形態によっては、充足率は、本明細書に記載の様々な要因に基づいて決定されてよく、そのような要因として、例えば、全ての取引商品の総量の、応じられたものと応じられなかったものとの対比、特定の取引商品の総量の、応じられたものと応じられなかったものとの対比、全てのソースからの注文の総数の、応じられたものと応じられなかったものとの対比、特定の取引商品に対する注文の数の、応じられたものと応じられなかったものとの対比、特定の注文と同じ量及び範囲の注文の数の、応じられたものと応じられなかったものとの対比等がある。例えば、充足率(例えば、正味充足率)は、ここで論じられているように計算された2つ以上の充足率値の単純平均又は重み付き平均として計算されてよい。例えば、特定の取引者の注文帳にある、特定の取引商品に対する特定の取引者の注文を注文することに使用されてよい、或るプロバイダについて計算される充足率は、(1)全てのパーティについての全ての取引商品を考慮した、そのプロバイダの計算された総充足率、(2)その特定の取引者に対抗する全ての取引商品についての、そのプロバイダの計算された充足率、及び(3)特定の取引商品についての、その特定の取引者に対抗する、そのプロバイダの計算された充足率の平均として計算されてよい。
実施形態によっては、充足率は、応答時間に少なくとも部分的に基づいて決定されてよい。例えば、プロバイダが、応答時間が異なれば充足率も異なるように決定されてよい。例えば、プロバイダが、典型的には、10ミリ秒以内であれば平均的注文の70%に応じ、20ミリ秒以内であれば平均的注文の85%に応じるように計算されてよい。
実施形態によっては、充足率は、単位時間あたりの応じる確率として表されてよく、これは、(本明細書の様々な例において計算されるような)充足率と応答時間との両方を反映する。
別の例及び/又は追加の例によれば、プロバイダの充足率がサーバに伝達され、サーバで使用可能にされると、充足率は、例えば、そのサーバのマッチングエンジンに通知されてよいが、そのサーバの取引アプリケーション及び/又はユーザには通知されなくてよい。別の例及び/又は追加の例によれば、充足率は、サーバの取引アプリケーション及び/又はユーザに通知されてよい。別の例及び/又は追加の例によれば、受信された注文がマッチングエンジンによってそれぞれの取引アプリケーション/ユーザに伝達される場合、その注文を生成したプロバイダの充足率も、取引アプリケーション/ユーザに伝達されてよい。
これも当業者であれば理解されるように、ここで規定される充足率の決定及びその使用は、システム100のような分散アーキテクチャに限定されない。例えば、充足率の使用は、集中型注文帳にも当てはまってよい。ここで、例えば、集中型取引システム(例えば、注文帳及び注文の受信を管理し、そのような注文に対抗する取引コマンドの執行を管理する中央サーバ)が、プロバイダの充足率を決定してよい。そのようなサーバは、エンドユーザが使用するコンピュータシステムに充足率を伝達してもよい。
別の例によれば、例えば、3人のプロバイダ、ユーザA、C、及びDのそれぞれが、商品の注文を同じ価格でサブミットすると仮定し、例えば、Aの注文のサイズが10、Cの注文のサイズが5、Dの注文のサイズが5であると仮定する。更に、ここで論じられているように、各注文がユーザBのサーバ102にルーティングされ、注文帳124bに記載されると仮定する。更に、例えば、Aの注文がCの注文より時間的に優先され、Cの注文がDの注文より時間的に優先されると仮定する。更に又、ユーザAの充足率が70%であり、ユーザCの充足率が80%であり、ユーザDの充足率が90%であると仮定する。ユーザB及び/又は取引アプリケーション122bは、注文を受信したら、商品に対する取引コマンドを、それら3つの注文の価格で、且つ、サイズを10として、サブミットしてよい。一例によれば、マッチングエンジン120bは、注文帳124bにおいて、価格と、次に、注文が市場にサブミットされる時間とに基づいて、ユーザA、C、及びDの注文に優先順位を付けてよい。従って、ユーザAの注文はユーザCの注文より優先されてよく、ユーザCの注文はユーザDの注文より優先されてよい。ここで、マッチングエンジン120bは、ユーザBからの取引コマンドに応答して、取引コマンドを、サイズを10として、サーバ101/マッチングエンジン120aに転送してよい(これによってAの注文に対抗する執行がなされてよい)。これは、ユーザAの注文が最高優先度を有する為である。別の例によれば、マッチングエンジン120bは、注文帳124bにおいて、価格と、次に、充足率とに基づいて、ユーザA、C、及びDの注文に優先順位を付けてよい(即ち、2つ以上の注文が同じ価格と関連付けられた充足率とを有さない限り、時間には基づかない)。従って、ユーザDの注文はユーザCの注文より優先されてよく、ユーザCの注文はユーザAの注文より優先されてよい。ここで、マッチングエンジン120bは、ユーザBからの取引コマンドに応答して、取引コマンドを、サイズを5として、サーバ104/マッチングエンジン120dに転送してよい(これによってDの注文に対抗する執行がなされてよい)。これは、ユーザDの注文が最高優先度を有する為である。更に、マッチングエンジン120bは、ユーザDとの取引コマンドの残りサイズの5に応じようとしてもよい。代替として、マッチングエンジン120bは、取引コマンドを、残りサイズを5として、サーバ103/マッチングエンジン120cに転送してもよい(これによってCの注文に対抗する執行がなされてよい)。これは、ユーザCの注文が、(例えば、注文帳において)次に高い優先度を有する為である。ここでも当業者であれば理解されるように、上記はシステム100の一動作例であり、他の変形も可能である。
別の例によれば、例えば、3人のプロバイダ、ユーザA、C、及びDのそれぞれが、商品の注文を異なる価格でサブミットすると仮定し、例えば、Aの注文の価格がCの注文の価格より優位であり、Cの注文の価格がDの注文の価格より優位であると仮定する(優位である、とは、例えば、ビッドの場合には価格がより高いことを意味し、オファーの場合には価格がより低いことを意味する)。更に、ここで論じられているように、各注文がユーザBのサーバ102にルーティングされ、注文帳124bに記載されると仮定する。更に、例えば、Aの注文がCの注文より時間的に優先され、Cの注文がDの注文より時間的に優先されると仮定する。更に又、ユーザAの充足率が70%であり、ユーザCの充足率が80%であり、ユーザDの充足率が90%であると仮定する。一例によれば、マッチングエンジン120bは、注文帳124bにおいて、充足率と、次に、価格とに基づいて、ユーザA、C、及びDの注文に優先順位を付けてよい(ここでも、時間は、2つ以上の注文の充足率が同じである場合に追加の要因として使用されてよい)。従って、ユーザDの注文はユーザCの注文より優先されてよく、ユーザCの注文はユーザAの注文より優先されてよい。この例によれば、ユーザB及び/又は取引アプリケーション122bは、取引コマンドが応じられる価格よりも、取引コマンドが応じられることにより関心があってよい。従って、ユーザB及び/又は取引アプリケーション122bが、注文を発したプロバイダのそれぞれの充足率を認識していない場合でも、或る注文が、異なる価格の別の注文より優先されていることがわかっていれば、ユーザは、価格に対して優位な充足率であるとユーザが見なすものを選択することが可能であってよい。
別の例及び/又は追加の例によれば、注文は、価格及び充足率の重み付き平均に従って注文されてよい。例えば、実施形態によっては、或る注文が、価格が0.09ドル劣位であって充足率が5%優位である注文より優先して注文されるように、充足率の5%の差に、0.10ドルの価格差と同じ重みが付けられてよい。応答時間は、重み付きで考慮されてもよい。実施形態によっては、特定の取引者が、例えば特定の取引商品について、その特定の取引者の注文帳において、充足率、応答時間、価格などの様々な要因の重み付けを指定してよい。例えば、ユーザは、価格差に等しい充足率のパーセンテージを指定してよく、例えば、応答時間に等しい充足率のパーセンテージを指定してよい。例えば、特定の取引者の注文帳を注文する目的で、その特定の取引者は、1価格単位(即ち、特定の取引者にとって1単位だけ優位である価格)が、充足率の3%の改善、及び応答時間の2.5ミリ秒の改善に等しいように指定してよい。この例では、第1の売り注文の価格が12.25ドルであり、関連付けられた充足率が80%であり、関連付けられた応答時間が13ミリ秒であり、第2の売り注文の価格が12.26ドル(12.25ドルより1単位だけ劣位)であり、関連付けられた充足率が86%であり、関連付けられた応答時間が15.5ミリ秒であると、第1の売り注文と第2の売り注文は優先度が等しいと見なされてよく、これらの注文は両方とも、価格が12.25ドルであり、応答時間が80%であり、応答時間が15.5ミリ秒である第3の注文より優先して注文されてよい。
別の例及び/又は追加の例によれば、システム100の1人以上のユーザが、そのユーザが取引コマンドのサブミット時に達成したい最小充足率に対応する規定閾値を有してよい。言い換えると、システム100の或るユーザがテイカーとして働く場合には、そのユーザは、取引コマンドのサブミット時に達成したい最小充足率を規定してよい。或るユーザが、取引を望む全ての金融商品に適用される単一の閾値を有してよい。別の例として、或るユーザが、取引を望む各商品にそれぞれが対応する複数の閾値を有してよい。ユーザが異なれば、各ユーザが有する規定閾値も異なってよく、規定閾値の数も異なってよい。一例によれば、システム100のユーザ/取引アプリケーション/管理者が、ユーザの閾値を使用して、そのユーザに関連付けられたそれぞれのサーバを構成してよく、例えば、閾値を有する、それぞれのマッチングエンジンを構成してよい。別の例及び/又は追加の例によれば、ユーザ/取引アプリケーションがそれぞれのマッチングエンジンに取引コマンドをサブミットする場合、注文は閾値を含んでよい。例えば、ユーザB及び/又は取引アプリケーション122bが、或る注文に対抗する取引コマンドをそのマッチングエンジン120bにサブミットする場合、この取引コマンドは閾値を含んでよい。当業者であれば理解されるように、他の変形も可能である。
実施形態によっては、充足率が高いほど、関連して、価格が劣位になり、スプレッドが高くなる可能性があり、これは、カウンタパーティが一般に、自身にとってより好ましい価格で注文に応じる可能性がより高い為である。(例えば、或る取引商品に対する現在の最良のビッド/オファーが5.00ドル/5.50ドルである場合、或る取引者は4.75ドルよりも5.50ドルでビッドに応じる可能性がより高く、或る取引者は5.50ドルよりも5.75ドルでオファーに応じる可能性がより高い。)従って、ユーザが最小充足率を指定することを可能にすることにより、様々な実施形態が、ユーザが充足率と価格との間のトレードオフを表現することを可能にする。例えば、ユーザは、高い充足率を、しかしながら典型的には、より劣位の価格で指定してよく、或いは、より低い充足率を、典型的には、より優位の価格で指定してよい。
図2及び図3は、幾つかの実施形態による、平均スプレッドと推定充足率との関係を示す例示的グラフである。図2は、取引注文サイズが1,000,000に等しい場合の例示的グラフを示す。図3は、取引注文サイズが5,000,000である場合の例示的グラフを示す。例示的モデルA及び例示的シフトブックの両方についてのこれらのグラフに示されるように、推定充足率は平均スプレッドと共に増加する傾向がある。図2及び図3の例示的グラフは又、グラフ化されたデータセットについての、これらの変数間の非線形関係も示しており、例えば、推定充足率は、スプレッドが低いところでは、スプレッドが高いところよりも急激に増加する。
別の例及び/又は追加の例によれば、テイカー(例えば、ユーザB及び/又は取引アプリケーション122b)が、プロバイダ(例えば、ユーザA及び/又は取引アプリケーション122a)からサブミットされた、テイカーの注文帳124bにある注文に対抗する取引コマンドをサブミットすると、マッチングエンジン120bは、例えば、ユーザBの規定閾値をユーザAの決定済み充足率と比較し、ユーザAの充足率がユーザBの閾値より大きい場合(又はユーザBの閾値以上の場合)のみ、その注文に対抗する取引コマンドの潜在的執行の為に、取引コマンドをユーザAのサーバ101に伝達してよい。そうでない場合、マッチングエンジン120bは、その注文に対抗する取引コマンドを執行しようとしなくてよい。別の例及び/又は追加の例によれば、注文帳124bに、例えば、2つの注文が記載されていて、それぞれが別々のプロバイダからであり、それぞれが同じ価格であり、例えば、市場にサブミットされた時点に基づいて、第1の注文が第2の注文より優先されていると仮定する。ここで、マッチングエンジン120bは、ユーザB及び/又は取引アプリケーション120bから取引コマンドを受信した時点で、まず、ユーザBの規定閾値を、第1の注文をサブミットしたプロバイダの決定済み充足率と比較し、充足率がユーザBの閾値より大きい場合(又はユーザBの閾値以上の場合)のみ、その注文に対抗する取引コマンドの潜在的執行の為に、取引コマンドをそのプロバイダのサーバに伝達してよい。そうでない場合、マッチングエンジン120bは、第1の注文を飛ばし/無視し、ユーザBの規定閾値を、第2の注文をサブミットしたプロバイダの決定済み充足率と比較してよい。ここでも、マッチングエンジン120bは、充足率がユーザBの閾値より大きい場合(又はユーザBの閾値以上の場合)のみ、第2の注文をサブミットしたプロバイダのサーバに、取引コマンドを潜在的執行の為に伝達してよい。より一般的には、マッチングエンジン120bは、ユーザB及び/又は取引アプリケーション120bから取引コマンドを受信した時点で、注文帳124bにある注文の充足率が、例えば、ユーザBの規定閾値より小さい場合には、それらの注文を飛ばして/無視してよい。ここでも、充足率をこのように使用することは、集中型取引システムにも適用されてよい。当業者であれば理解されるように、充足率をこのように使用することは、注文帳が価格、充足率の順で優先順位付けされるか、充足率、価格の順で優先順位付けされている場合にも適用されてよい。
別の例及び/又は追加の例によれば、或るプロバイダがシステム100に注文をサブミットし、その注文が他の複数のサーバ、及びそれらのサーバのそれぞれのマッチングエンジンに伝達された場合、マッチングエンジンによっては、その注文をそれぞれの注文帳に自動的に記載しなくてよい。例えば、ユーザA及び/又は取引アプリケーション122aがシステム100に注文をサブミットし、その注文がユーザBのサーバ102において受信されたと仮定する。マッチングエンジン120bは、その注文を受信したら、ユーザBの規定閾値を、ユーザAの決定済み充足率と比較してよい。この充足率がユーザBの閾値より大きい場合(又はユーザBの閾値以上の場合)に、マッチングエンジンは、その注文を注文帳124bに記載してよい(場合によっては、その注文に関する情報をユーザ及び/又は取引アプリケーション122bに転送してよい)。代替として、充足率がユーザBの閾値より小さい場合(又はユーザBの閾値以下の場合)、マッチングエンジンは、その注文を注文帳124bに記載しなくてよい(そして、その注文に関する情報をユーザB及び/又は取引アプリケーション122bに転送しなくてよい)。このように、ユーザB/取引アプリケーション124bは、或る一定の閾値を満たす関連付けられた充足率を有する注文のみが与えられる(そして、それによって、その注文に対抗する取引を行う機会を有する)。ユーザからは、そのユーザの規定閾値を満たさない関連付けられた充足率を有する注文が見えない(従って、そのユーザは、その注文に対抗する取引を行う機会を有しない)。更に、この例によれば、システム100における別々のユーザが、異なる閾値を有してよく、且つ/又は、それぞれのプロバイダごとに異なる充足率を使用してよい為、或る商品に対する、各サーバにおける注文帳は異なってよい(即ち、市場の現在の表現が異なってよい)。当業者であれば理解されるように、充足率をこのように使用することは、注文帳が価格、充足率の順で優先順位付けされるか、充足率、価格の順で優先順位付けされている場合にも適用されてよい。
別の例及び/又は追加の例によれば、注文帳が、応答時間に少なくとも部分的に基づいて注文されてよい。応答時間は、応じる応答又は応じない応答を受信するのに(例えば、平均的に)かかる時間を含んでよい。応答時間は、システム構成要素間、時刻間、ユーザ間等でばらついてよい。例えば、システムにおいて互いに非常に近接する2つのノードが、非常に小さい応答時間を有してよく、ノード同士が離れていれば応答時間が長くなってよい。又、応答時間は、ネットワークトラフィックが重い時間帯には長くなる可能性がある。いずれにせよ、応じるメッセージ及び応じないメッセージの応答時間は、追跡及び測定されてよい。充足率と同様に、応答時間は、様々な時間帯及び状況に対して測定されてよい。具体的には、応答時間は、特定のメッセージ経路について計算されてよく(例えば、プロバイダ#2が(例えば、過去3取引日にわたって)取引者#3に応答する応答時間)、又、特定の取引エンティティについて計算されてもよい(例えば、プロバイダ#2から他の全ての取引エンティティへの、全ての応じるメッセージ及び応じないメッセージにわたる平均応答時間)。
場合によっては、応答時間が長ければ(例えば、100ミリ秒)、取引者が単一のプロバイダから単一の応答を取得することが期待できる時間に、応答時間が短ければ(例えば、0.1〜1ミリ秒)、取引者は、複数のプロバイダから複数の応答を受信することを期待できる。例えば、1000単位の注文に応じようとする取引者は、その取引者の注文帳に以下の反対注文を有してよい。(1)プロバイダ#1の注文。量は1000。応答時間は1ミリ秒。充足率は40%。(2)プロバイダ#2の注文。量は1200。応答時間は5ミリ秒。充足率は50%。(3)プロバイダ#3の注文。量は1200。応答時間は10ミリ秒。充足率は60%。及び、(4)プロバイダ#3の注文。量は2000。応答時間は40ミリ秒。充足率は90%。特に、取引者は、応じる応答又は応じない応答をプロバイダ#1から、(注文が#1によって完全には応じられなかった場合には)プロバイダ#2から、(注文が#1及び#2によって完全には応じられなかった場合には)プロバイダ#3から取得することが可能であり、これら全てが順々に、プロバイダ#4から応答を取得するのにかかるであろう時間より短い時間(16ミリ秒)で可能である。注文#4が最良の充足率を有しうる間に、取引者は、注文を(必要に応じて)プロバイダ#1、#2、及び/又は#3に送信することによって、注文に(しかも、より迅速に)応じる可能性がより高い。
実施形態によっては、或る注文が同じプロバイダに複数回ルーティングされてよい。例えば、或る注文がプロバイダ#1に複数回ルーティングされてから、プロバイダ#4からの応答が受信されてよい。プロバイダ#1への1回のルーティングに対して応じる確率は40%と計算されうる一方、プロバイダ#1への5回の注文のルーティングに対して応じる確率は、40%より著しく高い可能性がある。そのような確率の1つの計算は、(プロバイダ#1への5回のルーティングの後の)応じる確率=1−(1−0.4)^5=92.224%であってよく、これは、1回のルーティングの後のプロバイダ#4が応じる確率より高い。しかしながら、複数回のルーティングの後の応じる確率は、このようには増加しない可能性があり、それは、同じプロバイダへの個々のルーティングが数学的に独立した事象ではない可能性がある為である。逆に、プロバイダが応じる確率は、そのようなプロバイダが注文に応じないたびに減少する可能性がある。これらの値も追跡及び測定されてよい。例えば、充足率が50%であるプロバイダが、以前にそのプロバイダにルーティングされて応じられなかった注文に対して30%の充足率を有するであろうこと、並びに、そのプロバイダが2回拒否した注文に対して10%の充足率を有するであろうことが決定されてよい。いずれにせよ、何回かのルーティングの後の全体充足率が、1回のルーティングの場合の充足率より高くなることが決定されてよい。
従って、実施形態によっては、充足率を高くする為には(且つ/又は、価格を多少優位にする為には、或いは、量を多少増やす為には)、応答時間を減らすことが好ましい場合がある。
別の例及び/又は追加の例によれば、(例えば、流動性プロバイダによる)拒否率(例えば、プロバイダが或る注文又は注文のタイプを拒否する率。ある意味で充足率の逆)同士に高い相関性があってよい。例えば、複数の流動性プロバイダからの注文の後ろに単一の注文があってよい。例えば、ユーザAが1000単位を買おうとする場合、流動性プロバイダ#1、#2、及び#3の全員が、それらの単位を取得してユーザAに得る為に、1000単位に対する売り注文を出してよい。注文帳は1000単位に対する3つの別々の注文を反映してよいが(これは総量が3000単位であるように見える)、実際に必要なのは1000単位だけである。或る流動性プロバイダが1000単位を取得してユーザAの買い注文を満たした場合、他の流動性プロバイダからの、1000単位に対する他の売り注文は消滅する可能性が高い。この例では、取引者#1が2000単位を買おうとしてよく、取引者#1の注文帳には、流動性プロバイダ#1、#2、及び#3からの1000単位の注文が75%、80%、及び90%の充足率で示されてよい。このシナリオでは、取引者#1は、1000単位の取引をプロバイダ#3と行ってよく、その後、プロバイダ#1及びプロバイダ#2が取引者の残り1000個の注文に応じないことが判明してよい。この場合、プロバイダ#1及び#2の充足率は相関性が高くなる。
従って、実施形態によっては、2つ(以上)の注文が独立か非独立かの確率が、例えば、履歴取引情報(例えば、1つの対応する注文が(例えば一定期間内に)応じられた後に、例えば、全て又は一部の注文を取り消す2つのパーティの間の相関)、量の類似性、及び時間の類似性(例えば、同時又はほぼ同時に入力されたこと)などに基づいて決定されてよい。例えば、プロバイダA及びBからのよく似た2つの注文(例えば、それらの注文が同じ又はほぼ同じ価格及び量であって、例えば、同時又はほぼ同時に入力されたという理由でよく似ている注文)が、同じ商品に対するよく似た注文がプロバイダA及びBから入力されたという最後の4つのインスタンスのうちの3つにおいて、それらの注文のうちの1つが、応じられている他の注文から3ミリ秒以内に取り消された場合には、重複である可能性が高いと判定される可能性がある。
実施形態によっては、拒否率は、示されたサイズの関数であってよい。例えば、プロバイダらが示す同じ注文量が多いほど、それらの拒否率同士が相関する可能性が高くなる。(例えば、これは、それらの注文が、サードパーティからの同じ潜在量に基づいていて、同じ潜在注文の重複量を反映している為であってよい)。実施形態によっては、拒否率は、微細構造の関数であってよい。充足率及び拒否率の相関は、追跡及び測定されてよい。
実施形態によっては、2つ以上の注文の間の流動依存性は、例えば、充足率及び拒否率の相関に基づいて推定されてよい。例えば、サーバは、2つ(以上)の注文が互いに独立であるか、互いに(全体又は一部が)重複している可能性の高さを判定、計算、又は他の方法で推定してよい。例えば、システムは、完全に異なる流動性を有する2つの注文が独立である可能性が高く、従って、一方の注文に応じることが他方において利用可能な量に影響せず、従って、両方の注文が(例えば、それらの全量において)ヒットすることが可能であると判定してよい。システムは、別の3つの注文が少なくとも部分的に、互いに重複している可能性が高く、従って、いずれかのパーティが3つの注文全てに、それらの全量においてヒットしうる可能性が低いと判定してよい。例えば、システムは、3つの注文が80%重複しており、従って、1つの注文が応じられた後に、他の2つの注文が、それぞれの量のうちのまだ取引可能な20%を有するのみになると判定してよい。実施形態によっては、流動依存性を推定する為に、ルータが各カウンタパーティ間のリンク状態を検出してよい。実施形態によっては、システムは、流動非依存性を推定する為にグレンジャー因果関係を検出してよい。
図4は、本発明の様々な実施形態による一例示的フローチャートを示す。
ブロック405では、取引者が、量及び価格を含む取引商品に対する注文を受信してよい。これらの注文は、買い取引/売り取引の特定の側を含んでよく、例えば、ビッド(又はオファー)を含んでよい。各注文は量を含んでよい。幾つかの注文は、他の注文より先に受信されてよい。
ブロック410では、注文、及び注文のプロバイダに関する情報が決定されてよく、例えば、充足率、応答時間、流動非依存性(又は依存性)、及び他の条件が決定されてよい。当然のことながら、ブロック210で決定される情報は、いかなる特定の時点でも、或いは、フローチャート内の他のブロックから見た相対的な、いかなる特定の時点でも、決定されなくてよい。
ブロック415では、取引者は、注文に関連する情報を受信してよく、例えば、ブロック210で決定された情報を受信してよい。この情報は、充足率、応答時間、流動非依存性(又は依存性)に関する情報、及び他の情報を含んでよい。
ブロック420では、取引者は、取引者プレファレンスをサブミットするよう促されてよく、例えば、閾値充足率、閾値応答時間、最小ボリューム要件、及び/又は他の取引条件をサブミットするよう促されてよい。取引者は、条件及び/又はユーザプレファレンスを入力してよく、例えば、(例えば、特定の取引商品に関する)目標充足率、閾値応答時間、最小ボリューム要件、及び/又は他の取引条件を入力してよい。例えば、ユーザは、最小ボリューム要件として1000単位、最小充足率として70%、最大期待応答時間として20ミリ秒を指定してよい。
ブロック425では、取引者は取引コマンドを入力してよく、例えば、取引商品に対する、或る量の注文に、例えば、指定された価格で(又は最良の価格で)応じる為に、取引コマンドを入力してよい。取引コマンドは、目標充足率、最小ボリューム要件などの条件に関連付けられてよい。取引コマンドは、注文帳及び条件に従って注文に応じることの指示であると解釈されてよく、例えば、条件に基づく(例えば、条件を満たす)取引者の注文帳にある逆注文に対抗する、取引者の注文仕様に応じることによって、注文に応じることの指示であると解釈されてよい。例えば、このコマンドは、最小時間で、良好な(又は最良の)価格で、様々な条件を満たす逆注文に対抗して、注文に応じることの指示であると解釈されてよい。
ブロック430では、取引者からの1つ以上の注文指示(例えば、執行要求)が、(例えば、取引者の注文帳及び条件に従って)注文の1人以上のプロバイダにルーティングされてよい。例えば、注文帳の先頭にある1つ以上の注文を執行することの指示が、それらの注文のプロバイダにルーティングされてよい。それらの注文は、それらの価格、量、充足率、応答時間、流動非依存性、及び/又は他の要因に基づいて選択されてよい。プロバイダのうちの1人以上に、要求された注文に応じるかどうかを決定する為の「セカンドルック」が与えられてよい。
ブロック435では、取引者の注文帳に記載された1つ以上の注文が執行されてよく、例えば、1人以上の流動性プロバイダによって執行されてよい。執行に関する情報が、取引者にルーティングされてよく、取引者の注文帳(及びその中での注文)は、取引を反映するように更新されてよい。例えば、注文帳の先頭付近にある応じられない注文が、注文帳の最後部に移動させられてよく、これは、(例えば、ブロック430で)応じられた流動性が、応じられない注文の量だけ重複している可能性が高く、これは、応じられない注文が対抗して執行される可能性が低くなることを意味する、という判定に基づいて行われてよい。
ブロック440では、取引者の所望の量の一部が応じられないままである場合、1つ以上の注文指示(例えば、執行要求)が、取引者の更新された注文帳及び条件に従って、それらの注文の1人以上のプロバイダにルーティングされてよい。更新された注文帳に記載されている注文のうちの1つ以上が、それに対する応答として執行されてよい。
ブロック445では、応じること、応じないこと、及び応答時間に関する情報が追跡されてよい。そのような情報は、充足率、応答時間、及び他の、注文帳及びルーティングに関連する情報の推定値を決定及び更新する為に使用されてよい。
特定の実施形態及び一般的に関連付けられる方法の観点から本開示を説明してきたが、これらの実施形態及び方法の変更及び置換は、当業者であれば明らかであろう。例えば、当然のことながら、FX商品に関連して様々な特徴が説明されているが、そのような特徴は、他の商品及び取引商品(例えば、株式、債券、小売商品、及び他の商品及びサービス)にも当てはまってよい。従って、上述の、例示的実施形態の説明は、本開示を限定しない。他の変更、置換、及び改変も、本開示の趣旨及び範囲から逸脱しない限り、可能である。
以下の項は、本明細書を解釈する上での指針を提供する。
I.用語
「製品」という用語は、その他特に明示的に記載のない限り、マシン、製造、および/または物の組成を意味する。
「プロセス」という用語は、その他特に明示的に記載のない限り、プロセス、アルゴリズム、方法等を意味する。
各プロセス(方法、アルゴリズム、または他で呼ばれるかに関わらず)は本質的に、1つ以上のステップを含み、したがって、プロセスの「ステップ」(単数または複数)へのあらゆる参照は、プロセスの単なる説明、または「プロセス」等の用語の単なる記述において本質的な先行根拠を有する。したがって、請求項におけるプロセスの「ステップ」(単数または複数)への参照は、十分な先行根拠を有する。
「発明」等の用語は、その他特に明示的に記載のない限り、「本明細書において開示される1つ以上の発明」を意味する。
「ある実施形態」、「実施形態」、「実施形態(複数)」、「該実施形態」、「該実施形態(複数)」、「1つ以上の実施形態」、「いくつかの実施形態」、「所定の実施形態」、「一実施形態」、「別の実施形態」等の用語は、その他特に明示的に記載のない限り、「発明の1つ以上の(しかし全てではない)実施形態」を意味する。
本発明の「変形」という用語は、その他特に明示的に記載のない限り、本発明の実施形態を意味する。
「指標」という用語は、極めて広い意味で使用される。事柄の「指標」は、事柄を決定するために使用され得る任意のものを含むことを理解されたい。
事柄の指標は、事柄を特定する電子メッセージを含んでもよい(例えば、ウィジェットに取り付けられたシリアル番号によるウィジェットの特定、ウィジェットの1つ以上の特性によるウィジェットの特定)。事柄の指標は、事柄を計算および/または参照するために使用され得る情報を含み得る(例えば、ウィジェットが、ウィジェットを決定するために使用され得る一部であるマシンを特定する情報)。事柄の指標は、事柄に関連する事柄を指定し得る(例えば、事柄の特性、事柄の名称、事柄に関連する事柄の名称)。事柄の指標は、事柄に関連する事柄を指定しない場合がある(例えば、「ある(a)」という文字は、文字「ある(a)」を解釈してウィジェットを特定するように構成されるコンピュータシステムのウィジェットの指標であり得る)。事柄の指標は、事柄のサイン、兆し、および/またはトークンを含み得る。指標は、例えば、コード、参照、実施例、リンク、信号、および/または識別子を含み得る。事柄の指標は、事柄を表し、説明し、および/またはその他特に事柄に関連付けられた情報を含み得る。
事柄の指標の変換は、事柄の指標であり得る(例えば、事柄の暗号化された指標は、事柄の指標であり得る)。事柄の指標は、事柄それ自体、事柄のコピー、および/または事柄の一部を含み得る。事柄の指標は、指標を理解するように構成されない事柄に対して無意味なものである場合がある(例えば、ある人は、文字「ある(a)」がウィジェットを示すが、コンピュータシステムが文字「ある(a)」からウィジェットと判定し得るため、それがそれでもなおウィジェットの指標であり得ることを理解しない場合がある)。事柄の指標は、事柄が、事柄または任意のものが決定されることを意味しないと決定するように使用され得る事実を理解されたい。事柄の指標は、その他特に指定されない限り、事柄の任意の数の指標を含み得る。事柄の指標は、他の事柄の指標(例えば、多くの事柄を示す電子メッセージ)を含んでもよい。(指標は、特許請求の範囲の言語において非常に広い用語として使用され得る。例えば、金融商品の指標を受信すること。)
「表す」という用語は、(1)単語、記号、同様のものが行うように、表現する、指定する、表象する、または示すように機能すること、(2)いくつかの用語、文字、記号、同様のものによって表現するまたは指定すること、(3)写真が行うように、そのものを描く、または描写、または提示すること、または(4)サインまたは記号そのものとして機能すること、を意味する。
実施形態を説明する際の「別の実施形態」への参照は、その他特に明示的に記載のない限り、参照された実施形態が別の実施形態(例えば、参照された実施形態の前に記載された実施形態)と相互に排他的であることを暗示しない。同様に、2つ(以上)の実施形態が参照されるという単なる事実は、これらの実施形態が相互に排他的であることを暗示しない。
本発明の一実施形態は、本発明の2つ以上の他の実施形態を含み得るかまたは網羅し得るかまたは包括し得る。例えば、要素a、b、およびcを含む第1の実施形態は、要素a、b、c、およびdを含む第2の実施形態、ならびに要素a、b、c、およびeを網羅する第3の実施形態を網羅し得る。同様に、第1、第2、および第3の実施形態の各々は、要素a、b、c、d、およびeを含む第4の実施形態を網羅し得る。
「含む」、「備える」という用語およびそれらの変形は、その他特に明示的に記載のない限り、「含むが、必ずしも限定されない」ことを意味する。このため、例えば、「マシンは、赤いウィジェットおよび青いウィジェットを含む」という文は、マシンが赤いウィジェットおよび青いウィジェットを含むが、可能性として1つ以上の他のアイテムも同様に含み得ることを意味する。
「〜からなる」という用語およびその変形は、その他特に明示的に記載のない限り、「〜を含み、かつまた〜に限定される」ことを意味する。このため、例えば、「マシンは、赤いウィジェットおよび青いウィジェットからなる」という文は、マシンが赤いウィジェットおよび青いウィジェットを含むが、その他には何も含まないことを意味する。
「構成する」という用語およびその変形は、その他特に明示的に記載のない限り、「その成分、その構成部分、またはその要素を作り上げる」ことを意味する。このため、例えば、「赤いウィジェットおよび青いウィジェットはマシンを構成する」という文は、マシンが、赤いウィジェットおよび青いウィジェットを含むことを意味する。
「排他的に構成する」という用語およびその変形は、その他特に明示的に記載のない限り、「その成分を排他的に作り上げる、その構成部分のみである、またはその要素のみである」ことを意味する。このため、例えば、「赤いウィジェットおよび青いウィジェットはマシンを排他的に構成する」という文は、マシンが、赤いウィジェットおよび青いウィジェットだけ(すなわち、他には何もない)からなることを意味する。
「ある」、「一」、「1つ」および「その」(「a」、「an」および「the」)という用語は、その他特に明示的に記載のない限り、「1つ以上」を指す。このため、例えば、「ウィジェット」という語句は、その他特に明示的に記載のない限り、「1つ以上のウィジェット」を意味する。同様に、「ウィジェット」という語句を記した後、「ウィジェット」という語句の連続の記述は、「1つ以上のウィジェット」を意味する。したがって、「前記・その(the)」という単語は、先行根拠を有する特定の用語も指し得ることを理解されたい。例えば、段落に、「ある特定の単一の特徴」と記され、次いで、「前記特徴」を指す場合、そのとき「前記特徴」という語句は、先に記された「特定の単一の特徴」を指すことを理解されたい(「ある特定の単一の特徴」中の「ある」という用語は、「1つ」の特定の単一の特徴を指し、「1つ以上の」特定の単一の特徴ではないことを理解されたい)。
「複数」という用語は、その他特に明示的に記載のない限り、「2つ以上」を意味する。
「本明細書において」という用語は、その他特に明示的に記載のない限り、「参照によって組み込まれてもよい任意の事柄を含む、本明細書において」を意味する。
「のうちの少なくとも1つ」という語句は、このような語句が複数の事柄(事柄の列挙リスト)を修飾する場合、その他特に明示的に記載のない限り、それらの事柄の1つ以上の任意の組み合わせを意味する。例えば、「ウィジェット、車、ハンドルのうちの少なくとも1つ」という語句は、(i)ウィジェット、(ii)車、(iii)ハンドル、(iv)ウィジェットおよび車、(v)ウィジェットおよびハンドル、(vi)車およびハンドル、または(vii)ウィジェット、車、およびハンドルのいずれかを意味する。「のうちの少なくとも1つ」という語句は、このような語句が複数の事柄を修飾する場合、複数の事柄「の各々の1つ」を意味しない。例えば、「ウィジェット、車、ハンドルのうちの少なくとも1つ」という語句は、「1つのウィジェット、1つの車、および1つのハンドル」を意味しない。
「1つ」、「2つ」等の数値用語は、何らかの数量を示すために基数として使用される場合(例えば、1つのウィジェット、2つのウィジェット)、その数値用語によって示される数量を意味するが、少なくともその数値用語によって示される数量、を意味しない。例えば、「1つのウィジェット」という語句は、「少なくとも1つのウィジェット」を意味せず、したがって、「1つのウィジェット」という語句は、例えば、2つのウィジェットを網羅しない。
「基づく」という語句は、その他特に明示的に記載のない限り、「のみに基づく」ことを意味しない。すなわち、「基づく」という語句は、「のみに基づく」および「少なくとも基づく」の両方を網羅する。「少なくとも基づく」という語句は、「少なくとも部分的に基づく」という語句と同等である。例えば、「要素Aは、要素Bおよび要素Cに基づいて算出される」という語句は、要素AがB掛けるCの積として算出される(すなわち、A=B×C)実施形態、Aが、B足すCの和として算出される(すなわち、A=B+C)実施形態、Aが、B掛けるC掛けるDの積として算出される実施形態、Aが、B足すC足すD掛けるEの平方根の和として算出される実施形態等を網羅する。
「表す」等の用語は、その他特に明示的に記載のない限り、排他的ではない。例えば、「表す」という用語は、その他特に明示的に記載のない限り、「のみを表す」ことを意味しない。例えば、「データがクレジットカード番号を表す」という語句は、「データがクレジット番号だけを表す」および「データがクレジットカード番号を表し、データは他の何らかも表す」の両方を網羅する。
「それにより」という用語は、本明細書において、「それにより」という用語の前に明示的に記された何かの意図された結果、目的、または帰結のみを表現する節または他の単語セットに先行するようにのみ使用される。したがって、「それにより」という用語が特許請求の範囲内で使用される場合、「それにより」という用語が修飾する節または他の単語は、特許請求の範囲の特定の更なる制限を確立せず、または特許請求の範囲もしくは意味を制限しない。
「例えば」、「等」という用語および同様の用語は、「例を挙げれば」を意味し、したがって、それらが説明する用語または語句を制限しない。例えば、「コンピュータはインターネットを介してデータ(例えば、命令、データ構造)を送信する」という文では、「例えば」という用語は、「命令」が、コンピュータがインターネットを介して送信することができる「データ」の一例であることを説明すると共に、「データ構造」が、コンピュータがインターネットを介して送信することができる「データ」の一例であることも説明する。しかし、「命令」および「データ構造」は両方とも、「データ」の単なる例にすぎず、「命令」および「データ構造」以外の他の物事も「データ」であり得る。
「それぞれ」という用語および同様の用語は、「個々に」を意味する。したがって、2つ以上の物事が特性を「それぞれ」有する場合、このような各物事はそれ自体の特性を有し、これらの特性は互いに異なってよいが、互いに異なる必要はない。例えば、「2つのマシンの各々がそれぞれの機能を有する」という語句は、2つのマシンのうちの第1のものが機能を有し、2つのマシンのうちの第2のものも同様に機能を有することを意味する。第1のマシンの機能は、第2のマシンの機能と同じであってもよく、または同じでなくてもよい。
「すなわち」という用語および同様の用語は、「つまり」を意味し、したがって、それが説明する用語または語句を制限する。例えば、「コンピュータはインターネットを介してデータ(すなわち命令)を送信する」という文では、「すなわち」という用語は、「命令」が、コンピュータがインターネットを介して送信する「データ」であることを説明する。
数値範囲は、その他特に明示的に記載のない限り、その範囲における整数および非整数を含む。例えば、範囲「1〜10」は、1〜10の整数(例えば、1、2、3、4、...9、10)および非整数(例えば、1.0031415926、1.1、1.2、...、1.9)を含む。
2つ以上の用語または語句が同義語である場合(例えば、用語または語句が同義語であるという明示的な記載のため)、1つのこのような用語または語句の事例は、別のこのような用語または語句が異なる意味を有さなければならないことを意味しない。例えば、ある文が、「含む」という意味が「含むが、限定されない」と同義であると示す場合、「含むが、限定されない」という語句の単なる使用は、用語「含む」が「含むが、限定されない」以外を意味することを意味しない。
II.決定する
「決定する(determining)」という用語およびその文法的変形(例えば、価格の決定、値の決定、ある特定の基準を満たすオブジェクトの決定)は、極めて広い意味で使用される。「決定する」という用語は、広範囲の動作を包含するため、「決定する」は、算出する、計算する、処理する、導出する、検査する、参照する(例えば、テーブル、データベース、または別のデータ構造を参照する)電子フォーマットまたはデジタル表現にレンダリングする、特定する等を含むことができる。「決定する」は、受信すること(例えば、情報を受信すること)、アクセスすること(例えば、メモリ内のデータにアクセスすること)等も含むことができる。また、「決定する」は、解決すること、選択すること、選ぶこと、確立すること等も含むことができる。
「決定する」という用語は、確実性または絶対的な正確さを含意せず、したがって、「決定する」は、推定すること、推断すること、予測すること、推測すること、平均化すること等を含むことができる。
「決定する」という用語は、数学的処理を実施しなければならないことを含意せず、数値的方法を使用しなければならないことを含意せず、かつアルゴリズムが使用されることを含意しない。
「決定する」という用語は、特定の任意のデバイスを使用しなければならないことを含意しない。例えば、コンピュータが決定することを実施する必要は必ずしもない。
「決定する」という用語は、「算出する」ことを含んでもよい。「算出する」という用語は、1つ以上の算出を実施することを含むと理解されるべきである。算出することは、計算すること、処理すること、および/または導出することを含んでもよい。算出することは、コンピューティングデバイスによって実施され得る。例えば、事柄を算出することは、コンピュータプロセッサによってアルゴリズムをデータに適用すること、およびプロセッサの出力として事柄を生成することを含み得る。
「決定する」という用語は、「参照する」ことを含んでもよい。「参照する」という用語は、1つ以上の参照を、例えば、事柄に対してなすことを含むと理解されるべきである。参照することは、問い合わせること、アクセスすること、選択すること、選ぶこと、読み出すこと、および/または検索することを含み得る。参照する作動は、コンピューティングデバイスによって実施され得る。例えば、事柄を参照することは、事柄がプロセッサによって記憶されるメモリ場所を読み出すことを含んでもよい。
「決定する」という用語は、「受信する」ことを含んでもよい。例えば、事柄を受信することは、事柄を取り込むことを含んでもよい。いくつかの実施形態では、受信することは、事柄が通って取り込まれるネットワークインターフェースを動作すること等の事柄を取り込むように実施された作動を含んでもよい。いくつかの実施形態では、受信することは、ダイレクトメモリ書き込みまたはハードワイヤード回路等において事柄を取り込むように実施された作動なしに実施されてもよい。事柄を受信することは、事柄を算出した可能性があるリモート情報源から事柄を受信することを含んでもよい。
III.文章の形態
第1の請求項の制限が、特徴の1つならびに特徴のうちの2つ以上を包含し(例えば、「少なくとも1つのウィジェット」等の制限は、1つのウィジェットならびに2つ以上のウィジェットを包含する)、第1の請求項に従属する第2の請求項において、第2の請求項が、その制限を指すために定冠詞「前記(the)」を使用する場合(例えば、「前記ウィジェット(the widget)」)、この単なる使用は、第1の請求項が特徴のうちの1つのみを包含することを含意せず、第2の請求項が特徴のうちの1つのみを包含することを含意しない(例えば、「前記ウィジェット」は、1つのウィジェットおよび2つ以上のウィジェットの両方を包含することができる)。
序数(「第1の」、「第2の」、「第3の」等)が用語の前に形容詞として使用される場合、その序数は(その他特に明示的に記載のない限り)、単に、特定の特徴を同じ用語または同様の用語で説明される別の特徴と区別するため等の特定の特徴を示すために使用されるが、その序数は、任意の他の意味または限定効果を有しない、単に便宜上の名称である。例えば、「第1のウィジェット」は、単に、例えば「第2のウィジェット」から区別するためにそのような名称を有し得る。したがって、「ウィジェット」という用語の前に単に序数「第1の」および「第2の」を使用することは、2つのウィジェットの他のいかなる関係も示さず、同様に、いずれかまたは両方のウィジェットの他のいかなる特性も示さない。例えば、「ウィジェット」という用語の前に単に序数「第1の」および「第2の」を使用することは、(1)いずれかのウィジェットの順序または場所が他の任意のウィジェットの前または後にくることを示さず、(2)いずれかのウィジェットが、他の任意のウィジェットの時間的に前または後に発生するか、または作動することを示さず、かつ(3)いずれかのウィジェットが、重要性または品質において他の任意のウィジェットよりも上または下にランクされることを示さない。単なる序数の使用は、序数を使用して識別される特徴に対する数値的制限を定義しない。例えば、「ウィジェット」という用語の前の序数「第1の」および「第2の」の単なる使用は、ウィジェットが厳密に2個存在することを示さない。
単一のデバイス、物品、または他の製品が本明細書において述べられる場合、別の実施形態では、代替として、説明される単一のデバイスまたは物品に代えて2つ以上のデバイスまたは物品を(連携するか否かに関わりなく)使用してもよい。したがって、別の実施形態では、デバイスによって処理されると説明される機能は、代替として、2つ以上のデバイスまたは物品によって所有されてもよい(連携するか否かに関わりなく)。
同様に、2つ以上のデバイス、物品、または他の製品が本明細書において述べられる場合(連携するか否かに関わりなく)、別の実施形態では、代替として、述べられている2つ以上のデバイスまたは物品に代えて、単一のデバイスまたは物品を使用してもよい。例えば、複数のコンピュータベースのデバイスを単一のコンピュータベースのデバイスで置き換えてもよい。いくつかの実施形態では、このような複数のコンピュータベースのデバイスは、グリッドコンピューティングシステムにおいて一般的であるようなプロセスの1つのステップを実施するように一緒に動作し得る。いくつかの実施形態では、複数のものが、クラウドコンピューティングシステムにおいて一般的であるようなプロセスの1つのステップを実施するように動作し得るように、このような複数のコンピュータベースのデバイスは、互いに追加された機能性を動作し得、且つ提供し得る。(逆に、単一のコンピュータベースのデバイスは、互いに連携して動作する複数のコンピュータベースのデバイスで置き換えてもよい。例えば、単一のコンピューティングデバイスは、インターネットを介して互いに通信しているサーバおよびワークステーションで置き換えてもよい。)したがって、2つ以上のデバイスまたは物品によって処理されると述べられる様々な機能は、代替として、単一のデバイスまたは物品によって所有されてもよい。
述べられる単一のデバイスの機能および/または特徴は、別の実施形態では、代替として、述べられているが、このような機能または特徴を有するものとして明示的に述べられていない1つ以上の他のデバイスで実施してもよい。したがって、他の実施形態は、述べられたデバイス自体を含む必要はなく、むしろ、これら他の実施形態において、このような機能または特徴を有する1つ以上の他のデバイスを含んでもよい。
IV.開示される例および用語は非制限的である
名称(本明細書の第1のページの先頭に記載)も要約(本明細書の最後に記載)も決して、開示される発明の範囲を限定すると解釈されてはならず、任意の請求項の意味を解釈する際に使用されてはならず、任意の請求項の範囲を限定する際に使用されてはならない。要約は、37.C.F.R.の1.72(b)下で必要であることを理由としてのみ、要約は本明細書に含まれる。
本願に提供される項の見出しは便宜を図るためのみであり、本開示を制限するものとして決して解釈されるべきではない。
多くの実施形態が本願において説明され、例示のみを目的として提示される。説明される実施形態は、決して制限せず、決して制限を目的としない。開示される発明は、本開示から容易に明らかなように、多くの実施形態に対して広く適用可能である。当業者ならば、構造的、論理的、ソフトウェアの、および電気的な修正等の様々な修正および変更を加えて、開示される発明を実施してもよいことを理解するであろう。開示される発明の特定の特徴を、1つ以上の特定の実施形態および/または図面を参照して説明することがあるが、このような特徴が、その他特に明示的に記載のない限り、参照して説明される1つ以上の特定の実施形態または図面内の使用法に制限されないことを理解されたい。
一実施形態は、いくつかの特徴を含むとして開示されてもよいが、本発明の他の実施形態は、全てのこのような特徴よりも少ない特徴を含んでもよい。このため、例えば、一請求項は、開示される実施形態において、全体の組の特徴よりも少ない特徴に関してもよく、このような請求項は、請求項が明示的に記載するそれらの特徴以外の特徴を必要とするとして解釈されることはない。
本願において説明される方法ステップまたは製品要素の実施形態は、本明細書においてそのように明示的に記述されるか、または(特許請求の範囲およびその特許請求の範囲によって定義される本発明に関して)その特許請求の範囲内で明示的に記載される場合を除き、本明細書において請求される本発明を構成せず、本明細書において請求される本発明にとって必須ではなく、または本明細書において請求される本発明と同一の広がりを持たない。
法定分類以外の任意のものを記す特許請求の範囲の任意のプリアンブルは、請求される本発明の目的、利点、および可能な使用法を記すと解釈されるものとし、このようなプリアンブルは、請求される本発明を制限するように解釈されるものとしない。
本開示は、本発明の全ての実施形態の文字通りに正確な説明ではない。また、本開示は、全ての実施形態に存在することが必要である、本発明の特徴の列挙ではない。
全ての開示される実施形態は必ずしも請求項によって網羅されない(全ての保留、変更、公開、および取り消された請求項を含む場合であっても)。加えて、開示される実施形態は、いくつかの請求項によって網羅されてもよい(しかし、必ずしも網羅される必要はない)。したがって、一請求項(保留、変更、公開、または取り消しに関わりなく)が特定の実施形態に関する場合、これは、他の請求項の範囲もその実施形態に関係するということはないという証拠ではない。
互いに通信するものとして説明されるデバイスは、その他特に明示的に記載のない限り、互いに連続して通信する必要はない。逆に、このようなデバイスは、必要または所望に応じて互いに伝送する必要があるだけであり、実際には、大半の時間においてデータを交換しなくてもよい。例えば、インターネットを介して別のマシンと通信するマシンは、長期間(例えば、1度に数週間)にわたって他のマシンにデータを伝送しなくてもよい。これに加えて、互いに通信するデバイスは、直接通信してもよく、または1つ以上の媒介物を通して間接的に通信してもよい。デバイスは、それらが互いに少なくとも一方向の通信ができている場合、互いに通信している。例えば、第1のデバイスは、第1のデバイスが第2のデバイスに情報を伝送できている場合、第2のデバイスと通信している。同様に、第2のデバイスは、第2のデバイスが第1のデバイスから情報を受信できている場合、第1のデバイスと通信している。
いくつかの構成要素または特徴を有する一実施形態の説明は、このような構成要素または特徴の全てまたは任意のものが要求されることを含意しない。逆に、本発明の広範囲の可能な実施形態を示すために、様々な任意選択的な構成要素が説明される。別段の明示的な定めがない限り、構成要素または特徴は必須ではなく、または要求されない。
プロセスステップ、アルゴリズム等は、特定の逐次順で説明または請求されることがあるが、このようなプロセスは異なる順序で働くように構成することが可能である。
換言すれば、明示的に説明または請求され得るステップのいかなる順序または順番も、ステップをその順番で実施するという要件を必ずしも示すものではない。本明細書において説明されるプロセスのステップは、可能な任意の順番で実施することができる。更に、(例えば、あるステップが他のステップの後に説明されるため)同時に行われるものとして説明または含意されていないにもかかわらず、いくつかのステップを同時に実施してもよい。更に、図面内の説明によるプロセスの例示は、例示されたプロセスが他の変形および変更を除外することを含意せず、例示されたプロセスまたはそのステップの任意のものが本発明にとって必要であることを含意せず、かつ例示されたプロセスが好ましいことを含意しない。
プロセスを複数のステップを含むものとして説明することがあるが、それは、ステップのうちの全てまたは任意のものが好ましい、必須である、または要求されることを含意しない。本発明の範囲内の多様な他の実施形態は、記載のステップのうちのいくつか、または全てを省略する他のプロセスを含む。その他特に明示的に記載のない限り、どのステップも必須または必要ではない。
プロセスを単独で、すなわち他の製品または方法を参照せずに説明し得るが、一実施形態では、プロセスは他の製品または方法と相互作用してもよい。例えば、このような相互作用は、あるビジネスモデルを別のビジネスモデルにリンクすることを含み得る。このような相互作用は、プロセスの柔軟性または望ましさを向上させるために提供することができる。
製品は、複数の構成要素、態様、数量、特性、および/または特徴を含むものとして説明され得るが、それは、これら複数のうちのいくつかまたは全てが好ましい、必須である、または要求されることを示さない。記載される本発明の範囲内の他の様々な実施形態は、説明される複数のうちのいくつかまたは全てを省いた他の製品を含む。
アイテム(付番されているものもあれば、ないものもある)の列挙リストは、その他特に明示的に記載のない限り、アイテムのうちの任意のものまたは全てが相互に排他的であることを含意しない。同様に、アイテム(付番されているものもあれば、ないものもある)の列挙リストは、その他特に明示的に記載のない限り、アイテムのうちの任意のものまたは全てが任意のカテゴリを包括するものであることを含意しない。例えば、列挙リスト「コンピュータ、ラップトップ、およびPDA」は、そのリストの3つのアイテムのうちの任意のもの又は全てが相互に排他的であることを含意せず、そのリストの3つのアイテムのうちの任意のものまたは全てが任意のカテゴリを包括することを含意しない。
アイテム(付番されているものもあれば、ないものもある)の列挙リストは、アイテムのうちの任意のものまたは全てが、互いに等価である、または互いに容易に置換されることを含意しない。
全ての実施形態は例示的であり、場合によっては、本発明またはあらゆる実施形態が作成または実施されたことを含意しない。
V.コンピューティング
本明細書において説明する様々なプロセスは、例えば、適宜プログラムされた汎用コンピュータ、専用コンピュータ、およびコンピューティングデバイスによって実施してもよいことを当業者ならば容易に理解するであろう。通常、プロセッサ(例えば、1つ以上のマイクロプロセッサ、1つ以上のマイクロコントローラ、1つ以上のデジタル信号プロセッサ)は、命令を受け取り(例えば、メモリまたは同様のデバイスから)、それら命令を実施し、それにより、命令によって定義される1つ以上のプロセスを実行する。命令は、例えば、1つ以上のコンピュータプログラム、1つ以上のスクリプトで実施することができる。
「計算」という用語は、ソフトウェアアルゴリズムに関してプロセッサを使用することを決定することを意味するものとする。
「プロセッサ」は、アーキテクチャ(例えば、チップレベルマルチプロセッシングまたはマルチコア、RISC、CISC、インターロックパイプラインステージを有さないマイクロプロセッサ、パイプライン構成、同時マルチスレッド、統合型グラフィックス処理装置付きマイクロプロセッサ(microprocessor with integrated graphics processing unit)、GPGPU)に関わりなく、1つ以上のマイクロプロセッサ、中央演算処理装置(CPU)、コンピューティングデバイス、マイクロコントローラ、デジタル信号プロセッサ、グラフィックス処理装置(GPU)、同様のデバイス、またはこれらの任意の組み合わせを意味する。
「コンピューティングデバイス」は、アーキテクチャ(例えば、チップレベルマルチプロセッシングまたはマルチコア、RISC、CISC、インターロックパイプラインステージを有さないマイクロプロセッサ、パイプライン構成、同時マルチスレッド)に関わりなく、1つ以上のマイクロプロセッサ、中央演算処理装置(CPU)、コンピューティングデバイス、マイクロコントローラ、デジタル信号プロセッサ、グラフィックスカード、モバイルゲームデバイス、同様のデバイス、またはこれらの任意の組み合わせを意味する。
したがって、プロセスの説明は同様に、プロセスを実施するための装置の説明でもある。プロセスを実施する装置は、例えば、プロセッサおよびプロセスの実施に適した入出力デバイスを含むことができる。例えば、プロセスの説明は、プロセッサと、プロセッサによって実行されたとき、プロセッサに方法を実施するように指示する命令を含むプログラムを記憶するメモリと、を備える装置の説明である。
プロセスを実施する装置は、プロセスを実施するために一緒に稼働する複数のコンピューティングデバイスを含むことができる。コンピューティングデバイスのうちのいくつかは、プロセスの各ステップを実施するために一緒に稼働し得、プロセスの別個のステップについて稼働し得、プロセスの実施を容易にし得るその他のコンピューティングデバイスに基礎となるサービスを提供し得る。このようなコンピューティングデバイスは、中央権限の命令下で作動し得る。別の実施形態では、このようなコンピューティングデバイスは、中央権限の命令なしで作動し得る。このような方法のうちのいくつかまたは全てにおいて動作し得る装置のうちのいくつかの実施例は、グリッドコンピュータシステム、クラウドコンピュータシステム、ピアツーピアコンピュータシステム、サービスとしてソフトウェアを提供するように構成されるコンピュータシステム等を含み得る。例えば、装置は、VMwareソフトウェアを実行するコンピュータシステム等の、その処理ロードのバルクをリモートサーバ上で実行するが、ローカルユーザコンピュータに表示情報を出力し、ローカルユーザコンピュータからユーザ入力情報を受信するコンピュータシステムを含み得る。
更に、このような方法を実施するプログラム(ならびに他の種類のデータ)は、様々な媒体(例えば、コンピュータ可読媒体)を使用していくつかの様式で記憶し伝送することができる。いくつかの実施形態では、様々な実施形態のプロセスを実施することができるソフトウェア命令のうちのいくつかまたは全てに代えて、またはそれと組み合わせて、ハードワイヤード回路またはカスタムハードウェアを使用してもよい。したがって、ソフトウェアのみに代えて、ハードウェアおよびソフトウェアの様々な組み合わせを使用してもよい。
「コンピュータ可読媒体」という用語は、コンピュータ、プロセッサ、または同様のデバイスにより読み取り可能な、データ(例えば、命令、データ構造)の提供に関与する任意の非一時的媒体、複数の同じ媒体、または異なる媒体の組み合わせを指す。このような媒体は、不揮発性媒体、揮発性媒体、および伝送媒体を含むがこれらに制限されない多くの形態をとり得る。不揮発性媒体は、例えば、光ディスク、磁気ディスク、および他の永久メモリを含む。揮発性媒体は、通常、メインメモリを構成するダイナミックランダムアクセスメモリ(DRAM)を含む。伝送媒体は、プロセッサに結合されるシステムバスを構成する線を含め、同軸ケーブル、銅線、および光ファイバを含む。伝送媒体は、音波、光波、および無線周波(RF)および赤外線(IR)データ通信中に生成されるような電磁波(electromagnetic emission)を含むか、または伝達することができる。コンピュータ可読媒体の一般的な形態としては、例えば、フロッピー(登録商標)ディスク、フレキシブルディスク、ハードディスク、磁気テープ、他の任意の磁気媒体、CD−ROM、DVD、他の任意の光学媒体、パンチカード、紙テープ、パターンになった穴を有する他の任意の物理媒体、RAM、PROM、EPROM、フラッシュEEPROM、他の任意のメモリチップまたはカートリッジ、後述する搬送波、またはコンピュータが読み取り可能な他の任意の媒体が挙げられる。
「有形のコンピュータ可読媒体」という用語は、光学または磁気ディスク等のハードウェア構成要素を備える「コンピュータ可読媒体」を指す。
様々な形態のコンピュータ可読媒体が、データ(例えば、命令シーケンス)のプロセッサへの搬送に関与し得る。例えば、データは、(i)RAMからプロセッサに送出され、(ii)無線伝送媒体を介して搬送され、(iii)イーサネット(登録商標)(またはIEEE802.3)、それらがWiFi Allianceによって承認されたかどうかのIEEE802.11仕様書によって定義される無線ローカルエリアネットワーク通信、SAP、ATP、Bluetooth(登録商標)、およびTCP/IP、TDMA、CDMA、および3G等の多くの形式、規格、またはプロトコルに従ってフォーマットされおよび/または伝送され、および/または(iv)当分野において周知の様々な方法のうちの任意の方法で暗号化されて、プライバシーを確保し、不正を阻止することができるものであることとしてもよい。
「データベース」という用語は、検索可能な形式で記憶されるデータの任意の電子記憶されるコレクションを指す。
「データ構造」という用語は、コンピュータ等のハードウェアマシン内のデータベースを指す。
「ネットワーク」という用語は、通信経路によって相互接続される一連のポイントまたはノードを意味する。例えば、ネットワークは、1つ以上の有線および/または無線通信経路によって相互接続される複数のコンピュータまたは通信デバイスを含み得る。ネットワークは、他のネットワークと相互接続し得、サブネットワークを含み得る。
「所定の」という用語は、例えば、現在時刻または現在の動作前に、予め決定されていることを意味する。例えば、「所定の値を表示する」という語句は、表示の作動前に決定された値を表示することを意味する。
「条件」という用語は、(1)合意の履行に基づく前提、または(2)何らかの出現または発生に必要不可欠な何か、を意味する。
「トランザクション」という用語は、(1)商品、サービス、または基金の交換または転送、または(2)相互に影響をおよぼすかまたは互いに影響しあう2つの組織または事柄を含む通信動作または活動を意味する。
したがって、プロセスの説明は同様に、プロセスを実施するためのプログラムを記憶するコンピュータ可読媒体の説明でもある。コンピュータ可読媒体は、方法の実施に適したプログラム要素を(任意の適切な形式で)記憶することができる。例えば、プロセスの説明は、プロセッサによって実行されたとき、プロセッサに方法を実施するように指示する命令を含むプログラムを記憶するコンピュータ可読媒体の説明である。
プロセスの様々なステップの説明が、説明される全てのステップが要求されることを示さないのと同様に、装置の実施形態は、説明されたプロセスのうちのいくつか(であるが、必ずしも全てである必要はない)を実行するように動作可能なコンピュータまたはコンピューティングデバイスを含む。
同様に、プロセスの様々なステップの説明が、説明される全てのステップが要求されることを示さないのと同様に、プログラムまたはデータ構造を記憶するコンピュータ可読媒体の実施形態は、実行されると、説明されたプロセスのうちのいくつか(であるが、必ずしも全てである必要はない)をプロセッサに実施させることができるプログラムを記憶するコンピュータ可読媒体を含む。
データベースが説明される場合、(i)説明された構造に対する代替のデータベース構造を容易に利用することができ、かつ(ii)データベース以外の他のメモリ構造も容易に利用することができることを当業者ならば理解するであろう。本明細書において提示される任意のデータベースサンプルのいかなる例示または説明も、記憶された情報表現の例示的な構成である。例えば、図面または他の場所で示されるテーブルによって示唆されるもの以外の任意の数の他の構成を利用してもよい。同様に、データベースの例示されるいかなるエントリも、例示的な情報を表すにすぎず、エントリの数および内容は、本明細書において説明されるものと異なってよいことを当業者ならば理解するであろう。更に、テーブルとしてのデータベースの任意の説明にもかかわらず、本明細書において説明されるデータ型を記憶し操作するために、他の形式(関係データベース、オブジェクトベースモデル、および/または分散データベースを含む)を使用してもよい。同様に、データベースのオブジェクトの方法または挙動を使用して、本明細書において説明されるような様々なプロセスを実施することができる。これに加えて、データベースは、またはこのようなデータベース内のデータにアクセスするデバイスにローカルまたはリモートに既知の様式で記憶することができる。
様々な実施形態は、1つ以上のデバイスと(例えば、通信ネットワークを介して)通信するコンピュータを含むネットワーク環境で動作するように構成することができる。コンピュータは、有線または無線媒体(例えば、インターネット、LAN、WAN、またはイーサネット、トークンリング、電話回線、ケーブル回線、無線チャネル、光通信回線、商業オンラインサービスプロバイダ、電子掲示板システム、衛星通信リンク、上記の任意の組み合わせ)を介して直接または間接的にデバイスと通信することができる。各デバイスは、それ自体、コンピュータと通信するように構成された、インテル(Intel)(登録商標)、ペンティアム(Pentium)(登録商標)、またはセントリノ(Centrino)(商標)、アトム(Atom)(商標)、またはコア(Core)(商標)プロセッサに基づくようなコンピュータまたは他のコンピューティングデバイスを含むことができる。任意の数および種類のデバイスがコンピュータと通信状態であってもよい。
一実施形態では、サーバコンピュータまたは中央権限は必要なくてもよいか、または望ましくない場合がある。例えば、本発明は、一実施形態では、中央権限なしで1つ以上のデバイス上で実施してもよい。このような一実施形態では、サーバコンピュータによって実施されるものとして本明細書において説明されるいかなる機能またはサーバコンピュータに記憶するものとして説明されるデータは、サーバコンピュータに代えて、このような1つ以上のデバイス上で実施してもよいか、または記憶してもよい。
プロセスが説明される場合、一実施形態では、プロセスは一切のユーザ介入なしで動作することが可能である。別の実施形態では、プロセスは、何らかの人的介入を含む(例えば、ステップが、人間により、または人間の支援により実施される)。
本明細書に使用されるとき、「暗号化」という用語は、情報が特別な知識なしに容易に理解可能とならないように、情報を隠蔽または隠匿するためのプロセスを指す。暗号化のプロセスは、プレーンテキストと呼ばれる未加工の情報を暗号化された情報に変換できる。暗号化された情報は、暗号文と呼ばれてもよく、プレーンテキストを暗号文に変換するためのアルゴリズムは、暗号化法として称され得る。暗号化法は、暗号文をプレーンテキストに戻して変換する逆の動作を実施するためにも使用され得る。暗号化法の例としては、換字式暗号化法、転置式暗号化法、およびロータマシンを使用して実装される暗号化法が挙げられる。
種々の暗号化の方法では、暗号化法は、キーと呼ばれる情報の追加片を必要とし得る。キーは、例えば、ビットのストリングからなり得る。キーは、プレーンテキストを暗号化するための暗号化法と合わせて使用され得る。キーはまた、暗号文を解読するための暗号化法と合わせて使用され得る。対称キーアルゴリズムと呼ばれる暗号化法の分類では(例えば、秘密キー暗号法)、同じキーが、暗号化と解読化のいずれにも使用される。暗号化される情報の不可侵性は、したがって、秘密が明らかにされないキーに応じて様々であり得る。対称キーアルゴリズムの例は、DESおよびAESである。非対称キーアルゴリズムと呼ばれる暗号化法の分類では(例えば、公開キー暗号法)、異なるキーが、暗号化および解読化に使用される。非対称キーアルゴリズムでは、公衆の任意のメンバが、プレーンテキストを暗号文に暗号化するために第1のキー(例えば、公開キー)を使用し得る。しかしながら、第2のキー(例えば、秘密キー)の保持者のみが、暗号文をプレーンテキストに戻して解読することができるであろう。非対称キーアルゴリズムの例は、RSAアルゴリズムである。
VI.継続出願
本開示は、いくつかの実施形態および/または発明の実施可能要件の説明を当業者に提供する。これら実施形態および/または発明のうちのいくつかは、本願において請求されないかもしれないが、それでもやはり、本願の優先権の恩恵を主張する1つ以上の継続出願において請求され得る。
出願は、本願において開示され、実施可能要件が提示されたが請求されなかった趣旨について特許を請求するために、追加の出願を提出することを意図する。
VII.米国特許法112条、第6段落
請求項において、「のための手段」という語句または「のためのステップ」という語句を含む請求項の制限は、米国特許法112条、第6段落が、その制限に適用されることを意味する。
請求項において、「のための手段」という語句または「のためのステップ」という語句を含まない請求項の制限は、その制限が、その機能を実施するための構造、材料、または作動の記載を含めずに、機能を記載しているかどうかに関わらず、米国特許法112条、第6段落が、その制限に適用されないことを意味する。例えば、請求項において、その請求項または別の請求項の1つ以上のステップを参照する際の「のステップ(複数可)」という語句の単なる使用は、米国特許法112条、第6段落がそのステップ(複数可)に適用されることを意味しない。
米国特許法112条、第6段落に従って特定の機能を実施するための手段またはステップに関して、本仕様書、およびその同等物に記載される対応する構造、材料、または作動は、追加の機能、ならびに指定された機能を実施することができる。
コンピュータ、プロセッサ、コンピューティングデバイス、および同様な製品は、広範囲の機能を実施することができる構造物である。このような製品は、その製品のメモリデバイスまたはその製品がアクセスするメモリデバイスに記憶されたプログラム等、1つ以上のプログラムを実行することによって、指定された機能を実施するように操作可能であり得る。その他特に明示的に記載のない限り、そのようなプログラムは、本明細書に開示されるかもしれない、任意の特定のアルゴリズム等、任意の特定のプログラムに基づく必要はない。当業者には、指定された機能は、異なるアルゴリズムを介して実装されてもよいこと、いくつかの異なるアルゴリズムのうちのいずれかは、指定された機能を実行するための単なる設計選択肢であることが周知である。
したがって、米国特許法112条、第6段落に従って特定の機能を実施するための手段またはステップに関して、指定された機能に対応する構造物は、指定された機能を実施するようにプログラムされた任意の製品を含む。このような構造物は、このような製品が、(i)機能を実施するための開示されたアルゴリズム、(ii)開示されたアルゴリズムに類似のアルゴリズム、または(iii)機能を実施するための異なるアルゴリズムを用いてプログラムされているかに関わらず、機能を実施する、プログラムされた製品を含む。
方法である機能を実施するための手段が記載されている場合、この方法を実施するための構造物は、その機能を実施するために、適切なハードウェアを用いてプログラムおよび/または構成されるコンピューティングデバイス(例えば、汎用コンピュータ)を含む。
また、当業者によって理解されるであろう他のアルゴリズムを介してその機能を実施するように、適切なハードウェアを用いてプログラムおよび/または構成されるコンピューティングデバイス(例えば汎用コンピュータ)も含まれる。
VIII.放棄
特定の実施形態への多くの参照は、追加の異なる実施形態の放棄または否認を示さず、同様に、全て特定の特徴を含む実施形態の説明への参照も、その特定の特徴を含まない実施形態の放棄または否認を示さない。本願における明確な放棄または否認は、「含まない」という語句または「実施できない」という語句によって前置きされるであろう。
IX.参照による援用
本明細書において参照されるあらゆる特許、特許出願、または他の文献は、本開示の一部として本特許出願に参照により援用されるが、米国特許法第112条第1項による書面での説明および米国特許法第112条第1項による実施可能要件のためにのみであり、このような参照による援用がなければ通常の意味を当業者が確認できなかったという場合ではない限り、本願のいかなる用語の制限、定義、または解釈にも決して使用されるべきではない。したがって、当業者は、参照により提供されるいかなる実施形態によっても決して制限される必要はない。逆に、本明細書に提供される定義は、参照により本明細書に組み込まれるいずれの文書のいずれの用語も限定、定義、または別段に解釈されるように使用されるべきではない。本明細書に明示的に記載される定義は、定義(複数可)と矛盾し得る特定の実施形態の説明にかかわらず統制している。
参照による援用はいずれもそれ自体は、本特許出願において別段の明示的な定めがない限り、援用されるいかなる特許、特許出願、または他の文献に含まれるいかなる記述、意見、議論、または特徴のいかなる裏書き、承認、または黙認も含意しない。
X.審査経過
(特許請求の範囲を含む)本願を解釈するに際して、当業者は、本願に関連すると考えられる他の特許出願があるか否かに関わりなく、また本願と優先権の主張を共有する他の特許出願があるか否かに関わりなく、任意の他の特許または特許出願の経過履歴ではなく、本願の審査経過を参照する。
〔付記1〕
特定の取引者のワークステーションに関連付けられた少なくとも1つのプロセッサと、
命令が格納された少なくとも1つのメモリと、を備え、前記命令は、前記少なくとも1つのプロセッサによって実行された場合に、前記少なくとも1つのプロセッサに対し、
アイテムに対する、第1の充足率及び第1の応答時間に関連付けられた第1の注文を受信するステップと、
前記第1の注文を受信した後に、前記アイテムに対する、第2の充足率及び第2の応答時間に関連付けられた第2の注文を受信するステップと、
前記特定の取引者の注文帳において、前記第1の注文に関連付けられた前記第1の充足率及び前記第1の応答時間と、前記第2の注文の前記第1の充足率及び前記第1の応答時間と、に少なくとも部分的に基づいて、前記第2の注文を、前記第1の注文より優先して注文するステップと、
前記注文帳において、前記第2の注文を、前記第1の注文より優先して注文することに応答して、前記第1の注文に対抗する、前記特定の取引者のいかなる注文のいかなる執行よりも前に、前記特定の取引者の注文を、前記第2の注文に対抗して執行されるようにするステップと、を更に指示する、
装置。
〔付記2〕
前記第1の注文を受信する前記ステップは、前記第1の充足率を受信することを含み、前記第2の注文を受信する前記ステップは、前記第2の充足率を受信することを含む、付記1に記載の装置。
〔付記3〕
前記第1の充足率は、前記第1の注文のプロバイダにルーティングされた注文が前記第1の注文の前記プロバイダによって応じられた回数と、前記第1の注文の前記プロバイダにルーティングされた注文が前記第1の注文の前記プロバイダによって応じられなかった回数と、の比較に基づいて決定される、付記1に記載の装置。
〔付記4〕
前記第1の充足率は、前記第1の注文のプロバイダにルーティングされた、前記アイテムに対する注文が前記第1の注文の前記プロバイダによって応じられた回数と、前記第1の注文の前記プロバイダにルーティングされた、前記アイテムに対する注文が前記第1の注文の前記プロバイダによって応じられなかった回数と、の比較に基づいて決定される、付記1に記載の装置。
〔付記5〕
前記第1の充足率は、前記第1の注文のプロバイダにルーティングされ、前記第1の注文の前記プロバイダによって応じられた総量と、前記第1の注文の前記プロバイダにルーティングされ、前記第1の注文の前記プロバイダによって応じられなかった総量と、の比較に基づいて決定される、付記1に記載の装置。
〔付記6〕
前記第1の充足率は、前記第1の注文のプロバイダにルーティングされ、前記第1の注文の前記プロバイダによって応じられた、前記アイテムの総量と、前記第1の注文の前記プロバイダにルーティングされ、前記第1の注文の前記プロバイダによって応じられなかった、前記アイテムの総量と、の比較に基づいて決定される、付記1に記載の装置。
〔付記7〕
前記第1の充足率は、前記第1の注文のプロバイダにルーティングされた、前記アイテムに対する特定の量の範囲の注文が前記第1の注文の前記プロバイダによって応じられた回数と、前記第1の注文の前記プロバイダにルーティングされた、前記アイテムに対する前記特定の量の範囲の注文が前記第1の注文の前記プロバイダによって応じられなかった回数と、の比較に基づいて決定される、付記1に記載の装置。
〔付記8〕
前記第2の注文は第1の応答時間に関連付けられ、前記命令は、少なくとも1つのプロセッサによって実行された場合に、前記少なくとも1つのプロセッサに対し、
前記第2の注文を受信するより先に、前記アイテムに対する第3のユーザからの第3の注文を前記少なくとも1つのサーバにより受信するステップであり、前記第3の注文は、価格が前記第2の注文の価格と等しく、前記第3の注文は、前記第1の応答時間より長い第2の応答時間に関連付けられている、前記ステップと、
少なくとも1つのサーバにより、前記注文帳において、前記第2の注文に関連付けられた前記第1の応答時間より長い、前記第3の注文に関連付けられた前記第2の応答時間に少なくとも部分的に基づいて、前記第2の注文を、前記第3の注文より優先して注文するステップと、を更に指示し、
少なくとも1つのサーバにより前記取引コマンドを前記第2のユーザまで伝達する前記ステップは、前記少なくとも1つのサーバにより、前記アイテムに関するいかなる取引コマンドを前記第3のユーザに伝達するステップよりも先に行われ、前記伝達するステップは、前記注文帳において前記第2の注文が前記第3の注文より優先して注文されることに応答して行われる、
付記1に記載の装置。
〔付記9〕
前記命令は、前記少なくとも1つのプロセッサによって実行された場合に、前記少なくとも1つのプロセッサに対し、
第3の注文及び第4の注文を受信するステップと、
前記第3の注文の少なくとも一部分が、前記第1の注文の少なくとも一部分から独立していない確率を求めるステップと、
前記求められた、前記第3の注文の少なくとも一部分が、前記第1の注文の少なくとも一部分から独立していない確率に少なくとも部分的に基づいて、前記注文帳に記載されている前記第3の注文及び前記第4の注文を注文するステップと、を更に指示する、
付記1に記載の装置。
〔付記10〕
前記第1の充足率は、単位時間当たりの応じる確率を含み、前記第2の充足率は、単位時間当たりの応じる確率を含む、付記1に記載の装置。
〔付記11〕
少なくとも1つのサーバにより、アイテムに対する第1の注文及び第2の注文を受信するステップであって、
前記第1の注文は第1のユーザに関連付けられており、前記第2の注文は第2のユーザに関連付けられており、
前記第1及び第2の注文は、関連付けられている価格が同じであり、
前記第1の注文は、前記第2の注文より先に受信され、
前記第1の注文には第1の充足率が関連付けられ、
前記第2の注文には第2の充足率が関連付けられる、前記ステップと、
少なくとも1つのサーバにより、前記アイテムを買うか売る為のコマンドを受信するステップであって、前記コマンドは、それに関連付けられた条件を有する、前記ステップと、
少なくとも1つのサーバにより、前記第1の注文に関連付けられた前記第1の充足率が前記閾値を満たさないと判定するステップと、
前記第1の注文に関連付けられた前記第1の充足率が前記閾値を満たさないと判定したことの結果として、少なくとも1つのサーバにより、前記第1の注文を無視し、前記第2の注文に関連付けられた前記第2の充足率が前記条件を満たすかどうかを判定するステップと、
少なくとも1つのサーバにより、前記第2の注文に関連付けられた前記第2の充足率が前記条件を満たすと判定するステップと、
前記第2の注文に関連付けられた前記第2の充足率が前記条件を満たすと判定したことの結果として、少なくとも1つのサーバにより、前記第1の注文に関連するいかなる取引コマンドを伝達するよりも先に、前記第2の注文に関連付けられた取引コマンドを前記第2のユーザに伝達するステップと、
前記第2のユーザに前記取引コマンドを伝達することに応答して、前記第2のユーザが前記取引コマンドに対抗する取引をしようとしているという通知を受信するステップと、
を含む方法。
〔付記12〕
前記第1の注文を受信する前記ステップは、前記第1の充足率を受信することを含み、
前記第2の注文を受信する前記ステップは、前記第2の充足率を受信することを含み、
前記第1の充足率は、単位時間当たりの応じる確率を含み、
前記第2の充足率は、単位時間当たりの応じる確率を含み、
前記条件は、充足率閾値を含み、
前記第2の充足率が前記条件を満たすと判定する前記ステップは、前記第2の充足率が前記閾値より大きいと判定することを含む、
付記11に記載の方法。
〔付記13〕
前記第1の充足率は、前記第1のユーザにルーティングされた注文が前記第1のユーザによって応じられた回数と、前記第1のユーザにルーティングされた注文が前記第1のユーザによって応じられなかった回数と、の比較に基づいて決定され、
前記条件は、充足率閾値を含み、
前記第1の充足率が前記条件を満たさないと判定するステップは、前記第1の充足率が前記閾値より小さいと判定することを含む、
付記11に記載の方法。
〔付記14〕
前記第1の充足率は、前記第1のユーザにルーティングされた、前記アイテムに対する注文が前記第1のユーザによって応じられた回数と、前記第1のユーザにルーティングされた、前記アイテムに対する注文が前記第1のユーザによって応じられなかった回数と、の比較に基づいて決定される、付記11に記載の方法。
〔付記15〕
前記第1の充足率は、前記第1のユーザにルーティングされ、前記第1のユーザによって応じられた総量と、前記第1のユーザにルーティングされ、前記第1のユーザによって応じられなかった総量と、の比較に基づいて決定される、付記11に記載の方法。
〔付記16〕
前記第1の充足率は、前記第1のユーザにルーティングされ、前記第1のユーザによって応じられた前記アイテムの総量と、前記第1のユーザにルーティングされ、前記第1のユーザによって応じられなかった前記アイテムの総量と、の比較に基づいて決定される、付記11に記載の方法。
〔付記17〕
前記第1の充足率は、前記第1のユーザにルーティングされた、前記アイテムに対する特定の量の範囲の注文が前記第1のユーザによって応じられた回数と、前記第1のユーザにルーティングされた、前記アイテムに対する前記特定の量の範囲の注文が前記第1のユーザによって応じられなかった回数と、の比較に基づいて決定される、付記11に記載の方法。
〔付記18〕
前記第2の注文は第1の応答時間に関連付けられ、
前記第2の注文を受信するより先に、前記アイテムに対する第3のユーザからの第3の注文を前記少なくとも1つのサーバにより受信するステップであり、前記第3の注文は、価格が前記第2の注文の価格と等しく、前記第3の注文は、前記第1の応答時間より長い第2の応答時間に関連付けられている、前記ステップと、
少なくとも1つのサーバにより、前記注文帳において、前記第2の注文に関連付けられた前記第1の応答時間より長い、前記第3の注文に関連付けられた前記第2の応答時間に少なくとも部分的に基づいて、前記第2の注文を、前記第3の注文より優先して注文するステップと、を更に含み、
少なくとも1つのサーバにより前記取引コマンドを前記第2のユーザまで伝達する前記ステップは、前記少なくとも1つのサーバにより、前記アイテムに関するいかなる取引コマンドを前記第3のユーザに伝達するステップよりも先に行われ、前記伝達するステップは、前記注文帳において前記第2の注文が前記第3の注文より優先して注文されることに応答して行われる、
付記11に記載の方法。
〔付記19〕
第3の注文及び第4の注文を受信するステップと、
前記第3の注文の少なくとも一部分が、前記第1の注文の少なくとも一部分から独立していない確率を求めるステップと、
前記求められた、前記第3の注文の少なくとも一部分が、前記第1の注文の少なくとも一部分から独立していない確率に少なくとも部分的に基づいて、前記注文帳に記載されている前記第3の注文及び前記第4の注文を注文するステップと、
を更に含む、付記11に記載の方法。
〔付記20〕
命令が格納された非過渡的コンピュータ可読媒体であって、前記命令は、特定の取引者のワークステーションの少なくとも1つのプロセッサによって実行された場合に、前記少なくとも1つのプロセッサに対し、
アイテムに対する、第1の充足率及び第1の応答時間に関連付けられた第1の注文を受信するステップと、
前記第1の注文を受信した後に、前記アイテムに対する、第2の充足率及び第2の応答時間に関連付けられた第2の注文を受信するステップと、
前記特定の取引者の注文帳において、前記第1の注文に関連付けられた前記第1の充足率及び前記第1の応答時間と、前記第2の注文の前記第1の充足率及び前記第1の応答時間と、に少なくとも部分的に基づいて、前記第2の注文を、前記第1の注文より優先して注文するステップと、
前記注文帳において、前記第2の注文を、前記第1の注文より優先して注文することに応答して、前記第1の注文に対抗する、前記特定の取引者のいかなる注文のいかなる執行よりも前に、前記特定の取引者の注文を、前記第2の注文に対抗して執行されるようにするステップと、を指示する、
非過渡的コンピュータ可読媒体