JP6141667B2 - 清算関係に基づく可変価格を有するトレードマッチングプラットフォーム - Google Patents

Description

［１］
この出願は、２０１１年２月２日に出願された米国仮特許出願第６１／４３８，９３３号の優先権を主張する２０１１年１２月６日に出願された米国特許出願第１３／３１２，５３５号の一部継続出願である２０１２年４月２日に出願された米国特許出願第１３／４３７，５８３号の優先権を主張し、かつその一部継続出願であり、これらの先行出願の全ては、参照によりそれらの全体が本明細書に組み入れられる。

［２］
金融業界においては、クレジット・デフォルト・スワップ（ＣＤＳ）、リクエスト・フォー・クオート（ＲＦＱ）、スプレッド注文、および、インプライド注文がよく知られている。

［３］
クレジット・デフォルト・スワップ（ＣＤＳ）は、ＣＤＳの買い手が、売り手に対して一連の支払いをして、それと引き換えに、信用供与の手段（一般的には、担保または貸付け）が債務不履行に陥る（滞納する）場合には支払いを受けるスワップ契約である。それほど多くはないが、支払いを引き起こす信用事由は、会社が再建、破産した、または、更にはその信用格付けが低下したことであり得る。通常、クレジット・デフォルト・スワップの値付けには、２つの競合する理論が挙げられる。「確率モデル」と称される第１の理論は、不履行のない確率により重み付けられる一連のキャッシュフローの現在価格をとる。この方法は、クレジット・デフォルト・スワップは社債よりもかなり低いスプレッドでトレードしなければならないことを示唆する。第２のモデルは、ダレル・デュフィー（Ｄａｒｒｅｌｌ Ｄｕｆｆｉｅ）によって提案され、ジョーン・ハル（Ｊｏｈｎ Ｈｕｌｌ）およびホワイト（Ｗｈｉｔｅ）によっても提案されたものであり、非裁定手法を使用する。クレジット・デフォルト・スワップに値付けし、それらの決済価格を決定する様々な技術が業界で知られている。

［４］
また、トレーダー（および他の者）は、リクエスト・フォー・クオート（ＲＦＱまたはｅＲＦＱ）を取引所および／または規制されたトレーディングプラットフォームへ提出する場合がある。ＲＦＱは取引所へ提出される注文に類似するが、ＲＦＱは、ＲＦＱに拘束力がなく直ぐに取引実行できないという点において注文とは異なる。ＲＦＱは、当該技術分野においてよく知られており、特定の金融商品における現在の市場に関して問い合わせるためにトレーダー、清算機関、および／または、取引所によって一般に使用される。しかしながら、ＲＦＱは時として濫用される。例えば、トレーダーは、注文に拘束されることなく特定の金融商品に関する他のトレーダーの価格を確かめようとする試みにおいてＲＦＱを用いて市場を氾濫させる場合がある。ＲＦＱに応答するトレーダー（例えば、マーケットメーカー、他のトレーダーなど）は、ＲＦＱの膨大な量に起因して、ＲＦＱを無視する場合がある。残念ながら、そのような挙動に起因して、濫用でないＲＦＱが応答されないままとなる場合がある。また、幾つかのシナリオにおいて、マーケットメーカーは、ＲＦＱに応答しなければならない契約上の義務を負うが、依然としてＲＦＱに熱心に応答するまでには至らず、したがって、取引所に対する否定的な見方がもたらされる。ＲＦＱに加えて、トレーダーは、最初に、例えば参照することによりその全体が本願に組み入れられる「インプライド・スプレッド・トレーディング・システム（Ｉｍｐｌｉｅｄ Ｓｐｒｅａｄ Ｔｒａｄｉｎｇ Ｓｙｓｔｅｍ）」と題される米国特許第７，５８４，１４０号の図３Ａおよび他の部分に記載されるような、マーケットメーカーからの拘束力のない気配値によるクオートを要求する場合がある。

［５］
また、トレーダーは、時として、しばしばスプレッド注文と呼ばれるものを使用して、複数の金融商品を組み合わせてトレードすることを望む。組み合わせのそれぞれの構成要素はレッグと呼ばれる。トレーダーは、組み合わせ（例えば、取引所によって規定される組み合わせ）を規定して、レッグごとに注文を提出することができ、あるいは、幾つかのケースでは、レッグリスクを回避するために複数の金融商品に関して単一の注文を提出することができる。そのような注文は、ストラテジー注文、スプレッド注文と呼ばれる場合があり、または、様々な他の名前で呼ばれる場合がある。例えば、スプレッドは、価格関係の変化から利益を得るという目的をもった２つの契約間の価格差の注文である。前述の組み合わせ注文にマッチされるカウンターパーティー（相手方）注文は、個別の“アウトライト”注文であってもよく、あるいは、他の組み合わせ注文の一部であってもよい。スプレッド注文の場合、マッチングシステムが、複数の注文を使用してカウンターパーティー注文を生成することによるカウンターパーティー注文を意味する場合がある。スプレッドの例としては、クラック、クラッシュ、ストラドル、ストラングル、バタフライ、カレンダー、および、パックスプレッドが挙げられる。

［６］
インプライド注文は、市場のギャップを埋めて、さもなければ利用可能な買呼値（ビッド）および売呼値（アスク）が殆ど無いあるいは全く無い商品の流動性（リクイディティ）をスプレッドトレーダーおよびアウトライトトレーダーが共有できるようにすることが可能である。したがって、商品の流動性は、インプライド注文の使用によって高められる。例えば、スプレッド市場とアウトライト市場とをリンクさせることにより、インプライドスプレッド取引が市場流動性を高める。インプライドスプレッド取引の例としては、参照により本明細書に組み入れられる「インプライドスプレッドトレーディングシステム（Ｉｍｐｌｉｅｄ Ｓｐｒｅａｄ Ｔｒａｄｉｎｇ Ｓｙｓｔｅｍ）」と題される米国特許出願第１０／９８６，９６７号明細書に開示されるインプライドスプレッド取引が挙げられる。大規模な取引所は、一般に、多数のスプレッド商品およびスプレッド商品のレッグに関する注文控帳（オーダーブック）を有する。電子トレーディングシステム内の潜在的なインプライドスプレッドの特定および処理は、時として、かなりの処理リソースを費やす。参照することによりその全体が本願に組み入れられる「オプションスプレッド気配値のクオートを提供する方法及びシステム（Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｐｒｏｖｉｄｉｎｇ Ｏｐｔｉｏｎ Ｓｐｒｅａｄ Ｉｎｄｉｃａｔｉｖｅ Ｑｕｏｔｅｓ）」と題される米国特許第７，５８４，１４０号明細書は、とりわけ、デリバティブ商品および他のタイプの金融商品をトレードする当事者間での通信帯域幅消費を最小限に抑えるためのシステムおよび方法について記載する。

［７］
最後に、米国商品先物取引委員会（「委員会」または「ＣＦＴＣ」）は、ドッド・フランク・ウォールストリート改革及び消費者保護法（Ｔｉｔｌｅ ＶＩＩ ｏｆ ｔｈｅ Ｄｏｄｄ−Ｆｒａｎｋ Ｗａｌｌ Ｓｔｒｅｅｔ Ｒｅｆｏｒｍ ａｎｄ Ｃｏｎｓｕｍｅｒ Ｐｒｏｔｅｃｔｉｏｎ Ａｃｔ）によって制定される新たな法令規定を実施するための新たな規則、ならびに、手引きおよび許容実務を提案している。スワップ取引執行機関（ＳＥＦ）と呼ばれる規制された事業体の新たなタイプの登録および事業に適用する提案された規則、手引き、および、許容実務は、スワップ取引執行機関の登録および事業に関する新たな条文５ｈを商品取引法（「ＣＥＡ」）に加えるとともに、スワップ取引執行機関でのスワップのリストアップ、取引、および、執行に関する新たな条文２（ｈ）（８）をＣＥＡに加える新たな法定の枠組みを実施する。

［８］
本開示は、とりわけ、少なくとも清算機関属性を備えるエンハンスト金融商品または所望の清算成果を与える方法およびシステムを提供することによって従来技術の限界を克服する。１つの例では、第１および第２の清算機関を特定するエンハンスト金融商品の注文をユーザのコンピュータデバイスから受ける方法が開示される。注文は、マッチングエンジンモジュールと注文処理モジュールとを使用してマッチングされて処理されてもよい。エンハンスト金融商品は、少なくとも第１および第２の清算機関を含む複数の清算機関で利用できる店頭（ＯＴＣ）金融商品に対応してもよい。コンピュータプロセッサは、第１の清算機関でのユーザの注文が直ぐに実行できないが、第２の清算機関でのユーザの注文が直ぐに実行できることを決定してもよい。コンピュータプロセッサは、マッチングされた注文を第２の清算機関へ提出してもよい。また、幾つかの例において、前述した方法は、清算機関指定（例えば、第１の清算機関、第２の清算機関など）を含む市場データ記録（例えば、注文データなど）を取引所から受けることを含んでもよい。コンピュータプロセッサは、送信のためにフォーマットされる情報を生成して、ユーザのコンピュータデバイスで表示してもよい。そのような情報は、幾つかの例では、受けられた市場データ記録の少なくとも一部分を備えるとともに、第１の清算機関に対応するそれらの部分を薄いグレーで表示するようにフォーマットされてもよいが、第２の清算機関に対応するそれらの部分を選択可能にレンダリングしてもよい。また、先の例は市場データ（例えば、注文データ）に言及するが、本開示はそのように限定されない。例えば、先の例において、リクエスト・フォー・クオート（ＲＦＱ）が、ＣＣＰ属性を含むエンハンストＲＦＱをユーザがリクエスト・フォー・クオートプロセッサモジュールへ提出するように置き換えられてもよい。それに応じて、マーケットメーカーおよび／または他の者は、クオートデータ／価格（例えば、気配値のクオート）をユーザへ与えてもよい。

［９］
他の例において、コンピュータプロセッサは、ユーザの設定を検索するために、ユーザデータストアまたはユーザデータベースへアクセスしてもよい。ユーザの設定は、価格を直ぐに実行できないが見ることができる複数の清算機関のうちの１つ以上の第１の表示、価格を直ぐに実行できる複数の清算機関のうちの１つ以上の第２の表示、および、ユーザから制限される複数の清算機関のうちの１つ以上の第３の表示、のうちの１つ、２つ、あるいは、それ以上を備えてもよい。前述の例において、システムは、ユーザのコンピュータデバイスから、少なくとも第１の清算機関、第２の清算機関、および、第３の清算機関を含む複数の清算機関で利用できる店頭商品におけるエンハンスト金融商品に対応する金融識別子を受けてもよい。その後、システムは、第１の表示（例えば、第１の清算機関）および第２の表示（例えば、第２の清算機関）を含む金融識別子の市場データ記録（例えば、注文データ）をユーザのコンピュータデバイスへ送ってもよい。市場データ記録は、幾つかの例では、清算機関、価格（例えば、注文価格）属性、および、金融識別子属性を特定するように構成される属性を少なくとも含んでもよい。システムは、送信のためにフォーマットされる情報を生成してユーザのコンピュータデバイスで表示してもよい。そのようなフォーマットは、幾つかの例では、第１の清算機関に対応する部分を薄いグレーで表示する第１のスタイル、および、第２の清算機関に対応する部分を選択可能にレンダリングする第２のスタイルのうちの少なくとも一方を含むユーザの設定に基づいてもよい。また、幾つかの例において、送信された情報は、スクロールするテキストベースのメッセージングインタフェースの一部としての表示に適合し得るようにフォーマットされてもよい。他の例では、フォーマットされた送信情報が清算機関のマトリクスの一部として表示されてもよい。また、先の例は市場データ（例えば、注文データ）に言及するが、本開示はそのように限定されない。例えば、ユーザ設定に基づいてフォーマットされかつ／またはレンダリングされたデータは、本明細書中に記載されるように、マーケットメーカーおよび／または他の者からのクオートデータ／価格を含んでもよい。

［１０］
また、幾つかの例において、受けられた市場データ記録の価格属性は、エンハンスト金融商品の金融識別子の少なくとも買呼値および売呼値を記憶してもよい。買呼値および売呼値は、清算機関属性で特定される清算機関に固有のものであってもよい。また、幾つかの例において、特定の清算機関の買呼値および売呼値は、複数レベルの深さ（マルチプル・レベルズ・ディープ）またはマーケット・バイ・オーダーであってもよい。１つの例では、データ記録がオーダー・バイ・オーダーを示すレベル２記録であってもよい。レベル２記録は非匿名市場のためであってもよいが、幾つかのシナリオでは、本開示の様々な実施形態に従って、マーケット・バイ・オーダー市場データを匿名市場のために与えることもできる。

［１１］
更なる他の例において、コンピュータシステムは、清算機関識別子（例えば、第２の表示で特定された清算機関、第１の表示で特定された清算機関）および金融識別子を含む最新の市場データを自動的に受けるべく取引所に登録してもよい。結果として、取引所は、価格属性、金融識別子属性、および／または、清算機関属性を少なくとも含む市場データをコンピュータシステムへ送信してもよい。

［１２］
エンハンストＲＦＱに関しては、以下のステップ、すなわち、コンピュータシステムのリクエスト・フォー・クオート（ＲＦＱ）プロセッサモジュールを使用して、金融商品（例えば、先物契約のアウトライト注文、先物契約のスプレッド注文、および、オプション契約のアウトライト注文）のエンハンスト・リクエスト・フォー・クオートを受けるステップであって、エンハンスト・リクエスト・フォー・クオートが少なくとも１つの清算機関を特定するように構成される属性を備えるステップ；コンピュータシステムのコンピュータプロセッサにより、本明細書中に記載される設定を検索するためにユーザデータストアにアクセスするステップ；ＲＦＱプロセッサモジュールを使用して、エンハンスト・リクエスト・フォー・クオートが設定で規定される第３の清算機関を特定するか否かを決定するためにエンハンスト・リクエスト・フォー・クオートの属性にアクセスするステップ；ＲＦＱプロセッサモジュールを使用して、エンハンスト・リクエスト・フォー・クオートを１つ以上のディーラーシステム（または、マーケットメーカーに対応する複数のシステム）へ送るステップ；エンハンスト・リクエスト・フォー・クオートで特定されたそれぞれの清算機関に関する金融商品のクオート価格を１つ以上のディーラーシステム（または、マーケットメーカー）から受けるステップ；ＲＦＱプロセッサモジュールを使用してメッセージを少なくとも単一のサブスクライバーへ送るステップであって、メッセージが異なる清算機関に関する金融商品の複数の価格クオートを含み、メッセージの挙動／配分が、ＲＦＱがダイレクトＲＦＱ、オープンＲＦＱ、または、ハイブリッドＲＦＱ（例えば、気配値のリクエスト・フォー・クオート）であるかどうかに基づいて変化するステップ；ＲＦＱプロセッサモジュールを使用して、エンハンスト・リクエスト・フォー・クオートを遠隔の規制されたトレーディングプラットフォームおよび遠隔のＤＣＭプラットフォームのうちの少なくとも一方へ送るステップ；第１の清算機関に対応する部分が薄いグレーで表示されるとともに第２の清算機関に対応する部分が選択可能にレンダリングされるようにメッセージをユーザのコンピュータシステム上に表示するステップのうちの１つ以上を備えるコンピュータを利用した方法が開示される。当業者であれば、参照により既に本明細書に組み入れられた米国仮特許出願第６１／４３８，９３３号明細書を含めて本明細書中に開示される全体を検討すれば、本明細書中に記載されるステップのうちの１つ以上が、随意的であってもよく、また、先に挙げられた注文とは異なる注文において行なわれてもよいことが分かる。

［１３］
無論、前述した実施形態の方法およびシステムは、他の更なる要素、ステップ、コンピュータ実行可能命令、または、コンピュータ可読データ構造を含んでもよい。これに関しては、他の実施形態も同様に本明細書中に開示されて特許請求の範囲に記載される。例えば、コンピュータシステムは、コンピュータプロセッサと、プロセッサにより実行されるときに本明細書中に記載されるステップのうちの１つ以上をコンピュータシステムに行なわせるコンピュータ実行可能命令を記憶する有形な持続性のコンピュータメモリとを備えてもよい。本開示のこれらの実施形態および他の実施形態の詳細は、添付図面および以下の説明に記載される。本開示の他の特徴および利点は、明細書本文および図面から、ならびに、特許請求の範囲から明らかとなる。

［１４］
本開示の実施形態は特定の部分およびステップにおいて物理的形態をとってもよく、これらの実施形態は、以下の説明に詳しく記載されるとともに、その説明の一部を形成する添付図面に示される。

［１５］
本明細書中に開示されるシステムの様々な態様を実施するために使用することができる例示的なコンピュータネットワークシステムを示す。

［１６］
本明細書中に開示されるシステムの様々な態様を実施するために使用することができる例示的なコンピュータネットワークシステムの一部を示す。

［１７］
本明細書中に開示されるシステムの様々な態様に従って生成し表示することができる例示的なグラフィカルユーザインタフェース（ＧＵＩ）を示す。

［１８］
本明細書中に開示されるシステムの様々な態様に従って実行することができる様々なステップの例示的なフローチャートである。

［１９］
本開示は、複数の清算機関と通信できる規制されたトレーディングプラットフォームについて記載する。特に、本開示の態様は、異なる清算機関で清算することができる価格あるいは原資産となる金融商品／証券の差別化された価格を与えることおよび／または計算することに関する。トレーディングプラットフォームは、マルチ清算環境において完全な透明性および向上した流動性をもって匿名のカウンターパーティーを許容してもよい。幾つかの状況では、トレーディングプラットフォームが非匿名カウンターパーティーを許容してもよい。

［２０］
幾つかの実施形態では、エンハンスト金融商品および高度グラフィカルユーザインタフェース（ＧＵＩ）またはメッセージインタフェースを使用して１つ以上の清算機関およびユーザ（例えば、購入側クライアント、ディーラー（例えば、スワップディーラー）など）と情報をやりとりする規制されたトレーディングプラットフォーム（例えば、ＳＥＦ）を含む環境のための方法、システム、および、装置が開示される。幾つかの実施形態において、ディーラー（または、流動性を与える他の事業体あるいはユーザ）は、複数の清算機関（例えば、１４０Ａ、１４０Ｂ、１４０Ｃ等）でリストアップされるエンハンスト金融商品の異なる価格を計算してもよい。幾つかの例において、価格は、清算機関関係（例えば、クロスマージニング利益、委託保証金、清算のコスト／価格など）によって決定されてもよい。また、価格は、これらに限定されないが、ユーザ（例えば、購入側クライアント）の識別情報（例えば、信用格付け）および注文の規模のうちの１つ以上などの要因によって決まる場合がある。そのような例における規制されたトレーディングプラットフォーム（例えば、ＳＥＦ）は、複数の清算機関で清算されるべきトレードを集めてリストアップしてもよく、また、ユーザがいずれの清算機関で清算できるのか（または、証拠金および他の理由によりユーザがいずれの清算機関で清算したいと望み得るのか）によって決まる異なる価格を、それ以外は同一のトレードに関して有してもよい。そのような例において、グラフィカルユーザインタフェース（ＧＵＩ）は、清算機関（例えば、清算カウンターパーティー）対価格のマトリクス（図３参照）を表示する単一のディスプレイスクリーンまたは複数のスクリーンを含んでもよい。例えば、ｘ軸に沿って異なる清算機関をリストアップするとともに、ｙ軸を横切って同じ金融商品の異なる価格をリストアップする清算マトリクスが表示されてもよい。同様に、幾つかの例では、自動トレーディングシステムが、単一の金融商品に関する清算機関に応じた価格を追跡するためにメッセージインタフェースに基づいてメモリマップを内部に維持してもよい。ユーザは、その金融商品（例えば、店頭（ＯＴＣ）商品、スワップトレードなど）を清算するのに望ましい価格および／または清算カウンターパーティー（ＣＣＰ）を選択するためにＧＵＩ（または、もう一つの方法として、Ｂｌｏｏｍｂｅｒｇ（商標）端末などのスクロールするテキストベースのメッセージングインタフェース）と情報をやりとりしてもよい。

［２１］
本開示に係るシステムによってトレードされ／清算される金融商品は、標準化された店頭（ＯＴＣ）契約商品または注文品を含んでもよい。契約は、協会（例えば、国際スワップ・デリバティブ協会）または事業体（例えば、清算機関、ＳＥＦなど）によって公布される一組の仕様によって標準化され／調整されてもよい。例えば、契約（例えば、金融商品）は、これらに限定されないが、価格、名目元本、満期／期間、トリガー事象（例えば、ＣＤＳの場合）、契約に対する１または複数の当事者（例えば、保証の買い手（プロテクション・バイヤー））の識別表示などの一般的な属性／項目のうちの１つ以上を含んでもよい。１つの例において、価格属性は、配列データ構造の形をとってもよい。また、契約は、望ましい清算機関またはＣＣＰを指定するための属性（例えば、「ＣＣＰ属性」）を含んでもよい。金融商品のＣＣＰ属性は、ワークステーション端末（例えば、コンピュータデバイス１２０）にあるＧＵＩ上（または、もう一つの方法として、メッセージングインタフェース上）での清算機関（またはＣＣＰ、この場合、ＣＣＰは清算機関にリンクされる）のユーザによる選択によって入力されてもよい。ＣＣＰは、１つの清算機関に関してのみ清算してもよく、あるいは、複数の清算機関における清算当事者であってもよい。

［２２］
代わりの実施形態において、金融商品（例えば、ＯＴＣ契約）のＣＣＰ属性は、清算機関を指定しなくてもよく（すなわち、空のまま）、したがって、システムは、ユーザにより既に与えられる初期設定（例えば、デフォルトユーザ設定）および／または他の事業体（例えば、デフォルトグローバルシステム設定）により既に与えられる初期設定に依存してもよい。１つの例において、デフォルトグローバルシステム設定は、規制されたトレーディングプラットフォームに適用されてもよく、また、それが１つの値と共に入力される場合には、対応するユーザ指定の設定に優先するか、または、ユーザ指定の設定が優先するようにしてもよい。初期設定は、特定のタイプの金融商品が取引所を介して特定の清算機関またはシステム（例えば、非ＳＥＦシステム）へ自動的に送られ得るように、より多くのプレファレンスの詳細を与えることができる能力を与えてもよい。例えば、設定は、全てのＩＲＳ契約が清算機関Ｄ（１０４Ｄ）を使用して（例えば、エンハンストＲＦＱによって）清算され／クオートされる一方でＣＤＳ契約が清算機関Ｃを使用して清算される／クオートされることを指示してもよい。設定は、清算機関のそれぞれに対応する固有の識別子のリストを指示してもよい。他の実施形態において、指示は、清算機関のグループにリンクされるポインタであってもよい。例えば、１つの例示的なグループは、その事業方針が、ユーザが清算機関との既存の認可関係を有していなければ買呼値／売呼値（または、エンハンストＲＦＱに応じたクオートデータ）をユーザへ送るのを禁止することであってもよい清算機関であってもよい。ユーザから制限される少なくとも１つの清算機関の第３の指示は、前述した例示的グループを含んでもよい。更なる他の例において、ユーザは、１００件の量の契約に関する注文が２つの清算機関（例えば、清算機関１４０Ａ、１４０Ｂ）のうちのいずれかによって応じられてもよく、また、トレーディングプラットフォームシステム１００がその注文に応じて清算機関１４０Ｃと６０件の契約を清算するとともに他の４０件の契約を清算機関１４０Ｂと清算してもよいことを指示してもよい。この指示（例えば、規則）は、ユーザデータストア（例えば、ユーザデータベース１０２）または他のコンピュータメモリに記憶されてもよい。そのような前述した特徴により、トレーディングプラットフォーム（例えば、コンピュータシステム１００）は、ユーザ（例えば、ユーザデバイス１２０）およびディーラー（例えば、ディーラーデバイス１３０）に対して、彼らが何の情報を受けるのかおよびその情報が下流側のシステム（例えば、システム１００および清算機関１４０）によってどのようにして処理されるのかに関して更に高いレベルの制御を与えることができる場合がある。それにもかかわらず、幾つかの実施形態では、注文（例えば、ＯＴＣ契約、入ってくる注文、受け取った指図など）またはトレードを提出できる能力が、ＣＣＰで利用できる価格に関連して特定のＣＣＰで清算するというユーザの要望／能力と清算関係とによって支配されてもよい。

［２３］
本開示の様々な態様によれば、エンハンスト金融商品に関する市場データ記録は、金融識別子（例えば、「ＩＢＭ」クレジット・デフォルト・スワップ）を備えることに加えて、市場データが何の清算機関（または他の事業体、例えば、ＤＣＭ、非ＳＥＦ、ＳＥＦシステム）に関連するのかを示すフラグまたは識別子を含んでもよい。例えば、本明細書中に記載される「ＣＣＰ属性」は、この関係を示すために市場データ記録に含まれてもよい。あるいは、この「ＣＣＰ属性」は、市場データ記録（例えば、特定の証券に関する価格クオート）が全ての清算機関にわたって有効であることを（例えば、ブランク値を用いて）示してもよい。

［２４］
また、ＣＣＰ属性がリンクされた注文を可能にしてもよく、その場合、ユーザ／ディーラーは、特定の金融商品（例えば、ＩＢＭ ＣＤＳ）の多くの（例えば１０件の）契約を欲していること、および、２つの清算機関のみによって金融商品が清算されることを望んでいることを示唆できてもよい。そのような例では、１０件の契約のうちの一部が清算機関Ａにより清算され、一方、他の契約が清算機関Ｂにより清算されてもよい。また、幾つかの例において、エンハンス型金融商品は、指定された清算機関に応じた異なる価格の指定を含んでもよい。異なる価格の指定は、エンハンスト金融商品の価格属性で列挙されてもよい。あるいは、価格属性は、エンハンスト金融商品に関して応じられる注文の全てにわたって望まれる平均価格を示してもよい。前述した特徴の１つ以上の組み合わせが実施されてもよく、また、そのような組み合わせが本開示によって考慮される。ユーザ／ディーラーは、いずれの注文が清算され／実行されてもよくかつそれらの注文が誰と（例えば、いずれの決済会社と）清算されてよいのかのプレファレンスを示すためにＳＥＦ１００を用いて優先順位設定（例えば、ユーザ設定の一環）を指示してもよい。そのようなリンクされた注文は、ユーザ／ディーラーが別個の契約（例えば、清算機関Ａに関する契約、および、清算機関Ｂに関する他の契約）を作成／管理する必要なく行なうことができる。これは、標準化された契約を前述したＣＣＰ属性と共に使用できるからである。他の例において、ユーザ／ディーラーは、清算機関／会社が注文／要求を完了するための基準ではないことを示すために、ＣＣＰ属性をブランクのままにしてもよい。このようにすると、ＳＥＦ１００は、清算機関のプレファレンスを気にせずに清算のための注文／要求を提出することができる。

［２５］
本明細書の開示によれば、図３に示されるような価格に対する清算機関（または、他の事業体）のマトリクスを備えるグラフィカルユーザインタフェース（ＧＵＩ）を生成および／または表示するためのシステムが考えられる。該システムは、プロセッサ、メモリ、および／または、ディスプレイを備えて、メモリに記録されるコンピュータ実行可能な命令を実行することができる。命令は、ユーザが１つ以上の金融商品を選択して１つ以上の清算機関（または、他の事業体、例えばＤＣＭなど）を指定できるようにしてもよい。命令は、この情報を取得して、後述するようにエンハンストＲＦＱをＳＥＦ１００へ提出してもよく、ＳＥＦ１００は、特定の清算機関（または、他の事業体）に関するクオートの要求をディーラーへ送る。ＳＥＦ１００は、ユーザコンピュータシステム１２０のユーザに対する表示のために、ディーラーからグラフィカルユーザインタフェースへと受けられる情報を収集して整理してもよい。遠隔のユーザコンピュータシステム１２０上に表示されてもよいＧＵＩは、本明細書中に記載されるように、様々な理由により特定のユーザにとって直ぐに使用できない（例えば、薄いグレー表示でレンダリングされる）値を含んでもよいが、他の値は選択可能／直ぐに使用できるようにレンダリングされる。値が直ぐに使用できる／直ぐに使用できないかどうかの決定は、ユーザデータストア１０２に記憶される設定に依存してもよいが、直ぐに使用できる／直ぐに使用できない値のレンダリングは、システム１００（例えば、サーバ側）またはユーザコンピュータシステム１２０（例えば、クライアント側）で行なわれてもよい。

［２６］
幾つかの例において、ユーザ（例えば、コンピュータデバイス１２０のユーザ）は、１つ以上の清算機関（ＣＨ）へ向けられるエンハンスト・リクエスト・フォー・クオート（ＲＦＱ）を要求してもよい。結果として、ユーザには、清算機関マトリクス（例えば、望ましいＣＣＰに基づく差別化された価格）を表示するメッセージングインタフェースまたはＧＵＩが与えられてもよい。米国仮特許出願第６１／４３８，９３３号明細書の付属書類Ｅは、この開示の様々な態様に従って含まれてもよいＲＦＱの態様を与える。特に、米国仮特許出願第６１／４３８，９３３号明細書の付属書類Ｅの図１および図２は、ユーザコンピュータシステム１２０からＲＦＱを受けて（例えば、図４の参照符号４０２を参照）、該ＲＦＱをＲＦＱプロセッサモジュール１４２により（米国仮特許出願第６１／４３８，９３３号明細書の付属書類Ｅに示されるように）処理する規制された規制されたトレーディングシステム（例えば、システム１００）を示す。米国仮特許出願第６１／４３８，９３３号明細書の付属書類Ｅの段落００２８は、ＲＦＱの一部として含まれてもよい多数の項目について説明する。エンハンストＲＦＱは、以下の項目、すなわち、要求されるクオートが買主側かまたは売主側かどうかの指標、カバーされるまたはカバーされない、特定の清算機関でカバーされるＲＦＱを提出するユーザ／事業体に関する統計／情報（例えば、優れた信用格付け、プレミアム状況など）、ＲＦＱの有効期限が切れるまでの時間（例えば、オープンＲＦＱの場合）、「スプレッド最良価格」指標（例えば、“最良価格”に対する単一の清算機関価格）、および、他の項目のうちの１つを含んでもよく、全く含まなくてもよく、または、これらのうちの複数を含んでもよい。

［２７］
本明細書中に開示されるシステムの様々な実施形態によれば、問い合わせるのに望ましい１つ以上の清算機関を指定するために、清算機関（または、非ＳＥＦシステム２１２）属性／項目（例えば、「ＣＣＰ属性」）がＲＦＱ（すなわち、エンハンストＲＦＱ２０６）に含まれてもよい。例えば、ＲＦＱ２０６は、清算機関Ａ（１４０Ａ）および清算機関Ｂ（１０４Ｂ）のみを指定してもよい。このようにすると、ＲＦＱを受けるコンピュータシステム１００は、それらの特定の清算機関での清算に関する情報のみを与えるようにマーケットメーカー１３０に要求することができる。米国仮特許出願第６１／４３８，９３３号明細書の付属書類Ｅの図１および図２に示される１つ以上のモジュール／コンポーネント／システムは、本明細書中で考慮される／開示される特徴を可能にするためにこの開示の図１および図２のシステムに組み込まれてもよい。

［２８］
また、代わりの実施形態では、エンハンストＲＦＱが清算機関を指定しなくてもよく、また、ユーザ（例えば、コンピュータデバイス１２０のユーザ）への表示のために生成される清算マトリクスは、全ての清算機関（または、ユーザへの表示のために利用できる清算機関の一部）を初期設定によって表示してもよい。幾つかの例では、ＣＣＰ属性が空であってもよく、あるいは、（例えば、下位互換性を理由に）レガシーＲＦＱメッセージの場合には、ＣＣＰ属性が存在しなくてもよい。そのような場合、システム１００は、リクエスト・フォー・クオートプロセッサモジュール１４２を使用して、第１の清算機関および第２の清算機関（または、任意の他の最大でｎ個の清算機関）を属性に加えることによりエンハンストＲＦＱを変更し（例えば、図４の参照符号４０４を参照）、その後に、変更されたＲＦＱを１つ以上のディーラーシステム１３０へ送ってよい。更なる他の実施形態において、ユーザは、清算機関を指定しないエンハンストＲＦＱを提出してもよく（または、図示のシステム１００と下位互換性があってもよいＲＦＱを提出してもよく）、また、代わりに、ユーザおよび／または他の事業体により既に与えられた初期設定（例えば、デフォルトグローバルシステム設定）に依存してもよい。他の例において、システム１００は、リクエスト・フォー・クオートプロセッサモジュール１４２を使用して、初期設定（例えば、グローバルおよび／またはユーザ固有）に従って１つ以上の清算機関を属性に加えることによりエンハンストＲＦＱを変更し（例えば、図４の参照符号４０４を参照）、その後に、変更されたＲＦＱを１つ以上のディーラーシステム１３０へ送ってよい。初期設定は、異なる清算機関またはシステム（例えば、非ＳＥＦシステム２１２）が異なるタイプの金融商品に関して指定され得るように、より多くのプレファレンスの詳細を与えることができる能力を与えてもよい。これらの初期設定は、幾つかの例では、所望量に至る清算機関の初期設定の後に最良価格を得たいという望みをもって金融商品に関して送られる成り行き注文をサポートするために使用されてもよい。例えば、システム設定は、全てのＩＲＳ契約が清算機関Ａを使用して清算され／クオートされ、一方でＣＤＳ契約が清算機関Ｃを使用して清算される／クオートされることを指示してもよい。他の例において、ＲＦＱ２０６は、クオートを単一の清算機関に制限する代わりに一組の清算機関（例えば、１４０Ａ、１４０Ｄ）にわたってスプレッドのレッグが清算されてもよいことを指定する先物契約のスプレッド注文のためであってもよい。本開示の様々な態様に係る他の例は、先物契約のアウトライト注文およびオプション契約のアウトライト注文のためのエンハンストＲＦＱを含む。前述した特徴により、トレーディングプラットフォーム（例えば、コンピュータシステム１００）は、前述したように更によいクオート価格などの利益をユーザ／ディーラーに与えることができてもよい。

［２９］
幾つかの例において、特定の商品に関するＲＦＱを提出することができる能力は、ＣＣＰで利用できる価格に関連して特定のＣＣＰで清算したいユーザの要望／清算できるユーザの能力および／または清算関係によって管理されてもよい。また、幾つかの清算機関は、ユーザが清算機関との既存の認可関係を有していなければ買呼値／売呼値（または、エンハンストＲＦＱに応じたクオートデータ）をユーザへ送るのを禁止してもよい事業方針を有してもよい。これらの制限された清算機関によって、システム１００は、コンピュータプロセッサにより、ユーザデータストアにアクセスして、設定を検索する（例えば、図４の参照符号４０６を参照）とともに、エンハンストＲＦＱが制限された清算機関を特定するかどうかを決定してもよい。特定する場合には、ＲＦＱプロセッサモジュール１４２は、エンハンストＲＦＱが１つ以上のディーラーシステム１３０へ送られるのを妨げてもよい（例えば、図４の参照符号４０８を参照）。あるいは、ＲＦＱプロセッサモジュール１４２は、ユーザから制限されるそれらの清算機関を除去するようにエンハンストＲＦＱを変更し、その後、変更されたエンハンストＲＦＱを１つ以上のディーラーシステム１３０（または、マーケットメーカーに対応する複数のシステム）へ送ってもよい（例えば、図４の参照符号４１０を参照）。

［３０］
マーケットメーカーまたはディーラー（例えば、システム１３０のディーラー）は、特定のＣＣＰをクオートするかまたはクオートしないことを選択してもよく、あるいは、特定のＣＣＰで清算したいという自分達の欲求に基づいて異なるスプレッドおよび流動性をクオートすることを選択してもよい。ディーラーシステム１３０がエンハンストＲＦＰにおいて指定された一部のまたは全てのＣＣＰをクオートすることを選択すると、システム１００は、エンハンストＲＦＱにおいて特定されたそれぞれの（すなわち、一部のまたは全ての）清算機関に関するエンハンストＲＦＱの金融商品のクオート価格を１つ以上のディーラーシステムから受けてもよい（例えば、図４の参照符号４１２を参照）。しかしながら、ある場合に、ディーラー／マーケットメーカーが一部のまたは全ての指定された清算機関に関するクオートを与えないことを選択すると、システム１００は代わりの選択肢を探してもよい。１つの例において、システム１００（例えば、ＲＦＱプロセッサモジュール１４２）は、コンピュータシステム１００と通信するように構成される他の規制されたトレーディングプラットフォーム（例えば、ＳＥＦ２００）へエンハンストＲＦＱを送ってもよい（例えば、図４の参照符号４２２を参照）。他のＳＥＦ２００は、ＲＦＱに応じてクオートを進んで与え得るディーラーシステム２３０を含んでもよい。結果として、システム１００は、エンハンストＲＦＱに応じてクオートデータ２０２を他のＳＥＦ２００から（または、ディーラーシステム２３０から直接に）受けてもよい（例えば、図４の参照符号４２４を参照）。代わりの実施形態において、システム１００は、応答クオートのためにＳＥＦシステム２００および／もしくは非ＳＥＦシステム２１２（例えば、遠隔のＤＣＭプラットフォーム）のうちの一方または両方へエンハンストＲＦＱを送ることを選択してもよい。

［３１］
また、本開示の様々な態様に係る他の実施形態において、ＲＦＱプロセッサモジュール１４２は、参照により本明細書に既に組み入れられた米国仮特許出願第６１／４３８，９３３号明細書の付属書類Ｅに記載されて論じられるように、他の規制されたトレーディングプラットフォーム（例えば、ＳＥＦ２００）または非ＳＥＦシステム（例えば、ＤＣＭ２１２）へエンハンストＲＦＱ２０６を提出する前に所定時間待つように構成されてもよい。例えば、ＲＦＱプロセッサモジュール１４２は、時間ｔ１でＲＦＱ２０６を受けてもよい。ＲＦＱプロセッサモジュール１４２におけるタイマーコンポーネントが、ＲＦＱへの応答が受けられるまで、時間ｔ１から所定時間（例えば、１０秒、３０秒、１分、３分、５分未満など）にわたってカウントダウンを始めてもよい。所定時間が経過する前にＲＦＱへの応答が受けられる場合には、ＲＦＱ応答が要求している事業体／個人（例えば、特定の金融商品に関してクオートを要求しているトレーダー１２０）へ送られてもよい。所定時間内に応答が受けられない場合には、エンハンストＲＦＱが他の規制されたトレーディングプラットフォーム（例えば、ＳＥＦ２００）または非ＳＥＦシステム（例えば、ＤＣＭ２１２）へ提出されてもよい。幾つかの例において、ＲＦＱプロセッサモジュール１４２は、ＳＥＦシステムおよび非ＳＥＦシステムの記憶されたリストと情報を清算して、これらのシステムのうちの（全部でない場合）どちらへエンハンストＲＦＱを送るのかを決定してもよい。他の例において、エンハンストＲＦＱは、システム１００と関連するディーラーシステム１３０がＲＦＱに応答しない場合にＳＥＦシステムおよび非ＳＥＦシステムのどちらと接触すべきかを指示してもよい（あるいは、トレーダー１２０のためのユーザ設定が指示してもよい）。幾つかの例において、ＲＦＱプロセッサモジュール１４２は、応答が所定時間内に（例えば、マーケットメーカー１３０から）受けられる場合には、エンハンストＲＦＱを他の規制されたトレーディングプラットフォーム（例えば、ＳＥＦ２００）または非ＳＥＦシステム（例えば、ＤＣＭ２１２）へ提出してもよい。そのような手法の少なくとも１つの利点は、単一のＲＦＱに基づいてより多くの応答クオートを発生させることができるという点である。

［３２］
本開示の様々な態様によれば、外部トレーディングプラットフォーム（例えば、ＳＥＦシステム、ＤＣＭシステム、非ＳＥＦシステム、取引所など）を指定するための項目／属性を含んでもよいエンハンストＲＦＱ２０６が考えられる。そのような実施形態により、ユーザ／ディーラーは、より高い流動性および更に多くのクオートデータを与えるために、多数の異なるＳＥＦシステムおよび非ＳＥＦシステムにわたって及び得るエンハンストＲＦＱを提出することができてもよい。この開示は、エンハンストＲＦＱ（清算機関属性および他の項目を伴う）と１つ以上のＲＦＱプロセッサモジュールとを含むが、インプライドスプレッド決定モジュールなどの米国仮特許出願第６１／４３８，９３３号明細書の付属書類Ｅに記載されるモジュール／コンポーネントの一部または多くを省く方法も考慮する。そのようなシステムでは、エンハンストＲＦＱを提出することにより、清算マトリクス（例えば、図３に示される価格マトリクスなど）がＧＵＩ上に表示される。

［３３］
図３を参照すると、価格マトリクスは、複数の異なるトレーディングプラットフォーム（例えば、非ＳＥＦシステム２１２）または清算機関（例えば、１０４Ａ、１０４Ｂなど）の同じ金融契約／協定に関して異なる価格クオート（例えば、買呼値／売呼値）を見ることができる能力を与えてもよい。受けられた市場データ（または、クオートデータ２０２）は、価格マトリクスを入力するために使用されてもよい。システム１００（例えば、ＲＦＱプロセッサモジュール１４２）は、トレーダー１２０などの少なくとも単一のサブスクライバーへメッセージ（例えば、単一または複数のメッセージ）を送ってもよい。メッセージは、エンハンストＲＦＱによって要求される異なる清算機関（例えば、１４０Ａ、１４０Ｂ）に関する金融商品の複数の価格クオートを含んでもよく、また、複数のレベルの深さおよびマーケット・バイ・オーダーを含むがこれらに限定されない様々な異なる方法で編成されてもよい。システム１００へ提出されるエンハンストＲＦＱ（例えば、ダイレクトＲＦＱ、オープンＲＦＱ、ハイブリッドＲＦＱなど）のタイプに応じて、メッセージが単一または複数のサブスクライバーへ送られてもよい。例えば、ダイレクトＲＦＱの場合には、メッセージが単一のサブスクライバー１２０へ送られてもよい（例えば、図４の参照符号４１４を参照）。ダイレクトＲＦＱは、ユーザ１２０がクオート／トレードを誰に要求したいのかを指定することを望み得る非匿名トレードで一般に使用される。応答しているディーラーシステム１３０により生成されるクオートデータ２０２は、ユーザ１２０のためにカスタマイズされてもよい。他の例では、オープンＲＦＱの場合、メッセージがシステム１００の一部のまたは全てのサブスクライバーへ送られてもよい（例えば、図４の参照符号４２０を参照）。オープンＲＦＱは、ユーザ１２０が関与する当事者を特定することなくクオートを要求することを望み得る匿名トレードで一般に使用される。また、オープンＲＦＱは、ストリーミング注文ができる流動性商品のために一般に使用される。例えば、エンハンストＲＦＱ２０６は、ユーザ１２０が特定の金融商品に関する更新されたクオートデータ２０２を受け取りたい時間を指定してもよい。マーケットメーカー１３０は、特定の対象商品に関する更新されたクオートデータ２０２をシステム１００へ与え続けてもよい。結果として、システム１００は、１つ以上のディーラーシステム１３０から、所定期間にわたって（あるいは、予め決められた時間にわたって）、自動更新方式で、ＣＣＰ属性で特定される指定された清算機関および金融商品に関するクオートデータを受けてもよい（例えば、図４の参照符号４１８参照）。システム１００は、更新されたクオートデータ２０２をユーザ１２０へ送ってもよい。所定時間が経過した後、システム１００は、更新されたクオートデータをユーザ１２０へ送るのを止めてもよい。１つの例において、エンハンストＲＦＱ２０６は、システム１００と関連すると共に外部プラットフォーム（例えば、ＳＥＦ２００およびＤＣＭ２１２）とも関連するマーケットメーカー１３０の両方から流れるクオートデータ２０２を要求するオープンＲＦＱであってもよい。そのようなシステムの利益は多い。

［３４］
図３の例を参照し続けると、受け取ったデータ（例えば、市場データ、クオートデータ２０２、注文データなど）がマーケット・バイ・オーダー（ＭＢＯ）、マーケット・バイ・プライス、または、他のフォーマットのように整理されてもよい。マーケット・バイ・オーダーの場合、データは、匿名であってもよく、あるいは、匿名でなくてもよい。マーケット・バイ・プライスの場合、情報集約されたブックが、価格属性が最良の買呼値および売呼値に加えて次のＮ個（Ｎは複数の数（例えば、２、５、１０など））の最良の買呼値および売呼値を記憶できるように複数のレベルの深さであってもよい。１つの例では、エンハンスト金融商品の価格属性が配列データ構造の形態をとってもよい。幾つかの例では、ユーザの注文が直ぐに実施可能である清算機関に関して複数レベルのデータ（買呼値／売呼値）が利用できてもよいが、複数レベルのデータが他の清算機関から利用できてもよくまたは利用できなくてもよい。各清算機関などに対応する価格は、以下のファクタ、すなわち、清算機関で清算する価格、クロスマージニング、および、他のファクタを含むがこれらに限定されないファクタのうちの１つ以上によって決まってもよい。図３の例示的な価格マトリクス（例えば、清算機関マトリクス）を参照すると、ＧＵＩ３００が様々な清算機関（または、他の事業体、例えば指定された契約市場（ＤＣＭ）および他の非ＳＥＦ２１２）に関する価格情報を含んでもよい。例えば、１つの例では、清算機関Ａ（１４０Ａ）に関する価格情報がチャート３０２上に表示されてもよい。一方、清算機関Ｂ（１４０Ｂ）に関する価格情報がチャート３０４上に表示されてもよく、また、清算機関Ｃ（１４０Ｃ）に関する価格情報がチャート３０６上に表示されてもよい。他の例では、複数の清算機関に関する価格情報が単一のチャート（あるいは、２次元グラフまたは３次元グラフ）に組み入れられて並んで比較されてもよい。コンピュータシステム１２０のユーザは、コンピュータシステム１２０のビジュアルディスプレイ（例えば、ＬＣＤディスプレイ）上でＧＵＩ３００を見ることができ、また、それぞれの清算機関と比べると、価格の並列比較の利益を享受できる。また、幾つかの例において、ユーザへの表示のために生成される情報は、全ての清算機関にわたってまたはユーザの注文を直ぐに実施できる全ての清算機関にわたって最良の買呼値および最良の売呼値を含んでもよい（すなわち、第１の表示）。本明細書中で説明されるように、当業者であれば、本明細書中に開示される全体を検討すれば、ユーザのアカウント／設定に関するプレファレンスおよび／または制限ごとに、全ての清算機関（または、他の事業体）の価格をＧＵＩ３００上で表示できるか、かつ／または直ぐに使用できるとは限らないことが分かる。

［３５］
本開示の態様に係る１つの実施形態では、１つ以上のＲＦＱからの何らかの情報を使用してインプライド注文が生成され／処理されてもよい。米国仮特許出願第６１／４３８，９３３号明細書の付属書類Ｅの図１および図２を参照すると、本開示の様々な態様に従って使用されてもよいクオートプロセッサモジュールおよびインプライドスプレッド決定モジュールが示されている。例えば、ＲＦＱは、ＯＴＣ商品（例えば、スワップ契約）のクオートを要求することに加えて、ユーザ（例えば、コンピュータデバイス１２０を使用するトレーダー）がとりわけヘッジ目的でトレードするための先物契約または他の関連する商品に関するクオートのための表示／要求を含んでもよい。幾つかの実施形態では、特定の自動防護対策を可能にするために自動ヘッジ機能が含まれてもよい。

［３６］
前記実施例の様々な態様に係る１つの実施形態においては、ＲＦＱプロセッサモジュール１４２を使用して、金融商品に関するＲＦＱを受けるステップであって、ＲＦＱが１つ以上の清算機関（例えば、選択された清算機関）を示すための属性／項目を含むステップと、リクエスト・フォー・クオートプロセッサモジュールを使用して、リクエスト・フォー・クオートと関連する金融商品を複数の規制されたトレーディングプラットフォーム（例えば、ＳＥＦ）または清算機関のインプライドスプレッド決定モジュールへ送るステップと、インプライドスプレッド決定モジュールを使用して、１つ以上の指し値注文と組み合わせてリクエスト・フォー・クオートと関連する金融商品がインプライドスプレッドをもたらすことを決定するステップであって、インプライドスプレッドが複数のレッグを備え、複数のレッグのうちの第１のレッグがリクエスト・フォー・クオートと関連する金融商品に対応し、複数のレッグのうちの第２のレッグが１つ以上の指し値注文のうちの１つの指し値注文に対応するステップと、インプライドスプレッド決定モジュールを使用して、インプライドスプレッドの通知を、マッチングのためにトレーディングプラットフォームシステム（例えば、ＳＥＦ）の電子マッチエンジンへ送るステップであって、マッチングがインプライドスプレッドの複数のレッグの全てを実行することを含むステップとを含む方法が考えられる。米国仮特許出願第６１／４３８，９３３号明細書の付属書類Ｅ（例えば、付属書類の２８〜３２頁）に開示される１つ以上の特徴がＲＦＱを伴う前述した方法に含まれてもよい。

［３７］
また、前述した例において発生されるインプライド注文は、本明細書中に記載される清算マトリクスとＲＦＱで設定されるかまたはそれに通される所定のユーザプレファレンスとに基づき、同じ清算機関（例えば、清算機関Ａ、１０４Ａ）にわたってまたは複数の清算機関にわたって有効であってもよい。また、幾つかのインプライド注文が、フロントエンドシステム（例えば、ユーザコンピュータデバイス１２０）またはその近傍で発生されてもよく、また、清算機関、規制されたトレーディングプラットフォーム、および／または、ユーザが清算またはトレードできる取引所にわたってインプライドストラテジーを示してもよい。例えば、米国仮特許出願第６１／４３８，９３３号明細書の付属書類Ｄは、付属書類の図７および図８において、リスク制御およびクレジット制御を監視して調整する／管理するためにフロントエンドのトレーディングエンジンがバックエンドのマッチングシステムと情報をやりとりするシステムを記載する。そのようなシステムは、リスク制御およびクレジット制御に基づいて、特定の清算機関で清算できるユーザの能力を制限してもよい。結果として、そのようなユーザへ表示される価格マトリクスは、ブロックされた（例えば、望ましくない、または、ユーザ／システム設定により排除された／制限された）清算機関および該清算機関の対応する価格情報をリストアップしてもよくまたはリストアップしなくてもよい。代わりの実施形態において、清算マトリクス（例えば、図３のＧＵＩ３００）は、特定の清算機関の薄いグレー表示の（例えば、選択できない；直ぐに使用できない）価格を有してもよいが、依然としてユーザへ表示されてもよい。幾つかの例において、ＧＵＩ３００は、価格に影響を与えたいユーザが特定の清算機関でトレードできない（例えば、その清算機関と関係を有さない）場合には価格を直ぐに使用できないことを示してもよい。清算マトリクス（例えば、図３のＧＵＩ３００）は、第１のスタイル（例えば、図示しない、色、フォントタイプ、サイズ、イタリック体／ボールド体／アンダーラインなど）の第１の清算機関に関する情報（例えば、第１の清算機関から受けられる買呼値および売呼値）をフォーマットしてもよいが、第２のスタイルの第２の清算機関に関する情報をフォーマットしてもよい。

［３８］
また、電子トレーディングシステム内の潜在的なインプライドスプレッドの特定および処理は、時として、処理リソースを費やす。米国仮特許出願第６１／４３８，９３３号明細書の付属書類Ｆは、とりわけ、デリバティブ商品および他のタイプの金融商品をトレードする当事者間での通信帯域幅消費を最小限に抑えるためのシステムおよび方法について記載する。米国仮特許出願第６１／４３８，９３３号明細書の付属書類Ｆのシステムおよび方法は、本明細書中に開示されるシステムおよび方法と共に組み入れられまたは使用されてもよい。例えば、米国仮特許出願第６１／４３８，９３３号明細書の付属書類Ｆの例におけるマーケットメーカー１３０は、金融商品をそれが清算される清算機関に関して異なってクオートしてもよく、また、そのクオートデータが、ＳＥＦで受けられるとともに、米国仮特許出願第６１／４３８，９３３号明細書の付属書類Ｆに記載されるように１つ以上の金融商品における気配値のクオートの導出を容易にするために使用されてもよい。例えば、ハイブリッドＲＦＱの場合には、気配値のクオートデータを要求するために、エンハンストＲＦＱがシステム１００へ送られてもよい。気配値のクオートデータ２０２は、複数の価格クオート（例えば、ＣＣＰ属性で指定される清算機関に関して、あるいは、一般的には、全ての清算機関に関して）を含むメッセージとしてパッケージ化されてもよい。気配値の価格クオートは、拘束力がなく、直ぐに使用できない。システム１００は、複数の拘束力がなく直ぐに使用できない価格クオートを含むメッセージを１つ以上のサブスクライバー１３０へ送る（例えば、図４の参照符号４１６を参照）。また、当業者であれば、本明細書中に開示される全体（米国仮特許出願第６１／４３８，９３３号明細書の付属書類Ｆを含む）を検討すれば、米国仮特許出願第６１／４３８，９３３号明細書の付属書類Ｆに開示される他の例および特徴が本明細書中に記載される例と共に使用するためにこの開示によって考慮されるのが分かる。

［３９］
図２を参照すると、ＳＥＦシステム（例えば、コンピュータシステム１００）が指定された契約市場（非ＳＥＦシステム２１２などのＤＣＭ）および／または清算機関（例えば、１４０Ｂ、１４０Ｃ、１４０Ａなど）と通信してもよい。幾つかの例において、ＳＥＦシステムは、特定の清算機関１４０Ｃで清算するために非ＳＥＦシステム２１２を介して通信してもよい。他の事例では、清算機関１４０Ｂが全てのトレーディングプラットフォームに利用できてもよい。他の実施形態において、清算機関Ａ（１４０Ａ）は、特定のトレーディングプラットフォーム（例えば、ＳＥＦ１００）を介してのみ利用できてもよい。インプライド注文、ＲＦＱ、および、他の要求／提出は、非ＳＥＦシステム２１２およびＳＥＦシステム１００にわたって行なわれてもよい。幾つかの例では、単一のコンピュータシステム１００（例えば、マッチエンジンモジュール１０６）がＳＥＦサービスおよび非ＳＥＦサービスの両方を含んでもよい。

［４０］
本開示の様々な態様に係る自動ヘッジ機能に関して、幾つかのＯＴＣ商品（例えば、スワップ、ＩＲＳ、ＣＤＳ、通貨スワップなど）が先物市場または他の市場における１つの商品とヘッジされてもよい。多くの場合、先物商品がＯＴＣ商品よりも大きい流動性を有してもよい。このようにすると、ユーザ（例えば、コンピュータシステム１２０のユーザ）は、自分のＯＴＣ市場リスクを先物市場における購入によって未然に回避することを望むことができる。１つの例において、ヘッジは、異なるかまたは選定した清算機関でトレードするように定められてもよい。他の例において、ユーザは、ユーロドルのバスケットにおけるヘッジを伴うＩＲＳのためのトレードを提出してもよい。ユーザは、ＩＲＳトレードを自動的に回避すべきかどうかを決定するのに役立つＲＦＱ（または、他の注文タイプ、例えばカバードコール）を提出してもよい。ＲＦＱにおいて、ユーザは、非スワップ（例えば、金利先渡し契約）を指示してもよく、システム１００にインプライド注文を発生させてその注文をクオートさせてもよい。商品がＳＥＦ１００上でリストアップされない場合、ＳＥＦは、他のプラットフォームまたは清算機関またはＤＣＭ（例えば、非ＳＥＦシステム２１２）に目を向けてもよい。ＳＥＦシステムおよび非ＳＥＦシステムは、所望の情報を得るために情報をやりとりしてもよい。一部の場合には、ユーザは、リスクマネージメントのために異なる清算機関で好んでヘッジしてもよく、したがって、ユーザは、１つのスプレッドにおいて所望の組の契約を得るためにユーザ定義のスプレッドを規定してもよく、この場合、それぞれの契約は、同じかまたは異なる清算機関に存在し得る。例えば、トレーディングプラットフォームシステム１００は、スプレッド注文に応じるとともに、その注文を、６０件の契約が清算機関１４０Ａにより清算されるとともに他の４０件の契約が清算機関１４０Ｂにより清算されるように分割してもよい。

［４１］
この開示の様々な態様に係る他の実施形態において、規制されたトレーディングプラットフォーム（例えば、システム１００）は、多数の清算機関（例えば、１４０Ａ、１４０Ｂ、１４０Ｃなど）および他の事業体（例えば、非ＳＥＦシステム２１２、ＤＣＭなど）と情報をやりとりしてもよい。トレーディングプラットフォーム１００は、前述したようなリスクマネージメントモジュール１３４を含んでもよい。リスクマネージメントモジュール１３４は、金融商品または金融商品のポートフォリオと関連するリスクの大きさを計算して決定してもよい。また、幾つかの例では、モジュールによるリスクマネージメントが特定の清算機関リスク値に関してまたは清算機関（例えば、１４０Ａ〜１４０Ｃ）のユーザ定義の組にわたって行なわれてもよい。他の例において、リスクマネージメントは、ユーザ／トレーダー、清算会社、商品、証拠金などによって行なわれてもよい。更なる他の例において、リスクは、米国仮特許出願第６１／４３８，９３３号明細書の付属書類Ｃに記載されるように集約されてもよい。例えば、米国仮特許出願第６１／４３８，９３３号明細書の付属書類Ｃの図７、８、９は、モジュール１３４によって行なわれる計算に基づいてリスク（例えば、対応する委託保証金）を計算して調整できるシステムを示している。米国仮特許出願第６１／４３８，９３３号明細書の付属書類Ｃのこれらの図は多数の取引所と情報をやりとりするシステムを参照するが、同じタイプの情報のやりとりを、システム１００が多数の清算機関（例えば１４０）および／または他の事業体（例えば、非ＳＥＦシステム２１２）と情報をやりとりできるこの開示に適用できることは言うまでもない。

［４２］
例えば、米国仮特許出願第６１／４３８，９３３号明細書の付属書類Ｃの教示内容を適用して、システム１００は、リスク閾値およびリスクレベルに関してユーザおよび／または他の事業体に警告するメッセージを送ってもよい。例えば、ＳＥＦ（例えば、トレーディングシステム１００）は、複数の清算機関にアクセスして接触してもよい。このようにすると、ＳＥＦ１００は、清算機関のうちの１つ以上にわたって単一の信用限度の設定を許容し得る。ＳＥＦ１００は、１つの清算機関（１４０Ａ）で許容されるリスクの大きさに関する限度の設定を可能にしてもよいが、他の清算機関（１４０Ｂ）が更に大きなリスクを許容できるようにしてもよい。ＳＥＦ１００は、ユーザ／トレーダーが清算機関Ａ（１４０Ａ）で金融商品において買い持ちを保ちかつ清算機関Ｂ（１４０Ｂ）で同じ金融商品において売り持ちを保つことを認めてもよい。結果として、ＳＥＦ１００は、ユーザのポジションのリスクに独自にアクセスしてもよく、また、ユーザのトレーダーまたは要求の処理を承認しまたは拒絶してもよい。

［４３］
１つの例では、トレーディングプラットフォームで出された注文と関連するリスクを監視するためのシステムが開示される。該システムは、複数の清算機関に接続するインタフェースであって、これらの清算機関のうちの１つ以上が清算機関に関する最大集約リスクパラメータと関連する総クレジットパラメータを含む、インタフェースと、複数の清算機関と通信できる少なくとも１つのクレジット制御モジュールであって、注文／トレードを受けて、それぞれの個別の清算機関で出された注文の値を決定するために量定義を通信する少なくとも１つのクレジット制御モジュールとを備え、注文の値が所定の大きさの量定義を上回れば、クレジット制御モジュールは、注文ルーティング機構から他の清算機関へのクレジットの増大を要求する。代わりの実施形態において、クレジット制御モジュールは、ユーザ／システムプレファレンスに基づいて、清算されるべき注文を、利用可能なクレジットを伴う他の清算機関へと経路付けてもよい。

［４４］
米国仮特許出願第６１／４３８，９３３号明細書の付属書類Ｃで参照されるように、クレジット制御モジュールは、前述した特徴のうちの１つ以上を実施するのに役立ってもよい。米国仮特許出願第６１／４３８，９３３号明細書の付属書類Ｃに記載されるクレジット制御の一部は取引所またはトレーディングエンジンに関して記載される場合があるが、本明細書中の開示は、言うまでもなく、複数の清算機関、ユーザ／トレーダー、および、他の当事者（例えば、清算会社）に関するクレジット制御モジュールを更に考慮する。また、複数のトレーディングプラットフォーム（例えば、ＳＥＦ１００および非ＳＥＦシステム２１２）と通信する清算機関１４０Ｂは、異なるＳＥＦシステムおよび非ＳＥＦシステムにわたって非同期的なクレジット制御を（そのコンピュータシステムで実行するクレジット制御モジュールを介して）行なってもよい。

［４５］
図１は、本発明の様々な態様を実施するために使用されてもよい例示的な動作環境を描いている。動作環境は、適した動作環境の単なる１つの例にすぎず、本発明の使用または機能性の範囲に関する任意の限定を示唆しようとするものではない。本発明の態様は、契約履行保証額要件・トレード情報を含むがこれに限定されないトレード情報をやりとりし、送信し、通信し、与え、管理し、容易にするためのコンピュータデバイスおよびネットワークを用いて実施されるのが好ましい。取引所コンピュータシステム１００は、本発明の態様に従って、市場データを受け、履歴データを解析し、様々な値、例えば、定率法と関連する未払い額、履歴未払い額、日々の決済価格調整、現金支払い等を計算して広める。

［４６］
取引所コンピュータシステム１００には、１つ以上のメインフレーム、サーバ、ゲートウェイ、コントローラ、デスクトップ、または、他のコンピュータが実装されてもよい。取引所コンピュータシステム１００は、１つ以上のモジュール、プロセッサ、データベース、メインフレーム、デスクトップ、ノートブック、タブレットＰＣ、ハンドヘルド、携帯端末、スマートフォン、ゲートウェイ、および／または、例えば図１に示されるような他の構成要素を含んでもよい。また、コンピュータシステム１００は、１つ以上のプロセッサ２０８（例えば、インテル（登録商標）マイクロプロセッサ、ＡＭＤ（登録商標）マイクロプロセッサ、リスクプロセッサなど）、および、１つ以上のメモリ２０４（例えば、固体メモリ、ＤＲＡＭ、ＳＲＡＭ、ＲＯＭ、フラッシュメモリ、不揮発性メモリ、ハードドライブ、レジスタ、バッファなど）を含んでもよい。また、Ｇｌｏｂｅｘ（登録商標）取引システムなどの電子トレーディングシステム１３８が取引所コンピュータシステム１００と関連付けられてもよい。そのような実施形態において、電子トレーディングシステムは、地球的規模で配設されたコンピュータ、コントローラ、サーバ、ネットワーク、ゲートウェイ、ルータ、データベース、メモリ、および、他の電子データ処理・ルーティングデバイスの組み合わせを含む。トレーディングシステムは、入力メッセージをトレーディングシステムと関連する適切なデバイスへと経路付けるように構成されるデバイスを有するトレーディングシステムインタフェースを含んでもよい。トレーディングシステムインタフェースは、コンピュータ、コントローラ、ネットワーク、ゲートウェイ、ルータ、および、他の電子データ処理・ルーティングデバイスを含んでもよい。入力メッセージは、ユーザのコンピュータデバイス１２０から直接または間接（例えば、インターネットを介して、有線または無線ネットワークを介して、など）に受けられて、トレーディングプラットフォームシステム１００へ送られてもよい。トレーディングシステムを用いて出される注文またはトレーディングシステムへ提出される注文は、トレーディングシステムインタフェースで受けられる。トレーディングシステムインタフェースは、注文を適切なデバイスへと経路付ける。トレーディングエンジンコンピュータシステム１００は、注文を受けて、その注文およびトレードに関連付けられる市場データをユーザへ送信する。

［４７］
ユーザデータストア（例えば、ユーザデータベース１０２）は、トレーダーおよび取引所コンピュータシステム１００の他のユーザを特定する情報を含んでもよい。そのような情報は、ユーザ名およびパスワードを含んでもよい。取引所１００と情報をやりとりする電子デバイス（例えば、コンピュータデバイス１１４、１１６、１１８、１２０、１２２）を作動させるトレーダーは、ユーザデータベース１１２に記憶されるユーザ名およびパスワードと対照して認証されてもよい。また、アカウントデータモジュール１０４が、トレード中に使用されてもよいアカウント情報を処理してもよい。アカウント情報は、取引所１００と情報をやりとりする電子デバイスの特定のトレーダー（または、ユーザ）に固有のものであってもよい。

［４８］
マッチエンジンモジュール１０６が、本発明の態様に従って構成される注文における買呼値と売呼値とをマッチングさせてもよい。マッチエンジンモジュール１０６には、本発明の態様に従って金融商品における買呼値と売呼値とをマッチングさせるための１つ以上のアルゴリズムを実行するソフトウェアが実装されてもよい。マッチエンジンモジュール１０６およびトレーディングシステムインタフェースは、別個の異なるモジュールまたは構成要素であってもよく、あるいは、一体部品であってもよい。マッチエンジンモジュールは、トレーディングシステムに提出される注文をマッチングさせるように構成されてもよい。マッチエンジンモジュールは、現在知られるかまたは後に開発されるトレードマッチングプラクティスおよびプロセスに従って注文をマッチングしてもよい。一実施形態では、買呼値と注文とが価格に関してＦＩＦＯ方式でマッチングされてもよい。マッチングアルゴリズムは、比例配分方式で、あるいは、ＦＩＦＯ方式と比例配分方式との組み合わせで、注文をマッチングしてもよい。他のプロセスおよび／またはマッチングプロセスが使用されてもよい。

［４９］
また、トレーダーを特定する履歴情報およびトレーダーの銘柄を記憶するためにトレードデータベース１０８が含まれてもよい。特に、トレードデータベースは、注文が実行された時間および契約価格を特定するかまたはそれらと関連する情報を記憶してもよい。トレードデータベース１０８は、トレーダー（および／または他のユーザ）によって操作される電子デバイスにより提出される注文の少なくとも一部を記憶するように構成される記憶デバイスを備えてもよい。マッチエンジンモジュール１０６が注文に関してマッチングを見出して、その注文がその後に実行されると、確認メッセージが送られてもよい。確認メッセージは、幾つかの実施形態では、トレーダーへの電子メールメッセージ、様々なフォーマットのうちの１つを成す電子通知、または、注文実行の通知を発する任意の他の形式であってもよい。

［５０］
更に、現在の買呼値および売呼値を計算するかまたは他の方法で決定するためにオーダーブックモジュール１１０が含まれてもよい。オーダーブックモジュール１１０は、金融商品の価格を計算するように構成されてもよい。金融商品または金融商品のポートフォリオと関連するリスクの大きさを計算して決定するためにリスクマネージメントモジュール１３４がコンピュータシステム１００に含まれてもよい。金融商品（例えば、エンハンスト金融商品）の注文に関連するデータを受けるためにオーダープロセッサモジュール１３６が含まれてもよい。モジュール１３６は、オーダーブックモジュール１１０およびマッチエンジンモジュール１０６によって処理するためにデルタベースタイプと大口注文タイプとに分解してもよい。オーダープロセッサモジュール１３６は、金融商品の注文と関連するデータまたはトレード後のルーティングを扱うための更なる属性と関連するデータを処理するように構成されてもよい。幾つかの例において、オーダープロセッサモジュール１３６は、エンハンスト金融商品の清算機関属性を清算機関へ送る前に除去することによりエンハンスト金融商品を処理してもよい。とりわけ、エンハンスト金融商品の清算機関属性を清算機関へ送る前に除去する少なくとも１つの理由が下位互換性のためであってもよい。清算機関は、その機能を果たすためにこの属性を必ずしも認識する必要がないからである。

［５１］
オーダープロセッサモジュール１３６と同様に、リクエスト・フォー・クオート（ＲＦＱ）プロセッサモジュール１４２がトレーダー操作コンピュータデバイス１１４、１１６、１１８、１２０、１２２からリクエスト・フォー・クオート（ＲＦＱまたはｅＲＦＱと称される）を受けてもよい。ＲＦＱプロセッサモジュール１４２は、取引所、規制されたトレーディングプラットフォーム（例えば、ＳＥＦ）、および／または、清算機関１４０を含むがこれらに限定されない他のソースからＲＦＱを受けてもよい。ＲＦＱは、価格、証券識別子、ＣＣＰ属性、有効期限／行使価格（例えば、オプション契約、ＯＴＣ、または、先物の場合）、外部トレーディングプラットフォーム属性（例えば、使用するための他のＳＥＦシステムおよび非ＳＥＦシステム）、および／または、当業者に知られる他の項目などの金融商品に関連する項目に関する情報を含んでもよい。ＲＦＱプロセッサモジュール１４２は、ＲＦＱを受けるとともに、ＲＦＱへの応答を得るためにマーケットメーカー１３０および／またはトレーダーと通信してもよい。例えば、ＲＦＱプロセッサモジュール１４２は、クオートが特定の金融商品に関して要求されることを知らせるためにＲＦＱをサブスクライバー（例えば、マーケットメーカー１３０、トレーダーなど）へ送信してもよい。ある場合には、応答が得られなくてもよく、また、ＲＦＱが返答なしのままであってもよい。他の実施形態において、ＲＦＱプロセッサモジュール１４２は、要求している事業体／個人（例えば、トレーダー）に対して情報を与えることができてもよい。

［５２］
また、市場データを収集して、ユーザへの送信に備えてデータを準備するために市場データモジュール１１２が含まれてもよい。１つの実施形態において、市場データモジュール１１２は、現在の発生額、および／または、日々の決済価格調整額、および／または、現金払い額の値を公開してもよい。市場データモジュール１１２は、値（例えば、配当の発表）が報告される際に生じ得る金融商品の最新情報を含めて、金融商品の最新情報を定期的に広めてもよい。市場データは、匿名で報告されてもよく、幾つかの例では、清算会社固有であってもよく、および／または、ブローカー／トレーダー固有であってもよい。本発明の態様に係る幾つかの実施形態において、市場データモジュール１１２は、金融商品の市場データ記録を毎日（例えば、それぞれの取引日の最後に）更新してもよい。

［５３］
図１に示されるトレーディングネットワーク環境は、コンピュータ（すなわち、電子）デバイス１１４、１１６、１１８、１２０、１２２を含む。コンピュータデバイス１１４、１１６、１１８、１２０、１２２は、コンピュータの全体の動作を制御する１つ以上のプロセッサまたはコントローラを含んでもよい。コンピュータデバイス１１４、１１６、１１８、１２０、１２２は、プロセッサをネットワークカードまたはモデムなどの１つ以上の構成要素に接続する１つ以上のシステムバスを含んでもよい。コンピュータデバイス１１４、１１６、１１８、１２０、１２２は、データまたはファイルを読み書きするためのインタフェースユニットおよびドライブを含んでもよい。コンピュータデバイスのタイプに応じて、ユーザは、キーボード、ポインティングデバイス、マイクロフォン、ペンデバイス、または、他の入力デバイスを用いて、コンピュータと情報をやりとりできる。例えば、電子デバイスは、パーソナルコンピュータ、ラップトップコンピュータ、または、ハンドヘルドコンピュータ、タブレットＰＣ、および、ユーザインタフェースを有する同様のコンピュータデバイスであってもよい。電子デバイスは、パーソナル通信デバイス、携帯電話または卓上電話、携帯端末（「ＰＤＡ」）、遠隔制御デバイス、パーソナルデジタル媒体システム、および、同様の電子デバイスなどの専用の機能デバイスであってもよい。

［５４］
コンピュータデバイス１１４は、取引所コンピュータシステム１００に直接に接続されて示されている。取引所コンピュータシステム１００およびコンピュータデバイス１１４は、Ｔ１ライン、共通のローカルエリアネットワーク（ＬＡＮ）、または、コンピュータデバイスを接続するための他の機構を介して接続されてもよい。コンピュータデバイス１１４はラジオ１３２に接続されて示されている。ラジオ１３２のユーザは、トレーダーまたは取引所従業員であってもよい。ラジオユーザは、注文または他の情報をコンピュータデバイス１１４のユーザへ送信してもよい。その後、コンピュータデバイス１１４のユーザは、トレードまたは他の情報を取引所コンピュータシステム１００へ送信してもよい。

［５５］
コンピュータデバイス１１６、１１８がローカルエリアネットワーク（ＬＡＮ）１２４に結合される。ＬＡＮ１２４は、よく知られるＬＡＮトポロジーのうちの１つ以上を有してもよく、また、イーサネット（登録商標）などの様々な異なるプロトコルを使用してもよい。コンピュータ１１６、１１８は、互いに通信してもよく、また、ＬＡＮ１２４に接続される他のコンピュータおよびデバイスと通信してもよい。コンピュータおよび他のデバイスは、ツイストペア配線、同軸ケーブル、光ファイバ、または、他の媒体を介してＬＡＮ１２４に接続されてもよい。あるいは、無線携帯端末デバイス（ＰＤＡ）１２２が電磁波によってＬＡＮ１２４またはインターネット１２６と通信してもよい。ＰＤＡ１２２は、従来の無線ハブ１２８を介して取引所コンピュータシステム１００と通信してもよい。ここで使用されるＰＤＡとしては、電磁波によってネットワークと通信する携帯電話および他の無線デバイスが挙げられる。

［５６］
図１は、インターネット１２６に接続されるＬＡＮ１２４も示している。ＬＡＮ１２４は、ＬＡＮ１２４をインターネット１２６に接続するためのルータを含んでもよい。コンピュータデバイス１２０は、インターネット１２６に直接に接続されて示されている。この接続は、モデム、ＤＳＬライン、サテライトディッシュ、または、コンピュータデバイスをインターネットに接続するための任意の他のデバイスを介してなされてもよい。

［５７］
図１に示されるコンピュータデバイスおよびシステムの動作は、コンピュータ可読記憶媒体に記憶されるコンピュータ実行可能命令によって制御されてもよい。実施形態は、オブジェクトおよび／またはソースコードを含めて、電子ハードウェア、コンピュータソフトウェア、ファームウェア、および／または、これらの組み合わせの形態を成してもよい。実施形態は、１つ以上のデータプロセッサ（例えば、リスクプロセッサ）、コントローラ、コンピュータ、クライアント、サーバ、ゲートウェイ、コンピュータのネットワーク、および／または、これらの任意の組み合わせに組み込まれ、これらによって配備され、これらに存在し、これらによって呼び出され、および／または、これらによって使用されるコンピュータ可読媒体に記憶されてもよい。コンピュータ、サーバ、ゲートウェイは、コンピュータソフトウェアとして具現化される命令を実行するように構成される１つ以上のコントローラを有してもよい。例えば、コンピュータデバイス１２０は、更新された決済価格、未払い額、および、他の情報をコンピュータシステム１００から受けてユーザへ表示するためのコンピュータ実行可能命令を含んでもよい。他の例において、コンピュータデバイス１１８は、市場データをコンピュータシステム１００から受けてその情報をユーザへ表示するためのコンピュータ実行可能命令を含んでもよい。更なる他の例において、コンピュータシステム１００のプロセッサは、本明細書中に開示される方法をシステム１００に行なわせるコンピュータ実行可能命令を実行するように構成されてもよい。

［５８］
１つ以上のマーケットメーカー１３０は、デリバティブまたは担保における買呼値および売呼値を取引所コンピュータシステム１００へ与えることによって市場を維持してもよい。取引所コンピュータシステム１００は、トレードエンジン１３８などの他のトレードエンジンと情報を清算してもよい。当業者であれば分かるように、多くの更なるコンピュータおよびシステムが取引所コンピュータシステム１００に結合されてもよい。そのようなコンピュータおよびシステムは、清算システム、規制システム、および、料金システム、例えば清算機関１４０を含んでもよい。結合は、前述したように直接であってもよく、あるいは、本明細書中に記載される任意の他の方法であってもよい。

［５９］
清算機関１４０は、店頭（ＯＴＣ）商品よりも危険なカウンターパーティークレジットリスクの相互にリスクを伴う契約を取引所コンピュータシステム１００が与えることができるようにする。清算機関１４０は、決済されて清算されるべき取引を手配する。清算は、清算機関１４０が契約（例えば、先物契約、普通株、通貨、金利商品など）のそれぞれの売り手に対して買い手になりかつそれぞれの買い手に対して売り手になるとともに、清算機関１４０がそれぞれの契約の遂行を保証することにより買い手および売り手を金銭的損失から保護する責任を負う手続きである。清算機関１４０は、売買勘定を決済し、トレードを清算し、契約履行保証資金を収集して維持し、受渡しを調整し、トレーディングデータを報告してもよい。幾つかのシナリオにおいて、取引所は、取引所の分割によってそれ自体の清算機関１４０を稼働させてもよく、それにより、行なわれる全ての取引は、オフセットまたは受渡しまで、毎日、確認され、マッチングされ、かつ、決済される。言い換えると、取引所コンピュータシステム１００が清算機関１４０の内部にあってもよい。あるいは、１つ以上の他の会社には、取引所（および、場合により、他の取引所）と共に清算機関１４０としての役目を果たす責務が与えられてもよい。取引所は、取引所と関連する１つ以上の清算機関を有してもよい。取引所は、取引所コンピュータシステム１００のための清算機関１４０を与えるためにトレードを清算する資格がある会社を提供してもよい。ある場合には、これらの清算機関の構成員が、彼らが清算できる商品のタイプおよび他のファクタに基づいて、異なるカテゴリーへと指定されてもよい。

［６０］
清算機関１４０は、それが扱う商品に関して最小限の契約履行保証（すなわち、証拠金）要件を定めてもよい。顧客は、オープンポジションによる損失に対して清算機関１４０を保証する目的で契約履行保証を清算機関１４０に寄託する（または、指定された掛け金）ように求められてもよい。契約履行保証は、ブローカー、清算機関、および、取引所の金銭上の完全性を全体として確保するのを助ける。トレーダーが最小限の要件を下回る資金の下落を経験する場合、清算機関１４０は、トレーダーの持ち分を回復させるために証拠金の追加を求める追証の請求（マージンコール）を出してもよい。清算機関１４０は、清算機関の裁量で、更なる契約履行保証要件を課してもよい。例えば、清算機関の潜在的なマーケットエクスポージャーがそれらのエクスポージャーをサポートするために利用できる金融資産に対して大きく増える場合には、清算機関１４０が追証の請求をしてもよい。

［６１］
他の実施形態において、清算機関１４０は、顧客／トレーダーの信用調査（例えば、とりわけ、ＦＩＣＯ（登録商標）または可比スコアを使用するなどの信用度の分析）に基づいて更に大きな契約履行保証を要求してもよい。信用調査は、清算機関１４０または取引所１００によって行なわれ（すなわち、着手され）てもよい。清算機関１４０が信用調査を行なう例では、清算機関１４０がメッセージ（例えば、執行メッセージ）を取引所へ送ってもよい。顧客／トレーダーがハイリスクであることを信用調査が示す場合には、執行メッセージは、顧客／トレーダーの委託保証金を増大させてもよく、またはそうでなければ、更に高いリスクと釣り合う顧客／トレーダーの能力／制約を調整してもよい。取引所１００が信用調査に着手する例では、顧客／トレーダーと関連するリスク増加／減少に関して清算機関を更新するために、取引所１００が取引所１００と関連する１つ以上の清算機関へメッセージを送ってもよい。

［６２］
効率的な清算手続きを促進させるとともに清算機関の真の市場間リスクエクスポージャーに焦点を合わせたいという要望に鑑みて、クロスマージニングシステムが使用されてもよい。特定の広範囲にわたる株価指数先物取引および株価指数オプションにおける合同提携清算機関のポジションを単一のポートフォリオへと組み合わせることにより、全ての市場にわたる単一の契約履行保証要件が決定されてもよい。クロスマージニングシステムは、清算システムの効率および金銭上の完全性を大きく高めてもよい。

［６３］
清算機関１４０が債務不履行の可能性を軽減する主な手段は、値洗い（ＭＴＭ）調整によるものである。清算機関１４０は、主に、債務契約が起こる際に債務契約を市場参加者間で除去することにより、その金融安定性を得る。毎日のＭＴＭ調整により、全ての契約が、そのトレーディングセッションの利益または損失に基づいて、借方に記入されまたは貸方に記入される。例えば、価格が１つのポジションの方へ動くかもしくは１つのポジションと逆の方へ動くと、資金が売買勘定へと流れ込みまたは売買勘定から流れ出す。このキャッシュフローは決済変動として知られる。

［６４］
無論、多くの更なるサーバ、コンピュータ、ハンドヘルドデバイス、携帯端末、電話、および、他のデバイスが取引所コンピュータシステム１００に接続されてもよい。また、当業者であれば分かるように、図１に示されるトポロジーは単なる一例であり、図１に示される構成要素が多くの別のトポロジーによって接続されてもよい。

［６５］
「金融商品」としては、スワップ契約、レジット・デフォルト・スワップ（ＣＤＳ）、金利スワップ（ＩＲＳ）、金利先渡し契約（ＦＲＡ）、ＯＴＣ普通株、ＯＴＣ外貨、デリバティブ契約、普通株、通貨のスワップ（ＦＸ）、二者間金融契約、中央清算パーティー／中央カウンターパーティー（ＣＣＰ）を伴う金融契約、および、本明細書中に開示される全体を検討して当業者に明らかな他の匹敵する金融商品を挙げることができるが、これらに限定されない。

［６６］
無論、前述の実施形態の方法およびシステムは、他の更なる要素、ステップ、コンピュータ実行可能命令、または、コンピュータ可読データ構造を含んでもよい。この関連では、他の実施形態も同様に本明細書中に開示されて特許請求の範囲に記載される。他の実施形態において、システムおよび方法は、例えば、コンピュータ実行可能命令またはモジュールを記憶することにより、あるいは、コンピュータ可読データ構造を利用することにより、コンピュータ可読媒体上で部分的または全体的に実施されてもよい。これらの命令は、本明細書中に開示される方法の１つ以上のステップを実行するためにコンピュータデバイスのプロセッサによって実行されてもよい。これらの実施形態および他の実施形態の詳細は、添付図面および本明細書に記載される。開示される方法、システム、および、装置の他の特徴および利点は、明細書本文、図面、および、付属書類から明らかになる。

［６７］
当業者であれば明らかなように、この発明を理解する者は、添付の特許請求の範囲に記載される開示のより広範な思想および範囲から逸脱することなく、本明細書中に開示される原理を利用する変更または他の実施形態または変形を考え出すことができる。例えば、多くの実施例がスワップ契約を挙げるが、当業者であれば分かるように、本明細書中に開示される新規の原理は、他のタイプの金融商品に適用されてもよく、依然として本明細書中で考慮される本発明の範囲内に入る。

Claims (18)

1. コンピュータ化された装置であって、
   コンピュータ実行可能な命令を実行するように構成されたコンピュータプロセッサと、
   コンピュータ実行可能命令を格納したコンピュータメモリであって、前記コンピュータ実行可能命令が前記コンピュータプロセッサによって実行されたとき、前記装置に、
   ユーザの設定を取得するためにデータベースにアクセスし、前記ユーザの設定は、
   価格を実行できないが見ることができる複数の清算機関の１つ以上の第１の表示であって、前記第１の表示は少なくとも第１の清算機関を特定する第１の表示と、
   価格を実行できる複数の清算機関の１つ以上の第２の表示であって、前記第２の表示は少なくとも第２の清算機関を特定する第２の表示と、
   前記ユーザから制限された複数の清算機関の１つ以上の第３の表示であって、前記第３の表示は少なくとも第３の清算機関を特定する第３の表示と
   を含み、
   金融識別子の更新された市場データを自動的に受信する取引所コンピュータシステムに登録し、前記市場データは前記第２の表示に特定された１つ以上の清算機関に関連付けられ、
   取引所から、価格属性及び金融識別子の属性を少なくとも含む市場データを受信し、
   前記コンピュータプロセッサによって、前記ユーザに表示するためにフォーマットされた情報を生成し、前記情報は前記受信された市場データの少なくとも一部を含み、前記フォーマットは前記ユーザの設定に基づき、
   前記コンピュータプロセッサによって前記ユーザに、前記フォーマットされた表示のための情報を送信する
   ようにさせることを含むコンピュータメモリと
   を含む装置。
2. 前記受信した市場データの価格属性は前記金融識別子の買呼値及び売呼値を少なくとも格納し、前記買呼値及び売呼値は前記清算機関のそれぞれに固有であり、前記第２の清算機関についての買呼値及び売呼値は複数のレベルの深さ及びマーケット・バイ・オーダーの１つである請求項１に記載の装置。
3. 前記情報を生成することは、
   少なくとも前記第１の清算機関から受信した買呼値及び売呼値をフォーマットし、前記第１の清算機関は第１のスタイルの前記第１の表示で識別され、
   少なくとも前記第２の清算機関から受信した買呼値及び売呼値をフォーマットし、前記第２の清算機関は第２のスタイルの前記第２の表示で識別された
   ことをさらに含む請求項１に記載の装置。
4. 前記第１及び第２のスタイルは、選択できるものとして、グレーアウトした部分と、レンダリングした部分とを含む請求項３に記載の装置。
5. 前記コンピュータメモリはコンピュータ実行可能命令をさらに格納し、前記コンピュータ実行可能命令は前記コンピュータプロセッサによって実行されたときに、前記装置に、
   前記コンピュータプロセッサによって、前記第２の表示に対応する清算機関のすべてにわたる最良の買呼値及び売呼値を含む追加情報を生成する
   ようにさせる請求項１に記載の装置。
6. 前記受信した市場データは、清算機関を特定するように構成された属性を含み、第１の市場データ及び第２の市場データはほぼ同一であるが、前記清算機関の属性に基づき前記価格属性について異なる値を含む請求項１に記載の装置。
7. 前記送信した情報はスクロールするテキストベースのメッセージングインターフェースの一部としての表示に適合するようにフォーマットされた請求項１に記載の装置。
8. 前記送信した情報は、価格への清算機関のマトリクスとして表示に適合するようにフォーマットされた請求項１に記載の装置。
9. コンピュータプロセッサによって、ユーザの設定を取得するためにデータベースにアクセスし、前記ユーザの設定の取得は、
   価格を実行できないが見ることができる複数の清算機関の１つ以上の第１の表示であって、前記第１の表示は少なくとも第１の清算機関を特定する第１の表示と、
   価格を実行できる複数の清算機関の１つ以上の第２の表示であって、前記第２の表示は少なくとも第２の清算機関を特定する第２の表示と、
   前記ユーザから制限された複数の清算機関の１つ以上の第３の表示であって、前記第３の表示は少なくとも第３の清算機関を特定する第３の表示と
   を含み、
   取引所コンピュータシステムから、価格属性、金融識別子の属性、及び清算機関を特定するように構成された属性の少なくとも１つを含む市場データを受信し、前記市場データは前記第２の表示に特定された１つ以上の清算機関に関連付けられ、
   前記コンピュータプロセッサによって、前記ユーザに表示するためにフォーマットされた情報を生成し、前記情報は前記受信された市場データの少なくとも一部を含み、前記フォーマットは前記ユーザの設定に基づき、
   前記コンピュータプロセッサによって前記ユーザに、前記フォーマットされた表示のための情報を送信する
   ようにさせることを含む方法。
10. 前記受信した市場データの価格属性は前記金融識別子の買呼値及び売呼値を少なくとも格納し、前記買呼値及び売呼値は前記清算機関のそれぞれに固有であり、前記第２の清算機関についての買呼値及び売呼値は複数のレベルの深さ及びマーケット・バイ・オーダーの１つであり、第１の市場データ及び第２の市場データはほぼ同一であるが、前記清算機関の属性に基づき前記価格属性について異なる値を含む請求項９に記載の方法。
11. 前記情報を生成することは、
    少なくとも前記第１の清算機関から受信した買呼値及び売呼値をフォーマットし、前記第１の清算機関は第１のスタイルの前記第１の表示で識別され、
    少なくとも前記第２の清算機関から受信した買呼値及び売呼値をフォーマットし、前記第２の清算機関は第２のスタイルの前記第２の表示で識別された
    ことをさらに含む請求項９に記載の方法。
12. 前記第１及び第２のスタイルは、選択できるものとして、グレーアウトした部分と、レンダリングした部分とを含む請求項１１に記載の方法。
13. 前記送信した情報はスクロールするテキストベースのメッセージングインターフェースの一部としての表示に適合するようにフォーマットされた請求項１１に記載の方法。
14. 前記送信した情報は、価格への清算機関のマトリクスとして表示に適合するようにフォーマットされる請求項９に記載の方法。
15. コンピュータ実行可能命令を格納する非一時的コンピュータメモリであって、コンピュータプロセッサによって実行されたときに、コンピュータに、
    ユーザの設定を取得するためにデータベースにアクセスし、前記ユーザの設定は、
    価格を実行できないが見ることができる複数の清算機関の１つ以上の第１の表示であって、前記第１の表示は少なくとも第１の清算機関を特定する第１の表示と、
    価格を実行できる複数の清算機関の１つ以上の第２の表示であって、前記第２の表示は少なくとも第２の清算機関を特定する第２の表示と、
    前記ユーザから制限された複数の清算機関の１つ以上の第３の表示であって、前記第３の表示は少なくとも第３の清算機関を特定する第３の表示と
    を含み、
    取引所コンピュータシステムから、価格属性、金融識別子の属性、及び清算機関を特定するように構成された属性の少なくとも１つを含む市場データを受信し、前記市場データは前記第２の表示に特定された１つ以上の清算機関に関連付けられ、
    前記ユーザに表示するためにフォーマットされた情報を生成し、前記情報は前記受信された市場データの少なくとも一部を含み、前記フォーマットは前記ユーザの設定に基づき、
    前記ユーザへの表示のためにフォーマットされた情報を送信するようにさせる
    非一時的コンピュータメモリ。
16. 第１の市場データ及び第２の市場データはほぼ同一であるが、前記清算機関の属性に基づき前記価格属性について異なる値を含む請求項１５に記載の非一時的コンピュータメモリ。
17. 前記送信した情報はスクロールするテキストベースのメッセージングインターフェースの一部としての表示に適合するようにフォーマットされた請求項１５に記載の非一時的コンピュータメモリ。
18. 前記送信した情報は、価格への清算機関のマトリクスとして表示に適合するようにフォーマットされる請求項１５に記載の非一時的コンピュータメモリ。

Images