(57)【特許請求の範囲】
【請求項１】
先物取引および／またはオプション取引をネットワークを介して行う際の必要証拠金の計算を含む処理を実行するコンピュータにより構成された必要証拠金計算システムであって、
顧客が操作する顧客端末装置から前記ネットワークを介して送信されてくる先物取引および／またはオプション取引についての顧客の注文データを受け付ける処理を実行する注文受付手段と、
先物取引および／またはオプション取引について成立した注文に係る顧客の建玉データを、顧客を識別するための顧客識別情報と関連付けて記憶する建玉データベースと、
先物取引および／またはオプション取引についての未成立の注文に係る顧客の建玉データを、前記顧客識別情報と関連付けて記憶する未成立注文データベースと、
先物取引および／またはオプション取引についての建玉を維持するために顧客により差し入れられた証拠金の残高を、前記顧客識別情報と関連付けて記憶する証拠金データベースと、
ＳＰＡＮ（登録商標）を用いた証拠金計算処理を実行するＳＰＡＮ証拠金計算手段と、
前記注文受付手段により顧客の前記注文データを受け付けた際に、当該顧客の顧客識別情報と関連付けられて前記建玉データベースに記憶された当該顧客の成立済みの建玉データにより成立済み建玉群を生成し、この成立済み建玉群を前記ＳＰＡＮ証拠金計算手段に入力し、前記ＳＰＡＮ証拠金計算手段から計算結果として出力された仮の必要証拠金の額を受け取り、受け取った仮の必要証拠金の額を、成立済み建玉群計算額として計算額記憶手段に記憶させる処理を実行する成立済み建玉群計算手段と、
前記注文受付手段により顧客の前記注文データを受け付けた際に、当該顧客の顧客識別情報と関連付けられて前記建玉データベースに記憶された当該顧客の成立済みの建玉データ、当該顧客の顧客識別情報と関連付けられて前記未成立注文データベースに記憶された当該顧客の未成立の建玉データのうちの先物および／またはオプションの原資産価値が上昇した場合に価値が上昇するブルポジションの建玉データ、並びに、前記注文データがブルポジションの建玉データであった場合の当該建玉データによりブル建玉群を生成し、このブル建玉群を前記ＳＰＡＮ証拠金計算手段に入力し、前記ＳＰＡＮ証拠金計算手段から計算結果として出力された仮の必要証拠金の額を受け取り、受け取った仮の必要証拠金の額をブル建玉群計算額として前記計算額記憶手段に記憶させる処理を実行するブル建玉群計算手段と、
前記注文受付手段により顧客の前記注文データを受け付けた際に、当該顧客の顧客識別情報と関連付けられて前記建玉データベースに記憶された当該顧客の成立済みの建玉データ、当該顧客の顧客識別情報と関連付けられて前記未成立注文データベースに記憶された当該顧客の未成立の建玉データのうちの先物および／またはオプションの原資産価値が下降した場合に価値が上昇するベアポジションの建玉データ、並びに、前記注文データがベアポジションの建玉データであった場合の当該建玉データによりベア建玉群を生成し、このベア建玉群を前記ＳＰＡＮ証拠金計算手段に入力し、前記ＳＰＡＮ証拠金計算手段から計算結果として出力された仮の必要証拠金の額を受け取り、受け取った仮の必要証拠金の額をベア建玉群計算額として前記計算額記憶手段に記憶させる処理を実行するベア建玉群計算手段と、
前記計算額記憶手段に記憶された前記成立済み建玉群計算額、前記ブル建玉群計算額、および前記ベア建玉群計算額の３つの計算額のうちの最も大きい金額を必要証拠金として採用し、注文を行った顧客の顧客識別情報と関連付けられて前記証拠金データベースに記憶された当該顧客の証拠金の残高と、採用した前記必要証拠金とを比較し、当該顧客について証拠金が足りているか否かの判断により注文に係る取引の許否を判断する処理を実行する取引許否判断手段と、
この取引許否判断手段により取引を許可しないと判断した場合に、取引を許可しない旨および／または証拠金が不足する旨の通知情報を、前記ネットワークを介して前記顧客端末装置へ送信する処理を実行する通知手段と
を備えたことを特徴とする必要証拠金計算システム。
【請求項２】
前記取引許否判断手段により前記３つの計算額のうちのいずれが必要証拠金として採用されたのかを示す採用情報を、前記顧客識別情報と関連付けて記憶する採用情報記憶手段と、
前記注文受付手段により顧客の前記注文データを受け付けた際に、前記採用情報記憶手段に記憶された当該顧客の前回採用に係る前記採用情報を取得し、前記注文データがブルポジションの建玉データであり、かつ、取得した前記採用情報が前記ブル建玉群計算額を採用したことを示す情報であった場合には、前記成立済み建玉群計算手段、前記ブル建玉群計算手段、および前記ベア建玉群計算手段の３つの計算手段のうち、前記ブル建玉群計算手段のみに計算処理の実行指令を送り、前記注文データがベアポジションの建玉データであり、かつ、取得した前記採用情報が前記ベア建玉群計算額を採用したことを示す情報であった場合には、前記３つの計算手段のうち、前記ベア建玉群計算手段のみに計算処理の実行指令を送り、その他の場合には、前記３つの計算手段の全てに計算処理の実行指令を送る処理を実行する採用情報参照手段とを備え、
前記取引許否判断手段は、
前記採用情報参照手段により前記ブル建玉群計算手段のみに計算処理の実行指令が送られた場合には、前記計算額記憶手段に記憶された前記ブル建玉群計算額を必要証拠金として採用し、前記採用情報参照手段により前記ベア建玉群計算手段のみに計算処理の実行指令が送られた場合には、前記計算額記憶手段に記憶された前記ベア建玉群計算額を必要証拠金として採用する処理を実行するとともに、前記３つの計算額のうちのいずれかを必要証拠金として採用したときに、そのときの採用に係る前記採用情報を、注文を行った顧客の顧客識別情報と関連付けて前記採用情報記憶手段に記憶させる処理を実行する構成とされている
ことを特徴とする請求項１に記載の必要証拠金計算システム。
【請求項３】
請求項１または２に記載の必要証拠金計算システムとして、コンピュータを機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、先物取引および／またはオプション取引をネットワークを介して行う際の必要証拠金の計算を含む処理を実行するコンピュータにより構成された必要証拠金計算システムおよびプログラムに係り、例えば、インターネットを含むネットワークを介して株価指数先物取引や株価指数オプション取引の注文があった際に、取引の許否判断のために必要証拠金の計算処理を行う場合等に利用できる。
【背景技術】
【０００２】
一般に、証券会社等の金融機関が提供するインターネット取引システムを用いて株価指数先物取引や株価指数オプション取引等の先物・オプションの売買取引を行う場合には、証券会社等で採用している前受制と呼ばれる制度があり、証券会社等は、顧客（投資家）から先物取引やオプション取引の注文を受けた際に、当該取引を行うことで成立する建玉を維持するために必要な証拠金がその顧客（投資家）により差し入れられているかをチェックし、証拠金が足りている場合にのみ取引を許可している。
【０００３】
このような先物取引やオプション取引の証拠金が足りているか否かのチェックには、通常、ＳＰＡＮ（登録商標）証拠金計算というブラックボックス化された計算方式を利用する。ここで、ＳＰＡＮ（スパン；Standard Portfolio Analysis of Risk）とは、シカゴ・マーカンタイル取引所が１９８８年に開発したリスクベースの証拠金計算方法およびシステムであり、現在、世界の主要先物・オプション取引所・清算機関で採用されている（非特許文献１参照）。
【０００４】
一般に、先物取引やオプション取引の証拠金については、顧客が証券会社等（清算参加者）に差し入れる証拠金と、証券会社等（清算参加者）が株式会社日本証券クリアリング機構に預託する証拠金とがあり（非特許文献２参照）、本発明では、専ら前者の場合の証拠金の計算を取り扱う。
【０００５】
後者の場合の証券会社等（清算参加者）が株式会社日本証券クリアリング機構に預託する証拠金については、証券会社等が抱えている全ての顧客の建玉（ポートフォリオ）を勘案して計算されるが、この計算は、ＳＰＡＮで行わなければならない。これに対し、本発明で取り扱う前者の場合の証拠金（顧客が証券会社等に差し入れる証拠金）は、必ずしもＳＰＡＮそのもので計算する必要はないが、後者の場合の証拠金の計算がＳＰＡＮで行われることを考えれば、前者の場合の証拠金の計算も、ＳＰＡＮの考え方に沿った計算方法で行うことが好ましいため、通常はＳＰＡＮが用いられている。
【０００６】
なお、ＳＰＡＮ証拠金計算に関する周辺技術としては、例えば、取引所で取引される複数の商品のポートフォリオに基づいて当初証拠金所要額を計算し、その証拠金所要額を満たすための担保として少なくとも１つの資産を受け取り、受け取った少なくとも１つの資産をポートフォリオ内の複数の商品のうちの少なくとも１つと相関付け、その相関に基づいて証拠金所要額を調整するシステムが知られている（特許文献１参照）。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特表２００８−５１２７７８号公報
【非特許文献】
【０００８】
【非特許文献１】株式会社日本証券クリアリング機構、“ＳＰＡＮとは”、［online］、株式会社日本証券クリアリング機構ホームページ、［平成２７年１月８日検索］、インターネット＜ＵＲＬ：http://www.jscc.co.jp/seisan/sakimono/shokokin_seido/span.html＞
【非特許文献２】株式会社日本証券クリアリング機構、“証拠金とは”、［online］、株式会社日本証券クリアリング機構ホームページ、［平成２７年１月８日検索］、インターネット＜ＵＲＬ：http://www.jscc.co.jp/seisan/sakimono/shokokin_seido/shokokin.html＞
【発明の概要】
【発明が解決しようとする課題】
【０００９】
前述したように、顧客（投資家）が証券会社等に差し入れる証拠金の計算については、通常、ＳＰＡＮ証拠金計算を実行するＳＰＡＮ証拠金計算手段に対し、当該顧客の保有している建玉（ポートフォリオ）を読み込ませて計算させ、得られたＳＰＡＮ証拠金計算手段の出力を必要証拠金の額とする処理が行われている。
【００１０】
このＳＰＡＮ証拠金計算の大きな特徴として、必要証拠金の相殺という考え方がある。つまり、原資産価値が上昇した場合に価値が上昇する建玉（ブルポジション）と、原資産価値が下降した場合に価値が上昇する建玉（ベアポジション）とが、顧客のポートフォリオに同時に同じ数量に相当する分だけ含まれていた場合、その顧客の必要証拠金はゼロになる。
【００１１】
このような相殺を行う場合、既に成立している建玉であれば、特に問題は生じないが、未だ成立していない建玉（マーケットでは未約定で注文中の状態となっているもの）が顧客のポートフォリオに存在する場合には、その取り扱いが問題となる。この注文中の建玉を全て成立済みの建玉であるものと仮定してＳＰＡＮ証拠金計算をした場合であって、かつ、この注文中の建玉が必要証拠金を減算する要素となった場合には、まだ未成立の状態なので、そのような減算は行ってはいけないこととなる。一方、注文中の建玉が必要証拠金を加算する要素となる場合には、未成立の状態であっても、加算する必要がある。なぜなら、必要証拠金は、未約定の注文も含めて今後想定可能な最大の必要額を考慮する必要があるからである。
【００１２】
従って、仮に、未成立の建玉がＮ個あるとし、それぞれの注文が最終的に成立または未成立となる場合を考慮すると、２のＮ乗個の組み合わせができるので、それらの組み合わせを反映させた２のＮ乗個の仮のポートフォリオ（建玉群）を用意し、それらの仮のポートフォリオの各々についてＳＰＡＮ証拠金計算を行って必要証拠金の額を仮算出し、得られた２のＮ乗個の仮の必要証拠金の額のうちの最大値を採用し、必要証拠金を求める必要がある。このような計算処理を行わない場合には、実際に成立した注文のパターンによっては、証拠金不足が発生するおそれがある。このため、未成立の建玉の個数が多い場合には、処理時間が長くなるので、インターネット取引のようなスピードが要求される場合の処理としては、好ましくない状況になる場合もあり得る。
【００１３】
一方、前述したように、顧客が証券会社等（清算参加者）に差し入れる証拠金については、必ずしもＳＰＡＮそのものを用いて計算する必要はないので、ＳＰＡＮ証拠金計算の計算式を変更し、未成立の建玉を考慮した内容を組み込む方式をとることも考えられるが、ＳＰＡＮ証拠金計算の計算式は、取引所（または株式会社日本証券クリアリング機構）からパッケージとして提示されている計算方式であるため、それを変更することはリスクが高いうえ、市場の要件等によりパッケージ自体の仕様に変更があった場合には、その仕様変更に対応させて更なる内容変更を行う必要が生じる可能性がある。
【００１４】
本発明の目的は、処理速度の向上および一定化を図ることができるとともに、リスクを軽減でき、ＳＰＡＮ証拠金計算のパッケージ自体の仕様に変更があった場合にも容易に対応が可能な必要証拠金計算システムおよびプログラムを提供するところにある。
【課題を解決するための手段】
【００１５】
本発明は、先物取引および／またはオプション取引をネットワークを介して行う際の必要証拠金の計算を含む処理を実行するコンピュータにより構成された必要証拠金計算システムであって、
顧客が操作する顧客端末装置からネットワークを介して送信されてくる先物取引および／またはオプション取引についての顧客の注文データを受け付ける処理を実行する注文受付手段と、
先物取引および／またはオプション取引について成立した注文に係る顧客の建玉データを、顧客を識別するための顧客識別情報と関連付けて記憶する建玉データベースと、
先物取引および／またはオプション取引についての未成立の注文に係る顧客の建玉データを、顧客識別情報と関連付けて記憶する未成立注文データベースと、
先物取引および／またはオプション取引についての建玉を維持するために顧客により差し入れられた証拠金の残高を、顧客識別情報と関連付けて記憶する証拠金データベースと、
ＳＰＡＮ（登録商標）を用いた証拠金計算処理を実行するＳＰＡＮ証拠金計算手段と、
注文受付手段により顧客の注文データを受け付けた際に、当該顧客の顧客識別情報と関連付けられて建玉データベースに記憶された当該顧客の成立済みの建玉データにより成立済み建玉群を生成し、この成立済み建玉群をＳＰＡＮ証拠金計算手段に入力し、ＳＰＡＮ証拠金計算手段から計算結果として出力された仮の必要証拠金の額を受け取り、受け取った仮の必要証拠金の額を、成立済み建玉群計算額として計算額記憶手段に記憶させる処理を実行する成立済み建玉群計算手段と、
注文受付手段により顧客の注文データを受け付けた際に、当該顧客の顧客識別情報と関連付けられて建玉データベースに記憶された当該顧客の成立済みの建玉データ、当該顧客の顧客識別情報と関連付けられて未成立注文データベースに記憶された当該顧客の未成立の建玉データのうちの先物および／またはオプションの原資産価値が上昇した場合に価値が上昇するブルポジションの建玉データ、並びに、注文データがブルポジションの建玉データであった場合の当該建玉データによりブル建玉群を生成し、このブル建玉群をＳＰＡＮ証拠金計算手段に入力し、ＳＰＡＮ証拠金計算手段から計算結果として出力された仮の必要証拠金の額を受け取り、受け取った仮の必要証拠金の額をブル建玉群計算額として計算額記憶手段に記憶させる処理を実行するブル建玉群計算手段と、
注文受付手段により顧客の注文データを受け付けた際に、当該顧客の顧客識別情報と関連付けられて建玉データベースに記憶された当該顧客の成立済みの建玉データ、当該顧客の顧客識別情報と関連付けられて未成立注文データベースに記憶された当該顧客の未成立の建玉データのうちの先物および／またはオプションの原資産価値が下降した場合に価値が上昇するベアポジションの建玉データ、並びに、注文データがベアポジションの建玉データであった場合の当該建玉データによりベア建玉群を生成し、このベア建玉群をＳＰＡＮ証拠金計算手段に入力し、ＳＰＡＮ証拠金計算手段から計算結果として出力された仮の必要証拠金の額を受け取り、受け取った仮の必要証拠金の額をベア建玉群計算額として計算額記憶手段に記憶させる処理を実行するベア建玉群計算手段と、
計算額記憶手段に記憶された成立済み建玉群計算額、ブル建玉群計算額、およびベア建玉群計算額の３つの計算額のうちの最も大きい金額を必要証拠金として採用し、注文を行った顧客の顧客識別情報と関連付けられて証拠金データベースに記憶された当該顧客の証拠金の残高と、採用した必要証拠金とを比較し、当該顧客について証拠金が足りているか否かの判断により注文に係る取引の許否を判断する処理を実行する取引許否判断手段と、
この取引許否判断手段により取引を許可しないと判断した場合に、取引を許可しない旨および／または証拠金が不足する旨の通知情報を、ネットワークを介して顧客端末装置へ送信する処理を実行する通知手段と
を備えたことを特徴とするものである。
【００１６】
このような本発明の必要証拠金計算システムにおいては、顧客のポートフォリオ内の建玉の個数がどんなに多くとも、ＳＰＡＮ証拠金計算手段によるＳＰＡＮ証拠金計算式によるデータ処理を３回行えば、必要証拠金を計算することが可能となる。従って、例えば、仮に、未成立の建玉がＮ個あるとしたときに２のＮ乗回のデータ処理を行う場合に比べ、処理時間を短縮し、処理速度の向上を図ることが可能となり、また、未成立の建玉の個数の変動に伴う処理時間の変動を回避し、処理速度の一定化を図ることも可能となる。このため、インターネット取引のようなスピードが要求される場合においても、一定の性能要件を満たすことができるようになる。
【００１７】
また、ＳＰＡＮ証拠金計算手段は、ＳＰＡＮ証拠金計算式をブラックボックス化されたまま利用する構成とされているので、ＳＰＡＮ証拠金計算式を変更して使用する場合に比べ、証券会社等に発生するリスクを抑えることが可能となる。さらに、ＳＰＡＮ証拠金計算式をブラックボックス化されたまま利用するので、ＳＰＡＮ証拠金計算のパッケージ自体の仕様に変更があった場合でも、パッケージを入れ替えることで容易に対応することが可能となり、これらにより前記目的が達成される。
【００１８】
また、上述した必要証拠金計算システムにおいて、次のような構成としてもよい。すなわち、上述した必要証拠金計算システムにおいて、
取引許否判断手段により３つの計算額のうちのいずれが必要証拠金として採用されたのかを示す採用情報を、顧客識別情報と関連付けて記憶する採用情報記憶手段と、
注文受付手段により顧客の注文データを受け付けた際に、採用情報記憶手段に記憶された当該顧客の前回採用に係る採用情報を取得し、注文データがブルポジションの建玉データであり、かつ、取得した採用情報がブル建玉群計算額を採用したことを示す情報であった場合には、成立済み建玉群計算手段、ブル建玉群計算手段、およびベア建玉群計算手段の３つの計算手段のうち、ブル建玉群計算手段のみに計算処理の実行指令を送り、注文データがベアポジションの建玉データであり、かつ、取得した採用情報がベア建玉群計算額を採用したことを示す情報であった場合には、３つの計算手段のうち、ベア建玉群計算手段のみに計算処理の実行指令を送り、その他の場合には、３つの計算手段の全てに計算処理の実行指令を送る処理を実行する採用情報参照手段とを備え、
取引許否判断手段は、
採用情報参照手段によりブル建玉群計算手段のみに計算処理の実行指令が送られた場合には、計算額記憶手段に記憶されたブル建玉群計算額を必要証拠金として採用し、採用情報参照手段によりベア建玉群計算手段のみに計算処理の実行指令が送られた場合には、計算額記憶手段に記憶されたベア建玉群計算額を必要証拠金として採用する処理を実行するとともに、３つの計算額のうちのいずれかを必要証拠金として採用したときに、そのときの採用に係る採用情報を、注文を行った顧客の顧客識別情報と関連付けて採用情報記憶手段に記憶させる処理を実行する構成としてもよい。
【００１９】
このように３つの計算額のうちのいずれが必要証拠金として採用されたのかを示す採用情報を記憶しておき、注文を受けたときに、前回の採用情報を利用し、一定の条件を満たせば３回ではなく１回の計算処理で済ませる構成とした場合には、成立済み建玉群計算手段、ブル建玉群計算手段、およびベア建玉群計算手段の３つの計算手段のうちの２つの計算手段によるデータ処理を省略することが可能となる。
【００２０】
さらに、本発明のプログラムは、以上に述べた必要証拠金計算システムとして、コンピュータを機能させるためのものである。
【００２１】
なお、上記のプログラムまたはその一部は、例えば、光磁気ディスク（ＭＯ）、コンパクトディスク（ＣＤ）を利用した読出し専用メモリ（ＣＤ−ＲＯＭ）、ＣＤレコーダブル（ＣＤ−Ｒ）、ＣＤリライタブル（ＣＤ−ＲＷ）、デジタル・バーサタイル・ディスク（ＤＶＤ）を利用した読出し専用メモリ（ＤＶＤ−ＲＯＭ）、ＤＶＤを利用したランダム・アクセス・メモリ（ＤＶＤ−ＲＡＭ）、フレキシブルディスク（ＦＤ）、磁気テープ、ハードディスク、読出し専用メモリ（ＲＯＭ）、電気的消去および書換可能な読出し専用メモリ（ＥＥＰＲＯＭ）、フラッシュ・メモリ、ランダム・アクセス・メモリ（ＲＡＭ）等の記録媒体に記録して保存や流通等させることが可能であるとともに、例えば、ローカル・エリア・ネットワーク（ＬＡＮ）、メトロポリタン・エリア・ネットワーク（ＭＡＮ）、ワイド・エリア・ネットワーク（ＷＡＮ）、インターネット、イントラネット、エクストラネット等の有線ネットワーク、あるいは無線通信ネットワーク、さらにはこれらの組合せ等の伝送媒体を用いて伝送することが可能であり、また、搬送波に載せて搬送することも可能である。さらに、上記のプログラムは、他のプログラムの一部分であってもよく、あるいは別個のプログラムと共に記録媒体に記録されていてもよい。
【発明の効果】
【００２２】
以上に述べたように本発明によれば、顧客のポートフォリオ内の建玉の個数がどんなに多くともＳＰＡＮ証拠金計算式によるデータ処理を３回行えば必要証拠金を計算することができるので、処理速度の向上および一定化を図ることができるとともに、ＳＰＡＮ証拠金計算式を変更することなく、ブラックボックス化されたまま利用するので、リスクを軽減でき、ＳＰＡＮ証拠金計算のパッケージ自体の仕様に変更があった場合にも容易に対応できるという効果がある。
【図面の簡単な説明】
【００２３】
【図１】本発明の一実施形態の証拠金計算システムを含む先物・オプションの売買取引システムの全体構成図。
【図２】前記実施形態の証拠金計算システムによる処理の流れを示すフローチャートの図。
【図３】前記実施形態の証拠金計算における相殺の説明図。
【発明を実施するための形態】
【００２４】
以下に本発明の一実施形態について図面を参照して説明する。図１には、本実施形態の証拠金計算システムを含む先物・オプションの売買取引システム１０の全体構成が示されている。図２には、売買取引システム１０による注文受付時の証拠金計算に関する処理の流れがフローチャートで示されている。図３は、証拠金計算における相殺の説明図である。
【００２５】
図１において、売買取引システム１０は、先物・オプションの売買取引に関する各種処理を実行するとともに各種処理に必要なデータを記憶する売買取引サーバ２０と、この売買取引サーバ２０にネットワーク１を介して接続された複数の顧客端末装置４０と、売買取引サーバ２０に通信回線２を介して接続された市場システム５０とを備えている。
【００２６】
ここで、ネットワーク１は、主としてインターネットであるが、ＬＡＮ、ＭＡＮ、ＷＡＮ、イントラネット、エクストラネット、あるいはこれらとインターネットとの組み合わせ等でもよく、有線であるか無線であるか、さらには有線および無線の混在型であるかは問わず、要するに、複数地点（距離の長短は問わない。）間で、ある程度の速度をもって情報を伝送することができるものであればよい。また、通信回線２は、主として専用線であるが、ネットワークでもよい。
【００２７】
売買取引サーバ２０は、証券会社等の金融機関が管理する１台または複数台のコンピュータにより構成され、注文受付手段２１と、ＳＰＡＮ証拠金計算手段２２と、必要証拠金計算手段２３と、取引許否判断手段２４と、通知手段２５と、発注手段２６と、約定手段２７と、建玉データベース３０と、未成立注文データベース３１と、証拠金データベース３２と、注文データ記憶手段３３と、計算額記憶手段３４とを含んで構成されている。
【００２８】
注文受付手段２１は、顧客端末装置４０からの注文画面の送信要求に応じ、ネットワーク１を介して注文画面の表示用データを送信し、顧客端末装置４０からネットワーク１を介して送信されてくる先物取引やオプション取引についての顧客の注文データを受信し、受信した注文データを、注文に付与した注文識別情報（注文コード等）および注文を行った顧客の顧客識別情報（顧客コード等）と関連付けて注文データ記憶手段３３に記憶させる処理を実行するものである。
【００２９】
ここで、注文データは、例えば、日経２２５やＴＯＰＩＸ等の株価指数を取引対象（原資産）とする株価指数先物取引や株価指数オプション取引等の注文データであり、より具体的には、日経２２５先物、日経２２５ｍｉｎｉ先物、日経３００先物、ＴＯＰＩＸ先物、日経２２５オプション、ＴＯＰＩＸオプション等の注文データである。なお、本発明における先物取引やオプション取引は、株価指数を原資産とする取引に限定されるものではなく、例えば、商品、株式、債券、金利など、様々な商品（原資産）を対象とした取引が含まれ、要するに、現在または将来においてＳＰＡＮ証拠金計算の対象となっているか、または対象となり得る取引であればよい。
【００３０】
先物取引の場合の注文データには、銘柄識別情報（商品（原資産）、限月）、売買区分、数量（枚数）、成行・指値等の執行条件、指値などが含まれ、オプション取引の場合の注文データには、銘柄識別情報（商品（原資産）、限月、コール・プットの別、権利行使価格）、売買区分、数量（枚数）、成行・指値等の執行条件、指値などが含まれる。このうち、ＳＰＡＮ証拠金計算で必要な要素（ＳＰＡＮ証拠金計算手段２２に入力するデータ）は、銘柄識別情報、売買区分、数量（枚数）であるため、証拠金計算に関する以下の記載において注文データ（または建玉データ）というときは、これらのみを指すことがある。すなわち、成行・指値等の執行条件、指値は、注文で入力されるが、証拠金計算での相殺処理には無関係である。
【００３１】
ＳＰＡＮ証拠金計算手段２２は、ＳＰＡＮ（登録商標）を用いた証拠金計算処理を実行するものであり、必要証拠金計算手段２３から渡される顧客の建玉データ群（建玉データの集合）を入力し、ＳＰＡＮ証拠金計算式による計算処理（相殺処理）を実行し、計算結果（必要証拠金の額）を出力して必要証拠金計算手段２３に返す（渡す）処理を実行する。ＳＰＡＮ証拠金計算のロジックは、取引所（または株式会社日本証券クリアリング機構）からパッケージとして提示されているものをそのままの状態で、すなわちブラックボックス化された状態で用いる。
【００３２】
ここで、ＳＰＡＮ証拠金計算手段２２に相殺処理の対象として入力する建玉データ群には、同一の商品の同一の限月の銘柄に限らず、異なる限月の銘柄も含まれる。例えば、日経２２５先物の３月が限月の銘柄と日経２２５先物の９月が限月の銘柄も相殺される。また、同一の商品に限らず異なる商品も相殺処理の対象として入力される。例えば、日経２２５ｍｉｎｉ先物は、日経２２５先物の１／１０の金額であり、日経２２５ｍｉｎｉ先物が１０枚あれば、日経２２５先物の１枚と相殺可能となる。１対１の相殺にならない場合の相殺の程度は、ＳＰＡＮ証拠金計算のロジックで定められている。
【００３３】
必要証拠金計算手段２３は、成立済み建玉群計算手段２３Ａと、ブル建玉群計算手段２３Ｂと、ベア建玉群計算手段２３Ｃとを含んで構成されている。
【００３４】
成立済み建玉群計算手段２３Ａは、注文受付手段２１により顧客の注文データを受け付けた際に、当該顧客の顧客識別情報と関連付けられて建玉データベース３０に記憶された当該顧客の成立済みの建玉データ（複数存在する場合にはその全て）のみにより成立済み建玉群（建玉データの集合）を生成し、この成立済み建玉群をＳＰＡＮ証拠金計算手段２２に入力し、ＳＰＡＮ証拠金計算手段２２から計算結果として出力された仮の必要証拠金の額を受け取り、受け取った仮の必要証拠金の額（採用候補となる額）を、成立済み建玉群計算額３４Ａとして計算額記憶手段３４に記憶させる処理を実行するものである。
【００３５】
ブル建玉群計算手段２３Ｂは、注文受付手段２１により顧客の注文データを受け付けた際に、当該顧客の顧客識別情報と関連付けられて建玉データベース３０に記憶された当該顧客の成立済みの建玉データ（複数存在する場合にはその全て）、当該顧客の顧客識別情報と関連付けられて未成立注文データベース３１に記憶された当該顧客の未成立の建玉データのうちのブルポジションの建玉データ（複数存在する場合にはその全て）、並びに、注文データ記憶手段３３に記憶された注文データがブルポジションの建玉データであった場合の当該建玉データによりブル建玉群（建玉データの集合）を生成し、このブル建玉群をＳＰＡＮ証拠金計算手段２３に入力し、ＳＰＡＮ証拠金計算手段２３から計算結果として出力された仮の必要証拠金の額（採用候補となる額）を受け取り、受け取った仮の必要証拠金の額をブル建玉群計算額３４Ｂとして計算額記憶手段３４に記憶させる処理を実行するものである。
【００３６】
ベア建玉群計算手段２３Ｃは、注文受付手段２１により顧客の注文データを受け付けた際に、当該顧客の顧客識別情報と関連付けられて建玉データベース３０に記憶された当該顧客の成立済みの建玉データ（複数存在する場合にはその全て）、当該顧客の顧客識別情報と関連付けられて未成立注文データベース３１に記憶された当該顧客の未成立の建玉データのうちのベアポジションの建玉データ（複数存在する場合にはその全て）、並びに、注文データ記憶手段３３に記憶された注文データがベアポジションの建玉データであった場合の当該建玉データによりベア建玉群（建玉データの集合）を生成し、このベア建玉群をＳＰＡＮ証拠金計算手段２２に入力し、ＳＰＡＮ証拠金計算手段２２から計算結果として出力された仮の必要証拠金の額（採用候補となる額）を受け取り、受け取った仮の必要証拠金の額をベア建玉群計算額３４Ｃとして計算額記憶手段３４に記憶させる処理を実行するものである。
【００３７】
ここで、ブルポジションの建玉データとは、先物・オプションの原資産価値が上昇した場合に価値が上昇する建玉データのことをいい、具体的には、先物の買建て、コールの買建て（オプションの買い手は証拠金不要であるが、相殺処理の対象にはするため、ＳＰＡＮ証拠金計算手段２２への入力対象になる。）、プットの売建ての各データである。
【００３８】
また、ベアポジションの建玉データとは、先物・オプションの原資産価値が下降した場合に価値が上昇する建玉データのことをいい、具体的には、先物の売建て、プットの買建て（オプションの買い手は証拠金不要であるが、相殺処理の対象にはするため、ＳＰＡＮ証拠金計算手段２２への入力対象になる。）、コールの売建ての各データである。
【００３９】
従って、ブル建玉群計算手段２３Ｂやベア建玉群計算手段２３Ｃによるブルポジションの建玉データであるか、ベアポジションの建玉データであるかの判断処理は、先物の場合には、売買区分を参照し、オプションの場合には、銘柄識別情報に含まれるコール・プットの別、および売買区分を参照することにより実行される。
【００４０】
取引許否判断手段２４は、計算額記憶手段３４に記憶された成立済み建玉群計算額３４Ａ、ブル建玉群計算額３４Ｂ、およびベア建玉群計算額３４Ｃの３つの計算額のうちの最も大きい金額を必要証拠金として採用し、注文を行った顧客の顧客識別情報と関連付けられて証拠金データベース３２に記憶された当該顧客の証拠金の残高と、採用した必要証拠金とを比較し、当該顧客について証拠金が足りている場合（証拠金の残高が必要証拠金以上である場合）には、注文に係る取引を許可し、一方、当該顧客について証拠金が足りていない場合（証拠金の残高が必要証拠金よりも少ない場合）には、注文に係る取引を許可しないという取引の許否の判断処理を実行するものである。
【００４１】
ここで、必要証拠金として成立済み建玉群計算額３４Ａが採用された場合は、未成立の建玉を考慮すると、必要証拠金が減ってしまうので、それは採用できなかったことになる。また、ブル建玉群計算額３４Ｂが採用された場合は、成立済みの建玉がトータルでブルポジションなので、未成立の建玉を考慮すると、必要証拠金が増えるのでこれを採用したことになる。さらに、ベア建玉群計算額３４Ｃが採用された場合は、成立済みの建玉がトータルでベアポジションなので、未成立の建玉を考慮すると、必要証拠金が増えるのでこれを採用したことになる。
【００４２】
通知手段２５は、取引許否判断手段２４により取引を許可しないと判断した場合に、取引を許可しない旨および／または証拠金が不足する旨の通知情報（表示用データ）を、ネットワーク１を介して顧客端末装置４０へ送信する処理を実行するものである。
【００４３】
発注手段２６は、取引許否判断手段２４により取引を許可すると判断した場合に、注文データ記憶手段３３に記憶された顧客の注文データを用いて、発注データ（銘柄識別情報、売買区分、数量（枚数）、成行・指値等の執行条件、指値、注文識別情報、顧客識別情報などを含む。）を作成し、作成した発注データを、通信回線２を介して市場システム５０に送信するとともに、注文データ記憶手段３３に記憶された顧客の注文データを、当該顧客の未成立の建玉データとして、注文識別情報および顧客識別情報と関連付けて未成立注文データベース３１に記憶させる処理を実行するものである。
【００４４】
約定手段２７は、市場システム５０から通信回線２を介して送信されてくる約定データ（銘柄識別情報、売買区分、約定数量（約定枚数）、約定価格、注文識別情報、顧客識別情報などを含む。）を受信し、受信した約定データに含まれる注文識別情報および顧客識別情報に関連付けられて未成立注文データベース３１に記憶されている建玉データを、成立済みの建玉データとして、建玉データベース３０に振り替えて記憶させる処理を実行するものである。
【００４５】
建玉データベース３０は、先物取引・オプション取引について成立した注文に係る顧客の建玉データ（銘柄識別情報、売買区分、数量（枚数）、売買価格等を含む。）を、注文識別情報および顧客識別情報と関連付けて記憶するものである。
【００４６】
未成立注文データベース３１は、先物取引・オプション取引についての未成立の注文に係る顧客の建玉データ（銘柄識別情報、売買区分、数量（枚数）、売買価格等を含む。）を、注文識別情報および顧客識別情報と関連付けて記憶するものである。なお、未成立注文データベース３１は、成立・未成立の別を示すステータスのカラムを設けること等により、建玉データベース３０と一体化してもよい。
【００４７】
証拠金データベース３２は、先物取引・オプション取引についての建玉を維持するために顧客により差し入れられた証拠金の残高を、顧客識別情報と関連付けて記憶するものである。
【００４８】
注文データ記憶手段３３は、注文受付手段２１により受け付けた顧客の注文データ（銘柄識別情報、売買区分、数量（枚数）、売買価格等を含む。）を、注文受付手段２１により当該注文に付与した注文識別情報および当該注文の際に顧客により入力された顧客識別情報と関連付けて（一時的に）記憶するものである。
【００４９】
計算額記憶手段３４は、必要証拠金計算手段２３による処理で得られた成立済み建玉群計算額３４Ａ、ブル建玉群計算額３４Ｂ、およびベア建玉群計算額３４Ｃを（一時的に）記憶するものである。
【００５０】
以上において、売買取引サーバ２０は、１台のコンピュータあるいは１つのＣＰＵにより実現されるものに限定されず、複数のコンピュータあるいは複数のＣＰＵで分散処理を行うことにより実現されるものであってもよい。
【００５１】
また、先物・オプションの売買取引に関する各処理を実行する各手段２１，２２，２３，２４，２５，２６，２７は、売買取引サーバ２０を構成するコンピュータ本体の内部に設けられた中央演算処理装置（ＣＰＵ）、およびこのＣＰＵの動作手順を規定する１つまたは複数のプログラムにより実現される。
【００５２】
さらに、建玉データベース３０、未成立注文データベース３１、証拠金データベース３２としては、例えば、ハードディスクが好適であるが、必要な記憶容量、アクセス速度、耐久性等を確保できれば、フラッシュ・メモリ等の他の記録媒体を用いてもよい。一方、注文データ記憶手段３３および計算額記憶手段３４については、顧客からの注文を受け付けた際の一時的な記憶で足りるため、主メモリ上の記憶でよいが、不揮発性の記録媒体を用いてもよい。
【００５３】
顧客端末装置４０は、顧客（投資家）が操作する端末装置であり、コンピュータにより構成され、例えばマウスやキーボードやタッチパネル等の入力手段と、例えば液晶ディスプレイやＣＲＴディスプレイ等の表示装置とを備え、さらには適宜、印刷装置等を備えていてもよい。また、顧客端末装置４０は、例えば、タブレット端末、携帯情報端末（ＰＤＡ）、携帯電話機（ＰＨＳを含む。）等の携帯機器でもよい。
【００５４】
市場システム５０は、先物取引やオプション取引を取り扱う市場を形成するシステムであり、コンピュータにより構成され、現行法規である金融商品取引法上の金融商品取引所システムに限らず、将来施行される法規に基づく市場システムを含み、例えば、既存または将来新設される取引所システム、ＰＴＳ市場を形成する証券会社のシステム（私設取引システム）等である。
【００５５】
このような本実施形態においては、以下のようにして売買取引システム１０により先物・オプションの売買取引に関する処理、特に証拠金計算処理が行われる。
【００５６】
図２において、顧客端末装置４０からネットワーク１を介して送信されてくる顧客（投資家）による注文画面の送信要求信号を受信した場合には、注文受付手段２１により、先物・オプションの売買取引用の注文画面の表示用データを、ネットワーク１を介して顧客端末装置４０へ送信する。この時点で、注文受付手段２１は、ログイン時に顧客により入力された顧客識別情報（顧客コード等）を受信している。それから、注文受付手段２１により、顧客端末装置４０からネットワーク１を介して送信されてくる先物取引やオプション取引についての顧客の注文データを受信し、受信した注文データに注文識別情報（注文コード等）を付与し、この注文データを、注文識別情報および顧客識別情報と関連付けて注文データ記憶手段３３に記憶させる（ステップＳ１）。
【００５７】
それから、成立済み建玉群計算手段２３Ａにより、注文を行った顧客の顧客識別情報と関連付けられて建玉データベース３０に記憶された当該顧客の成立済みの建玉データ（銘柄識別情報、売買区分、数量（枚数））を取得する。複数存在する場合にはその全てを取得する。そして、取得した建玉データにより、ＳＰＡＮ入力用データとしての成立済み建玉群を生成し、この成立済み建玉群をＳＰＡＮ証拠金計算手段２２に入力し、ＳＰＡＮ証拠金計算手段２２から計算結果として出力された仮の必要証拠金の額を受け取り、受け取った仮の必要証拠金の額（採用候補となる額）を、成立済み建玉群計算額３４Ａとして計算額記憶手段３４に記憶させる（ステップＳ２）。
【００５８】
続いて、ブル建玉群計算手段２３Ｂにより、注文を行った顧客の顧客識別情報と関連付けられて建玉データベース３０に記憶された当該顧客の成立済みの建玉データ（銘柄識別情報、売買区分、数量（枚数））を取得する。複数存在する場合にはその全てを取得する。また、ブル建玉群計算手段２３Ｂにより、当該顧客の顧客識別情報と関連付けられて未成立注文データベース３１に記憶された当該顧客の未成立の建玉データ（銘柄識別情報、売買区分、数量（枚数））を取得する。複数存在する場合にはその全てを取得する。そして、それらの未成立の建玉データの中から、ブルポジションの建玉データを抽出する。複数存在する場合にはその全てを抽出する。この際、ブルポジションの建玉データの抽出処理では、銘柄識別情報および売買区分を参照し、先物の買建て、コールの買建て、プットの売建ての場合を抽出する。さらに、ブル建玉群計算手段２３Ｂにより、注文データ記憶手段３３に記憶された注文データがブルポジションの建玉データであるか否かを判断する。そして、成立済みの建玉データと、未成立の建玉データのうちのブルポジションの建玉データと、注文データがブルポジションの建玉データであった場合のその建玉データとにより、ＳＰＡＮ入力用データとしてのブル建玉群（建玉データの集合）を生成し、このブル建玉群をＳＰＡＮ証拠金計算手段２３に入力し、ＳＰＡＮ証拠金計算手段２３から計算結果として出力された仮の必要証拠金の額（採用候補となる額）を受け取り、受け取った仮の必要証拠金の額をブル建玉群計算額３４Ｂとして計算額記憶手段３４に記憶させる（ステップＳ３）。
【００５９】
さらに、ベア建玉群計算手段２３Ｃにより、注文を行った顧客の顧客識別情報と関連付けられて建玉データベース３０に記憶された当該顧客の成立済みの建玉データ（銘柄識別情報、売買区分、数量（枚数））を取得する。複数存在する場合にはその全てを取得する。また、ベア建玉群計算手段２３Ｃにより、当該顧客の顧客識別情報と関連付けられて未成立注文データベース３１に記憶された当該顧客の未成立の建玉データ（銘柄識別情報、売買区分、数量（枚数））を取得する。複数存在する場合にはその全てを取得する。そして、それらの未成立の建玉データの中から、ベアポジションの建玉データを抽出する。複数存在する場合にはその全てを抽出する。この際、ベアポジションの建玉データの抽出処理では、銘柄識別情報および売買区分を参照し、先物の売建て、プットの買建て、コールの売建ての場合を抽出する。さらに、ベア建玉群計算手段２３Ｃにより、注文データ記憶手段３３に記憶された注文データがベアポジションの建玉データであるか否かを判断する。そして、成立済みの建玉データと、未成立の建玉データのうちのベアポジションの建玉データと、注文データがベアポジションの建玉データであった場合のその建玉データとにより、ＳＰＡＮ入力用データとしてのベア建玉群（建玉データの集合）を生成し、このベア建玉群をＳＰＡＮ証拠金計算手段２２に入力し、ＳＰＡＮ証拠金計算手段２２から計算結果として出力された仮の必要証拠金の額（採用候補となる額）を受け取り、受け取った仮の必要証拠金の額をベア建玉群計算額３４Ｃとして計算額記憶手段３４に記憶させる（ステップＳ４）。
【００６０】
その後、取引許否判断手段２４により、計算額記憶手段３４に記憶された成立済み建玉群計算額３４Ａ、ブル建玉群計算額３４Ｂ、およびベア建玉群計算額３４Ｃの３つの計算額のうちの最も大きい金額を必要証拠金として採用し、注文を行った顧客の顧客識別情報と関連付けられて証拠金データベース３２に記憶された当該顧客の証拠金の残高と、採用した必要証拠金とを比較し、当該顧客について証拠金が足りている場合（証拠金の残高が必要証拠金以上である場合）には、注文に係る取引を許可し、一方、当該顧客について証拠金が足りていない場合（証拠金の残高が必要証拠金よりも少ない場合）には、注文に係る取引を許可しないという判断を行う（ステップＳ５）。
【００６１】
そして、ステップＳ５で、取引許否判断手段２４により取引を許可しないと判断した場合には、通知手段２５により、取引を許可しない旨および／または証拠金が不足する旨の通知情報（表示用データ）を、ネットワーク１を介して顧客端末装置４０へ送信する（ステップＳ６）。顧客端末装置４０では、売買取引サーバ２０からの通知情報を受信すると、取引を許可しない旨および／または証拠金が不足する旨を画面表示し、顧客への通知を行う。
【００６２】
一方、ステップＳ５で、取引許否判断手段２４により取引を許可すると判断した場合には、発注手段２６により、注文データ記憶手段３３に記憶された顧客の注文データを用いて、発注データ（銘柄識別情報、売買区分、数量（枚数）、成行・指値等の執行条件、指値、注文識別情報、顧客識別情報などを含む。）を作成し、作成した発注データを、通信回線２を介して市場システム５０に送信する（ステップＳ７）。また、発注手段２６により、市場システム５０への発注処理に伴って、注文データ記憶手段３３に記憶された顧客の注文データを、当該顧客の未成立の建玉データとして、注文識別情報および顧客識別情報と関連付けて未成立注文データベース３１に記憶させる。
【００６３】
その後、約定手段２７により、市場システム５０から通信回線２を介して送信されてくる約定データ（銘柄識別情報、売買区分、約定数量（約定枚数）、約定価格、注文識別情報、顧客識別情報などを含む。）を受信した場合には、受信した約定データに含まれる注文識別情報および顧客識別情報に関連付けられて未成立注文データベース３１に記憶されている建玉データを、成立済みの建玉データとして、建玉データベース３０に振り替えて記憶させる（ステップＳ８）。
【００６４】
次に、以上に述べた必要証拠金の計算処理の妥当性を確認するため、具体的な数量（枚数）を用いて説明を行う。説明の便宜上、銘柄は同じであり、ブルポジションとベアポジションとの数量（枚数）は１対１で相殺できるものとする。なお、注文に係る建玉は、未成立の建玉に含めて考えている。
【００６５】
図３において、状況（Ａ）は、成立済み建玉データのみの場合であり、ブルポジションの建玉データが６枚あり、ベアポジションの建玉データが４枚あり、これらが相殺されると、必要証拠金は建玉２枚分となるので、成立済み建玉群計算額３４Ａ＝２枚である。未成立建玉がない場合は、これで確定となる。
【００６６】
状況（Ｂ）は、状況（Ａ）に全ての未成立の建玉（ブルポジションが２枚、ベアポジションが３枚）を加えた場合である。全ての未成立の建玉が成立したと仮定した場合、ブルポジションが８枚となり、ベアポジションが７枚となり、必要証拠金が１枚に減ってしまう。注文を入れるだけで必要証拠金が減ってしまうのは、問題であるから、このような必要証拠金は採用できない。
【００６７】
状況（Ｃ）は、状況（Ａ）にブルポジションの未成立の建玉２枚を加えた場合である。ブルポジションの未成立の建玉が成立したと仮定した場合、ブルポジションが８枚となり、ベアポジションが４枚となり、必要証拠金は建玉４枚分となるので、ブル建玉群計算額３４Ｂ＝４枚である。状況（Ａ）はトータルでブルポジションであり、それに同じ側のブルポジションの全ての未成立の建玉を加えているので、必要証拠金が増えていることから、このブル建玉群計算額３４Ｂ＝４枚は、採用することができる。
【００６８】
状況（Ｄ）は、状況（Ａ）にベアポジションの未成立の建玉３枚を加えた場合である。ベアポジションの未成立の建玉が成立したと仮定した場合、ブルポジションが６枚となり、ベアポジションが７枚となり、必要証拠金は建玉１枚分となるので、ベア建玉群計算額３４Ｃ＝１枚である。状況（Ａ）はトータルでブルポジションであり、それに反対側のベアポジションの全ての未成立の建玉を加えているので、必要証拠金が減ってしまっていることから、このベア建玉群計算額３４Ｃ＝１枚は、採用することができない。
【００６９】
このような本実施形態によれば、次のような効果がある。すなわち、顧客のポートフォリオ内の建玉の個数がどんなに多くとも、ＳＰＡＮ証拠金計算手段２２によるＳＰＡＮ証拠金計算式によるデータ処理を３回行えば、必要証拠金を計算することができる。従って、例えば、仮に、未成立の建玉がＮ個あるとしたときに２のＮ乗回のデータ処理を行う場合に比べ、処理時間を短縮し、処理速度の向上を図ることができる。また、未成立の建玉の個数の変動に伴う処理時間の変動を回避し、処理速度の一定化を図ることもできる。このため、インターネット取引のようなスピードが要求される場合においても、一定の性能要件を満たすことができる。
【００７０】
また、ＳＰＡＮ証拠金計算手段２２は、ブラックボックス化されたＳＰＡＮ証拠金計算式をそのまま利用するので、ＳＰＡＮ証拠金計算式を変更して使用する場合に比べ、証券会社等に発生するリスクを抑えることができる。
【００７１】
さらに、ＳＰＡＮ証拠金計算式をブラックボックス化されたまま利用するので、ＳＰＡＮ証拠金計算のパッケージ自体の仕様に変更があった場合でも、パッケージを入れ替えることで容易に対応することができる。
【００７２】
なお、本発明は前記実施形態に限定されるものではなく、本発明の目的を達成できる範囲内での変形等は本発明に含まれるものである。
【００７３】
例えば、前記実施形態では、図２に示すように、説明の便宜上、成立済み建玉群計算手段２３ＡによるステップＳ２の処理、ブル建玉群計算手段２３ＢによるステップＳ３の処理、ベア建玉群計算手段２３ＣによるステップＳ４の処理は、この順で記載されていたが、これらの処理順は任意であり、ＳＰＡＮ証拠金計算手段２２への３回の入力は、どのような順番でもよい。また、必要証拠金計算手段２３を構成するこれらの３つの各手段２３Ａ，２３Ｂ，２３Ｃによる各処理は、説明の便宜上、処理の一部につき重複する内容の記載がなされているが、これらの３つの各手段２３Ａ，２３Ｂ，２３Ｃによる各処理の一部は、並行して行われてもよく、共通化されていてもよく、要するに、ＳＰＡＮ証拠金計算手段２２に入力する３つの建玉データの集合（但し、建玉データが１つしかない場合もある。）を生成できればよい。
【００７４】
具体的には、必要証拠金計算手段２３を構成するこれらの３つの各手段２３Ａ，２３Ｂ，２３Ｃによる処理の各々には、建玉データベース３０からの成立済みの建玉データの取得処理が含まれているが、主メモリやキャッシュメモリにデータが残っていれば、３回行う必要はなく、共通化してもよい。
【００７５】
また、ブル建玉群計算手段２３Ｂは、未成立注文データベース３１からの未成立の建玉データの取得と、それらの未成立の建玉データの中からのブルポジションの建玉データの抽出とを行い、ベア建玉群計算手段２３Ｃは、未成立注文データベース３１からの未成立の建玉データの取得と、それらの未成立の建玉データの中からのベアポジションの建玉データの抽出とを行う。従って、未成立注文データベース３１からの未成立の建玉データの取得は、双方の手段２３Ｂ，２３Ｃで行っているが、この取得処理は、主メモリやキャッシュメモリにデータが残っていれば、２回行う必要はなく、共通化してもよい。そして、ブルポジションの建玉データであるか、ベアポジションの建玉データであるかの判断処理は、表裏一体の処理であるから、別々に行うのではなく、まとめて行ってもよい。
【００７６】
さらに、前記実施形態では、ＳＰＡＮ証拠金計算手段２２は、売買取引サーバ２０に設けられていたが、必要証拠金計算手段２３を含むサーバとは別のサーバに設けてもよく、また、先物取引やオプション取引の注文を受け付ける証券会社等の金融機関が管理するサーバではなく、別の機関（例えば、ＳＰＡＮ証拠金計算のパッケージの提供者）が管理するサーバに設けてもよい。この場合には、必要証拠金計算手段２３を含むサーバから、３つの建玉データの集合（成立済み建玉群、ブル建玉群、ベア建玉群）を、通信回線を介してＳＰＡＮ証拠金計算手段２２を含むサーバへ送信するとともに、ＳＰＡＮ証拠金計算手段２２を含むサーバから通信回線を介して送信されてくる３つの計算結果としての仮の必要証拠金の額（計算額３４Ａ，３４Ｂ，３４Ｃ）を、必要証拠金計算手段２３を含むサーバで受信する。
【００７７】
また、前記実施形態では、いずれの注文を受け付けた際にも、成立済み建玉群計算手段２３ＡによるステップＳ２の処理と、ブル建玉群計算手段２３ＢによるステップＳ３の処理と、ベア建玉群計算手段２３ＣによるステップＳ４の処理とが行われていたが、次のように、所定の条件１または２を満たした場合に、これらの３つの処理のうちの２つの処理を省略できる構成としてもよい。なお、以下では、説明の便宜上、各構成要素が前記実施形態と異なる機能を有する場合も、前記実施形態と対応する構成要素であれば、前記実施形態と同一の符号を用いて説明を行う。
【００７８】
先ず、取引許否判断手段２４により、成立済み建玉群計算額３４Ａ、ブル建玉群計算額３４Ｂ、ベア建玉群計算額３４Ｃの３つの計算額のうちのいずれが必要証拠金として採用されたのかを示す採用情報を顧客識別情報と関連付けて記憶する採用情報記憶手段（不図示）を、売買取引サーバ２０に設けておく。そして、取引許否判断手段２４が３つの計算額３４Ａ，３４Ｂ，３４Ｃのうちのいずれかを採用したときに、取引許否判断手段２４がその採用情報を採用情報記憶手段に記憶させるようにする。なお、採用情報のデータ形態は、任意であり、例えば、計算額３４Ａが採用されたことを示す情報を「１」とし、ブル建玉群計算額３４Ｂが採用されたことを示す情報を「２」とし、ベア建玉群計算額３４Ｃが採用されたことを示す情報を「３」とし、これらの情報をクリアしたときには「０」とする等である。なお、採用情報のクリアは、予め定められた場合に採用情報消去手段（不図示）が行う。
【００７９】
次に、必要証拠金計算手段２３の中に、注文受付手段２１により顧客の注文データを受け付けた際に、上記の採用情報記憶手段に記憶された当該顧客の前回採用に係る採用情報を取得し、取得した前回採用に係る採用情報を用いた処理を実行する採用情報参照手段（不図示）を設けておく。
【００８０】
この採用情報参照手段は、注文の受付時に、採用情報記憶手段から前回採用に係る採用情報を取得し、今回の注文データがブルポジションの建玉データであり、かつ、取得した前回の採用情報がブル建玉群計算額３４Ｂを採用したことを示す情報であった場合（条件１）には、成立済み建玉群計算手段２３Ａ、ブル建玉群計算手段２３Ｂ、およびベア建玉群計算手段２３Ｃの３つの計算手段のうち、ブル建玉群計算手段２３Ｂのみに計算処理の実行指令を送る。当該顧客の前回の注文受付時に、ブル建玉群計算額３４Ｂを採用していた場合には、トータルでブルポジションであったということであるから、その直後の注文データがブルポジションの建玉データであれば、その注文データを相殺対象に加えても、トータルでブルポジションが維持されることになるので、ブル建玉群計算手段２３Ｂの計算のみでよいためである。
【００８１】
また、採用情報参照手段は、注文の受付時に、採用情報記憶手段から前回採用に係る採用情報を取得し、今回の注文データがベアポジションの建玉データであり、かつ、取得した前回の採用情報がベア建玉群計算額３４Ｃを採用したことを示す情報であった場合（条件２）には、３つの計算手段２３Ａ，２３Ｂ，２３Ｃのうち、ベア建玉群計算手段２３Ｃのみに計算処理の実行指令を送る。当該顧客の前回の注文受付時に、ベア建玉群計算額３４Ｃを採用していた場合には、トータルでベアポジションであったということであるから、その直後の注文データがベアポジションの建玉データであれば、その注文データを相殺対象に加えても、トータルでベアポジションが維持されることになるので、ベア建玉群計算手段２３Ｃの計算のみでよいためである。
【００８２】
そして、採用情報参照手段は、その他の場合（条件１も条件２も満たさない場合）には、３つの計算手段２３Ａ，２３Ｂ，２３Ｃの全てに計算処理の実行指令を送る。すなわち、条件１も条件２も満たさない場合には、通常通り、ＳＰＡＮ証拠金計算手段２２によるＳＰＡＮ証拠金計算式によるデータ処理を３回行う。
【００８３】
取引許否判断手段２４は、前記実施形態では、計算額記憶手段３４に３つの計算額３４Ａ，３４Ｂ，３４Ｃの全てが記憶されているので、それらの３つの計算額３４Ａ，３４Ｂ，３４Ｃのうちの最も大きい金額を必要証拠金として採用する処理を行う構成とされていた。しかし、条件１を満たす場合、すなわち採用情報参照手段によりブル建玉群計算手段２３Ｂのみに計算処理の実行指令が送られた場合には、計算額記憶手段３４にはブル建玉群計算額３４Ｂしか記憶されていないので、取引許否判断手段２４は、そのブル建玉群計算額３４Ｂを必要証拠金として採用することになる。また、条件２を満たす場合、すなわち採用情報参照手段によりベア建玉群計算手段２３Ｃのみに計算処理の実行指令が送られた場合には、計算額記憶手段３４にはベア建玉群計算額３４Ｃしか記憶されていないので、取引許否判断手段２４は、そのベア建玉群計算額３４Ｃを必要証拠金として採用することになる。その他の場合（条件１も条件２も満たさない場合）には、前記実施形態の場合と同様に、計算額記憶手段３４には３つの計算額３４Ａ，３４Ｂ，３４Ｃの全てが記憶されているので、取引許否判断手段２４は、それらの３つの計算額３４Ａ，３４Ｂ，３４Ｃのうちの最も大きい金額を必要証拠金として採用することになる。
【００８４】
そして、取引許否判断手段２４は、３つの計算額３４Ａ，３４Ｂ，３４Ｃのうちの最も大きい金額を採用した場合（条件１も条件２も満たさない場合）、ブル建玉群計算額３４Ｂしか計算されていないので、それを採用した場合（条件１）、ベア建玉群計算額３４Ｃしか計算されていないので、それを採用した場合（条件２）のいずれの場合についても、そのときの採用に係る採用情報を、注文を行った顧客の顧客識別情報と関連付けて採用情報記憶手段に記憶させる処理を実行する。
【００８５】
また、取引許否判断手段２４は、３つの計算額３４Ａ，３４Ｂ，３４Ｃのうちのいずれかを必要証拠金として採用した後に、証拠金の過不足判定による取引の許否の判断処理を行うという点は、前記実施形態の場合と同様である。
【００８６】
なお、前回の注文時から今回の注文時までの間に、未成立の注文が約定した場合には、建玉データベース３０や未成立注文データベース３１の状況が前回の注文時から変化するので、その約定に係る情報を受け取った採用情報消去手段により、採用情報記憶手段に記憶されている採用情報をクリアする（ＮＵＬＬやゼロ等にする）。また、満期日（決済期日）到来で決済が行われた場合等も前回の注文時から状況が変化するので、その状況変化をもたらした要因に係る情報を受け取った採用情報消去手段により、採用情報記憶手段に記憶されている採用情報をクリアする。採用情報がクリアされると、前回採用に係る採用情報を取得できなくなり、条件１，２は満たされないことになるので、通常通り、ＳＰＡＮ証拠金計算手段２２によるＳＰＡＮ証拠金計算式によるデータ処理を３回行う。
【００８７】
このように採用情報記憶手段や採用情報参照手段を設けた構成とした場合には、成立済み建玉群計算手段２３Ａ、ブル建玉群計算手段２３Ｂ、およびベア建玉群計算手段２３Ｃの３つの計算手段のうちの２つの計算手段によるデータ処理を省略することができ、その分だけ処理時間を短縮することができる。すなわち、条件１を満たせば、ブル建玉群計算手段２３Ｂによる計算処理だけでよいので、成立済み建玉群計算手段２３Ａやベア建玉群計算手段２３Ｃによる計算処理を省略することができ、ＳＰＡＮ証拠金計算手段２２によるＳＰＡＮ証拠金計算式によるデータ処理を３回ではなく、１回で済ませることができる。また、条件２を満たせば、ベア建玉群計算手段２３Ｃによる計算処理だけでよいので、成立済み建玉群計算手段２３Ａやブル建玉群計算手段２３Ｂによる計算処理を省略することができ、ＳＰＡＮ証拠金計算手段２２によるＳＰＡＮ証拠金計算式によるデータ処理を３回ではなく、１回で済ませることができる。
【産業上の利用可能性】
【００８８】
以上のように、本発明の必要証拠金計算システムおよびプログラムは、例えば、インターネットを含むネットワークを介して株価指数先物取引や株価指数オプション取引の注文があった際に、取引の許否判断のために必要証拠金の計算処理を行う場合等に用いるのに適している。
【符号の説明】
【００８９】
１  ネットワーク
１０  証拠金計算システムを含む先物・オプションの売買取引システム
２１  注文受付手段
２２  ＳＰＡＮ証拠金計算手段
２３  必要証拠金計算手段
２４  取引許否判断手段
２５  通知手段
３０  建玉データベース
３１  未成立注文データベース
３２  証拠金データベース
３３  注文データ記憶手段
３４  計算額記憶手段
４０  顧客端末装置
【要約】
【課題】処理速度の向上および一定化を図ることができるとともに、リスクを軽減でき、ＳＰＡＮ証拠金計算のパッケージ自体の仕様に変更があった場合にも容易に対応が可能な必要証拠金計算システムを提供する。
【解決手段】注文を受け付けた際に、成立済みの建玉のみをＳＰＡＮ証拠金計算手段２２に入力して得られた成立済み建玉群計算額３４Ａと、成立済みの建玉、ブルポジションの未成立の建玉、ブルポジションの建玉の注文をＳＰＡＮ証拠金計算手段２２に入力して得られたブル建玉群計算額３４Ｂと、成立済みの建玉、ベアポジションの未成立の建玉、ベアポジションの建玉の注文をＳＰＡＮ証拠金計算手段２２に入力して得られたベア建玉群計算額３４Ｃとのうち、最も大きい金額を必要証拠金として採用する。
【選択図】図１【図１】
0005943527.tif 000002
【図２】
0005943527.tif 000003
【図３】
0005943527.tif 000004