JP2002526820A - 総合トレーディング・マーケットを設計および展開するシステムのための方法および装置 - Google Patents

Abstract

(57)【要約】 ネットワークを介してアクセス可能なトレーディング・プリミティブ（「ＴＰ」）のセットと、ＴＰのセットを特定のオークション指定を表す一時的プロトコル・スクリプトと組み合わせるためのスクリプト・ジェネレータ（１２１）を含むマーケット指定コンソール（１１０）とを含む、総合オークション指定システム。さらにこのシステムは、各モジュールがＴＰを有することのできる複数のモジュールを有するプログラム可能オークション・サーバ（１４０）を含む。

Description

【発明の詳細な説明】

【０００１】 （関連出願の相互参照） 本出願は、Ｙｏａｖ Ｓｈｏｈａｍ等による「Ａ Ｕｎｉｖｅｒｓａｌ Ｏｎ
−Ｌｉｎｅ Ｔｒａｄｉｎｇ Ｍａｒｋｅｔ Ｄｅｓｉｇｎ Ａｎｄ Ｄｅｐｌ
ｏｙｍｅｎｔ Ｓｙｓｔｅｍ」という名称の１９９８年８月７日付で出願された
同時係属の米国特許出願０９／１３１０４８号の一部継続出願である。

【０００２】 （発明の分野） 本発明は、トレーディング・マーケットを設計および展開するために、ネット
ワーク化されたコンピュータ・システムを使用することに関する。より具体的に
言えば、本発明は、オークション指定のディメンションを表すモジュラー構成要
素周囲に編成されたオークション・エンジンに関する。

【０００３】 （発明の背景） 複雑な計算を必要としない単純なオークションが、現在インターネット上で盛
んに行われている。こうしたオークションの代表的なものが、Ｏｎｓａｌｅ．ｃ
ｏｍ、ｅＢａｙ．ｃｏｍ、およびＰｒｉｃｅｌｉｎｅ．ｃｏｍである。Ｏｎｓａ
ｌｅ，Ｉｎｃ．およびＰｒｉｃｅｌｉｎｅ，Ｉｎｃ．は、自社の特定オークショ
ン規則に特有のカスタマイズされたソフトウェアを使用した。このソフトウェア
は、多様なビジネス状況の中で、簡単に修正または展開されるものではない。

【０００４】 ＯｐｅｎｓｉｔｅおよびＢｏｎｓａｉが提供するソフトウェアで具体化された
ツールキットを使用して単純なオークションを構築し、これを動作させることが
できる。しかし、これらツールキットによるオークションのカスタム化は制限さ
れている。たとえば、マーケット・デザイナはオークションの継続時間を指定す
るか、または簡単なオークション形式を選択することはできるが、オークション
を確立する際の他の変動要素はそれほど簡単に修正できない。ＩＢＭは、ソフト
ウェア・オブジェクトのライブラリからの要素を下位分類することによって、オ
ークションの多少高度なカスタム化を可能にするオークション・ツールキットを
開発したが、これは総合的なマーケットの設計および展開システムではない。さ
らに、このシステムは、単一ユニットのバイヤー専用オークションに限定されて
いる。

【０００５】 Ｍｏａｉ，Ｉｎｃ．（Ｍｏａｉ）は、オークション製品でない製品の典型であ
るソフトウェアを有し、正確に言えばＭｏａｉは、オークション技術を具体化す
るソフトウェア・ソリューションを提供している。Ｍｏａｉは、製造業者または
再販業者が余剰品および過剰在庫品を販売する場合にインターネット・オークシ
ョン・ソリューションを作成するソフトウェアを構築している。Ｍｏａｉのソフ
トウェア・ソリューションは、顧客のニーズに合致するように調整することが可
能であり、オークションのスタイルおよび機構は特定のオークション・タイプに
限定されている。

【０００６】 他のインターネット・サービスであるＭｉｃｈｉｇａｎ Ｉｎｔｅｒｎｅｔ
ＡｕｃｔｉｏｎＢｏｔは、当事者がオークションの作成および管理（たとえば入
札の受け付け、入札者へのオークション結果の通知など）を行えるようにするも
のである。ＡｕｃｔｉｏｎＢｏｔは、他のサービスよりも広範なオークション・
セットをサポートしてはいるが、限界がある。具体的に言えば、Ａｕｃｔｉｏｎ
Ｂｏｔは、ＦＣＣスペクトラム・オークションおよびＣａｌｉｆｏｒｎｉａ Ｐ
ｏｗｅｒ Ｅｘｃｈａｎｇｅなどの工業マーケットで遭遇したそのようなアクテ
ィビティ規則をサポートすることができない。さらに、システムの構成可能度の
範囲を広げるための、モジュラー・アーキテクチャも提供しない。

【０００７】 要するに、インターネット・オークションのマーケット・デザイナには、ソフ
トウェアの開発または限定されたツールキットの使用という２つのオプションが
ある。したがって、冗長なソフトウェア開発に従事することなく、広範囲なイン
ターネット・オークション・マーケットの定義および展開に使用する手段を有す
ることが望ましい。

【０００８】 （発明の概要） インタラクティブでリアルタイムな、総合トレーディング・マーケット・シス
テムをインターネット上で設計および展開するための方法および装置が開示され
る。本発明の一実施態様は、プログラム可能オークション・サーバを有する総合
オークション指定システムに関する。プログラム可能オークション・サーバは、
少なくとも１つのオークション指定モジュールが、入札処理、情報公開、および
精算からなるグループから選択されるオークション変数の少なくとも１つの関数
に対応する、複数のオークション指定モジュールを有する。

【０００９】 本発明の他の態様および方法、ならびにこれらの方法を使用して形成された装
置について、以下の図に関して下記にさらに詳しく記載する。

【００１０】 （好ましい実施形態の詳細な説明） インターネットおよび同様のネットワークを介して通信する、総合的、インタ
ラクティブ、リアルタイムな、トレーディング・マーケット・システム処理トレ
ーダを設計および展開する方法および装置が開示される。オークションなどのト
レーディング・マーケット・システムを特定および展開するこの包括的なシステ
ムは、当分野で知られる限定されたシステムに対して新規である。本発明の一実
施形態は、プログラム可能オークション・サーバ（ＰＡＳ）を有する総合オーク
ション指定システムに関する。プログラム可能オークション・サーバは、複数の
オークション指定モジュールを有し、少なくとも１つのオークション指定モジュ
ールが、入札の処理、オークション情報の公開、およびオークションの精算とい
うオークション関数の少なくとも１つに対応する。

【００１１】 以下の詳細な説明では、本明細書を完全に理解できるように数値を特定した詳
細が記載してある。ただし、当分野の通常の技術者であれば、本発明がこれら特
定の詳細を使用しなくても実施可能であることが明らかであろう。その他の場合
では、本発明を不必要に不明確なものにしないように、よく知られた構造および
デバイスが構成図形式で示されている。

【００１２】 図１Ａ、図１Ｂは、本発明の総合オークション指定システムが、マーケット指
定コンソール（「ＭＳＣ」）１１０、総合トレーディング・コンソール（「ＵＴ
Ｃ」）１２０、総合監視コンソール（「ＵＳＣ」）１３０、マーケット管理コン
ソール（「ＭＡＣ」）１５０、ＰＡＳ １４０、ならびに様々な構成要素をリン
クしている通信ネットワーク１６０および１６１など、多彩な構成要素を含むこ
とができる、本発明の様々な実施形態を示す。これらの構成要素は、単一のコン
ピュータ・システム内、またはネットワークによって接続された複数のコンピュ
ータ・システム内に格納するか、またはその中で動作することができる。

【００１３】 システム・モジュールの概要 ＭＳＣ １１０は、マーケット・デザイナが無数の可能なマーケット・プロト
コルのうちのいずれかを指定することができるコンピュータ・プログラムを走ら
せるコンピュータからなる。その後、マーケット・プロトコルによって定義され
たマーケットが、実行のためにＰＡＳ １４０に提示またはアップロードされる
。マーケットは、マーケット・デザイナによって指定されるいくつかのパラメー
タを使用して、英国またはドイツのオークションと同様に単純なものにすること
ができる。あるいは、マーケット・デザイナが、非常に複雑な計算を使用する自
由裁量オークションを開発することができる。

【００１４】 マーケットを様々な方法で編成することができるが、一般にはフェーズのシー
ケンスからなる。各フェーズには、マーケット・デザイナが指定する相対的に固
定された規則セットによってアクティビティが支配されるインターバルが含まれ
る。マーケットの一時フローは、マーケット・デザイナが指定する一連のマーケ
ット・フェーズからなる。マーケット・デザイナは、この一時フローを指定する
ためにフェーズを識別しなければならない。ＭＳＣ １１０のグラフィカル・ユ
ーザ・インターフェース（ＧＵＩ）上でフェーズの表示を操作することによって
、フェーズが識別され、シーケンス関係（たとえば、終了条件、フェーズ間の条
件付きブランチングなど）が指定される。フェーズは、時間枠、制限、条件（た
とえば停止条件、同時条件、解除条件など）、例外、除外、但し書きなどによっ
て定義することができる。マーケット・デザイナは、フェーズが終了するとき（
たとえば指定された時間枠、最初の１００ビットが受け取られるなどの条件など
）、後続のフェーズ（あれば）を選択する方法、および任意の他の適用可能な制
限などの基準を指定することができる。

【００１５】 特定のフェーズを支配するマーケット規則などの規則を指定するために、マー
ケット・デザイナは、ＰＡＳ １４０内の構成要素の挙動を命令するオプション
を選択し、本明細書ではこのオプションをトレーディング・プリミティブ（「Ｔ
Ｐ」）と呼ぶ。ＭＳＣ １１０はオプションを選択するためのメニューおよび他
の手段を提供し、これらオプションの法的な組み合わせに関するガイダンス、ま
たは指定された設計目標に関連付けられた推奨される選択肢を、マーケット・デ
ザイナに提供することができる。

【００１６】 ＵＴＣ １２０は、トレーダ（たとえば、セラー、バイヤー、セラーまたはバ
イヤーのエージェント）が、ＰＡＳ １４０上で実行中の任意のマーケット・プ
ロトコルでトレーディングできるようにするコンピュータ・プログラムを実行す
るコンピュータからなる。ＵＴＣ １２０は、実行中の特有のマーケット・プロ
トコルに自動的に適合する方法で、トレーダに情報を提示する。

【００１７】 ＵＳＣ １３０は、監理機関または独立監査会社などの監視団体がＰＡＳ １
４０上で実行中のマーケットの動作を監視できるようにするコンピュータ・プロ
グラムを実行するコンピュータからなる。この機能によって、監視団体は、オー
クションの実行が規範に合致しているかどうかを判定し、規範からの逸脱が検出
された場合には任意選択でマーケットに介入することができる。

【００１８】 ＭＡＣ １５０は、ＰＡＳ １４０を収容しＰＡＳの動作を担当するエンティ
ティであるマーケット・オペレータに、ＰＡＳ １４０上で動作している様々な
マーケットの実行を監視させるコンピュータ・プログラムを実行するコンピュー
タからなる。ＭＡＣ １５０は、トレーダが自分自身をシステムに識別させる（
たとえば自分の名前および身分証明書を提供する）プロセスなどの登録トランザ
クションも監理する。さらに、ＭＡＣ １５０は、マーケット・オペレータがリ
アルタイムでシステムのトラブルシューティングを実行できるようにする。

【００１９】 ＰＡＳ １４０は、ＭＳＣ １１０から提示される複数のマーケット・プロト
コルを受け入れ、複数のマーケット・プロトコル（たとえばオークションの開設
、入札の許可または拒否、価格の精算、トレーダへのマーケット・イベントの通
知、およびオークションの打ち切りなど）を実行することができる、コンピュー
タ・プログラムを実行するコンピュータを含む。より具体的に言えば、ＰＡＳ
１４０はいくつかのモジュールを使用してマーケットの動作を制御する。入札検
証器、公開情報マネージャ、および精算器などのモジュールは、入ってくる入札
の処理、照会への応答、マーケット状態の維持（たとえば入札の追跡など）、な
らびにトレーダに、および任意選択でトレーダ以外の人に結果を報告することに
よって、マーケットの監視を支援する。これらのモジュールを介して、入札の検
証（たとえばトレーダからの入札に、規則によって「入札」としての資格を与え
るかなど）、情報の公開（たとえば現在のすべての入札を表示するなど）、精算
（価格または入札の精算）、情報の登録（たとえばトレーダの氏名および電話番
号など）、ならびに入札変換など、さまざまなトランザクションを実行すること
ができる。好ましい実施形態では、様々な構成要素が、図１Ａに示されたような
２つのファイアウォール１６４で境界を区切られた３層のアーキテクチャを介し
て完全なシステムに編成される。

【００２０】 マーケット指定コンソール（ＭＳＣ） ＭＳＣ １１０は、マーケット・デザイナが、直感的な方法でマーケット・プ
ロトコルを決めるために規則全般を使用できるようにするものである。これらの
規則は、マーケット・デザイナが修正することができる。マーケットに参加する
ための規則およびマーケットを動作させるための規則の組み合わせが、マーケッ
ト・プロトコルを構成する。ＭＳＣを介して指定できるマーケット・プロトコル
は、英国式、ドイツ式、および密封入札式のオークションなど、単純なオークシ
ョンから、金融取引所およびＣａｌｉｆｏｒｎｉａ Ｐｏｗｅｒ Ｅｘｃｈａｎ
ｇｅの取引会場で行われるような非常に複雑なオークションまで、広範囲にわた
る。

【００２１】 表１は、ＰＡＳ １４０で展開するためにＭＳＣ １１０を介して指定できる
、一部のオークション・タイプの例を示したものである。以下に示すように、オ
ークション・タイプは階層形式で配列することが可能であり、マーケット・デザ
イナはこれをマーケット指定プロセスの一部として使用する。記載された部分的
階層が、多くの可能な配列の一部に過ぎないことに留意されたい。 表１：オークションの分類例 ┌────────────────────────┐ │ １）単一商品タイプ │ │ ａ）一方向（たとえばバイヤー入札のみ） │ │ ｉ）英国式（価格の競り上げ） │ │ ｉｉ）ドイツ式（価格の競り下げ） │ │ ｉｉｉ）密封入札式 │ │ ｂ）双方向（バイヤーおよびセラーの入札） │ │ ｉ）連続二重オークション │ │ ｉｉ）コール・マーケット │ │ ２）複数商品タイプ │ │ ａ）同時価格競り上げ │ │ ｂ）組み合わせ（抱き合わせ入札） │ └────────────────────────┘

【００２２】 表１は、オークションの複数のクラスを示す。この表には、単一商品用または
複数商品用のオークションが含まれる。単一商品は、一方向または双方向のオー
クションによってオークションにかけることができる。一方向オークション・タ
イプの中には、英国式、ドイツ式、および密封入札式のオークションがある。英
国式オークション（この場合はバイヤーが入札する）は、トレーダＡが商品に入
札するという典型的な方法で行われる。その後トレーダＢは、トレーダＡが提示
した入札値よりも高い入札値をつけることになる。買い側の英国式オークション
では、最高の入札値をつけた入札者が競り勝つ。これに対して買い側のドイツ式
オークションでは、価格は最高レベルから始まり、トレーダが入札を提示するま
で下がっていく。密封入札式オークションでは、トレーダから入札を集め、終わ
りまでこの情報を保留する。精算時間になると、最高の入札値が競り勝つ。

【００２３】 双方向オークションは、オークションの他のクラスである。双方向オークショ
ンでは、バイヤーとセラーの両方が入札を提示する。このクラスの一例が、連続
二重オークションである。連続二重オークションは、バイヤーおよびセラーから
オファーを集める。買いのオファーと売りのオファーが一致すれば、トレードは
完了である。コール・マーケットはこれと同様に行われるが、入札が時間の経過
と共に集計され、定期的に突き合わされるという点が異なる。トレードは、突き
合わされたすべての入札に適合する均一の価格で発生するのが典型的である。

【００２４】 前述のように、複数商品をオークションにかけることができる。これには、単
一の会社、政府機関、または何らかの他のエンティティからオファーのあった複
数の商品が含まれる。同時価格競り上げ式オークションは、異なる商品について
複数のオークションが進行するものである。組み合わせ式（抱き合わせ入札）オ
ークションは、商品Ａ、商品Ｂ、および商品Ｃを抱き合わせたものにトレーダが
入札を提示するというように、商品の組み合わせに対してトレーダが入札するも
のである。

【００２５】 一般に、マーケット・デザイナは、２つの方法のどちらかでマーケットを定義
することができる。１つの方法とは、パラメータ化された形式で事前に定義され
たマーケット・プロトコルを選択し、その空きパラメータの値を入力するという
方法である。たとえば、マーケット・デザイナは、英国式オークションで、最小
増分および開始時間を指定することができる。もう１つの方法は、マーケット・
デザイナが、任意の所与の状況に好適な自由裁量のマーケット・プロトコルを定
義することができるものである。

【００２６】 マーケット・プロトコルの数は無制限であるが、なんらかの総合原理が適用さ
れる。第１に、あらゆるオークションが、参加が許可されたトレーダと呼ばれる
エンティティのセットに関連付けられる。トレーダは入札を提示することでマー
ケットに参加し、これが指定された条件（たとえば入札に記載された価格および
数量）でオークション商品を買うまたは売るためのオファーである。入札の結果
、マーケットの状況に関する何らかの情報がトレーダに公開される。マーケット
・プロトコルに指定された条件の下でオークションが精算され、その結果生じた
取引が決定される。終了条件に合致すると、オークションが打ち切られる。

【００２７】 これらの総合的要素により、オークション・タイプの範囲に渡って適用可能な
マーケット・プロトコルの特徴に関する特定の選択肢を表すＴＰを定義すること
ができる。たとえば、１つのＴＰは、オークションが一方向（たとえばバイヤー
またはセラーの入札）、双方向（バイヤーおよびセラーの入札）、密封入札式、
または「オープン競売」（たとえば入札がすべてのトレーダに公開される）のい
ずれであるかを指定することができる。さらにＴＰは、精算または情報公開など
の重要なイベントが発生しようとしている場合に、これを伝えることもできる。
ＴＰの他の例、およびオークションの挙動を指定するためのその使用方法につい
ては、ＰＡＳ １４０について記述している以下の項で述べる。

【００２８】 オークションの各フェーズは、それが含むＴＰまたはＴＰを適用するためのタ
イムラインを指定することによって決められる。タイムラインを指定する一般的
な方法の１つは、シーケンシングおよび反復のための制御構成、内部オークショ
ン・イベントおよび時刻機構へのアクセス、ならびにＴＰの呼出し機能を有する
スクリプト言語を呼び出すことである。この役割は、特別に設計されたオークシ
ョン・スクリプト言語、ＴＣＬ／ＴＫ、ＪａｖａＳｃｒｉｐｔなどの標準スクリ
プト言語、Ｊａｖａなどの本格的プログラミング言語、任意の他のスクリプト言
語、あるいは任意のプログラミング言語によって記入することができる。本発明
の好ましい実施形態では、スクリプト・ジェネレータ１２１を使用して、一般に
ＣｏｍｍｅｒｃｅＳｃｒｉｐｔと呼ばれる言語でスクリプトを生成する。Ｃｏｍ
ｍｅｒｃｅＳｃｒｉｐｔは、オークション指定を表す一時的なプロトコル・スク
リプトである。

【００２９】 ＣｏｍｍｅｒｃｅＳｃｒｉｐｔの一時的な性質は、マーケット指定に便利さの
追加レベルを与える。本発明では、マーケット・デザイナを逐語的なスクリプテ
ィングだけに制限するのではなく、マーケット・デザイナに視覚的なスクリプテ
ィング・オプションを提示する。この視覚的スクリプティング・オプションを使
用すると、マーケット・デザイナは、タイムラインを図形的に描き、タイムライ
ンに沿って様々なＴＰを配置することができる。各ＴＰには、ＴＰを実行してい
るマーケット・エンティティ、この実行が強制的なものか許容可能なものか、条
件がこのステップより前に発生するか後に発生するか、および合致しなければな
らない一時的な前提条件など、多彩な情報の注釈を付けることができる。視覚的
指定構成要素の出力は、逐語的指定構成要素のそれと同じである。当分野には様
々な視覚的プログラミング・ツールがあるが、このようなツールはトレーディン
グ・マーケット指定の作成には適用されていない。視覚的指定構成要素の注釈の
新しい態様の１つには、商用的な応用例に独特の、「強制的」または「許容可能
」としてステップを処理することが含まれる。

【００３０】 プログラム可能オークション・サーバ（ＰＡＳ） ＰＡＳ １４０は、拡張可能であり柔軟である。ＰＡＳは、Ｃｏｍｍｅｒｃｅ
Ｓｃｒｉｐｔ用のインタープリタ、およびスクリプト内で参照されたＴＰによっ
て命令された挙動を実施するモジュールを含む。原則として、許容可能なマーケ
ット・プロトコルの範囲には、コンピュータ・メモリおよび他のコンピュータ・
リソースに関するＰＡＳ １４０の実際的な制限以外に制限はない。

【００３１】 マーケット・プロトコルは、一定方法での入札または一定形式での情報の取り
出しなどのアクティビティを実行するための、明確なマーケット・エンティティ
の様々な許可と一致する。このような許可は、ＭＡＣ １５０登録プロセスによ
って獲得された、登録済みトレーダおよびオークションの属性に基づくものであ
る。ＰＡＳ １４０の１つの特徴は、実行される特定のマーケット・プロトコル
に関係なく、許可を処理する総称的方法である。プロトコルを実行する各ステッ
プは、マーケット・アクティビティのタイプ、その特定のインスタンシエーショ
ン（すなわち指定された入力の値）、およびそれの実行を試行中のエンティティ
によってゲート制御される。本発明によって提供される柔軟性許容管理は、一般
に、悪意のある侵入者および不適格なマーケット・エンティティに対する防御な
どの、セキュリティ処置を必要とする産業用アプリケーションにおいて重要であ
る。

【００３２】 耐障害性を向上させるために、ＰＡＳ １４０は、入札、他のトレーダ・アク
ション、マーケット精算結果、および他の同様のアクションを含む、システム上
で実行されるあらゆるアクティビティを記録することによって、監査の手がかり
を作成する。さらに、トレード管理モジュールは、トレードおよび各参加者が負
う義務を記録する。たとえば、トレード管理モジュールは、バイヤーであるトレ
ーダＡが、本などの商品に対して１００ドルの入札を提示したことを記録するこ
とができる。この入札は受け取った入札の中で最高の入札を反映するので、セラ
ーＢは自分の本をバイヤーＡに１００ドルで売った。トレード管理モジュールは
、バイヤーＡがセラーＢの本の交換にあたって、セラーＢに対して１００ドルの
支払い義務を負うことを記録する。

【００３３】 ＰＡＳ １４０は、異なるマーケット・プロトコルについて追加またはカスタ
マイズすることができる、いくつかのモジュールからなる。これらのモジュール
については以下で論じるが、マーケット・デザイナによって指定されたＴＰに基
づいてマーケット関数を実施する。ＰＡＳ １４０はスクリプト・インタープリ
タ１４１を使用してマーケット・プロトコルを実行し、アプリケーション・プロ
グラム・インターフェース５１０および代理入札器５０９に拡張可能性および他
のオークション・システム構成要素との接続を提供する。

【００３４】 １．スクリプト・インタープリタ ＰＡＳ １４０は、ＣｏｍｍｅｒｃｅＳｃｒｉｐｔ、他のタイプのスクリプト
、または任意のプログラミング言語を認識し、解釈することができる、総称的な
スクリプト・インタープリタ１４１を使用する。さらにスクリプト・インタープ
リタ１４１を、新しいスクリプト言語に適合するように修正することができる。

【００３５】 ２．入札検証器 入札検証器１５１は、入ってくるそれぞれの入札について、マーケット・デザ
イナによって確立された入札規則との整合性をテストする。「入札」とは、入札
状態を修正できるアクションの表現として定義される。入札には、バイヤーが一
定の価格で商品を購入する意志を示すこと、または以前の入札を撤回することな
ど、多彩なアクションが含まれる。入札を変更すると、新しい入札としての資格
を得る。資格のある入札として検証されると、その入札は注文控え帳宛に許可さ
れるが、そうでない場合入札は拒否される。ＭＳＣ １１０を介してＴＰ内に指
定できる入札規則には、多数の可能な変形がある。以下に提供される入札規則の
例は、例示目的のためにのみ示されたものである。

【００３６】 一実施形態では、入札検証器１５１が、入ってくる入札が基準入札と呼ばれる
入札と比較されるように動作する。この基準入札は、入札規則を適用することに
よって決定された、トレーダ自身の入札、すべての入札、またはなんらかの一覧
（たとえば価格相場）を参照することができる。たとえば、入札規則は、適格な
入札のために、入札が以下の要件を満たしていなければならないことを必要とす
ると想定する。 入札・受理された最高入札＋ｘ ここでｘは２０ドルに等しく、受け取った最高入札は１００ドルと想定され、こ
れはこのオークションに関して一定時間枠で受理された最高の入札である。最高
入札は、基準入札を表す。この例では、基準入札がより高い入札に置き換えられ
る。その後、より高い入札が、基準入札と呼ばれる。入ってくる入札は注文控え
帳に入力されるものであり、少なくとも１２０ドルでなければならない。

【００３７】 入札規則の他の例は、入札に適格なトレーダのタイプを制限することができる
か、または異なるトレーダが提示できる入札を制限できる。入札規則は、入札の
撤回または置換が可能であるかどうかも規定できる。このようなアクションの頻
度または一般に入札の頻度に対して制限を与えることもできる。マーケット・デ
ザイナがオークション全体にわたって適用するか、または指定期間（フェーズ、
ラウンドなど）について適用することで、いかなる入札規則も指定することがで
きる。入札内容に基づいた動的な入札規則も使用することができる。たとえば、
競り上げ（競り下げ）制限は、前述のように、置換入札がなんらかの基準入札を
超えるかまたはこれを超えないものでなければならないことを命じる。これらの
制限は、トレードの片側にのみ適用するか、売り手または買い手の両方に適用す
ることができる。

【００３８】 他の方法では、入札規則が、どのオファーが表現可能であるかを定義するのに
使用できる。たとえば、入札が単一ユニットの商品だけを対象とするか、または
複数のユニットに対して入札できるかを指定することができる。さらに、複数の
ユニットが可能である場合、入札規則は、オファーに単一の価格ポイント、複数
の価格ポイント、または所与の価格での数量のみが含まれるように指定すること
ができる。他の表現性の制限例には、不連続オファー対連続オファー、価格／量
の単調性、可分性（全か無かの入札）、内挿法／外挿法などが含まれる。

【００３９】 表現可能な入札条件を入札規則で使用して、オークションでの入札を制限する
こともできる。たとえば、表現可能な入札条件は、入札の対象となる商品の最低
量、または満たさなければならない最小入札額を含む。多次元オークションの場
合、組み合わせは抱き合わせで許容可能であるとみなすことができる。「ポート
フォリオ」入札も受け入れ可能である。最高に複雑な抱き合わせ制約指定も含め
ることができる。

【００４０】 適格性に関する入札規則も指定することができる。トレーダまたは特定の入札
の適格性は、多様な方法で指定することができる。たとえば、トレーダまたは入
札の適格性は、問題のオークションとは異なるが関連するオークションの履歴を
含む、以前のオークション履歴に関して指定することができる。これは、典型的
には、複雑なオークション・シナリオに共通のアクティビティ規則として参照さ
れる制限の場合である。

【００４１】 入札規則には、参加者がトレーディングに参加できるようにするために支払う
費用などの支払いも含めることができる。たとえば、最初の入札には参加費（返
金可能または返金不可）が必要であるようにしたり、掛かり合いを絶つための違
約金を支払えば撤回できるようにすることができる。前記の内容は、オークショ
ンで使用可能な入札規則の一部を表す。前述のような入札規則を実行することに
よって、「入札状態」が作成される。「入札状態」とは、様々なトレーダからの
入札状況である。入札状況は、当分野で知られている方法で維持される。入札状
態には、様々な入札の履歴データも含めることができる。たとえば、トレーダに
表示されるトレード・インターフェース上で、入札のグラフをトレーダに表示す
ることができる。トレーダは、トレーダ・インターフェースを介して、総合オー
クション・システムから情報を入力し、受け取ることができる。情報は、キーボ
ード、タッチ・スクリーン・ディスプレイ、または音声起動システムを介して、
総合オークション・システムに送信することができる。

【００４２】 ３．入札変換器 入札変換器１５５は、様々な有効価格を生成できる識別割振りマーケット・プ
ロトコルを実施する。識別割振りマーケット・プロトコルは、入札に提示された
トレーダのアイデンティティ（「トレーダ・アイデンティティ」）、トレーダ・
アイデンティティに割り振られた数量、またはマーケット・デザイナが指定する
任意の他の条件に基づくことができる。トレーダ・アイデンティティは、個々の
トレーダまたは確立されたグループ（たとえば認可ディーラ、登録済みクライア
ント、特定の信用等級保持者など）に関連付けることができる。

【００４３】 好ましい実施形態では、提示された各入札が、識別方針を入札に適用する入札
変換器１５５の対象となる。たとえば、トレーダＡなどの特定のトレーダに２０
％割引の資格が与えられた場合、そのオファー価格は、２０％削減が元の入札に
等しくなるような額だけ増分される。したがって、トレーダＡによる１０ドルの
入札は、１２．５０ドルに変換される。次いで、この変換された１２．５０ドル
の入札が、他のトレーダによって受け取られた入札と比較される。

【００４４】 他の例は、一定のしきい値価格より上の、商品の数量に対するオファー価格（
または指定されたタスク量などのサービス）に関する。商品の数量は、割振りを
トレーダの方に偏らせるための「ペナルティ」の割合を査定することができる。
入札変換器１５５によって入札が変換された後、変換済み入札は入札検証器１５
１に送られる。好ましい方法の一代替方法には、精算器１５４を使用した識別割
振り方針の実施が含まれる。この方法では、入札は変換されない。その代わり、
識別割振り方針を実施するために精算計算が修正される。たとえば、識別割振り
方針が、トレーダは割り振られた数量の半分以上を受け取ってはならないと命じ
た場合、精算アルゴリズムは、この規定数量を超えないという制約に従ってその
目標基準を最大限にする。

【００４５】 ４．情報マネージャ 情報マネージャ１５２は、入札進行中、オークションによって参加者に公開さ
れる情報を制御する。実際は、入札状態ならびにオークションが処理できる入札
およびトレーディング履歴に関して、照会クラスに命令する。未処理の照会は空
白応答を生成する。

【００４６】 機構は、能動的手段を介して使用可能な情報と受動的手段を介して使用可能な
手段とを区別することができる。トレーダは、明示的照会を介して、公開された
情報を能動的に要求することができる。情報は、価格相場動作を定義することに
よって、受動的アクセスに公開される。価格相場は、典型的には仮の精算の結果
を指定するが、任意の他の顕著な情報（たとえば受理された最高の買い入札）も
指定することができる、オークション状況概要の特別な形式である。価格相場は
、情報が照会なしで使用できるようになり、明示的照会が複雑な計算を引き起こ
さないように、公開時に計算され、キャッシュに保管される。単一商品オークシ
ョンの場合、価格相場の一形式は、単一価格に集約する「入札要求スプレッド」
である。入札相場は、エージェントが（オークション状態には他の変更はいっさ
い発生しないと想定して）首尾良く売るために売りをオファーしなければならな
い価格、またはそれよりも下の価格を示す。要求相場は、要求相場に関する対応
価格を表す。オークションは、異なる状況でまたは異なるトレーダ・クラスにつ
いて使用される複数の価格相場操作を定義することが可能であって、クラスをト
レーダ・アイデンティティまたは入札状況に関して特徴付けることができる。

【００４７】 マーケット・デザイナは、価格相場の内容およびタイミングならびに処理され
る明示的照会のクラスを指定するＴＰを（ＭＳＣ １１０を介して）選択するこ
とによって、情報マネージャ１５２の挙動を定義する。他のオークション・イベ
ントと同様に、情報公開は、固定スケジュールに従って、あるいはイベント（た
とえば精算、入札、無活動間隔など）ごとに、時間を設定することができる。

【００４８】 情報マネージャ１５２は、注文控え帳１５４に反映されたような入札状態に加
えて、他の関連するオークション状態情報の公開も制御することができる。たと
えば、オークション状態には、トレーダが追加の入札を行う適格性、またはトレ
ーダの予想に影響を及ぼす可能性のある他のマーケット情報が含まれる場合があ
る。

【００４９】 情報マネージャ１５２によって実施される情報公開方針は、オークションの性
質にかなりの影響を与えることがある。さらに、極端な場合は、入札状態情報に
関するすべての情報が、呼び売りオークションの最中に明らかにされることがあ
る。ただし、もう一方の極端な場合である密封入札式オークションが使用される
ときには、他のトレーダの入札に関する情報はいっさい明らかにされない。

【００５０】 ５．注文控え帳／精算器 注文控え帳／精算器１５４（精算器）は、入札履歴およびオークション規則を
基礎として、商品の割振りおよび取引の条件を決定する。典型的に割振りは、オ
ークション参加者間でのトレード・セットに対応する。いったんトレードが決定
されると、結果をトレーダに報告し、任意選択でトレーダ以外にも報告する。精
算器１５４は、所与の状態でオークション規則によって決定された取引を導出す
るために、注文控え帳によって表された入札状態を使用する。さらに、トレード
・マネージャ・モジュールを呼び出して、これらのトレードの通知および実行を
制御することもできる。

【００５１】 精算器１５４は、ＭＳＣで指定された一時的フローＴＰに従って呼び出される
。他のＴＰが、割振りを決定する方法を命じる。割振り方針は、オークション状
態から割振りへの関数を実行するアルゴリズムを命名すること、または可能な割
振り（たとえば入札によって表されたオファーと一致した割振り）の中から選択
するための完全な基準セットを定義することによって、指定することができる。

【００５２】 精算器１５４は、入札に指定されたオファーを値関数を示すものとして解釈す
ること、およびその結果生じる剰余金を最大にすることによって定義できる、一
般クラスの割振り方針を使用することができる。ただし、金銭の振り替えがゼロ
サム操作であるため、通常この最大化は一意ではない。したがって、規則が、ト
レーダ間での剰余金の割振り方法を指定する必要がある。たとえば、単一ユニッ
ト商品の密封入札式オークションでは、最初の価格でのオークションが合計剰余
金を最大にし、次いでできる限り多くをセラーに対して割り振る。２番目の価格
でのオークションは、剰余金の多くをバイヤーに対して割り振る。ｋ−二重オー
クションは、パラメータｋに従って、この剰余金を分数的に分けることができる
。典型的には、バイヤー（またはセラー）間には明確な剰余金を割り振るための
選択肢があるので、これらの規則が明白でない場合もある。剰余金と同等の入札
間で選択するための方法は、入札時間、数量、またはランダム選択などの特徴に
基づくものであってよい。このような基準は、同点決勝規則と呼ばれることが多
い。

【００５３】 精算器１５４は、年代順の優先順位に基づいて取引を決定する、他のタイプの
精算方針を使用することができる。たとえば、連続二重オークション（「ＣＤＡ
」）は、適合するオファーを受け取ると同時にバイヤーとセラーを突き合わせる
。取引に関する情報公開は遅れることがある。これとは対照的に、コール・マー
ケットでは、割振りを決定する前に、時間の経過と共に入札を集計する。コール
・マーケットの精算間隔が短くなると、ＣＤＡの近似値が決定される。

【００５４】 精算器１５４は、同一商品を異なる価格でトレーダに割り振ることができる、
区別的または非均一価格のオークションを使用することができる。たとえば、入
札分支払いオークションでは、一方の側で競り勝ったトレーダは、他の競り勝っ
たトレーダに対する条件とは関係なく、自分が入札した額を厳密に取り引きする
。

【００５５】 本発明は、指定された割振り方針には関係なく、マーケット・デザイナが使用
可能なＴＰを指定できるようにするか、または方針を補うためにまったく新しい
構成要素をＰＡＳ １４０内に組み込めるようにすることで、それぞれを実現す
ることができる。

【００５６】 ６．代理入札器 トレーダによって提示された入札は、直接入札または代理入札によって入力す
ることができる。直接入札の場合、入札者はオークションを選択し、コンピュー
タのキーボードおよびマウス（ＵＴＣ １２０によって提供されたインターフェ
ース）を使用して入札を入力する。代理入札の場合、ユーザは、ＰＡＳ １４０
で実行中の１つまたは複数のオークションで、自分の代わりに入札するスクリプ
トを定義する。代理入札の一部として、トレーダは、スクリプトがトレーダ・コ
ンソールＵＴＣ １２０内で実行するためのもの（たとえば代理入札器５０８）
であるか、またはＰＡＳ １４０に送られてそこで実行されるもの（たとえば代
理入札器５０９）であるかも指定する。

【００５７】 代理入札器５０９は、ＰＡＳ内で実行中の事実を活用するようにさらに最適化
することができる。具体的に言えば、複数のトレーダから代理入札がある場合、
代理入札器５０９は、連続的に増加していく入札を注文控え帳に繰返し提示する
必要なしに、これらの入札間での競り合いを直接解決することが可能である。

【００５８】 ７．アプリケーション・プログラム・インターフェース ＰＡＳ １４０は、置換または追加のモジュールを組み込むためにＰＡＳを拡
張する手段を提供するアプリケーション・プログラム・インターフェース（「Ａ
ＰＩ」）５１０のセットを有する。ＡＰＩの目的は、クローズド・システムをオ
ープン・システムに変えることである。クローズド・システムは、システムを全
体で使用するかまたはクローズド・システムを使用して先行させる必要がある。
オープン・システムでは、構成要素を既存の構成要素と継ぎ目なく統合すること
ができる。たとえば、ＡＰＩは、ＰＡＳ １４０と（１）登録または処理管理用
のレガシー・ソフトウェア、（２）認可エージェンシーの監査または監視機能、
（３）新しい精算アルゴリズムを実施するプログラム、ならびに（４）以下で論
じるＵＴＣ １２０を迂回するトレードを実行するプログラムとを統合すること
ができる。

【００５９】 総合トレーディング・コンソール（ＵＴＣ） ＵＴＣ １２０には、情報の表示および入札の入力という、少なくとも２つの
機能がある。ユーザに表示される情報の例には、ＰＡＳ １４０上でのアクティ
ビティおよび補助情報が含まれる。ＰＡＳ １４０のアクティビティとは、原則
的に、オークションの開始、入札の配置、および価格の精算など、ＰＡＳ １４
０によってログされたイベントである。実際に表示される情報は、異なるマーケ
ット設計を反映して、マーケットによって異なる場合がある。具体的に言えば、
表示される情報の量は異なる場合がある。たとえば、２つの同時に行われる競り
上げ入札式オークションで情報の開示方針が異なり、一方のオークションは、各
ラウンド後に入札者の全リストおよびそのラウンドでの入札などの情報を公開し
、他方のオークションは、入札者特有の情報は供給せずに集計された入札だけを
公開する。補助情報は、トレードの決定に関連するがマーケット・アクティビテ
ィ固有のものではない、任意の情報であってよい。たとえば、エネルギー・マー
ケットおよびその他多くの将来のマーケットでは、天気予報がトレーダにとって
重要な情報となる可能性がある。

【００６０】 異なるタイプのオークション間には、情報の伝播および入札のセットという両
方の形式で、多様性が存在する。好ましい実施形態では、データベース・レイヤ
をＰＡＳ １４０とＵＴＣ １２０との間に導入することによって、この多様性
に対処している。それぞれのオークション・タイプに対して、いくつかの特有の
データベース・スキームを導入しなければならない。ＰＡＳ １４０はデータベ
ースに特有のデータを収納し、そのデータが動的ＨＴＭＬを使用してＵＴＣ １
２０内で自動的に表示される。この設計の特徴は、ＰＡＳ １４０内のデータベ
ース・テーブルは特定オークション用に作成しなければならないが、ＵＴＣ １
２０は修正の必要がないことである。

【００６１】 図２および図３は、いくつかのモジュールが示された、本発明の一実施形態を
示す概略図である。ここでは、動作６００で、入札（たとえば１００ドル）がト
レーダＡによって提示される。入札は、動作６１０で入札検証器１５１に送られ
る。入札検証器１５１は入札を受け取り、マーケット・デザイナが設定したＴＰ
に入札を組み込むことによって、この入札を使用する。動作６１０では、入札検
証器が、入札が受け入れ可能であるかどうかを判定する。入札が、マーケット・
デザイナが確立した受け入れ可能入札に関する最低基準を満たしていれば、入札
は受け入れ可能入札として検証され、動作６４０で注文控え帳／精算器１５４内
に配置される。入札がこれらの最低基準を満たしていない場合、入札は拒否され
、入札が受け入れ不能であることがトレーダＡに通知される。情報マネージャ１
５２は、動作６２５でトレーダＡに拒否を伝送することによって、トレーダＡに
通知する。同様に、代理入札器５０９も入札検証器１５１に入札を提示すること
ができる。この入札は、前述のプロセスと同じプロセスに従って行われる。代理
入札を提示したトレーダは、代理入札が受け入れ可能であるか受け入れ不能であ
るかについて、情報マネージャ１５２を介して通知される。

【００６２】 総合監視コンソール（ＵＳＣ） 専門のトレーディング・マーケットは、一般に、ＳＥＣ、ＦＣＣ、ＦＥＲＣ、
Ｃａｌｉｆｏｒｎｉａ Ｐｕｂｌｉｃ Ｕｔｉｌｉｔｙ Ｃｏｍｍｉｓｓｉｏｎ
（ＣＰＵＣ）、取引内部監視部門、および外部施設監査機関など、１つまたは複
数の監視団体に関連付けられる。監視団体はトレーディング・アクティビティを
監視し、トレーディング・アクティビティが指定された基準を満たしていること
を確認する。監視は、トレーダを法律や規則に従わせるために不可欠である。規
則に従うことで、マーケットの信頼性が向上する。ＵＳＣ １３０は、マーケッ
トから監視機関へ情報を呈示する。ＵＳＣ １３０は、マーケット内でのトレー
ディング方法は提供しないが、トレーダに提供されていないマーケット制御を提
供する。このような制御の例が、ＵＴＣ １２０に表示されトレーディング・ア
クティビティを停止させる同報通信メッセージである。

【００６３】 好ましい実施形態の３層アーキテクチャ 本発明のシステムは、タイプの異なるトレーディング・マーケットの多様なニ
ーズに適合するように設計されている。単一ユーザのパーソナル・コンピュータ
（ＰＣ）から、統合されたクライアント／サーバ・ベースのプラットフォームま
で、広範囲にわたるハードウェア上で動作する本発明のシステムは、少人数のユ
ーザにも、何千人というユーザを抱えるマーケットにも好適である。このシステ
ムは、マーケット要件が成熟し変化するに連れて、増加するユーザ数に対処する
ように現場で修正できるものである。

【００６４】 図４は、本発明の一実施形態を示すデータの流れを示す。マーケット７００は
、オークション７１０を含む。マーケットは複数のフェーズを含むことができる
が、動作７２０ではフェーズを１つだけ示してある。複数のフェーズについては
、当分野で知られる方法によって、１フェーズのオークション指定が他のフェー
ズのオークション指定に置き換えられることを、当分野の技術者であれば理解さ
れよう。トレーダが提示した入札は、動作７３０で入札検証器に送られる。入札
検証器は、この入札が、マーケット・デザイナまたはオークションのアスペクト
を制御できる他の当事者によって指定された、一定の規則を満たしているかどう
かを判定する。その後、動作７４０で、許可された入札が入札変換器に送られる
。この動作では、入札が識別方針を反映するように修正され、特定トレーダまた
は特定商品に対して認められた状況を反映するために、入札に対して増加、減少
、またはその他何らかの修正を行うことができる。動作７５０では、入札が処理
され、受け入れられた入札に規則が適用されて、最良入札が競り勝つ。最良入札
は必ずしも最高入札ではなく、適用される識別割振り方針を反映した入札である
ことに留意されたい。次いで動作７６０で、この入札が注文控え帳に提示される
。この動作では、同点決勝規則が適用可能であり、分類基準が使用可能であって
、マーケット・デザイナによって指定された任意の他の基準が実施可能である。
動作７７０では、入札が精算器に提示され、精算動作が適用される。動作７８０
では、入札がトレード・マネージャに提示されてさらに処理される。情報マネー
ジャは継続的に動作し、動作７９０で連続してトレーダに情報を提供することが
できる。

【００６５】 図５は、３層のアーキテクチャが、他のシステム・アーキテクチャを実施可能
にするスケーラビリティをサポートしている、本発明の一実施形態を示す図であ
る。第１層１１０は、ユーザ１１４とシステムのバックエンド１１６との間にイ
ンターフェースを構成する、フロントエンド・データベース１１２およびＷｅｂ
サーバ１１１で実行するＷｅｂアプリケーションを含む。認可ユーザは、Ｗｅｂ
ブラウザを介してシステムにアクセスすることができる。ＧＵＩは、（ユーザの
選択およびブラウザのバージョンに応じて）Ｊａｖａ Ａｐｐｌｅｔまたは一般
的なＨＴＭＬのいずれかで実行可能である。ＪａｖａおよびＨＴＭＬプログラミ
ング言語は、当分野の通常の技術者にはよく知られている。システムの安全を保
障するために、Ｗｅｂアプリケーションの周囲はＤＭＺ（非武装地帯）内のファ
イアウォール１２２で囲まれており、これによってアプリケーション・サーバ１
２０への侵入はほぼ不可能になっている。アプリケーションの論理が、第２層１
１５を構成する。ミドルウェア１３０環境は、可用性およびスケーラビリティの
高い構成要素ベースである。第３層１３３には、データベース１３６および、マ
ーケット・アドミニストレータのレガシー・システムへのインターフェース１３
８が含まれる。オークション・プロセスの出力はレガシー・システムによってポ
ーリングされるため、レガシー環境の全セキュリティが常時保証される。

【００６６】 したがって、インターネットを介して通信するトレーダに役立つ、総合的、イ
ンタラクティブ、リアルタイムな、トレーディング・マーケット・システムを設
計および展開するための方法および装置が開示される。本発明について、特有の
例示的実施形態を参照しながら説明してきたが、前記請求の範囲に記載された本
発明の広範な精神および範囲を逸脱することなく、これらの実施形態に様々な修
正および拡大を実行できることが、当分野の通常の技術者であれば明らかであろ
う。

【図面の簡単な説明】

【図１Ａ】 好ましい実施形態の構成要素を示すシステムの構造図である。

【図１Ｂ】 システムのプログラム可能オークション・サーバを示す図である。

【図２】 入札の受け入れおよび検証が実行される、本発明の一実施形態の概略図である
。

【図３】 入札の受け入れおよび検証が実行される、本発明の一実施形態の概略図である
。

【図４】 本発明の一実施形態を示す流れ図である。

【図５】 本発明の３層構造の特有の実施形態を示す図である。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ， ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，Ｉ Ｔ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ， ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，Ｋ Ｅ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＵＧ，ＺＷ)，Ｅ Ａ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ， ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，Ｇ Ｅ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ， ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，Ｍ Ｎ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ， ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ，ＹＵ，Ｚ Ａ，ＺＷ (72)発明者 エフラティ，イーサン アメリカ合衆国・94087・カリフォルニア 州・サニーベイル・テナカ プレイス・ 1575・アパートメント シイ−３

Claims (21)

【特許請求の範囲】
1. 【請求項１】 プログラム可能オークション・サーバを備えた総合オークシ
   ョン・システムであって、プログラム可能オークション・サーバは、 少なくとも１つのオークション・モジュールが、入札検証器、情報マネージャ
   、精算器、登録マネージャ、および代理入札器からなるグループから選択された
   オークションの少なくとも１つの関数に対応する複数のオークション・モジュー
   ルを含む、総合オークション・システム。
2. 【請求項２】 少なくとも１つのオークション指定モジュールが、入札検証
   トランザクション、情報管理トランザクション、精算トランザクション、および
   登録トランザクションを含むグループから選択された少なくとも１つのトランザ
   クションを実行するオークション・モジュールをさらに含む請求項１に記載のプ
   ログラム可能オークション・サーバ。
3. 【請求項３】 トレーディング・プリミティブ・セットと、 トレーディング・プリミティブ・セットの少なくとも一部の参照を含みオーク
   ション指定を表す一時的プロトコル・スクリプトを解釈するための、スクリプト
   ・インタープリタと、 １つのフェーズのオークション指定を他のフェーズのオークション指定に切り
   換えるための手段とをさらに含む請求項１に記載のプログラム可能オークション
   ・サーバ。
4. 【請求項４】 １つのフェーズの少なくとも１つのオークション・モジュー
   ルが、他のフェーズの少なくとも１つのオークション・モジュールに置き換えら
   れる請求項３に記載のプログラム可能オークション・サーバ。
5. 【請求項５】 少なくとも１つのフェーズが少なくとも１つのトランザクシ
   ョンが発生するインターバルを含み、前記トランザクションが、入札の提示、入
   札の許可、入札の撤回、および入札の置換を含むグループから選択される請求項
   １に記載のプログラム可能オークション・サーバ。
6. 【請求項６】 前記フェーズが条件によって終了する請求項５に記載のプロ
   グラム可能オークション・サーバ。
7. 【請求項７】 前記条件が時間枠である請求項６に記載のプログラム可能オ
   ークション・サーバ。
8. 【請求項８】 トレーディング・プリミティブと、 トレーディング・プリミティブを一時的プロトコル・スクリプトに変換するた
   めのスクリプト・ジェネレータと、 スクリプト・プロトコルを解釈するためのスクリプト・インタープリタと、 複数のマーケット・プロトコルをサポートするように適合されたマーケット指
   定コンソールとを含む、総合オークション・システム。
9. 【請求項９】 前記マーケット指定コンソールが、少なくとも１つの規則が
   ユーザによって修正可能である複数の規則を含む請求項８に記載の総合オークシ
   ョン・システム。
10. 【請求項１０】 規則がマーケット・プロトコルを含む請求項９に記載の総
    合オークション・システム。
11. 【請求項１１】 前記マーケット指定コンソールがプログラム可能オークシ
    ョン・サーバに結合され、前記プログラム可能オークション・サーバが、前記マ
    ーケット指定コンソールからマーケット・プロトコルを受け取るように適合され
    、前記マーケット指定コンソールがグラフィック・ユーザ・インターフェース（
    ＧＵＩ）を有する請求項８に記載の総合オークション・システム。
12. 【請求項１２】 トレーダ・インターフェースがネットワークに結合される
    請求項１１に記載の総合オークション・システム。
13. 【請求項１３】 前記トレーダ・インターフェースが入札を提示するために
    トレーダによって使用される請求項１２に記載の総合オークション・システム。
14. 【請求項１４】 複数のマーケット・プロトコルを指定する手段と、 少なくとも１つのマーケット・プロトコルを表示する手段と、 少なくとも１つのマーケット・プロトコルをプログラム可能オークション・サ
    ーバに伝送する手段とを含む、マーケット指定コンソール。
15. 【請求項１５】 少なくとも１つのオークション・モジュールが、入札検証
    器、情報マネージャ、精算器、および登録マネージャからなるグループから選択
    されたオークションの少なくとも１つの関数に対応する、複数のオークション・
    モジュールを生成するステップと、 トランザクションが少なくとも１つの規則を含む、複数の規則を指定するステ
    ップと、 入札検証、情報伝播、精算、および情報登録を含む少なくとも１つのトランザ
    クションを実施するステップと を含む、総合オークション・システムを設計する方法。
16. 【請求項１６】 マーケット・デザイナに規則を表示するステップをさらに
    含む請求項１５に記載の方法。
17. 【請求項１７】 少なくとも１つの規則を修正するステップをさらに含む請
    求項１５に記載の方法。
18. 【請求項１８】 スクリプト化された規則を解釈するステップをさらに含む
    請求項１５に記載の方法。
19. 【請求項１９】 スクリプト化された規則を生成するステップをさらに含む
    請求項１５に記載の方法。
20. 【請求項２０】 規則をプログラム可能オークション・サーバに伝送するス
    テップをさらに含む請求項１５に記載の方法。
21. 【請求項２１】 入札の状況を維持するステップをさらに含む請求項１５に
    記載の方法。