JP2004537797A - 会話型ディーリングシステム - Google Patents

Abstract

会話型トレーディングシステムは、単一のユーザインターフェイスから、たとえば外国為替商品のような金融証券などの複数の証券を取引することを可能にする。インターフェイスは、取引リストと取引詳細パネルとボタンバーとを含む取引スタックを含む。取引リストは、ステータス、当事者、証券、証券およびステータス関連ストリングなどの取引関連情報をすべての証券に対して共通の形式で表示する。新たなクォートリクエストが検出されるたびに新たな会話が始まる。これは、既存の会話と同じ当事者であってもよい。会話は１行ずつパーズされ、ユーザは、会話がカウンターパーティに送られる前にそれを編集することができる。パーサーは取引の記録をまったく保存せず、インターフェイスにより、アプレットとしてダウンロードされ得る。

Description

【０００１】
【関連出願との相互参照】
この出願は、２００１年１月３日提出の米国特許出願番号第０９／７５３９４０号および２００１年７月３０日提出の米国特許仮出願連続番号第６０／３０８６１８号について優先権を主張する。これら出願はここにその全体として援用により引用される。
【０００２】
【発明の分野】
この発明はディーリングシステムに関し、より特定的には当事者間で証券の取引をする会話型ディーリングまたはトレーディングシステムに関する。これは排他的ではないが、特定的にさまざまな金融証券をトレーディングする金融トレーディングおよびディーリングシステムに関する。この発明は、特にトレーダによってシステムに入力される会話メッセージのパーズに関する。
【０００３】
【発明の背景】
コンピュータシステムを用いて金融証券をトレーディングすることは、一般化している。これは、トレーダーが立会場で直接対面してトレーディングするオープン・アウトクライトレーディング方法に大きく取って代わった。外国為替スポット（ＦＸスポット）、金利先渡契約（ＲＦＡ）および他の証券のような異なった証券をトレーディングするための、さまざまなコンピュータ化されたトレーディングシステムが開発された。いくつかのシステムは匿名であって、取引のカウンターパーティは取引がダン（成立）するまで、マーケットの他のカウンターパーティの身元を知らない。イー・ビィ・エス・ディーリング・リソーシーズ・インコーポレイテッド（ＥＢＳ Ｄｅａｌｉｎｇ Ｒｅｓｏｕｒｃｅｓ， Ｉｎｃ．）およびロイター（Ｒｅｕｔｅｒｓｐｌｃ．）は、成功している匿名トレーディングシステムを数年にわたり運営している。後者の企業はまた、ロイター２０００／１として公知である会話型ディーリングシステムを運営するが、これは取引を行なうトレーダーの間の会話型のやりとりをコンピュータ化し、トレーダー間の商談を可能にするものである。
【０００４】
既存のディーリングシステムは、単一の証券をトレーディングするトレーダーをサポートしがちであった。所与のトレーダーが単一の証券のみをトレーディングする大きな機関においては、これはどのような問題も招かない。しかしながら、より小さな機関においては、たとえば外国為替トレーダーは１つ以上の通貨ペアについて数種類の証券をトレーディングし得る。そのようなトレーダーにとって、いくつかの異なったトレーディングシステムを用いなければならないことや、またはコンピュータ化されたシステムとボイスブローカーのような従来のトレーディング方法を併用しなければならないことは、不便である。
【０００５】
したがって、特に小さな機関におけるトレーダーのための、いくつかの証券トレーディングを単一のプラットフォームに統合してトレーディングを簡略化することに対する必要性が存在する。
【０００６】
外国為替市場のような金融市場は、極めて速く動き得る。ディーラーは、潜在的な取引を逃さないようほぼ瞬間的に市場の動きに反応することが求められる。その結果、トレーダー端末は視覚的に非常に単純であって、トレーダーが新しいまたは変化した情報を吸収するのが容易でなければならない。単一の端末からいくつもの異なった証券をトレーディングできる能力は、複雑さを増し、かつトレーダーにより多くの情報を提示することになりかねない。
【０００７】
いずれかの一時点において、トレーダーは、いくつかはダンになり他は完了前のどこかの段階でキャンセルされる多くの取引に関わり得る。これらの取引は、さまざまな証券にわたり得る。これらの取引の各々は、トレーダーが取引ができるよう見ることが可能でなければならない証券特有情報を有する。しかしながら、この情報のすべてをスクリーンに表示すると、トレーダーが視覚的にスクリーンを理解することが困難になるので、不所望である。
【０００８】
ロイターは、ロイターディーリング２０００／１の商標のもとに従来のディーリングシステムを運用する。このシステムでは、トレーダは、実行したい取引に関連する端末に会話テキストをタイプする。会話テキストは、取引関連内容を有しても取引に関連する情報を含んでもよい。システムは、会話を、システムに入るとともに一文字ベースで送る。取引が完了するとき、当事者は取引を確認するよう求められ、取引の契約条件を再交渉してもよい。
【０００９】
ロイター２０００／１システムは、数年にわたり成功裏に運用されてきたが、パーズについてとられているアプローチにいくつかの不利益があることを我々は理解した。この発明は、そのさまざまな局面においてこれらの不利益を克服し会話型ディーリングシステムでの改良されたパーズを提供し、そして、トレーダや機関にとってのこのようなシステムの有用性と受容しやすさとを改善することである。
【００１０】
【発明の要約】
この発明の第一の局面は、取引ステータスの変化を示す会話における用語を検出するためのパーズの使用にある。
【００１１】
より特定的には、カウンターパーティ間で証券をトレーディングするための会話型ディーリングシステムが提供され、該会話型ディーリングシステムは、取引関連情報を含むトレーダ会話メッセージを入力および表示するためのユーザインターフェイスを各々有する複数のトレーダー端末を含み、該トレーダー端末は通信ネットワークを介して互いと通信し、該トレーダ端末は各々前記入力される会話メッセージをパーズするためのパーサをさらに含み、前記パーサは、取引のステータスの変化を検出するよう会話メッセージを分析するための手段を含み、該取引は、複数の可能なステータスを有し、前記パーサはさらに、取引の前記検出されたステータスに適した取引関連情報を検出するよう会話メッセージを分析するための手段と、取引ステータスと適切な取引関連情報とを含むパーズされたメッセージをユーザインターフェイスに返すための手段とを含む。
【００１２】
この発明のこの局面の実施例は、会話のパーズが極めて簡略化されるという利点を有する。第一の例では、パーサは、いくつかの可能な取引ステータスのみのうちのひとつの間でのステータスの変化を検出するだけでよい。ステータスの変化が検出されたとき、そのステータスに適した取引関連情報の用語は限られた数しかなく、パーズが極めて簡単になる。
【００１３】
この発明の第二の局面は、端末から提供される完全な会話メッセージにパーズを行うことである。さらに特に、カウンターパーティ間で証券をトレーディングするための会話型ディーリングシステムが提供され、該会話型ディーリングシステムは、各々会話メッセージとして取引関連情報をトレーダに対して入力および表示するためのユーザインターフェイスを有する複数のトレーダ端末を含み、該トレーダ端末は、通信ネットワークを通じて互いに通信し、該トレーダ端末はさらに、各々、前記入力された会話メッセージをパーズするためのパーサを含み、前記パーサは、取引関連情報を検出してパーズされたメッセージを形成するよう、ユーザインターフェイスから完全な会話メッセージを受け取りかつ完全なメッセージを分析するための手段と、パーズされたメッセージをユーザインターフェイスに返すための手段とを含む。
【００１４】
会話の完全なラインのパーズは、取引ステータスの変化などの第一の関数を見つけるためにメッセージをパーズすることができ、さらに、該第一の関数によって決まる態様でメッセージをパーズすることができる、構造的なパーズアプローチをとることを可能にするので、きわめて有利である。文字ごとにパーズを行う先行技術のシステムではこれは不可能である。
【００１５】
この発明の第３の局面は、パーズされたメッセージがカウンターパーティに送られる前に、パーズされたメッセージをユーザが見て変更することを可能にする。
【００１６】
さらに特に、カウンターパーティ間での証券のトレーディングのための会話型ディーリングシステムが提供され、該会話型ディーリングシステムは、各々会話メッセージとして取引関連情報をトレーダに対して入力および表示するためのユーザインターフェイスを有する複数の端末を含み、該トレーダ端末は、通信ネットワークを介して互いに通信し、該トレーダ端末は各々さらに、前記入力された会話メッセージをパーズするためのパーサを含み、前記パーサは、取引関連情報を検出しパーズされたメッセージを形成するようユーザインターフェイスからの会話メッセージを分析するための手段と、ユーザインターフェイスにパーズされたメッセージを返しパーズされたメッセージを表示するための手段と、カウンターパーティのトレーダ端末へのメッセージの送信前にパーズされたメッセージの内容を確認または変更するための手段とを含む。
【００１７】
いったん、パーズされたメッセージが形成されると、ユーザはそれを容認または編集またはキャンセルできる。カウンターパーティは、もしあれば最後に送られたメッセージしか見ることができない。したがって、もしトレーダが誤りを犯す、または気を変える、または市場状況が突然変化するなどすれば、トレーダは、さもなくば送られていたであろうメッセージを変更または削除できる。これは、トレーダにとって好都合であるだけでなく、トレーダのトレーディング位置およびその思考過程をトレーダが自分の位置に満足するまで明らかにする必要がないため、トレーダの市場位置についても非常に有利である。先行技術のシステムでは会話がタイプされるとともにパーズされており、これは不可能である。いずれの当事者も、いったん取引の契約が完了されれば取引契約条項をキャンセルまたは補正しようとすることができるが、それまでに、カウンターパーティに対して手のうちを見せてしまっており、望ましくない。
【００１８】
この発明のさらなる局面は、常に同じカウンターパーティと１以上の会話を行うことができる。もし、パーサが新しい取引に関連する情報を検出すれば、いつでも、その時点での取引のステータスにかかわらず、ユーザインターフェイスに通知し、新しい会話または取引が開始される。
【００１９】
さらに、カウンターパーティ間で証券をトレーディングするための会話型ディーリングシステムが提供され、該会話型ディーリングシステムは、各々取引関連情報を会話メッセージとしてトレーダに対して入力および表示するためのユーザインターフェイスを有する複数のトレーダ端末を含み、該トレーダ端末は、通信ネットワークを介して互いに通信し、トレーダ端末は各々、前記入力された会話メッセージをパーズするためのパーサをさらに含み、前記パーサは、取引関連情報を検出しパーズされたメッセージを形成するようユーザインターフェイスからの会話メッセージを分析するための手段と、パーズされたメッセージをユーザインターフェイスに返しパーズされたメッセージを表示するための手段とを含み、該システムはさらに、トレーダからのリクエストでカウンターパーティとの取引を開始するための手段と、現在の取引に対し付加的な取引に関連する取引関連情報のパーサによる検出に際して、同じカウンターパーティとのさらなる取引を開始するための手段とを含む。
【００２０】
この発明のこの局面を具体化するシステムは、きわめて柔軟であるという利点を有し、トレーダが働き考える態様に反応する。カウンターパーティとの取引交渉のいついかなる段階においても、もしトレーダが関連のない取引についてのクオートを要求すれば、システムはクオートリクエストを検出し、新しい取引を開始する。いずれの取引も、そしてさらなるどの新しい取引も、同時にしかし完全に互いから独立して進行しうる。先行技術のシステムは、どの一時点でも所与のカウンターパーティ内での単一の会話を可能にするのみである。
【００２１】
この発明のさらなる局面で、パーサは、取引成立過程の知識を保持しないという点で頭が悪い。パーサは、会話ラインをパーズし、取引ステータスと関連取引情報とを含むファイルを返す。
【００２２】
さらに特に、カウンターパーティ間で証券をトレーディングするための会話型ディーリングシステムが提供され、該会話型ディーリングシステムは、会話メッセージとして取引関連情報をトレーダに対して入力および表示するためのユーザインターフェイスを各々有する複数のトレーダ端末を含み、該トレーダ端末は、通信ネットワークを介して互いに通信し、該トレーダ端末は各々さらに、前記入力された会話メッセージをパーズするためのパーサを含み、前記パーサは、取引関連情報を検出しパーズされたメッセージを形成するようユーザインターフェイスからの会話メッセージを分析するための手段と、パーズされたメッセージをユーザインターフェイスに返しパーズされたメッセージを表示するための手段とを含み、パーズされたメッセージをユーザインターフェイスに返す際、パーサはパーズされたメッセージまたはパーズされたメッセージが関連する取引の記録を全く保持しない。
【００２３】
この発明のこの局面の実施例は、パーサが極めて簡単であるという利点を有する。さらに、パーサは経時的情報を記憶しないため、ユーザがシステムにログオンするたびにユーザへ、たとえばアプレットとして、これをダウンロードするのが容易である。このため、システムをインターネット環境での使用に適切とし、トレーダが自身のワークステーションにパーサをロードする必要がないためトレーダがシステムにアクセスするのを極めて容易にする。さらに、銀行または他の金融機関などのユーザ機関におけるＩＴ支援の諸経費を減少させる。
【００２４】
この発明のさらなる局面において、パーズされたメッセージのフィルタリングのレベルがトレーダ端末間に導入される。これによって、パーズされたメッセージがチェックされ、それらがシステムの運用規則または営業に確実に一致するようにできる。
【００２５】
さらに特に、カウンターパーティ間で証券をトレーディングするための会話型ディーリングシステムが提供され、該会話型ディーリングシステムは、各々トレーダに対して取引関連情報を会話メッセージとして入力および表示するためのユーザインターフェイスを有する複数のトレーダ端末を含み、該トレーダ端末は、通信ネットワークを介して互いに通信し、該トレーダ端末は各々さらに前記入力された会話メッセージをパーズするためのパーサを含み、前記パーサは、取引関連情報を検出してパーズされたメッセージを形成するようユーザインターフェイスからの会話メッセージを分析するための手段と、パーズされたメッセージをユーザインターフェイスに返しパーズされたメッセージを表示するための手段とを含み、該システムはさらに、取引関連情報を含むパーズされたメッセージをトレーダ端末から受け取りパーズされたメッセージを行先端末に分配するためのサーバを含み、該サーバは、行先トレーダ端末への通信前にトレーダ端末から送られるパーズされたメッセージの許容可能性をチェックし、拒否されたメッセージを行先トレーダ端末に通さずに許容されないパーズされたメッセージは拒否するための手段を含む。
【００２６】
この発明のこの局面は、当事者が取引に合意しなくとも、不法な取引はフィルタリングされうるという利点を有する。さらに、フィルタリングは、各当事者が取引を完結させるに十分な資金を持っていることを確実にするよう信用度チェックを含んでもよい。信用度チェックは、設定期間中にどのカウンターパーティが完了できるトレーディングについても典型的には限界を設ける機関信用システムに統合されてもよい。
【００２７】
もし、パーズされたメッセージが許可できないとして拒否されれば、意図された受け手はメッセージが送られたことを知ることがない。トレーダはトレードが可能なとき以外は自分のディーリング位置についての情報を開示しないので、これは有利である。
【００２８】
この発明のこの局面はさらに、しばしば極めて変化しやすく速く動きつづけている市場において、締結されれば許可できないものとして拒否されるであろうトレードのためにトレーダが時間を無駄にすることを防止するので有利である。
【００２９】
この発明のさらなる局面において、ユーザインターフェイスに表示されるメッセージは、その出所によって色分けされる。
【００３０】
さらに特に、カウンターパーティ間で証券をトレーディングするための会話型ディーリングシステムが提供され、該会話型ディーリングシステムは、各々取引関連情報を含む会話メッセージをトレーダに対して入力および表示するためのユーザインターフェイスを有する複数のトレーダ端末を含み、該トレーダ端末は通信ネットワークを介して互いに通信し、該会話メッセージは色分けされた形で表示され、会話メッセージの出所をユーザに対して示す。
【００３１】
好ましい一実施例では、ユーザにより生成されたメッセージは第一の色で示され、カウンターパーティによって生成されたメッセージは第二の色で示され、システムによって生成されたメッセージは第三の色で示される。システムメッセージは、ユーザまたはカウンターパーティ入力会話メッセージに基づいてパーズされたメッセージを含んでよい。
【００３２】
好ましくは、警告メッセージ、エラーまたは危険メッセージが各々さらなる色で示される。
【００３３】
この発明のこの局面は、ユーザディスプレイをはるかに読みやすくするという利点を有する。これは、どの時点においてもトレーダが多くの進行中の取引を有しているかもしれずトレーダが取引情報をきわめて迅速に分析する必要のある進行の早い市場においてはきわめて重要である。
【００３４】
この発明の実施例を例示目的でのみ、添付の図面を参照して説明する。
【００３５】
【ベストモードの説明】
図１に概略的に示されるシステムは、さまざまな金融証券をトレーディングするための会話型ディーリングシステムである。取引され得る証券は、これらに限定されるものではないが、外国為替（Ｆ／Ｘ）スポット、フォワード、およびアウトライトを含む。以下にＦ／Ｘスポットおよびフォワードに集中して説明するが、これは純粋にこの発明の例示目的であって、この発明はいかなる特定の金融証券にも、または金融証券にさえも限定されないことを理解されたい。これは、商品（ｃｏｍｍｏｄｉｔｙ）、金属のような他のどのような代替可能物の取引にも等しく適用可能である。
【００３６】
示されるシステムは好ましくはインターネットに基づくシステムであって、トレーダーはインターネットをわたってトレーダー端末から他のトレーダーと通信する。取引は、トレーダー間のメッセージの交換によって合意される。メッセージ内容は自動的にシステムによってパーズされて、取引関連内容を識別されて処理される。パーズによって取引ステータスの変化が検出されると、取引処理の残りは取引スタックによって扱われる。取引ステータスは会話によって入力される必要はなく、たとえばオンスクリーン機能ボタンまたはキーボード駆動メニューを用いてトレーダー端末から直接入力されてもよい。こうして、システムはユーザが非会話型の取引内容データの簡単な交換によって、または２つの方法の併用によって、取引することをも可能にする。
【００３７】
以下の説明は、トレーディングシステムであって、その中で取引を行なうためにトレーダーによってユーザインターフェイスが用いられるものの概要を示す。しかしながら、これはこの発明によって用いるのに適切なトレーディングシステムの一例に過ぎないことを理解されたい。この発明はいかなる特定のトレーディングシステムにも限定されるものではなく、トレーダーが多数の証券をトレーディングするどのようなシステムにも適用可能である。そのようなシステムは、インターネットに基づくか、または従来の公衆ネットワークまたは専用ネットワークで動作してもよい。これは分散アーキテクチャを用いるか、中央上位計算機を用いて動作するか、または他のどのような態様で構成されてもよい。
【００３８】
図１を参照して、開示されるトレーディングシステム１０はシステムイントラネット１４を介して接続する複数のサーバファーム１２に基づく。サーバファーム１２は、ここではインターネット１４である通信ネットワークと構内銀行イントラネット１８とを介して銀行立会場のトレーダー端末１６と通信する。ほとんどの取引処理はトレーダー端末１６で行なわれ、取引メッセージはサーバファーム１２からカウンターパーティのトレーダー端末１６に送られる。サーバファームはまた、ダンした取引情報を銀行の（図示しない）バックオフィスシステムに送って、取引チケットが処理され取引が確定されるようにする。取引は、直接トレーダーによって、または以下に説明するようにパーズされたトレーダー間で交わされた会話によってのいずれかで、システム１６に入力される。パーズはトレーダー端末で行なわれる。
【００３９】
図２は、ユーザ端末１６およびひとつのサーバファームを概略的に示す。二つを図示する複数のトレーダ端末１６が、サーバファームの部分を形成するシステムサーバを介して会話メッセージを交換することで互いにおよび（図示しない）他の端末と通信する。各クライアント端末１６は、三つの論理構成要素、すなわち、ユーザインターフェイス２０、通信モジュール２２およびパーサ２４を有する。クライアント端末は、典型的には、キーボードおよびマウスを含む入力装置ならびにユーザインターフェイスをトレーダに対して提示するモニタなどの通常の構成要素を有するＰＣまたはワークステーションなどの適切なコンピュータである。
【００４０】
トレーダ端末１６およびサーバ２６は、図１に示すように、私的なネットワークまたはワールドワイドウェッブを介するなどのインターネットなどの公的なネットワークであってよい通信ネットワークを介して通信する。通信モジュールは、たとえば、トレーダ端末もしくはクライアントのローカルエリアネットワークのモデムまたは他の適切な装置でよい。
【００４１】
パーサ２４は、トレーダ端末間で交換される会話の分析を行い、これらの会話交換から以下に詳細に示すように取引関連情報を抽出する。システムの機能的構成要素である、パーサ２４、ユーザインターフェイス２０、および通信モジュール２２用の通信ソフトウェアは、トレーダがシステムにログオンするごとにアプレットとしてトレーダ端末にダウンロードされることが好ましい。これは、クライアント端末がシステムにアクセスしランするために何のソフトウェアも記憶しなくてよく、ワールドワイドウェッブ上の適切なサイトにアクセスすることですべて行われるということを意味する。システム１０は、トレーダがどこにいるかにかかわりなく使用されうる。しかし、理解されるように、システムはきわめて多額の通貨および通貨産物、ならびに他の代替可能物をトレーディングするように意図されており、実際には、相当の信頼性が証明された銀行および他の機関に制限される。しかし、このシステムの可動性および柔軟性はトレーダにとって有利であり、アクセスが独占的ネットワークに限定されていた先行技術の会話型ディーリングシステムでは利用不可能であった。
【００４２】
好ましい実施例では、サーバ２６は、取引サーバ２８およびチャットサーバ３０を含む。これらは、図１のサーバファームの一部を形成する。取引サーバは、提案された取引の詳細を商取引および銀行業務規則に照らして検証し、提案された取引が潜在的なカウンターパーティに見えるようになる前に他のチェックが行われうるようにする。これは、取引メイカーの相当の信頼性すなわち、メイカーが提案しているトレードを締結する能力を含みうる。チャットサーバ６０は、ネットワーク上のクライアント間の会話交換を扱う。以下に述べるように、取引関連情報を含んでも含まなくてもよい会話メッセージは、チャットサーバを介してクライアント間を通される。クライアントは、どの時点でもいくつかの会話に参加でき、特定の他の異なったクライアントと同時に異なったいくつかの会話を行うことができ、同時に二人の当事者が２以上の取引を交渉することが可能である。
【００４３】
図３は、各トレーダー端末で表示されるユーザインターフェイスを示す。表示は、いくつかのパネルを含む。どの程度パネルが表示されるかは、各トレーダーの好みにしたがって構成可能であるが、いくつかのパネルは永久的である。すなわち、ディスプレイ１００は概念コンテナ（ｎｏｔｉｏｎａｌ ｃｏｎｔａｉｎｅｒ）１０２，１０４および１０６を含む。コンテナ１０２は、３つのコンテナのうちの上のものであり、ディスプレイの幅をわたって延在し、その上コンテナの下には、左下コンテナ１０４がおよび右下コンテナ１０６がある。コンテナの左には、構成可能アイコン表示１０８がある。
【００４４】
上コンテナは、トレーダーの表示エリアの全幅を必要とするパネルだけを表示する。表示され得る各パネルは、２つのうちの１つの優先順位を割当てられる。優先順位１のパネルは隠れない。優先順位２のパネルは、覆われるか、または高さ０を与えられる。いずれの場合においても、パネルデータモデルはパネルが見えないときにも維持されており、これらが再び見えるようになったときに、含まれたデータを表示することが可能である。
【００４５】
各々が優先順位１を有する３つの永久的パネルがある。これらを図３および図４に示す。上コンテナ１０２内には取引スタック１１０が表示され、左下コンテナ１０４にはトレーダーが参加しているいくつかの会話を含む会話エリア１１２が表示され、右下コンテナには入ってくる会話メッセージが表示される入来会話パネル１１４が表示される。入来メッセージは、トレーダーがまだ参加していないか、または全く参加しないかもしれない会話を含む。
【００４６】
トレーダーが表示することを選択し得る任意のパネルは以下を含む：
優先順位１を割当てられ、かつトレーダーによってダンされて下の２つのコンテナのいずれかに表示され得るすべての取引を示す、トレーダー取引パネル（図示せず）；
優先順位１を割当てられ、下の２つのコンテナのいずれかに配置される、概要パネル（図示せず）；
優先順位２を割当てられ、システムによってログされた取引を示し、上コンテナ１０２に表示される、取引ログパネル（図示せず）；
さまざまな通貨ペアに対するシステム上の現在の取引レートを表示し、優先順位２を割当てられる、レートエリア１１６；および
下のコンテナのうちの１つに配置され、優先順位２を有する、会話アーカイブ（図示せず）。
【００４７】
図４に示されるように、いくつかのパネルはそれらの下端にボタンバーを含む。ボタンのさまざまな機能は、以下に説明する。会話パネルボタンバーは、フロート（ｆｌｏａｔ）ボタンを含む。このボタンをクリックすると、パネルの位置をスクリーン中で、全システムが表示されているウインドウ外にさえも、変化させることができる。これは、たとえばクライアントがいくつかの任意のパネルの表示を所望するか、または多数の会話が行なわれている場合に有用である。説明される実施例においては、一時点において最大１０までの会話が進行し得るが、これは変化し得る任意の数字であることを認識されたい。
【００４８】
入来会話パネルは、入ってくる会話型メッセージのみをリストする。図３の例においては、単一の会話のみが表示されている。この時点で、クライアントは会話の当事者ではない。会話は４つの見出しの下に表示されている：独自会話識別番号であるＩＤ；カウンターパーティによって会話が開始された時間であるＴｉｍｅ；会話を開始したカウンターパーティの識別であるＦｒｏｍ；および会話内の最新メッセージラインであるＭｅｓｓａｇｅである。図３の例においては、メッセージ「会話はｐｅｔｅｒ＠ＣＩＴＱによって開始されました」が、識別子ＣＩＴＱを有する機関のピーターとして識別されるトレーダーによって送られている。会話は１３．３４．５４に開始し、ＩＤ番号１７９１を有する。新しい会話は各々、ＩＤ番号で特定される。さらに、Ｓｐｏｔ ＦＸ， ＦＸ ｏｕｔｒｉｇｈｔｓ， Ｆｏｒｗａｒｄｓなどを含む取引タイプ、取引アマウント、取引方向（メイカー、テイカー）および他の必要な情報を含む取引関連情報の１組であるＤｅａｌＩｎｆｏファイルと関連付けられる。ＤｅａｌＩｎｆｏ構造はさらに、取引の現在ステータスを含む。会話がパーズされる態様に中心的なのは、取引がどの程度進行しているかを示すいくつかの状態のうちのひとつに取引が該当するという着想である。本質的に、これらの状態は、取引関連情報がない会話に関連するＮｏＳｔａｔｅで開始し、パーサによってクオートリクエストが識別された状態であるＲＦＱ、ＲＦＱに応答してパーサによりクオートが特定されたＱｕｏｔｅ、およびクオートされた価格での買いまたは売りに一当事者が同意することで取引が完了したＢｕｙ／Ｓｅｌｌである。
【００４９】
入来会話パネルの下にあるのは、「ピックアップ（Ｐｉｃｋ Ｕｐ）」「クリア（Ｃｌｅａｒ）」「転送（Ｔｒａｎｓｆｅｒ）」および「チャット（Ｃｈａｔ）」と記されるボタンを備えたボタンバーである。アクションのために会話を選択するために、クライアントが会話ラインをクリックすると、その会話ラインはパネル内の他のいずれの会話とも異なった色で表示される（ここでは、これは唯一の会話である）。もしクライアントが「ピックアップ」ボタンをクリックすれば、選択された会話に対して会話パネルが左下コンテナ１０４で開く（図４）。この時点で、システムは、会話型メッセージが送られた他のすべての当事者に、メッセージ「ユーザ名が会話に加わりました」というメッセージを表示させる。当事者が会話に加わったとき、当事者は参加した時点からの会話のみを見る。最初の人物が取引コードに対するチャットへの招待をピックアップすると、この招待はこれが送られた他のすべての当事者から取り下げられる。
【００５０】
トレーダーが会話をピックアップすると、会話は彼の入来会話パネルから除去される。
【００５１】
「クリア」ボタンをクリックすると、選択された会話をディスプレイからクリアする。会話がクリアされると、会話の開始者は彼ら自身の会話パネルに「会話はユーザ名によって辞退されました」を受取る。
【００５２】
「転送」ボタンは、会話が相互的である場合にのみイネーブルされる。クリックすると、会話はトレーダーまたは、転送会話ダイアログ内に特定される取引コードに転送される。所与のトレーダーが、相手があるならば誰に会話を転送するのかを規定するルールが確立され得る。
【００５３】
「チャット」ボタンは、会話セッションの起動を呼出し、かつ会話エリアに会話パネルを開く。ユーザが同じ人物に対して第２またはその後の会話を開始しようと試みた場合、好ましくは警告ボックスが表示されてクライアントに通知するが、同じ人物に対して多数の会話を開始し得る。
【００５４】
ボタンバーのすべての機能を表示するか、またはこれに代えて、キーボードによる操作のみを可能にするようにドロップダウンメニューとして表示されてもよい。
【００５５】
図５から図７をさらに参照して、取引スタックは、トレーダが関与しており、かつ継続中であるかまたは完了している取引のリストを示す。
【００５６】
取引スタック１３０は、以下の主な構成要素を含む：取引リスト１３２、取引詳細パネル１３４、およびボタンバー１３６である。取引リストは、４つの見出しの下に取引についての情報を示す：取引ステータス１２０、時間１２２、カウンターパーティ（トレーダー／銀行）１２４、取引されている証券１２６および行なわれている取引１２６である。取引リスト１３２に示される情報は、取引されている証券に依存しない。これは、取引詳細パネルの使用によって達成されるが、取引スタックは、最小限の情報がトレーダーが簡単に理解できる態様で、非常に単純な態様でクライアントに示されるので、たいへん有利である。
【００５７】
取引フィールド１２６のテキストを理解するために、第一にどのように取引関連情報がシステムに入力され、どのようにシステムがその情報が取引に関連していることを理解するのかを認識しなければならない。取引情報は２つの方法のうちの１つでシステムに提出され得る：直接取引き入力または会話のパーズである。会話のパーズは、後に詳述する。この時点では、パーズがシステムが会話型メッセージを解析して、それらが取引関連内容を含むかどうか判断することに関わることを認識すれば十分である。もしそれらが含んでいれば、取引は取引リストに表示される。
【００５８】
取引は、トレーダーによるシステムへの「リクエスト・フォー・クォート」（ＲＦＱ）入力によって開始する。ＲＦＱは、トレーダによる、取引に関心を持っていることの表明である。図３の取引リストの第１のラインはＲＦＱを示す。ここで、トレーダーは２５０万ドルをアメリカドル／カナダドルマーケットで取引するリクエストをマーケットに提示する。この段階で、ビッドまたはオファープライスは与えられておらず、トレーダーが買いまたは売りを所望するかの示唆もない。ＲＦＱはシステムに会話型メッセージとして入力されていても、またはトレーダーによって直接入力として入力されていてもよく、この場合トレーダーは取引ボタンバーのＲＦＱボタンを押す。これにより、証券、通貨ペア、および金額を要求するパネルが表示される。
【００５９】
こうして、取引は直接のクォートリクエストのシステムへの入力、または会話のパーズによるクォートリクエストの検出のいずれかにより、取引が開始し得る。便宜上、後者を間接的なクォートリクエストと称してもよい。
【００６０】
ＲＦＱが受取られるかまたは検出されると、システムは取引リストに表示されるべきテキストを決定する。これは、直接ＲＦＱの文字変換、またはパーズされた間接的ＲＦＱのいずれかである。
【００６１】
証券ごとに、いくつかの取引ステータスが定義される。これらの各々が、ステータスフィールドに表示される関連のステータスストリング、取引フィールドに表示されるテキストである取引ストリング、および理解される説明を有する。
【００６２】
Ｆ／Ｘスポットに対する取引ステータスのいくつかの例は以下の通りである。
【００６３】
【表１】

【００６４】
【表２】

【００６５】
上のもののいくつかと関連する取引ストリングおよびステータスストリングは以下の通りである：取引ストリングは、トレーダーによって入力された実際の会話に対するシステムによって置換された会話型テキスト、またはトレーダーが取引スタック上のボタンバーまたは等価物のキーボードメニューのいずれかを用いて取引情報を入力した場合に置換されたものであることを認識されたい。
【００６６】
【表３】

【００６７】
以下は、証券（ｉｎｓｔｒｕｍｅｎｔ）がフォワード取引である取引ステータスの一例である。
【００６８】
【表４】

【００６９】
【表５】

【００７０】
取引スタック中のすべての取引について、対応する会話セッションが存在する。いくつかの場合には、ＲＦＱは会話から始まっていた。別の場合は、そうではなかった。後者の場合、直接クォートすなわち会話が生じるが、トレーダーが特に要求すれば、会話パネルが開かれるのみ、すなわち、会話が公開される。
【００７１】
したがって、トレーダーのアクションに応答してシステムが取引に対してアクションを起こす際はいつでも、このアクションの性質を示す会話セッションにメッセージラインが含まれる。このメッセージラインは、トレーダーが下にある（ｕｎｄｅｒｌｙｉｎｇ）会話を公開し、メッセージテキストをタイプしたならば、それがパーズを行ない、取引に対して同じアクションを起こす形態のものである。メッセージは、パーズの観点から、最良の会話的実践を反映する形態にある。
【００７２】
取引リストは、トレーダーが関わっているすべてのライブＲＦＱをディスプレイする。トレーダーは、適切なオプションが設定されていれば、他のＲＦＱを見得る。トレーダーは好ましくは、取引が完了すれば、完了した取引を自動的にクリアするオプションを有する。トレーダーは好ましくは、自分のアカウントから自動転送されたすべてのＲＦＱを見るオプションを有する。自動転送されたＲＦＱは、クリア機能によって取引リストからクリアされる。
【００７３】
上述のように、取引リストは取引される証券から完全に独立している。したがって、取引リストは５つのコラム、すなわち、ステータス、時間、トレーダー／銀行、証券および取引をディスプレイするのみである。取引コラムは、システムが生成して取引を記述する、証券／ステータス特有ストリングを含む。
【００７４】
取引リスト１３２の独立性のバランスを取るため、取引リストの下部の取引詳細パネル１３４は証券特有フォーマットを有しかつ、リスト中で現在選択されている取引の全詳細を反映する。
【００７５】
取引リストに新たな取引が加わると、それは、現在選択されているソート順に関わらず、リストのいちばん下に挿入される（その取引をソート順に正しく位置付けるには再ソートが必要である）。取引リストに取引が加えられると、トレーダーのアクション（ＲＦＱまたはチャット）の結果、最後にテーブルに加えられた項目が選択された項目になる。リストは、選択された項目がトレーダーに見えるようにスクロールされる。
【００７６】
カウンタパーティが新たな取引を始める場合、選択された取引は変わらない。対象が取引リストの中にあるならば、現在選択されている項目は、リストに新たな取引が加わっても変わらない。新たな取引が取引スタックに加わって、その取引を見るには取引スタックをスクロールしなければならない場合、スクロールバーのバックグラウンドは、スクロールによって取引が見えるようになるまで、たとえば赤に点滅する。
【００７７】
取引詳細パネルは、標準取引スタックボタンを介しては利用できない証券特有機能に関するボタンおよび他のコントロールを含んでもよい。取引が変更可能な状態にあるとき、その変更は、取引詳細パネル中の編集コントロールによって行なわれる。これらの潜在的に変更可能なフィールドは、取引詳細パネルのその他の部分とは異なる色、たとえばシアンのバックグラウンドを有する。取引詳細パネル自体が、取引リストとは異なる色、たとえば黄色であってもよい。フィールドが編集可能であるとき、それらは、たとえば黒の境界線を有する白のバックグラウンドによって区別されるうる。
【００７８】
取引詳細パネルのフォーマットは取引の証券に特有である。パネルのすべての実現例は、常に同じ場所にある共通のあるフィールドおよびコントロール、すなわち、ステータス、時間、トレーダー／銀行、証券およびエラー／警告組合せボックスを有する。図５、６、８および９は、Ｆ／Ｘスポットおよび取引のさまざまな段階用の取引詳細パネルを図示し、図７は、取引過程のある段階のＦ／Ｘフォワード用の取引詳細パネルを図示する。
【００７９】
したがって、取引詳細パネル１３４は、取引リスト１３２の代わりに、入力され次にパーズされるとその取引リスト１３２を結果的に生じるような情報を含むことを除いて、取引リスト１３２中のすべての情報を含む。したがって、Ｆ／Ｘスポット（図５）については、取引詳細パネルは、アマウント、通貨ペア、バリューデート、ビッドおよびオファープライスならびに取引済み（Ｄｅａｌｔ）を含む。図５で、スタック中の最初の取引について取引詳細パネルが示される。これは、ちょうど始まったばかりで、ＲＦＱが出された取引である。ビッドまたはオファープライスはまだまったくないため、埋まっているフィールドは、アマウント、通貨ペアおよびバリューデートのみである。取引リスト１３２の上に示すように、パーズすると、これは、“２．５ｍｉｌのＵＳＤ．ｃａｄを要求”となる。
【００８０】
図６で、ハイライトされた取引は、リスト中の３番目のものである。取引のステータスはｐｒｅ ｑｕｏｔｅ Ｂ ｍａｋｅｒであり、これは、メイカーがテイカーのクォートをピックアップし、日本円３２億円に対するビッドおよびオファープライスをクォートしていることを示す。アマウントとプライスの両者とも編集可能であるので、取引詳細パネル中、それらは白のバックグラウンド上の黒い文字として表れる。
【００８１】
図７は、フォワード取引用の取引詳細パネルを示す。ここで、パネルは、ニア（ｎｅａｒ）およびファー（ｆａｒ）アマウントの両者、通貨、ニアおよびファー取引の両者の性質、それらのバリューデート、左右側、スポット（図５）アマウント、オールインアマウントならびに取引アマウントをリストで示している。示された例では、パネルは、完了した取引である、リスト中の４番目の取引に関する。したがって、取引詳細パネル中のすべてのフィールドは埋まりかつダンであり（ｄｏｎｅ）、変更可能である。許容できないエントリまたは誤りをトレーダーに通知可能にするため、詳細パネルの左下側にエラー／警告組合せボックスがある。この組合せボックスは好ましくは、取引に関連するあらゆるエラーまたは警告状態のために、そのドロップダウンリスト中にエントリを有する。組合せボックス中でエラーまたは警告が選択されると、エラーまたは警告が属するフィールドが、非常に明らかな態様で、たとえば、赤（エラー）またはオレンジのバックグラウンド（警告）でハイライトされる。エラーおよび警告はそれらの優先順位順にリストにされる。この組合せボックスはその右側に関連の標識を有し、それは、組合せボックスが含むエラーまたは警告の数を示す。リスト中のアラームまたは警告状態が変化するとき、最も優先順位の高い項目が選択された項目である。
【００８２】
図８は、エラーボックスの例を示す。ここで、ハイライトされた取引は、取引リスト中の３番目のものである。これは、アマウントとビッドおよびオファープライスとの両者を必要とする。トレーダーはビッドおよびオファープライスを入力しておらず、エラーボックスは、ビッドまたはオファープライスが必要であることを示している。さらに、Ｑｕｏｔｅ？ステータスストリングと、通常は白で示されるビッドおよびオファーフィールドとが赤でハイライトされる。
【００８３】
組合せボックス中のエラーの存在は、そのエラー状態が訂正されるまで、取引を進めるキーおよびメニュー項目を不能にする。
【００８４】
図９は、受け入れを待っている取引の取引詳細パネルを示す。ここで、メイカーはクォートを提出し、取引は現在テイカーからの受入れまたは拒否を待っている。アマウントとビッドおよびオファーの詳細とがハイライトされ、それらを変更可能であることを示している。
【００８５】
ステータス、時間、トレーダー／銀行および証券のコラムエントリは、取引リスト中のそれらのそれぞれのコラムのすぐ下に、取引詳細パネル上に位置決めされる。列を再サイズ決めすればそれらの相対的な位置も変わる。エラー／警告組合せボックスおよびその関連のカウント標識の幅は好ましくは、ステータス、時間、トレーダー／銀行および証券コラムの組合せの幅に自動的に設定される。取引コラム下の証券特有フィールドは、取引コラムの幅に比例してそれら自身を再サイズ決めし、位置決めする。
【００８６】
２つの例示的な証券について、証券特有のフィールドがより詳細に説明される。この発明はいかなる証券にも適用可能であり、フィールドは証券によって異なることを理解されたい。
【００８７】
アマウントフィールドは当初読出専用であり、ＲＦＱのアマウントを１００万単位でディスプレイする。取引がｐｒｅ ｑｕｏｔｅ−ｍａｋｅｒ段階（図６）に達すると、フィールドが編集可能になる。
【００８８】
“オン”（ｏｎ）通貨フィールドはアマウントフィールドの右にあり、ＲＦＱが表わされる通貨である。それが基準通貨でなければそれがディスプレイされ、そうでなければディスプレイされない。それはｐｒｅ ｑｕｏｔｅ Ｂ ｍａｋｅｒ段階までは編集不可能であり、ｐｒｅ ｑｕｏｔｅ−ｍａｋｅｒ段階の時点で編集可能になる。
【００８９】
通貨ペアフィールドは、取引される通貨ペアを単に示す。
バリューデートは取引のバリューデートを示し、当事者が変更することはできない。たとえばアスタリスクなどで他に示されなければ、それは証券の通常の日（ｒｅｇｕｌａｒ ｄａｔｅ）である。
【００９０】
ビッドおよびクォートフィールドは、これらが存在するビッドおよびクォートをディスプレイする。それらは、図６に関連して説明されるように、それらを編集可能な取引のｐｒｅ ｑｕｏｔｅ Ｂ ｍａｋｅｒおよびＰｒｅ ｒｅ−ｑｕｏｔｅ ｍａｋｅｒ段階を除いて、読出専用である。ビッグフィギュア（ｂｉｇ ｆｉｇｕｒｅ）、すなわち、プライスの最も有効な桁がマーケット供給からトレーディングシステムへ利用可能ならば、そのフィギュアが用いられる。裁定取引状態が存在すれば、マーケット供給レート、システムのベストオファーからのビッグフィギュアが用いられる。これはシステムレートパネルで見ることができ、パネルはクライアントがディスプレイすることを選び得るものである。
【００９１】
最後のフィールドは、取引が完了したプライスを示す取引済みプライスフィールドである。図１０からわかるように、これは、取引が完了した側（買いまたは売り）を反映する。図１０では、取引されたプライスはビッドプライスである。
【００９２】
取引詳細パネルに示されるフォワード特有フィールドは以下のとおりである。 ニアおよびファーアマウント これらは、スポット例のアマウントフィールドと同じ態様で機能する。
【００９３】
オン通貨 これはスポット例のアマウントフィールドと同じ態様で機能する。
通貨ペア これはスポット例のアマウントフィールドと同じ態様で機能する。
【００９４】
ニアおよびファー期間 これらの期間がたとえば１ヶ月などの標準的な期間に適合すれば、それらはそのようなものとして示される。適合しなければ、半端（ｂｒｏｋｅｎ）として示される。
【００９５】
ニアおよびファーデート これはニアおよびファーバリューデートを示す。
左右側プライス ＬＨＳまたはＲＨＳが存在する場合、それはこのフィールドにディスプレイされる。取引ステータスがｐｒｅ ｑｕｏｔｅ Ｂ ｍａｋｅｒまたはｐｒｅ ｒｅｑｕｏｔｅ Ｂ ｍａｋｅｒステータスであるときを除き、これは読出専用フィールドである。編集モードでは、このフィールドには、ビッドに利用可能ならばマーケットレートが入れられる。トレーダーがＬＨＳまたはＲＨＳをブランクのままにした場合、それぞれビッドまたはオファーがない片側プライスがクォートされる。
【００９６】
プレミアムおよびディスカウント ＬＨＳがＲＨＳよりも小さければ、システムは、基準通貨が現地通貨に対してプレミアムであると仮定する。トレーダーがマイナスを入力せずかつＲＨＳがＬＨＳよりも小さければ、システムは、基準通貨が現地通貨に対してディスカウントされていると仮定する。ディスカウントが検出されると、システムは各値の前にＡ−Ａ符号を挿入し、符号をつけてビッドおよびオファーをディスプレイする。トレーダーは、ディスカウントについて負のアマウントを入力することができる。
【００９７】
スポットレート スポットレートが存在するとき、スポットレートビッドフィールドがそれをディスプレイする。取引がＩ Ｂ／Ｓ−ＲａｔｅまたはＩ Ｓ／Ｂ−Ｒａｔｅ（所与のレートでのＩ ｓｅｌｌ／ｂｕｙまたはｂｕｙ／ｓｅｌｌ）であるときを除き、これは読出専用フィールドである。編集モードでは、フィールドには、ビッドおよびオファーマーケットレートの間の中間レートが入れられる。
【００９８】
スポットボタン 図１１からわかるように、取引詳細パネルは、クライアントがクリックしてスポットレートクエリダイアログウィンドウをディスプレイすることができるスポットボタンを含む。スポットボタンは、取引がＩ Ｂ／Ｓ Ｂ ＣｏｎｆｉｒｍまたはＩＳ／Ｂ−Ｃｏｎｆｉｒｍ段階にあるときのみトレーダーに見える。スポットレートクエリダイアログウィンドウは編集ボックスを含み、これは、テキスト“Ｃｈｅｃｋ Ｒａｔｅ”で予め埋められた、３０字までのテキストをトレーダーが入力できるようにしている。これにより、トレーダーは、取引にコミットする前にスポットレートをチェックすることができる。図１１からわかるように、ダイアログボックスは送信およびキャンセルボタンを含む。送信ボタンはボックスを閉じ、メッセージを送り、取引ステータスをＩ Ｓ／Ｂ ａｗａｉｔｉｎｇ ｒａｔｅまたはＩ Ｂ／Ｓ ａｗａｉｔｉｎｇ ｒａｔｅに変更する。
【００９９】
メイカー取引がそれに対するスポットレートクエリメッセージを受取ると、エラー／警告組合せボックスに警告としてメッセージが現れる。これは図１２に図示される。
【０１００】
オールインレート このフィールドは読出専用であり、メイカーがスポットレートを提出すると、取引済みレートおよびスポットレートの総計（ａｇｇｒｅｇａｔｅ）を反映する。一晩または翌日以降の期間については、フォワードビッドまたはオファーの符号を反転してオールインレートを計算する。
【０１０１】
取引済みレート これは取引詳細パネル中の最後のフィールドであり、読出専用フィールドである。テイカーが買い／売りまたは売り／買いを有するとき、フィールドは取引が行なわれるマーケットの側からのプライスを反映する。
【０１０２】
アウトライト 証券がアウトライトであるときの取引詳細パネル用のフィールドは図示されない。というのも、それらは上述のスポット取引と同じであるからである。
【０１０３】
取引コラムは、各証券ごとに異なるステータス依存ストリングをディスプレイする。スポット用のこれらのうちいくつかが前述された。ストリングはシステムにハードコードされるのではなく、システム管理者が中央で設定可能である。トレーダーは好ましくはストリングに対するコントロールは有しない。前に見たように、ステータス定義は、取引の潜在的値を表わす、チルダ（〜）で区切られたトークンを含む。
【０１０４】
スポットおよびアウトライト用のトークンは以下のとおりである。
【０１０５】
【表６】

【０１０６】
フォワード取引用のトークンは以下のとおりである。
【０１０７】
【表７】

【０１０８】
取引スタック１３０の第３の部分はボタンバー１３６であり、これは取引リスト１３２および取引詳細パネル１３４の下にある。ボタンバーは、取引を進めるまたはキャンセルするため、トレーダーにさまざまなオプションを与える。ボタンバーは各取引に特有である。すなわち、ディスプレイされたボタンバーは、取引スタック中の選択される取引に依存する。説明されるように、取引のある段階では、いくつかのオプションはトレーダーが利用不可能である。
【０１０９】
図５から図８に戻って、ボタンバーは、取引リスト中でハイライトされる取引のステータスに依存して、図面によって異なることがわかる。ある場合は、ボタンは太字でディスプレイされておらず、利用不可能であることを示している。後者の例として、図５のピックアップボタンは、図６のクォートボタンで置き換えられている。図５のキャンセルボタンは図６のナッシングボタンで置き換えられている。
【０１１０】
ボタンバーは、会話パネルを用いたカウンタパーティとの会話交換に対して、代替的なしかし等しく有効な取引方法をトレーダーに与える。システムは、会話テキストをパーズして取引リスト取引フィールド用のパーズされたテキストを生じるのと同じ態様で、ボタンを介して入力される取引命令を、パーズされたテキストに変換することによって動作する。
【０１１１】
トレーダーが利用可能なボタンは以下のとおりである。
たとえば図５のピックアップ これは、テイカーがシステムに入力したＲＦＱをトレーダーが“ピックアップ”するのを可能にする。その結果、ピックアップボタンは、メイカーにのみおよび、取引がＰｒｅ Ｐｉｃｋｕｐ Ｂ Ｍａｋｅｒステータスにあるときにのみ利用可能である。ピックアップを押すことにより、メイカーはＲＦＱのクォートに興味があることを示す。ＲＦＱは、テイカーによって一人または多数のトレーダーに送られてもよい。それが取引コード（すなわち立会い場または複数の場）に送られれば、ピックアップを受けると、ＲＦＱはすべての他の受取者の取引リストから除かれる。
【０１１２】
クォート（たとえば図６） これはトレーダーがクォートを入力できるようにするものであるので、取引がｐｒｅ ｑｕｏｔｅ Ｂ ｍａｋｅｒステータスにあるときにメイカー側でのみ可能化される。クォートのアクションは証券とは異なる。スポットまたはアウトライト取引については、システムは、アマウントとともにメイカーのビッドおよび／またはオファーをテイカーに送る。フォワード取引については、システムは、ニアおよびファーアマウントとともに、メイカーのＬＨＳ点および／またはＲＨＳ点をテイカーに送る。
【０１１３】
ボタンバー中の第１のボタンはすべてのデフォルトアクションを組合せる。スポット例については、ボタンはピックアップに戻るが、上述されたもの以外の取引ステータスについては灰色で表示される。フォワードについては、より多くのオプションが利用可能である。取引がＳ／ＢもしくはＢ／Ｓ Ｐｒｅ Ｒａｔｅ−ＭａｋｅｒまたはＳ／ＢもしくはＢ／Ｓ Ｐｒｅ Ｒａｔｅ２−Ｔａｋｅｒステータスにあると、ボタンは、メイカーがメイカーのスポットレートをシステムに送れるようにするレートボタン（図示せず）としてディスプレイされる。フォワード取引がＳ／ＢもしくはＢ／Ｓ Ｐｒｅ Ｃｏｎｆｉｒｍ−ＴａｋｅｒまたはＳ／ＢもしくはＢ／Ｓ Ｐｒｅｃｏｎｆｉｒｍ２−Ｔａｋｅｒステータスにあれば、ボタンは、テイカーがメイカーの提示したスポットレートを受入れられるようにするスポットボタンとしてディスプレイされる。
【０１１４】
Ｃｈａｔ（チャット） このボタンは、単一の取引が選択されるときにのみ利用可能であり、取引のために開かれる会話パネルを左下コンテナにディスプレイするようにする。取引が会話的でなく直接的な形態で行なわれても、システムは、その取引状態をもたらしたであろう会話の逆パーズ（ｄｅｐａｒｓｅｄ）バージョンを示す。会話によってまたはボタンバーを用いた直接エントリによって、取引がどのように行なわれているかに関わらず、各取引はシステムとの会話を有するので、これが可能である。トレーダーはいつでも会話に切換えて取引を継続することができる。システムはその会話をパーズし、直接および間接的取引エントリ方法を区別しない。この点で、システムは透明である。
【０１１５】
Ｈｏｌｄ（保留） このボタンは、選択された取引がＰｒｅ Ｑｕｏｔｅ−Ｍａｋｅｒステータスにあるときのみ可能化される。それは、選択された取引をＰｒｅ Ｐｉｃｋｕｐ−ＴａｋｅｒおよびＰｒｅ Ｐｉｃｋｕｐ−Ｍａｋｅｒステータスに戻し、もとのＲＦＱが取引コードに送られれば、すべてのそれらの当事者に再びＲＦＱをディスプレイする。
【０１１６】
Ｔｒａｎｓｆｅｒ（転送） このボタンは、選択された取引がＰｒｅ Ｑｕｏｔｅ Ｍａｋｅｒステータスにあるときのみ可能化される。それは、予め設定された権限の限界内でトレーダーが取引を別のトレーダーに転送できるようにする。ボタンを押すことによってダイアログボックスがディスプレイされ、そこに、取引を転送すべきトレーダーのコードをトレーダーが入力することができる。この趣旨のメッセージは発信者の取引スタックにディスプレイされるので、その人は今は異なるカウンタパーティとディーリングを行なっていることがわかる。
【０１１７】
Ｓｅｌｌ（売り） このボタンは、スポットまたはアウトライトなどの証券のためにのみ可能化される。これは、テイカーがメイカーのビッドプライスで売るための手段を提供し、メイカーからのビッドが存在するＰｒｅ ＢｕｙＳｅｌｌステータスでのみ可能化される。
【０１１８】
ＲＦＱ このボタンは、メイカーがマーケットへのクォート要求を出すのを可能にする。このボタンが押されると、メイカーはアマウントおよび通貨ペアを与えなければならない。システムによってＲＦＱを受けると、新たな会話が取引と関連付けられる。
【０１１９】
ＲＦＱボタンは、テイカー側の会話パーズによってＲＦＱが開始されかつ、テイカーによる正確さの確認を待っているときにキャプションＦＩＸに変換する。
【０１２０】
Ｃａｌｌｏｕｔ（コールアウト） このボタンはトレーダーがコールアウトを開始するのを可能にする。
【０１２１】
Ｂｕｙ（買い） このボタンは、スポットまたはアウトライトなどの証券の選択された取引が、メイカーからのオファーが存在するＰｒｅ Ｂｕｙ／Ｓｅｌｌ−Ｔａｋｅｒステータスにあるときにのみ可能化される。このボタンを押すことにより、テイカーは、メイカーのオファープライスで買いたいことをシステムに示す。
【０１２２】
Ｃａｎｃｅｌ（キャンセル） これは多機能ボタンであり、そのキャプションは、選択された取引で取引される証券および取引ステータスに依存する。これは、すべての否定的機能に用いられる。機能は証券によって異なるが、スポット用の機能は以下のとおりである。
【０１２３】
【表８】

【０１２４】
フォワード用の否定的アクションは以下のとおりである。
【０１２５】
【表９】

【０１２６】
上記のさまざまなアクションのうち、キャンセルアクションは既存の取引段階をキャンセルし、それをその前の取引段階に戻す。ナッシングアクションは、テイカーが提示された取引に興味がないことを示す。割込みアクションは、取引スタックから取引を除去し、取引がターミナルステータスに達するとき、すなわち、完了した取引であるときにのみ可能化される。
【０１２７】
Ｃｌｅａｒ Ａｌｌ（すべてクリア） このボタンは取引スタックからすべての適格な取引をクリアする。
【０１２８】
Ｏｆｆ Ａｌｌ（すべてオフ） このボタンは当該形態のすべての取引をマーケットから引揚げる。
【０１２９】
以上のセクションは、ボタンバーからトレーダーが利用可能なトレーディングアクションを説明した。トレーダーは、マウスなどのポインティングデバイスを用いずにすべての利用可能な機能を行なえることが望ましい。したがって、システムは、ボタンバーと同じ機能性を与えながら、キーボードからすべて起動可能なセットアップポップアップメニューを提供する。各機能は、各メニューにおいて同じキーボード文字によって起動可能である。機能に割当て可能な文字の例は以下のとおりである。
【０１３０】
【表１０】

【０１３１】
取引ステータスのための可能なメニューの例は以下のとおりである。
【０１３２】
【表１１】

【０１３３】
パーズ
上記説明は、ディーリングシステムとのトレーダーインターフェイスに関していた。取引は、取引スタックボタンバーもしくは同等のキーボードストロークを介して直接にシステムに入力可能であるかまたは、会話的に入力可能、すなわち、システムが会話をパーズして取引関連情報を抽出可能であることが述べられた。次のセクションはパーズメカニズムを考察する。
【０１３４】
トレーディングシステム内のパーズ自体は公知である。パーズは導入部で参照されたロイター社のディーリング２０００／１システムで用いられている。しかし、そのシステムでは、すべての取引トランザクションは会話を介している。トレーダーは、上述のような直接取引エントリを用いるオプションは有していない。その結果、システムが取引情報を逆パーズ可能であるという要件は存在しない。このため、およびさまざまな他の理由から、このシステムのパーズ要件は先行技術の要件とは著しく異なっている。以下の説明は外国為替マーケットを考察し、特に、上述の３つの証券、すなわちＦＸスポット、ＦＸアウトライトおよびＦＸ先物を考察する。第１に、パーサが動作する態様の説明を、どのように会話型取引が行なわれるか、図１３、図１４ａ、図１４ｂのフローチャートおよび図１５〜図２２のユーザインタフェースのさまざまなショットを参照しながら論じることにより、説明する。まず、図１５〜図２２は先に記載されたものとは異なるユーザインタフェースの異なる実施例を示すことに注意されたい。
【０１３５】
チャットの交換におけるすべてのステージにおいて、パーサは会話を監視してＲＦＱ（クォートに対する要求）を探す。ＲＦＱの存在はパーサに対し新たな取引が開始されつつあることを警告する。したがって２人のトレーダが取引に関係のない挨拶を交わしている場合にはパーサはその会話をＲＦＱを求めて監視する。ユーザのパーサはユーザの会話をパーズすることを担うが、他の当事者から会話に対し受取られる会話のパーズには全く関与しない。
【０１３６】
以下の例では、新たな会話が、クライアント１と称され図１５ではｋｄｕｎａｙ＠ＥＢＳＮとして示されるクライアントによって開始されている。このユーザはメッセージを自分のチャットパネルにタイピングしてリターンキーを叩いている。これにより、ユーザインタフェース（図２）はチャットのラインをパーサに対しコンテンツにかかわりなく送る。パーサは会話をパーズしてステータスの変更および他の取引関連情報を探し求める。この例では、パーサはＲＦＱをチャットのラインにおいて検出している。そのラインは、図示されてはいないが、「私は１円が欲しい。」であったとしてもよい。パーサはこれをＲＦＱとして検出し、次いで、ここではＦＸスポット（ＦＸ Ｓｐｏｔ）として識別されるトレードされる証券、ここではＵＳドル／日本円として認識される通貨ペア、およびここでは１００万として識別されるアマウントを含む他の取引関連情報を探し求める。パーサは、パーズされた会話を、ユーザインタフェースに対し、先に言及された、Ｄｅａｌ Ｓｔａｔｕｓ（取引ステータス）および取引関連情報を含むＤｅａｌＩｎｆｏ構造の形式で戻す。
【０１３７】
図１５には、ＤｅａｌＩｎｆｏ構造がユーザインタフェースに戻された状況を示す。ＲＦＱはまだシステムには入力されておらず、パーズされたライン２００として取引スタック２０２に表示される。パーズされたラインはユーザつまりｋｄｕｎａｙ＠ＥＢＳＮによりＲｅｄ Ｃａｎｃｅｌｌボタン２０４を押すことによってキャンセルされてもよく、または、トレーダが過ちを犯したか、気が変わったか、またはマーケット状況における変化に反応している場合にはたとえばアマウントまたは通貨を変更するべく編集されてもよい。編集は「Ｆｉｘ（固定）」ボタン２０８を押すことにより実行される。代替的に、ユーザは会話を再入力してそれが再びパーズされるようにしてもよい。ユーザに対し、アクションが必要である旨を示すためには、取引スタックにおけるラインのステータスは好ましくは代表的な色たとえば緑で示される。ＲＦＱが送られるべくユーザが押さなければならないボタンバー上のボタン２０６も緑で示される。パーズされた会話は取引スタックにおいて代表的な色たとえば赤で示されることによりそれがシステムによって生成されたテキストであることを示す。この点で、システムメッセージ「Ｓｕｂｍｉｔ（提出）？」も、赤で、会話パネルに表示される。
【０１３８】
図１５の取引スタックが先の例におけるそれと相違する点は、それがストリップ２１０をボタンバーの上に含んでユーザに対し強調された取引に関する重要な情報を示すという点であることがわかる。かくして、ストリップには、取引ステータス２０１、トレーダ２０３、証券（スポット）２０５、通貨ペア２０７、基準通貨が示された状態でのアマウント、ならびに買いおよび売りレートが含まれる。これらの後者のレートはボックス２１２、２１４において表示されるが、それらは図１５においてはレートがまだこの取引においては全くクォートされていないため空欄である。
【０１３９】
この例では、パーズされた会話のラインの結果、検出された取引ステータスがもたられさる。テキストのラインはたとえば「Ｈｉ， ｈｏｗ ａｒｅ ｙｏｕ（やあ、どうだい）」といったことを言ったにすぎないかもしれない。パーサは、何の取引関連情報も検出しなかったであろうが、それでも、なんらかの応答をユーザインタフェースに送って、会話のラインがパーズされたが何の取引情報も見出されなかった旨を示すであろう。
【０１４０】
ユーザが、パーズされたラインが取引スタックに現われ、それに満足すると、ユーザは「Ｐｒｏｃｅｅｄ（続行）」ボタン２０６を押す。これにより、パーズされた会話はクライアントの通信モジュール２２（図２）に、次いで取引サーバ２８に送られる。
【０１４１】
この時点で、強調されるべきパーズの多数の特徴がある。第１に、パーサは会話をラインごとにパーズし、パーズはユーザがタイピングを終えｓｅｎｄ（送る）ボタン２１６を押すまでは生じない。これは先に言及されたＲｅｕｔｅｒｓ ２００１／１システムにおいて用いられるシステムとは対照的であり、なぜならば、それは、会話のパーズを、ラインごとに、それらのタイピングがユーザによって行なわれている最中に行なうからである。ここに記載されるシステムが有利であるのは、ユーザが自分がタイピングしたものを変更してたとえばマーケットにおける変更に応答すること、または単に誤りを訂正することを、自分の手の内をカウンタパーティのトレーダに明かすことなく行ない得るという点である。カウンタパーティのトレーダにマーケットの概況に関する知識を与えることは非常に望ましくないことであり、なぜならばそれによって、自分がなすビッドまたはオファーが影響を受けるかもしれないからである。
【０１４２】
第２に、パーサは取引を行なうプロセスには関与せず、取引の知識を全く保持しない。パーサは単に会話のラインを見て取引ステータスに関係する情報を探すにすぎない。それはＤｅａｌＩｎｆｏ構造をユーザインタフェースに戻し、取引の知識を何ら保持しない。このことはパーサを非常に単純なものにする。
【０１４３】
第３に、パーズは、ステータスの動きを検出することに強調を伴う取引ステータス構造に基づく。取引ステータスは非常に単純なものであり：Ｎｏｎｅ（なし）、ＲＦＱ、Ｑｕｏｔｅ（クォート）、Ｂｕｙ／Ｓｅｌｌ（買い／売り）であるが、これらについては後により詳細に論ずることにする。各ステータスには、パーサが探し求める多数の取引関連用語がある。このことはパーズを非常に単純かつ正確なものにする。第１に探すべき用語が多くなく、第２にパーズ誤りから生ずる混乱の確率がより少ないからである。これが生じ得るのは、たとえば、会話のラインが当事者間の履歴取引に言及する場合である。取引のプロセスを、限られた数のパーズ可能な用語を各々が有する多数のステータスに分離することにより、パーサはそのようなパーズ誤りを避けることが比較的容易となる。ステータスおよび各ステータスごとの取引関連用語の詳細については後に詳細に論ずることにする。
【０１４４】
所与の例では、パーサによってパーズされた会話は、取引ステータスにおける変更およびその検出されたステータスに伴うよう必要とされるすべての情報（証券、通貨ペアなど）の両方を含んだ。各考えられ得る取引ステータスごとに、ある数の許された遷移があるにすぎず、各取引ステータスごとに、ある限られた数の、パーサによりステータスにおける変更が示されていると認識される表現がある。たとえば、新たな会話がクォートに対する要求を含む場合、パーサはクォートを示す情報を探す。それは全ラインをパーズし、所与のステータスに対して、予め定められた数の情報フィールドを満たすことを期待する。これらはステータスに依存して変動する。ある例として、パーサがステータスにおける変更をＲＦＱからＱｕｏｔｅに期待しているとき、それは、ビッドクォートおよび／またはオファークォート、またはクォートに対する拒否の表示があるか否かを見ることを期待する。ビッド／オファークォートがある場合、それはさらに通貨の表示を、ＦＸスポットトレードの場合においては、探す。必要とされる取引およびフィールドの状態はトレードされている証券に依存して変動する。
【０１４５】
一旦、ユーザから入力された会話がパーズされると、パーサはユーザインタフェースに以下の３つの可能性のうちの１つを戻す：
ａ）会話にはパーズ可能なものはない。これがあてはまるのは、会話が何ら取引関連情報を含まない場合である；
ｂ）見出される新たな取引ステータスおよびフィールドを含む取引構造における更新；
ｃ）曖昧さがありステータス変更を解決し得ないエラーメッセージ。この場合、エラーはチャットスタックに表示され、取引は変更されない。
【０１４６】
パーズされた会話メッセージに逆戻りして、クライアントの通信モジュール２２からメッセージは取引サーバ２８に送られ、その点で、それはチェックされ、それがシステム規定、銀行業務規制およびビジネス関連規則に従うことを保証する。それは、さらに、クレジットチェックが行なわれることを、たとえば取引詳細においてユーザの銀行の広域クレジットチェック機構にリンクすることにより可能にしてもよい。取引が続行し得ない場合、障害メッセージがユーザターミナルに表示されるが、カウンタパーティにはその事実は知らされない。カウンタパーティに関する限り、カウンタパーティが出したＲＦＱは単に返答されないだけである。失敗した取引を隠すというこの能力は有利なものであり、なぜならば、ユーザは、カウンタパーティに、自分は相手と取引することを試みたが失敗したということを知られたくないことが多いからである。さらに、ユーザはカウンタパーティがその試みられた取引の詳細を知ることを望まず、なぜならば、それは、彼の意図についての価値ある情報および彼のマーケットに対する読みを明かすことになるからである。この利点は、システムが会話のパーズを、実時間でそれらのタイピングが文字単位で行なわれる中ではなく、ライン単位で行なわれるという態様からきている。
【０１４７】
取引サーバ２８がＲＦＱを拒否しないと仮定して、パーズされたメッセージは宛先ユーザインタフェースに対し宛先クライアントの通信モジュールを介して送られる。注目すべきは、システムの構成は、取引サーバがすべての取引関連のパーズされたトラフィックを取扱い、会話サーバはパーズされない会話を搬送するすべての会話；つまり取引ステータスにおいて変更を含むとパーサが見出さなかった会話を取扱うようになされる、ということである。この二重サーバ構成は便利であるが本質的なものではなく、単一のサーバまたは何らかの他のサーバ構成によって置換えられることもある。
【０１４８】
図１６には、ＲＦＱがカウンタパーティに送られた後のユーザインタフェースが示される。取引スタックにおける取引のステータスは「ピックアップ待ち（Ｗａｉｔｉｎｇ ｐｉｃｋ−ｕｐ）」として示され、これは、ユーザインタフェースに対し、カウンタパーティが取引を自分のの入来会話（Ｉｎｃｏｍｉｎｇ Ｃｏｎｖｅｒｓａｔｉｏｎｓ）パネルからピックアップした旨が通知されていないことを意味する。取引に対する会話パネルにおいて、クライアントの会話は、今、代表的な色たとえば緑で示され、メッセージがそのクライアントから発信されたことを示す。
【０１４９】
ここで図１７を参照して、図１４に記載されるＲＦＱが送られたクライアントのユーザインタフェースを示す。クライアントはｔｅｓｔ＠ＥＢＳＮとして識別される。ＲＦＱメッセージは取引サーバによって送られクライアントｔｅｓｔ＠ＥＢＳＮに中継されている。送信側クライアントユーザインタフェースも、メッセージが送られた旨を通知される。入来メッセージはまずクライアントの入来メッセージパネルに現われる。図１５において、クライアントｔｅｓｔ＠ＥＢＳＮはそのメッセージをダブルクリックして新たな会話をアクティブな会話パネルに開く。この図において、これは、カウンタパーティ、識別されるｋｄｕｎａｙ＠ＥＢＳＮの名を伴う会話として識別される。システムは、会話パネルに、クライアントが会話に加わった （ｔｅｓｔ＠ＥＢＳＮ ｈａｓ ｊｏｉｎｅｄ ｔｈｅ ｃｏｎｖｅｒｓａｔｉｏｎ） ことを示し、パーズされたメッセージを取引スタックにおいて表示する。注目すべきは、そのメッセージが、メイカークライアントの取引スタックにおいて示されるパーズされたメッセージの装飾されたバージョンであるＱｕｏｔｅ １ ｍｉｌ ＪＰＹ ｕｓｄ／ＪＰＹ？として識別されることである。メッセージの元のバージョンが会話パネルに示される。メッセージは会話パネルにおいて代表的な色たとえば青で示されて、それが入来メッセージであることを示す。取引スタックにおいて、取引のステータスは「ｐｉｃｋｕｐ」として示され、緑で色づけされて、アクションがクライアントによって求められている旨を示す。この場合、クライアントはＲＦＱに対し応答しなければならない。
【０１５０】
第２のクライアントｔｅｓｔ＠ＥＢＳＮは次いでＲＦＱに対する自分の応答において会話のチャットライン２２０においてタイピングしｓｅｎｄ（送る）ボタン２２２を叩く。ＲＦＱラインと同じ態様で、これによりユーザインタフェースは完全なテキストのラインをパーサに送り、パーサは再びそのテキストをパーズしてＤｅａｌＩｎｆｏ構造をユーザインタフェースに送り返す。パーズされたテキストは、それがステータスの変更および必要な取引関連情報を含む場合には、取引サーバを介してカウンタパーティに送られる。注目すべきは、クライアントｋｄｕｎａｙ＠ＥＢＳＮに対するパーサはそのクライアントによって入力された会話をパーズするのみであり、クライアントｔｅｓｔ＠ＥＢＳＮのところのパーサはそのクライアントによって入力された会話をパーズするのみである、という点である。
【０１５１】
図１８には、あるクォートがユーザによって入力されパーサによってパーズされたがユーザによって確認はされていない場合のカウンタパーティクライアントｔｅｓｔ＠ＥＢＳＮが示される。取引スタックにおけるステータスはＱｕｏｔｅ？を示し、会話パネルはパーサによってパーズされたとおりのクォートに疑問符が続くものを示す。会話パネルのチャットラインはユーザに対し先に進むよう促す。図１８において、取引パネルのステータスは好ましくは警告（Ｗａｒｎｉｎｇ）を示す代表的な色、この場合はオレンジ色で示される。システムはメッセージを会話パネルにおいて「ビッグフィギュア利用不可（Ｂｉｇ Ｆｉｇｕｒｅ ｕｎａｖａｉｌａｂｌｅ）」を示す。この場合、メッセージは偽であり、レートパネルが不能化される中発生されるが、どのように警告が示され得るかを示すよう働く。
【０１５２】
図１９には、応答が受取られるときのクライアントｋｄｕｎａｙ＠ＥＢＳＮユーザインタフェースを示す。クライアントｔｅｓｔ＠ＥＢＳＮは、クォートを、ＲＦＱに応答して、１２３．３３／１２３．４５として示されるように提出している。これらの数字は買い／売りスプレッドである。これは、会話パネルにおいて、たとえば青色で示され、なぜならばそれは入来メッセージであるからである。注目すべきは、パネルにおける先のエントリはクライアントの自身の会話であるという点である。これは代表的な色たとえば緑で示される。取引スタックは、ステータスにおける買い／売りへの変更を、そのステータスを緑で強調して示す。これは、アクションがクライアントによって必要とされていること、および取引の次の段階はオファープライスでの買いまたは売りに対する同意であるかまたは拒否であることを示す。取引情報ラインは、オファープライス、アマウント、通貨ペアおよびを示すことと、底部のストリップ２１２、２１４上の大きなボックスは、今、買い／売りプライスを含むこととがわかる。
【０１５３】
図２２は、第１のクライアントがクォートに対する応答をオファープライスでの売りに対する同意によって行なった後のそのクライアントのインタフェースを示す。ステータスは“Ｉ ｓｅｌｌ（私は売る）”に変っており、取引ラインは現在“Ｉ ｓｅｌｌ １ ｍｉｌ ＪＰＹ ｕｓｅｄ／ＪＰＹ ＠ １２３．３３．”と読める。会話パネルにおける最後の行は、緑色で、クライアントは売りを行ない、赤色でシステムプロンプトＳｅｌｌ？（ 売り？）に先行されている。このプロンプトが現われるのはユーザが「Ｓｅｌｌ」とタイピングし、ステータスの売りへの変更がパーサによって検出されユーザインタフェースに戻されるがただしそれはクライアントがその売りの確認を続行ボタンを叩くことにより行なう前である場合に現われる。
【０１５４】
取引のステータスが何であれ、パーサは常に新たなＲＦＱを探し求め、それが検出されると、新たな会話を開く。かくして、先の例では、売りに同意する代わりに、クライアントｋｄｕｎａｙ＠ＥＢＳＮは新たな要求たとえば「Ｉ ｗａｎｔ １ ｍｉｌ ｇｐｂ（私は１００万ｇｐｂ欲しい）」などを出してＵＳドルに対し１００万イギリスポンドを買いたい旨を示したということもあり得る。パーサはこのＲＦＱを検出し、新たな会話を開くが、既存の会話を終結しはしない。次いでここで２つの会話が同じ２つの当事者間に存在することになる。いくつかの会話を同じ２つのカウンタパーティ間で同時に行なわせる能力は非常に望ましいものである。システムは多数の同時の会話を同じ２つのカウンタパーティ間でたとえば１０サポートし得る。このことは、当該技術分野において公知でありこの発明において実施されるシステムでも可能である、多数の会話を異なるカウンタパーティで同時に開かせるという能力と混同されるべきではない。
【０１５５】
上述の議論はどのようにシステムがユーザによって入力された会話を取扱うかを説明する。取引の過程においてはいくつかの会話のラインが存在し、しかも各々は論じられた態様で取扱われる。パーサによって取引構造および検出されたフィールドがユーザインタフェースに送られるとすぐに、情報はパーサから失われる。パーサは、好ましくは、会話の履歴に関する情報を保持する何の能力または要件も持たない。
【０１５６】
図２１および図２２にはパーサの２つのさらなる局面が示される。図２１においては、２つの別個の会話がｔｅｓｔ＠ＥＢＳＮとｋｄｕｎａｙ＠ＥＢＳＮとの間にあることがわかる。これら２つの会話は２２４および２２６で取引スタックにおいて示され、会話１および２として会話パネルにおいて示される。図２１では、第２の会話がアクティブである。これは取引スタックの一番上のラインである。システムはエラーメッセージを介しつつあり、なぜならばクォートはアマウントなしで入力されたからである。クォートステータスは代表的な色たとえばピンクで取引スタックに示され、エラーメッセージが赤色でボタンバーの上に表示され、ユーザに問題の出所を教える。この場合、それは「Ｍｕｓｔ ｈａｖｅ Ａｍｏｕｎｔ（アマウントを有さなければならない）」という。エラーは、さらに、会話パネルにおいて反映され、一連のエラーメッセージ「Ａｍｏｕｎｔ Ｒｅｑｕｉｒｅｄ（アマウントが必要）」２２８に続きさらなる強調メッセージ「Ｍｕｓｔ ｈａｖｅ Ａｍｏｕｎｔ」２３０が続く。
【０１５７】
図２２には警告メッセージの他の例が示される。示される状況は図２１の第２の会話の発展である。クォートアマウントが既に入力されているが、システムは、再び、ビッグフィギュアは利用不可であることを示し、そのようにステータスをオレンジ色で強調する。取引スタックにおける第２の取引ラインも警告を示しており、なぜならば取引は当事者のうちの一方によって退けられたからである。
【０１５８】
ここで図１３および図１４に戻って、図１３には記載されたプロセスの概観が示される。ステップ３００で、パーサは、所与の会話に対する識別番号が存在するかどうかを見ることを期待する。存在しなければ、ステップ３０２でそれは新たな取引情報構造を創出し、ステップ３０４で取引のステータスをＡｎｏ ｄｅａｌ＠にセットする。ＩＤが存在する場合には、ステップ３０６で先のパーズから取引ステータスを参照する。しかしながら、このステータスは、パーサには保持されておらず、ユーザインタフェースから与えられる。ステップ３０８で、現在の取引ステータスを取引の次のステージにセットし、ステップ３１０で定義がメッセージに対し現在の取引ステータスに従って与えられる。これらは、会話の中のどの用語をパーサが取引関連情報であるとして認めるかを決定する。
【０１５９】
図１４Ａおよび図１４Ｂにおいて、トレーダはメッセージをユーザインタフェースにステップ４００で入力する。このメッセージはユーザインタフェースによってパーサに送られ、そこでそれは４１０で受取られる。４２０でパーサはそのメッセージのパーズを試みる。パーズし得ない場合、会話型メッセージはチャットサーバに４３０で送られ、次いで、意図される受け手に４４０で送られる。パーズされ得ないメッセージは取引関連コンテンツを全く有さないメッセージである。
【０１６０】
パーサが取引関連情報を検出し得る場合、ステップ４５０でそれはエラーがあるかどうかを判断する。エラーが検出される場合には、エラーメッセージがトレーダに対し４６０で送られる。
【０１６１】
エラーがない場合には、ステップ４７０でパーサはパーズが完了しているかどうかを判断する。完了していない場合には、クライアントは当該情報をステップ４８０で完了するよう求められる。
【０１６２】
パーズが成功裏に完了される場合には、ステップ４９０で取引情報ファイルが更新されステップ５００でパーズ結果がユーザインタフェースで表示される。
【０１６３】
トレーダは、次いで、続行して、パーズされたメッセージをカウンタパーティに送りたいかどうかを（５１０で）判断しなければならない。確認ステージは、先に記載された取引パネル上の続行ボタン、編集ボタンおよびキャンセルボタンによって実行される。図１４Ｂの単純化された図においては、編集機能は図示されていない。トレーダが続行を望まない場合、取引は、ステップ５２０において、カウンタパーティに示されることなくキャンセルされる。トレーダが続行を望む場合には、５３０で、パーズされたメッセージは取引サーバに送られ、５４０で、取引サーバはパーズされたメッセージをシステムビジネス規則に対して確認するよう試みる。取引をステップ５５０において確認し得ない場合には、トレーダには知らされるが、カウンタパーティのトレーダはメッセージがかつて送られたという表示は全く受けない。取引が確認されると、次いで、確認メッセージがトレーダに対し５６０で送られ、さらにチャットサーバに対し５７０で送られ、および受け手に４４０で送られる。
【０１６４】
パーズが生ずる態様を次により詳細に説明する。
一般的なＦＸ術語モジュールは、トレーダープラットフォーム上のチャットパネルを介してＦＸを取引するディーラーが用いる一般的術語の表示を与える。
【０１６５】
システムは、チャットパネルを介して行なわれるすべての会話をモニタし、会話からのテキストを取引スタック内の固定フォーマットに解釈し、こうして取引詳細を標準化して、システムが各ＦＸ取引ごとに正式な取引チケットを構築できるようにする。
【０１６６】
システムは、取引の完了に関する、会話内の重要な用語を区別することができる。これは、クォートを要求すること、クォートに応答すること、買いまたは売りの確認および特別な決済命令の何らかの通知に関する用語を含む。
【０１６７】
システムは、取引詳細または取引が実際に進んでいるか否かについての曖昧さにつながり得る、会話内の用語を区別することができる。たとえば、ディーラーは、以前のトレードの話をしていたりまたは内々に示唆的なクォートを与えていたりすることがある。
【０１６８】
システムは、取引の完了と関係のない用語を無視することができる。すなわち、天気や特定のニュースについての話などの友人どうしの儀礼的な話は、取引の過程のどの点でそれらが起こっても、システムによって無視される。
【０１６９】
一般的なＦＸ術語要件の機能的要素は以下のとおりである。
チャット術語 − 一般的取引用語
チャット術語 − 否定的用語
チャット術語 − 認識されない用語
要素間の相互作用は以下のとおりである。
【０１７０】
チャット術語 − 一般的取引用語は、完了されるＦＸ取引に直接に関する用語および変数のリストを提供し、これらはシステムによってパーズされなければならない。
【０１７１】
チャット術語 − 否定的用語は、前に出てきた／後に続く用語／フレーズが進行中の取引に関係ないのを示すことにシステムが気づくべき否定的用語のリストを提供する。
【０１７２】
チャット術語 − 認識されない用語は、チャット会話中でシステムが認識しない用語／フレーズをシステムがどのように扱うべきかを示す。
【０１７３】
チャット術語 − 一般的取引用語
システムは、取引の完了に関係のある、会話内で用いられるすべての一般的フレーズおよび用語を認識することができる。会話中の特定の用語は、取引を完了するのに必要な変数の値を与える。システムは、これらの用語をピックアップして、データを取引スタック内の対応のフィールドに送達できるべきである。
【０１７４】
ディーラーは、会話の中で同じことを伝えるのにさまざまな異なる言い方／ショートカットを用いる。システムは、取引スタックに必要なキー変数に関するマーケット慣習をピックアップすることができる。
【０１７５】
クォート要求の一部として、システムは、ユーザが単一のＩＳＯ通貨コード‘ＣｕｒｒＸ’またはそのニックネームを入力して、通貨ペアＵＳＤ／ＣｕｒｒＸをたとえば以下のように表わすのを許す。
【０１７６】
ＣＨＦ＝ＵＳＤ／ＣＨＦ
ＮＺＤ＝ＮＺＤ／ＵＳＤ
ＧＢＰ＝ＧＢＰ／ＵＳＤ
Ｃａｂｌｅ＝ＧＢＰ／ＵＳＤ
Ｐｅｓｏ＝ＵＳＤ／ＭＸＰ
システムは、ユーザが完全な通貨ペア、すなわち両方の通貨の参照を以下のフォーマットで入力することを許す。
【０１７７】
通貨１／通貨２
通貨１ 通貨２
通貨１通貨２
通貨１−通貨２
システムは、大きさを表わす標識を用いてユーザがアマウントを特定することを許す。たとえば、
１０ｍｉｏ＝１０００万
５００ｋ＝５０万
１ｂｉｏ＝１０億
大きさを表わす標識なしでユーザがアマウントを特定する場合、システムは、１００万単位で表わされたものとしてそのアマウントを解釈する。たとえば、
１０＝１０００万
ＣＨＦを２０＝２０００万ＵＳＤに対するＵＳＤ／ＣＨＦ
ＧＢＰを５００ｋ＝５０万ＧＢＰに対するＧＢＰ／ＵＳＤ
システムは、以下のフォーマットのいずれでユーザがツーウェイクォートを特定するのも許す。
【０１７８】
ビッドクォート／オファークォート
ビッドクォート−オファークォート
ビッドクォート オファークォート
ビッドクォート＊オファークォート
ユーザは、以下のフォーマットのいずれでワンウェイビッドクォートを特定してもよい。
【０１７９】
ビッドクォート／−
［ビッドクォート］で買い
［ビッドクォート］でビッド
ユーザは、以下のフォーマットのいずれでワンウェイオファークォートを特定してもよい。
【０１８０】
−／オファークォート
［オファークォート］で売り
［オファークォート］でオファー
ユーザは以下の用語を用いて取引を確認してもよい。
【０１８１】
ｏｋ
ｄｏｎｅ
ｃｏｎｆｉｒｍｅｄ
ｃｏｎｆ
ａｇｒｅｅｄ
ａｇｒｅｅ
システムは、以下の用語のいずれを用いてユーザが取引をキャンセルするのも許す。
【０１８２】
Ｃａｎｃｅｌ
Ｃａｎｃ
Ｎｏｔｈｉｎｇ
Ｎｏｔｈｎｇ
Ｎｔｈｉｎｇ
Ｎｔｈｎｇ
ＮＴ
Ｎｏ Ｔｈａｎｋｓ
Ｎｏ ｔｈｋｓ
ユーザが会話の中で取引をキャンセルすれば、システムは、取引スタック中の当該取引エントリを自動的にキャンセルする。
【０１８３】
チャット術語 − 否定的用語
システムは、システム上のディーラーがチャットパネルを介して以前完了済みの取引の話をすることがあるが、取引を完了しようとしていないことを考慮する。システムは、ディーラがしている現在の会話が取引に関係ないことを示す用語を認識する。
【０１８４】
システムは、（…部をどの文字とも置換して）過去の事象を示す入力／文の同じ行の中で以下のフレーズが変数の前に来る場合は、チャットパネルからいかなる変数もパーズしようとしない。
【０１８５】
…ｄｉｄ… ［取引変数］
…ｄｅａｌｔ… ［取引変数］
…ｃｏｍｐｌｅｔｅｄ… ［取引変数］
…ｍａｄｅ… ［取引変数］
…ｑｕｏｔｅｄ… ［取引変数］
…ｂｏｕｇｈｔ… ［取引変数］
…ｓｏｌｄ… ［取引変数］
上記用語の出現するいくつかの例は以下のとおりである。
【０１８６】
Ｗｅ ｄｉｄ １０ ｍｉｏ ＥＵＲ ｙｓｔｄ − ディーラーは過去の取引に言及している
Ｗｅ ｄｅａｌｔ ｃａｂｌｅ ｉｎ １０ ｌａｓｔ ｗｅｅｋ − ディーラーは過去の取引に言及している
Ｉ ｃｏｍｐｌｅｔｅｄ ｔｈｅ ｓｔｇ ｄｅａｌ − ディーラーは過去の取引に言及している
Ｈｅ ｍａｄｅ ｍｅ ｓｔｇ ａｔ ６７／７０ − ディーラーは過去の取引に言及している
Ｉ ｈａｖｅ ｄｏｎｅ ａ ｄｅａｌ ｆｏｒ Ｓｗｉｓｓ ｉｎ ２０ − ディーラーは過去の取引に言及している
Ｈｅ ｑｕｏｔｅｄ ６７／７０ − ディーラーは過去の取引に言及している。
【０１８７】
ユーザが過去の事象に関するフレーズ／用語を入力した場合、システムは、カウンタパーティに入力が送られたすぐ後、チャットパネルのそのモニタプロセスを継続する。たとえば、
Ｗｅ ｄｉｄ Ｅｕｒ ｙｅｓｔｅｒｄａｙ
Ｉ ｗａｎｔ ２０ ＣＨＦ ｔｏｄａｙ − ディーラーはまず過去の取引に言及しているが、これは上記ルールに基づいてシステムによって無視される。第２の文は、ＵＳＤ／ＣＨＦ、２０００万ＵＳＤに対するＲＦＱであり、これはシステムによってパーズされる。
【０１８８】
Ｉ ｄｉｄ ｎｏｔ ｑｕｏｔｅ ｙｏｕ ＣＨＦ ａｔ ５０／４７
Ｉｔｓ ６０／５７ − ディーラーは過去のクォート（またはこの場合は間違ったクォート）にまず言及するが、これは上記ルール２．３．２．１に基づいてシステムによって無視される。第２の文はＵＳＤ／ＣＨＦに対するクォートであり、システムによってパーズされる。
【０１８９】
チャット術語 − 認識されない用語
チャットパネルは、取引プロセスとは関係のないさまざまな日常会話に用いられる。システムは、取引使用欄（ｄｅａｌ ｕｓｅ ｃａｓｅ）の要件に合わないすべての用語を無視する。
【０１９０】
ＦＸスポットパーズ
ＦＸスポットモジュールは、ＥＢＳトレーダープラットフォーム上のチャットパネルを介してＦＸスポット証券タイプを取引する能力をユーザに与える。
【０１９１】
ＦＸスポットパーズ要件の機能的要素は、取引使用欄およびチャット術語−取引用語である。取引使用欄は取引を完了するプロセスを記載し、実際の取引に関係のある、会話内に見られるであろう特定の用語／フレーズをシステムが能動的に‘待受け’できるようにする。チャット術語−取引用語は、完了される取引に直接に関係のある用語および変数のリストを提供し、これらはシステムによってパーズされなければならない。
【０１９２】
取引使用欄
ＦＸスポット取引を完了させるには、以下のことが起こらなければならない。
【０１９３】
クォートに対するＦＸスポット要求は、テイカーによりそのメイカーに送られる。
【０１９４】
応答して、メイカーは以下のいずれかを行なうことができる。すなわち、ＲＦＱに応答してツーウェイクォート（ビッドおよびオファー）を与える、ただしこれはアマウントがＲＦＱに示された場合のみ；ＲＦＱに応答してワンウェイクォート（ビッドもしくはオファー）を与える、ただしこれはアマウントがＲＦＱに示された場合のみ；ＲＦＱに応答して特定のアマウントに対するクォートを与える；または、クォートを与えたくないことを示すので取引は発生しない。
【０１９５】
テイカーはクォートを受ける。応答して、テイカーは以下のいずれかを行なうことができる。すなわち、買いたいことを示して、取引を確認する；売りたいことを示して、取引を確認する；または、テイカーがそのクォートを気に入らなければ取引をキャンセルする。
【０１９６】
これで取引が完了する。
システムは、ＦＸスポット取引がディーリングプロセス内にある段階を認識する。システムは、取引プロセスの特定の段階に関係のある特定のフレーズを待受ける。チャットパネル内で現在取引が進行していなければ、システムはクォート要求の表示を求めてチャットパネルをモニタする。特に、システムは、チャットパネルの会話の中でクォート要求が開始されたことを示す以下の用語を待受ける。
【０１９７】
証券タイプ（ＦＸスポット）の表示
通貨ペアの表示
アマウントの表示
そのアマウントの通貨の表示
クォート要求は少なくとも通貨ペアの表示を含む。いくつかの例は以下のとおりである。
【０１９８】
ｈｉｈｉ ＣＨＦ ｐｌｓ − テイカーはＵＳＤ／ＣＨＦのクォートを要求している。
ｈｉ ＣＨＦ ｉｎ １０ ｐｌｓ − テイカーは１０００万ＵＳＤに対するＵＳＤ／ＣＨＦのクォートを要求している
Ｈｉｈｉ ＳＰＯＴ ＳＴＧ ｉｎ １０ ｐｌｓ − テイカーは１０００万ＧＢＰに対するＧＢＰ／ＵＳＤのクォートを要求している
Ｈｉ ｆｒｄ ＧＢＰ／ＥＵＲ ｐｌｓ − テイカーはＧＢＰ／ＥＵＲに対するクォートを要求している
Ｗｅｌｌｙ ｆｏｒ ２０ ｐｌｓ − テイカーは２０００万ＮＺＤに対するＮＺＤ／ＵＳＤのクォートを要求している。
【０１９９】
システムは、ＲＦＱの一部として表示されるすべての変数を会話から取引スタックの適切なフィールドにパーズする。
【０２００】
システムがリクエスト・フォー・クォートを識別し、かつそれがメイカーに送信されたならば、システムは、システム・フォー・クォートに対する応答の表示を求めてチャットパネルをモニタする。システムは、リクエスト・フォー・クォートに対する応答を表示するチャットパネル内の以下の用語を待ち受ける：
ビッドクォートの表示
オファークォートの表示
クォートの拒否の表示
アマウントの表示
アマウントの通貨の表示。
【０２０１】
リクエスト・フォー・クォートに対する応答は、以下の少なくとも１つとともに、アマウントがＲＦＱ内に与えられていないならばこれを含む：
ビッドクォート
オファークォート、または
クォートの拒否。
【０２０２】
リクエスト・フォー・クォートに対する応答の例のいくつかである：
１．４６９６／４７００−メイカーがツーウェイクォート、すなわちビッド／オファーを提供する
４６９６／４７００−メイカーがツーウェイクォート、すなわちビッド／オファーを提供する
９６／００−メイカーがツーウェイクォート、すなわちビッド／オファーを提供する
５６−６０ ｕｐ ｔｏ １０−メイカーがツーウェイクォート、すなわちビッド／オファーおよびアマウント、すなわち１０００万の表示を提供する
Ｉ ｂｕｙ ａｔ ６０−メイカーがワンウェイクォート、すなわちオファークォートを提供する
Ｎｏｔｈｉｎｇ−メイカーがクォートするのを拒否する。
【０２０３】
システムは、リクエスト・フォー・クォートに対する応答においてメイカーによって表示されるすべての変数を会話から取引スタック中の適切なフィールドにパーズする。クォートの拒否は、メイカーがこの意思をチャットパネルに入力するかまたは取引スタックを介して取引をキャンセルするならば表示される。メイカーがクォートするのを拒否するならば、システムは取引がキャンセルされたと結論付ける。メイカーがクォートするのを拒否するならば、システムはそのモニタプロセスを再開し、会話内のリクエスト・フォー・クォートを探す。システムは確実に、テイカーが買うまたは売る意思を表示することを可能にする前に以下の変数が会話から取引スタックにパーズされてしまうようにする：
通貨ペア
アマウント
アマウントの通貨
ビッドおよび／またはオファー。
【０２０４】
上記変数がすべて取引スタックにうまくパーズされたのでなければ、システムは、メイカーが送信する意思を表示する前に抜けている変数を入力することを要求する。たとえば、システムはアラームを発してもよい。システムがリクエスト・フォー・クォートに対する応答を識別し、かつ応答がテイカーに送信されたならば、システムは、クォートに対する応答を求めてチャットパネルをモニタする。
【０２０５】
システムは、クォートに対する応答を表示する、チャットパネル内の以下の用語を待ち受ける：
オファープライスで買うという表示
ビッドプライスで売るという表示
取引のキャンセルの表示。
【０２０６】
クォートに対する応答は以下の少なくとも１つを含む：
オファープライスで買うという表示
ビッドプライスで売るという表示
取引のキャンセルの表示。
【０２０７】
クォートに対する応答のいくつかの例である：
ＯＫ， Ｉ ｂｕｙ−テイカーがクォートに満足しオファープライスで買うことに同意する
ＯＫ， ｍｉｎｅ ｉｎ １０−テイカーがクォートに満足し１０００万のアマウントについてオファープライスで買うことに同意し、アマウント「１０」はシステムによって無視され、入手可能なすべてのアマウントが買われる
Ｙｏｕｒｓ−テイカーがクォートに満足しビッドプライスで売ることに同意する
ＯＫ， Ｉ ｓｅｌｌ−テイカーが売ることに同意する
Ｎｏｔｈｉｎｇ ｔｈｋｓ−テイカーがクォートを気に入らず取引を希望しない。
【０２０８】
テイカーがキャンセルする意思を入力するか（テイカーがプライスを気に入らない）またはテイカーが取引スタック内の取引をキャンセルするならば、取引のキャンセルが表示される。テイカーが取引をキャンセルするならば、システムはそのモニタプロセスを再開し会話内のリクエスト・フォー・クォートを探す。システムがクォートに対する応答を識別したならば、システムは、取引スタック内の取引を確認し、そのモニタプロセスを再開し、会話内のリクエスト・フォー・クォートを探す。
【０２０９】
チャット術語−Ｂ取引用語
システムは、取引の完了に直接関係のある、会話内に使用されるすべてのフレーズおよび用語を認識することができる。
【０２１０】
会話内の特定の用語が、取引が締結されるために必要である変数のための値を与える。システムは、これらの用語を拾い上げて取引スタック内の対応のフィールドにデータを引渡すことができる。
【０２１１】
ディーラーは、会話内の同じことを伝えるのに種々の異なった方法／ショートカットを用いる。システムは、取引スタックに必要とされるキー変数と関連するマーケット上の規定を理解することができる。
【０２１２】
リクエスト・フォー・クォートの一部として、システムは、ユーザが「スポット」という用語を入力して取引がＦＸスポット取引であることを表示することを可能にする。たとえば：
ＳＰＯＴ Ｓｗｉｓｓ ｐｌｅａｓｅ−ＵＳＤ／ＣＨＦのＦＸスポット取引である。
【０２１３】
リクエスト・フォー・クォートの一部として、システムは、ユーザがアマウントとともにまたはアマウントなしで通貨ペアを指定して取引がＦＸスポット取引であることを表示することを可能にする。たとえば：
Ｓｔｇ ｐｌｓ＝ＧＢＰ／ＵＳＤのＦＸスポット取引である
ＥＵＲ ｐｌｓ＝ＥＵＲ／ＵＳＤのＦＸスポット取引である
Ｅｕｒ ｉｎ １０ ｐｌｓ＝ＥＵＲ／ＵＳＤのＦＸスポット取引であって、アマウントは１０００万ＥＵＲである
ＣＨＦ ｆｏｒ ２０＝ＵＳＤ／ＣＨＦのＦＸスポット取引であって、アマウントは２０００万ＵＳＤである。
【０２１４】
システムは、ユーザが通貨のアマウントを指定して買うまたは売ることを可能にする。たとえば：
１０ ｍｉｏ ＧＢＰ ａｇｉｎｓｔ ＵＳＤ ｐｌｓ＝ＵＳＤ／ＧＢＰ、１０００万ＧＢＰ
Ｅｕｒ ｐｌｓ， １０ ｍｉｌｌｉｏｎ ＵＳ＝ＥＵＲ／ＵＳＤ、１０００万ＵＳＤ。
【０２１５】
ユーザがアマウントの通貨を具体的に表示しなければ、システムは通貨ペアの基準通貨でアマウントを表わすようそのアマウントを解釈する。たとえば：
ｅｕｒ ｉｎ １０ ｐｌｓ＝ＥＵＲ／ＵＳＤ、１０００万ＥＵＲ
ｃｈｆ ｆｏｒ １０＝ＵＳＤ／ＣＨＦ、１０００万ＵＳＤ
５０ ｍｉｏ Ｗｅｌｌｙ ｐｌｓ＝ＮＤＺ／ＵＳＤ、５０００万ＮＺＤ。
【０２１６】
システムは、ユーザが、ビッドであってもオファーであっても、クォートの最初の部分の一部として１回のみビッグフィギュアを入力することを可能にする。たとえば：
１．４５６７／７０＝＞ビッドクォート＝１．４５６７、オファークォート＝１．４５７０
１２１．４３／５３＝＞ビッドクォート＝１２１．４３、オファークォート＝１２１．４３。
【０２１７】
システムは、ユーザが、ビッグフィギュアなしで、すなわちクォートのピップのみでクォートを入力することを可能にする。たとえば：
６７／７０＝＞ＧＢＰ／ＵＳＤクォート、ビッドクォート＝１．４５６７、オファークォート＝１．４５７０
４３／５３＝＞ＧＢＰ／ＪＰＹクォート、ビッドクォート＝１２１．４３、オファークォート＝１２１．５３。
【０２１８】
システムは、有効なビッグフィギュアがなければユーザに警告する。システムは、ユーザが以下の用語を用いて定められたアマウントの通貨を買いたいということを表示することを可能にする：
Ｂｕｙ
Ｍｉｎｅ
Ｍ
Ｂ
Ｔａｋｅ
Ｔ
Ａｔ［オファープライス］
［オファープライス］。
【０２１９】
システムは、ユーザが以下の用語を用いて定められたアマウントの通貨を売りたいということを表示することを可能にする：
ｓｅｌｌ
Ｙｏｕｒｓ
Ｙ
Ｓ
ｇｉｖｅ
Ｇ
Ａｔ［ビッドプライス］
［ビッドプライス］。
【０２２０】
システムは、テイカーが買うまたは売る意思を表示することを可能にする。たとえば：
Ｉ ｓｅｌｌ ＣＨＦ＝ユーザが、前に表示されたマウントのＣＨＦを売る
Ｙ＝ユーザが、前に表示された通貨の、前に表示されたアマウントを売る。
【０２２１】
ＦＸアウトライト
ＦＸアウトライトのためのパージング要件は、ＦＸスポットについて記載されたものと同様である。
【０２２２】
以下は、ＦＸアウトライト取引を完了するために辿られるプロセスの説明である。
【０２２３】
ＦＸアウトライトのリクエスト・フォー・クォートは、テイカーによってそのメイカーに送信される。
【０２２４】
これに応答して、メイカーは、ＲＦＱに応答してツーウェイクォート（ビッドおよびオファー）を提供するか−これは、アマウントがＲＦＱに表示された場合のみである；ＲＦＱに応答してワンウェイクォート（ビッドまたはオファー）を提供するか−これは、アマウントがＲＦＱに表示された場合のみである；ＲＦＱに応答して特定のアマウントについてクォートを提供するか；または、彼がクォートを与えることを望まず、取引が行なわれないか、のいずれかができる。
【０２２５】
テイカーはクォートを受信する。これに応答して、彼は、：買いを希望し取引を確認することを表示するか；売りを希望し取引を確認することを表示するか；取引Ｂをキャンセルするか−テイカーがクォートを気に入らない；のいずれかができる。
【０２２６】
取引はここで完了する。
システムは、取引がディーリングプロセス内で関わっている段階を認識し、取引プロセスの特定の段階に直接関係のある特定のフレーズを待ち受ける。取引がチャットパネル内で現在進行中でなければ、システムは、リクエスト・フォー・クォートの表示を求めてチャットパネルをモニタする。リクエスト・フォー・クォートがチャットパネルの会話内で起動されたことを表示する以下の用語が待ち受けられる：
証券タイプ（ＦＸアウトライト）の表示
通貨ペアの表示
アマウントの表示
アマウントの通貨の表示
期間／フォワードデート（ｆｏｒｗａｒｄ ｄａｔｅ）の表示。
【０２２７】
リクエスト・フォー・クォートは、少なくとも以下を含む：
通貨ペアの表示
証券タイプの表示
期間／フォワードデートの表示。
【０２２８】
リクエスト・フォー・クォートのいくつかの例である：
ｈｉｈｉ Ｏｕｔｒｉｔｅ ３ｍ ＣＨＦ ｐｌｓ−テイカーが、３ヶ月で満期になるＵＳＤ／ＣＨＦのＦＸアウトライトのクォートを要求している
ｈｉ Ｏｕｔ １０ ｍｉｏ ＣＨＦ ６ｍ ｐｌｓ−テイカーが、６ヶ月で満期になる１０００万ＵＳＤについてＵＳＤ／ＣＨＦのＦＸアウトライトのクォートを要求している
Ｈｉｈｉ ｏ／ｒ ｃａｂｌｅ ｉｎ １０ ｍａｔｕｒｉｔｙ ５ Ｊａｎ ０１ ｐｌｓ−テイカーが、２００１年１月５日に満期になる１０００万ＧＢＰについてＧＢＰ／ＵＳＤのＦＸアウトライトのクォートを要求している
Ｈｉ ｆｒｄ Ｏｕｔｒｉｔｅ ＧＢＰ／ＥＵＲ １ｙｒ ｐｌｓ−テイカーが、１年で満期になるＧＢＰ／ＥＵＲのＦＸアウトライトのクォートを要求している。
【０２２９】
システムは、ＲＦＱの一部として表示されたすべての変数を会話から取引スタック中の適切なフィールドにパーズする。システムがリクエスト・フォー・クォートを識別し、かつＲＦＱがメイカーに送信されたならば、それは、リクエスト・フォー・クォートに対する応答の表示を求めてチャットパネルをモニタする。
【０２３０】
リクエスト・フォー・クォートに対する応答を表示するチャットパネル内の以下の用語が待ち受けられる：
ビッドクォートの表示
オファークォートの表示
クォートの拒否の表示
アマウントの表示。
【０２３１】
リクエスト・フォー・クォートに対する応答は、以下の少なくとも１つとともにアマウント（ＲＦＱ内に与えられていない場合）を含む：
ビッドクォート
オファークォート、または
クォートの拒否。
【０２３２】
リクエスト・フォー・クォートに対する応答のいくつかの例である：
１．４３０１／０８−メイカーがツーウェイクォート、すなわちビッド／オファーを提供する
４６９６／４７００−メイカーがツーウェイクォート、すなわちビッド／オファーを提供する
０．８７５６３−６２−メイカーがツーウェイクォート、すなわちビッド／オファーを提供する
１０６．７０ ９０ Ｓｐｏｔ １０７．００ ０３−メイカーがツーウェイクォート、すなわちビッド／オファーおよびスポットスプリット、すなわち１０７．００／１０７．０３を提供する
Ｎｏｔｈｉｎｇ−メイカーがクォートするのを拒否する。
【０２３３】
リクエスト・フォー・クォートに対する応答におけるメイカーによって表示されるすべての変数は、会話から取引スタック中の適切なフィールドにパーズされる。クォートの拒否は、メイカーがこの意思をチャットパネルに入力するかまたはメイカーが取引スタック中の取引をキャンセルするならば表示される。
【０２３４】
メイカーがクォートするのを拒否するならば、システムは取引がキャンセルされたと結論し、モニタプロセスが再開され、会話内のリクエスト・フォー・クォートを探す。
【０２３５】
システムは確実に、テイカーが買うまたは売る意思を表示することを可能にする前に以下の変数が会話から取引スタックにパーズされてしまうようにする：
期間／フォワードデートの表示
通貨ペア
アマウント
アマウントの通貨
ビッドおよび／またはオファー。
【０２３６】
上記変数がすべて取引スタックにうまくパーズされたのでなければ、システムは、メイカーが送信する意思を表示する前に抜けている変数を入力することを要求する。システムがリクエスト・フォー・クォートに対する応答を識別し、かつ応答がテイカーに送信されたならば、それは、クォートに対する応答を求めてチャットパネルをモニタする。クォートに対する応答を表示する以下の用語がチャットパネル内で待ち受けられる：
買うという表示
売るという表示
取引のキャンセルの表示。
【０２３７】
クォートに対する応答は、以下の少なくとも１つを含む：
買うという表示
売るという表示
取引のキャンセルの表示。
【０２３８】
クォートに対する応答のいくつかの例である：
Ｏｋ， Ｉ ｂｕｙ−テイカーがクォートに満足しオファープライスで買うことに同意する
Ｎｏｔｈｉｎｇ ｔｈｋｓ．−テイカーがクォートを気に入らず、取引を希望しない。
【０２３９】
テイカーが、キャンセルする意思を入力するか（テイカーがプライスを気に入らない）またはテイカーが取引スタック中の取引をキャンセルするならば、取引のキャンセルが表示される。テイカーが取引をキャンセルするならば、システムはそのモニタプロセスを再開し会話内のリクエスト・フォー・クォートを探す。システムがクォートに対する応答を識別したならば、システムは、取引スタック中の取引を確認し、そのモニタプロセスを再開して会話内のリクエスト・フォー・クォートを探す。
【０２４０】
リクエスト・フォー・クォートの一部として、システムは、ユーザが以下の用語の１つを入力して取引がＦＸアウトライト取引であることを表示することを要求する：
Ｏｕｔｒｉｇｈｔ
Ｏｕｔｒｉｔｅ
Ｏｕｔ
Ｏ／ｒ。
【０２４１】
リクエスト・フォー・クォートの一部として、システムはユーザが通貨ペアを指定することを要求する。たとえば：
Ｏｕｔｒｉｇｈｔ ６ｍ Ｓｔｇ ｐｌｓ＝ＧＢＰ／ＵＳＤについて６ヶ月のＦＸアウトライト
Ｏｕｔ ３ｍ ＥＵＲ ｐｌｓ＝ＥＵＲ／ＵＳＤについて３ヶ月のＦＸアウトライト
Ｏ／ｒ ２３／０１ Ｅｕｒ ｉｎ １０ ｐｌｓ＝ＥＵＲ／ＵＳＤのＦＸアウトライトであって、アマウントは１０００万ＥＵＲであり、満期は２３／０１／０１である
Ｏｕｔｒｉｔｅ ９ｍｔｈ ＣＨＦ ｆｏｒ ２０＝ＵＳＤ／ＣＨＦについて９ヶ月のＦＸアウトライトであって、アマウントは２０００万ＵＳＤである。
【０２４２】
ユーザは、買うまたは売る通貨のアマウントを指定することができる、たとえば：
Ｏｕｔｒｉｔｅ １０ ｍｉｏ ＧＢＰ ａｇａｉｎｓｔ ＵＳＤ ６ｍ ｐｌｓ＝ＧＢＰ／ＵＳＤ、１０００万ＧＢＰ、６ヶ月の期間。
【０２４３】
Ｏｕｔｒｉｔｅ Ｅｕｒ ｐｌｓ， １０ ｍｉｌｌｉｏｎ ＵＳ ６ｍ＝ＥＵＲ／ＵＳＤ、１０００万ＵＳＤ、６ヶ月の期間。
【０２４４】
ユーザがアマウントの通貨を具体的に表示しなければ、システムは、通貨ペアの基準通貨でアマウントを表示するようそのアマウントを解釈する、たとえば：
Ｏｕｔ ｅｕｒ １０ｍｉｏ ３ｍ ｐｌｓ＝ＥＵＲ／ＵＳＤ、１０００万ＥＵＲ、３ヶ月
Ｏｕｔ ｃｈｆ ｆｏｒ １０ ｍｏｎｔｈｓ， ２０ ｍｉｏ＝ＵＳＤ／ＣＨＦ、１０ヶ月、２０００万ＵＳＤ
５０ ｍｉｏ Ｗｅｌｌｙ ｏｕｔ ｐｌｓ， ３ｍ＝ＮＺＤ／ＵＳＤ、５０００万ＮＺＤ、３ヶ月。
【０２４５】
システムは、ユーザがリクエスト・フォー・クォートの一部として取引の期間を述べることを要求する。
【０２４６】
システムは、リクエスト・フォー・クォートの一部として期間の代わりに満期日（「バリューデート」または「決済日」という言葉が使用され得る）を述べることを可能にする。メイカーは、フォワードビッドレートを直接入力して、ＦＸアウトライトのためのビッドクォートを表わしてもよい。メイカーはフォワードオファーレートを直接入力してＦＸアウトライトのためのオファークォートを表わしてもよい。ユーザは、ビッドであってもオファーであっても、クォートの最初の部分の一部として１回だけビッグフィギュアを入力すればよい。たとえば：
１．４５６７／７０＝＞ビッドクォート＝１．４５６７、オファークォート＝１．４５７０
１２１．４３／５３＝＞ビッドクォート＝１２１．４３、オファークォート＝１２１．４３。
【０２４７】
ユーザは、ビッグフィギュアなしで、すなわちクォートのピップスのみでクォートを入力してもよい。たとえば：
６７／７０＝＞ＧＢＰ／ＵＳＤクォート、ビッドクォート＝１．４５６７、オファークォート＝１．４５７０
４３／５３＝＞ＧＢＰ／ＪＰＹクォート、ビッドクォート＝１２１．４３、オファークォート＝１２１．５３。
【０２４８】
ユーザは、有効なビッグフィギュアがなければシステムによって警告される。ユーザは、以下の用語を用いてフォワードデートに定められたアマウントの通貨を買いたいということを表示してもよい：
Ｂｕｙ
Ｍｉｎｅ
Ｍ
Ｂ
Ｔａｋｅ
Ｔ
Ａｔ（オファープライス）
（オファープライス）。
【０２４９】
ユーザは、以下の用語を用いてフォワードデートに定められたアマウントの通貨を売りたいということを表示することができる：
Ｓｅｌｌ
Ｙｏｕｒｓ
Ｙ
Ｓ
Ｇｉｖｅ
Ｇ
Ａｔ（ビッドプライス）
（ビッドプライス）。
【０２５０】
システムは、テイカーが買うまたは売る意思を表示することを可能にする。たとえば：
Ｉ ｓｅｌｌ ＣＨＦ＝ユーザが、先に表示されたアマウントのＣＨＦを売る
Ｙ＝ユーザが、先に表示された通貨の、先に表示されたアマウントを売る。
【０２５１】
ＦＸフォワードのパージング
取引使用の場合
以下は、ＦＸフォワード取引を完了するために辿られるプロセスの説明である：
ＦＸフォワードのリクエスト・フォー・クォートがテイカーによってそのメイカーに送信される。
【０２５２】
これに応答して、メイカーは：ＲＦＱに応答してツーウェイクォートを提供するか−これはアマウントがＲＦＱに表示された場合のみである；ＲＦＱに応答してワンウェイクォートを提供するか−これはアマウントがＲＦＱに表示された場合のみである；ＲＦＱに応答して特定のアマウントのクォートを提供するか；または彼がクォートを与えることを望まないことを表示するか、この場合には取引が行なわれない、のいずれかができる。
【０２５３】
テイカー（取引のテイカー）がクォートを受信する。これに応答して、彼は：ニアデート（ｎｅａｒ ｄａｔｅ）で売るかファーデート（ｆａｒ ｄａｔｅ）で買うことを望み取引を確認することを表示するか；ニアデートで買い／ファーデートで売ることを望み、取引を確認することを表示するか；または取引をキャンセルするＢテイカーがクォートを気に入らない、のいずれかができる。
【０２５４】
メイカー（取引のメイカー）はテイカーの意思通知を受信する。これに応答して、彼は、スポットレートを与えなければならない。
【０２５５】
テイカーがスポットレートを受信する。これに応答して、彼は取引を確認するかまたはスポットレートを問合せるかのいずれかができる。
【０２５６】
テイカーがスポットレートを問合せる場合、メイカーは問合せの通知を受信する。これに応答して、彼は、新しいスポットレートを与えるか、またはメイカーがどの他のレートにも満足しなければ取引をキャンセルするか、のいずれかができる。
【０２５７】
テイカーが新しいスポットレートを受信する。これに応答して、彼は取引を確認するか；スポットレートを再び問合せるか；またはテイカーが納得を得て満足しなければ取引をキャンセルするか（１度既に問合せられた場合のみ可能である）、のいずれかができる。
【０２５８】
テイカーが取引を確認すると、それはここで完了する。
システムは、取引がディーリングプロセス内で関わっている段階を認識し、取引プロセスの特定の段階に直接関係のある特定のフレーズを待ち受ける。取引がチャットパネル内で現在進行中でなければ、システムは、リクエスト・フォー・クォートの表示を求めてチャットパネルをモニタする。システムは、リクエスト・フォー・クォートがチャットパネル会話内で起動されたことを表示する以下の用語を待ち受ける：
証券タイプ（ＦＸフォワード）の表示
通貨ペアの表示
ニア期間のアマウントの表示
ファー期間のアマウントの表示
アマウントの通貨の表示
バリューデートについての期間／フォワードデートの表示
満期日についての期間／フォワードデートの表示。
【０２５９】
リクエスト・フォー・クォートは少なくとも以下を含む：
通貨ペアの表示
証券タイプの表示
期間／フォワードデートの表示。
【０２６０】
リクエスト・フォー・クォートのいくつかの例は以下のとおりである：
ｈｉｈｉ Ｆｗｄ ３ｍ ＣＨＦ ｐｌｓ−テイカーが、ＵＳＤ／ＣＨＦのＦＸフォワードであって、バリューデートがスポット日であり三ヶ月で満期になるもののクォートを要求する
ｈｉ Ｓｗａｐ １０ ｍｉｏ ＣＨＦ ｓ／ｎ ｐｌｓ−テイカーがスポットネクストの１０００万ＵＳＤについてＵＳＤ／ＣＨＦのＦＸフォワードのクォートを要求している（バリューデートはスポット日であり、満期日はスポット日の次の日である）
Ｈｉｈｉ Ｆｏｒｗａｒｄ ｃａｂｌｅ ｉｎ １０ ｍａｔｕｒｉｔｙ ５ Ｊａｎ ０１ ｐｌｓ−テイカーが、１０００万ＧＢＰについてのＧＢＰ／ＵＳＤのＦＸフォワードであってバリューがスポット日であり２００１年１月５日に満期になるもののクォートを要求する
Ｈｉ ｆｒｄ Ｆｗｄ−Ｆｗｄ ＧＢＰ／ＥＵＲ ６ ｍｏｎｔｈｓ ｖ １ｙｒ ｐｌｓ−テイカーが、６ヶ月内のバリューデートであって１年で満期になる、ＧＢＰ／ＥＵＲのＦＸフォワードのクォートを要求している
Ｈｉ ｓｗｐ ＣＨＦ， ６ ｍｔｈｓ １０ｍｉｏ ａｔ ｎｅａｒ ｅｎｄ １０，５００，０００ ａｔ ｆａｒ−テイカーがＵＳＤ／ＣＨＦのＦＸフォワードのクォートを要求し、１０００万ＵＳＤがスポット日で取引され１０，５００，０００ＵＳＤが満期日（６ヶ月）で取引される。
【０２６１】
システムは、ＲＦＱの一部として表示されるすべての変数を会話から取引スタック中の適切なフィールドにパーズする。システムがリクエスト・フォー・クォートを識別し、かつＲＦＱがメイカーに送信されたならば、それは、リクエスト・フォー・クォートに対する応答の表示を求めてチャットパネルをモニタする。システムは、リクエスト・フォー・クォートに対する応答を表示するチャットパネル内の以下の用語を待ち受ける：
スポットビッドクォートの表示
スポットオファークォートの表示
バリューデートについてのフォワードクォートの表示
クォートの拒否の表示
アマウントの表示。
【０２６２】
リクエスト・フォー・クォートに対する応答は、以下の少なくとも１つとともにアマウント（ＲＦＱに与えられていない場合）を含む：
ビッドクォート
オファークォート、または
クォートの拒否。
【０２６３】
リクエスト・フォー・クォートに対する応答のいくつかの例である：
６０／５６−メイカーがツーウェイクォート、すなわちビッド／オファーを提供する
４６９６／４７００−メイカーがツーウェイクォート、すなわちビッド／オファーを提供する
３８−３０−メイカーがツーウェイクォート、すなわちビッド／オファーを提供する
５６−６０ ｕｐｔｏ １０−メイカーがツーウェイクォート、すなわちビッド／オファーおよびアマウント、すなわち１０００万の表示を提供し、「ｕｐｔｏ」はシステムによって無視される
Ｎｏｔｈｉｎｇ−メイカーがクォートするのを拒否する。
【０２６４】
システムは、リクエスト・フォー・クォートに対する応答においてメイカーによって表示されるすべての変数を会話から取引スタック中の適切なフィールドにパーズする。クォートの拒否は、メイカーがこの意思をチャットパネルに入力するかまたはメイカーが取引スタック中の取引をキャンセルするならば表示される。メイカーがクォートするのを拒否するならば、システムは、取引がキャンセルされたと結論する。メイカーがクォートするのを拒否するならば、システムは、そのモニタプロセスを再開し会話内のリクエスト・フォー・クォートを探す。システムは確実に、テイカーが買うまたは売る意思を表示することを可能にする前に以下の変数が会話から取引スタックにパーズされてしまうようにする：
期間／フォワードデートの表示
通貨ペア
ニアアマウント
ファーアマウント
アマウントの通貨
ビッドおよび／またはオファー。
【０２６５】
上記変数のすべてが取引スタックにうまくパーズされたのでなければ、システムは、メイカーが送信する意思を表示する前に抜けている変数を入力することを要求する。システムがリクエスト・フォー・クォートに対する応答を識別し、かつ応答がテイカーに送信されると、システムは、クォートに対する応答を求めてチャットパネルをモニタする。
【０２６６】
システムは、クォートに対する応答を表示する、チャットパネル内の以下の用語を待ち受ける：
ＬＨＳ（左側）プライスで（基準通貨を）買う／売るという表示
ＲＨＳ（右側）プライスで（基準通貨を）売る／買うという表示
ＲＨＳプライスで（外貨を）買う／売るという表示
ＬＨＳプライスで（外貨を）売る／買うという表示
取引のキャンセルの表示。
【０２６７】
クォートに対する応答は、以下の少なくとも１つを含む：
買う／売るという表示
売る／買うという表示
取引のキャンセルの表示。
【０２６８】
クォートに対する応答のいくつかの例である：
Ｏｋ， Ｉ ｂｕｙ／ｓｅｌｌ−テイカーがクォートに満足し、ＲＨＳプライスでスポット日に現地通貨を買い、満期日に現地通貨を売ることに同意する
Ｏｋ， Ｉ ｓ／ｂ−テイカーがクォートに満足し、ＬＨＳプライスでスポット日に現地通貨を売り満期日に現地通貨を買うことに同意する
Ｎｏｇｈｉｎｇ ｔｈｋｓ−テイカーがクォートを気に入らず取引を希望しない。
【０２６９】
取引のキャンセルは、テイカーがキャンセルする意思を入力するか（彼がプライスを気に入らない）またはテイカーが取引スタック中の取引をキャンセルするならば表示される。テイカーが取引をキャンセルするならば、システムはそのモニタプロセスを再開し会話内のリクエスト・フォー・クォートを探す。システムがクォートに対する応答を識別し、かつクォートに対する応答がメイカーに送信されたならば、システムは、スポットレートの提供を求めてチャットパネルをモニタする。システムは、スポットレートの提供を表示する、チャットパネル内の以下の用語を待ち受ける：
スポットレートの提供
取引のキャンセルの表示（スポットレートが既に問合せ済みの場合のみ）。
【０２７０】
スポットレートの提供のいくつかの例である：
１．４３５０ Ｂ メイカーが１．４３５のスポットレートを使用したがっている。
【０２７１】
システムがスポットレートの提供を識別し、かつレートがテイカーに送信されたならば、システムは、スポットレートに対する応答を求めてチャットパネルをモニタする。
【０２７２】
システムは、スポットレートに対する応答を表示する、チャットパネル内の以下の用語を待ち受ける：
取引確認の表示
スポットレートを問合せることの表示
取引のキャンセルの表示（少なくとも１つのレートが前に提供済みの場合のみ）。
【０２７３】
スポットレートを問合せることのいくつかの例は以下のとおりである：
ｃｈｅｃｋ ｓｐｏｔ−簡潔な最小限の問合せ
ｃｈｅｃｋ ｓｐｏｔ ｓｅｅｍｓ ｈｉｇｈ−条件付きの問合せ。
【０２７４】
システムは、スポットレートの問合せを含むライン全体を返し、メイカーに警告をするスポットレート問合せへのテキストとしてそれを用いる：
取引確認のいくつかの例である：
Ｏｋ−確認、取引が完了した
Ｃｏｎｆｉｒｍ−確認、取引が完了した
Ｄｏｎｅ Ｂ 確認、取引が完了した。
【０２７５】
メイカーが会話内の取引を確認するならば、システムは取引スタック内の関連する取引エントリを確認する。取引のキャンセルは、メイカーがキャンセルする意思を入力するか（メイカーが何かを気に入らない）またはメイカーが取引スタック中の取引をキャンセルするならば表示される。メイカーまたはテイカーが取引をキャンセルするならば、システムはそのモニタプロセスを再開し会話内のリクエスト・フォー・クォートを探す。テイカーが取引を確認すると、システムは取引スタック中の取引を確認しそのモニタプロセスを再開し会話内のリクエスト・フォー・クォートを探す。
【０２７６】
リクエスト・フォー・クォートの一部として、システムは、ユーザが以下の用語の１つを入力して取引がＦＸフォワード取引であることを表示することを要求する。
【０２７７】
Ｓｗａｐ
Ｓｗｐ
Ｆｗｄ
Ｆｏｒｗａｒｄ
Ｆｗｄ−ｆｗｄ
Ｆｗｄ ｆｗｄ
Ｆｗｄｆｗｄ
Ｆｗｄ／ｆｗｄ
リクエスト・フォー・クォートの一部として、システムはユーザが通貨ペアを指定することを要求する。たとえば：
Ｓｗａｐ ６ｍ Ｓｔｇ ｐｌｓ＝ＧＢＰ／ＵＳＤについてのＦＸフォワード６ヵ月
Ｓｗｐ ３ｍ ＥＵＲ ｐｌｓ＝ＥＵＲ／ＵＳＤについて３ヵ月のＦＸフォワード
Ｆｗｄ ２３／０１ Ｅｕｒ ｉｎ １０ ｐｌｓ＝ＥＵＲ／ＵＳＤについてのＦＸフォワード、アマウントは１０００万ＥＵＲであり、満期は２３／０１／０１である
Ｆｏｒｗａｒｄ ９ｍｔｈ ＣＨＦ ｆｏｒ ２０＝ＵＳＤ／ＣＨＦについて９ヵ月のＦＸフォワードであり、アマウントは２０００万ＵＳＤである。
【０２７８】
システムは、ユーザが通貨のアマウントを指定して買うまたは売ることを可能にする、たとえば：
Ｓｗｐ １０ ｍｉｏ ＧＢＰ ａｇａｉｎｓｔ ＵＳＤ ６ｍ ｐｌｓ＝ＧＢＰ／ＵＳＤ、１０００万ＧＢＰ、６ヵ月の期間
Ｓｗａｐ Ｅｕｒ ｐｌｓ， １０ ｍｉｌｌｉｏｎ ＵＳ ６ｍ＝ＥＵＲ／ＵＳＤ、１０００万ＵＳＤ、６ヵ月の期間。
【０２７９】
ユーザがアマウントの通貨を具体的に表示しなければ、システムは、通貨ペアの基準通貨でアマウントを表わすようアマウントを解釈する。たとえば：
Ｏｕｔ ｅｕｒ １０ｍｉｏ ３ｍ ｐｌｓ＝ＥＵＲ／ＵＳＤ、１０００万ＥＵＲ、３ヵ月
Ｏｕｔ ｃｈｆ ｆｏｒ １０ ｍｏｎｔｈｓ， ２０ ｍｉｏ＝ＵＳＤ／ＣＨＦ、１０ヵ月、２０００万ＵＳＤ
５０ ｍｉｏ Ｗｅｌｌｙ ｏｕｔ ｐｌｓ， ３ｍ＝ＮＺＤ／ＵＳＤ、５０００万ＮＺＤ、３ヵ月。
【０２８０】
システムは、ユーザが第２のアマウントを入力してＦＸフォワードのアマウント・ファー・エンド（満期日）を表わすことを可能にする。システムは、ユーザが以下のフォーマットでＦＸフォワードのファー・エンドでのアマウントを表示することを可能にする：
ファーエンド（ｆａｒ ｅｎｄ）／レッグ（ｌｅｇ）での［アマウント］
スプリットアマウント（ファー・エンド／レッグにおける）［アマウント］
［アマウント］スプリットアマウント（ファー・エンド／レッグにおける）
コックアマウント（ファー・エンド／レッグにおける）［アマウント］
［アマウント］コックアマウント（ｃｏｃｋ ａｍｏｕｎｔ）（ファー・エンド／レッグにおける）。
【０２８１】
システムは、ユーザがリクエスト・フォー・クォートの一部として取引の期間を述べることを可能にし、かつユーザがリクエスト・フォー・クォートの一部として期間の代わりに満期日を述べることを可能にする。ユーザは、バリューデートを表わすための期間を述べることができ、期間の代わりにバリューデートを表わすための日付を述べることができる。ユーザは、ＦＸフォワード取引のビッドクォートを表わしかつＦＸフォワード取引のオファークォートを表わすためにポイントを入力してもよい。ユーザがビッドおよびオファークォートの両方をポイントで入力する場合、システムはビッドクォートとして２つのクォートの最初の値（左側）を解釈しパーズし、オファークォートとして２つのクォートの２番目の値（右側）を解釈しパーズする。この場合には、ビッドクォートはオファークォートよりも高く、バリューデートはスポット日よりも前（たとえば明日）であり、システムはビッドクォートのポイント（左側）をビッドレートに加えてフォワードビッドレートを計算する。このレートは、ＦＸフォワードの第１のレッグ（ニアデート）に基準通貨を買う際のレートを表わす。この状況において、通貨ペアのフォワードレートはニアレートよりも低い。もし、ビッドクォートがオファークォートよりも高くかつバリューデートがスポット日よりも前（たとえば明日）であるならば、システムはオファークォートのポイント（右側）をスポットオファーレートに加えてフォワードオファーレートを計算する。このレートは、ＦＸフォワードの第１のレッグ（ニアデート）に基準通貨を売る際のレートを表わす。この状況において、通貨ペアのフォワードレートは、ニアレートよりも低い。ビッドクォートがオファークォートよりも高くかつ満期日がスポット日の後（たとえば１週間）であるならば、システムはスポットビッドレートからビッドクォートのポイント（左側）を減じてフォワードビッドレートを計算する。このレートは、ＦＸフォワードの第２のレッグ・（ファーデート）に基準通貨を売る際のレートを表わす。この状況において、通貨ペアのフォワードレートはニアレートよりも低い。ビッドクォートがオファークォートよりも高くかつ満期日がスポット日よりも前（たとえば明日）であるならば、システムは、オファークォートのポイント（右側）をスポットオファーレートに減じてフォワードオファーレートを計算する。このレートは、ＦＸフォワードの第２のレッグ（ファーデート）に基準通貨を買う際のレートを表わす。この状況において、通貨ペアのためのフォワードレートはニアレートよりも小さい。
【０２８２】
ビッドクォートがオファークォートよりも低くかつバリューデートがスポット日より前（たとえば明日）であるならば、システムは、スポットビッドレートからビッドクォートのポイント（左側）を減じてフォワードビッドレートを計算する。このレートは、ＦＸフォワードの第１のレッグ（ニアデート）に基準通貨を買う際のレートを表わす。この状況において、通貨ペアのフォワードレートはニアレートよりも大きい。
【０２８３】
ビッドクォートがオファークォートよりも低くかつバリューデートがスポット日よりも前（たとえば明日）であるならば、システムはスポットオファーレートからオファークォートのポイント（右側）を減じてフォワードオファーレートを計算する。このレートは、ＦＸフォワードの第１のレッグ（ニアデート）に基準通貨を売る際のレートを表わす。この状況において、通貨ペアのフォワードレートはニアレートよりも大きい。
【０２８４】
ビッドクォートがオファークォートよりも低くかつ満期日がスポット日の後（たとえば１週間）であるならば、システムは、ビッドクォートのポイント（左側）をスポットビッドレートに加えてフォワードビッドレートを計算する。このレートは、ＦＸフォワードの第２のレッグ（ファーデート）に基準通貨を売る際のレートを表わす。この状況において、通貨ペアのフォワードレートはニアレートよりも大きい。
【０２８５】
ビッドクォートがオファークォートよりも高くかつ満期日がスポット日より前（たとえば明日）であるならば、システムはオファークォートのポイント（右側）をスポットオファーレートに加えてフォワードオファーレートを計算する。このレートは、ＦＸフォワードの第２のレッグ（ファーデート）に基準通貨を買う際のレートを表わす。この状況において、通貨ペアのフォワードレートはニアレートよりも大きい。
【０２８６】
ユーザは、ＦＸフォワードと関連付けてスポットビッドクォートを入力してスポットビッドレートを表わすことができ、かつＦＸフォワードと関連付けてスポットオファークォートを入力してスポットオファーレートを表わすことができる。ユーザがＦＸフォワードと関連付けてスポットビッドクォートを入力しなかった場合、システムは、特定の通貨ペアのスポットマーケットミッドレートを用いてスポットビッドレートを表わす。ユーザがＦＸフォワードと関連付けてスポットビッドクォートを入力しなかった場合、システムは特定の通貨ペアのスポットマーケットミッドレートを用いてスポットオファーレートを表わす。
【０２８７】
スワップの２つのレッグのいずれもスポット日に当らなければ、システムは、ユーザがＦＸフォワードと関連付けてバリューデートのビッドクォートを入力しかつＦＸフォワードと関連付けてバリューデートのオファークォートを入力することを可能にする。
【０２８８】
ユーザは、フォワードビッドまたはオファーレートを直接入力してＦＸフォワードのビッドクォートを表わすことができる。
【０２８９】
ユーザがフォワードレートを用いてクォートする場合、システムはレートの第１のもの（左側）をビッドクォートとして解釈しレートの第２のもの（右側）をオファークォートとして解釈する。
【０２９０】
ユーザは、以下の用語を用いてニアデートに定められたアマウントの通貨を買いファーデートに定められたアマウントの通貨を売りたいということを表示することができる：
ｂｕｙ／ｓｅｌｌ
ｂｕｙ ｓｅｌｌ
ｂ／ｓ
ｂ ｓ
Ｉ ｂｕｙ［アマウント］［通貨］ｏｎ［バリューデート］。
【０２９１】
ユーザは、以下の用語を用いてニアデートに定められたアマウントの通貨を売りファーデートに定められたアマウントの通貨を買いたいということを表示することができる：
ｓｅｌｌ／ｂｕｙ
Ｓｅｌｌ ｂｕｙ
ｓｅｌｌ＆ｂｕｙ
ｓ／ｂ
ｓ ｂ
Ｉ ｓｅｌｌ［アマウント］［通貨］ｏｎ［バリューデート］。
【０２９２】
ユーザは、買う／売るまたは売る／買う意思を表示することができる。たとえば：
Ｉ ｓｅｌｌ／ｂｕｙ ＣＨＦ＝ユーザが、先に表示されたマウントのＣＨＦを売り／買う
Ｓ／ｂ＝ユーザが、先に表示された通貨の先に表示されたアマウントを売り／買う。
【０２９３】
テイカーが売り／買いを行なうＦＸフォワード取引の場合、システムは、メイカーが以下のさらなる用語を用いて取引を確認することを可能にする：
ｂｕｙ／ｓｅｌｌ
ｂｕｙ ｓｅｌｌ
ｂｕｙ＆ｓｅｌｌ
ｂ／ｓ
ｂ ｓ。
【０２９４】
メイカーがスポットレートを与えるＦＸフォワード取引の場合、システムは、メイカーがビッグフィギュアなしにレートを与えることを可能にする。システムは、ビッグフィギュアを導出すべきマーケットレートが有効でないならば、ユーザーに警告する。
【０２９５】
この発明は、ユーザに非常に有利なインターフェイスを提供するものであって、しばしば非常に短い間に大量の情報を吸収しなければならないディーラーによって解釈するのが容易である態様で取引スタックがユーザに対して提示されることが上記から理解される。いずれかの特定の証券での取引に特有の情報からすべての証券に共通する情報を分けることにより、簡素で閲覧が容易である取引リストを提示することが可能である。しかしながら、取引の詳細パネルは選択された取引に関連する情報を含んでいるので、トレーダーが、トレーダーが取組んでいる取引に関する必須の情報から取り残されることはない。
【０２９６】
記載されたシステムで取引をする際、トレーダーは、システムによってパーズされる会話型チャットを通じて取引情報を入力するか、または好ましくはユーザインターフェイス上のボタンもしくはキーボードで駆動されるメニューを直接用いるかの選択を有する。トレーダーは、取引の進行中にこの２つを切換えることができる。この柔軟性が可能であるのは、取引に関連した情報の入力が、パーズされた会話であっても直接の入力であっても、取引ステータスの変更があったということを取引スタックに伝えるだけであるためである。すべての他の取引関連の活動は、取引スタックによって行なわれ、システムの残りのもの、たとえばバックオフィスシステムの他のトレーダー端末に必要なメッセージを送信して取引チケットを発生することを含む。取引スタックはまた、すべて取引ステータスに依存するボタンバー上のボタンおよびキーボードメニューの機能を変更する役割も担う。
【０２９７】
なお上記から、取引プロセスにおけるパーサーの活動は取引ステータスにおける変更を検出することに限られている。これは、システムがより柔軟になることを可能にする。これは、１人のみのトレーダーが任意のあるときに会話へのカーソルを「所有」することのできる、会話型メッセージの固定的な交換により動作する先行技術のシステムと対称的である。記載されたシステムでは、取引の任意の当事者が任意のときにシステムに会話を入力することができる。しかしながら、会話が、パーサーがその取引ステータスにおいて関連する取引を認識するよう予めプログラムされている用語を含まなければ、会話は取引プロセスに影響を及ぼさない。したがって、会話がある当事者から他の当事者にたらい回しになる必要がない。取引を行なうプロセスにおけるいかなる段階においても、会話型メッセージを送信する最終の当事者がさらなるメッセージを送信することができる。これがその現在のステータスにおいて取引に関連する内容を含んでいなければ、それはパーサーによって無視され取引に影響を及ぼすことがない。
【０２９８】
記載されたシステムに対する多くの変形がこの発明の範囲内で可能である。特に、この発明は、前掲の特許請求の範囲の制限を超えるトレーディングシステムのアーキテクチャのいずれのタイプにも、証券のいずれの特定のタイプにも限られるものでない。
【図面の簡単な説明】
【図１】トレーディングシステムの概略図である。
【図２】トレーダ端末の主要機能構成要素を示すさらなる概略図である。
【図３】この発明の第一の実施例によるトレーダ端末のユーザインターフェイスの図である。
【図４】いくつかの会話パネルを示す図３に類似の図である。
【図５】ユーザインターフェイス内にあり取引詳細パネルを示す取引スタックの図である。
【図６】図５の取引詳細パネル内の異なった取引がハイライトされた、取引詳細パネルと取引スタックのさらなる図である。
【図７】締結されたフォワード取引のための取引詳細パネルを示す取引スタックのさらなる図である。
【図８】エラーボックスを表示する取引詳細パネルを示す取引スタックのさらなる図である。
【図９】潜在的に変更可能なフィールドをハイライトして表示する取引詳細パネルを示す取引スタックのさらなる図である。
【図１０】ダン取引のバリューを含む、締結されたＦ／Ｘスポット取引を示す取引詳細パネルと取引スタックを示す図である。
【図１１】スポットレートクエリーメッセージとともにフォワード取引を示す取引詳細パネルとともに取引スタックを示す図である。
【図１２】図１１のスポットレートクエリーメッセージがどのように警告メッセージとしてカウンターパーティの取引詳細パネルに現れるかを示す図である。
【図１３】パーズのプロセスの概略を示すフローチャートである。
【図１４Ａ】パーズのプロセスをさらに詳細に示すフローチャートである。
【図１４Ｂ】パーズのプロセスをさらに詳細に示すフローチャートである。
【図１５】メイカーにより入力されたパーズされたメッセージを示すユーザインターフェイスの第二の実施例のスクリーンショットの図である。
【図１６】パーズされたメッセージが送られたがピックアップされていないときの図１５のスクリーンの図である。
【図１７】パーズされたメッセージが受け取られたときのテイカーのインターフェイスの図である。
【図１８】システムがテイカーのクオートを待っているときのテイカーのインターフェイスの図である。
【図１９】クオートが受け取られたときのメイカーのスクリーンの図である。
【図２０】取引が最終決定されたときのメイカーのスクリーンの図である。
【図２１】第一の会話から開始した第二の会話とともに警告メッセージおよびエラーメッセージの例を示す図である。
【図２２】警告メッセージのさらなる例を示す図である。

Claims (74)

1. カウンターパーティ間で証券をトレーディングするための会話型ディーリングシステムであって、
   取引関連情報を含む会話メッセージを入力しかつトレーダーに表示するためのユーザインターフェイスを各々が有する複数のトレーダー端末を含み、前記トレーダー端末は通信ネットワークを介して互いと通信し、トレーダー端末は各々、前記入力された会話メッセージをパーズするためのパーサーをさらに含み、
   前記パーサーは、
   会話メッセージを分析して取引のステータスを検出するための手段を含み、取引は複数の可能なステータスを有し、さらにパーサーは、
   会話メッセージを分析して、検出された取引ステータスに関連の取引関連情報を検出するための手段と、
   取引ステータスおよび取引関連情報を含むパーズされたメッセージをユーザインターフェイスに戻すための手段とを含む、会話型ディーリングシステム。
2. パーサーは、ユーザインターフェイスから与えられる完了した会話メッセージをパーズする、請求項１に記載の会話型ディーリングシステム。
3. パーサーは、ユーザインターフェイスから受けたすべての会話メッセージをモニタして、現在の取引の取引ステータスにかかわらず、新たな取引を識別するための手段を含む、請求項１に記載の会話型ディーリングシステム。
4. ユーザインターフェイスは、新たな取引が識別されると、少なくとも１つの既存の会話を有するカウンターパーティ間で新たな会話を開始するための手段を含む、請求項３に記載の会話型ディーリングシステム。
5. パーサーは、会話メッセージをモニタしてリクエスト・フォー・クォート（ＲＦＱ）を識別する、請求項３に記載の会話型ディーリングシステム。
6. 可能な取引ステータスは、保留中の取引なし、リクエスト・フォー・クォート、クォートおよび買い／売りを含む、請求項１に記載の会話型ディーリングシステム。
7. パーズされたメッセージを戻すための前記手段は、取引情報構造をユーザインターフェイスに戻すための手段を含む、請求項１に記載の会話型ディーリングシステム。
8. ユーザインターフェイスは、パーサーから受けたパーズされたメッセージを表示し、パーズされたメッセージをカウンターパーティに通信する前に、パーズされたメッセージを受入れるかまたは拒否するための手段を含む、請求項１に記載の会話型ディーリングシステム。
9. ユーザインターフェイスは、カウンターパーティへの通信の前に、パーズされたメッセージを編集するための手段をさらに含む、請求項８に記載の会話型ディーリングシステム。
10. パーズされたメッセージを受入れるかまたは拒否するための手段は、ポインティングデバイスによって動作可能な、ユーザインターフェイスディスプレイ上の少なくとも１つのボタンを含む、請求項８に記載の会話型ディーリングシステム。
11. パーズされたメッセージを編集するための手段は、ポインティングデバイスによって動作可能な、ユーザインターフェイスディスプレイ上の少なくとも１つのボタンを含む、請求項９に記載の会話型ディーリングシステム。
12. 取引サーバをさらに含み、取引サーバは、第１のカウンターパーティからのパーズされたメッセージの受入れ可能性をチェックし、かつ、パーズされたメッセージが受入れ不可能な場合、別のカウンターパーティに知らせずに、パーズされたメッセージを拒絶するように働く、請求項１に記載の会話型ディーリングシステム。
13. 取引に関連のない会話を扱うためのチャットサーバをさらに含み、パーサーが一切の取引関連情報を検出しない会話メッセージがチャットサーバを介してデスティネーショントレーダーに送られる、請求項１に記載の会話型ディーリングシステム。
14. パーサーは、トレーダー端末が会話型ディーリングシステムにログオンすると、トレーダー端末にダウンロードされる、請求項１に記載の会話型ディーリングシステム。
15. パーサーはアプレットである、請求項１４に記載の会話型ディーリングシステム。
16. 通信ネットワークを介して互いと通信する複数のトレーダー端末を有する会話型ディーリングシステムのためのトレーダー端末であって、
    取引関連情報を含む会話メッセージを入力しかつトレーダーに表示するためのユーザインターフェイスと、
    前記入力された会話メッセージをパーズするためのパーサーとを含み、
    前記パーサーは、
    会話メッセージを分析して取引のステータスを検出するための手段を含み、取引は複数の可能なステータスを有し、さらにパーサーは、
    会話メッセージを分析して、検出された取引ステータスに関連の取引関連情報を検出するための手段と、
    取引ステータスおよび取引関連情報を含むパーズされたメッセージを形成し、ユーザインターフェイスに戻すための手段とを含む、トレーダー端末。
17. パーサーは、ユーザインターフェイスから与えられた、完了した会話メッセージをパーズする、請求項１６に記載のトレーダー端末。
18. パーサーは、ユーザインターフェイスから受けたすべての会話メッセージをモニタして、現在の取引の取引ステータスにかかわらず、新たな取引を識別するための手段を含む、請求項１６に記載のトレーダー端末。
19. ユーザインターフェイスは、新たな取引が識別されると、少なくとも１つの既存の会話を有するカウンターパーティ間で新たな会話を開始するための手段を含む、請求項１８に記載のトレーダー端末。
20. パーサーは、会話メッセージをモニタしてリクエスト・フォー・クォート（ＲＦＱ）を識別する、請求項１８に記載のトレーダー端末。
21. 可能な取引ステータスは、保留中の取引なし、リクエスト・フォー・クォート、クォートおよび買い／売りを含む、請求項１６に記載のトレーダー端末。
22. パーズされたメッセージを戻すための前記手段は、取引情報構造をユーザインターフェイスに戻すための手段を含む、請求項１６に記載のトレーダー端末。
23. ユーザインターフェイスは、パーサーから受けたパーズされたメッセージを表示し、パーズされたメッセージをカウンターパーティに通信する前に、パーズされたメッセージを受入れるかまたは拒否するための手段を含む、請求項１６に記載のトレーダー端末。
24. ユーザインターフェイスは、カウンターパーティへの通信の前に、パーズされたメッセージを編集するための手段をさらに含む、請求項２３に記載のトレーダー端末。
25. パーズされたメッセージを受入れるかまたは拒否するための手段は、ポインティングデバイスによって動作可能なユーザインターフェイスディスプレイ上の少なくとも１つのボタンを含む、請求項２３に記載のトレーダー端末。
26. パーズされたメッセージを編集するための手段は、ポインティングデバイスによって動作可能な、ユーザインターフェイスディスプレイ上の少なくとも１つのボタンを含む、請求項２４に記載のトレーダー端末。
27. 取引サーバをさらに含み、取引サーバは、第１のカウンターパーティからのパーズされたメッセージの受入れ可能性をチェックし、かつ、パーズされたメッセージが受入れ不可能な場合、別のカウンターパーティに知らせずに、パーズされたメッセージを拒絶するように働く、請求項１６に記載のトレーダー端末。
28. 取引に関連のない会話を扱うためのチャットサーバをさらに含み、パーサーが一切の取引関連情報を検出しない会話メッセージがチャットサーバを介してデスティネーショントレーダーに送られる、請求項１６に記載のトレーダー端末。
29. パーサーは、トレーダー端末がトレーダー端末にログオンすると、トレーダー端末にダウンロードされる、請求項１６に記載のトレーダー端末。
30. パーサーはアプレットである、請求項２９に記載のトレーダー端末。
31. カウンターパーティが通信ネットワークを介して互いと通信する会話型トレーディングシステムにおいてカウンターパーティ間で証券をトレーディングする方法であって、
    取引関連情報を含む会話メッセージをシステムに入力するステップと、
    会話メッセージを分析して取引ステータスを検出するステップとを含み、取引は複数の可能なステータスを有し、さらに
    検出された取引ステータスに関連の取引関連情報を検出するステップと、
    取引ステータスおよび取引関連情報の少なくとも一部を含むパーズされたメッセージを形成するステップとを含む、方法。
32. 会話メッセージはユーザインターフェイスから与えられる、請求項３１に記載の方法。
33. 受けたすべての会話メッセージをパーズして、現在の取引の取引ステータスにかかわらず、新たな取引を識別するステップをさらに含む、請求項３１に記載の方法。
34. 新たな取引が識別されると、少なくとも１つの既存の会話を有するカウンターパーティ間で新たな会話を開始するステップをさらに含む、請求項３３に記載の方法。
35. 会話メッセージをモニタして、リクエスト・フォー・クォート（ＲＦＱ）を識別するステップをさらに含む、請求項３３に記載の方法。
36. 可能な取引ステータスは、保留中の取引なし、リクエスト・フォー・クォート、クォートおよび買い／売りを含む、請求項３１に記載の方法。
37. 取引関連情報をユーザインターフェイスに戻すステップをさらに含む、請求項３１に記載の方法。
38. パーズされたメッセージを表示するステップと、
    カウンターパーティの一方が、パーズされたメッセージを他方のカウンターパーティに通信する前に、パーズされたメッセージを受入れるかまたは拒否できるようにするステップとをさらに含む、請求項３１に記載の方法。
39. 第１の当事者が、パーズされたメッセージを他方のカウンターパーティに通信する前に、パーズされたメッセージを編集できるようにするステップをさらに含む、請求項３８に記載の方法。
40. 第１のカウンターパーティからのパーズされたメッセージの受入れ可能性をチェックするステップと、
    パーズされたメッセージが受入れ不可能な場合、別のカウンターパーティに知らせずに、パーズされたメッセージを拒絶するステップとを含む、請求項３１に記載の方法。
41. チェックするステップは、パーズされたメッセージ中の提案された取引について、カウンターパーティが十分な相互の信用を有するか否かをチェックするステップを含む、請求項４０に記載の方法。
42. チェックするステップは、取引関連情報が会話型ディーリングシステムのビジネスルールに一致することをチェックするステップを含む、請求項４０に記載の方法。
43. 取引に関連のない情報を含む会話メッセージをチャットサーバを介してカウンターパーティの一方に送るステップをさらに含む、請求項３１に記載の方法。
44. ステータスの変化が検出される際、不十分な取引関連情報が、ステータスに関連ありと検出されると、ユーザインターフェイスにエラーメッセージが送られる、請求項３１に記載の方法。
45. エラーメッセージは、進行中の取引専用のユーザインターフェイス区域に表示される、請求項４４に記載の方法。
46. エラーメッセージは、欠落している取引関連情報を識別する、請求項４５に記載の方法。
47. 現在の取引の取引関連情報は第１のリクエスト・フォー・クォートを含み、
    パーサーが第２のリクエスト・フォー・クォートを検出すると、新たな取引が識別される、請求項３に記載の会話型ディーリングシステム。
48. 現在の取引の取引関連情報は第１のリクエスト・フォー・クォートを含み、
    パーサーが第２のリクエスト・フォー・クォートを検出すると、新たな取引が識別される、請求項１８に記載の会話型ディーリングシステム。
49. 現在の取引の取引関連情報は第１のリクエスト・フォー・クォートを含み、
    パーサーが第２のリクエスト・フォー・クォートを検出すると、新たな取引が識別される、請求項３３に記載の会話型ディーリングシステム。
50. パーサーは、伝達されたメッセージの記録を保持しない、請求項１に記載の会話型ディーリングシステム。
51. パーサーは、伝達されたメッセージの記録を保持しない、請求項１６に記載の会話型ディーリングシステム。
52. パーサーは、伝達されたメッセージの記録を保持しない、請求項３１に記載の会話型ディーリングシステム。
53. カウンターパーティ間で証券をトレーディングするための会話型ディーリングシステムであって、
    取引関連情報を含む会話メッセージを入力しかつトレーダーに表示するためのユーザインターフェイスを各々が有する複数のトレーダー端末を含み、トレーダー端末は通信ネットワークを介して互いと通信し、会話メッセージは色分けされた形態で表示されて会話メッセージの発信元をユーザに示す、会話型ディーリングシステム。
54. カウンターパーティのトレーダー端末から受けたメッセージは第１の色で表示され、ユーザインターフェイスで生成されたメッセージは第２の色で表示される、請求項５３に記載の会話型ディーリングシステム。
55. 各トレーダー端末は、端末に入力された会話メッセージをパーズして取引関連情報を抽出しかつパーズされたメッセージを生成するためのパーサーを含み、パーズされたメッセージは第３の色で表示される、請求項５４に記載の会話型ディーリングシステム。
56. 警告メッセージは第４の色で表示される、請求項５４に記載の会話型ディーリングシステム。
57. エラーメッセージは第４の色で表示される、請求項５４に記載の会話型ディーリングシステム。
58. トレーダー間で証券をトレーディングするための会話型ディーリングシステムであって、システムは、
    ネットワークを形成するようにともに結合された複数のトレーダー端末を含み、各々のトレーダー端末はユーザインターフェイスおよびパーサーを含み、
    ユーザインターフェイスは、トレーダー間の取引に関する取引関連情報を含む会話メッセージを受けかつ表示し、
    パーサーは、会話メッセージを分析してトレーダー間の現在の取引ステータスを検出し、パーサーは、会話メッセージをさらに分析して、現在の取引ステータスに関する取引関連情報を検出し、パーサーは、現在の取引ステータスおよび取引関連情報の少なくとも一部を含むパーズされたメッセージを発生する、会話型ディーリングシステム。
59. パーサーは、現在の取引ステータスにかかわらず、新たな取引を識別する、請求項５８に記載のシステム。
60. 現在の取引の取引関連情報は、第１のリクエスト・フォー・クォートを含み、
    新たな取引は、パーサーが第２のリクエスト・フォー・クォートを検出すると識別される、請求項５９に記載のシステム。
61. ユーザインターフェイスは、新たな取引が識別されると、第１の会話を有するトレーダー間で第２の会話を開始する、請求項５９に記載のシステム。
62. パーサーはパーズされたメッセージをトレーダーに表示し、パーズされたメッセージを別のトレーダーに送る前に、トレーダーがパーズされたメッセージを編集するのを許す、請求項５８に記載のシステム。
63. パーサーはパーズされたメッセージをトレーダーに表示し、パーズされたメッセージを別のトレーダーに送ることをトレーダーが拒否するのを許す、請求項５８に記載のシステム。
64. トレーダー端末に結合された取引サーバをさらに含み、取引サーバは、パーズされたメッセージをパーサーから受け、現在の取引の現在のステータスに基づいて、パーズされたメッセージを受入れ可能か否かを判断し、
    取引サーバが、パーズされたメッセージが受入れ不可能と判断すると、取引サーバは、パーズされたメッセージを別のトレーダー端末に送らない、請求項５８に記載のシステム。
65. トレーダー端末に結合されたチャットサーバをさらに含み、
    パーサーは、会話メッセージ中に取引関連情報が存在しない場合、会話メッセージをチャットサーバに送る、請求項５８に記載のシステム。
66. それぞれのトレーダー端末がシステムにアクセスすると、パーサーはそれぞれのトレーダー端末にダウンロードされる、請求項５８に記載のシステム。
67. パーサーはアプレットである、請求項６６に記載のシステム。
68. コンピュータ実行可能ソフトウェアを含むコンピュータ読出可能記憶媒体であって、コンピュータ実行可能ソフトウェアは、
    取引関連情報を含む会話メッセージを受けるステップと、
    会話メッセージを分析して、トレーダー間の取引のステータスを検出するステップと、
    会話メッセージを分析して、取引のステータスに関する取引関連情報を検出するステップと、
    取引ステータスおよび取引関連情報の少なくとも一部を含む、パーズされたメッセージを発生するステップとを行うためのものである、コンピュータ読出可能記憶媒体。
69. ソフトウェアは、現在の取引のステータスにかかわらず、新たな取引を識別するステップをさらに行う、請求項６８に記載の記憶媒体。
70. 現在の取引の取引関連情報は、第１のリクエスト・フォー・クォートを含み、
    新たな取引は、第２のリクエスト・フォー・クォートが検出されると識別される、請求項６９に記載の記憶媒体。
71. ソフトウェアは、新たな取引が識別されると、第１の会話を有するトレーダー間で第２の会話を開始するステップをさらに行う、請求項６９に記載の記憶媒体。
72. ソフトウェアは、パーズされたメッセージをトレーダーに表示するステップと、パーズされたメッセージを別のトレーダーに送る前に、トレーダーがパーズされたメッセージを編集するのを許すステップとをさらに行う、請求項６８に記載の記憶媒体。
73. ソフトウェアは、パーズされたメッセージをトレーダーに表示するステップと、パーズされたメッセージを別のトレーダーに送るのをトレーダーが拒否するのを許すステップとをさらに行う、請求項６８に記載の記憶媒体。
74. ソフトウェアは、現在の取引の現在のステータスに基づいて、パーズされたメッセージを受入れ可能か否かを判断するステップと、
    パーズされたメッセージが受入れ不可能な場合、パーズされたメッセージが別のトレーダー端末に送られるのを禁じるステップとをさらに行う、請求項６８に記載の記憶媒体。

Images