(57)【要約】  証券などの取引を行う取引システムにおいて、自己の注文品管理装置の情報を中央取引サーバーに露呈することなく、注文品管理装置内の流動資産を公開することを、ユーザーに可能とすることで、コントラ・ターゲティングが行われる。加えて、ユーザーに対して、約定の瞬間まで、株を予約することなく、注文に対する価格−時間的プライオリティを与えることが可能なバーチャル注文を発注したり、それを約定したりすることが可能である。【選択図】  図６Ａ
2010534892.tif 000002
【特許請求の範囲】
【請求項１】
複数のトレーダー間の商品取引を容易にする方法であって、
（ａ）前記複数のトレーダーに対応する複数のワークステーションであって、各々が、注文品管理装置を作動する又は注文品管理装置に接続されているワークステーション間の電子通信を提供し、
（ｂ）  どのトレーダーが自己の注文品管理装置に対するサーチの実施に合意しているかを示す情報を取引サーバーに記憶し、
（ｃ）前記商品の一つに対する注文であって、前記複数のトレーダーのうち、発端となるトレーダーが取引を望む他のトレーダーを特定することを含む注文を、前記複数のワークステーションのうち、発端となるワークステーションから、前記取引サーバーへ受け取り、
（ｄ）前記複数のトレーダーのうち、前記注文で特定されており、自己の注文品管理装置に対するサーチの実施に合意しているトレーダーのワークステーションに前記注文を送り、
（ｅ）前記ステップ（ｄ）において前記注文が送られたワークステーション各々で、前記注文に対する逆注文があるか判定するため、主体システムに公開された注文品管理装置から取引可能の注文群を検索し、又は主体システムに公開された注文品管理装置から注文群に関する情報を検索し、
（ｆ）前記ステップ（ｅ）で前記注文に対する逆注文があると判定されたワークステーションの最低一つに、前記注文に関する表示を提供すること、
を特徴とする方法。
【請求項２】
前記注文は広告依頼メッセージを含むことを特徴とする請求項１記載の方法。
【請求項３】
前記複数のトレーダーは複数の項目にグループ化され、前記注文は、前記複数のトレーダーのうち、どの項目のトレーダーが前記注文を受け取るかの指示を含む請求項１記載の方法。
【請求項４】
前記表示は、該当するトレーダーに、前記注文を約定するオプションを与え、前記方法は、（ｇ）前記ステップ（ｆ）において前記注文を約定するオプションを与えられたトレーダーの一人が、前記注文を約定する選択をした場合に、前記注文を約定することを更に含むことを特徴とする請求項１記載の方法。
【請求項５】
前記ステップ（ｆ）で与えられた前記オプションは、シングルクリックで前記注文を自動約定するオプションを含むことを特徴とする請求項４記載の方法。
【請求項６】
前記注文は、暗号化されたメッセージとして送られることを特徴とする請求項１記載の方法。
【請求項７】
前記ステップ（ｅ）において前記注文に対する逆注文がないと判定されたワークステーション各々において、前記注文が削除されることを特徴とする請求項１記載の方法。
【請求項８】
前記ステップ（ｆ）は、期間タイマーの設定を行い、該期間タイマーの期限が切れるまで、前記表示を提供し、該期間タイマーの期限が切れると、前記表示を解除することを含むことを特徴とする請求項１記載の方法。
【請求項９】
前記期間タイマーの期限が切れると、第一システムに広告結果メッセージが送られることを特徴とする請求項８記載の方法。
【請求項１０】
前記広告結果メッセージは、広告依頼メッセージＩＤを含むことを特徴とする請求項９記載の方法。
【請求項１１】
前記広告結果メッセージは、広告依頼メッセージ適性スコアを含むことを特徴とする請求項９記載の方法。
【請求項１２】
前記広告結果メッセージは、前記第一システムからの内密の取引利益情報の表示属性の表示に応えて入力された一群の応答を含むことを特徴とする請求項９記載の方法。
【請求項１３】
前記第一システムは、前記広告結果メッセージを受け取ると、該広告結果メッセージに含まれている情報を記録し、該情報を含んだ電子メールを調査部に対し作成することを特徴とする請求項９記載の方法。
【請求項１４】
前記電子メールは、ユーザーのビヘイビアを監視するのに利用されることを特徴とする請求項１３記載の方法。
【請求項１５】
前記ユーザービヘイビアの監視は、市場参加者の、前記第一システムからの内密の取引利益情報の表示属性の表示を見つつも応答しない頻度をモニタリングすることを含むことを特徴とする請求項１４記載の方法。
【請求項１６】
前記ユーザービヘイビアの監視は、前記広告通知メッセージからの情報を記憶し、逆注文情報の受取りと値動きとを関連づけることを特徴とする請求項１５記載の方法。
【請求項１７】
前記ステップ（ｆ）は、前記注文が表示に適しているかどうかを判定するため、前記注文をランキングサービスに転送することを更に含むことを特徴とする請求項１記載の方法。
【請求項１８】
複数のトレーダー間で商品を取引する方法であって、
（ａ）前記複数のトレーダーの一人から、少なくとも一つの商品のバーチャル注文であって、少なくとも一つの商品のプライオリティを提供するが、該商品の予約を行わない注文を、電子商取引システムに受け取り、
（ｂ）逆注文を、前記複数のトレーダーの別の一人から電子商取引システムに受け取り、
（ｃ）前記バーチャル注文が、前記逆注文で少なくとも部分的に成立可能かどうか判定し、
（ｄ）前記ステップ（ｃ）で、前記バーチャル注文が、前記逆注文で少なくとも部分的に成立可能であると判定すると、前記バーチャル注文を、前記逆注文で可能なだけ成立させること、
を特徴とする方法。
【請求項１９】
前記複数のトレーダーは、バーチャル注文を出す又は予約するオプションが与えられることを特徴とする請求項１８記載の方法。
【請求項２０】
前記ステップ（ｄ）の後、成立しなかった分のバーチャル注文をキャンセルすることを特徴とする請求項１８の方法。
【請求項２１】
複数のトレーダー間の商品取引を容易にするシステムであって、
互いに電子通信を行う、前記複数のトレーダーに対応する複数のワークステーションであって、各々が、注文品管理装置を作動する又は注文品管理装置に接続されているワークステーションと、
どのトレーダーが自己の注文品管理装置に対するサーチの実施に合意しているかを示す情報を記憶する取引サーバーであって、
前記商品の一つに対する注文であって、前記複数のトレーダーのうち、発端となるトレーダーが取引を望む他のトレーダーを特定することを含む注文を、前記複数のワークステーションのうち、発端となるワークステーションから受け取り、
前記複数のトレーダーのうち、前記注文で特定されており、自己の注文品管理装置に対するサーチの実施に合意しているトレーダーのワークステーションに前記注文を送り、
前記注文が送られたワークステーション各々で、前記注文に対する逆注文があるか判定するため、主体システムに公開された注文品管理装置から取引可能の注文群を検索し、
前記注文に対する逆注文があると判定されたワークステーションの最低一つに、前記注文に関する表示を提供する取引サーバーと、
を備えることを特徴とするシステム。
【請求項２２】
前記注文は広告依頼メッセージを含むことを特徴とする請求項２１記載のシステム。
【請求項２３】
前記複数のトレーダーは複数の項目にグループ化され、前記注文は、前記複数のトレーダーのうち、どの項目のトレーダーが前記注文を受け取るかの指示を含む請求項２１記載のシステム。
【請求項２４】
前記表示は、該当するトレーダーに、前記注文を約定するオプションを与え、前記注文を約定するオプションを与えられたトレーダーの一人が、前記注文を約定する選択をした場合に、前記注文を約定することを特徴とする請求項２１記載のシステム。
【請求項２５】
前記与えられたオプションは、シングルクリックで前記注文を自動約定するオプションを含むことを特徴とする請求項２４記載のシステム。
【請求項２６】
前記注文は、暗号化されたメッセージとして送られることを特徴とする請求項２１記載のシステム。
【請求項２７】
前記注文に対する逆注文がないと判定されたワークステーション各々において、前記注文が削除されることを特徴とする請求項２１記載のシステム。
【請求項２８】
前記表示を提供するワークステーション各々が、期間タイマーの設定を行い、該期間タイマーの期限が切れるまで、前記表示を提供し、該期間タイマーの期限が切れると、前記表示を解除することを特徴とする請求項２１記載のシステム。
【請求項２９】
前記期間タイマーの期限が切れると、第一システムに広告結果メッセージが送られることを特徴とする請求項２８記載のシステム。
【請求項３０】
前記広告結果メッセージは、広告依頼メッセージＩＤを含むことを特徴とする請求項２９記載のシステム。
【請求項３１】
前記広告結果メッセージは、広告依頼メッセージ適性スコアを含むことを特徴とする請求項２９記載のシステム。
【請求項３２】
前記広告結果メッセージは、前記第一システムからの内密の取引利益情報の表示属性の表示に応えて入力された一群の応答を含むことを特徴とする請求項２９記載のシステム。
【請求項３３】
前記第一システムは、前記広告結果メッセージを受け取ると、該広告結果メッセージに含まれている情報を記録し、該情報を含んだ電子メールを調査部に対し作成することを特徴とする請求項２９記載のシステム。
【請求項３４】
前記電子メールは、ユーザーのビヘイビアを監視するのに利用されることを特徴とする請求項３３記載のシステム。
【請求項３５】
前記ユーザービヘイビアの監視は、市場参加者の、前記第一システムからの内密の取引利益情報の表示属性の表示を見つつも応答しない頻度をモニタリングすることを含むことを特徴とする請求項３４記載のシステム。
【請求項３６】
前記ユーザービヘイビアの監視は、前記広告通知メッセージからの情報を記憶し、逆注文情報の受取りと値動きとを関連づけることを特徴とする請求項３５記載のシステム。
【請求項３７】
前記最低一つのワークステーションは、前記注文が表示に適しているかどうかを判定するため、前記注文をランキングサービスに転送することを特徴とする請求項２１記載のシステム。
【請求項３８】
複数のトレーダー間で商品を取引するためのシステムであって、
複数のトレーダーと電子的に情報をやりとりする通信コンポーネントと、
（ａ）前記複数のトレーダーの一人から、少なくとも一つの商品のバーチャル注文であって、少なくとも一つの商品のプライオリティを提供するが、該商品の予約を行わない注文を受け取り、
（ｂ）前記複数のトレーダーの別の一人から逆注文を受け取り、
（ｃ）前記バーチャル注文が、前記逆注文で少なくとも部分的に成立可能かどうか判定し、
（ｄ）前記ステップ（ｃ）で、前記バーチャル注文が、前記逆注文で少なくとも部分的に成立可能であると判定すると、前記バーチャル注文を、前記逆注文で可能なだけ成立させる取引サーバーと、
を備えることを特徴とするシステム。
【請求項３９】
前記複数のトレーダーは、バーチャル注文を出す又は予約するオプションが与えられることを特徴とする請求項３８記載のシステム。
【請求項４０】
前記取引サーバーは、前記ステップ（ｄ）の後、成立しなかった分のバーチャル注文をキャンセルすることを特徴とする請求項１８のシステム。
【請求項４１】
複数のトレーダー間の商品取引を容易にする製品であって、
コンピュータ可読記憶媒体と、
コンピュータ可読記憶媒体に記録されたコードとを備え、
前記コードは、一以上の計算装置で実行されると、該一以上の計算装置が、
（ａ）前記複数のトレーダーに対応する複数のワークステーションであって、各々が、注文品管理装置を作動する又は注文品管理装置に接続されているワークステーション間の電子通信を提供し、
（ｂ）  どのトレーダーが自己の注文品管理装置に対するサーチの実施に合意しているかを示す情報を取引サーバーに記憶し、
（ｃ）前記商品の一つに対する注文であって、前記複数のトレーダーのうち、発端となるトレーダーが取引きを望む他のトレーダーを特定することを含む注文を、前記複数のワークステーションのうち、発端となるワークステーションから、前記取引サーバーへ受け取り、
（ｄ）前記複数のトレーダーのうち、前記注文で特定されており、自己の注文品管理装置に対するサーチの実施に合意しているトレーダーのワークステーションに前記注文を送り、
（ｅ）前記ステップ（ｄ）において前記注文が送られたワークステーション各々で、前記注文に対する逆注文があるか判定するため、主体システムに公開された注文品管理装置から取引可能の注文群を検索し、
（ｆ）前記ステップ（ｅ）で前記注文に対する逆注文があると判定されたワークステーションの最低一つに、前記注文に関する表示を提供するように、
該装置を制御することを特徴とする製品。
【請求項４２】
複数のトレーダー間で商品を取引するための製品であって、
コンピュータ可読記憶媒体と、
コンピュータ可読記憶媒体に記録されたコードとを備え、
前記コードは、一以上の計算装置で実行されると、該一以上の計算装置が、
（ａ）前記複数のトレーダーの一人から、少なくとも一つの商品のバーチャル注文であって、少なくとも一つの商品のプライオリティを提供するが、該商品の予約を行わない注文を受け取り、
（ｂ）前記複数のトレーダーの別の一人から逆注文を受け取り、
（ｃ）前記バーチャル注文が、前記逆注文で少なくとも部分的に成立可能かどうか判定し、
（ｄ）前記ステップ（ｃ）で、前記バーチャル注文が、前記逆注文で少なくとも部分的に成立可能であると判定すると、前記バーチャル注文を、前記逆注文で可能なだけ成立させるように、
該装置を制御することを特徴とする製品。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、２００７年７月２６日出願の米国仮出願第６０／９６２、３０７号、２００７年１０月１９日出願の米国仮出願第６０／９８１、２４２号、２００８年２月２９日出願の米国仮出願第６１／０３２、６２３号、そして２００８年４月８日出願の米国仮出願第６１／０４３、１７２号に対する優先権を主張するものである。なお、本発明の要旨に関連する内容が、現在係属中である２００２年１２月５日出願の米国特許出願第１０／３１０、３４５号、２００３年６月２４日出願の第１０／６０３、１００号、２００４年３月１１日出願の第１０／７９９、２０５号、２００７年４月６日出願の第１１／７８３、２５０号から第１１／７８３、２５４号、及び２００８年５月１６日出願の第１２／１５３、３６２号に開示されており、これらの出願は全て、参照により全体として本開示に組み込まれる。
【０００２】
本願発明は、金融取引における注文管理に係り、具体的には、ユーザーが、注文管理装置（ＯＭＳ：Ｏｒｄｅｒ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ）にある流動資産を、内密の取引情報を漏洩させることなく、他のトレーダーに公開出来るようにする注文管理に関する。
【背景技術】
【０００３】
公募証券市場では、市場機構や取引心理によって、有効な情報の流布及び価格の発見に対し障壁が築かれる。市場参加者が、正確な指し値の情報公開を決定した場合、それは、価格期待に影響を与えた場合のマーケットインパクトコストと、売買を遅らせた又は約定しなかった場合の機会コストとのトレードオフを意味する。なお、ここで「市場参加者」という用語は、証券又は他の金融商品をトレード可能な全ての者又は企業を指し、市場参加者の例としては、ブローカーディーラー、機関投資家、投資信託会社、統計的裁定取引及び他の自己勘定売買などを業務とする者、そして電子通信ネットワーク（ＥＣＮｓ：ｅｌｅｃｔｒｏｎｉｃ  ｃｏｍｍｕｎｉｃａｔｉｏｎ  ｎｅｔｗｏｒｋｓ）により取り引きを行う個人投資家などが挙げられる。
【０００４】
例えば、一人でも複数でも、見込まれる売り手に、正確な買いの指し値を提示することで、市場参加者は、どの売り手でも自由に選んで約定してくれて構わない、というオプションを実質的に書き込んでいる。このオプションが開かれている限り、公正取引価格がいくらであるべきかという市場参加者の予想に下限ができる。売り手の一人が、これより低い値を初めに予想していたとしても、表示された買い手の指し値を知ると、この予想をすぐに変え、公正価格がさらに高くあるべきかどうかという問題だけが残る。買い手は、高値を提示することで、この株を得る意欲を示すのだが、これは、まだ売り手が気付いていない情報を示してしまうこともある。
【０００５】
ブローカーディーラーは、両者のトレード期待値を慎重に管理し、公正価格が分かってから、両者にとって満足のいく公正取引価格を提示することで、この問題に対処している。最近では、こういった委託注文が、ますます電子的に行われるようになっている。価格期待に対する上記インパクトを避けるため、「成り行き」とされた注文は大衆相場に示されることはない。ブローカーは、セルサイドとバイサイドの交差する成行注文を受けることもあり、反対売買を約定するために、両注文の間で公正価格を選択しなければならなくなる。通常、このような状況への対処は、ブローカーの自由裁量に任せられる。例えば、買い手が午前１０：００に３０．００ドルでの大口買い注文を出し、その後、市場が現在の最高付け値２９．８０ドルまで落ちている場合、２９．９９ドルでの大口売り注文が、この値で自動的に付け合せられることは、現在の市場に比べ高いと思われることから、恐らくないだろう。もっとも、買い手のこの指し値は、もし市場価格がこのレベルを上回った場合には買うことをやめる指示として解釈される。これも買い手のはるかに高い指し値と交差するものであるが、２９．８２ドルでの大口売り注文は、恐らく受け入れられるであろう。２９．８５ドルでのものでは、ブローカーが売り手に電話することになると思われる。
【０００６】
この他者の仲介というものは、支払われるコミッションや、投資信託会社等のアグレッシブな商社と親密な関係を持つ者への情報漏洩という観点からすれば、途方もなく高くつき、結果として、従来のブローカーによる自由裁量の介入なく自分の注文を自分で発することが出来る代わりの市場を手に入れたい、という大手機関投資家の要求が加速した。
【０００７】
ナスダック又はエレクトリックコミュニケーションネットワーク（ＥＣＮ：Ｅｌｅｃｔｒｏｎｉｃ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ  Ｎｅｔｗｏｒｋ）などの電子的市場には、大量株取引の価格の発見についての問題に対処する十分な能力がない。電子市場は、最もシンプルな形では、単に買い手及び売り手の取引利益を加入者に示すだけであり、それにより加入者は、そのような売買の利益を約定出来るようになる。電子的市場のユーザーは、市場参加者の価格期待へのインパクトを避けるため、通常、消極的な値で比較的小口の注文を出し、ひたすら他の者がそれらを約定するのを待つか、多少積極的な姿勢を取り、他の者がスプレッドの向こうに発した注文を約定する。
【０００８】
大口注文を、このようなやり方で扱える多数の小注文に「スライスし、さいの目に切る」ツールも使用可能であるが、それを機能させると、大量注文の存在が、必然的に統計的分析分野の技術に精通した者に知られてしまう。こういったトレーダーは、内密の大口注文の取引を、意図的に探知する取引戦略を生み出し、それを能率的に利用することで、大口注文により多々もたらされるマーケットインパクトを予想し利益を生み出す。このような戦略で、最もシンプルなものは、大口注文前にポジションを持ち、その継続により有益な方向に値が押し進められるのを当てにするというものである。大口注文と同じ向きに取り引きすることで、このような寄生戦略は、大口注文により本来起きていたであろう元々の値動きを激化させることになる。最終的な結果というものは、ニューヨーク証券取引所に大口注文を発するときのそれと似ているところもあり、後者の場合、フロア・トレーダーが、競り売りされた注文に「関与する」ために加わる、又は得ることが出来た流動資産を横取りしようと直接割り込んでくる。ニューヨーク証券取引立会場や電子市場などでは、この手の寄生戦略を述べるのに、「ペニージャンピング」及び「フロントランニング」という用語が用いられるようになった。
【０００９】
いくつかの電子証券取引ネットワークは、フロントランニングの問題を多少とも解決しようと、より高度化した注文タイプを提供する。これらのいくつか（例えば自由裁量注文）は、単に、一価格を示しつつも、内密の更に高い指し値までは、約定する優先権を得ようとするもので、これにより正確な指し値を隠そうとするものである。しかしながら、これらは、異なる価格水準で小口注文をかけ、示されていない価格水準でいつ注文が約定されるかを見るというような、簡単な反対戦略に苦しめられる。他の高度化した注文タイプでは、小注文をかけての探知を避けるため、オープン価格を隠すのと同時に最低取引数量の条件を利用するものもある。価格が示されないことから、従来的な意味での価格発覚はないが、逆売買する大口トレーダーは、単に注文を、在する注文の指し値と交差するまで、悪い価格水準から徐々に、繰り返し出したり取り消したりすることで、最初の指し値を知ることが可能であり、実際、そのようにする信用義務がある。したがって、価格期待が取引に先立って変えられることはないが、３０．００ドルの大口買い注文を隠して電子証券取引ネットワークに出すトレーダーは、売り手が２９．９０ドルまでの価格ならいくらでも受ける意思があったとしても、実際に３０．００ドルでの取引になると予想しなければならない。
【００１０】
その結果、参加者の多くが、物陰に潜んで他の者がどの程度の値段を示そうとしているかを掴むほうが、又は一度に複数の小口を提示するほうが有益であるとすぐに気付いてしまことから、スーパーモンタージュなどの電子書籍は、アトラクティブな価格水準で大口注文を得るのに困難を有している。これは市場の変化につながり、市場では合計出来高及び平均機関発注規模が増加しているものの、平均取引規模は約５００株まで徐々に下がっている。
【００１１】
この状況のもと、逆売買する相手も積極的な場合に、自己の積極性を正確な値で内々に示す意思があるトレーダーに、価格改善という恩恵で報いる電子商取引システムが、急速に必要となっている。こうした大口取引についての解決策では、積極的なトレーダーの最適戦略は、積極的な値で注文を出すことであり、消極的なトレーダーは、必然的に、消極的な値の注文を出すことが一番良いということになる。
【００１２】
しかしながら、このニーズに答えること、つまり、人の仲介又は取引前の情報漏洩なく取引を約定出来るようにすることは、従来市場の電子商取引システムに認められる主な利点を犠牲にしてしまっては、成り立たない。
【先行技術文献】
【特許文献】
【００１３】
【特許文献１】米国特許出願第１０／３１０、３４５号
【特許文献２】米国特許出願第１０／６０３、１００号
【特許文献３】米国特許出願第１０／７９９、２０５号
【特許文献３】特開２００６−２３６３３８号公報
【発明の概要】
【発明が解決しようとする課題】
【００１４】
本発明は、積極的な指し値によって電子的に約定可能な注文を、逆売買する者もまた積極的な場合に、このような積極的な値で実際に約定されないよう守ることを課題とする。
【００１５】
電子的なスピード売買における周知の利点を失うことなく、そして第三者の仲介なく、積極的な注文を出した者にとって有利な展開とするには、積極的な値を示す意思のある者の交渉ポジションを強くできるバリューアイテムを見極めなければならない。このバリューアイテムの一つは情報である。２００３年６月２４日出願の関連出願第１０／６０３、１００号、２００１年５月３１日出願の関連出願第０９／８７０、８４５号、２０００年１２月２９日出願の関連出願第０９／７５０、７６８号、及び２０００年６月１日出願の関連出願第０９／５８５、０４９号（各出願が参照により全体としてここに盛り込まれる）では、公認の取引利益情報をコンピューターシステムに内々に公開する意思のある者が、どのように、彼らと取り引きをする意思がある者から、公認の取引利益情報を受け取る権利を得られるかについて開示されている。これらは、トレーダーが積極的な値の注文を取引システムに出したときの情報フローの矢印を逆にする可能性を開くもので、積極的な値がサードパーティに示されることはなく、その代りに、トレーダーが、消極的なオファーを出すサードパーティからの情報を得るのを支援する。
【００１６】
上記技術のユーザーは、本システムの中央取引サーバーに内密の取引情報を提示することなく、彼らの注文品管理装置（ＯＭＳ：Ｏｒｄｅｒ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ）にある流動資産を、本システムを用いる他のトレーダーに直接的に公開するという追加オプションを望むであろうと思われる。以下、この本システム中央取引サーバーを、ＰＴＳ（Ｐｉｐｅｌｉｎｅ  Ｔｒａｄｉｎｇ  Ｓｅｒｖｅｒ）又はパイプライン取引サーバーと呼ぶ。本発明は、分散プロセスを編成することで、このオプションをトレーダーに提供する。このプロセスでは、ＯＭＳに格納されている注文の指定サブセット及び／又はＯＭＳ内の注文自体に関する情報が、システム内に在する注文と照合チェックされるが、トレーダーは、この注文をＰＴＳに提示する必要はない。
【００１７】
したがって、本システムのユーザーが、内密の取引情報のセキュリティを犠牲にすることなく、ＯＭＳにある流動資産を公開できる様々な方法を展開し、それにより取引を向上させることが、本発明の目的である。
【課題を解決するための手段】
【００１８】
本発明の一様態は、本システムのユーザーがＯＭＳにある流動資産を公開出来る様々な方法を展開することによって、取引を向上させるものである。本様態において、ユーザーは、注文品管理装置内に潜在的な逆注文があるかについて本システムにサーチされることを許容すると決定したユーザーの、本システムのデスクトップアプリケーション（以下、クライアントＧＵＩとして参照）に対し、注文クエリーを、確固とした約定可能な注文を含む暗号メッセージの形で送ることが可能である。クライアントＧＵＩは、暗号化したクエリーに応えて、照合するものを見つけると、このＯＭＳがサーチされたユーザーに対し、クエリーに応えて、確固とした約定可能な注文を入れる機会を与える。その結果、本システムのユーザーは、ＰＴＳに内密の取引情報を全く送ることなく、注文品管理装置に格納されている流動資産の全てを、本システムにログインしている全ユーザーに公開することが可能となる。本態様では、１）ＰＴＳサーバーが、ユーザーのＯＭＳに何があるか「知っており」、そして２）本システムのユーザーが、注文品管理装置にある流動資産を本システムに在する注文に公開するためとして、ＯＭＳからＰＴＳに内密の取引情報を送る必要がないようになっており、注文約定のための分散市場を作れる。本様態は「コントラ（Ｃｏｎｔｒａ：逆売買）・ターゲティング」と呼ばれることもある。
【００１９】
本発明の他の様態は「バーチャルオーダー」であり、トレーダーの、注文品管理装置内の流動資産を公開するためのオプションを増加することによって、取引を向上させるものである。これは、本システムに入った注文に対し、約定の瞬間まで、この注文に示された株を実際にリザーブすることなく、本システムの注文キューにおける時間的なプライオリティを与える。本様態の目的は、ユーザーが、バーチャルオーダーで示された株の幾つか又は全てに対する逆の大口を待ちながら、バーチャルオーダーにある株の幾つか又は全てを市場の他のところで取り引き出来るようにすることである。そして、バーチャルオーダーが別の注文にマッチすると、本システムは、自動的にバーチャルオーダーの注文者のＯＭＳ又はバーチャルオーダーの注文者のＯＭＳに存在する情報を自動的にチェックし、バーチャルオーダーにある株で、まだ約定可能なものの数を断定する。そして、バーチャルオーダーにある株で約定可能なものを、可能な限り多くリザーブし、この注文を自動的に約定する。なお、バーチャルオーダーに示された株は約定の瞬間まで本システムでリザーブされないが、それでもバーチャルオーダーは、確固とした約定可能な債務であることに留意されたい。バーチャルオーダーが本システムにおいてマッチすると、発注したユーザーには、約定前に注文をキャンセルする又は注文の規模或いは価格を変更するオプションが与えられず、本システムは自動的に、バーチャルオーダーに示された株で、まだ約定可能なものを、可能な限り多く約定する。本システムには以前、本システムに入った大口注文が、本システム内に置かれ逆の大口を待つ間に、「拘束されて」本システムの外での約定が不可能となるという制限があり、これによりユーザーは本システムに入れる注文の数や規模を制限することが多かったが、上記特徴は、これに対処したものである。バーチャルオーダーオプションによって、現れるかどうか分からない逆の大口を待つ間に注文の幾つか又は全てを市場の他のところで運用する機会を逃す、ということがなく、それを分かっているから、トレーダーは、更に多くの大口注文を本システムに入れることが出来る。
【００２０】
参照により盛り込まれる上記出願に記載の本システム固有の様態の一つは、本システムの、流動資産を本システムに呼び寄せる方法であって、これには、本システムにおける確定注文のアクティビティの存在を、特殊記号でユーザーに報知するサイドレス、サイズレス、及びプライスレスな「アクティブシンボル通知」が用いられる。この流動資産を呼び寄せる方法を進歩させたものにおいては、ここに記載される本発明の様々な実施形態各々が、「ステルスモード」で使用可能で、このモードでは、上記アクティブシンボル通知に結び付く、知覚された情報漏洩源が排除される。このステルスモードは、何人かの顧客に対し、アクティブシンボル通知を全く引き起こさない、又は限定的にのみアクティブシンボル通知を引き起こす確固とした自動約定可能な注文を提出可能とすることで、これらの知覚された情報漏洩源に対処する。このステルスモードの目的は、本システムに注文を入れたいが、アクティブシンボル通知を通じて流動資産を呼び寄せようとすることに関心がないユーザーに、注文エントリーオプションを与えることである。
【００２１】
このステルスモードの最良の形態では、注文発注時にトレーダーに「ステルス」注文エントリーオプションが与えられるが、これは、ここに記載の「ダーク」又は「ブラック」注文を示すルールに従うことも可能である。なお、ステルス、ブラック、及びダークという用語は全て、特定ユーザインターフェースに対応するものであって、限定として解釈されるべきではない。また、ステルスオプションに関連付けられるルールは、企業／ユーザーレベルで、ＰＴＳ上で設定してもよい。
【００２２】
最良の形態では、ステルス注文に対するディフォルトルールはダークとなるが、他の実施形態では、ディフォルトをブラックとすることも可能である。最良の形態では、ダーク及び／又はブラックステルス注文オプションは、バイサイドの顧客の一部にのみに提供されるが、他の実施形態では、ステルス注文は、バイサイド及びセルサイドのユーザー全てを含む全顧客に提供されることとなる。
【００２３】
ユーザーが、確固とした自動約定可能な注文を「ダーク」としてシステムに入れると、「標準」注文を取り扱うルールにあるようにアクティブシンボル通知を引き起こすのではなく、対応するシンボルがアクティブシンボル通知を表示しない。更に、その注文が本システムにおいてアクティブになっても、その注文は、最低限のアクティブシンボル通知しか引き起こさない。また、通知が引き起こされても、非常に短時間しか続かないし、通知間に大幅な間隔がある。具体的に言うと、ダーク注文がアクティブシンボル通知を生じさせると、通知が、１秒から４０秒間隔で、（ＩＯＣ（ｉｍｍｅｄｉａｔｅ  ｏｒ  ｃａｎｃｅｌ：即時又はキャンセル）注文のように）限定期間だけ点滅する。また、ダーク注文には権利がない、つまり本システムの注文キューにおける価格−時間的プライオリティが与えられない。具体的に言うと、ダーク注文と同時に、同一シンボル、同一値、及び同一サイドの注文がシステムに在する場合、これはダーク（又はブラック）としては分類されずに逆注文がシステムに入り、ダークでない注文は、ダーク注文の後に入っていたとしても、約定を受けることになる。
【００２４】
ダーク注文は逆売買の存在指摘を引き起こすことになる。これは、本システムの、流動資産の種類についての通知の一つで、本システム内に「消極的な」（基準値より下の値の注文）逆注文が存在することをユーザーに報知するものである。この基準値は、２００４年３月１１日出願の米国出願番号第１０／７９９、２０５号に記載されているような基準値にもなりえるし、当業者であれば想像がつくような、現行市場価格を反映する他の基準値にもなりえる。はじめに述べたとおり、逆売買の存在指摘は、「積極的な」注文（基準値より上の値の注文）をする意思があるユーザーに、積極的な注文が消極的な注文とマッチした場合に、情報フローを逆転し、基準値の中間より下の値で取り引きするオプションを与えることで、報いることを目的としたものである。具体的には、ダーク注文が消極的な注文である場合に、積極的な逆注文がシステムに入ると、この消極的なダーク注文に対し積極的な逆注文を入れたユーザーは、その消極的なダーク注文の存在をユーザーに報知する逆売買の存在指摘を受信する。また、ダーク注文が積極的な値を有している場合に、この積極的なダーク注文に対しユーザーが消極的な逆注文を入れると、積極的なダーク注文を入れたトレーダーは、その消極的な逆注文の存在をユーザーに報知する逆売買の存在指摘を受信する。
【００２５】
ユーザーが確固とした自動約定注文を「ブラック」としてシステムに入れた場合、この注文がアクティブシンボル通知を生じさせることは絶対にない。加えて、積極的な逆注文がシステムに入った場合に、消極的なブラック注文が逆注文の存在指摘を引き起こすことはなく、また、積極的なブラック注文が、別のユーザーがこの積極的なブラック注文に対し消極的な逆注文を入れた場合に、逆注文の存在指摘を見る権利をユーザーにもたらすこともない。ダーク注文と同じく、ブラック注文には権利がない、つまり注文キューにおける価格−時間的プライオリティが与えられない。具体的に言うと、ブラック注文と同時に、同一シンボル、同一値、及び同一サイドの注文がシステムに在する場合、これはブラック（又はダーク）としては分類されずに逆注文がシステムに入り、ブラックでない注文は、ブラック注文の後に入っていたとしても、約定を受けることになる。ブラック注文オプションについては、この機能にアクセスする権限を有する特定の認定ユーザーに限定してもよい。この権限は、当業者であれば理解されるであろう様々な基準に基づいて与えることが可能で、該基準としては、例えば、バイサイドなのかセルサイドの顧客なのか、又は管理資産などの、ユーザー又は企業レベルでの取引経過歴史又は企業分類が挙げられるが、これに限定されない。
【発明の効果】
【００２６】
本発明によりもたらされる効果の一つは、注文品管理装置の全内容をＰＴＳに入れなくても、注文品管理装置の流動資産を公開すること及び他のトレーダーの注文品管理装置の流動資産を調べることが、ユーザーに可能となることである。本発明の他の効果については、続く説明により、容易に明らかなものとなるだろう。
【図面の簡単な説明】
【００２７】
【図１】図１は、本発明の最良の形態におけるコントラ・ターゲティングのための注文エントリー画面の一例を示している。
【図２】図２は、コントラ・トラッキングのためのポップアップ通知の一例を示している。
【図３】図３は、本発明の最良の形態におけるバーチャル注文のための設定管理スクリーンを示している。
【図４Ａ−１】図４Ａ−１は、最良の形態におけるコントラ・ターゲティングのフローチャートである。
【図４Ａ−２】図４Ａ−２は、最良の形態におけるコントラ・ターゲティングのフローチャートである。
【図４Ｂ−１】図４Ｂ−１は、最良の形態におけるコントラ・ターゲティングのフローチャートである。
【図４Ｂ−２】図４Ｂ−２は、最良の形態におけるコントラ・ターゲティングのフローチャートである。
【図４Ｃ−１】図４Ｃ−１は、最良の形態におけるコントラ・ターゲティングのフローチャートである。
【図４Ｃ−２】図４Ｃ−２は、最良の形態におけるコントラ・ターゲティングのフローチャートである。
【図４Ｃ−３】図４Ｃ−３は、最良の形態におけるコントラ・ターゲティングのフローチャートである。
【図５】図５は、最良の形態におけるバーチャル注文の発注のフローチャートである。
【図６Ａ】図６Ａは、本発明の好適又は他の実施形態を実装可能なシステム及び変形例の概念図である。
【図６Ｂ】図６Ｂは、本発明の好適又は他の実施形態を実装可能なシステム及び変形例の概念図である。
【図６Ｃ】図６Ｃは、本発明の好適又は他の実施形態を実装可能なシステム及び変形例の概念図である。
【発明を実施するための形態】
【００２８】
本発明の好適実施形態について、図面を参照して詳細に説明する。まず、図面４Ａ−４Ｃのフローチャートを参照して詳細に説明する。ここで、コントラ・ターゲティング機能を実行可能にする主要素は３つある。
【００２９】
第一の要素はコントラ・リクエストサービスと呼ばれるものである。このバックエンドサービスはＰＴＳに常駐し、コントラ・ターゲティングを依頼する注文を処理する。そして、依頼注文に設定されている基準に基づいて、コントラ・ターゲット通知を受け取る資格が潜在的にある候補トレーダーのリストを生成する。それから、コントラ・ターゲット告知要求を流布し、コントラ・ターゲットリザルトを収集する。
【００３０】
第二の要素はクライアントＧＵＩと呼ばれるものであり、これはトレーダーが有するワークステーションのデスクトップ上で動作可能である。クライアントＧＵＩは、トレーダーのＯＭＳに格納されているコントラ・ターゲット注文の属性及びデータに基づき、適性スコアを計算する役割を担う。ランキングサービスにより、トレーダーのＯＭＳにある注文が適格であると判定され、クライアントＧＵＩによる通知の表示が許可されると、クライアントＧＵＩは、トレーダーに対しコントラ・ターゲット通知を表示する。
【００３１】
第三の要素はランクキングサービスと呼ばれるものである。ランキングサービスは、独立したバックエンドプロセスであり、ＰＴＳに常駐することも可能であるし、サードパーティの所にあってもよい。これは、コントラ・ターゲットの適性スコアを評価し、適格なクライアントＧＵＩに対し、コントラ・ターゲット通知を表示する許可を与える。
【００３２】
コントラ・ターゲットオプションは、市場の最良気配により決定される相場の中値、２００３年６月２４日出願の米国出願番号第１０／６０３、１００号に記載されているブロック値幅の中値、或いは当業者であれば想像がつくような、相場の中値を反映する他の公開価格の中値で、又は相場の中値より積極的な指し値で約定するよう相場に固定されている注文をクライアントＧＵＩを介して出すトレーダーに、注文ごとに利用可能である。また、下記の表１に示す通り、コントラ・ターゲティングには４つのレベルがある。
【００３３】
【表１】
2010534892.tif 000003
【００３４】
ＰＴＳは、他のアプリケーションを介して送られた注文の、空値／未確認のコントラ・ターゲティングオプションの概念にも対応するようになっている。コントラ・ターゲティングが空値の注文を受けると、サーバーは企業レベルで設定されているコントラ・ターゲットレベルを適用する。初期段階では、このレベルは「０：無」であり、システム管理者は、後にそれを「１：近時にアクティブ」に変更するよう選択可能である。
【００３５】
新たな注文依頼で、「無し」以外の値に設定されたコントラ・ターゲティングオプションを有したものを受ける（図４Ａ、ステップ４１０２）と、コントラ・リクエストサービスには、受信候補者のリストの作成が課せられ、受信候補者リストを構築する（図４Ａ、ステップ４１０４）ために、表２に記載のパイプライン顧客企業情報を知る必要が出てくる。この情報はシステムデータベースに記憶され、システムヘルプデスクアプリケーションを介してアクセス可能となる。なお、他の企業属性のように、これは「ライブアップデート可能」であるべきである。
【００３６】
【表２】
2010534892.tif 000004
【００３７】
コントラ・ターゲット・リクエストサービスは、新しい注文に対する、コントラ・ターゲティング評価の基準に基づく、受信適格者の初期リストの作成に、これらの企業属性を用いる。近時のアクティビティに基づくコントラ・ターゲットメッセージの適格対象となるためには、トレーダーは、以下の適格性の一つを満たさなければならない。第一の適格性とは、トレーダーが、コントラ・ターゲット適格対象−近時のアクティビティ、に関して正と設定されている企業にいなければならない、というものである。第二の適格性とは、トレーダーが、機関又は投資信託会社である企業にいなければならない、というものである。第３の適格性とは、トレーダーが、以下の基準にマッチする注文を出していなければならない、というものである。その基準とは、受信者が、在するための特定要件を少なくとも一つ満たしている、注文価格が（市場が開いた時点又は発注時のいずれか早い時点の）基準値以上である、又は発注時の発注数が、コントラ・ターゲット・リクエストに対する最小適格数以上である、というものである。
【００３８】
在するための要件は、注文が、キャンセルされている又は締め切られているものの、市場が開いた後に最低でもＮ分システムに残っている場合、注文が、キャンセルされている又は締め切られているものの、最小規模条件（以下、大口数量又はＬＢＱ（Ｌａｒｇｅ  Ｂｌｏｃｋ  Ｑｕａｎｔｉｔｙ）として参照）を満たし、約定がすでになされている場合、注文がシステムにおいて現在アクティブであるものの、その値が基準値より下に限定されている場合、注文がシステムにおいて現在アクティブであるものの、その最小約定可能数が原注文にとって大きすぎる場合、注文がシステムにおいてアクティブであり、その価格が基準値以上である場合、又は注文が、キャンセルされている又は締め切られているものの、その価格が基準値以上であった場合に満たされる。注文が、その日の株取引が始まった後に出された場合、その注文発注時に、その価格が基準値以上であれば、在するための要件が満たされる。注文が、株式市場が開かれる前に出された場合、市場が開かれた時に、その価格が基準値以上であれば、在するための要件が満たされる。
【００３９】
コントラ・ターゲット・リクエストを入れたユーザーが、レベル１のみを選択している場合、リスト作成はここで完了するが、レベル２又は３を選択している場合、更なるチェックが行なわれなければならない。
【００４０】
レベル１のコントラ・ターゲット通知を受信する資格があるトレーダーは、アクティブシンボル通知の受信から除外されている状態の可能性がある。コントラ・ターゲット注文がレベル２又は３をターゲットとしいる場合、適当な企業タイプにマッチする者であって、「コントラ・ターゲット適格対象−ＯＭＳ」が正と設定されている企業のトレーダーが、コントラ・リクエストサービスにより、候補者リストに加えられる。
【００４１】
コントラ・リクエストサービスにより、コントラ・ターゲット候補者のリストが作成されると、各候補者にコントラ・ターゲット・リクエストメッセージが送られることとなる（図４Ａ、ステップ４１０６）が、このコントラ・ターゲット・リクエストメッセージとともに、コントラ・ターゲットを依頼している注文に関連したデータであって、トレーダーに通知が表示されるべきかどうかの判定（図４Ａ、ステップ４１１０）に用いられる事前適正スコアを、クライアントＧＵＩに計算させる（図４Ａ、ステップ４１０８）ことを可能とするのに十分なものも送信される。コントラ・ターゲット・リクエストとともに送信されるデータは以下の通りである。
【００４２】
コントラ・ターゲット・リクエスト
【００４３】
【表３】
2010534892.tif 000005
【００４４】
コントラ・ターゲット・リクエストは、本システムがその日の取引をシンボル内で開始するまで、送られることはない。本システムが、その日の取引をシンボル内で開始する前に注文が出された場合、コントラ・ターゲット・リクエストはＰＴＳに保留される。そして、取引のためシンボルが開かれると、候補者リストが作成され、コントラ・ターゲット・リクエストが送られる。
【００４５】
コントラ・ターゲット通知がクライアントＧＵＩで表示された（図４Ａ、  ステップ４１２４）後、それが期限切れになる又はコントラ・ターゲット・リクエストがキャンセルされると、コントラ・ターゲット応答メッセージは、コントラ・リクエストサービスまで下記データとともに送り戻される（図４Ａ、ステップ４１２６）。
【００４６】
コントラ・ターゲット応答
【００４７】
【表４】
2010534892.tif 000006
【００４８】
ステップ４１２４及び４１２６における期間タイマーは、内密の取引利益情報の表示属性が表示される時間を管理するために提供される。この時間が過ぎると、表示が終了し、広告結果がコントラ・リクエストサービスに送り戻せるようになる。広告結果は、１つ以上の広告依頼メッセージＩＤ、広告依頼メッセージ適性スコア、表示属性の表示に応答して市場参加者が入れた応答注文数を含むことが可能である。これらの情報は、記録及び本システムの調査部にＥメール送信可能で、調査部においては、これは、市場参加者が内密の取引利益情報の表示属性の表示を見つつも応答しない頻度をモニタリングし、ユーザーのビヘイビアを管理規制するのに用いることが可能である。非応答が一定のしきい値を超えると、コントラ・リクエストサービスは、本システムのヘルプ・デスクに対し、市場参加者への連絡を促す通知を生成可能で、この連絡により、コントラ・ターゲット通知を悪用し、応答注文を入れることなく繰り返しコントラ・ターゲット通知を見る選択を行っている行為に、警告がなされる。また通知を生成せずに、次からコントラ・ターゲットメッセージを受信できないよう、この市場参加者を自動的に阻害することも可能である。また、コントラ・リクエストサービスは、広告している通知メッセージから得た情報を記憶可能で、それによりコントラ情報の受信と値動きの関連性を示すスクリプトを実行するための調査が可能となる。関連性がある場合、次からのコントラ・ターゲットメッセージを受信できないよう、市場参加者を阻害することが可能である。
【００４９】
クライアントＧＵＩにより送られたコントラ・ターゲット応答結果メッセージと共にコントラ・リクエストサービスにキャッシュされたデータに基づき、コントラ・ターゲットログエントリーが生成される（図４Ａ、ステップ４１２８）。これには、下記データが取り込まれることとなる。
【００５０】
コントラ・ターゲット表示ログ
【００５１】
【表５】
2010534892.tif 000007
【００５２】
この情報は、電子メールを介して調査部に送られこととなる。またデータ・ウエアハウスに記憶する必要もある。
【００５３】
上述の通り、ランキングサービスの目的は、適格なクライアントＧＵＩからの表示許可要求を処理し（図４Ａ、ステップ４１１２）、コントラ・ターゲット通知の表示を許可又は拒否することであり、このサービスは、コントラ・ターゲット・リクエストに関連する注文、発注したトレーダーのＯＭＳ、又はターゲットとされたトレーダーのＯＭＳについての特別な情報なく、このロジックを実行する。
【００５４】
本実施形態の変形例においては、ランキングサービスは、表示許可要求を、コントラ・ターゲット・リクエストＩＤに基づいて集約して、収集してもよい。表示許可要求は、各々が表６に記載のデータフォーマットを有する。
【００５５】
表示許可要求
【００５６】
【表６】
2010534892.tif 000008
【００５７】
本実施形態は、即座に要求に応答するよう構成可能である。
【００５８】
図４Ａのステップ４１１４で、ランキングサービスは、依頼している企業の最低スコア（最低取引数量未満であるという可能性を排除するため初期値は０．１）に対するコントラ・ターゲットスコアを評価し、図４Ａのステップ４１１６で表示に適格かどうか判定する。そして、ランキングサービスが、スコアが最低コントラ・ターゲット適性スコアより大きい要求全てに表示許可を与える（図４Ａ、ステップ４１１８）。なお、最低コントラ・ターゲット適性スコアは、企業ごとに割り当てられた設定可能な値で、この値は初期値を０（与えられた全要求）に設定することができる。大きくない要求には、図４Ａのステップ４１２０で、ランキングサービスによりコントラ・ターゲット表示拒否通知が送られ、そしてステップ４１２２で、そのＧＵＩは、コントラ・ターゲットシンボル／サイドの新たなＯＭＳイベントを待つことになる。
【００５９】
ランキングサービスは、そのビジネスロジックを実行するため、これらの企業構成による設定を用いることとなる。
【００６０】
【表７】
2010534892.tif 000009
【００６１】
ヘルプ・デスクによる編集には日中効果がある。
【００６２】
表示許可応答には以下のものが含まれる。
【００６３】
表示許可応答
【００６４】
【表８】
2010534892.tif 000010
【００６５】
クライアントＧＵＩによる作業は、表示許可を得ることと実際の表示とに関連するステップ間で割けることが可能である。クライアントＧＵＩは、コントラ・ターゲット・リクエストをキャッシュし、ＯＭＳ情報とリクエストメッセージ内の情報とに基づき、コントラ・ターゲット一致度及び価格度スコアを計算する。コントラ・ターゲット適性スコアは以下のように計算される。まず、一致度スコアの初期値が以下のように設定される。
【００６６】
一致度スコアの初期値設定
【００６７】
【表９】
2010534892.tif 000011
【００６８】
次に、数量不一致の場合は０にセットされ、ＯＭＳに一致がある場合、２又は６増える。ＯＭＳに完全な一致（シンボルが同じで、逆サイドであり、取引可能数量が最低取引数量以上で、現在の値が、ＯＭＳ内に指し値がある場合に、その範囲内）がある場合、初期スコアに６が加えられる。最低取引数量において不一致があるが、取引可能数量がＬＢＱより大きい場合、スコアは０．０２にセットされ、取引可能数量がＬＢＱ未満の場合、スコアは０．０１にセットされる。指し値においてのみ不一致がある場合、初期スコアに２が加えられる（トレーダーはＰＭに連絡可能）。
【００６９】
第三に、価格度スコアがセットされる。「優先価格」は、（順次に）（ａ）（ＯＭＳに）本日現在までに成立したものがあれば、その平均価格、（ｂ）利用可能であれば、その注文が最初にＯＭＳにヒットした時の着値（ＯＭＳに対する日中変動として、これが変動時のＮＢＢＯ（Ｎａｔｉｏｎａｌ  Ｂｅｓｔ  Ｂｉｄ  ａｎｄ  Ｏｆｆｅｒ：市場の最良気配）中値となる可能性がある）、（ｃ）指し値があれば、指し値、（ｄ）現行価格、となるようセットされる。相対価格向上は優先価格から現行価格までで計算され、価格度スコアは、ＯＭＳの売り注文に対してはｘ＝（Ｓ−Ｓ＿プリファレンス）／Ｓ＿プリファレンスであり、ＯＭＳの買い注文に対しては、この反対記号となる。
【００７０】
クライアントＧＵＩが、０を超える適性スコアに行き着くと、表示許可要求がランキングサービスに送信される。そしてＧＵＩは、許可要求の送信後程なくして、表示許可応答メッセージを受信することになる。表示フラグが「Ｙ」の表示許可応答を受信すると、ＧＵＩは、コントラ・ターゲッティング通知を表示し、表示有効期間の終了カウントダウンを開始する。
【００７１】
適格なトレーダーはコントラ・ターゲットシンボル通知を受信することとなり、システム内に継続注文を有するコントラ・ターゲット（大きい最小値又は基準値未満の指し値）が受信されると、「中値での取引」を読出す追加注文エントリーオプションが出る。この注文エントリーオプションを選択するとＩＯＣ（ｉｍｍｅｄｉａｔｅ  ｏｒ  ｃａｎｃｅｌ：即時又はキャンセル）注文が出される。その注文に出された数量が、逆注文の最小規模条件を満たさない場合、システムは、完全に適格な数量まで取り引きするオプションを、応答トレーダーに提供することができる。
【００７２】
コントラ・ターゲット通知されたシンボルに注文を出す場合、トレーダーに利用可能な主要ワークフローは２つある。「通常の注文エントリー」及び「今それを買う」である。通常の注文エントリーは、アクティブシンボル通知に応答すること、又はシンボル内にアクティブシンボル通知がないときに注文を出すことと同じであり、シンボルをクリックしドラッグすることで３つの注文エントリーオプション、つまり「大口＋エンジン」、「尾口のみ」、及び「ステルス」が表示される。これらの３つの注文オプションは、（２００３年６月２４日出願の継続中の出願第１０／６０３、１００号、２００４年３月１１日出願の継続中の出願第１０／７９９、２０５号、及び継続中の出願第１１／７８３、２５１号に記載の）本システムのブロック市場にのみ注文を出すため、（出願番号第１１／７８３、２５０号及び２５１号に記載の）ブロック市場及びアルゴリズムスイッチエンジンに注文を出すため、又は上述のステルス注文オプションを利用し、ブロック市場或いはブロック市場及びアルゴリズムスイッチエンジンに注文を出すためとして、クライアントＧＵＩを利用する際に、トレーダーが出来ることを表す。また、トレーダーは、コントラ・ターゲット通知を利用し、そのプレファレンスを「コントラ・ターゲットについての通知を無視」にセットするオプションも有している。コントラ・ターゲット通知が表示される場合に、注文がアクティブ（コントラ・ターゲット受信者の注文が遠くに制限されている、又はコントラ・ターゲット受信者の注文に大きい最小取引条件があることを意味する）であれば、シンボルをクリックしドラッグすることで、「交換」及び「キャンセル」という注文管理オプションが表示される。
【００７３】
トレーダーがコントラ・ターゲット通知を表示するシンボルに注文を出した後は、本システムの、アクティブシンボル通知に対する通常ルールが実行される。ほとんどの場合、コントラ・ターゲット通知に対するタイムリーな応答は成立する結果となる。トレーダーが通知に応答する時点で、コントラ・ターゲット注文が積極的でなくなっている場合、応答するトレーダーはコントラ存在通知を受ける。開始されたコントラ・ターゲット注文が、競合条件により、システムにおいてアクティブでなくなった場合、又は注文価格が市場の最良気配の範囲外に落ちた場合、優勢注文属性及び市場情勢に応じて、アクティブシンボル通知は「ＯＮ」又は「ＯＦＦ」される。
【００７４】
「今それを買う」においては、トレーダーは、更なる注文エントリーオプションを有し、これにより、コントラ・ターゲット通知に対する簡単なＩＯＣタイプの応答が容易なものとなる。この更なる注文エントリーオプションのブロックをドラッグしドロップすることで、ＩＯＣ注文（現在アクティブであれば、新たなものか、交換するものいずれか）が出され、現在消極的な指し値が取りやめられるか、基準値に固定した指し値がセットされる。新たな注文では、適格な数量が１００％本システムのブロック市場に入れられる。さらに、注文エントリーオプションによって、トレーダーは、その取引日の残りの間コントラ・ターゲット通知を無視するという選択がシンボルで出来る。コントラ・ターゲット通知に対し、無視するオプションを選択することで、トレーダーは、その取引日中、コントラ・ターゲット通知が、その名で生成されることを停止することが出来るようになるのである。  この「無視」メニューは、「この逆売買大口注文を無視」、「シンボル内の全コントラ通知を無視」、又は「無視」オプションが既に選択されている場合に、「［シンボル］コントラ通知を有効」など、いくつかのオプションを提供するが、これらに限定されない。
【００７５】
以下のイベントの一つが起こるまで、コントラ・ターゲット通知は受信者のクライアントＧＵＩに残る。まず、コントラ・ターゲット原注文がキャンセルされた、成立した、又はＬＢＱ未満で部分的に成立した場合に、そのコントラ・ターゲットのためのキャンセルメッセージが、サーバーより送られる。コントラ・ターゲットキャンセル通知において、リクエストＩＤは、そのコントラ・ターゲット・リクエスト特有の識別子であり、クライアントＧＵＩは、このコントラ・ターゲット・リクエストＩＤにマッチするコントラ・ターゲット通知を表示している場合、コントラ・ターゲット通知インジケータを即座にオフにし、キャッシュから通知を消去してから、コントラ・ターゲット結果メッセージを送る。また、表示有効期間が満期終了となった場合、コントラ・ターゲット通知が非アクティブとされ、そしてコントラ・ターゲット結果が送られる。コントラ・ターゲット通知が無効となると、受信者の、今後の通知を受信する適格性を保証するのに利用されるメッセージが、コントラ・リクエストサービスまで送り戻される。なお、クライアントＧＵＩは、与えられたシンボル／サイドについて、一度に一通しかコントラ・ターゲット通知を表示せず、現在表示されているシンボル／サイドにコントラ・ターゲット・リクエストが到達すると、クライアントＧＵＩは、その新たな告知要求を引き下げる。クライアントＧＵＩが、そのシンボル／サイドのためのコントラ・ターゲット通知を現在表示していない場合、そのリクエストは、「ペンディング」状態の他のものとともにキャッシュされる。
【００７６】
適性スコアが０であることにより又はランキングサービスが表示許可要求を拒否することにより表示出来ないというコントラ・ターゲット通知を、クライアントＧＵＩが受けることはよくあることとなるが、これらの「非表示」コントラ・ターゲット・リクエストは、キャッシュに保持される。
【００７７】
ＯＭＳのスイープイベントのたびに、クライアントＧＵＩはキャッシュを調べ、新たなＯＭＳ注文が到着しているか、又は既存のＯＭＳ内注文が変わって適格性関数が０を超える結果に戻っているかどうか見る。
【００７８】
同じシンボルに対し、シンボル通知に影響する複数の条件が当てはまる場合、優先順位は、コントラ存在、コントラ・ターゲット、シンボルアクティビティとなる。例えば、トレーダーＡが、中値での１００万株の買い注文を、３０％の最低取引数量で出し、トレーダーＢが、指し値での５００、０００株の売り注文を出し、そしてトレーダーＣが、中値での１００、０００株の売り注文を出したとすると、トレーダーＡは、コントラ存在通知、及びコントラ存在及びコントラ・ターゲット通知を見ることになる。
【００７９】
本コントラ・ターゲティング機能は、「改良された注目銘柄一覧」とのインテグレーションも可能であるようされるべきである。注目銘柄一覧については、出願番号第１１／７８３、２５１号及び第１１／７８３、２５４号に記載されており、改良された注目銘柄一覧とはシンボル、サイド、及び適格数量情報を提供するものである。クライアントＧＵＩは、注目銘柄一覧と共に機能するように構成した場合に、コントラ・ターゲット通知を受けると、コントラ・ターゲット通知を表示すべきかどうか判定するための、ＯＭＳとのインテグレーションのロジックと類似するロジックで、機能するはずである。
【００８０】
その様々な構成データを以下に示す。
【００８１】
企業構成データ
【００８２】
【表１０】
2010534892.tif 000012
【００８３】
他の構成データ
【００８４】
【表１１】
2010534892.tif 000013
【００８５】
コントラ・リクエストサービスによりクライアントＧＵＩに送信されるコントラ・ターゲット・リクエストは、下記を含む。
【００８６】
コントラ・ターゲット・リクエスト
【００８７】
【表１２】
2010534892.tif 000014
【００８８】
トレーダーへのコントラ通知の表示が完了した後、クライアントＧＵＩにより、コントラ・ターゲット応答がコントラ・リクエストサービスに送られる。なお、元となる通知が表示されなかった場合、この応答は送られない。
【００８９】
コントラ・ターゲット応答
【００９０】
【表１３】
2010534892.tif 000015
【００９１】
コントラ・ターゲット・リクエストが処理され、適性スコアが０を超えると計算されると、表示許可要求が、クライアントＧＵＩにより、ランキングサービスに送られる。
【００９２】
表示許可要求
【００９３】
【表１４】
2010534892.tif 000016
【００９４】
ＧＵＩによる元となるコントラ・ターゲット通知の表示が認められるか否かを示すため、ランキングサービスにより、表示許可応答がクライアントＧＵＩに送られる。このメッセージは、表示許可要求の受信後すぐに送られてもいいし、多少遅れてもよい。
【００９５】
表示許可応答
【００９６】
【表１５】
2010534892.tif 000017
【００９７】
コントラ・ターゲットキャンセル通知は、コントラ・ターゲット・リクエストがもはや有効ではないことを示すためとして、コントラ・サービスからクライアントに送られる。これは、発注された注文のキャンセル、完了、又はＬＢＱ未満の値に対する部分的な約定などにより起こり得る。そのリクエストＩＤは、コントラ・ターゲット・リクエストで送られた特有の識別子である。
【００９８】
注文のキャンセルについては、図４Ｂを参照して説明されるが、これは、下記を除いて、図４Ａに類似している。まず、コントラ・リクエストサービスが、ステップ４２０２で、コントラ・ターゲット注文に対するキャンセル要求を受け、ステップ４２０４で、コントラ・ターゲット・キャンセル要求を、当該コントラ・ターゲット・リクエストＩＤを格納するコントラ・ターゲットに適格なＧＵＩ全てに送る。次に、ステップ４２０６で、ＧＵＩが、コントラ・ターゲットキャンセル要求を受ける。そして、ステップ４２０８で、コントラ・ターゲット通知が表示されているものかどうかが判定され、そうでない場合、キャンセルプロセスが図４２１０にて終了となる。他の場合には、プロセスがステップ４１２６及び４１２８に移行する。
【００９９】
同じシンボル／サイドに対する複数のコントラ・ターゲット通知に関するワークフローは、図４Ｃで示されるが、これは下記を除き、図４Ａに類似している。つまり、ステップ４３０２で、ＧＵＩが、そのシンボル／サイドのコントラ・ターゲットを現在表示しているかどうかが判定され、そうでない場合、ステップ４３０４で、コントラ・ターゲット・リクエストが引き下げられ、プロセスがステップ４３０６で終了となる。他の場合には、ステップ４３０８で、ＧＵＩが、上述のようにキャッシュされたコントラ・ターゲット・リクエストをすべて評価し、図４Ａにおけるようにプロセスが進む。
【０１００】
先に開示された実施形態と共に又は別個に利用可能な本発明の他の実施形態は、バーチャル注文であり、これは下記のように実施可能である。図３は、本システムの最良の形態のための設定管理スクリーンを表しており、ここでは、符号３００にあるように、ユーザーが、本システムによるＯＭＳ発注の作成を、注文が本システムに最初に入れられる時に行わせたいのか、それとも約定前に行わせたいのかを選択可能である。ユーザーには、本システムに注文を入れる際に、その注文がＰＴＳ内でどのように処理されるかについて、２つのオプションがあり（図３、符号３００）、そのＯＭＳからの注文に示されている株を、ＰＴＳに「リザーブ」させるのか、それとも獲得させるのかを選択することができる。発注時に、株がリザーブされた場合、これらの株は本システム内に「拘束され」、他のところで約定不可能となる。一方、ユーザーは、注文を入れる際に、バーチャル注文を入れる選択をすることもできる。これは、注文発注時に、実際に株をリザーブするのではなく、ＰＴＳ内にバーチャル注文又は「プレースホルダ」注文を作り出すというものである。（図５、  ステップ５０２）。本システム内に、その「プレースホルダ」注文に対する逆売買注文が到達すると（図５、ステップ５０４））、約定の前に、本システムは、バーチャル注文を入れたユーザーのＯＭＳにある注文情報をチェックするか、又はそのバーチャル注文で示されている株のいくつが今も取引可能であるか断定するため、ユーザーのＯＭＳを直接チェックする。株の幾つか又は全てがまだ約定可能な場合、本システムは、そのバーチャル注文で示されている株の残りを、可能な限り多く自動的に約定することとなる（図５、ステップ５０６）。なお、重ねて言うが、ここで留意すべき重要点は、バーチャル注文に示されている株は、約定の瞬間まで本システムにリザーブされないが、それでも、このバーチャル注文は確固とした、自動約定可能な債務であるということである。バーチャルオーダーが本システムにおいてマッチすると、発注したユーザーには、約定前に注文をキャンセルする又は注文の規模或いは価格を変更するオプションが与えられず、本システムは自動的に、バーチャルオーダーに示された株で、まだ約定可能なものを、可能な限り多く約定する。
【０１０１】
下記は、バーチャル注文オプションが本システム内でどのように機能するかの具体例である。まず、ユーザーが、１、０００、０００株のバーチャル注文を入れる。その１、０００、０００のバーチャル注文に対する逆売買注文が本システムに達すると、ＰＴＳマッチングエンジンは、バーチャル注文とともに該ユーザーのクライアントＧＵＩに送る、暗号化されたメッセージを生成する。次に、この暗号化されたメッセージが、ＯＭＳ内においてバーチャル注文に示された１、０００、０００株の幾つか又は全てがまだ取引可能か、クライアントＧＵＩに尋ねる。そして、本システムが、ユーザーのＯＭＳにある注文情報をチェックするか、又は示されている株の幾つか又は全てが今も取引可能であるか断定するため、ユーザーのＯＭＳを直接チェックする。株の幾つか又は全てが、まだ取引可能である場合、クライアントＧＵＩは、ＰＴＳに対し、取引可能な株最大数で真の発注（物理的にそれらの株を予約するもの）を作成するメッセージを送り返す。この例では、元となる１、０００、０００株のバーチャル注文のうち９００、０００がまだ取引可能であった場合、クライアントＧＵＩは、９００、０００株の発注を送る。その結果、注文が最大取引可能数で自動約定する。トレーダーが、これら逆注文間の自動約定を進めるステップに気づくことはなく、また、いずれかのトレーダーに、この注文を約定前にキャンセル又は多少なりとも変更するオプションが与えられることもない。
【０１０２】
図６Ａ−６Ｃは、上記の実施形態または他の実施形態を実装可能なハードウェアを示す概念図である。図６Ａは、ミドルウェアがないインプリメンテーションを示しており、顧客ＯＭＳ６０２及びクライアントＧＵＩ（デスクトップアプリケーション）６０４を動作させるワークステーションが、ファイアウォール６０６の後ろにある。ＯＭＳ６０２とクライアントＧＵＩ６０４は、それぞれ仮想プライベートネットワーク６０８及びインターネット６１０、そして取引サーバー（ＰＴＳ）６１４に対する他のファイアウォール６１２を通じて情報をやりとりする。矢印Ａはスイープイベントを、矢印Ｂは発注及び約定を、矢印Ｃは、ＦＩＸ（Ｆｉｎａｎｃｉａｌ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｅｘｃｈａｎｇｅ：財務情報交換）承認及び非承認を、そして矢印Ｄは、クライアントＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ：アプリケーション・プログラミング・インターフェース）を示している。
【０１０３】
図６Ｂは、カスタマサイトにおけるミドルウェアの使用を示す。ＧＵＩ６０４は、取引ＡＰＩ６１６及びＯＭＳ−ＡＰＩ６１８を含み、ミドルウェア６２０は、ＦＩＸエンジン６２２及びネットサーバー６２４を含む。また、ＧＵＩ６０２及びミドルウェア６２０は、顧客ファイアウォール６２６の後ろに常駐する。ＧＵＩ６０４の取引ＡＰＩ６１６は、矢印Ｅで示されるように、顧客ファイアウォール６２６、インターネット６１０、及びバックエンドファイアウォール６２８を介してバックエンドシステム６３０と情報をやりとりする。なお、バックエンドシステム６３０もまたＦＩＸエンジン６２２及びネットサーバー６２４を有している。取引立会いにおいて、バックエンドシステム６３０は、矢印Ｆで示されるように、ファイアウォール６２８、ＶＰＮ６０８、及び他のファイアウォール６３２を介して、ＯＭＳバックエンドシステム６３４と情報のやりとりをする。そして、ＯＭＳ公開立会いにおいて、ＯＭＳバックエンドシステムは、矢印Ｇで示されるように、ファイアウォール６３２、ＶＰＮ６０８或いはインターネット６１０、及び顧客ファイアウォール６２６を介して、ミドルウェア６２０と情報のやりとりをする。ＯＭＳ−ＡＰＩデータフローにおいて、ミドルウェア６２０は、矢印Ｈで示されるように、ＧＵＩ６０４のＯＭＳ−ＡＰＩ６１８と情報をやりとりする。
【０１０４】
図６ＣはＯＭＳバックエンドシステム６３４におけるミドルウェア６２０を示す。図６Ｃのデータフローは図６Ｂのものとは異なり、ＯＭＳ公開立会いが、ＯＭＳバックエンドファイアウォール６３２の後ろのミドルウェア６２０までしか行かず、またＯＭＳ登録ＡＰＩデータフローが、ファイアウォール６３２、ＶＰＮ６０８或いはインターネット６１０、及び顧客ファイアウォール６２６を介して、ＧＵＩ６０４のＯＭＳ−ＡＰＩ  ６１８まで行く。
【０１０５】
上記では好適実施形態を説明してきたが、本開示を概観した当業者には、他の実施形態が、本発明の範囲から逸脱することなく実現可能なことは、容易に理解できるであろう。例えば、数値は限定ではなく例示であり、また、別々に開示した実施形態を、適切な形で組み合わせることが可能である。更に本発明は、金融商品（株、債券、オプション、先物、通貨など）及び非金融商品の取引を含み、証券の取引を越えて適用できる可能性を持っている。加えて、すでに理解されている通り、本発明は注文品管理装置と共に利用可能であると考えられるが、例えば当業者には周知であろうもので、限定はされないが、現在ある又はこれから開発される可能性があるＥＭＳ（ｅｌｅｃｔｒｏｎｉｃ  ｍａｎａｇｅｍｅｎｔ  ｓｙｓｔｅｍ：電子管理装置）や他の同様のシステムなどの、取引利益及び／又は注文情報を追跡及び／又は管理する他の情報管理装置と共にも利用することができる。したがって、「注文品管理装置」という文言は、限定されない限り、他の同様の装置全てを包含すると解釈されるべきである。よって、本発明は、添付の特許請求の範囲によってのみ限定されるものと解釈されるべきである。
【図１】
2010534892.tif 000018
【図２】
2010534892.tif 000019
【図３】
2010534892.tif 000020
【図４Ａ−１】
2010534892.tif 000021
【図４Ａ−２】
2010534892.tif 000022
【図４Ｂ−１】
2010534892.tif 000023
【図４Ｂ−２】
2010534892.tif 000024
【図４Ｃ−１】
2010534892.tif 000025
【図４Ｃ−２】
2010534892.tif 000026
【図４Ｃ−３】
2010534892.tif 000027
【図５】
2010534892.tif 000028
【図６Ａ】
2010534892.tif 000029
【図６Ｂ】
2010534892.tif 000030
【図６Ｃ】
2010534892.tif 000031
【国際調査報告】
2010534892.tif 000032
2010534892.tif 000033