(57)【要約】【課題】気象情報等の報知情報と報知情報に係る気象現象等に影響を受け得る管理対象の状況を、管理対象に専用の機器を用いることなく、一括して管理すること。【解決手段】自然災害等の報知情報がメールで配信すべき情報であると判断された場合には、報知情報と紐付けされた地域情報に該当する管理対象情報が抽出され、管理対象情報に関する掲示板３００のデータが作成され、掲示板３００のリンク先が記載されたメールが担当者以外の閲覧者に配信される。また、掲示板３００に表示される情報のうち、担当者の管理対象に関する情報を表示する画面１００のリンク先が記載されたメールが担当者に配信される。【選択図】図２
2019160175.tif 000002
【特許請求の範囲】
【請求項１】
地域情報と紐付けられた報知情報を取得する情報取得部と、
管理対象情報を、地域情報、および管理対象の担当者の所属情報と紐付けて記憶する管理対象情報記憶部と、
前記報知情報ごと、および地域ごとに、前記報知情報をメールで配信すべきか否かを示すメール配信情報を記憶するメール配信情報記憶部と、
前記担当者および前記担当者以外の閲覧者のメールアドレスを、前記担当者および前記閲覧者、並びに前記所属情報と紐付けて記憶するメールアドレス記憶部と、
グループごとに、メールの配信パターンおよび前記所属情報と紐付けて前記担当者および前記閲覧者を記憶する配信先情報記憶部と、
前記メール配信情報に基づいて、前記報知情報をメールで配信すべきと判断した場合には、前記報知情報と紐付けられた前記地域情報に基づいて、当該地域情報と紐付けられた前記管理対象情報が存在するか否かを判定する判定部と、
前記管理対象情報が存在すると判定された場合に、前記管理対象情報に関する掲示板のデータを作成する掲示板データ作成部と、
前記管理対象情報が存在すると判定された場合に、前記報知情報および前記管理対象情報の少なくともいずれか一方が、前記配信パターンに合致する前記グループを判別し、判別したグループに属する前記担当者および前記閲覧者の前記所属情報、または当該所属情報と紐付けられた前記担当者および前記閲覧者を読み出し、前記メールアドレス記憶部から前記担当者および前記閲覧者のメールアドレスを抽出する抽出部と、
前記閲覧者のメールアドレス宛てには、前記掲示板のリンク先が記載されたメールを配信し、前記担当者のメールアドレス宛てには、前記掲示板に表示される情報のうち、前記担当者の管理対象に関する情報を表示する画面のリンク先が記載されたメールを配信するメール配信部と、
前記掲示板に表示される情報が編集された場合に、当該編集された情報を前記掲示板で共有可能に管理する管理部と、を備える、
ことを特徴とする報知情報管理システム。
【請求項２】
前記報知情報は、防災情報、気象情報、災害情報、およびライフラインに関する情報である、
ことを特徴とする請求項１に記載の報知情報管理システム。
【請求項３】
前記担当者のメールアドレス宛のメールに記載されたリンク先の前記画面には、当該担当者の管理対象と、編集可能な当該管理対象に対する対応状況とが一覧表示されており、
前記担当者以外の閲覧者のメールアドレス宛のメールに記載されたリンク先の前記掲示板には、一または複数の前記地域情報に対応する前記管理対象および当該管理対象に対する対応状況を含む概要情報の一覧と、前記管理対象の位置を示す地図とが表示されている、
ことを特徴とする請求項１または請求項２に記載の報知情報管理システム。
【請求項４】
前記掲示板データ作成部は、前記報知情報ごとに前記掲示板のデータを作成する、
ことを特徴とする請求項１ないし請求項３のいずれか１項に記載の報知情報管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、報知情報を管理する報知情報管理システムに関する。
【背景技術】
【０００２】
従来、情報源から情報を取得し、当該情報を配信および管理するシステムは存在していた。例えば、特許文献１に記載のシステムにおいては、観測情報装置から災害観測情報を取得し、各地域の被害発生の可能性を判定する災害判定部を設け、被害発生の可能性が有ると判定された該当地域を管轄する情報提供者の電子メールアドレスを抽出し、被害内容を問う災害情報メールを送信する。また、情報提供者から返信された災害情報返信メールに記載された被害内容を、電子メール判定部により自動的に災害ＩＤに関連付けて災害情報データベースに分類、蓄積する。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１０−１８６３１４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、特許文献１のシステムでは、任意の建物が被害の該当地域であるか否かの気付きや、当該建物の詳細情報についての共有化が行われておらず、建物の被害状況等を一括して管理することが困難である。また、任意の建物の情報を配信するシステムでは、情報の発信源が人であるため、情報伝達の漏れ等により、利用ユーザは、当該建物が被害対象および被害の可能性のある対象であることに気付けない恐れがある。また、従来のシステムの場合、専用機器から情報の発信を行い、受信側においても建物ごとに専用機器を導入する必要があった。また、従来のシステムでは、発信される情報が特定の情報に特化されており、多種の情報を取り扱えなかった。
【０００５】
上述のような問題は、管理対象が建物の場合に限らず、例えば、介護を必要とする人等を管理対象とする場合も同様であった。
【０００６】
そこで、本発明は、気象情報や防災情報等の報知情報と、当該報知情報に係る気象現象等に影響を受け得る管理対象の状況を、管理対象に専用の機器を用いることなく、一括して管理することが可能な報知情報管理システムを提供することを課題とする。
【課題を解決するための手段】
【０００７】
前記課題を解決するため、本発明の報知情報管理システムの一態様は、
地域情報と紐付けられた報知情報を取得する情報取得部と、
管理対象情報を、地域情報、および管理対象の担当者の所属情報と紐付けて記憶する管理対象情報記憶部と、
前記報知情報ごと、および地域ごとに、前記報知情報をメールで配信すべきか否かを示すメール配信情報を記憶するメール配信情報記憶部と、
前記担当者および前記担当者以外の閲覧者のメールアドレスを、前記所属情報と紐付けて記憶するメールアドレス記憶部と、
グループごとに、メールの配信パターンおよび前記所属情報と紐付けて前記閲覧者を記憶する配信先情報記憶部と、
前記メール配信情報に基づいて、前記報知情報をメールで配信すべきと判断した場合には、前記報知情報と紐付けられた前記地域情報に基づいて、当該地域情報と紐付けられた前記管理対象情報が存在するか否かを判定する判定部と、
前記管理対象情報が存在すると判定された場合に、前記管理対象情報に関する掲示板のデータを作成する掲示板データ作成部と、
前記管理対象情報が存在すると判定された場合に、前記報知情報および前記管理対象情報の少なくともいずれか一方が、前記配信パターンに合致する前記グループを判別し、判別したグループに属する前記担当者および前記閲覧者の前記所属情報、または当該所属情報と紐付けられた前記担当者および前記閲覧者を読み出し、前記メールアドレス記憶部から前記担当者および前記閲覧者のメールアドレスを抽出する抽出部と、
前記閲覧者のメールアドレス宛てには、前記掲示板のリンク先が記載されたメールを配信し、前記担当者のメールアドレス宛てには、前記掲示板に表示される情報のうち、前記担当者の管理対象に関する情報を表示する画面のリンク先が記載されたメールを配信するメール配信部と、
前記掲示板に表示される情報が編集された場合に、当該編集された情報を前記掲示板で共有可能に管理する管理部とを備える、
ことを特徴とする。
【０００８】
本態様において、「担当者」とは、例えば、国内の各地に置かれた拠点の担当者であり、建物（物件）の状況を確認して、建物が受けた影響の有無等の報告を行う業務の担当者である。また、「閲覧者」は、例えば、本社の役員、管理職、関係部署等である。
【０００９】
上記一態様によれば、報知情報がメールで配信すべき情報であると判断された場合には、報知情報と紐付けされた地域情報に該当する管理対象情報が抽出され、管理対象情報に関する掲示板のデータが作成され、掲示板のリンク先が記載されたメールが担当者以外の閲覧者に配信される。また、掲示板に表示される情報のうち、担当者の管理対象に関する情報を表示する画面のリンク先が記載されたメールが担当者に配信される。したがって、担当者と担当者以外の閲覧者は、報知情報を逃すことなくリアルタイムで知ることができる。また、掲示板に表示される情報が編集された場合には、編集された情報が掲示板で共有可能に管理されるので、必要な情報を一括で管理し、かつ、共有することができる。
【００１０】
次に、本発明の報知情報管理システムの他の態様は、前記報知情報は、防災情報、気象情報、災害情報、およびライフラインに関する情報であることを特徴とする。この態様によれば、防災情報、気象情報、災害情報、およびライフラインに関する情報、並びに、これらの気象等の影響を受け得る管理対象の情報を一括で管理し、かつ、共有することができる。
【００１１】
次に、本発明の報知情報管理システムの他の態様は、前記担当者のメールアドレス宛のメールに記載されたリンク先の前記画面には、当該担当者の管理対象と、編集可能な当該管理対象に対する対応状況とが一覧表示されており、前記担当者以外の閲覧者のメールアドレス宛のメールに記載されたリンク先の前記掲示板には、一または複数の前記地域情報に対応する前記管理対象および当該管理対象に対する対応状況を含む概要情報の一覧と、前記管理対象の位置を示す地図とが表示されていることを特徴とする。この態様によれば、担当者は、報知情報を逃すことなくリアルタイムで自分の管理対象の状況を確認することができ、その対応状況を報告することができる。また、担当者以外の閲覧者は複数の担当者の管理対象の対応状況を一括して確認することができ、対応状況の共有を図ることができる。
【００１２】
次に、本発明の報知情報管理システムの他の態様は、前記掲示板データ作成部は、前記報知情報ごとに前記掲示板のデータを作成することを特徴とする。この態様によれば、必要な情報を網羅的に集約し、共有することができる。
【発明の効果】
【００１３】
本発明によれば、気象情報や防災情報等の報知情報と、当該報知情報に係る気象現象等に影響を受け得る管理対象の状況を、管理対象に専用の機器を用いることなく、一括して管理することが可能となる。
【図面の簡単な説明】
【００１４】
【図１】本発明の一実施形態に係る報知情報管理システムの構成を示すブロック図である。
【図２】報知情報管理システムの処理の流れを示すシーケンス図である。
【図３】報知情報としてのＸＭＬ形式のデータの一例を模式化した図である。
【図４】メール配信設定テーブルの一例を示す図である。
【図５】建物マスタの一例を示す図である。
【図６】人事マスタの一例を示す図である。
【図７】部署マスタの一例を示す図である。
【図８】配信先マスタの一例を示す図である。
【図９】テンプレートを用いて作成されたメールの一例を示す図である。
【図１０】テンプレートを用いて作成されたメールの一例を示す図である。
【図１１】担当者用の画面の一例を示す図である。
【図１２】詳細閲覧画面の一例を示す図である。
【図１３】閲覧者用の掲示板の一例を示す図である。
【図１４】閲覧者用の掲示板の一例を示す図である。
【図１５】閲覧者用の掲示板に表示されるグラフの一例を示す図である。
【発明を実施するための形態】
【００１５】
本発明の一実施形態に係る報知情報管理システムについて、図面を参照しつつ説明する。本実施形態は、管理対象を建物とする例で説明する。
【００１６】
（１）報知情報管理システムの概要
図１は、本発明の一実施形態に係る報知情報管理システム１の構成を示すブロック図である。図１に示すように、本実施形態に係る報知情報管理システム１は、マッチングサーバ１０と、データベースサーバ２０と、管理サーバ３０とを備えている。
【００１７】
マッチングサーバ１０は、図示を省略する記憶部に記憶されたプログラムを実行することにより、マッチング処理部１２と、メール配信部１３として機能する。情報取得部１１は、報知情報としての自然災害情報、ライフライン情報等を提供する自然災害情報サービス会社５０のコンテンツシェアサービスサーバ５１と通信可能となっており、コンテンツシェアサービスサーバ５１に対して一定時間ごとにポーリングを行う。本実施形態では、一例として、５分ごとにポーリングを行う。情報取得部１１は、コンテンツシェアサービスサーバ５１に新たなデータが追加された場合には、そのデータの内容を取得する。
【００１８】
コンテンツシェアサービスサーバ５１から配信されるデータとしては、例えば、気象警報・注意報、地震情報、防災気象情報、および電気、ガス、水道等のライフライン情報のデータが含まれる。
【００１９】
マッチング処理部１２は、本発明の判定部、掲示板データ作成部、および抽出部として機能する。マッチング処理部１２は、情報取得部１１によって取得されたデータに、配信が必要な情報が含まれているか否かを判断し、所定の処理を行う。マッチング処理部１２は、データベースサーバ２０の自然災害記録部２１、建物マスタ記憶部２３、および配信先マスタ記憶部２６と通信可能となっている。マッチング処理部１２は、配信先マスタ記憶部２６に記憶されたメール配信設定テーブルに設定された配信すべき気象情報等の情報と、取得されたデータに含まれる気象情報等の情報とを照合する。配信先マスタ記憶部２６は、本発明のメール配信情報記憶部として機能する。また、マッチング処理部１２は、建物マスタ記憶部２３に記憶された管理対象としての建物が属する地域情報と、取得されたデータに含まれる地域情報とを照合する。建物マスタ記憶部２３は、本発明の管理対象情報記憶部として機能する。マッチング処理部１２は、これらの情報の照合の結果、取得されたデータに配信が必要な情報が含まれているか否かを判断する。
【００２０】
マッチング処理部１２は、取得されたデータに、配信が必要な情報が含まれていると判断した場合には、当該情報を自然災害記録部２１に記録する。また、当該情報が警報等であった場合に、警報が解除された際には、前記情報の更新を行う。
【００２１】
抽出部としてのマッチング処理部１２は、データベースサーバ２０の人事マスタ記憶部２４とも通信可能となっている。マッチング処理部１２は、上述した配信が必要と判断した情報の配信先のグループを、配信先マスタ記憶部２６に記憶された配信先マスタ２６ａ（図８参照）から読み出す。
【００２２】
配信先マスタ２６ａにおける配信先のグループの設定は、管理サーバ３０の自然災害情報ポータルサイト３１において行うことができ、設定した情報は、配信先マスタ２６ａに登録される。自然災害情報ポータルサイト３１は、マッチングサーバ１０のマッチング処理部１２と通信可能であり、マッチング処理部１２は、管理サーバ３０の部署マスタ記憶部２５と通信可能である。部署マスタ記憶部２５には、例えば図７に示すように、前記担当者および閲覧者の所属情報としての組織コード、組織名、省略名称等の情報が含まれている。配信先のグループの設定の際、自然災害情報ポータルサイト３１において表示される部署は、部署マスタ記憶部２５に記録された情報が参照される。また、役職等の所属情報等は、人事マスタ記憶部２４に記録された情報が参照される。
【００２３】
各グループには、災害の種別またはレベルに応じた配信パターンが設定されており、この配信パターンと配信先のメンバーとして担当者および閲覧者とが紐付けられている。マッチング処理部１２は、配信が必要と判断した情報と配信パターンとを照合することにより、配信先のグループを判別し、災害の種別またはレベルに応じて異なる配信先のメンバーを読み出すことができる。
【００２４】
さらに、マッチング処理部１２は、配信先マスタ２６ａから読み出した配信先のメンバーと、人事マスタ記憶部２４に記憶された人事マスタ２４ａ（図６参照）とを照合することにより、配信先のメンバーの配信先メールアドレスを抽出する。人事マスタ記憶部２４は、メールアドレス記憶部として機能する。
【００２５】
この場合の前記情報の配信先メールアドレスは、前記建物の担当者のメールアドレスである。「担当者」とは、例えば、国内の各地に置かれた拠点の担当者であり、建物（物件）の状況を確認して、建物が受けた影響の有無等の報告を行う業務の担当者である。また、「閲覧者」は、例えば、本社の役員、管理職、関係部署等であり、国内の各地の担当者から報告される状況を、一括して把握することができる。
【００２６】
マッチング処理部１２は、上述のように配信が必要と判断した気象情報等の情報、建物の情報、配信先の情報をメール配信部１３に受け渡す。メール配信部１３は、災害等に応じてテンプレートを選択し、前記配信先にメール８０を配信する。テンプレートは、配信先マスタ２６ａに設定される前記グループと紐付けられている。テンプレートの一例等については後述する。
【００２７】
データベースサーバ２０には、同期バッチ処理部２８が備えられており、同期バッチ処理部２８は、報知情報管理システム１を運用している運用会社４０の既存システム４１と通信可能となっている。既存システム４１において作成された建物・人事情報ＣＳＶデータ２７は、既存システム４１から同期バッチ処理部２８へと送信される。同期バッチ処理部２８は、建物・人事情報ＣＳＶデータ２７に基づいて、建物マスタ記憶部２３、人事マスタ記憶部２４、および部署マスタ記憶部２５の各データを作成・更新する。同期バッチ処理部２８による同期バッチ処理は、定期的に、例えば毎日行われている。したがって、人事異動等があった場合でも、適切な情報を、適切な担当者および閲覧者に配信することができる。
【００２８】
掲示板データ作成部としてのマッチング処理部１２は、上述のようにメールの配信を行った災害等の情報を、掲示板により担当者、およびその他の閲覧者と共有するために、当該掲示板を表示するためのデータを作成し、データベースサーバ２０の災害報告記録部２２に記録する。
【００２９】
マッチング処理部１２は、管理サーバ３０とも通信可能となっている。管理サーバ３０には、掲示板を表示するための自然災害情報ポータルサイト３１が予め作成されている。上述のようにメール配信部１３によって、担当者以外の閲覧者に配信されたメールには、自然災害情報ポータルサイト３１において表示される掲示板のリンク先が記載されている。また、上述のようにメール配信部１３によって、担当者に配信されたメールには、掲示板のうち、担当者の管理対象に関する情報を表示する画面のリンク先が記載されている。したがって、メールを受け取ったユーザ７０としての閲覧者が、リンク先をクリックすると、自然災害情報ポータルサイト３１において掲示板が表示される。また、メールを受け取ったユーザ７０としての担当者が、リンク先をクリックすると、自然災害情報ポータルサイト３１において、掲示板のうち、担当者の管理対象に関する情報を表示する画面が表示される。
【００３０】
管理部としての管理サーバ３０は、自然災害情報ポータルサイト３１へのアクセスがあった場合には、掲示板を表示するための情報を、マッチングサーバ１０のマッチング処理部１２に対して要求する。マッチング処理部１２は、掲示板を表示するために必要なデータを、データベースサーバ２０の災害報告記録部２２から取得し、管理サーバ３０へ送信する。管理サーバ３０は、前記データを受信し、自然災害情報ポータルサイト３１において掲示板として表示する。
【００３１】
また、上述したように、自然災害情報ポータルサイト３１においては、グループの設定も可能になっている。グループの設定を行うことのできるユーザは、管理サーバ３０に備えられたサイト権限マスタ記憶部３２に記憶されたサイト権限マスタにより管理されている。
【００３２】
（２）報知情報管理システムの処理の流れ
次に、本実施形態における報知情報管理システム１の処理の流れについて、図２から図１５を参照しつつ説明する。図２は、報知情報管理システム１の処理の流れを示すシーケンス図である。
【００３３】
図２に示すように、マッチングサーバ１０は、情報取得部１１により、コンテンツシェアサービスサーバ５１に対して、例えば５分ごとにポーリングを行う（Ｓ１）。コンテンツシェアサービスサーバ５１においては、警報等のデータが、例えばＸＭＬ形式のデータで一つのＵＲＬ内に記載され、ＵＲＬのリストとして提供されている。したがって、情報取得部１１は、このリストをチェックし、新たなＵＲＬが追加されていた場合には、新たなデータが追加されたと判断して、当該ＵＲＬにアクセスし、ＸＭＬ形式のデータを取得する（Ｓ２）。
【００３４】
図３は、前記ＸＭＬ形式のデータＤＴの一例を模式化した図である。図３に示すように、データＤＴには、第１カテゴリＤＴ１、第２カテゴリＤＴ２、情報番号ＤＴ３、都道府県ＤＴ４、市町村ＤＴ５、レベルＤＴ６、およびその他ＤＴ７が含まれている。第１カテゴリＤＴ１は、災害種別を示すデータであり、例えば、気象災害、地震災害、ライフライン情報、防災気象情報等を示す。
【００３５】
第２カテゴリＤＴ２は、第１カテゴリＤＴ１に記載された災害種別の詳細を示すデータである。第１カテゴリＤＴ１のデータが気象災害の場合は、第２カテゴリＤＴ２に、例えば大雨や大雪等の注警報等を示すデータが記載される。第１カテゴリＤＴ１のデータが地震災害の場合は、例えば第２カテゴリＤＴ２に地震情報を示すデータが記載される。第１カテゴリＤＴ１のデータがライフライン情報の場合は、第２カテゴリＤＴ２に、例えば電気情報、ガス情報、水道情報等が記載される。第１カテゴリＤＴ１のデータが防災気象情報の場合は、第２カテゴリＤＴ２に、河川洪水情報、土砂災害警戒情報、竜巻注意情報等が記載される。
【００３６】
情報番号ＤＴ３には、各情報の発令、続報、解除のデータが記載される。都道府県ＤＴ４には、警報等が発せられた都道府県名が記載され、市町村ＤＴ５には、警報等が発せられた市町村名が記載される。レベルＤＴ６には、地震等のレベルが記載される。その他ＤＴ７には、各災害情報において必要なその他の情報が記載される。
【００３７】
このように、第１カテゴリＤＴ１および第２カテゴリＤＴ２に記載された報知情報としての災害種別を示すデータおよび災害種別の詳細を示すデータは、都道府県ＤＴ４および市町村ＤＴ５に記載された地域情報と紐付けられている。
【００３８】
マッチングサーバ１０は、情報取得部１１により以上のようなデータＤＴを取得すると、次に、データベースサーバ２０の配信先マスタ記憶部２６に記憶されたメール配信設定テーブルＴＢＬ１の読み取りと、建物マスタ記憶部２３に記憶された建物マスタ２３ａ（図５参照）の読み取りをデータベースサーバ２０に要求し（図２：Ｓ３）、データベースサーバ２０からメール配信設定テーブルのデータと、建物マスタを取得する（図２：Ｓ４）。
【００３９】
メール配信設定テーブルＴＢＬ１としては、例えば、図４に示すように、注警報配信設定テーブルＴＢＬ１−１、地震配信設定テーブルＴＢＬ１−２、ライフライン配信設定テーブルＴＢＬ１−３、および防災気象配信設定テーブルＴＢＬ１−４が用意されている。これらのテーブルには、報知情報としての警報等をメールで配信すべきか否かを示すメール配信情報が、警報等ごと、および地域ごとに示されている。したがって、マッチング処理部１２は、警報等の報知情報および地域情報と、前記各テーブルのメール配信情報とを照合することにより、警報等の報知情報を含むデータＤＴを配信する必要があるのか否かを判断することができる。
【００４０】
マッチング処理部１２が、データＤＴは、配信する必要のある情報ではないと判断した場合には、情報取得部１１は、再び５分間隔のポーリングを行う。しかし、マッチング処理部１２は、データＤＴを、配信する必要のある情報と判断した場合には、データベースサーバ２０の自然災害記録部２１に、データＤＴを、配信する必要のある情報として記録する（図２：Ｓ５）
【００４１】
建物マスタ２３ａには、例えば、図５に示すように、地域情報としての都道府県および建物住所、管理対象情報としての建物名称、管理形態、所属情報等の情報が含まれている。このように、管理対象情報としての建物名称は、地域情報および所属情報と紐付けられている。所属情報とは、管理対象としての建物の担当者の所属情報であり、例えば、担当者の部署の組織コードである。
【００４２】
マッチング処理部１２は、メール配信設定テーブルＴＢＬ１に記載されたメール配信情報に基づいて、警報等をメールで配信すべきと判断した場合には、警報等と紐付けられた地域情報と、建物マスタ２３ａとを照合することにより、前記地域情報と紐付けられた管理対象情報としての建物名称が存在するか否かを判定する。本実施形態では、このようにして、警報等が出されている地域に、管理対象となっている建物が存在するか否かを判定している。
【００４３】
マッチング処理部１２は、警報等が出されている地域に、管理対象となっている建物が存在すると判定した場合は、データベースサーバ２０の配信先配信部２６に記憶された配信先マスタ２６ａ（図８参照）の読み取りをデータベースサーバ２０に要求し（図２：Ｓ６）、データベースサーバ２０から配信先マスタ２６ａのデータを取得する（図２：Ｓ７）。
【００４４】
配信先マスタ２６ａは、どのような場合に、どのような担当者および閲覧者にメールの配信を行うかを設定するために用いられる。図８に示すように、配信先マスタ２６ａには、グループごとに、メールを配信する担当者および閲覧者が、メンバー・役職の欄に登録される。この例では、メンバー・役職の欄には、担当者および閲覧者の氏名が登録されるのではなく、組織名、役職等の所属情報が登録される。このように構成することにより、人事異動等により各役職につく人物に変動があった場合でも、災害、警報等による建物の状況を一括して把握すべき役職の閲覧者に、適切にメールを配信することができる。但し、メンバー・役職の欄に、担当者および閲覧者の氏名を登録することも可能である。
【００４５】
配信先マスタ２６ａの役割／建物の欄における役割とは、メールを受け取ったメンバーが、その後にとるべき役割を設定する項目であり、例えば、閲覧と報告という役割がある。配信先マスタ２６ａには、後述するメールのテンプレートが、この役割に応じて紐付けされている。建物とは、災害、警報等の影響を受け得る建物が存在した場合に、どのような建物の場合にメールを配信するかを設定する項目である。例えば、この建物の項目には、全物件、紐付けのある建物のみ等が登録される。役割／建物の欄に、全物件と登録されているグループについては、災害、警報等の影響を受け得る建物が存在した場合には、常にメールが配信される。しかし、役割／建物の欄に、紐付けのある建物のみと登録されているグループについては、災害、警報等の影響を受け得る建物が存在した時、その建物が、メンバー・役職の欄に登録された者に紐付けされている場合にのみ、メールが配信される。
【００４６】
また、配信先マスタ２６ａには、重大な警報のみ受信、震度６以上等の配信パターンがグループごとに紐付けられている。マッチング処理部１２は、データＤＴが、配信する必要のある情報と判断した場合には、データＤＴの内容と、配信先マスタ２６ａの配信パターンとを照合することにより、配信先のグループを選択する。そして、マッチング処理部１２は、選択したグループのメンバー・役職に登録されているメンバーの所属情報またはメンバーの氏名を読み出す。
【００４７】
以上のように、配信先情報記憶部としての配信先マスタ記憶部２６に記憶される配信先マスタ２６ａには、グループごとに、メールの配信パターンおよび所属情報と、担当者および閲覧者とが紐付けられている。
【００４８】
次に、マッチング処理部１２は、データベースサーバ２０の人事マスタ記憶部２４に記憶された人事マスタ２４ａ（図６参照）の読み取りをデータベースサーバ２０に要求し（図２：Ｓ８）、データベースサーバ２０から人事マスタ２４ａのデータを取得する（図２：Ｓ９）。
【００４９】
人事マスタ２４ａには、例えば、図６に示すように、社員番号、担当者および閲覧者の氏名、所属情報としての組織コード、組織名、役職コード、役職名、担当者および閲覧者のメールアドレス等の情報が含まれている。このように、担当者および閲覧者のメールアドレスは、担当者および閲覧者の所属情報としての組織コードと紐付けられている。
【００５０】
マッチング処理部１２は、上述のように配信先マスタ２６ａから読み出したメンバーの所属情報または氏名と、人事マスタ２４ａに登録された所属情報を含む人事情報とを照合し、メールの配信先のメールアドレスを取得する。
【００５１】
マッチングサーバ１０のメール配信部１３は、災害種別および警報等に応じて、また、配信先マスタ２６ａにおいてグループごとに紐付けられ、予め用意されたテンプレートを用いてメール本文を作成し、上述のように取得したメールアドレス宛にメールを配信する（図２：Ｓ１０、Ｓ１１）。
【００５２】
図９および図１０に、このようなテンプレートを用いて作成されたメールの一例を示す。図９に示すように、メールのタイトルには、災害種別と、警報等が発令されたことを示す内容が記載される。メールの本文には、警報等の種類、警報等が発令された地域、および、掲示板または画面のＵＲＬが記載される。ＵＲＬは、予め用意されていたＵＲＬを用いてもよいし、マッチング処理部１２がその都度作成してもよい。図９に示す例は、担当者用の画面のＵＲＬが記載されている。また、図１０は、警報が解除された場合のメールの一例を示している。
【００５３】
上述のようなメールを、担当者および閲覧者が、携帯端末またはパーソナルコンピュータ等の端末装置で受信し、メール本文に記載されたリンク先をクリックすると、管理サーバ３０に設けられた自然災害情報ポータルサイト３１の掲示板または画面のページに閲覧要求が送信される（図２：Ｓ１２、Ｓ１６）。
【００５４】
管理部としての管理サーバ３０は、担当者用の画面への閲覧要求があった場合には（図２：Ｓ１２）、マッチングサーバ１０に対して、当該画面の表示に必要なデータの問い合わせを行う（図２：Ｓ１３）。問い合わせを受けたマッチングサーバ１０は、マッチング処理部１２により、データベースサーバ２０の災害報告記録部２２から、画面の表示必要なデータを取得し、管理サーバ３０に返す（図２：Ｓ１４）。管理サーバ３０は、マッチングサーバ１０からのデータを用いて画面の表示処理を行う（図２：Ｓ１５）。その結果、担当者の携帯端末等の端末装置には、図１１に示すような担当者用の画面１００が表示される。
【００５５】
図１１は、担当者用の画面１００の一例を示す図である。図１１に示すように、担当者用の画面１００には、建物名欄１１０、ステータス欄１２０、更新日時欄１３０、詳細欄１４０、対応開始ボタン１５０、および被害無しボタン１６０が含まれる。
【００５６】
建物名欄１１０には、当該担当者が管理を担当している建物名が記載される。ステータス欄１２０には、建物名欄１１０に記載されたそれぞれの建物の状況が表示される。更新日時欄１３０には、ステータス欄１２０に表示される状況の最新の更新日時が表示される。詳細欄１４０には、表示アイコン１４１と、編集アイコン１４２とが表示される。表示アイコン１４１をクリックすることにより、図１２に示すような詳細閲覧画面２００が表示される。図１２は、詳細閲覧画面２００の一例を示す図である。
【００５７】
図１２に示すように、詳細閲覧画面２００には、警報名、発令日時、解除日時、建物名、対応ステータス、被害要因、人的被害の有無、インフラ被害の有無等が表示される。また、詳細閲覧画面２００には、該当の地域について警報等が複数発令された場合には、それぞれの警報の発令日時と解除日時が表示される。また、編集履歴についても表示される。
【００５８】
表示アイコン１４１をクリックすることにより、上述の詳細閲覧画面２００が編集不可の状態で表示され、編集アイコン１４２がクリックされることにより、詳細閲覧画面２００が編集可能な状態で表示される。したがって、担当者は、自らが確認した状況に基づいて、詳細閲覧画面２００に詳細な状況を書き込むことができる。
【００５９】
対応開始ボタン１５０をクリックすることにより、ステータス欄１２０には、ステータスとして「対応中」が表示される。また、確認の結果、被害が無かった場合には、被害無しボタン１６０をクリックすることにより、ステータス欄１２０には、ステータスとして「被害無」が表示される。
【００６０】
本実施形態によれば、担当者には、以上のようなメールが配信されるので、担当者は、災害等に関する警報等が発令されたことを、リアルタイムで知ることができる。また、メールに記載されたリンク先をクリックすることにより、担当者用の画面１００を閲覧することができるので、自分が確認すべき建物を、一括して知ることができる。さらに、それぞれの建物の状況を、画面１００を用いて報告することができる。
【００６１】
次に、管理サーバ３０は、担当者以外の閲覧者用の掲示板への閲覧要求があった場合には（図２：Ｓ１６）、マッチングサーバ１０に対して、当該掲示板の表示に必要なデータの問い合わせを行う（図２：Ｓ１７）。問い合わせを受けたマッチングサーバ１０は、マッチング処理部１２により、データベースサーバ２０の災害報告記録部２２から、掲示板の表示必要なデータを取得し、管理サーバ３０に返す（図２：Ｓ１８）。管理サーバ３０は、マッチングサーバ１０からのデータを用いて掲示板の表示処理を行う（図２：Ｓ１９）。その結果、担当者の携帯端末等の端末装置には、図１３に示すような閲覧者用の掲示板のトップ画面３００ａと検索ウィンドウ３１０が表示される。
【００６２】
図１３は、閲覧者用の掲示板の一例を示す図である。図１３に示すように、閲覧者用の掲示板のトップ画面３００ａには、検索ウィンドウ３１０が表示される。掲示板は、警報等ごとに作成されるため、閲覧者は、この検索ウィンドウ３１０において、閲覧する掲示板を検索する。検索ウィンドウ３１０には、警報等の発令年月日の指定欄、災害種別の指定欄、警報等の指定欄、都道府県指定欄、地域指定欄、部署指定欄等が備えられている。
【００６３】
閲覧者が、検索ウィンドウ３１０を用いて、所望の警報等を検索すると、図１４に示すように、閲覧者のパーソナルコンピュータ等の端末装置に掲示板３００が表示される。図１４は、閲覧者用の掲示板３００の一例を示す図である。図１４に示すように、閲覧者用の掲示板３００には、検索ウィンドウタブ３１０ａ、図表示欄３２０、およびリスト欄３３０が含まれる。
【００６４】
検索ウィンドウタブ３１０ａは、上述した検索ウィンドウ３１０を表示させるためのタブであり、検索ウィンドウタブ３１０ａをクリックすることにより、図１３の検索ウィンドウ３１０が表示される。
【００６５】
検索ウィンドウ３１０において、適宜、地域および警報等を検索することにより、掲示板３００には、メールを用いて配信された全ての警報等の情報、この警報等により影響を受け得る全ての建物のステータス情報が表示可能になっている。また、担当者が、実際に建物の確認を行い、建物のステータス情報を更新した時には、リスト欄３３０にその更新されたステータス情報が反映される。したがって、発令された警報等が広い地域にわたり、複数の担当者により建物のステータス情報がアップされる場合であっても、例えば、役員、本社、関係部署等において、一元的に災害情報と建物のステータス情報を管理することができる。
【００６６】
図表示欄３２０には、地図表示タブ３４０と、グラフ表示タブ３５０が備えられており、初期状態では、地図表示タブ３４０が選択された状態になっている。地図表示タブ３４０が選択されると、図表示欄３２０には、検索ウィンドウタブ３１０ａで指定した地域の地図が表示される。地図は、マッチングサーバ１０のマッチング処理部１２が、地図情報サービス会社６０の地図情報サービスサーバ６１から、該当する地域の地図情報を取得し、管理サーバ３０に対して、該当地域の地図情報として送信する。
【００６７】
図表示欄３２０に表示される地図には、リスト欄３３０に表示される、対応中、被害なし、対応完了、未対応等の色分けされたステータス情報に対応して、ステータス情報と同じ色のマークが該当する建物の場所に表示される。また、地図は、自由に拡大・縮小が可能であり、検索ウィンドウタブ３１０ａで指定した地域だけでなく、他の地域も含めて全体的にステータス情報を把握することも可能となっている。
【００６８】
図表示欄３２０において、グラフ表示タブ３５０が選択された状態においては、図１５のようなグラフが表示される。図１５は、図表示欄３２０に表示されるグラフの一例を示す図である。図１５に示すように、選択した地域において管理対象となっている建物のステータス情報が、グラフとして表示される。この例では、グラフは棒グラフとして表示されており、各棒グラフは、リスト欄３３０において色分けされたステータス情報に対応して、色分けして表示される。図１５に示す例では、グラフの横軸は、各建物を管理する拠点等の名前、縦軸は、件数となっている。したがって、このグラフを見ることにより、各支社等において管理される建物のステータス情報を一括して把握することができる。
【００６９】
自然災害情報ポータルサイト３１は、上述のように、担当者または閲覧者からの閲覧要求、あるいは、担当者用の画面１００におけるステータスの更新、または掲示板３００における表示項目の選択等が行われた場合に、必要な情報を取得して表示処理を行う。しかし、このような表示処理だけでなく、掲示板３００を閲覧する際に使用するブラウザのリフレッシュ機能等を用いて、所定時間ごとにマッチングサーバ１０に問い合わせを行い（図２：Ｓ２０）、マッチングサーバ１０からデータを取得して（図２：Ｓ２１）、表示処理を行う（図２：Ｓ２２）ようにしてもよい。このようにすれば、常に最新の情報を掲示板３００に表示させることができる。
【００７０】
以上のように、本実施形態の報知情報管理システム１によれば、自然災害の発生、警報等の発令、ライフライン障害の発生等の情報を、自然災害情報サービス会社５０からタイムリーに取得し、災害等の影響を受ける地域の管理対象としての建物のステータスを、担当者を通じて、一元的に集約して確認することができる。
【００７１】
また、閲覧者用の掲示板３００は、ＷＥＢベースで閲覧することができ、本システムの利用者間で必要な情報をリアルタイムで共有することが可能となる。
【００７２】
担当者用の画面１００および掲示板３００の閲覧は、専用機器ではなく、一般に用いられている携帯端末、あるいはパーソナルコンピュータ等を用いて行うことができる。したがって、建物ごとに専用機器を設置する必要がなく、導入コスト、および管理コストを低減することができる。
【００７３】
一つの警報等が解除される前に、新たな災害等が発生した場合には、警報等の発令ごとに、建物のステータス等を表示する掲示板が作成される。したがって、確認する必要のある情報を網羅的に集約することができる。しかも、掲示板３００においては、表示させる警報等ごとに、あるいは地域ごと等に選択して表示させることが可能なので、閲覧する際の利便性も高められている。
【００７４】
本実施形態の報知情報管理システム１においては、自然災害の発生、警報等の発令は、メールによって担当者および閲覧者に配信されるので、警報等の発令等を見逃すことなく、リアルタイムで知ることができる。
【００７５】
［変形例］
本発明は例示された実施形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において、種々の改良及び設計上の変更が可能であることは言うまでもない。
【００７６】
上述の実施形態では、報知情報の一例として、気象災害、地震災害、ライフライン情報、防災気象情報等に関する警報等を挙げ、管理対象を建物とした例について説明した。しかしながら、本発明はこのような態様に限定される訳ではない。例えば、報知情報として、電車、飛行機等の運行状況を採用し、管理対象を人の移動または物流等とする場合でも適用可能である。また、報知情報として、風邪等のウィルスの発生情報を採用し、管理対象を人または動物等とする場合でも適用可能である。さらに、報知情報として、パーソナルコンピュータのウィルスの発生情報を採用し、管理対象をパーソナルコンピュータ等とする場合でも適用可能である。また、報知情報を気象災害、地震災害、ライフライン情報、防災気象情報等に関する警報等とする場合でも、管理対象を介護が必要な人等にする場合でも、適用可能である。
【符号の説明】
【００７７】
１：  報知情報管理システム
１０：  マッチングサーバ
１１：  情報取得部
１２：  マッチング処理部
２０：  データベースサーバ
２１：  自然災害記録部
２２：  災害報告記録部
２３：  建物マスタ記憶部
２４：  人事マスタ記憶部
２５：  部署マスタ記憶部
２６：  配信先マスタ記憶部
３０：  管理サーバ
３１：  自然災害情報ポータルサイト
５０：  自然災害情報サービス会社
５１：  コンテンツシェアサービスサーバ
６０：  地図情報サービス会社
６１：  地図情報サービスサーバ
３００：  掲示板
【図１】
2019160175.tif 000003
【図２】
2019160175.tif 000004
【図３】
2019160175.tif 000005
【図４】
2019160175.tif 000006
【図５】
2019160175.tif 000007
【図６】
2019160175.tif 000008
【図７】
2019160175.tif 000009
【図８】
2019160175.tif 000010
【図９】
2019160175.tif 000011
【図１０】
2019160175.tif 000012
【図１１】
2019160175.tif 000013
【図１２】
2019160175.tif 000014
【図１３】
2019160175.tif 000015
【図１４】
2019160175.tif 000016
【図１５】
2019160175.tif 000017