(57)【要約】【課題】被監視部からの警報情報を監視メールとして監視サーバーからクライアントに送信する監視制御方法に関し、クライアントに於ける警報情報の収集及び処理の迅速化を図る。【解決手段】各種センサを含む被監視部５からの警報情報を監視サーバー１に通知し、この監視サーバー１からクライアント２に通知し、このクライアント２に於いて監視制御を行う監視制御方法であって、監視サーバー１は、被監視部５からの警報情報により警報メール（ＸＭＬメール）を作成してメールボックス３に着信メールとして一旦格納し、クライアント２にメール着信を通知し、クライアント２は、メールボックス３内の警報メール（ＸＭＬメール）を受信して、ウェブブラウザ４により警報情報を処理する過程を含むものである。【選択図】      図１
2004178241.tif 000002
【特許請求の範囲】
【請求項１】
被監視部からの警報情報を監視サーバーに通知し、該監視サーバーからクライアントに通知し、該クライアントに於いて監視制御を行う監視制御方法に於いて、
前記監視サーバーは、前記被監視部からの警報情報により警報メールを作成してメールボックスに着信メールとして一旦格納し、前記クライアントにメール着信を通知し、該クライアントは前記メールボックス内の警報メールを受信して、ウェブブラウザにより警報情報を処理する過程を含む
ことを特徴とする監視制御方法。
【請求項２】
前記監視サーバーは、前記被監視部からの警報情報に従ってＸＭＬメール作成アプリケーションによりメールヘッダ部と警報データ部とからなる警報メールを作成して前記メールボックスに受信メールとして一旦格納し、ＩＭＰＡ４管理アプリケーションにより前記クライアントにメール着信を通知し、該クライアントからの指示に従って前記メールボックスに格納された警報メールを前記ＩＭＡＰ４管理アプリケーションにより転送する過程を含むことを特徴とする請求項１記載の監視制御方法。
【請求項３】
前記監視サーバーの前記ＸＭＬメール作成アプリケーションは、予め設定した時間内で同時的に発生した複数の警報情報を、警報データ部に集約して１通の警報メールを作成する過程を含むことを特徴とする請求項１又は２記載の監視制御方法。
【請求項４】
前記監視サーバーの前記ＸＭＬメール作成アプリケーションにより作成して前記メールボックスに格納する警報メールは、前記警報情報の発生時刻情報を含み、前記クライアントの前記ウェブブラウザを起動した時に、前記監視サーバーのメールボックスに格納されている警報メールについて、前記ウェブブラウザの起動時刻から予め設定した時間前の時刻までの前記警報メールを検索し、前記クライアントに検索結果の警報メールを転送する過程を含むことを特徴とする請求項１乃至３の何れか１項記載の監視制御方法。
【請求項５】
前記クライアントのアプレットの処理により、前記監視サーバーの前記メールボックスから複数の警報メールを受信データバッファに受信蓄積し、該受信データバッファに蓄積された警報メールについて、ウェブブラウザのスクリプトに１通毎にイベント通知を行ってイベント抑止を行い、前記スクリプトのイベント処理後のイベント抑止解除メソッドに従って、前記アプレットは次の警報メールについてのイベント通知を行ってイベント抑止を行う処理を繰り返す過程を含むことを特徴とする請求項１乃至４の何れか１項記載の監視制御方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、各種のセンサ等を含む被監視部からの警報情報を監視サーバーが受信して警報メールを作成し、この警報メールをウェブ（Ｗｅｂ）ブラウザを有するクライアントに伝送し、クライアントに於いて被監視部の状態の監視制御を行う監視制御方法に関する。
【０００２】
【従来の技術】
各種センサやテレビカメラ等により被監視部の状態を監視し、異常状態を警報情報として端末から監視センタに伝送し、監視センタに於いて警報情報を表示して監視制御する各種の監視システムが知られている。その場合、異常状態発生により直ちに警報情報を監視センタに送出するシステムと、監視センタからのポーリングにより警報情報を送出するシステムとに大別することができる。
【０００３】
又侵入センサ等の各種のセンサと、侵入者等を撮影するディジタルカメラと、ガラス破壊等の異常音を集音するマイクロホンと、通信処理する端末とを含む監視ユニットと、監視情報を受信処理する監視者側端末との間を、インターネットを介して接続し、各種センサによる検出情報と、ディジタルカメラによる撮像画像情報と、マイクロホンにより集音した音声情報とを含む警報情報を、電子メール形式で伝送する比較的小規模の監視システムが知られている（例えば、特許文献１参照）。
【０００４】
又一般の電子メールの送受信システムに於いて、ファイアウォールより内側の基幹メールサーバーと、ファイアウォールより外側のリモートメールサーバーとのメールボックスのメール内容が同一となるように一元管理し、又ＩＭＡＰ４（Ｉｎｔｅｒｎｅｔ  Ｍｅｓｓａｇｅ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ  Ｖｅｒｓｉｏｎ  ４）を適用し、ファイアウォールより内側からのメールサーバーへのアクセスは、基幹メールサーバーに対して行い、ファイアウォールより外側からのメールサーバーへのアクセスは、リモートメールサーバーに対して行うことにより、ファイアウォールに対して内側と外側との端末から、セキュリティを維持して電子メールの送受信を行う電子メール管理システムが知られている（例えば、特許文献２参照）。
【０００５】
【特許文献１】
特開２００２−４２２７３号公報
【特許文献２】
特開平１１−２６６２７９号公報
【０００６】
【発明が解決しようとする課題】
従来の監視センタからポーリングを行って警報情報を収集する監視システムに於いては、ポーリング間隔を短くすると、監視センタの処理負荷が大きくなる問題があり、反対にポーリング間隔を長くすると、迅速に警報情報を収集できない問題がある。又異常状態発生により警報情報を監視センタに送出する監視システムに於いては、複数箇所から同時的に警報情報が発生した場合に、監視センタでは同時的な処理が困難となる問題がある。
【０００７】
又前述の特許文献１に示すように、警報情報を電子メール形式でインターネットを介して伝送するシステムに於いて、被監視部からの警報情報を受信した監視サーバーが、警報情報を電子メールとして、ウェブ（Ｗｅｂ）ブラウザを備えたクライアントにインターネット等のネットワークを介して伝送する場合に、監視サーバーとクライアントとの間にファイアウォールを設けたシステムに於いては、ウェブアプリケーションに通知できない場合が生じる。このような場合に、前述の特許文献２に記載されているように、ファイアウォールの内外にメールサーバを設けて同期をとることが考えられるが、二重化したメールサーバーによるコストアップと、それらの間の同期をとる為の処理が余分となる問題がある。
【０００８】
又クライアントを立上げてメーラーを起動した時に、メールサーバーに保管されている総てのメールを読出すシステムが一般的である。従って、警報情報を電子メールとして送信するシステムに於いては、必要でなくなった過去の古いメールまでも読出して、無駄な処理が増加する問題がある。
【０００９】
本発明は、前述の従来の問題点を解決するもので、クライアントの処理負担の増加がなく、迅速に監視サーバーからの警報情報を収集してウェブブラウザ上でリアルタイムで処理可能とすることを目的とする。
【００１０】
【課題を解決するための手段】
本発明の監視制御方法は、図１を参照して説明すると、被監視部５からの警報情報を監視サーバー１に通知し、この監視サーバー１からクライアント２に通知し、このクライアント２に於いて監視制御を行う監視制御方法に於いて、監視サーバー１は、被監視部５からの警報情報により警報メールを作成してメールボックス３に着信メールとして一旦格納し、クライアント２にメール着信を通知し、クライアント２は、メールボックス３内の警報メールを受信して、ウェブブラウザ４により警報情報を処理する過程を含むものである。
【００１１】
又監視サーバー１は、被監視部５からの警報情報に従ってＸＭＬメール作成アプリケーションによりメールヘッダ部と警報データ部とからなる警報メールを作成して、メールボックス３に受信メールとして一旦格納し、ＩＭＰＡ４管理アプリケーションにより、クライアント２にメール着信を通知し、クライアント２からの指示に従って、メールボックス３に格納された警報メールを、ＩＭＡＰ４管理アプリケーションにより転送する過程を含むものである。又監視サーバー１のＸＭＬメール作成アプリケーションは、予め設定した時間内で同時的に発生した複数の警報情報を、警報データ部に集約して１通の警報メールを作成する過程を含むことものである。又監視サーバー１のＸＭＬメール作成アプリケーションにより作成してメールボックス３に格納する警報メールは、警報情報の発生時刻情報を含み、クライアント２のウェブブラウザ４を起動した時に、監視サーバー１のメールボックス３に格納されている警報メールについて、ウェブブラウザ４の起動時刻から予め設定した時間前の時刻までの警報メールを検索し、クライアント２に検索結果の警報メールを転送する過程を含むものである。
【００１２】
又クライアント２のアプレットの処理により、監視サーバー１のメールボックス３から複数の警報メールを受信データバッファに受信蓄積し、この受信データバッファに蓄積された警報メールについて、ウェブブラウザ４のスクリプトに１通毎にイベント通知を行ってイベント抑止を行い、スクリプトのイベント処理後のイベント抑止解除メソッドに従って、アプレットは次の警報メールについてのイベント通知を行ってイベント抑止を行う処理を繰り返す過程を含むものである。
【００１３】
【発明の実施の形態】
図１は本発明の実施の形態のシステム構成の概要説明図であり、１は監視サーバー、２はクライアント、３はメールボックス、４はウェブブラウザ、５は被監視部を示す。この被監視部５は、不法侵入者検知用のセンサや火災発生検知用のセンサ等の各種のセンサ又はテレビカメラ等を含み、異常状態発生を検出すると、センサの種別等を含む警報情報を監視サーバー１に送出する。又監視サーバー１とクライアント２との間は、ＬＡＮ（ローカル・エリア・ネットワーク）やインターネット等のネットワークを介して接続されている。
【００１４】
監視サーバー１は、各種センサ等を含む被監視部５からの警報情報により警報メールを作成してメールボックス３に着信メールとして一旦格納し、クライアント２にメール着信を通知し、クライアント２は、メールボックス３内の警報メールを受信して、ウェブブラウザ４により警報情報を処理する過程を含むものである。
【００１５】
この場合、監視サーバー１は、被監視部５からの警報情報受信により、メールヘッダ部と警報データ部とを含む警報メールを作成するもので、この警報メールをＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）メールとして作成する。そして、このＸＭＬメールをメールボックス３に受信メールと見做して一旦格納し、クライアント２にメール着信を通知する。クライアント２は、メールボックス３からＸＭＬメールを受信して、ウェブブラウザ４により警報情報を表示する。又メールボックス３に格納する最大メール数を管理し、最大メール数を超えた時は、最も古いメールから順に削除して、新しいメールを格納する。この場合、メールボックス３から削除されても、図示を省略したデータベースにより警報情報を管理している。
【００１６】
図２は監視サーバーのアプリケーション説明図であり、１１は警報受信アプリケーション、１２はＸＭＬメール作成アプリケーション、１３は警報管理データベース、１４はＩＭＡＰ４管理アプリケーション、１５は受信データメールボックスを示す。
【００１７】
被監視部から警報発生として通知を、監視サーバーの警報受信アプリケーション１１が受信すると、その警報情報を、警報管理データベース１３に格納すると共に、ＸＭＬメール作成アプリケーション１２にメール作成依頼を行う。このＸＭＬメール作成アプリケーション１２は、ＭＩＭＥ（ＭｕｌｔｉｐｕｒｐｏｓｅＩｎｔｅｒｎｅｔ  Ｍａｉｌ  Ｅｘｔｅｎｓｉｏｎｓ）エンコードとして示すように、作成したＸＭＬメールをエンコードして受信データメールボックス１５に格納する。この場合のメールは、インターネットメールフォーマットに従って、メールヘッダ部と警報データ部とを含むものである。
【００１８】
又ＸＭＬメールのメールヘッダ部には、アプリケーションや警報種別、送信先、送信元等を含むものであり、又警報データ部は、警報発生時刻、警報内容等をＸＭＬタグの内容とするものである。又ＩＭＡＰ４管理アプリケーション１４は、受信データメールボックス１５に格納されたＸＭＬメールを受信メールとして取扱い、クライアントにメール着信を通知する。この場合の受信データメールボックス１５は、図１のメールボックス３に相当する。又ＩＭＡＰ４管理アプリケーション１４の処理により、ＩＭＡＰ４の１４３ポートを使用するもので、監視サーバー１とクライアント２との間に、ファイアウォールが設置されている場合でも、このポート番号の設定により、ＸＭＬメールの送受信が可能となる。
【００１９】
図３はＸＭＬメールの説明図であり、ＸＭＬメール作成アプリケーション１２（図２参照）により作成したＸＭＬメールの一例を示し、メールヘッダ部と警報データ部とを有し、メールヘッダ部は、日時情報やＭＩＭＥのバージョン情報等を含み、且つ通知を受けたアプリケーションの種別や警報の種別に従ってＳｕｂｊｅｃｔ，Ｆｒｏｍ，Ｔｏを編集する。又警報データ部は、ＸＭＬ形式に従って警報情報を、＜ＤＡＴＡ＞タグの内部に設定することになる。
【００２０】
図４はＳＭＴＰ（Ｓｉｍｐｌｅ  Ｍａｉｌ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）管理説明図であり、監視サーバーと他のサーバーとを含む構成に於いて、監視サーバーのＸＭＬメール作成アプリケーション２１（図２に於けるＸＭＬメール作成アプリケーションプログラム１１に相当）により前述のように、ＸＭＬメール（警報メール）を作成し、警報の種別に従って通知する宛先を管理し、ＳＭＴＰ管理メールボックス２２にＸＭＬメールを格納する。ＳＭＴＰ管理アプリケーション２３は、ＳＭＴＰメールボックス２２に格納されたＸＭＬメールを読出して、その送信先を確認し、警報管理アプリケーション２５や連携制御アプリケーション２６等へ通知し、又受信データメールボックス２４に格納する。そして、処理が終了したＸＭＬメールは、ＳＭＴＰメールボックス２２から削除する。前述の受信データメールボックス２４は、図１に於けるメールボックス３又は図２に於ける受信データメールボックス１５に相当する。
【００２１】
又他のサーバーのＳＭＴＰ管理メールボックス２８に格納したＸＭＬメールを、ＳＭＴＰ管理アプリケーション２７により読出し、メールヘッダ部の送信先に従ってＳＭＴＰ２９は、外部にメール送信し、又は監視サーバーのＳＭＴＰ２７にメールを転送し、ＳＭＴＰ２７は転送されたメールをＳＭＴＰ管理メールボックス２２に格納する。そして、ＡＭＴＰ管理アプリケーション２３により受信データメールボックス２４に格納し、又は警報管理アプリケーション２５や連携制御アプリケーション２６等のアプリケーションに通知する。
【００２２】図５はメールヘッダ部の説明図であり、ＸＭＬメールのメールヘッダ部の一例を示し、送信元ＦｒｏｍをＳｒｖＡ＠ｍｙｈｏｍｅ、送信先Ｔｏを、ａｐｌＡ＠ｍｙｈｏｍｅとしてアプリケーションＡを指定し、ａｐｌＢ＠ｍｙｈｏｍｅとしてアプリケーションＢを指定し、ａｂｃ＠ｄｅｆ．ｃｏ．ｊｐとして、ａｂｃを指定し、ｂｃｘＢ＠ｍｙｈｏｍｅとして、メールボックスＢを指定した場合を示す。又メッセージＩＤ等も含むものである。
【００２３】
図６は複数警報発生時の説明図であり、図２と同一符号は同一部分を示す。複数の被監視部からの警報発生通知又は被監視部からの複数の警報発生通知を監視サーバーが受信すると、警報受信アプリケーション１１は、ＸＭＬメール作成アプリケーション１２に警報メール作成依頼を行う。この場合、警報発生毎のＸＭＬメールを作成すると、メール数が増加して、クライアントに通知するイベント数が頻繁に発生することになる。そこで、同時的に発生する複数の警報情報については集約する為に、ＸＭＬメール作成アプリケーション１２は、警報発生の時間間隔を定義したテーブルを管理する。予め設定する時間間隔としては、数秒程度とすることができる。そして、この予め設定した時間内に発生する警報情報については、警報データ部に集約して１通のメールとして作成する。
【００２４】
図７は前述の複数の警報発生時に集約したＸＭＬメールの警報データ部の一例を示し、＜ＤＡＴＡ＞タグ間に、＜ＭＳＧ＞タグにより区切られた警報データ１，２，３，・・・を集約した場合を示す。又＜ＡＬＭＴＩＭＥ＞タグで示す警報発生時刻は、同一の２２時３５分４８秒の場合を示し、予め設定した具体的な時間は図示していないが、前述のように、数秒程度とすることができる。このように、複数の同時的に発生した警報を集約して１通のＸＭＬメールとすることにより、クライアントに通知するイベント数が少なくて済む利点がある。
【００２５】
図８はＩＭＡＰ４による警報メール送信の説明図であり、１４はＩＭＡＰ４管理アプリケーション、１５は受信データメールボックス、３１はＩＭＡＰ４部品、３２−１〜３２−ｎはＷｅｂブラウザ、３３はアプレットを示す。ＩＭＡＰ４管理アプリケーション１４と受信データメールボックス１５とは、監視サーバー側の機能であり、又Ｗｅｂブランザ３２−１〜３２−ｎはクライアント側の機能である。
【００２６】
監視サーバーに於いては、前述のように、警報発生により、ＸＭＬメール（警報メール）を作成し、受信データメールボックス１５に受信メールとして格納する。ＩＭＡＰ４管理アプリケーション１４のＩＭＡＰ４部品３１は、Ｗｅｂブラウザ３２−１〜３２−ｎのアプレット３３に対してメール受信通知を行う。アプレット３３は、ＩＭＡＰ４に従ってメール受信処理を行い、Ｗｅｂブラウザに対してメール受信イベントを発行し、Ｗｅｂブラウザは、イベント通知に従った処理を行う。即ち、複数のＷｅｂブラウザ３２−１〜３２−ｎにより、受信データメールボックス１５に格納されたＸＭＬメールを必要に応じて読込むことができる。
【００２７】
図９は監視サーバー１とクライアント２との間のメールの送受信の説明図であり、監視サーバー１のＩＭＡＰ管理アプリケーション１４のＩＭＡＰ４部品３１と、クライアント２のＷｅｂブラウザ３２のアプレット３３とを示す。監視サーバー１とクライアント２との間の通信順序を（１）〜（５）で示し、アプレット３３の起動時に、監視サーバー１についての（１）認証処理を行う。その後、警報発生がなければ、（２）ＩＤＬＥ状態が継続する。
【００２８】
又被監視部からの警報発生通知に従ってＸＭＬメールを作成して受信データメールボックスに格納し、ＩＭＡＰ４管理アプリケーション１４のＩＭＡＰ４部品３１の処理により、（３）受信通知をクライアント２のアプレット３３に送出する。それに従って、アプレット３３はＸＭＬメールの（４）取得を行う。監視サーバー１は、（５）応答として、受信データメールボックスに格納したＸＭＬメールをクライアント２のアプレット３３に送出する。
【００２９】
又クライアント２は、監視サーバー１側でＸＭＬメールのＭＩＭＥエンコード（図２参照）に対応して、受信ＸＭＬメールに対して、（６）ＭＩＭＥデコードを行って、Ｗｅｂブラウザ３２に、（７）イベント通知を行う。Ｗｅｂブラウザ３２は、このイベント通知に従って警報表示処理等を行う。
【００３０】
又クライアント２のＷｅｂブラウザ３２を起動していない場合でも、監視サーバー１側では、異常状態発生検出によるＸＭＬメールを受信データメールボックス１５に保持している。そして、Ｗｅｂブラウザ３２を起動した時に、クライアント２は、監視サーバー１の受信データメールボックス１５に保持されているＸＭＬメールを受信する処理を行うことになる。その場合に、数時間も前の警報情報は必要がない場合が一般的である。クライアント２に於いては、Ｗｅｂブラウザ３２を起動してから、数分〜数秒前からの警報情報で充分な場合が多いから、この場合の時間指定を行ってＸＭＬメール受信を行うことができる。
【００３１】
図１０はメール受信処理の説明図であり、左側のフローチャートと右側のコマンドの一例とを示す。クライアントのＷｅｂブラウザを起動し（Ａ１）、その日時を２００２年９月２７日１０時１０分１０秒とし、このＷｅｂブラウザを起動してから予め設定した時間として１分とし、Ｗｅｂブラウザ起動時刻から１分前までの警報情報を収集するように設定した場合を示す。先ず、Ｗｅｂブラウザ起動により、ＩＭＡＰ４とＳｏｃｅｔ接続（Ａ２）し、ＩＭＡＰ４ログイン（Ａ３）（００１  ＬＯＧＩＮ  ＡＢＣ  ＤＥＦ）後、メール検索（Ａ４）（００２  ＵＩＤ  ＳＥＡＲＣＨ  ＳＩＮＣＥ  ２７−ＳＥＰ−２００２−１０：０９：１０）として、起動時刻１０時１０分１０秒より１分前の１０時９分１０秒までのメール検索を指示する。
【００３２】
そして、メールの有無を判定し（Ａ５）、メールが保持されていない場合は、ステップ（Ａ８）に移行し、メール有りの場合は、メール取得を行う（Ａ６）。この場合、メール検索により、“＊ＳＥＡＲＣＨ  １１９５２００１  １１９５２００２”として示すように、２通のメールが検索されると、この検索結果を基に、メール取得（Ａ６）を行う。即ち、“００３  ＵＩＤ  ＦＥＴＣＨ  １１９５２００１  １１９５２００２  （ＢＯＤＹ，ＰＥＥＫ〔〕）”として示すように、ＵＩＤにより指定したメールの受信処理を行う（Ａ７）。
【００３３】
この場合、１通目は、９月２７日１０時９分２０秒の受信メールの“ＵＩＤ  １１９５２００１”であり、２通目は、９月２７日１０時９分５０秒の受信メールの“ＵＩＤ  １１９５２００２”となる。そして、新たな異常発生がければ、ＩＤＬＥ状態（Ａ８）とし、Ｗｅｂブラウザへイベント通知を行う（Ａ９）。従って、クライアントのＷｅｂブラウザの起動時に、過去の警報情報の中で必要とする時間範囲内の異常状態発生を示すＸＭＬメールのみの受信処理を行うことができるから、無駄なＸＭＬメール受信を回避し、起動時の処理が容易となる。
【００３４】
図１１は、同時的な異常状態発生により、監視サーバー１の受信データメールボックス１５に多数のＸＭＬメールが格納された状態に於けるクライアント２側の処理を円滑化する為の説明図であり、図９と同一符号は同一部分を示し、３５は受信データバッファを示す。監視サーバー１のＩＭＡＰ４管理アプリケーション１４の処理により、受信データメールボックス１５にＸＭＬメールが格納されると、クライアント２のアプレット３３に受信通知を行い、クライアント２側から監視サーバー１側へＸＭＬメールの取得要求を送出することにより、受信メールボックス１５に保持されたＸＭＬメールをクライアント２に送信する。
【００３５】
その場合に、受信データメールボックス１５に多数のＸＭＬメールが格納されると、クライアント２のＷｅｂブラウザ３２のスクリプトの処理が追いつかない状態が発生する。そこで、受信データバッファ３５を設け、受信データメールボックス１５からのＸＭＬメールを受信データバッファ３５に一旦受信保持する。そして、アプレット３３は、Ｗｅｂブラウザ３２のスクリプトの処理終了毎に、Ｗｅｂブラウザ３２に対してメールイベントを通知する。従って、Ｗｅｂブラウザ３２は、監視サーバー１からのＸＭＬメールを順次処理して表示等の処理を行うことができるから、監視サーバー１の受信データメールボックス１５に多数のメールが蓄積された場合でも、発生した警報を脱落させることなく、順次処理することができる。
【００３６】
図１２は、クライアント２のアプレット３３の受信データバッファ３５に、監視サーバー１からのＸＭＬメールをｎ通受信して格納した場合を示し、アプレット３３は、Ｗｅｂブラウザのスクリプト３６に対して先ず１通目のイベント通知を行い、そして、自らイベント抑止を行う。スクリプト３６が１通目のイベント処理を終了すると、アプレット３３に対してイベント抑止解除メソッドを実行する。それにより、アプレット３３は、イベント抑止を解除して、スクリプト３６に対して２通目のイベント通知を行うと共に、イベント抑止を行う。スクリプト３６は、２通目のイベント処理終了により、アプレット３３に対してイベント抑止解除メソッドを実行する。以下同様にして、ｎ通目のイベント処理を行うまで繰り返す。
【００３７】
図１３はスクリプト処理説明図であり、監視サーバーのＩＭＡＰ４部品３１の処理によるＸＭＬメールを、クライアントのアプレット３３に於いて受信し、Ｗｅｂブラウザのスクリプト３６にイベント通知を行い、スクリプト３６の実行による画面遷移、ブザー鳴動、アイコン等の表示色変更、リアルタイム警報表示等を示す。下左側に、ＸＭＬメールの警報データ部の一例を示し、右下側に、スクリプトの処理内容を示す。
【００３８】
同時的に多数の異常状態発生時には、図７に示すように、１通のメールに集約することができるものであり、その場合に、処理の優先順位を決定することができる。又＜ＡＬＭＴＩＭＥ＞タグによる異常状態発生日時情報と、＜ＥＶＥＮＴ＞タグによるイベント発生と、＜ＭＳＧＤＡＴＡ１＞タグ〜＜ＭＳＧＤＡＴＡ２＞タグによる異常発生箇所情報とにより、リアルタイムで警報表示処理を行うことができる。又＜ＵＲＬ＞タグにより複数のフレーム毎のＵＲＬを設定して、異常発生箇所等に対応したフレームに画面遷移を行うことができる。又＜ＢＺＲＦＩＬＥ＞タグと＜ＢＺＲＣＮＴ＞タグとにより、ブザー鳴動と鳴動回数との処理を行うことができる。又＜ＩＣＯＮ＞タグと、＜ＦＲＡＭ＞タグとにより、アイコンやバックのフレームの表示色を処理することができる。
【００３９】
【発明の効果】
以上説明したように、本発明は、被監視部５からの警報情報により監視サーバー１のＸＭＬメール作成アプリケーションにより警報メール（ＸＭＬメール）を作成して、メールボックス３に着信メールとして格納し、クライアント２にメール着信通知を行い、クライアント２のウェブブラウザ４により、警報メールを処理して警報表示等を行うもので、警報情報をＸＭＬメール化することにより、クライアント２は監視サーバー１からの警報メール（ＸＭＬメール）を受信して、ウェブブラウザ上でリアルタイムで処理が可能となる利点がある。又他のサーバーとの間の連携や監視等も容易となる利点がある。
【００４０】
又同時的に多数の警報発生時は、警報データ部に集約して１通の警報メール（ＸＭＬメール）とすることにより、監視サーバー１とクライアント２との間の送受信処理が簡単化される。又ＩＭＡＰ４の１４３ポートを使用することにより、監視サーバー１とクライアント２との間にファイアウォールが接続されている場合でも、監視サーバー１とクライアント２との間のソケット通信が可能となる。又クライアント２のウェブブラウザ４を起動した時に、その起動時刻より前の予め設定した時間までの警報メール（ＸＭＬメール）を収集するように制御することにより、無駄な処理を省略することが可能となる。
【００４１】
又監視サーバー１のメールボックス３から複数の警報メール（ＸＭＬメール）を、クライアント２のアプレットの処理により受信データバッファに一旦受信格納し、ウェブブラウザのスクリプトに対して警報メール（ＸＭＬメール）を１通毎にイベント通知して、スクリプトの処理終了によるイベント抑止解除メソッド実行までイベント抑止を行うことにより、スクリプトで一度に処理できないような多数のイベント発生に対しても、順次処理できることになり、警報情報を脱落することなく、処理できる利点がある。
【図面の簡単な説明】
【図１】本発明の実施の形態のシステム構成の概要説明図である。
【図２】監視サーバーのアプリケーション説明図である。
【図３】ＸＭＬメールの説明図である。
【図４】ＳＭＴＰ管理説明図である。
【図５】メールヘッダ部の説明図である。
【図６】複数警報発生時の説明図である。
【図７】複数警報発生時の警報データ部の説明図である。
【図８】ＩＭＡＰ４による警報メール送信の説明図である。
【図９】監視サーバーとクライアントとの間の送受信の説明図である。
【図１０】メール受信処理の説明図である。
【図１１】多数メールの処理説明図である。
【図１２】クライアント内の処理説明図である。
【図１３】スクリプト処理説明図である。
【符号の説明】
１  監視サーバー
２  クライアント
３  メールボックス
４  ウェブブラウザ
５  被監視部
１１  警報受信アプリケーション
１２  ＸＭＬメール作成アプリケーション
１３  警報管理データベース
１４  ＩＭＡＰ４管理アプリケーション
１５  受信データメールボックス
【図１】
2004178241.tif 000003
【図２】
2004178241.tif 000004
【図３】
2004178241.tif 000005
【図４】
2004178241.tif 000006
【図５】
2004178241.tif 000007
【図６】
2004178241.tif 000008
【図７】
2004178241.tif 000009
【図８】
2004178241.tif 000010
【図９】
2004178241.tif 000011
【図１０】
2004178241.tif 000012
【図１１】
2004178241.tif 000013
【図１２】
2004178241.tif 000014
【図１３】
2004178241.tif 000015