(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B1)
(11)【特許番号】
(24)【登録日】2024-09-27
(45)【発行日】2024-10-07
(54)【発明の名称】安否確認システム
(51)【国際特許分類】
G06Q 50/10 20120101AFI20240930BHJP
G08B 27/00 20060101ALN20240930BHJP
【ＦＩ】
G06Q50/10
G08B27/00 Z
【請求項の数】
8
(21)【出願番号】P 2024088309
(22)【出願日】2024-05-30
【審査請求日】2024-05-31
【早期審査対象出願】
(73)【特許権者】
【識別番号】500287710
【氏名又は名称】セコムトラストシステムズ株式会社
(74)【代理人】
【識別番号】110000752
【氏名又は名称】弁理士法人朝日特許事務所
(72)【発明者】
【氏名】越尾 俊明
(72)【発明者】
【氏名】川上 貴志
【審査官】神田 泰貴
(56)【参考文献】
【文献】特開２０２４－０８３８８０（ＪＰ，Ａ）
【文献】特開２０２０－０９１５７０（ＪＰ，Ａ）
【文献】特開２０２０－０４７０３４（ＪＰ，Ａ）
【文献】特開２０２４－０９９２２５（ＪＰ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｑ ５０／００ － ５０／２０
Ｇ０６Ｑ ５０／２６ － ９９／００
Ｇ１６Ｚ ９９／００
Ｇ０６Ｑ １０／００ － １０／３０
Ｇ０６Ｑ ３０／００ － ３０／０８
Ｇ０８Ｂ ２３／００ － ３１／００
(57)【特許請求の範囲】
【請求項1】
対象地震に関する地震情報を取得する取得部と、前記取得された地震情報に関する前記対象地震が、既に安否確認通知が送信された先行地震と一連の地震ではない場合には、前記対象地震に応じた安否確認の対象の利用者端末に安否確認通知を送信し、前記対象地震が前記先行地震と一連の地震である場合には、前記先行地震に応じて既に前記安否確認通知が送信された利用者端末に前記安否確認通知を送信しない送信部と
を備える安否確認システム。
【請求項2】
前記取得された地震情報を用いて、前記対象地震が前記先行地震と一連の地震であるか否かを判定条件に従って判定する判定部をさらに備え、前記判定条件は、前記先行地震の被災地が前記対象地震の被災地の隣接地域内であるという条件を含む
請求項１に記載の安否確認システム。
【請求項3】
前記対象地震が前記先行地震と一連の地震ではない場合には、前記対象地震に応じた前記安否確認の対象への前記安否確認通知の送信に関する操作に用いられる操作画像を含む画面を、前記操作画像を強調する表示形式で表示する表示部をさらに備え、前記送信部は、前記操作画像を用いて前記操作が行われた場合には、前記対象地震に応じた前記安否確認の対象の前記利用者端末に前記安否確認通知を送信する
請求項１に記載の安否確認システム。
【請求項4】
前記送信部は、前記対象地震が前記先行地震と一連の地震であり、前記対象地震の震度が前記先行地震の震度から上昇した場合、または前記対象地震の被災地が前記先行地震の被災地から拡大した場合には、前記先行地震と前記対象地震との前記安否確認の対象の差分に前記安否確認通知を送信する請求項１に記載の安否確認システム。
【請求項5】
前記対象地震が前記先行地震と一連の地震であり、前記対象地震の震度が前記先行地震の震度から上昇した場合、または前記対象地震の被災地が前記先行地震の被災地から拡大した場合には、前記差分への前記安否確認通知の送信に関する操作に用いられる操作画像を含む画面を、前記操作画像を強調する表示形式で表示する表示部をさらに備え、前記送信部は、前記操作画像を用いて前記操作が行われた場合には、前記差分に前記安否確認通知を送信する
請求項４に記載の安否確認システム。
【請求項6】
前記送信部は、前記対象地震が余震の判定条件を満たす場合には、前記対象地震に応じた前記安否確認の対象の管理者端末に余震通知を送信する請求項１に記載の安否確認システム。
【請求項7】
前記対象地震が前記余震の判定条件を満たす場合には、前記余震通知の送信に関する操作に用いられる操作画像を含む画面を、前記操作画像を強調する表示形式で表示する表示部をさらに備え、前記送信部は、前記操作画像を用いて前記操作が行われた場合には、前記対象地震に応じた前記安否確認の対象の前記管理者端末に前記余震通知を送信する
請求項６に記載の安否確認システム。
【請求項8】
前記送信部は、前記取得された地震情報が前記先行地震に関する続報である場合には、前記先行地震に応じて既に前記安否確認通知が送信された前記利用者端末に前記安否確認通知を送信しない請求項１に記載の安否確認システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、災害が発生した際に、会社等の顧客組織に属する人物の現状態を確認する安否確認システムに関する。特に、顧客組織と協働しつつ、事業者が顧客組織を代行して安否確認を行う安否確認システムに関する。
【背景技術】
【0002】
地震等の災害の発生時に、センター装置から安否確認通知を顧客組織の利用者に送信し、安否を確認する安否確認システムが知られている（例えば特許文献１）。
【先行技術文献】
【特許文献】
【0003】
【文献】特開２０２１－１４４２９３号公報
【発明の概要】
【発明が解決しようとする課題】
【0004】
大きな地震後の地震活動においては、同一震源地や隣接地域にて断続的に複数回の地震が発生する場合がある。このような一連の地震が発生する度に安否確認が行われると、利用者は何度も安否確認の応答を行わなくてはならず、煩わしい。
【0005】
本発明は、先行地震と一連の地震が発生した場合にも、安否確認が繰り返し行われることによる利用者の煩わしさを軽減することを目的とする。
【課題を解決するための手段】
【0006】
本発明の一態様は、対象地震に関する地震情報を取得する取得部と、前記取得された地震情報に関する前記対象地震が、既に安否確認通知が送信された先行地震と一連の地震ではない場合には、前記対象地震に応じた安否確認の対象の利用者端末に安否確認通知を送信し、前記対象地震が前記先行地震と一連の地震である場合には、前記先行地震に応じて既に前記安否確認通知が送信された利用者端末に前記安否確認通知を送信しない送信部とを備える安否確認システムを提供する。
【0007】
前記安否確認システムは、前記取得された地震情報を用いて、前記対象地震が前記先行地震と一連の地震であるか否かを判定条件に従って判定する判定部をさらに備え、前記判定条件は、前記先行地震の被災地が前記対象地震の被災地の隣接地域内であるという条件を含んでもよい。
【0008】
前記安否確認システムは、前記対象地震が前記先行地震と一連の地震ではない場合には、前記対象地震に応じた前記安否確認の対象への前記安否確認通知の送信に関する操作に用いられる操作画像を含む画面を、前記操作画像を強調する表示形式で表示する表示部をさらに備え、前記送信部は、前記操作画像を用いて前記操作が行われた場合には、前記対象地震に応じた前記安否確認の対象の前記利用者端末に前記安否確認通知を送信してもよい。
【0009】
前記送信部は、前記対象地震が前記先行地震と一連の地震であり、前記対象地震の震度が前記先行地震の震度から上昇した場合、または前記対象地震の被災地が前記先行地震の被災地から拡大した場合には、前記先行地震と前記対象地震との前記安否確認の対象の差分に前記安否確認通知を送信してもよい。
【0010】
前記安否確認システムは、前記対象地震が前記先行地震と一連の地震であり、前記対象地震の震度が前記先行地震の震度から上昇した場合、または前記対象地震の被災地が前記先行地震の被災地から拡大した場合には、前記差分への前記安否確認通知の送信に関する操作に用いられる操作画像を含む画面を、前記操作画像を強調する表示形式で表示する表示部をさらに備え、前記送信部は、前記操作画像を用いて前記操作が行われた場合には、前記差分に前記安否確認通知を送信してもよい。
【0011】
前記送信部は、前記対象地震が余震の判定条件を満たす場合には、前記対象地震に応じた前記安否確認の対象の管理者端末に余震通知を送信してもよい。
【0012】
前記安否確認システムは、前記対象地震が前記余震の判定条件を満たす場合には、前記余震通知の送信に関する操作に用いられる操作画像を含む画面を、前記操作画像を強調する表示形式で表示する表示部をさらに備え、前記送信部は、前記操作画像を用いて前記操作が行われた場合には、前記対象地震に応じた前記安否確認の対象の前記管理者端末に前記余震通知を送信してもよい。
【0013】
前記送信部は、前記取得された地震情報が前記先行地震に関する続報である場合には、前記先行地震に応じて既に前記安否確認通知が送信された前記利用者端末に前記安否確認通知を送信しなくてもよい。
【発明の効果】
【0014】
本発明によれば、先行地震と一連の地震が発生した場合にも、安否確認が繰り返し行われることによる利用者の煩わしさを軽減することができる。
【図面の簡単な説明】
【0015】
【図1】実施形態に係る安否確認システムの構成例を示す図。
【図2】センター装置の構成例を示す図。
【図3】気象庁から受信する地震情報を例示する図。
【図4】災害管理テーブルを例示する図。
【図5】災害情報テーブルを例示する図。
【図6】隣接地域テーブルを例示する図。
【図7】条件管理テーブルを例示する図。
【図8】顧客情報テーブルを例示する図。
【図9】通知種類判定の詳細を例示する図。
【図10】通知種類判定の一例を説明する図。
【図11】センター装置の動作例を示すフローチャート。
【図12】オペレーター画面（災害通知）の表示例を示す図。
【図13】安否確認通知を例示する図。
【図14】災害通知を例示する図。
【図15】代行送信通知を例示する図。
【図16】オペレーター画面（震度変更）の表示例を示す図。
【図17】震度変更通知を例示する図。
【図18】オペレーター画面（余震通知）の表示例を示す図。
【図19】余震通知を例示する図。
【図20】安否状況の集計画面および一覧画面を例示する図。
【発明を実施するための形態】
【0016】
１．構成
図１は、実施形態に係る安否確認システム１の構成例を示す図である。安否確認システム１は、災害の発生時に利用者に安否確認通知を送信し、利用者の安否を確認するためのシステムである。
図１は、実施形態に係る安否確認システム１の構成例を示す図である。安否確認システム１は、災害の発生時に利用者に安否確認通知を送信し、利用者の安否を確認するためのシステムである。
【0017】
安否確認システム１は、サーバー装置１０と、複数の管理者端末２０と、複数の利用者端末３０と、センター装置４０とを備える。サーバー装置１０とセンター装置４０とは、通信回線５０を介して接続されている。通信回線５０は、例えば専用回線である。センター装置４０と各管理者端末２０と各利用者端末３０とは、通信回線６０を介して接続されている。通信回線６０には、例えばインターネットと移動体通信網とが含まれる。なお、図１では管理者端末２０が複数示されているが、管理者端末２０の数は複数に限定されず、１台でもよい。
【0018】
サーバー装置１０は、気象庁により運営、管理される。サーバー装置１０は、災害が発生すると、気象庁により発表された災害情報に応じた電文をセンター装置４０に配信する。この実施形態では、災害が地震であるものとする。地震の場合、電文には地震情報が含まれる。地震情報は、地震の発生から約５分後に発表される確定報である。
【0019】
管理者端末２０は、顧客の管理者がセンター装置４０から提供される安否確認に関する各種情報を閲覧するのに用いられる。顧客は、安否確認サービスを契約している企業などの組織である。管理者は、例えば企業などの組織において災害の発生時に従業員の管理を担当する人である。管理者端末２０は、例えば電子メール機能を有し、センター装置４０から安否確認に関する各種通知を電子メールで受信する。また、管理者端末２０は、例えばウェブブラウザ機能を有し、センター装置４０から提供される安否確認に関するウェブ画面をウェブブラウザで表示する。管理者端末２０には、例えばスマートフォン、タブレット端末、ノートパソコンが含まれる。管理者端末２０は表示部２１を備える。表示部２１には、例えば液晶ディスプレイが含まれる。
【0020】
利用者端末３０は、顧客の利用者がセンター装置４０から送信された安否確認通知を閲覧し、安否情報を回答するのに用いられる。利用者は、例えば企業などの組織の従業員である。利用者端末３０は、例えば電子メール機能を有し、センター装置４０から安否確認通知を電子メールで受信する。また、利用者端末３０は、例えばウェブブラウザ機能を有し、ウェブブラウザを通じてセンター装置４０に安否情報を入力する。利用者端末３０には、例えばスマートフォン、タブレット端末、ノートパソコンが含まれる。利用者端末３０は表示部３１を備える。表示部３１には、例えば液晶ディスプレイが含まれる。
【0021】
図２は、センター装置４０の構成例を示す図である。センター装置４０は、安否確認サービスを提供する代行送信事業者により運営、管理される。センター装置４０は、サーバー装置１０から配信された地震情報に基づいて、顧客に安否確認に関する各種通知を提供する。センター装置４０は、例えば電子メール機能を有し、安否確認に関する各種通知を電子メールで管理者端末２０および利用者端末３０に送信する。また、センター装置４０は、例えばウェブサーバー機能を有し、安否確認に関する各種ウェブ画面を管理者端末２０および利用者端末３０に提供する。センター装置４０は、例えばクラウドサーバである。ただし、センター装置４０はクラウドサーバに限定されず、オンプレミスサーバでもよい。なお、センター装置４０がオンプレミスサーバである場合、管理者が一人（管理者端末２０が１台）であることも考えられる。センター装置４０は、制御部４１と、第１通信部４２と、第２通信部４３と、記憶部４４と、入力部４５と、表示部４６とを備える。制御部４１は、第１通信部４２、第２通信部４３、記憶部４４、入力部４５、および表示部４６とバスを介して接続されている。
【0022】
制御部４１は、センター装置４０の各部を制御して安否確認サービスを提供するための処理を行う。制御部４１には、例えばＣＰＵ（Central Processing Unit）などのプロセッサと、ＲＯＭ（Read Only Memory）およびＲＡＭ（Random Access Memory）などのメモリとが含まれる。メモリには、センター装置４０の機能を実現するためのプログラムが記憶される。第１通信部４２は、通信回線５０に接続される通信インターフェースである。第１通信部４２は、通信回線５０を介してサーバー装置１０とデータ通信を行う。第１通信部４２には、例えばネットワークアダプタが含まれる。第２通信部４３は、通信回線６０に接続される通信インターフェースである。第２通信部４３は、通信回線６０を介して管理者端末２０および利用者端末３０とデータ通信を行う。第２通信部４３には、例えばネットワークアダプタが含まれる。記憶部４４は、災害管理テーブル４４１、災害情報テーブル４４２、条件管理テーブル４４３、顧客情報テーブル４４４、隣接地域テーブル４４５などの、制御部４１により用いられる各種情報を記憶する。記憶部４４には、例えばハードディスク、ＳＳＤ（Solid State Drive）が含まれる。入力部４５は、センター装置４０への情報の入力に用いられる。入力部４５には、例えばマウス、キーボードが含まれる。表示部４６は、各種情報を表示する。表示部４６には、例えば液晶ディスプレイが含まれる。表示部４６は、代行送信事業者のオペレーターが操作するオペレーター端末の表示部でもよい。
【0023】
制御部４１は、取得部４１１と、対象判定部４１２と、特定部４１３と、送信部４１４と、表示制御部４１５と、記憶部更新部４１６として機能する。これらの機能は、メモリに記憶されたプログラムと、このプログラムを実行するプロセッサとの協働により、プロセッサが演算を行いまたは他のハードウェア要素の動作を制御することにより実現される。
【0024】
取得部４１１は、地震が発生すると、この地震に関する地震情報をサーバー装置１０から受信して取得する。図３は、気象庁から受信する地震情報を例示する図である。地震情報には、情報名称と、識別情報と、情報番号と、スキーマの運用種別情報と、見出し文と、防災気象情報要素名と、対象地域・地点名称と、地震発生時刻と、震央地名とが含まれる。情報名称は電文のタイトルである。識別情報は地震を一意に識別するイベントＩＤである。１つの地震につき１つのイベントＩＤが付与される。情報番号は同一の地震に関する地震情報以降の電文の配信順序を示すシリアルナンバーである。シリアルナンバーは同一の地震に関する最初の地震情報以降の電文に連番で付与される。スキーマの運用種別情報は電文が地震情報か否かを示すものである。見出し文は電文の概要を示す情報である。防災気象情報要素名は震度を表す。対象地域・地点名称は災害が発生した地域・地点（被災地）を表す。１つの震度に対して複数地域・地点が列挙されることがある。地震発生時刻は地震が発生した時刻である。震央地名は発生した地震の震央地を表す。
【0025】
対象判定部４１２は、地震情報に震度５弱以上の防災気象情報要素名が含まれるかどうかにより処理対象とするかを判定する。震度５弱以上の防災気象情報要素名が含まれない場合、対象判定部４１２は地震情報を処理対象外とする。震度５弱以上の防災気象情報要素名が含まれる場合、対象判定部４１２は地震情報を処理対象として地震情報の内容を記憶部更新部４１６を通じて災害管理テーブル４４１に登録する。なお、この実施形態では震度５弱以上を安否確認の対象としているため対象判定部４１２は地震情報により示される震度が５弱以上であるかどうかを判定しているが、例えば震度４以上を安否確認の対象とするシステムの場合、対象判定部４１２は地震情報により示される震度が４以上であるかどうかを判定する。
【0026】
図４は、災害管理テーブル４４１を例示する図である。災害管理テーブル４４１は取得部４１１が取得した地震情報の内容を格納する。災害管理テーブル４４１には、電文管理番号と、イベントＩＤと、シリアルナンバーと、電文種別と、震度と、震央地名と、発生日時と、処理ステータスと、災害名と、発生場所と、災害詳細と、エリアと、震度と、隣接フラグとが格納される。
【0027】
電文管理番号は、電文を一意に識別する情報である。電文管理番号は、受信された電文を災害管理テーブル４４１へ登録する際にセンター装置４０で採番される。イベントＩＤは、１つの災害（地震であれば揺れ）を表す。イベントＩＤには、地震情報から取得された識別情報がセットされる。シリアルナンバーは、１つのイベントＩＤに対する地震情報の連番である。シリアルナンバーには、地震情報から取得された情報番号がセットされる。電文種別は、様々ある災害情報の電文のうち何の電文であるかを表す。電文種別には、地震情報から取得されたスキーマの運用種別情報がセットされる。震度はその地震情報のなかでの最大震度である。震度には、地震情報から取得された防災気象情報要素名のうち最大震度のものがセットされる。震央地名は地震が発生した場所を表す。震央地名には、地震情報から取得された震央地名がセットされる。発生日時は地震が発生した日時である。発生日時には、地震情報に含まれる地震発生時刻がセットされる。なお、発生日時の日付と時刻の表記は、地震情報で用いられる日付と時刻の表記から変更されてもよい。
【0028】
処理ステータスは当該レコードの処理状況を表す。処理ステータスには、まず「未処理」が登録され、後続処理にて「処理済み」または「処理対象外」に更新される。災害名は災害を識別する名称であり、被災地の地域と上述した震度により表される。本実施形態では、被災地の地域は、地震情報から取得された防災気象情報要素名と対象地域・地点名称を基に震度５弱以上の都道府県が属する地域により表される。発生場所は災害の発生した地域を表す。発生場所は地震情報から取得された防災気象情報要素名と対象地域・地点名称を基に上述した被災地の地域と震度により表される。災害詳細は災害の詳細を記載したものである。災害詳細は、地震情報に含まれるスキーマの運用種別情報、情報名称、見出し文等を組み合わせて作成される。エリアは災害が発生した地域（被災地）を表す。エリアには、地震情報から取得された対象地域・地点名称を安否確認システム１で管理する単位に変換した被災地名がセットされる。またエリアには被災地名に加えて被災地の隣接地域名もセットされる。震度は当該エリアにおける地震の揺れの強弱の程度である。震度には、地震情報から取得された防災気象情報要素名がセットされる。隣接フラグは、エリアが隣接地域名であるか否かを示す情報である。エリアのうち隣接地域名の隣接フラグには「１」がセットされ、被災地名の隣接フラグには「０」がセットされる。
【0029】
特定部４１３は、対象判定部４１２により処理対象として判定された地震情報が、顧客への通知の対象であるか否かを判定する。また特定部４１３は、顧客への通知の対象である地震情報について対象となる地震が新規の災害であるか、既に安否確認通知が送信された先行地震と一連の地震であるかを判定する。なお、以下の説明では、取得部４１１により取得された地震情報の対象となる地震を「対象地震」ともいう。特定部４１３は、本発明に係る判定部の一例である。ここでいう「一連の地震」とは、先行地震と合わせて安否確認が行われるべき地震をいう。より具体的には、一連の地震は、先行地震より後に先行地震の震源地の近くで発生した地震であり、先行地震より規模の小さい地震であってもよい。例えば先行地震が本震である場合、一連の地震はその余震である。このように、一連の地震には余震が含まれる。ただし、先行地震より後に先行地震の震源地の近くで発生した地震であっても、先行地震とは別に安否確認が行われるべき地震については、先行地震と一連の地震と判定されない。
【0030】
一連の地震の判定条件は予め定められている。この実施形態では、一連の地震の判定条件には、先行地震の発生日時から対象地震の発生日時までの時間、先行地震の被災地と対象地震の被災地との関係が含まれる。例えば先行地震の発生日時から対象地震の発生日時までの時間が６時間などの所定時間以内であり、先行地震の被災地が対象地震の被災地の隣接地域内である場合、特定部４１３は、対象地震を先行地震と一連の地震であると判定する。一方、一連の地震の判定条件の少なくとも一部を満たさない場合、特定部４１３は、対象地震を先行地震と一連の地震ではない新規の災害と判定する。なお、一連の地震の判定条件にはさらに対象地震の震度が先行地震の震度以下であるという条件が含まれてもよい。
【0031】
ここでいう「隣接地域」とは、先行地震と一連の地震が発生した場合に被災地となり得る地域をいう。より具体的には、隣接地域は、近隣関係にある地域である。例えば隣接地域は、地理的に隣り合う地域である。ただし、隣接地域は、必ずしも被災地に接している必要はなく、例えば海や他の地域を介して被災地と隣り合ってもよい。また、地理的に隣り合う地域でも、先行地震と一連の地震が発生した場合に被災地となる可能性が低い地域については、隣接地域に含まれなくてもよい。特定部４１３は、記憶部４４に記憶された隣接地域テーブル４４５を用いて、先行地震の被災地が対象地震の被災地の隣接地域内であるか否かを判定する。
【0032】
図６は、隣接地域テーブル４４５を例示する図である。隣接地域テーブル４４５には、被災地名と、隣接地域名とが関連付けて格納される。被災地名は、基準となる被災地であり、例えば地震災害が発生した地名である。なお、被災地の単位は、例えば都道府県であるが、これに限定されず、区市町村でもよいし、都道府県または区市町村を北部、南部、東部、西部、諸島部のようにさらに分割したものでもよい。隣接地域名は、被災地名に隣接するとみなす地名である。隣接地域は、例えば代行送信事業者により予め定められる。地震災害において、対象地震の被災地名と隣接地域名に、対応中の先行地震の被災地名が１つでも含まれる場合には、先行地震と対象地震とは同一の災害と判定される。
【0033】
図６に示される例では、被災地名「東京都」には、隣接地域名「神奈川県」、「山梨県」、「埼玉県」、および「千葉県」が関連付けられている。これは、「東京都」の隣接地域が「神奈川県」、「山梨県」、「埼玉県」、および「千葉県」であることを示す。なお、図６において被災地名「千葉県」に関連付けられた隣接地域名のうちハッチングにより示された「神奈川県」のように、地理的に千葉県と接していない地域が隣接地域に含まれてもよい。隣接地域テーブル４４５は、例えば代行送信事業者により予め作成され、記憶部４４に記憶される。
【0034】
余震の判定条件には、一連の地震の判定条件に加えて、所定震度以上の新たな被災地の有無、先行地震と重複する被災地の震度が含まれる。例えば一連の地震の判定条件を満たし、さらに震度が５弱以上となる被災地が先行地震の被災地から増加しておらず、先行地震の被災地と重複する対象地震の被災地の震度が先行地震の震度から上昇していない場合、特定部４１３は、対象地震を先行地震の余震であると判定する。一方、余震の判定条件の少なくとも一部を満たさない場合、特定部４１３は、対象地震を先行地震の余震ではないと判定する。余震の判定条件は予め定められている。
【0035】
表示制御部４１５は、センター装置４０の表示部４６、管理者端末２０の表示部２１、または利用者端末３０の表示部３１に各種の画面を表示させる。例えば表示制御部４１５は、取得部４１１により取得された地震情報に応じてオペレーター画面を表示させる。オペレーター画面は、オペレーターによる地震情報の確認および安否確認に関する各種操作に用いられる。
【0036】
オペレーター画面には、安否確認に関する操作に用いられる複数の操作画像が含まれる。表示制御部４１５は、対象地震が先行地震と一連の地震であるか否かの判定結果に応じてオペレーターの推奨作業に用いられる操作画像を強調する形式で表示させる。ここでいう「強調する表示形式」とは、オペレーターが着目するような表示形式をいう。より具体的には、強調する表示形式は、操作画像を他の操作画像より目立つように表示する表示形式である。例えば強調する表示形式は、操作画像の背景色を他の操作画像の背景色とは異なる色に変更して表示することである。ただし、強調する表示形式は、操作画像の背景色の変更に限定されず、操作画像の背景領域の枠の色を他の操作画像の背景領域の枠とは異なる色に変更して表示してもよいし、操作画像自体の色、形、大きさを他の操作画像とは異なるものに変更して表示してもよいし、操作画像を点滅させて表示してもよいし、操作画像に付加画像を付加して表示してもよい。また、強調する表示形式は、他の操作画像を目立たないように表示することにより、対象の操作画像を相対的に目立たせてもよい。なお、以下の説明では、強調する表示形式で表示することを「強調表示」ともいう。
【0037】
送信部４１４は、特定部４１３により対象地震が先行地震と一連の地震ではないと判定された場合には、オペレーター画面におけるオペレーターの操作を条件として、通知対象として特定された顧客の利用者端末３０に安否確認通知を送信する。取得部４１１により取得された地震情報は、まず対象判定部４１２、特定部４１３で顧客への通知の対象かどうか判定される。顧客への通知の対象と判定された災害（地震）について、送信部４１４において送信条件を満たす顧客の利用者端末３０に安否確認通知を、管理者端末２０に代行送信通知および災害通知をそれぞれ送信する。この送信条件は条件管理テーブル４４３に格納されている。安否確認通知は、利用者の安否を確認するための情報である。代行送信通知は、代行送信事業者により安否確認通知が代行送信されたことを管理者に知らせる情報である。災害通知は、災害が発生した（地震情報を受信した）ことを管理者に知らせる情報である。安否確認通知、災害通知、および代行送信通知は、例えば電子メールを利用して送信される。ただし、安否確認通知、災害通知、および代行送信通知は、その他の手段を利用して送信されてもよい。
【0038】
一方、送信部４１４は、特定部４１３により対象地震が先行地震と一連の地震であると判定された場合には、先行地震に応じて既に安否確認通知が送信された利用者端末３０には安否確認通知を送信しない。ただし、送信部４１４は、対象地震の震度が先行地震の震度から上昇した場合、または対象地震の被災地が先行地震の被災地から拡大した場合には、オペレーター画面におけるオペレーターの操作を条件として、先行地震に応じた安否確認の対象と対象地震に応じた安否確認の対象との差分に安否確認通知を送信する。対象地震の震度が先行地震の震度から上昇した場合、または対象地震の被災地が先行地震の被災地から拡大した場合、対象地震に応じた安否確認の対象は、先行地震に応じた安否確認の対象を包含する。したがって、先行地震に応じた安否確認の対象に該当しないが、対象地震に応じた安否確認の対象に該当する利用者端末３０が安否確認の対象の差分となる。この差分は、対象地震に応じた安否確認の対象の利用者端末３０から先行地震の地震情報に応じて既に安否確認通知が送信された利用者端末３０を除くことにより得られる。
【0039】
また、送信部４１４は、特定部４１３により対象地震が先行地震の余震であると判定された場合には、オペレーター画面におけるオペレーターの操作を条件として、通知対象として特定された顧客の管理者端末２０に余震通知を送信する。余震通知は、余震が発生したことを管理者に知らせる情報である。
【0040】
図５は、災害情報テーブル４４２を例示する図である。安否確認通知の送信は災害情報テーブル４４２を基にして行われる。災害情報テーブル４４２には、顧客識別コードと、災害コードと、災害名と、発生年月日と、発生時刻と、発生場所と、詳細とが格納される。顧客識別コードは顧客を一意に識別する情報である。災害コードは災害を一意に識別する情報である。災害コードは、レコードを災害情報テーブル４４２へ登録する際にセンター装置４０で採番される。災害名、発生年月日、発生時刻、発生場所、詳細には、画面から入力された値がセットされる。災害情報テーブル４４２に登録されたレコードは、地震の発生日時から６時間などの所定時間が経過すると削除される。すなわち、災害情報テーブル４４２には、所定時間以内に発生した地震に関する地震情報しか格納されない。
【0041】
図７は、条件管理テーブル４４３を例示する図である。条件管理テーブル４４３は、顧客毎に、安否確認通知を送信する条件（被災地名、震度）を保持するテーブルである。条件管理テーブル４４３は、特定部４１３にて地震情報（災害）が顧客への通知の対象と判定された後、送信部４１４において通知の対象の顧客を特定するために使用される。条件管理テーブル４４３には、顧客識別コードと、安否確認通知の送信条件とが関連付けて格納される。顧客識別コードは、顧客を一意に識別する情報である。送信条件は、予め顧客により設定された安否確認通知を送信する条件である。送信条件には、安否確認システム１で管理する単位の被災地名と、震度とが含まれる。なお、この実施形態では、安否確認システム１が震度５以上を管理対象としているため、送信条件には４以下の震度は設定できないようになっているが、震度４以下の震度を設定できるようにしてもよい。図７に示される例では、顧客識別コード「顧客Ａ」と、被災地名「東京都」および震度「５弱」と、被災地名「千葉県」および震度「５弱」とが関連付けられている。これは、東京都および千葉県のうち少なくともいずれかで震度５弱以上の地震が発生したときに顧客Ａに安否確認通知が送信されることを示す。条件管理テーブル４４３は、予め作成され記憶部４４に記憶される。
【0042】
図８は、顧客情報テーブル４４４を例示する図である。顧客情報テーブル４４４は、顧客に紐づく管理者および利用者を管理するテーブルである。顧客ごとに管理者、利用者はそれぞれ１名のケースもあれば複数名のケースもある。顧客情報テーブル４４４には、顧客識別コードと、ユーザーコードの組み合わせに、氏名と、エリアと、端末識別と、通信アドレスとが関連付けて格納される。顧客識別コードは、顧客を一意に識別するコードである。ユーザーコードは、ユーザーを一意に識別するコードである。氏名は、ユーザーコードに紐づく管理者または利用者の氏名である。エリアは、管理者または利用者が所在するエリアであり、例えば勤務地または居住地である。エリアは、安否確認通知の送信条件として用いられる。管理者または利用者について登録されたエリアと災害が発生したエリアとが一致する場合に、通知対象となる。端末識別は、管理者端末２０か利用者端末３０かを識別する情報である。一の顧客に１または複数の管理者端末２０が登録されている。複数の管理者端末２０が登録されている場合、これらの管理者端末２０に対して同等の処理が行われてもよいし、被災地毎に分けて管理者端末２０が登録されてもよい。通信アドレスは、ユーザーコードに紐づく管理者端末２０または利用者端末３０の通信アドレスであり、ここではメールアドレスが登録される。顧客情報テーブル４４４は、予め作成され記憶部４４に記憶される。
【0043】
この実施形態では、条件管理テーブル４４３で顧客としては安否確認通知の送信条件を満たしても顧客情報テーブル４４４において利用者として安否確認通知の送信条件を満たさなければ安否確認通知は送信されない。また、後述する震度変更処理において被災地が拡大しまたは震度が上昇し顧客としても利用者としても安否確認通知の送信条件を満たしていれば安否確認の対象の差分に安否確認通知が送信される。
【0044】
記憶部更新部４１６は、記憶部４４に記憶された各テーブルにレコードを登録・更新する処理を担う。
【0045】
２．動作
図１１は、センター装置４０の動作例を示すフローチャートである。この動作は、地震が発生し、サーバー装置１０から地震情報が配信された場合に行われる。
図１１は、センター装置４０の動作例を示すフローチャートである。この動作は、地震が発生し、サーバー装置１０から地震情報が配信された場合に行われる。
【0046】
ステップＳ３１において、取得部４１１はサーバー装置１０より地震情報を受信する。地震情報を受信していなければステップＳ３１の判定がＮＯとなり、処理が終了する。一方、図３に示される東京都２３区、東京都多摩東部で震度５強の地震情報が受信されるとステップＳ３１の判定がＹＥＳとなり後続のステップＳ３２へ進む。
【0047】
ステップＳ３２において、地震情報が受信された場合、対象判定部４１２はこの地震情報の内容より最大震度が５弱以上であるかを判定する。最大震度が５弱以上であるか否かの判定は、地震情報に含まれる防災気象情報要素名により行われる。最大震度が５弱以上でなければステップＳ３２の判定がＮＯとなり処理が終了する。一方、図３に示される地震情報が受信された場合には最大震度が震度５強であるため、ステップＳ３２の判定がＹＥＳとなり後続のステップＳ３３へ進む。
【0048】
ステップＳ３３において、最大震度が５弱以上であれば受信された地震情報の内容が記憶部更新部４１６により災害管理テーブル４４１に登録される。図３に示される地震情報が受信された場合にはこの地震情報の内容が図４に示される災害管理テーブル４４１の上から４行目のレコードに登録される。ただし、登録された時点では、処理ステータスは「未処理」となる。
【0049】
ステップＳ３４において、特定部４１３は受信された地震情報が顧客への通知の対象外か否かを判定する。例えば１つの地震について識別情報（イベントＩＤ）が同一の複数の地震情報が受信される場合を想定する。この場合において、システムの不具合等により、後に配信された情報番号（シリアルナンバー）が２の地震情報が先に受信され処理された後に、先に配信された情報番号（シリアルナンバー）が１の地震情報が受信される場合が考えられる。情報番号が２の地震情報は情報番号が１の地震情報を訂正した内容となっているため、情報番号が２の地震情報を処理後に訂正前の情報番号が１の地震情報を処理する必要は無い。したがって、情報番号が２の地震情報の処理後に情報番号が１の地震情報が受信された場合、この情報番号が１の地震情報についてはステップＳ３４の判定がＹＥＳとなり、ステップＳ４９へ進み記憶部更新部４１６を通じて災害管理テーブル４４１に新たに登録されたレコードの処理ステータスが「処理対象外」に更新され処理が終了する。一方、この場合において情報番号が２の地震情報についてはステップＳ３４の判定がＮＯとなり後続のステップＳ３５へ進む。
【0050】
ステップＳ３５において、特定部４１３は受信された地震情報の通知種類を判定する。この判定結果によりオペレーター画面に表示する内容が変化する。「災害通知」と判定された場合にはステップＳ３６へ進みオペレーター画面（災害通知）が表示される。「震度変更通知」と判定された場合にはステップＳ４０へ進みオペレーター画面（震度変更）が表示される。「余震通知」と判定された場合にはステップＳ４４へ進みオペレーター画面（余震通知）が表示される。
【0051】
図９は、ステップＳ３５の通知種類判定の詳細を例示する図である。図９に示される処理は、図１１に示されるステップＳ３４から処理が遷移して開始される。ステップＳ１１において、特定部４１３は災害情報テーブル４４２を基に対応中の先行地震が存在するかチェックして判定する。ここでいう「対応中の先行地震」とは、既に安否確認通知が送信され、かつ発生日時からの経過時間が所定時間以内である過去の地震をいう。例えば災害情報テーブル４４２に登録されているレコードが存在しない場合には対応中の先行地震が存在しないため、ステップＳ１１の判定がＮＯになりステップＳ１４へ進む。この場合、一連の地震の判定条件が満たされないため、特定部４１３は受信された地震情報の対象となる対象地震を先行地震と一連の地震ではない新規の災害であると判定する。新規の災害の場合、安否確認通知を送信する必要がある。したがって、ステップＳ１４において、特定部４１３は受信された地震情報の通知種類を「災害通知」と判定する。一方、災害情報テーブル４４２にレコードが登録されている場合には対応中の先行地震が存在するため、ステップＳ１１の判定がＹＥＳとなり後続のステップＳ１２に進む。
【0052】
ステップＳ１２において、特定部４１３は受信された地震情報の対象となる対象地震の隣接地域内に、先行地震の被災地が含まれているかチェックして判定する。ここでいう「隣接地域内」とは、被災地と隣接地域とを合わせた範囲内をいう。対象地震の被災地は、災害管理テーブル４４１において対象地震の地震情報が登録されたレコードのエリアのうち被災地名により示される。隣接地域は、隣接地域テーブル４４５において対象地震の被災地名と関連付けられた隣接地域名により示される。先行地震の被災地は、災害管理テーブル４４１において先行地震の地震情報が登録されたレコードのエリアのうち被災地名により示される。
【0053】
先行地震の被災地が対象地震の被災地の隣接地域外である場合、ステップＳ１２の判定がＮＯになり上述したステップＳ１４に進む。この場合、一連の地震の判定条件が満たされないため、特定部４１３は対象地震を先行地震と一連の地震ではない新規の災害であると判定する。新規の災害である場合、安否確認通知を送信する必要がある。したがって、ステップＳ１４において、特定部４１３は受信された地震情報の通知種類を「災害通知」と判定する。一方、先行地震の被災地が対象地震の被災地の隣接地域内である場合、ステップＳ１２の判定がＹＥＳとなり後続のステップＳ１３に進む。この場合、一連の地震の判定条件が満たされるため、特定部４１３は対象地震を先行地震と一連の地震であると判定する。
【0054】
ステップＳ１３において、特定部４１３は先行地震の被災地と対象地震の被災地とを比較し、震度５弱以上の被災地が増加しているか否かを判定する。先行地震の被災地は、災害管理テーブル４４１において先行地震の地震情報が登録されたレコードのエリアのうち被災地名により示される。対象地震の被災地は、災害管理テーブル４４１において対象地震の地震情報が登録されたレコードのエリアのうち被災地名により示される。
【0055】
また、特定部４１３は、先行地震の被災地と対象地震の被災地とが同一である場合、先行地震の震度と対象地震の震度とを比較し、震度が上昇しているか否かを判定する。先行地震の震度は、災害管理テーブル４４１において先行地震の地震情報が登録されたレコードの震度により示される。対象地震の震度は、災害管理テーブル４４１において対象地震の地震情報が登録されたレコードの震度により示される。
【0056】
例えば震度５弱以上の被災地が増加している場合または同一の被災地について震度が上昇している場合、ステップＳ１３の判定がＹＥＳとなりステップＳ１６に進む。この場合、被災地の増加または震度の上昇により、先行地震に応じた安否確認の対象と対象地震に応じた安否確認の対象との間に差分が生じ得るため、この差分に安否確認通知を送信する必要がある。したがって、ステップＳ１６において、特定部４１３は受信された地震情報の通知種類を「震度変更通知」と判定する。
【0057】
一方、震度５弱以上の被災地が増加しておらず、同一の被災地について震度が上昇していない場合、ステップＳ１３の判定がＮＯとなりステップＳ１５に進む。この場合、余震の判定条件が満たされるため、特定部４１３は対象地震を余震とみなし、安否確認通知を不要とする。したがって、ステップＳ１５において、特定部４１３は受信された地震情報の通知種類を「余震通知」と判定する。ステップＳ１４、Ｓ１５、またはＳ１６の処理が完了すると、図１１に示される地震情報処理フローに戻る。
【0058】
図１０は、通知種類判定の一例を説明する図である。この例では、まず図１０（ａ）に示されるように対応中の先行地震が存在しない状況において東京都で震度５強の１回目の地震が発生したものとする。この場合、この地震の地震情報が受信され、図４に示される災害管理テーブル４４１の上から４行目のレコードに登録される。この地震情報の受信時には災害情報テーブル４４２に登録されているレコードが存在しないため、先行地震は存在しない。この場合、一連の地震の判定条件が満たされないため、１回目の地震は先行地震と一連の地震ではないと判定される。したがって、上述した通知種類判定ではこの地震情報の通知種類が「災害通知」と判定される。１回目の地震は新規の災害であるため、１回目の地震には災害Ｘという新たな災害コードが割り当てられる。
【0059】
続いて図１０（ｂ）に示されるように、１回目の地震の対応中に東京都で震度５強、千葉県で震度５弱の２回目の地震が発生したものとする。この場合、この地震の地震情報が受信され、図４に示される災害管理テーブル４４１の上から３行目のレコードに登録される。この地震情報の受信時には災害情報テーブル４４２に１回目の地震の地震情報が登録されたレコードが存在する。したがって、１回目の地震が先行地震となる。また２回目の地震の被災地は東京都と千葉県であり、東京都と千葉県の隣接地域は図６に示されるように神奈川県、山梨県、埼玉県、茨城県である。１回目の地震の被災地である東京都は、２回目の地震の被災地である東京都と千葉県の隣接地域内に含まれる。この場合、一連の地震の判定条件が満たされるため、２回目の地震は１回目の先行地震と一連の地震であると判定される。さらに１回目の地震は東京都で震度５強であるのに対し、２回目の地震は東京都で震度５強、千葉県で震度５弱であるため、震度５弱以上の被災地として千葉県が追加されている。したがって、上述した通知種類判定では２回目の地震の地震情報の通知種類が「震度変更通知」と判定される。２回目の地震は１回目の地震と一連の地震であるため、２回目の地震の災害コードは１回目の地震と同じ災害Ｘになる。
【0060】
続いて図１０（ｃ）に示されるように、１回目および２回目の地震の対応中に東京都で震度５弱、千葉県で震度５弱の３回目の地震が発生したものとする。この場合、この地震の地震情報が受信され、図４に示される災害管理テーブル４４１の上から２行目のレコードに登録される。この地震情報の受信時には災害情報テーブル４４２に１回目および２回目の地震に関する地震情報が登録されたレコードが存在する。したがって、１回目および２回目の地震が先行地震となる。また３回目の地震の被災地は東京都と千葉県であり、東京都と千葉県の隣接地域は図６に示されるように神奈川県、山梨県、埼玉県、茨城県である。１回目の地震の被災地である東京都、２回目の地震の被災地である東京都と千葉県は、３回目の地震の被災地である東京都と千葉県の隣接地域内に含まれる。この場合、一連の地震の判定条件が満たされるため、３回目の地震は１回目および２回目の先行地震と一連の地震であると判定される。さらに１回目の地震は東京都で震度５強、２回目の地震は東京都で震度５強、千葉県で震度５弱であるのに対し、３回目の地震は東京都で震度５弱、千葉県で震度５弱であるため、震度５弱以上の被災地が増加しておらず、同一の被災地である東京都と千葉県において震度の上昇もない。したがって、上述した通知種類判定では３回目の地震の地震情報の通知種類が「余震通知」と判定される。３回目の地震は１回目および２回目の地震と一連の地震であるため、３回目の地震の災害コードは１回目および２回目の地震と同じ災害Ｘになる。
【0061】
続いて図１０（ｄ）に示されるように、１回目～３回目の地震の対応中に静岡県で震度５弱の地震が発生したものとする。この場合、この地震の地震情報が受信され図４に示される災害管理テーブル４４１の最上行のレコードに登録される。この地震情報の受信時には災害情報テーブル４４２に１回目～３回目の地震に関する地震情報が登録されたレコードが存在する。したがって、１回目～３回目の地震が先行地震となる。しかし４回目の地震の被災地は静岡県であり、静岡県の隣接地域は図６に示されるように神奈川県、山梨県、長野県、愛知県である。１回目の地震の被災地である東京都、２回目および３回目の地震の被災地である東京都と千葉県は、４回目の地震の被災地である静岡県の隣接地域内に含まれない。この場合、一連の地震の判定条件が満たされないため、４回目の地震は１回目～３回目の地震と一連の地震ではない新規の災害である。そのため、上述した通知種類判定では４回目の地震の地震情報の通知種類が「災害通知」と判定される。４回目の地震は１回目～３回目の地震と一連の地震ではないため、４回目の地震の災害コードは１回目～３回目の地震の災害コードとは異なる災害Ｙとなる。
【0062】
図９に示される通知種類判定においてステップＳ１４に進み「災害通知」と判定された場合には、図１１に示されるステップＳ３６に進む。以下のステップＳ３６～Ｓ３９の災害通知処理の説明では、図４に示される災害管理テーブル４４１の上から４行目のレコードに登録された地震情報が処理対象であるものとする。
【0063】
ステップＳ３６において、「災害通知」と判定された場合、表示部４６にオペレーター画面（災害通知）が表示される。図１２は、オペレーター画面（災害通知）の表示例を示す図である。オペレーター画面（災害通知）には、災害一覧画面４６０Ａと災害通知画面４６５Ａとが含まれる。表示部４６にはまず災害一覧画面４６０Ａが表示される。災害一覧画面４６０Ａには、現在発生している災害の一覧が含まれる。災害一覧には、災害管理テーブル４４１に登録された対象地震の地震情報のレコードに含まれる災害名、発生日時、処理ステータスが含まれる。
【0064】
また、災害一覧画面４６０Ａには、災害通知の作成ボタン４６１と、震度変更の作成ボタン４６２と、余震通知の作成ボタン４６３と、変更ボタン４６４とが含まれる。災害通知の作成ボタン４６１は、災害通知画面４６５Ａを表示するための操作に用いられる。災害通知画面４６５Ａは安否確認の対象への安否確認通知の送信に関する操作に用いられるため、災害通知の作成ボタン４６１は本発明に係る安否確認の対象への安否確認通知の送信に関する操作に用いられる操作画像の一例である。震度変更の作成ボタン４６２は、震度変更画面４６５Ｂを表示するための操作に用いられる。震度変更画面４６５Ｂは安否確認の対象の差分への安否確認通知の送信に関する操作に用いられるため、震度変更の作成ボタン４６２は本発明に係る安否確認の対象の差分への安否確認通知の送信に関する操作に用いられる操作画像の一例である。余震通知の作成ボタン４６３は、余震通知画面４６５Ｃを表示するための操作に用いられる。余震通知画面４６５Ｃは余震通知の送信に関する操作に用いられるため、余震通知の作成ボタン４６３は本発明に係る余震通知の送信に関する操作に用いられる操作画像の一例である。変更ボタン４６４は、地震情報を処理対象外にするための操作に用いられる。
【0065】
「災害通知」と判定された場合には、災害通知の作成ボタン４６１が強調表示（背景色を他と変えて目立たせる等）される。図１２に示される例では、「関東地域 震度５強」という災害について災害通知の作成ボタン４６１が背景色をピンク色などの目立つ色に変更することにより強調表示される。この強調表示により、オペレーターは、災害通知処理における推奨操作が災害通知の作成ボタン４６１の押下であることが分かる。
【0066】
なお、災害一覧画面４６０Ａにおいて震度変更の作成ボタン４６２または余震通知の作成ボタン４６３が押下された場合には、災害通知処理における推奨操作ではないため、本当にこの操作を実行してもよいかを問い合わせる警告情報が表示される。これにより、災害通知処理において推奨されない操作をオペレーターが行うのを抑制できる。
【0067】
ステップＳ３７において、オペレーターが災害通知の作成ボタン４６１を押下すると災害通知画面４６５Ａが表示部４６に表示される。図１２に示される例においてオペレーターが「関東地域 震度５強」という災害について災害通知の作成ボタン４６１を押下すると、災害管理テーブル４４１に登録された対象地震の地震情報の内容に基づき値をセットした状態で災害通知画面４６５Ａが表示される。図１２に示される例では、災害通知画面４６５Ａにおいて、図４に示される災害管理テーブル４４１の上から４行目のレコードに含まれるエリアの被災地名である「東京都」がオペレーターの操作を介さずに安否確認通知の送信対象エリアとして設定される。また、災害通知画面４６５Ａにおいて、このレコードの災害詳細が安否確認通知の本文として設定されてもよい。さらに、災害通知画面４６５Ａには、災害の発生年月日、発生時刻、発生場所を入力するための入力領域が含まれてもよい。さらに、災害通知画面４６５Ａには、送信ボタン４６６Ａが含まれる。送信ボタン４６６Ａは、災害通知を作成し安否確認通知を送信するための操作に用いられる。
【0068】
本実施形態では、安否確認通知を代行送信する際に、オペレーターが安否確認通知を送信すべきか否かを判断し、操作を行うようになっている。このように、オペレーターの判断結果を受け取るようにしたのは、地震情報が誤報の可能性があるため、安否確認通知を送信するか否かを最終的にオペレーターが判断できるようにするためである。オペレーターの判断を介入させることにより、安否確認通知の誤報を減らすことができる。
【0069】
災害通知画面４６５Ａには上述した通り災害管理テーブル４４１に登録された地震情報の内容に基づき初期値がセットされるため、そのままあるいは適宜修正し、オペレーターが送信ボタン４６６Ａを押下すると、ステップＳ３７の判定がＹＥＳとなり後続のステップＳ３８にて災害情報テーブル４４２にレコードが登録される。一方、オペレーターが災害通知の作成ボタン４６１を押下せず、災害一覧画面４６０Ａにおいて「関東地域 震度５強」という災害の処理ステータスを「処理対象外」にして変更ボタン４６４を押下すると、ステップＳ３７の判定がＮＯとなりステップＳ４９に進み記憶部更新部４１６により災害管理テーブル４４１に新たに登録されたレコードの処理ステータスが「処理対象外」に更新され処理が終了する。
【0070】
ステップＳ３８において、災害通知を作成する操作が行われると記憶部更新部４１６により災害情報テーブル４４２にレコードが登録される。図５に示される例では、災害情報テーブル４４２の最上行に顧客識別コードが共通のレコードが登録される。このレコードの災害名、発生年月日、発生時刻、発生場所、詳細には、上述した災害通知画面４６５Ａにおいて予め設定された情報またはオペレーターの操作により入力された情報がセットされる。
【0071】
ステップＳ３９において、送信部４１４は条件管理テーブル４４３より顧客ごとの送信条件を取得し、この送信条件を満たす顧客について災害情報テーブル４４２に登録する。送信部４１４は、受信された地震情報により示される震度５弱以上の被災地名と、条件管理テーブル４４３に含まれる被災地名、震度とを比較する。図７に示される例では、顧客Ａは被災地名「東京都」、「千葉県」についてそれぞれ震度５弱を設定しているところ、図４に示される災害管理テーブル４４１の上から４行目のレコードのエリアと震度に「東京都」と「震度５強」との組合せが含まれているため、送信条件を満たしており顧客Ａは通知対象となる。一方、顧客Ｂは「埼玉県」、「茨城県」についてそれぞれ震度５弱を設定しているが、図４に示される災害管理テーブル４４１の上から４行目のレコードのエリアと震度に「埼玉県」と「震度５弱」以上の震度の組合せも「茨城県」と「震度５弱」以上の震度の組合せも含まれていないため、送信条件を満たしておらず顧客Ｂは通知対象と判定されない。同様に顧客Ｃも通知対象と判定されない。
【0072】
この場合、対象地震に応じた安否確認の対象は顧客Ａであるため、図５に示されるように災害情報テーブル４４２の上から２行目に顧客識別コードが顧客Ａのレコードが登録される。このとき、顧客Ａのレコードの災害コード、災害名、発生年月日、発生時刻、発生場所、詳細には、災害情報テーブル４４２の最上行の顧客識別コードが共通のレコードと同じ値がセットされる。
【0073】
送信部４１４は、災害情報テーブル４４２を基に顧客情報テーブル４４４より利用者の通信アドレスを取得し利用者端末３０に安否確認通知を送信する。図５に示される例では、災害情報テーブル４４２に顧客識別コードが顧客Ａのレコードが登録されるため、通知対象と判定された顧客Ａについて、送信部４１４は顧客情報テーブル４４４より利用者端末３０の通信アドレスを取得し、第２通信部４３を介して利用者端末３０に安否確認通知を送信する。図４に示される災害管理テーブル４４１の上から４行目のレコードに含まれるエリアの被災地名は東京都であるため、顧客Ａの利用者のうちエリアが東京都の利用者が通知対象となる。したがって、送信部４１４は、図８に示される顧客情報テーブル４４４から顧客識別コードが「顧客Ａ」、端末種別が「利用者」、エリアが「東京都」のレコードに含まれる３つの通信アドレスを取得し、これらの通信アドレス宛に安否確認通知を送信する。
【0074】
また送信部４１４は通知対象と判定された顧客Ａについて管理者端末２０の通信アドレスを取得し、第２通信部４３を介して管理者端末２０に代行送信通知および災害通知を送信する。例えば送信部４１４は、図８に示される顧客情報テーブル４４４から顧客識別コードが「顧客Ａ」、端末種別が「管理者」のレコードに含まれる１つの通信アドレスを取得し、この通信アドレス宛に代行送信通知および災害通知を送信する。
【0075】
図１３は、安否確認通知を例示する図である。安否確認通知は、利用者の安否を確認するための通知である。安否確認通知は災害情報テーブル４４２に基づいて作成される。例えば顧客Ａに送信される安否確認通知には、図５に示される災害情報テーブル４４２の上から２行目の顧客識別コードが顧客Ａのレコードに含まれる災害名、発生年月日、発生時刻が含まれる。また、安否確認通知には、安否情報を回答するための情報が含まれる。利用者端末３０は、センター装置４０から受信した安否確認通知を表示部３１に表示する。利用者は、表示部３１に表示された安否確認通知に従って安否情報を回答（安否報告）する。この安否情報の回答は、ウェブ画面、電子メール、電話などのいずれの手段を利用して行われてもよい。
【0076】
図１４は、災害通知を例示する図である。災害通知は、災害が発生した（地震情報を受信した）ことを管理者宛に通知するものである。災害通知は災害情報テーブル４４２に基づいて作成される。例えば顧客Ａに送信される安否確認通知には、図５に示される災害情報テーブル４４２において上から２行目の顧客識別コードが顧客Ａのレコードに含まれる災害名、発生年月日、発生時刻が含まれる。災害通知により管理者は災害が発生したことが分かる。
【0077】
図１５は、代行送信通知を例示する図である。代行送信通知は、代行送信事業者により安否確認通知の代行送信が実施されたことを管理者宛に通知するものである。代行送信通知は災害情報テーブル４４２および条件管理テーブル４４３に基づいて作成される。例えば顧客Ａに送信される代行送信通知には、図５に示される災害情報テーブル４４２において上から２行目の顧客識別コードが顧客Ａのレコードに含まれる災害名、発生年月日、発生時刻と、図７に示される条件管理テーブル４４３において顧客識別コードが顧客Ａのレコードに含まれる該当する安否確認通知の送信条件が含まれる。代行送信通知により管理者は代行送信事業者により安否確認通知が代行送信されたことが分かる。
【0078】
なお図４に示される災害管理テーブル４４１の最上行のレコードに登録された地震情報が処理対象である場合にも、地震情報の通知種類が「災害通知」と判定されるため、上述と同様の処理が行われる。
【0079】
図９に示される通知種類判定においてステップＳ１６に進み「震度変更通知」と判定された場合には、図１１に示されるステップＳ４０に進む。以下のステップＳ４０～Ｓ４３の震度変更処理の説明では、図４に示される災害管理テーブル４４１の上から３行目のレコードに登録された地震情報が処理対象であるものとする。
【0080】
ステップＳ４０において、「震度変更通知」と判定された場合、表示部４６にオペレーター画面（震度変更）が表示される。図１６は、オペレーター画面（震度変更）の表示例を示す図である。オペレーター画面（震度変更）には、災害一覧画面４６０Ｂと震度変更画面４６５Ｂとが含まれる。災害一覧画面４６０Ｂは、基本的にはオペレーター画面（災害通知）に含まれる災害一覧画面４６０Ａと同様である。ただし、「震度変更通知」と判定された場合には、災害通知の作成ボタン４６１でなく、震度変更の作成ボタン４６２が強調表示（背景色を他と変えて目立たせる等）される。図１６に示される例では、「関東地域 震度５強」という災害について震度変更の作成ボタン４６２が背景色をピンク色などの目立つ色に変更することにより強調表示される。この強調表示により、オペレーターは、震度変更処理における推奨操作が震度変更の作成ボタン４６２の押下であることが分かる。
【0081】
なお、災害一覧画面４６０Ｂにおいて災害通知の作成ボタン４６１または余震通知の作成ボタン４６３が押下された場合には、震度変更処理における推奨操作ではないため、本当にこの操作を実行してもよいかを問い合わせる警告情報が表示される。これにより、震度変更処理において推奨されない操作をオペレーターが行うのを抑制できる。
【0082】
ステップＳ４１において、オペレーターが震度変更の作成ボタン４６２を押下すると表示部４６に震度変更画面４６５Ｂが表示される。図１６に示される例においてオペレーターが「関東地域 震度５強」という災害について震度変更の作成ボタン４６２を押下すると、災害管理テーブル４４１に登録された対象地震の地震情報および先行地震の地震情報の内容に基づき値をセットした状態で震度変更画面４６５Ｂが表示される。図１６に示される例では、震度変更画面４６５Ｂにおいて、図４に示される災害管理テーブル４４１の上から４行目のレコードに含まれる先行地震のエリアの被災地名と上から３行目のレコードに含まれる対象地震のエリアの被災地名とを統合した「東京都」と「千葉県」とがオペレーターの操作を介さずに安否確認通知の送信対象エリアとして設定される。また震度変更画面４６５Ｂにおいて、災害通知画面４６５Ａと同様にその他の情報が設定されてもよい。さらに、震度変更画面４６５Ｂには、送信ボタン４６６Ｂが含まれる。送信ボタン４６６Ｂは、震度変更を作成し先行地震と対象地震との安否確認の対象の差分への安否確認通知の送信に関する操作に用いられる。
【0083】
震度変更画面４６５Ｂには上述した通り災害管理テーブル４４１に登録された先行地震の地震情報と対象地震の地震情報とをまとめた内容に基づき初期値がセットされるため、そのままあるいは適宜修正し、オペレーターが送信ボタン４６６Ｂを押下すると、ステップＳ４１の判定がＹＥＳとなり後続のステップＳ４２にて災害情報テーブル４４２にレコードが登録される。一方、オペレーターが震度変更の作成ボタン４６２を押下せず、災害一覧画面４６０Ｂにおいて「関東地域 震度５強」という災害について処理ステータスを「処理対象外」にして変更ボタン４６４を押下すると、ステップＳ４１の判定がＮＯとなり、ステップＳ４９に進み記憶部更新部４１６により災害管理テーブル４４１に新たに登録されたレコードの処理ステータスが「処理対象外」に更新され処理が終了する。
【0084】
ステップＳ４２において、震度変更通知を作成する操作が行われると記憶部更新部４１６により災害情報テーブル４４２に登録済みのレコードが更新される。図４に示される災害管理テーブル４４１の上から３行目のレコードに登録された地震情報は、上から４行目のレコードに登録された地震情報に対応する先行地震と一連の地震に関するものである。したがって、災害管理テーブル４４１の上から４行目のレコードに含まれる先行地震の地震情報と上から３行目のレコードに含まれる対象地震の地震情報とを統合した内容を基に、図５に示される災害情報テーブル４４２の最上行の顧客識別コードが共通のレコードが更新される。
【0085】
ステップＳ４３において、送信部４１４は上述したステップＳ３９と同様に、条件管理テーブル４４３より顧客ごとの送信条件を取得し、この送信条件を満たす顧客について災害情報テーブル４４２に登録・更新する。図７に示される例では、顧客Ａは被災地名「東京都」、「千葉県」についてそれぞれ震度５弱を設定しているところ、図４に示される災害管理テーブル４４１の上から３行目のレコードのエリアと震度に「東京都」と「震度５強」、「千葉県」と「震度５弱」との組合せが含まれているため、送信条件を満たしており顧客Ａは通知対象となる。また図７に示される例では、顧客Ｃは被災地名「千葉県」、「神奈川県」、「埼玉県」、「山梨県」についてそれぞれ震度５弱、「静岡県」、「長野県」、「栃木県」についてそれぞれ震度５強を設定しているところ、図４に示される災害管理テーブル４４１の上から３行目のレコードのエリアと震度に「千葉県」と「震度５弱」との組合せが含まれているため、送信条件を満たしており顧客Ｃも通知対象となる。一方、顧客Ｂは「埼玉県」、「茨城県」についてそれぞれ震度５弱を設定しているが、図４に示される災害管理テーブル４４１の上から３行目のレコードのエリアと震度に「埼玉県」と「震度５弱」以上の震度の組合せも「茨城県」と「震度５弱」以上の震度の組合せも含まれていないため、送信条件を満たしておらず顧客Ｂは通知対象と判定されない。
【0086】
この場合、対象地震に応じた安否確認の対象は顧客ＡとＣである。図５に示される災害情報テーブル４４２では、顧客Ａのレコードは図４に示される災害管理テーブル４４１の上から４行目のレコードに登録された地震情報の受信時に登録済みなので、ステップＳ４２で更新された顧客識別コードが共通の最上行のレコードの内容で更新される。一方、顧客Ｃのレコードは災害情報テーブル４４２に未登録につき、図５に示されるように災害情報テーブル４４２の上から３行目に顧客識別コードが顧客Ｃのレコードが登録される。このとき、顧客Ｃのレコードの災害コード、災害名、発生年月日、発生時刻、発生場所、詳細には、ステップＳ４２で更新された顧客識別コードが共通の最上行のレコードと同じ値がセットされる。
【0087】
送信部４１４は、災害情報テーブル４４２を基に顧客情報テーブル４４４より安否確認の対象の差分の通信アドレスを取得し利用者端末３０に安否確認通知を送信する。図４に示される災害管理テーブル４４１の上から４行目のレコードに含まれる先行地震のエリアの被災地名と、上から３行目のレコードに含まれる対象地震のエリアの被災地名とを比較すると、対象地震のエリアの被災地名には「千葉県」が追加されている。そのため、顧客Ａの利用者のうちエリアが千葉県の利用者、および新たに通知対象となった顧客Ｃの利用者のうちエリアが千葉県の利用者が安否確認の対象の差分となる。したがって、送信部４１４は、図８に示される顧客情報テーブル４４４から顧客識別コードが「顧客Ａ」、端末種別が「利用者」、エリアが「千葉県」のレコードに含まれる１つの通信アドレス、および顧客識別コードが「顧客Ｃ」、端末種別が「利用者」、エリアが「千葉県」のレコードに含まれる１つの通信アドレスを取得し、これらの通信アドレス宛に安否確認通知を送信する。
【0088】
なお、送信部４１４は、震度変更処理では図４に示される災害管理テーブル４４１の上から４行目のレコードに登録された先行地震の地震情報に応じて既に安否確認通知が送信された顧客Ａの利用者のうちエリアが東京都の利用者の利用者端末３０には安否確認通知を送信しない。
【0089】
また送信部４１４は通知対象となる顧客ＡおよびＣについて管理者端末２０の通信アドレスを取得し、第２通信部４３を介して管理者端末２０に代行送信通知および震度変更通知を送信する。例えば送信部４１４は、図８に示される顧客情報テーブル４４４から顧客識別コードが「顧客Ａ」、端末種別が「管理者」のレコードに含まれる１つの通信アドレス、および顧客識別コードが「顧客Ｃ」、端末種別が「管理者」のレコードに含まれる１つの通信アドレスを取得し、これらの通信アドレス宛に代行送信通知および震度変更通知を送信する。
【0090】
図１７は、震度変更通知を例示する図である。震度変更通知は、震度変更が発生したことを管理者宛てに通知するものである。震度変更通知は災害管理テーブル４４１および災害情報テーブル４４２に基づいて作成される。例えば震度変更通知には、図４に示される災害管理テーブル４４１の上から３行目のレコードに含まれる災害名、発生日時が含まれる。震度変更通知により管理者は震度変更が発生したことが分かる。
【0091】
図９に示される通知種類判定においてステップＳ１５に進み「余震通知」と判定された場合には、図１１に示されるステップＳ４４に進む。以下のステップＳ４４～Ｓ４７の余震通知処理の説明では、図４に示される災害管理テーブル４４１の上から２行目のレコードに登録された地震情報が処理対象であるものとする。
【0092】
ステップＳ４４において、「余震通知」と判定された場合、表示部４６にオペレーター画面（余震通知）が表示される。図１８は、オペレーター画面（余震通知）の表示例を示す図である。オペレーター画面（余震通知）には、災害一覧画面４６０Ｃと余震通知画面４６５Ｃとが含まれる。災害一覧画面４６０Ｃは、基本的にはオペレーター画面（災害通知）に含まれる災害一覧画面４６０Ａと同様である。ただし、「余震通知」と判定された場合には、災害通知の作成ボタン４６１ではなく、余震通知の作成ボタン４６３が強調表示（背景色を他と変えて目立たせる等）される。図１８に示される例では、「関東地域 震度５弱」という災害について余震通知の作成ボタン４６３が背景色をピンク色などの目立つ色に変更することにより強調表示される。この強調表示により、オペレーターは、余震通知処理における推奨操作が余震通知の作成ボタン４６３の押下であることが分かる。
【0093】
なお、災害一覧画面４６０Ｃにおいて災害通知の作成ボタン４６１または震度変更の作成ボタン４６２が押下された場合には、余震通知処理における推奨操作ではないため、本当にこの操作を実行してもよいかを問い合わせる警告情報が表示される。これにより、震度変更処理において推奨されない操作をオペレーターが行うのを抑制できる。
【0094】
ステップＳ４５において、オペレーターが余震通知の作成ボタン４６３を押下すると表示部４６に余震通知画面４６５Ｃが表示される。図１８に示される例においてオペレーターが「関東地域 震度５弱」という災害について余震通知の作成ボタン４６３を押下すると、災害管理テーブル４４１に登録された対象地震の地震情報および先行地震の地震情報の内容に基づき値をセットした状態で余震通知画面４６５Ｃが表示される。図１８に示される例では、余震通知画面４６５Ｃにおいて、図４に示される災害管理テーブル４４１の上から３行目および４行目のレコードに含まれる先行地震のエリアの被災地名と上から２行目のレコードに含まれる対象地震のエリアの被災地名とを統合した「東京都」と「千葉県」とがオペレーターの操作を介さずに安否確認通知の送信対象エリアとして設定される。また余震通知画面４６５Ｃにおいて、災害通知画面４６５Ａと同様にその他の情報が設定されてもよい。さらに、余震通知画面４６５Ｃには、送信ボタン４６６Ｃが含まれる。送信ボタン４６６Ｃは、余震通知を作成し送信するための操作に用いられる。
【0095】
余震通知画面４６５Ｃには上述した通り災害管理テーブル４４１に登録された先行地震の地震情報と対象地震の地震情報とをまとめた内容に基づき初期値がセットされるため、そのままあるいは適宜修正し、オペレーターが送信ボタン４６６Ｃを押下すると、ステップＳ４５の判定がＹＥＳとなり後続のステップＳ４６にて災害情報テーブル４４２にレコードが登録される。一方、オペレーターが余震通知の作成ボタン４６３を押下せず、災害一覧画面４６０Ｃにおいて「関東地域 震度５弱」という災害について処理ステータスを「処理対象外」にして変更ボタン４６４を押下すると、ステップＳ４５の判定がＮＯとなり、ステップＳ４９に進み記憶部更新部４１６により災害管理テーブル４４１に新たに登録されたレコードの処理ステータスが「処理対象外」に更新され処理が終了する。
【0096】
ステップＳ４６において、余震通知を作成する操作が行われると記憶部更新部４１６により災害情報テーブル４４２に登録済みのレコードが更新される。図４に示される災害管理テーブル４４１の上から２行目のレコードに登録された地震情報は、上から３行目および４行目のレコードに登録された地震情報により示される先行地震と一連の地震に関するものである。したがって、図４に示される災害管理テーブル４４１の上から３行目および４行目のレコードに含まれる先行地震の地震情報と上から２行目のレコードに含まれる対象地震の地震情報とを統合した内容を基に、図５に示される災害情報テーブル４４２の最上行の顧客識別コードが共通のレコードが更新される。
【0097】
ステップＳ４７において、送信部４１４は上述したステップＳ３９と同様に、条件管理テーブル４４３より顧客ごとの送信条件を取得し、この送信条件を満たす顧客について災害情報テーブル４４２に登録・更新する。図７に示される例では、顧客Ａは被災地名「東京都」、「千葉県」についてそれぞれ震度５弱を設定しているところ、図４に示される災害管理テーブル４４１の上から２行目のレコードのエリアと震度に「東京都」と「震度５弱」、「千葉県」と「震度５弱」との組合せが含まれているため、送信条件を満たしており顧客Ａは通知対象となる。また図７に示される例では、顧客Ｃは被災地名「千葉県」、「神奈川県」、「埼玉県」、「山梨県」についてそれぞれ震度５弱、「静岡県」、「長野県」、「栃木県」についてそれぞれ震度５強を設定しているところ、図４に示される災害管理テーブル４４１の上から２行目のレコードのエリアと震度に「千葉県」と「震度５弱」との組合せが含まれているため、送信条件を満たしており顧客Ｃも通知対象となる。一方、顧客Ｂは「埼玉県」、「茨城県」についてそれぞれ震度５弱を設定しているが、図４に示される災害管理テーブル４４１の上から２行目のレコードのエリアと震度に「埼玉県」と「震度５弱」以上の震度の組合せも「茨城県」と「震度５弱」以上の震度の組合せも含まれていないため、送信条件を満たしておらず顧客Ｂは通知対象と判定されない。
【0098】
この場合、対象地震に応じた通知対象は顧客ＡとＣであるが、図５に示される災害情報テーブル４４２では、顧客ＡおよびＣのレコードは図４に示される災害管理テーブル４４１の上から３行目および４行目のレコードに登録された地震情報の受信時に災害情報テーブル４４２に登録済みなので、ステップＳ４６で更新された顧客識別コードが共通の最上行のレコードの内容で更新される。
【0099】
送信部４１４は、災害情報テーブル４４２を基に顧客情報テーブル４４４より通知対象となる顧客ＡおよびＣの管理者の通信アドレスを取得し、第２通信部４３を介して管理者端末２０に余震通知を送信する。例えば送信部４１４は、図８に示される顧客情報テーブル４４４から顧客識別コードが「顧客Ａ」、端末種別が「管理者」のレコードに含まれる１つの通信アドレス、および顧客識別コードが「顧客Ｃ」、端末種別が「管理者」のレコードに含まれる１つの通信アドレスを取得し、これらの通信アドレス宛に余震通知を送信する。なお、余震通知処理では、送信部４１４は安否確認通知を送信しない。これは対象地震が余震である場合、先行地震に応じた安否確認の対象と対象地震に応じた安否確認の対象との間に基本的には差分が生じないためである。
【0100】
図１９は、余震通知を例示する図である。余震通知は、余震が発生したことを管理者宛に通知するものである。余震通知は災害管理テーブル４４１および災害情報テーブル４４２に基づいて作成される。例えば余震通知には、図４に示される災害管理テーブル４４１の上から２行目のレコードに含まれる災害名、発生日時が含まれる。余震通知により管理者は余震が発生したことが分かる。
【0101】
ステップＳ４８において、ステップＳ３３で災害管理テーブル４４１に新たに登録されたレコードの処理ステータスが記憶部更新部４１６により「処理済み」に更新される。
【0102】
なお、ステップＳ４９に進んだ場合には、上述したように記憶部更新部４１６によりステップＳ３３で災害管理テーブル４４１に新たに登録されたレコードの処理ステータスが「処理対象外」に更新され処理が終了する。この場合、受信された地震情報について安否確認通知、代行送信通知、災害通知、震度変更通知、および余震通知の送信は行われない。
【0103】
センター装置４０は、利用者から回答された安否情報を記憶部４４に記憶する。管理者は、この安否情報に基づいてセンター装置４０から提供された集計画面および一覧画面を表示部２１に表示させることにより、利用者の安否情報を閲覧することができる。図２０は、安否状況の集計画面および一覧画面を例示する図である。管理者は、送信部４１４が送信した安否確認通知に対する利用者の応答状況（安否状況）を集計画面、一覧画面で確認することができる。また管理者は、必要により未確認、応答有の利用者に安否確認通知の再送を行うことも可能である。
【0104】
集計画面には、安否状況の集計結果が含まれる。この集計結果には、利用者数と、対象者数と、応答数と、未確認数と、安全者数と、軽傷者数と、重傷者数と、応答有数と、応答率とが含まれる。利用者数は、安否確認システム１に登録されている対象の顧客の利用者総数（ユーザーコード数）を表すものである。対象者数は、安否確認の送信対象者数を表すものである。応答数は、対象者が安否確認通知に応答した数を表すものである。未確認数は、安否状況の未確認数を表すものである。管理者が未確認の再送ボタンを押下すると安否状況が未確認の利用者に安否確認通知が再送される。安全者数は、「安全」と報告された数を集計したものである。軽傷者数は、「軽傷」と報告された数を集計したものである。重傷者数は、「重傷」と報告された数を集計したものである。応答有数は、電子メールの返信による安否報告において、応答区分に該当しない内容で返信をした数や、安否報告を実施するとき、センター装置４０にアクセスしただけで各応答項目に対する報告が正しくできていない利用者の数を集計したものである。管理者が応答有の再送ボタンを押下すると応答有の利用者に再度報告を行うよう安否確認通知が再送される。応答率は、応答数÷対象者数×１００により得られる値を％で表したものである。
【0105】
一覧画面には、ユーザーＩＤ／利用者名、エリア、本人の安否、出社可否、家族の安否、家屋の状態、返答日時、応答区分、コメント、登録者が含まれる。なお、図２０に示される例は、電文により示される災害の種類が「震災」の場合の表示項目であり、災害の種類により表示内容は異なる。ユーザーＩＤ／利用者名は、安否確認通知の送信先の利用者のユーザーコードおよび氏名を表すものである。エリアは、利用者または管理者の所在するエリア（居住地、勤務地等）を表す。エリアは顧客情報テーブル４４４に設定されている。本人の安否は、利用者より応答された安全、軽傷、重傷のいずれかを表す。正しく応答できていない場合は応答有となる。出社可否は、利用者より応答された不可、概ね１時間以内、概ね３時間以内、出社済、その他のいずれかを表すものである。家族の安否は、利用者より応答された不明、全員無事、負傷者有り、不明者有り、重大事故有りのいずれかを表すものである。家屋の状態は、利用者より応答された不明、無事、半壊、全壊のいずれかを表すものである。返答日時は、利用者より応答された日時を表すものである。応答区分は、利用者の応答がどのような手段で実施されたかを表すものである。例えば応答区分にはウェブ画面（ＰＣ）、スマートフォンのアプリケーション、電子メールなどがある。コメントは、利用者より応答された管理者へのメッセージを表すものである。登録者は、利用者本人が応答した場合には本人、管理者が代行登録した場合には管理者の氏名を表すものである。管理者が安否代行の登録ボタンを押下すると、管理者が利用者を代行して安否報告することが可能である。
【0106】
本実施形態では、図４に示される災害管理テーブル４４１の上から４行目のレコードに登録された地震情報の対象となる１回目の地震、および上から３行目のレコードに登録された地震情報の対象となる２回目の地震を一連の地震とみなし「災害Ｘ」という１つの災害として管理しているため、２回目の地震の発生時に行われた震度変更処理により安否確認の対象に追加された利用者（ここではユーザーＩＤがユーザー００５の利用者）の安否状況も、１回目の地震の発生時に安否確認通知が送信された利用者（ここではユーザーＩＤがユーザー００２～００４の利用者）の安否状況と一緒に確認することができる。このように、先行地震と一連の地震を１つの災害として管理できるため、煩わしさがない。
【0107】
上述した実施形態によれば、先行地震の後に対象地震が発生した場合に、対象地震が先行地震と一連の地震であるか否かをオペレーターの判断を介さずに判定し、その判定結果に応じた処理を行うことができる。これにより、オペレーターの負担を軽減することができる。また、一連の地震の判定条件には、先行地震の被災地が対象地震の被災地の隣接地域内であるという条件が含まれるため、先行地震と一連の地震を判定する精度が向上する。さらに、例えば第１地震の発生から所定時間以内に一連の地震の判定条件を満たす第２地震が発生し、第２地震の発生から所定時間以内に一連の地震の判定条件を満たす第３地震が発生した場合には、第２地震および第３地震はいずれも第１地震と一連の地震として判定されるというように、先行地震と一連の地震が連鎖的に判定されるため、一連の地震を判定する精度が向上する。
【0108】
さらに、対象地震が先行地震と一連の地震である場合には、先行地震に応じて既に安否確認通知が送信された通知対象の利用者端末３０には対象地震に応じて安否確認通知が送信されないため、一連の地震において安否確認が繰り返し行われることによる利用者の煩わしさを軽減することができる。これにより、利用者への不要な安否確認通知の送信を防止することができ、安否確認サービスの利便性が向上するとともに、通信量を減らすことができる。さらに、対象地震が先行地震と一連の地震である場合には、先行地震と対象地震との安否確認の対象の差分となる利用者端末３０に安否確認通知が送信されるため、先行地震に応じて既に安否確認通知が送信された利用者端末３０に対して、対象地震に応じて再び安否確認通知が送信されるのを防止することができる。さらに、対象地震が先行地震の余震である場合には、対象地震に応じて安否確認の対象となる顧客の管理者端末２０に余震通知が送信され、利用者端末３０に安否確認通知が送信されないため、先行地震に応じて既に安否確認通知が送信された利用者端末３０に対して、余震に応じて再び安否確認通知が送信されるのを防止することができる。
【0109】
さらに、オペレーター画面（災害通知）では災害通知の作成ボタン４６１が強調表示されるため、オペレーターが災害通知処理における推奨操作を容易に行うことができる。さらに、震度変更処理に係るオペレーター画面では震度変更の作成ボタン４６２が強調表示されるため、オペレーターが震度変更処理における推奨操作を容易に行うことができる。さらに、オペレーター画面（余震通知）では余震通知の作成ボタン４６３が強調表示されるため、オペレーターが余震通知処理における推奨操作を容易に行うことができる。
【0110】
３．変形例
本発明は、上述した実施形態に限定されない。上述した実施形態は一例であり、以下のように変形して実施されてもよいし、以下の２つ以上の変形例を組み合わせて実施されてもよい。
本発明は、上述した実施形態に限定されない。上述した実施形態は一例であり、以下のように変形して実施されてもよいし、以下の２つ以上の変形例を組み合わせて実施されてもよい。
【0111】
３－１．変形例１
上述した実施形態において、安否確認通知等はオペレーターの操作を介さずに送信されてもよい。この変形例では、上述したオペレーターによる災害通知の作成ボタン４６１、震度変更の作成ボタン４６２、余震通知の作成ボタン４６３、および送信ボタン４６６Ａ～４６６Ｃの押下は行われない。災害通知処理では、送信部４１４は地震情報の受信後、対象判定部４１２、特定部４１３によって顧客への通知の対象と判定したものについて、オペレーターの操作を介さずに、安否確認通知の送信条件を満たす顧客の利用者端末３０に安否確認通知を送信する。変更通知処理では、送信部４１４は地震情報の受信後、対象判定部４１２、特定部４１３によって顧客への通知の対象と判定したものについて、オペレーターの操作を介さずに、先行地震と対象地震との安否確認の対象の差分に安否確認通知を送信する。余震通知処理では、送信部４１４は地震情報の受信後、対象判定部４１２、特定部４１３によって顧客への通知の対象と判定したものについて、オペレーターの操作を介さずに、安否確認通知の送信条件を満たす顧客の管理者端末２０に余震通知を送信する。この変形例によれば、オペレーターが操作を行わなくても、安否確認通知等を自動的に送信することができる。
上述した実施形態において、安否確認通知等はオペレーターの操作を介さずに送信されてもよい。この変形例では、上述したオペレーターによる災害通知の作成ボタン４６１、震度変更の作成ボタン４６２、余震通知の作成ボタン４６３、および送信ボタン４６６Ａ～４６６Ｃの押下は行われない。災害通知処理では、送信部４１４は地震情報の受信後、対象判定部４１２、特定部４１３によって顧客への通知の対象と判定したものについて、オペレーターの操作を介さずに、安否確認通知の送信条件を満たす顧客の利用者端末３０に安否確認通知を送信する。変更通知処理では、送信部４１４は地震情報の受信後、対象判定部４１２、特定部４１３によって顧客への通知の対象と判定したものについて、オペレーターの操作を介さずに、先行地震と対象地震との安否確認の対象の差分に安否確認通知を送信する。余震通知処理では、送信部４１４は地震情報の受信後、対象判定部４１２、特定部４１３によって顧客への通知の対象と判定したものについて、オペレーターの操作を介さずに、安否確認通知の送信条件を満たす顧客の管理者端末２０に余震通知を送信する。この変形例によれば、オペレーターが操作を行わなくても、安否確認通知等を自動的に送信することができる。
【0112】
３－２．変形例２
上述した実施形態において、一連の地震の判定条件に含まれる所定時間は変更されてもよい。地震の規模が大きい場合には一連の地震がある程度の時間を空けて発生する場合がある。そこで、例えば地震の震度が７などの基準震度より大きい場合には、所定時間が基準の６時間から１０時間に変更されてもよい。この場合、災害情報テーブル４４２に格納された地震情報が削除される所定時間も同様に基準の６時間から１０時間に変更される。この所定時間の変更は、オペレーターの操作により行われてもよし、オペレーターの操作を介さずにセンター装置４０により自動的に行われてもよい。これにより、地震の規模が大きい場合に一連の地震がある程度の時間を空けて発生しても、この地震を一連の地震と判定することができる。
上述した実施形態において、一連の地震の判定条件に含まれる所定時間は変更されてもよい。地震の規模が大きい場合には一連の地震がある程度の時間を空けて発生する場合がある。そこで、例えば地震の震度が７などの基準震度より大きい場合には、所定時間が基準の６時間から１０時間に変更されてもよい。この場合、災害情報テーブル４４２に格納された地震情報が削除される所定時間も同様に基準の６時間から１０時間に変更される。この所定時間の変更は、オペレーターの操作により行われてもよし、オペレーターの操作を介さずにセンター装置４０により自動的に行われてもよい。これにより、地震の規模が大きい場合に一連の地震がある程度の時間を空けて発生しても、この地震を一連の地震と判定することができる。
【0113】
３－３．変形例３
上述した実施形態において、一連の地震の判定条件および余震の判定条件は、機械学習などのＡＩ（Artificial Intelligence）を利用して生成または更新されてもよい。これにより、一連の地震および余震を判定する精度が向上する。
上述した実施形態において、一連の地震の判定条件および余震の判定条件は、機械学習などのＡＩ（Artificial Intelligence）を利用して生成または更新されてもよい。これにより、一連の地震および余震を判定する精度が向上する。
【0114】
３－４．変形例４
上述した実施形態で説明した安否確認システム１、サーバー装置１０、管理者端末２０、利用者端末３０、センター装置４０の構成、機能、動作は例示であり、これに限定されない。サーバー装置１０、管理者端末２０、利用者端末３０、センター装置４０は、上述した装置または部位を１つまたは複数含むように構成されてもよいし、一部の装置または部位を含まずに構成されてもよい。サーバー装置１０、管理者端末２０、利用者端末３０、センター装置４０の機能の少なくとも一部を他の装置が有してもよい。また、安否確認システム１、サーバー装置１０、管理者端末２０、利用者端末３０、センター装置４０の動作手順は、矛盾の無い限り、順序が入れ替えられてもよいし、一部の動作手順が省略されてもよい。
上述した実施形態で説明した安否確認システム１、サーバー装置１０、管理者端末２０、利用者端末３０、センター装置４０の構成、機能、動作は例示であり、これに限定されない。サーバー装置１０、管理者端末２０、利用者端末３０、センター装置４０は、上述した装置または部位を１つまたは複数含むように構成されてもよいし、一部の装置または部位を含まずに構成されてもよい。サーバー装置１０、管理者端末２０、利用者端末３０、センター装置４０の機能の少なくとも一部を他の装置が有してもよい。また、安否確認システム１、サーバー装置１０、管理者端末２０、利用者端末３０、センター装置４０の動作手順は、矛盾の無い限り、順序が入れ替えられてもよいし、一部の動作手順が省略されてもよい。
【0115】
３－５．変形例５
本発明の別の形態は、安否確認システム１、サーバー装置１０、管理者端末２０、利用者端末３０、およびセンター装置４０のうち少なくともいずれかにおいて行われる動作のステップを有する方法を提供してもよい。また、本発明のさらに別の形態は、サーバー装置１０、管理者端末２０、利用者端末３０、またはセンター装置４０において実行されるプログラムを提供してもよい。このプログラムは、コンピュータが読み取り可能な記録媒体に記憶されて提供されてもよいし、インターネット等を介したダウンロードによって提供されてもよい。
本発明の別の形態は、安否確認システム１、サーバー装置１０、管理者端末２０、利用者端末３０、およびセンター装置４０のうち少なくともいずれかにおいて行われる動作のステップを有する方法を提供してもよい。また、本発明のさらに別の形態は、サーバー装置１０、管理者端末２０、利用者端末３０、またはセンター装置４０において実行されるプログラムを提供してもよい。このプログラムは、コンピュータが読み取り可能な記録媒体に記憶されて提供されてもよいし、インターネット等を介したダウンロードによって提供されてもよい。
【0116】
３－６．変形例６
上述した実施形態において、取得部４１１により取得された地震情報が先行地震に関する続報である場合にも、送信部４１４は上述した震度変更処理と同様に、先行地震と対象地震との安否確認の対象の差分に安否確認通知を送信し、先行地震に応じて既に安否確認通知が送信された利用者端末３０には安否確認通知を送信しなくてもよい。地震情報が先行地震に関する続報であるか否かの判定は、その地震情報のイベントＩＤ（識別情報）およびシリアルナンバー（情報番号）により行われる。例えば災害管理テーブル４４１に格納された先行地震のイベントＩＤが対象地震のイベントＩＤと同一である場合、対象地震は先行地震と同一の地震であることを意味する。対象地震と先行地震とが同一の地震である場合において、災害管理テーブル４４１に格納された対象地震のシリアルナンバーが、先行地震のシリアルナンバーより後の数字である場合には、対象地震の地震情報が先行地震の続報であることを示す。この変形例によれば、対象地震が先行地震と一連の地震である場合には、先行地震と対象地震との安否確認の対象の差分となる顧客の利用者端末３０に安否確認通知が送信されるため、先行地震に応じて既に安否確認通知が送信された利用者端末３０に対して、対象地震に応じて再び安否確認通知が送信されるのを防止することができる。
上述した実施形態において、取得部４１１により取得された地震情報が先行地震に関する続報である場合にも、送信部４１４は上述した震度変更処理と同様に、先行地震と対象地震との安否確認の対象の差分に安否確認通知を送信し、先行地震に応じて既に安否確認通知が送信された利用者端末３０には安否確認通知を送信しなくてもよい。地震情報が先行地震に関する続報であるか否かの判定は、その地震情報のイベントＩＤ（識別情報）およびシリアルナンバー（情報番号）により行われる。例えば災害管理テーブル４４１に格納された先行地震のイベントＩＤが対象地震のイベントＩＤと同一である場合、対象地震は先行地震と同一の地震であることを意味する。対象地震と先行地震とが同一の地震である場合において、災害管理テーブル４４１に格納された対象地震のシリアルナンバーが、先行地震のシリアルナンバーより後の数字である場合には、対象地震の地震情報が先行地震の続報であることを示す。この変形例によれば、対象地震が先行地震と一連の地震である場合には、先行地震と対象地震との安否確認の対象の差分となる顧客の利用者端末３０に安否確認通知が送信されるため、先行地震に応じて既に安否確認通知が送信された利用者端末３０に対して、対象地震に応じて再び安否確認通知が送信されるのを防止することができる。
【0117】
３－７．変形例７
上述した実施形態において、一連の地震の判定条件には先行地震の被災地が対象地震の被災地の隣接地域内であるという条件が含まれているが、この条件は対象地震の被災地が先行地震の被災地の隣接地域内であるという条件でもよい。すなわち、この条件は先行地震の被災地および対象地震の被災地のうち一方の被災地が他方の被災地の隣接地域内であるという条件であればよい。この変形例に係る構成でも先行地震と一連の地震を判定する精度が向上する。
上述した実施形態において、一連の地震の判定条件には先行地震の被災地が対象地震の被災地の隣接地域内であるという条件が含まれているが、この条件は対象地震の被災地が先行地震の被災地の隣接地域内であるという条件でもよい。すなわち、この条件は先行地震の被災地および対象地震の被災地のうち一方の被災地が他方の被災地の隣接地域内であるという条件であればよい。この変形例に係る構成でも先行地震と一連の地震を判定する精度が向上する。
【符号の説明】
【0118】
１：安否確認システム、１０：サーバー装置、２０：管理者端末、２１：表示部、３０：利用者端末、３１：表示部、４０：センター装置、４１：制御部、４２：第１通信部、４３：第２通信部、４４：記憶部、４５：入力部、４６：表示部、４１１：取得部、４１２：対象判定部、４１３：特定部、４１４：送信部、４１５：表示制御部、４１６：記憶部更新部
【要約】
【課題】先行地震と一連の地震が発生した場合にも、安否確認が繰り返し行われることによる利用者の煩わしさを軽減する。
【解決手段】安否確認システムは、対象地震に関する地震情報を取得する取得部４１１と、取得された地震情報に関する対象地震が、既に安否確認通知が送信された先行地震と一連の地震ではない場合には、対象地震に応じた安否確認の対象の利用者端末に安否確認通知を送信し、対象地震が先行地震と一連の地震である場合には、先行地震に応じて既に安否確認通知が送信された利用者端末に安否確認通知を送信しない送信部４１４とを備える。
【選択図】図２
【解決手段】安否確認システムは、対象地震に関する地震情報を取得する取得部４１１と、取得された地震情報に関する対象地震が、既に安否確認通知が送信された先行地震と一連の地震ではない場合には、対象地震に応じた安否確認の対象の利用者端末に安否確認通知を送信し、対象地震が先行地震と一連の地震である場合には、先行地震に応じて既に安否確認通知が送信された利用者端末に安否確認通知を送信しない送信部４１４とを備える。
【選択図】図２
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】