JP2003533793A - デリバティブ取引を電子的に実行するシステムとその方法 - Google Patents

Abstract

(57)【要約】 本発明は、取引契約条件の効率的な交渉および金融商品の取引における電子取引チケットの作成を容易にするものである。好ましくは、交渉プロセスは、ポイント・ツー・ポイントのメッセージ送信を使用する安全なオンライン・チャット・プログラムを介して行われる。ただし、電子取引システムの領域外の電話およびファックスを使用する交渉も可能である。取引契約条件が両方の当事者で同意されると、その当事者は本発明による電子取引システムに入り、取引される金融商品を選定して、取引システムおよび／または取引当事者の各々が保管できる電子取引チケットを作成する。

Description

【発明の詳細な説明】

【０００１】 ［関連出願の相互参照］ 本出願は、２００１年５月１６日に出願の同時係属の米国仮出願第６０／２０
４，７１７号の発明の名称「Ｄｉｒｅｃｔ−Ｔａｌｋ Ｓｙｓｔｅｍｓ ａｎｄ
Ｍｅｔｈｏｄｓ ｆｏｒ Ｃｏｎｄｕｃｔｉｎｇ Ｄｅｒｉｖａｔｉｖｅ Ｔ
ｒａｄｅｓ Ｅｌｅｃｔｒｏｎｉｃａｌｌｙ」（「デリバティブ取引の電子的管
理の直接会話システムとその方法」）、および米国非仮出願Ｎｏ．＿＿＿＿＿＿
の発明の名称「Ｓｙｓｔｅｍｓ ａｎｄ Ｍｅｔｈｏｄｓ ｆｏｒ Ｃｏｎｄｕ
ｃｔｉｎｇ Ｄｅｒｉｖａｔｉｖｅ Ｔｒａｄｅｓ Ｅｌｅｃｔｒｏｎｉｃａｌ
ｌｙ」（「デリバティブ取引の電子的管理システムとその方法」）の利益を主張
する。両出願の全文は、引用することにより本出願の一部をなすものとする。

【０００２】 ［発明の分野］ 本発明は一般に金融商品の取引に関し、詳細には、デリバティブの電子取引に
関する。

【０００３】 ［発明の背景］ 近年、商品取引はますます電子取引システムに依存するようになってきている
。取引を行う旧来の手作業による方法は、広く旧来の手作業による方法を模して
いる最新のコンピュータ・システムに取って代わられている。これらの比較的新
しい電子取引システムは、手作業によるシステムに勝る多くの利点がある。それ
ら利点には、優れた精度、人件費の削減、リアルタイムの市場情報、効率的な長
距離通信、自動記録保管といった機能を提供する能力を含む。しかし、これらの
商品が売買されている市場は、商品の内容から取引方法まで非常に大きく異なっ
ているため、電子取引システムは一般的には先物商品、現金、石油、株、セキュ
リティなどに限定されており、さらに時として単一市場内の特定の商品に限定さ
れている。

【０００４】 外貨の匿名の取引のために設計された自動取引システムの一例は、米国特許第
５，０７７，６６５号および第５，１３６，５０１号に記載されており、両方と
も、Ｓｉｌｖｅｒｍａｎらに発行され、ロンドンのＲｅｕｔｅｒｓ Ｌｉｍｉｔ
ｅｄに譲渡されている。Ｓｉｌｖｅｒｍａｎらのシステムにおいては、１台の中
央のホスト・コンピュータが、システム全体を通して存在する取引に有効な取引
商品、信用情報、多様な付値および売値で構成される中央データベースを維持し
ている。次に、ホスト・コンピュータはこの情報を使用して、見込みのあるマッ
チング売買、価格、および有効数量に対する契約相手間の全体の契約相手の信用
限度を含むマッチング条件を基にして、実際の買いと売りとを対応させる。その
ために、各クライアント側が、予想される契約相手それぞれに対して信用限度を
設定し、その後変更または再設定することがある。信用限度は、ホスト・コンピ
ュータによって使用され、予想される当事者の各ペアに対する契約相手の全体の
信用限度を確立する。前記信用限度は、第一当事者から第二当事者におよび第二
当事者から第一当事者に存続している信用の最少額（すなわち、すでに実行され
ている該当するあらゆる売買よりも少ない当初の信用限度）に等しい。ホスト・
コンピュータは、売買が該当する全体の信用限度を超える関連した値を有する場
合、所定のペアの任意の見込みのある契約相手の間で、他の資格のあるマッチン
グ売買の完了を阻止する。Ｓｉｌｖｅｒｍａｎらのシステムでは、さまざまなク
ライアント側のコンピュータ（キーステーションとも呼ばれる）が、所定の数の
最高付値および売値のような、ホスト・コンピュータで有効な情報の制限された
サブセットを単に維持して表示し、実行のためにホスト・コンピュータに信用そ
の他の売買に見合った情報を通信する。しかし、当事者の匿名性を保護しようと
して、クライアント側は、売買が完了するまで、予想される契約相手により設定
された信用限度、または特定の売買に対するその他の当事者の本人確認にさえア
クセスしない場合がある。

【０００５】 したがって、Ｓｉｌｖｅｒｍａｎらのシステムにおいて、契約相手の秘密の信
用限度データは、明らかに、中央のホスト・コンピュータにより取引マッチング
・プロセスの一部として維持され、利用されている。結果として、各クライアン
ト側には、ひとつまたは複数の匿名の契約相手から表示された価格で売買を確約
する前に、現在表示されている付値および売値のどれに対応する資格が実際にあ
るかどうかを決定する能力がない。さらに、信用限度は、単に一方の当事者がも
う一方の当事者と共に参加する取引の量のキャップ値（または信用限度）のよう
に見える。このシステムを用いて取引される金融商品と関連する金融契約は基礎
契約の成立時に終了するため、信用限度が、他の当事者が代表する信用リスクと
は無関係ということはほとんどない。したがって、キャップ値はこの特定の状況
においては十分である。中央のホスト・コンピュータは、契約相手間で一致が見
られ、契約相手が取引を実行するのに互いに十分な信用があるかどうかの確認が
終了するまで、信用情報を利用しない。

【０００６】 結果として、トレーダーがトレーダーの画面に現在表示されている最高価格で
取引を行おうと試みない限り、匿名マッチング・システムの１つを使用するトレ
ーダーは、トレーダーの画面に現在表示されている最高価格を提示する（すなわ
ち入札）匿名の契約相手に信用があるか、およびその相手に信用を供与する用意
があるどうかを認知できない。したがって、トレーダーは、表示価格で売買を行
う試みが、そのような信用の不足のためにシステムによりその後無効にされるか
どうかを認知できない。Ｓｉｌｖｅｒｍａｎらのシステムは当事者間の対話を提
供できず、まして、他の方法では実現し得ないほどに取引の実行を促進するもの
である匿名の対話を提供することはできない。

【０００７】 Ｒｅｕｔｅｒｓ ＬｉｍｉｔｅｄはＳｉｌｖｅｒｍａｎらに記載されているシ
ステムを拡張して、デリバティブ商品である先物外国為替契約を包含するように
した。しかし、対面決済に先立ち信用分析を可能にする決済リスク・システムを
提供するのとは対照的に、Ｒｅｕｔｅｒｓ Ｌｉｍｉｔｅｄのシステムは、決済
リスクでなく信用リスクを基にした取引を行うゆるやかなマッチングの概念を導
入している。したがって、取引は、両当事者がその後の信用確認を得るまで確定
されない。どちらの当事者も、取引相手を知ると、契約相手に有効な信用がない
ように装って売買を解消できる。したがって、Ｒｅｕｔｅｒｓ Ｌｉｍｉｔｅｄ
のシステムは電子取引システムを介したデリバティブ取引には不評なソリューシ
ョンであると言われている。

【０００８】 別の自動取引システムはＴｏｇｈｅｒらに発行され、Ｆｏｒｅｉｇｎ Ｅｘｃ
ｈａｎｇｅ Ｔｒａｎｓａｃｔｉｏｎ Ｓｅｒｖｉｃｅｓ Ｉｎｃ．に譲渡され
た、米国特許第５，３７５，０５５号に開示されている。Ｔｏｇｈｅｒらのシス
テムは、各クライアント側が現在取引する資格のあるこれらの契約相手から最高
付値および売値を識別し、その一方で見込みのある契約相手の匿名性および匿名
の見込みのある契約相手により課されたあらゆる信用限度の機密性を維持する、
匿名取引システムである。このシステムは明らかに、各種のローカル・コンピュ
ー・センターに接続された専用のデスクトップ端末を備えた、クローズド・シス
テムとして実行するように設計され、その結果前記ターミナルは地域コンピュー
タに接続される。

【０００９】 Ｔｏｇｈｅｒらのシステムでは、各クライアント側は画面により１回につき１
つの外貨を表示できるだけである。Ｔｏｇｈｅｒらのシステムはさらに、システ
ムに各クライアント側が見込みのある契約相手それぞれに対して限定された信用
情報（例えば、あらかじめ決められた制限がすでに超過しているかどうかを表示
する１ビット・フラグ）だけを提供できるという事実により制限されており、ま
た、特定のタイプの金融商品の各付値または売値は、限定された信用情報との整
合性のためシステムにより事前スクリーニングされ、その後に匿名の取引可能な
値を計算して、その特定の金融商品を扱うトレーダーに提示するという事実によ
り制限されている。Ｔｏｇｈｅｒらのシステムにおける事前スクリーニングは、
２つの契約相手間で見込みのある売買に対してすべての信用が存続しているかど
うか確認するための簡単な検査であり、したがって簡単なハイ／イイエを事前認
定するマトリックスを使用して実行する。

【００１０】 事前認定マトリックスは、分散処理通信ネットワークのいくつかの地域ノード
（分散ノードとも呼ばれる）の各々で維持できる、この各々の地域ノードは通信
ネットワークの対応する個別のリンクにより、地域ノードが個別調整された取扱
い可能な付値および売値の価格と全体最高価格を含む市場情報を配布するのに対
応できる、それぞれのクライアント側に接続されている。

【００１１】 特定のクライアント側が、予測される各契約相手にどの程度の信用を拡張する
意志があるかを示す敏感な信用限度データは、好ましくはその特定のクライアン
トに関連するアクセス・ノードにおいて維持され、その特定のクライアント側に
関連するエンティティ（例えば、トレーダー、取引所、または銀行など）が、特
定の契約相手と売買する意思があるかどうかという簡単なハイ／イイエの表示は
、通信ネットワークの他のノードに転送される。

【００１２】 さらに、関連する地域ノードの各コンピュータ（すなわち、特定のクライアン
ト側に最も近く、および／または特定の契約相手に最も近い地域ノード）が、受
信し処理するデータを限定するには、単に、特定のクライアント側と特定の契約
相手間の信用状態における変更（すなわち、その信用が有効でないか、または信
用が現在有効である）を、分散されたノードに転送できるだけであり、他の分散
されたノードに関連する２つのクライアント側間で売買に関連する信用状態のあ
らゆる情報はすべて無視される場合がある。

【００１３】 Ｔｏｇｈｅｒらのシステムにおいて、２つの適用可能な信用限度のどちらかが
特定のペアの契約相手の間でまだ超過していない場合、システムが売買可能な取
引として全体の付値または売値を表示するが、その後の取引の実行／確認処理に
おいて、明らかに各クライアント側が結果として生じるすべての「買い」または
「売り」の売買のあらゆる制限を超える部分を阻止できる。しかし、これはＴｏ
ｇｈｅｒらのシステムのユーザーに対して、複数のステップに費やす余分な時間
を加える。代替方法では、当事者によりまたは当事者に対して下限が設定されて
いる当事者の任意の選択によって、全体の売買を阻止できる可能性がある。第２
の代替方法として、事前認定マトリックスは、特定の見込みのある契約相手から
あらゆる信用がすでに使い果たされているかどうかについての単なる表示に加え
て、またはその代わりに、所定の基準となる取引金額を実行するために十分な信
用が存続しているかどうかを表示できる。Ｔｏｇｈｅｒらのシステムのそのよう
な代替の実施形態では、各トレーダーに２つの取引可能な価格、１つは少なくと
も所定の基準となる額が利用可能であるか価格、２つめは小額のみ利用可能な価
格、を表示することも可能である。したがって、契約相手の信用の質の違いによ
りユーザーが選択する場合、個別の注文は単独で取り扱われず、ユーザーは付値
および売値を調査し、最低価格で取引する能力を持つことができない。

【００１４】 Ｔｏｇｈｅｒらのシステムの別の態様によれば、その他のあらゆる取引所にお
いて最高値で取引可能なまたは標準値で取引可能な取引価格として表示できる、
オープンな取引価格を有する少なくとも最初のトレーダーは、付値（売値）見積
りが、相互の信用が存在する少なくとも１人の見込みのある契約相手に有効な最
高価格であることを自動的に通知され、したがって、随時ヒット（ｈｉｔ：相手
側から指定されること）される可能性がある。同様に、少なくとも価格見積者の
付値（売値）の見積が、少なくとも１つの取引所で現在最高価格ではないが、ト
レーダーによりその取引所でこのようにすぐにヒットを与えられる場合、好まし
くは、見積者は、その見積が別の取引所からそのような最高の取引可能なまたは
標準取引可能な価格に加えられている（すなわち、価格において等しく、時間に
おいて後である）のかどうかを通知される。言い換えると、Ｔｏｇｈｅｒらのシ
ステムでは、自動マッチングのプロセスは活動中のトレーダーが取引する最高値
以外の価格を選択することができない。これにより、トレーダーが信用の理由か
ら別の契約相手の方を望む場合でも、トレーダーはシステムが提供するものを強
制的に受け取ることになる。さらに、Ｔｏｇｈｅｒらのシステムは、市場の全体
的な詳細をトレーダーに示さず、取引が可能である価格のみ示す。したがって、
トレーダーに市場の全体像を提供することができない。また、トレーダーは指定
された量に制限される。取引の量またはその他の取引契約条件の変更または交渉
に対しては、何も提供されない。

【００１５】 前述のシステムは、一日だけの決済リスクに焦点を当てているようなものであ
る。これらシステムは、明らかに、各種の個々に異なる金融商品の同時発生の実
際の信用要求、または契約相手のこれらの要求に合わせる長期的な能力を扱うこ
とができない。結果として、これらのシステムは一般に、売買の決済が数日中に
発生する市場で採用されるだけであり、契約相手間の連続して継続する信用要求
または責任は存在しない。特に、これらの制限の結果として、これらの設計は金
利スワップ、キャップ、その他の多くの金融商品といった金融商品の匿名取引を
支援することができない場合がある。これらの設計はこれらのより複雑な金融商
品に対応することができない、なぜなら、とりわけ、これらのシステムは、明ら
かに全ての金融商品を一様に扱っている、その結果、対立する契約相手の財務の
健全性についての確認を要求するより複雑な金融商品を扱うことができない可能
性がある。デリバティブのようないくつかの金融商品を用いて行われる取引では
、複数年の財務契約を作成し、したがって、単なる信用限度または信用キャップ
・システムでは、会社の信用リスクを評価し、管理するには不十分である。

【００１６】 したがって、公知のシステムは、例えば金利スワップ、キャップ、取引所、先
物相場契約（ＦＲＡ）、金利ベーシス・スワップ、金利取引、外国為替、スイッ
チ、またはカウンター・デリバティブ商品に関するその他などのデリバティブ商
品を用いて操作するように設計されていない。多くの人は、デリバティブ取引は
電子取引システムで効率よく取扱うには複雑すぎると考えている。特にデリバテ
ィブ商品は一般に、特定の事項と条件で定義され、別のタイプのデリバティブ商
品は、別々の事項と条件の組み合わせで定義される。例えば、ＦＲＡは一般に、
開始時間、終了時間、期間、変動金利オプションで定義され、一方、金利スワッ
プは一般に、開始時間、終了時間、期間、変動金利オプション、固定クーポンの
頻度、特定通貨に適用できる基本および特殊ルールにより定義される。したがっ
て、異なるデリバティブ商品を適正に定義するのに必要な特定情報の多様性が、
明らかに電子的デリバティブ取引システムの発展を妨げている。

【００１７】 従来技術のシステムのさらに別の欠点は、１つのポジション（すなわち、信用
リスクポジション）を自動的に決定する能力がなく、かつ売買を開始するために
相殺ポジションを持つ、見込みのある契約相手を識別する能力を持たない。この
情報をリアルタイムに提供できる電子取引システムはまだ知られていない。これ
は、日々、信用リスクおよび市場・リスクを管理できる金融大企業に基礎を置い
ているデリバティブ市場の本質を言い当てている。

【００１８】 本出願および発明の譲受人は、デリバティブに対して動作中の第１および現在
の唯一の電子取引システムと確信するものを開発し、採用してきた。このシステ
ムは、上に少し述べた、技術的な多くの欠点を克服している。このシステムはＢ
ｌａｃｋｂｉｒｄ(商標）と呼ばれ（ｗｗｗ．ｂｌａｃｋｂｉｒｄ．ｎｅｔ）、
広く受け入れている。それにもかかわらず、多くのデリバティブ取引に対する全
電子化取引システムへの移行は徐々であり、時間を要すると思われ、多くのデリ
バティブトレーダーが退去して、非効率的な手動取引手順を扱っている。

【００１９】 例えば、金融市場および店頭（ＯＴＣ）デリバティブ市場は、長年に渡り、主
として電話およびファックスでアクセスされていた。この環境では、売買が完了
すると、両方の当事者は、別の会社を参照せずに別個に彼ら自身の内部「取引チ
ケット」を振り出す。その後、このチケットは手動でそれぞれの当事者のコンピ
ュータ・システムに入力されて処理される。この手動プロセスはエラー発生の機
会が多く、両方の当事者が同意する売買の詳細が同一であることを確認し、保証
するには、複数の階層の手動制御を必要とする。これは特に、デリバティブを定
義するのに必要なパラメータが多数になる理由から、ＯＴＣデリバティブに顕著
である。

【００２０】 したがって、産業界には、従来から未解決の、端末相互の電子取引を必要とせ
ずに、手動取引手順の欠点を克服する方法およびシステムの必要性が存在する。

【００２１】 ［発明の要約］ 本発明は、本明細書に記載するように、取引契約条件の効率的な交渉および電
子取引チケットの作成の促進を実現する方法とシステムを備える。好ましくは、
交渉プロセスは、ポイント・ツー・ポイントのメッセージ送信を使用する安全な
オンライン・チャット・プログラムを介して行われる。ただし、電子取引システ
ムの領域外の電話およびファックスを使用する交渉も可能である。取引契約条件
が両方の当事者で同意されると、その当事者は本発明による電子取引システムに
入り、取引される金融商品を選択して、取引システムおよび／または取引当事者
の各々が保管できる電子取引チケットを作成する。商品を選択するとき、記号発
音機能により、トレーダーが即座に、容易に取引される特定商品を識別できる。
デリバティブのような複雑な商品では、この容易な識別が望ましいのは、デリバ
ティブのすべての契約条件を定義するのに必要な手間が多いからである。有利に
は、例えば画面のＨＴＭＬ、ペーパー／ファックス、ＸＭＬまたは特別注文のフ
ォーマットなどの、複数の異なる様式で電子取引チケットを作成することができ
る。実際、電子取引チケットのフォーマットは、特定のトレーダーまたは複数の
トレーダーにより指定される特定フォーマットまたは複数フォーマットに基づい
て決定でき、それにより、トレーダーは特定フォーマットに変換した電子取引チ
ケットを直接処理できる。

【００２２】 本発明のその他の特徴および利点は、以下の図面および詳細な説明の例示によ
って、当業者には明らになるであろう。このような特徴および利点のすべては、
本明細書では、本発明の範囲に含まれるものとする。

【００２３】 本発明のファイルはカラーにされた少なくとも１つの図面を含む。カラー図面
を持つ本発明のコピーは、必要な料金を支払って要求すれば、米国特許商標庁か
ら提供されるであろう。

【００２４】 ［好ましい実施形態の詳細な説明］ 次に本発明を、好ましい実施形態を示す添付図面に関連させて以後に詳細に述
べる。しかし、本発明は多くの異なる方式で実現できるものであり、ここで述べ
る実施形態に限定されると解釈すべきでなく、むしろこれら実施形態は、本開示
を完全に説明し、かつ当業者に発明の範囲を完全に伝達するように提供されてい
るものである。同一符号は図面全体を通して同一要素を示す。

【００２５】 １．はじめに 以下の説明は、本発明を実行する最高に考慮されたモードである。本発明のシ
ステム、方法、およびコンピュータ・プログラム・プロダクトは、信用に敏感な
、双方間金融商品の広範な断面を匿名で取引する実際の用途を有する。しかし、
以後に述べる本発明の特定の用途は、本発明を使用してデリバティブ市場の金融
商品を取引することに向けられる。本発明の範囲は、以後に述べる範囲に限定さ
れるものではなく、添付特許請求の範囲によって決定されるべきものである。

【００２６】 本発明は、標準化された契約定義と、取引を実行する前に、各契約相手の複雑
な信用プリファレンスをマッチングする手段とを提供する。したがって、見込み
のある契約相手ユーザーは、取引開始前に、提供される信用プリファレンス情報
に基づいて取引するのに適する付値および売値を識別できる。本発明ではまた、
ユーザーが受動オーダー（登録ユーザーがさらに何かを実行することなく、他の
契約相手がヒット（付値）またはリフト（売値）から実際に選択する各種金融商
品の付値および売値）、または能動オーダー（画面を見ているユーザーが、シス
テムにすでに存在する受動付値または売値を選択して取引を実際に開始する）を
発行できる。これにより、ユーザーはオーダー・フロー手順の最大制御が可能に
なる。例えば、特定市場の付値が売値より高いが、取引が実行されない状態が発
生することがある。この状態は、最高売値（この場合、付値より低い）の信用品
質が、入札者がその契約相手との売買に入ることを意思決定するには十分でない
ときに発生する。これは、価格が等しい場合にオーダーが自動的にマッチングす
る従来システムとは大きく異なる。なぜならそのような従来システムは一般に、
オーダー・フローのユーザー制御を制限しているからである。

【００２７】 本発明はまた、金融市場に電子取引システムと方法とを提供し、それにより、
見込みのある契約相手を識別し、先物相場契約（ＦＲＡ）スイッチおよび別の記
入商品の取引を実行できる。本発明はさらに、ユーザーが、一人対複数または複
数対複数が可能なオークション・プロセスを介して各種金融商品へのオーダーを
発行し、それによりシステムが自動的に全オーダーにマッチングして、いくつか
のガイドラインおよびパラメータに基づいて実行される価格および数量を決定す
る能力を備える。本発明の別の形態は、ユーザーが利用できるオークション取引
であり、それにより、ユーザーはオークション・プロセスを使用して、別の契約
相手とＦＲＡスイッチを取引できる。この方式のオークションは、以後、スイッ
チ・オークションと呼ぶ。オークションでは、好ましくは、オークションを実行
する前に、価格を予め決定する。システムにより決定された価格は、以後、公正
価格と呼ぶ。

【００２８】 本発明のシステムおよび方法の設計は、金融会社が多くの異なる組織の下で運
営されている実態を反映して設計されている。これを達成するために、以下の概
念／定義が提供される。 法的主体（ＬＥ）： これは、システムのユーザー（トレーダー）により、契約が交渉される代表と
しての法人組織主体である。 ビジネス・ユニット（ＢＵ）： これは、共同して活動し、ＬＥ、マネージャ、アドレス、支払情報、信用プロ
ファレンス（下記参照）等のような属性を共有する法的主体内の個々のユーザー
のグループである。 リスク評価（ＲＱ）： これは、異なる属性を持つ契約を信用リスク目的の同一基準で比較できる、金
融契約に関連するリスクの特有の評価基準である。 信用プリファレンス（ＣＰ）： これは、システムが、異なる会社および異なる金融契約（すべて、異なる内部
組織を持つ）で使用される、同一リスクの異なる評価基準を扱えるモデルである
。 金融商品のクラス（ＣＬ）： これらは、同様の属性を共有する金融契約の集合である。 信用グループ（ＣＧ）： 記入契約のクラス全体に信用プリファレンスを割り当てる方法。 ユーザー・プリファレンス（ＵＰ）： 会社またはユーザーがシステムの機能へのアクセスを制御または管理できる方
法。 フィルタ（ＦＩ）： これにより、ユーザーはメッセージを制限できる（すなわち、ユーザーが受け
取るかまたは表示するスイッチに対する価格または要求を求める） 記号使用（ＳＹ）： これにより、ユーザーは、系統的にシステム内の金融契約を即座に、容易に参
照できる。 契約条件交渉（ＴＮ）： これは、ユーザーが、取引に続いて契約の非商用条件を交渉できる方法である
。例えば、拡大取引に関連する債権の交換。 信用無効化プロセス： このプロセスにより、ユーザーは彼らの個人情報を契約相手に開示し、彼らが
最初に、信用発行により相手を拒絶した場合でも、取引を受け取るかどうかを確
認できる。 総合確認： これは、金融商品の全クラスに渡り双方間契約を完全に確定するための確認レ
イアウトである。 要求発行（ＲＦ）： これは、価格または市場の関心事項を他のユーザ（彼らのＦＩに従い）にブロ
ードキャストする方法である。

【００２９】 ２．システム・アーキテクチャ 当業者には価値を理解されるように、本発明は、方法、データ処理システム、
またはコンピュータ・プログラム・プロダクトとして実現できる。したがって、
本発明は、全体のハ−ドウェア具体化、全体のソフトウェア具体化、またはソフ
トウェアおよびハードウェア構成を組み合わせた具体化の形態を取ることができ
る。さらに、本発明は、記憶媒体で実現されるコンピュータ読み取り可能プログ
ラム・コード手段を有する、コンピュータ読み取り可能な記憶媒体上のコンピュ
ータ・プログラム・プロダクトの形態を取る。ハード・ディスク、ＣＤ−ＲＯＭ
、光記憶媒体、または磁気記憶デバイスを含む、コンピュータ読み取り可能なす
べての適正な記憶媒体を利用できる。

【００３０】 本発明を、以下に、本発明の実施形態による方法、装置（すなわちシステム）
、およびコンピュータ・プログラム・プロダクトのブロック図およびフローチャ
ート図を参照して説明する。ブロック図およびフローチャート図の各ブロック、
ならびにブロック図およびフローチャート図のブロックの組み合わせは、それぞ
れ、コンピュータ・プログラム命令により実現される。これらコンピュータ・プ
ログラム命令は、汎用コンピュータ、特殊用途コンピュータ、または他のプログ
ラム可能なデータ処理装置にロードされてマシンを形成し、それにより、コンピ
ュータ上で実行される命令、または他のプログラム可能データ処理装置がフロー
チャート・ブロックまたはブロックで指定された機能を実行する手段を生成する
。

【００３１】 これらコンピュータ・プログラム命令はまた、コンピュータ読取り可能メモリ
に格納でき、それにより、コンピュータまたはプログラム可能なデータ処理装置
に命令して特定の方法で機能させ、コンピュータ読取り可能メモリに格納された
命令が、フローチャート・ブロックまたはブロック内で指定された昨日を実現す
る命令手段を含む製品を形成する。コンピュータ・プログラム命令をコンピュー
タまたは他のプログラム可能データ処理装置上にロードして、コンピュータまた
は他のプログラム可能装置上で一連の動作ステップを実行してコンピュータ実行
プロセスを形成し、それにより、コンピュータまたは他のプログラム可能データ
処理装置上で実行される命令が、フローチャート・ブロックまたはブロックで指
定された機能を実行するステップを備えることができる。

【００３２】 したがって、ブロック図またはフローチャート図のブロックは、特定機能を実
行する手段の組み合わせと、特定機能を実行するステップおよび特定機能を実行
するプログラム命令手段の組合わせとをサポートする。また、ブロック図または
フローチャート図の各ブロック、およびブロック図またはフローチャート図のブ
ロックの組み合わせは、指定された機能またはステップを実行する特定目的のハ
ードウェア・ベースのコンピュータ・システム、または特定目的のハードウェア
およびコンピュータ命令の組み合わせにより実現できる。

【００３３】 本発明による取引システムは電子的仲介システムであり、このシステムはイン
ターネット・プロトコル・ベースの通信ネットワークを使用して、ユーザーによ
る金融デリバティブの取引（すなわち、売買）を容易にし、またこのシステムの
各々が、以下に述べるように、金融会社（クライアント側）の取引所に設置され
たユーザー自身のデスクトップ・コンピュータ・システム（トレーダーシステム
）に結合されている。ユーザーのデスクトップ・コンピュータ・システムでは、
好ましくは、本発明Ｊａｖａ・ベースのソフトウェア・プログラムにより実現さ
れるが、例えばＤＨＴＭＬ（ｄｙｎａｍｉｃ ｈｙｐｅｒｔｅｘｔ ｍａｒｋｕ
ｐ ｌａｎｇａｇｅ）、Ｃ＋またはＣ＋＋のような別の適正なプログラム言語を
使用することもできる。

【００３４】 図１に示すように、本発明による取引システム１０は、１つまたは複数の各種
のインターネット・プロトコル・ベースの通信ネットワーク１６を介してクライ
アント側１４と通信する中央処理センター１２を備える。図では、プライーベー
ト・エキストラネット、パブリック・インターネット、およびサードパーティ・
エキストラネットを示すが、当業者には、公衆交換電話網（ＰＳＴＮ）のような
他のネットワークをネットワーク１６として組み入れることもできることは認識
されるであろう。さらに、利用可能な複数ネットワーク１６を有することにより
、ユーザーは１つのネットワークがサービス妨害を受けた場合の冗長性を備え、
またユーザーは料金または帯域幅などの要素に基づき、複数のネットワーク１６
の中で主アクセスを選択できる。

【００３５】 各クライアント側１４は１つまたは複数のビジネス・ユニット・サーバ１８を
含み、詳細にはこのサーバは、本発明を実現するのに利用できるＪａｖａアプレ
ットのコピーを格納できる。ビジネス・ユニット・サーバ１８はまた、ネットワ
ーク１６を介して送信および受信されるメッセージの暗号化機能／解読機能も実
行できる。好ましくは、ビジネス・ユニット・サーバ１８はクライアント側１４
の内部データ・ネットワークに接続される。このように、１つまたは複数のトレ
ーダーワークステーション２０は、クライアント側１４のビジネス・ユニット・
サーバ１８に接続される。したがって、クライアントの内部データ・ネットワー
クに接続されるユーザー自身のデスクトップ・コンピュータは、トレーダーワー
クステーション２０として機能し、本発明のＪａｖａベースのソフトウェアを実
行して、中央処理センター１２を介して別のトレーダーワークステーション２０
と対話できる。

【００３６】 図２には中央処理センター１２を示し、このセンター１２は取引メカニズム３
０、グループ・サーバ・メカニズム３２、オークション・メカニズム３４、スイ
ッチ・メカニズム３５を備える（これらメカニズムのすべては本発明によるもの
である）。取引メカニズム３０は、市場登録簿モジュール３８、実行モジュール
４０、決済モジュール４２を含む複数のモジュールを備える。市場登録簿ジュー
ル３８は各市場に対する受動オーダーを維持し、新しいオーダーを受け取るとト
レーダーワークステーション２０の前記受動オーダーをブロードキャストして、
すべての提案された取引を確認し、トレーダーワークステーション２０で実行で
きない第２および最終信用プリファレンス検査を実行し、さらに両方のトレーダ
ーがオンライン（すなわち能動）状態にあることを確認し、取引を実行し、トレ
ーダーに状態更新信号を送り出す。実行モジュール４０は、実行される取引を受
け取り、該当する場合はより大量の取引を提案し（ｗｉｌｌ−ｄｏ−ｍｏｒｅ（
さらに多くの取引を実行する）機能と呼ばれる）、該当する場合は契約条件交渉
を行う。決済モジュール４２は、適正な手数料を計算し、確認を行い、その確認
を両方の当事者に送る。

【００３７】 グループ・サーバ・メカニズム３２は、取引モジュール３０と取引ワークステ
ーションとを接続する。中央処理センター１２は複数のグループ・サーバ・メカ
ニズム３２を備えることができ、そのサーバの各々がシステム１０のユーザーの
サブセット（すなわち、トレーダーワークステーション）にサービスを提供する
。ただし、システム１０は１つのグループ・サーバ・メカニズム３２を実装でき
るだけである。グループ・サーバ・メカニズム３２は、各トレーダーワークステ
ーション２０のコネクションを監視し、ログ・インおよびログ・アウトの時間お
よび使用を監視できる。グループ・サーバ・メカニズム３２はまた、各トレーダ
ーワークステーション２０に表示される市場情報を保存し、そのトレーダーを固
有に識別するオーダー識別コードを生成する。全ユーザーの信用プリファレンス
情報はグループ・サーバ・メカニズム３２により保存され、関連するユーザーが
ログ・インすると、各トレーダーワークステーション２０に配信される。トレー
ダーによる信用プリファレンス設定のすべての変更は、検出されて、別のユーザ
ーのトレーダーワークステーション２０に送られる。

【００３８】 スイッチ・メカニズム３５の構成は、複数ユーザーの金利再設定リスクのポー
トフォリオを受け取り、かつそれらのユーザーに、他の見込みのある契約相手お
よびユーザーの金利再設定リスクを相殺できる有効な取引に対する、それらユー
ザーの相対ポジションにおける匿名表示を提供するように構成されている。オー
クション・メカニズム３４はスイッチ・オークション機能を実行し、それにより
オーダーまたはＦＲＡがユーザーから受け取られ、ユーザー信用プリファレンス
を考慮するアルゴリズムに基づいて匿名マッチングが取られる。

【００３９】 トレーダーメカニズム３０、グループ・サーバ・メカニズム３２、オークショ
ン／スイッチ・メカニズム３４、およびスイッチ・メカニズム３５は、市場モジ
ュール４４としてまとめて実現できる。 中央処理センター１２は、システム・インタフェース５２を介して中央処理セ
ンター１２内の他の構成要素と通信するプロセッサ５０を備える。入力デバイス
５４、例えばキーボードまたはポインティング・デバイスを使用してユーザーか
らデータを入力し、またスクリーン表示デバイス５６、例えばモニターを使用し
てユーザーにデータを出力する。中央処理センター１２内のメモリ５８は、市場
モジュール４４および従来のオペレーティング・システム６０を備え、そのオペ
レーティング・システム６０は市場モジュール４４と通信し、プロセッサ５０に
より市場モジュール４４（取引メカニズム３０、グループ・サーバ・メカニズム
３２、オークション・メカニズム３４を含む）の実行を可能にする。外部通信ラ
イン６２は、中央処理センター１２と、他のコンピュータ・システムまたはネッ
トワーク１６のようなコンピュータ・ベースのデバイスとを接続するために設け
られている。最後に、ハード・ディスク６４は、産業界で公知の永久メモリ・デ
バイスとして備えることができる。好ましくは、リレーショナル・データベース
６６がハード・ディスク６４に常駐し、例えば各トレーダーワークステーション
２０の現在の状態情報、ユーザーおよびビジネス・ユニット・データ、金融商品
定義、オーダー状態、売買状態、確認状態、履歴確認および売買データ、全ビジ
ネス・ユニットの信用プリファレンス、および履歴市場データなどの情報を維持
する。好ましくは、リレーショナル・データベース６６がハード・ディスク６４
に常駐し、例えば各トレーダーワークステーション２０の現在の状態情報、ユー
ザーおよびビジネス・ユニット・データ、金融商品定義、オーダー状態、売買状
態、確認状態、履歴確認および売買データ、全ビジネス・ユニットの信用プリフ
ァレンス、および履歴市場データなどの情報を維持する。好ましくは、リレーシ
ョナル・データベース６６は、産業界では公知の、構造化照会言語（ＳＱＬ）管
理システムを基本とする。

【００４０】 次の図３には、本発明によるトレーダーモジュール７０を含むトレーダーワー
クステーション２０の実施形態を示す。トレーダーモジュール７０は、例えばＮ
ｅｔａｃａｐｅ Ｃｏｍｍｕｎｉｃａｔｏｒ（登録商標）（Ｎｅｔｓｃａｐｅ
Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｃｏｍｐａｎｙ）またはＭｉｃｒｏｓｏｆｔ（登
録商標） Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（Ｍｉｃｒｏｓｏｆｔ Ｃｏｒ
ｐｏｒａｔｉｏｎ）バージョン３．０以上のような、Ｊａｖａ対応のインターネ
ット・ブラウザ・プログラム７２のコンポーネントとして実現できる。したがっ
て、好ましい実施形態では、トレーダーモジュール７０は、各セッションに対し
Ｊａｖａアプレットとしてダウンロードされ、かつインターネット・ブラウザ７
２内でＪａｖａ仮想計算機（ＪＶＭ）７３により実現されるＪａｖａベースのプ
ログラムである。インターネット・ブラウザ・プログラム７２のＪＶＭ７３は、
スタンド・アロン・ソフトウェア・アプリケーション、プラグイン・アプリケー
ション、またはヘルパー・アプリケーション（これらすべては、当技術分野で公
知）であってもよい。トレーダーモジュール７０は、市場インタフェース・モジ
ュール７４、信用プリファレンス・モジュール７６、記号モジュール７８、スイ
ッチ・モジュール８０、およびオークション・モジュール８１を含む。市場イン
タフェース・モジュール７４は、ユーザーに情報を提供する１つまたは複数のユ
ーザー・インタフェースを備える。本発明の実施形態では、ユーザー・インタフ
ェースは、インターネット・ブラウザ・プログラム７２のコンテキスト内のウイ
ンドウとして実現される。しかし、本発明によるユーザー・インタフェースは、
例えばバーチャル・リアリティ・モデリング言語（ＶＲＭＬ）に基づく３次元バ
ーチャル・リアリティ・ワールド、オーディオ受信機／送信機、またはユーザー
とトレーダーワークステーション２０との間の他の任意の適正な形態のインタフ
ェースなどの、多くの形態を取ることができる。好ましい実施形態では、市場イ
ンタフェース・モジュール７４は、コントロール・センター・インタフェース、
市場エントリ・インタフェース、市場詳細インタフェース、スイッチ・インタフ
ェース、およびオークション・インタフェース（これらはすべて、以後に詳細に
説明する）を備える。

【００４１】 信用プリファレンス・モジュール７６は、ユーザーにより入力され、グループ
・サーバ・メカニズム３２で格納された、格納された信用プリファレンスを受け
取る。格納された信用プリファレンスは、他のビジネス・ユニットの法的主体に
向けられたプリファレンスと、対象ユーザーのビジネス・ユニットの法的主体に
向けられた他のユーザーにより入力されるプリファレンスとを含む。前述のよう
に、好ましくは、信用プリファレンス情報はデータベース６６（図２）に格納さ
れる。信用プリファレンス・モジュール７６は、ユーザーの信用プリファレンス
を持つユーザーに提供されるオーダー情報と、そのオーダーを登録した契約相手
の信用優先とを符号化できる。また信用優先モジュール７６は、取引が開始され
るときに、各オーダーの信用優先検査を実行する。本発明により提供される異な
るタイプの信用方法に関連する予想される複雑性の理由から、信用検査プロセス
の各部分は中央処理センター１２の市場登録簿モジュール３８により実行するこ
ともできる。各トレーダーワークステーション２０の信用優先モジュール７６は
、合格／不合格の簡単なマトリックスと関連する満期日とを含む。ビジネス・ユ
ニットがさらに複雑な方法（すなわち複合）を選択した場合、満期日による単位
（リスク指数、すなわちＲＱ）も必要とされる。したがって取扱者ワークステー
ション２０は、全数量を取引できるかどうかを決定できない。このため、市場登
録簿モジュール３８は信用検査を繰り返して、最新の信用優先が使用されること
を保証し（トレーダーワークステーション２０の信用優先を更新しているどれか
の待ち時間の場合）、また数量に対するすべての複合信用優先検査を完成する。

【００４２】 スイッチ・モジュール７８は、システム１０で取引される異なる金融商品の主
題ベースのアドレス指定に利用される記号定義を格納する。記号モジュール７８
はまた、システム１０で使用する新しい記号を定義する手段を備える。スイッチ
・モジュール８０は、中央処理センター１２のスイッチ・メカニズム３５に送ら
れる、金利再設定リスク・ポートフォリオをユーザーから受け取るように構成さ
れる。スイッチ・メカニズム３５により発生する相対ポジション情報は、市場イ
ンタフェース・モジュール７４を介してポジション情報をユーザーに提供するス
イッチ・モジュール８０に戻される。オークション・モジュール８１の構成は、
異なる価格レベルの単一商品の複数またはバッチ・オーダーを受け取り、またス
イッチ・オークションの場合、ユーザーから金利再設定リスク・ポートフォリオ
を受け取るように構成されている。入力されたオーダーまたはポートフォリオは
、中央処理センター１２のオークション・サーバ３４に送られ、そこでオークシ
ョンまたはスイッチ・オークションがそれぞれ実行される。その結果得られたマ
ッチングは、その結果を市場インタフェース・モジュール７４によりユーザーに
提供する、オークション・モジュール８１に返送される。

【００４３】 トレーダーワークステーション２０は、システム・インタフェース８４を介し
てトレーダー内の他の構成要素と通信するプロセッサ８２を備える。入力デバイ
ス８６、例えばキーボードまたはポインティング・デバイスを使用してユーザー
からデータを入力し、またスクリーン表示デバイス８８、例えばモニターを使用
してユーザーにデータを出力する。トレーダーワークステーション２０内のメモ
リ９０は、インターネット・ブラウザ・プログラム７２（したがって、トレーダ
ーモジュール７０）および従来のオペレーティング・システム９４を備え、その
オペレーティング・システム９４はインターネット・ブラウザ・プログラム７２
（したがって、トレーダーモジュール７０）と通信し、プロセッサ８２によりイ
ンターネット・ブラウザ・プログラム７２（したがって、トレーダーモジュール
７０）の実行ができる。しかし、好ましくは、トレーダーモジュールは単一セッ
ションの間に実行のためメモリ９０内にダウンロードされるＪａｖａベースのプ
ログラムとして実現され、トレーダーワークステーション２０はトレーダーモジ
ュール７０を永久的に格納しない。さらに、Ｊａｖａベースのプログラムとして
、トレーダーモジュール７０は、インターネット・ブラウザ・プログラム７２の
コンポーネントであるＪＶＭ７３上で実行される。

【００４４】 外部通信リンク９６は、トレーダーワークステーション２０と、それぞれのビ
ジネス・ユニット・サーバ１８のようなコンピュータ・システムまたはコンピュ
ータ・ベースのデバイスとを接続するために設けられている。最後に、ハード・
ディスク９８は、産業界で公知の、永久メモリ・デバイスとして備えることがで
きる。トレーダーワークステーション２０は前述のデスクトップ・コンピュータ
・システムを備えることができ、または代替方法では、トレーダーワークステー
ション２０は例えばノートブック・コンピュータ、ハンドヘルドＰＣ、携帯情報
端末（ＰＤＡ）、またはインターネット・ブラウザ・プログラムを実行し、かつ
ネットワークに接続する通信リンクを形成する他の任意の適正なデバイスなどの
ようなポータブル・コンピューティング・デバイスを備えることもできる。

【００４５】 したがって、システム１０のユーザーは、必ずしも特定の配線された端末に縛
られることなく、Ｊａｖａ対応ブラウザへのアクセスおよびインターネット・ア
クセスを得られるどの場所にでも、ユーザーと共に移動する仮想端末を有する。
トレーダーモジュール７０は、インターネット、ローカル・エリア・ネットワー
ク（ＬＡＮ）、またはワイド・エリア・ネットワーク（ＷＡＮ）を介して中央処
理センター１２に通信リンクを確立できる独立プログラムとして実現できる。し
たがって、ユーザーは、公衆交換電話網（ＰＳＴＮ）またはインターネットを介
して中央処理センター１２に直接モデムでダイアル・インして、システム１０に
アクセスすることも可能である。

【００４６】 図４には、本発明によるプロキシ・エージェント１１０を含むビジネス・ユニ
ット・サーバ１８の実施形態を示す。プロキシ・エージェント１１０は、ネット
ワーク１６を介して送信および受信される暗号化されたメッセージの復号化およ
び符号化を含む多数の機能を実行できる。プロキシ・エージェント１１０は、ト
レーダーワークステーション２０との間のトラフィックを管理し、またドキュメ
ントのキャッシングおよびネットワーク・アクセス制御などの他の機能を備える
ことができる。プロキシ・エージェント１１０は、トレーダーワークステーショ
ン２０に頻繁に要求されるデータを格納または供給するか、またはネットワーク
１６からの情報をフィルタリングおよび／または処分することにより、性能を向
上できる。好ましくは、プロキシ・エージェント１１０は、それぞれのクライア
ント側１４の内部データ・ネットワークの一部であるビジネス・ユニット・サー
バ１８に常駐する。しかし、本発明のシステム１０はビジネス・ユニット・サー
バ１８を必要とせずに実現でき、その結果、プロキシ・エージェント１１０の機
能は、それぞれのトレーダーワークステーション２０のトレーダーモジュール７
０に組み込むことができる（このような機能には、暗号化されたメッセージの復
号化および符号化とネットワーク管理とを含む）。

【００４７】 ビジネス・ユニット・サーバ１８は、システム・インタフェース１１４を介し
てビジネス・ユニット・サーバ１８内の他の構成要素と通信するプロセッサ１１
２を含む。入力デバイス１１６、例えばキーボードまたはポインティング・デバ
イスを使用してユーザーからデータを入力し、またスクリーン表示デバイス１１
８、例えばモニターを使用してユーザーにデータを出力する。ビジネス・ユニッ
ト・サーバ１８内のメモリ１２０は、プロキシ・エージェント１１０および従来
のオペレーティング・システム１２２を備え、そのオペレーティング・システム
１２２はプロキシ・エージェント１１０と通信し、プロセッサ１１２によりプロ
キシ・エージェント１１０の実行を可能にする。外部通信リンク１２４は、ビジ
ネス・ユニット・サーバ１８と、ネットワーク１６およびトレーダーワークステ
ーション２０のようなコンピュータ・システムまたはコンピュータ・ベースのマ
シンとを接続するために設けられている。最後に、ハード・ディスク１２６は、
産業界で公知の、永久メモリ・デバイスとして備えることができる。特に、ハー
ド・ディスク１２６は、ビジネス・ユニット・サーバ１８に結合されている別々
のトレーダーワークステーション２０の各々のトレーダーデータ・プロファイル
１２８を含むことができる。代替方法では、トレーダーデータを中央処理センタ
ー１２に格納することにより、トレーダーがシステム１０にログ・オンする度に
トレーダーのスクリーンを再構成する必要をなくすることができる。

【００４８】 したがって、クライアント側１４の各トレーダーワークステーション２０は、
ユーザーのデスクトップ・コンピュータ上で動作するインターネット・ブラウザ
・プログラム７２を通してシステム１０にアクセスできる。システム１０にアク
セスするために、ユーザーはデスクトップ・コンピュータ上でインターネット・
ブラウザ・プログラムのＪａｖａベース・アプレットを実行できる。前記Ｊａｖ
ａアプレットは３つの方法のいずれかでデスクトップ・コンピュータ・システム
にアップロードできる。すなわち、１）デスクトップ・コンピュータ２のハード
・ディスクからアクセスする、２）ネットワークを介して、クライアント側の内
部データ・ネットワーク上のサーバからダウンロードする、３）中央処理センタ
ーから直接ダウンロードする、のいずれかの方法で可能である。アプレットがロ
ードされ、ユーザーのデスクトップ・コンピュータで実行されると、ユーザーは
システム１０にアクセスでき、他のトレーダーワークステーション２０と対話し
て、取引活動に参加できる。クライアント側のトレーダーに加えて、本発明の好
ましい実施形態では、クライアント側１４の非トレーダーユーザー（信用担当者
および利害関係者／関係者など）が、ユーザーと同一方法で本発明のシステムに
アクセスして、取引活動を閲覧し、信用制御または任意の別の機能を実行できる
。

【００４９】 ３．システム機能 特定の機能性および有用性を備える本発明の機能を以下に述べる。これらの機
能には、コマンド・センター・インタフェース、市場エンティティ・インタフェ
ース、市場詳細インタフェース、未決済オーダー・インタフェース、履歴オーダ
ー・インタフェースなどのインタフェース、および記号方式、信用プリファレン
ス検査、契約条件交渉、自動通知、金利リスク・スイッチ、およびオーダー・オ
ークションなどの機能を含む。

【００５０】 システム１０上でセッションを開始するとき、トレーダーワークステーション
２０のユーザーはインターネット・ブラウザ・プログラム７２を起動し、トレー
ダーワークステーション２０を中央処理センター１２に接続する特定アドレスに
移動する。好ましくは、これは、インターネット・ブラウザ・プログラム７２の
アドレス・フィールドに既知のＵＲＬ（Ｕｎｉｖｅｒｓａｌ Ｒｅｓｏｕｒｃｅ
Ｌｏｃａｔｏｒ）を入力することによりなされる。入力されたＵＲＬにおいて
、ユーザーはログ・オン・スクリーンを提示され、好ましくはそのスクリーンは
、ユーザーが識別、確認およびセキュリティの理由でユーザー名およびパスワー
ドを入力することを要求する。ユーザーがログ・オン後、ユーザーは、トレーダ
ーワークステーション２０を備えるデスクトップ・コンピュータ上でローカルに
稼動するＪａｖａアプレットをダウンロード（好ましくはプロキシ・エージェン
ト１１０から）する。代替方法では、ユーザーは、ローカルにまたは接続された
サーバで実行するローカルまたはネットワーク・アプリケーションを起動できる
。アプリケーションは、ＡＯＬのような多数のダイアル・アップ・サービスと同
様のネットワーク１６を介して、システム１０へのコネクションを可能にする。
さらに、トレーダープロファイルを基にするユーザー定義のプリファレンスのよ
うな他の情報は、トレーダーワークステーション２０にダウンロードされる。こ
れは、ユーザーが取引を許可されることに関する情報、ユーザーが関心を持ち閲
覧する市場に関する情報、およびユーザーまたは信用業務担当者等の別の個人に
よりすでに定義されているその他のユーザー情報を含む。

【００５１】 ユーザーがログ・オンを完了し、必要なＪａｖａアプレットをダウンロードし
、ＪＶＭ７３を稼動後、ユーザーは、スクリーン表示デバイス８８（図３）によ
り、図５に示すようなコマンド・センター・インタフェース１３０の提示を受け
る。コマンド・センター・インタフェース１３０は、以下に述べるように、本発
明の他のすべての機能にアクセスできるユーザー・インタフェースのフロント・
エンドである。コマンド・センター・インタフェース１３０の実施形態では、コ
マンド・センター・インタフェース１３０は、スクリーン表示デバイス８８上に
表示されるポップ・アップ・ウインドウである。しかし、コマンド・センター・
インタフェース１３０が動作している間は、ユーザーはインターネット・ブラウ
ザ・プログラム７２ウィンドウをアイコン化（すなわち最小化）できる、これは
、ユーザーがインターネット・ブラウザ・プログラム７２を見る必要がなくなっ
たときに望むと思われる。

【００５２】 コマンド・センター・インタフェース１３０から、ユーザーはシステム１０の
諸機能にアクセス可能であり、その機能により、ユーザーはシステム１０中で取
引を監視および制御できる。詳細には、コマンド・センター・インタフェース１
３０から、ユーザーはツール・バー１３２のメニュー・オプションとして、以下
の領域の機能にアクセスできる。すなわち、市場エントリ・インタフェース（図
１２に関して以下に述べる）、信用設定インタフェース（図１０に関して以下に
述べる）、スイッチ・エンジン・インタフェース（図２２に関して以下に述べる
）、オークション・インタフェース（図１３参照）、ツール、ユーザー・プリフ
ァレンス・インタフェース（図６Ａおよび６Ｂに関して以下に述べる）、履歴オ
ーダー記録簿インタフェース（図１７に関して以下に述べる）、未決済オーダー
記録簿インタフェース（図１６に関して以下に述べる）、ＭａｒｋｅｔＳｈｅｅ
ｔ(商標）（ＴＩＢＣＯ，Ｉｎｃ．の商標）のような外部アプリケーションへの
リンク（本明細書では、説明の目的で、引用符スクリーンおよびグラフ・スクリ
ーンと呼ぶ）、および詳細なオンライン・ヘルプが提供されるヘルプ・インタフ
ェースの機能にアクセスできる。好ましくは、ツール・バー１３２に表れるメニ
ュー・オプションはユーザーに対してカスタマイズ可能であり、記述されている
メニューは単に説明のためのものである。

【００５３】 さらに、コマンド・センター・インタフェース１３０は、リアルタイム・メッ
セージを表示するメッセージ表示ウィンドウ１３４を備える。これらメッセージ
には、システム情報、市場情報、価格に対する要求（ＲＦＰ）、スイッチに対す
る要求（ＲＦＳ）、またはシステム１０のユーザーとのオンライン・チャット・
セッションを含む。コマンド・センター・インタフェース１３０は、メッセージ
表示ウィンドウ１３４の下に、ユーザー名１３６、ユーザーのデフォルト通貨１
３８、ユーザーのビジネス・ユニット１４０、およびその他の関係情報を表示す
る。好ましくはメッセージ表示ウィンドウの背景色は、中央処理センター１２へ
のコネクションが何らかの理由で切断された場合に変化する。

【００５４】 ツール・バー１３２を介してコマンド・センター・インタフェース１３０から
アクセスできるユーザー・プリファレンス・インタフェース１４８は、図６Ａお
よび６Ｂに示すようなユーザー・プリファレンス機能をユーザーに提供する。図
６Ａでは、Ｄｅｒｖ Ｆｉｌｔｅｒｓタブにより、ユーザーは価格への要求（Ｒ
ＦＰ）フィルタを設定して、デリバティブ商品のタイプ（すなわちクラス）およ
び通貨に基づく異なるデリバティブ商品を表示させることができる。ユーザーは
また、表示の方法（すなわち、強調表示または通常）を選択できる。Ｄｅｒｖ
Ｆｉｌｔｅｒｓタブから、ユーザーは、ユーザー表示リスト（つまり、コマンド
・センター・インタフェース１３０のメッセージ・ウィンドウ１３４に表示され
る商品リスト）からデリバティブ商品を追加または削除できる。図６Ｂでは、Ｅ
ｎｖｉｒｏｎｍｅｎｔタブにより、ユーザーは表示オプションを選択して表示内
容を変更できる。カラー・コード化表示オプションに関しては、ユーザーはカラ
ー・ブラインド・ユーザーを選択することにより、コード化されたオーダー情報
カラーを持たないことを選択できることを注意する必要がある。ユーザーがカラ
ー・ブラインドであるかまたはモノクロ・スクリーン表示デバイス８８を使用し
ているとき、希望する場合には、マークまたは記号のような別の表示手段を利用
できる。信用グループ（Ｃｒｅｄｉｔ Ｇｒｏｕｐ）商品クラス（Ｉｎｓｔｒｕ
ｍｅｎｔ Ｃｌａｓｓ）およびＳＷＦ通貨（ＳＷＦ Ｃｕｒｒｅｃｙ）のユーザ
ー・デフォルトは、環境タブ（Ｅｎｖｉｒｏｎｍｅｎｔ ｔａｂ）を介して選択
することもできる。

【００５５】 この点で、本発明の動作に統合された複数の機能は注目する価値がある。詳細
には、広範囲の金融契約に対して電子取引システムを達成するために、２つの極
めて重要な問題を解決するソリューションを開発する必要があることが認識され
ていた。その問題とは、（１）金融契約を識別する方法と、（２）会社が商品に
対する信用プリファレンスまたは関係を記述できる方法とである。これらの問題
に対するソリューションとして、本発明は以下の述べる記号方式および信用プリ
ファレンス機能を提供する。

【００５６】 本発明の記号法は、外貨取引と異なり、金融商品が簡単である場合、デリバテ
ィブ売買の契約条件および条件のすべてを言葉により説明する別々の外貨取引が
、説明に比較的長時間を要する困難で複雑な作業である理由から開発された。さ
らに、大部分のデリバティブ売買は特定の要求に適合するように特有にカスタマ
イズされる。デリバティブ取引では、株、債券、または他の金融商品に比較して
、満期日、固定金利、変動金利、通貨、変動金利指標、および計算金利などの多
数のパラメータがあるのが一般であり、それらパラメータは重要であり、明確に
されるのが望ましい。この複雑性が、店頭（ＯＴＣ）デリバティブに対する効率
的なディーラ相互の電子取引システムの発展と実現の主要な阻害の１つの原因で
あると言われている。

【００５７】 記号法を用いることにより、特に、記号が取引社会に直感的であることが保証
され、新しい商品が導入されたときに新しい記号で作成されたシステムを表すこ
とができ、また詳細確認処理が可能になる。これらの目的は一般に、これらデリ
バティブ商品を定義するパラメータ、契約条件、および条件を４部分の主題コー
ドに系統的に分割することにより達成される。この４部分の主題コードにより、
主題ベースのアドレス指定として公知の方式を介してこれら商品を参照できる。
４部分の主題コードは、ソース（ＳＯＵＲＣＥ）、クラス（ＣＬＡＳＳ）、記号
（ＳＹＭＢＯＬ）、通貨（ＣＵＲＲＥＮＣＹ）に分割されている。４部分の主題
コードの各フィールドは以下のように定義される。

【００５８】 記号方式のソース・フィールドは、情報のソースを識別する。ほとんどの場合
、これは、本発明の譲受人であるコードＤＮＩ（すなわちＤｅｒｉｖａｔｉｖｅ
ｓ Ｎｅｔ，Ｉｎｃ．）である。システム１０内でコードを使用する場合、記号
方式のソース・フィールドＤＮＩであると仮定され、削除される。記号をより広
い状況で使用する場合、ソースは識別される。例えば、取引データが、Ｒｅｕｔ
ｅｒｓ Ｉｎｃ．により運営されるタイプのようなサード・パーティのデータ配
布システムを介しては配布およびアクセスされると仮定すると、主題コードのソ
ース・フィールドが使用されることになる。

【００５９】 クラス・フィールドは、金融商品をその中に分類して入れる主要な製品クラス
を識別する。クラス・パラメータは、類似の属性を共有する金融契約をグループ
化するように設計されている。本発明の開示の目的に対して、各々が別個の特性
、先物相場契約、金利スワップ、金利ベーシス・スワップ、金利オプション、外
国為替、およびスイッチを範囲に含む１１クラスの商品を範囲に含む。スイッチ
は、同一クラスの２つの商品を同時に購入し、販売する。以下は１１クラスのリ
ストおよび各々に関連する省略形である。

【００６０】 ＦＲＡ−先物相場契約 ＳＷＰ−金利スワップ ＣＡＰ−金利オプション（キャップまたはフロア） ＳＯＰ−金利オプション（スワップ） ＩＢＳ−金利ベーシス・スワップ（変動対変動スワップ） ＳＰＴ−外国為替スポット ＦＷＤ−外国為替無条件先物 ＦＸＳ−外国為替スワップ ＳＷＦ−ＦＲＡスイッチ ＳＷＴ−同一クラス内の商品の他のどれかのペアのスイッチ ＣＢＳ−通貨ベース・スワップ

【００６１】 記号フィールドは各商品を定義するのに使用される主要コードである。記号フ
ィールドは主題コードの最も明確なフィールドである。このコンポーネントの名
前付の規則により、デリバティブ商品の基礎構造を定義できる。簡単な表記（す
なわち、１ｙｒｓｗａｐ）を使用できるが、これは新しいデリバティブ商品を容
易に追加することを認めない。以下の説明は、異なる商品またはクラスの各々を
定義するパラメータを定義する。記号は、さらに分解（explode）または定義で
きる基礎パラメータの定義に依存する。例えば、ＦＬＯＰＴは、使用される可変
金利指標を記述する２つの文字コードであり、指定された満期日、指標名、ソー
ス、休業日の規則、および計算明細を含む。本発明の実施形態の記号を以下に示
す。

【００６２】 ＦＲＡ：［ＳＴＡＲＴ，ＥＮＤ，ＯＶＥＲ，ＦＬＯＰＴ］ ＳＷＰ：［ＳＴＡＲＴ，ＥＮＤ，ＯＶＥＲ，ＦＸＤＢＡＳＩＳ，ＦＬＯＰＴ，
ＳＰＥＣＩＡＬ ＲＵＬＥ］ ＣＡＰ：［ＳＴＡＲＴ，ＥＮＤ，ＯＶＥＲ，ＦＬＯＰＴ，ＴＹＰＥ，ＳＴＲＩ
ＫＥ］ ＳＯＰ：［ＳＴＡＲＴ，ＯＶＥＲ，ＵＮＤＥＲＬＹＩＮＧ ＳＷＡＰ，ＳＯＰ
ＴＹＰＥ，ＳＴＲＩＫＥ，ＯＰＴＴＹＰＥ］ ＩＢＳ：［ＳＴＡＲＴ，ＥＮＤ，ＯＶＥＲ，ＩＮＤＥＸ１，ＩＮＤＥＸ２，Ａ
ＲＲＥＡＲ］ ＳＰＴ：［ＣＣＹ１（ｔｅｒｍｓ），ＣＣＹ２（ｂａｓｅ）］ ＦＷＤ：［ＣＣＹ１（ｔｅｒｍｓ），ＣＣＹ２（ｂａｓｅ），ＳＴＡＲＴ，Ｅ
ＮＤ，ＯＶＥＲ］ ＦＸＳ：［ＣＣＹ１（ｔｅｒｍｓ），ＣＣＹ２（ｂａｓｅ），ＳＴＡＲＴ，Ｅ
ＮＤ，ＯＶＥＲ］ ＳＷＦ：［ＦＬＯＰＴ，ＤＡＹ１，ＤＡＹ２］ ＳＷＴ：［ＡＳＳＥＴ１，ＡＳＳＥＴ ２，ＣＬＡＳＳ］ ＣＢＳ：［ＳＴＡＲＴ，ＥＮＤ，ＯＶＥＲ，ＩＮＤＥＸ１／ＣＣＹ１，ＩＮＤ
ＥＸ２／ＣＣＹ２］

【００６３】 前述の記号フィールド以下のパラメータを含む。 ＳＴＡＲＴ：ＳＴＡＲＴパラメータは、契約が決済日、すなわち１、２、３、
．．．１３、．．．３６０からの相殺を開始する月である。ＳＴＡＲＴのデフォ
ルト設定は（０）であり、これは契約が現在の月から開始されることを表す。Ｏ
ＶＥＲも下記参照。

【００６４】 ＥＮＤ：ＥＮＤパラメータは、ＯＶＥＲに対し調整される月の決済日からの最
終満期日であり、期間、すなわち１、２、３、．．．１３、．．．３６０を表す
。決済日が１１月２８日である場合、［１２日を越える１、４］として確定され
た契約は、１月１２日に始まり、４月１２日に満期になる取引と解釈する。

【００６５】 ＯＶＥＲ：ＯＶＥＲパラメータ該当月の特定日を表す。例えば、今日が１２月
３日（決済日が１２月５日）であるとした場合、１２日を超える１^*４が１月１
２日（１ヶ月を超えるがスポット日を超える２ヶ月未満の第１日）に開始する。
これにより、契約を１〜３１日の任意の開始日に確定できる。これは実際の日を
表し、将来の日数ではない。ＯＶＥＲのデフォルト設定は（０）であり、これは
スポット開始を示す。２つの別のパラメータが許容される。すなわち（Ｉ）ＩＭ
Ｍ（国際通貨市場）記録を表すパラメータ（システム１０は通貨市場で定義され
た異なるＩＭＭ規則、つまり水曜日または第２水曜日を範囲に含む）と、（Ｅ）
月末を越える記録を表す。

【００６６】 ＦＸＤ ＢＡＳＩＳ：ＦＸＤ ＢＡＳＩＳパラメータは回数および固定クーポ
ンの基準を範囲に含む２部分コードである。例のＦＲＥＱでは：Ｍ＝毎月、Ｑ＝
四半期、Ｓ＝半年に１回、Ａ＝毎年、Ｚ＝Ｚｅｒｏ ＣｏｕｐｏｎプラスＢＡＳ
ＩＳ Ｆ＝Ａ／３６５固定、Ｂ＝３０／３６０、Ｍ＝Ａ／３６０、Ｉ＝Ａ／３６
５ ＩＳＤＡなど。例えば、ＳＭは半年Ａ／３６０または半分の金額である。

【００６７】 ＦＬＯＰＴ：ＦＬＯＰＴパラメータは回数および変動クーポンの指標タイプを
範囲に含む２部分コードであり、ＩＳＤＡにより定義される変動金利オプション
を表す。ＦＬＯＰＴパラメータは回数、基準およびソースを範囲に含む。各通貨
はデフォルトを有するが、大部分の指標は利用できる。ＦＬＯＰＴの例としては
、Ｌ＝Ｌｉｂｏｒ（ロンドン銀行間オファー・レート）（ＴＥＬＥＲＡＴＥ ３
７４０／５０）、Ｐ＝Ｐｉｂｏｒ（パリ銀行間オファー・レート）（ＴＥＬＥＲ
ＡＴＥ ２００７１）、Ｔ＝Ｔｉｂｏｒ（東京銀行間オファー・レート），Ｃ＝
ＣＤＯＲ、Ｂ＝ＡＵＳ Ｂｉｌｌｓ（ＲＥＵＴＥＲＳ ＢＢＳＷ）、ＦＦ＝Ｆｅ
ｄ Ｆｕｎｄｓ（Ｈ１５）、ＴＢ＝Ｔ−ｂｉｌｌｓ（Ｈ１５）、ＰＲ＝Ｐｒｉｍ
ｅ（Ｈ１５）、ＣＰ＝３０日小切手、ＢＥ＝ＢＥＬＯ、Ｓ＝ＳＴＩＢＯＲ、ＴＡ
＝ＴＡＭ、Ａ＝ＡＩＢＯＲ，Ｄ＝ＣＩＢＯＲ（ＲＥＵＴＥＲＳ ＤＫＮＫ）、Ｒ
Ｌ＝Ｒｅｕｔｅｒｓ ＬＯＢＯからのＬｉｂｏｒ、およびＩＬ＝Ｒｅｕｔｅｒｓ
ＩＳＤＡからのＬｉｂｏｒである。

【００６８】 ＣＡＰＴＹＰＥ：ＣＡＰＴＹＰＥパラメータは、キャップ（Ｃ）およびフロア
ー（Ｆ）に対する定義を含む。したがって、好ましい実施形態では、Ｃ＝キャッ
プ、Ｆ＝フロアのコードを利用する。

【００６９】 ＳＯＰＴＹＰＥ：ＳＯＰＴＹＰＥパラメータは支払人（Ｐ）および受取人（Ｒ
）に対する定義を含む。したがって、好ましい実施形態では、Ｐ＝支払人、Ｒ＝
受取人、Ｘ＝買方選択、Ｙ＝売方選択のコードを利用する。

【００７０】 ＯＰＴＹＰＥ：ＯＰＴＹＰＥパラメータはオプション・タイプである。（Ｅ）
ｕｒｏｐｉａｎ、（Ａ）ｍｅｒｉｃａｎまたは（Ｍ）ｕｌｔｉｐｌｅ Ｅｕｒｏ
ｐｉａｎである。

【００７１】 ＳＴＲＩＫＥ：ＳＴＲＩＫＥパラメータは、オプションで設定されたキャップ
またはスワップション買取利率または価格を示す。記号でＡＴＭ（金額で）と定
義された箇所をストライクする（押す）と、パラメータにそのように表示される
。この場合、パーセンテージまたはストライクは、以下に述べる契約条件交渉プ
ロセスを通して同意される。

【００７２】 ＳＰＥＣＩＡＬ ＲＵＬＥ（特殊規則）：ＳＰＥＣＩＡＬ ＲＵＬＥパラメー
タは、ＵＳＤおよびＣＡＤのような通貨に対して設計されている、それらは少数
しかない取引の特殊な規約を使用する特定市場である。例えば、無条件スワップ
のスプレッド取引の半期債券および年間金額はこの市場では広く使用される。Ｓ
ＰＲＣＩＡＬ ＲＵＬＥパラメータにより、システム１０はすべての通貨のデフ
ォルトを複数セットで設定できる。これによりシステム１０は、売買に続いて、
いつ債券の交換がであるかを知ることができる。以下は本発明の実施形態の規則
である。 Ａ−全通貨のデフォルト Ｓ−ＵＳＤスプレッド取引。ＵＳＤのデフォルは３ヶ月ＬＩＢＯＲに対する年
間金額である。この規則は、以下に述べる契約条件交渉機能で債券が交換される
場合の、半期債券スプレッド取引を定義する。 ２−ＣＡＤスプレッド取引。ＣＡＤのデフォルトは年間金額（Ａ／３６５固定
）対３ヶ月ＣＤＯＲ支払い半期である。この規則は、以下に述べる契約条件交渉
機能で債券が交換される場合の、半期支払いされる３ヶ月ＣＤＯＲに対する半期
Ａ／３６５固定定義する。 ３−ＡＵＤスプレッド取引。ＡＵＤのデフォルトは四半期／四半期構造である
。これは取引に対し、最長３年（３年を含む）を適用する。３年を超える取引で
は、規約が半期／半期構造に切り替わる。この規則は半期／半期構造をサポート
する。 ４−ＡＵＤスプレッド取引。これは、物的交換の同意を持つ債券形態契約に対
するＡＵＤ市場でスワップ取引するための規約である。 ５−ＧＢＰスプレッド取引。ＧＢＰのデフォルトは６ヶ月ＬＩＢＯＲに対する
年間金額（Ａ／３６５固定）である。この規則は、以下に述べる契約条件交渉機
能で債券が交換される場合の、半期Ａ／３６５固定対６ヶ月ＬＩＢＯＲを定義す
る。

【００７３】 ＡＲＲＥＡＲ：ＡＲＲＥＡＲパラメータは、スワップのクーポンが設定および
支払いの両方がなされるときに定義される。大部分の金利スワップは、期間の開
始時には変動金利クーポンに設定し、クーポン期間の終了時に支払う。しかし、
ＡＲＲＥＡＲスワップでは、クーポンは期間の終了時に設定され、支払いされる
。これは一般に、アリアー・スワップと呼ばれる。システム１０は、これに対し
、ベーシス・スワップの形式を可能にする。

【００７４】 ＤＡＹ１／２：ＤＡＹ１／２パラメータは、今日からＦＲＡスイッチ（クラス
ＳＷＦ）の各ＦＲＡの開始までの暦日日数のずれである。したがって、ＤＡＹ１
／２パラメータは設定日または日付を表す。

【００７５】 ＣＣＹ１／２：ＣＣＹ１／２パラメータは通貨コードであり、外国為替商品の
ＩＳＯコードにより定義される。

【００７６】 ＵＮＤＥＲＬＹＩＮＧ ＳＷＡＰ：ＵＮＤＥＲＬＹＩＮＧ ＡＷＡＰパラメー
タは、オプションの基本になる金利スワップの完全記号の、別名またはセキュリ
ティＩＤである。

【００７７】 ＩＮＤＥＸ１／２：ベーシス・スワップが、両側が変動金利であるとき、指標
はＦＬＯＰＴプラス各指標の通貨コードを表す。第１表示の指標（ＩＮＤＥＸ１
）は買手により支払いされる。例としては、１Ｌ−ＵＳＤ、３Ｌ−ＧＢＰ、ＰＲ
−ＵＳＤ等を含む。第２指標（ＩＮＤＥＸ２）は買手により受け取られる。これ
らは基本的に、スイッチ・メカニズム３５（図２）で使用されるコードと同一で
ある。通貨ベーシス・スワップに対しては、元金の交換は契約の開始および終了
時点でなされることを前提とする。

【００７８】 ＡＳＳＥＴ１／２：クラスＳＷＴは、ＦＲＡ以外の他のクラスのスイッチ取引
を可能にするために準備されている。ＡＳＳＥＴ１およびＡＳＳＥＴ２は各基本
契約の完全記号の、別名またはセキュリティＩＤを表す。両方は同一クラスの契
約から提供されるべきである。

【００７９】 ＳＥＴＴＬＥ：ＳＥＴＴＬＥパラメータは、スワップションが現金または物品
決済のどちらであるかを示すフラグである。デフォルトは現金（Ｃ）である。

【００８０】 本発明の記号方式に従うオーダーの例は、ＤＮＩ．ＦＲＡ．１，４．０，３Ｌ
．ＵＳＤである。ここでＤＮＩはソース、ＦＲＡはクラス、１，４．０，３Ｌ．
は記号、ＵＳＤは通貨である。詳細には、記号フィールドは、３ヶ月ＬＩＢＯＲ
スポット開始に関する１／４（すなわち１ヶ月で開始する３ヶ月）ＦＲＡを定義
する。コンマ（，）は区切り文字として記号フィールド内で使用される。本発明
の記号方式に従うオーダーの別の例は、ＤＮＩ．ＳＷＰ．０，６０，０，ＡＢ，
６ＬＡ．ＤＥＭである。ここでＤＮＩはソース、ＳＷＰはクラス、０，６０，０
，ＡＢ，６ＬＡは記号、ＤＥＭは通貨である。詳細には、記号フィールドは６ヶ
月ＬＩＢＯＲスワップに対する５年（６０ヶ月）の１年債券（ＡＢ）を定義する
。

【００８１】 したがって、前述の記号法は、商品評価に影響を与えるデリバティブ商品のパ
ラメータまたは取引契約条件を取り込むように設計されている。本発明は、常に
仮定される多数のデフォルト値を備える。例えば、以下は記号デフォルト値の代
表的なリストである。

【００８２】 ＲＯＵＮＤＩＮＧ（丸め）：別途同意されない限り、ソース・ページまたはド
キュメントに見られる金利が使用される。金利は、平均演算操作後、小数点以下
５桁で丸められる。

【００８３】 ＲＲＳＥＴ ＤＡＴＥＳ（再設定日付）：これは支払日に関して定義される。
再設定日は通貨に対して標準日数だけ相殺される（例えばＵＳＤに対し２日の業
務日）。

【００８４】 ＢＵＳＩＮＥＳＳ ＣＥＮＴＥＲ ＴＯ ＡＰＰＬＹ ＴＯ ＲＥＳＥＴ Ｄ
ＡＹＳ（再設定日に適合するビジネス・センター）：再設定に対して現在の相殺
を定義するのに使用された業務日は、ソースにより（売買中の支払いではなく）
定義される。例えば、ロンドンは常に、ＬＩＢＯＲを使用し（ロンドンおよびニ
ューヨークの両方で使用するＵＳＤ ＬＩＢＯＲを除いて）、またニューヨーク
市はＨ．１５金利を使用する。

【００８５】 ＩＮＴＥＲＰＯＬＡＴＩＯＮ（補間）：補間が必要な場合は、所望の日付のど
ちらかの側に参照金利を使用する直線法を使用すべきである。

【００８６】 ＣＡＬＣＵＬＡＴＩＯＮ ＰＥＲＩＯＤ（計算期間）：最初の規約であり、最
新ではない。したがって、計算期間は最初の支払い日を含むが、次の支払い日は
除く。

【００８７】 ＴＥＲＭＩＮＡＴＩＯＮ ＤＡＹ（終了日）：終了日が日業務日である場合、
すべての終了日は調整される。

【００８８】 ＡＤＪＵＳＴ ＣＡＬＣＵＬＡＴＩＯＮ ＰＥＲＩＯ（計算期間の調整）：支
払い日が非業務日に調整される場合は、日数は調整される。

【００８９】 ＴＲＡＤＥ ＤＡＹ（取引日）：取引日は、売買に対する当事者のどちらかの
場所によってではなく、システム１０により商品および通貨に対し定義される。

【００９０】 ＮＥＴ ＰＡＹＭＥＮＴ（正味支払い）：正味支払いは、システム１０を通し
て完了したすべての売買について想定される。

【００９１】 ＣＡＮＡＤＩＡＮ ＤＯＬＬＡＲ ＳＷＡＰ（カナダ・ドル・スワップ）：こ
の規約は四半期に設定され、重み付けされた平均と最初の金利の複利を使用して
、半期で支払う。

【００９２】 ＤＡＴＥＳ（日付）：すべての日付は非業務日を無調整で表示される。

【００９３】 ユーザーは、デリバティブ商品の評価に影響を与えないが、極めて重要な別の
パラメータを交渉することを望む場合がある。これらパラメータは以後、非商用
条件と呼ぶ。商用条件と非商用条件との差は不明瞭に変化し、したがって、以降
に商用として指定されたそれら条件のいくつかは非商用に指定されることがっで
き、デフォルト設定となって記号方式パラメータの一部になることができる。本
発明の説明を目的として、非商用条件項が、ユーザーが交渉により、システム１
０を介してデフォルト値の中の新しい値に変更できるデフォルト値を与えられて
いるとする。しかし、両方の契約相手（ユーザー）は、システム・デフォルトに
置き換わる新しい値に同意しなければならない。下の表１は、交渉されると予測
される、つまり非商用条件のパラメータ・リストである。

【００９４】

【表１】

【００９５】 主題ベースのアドレス指定を備える前述の記号は複雑である可能性があり、ユ
ーザーは、一般的に取引されるデリバティブ商品を参照するための、簡単な名前
付け規約を望むこともある。ユーザーが商品を簡単に容易に参照できるようにす
るために、本発明の記号方式は別名を提供する。別名は単に、商品に対し一般に
使用される主題ベースのアドレス指定の省略形である。データベース６６（図２
）は、システム１０で使用できる各記号に対し固有のセキュリティ識別名（例え
ば１１１２２２のような数字コード）を維持する。したがって、本発明の記号方
式により、システム１０のトレーダーおよび他のユーザーは、３つの方法（完全
な記号、別名、識別名）でシステム１０の特定のデリバティブ商品をすばやく参
照できる。

【００９６】 記号方式の通貨フィールドは、表示された商品の通貨を定義するコードを含む
。好ましい実施形態では、通貨コードは標準ＩＳＯ通貨コードで示される。すな
わち、ＵＳＤ、ＤＥＭ、ＪＰＹ、ＧＢＰ、ＦＲＦ、ＮＬＧ、ＢＥＦ、ＡＵＤ、Ｃ
ＡＤ、ＩＴＬ、ＥＳＰ、ＤＫＫ、ＳＥＫ、ＥＵＲ等で示される。デフォルト通貨
は各ユーザーにより、各ユーザーのプリファレンス・インタフェース１４３（図
６Ｂ参照）で設定される。これにより、記号方式の通貨コード・フィールドは時
間節約が可能になる。しかし、外国為替取引（ＦＸＲ）は通貨コードを含むのが
望ましい。さらに、通貨コードは通貨を表し、その通貨はスポットおよび先物ク
ーポンの両方に対し等しい量の指標となる。

【００９７】 本発明の信用プリファレンス機能は、広範囲の金融商品の取引に対する取り込
みされる２つのエンティティ間の双方信用状態、構造、および使用される匿名性
に対応している。従来技術のシステムでは、信用情報は主として、スポットの外
貨取引における決済リスクを扱うために利用されていた。このような従来技術の
システムでは、信用ラインまたは限界は通常、特定取引の数量または出来高と同
等と考える通貨の量で表される。取引が契約相手との間で実行されるとき、限界
量は、信用がわずかしか存在しないかまたは無くなるまで、実行される取引量に
対応する量で減少し、その後、取引が清算されるかまたは信用限界が再設定され
るまで、別の取引は阻止される。外貨取引では、両方の契約相手が通貨を交換後
、決済プロセスは数日で完了する。その後、両者間に別の信用リスクは存在しな
い（すなわち、取引は決済される）。このことは、リスクの量が一般に売買の元
金または量に一致せず、契約における債務が将来に継続するような、デリバティ
ブ取引とは大きな違いである。デリバティブ取引は、スポット（外国為替契約の
通常決済）から将来の３０年のどれかで取引できる。したがって、その結果の信
用信用危険度（credit exposure、すなわち、将来の時点での契約の値）は、未
知量の解約の寿命全体にまたがる。

【００９８】 本発明の信用プリファレンス機能は、店頭（ＯＴＣ）デリバティブ売買におけ
る、本質的に極めて長期間の信用問題を扱うように構成される。長期間信用問題
がさらに複雑になるのは、銀行が信用リスクを内部で監視し、管理するための標
準的方法が存在しない事実による。大部分の銀行は、デリバティブについての大
規模なポートフォリオに隠れている信用リスクを監視し、測定する銀行自体の、
多くは独自の方法を開発してきた。さらに銀行は、すべての市場に存在する多く
の異なる金融商品を扱うためにそれぞれの方法を有する。

【００９９】 本発明の信用プリファレンス機能は、これら問題に対応し、実行可能なソリュ
ーションを提供する。本発明の信用プリファレンス機能は、別々の手段が標準化
測定手法を使用して同等ベースを比較できる、リスク等価（ＲＱ）と呼ばれる信
用リスクの測定ユニットを導入することにより、少なくとも部分的にこれを達成
する。前記手法は、契約支払い期日、信用グループ、クラス、信用プリファレン
ス、法的主体の概念を結合し、またビジネス・ユニットによりシステム１０が、
双方、期間デリバティブ契約に埋もれている信用リスクに対するソリューション
を提供できる。本発明もまた、信用グループの指定機能も備える。信用グループ
は、ビジネス・ユニットが信用目的と同一方法で扱えることを希望する金融契約
のクラスをグループ化するものである。好ましい実施形態では、３つのデフォル
ト信用グループを利用できる。すなわち、（１）デリバティブ−ＳＷＰ、ＩＢＳ
、ＣＡＰ、ＳＯＰ、ＦＲＡ、ＣＢＳ、（２）スイッチ−ＳＷＰ、ＳＷＦ、（３）
外国為替、の３つのグループである。必要に応じて、ビジネス・ユニットにより
その他の任意の組み合わせを構成できる。

【０１００】 信用プリファレンスは、ビジネス・ユニットにより信用グループ内で選択され
る方法および規則であり、それによりシステム１０が、他のすべての法的主体に
対するスクリーン価格（付値または売値）および取引を利用できる。好ましい実
施形態では、以下の３つの信用プリファレンスを備える。ただし、他の信用プリ
ファレンスが本発明により利用できることは、当業者にはその価値を認識される
であろう。

【０１０１】 方法１：バイナリ（簡単なｙｅｓ／ｎｏ）−これは、値洗い（ＭＴＭ）合意が
契約相手との間に存在する場合に使用される。ＭＴＭは、双方の担保合意であり
、両当事者間の信用リスクを共通にして、減少させ、単一ＩＳＤＡ（国際スワッ
プおよびデリバティブ協会）基本協約の範囲に含まれるデリバティブのポートフ
ォリオの値に対して担保を公開することによりほぼゼロにする。

【０１０２】 方法２：ライン・バイナリ−金融契約の支払い期日（取引日からの月で見積も
る）を考慮する。

【０１０３】 方法３：複合−これは満期日バンド（ｂａｎｄ）内の各契約のＲＱを基本にす
る。システムは、パーセンテージで示す一定通貨単位の形式で各商品に対しＲＱ
を計算する。各ビジネス・ユニットは、システムで生成されたＲＱ単位を使用し
て選択するか、またはそれら自体を備える。

【０１０４】 バイナリ方法では、ビジネス・ユニットはＹｅｓまたはＮｏを決定して、それ
らが特定信用グループに対し特定契約相手を扱うかどうかを決める。この信用プ
リファレンスでは、決定はバイナリである。バイナリ方法では、最長満期日限界
（すなわち時間限界）または数量限界（すなわち量）は存在しない。バイナリ方
法は、本明細書で提供される３つの信用プリファレンス決定の最も広範囲のもの
である。ＭＴＭ合意が存在するか、または信用危険度が少ない（例えば、スイッ
チにおいて）場合、一般にバイナリ方法を使用して信用を拒絶する。

【０１０５】 ライン・バイナリ方法では、ビジネス・ユニットは、特定の信用グループに対
し特定の契約相手を扱うことを前提とする。しかし、ライン・バイナリ方法はさ
らに、取引可能なすべての契約の最長満期日の別の制限を加える。好ましくは、
追加された制限は将来の月数により表される。バイナリ方法は、ＲＱユニットを
まだ使用していないが、長期間契約に対する予測される危険度を制限する方法（
例えば、一時的手段）を希望する会社で使用するのに最適である。

【０１０６】 複合方法により、各ビジネス・ユニットが、満期日バンドにより各信用グルー
プに対しすべての他の法的主体において入力準備された新しいリスク量を正確に
明記できる。複合方法により、ビジネス・ユニットは特定満期日だけでなく、特
定量またはＲＱの基準に基づく量も指定できる。さらに複合方法により、ビジネ
ス・ユニットは複数の時間期間に対しこれを指定できる。例えば、ビジネス・ユ
ニットは、銀行Ａが、５年間最大１億ドルとし、その後１０年間わずかに５千万
ドルし、その後は何も指定しないようにできる。

【０１０７】 本明細書では、リスクは一般に将来の正味返還の不確定性の程度として定義さ
れる。信用リスクはさらに、契約相手のその債務に適合する能力の不足に起因す
る、可能な損失の推定値として定義される。したがって、特定の売買のリスクは
、市場金利および売買の契約相手の信用持続の変化に依存するだけでなく、同時
に、信用リスクまたは危険度が、契約相手がその債務を履行しないときに喪失可
能な正常量であることにもよる。前述のようにデリバティブ売買の信用リスクは
比較的に複雑である。例えばデリバティブ契約は多くの形式が必要になる。大多
数は、売買が最初に開始された時には、ゼロの適正な信用値を有する。つまり、
契約が作成された時は、当事者間で資金が移動しない。どちらかと言えば、契約
は契約事項に関して両者に債務を設定する。さらに両方の当事者は、両者に一定
量のリスクを受け入れることを要求する契約を結ぶ。ＲＱは、実質的に任意の時
点で、すべての契約を同一ベースで比較できる信用リスクの単位である。ＲＱは
元金のパーセンテージで示される信用危険度である。

【０１０８】 ＲＱの計算は、連続した時間点で平均された予測される危険度を基本とし、適
正な割引係数で重み付される。本明細書では、以下に述べるオプション価格決定
法を使用してＲＱを計算するが、売買の危険度を計算するいくつかの方法がある
。

【０１０９】 特定の当事者に対し、売買は２つの逆キャッシュ・フローと見ることができる
。流入は資産（Ａ（ｔ）で示される）であり、流出は負債（Ｌ（ｔ）で示される
）である。したがって、現在の危険度は以下のように表される。

【数１】 この式はコールオプションの本質価値と同様である。主な差はＡ（ｔ）とＬ（
ｔ）の両方がランダムであることである。したがって、Ｂｌａｃｋ−Ｓｃｈｏｌ
ｅｓによるものと同一の構造に従う。

【数２】 ここでσ（ｔ）は、Ａ（ｔ）とＬ（ｔ）の両方がランダムであることを考慮に入
れた日変動率（パーセント）である。最大危険度推定値は以下の式を基本とする
。

【数３】

【０１１０】 したがって、ＲＱは以下のように表される。 ここで

【数４】 ここで

【数５】 ここでのδ（ｔ）は、将来時間ｔにおける割引率である。

【数６】

【０１１１】 ＦＲＡに対しては、以下の式が成立する。

【数７】 ここで

【数８】 および

【数９】 ここで

【数１０】 ｔ＜ｓに対し、ｘ＝１ ｔ＞＝ｓに対し、ｘ＝０

【０１１２】 ＲＱに上式を適用して、時間ｔにおける予測される危険度を求めることができ
る。時間区間ｔ₀、ｔ₁、ｔ₂、．．．．．ｔ_nを選択して、各点における予測され
る危険度を計算し、ＲＱの式を使用すれば、このＦＲＡのＲＱを計算できる。

【０１１３】 スワップに対しては、任意の時間（ｔ_i＜ｔ＜＝ｔ_i+1）に対し以下の式を適用
できる。

【数１１】 ここで、ｆｌｏａｔｉｎｇＣｏｕｐｏｎ（ｔ_j）は時間ｔ_jにおける変動クーポン
であり、ｆｉｘｅｄＣｏｕｐｏｎ（ｔ_j）は時間ｔ_jにおける固定クーポンである
。次にオプション価格決定方法の式を適用して、時間ｔにおける予測される危険
度を算出できる。その予測される危険度を割引率で平均化して、ＲＱを計算でき
る。

【０１１４】 この点で、本発明の信用プリファレンス機能を他の公知のシステムと区別する
価値があるであろう。本発明の信用プリファレンスは、２つの契約相手間で売買
される量を単に監視するだけでなく、それにより利用可能な量を減少させる。本
発明の信用プリファレンスにより実行される事前スクリーニングを使用して、各
契約相手の信用プリファレンスに基づいて可能な取引を事前にスクリーニングす
る。本発明はユーザー取引を制御せず、また、ユーザーの過去の取引を根拠にし
て、ユーザーの将来取引を直接制限しない。実際、新しい売買が２つの法的主体
の危険度を減少させることも可能である。ユーザーのビジネス・ユニットの役割
は、すべての法的主体の契約相手に関するビジネス・ユニットの信用危険度を監
視し、それによりシステム１０の信用プリファレンスを調整することである。こ
れは、取引が実行される時にそれぞれの契約相手と売買できる量を自動的に減少
する、従来技術のシステムと大きく異なる。本発明の信用プリファレンスは、こ
のようなシステム全体を改良する。なぜなら、リスクのバランスが単に新しい売
買だけでなく、２つの当事者間の全体ポートフォリオを基本とし、また、リスク
・バランスが市場動向、システム１０以外で実行される取引、および格付けの内
部変更により影響を受けるからである。

【０１１５】 ＯＴＣデリバティブに対する信用決定は他の多くの金融商品と異なると考えら
れる。一般に、ＯＴＣデリバティブに対する信用決定は、特に、ユーザーの現在
のデリバティブ・ポートフォリオのコンポーネント、金融市場の現在レベルまた
は価格、新しい金融売買、および各法的主体の信用価値の格付けまたはレベルの
関数である。したがって、ＯＴＣデリバティブ市場および他の金融市場において
信用危険度を適正に測定し、管理するためには、本発明の信用プリファレンスの
事前スクリーニングのような総合的な手段が必要とされる。

【０１１６】 本発明により、ユーザーは、図７に示す信用プリファレンス・インタフェース
１７０を介して各法的主体に対して所望の信用プリファレンスを設定できる。ユ
ーザーはコマンド・センター・インタフェース１３０（図５）のツール・バー１
３２内の信用設定ボタンを選択して、信用プリファレンス・インタフェース１７
０に移動できる。信用プリファレンス・インタフェース１７０により、ユーザー
は、鮮明な、簡単な、分かりやすい、直感的な方法で、信用プリファレンス設定
を表示および／または更新できる。信用プリファレンス・インタフェース１７０
を使用して、ビジネス・ユニットの信用プリファレンスを表示または入力／修正
できる。信用プリファレンス設定はユーザーだけがビジネス・ユニット内で表示
でき、また修正許可を持つユーザーによってだけ修正できるのが望ましく、その
両方が金融会社またはビジネス・ユニットにより指定できるのが望ましい。また
ビジネス・ユニットを選択して、それのファミリー階層内の別のビジネス・ユニ
ットから信用プリファレンスを引き継ぐことができる。

【０１１７】 好ましい実施形態では、信用プリファレンス・インタフェース１７０は、シス
テム１０へのアクセス権を持つ他のすべての法的主体（すなわち、金融会社）の
アルファベット順のリストを含む、各種情報を表示する表示ウィンドウ１７２を
備える。各法的主体は拡張ボタン１７４を介して拡張することにより、ユーザー
が、Ｍｅｒｒｉｌｌ Ｌｙｎｃｈエントリに示したのと同様にその法的主体内で
取引できるように選択した、すべての信用グループに対する設定をリストにする
ことができる。ウィンドウ１７２内で拡張されない法的主体については、表示さ
れる設定は指定されたデフォルト信用グループ１７６に対するものである。ユー
ザーが表示された信用グループを変更するには、図８Ａおよび８Ｂに示すように
、変更信用グループ・インタフェース１８０を起動するＭｏｄｉｆｙ Ｃｒｅｄ
ｉｔ Ｇｒｏｕｐ（信用グループの変更）ボタン１７８選択するにより可能にな
る。信用変更グループ・インタフェース１８０により、図８Ａに示すように、ク
ラス・グループから商品を追加および削除する操作を実行する機能を提供するこ
とにより、ユーザーはそれらのクラス・グループをカスタマイズできる。例えば
、選択された信用グループ１８２に対し、その信用グループ内の商品のリスト１
８３が提供される。指定されない商品を追加し、またリスト中の商品を削除でき
る。さらに、信用グループ１８２は、ボタン１８２、１８５を介してそれぞれ、
追加および削除できる。図８Ｂでは、各信用グループ１８２は、定義された満期
日バンド１８６（すなわち、追加または削除される）を持つことができる。好ま
しくは、各クラス・グループは密接に関連する商品を含む。なぜなら、各クラス
・グループ内の商品には同一信用プリファレンス設定が与えられ、それによって
、信用プリファレンス設定プロセスを簡単化することができるからである。

【０１１８】 図７の信用プリファレンス・インタフェース１７０に戻り説明を続ける。プリ
ファレンス設定列１８７は、対応する法的主体１８３に対し設計された信用プリ
ファレンス設定を備える。すべての法的主体に対する信用プリファレンス設定は
、ドロップ・ダウン・ダイアログ・ボックス１８８により変更または選択できる
。ドロップ・ダウン・ダイアログ・ボックス１８８から、ユーザーは予め定義さ
れた信用プリファレンス・オプションのリストから選択できる。新しいライン・
バイナリに対し、ユーザーが満期日を入力できる新しいライン・バイナリ・イン
タフェース１８９により、ユーザーは入力を促される。例えば、ユーザーが各満
期日バンドに対する危険度を入力できる複合プリファレンス・インタフェース１
９０（図９Ｂ）により、ユーザーは入力を促される。

【０１１９】 図７では、複合信用プリファレンス設定およびＲＱは、適正な法的主体を選択
し、その後Ｃｏｍｐｌｅｘ Ｂａｎｄｓ ｂｕｔｔｏｎ（複合バンドボタン）１
９４を選択することにより指定される各商品を提供できる。

【０１２０】 ユーザーが特定契約相手に対して特定プリファレンスを設定しない場合、信用
プリファレンスは簡単なバイナリ（偽）であると仮定する。これらプリファレン
スを最初に設定後、新しい契約相手がシステムに追加される場合、新しい契約相
手に対するプリファレンスはバイナリ（偽）であり、特に新しい契約相手に対す
る信用プリファレンスを設定するまでその状態を維持する。

【０１２１】 レベル列１９６は、レベルＡ、ＢまたはＣに応じて、各法的主体に対するビジ
ネス・ユニット割当てを表示する。各法的主体の対するレベル設定を、市場詳細
インタフェース（以下の図１５で説明される）のような各種インタフェースを介
してシステム１０により提供して、トレーダーに信用度の高い契約相手に関する
情報を提供できる。このように、ビジネス・ユニットは各法的主体に対しレベル
Ａ、Ｂ、Ｃの１つを割り当てることができる。これは基本的に、ユーザーに対す
る信用価値の高速参照である。

【０１２２】 Ｓ＆ＰおよびＭｏｏｄｙを表記された列１９８は、信用プリファレンス・イン
タフェース１７０に集積された産業信用格付けである。産業信用格付けは、外部
通信インタフェース・リンク・インタフェース６２（図２）を介して加入ベース
でダウンロードできる。最後に、最後に変更された列および列による変更事項は
、最後に変更された設置の時間および個人を識別する。前述のように、信用プリ
ファレンスのどれかを変更するためのアクセスは、金融担当者または法的主体の
信用担当者に対して制限されるべきである。

【０１２３】 信用プリファレンス設定は、電子ファイル転送または手動入力により、ユーザ
ーが望む回数だけ、いつでもオンラインで転送できる。さらに更新は、すべての
信用グループおよび法的主体に対して実現でき、またはこれとは別に、更新は個
々の設定にするようにもできる。

【０１２４】 さらに、信用プリファレンス・インタフェース１７２は、ＢＵ Ｉｎｆボタン
２０２を備えており、このボタンが選択されると、図１０に示すビジネス・ユニ
ット・データ・インタフェース２０４が表示される。ビジネス・ユニット・デー
タ・インタフェース２０４により、ユーザーは他の法的主体に関する有用な内部
情報を見ることができる。それぞれのビジネス・ユニットは、どの情報をビジネ
ス・ユニット・データ・インタフェースに含むかを定義する。例えば、図１０の
ビジネス・ユニット・データ・インタフェース２０４は内部機能番号、電話番号
、内部参照番号、内部正味ＭＴＭ、内部全体ＭＴＭ、およびビジネス・ユニット
の内部扱い番号を備える。また別に、ビジネス・ユニットは契約名または他のビ
ジネス・ユニット特有データを含む。

【０１２５】 したがって、本発明の信用プリファレンス論理は、図１１の図のように表すこ
とができる。図１１の目的に対し、ビジネス・ユニット（ｉ）は法的主体（ｉ）
（ここでｉ＝１、２、３）に属し、ビジネス主体（ｊ）はＬＥ（ｊ（ここでｉ＝
１、２および３）に属する。したがって図１１は、本発明の信用プリファレンス
機能を実現するためにシステム１０により格納された信用データの一部を示す。
各列は、すべての信用グループ全体に渡り各法的主体に対する各ビジネス・ユニ
ットについて匿名で格納された信用プリファレンス（すなわち、バイナリ、ライ
ン・バイナリ、または複合）を表す。垂直および水平バー２１０は、ビジネス・
ユニット（３）がオーダーの信用プリファレンス状態を決定するのに必要な情報
を表す。列内２１０の情報は、ビジネス・ユニット（３）が他のすべての法的主
体に対して設定した信用プリファレンスを備え、また行２１１は他のすべてのビ
ジネス・ユニットがビジネス・ユニット（３）の法的主体、つまり法的主体（３
）に対して設定した信用プリファレンスを備える。図の奥行き２１６は、スイッ
チ、デリバティブ、外国為替のような別々の信用グループに分割される。

【０１２６】 三角形２１２、２１４は、ビジネス・ユニット（３）により使用される情報を
含むセルを示しており、そのビジネス・ユニット（３）が、信用状態情報を用い
て法的主体（５）のビジネス・ユニット（５）から特定オーダーを符号化し、本
明細書で述べる１つまたは複数のインタフェースを介してユーザーに示す。好ま
しい実施形態では、本発明の信用プリファレンス機能は、表示しているビジネス
・ユニットのそれぞれから各オーダーに信用プリファレンスをカラー・コード化
する。また、オーダーの信用プリファレンス状態を符号化する別の方法が、ユー
ザーがカラーを望まない場合には、オーダーに対しアスタリスクまたはスターの
ような文字表記法を追加することを含む。

【０１２７】 各オーダーは三角形２１２で示された信用プリファレンスに従ってカラー・コ
ード化される。この三角形２１２は、オーダー発行のビジネス・ユニットがビジ
ネス・ユニット（３）の法的主体に対し設定したものに対応し、また三角形２１
４は、ビジネス・ユニット（３）がオーダー発行の法的主体に対し設定したもの
に対応する。オーダーは、三角形２１２、２１４で示されたセル内で定義された
信用プリファレンスに従って評価され、その結果を以下に記載するカラー・コー
ド化方式によりユーザーに表示できる。以下の記載では、「真」はオーダーが設
定当事者の信用プリファレンスに合格すること意味し、「偽」はオーダーが設定
当事者の信用プリファレンスに不合格を意味する。

【０１２８】 三角形２１２ 三角形２１４ カラー 偽 偽 赤 偽 真 黄 真 偽 赤 真 真 緑

【０１２９】 したがって、各オーダーはカラー・コード化されて、ユーザーに、両方のユー
ザーのプリファレンスに基づき市場内での付値および売値の取引可能性を伝達す
る。ここで述べるカラー・コード化方法は、市場エントリ・インタフェース（図
１２に関して以下の述べる）と、市場詳細インタフェース（（図１５に関して以
下の述べる）との両方に使用される。本発明の実施形態に対し、以下の意味が引
用されたカラーに関連付けされている。

【０１３０】 緑：価格は両方の当事者の信用プリファレンスに合格し、契約相手は自由に取
引できる。緑で示されるすべての取引はトレーダーにより自由に取引でき、信用
承認は適切であると予測される。

【０１３１】 黄：登録された価格は閲覧者により自由に取引できるが、価格の登録者は、登
録者の信用プリファレンスから閲覧者を除外している。価格が黄色である場合、
取引を可能にできるのは、受動オーダーを発行した当事者は相互のプットを許可
し、また以下の述べる信用無効化プロセスが完了している場合である。閲覧者は
、閲覧者の名前および／または識別名、および閲覧者により入力された相互のプ
ット満期日を開示している価格の登録者にメッセージを送り（それにより信用無
効化プロセスを開始する）取引することを意図することができる。次に登録者は
受け入れるか、信用に対する主題を受け入れる（どちらの場合も、登録者は相互
のプット満期日を短縮できる）か、または拒絶する機会を持つ。登録者名は、取
引が実行されるまで閲覧者に解放される。登録された価格は、取引が完了するま
で、システム１０上の他のすべてのトレーダーに有効性を維持する。オーダーが
別の閲覧者と取引する場合、信用無効化プロセスは終了する。

【０１３２】 赤：登録された価格は、登録者が取引を明らかにする（取引する可能性がある
）場合でも、閲覧者自身のプリファレンスにより実行される。この場合、取引を
阻止する閲覧者設定が、閲覧者自身の信用プリファレンスであるため、閲覧者は
自由に取引できない。

【０１３３】 青：価格は閲覧者自身のオーダーである。

【０１３４】 白：市場エントリ・インタフェース２５０（図１２）で使用されるだけであり
、複数オーダーが異なるコードを持つ最高価格である場合の価格を表示する。し
たがって、閲覧者は、市場詳細インタフェースを閲覧してさらの情報を得るよう
に通告される。

【０１３５】 前述の無効化プロセスでは、閲覧者が売買したいカラーコード化された黄を見
ると、閲覧者が無効化プロセスを起動できる。無効化プロセスは、登録当事者に
オーダー量に対する要求を促すことで開始される。登録者に送られるメッセージ
は基本的に、メッセージ内の名前により識別される閲覧者が、定められた量を取
引することを記載し、また受け取る当事者が応答するための定められた時間期間
（例えば１５秒）を持つことを記載する。次に閲覧者は、閲覧者のメッセージの
コピーと、登録者に対して定められた時間のカウントダウンを表示する時計を見
る。登録者はメッセージを受け取り、断るかまたは受け入れる。登録者が断ると
、閲覧者は結果的に情報に通じる。登録者が受け入れると、登録者はオプション
を得て、相互プットの満期を追加し、特定数の月に提示される小幅の価格調整を
要求する。時計が動いている間（価格調整が要求されるまで）、閲覧者はその取
引から出て戻ることができない。さらに、全ステップが完了するまで、登録者が
取引に入ることはない。

【０１３６】 受動取引がカラー・コード化されるプロセスについて述べる。信用プリファレ
ンス・タイプに関係なく、トレーダーワークステーション２０は、オーダーがカ
ラー・コード化される方法を決定する最長満期日値を発生する。最長満期日値は
、長さで整数ｎ桁の形式であり、最も右の２桁は日を表し、左の（ｎ−２）桁が
月を表す。したがって、１２０００は１０年を、３６００は３６月を表し、１１
４は１月、１４日を表す。信用プリファレンスを最長満期日値に変換する方法は
、以下の表２に示す。

【０１３７】

【表２】

【０１３８】 システム１０の各商品は最長満期日値を有する。特定オーダーが取引できるか
どうかを決定するため、そのオーダーの商品に対する最長満期日が、信用プリフ
ァレンスの最長満期日と比較される。商品の最長満期日が、信用プリファレンス
の最長満期日より長い場合、そのオーダーは取引でき、そうでない場合は取引で
きない。

【０１３９】 バイナリ−Ｎｏプリファレンスで指定された最長満期日はすべての商品の最長
満期日より短かく、全商品は効果的に取引できないことに注意する必要がある。
同様に、バイナリ−Ｙｅｓプリファレンスの最長満期日は、すべての商品の最長
満期日を超える。

【０１４０】 適正なカラー・コードを決定するために、トレーダーワークステーション２０
は各商品クラスに対し２つのリストを維持する。一方のリストは閲覧者が他の法
的主体に対しその商品クラスに関して設定する信用プリファレンスを含む。この
リストはＭＹ＿ＰＲＥＦＳと呼ばれる。他方のリストは、他のすべてのビジネス
・ユニットが表示している法的主体に対しその商品クラスに関して設定する信用
プリファレンスを含む。このリストはＯＴＨＥＲ＿ＰＲＥＦＳと呼ばれる。これ
らリストの各々は以下のデータを含む。

【０１４１】 ビジネス・ユニットＩＤ（ＯＴＨＥＲ＿ＰＲＥＦＳに対してだけ使用される） 法的主体ＩＤ（ＭＹ＿ＰＲＥＦＳに対してだけ使用される） 最長満期日 信用レベル（ＭＹ＿ＰＲＥＦＳに対してだけ使用される）

【０１４２】 例えば、法的主体（１）のビジネス・ユニット（１）により発行された任意の
ＦＲＡ商品のオーダーを考える。オーダーが複数のトレーダー２０（すなわち閲
覧者）のブロードキャストされるとき、そのオーダーは以下の情報を含む。 オーダーを発行するトレーダーのビジネス・ユニット：ビジネス・ユニット（
１） オーダーを発行するトレーダーの法的主体：法的主体（１） オーダーの最長満期日：３６００（例えば）

【０１４３】 オーダーをカラー・コード化するために、表示中の当事者は、ＦＲＡ ＭＹ＿
ＰＲＥＦＳリストから法的主体（１）に対する当事者の信用プリファレンスと、
ＦＲＡ ＯＴＨＥＲ＿ＰＲＥＦＳリストから当事者に対するビジネス・ユニット
（１）のプリファレンスとを抽出および利用する必要がある。抽出した信用プリ
ファレンスから、トレーダーに現れるオーダーのカラーは、以下の表３で定義さ
れるものである。

【０１４４】

【表３】

【０１４５】 また、ＭＹ＿ＰＲＥＦＳリストは信用レベル（すなわち、オーダーに関連付け
し、閲覧者に提示できる）を含むことができることに注意する必要がある。

【０１４６】 したがって、ユーザーがシステム１０にログ・インするとき、ユーザーは、信
用プリファレンス・モジュール７６（図３）から、商品クラスに対するＭＹ＿Ｐ
ＲＥＦＳリストおよびＯＴＨＥＲ＿ＰＲＥＦＳリストにデータを入れて使用する
。これは、中央処理センター１２により達成され、前記センターは、ハード・デ
ィスク６４のデータベース（図２）から、ＭＹ＿ＰＲＥＦＳリストおよびＯＴＨ
ＥＲ＿ＰＲＥＦＳリストを含む１つまたは複数メッセージを、ログ・オンしてい
るＡトレーダーワークステーション２０に送る。

【０１４７】 ユーザーが、信用プリファレンスの最長満期日を変更できる方法で、特定信用
グループに対して法的主体に割り当てられた信用プリファレンスを変更する場合
、ユーザーは中央処理センター１２からＭＹ＿ＰＲＥＦＳの更新を受け取る。ま
た、システム１０にログ・オンしている影響を受ける法的主体内のすべてのユー
ザーは、ＯＴＨＥＲ＿ＰＲＥＦＳの更新を受け取る。複合プリファレンスの変更
は、ゼロ・バンドが変更されない限り（したがって、最長満期日を変更する）、
このような更新を必要としない。ユーザーが法的主体に関連付けされた信用レベ
ルを変更する場合、ユーザーはＭＹ＿ＰＲＥＦＳの更新を受け取る。

【０１４８】 しかしこれら２つの更新は、変更される時には実行する必要がない。なぜなら
それを実行することにより、ユーザーは、オーダーの色が変わるまで、各法的主
体に対するユーザーのプリファレンスを緑状態から赤状態に順序よく変更するこ
とにより、オーダーを発行した法的主体を決定できるからである。代わりに、必
要な更新は定期的に収集され、送り出される。また、固有の信用レベルを単一法
的主体に割り当てることによって、契約相手の身元が発見されるのを防止するた
め、各信用レベルは法的主体に割り当てないか、または複数の法的主体に割り当
てるかのどちらかにするべきである。

【０１４９】 コマンド・センター・インタフェース１３０から、ユーザーは、図１２に示す
市場エントリ・インタフェース２５０に入ることができる。市場エントリ・イン
タフェース２５０では、ユーザーは、付値および売値を含んでいる多くの市場を
同時に閲覧し、オーダーを発行できる。また市場エントリ・インタフェース２５
０により、ユーザーは表示されているすべての商品を選択でき、各種の取引機能
（例えば、１つのインタフェース上の共通ＦＲＡ、別のインタフェース上のＳＷ
ＡＰ、およびさらに別のインタフェース上のスイッチ）を持つ複数の市場エント
リ・インタフェース２５０を、トレーダーデスクトップ上に同時に開くことがで
きる。市場エントリ・インタフェース２５０の設計は、最高付値および要求の集
積と、すべての２つの当事者による取引活動とを、右上端コーナーの出来高イン
ジケータを点滅させることにより表すように設計されている。したがって、市場
エントリ・インタフェース２５０により、ユーザーは多くの異なる市場を容易に
便利に閲覧できる。システム１０はオーダーの自動マッチングを実行できないが
、このシステムによりユーザーは常時取引プロセスの制御が可能になる。システ
ム１０は、能動および受動オーダーの概念を導入して、これを実現している。受
動オーダーは、システム１０内で、特定商品に対し、特定価格で、特定時間期間
に対して発行されたオーダーである（下のオーダー・タイプを参照）。能動オー
ダーは、ユーザーがシステム１０で表示された受動オーダーの取引を決定する時
であり、通常は量を定めていることだけを必要とする。このように、能動および
受動付値および売値が可能になる。

【０１５０】 ユーザーは、商品表示ウィンドウ２５２に表示された商品（すなわち市場）を
追加および削除することにより、市場エントリ・インタフェース２５０をカスタ
マイズできる。ユーザーは、商品識別名フィールド２５４に商品記号を入力する
ことにより（本発明の記号方式に従って）、新しい市場を追加できる。ユーザー
は商品のグループを定義して、プロファイルとして保存して一緒に表示できるこ
とを希望することもある。プロファイルにより、ユーザーは、同一属性により複
数市場を整理できる。表示されるプロファイルはプロファイル表示フィールド２
５６内に表示される。プロファイル表示フィールド２５６は、ユーザーにより定
義された他のプロファイルを一覧表示するプル・ダウン・メニューである。ユー
ザーが最初のプロファイルを定義するまで、プロファイル表示フィールド２５６
はデフォルトに設定されている。

【０１５１】 商品表示ウィンドウ２５２に表示された個々の市場は、４つの列、ｉｎｓｔｒ
ｕｍｅｎｔ（商品）、ｂｅｓｔ ｂｉｄ（最高付値）、ｂｅｓｔ ａｓｋ（最高
売値）、およびｉｎｆｏに分割される。商品列は商品名（すなわち、記号、別名
またはセキュリティ識別名）を表示する。最高付値列は、本明細書では最高価格
であるオーダーとして定義される、最高付値情報を表示する。最高付値情報は少
なくとも２桁の有効数字の価格を表示する比較的大きい中心数と、少なくとも２
桁の有効数字の価格以外の全部を表示する左下の数と、現在の取引のすべての出
来高または量を表示する右下の数と、現在の数量を百万単位で表示する右上の数
とを含む。希望する精度に応じて、さらに大きいまたは小さい桁の数を、大きい
中心数で表示できる。表示される中心数の精度は各商品に対して定義され、例え
ば２、３、４またはそれ以上の桁を備えることができる。最高売値列は最高付値
のフォーマットとほぼ同一であるが、最高付値でなく最高売値を表示する。ｉｎ
ｆｏ列は、インフォウィンドウ２５８で定義されるような、ユーザーが選択して
表示できるデータ項目用の空白を有する。本発明の実施形態では、インフォウィ
ンドウ２５８内で３つの項目が定義され、したがって商品に対応する情報はｉｎ
ｆｏ列に一覧表示される。

【０１５２】 システム１０は、ユーザーに、図１３に示す記号形成インタフェース２７０を
提供する。このインタフェース２７０には、市場エントリ・スクリーン２５０か
らＬｏｏｋｕｐボタン２７２によりアクセスできる。記号形成インタフェース２
７０に機能は、商品表示ウィンドウ２５２の表示に対して商品を選択する場合に
ユーザーを支援することである。記号形成インタフェース２７０から、ユーザー
はウィンドウ２７３内の利用可能な別名を見て、Ｅｘｐｌｏｄｅ Ｓｙｍｂｏｌ
（記号分解）ボタン２７４により記号（すなわち、記号に関連付けされた基本パ
ラメータのリスト、例えば支払日）を分解し、Ａｄｄ ｔｏ Ｐｒｏｆｉｌｅ（
プロファイルに追加）ボタン２７６によりプロファイルに追加される記号を選択
し、Ｂｕｉｌｄ Ｓｙｍｂｏｌ（記号形成）ボタン２７８により新しい記号また
は別名を形成できる。記号形成インタフェース２７０はまたエラー・チェック機
能を備えて、確認された記号だけを選択できるようにしている。データベース内
には確認された商品を格納するが、必ずしもすべての組み合わせを格納する必要
はない。追加確認のため、Ｅｘｐｌｏｄｅ Ｓｙｍｂｏｌ（記号分解）ボタン２
７４の記号分解機能により、基本的に、商品の全態様を詳細に表示できる。した
がって、記号分解機能はＳｙｍｂｏｌ（記号）ウィンドウ２８０の完全な詳細内
容を提供する。

【０１５３】 また記号形成インタフェース２７０スクリーンにより、ユーザーは記号のグル
ープを探索できる。この探索を実行するには、Ｓｅａｒｃｈ Ｏｐｔｉｏｎ（探
索オプション）ボタン２８４の上方の入力パラメータ２８２を少なくとも部分的
に書き込み、次にＳｅａｒｃｈ Ｏｐｔｉｏｎ（探索オプション）ボタン２８４
を選択する。入力パラメータ２８２は、売買の後に、交渉しできる商品の各種の
非商用条件を含む。例えば、図１３に示すように、入力パラメータ２８２は商品
のクラス、通貨、開始月、終了月、延滞、ＦＬＯＰ、および特殊規則を含む。こ
れらパラメータを少なくとも部分的に書き込むことにより、ユーザーはウィンド
ウ２８０に表示される同様な商品を探索できる。

【０１５４】 図１２の市場エントリ・インタフェースに戻り説明する。最高付値および最高
売値列に表示される価格は、前述のカラー方式を使用して、信用情報で符号化さ
れる。前述のように、カラー・ブラインド・ユーザーは、記号方式で置き換えら
れたカラー・コード化方式を得ることができ、このコード方式では、異なる記号
はオーダーの信用状態を示すそれぞれの価格の隣に配置される。記号方式は、プ
リファレンス・インタフェース１４８（図６Ｂ参照）のＥｎｖｉｒｏｎｍｅｎｔ
（環境）タブによりユーザーが選択できる。

【０１５５】 現在、本発明の発明者らは、すべての電子取引システムが、本明細書に開示す
るカラー・ベースの信用プリファレンスの事前スクリーニングを提供することを
意識していない。本発明はカラー・ベースの信用プリファレンスの事前スクリー
ニングを備えるが、この理由は、最高の取引可能価格または最適最小数量を発生
するだけの従来技術のシステムと異なり、本発明が、それらの信用プリファレン
スに関係なく、すべての価格（付値および売値）を示すからである。したがって
ユーザーには、ユーザーが希望する限りの広範囲の市場表示を提供できる。有利
にはカラー・コード化により、ユーザーは、トレーダーおよび契約相手の信用プ
リファレンスを基にして、どの付値および売値が取引できるかを目視により実質
的に瞬時に決定できる。

【０１５６】 ユーザーが、記号方式により市場エントリ・インタフェース２５０に希望する
金融商品を入力すると、希望する商品の各々の最高付値および売値が商品表示ウ
ィンドウ２５２に表示される。ウィンドウ２５２に表示される最高付値および最
高売値の価格は、多くの従来システムと異なる（従来システムのそれら価格は、
一定数量における絶対的最高付値および最高売値である）。特有のカラー・コー
ド化方式のため、ユーザーは、付値または売値が取引可能かどうかを即座に知ら
せることができる。ユーザーが希望する場合には、ユーザーは、マウスのような
ポインティング・デバイス８６（図３）を用いて金融商品を選択し、商品表示ウ
ィンドウ２５２内のその商品の行を強調表示できる。金融商品が強調表示される
と、ユーザーは、機能バー２９０により提供されているいくつかの機能の１つを
実行できる。前記機能の各々を以下に記載する。

【０１５７】 ＥＸＰＬ機能：これは商品記号を契約の完全内容に分解して、確認する。 ＨＩＴ、ＬＩＦＴ、ＯＲＤ機能：これら３つのボタンにより、ユーザーは、希
望するそれぞれの付値または売値をヒットするかリフトすることにより、商品を
選択して新しいオーダーを発行するか、または能動オーダーを実行できる。ＨＩ
Ｔ、ＬＩＦＴ、ＯＲＤ機能はまた、スクリーンでマウスをダブル・クリックして
実行できる。

【０１５８】 ＲＥＰ機能：価格に対する要求メッセージは、市場と通信する重要なツールで
ある。トレーダーが市場を見ることを望む場合、ブローカーは電話を介して連絡
を取り、また逆に他のトレーダーに電話して、商品を売り込む。本発明のシステ
ム１０を使用して、ＲＦＰを登録されたユーザーに送ることにより、瞬時に同一
結果を得ることができる。このメッセージは、別のユーザーのコマンド・センタ
ー・インタフェース１３０に表示して、指定された商品のＲＦＰのメッセージ通
知できる。さらに、デリバティブトレーダーが複数の金融商品を、ときには複数
の通貨で取引することが多いため、デリバティブトレーダーは複数の受動オーダ
ーを持つことが多い。本発明は、オーダーを取消しまたは一時的に停止するのに
役立つ、少なくとも３つのオーダー管理機能を備える。これは、市場が急激に変
動するとき、またはトレーダーのポジションが突然変化する場合に重要な機能で
ある。

【０１５９】 ＸＬＳＴ機能：この機能は、トレーダーの発行した最後の受動オーダーを取り
消す。したがって、ユーザーがオーダーを発行し、直ちにその決定を変更する場
合、オーダーを個々に選択することなく、オーダーを取り消しできる。

【０１６０】 ＸＡＬＬ機能：この機能により、ユーザーは１回のキー操作で未処理の受動オ
ーダーを取り消しできる。

【０１６１】 ＲＥＦ機能：この機能により、ユーザーは全オーダーを一時停止または参照状
態に置くことができる。この機能により、別の方法で、オーダーを１つずつ取り
消しできる。例えば、ユーザーが少数の未処理オーダーだけに影響を与える可能
性のあるニュースを期待する場合、全オーダーを参照状態に置き、トレーダーが
影響を与えずに市場に戻すことを期待するオーダーを、個々に再解放することは
より安全である。

【０１６２】 ＤＥＬ機能：この機能により、ユーザーはプロファイルから市場を削除できる
。 機能バー２９０のＯＲＤボタンに関しては、ユーザーは、ＯＲＤボタンを選択
して受動オーダーを発行できる。ＯＲＤボタンが選択されると、図１４に示す受
動オーダー・インタフェース２９４がユーザーに提供される。受動オーダー・イ
ンタフェース２９４から、ユーザーは受動オーダーを付値（すなわち、買い）ま
たは売値（すなわち、売り）のような受動オーダーを発行できる。ユーザーは価
格および数量を入力し、オーダーの有効期間を選択する。価格のデフォルト値は
現在の市場レベルになり、その結果ユーザーは価格の最後の２桁を入力するだけ
でよい。数量に対しては、システム１０は千、百万および１０億のそれぞれに対
し、ｍ、ｍｍおよびｂと認識する。システム１０には、ｇｏｏｄ ｕｎｔｉｌ
ｏｐｔｉｏｎで、以下のオーダー・タイプを問題なく入力できる。 ｇｏｏｄ ｕｎｔｉｌ ｌｏｇｏｕｔ（デフォルト）−ユーザーに、ログ・オ
ンおよびオーダー状態を見るように要求する。 ｇｏｏｄ ｕｎｔｉｌ ｔｉｍｅ−ユーザーは時間を入力するように催促され
る（ユーザー自身の時間ゾーン）。このオーダーはユーザーにログ・することを
要求せず、適切な時間にシステム１０により自動的に取り消しされる。 ｇｏｏｄ ｕｎｔｉｌ ｃａｎｃｅｌｄ−このオーダーはユーザーに、再度ロ
グ・オンするように要求しないが、ユーザーにより取り消しされる必要がある。

【０１６３】 システムは、すべての新しいオーダーの発行時に、そのオーダーを適正に検査
（または「構成」）する。例えば、付値は、ユーザーの二重検査なしに、既存の
売値より高くできない。タブ・キー、エンター・キー、またはマウスを使用して
、受動オーダー・インタフェース２９４内を移動できる。ＯＫボタンを選択する
と、オーダーはシステム１０に登録され、ユーザーは市場エントリ・インタフェ
ース２５０に戻る。

【０１６４】 機能バー２９０のＨＩＴおよびＬＩＦＴボタンに関しては、ユーザーは、付値
（すなわち、買い）をヒットするか、または売値（すなわち、売り）をリフトし
て、能動オーダーを起動できる。ＨＩＴまたはＬＩＦＴボタンどちらかを選択す
ることにより、ヒット・オーダー・ウィンドウまたはリフト・オーダー・ウィン
ドウがユーザーに提示される。例えば、ヒット・オーダー・ウィンドウ２９６は
図１４Ｂに示される。ヒット・オーダー・ウィンドウ２９６はリフト・オーダー
・ウィンドウとほぼ同一である。図のように、ヒット・オーダー・ウィンドウ２
９６は商品およびオーダー価格を識別する。さらにユーザーは、最初に契約相手
により提供された全量に設定された売買数量の提示を受ける。ユーザーは数量値
を減少することができる。ユーザーがこの時点で数量値を減少できない理由は、
契約相手がすでに売りを望む数量を指示しているからである。ＯＫボタンを選択
すると、オーダーは以下の方法でシステムにより実行され、ユーザーは市場エン
トリ・インタフェース２５０に戻る。

【０１６５】 機能バー２９０により提供される前述の機能に加えて、ユーザーが、特定商品
に関する特定市場の完全な深さと気配を知りたいと望む場合、ユーザーは商品表
示ウィンドウ２５２内の商品を選択（すなわち、強調表示）し、次にＭＤＳボタ
ン２９２をクリックすればよい。これにより、強調表示された商品に対する、図
１５に示す市場詳細インタフェース３０２が起動される。

【０１６６】 市場詳細インタフェース３０２により、トレーダーは基本的に、特定商品に対
する市場の全商品、付値および売値の両方を見ることができる。付値オーダーは
、付値ウィンドウ３０４内に表示され、そこには信用レベル（すなわち、Ａ、Ｂ
またはＣ）、付値数量および付値の価格が示される。売値オーダーは売値ウィン
ドウ３０６に表示され、そこには売値の価格、売値数量および信用レベルが示さ
れる。市場エントリ・インタフェース２５０と同様に、オーダーは適正な信用プ
リファレンスを用いてカラー・コード化される。これは、最高取引価格または混
合価格を示すだけの多くの従来システムと大きく異なる。

【０１６７】 市場詳細インタフェース３０２では、オーダーは、付値ウィンドウ３０４また
は売値ウィンドウ３０６に個別に、価格順およびオーダーが市場に入った時刻に
おうじて表示される。ユーザーはスクリーン上のすべてのオーダーを選択し、そ
のオーダーをヒットまたはリフトする能力を有する、ただしそれぞれの信用プリ
ファレンスが取引を許可することを前提とする。ユーザーは、機能バー２９０と
ほぼ同一の機能バー３０８を提供される。詳細には、機能バー３０８のボタンは
機能バー２９０のボタンとほぼ同一である。ただし、前者のボタンが特定の商品
だけに適合するのに対して、機能バー２９０のボタンは複数商品に対し適合する
。さらに、公正価格インジケータ、スポット／設定インジケータ（すなわち、そ
の日のＬＩＢＯＲ）、および最後の取引価格インジケータが、付値ウィンドウ３
０４および売値ウィンドウ３０６の下部に沿って備えられている。最後の取引価
格は、出来高、期間、ＲＱ、最終終値等で置き換えられる。

【０１６８】 市場詳細インタフェース３０２の利点は、ユーザーが、最高価格または第１オ
ーダーだけで取引することに制限されないことである。すべてのオーダーがシス
テム１０により自動的にマッチングされる、プロセス内の点は存在しない。ユー
ザーは完全な制御のオーダー・フロー・プロセス内にある。

【０１６９】 このように、ユーザーは、市場詳細インタフェース３０２または市場エントリ
・インタフェース２５０のどちらからでも、受動および能動オーダーの両方を実
行できる。どちらかのインタフェース２５０、３０２では、ユーザーが取引を望
む場合、ユーザーは、希望する付値または売値を強調表示し、それぞれの機能バ
ー２９０、３０８から対応する機能ボタンを選択して売買を起動するだけでよい
。オーダーを発行、変更、取り消しの意味は、それぞれ、比較的複雑であるが、
システム１０で可能な場合にはユーザーはこの複雑性から遮蔽される。

【０１７０】 システム１０に入力された各オーダーは、受け取られた価格および時間に基づ
いて待ち行列内に置かれる。オーダーの変更は、待ち行列内のオーダーポジショ
ンに影響を与えるか、または与えないことがある。価格の変更はすべて、価格レ
ベルに応じて、待ち行列内でオーダーを上下に移動させる。オーダーの出来高の
減少はどれも、待ち行列内のオーダーポジションに影響を与えない。出来高の減
少はどれも、結果的にその場所に保持する以前の数量となり、バランスを取るた
めに新しいオーダーが置かれる。

【０１７１】 効果的な電子取引は、直感的に理解でき、高速で高信頼性でなければならない
。これを促進するために、本発明はユーザー効率を最大にするように設計されて
いる。システム１０により、ユーザーは、入力デバイス８６を用いて市場エント
リ・インタフェース２５０または市場詳細インタフェース３０２のどちらからで
も受動オーダーを発行できる。例えば、ユーザーは商品名をダブル・クリックす
るか、機能バー２９０、３０８のＯＲＤボタンを選択して、受動オーダー・イン
タフェース２９４を起動できる。

【０１７２】 オーダーが発行されると、ユーザーが商品に対し現在の予約（すなわち、フィ
ールド設定）を有する場合には、他のユーザーの市場エントリ・インタフェース
２５０および市場詳細インタフェース３０２に対して、直ちに更新がなされる。

【０１７３】 ユーザーの未処理の（または、オープン）受動オーダーの状態を閲覧するため
、およびそれらオーダーを即座に調整するために、本発明は、図１６に示す未処
理オーダー・ブロッター３２０として公知の装備を有する。未処理オーダー・ブ
ロッター３２０は全未処理受動オーダーを収集し、ユーザーに、取引、記号、お
よびオーダーのタイプを確認する能力を与える。さらに、未処理オーダー・ブロ
ッター３２０により、ユーザーは、価格、数量、またはオーダーが選択されたと
きに現れるドロップ・ダウン・メニューによりｇｏｏｄ ｕｎｔｉｌ ｓｔａｔ
ｕｓを即座に変更できる。未処理オーダー・ブロッター３２０から、ユーザーは
新しいオーダーを発行および／または市場の特定オーダーを取り消しすることも
できる。したがって、未処理オーダー・ブロッター３２０は、ユーザーに、単一
インタフェースから市場の現在のユーザーの受動オーダーを管理する能力を与え
る。市場エントリ・インタフェース２５０および市場詳細インタフェース３０２
と同様に、ユーザーは、未処理オーダー・ブロッター３２０により、全取消し、
最終取消し、および全機能参照を提供される。これは、多くの従来システムに勝
る大きい利点である。その利点は、システム１０がすべての現在の受動オーダー
を追跡できるだけでなく、ユーザーが、市場エントリ・インタフェース２５０ま
たは市場詳細インタフェース３０２に戻ることなく、未処理オーダー・ブロッタ
ー３２０から受動オーダーを変更、追加または削除できることである。

【０１７４】 実行または取消しされたオーダーに対し、ユーザーは、図１７に示すクライア
ント・モニター３３０を提供される。クライアント・モニター３３０から、ユー
ザーは完了または取り消しされた取引にアクセスできる。したがって、クライア
ント・モニター３３０により、ユーザーは、どのオーダーが実行または取り消し
されたかを即座に見ることも、また、時間を戻して、前日の取引を見ることもで
きる。好ましく、売買履歴は、クライアント・モニター３３０により１月間有効
である。

【０１７５】 未処理オーダー・ブロッター３２０およびクライアント・モニター３３０によ
り、ユーザーは、自身の多様な取引活動を管理できる。どちらかのブロッターか
ら、ユーザーはオーダーの状態、および実行されたまたは取り消しされた取引を
見ることができる。未処理オーダー・ブロッター３２０およびクライアント・モ
ニター３３０の両方は、コマンド・センター・インタフェース１３０からアクセ
スできる。さらに、ブロッター３２０およびモニター３３０は、ユーザーが他の
インタフェースの１つを介してオーダーを発行する場合、自動的に更新される。

【０１７６】 システム１０により、機能バー２９０、３０８上のＨＩＴおよびＬＩＦＴボタ
ンを介して、能動オーダー（すなわち、トレーダーが受動オーダーをヒットまた
はリフトする場合のそれら）を市場エントリ・インタフェース２５０または市場
詳細インタフェース３０２のどちらからでも発行できる。システム１０は従来の
多くのシステムと異なり、２つの受動オーダーが相互に自動的に実行されない。
能動ユーザーからの能動オーダーは実行のために必要とされる。さらに各取引に
対し、１つの能動および受動ユーザーが存在する。これは、選択（付値がオーダ
ーに等しい場合）を意味するか、または対等の受け渡し延期（付値がオーダーよ
り高い場合）市場が可能である。したがって、システム１０で完了する売買では
、受動オーダーに対してアクションを起こす必要がある。

【０１７７】 能動オーダーがシステム１０内で発行されると。実行プロセスが完了する。図
１８に示す実行通知メッセージ３４０が、両方の契約相手に送られ、売買を記述
し、契約相手の名前を開示する。これは、契約相手が相互に識別される売買内の
第１ポジションである。システム１０は、取引が最終的に完成する前に、両方の
ユーザーがメッセージを受け取ることを保証する。これは、どちらかのユーザー
からの任意の形式のアクションを必要とせず、各トレーダーの市場情報モジュー
ル７４（図３）がそれぞれのユーザーに対して応答する。この確認により、この
プロセス中にコネクションが切断された場合にも、ユーザーが認識されないポジ
ションにならないことを保証する。

【０１７８】 システム１０の設計では、ユーザーが、取り消しされたかまたは無効な受動オ
ーダーを実行できないように保証している。これは、すべての取引中の契約相手
間のコネクションが常時生きた状態であることを確認する検査によりなされる。
コネクションが切断または破壊された場合、システム１０へのコネクションが切
断されたユーザーからのすべての取引は自動的に一時停止される。実行の後で、
クライアント・モニター３３０はその売買で更新される。

【０１７９】 実行通知メッセージ３４０（図１８）は、最初の取引が実行完了すると、ユー
ザーに取引数量を増加する機会を提供する。ユーザーの１人が、初期数量への追
加数量を表す「さらに続行する」フィールド３４２に数量を入力できる。この機
能の設計は、大きい取引数量を有するユーザーが、最初は小さい部分の受動オー
ダーを発行できるように設計されている。ユーザーは、大量の売買を有するとき
、オーダー数量を増加する能力を望むことが多い。これは、市場参加者がこのよ
うな大きいオーダーから引き下がる時に、市場での大きいオーダーが市場価格を
逆方向に移動させる傾向が多いからである。小さい数量の初期の売買が実行され
た後に、売買量を増加するために、システム１０を介する匿名対話を行う受動オ
ーダーに対する能力は、システム１０と従来の多くのシステムとの追加の差であ
る。動作において、数量が「さらに多くの取引を実行する」フィールド３４２に
入力され、Ｓｕｂｍｉｔ（提出）ボタン３４４が選択されると、契約相手は数量
増加の要求を提供される。契約相手は、増加の要求に応答するための不連続の時
間期間を与えられる、その後その要求は無効になる。契約相手がそれ以上の取引
を望む場合、契約相手は要求された数量を受け取るか、Ｒｅｊｅｃｔ（拒絶）ボ
タン３４６を選択して拒絶できる。または契約相手は異なる数量を要求し、その
数量を、応答するための不連続時間期間を有するユーザーに戻して提示すること
ができる。契約相手は提示を変更して、追加数量が同意されるかまたはそれ以上
続行しない決定がなされるまで、相手が希望する数倍の数量に増加できる。

【０１８０】 好ましくはこの機能は、能動オーダーが現在の最高価格の全市場サイズをクリ
アする場合だけ、有効である。この場合、一方の当事者は、それ以上を実行する
ように要求することができる。「さらに多くの取引を実行する」機能により、契
約相手はサイズ（取引量）を増加できるが、価格は高くできない。好ましくは、
価格は影響を受けない。このプロセスは、かなり長時間進行と後退を実行でき、
「この数量で取引する」が完全に受け取られるまで続行できる（すなわち複数回
発生する）。両方の当事者間で完了すると、システムは、すべての「より大きい
数量で取引する」を結合し、初期価格で増加した総量に対し１つだけの売買チケ
ットを作成する。

【０１８１】 取引の実行後、システム１０により、当事者は取引の非商用条件を交渉できる
。このプロセスは条件交渉と呼ばれ、図１９に示す交渉ウィンドウ３５０を通し
て効果的に実行される。事項交渉プロセスは、それにより取引の両方の当事者が
売買の非商用条件を交渉する能力を有するプロセスである。価格、数量等のよう
な商用条件の他に、デリバティブ売買は取引価格に影響しない非商用条件も有す
る。デフォルト値が存在する一方でが、当事者はこれら事項を交渉することを望
むことがある。取引が実行されると、システム１０は当事者にインタフェース３
５０を介して交渉するオプションを提供する。しかし、当事者がそれ他に完了す
べき他のさらに重要なタスクがあるときは、システムは当事者にこのプロセスを
即座に完了することを強要しない。しかし交渉は適正な時間内に完了すべきであ
る。能動当事者（すなわち、オーダーをヒットまたはリフトしたトレーダー）は
、交渉される事項３５２、訂正可能な（テキスト・フィールドによってなど）現
在値３５４、およびシステムで予め定義されたデフォルト値３５６を提示される
。トレーダーは、選択ボタン３５８によりシステム・デフォルト値を受け取るか
、またはトレーダーが望む値を入力して、提出ボタン３６０を選択することがで
きる。これらの値は、同様に望む値を受け取りまたは入力できる受動トレーダー
（すなわちシステムで最初にオーダーを発行するトレーダー）に送られる。同意
に達しない場合、デフォルト値が使用される。これら交渉の状態は図１７のクラ
イアント・モニター３３０に表示される。

【０１８２】 取引が実行され、非商用条件交渉がなされると、取引確定が両方のビジネス・
ユニットの決済関係部門に自動的にファックスで送られるのが望ましい。システ
ム１０はまた、ファイル転送を、ｅ−メール、または任意の他の通信手段を介し
て、この確定を送ることができる。好ましくは取引確定には、取引される数量ま
たは出来高、取引された金融製品の識別名、価格、実行が記録される日付および
時間、およびその売買を固有に識別する決済ＩＤを含む。しかし、必要に応じて
、売買の特性、タイプおよび主題に関するさまざまな他のパラメータおよび売買
データを含むことができるのは当然である。

【０１８３】 本明細書に述べる対話式取引機能に加えて、システム１０はトレーダーに、金
利スワップ・ディーラに特有のリスク管理問題を処理するための取引方法を提供
する。特に、最近数年間に渡り、金利スワップ・ディーラの結果として新しい市
場が出現してきており、それら市場では、ディーラの成長する金利スワップ・ポ
ートフォリオに関する金利変化に関連するリスクを正しく管理する必要がある。
これら市場の競争が激化するにともない、付値−売値値開きが大幅に狭くなって
いる。この要素は、為替取引ユーロ・ダラー契約と組み合わさって、費用の大き
い次善の、短期間リスクを防止する為替取引契約の利用に寄与する。結果的にス
イッチが形成された。スイッチは、簡単には、類似の先物相場契約のペアの同時
の買いおよび売りである。この商品、およびデリバティブ・ポートフォリオ・リ
スク管理のペアの相互相殺の必要性が、金利スワップの大きいポートフォリオに
対し改良されたリスク管理ツールを実現している。明らかな利点およびリスク管
理からの需要にもかかわらず、売買完成の複雑性および時間消費特性の結果とし
て、スイッチ市場の成長は比較的遅い。この理由は、リスク管理者が、自身のポ
ートフォリオの正確な特性およびサイズを開示するのに極めて慎重であることで
ある。したがって反対の必要性を有する契約相手を見出すのが困難な場合が多い
。

【０１８４】 一般にディーラはファックスを備える。そのファックスにはディーラが売買す
る日は記載されているが、どの所定の日の数量または重要事項も記載されていな
い。ディーラはリストを、他の会社の他のリスク管理者またはボイス・ブローカ
に送る。不完全な情報のこの付値から、売買は実質的に交渉される。スイッチを
見出すことは非常に重要であるが、それは、新しい実行または大きい明らかな市
場リスクの防止などのような、他のさらに急ぐタスクに比較して緊急ではない。
結果的に、一方側に大きく重り付けされ、完全ではないが別のポジションにマッ
チングするポジションに焦点を合わせる時間はあまり正確でない。ボイス・ブロ
ーカは、これを、複数ファックスをマッチングすることで解決しようと試みてい
た、しかし、これは解決には至らない。

【０１８５】 本発明はこれらの努力の及ばないいくつかのステップを実現し、考慮に入れる
トレーダーの信用プリファレンスとのマッチングを実現する。システム１０はす
べてのマッチング・プロセスにおいて公正性を示す。ポートフォリオが非常に大
きく、それにより各リスク管理者がそのポートフォリオの寿命を超える各日にポ
ジションを有し、その結果の組み合わせは大きくなるはずである。この規則、制
約および優先度は、好ましくは、市場参加者に対してユーザー間の実行の公正性
を示す方法で構成される。

【０１８６】 他者による公知の試みとの大きな差異では、本発明は、スイッチ・エンジンと
呼ばれる匿名ポジション発見システムにより、トレーダーにスイッチ取引の複雑
性のソリューションを提供する。スイッチ・エンジンの目的は、リスク管理者が
プロセスの制御を見失うことなく、匿名スイッチ売買を即座に効率的に実行でき
るツールをリスク管理者の手元に置くことである。スイッチ・エンジンは、これ
を達成するために、トレーダーの手動入力のトレーダーポジション（すなわち、
金利リスク・ポートフォリオ）を、図２０に示すように、最大１８０日または将
来的にそれ以上の間の可変金利指標および通貨を使用して、ポートフォリオ・イ
ンタフェース３８０を介してスイッチ・モジュール８０（図３）内に入れること
により達成する。ポートフォリオが入力されると、ユーザーは、Ａｐｐｌｙ（適
用）ボタン３８１を選択してそれの正確さを確認する必要があり、その後そのポ
ジションを中央処理センター１２（図２）のスイッチ・メカニズム３５内で使用
できる。

【０１８７】 さらに、システム１０は、電子的転送または特定の他の適当な方式のデータ転
送を介してポジションデータを受け取るように構成できる。これには、ユーザー
自身のリスク管理システムからの直接転送を含む。トレーダーワークステーショ
ン２０によっては、この方法でポートフォリオを受け取るのに特定のカスタマイ
ズを必要とすることがあるが、システム１０はこの機能をサポートしている。ス
イッチポジションの特性、特に近い期間（各指標の満期日の外に定義され）では
、比較的安定し、したがって、大部分のトレーダーに対しては、ユーザーによる
ポートフォリオのオンライン・エントリが適切である。次に、入力されたポート
フォリオ・データはトレーダーワークステーション２０から中央処理センター１
２のスイッチ・メカニズム３５に送られる。

【０１８８】 図２０のポートフォリオ・インタフェース３８０では、ポートフォリオが「入
力される」列３８２にすでに入力されているため、「入力される」列３８２はユ
ーザーにより入力されるポートフォリオを示し、「取引される」列３８４はユー
ザーにより取引される累積数量を示す。「正味」列３８６は、入力されたポート
フォリオおよび列３８４内の取引される数量を与えられるユーザーのリアルタイ
ムのポジションである。ユーザーは任意の時間に再開始できるが、この再開始は
、Ｒｏｌｌ（移動）ボタン３８８を選択するか、またはＣｌｅａｒ（クリア）ボ
タン３８９を選択して全ポジションをクリアすることにより、正味列３８６内の
正味のポジションを入力列３８２に移動させることでなされる。

【０１８９】 ポジションをシステム１０に入力すると、図２１に示すスイッチ・インタフェ
ース４００は、それぞれのトレーダーワークステーション２０に入力され、スイ
ッチ・メカニズム３５にアップロードされた他のトレーダーからのトレーダーの
ポジションデータを使用して、スイッチ・モジュール８０により生成される。ス
イッチ・インタフェース４００により、ユーザーは市場を探索し、トレーダーの
ポートフォリオの見込みのある取引組み合わせ、およびシステムに入力されてい
る他の契約相手からのポジションに対するトレーダーのポートフォリオの組み合
わせを見ることができる。これはポジション発見と呼ばれる。スイッチ・インタ
フェース４００には、コマンド・センター・インタフェース１３０（図５）のツ
ール・バー１３２のスイッチ・エンジン・ボタンを選択してアクセスできる。所
定の変動金利指標（例えば、１ヶ月ＬＩＢＯＲ）４０２に対しては、スイッチ・
エンジン・インタフェース４００は１８０日以外の各日４０６に対し正味ポジシ
ョン４０４を表示する。さらに、可能なスイッチ４０８、有効なスイッチ４１０
、公式化先物相場４１２、および公正価格４１４もまた、各日４０６に対し表示
される。日４０６を選択することにより、スイッチ・インタフェース４００はそ
の日に対するすべての可能なスイッチを表示する。したがって、ユーザーは最大
リスクを持つ日を選び出すことができる。スイッチ・インタフェースの有利な機
能は、ユーザーが、ユーザーが１つのポジションを持ち、他の誰かが反対のポジ
ションをとり、両方の当事者が以下に述べる相互の信用プリファレンスを満足す
る場合の組み合わせだけを、提供されることである。

【０１９０】 正味ポジション４０４はユーザーによりが入力または変更されるポジションで
ある。可能なスイッチ４０８は、トレーダーのポジションに関して任意に与えら
れる日に対するスイッチである。スイッチは一般に、トレーダーポジションが１
つの日では長く、また別の日には短い場合だけ反応することに注意する必要があ
る。

【０１９１】 有効なスイッチ４１０は、ユーザーのポジションを正しく相殺する他の契約相
手のポートフォリオ内のポジションである。スイッチ・インタフェースの構成は
、有効なスイッチをユーザー自身のポジションのサイズまで表示し、好ましくは
すべての契約相手の名前を、取引が完了する後まで開示しないように構成される
。これにより、ユーザーの匿名性を保証し、すべての重要なポジションは他のト
レーダーに開示しない。

【０１９２】 先物相場４１２は、基本指標満期日の満期日に対し、他の有効な市場金利から
システムにより計算された現在市場の先物相場である。公正価格４１４は２つの
基本ＦＲＡ間の相対価格を表し、先物相場同意が取引される基本価格である。公
正価格４１４は、他の金融商品から取られる、生きた（現在活動している）市場
データから計算される。表示される公正価格４１４で取引を実行するように設計
されていないが、公正価格はユーザーが市場の公正値を測る助けになる。

【０１９３】 ユーザーが、ユーザーの要求に一致するスイッチを見出すと、そのスイッチは
有効スイッチ４１０として示され、その後ユーザーは、スイッチ（ＲＦＳ）ボタ
ン４１６に対し要求を選択して、スイッチ・メッセージに対する要求を送ること
ができる。それに対応して、ＲＦＳメッセージが匿名で、選択された相殺ポジシ
ョンの他の契約相手だけに送られる。次に、受け取る契約相手のどれもが、メッ
セージを選択し（すなわちクリック・オン）、また本明細書で述べる市場エント
リ・インターフェース２５０を利用する売買を完了することにより、市場エント
リ・プロファイルに自動的に記号を追加できる。スイッチ・メカニズム３５によ
りスイッチを完了すると直ぐに、契約相手のポートフォリオが自動的に更新され
て、そのスイッチを反映する。スイッチ・エンジンの機能によれば、スイッチ売
買はリアルタイムに完了する。

【０１９４】 スイッチの例として、スイッチ・インタフェース４００を表示するトレーダー
は「Ｔｈｕｒｓ．，Ａｕｇ．２１」ポジションを選択（強調表示）し、次にＲＦ
Ｓボタン４１６を選択できる。次に、受動オーダー・インタフェース２９４（図
１４Ａ）が、トレーダーに、変更する数量および価格を提供するように促す。こ
の時、トレーダーはスイッチに対する要求を発行できる。この時、相殺ポジショ
ンを有するすべての匿名契約相手はコマンド・センター・インタフェース１３０
（図５）内に、スイッチに対する匿名の契約相手を通知するメッセージを受け取
る。契約相手のどれもが、市場エントリ・インタフェース２５０（図１２）に要
求を表示させることができる要求メッセージを選択できる。市場エントリ・イン
タフェース２５０から、契約相手はスイッチに対する要求をヒットするか、また
は受動オーダーを発行できる。

【０１９５】 トレーダーは、前述のように、ポートフォリオ・インタフェース３８０を起動
するＵｐｄａｔｅ（更新）ボタン４１８を選択して、トレーダーのポートフォリ
オを更新または変更できる。トレーダーは入力される数量３８２または取引され
る数量３８４を選択して、表示された値を望む値に入力または編集できる。

【０１９６】 本発明は、デリバティブ以外の金融市場の用途も有することを特に述べておく
。例えば、ディーラ相互間市場では、スイッチまたはスワップは望ましい手段で
あり、それによりリスクまたは商品構成不足分が相殺される。特に、セキュリテ
ィが流出するか、またはオープンのデリバティブポジションが別のポジションで
妨害されることがある。例えば、米国財務省長期証券市場では、トレーダーが債
券を売ったり買ったりして、最新問題またはベンチマーク問題を防ぐことは普通
である。米国財務省は各月に新しい２年債券を発行できる。第１月では、新しい
発行はベンチマーク（またはオン・ザ・ラン）発行であり〜２年の最終満期日を
持つその他方の発行は、旧発行と呼ばれる。トレーダーが旧発行分を買う場合、
オン・ザ・ランが流動性を持つため、トレーダーはオン・ザ・ランをヘッジとし
て売る。時間経過とともに、おそらく、トレーダーは旧発行を売り、自身のヘッ
ジを買い戻すことが必要になるであろう。逆のポジションを有する別のトレーダ
ーを持つスイッチ、そのような取引を実現するコストおよびリスク効果の高い方
法を提供する。

【０１９７】 しかし、ポジションを開示するのを望まないトレーダーは債券スイッチを困難
にさせる。したがって、本発明のスイッチ・エンジンは１つのソリューションで
ある。スイッチ・エンジンの重要点は、債券スイッチおよび他の金融商品スイッ
チに優れた適用性を持つことである。スイッチ・エンジン・インタフェース４０
０は、商品指定４０２が新しい市場（例えば、２年米国国債または３０ＦＨＬＭ
Ｃ ＴＢＡ）を反映するように変更される場合には、多少は変更する必要がある
。さらに、設定列４０６を変更して、スイッチされる個々の債券を反映させるこ
とができ、残り列は変更する必要ない。しかし、表示される各債券の期間を表す
新しい列を追加し、債券が公正を保証するように重み付される期間になるように
する。

【０１９８】 スイッチ・エンジンに加えて、システム１０は、オークションおよびスイッチ
・オークションと呼ばれる取引方法を提供する。オークションは各種の市場で開
催されるが、そのいくつかは電子的であり、オークションおよびスイッチ・オー
クションは、デリバティブ市場で既知の契約相手を持たない。オークションおよ
びスイッチ・オークション取引方法は、スイッチへの自動マッチング・プロセス
を提供するために開発された。しかし、システム１０これらオークション方法を
、スイッチだけでなく、他の広範な金融製品の自動マッチングに利用できる。

【０１９９】 従来のオークションと異なり、取引が完了すると、契約相手はデリバティブ取
引での将来の金融契約からは自由であり、取引が実行されると、契約相手は相互
に複数年金融契約を終了できる。この相対的に特有の問題は処理するために、オ
ークションおよびスイッチ・オークションはユーザーの信用プリファレンスを考
慮に入れる。ここでのオークション方式は「信用付き２方向Ｄｕｔｃｈオークシ
ョン」と呼ばれる。このようなオークションの実行では、ユーザーは、トレーダ
ーワークステーション２０（図３）のオークション・モジュール８１にオーダー
を提出し、そのワークステーション２０が中央処理センター１２（図２）のオー
クション・メカニズム３４に情報を伝達する。オーダーは、図２２Ａに示すオー
クション・インタフェース４３０を介して、価格、数量、およびアクションと共
に提出される。

【０２００】 図２２Ａでは、オークション・インタフェース４３０は、ユーザーがオーダー
を入力する待機オーダー・ウィンドウ４３２と、オークション・モジュール８１
を介してオークション・メカニズム３４に提出されるオーダーを示す提出される
オーダー・ウィンドウ４３４とを含む。オーダーはＡｄｄ（追加）ボタン４３６
により追加できる。オーダーは、そのオーダーを強調表示し、次にＳｕｂｍｉｔ
ボタン４３８を選択して、待機オーダー・ウィンドウ４３２から提出されるオー
ダー・ウィンドウ４３４に移動される。待機オーダー・ウィンドウ３４２に入力
された全オーダーは、全オーダーを強調表示し、次にＳｕｂｍｉｔ Ａｌｌ（す
べて提出）ボタン４４２を選択し、一度に提出できる。オーダーを提出す前に、
待機オーダー・ウィンドウ４３２のオーダーは、Ｅｄｉｔ（編集）ボタン４４０
により編集するか、Ｃａｎｃｅｌ（取り消し）ボタン４４４により取り消しでき
る。

【０２０１】 オークションによれば、オーダーはそれらの入力された価格またはそれより高
い価格の、相互に信用プリファレンスを満たす契約相手間での価格を記入される
。次に、オークション・メカニズム３４はオークションを実施し、好ましく以下
の制約および優先度を利用して公正を保証する。

【０２０２】 オークションは、最大出来高の価格を見出して計算される。この条件は公正価
格を形成するのに十分であり、全売買はこの価格で完了することになる。この価
格は信用を考慮に入れずに形成されることに注意する必要がある。オーダーのマ
ッチングは、信用プリファレンス（複合規則を含む）が安全に保護されることを
保証し、最小数のチケットが作成されることを保証することで完了する。より適
切な価格は優先権を持ち、オークション価格での全オーダーは相互に比例して記
入される。これらの制約の下で、オークション・メカニズム３４はオークション
、ユーザーのマッチング、決済リストの生成を実行する。決済リストはオークシ
ョンの取引結果を含む。

【０２０３】 確定プロセスは対話式取引とほぼ同一である。システム１０は記入内容をユー
ザーに通知する。最後に、結果は各ユーザーのコマンド・センター・インタフェ
ース１３０へのメッセージを介してユーザーに利用可能になる。 本明細書で述べる一般オークション装備に加えて、本発明はまた、スイッチ・
オークションと呼ばれるスイッチ用の専用の限定された自動マッチング・プロセ
スを提供する。このスイッチ・オークションは完全オークションを備えないが、
価格はシステム１０で設定できる。しかし、価格は、マッチングの開始前に有効
である。これにより、全ユーザーはスイッチ・オークションに入る使用されるレ
ベルを認識できる。またこれにより、ユーザーはユーザーポジションの制御を維
持できる。

【０２０４】 一般オークションと同様に、各トレーダーのポジションは、図２２Ｂに示すス
イッチ・オークション・インタフェース４６０を利用してシステム１０にロード
される。スイッチ・オークション・インタフェース４６０は２つの部分、オーク
ション・リスト４６２およびオークション・ステータス４６４を有する。オーク
ション・リスト４６２では、各種のオークションおよびそれぞれのステータスが
、ＦＬＯＰＴおよび通貨により一覧表示される。オークション・ステータス４６
４では、オークション・リスト４６２内で選択されたオークションが表示され、
識別される（開始および閉鎖に日／時間を含む）。それぞれの日付４６８に対す
るポジション４６６は、ユーザーにより入力され、ゼロに加える必要はないが、
両方の符号（すなわち、ロングおよびショート）のポジションを含む必要がある
。金利４７０はオークションが実施される価格である。金利４７０は所定の時間
長さ表示され、その時間後、オークションが実施され、その結果、参加者が希望
すればスイッチ・オークションから外れる機会を有する。好ましくは、金利は有
効な市場要素に基づいており、ｃａｌｃｓｅｖｅｒ（以下に述べる）により計算
できる。結果列４７２は、オークションの結果の全取引量である。所定の日付の
結果列４７２に表示される数量は、複数当事者による複数売買累積量である。追
加制御ボタン４７４により、ユーザーはオーダーの提出、オーダーの取り消し、
全オーダーの取り消し、またはオーダーの変更ができる。スイッチ・オークショ
ンはポジションを自動マッチングし、ユーザーの信用プリファレンスを考慮に入
れて、（１）最大出来高を実行し、（２）最小数のチケットを作成する。

【０２０５】 スイッチ・オークションは前述の２つの規則を利用して公正を保証する。どの
ユーザーも、それぞれの信用プリファレンスを満足するのに必要とされる場合を
除いて、他のすべてのユーザーを超える優先権を与えられない。好ましくは、２
方向スイッチだけが提供される。スイッチはリスク管理ツールであり、３つの契
約相手間に形成されるスイッチは、直線２方向スイッチに比べて実質的に大きい
信用リスクを発生する。

【０２０６】 この点で、オークション金利および価格情報を計算ｃａｌｃｓｅｒｖｅｒと、
システム１０の動作に対する他の関連データが述べられる。ｃａｌｃｓｅｒｖｅ
ｒはスイッチ・メカニズム３５に、各日のすべての所定の指標に対する先物相場
、市場エントリ・インタフェース２５０で値を付けられたシステム価格、および
利回り曲線からも求められるＯＴＣデリバティブ価格を提供する。ｃａｌｃｓｅ
ｒｖｅｒはプリプロセッサ、ゼロ曲線サーバ、ＦＲＡサーバおよびスワップ・サ
ーバを備える。プリプロセッサは、外部のデータ・ベンダー（Ｒｅｕｔｅｒまた
はＴｅｌｅｒａｔｅのような）と、および内部システム・ソース（システム１０
に正常に入力されたデータのような）とからリアルタイム・データを収集し、そ
のデータをｃａｌｃｓｅｒｖｅｒの他のコンポーネントで処理するように準備す
る。ゼロ曲線サーバは、プリプロセッサから提供される、市場金利（マネー市場
金利、スワップ金利、先物金利、スワップ・スプレッド、債券利回りおよびＦＲ
Ａなどの各種クラスの商品価格および利回り）を読み込み、そのデータから、各
通貨および信用レベルに対しでゼロおよび割引係数を生成する。詳細には、ゼロ
・クーポン利回り曲線（すなわちゼロ曲線）は、すべてのキャッシュ・フローが
分解すると考えることなく１つのステップで今日までに割引できるような、期間
構成（例えば０〜３０年）全体に渡る観察可能な市場金利から計算された金利ま
たは割引率を示すセットの点を含む。したがって、各指標／通貨のペアに対して
別々のゼロ曲線が存在する。ＦＲＡおよびスワップ・サーバは、先物、ＲＱ（上
に定義された）、期間および公正価格を計算する商品特定サーバである。

【０２０７】 例として、ゼロ曲線計算はマネー市場金利（ＭＭ）の最短期間構成を持つ商品
から開始する。ＭＭからのゼロ曲線上の点を見出す分析は以下のようである。Ｍ
Ｍの処理される価格、ＭＭの最終日、ＭＭの基準（ＭＭが基準とする１年内の日
数）が必要である。これらすべてはデータベース６４（図２）に格納される。処
理される価格は、正常に変化する入力だけである。以下の式で示される計算は、
ＭＭの最終日のデータを持つゼロ金利を発生する。この結果は、発生されたゼロ
点の残りに加えられる新しいゼロ点である。Ｚ（ｔ）に対する以下の式は、ＭＭ
の最終日でゼロ金利である。

【数１２】 ここでＲｍｍはＭＭの処理される価格であり、ｔはＭＭの最終日と現在の間の日
数の時間である。

【０２０８】 ＭＭの後、期間構成に従い使用される次の商品は先物またはＦＲＡのどちらか
である。先物およびＦＲＡは類似の期間構成を有するため、どちらを使用するか
の選択がでなされる。大きい流動性を有する理由から、最初に先物を使用する。
しかし、システム１０上で取引きされるＦＲＡが大きいレベルの流動性に達する
場合、代わりに、これらを使用するべきであると一般に言われている。

【０２０９】 先物からゼロ点を計算する場合、処理される価格、先物の基準（先物が基準と
する１年内の日数）、先物の開始日、先物の最終日および開始日のゼロ点が必要
である。先物に関するこのデータは、先物を示すために使用されるプリプロセッ
サから取り込まれる。開始日のゼロ点は、補間により前のゼロ点から求められる
。Ｚ（ｅ）に対する以下の式は、先物の最終日でゼロ金利である。

【数１３】 ここで、ｆｕｔＢａｓｉｓは先物が基準とする１年内の日数、ｆｕｔＲａｔｅは
先物の処理される価格、ｅは最終日−現在の日付、ｓは開始日−現在の日付であ
る。

【０２１０】 ＦＲＡゼロ点の計算は先物の計算と同一であるが、先物および先物基準の処理
される価格の代わりに、ＦＲＡおよびＦＲＡ基準の処理される価格が使用される
のが異なる点である。ＦＲＡに関する情報はプリプロセッサから与えられる。ｚ
（ｅ）_fraに対する以下の式は、ＦＲＡの最終日でゼロ金利である。

【数１４】

【０２１１】 ゼロ曲線の残りはスワップ情報から求められる。第１スワップに対し、各クー
ポン日付でのゼロ曲線および割引率を使用して、Ｚ（ｔ_n）に対し以下の式を使
用して、スワップのゼロ金利および最終日を計算する。他のスワップのゼロ点を
計算する場合、ゼロ曲線にギャップが発生することがある。精度を上げるとギャ
ップが発生する場合、合成金利が計算される。通常スワップ金利および合成スワ
ップ金利の計算は同一である。Ｚ（ｔ_i）に対する以下の式は特定クーポン日付
でゼロである。

【数１５】 ここでｓｗａｐＲａｔｅは取引価格調整であり、ｔ_iはクーポン日付、Ｙ（ｔ_n-1 ，ｔ_n）は２つのクーポン日付間の年数期間である。取引が完了し、条件交渉プ
ロセスが完了すると、システムは自動確認プロセスを実行する。前記プロセスは
、本発明の実施形態では、現行の市場通例に従う。したがって、システム１０は
売買を詳細に記載したファックス確認メッセージを各取引相手に自動的に送る。
ファックスは、売買完了後即座に送られるべきである。確認は、これら確認を電
子的に自動的に転送できる特有の形式に従うべきである。

【０２１２】 この確認は、標準形式が金融契約のすべてのクラスを範囲に含むことができる
ように特別に開発された。標準確認は以下の形式に従う。 セクション１：売買の要約 セクション２：契約相手明細および売買手数料 セクション３：売買明細 セクション４：条件交渉

【０２１３】 これは、ユーザーに売買を識別および／または記録する適正な情報を提供する
。しかし確認は、例えばｅ−メール、ボイス・メール、米国郵政公社、または商
用運送会社（例えば、ＦｅｄＥｘ、ＵＳＰ等）を介するようなかなり多くの方法
でトレーダーに送ることができる。さらに、提供される情報は本発明の範囲内の
他の多くの形式を取ることができる。

【０２１４】 本明細書ではシステム１０への各種インタフェースを、別個のウィンドウとし
て述べるが、複数のウィンドウを集積して、図２３に示すような複数フレームを
持つメイン・スクリーン４８０を形成できる。例えば、ツール・エリア４３２は
トレーダーに、グラフ、市場相場へ利回り変換に際する債券価格、価格決定ツー
ル、およびＭａｒｋｅｔ Ｓｈｅｅｔ(商標）アプレットを含むセットのカスタ
マイズされたツールを提供する。サービス・エリア４８４は前述の各種インタフ
ェースを一時的に提供する。メッセージ・センター４８６は最新のＲＦＰ、ＲＦ
Ｓ、チャット、および管理メッセージを表示し、好ましくは、複数メッセージを
表示するドロップ・ダウン・ウィンドウとして構成される。ステータス・バー４
８８はユーザー・ステータス情報を表示する。ワークスペース・エリア４９０に
より、データを無理のない方法でダイアログ・ボックスに入力し、さらにそのデ
ータ機能を実行できる。ウエアハウス・エリア４９２は大部分の共通に使用され
るインタフェースをタブ形式で格納し、セッション間にトレーダーが好ましい設
定を維持できるようにする。したがってメイン・スクリーン４８０は、単一ウィ
ンドウ内に複数インタフェースを集めて、強化された機能を提供する。

【０２１５】 ４．動作 前述のように、システム１０は中央処理センター１２を備え、そのセンターに
は、インターネット・プロトコル・ネットワークを介して個々の契約相手のトレ
ーダーワークステーション２０（デスクトップ・コンピュータ・ワークステーシ
ョンであってもよい）に接続された複数サーバを備える。システム１０のオープ
ン・システム・アーキテクチャの理由から、本発明は、ユーザーの既存のデスク
トップ・コンピュータ２０上のインターネット・ブラウザの環境内で実行できる
。好ましくは、デスクトップ・コンピュータ２０は、Ｊａｖａ使用可能なインタ
ーネット・ブラウザが利用できるオペレーション・システム・プラットフォーム
を含む。

【０２１６】 契約相手に、各側が他方と長期契約に入る場合の、広範囲な金融契約に対する
取引能力に基づく匿名信用プリファレンスを提供するために、本発明の設計は、
図２４に関して以下に一般的に説明するように、信用リスクのいくつかの異なる
判断基準を反映するのに十分な順応性を持つように設計されている。

【０２１７】 図２４のフローチャート５０２によれば、各ビジネス・ユニット（契約相手）
はグループ・サーバ３２（図２）に、各見込みのある契約相手のビジネス・ユニ
ットの法的主体に対する詳細な信用プリファレンスを提供する。次に、グループ
・サーバ３２は匿名形式の信用プリファレンスを、システム１０内で各アクティ
ブ・ビジネス・ユニット（契約相手）信用プリファレンスを使用する取引ワーク
ステーション２０に配布することにより、他の契約相手の市場オーダーに対して
ユーザーの市場オーダー（付値および売値）を事前スクリーニングする。したが
って、各トレーダーの信用プリファレンス・モジュール７６（図３）は、ブロッ
ク５０４に示すように、第２ユーザーを基準とする第１ユーザーにより定義され
た信用プリファレンス情報を受け取る。次にブロック５０６に示すように、信用
プリファレンス・モジュール７６は、第１ユーザーを基準として第２ユーザーか
ら信用プリファレンス情報を受け取る。次に信用プリファレンス・モジュール７
６は、どのオーダー、どの金融商品、どの契約相手を、ユーザーが取引できるか
を決定する。この情報は、ブロック５０８に示すように、カラーまたは記号のよ
うな別の表記法を利用して公示価格をコード化する。

【０２１８】 本発明の態様によれば、事前スクリーニングは複雑な検査であり、２つの特定
の契約相手が相互に、特定クラスの金融商品、特定の数量、および特定の満期日
を受け取るかどうかを決定する。これはリスク等価測定であり、簡単なＹｅｓ／
Ｎｏの事前確認マトリックスより複雑である。詳細には、各金融商品が異なる信
用品質を有する理由から、特定契約相手が、１つのタイプの金融商品に対し別の
特定契約相手を受け入れ、他は受け入れないように決定することできる。さらに
また、特定契約相手が特定金融商品に対し、一定期間（すなわち満期日）だけ、
他を受け入れることも可能である。またシステム１０により、ユーザーは異なる
満期日の異なる数量に対し契約相手を受け入れることもできる。

【０２１９】 さらにシステム１０は、契約相手を法的主体に分割できる。これら法的主体は
さらに、個々のビジネス・ユニットに分割できる。したがって、例えば、銀行Ａ
は法的主体（契約相手）であってもよく、銀行Ａは３つの別々の場所（例えば、
東京、ロンドン、ニューヨーク）の別のビジネス・ユニットを有していてもよい
。この例では、契約相手の信用情報は法的主体レベルで有効である。したがって
、例えば、銀行Ａが、それのビジネス・ユニットの各々が他の契約相手に対する
それら自体の信用プリファレンスを設定できることを望む場合、これら信用プリ
ファレンスは他のビジネス・ユニットすべての法的主体レベルに対し一覧表示さ
れる。言いかえると、銀行Ａのビジネス・ユニットＡは、それが銀行Ｂのデスク
Ａ（銀行ＢのデスクＢではなく）と取引する、と言うことはできない。システム
１０により、特定法的主体内のビジネス・ユニットが、希望する場合は、同一法
的主体ファミリー内の他のビジネス・ユニットから信用プリファレンスを引き継
ぐことができる。

【０２２０】 各ビジネス・ユニットがそれらの個々の信用プリファレンスを入力すると、こ
の信用プリファレンス情報は、入力するトレーダーワークステーション２０にロ
ーカルに維持され、中央処理センター１２のグループ・サーバ３２に送信される
。次に中央処理センターは符号化された信用プリファレンス・データのベクトル
を、ログ・オンしている各ユーザーに送信する。この場合、データは、影響され
る商品クラスに対する、他の法的主体へのユーザーのプリファレンスおよびその
ユーザーへの他のビジネス・ユニットのプリファレンスを表す。信用プリファレ
ンス・データの符号化されたベクトルは、システム１０のどのトレーダーワーク
ステーション２０にもアクセスできる。しかし、他の契約相手の敏感な信用情報
は利用できない。

【０２２１】 ユーザーがユーザーのビジネス・ユニット信用プリファレンスを入力すると、
ユーザーはメッセージを選択またはフィルタリングできる。そのメッセージは、
ユーザーが更新、メッセージおよび支払期限を受け取ることを望む、金融商品お
よび通貨が記載されている。フィルタを、ユーザー・プリファレンス・インタフ
ェース１４８を介して選択し、コマンド・センター・インタフェース１３０によ
り示されるオーダー情報をカスタマイズできる。このスクリーニング能力を設け
ている目的は、ユーザーが、システム１０が処理できる最大１４またはそれ以上
の異なる通貨の、予測される数千の異なる金融商品で圧倒されるのを防止し、お
よびそれらを分類するためである。これらフィルタがシステム１０に入力される
と、ユーザーは、ユーザーに対し選択されている通貨および金融商品を見ること
がきる。これは、例えばユーザーがＵＳドルを選択する場合、好ましくは、ユー
ザーは取引のためにシステム１０内に存在する日本円金融商品の情報を見ない。

【０２２２】 ユーザーの取引プリファレンスがシステム１０に入力されると、ユーザーは取
引を進行できる。次にユーザーは、完全なカスタマイズ可能な、サイズ変更可能
な市場エントリ・インタフェース２５０を起動する。市場エントリ・インタフェ
ース２５０により、ユーザーは、ユーザーが１つのスクリーン上で取引に関心を
持つ多くの異なる金融商品を入力でき、また各プロファイルがシステム１０内の
市場の収集または金融契約の収集である任意の数のプロファイルを持つことがで
きる。

【０２２３】 好ましい実施形態は、記号法と呼ばれる固有の記号セットの使用を通して各種
金融商品の入力および参照を実現する。本発明の記号法は主題ベースのアドレス
指定の概念を基本とし、それにより、ユーザーは、多くの複雑な金融商品のすべ
てを固有に定義する記号を生成できる。記号は金融商品パラメータおよび属性を
示す。本発明の標準記号法は、システム１０のユーザーが記号を見ると、その記
号の意味を認識するように設計されている。ユーザーがどの金融商品を取引して
いるのかをさらに理解しやすくするために、記号は完全な主題名、別名（最も一
般的に取引される商品の場合）、または固有の識別名（例えば、数字コード）に
より識別できる。ユーザーが、取引を望む金融商品を正確に表す記号を使用する
のを容易にするために、システム１０は、ユーザーが記号形成インタフェース２
７０（図１３）を利用して記号を形成できるようにしている。

【０２２４】 以下に説明し、また図２５のフローチャート５１０で示す本発明の記号法によ
り、ユーザーは、金融商品の提案取引を含むデータを入力できる。この場合、有
利には金融商品は、ブロック５１２に示すように、ソース・フィールド、クラス
・フィールド、記号フィールド、および通貨フィールドを含む記号法で定義され
る。記入商品を識別するための省略形式は、ブロック５１４に示すように、シス
テム１０内の他のユーザーに容易に送信できる。受け取るユーザートレーダーの
ワークステーション２０では、ブロック５１６に示すように、トレーダーが記号
法を利用して提案された取引を見ることができる。本発明の記号法を使用して金
融商品を定義することにより、ユーザーは解釈できる少数のデータを、相対的に
複雑な金融商品の詳細な記述に交換できる。これにより、システム１０の通信お
よび処理オーバヘッドを低減し、ユーザー作業を簡単化する。

【０２２５】 オーダーが記号法により入力されると、市場エントリ・インタフェース２５０
は、各商品の最高付値および最高売値、および最高価格および他の関連情報での
取引に有効な総数量を表示する。いくつかの価格が同一価格で現在公示されるが
、異なるステータスを有する限り、オーダー情報（すなわち、各商品の付値およ
び売値）は関連信用プリファレンスでコード化される。この場合、市場詳細イン
タフェース３０２が使用されるべきである。これは、取引できる最高価格だけを
示す従来のシステムと大きく異なる。システム１０は、信用プリファレンスまた
は信用限度に関係なく最高価格を示す。両方の当事者の信用プリファレンスが許
可する場合は、市場エントリ・インタフェース２５０から、ユーザーが直接取引
を実行できる。ユーザーはまた、市場エントリ・インタフェース２５０から受動
オーダーを発行できる。

【０２２６】 ユーザーはまた市場詳細インタフェース３０２を起動するオプションを有し、
そのオプションでは、ユーザーは、信用プリファレンス情報でコード化された、
特定金融商品に有効な全オーダー（すなわち付値および売値）の完全な画像（す
なわち深さ）を見ることができる。市場エントリ・インタフェース２５０および
市場詳細インタフェース３０２は最高付値および売値を表示するだけでなく、シ
ステム１０内の各個々のオーダーを別々に表示する。市場エントリ・インタフェ
ース２５０および市場詳細インタフェース３０２を通して、ユーザーは最高付値
または売値だけでなく、システム１０内のすべての付値および売値を選択する能
力を提供される。これは信用の理由から需要であり、閲覧している契約相手は特
定付値または売値を望めないか、または認められないことがある。これは、シス
テム１０内の最高付値および売値が、必ずしもその契約相手に有効な最高付値お
よび売値とはならないことを意味する。

【０２２７】 前述のように各ユーザーによりシステム１０に入力された信用プリファレンス
情報は、中央処理センター１２および送信ビジネス・ユニット・サーバ１８の両
方で使用され、付値および売値を事前スクリーニングされて、システム１０内で
オーダーに出され、その後それぞれのクライアント側１４のトレーダーワークス
テーション２０で表示される。どの契約相手が、どのような契約条件で受け入れ
できるかを示す敏感な信用プリファレンスは、好ましくは送信トレーダーワーク
ステーション２０および中央処理センター１２で維持される。他の閲覧している
ユーザーは他のユーザーの信用情報を受信しないか、またはアクセスしない。受
信ビジネス・ユニット・サーバ１８では、検査を実行して、受信クライアント側
１４が送信法的主体からの特定付値または売値を受け入れるかどうかを決定する
。要約および関連データは、暗号化形式でトレーダーワークステーション２０に
転送される。信用検査は中央側１４および／または中央処理センター１２により
売買時に再度実行される。

【０２２８】 本発明の信用プリファレンスの事前スクリーニングは、システム１０内のすべ
ての受動オーダーと、市場エントリ・インタフェース２５０および市場詳細イン
タフェース３０２の両方の閲覧者に関する関連信用状態との表示を可能にする。
この表示は、１）緑−これは閲覧者が登録契約相手を受け入れ、登録契約相手が
閲覧契約相手を受け入れることを意味し、２）黄−これは閲覧者が登録契約相手
を受け入れたが、登録契約相手が閲覧契約相手を受け入れないことを意味し、３
）赤−閲覧者が登録契約相手を受け入れない、４）青−閲覧された付値または売
値が閲覧者自身である、５）白−市場エントリ・インタフェース２５０上で使用
されて、２つまたはそれ以上のオーダーが同一価格であるが、異なる信用プリフ
ァレンスで発行された時を示す。カラー・コード化の使用により、システム１０
はユーザーの匿名性を保護できる一方で、閲覧しているビジネス・ユニットが、
閲覧中の付値および売値に関する信用情報を受け取ることができる。ユーザーが
カラー・ブラインドである場合、システム１０はまた、閲覧者に対し関連信用状
態を示す各価格の隣に小さい記号を表示するオプションを含む。

【０２２９】 閲覧者が緑の付値または売値を取引することを望む場合、システムはこれを即
座に実行することを許可する。さらに、売買への能動契約相手、つまり付値をヒ
ットするか、または売値をリフトした閲覧者が、売値または付値の全数量を実効
することを選択し、同一価格でのオーダーがなくなる場合、閲覧者は他の契約相
手にさらに取引を実行するよう要求できる状態にあることを促される。好ましく
は、このｗｉｌｌ−ｄｏ−ｍｏｒｅ（さらに多くの取引を実行する）機能は、所
定の時間限度に制限され、要求の受取者はその時間内で応答しなければならない
。要求の受取者は、価格への以前の同意時における増加される量（または増加さ
れる量の一部）の受け入れを同意できるか、または要求は失効する。ｗｉｌｌ−
ｄｏ−ｍｏｒｅ（さらに多くの取引を実行する）機能は、ユーザーが望むだけの
回数繰り返しできる。このプロセスが開始されると、ｗｉｌｌ−ｄｏ−ｍｏｒｅ
（さらに多くの取引を実行する）機能は必ずしも信用プリファレンスを検査する
必要がない。これは、両方のユーザーがこの時点で相互の識別名を知るからであ
る。これは、ユーザーに、初期取引量の点を超えるそれ以上の信用承認に応答す
ることを強制しない。

【０２３０】 ユーザーにより閲覧されるオーダーが黄の場合、閲覧者は登録者を受け入れる
が、登録者は閲覧者を受け入れない。この場合、システム１０により、ユーザー
は信用無効化メッセージを付値または売値の登録者に送ることができ、それによ
り、信用無効化の送信者は自身の識別名を登録者に明らかにし、登録者に、閲覧
者の要求した取引を実行するかしないかを再度考慮するように求める。この場合
、信用無効化を送ったユーザーは登録者に識別されるが、信用無効化の送信者は
、彼らが自身を誰に対して明らかにしたかを見出すことはない。登録者が信用無
効化の受け入れを選択する場合、登録者もまた、売買を受け入れるために追加の
信用要求事項を閲覧者に要求することを選択できる。これら追加の信用要求事項
は、取引確認での標準の相互配置条項の形式である。閲覧者は追加信用要求事項
の受入または拒絶のどちらかの機会を有する。いずれにせよ、信用無効化機能は
各ユーザーがシステム１０に前に入力した信用プリファレンスを変更しない。信
用無効化は売買ベース当たりであるのが望ましい。

【０２３１】 閲覧しているトレーダーが閲覧している付け値または売値が赤色の場合、閲覧
者は登録者を受け入れない。閲覧者が登録者を受け入れないと認識している事実
があるとしても、閲覧者は閲覧者承認しない契約相手間のどれが登録者であるか
を知ることはない。したがって、閲覧者は登録者を特定することができず、シス
テム１０の匿名性を保つ。登録者が信用変更を能動にしない場合、実行できる取
引は存在しない。

【０２３２】 付値または売値が青で表示された場合、オーダーは登録者自身のオーダーであ
る。システム１０は同一クライアント側１４内の異なるユーザーが相互に取引す
ることを妨げない。

【０２３３】 マーケット・エントリ・インタフェース２５０およびマーケット詳細インタフ
ェース３０２から、ユーザーは要求された金融商品に関心を持つ他の契約相手に
価格要求メッセージを送信することもできる。価格要求により、ユーザーは関心
のある他の市場参加者に匿名でブロードキャストすることができる。

【０２３４】 図２６によれば、フローチャート５２０は全体の取引ステップを表している。
最初に、第ユーザーと第２ユーザーには、ブロック５２２に示すように、マーケ
ット・エントリ・インタフェース２５０を介して、通常２つ以上の金融商品に関
するリアルタイムのオーダー情報が効果的に提供される。好ましくは、オーダー
情報にはＯＴＣデリバティブといった金融商品の売買要求が含まれている。ブロ
ック５２４で、第１または第２のユーザーの１つが第１または第２以外のユーザ
ーにより提供されたオーダー情報から選択されたオーダーで取引のプロセスを開
始する。各ユーザーの信用プリファレンスの情報は、ブロック５２６に示すよう
に、第１および第２ユーザーの取引の適格性を、選択されたオーダーに基づき相
互に確認するために使用される。第１および第２ユーザーの一方または両方が、
ブロック５２８に示されているとおり、オーダーの量を増やす要求を行うことが
できる。増加が要求される場合、その要求はブロック５３０でのプロセスである
。これとは別に、ブロック５２８で量を増やす要求がない場合、オーダーの条件
、詳細には、オーダーの基礎を成す金融商品の非商用的な条件を交渉する要求が
あるかどうかを確認するブロック５３２がある。ユーザーの１人により条件を交
渉する要求がある場合、要求はブロック５３４で処理される。条件を交渉する要
求がない場合、ブロック５３６に示すように、両方のユーザーに取引の実行を示
している通知が送られる。

【０２３５】 図２６に関する前述の取引プロセスは、第１および第２ユーザーの見地から説
明することもできる。例えば、図２７Ａを参照すると、フローチャート５４０は
概して受動ユーザーの見地から取引のプロセスを示している。最初に、ブロック
５４２で、信用プリファレンスの表示を実行するため、ユーザーの信用プリファ
レンスが入力され、他のユーザーに配布される。ブロック５４４で、ユーザーは
金融商品の取引を要求する他のユーザーに配布するためにシステム１０にオーダ
ーを送る。オーダーを発行したユーザーは、別のトレーダーが受動オーダーをヒ
ットまたはリフトする（それにより取引が実行される）のを待たなければならな
い。取引に対して両方の当事者は、ブロック５４８で決められたとおり、片方、
または両方のユーザーが量を増やす要求ができるという実行通知を受け取る。こ
の要求が受動オーダーをヒットまたはリフトする当事者から受け取られる場合、
ブロック５５０で示すように、第１ユーザーは要求された増量の承認、拒否、ま
たは変更を行う。増量の要求がない場合、金融商品の条件を交渉する要求がある
かどうかブロック５５２で確認される。この機能により、ブロック５５４により
示すように、ユーザーは金融の契約の非商用的条件に対してデフォルト値を変更
することができる。次に、ブロック５５６により示すように、第１ユーザーは第
２トレーダーとの取引を実行する承認を受け取る。

【０２３６】 図２７Ｂによれば、フローチャート５６０は全体の受動オーダーをリフトまた
はヒットした有効なユーザーの見地から取引のステップを示している。ブロック
５６２では、第２ユーザーは金融商品の取引を要求している第１ユーザーからオ
ーダーを受信する。このオーダーは、ブロック５６４に示すように、第１および
第２ユーザーの信用プリファレンスを基にして取引の適格性が検査される。この
オーダーは、ブロック５６６に示すように、信用調査を基にした適切な信用情報
と一緒にコード化される。コード化されたオーダーは、ブロック５６８に示すよ
うに、第２ユーザーにより設定されたプリファレンスまたはフィルタ・セットを
基にして第２ユーザーに提示され、現在の商品のオーダーを表示する。第２ユー
ザーは、ブロック５７０に示したように、オーダーをリフトまたはヒットするこ
とにより取引を開始する。ブロック５７２では、量を増やす要求があるかどうか
確認される。増量する要求がない場合、ブロック５７４で要求が処理される。増
量する要求がない場合、ブロック５７６で、金融商品の条件を交渉する要求があ
るかどうか確認される。この機能により、ブロック５７７に示すように、ユーザ
ーは金融の契約の非商用条件に対してデフォルト値を変更することができる。次
に、ブロック５７８に示すように、承認が第１および第２ユーザーにより受信さ
れ、取引が実行されていることを示す。

【０２３７】 本発明の別の機能は、図２８のフローチャート５８０に示すようにポジション
の発見である。ブロック５８２で、リスクポジションのポートフォリオがシステ
ム１０のユーザーから受け取られる。ブロック５８４で、関連するポジション情
報が、各ユーザーにポートフォリオに対して予想される取引の組み合わせ、およ
び他のユーザーからのポジションに対するポートフォリオの組み合わせを示すた
めに、各ユーザーに対して計算される。予想される取引の組み合わせは、本発明
にしたがって、信用プリファレンス情報と一緒にコード化される。スイッチが要
求されているかどうかがブロック５８６で確認される。スイッチが要求されてい
ない場合、プロセスは終了する。しかし、ブロック５８６でスイッチが要求され
ている場合、スイッチはブロック５８８で実行される。スイッチの実行は、前述
のとおり、その他の取引とほぼ同一方法で実行される。スイッチ実行時は、スイ
ッチに対する各当事者のポジション情報は、ブロック５９０に示すように、自動
的に更新され、スイッチを反映する。

【０２３８】 記録簿により、ユーザーは自身が市場に入力したオーダーのすべての経過を追
うことができる。好ましくは、記録簿はスクリーンであり、それによりいったん
起動されると、システムにユーザーが有している未処理のオーダーのすべてが表
示される。記録簿によりユーザーは、１箇所で都合よくさまざまな多くの商品の
中で、ユーザーの未処理のオーダーのすべてを閲覧できる。好ましくは、記録簿
には２つのタイプがある。第１は、オーダーの価格、またはサイズを変更する機
能など、ユーザーが自身のオーダーを管理するいくつかの機能を提供する未処理
のオーダー取引記録簿３２０である。これは、オーダーの取り消しおよび再提出
を行う必要はなく、ユーザーが迅速にダイヤル・アップまたはダウンを行うこと
ができるウィンドウ上のダイヤルを使用することによりなされる。この編集プロ
セスにより、オーダー変更に関するオーダー管理の複雑さからユーザーを保護す
ることができる。また、これにより、ユーザーがシステム１０において、偶然に
複製のオーダーを有するかまたはオーダーがなくなることを防止する。また、未
処理のオーダー取引記録簿３２０により、ユーザーは自身の有効なオーダーのす
べてをシステム１０に迅速に一時停止（または参照）し、必要な場合、１つずつ
再入力または削除を行うことができる。さらにまた、未処理のオーダーの取引記
録簿により、トレーダーはオーダーの１つまたはすべてを取り消しすることがで
きる。取引記録簿の第２のタイプは、履歴オーダー取引記録簿３３０である。履
歴オーダー取引記録簿から、ユーザーは以前に実行された取引およびそれぞれの
状態、同様に取り消された取引およびそれぞれの状態のすべてを表示することが
できる。

【０２３９】 金利スワップの必要性をトレーダーおよびポートフォリオ管理者のニーズに対
処するために、システム１０にはスイッチ・エンジンとして知られている機能が
含まれている。スイッチ・エンジンは、スイッチ・インタフェース４００により
実現され、これにより、ユーザーはシステム１０に金利再設定リスクのポートフ
ォリオ全体を入力し、日々、無制限な時間範囲で、将来を見通すことができる。
好ましい実施形態では、ユーザーは、再設定リスクのポートフォリオのサイズ（
１００万単位で）および指示（受け取りまたは支払い）を、広範囲の最も一般的
な金利指標（すなわち、１ヶ月米ドルＬＩＢＯＲ、３ヶ月米ドルＬＩＢＯＲ、１
ヶ月ドイツマルクＬＩＢＯＲなど）でシステム１０に入力する。ポートフォリオ
・インタフェース３８０（図２１）を介して直接か、または要求された情報を持
つファイルをアップロードするかのどちらかで、ポートフォリオを入力すること
ができる。情報がシステム１０に入力されると、ユーザーは入力を確認するよう
に要求される。この情報が確認されると、ユーザーは匿名で、信用プリファレン
スに基づいて決定されたこのような情報を入力した他の契約相手すべてに関連す
る、ユーザーの金利再設定リスクの状態を見る能力を有し、取引はシステム１０
においてユーザーに公開され、ユーザーの金利再設定リスクを相殺する。ユーザ
ーがこれらの取引を確認すると、ユーザーは取引を開始しようとしている他の契
約相手に、匿名でスイッチ要求を送ることができる。

【０２４０】 さらに、システムは、図２９のフローチャート６００に概要を示しているとお
り、オークション機能を介してさまざまな金融商品の取引を許可する機能を提供
する。システム１０は、この中で信用プリファレンスを用いる２方向Ｄｕｔｃｈ
オークションと呼ばれる。このオークション方法では、ユーザーは、ブロック６
０２で示すように、取引の実行を望んでいる価格および量の両方を提供するオー
ダーをオークションに提示する。オークションのプロセスは、ブロック６０４で
示すように、最も大きい量が取引される価格を計算することにより開始する。こ
れはオークション価格と呼ばれている。オークション価格は、すべての売買が完
了される公正価格である。この計算において、さまざまな契約相手の信用プリフ
ァレンスは考慮されない。ブロック６０６で、システムはチケットの最小数が発
生するようなオーダーとすべての信用プリファレンスが考慮されるようなオーダ
ーを組み合わせる。より高い提示価格が優先権を有し、オークション価格におけ
るすべてのオーダーが、好ましくは相互に比例して埋められる。オークション機
能の好ましい実施形態では、オークションのプロセスは、流動性を最大にするた
めに１日に数回行われる。また、システムは、ユーザーが、以前に述べられたも
のに類似するオークション環境内で、先物相場同意スイッチおよび他のスイッチ
商品を取引する機能を提供する。

【０２４１】 次に、システムは、ブロック６０８に示すように、自動的に各売買に対して確
認を実行し、電子メール、ファックス、またはその他の手段を介して実行された
各売買の契約相手に電子に確認を送る。この特有の確認プロセスは、すべての金
融商品に対して標準形式および適合形式を使用するように設計されている。

【０２４２】 この点において、オークション・メカニズム３４の操作、および機能のより詳
しい説明が提供される。図３０によれば、オークション・メカニズム３４は、ブ
ロック６２０で示すように、最初にオークションに参加を希望しているトレーダ
ーからオーダー・リストを受け取る。オーダー・リスト内のオーダーは、ブロッ
ク６２２に示されるＢｕｙＬｉｓｔおよびＳｅｌｌＬｉｓｔに区分される。ブロ
ック６２４で、価格リストが生成され、最高価格から最低価格に分類される。ブ
ロック６２６で、オークションは価格リストが空白かどうか確認することにより
行われるかどうか確認される。価格リストが空白の場合、ブロック６２８で示す
ように、オークションは行われない。価格リストが空白ではない場合、ブロック
６３０に示すように、オークションの平均価格が計算される。これは図３１に詳
細が記載されている。次に、ブロック６３２で示すように、すべての当事者の信
用プリファレンスを考慮して、オーダーは、最少の数のチケットが作成されるよ
うに、マッチングされる。これは図３２Ａおよび３２Ｂにさらに詳細が記載され
ている。オーダーがマッチングすると、ブロック６３４で示すように、決済リス
トが生成され、オプションを介して売買の実行を表す。

【０２４３】 図３１では、オークションの平均価格が計算される。詳細には、ブロック６４
０で開始され、例えば初期パラメータｉ＝１、ｊ＝１、差＝ｓ１−ｂ１、ｋ＝２
、およびＮ＝価格リストのサイズ、が確立される。さらに、ＢｕｙＬｉｓｔにお
ける総量はＢ_iであり、ＳｅｌｌＬｉｓｔの総量はＳ_N-i+1である。次に、ブロッ
ク６４２において、ｋ＝Ｎ＋１かどうか、確認される。その場合、オークション
の平均価格はＰ_Iである。そうでない場合、ブロック６４４において、差が０よ
り大きいかどうかが確認される。その場合、ブロック６４６で示すように、パラ
メータｊはｊ＝ｊ＋１に設定され、パラメータの差は、差＝差＋Ｂ_Jに設定され
、パラメータｋはｋ＝ｋ＋１に設定される。そうでない場合、ブロック６４６で
示すように、パラメータｉは、ｉ＝ｉ＋１に等しく設定され、パラメータの差は
、差＝差＋Ｓ_i、パラメータｋはｋ＝ｋ＋１、に設定される。ブロック６４２か
ら６４８の手順は，ブロック６４２でｋ＝ｎ＋１が確認されるまで繰り返される
。

【０２４４】 図３２では、オークションでのオーダーのマッチングのステップが詳しく説明
されている。詳細には、ブロック６５０で示すように、ＢｕｙＬｉｓｔおよびＳ
ｅｌｌＬｉｓｔの条件はオークションの平均価格に応じて削除される。ブロック
６５２で、ＢｕｙＬｉｓｔの大きさが０より大きく、ＳｅｌｌＬｉｓｔの大きさ
が０より大きいかどうか確認される。一方または他方が０よりも大きくない場合
、ブロック６５４で示すように、決済リストが生成される。ＢｕｙＬｉｓｔおよ
びＳｅｌｌＬｉｓｔの両方が０よりも大きい場合、ブロック６５６で示すように
、パラメータＢｓｕｍはＢｕｙＬｉｓｔでの総量に等しく設定され、Ｓｓｕｍは
ＳｅｌｌＬｉｓｔの総量に等しく設定される。ブロック６５８でＳｓｕｍがＢｓ
ｕｍより大きいかどうか確認される。その場合、ブロック６６０で示すように、
パラメータ・リスト１はＳｅｌｌＬｉｓｔと等しく設定され、パラメータ・リス
ト２はＢｕｙＬｉｓｔと等しく設定される。次に、オーダー１パラメータは、ブ
ロック６６２で示すように、リスト１の第１オーダーに等しく設定され、オーダ
ー１はリスト１から除去される。最大／最小および信用の規則は、オーダー２を
組み合わせるためにＢｕｙＬｉｓｔを検索するために適用される。ブロック６６
６で示すように、マッチング・オーダー２が検索され、取引がオーダー１とオー
ダー２の間で発生する。最大／最小および信用の規則は、オーダー２を組み合わ
せるためにＢｕｙＬｉｓｔを検索するために適用される。ブロック６６６で示す
ように、マッチング・オーダー２が検索され、取引がオーダー１とオーダー２の
間で生成される。ブロック６６８に示されているとおり、ブロック６６８でＳｓ
ｕｍがＢｓｕｍより大きくないと確認された場合、パラメータ・リスト１はＢｕ
ｙＬｉｓｔに等しく設定され、リスト２はＳｅｌｌＬｉｓｔに等しく設定される
。次に、ブロック６７０で示すように、オーダー１は、リスト１の第１オーダー
に等しく設定され、オーダー１はリスト１から除去される。次に、ブロック６７
２で示すように、リスト２は、オーダーに関する最大最小の規則および信用プリ
ファレンスを使用して、オーダー１に対するマッチングを見つけるために検索さ
れる。これは、図３３を参照するとさらに詳細が述べられている。それから、ブ
ロック６７４で示すように、取引がオーダー１とオーダー２の間で発生する。

【０２４５】 図３３では、オーダーに適合する最大最小の規則および信用の規則がより詳し
く述べられている。最初に、パラメータ量はオーダー量、特にオーダー１の量に
等しいことが示されている。ブロック６８０で、最初にパラメータ量がオーダー
１に対して０であるかどうかが確認される。０でない場合、ブロック６８２でリ
スト２が空白であるかどうか確認される。リスト２が空白でない場合、ブロック
６８４に示されているとおり、リスト２は第１マッチング・オーダーを検索する
。マッチング・オーダーが探し出された場合、ブロック６８６で示すように、取
引される量は、どちらかの当事者の信用プリファレンスにより定義されている最
小の量、オーダー１の量、またはオーダー２の量と等しくなる。次に、ブロック
６８８で示すように、取引量が０かどうか確認される。取引量が０である場合、
ブロック６８０でプロセスがやり直される。取引量が０に等しくない場合、ブロ
ック６９０で示すように、取引が起こり、決済リストに入れられる。加えて、ブ
ロック６９２で、オーダー２がリスト２から除去される。次に、ブロック６９４
で示すように、オーダー１およびオーダー２の量が以前の量から取引量が引かれ
た量にそれぞれ設定され、オーダー１およびオーダー２の量が更新される。ブロ
ック６９６で、オーダー２の量が０に等しいかどうか確認される。もしそうでな
い場合、ブロック６９８で示すように、オーダー２は一時リストに戻され、オー
ダー１およびオーダー２を配置している当事者の信用は更新される。オーダー１
が０であると確認されると、一時リストが空白かどうかブロック７０２で確認さ
れる。そうでない場合、ブロック７０４で示すように、一時リストはＢｕｙＬｉ
ｓｔに結合される。その後プロセスは終了する。

【０２４６】 次に中央処理センター１２の動作の概要を、図３４を参照して述べる。図３４
は、機能により、グループ・サーバ・メカニズム３２、オークション・メカニズ
ム３４およびスイッチ・メカニズム３５、市場在庫モジュール３８、実行モジュ
ール４０、および決済モジュール４２を表している。凡例７１０は、グループ・
サーバ・メカニズム３２、オークション・メカニズム３４、市場在庫モジュール
３８、実行モジュール４０、および決済モジュール４２の間で、さまざまなオー
ダー、相互およびスイッチ・オーダー、オークション・オーダー、およびスイッ
チ・オークション・オーダーのフローを表示する。トレーダーワークステーショ
ン２０の１人でユーザーが作成した対話／スイッチ・オーダーで始まり、最初に
、中央処理センター１２は、グループ・サーバ・メカニズム３２で対話／スイッ
チ・オーダー７１２を受け取る。グループ・サーバ・メカニズム３２では、オー
ダー記録が生成され、ユーザーの信用プリファレンスを検査してユーザーの現在
の信用プリファレンスに対する取引確認を保証し、売買オーダーを生成する。オ
ーダーが受動である場合、オーダーは市場在庫モジュール３８に移動し、そこで
そのオーダーがトレーダーワークステーション２０に配布されて、システム１０
にログ・オンしたユーザーのそれぞれの市場詳細インタフェース３０２を介して
閲覧される。オーダーが能動である場合、オーダーは市場在庫モジュール３８に
移動し、そこでそのオーダーがオークションの一部である場合は、取引マッチン
グが発生し、またそのオーダーの事前実行がなされる。事前実行は、例えば終端
検査を含み、信用プリファレンスの最新の更新および複合検査を完了することを
保証する。さらに、ユーザーに透過な方法で、市場在庫モジュール３８は、取引
の当事者であるそれぞれのユーザーのトレーダーワークステーション２０に対し
、肯定応答の応答を要求して、通信の紛失がないことまたはユーザーの１人がロ
グ・オフしていないことを確認する。肯定応答を受信すると、市場在庫モジュー
ル３８は取引を実行し、次に更新された量および状態をシステム１０にログ・オ
ンしたユーザーに発行し、ユーザーはユーザーのそれぞれのコマンド・センター
・インタフェース１３０を介して閲覧できる。

【０２４７】 次に、実行モジュール４０は、取引の当事者であった１人のユーザーの要求に
応じて、ｗｉｌｌ−ｄｏ−ｍｏｒｅ（さらに多くの取引を実行する）機能を介し
て取引量を増加できる。これは一般に、商品の全数量を売買しない場合である。
そうでない場合、実行モジュールは確認プロセスを起動し、その確認プロセスに
は、取引の当事者であったユーザーのどちらかが条件交渉に入る機会を含む。

【０２４８】 オーダーは決済モジュール４２に達し、そこで決済プロセスを起動する。決済
モジュールは記号分解をして、ユーザーが契約の厳密な条件を閲覧できるように
する。さらに、決済モジュールはプロセスが終了しているオーダーに基づいて手
数料を計算し、それによりオーダー実行プロセスの終了を記録する。

【０２４９】 オークションの場合、オークション・オーダー７１４はオークション・メカニ
ズム３４により受信される。オークション・モジュール３４により、本発明のオ
ークションおよびスイッチ・オークション機能が可能になる。最初に、オークシ
ョン・モジュールは、実際のオークション時間に対するカウントダウン中に複数
のユーザーからオークション・オーダー７１４を受信する。オークション時間に
達し、オークション・オーダーが提示されると、オークション・メカニズム３４
は考慮に入れたユーザーの信用プリファレンスを用いてオークション・マッチン
グを実行する。オークション・メカニズム３４により実行されるオークション・
マッチングは、本発明に従っており、すなわち、オークションは公正価格を基に
して、作成されたチケットの最少の数を持つ取引される最大量に対して実行され
る。オークション・メカニズム３４から、契約相手がマッチングを完了すると、
市場在庫サーバは、結果として生じるオークション・オーダーを基本的に対話／
スイッチ・オーダー７１２として扱う。特に、市場在庫モジュール３８はオーダ
ー・マッチング、事前実行、肯定応答、取引実行、および量／データ発行を実行
する。

【０２５０】 オークション・オーダー７１２は実行モジュール４０に送られる。実行モジュ
ール４０では、オークション・オーダーおよびスイッチ・オークション・オーダ
ーは、少し異なった取引が行われる。例えば、オークション・オーダーは、ｗｉ
ｌｌ−ｄｏ−ｍｏｒｅ（さらに多くの取引を実行する）機能を介してオークショ
ン・オーダーの当事者であるユーザーの１人により、量が増やされる。一方、ス
イッチ・オークション・オーダーはこの機能を使用しないが、直接確認プロセス
に進む。さらに、オークション・オーダーが条件交渉機能を使用して非商用の条
件交渉を行う場合、スイッチ・オークション・オーダーは、確認後、決済モジュ
ール４２に直接入る。次に、オークション・オーダーおよびスイッチ・オークシ
ョン・オーダーは両方とも決済モジュール４２により受信される。この決済モジ
ュール４２では、対話／スイッチ・オーダー７１２に対して行われるのと同様に
、オークション・オーダーに対して基本的に同一動作を実行する。詳細には、決
済オーダー４２は同様の分解およびオーダー・プロセスを完了する手数料計算を
行う。

【０２５１】 ５．直接対話機能 本発明は、直接対話機能と呼ばれ、オンライン取引システムを通じて直接行わ
れる交渉および取引、および自動的に両方の当事者の処理システムに売買データ
を直接ロードしたり、取引確認プロセスを完了したりするために使用できる電子
チケットの作成などに対して、デリバティブトレーダーに優れた柔軟性を提供す
る。有利には、両方の当事者が、基本的に取り入れられたデータの変更なしに同
時に同じデータを得る。結果として、トレーダーは従来システムに比べ、取引を
より迅速により効果的に行うことができる。

【０２５２】 好ましくは、本発明は電子取引システムに必須のコンポーネントを実装してお
り、さらに本発明はデリバティブ取引システムに関連付けて開示されているが、
有用性および機能性においてこれに限定されない。本発明は、デリバティブだけ
ではなく、実質上あらゆる金融商品の電子取引システムで実現することができる
。それにもかかわらず、本発明の例示の実施形態は、上に開示されている電子デ
リバティブ取引システムとの関連で述べられている。このシステムは、以後は、
Ｂｌａｃｋｂｉｒｄ(商標）システム１０と呼ぶ。

【０２５３】 図３５によれは、本発明による電子取引システム７１０は、通信ネットワーク
７１６を介してトレーダーのワークステーション７１４と通信を行う中央処理セ
ンター・サーバー７１２を含む。本発明は、Ｂｌａｃｋｂｉｒｄ(商標）システ
ム１０のような基礎となる電子取引システムの、電子チケット・アプリケーショ
ン７１８といった、一体化されるかまたはバンドルされたソフトウェア・コンポ
ーネントとして実現することができる。

【０２５４】 好ましくは中央処理センター７１２およびトレーダー７１４は、相互に連動し
て動作し、クライアント・サーバー構成のような本発明が動作する電子取引シス
テムを実現する。ただし、基礎のなる電子取引システムのシステム・アーキテク
チャは本発明に実質的に強い影響は与えない。したがって、トレーダーおよび中
央処理センターの構成要素に対して利用可能な具体例の形態と範囲は、本発明お
よびその実現にまで及ぶ。例えば、電子取引システムのトレーダーのワークステ
ーション・インタフェースがＰＤＡデバイスに実装されている場合、本発明のイ
ンタフェースは、類似したＰＤＡインタフェースを通じて実現されるであろう。

【０２５５】 本発明によれば、トレーダー７１４は通信ネットワーク７１６を通じて中央処
理センターと通信するだけではなく、相互に通信を行うことができる。通信ネッ
トワーク７１６は２人またはそれ以上の当事者を結びつけることができる、あら
ゆるデータまたは音声ネットワークであってもよい。その結果、通信ネットワー
クは、例えば、当事者間およびトレーダー７１４と中央処理センター７１２間の
インターネット・プロトコル、ファクシミリ、音声通信をサポートする。加えて
、プライマリ・ネットワークの障害の発生時に適切に即座にバックアップが行わ
れるために、いくつかのトレーダー７１４が通信ネットワーク７１６の複数と接
続していることが好ましい。この多重アクセス方式を用いて、本発明の好ましい
実施形態は予測されるユーザーへの広範な可能なアクセスを提供できる。

【０２５６】 電子チケット・アプリケーション７１８は、売買について合意すると、電子チ
ケットを作成する能力をトレーダーに提供し、そこでの電子チケットは標準的な
使用／処理が容易な形式となる。トレーダーが希望するあらゆる手段を使用して
取引条件を交渉できるが、従来は電話で行われていたこととほぼ同様の方法で、
トレーダーがオンラインで交渉することもできる、基礎となる電子取引システム
により提供される安全なチャット・アプリケーションといったポイント・ツー・
ポイント・メッセージングを利用することが好ましい。代わりに、トレーダーが
電話を使用して接続することを希望する場合、有利には電子チケットを作成し、
ポイント・ツー・ポイント・メッセージおよび確認を行うために本発明を使用す
ることができる。ポイント・ツー・ポイント・メッセージングは、当業者には明
らかな、多くの形式を利用できるが、ライブ・チャット・セッションが好ましい
。 好ましくは、電子取引システムには、例えばアドレス、法的主体（ＬＥ）、ビ
ジネス・ユニット（ＢＵ）、連絡方法、決済の詳細など、登録されている各トレ
ーダーのための取引プロファイル情報が含まれている。Ｂｌａｃｋｂｉｒｄ(商
標）システムにおいて、記号法は例えば、価格、量、買い手／売り手、取引デー
タ（必要な場合）、および条件交渉項目が取引条件の定義のために提供される。

【０２５７】 電子チケット・アプリケーション７１８により、トレーダーは取引が行われる
金融商品を選択し、さらに取引チケットを作成することができる。この選択プロ
セスはリストからの選択のように簡単か、またはあらゆる必要な条件を用いた記
号の形成のように複雑である。有利には、Ｂｌａｃｋｂｉｒｄ(商標)システムの
記号法により、トレーダーはデリバティブを定義する条件を見る記号または別名
を分解できる。これにより、トレーダーは、冗長で時間のかかるプロセスである
、電話またはファックスによって言葉の上で読む長く退屈なプロセスなしで、取
引が行われる商品に関して迅速に合意に達し、商品の条件を確認することができ
る。商品が選択されると、電気チケット・アプリケーション７１８はトレーダー
に対して電子チケットを作成する。電子チケットを作成し、ここで述べるように
、ＸＭＬまたはその他の標準的なメッセージ・プロトコルを使用して電子処理の
ために電子取引チケットおよび確認がトレーダーに転送される。特に、電子取引
チケットは、取引のライフサイクル内の記録保持および取引状態のために有利で
ある。

【０２５８】 図３６〜４０では、本発明の実施形態の動作を示している。最初に、非公開２
方向交渉に入ることを望むトレーダーは、図３６に示すチャット・スクリーン７
２０を利用する。好ましくは、チャット・スクリーンはＢｌａｃｋｂｉｒｄ(商
標）システムにインタフェースの１つから起動される。チャット対話を起動した
いトレーダーは、リスト７２２から別のトレーダーの名前をクリックする。好ま
しくは、有効なトレーダーのすべてまたは一部がリスト７２２に含まれ、そのリ
ストには、フル・ネーム、法的主体、取引される商品の通常クラス、取引される
通貨を含む。この情報は電子取引システム７１０に結合された１つまたは複数の
データベースから検索できる。これにより、別の会社の特定トレーダーを即座に
、容易に識別できる。これによりさらに、２人のトレーダーが取引の条件を非公
開に交渉でき、またそのセッションの２人の当事者だけが対話を見ることができ
る。しかしトレーダーは、複数のトレーダーを選択して、チャット・セッション
で発生したメッセージがセッションに参加しているトレーダーの各々に通信され
るようにして、通信できる。一般にはチャット交渉が望ましいが、トレーダーは
、従来からなされている電話またはファクシミリなどの別の手段で通信できる。

【０２５９】 Ｓｅｌｅｃｔ Ｉｎｓｔｒｕｍｅｎｔ（商品選択）およびＧｅｎｅｒａｌ Ｔ
ｉｃｋｅｔ（チケット作成）ボタン７２４を選択することにより、ユーザーは取
引する商品を選択して、電子チケットの作成を起動できる。どちらの当事者もそ
のチケットを使用して、以下に詳細に述べるように、売買データをそれぞれの処
理システムに自動的にロードできる。表示ウィンドウ７２６は、電子トレーダー
システム７１０に現在ログ・オンしているトレーダーを識別する。これは基本的
に、非公開交渉を起動したいトレーダーからのリストであり、交渉するどれかの
相手を選択できる。左から右に、各列は各トレーダーを識別する特性を含む。こ
れには例えば名前、会社名（法的主体名および／またはビジネス・ユニット名）
、ユーザーが最も多く取引するデリバティブ／金融商品のタイプ、そのトレーダ
ーの望ましい通貨を含む。

【０２６０】 チャット表示ウィンドウ７２８は、トレーダー間で作成された文の時間順の結
果を提供する。ウィンドウ７２８は、例えば、以下のような情報（それの一部は
図の実施形態に示される）、すなわちコメントが作成された時間、文を作成する
個人、個人がタイプ・インしメッセージを一覧表示する。メッセージ表示ウィン
ドウ７３０は、トレーダーによりタイプされた（すなわち入力された）メッセー
ジを表示する。トレーダーがキーボードのエンター・ボタンまたはチャット・ス
クリーン７２０の送信ボタン７３２を選択すると、メッセージ表示ウィンドウ７
３０のメッセージは他のトレーダーに送信され、チャット表示ウィンドウ７２８
に最終エントリとして挿入される。

【０２６１】 チャット・セッション中にトレーダーが取引の条件を決定し、条件に同意する
と、どちらかのトレーダーも、図３７に示す商品選択スクリーン７３４を起動す
るＳｅｌｅｃｔ Ｉｎｓｔｒｕｍｅｎｔ（商品選択）およびＧｅｎｅｒａｔｅ
Ｔｉｃｋｅｔ（チケット作成）ボタン７２４を選択することにより、取引チケッ
ト作成を起動できる。この商品選択スクリーン７３４により、ユーザーは、（１
）１つまたは複数のダウン−ダウン・メニュー７３６（例えば）から取引される
金融商品のタイプ（すなわち、クラス、通貨、および／またはＢｌａｃｋｂｉｒ
ｄ(商標）の記号法で定義された記号）を選択し、および（２）Ｂｌａｃｋｂｉ
ｒｄ(商標）の記号法で定義される選択可能なオプション７３８を介して適切な
条件を選択することができる。これには記号、パラメータ、取引日、通貨等を含
む。さらに、トレーダーはＥｘｐｌｏｄｅ（分解）ボタンを介して分解して、売
買の開始および終了日、変動金利オプション、発生原則等を含む取引の明細を見
ることができる。さらに別に、トレーダーはＢｕｉｌｄ（形成）ボタン７４２を
介してトレーダー自身の商品を形成できる。これによりトレーダーは、両者がす
べての条件に同意することを保証できる。

【０２６２】 トレーダーが商品を選択し、記号を形成すると、トレーダーは、図３８に示す
オーダー作成スクリーン７５０を起動するスクリーン７３４のＧｅｎｅｒａｔｅ
（作成）ボタン７４４を選択する。このインタフェースは、Ｂｌａｃｋｂｉｒｄ
(商標）システムの「Ｐｌａｃｅ Ｏｒｄｅｒ（オーダー発行）」スクリーンと
類似の機能を持つ。オーダー作成スクリーン７５０は、ウィンドウ７５２内に選
択された商品を表示し、そのスクリーン７５０によりユーザーは選択可能オプシ
ョン７５４を介して特定契約条件を選択できる。例えば、トレーダーは買手およ
び売手、取引の金融会社当事者、価格、数量、交渉の必要な追加条件（すなわち
、条件交渉を介して定義される）等を指定する。必要に応じて、トレーダーはＥ
ｘｐｌｏｄｅ（分解）ボタン７５６により商品を分解できる。トレーダーがＧｅ
ｎｅｒａｔｅ（作成）ボタン７５８を選択して、取引チケット（確認チケットと
も呼ばれる）を作成できる。この例は、図３９に示されている（当業者には理解
されるように、図５には取引チケットの第１ページだけが示されている）。 Ｂｌａｃｋｂｉｒｄ(商標）システムによれば、両方のトレーダーが確認する
と、取引がＢｌａｃｋｂｉｒｄ(商標）システム上で実行された場合には、両者
は条件交渉に入るオプションを与えられる。 取引を開始するトレーダーが作成オーダー・スクリーンのＧｅｎｅｒａｔｅ（
作成）ボタン７５８を選択すると、両方のトレーダーは電子取引チケットを受け
取る。取引チケットは以下の形式のすべてまたは一部、または任意の他の適当な
形式にできる。すなわち、オン・スクリーン／ＨＴＭＬ、Ｂｌａｃｋｂｉｒｄ(
商標)取引記録簿に含まれる、ペーパー／ファックスＢｌａｃｋｂｉｒｄ(商標)
チケット、ＩＳＤＡ確認形式、ＸＭＬ、またはフラット・ファイルの形式にでき
る。本発明の実施形態では、トレーダープリファレンス形式はトレーダーまたは
トレーダーの法的主体により事前選択して、そのトレーダーに対して作成された
取引チケットで、事前選択された形式で形式の作成ができる。これにより、トレ
ーダーのシステムで処理するために、電子取引チケットを別の形式に変換する必
要がなくなる。

【０２６３】 図４０には、本発明の実施形態による電子チケット作成アプリケーション７１
８の動作方法を示すフローチャートを示す。ステップ７６０で、トレーダーは、
Ｂｌａｃｋｂｉｒｄ(商標）システムの一体化コンポーネントであるのが望まし
い、安全チャット・ルーム・アプリケーションをオープンする。ステップ７６２
では、次にトレーダーは、提供されたリストの有効な契約相手から、交渉する相
手の当事者を選択する。電子チケット作成アプリケーション７１８を電子取引シ
ステムに一体化する利点は、各見込みのある契約相手に関する情報を、有効なト
レーダーのリストを持つユーザーにアクセスして、提示できることである。トレ
ーダーが１人または複数の見込みのある契約相手を選択すると、ステップ７６４
に示すように、すでに公知のように、当事者はチャット機能を使用して売買条件
の交渉を開始する。ステップ７６６において、トレーダーが売買の最終条件を決
定したことが判明する場合、トレーダーの一方は、Ｓｅｌｅｃｔ Ｉｎｓｔｒｕ
ｍｅｎｔ（商品選択）およびＧｅｎｅｒａｔｅ Ｔｉｃｋｅｔ（チケット作成）
ボタンを選択して、自動チケット作成プロセスを起動する。これと異なり、ステ
ップ７６６において、当事者が取引の最終条件を決定しないことが判明する場合
、当事者は、ステップ７６４で、条件の交渉を続行する。トレーダーがＳｅｌｅ
ｃｔ Ｉｎｓｔｒｕｍｅｎｔ（商品選択）およびＧｅｎｅｒａｔｅ Ｔｉｃｋｅ
ｔ（チケット作成）ボタンを選択すると、トレーダーは取引される商品および契
約条件を識別する。次に、ステップ７７２で、トレーダーは電子チケットが識別
商品および条件に従って作成されることを要求する。

【０２６４】 取引チケットが作成されると、そのチケットはデータベースに格納され（これ
は、トレーダーまたは必要な許可および／または認証を有する第３当事者のデー
タベース対し、Ｂｌａｃｋｂｉｒｄ(商標）システム・データベースにできる）
、それにより、以下の機能を可能にする。すなわち、後にリコール、監査、自動
確認、プロセス状態（すなわち、チケットが処理され、メッセージが受け取られ
、状態が更新されるとき）。例は「ファックスされる」、「ＸＭＬファイルが送
信される」、「同意」、「．．．で処理される」「満期になる」等を含む。

【０２６５】 前述の説明および関連図面に示された内容の利益を有する本発明に、多くの変
更およびその他の具体化が考えられることは、当業者には明らかであろう。した
がって、本発明は、開示された特定の実施形態に限定されず、その変形形態およ
び他の実施形態も添付の特許請求の範囲に含まれるものとする。本明細書では特
定用語を使用しているが、それらは一般的な、説明的意味で使用されているだけ
であり、限定の目的ではない。

【図面の簡単な説明】

【図１】 本発明の１つの実施形態による電子取引システムを実現するコンピュータ・ネ
ットワークの概略図である。

【図２】 本発明の１つの実施形態による中央処理センターのアーキテクチャと機能とを
示すブロック図である。

【図３】 本発明の１つの実施形態によるとトレーダーシステムのアーキテクチャと機能
とを示すブロック図である。

【図４】 本発明の１つの実施形態によるビジネス・ユニット・プロキシのアーキテクチ
ャと機能とを示すブロック図である。

【図５】 コマンド・センター・インタフェースの例である。

【図６Ａ】 ユーザー・プリファレンスインタフェースの異なるタブ部分の例である。

【図６Ｂ】 ユーザー・プリファレンスインタフェースの異なるタブ部分の例である。

【図７】 信用プリファレンス設定インタフェースの例である。

【図８Ａ】 変更信用グループ・インタフェースの異なるタブ部分の例である。

【図８Ｂ】 変更信用グループ・インタフェースの異なるタブ部分の例である。

【図９Ａ】 新しいバイナリ・インタフェースおよび複合プリファレンス・インタフェース
のそれぞれの例であり、信用プリファレンス設定インタフェースからアクセスで
きる。

【図９Ｂ】 新しいバイナリ・インタフェースおよび複合プリファレンス・インタフェース
のそれぞれの例であり、信用プリファレンス設定インタフェースからアクセスで
きる。

【図１０】 ビジネス・ユニット情報インタフェースの例である。

【図１１】 本発明の実施形態による信用プリファレンス論理を示す。

【図１２】 市場エントリ・インタフェースの例である。

【図１３】 記号定義インタフェースの例である。

【図１４Ａ】 受動オーダー・インタフェースの例である。

【図１４Ｂ】 ヒット・オーダー・インタフェースの例である。

【図１５】 市場詳細インターフェースの例である。

【図１６】 未決済オーダー記録表インタフェースの例である。

【図１７】 クライアント・モニター・インタフェースの例である。

【図１８】 実行通知および数量交渉インタフェースの例である。

【図１９】 契約条件交渉インタフェースの例である。

【図２０】 ユーザーポジションポートフォリオ・インタフェースの例である。

【図２１】 スイッチ・インタフェースの例である。

【図２２Ａ】 オークション・インタフェースおよびスイッチ・オークション・インタフェー
スのそれぞれの例である。

【図２２Ｂ】 オークション・インタフェースおよびスイッチ・オークション・インタフェー
スのそれぞれの例である。

【図２３】 本発明の１つの実施形態によるメイン・スクリーン・インタフェースの例であ
る。

【図２４】 本発明の１つの実施形態による信用プリファレンス機能のフローチャートであ
る。

【図２５】 本発明の１つの実施形態による主題ベースのアドレス指定機能のフローチャー
トである。

【図２６】 本発明の１つの実施形態による取引において実行されるフローチャートである
。

【図２７Ａ】 本発明の１つの実施形態による、オーダーへのユーザー登録およびオーダーへ
のユーザー・アクションの面からの取引において実行されるそれぞれのフローチ
ャートである。

【図２７Ｂ】 本発明の１つの実施形態による、オーダーへのユーザー登録およびオーダーへ
のユーザー・アクションの面からの取引において実行されるそれぞれのフローチ
ャートである。

【図２８】 本発明の１つの実施形態によるポジションの発見についての機能のフローチャ
ートである。

【図２９】 本発明の１つの実施形態によるオークション機能のフローチャートである。

【図３０】 本発明の１つの実施形態によるオークション機能の詳細フローチャートである
。

【図３１】 本発明の１つの実施形態による平均オークション価格計算のフローチャートで
ある。

【図３２】 本発明の１つの実施形態によるオークションで実行されるマッチングのフロー
チャートである。

【図３３】 本発明の１つの実施形態によるオークションにおいて得られたオーダーの確認
のフローチャートである。

【図３４】 本発明の１つの実施形態による中央処理センターの動作および機能を示す処理
フロー図である。

【図３５】 本発明の１つの可能な実施形態の高度な実現例である。

【図３６】 本発明の１つの実施形態によるチャットインタフェースの例である。

【図３７】 本発明の１つの実施形態による商品選定インタフェースの例である。

【図３８】 本発明の１つの実施形態によるオーダー発生インタフェースの例である。

【図３９】 本発明の１つの実施形態により作成された取引チケットである。

【図４０】 本発明の１つの実施形態による方法を示すフローチャートである。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ，ＴＲ)，ＯＡ(ＢＦ ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ， ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，Ｇ Ｍ，ＫＥ，ＬＳ，ＭＷ，ＭＺ，ＳＤ，ＳＬ，ＳＺ，ＴＺ ，ＵＧ，ＺＷ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ， ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＧ，ＡＬ，ＡＭ， ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，Ｂ Ｚ，ＣＡ，ＣＨ，ＣＮ，ＣＯ，ＣＲ，ＣＵ，ＣＺ，ＤＥ ，ＤＫ，ＤＭ，ＤＺ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ， ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，Ｉ Ｓ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＡ，ＭＤ，ＭＧ， ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＭＺ，ＮＯ，ＮＺ，ＰＬ，Ｐ Ｔ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ，ＵＳ， ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ

Claims (10)

【特許請求の範囲】
1. 【請求項１】 電子取引システムにおいて電子取引チケットを作成する方法
   であって、 少なくとも２つのトレーダー間で電子チャット・セッションを起動して、金融
   商品売買の契約条件を交渉するステップと、 トレーダーが売買することに同意した選択された金融商品を示す、前記システ
   ムへのトレーダー入力を受付けるステップと、 トレーダーが同意した金融商品の売買を定義する契約条件を示す、前記システ
   ムへのトレーダー入力を受付けるステップと、 前記売買のための電子取引チケットを作成するステップと、 該電子取引チケットをトレーダーに送信するステップと を含む方法。
2. 【請求項２】 前記電子取引チケットを作成するステップが、ファックス文
   書の形式の電子取引チケットを作成するステップを含むものである、請求項１に
   記載の方法。
3. 【請求項３】 前記電子取引チケットを作成するステップが、ＸＭＬファイ
   ルの形式の電子取引チケットを作成するステップを含むものである、請求項１に
   記載の方法。
4. 【請求項４】 選択された金融商品を分解して、該金融商品のトレーダー定
   義の構成要素を明示するステップをさらに含む請求項１に記載の方法。
5. 【請求項５】 選択された金融商品を示す、前記システムへのトレーダー入
   力を受け取るステップが、該金融商品の１つまたは複数のクラス、通貨および記
   号の表示を受け取るステップを含む、請求項１に記載の方法。
6. 【請求項６】電子取引システムにおいて電子取引チケットを作成するシステ
   ムであって、 少なくとも部分的に取引メカニズムを使用して電子取引を管理する、金融商品
   の電子取引システムと、 少なくとも２つのトレーダーにより電子取引システムの取引メカニズムの外部
   で交渉される売買のために、電子取引チケットを作成する電子チケット作成アプ
   リケーションと、 を備えたシステム。
7. 【請求項７】 前記電子チケット作成アプリケーションが、トレーダーが売
   買することに同意した選択された金融商品を示すトレーダー入力と、トレーダー
   が同意した金融商品の売買を定義する契約条件とを受け取るものである、請求項
   ６に記載のシステム。
8. 【請求項８】 前記電子取引システムが金融商品定義のための記号方式をサ
   ポートしている請求項６に記載のシステム。
9. 【請求項９】 前記電子チケット作成アプリケーションが、ファクシミリ文
   書およびＸＭＬファイルの１つとして形式化された電子取引チケットを作成する
   ものである、請求項６に記載のシステム。
10. 【請求項１０】 前記電子チケット作成アプリケーションにより、トレーダ
    ーが金融商品を分解して金融商品のトレーダー定義の構成要素を明示できる、請
    求項６に記載のシステム。