(57)【特許請求の範囲】
【請求項１】
データの配信先である配信先装置に対してネットワークを介して接続可能とされたデータ配信装置であって、
前記データを格納するデータ格納手段と、
当該データ配信装置と前記配信先装置との接続に関する制御を行うものであって、当該データ配信装置と前記配信先装置との接続確立状態の継続を当該配信先装置が許容すると予測される時間である接続継続時間を所定方法にて取得し、前記配信先装置に対して接続確立を行い、当該接続確立後から前記取得した接続継続時間が経過した時点で前記配信先装置に対する接続切断を行い、これら接続確立と接続切断とを交互に繰り返す接続制御手段と、
前記接続制御手段による前記接続確立中に、前記データ格納手段にて格納されたデータを前記配信先装置に対して送信する配信手段と、
前記配信先装置における前記データの受信環境を所定方法にて特定し、当該特定した受信環境に基づいて、前記接続制御手段の制御内容を決定する接続内容決定手段と、
を備えることを特徴とするデータ配信装置。
【請求項２】
前記接続内容決定手段は、
複数のテストデータを前記配信先装置に対して時間差で送信し、
前記複数のテストデータが前記配信先装置において受信された際の受信タイミングに基づいて当該配信先装置において判断された配信データ検証機能の有無を示す検証判定情報が当該配信先装置から送信された場合に、当該検証判定情報に基づいて、前記配信先装置に対する配信データの検証機能の有無を認識し、
前記テストデータの送信及びデータ検証機能の有無の認識を複数回繰り返し、当該複数回の認識結果に基づいて、前記データ検証機能の有無を最終的に判定し、
前記接続制御手段は、
前記接続内容決定手段により前記データ検証機能が無いものと判定された場合、前記接続継続時間が経過した時点で前記配信先装置に対する接続切断を行い、
前記接続内容決定手段により前記データ検証機能が有るものと判定された場合、前記配信先装置に対するデータの送信が完了する前に前記接続継続時間が経過した場合には、当該接続継続時間が経過した時点で前記配信先装置に対する接続切断を行い、前記接続継続時間の経過前に前記配信先装置に対するデータの送信が完了した場合には、当該送信が完了する毎に前記配信先装置に対する接続切断を行うこと、
を特徴とする請求項１に記載のデータ配信装置。
【請求項３】
前記接続内容決定手段は、
前記データ検証機能の有無の判定を繰り返す毎に、前記複数のテストデータの送信間隔又は送信数を変えること、
を特徴とする請求項２に記載のデータ配信装置。
【請求項４】
前記接続内容決定手段は、
前記接続確立が前記配信先装置にて切断される前に、前記接続継続時間が経過した場合には、当該接続継続時間が経過した時点で、前記配信先装置に対する接続切断を行い、
前記接続継続時間が経過する前に、前記接続確立が前記配信先装置にて切断された場合には、当該接続確立が切断されるまでの経過時間に基づいて、次回以降の接続確立における前記接続継続時間を決定すること、
を特徴とする請求項１に記載のデータ配信装置。
【請求項５】
データの配信先である配信先装置に対してネットワークを介して接続可能とされたデータ配信装置であって、
前記データを格納するデータ格納手段と、
前記データ配信装置と前記配信先装置との接続に関する制御を行うものであって、当該データ配信装置と前記配信先装置との接続確立状態の継続を当該配信先装置が許容すると予測される送信データ量である接続継続データ量を所定方法にて取得し、前記配信先装置に対して接続確立を行い、当該接続確立後からの送信データ量が前記取得した接続継続データ量に達した時点で前記配信先装置に対する接続切断を行い、これら接続確立と接続切断とを交互に繰り返す接続制御手段と、
前記接続制御手段による前記接続確立中に、前記データ格納手段にて格納されたデータを前記配信先装置に対して送信する配信手段と、
前記配信先装置における前記データの受信環境を所定方法にて特定し、当該特定した受信環境に基づいて、前記接続制御手段の制御内容を決定する接続内容決定手段とを備え、
前記接続内容決定手段は、
前記接続確立が前記配信先装置にて切断される前に、当該接続確立後からの送信データ量が前記接続継続データ量に達した場合には、当該接続継続データ量に達した時点で、前記配信先装置に対する接続切断を行い、
前記接続確立後からの送信データ量が前記接続継続データ量に達する前に、前記接続確立が前記配信先装置にて切断された場合には、当該接続確立が切断されるまでに送信したデータ量に基づいて、次回以降の接続確立における前記接続継続データ量を決定すること、
を特徴とするデータ配信装置。
【請求項６】
データの配信先である配信先装置に対してネットワークを介して接続可能とされたデータ配信装置にデータ配信方法を実行させるデータ配信プログラムであって、
当該データ配信装置と前記配信先装置との接続確立状態の継続を当該配信先装置が許容すると予測される時間である接続継続時間を所定方法にて取得し、前記配信先装置に対して接続確立を行い、当該接続確立後から前記取得した接続継続時間が経過した時点で前記配信先装置に対する接続切断を行い、これら接続確立と接続切断とを交互に繰り返す接続制御ステップと、
前記接続制御ステップにおける前記接続確立中に、当該データ配信装置に設けたデータ格納手段によって格納されたデータを前記配信先装置に対して送信する送信ステップとを含み、
前記配信先装置における前記データの受信環境を所定方法にて特定し、当該特定した受信環境に基づいて、前記接続制御ステップにおける制御内容を決定する制御内容決定ステップと、
を含んだことを特徴とするデータ配信方法を前記データ配信装置に実行させるデータ配信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ配信先の配信先装置に対してリアルタイムにデータ配信を行うデータ配信装置と、そのためのプログラムに関する。
【背景技術】
【０００２】
近年のインターネット技術の発達に伴い、このインターネット技術を利用して各種データの配信を行うためのデータ配信システムが広く普及してきている。例えば、証券取引所から提示された株式や債券の価格等に関する証券データを、インターネットを介して各証券会社あるいは個人投資家のクライアント端末に配信するためのサーバ装置が提案されている（特許文献１参照）。
【０００３】
このような従来のデータ配信においてデータをリアルタイムに配信する方法として、サーバ−クライアント通信における標準プロトコルであるＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）を用いた方法と、ＨＴＴＰ以外のプロトコルを用いた方法とがある。
ＨＴＴＰを用いる場合、例えばクライアントからサーバに対してＧｅｔメソッドを用いて所望のデータの配信をリクエストすることで、いわゆるＰｕｌｌ型のデータ配信を行うことができる。ここで、ＨＴＴＰによる通信では、クライアントからのリクエストに応じてサーバがクライアントへデータ配信を行う毎に、サーバ−クライアント間のコネクションが切断されるため、所定時間毎にリクエストを繰り返すことで、定期的に最新データの配信を受ける。この方法においては、１つのサーバにアクセスするクライアント数が増えるほどサーバの負荷が高まるという問題がある。特許文献２では、この問題の解決を図るため、クライアントが情報を自動更新するクライアントプルの時間を設定しており、アクセス者数に応じてクライアントプルの時間を増加する。すなわち、クライアントの数が多くなるほど自動更新の間隔を延長する仕組みとしている。
一方、ＨＴＴＰ以外のプロトコルを用いる場合、例えば非特許文献１に示すＲＴＰ（Ｒｅａｌ−Ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）を用いたフロー制御を行うことで、クライアントからの定期的なリクエストが不要な、いわゆるＰｕｓｈ型のデータ配信を行うことができる。
【０００４】
【特許文献１】特開２００１−２６５７２０号公報
【特許文献２】特開２００１−０９２７４６号公報
【非特許文献１】"ＲＢＢ  ＴＯＤＡＹ  ブロードバンド辞典"、[Ｏｎｌｉｎｅ]、監修：東京大学大学院  情報理工学系研究科  助教授  江崎  浩、発行：ＩＥインスティテュート、「ＲＴＰ」の項参照、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｄｉｃｔｉｏｎａｒｙ．ｒｂｂｔｏｄａｙ．ｃｏｍ／Ｄｅｔａｉｌｓ／ｔｅｒｍ１８９６．ｈｔｍｌ＞
【発明の開示】
【発明が解決しようとする課題】
【０００５】
しかしながら、上述の特許文献２では、サーバ−クライアント間のコネクションが切断している間にサーバにて新規のデータが発生しても、クライアントから次の要求が行われるまでは当該データを配信することができない。そのため、株価データの配信システムのように、データ量もクライアント数も多い上に高いリアルタイム性が求められる場合においては、サーバに負荷をかけずにリアルタイム配信を行う仕組みへの強い要望がある。
【０００６】
一方、ＨＴＴＰ以外のプロトコルを用いる方法では、不正アクセスを防止するためにクライアントに設けられたファイアウォール（以下、Ｆ／Ｗ）が障害となってデータ配信を行うことができない可能性があった。すなわち、通常のＦ／Ｗでは、ＨＴＴＰへのポートが開かれていることが多いため、ＨＴＴＰによって配信されたデータはＦ／Ｗを通過してクライアントに到達できるが、ＨＴＴＰ以外のプロトコルに対してはポートが開かれていないため、データがＦ／Ｗを通過できず、クライアントに到達できない場合があった。この問題を解消するためには、ＨＴＴＰ以外のプロトコルに対してもポートを開くようにＦ／Ｗの設定を変えればよいが、このような設定変更を各クライアントに強制することは現実的に困難であった。
【０００７】
本発明は、上記に鑑みてなされたものであって、クライアント側にＦ／Ｗが設けられている場合であっても、Ｆ／Ｗの設定変更を行うことなく、データ配信先の配信先装置に対してリアルタイムにデータ配信を行うことのできるデータ配信装置を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上述した課題を解決し、目的を達成するために、請求項１、６に記載の本発明は、接続継続時間の間は配信先装置に対する接続を行ってデータを送信し、データの受信環境を所定方法にて特定して接続確立の制御内容を決定することを特徴とする。
【０００９】
請求項２に記載の本発明は、請求項１に記載の本発明において、複数のテストデータを配信先装置に対して時間差で送信することで配信データ検証機能の有無を認識し、この認識を複数回繰り返した結果に基づいて、データ検証機能の有無を最終的に判定し、データ検証機能がない場合には接続継続時間が経過した時点で接続切断を行い、データ検証機能が有る場合には、配信先装置に対するデータの送信が完了する前に接続継続時間が経過した場合には、当該接続継続時間が経過した時点で配信先装置に対する接続切断を行い、接続継続時間の経過前に配信先装置に対するデータの送信が完了した場合には、当該送信が完了する毎に配信先装置に対する接続切断を行うことを特徴とする。
【００１１】
請求項３に記載の本発明は、請求項２に記載の本発明において、データ検証機能の有無の判定を繰り返す毎に、複数のテストデータの送信間隔又は送信数を変えることを特徴とする。
【００１２】
請求項４に記載の本発明は、請求項１に記載の本発明において、接続確立が配信先装置にて切断される前に、接続継続時間が経過した場合には、当該接続継続時間が経過した時点で、配信先装置に対する接続切断を行い、接続継続時間が経過する前に、接続確立が配信先装置にて切断された場合には、当該接続確立が切断されるまでの経過時間に基づいて、次回以降の接続確立における接続継続時間を決定することを特徴とする。
【００１３】
請求項５に記載の本発明は、接続確立が配信先装置にて切断される前に、当該接続確立後からの送信データ量が接続継続データ量に達した場合には、当該接続継続データ量に達した時点で、配信先装置に対する接続切断を行い、接続確立後からの送信データ量が接続継続データ量に達する前に、接続確立が配信先装置にて切断された場合には、接続確立が切断されるまでに送信されたデータ量に基づいて接続継続データ量を決定することを特徴とする。
【発明の効果】
【００１４】
請求項１に記載の本発明によれば、配信先装置の受信環境を特定し、この受信環境に応じた内容にて配信先装置とデータ配信装置との接続内容を決定できるので、配信先装置の受信環境に適したデータ配信を行うことができ、データ配信のリアルタイム性を高めることができる。
【発明を実施するための最良の形態】
【００１５】
以下に添付図面を参照して、この発明を実施するための最良の形態について説明する。ただし、各実施の形態によって本発明が限定されるものではない。まず各実施の形態を説明した後、各実施の形態に対する変形例について説明する。
【００１６】
〔実施の形態１〕
まず、実施の形態１について説明する。この形態は、配信先装置におけるデータ検証機能の有無を判定し、この判定結果に応じた方法にてデータ配信を行う形態である。以下では、本実施の形態に係る各装置の構成を説明した後、データ配信の処理について説明する。
【００１７】
（システム概要）
まず、本実施の形態１に係るデータ配信装置を用いたデータ配信システム（以下、本システム）の概要について説明する。このシステムにて配信対象となるデータの具体的内容は任意であるが、本実施の形態においては、証券データを配信する例を示す。図１は、本システムの構成を機能概念的に示すブロック図である。本システム１は、複数の証券取引所（東証、大証、ＪＡＳＤＡＱ等）の各々から提示された株式や債券の価格等に関する証券データを、複数の証券会社の各々に提示するための証券データ配信システムである。
【００１８】
具体的には、本システム１は、複数の証券取引所の各々が保有する「取引所サーバ」２と、各証券会社の各々が保有する「顧客サーバ」３とに対して、「配信サーバ」４を、インターネットやデータ専用回線の如きネットワーク５を介して通信可能に接続して構成されている（なお、図示では便宜上、ネットワーク５を複数示しているが、実際には同一のネットワーク５を用いることができる）。このような構成において、証券データは、各取引所サーバ２から配信サーバ４に配信され、配信サーバ４において各取引所サーバ２からのデータフォーマットの相違を吸収した所定フォーマットにて変換された後、各顧客サーバ３に送信される。ここで、顧客サーバ３、配信サーバ４は、特許請求の範囲における配信先装置、データ配信装置にそれぞれ対応する。なお、各取引所サーバ２から配信サーバ４への証券データの配信は任意の方法で行うことができるので、そのための構成及び処理の説明は以下省略する。
【００１９】
各顧客サーバ３の上流（各顧客サーバ３とネットワーク５との相互間）には、Ｆ／Ｗ６が設けられている（以下では、各顧客サーバ３の上流に設けられたＦ／Ｗ６を「顧客サーバ３のＦ／Ｗ６」と称する）。なお、Ｆ／Ｗ６を設けていない顧客サーバ３も存在しうる。このＦ／Ｗ６は、証券データの宛先、送信元のＩＰアドレス、及び、ポート番号等を監視し、この監視条件に適合した証券データのみを通過させて顧客サーバ３に送信することにより、証券データのフィルタリングを行う。このＦ／Ｗ６は、その全部又は任意の一部がウィルスチェック（特許請求の範囲におけるデータ検証機能）を行うウィルスチェック型（Bufferedタイプ）のＦ／Ｗ（Buffered Proxy）６であり、他の一部は非ウィルスチェック型である。
【００２０】
従来のＨＴＴＰを用いた通信においては、配信サーバ４は、顧客サーバ３からのデータ配信要求に応じてデータ配信を行う毎に接続を切断し、顧客サーバ３からの次の要求を待つ。ここで、データが複数のパケットに分割して配信サーバ４から顧客サーバ３に送信された場合、非ウィルスチェック型のＦ／Ｗ６は、これら複数のパケットを順次受信し、各パケットのフィルタリングを順次行うと、全てのパケットの受信を待つ（配信サーバ４から接続が切断されるまで待つ）ことなく、各パケットを配信サーバ４へ順次送信する。一方、ウィルスチェック型のＦ／Ｗ６は、パケットを全て受信するまで（配信サーバ４から切断されるまで）待ち、配信サーバ４から切断されると、ウィルスチェックを行った後、各パケットを配信サーバ４へ一括送信する。このＦ／Ｗ６を通過できる方法でデータ配信を行うために、本実施の形態１では、Ｆ／Ｗ６を通過できるセッション層のプロトコルであるＨＴＴＰの上位プロトコル（以下、配信プロトコルと称する）を用いたデータ配信を行う。また、各顧客サーバ３について、Ｆ／Ｗ６が設けられている場合には、そのＦ／Ｗ６がＢｕｆｆｅｒｅｄタイプであるか否かを判定し、この判定結果に応じた方法にてデータ配信を行う。
【００２１】
（配信サーバ４の構成）
次に、配信サーバ４の構成について説明する。配信サーバ４は、配信データＤＢ４ａ、ネットワークインターフェース（以下「ネットワークＩＦ」）４ｂ、記憶部４ｃ、及び、制御部４ｄをバスにて通信可能に接続して構成されている。
【００２２】
配信データＤＢ４ａは、顧客サーバ３に配信する証券データを格納するためのものであり、特許請求の範囲におけるデータ格納手段に対応している。具体的には、ＨＤ（Hard Disk）の如き不揮発的な記憶装置により構成されている（記憶部４ｃ、及び後述する受信データＤＢ３ａと記憶部３ｃにおいて同じ）。
【００２３】
ネットワークＩＦ４ｂは、配信サーバ４がネットワーク５を介した通信を行うための通信制御インターフェースであり、例えばネットワークボードとして構成される。
【００２４】
記憶部４ｃは、配信サーバ４における各処理を実行するために必要なデータを記憶するための記憶手段である。この記憶部４ｃには、後述するＣＷＴ（Client Watch Table）が格納されている。
【００２５】
制御部４ｄは、配信サーバ４の各部を制御する制御手段であり、機能概念的に、接続制御部４ｄ１、接続内容決定部４ｄ２、及び、配信処理部４ｄ３を備える。接続制御部４ｄ１は、配信プロトコルに従って、所定方法により取得した顧客サーバ３のＦ／Ｗ６が許容する接続継続時間や、後述する接続内容決定部４ｄ２によって決定された接続制御内容に基づいて、顧客サーバ３と配信サーバ４との接続確立あるいは接続切断等の制御を行うものであり、特許請求の範囲における接続制御手段に対応する。接続内容決定部４ｄ２は、顧客サーバ３のＦ／Ｗ６のタイプを特定し、これに基づいて接続制御部４ｄ１による制御内容を決定するものであり、特許請求の範囲における接続内容決定手段に対応する。配信処理部４ｄ３は、接続制御部４ｄ１による接続確立中に、配信データＤＢ４ａにて格納されたデータを顧客サーバ３に対して送信するものであり、特許請求の範囲における配信手段に対応する。この制御部４ｄは、具体的には、ＣＰＵ（Central Processing Unit）や、このＣＰＵ上で解釈実行される各種のプログラム（ＯＳなどの制御プログラムや、各種の処理手順などを規定したプログラム）、及び、所要プログラムや所要データを格納するための内部メモリを備えて構成される（後述する制御部３ｄにおいて同じ）。
【００２６】
（配信サーバ４の構成−ＣＷＴ）
次に、配信サーバ４の記憶部４ｃに記憶されているＣＷＴの構造について説明する。ただし、ＣＷＴの内容はあくまで例示であり、以下に示す情報以外の情報を含むことができ、あるいは、以下に示す情報の一部を除外することもできる。
【００２７】
ＣＷＴは、当該配信サーバ４との間で接続が確立されている顧客サーバ３に関する顧客サーバ情報を格納するためのものである。具体的には、図２に例示するように、「ログインＩＤ」、「ログイン時刻」、「切断時刻」、「判定回数」、「判定フラグ」、「Ｗａｔｃｈ銘柄」、及び「未送信データ」の各項目と、各項目に対応するデータとを含んでいる。項目「ログインＩＤ」のデータには、接続が確立されている各顧客サーバ３に割り当てたログインＩＤ（図２においては「３」）が格納されている。項目「ログイン時刻」のデータには、顧客サーバ３からのデータ配信要求を受信した際の時刻（図２においては絶対時刻（実際の時刻）として「１０：００：００」が格納されているが、任意タイミングを基準とする相対時刻を格納してもよい）が格納されている。項目「切断時刻」のデータには、顧客サーバ３との接続を切断する時刻（図２においては絶対時刻として「１０:１３:２０」が格納されているが、任意タイミングやログイン時刻を基準とする相対時刻を格納してもよい）が格納されている。「判定回数」には、後述する検証機能判定処理に使用される一時データが格納される。「判定フラグ」には、顧客サーバ３のＦ／Ｗ６がＢｕｆｆｅｒｅｄタイプであるか否かを示すフラグ（例えば、Ｂｕｆｆｅｒｅｄタイプである場合にはＯＮ、Ｂｕｆｆｅｒｅｄタイプでない場合にはＯＦＦであり、図２においては「ＯＮ」）が格納されている。「Ｗａｔｃｈ銘柄」には、顧客サーバ３が閲覧している（必要としている）証券データを特定する情報（図２においては銘柄コードであり、「３７１７」、「６５０１」等）が格納されている。「未送信データ」には、顧客サーバ３との接続が一旦切断され、その後再確立された場合において、接続の切断から再確立までの間に配信データＤＢ４ａの証券データが更新されたために顧客サーバ３に配信できなかった証券データを特定するための情報（例えば、配信データＤＢ４ａにおける未配信の証券データのアドレスであり、図２においては「\\c\data\001」等）が格納されている。
【００２８】
（顧客サーバ３の構成）
次に、顧客サーバ３の構成について説明する。図１に示すように、顧客サーバ３は、受信データＤＢ３ａ、ネットワークＩＦ３ｂ、記憶部３ｃ、及び、制御部３ｄをバスにて通信可能に接続して構成されている。
【００２９】
受信データＤＢ３ａは、配信サーバ４から受信した証券データを格納する。ネットワークＩＦ３ｂは、顧客サーバ３がネットワーク５を介した通信を行うための通信制御インターフェースであり、例えばネットワークボードとして構成される。記憶部３ｃは、顧客サーバ３における各処理を実行するために必要なデータを記憶するための記憶手段である。
【００３０】
制御部３ｄは、顧客サーバ３の各部を制御する制御手段であり、機能概念的に、接続制御部３ｄ１及び受信処理部３ｄ２を備える。接続制御部３ｄ１は、配信プロトコルに従って、配信サーバ４への接続要求等の制御を行う。受信処理部３ｄ２は、配信サーバ４との接続確立中に、配信サーバ４から配信された証券データを受信する。
【００３１】
（データ配信処理）
次に、配信サーバ４及び顧客サーバ３によって行われるデータ配信処理を説明する。図３はデータ配信処理の概念を示したブロック図、図４はデータ配信処理のフローチャートである。
【００３２】
顧客サーバ３は、配信サーバ４に対してデータ配信要求を送信する（図３のステップＳＡ−１、図４のステップＳＢ−１）。この要求は、ＨＴＴＰプロトコルにおけるＧｅｔメソッドにより行い、この際の引数として、自己の記憶部３ｃに前回のデータ配信要求時に取得したログインＩＤが記憶されている場合には当該ログインＩＤを指定する。この要求があった場合、配信サーバ４の接続制御部４ｄ１は、引数として指定されたログインＩＤが記憶部４ｃのＣＷＴに格納されているか否かを判定する（ステップＳＢ−２）。
【００３３】
ログインＩＤがＣＷＴに格納されている場合（ステップＳＢ−２、Ｙｅｓ）、接続制御部４ｄ１は、ＣＷＴに格納されている顧客サーバ３のログイン時刻および切断時刻を今回の接続に対応する時刻に更新し（ステップＳＢ−３）、このログインＩＤを含む顧客サーバ情報を用いて当該顧客サーバ３との間の接続を確立する（ステップＳＢ−５、ＳＢ−６、図３のステップＳＡ−２）。一方、引数として指定されたログインＩＤがＣＷＴに格納されていない場合（ＣＷＴから削除された場合）あるいはログインＩＤが指定されなかった場合（最初の接続である場合）（ステップＳＢ−２、Ｎｏ）、接続制御部４ｄ１は、当該顧客サーバ３に割り当てるログインＩＤを所定方法で決定し、このログインＩＤに対応付けて、顧客サーバ３のＩＰアドレス、顧客サーバ３のログイン時刻、切断時刻を含む顧客サーバ情報を記憶部４ｃのＣＷＴに格納すると共に（ステップＳＢ−４）、当該顧客サーバ３との間の接続を確立する（ステップＳＢ−５、ＳＢ−６、図３のステップＳＡ−２）。切断時刻は、顧客サーバ３のログイン時刻に接続継続時間を加えることにより決定する。この接続継続時間としては、所定方法（例えば、配信サーバ４の管理者による入力操作）で取得した時間であって、顧客サーバ３のＦ／Ｗ６により接続確立の継続が許容され得る所定時間（例えば８００秒）を用いる。なお、図４における図示は省略するが、接続制御部４ｄ１は、ステップＳＡ−２で決定したログインＩＤを顧客サーバ３に送信し、顧客サーバ３の接続制御部３ｄ１は、配信サーバ４から送信されたログインＩＤを記憶部３ｃに記憶する。
【００３４】
接続確立後、接続内容決定部４ｄ２は、顧客サーバ３のログインＩＤに対応する判定フラグがＣＷＴに格納されているか否かを判定し（ステップＳＢ−７）、格納されていない場合にのみ（ステップＳＢ−７、Ｎｏ）、顧客サーバ３のＦ／Ｗ６のタイプを特定する検証機能特定処理を実行する（ステップＳＢ−８）。この処理の詳細については後述する。この検証機能特定処理の結果としてＣＷＴには判定フラグが格納されるので、接続制御部４ｄ１はこの判定フラグを参照し、格納されている値が「ＯＮ」でない場合（ステップＳＢ−９、Ｎｏ）には第１データ配信処理を実行し（ステップＳＢ−１０）、「ＯＮ」である場合（ステップＳＢ−９、Ｙｅｓ）には第２データ配信処理を実行する（ステップＳＢ−１１）。
【００３５】
これら第１データ配信処理又は第２データ配信処理において顧客サーバ３に証券データが配信された後、接続を切断する（ステップＳＢ−１２，ＳＢ−１６）。この時、配信サーバ４の接続制御部４ｄ１は、当該接続を切断した顧客サーバ３の顧客サーバ情報をＣＷＴから直ちには削除せず、同一の顧客サーバ３からの再度のログインに備えて当該顧客サーバ情報を所定時間保持する。その際に、配信すべき証券データが発生した場合には未送信データのアドレスをＣＷＴに格納する（ＳＢ−１３）。そして、接続制御部４ｄ１は、所定時間が経過しても当該顧客サーバ３からの再度の接続要求がない場合には（ステップＳＢ−１４、Ｙｅｓ）、当該顧客サーバ情報をＣＷＴから破棄する（ステップＳＢ−１５）。一方、接続が切断された顧客サーバ３の接続制御部３ｄ１は（ステップＳＢ−１６）、所定タイミングで配信サーバ４に対してデータ配信要求を再度送信する（ステップＳＢ−１、図３のステップＳＡ−７）。ＣＷＴから顧客サーバ情報が破棄される前に顧客サーバ３からデータ配信要求を受信した場合、配信サーバ４の接続制御部４ｄ１は、当該顧客サーバ３のログインＩＤがＣＷＴに格納されていることから（ステップＳＢ−２、Ｙｅｓ）、ログインＩＤの決定等を行うことなく、このＣＷＴに格納されている顧客サーバ情報を用いて、接続を再確立する（ステップＳＢ−５）。一方、顧客サーバ情報がＣＷＴから破棄された後に顧客サーバ３からデータ配信要求を受信した場合、配信サーバ４の接続制御部４ｄ１は、当該顧客サーバ３のログインＩＤがＣＷＴに格納されていないことから（ステップＳＢ−２、Ｎｏ）、上述したステップＳＢ−４を経て、接続を再確立する（ステップＳＢ−５）。以降、ステップＳＢ−１からＳＢ−１６までの処理が繰り返して実行される。
【００３６】
（データ配信処理−検証機能判定処理）
次に、上述のステップＳＢ−８で実行される検証機能判定処理について説明する。図５は検証機能判定処理のフローチャートである。検証機能判定処理が起動されると、接続内容決定部４ｄ２は、顧客サーバ３に対して所定の複数個（例えば８個）のテストパケット（特許請求の範囲におけるテストデータに対応する）を所定間隔（例えば、１０ｍｓ毎）で送信し（ステップＳＣ−１）、その後、接続を切断する（ステップＳＣ−２，ＳＣ−３）。顧客サーバ３の接続制御部３ｄ１は、複数のテストパケットを受信した際の受信タイミングに基づいて、自己のＦ／Ｗ６がＢｕｆｆｅｒｅｄタイプか否かを検証し判定する（ステップＳＣ−４）。具体的には接続制御部３ｄ１は、複数のテストパケットを時間差で受信した場合にはＢｕｆｆｅｒｅｄタイプではないと判定し、複数のテストパケットを一括受信した場合にはＢｕｆｆｅｒｅｄタイプであると判定する。そしてＨＴＴＰのＧｅｔメソッドにより、自己の記憶部３ｃに記憶されているログインＩＤを引数として接続要求を行い（ステップＳＣ−５），ＣＷＴに格納された顧客サーバ情報により接続が確立されると（ステップＳＣ−６，ＳＣ−７）、当該判定結果を示す検証判定情報を配信サーバ４に送信する（ステップＳＣ−８）。この送信は、ＨＴＴＰプロトコルにおけるＰｏｓｔメソッドにより行い、この際に検証判定情報を引数として送信する。
【００３７】
配信サーバ４の接続内容決定部４ｄ２は、顧客サーバ３から受信した検証判定情報がＢｕｆｆｅｒｅｄタイプでない場合には（ステップＳＣ−９、Ｎｏ）、ＣＷＴの判定フラグを「ＯＦＦ」にセットする（ステップＳＣ−１０）。
【００３８】
ここで、実際にはＢｅｆｆｅｒｅｄタイプではないにもかかわらず、例えばネットワークの遅延等により顧客サーバ３でたまたまテストパケットを一括して受信した結果、顧客サーバ３において自己のＦ／Ｗ６がＢｅｆｆｅｒｅｄタイプであると誤判定する場合がある。そのため本実施の形態においては、Ｂｅｆｆｅｒｅｄタイプであるとの検証判定情報が送信されてきた場合（ステップＳＣ−９、Ｙｅｓ）には、テストを繰り返すことで精度の高い結果を得ることができる。
【００３９】
具体的には、あらかじめ決めた所定のテスト回数において、Ｂｅｆｆｅｒｅｄタイプであるとの検証判定情報が送信されてきた場合（ステップＳＣ−９、Ｙｅｓ）、ＣＷＴの判定回数（初期値＝０とする）を１増加する。そして、ステップＳＣ−１に戻り再度テストを行い、顧客サーバ３からＢｕｆｆｅｒｅｄタイプでない旨の検証判定情報が送信されてきたら（ステップＳＣ−９、Ｎｏ）、ＣＷＴの判定フラグを「ＯＦＦ」にセット（ステップＳＣ−１０）してテストを終了する。このようにＣＷＴの判定回数を１ずつ増加しながらテストを繰り返し、判定回数が所定回数に達した場合（ステップＳＣ−１１、Ｙｅｓの場合。すなわち、すべての回においてテスト結果がＢｕｆｆｅｒｅｄタイプであった場合）には、ＣＷＴの判定フラグを「ＯＮ」にセット（ステップＳＣ−１３）してテストを終了する。
【００４０】
この判定を複数回繰り返すに際し、接続内容決定部４ｄ２は、テストパケットの送信間隔又は送信数を判定毎に変える（ステップＳＣ−１２）。この送信間隔又は送信数の具体的な変化方法は任意であるが、例えば、最初の判定では８個のテストパケットを１秒間隔で送信し、次の判定では８個のテストパケットを１．５秒間隔で送信する。あるいは、最初の判定では８個のテストパケットを１秒間隔で送信し、次の判定では１０個のテストパケットを１秒間隔で送信する。
【００４１】
この検証機能判定処理を行なうことで、ネットワーク負荷によるパケットの受信時間の変動の如きノイズを排除した正確な判定を行なうことができる。特に、送信間隔又は送信数を変えることで、全てのテストパケットの送信を完了するまでの総所要時間を変えることができ、Ｆ／Ｗ６におけるテストパケットの受信条件を変化させることができるので、１回のテストで判定を行う場合に比べて、一層正確な判定を行うことができる。なお、一般的には、テストパケットの送信を完了するまでの総所要時間が長いほど正確なテスト結果が得やすくなるが、テストに時間がかかることになる。
【００４２】
（データ配信処理−第１データ配信処理）
次に、図４のステップＳＢ−１０で実行される第１データ配信処理について説明する。図６は第１データ配信処理のフローチャートである。この第１データ配信処理は、Ｆ／Ｗ６がＢｅｆｆｅｒｅｄタイプではない（Ｂｕｆｆｅｒ機能に起因する配信遅延がない）場合にリアルタイム配信を実行する処理である。なお、Ｆ／Ｗ６が設置されていない顧客サーバ３に対しても、第１データ配信処理にてデータ配信をすることができる。
【００４３】
ここで、図６には図示しないが、顧客サーバ３による最初の配信要求である場合には、上述した図５の検証判定情報の配信サーバ４への送信（ステップＳＣ−８）と同時に、またはその後に、Ｐｏｓｔメソッドの引数として所望する証券データの銘柄コードを送信しており、配信サーバ４にてＣＷＴのＷａｔｃｈ銘柄に銘柄コードを格納している。
【００４４】
そして、配信処理部４ｄ３は、切断されている間に図４のステップＳＢ−１３にて蓄積した未送信データがあれば、それを顧客サーバ３に配信する（ステップＳＤ−１）。これにより、顧客サーバ３に証券データをもれなく送信することができる。
【００４５】
次に、配信サーバ４の接続制御部４ｄ１は、記憶部４ｃのＣＷＴから取得した「切断時刻」と、自己の内部時計から取得した現在時刻とを比較することで、当該切断時刻の到来を監視し（ステップＳＤ−２）、切断時刻が到来する迄、顧客サーバ３との接続を継続すると共に、以下のステップＳＤ−３〜ＳＤ−４の処理を繰り返す。そして、切断時刻が到来したと判定した場合（ステップＳＤ−２、Ｙｅｓ）、第１データ配信処理を終了し、図４のステップＳＢ−１２に移行して接続を切断する（図３のステップＳＡ−６）。
【００４６】
接続継続中においては、配信処理部４ｄ３は、取引所サーバ２から証券データが自己に送信される毎に、この証券データを必要に応じて加工して配信データＤＢ４ａに格納することにより証券データを更新すると共に、この証券データを必要に応じて顧客サーバ３に配信する。具体的には配信処理部４ｄ３は、証券データが更新されると（ステップＳＤ−３、Ｙｅｓ）、当該証券データの銘柄コードがＣＷＴのＷａｔｃｈ銘柄に格納されているか否かを判定し（ステップＳＤ−４）、格納されている場合には（ステップＳＤ−４、Ｙｅｓ）その証券データを顧客サーバ３に配信する（ステップＳＤ−５、図３のステップＳＡ−３）。この証券データは、ＨＴＴＰの上位の配信プロトコルにて送信されていることから、Ｆ／Ｗ６を通過して顧客サーバ３に到達する。顧客サーバ３の受信処理部３ｄ２は、配信サーバ４から送信された証券データを受信データＤＢ３ａに格納する（ステップＳＤ−６）。
【００４７】
また、新規に配信を要求する証券データや、既に配信を要求しているが不要になった証券データがある場合（ステップＳＤ−７、Ｙｅｓ）、顧客サーバ３の受信処理部３ｄ２は、配信サーバ４に対して受信データ変更処理を実行する（ステップＳＤ−８）。この受信データ変更処理のフローチャートを図７に示す。受信処理部３ｄ２は、データ変更要求を配信サーバ４に対して送信する（ステップＳＥ−１、図３のステップＳＡ−４）。この要求は、ＨＴＴＰプロトコルにおけるＰｏｓｔメソッドにより行い、この際の引数として、自己の記憶部３ｃに記憶されているログインＩＤと、新規に配信を要求する証券データの銘柄コードや、既に配信を要求しているが不要になった証券データの銘柄コードを指定する。この変更要求があった場合（ステップＳＥ−２、Ｙｅｓ）、配信サーバ４の接続制御部４ｄ１は、引数として指定されたログインＩＤに対応してＣＷＴのＷａｔｃｈ銘柄に格納されている銘柄コードを更新することにより（ステップＳＥ−３）、それ以降に行うデータ配信の対象データを変更する（図３のステップＳＡ−５）。
【００４８】
（データ配信処理−第２データ配信処理）
次に、図４のステップＳＢ−１１で実行される第２データ配信処理について説明する。図８は第２データ配信処理のフローチャートである。この第２データ配信処理は、Ｆ／Ｗ６がＢｅｆｆｅｒｅｄタイプである（Ｂｕｆｆｅｒ機能に起因する配信遅延が生じ得る）場合に行うものである。
【００４９】
ここで、図８には図示しないが、顧客サーバ３による最初の配信要求である場合には、上述の第１データ配信処理と同様に銘柄コードの送信およびＣＷＴのＷａｔｃｈ銘柄への格納を行う。そして、配信処理部４ｄ３は、切断されている間に図４のステップＳＢ−１３にて蓄積した未送信データがあれば（ステップＳＦ−１、Ｙｅｓ）、それを顧客サーバ３に配信し（ステップＳＦ−２）て図４のステップＳＢ−１２に移行して接続を切断する。
【００５０】
そして、顧客サーバ３の受信処理部３ｄ２は、受信した証券データを受信データＤＢ３ａに格納する（図８のステップＳＦ−６）。配信サーバ４により接続が切断された（ステップＳＢ−１６）ので、顧客サーバ３は、ステップＳＢ−１のデータ配信要求処理に戻り処理を繰り返す。なお、顧客サーバ３は、要求する証券データが変更になった場合、当該変更を引数として伝えるＧｅｔメソッドのデータ配信要求を送信する。
【００５１】
一方、未送信データがない場合（ステップＳＦ−１、Ｎｏ）において、切断時刻が到来しない間（ステップＳＦ−３、Ｎｏ）は顧客サーバ３が所望する銘柄の証券データの更新有無の監視を続け、証券データが更新された場合に（ステップＳＦ−４、Ｙｅｓ）、データ配信を行って（ステップＳＦ−５）、接続を切断する（図４のステップＳＢ−１２）。顧客サーバ３においては、受信処理部３ｄ２が証券データを受信データＤＢ３ａに格納する（ステップＳＦ−５）。更新データが発生しないまま接続切断時刻が到来した場合（ステップＳＦ−３、Ｙｅｓ）には、何も送信せず（または送信すべきデータがない旨を顧客サーバ３に伝え）、図４のステップＳＢ−１２に移行して接続を切断する。
【００５２】
（実施の形態１の効果）
このように実施の形態１によれば、顧客サーバ３の受信環境の一つであるＦ／Ｗ６のタイプを特定し、この受信環境に応じて第１データ配信処理又は第２データ配信処理のいずれかの処理にてデータ配信を行うことで、顧客サーバ３の受信環境に適したデータ配信を行うことができる。
【００５３】
また、Ｆ／Ｗ６がウィルスチェック型であるか否かを、複数テストパケットの受信タイミングに基づいて行った特定することができるので、Ｆ／Ｗ６の種類を自動的に判定でき、顧客サーバ３の受信環境を特定することができる。
【００５４】
特に、Ｆ／Ｗ６のＢｕｆｆｅｒ機能に起因する配信遅延がない場合には、第１データ配信処理を行なうことで、接続継続時間の間は接続を切断することなくリアルタイムに顧客サーバ３にデータ配信することで、リアルタイム性の高いデータ配信をすることができる。
【００５５】
また、第２データ配信処理では、新規な証券データが発生するまでは接続を切断せず、新規な証券データが発生した時点で当該証券データの配信と接続切断とを行うため、従来のＧｅｔメソッドによるＰｕｌｌ型のデータ配信に比べてリアルタイム性が高く、特に配信するデータが多くない場合においては無駄なトラフィックのないデータ配信を行うことができる。なお、第２データ配信処理に代えて従来のＧｅｔメソッドによるＰｕｌｌ型配信としてもよい。
【００５６】
〔実施の形態２〕
次に、実施の形態２について説明する。この形態は、顧客サーバ３のＦ／Ｗ６により接続確立が切断されるまでの経過時間を計測し、この計測結果に基づいてＦ／Ｗ６が許容する接続継続時間を決定する形態である。なお、実施の形態２の構成は、特記する場合を除いて実施の形態１の構成と略同一であり、実施の形態１の構成と略同一の構成についてはこの実施の形態１で用いたのと同一の符号及び／又は名称を必要に応じて付して、その説明を省略する。
【００５７】
図５の検証機能判定処理の後、第１（第２）データ配信処理が最初に起動された場合（再接続でない場合）に、配信サーバ４の接続内容決定部４ｄ２は、接続確立から、顧客サーバ３のＦ／Ｗ６によって接続確立が切断されるまでの時間を計測する接続時間計測処理を実行して接続継続時間を決定し、この決定した接続継続時間に基づいて切断時刻を決定して、当該切断時刻をＣＷＴに格納する。なお、接続継続時間は実施の形態１のように一律ではなく顧客サーバ３により異なると思われるため、接続継続時間についてもＣＷＴに格納するとよい。
【００５８】
そして、以降の（再接続における）データ配信処理においては、決定された接続継続時間に従って切断時刻を決定して、実施の形態１と同様の方法によりデータを配信する。ここで、接続継続時間は、計測した時間（Ｆ／Ｗ６に切断される時間）から、例えば所定の予備時間（例えば１０秒）を減算することにより求めた時間とする。なお、計測した時間をそのまま接続継続時間とし、切断時刻を決定する際に予備時間を考慮した時刻としてもよい。また、ここでは１回目の第１データ配信処理の際に接続継続時間を計測する例を示したが、第１データ配信処理の前に計測を行うようにしてもよい。また、最初の１回のみの計測に限らず、随時計測を行って接続継続時間を更新してもよい。
【００５９】
（実施の形態２の効果）
このように実施の形態２によれば、顧客サーバ３の受信環境の一つである接続時間を特定し、この受信環境に応じて適切なデータ配信を行う。このため、顧客サーバ３毎に接続継続時間を最大限に活用して接続を維持し、データ配信のリアルタイム性を高めることが出来る。
【００６０】
〔実施の形態３〕
実施の形態２においては、接続継続時間を計測することにより各々のＦ／Ｗ６の環境に応じた適切なデータ配信をすることができる。しかし、Ｆ／Ｗ６によっては、接続継続時間ではなく、接続継続中に送信されたデータ量を監視して、データ量が異常に多いと認められた場合に接続を切断する場合もある。実施の形態３は、顧客サーバ３のＦ／Ｗ６により接続確立が切断されるまでの送信データ量を計測し、この計測結果に基づいてＦ／Ｗ６が許容する接続継続データ量を決定する形態である。なお、計測のタイミングについては上述の実施の形態２と同様である。
【００６１】
このため、本実施の形態３においては、接続継続時間を計測する代わりに、第１データ配信処理または第２データ配信処理において送信したデータサイズ（バイト数等）をチェックし、切断時までの合計データ量を計測し、当該合計データ量に基づいて接続継続データ量を決定してＣＷＴに記憶する。そして、以降のデータ配信処理において同様に送信データサイズをチェックし、接続継続データ量に達した時点で接続切断を行う。ここで、接続継続データ量は、計測した合計データ量（Ｆ／Ｗ６に切断されるデータ量）から、例えば所定の予備データ量を減算することにより求めた値とする。なお、計測した合計データ量をそのまま接続継続データ量とし、配信の際に予備データ量を考慮して接続切断を行ってもよい。また、実施の形態３においては実施の形態１，２における接続継続時間および、ＣＷＴの切断時刻は不要であるが、実施の形態２と組み合わせた方法として、接続継続時間あるいは接続継続データ量のいずれかに達した場合に接続を切断するようにしてもよい。
【００６２】
（実施の形態３の効果）
上述の実施の形態３によれば、顧客サーバ３の受信環境の一つである接続継続データ量を特定し、この受信環境に応じて適切なデータ配信を行う。このため、顧客サーバ３毎に接続継続データ量を最大限に活用して接続を維持し、データ配信のリアルタイム性を高めることが出来る。
【００６３】
〔III〕各実施の形態に対する変形例
以上、本発明に係る各実施の形態について説明したが、本発明の具体的な構成及び手段は、特許請求の範囲に記載した各発明の技術的思想の範囲内において、任意に改変及び改良することができる。以下、このような変形例について説明する。
【００６４】
（解決しようとする課題や発明の効果について）
まず、発明が解決しようとする課題や発明の効果は、前記した内容に限定されるものではなく、本発明によって、前記に記載されていない課題を解決したり、前記に記載されていない効果を奏することもでき、また、記載されている課題の一部のみを解決したり、記載されている効果の一部のみを奏することがある。例えば、従来に比べてデータ配信のリアルタイム性を向上できていない場合においても、従来と同程度のリアルタイム性を従来と異なる手段にて達成できていれば、本発明の課題が達成されている。
【００６５】
（受信環境や接続継続時間の特定について）
配信先装置におけるデータの受信環境の特定方法としては、上述した方法以外にも、例えば各配信先装置や各Ｆ／Ｗの記憶部に自己の通信条件に関する設定情報が記憶されている場合には、当該設定情報を取得し、この設定情報に基づいて受信環境を特定してもよい。あるいは、一つの配信先装置に対する受信環境が特定された場合には当該該受信環境をデータ配信装置に格納しておき、当該配信先装置と同一視できる他の所定の配信先装置（同一顧客により所有されている配信先装置等）に対するデータ配信時には、先に格納した受信環境に基づいてデータ配信を行ってもよい。
【００６６】
（対象とするデータの検証機能について）
データの検証機能としては、上述したＦ／Ｗのウィルスチェック以外にも、データ配信の遅延を生じさせ得る任意の検証機能を対象とすることができる。
【図面の簡単な説明】
【００６７】
【図１】本発明の実施の形態１に係るデータ配信システムの構成を機能概念的に示すブロック図である。
【図２】ＣＷＴの構成例を示す図である。
【図３】データ配信処理の概念を示したブロック図である。
【図４】データ配信処理のフローチャートである。
【図５】図４の検証機能判定処理のフローチャートである。
【図６】図４の第１データ配信処理のフローチャートである。
【図７】図６の受信データ変更処理のフローチャートである。
【図８】図４の第２データ配信処理のフローチャートである。
【符号の説明】
【００６８】
１  システム
２  取引所サーバ
３  顧客サーバ
３ａ  受信データＤＢ
３ｂ、４ｂ  ネットワークＩＦ
３ｃ、４ｃ  記憶部
３ｄ、４ｄ  制御部
３ｄ１、４ｄ１  接続制御部
３ｄ２  受信処理部
４  配信サーバ
４ａ  配信データＤＢ
４ｄ２  接続内容決定部
４ｄ３  配信処理部
５  ネットワーク
６  Ｆ／Ｗ
【要約】
【課題】Ｆ／Ｗの設定変更を行うことなく、データ配信先の配信先装置に対してリアルタイムにデータ配信を行うことのできるデータ配信装置を提供すること。
【解決手段】配信サーバ４であって、データを格納する配信データＤＢ４ａと、接続継続時間を所定方法にて取得し、顧客サーバ３に対して接続確立を行い、当該接続確立後から接続継続時間が経過した時点で顧客サーバ３に対する接続切断を行い、これら接続確立と接続切断とを交互に繰り返す接続制御部４ｄ１と、接続確立中に配信データＤＢ４ａにて格納されたデータを顧客サーバ３に対して送信する配信処理部４ｄ３と、顧客サーバ３の受信環境を特定して接続制御部４ｄ１の制御内容を決定する接続内容決定部４ｄ２とを備える。
【選択図】図１【図１】
0004092368.tif 000002
【図２】
0004092368.tif 000003
【図３】
0004092368.tif 000004
【図４】
0004092368.tif 000005
【図５】
0004092368.tif 000006
【図６】
0004092368.tif 000007
【図７】
0004092368.tif 000008
【図８】
0004092368.tif 000009