特許 7562902 安否確認システム

(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

【請求項の数】 5

(21)【出願番号】P 2024088308

(22)【出願日】2024-05-30

【審査請求日】2024-05-31

【早期審査対象出願】

(73)【特許権者】

【識別番号】500287710

【氏名又は名称】セコムトラストシステムズ株式会社

(74)【代理人】

【識別番号】110000752

【氏名又は名称】弁理士法人朝日特許事務所

(72)【発明者】

【氏名】越尾 俊明

(72)【発明者】

【氏名】川上 貴志

【審査官】神田 泰貴

(56)【参考文献】

【文献】特開２０２４－０８３８８０（ＪＰ，Ａ）

【文献】特開２０２０－０９１５７０（ＪＰ，Ａ）

【文献】特開２０２０－０４７０３４（ＪＰ，Ａ）

【文献】特開２０２４－０９９２２５（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ ５０／００ － ５０／２０

Ｇ０６Ｑ ５０／２６ － ９９／００

Ｇ１６Ｚ ９９／００

Ｇ０６Ｑ １０／００ － １０／３０

Ｇ０６Ｑ ３０／００ － ３０／０８

Ｇ０８Ｂ ２３／００ － ３１／００

(57)【特許請求の範囲】

【請求項1】

災害が発生すると、前記災害に関する速報および確定報を取得する取得部と、
前記速報を取得すると管理者端末に安否確認の予告通知を送信する予告送信部と、
前記確定報を取得すると安否確認の対象となる利用者端末に安否確認通知を送信する本送信部と
を備える安否確認システム。

【請求項2】

前記予告送信部が予告通知を送信すると、前記安否確認通知を送信するための管理者の操作を受け付ける画面に関連付けて、前記確定報に基づき前記安否確認通知が送信されることを示す注意情報を、前記管理者端末に表示させる表示制御部をさらに備える
請求項１に記載の安否確認システム。

【請求項3】

前記本送信部は、前記予告通知の送信対象エリアと前記安否確認通知の送信対象エリアとを比較可能に示す対象エリア情報を前記管理者端末に送信する
請求項１に記載の安否確認システム。

【請求項4】

前記速報は、一の災害に関する複数の速報を含み、
前記予告送信部は、前記複数の速報のうち最初に取得した速報については前記予告通知を送信し、その後に取得した速報については前記予告通知を送信しない
請求項１に記載の安否確認システム。

【請求項5】

前記予告送信部は前記速報に応じた安否確認の対象の管理者端末に安否確認の予告通知を送信し、
前記本送信部は、前記速報に応じた前記安否確認の対象に含まれ、前記確定報に応じた前記安否確認の対象に含まれない差分が生じる場合には、対象に含まれなくなった管理者端末に送信済である前記予告通知の取消通知を送信する
請求項１に記載の安否確認システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、災害が発生した際に、会社等の顧客組織に属する人物の現状態を確認する安否確認システムに関する。特に、顧客組織と協働しつつ、事業者が顧客組織を代行して安否確認を行う安否確認システムに関する。

【背景技術】

【0002】

地震等の災害の発生時に、センター装置から安否確認通知を顧客組織の利用者に送信し、安否を確認する安否確認システムが知られている（例えば特許文献１）。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０２１－１４４２９３号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

地震等の災害が発生した場合、気象庁等の機関からまず速報が発表され、その後に確定報が発表される。事業者は、不用意な安否確認を減らすために、信頼性の高い確定報に基づき安否確認を行っていた。この場合、速報の発表から安否確認通知の送信までに数分のタイムラグが生じる。テレビやスマートフォンを通じて提供される速報から災害が発生したことを知った顧客組織の管理者は、このタイムラグの間に安否確認通知が代行送信されるかどうか不安になる。このため、顧客組織の管理者は、安否確認通知の事業者へ問い合せたり、速報に基づき自ら安否確認通知などを行ったりすることがある。これにより、顧客組織の管理者の負担が増え、利用者にとっては不用意な状態での安否確認通知や重複した安否確認通知がなされるなどの課題がある。

【0005】

本発明は、災害の確定報に基づいて安否確認通知を送信する構成を採用した場合に生じ得るかかる課題を解決し、顧客の管理者および利用者の負担を減らすことを目的とする。

【課題を解決するための手段】

【0006】

本発明の一態様は、災害が発生すると、前記災害に関する速報および確定報を取得する取得部と、前記速報を取得すると管理者端末に安否確認の予告通知を送信する予告送信部と、前記確定報を取得すると安否確認の対象となる利用者端末に安否確認通知を送信する本送信部とを備える安否確認システムを提供する。

【0007】

前記安否確認システムは、前記予告送信部が予告通知を送信すると、前記安否確認通知を送信するための管理者の操作を受け付ける画面に関連付けて、前記確定報に基づき前記安否確認通知が送信されることを示す注意情報を、前記管理者端末に表示させる表示制御部をさらに備えてもよい。

【0008】

前記本送信部は、前記予告通知の送信対象エリアと前記安否確認通知の送信対象エリアとを比較可能に示す対象エリア情報を前記管理者端末に送信してもよい。

【0009】

前記速報は、一の災害に関する複数の速報を含み、前記予告送信部は、前記複数の速報のうち最初に取得した速報については前記予告通知を送信し、その後に取得した速報については前記予告通知を送信しなくてもよい。

【0010】

前記予告送信部は前記速報に応じた安否確認の対象の管理者端末に安否確認の予告通知を送信し、前記本送信部は、前記速報に応じた前記安否確認の対象に含まれ、前記確定報に応じた前記安否確認の対象に含まれない差分が生じる場合には、対象に含まれなくなった管理者端末に送信済である前記予告通知の取消通知を送信してもよい。

【発明の効果】

【0011】

本発明によれば、確定報に基づいて安否確認通知を送信する構成を採用した場合に生じ得る管理者の手間を減らすことができる。また、利用者に対し、同一の災害において、不用意に安否確認通知が複数回も送信されるのを防止できる。

【図面の簡単な説明】

【0012】

【図1】実施形態に係る安否確認システムの構成例を示す図。

【図2】センター装置の構成例を示す図。

【図3】気象庁から受信する地震の電文を例示する図。

【図4】災害管理テーブルを例示する図。

【図5】災害情報テーブルを例示する図。

【図6】条件管理テーブルを例示する図。

【図7】顧客情報テーブルを例示する図。

【図8】代行送信予告テーブルを例示する図。

【図9】震度速報受信時のセンター装置の動作例を示すフローチャート。

【図10】安否確認の代行送信予告通知を例示する図。

【図11】地震情報受信時のセンター装置の動作例を示すフローチャート。

【図12】オペレーター画面の表示例を示す図。

【図13】安否確認通知を例示する図。

【図14】災害通知を例示する図。

【図15】代行送信通知を例示する図。

【図16】管理者画面の表示例を示す図。

【図17】変形例に係る対象エリア情報を例示する図。

【図18】安否状況の集計画面および一覧画面を例示する図。

【発明を実施するための形態】

【0013】

１．構成
図１は、実施形態に係る安否確認システム１の構成例を示す図である。安否確認システム１は、災害の発生時に利用者に安否確認通知を送信し、利用者の安否を確認するためのシステムである。

【0014】

安否確認システム１は、サーバー装置１０と、複数の管理者端末２０と、複数の利用者端末３０と、センター装置４０とを備える。サーバー装置１０とセンター装置４０とは、通信回線５０を介して接続されている。通信回線５０は、例えば専用回線である。センター装置４０と各管理者端末２０と各利用者端末３０とは、通信回線６０を介して接続されている。通信回線６０には、例えばインターネットと移動体通信網とが含まれる。なお、図１では管理者端末２０が複数示されているが、管理者端末２０の数は複数に限定されず、１台でもよい。

【0015】

サーバー装置１０は、気象庁により運営、管理される。サーバー装置１０は、災害が発生すると、気象庁により発表された災害情報に応じた電文をセンター装置４０に配信する。この電文には、速報と確定報とが含まれる。速報とは、災害が発生した際にその後の被害予測をいち早く知らせる情報をいう。例えば地震であれば震度速報であり、火山の噴火であれば降灰予報（速報）がある。確定報とは、速報よりも遅れて報じられるものの、より多い情報に基づいて算出した情報のため精度の高い情報をいう。例えば地震であれば地震情報であり、火山の噴火であれば降灰予報（詳細）がある。

【0016】

この実施形態では、災害が地震であるものとする。地震の場合、電文には震度速報と地震情報とが含まれる。震度速報は、地震の発生を迅速に伝えるために、地震の発生から約１分半後に発表される速報である。地震情報は、地震の発生から約５分後に発表される確定報である。震度速報と地震情報とは、いずれも１つの地震に関する情報であるが、地震情報は震度速報より精度の高い情報である。したがって、震度速報と地震情報とでは、震度や被災地が異なる場合がある。

【0017】

管理者端末２０は、顧客の管理者がセンター装置４０から提供される安否確認に関する各種情報を閲覧するのに用いられる。顧客は、安否確認サービスを契約している企業などの組織である。管理者は、例えば企業などの組織において災害の発生時に従業員の管理を担当する人である。管理者端末２０は、例えば電子メール機能を有し、センター装置４０から安否確認に関する各種通知を電子メールで受信する。また、管理者端末２０は、例えばウェブブラウザ機能を有し、センター装置４０から提供される安否確認に関するウェブ画面をウェブブラウザで表示する。管理者端末２０には、例えばスマートフォン、タブレット端末、ノートパソコンが含まれる。管理者端末２０は表示部２１を備える。表示部２１には、例えば液晶ディスプレイが含まれる。

【0018】

利用者端末３０は、顧客の利用者がセンター装置４０から送信された安否確認通知を閲覧し、安否情報を回答するのに用いられる。利用者は、例えば企業などの組織の従業員である。利用者端末３０は、例えば電子メール機能を有し、センター装置４０から安否確認通知を電子メールで受信する。また、利用者端末３０は、例えばウェブブラウザ機能を有し、ウェブブラウザを通じてセンター装置４０に安否情報を入力する。利用者端末３０には、例えばスマートフォン、タブレット端末、ノートパソコンが含まれる。利用者端末３０は表示部３１を備える。表示部３１には、例えば液晶ディスプレイが含まれる。

【0019】

図２は、センター装置４０の構成例を示す図である。センター装置４０は、安否確認サービスを提供する代行送信事業者により運営、管理される。センター装置４０は、サーバー装置１０から配信された電文に基づいて、顧客に安否確認に関する各種通知を提供する。センター装置４０は、例えば電子メール機能を有し、安否確認に関する各種通知を電子メールで管理者端末２０および利用者端末３０に送信する。また、センター装置４０は、例えばウェブサーバー機能を有し、安否確認に関する各種ウェブ画面を管理者端末２０および利用者端末３０に提供する。センター装置４０は、例えばクラウドサーバーである。ただし、センター装置４０はクラウドサーバーに限定されず、オンプレミスサーバーでもよい。なお、センター装置４０がオンプレミスサーバーである場合、管理者が一人（管理者端末２０が１台）であることも考えられる。センター装置４０は、制御部４１と、第１通信部４２と、第２通信部４３と、記憶部４４と、入力部４５と、表示部４６とを備える。制御部４１は、第１通信部４２、第２通信部４３、記憶部４４、入力部４５、および表示部４６とバスを介して接続されている。

【0020】

制御部４１は、センター装置４０の各部を制御して安否確認サービスを提供するための処理を行う。制御部４１には、例えばＣＰＵ（Central Processing Unit）などのプロセッサと、ＲＯＭ（Read Only Memory）およびＲＡＭ（Random Access Memory）などのメモリとが含まれる。メモリには、センター装置４０の機能を実現するためのプログラムが記憶される。第１通信部４２は、通信回線５０に接続される通信インターフェースである。第１通信部４２は、通信回線５０を介してサーバー装置１０とデータ通信を行う。第１通信部４２には、例えばネットワークアダプタが含まれる。第２通信部４３は、通信回線６０に接続される通信インターフェースである。第２通信部４３は、通信回線６０を介して各管理者端末２０および各利用者端末３０とデータ通信を行う。第２通信部４３には、例えばネットワークアダプタが含まれる。記憶部４４は、災害管理テーブル４４１、災害情報テーブル４４２、条件管理テーブル４４３、顧客情報テーブル４４４、代行送信予告テーブル４４５などの、制御部４１により用いられる各種情報を記憶する。記憶部４４には、例えばハードディスク、ＳＳＤ（Solid State Drive）が含まれる。入力部４５は、センター装置４０への情報の入力に用いられる。入力部４５には、例えばマウス、キーボードが含まれる。表示部４６は、各種情報を表示する。表示部４６には、例えば液晶ディスプレイが含まれる。表示部４６は、代行送信事業者のオペレーターが操作するオペレーター端末の表示部でもよい。

【0021】

制御部４１は、取得部４１１と、対象判定部４１２と、特定部４１３と、予告送信部４１４と、表示制御部４１５と、本送信部４１６と、記憶部更新部４１７として機能する。これらの機能は、メモリに記憶されたプログラムと、このプログラムを実行するプロセッサとの協働により、プロセッサが演算を行いまたは他のハードウェア要素の動作を制御することにより実現される。

【0022】

取得部４１１は、地震が発生すると、この地震に関する速報である震度速報および確定報である地震情報をサーバー装置１０から受信して取得する。図３は、気象庁から受信する地震の電文を例示する図である。各電文には、情報名称と、基点時刻と、識別情報と、情報番号と、スキーマの運用種別情報と、見出し文と、防災気象情報要素名と、対象地域・地点名称と、地震発生時刻と、震央地名とが含まれる。情報名称は電文のタイトルである。基点時刻は地震が発生した時刻である。震度速報では基点時刻が用いられるが、地震情報では地震発生時刻が用いられる。識別情報は地震を一意に識別するイベントＩＤである。１つの地震につき１つのイベントＩＤが付与される。情報番号は同一の地震に関する地震情報以降の電文の配信順序を示すシリアルナンバーである。シリアルナンバーは同一の地震に関する最初の確定報である最初の地震情報以降の電文に連番で付与される。シリアルナンバーは震度速報には付与されない。スキーマの運用種別情報は電文が震度速報か地震情報かを示すものである。見出し文は電文の概要を示す情報である。防災気象情報要素名は震度を表す。対象地域・地点名称は災害が発生した地域・地点（被災地）を表す。１つの震度に対して複数地域・地点が列挙されることがある。地震発生時刻は確定報である地震情報においてのみセットされる、確定した地震発生時刻である。震央地名は確定報である地震情報においてのみセットされる、確定した震央地を表す。

【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】

１：安否確認システム、１０：サーバー装置、２０：管理者端末、２１：表示部、３０：利用者端末、３１：表示部、４０：センター装置、４１：制御部、４２：第１通信部、４３：第２通信部、４４：記憶部、４５：入力部、４６：表示部、４１１：取得部、４１２：対象判定部、４１３：特定部、４１４：予告送信部、４１５：表示制御部、４１６：本送信部、４１７：記憶部更新部

【要約】

【課題】災害の確定報に基づいて安否確認通知を送信する構成を採用した場合に生じ得る顧客の管理者および利用者の負担を減らす。
【解決手段】安否確認システムは、災害が発生すると、災害に関する速報および確定報を取得する取得部４１１と、速報を取得すると管理者端末に安否確認の予告通知を送信する予告送信部４１４と、確定報を取得すると安否確認の対象となる利用者端末に安否確認通知を送信する本送信部４１６とを備える。
【選択図】図２

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】