(57)【要約】【課題】クライアント側での制御や処理に用いられるプログラムデータ、バッチ情報等のデータをサーバより配信する場合、リアルタイムな配信を必要とする市場データを優先するために、プログラムデータ等が市場データの配信に際するトラフィックに影響が出さないようにする。【解決手段】任意のデータを任意に分割したブロックデータとし、該ブロックデータ各々にブロック番号が付与されてサーバより配信する手段と、クライアントは前記ブロックデータの各々にエラーがあるか否かを判定する手段と、該判定の結果、エラーブロックがある場合は当該ブロック番号と共にエラーログ情報としてサーバに送信する手段と、これを受信したサーバは、エラーログ情報に基づいて予め設定された送信手段を選定し、且つ必要なブロックデータを前記選定した送信手段により送信する手段とを有するデータ配信システム。【選択図】  図８
2004280406.tif 000002
【特許請求の範囲】
【請求項１】
複数のクライアントと、任意のデータを管理する少なくとも１つのサーバと、前記複数のクライアントに前記少なくとも１つのサーバより前記任意のデータを通信回線を介して配信するサーバ／クライアント方式のデータ配信システムにおいて、
前記任意のデータは任意の数に分割されてブロックデータとし、該ブロックデータの各々に固有のブロック番号が付与されてサーバより配信する手段と、
前記複数のクライアントの各々は前記ブロックデータの各々がエラーがあるか否かを判定する手段と、
該判定の結果、エラーブロックがある場合は当該ブロック番号と共にエラーログ情報としてサーバに送信する手段と、
該エラーログ情報を受信したサーバは、当該エラーログ情報に基づいて予め設定された送信手段を選定し、且つ必要なブロックデータを該当するクライアントに前記選定した送信手段により送信する手段と、
を有することを特徴とするデータ配信システム。
【請求項２】
前記請求項１記載のデータ配信システムであって、
サーバは、各クライアントから送信されるエラーログ情報を蓄積記憶し、該蓄積状態に応じてエラーログ情報の統計情報を算出し、該算出結果に基づいてサーバから該当するクライアントへの前記送信手段の選定を行う、
ことを特徴とするデータ配信システム。
【請求項３】
前記請求項１または請求項２記載のデータ配信システムであって、
前記サーバは、前記任意のデータ及び該任意のデータのエラーに基づくエラーブロックとは別に、他のサーバ手段より受信した時々刻々と変化する市場データを前記複数のクライアントに配信し、
且つ、市場データを配信する時間帯と、任意のデータ及び該任意のデータのエラーに基づくエラーブロックとを配信する時間帯とを異ならせることを特徴とするデータ配信システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、証券、株式、金融等の市場データをサーバで受信し、複数のクライアントに配信するサーバ／クライアント方式のデータ配信システムに係り、特に、クライアント側での各種処理、制御に用いるプログラムやプログラム更新データ、バッチ情報等の大容量データをサーバ側より配信するデータ配信システムに関するもので、サーバの負荷を軽減、平準化することでサーバ／クライアント間の回線上のトラフィック負荷を軽減し、または配信時間の短縮化を図り、クライアントでの各種処理、制御をスムーズに行うことのできるデータ配信システムに関するものである。
【０００２】
【従来の技術】
図１は、データ配信システムのシステム構成図である。従来のデータ配信システムについて図１を用いて説明する。
複数のデータ配信用のサーバ（サーバ１、サーバ２、…、サーバｎ）が、インターネット、イントラネットなどの通信回線であるネットワーク網を介し、複数の端末（クライアント１、クライアント２、…、クライアントｎ）、と接続されている。また、サーバは他の専用回線、例えば株価通報回線や時事情報回線等が接続されており、証券、株式、金融等の市場データをこの専用回線や前記ネットワーク網を介して受信し、必要な市場データを前記ネットワーク網を介してクライアントへ配信している。
市場データは、例えば証券データや金融データであり、任意の銘柄を示すデータと共にその現在値や売買高であったり、現在の為替や預金に関することを示すデータと共にその為替レートや金利値であったりし、これらのデータは時々刻々と変化する、いわばリアルタイムに変化するデータである。
【０００３】
ここで、サーバ側はこのようなリアル性が重視される市場データの他に、クライアント側での制御や処理に用いられるプログラムやプログラム更新データ、バッチ情報等の大容量のデータもクライアントへ配信する必要がある。制御や処理に用いられるこのようなプログラムデータは、市場データと異なりリアル性が重要なものではなく、正確にクライアントへ配信され、またリアル性の高い市場データの配信をなるべく妨げないことが重要となる。
【０００４】
図３は、従来のデータ配信システムによるプログラムデータの配信処理の動作フローチャート図である。
サーバよりクライアント側へ分割されたプログラム（プログラムブロック）を送信し、クライアント側にて受信処理を行う（Ｓ３０１）。
クライアント側は、プログラムブロックの最終ブロックを受信したかの判定を行う（Ｓ３０２）。
最終ブロック受信した時は、引き続きプログラムのブロック番号に抜けがあるかの判定を行い、抜けが有る場合を「異常」、抜けが無い場合を「正常」とする（Ｓ３０３）。ブロック番号の抜けの有無はＣＲＣ等のエラーチェックコード（ＣＲＣチェックコード）によりチェック判定される。
このステップＳ３０３にて、プログラムのブロック番号に抜けがなく「正常」の場合、正常受信した旨のメッセージをクライアントの画面に表示出力する（Ｓ３０４）。
一方、前述のステップＳ３０３にて、プログラムのブロック番号に抜けがあり「異常」の場合、異常（即ち、最終ブロックが未受信）の旨のメッセージをクライアントの画面に表示出力する（Ｓ３０５）。
この「正常」または「異常」受信か否かは、クライアント側の端末個々に個別であるため、異常受信したクライアント個々に保守員が配信されるべきプログラムのパッケージデータを持ち込んで、読み込み作業や入替作業等の各種作業が必要となる（Ｓ３０６）。
【０００５】
また、従来のサーバ／クライアント方式によるデータ配信システムに関連する技術として例えば特許文献１〜特許文献３などが公開されている。
【０００６】
【特許文献１】
特開２０００−９０１２８号公報
【０００７】
【特許文献２】
特開２００２−１０９２３６号公報
【０００８】
【特許文献３】
特開平１１−３１３０６１号公報
【０００９】
【発明が解決しようとする課題】
しかしながら、上記従来のデータ配信システムでは、サーバは市場データの他に、クライアント側での制御や処理に用いられるプログラムやプログラム更新データ、バッチ情報等の大容量のデータもクライアントへ配信する必要があるが、リアルタイムな配信を必要とする市場データを優先して配信する必要があり、大容量のプログラムデータ等により市場データを配信する際のトラフィックに影響が出てしまうという問題点がある。
【００１０】
また、プログラムデータ等の配信の際に異常受信したクライアント個々に保守員が配信されるべきプログラムのパッケージデータを持ち込んで、読み込み作業や入替作業等の各種作業が必要となり作業に要する手間が掛かるという問題点がある。
【００１１】
また、サーバより複数の端末であるクライアント側にプログラムデータ等を同報的に配信しており、配信後に任意のクライアントよりエラー情報を受け取った場合に、配信すべきプログラムデータの全部を配信（即ち再配信）することとなり、配信するデータ量が多く、配信時間も長くなるという問題点があった。さらに、配信後に幾つかの端末より時間差をおいてエラー情報が送られてくるような場合は、プログラムデータの全部を複数回に渡って再配信することもあり、運用の効率が悪いという問題点があった。
【００１２】
そこで本発明は上記従来の問題点に鑑みて為されたもので、市場データとは別にクライアント側での制御や処理に用いられるプログラムやプログラム更新データ、バッチ情報等の大容量のデータもクライアントへ配信することで、リアルタイムな配信を必要とする市場データを優先して配信し、大容量のプログラムデータ等が市場データの配信に際するトラフィックに影響が出さないようにするデータ配信システムを提供することを目的とする。
【００１３】
また、本発明は上記従来の問題点に鑑みて為されたもので、プログラムデータ等の配信の際に異常受信したクライアント個々に保守員によるプログラムデータの読み込み作業や入替作業等の各種作業を必要としないデータ配信システムを提供することを目的とする。
【００１４】
また、本発明は上記従来の問題点に鑑みて為されたもので、サーバより複数の端末であるクライアント側へのプログラムデータの同報的な配信後に任意のクライアントよりエラー情報を受け取った場合に、配信すべきプログラムデータの全部を再配信することなく必要なデータのみ配信することで、再配信するデータ量を少なくし、配信時間を短くし、システム全体の配信運用の効率を高くするデータ配信システムを提供することを目的とする。さらに、ネットワーク網の品質、接続端末台数などに応じて、適切な送信方法でプログラムデータ等の配信を行うデータ配信システムを提供することを目的とする。
【００１５】
【課題を解決するための手段】
上記従来の問題点を解決するため請求項１記載の発明は、複数のクライアントと、任意のデータを管理する少なくとも１つのサーバと、前記複数のクライアントに前記少なくとも１つのサーバより前記任意のデータを通信回線を介して配信するサーバ／クライアント方式のデータ配信システムにおいて、前記任意のデータは任意の数に分割されてブロックデータとし、該ブロックデータの各々に固有のブロック番号が付与されてサーバより配信する手段と、前記複数のクライアントの各々は前記ブロックデータの各々がエラーがあるか否かを判定する手段と、該判定の結果、エラーブロックがある場合は当該ブロック番号と共にエラーログ情報としてサーバに送信する手段と、該エラーログ情報を受信したサーバは、当該エラーログ情報に基づいて予め設定された送信手段を選定し、且つ必要なブロックデータを該当するクライアントに前記選定した送信手段により送信する手段と、を有することを特徴とするものである。
【００１６】
上記従来の問題点を解決するため請求項２記載の発明は、前記請求項１記載のデータ配信システムであって、サーバは、各クライアントから送信されるエラーログ情報を蓄積記憶し、該蓄積状態に応じてエラーログ情報の統計情報を算出し、該算出結果に基づいてサーバから該当するクライアントへの前記送信手段の選定を行う、ことを特徴とするものである。
【００１７】
上記従来の問題点を解決するため請求項３記載の発明は、前記請求項１または請求項２記載のデータ配信システムであって、前記サーバは、前記任意のデータ及び該任意のデータのエラーに基づくエラーブロックとは別に、他のサーバ手段より受信した時々刻々と変化する市場データを前記複数のクライアントに配信し、且つ、市場データを配信する時間帯と、任意のデータ及び該任意のデータのエラーに基づくエラーブロックとを配信する時間帯とを異ならせることを特徴とするものである。
【００１８】
【発明の実施の形態】
本発明の実施の形態について、図面を参照しながら説明する。
本発明は、前述した図１に示すようなデータ配信システムであって、証券、株式、金融等の市場データをサーバで受信し、複数のクライアントに配信するデータ配信システムにおいて、クライアント側での各種処理、制御に用いるプログラムやプログラム更新データ、バッチ情報等のプログラムデータをサーバ側より配信する際に、当該プログラムデータを分割し、且つ、サーバ／クライアント間のトラフィック情報に基づいてクライアントへ配信するものであり、これにより、サーバ装置の負荷が平準化されサーバ／クライアント間の回線上のトラフィック負荷を軽減し、または配信時間の短縮化を図り、クライアント側での各種処理、制御をスムーズに行うことのできるデータ配信システムとするものである。また、配信にはＴＣＰ／ＩＰ（ＴＣＰ：Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）やＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）等の簡易な送信プロトコルを選択的に用いることにより、より効率的な配信を行うものである。
【００１９】
図２は、本発明の実施の形態であるサーバからクライアントへ配信されるプログラムデータの電文形式である。
電文は、ヘッダ部とデータ部とトレーラ部より構成され、データ部には、分割されたプログラムのブロックの通番を示すブロック番号（ＢＬ１、ＢＬ２、…、ＢＬｎ）と、分割されたプログラム（プログラムブロック）がある。ここでプログラムブロックの最終は、最終ブロックであることを示す通番ＢＬｎ（最終ブロック番号）で構成される。そしてデータ部の前後には通信プロトコルのヘッダ部、ＣＲＣ等のエラーチェックコードなどを含むトレーラ部がある。
【００２０】
図４は、本発明の実施の形態であるクライアントにおける異常受信時のクライアントからサーバへ送信される結果連絡の電文である。
送信するクライアントの端末ＩＤと、エラーブロックの番号（ＥＢＬ１、ＥＢＬ２、…、ＥＢＬｎ）と、および全体の電文の長さである電文長から構成されて、当該クライアントにて異常受信さらたエラーブロックをサーバに通知する。
【００２１】
図５は、本発明の実施の形態であるサーバから各クライアントへ配信した配信結果の表示画面例である。
端末ＩＤ，ＩＰアドレス、送信（配信）結果、送信（配信）日時などを一覧表示するサーバの管理画面である。
【００２２】
図６は、本発明の実施の形態であるサーバから各クライアントへ配信した配信結果の詳細表示画面例である。
前述の図５において送信（配信）結果にエラーがあった場合の「項３、端末ＩＤ０００００３、…」をクリックし、当該エラーがあった端末ＩＤの、エラーブロックナンバー（Ｎｏ．）などを個別に表示するサーバの管理画面である。
【００２３】
図７は、本発明の実施の形態であるクライアントにおける正常受信時のクライアントからサーバへ送信される結果連絡の電文である。
端末ＩＤと、受信結果が正常であったことを示すフラグがセットされて、当該クライアントよりサーバに正常受信したことを通知する電文である。
【００２４】
図８は、本発明の実施の形態であるサーバからクライアントに電文を送信する場合の動作処理フローチャート図である。
サーバにおいて、送信方法が「手動設定」の場合、ＴＣＰ／ＩＰかＵＤＰかの送信方式の選定に移行し（Ｓ８０３）、送信方法が「自動設定」の場合、エラーレートが規定値以上か判定に移行する（Ｓ８０１）。
ステップＳ８０１による判定の結果、規定値以上＞エラーレート（エラーが多い場合）のクライアントの場合、例えば、ＴＣＰ／ＩＰで送信し（Ｓ８０１のＹ、Ｓ８０２）、またステップＳ８０１による判定の結果、規定値以上＜＝エラーレート（エラーが少ない場合）のクライアントの場合（Ｓ８０１のＮ）、次の送信処理の設定に移行する（Ｓ８０４）。
なお、送信方式の選択には、エラーレートのほか、接続端末台数、接続ネットワークの種類などの条件、またはそれらの複合条件が考えられる。
前述のステップＳ８０３により、送信方式「ＴＣＰ」を選定した場合はＴＣＰ／ＩＰにてプログラムを送信し（Ｓ８０５）、送信方式「ＵＤＰ」を選定した場合はさらに送信処理の設定が行われる（Ｓ８０４）。このように送信方式の選定は、操作による設定、または予め設定しておき、「ＴＣＰ」を選択時は、ＴＣＰ／ＩＰでプログラムを送信し、「ＵＤＰ」を選択時は、さらに送信処理の設定を行う。
なお、前述のステップＳ８０１により、送信方法が「自動設定」で、エラーレートが規定値以上＜＝エラーレート（エラーが少ない場合）のクライアントの場合にも、送信処理の設定が行われる（Ｓ８０４）。
【００２５】
ステップＳ８０４により、「ＵＤＰ」を選択時の送信処理の設定は、例えば以下の送信処理１、送信処理２、送信処理３に示すように幾つかの処理が設定される。なお、各送信処理（１、２、３）の詳細については後述する図１０、図１１、図１２を用いて説明する。
【００２６】
（送信処理１）送信回数を１回、エラーブロック（未受信ブロック）のログ取得をクライアント側で行う、エラーブロックの自動再送あり、とする場合の送信処理（Ｓ８０６）である。
この送信処理１のような送信処理は、各クライアントに配信するプログラムのバージョンアップに適している。例えば現行プログラムにてクライアントが動作している場合、この現行プログラムのバージョンアップを行う際に、クライアント側としては必ずしも直ぐにバージョンアップ後のプログラム処理での動作が必要ではない場合が多く、プログラムの各ブロックがクライアントにて完全に取得した後に、プログラムのバージョンアップすれば良いからである。
【００２７】
（送信処理２）送信回数を１回、エラーブロック（未受信ブロック）のログ取得をクライアント側で行う、エラーブロックの自動再送なし、とする場合の送信処理（Ｓ８０７）である。
この送信処理２のような送信処理は、クライアント毎に用いる新規のプログラム等に適している。例えばクライアントから要求される、予めサーバに保持している特定の表示処理プログラム等の場合、リアルタイムに配信される証券データ等が配信されなくなる少しの時間（例えば証券取引における前場と後場の間の時間帯）等に送信するものである。送信が完了しない場合はクライアントは当該プログラムの運用はできないこととなるが、元々空き時間に送信してもらうという比較的小規模なプログラムであり、リアルタイムに配信される証券データ等の配信に影響を与えないためのものである。
【００２８】
（送信処理３）送信回数をｎ回（任意の設定した回数）、エラーブロック（未受信ブロック）のログ取得をクライアント側で行わない、とする場合の送信処理（Ｓ８０８）である。
この送信処理３のような送信処理は、各種データのバッチ処理等に適している。例えばバッチ処理に使用される各種データには前日の証券データの合計値のデータ等があり、この合計値のデータ等について、旧データと新データが混在している場合にはクライアント側での統計処理等のデータの正確性を必要とする場合に無意味であり、旧データと新データの混在は好ましくない。そこでデータ全体を一括してクライアントが受信するまで（予め設定した回数まで）再送するものである。
【００２９】
図９は、本発明の実施の形態であるサーバからクライアントへのプログラムデータ送信（配信）の自動停止の動作処理フローチャート図である。
予め配信終了時刻を設定し（Ｓ９００）、サーバより各クライアントへプログラムデータの配信を行う（Ｓ９０１）。
ステップＳ９００にて設定された配信終了時刻になったかを監視し（Ｓ９０２）、終了時刻までは配信を継続、配信の終了時刻に達したら、配信完了したか否かの判定を行う（Ｓ９０３）。配信が完了していない、即ち配信未完了の場合（Ｓ９００のＮ）、配信済の最終ブロックＮＯ．の格納処理を行う（Ｓ９０４）。
そして次にクライアントからのエラーログ情報の収集、及び格納の処理を行う（Ｓ９０５）。なお、未配信のプログラムは次回のプログラム配信の際に配信を行う。
このように各クライアントへのプログラム配信は、クライアントが運用されていない時間帯等を利用して配信作業を行うことができて、全体として効率的なシステム運用が為される。
【００３０】
図１０〜図１２は、本発明の実施の形態であるサーバから電文が送信されてクライアントが受信する場合の動作処理フローチャート図（送信処理１、２、３）である。これらは前述した図８の各送信処理の選定において、予め電文の内容によって送信処理の選定が為されるように電文そのものに設定しておく。
【００３１】
図１０の送信処理１（図８のＳ８０６）について説明する。
まずサーバよりＵＤＰにて送信し（Ｓ１００１）、クライアント側はその受信したプログラムデータの受信処理を行う（Ｓ１００２）。
クライアント側は、最終ブロックを受信したかの判定を行う（Ｓ１００３）。そして最終ブロックを受信せず、一定時間経過しても次のブロックデータが受信されない場合にはタイムアウトとする（Ｓ１００４）。
ステップＳ１００３にて最終ブロックを受信した時は、各プログラムブロックのブロック番号に抜けがあるかの判定を行い、抜けが有る場合を「異常」、抜けが無い場合を「正常」とする（Ｓ１００５）。なおブロック番号の抜けの有無はＣＲＣ等のエラーチェックコード（ＣＲＣチェックコード）によりチェック判定される。
このステップＳ１００５にて、プログラムのブロック番号に抜けがなく「正常」の場合、正常受信した旨のメッセージをクライアントの画面に表示出力し（Ｓ１００６）、そして正常受信完了の旨の応答電文をサーバに返す（Ｓ１００７）。なおこの応答電文は前述した図７に示す電文となる。
一方、前述のステップＳ１００５にて、プログラムのブロック番号に抜けがある「異常」の場合、異常結果の連絡電文を当該クライアントからサーバに送信する（Ｓ１００８）。なおこの異常結果の連絡電文は前述した図４に示す電文となる。
サーバは、この異常結果の連絡電文を受信すると、エラーブロック部分のみをＴＣＰ／ＩＰにて送信する（Ｓ１００９）。
クライアントは、このエラーブロック部分を正常受信したかの判定を行い（Ｓ１０１２）、正常受信時は、前述のステップＳ１００６、ステップＳ１００７、の処理を行い、異常受信時はステップＳ１００８、ステップＳ１００９、の処理を繰り返し行う。
一方、前述のステップＳ１００４にてタイムアウトした場合は、当該クライアントが受信エラーであるとして「異常」とする旨の異常結果の連絡電文をサーバに送信する（Ｓ１０１０）。
そして、サーバはこの異常結果の連絡電文を受信すると、プログラム全体をＴＣＰ／ＩＰにて再送信する（Ｓ１０１１）。
クライアントは、この再送信によるプログラムブロック（全体）を正常受信したかの判定を行い（Ｓ１０１２）、正常受信時は、前述のステップＳ１００６、ステップＳ１００７、の処理を行い、異常受信時はステップＳ１００１の処理に戻り送信処理１を繰り返す。
【００３２】
図１１の送信処理２（図８のＳ８０７）について説明する。
まずサーバよりＵＤＰにて送信し（Ｓ１１００）、クライアント側はその受信したプログラムデータの受信処理を行う（Ｓ１１０１）。
クライアント側は、最終ブロックを受信したかの判定を行う（Ｓ１１０２）。そして最終ブロックを受信せず、一定時間経過しても次のブロックデータが受信されない場合にはタイムアウトとする（Ｓ１１０３）。
ステップＳ１１０２にて最終ブロックを受信した時は、各プログラムブロックのブロック番号に抜けがあるかの判定を行い、抜けが有る場合を「異常」、抜けが無い場合を「正常」とする（Ｓ１１０４）。なおブロック番号の抜けの有無はＣＲＣ等のエラーチェックコード（ＣＲＣチェックコード）によりチェック判定される。
このステップＳ１１０４にて、プログラムのブロック番号に抜けがなく「正常」の場合、正常受信した旨のメッセージをクライアントの画面に表示出力し（Ｓ１１０５）、そして正常受信完了の旨の応答電文をサーバに返す（Ｓ１１０６）。なおこの応答電文は前述した図７に示す電文となる。
一方、前述のステップＳ１１０４にて、プログラムのブロック番号に抜けがある「異常」の場合、異常受信した旨のメッセージをクライアントの画面に表示出力し（Ｓ１１０７）、異常結果の連絡電文を当該クライアントからサーバに送信する（Ｓ１１０８）。なおこの異常結果の連絡電文は前述した図４に示す電文となる。
一方、前述のステップＳ１００４にてタイムアウトした場合も、前述したステップＳ１１０７へ移行する。
なお、サーバは異常結果の連絡電文を受信すると、サーバは当該プログラムデータの送信を終了する。但し、クライアントの再度の要求や他のデータ配信に影響の無い範囲で再度本送信処理を繰り返すこともできる。
【００３３】
図１２の送信処理３（図８のＳ８０８）について説明する。
まずサーバは送信すべきプログラムデータを予め定めた任意の回数を送信するように設定しておき（Ｓ１２００）、そして当該プログラムデータをＵＤＰにて送信し（Ｓ１２０１）、クライアント側はその受信したプログラムデータの受信処理を行う（Ｓ１２０２）。
クライアント側は、最終ブロックを受信したかの判定を行う（Ｓ１２０３）。そして最終ブロックを受信せず、一定時間経過しても次のブロックデータが受信されない場合にはタイムアウトとする（Ｓ１２０７）。
ステップＳ１２０３にて最終ブロックを受信した時は、各プログラムブロックのブロック番号に抜けがあるかの判定を行い、抜けが有る場合を「異常」、抜けが無い場合を「正常」とする（Ｓ１２０４）。なおブロック番号の抜けの有無はＣＲＣ等のエラーチェックコード（ＣＲＣチェックコード）によりチェック判定される。
このステップＳ１２０４にて、プログラムのブロック番号に抜けがなく「正常」の場合、正常受信した旨のメッセージをクライアントの画面に表示出力し（Ｓ１２０５）、そして正常受信完了の旨の応答電文をサーバに返す（Ｓ１２０６）。なおこの応答電文は前述した図７に示す電文となる。
一方、前述のステップＳ１２０４にて、プログラムのブロック番号に抜けがある「異常」の場合、異常受信した旨のメッセージをクライアントの画面に表示出力し（Ｓ１２０８）、再送信（本送信処理を再度行う必要がある）の旨をサーバに返す（Ｓ１２０９）。なおこの際、返信回数ｎを１減じておくことでステップ２１２００にて設定された送信回数の規定値が０になるまで繰り返すことができるものとなる。
一方、前述のステップＳ１２０７にてタイムアウトした場合も、前述したステップＳ１２０８へ移行する。
【００３４】
図１３は、本発明の実施の形態であるサーバでのエラー情報のログ取得とエラーレート算出の動作処理フローチャート図である。
クライアントから送信されたエラー情報をサーバが取得し（Ｓ１３００）、取得したエラー情報は次に説明する図１４に示すエラー情報テーブルに格納される。そして、エラー情報から各クライアント毎のエラーレートなどの統計的データを算出する（Ｓ１３０１）。
例えば、エラーレート＝（エラーブロック数）／（総送信ブロック数）、など、各種の統計データを算出し、ネットワーク形態、接続クライアントの台数などに応じて、前述したステップＳ８０１に示す処理を行う。
【００３５】
図１４は、本発明の実施の形態であるサーバに記憶されるエラー情報を記憶するエラー情報テーブル図である。
このテーブル図は、サーバが保持しているエラー情報の格納テーブルを示しており、クライアント毎にユニークに付与される端末ＩＤ（Ｄ１４０１）、エラー情報の取得日時（Ｄ１４０２）、そのときの送信ブロック数（Ｄ１４０３）、エラーブロック数（Ｄ１４０４）、エラーブロック番号（Ｄ１４０５）などで構成される。
【００３６】
図１５は、本発明の実施の形態であるサーバから自動送信時における送信方法を定義した条件のテーブル図である。
送信の条件は、エラー率（Ｄ１５０１）、再送回数（例えばＴＣＰ／ＩＰで同一のプログラムデータを何回送信したかなど）（Ｄ１５０２）、接続端末台数（Ｄ１５０３）、ネットワークの構成や種類を示したネットワーク構成（Ｄ１５０４）が定義され、それらのパラメータに対し、ＵＤＰやＴＣＰ／ＩＰといった送信方法（Ｄ１５０５）が定義されている。
【００３７】
以上、説明したように本発明は以下の機能を有するデータ配信システムを提供する。
プログラムデータ等を分割し、その分割した各々のブロック番号と、最終ブロック番号には最終である旨を示す番号が付与されている構成の電文を配信プログラムデータ電文として配信する機能と、
配信されたプログラムデータ電文をクライアントが受信し、該受信したプログラムデータ電文中にエラーブロックが有る場合、その情報を当該クライアントがログし、サーバへ所定の電文形式で送信する機能と、
各クライアント毎に送信されたエラーログ情報を格納し、エラー情報から平均エラーレートなどの統計的情報を算出し、その算出値に対応し、送信（配信）方法を選択し、その送信方法によりプログラムデータ電文のエラーブロックに相当するブロックを配信する機能と、
エラーログ情報などを参酌し、各クライアント毎にプログラムデータ電文の送信方法を個別に自動設定、若しくは手動で設定する機能と、
を有するデータ配信システムである。
さらに、エラーログ情報を記憶保持することで、リアルタイムなデータ配信とは別の時間帯、別のタイミングにて、当該エラーログ情報に関わるエラーブロックを当該クライアントへ送信（配信）する機能を有することでより効率的な配信を可能とするデータ配信システムとなる。
【００３８】
したがって本発明によれば、以下の効果を有するデータ配信システムを提供することができる。
リアルタイム性を要する市場データ等の他にプログラムデータ等のクライアント側で使用する動作処理に関するデータをネットワークの形態に応じ、送信方法を容易に変更して配信が行える。
また、データの送受信にかかるエラーレート情報などの統計データを保持し、その結果にもとづき、自動的に送信（例えば、エラーなしのクライアントに対しては、例えばＵＤＰ送信、エラーレートが規定値以上の場合ＴＣＰ／ＩＰ送信）を行うことで、各クライアントへの配信、送信の効率が向上されて運用が簡易となる。さらに、エラーレートが低い場合、簡易なプロトコル（例えばＵＤＰ）を使用できるため、短時間で送信が行える。またさらに、エラーレートの統計データに基づき、その配信先毎に送信方法が設定でき、サーバから全クライアントへの送信時間のトータル時間の短縮化が図れ、運用時間の短縮化が図られ、個別にクライアント毎に対応する必要がない。
また、プログラムデータ等の配信時に、クライアント側でのエラーとなったエラーブロックのみを再送することにより、トラフィックの軽減が図れる。さらに、マルチキャスト等の方式でプログラム送信を行った場合においても、クライアントからサーバへエラー情報を返信し、サーバはクライアント側にエラーとなったブロックナンバーのみを再送するため、サーバからの再送信に関わる送信時間の短縮化が図れる。
また、エラー情報を保持しているため、異なるタイミング（市場データ等のリアルタイム性の必要な時間帯）にてそのエラーブロックのみ再送信が行え、運用が柔軟に行える。
これら送信時間の短縮化、通信帯域のトラフィックの軽減、平均化が図れるので他の情報（例えば次のデータ、別のデータ）の配信、送信が行え、回線の有効活用ができる。
【００３９】
即ち本発明は、クライアント側での制御や処理に用いられるプログラムデータ、バッチ情報等のデータをサーバより配信する場合、リアルタイムな配信を必要とする市場データを優先するために、プログラムデータ等が市場データの配信に際するトラフィックに影響が出さないようにするデータ配信システムを提供することを目的とし、そのため、任意のデータを任意に分割したブロックデータとし、該ブロックデータ各々にブロック番号が付与されてサーバより配信する手段と、クライアントは前記ブロックデータの各々にエラーがあるか否かを判定する手段と、該判定の結果、エラーブロックがある場合は当該ブロック番号と共にエラーログ情報としてサーバに送信する手段と、これを受信したサーバは、エラーログ情報に基づいて予め設定された送信手段を選定し、且つ必要なブロックデータを前記選定した送信手段により送信する手段とを有するサーバ／クライアント方式のデータ配信システムである。
【００４０】
【発明の効果】
本発明によれば、市場データとは別にクライアント側での制御や処理に用いられるプログラムやプログラム更新データ、バッチ情報等の大容量のデータもクライアントへ配信することで、リアルタイムな配信を必要とする市場データを優先して配信し、大容量のプログラムデータ等が市場データの配信に際するトラフィックに影響が出さないようにするデータ配信システムを提供することができる。
【００４１】
また、本発明によれば、プログラムデータ等の配信の際に異常受信したクライアント個々に保守員によるプログラムデータの読み込み作業や入替作業等の各種作業を必要としないデータ配信システムを提供することができる。
【００４２】
また、本発明によれば、サーバより複数の端末であるクライアント側へのプログラムデータの同報的な配信後に任意のクライアントよりエラー情報を受け取った場合に、配信すべきプログラムデータの全部を再配信することなく必要なデータのみ配信することで、再配信するデータ量を少なくし、配信時間を短くし、システム全体の配信運用の効率を高くするデータ配信システムを提供することを目的とする。さらに、ネットワーク網の品質、接続端末台数などに応じて、適切な送信方法でプログラムデータ等の配信を行うデータ配信システムを提供することができる。
【図面の簡単な説明】
【図１】データ配信システムのシステム構成図である。
【図２】本発明の実施の形態であるサーバからクライアントへ配信されるプログラムデータの電文形式である。
【図３】従来のデータ配信システムによるプログラムデータの配信処理の動作フローチャート図である。
【図４】本発明の実施の形態であるクライアントにおける異常受信時のクライアントからサーバへ送信される結果連絡の電文である。
【図５】本発明の実施の形態であるサーバから各クライアントへ配信した配信結果の表示画面例である。
【図６】本発明の実施の形態であるサーバから各クライアントへ配信した配信結果の詳細表示画面例である。
【図７】本発明の実施の形態であるクライアントにおける正常受信時のクライアントからサーバへ送信される結果連絡の電文である。
【図８】本発明の実施の形態であるサーバからクライアントに電文を送信する場合の動作処理フローチャート図である。
【図９】本発明の実施の形態であるサーバからクライアントへのプログラムデータ送信（配信）の自動停止の動作処理フローチャート図である。
【図１０】本発明の実施の形態である（送信処理１）サーバから電文が送信されてクライアントが受信する場合の動作処理フローチャート図である。
【図１１】本発明の実施の形態である（送信処理２）サーバから電文が送信されてクライアントが受信する場合の動作処理フローチャート図である。
【図１２】本発明の実施の形態である（送信処理３）サーバから電文が送信されてクライアントが受信する場合の動作処理フローチャート図である。
【図１３】本発明の実施の形態であるサーバでのエラー情報のログ取得とエラーレート算出の動作処理フローチャート図である。
【図１４】本発明の実施の形態であるサーバに記憶されるエラー情報を記憶するエラー情報テーブル図である。
【図１５】本発明の実施の形態であるサーバから自動送信時における送信方法を定義した条件のテーブル図である。
【符号の説明】
Ｓ８００〜Ｓ８０８…サーバからクライアントへの電文送信のフローチャートステップ、
Ｓ９００〜Ｓ９０５…電文送信の自動停止のフローチャートステップ、
Ｓ１００１〜Ｓ１０１２…送信処理１のフローチャートステップ、
Ｓ１１００〜Ｓ１１０８…送信処理２のフローチャートステップ、
Ｓ１２００〜Ｓ１２０９…送信処理３のフローチャートステップ、
Ｓ１３００〜Ｓ１３０１…エラー情報のログとエラーレート算出のフローチャートステップ、
Ｓ３０１〜Ｓ３０６…従来のサーバからクライアントへの電文送信のフローチャートステップ、
ＢＬ１〜ＢＬｎ…プログラムブロックナンバー及び分割プログラム、
ＥＢＬ１〜ＥＢＬｎ…エラーブロックナンバー、
Ｄ１４０１〜Ｄ１４０５…エラー情報のテーブルデータ、
Ｄ１５０１〜Ｄ１５０５…送信方法を定義したテーブルデータ。
【図１】
2004280406.tif 000003
【図２】
2004280406.tif 000004
【図３】
2004280406.tif 000005
【図４】
2004280406.tif 000006
【図５】
2004280406.tif 000007
【図６】
2004280406.tif 000008
【図７】
2004280406.tif 000009
【図８】
2004280406.tif 000010
【図９】
2004280406.tif 000011
【図１０】
2004280406.tif 000012
【図１１】
2004280406.tif 000013
【図１２】
2004280406.tif 000014
【図１３】
2004280406.tif 000015
【図１４】
2004280406.tif 000016
【図１５】
2004280406.tif 000017