JP2002259264A - サーバ及びデータ送信方法 - Google Patents

Abstract

(57)【要約】 【課題】サーバから複数の端末にデータを送信するシス
テムにおいて、端末へのデータ送信の性能の低下を招か
ないようにすること。 【解決手段】複数の端末６１，６２，６３，６４に対し
てデータ送信するサーバ１は、端末６１，６２，６３，
６４へのデータ送信結果により内容が変更される、複数
の端末の状態に係る端末名のリストから構成される端末
状態管理テーブル４０と複数の端末の障害に係る端末名
のリストから構成される障害端末管理テーブル５０とを
備え、該テーブルに従って前記複数の端末６１，６２，
６３，６４にデータ送信する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、サーバから複数の
端末にデータを送信するサーバ及びサーバによるデータ
送信方法に関する。

【０００２】

【従来の技術】サーバ側から送信対象となる端末に対し
てデータを送信をするシステムでは、サーバ側の端末送
信プロセスは、送信データを指定送信先の端末に対して
順次送信をする。

【０００３】このような場合に、送信先の端末が非稼動
状態の場合、即ち、電源が入っていなかったり、業務ア
プリケーションが起動されていなかった場合には、サー
バ側のデータ送信要求に対して端末側は応答しない。

【０００４】この結果、サーバ側の端末送信プロセス
は、送信要求がタイムアウトするまで待たされる。タイ
ムアウトするまでの時間は１分以上となることが多いの
で、サーバ側の端末送信プロセスは、タイムアウトする
までの間待ち続け、次の送信データの処理をすることが
できない。

【０００５】更にこのような端末へのデータ送信が連続
した場合には、毎回タイムアウトするまで待たせられる
という問題がある。

【０００６】

【発明が解決しようとする課題】上述したように、サー
バから複数の端末にデータを送信するシステムにおい
て、稼動状態に無い端末に対してデータ送信が発生する
と、他の端末へのサーバ側から端末へのデータ送信の性
能が低下するという問題がある。

【０００７】本発明の目的は、サーバから複数の端末に
データを送信するシステムにおいて、端末へのデータ送
信の性能の低下を招かないようにしたサーバ及びサーバ
によるデータ送信方法を提供することにある。

【０００８】

【課題を解決するための手段】上記課題を解決するため
に本発明は、複数の端末に対してデータ送信するサーバ
において、前記端末へのデータ送信結果により内容が変
更される、前記複数の端末の状態に係る端末名のリスト
から構成される端末状態管理テーブルを備え、該テーブ
ルに従って前記複数の端末へのデータ送信の可否を制御
することを特徴とする。

【０００９】また本発明は、複数の端末に対してデータ
送信するサーバにおいて、前記端末へのデータ送信結果
により内容が変更される、前記複数の端末の障害に係る
端末名のリストから構成される障害端末管理テーブルを
備え、該テーブルに従って前記複数の端末へのデータ送
信の可否を制御することを特徴とする。

【００１０】上記課題を解決するために本発明は、サー
バによるデータ送信方法において、前記サーバは前記複
数の端末に係る端末名のリストから構成される端末状態
管理テーブルを備え、前記端末から稼動状態通知が送信
されたとき当該稼動状態通知に基づき前記端末状態管理
テーブルに該当端末名を登録し、前記端末から非稼動状
態通知が送信されたとき当該非稼動状態通知に基づき前
記端末状態管理テーブルから該当端末名を削除し、前記
端末へのデータ送信時には前記端末状態管理テーブルに
登録された端末のみにデータ送信する。

【００１１】上記課題を解決するために本発明は、サー
バによるデータ送信方法において、前記サーバは前記複
数の端末に係る端末名及び障害発生日時のリストから構
成される端末状態管理テーブルを備え、前記端末へのデ
ータ送信時に端末側が応答しなかったためにデータ送信
ができなかった場合に前記障害端末管理テーブルに該当
端末名を登録し、前記端末へのデータ送信の時に送信先
の端末名が前記障害端末管理テーブルに登録されている
場合には該当端末にデータ送信を実施せず、前記障害端
末管理テーブルに登録された全ての端末名に対して障害
発生日時から一定時間経過している場合には該当端末の
稼動確認を実施し該確認により稼動状態であれば前記障
害端末管理テーブルから該当端末名及び障害発生日時を
削除する動作を周期的に実行することを特徴とする。

【００１２】本発明のサーバ及びサーバによるデータ送
信方法によれば、端末状態管理テーブル及び障害端末管
理テーブルに送信先の端末の状態や障害状態を持たせ、
送信に際してはテーブルを参照することで、データ送信
可能な端末にデータ送信可能となるので、データ送信の
性能の低下を招かないようにすることができる。

【００１３】

【発明の実施の形態】以下、本発明に係るサーバ及びサ
ーバによるデータ送信方法の実施形態を、図面を参照し
て説明する。

【００１４】図１は、第１実施形態のシステム構成例を
示すブロック図である。

【００１５】本実施形態のサーバ１は、端末６１，６
２，６３，６４と接続されている。業務アプリケーショ
ン１１，１２，１３はサーバ１内のアプリケーションの
プロセスであり、これらの業務アプリケーション１１，
１２，１３が処理した結果、該当端末に対してデータ送
信が発生する。

【００１６】送信データキュー２０は、業務アプリケー
ション１１，１２，１３が端末６１，６２，６３，６４
にデータ送信する場合に、送信データ２１を送信データ
キュー２０に登録する。

【００１７】端末送信プロセス３０は、送信データキュ
ー２０に登録された送信データ２１を順次読み出して、
指定された送信先の端末６１，６２，６３，６４にデー
タを送信する。端末状態管理テーブル４０と障害端末管
理テーブル５０は、端末６１，６２，６３，６４の状態
を管理しておくテーブルであり、端末送信プロセス３０
がこのテーブルの内容を更新し、端末６１，６２，６
３，６４へのデータ送信時に制御用情報として参照して
いる。

【００１８】図２は、送信データ２１の構成例であり、
データ種別２１ｓ，送信先端未名２１ｔ，データバイト
サイズ２１ｂ，送信内容２１ｄから構成されている。送
信先端未名２１ｔは、複数の端末名を登録することも可
能であるが、ここでは説明を簡単にするため１つの端末
名の場合で説明する。

【００１９】図３は、端末状態管理テーブル４０の構成
例である。この端末状態管理テーブル４０の用い方とし
ては２つの方式がある。方式１は、あらかじめ送信先と
して可能性のある端末を全て登録しておくものであり、
初期状態では可能性のある全ての端末名が登録されてい
る。また、方式２は、端末から稼動状態通知のあった端
末だけを登録しておき、端末側から非稼動通知があった
場合には削除するものであり、初期状態では、端末名は
何も登録されていない。

【００２０】両方式においては、方式１では端末名をあ
らかじめ登録しておかなければならないので端末の増設
／撤去時に端末状態管理テーブル４０のメインテナンス
が必要になる。これに対し、方式２はその必要がない。
ここでは、方式２を採用した例を示す。

【００２１】端末状態管理テーブル４０は、登録件数４
００，♯１レコードの稼動状態の端末名４０１，♯２レ
コードの稼動状態の端末名４０２，♯３レコードの稼動
状態の端末名４０３，♯４レコードの稼動状態の端末名
４０４などから構成される。端末名が記入されていない
レコードが空きレコードとなる。

【００２２】図４は障害端末管理テーブル５０の構成例
である。

【００２３】この障害端末管理テーブル５０は、登録件
数５００，＃１レコード５０１，♯２レコード５０２な
どから構成され、♯１レコード５０１は、障害端末名５
０１ｔから構成される。なお、このレコードに、障害ス
テータスなどを追加することも可能である。

【００２４】上述した構成の下、図５を参照して端末か
ら端末状態変化の通知（稼動状態／非稼動状態）を受信
した場合の端末送信プロセス３０の動作を説明する。

【００２５】先ず、ステップＳ１０１にて端末から稼動
状態変化の通知を受信したか否かを判断し、端末６１，
６２，６３，６４から稼動状態の変化の通知を受信して
いる場合にはステップＳ１０２へ進み、そうでない場合
には終わりとなる。

【００２６】ステップＳ１０２では、通知内容が「稼動
状態」の通知であるか否かを判断し、該通知内容が「稼
動状態」であればステップＳ１０３へ進み、そうでなけ
ればステップＳ１０４へ進む。

【００２７】ステップＳ１０３では、端末状態管理テー
ブル４０を更新して、稼動状態の追加を行う。ここで、
端末状態管理テーブル４０のレコードに該当端末名、例
えば端末６１が登録済みかどうかを調べる。ここで端末
名、例えば端末６１が未登録であれば、今まで「非稼動
状態」であった端末が稼動状態になったことを意味して
いるので、空きレコードを探す。空きレコードとは端末
名が未記入のレコードとする。例えば、＃２レコードが
空きレコードであれば、このレコードに端末名である端
末６１を書込み、登録件数４００を＋１し、ステップＳ
１０４へ進む。また、端末名、例えば端末６１が登録済
みであれば、既に稼動状態にある端末から再度稼動状態
の通知がきたので何もせずに終わりとなる。

【００２８】ステップＳ１０４では、通知内容が「非稼
動状態」であるか否かを調べる。

【００２９】ここで、通知内容が「非稼動状態」であれ
ばステップＳ１０５へ進み、そうでなければ終わりとな
る。

【００３０】ステップＳ１０５は、端末状態管理テーブ
ル４０を更新して、稼動状態の削除を行う。ここで、端
末状態管理テーブル４０のレコードに端末名、例えば端
末６１が登録済みかどうかを調べる。端末名、例えば端
末６１が登録済みであり、そのレコードが♯１レコード
であるとすれば、♯１レコードの端末名をクリアし、登
録件数４００を−１し、終わりとなる。また端末名、例
えば端末６１が未登録であれば、既に非稼動状態にある
端末から再度非稼動状態の通知がきたので何もせずに終
わりとなる。

【００３１】次に図６及び図７を参照して端末にデータ
送信する場合の端末送信プロセス３０の動作を説明す
る。先ず、ステップＳ２０１にて、送信データキュー２
０から送信データ２１を取り出す。

【００３２】次に、ステップＳ２０２にて、キューは空
か否かを調べる。ここで、送信データキュー２０が空で
あれば終わりとなり、そうでなければステップＳ２０３
へ進む。

【００３３】ステップＳ２０３では、送信データから送
信先の端末名を抽出し、ステップＳ２０４に移行する。
すなわち、送信データ２１から送信先端未名２１ｔを得
る。例えば、端末６２であるとする。

【００３４】ステップＳ２０４では、送信先の端末は稼
動状態か否かを調べる。すなわち、端末状態管理テーブ
ル４０のレコードの稼動状態の端末名に、送信先端末
名、例えば端末６２が登録されているかどうかを調べ
る。ここで、送信先端末名として端末６２が登録されて
いればステップＳ２０５へ進み、登録されていなければ
ステップＳ２０６へ進む。

【００３５】ステップＳ２０５では、障害端末管理テー
ブル５０に送信先の端末名が登録されているか否かを調
べる。すなわち、障害端末管理テーブル５０のレコード
の障害端末名として送信先端末名、例えば端末６２が登
録されているかを調べる。ここで、送信先端末名、例え
ば端末６２が登録されていれば結合子Ｂ１を介してステ
ップＳ２０６へ進み、登録されていなければステップＳ
２０７へ進む。

【００３６】ステップＳ２０６では、送信データを破棄
し、そのログを残す。そして、送信先端未は、「非稼動
状態」又は「障害端末」であるので送信データは端末に
は送信しないで破棄する。また、破棄したことを示すロ
グを登録し、Ａ１に戻る。

【００３７】ステップＳ２０７では、送信データを端末
に送る。すなわち、送信先端末名として例えば端末６２
に送信データ２１を送信する。

【００３８】次に、ステップＳ２０８として送信は成功
したか否かを調べる。送信先端未として例えば端末６２
への送信が成功した場合はＡ１に戻り、そうでない場合
はステップＳ２０９へ進む。

【００３９】ステップＳ２０９では、障害端末管理テー
ブル５０に該当端末名を登録する。送信先端未への送信
が失敗した場合には、障害端末管理テーブル５０の空き
レコードを探す。例えば、＃１レコードが空きレコード
であったとする。♯１レコードの障害端末名５０１ｔに
端末名として端末６２を登録する。次に、登録件数５０
０を＋１とし、Ａ１へ戻る。

【００４０】以上のように本実施形態によれば、サーバ
側から送信対象となる端末に対してデータを送信するシ
ステムで、サーバ側の端末送信プロセスが、端末へのデ
ータ送信時のタイムアウト発生した場合に、以後該当端
末にデータを送信しないようにするデータ送信方式が実
現できる。

【００４１】具体的には、端末側のアプリケーション又
はシステムがフリーズした場合やハードウェア障害が生
じた場合、正規の手順を経ずに端末側の電源をいきなり
落とした場合、端末自身は正常であるがサーバから端末
までのネットワークの経路に通信障害が発生した場合、
又は一部の端末や一部のネットワーク経路などの障害が
発生した場合であっても、サーバから複数端末へのデー
タ送信するシステム全体の性能が低下することを回避す
ることができる。

【００４２】次に、図８を参照して本発明の第２実施形
態のサーバを説明する。

【００４３】本実施形態のサーバ１Ｂは、図１と異なる
端末監視プロセス３１及び障害端末管理テーブル５１を
備える。

【００４４】障害端末管理テーブル５１は、登録件数５
１０，＃１レコード５１１，＃２レコード５１２などか
ら構成され、＃１レコード５１１は、障害端末名５１１
ｔ，障害検知日時５１１ｊなどから構成される。このレ
コードに障害ステータスなどを追加することも可能であ
る。

【００４５】次に、図８に示す構成の下でサーバから端
末へのデータ送信方法について、図１０，図１１を参照
して説明する。

【００４６】先ず、ステップＳ３０１として送信データ
キュー２０から送信データを取り出す。ここで、ステッ
プＳ３０２としてキューは空か否かを調べる。送信デー
タキュー２０が空であれば終わりとなり、そうでなけれ
ばステップＳ３０３へ進む。

【００４７】ステップＳ３０３では、送信データから送
信先の端末名を抽出し、ステップＳ３０４に移行する。
ここで、送信データ２１から送信先端未名２１ｔを得
る。例えば、端末６２であるとする。

【００４８】ステップＳ３０４では、送信先の端末が稼
動状態か否かを調べる。すなわち、端末状態管理テーブ
ル４０のレコードの稼動状態の端末名に、送信先端未
名、例えば、端末６２が登録されているかどうかを調べ
る。ここで、送信先端未名として例えば端末６２が登録
されていればステップＳ３０５へ進み、登録されていな
ければステップＳ３０６へ進む。

【００４９】ステップＳ３０５では、障害端末管理テー
ブル５１に送信先の端末名が登録されているか否かを調
べる。すなわち、障害端末管理テーブル５１のレコード
の障害端末名として送信先端末名として、例えば端末６
２が登録されているかを調べる。そして、送信先端末名
として、例えば端末６２が登録されていれば結合子Ｃ２
を経てステップＳ３０６へ進み、登録されていなければ
結合子Ｂ２を経てステップＳ３０７へ進む。

【００５０】ステップＳ３０６では、障害端末管理テー
ブル５１の障害発生日時から一定時間以上経過している
か否かを調べる。例えば、障害端末管理テーブル５１の
♯１レコードの障害端末名５１１ｔに端末６２が登録さ
れているとすれば、障害発生日時５１１ｊを得る。ま
た、現在日時と障害発生日時５１１ｊを比較し、一定時
間以上の差があるかどうかを調べる。ここで、一定時間
以上の差がある場合はステップＳ３０７へ進み、そうで
ない場合ステップＳ３１０へ進む。

【００５１】ステップＳ３０７では、送信データを端末
に送る。すなわち、送信先端末名として、例えば端末６
２に送信データ２１を送信する。

【００５２】次に、ステップＳ３０８では、送信は成功
したか否かを調べる。送信先端末として、例えば端末６
２への送信が成功した場合ステップＳ３１１へ進み、失
敗した場合はステップＳ３０９へ進む。

【００５３】ステップＳ３０９では、障害端末管理テー
ブル５１に該当端末名を登録する。すなわち、障害端末
管理テーブル５１のレコードに該当端末名が登録されて
いるかを調べ、端末名が登録されている場合、例えば＃
２レコードであるとすれば、障害検知日時５１２ｊを現
在日時に更新して結合子Ａ２に移る。また、端末名が登
録されていない場合は空きレコードを探す。例えば♯１
レコードが空きレコードであったとすれば、♯１レコー
ドの障害端末名５１１ｔに端末名として、例えば端末６
２を登録し、また♯１レコードの障害検知日時５１１ｊ
に現在日時を書込み、そして登録件数５１０を＋１と
し、結合子Ａ２に移る。

【００５４】一方、ステップＳ３０６では、障害端末管
理テーブル５１の障害発生日時から一定時間以上経過し
ていない場合は、ステップＳ３１０に移行し、送信デー
タを破棄し、そのログを残し、結合子Ａ２に移る。ここ
で、送信先端末は、「非稼動状態」又は「障害端末」で
あるので送信データは端末には送信しないで破棄する。
また、破棄したことを示すログを登録するものとする。

【００５５】ステップＳ３１１では、障害端末管理テー
ブル５１に該当端末名が登録されていれば削除する。す
なわち、障害端末管理テーブル５１のレコードに該当端
末名が登録されているかを調べる。ここで、端末名が登
録されている場合、例えば♯２レコードであるとすれ
ば、♯２レコードの障害端末名５１２ｔをクリアし、♯
２レコードの障害検知日時５１２ｊをクリアし、登録件
数５１０を−１として、結合子Ａ２に移る。また、端末
名が登録されていない場合も、結合子Ａ２に移る。

【００５６】以上のように本実施形態によれば、先の実
施形態では、サーバから端末までのネットワーク経路の
通信障害が復旧した場合には、手動による復旧操作をし
ない限り端末送信プロセスから該当端末に対してデータ
送信は停止したままであるに対し、サーバから端末まで
のネットワーク経路の通信障害が復旧した場合には、手
動による復旧操作を行わなくても自動的に端末送信プロ
セスから該当端末に対してデータ送信が再開される仕組
みを組込んだデータ送信方式が実現できるので、ネット
ワークの経路の信頼性が低く、ネットワークの通信障害
がランダムかつ短時間で自動復旧するような場合におい
てもサーバ／端末間のデータ送信が安定して動作すると
いう効果があるのでシステム運用面でのシステム管理者
の負担が軽減される。

【００５７】次に、図１２を参照して本発明の第３実施
形態のサーバについて説明する。

【００５８】本実施形態では、先の実施形態に、端末監
視プロセス７０が追加された構成となっている。

【００５９】本実施形態における端末送信プロセス３０
は、図１では障害端末管理テーブル５０の更新及び参照
を行っていたが、図１２では参照のみを行うものとなっ
ている。また端末監視プロセス７０は、障害端末管理テ
ーブル５０の更新を担当する。

【００６０】次に、図１２に示す構成の下で、図１３を
参照して、端末から端末状態変化の通知（稼動状態／非
稼動状態）を受信した場合の端末送信プロセス３０及び
端末監視プロセス７０の動作を説明する。

【００６１】先ず、ステップＳ４０１では、障害端末管
理テーブル５１の最初のレコードを対象にする。ここ
で、＃１レコード５１１を対象とする。ステップＳ４０
２では、レコードは使用されているか否かを調べる。例
えば、♯１レコードが対象とする。障害端末名５１１ｔ
が未使用かどうかを調べる。ここで、障害端末名５１１
ｔが未使用であればステップＳ４０７へ進み、使用され
ていればステップＳ４０３へ進む。

【００６２】ステップＳ４０３では、障害発生日時から
一定時間以上経過したか否かを調べる。例えば、＃１レ
コードを対象とする。すなわち、現在日時と障害発生日
時５１１ｊを比較し、一定時間以上の差があるかどうか
を調べる。ここで、一定時間以上の差がある場合ステッ
プＳ４０４へ進み、そうでない場合ステップＳ４０６へ
進む。

【００６３】次に、ステップＳ４０４において、該当端
末の稼動状態を確認する。すなわち、ネットワーク導通
又は端末アプリケーションとの生存確認通信により該当
端末の稼動状態を確認する。

【００６４】次に、ステップＳ４０５において、該当端
末は稼動状態か否かを調べる。すなわち、該当端末が稼
動状態であればステップＳ４０６へ進み、そうでなけれ
ばステップＳ４０７へ進む。

【００６５】ステップＳ４０６では、障害端末管理テー
ブル５１から該当端末のレコードを削除する。例えば、
♯１レコードが対象とする。ここで、♯１レコードの障
害端末名５１１ｔをクリアし、♯１レコードの障害検知
日時５１１ｊをクリアし、登録件数５１０を−１とし、
ステップＳ４０７に進む。

【００６６】ステップＳ４０７では、障害端末管理テー
ブル５１に登録されている全てのレコードに対して処理
したか否かを調べる。ここで、障害端末管理テーブル５
１の全てのレコードに対して処理した場合はステップＳ
４０９へ進み、そうでない場合はステップＳ４０８へ進
む。

【００６７】ステップＳ４０８では、次のレコードを対
象にする。障害端末管理テーブル５１の次のレコードを
対象にし、結合子Ｂ３に進む。

【００６８】また、ステップＳ４０９にてある時間の
間、遅延して、結合子Ａ３に進む。

【００６９】このように本実施形態によれば、先の実施
形態の効果に加えて、サーバから端末までのネットワー
ク経路の通信障害が復旧した場合には、手動による復旧
操作を行わなくても自動的に端末送信プロセスから該当
端末に対してデータ送信が再開される仕組みを組込んだ
データ送信方式が実現できるので、ネットワークの経路
の信頼性が低く、ネットワークの通信障害がランダムか
つ短時間で自動復旧するような場合においてもサーバ／
端末間のデータ送信が安定して動作するという効果があ
るのでシステム運用面でのシステム管理者の負担が軽減
される。

【００７０】さらに、本実施形態では、図１に示す構成
に端末監視プロセス７０を付加する形式で実現できるの
で、システムの運用状況により、後から機能追加するこ
とが容易となる。

【００７１】

【発明の効果】以上のように本発明によれば、サーバか
ら複数の端末にデータを送信するシステムにおいて、端
末へのデータ送信の性能の低下を招かないようにするこ
とが可能となる。

【図面の簡単な説明】

【図１】本発明に係るサーバ及びデータ送信方法の第１
実施形態のシステム構成例を示す図。

【図２】同実施形態における送信データの構成例を示す
図。

【図３】同実施形態における端末状態管理テーブルの構
成例を示す図。

【図４】同実施形態における障害端末管理テーブルの構
成例を示す図。

【図５】同実施形態のシステムにおける端末から稼動状
態変化の通知を受信した場合の端末送信プロセスの動作
を示すフローチャート。

【図６】同実施形態における端末にデータ送信する場合
の端末送信プロセスの動作を示すフローチャート。

【図７】同実施形態における端末にデータ送信する場合
の端末送信プロセスの動作を示すフローチャート。

【図８】本発明に係るサーバ及びデータ送信方法の第２
実施形態のシステム構成例を示す図。

【図９】同実施形態における障害端末管理テーブルの構
成例を示す図。

【図１０】同実施形態における端末にデータ送信する場
合の端末送信プロセスの動作を示すフローチャート。

【図１１】同実施形態における端末にデータ送信する場
合の端末送信プロセスの動作を示すフローチャート。

【図１２】本発明に係るサーバ及びデータ送信方法の第
３実施形態のシステム構成例を示す図。

【図１３】同実施形態における端末監視プロセスの動作
を示すフローチャート。

【符号の説明】

１…サーバ １１，１２，１３…業務アプリケーション ２０…送信データキュー ３０，３０´，３１…端末送信プロセス ４０…端末状態管理テーブル ５０，５１…障害端末管理テーブル ６１，６２，６３，６４…端末 ７０…端末監視プロセス

Claims (9)

【特許請求の範囲】
1. 【請求項１】 複数の端末に対してデータ送信するサー
   バにおいて、 前記端末へのデータ送信結果により内容が変更される、
   前記複数の端末の状態に係る端末名のリストから構成さ
   れる端末状態管理テーブルを備え、該テーブルに従って
   前記複数の端末へのデータ送信の可否を制御することを
   特徴とするサーバ。
2. 【請求項２】 複数の端末に対してデータ送信するサー
   バにおいて、 前記端末へのデータ送信結果により内容が変更される、
   前記複数の端末の障害に係る端末名のリストから構成さ
   れる障害端末管理テーブルを備え、該テーブルに従って
   前記複数の端末へのデータ送信の可否を制御することを
   特徴とするサーバ。
3. 【請求項３】 前記障害端末管理テーブルの内容変更を
   司る端末監視プロセスを備え、前記テーブルに従って前
   記複数の端末にデータ送信することを特徴とする請求項
   ２記載のサーバ。
4. 【請求項４】 複数の端末に対しサーバからデータを送
   信するデータ送信方法において、 前記サーバは前記複数の端末に係る端末名のリストから
   構成される端末状態管理テーブルを備え、 前記端末から稼動状態通知が送信されたとき当該稼動状
   態通知に基づき前記端末状態管理テーブルに該当端末名
   を登録し、前記端末から非稼動状態通知が送信されたと
   き当該非稼動状態通知に基づき前記端末状態管理テーブ
   ルから該当端末名を削除し、前記端末へのデータ送信時
   には前記端末状態管理テーブルに登録された端末にデー
   タ送信することを特徴とするサーバによるデータ送信方
   法。
5. 【請求項５】 前記サーバは、前記複数の端末に係る端
   末名のリストから構成される障害端末管理テーブルを備
   え、 前記サーバから前記端末へのデータ送信時に端末側が応
   答しなかったためにデータ送信ができなかった場合に前
   記障害端末管理テーブルに該当端末名を登録し、前記端
   末へのデータ送信の時に送信先の端末名が前記障害端末
   管理テーブルに登録されている場合には該当端末にデー
   タ送信を実施しないことを特徴とする請求項４記載のサ
   ーバによるデータ送信方法。
6. 【請求項６】 前記サーバの前記障害端末管理テーブル
   は前記端末の障害発生日時のデータ項目を有し、 前記サーバから前記端末へのデータ送信時に前記端末側
   が応答しなかったためにデータ送信ができなかった場合
   に前記障害端末管理テーブルに該当端末名及び障害発生
   日時を登録し、前記端末へのデータ送信の時に送信先の
   端末名が前記障害端末管理テーブルに登録されており且
   つ障害発生日時から一定時間経過している場合に該当端
   末にデータ送信を実施し送信が成功すれば前記障害端末
   管理テーブルから該当端末名及び障害発生日時を削除し
   自動復旧することを特徴とする請求項４又は５記載のサ
   ーバによるデータ送信方法。
7. 【請求項７】 前記端末へのデータ送信時に送信先の端
   末名が前記障害端末管理テーブルに登録されており且つ
   障害発生日時から一定時間経過している場合に該当端末
   にデータ送信を実施し、送信が失敗すれば前記障害端末
   管理テーブルの該当端末名に対応した障害発生日時を更
   新することを特徴とする請求項３記載のサーバによるデ
   ータ送信方法。
8. 【請求項８】 複数の端末に対しサーバからデータを送
   信するデータ送信方法において、 前記サーバは前記複数の端末に係る端末名及び障害発生
   日時のリストから構成される端末状態管理テーブルを備
   え、 前記端末へのデータ送信時に端末側が応答しなかったた
   めにデータ送信ができなかった場合に前記障害端末管理
   テーブルに該当端末名を登録し、前記端末へのデータ送
   信の時に送信先の端末名が前記障害端末管理テーブルに
   登録されている場合には該当端末にデータ送信を実施せ
   ず、前記障害端末管理テーブルに登録された全ての端末
   名に対して障害発生日時から一定時間経過している場合
   には該当端末の稼動確認を実施し該確認により稼動状態
   であれば前記障害端末管理テーブルから該当端末名及び
   障害発生日時を削除する動作を周期的に実行することを
   特徴とするサーバによるデータ送信方法。
9. 【請求項９】 前記障害端末管理テーブルに登録された
   全ての端末名に対して障害発生日時から一定時間経過し
   ている場合には該当端末の稼動確認を実施し該確認によ
   り非稼動状態であれば前記障害端末管理テーブルの該当
   端末名に対応した障害発生日時を更新することを特徴と
   する請求項８記載のサーバによるデータ送信方法。