JP2002366746A - 取引仲介システム及び方法 - Google Patents

Abstract

(57)【要約】 【課題】 コール取引などの仲介システムであって、リ
スクベース又はコストベースのプライシングを自動的に
行う取引仲介システムを提供する。 【解決手段】 取引仲介サーバ１０が、複数のクライア
ントと通信しながらクライアント間の取引を仲介する。
サーバ１０は、各クライアントから、各クライアントが
設定したリスクベースのプライシングデータ及びコスト
ベースのプライシングデータを受け（S361）、保存する
（S362）。サーバ１０は、各クライアントから、取引の
注文の入力を受けると（S363,S364）、保存されている
リスクベース及びコストベースのプライシングデータに
基づいて、その注文の金銭的な取引条件(例えば貸付利
息)を、取引相手のリスク及び1取引当たりのコストに応
じて調整する（S366）。そして、サーバ１０は、その注
文の調整された取引条件を、各取引相手に通知する（S3
67）。さらに、サーバ１０は、その注文の調整された取
引条件に基づいて、その注文についての取引の約定を成
立させる。

Description

【発明の詳細な説明】

【０００１】

【発明が属する技術分野】本発明は、資金、商品又はサ
ービスなどの貸借、寄託又は売買などの取引を仲介する
ためのコンピュータ利用システムに関する。

【０００２】本発明は、特に、例えばコール取引のよう
に、取引者が、秒や分のオーダでめまぐるしく変化する
市場状況や取引条件を的確に把握して短時間に約定を成
立させていく必要のある類の取引の仲介に好適なもので
あるが、それのみに本発明の適用範囲が限られるわけで
はない。

【０００３】

【従来の技術】以下、本発明の適用に好適な「コール取
引」を例に取り説明する。

【０００４】周知のように、コール取引は、金融機関が
短期的な支払準備金の過不足の調整のために金融機関相
互間で行なう資金の消費貸借であり、「市場相対取引」
と「直接相対取引」に大別される。

【０００５】「市場相対取引」は、短資会社の仲介の下
で、多数の金融機関が参加したコール市場において行な
われる。各金融機関がコール取引の注文を短資会社に発
することで、その注文がコール市場に投入されることに
なる。コール取引の注文には、資金の運用を希望する
（資金を出したい）ものと、資金の調達を希望する（資
金を取りたい）ものとがある。この明細書では、資金運
用のための注文を「オファー」（offer）と呼び、資金
調達のための注文を「ビッド」（bid）と呼ぶことにす
る。コール市場に投入される注文には、オファーかビッ
ドか、貸借期間、金利、取引希望最高金額などの取引条
件が含まれている。

【０００６】コール市場に参加した各金融機関では、コ
ール担当ディーラが注文を短資会社に対して発し、それ
を短資会社の各金融機関担当のスタッフが受け取ってコ
ール市場に投入する。コール市場では、短資会社のスタ
ッフの仲介により、取引条件の点で約定可能なオファー
とビッドが出会わされ、約定へ導かれていく。コール市
場では、矢継ぎ早に新たな注文が投入され、次々と新た
な約定が成立していく。したがって、コール市場の状況
はめまぐるしく変動している。実際のところ秒オーダ
で、市況が変動している。コール市場における短資会社
の仲介業務は、短資会社のスタッフの人手によって遂行
されている。

【０００７】「直接相対取引」は、短資会社を通さず
に、金融機関同士が直接コンタクトすることで行なわれ
るコール取引である。すなわち、資金を運用又は調達し
たい金融機関のコール担当ディーラは、自社の要求に応
え得るであろう金融機関と、電話やファクシミリなどの
方法で直接コンタクトをとり、自社の取引希望を伝え
る。このとき、コンタクトする金融機関の数は一つとは
限らず、むしろ複数であることが多い。そのディーラ
は、複数の金融機関に対して希望を伝え、それぞれの金
融機関から返答を受け、応諾してくれた金融機関と個別
に取引条件を詰めて約定に至る。或る相手との約定が成
立すると、必然的に、他の相手に対する取引希望は取り
消されたり取引希望金額などが変化したりするので、デ
ィーラは、直ちにその旨を他の相手に対して通知する必
要がある。

【０００８】

【発明が解決しようとする課題】市場相対取引における
短資会社の仲介業務で肝心なことは、めまぐるしく変動
するコール市場の状況を迅速にクライアントの金融機関
へ通知することにより、時々の市況の下でクライアント
にとり最適な約定を、効率的に成立させていくことにあ
る。しかし、このようにコール市場の高速な変化に実時
間で対応して最適に取引を仲介することは、短資会社の
スタッフにとり容易なことではない。

【０００９】短資会社が、取引条件上では約定可能なオ
ファーとビッドとを出会わせたとしても、オファー側の
クライアントがビッド側のクライアントに対して与えて
いるクレジットライン(与信枠)が不足していると、オフ
ァー側クライアントは約定を拒否せざるを得ない。そう
なると、短資会社は、そのオファーに対しては条件の合
う別のビッドを見つけて捜して出会わせることになる。
そのとき、約定に至れない同じクライアント同士の似た
ような条件のオファーとビッドを再び出会わせてしまう
と、再び同じ理由で破談に終わるという非効率且つ不愉
快な事態が発生する。そこで、短資会社のスタッフは、
そうした事態が生じないよう注意を払っている。しか
し、多くの取引を次々と処理していく過程で、こうした
点まで完全に注意を払うことは、短資会社のスタッフに
とり容易なことではない。

【００１０】直接相対取引においては、各金融機関のデ
ィーラは、上述したように、複数の相手とコンタクトを
とり、取引条件を詰めたり、条件の変動を通知したりと
いうような煩雑な事務処理を自社で行なわなければなら
ない。この煩雑な処理は、効率的に約定を成立させてい
くための障害となる。

【００１１】また、市場相対取引と直接相対取引には、
それぞれメリットとデメリットがある。金融機関は、目
的の資金を調達又は運用するのに、市場相対取引と直接
相対取引のいずれを利用する方が有利であるかという判
断を行なう必要がある。しかし、時々刻々と変化する市
場状況の下でその判断が容易にできるよう援助してくれ
るツールは従来存在しない。

【００１２】上述した問題に類似した問題は、コール取
引以外の取引においても存在する可能性がある。

【００１３】上記の事情に鑑み、本願の出願人らは、２
００１年４月３日付けの特願２００１−１０５１０４号
において、コンピュータと通信ネットワークを利用し
て、取引注文の投入や約定の成立などの市場の変化を市
場参加者に的確に通知しながら効率的に取引の仲介を自
動的に行なうための取引仲介システムを提案した（本願
の出願時において未公開である）。この取引仲介システ
ムは、市場取引と直接取引のいずれの仲介も行うことが
できる。

【００１４】ところが、コール取引において(また、他
の様々な金融取引又は商品取引においても)、取引リス
クに応じた値段付け（以下、「リスクベースのプライシ
ング」という）や、取引コストに応じた値段付け（以
下、「コストベースのプライシング」という）が行われ
ている。リスクベースのプライシングの典型例として
は、資金の借り手又は商品の買い手の信用格付けが高い
ほど（つまり、取引相手に起因するリスクが低いほ
ど）、貸付利息又は商品単価を下げるというものがあ
る。また、コストベースのプライシングの典型例として
は、一回の取引の金額又は商品数量が大きいほど（つま
り、取引対象の単位量当たりのコストが低いほど）、貸
付利息又は商品単価を下げるというものがある。

【００１５】このようなリスクベース又はコストベース
のプライシングについて、上記の特願２００１−１０５
１０４号は、格別の自動化手段を提供していない。よっ
て、各利用者は自身で相手の信用格付けや取引金額など
に応じたプライシングを制御しなければならない。しか
し、適正なプライシングの制御は、各利用者にとって容
易なことではない。

【００１６】従って、本発明の別の目的は、リスクベー
スのプライシングを自動的に行う取引仲介システムを提
供することにある。

【００１７】本発明のまた別の目的は、コストベースの
プライシングを自動的に行う取引仲介システムを提供す
ることにある。

【００１８】

【課題を解決するための手段】本発明の第１の観点に従
う、複数のクライアントと通信しながらクライアント間
の取引を仲介する取引仲介システムは、各クライアント
から、各クライアントが他のクライアントの各々に対し
て設定したリスクベースのプライシングデータを受け、
設定されたプライシングデータを記憶装置に格納するプ
ライシングデータ設定手段と、各クライアントから、取
引のための注文の入力を受け、入力された注文を記憶装
置に格納する注文手段と、各クライアントにより前記他
のクライアントの各々に対して設定された前記記憶装置
内のリスクベースのプライシングデータに基づいて、各
クライアントから入力された注文の金銭的な取引条件を
前記他のクライアントの各々毎に調整するプライシング
手段と、各クライアントから入力された注文に関し、前
記他のクライアントの各々毎に調整された金銭的な取引
条件を、前記他のクライアントの各々に通知する注文通
知手段と、各クライアントから入力された注文に関し、
他の或るクライアントについて調整された金銭的な取引
条件に基づいて、前記他の或るクライアントとの取引の
約定を成立させる約定手段とを備える。

【００１９】好適な実施形態では、前記プライシングデ
ータ設定手段は、各クライアントをして前記他のクライ
アントの各々に対し取引期間に応じて異なるプライシン
グデータを設定することを許し、各クライアントから受
けた前記取引期間に応じて異なるプライシングデータを
前記記憶装置に記憶し、前記プライシング手段は、各ク
ライアントから前記他のクライアントの各々に対し設定
されている前記記憶装置内の前記取引期間に応じて異な
るプライシングデータのうちの、各クライアントから入
力された注文が指定する取引期間に対応するプライシン
グデータに基づいて、各クライアントから入力された注
文の金銭的な取引条件を調整する。

【００２０】本発明の第２の観点に従う、複数のクライ
アントと通信しながらクライアント間の取引を仲介する
取引仲介システムは、各クライアントから、各クライア
ントが複数のコストレンジの各々毎に設定したコストベ
ースのプライシングデータを受け、設定されたプライシ
ングデータを記憶装置に格納するプライシングデータ設
定手段と、各クライアントから、取引のための注文の入
力を受け、入力された注文を記憶装置に格納する注文手
段と、各クライアントにより設定された前記記憶装置内
のコストベースのプライシングデータに基づいて、各ク
ライアントから入力された注文の金銭的な取引条件を、
その注文に適用可能なコストレンジの各々毎に調整する
プライシング手段と、各クライアントから入力された注
文に関し、前記適用可能なコストレンジの各々毎に調整
された金銭的な取引条件を、他のクライアントに通知す
る注文通知手段と、各クライアントから入力された注文
に関し、前記適用可能なコストレンジの内の何れか一つ
について調整された金銭的な取引条件に基づいて、前記
他の或るクライアントとの取引の約定を成立させる約定
手段とを備える。

【００２１】好適な実施形態では、前記プライシングデ
ータ設定手段は、各クライアントをして前記複数のコス
トレンジの各々に対し取引期間に応じて異なるプライシ
ングデータを設定することを許し、各クライアントから
受けた前記取引期間に応じて異なるプライシングデータ
を前記記憶装置に記憶し、前記プライシング手段は、各
クライアントから前記複数のコストレンジの各々に対し
設定されている前記記憶装置内の前記取引期間に応じて
異なるプライシングデータのうちの、各クライアントか
ら入力された注文が指定する取引期間に対応するプライ
シングデータに基づいて、各クライアントから入力され
た注文の金銭的な取引条件を調整する。

【００２２】本発明の第３の観点に従う、複数のクライ
アントと通信しながらクライアント間の取引を仲介する
取引仲介システムは、各クライアントから、各クライア
ントが他のクライアントの各々に対して設定したリスク
ベースのプライシングデータを受け、設定されたプライ
シングデータを記憶装置に格納するリスクプライシング
データ設定手段と、各クライアントから、各クライアン
トが複数のコストレンジの各々毎に設定したコストベー
スのプライシングデータを受け、設定されたプライシン
グデータを記憶装置に格納するコストプライシングデー
タ設定手段と、各クライアントから、取引のための注文
の入力を受け、入力された注文を記憶装置に格納する注
文手段と、各クライアントにより前記他のクライアント
の各々に対して設定された前記記憶装置内のリスクベー
スのプライシングデータと、各クライアントにより前記
コストレンジの各々毎に設定された前記記憶装置内のコ
ストベースのプライシングデータとに基づいて、各クラ
イアントから入力された注文の金銭的な取引条件を、前
記他のクライアントの各々毎に且つその注文に適用可能
なコストレンジの各々毎に、調整するプライシング手段
と、各クライアントから入力された注文に関し、前記他
のクライアントの各々毎に且つその注文に適用可能なコ
ストレンジの各々毎に調整された金銭的な取引条件を、
前記他のクライアントの各々に通知する注文通知手段
と、各クライアントから入力された注文に関し、他の或
るクライアントについて且つその注文に適用可能なコス
トレンジの内の何れか一つについて調整された金銭的な
取引条件に基づいて、前記他の或るクライアントとの取
引の約定を成立させる約定手段とを備える。

【００２３】本発明の他の特徴と目的は、以下の実施形
態の説明で明らかにされる。

【００２４】

【発明の実施の形態】本発明の理解を容易にするため
に、本発明の実施形態の説明に入る前に、上述した特願
２００１−１０５１０４号に記載されたコール取引用の
取引仲介システムの実施形態を、図１〜図３０を参照し
て説明する。その後に、この先願記載の取引仲介システ
ムの実施形態をベースにした本発明の実施形態を、図３
１〜図４０を参照して説明する。

【００２５】まず、上記先願記載の取引仲介システムの
実施形態を説明する。以下は、その説明で用いる主要な
用語の定義である。

【００２６】「マーケット取引」とは、従来技術の説明
で述べた「市場相対取引（Market Deal: MD）」のこと
をいう。すなわち、「マーケット取引」とは、多数の金
融機関が参加したコール市場において行なわれるコール
取引をいう。「マーケット取引」では、約定が成立する
まで又は約定成立の一歩前の段階まで、取引当事者には
取引相手の名称は知らされない。その意味で、「マーケ
ット取引」とは、不特定多数の金融機関の間で行なわれ
るクローズドネームのコール取引ということができる。

【００２７】「オープンネーム取引」とは、従来技術の
説明で述べた「直接相対取引(Direct Deal: DD)」と基
本的には同じであるが、若干異なる側面を有している。
すなわち、本発明の実施形態における「オープンネーム
取引」は、「マーケット取引」と同様に、取引仲介シス
テムの仲介の下で行なわれる。よって、金融機関のディ
ーラが相手と直接コンタクトをとって行なう文字通りの
「直接相対取引」は、本発明の実施形態の下では最早存
在しない。「オープンネーム取引」が従来の「直接相対
取引」と共通する点は、取引相手が誰であるかが、注文
を出す当初の段階から特定されていることである。その
意味で、「オープンネーム取引」とは、特定の金融機関
の間で行なわれるオープンネームのコール取引というこ
とができる。

【００２８】「コール市場」とは、コール取引が行なわ
れる金融機関相互間の市場をいう。一般には、マーケッ
ト取引が行なわれる市場をコール市場と呼ぶが、本発明
の実施形態の説明では、マーケット取引だけでなく、オ
ープンネーム取引が行なわれる市場も「コール市場」と
呼ぶ。

【００２９】「オファー(Offer)」とは、資金を運用し
たい（資金を出したい）金融機関が発するコール取引の
ための注文をいう。

【００３０】「ビッド(Bid)」とは、資金を調達したい
（資金を取りたい）金融機関が発するコール取引のため
の注文をいう。

【００３１】注文を発した金融機関又は注文そのもの
を、オファーとビッドの相対関係の点から区別して形容
するとき、オファーの方を「オファー側」、ビッドの方
を「ビッド側」、そして、オファー側から見たビッド側
及びビッド側から見たオファー側を「カウンターサイ
ド」という。

【００３２】本発明の実施形態のシステムにおいては、
金融機関が発する注文（オファー又はビッド）には、
「取引条件」の指定が必ず含まれる。その「取引条件」
には、幾つかの項目、例えば「サイド」、「ターム」、
「レート」、「ロット」、「刻み幅」及び「アマウン
ト」が含まれる。

【００３３】「サイド」とは、オファーかビッドかの区
別である。

【００３４】「ターム」は、取引（貸借）の期間であ
り、開始日時と終了日時の指定を含む。タームの種類に
は、最短1日以内のものから、最長３６５日のものまで
様々な種類がある。

【００３５】「レート」は、貸借金利である。

【００３６】「ロット」は、約定可能な取引金額の最低
額であり、ロット以上の金額で約定が成立することにな
る。

【００３７】「刻み幅」は、システムの計算処理上で取
引金額を増減するときに用いる増減単位である。

【００３８】「アマウント」とは、運用又は調達したい
金額の総額であり、事実上、約定可能な取引金額の最高
額を意味することになる。

【００３９】この明細書では説明の都合上、「取引条
件」を「業務条件」と「金額条件」に大別する。

【００４０】「業務条件」には、「サイド」、「ター
ム」及び「レート」が含まれる。

【００４１】「金額条件」には、「ロット」、「刻み
幅」及び「アマウント」が含まれる。

【００４２】「ホットクォーツ(Hot Quotes: HQ)」と
は、本発明の実施形態の仲介システムがグラフィカルユ
ーザインタフェース上で用いる用語であり、そのグラフ
ィカルユーザインタフェースを見ているクライアント
（金融機関）に向けられている（つまり、そのクライア
ントにその注文の受諾資格がある）他の金融機関からの
コール取引のための注文をいう。この明細書(特に、参
照図面中)では、「ホットクォーツ」を「HQ」と略称す
る場合がある。

【００４３】「オープンエンド(Open End: OE)取引」と
は、取引の終了日時を意図的に未定の状態にしてある取
引をいう。この明細書(特に、参照図面中)では、オープ
ンエンド取引を「OE」と略称する場合がある。マーケッ
ト取引にもオープンネーム取引にも、オープンエンド取
引が在り得る。

【００４４】「オープンエンドロール(Open End Roll:
OER)交渉」とは、オープンエンド取引で定められた期日
までに、その取引を継続、変更又は終了について当事者
間で行なわれる交渉をいう。この明細書(特に、参照図
面中)では、オープンエンドロール交渉を「OER」と略称
する場合がある。

【００４５】以下、添付図面を参照しながら、本発明の
一実施形態にかかる取引仲介システムについて説明す
る。

【００４６】図１は、この実施形態にかかる取引仲介シ
ステムの全体的な構成を示す。

【００４７】図1に示すように、コール取引仲介サーバ
システム(以下、「仲介サーバ」という)１０と、この仲
介サーバ１０のシステム管理者が用いる管理者システム
２０とが、短資会社の許に存在する。仲介サーバ１０と
管理者システム２０は、専用通信ネットワーク５０を介
して相互通信可能である。

【００４８】また、短資会社のクライアントである多数
の金融機関A〜Cは、仲介サーバ１０を利用するためのク
ライアントシステム３０A〜３０Cをそれぞれ有してい
る。仲介サーバ１０と、クライアントシステム３０A〜
３０Cの各々とは、専用通信ネットワーク５０を介して
相互通信可能である。

【００４９】さらに、成立した約定の確認に用いられる
短資取引約定確認システム４０が、複数の短資会社の協
力の下に存在する（図１では１つの短資会社しか図示し
ていない）。仲介サーバ１０は、管理者システム２０経
由で、短資取引約定確認システム４０と専用通信ネット
ワーク６０を介して相互通信可能である。各クライアン
トシステム３０A〜３０Cも、短資取引約定確認システム
４０と専用通信ネットワーク６０を介して相互通信可能
とすることができる。

【００５０】図２は、仲介サーバ１０が行なう各種のプ
ロセスを示す。

【００５１】図２に示すように、仲介サーバ１０は、参
照番号１０１〜１１０、１１０A及び１１０Bで示すプロ
セスを行なうことができる。仲介サーバ１０は、それら
のプロセス１０１〜１１０、１１０A及び１１０Bにおい
て、個々のクライアントシステム３０内のコール担当デ
ィーラが使用する端末装置（以下、「ディーラ端末」と
いう）３１又はディーラの背後の事務スタッフが使用す
る端末装置（以下、「バックオフィス端末」という）３
２と通信したり、或いは、管理者システム２０内のシス
テム管理者が使用する端末装置（以下、「システム管理
者端末」という）２１と通信したり、或るいは、短資取
引約定確認システム４０と通信したりする。

【００５２】仲介サーバ１０の行なうプロセス１０１〜
１１０、１１０A及び１１０Bを、以下に個別に説明す
る。

【００５３】メッセージ登録プロセス１０１は、システ
ム管理者端末２１からクライアン向けのメッセージの登
録を受付け、登録されたメッセージを個々のディーラ端
末３１及びバックオフィス端末３２のディスプレイ画面
に表示する。メッセージの表示方法には、ディーラ端末
３１及びバックオフィス端末３２が仲介システム１０に
ログインした直後にメッセージを表示する方法と、取引
仲介業務を行っている最中に随時にメッセージを表示す
る方法の２種類の方法が、システム管理者の任意で選択
できる。

【００５４】ログイン／ログアウトプロセス１０２は、
ディーラ端末３１及びバックオフィス端末３２の仲介シ
ステム１０へのログインとログアウトを制御する。

【００５５】初期設定プロセス１０３は、ディーラ端末
３１及びバックオフィス端末３２から取引仲介業務に必
要な所定項目の初期設定情報の入力を受け付けて仲介シ
ステム１０に登録したり、ディーラ端末３１及びバック
オフィス端末３２がログインした直後に、仲介システム
１０に登録済みの処理設定情報を読み込んで以後の取引
仲介業務を行なうための各種プロセスに反映させたりす
る。

【００５６】予約確認通知プロセス１０４は、毎日のコ
ール市場の開場時刻より早い時刻からディーラ端末３１
から予約的な注文の入力を受け付けて、コール市場の開
場時刻が来ると同時に、それらの予約的注文を本注文に
置き換える（つまり、コール市場に投入する）。

【００５７】タイマプロセス１０５は、時刻を出力する
プロセスであり、その時刻は予約確認通知プロセス１０
４や後述するリアルタイム配信プロセス１０７などで利
用される。

【００５８】注文約定プロセス１０６は、取引仲介業務
の中心的役割を果たすプロセスである。注文約定プロセ
ス１０６は、ディーラ端末３１から注文の入力（取引条
件変更や注文キャンセルの入力も含む）を受付ける（つ
まり、注文をコール市場に投入する）こと、ディーラ端
末３１のディスプレイ画面上にホットクォーツ（当該ク
ライアント向けの他のクライアントからの注文）や市場
概況や当該クライアントの注文履歴などの情報を表示す
る（つまり、コール市場の状況をグラフィカルにクライ
アントに通知する）こと、当該クライアントの注文と上
記当該クライアント向けの他のクライアントからの注文
との間で取引条件のマッチングを行なうこと、マッチン
グの結果に基づいて約定可能な注文同士を出会わせて約
定に導くこと、成立した約定を仲介システム１０内に登
録し短資約定確認システム４０に通知すること、などを
行なう。

【００５９】リアルタイム配信処理１０７は、注文約定
処理１０６が注文の入力（取引条件変更や注文キャンセ
ルの入力も含む）を受け付けたとき及び約定を成立させ
たとき、それらの事実に基づいて、リアルタイムで、デ
ィーラ端末３１のディスプレイ画面上のホットクォーツ
や市況情報や当該クライアントの注文履歴などの情報を
更新する（つまり、コール市場の変化をリアルタイムで
グラフィカルにクライアントに通知する）。

【００６０】OER（オープンエンドロール）プロセス１
０８は、ディーラ端末３１及びバックオフィス端末３２
のディスプレイ画面に、そのクライアントがもつオープ
ンエンド取引についてのオープンエンドロール交渉のス
ケジュールを表示すること、ディーラ端末３１のディス
プレイ画面に、オープンエンドロール交渉を行なうため
のウィンドウを表示してその交渉の仲介を行なうこと、
及びオープンエンドロール交渉の結果に従ってその取引
の継続、変更又は終了を制御すること、などを行なう。

【００６１】ユーザ管理プロセス１０９は、クライント
(ユーザ)の登録や、ログインのための認証情報の発行や
管理を行なう。

【００６２】照会プロセス１１０は、ディーラ端末３１
又はバックオフィス端末３２のディスプレイ画面に、そ
のクライアントが過去に成立させた全ての約定の履歴を
一覧で表示したり、選択された個々の約定の内容を詳細
に表示したり、それらの表示内容を印刷したりするもの
である。

【００６３】二次コンファームプロセス１１０Aは、照
会プロセス１１０によって約定の情報が表示されたバッ
クオフィス端末３２又はディーラ端末３１のディスプレ
イ画面上で、その約定に対する確認の入力を受け付け、
確認が入力されると、その確認入力の旨を、その約定の
相手方のバックオフィス端末又はディーラ端末に通知
し、そして、その相手方からも同様に確認の入力を受け
付けて戻すことで、当事者相互間での約定確認の手続き
を仲介するものである。

【００６４】約定取消プロセス１１０Bは、照会プロセ
ス１１０によって約定の情報が表示されたバックオフィ
ス端末３２又はディーラ端末３１のディスプレイ画面上
で、その約定に対する取消の入力を受け付けて、その約
定を取消すものである。

【００６５】以上のように構成された仲介サーバ１０が
行なうコール取引の仲介業務の処理を、以下にさらに詳
細に説明する。

【００６６】仲介サーバ１０が行なうコール取引の仲介
業務は、マーケット取引（市場相対取引）の仲介と、オ
ープンネーム取引（直接相対取引）の仲介とに大別され
る。図３は、マーケット取引の仲介業務の全体的な流れ
を示す。図４は、オープンネーム取引の仲介業務の全体
的な流れを示す。また、図５は、この仲介業務を行なう
ために仲介サーバ１０がディーラ端末３１のディスプレ
イ画面に表示するメインウィンドウ２００の構成を示
す。

【００６７】図３に示すマーケット取引の仲介業務で
も、図４に示すオープンネーム取引の仲介業務でも、初
めのステップS１〜S3の流れは同一である。

【００６８】仲介システム１０は、例えば毎朝、クライ
アントのディーラ端末３１及びバックオフィス端末３２
からログイン要求を受けて、ステップS1のログインプロ
セス（図２、１０２）を行ないログインを制御する。

【００６９】ディーラ端末３１又はバックオフィス端末
３２がログインすると、仲介システム１０は、図５に示
すようなメインウィンドウ２００をディーラ端末３１又
はバックオフィス端末３２のディスプレイ画面に表示す
る。メインウィンドウ２００内には、メニューバー２０
１、メッセージボックス２０２、通知ランプ２０３、ホ
ットクォーツ（HQ）ウィンドウ３００、市場情報詳細ウ
ィンドウ４００、自己注文状況ウィンドウ５００、約定
履歴ウィンドウ６００及びHQ表示切替ウィンドウ７００
がある。

【００７０】メッセージボックス２０２は、図２で説明
したメッセージ登録プロセス１０１がシステム管理から
のメッセージを表示する場所である。

【００７１】通知ランプ２０３は、図２で説明したOER
プロセス１０８が、オープンエンドロール交渉のための
相手方からのメッセージが届いたときに点灯させるラン
プである。

【００７２】ホットクォーツ（HQ）ウィンドウ３００
は、コール市場に存在するホットクォーツ(当該クライ
アント向けの他のクライアントからの注文)の状態がリ
アルタイムで一覧表示される場所である。その具体例は
図１１〜図１３に示されている（詳細は後に説明す
る）。

【００７３】市場情報詳細ウィンドウ４００は、コール
市場の全体的な市況がリアルタイムで表示される場所で
ある。その具体例は図１５に示されている（詳細は後に
説明する）。

【００７４】自己注文状況ウィンドウ５００は、当該ク
ライアントが発した注文の状態がリアルタイムで一覧表
示される場所である。その具体例は図１６及び図１７に
示されている（詳細は後に説明する）。

【００７５】約定履歴ウィンドウ６００は、当該クライ
アントがもっている約定の状態がリアルタイムで一覧表
示される場所である。その具体例は図１８及び図１９に
示されている（詳細は後に説明する）。

【００７６】HQ表示切替ウィンドウ７００は、ホットク
ォーツ（HQ）ウィンドウ３００の表示ページを切替えた
り、新規注文を発したりするための制御ボタンが並んで
いる場所である。その具体例は図１４に示されている
（詳細は後に説明する）。

【００７７】上述したメインウィンドウ２００内のメニ
ューバー２０１内の「ユーザ」メニューをディーラが選
ぶと、仲介システム１０は、図３及び図４に示したステ
ップS2のユーザ管理プロセス（図２、１０９）を行な
う。また、メニューバー２０１内の「初期設定」メニュ
ーをディーラが選ぶと、仲介システム１０は、図３及び
図４に示したステップS3の初期設定プロセス（図２、１
０３）を行なう。初期設定プロセスは、図７〜図９に例
示するようなウィンドウを用いて、取引仲介業務を行な
うために予め設定しておくべき所定事項を、ディーラ端
末３１及びバックオフィス端末３２から入力を受けて設
定する。

【００７８】ステップS3の初期設定プロセスが完了して
いる場合、仲介サーバ１０は、図３に示すステップS4以
降の処理、又は図４に示すステップS１４以降の処理に
入ることができる。ここから、マーケット取引の仲介と
オープンネーム取引の仲介とで処理内容が異なってくる
ことになるが、いずれの取引の仲介も、上述した同じメ
インウィンドウ２００を用いて行なわれる。

【００７９】まず、図３のステップS4以降の、マーケッ
ト取引の仲介業務の流れを説明する。

【００８０】図３に示すように、マーケット取引の仲介
業務では、仲介サーバ１０は、ステップS4でディーラ端
末３１から注文の入力を受け付け、入力された注文をデ
ータベース内の注文マスタテーブル１２４に登録する。
仲介サーバ１０は、ステップS5で、入力された注文と、
前述のメインウィンドウ２００内のホットクォーツウィ
ンドウ３００に表示されているホットクォーツ(当該ク
ライアント向けの他のクライアントからの注文)の内
の、上記入力された注文に対しカウンターサイドの関係
にある注文との間でマッチングを行なう。入力された注
文と取引条件の点で約定可能なカウンターサイドの注文
がホットクォーツ内に存在していれば、このマッチング
により、その約定可能なカウンターサイドの注文と、入
力された注文とが、マッチしたペアの注文としてピック
アップされる。

【００８１】仲介サーバ１０は、上記のマッチングによ
ってピックアップされたマッチしたオファーとビッドの
うち、オファー側のクライアントのディーラ端末に対し
て、ステップS7で、その取引内容とビッド側クライアン
トの名称とを通知して、約定を成立させるか否かの確認
を要求する。オファー側のクライアントは、取引内容と
ビッド側クライアントとに問題が無ければ、約定を許諾
するであろうし、問題（典型的には、ビッド側クライア
ントのクレジットラインが足りない）があれば、約定を
拒否するであろう。

【００８２】約定が拒否された場合、仲介サーバ１０
は、再びステップS5のマッチング処理へ進み、入力され
た注文と約定可能な別のカウンターサイドの注文を、ホ
ットクォーツ内から捜して、両注文をマッチしたペアと
して再度ピックアップすることになる。仲介サーバ１０
は、この再マッチングのときに、前のステップS7で破談
となった同じクライアント同士の似たような条件の注文
同士を再度出会わせて同じクレジットライン不足の理由
で再び破談に至ることがないよう、後に詳述するアルゴ
リズムでステップS5のマッチングを行なう。

【００８３】約定が許諾された場合、仲介サーバ１０
は、ステップS８で、約定を成立させ、その約定をデー
タベース内の約定マスタテーブル１２５に登録する。

【００８４】なお、上述した図３のステップS4〜S８
は、図２に示した注文約定プロセス１０６に対応する。

【００８５】上述した図３のステップS4で注文の入力が
あった場合、及びステップS8で約定の成立があった場
合、仲介サーバ１０は、ステップS12のリアルタイム配
信プロセス（図２、１０７）を行なう。すなわち、この
リアルタイム配信プロセスは、データベース内の注文マ
スタテーブル１２４及び約定マスタテーブル１２５を実
質的に常時監視していて、それらのテーブル１２４又は
１２５に新たに注文又は約定が登録されると、その影響
を受ける全てのクライアントのディーラ端末３１に表示
されているメインウィンドウ２００内のホットクォーツ
ウィンドウ３００、市場情報詳細ウィンドウ４００、自
己注文状況ウィンドウ５００又は約定履歴ウィンドウ６
００などに、その新たな注文の入力又は約定の成立の結
果をリアルタイムで反映させる。

【００８６】例えば、或る１つのクライアントから注文
が入力されれば、リアルタイム配信プロセスは、そのク
ライアントのディーラ端末３１上の自己注文状況ウィン
ドウ５００にその注文を追加表示し、また、その注文が
向けられた他のクライアントのディーラ端末３１上のホ
ットクォーツウィンドウ３００にその注文を追加表示す
る。さらに、リアルタイム配信プロセスは、その入力さ
れた注文に応じて、コール市場に参加している全てのク
ライアントのディーラ端末３１上の市場情報詳細ウィン
ドウ４００内の注文状況の表示を更新する。

【００８７】また、例えば、或る２つのクライアント間
で約定が成立すれば、その２つのクライアントのディー
ラ端末３１上の約定履歴ウィンドウ６００にその約定を
追加表示し、また、その約定に至ったオファーとビッド
がそれぞれ向けられている全てのクライアントのディー
ラ端末３１上のホットクォーツウィンドウ３００内の当
該オファーと当該ビッドの表示を更新する（すなわち、
その約定成立によって当該注文が消滅すれば、ホットク
ォーツウィンドウ３００から当該注文を消去し、また、
その約定成立によって当該注文のアマウントが減少すれ
ば、ホットクォーツウィンドウ３００内の当該注文のア
マウントを減少させる、など）。さらに、リアルタイム
配信プロセスは、その成立した約定に応じて、コール市
場に参加している全てのクライアントのディーラ端末３
１上の市場情報詳細ウィンドウ４００内の約定状況及び
市場状況の表示を更新する。

【００８８】図３に示すように、クライアントのディー
ラ端末３１から過去の約定について照会要求が入ると、
仲介サーバ１０は、ステップS13の照会プロセス(図２、
１１０)を行なう。照会プロセスは、データベース内の
約定マスタテーブル１２５に記録されている当該クライ
アントの約定の履歴情報を、そのディーラ端末３１及び
バックオフィス端末３２に表示する。

【００８９】図３に示すように、一旦成立した約定につ
いて、その約定当事者のクライアントのディーラ端末３
１及びバックオフィス端末３２から約定取消の要求が入
ると、仲介サーバ１０は、ステップS9の約定取消プロセ
ス（図２、１１０B）を行なう。約定取消プロセスは、
約定マスタテーブル１２５からその約定を消去する。こ
の約定取消の結果も、ステップS12のリアルタイム配信
プロセスによって、その約定に関係するクライアントの
ディーラ端末３１の約定履歴ウィンドウ６００の表示に
リアルタイムで反映される。

【００９０】図３に示すように、成立した約定がオープ
ンエンド取引であった場合、その約定について、仲介サ
ーバ１０は、ステップS10のOERプロセス（図２、１０
８）を行なう。OERプロセスは、そのオープンエンド取
引のオープンエンドロール交渉のスケジュールを、双方
の約定当事者のクライアントのディーラ端末３１上の約
定履歴ウィンドウ６００に表示し、そのいずれかの約定
当事者のクライアントのディーラ端末３１からオープン
エンドロール交渉の要求が入ると、双方の約定当事者間
のオープンエンドロール交渉の仲介を行なう。オープン
エンドロール交渉が終わると、OERプロセスは、その交
渉結果（つまり、その約定の継続、変更又は終了）に従
って、約定マスタテーブル１２５内の当該約定のレコー
ドを更新する。この更新結果も、ステップS12のリアル
タイム配信プロセスによって、その約定当事者のクライ
アントのディーラ端末３１のメインウィンドウ２００の
表示にリアルタイムで反映される。

【００９１】図３に示すように、ディーラ端末３１及び
バックオフィス端末３２からログアウトの要求が入る
と、仲介サーバ１０は、ステップS11のログアウト処理
を行なう。

【００９２】次に、図４のステップS14以降の、オープ
ンネーム取引の仲介業務の流れを説明する。

【００９３】仲介サーバ１０は、図４のステップS14で
ディーラ端末３１から注文の入力を受け付ける。ディー
ラからの注文の入力の仕方には2通りある。一つ目は、
取引相手の名称を選択して、その選択した取引相手が自
社に向けて発した注文をホットクォーツウィンドウ３０
０に表示した上で、そのホットクォーツウィンドウ３０
０の中から一つの注文を選択して、その選択した注文を
受諾する形の注文を入力する方法である。二つ目は、他
のクライアントから自社向けに発されている注文とは関
係なしに、自社が希望する取引条件と取引相手とを指定
して注文を発する方法である。この明細書では、前者の
方法で入力するオープンネーム取引注文を「岩陰注文」
（「岩陰」に隠れるように受動的に、相手から提示され
た注文を受けるという意味）と呼び、岩陰注文を発した
側のクライアントを、相手から提示された注文の「受け
手」と呼ぶ。また、後者の方法によるオープンネーム取
引注文を「矢面注文」（「矢面」に立つように能動的
に、相手へ注文を提示するという意味）と呼び、矢面注
文を発したクライアントを、注文の「プレゼンタ（提示
者）」と呼ぶ。

【００９４】ディーラ端末３１から岩陰注文が入力され
た場合には、仲介サーバ１０は、図４のステップS15の
マッチング処理に進み、入力された岩陰注文とディーラ
により選択された相手からの矢面注文とを出会わせ、そ
してS18の約定処理へ進み、出会った上記ペアの注文間
で約定を成立させて、その約定を約定マスタテーブル１
２５に登録する。

【００９５】ディーラ端末３１から矢面注文が入力され
た場合には、仲介サーバ１０は、図４のステップS15の
マッチング処理へ進み、入力された矢面注文と約定可能
な取引条件をもった指定取引相手からの岩陰注文を見つ
け出し、両者を出会わせる。続いて、仲介サーバ１０
は、図４のステップS18の約定処理へ進み、マッチング
で出会った２つの注文の間で約定を成立させて、その約
定を約定マスタテーブル１２５に登録する。

【００９６】なお、上述した図４のステップS14〜S18の
処理は、図２に示した注文約定プロセス１０６に対応す
る。

【００９７】図４に示したオープンネーム取引の仲介業
務において、ステップS22のリアルタイム配信プロセ
ス、ステップS23の照会プロセス、ステップS19の約定取
消プロセス、ステップS20のOERプロセス及びステップS1
1のログアウト処理の動作は、図３に示したマーケット
取引の仲介業務における対応プロセスの動作とほぼ同じ
である。

【００９８】以上、図３、図４を参照して説明した流れ
が、仲介サーバ１０が行なう仲介業務の全体的な処理流
れである。次に、この仲介業務を構成する個々のプロセ
スの流れや使用するウィンドウの構成について、より詳
細且つ具体的に説明する。

【００９９】まず、図３、図４にステップS3で示した初
期設定プロセスについて説明する。

【０１００】図６〜図９は、初期設定プロセスにおいて
仲介サーバ１０がディーラ端末３１及びバックオフィス
端末３２のディスプレイ画面に表示する幾つかのウィン
ドウを示す。図６〜図９に示したウィンドウは、図５に
示したメインウィンドウ２００のメニューバー２０１内
の「初期設定」メニューを操作することで表示される。

【０１０１】図６は、環境設定ウィンドウ９００を示
す。

【０１０２】図６に示すように、環境設定ウィンドウ９
００では、領域９０１において資金を運用する場合につ
いて、領域９０３において資金を調達する場合につい
て、上限アマウント（注文を出すときに指定するアマウ
ントの上限額）や、ネームグループ表示（自社が注文を
発するときに指定できる取引相手となり得る金融機関の
グループのデフォルト名）や、約束手形を受領したいか
否か、などが設定される。また、領域９０６及び９０７
では、それぞれ、取引開始時と取引終了時の決済に用い
る銀行口座のデフォルト名称が設定される。また、領域
９０４では、注文に発するときに指定されるアマウン
ト、ロット及び刻み幅のデフォルト値が設定される。領
域９０５では、図１や図２に示した短資取引約定確認シ
ステム４０を利用するか否かが設定される。領域９０９
では、図２（具体例は図１４）に示したHQ表示切替ウィ
ンドウ７００内にあるオープンネーム取引の取引相手を
選択するための金融機関名称リスト（図１４、７０４）
において、先頭の方に優先的に表示する金融機関名称が
設定される。

【０１０３】図７は、決済口座登録ウィンドウ９２０を
示す。

【０１０４】図６に示した環境設定ウィンドウ９００内
の登録画面ボタン９１０を操作することで、図７に示す
決済口座登録ウィンドウ９２０が開かれる。この決済口
座登録ウィンドウ９２０では、取引の決済に使用する銀
行口座を複数設定できる。

【０１０５】図８は、ホットクォーツ（HQ）反映先選択
ウィンドウ９３０を示す。

【０１０６】このHQ反映先選択ウィンドウ９３０では、
図２（具体例は、図１１〜図１３）に示したホットクォ
ーツウィンドウ３００に表示されるべき注文の発信元の
金融機関を複数選択できる。つまり、コール市場に参加
している多数の金融機関の中から、自社に向けた注文を
出してもらってよい（自社の取引相手となってよい）金
融機関を複数選択できる。領域９３１では、オファー側
の金融機関が選択でき、領域９３２ではビッド側の金融
機関が選択できる。ここで設定された金融機関から発さ
れた注文だけが、自社のディーラ端末３１のホットクォ
ーツウィンドウ３００に表示されることになる。

【０１０７】図９は、グループ設定ウィンドウ９４０を
示す。

【０１０８】このグループ設定ウィンドウ９４０では、
任意の名称（図９の例では、「G1」、「G2」、「G3」、
「普通銀行」、「都銀」、「信託銀行」など）の金融機
関グループを設定し、それぞれのグループに図８で選択
した設定した金融機関を任意に割り振ることができる。
領域９４１では、自社が資金を運用する場合に関して、
領域９４２では、自社が資金を調達する場合に関して、
金融機関グループが設定できる。ここで設定されたグル
ープは、図６に示した領域９０１、９０３のネームグル
ープ表示（自社が注文を発するときに指定できる取引相
手となり得る金融機関のグループのデフォルト名）の選
択対象になる。

【０１０９】次に、図3のステップS4以降、及び図4のス
テップS14以降の流れに含まれる諸処理について説明す
る。

【０１１０】まず、これらの処理においてディーラ端末
３１に表示される図５に示したメインウィンドウ２００
内の各種サブウィンドウ３００〜７００について説明す
る。

【０１１１】図１０〜図１３は、ホットクォーツ（HQ）
ウィドウ３００の幾つかの具体例を示す。

【０１１２】図１０は、マーケット取引用のホットクォ
ーツ（HQ）ウィンドウ３１０を示す。

【０１１３】マーケット取引用のホットクォーツ（HQ）
ウィンドウ３１０には、マーケット取引のコール市場に
存在する他の金融機関から発された注文のうち、自社が
初期設定プロセスの図８に示したHQ反映先選択画面で選
択した金融機関から発されたマーケット取引の注文（図
８のオファーサイド領域９３１で選択した金融機関から
のマーケット取引のオファーと、ビッドサイド領域９３
２で選択した金融機関からのマーケット取引のビッド）
だけが、表の形で一覧に表示される。各ターム毎に注文
のサイド、レート（Offer又はbidのカラムに表示され
る）、アマウントなどの取引条件の要約が表示される
（図１０の例では、表内の各行に、各タームをもつオフ
ァーのベストレートとそのベストレートのアマウントの
合算値、及び同じタームをもつビッドののベストレート
とそのベストレートのアマウントの合算値が表示されて
いる）。

【０１１４】図１１は、オープンネーム取引の受け手
（岩陰注文を発するとき）のためのホットクォーツ（H
Q）ウィンドウ３２０を示す。

【０１１５】このホットクォーツ（HQ）ウィンドウ３２
０には、後述の図１４に例示するHQ表示切替ウィンドウ
７００内の金融機関リスト７０４から選択した一つの金
融機関から自社に向けて発されたオープンネーム取引の
注文が一覧に表示される。各注文毎に、ターム、サイ
ド、レート（Offer又はbidのカラムに表示される）、ア
マウントなどが表示される。

【０１１６】図１２は、オープンネーム取引のプレゼン
タ（矢面注文を発するとき）のためのホットクォーツ
（HQ）ウィンドウ３３０を示す。

【０１１７】このホットクォーツ（HQ）ウィンドウ３３
０には、自社が過去に発した矢面注文であって、まだ約
定に至ってない（つまり、まだコール市場に存在してい
る）ものが一覧に表示される。各注文毎に、ターム、サ
イド、レート（Offer又はbidのカラムに表示される）、
アマウントなどが表示される。

【０１１８】図１０〜図１２に示した３種類のホットク
ォーツ（HQ）ウィンドウ３１０〜３３０は、後述する図
１４に具体例を示したHQ表示切替ウィンドウ１４に対す
るマウスクリックなどの操作によって、選択的に切替え
て表示させることができる。

【０１１９】図１３は、「コンポジットHQウィンドウ」
と呼ばれるホットクォーツ（HQ）ウィンドウ３４０を示
す。

【０１２０】このコンポジットHQウィンドウ３４０は、
図１０〜図１２に示したホットクォーツ（HQ）ウィンド
ウ３１０〜３３０のいずれかにおいて、ディーラが、興
味のある特定のタームをマウスクリックなどで選択した
上で、例えばマウスの右クリックでメニューリストを表
示させ、そのメニューリストから「コンポジットHQウィ
ンドウの表示」のようメニューを選択することで、表示
することができる。図１３に示すように、コンポジット
HQウィンドウ３４０では、領域３４１に、上記選択され
た特定のタームをもつマーケット取引のホットクォーツ
の中で、自社にとり最も有利なレートをもった注文が表
示される。また、領域３４２には、上記選択された特定
のタームをもつオープンネーム取引の自社宛てのホット
クォーツが一覧表示される。このコンポジットHQウィン
ドウ３４０によれば、ディーラは、マーケット取引及び
オープンネーム取引という異なった取引形態の枠を越え
て、コール市場の全体から、自社にとって一番有利な取
引条件をもった注文を、いち早く見つけ出すことができ
る。

【０１２１】図１４は、図５のメインウィンドウ２００
内のHQ表示切替ウィンドウ７００の具体例を示す。

【０１２２】HQ表示切替ウィンドウ７００には、マーケ
ットボタン７０１、プレゼンタ（Presenter）ボタン７
０２、新規注文ボタン７０３、及び金融機関リスト７０
４がある。マーケットボタン７０１をマウスクリックな
どで操作すると、図５に示したメインウィンドウ２００
内のホットクォーツウィンドウ３００の内容が、図１０
に示したマーケット取引用のホットクォーツウィンドウ
３１０になる。プレゼンタボタン７０２をマウスクリッ
クなどで操作すると、ホットクォーツウィンドウ３００
の内容が、図１２に示したオープンネーム取引のプレゼ
ンタ用のホットクォーツウィンドウ３３０になる。金融
機関リスト７０４内の一つの金融機関名をマウスクリッ
クなどで選択すると、ホットクォーツウィンドウ３００
の内容が、図１１に示したオープンネーム取引の受け手
用のホットクォーツウィンドウ３２０になる。また、新
規注文ボタン７０３をマウスクリックなどで操作する
と、ホットクォーツウィンドウ３００の内容に応じて、
マーケット取引の注文、オープンネーム取引の岩陰注文
又は矢面注文を仲介サーバ１０に発することができるよ
うになる（具体例は後述する）。

【０１２３】図１５は、図５に示したメインウィンドウ
２００内の市場情報詳細ウィンドウ４００の具体例を示
す。

【０１２４】市場情報詳細ウィンドウ４００では、領域
４０１に示されたタームをもつマーケット取引及びオー
プンネーム取引に関して、マーケット取引のコール市場
に存在する全ての注文と当日成立した約定に関する全体
的な情報が表示される。すなわち、領域４０２には、市
場中で最も有利な方の条件（レート）をそれぞれもつオ
ファーとビッドのレートとアマウントと個数が表示され
る。領域４０３には、当日成立した約定の最高と最低の
レートが示される。領域４０５には、当日の最近に成立
した５つの約定のレート、アマウント、約定時刻などが
表示される。市場情報詳細ウィンドウ４００によれば、
市場全体の現在の様子や動きが把握できる。

【０１２５】図１６及び図１７は、図５に示したメイン
ウィンドウ２００内の自己注文状況ウィンドウ５００の
具体例を示す。図１６及び図１７に示すように、自己注
文状況ウィンドウ５００内にはマーケット取引用のペー
ジ５１０とオープンネーム取引用のページ５２０があ
る。

【０１２６】図１６は、自己注文状況ウィンドウ５００
内のマーケット取引用のページ５１０を前面に表示した
例を示す。このページ５１０には、自社が発したマーケ
ット取引の注文の取引条件や現在のステータス（まだ出
会いがない、予約オンなど）が表示される。

【０１２７】図１７は、自己注文状況ウィンドウ５００
内のオープンネーム取引用のページ５２０を前面に表示
した例を示す。このページ５２０には、自社が発したオ
ープンネーム取引の注文の取引条件や現在のステータス
（まだ出会いがない、予約オンなど）が表示される。

【０１２８】図１８及び図１９は、図５に示したメイン
ウィンドウ２００内の約定履歴ウィンドウ６００の具体
例を示す。図１８及び図１９に示すように、約定履歴ウ
ィンドウ６００内には約定履歴を示すページ６１０とオ
ープンエンドロール交渉のスケジュールを示すページ６
２０がある。

【０１２９】図１８は、約定履歴ウィンドウ６００内の
約定履歴を示すページ６１０を前面に表示した例を示
す。このページ６１０には、自社が現在有している当日
に約定された全ての約定結果が一覧に表示される。各約
定毎に、確認（双方の当事者の二次コンファーム）が済
んでいるか否か、取引条件、取引相手及びOERの交渉結
果の状況（解約、有効など）、などの諸情報が表示され
る。

【０１３０】図１９は、約定履歴ウィンドウ６００内の
オープンエンドロール交渉のスケジュールを示すページ
６２０を前面に表示した例を示す。このページ６２０に
は、自社が現在有している全てのオープンエンド取引の
うち、取引終了日選択ボタン６２３、６２４、６２５で
選択された日（今日（TODAY）、翌営業日（TOM）又は翌
々営業日（SPOT））までにオープンエンドロール交渉を
行なうべき約定が一覧に表示される。各約定ごとに、現
在のステータス（交渉中か否かなど）、サイド、取引相
手、前回の取引条件、などの諸情報が表示される。

【０１３１】以上、図１０〜図１９を参照して、仲介サ
ーバ１０がディーラ端末３１に表示するメインウィドウ
２００の構成の具体例を説明した。以下では、このメイ
ンウィンドウ２００を用いて行なわれる取引仲介の細か
い手順を説明する。

【０１３２】図２０は、マーケット取引の注文から約定
までの、主に、ディーラがディーラ端末３１を用いて行
なう作業手順を示している。図２１は、マーケット取引
の注文から約定までの、主に、仲介サーバ１０が行なう
データ処理手順を示している。

【０１３３】マーケット取引の注文を発する場合、ディ
ーラはディーラ端末３１に表示されたメインウィンドウ
２００（図５）内のHQ表示切替ウィンドウ７００（図１
４）で、マーケットボタン７０１をマウスクリックす
る。すると、図２０にステップS３１で示すように、マ
ーケット取引用のホットクォーツウィンドウ３１０（図
１０）がメインウィンドウ２００（図５）内に表示され
る。

【０１３４】次にディーラは、図２０のステップS32
で、マーケット取引用のホットクォーツウィンドウ３１
０（図１０）内から、希望のタームをマウスのダブルク
リックなどで選択する。すると、メインウィンドウ２０
０（図５）の上に、マーケット取引の注文を入力するた
めの注文ウィンドウがポップアップする。図２２は、マ
ーケット取引用の注文ウィンドウ１００の具体例を示し
ている。

【０１３５】或いは、ディーラは、図２０のステップS3
1の後、図２０のステップS33に進み、HQ表示切替ウィン
ドウ７００（図１４）内の新規注文ボタン７０３をマウ
スクリックしてもよい。すると、同様に、図２２に例示
したような注文ウィンドウ１０００がポップアップす
る。

【０１３６】図２２に示すように、ポップアップした当
初のマーケット取引用の注文ウィンドウ１０００には、
項目設定ページ１０１０が前面に表示されている。この
項目設定ページ１０１０では、ボタン１０１１から１０
１６によりサイド（オファーかビッドか）が設定でき、
領域１０１７でアマウント（希望最高取引金額）、ロッ
ト（最低取引金額）、レート、刻み幅、オープンエンド
か否かなどの取引条件が設定でき、領域１０１８及び１
０１９で取引開始時と取引終了時に使用する決済口座な
どを設定することができる。

【０１３７】なお、ボタン１０１１〜１０１３はオファ
ーを出すときに選択できるボタンであり、この３つのど
のボタンを選択するかで、マッチング処理で出会うこと
になるビッドが違ってくる。すなわち、Offerボタン１
０１１を選択すると、最初に選んだタームにおいて、こ
のページで設定したアマウント、ロット、レート及び刻
み幅に関する注文をコール市場に一旦投入することにな
り、この注文にマッチしたビッドとのみ出会うことにな
る。Yoursボタン１０１２を選択すると、タームで一致
すると共に、このページで設定したアマウント、ロッ
ト、レート及び刻み幅について取引条件がマッチしたビ
ッドと直に出会うことになる。また、AllY(All Yours)
ボタン１０１３を選択すると、タームで一致すると共
に、このページで設定したロット、レート及び刻み幅に
ついてのみマッチした全てのビッドと直に出会うことに
なる。

【０１３８】また、ボタン１０１４〜１０１６はビッド
を出すときに選択できるボタンであり、この３つのどの
ボタンを選択するかで、マッチング処理で出会うことに
なるオファーが違ってくる。すなわち、Bidボタン１０
１４を選択すると、タームで一致すると共に、このペー
ジで設定したアマウント、ロット、レート及び刻み幅に
関する注文をコール市場に一旦投入することになり、こ
の注文とマッチしたオファーとのみ出会うことになる。
Mineボタン１０１５を選択すると、タームで一致すると
共に、このページで設定したアマウント、ロット、レー
ト及び刻み幅について取引条件がマッチしたオファーと
直に出会うことになる。また、AllM(AllMine)ボタン１
０１６を選択すると、タームで一致すると共に、このペ
ージで設定したロット、レート、刻み幅についてのみマ
ッチした全てのオファーと直に出会うことになる。

【０１３９】図２２に示した注文ウィンドウ１０００に
おいて、「ネーム選択」タグをクリックすると、図２３
に例示するようなネーム選択ページ１０２０が表示され
る。図２３に示したネーム選択ページ１０２０では、注
文が向けられる相手先の金融機関を限定することができ
る。すなわち、図２３に示すように、領域１０２１で相
手先の金融機関グループ（初期設定プロセスのグループ
設定ウィンドウ９４０（図９）で設定した金融機関グル
ープの中の任意のグループ）を選択し、領域１０２２
で、その選択したグループに属する個々の金融機関にチ
ェックマークをつけることで、相手先の金融機関を指定
することができる。注文を発した場合、その注文は、図
２３のネーム選択ページ１０２０で限定した金融機関以
外の金融機関のディーラ端末３１のホットクォーツウィ
ンドウには掲示されないことになる。

【０１４０】図２２及び図２３に示した注文ウィンドウ
１０００に注文の取引条件や決済口座や相手先グループ
などの事項を設定した後、この注文ウィンドウ１０００
内のONボタン１０３０をマウスクリックすると、その設
定された内容をもった注文が仲介サーバ１０へ送られ
る。これが、図２０に示すステップS34であり、また、
図２１に示すステップS51（オファーの入力）又はS54
（ビッドの入力）である。

【０１４１】図２１に示すように、ステップS51又はS54
でマーケット取引の注文が入力されると、仲介サーバ１
０は、ステップS52又はS55で、その入力された注文をデ
ータベース内の注文マスタテーブル１２４（図３）に登
録する。また、図２０に示すように、仲介サーバ１０
は、ステップS34で注文が入力されると、直ちにステッ
プS35で、その入力された注文の表示を、その注文を入
力したディーラ端末３１に表示される自己注文状況ウィ
ンドウ５００内のマーケット取引用のページ５１０（図
１６）、及び、その注文が向けられた相手先の金融機関
のディーラ端末３１に表示されるマーケット取引用のホ
ットクォーツウィンドウ３１０（図１０）に追加する。
これにより、相手先のディーラは、自社向けのマーケッ
ト取引の注文が市場に投入されたことをリアルタイムで
知ることができる。

【０１４２】続いて、仲介サーバ１０は、図２０に示す
ステップS36及び図２１に示すステップS56で、今入力さ
れたマーケット取引の注文と、それとは別の金融機関か
ら既に入力されているカウンターサイドの関係にあるマ
ーケット取引の注文との間でマッチング処理を行なう。
このマッチング処理（詳細は後に説明する）では、今注
文を入力したディーラ端末３１のマーケット取引用のホ
ットクォーツウィンドウ３１０(図１０)に表示されてい
る注文の中で、今入力された注文とカウンターサイドの
関係にあり且つ少なくとも業務条件（ターム、レート、
短資取引約定システムの参加有無、約束手形発行希望有
無など）が一致するものが選ばれる。そして、その選ば
れた注文と今入力された注文との間で、それぞれの金額
条件（ロット、刻み幅、アマウント）に基づいて、両注
文間に共通の取引金額が存在するか否かがチェックされ
る。その結果、共通の取引金額が存在すれば、両注文は
出会った（マッチした）ということになる。今入力され
た注文は、複数のカウンターサイドの注文と出会う可能
性がある。

【０１４３】マッチング処理によって２つの注文が出会
うと、次に、仲介サーバ１０は、図２１にステップS58
で示すように、その出会った注文を発した双方の金融機
関のうちのオファー側のディーラ端末３１に対して、ビ
ッド側の金融機関のクレジットライン(与信枠)のチェッ
ク（ラインチェック）を行なうための情報を送る。それ
により、図２０でステップS37及び図２１でステップS59
で示すように、そのオファー側のディーラ端末３１のメ
インウィンドウ２００（図５）上に、図２４に例示する
ようなラインチェックウィンドウ１１００がポップアッ
プする。このとき、ビッド側のディーラ端末３１では、
図２０でステップS39で示すように、自己注文状況ウィ
ンドウ５００のマーケット取引用ページ５１０(図１６)
に表示されている当該ビットのステータスが「チェック
中」となる。

【０１４４】図２４に示すように、オファー側のディー
ラ端末３１に表示されるラインチェックウィンドウ１１
００には、ターム、レート、ロット、刻み幅、アマウン
ト、カウンターサイド（つまり、ビッド側）の金融機関
名、処理件数（複数のビッドと出会った場合に、その中
の何番目のビッドを今チェックしているか）、タイムリ
ミット、取引開始日時、取引終了日時、及び約定可能金
額などが表示される。さらに、このラインチェックウィ
ンドウ１１００には、約定を成立させるためのDoneボタ
ン１１０１及び約定を拒否するためのNGボタン１１０２
がある。

【０１４５】ラインチェックウィンドウ１１００におい
て、タームとレートは、当然ながら、出会った両注文間
で共通するものであるが、ロットと刻み幅は、ビッド側
の値である。アマウントは、約定する場合の取引金額で
あり、約定可能金額を上限とし、ビッド側のロットを下
限として、オファー側が自由に設定できる。

【０１４６】ラインチェックウィンドウ１１００内の約
定可能金額は、出会った両注文がそれぞれもつ金額条件
（ロット、刻み幅、アマウント）を基にマッチング処理
で計算された、その両注文間で一致した取引金額の最大
値である。例えば、オファーの金額条件がロット２００
億円、刻み幅５０億円、アマウント６００億円であり、
ビッドの金額条件がロット３００億円、刻み幅１００億
円、アマウント１０００億円であったならば、両注文
は、３００、４００、５００、６００億円で一致するこ
とになるが、その一致金額のうちの最大値６００億円が
約定可能金額になる。

【０１４７】タイムリミットは、ラインチェックを行な
うためにオファー側ディーラに許された制限時間（例え
ば、3分）のうちの残り時間である。もし、このタイム
リミットがゼロになるまでにDoneボタン１１０１が押さ
れなければ、自動的に約定は拒否されたものとみなされ
る。

【０１４８】オファー側のディーラは、上記のラインチ
ェックウィンドウ１１００上で、約定を成立させる否か
を判断し、成立させるならばDoneボタン１１０１が押
し、拒否するならばNGボタン１１０２を押す。その判断
の基準は、主として、自社がカウンターサイド（つま
り、ビッド側）の金融機関に対して現在与えているクレ
ジットラインが、この条件で取引するのに十分であるか
否かということである。

【０１４９】すなわち、現在のビッド側のクレジットラ
インが、ラインチェックウィンドウ１１００に表示され
たロット（ビッド側が出した最低取引金額）を下回って
いれば、オファー側ディーラは約定を拒否するであろ
う。一方、現在のビッド側のクレジットラインが、ライ
ンチェックウィンドウ１１００に表示されたロット以上
で約定可能金額未満であれば、オファー側ディーラはお
そらく、ラインチェックウィンドウ１１００に表示され
たアマウント（約定するときの取引金額）をビッド側の
クレジットラインを超えない値（典型的には、クレジッ
トラインと等しい値）に設定した上で、約定を成立させ
るであろう。また、現在のビッド側のクレジットライン
が、ラインチェックウィンドウ１１００に表示された約
定可能金額以上であれば、オファー側ディーラは、ライ
ンチェックウィンドウ１１００に表示されたアマウント
を約定可能金額にした状態で、約定を成立させるであろ
う。

【０１５０】このようにしてオファー側ディーラはライ
ンチェックウィンドウ１１００上で約定を成立させるか
拒否するかを判断して、図２１にステップS60で示すよ
うに、Doneボタン１１０１又はNGボタン１１０２を押
す。Doneボタン１１０１が押されれば、仲介サーバ１０
は、図２０でステップS38及びステップS40で示すよう
に、また、図２１でステップS61及びステップS62で示す
ように、ラインチェックウィンドウ１１００に表示され
たアマウントを約定金額として確定して、その出会った
注文間で約定を成立させる。

【０１５１】また、仲介サーバ１０は、図２１でステッ
プS57で示すように、上記ラインチェックの結果に応じ
て、その出会った注文のうちのオファーに関して、再マ
ッチング防止情報を作成して（詳細は後に説明する）、
データベース内の注文マスタテーブル１２４（図３）に
保存する。この再マッチング防止情報は、オファー側金
融機関がビッド側金融機関に現在与えているクレジット
ラインの、上述のラインチェックの結果に基づく推測値
を表したものである。この再マッチング防止情報は、図
２１に示すように、今後、再び同じ金融機関が発したオ
ファーについてマッチング処理が行なわれる際、どの金
融機関のどのビッドと出会わせるかというカウンターサ
イドの注文の取捨選択に利用される。その目的は、ビッ
ド側金融機関のクレジットライが不足しているためにラ
インチェックで約定が拒否されるという事態を回避する
ことにある。再マッチング防止情報を作成してマッチン
グで利用するためのアルゴリズムの詳細は後に説明す
る。

【０１５２】約定が成立すると、仲介サーバ１０は、図
２０にステップS41で示すように、その成立した約定の
双方の当事者のディーラ端末３１に表示されている約定
履歴ウィドウ６００の約定履歴ページ６１０（図１８）
に、その成立した約定の表示を追加する。また、成立し
た約定の約定金額が、その約定にかかる注文のアマウン
トと等しい場合には、その注文は消滅したことになるの
で、仲介サーバ１０は、その注文が向けられた先のディ
ーラ端末３１のマーケット取引用のホットクォーツウィ
ンドウ３１０（図１０）、及びその注文を発したディー
ラ端末３１の自己注文ウィンドウ５００内のマーケット
取引用のページ５１０（図１６）から、直ちにその注文
の表示を削除する。また、成立した約定の約定金額が、
その約定にかかる注文のアマウントに満たない場合に
は、仲介サーバ１０は、図２０にステップS42で示すよ
うに、その注文のアマウントから約定金額を差し引いた
残額をその注文の新たなアマウントに設定して、その注
文が向けられた先のディーラ端末３１のマーケット取引
用のホットクォーツウィンドウ３１０（図１０）上、及
びその注文を発したディーラ端末３１の自己注文ウィン
ドウ５００内のマーケット取引用のページ５１０（図１
６）上の、その注文の表示を直ちに更新する。

【０１５３】図２５は、上述したマッチング処理（図２
０のステップS36、図２１のステップS56）の流れを示
す。

【０１５４】図２５に示すように、ステップS71で、或
るディーラ端末３１からマーケット取引の新たな注文が
入力されるか、又は、既に入力済みの注文が修正される
（前述したように、その注文のアマウントに満たない約
定金額で約定が成立すると、その約定金額分だけアマウ
ントが減少するし、また、ディーラが故意に取引条件を
変更する場合もある）ことで、その入力又は修正された
注文（以下、「着目注文」という）に関してマッチング
処理が開始される。

【０１５５】マッチング処理は、まず、ステップS72
で、その着目注文の入力元であるディーラ端末３１のマ
ーケット取引用のホットクォーツウィンドウ３１０（図
１０）に表示されている注文群の中から、その着目注文
とカウンターサイドの関係（オファーとビッドの関係）
にあって且つ互いに業務条件（タームとレート）が一致
するものを、「出会い候補」としてピックアップする。

【０１５６】着目注文がオファーである場合、マッチン
グ処理はステップS73へ進む。着目注文がビッドである
場合、マッチング処理はステップS74へ進む。

【０１５７】着目注文がオファーであってマッチング処
理がステップS73に進むと、その着目注文（オファー）
に「再マッチング防止情報」が付いているか否かが調べ
られる。そして、次のような処理が行なわれる。

【０１５８】(1) その着目オファーに再マッチング防
止情報が付いていない場合には、ステップS72でピック
アップされた出会い候補はそのまま維持される。

【０１５９】(2) その着目オファーに再マッチング防
止情報が付いている場合には、その再マッチング防止情
報に基づいて、ステップS72でピックアップされた出会
い候補（全てビッド）の絞込みが次のように行なわれ
る。ここで、再マッチング防止情報には「相手機関」と
「数値」が含まれている。

【０１６０】(2-1) 上記出会い候補の内、上記「相手
機関」とは異なる金融機関から発されたビッドは、その
まま出会い候補として維持される。

【０１６１】(2-2) 上記出会い候補の内、上記「相手
機関」と同じ金融機関から発されたビッドについては、
上記「数値」以上のロットをもつビッドが排除され、上
記「数値」以上のロットをもつビッドのみが、出会い候
補として維持される。

【０１６２】他方、着目注文がビッドであってマッチン
グ処理がステップS74に進むと、ステップS72でピックア
ップされた出会い候補（全てオファー）に「再マッチン
グ防止情報」が付いているか否かが調べられる。そし
て、出会い候補の絞込みが次のように行なわれる。

【０１６３】(1) 再マッチング防止情報が付いていな
い出会い候補は、そのまま維持される。

【０１６４】(2) 再マッチング防止情報が付いている
出会い候補であって、その再マッチング防止情報に含ま
れる「相手機関」がいずれも、着目注文(ビッド)を発し
た金融機関と異なっているものは、そのまま維持され
る。

【０１６５】(3) 再マッチング防止情報が付いている
出会い候補であって、その再マッチング防止情報に含ま
れる「相手機関」が、着目ビッドを発した金融機関と一
致しているものについては、次に、その再マッチング防
止情報の「数値」と着目ビッドのロットが比較される。
そして、上記「数値」が着目ビッドのロットより大きい
出会い候補（オファー）のみが維持され、上記「数値」
が着目ビッドのロット以下である出会い候補（オファ
ー）は排除される。

【０１６６】上記ステップS73又はS74の後、マッチング
処理は、ステップS75へ進む。ここでは、上記ステップS
73又はS74で絞り込まれた出会い候補の中から、条件の
良い順に（例えば、発注時刻の早い順に）、一つづつ出
会い候補が選択される。そして、選択された出会い候補
について、ステップS76以下の処理が行なわれる。

【０１６７】ステップS76では、着目注文と選択された
出会い候補とがそれぞれもつ金額条件（ロット、刻み幅
及びアマウント）に基づいて、着目注文と選択された出
会い候補の間に一致する取引金額が存在するか否かが調
べられる。例えば、着目注文の金額条件がロット２００
億円、刻み幅５０億円、アマウント６００億円であり、
出会い候補の金額条件がロット３００億円、刻み幅１０
０億円、アマウント１０００億円であったならば、両注
文間には３００、４００、５００、６００億円という一
致した取引金が存在する。このように一致した取引金額
が存在するならば、そのうちの最大金額を約定可能金額
（図２４のラインチェックウィンドウ１１００に表示さ
れるもの）とする。上の例では、６００億円が約定可能
金額である。

【０１６８】マッチング処理はステップS77へ進み、上
記ステップS76で約定可能金額が得られた場合には、そ
の選択された出会い候補を正式な出会い相手として採用
する（つまり、その候補は着目注文と出会った(マッチ
した)ことになる）。マッチング処理はステップS75へ戻
って、次順の出会い候補を選択してステップS76を再び
行う。一方、上記ステップS76で約定可能金額が得られ
ない場合（つまり、一致した取引金額が存在しない場
合）には、マッチング処理は直ちにステップS75へ戻っ
て、次順の出会い候補を選択してステップS76を再び行
う。

【０１６９】上記ステップS75及びステップS76が全ての
出会い候補について終わると、マッチング処理はステッ
プS79へ進み、ステップS78で採用された出会い相手を、
条件の良い順に一つづつ選んで、着目注文とのラインチ
ェック（図２０のS37、図２１のS58〜S59、図２４）を
行なう。

【０１７０】図２６は、上述した再マッチング防止情報
を作成する処理（図２１のS57）の流れを示す。

【０１７１】図２６に示すように、ステップS81でライ
ンチェック（図２０のS37、図２１のS58〜S59、図２
４）が行なわれ、ラインチェックの結果が出ると、ステ
ップS82で、そのラインチェック結果が「Done」(約定成
立)か「NG」（約定拒否）かが調べられる。ラインチェ
ック結果が「Done」(約定成立)であった場合には、さら
にステップS84で、その約定金額（図２４のラインチェ
ックウィンドウ１１００内の「アマウント」）が約定可
能金額であったかそれ以下であったかが調べられる。

【０１７２】上記ステップS82の結果、ラインチェック
結果が「NG」（約定拒否）であった場合には、ステップ
S83で再マッチング防止情報が作成される。ここでは、
再マッチング防止情報の「相手機関」に、そのラインチ
ェックを受けたビッド側の金融機関が設定される。ま
た、再マッチング防止情報の「数値」には、そのライン
チェックを受けたビッドが持つロットが設定される。

【０１７３】このステップS83で作成された再マッチン
グ防止情報は、次のような実質的意味をもつ。すなわ
ち、そのラインチェックを行なったオファー側の金融機
関がビッド側の金融機関（＝「相手機関」）に対して与
えているクレジットラインは、そのビッドがもっている
ロット（＝「数値」）に満たない。このケースでは、も
し、ビッド側の金融機関がそのビッドのロット以上のク
レジットラインをもっていたならば、ラインチェック結
果は「NG」にはならなかった筈だからである。

【０１７４】上記ステップS84で、成立した約定金額
（図２４のラインチェックウィンドウ１１００内の「ア
マウント」）が約定可能金額より低かったならば、ステ
ップS85で再マッチング防止情報が作成される。ここで
は、再マッチング防止情報の「相手機関」に、そのライ
ンチェックを受けたビッド側の金融機関が設定される。
また、再マッチング防止情報の「数値」には、「−１」
が設定される。

【０１７５】このステップS85で作成された再マッチン
グ防止情報は、次のような実質的意味をもつ。すなわ
ち、そのラインチェックを行なったオファー側の金融機
関がビッド側の金融機関（＝「相手機関」）に対して与
えているクレジットラインはゼロ（＝「−１」）であ
る。このケースでは、今成立した約定金額が約定可能金
額（約定金額がとり得る最大値）より低いわけであるか
ら、そのラインチェックの時点でビッド側の金融機関が
もっていたクレジットラインは、その約定金額に等しか
ったと推測され、よって、今成立した約定において、そ
のクレジットラインは全て使い尽くされたと推定される
からである。

【０１７６】上記ステップS84で、成立した約定金額
（図２４のラインチェックウィンドウ１１００内の「ア
マウント」）が約定可能金額（約定金額がとり得る最大
値）と等しかったならば、ステップS87で再マッチング
防止情報は作成されない。

【０１７７】再マッチング防止情報が作成されないとい
うことは、次のような実質的意味をもつ。すなわち、そ
のラインチェックを行なったオファー側の金融機関がビ
ッド側の金融機関に対して与えているクレジットライン
は不明ではあるが、かなり大きいと思われる。このケー
スでは、今成立した約定金額が約定可能金額（約定金額
がとり得る最大値）と一致していたわけであるから、そ
のラインチェックの時点でビッド側の金融機関がもって
いたクレジットラインは、その約定可能金額を超えてい
たと推測されるからである。

【０１７８】上記ステップS83又はS84で再マッチング防
止情報が作成されると、ステップS86で、その再マッチ
ング防止情報は、上記ラインチェックを行なったオファ
ー側金融機関から既に出されているオファーであって、
上記ラインチェックを受けたビッド側金融機関から出さ
れているビッドと出会う可能性がある（つまり、そのオ
ファーが入力される際に図２３の注文ウィンドウ１００
０のネーム選択ページで、そのビッド側金融機関が選択
されていた）オファーの全てに対して、その再マッチン
グ防止情報が添付される。

【０１７９】以上のように作成されオファーに添付され
た再マッチング防止情報は、前述した図２５のマッチン
グ処理においてステップS73及びS74で出会い候補の絞込
みに利用されることにより、クレジットライン不足で約
定が破談になるおそれのある注文同士が出会う可能性が
低減される。

【０１８０】以上、マーケット取引の注文から約定まで
の仲介業務を詳細に説明した。

【０１８１】次に、オープンネーム取引の注文から約定
までの仲介業務を詳細に説明する。

【０１８２】図２７は、オープンネーム取引における矢
面注文から約定までの流れを示す。

【０１８３】図２７に示すように、ステップS91で、金
融機関のディーラはディーラ端末３１のメインウィンド
ウ２００内のHQ表示切替ウィンドウ７００(図１４)にお
いて、「Presenter」ボタン７０２を押す。すると、仲
介サーバ１０は、そのディーラ端末３１のメインウィン
ドウ２００内のホットクォーツウィンドウ３００に、プ
レゼンタ用のホットクォーツウィンドウ３３０（図１
２）を表示する。このプレゼンタ用のホットクォーツウ
ィンドウ３３０（図１２）には、そのディーラ端末３１
から過去に入力された矢面注文でまだ有効に残っている
ものが一覧に表示される。

【０１８４】次にディーラが、ステップS92に示すよう
に、そのプレゼンタ用のホットクォーツウィンドウ３３
０（図１２）の中から、希望のタームをマウスのダブル
クリックなどで選択すると、メインウィンドウ２００の
上に、図２８に例示するようなオープンネーム取引用の
注文ウィンドウ１２００がポップアップする。このと
き、ポップアップしたオープンネーム取引用の注文ウィ
ンドウ１２００内の項目設定ページ１２１０には、先ほ
ど選択したタームがエントリされている。

【０１８５】或いは、ディーラが、プレゼンタ用のホッ
トクォーツウィンドウ３３０（図１２）を表示した上
で、ステップS93に示すように、HQ表示切替ウィンドウ
７００(図１４)内の「新規注文」ボタン７０３をマウス
クリックした場合にも、図２８に例示するようなオープ
ンネーム取引用の注文ウィンドウ１２００がポップアッ
プする。

【０１８６】次に、ディーラは、図２７でステップS94
に示すように、図２８に例示したオープンネーム取引用
の注文ウィンドウ１２００上で、オファーを出すのかビ
ッドを出すのかを選ぶ。

【０１８７】続いて、オファーを出す場合には、ディー
ラは、図２７にステップS95で示すように、図２８に例
示したオープンネーム取引用の注文ウィンドウ１２００
内の項目設定ページ１２１０にアマウント、ロット、レ
ート、刻み幅などの取引条件をエントリし、さらに、図
２９に例示したオープンネーム取引用の注文ウィンドウ
１２００内のネーム選択ページ１２２０で、そのオファ
ーの送り先（取引相手）の金融機関を１つ又は複数選択
するとともに、選択した各金融機関ごとに、自社がその
金融機関に与えているクレジットラインの数値をエント
リする。図２９の例では、「ライン」のコラムに表示さ
れている数値がクレジットラインであり、例えば「１０
００」は１０００億円であり、「＊」はオファーのアマ
ウントと同額を意味する。

【０１８８】また、ビッドを出す場合には、ディーラ
は、図２７にステップS96で示すように、図２８に例示
したオープンネーム取引用の注文ウィンドウ１２００内
の項目設定ページ１２１０に、アマウント、ロット、レ
ート、刻み幅などの取引条件をエントリし、さらに、図
２９に例示したオープンネーム取引用の注文ウィンドウ
１２００内のネーム選択ページ１２２０で、そのビッド
の送り先（取引相手）の金融機関を１つ又は複数選択す
る（クレジットラインはエントリできない）。

【０１８９】以上のように、ディーラが、矢面注文の内
容を図２８及び図２９の注文ウィンドウ１２００に入力
した後、注文ウィンドウ１２００内の「ON」ボタン１２
３０を押すと、図２７にステップS97で示すように、そ
の入力された矢面注文が仲介サーバ１０に受け取られ、
仲介サーバ１０は直ちに、その矢面注文を発した金融機
関のディーラ端末３１の自己注文状況ウィンドウ５００
内のオープンネーム取引用ページ５２０（図１７）に、
その入力された矢面注文の表示を追加し、また同時に、
その注文の送り先の金融機関のディーラ端末３１のオー
プンネーム取引受け手用のホットクォーツウィンドウ３
２０（図１１）にも、その入力された矢面注文の表示を
追加する。

【０１９０】続いて、仲介サーバ１０は、図２７にステ
ップS98で示すように、その入力された矢面注文につい
てマッチング処理を行なう。このマッチング処理では、
その矢面注文を発したディーラ端末３１のオープンネー
ム取引受け手用のホットクォーツウィンドウ３２０（図
１１）に表示されているオープンネーム取引注文の中か
ら、上記入力された矢面注文の送り先の金融機関から発
されたものであって、上記入力された矢面注文とカウン
ターサイドの関係にあり且つ上記入力された矢面注文と
同じ業務条件（タームとレート）をもった注文だけが、
出会い候補としてピックアップされる。そして、そのピ
ックアップされた各出会い候補と上記入力された矢面注
文との間で、両注文の金額条件に基づいて、一致した取
引金額のうち、矢面注文の入力時に図２９のネーム選択
ページ１２２０で設定した当該出会い候補の発行元金融
機関のクレジットライン（「ライン」）を超えない範囲
内での最大値（約定可能金額）が計算される。出会い候
補のうち、約定可能金額が算出できた（つまり、上記入
力された矢面注文と一致した取引金額が存在し且つそれ
がクレジットラインを超えていない）候補だけが、出会
い相手として採用される。

【０１９１】続いて、仲介サーバ１０は、図２７のステ
ップS99に示すように、マッチングで採用された出会い
相手を一つずつ条件の良い（又は、発注時刻の早い）順
に選択し、選択した出会い相手と上記入力された矢面注
文と間に約定を自動的に成立させる。

【０１９２】約定が成立すると、仲介サーバ１０は直ち
に、図２７のステップS100で示すように、その成立した
約定の表示を、その約定の双方の当事者のディーラ端末
３１の約定履歴ウィンドウ６００の約定履歴ページ６１
０（図１８）に追加する。同時に、約定の成立によっ
て、その約定にかかる双方の注文のアマウントが減少し
たり又は注文自体が消滅するので、そうした注文の変動
に応じて、仲介サーバ１０は直ちに、図２７にステップ
S101に示すように、変動した注文が表示されていた全て
のディーラ端末３１のオープンネーム取引用のホットク
ォーツウィンドウ３２０、３３０（図１１、図１２）又
は自己注文ウィンドウ５００のオープンネーム取引ペー
ジ５２０（図１７）を、更新する。

【０１９３】上記のステップS98のマッチング処理で見
つかった出会い相手が複数ある場合、仲介サーバ１０
は、それら複数の出会い相手の全てと上記入力された矢
面注文との間に約定が成立するか、又は上記入力された
矢面注文のアマウントがこれ以上の出会い相手との間で
約定を成立させ得ない額まで減少するまで、上記のステ
ップS99〜S101を繰り返す。

【０１９４】以上が、オープンネーム取引の矢面注文か
ら約定までの仲介業務の詳細である。

【０１９５】次に、オープンネーム取引の岩陰注文から
約定までの仲介業務の詳細を説明する。

【０１９６】図３０は、オープンネーム取引における岩
陰注文から約定までの流れを示す。

【０１９７】図３０に示すように、ステップS111で、金
融機関のディーラはディーラ端末３１のメインウィンド
ウ２００内のHQ表示切替ウィンドウ７００(図１４)にお
いて、金融機関リスト７０４内から取引相手として希望
する金融機関を選択する。すると、仲介サーバ１０は、
ステップS112で、そのディーラ端末３１のメインウィン
ドウ２００内のホットクォーツウィンドウ３００に、受
け手用のホットクォーツウィンドウ３２０（図１１）を
表示する。この受け手用のホットクォーツウィンドウ３
２０（図１２）には、先ほど金融機関リスト７０４内か
ら選択した金融機関から自社宛てに発されたオープンネ
ーム取引の注文（矢面注文）であってまだ有効に残って
いるものが一覧に表示される。

【０１９８】もし、別の金融機関からの矢面注文を見た
い場合には、ディーラは、再びステップS111で、金融機
関リスト７０４内から別の金融機関を選択すればよい。
すると、受け手用のホットクォーツウィンドウ３２０
（図１１）には、新たに選択した別の金融機関から自社
宛てに発されたオープンネーム取引の注文（矢面注文）
であってまだ有効に残っているものが一覧に表示され
る。

【０１９９】次に、ディーラが、ステップS113に示すよ
うに、表示された受け手用のホットクォーツウィンドウ
３２０（図１１）の中から、その希望の注文のタームを
マウスのダブルクリックなどで選択すると、メインウィ
ンドウ２００の上に、図２８に例示したものと類似のオ
ープンネーム取引の受け手用の注文ウィンドウ１２００
がポップアップする。このとき、ポップアップした受け
手用の注文ウィンドウ１２００内の項目設定ページ１２
１０には、先ほど選択した希望の注文の取引条件がエン
トリされている。

【０２００】また、ディーラが、ステップS114に示すよ
うに、表示された受け手用のホットクォーツウィンドウ
３２０（図１１）の中から、その希望の注文のタームを
マウスの右クリックなどで選択して、コンポジットホッ
トクォーツウィンドウの表示を要求すると、受け手用の
ホットクォーツウィンドウ３２０（図１１）が、コンポ
ジットホットクォーツウィンドウ３４０（図１３）に置
き換えられる。このコンポジットホットクォーツウィン
ドウ３４０（図１３）には、選択したタームをもつ他社
から自社宛てのオープンネーム取引の矢面注文のリスト
３４２と、選択したタームをもつマーケット取引の自社
向けの注文のうち最も条件（例えばレート）の良いもの
とが、対比された形で同時に表示される。ディーラは、
このコンポジットホットクォーツウィンドウ３４０（図
１３）上で、上述したステップS113のオープンネーム取
引の注文の選択を行なうこともできるし、或いは、マー
ケット取引のタームを選択して既に説明したようなマー
ケット取引の注文入力へ移行することもできる。

【０２０１】さて、ステップS113で希望の注文を選択し
て図２８に例示したものと類似のオープンネーム取引の
受け手用の注文ウィンドウ１２００をポップアップさせ
ると、その受け手用の注文ウィンドウ１２００内の項目
設定ページ１２１０には、先ほど選択した希望の注文の
取引条件がエントリされている。この項目設定ページ１
２１０上で、ディーラは、図３０でステップS115に示す
ように、取引条件の中のアマウントだけを下方へ修正す
ることができる（アマウントを増やすことはできな
い）。レート、ロット、刻み幅は、選択した相手注文に
従うだけであり、受け手はこれを変更することができな
い。また、図２９に示したネーム選択ページ１２２０
も、この岩陰注文では意味を持たない（表示できな
い）。

【０２０２】こうして、岩陰注文の内容が図２８の項目
設定ページ１２１０上で決定された後、図３０にステッ
プS116で示すように、注文ウィンドウ１２００内の「O
N」ボタン１２３０が押されると、その岩陰注文が仲介
サーバ１０に受け取られる。すると、仲介サーバ１０は
直ちに、ステップS117で示すように、その入力された岩
陰注文と上記選択された相手方の注文との間で自動的に
約定を成立させる。

【０２０３】約定が成立すると、仲介サーバ１０は直ち
に、図３０にステップS118で示すように、その成立した
約定の表示を、その約定の双方の当事者のディーラ端末
３１の約定履歴ウィンドウ６００の約定履歴ページ６１
０（図１８）に追加する。同時に、約定の成立によっ
て、その約定にかかる岩陰注文の相手の注文のアマウン
トが減少したり又はその相手注文自体が消滅するので、
仲介サーバ１０は直ちに、図３０のステップS119に示す
ように、その相手注文が表示されていた全てのディーラ
端末３１のオープンネーム取引用のホットクォーツウィ
ンドウ３２０、３３０（図１１、図１２）又は自己注文
ウィンドウ５００のオープンネーム取引ページ５２０
（図１７）を、更新する。

【０２０４】以上が、オープンネーム取引の岩陰注文か
ら約定までの仲介業務の詳細である。

【０２０５】以上、特願２００１−１０５１０４号に記
載されたコール取引仲介システムの実施例にについて説
明した。次に、このコール取引仲介システムをベースに
した本発明の実施形態の幾つかを、図３１〜図４０を参
照して説明する。

【０２０６】まず、クレジットラインの全自動管理機能
をもつコール取引仲介システムの実施形態を説明する。

【０２０７】この実施形態におけるクレジットライン自
動管理機能とは、仲介システム１０が各クライアントが
他のクライアントに対して与えているクレジットライン
を常に自動的に管理していて、図３に示したマーケット
取引の仲介におけるマッチング処理（S5）で取引条件の
マッチするビッドとオファーを抽出した後（又は抽出す
る際）、その自動管理されているクレジットラインを超
過しないように約定金額を自動制御しながら、マッチし
た注文間の取引を自動的に約定に至らせたり又は自動的
に破談に終わらせたりする機能である。この機能を利用
することにより、図３のステップS７のオファー側クラ
イアントによるライン確認の手続きは省略される。

【０２０８】図３１は、各クライアントがビッド側の取
引相手のクレジットラインを初期設定するために用いる
クレジットライン設定ウィンドウ２０００の例を示す。

【０２０９】このクレジットライン設定ウィンドウ２０
００は、図２に示した初期設定プロセス１０３（図３及
び図４のステップS3）でディーラ端末３１に表示させる
ことができる。すなわち、初期設定プロセス１０３で
は、図８及び図９を参照して既に説明したとおり、取引
相相手としての任意の金融機関を指定することができる
が、その他に、図３１に示したクレジットライン設定ウ
ィンドウ２０００を表示して、このクレジットライン設
定ウィンドウ２０００上で、取引相手の金融機関の各々
についてのクレジットラインを設定することができる。
このクレジットラインの設定は、クライアントの任意の
時に行うことができるが、毎営業日に使用するクレジッ
トラインの初期設定は、典型的には、その営業日の始業
前、或いは前日の終業後に行われるであろう。

【０２１０】図３１に示すように、クレジットライン設
定ウィンドウ２０００には、クレジットライン表があ
り、そこでは、ビッド側取引相手となり得る各金融機関
ごとに、取引のターム別にクレジットラインを設定する
ことができる。図３１には、α銀行〜λ銀行までの１１
個の相手銀行に関する初期設定例が示されている。この
表中、各銀行の「有効」のセルにチェックマークを入れ
ることで、その銀行をビット側相手とする取引につい
て、クレジットライン全自動管理機能が適用されること
になる。「有効」のセルにチェックマークを入れなけれ
ば、その銀行をビット側相手とする取引について、クレ
ジットライン全自動管理機能は適用されず、上述した先
願システムで採用されている半自動方式（つまり、図３
のステップS7のライン確認を行う方式）が適用されるこ
とになる。

【０２１１】図３１のクレジットライン表には、取引の
タームとして、ON、TN、SN、１W〜３W（1週間〜３週
間）、１M〜１２M（1月間〜１２月間）が示されてい
る。ここで、ON、TN及びSNは1営業日間のタームであ
る。図３２に示すように、ON（OverNight）は、本日ス
タート（キャッシュスタート）のターム、TN（Tomorrow
Next）は1営業日後スタートのもの、SN(Spot Next)は
２営業日後スタート（スポットスタート）のものであ
る。１W〜３W及び１M〜１２Mについても、キャッシュス
タート、トムスタート及びスポットスタートがあり、そ
のスタート日の違いは、システムの処理においては後述
のように区別されるが、クレジットライン表の上ではラ
イン設定を簡単にするために区別されていない。なお、
図３１に示したタームは例示に過ぎず、他の長さ又はス
タート日のタームがこの表中に在ってもよいし、或るタ
ームが省略されていてもよい。

【０２１２】図３１に示したクレジットライン設定ウィ
ンドウ２０００において、ディーラが相手銀行のクレジ
ットラインを初期設定する手順は次のとおりである。

【０２１３】ディーラは、各銀行について、設定したい
タームのセルに、その銀行に対してそのタームについて
与えられるクレジットラインの数値をエントリする。例
えば、「１０００」をエントリすれば、「１０００億
円」のクレジットラインを初期設定したことを意味し、
「０」をエントリすれば、クレジットラインが「ゼロ
円」（無い）であることを意味する。また、記号「＊」
をエントリすると、実質的に無限大のクレジットライン
を初期設定したことを意味する。

【０２１４】クレジットラインを初期設定するとき、デ
ィーラは次の規則に従わなくてはならない。すなわち、
「より長いタームに対するクレジットラインは、より短
いタームに対するクレジットラインより低いか同じでな
ければならない」という規則である。この規則は、ター
ムが長くなるほど、リスクが大きくなるから、クレジッ
トラインを下げるべきであるという原理に基づいてい
る。（よって、この規則は、初期設定時だけでなく、以
後、仲介システム１０がクレジットラインを更新してい
くときにも常に守られる。）従って、図３１に例示する
ように、各銀行に対して設定されたクレジットライン
は、一営業日物（ON、TN、SN）において最も高く、最長
の１２Mにおいて最も低い。なお、一営業日物（ON、T
N、SN）同士の間でクレジットラインが異なっていても
よい。

【０２１５】また、ディーラは、図３１のクレジットラ
イン表中で連続して並ぶ複数のタームに同じクレジット
ラインを初期設定する場合には、それらのタームのうち
の一番右側のタームのセルにだけクレジットラインをエ
ントリすれば、その左側の空白セルのタームにも同じク
レジットラインが適用される。例えば、図３１におい
て、α銀行に関して、ONとTNとSNには同じ「＊」が適用
され、２Wと３Wには同じ「５００」が適用されることに
なる。

【０２１６】このように、エントリされたクレジットラ
インが共通に適用される1又は複数のタームを、この明
細書では「ブロック」という。（但し、一営業日物のON
とTNとSNについては、ブロックという概念は適用されな
い。）例えば、図３１において、α銀行に関して、１W
は第1のブロック、２Wと３Wは第２のブロック、１M〜３
Mは第３のブロック、４M〜６Mは第４のブロック、７M〜
１２Mは第5のブロックである。

【０２１７】タームの短い順にブロックのクレジットラ
インをB1,B2,…,Bnで表すと、上記したクレジットライ
ンの規則は、 1営業日物ライン≧B1≧B2≧…≧Bn という関係で表される。

【０２１８】図３３は、クレジットラインの初期設定の
ときの仲介サーバ１０の処理流れを示す。

【０２１９】図３３に示すように、図３１に示したクレ
ジットライン設定ウィンドウ２０００上で一営業日物の
ターム（ON、TN又はSN）に対してクレジットラインがエ
ントリされる場合（S301）、仲介サーバ１０は、エント
リ可能な金額に上限を設けずに（S302）、クライアント
からエントリされた金額を、そのタームに対するクレジ
ットラインとして初期設定する（S303）。また、そのタ
ームから表中左側へ連続してライン未設定のタームが並
んでいる場合には、それらライン未設定のタームに対し
ても、同じ金額のクレジットラインを初期設定する（S3
03）。

【０２２０】また、1営業日より長期のタームに対して
クレジットラインがエントリされる場合（S311）には、
仲介サーバ１０は、エントリ可能な金額の上限値とし
て、そのタームよりより短期の（表中左側の）タームに
対して既に設定されているクレジットラインの最小値を
設定し（S312）、その上限値以下の金額のみをエントリ
可能とする。そして、クライアントから金額がエントリ
されたタームと、そのタームから表中左側へ連続してラ
イン未設定のタームが並んでいる場合には、それらのラ
イン未設定のタームとを、同一ブロックに分類する（S3
13）。そして、クライアントからエントリされた金額
を、そのブロックに属する全てのタームに対する共通の
クレジットラインとして初期設定する（S314）。

【０２２１】以上の処理により、上記の規則、つまり 1営業日物ライン≧B1≧B2≧…≧Bn という関係に従って、図３１に例示したようなクレジッ
トラインが初期設定され、その初期設定データが仲介サ
ーバ１０に保存される。そして、クライアントが、図３
１に示したクレジットライン表内の任意の相手銀行の
「有効」のセルにチェックマークを入れると、仲介サー
バ１０は、以後、その設定された相手銀行のクレジット
ラインをベースにして、その相手銀行をビッド側とし当
該クライアントをオファー側とするマーケット取引に関
して、クレジットラインの全自動管理を行なうことにな
り、その結果、当該クライアントのディーラは自分でラ
イン確認を行う必要が無くなる。

【０２２２】図３４は、クレジットライン全自動管理を
適用したマーケット取引の注文から約定までの、仲介サ
ーバ１０のデータ処理手順を示す。

【０２２３】この図３４に示す処理手順を、既に説明し
た図２１の半自動方式による処置手順と対比してみるこ
とで、その特徴が容易に分かる筈である。

【０２２４】すなわち、図３４に示す全自動管理を適用
した方式では、ステップS321〜S322で、オファー側クラ
イアントのビッド側クライアントに対するクレジットラ
インの初期設定が行われ、設定されたクレジットライン
のデータが仲介サーバ１０に保存される。そして、ステ
ップS323〜S325に示すように、それぞれのクライアント
から出された注文を受信すると、仲介サーバ１０は、出
された注文（着目注文）についてマッチング処理を行な
って（S327）、着目注文と取引条件のマッチしたカウン
ターサイドの注文を出会い候補として見つけ出す。この
マッチング処理の具体的手順は、既に図２５を参照して
説明した手順と基本的には同様であるが、一部におい
て、図２５の手順とは異なる。

【０２２５】異なる点について説明すると、仲介サーバ
１０は、図２５のステップS76に示すように、着目注文
と出会い候補との間の約定可能金額を決定するが、その
とき、図２５のステップS76に示した条件に加えて、図
３４のステップS322で保存しておいたクレジットライン
も使用して、約定可能金額を決定する。これが、図３４
のステップS328の自動ラインチェックである。このステ
ップS328の自動ラインチェックでは、着目注文と出会い
候補のうちオファー側のクライアントがビッド側のクラ
イアントに対して与えているクレジットラインを保存ク
レジットラインデータ（S322）の中から読み出し、その
読み出したクレジットライン以下になるように、着目注
文と出会い候補間の約定可能金額を決定する。そして、
保存クレジットライン以下の約定可能金額が決定できた
出会い候補のみを抽出し、さらに、その抽出した出会い
候補中から最も条件の良い一つの出会い候補を選出す
る。そして、その選出した出会い候補と着目注文との間
で、両者間の約定可能金額を約定金額とした約定を、自
動的に（よって、図２５のステップS79のマニュアルに
よるラインチェックは行わずに）成立させる（図３４、
S329）。

【０２２６】こうして約定が成立すると、仲介サーバ１
０は直ちに、その約定金額分だけ、オファー側クライア
ントがビッド側クライアントに与えているクレジットラ
インを減少させるように保存クレジットラインデータの
更新を行う（図３４、S329）。更新されたクレジットラ
インの値は、オファー側クライアントの端末に提供され
る図３１にしたクレジットライン表に反映されるので、
オファー側クライアントは、何時でも現時点での最新の
クレジットラインの状態を知ることができる。

【０２２７】図３５は、図３４にステップS３２８〜S３
２９で示した仲介サーバ１０によるクレジットラインの
自動チェックと自動更新の具体的な処理流れを示す。

【０２２８】この処理は、着目注文と出会い候補が共通
にもつターム（以下、当タームという）と、両注文のう
ちのオファー側のクライアントからビッド側のクライア
ントに対して設定されている図３１に例示したようなタ
ーム別のクレジットラインとに基づいて行われる。

【０２２９】まず、自動ラインチェックに適用するクレ
ジットラインの値を、図３１に例示したようなターム別
のクレジットラインの中から選ぶ処理を行う。この選定
の原理は、当タームとオーバーラップする全てのターム
のクレジットラインの中から最小値を選ぶということで
ある。その具体的手順は、当タームのスタート日によっ
て若干異なる。

【０２３０】すなわち、当タームがキャッシュスタート
（当日スタート）である場合には（S331）、図３１に示
したクレジットライン表中で、ONから当タームの属する
ブロック（以下、当ブロックという）までの全てのター
ムのクレジットラインの中から最小値を選んで、それを
自動ラインチェックに適用する（S332）。実際の処理で
は、上述した規則に従ってクレジットラインが設定され
ているので、当ブロックとTNとONのクレジットラインの
中の最小値を選択して適用するということになる。但
し、当タームがONの場合には、単純にONのクレジットラ
インを適用することになる。

【０２３１】また、当タームがトムスタート（1営業日
後スタート）である場合には（S341）、図３１のクレジ
ットライン表中で、TNから当ブロックまでの全てのター
ムのクレジットラインの中から最小値を選んで、それを
自動ラインチェックに適用する（S342）。実際の処理で
は、上述した規則に従ってクレジットラインが設定され
ているので、当ブロックとTNのクレジットラインのうち
の最小値を選択して適用するということになる。但し、
当タームがTNの場合には、単純にTNのクレジットライン
を適用することになる。

【０２３２】また、当タームがスポットスタート（２営
業日後スタート）である場合には（S351）、図３１のク
レジットライン表中で、SNから当ブロックまでの全ての
タームのクレジットラインの中から最小値を選んで、そ
れを自動ラインチェックに適用する（S352）。実際の処
理では、上述した規則に従ってクレジットラインが設定
されているので、単純に当ブロック（当タームがSNの場
合にはSN）のクレジットラインを選択して適用するとい
うことになる。

【０２３３】こうして適用するクレジットラインを決め
た後、ステップS333へ進み、約定金額をその適用クレジ
ットライン以下になるように決定して約定を自動成立さ
せる。約定金額の具体的な決め方は、既に図３４のステ
ップS328に関連して図２５のステップS76を参照しつつ
説明した通りである。

【０２３４】約定が成立すると、直ちに、その約定金額
に基づいてクレジットラインを更新する処理を行なう。
その更新の原理は、当タームとオーバーラップする全て
のタームのクレジットラインから約定金額を減算すると
共に、上述した規則を守るために、当タームより長期の
タームのクレジットラインを当タームのそれを超えない
よう修正することである。その具体的手順は、当ターム
のスタート日によって若干異なる。

【０２３５】すなわち、当タームがキャッシュスタート
の場合には、当ブロック及びそれより短期の全てのター
ムのクレジットラインから約定金額を差引く（S334）。
また、当タームがトムスタートの場合には、当ブロック
及びそれより短期のON以外の全てのターム（但し、ONは
除く）のクレジットラインから約定金額を差引く（S34
4）。また、当タームがスポットスタートの場合には、
当ブロック及びそれより短期のON及び以外の全てのター
ム（但し、ONとTNは除く）のクレジットラインから約定
金額を差引く（S354）。さらに、当タームのスタート日
がどれであっても、当ブロックより長期のブロックのク
レジットラインの中に、上記のように更新した当ブロッ
クのクレジットラインを超過するものがあるならば、そ
の超過したクレジットラインから超過分の金額を差引い
て、それを当ブロックのクレジットラインと同額にする
（S335）。

【０２３６】以上のようにしてクレジットラインのチェ
ックと更新が自動的に行われることにより、各クライア
ントは自分の取引相手のクレジットラインを適切に初期
設定しておきさえすれば、後は何もせずとも、取引相手
のクレジットラインは常に適正に管理され、クレジット
ラインを超える約定成立は良好に回避され、しかも、半
自動方式で生じたような機会損失も無くなる。

【０２３７】次に、リスクベースの自動プライシング機
能をもったコール取引仲介システムの実施形態について
説明する。

【０２３８】この実施形態におけるリスクベースの自動
プライシング機能とは、予め各クライアントが自己資金
の貸し付け先の信用格付け値（以下、ランクという）ご
とにレートの修正値を設定しておくことで、仲介サーバ
１０が、そのクライアントの発するオファーのレート
を、そのオファーの仕向け先のランクに応じて、予め設
定された修正値を用いて自動的に調整するという機能で
ある。この機能は、マーケット取引にもオープンネーム
取引にも適用される。

【０２３９】図３６は、各クライアントがビッド側の取
引相手のランクに応じたレート修正値を初期設定するた
めに用いるリスクプライシング設定ウィンドウ２１００
の例を示す。

【０２４０】このリスクプライシング設定ウィンドウ２
１００は、図２に示した初期設定プロセス１０３（図３
及び図４のステップS3）でディーラ端末３１に表示させ
ることができる。すなわち、初期設定プロセス１０３で
は、図８及び図９を参照して既に説明したとおり、取引
相手としての任意の金融機関を指定することができる
が、その他に、図３６に示したリスクプライシング設定
ウィンドウ２１００を表示して、このリスクプライシン
グ設定ウィンドウ２１００上で、取引相手の金融機関の
もつランク（信用格付け値）ごとのレート修正値を設定
することができる。このレート修正値の設定は、クライ
アントの任意の時に行うことができるが、毎営業日に使
用するレート修正値の設定は、典型的には、その営業日
の始業前、或いは前日の終業後に行われるであろう。

【０２４１】図３６に示すように、リスクプライシング
設定ウィンドウ２１００には、基本リスクプライシング
表があり、そこには、クライアントが、ビッド側取引相
手が持ち得るランクごとに、取引のターム別に任意のレ
ート修正値を設定することができる。

【０２４２】図３６には、A、B、C及びSの４つのランク
に対する設定例が示されている。この表中、各ランクの
行と各タームの列とが交差したセルにエントリされてい
る数値が、そのランクとタームに適用されるレート修正
値である。例えば、修正値「0.01」は、レートを0.01％
増加することを意味し、修正値「-0.01」はレートを0.0
1％減少させることを意味する。そのクライアントがオ
ファーを発するとき、そのクライアントが設定したその
オファーのオリジナルのレートに対して、そのオファー
に仕向け先のランクに応じたレート修正値が加算され
る。そして、こうして調整されたレートをもって、その
オファーが仕向け先のホットクォーツウィンドウに表示
されることになる。従って、一つのオファーが、仕向け
先の金融機関のランク（つまり、リスク）に応じて、調
整された異なるレートをもつことになる。

【０２４３】以下の説明では、レートを増やす正のレー
ト修正値を「プレミアム」と呼び、レートを減らす負の
レート修正値を「ディスカウント」と呼ぶ。

【０２４４】図３６の例では、ランクAが基準的なラン
クであり、このランクAに適用される修正値はゼロであ
る。ランクAからランクBそしてランクCになるにつれ
て、信用度がより低くなる（リスクが大きくなる）た
め、より大きなプレミアムが設定されている。また、タ
ームが長くなるにつれてリスクが大きくなるので、より
大きなプレミアムが設定されている。また、ランクS
は、標準ランクAよりも信用度が高い（リスクが小さ
い）ランクであるため、ディスカウントが設定されてい
る。これらのプレミアムやディスカウントを具体的にど
のような値にするかは、クライアントの任意である。

【０２４５】図３７は、図３６に例示したランクごとの
リスクプライシング設定に基づく、各金融機関ごとのリ
スクプライシング設定を見せたリスクプライシング展開
ウィンドウ２２００を示す。

【０２４６】図３６に例示したランクごとのリスクプラ
イシング設定が完了すると、仲介サーバ１０は、予め登
録されている各金融機関のランクに応じて、各ランクの
リスクプライシング設定を各金融機関ごとのリスクプラ
イシング設定に展開して、図３７に例示するようなリス
クプライシング展開ウィンドウ２２００を作成して、そ
のクライアントのディーラ端末に送る。図３７に示すよ
うに、リスクプライシング展開ウィンドウ２２００に
は、個別リスクプライシング表があり、そこでは、銀行
ごとに、そのランクとそのランクに対して設定されたタ
ーム別のレート修正値とが表示される。

【０２４７】図３８は、リスクベースの自動プライシン
グ機能を適用した注文の受信から配信までの、仲介サー
バ１０のデータ処理手順を示す。

【０２４８】図３８に示すように、ステップS361〜S362
で、上述したようなクライアントから入力されたランク
ごとのプライシング設定と、それに基づいて自動展開さ
れた銀行ごとのプライシング設定とが、仲介サーバ１０
内のリスクプライシングマスタに保存される。そのクラ
イアントからオファーの注文が入力されると（S363、S3
64）、仲介サーバ１０は、その入力されたオファーの注
文を注文データベースに保存し（S365）、そして、ステ
ップS362で保存されたリスクプライシングマスタを参照
して、そのオファーのタームに対する仕向け先銀行ごと
のレート修正量を読み、その修正量をそのオファーのオ
リジナルのレートに加算することで、各銀行のリスクに
応じて調整されたレートを決定する（S366）。そして、
その決定された調整後のレートをもってそのオファー
を、リアルタイム配信処理で各銀行の端末へ配信して
（S367）、それぞれの銀行の端末のホットクォーツウィ
ンドウに表示する（S368,S369,S370,S371）。

【０２４９】例えば、そのクライアントが発したオファ
ーのタームが３Wでレートが0.10％であったとすると、
図３７に例示したプライシング設定に従って銀行ごとに
調整されたレートは、図３８に示すように、α銀行やβ
銀行のようなAランクの銀行に対しては元と同じ0.10％
であり、ε銀行のようなBランクの銀行に対してはプレ
ミアム0.02％が加算された0.12％であり、κ銀行のよう
なCランクの銀行に対してはプレミアム0.03％が加算さ
れた0.13％であり、λ銀行のようなSランクの銀行に対
してはディスカウント-0.01％が加算された0.09％であ
る。

【０２５０】このようにして、クライアントの発したオ
ファーのレートを、各相手のランク(又はリスク)に応じ
て自動調整した後、仲介サーバ１０は、そのオファーに
ついてのマッチングや約定の処理を、その調整されたレ
ートに基づいて行なう。従って、クライアントは、最初
に取引相手のランクごとのプライシング設定さえしてお
けば、後はプライシングについて何もしなくても、相手
のランク（又はリスク）に応じたプライシングを用いて
約定を自動的に得ることが出来る。

【０２５１】次に、コストベースの自動プライシング機
能をもったコール取引仲介システムの実施形態について
説明する。

【０２５２】この実施形態におけるコストベースの自動
プライシング機能とは、予め各クライアントが取引のロ
ットレンジごとにレートの修正値を設定しておくこと
で、仲介サーバ１０が、そのクライアントの発する注文
のレートを、その注文に適用可能な幾つかのロットレン
ジごとに予め設定された修正値を用いて自動的に調整す
るという機能である。この機能は、マーケット取引にも
オープンネーム取引にも適用される。

【０２５３】図３９は、各クライアントが取引のロット
に応じたレート修正値を初期設定するために用いるコス
トプライシング設定ウィンドウ２３００の例を示す。

【０２５４】このコストプライシング設定ウィンドウ２
３００は、図２に示した初期設定プロセス１０３（図３
及び図４のステップS3）でディーラ端末３１に表示させ
ることができる。すなわち、初期設定プロセス１０３で
は、既に説明したような各種の設定の他に、図３９に示
したコストプライシング設定ウィンドウ２３００を表示
して、このコストプライシング設定ウィンドウ２３００
上で、取引のロットレンジごとのレート修正値を設定す
ることができる。このレート修正値の設定は、クライア
ントの任意の時に行うことができるが、毎営業日に使用
するレート修正値の設定は、典型的には、その営業日の
始業前、或いは前日の終業後に行われるであろう。

【０２５５】図３９に示すように、コストプライシング
設定ウィンドウ２３００には、オファーとビッド側のコ
ストプライシング表がある。オファー側のコストプライ
シング表では、クライアントがオファー側である取引に
関して、所定のロットレンジごとに、取引のターム別に
任意のレート修正値を設定することができる。ビッド側
のコストプライシング表では、クイアントがビッド側で
ある取引に関して、所定のロットレンジごとに、取引の
ターム別に任意のレート修正値を設定することができ
る。

【０２５６】図３９の各表には、１００億円以上、５０
億円以上１００億円未満、及び５０億円未満の３つのロ
ットに対する設定例が示されている。各表中、各ロット
レンジの行と各タームの列とが交差したセルにエントリ
されている数値が、そのロットレンジとタームに適用さ
れるレート修正値である。例えば、修正値「0.01」は、
クライアントが注文時に設定したオリジナルのレートを
0.01％増加することを意味し、修正値「-0.01」はその
オリジナルのレートを0.01％減少させることを意味す
る。クライアントが発したオファーには、オファー側コ
ストプライシング表のレート修正値が適用される、ビッ
ドにはビッド側コストプライシング表のレート修正値が
適用される。各コストプライシング表内のどのロットレ
ンジに対するレート修正値が適用されるかについては、
クライアントが発した注文に取引条件として付いている
ロットとアマウントの間の範囲とオーバラップする表中
の全てのロットレンジのレート修正値が個別に適用され
ることになる。

【０２５７】例えば、クライアントが出した或る注文
が、オファーであって、１Wのタームと、１０億円のロ
ットと、８０億円のアマウントと、0.10％のレートとを
もっていたとする。この注文に対して、図３９のオファ
ー側コストプライシング表内の、１０億円から８０億円
までの範囲内とオーバラップするロットレンジに対して
設定された１Wのタームのレート修正値、すなわち、５
０億円未満ロットレンジに対するレート修正値0.04％
と、５０億円以上１００億円未満ロットレンジに対する
レート修正値0.01％が個別に適用されることになる。そ
の結果、その注文は、５０億円未満ロットレンジのレー
ト修正値0.04％が適用された調整レート0.14％をもつ第
1の注文と、５０億円以上１００億円未満ロットレンジ
のレート修正値0.01％が適用された調整レート0.11％を
もつ第２の注文とに見かけ上変換される。この見かけ上
の２つの注文のアマウントはオリジナルのアマウント８
０億円と同じであるが、ロットは、それに適用されたロ
ットレンジの最小値とオリジナルのロット１０億円のう
ちの小さい方となる。従って、５０億円未満ロットレン
ジが適用された第1の注文のロットは１０億円であり、
５０億円以上１００億円未満ロットレンジが適用された
第２の注文のロットは５０億円である。このように、一
つの注文に適用可能なロットレンジが複数ある場合に
は、その一つの注文は、各ロットレンジに応じて調整さ
れた異なるレートと異なるロットとをもった複数の注文
に、見かけ上変換されることになる。

【０２５８】図３９の例では、１００億円以上ロットレ
ンジが基準的なランクであり、このロットレンジに適用
される修正値はゼロである。ロットレンジの金額が低く
なると、単位取引当たりのコストが高くなるため、オフ
ァー側コストプライシング表では収益率を高めるようよ
り大きい絶対値をもつプレミアムが設定されており、ビ
ッド側コストプライシング表では支出率を下げるようよ
り大きい絶対値をもつディスカウントが設定されてい
る。また、タームに応じたレート修正値の調整もなされ
ている。これらのプレミアムやディスカウントを具体的
にどのような値にするかは、クライアントの任意であ
る。

【０２５９】図４０は、コストベースの自動プライシン
グ機能を適用した注文の受信から配信までの、仲介サー
バ１０のデータ処理手順を示す。

【０２６０】図４０に示すように、ステップS381〜S382
で、上述したようなクライアントから入力されたロット
レンジごとのプライシング設定と、それに基づいて自動
展開された銀行ごとのプライシング設定とが、仲介サー
バ１０内のコストプライシングマスタに保存される。そ
のクライアントから注文が入力されると（S383、S38
4）、仲介サーバ１０は、その入力された注文を注文デ
ータベースに保存し（S385）、そして、ステップS382で
保存されたコストプライシングマスタを参照して、その
注文に適用可能なロットレンジごとのレート修正量を読
み、そのレート修正量をその注文のオリジナルのレート
に個別に加算することで、各ロットレンジに応じて調整
されたレートとロットを決定する（S386）。前述したよ
うに、適用可能なロットレンジが複数ある場合には、そ
の注文は、異なるロットと異なる調整レートとをもった
複数の注文に見かけ上変換されることになる。そして、
その見かけ上の複数の注文を、リアルタイム配信処理で
各銀行の端末へ配信して（S387）、その銀行の端末のホ
ットクォーツウィンドウに表示する（S388,S389）。各
銀行は、自社に配信された上記見かけ上の複数の注文の
中から、何れか一つの注文（通常は、自分にとって最も
好都合な一つの注文）を捕らえて、約定することにな
る。

【０２６１】例えば、上に例示した、オリジナルの取引
条件として１０億円のロットと８０億円のアマウントと
0.10％のレートをもったオファーは、１０億円のロット
と調整レート0.14％とをもつ第1のオファーと、５０億
円のロットと調整レート0.11％をもつ第２のオファーと
に見かけ上変換される。よって、図４０に示すように、
そのオファーの仕向け先の各銀行端末のホットクォーツ
ウィンドウには、その第1のオファーと第２のオファー
が同時に表示されることになる（S388,S389）。そし
て、例えば５０億円未満の資金調達をしたい銀行は、上
記第1のオファーの方を捕らえて約定するであろうし、
他方、５０億円以上の資金調達をしたい銀行は、上記第
２のオファーの方を捕らえて約定するであろう。

【０２６２】このようにして、クライアントの発した注
文のレートを、各ロットレンジに応じて自動調整した
後、仲介サーバ１０は、その注文についてのマッチング
や約定の処理を、その調整されたレートに基づいて行
う。なお、一つの注文から派生した見かけ上の複数の注
文は、実質的には一つの注文であるから、それらのうち
のいずれか一つについて約定が成立すれば、仲介サーバ
１０は、その成立した約定の内容（例えば約定額など）
もとづいて、同じ注文から派生した他の全ての見かけ上
の注文の内容（例えばアマウントなど）を更新する。

【０２６３】以上のコストベース自動プライシング機能
により、クライアントは、最初にロットレンジごとのプ
ライシング設定さえしておけば、後はプライシングにつ
いて何もしなくても、取引金額（又は1取引当たりのコ
スト）に応じたプライシングに従った約定を自動的に得
ることが出来る。

【０２６４】上述したリスクベースの自動プライシング
機能とコストベースの自動プライシング機能とは、それ
ぞれ単独で用いることが可能であるが、組み合わせて用
いることも可能である。組み合わせる方法としては、例
えば、リスクベースのレート修正と、コストベースのレ
ート修正値とを組み合わせた修正値（例えば、単純加算
値、重み付け加算値又は平均化値など）を計算して、そ
の組み合わせ修正値を用いてレートを調整するという方
法を用いることができる。

【０２６５】このような自動プライシング機能と、前述
したクレジットライン全自動管理機能とを組み合わせて
用いることも勿論可能である。例えば、自動プライシン
グ機能で個々の注文のレートを調整し、その後のマッチ
ング処理でクレジットライン全自動管理機能を働かせる
ことができる。

【０２６６】以上、本発明の実施形態を説明したが、こ
れは本発明の説明のための例示であり、この実施形態の
みに本発明の範囲を限定する趣旨ではない。従って、本
発明は、その要旨を逸脱することなく、他の様々な形態
で実施することが可能である。

【図面の簡単な説明】

【図１】本発明の一実施形態にかかる取引仲介システム
の全体的な構成を示すブロック図。

【図２】仲介サーバ１０が行なう各種のプロセスを示す
ブロック図。

【図３】仲介サーバ１０が行なうマーケット取引の仲介
業務の全体的な流れを示すフローチャート。

【図４】仲介サーバ１０が行なうオープンネーム取引の
仲介業務の全体的な流れを示すフローチャート。

【図５】メインウィンドウ２００の例を示す図。

【図６】環境設定ウィンドウ９００の例を示す図。

【図７】決済口座登録画面９２０の例を示す図。

【図８】ホットクォーツ（HQ）反映先選択ウィンドウ９
３０の例を示す図。

【図９】グループ設定ウィンドウ９４０の例を示す図。

【図１０】 マーケット取引用のホットクォーツ（HQ）
ウィドウ３１０の例を示す図。

【図１１】オープンネーム取引の受け手（岩陰注文を発
するとき）のためのホットクォーツ（HQ）ウィンドウ３
２０の例を示す図。

【図１２】オープンネーム取引のプレゼンタ（矢面注文
を発するとき）のためのホットクォーツ（HQ）ウィンド
ウ３３０の例を示す図。

【図１３】コンポジットHQウィンドウ３４０の例を示す
図。

【図１４】HQ表示切替ウィンドウ７００の例を示す図。

【図１５】市場情報詳細ウィンドウ４００の例を示す
図。

【図１６】自己注文状況ウィンドウ５００内のマーケッ
ト取引用のページ５１０の例を示す図。

【図１７】自己注文状況ウィンドウ５００内のオープン
ネーム取引用のページ５２０の例を示す図。

【図１８】約定履歴ウィンドウ６００内の約定履歴ペー
ジ６１０の例を示す図。

【図１９】約定履歴ウィンドウ６００内のオープンエン
ドロール交渉のスケジュールページ６２０の例を示す
図。

【図２０】マーケット取引の注文から約定までの、主
に、ディーラがディーラ端末３１を用いて行なう作業手
順を示すフローチャート。

【図２１】マーケット取引の注文から約定までの、主
に、仲介サーバ１０が行なうデータ処理手順を示すフロ
ーチャート。

【図２２】マーケット取引用の注文ウィンドウ１０００
内の項目設定ページ１０１０の例を示す図。

【図２３】マーケット取引用の注文ウィンドウ１０００
内のネーム選択ページ１０２０の例を示す図。

【図２４】ラインチェックウィンドウ１１００の例を示
す図。

【図２５】マッチング処理の流れを示すフローチャー
ト。

【図２６】再マッチング防止情報を作成する処理の流れ
を示すフローチャート。

【図２７】オープンネーム取引における矢面注文から約
定までの流れを示すフローチャート。

【図２８】オープンネーム取引用の注文ウィンドウ１２
００内の項目設定ページ１２１０の例を示す図。

【図２９】オープンネーム取引用の注文ウィンドウ１２
００内のネーム選択ページ１２２０の例を示す図。

【図３０】オープンネーム取引における岩陰注文から約
定までの流れを示すフローチャート。

【図３１】クレジットライン設定ウィンドウ２０００の
例を示す図。

【図３２】３種類の1日間タームとスタート日の説明
図。

【図３３】クレジットラインの初期設定のときの仲介サ
ーバ１０の処理流れを示すフローチャート。

【図３４】クレジットライン全自動管理を適用したマー
ケット取引の注文から約定までの、仲介サーバ１０のデ
ータ処理手順を示すフローチャート。

【図３５】図３４にステップS３２８〜S３２９で示した
仲介サーバ１０によるクレジットラインの自動チェック
と自動更新の具体的な処理流れを示すフローチャート。

【図３６】各クライアントがビッド側の取引相手のラン
クに応じたレート修正値を初期設定するために用いるリ
スクプライシング設定ウィンドウ２１００の例を示す
図。

【図３７】リスクプライシング展開ウィンドウ２２００
を示す図。

【図３８】リスクベースの自動プライシング機能を適用
した注文の受信から配信までの、仲介サーバ１０のデー
タ処理手順を示すフローチャート。

【図３９】コストプライシング設定ウィンドウ２３００
の例を示す図。

【図４０】コストベースの自動プライシング機能を適用
した注文の受信から配信までの、仲介サーバ１０のデー
タ処理手順を示すフローチャート。

【符号の説明】

１０ コール取引仲介サーバシステム（仲介サーバ） ３０ クライアントシステム １０３ 初期設定プロセス １０４ 予約確認通知プロセス １０６ 注文約定プロセス １０７ リアルタイム配信
プロセス １０８ オープンエンドロール（OER）プロセス １１
０ 照会プロセス １１０A 二次コンファームプロセス ２００ メイン
ウィンドウ ２０１ メニューバー ２０２ メッセージ表示エリア ２０３ 通知ランプ ３００ ホットクォーツ（HQ）ウィンドウ ４００ 市場情報詳細ウィンドウ ５００ 自己注文状況ウィンドウ ６００ 約定履歴ウィンドウ ７００ HQ表示切替ウィンドウ ２０００ クレジットライン設定ウィンドウ ２１００ リスクプライシング設定ウィンドウ ２２００ リスクプライシング展開ウィンドウ ２３００ コストプライシング設定ウィンドウ S328 自動ラインチェック S329 自動ライン更新 S366 リスクベースプライス計算処理 S376 リアルタイム配信処理 S386 コストベースプライス計算処理 S387 リアルタイム配信処理

───────────────────────────────────────────────────── フロントページの続き (72)発明者 中村 太志 東京都中央区日本橋室町一丁目２番３号 上田短資株式会社東京営業部内 (72)発明者 三石 健幸 東京都中央区日本橋室町一丁目２番３号 上田短資株式会社東京営業部内 (72)発明者 酒井 孝之 東京都中央区日本橋室町一丁目２番３号 上田短資株式会社東京営業部内 (72)発明者 奥浜 透 東京都中央区日本橋室町一丁目２番３号 上田短資株式会社東京営業部内 (72)発明者 土屋 雄多 東京都渋谷区渋谷３−28−13 渋谷新南口 ビル フュ−チャーシステムコンサルティ ング株式会社内 (72)発明者 高島 康裕 千葉県浦安市高洲14−２ 潮音の街４− 503 (72)発明者 平光 利浩 東京都渋谷区渋谷３−28−13 渋谷新南口 ビル フュ−チャーシステムコンサルティ ング株式会社内

Claims (8)

【特許請求の範囲】
1. 【請求項１】 複数のクライアントと通信しながらクラ
   イアント間の取引を仲介する取引仲介システムにおい
   て、 各クライアントから、各クライアントが他のクライアン
   トの各々に対して設定したリスクベースのプライシング
   データを受け、設定されたプライシングデータを記憶装
   置に格納するプライシングデータ設定手段と、 各クライアントから、取引のための注文の入力を受け、
   入力された注文を記憶装置に格納する注文手段と、 各クライアントにより前記他のクライアントの各々に対
   して設定された前記記憶装置内のリスクベースのプライ
   シングデータに基づいて、各クライアントから入力され
   た注文の金銭的な取引条件を前記他のクライアントの各
   々毎に調整するプライシング手段と、 各クライアントから入力された注文に関し、前記他のク
   ライアントの各々毎に調整された金銭的な取引条件を、
   前記他のクライアントの各々に通知する注文通知手段
   と、 各クライアントから入力された注文に関し、他の或るク
   ライアントについて調整された金銭的な取引条件に基づ
   いて、前記他の或るクライアントとの取引の約定を成立
   させる約定手段とを備える取引仲介システム。
2. 【請求項２】 前記プライシングデータ設定手段は、各
   クライアントをして前記他のクライアントの各々に対し
   取引期間に応じて異なるプライシングデータを設定する
   ことを許し、各クライアントから受けた前記取引期間に
   応じて異なるプライシングデータを前記記憶装置に記憶
   し、 前記プライシング手段は、各クライアントから前記他の
   クライアントの各々に対し設定されている前記記憶装置
   内の前記取引期間に応じて異なるプライシングデータの
   うちの、各クライアントから入力された注文が指定する
   取引期間に対応するプライシングデータに基づいて、各
   クライアントから入力された注文の金銭的な取引条件を
   調整する、請求項１記載の取引仲介システム。
3. 【請求項３】 記憶装置をもつコンピュータシステムを
   用いて、複数のクライアントと通信しながらクライアン
   ト間の取引を仲介する方法において、 各クライアントから、各クライアントが他のクライアン
   トの各々に対して設定したリスクベースのプライシング
   データを受け、設定されたプライシングデータを前記記
   憶装置に格納するステップと、 各クライアントから、取引のための注文の入力を受け、
   入力された注文を前記記憶装置に格納するステップと、 各クライアントにより前記他のクライアントの各々に対
   して設定された前記記憶装置内のリスクベースのプライ
   シングデータに基づいて、各クライアントから入力され
   た注文の金銭的な取引条件を前記他のクライアントの各
   々毎に調整するステップと、 各クライアントから入力された注文に関し、前記他のク
   ライアントの各々毎に調整された金銭的な取引条件を、
   前記他のクライアントの各々に通知するステップと、 各クライアントから入力された注文に関し、他の或るク
   ライアントについて調整された金銭的な取引条件に基づ
   いて、前記他の或るクライアントの各々との取引の約定
   を成立させるステップとを備える取引仲介方法。
4. 【請求項４】 複数のクライアントと通信しながらクラ
   イアント間の取引を仲介する取引仲介システムにおい
   て、 各クライアントから、各クライアントが複数のコストレ
   ンジの各々毎に設定したコストベースのプライシングデ
   ータを受け、設定されたプライシングデータを記憶装置
   に格納するプライシングデータ設定手段と、 各クライアントから、取引のための注文の入力を受け、
   入力された注文を記憶装置に格納する注文手段と、 各クライアントにより設定された前記記憶装置内のコス
   トベースのプライシングデータに基づいて、各クライア
   ントから入力された注文の金銭的な取引条件を、その注
   文に適用可能なコストレンジの各々毎に調整するプライ
   シング手段と、 各クライアントから入力された注文に関し、前記適用可
   能なコストレンジの各々毎に調整された金銭的な取引条
   件を、他のクライアントに通知する注文通知手段と、 各クライアントから入力された注文に関し、前記適用可
   能なコストレンジの内の何れか一つについて調整された
   金銭的な取引条件に基づいて、前記他の或るクライアン
   トとの取引の約定を成立させる約定手段とを備える取引
   仲介システム。
5. 【請求項５】 前記プライシングデータ設定手段は、各
   クライアントをして前記複数のコストレンジの各々に対
   し取引期間に応じて異なるプライシングデータを設定す
   ることを許し、各クライアントから受けた前記取引期間
   に応じて異なるプライシングデータを前記記憶装置に記
   憶し、 前記プライシング手段は、各クライアントから前記複数
   のコストレンジの各々に対し設定されている前記記憶装
   置内の前記取引期間に応じて異なるプライシングデータ
   のうちの、各クライアントから入力された注文が指定す
   る取引期間に対応するプライシングデータに基づいて、
   各クライアントから入力された注文の金銭的な取引条件
   を調整する、請求項４記載の取引仲介システム。
6. 【請求項６】 記憶装置をもつコンピュータシステムを
   用いて、複数のクライアントと通信しながらクライアン
   ト間の取引を仲介する取引仲介システムにおいて、 各クライアントから、各クライアントが複数のコストレ
   ンジの各々毎に設定したコストベースのプライシングデ
   ータを受け、設定されたプライシングデータを記憶装置
   に格納するステップと、 各クライアントから、取引のための注文の入力を受け、
   入力された注文を記憶装置に格納するステップと、 各クライアントにより設定された前記記憶装置内のコス
   トベースのプライシングデータに基づいて、各クライア
   ントから入力された注文の金銭的な取引条件を、その注
   文に適用可能なコストレンジの各々毎に調整するステッ
   プと、 各クライアントから入力された注文に関し、前記適用可
   能なコストレンジの各々毎に調整された金銭的な取引条
   件を、他のクライアントに通知するステップと、 各クライアントから入力された注文に関し、前記適用可
   能なコストレンジの内の何れか一つについて調整された
   金銭的な取引条件に基づいて、他の或るクライアントと
   の取引の約定を成立させるステップとを備える取引仲介
   方法。
7. 【請求項７】 複数のクライアントと通信しながらクラ
   イアント間の取引を仲介する取引仲介システムにおい
   て、 各クライアントから、各クライアントが他のクライアン
   トの各々に対して設定したリスクベースのプライシング
   データを受け、設定されたプライシングデータを記憶装
   置に格納するリスクプライシングデータ設定手段と、 各クライアントから、各クライアントが複数のコストレ
   ンジの各々毎に設定したコストベースのプライシングデ
   ータを受け、設定されたプライシングデータを記憶装置
   に格納するコストプライシングデータ設定手段と、 各クライアントから、取引のための注文の入力を受け、
   入力された注文を記憶装置に格納する注文手段と、 各クライアントにより前記他のクライアントの各々に対
   して設定された前記記憶装置内のリスクベースのプライ
   シングデータと、各クライアントにより前記コストレン
   ジの各々毎に設定された前記記憶装置内のコストベース
   のプライシングデータとに基づいて、各クライアントか
   ら入力された注文の金銭的な取引条件を、前記他のクラ
   イアントの各々毎に且つその注文に適用可能なコストレ
   ンジの各々毎に、調整するプライシング手段と、 各クライアントから入力された注文に関し、前記他のク
   ライアントの各々毎に且つその注文に適用可能なコスト
   レンジの各々毎に調整された金銭的な取引条件を、前記
   他のクライアントの各々に通知する注文通知手段と、 各クライアントから入力された注文に関し、他の或るク
   ライアントについて且つその注文に適用可能なコストレ
   ンジの内の何れか一つについて調整された金銭的な取引
   条件に基づいて、前記他の或るクライアントとの取引の
   約定を成立させる約定手段とを備える取引仲介システ
   ム。
8. 【請求項８】 記憶装置をもつコンピュータシステムを
   用いて、複数のクライアントと通信しながらクライアン
   ト間の取引を仲介する方法において、 各クライアントから、各クライアントが他のクライアン
   トの各々に対して設定したリスクベースのプライシング
   データを受け、設定されたプライシングデータを記憶装
   置に格納するステップと、 各クライアントから、各クライアントが複数のコストレ
   ンジの各々毎に設定したコストベースのプライシングデ
   ータを受け、設定されたプライシングデータを記憶装置
   に格納するステップと、 各クライアントから、取引のための注文の入力を受け、
   入力された注文を記憶装置に格納するステップと、 各クライアントにより前記他のクライアントの各々に対
   して設定された前記記憶装置内のリスクベースのプライ
   シングデータと、各クライアントにより前記コストレン
   ジの各々毎に設定された前記記憶装置内のコストベース
   のプライシングデータとに基づいて、各クライアントか
   ら入力された注文の金銭的な取引条件を、前記他のクラ
   イアントの各々毎に且つその注文に適用可能なコストレ
   ンジの各々毎に、調整するステップと、 各クライアントから入力された注文に関し、前記他のク
   ライアントの各々毎に且つその注文に適用可能なコスト
   レンジの各々毎に調整された金銭的な取引条件を、前記
   他のクライアントの各々に通知するステップと、 各クライアントから入力された注文に関し、他の或るク
   ライアントについて且つその注文に適用可能なコストレ
   ンジの内の何れか一つについて調整された金銭的な取引
   条件に基づいて、前記他の或るクライアントとの取引の
   約定を成立させるステップとを備える取引仲介方法。