JP4394786B2 - データ管理用コンピュータシステムおよびその操作方法 - Google Patents

Description

【０００１】
【関連出願のクロスリファレンス】
本出願は、本出願人が１９９６年９月１０日に出願したＰＣＴ出願ＰＣＴ／ＥＰ９６／０３９７２号、および、本出願人が１９９５年９月１４日に出願したヨーロッパ特許出願第９５１１４４６７．４号の両優先権を主張して、１９９７年５月１３日に出願した米国特許出願第０８／８３６，７１３号の一部継続出願である。本出願は、本出願人の同時係属出願である、１９９８年１２月４日出願の米国特許出願第６０／１１１，０３０号；１９９８年１２月４日出願の米国特許出願第６０／１１１，０３１号；および１９９８年１２月４日出願の米国特許出願第６０／１１１，０３２号；の優先権を主張する。
【０００２】
【発明の分野】
本発明は、データ管理用コンピュータシステム、およびそのシステムを操作するための方法に関し、より詳細には自動ワラント商取引システム (automated warrant trading system) に関する。
【０００３】
【発明の背景】
従来、ワラントの商取引きは時間がかかり、コスト圧力が高いものであった。なぜなら、顧客である銀行等の金融機関は、電話や刊行物で、消費者にとって最良のワラントを捜し出す調査をする必要があったからである。消費者は、ワラントを購入したい場合は先ず、株式取引所を通すかまたはワラントマーケットメーカー(証券業者：market maker) へ電話をかけて、注文を処理できる消費者の地元銀行に接触する必要があった。履行可能価格を付した取引対象ワラントに関するオンラインの情報商取引システムが存在しなかったので、顧客である地元銀行は、実際のオンライン情報を消費者に提供することができなかった。そのため、顧客による売買注文とその履行との間には時間差があり、その時間差中に相場および／または価格の変動リスクを生じた。
【０００４】
売買注文の履行は、注文したその日に履行できなかった場合、前日の相場に重きを置いた制限範囲をベースにすることが多かった。時間遅れの理由は、注文が何時間も経ってから株式取引所で履行されるか、または証券業者のトレーディングルームの電話が、熱狂的なマーケット時間中で立て込んでいるかのいずれかであった。従って、地元銀行は、知らない価格で盲目的に、消費者からの注文を出してしまうことが多く、即座の取引確認を受け取ることはなかった。
【０００５】
同時係属中の米国特許出願第０８／８３６，７１３号で開示された発明（ここでは「ＣＡＴＳ−ＯＳシステム」または「既存ＣＡＴＳ−ＯＳシステム」と称し、本明細書に引用して組込む）は、これらの問題を扱っており、銀行のデータ管理用コンピュータシステムおよびそのシステムを操作するための方法を提供し、このことは、トランザクションデータ (data transaction) を処理する場合、高度のセキュリティと組み合わせて、精度を上げるとともにエラーの確率を減らして、即時データを提供するデータ管理を実現する。既存ＣＡＴＳ−ＯＳシステムは、クライアント／サーバーアーキテクチャを使用しており、それは、トランザクションサーバー、相場(rate)サーバー、ハンドオフサーバー、クレジットサーバー、およびセキュリティサーバーのような、多数のサーバーを有する。ＣＡＴＳ−ＯＳとの典型的なインタラクションでは、システムの顧客または他のユーザーはそのシステムに結合して、セキュリティマネージャによって認証され、それにより顧客、トレーダー、および管理者の各レベルなどのユーザーレベルに応じて特定の特典をユーザーに与える。
【０００６】
既存ＣＡＴＳ−ＯＳシステムでは、顧客が相場を見て、トランザクションを実行し、これらのトランザクションを見て、実行済みトランザクションのレポートを印刷し、そしてポジションを見ることができるのが普通である。トレーダーは、所望すれば通常のトレーダー機能ではないが、手入力が可能である。通常のトレーダー機能には、新規証券 (instruments) が入手可能になり旧証券が期限切れになる際に証券を維持し、一般的にはシステムを維持し、量 (volume) を維持し、信用 (credit) を維持し、およびユーザー自身を維持する機能が含まれる。主たる相場および販売情報は、顧客システムから自動入力される。顧客は、普通、ワラント価格を算出する種々のシステムを持っている。ＣＡＴＳ−ＯＳシステムは、１日に３００万か４００万にのぼる更新になる可能性のある、顧客システムからやってくる全ての相場情報を本質的に受取り、この情報を別置きの相場サーバーへ入力してから、顧客が取引対象にできるよう保持する。
【０００７】
現在、主としてワラントと普通株を取扱うＣＡＴＳ−ＯＳシステムは、建値 (standing price) ベースで機能し、その中でシステムのホストバンクは自らが所定秒の間保証する価格を発行する。この保証は、ＣＡＴＳ−ＯＳのユーザーが発行価格で取引きできるようにする。しかし、ホストバンクはそのリスクに制限を加えるべく、唯一、その建値での所定規模以下の取引を認めるだけである。従って、既存ＣＡＴＳ−ＯＳシステムに伴なう問題は、ユーザーが、ホストバンクの許容取引規模を超える取引きの実行を必要としているかもしれない点である。
【０００８】
加えて、既存ＣＡＴＳ−ＯＳシステムは、所定量の技術と設備が顧客または他のユーザーのサイトで利用可能である必要がある。この技術と設備は、パーソナルコンピュータ（ＰＣ）およびデータの通信能力を含む。ＣＡＴＳ−ＯＳシステムの顧客または他の潜在的ユーザーの全てが、これら能力をインストールすることを望むわけではなく、代わりに、電話でトレーダーと直接会話してワラント取引を扱う方を好む。この好みは、小口取引が普通である顧客がトレーダーと直接会話する状況を回避することを意図したＣＡＴＳ−ＯＳシステムの目的と全く相反する。
【０００９】
更に、既存ＣＡＴＳ−ＯＳシステムは、単一の銀行用に、銀行の顧客および消費者に効果的な自動電子商取引ツールを提供するとはいえ、このシステムは一銀行だけの処理を表示する。この顧客は主としてブローカーであり、従って、銀行は、実際の顧客の身元を知らないことが多い。単に単一システムを扱っている間に、ブローカーが消費者に代わって他銀行のワラントを売買できるようにするために、例えば、複数の銀行がＣＡＴＳ−ＯＳシステムへ価格を付加することは現在のところできない。
【００１０】
【発明の概要】
本発明の特長と利点は、例えば、ホストバンクが課した限度を超えて、また相場が入手可能ではないかもしれない他の状況においても取引を完成させることができる自動商取引システムと自動商取引方法を提供することである。
【００１１】
本発明の更なる特長と利点は、トレーダーが、呼び値要求 (request for quote) に応答できて、ユーザーが取引き可能な提案価格を提供できる自動商取引システムと自動商取引方法を提供することである。
【００１２】
本発明の別の特長と利点は、販売トレーダーと称する、特殊なタイプのトレーダーが、特定のワラントの価格を必ずしも知らずに、そして選定顧客自身の価格を設定することなく、商取引システム内で選定顧客の代理として従事できるようにした自動商取引システムと自動商取引方法を提供することである。
【００１３】
本発明の追加の特長と利点は、システムの設置に伴なう出費をせずに、エラー率を減らせるなど、システムの全ての利点を与える自動商取引システムと自動商取引方法を提供することである。
【００１４】
本発明の別の特長と利点は、選定顧客が電話で取引きすることを可能にし、そのような顧客がそのシステムを設置しないで済む自動商取引システムと自動商取引方法を提供することである。
【００１５】
本発明の更なる特長と利点は、高給の専門トレーダーの出費もなくワラント取引を完全に行なえる自動商取引システムと自動商取引方法を提供することである。
【００１６】
本発明の追加の特長と利点は、ユーザーが、複数の銀行およびマーケットメーカーから容易にワラントを売買できるようにする自動商取引システムと自動商取引方法を提供することである。
【００１７】
本発明の更なる特長と利点は、電話をかけてシステムへアクセスする或る銀行のシステムのユーザーが、電話を切って他の銀行へリダイアルしなくてはならないという必要性を回避する自動商取引システムと自動商取引方法を提供することである。
【００１８】
本発明の別の特長と利点は、ユーザーが複数のシステムへ個別にログインしなくてはならないという必要性を回避する自動商取引システムと自動商取引方法を提供することである。
【００１９】
本発明の追加の特長と利点は、システムが株式取引所と見做されて規制される可能性のあるところまでシステムを統合してしまうことを回避する自動商取引システムと自動商取引方法を提供することである。
【００２０】
本発明の別の特長と利点は、価格形成者間の隔離を維持する自動商取引システムと自動商取引方法を提供することである。
【００２１】
上記の、そして他の特長、利点、および目的を達成するために、本発明の実施の形態は、呼び値要求局面、販売トレーダー局面、およびマルチバンク局面等、種々の局面を含むワラント取引きのための自動システムと方法を提供する。本発明の実施の形態のための方法とシステムは、例えば、トランザクションサーバー、相場サーバー、ハンドオフサーバー、クレジットサーバー、およびセキュリティサーバーのような、種々のサーバーを使用する。
【００２２】
本発明の実施の形態の呼び値要求局面は、特に、例えば、ユーザー端末、カテゴリートレーダー端末、トランザクションサーバー、相場サーバー、およびメールサーバーを使用する。本発明の実施の形態の販売トレーダー局面は、特に、例えば、１つ以上の販売トレーダー端末、トランザクションサーバー、クレジットサーバー、ハンドオフサーバー、およびクレジットサーバーを使用する。本発明の実施の形態でのマルチバンク局面は、特に、例えば、複数の独立して維持されて隔離された商取引システムのトランザクションサーバー、相場サーバー、およびハンドオフサーバーと共に、ユーザー端末を使用する。
【００２３】
本発明の実施の形態では、ワラント取引のような提案金融トランザクションに関するユーザーの要求は、ユーザー端末や販売トレーダー端末のような端末で受取られる。この要求を、ユーザーがユーザー端末で直接入力することにより、ユーザー端末で受取ることができる。代替として、要求は、例えば、ユーザーによる電話、ファックス、またはe - メールを介して販売トレーダーへ通信され、販売トレーダーがユーザーの要求を販売トレーダー端末に入力することにより、その販売トレーダー端末で受取られることになる。
【００２４】
他方、本発明の実施の形態において、要求は、端末へ結合されたトランザクションサーバーによりその端末から受取られるとともに、トランザクションサーバーへ結合された相場サーバーにより受取られる。マルチバンク局面において、要求は、端末へ結合された複数の独立して維持され隔離された取引システムの各トランザクションサーバーにより、そして各取引システムのトランザクションサーバーへ結合された対応の相場サーバーにより受取られる。
【００２５】
本発明の実施の形態において、相場呼び値 (rate quote) はシステムにより生成されるが、この相場呼び値は、提案された金融トランザクションに関する履行可能な相場呼び値またはカテゴリートレーダーの相場呼び値のいずれかから成る。履行可能な相場呼び値を生成するための予め定めた第１条件が、トランザクションサーバー、またはトランザクションサーバーに結合された相場サーバーにより識別されると、この履行可能な相場呼び値は、相場サーバーにより自動的に生成される。マルチバンク局面において、履行可能な相場呼び値を生成するための予め定めた第１条件が、特定の取引システムの相場サーバーまたはトランザクションサーバーのいずれかにより識別されると、この履行可能な相場呼び値は、特定の取引システムの対応トランザクションサーバーへ結合された複数の取引システムのうちの少なくとも１つのシステムの相場サーバーにより自動的に生成される。
【００２６】
本発明の実施の形態において、トランザクション相手当事者が取引き停止状態である；提案されたトランザクションシステムが停止状態である；提案されたトランザクション証券 (instrument) が取引停止状態である；提案されたトランザクション相場が停止状態である；提案されたトランザクションが利用可能量を超える；または、提案されたトランザクション額が予め定めた限度額を超える；というような提案トランザクションの拒絶の所定原因が、トランザクションサーバーでも相場サーバーでも識別されない場合、履行可能な相場呼び値を自動的に生成するための予め定めた第１条件が存在する。
【００２７】
本発明の実施の形態において、履行可能な相場呼び値を自動生成するための予め定めた第１条件が識別されない場合は、カテゴリートレーダーの相場呼び値を生成するための予め定めた第２条件が識別されれば、カテゴリートレーダーの相場呼び値が生成される。提案金融トランザクション拒絶の１つ以上の所定原因が、トランザクションサーバー、またはトランザクションサーバーに結合された相場サーバーのいずれかまたは両方により識別された場合、そして、拒絶の１つ以上の識別された原因に対応する呼び値要求パラメータの所定設定が、同様にトランザクションサーバーまたは相場サーバーのいずれかまたは両方により確認された場合、カテゴリートレーダーの相場呼び値を生成するための予め定めた第２条件が存在する。
【００２８】
本発明の実施の形態において、カテゴリートレーダーの相場呼び値を生成するための予め定めた第２条件が識別されれば、トランザクションサーバーは、カテゴリートレーダーの相場呼び値要求を自動生成し、その相場呼び値は、トランザクションサーバーによりメールサーバー経由で１つ以上のカテゴリートレーダーの端末へ自動的に通信される。１人以上のカテゴリートレーダーは、カテゴリートレーダー端末上の表示により、カテゴリートレーダーの相場呼び値の入力を促され、少なくとも１人のカテゴリートレーダーがカテゴリートレーダーの相場呼び値をカテゴリートレーダー端末で入力でき、それがトレーダー端末によりトランザクションサーバーへ通信される。
【００２９】
本発明の実施の形態において、トランザクションサーバーは、履行可能な相場呼び値またはカテゴリートレーダーの相場呼び値のいずれかをユーザー端末へ送り、または販売トレーダー局面では、ユーザーのために販売トレーダー端末へ送り、ここで相場呼び値はユーザーへ自動表示される。同時に、システムカウンタは自動的に所定期間が設定され、それは、生成された相場呼び値をユーザーのために所定期間保持し、実際に相場呼び値を所定期間ユーザーに保証する。
【００３０】
ユーザーのための提案トランザクションの履行要求がユーザー端末で（販売トレーダー局面では販売トレーダー端末で）所定期間内に受取られれば、履行要求は端末に結合されたトランザクションサーバーへ自動的に送られる。マルチバンク局面で、履行要求は複数の取引システムのうちの１つのシステムのトランザクションサーバーへ自動的に送られる。いずれの場合も、履行要求は、トランザクションサーバーに結合されたハンドオフサーバーへ自動的に引渡され (hand off)、このハンドオフサーバーはユーザーのために提案されたトランザクションを自動的に履行する。
【００３１】
本発明の追加の目的、利点、および新規の特長は、その一部が後に続く説明に記載され、また一部は以下を精査することにより、この技術に精通する者にはより明らかになるであろうし、あるいは本発明を実施して知ることができよう。
【００３２】
【詳細な説明】
添付図面に一実施例が示されている本発明の実施の形態を以下詳細に参照すると、本発明の実施の形態の呼び値要求局面は、ホストバンクが許容する取引限度を超え、そして相場が入手できないかもしれないその他の状況においても取引を完成させることができる、ワラント取引のための自動システムおよび方法を提供する。この機能を遂行するために、本発明の実施の形態は、トレーダーが呼び値要求に応答し、しかもユーザーが取引きできる提案価格を提供可能にする。本発明の実施の形態のシステムと方法は、呼び値要求の機能を遂行するが、既存ＣＡＴＳ−ＯＳシステムに関連して、この機能は、従来は行なえなかった。
【００３３】
図１は、本発明の実施の形態の呼び値要求局面の主要構成要素、および主要構成要素間の情報の流れの実施例概観を図解する概略図である。呼び値要求局面は、例えば、顧客ＧＵＩ２とトレーダーＧＵＩ４とを含むグラフィカルユーザーインタフェースを使用する。呼び値要求局面は、ワラントトランザクションサーバー（ＷＴＳ）６、ワラント相場サーバー（ＷＲＳ）８、およびメールサーバー（ＭＡＩ）１０も利用する。顧客ＧＵＩ２における顧客１２等のユーザーが、ＣＡＴＳ−ＯＳシステム内で通常の取引を進めようとしても、トランザクションの最大規模を超える等、既存ＣＡＴＳ−ＯＳシステムに特有の何らかの理由で取引きが妨げられる場合、呼び値要求局面が起動される。試みた取引に関するメッセージは、トレーダーＧＵＩ４においてトレーダー１４へ回される。トレーダー１４は取引についての情報を見て、それによりトレーダー１４が取引きを監視し、顧客の試みで用いた条件に基づいて提案価格を手入力できる。次いで、手入力された情報は顧客１２へ転送され、顧客は提案取引を受諾するか拒絶するかの機会を持つことになる。
【００３４】
このように、本発明の実施の形態に対する呼び値要求局面は、本質的に、顧客ＧＵＩ２における顧客１２と、トレーダーＧＵＩ４におけるトレーダー１４との間の電子的なメッセージの会話を含み、特定の状況の下での既存ＣＡＴＳ−ＯＳの拡張を提供するが、それら状況の基本となるひとつは、試みられた取引が、ホストバンクが建値で取扱いたいものよりも大きいという点である。この電子的メッセージングを遂行するために、本発明の実施の形態は、既存ＣＡＴＳ−ＯＳシステムのメッセージに追加メッセージング能力を提供する。詳細には、本発明の実施の形態は、顧客ＧＵＩ１２とトレーダーＧＵＩ４との間で直にメッセージを提供するためのシステムと方法とを含む。顧客ＧＵＩ２における顧客１２が、他には許可されていないであろう呼び値を出すことを希望する場合、トレーダーＧＵＩ４におけるトレーダー１４は、ポップアップメッセージを見て、次いでトレーダー１４は、例えば提案価格を入力することによってそれに応じる。
【００３５】
本発明の実施の形態のための呼び値要求局面は、トレーダー１４が責任を持つ全ての証券に対してトレーダー１４が取引価格を付けることができることにより、既存ＣＡＴＳ−ＯＳシステムの有用性を向上する。トレーダー１４は、拒絶されているワラントトランザクションを常に知らされており、トレーダー１４は、拒絶されたトランザクションを覆す (override) 力を与えられている。呼び値要求メカニズムは、ＣＡＴＳ−ＯＳシステムが自動的に履行可能な取引価格を付けることができない場合に有効である。また、特定の呼び値要求のトリガー (triggers) またはパラメータのために、他の場合は拒絶されるであろうトランザクションを履行するのにも有効である。他の場合は拒絶されるであろう全てのワラント取引トランザクションに対して、本発明の実施の形態は、トレーダー１４が、呼び値要求のトリガーを覆すことを可能にする。トレーダー１４は、上記の状況でも顧客１２へ取引価格を告げる能力を有する。これらの呼び値要求通知は、ワラントトランザクションで特定された証券に対して責任を持つトレーダーだけ配信される。
【００３６】
図２は、本発明の実施の形態の呼び値要求局面のための、カテゴリーメンテナンス画面のサンプル１６である。全ての証券 (instrument) はカテゴリーに属する。全てのカテゴリーに対して、いつ呼び値要求がトリガーされるべきかを示すパラメータが設定されている。これらのカテゴリーは、例えば、取引額の許容最大値の超過１８；取引量の利用可能量の超過２０；サニティ (sanity)、スプレッド(spread)、または時間切れ (time-out) のために相場が取引停止状態(suspended) ２２；証券の取引停止状態２４；相手当事者の取引停止状態２６；または、システムの停止状態２８；を含む。デフォルト設定は、全ての呼び値要求のトリガーのスイッチが付いている。新規カテゴリーが追加されると、ＧＵＩはデフォルト設定を表示する。トレーダー１４は、与えられたカテゴリーに対して、呼び値要求のトリガーのいずれかまたは全てのスイッチを消すことができる。従って、ワラントトランザクション毎に、ＷＴＳ６は、その証券カテゴリーに対する設定に基づいて呼び値要求をトリガーする。
【００３７】
本発明の実施の形態では、デフォルト設定は、いずれかまたは全ての呼び値要求のトリガー状況が生じた場合、ＷＴＳ６は呼び値要求をカテゴリートレーダーへトリガーする。呼び値要求となる全ての理由を示す。全ての呼び値要求（ＲＦＱ）トリガーパラメータのスイッチが、例えば、証券が停止状態２４であるようなひとつの場合を除いて、消されている場合、証券が停止される場合を除き、いずれのワラントトランザクションも、全てのトリガー状況で拒絶される。ＲＦＱトリガーがスイッチオンされていない場合、いずれのトリガー状況でも、ＷＴＳ６のトランザクションは拒絶される結果となる。証券を維持する特権を持つ全てのトレーダーおよびシステム管理者は、カテゴリーおよびＲＦＱトリガーパラメータを維持するアクセス権を自動的に有する。
【００３８】
図３は、本発明の実施の形態の呼び値要求局面のための、サンプルとしての取引入力画面３０を示す。顧客１２は、証券識別子３２および証券量３４を入力し、顧客がワラントの売り／買いのいずれを希望するのか指示する。ＧＵＩは、詳細を確認し、価格呼び値要求をＷＴＳ６へ送信する。トランザクション毎に、ＷＴＳ６はいずれかのＲＦＱパラメータのスイッチがオンになっているか否かをチェックする。ワラントトランザクションにおいて顧客１２により特定された証券に対して、ＷＴＳ６は、ＲＦＱパラメータをＷＲＳ８から得る。ＷＴＳ６は、相手当事者またはシステムが取引停止状態にあるか否かのチェック等、種々のチェックを行う。相手当事者の取引停止状態２６またはシステムの停止状態２８等の関連ＲＦＱパラメータが設定され、相手当事者またはシステムが取引き停止状態にある場合、ＷＴＳ６は、トランザクションに対して呼び値要求がなされていることを承認する。そうでなければ、顧客ＧＵＩ２の画面上に適切なメッセージを表示して、トランザクションを拒絶する。全てがうまくいけば、ＷＴＳ６は相場要求をＷＲＳ８へ送る。
【００３９】
本発明の実施の形態の呼び値要求局面では、ＷＲＳ８は、サニティ、スプレッド、または時間切れによる証券の取引停止状態、相場の取引停止状態等、種々のチェックを行なう。これらのいずれかが事実であり、証券の取引停止状態２４、または相場の取引停止状態２２等の関連ＲＦＱパラメータが設定されている場合、ＷＲＳ８は相場を見積ることができない。その後、ＷＲＳ８は、呼び値要求が必要であることを承認し、それに対する理由を与え、これらをＷＴＳ６へ送る。そうではなく、証券または相場が取引停止状態にあり、証券の取引停止状態２４または相場の取引停止状態２２等の関連ＲＦＱパラメータがスイッチオフである場合、トランザクションは拒絶され、ＧＵＩは画面上に適切なメッセージを表示する。既存ＣＡＴＳ−ＯＳシステムでは、顧客１２がワラントトランザクションを履行する時に、ＷＲＳ８は取引規模が利用可能量を超えるか否かをチェックする。しかし、本発明の実施の形態のための呼び値要求局面では、顧客１２が価格呼び値を要求する場合に、ＷＲＳ８はこのチェックを行う。ＷＲＳ８は、取引量が利用可能量を超えるか否かをチェックする。取引量が利用可能量より大きく、関連ＲＦＱパラメータ、即ち、利用可能量の超過２０が設定されている場合、ＷＲＳ８は、呼び値要求が必要であることを承認し、これがＷＴＳ６へ送信される。そうでなく、ＷＲＳ８が履行可能な相場を自動的に見積りできる場合、ＷＲＳ８は呼び値をＷＴＳ６へ送信する。
【００４０】
本発明の実施の形態の呼び値要求局面では、ＷＴＳ６は、[買いまたは売り相場x量]によって決定される取引額が、許容トランザクション最大限度を超えるか否かをチェックする。既存ＣＡＴＳ−ＯＳシステムでは、このチェックは、取引の履行時に行なわれる。本発明の実施の形態の呼び値要求局面では、これは、顧客１２が価格呼び値を要求する時に行なわれる。金額が最大限度額を超え、関連呼び値要求パラメータ、即ち、最大額の超過１８が設定されている場合、ＷＴＳ６は、呼び値要求が出されていることを承認する。そうでなければ、トランザクションは拒絶される。全てが良好で、ＷＲＳ８が履行可能な相場を見積る場合、履行可能な相場は、顧客１２が見るために顧客ＧＵＩ２へ送られる。顧客１２が、所定期間内に取引入力画面３０上の「買い」ボタン３６を押すことによって取引を履行すれば、取引は履行される。代替として、顧客１２は取引入力画面３０上の「取消」ボタン３８押すことができ、この場合にはトランザクションが削除される。時間切れが起きた場合、顧客１２は、取引入力画面３０上の「再要求」ボタン４０を押すことによって相場を再要求するか、または取引を取消すかのどちらかを行うことができる。取引を再要求すると、以前のトランザクションを削除し、新規取引をＷＴＳ６のトランザクションデータベースに入力することとなる。そうでなければ、トランザクションは未履行のまま残る。
【００４１】
本発明の実施の形態の呼び値要求局面では、呼び値要求が必要な場合、ＷＴＳ６は、そのための全ての理由を含めて顧客ＧＵＩ２へ通知する。顧客ＧＵＩ２は、「トレーダーからの応答待ち」等のメッセージを用いて顧客１２に通知する。ディーラー１４が提示した相場を受諾するか、取引相場を提供するまで、顧客１２は取引を履行できないので、「買い」ボタン３６は無効になる。「再要求」ボタン４０および「取消」ボタン３８は、顧客１２に対し相場の再要求またはトランザクションの削除を許可するよう有効となる。トレーダー１４からの応答を所定期間内に受取れない場合、呼び値要求は時間切れとなり、顧客ＧＵＩ２は、「申し訳ございません。トレーダーからの応答がありません」のようなメッセージを用いて顧客１２に通知する。
【００４２】
本発明の実施の形態の呼び値要求局面では、カテゴリートレーダー１４は、ＷＲＳ４により見積された相場の受諾、ディーラーの相場の見積り、またはトランザクションの拒絶により呼び値要求に応答できる。トレーダーの呼び値要求応答は、ＷＴＳ６により顧客ＧＵＩ２へ送信される。カテゴリートレーダー１４が呼び値要求を拒絶する場合、顧客ＧＵＩ２は、画面に表示された詳細が呼び値要求と同じであることを確認する。その場合、顧客ＧＵＩ２は、「ＲＦＱは拒絶されました」のようなメッセージを表示し、「再要求」ボタン４０および「取消」ボタン３８は、顧客１２に対し相場の再要求またはトランザクションの削除を許可するよう有効となる。カテゴリートレーダー１４が呼び値要求を受諾する場合、顧客ＧＵＩ２は、呼び値要求に対するトレーダーの応答が、画面上に表示されたトランザクションの詳細と合致することを確認する。その場合、次いで顧客ＧＵＩ２は、ディーラーの相場を表示し、顧客の応答を待つ。顧客１２は、「取消」ボタン３８を押すことによって取引相場を拒絶でき、この場合、トランザクションはＷＴＳ６のトランザクションデータベースから削除される。顧客１２は「買い」ボタン３６を押すことによってディーラーの相場を受諾でき、その後トランザクションが履行される。
【００４３】
図４は、本発明の実施の形態の呼び値要求局面のための、サンプルのメッセージボックス４４を示す。呼び値請求トリガーが生ずると、ＷＴＳ６は、ＭＡＩ１０へ通知メッセージを送信する。ＭＡＩ１０は、次いで、オンラインカテゴリートレーダーへ呼び値要求を警告するメッセージを送信する。カテゴリートレーダーは、呼び値要求メッセージボックス４４内またはメールを読む時に、これらのシステムが生成したメッセージを見ることができる。しかし、１人のカテゴリートレーダーもログオンしていない場合、ＭＡＩ１０は、デフォルトトレーダーカテゴリーに属する全てのトレーダーへ、呼び値要求メッセージを送る。デフォルトカテゴリートレーダーは、呼び値要求メッセージボックス４４内または次回にメールを読む時に、呼び値要求メッセージを見ることができる。
【００４４】
本発明の実施の形態の呼び値要求局面では、呼び値要求がトリガーされる度に、同じカテゴリー内のトレーダーがログオンしていると、トレーダー１４は、「入力メッセージ： １０：４７：５２ ＊８１５７２５ 相場呼び値要求」等の、時間、テキスト、およびシステム名を持つ入力メッセージを知らせるトレーダーＧＵＩ４画面上のステータスバー内のメッセージによって通知される。１人のカテゴリートレーダーもログオンしていない場合、ログオンしているデフォルトカテゴリートレーダー構成員がメッセージを受取る。トレーダー１４は、呼び値要求メッセージボックス４４からメッセージを選択することができ、ダブルクリックして、相場呼び値を待っているワラントトランザクションのためにディーラー相場を提供する。次いで、現在のトランザクション詳細が画面に現れる。一旦ディーラー１４がトランザクションを受諾または拒絶すると、メールメッセージは呼び値要求メッセージボックス４４に追加され、カテゴリートレーダーに呼び値要求状態の変更を通知する。加えて、トレーダーＧＵＩ４は、ステータスバーにメッセージを表示して、「入力メッセージ： １０：４７：５２ ＊８１５７２５ 相場呼び値要求受諾」または「入力メッセージ： １０：４７：５２ ＊８１５７２５ 相場呼び値要求拒絶」等の、時間、テキスト、およびシステム名を持つ入力メッセージをカテゴリートレーダーに警告する。１人のカテゴリートレーダーもログオンしていない場合、ログオンしているデフォルトカテゴリートレーダー構成員がメッセージを受取る。
【００４５】
図５は、本発明の実施の形態の呼び値要求局面のための、サンプル売買詳細画面４６を示す。呼び値要求が選択される場合、トレーダーＧＵＩ４は、トランザクション詳細をＷＴＳ６から得る。顧客１２がトレーダーの応答を待たないことに決めて取引を取消したかもしれないので、トランザクションは存在しないかもしれない。この場合には、トレーダーＧＵＩ４は、「申し訳ございません。相場要求はキャンセルされました」のようなメッセージを表示する。そうでなければ、トランザクション詳細は、呼び値要求に対する理由を含めて、売買詳細画面４６上に表示される。トレーダー１４は、ＷＲＳ８により見積りされたいずれかの相場を受諾するか、ディーラーの相場を入力する、またはトランザクションを拒絶することができる。ディーラー１４が、売買詳細画面４６上の「受諾」ボタン４８を押すと、ＷＴＳ６のトランザクションデータベースでの呼び値要求状態が、それに応じて更新される。同様に、ディーラー１４が、売買詳細画面４６上の「拒絶」ボタン５０を押すと、呼び値要求状態が更新される。結果は、トレーダーＧＵＩ１４からＷＴＳ６へ送信され、結果は、顧客ＧＵＩ２上の顧客１２へ送られる。ＷＴＳ６はまた、更新された呼び値要求状態を、ＭＡＩ１０経由で全てのオンラインカテゴリートレーダーへ中継する。トレーダー１４が呼び値要求を拒絶すると、顧客ＧＵＩ２は、拒否メッセージを表示し、取引入力画面３０上の「再要求」ボタン４０および「取消」ボタン３８を有効にする。トレーダー１４が呼び値要求を受諾すると、顧客ＧＵＩ２はディーラー相場を表示する。顧客１２は、「取消」ボタン３８を押すことによって取引相場を拒絶するか、または「買い」ボタン３６を押すことによって取引相場を受諾することができ、トランザクションが履行される。
【００４６】
図６は、本発明の実施の形態の呼び値要求局面において、顧客１２が相場を要求するプロセスの一実施例を説明するフローチャートである。Ｓ１において、顧客１２が、顧客ＧＵＩ２にログオンし、証券識別子３２、量３４を入力し、買いか売りか３６を指示する。Ｓ２において、顧客ＧＵＩ２が、詳細を確認し、相場要求をＷＴＳ６へ送信する。Ｓ３では、ＷＴＳ６が、相場要求を受取り、相手当事者またはシステムが取引停止状態にあるか否かをチェックする。そうでない場合、ＷＴＳ６は相場要求をＷＲＳ８へ送る。相手当事者またはシステムが取引停止状態にある場合、ＷＴＳ６は、関連ＲＦＱパラメータ２６、２８が設定されているかどうかをチェックする。されていない場合、ＷＴＳ６は、顧客ＧＵＩ２へ拒絶メッセージを送信する。関連ＲＦＱパラメータ２６、２８が設定されている場合、ＷＴＳ６は相場要求をＷＲＳ８へ送信する。
【００４７】
更に図６を参照すると、Ｓ４において、ＷＲＳ８が、相場要求を受取り、証券または相場が取引停止状態にあるか否かをチェックする。そうでない場合、ＷＲＳ８が、取引規模が利用可能量を超えるか否かをチェックする。証券または相場が取引停止状態にある場合、ＷＲＳ８が、関連ＲＦＱパラメータ２４、２２が設定されているかどうかをチェックする。されていない場合、ＷＲＳ８が、拒絶メッセージを顧客ＧＵＩ２のためにＷＴＳ６へ送信する。関連ＲＦＱパラメータ２４、２２が設定されている場合、ＷＲＳ８は、取引規模が利用可能量を超えるか否かをチェックする。取引規模が利用可能量を超えない場合、ＷＲＳ８は、履行可能な相場をＷＴＳ６へ送信する。取引規模が利用可能量を超える場合、ＷＲＳ８は関連ＲＦＱパラメータ２０が設定されているかどうかをチェックする。されていない場合、ＷＲＳ８は、拒絶メッセージを顧客ＧＵＩ２のためにＷＴＳ６へ送信する。関連ＲＦＱパラメータ２０が設定されている場合、ＷＲＳ８は、ＲＦＱメッセージをＷＴＳ６へ送信する。Ｓ５において、ＷＴＳ６が、履行可能な相場をＷＲＳ８から受取り、取引額がトランザクション限度を超えるか否かをチェックする。超えない場合、ＷＴＳ６は、履行可能な相場を顧客ＧＵＩ２へ送信する。取引額がトランザクション限度を超える場合、ＷＴＳ６は、関連ＲＦＱパラメータ１８が設定されているかどうかをチェックする。そうでない場合、ＷＴＳ６は、拒絶メッセージを顧客ＧＵＩ２へ送信する。関連ＲＦＱパラメータ１８が設定されている場合、ＷＴＳは、呼び値要求が必要であると判定する。
【００４８】
図７は、本発明の実施の形態の呼び値要求局面のための呼び値要求の通知プロセスの例を説明するフローチャートである。Ｓ６において、ＷＴＳ６は、ＷＲＳ８から呼び値要求メッセージを受取るか、または呼び値要求が必要かを決定し、ＲＦＱメッセージを顧客ＧＵＩ２へ、そしてＲＦＱ通知をＭＡＩ６へ送信する。Ｓ７において、顧客ＧＵＩ２は、ＲＦＱメッセージをＷＴＳ６から受取り、「買い」ボタン３６をディスエーブル化し、「再要求」ボタン４０および「取消」ボタン３８をイネーブル化し、ＲＦＱタイマーをセットする。Ｓ８では、ＭＡＩ１０が、ＲＦＱ通知をＷＴＳ６から受取り、ＲＦＱ通知をトレーダーＧＵＩ４へ送信する。Ｓ９では、トレーダーＧＵＩ４が、ＲＦＱメッセージを呼び値要求メッセージ画面４４上に表示する。Ｓ１０では、トレーダー１４が、メッセージ画面４４からの呼び値要求メッセージの選択を入力する。Ｓ１１において、トレーダーＧＵＩ４は、トランザクション詳細をＷＴＳ６から得て、詳細をトランザクション詳細画面４６上に表示する。
【００４９】
更に図７を参照すると、Ｓ１２において、トレーダー１４は、トランザクション詳細画面４６上で、「受諾」ボタン４８を押すことによって受諾を入力するか、または「拒絶」ボタン５０を押すことによって拒絶を入力する。Ｓ１３では、トレーダーＧＵＩ４は、トレーダーの受諾または拒絶をＷＴＳ６へ送信する。Ｓ１４では、ＷＴＳ６は、トレーダーの受諾または拒絶を顧客ＧＵＩ２へ送信し、ＷＴＳトランザクションデータベースの呼び値要求状態を更新し、更新された状態をＭＡＩ１０経由で全てのオンラインカテゴリートレーダーへ中継する。Ｓ１５において、顧客ＧＵＩ２は、トレーダーの受諾または拒絶を受取る。拒絶の場合、顧客ＧＵＩ２は、顧客１２のために拒否メッセージを表示する。受諾の場合、顧客ＧＵＩ２は、顧客１２のためにトレーダーの相場を表示する。Ｓ１６において、顧客１２は、トレーダーの相場の表示を見て、取引入力画面３０上で「取消」ボタン３８を押すことによって顧客の拒絶を入力する。代替として、顧客１２がトレーダーの相場を受諾したい場合、そして呼び値要求が時間切れしていない場合、顧客１２は、「買い」ボタン３６を押すことによってトレーダーの相場の顧客の受諾を入力し、トランザクションは履行される。
【００５０】
本発明の実施の形態のための別の局面は、販売トレーダーの特長であり、それは、販売トレーダーと称する特殊なトレーダーが、ＣＡＴＳ−ＯＳシステム内の選定された顧客の代理として取引することができる、ワラント取引のために自動化されたシステムと方法を提供する。図８は、本発明の実施の形態に対する販売トレーダー局面での、主要構成要素、および主要構成要素間の情報の流れの実施例概観を図解する概略図である。本発明の実施の形態のための販売トレーダー局面は、例えば、ひとつ以上の販売トレーダーＧＵＩ１０２、１０４、ワラントトランザクションサーバー（ＷＴＳ）６、ワラント相場サーバー（ＷＲＳ）８、と共にクレジットサーバー（ＣＲＳ）１０６、ワラントハンドオフサーバー（ＷＨＯ）１０８、およびダイレクトディーラーインタフェース（ＤＤＩ）１１０を使用する。販売トレーダー局面では、特定ワラントの価格を知っている必要もなく、そして自己の価格を設定することなく、任意数の販売トレーダー１１２、１１４が、この機能を実行する。必須ではないが、１人以上のそれら販売トレーダー１１２、１１４が、本人のトレーディングルーム近くの、販売トレーダーＧＵＩ１０２、１０４等のＣＡＴＳ−ＯＳシステム端末にいるのが普通である。販売トレーダー１１２、１１４は、顧客の取引を行うために、顧客１１６等の顧客から電話１１８または他の通信装置で呼出しを受け取る。
【００５１】
本発明の実施の形態の販売トレーダー局面の利点は、ＣＡＴＳ−ＯＳシステムの全ての設備が利用でき、正確に設定された価格、正しく集められた情報、および信用限度額設定等、取引を進めるための他の要件を含め、顧客を完全に満足させることである。加えて、この販売トレーダー局面は、ＣＡＴＳ−ＯＳシステムによって達成されるエラー率減少の利点を、全てのＣＡＴＳ−ＯＳシステム要件をインストールしなければならないという不利な点もなく、インストールは望まないが電話１１８により取引を続けたいと願う顧客に対しても提供する。従って、販売トレーダー局面は、高給の専門トレーダーまたは銀行間トレーダーの費用無しにワラント取引の全資格を提供する。販売トレーダー局面はまた、電話１１８による取引および顧客口座アクセスによる取引に関する専門化した特長も含んでいる。販売トレーダー局面では、販売トレーダー１１２、１１４は、ユーザー口座へのアクセス権を持っている。本実施の形態では、販売トレーダー１１２、１１４は、通常のＣＡＴＳ−ＯＳシステムユーザーが持っている全ての資格へのアクセス権は持っていないが、システムは、販売トレーダー１１２、１１４に、それらが代理となって行動する顧客１１６等の顧客を選択し、ワラント取引を行なうのに必要な所定機能を実行する資格を提供する。
【００５２】
本発明の実施の形態の販売トレーダー局面では、販売トレーダー１１２、１１４がログインする時、名前およびパスワード情報の入力によって、販売トレーダー１１２、１１４が多数のユーザーに代わって安全な方法で取引することを可能にする。販売トレーダー局面は、ユーザーが顧客の代理としてＣＡＴＳ−ＯＳシステムで取引することを可能にし、例えば、既存ＣＡＴＳ−ＯＳシステムのＧＵＩおよびサーバーを使用して、ＣＡＴＳ−ＯＳシステムを介して行なわれるワラントトランザクション数を増加させる。販売トレーダー局面は、これを顧客１１６等の顧客と電話１１８で行なわれるワラントトランザクションを含めることによって可能にしている。この新しい種類のユーザーは、顧客の代理としてＣＡＴＳ−ＯＳシステムでトランザクションを入力できる。
【００５３】
既存ＣＡＴＳ−ＯＳシステムは、ＤＤＩ１１０へ自動取引渡し (hand off) を提供するので、本発明の実施の形態のための販売トレーダー局面の利点は、例えば、間違った相場が、トレーダーによって誤ってシステム内で見積られるかまたは入力されることを著しく減少させることを含む。現在、多くの電話上取引が不一致となって、介在する事務所により調製されねばならなくなっている。本発明の実施の形態のための販売トレーダー局面の別の利点は、手作業および手書伝票を回避することであり、従って、トレーダーの時間を節約する。販売トレーダー局面の更なる利点は、ＣＡＴＳ−ＯＳシステムのＧＵＩソフトウエアアプリケーションを、顧客サイトでインストールする必要がないことである。というのは、販売トレーダー１１２、１１４等の販売トレーダーが、顧客の代理としてトランザクションを入力して、それを見ることができるからである。
【００５４】
図９は、本発明の実施の形態の販売トレーダー局面のデータベースの一実施例概観を図解する概略図である。販売トレーダー局面は、例えば、「機関」テーブル１１８、「支店」テーブル１２０、「ユーザー」テーブル１２２、および「顧客」テーブル１２４を含む。販売トレーダー局面では、ＣＡＴＳ−ＯＳシステムではない銀行の相手当事者詳細は、ＣＡＴＳ−ＯＳシステムの「支店」テーブル１２０へ手入力される。加えて、取引関係とクレジット限度額 (credit limits)は、関係およびクレジット限度額メンテナンス画面から手作業でメンテナンスされる。既存顧客のＧＵＩ取引メカニズムは変更されない。ＤＤＩ１１０は、顧客識別子および決済指示等の、追加フィールドを、既存ＣＡＴＳ−ＯＳシステムのＤＤＩインタフェーステーブルおよび替為フィード（Exchange Feed）テーブルに格納する。顧客リストは、テキストファイルからＣＡＴＳ−ＯＳシステムデータベースへアップロードされる。その後、ＣＡＴＳ−ＯＳシステムの「顧客」テーブル１２４は、システム管理者により手作業でメンテナンスされる。販売トレーダー１１２、１１４等の販売トレーダーは、価格を交渉したり、または削除されたトランザクション最大量を覆す権利は持っていない。この権利は、呼び値要求を待っている未処理のトランザクションに応答することができるトレーダーが利用できる。
【００５５】
本発明の実施の形態のための販売トレーダー局面は、数多くのサーバーを利用する。ＷＴＳ６が、ＣＡＴＳ−ＯＳシステムの活動を調整する。ＷＴＳ６は、ユーザーのプロフィール、トランザクション、および関係を記憶しているデータベースを含む。ＷＲＳ８は、ロイター価格フィード（ Reuters price feed ）等の、価格フィードから入力を受取り、メモリ内テーブルを最新相場で更新する。ＷＲＳ８は、量およびワラント証券詳細を記憶し、更新する。ＣＲＳ１０６は、各支店に対するクレジットを維持する。クレジットは、トランザクションが履行される毎に引出される。ＷＨＯ１０８は、完了したトランザクションを受取り、それらを取引キャプチャ（ deal capture ）およびポジション保持（ position-keeping ）システムまたはＤＤＩ１１０へ引渡す。
【００５６】
本発明の実施の形態のための販売トレーダー局面では、顧客１１６は、グローバルコンシューマバンク（ global consumer bank ）等のホストリテール銀行支店（ host retail bank branch ）に口座を持つ個人である。代替として、顧客１１６は、ＣＡＴＳ−ＯＳシステムを使用して、ホストバンクの支店に対してワラントトランザクションを履行する企業体（ corporate entity ）または銀行のファンドマネージャまたはブローカーである。顧客１１６は、「ユーザー」テーブル１２２内で「顧客」というユーザータイプと識別子としてのユーザーＩＤを用いて設定される。トレーダー１１２等のトレーダーは、ホストバンクの支店における企業ワラントディーラーである。トレーダー１１２等のトレーダーは、現地通貨で価格を作成し、売買限度を設定し、トランザクションから生じるポジションをカバーする責任を負う。トレーダー１１２等のトレーダーは、「ユーザー」テーブル１２２内で「トレーダー」としてのユーザタイプで、固有識別子またはユーザーＩＤを用いて設定される。相手当事者は、ＣＡＴＳ−ＯＳシステムを使用して、ホストバンクの支店に対しワラントトランザクションを履行する企業体、銀行、または金融機関である。相手当事者は、「支店」テーブル１２０内に固有識別子または支店ＩＤを用いて設定される。
【００５７】
本発明の実施の形態のための販売トレーダー局面では、トレーダー１１２のような販売トレーダーは、ＣＡＴＳ−ＯＳシステムの新しい種類のユーザーである。例えば、販売トレーダー１１２は、電話１１８上で、例えば、ホストバンクの相手当事者と取引するホストバンクの従業員かまたはホストバンクのブローカーである。販売トレーダー１１２は、ＣＡＴＳ−ＯＳシステムの顧客１１６の代理としてトランザクションを入力して見ることができる。顧客１１６自身もＣＡＴＳ−ＯＳシステムへログインできる。顧客１１６は、そこで、ユーザープロフィルメンテナンス画面からＣＡＴＳ−ＯＳシステムのユーザーとして手作業で追加され得る。組織は、ＣＡＴＳ−ＯＳシステムでは「機関」として分類される。機関は、「機関」テーブル１１８内で固有識別子または機関ＩＤを用いて記憶される。例えば、「The Acme Company」という会社は、「ACMEINST」とされる機関ＩＤを用いて設定される。支店は、「支店」テーブル１２０内に支店ＩＤとともに保持される銀行の支店または企業の支店の一例である。ロンドン、フランクフルト、東京に支店を持つ The Acme Company は、ＣＡＴＳ−ＯＳシステムに設定された、例えば、「LONACME」、「FFTACME」、「TOKACME」支店を持つ。
【００５８】
本発明の実施の形態のための販売トレーダー局面では、関係は、取引支店が他の全てのホストバンクの相手当事者との取引関係を説明する。関連する２つの支店間に取引関係が存在する限り、販売トレーダー１１２等の取引支店の販売トレーダーは、相手当事者または相手当事者のリテール客の何れかが存在する場合、その代理として取引できる。従って、販売トレーダーは、相手当事者顧客の部分集合(subset)の代理として取引することに限定されない。図１０は、本発明の実施の形態の販売トレーダー局面のための図９に示すデータベースのサンプル概観に関する更なる詳細を提供する拡大概略図である。既存ＣＡＴＳ−ＯＳシステムの取引メカニズムによれば、全てのワラントトランザクションは、銀行間で行われる。例えば、顧客１１６のようなリテール客またはグローバルコンシューマバンクの代理として取引する日本のホストバンクの販売トレーダー１１２のような販売トレーダーは、例えば「CITIJPY」と「CITIGCB」間で取引を行うこととなる。
【００５９】
本発明の実施の形態のための販売トレーダー局面では、販売トレーダートランザクションは、ワラントの価格が有効である自己の時間切れ期間を有する。この時間切れ期間は、販売トレーダー１１２の支店に対する「支店」テーブル１２０でメンテナンスされる。この時間切れ期間は、例えば、通常の価格時間切れ期間より長い。これは、買売価格が顧客１１６へ電話１１８で告げられる時間と、顧客１１６が、トランザクション量と顧客１１６の希望が買いか売りかを述べる時間との間に遅延時間があるためである。ワラント価格がその間に更新される可能性もある。販売トレーダーの時間切れ期間が有効である限り、トランザクションは、依然、見積された買売価格で履行される。
【００６０】
図１１、１２、１３、１４、１５は、本発明の実施の形態の販売トレーダー局面のための、サンプルとしての取引入力画面１３０、サンプルのトランザクション画面１３２、支店メンテナンス画面１３４、サンプルの顧客メンテナンス画面１３６、およびサンプルの取引詳細画面１３８をそれぞれ図示する。ＧＵＩ１０２およびＷＴＳ６は、販売トレーダートランザクションが新規の時間切れ期間内に履行されることを確認する。そうでない場合、ＧＵＩ１０２は、時間切れメッセージを表示して、取引入力画面１３０から「買い」ボタン１４０および「売り」ボタン１４２をディスエーブル化する。販売トレーダー１１２は、その後、取引入力画面１３０上で、「再要求」ボタン１４４を押すことによって価格呼び値を再要求するか、または「取消」ボタン１４６を押すことによりトランザクションを取消することができる。販売トレーダー１１２がＣＡＴＳ−ＯＳシステム内でワラントトランザクションを入力する場合、販売トレーダー１１２は、取引支店のブローカーとして入力する。換言すれば、顧客１１６が、「Ｘワラントを買いたい」と言う場合、販売トレーダー１１２は、取引入力画面１３０上の「売り」ボタン１４２を押すことによって「売り」を入力する。同様に、顧客１１６が「Ｘワラントを売りたい」と言う場合、販売トレーダー１１２は、取引入力画面１３０上の「買い」ボタン１４０を押すことによって「買い」を入力する。
【００６１】
本発明の実施の形態の販売トレーダー局面では、顧客１１６が、販売トレーダー１１２へ電話し、ワラントトランザクションを行うことを要求する場合、販売トレーダー１１２は、販売トレーダーＧＵＩ１０２においてＣＡＴＳ−ＯＳシステムへログインする。トランザクション画面１３２は、自動的にユーザー１１２へ表示される。トランザクション画面１３２は、ＣＡＴＳ−ＯＳシステムの顧客へ通常示されるものよりも詳細である。販売トレーダー１１２は、ワラント証券取引番号（ＳＥ Ｎｏ．）１４８を入力する。販売トレーダー１１２は、次いで、ｋＶ番号１５０またはデポ(depot)番号１５２を知っていれば入力する。ｋＶ番号は、ドイツ証券取引所(German stock exchange)で取引する銀行または金融機関へ与えられる。ｋＶ番号を持つものは、ドイツ清算システム(German clearing system)を介して貸借勘定を決済する。デポ番号を持つものはドイツ以外の銀行または金融機関であり、直接決済する。ＧＵＩ１０２は、ｋＶ番号１５０の入力を初期設定する。ｋＶ番号１５０またはデポ番号１５２は、国内外の銀行承認の相手当事者を識別する。
【００６２】
代替として、本発明の実施の形態のための販売トレーダー局面では、販売トレーダーは、相手当事者の支店名１５４を入力できる。販売トレーダー１１２は、ｘ文字（最大８文字）で始まる支店名のリストを要求できる。販売トレーダー１１２が検索文字列(search string)を入力し、支店メンテナンス画面１３４上で「検索」ボタン１５６を押す場合、ＧＵＩ１０２は、或る検索条件が入力されたことを確認する。ＷＴＳ６は、「支店」テーブル１２０をチェックして、支店名の最初の数文字が検索条件に一致するかどうかを見る。一致する支店名が見つかった場合、ＷＴＳ６は、一致した全数の支店ＩＤと名前を送り返す。１００件を超えた一致する支店ＩＤがある場合、ＷＴＳ６はいずれの支店詳細も送り返さずに、「ＸＸＸ件の一致する支店名が見つかりました。検索条件を再入力して下さい」等のメッセージが表示される。ひとつも見つからない場合、「該当はありません；検索条件を再入力して下さい」等のメッセージが表示される。
【００６３】
本発明の実施の形態のための販売トレーダー局面では、リテール銀行顧客の代理として取引するために、販売トレーダー１１２は、顧客ＩＤ１５８を知っていれば入力する。そうでなければ、販売トレーダー１１２は、ｘ文字（最大８文字）で始まる顧客名を要求できる。販売トレーダー１１２が検索文字列を入力し、顧客メンテナンス画面１３６上で「検索」ボタン１６０を押せば、ＧＵＩ１０２が、或る検索条件が入力されたことを確認する。ＷＴＳ６は、「顧客」テーブル１２４をチェックして、顧客名の最初の数文字が検索条件に一致するかを見る。一致する顧客名が見つかれば、ＷＴＳ６は、一致する全数の顧客ＩＤと名前を送り返す。１００件を超えた一致する顧客ＩＤがある場合、ＷＴＳはいずれの顧客詳細も送り返さずに、「ＸＸＸ件の一致する顧客名が見つかりました。検索条件を再入力して下さい」等のメッセージが表示される。ひとつも見つからない場合、「該当はありません；検索条件を再入力して下さい」等のメッセージが表示される。
【００６４】
本発明の実施の形態の販売トレーダー局面では、販売トレーダー１１２は、顧客１１６が買売したい量を知らない。ＣＡＴＳ−ＯＳシステムが買売価格を見積もると、顧客１１６は、量と、買いか売りかを決定する。販売トレーダー１１２は、トランザクション画面１３２上の「価格の取得」ボタン１６２を押すことにより価格呼び値を要求できる。ＧＵＩ１０２は、ｋＶまたはデポ番号が入力されたことを確認する。さもなければ、「ｋＶ／デポ番号、または相手当事者名を入力して下さい」等のメッセージが表示され、販売トレーダー１１２は再入力を促される。次いでＷＴＳ６は、入力されたｋＶまたはデポ番号を確認する。特定された相手当事者が存在しない場合、システム管理者は、手作業で、この支店、取引支店との取引関係、およびＣＡＴＳ−ＯＳシステムでの信用限度額を入力しなくてはならず、「無効の支店」等のメッセージが表示されることになる。顧客ＩＤが入力されれば、ＷＴＳ６は、「顧客」テーブル１２４にそれが存在することを確認する。存在しない場合、「無効の顧客」等のメッセージが表示されることになる。システム管理者は、顧客メンテナンス画面１３６で顧客詳細を手入力しなくてはならない。首尾良く確認されると、ＷＲＳ８は、販売トレーダーのトランザクションのための買いと売りの両方の価格である２方向の価格呼び値を生成する。トランザクションを履行する前に、販売トレーダー１１２は量を入力しなくてはならない。入力しない場合、ＧＵＩ１０２が、販売トレーダー１１２に量フィールドへの再入力を促す。顧客１１６が新規の時間切れ期間内に、見積られた相場をひとたび受諾すると、販売トレーダー１１２は、取引入力画面１３０上で、「買い」ボタン１４０または「売り」ボタン１４２を押してトランザクションを履行する。
【００６５】
本発明の実施の形態のための販売トレーダー局面では、ＣＡＴＳ−ＯＳシステムが価格を見積ることができずに、関連する呼び値要求（ＲＦＱ）パラメータがスイッチオンされている場合、ＷＴＳ６および／またはＷＲＳ８は、ログインされている関連カテゴリートレーダーへＲＦＱをトリガーする。ＧＵＩは、ＲＦＱに対する理由を示すメッセージを表示する。次いで、販売トレーダー１１２は、トレーダーがＲＦＱに応答して価格を見積る間は待機する。さもなければ、販売トレーダー１１２は、価格を再要求するか、またはトランザクションを取消すことができる。ＷＴＳ６とＷＲＳ８は、取引額がトランザクション最大限度額を超えるか否か、そして取引量が利用可能量を超えるか否かを判定するようチェックを行なう。超えるようであってかつ関連ＲＦＱパラメータがスイッチオンされている場合、ＲＦＱがトリガーされる。ＧＵＩは、ＲＦＱに対する理由を示すメッセージを表示する。次いで、販売トレーダー１１２はトレーダーがＲＦＱに応答して価格を見積るのを待つ。そうでなければ、販売トレーダー１１２は、価格を再要求するか、またはトランザクションを取消すことができる。販売トレーダー１１２が、トランザクションを履行または取消す場合、販売トレーダーの支店信用限度は、それに応じて更新される。
【００６６】
本発明の実施の形態の販売トレーダー局面で、販売トレーダー１１２は顧客メンテナンス画面１３６を見る。顧客参照フィールドで、販売トレーダー１１２は、相手当事者の従業員名を入力する。顧客参照フィールドは、トランザクションおよび報告書を見るのに使用できる。履行できた場合、ＷＴＳ６は、トランザクションテーブル上の量を更新する。次いで、トランザクションはＤＤＩ１１０へ自動的に渡される。例えば、ＤＤＩ１１０へ引渡された全ての日本の販売トレーダーのワラントトランザクション毎に、ＷＨＯ１０８は追加フィールドをＤＤＩ１１０へ送る。これらは、リテール客の銀行口座番号のような、顧客ＩＤ１６４およびリテール客の名前１６６である。顧客ＩＤ１６４および名前１６６フィールドは、リテール銀行顧客とのトランザクションに対して有効である。つまり、そうでなければ、このフィールドは空白である。リテール客の決済指示、つまり、顧客ＩＤ１６４と名前１６６は、例えば、日本のバックオフィスの決済操作のために、必須のフィールドと見做される。ＷＴＳ６は、顧客ＩＤと名前をトランザクション毎にＷＨＯ１０８へ引渡す。ＷＨＯ１０８は、例えば、日本のトランザクションのために追加の２つのフィールドを引渡すだけである。
【００６７】
本発明の実施の形態の販売トレーダー局面において、例えば、ドイツ決済会社 clearing house を通して決済しない銀行または金融機関については、ワラントトランザクション金額は、取引銀行または金融機関と、相手当事者の銀行または金融機関との間で直接決済される。この決済は、支店＋所在地＋口座番号等のデポ番号を使用して行なわれる。決済会社を通すドイツの銀行または金融機関は、例えば、ＤＤＩ１１０のドイツ株式取引所番号つまりｋＶ番号を用いて決済する。リテール銀行顧客とのワラントトランザクションに関して、それらの勘定は、例えば、バックオフィスの決済システムにより決済される。
【００６８】
本発明の実施の形態において、販売トレーダーのトランザクションに関し、取引票 （deal tickets） は、販売トレーダーのユーザーＩＤと相手当事者顧客ＩＤを示す。取引伝票の「入力者」フィールドは、販売トレーダーのユーザーＩＤである。ＷＴＳ６は、顧客のＩＤや顧客名等の追加フィールドを持つ取引伝票を生成する。これらは、リテール銀行顧客に代わって履行された販売トレーダーのトランザクションに対してのみ有効である。そうでなければ、これらのフィールドは空白である。販売トレーダーのトランザクションに関して、トランザクション報告書は、販売トレーダーのユーザーＩＤと相手当事者の顧客ＩＤを示す。トランザクション報告書の「入力者」フィールド１６８は、販売トレーダーのユーザーＩＤである。ＷＴＳ６は、顧客のＩＤやリテール客の決済指示等の追加フィールドを持つトランザクション報告書を生成する。これらは、リテール銀行顧客に代わって履行された販売トレーダーのトランザクションに対してのみ有効である。そうでなければ、これらフィールドは空白である。
【００６９】
本発明の実施の形態の販売トレーダー局面において、販売トレーダーのトランザクションにとっては、２方向の価格呼び値が必要である。販売トレーダー１１２がトランザクションを入力し、ＣＡＴＳ−ＯＳシステムが価格を見積もれない場合、ＲＦＱパラメータがスイッチオンされていれば、ＲＦＱがトリガーされる。換言すれば、カテゴリートレーダーが、ＲＦＱに応答して、２方向価格を見積ることが見込まれる。相場、証券、相手当事者、またはシステムが停止状態にある場合、または、取引額がトランザクション最大限度額を超えるか、取引量が利用可能量を超える場合、ＲＦＱがトリガーされる。量と、買い／売りのフィールドは、販売トレーダーのトランザクションについては空白でよい。ＧＵＩとＷＴＳ６は、トレーダーが、販売トレーダーのトランザクションに対して新たな時間切れ期間内に応答することを確保する。
【００７０】
図１６は、本発明の実施の形態の販売トレーダー局面のための、販売トレーダーのトランザクションのサンプルを図解するフローチャートである。Ｓ１０１では、顧客１１６が電話１１８で販売トレーダー１１２に接触し、ワラントトランザクションを要求する。Ｓ１０２では、販売トレーダー１１２が、販売トレーダーＧＵＩ１０２でログインし、販売トレーダーの名前とパスワード情報を入力して、顧客のワラントトランザクション情報を入力し、価格呼び値要求のために「価格を得る」ボタン１６２を押す。Ｓ１０３では、販売トレーダーＧＵＩ１０４が、価格呼び値要求をＷＴＳ６へ送る。Ｓ１０４では、ＷＴＳ６が、入力された情報を確認して、ＲＦＱパラメータをチェックし、設定されていれば、ＲＦＱプロセスをトリガーし；設定されていなければ、価格呼び値要求をＷＲＳ８へ送る。
【００７１】
更に図１６を参照すると、Ｓ１０５では、ＷＲＳ８が、ＲＦＱパラメータをチェックし、設定されていれば、ＲＦＱプロセスをトリガーし；設定されていなければ、２方向買い−売り価格呼び値を生成して、それをＷＴＳ６へ送る。Ｓ１０６では、ＷＴＳ６が、価格呼び値を販売トレーダーＧＵＩ１１２へ送る。Ｓ１１２では、販売トレーダーＧＵＩ１０２が、価格呼び値を販売トレーダーのために表示する。Ｓ１１４では、販売トレーダー１１２が、価格呼び値を顧客１１６へ通信する。Ｓ１０７で、顧客１１６は、価格呼び値の拒絶か受諾かの顧客の決定と、顧客１１６が受諾した場合の、顧客の希望量とを販売トレーダー１１２へ応答する。Ｓ１０８では、販売トレーダー１１２が、顧客の拒絶を「取消」ボタン１４６を押して入力するか、あるいは、顧客１１６が受諾する場合、顧客の希望量を入力して、「買い」ボタン１４０または「売り」ボタン１４２を押すことによりトランザクションを履行する。
【００７２】
本発明の実施の形態のための追加局面は、マルチバンクを特長とし、ＣＡＴＳ−ＯＳシステムを使用して複数の銀行が自らの価格を配信することを可能にする自動ワラント取引のためのシステムと方法を提供する。マルチバンク局面は、１つ以上の追加の銀行とのリンクを確立することにより、単体の銀行ＣＡＴＳ−ＯＳシステムがマルチバンクモードで実行することを可能にする。取引データは他の銀行から集められ、ひとたび取引がなされると、その取引は特定の銀行に戻されるので、その銀行のポジションを管理できるとともに、自らの評価およびそれに類似することを遂行できる。本発明の実施の形態のためのマルチバンク局面は、単体の銀行自動ワラント取引ＣＡＴＳ−ＯＳシステムを、マルチバンク自動ワラント取引のシステムおよび方法へ変換する。
【００７３】
図１７は、本発明の実施の形態のマルチバンク局面のための、主要構成要素、および主要構成要素間の情報の流れを図解する概略図である。このマルチバンク局面は、組込み過ぎであるという潜在的問題を回避している。例えば、銀行が競合価格をオファーする場合に、その銀行は株式取引所行為をしているとの申し立てのような潜在的な規制上の問題がある。換言すれば、銀行が１つのシステム上で多数の異なる競合価格を許した場合、そのシステムは事実上株式取引所であると申し立てられる可能性がある。本発明の実施の形態のためのマルチバンク局面は、それが株式取引所であると申し立てられることを回避する。というのは、このシステムは、そのマルチバンク局面を使用して各銀行間での直接的価格競争を伴なわないからである。
【００７４】
単体の銀行ＣＡＴＳ−ＯＳシステムは、最終階層 （end tier） クライアントサーバーシステムであり、その利点は、異なる機能が非常に良く区分けされていることである。この単体の銀行システムの機能は、相場サーバーつまりＷＲＳを含んで、トランザクションサーバーつまりＷＴＳからの相場要求を受取って履行すること、そして、ハンドオフサーバーつまりＷＨＯを含んで、完全なトランザクションを直結ディーラーインタフェースつまりＤＤＩへ引渡すことである。ＷＲＳは、銀行から権利を受取って管理し、それを必要に応じてシステムの他部へ提供し、ＷＨＯは、システムから請求書を受取って、それを銀行へ引渡し、再調整プロセスを提供する。単体の銀行ＣＡＴＳ−ＯＳシステムは、ＷＴＳ、およびシステム全体を共に結びつける、セキュリティとメッセージングの階層を含む。
【００７５】
本発明の実施の形態のマルチバンク局面では、第１の銀行のＷＴＳ６に加え、例えば、第２の銀行のＷＴＳ２０２のような、１つ以上の追加トランザクションサーバーが使用され、それらは、第１の銀行のＷＴＳ６からは完全に独立しているとともに相互に完全に独立している。本発明の実施の形態のためのマルチバンク局面では、第２の銀行のＷＴＳ２０２のような追加の各トランザクションサーバーは、第２の銀行のようなひとつの追加銀行専用で対処する。同様に、第２の銀行のＷＲＳ２０４のような１つ以上の追加相場サーバー、および第２の銀行のＷＨＯ２０６のような１つ以上の追加ハンドオフサーバーが提供され、これらが多数銀行間の隔離を可能にする。顧客２０８は、取引システム２１６と２１８のような、複数の銀行の個別自動ワラント取引システムへの、共有された通信およびメッセージングの階層２１４へネットワーク２１２を介して接続されたグラフィカルユーザーインタフェース（ＧＵＩ）２１０を使用する。
【００７６】
本発明の実施の形態のためのマルチバンク局面では、各銀行の個別の自動ワラント取引システム２１６と２１８は、例えば、共有された通信およびメッセージングの階層２１４へ結合された別々のトランザクションサーバーＷＴＳ６とＷＴＳ２１２、および、トランザクションサーバーＷＴＳ６とＷＴＳ２０２へそれぞれ結合された別々の相場サーバーＷＲＳ８とＷＲＳ２０４、およびハンドオフサーバーＷＨＯ７とＷＨＯ２１６を含む。更に、各銀行の別々の取引システム２１６、２１８は、それぞれの銀行の相場サーバーＷＲＳ８とＷＲＳ２０４、およびハンドオフサーバーＷＨＯ７とＷＨＯ２１６間に確立されたファイヤーウオール２２０、２２２、およびそれぞれの銀行のデータセンター２２４、２２６を含む。このように、マルチバンクシステム上の１つの銀行は、システム上の他の銀行が特定顧客２０８とどのようにして取引をしているかを見ることは許されてはいない。マルチバンク局面は、共有された通信およびメッセージングの階層２１４を利用する一方、それは各エンドユーザーのシステム上で独立して動作する。マルチバンク局面は、そのシステムを利用する各銀行に対してトランスペアレントである。マルチバンクシステムを利用する特定の銀行に関する限り、それは、そのシステム上の唯一の銀行である。
【００７７】
現在、ＣＡＴＳ−ＯＳシステムは、例えば、ドイツでは銀行の顧客のための自動電子商取引ツールとしてきわめて成功裏に稼動している。これらの顧客は主としてブローカーであるので、銀行は、最終顧客（end customer）の身元を知らないことが多い。本発明の実施の形態のためのマルチバンク局面は、他の銀行が自らの価格をＣＡＴＳ−ＯＳシステムへ追加できるようにしているので、これらのブローカーは、そのワラントも売買できる。これは、ブローカーが自らの顧客のニーズを満足するために１つのシステムを取扱うだけであるという点で、ブローカーにとり有利である。本発明の実施の形態のためのマルチバンク局面では、銀行の全面子会社のような企業体が、他の全ての当事者と同様に、銀行と自らとの間の分離を維持する子会社の能力を実証することにより、何百もの他の銀行、企業、および／またはファンドマネージャと取引するシステムを提供できるようにする。そのような企業体は、ＣＡＴＳ−ＯＳシステムのソフトウエアおよびハードウエアの両方に責任を持つことができ、そのシステムを自らのデータセンター２２８で実行させることができ、親銀行と自らとの間に明確に定義された引渡しを提供できる。
【００７８】
本発明の実施の形態のマルチバンク局面は、ＣＡＴＳ−ＯＳシステムのユーザー２０８が、多数の銀行とマーケットメーカーから容易にワラントを売買できるようにする。ユーザー２０８がダイヤルしてシステムにアクセスすれば、ユーザー２０８は、他の銀行と取引するために、接続を切って、再ダイヤルする必要がない。ユーザー２０８は、例えばシステム２１６、２１８の各々へ別々にログインする必要がない。更に、システム２１６，２１８は、株式取引所を形成する恐れを生ずるようには統合されていない。加えて、価格形成者間の隔離が保たれる。本発明の実施の形態のためのマルチバンク局面は、時宜を得て信頼性のある方法で、価格形成者から相場を引出し、結果としての取引を銀行へ戻す、早くて安全な、信頼できる方法を提供する。
【００７９】
本発明の実施の形態のためのマルチバンク局面では、追加した銀行を見ることができるように、追加したレベルの機能性を、現行のユーザーフロントエンドＧＵＩに付加できる。代替として、比較的少数の銀行に対して、利用可能な銀行毎にＧＵＩは何度でも実行することができる。この代替方法では、ユーザー２０８は、必要に応じて１つのシステムから他へ単にクリックするだけである。これを可能にするメカニズムも、キーボードだけで提供される。これは、例えば、ＧＵＩと高仕様マシンに変更して、同時に２つ以上のプログラムを実行することで遂行される。本発明の実施の形態のためのマルチバンク局面では、第１の銀行システム２１６と第２の銀行システム２１８の両銀行のユーザーは、自らのＧＵＩ経由でシステムへアクセスでき、全ての機能の隔離が維持される。第１の銀行の子会社のような企業体は、システム管理者モードで行動できる。どの顧客がどの銀行と可能にするかの決定がなされ得る。システムは、必要なら単体の銀行システムのままにして使用できる。所定のビジネス編成が、例えば、第１の銀行、その子会社、および第２の銀行のような他の銀行の間に入れられる。
【００８０】
図１８は、本発明の実施の形態のためのマルチバンク局面における、顧客トランザクションプロセスの一実施例を図解するフローチャートである。Ｓ２０１では、顧客２０８が、顧客ＧＵＩ２１０でログオンして、顧客の価格呼び値要求を入力する。Ｓ２０２では、顧客ＧＵＩ２１０が、価格呼び値要求を、共有された通信およびメッセージングの階層２１４経由で、別々に維持され隔離された取引システム２１６および２１８のＷＴＳ６およびＷＴＳ２０２へ同時に送る。Ｓ２０３では、ＷＴＳ６およびＷＴＳ２０２の各々が、価格呼び値要求を自らの取引システム２１６または２１８の、対応するＷＲＳ８およびＷＲＳ２０４へ送る。Ｓ２０４では、ＷＲＳ８およびＷＲＳ２０４の各々が、独立して、履行可能な相場を生成して、その相場を、自らの取引システム２１８または２１８の、対応するＷＴＳ６およびＷＴＳ２０２へ送る。Ｓ２０５では、ＷＴＳ６およびＷＴＳ２０２の各々が、自らの取引システムの相場呼び値を、共有された通信およびメッセージング階層２１４経由で顧客ＧＵＩ２１０へ送る。
【００８１】
更に図１８を参照すると、Ｓ２０６では、顧客ＧＵＩ２１０が、各々の相場呼び値を、各相場呼び値と、各相場呼び値を提供した金融機関の取引システム２１６または２１８の身元とが、顧客２０８と相場呼び値を提供した金融機関にだけ知られるように、受取って表示する。Ｓ２０７では、顧客２０８が、顧客ＧＵＩ２１０で取引システム２１６または２１８の一方が提供し相場呼び値の中からユーザーが選択したひとつを入力する。Ｓ２０８では、顧客ＧＵＩ２１０が、顧客の受諾を、共有された通信およびメッセージング階層２１４を介して、選択された相場呼び値を提供した取引システム２１６または２１８のＷＴＳ６またはＷＴＳ２０２へ、顧客２０８と、選択された相場呼び値を提供した金融機関の取引システム２１６または２１８へだけその選択が知られるように、送る。Ｓ２０９では、選択された相場呼び値を提供した取引システム２１６または２１８の、ＷＴＳ６またはＷＴＳ２０２が、顧客の受諾を受取り、その受諾を、選択された相場呼び値を提供した取引システム２１６または２１８の、対応するＷＨＯ７または２０６へ、処理するために送る。
【００８２】
本発明は、好ましいこれら実施の形態を参照して説明されたが、他の実施の形態も同じ結果を達成できる。本発明の変形および変更は当該技術に精通したものには明らかであろうし、上記の開示はそのような変更および同等仕様の全てを含むものとする。従って、本発明は以下の特許請求の範囲によってのみ限定される。
【図面の簡単な説明】
【図１】図１は、本発明の実施の形態の呼び値要求局面の、主要構成要素、および主要構成要素間の情報の流れの実施例概観図解する概略図であり；
【図２】図２は、本発明の実施の形態の呼び値要求局面のカテゴリーメンテナンス画面のサンプルであり；
【図３】図３は、本発明の実施の形態の呼び値要求局面の取引入力画面のサンプルを示し；
【図４】図４は、本発明の実施の形態の呼び値要求局面のメッセージボックスのサンプルを示し；
【図５】図５は、本発明の実施の形態の呼び値要求局面の取引詳細画面のサンプルを示し；
【図６】図６は、本発明の実施の形態の呼び値要求局面において、顧客が相場を要求するプロセスの一実施例を図解するフローチャートであり；
【図７】図７は、本発明の実施の形態の呼び値要求局面の呼び値要求通知プロセスの一実施例を図解するフローチャートであり；
【図８】図８は、本発明の実施の形態の販売トレーダー局面における、主要構成要素、および主要構成要素間の情報の流れの実施例概観を図解する概略図であり；
【図９】図９は、本発明の実施の形態の販売トレーダー局面のデータベースの実施例概観を図解する概略図であり；
【図１０】図１０は、図９に示すデータベースのサンプル概観に関する更なる詳細を提供する拡大概略図であり；
【図１１】図１１は、本発明の実施の形態の販売トレーダー局面の取引入力画面のサンプルを示し；
【図１２】図１２は、本発明の実施の形態の販売トレーダー局面のトランザクション画面のサンプルを示し；
【図１３】図１３は、本発明の実施の形態の販売トレーダー局面の支店メンテナンス画面のサンプルを示し；
【図１４】図１４は、本発明の実施の形態の販売トレーダー局面の顧客メンテナンス画面のサンプルを示し；
【図１５】図１５は、本発明の実施の形態の販売トレーダー局面の取引詳細画面のサンプルを示し；
【図１６】図１６は、本発明の実施の形態の販売トレーダー局面の販売トレーダーのトランザクションプロセス実施例を図解するフローチャートであり；
【図１７】図１７は、本発明の実施の形態のマルチバンク局面の、主要構成要素、および主要構成要素間の情報の流れの実施例概観を図解する概略図であり；
【図１８】図１８は、本発明の実施の形態のマルチバンク局面における顧客トランザクションプロセスの一実施例を図解するフローチャートである。

Claims (28)

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. 前記要求端末は、それぞれが相場サーバまたはトランザクションサーバを備える独立して維持され分離された複数の取引システムに結合されていることを特徴とする請求項１５〜２７のいずれかのトランザクションサーバ。

Images