JP2006215841A - 証券取引情報提供システムおよび証券発注プログラム - Google Patents

Abstract

【課題】オンライン証券に関する発注、約定の情報をその利用者の運用成績とともにタイムリーに提供する。
【解決手段】サービス提供サーバ１２０は、オンライン証券を利用した利用者の発注・約定情報を逐次プールして、利用者の運用成績をランキングする。また、この運用成績とともに、発注・約定情報を逐次利用者端末１４０に提供していく。証券ごとの掲示板では、各投稿について、その投稿を行った利用者の運用成績情報を投稿情報と併せて掲示する。
【選択図】図１

Description

本発明は、オンライン証券取引に関する情報提供システムに関する。

近年、複数の証券会社がインターネットを介した証券取引に関するオンラインサービスの提供を開始している。ここで、証券取引とは個別株式、証券先物、信用取引および商品先物取引等を含む。オンライン証券会社による、インターネットを利用したオンライン証券取引サービスは、利用者（顧客）から約定情報、資金の受入、引き出しの情報を受け入れ、管理するサービスを含む。一方、銀行も、インターネットを利用して自宅から口座間の資金の移動をオンラインで行えるサービスを提供するようになっている。このような背景から、これまで証券取引の経験のなかった個人も自宅に居ながらにして容易に証券取引に参加することができるようになってきた。このため、個人投資家が急増している。

従来、オンライン証券会社は、利用者が欲しいと思う証券に関する銘柄情報や株価情報などをクライアント（典型的にはパーソナルコンピュータ：ＰＣ）側から要求し、それに対応してオンライン証券会社側（サーバ）が当該要求された情報を返答するサービスを提供している。

また、証券取引に関しての運用成績を競うシミュレーションゲームとして、インターネット上でゲーム利用者を募り、その利用者から事前に提供された仮想の発注内容に基づき運用成績を算出し、この運用成績情報を当該発注内容と併せて提供するサービスが知られている（非特許文献１）。また、証券取引に関するオンライン掲示板にあっては、利用者が各個別株式に関する意見を書き込み、他の利用者がこれを閲覧することができるサービスを提供している。

特許文献１は、このようなシミュレーションゲームを用いた競技ではなく、インターネットを介したオンライントレードにおけるリアルマネーで順位を競う証券取引全般、又は商品取引全般に及ぶ競技の管理・運営方法並びにその競技の管理・運営システムを開示している。
特開２００３−２４２３５１号公報 http://www.stockrace.info/

個人投資家にとって、上記のようなシミュレーションゲームは、これに参加することにより仮想的に証券取引の経験を積むことができるという点で有用である。しかし、ゲームに参加するにしても、例えばどのような銘柄にどのようなタイミングどのような注文を出すかは、自身で判断する必要がある。そのためには、上記のような証券会社から提供される情報が有用であることは勿論であるが、それだけでは十分でなく、どの銘柄の株価がどのように変化するかを予想する必要がある。その判断のためには運用成績の良好な他者の取引内容が参考となると考えられる。

しかしながら、以上のようなシミュレーションゲームはあくまで仮想的なものであり、実際の投資には、当該ゲームにおける他の利用者の運用成績の情報は必ずしも役に立つものではない。なぜなら、提供される仮想の発注内容情報は実際の注文に反映されるとは限らず、また、その取引が実際に約定するかどうかは仮想によるしかないためである。したがって、情報を受ける側としても、ひとつの仮定として情報を受けるしかなかった。

また、市況は刻々変化していくのに対して、情報が提供されるタイミングはリアルタイムではないため、運用結果情報を受け取った時点では市況が大きく変化している可能性がある。

特許文献１に記載のシステムではリアルマネーによる実際の取引に基づく競技における収益率に基づく順位は分かるが、個々の競技利用者が実際にどのようなタイミングでどのような発注を行いどのような結果を得ているかについて、他の利用者は分からない。すなわち、このシステムは、利用者が実際の証券取引を行う際の参考となる情報を得るために有用なものではない。

また、証券取引に関する意見が書き込まれるオンライン掲示板においては、書き込みをしている利用者が、本当に掲示板に書かれているとおりの取引を行っているかどうか、また、その結果どのような運用成績をあげているかについては情報を得ることができなかった。この意味で、従来のオンライン掲示板の書き込み情報は玉石混淆であり、信憑性、信頼性は全くないものである。

本発明はこのような背景においてなされたものであり、その目的は、証券取引における実際の取引に参考となる情報を利用者に提供することができる証券取引情報提供システムを提供することにある。

本発明による他の目的は、オンライン証券に関する発注、約定の情報をその利用者の運用成績とともにタイムリーに提供することができる証券取引情報提供システムを提供することにある。

本発明によるさらに他の目的は、証券に関するオンラインの掲示板において、その投稿者がどのような運用をしていて、その結果、どのような運用成績を残しているのかを知ることができる証券取引情報提供システムおよびこれに関連して自動的に発注情報を作成することができる証券発注プログラムを提供することにある。

本発明による証券取引情報提供システムは、複数の利用者の情報を蓄積した利用者データベースと、各利用者によるオンライン証券取引に関する少なくとも発注・約定の情報を蓄積するデータベースと、利用者毎の運用成績を求める運用成績算出手段と、利用者毎の運用成績を蓄積するデータベースと、利用者の発注・約定の情報を当該利用者の運用成績と関連付けた証券取引情報を通信または放送を介して利用者に提供する送信手段とを備えたことを特徴とする。

各利用者によるオンライン証券取引に関する少なくとも発注・約定の情報を蓄積するデータベースは、利用者が例えば、オンライン証券会社を利用して証券取引を行った際の証券取引に関する注文、約定等に関するデータを受け取って蓄積する。運用成績算出手段は、このデータをもとに例えば期間収益率の計算を行い、各利用者の運用成績を求め、好ましくはその順位付けを行う。送信手段は、利用者の発注・約定の情報を当該利用者の運用成績と関連付けた証券取引情報を通信または放送を介して利用者に提供する。これにより、各利用者は他の利用者の実際の証券取引における発注・約定の情報とともに当該利用者の運用成績を知ることができる。

前記証券取引情報として、利用者端末上でグラフィック表示するための表示情報を作成する表示情報生成手段を備えてもよく、この場合、前記表示情報は、銘柄毎に、少なくとも運用成績の良好な利用者がその銘柄について当日に発注を行った売り買いの別、注文量、および約定の有無を反映させた、利用者単位の可視指標を含むことが好ましい。これによって、各利用者は自身が注目する他の利用者の実際の発注・約定の状況を視覚的に一覧により認識することができる。

表示領域内の第１軸上に当該銘柄の価格、前記第１軸と直角方向の第２軸上に時刻をそれぞれ割り当てて、各注文の該当する両軸上の位置に前記可視指標を表示させることにより、注目する利用者の取引状況とともに証券取引の推移を視覚的に認識することができる。

前記利用者の売り買いの別、注文量、および約定の有無は、前記可視指標の異なる表示パラメータに対応させて識別表示するようにしてもよい。これにより、文字による表示によらずにより多くの情報を表示することが可能となり、かつ、視覚的に取引状況の迅速な認識が容易となる。

当該銘柄について注文を行った利用者について、前記可視指標をその運用成績の上位者と他の者とで区別するようにしてもよい。

前記第１軸および第２軸上で、前記可視指標の表示とともに、当該銘柄の価格の推移をグラフ表示するようにしてもよい。これは、当該銘柄の価格の推移と注目する他の利用者の取引状況を比較検討するのに役立つ。

さらに、利用者が証券銘柄ごとに書き込みを行いこの書き込まれた情報を他の利用者が参照することができる掲示板手段を備える場合、この掲示板手段は、各投稿について、その投稿を行った利用者の運用成績情報を投稿情報と併せて掲示する。これにより、当該投稿の信憑性、信頼性が格段に向上することが期待できる。

本発明による証券発注プログラムは、ネットワークとの間で通信を行う機能を備えた端末装置において実行される証券取引発注プログラムであって、証券取引を行っている複数の利用者の少なくとも発注情報をその当該利用者の運用成績と関連付けた証券取引情報を、通信または放送を介してほぼリアルタイムに受信して蓄積するステップと、この蓄積された証券取引情報として、指定された特定の利用者の発注情報を受信したとき、その利用者の発注内容に当該取引に所定の条件を付加して得られる発注内容で当該端末装置の利用者の名義によるオンライン発注を行うステップとを実行する。これによって、利用者自身が指定した他の利用者の発注状況を参考にして自動的に発注情報を生成し、これに基づいてオンライン発注を行うことが可能となる。

本発明の証券取引情報提供システムによれば、情報提供サービスの利用者は、オンライン証券取引における他者の取引状況をその他者の運用成績の情報とともに認識できるので、自身の取引にとって有用な参考情報が得られる。加えて、証券ごとの掲示板を利用する利用者に関しては、当該利用者の運用状況、運用成績を参考にすることができるようにすることで、掲示板をみる利用者にとって格段に信憑性の高い情報を得ることができるようになる。

また、本発明により、オンライン証券取引業者にとっては、本サービスにより新たに証券取引への参加者の増大も見込める。通信事業者等にとっては通信利用者の増加が見込める。情報機器製造販売会社によっては、サーバや利用者端末の新たな調達が期待できる。

さらに本発明による証券発注プログラムによれば、利用者は自分の望む他の利用者の発注情報を参考にしながら自分の発注を行うことができるようになる。

以下、本発明の好適な実施の形態について、図面を参照しながら詳細に説明する。

図１は本発明が適用された証券取引情報提供システムの概略の構成を示している。このシステムは、少なくとも一社の、オンライン証券取引サービスを提供するオンライン証券会社のサーバ（証券取引サーバという）１１０（１１０ａ〜１１０ｎ）と、情報提供サービス業者のサーバ（情報提供サーバという）１２０と、複数の利用者端末１４０（１４０ａ〜１４０ｍ）とを含む。証券取引サーバ１１０および情報提供サーバ１２０と利用者端末１４０とは、インターネットを代表とする通信ネットワーク１３０を介して相互に接続される。証券取引サーバ１１０と情報提供サーバ１２０とは専用線で接続される例を示しているが、通信ネットワーク１３０により接続されてもよい。

利用者端末１４０からは、利用者による証券取引のための注文・売買等の発注を含むサービス要求を証券取引サーバ１１０へ発行し、証券取引サーバ１１０はこれに応じた証券取引サービスを利用者端末１４０へ提供する。また、この取引の情報の中から、本発明の情報提供サービスに対して自己の取引情報を公開することを承諾している利用者についての取引情報が、証券取引サーバ１１０から情報提供サーバ１２０に逐次通知される。証券取引サーバ１１０および情報提供サーバ１２０は、利用者端末１４０との間でｈｔｔｐプロトコル等に則ったデータの授受を行うＷｅｂサーバの機能を有する。情報提供サーバ１２０は、証券取引サーバ１１０から受領した取引情報を加工して利用者端末１４０へ提供する。

図２に、情報提供サーバ１２０の概略ハードウェア構成例を示す。証券取引サーバ１１０の構成も同様である。さらに、利用者端末１４０の構成も基本的には同様である。

図２において、制御部２０１はＣＰＵにより構成され、プログラム制御によりこのサーバ全体の動作を制御する。メモリ２０２は制御部２０１が実行するプログラムやデータを格納する記憶部である。入力部２０３はキーボードやマウス等の、ユーザがサーバに対して指示や情報を入力するための入力インタフェースを提供する部位である。外部記憶装置２０５はインストールされたプログラムや作成されたデータ等を不揮発的に記憶する大容量の記憶部である。表示部２０７は、液晶ディスプレイ、ＣＲＴ等の表示デバイスを含み、ユーザに対して表示情報を提供する部位である。通信部２０９は、通信ネットワーク１３０と接続され、データの通信機能を提供する。通信部２０９は、さらに専用線を介したデータ通信を行う機能を備えてもよい。このほか図示しないが、音声出力部や音声入力部を有してもよい。

図３に、本実施の形態における発注情報や情報提供のための各種情報を構成する各種データの流れを説明する。情報提供サーバ１２０には種々のデータベース（ＤＢ）を含む。まず、これらのデータベースについて説明する。

図４に示すように、利用者毎保有残高ＤＢ１００は利用者ごとに、現在保有する銘柄のデータを蓄積する。このＤＢ１００が保持する項目には、取引ＩＤ、顧客コード、会社コード、購入価格、株残、信用取引、購入日付、本日株価、評価額のデータを含む。ＤＢ１００は日次での更新を想定する。

「取引ＩＤ」は、原則として成立した約定データごとの取引番号をさす。したがって、後述する約定データ（当日分）ＤＢ２００（後述のプロセス２０）で採番していくことになる。この取引番号は例えば、「証券会社をあらわすコード＋約定日付＋通し番号」である。当日の約定データをＤＢ１００に反映させる段階（後述のプロセス５０）で、同一利用者、同一銘柄の取引については、当初の取引ＩＤを残すこととする。

「顧客コード」は、利用者毎に一意に割り当てられた番号である。この番号は、当初証券会社と契約し、このサービスに参加する段階で割り当てられる（後述のプロセス１１）。例えば、「証券会社をあらわす数字＋通し番号」である。
「会社コード」は取引銘柄の会社コードである。株式以外の商品（ワラント・国債等）はその他商品として取り扱う。
「購入価格」は、当該利用者の当該銘柄の購入（売却）価格（総計）である。。当初参加時点では、証券会社の保有するデータから引き継ぐ。当日分の約定データを反映させて更新する段階（後述のプロセス５０）では、既存の取引データに対して上書きする。
「株残」は当該利用者の現在手元にある購入（売却）株式数である。当初参加時点では、ＤＢ１００には証券会社の保有するデータを引き継ぐ。当日分の約定データを反映させて更新する段階（後述のプロセス５０）では、既存の取引データに対して上書きする。
「信用取引」はこの利用者が信用取引を利用している場合とそうでない場合を区別するための情報である。ＤＢ２００からＤＢ１００へ反映させる段階（後述のプロセス２０）においても、信用取引かどうかは区分する。信用取引を利用しているかどうかは、ランキングを作成する際にクラスわけに利用することができる。
「購入日付」は当初購入（信用取引の場合は売却もあり）の日付である。当日分の取引の結果が反映されて、ＤＢ１００の株数（Ｌｏｔ）が０になるまでは、当初の購入日付が引き継がれる。
「本日株価」は取引終了時点での本日最終株価である。このデータ自体は証券会社から受領する。新株発行時は、新株の株価がある場合には、その株価を利用して計算する。新株の株価がない場合には、新株の株価は適宜策定して「評価額」に反映させるものとする（例えば、新株の評価額は、親株の８割とする）。
「評価額」は現時点の取引ＩＤごとの評価額である。この評価額は次式で求める。新株についての評価は本日株価で述べたとおりの評価とする。
株数×本日株価

図５に示した約定データ（当日分）ＤＢ２００は、当日に約定した売買データを蓄積するデータベースであり、１つの注文であっても約定毎にほぼリアルタイムで記録しておく。（「ほぼリアルタイム」とは証券取引サーバ１１０から通知を受けるまでの遅延を考慮した表現である。）例えば銘柄２３４５の１０株について「成り行き」での「買い」注文が、例えば次に示すように順次すべて約定したときには、
銘柄２３４５ 買い ３株 単価４９００円
銘柄２３４５ 買い ２株 単価５０００円
銘柄２３４５ 買い ５株 単価５１００円
のようにＤＢ２００に時系列で約定毎にデータが記録されていく。

ＤＢ２００の保存する項目は、具体的には、取引ＩＤ、顧客コード、証券コード、売買の別、購入（売買）単価、約定株数、約定時刻のデータを含む。

「取引ＩＤ」はＤＢ１００の取引ＩＤと同じである。「購入単価」は約定時点での当該株式の単価である。ＤＢ２００からＤＢ１００に反映させる際には、購入価格に引きなおしてから実施する。
「約定株数」は当日の約定時点での約定株数である。上記の例のように、ひとつの注文でも複数の約定に分かれる可能性がある。その場合でも約定はそれぞれＤＢ２００に記録していく（後述するプロセス２０）。約定はプロセス４０を通じてＤＢ３００に反映させる。
「約定時刻」は約定が成立した時刻である。「約定株数」には、当日分の売買データのみを蓄積していく。つまり、プラス分もマイナス分もすべて記録していくこととする（後述するプロセス２０）。

図６に示した取引注文ＤＢ３００は当日の注文データを蓄積する。項目は、注文番号、顧客コード、利用証券会社コード、証券コード、注文単価、売買・成り、信用取引、注文時刻、注文期限、概算、約定済株、最終約定時刻、完了フラグの各データを含む。
「注文番号」は注文受付時点で採番する（後述のプロセス３０）。この番号は、例えば、証券会社コード＋通し番号である。
「注文単価」は注文時点での単価である。成り行きの場合は、現時点での価格を設定して送ってもらうものとする（後述のプロセス３０）。
「注文株数」は注文時点での発注株数である。注文すべてが約定し終わったかどうかは、後述のプロセス４０で約定株数の合計が注文株数に達したかどうかで判定する。
「売買・成り」は売り買い・成り行きの別を区分する情報であり、指値買い、指値売り、成り行き買い、成り行き売りの４通りがある。
「注文時刻」注文を発注した時刻である。「注文期限」は注文期限となる日付である。
「概算」は発注情報をもとにした成約した場合の金額である（但し、なくてもよい）。「約定済株数」は注文株数のうち、プロセス４０を通じて約定済みであることが判明した株数である。
「最終約定時刻」はプロセス４０を通じて、ＤＢ３００に反映した最後の約定データ（ＤＢ２００）の約定時刻である。
「完了フラグ」はプロセス４０を通じて、全株約定済みであることが判明した場合にたてられる識別情報である。

図７（ａ）（ｂ）に示した注文・売買速報ＤＢ７００は、データパターン１（後述のプロセス３１によるもの）とデータパターン２（後述のプロセス４１によるもの）とを格納するデータベースである。データパターン１の保有する項目は、注文番号、顧客コード、会社コード、注文単価、注文株数、売買・成り、信用取引、注文時刻、注文期限、概算、利用者ＨＮ、クラス１、ランク１である。データパターン２の保有する項目は、注文番号、顧客コード、会社コード、注文株数、信用取引、約定株数、約定時刻、最終約定時刻、完了フラグである。

図８に示したランキング用に用いる利用者評価ＤＢ４００は、利用者ごとの評価額のデータを蓄積する。保持する項目は、顧客コード、株式時価総額、キャッシュ計、キャッシュ出入り（ＣａｓｈＦｌｏｗ）、合計、信用取引の各データである。このＤＢは日時更新を行う。株式時価総額、キャッシュ計は当日分を計算して追加する。過去分のデータは別途ＤＢに保存する。信用取引については、同日に清算した場合の価値をキャッシュとして引きなおして計上する。
「株式時価総額」は当日分の保有株式に関する時価総額であり、プロセス６０を通じて計算され、株式分割時等の評価については修正が行われる
「キャッシュ計」は当日分の保有キャッシュ総額であり、株式の売買の対価として、キャッシュの増減がある場合にはそれを反映させる（後述のプロセス５１）。キャッシュの計算は約定ベースで行う。手数料等がかかっている場合にはそれも反映させる（後述のプロセス１３）。キャッシュの出入りが発生した場合にもそれを反映させる。信用取引については含み損益を計上する。その他商品の売買に関しても、キャッシュの出入りがあったものとして計算する（たとえば、国債の購入は、購入価格についてのキャッシュフローの出と扱う）。
「キャッシュフロー」は当日の株式売買以外におけるキャッシュの出入りである。対外（銀行等）との資金のやりとりのみを記載する。ただし、その他商品の売買結果もキャッシュフローと同様に扱う。また、株式売買に関する手数料はキャッシュフローとして扱うものとする。
「合計」は当日の株式時価総額とキャッシュ計の総額である。利用者のランキングを決定する場合の基礎資料はこの数字を用いる。
「信用取引」は前述のとおり当該利用者の利用している取引に信用取引が含まれているかどうかの情報である。

図９に示した利用者ＤＢ５００は、利用者ごとの情報を蓄積する。保持する項目は、顧客コード、ハンドルネーム、メールアドレス、パスワード、契約日、証券会社ＩＤ、信用取引、最終信用取引、クラス１、ランク１、クラス２、ランク２、手数料区分の各データを含む。これらのクラスやランクは契約当初は空欄としておく。
「利用者ハンドルネーム」は証券取引情報の公開時や掲示板での利用者の識別のために用いる利用者のハンドルネームである。本サービスの利用登録時に利用者が設定する。
「メールアドレス」は情報提供サービス業者が利用者との連絡に用いる利用者用のメールアドレスである。個人情報との隔離のために、証券会社から受領することはせず、利用者からメールアドレスを設定して与えることとする。「パスワード」は利用者が情報提供サーバ１２０にアクセスする際に用いる暗証番号（例えば複数桁の英数字）である。利用者はハンドルネームとパスワードを使って当サービスサーバにアクセスする。
「契約日」は証券会社と当初契約した日付である。「証券会社コード」は証券会社ごとのコードである。
「最終信用取引」は利用者が信用取引を利用していた最終日であり、ランキングを作成する際に、信用取引利用者とそれ以外を区別するために使う。
「クラス１」は最新のランキングにおける、クラスわけ、および同クラスの参加人数である。「ランク１」は最新のランキングにおける、利用者のランクである。「クラス２」は前回ランキングにおけるクラスわけおよび同クラスの参加人数であり、「ランク２」は前回ランキングにおける利用者のランクである。ランク２、クラス２はなくてもよい。
「手数料等区分」は利用区分による手数料区分である。利用者によって有料や無料を区分する区分１、およびランキングがわかる利用者を区分２を含む。追加サービス（特定の利用者の発注情報を追尾するサービス等）の利用者には別のクラスを用意するようにしてもよい。

図１０に示した掲示板ＤＢ６００は、掲示板データを蓄積するデータベースであり、顧客コード、利用者ハンドルネーム、会社コード、投稿タイトル、投稿内容、投稿時間の各データを含む。
「投稿タイトル」は株式銘柄ごとのの投稿につけるタイトルである。「投稿内容」は株式銘柄毎の投稿内容である。
「投稿時間」はその投稿が行われた日時である。

図３内に示した各プロセスの処理内容を説明する前に、本実施の形態における利用者端末１４０での表示画面例について説明する。

図１１は本サービスを利用する際に利用者が利用者ＩＤおよびパスワードを用いてログインを行った後に表示されるメインメニュー画面を示している。画面最上部には「メインメニュー」「ポートフォリオ」「ランキング」「マーケット概況」をそれぞれ選択するためのボタン２１１〜２１４が表示されている。図１１は「メインメニュー」が選択された状態を示している。画面の左上部の表示領域２２０内には、この利用者がお気に入りとして登録した銘柄群２２１およびこの利用者がお気に入りとして登録した他の利用者２２３が表示されている。他の利用者については、そのハンドルネームとランキング情報が対応づけて示されている。表示領域２２０内にはこれらの利用者の発注オンライン情報２２５も表示される。

図１１の下半分の表示領域２３０内には、登録した銘柄２２１の中から選択した銘柄を示すタイトル情報領域２３１とグラフ表示領域２３５とが設けられている。タイトル情報領域２３１には銘柄の他、この銘柄の発注情報や掲示板を見るためのボタンおよび昨日終値が表示される。グラフ表示領域２３５は第１軸（ここでは縦軸）上に当該銘柄の価格、第２軸（ここでは横軸）上に当日の時間をそれぞれ割り当てて、各注文の該当する両軸上の位置に可視指標を表示している。この例では、利用者の運用成績、売り買いの別、注文量、および約定の有無は、前記可視指標の異なる表示パラメータに対応させて識別表示している。すなわち、形状（□か○）はランキングの高低を示し、色（青か赤）は売り買いの別を示し、囲みの有無は約定の有無を示し、大きさは注文金額概算を示し、点滅は約定中を示している。また、グラフ表示領域２３５内には、当該銘柄の価格の推移を折れ線グラフで表示している。利用者のクラスは複数のクラスを対象としてもよいし、一方（例えば上位クラス）を対象としてもよい。さらには、利用者がクラスを選択できるようにしてもよい。

この例では、グラフ表示領域２３５内に表示する指標は、当該利用者がお気に入りに登録した他の利用者のみとしたが、当該銘柄について発注を行ったすべての利用者について表示するようにしてもよい。グラフ表示領域２３５はボタン２３９により拡大および縮小を行えるようになっている。

端末利用者がポインティング装置により特定の指標を指示すると、図１２に示すように、その指標の発注情報をテキストとして表示するウィンドウ２３８が表示される。図では明示しないが、指示された指標は、表示の色や輝度、ブリンク等による強調表示態様により他の指標と区別されるようにしてもよい。また、お知らせ等の他の情報が画面右上の領域２４０に表示される。

なお、例えばメインメニューのサブメニュー（図示せず）からお気に入りの変更を行うためのサブメニュー（図示せず）指示すると、図１３に示すような画面が開き、この画面上で、お気に入りの銘柄を追加したり削除したりすることができる。

図１１の画面において、メニュー項目２１２（ポートフォリオ）が選択されると、図１４に示すような当該利用者本人および他の利用者を含む任意の利用者の保有する証券についてのポートフォリオ情報等を表示する画面が表示される。ここでのポートフォリオ情報（表示領域２４１）には、保有する証券の銘柄や株数、株価情報が含まれる。ポートフォリオ情報とともに、運用状況（表示領域２４３）、ランキング情報（表示領域２４５）が同画面に表示される。図の例では図１１に示したお気に入りの銘柄と同じ銘柄を示しているが、実際には両者は同じとは限らない。

図１１の画面において、メニュー項目２１３（ランキング）が選択されると、図１５に示すような、運用成績に基づいて順位付けされた複数の利用者の運用成績情報が表示される。この画面では、利用者のお気に入りへの追加や削除を行うこともできる。

図１１の画面において、メニュー項目２１４（マーケット概況）が選択されると、図１６に示すように業種の階層的な分類情報の表示領域２５１と、選択された業種に属する銘柄の掲示板を選択するための表示領域２５２と、選択された業種についてのグラフ表示領域２３５を含むマーケット概況画面が表示される。グラフ表示領域２３５のデータは特定の銘柄ではなく、当該業種に属する銘柄すべてについてのものである。

図１７は特定の銘柄についての掲示板の投稿リスト画面を示している。この画面は、図１１の画面におけるタイトル情報領域２３１における「の掲示板をみる」を指示することにより開かれる。或いは、図１６の表示領域２５２から任意の銘柄の「掲示板」を指示することにより開かれる。

投稿リストは、投稿Ｎｏ、タイトル、投稿者ハンドルネーム、投稿者ランク／クラス／順位、投稿時間を含む。この掲示板に投稿できるのは本サービスの利用者であり、本サービスでの情報提供時に示される利用者のハンドルネームが投稿者ハンドルネームとして利用される。したがって、投稿の閲覧者はその投稿者がどのような発注を行いどのような成果を得ているかが分かるため、投稿の内容が虚偽かどうかがわかりやすい。そのため、投稿者も虚偽や不誠実な投稿を行うことが抑止される。

図１８は、図１７の投稿リスト中の任意の投稿を選択してその内容を表示させた画面である。この画面でも投稿者ランク／クラス／順位が表示されている。

図１９は銘柄毎の投稿作成画面を示している。この画面は、例えば図１１の画面におけるメインメニューから開くことができる。投稿者ＨＮの欄には自動的に投稿者のハンドルネームが入力され、利用者はこの画面で投稿者ＨＮを変更したり削除したりすることはできないようになっている。

以下、本実施の形態の動作について説明する。まず、情報提供サーバ１２０の各種データベース（ＤＢ）の更新に関する概略の処理を説明する。本実施の形態では、ＤＢの更新のタイミングとして、証券取引サーバ１１０から当日の注文データや約定データを受信したときにリアルタイムに実行するＤＢ更新処理（１）と、１日の取引終了後に実行するＤＢ更新処理（２）とを分けて説明する。

図２０に示したＤＢ更新処理（１）は１日の取引が行われている間動作する。証券取引サーバ１１０から注文データを受信すると（Ｓ１１，Ｙｅｓ）、この内容を注文ＤＢ３００に反映させるよう注文ＤＢ３００を更新する（Ｓ１２）。これとともに、速報ＤＢ７００に当該注文データを付加する更新を行う（Ｓ１３）。証券取引サーバ１１０から約定データを受信すると（Ｓ１４，Ｙｅｓ）、この内容を約定ＤＢ２００に反映させるよう約定ＤＢ２００を更新する（Ｓ１５）。これとともに、速報ＤＢ７００に当該約定データを付加する更新を行う（Ｓ１６）。

図２１に示したたＤＢ更新処理（２）は１日の取引終了後の所定の時点で起動される。まず、当日の約定データが蓄積された約定ＤＢ２００の内容を利用者毎保有残高ＤＢ１００に反映させる（Ｓ２１）。ついで、このＤＢ１００の更新結果を利用者評価ＤＢ４００に反映させるようＤＢ４００の更新を行う（Ｓ２２）。この利用者評価ＤＢ４００の内容に基づいて、当日の時点での利用者のランキングを決定する（Ｓ２３）。その具体例については後述する。その後、この決定された新たなランキングの内容を利用者評価ＤＢ４００の該当する項目（クラスやランク）に反映させ、かつ、変化があった利用者については利用者ＤＢ５００にもその変更内容を反映させる（Ｓ２４）。

以下、上記種々のデータベースを用いて行う本実施の形態における動作を定める具体的な各種プロセスについて説明する。

プロセス１０は、オンライン証券会社で管理している利用者ごとの保有している証券に関する売買データを、ＤＢ１００に反映させる当初売買データの投入プロセスである。当初売買データは、顧客コード、売買銘柄、売買価格、株数、現在価格を含むものである。このプロセス１０は、好ましくは他のプロセス（後述のプロセス５０等）との齟齬を避けるため、夜間バッチ処理とするようにしてもよい。「本日株価」は当プロセスにおいては前日終値を反映させる。証券会社からは、後述のプロセス１１で設定した顧客コードを添付してもらう。株式以外の取引情報（債権、ワラントなど）については、このプロセスにおいては無視する。

プロセス１１は、利用者が証券会社と契約した時点で証券会社が持っている利用者に関する情報のうち、ＤＢ４００とＤＢ５００に入力すべき項目を反映させるプロセスである。このデータ内容には、利用者のキャッシュの残高および、信用取引を利用している場合の現時点での含み損益の情報を含むものである。ＤＢ４００への利用者ＩＤはＤＢ５００に対するものと同じものを入力する。

プロセス１２はオンライン証券を通じて利用者が当日行った取引についての情報を本件情報提供業者のＤＢ１００に反映させる売買データ投入（当日分）プロセスであり、データの内容は利用者が当日に約定した証券に関する時価情報を含む。すなわちこのプロセスで、ＤＢ１００の「本日株価」（それにともない評価額）を書き換える。夜間バッチ処理を想定している。後述するプロセス５０で実行した売買データの追加が正しいかどうかの検証も行うので、プロセス５０実行後に実行する。プロセス１２で証券会社から受領するデータはＤＢ１００の各項目に該当するデータである。なお、証券会社から送られてくるデータは、証券コードごとにまとめて株数を記入したデータでない場合もありうる。その場合には、後述のプロセス５０と類似の方法で、「証券ごとにまとめた」データをＤＢ２００に反映させることになる。既存契約者についてこのプロセスはプロセス５０を経過して反映されたＤＢ１００に齟齬がないかを確認する（定期的に、例えば毎日）。

プロセス１３は、オンライン証券会社で預かっている資金についての当日分のデータをＤＢ４００に移転する、個人ごと資金移動などのデータ投入プロセスであり、データの内容は利用者のキャッシュの出入り、手数料、ランキングの対象以外の証券に関する売買情報を含む。この処理も夜間バッチで行うことが好ましい。後述するプロセス５１で実行したキャッシュの移動データを検証することも行えるとよいので、プロセス５１実行後に実行する。

また、プロセス５１とプロセス６０の結果との照合、および追加情報の反映を行うことができる。プロセス５１およびプロセス６０の結果との照合は、プロセス５１およびプロセス６０を通じて、株式に関する資金の出入りと、信用取引の評価額の増減が分かるはずなので、キャッシュ計（キャッシュと信用取引の評価額の合計額）の数値に誤差がないかを、確認する。国債、ワラント、投信、など、株式以外の商品の売買は、キャッシュの出入りと判断するので、追加情報として投入する。当日のキャッシュ計には増減後の数値を計上する。

プロセス２０は、オンライン証券会社で約定した利用者の取引のうち、当日分のデータをＤＢ２００に移転する売買データ当日分投入プロセスであり、データ内容は、利用者のＩＤ、売買銘柄、売買価格、約定時刻、株数、約定価格を含むものである。注文データとの関連を解決するのはプロセス５０に譲るので、ここでは約定が成立したという情報を蓄積するだけでよい。この約定データのＤＢ２００への移転は発注後にすみやかに行われることが好ましい。

プロセス３０はオンライン証券会社が受付けた利用者の注文情報のうち、当日分に関するデータをＤＢ３００に移転する注文データ当日分投入プロセスであり、データ内容は、利用者ＩＤ、注文銘柄、売買一成り行きの別、指値、株数、注文時刻を含むものである。この注文データのＤＢ３００への移転は発注後にすみやかに行われることが好ましい。

プロセス３１は、プロセス３０を通じて得た発注に関する情報を利用者に速報で通知するための情報を注文・売買速報ＤＢ７００へ移転するプロセスであり、利用者ＩＤ、注文銘柄、売買・成行きの別、指値、株数、注文時刻のほか、利用者の運用成績に関する情報を含むものである。通知する情報は、ＤＢ３００に蓄積する情報に、ＤＢ５００から得られるランキング情報を加えたものである。具体的には図７（ａ）に示すとおりである。

プロセス４０は、日中にＤＢ２００に受け入れた当日の約定データをＤＢ３００に反映させる約定データ反映プロセスであり、ＤＢ３００にある同一利用者ＩＤ、同一銘柄の注文データに対して、約定成立分について、約定株数、約定時間を追加記入し、すべて約定したものについては約定完了フラグを追加するものである。プロセス２０とプロセス３０の処理順序が逆になるケースにも対応できるように、処理済みのものにはフラグをたてていき、処理できなかったものは再度プロセス４０を実行するようにする。この処理は周期的な（１５秒置き程度）実行を想定している。その具体的な手順としては、次のとおりである。
・まずは、売買データ（ＤＢ２００）のうち、ＤＢ３００反映フラグの立っていないものを抽出する。
・同一利用者（利用者ＩＤ）で同一銘柄の注文データをピックアップする。
・信用取引か否かの同一性を確認する。
・注文データが買いデータであり、約定データの約定株数がプラスであれば、注文データの約定済み株数に、約定株数をプラスする。プラスする際には約定データの約定時刻を最終約定時刻に反映させる。
・プラスした結果、注文データの注文株数と一致した場合には、注文データの完了フラグに反映させる。
・プラスすることにより、約定データをＤＢ３００に反映した場合には、約定完了如何に関わらず、ＤＢ２００に「ＤＢ３００反映済みフラグ」を立てる。同時にプロセス４１を実行する。
・注文データが売りデータであり、約定データの約定株数がマイナスであれば、注文データの約定済み株数に約定株数を反映させる（マイナスする）。
・上記の際には約定データの約定時刻を最終約定時刻に反映させる。
・上記の結果、注文データの注文株数と一致した場合には、ＤＢ３００の注文データの完了フラグに反映させる。
・約定株数を反映させることにより、約定データをＤＢ３００に反映した場合には、約定完了如何に関わらず、ＤＢ２００に「ＤＢ３００反映済みフラグ」を立てる。同時にプロセス４１を実行する。
・上記処理ができなかった約定データについては、「ＤＢ３００反映済みフラグ」を立てずに次回処理にまわす。

プロセス４１は、プロセス４０で反映した利用者の約定に関する情報を利用者に速報で通知するためのＤＢ７００へ移転するプロセスである。この通知する情報は注文番号、利用者ＩＤ、約定銘柄、約定価格、約定時刻のほか、利用者の運用成績に関する情報を含むものである。具体的には図７（ｂ）に示すとおりである。

プロセス５０は、本実施の形態では一日の取引が終了した時点でＤＢ２００に蓄積した当日の約定データをＤＢ１００に反映させる売買データ追加プロセスである。このプロセス５０では、ＤＢ１００に同一利用者ＩＤ、同一銘柄の取引がある場合には、株数を増減させることでそのデータを書き換え、同一利用者ＩＤ、同一銘柄の取引がない場合には、新規データとして反映させる。具体的には、ＤＢ２００のデータごとに以下の手順を実行する。ＤＢ１００への反映のタイミングで結果が異なる可能性があるので、処理はＤＢ２００の約定時刻の順に行うものとする。
（ａ）ＤＢ１００に、当該取引と同じ「顧客コード」「会社コード」「信用取引（区分）」の取引が存在する場合、
・取引ＩＤとしてはＤＢ１００にあるものを引き続き利用する。
・購入総額としては、ＤＢ２００の購入単価×約定株数（＝購入価格）をＤＢ１００の購入総額に加える（約定株数は売りのときにはマイナスなので、特別の処理はいらない）
・株数はＤＢ１００の株数にＤＢ２００の約定株数をプラスする。（約定株数は売りのときにはマイナスなので、特別の処理はいらない）
・購入日付としてはＤＢ１００にあるものを引き続き利用する。
・当該プロセスの際、「株数」がゼロになった場合は、当該取引ＩＤは抹消する。
・当該プロセスの際、「株数」のプラス、マイナスが逆転した場合は、逆転した部分については次と同様の処理を行う。
（ｂ）ＤＢ１００に、当該取引と同じ「顧客コード」「会社コード」「信用取引（区分）」の取引が存在しない場合
・取引ＩＤとしてはＤＢ２００にある取引ＩＤを利用する。
・購入総額はＤＢ２００の購入単価×約定株数 を購入総額として計上する。
・株数としては、ＤＢ２００の約定株数（または、プラス、マイナスが逆転したケースは差し引き分）を計上する。
・購入日付には約定日（当日）を記入する。

プロセス５１は、売買データすなわち、ＤＢ２００に蓄積した当日の約定データに基づく、利用者の資金（キャッシュ）の増減をＤＢ４００に反映させるプロセスである。このプロセスでは、ＤＢ２００における利用者のＩＤが同一の取引に関する資金の増減をまとめてＤＢ４００に反映させる。
・現物取引の場合は、すべてのケースでＤＢ２００の「購入単価」×「約定株数」をＤＢ４００へ送付する。
・信用取引のケースでは、キャッシュデータは、前日比の信用取引の評価損益の増減、ということになる。これを、当業務においては（前日までの信用取引ポジションについての今日の終値での昨日比損益）＋（今日の新規信用取引ポジションについての今日の終値での昨日比損益）として計上することとする。
・前段はプロセス５１αとして、プロセス５０実行前に計算しておく。すなわち、プロセス５１αは、売買データのうちキャッシュ評価のＤＢ４００への反映プロセスであり、プロセス５１の補助的役割を果たすためにプロセス５０を実行するまえに、前日ベースのＤＢ１００にある「信用取引」分について本日評価額を反映し、評価額をＤＢ４００にキャッシュ情報として追加する。
・後段はプロセス５０実行時に、ＤＢ２００であらたに約定した信用取引についてのみ、本日の終値での損益評価を計算することで、算出するものとする。

プロセス６０は、１日の取引終了後に、ＤＢ１００に蓄積されているデータをもとにＤＢ４００を書き換える評価額データ更新プロセスである。すなわち、ＤＢ１００にあるデータから利用者ごとに保有している株式の時価を計算して当日の評価額としてＤＢ４００に追記するプロセスである。具体的には、プロセス１２を通じて反映した本日の株式評価額に基づき、個人ごと評価額データ（ＤＢ４００）を更新する。そのために、「株式時価総額（当日分）」の欄に、ＤＢ１００に計上されている現物の「評価額」の合計を記入する。

プロセス７０は、ＤＢ４００に保有している利用者ごとの評価額をもとに一定期間（たとえば１週間、１ヶ月等）の運用成績を計算し、同時に順位付けを行い、それをＤＢ５００に反映させるランキング更新プロセスである。具体的な手順は次のとおりである。
・当日の取引結果による新たなランキングを作成して、データを更新するために利用する。
・計算開始日のＤＢ４００の「合計額」を基準値として利用する。
・期間中の「キャッシュの出入り」は日々計算を実行する。期間中でキャッシュのプラスが最大になったときの金額に「基準値」を加えたものを、ランキングを計算する際の「分母」として採用する。分母はクラスわけにも利用する。クラス分けは「基準値」が所定の値（例えば５００万円）以上と未満に分類する。
・損益の計算

当日の「合計」額から「基準値」を引いた金額に「キャッシュの出入り累計」の差し引きを実行したものを「損益額」とする。
・ランキングの計算
「損益額＋分母」／「分母」（％）（「ここでは損益率」とよぶ）を計算して、ランキングつける。損益がなければ１００％となる。
・期間ランキング（１ヶ月ごと）を計算する。
・長期ランキング（年間ランキングなど）は「損益率」を掛け合わせていくことによって計算する。
・更新したランキングは利用者ＤＢ５００に反映させる。

以下、利用者端末１４０における画面の表示に関連したプロセスを説明する。

情報提供サーバ１２０が利用者端末１４０へ通信ネットワーク１３０経由で情報を提供する方法としては、次のような種々の形態が考えられる。

サーバから利用者端末へ提供するデータの形態としては、主として次の２つの形態が考えられる。その第１は、利用者端末で表示すべき画面のデータをＨＴＭＬ等のマークアップ言語で記述されたウェブページデータとして利用者端末に提供し、利用者端末ではこれをウェブブラウザを用いて表示するものである。第２は、画面を生成するための資料情報を利用者端末に提供し、利用者端末側でその資料情報から必要な情報を抽出して加工し表示データを生成するものである。前者は全利用者にほぼ共通の表示情報に適するが、個々の利用者で異なる表示情報の場合にはサーバ側の負荷が増加する。したがって、表示情報の内容によって両形態を使い分けるようにしてもよい。あるいは、いずれか一方のみの形態であってもよい。

また、情報を提供する契機に関しては次のような異なる形態が考えられる。

利用者端末１４０の利用者の指示操作に応じて要求された情報を提供する形態：例えば、当該利用者のお気に入りの銘柄についての当日の注文・売買データを提供する場合である。

利用者端末１４０から自動的に周期的に情報を要求し、これに応じて情報提供サーバ１２０が要求された情報を提供する形態：この情報は、例えば、注文・売買速報ＤＢ７００からの注文・売買速報データである。

すべての利用者端末に定期的に共通の情報を、いわゆるライブ型のインターネット放送によりすべての利用者端末に定期的に情報を提供する構成としてもよい。この場合、利用者端末１４０は当該利用者に必要なデータのみを取得するようデータを取捨選択する。

次に、利用者端末１４０において実行される主要なプロセスについて説明する。

プロセス８０（銘柄ごと、発注情報リアルタイム表示）
このプロセスは、図１１等に示した表示領域２３０に表示するデータの表示処理である。

利用者が選定した銘柄について、ＤＢ３００から抽出された当日の発注データと約定データを取得するとともに、注文・売買速報ＤＢ７００からの注文・売買速報データを取得し、当該銘柄についての発注・約定情報を選定して蓄積することを開始し、表示するプロセスである。そのためには、一例として次のような手順をとる。
１）まず、ＤＢ２００とＤＢ３００から、特定時間までに蓄積された当日の発注、約定情報を取り出して表示するとともに、
２）特定時間以降の情報については、注文・売買データ速報データを受けて、現在の発注・約定情報を表示する。速報データで蓄積しているもので同じ注文番号のデータがあれば、上書きする。

このようにプロセスを２つにわけることで、同一のデータを何度も送信することによってかかるサーバの負荷を軽減することができる。希望する銘柄のデータの抽出はサーバ側で行ってもよいし、利用者端末側で行ってもよい。例えば、ステップ１）については銘柄のデータの選別をサーバ側で行い、ステップ２）については利用者端末側で行う、というように処理過程で実行側を異ならせてもよい。

グラフ表示領域２３５における利用者対応の可視指標の表示としては、前述したように、利用者の運用成績、売り買いの別、注文量、および約定の有無を、可視指標の異なる表示パラメータに対応させて識別表示する。また、グラフ表示領域２３５内に、当該銘柄の価格の推移を折れ線グラフで表示する。

プロセス８１（ポートフォリオ作成画面）
このプロセスは、利用者が前日のマーケット終了時点で保有している株式の残高を表示する画面（図１４の表示領域２４１，２４３，２４５）を作成するプロセスである。具体的には、利用者端末からサーバに対して、利用者本人の顧客コードに基づいてＤＢ１００およびＤＢ４００に蓄積されたデータのなかから当該利用者の顧客コードに該当するデータを抽出し送信することを要求し、利用者端末がこのデータを受信して図１４の形式に加工して表示する。

プロセス８２（お気に入り銘柄選択画面）
このプロセスは、利用者が複数の株式の銘柄を選定することができる画面（図１３の表示領域）を作成するプロセスである。選定された株式銘柄の情報は利用者側のアプリケーションに反映されて蓄積される。利用者はこの選定した銘柄についてＤＢ２００とＤＢ３００から抽出した当日の発注情報や、約定情報、また、注文・売買速報データベースから抽出した情報を参照することができる。

プロセス９０（お気に入り利用者ポートフォリオ表示画面）
このプロセスは利用者が別の利用者（たとえば運用成績のよい利用者）のポートフォリオを参照できるプロセスである。このプロセスでは、図１１の他の利用者２２３のポートフォリオをＤＢ１００およびＤＢ４００から抽出されたデータに基づいて表示させる。画面としては図１４に示したとおりである。このプロセスでは、選定した別の利用者のポートフォリオをＤＢ１００およびＤＢ４００から抽出し、当日の発注、約定情報をＤＢ２００とＤＢ３００から抽出するとともに、注文・売買データサーバから送信されてくる速報データの中から該当するデータを抽出して表示させる。前日までの対応利用者のポートフォリオ情報については、プロセス８１と同様の方法でピックアップすることができるものとする。また、対応利用者の当日の発注、約定情報だけをピックアップして表示していく機能も有する。銘柄ごとの発注・約定情報と同様に、対応利用者の発注・約定情報がリアルタイムで表示される機能を有することが好ましい。

プロセス９１（お気に入り利用者発注・売買状況データ）
このプロセスは、図１１の表示領域２２５の表示プロセスである。利用者が登録した他の利用者（図１１の２２３）について、ＤＢ２００、ＤＢ３００から抽出された発注情報や、約定情報、また、速報データに基づいて表示データを生成する。

プロセス９８（掲示板書き込み・表示画面）
このプロセスは、利用者が利用する銘柄ごとの掲示板に書き込みを行ったり、参照することができる画面（図１７、図１８、図１９）を作成するプロセスである。プロセス９８では、利用者は銘柄ごとに設置された掲示板に書き込みを行うことができる。掲示板を閲覧する際には、それがどの利用者によってなされており、その利用者の運用成績がどのような状態であるかも参照することができるように表示するプロセスである。利用者は、ハンドルネームをつけて投稿するが、当該ハンドルネームには、当該利用者のランキング情報がリンクされ、自動的に投稿内容に付加される。

なお、図１５に示すような利用者の成績に基づくランキング情報を表示する画面データは、サーバから利用者のデータを受信して、利用者端末で表示画像を生成してもよいし、サーバがＤＢ５００の内容に基づいて生成したウェブページデータとして提供し、利用者端末においてそのままブラウザで表示するようにしてもよい。また、両処理が混在した形態であってもよい。図１６のマーケット概況画面の表示領域２５１，２５２についても同様である。表示領域２３０についても、図１１と同様、利用者端末側で表示画面を生成してもよいし、ウェブページデータとしてサーバ側から提供してもよい。

その他、利用者の登録・解約のための画面、利用者情報変更のための画面、手数料区分や、パスワードを変更する場合に利用する画面等については、特に詳述しない。

プロセス９９（利用者自身の発注情報自動作成）
最後に、利用者端末において利用者が選定した別の利用者（たとえば運用成績のよい利用者）の発注情報を受け取るたびに、その利用者の発注内容に当該取引に所定の条件を付加して得られる発注内容で当該端末装置の利用者の名義によるオンライン発注を行う処理について説明する。

「所定の条件」とは利用者自身が定めた条件である。図示しないが、例えば図１１の画面のメインメニューからサブメニューとして選択することによりこのプロセスの設定操作が行えるようにすることができる。このような設定操作では、利用者は、事前に特定の利用者を登録するとともに、どういう条件の発注をするか決めておく。

図２２に利用者端末１４０において実行される発注情報自動作成処理の概略の流れを示す。速報データに基づいて、当該利用者が指定した他の利用者の発注情報を受信したら（Ｓ３１，Ｙｅｓ）、この発注に対して追従可能かどうかを判断する（Ｓ３２）。例えば、発注が「売り」でその銘柄を保有していないような場合を「追従不能」と判断する。「追従可能」と判断されたら、その発注内容に所定の条件を付加する（Ｓ３３）。この条件の例は例えば次のようなものである。

例１：特定の利用者が発注したデータと同じ銘柄について、概算額は一定額（たとえば１００万円）になるようにして、発注情報を作成する。

例２：特定の利用者が発注したデータと同じ銘柄について、発注額は、買いなら１単位高く、売りなら１単位安くする発注情報を作成する。

このように作成された発注情報を端末の表示画面に表示し、この端末の利用者の指示を待ち、発注ＯＫの指示があれば（Ｓ３４，Ｙｅｓ）、この発注情報に基づくオンライン発注を実行する（Ｓ３５）。利用者はオンライン発注の前に、発注情報を確認して、この発注をやめることもできる。また、確認した発注情報に変更を施して発注できるようにしてもよい。

以上説明した実施の形態によれば、利用者はプロセス８０により、利用者の登録した銘柄にかかる発注、約定の状況について、発注している利用者の運用成績を参考にしながら時々刻々確認することができる。プロセス９１によれば、利用者の登録した別の利用者の発注、約定の情報について、当該利用者の運用成績を参考にしながら時々刻々確認することができる。プロセス９９によれば、利用者の選択した別の利用者の発注情報を確認したうえで、同様の銘柄についての発注をタイムリーに行うことができる。プロセス９８によれば、利用者は、当該掲示板に書き込みをしている利用者がどういう運用成績をしているか、また、どういうポートフォリオを持っているかを参考にすることができる。

以上、本発明の好適な実施の形態について説明したが、本発明の範囲を逸脱することなく、上記で言及した以外にも種々の変形、変更を行うことが可能である。

例えば、上述した各種のＤＢやその蓄積する項目はあくまで説明のための一例であり、ＤＢの結合や分割も可能である。各種の処理も例示であり、本発明は上記の具体的な処理に限定されるものではない。

利用者端末１４０は通信ネットワーク１３０経由で情報を得る例について説明したが、これに代えてまたはこれに加えて、衛星や地上波を利用したデータ放送受信機能を備える場合にはデータ放送により情報を得るようにすることも可能である。これにより、利用者側のシステム（クライアント側）からリクエストするのではなく、必要な情報を情報提供者側（サーバ側）から常に送付し続け、利用者側のシステムで必要な情報を選定して表示することができる。

本発明が適用された証券取引情報提供システムの概略の構成をす図である。 図１内に示した情報提供サーバの概略ハードウェア構成例を示す図である。 本発明の実施の形態における発注情報や情報提供のための各種情報を構成する各種データの流れを説明するフローチャートである。 本発明の実施の形態における利用者毎保有残高ＤＢ１００の構成例を示す図である。 本発明の実施の形態における売買データ（当日分）ＤＢ２００の構成例を示す図である。 本発明の実施の形態における取引注文ＤＢ３００の構成例を示す図である。 本発明の実施の形態における注文・売買速報ＤＢ７００の構成例を示す図である。 本発明の実施の形態におけるランキング用ポートフォリオ（個人毎評価額データ）ＤＢ４００の構成例を示す図である。 本発明の実施の形態における利用者ＤＢ５００の構成例を示す図である。 掲示板ＤＢ６００の構成例を示す図である。 本発明の情報提供サービスを利用する際のメインメニュー画面を示す図である。 図１１のメインメニュー画面の変化例を示す図である。 本発明の実施の形態におけるお気に入りの銘柄を追加したり削除したりするための画面を示す図である。 本発明の実施の形態における利用者本人および他の利用者を含む任意の利用者の保有する証券についてのポートフォリオ情報等を表示する画面を示す図である。 運用成績に基づいて順位付けされた複数の利用者の運用成績情報を表示する画面を示す図である。 本発明の実施の形態におけるマーケット概況画面を示す図である。 本発明の実施の形態における特定の銘柄についての掲示板の投稿リスト画面を示す図である。 図１７の投稿リスト中の任意の投稿を選択してその内容を表示させた画面である。 本発明の実施の形態における銘柄毎の投稿作成画面を示す図である。 本発明の実施の形態における情報提供サーバでのＤＢ更新処理（１）を示すフローチャートである。 本発明の実施の形態における情報提供サーバでのＤＢ更新処理（２）を示すフローチャートである。 本発明の実施の形態における利用者端末において実行される発注情報自動作成処理の概略の流れを示すフローチャートである。

符号の説明

１０９…通信部、１００…利用者毎保有残高ＤＢ、１１０…証券取引サーバ、１２０…情報提供サーバ、１３０…通信ネットワーク、１４０…利用者端末、２００…約定ＤＢ、３００…取引注文ＤＢ、４００…利用者評価ＤＢ、５００…利用者ＤＢ、６００…掲示板ＤＢ、７００…注文・売買速報ＤＢ

Claims (9)

1. 複数の利用者の情報を蓄積した利用者データベースと、
   各利用者によるオンライン証券取引に関する少なくとも発注・約定の情報を蓄積するデータベースと、
   利用者毎の運用成績を求める運用成績算出手段と、
   利用者毎の運用成績を蓄積するデータベースと、
   利用者の発注・約定の情報を当該利用者の運用成績と関連付けた証券取引情報を通信または放送を介して利用者に提供する送信手段と
   を備えたことを特徴とする証券取引情報提供システム。
2. 前記運用成績算出手段は、前記運用成績として利用者毎に収益率の計算を行い、利用者の順位付けを行い、この順位情報を前記証券取引情報に含めたことを特徴とする請求項１記載の証券取引情報提供システム。
3. 前記証券取引情報として、利用者端末上でグラフィック表示するための表示情報を作成する表示情報生成手段を備え、
   前記表示情報は、銘柄毎に、少なくとも運用成績の良好な利用者がその銘柄について当日に発注を行った売り買いの別、注文量、および約定の有無を反映させた、利用者単位の可視指標を含むことを特徴とする請求項１または２に記載の証券取引情報提供システム。
4. 表示領域内の第１軸上に当該銘柄の価格、前記第１軸と直角方向の第２軸上に時刻をそれぞれ割り当てて、各注文の該当する両軸上の位置に前記可視指標を表示させることを特徴とする請求項３記載の証券取引情報提供システム。
5. 前記利用者の売り買いの別、注文量、および約定の有無は、前記可視指標の異なる表示パラメータに対応させて識別表示することを特徴とする請求項３または４記載の証券取引情報提供システム。
6. 当該銘柄について注文を行った利用者について、前記可視指標をその運用成績の上位者と他の者とで区別して表示することを特徴とする請求項５記載の証券取引情報提供システム。
7. 前記第１軸および第２軸上で、前記可視指標の表示とともに、当該銘柄の価格の推移をグラフ表示することを特徴とする請求項３〜６のいずれかに記載の証券取引情報提供システム。
8. 利用者が証券銘柄ごとに書き込みを行いこの書き込まれた情報を他の利用者が参照することができる掲示板手段を備え、前記掲示板手段は、各投稿について、その投稿を行った利用者の運用成績情報を投稿情報と併せて掲示することを特徴とする請求項１〜６のいずれか記載の証券取引情報提供システム。
9. ネットワークとの間で通信を行う機能を備えた端末装置において実行される証券取引発注プログラムであって、
   証券取引を行っている複数の利用者の少なくとも発注情報をその当該利用者の運用成績と関連付けた証券取引情報を、通信または放送を介してほぼリアルタイムに受信して蓄積するステップと、
   この蓄積された証券取引情報として、指定された特定の利用者の発注情報を受信したとき、その利用者の発注内容に当該取引に所定の条件を付加して得られる発注内容で当該端末装置の利用者の名義によるオンライン発注を行うステップと
   を実行する証券発注プログラム。