JP2006505869A - 資産取引のための方法および装置 - Google Patents

Abstract

外国為替および金融市場取引証券、商品および有価証券などの金融資産を取引するための方法および装置（図２）。本発明は、インターネットなどの相互接続されたデータ通信ネットワークを介して、専用のユーザインタフェースだけでなく、標準のＷｅｂブラウザを使用してアクセスされてもよく、カスタマーの要求を受け取り（２０５）、カスタマーのプリファランスの組に従って、それらの要求を自動的に結合して、注文のバッチ内に編成し（２１０）、注文のバッチを、気配値または実際の価格クォートとともにカスタマーに表示し（２１５）、それにより、カスタマーは、複数の注文および複数の要求を同時に選択（２２０）および処理できるようになる。注文の価格設定およびブックは自動的に行われる。

Description

関連出願
本出願は、２００２年１１月８日に出願された米国仮出願第６０／４２４，６８２号に関連しており、米国特許法１１９条に基づいてその優先権を主張している。米国仮出願第６０／４２４，６８２号は、その全体が、この参照により本出願に含まれる。

技術分野
本発明は、一般に、金融取引システムに関し、より具体的には、取引の少なくとも一部が、インターネットなどの相互接続されたデータ通信ネットワークを介して行われる、金融取引システムに関する。

関連技術
今日の世界市場では、金銭は、投資家と借手との間で、そして売手と買手との間で、国境を越えて自由に流れている。例えば、外国為替（「ＦＸ」）市場は、市場参加者が、１つの通貨を別の通貨と交換する（または「取引する」）ことを可能にする。ＦＸ取引では、一方の相手方（ｃｏｕｎｔｅｒｐａｒｔｙ）が、指定された通貨を、もう一方の相手方から、別の通貨と引き替えに買う。ＦＸ市場証券（ＦＸ ｍａｒｋｅｔ ｉｎｓｔｒｕｍｅｎｔｓ）には、例えば、スポット（ｓｐｏｔ）、フォワード（ｆｏｒｗａｒｄ）、およびスワップ協定（ｓｗａｐ ａｇｒｅｅｍｅｎｔ）（以下で定義する）が含まれる。

別の例では、金融市場は、市場参加者が金銭を借りること、および貸すことを可能にする。金融市場取引では、一方の相手方（借手）が、もう一方の相手方（貸手）から、指定されたレートで、指定された期間、金銭を借りる。金融市場証券（ｍｏｎｅｙ ｍａｒｋｅｔ ｉｎｓｔｒｕｍｅｎｔ）には、譲渡可能定期預金証書（ｃｅｒｔｉｆｉｃａｔｅ ｏｆ ｄｅｐｏｓｉｔ）（ＣＤ）および現先取引（ｒｅｐｕｒｃｈａｓｅ ａｇｒｅｅｍｅｎｔｓ）などの利付き証券（ｃｏｕｐｏｎ ｂｅａｒｉｎｇ ｉｎｓｔｒｕｍｅｎｔ）、財務省短期証券（Ｔ−ｂｉｌｌ）およびコマーシャルペーパー（ｃｏｍｍｅｒｃｉａｌ ｐａｐｅｒ）などの割引証券（ｄｉｓｃｏｕｎｔ ｉｎｓｔｒｕｍｅｎｔ）、ならびに金利先渡し契約（ｆｏｒｗａｒｄ ｒａｔｅ ａｇｒｅｅｍｅｎｔ）、金利先物、および金利オプションなどのデリバティブ（ｄｅｒｉｖａｔｉｖｅ）が含まれる。

投資の際に、ほとんどのＦＸ証券および金融市場は「流動性がある（ｌｉｑｕｉｄ）」、つまり売買することが可能であり、したがって、迅速に現金に変換することができる。この流動性が、多くの企業の財務担当者が、財政上の決定を行う前に、短期、低リスクの投資手段に余分な現金を一時的に「駐車（ｐａｒｋｉｎｇ）」するための方法として、これらの市場を利用して余分な現金を銀行に貸す、または売る理由である。銀行は、余分な現金を使って、短期の融資を必要としている借手に貸し付けを行う。これらの借手には、例えば、他の銀行、企業、政府、および世界銀行などの超国家的組織が含まれる場合がある。

これらの市場の借手、貸手、売手、および買手は、それらの取引を、金融市場証券の貸し借り、またはＦＸ証券の売買を行うディーラー（「トレーダー（ｔｒａｄｅｒ）」とも呼ばれる）を介して行う。ディーラーおよびトレーダーは、「マーケットメーカー（ｍａｒｋｅｔ−ｍａｋｅｒ）」または「流動性プロバイダー（ｌｉｑｕｉｄｉｔｙ−ｐｒｏｖｉｄｅｒ）」と呼ばれ、取り扱う証券を買う（または借りる）意志のある価格、および前記証券を売る（または借りる）意志のある価格をクォート（ｑｕｏｔｅ）する。借りる、または買う価格は「ビッド（ｂｉｄ）」として知られ、貸す、または売る価格は「オファー」として知られている。これらの２つの価格の間の差は「ビッド−オファースプレッド（ｂｉｄ−ｏｆｆｅｒ ｓｐｒｅａｄ）」として知られており、このスプレッドが、マーケットメーカーのための利益を生成する。これは、マーケットメーカーが、常に、買いおよび借りを、売りおよび貸しよりもわずかに安く行うためである。

長年にわたり、流動性プロバイダーおよびそれらのカスタマー（流動性プロバイダーと取引を行う買手、売手、貸手、および借手）は、取引（ｔｒａｎｓａｃｔｉｏｎ）（「取引（ｄｅａｌ）」とも呼ばれる）の交渉、執行、確認、および決算を、開始から終了まで、直接会うこと（証券取引所または商品取引所におけるように）、または電話およびファックス装置を使用することによる、手動システムのみを使用して行っている。しかし、市場が拡大するにつれて、そして、取引活動が１日２４時間に及ぶようになるにつれて、手動システムは、あまりにも低速で非効率なため、市場の要求に対応することができないことがわかってきた。手動システムは、例えば、今日の市場の速いペースと大容量に対応するため、または今日の市場取引に従事することに伴う財政的リスクに対処するために必要とされる、人、価格、および取引記録への適切なアクセスを、常に提供するとは限らない。手動システムは、また、市場参加者が取引を行っている間に自由自在に利用できることを必要とする、最新の市場ニュース、市場レート、市場調査、およびその他の情報への、適切な、または適時のアクセスを、通常は提供しない。

カスタマーおよび流動性プロバイダーのための、自動オンライン取引システムが、これらの問題のいくつかに対処する試みとして導入された。しかし、既存の自動システムは、これまでのところ、古い手動システムの最も時間のかかる側面の多くを解決することに失敗している。例えば、既存のオンライン取引システムは、資産管理者などのカスタマーが、電子記録簿上で、多数の未決着の財務要求についての、銀行などの相手方により提供されたクォート（ｑｕｏｔｅ）を表示することを可能にする。各財務要求は、例えば、１つの通貨を別の通貨に、将来の指定された日に交換する提案（例えば、１００万ユーロを、同等量の米ドルで、２００４年１月２日を決算日として買う提案）を含む場合がある。状況によっては、カスタマーは、自分の記録簿上で、例えば、２００の異なる提案された取引について、２００もの異なるクォートを処理しなければならない場合がある。これらの取引のいくつかは、かなりの財務価値を有する場合があり（例えば、５０００万米ドルをユーロに対して取引する提案に応えたクォート）、したがって、カスタマーにとっての、かなりの財務出資金またはリスクを表す場合がある。カスタマーは、通常、かなりの価値を有するこれらの要求およびクォートのそれぞれを、非常に注意深く検討し、それぞれを個別に処理することを希望する。

しかし、多くの状況では、カスタマーの電子記録簿は、比較的小さな取引についての多数のクォートを含む場合もある。それらの取引は、例えばカスタマーにとって小さな財務上のリスクしか表さないため、比較的重要ではないと見なされる場合がある（例えば、わずか＄１０，０００に匹敵する日本円を買う提案）。それらの小さな取引は、しばしば「ハウスキーピング（ｈｏｕｓｅｋｅｅｐｉｎｇ）」取引と呼ばれ、例えば、支払期日が来る配当金支払、以前に適用され現在調整が必要なヘッジ、為替レートの変更による資産価値の変動、などにより発生する。したがって、カスタマーは、多数の提案された取引（それぞれの取引は比較的小さな価値である）について受け取られた、多数のクォートに対応する必要に直面する場合がある。このサイズの取引は、通常、より高い価値の取引に必要とされる、慎重な個別の検討および処理に値しない。しかし、カスタマーは、やはり、それぞれのクォートに、その価値に関係なく対応する必要がある。ことによると何百もの処理される必要のあるハウスキーピング取引に直面したカスタマーは、通常、それらを迅速に処理することを希望する（それにより、その後、より高い価値の取引の検討と処理のために、時間と資源を振り向けることができるようにするため）。

しかし、場合によっては、カスタマーは、高い価値の取引を処理または完了するために、多くの時間と資源を振り向ける必要はないこともある。そのような場合は、例えば、取引されるべき特定の資金が単一の銀行のみと取引できる場合や、銀行が戻す価格の質についての一般協定をカスタマーと相手方が有する場合（例えば、市場基準から差し引く固定スプレッドを使用（ａ ｆｉｘｅｄ ｓｐｒｅａｄ ｏｆｆ ａ ｍａｒｋｅｔ ｒｅｆｅｒｅｎｃｅ））、などに発生する。このような場合、カスタマーは、競争で取引することができないか、または競争で取引する必要がなく、したがって、迅速かつ効率的に取引を完了して片付けることを希望する（それにより、詳細な検討に値する取引の検討に進むことができるようにするため）。

しかし、従来の自動オンライン取引システムに伴う１つの欠点は、カスタマーがそれぞれの取引を個別に処理する必要があるということである（例えば、クォートを受諾または拒否することにより）。記録簿上に多数の比較的重要ではない取引がある場合、このプロセスは、非常に時間を浪費するものとなる。さらに、カスタマーは、通常、個別に処理される各取引について、委託手数料を個別に支払う必要があるため、各取引に対応するということは、カスタマーにとってのそれらの取引の価値に比較して、非常に高価なものになる可能性がある。

既存の自動オンライン取引システムに伴うもう１つの欠点は、各取引は、相手方（通常は銀行）の販売員またはその他の代理人によって、個別に価格設定または確認されなければならず、そのため、小さな取引の大規模な集まりを完全に処理するために必要とされる時間は非常に多くなるということである。

したがって、カスタマーが多数の（つまり、「バッチ」の）取引を、最小数の指示、キーストローク、またはマウスクリックで、迅速かつ効率的に、一括して処理することを可能にする、自動オンライン取引システムが必要とされている。さらに、複数の取引の「ネッティングされた値（ｎｅｔｔｅｄ ｖａｌｕｅｓ）」を自動的に配置して計算するシステムも必要とされている。取引の「ネッティング（ｎｅｔｔｉｎｇ）」とは、さまざまな取引から発生する複数の支払を、単一の同等の支払にまとめて、それにより、関与者間の支払の数を減らし、そしてほとんどの場合、複数の取引を完了することに伴う全体的な取引コストを減少させることを意味する。それらのシステムは、カスタマー、相手方銀行、またはそれらの両方に関連付けられた、プリファランスの組に従ってバッチを一括処理できるならば、そしてさらに、カスタマーの信用プロファイル、ならびに政府または業界の規制および制限を考慮に入れるならば、さらに有用なものとなる。それらのシステムは、相手方銀行またはプロバイダーにおける人間の介入の必要がほとんどまたはまったくなしに、取引のバッチを自動的にクォート、確認、および決算するための、構成要素および／またはプロセッサを含んでいるならば、さらに有用なものとなる。

本発明は、複数の取引をバッチ方式で自動的に処理する（例えば、提出、クォート、受諾、ブック、確認、および決算する）ためのシステムおよび方法を提供することにより、既存の自動オンライン取引システムに伴う上述の、およびその他の欠点に対処する。さらに、本発明を使用すれば、カスタマー、相手方、政府または業界の規制と制限、あるいはそれらのすべてに関連付けられた、デフォルトの、または指定されたプリファランスの組に従って、前記バッチが処理されることが可能になる。

一般に、本発明は、資産を取引するための方法を含み、前記方法は、（１）カスタマーとの通信チャネルを確立するステップと、（２）通信チャネルを介してカスタマーからの要求の組を受け取るステップと、（３）注文のバッチを形成するように要求の組を配置する（arranging）ステップと（バッチ内の各注文は、要求の組のサブセットを含む）、（４）バッチ内の少なくとも１つの注文についてのクォートを自動的に提供するステップと（クォートは、取引のグループを執行するための価格を含み、グループ内の各取引は、注文内の要求に対応する）、（５）通信チャネルを介してカスタマーにクォートを提示するステップと、（６）通信チャネルを介してカスタマーからクォートの受諾（ａｃｃｅｐｔａｎｃｅ）を受け取るステップと、（７）受諾に応えて、取引のグループをブックするステップとを含む。

要求の組が、特定の通貨ペア、銀行預金口座、または決済日を共通に有する少なくとも２つの要求を含む場合、前記配置するステップは、さらに、それらの要求を、注文のバッチ内の同じ注文に割り当てるステップを含んでいてもよい。好ましくは、前記２つの要求についてのネッティングされた値が、次に、計算されて、受諾または拒否のためにカスタマーに表示される。これらの要求は、同じ取引通貨（以下で定義する）を有していても、いなくてもよい。要求についてのネッティングされた値を計算する機構は、以下の詳細な説明の項で、本発明の一実施形態の例示的バッチ管理サーバ構成要素の詳細な説明と組み合わせて説明している。

要求のサブセットは、例えば、１つの通貨を別の通貨と交換するための提案、金銭を貸すかまたは借りるための提案、商品を買うかまたは売るための提案、あるいは有価証券を買うかまたは売るための提案を含んでいてもよい。自動的にクォートされた注文内のすべての要求を満足する必要に応じて、取引のグループは、任意数の取引（１つのみの取引を含む）を含んでいてもよい。本発明の一部の実施形態では、前記方法は、さらに、取引のグループ内の１つまたは複数の取引を執行するための、１つまたは複数の気配値（ｉｎｄｉｃａｔｉｖｅ ｐｒｉｃｅ）を生成および表示するステップを含む。気配値を生成するために、気配値エンジンが使用されてもよい。

上述のように、本発明は、外国為替と金融市場資産、商品と有価証券の取引を含む（ただし、これらに限定されない）、さまざまな異なる資産取引状況に適用されてもよい。外国為替資産を取引する状況では、「要求」は、個々の外国為替提案（例えば、「１００万ユーロを、米ドルで、２００４年１月２日を決算日として、銀行預金口座番号１２３４５で買いたい」）である。「注文」は、相手方（通常は銀行）に送られて、ユニットとして一括して価格設定または執行される、１つまたは複数の要求の組を含む。言い換えると、銀行が注文についてのクォートを提供する場合、銀行は本質的に、カスタマーが注文内のすべての要求について取引に合意する限り、表示価格で要求を提供することを提案している。したがって、注文についてのクォートを受け取った後、カスタマーは、注文の中のいくつかの要求についてのみ取引することを選択することはできない。カスタマーは、注文の中のすべての要求について取引して、クォートされた価格を得るか、または何も取引しないことが可能である。「バッチ」は、最小限の指示、キーストローク、またはマウスクリックを使用して、一括して価格設定されること、および／または実質的に同時に執行されることが可能な、１つまたは複数の注文の組である。カスタマーは、注文のバッチについての価格クォート（ｐｒｉｃｅ ｑｕｏｔｅｓ）を受け取った後は、それらの注文のうちの１つの注文、２つ以上の注文、またはすべての注文についての取引を行うこと、またはいずれの注文についての取引も行わないことを選択できる。

好ましい実施形態では、本発明はさらに、クォートを提供するための要求（「リクエスト・フォー・クォート」または「ＲＦＱ」としても知られている）を、カスタマーから、通信チャネルを介して受け取るステップを含む。前記方法は、さらに、取引のグループを執行するステップと、取引のグループが執行されたことを示す通知を、通信チャネルを介して、カスタマーに送るステップとを含んでいてもよい。取引のグループに関連付けられた、取引詳細（ｔｒａｄｅ ｄｅｔａｉｌｓ）が、次に、そのような情報を保持するように構成された取引データベース内に記憶されてもよい。前記方法は、取引のグループ内の１つまたは複数の取引を、この取引データベース内に記憶された対応する取引詳細の組に基づいて、照合、確認（ｃｏｎｆｉｒｍｉｎｇ）、決算（ｓｅｔｔｌｉｎｇ）、アウトソーシング、および／または修正（ａｍｅｎｄｉｎｇ）する、後続のステップを含むことが好ましい（ただし必須ではない）。

本発明の好ましい実施形態は、さらに、カスタマーに関連付けられたデフォルトのプリファランスの組に従って、要求の組を配置するステップを含む。本発明は、さらに、ユーザがデフォルトのプリファランスの組を無効にして、１つまたは複数の任意の注文を、要求の組から作成することを可能にする（つまり、カスタマーは、デフォルトのプリファランスの組が使用されているとしたら、まとめられていないであろう要求を、単一の注文内にまとめるように、システムに手動で指示する）。カスタマーは、さらに、注文から要求を削除すること、１つの注文から別の注文に要求を移動すること、またはバッチ内の２つの注文を結合して新しい注文を形成することを、システムに指示することも可能である。したがって、前記方法は、さらに、デフォルトのプリファランスの組を使用するか、または修正するための指示、あるいは、任意のまたはすべての注文内の要求のデフォルトの配置を修正するための指示を、通信チャネルを介して、カスタマーから受け取るステップを含んでいてもよい。プリファランスの組は、例えば、個々の注文についての最大値または最小値、使用するアカウントまたは相手方銀行の優先される組、通貨や決算日の優先される組、その他を含んでいてもよい。

本発明は、さらに、さまざまなクラスからの資産を含む要求を一括して取引するために使用されてもよい。例えば、カスタマーは、外国証券市場で売られている有価証券を買うことに関心がある場合がある。しかし、カスタマーは、最初に、国内通貨（例えば、米ドル）を、外国市場で受理される通貨（例えば、円）に変換する必要がある。したがって、要求の組は、有価証券を買うかまたは売る提案（有価証券資産クラス）と、１つの通貨を別の通貨と交換する提案（外国為替資産クラス）との、両方を含んでいてもよい。この場合、前記配置するステップは、有価証券要求と外国為替要求とを同じ注文に割り当てるステップと、それらが同じ資産クラスの中にないにもかかわらず、２つの要求のネッティングされた値を計算するステップとを含んでいてもよい。

本発明は、バッチ内の１つの注文についてのクォートを自動的に生成することに加えて、あるいはその代わりに、バッチ内の各注文についてのクォートを自動的に生成することのために使用されてもよい（その結果として、注文の集まりについてのクォートの集まりが生成される）。したがって、本発明の原理に従って、カスタマーは、バッチ内の１つの注文の中のすべての要求、バッチ内の複数の注文の中のすべての要求、またはバッチ内のすべての注文の中のすべての要求を一括して処理することを選択してもよい。要求を一括して処理するとは、例えば、１つまたは複数の注文内のすべての要求についての気配値またはクォートを要求すること、１つまたは複数の注文内のすべての要求が、１つの優先される相手方に送られることを要求すること、１つまたは複数の注文内のすべての要求が、複数の優先される相手方に送られることを要求すること、１つまたは複数の注文内のすべての要求についてのクォートされた価格を受諾するように、システムに指示することなどを意味している。

場合によっては、カスタマーは、例えばユーザ入力画面上の一連の指示、キーストローク、またはマウスクリックを介して、１つまたは複数の注文を、送られる１つまたは複数の注文が、カスタマと相手方との間の以前の取引に関連付けられた１つまたは複数の詳細を含むことを相手方に示す信号（フラグまたはその他のインジケータ）とともに、相手方に送るようにシステムに指示してもよい。以前の取引は、その一部または全体が、例えば、カスタマーと相手方との間の面談の中で、自動オンライン取引システム上で、またはそれを介して、あるいは電話またはファクシミリ接続を通して執行されていてもよい。クォートを完了するための欠落している、または追加の項目（ｔｅｒｍ）を、ブックおよび／または取引の執行に先立って提供することが、相手方にとって必要であるか、または望ましい場合に、カスタマーは注文を、この信号またはフラグとともに送るのが一般的である（ただし必須ではない）。

外国為替注文については、例えば、カスタマーとプロバイダーとは、電話を介して行われた以前の取引において、以前の取引の注文内のすべての要求の、ネッティングされたスポットポジション（ｎｅｔｔｅｄ ｓｐｏｔ ｐｏｓｉｔｉｏｎ）をすでに取引している場合がある。ネッティングされたスポットポジションとは、以前の取引の注文内のすべての要求について計算されたネッティングされた値に基づく、関与者により取引された通貨の正味の量を意味する。したがって、例えば、現在の注文が、以前の取引の注文内の各要求についての、各決済日についての量を含むことをプロバイダーに示すために、信号、フラグ、またはその他のインジケータが使用される。別の場合には、カスタマーは、以前の取引の注文を完了するために必要なその他の詳細（例えば、以前の取引の注文内の各要求についてのアカウント番号および決済日など）を、現在の注文が含むことをプロバイダーに通知するために、フラグをセットしてもよい（または、フラグがセットされるようにしてもよい）。通常、プロバイダーは、次に、クォートを完了するために、すべての非スポット決済日についての価格を提供する。

一部の実施形態によれば、本発明は、さらに、相手方との第２の通信チャネルを確立するステップと、第２の通信チャネルを介して相手方に注文を提示するステップと、第２の通信チャネルを介して相手方からクォートを受け取るステップとを含む。この実施形態では、前記方法は、さらに、任意選択で、第２の通信チャネルを介して相手方に受諾を伝送するステップと、受諾に応えた確認（ｃｏｎｆｉｒｍａｔｉｏｎ）を相手方から受け取るステップと、第１の通信チャネルを介してカスタマーに確認を送るステップとを含んでいてもよい。もう１つの任意選択は、取引のグループがブックされたことを示す通知を、第２の通信チャネルを介して、相手方に送るステップを含む。

本発明のもう１つの態様では、資産を取引するための別の方法が提供され、前記方法は、（１）カスタマーとの通信チャネルを確立するステップと、（２）通信チャネルを介してカスタマーから要求の組を受け取るステップと、（３）注文のバッチを形成するように要求の組を配置するステップと（バッチ内の各注文は、要求の組の中の要求のサブセットを含む）、（４）バッチ内の注文をブックするための要求をカスタマーから受け取るステップと、（５）前記要求に応えて取引のグループをブックするステップと（グループ内の各取引は、注文内の要求に対応する）、（６）取引のグループに関連付けられたブックの詳細をカスタマーに伝送するステップとを含む。ブックの詳細は、例えば、執行、価格設定、アカウント、または決済日の情報を含んでいてもよく、それらは、カスタマーとの間に確立された通信チャネルを介して、あるいは電話、ファクシミリ、または電子メールなどのその他の何らかの手段を通して、カスタマーに伝送されてもよい。

本発明のこの態様は、取引のグループがブックされる前に、カスタマーに、気配値またはクォートなどの価格設定情報を要求または提供するステップは、必ずしも含んでいない。取引は、カスタマーによる要求の組の提供に応えて、好ましくは取引規則またはカスタマーのプリファランスの組に従って、自動的にブックまたは執行されてもよい。そのような取引は、プロバイダーは利用できる最良の価格をカスタマーに提供するという、カスタマーとの合意に基づいて、銀行によりブックまたは執行されてもよい。前記方法は、さらに、取引のグループが執行されたことを示す通知をカスタマーに送るステップと、執行の詳細をカスタマーに提供するステップとを含んでいてもよい。好ましくは、取引のグループに関連付けられた執行の詳細は、データベースに記憶され、そこでそれらの執行の詳細は、カスタマーのためにブックされた取引の詳細と、相手方のためにブックされた取引の詳細との照合および確認などの、さらなる処理のために検索されてもよい。

本発明のさらにもう１つの態様では、資産を取引するためにコンピュータシステムと交信するための方法が提供され、前記方法は、（１）コンピュータシステムとの通信チャネルを確立するためのコマンドを含む、注文管理システムを起動するステップと、（２）注文管理システムを介してコンピュータシステムに要求の組を提供するステップと、（３）コンピュータシステムに注文のバッチを生成させるために、注文管理システム内のコマンドを呼び出すステップと（バッチ内の各注文は、要求の組からの要求のサブセットを含む）、（４）バッチ内の少なくとも１つの注文の中の各要求を実現するために、取引のグループを一括して執行するためのクォートをコンピュータシステムが提供するように、注文管理システム内のコントロールを選択するステップと、（５）クォートを受諾するための指示を、注文管理システムを介して発行するステップとを含む。好ましい実施形態では、前記方法はさらに、（６）取引のグループに関連付けられたプリファランスの組を提供するために、注文管理システム内のコマンドを実行するステップと、（７）コンピュータシステムが相手方に注文を送るように構成された、別のコントロール（例えば、グラフィカルユーザインタフェース内のボタンまたはチェックボックスなど）を選択するステップとを含んでいてもよい。

本発明の別の態様によれば、資産取引システムが提供され、前記システムは、（１）カスタマーからの要求の組を受け取るための通信チャネルと、（２）要求の組を注文のバッチ内に配置するように構成されたバッチマネージャと（バッチ内の各注文は、要求の組からの要求のサブセットを含む）、（３）バッチ内の注文についてのクォートを提供するように構成された取引サーバと（クォートは、取引のグループを執行するための価格を含み、グループ内の各取引は、注文内の要求に対応する）、（４）通信チャネルを介してカスタマーにクォートを提示し、通信チャネルを介してカスタマーからクォートの受諾を受け取るように構成された、ユーザインタフェースとを含む。取引サーバは、さらに、ユーザインタフェースによって受け取られた受諾に応えて、取引のグループをブックするように構成される。

一部の実施形態では、バッチマネージャは、プリファランスの組に従って、要求の組を配置するように構成される。好ましい実施形態では、ユーザインタフェースは、さらに、クォートを提供するための要求を、通信チャネルを介してカスタマーから受け取り、取引のグループが執行されたことを示す通知を、通信チャネルを介してカスタマーに送り、プリファランスの組を、あるいは１つまたは複数の注文内の要求のデフォルトの配置を修正するための指示を、通信チャネルを介してカスタマーから受け取るように構成される。ユーザインタフェースは、さらに、特定の相手方、または相手方のグループに注文を送る要求を、カスタマーから受け取るように構成されてもよい。プリファランスの組は、本発明の原理に従って、この目的のために構成された任意選択の管理サーバ内に記憶されてもよい。その上、取引サーバは、さらに、取引のグループを執行するように構成されてもよい。

実際には、本発明に従って動作するように構成されたシステムは、ネッティング機能も含む。それにより、要求の組が、特定の通貨ペア、特定のアカウント、または特定の決算日を共通して有する少なくとも２つの要求を含む場合、バッチマネージャは、前記少なくとも２つの要求を同じ注文に割り当て、それらの２つの要求についてのネッティングされた値を計算する。そのようなネッティング機能は、要求が同じ取引通貨（ｄｅａｌｔ ｃｕｒｒｅｎｃｙ）を有する場合だけでなく、要求が同じ取引通貨を有さない場合にも実装されてもよい。またさらに、好ましい実施形態では、バッチマネージャは、混合された資産クラスを有する要求（例えば、１つの要求は為替（ｃｕｒｒｅｎｃｙ ｅｘｃｈａｎｇｅ）を求め、もう１つの要求は有価証券を買うこと、または売ることを求める）を結合して、ネッティングされた値を計算するように構成されてもよい。

システムは、任意選択で、取引のグループを執行するための気配値を生成するように構成された気配値エンジンを含み、それによりカスタマーは、提出された要求についての市場の状態に関する有用な価格設定情報を、相手方からの実際のクォートを要求および／または取得する前に得ることが可能になる。気配値エンジンは、バッチマネージャ、ユーザインタフェース、または取引サーバに直接接続されていても、いなくてもよい。

本発明の方法に関して上で述べたように、カスタマーは、バッチ内の単一の注文、バッチ内の複数の注文、またはバッチ内のすべての注文を、一括して処理することを選択してもよい。したがって、本発明に従って動作するように構成されたシステム内のバッチマネージャは、さらに、バッチに対するクォートの集まり（バッチ内の各注文について１つのクォート）を生成するように構成される。その上、ユーザインタフェースは、クォートの集まりを、通信チャネルを介してカスタマーに提示するように、そして、クォートの集まりを受諾するための指示を、通信チャネルを介してカスタマーから受け取るように構成されてもよい。この機能により、カスタマーは、要求のバッチ全体のクォート、ブック、および／または執行を行うように、迅速かつ効率的にシステムに指示することが可能になる。

システムは、任意選択で、取引サーバに接続された第２の通信チャネルを含む。第２の通信チャネルは、取引サーバから相手方に注文を伝え、相手方から取引サーバにクォートを伝え、そして、取引サーバから相手方に受諾を伝えるように構成される。第２の通信チャネルは、さらに、受諾に応えた確認を相手方から取引サーバに伝えるための経路を提供してもよい（前記確認は、通常、ユーザインタフェースを通してカスタマーに送られる）。

ここで説明した本発明の実施形態のそれぞれの中の通信チャネルは、例えば、インターネット接続、ワイドエリアネットワーク接続、ローカルエリアネットワーク接続、電話接続、または上述のタイプの接続のうちの１つまたはすべての何らかの組み合わせを含んでいてもよい。

本発明の一部の実施形態では、システムはさらに、ユーザインタフェースサーバおよびストレートスルー処理（「ＳＴＰ］）アダプタの制御下で、カスタマーから直接入力を受け取るように構成された、注文管理システムを含んでいてもよい。ＳＴＰアダプタは、通常、取引サイクルに関与しているすべての関与者への、取引情報のシームレスな、自動化された、電子転送を提供するために、要求を１つの標準または専用フォーマットから別の標準または専用フォーマットに変換するように構成された、ハードウェア、ソフトウェア、または両方の、１つまたは複数の部分を含む。相手方側では、本発明の原理に従って動作するように構成されたシステムは、さらに、取引サーバの制御下で相手方から直接入力を受け取るように構成された、相手方取引管理システムを含んでいてもよい。取引管理システムは、さらに、要求の組の中の各要求についての実際の価格を生成するように構成された価格エンジンを含んでいてもよく、かつ／または、前記価格エンジンに接続されていてもよい。

最後に、本発明のこの態様の好ましい実施形態では、システムは、ユーザインタフェースサーバ、バッチ管理サーバ、および取引サーバへの許可されていないアクセスを防止するための、業界でよく知られている方法に従って構成された、セキュリティサーバを含む。通常、セキュリティサーバは、カスタマー、銀行、ブローカー、およびその他のプロバイダーに関連付けられたセキュリティ関連データを含む、セキュリティデータベースに接続される。

本発明のさらにもう１つの態様では、コンピュータシステム上で資産を取引するためのユーザインタフェースが提供される。ユーザインタフェースは、注文管理システムによって呼び出し可能であり、同時に表示可能であっても、なくてもよい、２つの表示画面を含む。第１の表示画面は、カスタマーからの、要求の組を含む入力を受け取るように構成される。他方、第２の表示画面は、第１の表示画面から受け取った入力に応じて、注文のバッチと（バッチ内の各注文は、要求の組からの要求のサブセットを含む）、バッチ内の各注文についてのクォートと（各クォートは、取引のグループを執行するための価格を含み、グループ内の各取引は、要求のサブセットの中の要求に対応する）、コンピュータシステムが、取引のグループの一括した執行を行うように構成された、ユーザが起動可能なコントロールとを表示するように構成される。前記注文は、本発明のこの態様の中のユーザインタフェースにより表示される場合、特定の通貨ペアを有する、要求の組の中のすべての要求、特定のアカウントに関連付けられた、要求の組の中のすべての要求、特定の決済日を有する、要求の組の中のすべての要求、または、上記のそれぞれの何らかの組み合わせを含んでいてもよい、

したがって、本発明の特徴は、カスタマーが複数の要求をバッチ方式で処理することを可能にし、それによりカスタマーは複数の要求を可能な限り迅速かつ効率的に処理できるようになるということである。要求は、大きな価値の取引、小さな価値の取引、または中間の任意のサイズの取引を表していてもよい。もう１つの特徴は、本発明は、カスタマーからの最小限の数の指示、キーストローク、およびマウスクリックによって、そのような処理を呼び出す、ユーザインタフェースを提供するということである。さらなる特徴は、カスタマーによってバッチモードの処理が呼び出された後、システムは、気配値、クォート、取引のブック、取引の執行、またはそれらの何らかの組み合わせを、取引の相手側における人間の介入はほとんど、またはまったくなしに、自動的に提供するということである。

これらの特徴のすべてにより、さまざまな異なる状況における取引要求の処理に関連付けられる時間、労力、およびコストに関して、既存のオンライン取引システムを大幅に超える利点が提供される。

本発明、およびそのさまざまな態様、特徴、利点について、例示的な（したがって制限的ではない）実施形態を参照して、そして（本明細書の一部を構成し、本発明のさまざまな形態のいくつかの例示的実施形態を含む）図面を利用して、以下で詳しく説明する。

図４〜８では、注文は、同じ通貨ペアおよび同じ取引通貨を有する要求の間で「ネッティング」されている。しかし、図９〜１２では、注文は、同じ通貨ペアおよび異なる取引通貨を有する要求の間で「ネッティング」されている。

好ましい実施形態の詳細な説明
ここに示す好ましい実施形態の詳細な説明では、主として外国為替（ＦＸ）取引について言及しているが、これらの言及は、その特定の状況において本発明がどのように適用されてもよいかを細部にわたって明瞭に説明することを単に意図したものであり、他の状況における本発明の適用可能性に対する制限として働くものではない。したがって、そのような言及は、金融市場、商品および有価証券の取引などの、その他の種類の金融取引が、本発明の特許請求の範囲外にあることを意味するものと解釈されるべきではない。

用語の定義
以下の用語は、本明細書内で使用される場合、文脈により他の定義が示される場合を除き、以下に示す定義を参照して理解されてもよい。

ＦＸ用語
「外国為替」または「ＦＸ」取引（または「ディール」）は、１つの通貨を別の通貨と、協定したレートで（ａｔ ａｎ ａｇｒｅｅｄ ｒａｔｅ）、指定された受け渡し日（ｄｅｌｉｖｅｒｙ ｄａｔｅ）（「決済日（ｖａｌｕｅ ｄａｔｅ）」とも呼ばれる）に交換するための契約である。

「決済日」または「決算日（ｓｅｔｔｌｅｍｅｎｔ ｄａｔｅ）」は、通貨の交換が行われる日である。

「ＦＸスポット取引（ＦＸ ｓｐｏｔ ｄｅａｌ）」、「スポット取引（ｓｐｏｔ ｔｒａｄｅ）」、および「スポット協定（ｓｐｏｔ ａｇｒｅｅｍｅｎｔ）」という用語は、ＦＸスポット日（ＦＸ ｓｐｏｔ ｄａｔｅ）に、単一の外貨を別の通貨と交換する（つまり、１つの通貨をＸ単位買い、別の通貨をＹ単位売る）取引または協定を意味する。

「ＦＸスポット日」は、通常、協定が行われた日から２営業日後であり、特定の取引日において通貨を売るまたは買うための、最も流動性のある（つまり、最も安価な）日である。

「スワップ（ｓｗａｐ）」または「スワップ協定（ｓｗａｐ ａｇｒｅｅｍｅｎｔ）」という用語は、２つの異なる決済日についての、特定の量の１つの通貨の、別の通貨に対する、同時の購入と売却、または売却と購入を含む取引を意味する。スワップは、単一の相手方（ｃｏｕｎｔｅｒｐａｒｔｙ）との単一の取引ではあるが、この取引は、資金の交換が発生する２つの決済日（または「レッグ（ｌｅｇ）」）を有する。

「スポットレート（ｓｐｏｔ ｒａｔｅ）」は、マーケットメーカー（ｍａｒｋｅｔ ｍａｋｅｒ）が基準通貨（ｂａｓｅ ｃｕｒｒｅｎｃｙ）を別の通貨に対して売買するレート（ビッド（買い）価格とオファー（売り）価格との組み合わせとして表される）である。

「オール・イン・レート（Ａｌｌ−ｉｎ ｒａｔｅ）」という用語は、通常、アウトライト（ｏｕｔｒｉｇｈｔ）の文脈の中で、交換が発生する総合レート（ｏｖｅｒａｌｌ ｒａｔｅ）を意味する。オール・イン・レートは、スポットレートとＦＸポイント（ＦＸ ｐｏｉｎｔｓ）（価格調整）とを加算することにより計算される。

「シングル・スポット・ポートフォリオ（ｓｉｎｇｌｅ ｓｐｏｔ ｐｏｒｔｆｏｌｉｏ）」（ＳＳＰ）は、任意の組み合わせの決済日における、単一の通貨ペア内での、１つまたは複数のレッグを含むＦＸ取引である。取引通貨（ｄｅａｌｔ ｃｕｒｒｅｎｃｙ）は、すべてのレッグについて同じでなければならない。ＳＳＰ価格クォート（ＳＳＰ ｐｒｉｃｅ ｑｕｏｔｅｓ）は、通常、スポットレート、非スポット決済日（ｎｏｎ−ｓｐｏｔ ｖａｌｕｅ ｄａｔｅ）のそれぞれについてのＦＸポイント、および非スポット決済日のそれぞれについてのオールインレートという、４つの構成要素を有する。

「マルチプル・スポット・ポートフォリオ（ｍｕｌｔｉｐｌｅ ｓｐｏｔ ｐｏｒｔｆｏｌｉｏ）」または「マルチスポット・ポートフォリオ（ｍｕｌｔｉ−ｓｐｏｔ ｐｏｒｔｆｏｌｉｏ）」（ＭＳＰ）は、任意の組み合わせの決済日における、複数の通貨ペア内での、１つまたは複数のレッグを含むＦＸ取引である。取引通貨は、すべてのレッグについて同一ではない。

関与者（Ｐａｒｔｉｅｓ）
「プロバイダー」という用語は、通常、「流動性プロバイダー（Ｌｉｑｕｉｄｉｔｙ Ｐｒｏｖｉｄｅｒ）」の略記である。「流動性プロバイダー」は、通常、取引システムの中でマーケットメーカーとして働く、銀行などの金融機関である。流動性プロバイダーは、「カスタマー」からの要求に応じて価格をクォートする。

ここで使用される「銀行」という用語は、通常、「プロバイダー」と区別なく使用される。

「ディーラー」または「トレーダー」という用語は、通常、プロバイダー側からシステムを監視し、価格クォートに対するカスタマーの要求に応じる、銀行または流動性プロバイダーの従業員を意味する。

「カスタマー」という用語は、通常、銀行、プロバイダー、ディーラー、またはトレーダーではない、システムの使用者を意味する。カスタマーは、１つまたは複数のプロバイダーに、スワップ、フォワード、またはスポット取引などの特定のＦＸ証券についての価格を尋ねることにより、取引プロセスを開始する。「カスタマー」は、通常、「ユーザ」と実質的に区別されないが、場合によっては、文脈により、「カスタマー」は、例えば会社内などの、ユーザの集合も意味してもよい。

さまざまな概念
「ストレートスルー処理（Ｓｔｒａｉｇｈｔ−ｔｈｒｏｕｇｈ−Ｐｒｏｃｅｓｓｉｎｇ）」という用語は、注文から決算までの取引プロセスのエンド・ツー・エンドの自動化を意味する。これは、取引サイクルに関与するすべての関与者への、できるだけ早い、取引情報のシームレスな、自動化された電子転送を含む。

「取引通貨（ｄｅａｌｔ ｃｕｒｒｅｎｃｙ）」という用語は、外国為替の提案またはクォートにおける固定通貨を意味する、外国為替用語である。例えば、外国為替市場の参加者が、１００万ユーロを、同等量の米ドルと交換する取引を提案またはクォートした場合、その取引は、固定量のユーロを、可変量の米ドルに対して取引することを必然的に含む。米ドルの量は、為替レートによって異なる。したがって、この取引の中での取引通貨（「基準通貨（ｂａｓｅ ｃｕｒｒｅｎｃｙ）」とも呼ばれる）は、ユーロである。他方、米ドルは、「対価通貨（ｃｏｕｎｔｅｒ ｃｕｒｒｅｎｃｙ）」と呼ばれる。

「ネッティング（ｎｅｔｔｉｎｇ）」、「ネッティングされたスポットポジション（ｎｅｔｔｅｄ ｓｐｏｔ ｐｏｓｉｔｉｏｎ）」、および「ネッティングされた値の計算（ｃｏｍｐｕｔｉｎｇ ａ ｎｅｔｔｅｄ ｖａｌｕｅ）」という用語は、さまざまな取引から発生する複数の支払を、単一の、同等の支払にまとめることを意味する。複数の取引（ｔｒａｎｓａｃｔｉｏｎｓ）、要求（ｒｅｑｕｉｒｅｍｅｎｔｓ）、またはディール（ｄｅａｌｓ）のネッティングは、通常、決算プロセスを単純化し、取引コストを減少させる。

頭字語
ＡＰＩ−アプリケーション・プログラマ・インタフェース（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｅｒ Ｉｎｔｅｒｆａｃｅ）。コンピュータ間のインタフェースを表し、会話では頭字語のまま使用される。

ＯＭＳ−注文管理システム（Ｏｒｄｅｒ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）。注文管理システムは、市場で取引が執行される必要のあるＦＸ、それらを執行すべき人、その他の記録を維持するために、カスタマーにより使用される。取引が執行されると、ＯＭＳは、通常、各取引についての執行レートを使用して更新される。

ＳＳＰ−シングル・スポット・ポートフォリオ（Ｓｉｎｇｌｅ Ｓｐｏｔ Ｐｏｒｔｆｏｌｉｏ）。単一の通貨ペアについての、複数の決算日を含む、外国為替取引または「ディール」である。プロバイダーは、各決算日について、単一のスポットレート（したがって、名前）を、ＦＸポイントとともにクォートする。

ＭＳＰ−マルチプル・スポット・ポートフォリオ（Ｍｕｌｔｉｐｌｅ Ｓｐｏｔ Ｐｏｒｔｆｏｌｉｏ）。複数の通貨ペアについての、複数の決算日を含む、外国為替取引または「ディール」である。

ＲＦＱ−リクエスト・フォー・クォート（Ｒｅｑｕｅｓｔ Ｆｏｒ Ｑｕｏｔｅ）。取引のプロトコルであり、カスタマーはこれによって、特定の通貨ペア、決済日、および量についての価格を尋ねることにより取引を開始する。銀行は、カスタマーに価格（つまり、クォート）を送り返すことにより応答する。その価格を受け入れるには、カスタマーは、通常、受諾または「オファー・ツー・ディール（Ｏｆｆｅｒ ｔｏ Ｄｅａｌ）」をプロバイダーに送る。

ＵＳＤ−米ドル（Ｕｎｉｔｅｄ Ｓｔａｔｅｓ Ｄｏｌｌａｒｓ）
ＧＢＰ−英ポンド（Ｕｎｉｔｅｄ Ｋｉｎｇｄｏｍ Ｓｔｅｒｌｉｎｇ）
ＪＰＹ−日本円（Ｊａｐａｎｅｓｅ Ｙｅｎ）
ＣＨＦ−スイス・フラン（Ｓｗｉｓｓ Ｆｒａｎｃ）
ＥＵＲ−欧州ユーロ（Ｅｕｒｏｐｅａｎ Ｅｕｒｏ）
ＣＡＤ−カナダ・ドル（Ｃａｎａｄｉａｎ Ｄｏｌｌａｒｓ）
ＮＯＫ−ノルウェー・クローネ（Ｎｏｒｗｅｇｉａｎ Ｋｒｏｎｅｒ）

高レベルアーキテクチャの説明
図１は、本発明に従って動作するように構成された資産取引システムの高レベルブロック図を示す。図１に示すように、本発明の原理によるコンピュータシステム１００は、ユーザインタフェースサーバ１１０、バッチ管理サーバ１１５、取引サーバ１２０、気配値エンジン１２５、管理サーバ１３０、および取引データベース１３５を含む。図１に示すように、そして、以下でさらに詳しく説明するように、本発明に従って動作するように構成された資産取引システムは、さらに、セキュリティサーバ１６０、セキュリティデータベース１６５、ならびに、カスタマー注文管理システム１４０、ストレートスルー処理（ＳＴＰ）アダプタ１４５、価格エンジン１５０，および相手方取引管理システム１５５も含んでいてもよい。

カスタマー注文管理システム１４０は、通常、外国為替要求のリストなどのカスタマー入力を受け入れるように構成された、標準または専用の、プログラムまたはプロセッサを含む。カスタマー注文管理システム１４０は、さらに、例えば、最近のコンピュータシステムのユーザによく知られている単純なカットおよびペーストコマンドによって要求をインポートおよびエクスポートするのに適した、通常のスプレッドシートも含んでいてもよい。カスタマー入力は、カスタマー注文管理システム１４０上で、キーボードのキーストローク、マウス、およびその他のコンピュータ入力装置により操作される、ユーザ入力画面、フィールド、ボタン、およびコントロールを介して提供されてもよい。ＳＴＰアダプタ１４５は、要求およびメッセージがカスタマー注文管理システムからユーザインタフェースサーバに、またはその逆に移動される場合に、それらの要求およびメッセージを１つのフォーマットから別のフォーマットに変換するように構成されているため、ある種の変換機構として働く。

ユーザインタフェースサーバ１１０は、カスタマ注文管理システム１４０およびＳＴＰアダプタ１４５などの、１つまたは複数のカスタマー側アプリケーションと、リンク１０１を介して、オンライン接続（例えば、インターネット接続）を確立するように構成されている。ユーザインタフェース１１０は、さらに、入出力画面イメージ（例えば、ハイパーテキストマークアップ言語（Ｈｙｐｅｒ−Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）ｗｅｂページ）を生成し、リンク１０１を介してカスタマー側アプリケーションに伝送するための、よく知られた方法により構成される。ユーザインタフェースサーバ１１０は、さらに、カスタマーからの入力および指示（通常は、マウスクリックおよびキーストロークの形態）を受け取り、そのような入力および指示を、さらなる処理のために、適切なシステム構成要素（例えば、バッチ管理サーバ１１５、取引サーバ１２０、または取引データベース１３５）に渡す。

バッチ管理サーバ１１５は、オンライン接続１０１およびユーザインタフェースサーバ１１０を介してカスタマーにより提出された要求を、１つまたは複数の注文のバッチ内に、結合、コレート（ｃｏｌｌａｔｅ）、および／または配置する（各注文は１つまたは複数の要求を含む）。バッチ管理サーバ１１５は、これらの操作を、管理サーバ１３０内に記憶された、あるいは、カスタマーにより要求とともに提供された、デフォルトのプリファランスまたはプロファイルの組に従って実行することが好ましい（ただし、必須ではない）。好ましい実施形態では、バッチ管理サーバ１１５は、さらに、同じ通貨ペア、同じアカウント、および／または同じ決済日を共通に有する要求についての、ネッティングされた値も計算する。

ネッティングプロセスの機構は、通常、カスタマーと相手方との間のネッティング協定により定義される。一般的なプロセスでは、それらの２つの関与者が、同じ銀行預金口座についての、同じ決済日にスケジュールされたキャッシュフローを調べて、純支払（ｎｅｔ ｐａｙｍｅｎｔ）のみを交換するように協定する。スケジュールされた支払を生成した、基礎となる取引は、異なる日に執行されていてもよいことに留意されたい。純支払の量が合意された後は、いかなる新しい取引も別に処理しなければならず、そうしない場合は、最初の純支払スケジュールは取り消さなければならない。そのような取引が複数ある場合、同様に、それらをまとめて単一の支払にネッティングすることが可能であるが、当初のネッティングされた支払は変更されないまま残る。

以下の表１は、同じ通貨ペアを有する取引要求についての支払を、それらの取引を執行およびブックする前にネッティングすることの利点の１つを、例として示す。

表１に示すように、カスタマーは、２つの要求を、別々に取引する代わりに、ネッティングに基づいて取引することにより、＄３０（＄１１７，６６０−＄１１７，６３０）節約できる。

上の表１は、同じ取引通貨（この場合は、ユーロ）を指定する２つの要求のネッティングの結果を示す。しかし、同じ通貨ペアを有する要求は、それらが同じ取引通貨を有していない場合でも、ネッティングされてもよい。このプロセスは、「通貨ペア間ネッティング（ｉｎｔｒａ−ｃｕｒｒｅｎｃｙ ｐａｉｒ ｎｅｔｔｉｎｇ）」と呼ばれる。表２は、通貨ペア間ネッティングの利点を、例として示す。

表２に示すように、カスタマーは再び、２つの要求を、別々に取引する代わりに、ネッティングに基づいて取引することにより、＄３０節約できる。

図１に示すシステムを再び参照すると、バッチ管理サーバ１１５は、カスタマーにより提供された要求を取り上げて、必要に応じて、要求の組に含まれている要求を一緒に再編成し、結合して、ネッティングする。好ましい実施形態では、バッチ管理サーバ１１５は、さらに、気配値エンジン１２５から、要求についての気配値を受け取る。通常、注文のバッチと気配値は、次に、ユーザインタフェースサーバ１１０により、オンライン接続１０１、ＳＴＰアダプタ１４５、およびカスタマー注文管理システム１４０を使用して、カスタマーに提示される。それに応えて、カスタマーは、例えばユーザインタフェースサーバにより提供される表示画面上の１つまたは複数の入力コントロールを選択することにより、バッチ内の１つまたは複数の注文が、クォートまたは執行のために、相手方に送られることを要求してもよい。カスタマーがこの要求を行った場合、バッチ管理サーバ１１５は、選択された注文を、取引サーバ１２０に転送する。

取引サーバ１２０は、注文のバッチ（ちなみにこれは、バッチからの複数の注文、すべての注文、または１つのみの注文を含んでいてもよい）を受け取り、それらを、オンライン接続１０２を介して、システムの相手方側の構成要素に送る。好ましい実施形態では、取引サーバ１２０は、オンライン接続１０２を介して、相手方取引管理システム１５５に接続されており、相手方取引管理システム１５５は、相手方（通常はプロバイダー銀行）が注文、リクエスト・フォー・クォート、その他を受け取って応答することを可能にする、１つまたは複数のアプリケーションプログラムまたはプロセスを含んでいる。したがって、相手方は、本発明の原理に従った相手方取引管理システム１５５を使用して、特に、新しい注文についてのクォート、未決注文（ｐｅｎｄｉｎｇ ｏｒｄｅｒｓ）についての価格の追加と調整、ならびに、ブックされた、および／または執行された注文についての確認と取引詳細（ｔｒａｄｅ ｄｅｔａｉｌｓ）とを提供してもよい。

図１に示すように、本発明の実施形態は、さらに、通常は相手方取引管理システム１５５に接続された、価格エンジン１５０を含んでいてもよい。価格エンジン１５０は、取引サーバ１２０から要求を受け取ると、それらの要求についての価格クォートを自動的に生成するように構成されており、それにより相手方は、入ってくる注文についての正確かつ採算の取れるクォートを、人間の介入なしに、即座に、そしていつでも提供することが可能になる。したがって、価格エンジン１５０をシステム内に含めることにより、多数の要求を含む注文、または注文のバッチの、提案、ブック、および確認に要する時間が、通常は大幅に削減される。

好ましい実施形態では、任意選択のセキュリティサーバ１６０が、許可されていないカスタマーおよびプロバイダーによるシステムへのアクセスを防止する。これらのセキュリティ手段を補助（ｆａｃｉｌｉｔａｔｅ）および制御するために、セキュリティサーバ１６０は、各カスタマーおよび各プロバイダーについてのセキュリティ関連データ（例えば、名前、アカウント番号、パスワード、その他）を含むセキュリティデータベース１６５に接続されていてもよい。

システムの好ましい実施形態は、さらに、ブックされた、および／または執行された取引に関連付けられた、取引のメッセージおよび詳細を記憶するように構成された、取引データベース１３５を含む。システムは、さらに、取引データベース１３５内に記憶されたメッセージおよび詳細を利用した、執行ステージ後（ｐｏｓｔ−ｅｘｅｃｕｔｉｏｎ−ｓｔａｇｅ）の照合、確認、修正、決算、および流動性アウトソーシング機能を実装する、ハードウェアおよび／またはソフトウェアプロセッサを含んでいてもよい。この機能は、例えば、本発明の機能を、同時係属中の米国特許出願第１０／４６３，８６６号明細書（タイトル「ＭＥＴＨＯＤ ＡＮＤ ＡＰＰＡＲＡＴＵＳ ＦＯＲ ＭＡＮＡＧＩＮＧ ＦＩＮＡＮＣＩＡＬ ＴＲＡＮＳＡＣＴＩＯＮＳ ＩＮＶＯＬＶＩＮＧ ＭＵＬＴＩＰＬＥ ＣＯＵＮＴＥＲＰＡＲＴＩＥＳ ＡＮＤ ＰＲＯＣＥＳＳＩＮＧ ＤＡＴＡ ＰＥＲＴＡＩＮＩＮＧ ＴＨＥＲＥＴＯ」、２００３年６月１８日出願）および米国特許出願第１０／２３７，９８０号明細書（タイトル「ＭＥＴＨＯＤ ＡＮＤ ＡＰＰＡＲＡＴＵＳ ＦＯＲ ＡＭＥＮＤＩＮＧ ＦＩＮＡＮＣＩＡＬＴＲＡＮＳＡＣＴＩＯＮＳ」、２００２年９月１０日出願）に記載された発明および機能と組み合わせることにより実現されてもよい。これらの米国特許出願は、両方とも、本発明の譲受人に譲渡されており、これらの米国特許出願の全体は、この参照により開示に含まれる。

図２および図３は、例えば図１により示されるシステムなどの、本発明の実施形態に従って動作するように構成された資産取引システムにより実行されてもよいステップを、高レベルフロー図により説明する。図２に示すように、プロセスはステップ２０５で開始され、ここで、要求の組がカスタマーから受け取られる。通常、要求は、システム内にインポート、コピー、または手動でタイプされるか、あるいは、図１を参照して上で説明した、カスタマー注文管理システム（ＯＭＳ）およびＳＴＰアダプタを介してシステムに伝送される。ステップ２１０では、最小および最大の注文合計、優先される銀行預金口座、決済日などの、デフォルトの、または指定されたプリファランスの組に従って、要求の組が、注文のバッチを形成するように配置される。バッチ内の各注文は、要求の組からの要求のサブセットを含む。サブセットは、要求の組からの１つの要求、要求の組からのすべての要求、またはその間の任意の数を含んでいてもよい。

次に、ステップ２１５で、注文のバッチがカスタマーに表示される。注文のバッチは、さまざまな方法およびフォーマットでカスタマーに表示されてもよい。ここで「アロケーションビュー」および「サマリビュー」と呼ぶ、２つのそのようなフォーマットについては、図７、８、１２、および１３を参照して以下で詳しく説明する。好ましくは、注文は、現在の市場の状態についてのいくらかのアイデアをカスタマーに提供するために、気配値とともにカスタマーに表示される。これは、気配値が、カスタマーが実現を望む要求に関係するためである。

ステップ２２０に示すように、システムは、カスタマーが、任意の注文の最大値または最小値などのパラメータを新たに指定することにより、デフォルトのプリファランスの組を無効にすることを許可する。好ましい実施形態では、カスタマーは、この時点で、特定の注文から特定の要求を移動または除外することをさらに選択してもよい。次に、ステップ２２５において、システムは、カスタマーから、１つまたは複数の優先される相手方を識別する情報を受け取る。そのような情報は、さらに、例えばシステムの管理サーバ構成要素内に存在していてもよいカスタマープロファイル２３０を参照することにより提供されてもよく、あるいは、要求とともに手動で提供されてもよい。

ステップ２３５において、システムは、オプションの管理サーバ構成要素を参照して、例えば相手方銀行により定義される信用限度額や、あるいは従業員退職所得保障法（Ｅｍｐｌｏｙｅｅ Ｒｅｔｉｒｅｍｅｎｔ Ｉｎｃｏｍｅ Ｓｅｃｕｒｉｔｙ Ａｃｔ）（ＥＲＩＳＡ）などの政府規制などのなどのビジネス規則２４０の組の下で、要求された取引が許可されるかどうかを判定してもよい。取引が許可されない場合は、エラーメッセージが表示され（ステップ２５０）、処理はステップ２２０に戻り、そこで、カスタマーは、ビジネス規則２４０により提供される許可の範囲内に適合させるために、注文を調整することが可能になる。例えば、注文が、信用限度額を超える場合、ユーザは、注文を２つのより小さな注文に分割して（ステップ２２０での操作）、各注文が異なる銀行に送られることを要求してもよい（２２５の操作）。

他方、ステップ２３５において、要求された取引がビジネス規則２４０の下で許可されると判定された場合、システムは、ステップ２５５において、価格設定（ｐｒｉｃｉｎｇ）のために注文を相手方に送る要求がすでに受け取られているかどうかを判定する。そのような要求が受け取られていない場合、システムは、そのような要求の確認を単に継続する。しかし、プロバイダーに注文を送る要求がすでに受け取られている場合、処理はステップ２６０に進み、そこでシステムは、カスタマーと相手方との間の以前の取引に関係する詳細が注文に含まれていることを示す信号またはフラグを、カスタマーがさらに送ったかどうかを判定する。信号またはフラグが送られていない場合、処理は、フローチャートコネクタＦＣ１を経由して、図３のステップ３０５に進み、そこでシステムは、選択された相手方に注文のバッチを送り（ステップ３０５）、注文に対する価格を相手方から受け取る（ステップ３１０）。ステップ２６０で、信号またはフラグがすでに送られていると判定された場合、処理は、フローチャートコネクタＦＣ２を経由して、図３のステップ３２０に進み、そこで、バッチおよびフラグが相手方に送られる（ステップ３２０）。ステップ３２５で、システムは、相手方とカスタマーとの間の以前の取引に関連付けられた注文を完了させるための、追加の、または調整された価格を相手方から受け取る。

次に、システムは、注文に対する価格をカスタマーに表示し（ステップ３１５）、カスタマーがその価格を受諾したか、または拒否したかを判定する（それぞれ、ステップ３３０および３４５）。ステップ３３０で受諾が受け取られた場合、注文内の要求に対応する１つまたは複数の取引が執行され（ステップ３３５）、勘定残高（ａｃｃｏｕｎｔ ｂａｌａｎｃｅ）などの特定の取引詳細がカスタマーに表示される（ステップ３４０）。処理は、次に、フローチャートコネクタＦＣ３を経由して、フロー図の最初（図２のステップ２０５）に戻る。しかし、ステップ３４５において、カスタマーが価格を拒否したと判定された場合、取引は終了し、再び、処理は、フローチャートコネクタＦＣ３を経由して、フロー図の最初（図２のステップ２０５）に戻る。

他方、ステップ３３０および３４５において、カスタマーが受諾または拒否のいずれも提供していないと判定された場合、システムは、更新された価格が相手方から受け取られているかどうかを判定する（ステップ３５０）。更新された価格が受け取られている場合、制御はステップ３１５に戻り、そこで、それらの更新された価格がカスタマーに提示される。更新された価格が受け取られていない場合、システムは、ステップ３５５で、指定された時間制限を経過したかどうかを判定する。指定された制限時間を経過している場合、処理は、再び、フローチャートコネクタＦＣ３を経由して、図２のステップ２０５に進む。制限時間を経過していない場合、制御は再びステップ３３０に戻り、そこでシステムは、カスタマーが価格を受諾したか拒否したかの判定を試みる（それぞれ、ステップ３３０および３４５）。

図４は、本発明の原理に従って動作するように構成されたバッチ取引システム内に、要求をコピー、ペースト、およびインポートするために使用されてもよい、ユーザ入力画面の例を示す。この画面は、例えば、図１のユーザインタフェースサーバ１１０およびカスタマー注文管理システム１４０によって、描画、伝送、または提示されてもよい。参照番号４０５によって大まかに示されている領域内からわかるように、例の画面には、取引要求の組についての、特に、アカウント番号、通貨ペア、取引通貨、取引のタイプ（「Ｂ」は買い、「Ｓ」は売り）、および決済日が含まれている。図４に示す例では、１７の要求が表示されている（参照番号４０５により大まかにラベル付けされた領域を参照されたい）。要求は、カスタマーにより手動でタイプされてもよく、あるいは、別のファイルまたはプログラムから、ロードまたはペーストされてもよい。したがって、画面には、テキスト入力フィールドおよびコントロールも含まれており（それぞれ、４１０および４１５とラベル付けされている）、カスタマーはそれを使用して、追加の、および／または代替の要求を含むファイルを指定およびロードしてもよい。要求をロードまたは手動でタイプした後、カスタマーは、例えば、図４で４２０とラベル付けされた「インポート」ボタンをクリックすることにより、その要求を、本発明のバッチ管理サーバ構成要素に伝送してもよい。

図５は、要求の組が、注文および要求のバッチ内に配置された後で、それらの要求の組を、それらが銀行などの相手方に提出される前に、気配クォート（ｉｎｄｉｃａｔｉｖｅ ｑｕｏｔｅ）とともに提示するために使用されてもよい、表示画面の例を示す。図５は、３つの注文（大まかに、５０５、５１０、および５１５とラベル付けされている）内に配置された１５の要求を示す。この場合、同じ通貨ペアおよび取引通貨を有するすべての要求が、同じ注文内にあるように配置されている。例えば、ＥＵＲ．ＵＳＤという通貨ペアを有するすべての要求は、５０５で示されている注文の中に配置されている。その上、特定の注文内のすべての要求のネッティングされた値が、計算されて、各注文の最上部に表示されている。例えば、注文５１０内の５つの要求のネッティングされた値は、３３０，０００ ＧＢＰである。したがって、注文５１０の最上部に、３３０，０００ ＧＢＰ（図５で５２０とラベル付けされている）が表示されている。各要求についての気配値も、大まかに５５０で示されている列内に示されている。

注文を送るための優先される銀行をカスタマーが指定できるようにするための、入力フィールド（図５で５２５とラベル付けされている）も提供されている。カスタマーが１つまたは複数の注文を、図２および図３を参照して上で説明した「詳細送信」フラグを設定して、または設定せずに、指定された銀行に送ることができるようにするための、コントロール（５３０および５３５とラベル付けされている）が提供されている。最後に、カスタマーがバッチ全体（画面上のすべての注文内のすべての要求）を同時に送ることができるようにするための、コントロール（図５で５４０とラベル付けされている）が提供されている。

図５の例示的表示画面は、各注文内のすべての要求を示す。これは、注文のバッチの「アロケーションビュー」と呼ばれる。図５で５７０とラベル付けされたコントロールを選択（例えば、クリック）することにより、カスタマーは、システムに、各注文内の「売り」要求を結合してネッティングすること、および各注文内の「買い」要求をすべて結合してネッティングすることを指示してもよい。その結果は、図６に示す例示的画面であり、これは、注文のバッチの「サマリビュー」と呼ばれる。

図７は、バッチが提出され、銀行により価格設定されて戻された後の、要求のアロケーションビューを示す。図７に示すように、実際の価格クォートは、各要求の横に並べられている（図７で大まかに７１０とラベル付けされている列を参照）。コントロール７２１および７３０は、カスタマーが、１つまたは複数の注文を受諾または拒否することができるように提供されている。さらに、コントロール７４０および７５０は、カスタマーが、注文のバッチ全体を、１クリックで受諾または拒否するための方法を提供するように構成されている。図８は、図７に含まれている注文のバッチのサマリビューを示す。

図４〜８では、同じ通貨ペアおよび同じ取引通貨を有する要求間で、注文が「ネッティング」される。しかし、図９〜１２では、同じ通貨ペアおよび異なる取引通貨を有する要求間で、注文が「ネッティング」される。したがって、例えば図９は、要求の組を、各要求についての気配クォート（図９で大まかに９２０で示されている列を参照）とともに含む、注文のバッチ（図９で９０５、９１０、および９１５とラベル付けされている）のアロケーションビューを示す。しかし、図９に示すように、各注文は、異なる取引通貨を有する要求を含む。例えば、注文９０５は、ＥＵＲを取引通貨として指定するいくつかの要求と、ＵＳＤを取引通貨として指定するその他の要求とを含む。

各注文の最上部に示されている、異なる取引通貨を有する要求のネッティングされた値（図９の９３０を参照）は、２つの取引通貨の間の為替レートについての気配値に従って計算される。ネッティングされた値は、概算インジケータ（「〜」）とともに示されており、これは、示されているネッティングされた値は、「気配」価格に基づいた概算にすぎず、実際のクォートに基づいたものではないことをカスタマーに注意するためである。図１０は、図９に含まれている注文のバッチのサマリビューの例を示す。

図１１は、図７と同様に、バッチが提出され、銀行により価格設定されて戻された後の、注文のバッチ内の要求のアロケーションビューを示す。ただし、図１１は、異なる取引通貨を有する要求が注文内に存在する、注文のバッチのアロケーションビューを示す。銀行は、実際のクォートをすでに提供しており、ネッティングされた値を計算するために、気配クォートはもはや使用されていないため、概算記号（「〜」）は使用されていない。図１２は、図１１に含まれている注文のバッチのサマリビューの例を示す。

本発明は、ここで、最も好ましいと考えられる実施形態により開示され説明された。当業者が本開示を読めば、変形形態および均等物が思い浮かぶ場合があるということ、およびそのような変形形態および均等物は、本発明および添付の特許請求項の範囲内であると解釈されるということに留意すべきである。したがって、本発明は外国為替取引に限定されず、上述のようなその他のタイプの取引に有益に適用されてもよいということが、例えば、当業者により理解されるべきである。

本発明に従って動作するように構成された資産取引システムの高レベルブロック図を示す。 本発明の一実施形態に従って動作するように構成された、資産取引システム、コンピュータシステム、プロセッサ、またはプロセッサの組み合わせにより実行されてもよいステップを説明する高レベルフロー図を含む。 本発明の一実施形態に従って動作するように構成された、資産取引システム、コンピュータシステム、プロセッサ、またはプロセッサの組み合わせにより実行されてもよいステップを説明する高レベルフロー図を含む。 本発明の原理に従って動作するように構成された資産取引システム内に、取引要求をコピー、ペースト、およびインポートするために使用されてもよい、ユーザ入力画面の例を示す。 注文および要求のバッチを、それらが銀行などの相手方に提出される前に、気配クォートとともにカスタマーに提示するために、本発明の特徴に従って使用されてもよい、表示画面の例を示す。本発明の一実施形態に従って、図５の表示画面は、注文のバッチを構成するすべての要求を示す、要求の「アロケーションビュー」を含む。 同様に、注文および要求のバッチを、それらが銀行などの相手方に提出される前に、気配クォートとともにカスタマーに提示するために、本発明の特徴に従って使用されてもよい、表示画面の例を示す。ただし、本発明の実施形態に従って、図６の表示画面は、図５に示されたアロケーションビューの代替のビューを構成する、取引要求の「サマリビュー」を含む。 注文のバッチおよびクォートが銀行から戻された際のための、要求および価格クォートのアロケーションビューを示す。 バッチが銀行に提出された後で戻された、要求および価格クォートの、サマリビューを示す。 注文および要求のバッチを、それらが銀行などの相手方に提出される前に、気配クォートとともにカスタマーに提示するために、本発明の特徴に従って使用されてもよい、表示画面の例を示す。本発明の一実施形態に従って、図９の表示画面は、注文のバッチを構成するすべての要求を示す、要求の「アロケーションビュー」を含む。 同様に、注文および要求のバッチを、それらが銀行などの相手方に提出される前に、気配クォートとともにカスタマーに提示するために、本発明の特徴に従って使用されてもよい、表示画面の例を示す。ただし、本発明の実施形態に従って、図１０の表示画面は、図９に示されたアロケーションビューの代替のビューを構成する、取引要求の「サマリビュー」を含む。 注文のバッチおよびクォートが銀行から戻された際のための、要求および価格クォートのアロケーションビューを示す。 バッチが銀行に提出された後で戻された、要求および価格クォートの、サマリビューを示す。

Claims (176)

1. 資産を取引するための方法であって、前記方法は、
   カスタマーとの通信チャネルを確立するステップと、
   前記通信チャネルを介して、前記カスタマーから、要求の組を受け取るステップと、
   注文のバッチを形成するように、前記要求の組を配置するステップと（前記バッチ内の各注文は、前記要求の組からの要求のサブセットを含む）、
   前記バッチ内の注文についてのクォートを自動的に提供するステップと（前記クォートは、取引のグループを執行するための価格を含み、前記グループ内の各取引は、前記注文内の要求に対応する）、
   前記通信チャネルを介して、前記カスタマーに、前記クォートを提示するステップと、
   前記通信チャネルを介して、前記カスタマーから、前記クォートの受諾を受け取るステップと、
   前記受諾に応えて、前記取引のグループをブックするステップとを含む方法。
2. 前記通信チャネルを介して、前記カスタマーから、前記クォートを提供するための要求を受け取るステップをさらに含む、請求項１に記載の方法。
3. 前記取引のグループを確認するステップをさらに含む、請求項１に記載の方法。
4. 前記取引のグループを決算するステップをさらに含む、請求項１に記載の方法。
5. 前記通信チャネルを介して、前記カスタマーに、前記取引のグループがブックされたことを示す通知を送るステップをさらに含む、請求項１に記載の方法。
6. 前記取引のグループに関連付けられた取引詳細を、取引データベース内に記憶するステップをさらに含む、請求項１に記載の方法。
7. 前記通信チャネルを介して、前記カスタマーから、前記注文内の前記要求のサブセットを修正するための指示を受け取るステップをさらに含む、請求項１に記載の方法。
8. 前記通信チャネルを介して、前記カスタマーから、前記バッチ内の２つの注文を結合して新しい注文を形成するための指示を受け取るステップをさらに含む、請求項１に記載の方法。
9. 前記配置するステップは、プリファランスの組を使用して実行されることを特徴とする、請求項１に記載の方法。
10. 前記通信チャネルを介して、前記カスタマーから、前記プリファランスの組を修正するための指示を受け取るステップをさらに含む、請求項９に記載の方法。
11. 前記プリファランスの組は、
    注文についての最大値、および
    注文についての最小値、
    のうちの少なくとも１つを含む、請求項９に記載の方法。
12. 前記要求の組は、特定の通貨ペアを有する少なくとも２つの要求を含み、そして、
    前記配置するステップは、前記少なくとも２つの要求を、同じ注文に割り当てるステップを含む、請求項１に記載の方法。
13. 前記少なくとも２つの要求についてのネッティングされた値を計算するステップをさらに含む、請求項１６に記載の方法。
14. 前記少なくとも２つの要求は、同じ取引通貨を有さないことを特徴とする、請求項１６に記載の方法。
15. 前記少なくとも２つの要求についてのネッティングされた値を計算するステップをさらに含む、請求項１８に記載の方法。
16. 前記要求の組は、特定のアカウントに関連付けられた少なくとも２つの要求を含み、そして、
    前記配置するステップは、前記少なくとも２つの要求を、同じ注文に割り当てるステップを含む、請求項１に記載の方法。
17. 前記少なくとも２つの要求についてのネッティングされた値を計算するステップをさらに含む、請求項１６に記載の方法。
18. 前記要求の組は、特定の決済日を有する少なくとも２つの要求を含み、そして、
    前記配置するステップは、前記少なくとも２つの要求を、同じ注文に割り当てるステップを含む、請求項１に記載の方法。
19. 前記少なくとも２つの要求についてのネッティングされた値を計算するステップをさらに含む、請求項１８に記載の方法。
20. 前記要求の組は、
    有価証券を買うか、または売るための提案を含む第１の要求と、
    １つの通貨を別の通貨と交換するための提案を含む第２の要求とを含み、そして、
    前記配置するステップは、前記第１の要求と前記第２の要求とを同じ注文に割り当てるステップを含む、請求項１に記載の方法。
21. 前記第１の要求および前記第２の要求についてのネッティングされた値を計算するステップをさらに含む、請求項１６に記載の方法。
22. 前記取引のグループ内の取引を執行するための、気配値を生成するステップをさらに含む、請求項１に記載の方法。
23. 前記気配値を生成するためのステップは、気配値エンジンを使用して実行されることを特徴とする、請求項２２に記載の方法。
24. クォートの集まりを形成するために、前記バッチ内の各注文について少なくとも１つのクォートを自動的に生成するステップをさらに含む、請求項１に記載の方法。
25. 前記通信チャネルを介して、前記カスタマーに、前記クォートの集まりを提示するステップと、
    前記通信チャネルを介して、前記カスタマーから、前記クォートの集まりを受諾するための指示を受け取るステップとをさらに含む、請求項２４に記載の方法。
26. 前記注文を相手方に送るための要求を、前記カスタマーから受け取るステップをさらに含む、請求項１に記載の方法。
27. 前記相手方は、銀行を含む、請求項２２に記載の方法。
28. 前記相手方は、ブローカーを含む、請求項２６に記載の方法。
29. 前記カスタマーと前記相手方との間の以前の取引に関連付けられた詳細を、前記注文が含むという指示を、前記要求が含む、請求項２６に記載の方法。
30. 前記以前の取引についての追加の項目を、前記相手方から受け取るステップをさらに含む、請求項２９に記載の方法。
31. 前記追加の項目は、取引価格（ｔｒａｄｉｎｇ ｐｒｉｃｅ）を含む、請求項３０に記載の方法。
32. 前記追加の項目は、価格調整を含む、請求項３０に記載の方法。
33. 前記通信チャネルを介して、前記カスタマーに、前記バッチを伝送するステップをさらに含む、請求項１に記載の方法。
34. クォートを自動的に提供する前記ステップは、
    相手方との第２の通信チャネルを確立するステップと、
    前記第２の通信チャネルを介して、前記相手方に、前記注文を提示するステップと、
    前記第２の通信チャネルを介して、前記相手方から、前記クォートを受け取るステップとを含む、請求項１に記載の方法。
35. 前記第２の通信チャネルを介して、前記相手方に、前記受諾を伝送するステップと、
    前記受諾に応えて、前記相手方から、確認を受け取るステップと、
    前記通信チャネルを介して、前記カスタマーに、前記確認を送るステップとをさらに含む、請求項３４に記載の方法。
36. 前記第２の通信チャネルを介して、前記相手方に、前記取引のグループがブックされたことを示す通知を送るステップをさらに含む、請求項３５に記載の方法。
37. 前記注文についての優先される相手方を識別する指示を、前記カスタマーから受け取るステップをさらに含む、請求項１に記載の方法。
38. 前記優先される相手方に、前記注文を提示するステップをさらに含む、請求項３７に記載の方法。
39. 前記バッチ内の各注文についての優先される相手方を識別する指示を、前記カスタマーから受け取るステップをさらに含む、請求項２４に記載の方法。
40. 前記各注文についての優先される相手方に、前記バッチ内の各注文を提示するステップをさらに含む、請求項３９に記載の方法。
41. 前記通信チャネルは、インターネット接続を含む、請求項１に記載の方法。
42. 前記通信チャネルは、ワイドエリアネットワーク接続を含む、請求項１に記載の方法。
43. 前記通信チャネルは、ローカルエリアネットワーク接続を含む、請求項１に記載の方法。
44. 前記通信チャネルは、電話接続を含む、請求項１に記載の方法。
45. 前記要求のサブセットは、１つの通貨を別の通貨と交換するための提案を含む、請求項１に記載の方法。
46. 前記要求のサブセットは、金銭を貸す、または借りるための提案を含む、請求項１に記載の方法。
47. 前記要求のサブセットは、商品を買うか、または売るための提案を含む、請求項１に記載の方法。
48. 前記要求のサブセットは、有価証券を買うか、または売るための提案を含む、請求項１に記載の方法。
49. 資産を取引するための方法であって、前記方法は、
    カスタマーとの通信チャネルを確立するステップと、
    前記通信チャネルを介して、前記カスタマーから、要求の組を受け取るステップと、
    注文のバッチを形成するように、前記要求の組を配置するステップと（前記バッチ内の各注文は、前記要求の組の中の要求のサブセットを含む）、
    前記バッチ内の注文をブックするための要求を、前記カスタマーから受け取るステップと、
    前記要求に応えて、取引のグループの中の取引をブックするステップと（前記グループ内の各取引は、前記注文内の要求に対応する）、
    前記取引のグループについてのブックの詳細を、前記カスタマーに伝送するステップとを含む方法。
50. 前記ブックの詳細は、前記通信チャネルを介して、前記カスタマーに伝送されることを特徴とする、請求項４９に記載の方法。
51. 前記要求は、利用できる最良の価格で前記取引のグループを執行するための指示を含む、請求項４９に記載の方法。
52. 前記取引のグループを確認するステップをさらに含む、請求項４９に記載の方法。
53. 前記取引のグループを決算するステップをさらに含む、請求項４９に記載の方法。
54. 前記取引のグループがブックされたことを示す通知を、前記カスタマーに送るステップをさらに含む、請求項４９に記載の方法。
55. 前記カスタマーに、執行の詳細を送るステップをさらに含む、請求項５２に記載の方法。
56. 前記配置するステップは、プリファランスの組を使用して実行されることを特徴とする、請求項４９に記載の方法。
57. 前記プリファランスの組を修正するための指示を、前記カスタマーから受け取るステップをさらに含む、請求項５６に記載の方法。
58. 前記プリファランスの組は、
    注文についての最大値、および
    注文についての最小値、
    のうちの少なくとも１つを含む、請求項５６に記載の方法。
59. 前記要求は、相手方に前記注文を送るための指示を含む、請求項５８に記載の方法。
60. 前記相手方は、銀行を含む、請求項５９に記載の方法。
61. 前記相手方は、ブローカーを含む、請求項６０に記載の方法。
62. 前記カスタマーと前記相手方との間の以前の取引に関連付けられた詳細を、前記注文が含むという指示を、前記要求が含む、請求項４９に記載の方法。
63. 前記以前の取引についての追加の項目を、前記相手方から受け取るステップをさらに含む、請求項６２に記載の方法。
64. 前記追加の項目は、取引価格を含む、請求項６３に記載の方法。
65. 前記追加の項目は、価格調整を含む、請求項６３に記載の方法。
66. 前記通信チャネルは、インターネット接続を含む、請求項４９に記載の方法。
67. 前記通信チャネルは、ワイドエリアネットワーク接続を含む、請求項４９に記載の方法。
68. 前記通信チャネルは、ローカルエリアネットワーク接続を含む、請求項４９に記載の方法。
69. 前記通信チャネルは、電話接続を含む、請求項４５に記載の方法。
70. 前記要求の組の中の要求は、１つの通貨を別の通貨と交換するための提案を含む、請求項４９に記載の方法。
71. 前記要求の組の中の要求は、金銭を貸す、または借りるための提案を含む、請求項４９に記載の方法。
72. 前記要求の組の中の要求は、商品を買うか、または売るための提案を含む、請求項４９に記載の方法。
73. 前記要求の組の中の要求は、有価証券を買うか、または売るための提案を含む、請求項４９に記載の方法。
74. 資産を取引するための方法であって、前記方法は、
    通信チャネルを介して、カスタマーから、要求の組を受け取るステップと、
    注文のバッチを形成するように、前記要求の組を配置するステップと（前記バッチ内の各注文は、前記要求の組の中の要求のサブセットを含む）、
    取引のグループを自動的にブックするステップと（前記グループ内の各取引は、注文内の要求に対応する）を含む方法。
75. 前記取引のグループを確認するステップをさらに含む、請求項７４に記載の方法。
76. 前記取引のグループを決算するステップをさらに含む、請求項７４に記載の方法。
77. 前記通信チャネルを介して、前記カスタマーに、前記取引のグループがブックされたことを示す通知を送るステップをさらに含む、請求項７４に記載の方法。
78. 前記取引のグループに関連付けられた取引詳細を、取引データベース内に記憶するステップをさらに含む、請求項７４に記載の方法。
79. 前記配置するステップは、プリファランスの組を使用して実行されることを特徴とする、請求項７４に記載の方法。
80. 前記通信チャネルを介して、前記カスタマーから、前記プリファランスの組を修正するための指示を受け取るステップをさらに含む、請求項７９に記載の方法。
81. 前記プリファランスの組は、
    注文についての最大値、および
    注文についての最小値、
    のうちの少なくとも１つを含む、請求項７９に記載の方法。
82. 前記要求の組は、特定の通貨ペアを有する少なくとも２つの要求を含み、そして、
    前記配置するステップは、前記少なくとも２つの要求を、同じ注文に割り当てるステップを含む、請求項７４に記載の方法。
83. 前記少なくとも２つの要求についてのネッティングされた値を計算するステップをさらに含む、請求項８２に記載の方法。
84. 前記少なくとも２つの要求は、同じ取引通貨を有さないことを特徴とする、請求項８２に記載の方法。
85. 前記少なくとも２つの要求についてのネッティングされた値を計算するステップをさらに含む、請求項８４に記載の方法。
86. 前記要求の組は、特定のアカウントに関連付けられた少なくとも２つの要求を含み、そして、
    前記配置するステップは、前記少なくとも２つの要求を、同じ注文に割り当てるステップを含む、請求項７４に記載の方法。
87. 前記少なくとも２つの要求についてのネッティングされた値を計算するステップをさらに含む、請求項８６に記載の方法。
88. 前記要求の組は、特定の決済日を有する少なくとも２つの要求を含み、そして、
    前記配置するステップは、前記少なくとも２つの要求を、同じ注文に割り当てるステップを含む、請求項７４に記載の方法。
89. 前記少なくとも２つの要求についてのネッティングされた値を計算するステップをさらに含む、請求項８８に記載の方法。
90. 前記要求の組は、
    有価証券を買うか、または売るための提案を含む第１の要求と、
    １つの通貨を別の通貨と交換するための提案を含む第２の要求とを含み、そして、
    前記配置するステップは、前記第１の要求と前記第２の要求とを同じ注文に割り当てるステップを含む、請求項８５に記載の方法。
91. 前記第１の要求および前記第２の要求についてのネッティングされた値を計算するステップをさらに含む、請求項９０に記載の方法。
92. 資産を取引するためにコンピュータシステムと対話するための方法であって、前記方法は、
    前記コンピュータシステムとの通信チャネルを確立するためのコマンドを含む、注文管理システムを起動するステップと、
    前記注文管理システムを介して前記コンピュータシステムに要求の組を提供するステップと、
    前記コンピュータシステムに注文のバッチを生成させるために、前記注文管理システム内のコマンドを呼び出すステップと（前記バッチ内の各注文は、前記要求の組からの要求のサブセットを含む）、
    前記バッチ内の少なくとも１つの注文の中の各要求を実現するために、取引のグループを一括して執行するためのクォートを前記コンピュータシステムが提供するように、前記注文管理システムの中のコントロールを選択するステップと、
    前記クォートを受諾するための指示を、前記注文管理システムを介して発行するステップとを含む方法。
93. 前記取引のグループが執行されたことを示す通知を、前記通信チャネルを介して受け取るステップをさらに含む、請求項９２に記載の方法。
94. 前記取引のグループに関連付けられたプリファランスの組を提供するためのコマンドを、前記注文管理システム内で実行するステップをさらに含む、請求項９２に記載の方法。
95. 前記コンピュータシステムが相手方に前記注文を送るように構成された、別のコントロールを選択するステップをさらに含む、請求項９２に記載の方法。
96. 前記相手方は、銀行を含む、請求項９５に記載の方法。
97. 前記相手方は、ブローカーを含む、請求項９５に記載の方法。
98. 以前の取引に関連付けられた詳細を前記注文が含むことを示す信号を、前記コンピュータシステムが提供するように構成されたボタンを選択するステップをさらに含む、請求項９２に記載の方法。
99. 前記要求のサブセットは、１つの通貨を別の通貨と交換するための提案を含む、請求項９２に記載の方法。
100. 前記要求のサブセットは、金銭を貸す、または借りるための提案を含む、請求項９２に記載の方法。
101. 前記要求のサブセットは、商品を買うか、または売るための提案を含む、請求項９２に記載の方法。
102. 前記要求のサブセットは、有価証券を買うか、または売るための提案を含む、請求項９２に記載の方法。
103. 資産取引システムであって、前記システムは、
     カスタマーからの要求の組を受け取るための通信チャネルと、
     前記要求の組を注文のバッチ内に配置するように構成されたバッチマネージャと（前記バッチ内の各注文は、前記要求の組からの要求のサブセットを含む）、
     前記バッチ内の注文についてのクォートを提供するように構成された取引サーバと（前記クォートは、取引のグループを執行するための価格を含み、前記グループ内の各取引は、前記注文内の要求に対応する）、
     前記通信チャネルを介して、前記カスタマーに前記クォートを提示し、前記通信チャネルを介して、前記カスタマーから前記クォートの受諾を受け取るように構成された、ユーザインタフェースとを含み、
     前記取引サーバは、前記受諾に応えて、前記取引のグループをブックするように構成されることを特徴とするシステム。
104. 前記ユーザインタフェースは、さらに、前記クォートを提供する要求を、前記通信チャネルを介して、前記カスタマーから受け取るように構成されることを特徴とする、請求項１０３に記載のシステム。
105. 前記取引のグループを確認するように構成された、執行ステージ後プロセッサをさらに含む、請求項１０３に記載のシステム。
106. 前記取引のグループを決算するように構成された、執行ステージ後プロセッサをさらに含む、請求項１０３に記載のシステム。
107. 前記ユーザインタフェースは、さらに、前記取引のグループがブックされたことを示す通知を、前記通信チャネルを介して、前記カスタマーに送るように構成されることを特徴とする、請求項１０３に記載のシステム。
108. 前記バッチマネージャは、前記要求の組を、プリファランスの組に従って配置するように構成されることを特徴とする、請求項１０３に記載のシステム。
109. 前記ユーザインタフェースは、さらに、前記プリファランスの組を修正するための指示を、前記通信チャネルを介して、前記カスタマーから受け取るように構成されることを特徴とする、請求項１０８に記載のシステム。
110. 前記プリファランスの組は、
     注文についての最大値、および
     注文についての最小値、
     のうちの少なくとも１つを含む、請求項１０８に記載のシステム。
111. 前記プリファランスの組を記憶するように構成された、管理サーバをさらに含む、請求項１０８に記載のシステム。
112. 前記要求の組は、特定の通貨ペアを有する少なくとも２つの要求を含み、そして、
     前記バッチマネージャは、さらに、前記少なくとも２つの要求を、同じ注文に割り当てるように構成されることを特徴とする、請求項１０３に記載のシステム。
113. 前記バッチマネージャは、さらに、前記少なくとも２つの要求についてのネッティングされた値を計算するように構成されることを特徴とする、請求項１１２に記載のシステム。
114. 前記少なくとも２つの要求は、同じ取引通貨を有さないことを特徴とする、請求項１１２に記載のシステム。
115. 前記バッチマネージャは、さらに、前記少なくとも２つの要求についてのネッティングされた値を計算するように構成されることを特徴とする、請求項１１４に記載のシステム。
116. 前記要求の組は、特定のアカウントに関連付けられた少なくとも２つの要求を含み、そして、
     前記バッチマネージャは、さらに、前記少なくとも２つの要求を、同じ注文に割り当てるように構成されることを特徴とする、請求項１０３に記載のシステム。
117. 前記バッチマネージャは、さらに、前記少なくとも２つの要求についてのネッティングされた値を計算するように構成されることを特徴とする、請求項１１６に記載のシステム。
118. 前記要求の組は、特定の決済日を有する少なくとも２つの要求を含み、そして、
     前記バッチマネージャは、さらに、前記少なくとも２つの要求を、同じ注文に割り当てるように構成されることを特徴とする、請求項１０３に記載のシステム。
119. 前記バッチマネージャは、さらに、前記少なくとも２つの要求についてのネッティングされた値を計算するように構成されることを特徴とする、請求項１１８に記載のシステム。
120. 前記要求の組は、
     有価証券を買うか、または売るための提案を含む第１の要求と、
     １つの通貨を別の通貨と交換するための提案を含む第２の要求とを含み、そして、
     前記バッチマネージャは、さらに、前記第１の要求と前記第２の要求とを、同じ注文に割り当てるように構成されることを特徴とする、請求項１０３に記載のシステム。
121. 前記バッチマネージャは、さらに、前記第１の要求および前記第２の要求についてのネッティングされた値を計算するように構成されることを特徴とする、請求項１２０に記載のシステム。
122. 前記取引のグループを執行するための気配値を生成するように構成された、気配値エンジンをさらに含む、請求項１０３に記載のシステム。
123. 前記気配値エンジンは、前記バッチマネージャに通信接続されていることを特徴とする、請求項１２２に記載のシステム。
124. 前記バッチマネージャは、さらに、前記バッチ内の各注文について少なくとも１つのクォートを生成することにより、クォートの集まりを形成するように構成されることを特徴とする、請求項１０３に記載のシステム。
125. 前記ユーザインタフェースは、さらに、
     前記通信チャネルを介して、前記カスタマーに、前記クォートの集まりを提示するように構成され、そして、
     前記通信チャネルを介して、前記カスタマーから、前記クォートの集まりを受諾するための指示を受け取るように構成されることを特徴とする、請求項１２４に記載のシステム。
126. 前記ユーザインタフェースは、さらに、前記注文を相手方に送るための要求を、前記カスタマーから受け取るように構成されることを特徴とする、請求項１０３に記載のシステム。
127. 前記相手方は、銀行を含む、請求項１２６に記載のシステム。
128. 前記相手方は、ブローカーを含む、請求項１２６に記載のシステム。
129. 前記カスタマーと前記相手方との間の以前の取引に関連付けられた詳細を前記注文が含むという指示を、前記要求が含む、請求項１２６に記載のシステム。
130. 前記取引サーバは、さらに、前記以前の取引についての追加の項目を、前記相手方から受け取るように構成されることを特徴とする、請求項１２９に記載のシステム。
131. 前記追加の項目は、取引価格を含む、請求項１３０に記載のシステム。
132. 前記追加の項目は、価格調整を含む、請求項１３０に記載のシステム。
133. 前記ユーザインタフェースは、さらに、前記バッチを、前記通信チャネルを介して、前記カスタマーに表示するように構成されることを特徴とする、請求項１０３に記載のシステム。
134. 前記取引サーバに接続され、前記取引サーバから相手方に前記注文を伝えるように構成された、第２の通信チャネルをさらに含む、請求項１０３に記載のシステム。
135. 前記第２の通信チャネルは、さらに、前記相手方から前記取引サーバに、前記クォートを伝えるように構成されることを特徴とする、請求項１３４に記載のシステム。
136. 前記第２の通信チャネルは、さらに、前記取引サーバから前記相手方に、前記受諾を伝えるように構成されることを特徴とする、請求項１３４に記載のシステム。
137. 前記第２の通信チャネルは、さらに、前記相手方から前記取引サーバに、前記受諾に応えた確認を伝えるように構成されることを特徴とする、請求項１２５に記載のシステム。
138. 前記取引サーバは、さらに、前記第２の通信チャネルを介して、前記相手方に、前記取引のグループがブックされたことを示す通知を送るように構成されることを特徴とする、請求項１３６に記載のシステム。
139. 前記ユーザインタフェースは、さらに、前記注文についての優先される相手方を識別する指示を、前記カスタマーから受け取るように構成されることを特徴とする、請求項１０３に記載のシステム。
140. 前記取引サーバは、さらに、前記優先される相手方に、前記注文を伝送するように構成されることを特徴とする、請求項１３９に記載のシステム。
141. 前記ユーザインタフェースは、さらに、前記集まりの中の各注文についての優先される相手方を識別する指示を、前記カスタマーから受け取るように構成されることを特徴とする、請求項１２４に記載のシステム。
142. 前記取引サーバは、さらに、前記集まりの中の各注文を、前記各注文についての優先される相手方に伝送するように構成されることを特徴とする、請求項１４１に記載のシステム。
143. 前記通信チャネルは、インターネット接続を含む、請求項１０３に記載のシステム。
144. 前記第２の通信チャネルは、インターネット接続を含む、請求項１３４に記載のシステム。
145. 前記通信チャネルは、ワイドエリアネットワーク接続を含む、請求項１０３に記載のシステム。
146. 前記第２の通信チャネルは、ワイドエリアネットワーク接続を含む、請求項１３４に記載のシステム。
147. 前記通信チャネルは、ローカルエリアネットワーク接続を含む、請求項１０３に記載のシステム。
148. 前記第２の通信チャネルは、ローカルエリアネットワーク接続を含む、請求項１３４に記載のシステム。
149. 前記通信チャネルは、電話接続を含む、請求項１０３に記載のシステム。
150. 前記第２の通信チャネルは、電話接続を含む、請求項１３４に記載のシステム。
151. 前記要求のサブセットは、１つの通貨を別の通貨と交換するための提案を含む、請求項１０３に記載のシステム。
152. 前記要求のサブセットは、金銭を貸す、または借りるための提案を含む、請求項１０３に記載のシステム。
153. 前記要求のサブセットは、商品を買うか、または売るための提案を含む、請求項１０３に記載のシステム。
154. 前記要求のサブセットは、有価証券を買うか、または売るための提案を含む、請求項１０３に記載のシステム。
155. 前記取引のグループに関連付けられた取引詳細を記憶するように構成された、取引データベースをさらに含む、請求項１０３に記載のシステム。
156. 前記カスタマーについての、前記プリファランスの組を記憶するように構成された、管理サーバをさらに含む、請求項１０９に記載のシステム。
157. 前記管理サーバは、さらに、前記カスタマーに関連付けられた取引規則の組を記憶するように構成されることを特徴とする、請求項１５６に記載のシステム。
158. 前記ユーザインタフェースサーバの制御下で、前記カスタマーから直接入力を受け取るように構成された、注文管理システムをさらに含む、請求項１０３に記載のシステム。
159. 前記カスタマー取引管理システムは、ストレートスルー処理アダプタを含む、請求項１５８に記載のシステム。
160. 前記取引サーバの制御下で、前記相手方から直接入力を受け取るように構成された、相手方取引管理システムをさらに含む、請求項１０３に記載のシステム。
161. 前記相手方取引管理システムは、前記要求の組の中の各要求についての実際の価格を生成するように構成された、価格エンジンを含む、請求項１６０に記載のシステム。
162. 前記ユーザインタフェースへの許可されていないアクセスを防止するように構成された、セキュリティサーバをさらに含む、請求項１０３に記載のシステム。
163. 前記セキュリティサーバは、前記カスタマーに関連付けられたセキュリティ関連データを含む、セキュリティデータベースに接続されることを特徴とする、請求項１６２に記載のシステム。
164. 前記取引サーバへの許可されていないアクセスを防止するように構成された、セキュリティサーバをさらに含む、請求項１０３に記載のシステム。
165. 前記セキュリティサーバは、相手方に関連付けられたセキュリティ関連データを含む、セキュリティデータベースに接続されることを特徴とする、請求項１６４に記載のシステム。
166. コンピュータシステム上で資産を取引するためのユーザインタフェースであって、前記ユーザインタフェースは、注文管理システムを介して呼び出し可能であり、前記ユーザインタフェースは、
     カスタマーからの要求の組を含む入力を受け取るように構成された、第１の表示画面と、
     前記入力に応じて、
     注文のバッチと（前記バッチ内の各注文は、前記要求の組からの要求のサブセットを含む）、
     前記バッチ内の各注文についてのクォートと（各クォートは、取引のグループを執行するための価格を含み、前記グループ内の各取引は、前記要求のサブセットの中の要求に対応する）、
     前記コンピュータシステムに、前記取引のグループの一括した執行を行わせるように構成された、ユーザが作動可能なコントロールと、
     を表示するように構成された、第２の表示画面とを含む、ユーザインタフェース。
167. 前記バッチ内の注文は、特定の通貨ペアを有する前記要求の組の中のすべての要求を含む、請求項１６６に記載のユーザインタフェース。
168. 前記バッチ内の注文は、特定のアカウントに関連付けられた前記要求の組の中のすべての要求を含む、請求項１６６に記載のユーザインタフェース。
169. 前記バッチ内の注文は、特定の決済日を有する前記要求の組の中のすべての要求を含む、請求項１６６に記載のユーザインタフェース。
170. 資産を取引するためのシステムであって、前記システムは、
     カスタマーからの要求の組を受け取るための手段と、
     注文のバッチを形成するように、前記要求の組を配置するための手段と（前記バッチ内の各注文は、前記要求の組の中の要求のサブセットを含む）、
     前記バッチ内の注文についてのクォートを提供するための手段と（前記クォートは、取引のグループを一括して執行するための価格を含み、前記グループ内の各取引は、前記注文内の要求に対応する）、
     前記取引のグループをブックするための手段と、を含むシステム。
171. 前記取引のグループを執行するための手段をさらに含む、請求項１７０に記載のシステム。
172. 前記取引のグループがブックされたことを示す通知を、前記カスタマーに送るための手段をさらに含む、請求項１７０に記載のシステム。
173. 前記取引のグループに関連付けられた取引詳細を、データベース内に記憶するための手段をさらに含む、請求項１７０に記載のシステム。
174. 前記配置する手段は、プリファランスの組に従って動作することを特徴とする、請求項１７０に記載のシステム。
175. 前記プリファランスの組を修正するための指示を、前記受け取るための手段を介して、前記カスタマーから受け取るための手段をさらに含む、請求項１７４に記載のシステム。
176. 前記注文のバッチを再配置するための指示を、前記受け取るための手段を介して、前記カスタマーから受け取るための手段をさらに含む、請求項１７４に記載のシステム。