(57)【要約】【課題】複数のビルに設置されたビル内装置における異常の発生を一元化して監視でき、ビル内の装置に異常が発生した場合の通知先の選定、通知方法の選択などの異常発生時の対応サービス内容（アクション）をビルごとに個別に設定する必要がなく、また、サービスの切り替えや変更を容易に行える、自動警報通知装置を提供する。【解決手段】群管理サーバ１０１により、監視対象となる複数ビルのビル内装置（設備機器）１１の異常情報をネットワーク経由で検知する。また、異常の種類や内容に応じて、通知先の選定などの所定の対応処理の組み合わせを予め定めたシナリオとして記憶しておく。そして、ビル内装置１１に異常が発生した場合に、シナリオサーバ３０１では、その異常の種類と内容に応じて、シナリオ記憶部から対応するシナリオを抽出し、この抽出したシナリオに従って異常発生に対する処理を実行する。【選択図】図１
2010231422.tif 000002
【特許請求の範囲】
【請求項１】
複数のビルに設置された監視対象である複数のビル内装置の動作状態を示す情報をネットワークを介して収集し、収集した動作状態を示す情報を通知先である管理センタまたは保守者のいずれか一方、または両方に通知する自動警報通知装置であって、
前記ビル内装置のいずれか１つまたは複数に異常が発生した場合に、該異常が発生したビル内装置から異常の種類と内容とを含む異常情報を前記ネットワーク経由で収集する群管理手段と、
前記ビル内装置における異常の種類と内容に応じて、前記通知先への連絡を含む所定の対応処理の組み合わせを予め定めたシナリオとして記憶するシナリオ記憶手段と、
前記ビル内装置に異常が発生した場合に、前記群管理手段が収集した前記異常情報に基づいて、前記シナリオ記憶手段からシナリオを抽出し、該抽出したシナリオに従って前記所定の対応処理を実行するシナリオ実行手段と、
を備えることを特徴とする自動警報通知装置。
【請求項２】
前記ビル内装置の動作状態を示す情報を定期的に取得するビル内装置情報取得手段、
を更に備え、
前記ビル内装置情報取得手段は、
前記ビル内装置に異常が発生した場合に、ビル内装置に異常が発生したことを示す前記異常情報を前記群管理手段に通知する、
を特徴とする請求項１に記載の自動警報通知装置。
【請求項３】
前記保守者の情報と、通知された異常情報に対する前記保守者の対応回数の履歴情報とを関連付けて記録した保守者データベースを更に備え、
前記シナリオ実行手段が抽出したシナリオに従って通知を行う前記保守者を選択する際に、前記保守者データベースを参照して、対応回数が多い保守者を優先して選択する、
ことを特徴とする請求項１または請求項２に記載の自動警報通知装置。        
【請求項４】
前記保守者の情報と、前記保守者ごとのスケジュールとを関連付けて記録したスケジュールデータベースを更に備え、
前記シナリオ実行手段が抽出したシナリオに従って通知を行う前記保守者を選択する際に、前記スケジュールデータベースを参照して、対応可能な保守者を優先して選択する、
ことを特徴とする請求項１または請求項２に記載の自動警報通知装置。
【請求項５】
前記保守者の情報と、前記保守者の現在の所在情報を関連付けて記録した所在データベースを更に備え、
前記シナリオ実行手段が抽出したシナリオに従って通知を行う前記保守者を選択する際に、前記所在データベースを参照して、異常が発生したビル内装置に近い保守者を優先して選択する、
ことを特徴とする請求項１または請求項２に記載の自動警報通知装置。
【請求項６】
前記通知先の端末に呼接続して前記異常情報を通知するための呼制御手段を更に備え、
前記呼制御手段は、
前記異常情報に基づいて、前記異常情報の内容を通知するための合成音声メッセージを生成し、該合成音声メッセージを前記通知先の端末に通知する、
ことを特徴とする請求項１から請求項５のいずれかに記載の自動警報通知装置。
【請求項７】
前記保守者が前記通知先の端末に応答したことを検知する応答検知手段、
を更に備え、
前記応答検知手段は、
前記通知先の端末に予め定められた釦の押下を検知することによって、前記保守者が該異常情報の通知に応答したものと判断する、
ことを特徴とする請求項１から請求項６のいずれかに記載の自動警報通知装置。
【請求項８】
前記保守者が通知した異常情報に対応不可能であることを検知する応答不可検知手段、
を更に備え、
前記応答不可検知手段は、
前記通知先の端末に予め定められた釦の押下を検知することによって、前記保守者が該異常情報の通知に対応不可能であると判断し、
次に異常情報を通知する候補の保守者に通知する、
ことを特徴とする請求項１から請求項７のいずれかに記載の自動警報通知装置。
【請求項９】
前記通知先の端末に異常情報を通知すると共に、該通知先の端末と異なる第２の通知先の端末にも通知する三者通話確立手段を更に備え、
前記通知先の端末と前記第２の通知先の端末との間の通話を実現する、
ことを特徴とする請求項１から請求項８のいずれかに記載の自動警報通知装置。
【請求項１０】
前記保守者の情報と、前記保守者ごとの状況および行動予定の情報を含むプレゼンス情報とを関連付けて記録したプレゼンス情報データベースを更に備え、
前記シナリオ実行手段が抽出したシナリオに従って通知を行う前記保守者を選択する際に、前記プレゼンス情報データベースを参照して、対応可能な保守者を優先して選択する、
ことを特徴とする請求項１または請求項２に記載の自動警報通知装置。
【請求項１１】
複数のビルに設置された監視対象である複数のビル内装置の動作状態を示す情報をネットワークを介して収集し、収集した動作状態を示す情報を通知先である管理センタまたは保守者のいずれか一方、または両方に通知する自動警報通知システムであって、
前記ビル内装置のいずれか１つまたは複数に異常が発生した場合に、該異常が発生したビル内装置から異常の種類と内容とを含む異常情報を前記ネットワーク経由で収集する群管理サーバと、
前記ビル内装置における異常の種類と内容に応じて、前記通知先への連絡を含む所定の対応処理の組み合わせを予め定めたシナリオとして記憶するシナリオ記憶部と、
前記ビル内装置に異常が発生した場合に、前記群管理手段が収集した前記異常情報に基づいて、前記シナリオ記憶手段からシナリオを抽出し、該抽出したシナリオに従って前記所定の対応処理を実行するシナリオサーバと、
を備えることを特徴とする自動警報通知システム。
【請求項１２】
複数のビルに設置された監視対象である複数のビル内装置の動作状態を示す情報をネットワークを介して収集し、収集した動作状態を示す情報を通知先である管理センタまたは保守者のいずれか一方、または両方に通知する自動警報通知装置における自動警報通知方法であって、
前記ビル内装置のいずれか１つまたは複数に異常が発生した場合に、該異常が発生したビル内装置から異常の種類と内容とを含む異常情報を前記ネットワーク経由で収集する群管理手順と、
前記ビル内装置における異常の種類と内容に応じて、前記通知先への連絡を含む所定の対応処理の組み合わせを予め定めたシナリオとして記憶するシナリオ記憶手順と、
前記ビル内装置に異常が発生した場合に、前記群管理手段が収集した前記異常情報に基づいて、記憶しているシナリオを抽出し、該抽出したシナリオに従って前記所定の対応処理を実行するシナリオ実行手順と、
を含むことを特徴とする自動警報通知方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークを利用して広域の複数のビルを管理するビル管理システムにおいて、特に、ビル内装置（ビル設備機器）から異常を知らせる警報が発生した場合に、この警報を保守管理センタや保守者（現場に駆けつける保守者）に自動的に通知する、自動警報通知装置、自動警報通知システム、および自動警報通知方法に関する。
【背景技術】
【０００２】
従来のビル内／ビル間通信の動向として、これまで、ビルの設備機器をネットワークでつなぎ自動監視するといったシステムに関するものはあった。例えば、ネットワークカメラを使用し、カメラが撮影した画像をネットワーク経由で送信することによって、離れた場所でも監視できるものがある（例えば、非特許文献１を参照）。また、ビル内で使用している機器で用いる全てのネットワークを同一のＩＰネットワークに統一するシステムがある（例えば、非特許文献２を参照）。
【０００３】
一方、ビル管理システムについては、建物に設置された機器や設備をネットワーク経由で監視、制御するビル管理システムとして、たとえばＢＡＳ（Building Automation System）やＢＭＳ（Building Management System）、ＢＥＭＳ（Building Energy Management System）と呼ばれるようなシステムが導入されてきた。これらのビル管理システムは、一般的には、ビル内の照明や空調、昇降機、電力などの機器（装置、デバイス）をセンタ装置から監視するために利用されている。
【０００４】
また、機器の監視、操作、データ収集を行うためのプロトコルとして、米国Echelon社が提唱したＬＯＮＴＡＬＫ（Local Operating Network・Talks：登録商標）とＡＳＨＲＡＥ（米国冷暖房空調工業会：American Society of Heating，Refrigerating and Air Conditioning Engineers）により策定されたＢＡＣｎｅｔ（A Data Communication Protocol for Building Automation and Control Network：登録商標）が知られている。
【０００５】
また、近年、ビル設備間の通信をＴＣＰ／ＩＰで統合、オープン化し、マルチベンダ性を高めて、拠点を跨ぐビル群を統合的に管理するようなシステムを実現するため、ＳＯＡＰ／ＨＴＴＰ（Simple Object Access Protocol/HTTP）を用いたウェブサービス技術が注目されている。ウェブサービス（Ｗｅｂサービス）によりビル内の機器を制御するプロトコル規格として、ＡＳＨＲＡＥ（米国冷暖房空調協議会）によって策定されたＢＡＣｎｅｔ／ＷＳ（BACnet Web Service）と、ＯＡＳＩＳ（Organization for the Advancement of Structured Information Standard)によって策定されたｏＢＩＸ（Open Building Information Exchange）という２種類のプロトコルがある。
【先行技術文献】
【非特許文献】
【０００６】
【非特許文献１】“ビル設備管理ネットワークシステム”、ＮＴＴコミュニケーションズ、［平成２１年１月２５日検索］、インターネット、<http://www.ntt.com/business/solution/alliance/emit/index3.html>
【非特許文献２】“東京ミッドタウン電話からビル監視までＩＰで統合，約１０００台のＡＰでＶｏＩＰ網構築”、日経ＢＰ社、［平成２１年１月２５日検索］、インターネット、<http://itpro.nikkeibp.co.jp/artcle/JIREI/20070726/278389/>
【発明の概要】
【発明が解決しようとする課題】
【０００７】
従来のビル管理においては、通常、運用方法が決められており、現状の運用方法に合わせたシステムの作り込みが行われている。このため、新たな技術やサービスが活用できるようになっても、既存のシステム構成によって拘束され、新たな運用方法に変更することが難しかった。
【０００８】
たとえば、従来の方法では、伝達手段において「メールで通知するか、電話で通知するか」を、状況に合わせて変更することや、新たな伝達手段を追加することは容易でなかった。また、「ビルの近くにいる保守者を選択するか、または対応回数が多い保守者を選択するか」といった選択条件を変更することや、追加することが難しかった。また、ビルの所有者（オーナー）あるいはビルの省エネコンサルタントが複数ビルを一元的に管理する場合において、システムの一部を変更しようとすると、個々のビルのサーバを含めてシステムを変更する必要があり、大規模のビル管理には向いていなかった。このように、従来技術や既存のシステムを変更するには、システム自体を一から造り直す必要が発生するため、別システムとの組合せ運用によって対応する必要があった。
【０００９】
本発明は、上記の課題認識に基づいてなされたものであり、複数のビルに設置されたビル内装置における異常の発生を一元化して監視するとともに、ビル内の装置に異常が発生した場合の通知先の選定、通知方法の選択、および連絡など、異常発生時の対応サービスの内容（アクション）をビルごとに個別に設定する必要がなく、また、自動警報通知装置におけるサービスの切り替えや変更、追加を容易に実現することができる、自動警報通知装置、自動警報通知システム、および自動警報通知方法を提供することを目的としている。
【課題を解決するための手段】
【００１０】
上記の課題を解決するため、本発明の自動警報通知装置は、複数のビルに設置された監視対象である複数のビル内装置の動作状態を示す情報をネットワークを介して収集し、収集した動作状態を示す情報を通知先である管理センタまたは保守者のいずれか一方、または両方に通知する自動警報通知装置であって、前記ビル内装置のいずれか１つまたは複数に異常が発生した場合に、該異常が発生したビル内装置から異常の種類と内容とを含む異常情報を前記ネットワーク経由で収集する群管理手段と、前記ビル内装置における異常の種類と内容に応じて、前記通知先への連絡を含む所定の対応処理の組み合わせを予め定めたシナリオとして記憶するシナリオ記憶手段と、前記ビル内装置に異常が発生した場合に、前記群管理手段が収集した前記異常情報に基づいて、前記シナリオ記憶手段からシナリオを抽出し、該抽出したシナリオに従って前記所定の対応処理を実行するシナリオ実行手段と、を備えることを特徴とする。
【００１１】
また、本発明の自動警報通知装置は、前記ビル内装置の動作状態を示す情報を定期的に取得するビル内装置情報取得手段、を更に備え、前記ビル内装置情報取得手段は、前記ビル内装置に異常が発生した場合に、ビル内装置に異常が発生したことを示す前記異常情報を前記群管理手段に通知する、を特徴とする。
【００１２】
また、本発明の自動警報通知装置は、前記保守者の情報と、通知された異常情報に対する前記保守者の対応回数の履歴情報とを関連付けて記録した保守者データベースを更に備え、前記シナリオ実行手段が抽出したシナリオに従って通知を行う前記保守者を選択する際に、前記保守者データベースを参照して、対応回数が多い保守者を優先して選択する、ことを特徴とする。
【００１３】
また、本発明の自動警報通知装置は、前記保守者の情報と、前記保守者ごとのスケジュールとを関連付けて記録したスケジュールデータベースを更に備え、前記シナリオ実行手段が抽出したシナリオに従って通知を行う前記保守者を選択する際に、前記スケジュールデータベースを参照して、対応可能な保守者を優先して選択する、ことを特徴とする。
【００１４】
また、本発明の自動警報通知装置は、前記保守者の情報と、前記保守者の現在の所在情報を関連付けて記録した所在データベースを更に備え、前記シナリオ実行手段が抽出したシナリオに従って通知を行う前記保守者を選択する際に、前記所在データベースを参照して、異常が発生したビル内装置に近い保守者を優先して選択する、ことを特徴とする。
【００１５】
また、本発明の自動警報通知装置は、前記通知先の端末に呼接続して前記異常情報を通知するための呼制御手段を更に備え、前記呼制御手段は、前記異常情報に基づいて、前記異常情報の内容を通知するための合成音声メッセージを生成し、該合成音声メッセージを前記通知先の端末に通知する、ことを特徴とする。
【００１６】
また、本発明の自動警報通知装置は、前記保守者が前記通知先の端末に応答したことを検知する応答検知手段、を更に備え、前記応答検知手段は、前記通知先の端末に予め定められた釦の押下を検知することによって、前記保守者が該異常情報の通知に応答したものと判断する、ことを特徴とする。
【００１７】
また、本発明の自動警報通知装置は、前記保守者が通知した異常情報に対応不可能であることを検知する応答不可検知手段、を更に備え、前記応答不可検知手段は、前記通知先の端末に予め定められた釦の押下を検知することによって、前記保守者が該異常情報の通知に対応不可能であると判断し、次に異常情報を通知する候補の保守者に通知する、ことを特徴とする。
【００１８】
また、本発明の自動警報通知装置は、前記通知先の端末に異常情報を通知すると共に、該通知先の端末と異なる第２の通知先の端末にも通知する三者通話確立手段を更に備え、前記通知先の端末と前記第２の通知先の端末との間の通話を実現する、ことを特徴とする。
【００１９】
また、本発明の自動警報通知装置は、前記保守者の情報と、前記保守者ごとの状況および行動予定の情報を含むプレゼンス情報とを関連付けて記録したプレゼンス情報データベースを更に備え、前記シナリオ実行手段が抽出したシナリオに従って通知を行う前記保守者を選択する際に、前記プレゼンス情報データベースを参照して、対応可能な保守者を優先して選択する、ことを特徴とする。
【００２０】
また、本発明の自動警報通知システムは、複数のビルに設置された監視対象である複数のビル内装置の動作状態を示す情報をネットワークを介して収集し、収集した動作状態を示す情報を通知先である管理センタまたは保守者のいずれか一方、または両方に通知する自動警報通知システムであって、前記ビル内装置のいずれか１つまたは複数に異常が発生した場合に、該異常が発生したビル内装置から異常の種類と内容とを含む異常情報を前記ネットワーク経由で収集する群管理サーバと、前記ビル内装置における異常の種類と内容に応じて、前記通知先への連絡を含む所定の対応処理の組み合わせを予め定めたシナリオとして記憶するシナリオ記憶部と、前記ビル内装置に異常が発生した場合に、前記群管理手段が収集した前記異常情報に基づいて、前記シナリオ記憶手段からシナリオを抽出し、該抽出したシナリオに従って前記所定の対応処理を実行するシナリオサーバと、を備えることを特徴とする。
【００２１】
また、本発明の自動警報通知方法は、複数のビルに設置された監視対象である複数のビル内装置の動作状態を示す情報をネットワークを介して収集し、収集した動作状態を示す情報を通知先である管理センタまたは保守者のいずれか一方、または両方に通知する自動警報通知装置における自動警報通知方法であって、前記ビル内装置のいずれか１つまたは複数に異常が発生した場合に、該異常が発生したビル内装置から異常の種類と内容とを含む異常情報を前記ネットワーク経由で収集する群管理手順と、前記ビル内装置における異常の種類と内容に応じて、前記通知先への連絡を含む所定の対応処理の組み合わせを予め定めたシナリオとして記憶するシナリオ記憶手順と、前記ビル内装置に異常が発生した場合に、前記群管理手段が収集した前記異常情報に基づいて、記憶しているシナリオを抽出し、該抽出したシナリオに従って前記所定の対応処理を実行するシナリオ実行手順と、を含むことを特徴とする。
【発明の効果】
【００２２】
本発明の自動警報通知装置および自動警報通知システムにおいては、監視対象である複数ビルのビル内装置（ビル設備機器）の異常情報をネットワーク経由で検知する。また、異常の種類や内容に応じて、通知先の選定および通知先への連絡を含む所定の対応処理の組み合わせを予め定めたシナリオとして記憶しておく。そして、ビル内装置に異常が発生した場合に、その異常の種類と内容に応じたシナリオを抽出し、この抽出したシナリオに従って異常発生に対する対応処理を実行する。
これにより、複数のビルのビル内装置において発生した異常情報を一元化して監視することができると共に、ビル内装置に異常が発生した場合の通知先の選定、通知方法の選択、および連絡などの異常発生時の対応サービス（アクション）をビルごとに個別に設定する必要がなく、また、例えば、ビル管理装置などの自動警報通知装置または自動警報通知システムにおけるサービスの切り替えや変更、追加を容易に実現することができる。
【００２３】
また、本発明の自動警報通知装置においては、各ビル内に設置されたビル内装置の動作状態を示す情報を定期的に取得するビル内装置情報取得手段を備え、このビル内装置情報取得手段により、ビル内装置に異常が発生したことを群管理手段に通知する。
これにより、各ビル内に設置されたビル内装置の動作状態を示す情報をビル内装置情報取得手段により定期的に監視できると共に、ビル内装置に異常が発生した場合に、これを集約して群管理手段に通知することができる。
【００２４】
また、本発明の自動警報通知装置においては、保守者の情報と、該保守者の異常情報（異常の種類と内容）に応じた対応回数の履歴情報とを関連付けて記録した保守者データベースを備え、保守者に異常情報を通知する際に、保守者データベースを参照して、異常情報の内容に応じた対応回数が多い保守者を優先して選択する。
これにより、ビル内装置で発生した異常の種類と内容に応じて、熟練度の高い最適な保守者を選択することができる。このため、ビル内装置の異常に迅速に対応することができる。
【００２５】
また、本発明の自動警報通知装置においては、保守者の情報と、該保守者ごとのスケジュールデータとを関連付けて記録したスケジュールデータベースを備え、保守者に異常情報を通知する際に、スケジュールデータベースを参照して、対応可能な保守者を優先して選択する。
これにより、ビル内装置に異常が発生した場合に、対応可能な保守者を迅速に選定することができる。
【００２６】
また、本発明の自動警報通知装置においては、保守者の情報と、該保守者の現在の所在情報とを関連付けて記録した所在データベースを備え、保守者に異常情報を通知する際に、所在データベースを参照して、ビル内装置に異常が発生したビルに近い保守者を優先して選択する。
これにより、ビル内装置に異常が発生した場合に、異常が発生したビルに最も近い場所にいる（例えば、待機している）保守者を選定することができる。このため、ビル内装置の異常に対して迅速に対応できる。
【００２７】
また、本発明の自動警報通知装置においては、通知先の端末に呼接続して異常の情報を通知する呼制御手段を備え、この呼制御手段では、通知先の端末に異常の情報を通知する際に、異常情報の内容を通知するための合成音声メッセージを生成して通知する。
これにより、シナリオ実行手段から呼制御手段に、例えば、ビル名、フロア、機器名等を引数として送るだけで、呼制御手段により異常の情報を通知するための合成音声メッセージを生成して通知先の端末に通知することができる。
【００２８】
また、本発明の自動警報通知装置においては、通知先の端末にビル内装置に異常が発生したことを通知した際に、通知先の端末の予め定められた釦が押下されたことによって、通知先の端末に所属している保守者が応答したことを検知する。
これにより、保守者はビル内装置の異常発生の通知を受けたことを示す際に、迅速かつ容易に応答することができる。
【００２９】
また、本発明の自動警報通知装置においては、通知先の端末にビル内装置に異常が発生したことを通知した際に、通知先の端末の予め定められた釦が押下されたことによって、通知先の端末に所属している保守者が対応不可能であることを検知し、次の候補となる保守者に通知する。
これにより、保守者はビル内装置の異常発生の通知を受けたことと、対応不可能であることを示す際に、迅速かつ容易に応答することができる。このため、自動警報通知装置では、次の候補となる保守者に迅速に通知することができる。
【００３０】
また、本発明の自動警報通知装置においては、通知先の端末にビル内装置に異常が発生したことを通知する際に、三者通話により保守者以外の端末へも同時に通知すると共に、保守者の端末と保守者以外の端末と間の通話を確立する。
これにより、ビル内装置から発せられる異常情報を契機に、例えば、３ＰＣＣ（3rd Party Call Control)を利用して、異常情報の通知を受けた保守者と異常情報を発したビル内装置のメーカとの間の通話を確立するという新しいサービスを提供できる。
【００３１】
また、本発明の自動警報通知装置においては、保守者の情報と、該保守者ごとの状況および行動予定の情報を含むプレゼンス情報とを関連付けて記録したプレゼンス情報データベースを備え、保守者に異常情報を通知する際に、プレゼンス情報データベースを参照し、対応可能な保守者を優先して選択する。
これにより、ビル内装置に異常が発生した場合に、プレゼンス情報を基に、対応可能な（予定の空いている）保守者を迅速に選定することができる。
【００３２】
また、本発明の自動警報通知方法においては、監視対象である複数ビルのビル内装置（ビル設備機器）の異常情報をネットワーク経由で検知する。また、異常の種類や内容に応じて、通知先の選定および通知先への連絡を含む所定の対応処理の組み合わせを予め定めたシナリオとして記憶しておく。そして、ビル内装置に異常が発生した場合に、その異常の種類と内容に応じたシナリオを抽出し、この抽出したシナリオに従って異常発生に対する対応処理を実行する。
これにより、複数のビルのビル内装置において発生した異常情報を一元化して監視することができると共に、ビル内装置に異常が発生した場合の通知先の選定、通知方法の選択、および連絡などの異常発生時の対応サービス（アクション）をビルごとに個別に設定する必要がなく、また、例えば、ビル管理装置などの自動警報通知装置におけるサービスの切り替えや変更、追加を容易に実現することができる。
【図面の簡単な説明】
【００３３】
【図１】本発明の第１の実施の形態に係るビル管理装置の基本構成を示す図である。
【図２】ビル管理装置における各部の構成例を示す図である。
【図３】図１に示すビル管理装置における処理の流れを示すシーケンス図である。
【図４】シナリオサーバにおいて呼の接続状態を確認する処理の流れをフローチャートである。
【図５】保守者を選択する方法の例を示す図である。
【図６】ビル情報および保守者データベース等の例を示す図である。
【図７】本発明の第２の実施の形態に係るビル管理装置の全体構成を示す図である。
【図８】図７に示すビル管理装置における処理の流れを示すシーケンス図である。
【図９】本発明の第３の実施の形態係るビル管理装置の全体構成を示す図である。
【図１０】対応回数の多い保守者情報を取得する際の処理の流れを示すフローチャートである。
【図１１】本発明の第４の実施の形態に係るビル管理装置の全体構成を示す図である。
【図１２】時間の空いている保守者情報を取得する際の処理の流れを示すフローチャートである。
【図１３】他の保守会社の保守管理情報ワークステーションと連携する構成例を示す図である。
【図１４】保守者データベースおよびスケジューラデータベースの例を示す図である。
【図１５】本発明の第５の実施の形態に係るビル管理装置の全体構成を示す図である。
【図１６】ビルに近い者を選択する際の処理の流れを示すフローチャートである。
【図１７】第５の実施の形態に係るビル管理装置における処理の流れを示すシーケンス図である。
【図１８】保守者の現在位置を記録した保守者データベース等の例を示す図である。
【図１９】本発明の第６および第７の実施の形態に係るビル管理装置における処理の流れを示すシーケンス図である。
【図２０】「＃ボタン」による確認処理の流れを示すフローチャートである。
【図２１】「＊ボタン」による確認処理の流れを示すフローチャートである。
【図２２】本発明の第８の実施の形態に係るビル管理装置における処理の流れを示すシーケンス図である。
【図２３】本発明の第９の実施の形態に係るビル管理装置における処理の流れを示すシーケンス図である。
【発明を実施するための形態】
【００３４】
以下、本発明の実施の形態を添付図面を参照して説明する。
［第１の実施の形態］
（ビル管理装置の基本構成の説明）
図１は、本発明の自動警報通知装置の実施の形態に係るビル管理装置の基本構成と、その動作の概要を説明するための図である。図１に示すビル管理装置においては、ビル内装置で異常が発生したときに、保守者と保守管理センタの端末に警報を通知すると共に、保守者と保守管理センタの間を３ＰＣＣ（3rd Party Call Control）で結ぶ装置である。なお、図１に示すビル管理装置は、複数のサーバが連携して処理を行うように構成されているため「ビル管理システム」とも呼ばれる。また、図１に示す、本発明の自動警報通知装置の実施の形態に係るビル管理装置は、複数のサーバが連携して処理を行うように構成されているため、本発明の「自動警報通知装置」は「自動警報通知システム」とも呼ばれ、図１に示すビル管理装置は、本発明の自動警報通知システムの実施の形態にも相当するものである。
【００３５】
このビル管理装置は、群管理サーバ１０１、実行制御サーバ２０１、シナリオサーバ３０１、および呼制御イネーブラ４０１を中心に構成されるものである。これらの群管理サーバ１０１、実行制御サーバ２０１、シナリオサーバ３０１、および呼制御イネーブラ４０１により、ビル内装置で異常が発生したときに、保守者と保守管理センタの端末に警報（異常情報）を通知するためのサービス連携装置（例えば、ネットワークサービスプラットフォーム（ＮＷＳＰＦ：Network service platform））が構成されている。
【００３６】
また、保守管理情報ワークステーション（保守管理情報ＷＳ）５０１、およびビル情報サービスエンジン（ビル情報ＳＥ）６０１は、ネットワークを介してシナリオサーバ３０１と接続され、このシナリオサーバ３０１と連携して処理を行うサーバ群である。なお、群管理サーバ１０１、実行制御サーバ２０１、シナリオサーバ３０１、呼制御イネーブラ４０１、保守管理情報ワークステーション５０１、およびビル情報サービスエンジン６０１を一体化した構成とすることもできる。
【００３７】
そして、各ビル内にはビルウェブサービスゲートウェイ（ビルＷｅｂサービスゲートウェイ）２１が設置され、各ビル内の空調や水位計などのビル内装置１１に取り付けられた各センサ等は、ＢＡＣｎｅｔ（登録商標）やＬＯＮＷＯＲＫＳ（登録商標）により、ビルウェブサービスゲートウェイ２１に接続されている。また、各ビル内に設置されたビルウェブサービスゲートウェイ２１は、ＳＯＡＰにより、群管理サーバ１０１と接続されている。また、保守者３１のＳＩＰ端末（ＳＩＰ：Session Initiation Protocol）３２と、保守管理センタ４１のＳＩＰ端末４２とは、呼制御イネーブラ４０１を介して、シナリオサーバ３０１と接続されている。
【００３８】
上記構成において、ビル内のセンサが異常を感知すると、警報メッセージ（異常情報）をビルウェブサービスゲートウェイ２１に送る。ビルウェブサービスゲートウェイ２１はその響報をＢＡＣｎｅｔ／ＷＳあるいは、ｏＢＩＸ等の形式で記述したＳＯＡＰ／ＨＴＴＰ（Simple Object Access Protocol/HTTP）による異常を通知するためのメッセージを作成し、群管理サーバ１０１に送る（ステップＳ１）。この警報メッセージは、ビル名や機器名、異常場所、異常の内容などを含んだものである。
【００３９】
群管理サーバ１０１がメッセージを受信すると、群管理サーバ１０１は、ＳＯＡＰメッセージを実行制御サーバ２０１に送り、シナリオサーバ３０１がシナリオを実行する（ステップＳ２）。シナリオが実行されると、シナリオサーバ３０１は、ビル情報サービスエンジン（ビル情報ＳＥ）６０１からビル情報（ビルＩＤなどの情報）を取得し（ステップＳ３）、また、保守管理情報ワークステーション５０１（保守管理情報ＷＳ）５０１から警報の内容に応じた通知手段と通知先の情報を取得する（ステップＳ４）。例えば、図の右上に示すような通知先情報５０４を取得する。
【００４０】
また、シナリオサーバ３０１は呼制御イネーブラ４０１にＳＯＡＰメッセージを投げ、呼制御イネーブラ４０１は、ビルの保守者のＳＩＰ端末３２にＳＩＰで発呼する。保守者が対応できない場合は、予め決められた次の保守者に発呼する。保守者が電話にでた場合は、機器の保守管理センタ４１等に発呼し、ビルの保守者３１と保守管理センタ４１を３ＰＣＣにより自動的につなげる（ステップＳ５）。
【００４１】
また、図２は、群管理サーバ１０１、実行制御サーバ２０１、シナリオサーバ３０１、および保守管理情報ワークステーション５０１の構成例を示す図であり、また、サーバ間の連携関係を説明するための図である。なお、各サーバにおける詳細な処理動作については、後述する図３等のシーケンス図において説明するので、ここでは、各サーバの基本的な構成と、その動作の概要についてだけ説明する。
【００４２】
図２において、ビル内装置１１が異常を検知すると、ビルウェブサービスゲートウェイ２１にＳＯＡＰ／ＨＴＴＰベースのＢＡＣｎｅｔでメッセージ（ｕｒｉ）を送られる。ｕｒｉは識別子であり、ビルの名称、ビルのＩＤ、フロア、機器名、機器ＩＤ、警報情報（異常内容）などの情報を含んでいる。ビルウェブサービスゲートウェイ２１は、群管理サーバ１０１にメッセージ（ｕｒｉ）を送る。
【００４３】
群管理サーバ１０１は、機器動作状態情報取得部１１１を有しており、この機器動作状態情報取得部１１１により、ビルウェブサービスゲートウェイ２１から送られるメッセージ（ｕｒｉ）を、ネットワークを通して受信する処理を行う。また、群管理サーバ１０１は、機器動作状態情報送信部１１２を有しており、この機器動作状態情報送信部１１２は、実行制御サーバ２０１内のログイン受付部２１１からログインＩＤを取得し、実行制御サーバ２０１に、ユーザＩＤ（userid）、ログインＩＤ、ｕｒｉ、日時を含むメッセージを渡す処理を行う。
【００４４】
実行制御サーバ２０１では、ログイン受付部２１１により、群管理サーバ１０１に対してログインＩＤを発行する。また、認証部２１２により、群管理サーバ１０１から送られたメッセージの認証処理を行う。また、認証部２１２で実行制御サーバ２０１から送られたメッセージを認証すると、シナリオサーバ３０１にｕｒｉ（識別子）と日時を引数にしたメッセージを送る。
【００４５】
シナリオサーバ３０１内のシナリオ実行部３１１は、実行制御サーバ２０１から受信したメッセージ（ｕｒｉ）を基に、シナリオ記憶部３０２を参照して、ビル内装置１１の異常内容に応じたシナリオを取得する処理を行う。また、ビル情報取得部３１３を通して、ビル情報サービスエンジン（ビル情報ＳＥ）６０１にｕｒｉを引数としたメッセージを送り、機器ＩＤを取得する処理を行う。また、保守管理情報取得部３１２を通して、保守管理情報ワークステーション５０１から保守者３１や保守管理センタ４１の通知先の情報（ＳＩＰＵＲＩ等）を取得する処理を行う。
【００４６】
また、シナリオサーバ３０１内の呼接続制御部３１４は、呼制御イネーブラ４０１に対して、ＳＯＡＰメッセージを送り、保守者３１の端末３２や保守管理センタ４１の端末４２に対してＳＩＰで呼接続するように指示すると共に、呼制御イネーブラ４０１から呼情報を受け取り呼状態を確認する処理を行う。そして、呼が確立された場合は、保守者３１のＳＩＰ端末３２や保守管理センタ４１のＳＩＰ端末４２に対して警報情報を通知するように指示する処理を行う。また、呼接続制御部３１４は、呼制御イネーブラ４０１に対し、保守者３１のＳＩＰ端末３２と保守管理センタ４１のＳＩＰ端末４２との間、さらには第３者のＳＩＰ端末を含めて３ＰＣＣで接続するように指示する処理を行う。
【００４７】
ビル情報サービスエンジン（ビル情報ＳＥ）６０１では、シナリオサーバ３０１から得たメッセージ（ｕｒｉ）を解析し、機器情報データベース６１１を参照し、機器ＩＤを抽出すると共に、この抽出した機器ＩＤをシナリオサーバ３０１に返信する処理を行う。この機器情報データベース６１１のデータ構成例を図６（Ａ）に示す。
【００４８】
保守管理情報ワークステーション５０１では、シナリオサーバ３０１から得たメッセージ（ｕｒｉ）を解析し、検索部５１１により、保守者データベース５０２にアクセスし、保守者３１の情報を検索して抽出すると共に、この抽出した保守者の情報（ＳＩＰＵＲＩ等）をシナリオサーバ３０１に返信する処理を行う。
【００４９】
また、保守管理情報ワークステーション５０１では、検索部５１１により、保守管理センタデータベース５０３にアクセスし、保守管理センタ４１を検索して抽出すると共に、シナリオサーバ３０１に保守管理センタ４１の情報（ＳＩＰＵＲＩ等）を返す処理を行う。
【００５０】
呼制御イネーブラ４０１は、シナリオサーバ３０１からの指示により、保守者３１のＳＩＰ端末３２、および保守管理センタ４１のＳＩＰ端末４２に呼接続すると共に、保守者３１のＳＩＰ端末３２と保守管理センタ４１のＳＩＰ端末４２との間、さらには第３者のＳＩＰ端末を含めた３ＰＣＣで接続するための処理を行う。
【００５１】
（ビル管理装置における動作シーケンスの説明）
図３は、本発明の第１の実施の形態に係るビル管理装置における処理の流れを示すシーケンス図である。このシーケンス図は、図１および図２に示すビル管理装置における処理の流れを示すものであり、以下、図３に示すシーケンス図を参照して説明する。
【００５２】
最初に、ビル内装置１１が異常を検知すると、ビルウェブサービスゲートウェイ（ビルＷｅｂサービスゲートウェイ）２１にＳＯＡＰ／ＨＴＴＰベースのＢＡＣｎｅｔでメッセージ（ｕｒｉ）を送る（ステップＳ１０１）。
【００５３】
ｕｒｉは識別子であり、以下のようにビルの名称、ビルのＩＤ、フロア、機器名、機器ＩＤ、障害内容などの情報を含んでいる。
【００５４】
ＵＲＩの例、http://musasino:02:F5-E/Aircon:03/alarm/leaking
ＵＲＩの形式）http://[ビル名]:[ビルID]/[フロア]/[機器名]:[機器ID]/alarm/[状態]
【００５５】
ビルウェブサービスゲートウェイ２１は、群管理サーバ１０１にＢＡＣｎｅｔ／ＷＳあるいはｏＢＩＸ形式等で記述されたＳＯＡＰ／ＨＴＴＰメッセージ（ｕｒｉ）を送る（ステップＳ１０２）。
【００５６】
群管理サーバ１０１は、実行制御サーバ２０１にログインするために、ユーザＩＤ（userid）とパスワード（pw）を引数とするログインメッセージ（login（userid,pw））を渡し（ステップＳ１０３）、ログインＩＤを受け取る（ステップＳ１０４）。
【００５７】
群管理サーバ１０１は、実行制御サーバ２０１に、ユーザＩＤ（userid）、ログインＩＤ、ｕｒｉ、日時を渡す。このために、群管理サーバ１０１から実行制御サーバ２０１に、メッセージAlarmGeneration（userid，loginid，uri，datetime）を送信する（ステップＳ１０５）。
【００５８】
実行制御サーバ２０１では、群管理サーバ１０１から送られたメッセージの認証を行う（ステップＳ１０６）。
実行制御サーバ２０１はシナリオサーバ３０１にメッセージ（uri）と日時（datetime）引数にしたメッセージを送る。すなわち、実行制御サーバ２０１からシナリオサーバ３０１に、メッセージAlarmGeneration（uri，datetime）を送信する（ステップＳ１０７）。
【００５９】
シナリオサーバ３０１は、ビル情報サービスエンジン（ビル情報ＳＥ）６０１にｕｒｉを引数としたメッセージを送る。すなわち、シナリオサーバ３０１からビル情報サービスエンジンに、メッセージgetFacilitiesInfo（uri）を送信する（ステップＳ１０８）。
【００６０】
ビル情報サービスエンジン６０１は得たｕｒｉを解析し、機器ＩＤを抽出する（ステップＳ１０９）。ビル情報サービスエンジン６０１は、機器ＩＤを引数にし、ビル情報サービスエンジン６０１内の機器情報データベース６１１から、機器ＩＤが一致するものを抽出する。この機器情報データベース６１１のデータ構成例を図６（Ａ）に示す。
そして、ビル情報サービスエンジン６０１は、シナリオサーバ３０１に対し、該当するビルの機器の製造メーカ、販売者、製品番号を含んだ機器情報を返す（ステップＳ１１０）。ビル情報サービスエンジン６０１からシナリオサーバ３０１に送られる機器情報の例を図６（Ｂ）に示す。
【００６１】
シナリオサーバ３０１は、保守管理情報ワークステーション５０１（保守管理情報ワークステーション）から保守者の情報を得るため保守管理情報ワークステーション５０１にビルＩＤを引数としたｇｅｔメッセージを送る。すなわち、シナリオサーバ３０１から保守管理情報ワークステーション５０１に、メッセージgetContactList(uri)を送信する（ステップＳ１１１）。
【００６２】
保守管理情報ワークステーション５０１は、保守者のＳＩＰＵＲＩを得るために、保守者データベース５０２にアクセスし、ビルＩＤをキーとして保守者を検索し（ステップＳ１１２）、シナリオサーバ３０１に複数（たとえば上位２個）のＳＩＰＵＲＩを返す（ステップＳ１１３）。この保守者データベースの例を、図６（Ｃ）に示す。
【００６３】
また、保守管理情報ワークステーション５０１は、メーカの保守管理センタ（コールセンタ）のＳＩＰＵＲＩを得るために、図６（Ｄ）に示す保守管理センタデータベース５０３にアクセスし、機器ＩＤと一致するＳＩＰＵＲＩを、シナリオサーバ３０１に返す。シナリオサーバ３０１に返されるＳＩＰＵＲＩの例を図６（Ｅ）に示す。
【００６４】
続いて、シナリオサーバ３０１は、上記で得たＳＩＰＵＲＩをもとに、呼制御イネーブラ４０１にＳＯＡＰメッセージ（makecall(from,to)メッセージ）を送り（ステップＳ１１４）、呼情報を得るためのＩＤ（callInstanceID）メッセージを受け取る（ステップＳ１１５）。
【００６５】
呼制御イネーブラ４０１はＳＩＰ端末３２にインバイト（invite）のＳＩＰメッセージを送信し（ステップＳ１１６）、またシナリオサーバ３０１は、呼制御イネーブラ４０１に呼状態を確認するためにcallInstanceIDを引数としたメッセージ（getCallInformation(callInstanceID)）メッセージをＳＯＡＰにより送り、呼情報を得る（ステップＳ１１７、Ｓ１１８）。
【００６６】
一定時間内に一定回数、呼状態を確認する。一定時間内に呼が確立されなかった場合は、cancellCallメッセージによって呼接続を終了させ、別の保守者に発呼するためにステップＳ１１４以下の手順を繰り返す。この場合、ステップＳ１１２において、保守管理情報ワークステーション５０１がシナリオサーバ３０１に返したＳＩＰＵＲＩ（保守者の情報）の数だけ繰り返す（ステップＳ１１９）。
【００６７】
呼が確立された場合は、保守管理センタ４１のＳＩＰ端末４２に接続し、保守者３１のＳＩＰ端末３２と３ＰＣＣで接続するために、シナリオサーバ３０１は、呼制御イネーブラ４０１にメッセージmakeCal1Array(fromList,to)のＳＯＡＰメッセージを送る（ステップＳ１２０）。
【００６８】
呼制御イネーブラ４０１は、発信者（from）であり、着信者（to）かという「from,to」を引数にしたメッセージ（makeCallDtmf）を（ステップＳ１２１）、シナリオサーバ３０１にcallInstanceIDメッセージを返す。接続ができない場合は“ＮＧ”メッセージを返す（ステップＳ１２２）。
【００６９】
なお、図４は、図３に示すシーケンス図において、ステップＳ１１４〜ステップＳ１１９までの処理手順をフローチャートで示したものであり、呼制御イネーブラ４０１において一定時間内に一定回数発呼し、シナリオサーバ３０１において呼の接続状態を確認する処理の流れをフローチャートで示したものである。また、図４中にステップ番号は、図３に示すシーケンス図内のステップに対応するものである（ただし、ステップＳ１１８Ａ、ステップＳ１１８Ｂは、説明のために新たに追加したものである）。
【００７０】
図４を参照して、シナリオサーバ３０１は、ＳＩＰＵＲＩをもとに、呼制御イネーブラ４０１にＳＯＡＰメッセージ（makecall(from,to)）を送り、呼情報を得るためのＩＤ（callInstanceIDメッセージ）を受け取る（ステップＳ１１４、ステップＳ１１５）。
【００７１】
呼制御イネーブラ４０１はＳＩＰ端末にインバイト（invite）のＳＩＰメッセージを送信する（ステップＳ１１６）。またシナリオサーバ３０１は、呼制御イネーブラ４０１に呼状態を確認するためにcallInstanceIDを引数としたメッセージ（getCallInformation(callInstanceID)）をＳＯＡＰにより送り、呼情報を得る（ステップＳ１１７、ステップＳ１１８）。
【００７２】
そして、呼制御イネーブラ４０１から取得した呼情報によりＳＩＰ端末に接続したか、未接続かを判定する（ステップＳ１１８Ａ）。そして、未接続の場合は（ステップＳ１１８Ａ：未接続）、５回目の発呼か否かを判定する（ステップＳ１１８Ｂ）。５回目でなければ（ステップＳ１１８Ｂ：ＮＯ）、ステップＳ１１７に戻り、呼制御イネーブラ４０１によりＳＩＰ端末に対して発呼を行わせる。一方、ステップＳ１１８Ｂにおいて５回目と判定された場合は（ステップＳ１１８Ｂ：ＹＥＳ）、メッセージ（cancellCall）によって、呼制御イネーブラ４０１における呼接続を終了させ、別の保守者に発呼するためにステップＳ１１４以下の手順を繰り返す。
【００７３】
また、ステップＳ１１８ＡにおいてＳＩＰ端末に接続（呼確立）と判定された場合は（ステップＳ１１８Ａ：接続）、ステップＳ１２０に移行し、管理センタ等に接続し、保守者と３ＰＣＣで接続するために、シナリオサーバ３０１は、呼制御イネーブラ４０１にメッセージ（makeCal1Array(fromList,to)のＳＯＡＰメッセージを送信する。
【００７４】
なお、上記処理手順において、シナリオサーバ３０１により保守者を選択する場合に、図５に示すように、予定の空いている者を選択する方法Ａ、対応回数の多いものを選択する方法Ｂか、または、ビルに近い者を選択するなどの方法Ｃを用いることができる。なお、これらのそれぞれ選択方法の例については後述する。
【００７５】
以上、本発明の第１の実施の形態について説明したが、図１および図２に示す、本発明の自動警報通知装置の第１の実施の形態に係るビル管理装置において、前述の群管理手段は群管理サーバ１０１が相当し、前述のシナリオ記憶手段はシナリオ記憶部３０２が相当し、シナリオ実行手段はシナリオサーバ３０１（主には、シナリオ実行部３１１）が相当する（後述する第２の実施の形態から第９の実施の形態においても同じ）。なお、前述のように、図１および図２に示すビル管理装置は、複数のサーバが連携して処理を行うように構成されているため、本発明の自動警報通知システムの実施の形態にも相当するものである。
【００７６】
そして、本発明の第１の実施の形態のビル管理装置は、ビル内装置１１のいずれか１つまたは複数に異常が発生した場合に、該異常が発生したビル内装置１１から異常の種類と内容とを含む異常情報（警報）をネットワーク経由で収集する群管理サーバ１０１と、ビル内装置１１における異常の種類と内容に応じて、通知先への連絡を含む所定の対応処理の組み合わせを予め定めたシナリオとして記憶するシナリオ記憶部３０２と、ビル内装置１１に異常が発生した場合に、群管理サーバ１０１が収集した異常情報に基づいて、シナリオ記憶部３０２からシナリオを抽出し、該抽出したシナリオに従って所定の対応処理を実行するシナリオ実行部３１１と、を有して構成される。
これにより、複数のビルのビル内装置において発生した異常情報を一元化して監視することができると共に、ビル内装置に異常が発生した場合の通知先の選定、通知方法の選択、および連絡などの異常発生時の対応サービス（アクション）をビルごとに個別に設定する必要がなく、また、例えば、ビル管理装置などの自動警報通知装置におけるサービスの切り替えや変更、追加を容易に実現することができる。
【００７７】
[第２の実施の形態]
次に、本発明の自動警報通知装置の第２の実施の形態に係るビル管理装置として、ビル内装置１１からビルウェブサービスゲートウェイ２１に警報を送る部分の構成を変更した例について説明する。図７は、本発明の第２の実施の形態に係るビル管理装置の全体構成を示す図である。
【００７８】
図７に示すビル管理装置が、図１に示すビル管理装置と比べて構成上異なる点は、ビルウェブサービスゲートウェイ２１が、定期的にビル内装置１１の状態情報を取得する点であり（図中の代替処理ａで示す部分を参照）、他の構成、および図中のステップＳ１〜ステップＳ５で示す処理内容は、図１に示すビル管理装置と同様である。このため、同一の構成部分には同一の符号を付し、重複する説明は省略する。
【００７９】
図７に示すビル管理装置においては、ビルウェブサービスゲートウェイ２１は、定期的にビル内装置１１の動作状態の情報を取得する。このとき使用されるプロトコルは、ＢＡＣｎｅｔやＬＯＮＷＯＲＫＳ等である。
【００８０】
また、図８は、図７に示すビル管理装置における処理の流れを示すシーケンス図である。図８に示すシーケンス図が、図３に示すシーケンスと異なる点は、図３におけるステップＳ１０１の部分を、図８に示すステップＳ１０１Ａ、ステップＳ１０１Ｂ（代替処理ａで示す部分）に変更した点であり、他のステップＳ１０２〜ステップＳ１２２における処理は、図３に示すシーケンス図の場合と同様である。このため、同一の処理内容の部分には同一のステップ番号を付し、重複する説明は省略する。
【００８１】
すなわち、ビルウェブサービスゲートウェイ２１は、ビル内装置１１に対して、定期的に操作状態の情報を送るように指示する（ステップＳ１０１Ａ）。ビル内装置１１は、ビルウェブサービスゲートウェイ２１に対して、動作状態の情報を送信する（ステップＳ１０１Ｂ）。
【００８２】
なお、第２の実施の形態において、前述のビル内装置情報取得手段は、ビルウェブサービスゲートウェイ２１が相当する。
そして、各ビル内には定期的にビル内装置の動作状態の情報を取得するビルウェブサービスゲートウェイ２１を備え、このビルウェブサービスゲートウェイ２１は、ビル内装置１１に異常が発生した場合に、ビル内装置１１に異常が発生したことを示す異常情報を警報として群管理サーバ１０１に通知する。
これにより、各ビル内に設置されたビル内装置の動作状態を示す情報をビルウェブサービスゲートウェイ２１により定期的に収集して監視できると共に、ビル内装置１１に異常が発生した場合に、これを集約して群管理サーバ１０１に通知することができる。
【００８３】
［第３の実施の形態］
次に、本発明の自動警報通知装置の第３の実施の形態に係るビル管理装置として、保守管理情報ワークステーション５０１において、保守者の通知先情報（電話をかける相手）を選択する方法として、警報対応者の履歴情報を保存しておき、対応回数が多い人を選択する例について説明する。
【００８４】
図９は、本発明の第３の実施の形態係るビル管理装置の全体構成を示す図である。この図９に示すビル管理装置が、図１に示すビル管理装置と構成上異なるのは、保守管理情報ワークステーション（保守管理情報ＷＳ）５０１が取得する保守者情報（電話をかける相手）として、警報対応者の履歴情報を予め定め保守者データベース（保守者ＤＢ）５０２に保存しておき、対応回数が多い人を選べるようにした点が異なり、その他の構成、および図中のステップＳ１〜ステップＳ５で示す処理内容は、図１に示すビル管理装置と同様である。
【００８５】
図９に示すビル管理装置においては、対応回数が多い人を選べるように保守管理情報ワークステーション５０１内に保守者データベース５０２を有しており、この保守者データベース５０２に格納されるデータの例を、図１４（Ａ）に示す。
【００８６】
また、図１０は、保守管理情報ワークステーションから、対応回数の多い保守者情報を取得する際の処理の流れを示すフローチャートである。
【００８７】
図１０を参照して、シナリオサーバ３０１において、保守管理情報ワークステーション５０１からの情報取得のシナリオが開始されると、保守管理情報ワークステーション５０１では、保守者データベース５０２を検索して保守者の対応回数情報を取得し（ステップＳ２０１）、対応回数の多い保守者を選択する（ステップＳ２０２）。そして、シナリオサーバ３０１では、呼制御イネーブラ４０１を介して、選択された対応回数の多い者に通知する（ステップＳ２０３）。また、装置メーカにも警報情報を通知する（ステップＳ２０４）。
【００８８】
このように、本発明の第３の実施の形態のビル管理装置においては、保守者の情報と、通知された異常情報に対する保守者の対応回数の履歴情報とを関連付けて記録した保守者データベース５０２を備え、シナリオ実行部３１１が抽出したシナリオに従って通知を行う保守者を選択する際に、保守者データベース５０２を参照して、対応回数が多い保守者を優先して選択する、
これにより、ビル内装置で発生した異常の種類と内容に応じて、熟練度の高い最適な保守者を選択することができる。このため、ビル内装置の異常に迅速に対応することができる。
【００８９】
［第４の実施の形態］
次に、本発明の自動警報通知装置の第４の実施の形態に係るビル管理装置として、保守者の通知先情報（電話をかける相手）を選択する方法として、時間が空いている対応者を選択する例について説明する。
【００９０】
図１１は、本発明の第４の実施の形態に係るビル管理装置の全体構成を示す図である。図１１に示す例は、保守者の通知先情報を選択する方法として、警報対応者のスケジュール情報を保存しておき、スケジュールウェブサービスを検索し時間が空いている対応者を選択する例である。
【００９１】
この図１１に示すビル管理装置が、図１に示すビル管理装置と構成上異なるのは、スケジューラワークステーション（スケジューラＷＳ）７０１が新たに追加され点が異なる。また、保守管理情報ワークステーション５０１が取得する保守者情報（電話をかける相手）として、警報対応者の履歴情報（スケージュール情報）を保守者データベース５０２に保存しておき、時間が空いている保守者を選べるようにした点が異なる。その他の構成は図１に示すビル管理装置と同様である。
【００９２】
この時間が空いている対応者を選択する方法では、スケジューラワークステーション７０１内にスケジューラデータベース７０２が設けられており、このスケジューラデータベース７０２に担当者ごとのスケジュールのデータが登録されている。スケジューラデータベース７０２におけるデータ構成例を図１４（Ｂ）に示す。
【００９３】
また、図１２は、保守管理情報ワークステーション５０１において、時間の空いている保守者情報を取得する際の処理の流れを示すフローチャートである。
【００９４】
図１２を参照して、シナリオサーバ３０１において、保守管理情報ワークステーション５０１からの情報取得のシナリオが開始されると、保守管理情報ワークステーション５０１では、保守者データベース５０２を検索して保守者の予定の情報を取得し（ステップＳ３０１）、予定の空いている保守者を選択する（ステップＳ３０２）。そして、選択した予定の空いている保守者に、呼制御イネーブラ４０１を介して、警報情報を通知する（ステップＳ３０３）。また、装置メーカにも警報情報を通知する（ステップＳ３０４）。
【００９５】
また、時間が空いている保守者を選択する方法では、図１３に示すように、ユーザマネージャーワークステーション８０１を使用することができる。すなわち、図１３（Ａ）に示す保守管理情報ワークステーション（保守管理情報ＷＳ）５０１の構成を、図１３（Ｂ）に示すように、保守管理情報ワークステーション５０１の隣に、ユーザマネージャーワークステーション（ユーザマネージャＷＳ）８０１を追加した構成とすることができる。
【００９６】
図１３（Ｂ）に示す構成においては、シナリオサーバ３０１からの保守者情報などの要求を、ユーザマネージャーワークステーション８０１により受け付けるように構成されている。また、ユーザマネージャーワークステーション８０１に対し、保守会社Ａに設けられた保守管理情報ワークステーション５０１Ａと、保守会社Ｂに設けられた保守管理情報ワークステーション５０１Ｂとが連携可能に構成される。
【００９７】
このような構成により、例えば、保守会社Ｂの保守管理情報ワークステーション５０１Ｂでは、保守会社Ｂのスケジューラワークステーション７０１Ｂとリンクして、保守管理情報ワークステーション５０１Ｂの保守管理情報を更新することができる。このため、病気や遅延などの保守者の急な変更にも対応することが可能である。
【００９８】
そして、ユーザマネージャーワークステーション８０１が、シナリオサーバ３０１からの情報提供の要求のメッセージを受け取ると、ユーザマネージャーワークステーション８０１では、シナリオサーバ３０１から受け取ったメッセージの内容を解析し、提供するサービスを選択する（ステップＳ３１１）。例えば、対象となるビル設備機器がＡ社の製品である場合は、Ａ社の保守管理情報ワークステーション５０１Ａから、時間の空いている保守者の情報を選択する（ステップＳ３１２）。また、対象となるビル設備機器がＢ社の製品である場合は、Ｂ社の保守管理情報ワークステーション５０１Ｂから、時間の空いている保守者の情報を選択する（ステップＳ３１３）。また、対象となるビル設備機器がＡ社の製品でなく、かつＢ社の製品でもない場合は、デフォルト（初期値）として、保守管理情報ワークステーション５０１にアクセスする（ステップＳ３１４）。
【００９９】
また、前述のように、Ｂ社における保守者の変更や、通知先の変更情報は、Ｂ社のスケジューラワークステーション７０１Ｂに入力され（ステップＳ３１５）、この変更された情報は、Ｂ社の保守管理情報ワークステーション５０１Ｂに通知される（ステップＳ３１６）。
【０１００】
このように、本発明の第４の実施の形態においては、保守者の情報と、保守者ごとのスケジュールデータとを関連付けて記録したスケジューラデータベース７０２を備え、シナリオ実行部３１１が抽出したシナリオに従って通知を行う保守者を選択する際に、スケジューラデータベース７０２参照し、対応可能な保守者を優先して選択する。
これにより、ビル内装置に異常が発生した場合に、対応可能な保守者を迅速に選定することができる。
【０１０１】
［第５の実施の形態］
次に、本発明の自動警報通知装置の第５の実施の形態に係るビル管理装置として、ビルの近くにいる対応者（ＧＰＳや携帯電話を所持している保守者）を選択する例について説明する。
【０１０２】
図１５は、本発明の第５の実施の形態に係るビル管理装置の全体構成を示す図である。図１５に示すビル管理装置が、図１に示すビル管理装置と構成上異なるのは、図１５に示すビル管理装置の保守管理情報ワークステーション５０１内の保守者データベース５０２内に保守者（対応者）の現在置の情報を登録するようにした点と、シナリオサーバ３０１がビルの位置情報を取得するために、位置参照ワークステーション（位置参照ワークＷＳ）９０１を追加した点であり、他の構成は、図１に示すビル管理装置と同様である。
【０１０３】
図１８（Ａ）に保守者データベース５０２におけるデータ構成例を示す。図に示す例では、保守者（ビルの近くにいる対応者）の位置情報をＧＰＳ等で取得し、この位置情報を緯度と経度の情報により登録した例である。
【０１０４】
また、図１６は、保守管理情報ワークステーション５０１において、ビルに近い者を選択する際の処理の流れを示すフローチャートである。
【０１０５】
図１６を参照して、シナリオサーバ３０１において、保守管理情報ワークステーション５０１からの保守者情報取得のシナリオが開始されると、保守管理情報ワークステーション５０１では、保守者データベースを検索して保守者の現在値情報を取得し（ステップＳ４０１）、ビルに近い保守者を選択する（ステップＳ４０２）。そして、シナリオサーバ３０１では、選択した保守者に、呼制御イネーブラ４０１を介して。警報情報を通知する（ステップＳ４０３）。また、装置メーカにも警報情報を通知する（ステップＳ４０４）。
【０１０６】
また、図１７は、図１５に示す第５の実施の形態に係るビル管理装置における処理の流れを示すシーケンス図である。
【０１０７】
図１７に示すシーケンス図は、図３に示すシーケンス図と比較して、ステップＳ１０１〜ステップＳ１０６までの処理については、同じである。また、ステップＳ１１１〜ステップＳ１２２の処理についても同じである。
【０１０８】
そして、図１７に示すシーケンス図においては、図３に示すシーケンス図におけるステップＳ１０７〜ステップＳ１１０を以下のステップに置き換える。
【０１０９】
すなわち、実行制御サーバ２０１はシナリオサーバ３０１にｕｒｉと日時を引数にしたメッセージを送る（ステップＳ１０７Ａ）。
続いて、シナリオサーバ３０１は、ビル情報サービスエンジン６０１からビル情報を得るためｕｒｉを引数としたgetメッセージを送る（ステップＳ１０８Ａ）。ビル情報サービスエンジン６０１は、得たｕｒｉを解析し、ビルＩＤを抽出する（ステップＳ１０９Ａ）。
【０１１０】
ビル情報サービスエンジン６０１は得たビルＩＤを引数にし、ビル情報サービスエンジン６０１内のビルＩＤデータベース（図１８（Ｂ）を参照）から、ビルＩＤが一致するものを抽出し、シナリオサーバ３０１に、該当するビルの住所を含んだビル情報を返す（図１８（Ｃ）に示すビル情報を参照）。
【０１１１】
そして、ステップＳ１１０Ａ〜ステップＳ１１１の間に以下のステップを挿入する。
シナリオサーバ３０１は、ビルの所在地を緯度、経度の形に直すために、位置参照ワークステーション（位置参照ＷＳ）９０１にビルの所在地を引数としたgetGeocodingメッセージを送る（ステップＳ１１０Ｂ）。位置参照ワークステーション９０１は、ビルの所在地を緯度、経度に返還してシナリオサーバ３０１に返す（ステップＳ１１０Ｃ、ステップＳ１１０Ｄ）。
【０１１２】
シナリオサーバ３０１は、保守管理情報ワークステーション５０１から保守者の情報を得るために保守管理情報ワークステーション５０１にｕｒｉを引数としたgetメッセージを送る（ステップＳ１１１）。保守管理情報ワークステーション５０１は、保守者のＳＩＰＵＲＩを得るために、保守者データベース５０２（図１８（Ａ）を参照）にアクセスし（ステップＳ１１２）、シナリオサーバ３０１にビルの緯度、経度と最も近い保守者のＳＩＰＵＲＩを返す（ステップＳ１１３）。
【０１１３】
なお、図１７に示すシーケンス図において、ステップＳ１１７〜ステップＳ１２０における保守者および管理者センタへの通知では、電話に出ると初めに異常が発生したビル、異常の内容などを自動に合成音声メッセージ、例えば、「○○ビル５階より空調の異常情報をお知らせいたします。メーカにおつなぎしますので、しばらくそのままでお待ち下さい。」などと流すことも可能である。これは、保守者への呼が確立した後に、シナリオサーバ３０１が、ｕｒｉからビル名、フロア、機器名を抽出し、これらを引数に呼制御イネーブラ４０１にメッセージ（playAudioMessgge）を送る。そして、呼制御イネーブラ４０１は、シナリオサーバ３０１から得た引数により、決められた ＶｏｉｃｅＸＭＬに従い、トーキーを出力することにより実現できる。
【０１１４】
なお、本発明の第５の実施の形態のビル管理装置においては、前述の所在データベースは、図１８（Ａ）に示すようなデータ形式（緯度と経度）で保守者の位置情報を保持する保守者データベース５０２が相当する。
【０１１５】
そして、第５の実施の形態のビル管理装置では、保守者の情報と、保守者の現在の所在情報（位置情報）とを関連付けて記録した保守者データベース５０２を備え、シナリオ実行部３１１が抽出したシナリオに従って通知を行う保守者を選択する際に、保守者データベース５０２を参照し、異常が発生したビル内装置に近い保守者を優先して選択する。
これにより、ビル内装置に異常が発生した場合に、異常が発生したビルに最も近い場所にいる（例えば、待機している）保守者を選定することができる。このため、ビル内装置の異常に対して迅速に対応できる。
【０１１６】
また、前述の通知先の端末に呼接続して異常情報（警報）を通知する呼制御手段は、呼制御イネーブラ４０１が相当し、この呼制御イネーブラ４０１では、異常情報に基づいて、異常情報の内容を通知するための合成音声メッセージを生成し、該合成音声メッセージを通知先の端末に通知する。
これにより、シナリオサーバ３０１から呼制御イネーブラ４０１に、例えば、ビル名、フロア、機器名等を引数として送るだけで、呼制御イネーブラ４０１により異常情報を通知するための合成音声メッセージを生成して通知先の端末に通知することができる。
【０１１７】
「第６の実施の形態」
次に、本発明の自動警報通知装置の第６の実施の形態に係るビル管理装置として、保守者が電話にでたことを、例えば、「＃ボタン」などを押すことにより、確かめる例について説明する（留守番電話等に接続することなく）。
【０１１８】
図１９は、本発明の第６の実施の形態における処理の流れを示すシーケンス図である。図１９に示すシーケンス図は、図３に示すシーケンス図に、ステップＳ１３０、ステップＳ１３１、およびステップＳ１３２を新たに追加したものであり、他のステップについては、図３に示すシーケンス図と同様である。
【０１１９】
すなわち、図１９に示すシーケンス図におけるステップＳ１３０、ステップＳ１３１，およびステップＳ１３２に示すように、保守者が電話に出て、かつ、対応可能な場合であることを確かめるために、シナリオサーバ３０１は、Subscribeメッセージを呼制御イネーブラ４０１に投げる（ステップＳ１３０）。
【０１２０】
そして、呼制御イネーブラ４０１からＳＩＰ端末３２への接続処理の後、ＳＩＰ端末３２で「＃ボタン」が押されると（ステップＳ１３１）、notificationメッセージがシナリオサーバ３０１に届き（ステップＳ１３２）、ステップＳ１２０に進む。なお、呼が確立されたのにも関わらず、かつ、一定時間が過ぎても、「＃ボタン」が押されない場合は、シナリオサーバ３０１は、endCallメッセージで呼を切断し、次の保守者に通知するために、ステップＳ１１４に戻る。
【０１２１】
図２０は、第６の実施の形態における保守者への確認処理の流れを示すフローチャートである。図２０に示すフローチャートにおいて、ステップＳ１１４〜ステップＳ１１９までの処理については、図４に示すフローチャートと同様であり、重複する説明は省略する。
【０１２２】
図２０に示すフローチャートにおいて、呼制御イネーブラ４０１とＳＩＰ端末３２とが接続されたのち、シナリオサーバ３０１は、ＳＩＰ端末３２で「＃ボタン」が押されたかどうかを判定する（ステップＳ１３２Ａ）。呼が確立されたのにも関わらず、かつ、一定時間が過ぎても、「＃ボタン」が押されない場合は（ステップＳ１３２Ａ：未受信）、シナリオサーバ３０１は、endCallメッセージで呼を切断し（ステップＳ１３２Ｂ）、次の保守者に通知するために、ステップＳ１１４に戻る。「＃ボタン」が押された場合は（ステップＳ１３２Ａ：受信）、次のステップ（製造メーカに通知）へ進む。
【０１２３】
このように、本発明の第６の実施の形態のビル管理装置においては、保守者のＳＩＰ端末３２にビル内装置１１に異常が発生したことを通知した際に、保守者のＳＩＰ端末の、例えば、＃ボタンまたは所定のボタンが押された場合は、当該保守者が応答したことを検知する。これにより、保守者はビル内装置の異常発生の通知を受けたことを、迅速かつ容易に応答することができる。
【０１２４】
なお、本発明の第６の実施の形態のビル管理装置において、前述の応答検知手段は、呼制御イネーブラ４０１と、シナリオサーバ３０１とにより、その機能が実現される手段である。そして、シナリオサーバ３０１では、呼制御イネーブラ４０１を介して、通知先の端末に予め定められた釦の押下を検知することによって、保守者が該異常情報の通知に応答したものと判断する。
【０１２５】
［第７の実施の形態］
次に、本発明の自動警報通知装置の第７の実施の形態に係るビル管理装置について説明する。この第７の実施の形態は、第６の実施の形態のシーケンス図（図１９を参照）におけるステップＳ１１７以下の処理手順において、保守者への呼が確立し、合成音声メッセージを保守者が聞き、対応不可能と判断した場合に、次の保守者に発呼する例である。
【０１２６】
この第７の実施の形態においては、第６の実施の形態におけるシーケンス図（図１９）は共通のものとなる。ただし、ステップＳ１３１において、保守者が対応できない場合にＳＩＰ端末３２において、例えば、「＊ボタン」が押される点が異なる。
【０１２７】
すなわち、図１９に示すシーケンス図において、シナリオサーバ３０１はSubseribeメッセージを呼制御イネーブラ４０１に投げる（ステップＳ１３０）。ＳＩＰ端末３２で「＊ボタン」が押され、notificationメッセージがシナリオサーバ３０１に届くと（ステップＳ１３２）、シナリオサーバ３０１は次の保守者に通知するためにステップＳ１１４に戻る。
【０１２８】
図２１は、第７の実施の形態における保守者の確認処理の流れを示すフローチャートである。図２１に示すフローチャートは、図２０に示すフローチャートと比較して、ステップＳ１３２Ｃにおいて、保守者が対応できない場合にＳＩＰ端末３２の「＊ボタン」が押される点だけが異なる。その他の処理内容は同様である。
【０１２９】
この第７の実施の形態における「＊ボタン」を押す確認処理と、第６の実施の形態における「＃ボタン」を押す確認処理とは、シナリオサーバ３０１において、電話をかける人の選択方法により、シナリオを書き換えることにより実現する。
【０１３０】
このように、本発明の第７の実施の形態のビル管理装置においては、保守者のＳＩＰ端末３１にビル内装置１１に異常が発生したことを通知した際に、保守者のＳＩＰ端末３２の、例えば、＊ボタンまたは所定のボタンが押された場合は、当該保守者が対応不可能であることを検出し、次の候補となる保守者に発呼する。
これにより、保守者はビル内装置の異常発生の通知を受けたことと、対応不可能であることを示す際に、迅速かつ容易に応答することができる。このため、ビル管理装置では、次の候補となる保守者に迅速に発呼することができる。
【０１３１】
なお、本発明の第７の実施の形態のビル管理装置において、前述の応答不可検知手段は、呼制御イネーブラ４０１とシナリオサーバ３０１とにより、その機能が実現される手段である。そして、シナリオサーバ３０１では、呼制御イネーブラ４０１を介して、情報通知先の端末に予め定められた釦の押下を検知することによって、保守者が該異常情報の通知に対応不可能であると判断する。
【０１３２】
［第８の実施の形態］
次に、本発明の自動警報通知装置の第８の実施の形態に係るビル管理装置は、保守者（オーナ）とビルの警備員室、メーカなど、例えば、図３に示す第１の実施の形態のシーケンス図において、ステップＳ１１９〜ステップＳ１２０との間でさらにもう一人に通知し、３ＰＣＣによる三者通話も可能とした例である。
【０１３３】
図２２は、第８の実施の形態における処理の流れを示すシーケンス図である。図２２に示すシーケンス図において、ステップＳ１０１〜ステップＳ１１９までは、図３に示すシーケンス図と同様であり、重複する説明は省略する。
【０１３４】
図２２に示すシーケンス図において、初めの者への呼や確立したら、シナリオサーバ３０１は、第２者と第３者のＵＲＩ（SIPURIs）を引数に「addCallParticipant」というＳＯＡＰメッセージを呼制御イネーブラ４０１に送る（ステップＳ１４０）。呼制御イネーブラ４０１は、第２者目と第３者目に発呼し、三者通話を実現させる（ステップＳ１４１）。なお、繋がらなかった場合は、シナリオサーバ３０１ら呼制御イネーブラ４０１にdeleteCallParticipant（SIPURI）メッセージを送り（ステップＳ１４２）、ＳＩＰ端末との接続を切断する（ステップＳ１４３）。
【０１３５】
このように、本発明の第８の実施の形態のビル管理装置においては、保守者のＳＩＰ端末３２に対し、ビル内装置１１に異常が発生したことを通知する際に、３ＰＣＣによる三者通話により保守者以外の端末へも同時に通知すると共に、保守者の端末と保守者以外の端末と間の通話を確立する。
これにより、ビル内装置から発生される警報を契機に、３ＰＣＣを利用して保守者とメーカの間の通話を確立するという新しいサービスを提供できる。
【０１３６】
なお、本発明の第８の実施の形態のビル管理装置において、前述の三者通話確立手段は、シナリオサーバ３０１からの指示により呼制御イネーブラ４０１が３ＰＣＣ接続を行うことにより、その機能が実現される手段である。そして、呼制御イネーブラ４０１では、シナリオサーバ３０１からに指示により、通知先の端末に異常情報を通知すると共に、該通知先の端末と異なる第２の通知先の端末にも通知する。
【０１３７】
［第９の実施の形態］
次に、本発明の自動警報通知装置の第９の実施の形態に係るビル管理装置として、保守者のプレゼンス情報データベースを利用して、予定のあいている保守者に通知する例について説明する。なお、プレゼンス情報とは、スケジュール情報に関連した情報であり、保守者の状況または行動等を示す情報である。
【０１３８】
図２３は、第９の実施の形態における処理の流れを示すシーケンス図である。図２３に示すシーケンス図においては、図３に示すシーケンス図と比較して、呼制御イネーブラ４０１内にプレゼンス情報データベース４０２が新たに追加されている。このプレゼンス情報データベース４０２に、保守者のＳＩＰ端末３２からプレゼンス情報が登録される。
【０１３９】
なお、プレゼンス情報データベース４０２は、呼制御イネーブラ４０１内ではなく、独立したサーバ（プレゼンス情報サーバ）を設けて、このサーバ内に設けるようにしてもよい。
【０１４０】
また、図２３に示すシーケンス図の各処理ステップは、図３に示すシーケンス図の処理ステップと比較して、破線で囲んだ部分のステップＳ１１１Ａと、ステップＳ１１１Ｂと、ステップＳ１１１Ｃとが追加、変更された点だけが異なる。他のステップについては、図３に示すシーケンス図と同様である。このため、重複する説明は省略する。
【０１４１】
図２３に示すシーケンス図において、保守管理情報ワークステーションは、保守者のＩＤを引数にgetUserPresenceメッセージを呼制御イネーブラ４０１に送る（ステップＳ１１１Ａ）。呼制御イネーブラ４０１は保守者のプレゼンス情報をプレゼンス情報データベース４０２から抽出し、保守管理情報ワークステーションに渡す（ステップＳ１１１Ｂ）。保守管理情報ワークステーション５０１は、呼制御イネーブラ４０１から受け取った保守者のプレゼンス情報をシナリオサーバ３０１に渡す（ステップＳ１１１Ｃ）。
【０１４２】
この構成により、保守者のプレゼンス情報データベースを利用して、予定のあいている保守者に通知することが可能になる。
【０１４３】
このように、本発明の第９の実施の形態のビル管理装置においては、保守者の状況および行動予定の情報をプレゼンス情報として登録するプレゼンス情報データベース４０２を備え、保守者の通知先情報を選択する際に、プレゼンス情報データベース４０２を参照し、予定の空いている保守者に通知する。
これにより、ビル内装置に異常が発生した場合に、プレゼンス情報データベース４０２を基に、予定の空いている保守者を迅速に選定することができる。
【０１４４】
以上、本発明の第１の実施の形態から第９の実施の形態に説明したように、本発明の自動警報通知装置においては、以下の効果を得ることができる。すなわち、これまでも警報を保守者へ通知するサービスはあったが、いずれもシステムとして作り込みが必要で、通知方法などを柔軟に変更することはむずかしかった。例えば、「メールで通知するか電話で通知するか」や、「ビルの近くにいる保守者を選択するか、または対応回数が多い保守者を選択するか」といった通知方法を柔軟に変更することはむずかしかった。本発明により、ウェブサービスインターフェース（Ｉ／Ｆ）ベースのテレコム（Telcom）イネーブラを経由し、ビルで発生したイベントを契機にテレコム機器を呼び出す様々なサービスを、短期間、低コネトで開発、実現することができる。
【０１４５】
また、ビル内装置から発生される警報を契機に、３ＰＣＣ（3rd Party Call Control)を利用して保守者とメーカの間の通話を確立するという新しいサービスを提供できる。
【０１４６】
また、保守者やメーカなどの関係者が、情報を利用して運用にあわせた情報を追加したり、呼出方法を切り替えたりすることができる。例えば、図５に示すように、保守者を選択する場合に、予定の空いている者を選択する方法、対応回数の多いものを選択する方法、または、ビルに近い者を選択するなどの方法を用いることができる。
【０１４７】
また、本発明の自動警報通知装置は、ネットワークサービスプラットフォーム（ＮＷＳＰＦ）と、ビルウェブサービスゲートウェイと、ビル内装置から組みあわされるシステム構成であり、ビルで発生した警報（イベント）を契機にネットワークサービスプラットフォーム（ビル管理サーバ群）で集約し、ネットワークサービスプラットフォーム（ＮＷＳＰＦ）の呼制御イネーブラを経由し、ウェブサービスＩ／Ｆで３ＰＣＣや会議電話（conference call）などのテレコムサービスを呼ぶシステムである。このため、イベントの内容に応じていろんなサービスを呼び出すことができる。
【０１４８】
また、シナリオサーバ３０１におけるシナリオを書き換えることにより、警報の通知者を選択する方法を柔軟に追加、変更することができる。シナリオサーバ３０１には、「通知者を選択」「通知方法を選択」等といった機能を記述し、どのように選択するかという選択の実現部分については他のサーバと連携させることによりこれを可能にする。シナリオサーバ３０１に通知者の情報を置かないことにより、シナリオサーバ３０１の汎用性を保ち、サービスの組合せ（シナリオ）を柔軟に変更することができる。
【０１４９】
また、本発明の自動警報通知装置は、組み合わされたサービスの情報を、サービスインターフェース（Ｉ／Ｆ）を介して、保守者やメーカなどの関係者のシステムと連係する仕組みを有する。広域のビル管理において複数の保守会社が存在する場合、各社の保守者管理システムに合わせた対応が可能となり緊急の保守者変更や通知先の変更などに柔軟に対応することができる。
【０１５０】
また、群管理サーバ１０１により、シナリオサーバ３０１は複数ビルのデータを一元的に扱うことが可能になる。さらに、全体のシステム構成を変更する場合においても、個々のビルの内部構成を変更することなく、システム構成の変更が可能になる。
【０１５１】
以上、本発明の実施の形態について説明したが、上述の群管理サーバ１０１、実行制御サーバ２０１、シナリオサーバ３０１、呼制御イネーブラ４０１、および保守管理情報ワークステーション５０１は内部にコンピュータシステムを有している。
【０１５２】
そして、上述した処理に関する一連の処理の過程は、プログラムの形式でコンピュータ読み取り可能な記録媒体に記憶されており、このプログラムをコンピュータが読み出して実行することによって、上記処理が行われる。
【０１５３】
すなわち、群管理サーバ１０１、実行制御サーバ２０１、シナリオサーバ３０１、呼制御イネーブラ４０１、および保守管理情報ワークステーション５０１における、各処理は、ＣＰＵ等の中央演算処理装置がＲＯＭやＲＡＭ等の主記憶装置に上記プログラムを読み出して、情報の加工、演算処理を実行することにより、実現されるものである。
【０１５４】
ここでコンピュータ読み取り可能な記録媒体とは、磁気ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、半導体メモリ等をいう。また、このコンピュータプログラムを通信回線によってコンピュータに配信し、この配信を受けたコンピュータが当該プログラムを実行するようにしても良い。
【０１５５】
また、群管理サーバ１０１、実行制御サーバ２０１、シナリオサーバ３０１、呼制御イネーブラ４０１、および保守管理情報ワークステーション５０１には、周辺機器として入力装置、表示装置等（いずれも表示せず）が接続されているものとする。ここで、入力装置としては、キーボード、マウス等の入力デバイスのことをいう。表示装置とは、ＣＲＴ（Cathode Ray Tube）や液晶表示装置等のことをいう。
【０１５６】
以上、本発明の実施の形態について説明したが、本発明の自動警報通知装置は、上述の図示例にのみ限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変更を加え得ることは勿論である。
【符号の説明】
【０１５７】
１１・・・ビル内装置（ビル設備機器）、２１・・・ビルウェブサービスゲートウェイ、３１・・・保守者、３２・・・保守者のＳＩＰ端末、４１・・・保守管理センタ、４２・・・保守管理センタのＳＩＰ端末、１０１・・・群管理サーバ、２０１・・・実行制御サーバ、３０１・・・シナリオサーバ、３１１・・・シナリオ実行部、４０１・・・呼制御イネーブラ、５０１・・・保守管理情報ワークステーション、５０１Ａ，５０１Ｂ・・・保守管理情報ワークステーション、５０２・・・保守者データベース、５０３・・・保守管理センタデータベース、６０１・・・ビル情報サービスエンジン、７０１・・・スケジューラワークステーション、７０２・・・スケジューラデータベース、８０１・・・ユーザマネージャーワークステーション、９０１・・・位置参照ワークステーション
【図１】
2010231422.tif 000003
【図２】
2010231422.tif 000004
【図３】
2010231422.tif 000005
【図４】
2010231422.tif 000006
【図５】
2010231422.tif 000007
【図６】
2010231422.tif 000008
【図７】
2010231422.tif 000009
【図８】
2010231422.tif 000010
【図９】
2010231422.tif 000011
【図１０】
2010231422.tif 000012
【図１１】
2010231422.tif 000013
【図１２】
2010231422.tif 000014
【図１３】
2010231422.tif 000015
【図１４】
2010231422.tif 000016
【図１５】
2010231422.tif 000017
【図１６】
2010231422.tif 000018
【図１７】
2010231422.tif 000019
【図１８】
2010231422.tif 000020
【図１９】
2010231422.tif 000021
【図２０】
2010231422.tif 000022
【図２１】
2010231422.tif 000023
【図２２】
2010231422.tif 000024
【図２３】
2010231422.tif 000025