"複数の建物にそれぞれ設置されて監視対象の設備機器の異常が検出されると異常情報を発報する端末装置と、これら複数の端末装置と通信回線を介して接続されて前記異常情報発報の配信先を管理する監視サーバと、前記異常情報発報が配信可能な1つ以上の自社監視センタおよび1つ以上の他社監視センタとを備えた遠隔監視システムにおいて、前記監視サーバが、前記自社監視センタと前記他社監視センタのそれぞれについて、未対応な前記異常情報発報の件数に基づき、該未対応件数が監視センタ毎に定めた過剰件数に達しているか否かを判断し、通報された異常情報発報の優先的な配信先である前記自社監視センタの未対応件数がその過剰件数に達しているときには、該異常情報発報を未対応件数がその過剰件数に達していない前記他社監視センタへ配信できるようにしたことを特徴とする遠隔監視システム。請求項1の記載において、前記監視サーバが、通報された前記異常情報発報の内容が緊急対応を要するものであるか否かを判定し、優先的な配信先が前記自社監視センタで緊急対応を要すると判定された前記異常情報発報については、未対応件数に拘らず該自社監視センタへ配信するようにしたことを特徴とする遠隔監視システム。前述した従来の遠隔監視システムは、自社監視対象の設備機器に関する異常情報発報は自社監視センタへ配信し、他社監視対象の設備機器に関する異常情報発報は他社監視センタへ配信するというものであるが、自社監視センタに異常情報発報が集中した際に他社監視センタが活用できる特別なバックアップ態勢が講じられているわけではない。そのため、広域災害などによって自社監視センタに各種の異常情報発報が集中すると、自社監視センタでは異常対応に手間取ってしまい、例えば、エレベータのかご内に乗客が閉じ込められて通報されたにも拘らず迅速に救出できない等の問題が発生し、態勢不備を指摘されかねない。本発明は、このような従来技術の実情に鑑みてなされたもので、その目的は、異常情報発報の集中時に他社監視センタが活用できるバックアップ態勢を講じて自社監視センタでの異常対応に支障をきたさないようにした遠隔監視システムを提供することにある。上記の目的を達成するために、本発明は、複数の建物にそれぞれ設置されて監視対象の設備機器の異常が検出されると異常情報を発報する端末装置と、これら複数の端末装置と通信回線を介して接続されて前記異常情報発報の配信先を管理する監視サーバと、前記異常情報発報が配信可能な1つ以上の自社監視センタおよび1つ以上の他社監視センタとを備えた遠隔監視システムにおいて、前記監視サーバが、前記自社監視センタと前記他社監視センタのそれぞれについて、未対応な前記異常情報発報の件数に基づき、該未対応件数が監視センタ毎に定めた過剰件数に達しているか否かを判断し、通報された異常情報発報の優先的な配信先である前記自社監視センタの未対応件数がその過剰件数に達しているときには、該異常情報発報を未対応件数がその過剰件数に達していない前記他社監視センタへ配信できるようにした。このように異常情報発報の配信先を管理する監視サーバが、自社監視センタや他社監視センタの未対応件数がそれぞれ過剰件数に達しているか否かを把握していれば、自社監視センタへの異常情報発報が集中しているときに、優先的な配信先が自社監視センタである異常情報発報を、未対応件数が過剰件数に達していない他社監視センタへ配信することによって、異常対応の停滞が回避しやすくなる。すなわち、この遠隔監視システムは、異常対応に余裕のある他社監視センタを活用してバックアップ態勢が強化されているため、広域災害などで自社監視センタに各種の異常情報発報が集中した場合にも、自社監視センタでの異常対応が円滑に行いやすくなる。上記の遠隔監視システムにおいて、監視サーバが、通報された異常情報発報の内容が緊急対応を要するものであるか否かを判定し、優先的な配信先が自社監視センタで緊急対応を要すると判定された異常情報発報については、未対応件数に拘らず該自社監視センタへ配信するようにしてあれば、緊急対応を要する異常情報例えばエレベータの閉じ込め事故等の発報には常に自社監視センタで対応できるため、致命的な対応遅れが回避しやすくなる。なお、この場合も、未対応件数が過剰件数に達している自社監視センタを優先的な配信先とする異常情報発報の内容が、緊急対応を要するものではない例えば空調設備の故障等と判定されたときには、これを他社監視センタへ配信して協力してもらうことで自社監視センタでの異常対応が円滑に行いやすくなり、且つ、緊急性の高い異常対応への協力を要請されるわけではないので他社監視センタ側の負担も軽減できる。本発明の遠隔監視システムによれば、自社監視センタや他社監視センタの未対応件数がそれぞれ過剰件数に達しているか否かを、異常情報発報の配信先を管理する監視サーバが把握しており、自社監視センタへの異常情報発報が集中しているときに、優先的な配信先が自社監視センタである異常情報発報を、未対応件数が過剰件数に達していない他社監視センタへ配信できるようになっている。したがって、広域災害などで自社監視センタに各種の異常情報発報が集中したときに、異常対応に余裕のある他社監視センタが活用できることになってバックアップ態勢が強化され、自社監視センタでの異常対応が円滑に行いやすくなる。以下、本発明の実施形態例に係る遠隔監視システムについて図1~図3を参照しながら説明する。図1に示すように、本実施形態例に係る遠隔監視システムで用いられる監視サーバ2は、通信回線7を介して自社監視センタ3および自社監視センタ4と接続されていると共に、通信回線8を介して他社監視センタ5と接続されている。これら各監視センタ3~5は、後述する端末装置を介して監視対象の設備機器を遠隔的に監視している。また、監視サーバ2は一般電話回線6を介して、監視エリアAに存する図示せぬ複数の建物にそれぞれ設置された端末装置1Anただしnは不特定な自然数。以下同や、監視エリアBに存する図示せぬ複数の建物にそれぞれ設置された端末装置1Bnと接続されている。端末装置群1A1~1Anに含まれる多くの端末装置は、自社監視対象の設備機器の動作状態を自社監視センタ3へ自動発報するためのものである。同様に、端末装置群1B1~1Bnに含まれる多くの端末装置は、自社監視対象の設備機器の動作状態を自社監視センタ4へ自動発報するためのものである。ただし、端末装置群1A1~1An,1B1~1Bnのうちの一部は、他社監視対象の設備機器の動作状態を他社監視センタ5へ自動発報するための端末装置である。なお、監視対象の設備機器とはエレベータや空調設備、電気設備、防犯装置、防災装置などであり、前記端末装置は監視対象の設備機器と電気的に接続されているため、電気信号の変化に基づき設備機器の異常や復旧状態等を端末装置が検知できるようになっている。端末装置群1A1~1An,1B1~1Bnに含まれる個々の端末装置は、監視対象の設備機器の異常が検出されると異常情報を発報し、この異常情報発報は一般電話回線6を介して監視サーバ2へ通報される。監視サーバ2では、受信した異常情報発報を所定の配信先へ送信する。すなわち、配信先が自社監視センタ3や自社監視センタ4の場合は、監視サーバ2から通信回線7を介して異常情報発報が送信され、配信先が他社監視センタ5の場合は、監視サーバ2から通信回線8を介して異常情報発報が送信される。これにより、自社監視センタ3,4や他社監視センタ5では、受信した異常情報発報の内容に応じた迅速な対応が可能となる。なお、本実施形態例では、他社監視センタ5での送受信が監視サーバ2に接続可能な通信機能を有する汎用パソコンによって行われるため、通信回線8としてインターネット回線を利用している。自社監視センタ3には複数の監視卓31~3nが設けられており、自社監視センタ4には複数の監視卓41~4nが設けられている。端末装置群1A1~1Anのうち自社監視対象の設備機器と接続されている自社端末装置から発報された異常情報は、通常は自社監視センタ3へ配信されて対応する監視卓例えば監視卓31に表示される。同様に、端末装置群1B1~1Bnのうち自社監視対象の設備機器と接続されている自社端末装置から発報された異常情報は、通常は自社監視センタ4へ配信されて対応する監視卓例えば監視卓41に表示される。また、端末装置群1A1~1An,1B1~1Bnのうち他社監視対象の設備機器と接続されている他社端末装置から発報された異常情報は、それぞれが他社監視センタ5として機能する他社監視卓51~5nに表示される。監視サーバ2には、端末装置群1A1~1An,1B1~1Bnとの接続を制御する回線制御装置21と、受信データや送信データを管理するための演算処理等を行う制御装置22と、制御装置22の指定したデータを記憶する記憶装置23と、自社監視センタ3,4や他社監視センタ5との送受信を制御する送受信制御装置24とが備えられており、記憶装置23には未対応件数管理テーブル23Aが設けられている。この未対応件数管理テーブル23Aには、監視センタ3~5別に、対応すべき異常情報発報のうち未対応な発報の件数未対応件数と、この未対応件数が過剰ではないと判断しうる上限の件数余裕限界件数とが記憶されており、未対応件数が余裕限界件数よりも1件多い過剰件数に達すると、その監視センタは異常対応に手間取る可能性が高まる。また、制御装置22には、端末装置からの異常情報発報の配信先を決定するための監視センタ対応指令部22Aが設けられている。この監視センタ対応指令部22Aは、通常時には、受信した異常情報発報をその優先的な配信先へと配信するが、前記未対応件数が前記過剰件数に達している自社監視センタ3や自社監視センタ4を配信先とする異常情報発報を受信し、その異常情報の内容が緊急対応を要するものでないと確認できたときには、配信先の変更を行うように指令する。その際、新たな配信先に選定する監視センタは異常対応に余裕のあることが前提となるため、例えば、優先的な配信先が自社監視センタ3である異常情報発報の新たな配信先として、自社監視センタ4が不適な場合は、未対応件数が過剰件数に達していない他社監視センタ5が選定されるようになっている。次に、監視サーバ2が端末装置からの異常情報発報の配信先を決定する際に行う処理手順を、図2のフローチャートを参照しながら説明する。端末装置からの異常情報発報を回線制御装置21が受信するステップS1と、制御装置22は、この異常情報発報のデータを図3に示す発報別情報テーブルFに書き込むステップS2。この発報別情報テーブルFには、受信連番の項目F1と、ビル名の項目F2と、異常発生時刻の項目F3と、監視設備名の項目F4と、異常状態の項目F5と、対応先コードの項目F6とが用意されており、ステップS2では項目F6を除く各項目F1~F5に異常情報発報のデータを書き込む。ここで、発報別情報テーブルFの各項目の内容について説明すると、項目F1の受信連番は、異常情報発報を受信する度に新規に採番されるコード番号例えば9桁の通し番号である。項目F2のビル名は、異常情報を発報した端末装置が設置されているビルの名称である。項目F3の異常発生時刻は、異常情報発報を受信した時刻である。項目F4の監視設備名は、異常が発生した監視対象の設備機器の名称である。項目F5の異常状態は、その設備機器の異常状態の内容ならびに対応優先度の重要度ランクであり、異常状態の内容が緊急対応を要する場合は、対応優先度がランクAに指定される。項目F6の対応先コードは、異常情報発報の配信先として監視センタ対応指令部22Aが最終的に決定した監視センタ名を示すコード番号である。図2のフローチャートへ戻り、ステップS2の後、制御装置22の監視センタ対応指令部22Aは、記憶装置23に記憶されているデータを参照して、受信した異常情報発報の優先的な配信先通常時の対応先がどの監視センタであるのかを確認するステップS3。すなわち、異常情報を発報する端末装置毎に、その異常情報発報の優先的な配信先がどの監視センタであるのかは、予め端末別対応先データとして記憶装置23に記憶されている。例えば、監視エリア1A内の端末装置群1A1~1Anの多くは優先的な配信先が自社監視センタ3であり、監視エリア1B内の端末装置群1B1~1Bnの多くは優先的な配信先が自社監視センタ4である。ステップS3の後、制御装置22の監視センタ対応指令部22Aは、受信した異常情報発報の優先的な配信先が自社監視センタ3または自社監視センタ4であるか否かを判定しステップS4、判定がYesの場合はステップS5へ進む。ただし、受信した異常情報発報の優先的な配信先が他社監視センタ5の場合は、ステップS4での判定がNoとなるため、ステップS14へ進んで対応可能な他社監視センタ5を探し、該当する他社監視センタ5例えば他社監視卓51を示すコード番号例えば051を発報別情報テーブルFの対応先コードの項目F6に書き込んだステップS15後、この異常情報発報を該当する他社監視センタ5へ配信ステップS16して処理を終了する。ステップS4での判定がYesの場合は、ステップS5において、受信した異常情報が監視エリア1A内の自社端末装置から発報されたものであるか否かを判定する。そして、ステップS5での判定がYesの場合は、次なるステップS6で、その異常情報発報の内容の緊急性を判定し、緊急対応を要する重要発報ではないと確認された場合はステップS7へ進む。すなわち、自社監視センタ3を優先的な配信先とする緊急性の高くない異常情報発報を受信した場合、ステップS6での判定がYesとなり、次なるステップS7において、自社監視センタ3の未対応件数が過剰件数未満であるか否かが判定される。前述したように、監視センタでは未対応件数が余裕限界件数を上回るつまり過剰件数に達すると、異常対応に手間取る可能性が高まる。また、この余裕限界件数は監視センタの規模に応じて予め設定されており、本実施形態例では、自社監視センタ3,4の余裕限界件数をいずれも10件とし、他社監視センタ5の余裕限界件数を例えば5件としている。ステップS7で自社監視センタ3の未対応件数が過剰件数未満10件以内であると判定された場合、自社監視センタ3は異常対応に余裕があると判断できるため、監視センタ対応指令部22Aは、自社監視センタ3を優先的な配信先とする緊急性の高くない異常情報発報を、通常どおり自社監視センタ3へ配信するという決定を下し、発報別情報テーブルFの対応先コードの項目F6に自社監視センタ3を示すコード番号例えば003を書き込むステップS8。そして、次なるステップS9で、この異常情報発報を送受信制御装置24を介して自社監視センタ3へ配信した後、処理を終了する。また、ステップS6での判定がNoの場合、つまり、自社監視センタ3を優先的な配信先とする異常情報発報が緊急対応を要する重要発報対応優先度がランクAであると判定された場合は、自社監視センタ3の未対応件数に拘らず、監視センタ対応指令部22Aは配信先を自社監視センタ3に決定して、発報別情報テーブルFの項目F6に自社監視センタ3を示すコード番号を書き込むステップS8。そして、この異常情報発報を自社監視センタ3へ配信ステップS9した後、処理を終了する。したがって、この場合、自社監視センタ3の未対応件数が余裕限界件数10件を上回ってしまうこともある。ただし、仮に未対応件数が過剰件数に達したとしても、エレベータのかご内に乗客が閉じ込められる等の緊急性の高い異常情報発報を受信したときには、迅速な対応が最優先されるため、自社監視センタ3では緊急性の高くない未対応な異常情報発報については後刻対応することとし、ある程度の対応遅れを容認する。一方、ステップS7で自社監視センタ3の未対応件数が過剰件数に達していると判定された場合はステップS17へ進んで、別の自社監視センタ4の未対応件数が過剰件数未満10件以内であるか否かが判定される。そして、ステップS17での判定がYesの場合、自社監視センタ4は異常対応に余裕があると判断できるため、監視センタ対応指令部22Aは、自社監視センタ3を優先的な配信先とする緊急性の高くない異常情報発報を、別の自社監視センタ4へ配信するという配信先変更の決定を下し、発報別情報テーブルFの対応先コードの項目F6に自社監視センタ4を示すコード番号例えば004を書き込むステップS12。そして、次なるステップS13で、この異常情報発報を送受信制御装置24を介して自社監視センタ4へ配信した後、処理を終了する。しかるに、ステップS17での判定がNoの場合は、別の自社監視センタ4の未対応件数も過剰件数に達している場合なので、監視センタ対応指令部22Aは、まず記憶装置23の未対応件数管理テーブル23Aを参照して、未対応件数が過剰件数未満例えば5件以内の他社監視センタ5を探しステップS14、該当する他社監視センタ5例えば他社監視卓51を、自社監視センタ3を優先的な配信先とする緊急性の高くない異常情報発報の配信先に決定する。つまり、監視センタ対応指令部22Aは、この異常情報発報をいずれかの他社監視センタ5へ配信するという配信先変更の決定を下し、発報別情報テーブルFの対応先コードの項目F6に該当する他社監視センタ5を示すコード番号例えば051を書き込むステップS15。そして、次なるステップS16で、この異常情報発報を送受信制御装置24を介して該当する他社監視センタ5へ配信した後、処理を終了する。一方、前記ステップS5での判定がNoの場合、つまり、受信した異常情報発報が監視エリア1A内の自社端末装置から発報されたものではないと判定された場合は、監視エリア1B内の自社端末装置から発報された異常情報発報であり、その優先的な配信先は自社監視センタ4であることがわかる。それゆえ、まずステップS10へ進んで、受信した異常情報発報の内容の緊急性を判定する。このステップS10において、緊急対応を要する重要発報ではないと確認された場合はステップS11へ進んで、自社監視センタ4の未対応件数が過剰件数未満10件以内であるか否かが判定される。ステップS11で自社監視センタ4の未対応件数が過剰件数未満であると判定された場合、自社監視センタ4は異常対応に余裕があると判断できるため、監視センタ対応指令部22Aは、自社監視センタ4を優先的な配信先とする緊急性の高くない異常情報発報を、通常どおり自社監視センタ4へ配信するという決定を下し、発報別情報テーブルFの項目F6に自社監視センタ4を示すコード番号を書き込むステップS12。そして、次なるステップS13で、この異常情報発報を自社監視センタ4へ配信した後、処理を終了する。また、ステップS10での判定がNoの場合、つまり、自社監視センタ4を優先的な配信先とする異常情報発報が緊急対応を要する重要発報対応優先度がランクAであると判定された場合は、自社監視センタ4の未対応件数に拘らず、監視センタ対応指令部22Aは配信先を自社監視センタ4に決定して、発報別情報テーブルFの項目F6に自社監視センタ4を示すコード番号を書き込むステップS12。そして、この異常情報発報を自社監視センタ4へ配信ステップS13した後、処理を終了する。したがって、この場合、自社監視センタ4の未対応件数が余裕限界件数10件を上回ってしまうこともあるが、前述したようにエレベータのかご内に乗客が閉じ込められる等の緊急性の高い異常情報発報を受信したときには迅速な対応が最優先されるため、自社監視センタ4では緊急性の高くない未対応な異常情報発報については後刻対応することとし、ある程度の対応遅れを容認する。一方、ステップS11で自社監視センタ4の未対応件数が過剰件数に達していると判定された場合は、ステップS18へ進んで、別の自社監視センタ3の未対応件数が過剰件数未満10件以内であるか否かが判定される。そして、ステップS18での判定がYesの場合、自社監視センタ3は異常対応に余裕があると判断できるため、監視センタ対応指令部22Aは、自社監視センタ4を優先的な配信先とする緊急性の高くない異常情報発報を、別の自社監視センタ3へ配信するという配信先変更の決定を下し、発報別情報テーブルFの項目F6に自社監視センタ3を示すコード番号を書き込むステップS8。そして、次なるステップS9で、この異常情報発報を自社監視センタ3へ配信した後、処理を終了する。しかるに、ステップS18での判定がNoの場合は、別の自社監視センタ3の未対応件数も過剰件数に達している場合なので、監視センタ対応指令部22Aは、まず記憶装置23の未対応件数管理テーブル23Aを参照して、未対応件数が過剰件数未満の他社監視センタ5を探しステップS14、該当する他社監視センタ5を、自社監視センタ4を優先的な配信先とする緊急性の高くない異常情報発報の配信先に決定する。そして、発報別情報テーブルFの項目F6に該当する他社監視センタ5を示すコード番号を書き込んでステップS15、この異常情報発報を該当する他社監視センタ5へ配信ステップS16した後、処理を終了する。以上説明したように、本実施形態例に係る遠隔監視システムでは、異常情報発報の配信先を管理する監視サーバ2が、自社監視センタ3,4や他社監視センタ5の未対応件数がそれぞれ過剰件数に達しているか否かを把握している。そして、自社監視センタ3または4への異常情報発報が集中しているときに、優先的な配信先が該自社監視センタ3または4である異常情報発報を、未対応件数が過剰件数に達していない別の自社監視センタ4または3や他社監視センタ5へ配信できるようになっている。したがって、広域災害などで自社監視センタ3または4に各種の異常情報発報が集中したときに、異常対応に余裕のある別の自社監視センタ4または3や他社監視センタ5が活用できることになってバックアップ態勢が強化され、自社監視センタ3,4での異常対応が円滑に行いやすくなる。また、本実施形態例に係る遠隔監視システムでは、監視サーバ2が、優先的な配信先が自社監視センタ3または4で緊急対応を要すると判定した異常情報発報については、未対応件数に拘らず該自社監視センタ3または4へ配信するようにしてある。それゆえ、エレベータのかご内に乗客が閉じ込められる等の緊急性の高い異常情報発報に対しては、常に自社監視センタで対応できることになり、致命的な対応遅れが回避しやすくなると共に、他社監視センタ5側の負担が軽減できる。なお、上記の実施形態例では、自社監視センタを2つ備えた遠隔監視システムについて例示したが、自社監視センタが1つだけ、あるいは3つ以上であっても、本発明を適用できることは言うまでもない。また、余裕限界件数や過剰件数は各監視センタの規模に応じて適宜設定されるので、上記の実施形態例で例示した件数に限定されるものではない。"