(57)【要約】  本発明は、電子的有価証券取引を促進するためのシステム及び方法を備えている。好ましいシステム実施形態は、ファシリテータモジュール、金融情報交換サーバー、トランザクションデータベース、及び有価証券の基準価格を計算するように働く分析サーバーで構成される取引促進コンピュータシステムを備えている。好ましい方法実施形態は、有価証券の市場データを受け取るステップと、有価証券の基準価格を計算するステップと、第１価格限界及び第１量限界を含む第１注文を受け取るステップと、第１注文とは逆側の第２注文で、第２価格限界及び第２量限界を含むような第２注文を受け取るステップと、第１注文と前記第２注文とで構成される取引を、基準価格からの差が最小である価格で実行するステップであって、その取引が前記第１及び第２価格と、第１及び第２量限界とに従うものであるようなステップとを備えている。【選択図】図１【特許請求の範囲】
【請求項１】
コンピュータシステムを介して有価証券の取引を促進する方法であって、
有価証券の価格を含む市場データを電子的に受け取るステップと、
前記有価証券の基準価格を、少なくとも部分的には前記市場データに基づいて計算するステップと、
前記基準価格をコンピュータ読み取り可能な媒体に電子的に記憶するステップと、
第１ユーザから前記有価証券に関する第１注文を電子的に受け取るステップであって、前記第１注文が第１の価格限界及び第１の量限界を含むようなステップと、
前記第１注文をコンピュータ読み取り可能な媒体に電子的に記憶するステップと、
第２ユーザから前記有価証券に関する第２注文を電子的に受け取るステップであって、前記第２注文は前記第１注文とは逆側の第２の価格限界及び第２の量限界を含むようなステップと、
前記第２注文をコンピュータ読み取り可能な媒体に電子的に記憶するステップと、
前記第１注文と前記第２注文とで構成される取引であって、該取引が前記第１及び第２の価格と、第１及び第２の量限界とに従っており、前記基準価格からの差が最小になる価格で前記取引を実行するステップと、を備えた方法。
【請求項２】
（ａ）価格面で、前記第２注文が前記第１注文と交わるほど積極的でなく、且つ（ｂ）前記第１注文が少なくとも前記基準価格と同程度に積極的に価格付けされた場合に、前記第１ユーザに電子通知を送信するステップであって、前記通知は、前記システムに逆注文が出されたことを前記第１ユーザに通知するものであるステップを更に備えた、請求項１に記載の方法。
【請求項３】
前記第２ユーザは、所定の時間周期が経過した後にのみ価格の積極性を高めることが許される、請求項１に記載の方法。
【請求項４】
前記基準価格は、最近の市場価格に基づくものである、請求項１に記載の方法。
【請求項５】
前記基準価格を、グラフィックユーザインターフェイスにより遠隔位置のユーザに表示するステップを更に備えた、請求項１に記載の方法。
【請求項６】
ブロック価格範囲を計算するステップであって、前記第２注文が前記ブロック価格範囲のパッシブ的な終端（passive end）と少なくとも同程度に積極的である場合だけ前記通知が発行されるようなステップを更に備えた、請求項２に記載の方法。
【請求項７】
ブロック価格範囲を計算する前記ステップは、前記有価証券の価格の最近の乱高下性(volatility)に基づく、請求項６に記載の方法。
【請求項８】
ブロック価格範囲を計算する前記ステップは、第１の所定時間周期内に生じ得る価格範囲を予想することを含む、請求項６に記載の方法。
【請求項９】
前記ブロック価格範囲は、前記第１の所定時間周期にほぼ等しい時間間隔で再計算される、請求項８に記載の方法。
【請求項１０】
ブロック価格範囲を計算する前記ステップは、最近の又は現在の市場価格に基づく、請求項６に記載の方法。
【請求項１１】
前記第１注文が前記ブロック価格範囲の消極的な終端（passive end）と少なくとも同程度に積極的に価格付けされた場合に前記第１注文の受け取りに続いてアクティブシンボル通知を発行するステップを更に備えた、請求項６に記載の方法。
【請求項１２】
前記第２注文が受け取られた後に前記第２ユーザへ逆注文通知を電子的に送信するステップであって、この逆注文通知は、ほぼ対応する逆注文がシステム内でアクティブであることを指示するものであるステップを更に備えた、請求項２に記載の方法。
【請求項１３】
前記第２ユーザは、所定時間周期が経過した後にのみ前記逆注文通知を受け取る、請求項１２に記載の方法。
【請求項１４】
コンピュータシステムを経て有価証券の取引を促進する方法にであって、
有価証券の注文を受け取るための累積周期をシステムの１人以上のユーザに電子的に通知するステップと、
前記有価証券の価格を含む市場データを電子的に受け取り、そして基準価格を前記市場データに少なくとも部分的に基づいて計算するステップと、
前記基準価格をコンピュータ読み取り可能な媒体に電子的に記憶するステップと、
第１ユーザから前記有価証券に対する第１注文を電子的に受け取るステップであって、前記第１注文が第１の価格限界及び第１の量限界を含むようなステップと、
前記第１注文をコンピュータ読み取り可能な媒体に電子的に記憶するステップと、
第２ユーザから前記有価証券に対する第２注文を電子的に受け取るステップであって、前記第２注文が第２の価格限界及び第２の量限界を含むようなステップと、
前記第２注文をコンピュータ読み取り可能な媒体に電子的に記憶するステップと、
逆注文がシステムに出されたことを前記第１ユーザに電子的に通知するステップと、
前記累積周期が経過したときに、前記第１注文と前記第２注文とで構成される取引であって、該取引が前記第１及び第２の価格と、第１及び第２の量限界とに従っており、前記基準価格からの差が最小になる価格で前記取引を実行するステップと、を備えた方法。
【請求項１５】
所与の有価証券において入力されるべき注文に対して１つ以上のコール(call)を電子的に発行するステップを更に備えた、請求項１４に記載の方法。
【請求項１６】
前記コールは、規則的な時間間隔で発行される、請求項１５に記載の方法。
【請求項１７】
前記コールは、アクティビティが前記有価証券の買い及び売りの両方のブロック関心を示すところの有価証券について規則的な時間間隔で発行される、請求項１５に記載の方法。
【請求項１８】
前記アクティビティは、有価証券を買う注文と、有価証券を売る注文との両方の受け取りを含む、請求項１７に記載の方法。
【請求項１９】
前記アクティビティは、有価証券を買うための注文の受け取りと、ブロック売りの関心についての市場データにおける兆候(evidence)とを含む、請求項１７に記載の方法。
【請求項２０】
有価証券の取引を促進するための電子システムであって、
ファシリテータモジュール、金融情報交換サーバー、トランザクションデータベース、及び有価証券の基準価格を計算するように働く分析サーバーで構成される取引促進コンピュータシステムを備え、
前記取引促進コンピュータシステムは、金融情報交換ネットワーク及び通信ネットワークと通信し、
前記金融情報交換ネットワークは、前記通信ネットワークと通信し、
前記通信ネットワークは、１つ以上のユーザターミナルと通信し、
実行エンジンが前記取引促進コンピュータシステムと通信し、
前記実行エンジンは、有価証券で実行される取引の価格と、前記有価証券に対する基準価格との間の差を最小にするように動作するように構成された電子システム。
【請求項２１】
前記分析サーバーは、前記注文の価格積極性を前記有価証券に対する基準価格と比較することにより有価証券に対する注文を評価する、請求項２０に記載のシステム。
【請求項２２】
前記取引促進コンピュータシステムは、前記有価証券の第１注文を出した第１ユーザに、前記第１注文が前記基準価格と少なくとも同程度に積極的である場合に前記第１注文とは逆の注文が前記取引促進コンピュータシステムにより受け取られたという通知を送信するように動作する、請求項２１に記載のシステム。
【請求項２３】
前記注文は、ブローカー／ディーラーにより受け取られる平均注文サイズより大きなブロックサイズの倍数であることが要求される、請求項２１に記載のシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ブロックトレーディングの関心を機密の交差ブックに集中させるように情報を管理し、そしてインターネットのようなコンピュータネットワークを経てブロックトレーディングを実行するための方法に係る。
【０００２】
関連出願へのクロスリファレンス：本出願は、２００３年６月２４日に出願された米国特許出願第１０／６０３，１００号の一部継続出願であり、これは、２００１年５月３１日に出願された米国特許出願第０９／８７０，８４５号の一部継続出願であり、又、これは、２０００年１２月２９日出願された米国特許出願第０９／７５０，７６８号の一部継続出願であり、更に、これは、２０００年６月１日に出願された米国特許出願第０９／５８５，０４９号の一部継続出願である。これら特許出願各々の全体的な内容を参考としてここに援用する。
【背景技術】
【０００３】
公共の有価証券市場では、市場の機構及び取引の心理が効率的な情報の普及や価格の発見に対して障壁を生み出している。自分の真の価格限界に関する情報を露呈する市場参加者の判断は、価格期待に影響する市場衝撃コストと、取引の実行を遅延又は失敗させる機会コストとの間の妥協をもたらす。ここで使用する「市場参加者」という語は、有価証券を取引する能力をもつ個人又は会社を指し、市場参加者の例は、ブローカー／ディーラー、団体、ヘッジファンド、統計学的鞘取引(statistical arbitrage)及び他の独占的取引運営、並びに電子通信ネットワーク（ＥＣＮ）で取引する個人投資家を含む。
【０００４】
例えば、買手の真の価格限界を１人以上の有望な売手に示すことにより、市場参加者は、実際に、いずれかの売手が実行を自由に選択できるところのオプションを書き込み、このオプションがオープンである限り、何が公平な取引価格であるべきかの市場参加者の期待に対する下方限度をセットする。たとえ売手の１人が下方価格期待を最初に有していたとしても、この期待は、買手の価格限界が分かったときに直ちに変更され、唯一残された質問は、公平な価格がもっと高くなければならないかどうかである。実際に、高い価格を発表することで、買手は、株の取得を切望することを指示し、これは、売手の注意を引くことになる情報を反映することができる。
【０００５】
ブローカー／ディーラーは、公平な価格が発見されるまで取引の両側の当事者の期待を入念に管理し、次いで、両者が満足し得る公平な取引価格を提案することにより、この問題に対処する。今日、このような仲介注文が電子的に益々配達されている。「保持されない(not held)」と識別される注文は、価格期待に対する前記衝撃を回避するために公共の市場に表示されない。ブローカーは、売り側と買い側に交差する「保持されない」注文を受け取り、２つの注文の限界間のどこかでクロス取引を実行するための公平な価格を選択しなければならない立場においてそれらを見出す。このような状態を取り扱うときには、自由裁量が通常使用される。例えば、買手が１０：００ＡＭに＄３０．００の大ブロック買い注文を出し、そして市場が、それ以来、現在の最良の申し出＄２９．８０まで下げた場合には、＄２９．９９の大ブロック売り注文は、おそらく、この価格では自動的に交差しない。というのは、これは、今や、現在市場に比して高いと思われ、即ち買手の限界は、市場価格がこのレベルを越えて上昇する場合に買いを停止するための命令として解釈されるからである。しかし、買手のより高い限界にも交差する＄２９．８２のブロック売り注文は、おそらく、受け容れられるが、＄２９．８５では、ブローカーが買手にコールするのを促すことになろう。
【０００６】
この人間の仲介は、支払われるコミッションと、ヘッジファンドのような積極的な取引会社と密接な関係をもつ個人への情報漏洩との両方に関して、法外な価格になる。これは、大きな団体が、慣習的なブローカーによる自由裁量の介入なしに、それらの注文を自分自身で掲示できるような別の市場を見出す要望を煽ることになる。
【０００７】
ＮＡＳＤＡＱ又は電子通信ネットワーク（ＥＣＮ）のような電子市場は、大ブロックトレーディングのための価格発見問題を取り扱うに充分な装備がなされていない。その最も簡単な形態では、電子市場は、単に、買手及び売手の取引の関心を、そのときこのような買い及び売りの関心を実行に移すことのできる申し込み者に表示するだけである。市場参加者の価格期待に衝撃を与えるのを回避するために、電子市場のユーザは、通常、比較的小さな注文を消極的な価格で出し、そして他の者がそれを実行するのを根気良く待つか、或いは若干積極的なスタンスをとり、他の者がスプレッドの他側に掲示した注文を実行する。
【０００８】
大きな注文を、このように処理できる非常に多数の小さな断片に「スライスし且つさいの目に刻む(slice and dice)」ツールが利用できるが、それらの行動が大きな注文の存在を統計学的分析の当業者に露呈することは不可避である。このようなトレーダーは、大きな機密の注文が処理されるときにそれらを慎重に検出し、そしてこれらの注文がおそらく引き起こす市場衝撃を予想することにより利益を発生する取引戦略を開発しそして最適化する。最も簡単なこのような戦略は、大きな注文の前方に位置をとり、そしてその継続する存在に基づいて、有利な方向に価格をプッシュすることである。大きな注文と同じ方向に取引することで、このような寄生的戦略は、最初に出された大きな注文により当然引き起こされる価格移動の激化を終わらせる。その最終的結果は、ニューヨーク証券取引所に大きな注文を出す場合と全く異なるものではなく、後者のケースでは、フロアトレーダーが加わって、オークション注文に「参加」するか、又は直接前方にステップインして、魅力的であった流動資産を封じる。「ペニージャンピング(penny-jumping)」及び「フロントランニング(front-running)」という語は、ＮＹＳＥフロア及び電子市場におけるこの形式の寄生的戦略を説明するために同様に適用されるようになった。
【０００９】
あるＥＣＮは、フロントランニング問題を軽減する試みにおいて、より精巧な注文形式を与える。これらの幾つか（例えば、自由裁量注文）は、１つの価格を示すが、より高い機密性の価格限界まで実行するためのプライオリティを奪うことで、真の価格限界をマスクするように単に試みる。これらは、表示されない価格レベルでいつ注文が実行されるか調べるために小さな注文を異なる価格レベルで浴びせるといった簡単な対抗戦略により悩まされている。他の精巧な注文形式は、最小量の条件を、隠れた自由裁量価格に関連して使用して、小さな注文を浴びせることによる検出を回避する。価格が表示されないので、伝統的な意味での「価格の暴露」はない。更に、逆の関心をもつブロックトレーダーは、第１注文の限界を発見できると共に、実際には、注文が常駐(resident)注文の限界に交差するまでどんどん悪化する価格レベルで繰り返し注文を出したりキャンセルしたりするだけで、それを行うための信用債務をもつことになる。従って、価格の期待は、取引の前に変更されないが、＄３０．００で買うためにＥＣＮに大きな隠れた注文を出すトレーダーは、実際に、たとえ売手が＄２９．９０への価格低下を受け容れるつもりであったとしても、＄３０．００での取引を期待する。
【００１０】
その結果、ＳｕｐｅｒＭｏｎｔａｇｅのような電子ブックは、ほとんどの参加者が、陰で待ち伏せして、他の者がどんな価格を示そうとするか取り入れ、又は一度に小さなサイズを表示する方が有利であることが直ちに分かるので、魅力的な価格レベルで著しいサイズの注文を引き付ける上で問題がある。これは、平均取引サイズが約５００株までどんどん下降する一方、合計取引量及び平均団体注文サイズが増加するような市場の展開を導いた。
【００１１】
この環境では、逆の当事者が同様に積極的であるときに真の価格積極性を機密裡に表現しようとするトレーダーに価格改善の利益で報いる電子取引システムが深刻に要望される。このようなブロックトレーディング解決策では、積極的なトレーダーのための最適な戦略は、それらの注文を積極的な価格で出すべきである一方、消極的なトレーダーは、当然、消極的に価格付けされた注文を出すことで最良のサービスを受けることになる。
【００１２】
このような要望に対する回答は、慣習的な市場に対し、人間の介在や、予めの取引情報漏洩がない状態で取引を即座に実行することのできる電子取引システムの主たる認められた利点を犠牲にして行うことはできない。
【００１３】
その挑戦は、手短に言えば、積極的な限界価格で電子的に実行できる注文を、相手方も実際に積極的であろうとするときに、そのような積極的な価格で実際に実行されないように保護することである。
【発明の開示】
【発明が解決しようとする課題】
【００１４】
積極的な注文を出した当事者のために、電子スピード実行の認められた利点を失わずに、且つ第三者の仲介を伴わずにスケールを後方に倒すには、積極的な価格を表現しようとする当事者の交渉の立場を強化し得る価値アイテムを識別しなければならない。関連特許出願である２００３年６月２４日に出願された第１０／６０３，１００号、２００１年５月３１日に出願された第０９／８７０，８４５号、２０００年１２月２９日に出願された第０９／７５０，７６８号、及び２０００年６月１日に出願された第０９／５８５，０４９号（各々の全体的な内容を参考としてここに援用する）は、「承認された取引関心(Certified Trading Interest)」情報をコンピュータシステムに機密裡に開示しようとする当事者が、彼等との取引に関心のある他の当事者から「承認された取引関心」情報を受け取るための権利をいかに得ることができるかを示している。これは、トレーダーが積極的に価格付けされた注文を取引システムに出したときに情報の流れの矢印を逆転する可能性をオープンし、即ち積極的な価格は第三者には示されず、むしろ、より消極的な申し出と共に第三者からの魅力的な情報でトレーダーを助ける。
【課題を解決するための手段】
【００１５】
本発明のシステムは、市場参加者が、限界価格を逆の当事者に開示せずに、又はこのような限界価格を自由に検出する戦略の犠牲にならずに、積極的に価格付けされた注文を電子マッチングブックへ出し、そして２つの注文限界が許すときに「全国市場」中間点（又は他の基準価格）のような公表基準価格に接近して価格付けされたマッチングする注文が見つかったときに即座の実行を受け入れるのを可能とすることで、既知の自動取引システムの制約を克服する。好ましい実施形態は、市場参加者が次のことを行えるようにする。（１）注文がどちら側であるか及び注文の価格を公衆に開示せずに、システムの電子マッチングブックに隠れた注文を出し、（２）価格時間プライオリティでランク付けされたブック内の対応する逆注文に対して即座の実行を、そのマッチングする注文が許すときに「全国市場」中間点（又は他の基準価格）に接近した価格で受け入れ、（３）他の参加者がこの有価証券において注文を出すのを誘導するためにシステムが「ＡＣＴＩＶＥ  ＳＹＭＢＯＬ（アクティブシンボル）」指示子を発行するようにさせ、（４）注文が、少なくとも、「全国市場」中間点（又は他の基準価格）と同程度に積極的に出され、そして第２の市場参加者がシステム表示「ブロック価格範囲」内で消極的な逆注文を出すときに、「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ（逆の存在）」通知を受け取り、（５）少なくとも「全国市場」中間点（又は他の基準価格）と同程度に積極的に既に価格付けされている場合にはいつでも、或いは中間点よりも消極的に価格付けされている場合にはある遅延（例えば、５秒）の後に、注文の価格を増加し、従って、次第に積極的な価格で逆の注文を次々にキャンセルしたり置き換えたりすることで継続注文の真の限界価格を検出することを目的とする戦略が適用できないようにする。
【００１６】
好ましい実施形態は、金融有価証券のような公共の市場で取引される代替可能なアイテムでブロックトレーディングを実行するための方法であって、少量の代替可能なアイテムに対する基準価格、例えば、代替可能なアイテムを取引するための最良のディーラー相場の平均値を電子的に計算するか又は受け取るステップと、基準価格を電子的に記憶するステップと、基準価格を参加者に電子的に表示するステップと、代替可能なアイテムを買うか又は売るためのブロック注文を含む情報を第１の参加者からネットワークを経て電子的に受け取るステップと、第１の参加者からの情報を電子マッチングブックに電子的に記憶するステップと、を備えた方法を包含する。注文が、価格時間プライオリティでランク付けされた電子マッチングブック内に以前に入力された他の注文とマッチングし得る場合には、この方法は、そのマッチングする注文の価格及び量の属性内の取引を、基準価格にできるだけ近い価格で且つ両方の注文により許された範囲内で実行するステップと、その実行された取引をユーザ並びに認可(clearing)及び取締エンティティに報告するステップも備えている。注文がマッチングせず、且つ第１の注文が基準価格より消極的に価格付けされ、そして基準価格より積極的に価格付けされた（しかし、第１参加者の注文にマッチングするに充分なほど積極的ではない）第２の市場参加者（１人又は複数）からの常駐の逆注文が存在する場合には、この方法は、「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知を第２の市場参加者へ電子的に送信して、逆の側に消極的注文が存在することを通知するステップと、第２の参加者の注文がキャンセルされるか又は基準価格より消極的な価格へと変更されるときには、「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知を除去するステップと、基準価格を連続的に再計算すると共に、注文を基準価格に「固定(peg)」することを選択した第１参加者及び第２参加者からの注文を再価格付けするステップと、基準価格の変化が、両注文のパラメータ内で実行を可能とするときに、一定価格の注文に対してこの固定された注文を実行し、そしてその実行された取引をユーザ並びに認可及び取締エンティティに報告するステップも備えている。
【００１７】
好都合にも、基準価格に比して決定される最も積極的な注文を入力したトレーダーに価格改善を許可するように取引が実行される。例えば、第１参加者が基準価格より３セント高く買うための注文を出し、そして第２参加者が基準価格より２セント安く売るための注文を出した場合には、取引が基準価格それ自体で実行され、３セントの積極性をもつ注文に最大の価格改善を与える。買い注文が基準価格より３セント高いが、売り注文が基準価格より１セント高く出された場合には、取引は、基準価格＋１セントで実行され、この場合には、積極的な注文のみが価格改善を受ける。買い注文が基準価格で出され、そして売り注文が基準価格より１セント高く出された場合には、取引を実行できないが、買手は、「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知を受け取る。取引の前にこの情報が発表されると、第１参加者を撤退させることになるので、実際に取引を切望する第２参加者が手ぶらのままになり得る。このようなトレーダーは、おそらく、積極性限界で注文を出すことにより自分の取引目的を達成することになる。他方、このような第２参加者が、実際に、より良い価格で取引する機会を待機しようとする場合には、「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知が、より積極的な価格を考えるように第１参加者に求めることにより、建設的な役割を果たす。両方のケースでは、積極的なトレーダーが取引の前に他の者に情報を漏洩し、悪い市場衝撃や低い充満率(fill rate)をしばしば生じる電子市場とは明らかに対照的に、積極的なトレーダーは、「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知に含まれた情報の恩恵を受ける。情報の流れのこの逆転により、「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知は、トレーダーが自分の取引の好みを表現するための動機を生み出し、より大きな流動性及びより効率的な価格発見を導く。
【００１８】
別の実施形態は、「ブロック価格範囲（ＢＰＲ）」を電子的に計算するステップと、このＢＰＲをコンピュータ読み取り可能な媒体に電子的に記憶するステップと、ＢＰＲ及び基準価格情報を含むデータを、インターネットのような通信ネットワークを経て電子的に送信するステップと、グラフィックユーザインターフェイスを経て複数のユーザへそのデータを表示するステップとを更に備えている。別の実施形態では、基準価格がシステム外部での事象により急激に変化し、そして基準価格それ自体が連続的に更新されるときを除いて、６０秒のような限定時間周期までの間、ＢＰＲを一定に維持するのが好ましい。この別の実施形態では、上述したステップに加えて、本発明のシステムは、第１参加者が、システムに現在ある逆注文にマッチングしないが、少なくともＢＰＲと同程度に積極的に価格付けされた注文を出すとき、即ちそれが「ブロック付け値(Block Bid)」以上の買い注文であるか又は「ブロック売り値(Block Offer)」以下の売り注文である場合にその旨ユーザに電子的に通知し、ここで、「ブロック付け値」及び「ブロック売り値」は、当該システム内の代替可能なアイテムを取引するための能動的な関心があるところのＢＰＲの下限及び上限を各々形成する。この別の実施形態では、逆が存在するという通知は、逆注文が少なくともＢＰＲと同程度に積極的に価格付けされた場合にのみ送信され、そして逆の存在条件を生じさせた２つの注文のいずれかが、その後に、一方又は両方の注文を固定できるところの基準価格の変化により、又はＢＰＲそれ自体の変化により、ＢＰＲより消極的に価格付けされたことが分かった場合には除去される。
【００１９】
別の実施形態は、上述した２つの実施形態のいずれかで述べたように機能するが、基準価格に対して消極的である注文を入力した第１参加者が、より積極的な価格をもつ注文に置き換えることが許されるまでに、公表された最小時間、例えば、５秒間、待機しなければならないことを更に必要とする。この別の実施形態では、システム内で消極的な逆の存在が通知された第２参加者は、次いで、第１参加者の逆のオファーを実行するために注文をキャンセルするか又は置き換えるように選択することができる。
【００２０】
本発明の好ましいコンピュータシステムの実施形態の概略が図１に示されている。
【００２１】
このシステムは、取引促進システム１００を備えているのが好ましい。この取引促進システム１００は、インターネットのような通信ネットワーク８０、及びＦＩＸネットワーク９０のような金融情報交換ネットワークを経て参加者に接続される。システム１００は、売主６０から売主のネットワーク７０を経て市場データを受け取る。参加者は、各参加者のワークステーションにインストールされたグラフィックユーザインターフェイス（ＧＵＩ）２０を経てシステムにアクセスする。注文は、実行エンジン５０へルーティングされる。マッチングする注文は、前記実行エンジンにより受け取られたときに自動的に取引される。好ましい実施形態では、ネットサーバーサブシステム１１０は、各クライアントＧＵＩに接続する役割を果たし、金融情報交換（ＦＩＸ）サーバー１２０は、バックオフィスシステム及びクライアント注文マネージメントシステムへ接続を与え、そして注文マネージメントサブシステム１３０は、ここに述べるシステムの注文取り扱いロジックを実施する役割を果たす。ファシリテータモジュール１４０は、関心を集中させそしてユーザを取引に向けて進ませるように意図された情報事象を生成する。取引促進システム１００は、トランザクションデータベース１５０において注文の状態を追跡する。システムは、分析サーバー１６０により計算された「全国最良付け値及び売り値(National Best Bid and Offer)」中間点価格のような基準価格に比して注文の価格積極性を決定する。別の実施形態では、システムは、これも分析サーバー１６０により計算される「ブロック価格範囲」に対して価格積極性を測定し、即ち注文の価格は、（ａ）ＢＰＲより消極的であるか、又は（ｂ）積極的であって、価格がＢＰＲ内であるか又はＢＰＲより積極的であることを意味する。実行エンジン５０は、通信ネットワーク８０を経て注文を受け取り、そしてそれらを欠陥許容のトランザクションデータベース（ブロック５１）に電子的に記憶し、即ちこの同じネットワークを経て取引促進システム１００へ実行を報告する。別の実施形態では、実行エンジン５０は、システム１００内の付加的なコンポーネントとしてローカルにホストになり得る。
【００２２】
参加者は、グラフィックユーザインターフェイス２０を使用して、注文をシステムに入力する。この注文が実行されるときには、その結果が、ＦＬＸプロトコルを使用して、それらのスポンサーブローカー９５及びそれら自身の会社の「注文マネージメントシステム（ＯＭＳ）」１０へ処理のために報告される。
【００２３】
全ての注文は、好ましくは、「大ブロック注文」であることが要求され、これは、そのサイズが大ブロック量の倍数でなければならないことを意味する。例えば、大ブロック量が１００，０００である場合には、ＧＵＩは、１００，０００株の倍数の注文しか許さない。これらの注文は、限界以上でもよいし、又は全国市場における最良の付け値と売り値との間の中間点のような市場指示子に固定されてもよい。全ての有効なブロック注文は、実行エンジン５０へ直ちにルーティングされ、そこで、ブロック５１に記憶される。別の実施形態では、いかなるサイズの注文も受け容れられる。
【００２４】
好ましい実施形態では、最初に来たものが最初にサービスされるように注文が処理される。トレーダーが積極的に価格付けされた注文を出す付加的な動機を生み出すことを目的とする別の実施形態では、このシステムは、注文を受け取って、マッチングについて考慮せずに待ち行列に入れるところの累積周期を発表し、その後に、取引周期を発表し、この周期中に、注文を価格時間プライオリティで実行エンジン５０に入れて、最初に買い注文を、次いで、売り注文を出し、そして注文エントリーにおいてマッチングが検出されたときに上述したようにそれらを実行する。例えば、このシステムは、１５分の累積周期を発表し、実行周期は、各１５分のインターバルの最後の１秒を占有する。この実施形態では、システムは、１日を通じて累積周期と取引周期との間を交番させ、例えば、累積周期は、８：３０：００〜８：４４：５９、８：４５〜８：５９：５９、９：００〜９：１４：５９、等々である。
【００２５】
ＧＵＩ２０は、所与の有価証券の大ブロックの取引に関心のあるトレーダーが、メインスクリーンの頂部のボックスに表示される有価証券のシンボルをクリックして、注文エントリーダイアログを出現させ、そして注文エントリーダイアログのフィールドを、自分の予め構成された好みに基づいて自動的にポピュレートできるようにする。トレーダーは、これらのフィールドを必要に応じて編集し、そして「提示(Submit)」とマークされたボタンを押して、注文を出す。
【００２６】
新たに入力された注文が１つ以上の以前のブロック注文にマッチングする（新たな注文が同じ有価証券におけるもので、逆の側にあり、そして価格が継続ブック注文に等しいか又はそれより良好である）場合には、実行エンジン５０は、逆注文を価格時間プライオリティで自動的にランク付けし、そして到来する注文と継続注文（１つ又は複数）との間の取引を、その前者又は後者のいずれかが完全に満たされるまで、システムの現在基準価格に最も近い２つの注文の限界内の価格で実行し、そしてその取引を、統合したテープのために「自動確認及びトランザクション（ＡＣＴ）４０サービスへ及びスポンサーブローカーの認可会社３０へ電子的に報告する。又、実行の通知は、取引のトレーダーに知らせるためにグラフィックユーザインターフェイス２０にも送信される。他方、マッチングする注文がブックにない場合には、新たな注文が継続注文としてブックに記憶されたままとなる。好ましい実施形態では、クライアントは、それらの注文を第三者ブローカーにより後援されるよう選択することができ、この場合、トレーダーは、ＦＩＸを経てスポンサーブローカーのバックオフィスシステム９５にも報告される。好ましい実施形態では、消極的な注文（現在の基準価格に比して）を入力する参加者は、最小遅延（例えば、５秒の）の後にのみ、その注文の価格積極性を高めることが許される。別の実施形態では、ユーザは、注文を直ちに置き換えることができるが、その置き換えられた注文は、指定の最小遅延の後でなければマッチングに適格なものとならない。更に別の実施形態では、全ての注文が、システム公表の累積周期中にはマッチングに対して不適格であり、そして累積周期が終了した後に、側、価格積極性及び時間の順で、実行エンジン５０にロードされる。更に別の実施形態では、トレーダーが任意の時間に注文を出しそして変更することができ、又、システムオペレータは、特定のユーザが常駐注文の限界を「探る(feeling out)」練習に参加するかどうか監視する（もしそうであれば、彼等の口座をキャンセルする）。
【００２７】
トレーダーの見込みを高めるために、システムの注文マネージャー１３０は、ファシリテータモジュール１４０に接続され、これは、新たに入力された注文がマッチングを見出さずに、継続注文としてブック５１に記憶されるときに、自動的にアクションを行う。好ましい実施形態では、買い（売り）注文が入力されると、ファシリテータは、「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知により、逆注文が入力されたところの基準価格以下（以上）で価格付けされた継続売り（買い）注文を通知する。別の実施形態では、到来する注文に対して逆の側にある全ての継続注文は、このような通知を受け取るのに適格である。
【００２８】
別の実施形態では、適度に価格付けされた注文だけが促進を受け、即ち大ブロックを取引するための適度な価格範囲（ブロック価格範囲）は、分析サーバー１６０により計算され、そして６０秒ごとに更新されてトレーダーのグラフィックユーザインターフェイス２０に掲示される。この別の実施形態では、ファシリテータ１４０は、注文の価格又は注文のどちら側かを漏洩せずに他の者が同じ有価証券についての注文を入力するよう促す情報事象を発生する。
【００２９】
この実施形態では、ファシリテータ１４０がアクションに向かってコールされたときに、システムのデータベース１５０内で知られた注文の状態に基づいて、２つの考えられるアクションの流れがある。
【００３０】
第１のケースでは、新たに入力された注文がマッチングを見出さないときに、システムの状態は、適度に価格付けされた他の注文がシステム内にないというものである。この有価証券を申し込む全ての当事者には、新たに入力された注文のシンボル主題におけるアクティビティの存在を指示するメッセージが配送される（シンボルが既に「アクティブ」な状態にある場合には、このステップが省略される）。グラフィックユーザインターフェイス２０は、図２に示すように、注文入力ダイアログ２０５の上のオレンジ色のボックス２１５にアクティブなシンボルを表示する。システムは、この有価証券の大ブロックの取引に関心があってアクティブなシンボルを見る第２の参加者が、シンボルをクリックすることで、注文入力ダイアログを出現させることができるのが好ましい。システムは、第２参加者の予め構成された好みに基づいて、注文入力ダイアログ２０５の全てのフィールドをポピュレートするのが好ましい。第２の参加者は、シンボルが「アクティブ」であるという知識で行動する。それ故、第２の参加者は、第１注文が以前に入力されて「ＡＣＴＩＶＥ  ＳＹＭＢＯＬ」通知を発行させたこと、及びこの第１注文がＢＰＲ内で価格付けされたことを理解する。この情報の利点を取り入れて、第２の参加者は、ブロック売り値（ブロック付け値）で限界買い（売り）注文を提示するように選択し、第１注文が逆の側であって且つ依然オープンである場合に取引を保証してもよい。好ましい実施形態では、シンボルがアクティブになると、少なくとも６０秒間は（又は他の所定の周期中は）そのままであり、即ちオープンのアクティブなシンボル通知は、ＢＰＲの更新に関連して再検討され、そしてその通知が６０秒以上未処理であり且つＢＰＲ更新時にシステム内で現在オープンであるこのシンボルにもはや適度に価格付けされた注文がない場合だけ、除去される。別の実施形態では、「ＡＣＴＩＶＥ  ＳＹＭＢＯＬ」通知は、このときシステム内に適度に価格付けされた注文があるかどうかを反映するようにリアルタイムで更新される。別の実施形態では、カラーに加えて、ＧＵＩは、システム内で現在オープンである適度に価格付けされた注文の数を表示する。
【００３１】
第２のケースでは、ブック５１に常駐する適度に価格付けされた逆注文があるが、この逆注文は、新たに入力される注文によりオファーされる限界価格を満足するに充分な非常に積極的なものではない。このケースでは、ファシリテータモジュール１４０は、現在基準価格と少なくとも同程度に積極的に価格付けされるものとして適任な常駐逆注文へ「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知を送信する。逆注文が現在この基準を満足しないが、基準価格の変化のために後で満足する場合には、「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知は、後で、条件を満足するときに送信される。いったん送信されると、「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知は、注文が適度に価格付けされたままである限り、実際上保持される。別の実施形態では、基準価格に対する条件はなく、そして適度な価格条件を満足する継続逆注文は、「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知を受け取るのに適格なものである。グラフィックユーザインターフェイス２０は、図２に示すように、注文入力ダイアログ２０５の上の黄色のボックス２２５においてシンボルをハイライト状態にすることで「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知を表示する。それ故、シンボルをアクティブにさせた第１参加者は、そこで、逆が存在することが分かる。システムは、その第１参加者が注文を積極的な価格で再価格付けし、そして注文を置き換えて、第２参加者の注文を実行できるようにするのが好ましい。好ましい実施形態では、システムは、ＢＰＲの積極端をデフォールト価格として自動的に提案して、取引を生じさせる戦略を促進させ、次いで、トレーダーは、その提案された価格限界を受け容れるか又は他のパラメータを必要に応じて変更するためにクリックすることができる。別の実施形態では、システムは、ユーザが、積極的注文の形式を、現在「全国市場中間点」価格からＢＰＲ又は構成可能なセント数（又はその端数）の良い方に制限すべく構成できるようにし、そしてこの積極的注文形式は、「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知の存在する中でデフォールトとして提案されたものである。好ましい実施形態では、ユーザは、シンボルをもつ黄色のボックスをクリックし、次いで、その目的で表示された単一のボタンを押すことにより、システムが逆注文の実行を試みるようにさせる注文を入力することが許される。別の実施形態では、ユーザインターフェイス２０は、トレーダーが新たな価格を選択しそして「置き換え」とマークされたボタンを押すようにさせる。継続注文をもつトレーダーが誰もそれらの価格積極性を上昇させず、そして３０秒後も依然として継続逆注文がある場合には、第２参加者の注文が基準価格と少なくとも同程度に積極的に価格付けされると分かった場合に、第２参加者は、次いで、システム内に継続逆注文があることを学習するのに適格となる。システムは、好ましくは、第１参加者について上述したように、黄色のボックスによりこの情報を表示し、そして第２参加者は、取引をクローズするように自分の価格積極性を高めるよう選択してもよい。別の実施形態では、第２参加者の注文は、３０秒（又は所定の周期）の後に「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知を受け取るのに適任となるために「適度に価格付け」されること���唯一必要とされる。両方のケースにおいて、３０秒の遅延は、第２参加者が、後で撤退するだけのために逆が存在するかどうか発見すべくシステムを厳密に調べるよう試みることを思いとどまらせ、常駐注文は、対抗オファーを取り上げるべきか撤退すべきか判断するために３０秒を有する。別の実施形態では、３０秒の遅延がなく、全てのトレーダーが「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知を同時に受け取るが、注文をキャンセルできない５秒の最小時間が強制的にとられる。更に別の実施形態では、全てのユーザが「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知を直ちに受け取り、最小時間が強制される状態はない。更に別の実施形態では、トレーダーは、「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知が受け取られたときに積極的な価格で自分の注文を自動的に置き換えるようにＧＵＩ２０を構成することができる。この最後の実施形態において、自動的に再価格付けする命令があって同じ逆注文を実行するように競合するシステム内に多数の注文がある場合に、システムは、価格時間プライオリティで応答注文を実行し、即ち継続注文は、到来する逆注文を満たすために最初に価格で競合し、次いで、２つの注文が、入力時に、同じ積極的価格限界を有する場合には、プライオリティは、最初に入力された注文へ移行する。
【００３２】
「ブロック価格範囲」（ＢＰＲ）を計算するための好ましいアルゴリズムは、株の乱高下性に基づき、次の６０秒以内に大ブロック注文を取引するのに適した価格を決定するように求める。好ましい実施形態では、この範囲は、最後にＢＰＲが更新されて以来、トレーダーが統合テープへ報告した価格に基づくもので、「全国最良付け値及び売り値」の現在中間点から上下に対称的な価格範囲を取り入れている。この範囲は、最新のＢＰＲ更新以来の観察された価格乱高下性に直接関係した量だけ中間点から上下に拡張する。
頭字語
2007528559.tif 000002
2007528559.tif 000003
【発明を実施するための最良の形態】
【００３３】
本発明の好ましい実施形態及び別の実施形態を以下に詳細に説明する。
重要な特徴：本発明の特徴の好ましいリストを以下に示す。
１．ブロックの機密交差。注文はマッチングエンジンへルーティングされ、このマッチングエンジンは、注文を価格時間プライオリティで交差させ、そしてロックインされた取引を認可のために報告する。マッチングエンジンは、リモートにホストになり得る。
２．大ブロック量。全ての注文は、有価証券当たりに構成される大ブロック量の倍数で入力されるのが好ましい。大ブロックサイズは、ゲーム感覚を阻止し、そしてユーザが同じ注文量を使用するよう促すことにより、「買手の自責の念」の問題、又は完全に充満した後に誤った側になる心配を軽減する。
【００３４】
３．「ＡＣＴＩＶＥ  ＳＹＭＢＯＬ」通知。別の実施形態では、システムは、有価証券について両側にブロック関心があると決定したときにユーザに通知する。これは、注文入力を時間的に集中させ、これにより、充満率を高める。
４．「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知。システムに積極的に価格付けされた（基準価格に対して）注文をもつトレーダーは、ほぼマッチングする逆注文が入力されたときに通知される。３０秒後に、第２の注文をもつ参加者も、その第２の注文がそのときの価格積極性条件を満足する場合にほぼマッチングするものの存在についてアラートされる。「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知は、積極的に価格付けされた注文を入力するトレーダーに、消極的な対抗オファーに関する情報で報い、これにより、トレーダーが真の価格積極性を表現するように促す。
【００３５】
５．バックオフィスへのＦＩＸ接続性。好ましい実施形態では、ＦＩＸ実行を「買い側注文マネージメントシステム」へ直接的に又はＦＩＸサービス局を通して配送するためのメカニズムをサポートする。これは、スポンサーブローカーに対して買い側のクライアントのために１日の終りの匿名をサポートする。
６．ＦＩＸチケット処理アプリケーション。クライアントは、自分の「注文マネージメントシステム」からシステムへ株を入れ（シンボル、量及び側）、次いで、ＧＵＩ２０を使用してその入れられた量に作用することができる。ＯＭＳは、個々のワークオーダーを追跡するために、或いは充満時にのみ、クライアントの構成に基づいて、更新することができる。
【００３６】
７．ＡＰＩ／ＧＵＩアクセス。システムは、「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知を受信した関心のある有価証券のウオッチリストに対してシンボルを顕著に表示する団体トレーダーからの入力で設計された任意の取引フロントエンドを与える。「ＡＣＴＩＶＥ  ＳＹＭＢＯＬ」通知を伴う別の実施形態では、これも表示される。又、システムは、承認された第三者が彼等の顧客に代わってこのような通知を受け取りそしてそれら自身のフロントエンドアプリケーションを通して視覚性を与えることができるように、アプリケーションプログラミングインターフェイス（ＡＰＩ）も露呈させる。別の実施形態では、このような通知及び「ブロック価格範囲」は、市場データサービスに対するＦＩＸプロトコルを通して得ることもできる。
【００３７】
本発明は、このシステムを、参加者及び関連会社、例えば、スポンサーブローカー又はそれらの認可会社の電子システムと一体化するための好ましいアーキテクチャーを備えている。この一体化の概要が図３（ａ）及び３（ｂ）に示されている。これらの図は、以下に述べる参加者ＣとＥとの間に取引を導くフローを示す。継続注文がシステムに既にある状態で、新たな参加者が逆注文を入力する。システムは、「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知を送出し、常駐注文が、より高い価格積極性レベルへと変更され、実行される取引を生じさせる。
【００３８】
システムは、次のステップを通して、前記例における取引を容易にするのが好ましい。
１．ステップ１において、ユーザは、好ましくは、グラフィックユーザインターフェイス２０を使用して、システムに注文を入力する。
２．システムは、好ましくは、ステップ２において、レコードのブローカーを指定し、そしてレコードのブローカー及び顧客ＩＤに基づいてクレジット限界に対して注文を有効確認する。注文情報は、データベース１５０に記憶される。
３．ステップ３において、注文マネージャー１３０は、注文を実行エンジン５０へルーティングし、そして注文が入力において満たされるか、有効限界注文として記憶されるか、又は注文が無効であった場合にキャンセルされるかを指示する注文更新メッセージが実行エンジンから戻されるのを期待する。
【００３９】
４．注文が実行エンジンにおいて実行もキャンセルもされないことが分かると、ＯＭ１３０は、ファシリテータモジュール１４０に注文入力事象を通知する。
５．ファシリテータモジュール１４０は、積極的な価格をもつ逆側がシステムに存在することを見出し、常駐逆側に「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知を直ちに送信し、そして新たな注文が積極的なものであることが分かった場合に、例えば、３０秒の遅延の後に、その新たな注文を発した第２の参加者へこの同じメッセージを発表するための事象をスケジュールする。
６．ステップ６において、逆の存在メッセージが常駐注文へ配送される。
【００４０】
７．ステップ７は、第１の逆の存在メッセージが送信された３０秒後に行うのが好ましく、「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知は、逆の存在状態が持続する場合に新たな注文へ配送され、次いで、新たな注文が基準価格に比して積極的に価格付けされる。
８．ステップ８では、常駐注文について、システムへのＦＩＸ接続性に対してサービス局を使用するスポンサー付き顧客は、ＧＵＩ２００において「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知を受け取り、そして価格の積極性を高めるように注文を変更する。
９．ステップ９において、ＯＭ１３０は、変更注文要求をルーティングし、そしてＯＭデータベース１５０において注文の状態を更新する。
【００４１】
１０．ステップ１０において、ＯＭ１３０は、変更注文メッセージを実行エンジン５０へ通す。
１１．ステップ１１において、実行エンジン５０は、新たな価格積極性が取引をロックインするのに充分であると決定し、そして好ましくは、この取引を認可相手当事者情報と共にＡＣＴへ報告する。別の実施形態では、別の実施形態では、取引がテープのみに対して報告され、そして認可情報は、スポンサーブローカーに取引が通知されるときを遅延するために１日の終りまで保留される。
１２．実行エンジン５０は、注文マネージャー１３０へ実行を報告するのが好ましく、ＯＭ１３０は、データベース１５０において注文の状態を更新し、そして消費したクレジットを更新する。
【００４２】
１３．ステップ１３において、注文マネージャー１３０は、取引をネットサーバー１１０及びＦＩＸサーバー１２０に報告する。
１４．ネットサーバー１１０及びＦＩＸサーバー１２０は、実行メッセージをそれらの各クライアントへ転送する。
１５．第２のクライアントは、サービス局を経てＦＩＸ実行を受け取る。
１６．取引プロセスの最後のステップにおいて、実行のドロップコピーがスポンサーブローカー（１つ又は複数）へ送信される。好ましい実施形態では、これが１日の終りに行われ、別の実施形態では、これが直ちに行われ、そしてスポンサーブローカーに、彼等が後援する全ての取引活動が直接報告される。
【００４３】
ファシリティ
システムは、次のファシリティ又はサブシステムを備えているのが好ましい。
１．ネットサーバー１１０。ネットサーバーサブシステムは、クライアントがグラフィックユーザインターフェイス２００を経てシステムにアクセスできるようにする。これは、システムに注文を入力するのに使用できる唯一のインターフェイスであるのが好ましい。全てのユーザは、取引アプリケーション（ＧＵＩ）をダウンロードするか、又はアクティブなシンボル及び逆の存在フラグへ満足な視覚性を与えるＧＵＩを開発しなければならない。ネットサーバー１１０は、発表されたＡＰＩを経てトレーダーフロントエンドへの接続性をサポートするのが好ましい。
【００４４】
２．ＦＩＸサーバー１２０。ＦＩＸサーバーは、ユーザ（クライアント）が接続をオープンし、そしてＦＩＸプロトコルに基づいて金融情報メッセージを交換できるようにし、ＦＩＸサーバーのためのソースコードは、オープンソースコードライブラリにおいて入手できる。ＦＩＸサーバーは、チケット（新規、キャンセル、キャンセル／置き換え）並びに注文状態要求メッセージを受け取るように構成されるのが好ましい。これは、注文更新及び充満を含む実行を押し出す。これは、クライアントの「注文マネージメントシステム」との直接的な接続と、サービス局を経ての接続とをサポートするのが好ましい。又、ＦＩＸサーバーは、実行メッセージ（「終了(done)」状態を伴う）をスポンサーブローカーへ配送して、取引後の処理を設定するのに使用されてもよい。通常、これらのメッセージは、１日の終りに発行されるが、クライアントは、システムが彼等のブローカーに１日の内の実行を必要に応じて通知することも要求できるのが好ましい。
【００４５】
３．注文マネージャー１３０。注文マネージャーは、注文及びその後の取引メッセージを処理し、それらを記憶及び実行のために実行エンジンへ通す。これは、分析サーバー１６０からＢＰＲ更新メッセージを受け取り、そして注文が少なくともＢＰＲと同程度に良好に価格付けされるか又は消極的に価格付けされるときを追跡することで、その注文に対する価格積極性フラグを維持するのが好ましい。
【００４６】
４．ファシリテータモジュール１４０。注文マネージャー１３０は、ここに述べるように、注文に関する情報を入念に発表することにより、マッチングする情報のシステムへの入力を容易にするという役割を果たすコンポーネントを備えているのが好ましい。
【００４７】
５．注文マネージメントデータベース１５０。注文マネージャー１３０は、トランザクション及び完全に回復可能な構造化問合せ言語（ＳＱＬ）データベースにおいて注文の状態を追跡するのが好ましい。又、これは、取引を認可部へ報告すると共に、毎日の必須レポートをそれに対応する自己規制組織（ＳＲＯ）へ発生するという役割を果たすレポートモジュールも含む。
【００４８】
６．分析サーバー１６０。分析サーバー１６０は、シンボル当たりの市場活動状態（スタート、ストップ、取引停止）を前記サーバーに通知するデータフィードと、全てのＮａｓｄａｑ及びＮＹＳＥリスト株に対する内部の最良の付け値及び売り値（価格、積極性サイズ及びタイムスタンプ）と、全国市場システム統合テープからの最後の売り取引データとを受け取る。サーバーは、この情報をハードディスクドライブのようなコンピュータ読み取り可能な媒体に記憶し、そしてここに述べるように分析計算を実行して、基準価格及びブロック価格範囲を決定する。これは、シンボルごとに、基準価格の変化、ＢＰＲ更新メッセージ、及び取引停止を申し込み当事者へ発表する役割を果たす。
【００４９】
７．ヘルプデスク。システムは、ウェブＧＵＩのようなユーザインターフェイスを含むヘルプデスクサブシステムを備えているのが好ましい。ヘルプデスクオペレーションは、このインターフェイスにアクセスして、クライアントの会社、スポンサーブローカー、又は個々のトレーダーに関連したＧＵＩアカウントを追加／除去／変更することができる。ヘルプデスクは、取引操作個人が、注文ＩＤに基づき又は会社及びシンボルによりシステムに問合せして、システムへのクライアント注文入力に続く事象シーケンスを追跡すると共に、ヘルプデスクをコールすることを望むトレーダーに、システムにおける彼等の注文についての詳細な応答を与えることができるようにする。
【００５０】
８．システムオペレーションマネージメント。システムは、システムオペレータが全てのファシリティの機能的実施を管理できるようにするシステムオペレーションコンソールサブシステムも含むのが好ましい。又、共有システムオペレーションデューティに加えて、システムは、オペレータが、有価証券、監査、１日の終了及び１日の開始事象に対するバッチプロセスの管理、容量のプランニング、及び内部アカウントに対する資格の管理（オペレータ及びヘルプデスク）を含む他のデューティを実行できるようにするのが好ましい。
【００５１】
９．マッチングエンジン５０。マッチングエンジン５０は、参加者の注文を電子マッチングブック５１に記憶し、そして買い注文及び売り注文が重畳する価格で入力されたときに取引を実行し、実行価格は、２つの注文価格限界が許す限り基準価格に近いものとなるように選択される。
【００５２】
前記特徴の好ましい実施形態を、より広範囲に以下に説明する。
ＦＩＸサーバー：好ましい実施形態では、必要なときにクライアントの「注文マネージメントシステム」１０及びスポンサーブローカーとバックオフィス一体化するためにＦＩＸプロトコルを使用するのが好ましい。図４は、認可の観点からの取引のライフサイクルを示している。クライアントは、システムを使用するための２つのモード間で選択を行えるのが好ましい。第１モデルは、チケットを使用して、多数の市場行先にわたる債務の管理を容易にする。チケットは、クライアントの注文マネージメントシステムから出されるもので、トレーダーが、各市場行先においてどれほど多くの株を取引するかのタブを保持する上で助けとなるものである（市場行先とは、本システムのように、注文を実行できる場所である）。チケットの目的は、全ての行先にわたって出される株の総計数が、クライアントの「注文マネージメントシステム」１０に知られているクライアントの全注文の合計株数を決して越えないように確保することである。トレーダーがチケットを使用するときには、ＯＭＳから入力されたチケットがＧＵＩ２０に現われ、そして注文は、これらのチケットに対して入力することしかできない。
【００５３】
チケットの使用を選択するクライアントは、注文が、以前に入力されたチケットと同じ有価証券におけるもので、同じ側にあり、且つそれ以下のサイズである場合にしかシステムへこの注文を入力できないのが好ましい。システムは、トレーダーがチケットの使用を選択するときに、次のステップを実行することによりバックオフィス及び第三者システムを更新するのが好ましい。
【００５４】
１．ステップ４１０において、価格をもたないＦＩＸ注文としてシステム１００にチケットを入力する。チケットは、システムが特定のＧＵＩへマップするところのターミナルＩＤを保持する。トレーダーは、自分のＧＵＩに映し出されたチケットを見る。
２．ステップ４２０において、トレーダーは、このチケットに対する注文を入力し、これは、ここでは、「子」注文と称される。この子注文は、チケットと同じ有価証券で且つ同じ側にあり、そしてその量は、トレーダー構成デフォールト注文量又はチケット量より少なく選択される。システムは、好ましくは、注文を有効確認し、そして実行エンジン５０へ通す。好ましい実施形態では、注文入力事象は、「注文状態＝新規」であるＦＩＸ実行メッセージを経てＯＭＳへ報告される。別の実施形態では、クライアントＯＭＳは、取引が完了したときに実行メッセージしか受け取らない（以下を参照）。
３．この注文に対して取引が行われるときには、実行エンジン５０は、好ましくは、テープ及び認可のためにＡＣＴに報告し（ステップ４３０）、次いで、取引を注文マネージャー１３０に通知する。好ましい実施形態では、システムは、顧客注文マネージメントシステムのＧＵＩ及びＦＩＸクライアントのような両ＡＰＩクライアントに取引の詳細を通知する。
【００５５】
４．ステップ４５０において、システムは、好ましくは、ＦＩＸ実行メッセージを、クライアントＩＤを含む実行ブローカーへ送信する。
５．システムは、好ましくは、ユーザが、取引日の終了以前に割り当てプロセスを開始できるようにする（ステップ４４０は、ユーザが任意に実行する）。
６．好ましいシステムは、１日の終りに次のことを実行する（ステップ４６０）。
ａ．取引概要ファイルがスポンサーブローカーの認可会社へ送信される。これは、シンボル、売り買いした株、及び逆の当事者のＭＰＩＤを含む認可に関する情報を備えている。
ｂ．ＯＡＴＳレポートは、スポンサーブローカーに代わって注文トレール及び実行の概要を与える。システムは、ＯＡＴＳレポートをスポンサーブローカー（１つ又は複数）に自動的に送信し、ＮＡＳＤへ転送する。別の実施形態では、レポートをＮＡＳＤへ直接送信する。これらのファイル転送は、電子的であり、ファイル転送プロトコル（ＦＴＰ）を使用する。
【００５６】
好ましい実施形態では、ユーザは、チケットの使用を必要としない別の構成を選択することができるが、むしろ、トレーダーが注文入力ステップ４２０でプロセスをスタートするのを許す。残りのフローは、上述したものと同じである。
【００５７】
別の実施形態では、システム１００は、システムを使用する全クライアントに対してスポンサーブローカーがホストとなり、そしてこのシステムは、当業者が容易に実施できるか又は特殊な売主を介して商業的に入手できる取引後処理サブシステムを備えている。この別の実施形態では、１日の終りの匿名を必要とせず、そしてブローカー実行レポートを直ちにディスパッチすることができる。
【００５８】
ＦＩＸサーバー１２０は、クライアントの「注文マネージメントシステム」１０への接続性を与えるために種々のネットワーク解決策をサポートするのが好ましい。例えば、クライアントのＯＭＳは、前記ＦＩＸサーバーに直接接続することもできるし、或いはＦＩＸサーバー１２０と複数のクライアントとの間の接続を仲裁するＦＩＸサービス局を経てＦＩＸサーバー１２０と通信することもできる。
【００５９】
ＦＩＸサーバー１２０は、チケットが無効であるとき、又はクライアントがチケットを使用しないように構成されたときに、チケットを拒絶するのが好ましく、チケット拒絶メッセージは、分かり易い拒絶理由をテキストフィールドに保持するのが好ましい。注文量がこの有価証券の「大ブロック量」未満であるために拒絶が送信される場合には、拒絶メッセージにおけるメッセージテキストの情報に対して正しいＬＢＱが与えられるのが好ましい。好ましい実施形態では、ＦＩＸサーバー１２０は、次の到来メッセージ、即ちＦＩＸ新規注文、注文キャンセル、キャンセル／置き換え、及び注文状態要求、をサポートするのが好ましい。アウトバウンドメッセージは、クライアントがチケットを使用する場合に、所与のチケットの子注文に関連した「注文更新」（基礎となるチケットの注文ＩＤを保持するＦＩＸ実行メッセージ）を含むのが好ましい。チケットを使用しないクライアントは、充満（ＦＩＸ実行メッセージ）しか受け取らないのが好ましい。別の実施形態では、チケットを使用しないクライアントは、ＧＵＩを経て入力された注文に関連した各事象に対して、「新規注文」確認メッセージを含む「注文更新」メッセージを受け取り、従って、ＯＭＳは、処理される全サイズ及び充満されたサイズを事象ごとに追跡することができる。
【００６０】
ＦＩＸサーバー１２０は、オペレータが、システムソフトウェアへの変更を必要とせずに、新たなクライアント接続を設定し及びカスタマイズできるようにするウェブコンフィギュレーションスクリーンをサポートするのが好ましい。上述したように、ＦＩＸ買い側クライアントは、（ａ）ＦＩＸ実行のみのために、又は（ｂ）チケット取り扱い及び実行報告をサポートするために、構成できるのが好ましい。ＦＩＸスポンサーブローカークライアントは、実行しか受け取らないように構成されるのが好ましい。別の実施形態では、スポンサー付きクライアントのＯＭＳへ送信された各メッセージのドロップコピーを受け取るようにスポンサーブローカーのＦＩＸ接続を構成することができる。各充満時に送信される実行メッセージに加えて、コンフィギュレーションオプションは、注文が完了したときに、この注文についての処理が完了したことを示すように「注文状態」フィールドが「終了」にセットされた最終的なＦＩＸ実行メッセージを送信するオプションを含むのが好ましい。
【００６１】
注文マネージャー：注文マネージャー１３０は、メッセージプロセッサとして動作する。以下、種々のメッセージの処理について説明する。
システムは、ユーザが「新規チケット」メッセージを入力できるようにするのが好ましい。「新規チケット」メッセージは、「注文形式＝市場」で且つ限界価格をもたない「ＦＩＸ新規注文」メッセージである。限界価格をもつ「ＦＩＸ注文」は、拒絶される。別の実施形態では、このメッセージは、システムの「アプリケーションプログラミングインターフェイス（ＡＰＩ）」を経て提出することができる。
【００６２】
以下のステップは、「新規チケット」を処理する間に（図５を参照）、チケットがステップ５１０で受け取られた後に、実行されるのが好ましい。
−  有効確認。ステップ５２０において、システムは、「ＦＩＸ新規注文」メッセージにおけるフィールドを最初に有効確認することにより新規注文を処理するのが好ましい。チケットは、有効なクライアントＩＤ、トレーダーＩＤ（独特のＧＵＩへマップする）、有価証券、及び側（買いか売りか）を有すると共に、少なくともこの有価証券に対するブロック量と同程度の大きさでなければならない。Ｃｌｏｕｄ９は、「市場」注文及び「ＮｏｔＨｅｌｄ」として識別されたＦＩＸ注文（チケット）を受け入れ、そして限界価格を有するチケットを拒絶する。別の実施形態では、価格及び「ＮｏｔＨｅｌｄ」状態に関する制約は、実施されない。クライアントは、好ましくは、各側に有価証券ごとに１つのチケットをもつことしか許されず、同じ有価証券における第２の買いチケット又は第２の売りチケットは、以前のチケットが依然残っている場合には拒絶される。以前のチケットが満たされるか又はキャンセルされた場合には、第２のチケットを入力することができ、ＧＵＩフロントエンドにおいて第１のチケットに置き換わる。別の実施形態では、有価証券ごとに多数のチケットの表示を可能にするフロントエンドが使用されると共に、クライアントは、いかなる数のチケットを出すことも許される。他のビジネスＦＩＸ注文属性は、無視される。拒絶されたチケットは、理由コードと共にＧＵＩに表示されるのが好ましい。
【００６３】
−  処理。システムは、有効なチケットをそのデータベース１５０に記憶するのが好ましい。次いで、チケットは、ステップ５４０において、ＮｅｔＳｅｒｖｅｒ１１０を経てクライアントＧＵＩに表示され、そしてステップ５３０において、ＦＩＸサーバー１２０を経てクライアントＯＭＳに確認が返送される。以下のテーブルは、好ましい実施形態においてチケットメッセージの所要フィールドを与える。
2007528559.tif 000004
【００６４】
システムは、ユーザが「キャンセル／置き換えチケット」メッセージを入力できるようにするのが好ましい。「キャンセル／置き換えチケット」は、以前のオープンチケットのＣｌｉｅｎｔＴｉｃｋｅｔＩＤ及び新規チケットのＣｌｉｅｎｔＴｉｃｋｅｔＩＤと共に「ＦＩＸキャンセル／置き換え注文」として提出されるのが好ましい。別の実施形態では、このメッセージは、ＡＰＩを経て提出されてもよい。好ましい実施形態では、システムは、「キャンセル／置き換えチケット」メッセージを受け取ったときに次のステップを実行する。
【００６５】
−  有効確認。本発明のシステム主題は、新規の量から既に満たされた量を引いたもの（新規の残り(Leaves)）が、そのシンボルに対するシステムの「大ブロック量」未満である場合、或いはオープン注文として実行エンジンに出された株の全量未満である（残りが処理中のものより少ない）場合に、「キャンセル／置き換え」メッセージを拒絶するのが好ましい。
−  処理。要求を受け容れる場合には、Ｃｌｏｕｄ９は、チケットサイズを、その後の注文入力事象に適用すべく変更し、そしてＮｅｔＳｅｒｖｅｒ１１０を経てクライアントＧＵＩへ変化をプッシュするのが好ましい。又、ＦＩＸを経てクライアントのＯＭＳへその変化を確認するのが好ましい。
【００６６】
システムは、ユーザが「キャンセルチケット」要求を入力できるようにするのが好ましい。「キャンセルチケット」メッセージは、以前のオープンチケットのＣｌｉｅｎｔＴｉｃｋｅｔＩＤをもつ「ＦＩＸ注文キャンセル」メッセージである。別の実施形態では、このメッセージは、ＡＰＩを経て提出されてもよい。本発明のシステム主題は、「キャンセルチケット」メッセージを次のように処理する（図６を参照）。
【００６７】
−  有効確認。システムは、ステップ６１０において、オープンチケットを指すよう確保することにより、「キャンセル要求」メッセージのフィールドを有効確認するのが好ましい。
−  処理。オープン注文がある場合には、ステップ６２０において、システムは、先ず、チケットに関連した全てのオープン注文をキャンセルするように試み、次いで、フライト中のメッセージでキャンセルする前に行われた実行を報告する（６３０）（この「クリーンアップ」プロセスは、全ての関連注文が満たされるか又はキャンセルされたときに終了し、そしてＣｌｏｕｄ９注文マネージャーのデータベースは、充満の状態において実行エンジンのデータベースと合意する）。オープン注文がクリーンアップされると、ステップ６４０において、システムは、キャンセルされたサイズを指示する結果と共に、「キャンセルチケット」を確認する。成功の「キャンセルチケット」要求は、ステップ６５０において、ＮｅｔＳｅｒｖｅｒを経てクライアントＧＵＩに通知される。
【００６８】
システムは、ユーザが「新規注文」メッセージを入力できるのが好ましい。「新規注文」メッセージは、ＧＵＩ又はＡＰＩを経て提出されるのが好ましく、そしてこのメッセージは、限界価格以上の所与の有価証券の所与の数の大ブロックロットを買う又は売る要求を含む。好ましい実施形態では、ユーザは、固定価格限界を選択してもよく、この場合に、注文は、絶対的限界価格と固定限界価格との間のあまり積極的でない価格に制限される。別の実施形態では、ユーザは、ＦＩＸ  ＥｘｅｃＩｎｓｔｒフィールドを使用して、ＦＩＸを経て「新規注文」を入力し、チケット（ＥｘｅｃＩｎｓｔｒ＝「保留」のＦＩＸ注文）を新規の注文（保留されていない）から区別するよう選択してもよいし、或いはチケットを全く使用せず、全てのＦＩＸ注文を「新規注文」メッセージとして解釈するよう選択してもよい。「新規注文」メッセージは、次のように取り扱われるのが好ましい。
【００６９】
有効確認。システムは、注文が、サポートされた有価証券における大ブロック量の倍数に対するものであることを有効確認するのが好ましい。別の実施形態では、注文がいかなる量に対するものでもよい。好ましい注文有効確認プロセスにおける別のステップは、注文が価格フィールドを含むことを照合することである。別の実施形態では、この要求は、ユーザが固定価格を選択した場合に撤回され、この場合には、固定注文が、制限なしにフローとしてもよい。好ましい実施形態でサポートされる固定形式は、ＮＢＢＯ中間点に固定されるか、又は全く固定されない。別の実施形態では、当業者に良く知られたように、付加的な固定属性がサポートされる。又、システムは、注文の買い側であるか売り側であるかも有効確認するのが好ましい。又、別の実施形態では、短い売り注文もサポートされる。パラメータＰｅｇＯｆｆｓｅｔは、注文を価格付けしなければならない場合に固定値（ＮＢＢＯ中間点）からのセント数（又はその端数）を決定する。ＰｅｇＯｆｆｓｅｔ属性は、注文が固定されない場合には無視されるのが好ましい。システムは、拒絶された注文を、包含的エラーコードと共にＧＵＩクライアントへ報告するのが好ましい。クライアントがチケットを使用する場合には、有効確認ステップは、注文が関連チケットのサイズを越えずそしてチケットと同じ側にあることもチェックするのが好ましい。注文を入力するクライアントがスポンサーブローカーとのクレジット限界を有する場合には、システムは、有効確認プロセスの一部分として、注文が前記クレジット限界に違反しないことを照合するのが好ましく、このクレジット照合プロセスは、以下に詳細に述べる。好ましい実施形態では、システムが、最後の５秒（又は他の所定の周期）以内に、同じ有価証券及び側において、現在の注文より消極的で且つそのときの基準価格より消極的ある価格で、注文を以前に受け取っている場合には、注文が拒絶される。別の実施形態では、このような高い積極性の注文が受け容れられるが、５秒の遅延が経過するまでは、実行不能とマークされる。更に別の実施形態では、累積周期が経過するまで全ての注文が実行不能であるが、側、価格、及び入力時刻の順に、実行エンジン５０へ提出される。更に別の実施形態では、このような条件がなく、注文は、いつでもいかなる価格でも入力することができ、且つ直ちに実行できるが、常駐注文の価格限界を探るよう試みるために種々の価格レベルをチェックするパターンがあることが特定ユーザに分かったときにヘルプデスクオペレータに通知がなされ、顧客にコールして、そのような振舞いが許されないことを通知する。この実施形態では、ヘルプデスクオペレータは、振舞いが矯正されない場合にシステムで取引する顧客の資格を停止させる特定の基準が与えられる。
【００７０】
好ましい実施形態では、ＩＯＣ注文は、無効として拒絶される。別の実施形態では、ＩＯＣ注文は受け容れられるが、「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知を見る資格のある継続した逆注文の所有者は、逆の者が出したＩＯＣ注文が実行されなかったことが分かる（好ましいＧＵＩにおいて、シンボルがオレンジからイエローに短時間で変化し、次いで、オレンジに戻る）。更に別の実施形態では、ＩＯＣ注文は受け容れられるが、「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知が送信されない。
【００７１】
注文属性。好ましい実施形態のシステムは、次のテーブルに示す「新規注文」メッセージにおいて必要なフィールドを見出すことを期待する。
2007528559.tif 000005
【００７２】
処理。システムは、次のステップにより有効な注文を処理するのが好ましい（図７を参照）。
−  有効確認（ステップ７１０）の後に、ステップ７２０において、有効な注文が実行エンジンへ直ちに通される。応答は、注文が拒絶されたか、又は受け容れられてオープン注文としてブックに入れられたか、或いは実行保留であるかを指示する。実行エンジンからの状態がＮｅｔＳｅｒｖｅｒを経てＧＵＩクライアントへ報告される。
−  クライアントがＦＩＸチケットを使用する場合には、システムは、注文状態を、受け入れ又は拒絶としてＦＩＸを経て報告するのが好ましく（ステップ７３０）、実行保留状態は、ＦＩＸにおいてオープン状態として報告される（その後にロックイン実行メッセージが続く）。ＦＩＸ注文状態更新メッセージは、関連チケットのＩＤを保持する。
【００７３】
−  注文がオープンであることを実行エンジンが指示する場合には、システムは、取引の見込みを高める目的でファシリテータを経てプロセス７４０を開始する。
・  好ましい実施形態では、システムに積極的な逆注文があるかどうか決定する。注文は、それが逆側にあって少なくともシンボルの現在基準価格と同程度に積極的に価格付けされた場合には、積極的な逆注文である。積極的な逆注文をもつユーザは、「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知を直ちに受け取る。現在積極的であるとみなされない逆注文をもつユーザは、基準価格の変化により後で積極的となるや否やこのような通知を受け取る資格をもつ。注文が積極的であると分かった場合に、新たに入力される注文に「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知を送信するために、注文入力時間＋３０秒（又は他の所定の周期）で事象をスケジュールするのが好ましい。これは、常駐の逆注文が通知を受け取る資格があるかどうかに関わらず、行われるのが好ましい。従って、システムに消極的な注文を出すユーザは、そのような注文の存在を、３０秒以上の間積極的な注文を出そうとする者により発見させることができる。別の実施形態では、遅延された「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知は、常駐の逆側がこのような通知を最初に受け取る資格があると分かった場合だけ送信される。
・  別の実施形態では、システムは、注文の入力時に、新規注文の価格が「ブロック価格範囲（ＢＰＲ）」の最新の発表値と少なくとも同程度に積極的であるかどうかも決定し、そしてもしそうであれば、注文に「適度に価格付けされた」とタグ付けする。注文が「適度に価格付けされた」と識別され、そしてシンボルがまだ「アクティブ」状態でない場合には、システムは、「ＡＣＴＩＶＥ  ＳＹＭＢＯＬ」通知を全ユーザへ発行し、この有価証券において注文を出すように彼らに求める。「ブロック価格範囲」も計算する別の実施形態では、「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知は、新規注文の価格が適度に価格付けされた場合しか送信されず、そして注文の価格やＢＰＲの変化により、いずれかの注文がもはや適度に価格付けされないことが後で決定された場合には除去される。
【００７４】
−  ステップ７５０において、システムは、他の注文が到着するのを待機し、逆注文は、上述したように、有効確認ステップ７１０で始めて処理される。同等以上の価格をもつ逆注文は、そのときの基準価格にできるだけ接近して実行されるのが好ましい。
【００７５】
システムは、ユーザが「注文キャンセル」メッセージを入力できるようにするのが好ましい。「注文キャンセル」は、ＣｌｉｅｎｔＯｒｄｅｒＩＤが従来の「新規／置き換え注文」に対応するＧＵＩ／ＡＰＩメッセージである。別の実施形態では、注文キャンセル要求もＦＩＸを経て受け取られる。
【００７６】
有効確認。注文ＩＤが無効であるか、又はオープンされているＣｌｏｕｄ９内で知られていない注文を指す場合には、注文キャンセル要求が拒絶される。
【００７７】
処理。システム１００は、次のステップを経て「注文キャンセル」要求を処理するのが好ましい。
−  Ｃｌｏｕｄ９  ＯＭ１３０は、有効な注文キャンセル要求を実行エンジン５０へ通す。
−  実行エンジン５０は、キャンセルされた株で応答する。キャンセル応答に先行して実行（１つ又は複数）が行われてもよい。満たされた又は期限切れとなった注文については、キャンセル要求が拒絶される。
【００７８】
−  実行エンジン５０から首尾良いキャンセル応答を受け取ると、
・  注文状態更新がＧＵＩクライアント２０及び分析サーバー１６０へプッシュされる。
・  クライアントがＦＩＸチケットを使用する場合には、ＦＩＸを経て状態更新も報告する。
・  この注文に割り当てられたクレジットを解除する。
・  「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知がこの注文に関連して発行された場合には、もはや逆側が存在しなければ、通知を除去する。
・  注：「ＡＣＴＩＶＥ  ＳＹＭＢＯＬ」通知を伴う別の実施形態では、注文キャンセルがこの通知を除去しないのが好ましい。ユーザは、通知に対する応答において両側に注文を出し続け、取引の機会を導くことができる。更に別の実施形態では、「ＡＣＴＩＶＥ  ＳＹＭＢＯＬ」状態が、システムにおける適度に価格付けされた注文の存在に直接リンクされる。
【００７９】
又、システムは、以前に入力された注文を変更するためにユーザがキャンセル／置き換え注文要求を入力できるようにする。好ましい実施形態では、「キャンセル／置き換え注文」は、有効な以前の「新規／置き換え注文」を指すＧＵＩ／ＡＰＩメッセージ（ＣｌｉｅｎｔＯｒｄｅｒＩＤ）である。別の実施形態では、このメッセージも、「新規注文」メッセージについて上述したものと同じコンフィギュレーションオプションで、ＦＩＸを経て入力することができる。
【００８０】
有効確認。ＣｌｉｅｎｔＯｒｄｅｒＩＤは、有効な注文を指さねばならない。システムは、キャンセル／置き換え要求が、キャンセルされ、時間切れとなり又は満たされることが既に知られている注文を指す場合、或いは最小遅延（例えば、５秒）が経過する前に以前の消極的注文に対する価格積極性を高める場合には、このキャンセル／置き換え要求を拒絶するのが好ましく、この機能についての別の実施形態は、「新規注文」メッセージについて上述した。システムは、取引前クレジットチェックをサポートするのが好ましい。それ故、注文のサイズをキャンセル／置き換え要求により増加すべき場合には、システムは、先ず、新たなサイズがユーザアカウントのクレジット限界を越えないことを照合する。クレジットの有効確認に不合格な置き換え注文要求は、クレジット理由を説明する理由コードで無効として拒絶される。
【００８１】
キャンセル／置き換え注文処理。Ｃｌｏｕｄ９  ＯＭ１３０は、キャンセル／置き換え注文メッセージを実行エンジンへ通すことによりそれらメッセージを処理するのが好ましい。実行エンジン５０は、満たされた株、残りのオープン株、及び平均価格を含む注文状態で応答する。
−  取引メッセージ。状態更新がＮｅｔＳｅｒｖｅｒ１１０を経てＧＵＩクライアントへプッシュされる。
−  クライアントがＦＩＸチケットを使用する場合には、ＦＩＸを経て状態更新も報告する。
−  キャンセル／置き換えが注文のサイズを変更する場合には、キャンセル及び置き換えクレジット量が、新規注文を反映するようにこの注文に割り当てられる。
【００８２】
取引メッセージ。実行エンジン５０は、取引メッセージにより注文マネージャー１３０へ取引を報告する。実行エンジンからの各取引メッセージは、厳密に２つの注文を含むロックイン取引を報告する。
【００８３】
実行エンジン５０は、個々の注文を逆注文のブックに対してマッチングさせる（１対多のマッチング）。マッチングチェックの後に多数の個々の取引があり、その各々は、独立して処理される。
取引は単一のトランザクションであるから、取引の両辺をユニットとして報告しなければならない。
【００８４】
システムの好ましい実施形態では、取引メッセージに次のフィールドがあることが予想される。
2007528559.tif 000006
【００８５】
取引メッセージの処理。システム１００は、次のステップを経て実行エンジン５０からの取引メッセージを処理するのが好ましい。
−  両充満を関連ＧＵＩクライアントへ報告すると共に、チケットを使用するか又はＦＩＸ実行を要求するクライアントについては、ＦＩＸを経て報告する。
−  取引の価格に基づき消費したクレジットの実際の量を反映するようにクレジットを更新する。
−  トレーダーがチケットを使用し、そしてチケットの残留量がこのシンボルの大ブロック量未満である場合には、チケットの残留量を吐き出す。
−  ブロックテープメッセージをネットサーバーへ送信し、この有価証券をウオッチするＧＵＩへ配送する。ブロックテープメッセージは次のフィールドを含むのが好ましい。
2007528559.tif 000007
【００８６】
システムは、トレーダーが、単一の要求でシステムに以前に入れた全ての注文を、非常時にキャンセルできるようにするのが好ましい。ＣａｎｃｅｌＡｌｌＣｌｉｅｎｔＯｒｄｅｒは、所与のＧＵＩにより入力された全ての注文のキャンセルを要求するネットサーバーからのメッセージである。別の実施形態では、このメッセージは、ＦＩＸを経て配送することもできる。実行エンジン５０は、顧客ＩＤを知らないので、Ｃｌｏｕｄ９  ＯＭは、オープン状態を有するこのクライアントに関連した各注文を個々にキャンセルして、それらを個々の「注文キャンセル」要求として処理することにより、キャンセル全メッセージを処理する。
【００８７】
「ブロック価格範囲」を含む実施形態では、注文マネージャー１３０は、それがオープン注文を有するところの有価証券において分析サーバー１６０からのＢＰＲ更新メッセージを申し込み、そしてＢＰＲ更新メッセージを受け取るときに適度に価格付けされた状態を更新する。注文の適度な価格状態に変化がある場合には、注文マネージャー１３０は、この有価証券における全ての注文に対して逆の存在状態があるかどうか再評価し、そして上述したように、逆の存在通知を更新する。これが注文の逆の存在状態に変化を生じさせる場合には、システムは、「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知更新を、その影響のあるＧＵＩクライアントへ送信するのが好ましい。「ＡＣＴＩＶＥ  ＳＹＭＢＯＬ」通知を伴う実施形態では、システムは、ＢＰＲ更新メッセージに基づいてこれらの通知も更新する。シンボルがアクティブ状態になり、少なくとも６０秒間（又は他の所定の周期中）この状態にあり、そしてＢＰＲ内の注文がもはやない場合には、シンボルが「不安定(not firm)」状態にセットされ、そしてネットサーバーは、ＳｙｍｂｏｌＳｔａｔｕｓ＝否アクティブである「ＡＣＴＩＶＥ  ＳＹＭＢＯＬ」通知更新メッセージを送信する。別の実施形態では、アクティブシンボル状態がＢＰＲ更新メッセージにおいて更新され、そしてたとえシンボルが安定であるのが６０秒未満であっても、否アクティブ状態にセットされてもよい。更に別の実施形態では、アクティブ状態が、常に、その時点でシステムにおける生きた適度に価格付けされた実行可能な注文の存在を反映するよう保証するために、「全国市場最良付け値及び売り値」価格に対する各変化並びに各注文入力又はキャンセル事象についてアクティブ状態が更新される。
【００８８】
実行エンジン。好ましい実施形態における実行エンジン５０は、Ｃｌｏｕｄ９システム１００と同じファシリティにおいてホストとされ、２つのシステムは、イントラネットを経て通信する。別の実施形態では、実行エンジン５０は、Ｃｌｏｕｄ９システム１００内のコンポーネントであり、両方の実施形態における実行エンジン５０の機能を以下に説明する。実行エンジン５０は、「匿名化」注文を受け取り、これは、注文から買い側顧客ＩＤが剥離され、それに代わって、内部注文ＩＤ及びスポンサーブローカーＩＤにより識別されることを意味する。実行エンジン５０は、到来する注文にマッチングする常駐注文があるかどうか調べるためにチェックし、そして以下に詳細に述べるように、価格時間プライオリティを使用してランク付けされた常駐注文との取引を実行することにより、到来する新規の注文を処理する。
【００８９】
好ましい実施形態における実行エンジン５０は、欠陥があった場合にＣｌｏｕｄ９取引に関する真の状態を回復するためのレコードのブックである。
【００９０】
実行エンジン５０の好ましい実施形態は、限界注文と、ＮＢＢＯ中間ポイントに固定された注文とをサポートする。別の実施形態では、当業者に知られた他の注文形式もサポートされる。例えば、別の実行エンジンは、システムに他の注文が出されたときに価格時間プライオリティランキングのトップ位置を保持するように価格積極性を自動的に高める価格自由裁量注文をサポートしてもよい。このような注文は、自由裁量注文の絶対限界価格に違反しない限り、同じシンボル及び側で最良の他の注文より１チック（小幅）良好に再価格付けされるのが好ましい。別の実施形態の別の例では、システムは、トレーダーが、先の時間間隔に対するボリューム重み付け平均価格（ＶＷＡＰ）、例えば、取引時間から１日の終りまでのＶＷＡＰ、或いは半時間間隔のような特定時間間隔にわたるＶＷＡＰに基づいて、後で価格付けされるべき注文を入力できるようにする。例えば、このような注文は、１１：００−１２：００の将来時間間隔に対してＶＷＡＰより２セント上まで買うように価格付けすることができる。この実施形態では、将来価格付けされる注文に対する「ＡＣＴＩＶＥ  ＳＹＭＢＯＬ」通知は、注文が価格付けされるところの時間間隔を表示し、そしてこのような通知に応答する全ての注文は、当然、同じ将来の平均価格に関して価格付けされねばならない。従って、ＶＷＡＰ時間間隔は、取引されている代替可能なアイテムの定義の一部分を有効に形成する。同様に、別の実施形態では、ユーザは、一対の有価証券で、又は多数の有価証券より成るバスケットで、注文を出すことができる。「ＡＣＴＩＶＥ  ＳＹＭＢＯＬ」通知は、取引単位の組成を記述し、そしてトレーダーは、同じ取引単位で買い又は売り注文に応答することが予想される。これら別の実施形態では、基準価格及び「ブロック価格範囲」をＶＷＡＰ注文又はバスケットへと拡張しなければならない。ＶＷＡＰ注文については、基準価格がＶＷＡＰそれ自体であるが、対及びバスケットについては、基準が、対又はバスケットにおけるインスツルメントの価格の平均を、各アイテムのドル値により、その個々の基準価格に基づいて重み付けしたものである。
【００９１】
全ての注文は、限界注文であるか、又は基準価格に対して価格付けされた注文（固定注文）である。固定注文が限界価格も有する場合には、注文が、より消極的な限界値又は固定値に価格付けされると考えるのが好ましい。ＶＷＡＰ注文のような将来価格付けされる注文を伴う実施形態では、絶対限界価格が許されないのが好ましい。取引がロックインされると、将来の価格がどれほどになるか明らかである。将来価格付けされるＶＷＡＰ注文を伴う別の実施形態では、ユーザは、ＶＷＡＰ注文に対する停止価格を公表することができる。価格付け周期が経過するまでにこの価格レベルを突破した場合には、その周期が早目に終了し、そして取引は、このポイントまでのＶＷＡＰにおいて、株の対応部分に対してのみロックインされる。例えば、＄２１．１５の停止価格で（例えば、現在価格は＄２１．０１とする）次の１時間にわたり将来のＶＷＡＰで１００，０００株を買う注文は、市場価格がその１時間に対して４５分で、＄２１．１５を突破した場合にクローズとなる。３／４の時間が経過したので、取引は、４５分間隔にわたりＶＷＡＰで７５，０００株についてロックインされる。このような停止価格は、買手が価格付け間隔中に急速に価格が揺れ動くリスクから保護し、そして売手は、より強い市場価格で残りの株を出すようにエンジョイする。
【００９２】
実行エンジン５０は、固定注文及び限界注文が相互作用するのを許すのが好ましい。固定注文は、マッチングチェック事象が生じたときに価格付けされ、次いで、より消極的な限界価格又は固定価格で限界注文と動揺に処理される。好ましい実施形態では、固定値は、基準価格としてのＮＢＢＯ中間点に、正でも負でもよいＰｅｇＯｆｆｓｅｔ額を加えたものである。
【００９３】
好ましい実施形態のユーザは、Ｐｅｇを限界注文における保護として使用し、市場が迅速に動くときに、それらの注文が、ＮＢＢＯに比して突然非常に積極的に現われる価格で取引されないよう保証することができる。ＧＵＩ２０は、特徴を「価格保護」として表わし、そして「ＮＢＢＯ中間点価格から＜ｎ＞セントを越えるものを取引しない」というオプションをオファーすることにより、このようにＰｅｇを使用する方法を示唆する。
【００９４】
システムには固定注文及び限界注文の両方があるので、マッチングは、注文の入力時にトリガーされるだけでなく、ＮＢＢＯ価格が変化して、固定注文価格を逆注文の限界価格に交差させる結果としてトリガーされてもよい。
【００９５】
それ故、本発明の好ましい実施形態では、マッチングは、新規注文の入力時にトリガーすることもできるし、ＮＢＢＯ価格が変化して固定注文を他の注文と交差させるときにトリガーすることもできる。システムは、次のプロセスを実行してこのようなマッチングを識別するのが好ましい。
【００９６】
実行エンジン５０は、データプロバイダー６０から全ての相場更新メッセージを受け取り、そしてこの分野で知られた情報キャッシング技術を使用して、現在の最良付け値及び最良売り値を追跡するコンポーネントを備えているのが好ましい。又、実行エンジン５０のコンポーネントは、所与の有価証券に対する価格更新を申し込み、その後、所与の有価証券における最良付け値又は最良売り値に変化があるときにメッセージを受け取ることができるのが好ましい。
【００９７】
実行エンジン５０は、片側に１つ以上の限界注文を及び他側に１つ以上の固定注文を有するシンボルのリストを維持し、そしてこのリストの全ての有価証券に対してＮＢＢＯ価格変更を申し込むのが好ましい。このセクションの目的として、限界価格を伴う固定注文は、それらの価格が実行エンジン５０により受け取られたときに固定値であるとみなされる場合には固定注文であると考えられ、そして入力時に限界注文として価格付けされた（即ち、固定値が限界価格より消極的である）場合には限界注文と考えられる。このリスト内の各シンボルに対して、実行エンジン５０は、固定注文の値が最良の限界逆注文に等しい基準価格の値として定義される買手スレッシュホールド、及び／又は限界買い注文に交差する固定売り注文に対して同様に定義される売手スレッシュホールドをセットするのが好ましい。各々のＮＢＢＯ価格変化の際に、システムは、新たな基準価格を計算し、そしてこの価格が買手スレッシュホールド又は売手スレッシュホールドのいずれかを突破するかどうか決定する。買手スレッシュホールドを突破する場合には、システムは、買い注文がシステムに入力されたかのように、固定買い注文と、価格時間プライオリティでランク付けされた限界逆注文との間の取引を実行するように進み、そして売手スレッシュホールドを突破するときには売り注文に対して逆のことが言える。
【００９８】
多数の固定注文が売り注文に対してマッチングするのに適格なものである場合には、それらがその時点の有効価格に基づいて価格時間プライオリティでランク付けされるのが好ましく、従って、２つの注文が、異なる絶対限界価格とのＮＢＢＯ中間点で固定される場合には、限界価格が無関係なものとなる。というのは、２つの注文が同じ有効価格を有し、そしてそれらのランクが入力の時間で決定され、最も古い注文が最も高いプライオリティレベルになるからである。
【００９９】
実行エンジン５０は、一次市場における取引停止を次のように観察するのが好ましい。有価証券が停止される間には、既存の注文及び新規の注文が全て断られる。実行エンジン５０は、データ売主６０から有価証券取引状態を導出する。データ売主６０がサービスを提供できないか、又はそれに対応する通信ネットワーク７０がフェイルした場合には、実行エンジンは、いかなる取引も処理せず、活力に満ちたサービスが再確立されるのを単に待機する。
【０１００】
好ましい実施形態における市場データフィードは、市場停止情報と、分析サーバー１６０のためのレベル１及び最後の売りデータとを含む。
【０１０１】
新規注文がマッチングをトリガーした場合には、実行エンジンは、予想される合計マッチング量と共に、Ｃｌｏｕｄ９  ＯＭ１３０へ実行保留を直ちに報告するのが好ましい。この報告は、ファシリテータ１４０により使用するための情報に過ぎず、以下に述べるように、取引が認可されることを保証するものではない。
【０１０２】
コンピュータ故障の場合にシステムが取引の片側で報告するが、他側では報告しないリスクを回避するために、この技術で知られたソフトウェアプログラミング方法を使用して、取引が単一のトランザクションとして処理されるのが好ましい。取引の処理は、次のステップを含むのが好ましい。
【０１０３】
１．取引を必要に応じて取締組織へ報告し、そしてデータベースにおいて注文状態を更新する。好ましい実施形態では、取引がＮａｓｄａｑ  ＡＣＴシステムに報告される。マッチングエンジンは、データ普及（テープ報告）及び認可目的でＡＣＴに直ちに報告を行う。
【０１０４】
２．取引が認可のために首尾良くロックインされると（ＡＣＴが取引の報告を確認しそしてＡＣＴ報告ＩＤを指定すると）、実行エンジン５０は、安定取引報告メッセージを注文マネージャー１３０へ送信するのが好ましい。固定注文を伴う取引は、ＮＢＢＯ中間点を計算するのに使用された最新の付け値のタイムスタンプ及び最新の売り値のタイムスタンプと、実行が処理されたところのタイムスタンプと共に、報告されるのが好ましい。
【０１０５】
実行エンジン５０は、到来するメッセージを次のように処理する。
新規注文処理。新規注文は、ＯＭ１３０からのメッセージである。これは、次のように処理されるのが好ましい。
−  マッチングする注文がもしあれば、それを識別し、そして注文入力を状態と共に注文マネージャー１３０へ確認する。
−  注文が満たされないが、片側に限界注文があり且つ他側に固定注文がある状態を生じさせる場合には、有価証券のＮＢＢＯ価格更新を登録する。
−  取引を上述したように処理する。
【０１０６】
注文キャンセル。注文キャンセルは、オープン注文をキャンセルするためのＣｌｏｕｄ９  ＯＭからの要求である。これは、次のように処理されるのが好ましい。
−  注文キャンセル要求がブック５１における注文を指す有効注文ＩＤを保持するかどうか照合する。
−  注文が既に取引された場合には、注文キャンセル要求メッセージを拒絶する。
−  注文がまだ取引されない場合には、
・  注文状態を実行エンジンデータベース（ブック５１）においてキャンセルとマークする。
・  首尾良いキャンセル状態を注文マネージャー１３０へ報告する。
【０１０７】
好ましい実施形態では、注文は、上述したように消極的注文の価格積極性を高める以外は、いつでも変更又はキャンセルすることができる。別の実施形態では、注文は、ファシリテータ１４０によりトリガーされる事象、例えば、「ＡＣＴＩＶＥ  ＳＹＭＢＯＬ」又は「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知に反応するための適度な時間を他の参加者に与えるために、１０秒の強制最小時間をもつことが要求される。
【０１０８】
又、システムは、注文マネージャー１３０が、所与のスポンサーブローカーに関連した全ての注文をキャンセルし、又は全ての注文を一緒にキャンセルすることを要求できるようにすることが好ましい。実行エンジン５０は、先ず、影響のある全ての注文を識別し、次いで、注文キャンセル要求を注文の入力時間で処理することにより、このような総計注文キャンセル要求を処理する。
【０１０９】
実行エンジン５０は、３０秒の心臓鼓動を使用して注文マネージャー１３０との接続を有効確認するのが好ましい。接続が失われると、システムは、全ての注文をキャンセルするのが好ましい。
【０１１０】
ネットサーバー。システムは、クライアントＧＵＩ２０がインターネットのような通信ネットワーク８０を経てネットサーバー１１０に接続できるようにするアプリケーションプログラミングインターフェイスを備えているのが好ましい。ネットサーバー１１０は、顧客のフロントエンドアプリケーションが、ＢＰＲの更新を見たりシステムに注文を入力したりといったＣｌｏｕｄ９取引サービスにアクセスするのを許す。
【０１１１】
クライアントへの接続が失われたことが検出された場合には、Ｃｌｏｕｄ９は、実行エンジン５０でクライアントの全ての注文をキャンセルするよう試みるのが好ましい。別の実施形態では、システムは、接続が失われてもオープン注文をキャンセルしないコンフィギュレーションをクライアントが選択するのを許し、この別のコンフィギュレーションを選択するクライアントは、非常時に注文をキャンセルするにはヘルプデスクをコールしなければならない。
【０１１２】
ネットサーバー１１０は、取引活動メッセージ（注文、キャンセル／置き換え、キャンセル）を注文マネージャーへ通すと共に、応答及び求められていないメッセージをクライアントに返送する。又、クライアントＧＵＩコンフィギュレーション、例えば、スクリーン上のウインドウの位置及びサイズや、トレーダーがウオッチしたい有価証券のリストも記憶する。これらの例は、余すところのないリストを構成するものではなく、例示のためのものに過ぎず、当業者により容易に明らかなように通常のＧＵＩ表示オプションをサポートするために他のコンフィギュレーションパラメータが記憶される。
【０１１３】
好ましい実施形態では、ＧＵＩは、利用可能なクレジットの量が、大ブロックトレーディングを実行するのに通常必要なドル額より下がったときに、システムにより発生されるクレジットアラートをトレーダーが見ることができるようにする。別の実施形態では、クレジットアラートが表示されず、ユーザは、注文入力要求がフェイルしたときに充分なクレジットが存在しないことを単に発見する。
【０１１４】
本発明の別の実施形態では、ＧＵＩ２０は、トレーダーが、有価証券のウオッチリストの管理を容易にするダイアログにアクセスできるようにする。ウオッチリストの目的は、システムから、トレーダーに関心のあるシンボルへの情報の流れを制限することである。この実施形態では、システムは、誰かがオープンＧＵＩで所与のシンボルを現在ウオッチしているかどうかトレーダーに分かるようにするのが好ましい（これは、取引の見込みを高めるので関心をもたせるものである）。別の実施形態では、ＧＵＩ２０は、有価証券をウオッチングしているトレーダーの数がユーザに分かるようにする。ＧＵＩ２０は、ウオッチされた有価証券のみにおいてＢＰＲ更新メッセージと、「アクティブシンボル」及び「逆の存在」メッセージの受信とを登録する。好ましい実施形態では、ＡＰＩは、ＧＵＩが、任意の有価証券においてＢＰＲ／アクティブ／逆の存在メッセージを登録し、そしてそれとは別に、有価証券の個別リストにおいて相場更新メッセージを登録するのを許す。好ましいＧＵＩ２０は、一度に１つの有価証券に対してＮＢＢＯ価格を表示するだけであり、即ち図２に示すように、注文入力ダイアログがオープンであるところのものを表示する。別の実施形態では、ＧＵＩは、ウオッチされた全ての有価証券におけるＮＢＢＯ更新を申し込み、これらの価格は、ドロップリストにおいてシンボルの隣に表示される。
【０１１５】
ウオッチリストを管理するために、ユーザは、個々のシンボルを追加できるか、或いは工業グループ又はセクターのような有価証券の既知のグループ内にあると分類された全てのシンボルを追加できるのが好ましい。又、システムは、ユーザが、それら自身の有価証券グループをエクセルファイルの形態で提出し、そしてこれらのグループをシステムにロードすることができるようにし、この点において、それらは、トレーダーが自分のウオッチリストをポピュレートするために選択できる有価証券グループのリストに単に追加される。
【０１１６】
好ましいウオッチリストコンフィギュレーションダイアログが図８に示されている。ユーザは、シンボル又はシンボルのグループを追加することができる。ユーザが変化をセーブするまで変化は保留状態にある。又、ユーザは、以前のセーブされたウオッチリストに復帰することもできるし、或いは例えば、それらのＯＭＳ又はプロッターから導出できるエクセルスプレッドシートから有価証券のグループをロードすることもできる。
【０１１７】
ウオッチリストは、クライアントにより管理されそしてサーバーに持続されるのが好ましい。
ウオッチされるシンボルの通知を伴う実施形態では、ネットサーバー１１０は、どのシンボルが２つ以上のＧＵＩにより「ウオッチ」されるか追跡するのが好ましい。シンボルがトレーダーのウオッチリストに追加されて、ウオッチするクライアントの数を２に到達させる場合には、ネットサーバー１１０は、アクティブシンボルメッセージを申し込む全てのＧＵＩにメッセージをブロードキャストして、シンボルがウオッチされていることを指示する。ウオッチするＧＵＩの数が１に下がった場合には、ネットサーバーは、アクティブシンボル更新を申し込むＧＵＩにメッセージをブロードキャストして、このシンボルがもはやウオッチされないことを指示する。別の実施形態では、ユーザがシンボルにウオッチを追加するか又は除去し、そしてシンボル、タイムスタンプ、及びシンボルをウオッチする当事者の更新された数を与えるときに、メッセージが送信される。
【０１１８】
ＧＵＩ２０は、トレーダーのウオッチリストにあって且つアクティブであるか又は逆が存在する全てのシンボルを示すのが好ましい。これは、「ＡＣＴＩＶＥ  ＳＹＭＢＯＬ」通知を含む実施形態ではアクティブシンボルに対してオレンジ色を、そして「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知に対して黄色を使用して、カラーコード長方形によりＧＵＩの頂部においてそれらをハイライト化することにより行われる。別の実施形態では、ウオッチされるシンボルがアクティブになるか又は逆が存在することを指示するメッセージが、インスタントメッセンジャーアプリケーションと同様の一時的ポップアップスクリーンにより表示される。別の実施形態では、これらのポップアップメッセージは、クリックして注文入力ダイアログを発生しそしてメッセージに応答して注文を入力するか、或いは「クローズ」又は「最小化」ボタンをクリックして、ポップアップをクローズするか、又はそれをスクリーンの底部のバーまで減少することにより、アクションが取られるまで見えるままにする。
【０１１９】
好ましい実施形態におけるトレーダーＧＵＩ２０は、「ウオッチされる」状態（即ち、少なくとも１人の他のトレーダーがシンボルをウオッチしている）にあるウオッチリストにおいてシンボルを示すか又は示さないオプションを有する。これらのシンボルを見るように選択した場合に、「アクティブ」でないか又は逆が存在するとき、トレーダーの注意を直ちに必要としないので他の２つより目立たない第３のカラーで表わされ、好ましい実施形態においては、ＧＵＩ２０は、ウオッチされるシンボルを、アクティブ及び逆が存在する長方形の隣のグレーの長方形で示す。
【０１２０】
ネットサーバー１１０は、リモートクライアントがシステムのサービスにアクセスするためのＡＰＩを露出させるのが好ましい。ＡＰＩは、ユーザが、取引サービスを利用する前に、基本的な認証（ユーザ名パスワード）によりセッションをオープンできるようにするのが好ましい。別の実施形態では、クライアントは、証明書でそれ自身を認証する。ユーザ証明書の交換は、ネットサーバーパブリックキーを使用して暗号キーを交換するＳＳＬセッションを経て行われるのが好ましい。ユーザが認証されると、セッションがユーザ認識へとマップする。
【０１２１】
ネットサーバーＡＰＩは、次の機能を露出させるのが好ましい。
−  ゲット・セクター・リスト(Get Sector List)：各会社は、セクター又は他の有価証券グループ分けによりアレンジされた有価証券を任意にもつことができる。有価証券のグループは、クライアントの会社ごとに構成することができる。ＡＰＩは、クライアントの会社及びグループ名に関連した有価証券のリストを返送する。
−  ゲット・有価証券・リスト(Get Security List)：システムは、構成された有価証券のリストを有する。この機能は、そのリストを返送する。リストの各エレメントは、シンボル、会社名、及びセクターである。
【０１２２】
−  セット・アンド・ゲット・トレーダー・デフォールト(Set & Get Trader Defaults)：システムは、クライアントがデフォールトパラメータを記憶できるようにする。次のリストは、余すところのないものではなく、特に関心のある幾つかのトレーダー・デフォールトを含み、当業者であれば、他のものも明らかであろう。
・  デフォールト提出量(Default Placed amount)：注文入力ダイアログは、デフォールトによる量フィールドを、このシンボルに対する最小量（大ブロック量）、又はトレーダーがチケットを使用する場合にはトレーダーの合計チケットサイズでポピュレートする。
・  デフォールト価格(Default Price)：注文入力ダイアログは、価格フィールドを、次のルールの１つにより選択された限界価格でポピュレートする。即ち、ＮＢＢＯの積極端、ＮＢＢＯの消極端、ＮＢＢＯの中間点、及びＢＰＲを含む実施形態の場合には、ＢＰＲの積極端、ＢＰＲの消極端、又はＢＰＲの中間点。
・  デフォールトＴＩＦ(Default TIF)：注文入力ダイアログは、強制時間フィールドをこの秒数でポピュレートする。
・  デフォールト・ウオッチ・リスト・マネージメント(Default Watch List Management)（有価証券、セクター）：全てのウオッチリストマネージメントは、フロントエンドにより取り扱われ、サーバーに維持される。
・  デフォールトＰｅｇ及びオフセット(Default Peg and offset)：注文入力ダイアログは、デフォールトによりＰｅｇオプションを選択してもしなくてもよく、選択する場合には、このセント数を買い注文に対するＰｅｇＯｆｆｓｅｔとして加算するか、又は売り注文に対する中間点Ｐｅｇについてこのセント数を減算する。
・  チケット型注文のみ(Ticketed Orders Only)：このオプションは、トレーダーがチケットにより予約されたサイズに対して注文をチェックすることを望むかどうか決定する。このオプションが選択されない場合には、トレーダーは、対応するチケットがないときでも注文を入力することができる。
・  セット・アンド・ゲット・セクター・ウオッチ・リスト(Set & Get Sector Watch List)：セクター又は他のグループを含むセキュリティのリストをセーブしそして検索する。
・  セット・アンド・ゲット・シンボル・ウオッチ・リスト(Set & Get Symbol Watch List)：所与のウオッチリストにある有価証券のリストをセーブしそして検索する。
【０１２３】
−  セット＆ゲット・ＧＵＩ・デフォールト(Set & Get GUI Default)：
・  チケット・マネージメント・グリッド(Ticket Management Grid)：チケットのリストをオープンにして又は隠して表示するウインドウでアプリケーションをスタートするオプション。
・  チケット・マネージメント・グリッド定義(Ticket Management Grid definition)：フォント、フィールド注文、ｃｏｌサイズ、ｃｏｌタイプ、ヘッダー、及びフィールド＝ｃｏｌマッピング。
・  カラー変化(Color Changes)（イエス、ノー）：ＧＵＩは、注文がシステムに既に提出されそしてこのフィールドがそれ以来編集されたときに、ユーザがこのオプションを選択して注文入力ダイアログにおいて注文のフィールドをハイライト化するのを許すのが好ましい。フィールドが編集されたときに、ユーザは、「置き換え」キーを押し、キャンセル／置き換え注文メッセージを経てシステムへ新たな値を送信することができる。編集されたフィールドをハイライト化することで、ユーザが注文を管理する上で助けとなる。
【０１２４】
−  ゲット心臓鼓動間隔(Get Heartbeat Interval)：ＧＵＩ２０とネットサーバー１１０との間の接続が機能するかどうか決定するための周期的心臓鼓動に対する秒数。システムは、接続マネージメントデューティでネットサーバー１１０が過負荷になるのを回避するためにこのパラメータに下限を課すのが好ましい。別の実施形態では、パラメータをサーバーにしかセットできず、ＡＰＩを経て露出させることができない。
【０１２５】
−  ゲット・チケット(Get Tickets)：ユーザのチケットを入手する。取引日の中で、ユーザは、シンボル／側当たり１つのチケットしかもつことができない。チケットがキャンセルされた場合には、サイズが非実行サイズに減少する。同じシンボル及び側をもつ新規なチケットが、リスト内の入力に置き換わる。
【０１２６】
−  ゲット注文(Get Order)：全ての注文のリストを入手する。
−  ゲット注文状態(Get Order Status)：ＣｌｉｅｎｔＯｒｄｅｒＩＤに対する注文詳細を返送する。
−  新規注文提出(Submit New Order)：新規注文をシステムへキューイングする。ＯｎＯｒｄｅｒＵｐｄａｔｅ又はＯｎＯｒｄｅｒＲｅｊｅｃｔ事象でフォローアップされる非同期コール。
【０１２７】
−  注文置き換え(Replace Order)：この機能は、注文置き換え要求をキューイングする。発呼者は、注文状態を返送時に「置き換え保留」であると仮定する。ＯｎＯｒｄｅｒＵｐｄａｔｅ又はＯｎＯｒｄｅｒＲｅｊｅｃｔ事象でフォローアップされる非同期コール。置き換えられた注文の詳細は、新規注文の詳細＋ＯｒｉｇＣｌｉｅｎｔＩＤフィールドと同じである。量は、満たされたサイズを含む合計量である。
【０１２８】
−  注文キャンセル(Cancel Order)：この機能は、注文キャンセル要求をキューイングする。発呼者は、注文状態を返送時に「キャンセル保留」であると仮定する。ＯｎＯｒｄｅｒＵｐｄａｔｅ又はＯｎＯｒｄｅｒＣａｎｃｅｌｌｅｄ事象でフォローアップされる非同期コール。
【０１２９】
−  取引実行(Execute Trade)：この機能は、この取引をスポンサーブローカーに報告して割り当てプロセスを設定することを要求する。これは、取引日の終りに自動的に行われる。
【０１３０】
−  Get Trades for (ClientOrderID, Symbol, or ALL)：取引詳細を検索するための要求／応答。この要求については、３つのバージョンがあるのが好ましい。即ち、次のものについて取引を得る；ある注文、ある有価証券の全ての注文、又はこのＧＵＩクライアントに対する全ての取引。
【０１３１】
次は、ＡＰＩ事象であり、即ちシステムにより発生されてＡＰＩを経てＧＵＩ２０へプッシュされるメッセージである。
−  ＯｎＴｉｃｋｅｔＵｐｄａｔｅ：この事象は、新規、置き換えられた及びキャンセルされたチケット事象において生じる。
−  ＯｎＯｒｄｅｒＵｐｄａｔｅ：この事象は、注文状態が変化するときに生じる。これは、他のチャンネルより上又は他のチャンネルを通る要求に対する注文マネージメント応答を含む。
−  ＯｎＯｒｄｅｒＲｅｊｅｃｔ：この事象は、このセッション内に入力された新規／置き換え注文要求に応答して生じる。
−  ＯｎＣａｎｃｅｌＲｅｊｅｃｔ：この事象は、キャンセル要求が拒絶されたときに生じる。
−  ＯｎＴｒａｄｅ：この図小は、このＡＰＩ又は別のチャンネルを通して入力されたトレーダー注文の１つの中に取引があったときに生じる。
【０１３２】
又、ネットサーバー１１０の好ましい実施形態は、有価証券ごとの市場データを申し込み、そしてハードディスクのようなコンピュータ読み取り可能な媒体にデータを記憶するためのインターフェイスもなす。フィールドは、（ＮＢＢＯ付け値、アスク及びＴａｐｅＴｉｍｅＳｔａｍｐ）、（ＢＰＲロー及びハイ）、ブロックテープ（最後及び合計ボリューム）、アクティブシンボル、逆の存在、有価証券状態（オープン、クローズ、停止、等）、及びタイムスタンプを含む。このインターフェイスの好ましい実施形態に露出される機能は、次の通りである。
【０１３３】
−  申し込み要求／応答(Subscribe Request/Response)：この機能は、要求メッセージで与えられる有価証券のリストをクライアントの申し込みリストに追加するのが好ましい。この要求は、要求されたフィールドに対するその入力の現在データのスナップショットを返送する。ウオッチされるフィールドへのその後の変化は、変化を伴う更新事象（ＯｎＵｐｄａｔｅ）を生じさせる。
−  申し込み解除要求／応答(Unsubscribe Request/Response)：申し込み要求を除去する。
−  ＯｎＵｐｄａｔｅ事象：申し込み者に、申し込み入力内のフィールド変化を通知する。
−  アクティブシンボル供給スタート要求／応答(Start Active Symbol Feed Request/Response)：アクティブシンボルフラグがセットされた全てのシンボルのリストを返送する。コールに続いて、アクティブシンボルフラグにおける全ての状態変化は、ＯｎＡｃｔｉｖｅＳｙｍＣｈａｎｇｅ（Ｓｙｍｂｏｌ、Ｏｎ／Ｏｆｆ）を生じさせる。
−  アクティブシンボル供給ストップ要求／応答(Stop Active Symbol Feed Request/Response)：前記事象通知を終了する。
−  ＯｎＡｃｔｉｖｅＳｙｍＣｈａｎｇｅ事象は、申し込み者に、アクティブシンボルフラグの変化を通知する。
【０１３４】
リサーチデータ記憶：このシステムは、システムのアクティビティに関する情報を、ハードディスク又はテープのようなコンピュータ読み取り可能な媒体に記憶するのが好ましい。この記憶されたデータは、オペレータ及びサーチスタッフが、システムアクティビティの種々のゲージを監視し、より詳細には、シンボルにおけるトレーダーアクティビティの異なる尺度が、ユーザが注文を入力するときに充満率にどのように相関しているか評価できるようにする。この情報は、マーケッティング媒体やトレーダーのワークステーションへの訪問を通して大きな成功を導くワークフローに向かってシステムの使用を舵取りする上で重要な役割を演じる。例えば、ウオッチされていない有価証券における注文の入力に続く充満率が非常に低いか又はナルである場合には、トレーダーは、他のトレーダーによりウオッチされている有価証券においてシステムにそれらの取引を集中させるようにアドバイスされてもよい。又、システムは、システムにおける充満率を改善するためにフラグを送出するときのルールを変更するように構成し直すこともできる。例えば、有価証券をウオッチしているトレーダーが３人以上のときの方が、２人のときより、充満率が実質的に高いことが決定された場合には、システムは、ＧＵＩユーザの合計数が、２以上ではなく、３以上であるときだけ、ウオッチされたシンボルメッセージを送出するように再構成できる。前記の例は、例示に過ぎず、余すところのないリストを与えるものではなく、当業者であれば、上述したパラメータの変更に基づく他の最適化が明らかであろう。
【０１３５】
トレーダーアクティビティ尺度は、ヘルプデスクにおいて入手でき、考えられるシステムコンフィギュレーション設定と、より高い充満率との間の相関を見出す目的でオフライン分析のために毎日の終りに永久的なデータレポジトリーにエクスポートされる。
【０１３６】
関心のある尺度は、次のとおりである。
−  注文アクティビティ（入力、ＢＰＲ積極性の変化、キャンセル／時間切れ）
−  充満
−  チケット
−  シンボルのアクティブフラグを見ることのできるトレーダーの数（ウオッチリストにおいて、シンボルとして、又はセクターの一部分として）
−  ＢＰＲ更新を見ることのできるトレーダーの数（申し込み者）
−  相場更新を見ることのできるトレーダーの数（申し込み者）
【０１３７】
以下のデータテーブル（Ａ−Ｄ）は、標準的なカンマ区切り（ＣＳＶ）フォーマットで記憶される。
テーブルＡ．チケットテーブル
2007528559.tif 000008
【０１３８】
テーブルＢ．注文テーブル
2007528559.tif 000009
【０１３９】
テーブルＣ．取引テーブル
2007528559.tif 000010
【０１４０】
テーブルＤ．ウオッチリストテーブル
2007528559.tif 000011
【０１４１】
分析サーバー
好ましい実施形態における分析サーバー１６０は、売主相場フィード６０を聴取し、そして最良の価格を形成した相場がキャンセルされるか、又はより良好な価格を伴う新規の相場により改善されたときに、前記ＮＢＢＯ価格を更新することにより、全国最良付け値及び売り値価格を追跡する。現在ＮＢＢＯ価格は、ハードディスク又はテープのようなコンピュータ読み取り可能なメモリに記憶されるのが好ましい。ＮＢＢＯ価格に加えて、分析サーバー１６０は、最近の相場及び取引データに基づいてブロック付け値及びブロック売り値を計算する。
【０１４２】
分析サーバーの主たる機能は、次のメッセージを発生することである。
−  ＮＢＢＯ価格変化、及び
−  ブロック価格範囲を含む実施形態については、ＢＰＲ更新メッセージ
【０１４３】
分析サーバー１６０は、サポートされた全ての有価証券における１日全体にわたる内部付け値又は売り値価格の全ての変化及び最後の販売データを記憶する。分析のために記憶する必要のあるデータをテーブルＥ及びＦに示す。
【０１４４】
テーブルＥ．内部市場価格更新
2007528559.tif 000012
【０１４５】
テーブルＦ．最後の販売
2007528559.tif 000013
【０１４６】
分析サーバー１６０は、内部市場最良付け値価格又は最良売り値価格に変化が生じたときに、全ての接続されたクライアントに相場更新メッセージを配送する。更新メッセージは、新規な付け値価格又は新規な売り値価格と、この付け値又は売り値を変化させた相場の出現又は除去に関連したタイムスタンプとを保持する。
【０１４７】
又、分析サーバー１６０は、６０秒ごとにＢＰＲを更新し、そしてＢＰＲを伴う実施形態では、その注文の価格積極性を決定する目的でＢＰＲ更新メッセージを注文マネージャー１３０へ送信すると共に、ＧＵＩクライアント２０へブロードキャストするためにネットサーバー１１０へも送信する。
【０１４８】
ブロック価格範囲の計算を含む実施形態は、ＢＰＲを計算する役割を果たす交換可能なモジュールを備えている。ＢＰＲは、当業者に良く知られた方法を使用して計算することができ、例えば、ブロック付け値を、全国最良付け値価格から５セントを引いた価格に等しくし、そしてブロック売り値を、全国最良売り値に５セントを加えた価格に等しくすることにより、計算することができる。別の例では、ＮＢＢＯ価格に加える（又はそこから差し引く）セント数は、株の乱高下経歴に比例するようにセットされ、従って、技術的な争点のような乱高下の激しいシンボルについては、変化が５セントを越えることがあるが、優良株ユーティリティのような堅実な株については変化がより少ない。
【０１４９】
ＢＰＲを計算するためのより正確なアルゴリズムの一例では、過去の６０秒間に取引された最高及び最低価格、各々、Ｈ及びＬと、現在のＮＢＢＯ中間点価格Ｍとを考慮し、そして次のステップ（図９）によりブロック付け値及びブロック売り値を計算する。
−  ステップ９１０：前記で定義された所与の有価証券に対する価格Ｈ、Ｌ及びＭを決定する。
−  ステップ９２０：最後のＢＰＲ更新のタイムスタンプまで戻る最後の売りデータを見て、現在ＮＢＢＯ中間点から最も離れてプリントされた取引を見つける。Ｘが、この取引価格と、現在ＮＢＢＯ中間点との間の絶対価格差を表わすとする。従って、Ｘは、Ｈ−Ｍ及びＭ−Ｌの大きい方である。
【０１５０】
−  ステップ９３０：Ｚ＝Ｙ＋（ＭａｘＢｌｏｃｋＳｐｒｅａｄ／２−Ｙ）＊（１＋１／（１＋ｅｘｐ（−ＢＥＴＡ＊Ｘ））とする。但し、Ｙは、有価証券ごとにセットされるパラメータで、ブロック付け値と最良売り値との間の開きに対する下限をセットするものであり、ＭａｘＢｌｏｃｋＳｐｒｅａｄは、前記開きに対する上限であり、そしてＢＥＴＡは、例えば、１０．０にセットできるパラメータである。
−  ステップ９４０：ブロック付け値をＭ＋Ｚに等しくなるように計算し、そしてブロック売り値をＭ−Ｚに等しくなるように計算する。
−  ステップ９５０：ＢＰＲ更新メッセージを注文マネージャー１３０及びネットサーバー１１０へ発行する。
【０１５１】
これらの例は、例示のためのものであり、当業者であれば、ブロック価格範囲を計算する他の手段が容易に考えられよう。
【０１５２】
クレジットマネージメント：システムは、スポンサーブローカーが彼等の顧客アカウントに対してクレジット限界をセットできるようにするのが好ましい。好ましい実施形態では、買った株と売った株との合計値を数えて、総ドル限界に基づいて、クレジットチェックが行われる。注文は、ＢＰＲのトップ又は注文限界価格の大きい方に基づいてクレジットに対して有効確認され、そしてクレジットは、注文が完全に満たされ、時間切れし、又はキャンセル（部分的充満において）されたときに消費された実際のクレジット量に基づいて調整される。
【０１５３】
−  ブローカーにはクレジットを管理するためのウェブアカウントが与えられ、即ち彼等は、クライアントにより現在消費されるが、次のように貯蔵(bin)のみされているクレジットのレベルを見ることができる。２５％未満；２５−５０％；５０−７５％；７５％より多く。
−  ブローカーは、今日のクレジットを即座の作用で増加できるか、或いは各取引日の始めにリフレッシュしたクレジットの量を増加又は減少できねばならない。又、ブローカーは、クレジットを保留することもでき、これは、その日の内及びその後の日々に作用する。その日のクレジットが保留される場合には、システムは、全てのオープン注文をキャンセルする。
−  ブローカーは、後で、クライアントに対するクレジットを保留解除することができる。保留は、永久的な作用を有し、翌日へと持続する。クレジットは、１日の終りにリフレッシュされる。
−  ブローカーは、クレジットアラートスレッシュホールドを合計のあるパーセンテージ（デフォールト＝７５％）として設定することができ、更に、システムは、利用可能なクレジットが、ブロックシステムを利用するには低過ぎるシステム構成ドル額ＭｉｓＣｒｅｄｉｔＡｍｏｕｎｔ（例えば、＄２百万）より下がったときにアラートを発生する。クレジットアラートは、ヘルプデスク要員へ配送されそしてクライアントＧＵＩへプッシュされる。
【０１５４】
ヘルプデスク：システムは、顧客からのコールを取り扱う要員により使用されるべきヘルプデスクインターフェイスを備えているのが好ましい。このユーザインターフェイスは、アクセスがパブリックキー暗号化及び証明書ベースの認証、並びにユーザ名及びパスワード対により確保されるようなウェブブラウザインターフェイスでよい。このインターフェイスは、ユーザが注文の寿命に関する詳細な情報を見ることができるようにするのが好ましい。ユーザは、所与のシンボル及びクライアントＩＤで注文のリストをプルアップし、顧客がコールする注文を探索することができる。ヘルプデスクインターフェイスは、そのユーザが関心のある注文をクリックして、次のメッセージを時間順に見ることができるようにする。
【０１５５】
−  もし適用できれば、チケット
−  注文入力要求（１つ又は複数）
−  注文入力応答：拒絶（理由コードを伴う）；実行保留；時間切れ；オープン
−  充満
−  注文に対して送信されたＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ通知（１つ又は複数）
−  変更注文要求及び応答（受け容れ、拒絶）
−  キャンセル要求及び応答（受け容れ、拒絶）
−  時間切れ
【０１５６】
更に、ヘルプデスクオペレータは、ＮＢＢＯ内部価格、付け値側及び売り値側に各々見られる最新の相場のタイムスタンプ、ＢＰＲ価格、及び注文の寿命における各顕著な事象（入力、キャンセル、実行）のタイムスタンプを見ることができる。これは、注文が入力されたとき等にアクティブな状態に対して何故シンボルが変化するか又は変化しないかといった質問に解答するのに使用される。
【０１５７】
別の実施形態では、ヘルプデスクオペレータは、トレーダーが団体顧客に関心のある取引を知っていることに関連したセキュリティリスクを減少するために、注文の側又はシンボルを見ることができない。この実施形態では、ヘルプデスクオペレータは、各注文の入力時間及びサイズ、並びにトレーダーのＧＵＩ２０で見ることのできるＣｌｉｅｎｔＯｒｄｅｒＩＤと共に、トレーダーに関連した注文のリストをプルアップすることにより、発呼者の注文を識別する。ヘルプデスクオペレータは、トレーダーと共に働いて、どちらの注文に問合せするか識別し、次いで、上述したように、注文をクリックすることにより、対応するアクティビティトレイルを見る。
【０１５８】
又、好ましい実施形態では、ヘルプデスクは、オペレータがドロップリストからクライアントの会社を選択し、そして取引の論理に関するそれらのコンフィギュレーションを見ることができるようにする。以下のリストは、ヘルプデスクオペレータのためのより重要なユーザコンフィギュレーション及び使用統計学情報を与え、このリストは、余すところのないものではなく、当業者であれば、他のものも容易に明らかであろう。
【０１５９】
−  クレジット限界及び消費したクレジット
−  トレーダーによるアクティビティ：注文の数、取引株、取引ドル
−  トレーダーのリスト：トレーダーオプションを見て編集するためのものを選択
−  ウオッチリスト管理（追加／除去シンボル、追加／除去工業グループ）
−  アクティブシンボルバーを指示する／指示しない
−  チケットのドロップリストを指示する／指示しない
−  デフォールトチケット属性
【０１６０】
又、好ましい実施形態では、ブローカーは、ヘルプデスクオペレータの場合と同じ認証及びセキュリティモデルを使用してウェブページにアクセスすることができる。ブローカーは、このページをクレジット管理目的に使用する。クライアントの信頼性を維持するために、インターフェイスは、ブローカーに表示される情報を、クライアントの取引の詳細を露呈しないように制限するのが好ましい。この実施形態では、ブローカーは、クライアントにより消費されたクレジットの量を全クレジット限界のパーセンテージとしてのみ見ることができ、例えば、これは、４つの間隔、即ち２５％未満、２５−５０％、５０−７５％、及び７５％を越える、で貯蔵することができる。スポンサーブローカーは、更に、次の機能を通してクライアントのクレジットを変更することができる。
【０１６１】
・  １日の内のクレジットを追加する
・  本日クレジットを追加すると共に、翌日のリフレッシュ量を増加する
・  翌日のリフレッシュ量を下げる
・  保留クレジット
・  非保留クレジット
【０１６２】
別の実施形態では、取引がスポンサーブローカーに直ちに報告され、そしてスポンサーブローカーは、実行された取引と、消費したクレジットの正確な量とを見ることができる。更に別の実施形態では、スポンサーブローカーは、取引前のアクティビティを見ることもできる。
【０１６３】
システムコンフィギュレーションインターフェイス：システムは、オペレータが、時間外のシステム保守スケジュール中に、コンフィギュレーションを変更して、スポンサーブローカーのクライアントを追加／除去できるようにする。
【０１６４】
システムコンフィギュレーションインターフェイスは、システムオペレータが、クライアントを追加すると共に、ユーザが取引を行えるのに必要なコンフィギュレーション属性をセットすることができるようにする。新規クライアント会社は、利用可能なブローカーのリストからスポンサーブローカーを選択しなければならない。スポンサーブローカーは、同じ会社の中の全てのトレーダーに対して独特であるのが好ましい。別の実施形態では、同じ会社が複数のスポンサーブローカーを使用することができ、そしてＧＵＩ２０は、トレーダーが注文入力時にスポンサーブローカーを選択するようにさせる。新規の会社は、ＦＩＸサービス局を経て、又はスポンサーブローカー９５を通して、ＦＩＸサーバー１２０への直接的なＦＩＸ接続を任意に設定することができる。後者のケースでは、スポンサーブローカーは、クライアントからＦＩＸサーバー１２０へそれに代わってＦＩＸメッセージを転送する。会社は、ワークフロー要求に基づいてＦＩＸ接続性の２つのモードを選択することができ、即ちＦＩＸチャンネルは、実行のみを受け取るか、或いは実行及び注文更新を受け取るように設定することができる。又、それらは、チケットを入力して、チケットにより割り当てられるサイズに対してＧＵＩ入力注文をチェックするか、或いはチケットを使用せずに機能するように設定することもできる。クライアント会社がシステムに追加されるときには、ヘルプデスク要員がブローカーにコールして、顧客のアカウントに対するクレジット限界を設定すると共に、１日の終りの報告に使用すべきクライアントＩＤに合意するようにさせる。新規ユーザは、システムにおいて取引できるようにＧＵＩ／ＡＰＩアクセスを構成することが要求されるのがあるのが好ましい。別の実施形態では、注文入力もＦＩＸインターフェイスを経てサポートされ、ユーザは、ＧＵＩ２０又はＡＩＰアクセスを使用することが要求されない。
【０１６５】
又、システムコンフィギュレーションインターフェイスは、システムオペレータが、サポートされるブローカーのリストにスポンサーブローカーを追加できるようにするのが好ましい。別の実施形態では、システムは、単一のスポンサーブローカーにより操作され、第三者のブローカー関係を通してアクセスすることはできない。スポンサーブローカーを構成する際には、オペレータは、上述したように、クライアントアカウントのクレジットを管理するために、スポンサーブローカーのためのユーザアカウントを生成する。電話番号、ＦＡＸ及びｅメールのようなブローカーコンタクト情報を入力してシステムデータベース１５０に記憶しなければならず、ヘルプデスク要員は、このデータを利用して、クレジット発行のためにブローカーにコンタクトする。新たなスポンサーブローカーを設定するプロセスを完了するために、次のステップを実行するのが好ましい。
【０１６６】
−  ブローカーは、全ての実行のドロップコピーを受け取るためにＦＩＸ接続を設定しなければならない。ブローカーが、クライアントＯＭＳのためのサービス局としても使用されて、クライアントに代わって、チケットを送信する場合には、この同じ接続が、クライアントへのＦＩＸ接続としても使用される。
−  各取引の買い側顧客の身元を含む、各取引の詳細を備えたシステムからの１日の終りのファイル転送を設定する。
−  任意であるが、１日の終りに売り側取引詳細と共にブローカーの認可会社へ１日の終りのファイル転送を設定する。
【０１６７】
オペレータは、更に、取引に対してサポートされる有価証券のリストから有価証券を追加又は除去することもできる。これら有価証券は、本発明に特有のパラメータ値、例えば、「ブロック価格範囲」計算を含む実施形態では「ブロック価格範囲」を計算するために分析サーバー１６０により使用される「大ブロック量」及びパラメータ、に関連付けられるのが好ましい。有価証券に対する１組の必要なフィールドの一例を以下のテーブルに示す。
2007528559.tif 000014
【０１６８】
システムオペレーション：好ましい実施形態におけるシステムは、サーバー、ネットワークハードウェア及び取引の集中管理を行うために使用されるオペレーションコンソールを備えている。必要な機能をサポートするためのオペレーションソフトウェアは、少なくとも次の特徴を与えるバージョンで商業的に入手できる。
【０１６９】
−  全サーバー統計学的情報のリアルタイム表示
−  問題の概要
−  問題解決フィードバック
−  リモートマネージメント／モニタリング
−  インテリジェント通知システム（アラート）
−  アラート表示、確認及び注釈
−  可聴アラーム
−  ロギング
−  オンラインヘルプ
【０１７０】
オペレータコンソールは、システムオペレータが次のリモートアクションを実行するのを許す。
−  システムスタートアップ
−  システム再スタート
−  システムシャットダウン
−  システムコンポーネント再スタート
−  システムコンポーネントシャットダウン
−  システムコンポーネントスタートアップ
−  システムバックアップ
−  データベースバックアップ
−  １日の内のスタートアップ／シャットダウン
−  １日の終りのリセット
−  １日の終りのバッチ処理実行
【０１７１】
システムは、更に、オペレーションスタッフが、１日の終りに「毎日の使用レポート」を作成し、そしてそこから、ビリング、リサーチ、認可、及びＯＡＴＳ報告に必要な情報を抽出できるようにする。
【０１７２】
又、オペレーションスタッフは、システムオペレーションツールを使用して、取引の両側にブローカーＩＤを伴う取引のリストを含む認可概要を生成するのが好ましい。スポンサーブローカー及びその認可会社に関する取引概要は、少なくとも所与のブローカーが片側で後援するような全ての取引を含む。
【０１７３】
又、システムは、ブローカーに送信するためのスポンサーブローカーを伴う全ての充満のリストを含むビリングレポートも作成するのが好ましい。充満は、１日の内の実行レポートと１対１でマッチングしなければならない。１日の終りのレポートは、１日の内のレポートでマスクされたクライアントＩＤを更に含む。取引の両辺が同じブローカーにより後援される場合には、概要ファイルに２つの充満レポートがある。
【０１７４】
好ましい実施形態では、以下に述べるデータの２つのコピーをアーカイブ及び分析のために取り外し可能な媒体にセーブする。可能であれば、事象をログすることは、ミリ秒の精度の日付タイムスタンプを含む。
−  システム及びアプリケーションログ：各マシンにおけるアプリケーション及びシステムログがラベル表示され、セーブされる。ログは、１日の始まる前にリセットされるのが好ましい。
−  コンフィギュレーション監査：ファームウェアコンフィギュレーションの１日の始め及び１日の終りの監査の詳細が記録される（ＮＴレジストリー、アプリケーションＣｏｎｆｉｇ、等）。
−  ＡＣＴメッセージ：全てのＡＣＴメッセージに対する詳細を含む個別のログがなければならない。このログは、１日の始まる前にリセットされるのが好ましい。
−  注文及び取引：注文及び取引テーブルは、１日の終りに取り外し可能な記憶装置にコピーされる。注文状態の遷移の詳細についての個別のログが維持される。ログ及びテーブルは、１日の始まる前にリセットされるのが好ましい。
−  オペレーションアクティビティ：システムの振舞いに影響するオペレータのアクティビティがログされる。このログ動作は、タイムスタンプが印され、オペレータの身元を含む。このログは、１日の始まる前にリセットされるのが好ましい。
【０１７５】
全てのシステムアクティビティログ及び毎日のレポートは、各取引日の終りに永久的記憶装置へ移動されるのが好ましい。システムアクティビティログは、価格付け論争を解決するのに必要なタイムスタンプを含む各注文及び取引事象に対して取引ロジック及び価格付けを再構成するに充分な情報を含む。
【０１７６】
システムは、偶発的な故障の場合に、以下の事項に基づくプロセスを使用して、サービスを自動的に回復するように構成されるのが好ましい。
−  ＧＵＩが失われる。ＧＵＩ２０は、Ｃｌｏｕｄ９サービスに必要とされるチャンネルである。ネットサーバー１１０が、クライアントとの接続が失われたことを検出すると、好ましい実施形態では、全ての注文が自動的にキャンセルされ、そしてシステムは、注文がキャンセルされたトレーダーの電話番号でヘルプデスク要員へアラートを発生する。ＧＵＩ２０は、注文状態を「キャンセル保留」として示すのが好ましい。再接続されると、注文状態が「キャンセル」へと更新される。トレーダーは、接続故障の結果としてキャンセルされた注文のリストをプルアップして、これらの注文を再アクチベートし、システムは、それらを新たな注文として取り扱い、適宜に処理する。別の実施形態では、ユーザは、ＧＵＩとの接続が失われたときに注文がキャンセルされないようなコンフィギュレーションを選択することができ、この実施形態では、ユーザは、接続を回復できないときにヘルプデスクにコールして注文をキャンセルする。
【０１７７】
−  ＦＩＸが失われる。ＦＩＸ接続が失われても、注文のキャンセルが生じないのが好ましい。というのは、ＦＩＸは、実行可能な注文が管理されるチャンネルではないからである。オペレータは、ＦＩＸ接続が失われたときにアラートされねばならない。再接続時には、ＦＩＸクライアントは、ＦＩＸプロトコル要求に基づいてサーバーと再同期する。別の実施形態では、ＦＩＸを使用して、実行可能な注文をシステムに入力することができ、前記システムは、ＦＩＸ接続が失われたときに注文を自動的にキャンセルすることをユーザが要求できるようにするコンフィギュレーションをサポートする。
【０１７８】
−  分析サーバー：分析サーバー１６０が停止した場合に、好ましい実施形態のシステムは、機能し続けるが、「ＡＣＴＩＶＥ  ＳＹＭＢＯＬ」メッセージ（「ＡＣＴＩＶＥ  ＳＹＭＢＯＬ」通知を伴う実施形態の場合）、又は「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」メッセージのようなファシリテータにより通常実施される機能の利益を伴わない。又、ＧＵＩ２０は、相場更新及びＢＰＲ更新メッセージを受け取らない。分析サーバー１６０がオンラインに速やかに戻れない場合には、システムオペレータは、システムをオフライン状態に入れる命令をもち、ここでは、更なる注文入力を拒絶するが、既存の注文をキャンセルすることはない。これらの解決策は、本発明のような取引システムが信頼性の問題にいかに対処するかの一例として説明するが、当業者であれば、他の解決策も容易に明らかであろう。例えば、別の解決策は、分析サーバー１６０を重要なサービスとみなし、サービスが失われたときに、自動的にシステムをオフラインにして、全ての注文をキャンセルする。
【０１７９】
−  ネットサーバー、注文マネージャー及びファシリテータ：これらのサービスは、取引システムの重要な機能に厳密に関係している。それ故、これらのサービスの失敗は、好ましい実施形態において致命的と考えられ、オペレータが実行エンジンにおいて全ての注文をキャンセルするよう試みるか、或いは接続が失われたことが検出されたときにそれらが自動的にキャンセルされる。システムは、これらサービスの失敗を検出すると、自動的にオフライン状態になる。
【０１８０】
システムの完全性は、独立したシステムにおいて連続的に実行されるシステムマネージメントコンソールにより常時監視される。取引日の間に、システムの完全性が不確実になった場合には、システムは、自動的にオフラインモードにスイッチする。この時点で、全ての注文がキャンセルされる。システムが完全な動作状態に復帰するまで、それ以上の注文は全て断られる。
【０１８１】
システム発生コールを伴う別の実施形態
大ブロック交差システムに伴う良く知られた問題は、大きな買い手と大きな売手が同時に注文を入力する確率が低いことである。本発明の多くは、第１のトレーダーが注文を入力した後にこの問題を解決することに向けられるが、この第１の参加者がいつ注文を出すよう最も促すべきかについて、それ自身手引きを与えるものではない。
関心を時間に集中させられることは、ここに述べるメカニズムを通して考えられる最良の価格改善を得るという要望に対して特に重要である。
【０１８２】
別の実施形態では、システムは、上述したように動作するが、トレーダーの関心を有価証券の売り買いの両方の関心の指示があるときに集中させるシステム発生「コール」事象を更に発生する。別の実施形態では、アクティブフラグが送信されず、コールが唯一の時間集中事象となる。コールは、充満の見込みが最も高いときを決定するアルゴリズムを経てスケジュールされるのが好ましい。トレーダーがシステムに出した注文がそれらの直接的なコントロールを越える望ましからぬ情報事象を引き起こすことをトレーダーが感じるような情報漏れの認識を回避するために、アンバランスな取引情報（売手がいないときに買い関心の存在を露呈するような）利用しないのが好ましい。
【０１８３】
コールの目的は、充満の見込みが最も高いときにトレーダーから注文の入力を引き出すことである。例えば、所与の有価証券の注文を出す第１トレーダーについての平均充満率が５％である場合には、有価証券においてコールがオープンであるときの充満率が１０％又は１５％となり、これに対して、コールがないときの充満率は、５％より低く、コールとは独立してランダムな時間に注文を出すトレーダーの全体的平均は５％である。
【０１８４】
最小限、このような別の実施形態では、トレーダーが両側に注文を出したが、それらの注文が異なる時間に出されたために互いにミスしたときに、有価証券の注文入力を集中させるためにコールを発する。システムがコールを発生できるケースの一例を以下に述べる。システムに出された注文に関する情報の漏れを回避するために、これらのコールは、注文入力事象の発生時ではなく、ＢＰＲを伴う実施形態では６０秒ＢＰＲ更新のような予めスケジュールされた時間に報告される。
2007528559.tif 000015
【０１８５】
コールを発生するためのアルゴリズムは、次の原理に基づくのが好ましい。
−  注文入力時にトリガーされない：コールを発行する機会は、予めスケジュールされた時間に評価される。これは、トレーダーが、自分自身の注文がコールの発行を引き起こすことが分かった場合に生じる情報漏れのおそれを排除する。又、これは、このようなトレーダーがブックに関する情報を発見するのを防止する。例えば、システムルールが、買い側及び売り側で注文が受け取られたときにコールを発することであると仮定する。買手は、注文入力時にコールをトリガーすべきである場合に、最近システムに売手がいたことを発見する。予めスケジュールされた時間にコールを発することにより、コールは、もはやトレーダーの注文に直接関係したものとならず、その解釈が、必ずしも、ブックにおける他の注文の側に関する情報を漏らすことにならない。
【０１８６】
−  １分の最小ライフスパン：コールが開始されると、トレーダーがコールに反応し且つ応答するに充分な時間オープンに留まる。
−  両側付き：両側に関心のあるブロックの形跡がある場合だけコールが発せられる。これは、潜在的ゲーム感覚を減少する。
【０１８７】
−  必ずしも注文でない：システムにアクティブな注文がないときにコールが発生されることがあり、従って、トレーダーは、システムがコールを発するときを監視することでシステムにおける注文の存在を推測できない。
−  開示されないルール：システムがコールを発するようにさせるルールは、寄生的トレーダーがコールのタイミングからシステムのブックに関する情報の推測を試みるリスクを減少するために、周期的に変更され且つ参加者に開示されないのが好ましい。又、周期的な更新は、コールの適度な頻度を維持するようにルールを調整する融通性をシステムオペレータに与える。
【０１８８】
次のデータは、コールを発生すべきときを判断する目的で入手できるのが好ましい。
−  残りの量を伴うチケット
−  オープン注文
−  時間切れした注文
−  取引
−  テープにおけるブロックプリント
−  異常に高いボリュームを伴うテープにおける繰り返しプリント
【０１８９】
コールを発するためのルールに基づく方法
第１の別の実施形態は、コールを発するべきときを判断するためのルールに基づく解決策を利用する。アクティブな評価プロセスは、各シンボルに対してＢＰＲ更新プロセスと一緒に実行される。
【０１９０】
まだコールがない場合に、以下のルールは、システムのアクティビティ（注文、取引、等）及び市場に基づいてシンボルをコールすべきかどうか判断するのに適用されるのが好ましい。いずれかのブールのルールが真である場合には、シンボルがコールされる。
【０１９１】
シンボルが既にコールされ、少なくとも＜６０＞秒（構成可能なグローバルパラメータ）の間コールされ、且つ有価証券に逆の存在フラグがない場合には、システムは、コールを除去するのが好ましい。
【０１９２】
コールを導くルールを以下に列挙する。
−  注文が入力されて、時間切れとなる。その後、別の注文が逆側に入力される。次の規則的にスケジュールされた時間に、コールがこのシンボルにおいて最後の３０分間（構成可能なＡｃｔｉｖｅＭａｘＤｅｌａｙ１）掲示されたかどうかチェックし、もしそうでなければ、コールをこのシンボルに掲示する。
−  注文が入力されて、時間切れとなる。その後、ブロックプリントがテープにおいて検出され（１００００株又は＄２５０，０００より大きい、この場合も、これらは、全て、構成可能なパラメータ）、そしてコールは、このシンボルにおいて最後の９０分間（構成可能なＡｃｔｉｖｅＭａｘＤｅｌａｙ２）掲示されない。
−  自由裁量：ヘルプデスクオペレータは、シンボルをタイプ入力し、ボタンをクリックする。
−  注文が入力され、逆側にチケットが存在する。
−  最後の＜３０＞分以内に取引されたシンボルに注文が入力される。
−  常駐注文が消極的に価格付けされ、新たな注文が積極的な価格で逆側に到着する。
−  常駐売り注文が積極的であり、ブロックサイズに対する売り値での積極的な買いを示す繰り返しプリントがテープにおいて検出されるか、或いはシステムにおける買い注文及び市場におけるブロック売りの形跡に対して逆のことが行われる。
【０１９３】
前記リストは、例示に過ぎず、余すところのないものではない。当業者であれば、より高い取引の見込みがあるときを識別するのに使用できる他のルールが容易に明らかであろう。
【０１９４】
コールを発するためのスコア機能方法
コールを伴う別の方法は、スコア機能を使用して、コールを発生すべきときを次のように決定する。
【０１９５】
コール評価プロセスは、シンボルごとに、ＢＰＲ更新プロセスと一緒に実行される。このシンボルに現在コールがない場合には、システムは、以下に述べるように、シンボルのアクティビティスコアと、スレッシュホールドとの両方を計算する。スコアがスレッシュホールドを越える場合には、システムがこのシンボルに対してコールを発生するのが好ましい。
【０１９６】
シンボルが既にコールされ、少なくとも＜６０＞秒間（構成可能なグローバルパラメータ）コールされ、且つ有価証券に逆の存在フラグがない場合には、システムは、コールを除去するのが好ましい。
【０１９７】
システムは、２つのステップを経てスコア機能を計算するのが好ましい。
ステップ１：次の条件に関連した重みを加算することにより有価証券の買い側の利益と売り側の利益とを計算する。
−  ＯｐｅｎＯｄｅｒＣｏｎｄｉｔｉｏｎ：現在オープンで且つ積極的に価格付けされた買い（売り）注文。
−  ＰａｓｓｉｖｅＯｄｅｒＣｏｎｄｉｔｉｏｎ：現在オープンであるが消極的に価格付けされた買い（売り）注文。
【０１９８】
−  ＥｘｐｉｒｅｄＯｒｄｅｒＣｏｎｄｉｔｉｏｎ：最近時間切れした買い（売り）注文。
−  ＴｉｃｋｅｔＣｏｎｄｉｔｉｏｎ：残りの量を伴う買い（売り）チケット。
−  ＢｌｏｃｋＴａｐｅＣｏｎｄｉｔｉｏｎ：Ｃｌｏｕｄ９における最近の大ブロック充満。
−  ＭａｒｋｅｔＰｒｉｎｔＣｏｎｄｉｔｉｏｎ：中間点より上（下）にプリントされた少なくとも＜ＢｌｏｃｋＱｔｙ＝１００００＞株又は＜ＢｌｏｃｋＶａｌｕｅ＝＄２５０，０００＞に対するテープ上のブロックプリントで、最後にスケジュールされたコール評価時間以来行われたもの。
【０１９９】
−  ＲａｎｄｏｍＲｅｆｒｅｓｈＣｏｎｄｉｔｉｏｎ：最後のコール評価時間以来の中間点より上（下）の繰り返しプリントで、合計量が＜ＢｌｏｃｋＱｔｙ＝１００００＞株又は＜ＢｌｏｃｋＶａｌｕｅ＝＄２５０，０００＞より上で、率が有価証券に対する平均ボリュームの＜ＬｉｑｕｉｄｉｔｙＲａｔｉｏ＝２＞倍を越えるもの。
−  ＷａｔｃｈＬｉｓｔＣｏｕｎｔ：ウオッチリストにこのシンボルを有する取引の数。
【０２００】
以下のテーブルは、重みに対する適度なコンフィギュレーションの一例を以下に示す。
2007528559.tif 000016
【０２０１】
ステップ２：買い側の利益と売り側の利益との積としてシンボルアクティビティスコアを計算する。
システムは、スレッシュホールドを次のように計算するのが好ましい。スレッシュホールドは、シンボルがコールされなかった場合にはゼロに等しい。シンボルが以前にコールされた場合には、このシンボルに対するスレッシュホールドは、このシンボルにおいて最後のコールが時間切れして以来の時間の指数関数に等しくなる。
スレッシュホールド＝ＭａｘＴｈｒｅｓｈｏｌｄ＊ＥＸＰ（−β＊ＴｉｍｅＤｅｌａｙ）
パラメータＭａｘＴｈｒｅｓｈｏｌｄ及びβは、有価証券ごとに構成可能であるのが好ましい。
【０２０２】
システムコールを伴う実施形態では、システムは、上述した実施形態のように、注文を連続的にマッチングさせることもできるし、或いはスケジュールされたコール周期が経過するまでマッチングを行わずに注文を蓄積し、そしてその時点で、上述したように、側、価格及び時間の順に、実行エンジンへそれらを解除することもできる。後者の方法は、本システムで行われる通常の取引と隣接して動作し得るコールオークション環境を形成し、ここでは、システムは、このようなステップを正当化するためのアクティビティを見つけたときに自動的にコールを発生し、次いで、そのコール周期中に全ての注文を保持して、積極的な参加者のための価格改善の最良の機会を得るに充分な注文を蓄積する。この実施形態では、例えば、連続的なマッチングが、低い最小量要求（例えば、１００株）で作用し、そして両側にブロック利益の指示を見つけたときに大ブロックオークション（例えば１００，０００株）に対するコールを自動的にトリガーする。遅延コールを実行するときに、システムは、次のように、コールオークションごとに単一認可価格にそれ自身を制限するのが好ましく、即ち上述したように注文をランク付けし、それらを実行エンジン５０へ１つづつ入れ始め、第１の取引が実行されるときに、その後の全ての注文を必要に応じて再価格付けして、それらの限界が、このコールの発生時に、第１に取引された価格より積極的にならないように確保する。マッチングしない注文は、全ての注文が入力されそして全ての考えられるマッチングが実行された後に、時間切れとなるのが好ましい。
【０２０３】
ターゲットに向けたＡＣＴＩＶＥ  ＳＹＭＢＯＬメッセージを伴う別の実施形態
別の実施形態では、システムは、「ＡＣＴＩＶＥ  ＳＹＭＢＯＬ」通知を伴う別の実施形態について上述したように動作するが、アクティブシンボルメッセージは、この有価証券の大きなブロックを売り買いすることにおそらく関心があることを指示する承認された取引関心情報を与えたトレーダーのみに送信される。例えば、このような承認された取引関心情報は、各取引の後にブローカーが発行する実行レポートのドロップコピーでよく、又、選択基準は、会社が最後の３０分以内に正味（販売正味）少なくとも１０，０００株を買うことでよい。他の例が、参考として全ての内容を各々ここに援用する次の出願中の米国特許出願に広範囲に説明されている。２０００年６月１日に出願された第０９／５８５，０４９号；２０００年１２月２９日に出願された第０９／７５０，７６８号；及び２００１年５月３１日に出願された第０９／８７０，８４５号。
【０２０４】
ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ通知の別の実施形態
別の実施形態では、「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知は、カウンターオファーの価格も表示し、従って、この通知を受け取る当事者は、価格を提案しなければならなのではなく、前記カウンターオファーを直接受け容れるべきかどうか判断することができる。
【０２０５】
このシステムの別の実施形態では、誰が「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知を受け取るのに適任で、特に関心があるかを、相場ルール及び注文表示ルールに鑑みて決定するための異なるルールを使用する。相場ルールは、市場参加者に相場を示し、それらの相場で最良に価格付けされた注文を表わすことを要求し、一方、注文表示ルールは、２人以上の当事者に価格が示される場合に、それが、当然、全市場に示され且つ得られるようにしなければならないことを要求する。両方のルールは、「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知を相場としてみることを決定した場合に、本発明のシステム主題の開発に対して潜在的なハードルを生成する。別の実施形態は、「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知を一方の当事者のみに示し、この目的で、最高のマッチングプライオリティを伴う注文を選択することにより、この状態に対処する。逆の解決策は、ユーザがシステムに注文を有するかどうかに関わらず、全てのユーザに「ＣＯＮＴＲＡ  ＰＲＥＳＥＮＴ」通知を示すという実施形態で構成される。当然、逆側の利益を推定できるのは、システムに注文をもつユーザだけであり、例えば、システムに買い注文をもつユーザは、システム内に少なくとも１人の売手とおそらく他の多数の買手とがいることを知る。システムに注文をもたないユーザは、少なくとも１人の買手と、少なくとも１人の売手がいることは分かるが、どちらの側が他の側より積極的であるかは分からない。このような２つの側の情報は、当業者の取引の利益にダメージを及ぼさないので、この情報を全市場に発表するのは、受け容れられる情報リークである。
【０２０６】
図示して説明した実施形態は、本発明の目的を完全に達成することができるが、以上の説明に鑑み、多数の変更や、修正や、置き換えが当業者に明らかであろう。これらの変更や、修正や、置き換えは、本発明の範囲内にあり、上述した実施形態は、単に例示のためのものであって、本発明をそれに限定するものではないことを理解されたい。
【図面の簡単な説明】
【０２０７】
【図１】本発明の好ましいコンピュータシステム実施形態の概略図である。
【図２】注文入力ダイアログがオープンである好ましいＧＵＩを示す図である。
【図３（ａ）】好ましいシステムのオペレーション、並びにこのシステムと参加者及び関連会社の電子システムとの相互作用を含む方法とを示す図である。
【図３（ｂ）】好ましいシステムのオペレーション、並びにこのシステムと参加者及び関連会社の電子システムとの相互作用を含む方法とを示す図である。
【図４】好ましい実施形態において認可の観点からの取引のライフサイクルを示す図である。
【図５】「新たなチケット」を処理する間に好ましく実行されるステップを示す図である。
【図６】「キャンセルチケット」メッセージを処理するための好ましいステップを示す図である。
【図７】有効な注文を処理するための好ましいステップを示す図である。
【図８】好ましいウオッチリスト構成ダイアログを示す図である。
【図９】ＢＰＲを計算するための好ましい方法のステップを示す図である。
【図１０】ウオッチされた有価証券が識別される好ましいＧＵＩを示す図である。
【図１】
2007528559.tif 000017
【図２】
2007528559.tif 000018
【図３（ａ）】
2007528559.tif 000019
【図３（ｂ）】
2007528559.tif 000020
【図４】
2007528559.tif 000021
【図５】
2007528559.tif 000022
【図６】
2007528559.tif 000023
【図７】
2007528559.tif 000024
【図８】
2007528559.tif 000025
【図９】
2007528559.tif 000026
【図１０】
2007528559.tif 000027