JP6516707B2 - リクエスト受付サーバ及びリクエストの受付方法 - Google Patents

Description

本発明は、特に証券会社等のシステムにおいて、第三者が作成したプログラムから発信された売買注文の発注や株価情報の配信などのリクエストを受け付けるのに好適な、ネットワークを介して接続された端末から発信されたリクエストの受付けの可否を判断するリクエスト受付サーバ及びリクエストの受付方法に関するものである。

インターネット経由での株式の売買注文の発注や株価情報の配信が一般的となっているが、証券会社が顧客からインターネット経由で株式の売買注文の発注等のリクエストを受け付ける手段としては、図１の（１）に示したように、顧客がＰＣ（パーソナルコンピュータ）やスマートフォンなどの端末から、Ｗｅｂブラウザを用いて証券会社のＷｅｂページにアクセスして注文データ等を入力する方式や、図１の（２）に示したように、顧客がそれらの端末から、証券会社が提供する専用のアプリケーションプログラムを用いて証券会社システムにアクセスする方式（例えば、非特許文献１参照）が採用されることが多い。

Ｗｅｂブラウザの機能による制約を受ける図１の（１）の方式に比べて、図１の（２）の方式によると設計の自由度が高くなるので、証券会社が提供する専用のアプリケーションプログラムには多様な機能が備えられ、主に投資の中・上級者に用いられている。さらに上級者になると、自らの投資指針等をモデル化した専用の取引プログラムを作成したり、投資助言業者等が作成した専用の取引プログラムを用いたりして、これらの取引プログラムと証券会社が提供する専用のアプリケーションプログラムとの間でデータを受け渡し、自動売買等を行っているケースも珍しくない。

このように証券会社が提供するものとは異なる取引プログラムを用いている顧客への利便性を考慮すると、図１の（３）に示したように、証券会社が提供する専用のアプリケーションプログラムを介することなく、顧客や顧客の投資助言者の投資指針等に合わせて作成された取引プログラムを証券会社のシステムに直接接続できることが好ましい。そうしたニーズに応えるために、出願人は接続のためのＡＰＩ（アプリケーション・プログラミング・インターフェイス）を投資助言業者等に提供するサービスを行っている（非特許文献２参照）。

図１の（２）や（３）の方式を採用すると、高度な機能が備えられる結果として、売買注文の発注が自動化されて注文の発注回数や訂正回数が増加したり、株価情報等の更新頻度が高くなったりすることが通常であるため、証券会社システムにかかる負荷が増大しやすくなるという問題が生じる。こうした問題に対して、例えば、株価情報の配信における負荷を軽減する方策としては、株価の更新が必要な銘柄をあらかじめサーバに登録しておき、端末から随時更新のリクエストを受け付けるのではなく、その銘柄に変動があった際に端末に通知することで、サーバと端末間の通信量を削減する発明が開示されている（特許文献１参照）。

特開２００２−１０８７４６号公報

カブドットコム証券「ｋａｂｕＳＴＡＴＩＯＮ」、〔ｏｎｌｉｎｅ〕、〔平成２６年９月１８日検索〕、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｋａｂｕ．ｃｏｍ／ｋａｂｕｓｔａｔｉｏｎ／ｄｅｆａｕｌｔ．ｈｔｍｌ＞ カブドットコム証券・プレスリリース「主要ネット証券初、機関投資家並のシステムトレード環境を個人投資家向けに提供」、〔ｏｎｌｉｎｅ〕、〔平成２６年９月１８日検索〕、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｋａｂｕ．ｃｏｍ／ｃｏｍｐａｎｙ／ｐｒｅｓｓｒｅｌｅａｓｅ／２０１２／０４１９＿００１．ｈｔｍｌ＞

特許文献１に開示されている発明は、通信回線の容量が十分でないことを前提として、端末と株価を配信するサーバの間の通信回線にかかる負荷を削減することを目的とするものであるが、近年のブロードバンド化の進展によって、こうした通信回線への負荷に関する問題は大きく改善されることとなっている。むしろこうした環境を前提にした場合に考えなければならないのは、大量のアクセスが集中することによって証券会社システムがダウンしてしまうリスクへの対応策である。

この点について、図１の（２）の方式であれば、証券会社が提供する専用のアプリケーションプログラムに何らかの制限をかけておくことによって、証券会社システムへのアクセスをコントロールすることが可能である。ところが、図１の（３）の方式による場合、取引プログラムの設計は顧客自身や投資助言業者等に委ねられることになるので、悪意のあるユーザやプログラムによって、証券会社システムに大量アクセスが発生するリスクを回避するための仕組みが求められることになる。

本発明は、このような課題に対応するためになされたものであり、特に証券会社等のシステムにおいて、第三者が作成したプログラムから発信された売買注文の発注や株価情報の配信などのリクエストを受け付けるのに好適な、ネットワークを介して接続された端末から発信されたリクエストの受付けの可否を判断するリクエスト受付サーバ及びリクエストの受付方法を提供することを目的とするものである。

このような課題を解決する本発明は、ネットワークを介して接続された端末から発信された金融商品の売買注文のリクエストの受付けの可否を判断するリクエスト受付サーバであって、前記端末において動作する、金融商品の売買注文を受け付ける注文受付者と異なる事業者により提供されたプログラムによって発信された、前記売買注文の注文者であるユーザの識別情報及び前記プログラムの識別情報を含む前記リクエスト受付サーバへの接続を要求するリクエストを受信する第１の受信手段と、前記リクエストに含まれるユーザの識別情報から、前記ユーザがあらかじめ登録されたユーザであるかを認証する第１の認証手段と、前記リクエストに含まれるプログラムの識別情報から、前記プログラムが前記注文受付者によってリクエストの受付けが許可されたプログラムであるかを認証する第２の認証手段と、少なくとも、前記第１の認証手段によって前記ユーザがあらかじめ登録されたユーザであることが認証され、かつ前記第２の認証手段によって前記プログラムが前記注文受付者によってリクエストの受付けが許可されたプログムであることが認証されることを条件として、前記端末との接続処理を実行してセッションを確立する確立手段と、前記端末とのセッションが確立されている間に、前記端末において動作する前記プログラムによって発信された、金融商品の売買注文のリクエストを受信する第２の受信手段と、前記セッションを確立する際に認証されたユーザの識別情報から特定されるユーザとの所定の期間内における通信回数が、特定のユーザによる大量アクセスと判断する基準となる所定の制限値を超過していないかを判断する判断手段と、少なくとも、前記判断手段によって前記ユーザとの通信回数が所定の制限値を超過していないと判断されることを条件として、前記リクエストを受け付けて前記売買注文を発注するための所定の処理を実行する第１の実行手段と、前記判断手段によって前記ユーザとの通信回数が所定の制限値を超過していると判断された場合には、前記端末との間で確立された前記セッションを切断する処理を実行する第２の実行手段と、を備えることを特徴とするリクエスト受付サーバである。

本発明では、売買注文の発注や訂正、株価情報の配信などのリクエストをサーバで受け付ける際に、リクエストを発信したユーザを認証し、ユーザ毎の通信量を制限することによって、特定のユーザによる大量アクセスのリスクを回避するとともに、リクエストの発信に用いられた端末で動作するプログラムの認証処理も行うことによって、悪意のあるプログラムによる不正アクセスへの対応も可能にしている。

尚、本発明におけるプログラムの識別情報については、どのような区分を基準にしてプログラムを識別するかは特に限定されるものではなく、例えば、プログラムの種別やバージョン、プログラムの作成者毎に固有の識別キー等を割り当てて、この識別キーを照合してプログラムの認証処理を行うこととすればよい。

また、本発明において、判断手段による判断の基準になる所定の制限値の対象となる通信量には、リクエストを受信した回数や送受信したデータ量を用いることとすればよいが、これらの例に限定されるものではなく、例えば、株価情報の配信であれば株価を配信した銘柄の数を対象にすることもできる。所定の制限値には、通信量の絶対値のみでなく、基準となる時間も設定される（例えば、「１分以内に〜回」等）ことが通常である。

また、本発明において、実行手段が実行する所定の処理には、リクエストに指定された売買注文の発注や株価情報の配信などを実行する処理のみでなく、それらの処理の実行を他のアプリケーションサーバに命令する処理なども含まれる。

本発明は、端末から受信したリクエストにより発生した通信の通信ログをユーザ毎に記憶する記憶手段を備えていて、前記判断手段は、前記記憶手段に記憶された通信ログから特定される所定の時間内における前記ユーザとの通信回数が所定の制限値を超過していないかを判断することを特徴とすることもできる。

このように通信回数を基準に通信量を制限する構成は、簡易な方法によってユーザ毎の通信量を制限するのに好適である。

本発明は、前記セッションを確立する際に認証されたプログラムの識別情報から特定されるプログラムによって発信されたリクエストにより発生した通信量が、特定のプログラムによる大量アクセスと判断する基準となる所定の制限値を超過していないかを判断する第２の判断手段を備えていて、前記第１の実行手段は、さらに、前記第２の判断手段で前記プログラムによって発信されたリクエストにより発生した通信量が所定の閾値を超過していないと判断されることを条件として、前記売買注文を発注するための所定の処理を実行し、前記第２の実行手段は、前記第２の判断手段によって前記プログラムによって発信されたリクエストにより発生した通信量が所定の閾値を超過していると判断された場合には、前記端末との間で確立された前記セッションを切断する処理を実行することを特徴としてもよい。

このように構成すると、ユーザ毎の通信量のみでなく、プログラム毎の通信量の制限も可能になるので、悪意のある特定のプログラムを用いて大量アクセスが行われているようなケースにおいて、そのプログラムからのアクセスを制限することも可能になる。

本発明は、本発明に係るリクエスト受付サーバによって実行されるリクエストの受付方法として特定することもできる。

本発明に係るリクエストの受付方法は、端末から発信された金融商品の売買注文のリクエストの受付けの可否を判断するリクエストの受付方法であって、前記端末とネットワークを介して接続されたサーバが、前記端末において動作する、金融商品の売買注文を受け付ける注文受付者と異なる事業者により提供されたプログラムによって発信された、前記売買注文の注文者であるユーザの識別情報及び前記プログラムの識別情報を含む前記サーバへの接続を要求するリクエストを受信する第１の受信ステップと、前記サーバが、前記リクエストに含まれるユーザの識別情報から、前記ユーザがあらかじめ登録されたユーザであるかを認証する第１の認証ステップと、前記サーバが、前記リクエストに含まれるプログラムの識別情報から、前記プログラムが前記注文受付者によってリクエストの受付けが許可されたプログラムであるかを認証する第２の認証ステップと、前記サーバが、少なくとも、前記第１の認証ステップで前記ユーザがあらかじめ登録されたユーザであることが認証され、かつ前記第２の認証ステップで前記プログラムが前記注文受付者によってリクエストの受付けが許可されたプログムであることが認証されることを条件として、前記端末との接続処理を実行してセッションを確立する確立ステップと、前記サーバが、前記端末とのセッションが確立されている間に、前記端末において動作する前記プログラムによって発信された、金融商品の売買注文のリクエストを受信する第２の受信ステップと、前記サーバが、前記セッションを確立する際に認証されたユーザの識別情報から特定されるユーザとの所定の期間内における通信回数が、特定のユーザによる大量アクセスと判断する基準となる所定の制限値を超過していないかを判断する判断ステップと、前記サーバが、少なくとも、前記判断ステップで前記ユーザとの通信回数が所定の制限値を超過していないと判断されることを条件として、前記リクエストを受け付けて前記売買注文を発注するための所定の処理を実行する第１の実行ステップと、前記サーバが、前記判断ステップで前記ユーザとの通信回数が所定の制限値を超過していると判断された場合には、前記端末との間で確立された前記セッションを切断する処理を実行する第２の実行ステップと、を有することを特徴とするリクエストの受付方法である。

また、本発明に係るリクエストの受付方法は、先に説明した各々の構成に対応するリクエスト受付サーバによって実行されるリクエストの受付方法として特定することもできる。

本発明によると、第三者が作成したプログラムから発信されたリクエストをサーバで受け付ける際に、ユーザ毎の通信量の制限による大量アクセスへの対応や、悪意のあるプログラムによる不正アクセスへの対応が可能になるので、顧客や投資助言業者等が各々の投資指針をモデル化して作成したプログラムによって自動売買等のリクエストを受け付ける証券会社のサーバに、特に好適である。

証券会社のサーバにおいて、第三者が作成したプログラムから発信されたリクエストの受付けが可能になれば、投資助言業者等にとっては、自らが証券会社のようなシステム投資コスト（取引所や情報ベンダーとの契約、システムインフラの維持等）を負担することなく、自らの投資指針をモデル化したプログラムを配布することのみによって、顧客に売買注文の発注や株価情報の提供に関する固有のサービスを提供することが可能になる。証券会社にとっても、自らが投資助言のノウハウを持たない場合であっても、自社のシステムに売買注文等を誘導できるというメリットが生じることになる。

証券会社システムにおいて、売買注文の発注等のリクエストを受け付ける３つの方式を示す図である。 本発明に係るリクエスト受付サーバの実施形態の概要を示す図である。 本発明に係るリクエスト受付サーバの構成の一例を示すブロック図である。 本発明に係るリクエスト受付サーバによる認証処理と流量制限の概要を示す図である。 本発明に係るリクエスト受付サーバの処理フローを示す第１のフローチャートである。 本発明に係るリクエスト受付サーバの処理フローを示す第２のフローチャートである。

本発明を実施するための形態について、図面を用いて以下に詳細に説明する。尚、以下の説明では、本発明に係るリクエスト受付サーバを証券会社の売買注文等のリクエストを受け付けるシステムに適用する例について説明するが、ここに示しているのは本発明の実施形態の一例であって、本発明はかかる実施形態に限定されるものではない。

図１に示した、証券会社システムにおいて売買注文の発注等のリクエストを受け付ける３つの方式については、背景技術として既に説明したとおりであるが、本発明に係るリクエスト受付サーバは、図１の（３）に示したＡＰＩを用いる方式が前提となるものである。

図２は、本発明に係るリクエスト受付サーバの実施形態の一例を示したものである。この例の証券会社システムは、図１に示した（１）と（３）の方式に対応しており、証券会社のＷｅｂページにアクセスして取引等を行う顧客は、ＰＣやスマートフォン等の顧客端末からＷｅｂブラウザを用いてインターネット経由で証券会社システムのＷｅｂサーバに接続して、証券会社のＷｅｂページに必要な情報を入力して株式等の売買注文を発注したり、Ｗｅｂブラウザで開いた画面にＷｅｂサーバから配信された株価情報を出力して株価を確認したりする。

尚、証券会社システムにおいて、Ｗｅｂサーバは顧客端末に備えられるＷｅｂブラウザと交信して、主に顧客端末との情報の送受信に関する処理を行うサーバであり、株式等の売買注文の取引所システムへの発注や訂正、売買注文の約定等の情報の顧客・注文情報管理データベースへの書込み、株価情報を配信するための情報系データベースに格納された株価等の時価情報の取得などに係る処理は、各々の機能に対応するアプリケーションサーバが実行する構成となっている。

一方、顧客自身や投資助言業者等の投資指針に基づいて独自に作成された取引プログラムを用いて取引等を行う顧客は、ＰＣやスマートフォン等の顧客端末から取引プログラムを用いてインターネット経由で証券会社システムに接続するが、この取引プログラムは認証方法の違いなどの理由から、ＷｅｂサーバではなくＡＰＩサーバに接続される。そのため、証券会社は取引プログラムの作成者に対して、ＡＰＩサーバに接続するための仕様を公開することが必要になる。

顧客端末で動作する取引プログラムは、Ｗｅｂブラウザの機能の制約を受けることなく自由に設計することができるため、顧客や投資助言業者は自らの投資指針等をモデル化した取引プログラムを作成、これを用いて顧客端末から証券会社のＡＰＩサーバに接続して、株式の売買注文の発注や訂正、株価情報の配信等のリクエストを送信する。リクエストを受け付けたＡＰＩサーバでは、リクエストの受付けの可否を判断した上で、受付けが可能と判断される場合はリクエストによって特定される処理を所定のアプリケーションサーバに実行させる。

ＡＰＩサーバでリクエストの受付けの可否を判断する際には、顧客の認証処理と顧客毎の流量制限の確認、さらに取引プログラムの認証処理を行う。あわせて、Ｗｅｂサーバで受付けの可否を判断する場合と同様に、預かり資産残高等から取引可能額の確認等を行うこととしてもよい。このような特徴を備える本発明は、顧客毎の流量制限の確認と取引プログラムの認証処理によって、同じ顧客が頻繁に売買注文の発注や訂正、株価情報の取得を繰り返した場合や、証券会社があらかじめ承認していない取引プログラムを用いたアクセスがあった場合には、ＡＰＩサーバにおいてリクエストの受付けを拒否することによって、大量アクセスや不正アクセスに対応できる構成となっている。

図３は、本発明に係るリクエスト受付サーバの構成の一例を示している。図３において、本発明に係るリクエスト受付サーバは、証券会社サーバ１０の一部の機能（主としてアクセス制御部１１）に対応する。

証券会社サーバ１０は、インターネットに接続されたサーバコンピュータであって、ＣＰＵ、メインメモリ、ＨＤＤやＳＳＤ等の補助記憶装置が備えられたコンピュータであって、補助記憶装置に格納されたプログラムがメインメモリに読み出され、ＣＰＵで演算処理を実行することによって、所定の機能が実現される。

証券会社サーバ１０を構成するコンピュータの物理的な構成は特に限定されるものではなく、図３を用いて説明する機能以外の他の機能が同一のコンピュータに備えられるものであってもよい。本発明に必要な各々の機能は、複数のコンピュータを用いて実現されるものであってもよいし、単独のコンピュータによって実現されるものであってもよい。

証券会社サーバ１０のアクセス制御部１１、注文処理部１４、情報配信処理部１５は、いずれも機能的に特定されるものであって、ＨＤＤやＳＳＤ等の補助記憶装置に格納された各部の機能に対応するプログラムがメインメモリに読み出され、ＣＰＵで演算処理を実行することによって、各部に対応する機能が実現される。

証券会社サーバ１０の認証情報記憶部１２、通信ログ記憶部１３、顧客・注文情報管理ＤＢ１６、情報系ＤＢ１７には、それぞれＨＤＤやＳＳＤ等の補助記憶装置の所定の記憶領域が割り当てられる。これらの記憶領域は物理的に一台のコンピュータに設けられることを要件とするものではなく、データベースサーバ等を構成するコンピュータなどの他のコンピュータや複数のコンピュータに設けられるものであってもよい。

顧客端末２０には、インターネットに接続可能なＰＣやスマートフォン、タブレット型コンピュータなどのネットワーク端末が用いられる。これらの端末には、ＣＰＵ、メインメモリ、ＨＤＤやＳＳＤ等の補助記憶装置が備えられていて、補助記憶装置に格納されたプログラムがメインメモリに読み出され、ＣＰＵで演算処理を実行することによって、所定の機能が実現される。

顧客端末２０のＷｅｂブラウザ２１、取引プログラム２２は、ＨＤＤやＳＳＤ等の補助記憶装置に格納され、メインメモリに読み出されてＣＰＵで演算処理を実行することによって、各々に対応する処理が実行される。

取引所システム３０は、株式の売買取引の執行等を行うためのコンピュータシステムであり、その構成は特に限定されるものではないが、証券会社サーバ１０から売買注文を受け付けて、売買取引の執行等に必要な処理を実行する。

以上の構成を前提として、図５及び図６のフローチャートに従って、本発明に係るリクエスト受付サーバの処理フローについて説明する。

証券会社に口座を開設して、インターネットを介して株式の売買取引等を行う顧客は、顧客端末２０で、証券会社サーバ１０との取引に用いるために作成した取引プログラム２２を起動して、証券会社サーバ１０への接続を要求するリクエストを発信する。発信されるリクエストには、証券会社で顧客を識別するために割り当てられた顧客ＩＤと、証券会社であらかじめリクエストの受付けを許可する取引プログラム（ツール）に対して割り当てられたツールＩＤが含まれている。

ここで顧客端末２０において動作する取引プログラム２２は、証券会社が提供する専用のアプリケーションプログラムではなく、顧客自身や顧客が利用する投資助言業者等が作成した独自の取引用のプログラムであって、例えば、証券会社サーバ１０から株価情報の配信を受け、株価の変動を自動解析し、自らの投資指針に従って設定した所定の条件に合致した場合に株式の売買注文を自動的に発注する機能等を備えるものである。

顧客端末２０から取引プログラム２２を用いて発信されたリクエストは、証券会社サーバ１０のアクセス制御部１１において、図５及び図６のフローチャートに従って受け付けられる。まず、受信した証券会社サーバ１０への接続を要求するリクエストから、リクエストに含まれている顧客を識別する顧客ＩＤと、取引プログラム２２を識別するツールＩＤを読み取る（Ｓ０１）。

続いて、認証情報記憶部１２を検索して（Ｓ０２）、顧客ＩＤをキーにした検索による顧客の認証処理（Ｓ０３）と、ツールＩＤをキーにした検索によるツール（取引プログラム２２）の認証処理（Ｓ０４）を行う。具体的には、図４に示したように、認証情報記憶部１２に顧客認証情報として記憶されている、取引等が可能なユーザとしてあらかじめ登録されている顧客ＩＤのリストに、リクエストから読み取った顧客ＩＤが含まれているか、認証情報記憶部１２にツール認証情報として記憶されている、リクエストの受付けが可能なツール（取引プログラム）としてあらかじめ登録されているツールＩＤのリストに、リクエストから読み取ったツールＩＤが含まれているかを確認して、顧客とツールの認証処理を行う。

顧客とツールの双方が認証された場合には、証券会社サーバ１０への接続処理によってセッションが確立され（Ｓ０５）、証券会社サーバ１０と顧客端末２０との新たなセッションが開始される。これらのいずれかについて認証ができない場合には、証券会社サーバ１０に接続できない旨のメッセージを顧客端末２０に返信するなどのエラー処理を行う（Ｓ０６）。

このように、Ｗｅｂサーバへのアクセスでも行われている顧客の認証処理のみでなく、ツール（取引プログラム）の認証処理も行うよう構成すれば、あらかじめ証券会社が承認した投資助言業者等が作成したツール（取引プログラム）からのアクセスのみを選択して受け付けることができるように、それらのツールＩＤを認証情報記憶部１２に登録しておくことによって、証券会社サーバ１０が悪意のあるツール（取引プログラム）からのリクエストの大量送信などで不正な攻撃を受けるリスクを低減することが可能になる。

証券会社サーバ１０とのセッションが確立された顧客端末２０からは、株式の売買注文の発注や訂正、株価情報の配信等のリクエストが、取引プログラム２２によって証券会社サーバ１０に発信される。これらのリクエストは、取引プログラム２２によって自動的に発信されるのが通常であり、売買注文発注のリクエストであれば、売買対象となる銘柄の証券コードや売買数量、指値等の売買条件が指定された注文データ等が、株価情報配信のリクエストであれば配信対象となる銘柄の証券コード等が、それぞれ含まれている。

証券会社サーバ１０のアクセス制御部１１において、これらのリクエスト（処理要求）を受信すると（Ｓ０７）、先に認証した顧客ＩＤに対応する顧客の通信ログを通信ログ記憶部１３で検索して（Ｓ０８）、あらかじめ設定された流量制限を超過しないかを確認する（Ｓ０９）。具体的には、所定の時間内に受信したリクエストの回数やそれに対して返信したデータの容量、株価情報の配信であれば所定の時間内に受信したリクエストに指定された配信対象の銘柄の数などの通信量を基準に制限値を設定し、これを超過する場合には流量制限を超えると判断することとすればよい。

また、図４に示したように、通信ログ記憶部１３には、顧客別の通信量だけでなく、ツール（取引プログラム）別の通信量も通信ログとして記憶しておき、先に認証したツールＩＤに対応するツール（取引プログラム）の通信ログも検索して（Ｓ０８）、これについてあらかじめ設定された流量制限を超過しないかを確認する（Ｓ０９）こととしてもよい。このように構成すると、証券会社サーバ１０に大量のリクエストを発信させるような不適切なツール（取引プログラム）への対応も可能になる。

流量制限の範囲内にあることが確認された場合は、リクエストに指定された内容に応じて、以下に例示するような所定の処理を実行する（Ｓ１０）。

具体的には、売買注文を発注するリクエストや発注済の売買注文を訂正するリクエストであれば、リクエストから生成した発注データや訂正データを注文処理部１４に引き渡して、取引所システム３０への発注処理や訂正処理を実行させる。このときには、顧客・注文情報管理ＤＢ１６の預かり資産残高等を確認して、注文の受付けの可否を判断することが必要になるが、かかる受付けの可否を判断する処理は、注文処理部１４で行うこととしてもよいし、アクセス制御部１１での顧客の認証処理とあわせて実行することとしてもよい。

株価情報を配信するリクエストであれば、リクエストに指定された銘柄の証券コード等を情報配信処理部１５に引き渡し、情報系ＤＢ１７から読み出した証券コード等から特定される銘柄の最新の株価データ等を受け取って、アクセス制御部１１から顧客端末２０の取引プログラム２２に返信する処理を実行する。

これらの処理を実行すると、受け付けたリクエストによって発生した通信ログを通信ログ記憶部１３に書き込んで（Ｓ１１）、顧客端末２０からログアウトのリクエストを受信するまでは（Ｓ１２）、次のリクエストの受信まで待機する。ログアウトのリクエストを受信した場合には、セッションの切断処理を行って（Ｓ１３）、証券会社サーバ１０と顧客端末２０との接続を切断する。Ｓ０９で流量制限を超えていると判断された場合にも、同様にセッションの切断処理を行う（Ｓ１３）。

１０ 証券会社サーバ
１１ アクセス制御部
１２ 認証情報記憶部
１３ 通信ログ記憶部
１４ 注文処理部
１５ 情報配信処理部
１６ 顧客・注文情報管理ＤＢ
１７ 情報系ＤＢ
２０ 顧客端末
２１ Ｗｅｂブラウザ
２２ 取引プログラム

Claims (2)

1. ネットワークを介して接続された端末から発信された金融商品の売買注文のリクエストの受付けの可否を判断するリクエスト受付サーバであって、
   前記端末において動作する、金融商品の売買注文を受け付ける注文受付者と異なる事業者により提供されたプログラムによって発信された、前記売買注文の注文者であるユーザの識別情報及び前記プログラムの識別情報を含む前記リクエスト受付サーバへの接続を要求するリクエストを受信する第１の受信手段と、
   前記リクエストに含まれるユーザの識別情報から、前記ユーザがあらかじめ登録されたユーザであるかを認証する第１の認証手段と、
   前記リクエストに含まれるプログラムの識別情報から、前記プログラムが前記注文受付者によってリクエストの受付けが許可されたプログラムであるかを認証する第２の認証手段と、
   少なくとも、前記第１の認証手段によって前記ユーザがあらかじめ登録されたユーザであることが認証され、かつ前記第２の認証手段によって前記プログラムが前記注文受付者によってリクエストの受付けが許可されたプログムであることが認証されることを条件として、前記端末との接続処理を実行してセッションを確立する確立手段と、
   前記端末とのセッションが確立されている間に、前記端末において動作する前記プログラムによって発信された、金融商品の売買注文のリクエストを受信する第２の受信手段と、
   前記セッションを確立する際に認証されたユーザの識別情報から特定されるユーザとのセッション確立後の所定の期間内における通信回数が、特定のユーザによる大量アクセスと判断する基準となる所定の制限値を超過していないかを判断する第１の判断手段と、
   前記セッションを確立する際に認証されたプログラムの識別情報から特定されるプログラムによって発信されたリクエストにより発生した通信量が、特定のプログラムによる大量アクセスと判断する基準となる所定の制限値を超過していないかを判断する第２の判断手段と、
   少なくとも、前記第１の判断手段によって前記ユーザとの通信回数が所定の制限値を超過していないと判断されること、かつ、第２の判断手段で前記プログラムによって発信されたリクエストにより発生した通信量が所定の閾値を超過していないと判断されることを条件として、前記リクエストを受け付けて前記売買注文を発注するための所定の処理を実行する第１の実行手段と、
   前記第１の判断手段によって前記ユーザとの通信回数が所定の制限値を超過していると判断された場合、又は、前記第２の判断手段によって前記プログラムによって発信されたリクエストにより発生した通信量が所定の閾値を超過していると判断された場合には、前記端末との間で確立された前記セッションを切断する処理を実行する第２の実行手段と、
   を備えることを特徴とするリクエスト受付サーバ。
2. 端末から発信された金融商品の売買注文のリクエストの受付けの可否を判断するリクエストの受付方法であって、
   前記端末とネットワークを介して接続されたサーバが、前記端末において動作する、金融商品の売買注文を受け付ける注文受付者と異なる事業者により提供されたプログラムによって発信された、前記売買注文の注文者であるユーザの識別情報及び前記プログラムの識別情報を含む前記サーバへの接続を要求するリクエストを受信する第１の受信ステップと、
   前記サーバが、前記リクエストに含まれるユーザの識別情報から、前記ユーザがあらかじめ登録されたユーザであるかを認証する第１の認証ステップと、
   前記サーバが、前記リクエストに含まれるプログラムの識別情報から、前記プログラムが前記注文受付者によってリクエストの受付けが許可されたプログラムであるかを認証する第２の認証ステップと、
   前記サーバが、少なくとも、前記第１の認証ステップで前記ユーザがあらかじめ登録されたユーザであることが認証され、かつ前記第２の認証ステップで前記プログラムが前記注文受付者によってリクエストの受付けが許可されたプログムであることが認証されることを条件として、前記端末との接続処理を実行してセッションを確立する確立ステップと、
   前記サーバが、前記端末とのセッションが確立されている間に、前記端末において動作する前記プログラムによって発信された、金融商品の売買注文のリクエストを受信する第２の受信ステップと、
   前記サーバが、前記セッションを確立する際に認証されたユーザの識別情報から特定されるユーザとのセッション確立後の所定の期間内における通信回数が、特定のユーザによる大量アクセスと判断する基準となる所定の制限値を超過していないかを判断する第１の判断ステップと、
   前記サーバが、前記セッションを確立する際に認証されたプログラムの識別情報から特定されるプログラムによって発信されたリクエストにより発生した通信量が、特定のプログラムによる大量アクセスと判断する基準となる所定の制限値を超過していないかを判断する第２の判断ステップと、
   前記サーバが、少なくとも、前記第１の判断ステップで前記ユーザとの通信回数が所定の制限値を超過していないと判断されること、かつ、前記第２の判断ステップで前記プログラムによって発信されたリクエストにより発生した通信量が所定の閾値を超過していないと判断されることを条件として、前記リクエストを受け付けて前記売買注文を発注するための所定の処理を実行する第１の実行ステップと、
   前記サーバが、前記第１の判断ステップで前記ユーザとの通信回数が所定の制限値を超過していると判断された場合、又は、前記第２の判断ステップで前記プログラムによって発信されたリクエストにより発生した通信量が所定の閾値を超過していると判断された場合には、前記端末との間で確立された前記セッションを切断する処理を実行する第２の実行ステップと、
   を有することを特徴とするリクエストの受付方法。