(57)【特許請求の範囲】
【請求項１】
ユーザーが携帯する携帯端末と通信可能に接続された安否確認サーバーであって、
前記携帯端末にインストールされ、電子メールよりも操作が容易なアプリケーションを通じて、前記ユーザーに無事を問い合わせる第１問い合わせ部と、
前記アプリケーションを用いた前記ユーザーからの回答の有無を確認する第１確認部と、
前記第１確認部による確認に基づいて前記ユーザーからの回答が無いことを確定した場合、さらに、電子メールを介して、前記ユーザーの無事を問い合わせる第２問い合わせ部と、
前記電子メールを用いた前記ユーザーからの回答の有無を確認する第２確認部と、
を備える安否確認サーバー。
【請求項２】
前記第１問い合わせ部は、複数回の前記問い合わせを行い、
前記第１確認部は、前記複数回の問い合わせのいずれに対しても回答が無い場合に、ユーザーからの回答が無いことを確定する、請求項１に記載の安否確認サーバー。
【請求項３】
前記第１確認部は、前記第１問い合わせ部による問い合わせから所定時間が経過するまでに回答が無い場合に、ユーザーからの回答が無いことを確定する、請求項１に記載の安否確認サーバー。
【請求項４】
複数のユーザーの滞在地および滞在期間を記憶している記憶部をさらに備え、
前記第１問い合わせ部は、管理者から安否確認の対象となる地域および日時の指定を受け付けた場合に、前記記憶部に記憶されている前記滞在地および前記滞在期間を参照して、前記複数のユーザーのうち前記管理者により指定された地域および日時に滞在しているユーザーに対して問い合わせを行う、請求項１〜３のいずれか一項に記載の安否確認サーバー。
【請求項５】
前記アプリケーションを用いた前記ユーザーの回答は、前記携帯端末においてユーザー自身が無事である旨の回答をするためのボタンをタッチする操作によって行われる、請求項１〜４のいずれか一項に記載の安否確認サーバー。
【請求項６】
前記電子メールには、ユーザー自身が無事である旨を回答するサーバーの場所を示すＵＲＬ情報が含まれる、請求項１〜５のいずれか一項に記載の安否確認サーバー。
【請求項７】
ユーザーが携帯する携帯端末と、当該携帯端末と通信可能に接続された安否確認サーバーとを備える安否確認システムであって、
前記安否確認サーバーは、
前記携帯端末にインストールされ、電子メールよりも操作が容易なアプリケーションを通じて、前記ユーザーに無事を問い合わせる第１問い合わせ部、を備え、
前記携帯端末の前記アプリケーションは、
前記安否確認サーバーから前記問い合わせを受け付けると、ユーザー自身が無事である旨を回答するためのボタンを表示し、前記ボタンをタッチする操作を前記ユーザーから受け付けたときに、ユーザー自身が無事である旨の回答を前記安否確認サーバーへ通知し、
前記安否確認サーバーは、
前記アプリケーションを用いた前記ユーザーからの回答の有無を確認する第１確認部と、
前記第１確認部による確認に基づいて前記ユーザーからの回答が無いことを確定した場合、さらに、電子メールを介して、前記ユーザーの無事を問い合わせる第２問い合わせ部と、
前記電子メールを用いた前記ユーザーからの回答の有無を確認する第２確認部と、
を備える安否確認システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、安否確認サーバー、および安否確認システムに関する。
【背景技術】
【０００２】
大学や企業等は、所属するユーザー（学生や社員等）が学会、留学、研修等で一時的に滞在している地域に、重大な災害が発生した時には、そのユーザーの安否を迅速かつ正確に確認する必要がある。安否確認の方法としては、被災した可能性があるユーザーと電話や電子メールによって直接連絡をとる方法がある。
【０００３】
しかし、重大な災害が発生した時には、電話がつながりにくくなり、電子メールもサーバーによっては送受信できなくなることが知られている。
【０００４】
この問題を解消すべく、電話や電子メールを使用しない方法によって、ユーザーの安否確認が可能なシステムが開発されるようになった。たとえば、特許文献１には、特定のアプリケーション（ＳＮＳ：Ｓｏｃｉａｌ  Ｎｅｔｗｏｒｋｉｎｇ  Ｓｅｒｖｉｃｅ等）を用いて、被災したユーザーに対し安否確認を行うことが記載されている。そして、この安否確認に対して回答しない未回答ユーザーがいる場合には、その未回答ユーザーの近くにいる他のユーザーに、未回答ユーザーの安否を連絡させている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１３−２５５０１８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかし、引用文献１には、安否確認に対して回答する際に、ユーザーがどのような作業を行うのか具体的に記載されていない。そのため、ログインＩＤやパスワードの入力、ユーザー自身が無事である旨のメッセージ等の入力、当該メッセージを通知する宛先の入力等が必要である場合には、安否確認に応じるための作業（携帯端末の操作）にかかるユーザーの負担が大きくなる。
【０００７】
また、引用文献１において、未回答ユーザーの近くにいる他のユーザーを探すためには、当該未回答ユーザーから位置情報が提供される必要がある。しかし、個人情報保護の観点から、位置情報を提供しないように設定しているユーザーもいる。この場合には、未回答ユーザーの近くにいる他のユーザーを探すことができず、未回答ユーザーの安否を確認することができない。仮に、未回答ユーザーが位置情報を提供するように設定していたとしても、他のユーザーが被災地で未回答ユーザーの安否を確認できるという保証はない。
【０００８】
本発明は、上記事情に鑑みてなされたものであり、より容易かつ確実に、被災地に滞在しているユーザーの安否を確認できる安否確認サーバー等を提供することを目的とする。
【課題を解決するための手段】
【０００９】
上記の課題を解決するために、本発明の安否確認サーバーは、ユーザーが携帯する携帯端末と通信可能に接続された安否確認サーバーであって、前記携帯端末にインストールされ、電子メールよりも操作が容易なアプリケーションを通じて、前記ユーザーに無事を問い合わせる第１問い合わせ部と、前記アプリケーションを用いた前記ユーザーからの回答の有無を確認する第１確認部と、前記第１確認部による確認に基づいて前記ユーザーからの回答が無いことを確認した場合、さらに、電子メールを介して、前記ユーザーの無事を問い合わせる第２問い合わせ部と、前記電子メールを用いた前記ユーザーからの回答の有無を確認する第２確認部と、を備える。
【発明の効果】
【００１０】
本発明によれば、被災したユーザーにかかる負担が少ない方法（アプリケーションを用いた安否確認、電子メールを用いた安否確認）順で、当該ユーザーの安否確認を段階的に行っている。最初に、ユーザーにかかる負担が最も少ない方法で安否確認を行うため、より多くのユーザーから素早く安否確認に対する回答を得ることができる。
【図面の簡単な説明】
【００１１】
【図１】本実施形態に係る安否確認システムの概略構成例を示す図である。
【図２】安否確認サーバーのハードウェア構成例を示すブロック図である。
【図３】第１携帯端末のハードウェア構成例を示すブロック図である。
【図４】第２携帯端末のハードウェア構成例を示すブロック図である。
【図５】第３携帯端末のハードウェア構成例を示すブロック図である。
【図６】安否確認システムの機能構成例を示すブロック図である。
【図７】ユーザーデータの概略データ構造例を示す図である。
【図８】安否確認データの概略データ構造例を示す図である。
【図９】アプリ登録処理を説明するためのフローチャートである。
【図１０】アプリ登録画面の一例を示す図である。
【図１１】第１安否確認処理を説明するためのフローチャートである。
【図１２】回答結果の表示例を示す図である。
【図１３】第２安否確認処理を説明するためのフローチャートである。
【図１４】第３安否確認処理を説明するためのフローチャートである。
【図１５】アプリケーションによる回答処理を説明するためのフローチャートである。
【図１６】（Ａ）位置情報の提供に関する同意画面の一例を示す図である。（Ｂ）ログイン画面の一例を示す図である。（Ｃ）アプリ登録ＩＤの解除画面の一例を示す図である。
【図１７】（Ａ）トップ画面の一例を示す図である。（Ｂ）メッセージ画面の一例を示す図である。（Ｃ）連絡先の案内画面の一例を示す図である。
【図１８】問い合わせ順序、問い合わせ回数、問い合わせ間隔等に関する設定画面の一例を示す図である。
【発明を実施するための形態】
【００１２】
以下、添付した図面を参照して、本発明の実施形態を説明する。なお、図面の説明において同一の要素には同一の符号を付し、重複する説明を省略する。また、図面の寸法比率は、説明の都合上誇張されており、実際の比率とは異なる場合がある。
【００１３】
＜安否確認システム１０（ハードウェア構成）＞
本実施形態に係る安否確認システム１０は、ユーザーの安否を確認するのに適したシステムである。たとえば、大学や企業等に所属するユーザー（学生や社員等）が、日本国内または海外のいずれかの地域を訪問（滞在）中に、災害等（事故、事件等を含む）が発生する場合がある。本実施形態に係る安否確認システム１０は、そのような災害等に遭遇した可能性があるユーザーの安否を確認するのに適している。
【００１４】
図１は、本実施形態に係る安否確認システムの概略構成例を示す図である。図２は、安否確認サーバーのハードウェア構成例を示すブロック図である。図３は、第１携帯端末のハードウェア構成例を示すブロック図である。図４は、第２携帯端末のハードウェア構成例を示すブロック図である。図５は、第３携帯端末のハードウェア構成例を示すブロック図である。以下、図１〜図５を参照して、安否確認システム１０の概略構成、特にハードウェア構成について説明する。
【００１５】
（１）全体構成
図１に示すように、安否確認システム１０は、安否確認サーバー１００と、少なくとも１台以上の携帯端末２００とを備える。なお、安否確認サーバー１００と携帯端末２００は、インターネット等のコンピューターネットワーク（以下では、単に「ネットワーク３００」と称する）を介して相互に通信可能に接続されている。
【００１６】
安否確認サーバー１００は、災害等に遭遇した可能性があるユーザーの安否（無事）を問い合わせる機能、その問い合わせに対する回答を確認する機能を、少なくとも有する一般的なコンピューターである。これらの機能について、詳細な説明は後述する。
【００１７】
携帯端末２００は、大学や企業等に所属するユーザー（学生や社員等）が訪問（滞在）先に携帯する電子機器である。図１に示す例では、各ユーザーＡ〜Ｄは、それぞれ、１台の携帯端末２００を所持しているが、以下の説明では、各ユーザーが複数台、複数種類の携帯端末２００を所持しているものとして説明する。
【００１８】
また、ユーザーが所持可能な携帯端末２００として、３種類の携帯端末（第１携帯端末２００ａ、第２携帯端末２００ｂ、第３携帯端末２００ｃ）を例に挙げて説明する。ただし、これらの携帯端末は、あくまで例示であり、これらとは異なる種類の携帯端末が用いられてもよい。
【００１９】
第１携帯端末２００ａは、スマートフォン、タブレット型ＰＣ等に代表される電子機器であり、一般的な携帯電話としての機能（通話機能、電子メール機能等）を有しつつ、様々な種類のアプリケーションをインストール可能な多機能携帯電話である。
【００２０】
第２携帯端末２００ｂは、一般的な携帯電話であり、通話機能、電子メール機能等の基本的な機能は有しているが、様々な種類のアプリケーションを自由にインストール（追加等）することはできない。
【００２１】
第３携帯端末２００ｃは、ノートパソコン等に代表される電子機器であり、様々な種類のアプリケーションをインストール可能であるが、電話回線を利用する通話機能は有さない。
【００２２】
（２）安否確認サーバー１００（ハードウェア構成）
次に、安否確認サーバー１００のハードウェア構成について説明する。
【００２３】
図２に示すとおり、安否確認サーバー１００は、制御部１１０と、表示部１２０と、入力部１３０と、通信部１４０とを有する。各部１１０〜１４０は、信号をやり取りするための信号線（バス等）１７０を介して相互に接続されている。
【００２４】
（２−１）制御部１１０
制御部１１０は、安否確認サーバー１００全体を制御する。たとえば、制御部１１０は、図２に示すように、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１１１と、メモリー１１２と、ストレージ１１３とを有する。
【００２５】
ＣＰＵ１１１は、プログラムにしたがって上記各部１２０〜１４０の制御や各種の演算処理を実行するマルチコアのプロセッサ等から構成される制御回路であり、安否確認サーバー１００の各機能は、それに対応するプログラムをＣＰＵ１１１が実行することにより発揮される。
【００２６】
メモリー１１２は、作業領域として一時的にプログラムおよびデータを記憶する高速アクセス可能な主記憶装置である。メモリー１１２には、たとえば、ＤＲＡＭ（Ｄｙｎａｍｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、ＳＤＲＡＭ（Ｓｙｎｃｈｒｏｎｏｕｓ  Ｄｙｎａｍｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、ＳＲＡＭ（Ｓｔａｔｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）等が採用される。
【００２７】
ストレージ１１３は、オペレーティングシステムを含む各種プログラムや各種データを格納する大容量の補助記憶装置である。ストレージ１１３には、たとえば、ハードディスク、ソリッドステートドライブ、フラッシュメモリー、ＲＯＭ等が採用される。
【００２８】
（２−２）表示部１２０
表示部１２０は、安否確認サーバー１００における各種の操作画面、設定画面等を表示する。たとえば、表示部１２０には、液晶ディスプレイ、有機ＥＬ（Ｅｌｅｃｔｒｏ−Ｌｕｍｉｎｅｓｃｅｎｃｅ）ディスプレイ等が採用される。
【００２９】
（２−３）入力部１３０
入力部１３０は、安否確認サーバー１００を管理する管理者等が各種情報を入力するために用いられる。たとえば、入力部１３０には、キーボード、マウス等のポインティングデバイスが採用される。
【００３０】
（２−４）通信部１４０
通信部１４０は、ネットワーク３００を介して携帯端末２００と通信するためのインターフェイスである。たとえば、通信部１４０は、携帯端末２００に対してユーザーの安否を問い合わせるための信号や、その問い合わせに対する回答を含む信号等、各種信号の送受信を行う。
【００３１】
（３）第１携帯端末２００ａ（ハードウェア構成）
次に、第１携帯端末２００ａのハードウェア構成について説明する。
【００３２】
図３に示すとおり、第１携帯端末２００ａは、制御部２１０ａと、タッチパネル部２２５ａと、通信部２４０ａと、通話部２５０ａと、ＧＰＳ受信部２６０ａとを有する。各部２１０ａ〜２６０ａは、信号をやり取りするための信号線２７０ａを介して相互に接続されている。
【００３３】
（３−１）制御部２１０ａ
制御部２１０ａは、第１携帯端末２００ａ全体を制御する。たとえば、制御部２１０ａは、図３に示すように、ＣＰＵ２１１ａと、メモリー２１２ａと、ストレージ２１３ａとを有する。
【００３４】
ＣＰＵ２１１ａは、プログラムにしたがって上記各部２２５ａ〜２６０ａの制御や各種の演算処理を実行するプロセッサ等から構成される制御回路であり、第１携帯端末２００ａの各機能は、それに対応するプログラムをＣＰＵ２１１ａが実行することにより発揮される。
【００３５】
メモリー２１２ａは、作業領域として一時的にプログラムおよびデータを記憶する高速アクセス可能な主記憶装置である。メモリー２１２ａには、たとえば、ＤＲＡＭ、ＳＲＡＭ等が採用される。
【００３６】
ストレージ２１３ａは、オペレーティングシステムを含む各種プログラムや各種データを格納する比較的容量の大きい補助記憶装置である。ストレージ２１３ａには、たとえば、フラッシュメモリー等が採用される。
【００３７】
（３−２）タッチパネル部２２５ａ
タッチパネル部２２５ａは、液晶ディスプレイ等のディスプレイの表示面側に貼られた透過性のある操作パネルである。タッチパネル部２２５ａは、ディスプレイに表示された画像のＸＹ座標と対応したタッチ位置を特定し、タッチ位置を座標に変換して出力する。なお、タッチパネル部２２５ａは、感圧式または静電式の入力検出素子などにより構成される。
【００３８】
（３−３）通信部２４０ａ
通信部２４０ａは、ネットワーク３００を介して安否確認サーバー１００と通信するためのインターフェイスである。たとえば、通信部２４０ａは、安否確認サーバー１００との間で、各種データの送受信を行う。
【００３９】
（３−４）通話部２５０ａ
通話部２５０ａは、電話回線を通じて、他の携帯電話（第１携帯端末２００ａ、第２携帯端末２００ｂ等）と通話可能に構成されている。たとえば、通話部２５０ａは、送受信アンテナ、符号化部、復号化部を備え、携帯端末用の無線基地局との間で無線通信を行う。また、通話部２５０ａは、Ａ／Ｄ変換器、Ｄ／Ａ変換器を備え、無線通信により受信した信号を音声信号に変換してスピーカーに出力させたり、マイクロフォンが集音した音に基づく音声信号を無線通信用の信号に変換して出力したりする。
【００４０】
（３−５）ＧＰＳ受信部２６０ａ
ＧＰＳ受信部２６０ａは、３個以上のＧＰＳ衛星からの信号を受信する。ＧＰＳ受信部２６０ａにより受信された信号に基づいて、第１携帯端末２００ａと各ＧＰＳ衛星間の距離とその距離の変化率が測定されることにより、第１携帯端末２００ａの位置（すなわち、ユーザーの位置）が検出される。ここで、ＧＰＳは、Ｇｌｏｂａｌ  Ｐｏｓｉｔｉｏｎｉｎｇ  Ｓｙｓｔｅｍの略称である。
【００４１】
（４）第２携帯端末２００ｂ（ハードウェア構成）
次に、第２携帯端末２００ｂのハードウェア構成について説明する。
【００４２】
図４に示すとおり、第２携帯端末２００ｂは、制御部２１０ｂと、表示部２２０ｂと、入力部２３０ｂと、通信部２４０ｂと、通話部２５０ｂと、ＧＰＳ受信部２６０ｂとを有する。各部２１０ｂ〜２６０ｂは、信号をやり取りするための信号線２７０ｂを介して相互に接続されている。
【００４３】
（４−１）制御部２１０ｂ
制御部２１０ｂは、第２携帯端末２００ｂ全体を制御する。たとえば、制御部２１０ｂは、図４に示すように、ＣＰＵ２１１ｂと、メモリー２１２ｂと、ストレージ２１３ｂとを有する。
【００４４】
ＣＰＵ２１１ｂは、プログラムにしたがって上記各部２２０ｂ〜２６０ｂの制御や各種の演算処理を実行するプロセッサ等から構成される制御回路であり、第２携帯端末２００ｂの各機能は、それに対応するプログラムをＣＰＵ２１１ｂが実行することにより発揮される。
【００４５】
メモリー２１２ｂは、作業領域として一時的にプログラムおよびデータを記憶する高速アクセス可能な主記憶装置である。メモリー２１２ｂには、たとえば、ＤＲＡＭ、ＳＲＡＭ等が採用される。
【００４６】
ストレージ２１３ｂは、オペレーティングシステムを含む各種プログラムや各種データを格納する比較的容量の大きい補助記憶装置である。ストレージ２１３ｂには、たとえば、フラッシュメモリー等が採用される。
【００４７】
（４−２）表示部２２０ｂ
表示部２２０ｂは、第２携帯端末２００ｂにおける各種の操作画面、設定画面等を表示する。たとえば、表示部２２０ｂには、液晶ディスプレイ等が採用される。
【００４８】
（４−３）入力部２３０ｂ
入力部２３０ｂは、第２携帯端末２００ｂを所持するユーザー等が各種情報を入力するために用いられる。たとえば、入力部２３０ｂには、電源のオン、オフや、電話番号の入力等を行うための物理的なボタンやスイッチが採用される。
【００４９】
（４−４）通信部２４０ｂ
通信部２４０ｂは、ネットワーク３００を介して安否確認サーバー１００と通信するためのインターフェイスである。たとえば、通信部２４０ｂは、安否確認サーバー１００との間で、各種データの送受信を行う。
【００５０】
（４−５）通話部２５０ｂ
通話部２５０ｂは、第１携帯端末２００ａの通話部２５０ａと同様に、電話回線を通じて、他の携帯電話（第１携帯端末２００ａ、第２携帯端末２００ｂ等）と通話可能に構成されている。
【００５１】
（４−６）ＧＰＳ受信部２６０ｂ
ＧＰＳ受信部２６０ｂは、第１携帯端末２００ａのＧＰＳ受信部２６０ａと同様に、３個以上のＧＰＳ衛星からの信号を受信して、第２携帯端末２００ｂの位置（すなわち、ユーザーの位置）を検出する。
【００５２】
（５）第３携帯端末２００ｃ（ハードウェア構成）
次に、第３携帯端末２００ｃのハードウェア構成について説明する。
【００５３】
図５に示すとおり、第３携帯端末２００ｃは、制御部２１０ｃと、表示部２２０ｃと、入力部２３０ｃと、通信部２４０ｃとを有する。各部２１０ｃ〜２４０ｃは、信号をやり取りするための信号線２７０ｃを介して相互に接続されている。
【００５４】
（５−１）制御部２１０ｃ
制御部２１０ｃは、第３携帯端末２００ｃ全体を制御する。たとえば、制御部２１０ｃは、図５に示すように、ＣＰＵ２１１ｃと、メモリー２１２ｃと、ストレージ２１３ｃとを有する。
【００５５】
ＣＰＵ２１１ｃは、プログラムにしたがって上記各部２２０ｃ〜２４０ｃの制御や各種の演算処理を実行するプロセッサ等から構成される制御回路であり、第３携帯端末２００ｃの各機能は、それに対応するプログラムをＣＰＵ２１１ｃが実行することにより発揮される。
【００５６】
メモリー２１２ｂは、作業領域として一時的にプログラムおよびデータを記憶する高速アクセス可能な主記憶装置である。メモリー２１２ｂには、たとえば、ＤＲＡＭ、ＳＤＲＡＭ、ＳＲＡＭ等が採用される。
【００５７】
ストレージ２１３ｂは、オペレーティングシステムを含む各種プログラムや各種データを格納する大容量の補助記憶装置である。ストレージ２１３ｂには、たとえば、ハードディスク、フラッシュメモリー、ＲＯＭ等が採用される。
【００５８】
（５−２）表示部２２０ｃ
表示部２２０ｃは、第３携帯端末２００ｃにおける各種の操作画面、設定画面等を表示する。たとえば、表示部２２０ｃには、液晶ディスプレイ等が採用される。
【００５９】
（５−３）入力部２３０ｃ
入力部２３０ｃは、第３携帯端末２００ｃを所持するユーザー等が各種情報を入力するために用いられる。たとえば、入力部２３０ｃには、キーボード、マウスパッド等が採用される。
【００６０】
（５−４）通信部２４０ｃ
通信部２４０ｃは、ネットワーク３００を介して安否確認サーバー１００と通信するためのインターフェイスである。たとえば、通信部２４０ｃは、安否確認サーバー１００との間で、各種データの送受信を行う。
【００６１】
＜安否確認システム１０（機能構成）＞
以上のようなハードウェア構成を有する安否確認システム１０は、以下の機能構成を有する。
【００６２】
図６は、安否確認システムの機能構成例を示すブロック図である。図７は、ユーザーデータの概略データ構造例を示す図である。図８は、安否確認データの概略データ構造例を示す図である。
【００６３】
以下、図６〜図８を参照して、安否確認システム１０に含まれる安否確認サーバー１００の機能構成について説明する。
【００６４】
（１）安否確認サーバー１００
図６に示すとおり、安否確認サーバー１００の制御部１１０は、第１問い合わせ部３１０と、第１確認部３２０と、第２問い合わせ部３３０と、第２確認部３４０と、ユーザーデータ記憶部４００と、安否確認データ記憶部５００とを有する。
【００６５】
（１−１）第１問い合わせ部３１０
第１問い合わせ部３１０は、被災したユーザーが携帯する第１携帯端末２００ａにインストールされ、一般的な電子メールよりも操作が容易な安否確認用のアプリケーション（後述するアプリケーション部６１０）を通じて、当該ユーザーの無事を問い合わせる。
【００６６】
（１−２）第１確認部３２０
第１確認部３２０は、第１問い合わせ部３１０による問い合わせに対する、上記アプリケーションを用いたユーザーの回答の有無を確認する。
【００６７】
（１−３）第２問い合わせ部３３０
第２問い合わせ部３３０は、第１確認部３２０によりユーザーからの回答が無いことが確認された場合、さらに、電子メール（後述する電子メール部６２０、６３０）を介して、当該ユーザーの無事を問い合わせる。
【００６８】
（１−４）第２確認部３４０
第２確認部３４０は、第２問い合わせ部３３０による問い合わせに対する、上記電子メールを用いたユーザーの回答の有無を確認する。
【００６９】
（１−５）ユーザーデータ記憶部４００
ユーザーデータ記憶部４００は、図７に示すようなユーザーデータ４１０を記憶する。ユーザーデータ４１０には、大学や企業等に所属するユーザー（学生や社員等）のうち、日本国内または海外のいずれかの地域を訪問（滞在）する予定のユーザーに関するデータが登録される。たとえば、ユーザーデータ４１０には、登録対象のユーザーごとに、ユーザーＩＤ４１１と、ユーザー名４１２と、出発日４１３と、帰宅日４１４と、滞在地４１５と、アプリ登録ＩＤ４１６と、携帯用メールアドレス４１７と、ＰＣ用メールアドレス４１８とが対応づけて記憶される。
【００７０】
ユーザーＩＤ４１１は、ユーザーを特定可能なＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ  Ｄａｔａ）である。
【００７１】
ユーザー名４１２は、ユーザーの名称（たとえば、氏名、ログイン名）を示すデータである。
【００７２】
出発日４１３は、ユーザーが日本国内または海外のいずれかの地域へ向けて出発する日（たとえば、海外を訪問する場合は、出国予定日）を示すデータである。
【００７３】
帰宅日４１４は、ユーザーが日本国内または海外のいずれかの地域から帰宅する日（たとえば、海外を訪問する場合は、帰国予定日）を示すデータである。
【００７４】
滞在地４１５は、ユーザーが訪問（滞在）を予定している地域の名称（たとえば、国名、県名、市町村名、都市名）を示すデータである。
【００７５】
アプリ登録ＩＤ４１６は、安否確認用のアプリケーション（後述するアプリケーション部６１０）を第１携帯端末２００ａにインストール（登録）する際に必要な登録ＩＤである。
【００７６】
携帯用メールアドレス４１７は、ユーザーが所持する第２携帯端末２００ｂにおいて使用可能であって、移動体通信事業者により携帯電話向けに提供された電子メールアドレスである。
【００７７】
ＰＣ用メールアドレス４１８は、ユーザーが所持する第３携帯端末２００ｃにおいて使用可能であって、移動体通信事業者以外から提供された電子メールアドレスである。
【００７８】
なお、ユーザーデータ４１０を登録するタイミングは任意である。たとえば、ユーザーが、日本国内または海外のいずれかの地域を訪問（滞在）するための申請を、大学や企業等に対して行う際に登録される。ただし、アプリ登録ＩＤ４１６については、第１携帯端末２００ａに安否確認用のアプリケーションをインストールする際に登録される。
【００７９】
（１−６）安否確認データ記憶部５００
安否確認データ記憶部５００は、図８に示すような安否確認データ５１０を記憶する。安否確認データ５１０には、被災したユーザーからの安否に関する回答結果が登録される。たとえば、安否確認データ５１０には、被災したユーザーごとに、ユーザーＩＤ５１１と、ユーザー名５１２と、アプリケーションによる問い合わせ回数５１３および回答実績５１４と、携帯用電子メールによる問い合わせ回数５１５および回答実績５１６と、ＰＣ用電子メールによる問い合わせ回数５１７および回答実績５１８とが対応づけて記憶される。
【００８０】
ユーザーＩＤ５１１は、ユーザーデータ４１０のユーザーＩＤ４１１に相当するデータである。
【００８１】
ユーザー名５１２は、ユーザーデータ４１０のユーザー名４１２に相当するデータである。
【００８２】
アプリケーションによる問い合わせ回数５１３は、アプリケーションによる安否の問い合わせ回数を示すデータである。なお、アプリケーションによる問い合わせは、被災したユーザーに限定して実施され、所定回数（たとえば、５回）を上限として、ユーザーの無事が確認できるまで繰り返される。
【００８３】
アプリケーションによる回答実績５１４は、アプリケーションによる安否の問い合わせに対する、ユーザーからの回答の有無を示すデータである。ユーザーの無事が確認されたときに回答「有り」を示すデータが登録され、繰り返し（たとえば、５回）問い合わせてもユーザーの無事が確認できないときに回答「無し」を示すデータが登録される。
【００８４】
携帯用電子メールによる問い合わせ回数５１５は、携帯用電子メールによる安否の問い合わせ回数を示すデータである。なお、携帯用電子メールによる問い合わせは、アプリケーションによってユーザーの無事が確認できなかったユーザーに限定して実施され、所定回数（たとえば、２回）を上限として、ユーザーの無事が確認できるまで繰り返される。
【００８５】
携帯用電子メールによる回答実績５１６は、携帯用電子メールによる安否の問い合わせに対する、ユーザーからの回答の有無を示すデータである。ユーザーの無事が確認されたときに回答「有り」を示すデータが登録され、繰り返し（たとえば、２回）問い合わせてもユーザーの無事が確認できないときに回答「無し」を示すデータが登録される。
【００８６】
ＰＣ用電子メールによる問い合わせ回数５１７は、ＰＣ用電子メールによる安否の問い合わせ回数を示すデータである。なお、ＰＣ用電子メールによる問い合わせは、携帯用電子メールによってユーザーの無事が確認できなかったユーザーに限定して実施され、所定回数（たとえば、２回）を上限として、ユーザーの無事が確認できるまで繰り返される。
【００８７】
ＰＣ用電子メールによる回答実績５１８は、ＰＣ用電子メールによる安否の問い合わせに対する、ユーザーからの回答の有無を示すデータである。ユーザーの無事が確認されたときに回答「有り」を示すデータが登録され、繰り返し（たとえば、２回）問い合わせてもユーザーの無事が確認できないときに回答「無し」を示すデータが登録される。
【００８８】
なお、各機能部３１０〜３４０は、それぞれ、安否確認サーバー１００において、ＣＰＵ１１１がストレージ１１３にインストールされているプログラムをメモリー１１２に読み出して実行することにより実現される。ただし、これに限らず、各機能部３１０〜３４０は、ＡＳＩＣ等のハードウェアにより実現されてもよい。また、ユーザーデータ記憶部４００および安否確認データ記憶部５００は、それぞれ、ストレージ１１３により実現される。
【００８９】
次に、図６を参照して、安否確認システム１０に含まれる第１〜第３携帯端末２００ａ〜ｃの機能構成について説明する。
【００９０】
（２）第１〜第３携帯端末２００ａ〜ｃ
図６に示すとおり、第１携帯端末２００ａの制御部２１０ａは、アプリケーション部６１０を有する。第２携帯端末２００ｂの制御部２１０ｂは、電子メール部６２０を有する。第３携帯端末２００ｃの制御部２１０ｃは、電子メール部６３０を有する。
【００９１】
（２−１）アプリケーション部６１０
アプリケーション部６１０は、第１携帯端末２００ａにインストールされることにより機能する。アプリケーション部６１０を利用している限り、安否確認サーバー１００とやりとりした内容が、他のユーザーや部外者に見られることはなく、個人情報の秘匿性が高い。
【００９２】
アプリケーション部６１０は、安否確認サーバー１００からユーザーの安否に関する問い合わせを受け付けると、ユーザー自身が無事である旨を回答するためのボタンが少なくとも含まれた画面を、タッチパネル部２２５ａに表示する。そして、アプリケーション部６１０は、当該ボタンをタッチする操作をユーザーから受け付けると、ユーザーが無事である旨の回答を安否確認サーバー１００へ通知する。
【００９３】
なお、アプリケーション部６１０は、第１携帯端末２００ａにおいて、ＣＰＵ２１１ａがストレージ２１３ａにインストールされているプログラムをメモリー２１２ａに読み出して実行することにより実現される。
【００９４】
（２−２）電子メール部６２０
電子メール部６２０は、第２携帯端末２００ｂにインストールされており、移動体通信事業者により携帯電話向けに提供された電子メールアドレス宛てに送信された携帯用電子メールを受信する。たとえば、安否確認サーバー１００から送信される携帯用電子メールには、ユーザー自身が無事である旨を回答するサーバー（安否確認サーバー１００でもよい）の場所を示すＵＲＬ情報が含まれている。
【００９５】
なお、電子メール部６２０は、第２携帯端末２００ｂにおいて、ＣＰＵ２１１ｂがストレージ２１３ｂにインストールされているプログラムをメモリー２１２ｂに読み出して実行することにより実現される。
【００９６】
（２−３）電子メール部６３０
電子メール部６３０は、第３携帯端末２００ｃにインストールされており、移動体通信事業者以外から提供された電子メールアドレス宛てに送信されたＰＣ用電子メールを受信する。たとえば、安否確認サーバー１００から送信されるＰＣ用電子メールには、ユーザー自身が無事である旨を回答するサーバー（安否確認サーバー１００でもよい）の場所を示すＵＲＬ情報が含まれている。
【００９７】
なお、電子メール部６３０は、第３携帯端末２００ｃにおいて、ＣＰＵ２１１ｃがストレージ２１３ｃにインストールされているプログラムをメモリー２１２ｃに読み出して実行することにより実現される。
【００９８】
＜安否確認システム１０の動作＞
次に、本実施形態に係る安否確認システム１０の特徴的な動作について説明する。
【００９９】
（１）アプリ登録処理
図９は、アプリ登録処理を説明するためのフローチャートである。図１０は、アプリ登録画面の一例を示す図である。
【０１００】
以下、図９、図１０を参照して、第１携帯端末２００ａにおいて実行されるアプリ登録処理について説明する。
【０１０１】
ユーザーは、訪問（滞在）先に第１携帯端末２００ａを持っていく場合には、事前に安否確認用のアプリケーション（アプリケーション部６１０）を第１携帯端末２００ａにインストールしている必要がある。たとえば、安否確認サーバー１００からは、安否確認用のアプリケーションのインストールをユーザーに促すための電子メール（以下、「促進メール」と称する）が、第１携帯端末２００ａへ送信される。当該促進メールには、安否確認用のアプリケーションを提供しているサーバーへのアクセス情報と、当該アプリケーションのインストールに必要な登録ＩＤ（アプリ登録ＩＤ４１６に相当するＩＤ）とが、少なくとも記載されている。当該促進メールを受信後、第１携帯端末２００ａは、安否確認用のアプリケーションのインストールを開始するタイミングで、図９に示すアプリ登録処理を開始する。また、促進メールを送信する代わりに、同様の内容が記載された書面をユーザーに提示してもよい。
【０１０２】
（ステップＳ１０１）
アプリ登録処理を開始すると、第１携帯端末２００ａは、安否確認用のアプリケーションをダウンロードする。たとえば、第１携帯端末２００ａの制御部２１０ａは、通信部２４０ａを介して、上記促進メールに記載されたアクセス情報によって特定されるサーバーへアクセスし、安否確認用のアプリケーションをダウンロードする。その後、制御部２１０ａは、ダウロードしたアプリケーションをメモリー１１２等に展開して、第１携帯端末２００ａにおいて起動可能なようにインストールする。なお、アプリ登録処理による登録が済まないと、当該アプリケーションは使用（ログイン）できないように設定されている。
【０１０３】
（ステップＳ１０２）
第１携帯端末２００ａは、ステップＳ１０１においてインストールされた安否確認用のアプリケーションを起動する。
【０１０４】
（ステップＳ１０３）
起動後、第１携帯端末２００ａは、アプリケーション部６１０として機能し、アプリ登録画面を、タッチパネル部２２５ａのディスプレイに表示する。アプリ登録画面には、図１０に示すように、登録ＩＤを入力するための入力ボックス７１０と、入力ボックス７１０に入力された登録ＩＤを確定して安否確認サーバー１００へ送信するための登録ボタン７２０と、が少なくとも含まれている。
【０１０５】
（ステップＳ１０４）
アプリ登録画面がタッチパネル部２２５ａのディスプレイに表示されている間、ユーザーは、タッチパネル部２２５ａの操作パネルを操作して、上記促進メールに記載された登録ＩＤ（アプリ登録ＩＤ４１６に相当するＩＤ）を入力する必要がある。
【０１０６】
第１携帯端末２００ａは、アプリケーション部６１０として機能し、登録ＩＤ（アプリ登録ＩＤ４１６）が入力された後に、登録ボタン７２０をタッチする操作がユーザーによって行われたか否か判別する。
【０１０７】
第１携帯端末２００ａは、登録ボタン７２０をタッチする操作が行われていないと判定した場合には（ステップＳ１０４：ＮＯ）、アプリ登録画面の表示を継続しながら、登録ボタン７２０をタッチする操作が行われるまで待機する。一方、第１携帯端末２００ａは、登録ボタン７２０をタッチする操作が行われたと判定した場合には（ステップＳ１０４：ＹＥＳ）、処理をステップＳ１０５に進める。
【０１０８】
（ステップＳ１０５）
第１携帯端末２００ａは、アプリケーション部６１０として機能し、アプリ登録画面の入力ボックス７１０に入力された登録ＩＤを、通信部２４０ａを介して、安否確認サーバー１００へ送信する。これとともに、第１携帯端末２００ａは、第１携帯端末２００ａに固有の識別番号（たとえば、ＩＭＳＩであり、以下、「個体識別番号」と称する）等を、安否確認サーバー１００へ送信する。
【０１０９】
このとき、安否確認サーバー１００は、第１携帯端末２００ａから送信された登録ＩＤを、通信部１４０を介して受信し、ユーザーデータ４１０にアプリ登録ＩＤ４１６として登録する。なお、上記促進メールに記載されていた登録ＩＤと、その促進メールを送信したユーザーのユーザーＩＤ４１１との対応関係は、安否確認サーバー１００において保持されている。そのため、安否確認サーバー１００は、第１携帯端末２００ａから送信された登録ＩＤ（アプリ登録ＩＤ４１６）を参照すれば、ユーザーデータ４１０のどのユーザーＩＤ４１１にその登録ＩＤを対応づけて記憶すべきか判断できる。
【０１１０】
また、図示していないが、安否確認サーバー１００は、第１携帯端末２００ａから送信された個体識別番号を、同ユーザーＩＤ４１１に対応づけておく。
【０１１１】
ステップＳ１０５の処理後、第１携帯端末２００ａは、アプリ登録処理を終了する。
【０１１２】
以上のアプリ登録処理が第１携帯端末２００ａにおいて実行されることにより、第１携帯端末２００ａにインストールされた安否確認用のアプリケーションの登録ＩＤを、安否確認サーバー１００のユーザーデータ４１０にアプリ登録ＩＤ４１６として登録できる。この登録が済めば、安否確認サーバー１００は、ユーザーデータ４１０を参照して、安否確認用のアプリケーションへのログイン許可、不許可を判断できる。
【０１１３】
（２）第１安否確認処理
図１１は、第１安否確認処理を説明するためのフローチャートである。図１２は、回答結果の表示例を示す図である。
【０１１４】
以下、図１１、図１２を参照して、安否確認サーバー１００において実行される第１安否確認処理について説明する。
【０１１５】
安否確認サーバー１００は、災害が発生した後、ユーザーからの指示に基づいて図１１に示す第１安否確認処理を開始する。
【０１１６】
（ステップＳ２０１）
第１安否確認処理を開始すると、安否確認サーバー１００は、第１問い合わせ部３１０として機能し、災害が発生した日時、地域（すなわち、安否確認の対象となる日時、地域）等の指定を管理者等から受け付ける。たとえば、安否確認サーバー１００は、所定の入力画面を表示部１２０に表示し、管理者等が入力部（キーボード、マウス等）１３０を操作することによって、災害が発生した日時、地域等の指定を受け付ける。
【０１１７】
（ステップＳ２０２）
安否確認サーバー１００は、第１問い合わせ部３１０として機能し、大学や企業等に所属する全てのユーザーの中から、被災した虞がある（被災地に滞在している）ユーザーを抽出する。たとえば、安否確認サーバー１００は、ユーザーデータ記憶部４００に記憶されているユーザーデータ４１０（図７参照）を、メモリー１１２等へ読み出す。その後、安否確認サーバー１００は、ステップＳ２０１で入力された日時が出発日４１３から帰宅日４１４までの間であり、かつ、ステップＳ２０１で入力された地域に滞在地４１５が含まれているレコードを、被災した虞があるユーザーのデータとして抽出する。ここで、出発日４１３から帰宅日４１４までの期間は、ユーザーが滞在地４１５に訪問（滞在）している期間（以下、「滞在期間」とも称する）に相当する。
【０１１８】
以下、一例として、災害が「２０１５年２月２０日」に「Ｙ国」で発生した場合について説明する。この場合、図７に示すユーザーデータ４１０からは、「２０１５年２月２０日」が出発日４１３と帰宅日４１４の間にあり、かつ、「Ｙ国」が滞在地４１５に含まれているユーザーＢ、Ｃ、Ｄのレコードが抽出される。
【０１１９】
また、安否確認サーバー１００は、被災した虞があるユーザーを抽出後、当該ユーザーに関するデータを安否確認データ記憶部５００の安否確認データ５１０（図８参照）に登録する。具体的には、安否確認サーバー１００は、被災した虞があるユーザーのデータとして抽出されたレコードに含まれるユーザーＩＤ４１１およびユーザー名４１２を、安否確認データ５１０のユーザーＩＤ５１１およびユーザー名５１２として記憶する。
【０１２０】
（ステップＳ２０３）
安否確認サーバー１００は、第１問い合わせ部３１０として機能し、被災したユーザーが携帯する第１携帯端末２００ａにインストールされた安否確認用のアプリケーション（アプリケーション部６１０）を通じて、当該ユーザーの無事を問い合わせる。たとえば、安否確認サーバー１００は、被災した虞があるユーザーが所有する第１携帯端末２００ａを、そのユーザーのユーザーＩＤ４１１に対応付けられている個体識別番号等に基づいて特定する。そして、安否確認サーバー１００は、特定した第１携帯端末２００ａに対して、ユーザーの無事について問い合わせがあることを通知するための信号（以下では、「問い合わせ信号」と称する）を、通信部１４０を介して送信する。
【０１２１】
なお、被災したユーザーが複数人いる場合には、安否確認サーバー１００は、各ユーザーに対して同様の問い合わせを行う。また、以降のステップＳ２０５までの処理についても、被災したユーザーが複数人いる場合には、安否確認サーバー１００は、各ユーザーに対して同様の処理を行う。
【０１２２】
第１携帯端末２００ａは、安否確認サーバー１００から送信された問い合わせ信号を受信すると、着信音等によってユーザーに通知する。ユーザーが無事である場合には、ユーザーの操作に基づき、無事である旨の回答がアプリケーション（アプリケーション部６１０）を通じて、安否確認サーバー１００へ通知される。この処理については、後述する（図１５に示す回答処理）。
【０１２３】
（ステップＳ２０４）
安否確認サーバー１００は、第１確認部３２０として機能し、第１問い合わせ部３１０による問い合わせに対する、上記アプリケーション（アプリケーション部６１０）を用いたユーザーの回答の有無を確認する。
【０１２４】
たとえば、安否確認サーバー１００は、ステップＳ２０３の後、第１携帯端末２００ａから、ユーザーが無事である旨の回答が通知されている場合に、回答「有り」と確定する。その後、安否確認サーバー１００は、処理をステップＳ２０５に進める。
【０１２５】
一方、安否確認サーバー１００は、ステップＳ２０３の後、第１携帯端末２００ａから何の通知もない場合には、そのまま処理をステップＳ２０５に進める。
【０１２６】
（ステップＳ２０５）
安否確認サーバー１００は、第１確認部３２０として機能し、直近のステップＳ２０３での問い合わせから所定時間（たとえば、３０分）が経過（回答期限を超過）したか否か判別する。安否確認サーバー１００は、所定時間が経過していない場合には（ステップＳ２０５：ＮＯ）、処理をステップＳ２０４に戻して、ユーザーからの回答の有無を確認し直す。したがって、ユーザーからの回答がない状態で、所定時間が経過していないうちは、ステップＳ２０４、Ｓ２０５の処理を繰り返す。一方、安否確認サーバー１００は、所定時間が経過した場合には（ステップＳ２０５：ＹＥＳ）、処理をステップＳ２０６に進める。
【０１２７】
（ステップＳ２０６）
安否確認サーバー１００は、第１確認部３２０として機能し、ステップＳ２０４において確認した結果に基づいて、安否確認データ５１０を更新する。具体的には、安否確認サーバー１００は、ステップＳ２０３で問い合わせをした全てのユーザーのレコードを対象として、アプリケーションによる問い合わせ回数５１３をインクリメントする。さらに、安否確認サーバー１００は、ステップＳ２０４で回答「有り」と確定された全てのユーザーのレコードを対象として、アプリケーションによる回答実績５１４に「有り」を登録する。
【０１２８】
このとき、安否確認サーバー１００は、被災したユーザーからの回答結果を表示する。たとえば、安否確認サーバー１００は、ユーザーデータ記憶部４００からユーザーデータ４１０を読み出すとともに、安否確認データ記憶部５００から最新の安否確認データ５１０を読み出して、図１２に示すような一覧表を表示部１２０に表示する。一覧表には、ユーザー名、メールアドレス、目的、所属、出発日、帰宅日、位置情報更新日時、アプリ登録の可否、メールアドレス登録の可否、回答確認、地図、メッセージ等を含めることができる。
【０１２９】
ユーザー名は、ユーザーデータ４１０のユーザー名４１２に相当するデータである。メールアドレスは、ユーザーデータ４１０の携帯用メールアドレス４１７またはＰＣ用メールアドレス４１８に相当するデータである。目的は、ユーザーが日本国内や海外のいずれかの地域を訪問（滞在）する目的（たとえば、研修名等）を示すデータである。所属は、ユーザーが所属している組織（大学、企業等）の名称を示すデータである。出発日は、ユーザーデータ４１０の出発日４１３に相当するデータである。帰宅日は、ユーザーデータ４１０の帰宅日４１４に相当するデータである。位置情報更新日時は、ユーザーから位置情報が提供された場合の最新の更新日時を示すデータである。アプリ登録の可否は、安否確認用のアプリケーションの登録（図９に示すアプリ登録処理）が済まされているか否かを示すデータである。メールアドレス登録の可否は、携帯用メールアドレスおよびＰＣ用メールアドレスがユーザーデータ４１０に登録されているか否かを示すデータである。回答確認は、ユーザーから無事である旨の回答が得られたか否かを示すデータである。地図、メッセージは、ユーザーの位置を地図上に表示する画面や、ユーザーとやりとりしたメッセージを表示する画面等への遷移を可能にするリンク情報である。
【０１３０】
ただし、一覧表として表示するデータは、これに限定されるものではなく、管理者等の意向によって自由にカスタマイズしてよい。また、上記項目のうち一部のデータは、図７、図８に示すユーザーデータ４１０および安否確認データ５１０のいずれにも登録されていないが、適宜、ユーザーデータ４１０等に予め登録しておいてよい。
【０１３１】
（ステップＳ２０７）
安否確認サーバー１００は、第１確認部３２０として機能し、ステップＳ２０３の問い合わせに対して回答が無いユーザー（以下、「未回答者」とも称する）がいるか否か判別する。安否確認サーバー１００は、未回答者がいない場合には（ステップＳ２０７：ＮＯ）、第１安否確認処理を終了する。一方、安否確認サーバー１００は、１人でも未回答者がいる場合には（ステップＳ２０７：ＹＥＳ）、処理をステップＳ２０８に進める。なお、以下のステップＳ２０８、Ｓ２０９の処理は、未回答者を対象としており、ステップＳ２０４において回答「有り」と確定したユーザーに対しては実施しない。
【０１３２】
（ステップＳ２０８）
安否確認サーバー１００は、第１確認部３２０として機能し、未回答者に対する問い合わせの回数が所定数（たとえば、５回）以上であるか否か判別する。安否確認サーバー１００は、未回答者に対する問い合わせの回数が所定数未満である場合には（ステップＳ２０８：ＮＯ）、処理をＳ２０３に戻す。したがって、未回答者がいなくなるか、全ての未回答者に対する問い合わせの回数が所定数以上になるまで、ステップＳ２０３〜Ｓ２０８の処理を繰り返す。これにより、安否確認サーバー１００は、安否確認用のアプリケーションを通じた複数回の問い合わせを行うことができ、複数回の問い合わせのいずれに対しても回答が無い場合に、ユーザーからの回答が無いことを確定する。なお、ステップＳ２０３〜Ｓ２０８の処理が繰り返されると、ステップＳ２０３で問い合わせをする毎に、回答の無いユーザーについては、安否確認データ５１０のアプリケーションによる問い合わせ回数５１３がインクリメントされる。そして、安否確認サーバー１００は、ステップＳ２０３の問い合わせに対する回答が無いまま、問い合わせ回数が所定数以上となったユーザーについては、アプリケーションによる回答実績５１４に「無し」を登録する。
【０１３３】
そして、全ての未回答者に対する問い合わせの回数が所定数以上になった場合には（ステップＳ２０８：ＹＥＳ）、安否確認サーバー１００は、処理をＳ２０９に進める。
【０１３４】
（ステップＳ２０９）
安否確認サーバー１００は、第２問い合わせ部３３０として機能し、第２安否確認処理を実行する。第２安否確認処理は、第１確認部３２０によりユーザーからの回答が無いことが確認された場合に、さらに、携帯用電子メール（電子メール部６２０）を介して、当該ユーザーの無事を問い合わせるための処理である。詳細については、後述する（図１３に示す第２安否確認処理）。
【０１３５】
その後、安否確認サーバー１００は、第１安否確認処理を終了する。
【０１３６】
以上の第１安否確認処理が安否確認サーバー１００において実行されることにより、被災したユーザーに負担がかからない（安易な）方法で安否確認を行うことができ、より多くのユーザーから素早く安否確認に対する回答を得ることができる。
【０１３７】
また、被災した虞があるユーザーの安否情報を容易に管理者等に提供できる。なお、管理者等には、安否確認サーバー１００を管理している管理者、管理会社に限らず、被災した虞があるユーザーが所属する組織（大学、企業等）の管理者等も含まれる。この場合には、ユーザーが所属する組織（大学、企業等）の管理者に限り、安否確認サーバー１００へのネットワーク３００を介したアクセスを許可すればよい。
【０１３８】
（３）第２安否確認処理
図１３は、第２安否確認処理を説明するためのフローチャートである。以下、図１３を参照して、安否確認サーバー１００において実行される第２安否確認処理について説明する。
【０１３９】
安否確認サーバー１００は、上記の第１安否確認処理において、ステップＳ２０９に処理が移行したときに、図１３に示す第２安否確認処理を開始する。
【０１４０】
（ステップＳ３０１）
第２安否確認処理を開始すると、安否確認サーバー１００は、第２問い合わせ部３３０として機能し、携帯用電子メール（電子メール部６２０）を介して、第１安否確認処理で回答が無かったユーザーの無事を問い合わせる。たとえば、安否確認サーバー１００は、安否確認データ５１０を参照して、アプリケーションによる回答実績５１４に回答「無し」と登録されているユーザーを抽出する。そして、安否確認サーバー１００は、抽出したユーザーのユーザーＩＤ４１１に対応付けられている携帯用メールアドレス４１７をユーザーデータ４１０から特定する。その後、安否確認サーバー１００は、特定した携帯用メールアドレス４１７を宛先として、安否確認用の電子メールを送信する。当該電子メールには、ユーザー自身が無事である旨を回答するサーバー（安否確認サーバー１００でもよい）の場所を示すＵＲＬ情報が含まれている。
【０１４１】
なお、第１安否確認処理で回答が無かったユーザーが複数人いる場合には、安否確認サーバー１００は、各ユーザーに対して同様の問い合わせを行う。また、以降のステップＳ３０３までの処理についても、第１安否確認処理で回答が無かったユーザーが複数人いる場合には、安否確認サーバー１００は、各ユーザーに対して同様の処理を行う。
【０１４２】
第２携帯端末２００ｂは、安否確認サーバー１００から送信された安否確認用の電子メールを受信すると、着信音等によってユーザーに通知する。ユーザーが無事である場合には、ユーザーが安否確認用の電子メールに含まれているＵＲＬ情報をクリックする操作等が行われる。これにより、第２携帯端末２００ｂは、当該ＵＲＬ情報が示す場所にあるサーバーにアクセスして、無事である旨の回答が安否確認サーバー１００へ通知される。
【０１４３】
（ステップＳ３０２）
安否確認サーバー１００は、第２確認部３４０として機能し、ステップＳ３０１の問い合わせに対する、携帯用電子メール（電子メール部６２０）を用いたユーザーの回答の有無を確認する。
【０１４４】
たとえば、安否確認サーバー１００は、ステップＳ３０１の後、第２携帯端末２００ｂから、ユーザーが無事である旨の回答が通知されている場合に、回答「有り」と確定する。その後、安否確認サーバー１００は、処理をステップＳ３０３に進める。
【０１４５】
一方、安否確認サーバー１００は、ステップＳ３０１の後、第２携帯端末２００ｂから何の通知もない場合には、そのまま処理をステップＳ３０３に進める。
【０１４６】
（ステップＳ３０３）
安否確認サーバー１００は、第２確認部３４０として機能し、直近のステップＳ３０１での問い合わせから所定時間（たとえば、２時間）が経過（回答期限を超過）したか否か判別する。安否確認サーバー１００は、所定時間が経過していない場合には（ステップＳ３０３：ＮＯ）、処理をステップＳ３０２に戻して、ユーザーからの回答の有無を確認し直す。したがって、ユーザーからの回答がない状態で、所定時間が経過していないうちは、ステップＳ３０２、Ｓ３０３の処理を繰り返す。一方、安否確認サーバー１００は、所定時間が経過した場合には（ステップＳ３０３：ＹＥＳ）、処理をステップＳ３０４に進める。
【０１４７】
（ステップＳ３０４）
安否確認サーバー１００は、第２確認部３４０として機能し、ステップＳ３０２において確認した結果に基づいて、安否確認データ５１０を更新する。具体的には、安否確認サーバー１００は、ステップＳ３０１で問い合わせをした全てのユーザーのレコードを対象として、携帯用電子メールによる問い合わせ回数５１５をインクリメントする。さらに、安否確認サーバー１００は、ステップＳ３０２で回答「有り」と確定された全てのユーザーのレコードを対象として、携帯用電子メールによる回答実績５１６に「有り」を登録する。
【０１４８】
このとき、安否確認サーバー１００は、上述したステップＳ２０６と同様に、ユーザーデータ４１０および最新の安否確認データ５１０に基づいて、被災したユーザーからの回答結果を表示してもよい。
【０１４９】
（ステップＳ３０５）
安否確認サーバー１００は、第２確認部３４０として機能し、ステップＳ３０１の問い合わせに対して回答が無いユーザー（未回答者）がいるか否か判別する。安否確認サーバー１００は、未回答者がいない場合には（ステップＳ３０５：ＮＯ）、第２安否確認処理を終了して、処理を第１安否確認処理のステップＳ２１０へ戻す。一方、安否確認サーバー１００は、１人でも未回答者がいる場合には（ステップＳ３０５：ＹＥＳ）、処理をステップＳ３０６に進める。
【０１５０】
（ステップＳ３０６）
安否確認サーバー１００は、第２確認部３４０として機能し、未回答者に対する問い合わせの回数が所定数（たとえば、２回）以上であるか否か判別する。安否確認サーバー１００は、未回答者に対する問い合わせの回数が所定数未満である場合には（ステップＳ３０６：ＮＯ）、処理をＳ３０１に戻す。したがって、未回答者がいなくなるか、全ての未回答者に対する問い合わせの回数が所定数以上になるまで、ステップＳ３０１〜３０６の処理を繰り返す。これにより、安否確認サーバー１００は、携帯用電子メールを通じた複数回の問い合わせを行うことができ、複数回の問い合わせのいずれに対しても回答が無い場合に、ユーザーからの回答が無いことを確定する。なお、ステップＳ３０１〜Ｓ３０６の処理が繰り返されると、ステップＳ３０１で問い合わせをする毎に、安否確認データ５１０の携帯用電子メールによる問い合わせ回数５１５がインクリメントされる。そして、安否確認サーバー１００は、ステップＳ３０１の問い合わせに対する回答が無いまま、問い合わせ回数が所定数以上となったユーザーについては、携帯用電子メールによる回答実績５１６に「無し」を登録する。
【０１５１】
そして、全ての未回答者に対する問い合わせの回数が所定数以上になった場合には（ステップＳ３０６：ＹＥＳ）、安否確認サーバー１００は、処理をＳ３０７に進める。
【０１５２】
（ステップＳ３０７）
安否確認サーバー１００は、第２問い合わせ部３３０として機能し、第３安否確認処理を実行する。第３安否確認処理は、第２確認部３４０によりユーザーからの回答が無いことが確認された場合に、さらに、ＰＣ用電子メール（電子メール部６３０）を介して、当該ユーザーの無事を問い合わせるための処理である。詳細については、後述する（図１４に示す第３安否確認処理）。
【０１５３】
その後、安否確認サーバー１００は、第２安否確認処理を終了して、処理を第１安否確認処理のステップＳ２１０へ戻す。
【０１５４】
以上の第２安否確認処理が安否確認サーバー１００において実行されることにより、アプリケーションによる問い合わせに対して回答が無かったユーザーに対して、別の方法（携帯用電子メール）で無事を確認できる。
【０１５５】
（４）第３安否確認処理
図１４は、第３安否確認処理を説明するためのフローチャートである。以下、図１４を参照して、安否確認サーバー１００において実行される第３安否確認処理について説明する。
【０１５６】
安否確認サーバー１００は、上記の第２安否確認処理において、ステップＳ３０７に処理が移行したときに、図１４に示す第３安否確認処理を開始する。
【０１５７】
（ステップＳ４０１）
第３安否確認処理を開始すると、安否確認サーバー１００は、第２問い合わせ部３３０として機能し、ＰＣ用電子メール（電子メール部６３０）を介して、第２安否確認処理で回答が無かったユーザーの無事を問い合わせる。たとえば、安否確認サーバー１００は、安否確認データ５１０を参照して、携帯用電子メールによる回答実績５１６に回答「無し」と登録されているユーザーを抽出する。そして、安否確認サーバー１００は、抽出したユーザーのユーザーＩＤ４１１に対応付けられているＰＣ用メールアドレス４１８をユーザーデータ４１０から特定する。その後、安否確認サーバー１００は、特定したＰＣ用メールアドレス４１８を宛先として、安否確認用の電子メールを送信する。当該電子メールには、アクセスによってユーザー自身が無事である旨を回答可能なＵＲＬ情報が含まれる。
【０１５８】
なお、第２安否確認処理で回答が無かったユーザーが複数人いる場合には、安否確認サーバー１００は、各ユーザーに対して同様の問い合わせを行う。また、以降のステップＳ４０３までの処理についても、第２安否確認処理で回答が無かったユーザーが複数人いる場合には、安否確認サーバー１００は、各ユーザーに対して同様の処理を行う。
【０１５９】
第３携帯端末２００ｃは、安否確認サーバー１００から送信された安否確認用の電子メールを受信する。ユーザーが無事である場合には、ユーザーが安否確認用の電子メールに含まれているＵＲＬ情報をクリックする操作等が行われる。これにより、第３携帯端末２００ｃは、当該ＵＲＬ情報が示す位置にあるサーバーにアクセスして、無事である旨の回答が安否確認サーバー１００へ通知される。
【０１６０】
（ステップＳ４０２）
安否確認サーバー１００は、第２確認部３４０として機能し、ステップＳ４０１の問い合わせに対する、ＰＣ用電子メール（電子メール部６３０）を用いたユーザーの回答の有無を確認する。
【０１６１】
たとえば、安否確認サーバー１００は、ステップＳ４０１の後、第３携帯端末２００ｃから、ユーザーが無事である旨の回答が通知されている場合に、回答「有り」と確定する。その後、安否確認サーバー１００は、処理をステップＳ４０３に進める。
【０１６２】
一方、安否確認サーバー１００は、ステップＳ４０１の後、第３携帯端末２００ｃから何の通知もない場合には、そのまま処理をステップＳ４０３に進める。
【０１６３】
（ステップＳ４０３）
安否確認サーバー１００は、第３確認部４４０として機能し、直近のステップＳ４０１での問い合わせから所定時間（たとえば、２時間）が経過（回答期限を超過）したか否か判別する。安否確認サーバー１００は、所定時間が経過していない場合には（ステップＳ４０３：ＮＯ）、処理をステップＳ４０２に戻して、ユーザーからの回答の有無を確認し直す。したがって、ユーザーからの回答がない状態で、所定時間が経過していないうちは、ステップＳ４０２、Ｓ４０３の処理を繰り返す。一方、安否確認サーバー１００は、所定時間が経過した場合には（ステップＳ４０３：ＹＥＳ）、処理をステップＳ４０４に進める。
【０１６４】
（ステップＳ４０４）
安否確認サーバー１００は、第２確認部３４０として機能し、ステップＳ４０２において確認した結果に基づいて、安否確認データ５１０を更新する。具体的には、安否確認サーバー１００は、ステップＳ４０１で問い合わせをした全てのユーザーのレコードを対象として、ＰＣ用電子メールによる問い合わせ回数５１７をインクリメントする。さらに、安否確認サーバー１００は、ステップＳ４０２で回答「有り」と確定された全てのユーザーのレコードを対象として、ＰＣ用電子メールによる回答実績５１８に「有り」を登録する。
【０１６５】
このとき、安否確認サーバー１００は、上述したステップＳ２０６と同様に、ユーザーデータ４１０および最新の安否確認データ５１０に基づいて、被災したユーザーからの回答結果を表示してもよい。
【０１６６】
（ステップＳ４０５）
安否確認サーバー１００は、第２確認部３４０として機能し、ステップＳ４０１の問い合わせに対して回答が無いユーザー（未回答者）がいるか否か判別する。安否確認サーバー１００は、未回答者がいない場合には（ステップＳ４０５：ＮＯ）、第３安否確認処理を終了して、処理を第１安否確認処理のステップＳ２１０へ戻す。一方、安否確認サーバー１００は、１人でも未回答者がいる場合には（ステップＳ４０５：ＹＥＳ）、処理をステップＳ４０６に進める。
【０１６７】
（ステップＳ４０６）
安否確認サーバー１００は、第２確認部３４０として機能し、未回答者に対する問い合わせの回数が所定数（たとえば、２回）以上であるか否か判別する。安否確認サーバー１００は、未回答者に対する問い合わせの回数が所定数未満である場合には（ステップＳ４０６：ＮＯ）、処理をＳ４０１に戻す。したがって、未回答者がいなくなるか、全ての未回答者に対する問い合わせの回数が所定数以上になるまで、ステップＳ４０１〜４０６の処理を繰り返す。これにより、安否確認サーバー１００は、ＰＣ用電子メールを通じた複数回の問い合わせを行うことができ、複数回の問い合わせのいずれに対しても回答が無い場合に、ユーザーからの回答が無いことを確定する。なお、ステップＳ４０１〜Ｓ４０６の処理が繰り返されると、ステップＳ４０１で問い合わせをする毎に、安否確認データ５１０のＰＣ用電子メールによる問い合わせ回数５１７がインクリメントされる。そして、安否確認サーバー１００は、ステップＳ４０１の問い合わせに対する回答が無いまま、問い合わせ回数が所定数以上となったユーザーについては、ＰＣ用電子メールによる回答実績５１８に「無し」を登録する。
【０１６８】
そして、全ての未回答者に対する問い合わせの回数が所定数以上になった場合には（ステップＳ４０６：ＹＥＳ）、安否確認サーバー１００は、第３安否確認処理を終了して、処理を第１安否確認処理のステップＳ２１０へ戻す。
【０１６９】
以上の第３安否確認処理が安否確認サーバー１００において実行されることにより、携帯用電子メールによる問い合わせに対して回答が無かったユーザーに対して、さらに別の方法（ＰＣ用電子メール）で無事を確認できる。
【０１７０】
以上のように、複数種類の方法によって、段階的にユーザーの安否の確認を行っているため、ユーザーが訪問先（滞在先）に持参した電子機器の種類によらず、確実にユーザーの安否を確認することができる。
【０１７１】
また、本実施形態では、第１安否確認処理、第２安否確認処理、第３安否確認処理の順序で、ユーザーの安否確認を段階的に行っている。第１安否確認処理は、第２安否確認処理や第３安否確認処理と比較して、ユーザー自身が無事である旨を安否確認サーバー１００へ回答する操作が容易であり、ユーザーにかかる負担が少ない。このように、最初に、ユーザーにかかる負担が最も少ない方法で安否確認を行うため、より多くのユーザーから素早く安否確認に対する回答を得ることができる。
【０１７２】
（５）アプリケーションによる回答処理
図１５は、アプリケーションによる回答処理を説明するためのフローチャートである。図１６（Ａ）は、位置情報の提供に関する同意画面の一例を示す図である。図１６（Ｂ）は、ログイン画面の一例を示す図である。図１６（Ｃ）は、アプリ登録ＩＤの解除画面の一例を示す図である。図１７（Ａ）は、トップ画面の一例を示す図である。図１７（Ｂ）は、メッセージ画面の一例を示す図である。図１７（Ｃ）は、連絡先の案内画面の一例を示す図である。
【０１７３】
以下、図１５〜図１７を参照して、第１携帯端末２００ａにおいて実行されるアプリケーションによる回答処理について説明する。
【０１７４】
第１携帯端末２００ａは、電源が投入されるタイミングで、アプリケーションによる回答処理を開始する。ただし、アプリケーションによる回答処理を開始するタイミングは、これに限定されず、適宜、設計変更してよい。
【０１７５】
（ステップＳ５０１）
アプリケーションによる回答処理を開始すると、第１携帯端末２００ａは、安否確認サーバー１００から問い合わせを受け付けたか否か判別する。たとえば、第１携帯端末２００ａは、第１安否確認処理のステップＳ２０３において安否確認サーバー１００から送信された問い合わせ信号を受信した場合に、安否確認サーバー１００から問い合わせを受け付けたと判断する。
【０１７６】
第１携帯端末２００ａは、安否確認サーバー１００から問い合わせを受け付けていなければ（ステップＳ５０１：ＮＯ）、受け付けるまで待機する。そして、第１携帯端末２００ａは、安否確認サーバー１００から問い合わせを受け付けると（ステップＳ５０１：ＹＥＳ）、着信音等によってユーザーに通知する。
【０１７７】
このとき、ユーザーが無事である場合には、第１携帯端末２００ａは、安否確認用のアプリケーション（アプリケーション部６１０）を起動させる指示をユーザーから受け付けて、処理をステップＳ５０２に進める。ただし、これに限定されず、たとえば、第１携帯端末２００ａは、安否確認サーバー１００から送信された問い合わせ信号を受信したときに、自動的に安否確認用のアプリケーションを起動して、処理をステップＳ５０２に進めてもよい。
【０１７８】
（ステップＳ５０２）
第１携帯端末２００ａは、アプリケーション部６１０として機能し、ログイン処理を行う。
【０１７９】
たとえば、第１携帯端末２００ａは、最初に、図１６（Ａ）に示すような位置情報の提供に関する同意画面をタッチパネル部２２５ａのディスプレイに表示する。位置情報の提供に関する同意画面には、位置情報の提供に同意するための同意ボタン８１０と、位置情報の提供に同意しないための非同意ボタン８２０とが、少なくとも含まれている。
【０１８０】
同意ボタン８１０をタッチする操作がユーザーにより行われた場合には、第１携帯端末２００ａは、定期的に、ＧＰＳ受信部２６０ａで受信した信号に基づいて、第１携帯端末２００ａの位置を、安否確認サーバー１００に提供してもよい。また、非同意ボタン８２０をタッチする操作がユーザーにより行われた場合には、第１携帯端末２００ａは、災害が発生したときにおいても、第１携帯端末２００ａの位置を安否確認サーバー１００に提供しないようにする。
【０１８１】
なお、ステップＳ５０２において、図１６（Ａ）の同意画面の表示を省略し、特別な指示がない限り、第１携帯端末２００ａの位置を安否確認サーバー１００に提供しないようにしてもよい。
【０１８２】
次に、第１携帯端末２００ａは、図１６（Ｂ）に示すようなログイン画面をタッチパネル部２２５ａのディスプレイに表示する。ログイン画面には、登録ＩＤを入力するための入力ボックス８３０と、入力ボックス８３０に入力された登録ＩＤを安否確認サーバー１００へ送信するためのログインボタン８４０と、が少なくとも含まれている。
【０１８３】
入力ボックス８３０に登録ＩＤが入力された後、ログインボタン８４０をタッチする操作がユーザーにより行われた場合には、第１携帯端末２００ａは、入力ボックス８３０に入力された登録ＩＤを安否確認サーバー１００へ送信する。
【０１８４】
このとき、上述したアプリ登録処理で登録したアプリ登録ＩＤ４１６が正しく入力されている場合には、安否確認サーバー１００は、第１携帯端末２００ａを操作しているユーザーに対して、アプリケーションへのログインを許可する。
【０１８５】
一方、アプリ登録ＩＤ４１６が正しく入力されていない場合には、安否確認サーバー１００は、第１携帯端末２００ａを操作しているユーザーに対して、アプリケーションへのログインを不許可にする。
【０１８６】
また、安否確認サーバー１００は、第１携帯端末２００ａから送信された登録ＩＤを受信した日時が、ユーザーデータ４１０の出発日４１３から帰宅日４１４までの期間外である場合にも、ユーザーのログインを不許可にする。この場合には、第１携帯端末２００ａは、図１６（Ｃ）に示すように、登録ＩＤの解除を促す解除画面をタッチパネル部２２５ａのディスプレイに表示する。解除画面には、登録ＩＤを解除するための解除ボタン８５０が少なくとも含まれている。
【０１８７】
解除ボタン８５０をタッチする操作がユーザーにより行われた場合には、第１携帯端末２００ａは、登録ＩＤの解除を要求するための信号を、安否確認サーバー１００へ送信する。安否確認サーバー１００は、この信号を受信すると、先に第１携帯端末２００ａから送信された登録ＩＤ（アプリ登録ＩＤ４１６）に基づいて、該当するユーザーのレコードをユーザーデータ４１０から削除する。
【０１８８】
なお、ステップＳ５０２において、図１６（Ｂ）、（Ｃ）の画面の表示を省略し、起動と同時に自動ログイン可能にしてもよい。
【０１８９】
（ステップＳ５０３）
安否確認用のアプリケーションの起動後、第１携帯端末２００ａは、図１７（Ａ）に示すようなトップ画面をタッチパネル部２２５ａのディスプレイに表示する。トップ画面には、ユーザー自身が無事である旨を回答するための回答ボタン９１０が少なくとも含まれている。また、図１７（Ａ）に示すように、回答ボタン９１０以外にも、メッセージボタン９２０、フリーダイヤルボタン９３０、直通電話ボタン９４０、連絡先案内リンク９５０などが含まれていてもよい。
【０１９０】
なお、メッセージボタン９２０は、図１７（Ｂ）に示すようなメッセージ画面に遷移させるためのボタンであり、当該メッセージ画面において安否確認サーバー１００の管理者等とメッセージのやりとりを行うことができる。フリーダイヤルボタン９３０は、フリーダイヤルで電話（通話部２５０ａによる電話）できる画面（不図示）に遷移させるためのボタンである。直通電話ボタン９４０は、大使館等の所定の機関に直通電話（通話部２５０ａによる電話）をかけることができる画面（不図示）に遷移させるためのボタンである。連絡先案内リンク９５０は、図１７（Ｃ）に示すような所定の機関の連絡先が記載された案内画面に遷移させるためのリンクである。
【０１９１】
（ステップＳ５０４）
第１携帯端末２００ａは、アプリケーション部６１０として機能し、トップ画面の回答ボタン９１０をタッチする操作がユーザーにより行われたか否か判別する。第１携帯端末２００ａは、回答ボタン９１０をタッチする操作が行われずに（ステップＳ５０４：ＮＯ）、他のボタン等をタッチする操作を受け付けた場合には、その操作に応じた処理を実行し、回答ボタン９１０をタッチする操作が行われるまで待機する。一方、第１携帯端末２００ａは、タッチパネル部２２５ａを介して回答ボタン９１０をタッチする操作を受け付けた場合には（ステップＳ５０４：ＹＥＳ）、処理をステップＳ５０５へ進める。
【０１９２】
（ステップＳ５０５）
第１携帯端末２００ａは、アプリケーション部６１０として機能し、ユーザー自身が無事である旨の回答を安否確認サーバー１００へ通知する。たとえば、第１携帯端末２００ａは、通信部２４０ａを介して、ユーザー自身が無事である旨の信号を安否確認サーバー１００へ送信する。
【０１９３】
（ステップＳ５０６）
第１携帯端末２００ａは、アプリケーション部６１０として機能し、終了させるための操作がユーザーにより行われたか否か判別する。第１携帯端末２００ａは、終了させるための操作を受け付けていない場合には（ステップＳ５０６：ＹＥＳ）、当該操作を受け付けるまで待機する。一方、第１携帯端末２００ａは、タッチパネル部２２５ａを介して終了させるための操作を受け付けた場合には（ステップＳ５０６：ＹＥＳ）、アプリケーションによる回答処理を終了する。
【０１９４】
以上のアプリケーションによる回答処理が第１携帯端末２００ａにおいて実行されることにより、電子メールを利用する場合よりも容易にユーザーの無事を回答できる。というのも、一般的な電子メールで回答する場合には、電子メールの宛先やメッセージの入力等をユーザーが行う必要があるからである。
【０１９５】
上記した各フローチャートの各処理単位は、安否確認システム１０の理解を容易にするために、主な処理内容に応じて分割したものである。処理ステップの分類の仕方やその名称によって、本願発明が制限されることはない。安否確認システム１０で行われる処理は、さらに多くの処理ステップに分割することもできる。また、１つの処理ステップが、さらに多くの処理を実行してもよい。
【０１９６】
＜変形例＞
なお、上記実施形態は、本発明の要旨を例示することを意図し、本発明を限定するものではない。多くの代替物、修正、変形例は当業者にとって明らかである。
【０１９７】
たとえば、上記実施形態では、３種類の方法（アプリケーション、携帯用電子メール、ＰＣ用電子メール）によって、段階的にユーザーの安否の確認を行っている。しかし、本発明は、３種類の方法に限定されず、アプリケーションと電子メールの２種類の方法によって、段階的にユーザーの安否の確認を行ってもよい。この場合、アプリケーションによって安否を確認できないユーザーに対して、携帯用電子メールを送信するようにしてもよい（この場合、図１４の第３安否確認処理を省略すればよい）。また、アプリケーションによって安否を確認できないユーザーに対して、ＰＣ用電子メールを送信するようにしてもよい（この場合、図１３の第２安否確認処理を省略すればよい）。あるいは、最近では、携帯用電子メールとＰＣ用電子メールの区別もなくなりつつある。したがって、アプリケーションによって安否が確認できないユーザーに対して、携帯用電子メールおよびＰＣ用電子メールを区別せずいずれかを送信してもよい。また、アプリケーションによって安否を確認できないユーザーに対して、選択的に、携帯用電子メール、ＰＣ用電子メールのいずれかを送信するようにしてもよい。また、４種類以上の方法によって、段階的にユーザーの安否の確認を行ってもよい。
【０１９８】
また、上記実施形態では、アプリケーションによる問い合わせの後に、電子メール（携帯用電子メールまたはＰＣ用電子メール）による問い合わせを行うようにしている。しかし、これに限定されず、電子メール（ただし、文字入力などの煩雑な操作は必要ないものに限る）による問い合わせの後に、アプリケーションによる問い合わせを行うようにしてもよい。また、アプリケーションによる問い合わせと、電子メール（携帯用電子メールまたはＰＣ用電子メール）による問い合わせの順序を、管理者等により変更可能にしてもよい。
【０１９９】
また、上記実施形態では、アプリケーションによる問い合わせの回数は、５回を上限としている。しかし、５回に限定する必要なく、４回以下、もしくは６回以上であってもよい。また、管理者等の指示に基づいて、自由に変更できるようにしてよい。
【０２００】
さらに、携帯用電子メールによる問い合わせの回数も、２回に限定されず、１回、もしくは３回以上であってもよく、管理者等の指示に基づいて、自由に変更できるようにしてよい。
【０２０１】
さらに、ＰＣ用電子メールによる問い合わせの回数も、２回に限定されず、１回、もしくは３回以上であってもよく、管理者等の指示に基づいて、自由に変更できるようにしてよい。
【０２０２】
また、上記実施形態では、アプリケーションによる問い合わせの間隔（ステップＳ２０５の所定時間に相当）を３０分としている。しかし、３０分に限定する必要はなく、３０分より短くしてもよいし、長くしてもよい。また、問い合わせの回数が増加するにつれて、問い合わせ間隔を長く、もしくは短くしてもよい。また、管理者等の指示に基づいて、自由に変更できるようにしてよい。
【０２０３】
さらに、携帯用電子メールによる問い合わせの間隔（ステップＳ３０３の所定時間に相当）も、２時間に限定されず、２時間より短くしてもよいし、長くしてもよい。また、問い合わせの回数が増加するにつれて、問い合わせ間隔を長く、もしくは短くしてもよい。また、管理者等の指示に基づいて、自由に変更できるようにしてもよい。
【０２０４】
さらに、ＰＣ用電子メールによる問い合わせの間隔（ステップＳ４０３の所定時間に相当）も、２時間に限定されず、２時間より短くしてもよいし、長くしてもよい。また、問い合わせの回数が増加するにつれて、問い合わせ間隔を長く、もしくは短くしてもよい。また、管理者等の指示に基づいて、自由に変更できるようにしてもよい。
【０２０５】
図１８は、問い合わせ順序、問い合わせ回数、問い合わせ間隔等に関する設定画面の一例を示す図である。
【０２０６】
たとえば、安否確認サーバー１００は、管理者等の指示に基づき、図１８に示すような設定画面を表示部１２０に表示する。設定画面には、災害等が発生したときに最初に実施する問い合わせの方法を選択するための第１選択ボックス１０１０が含まれている。管理者等は、第１選択ボックス１０１０から、一の問い合わせ方法（アプリケーション、電子メール等）を選択できる。さらに、設定画面には、第１選択ボックス１０１０で選択された問い合わせ方法による問い合わせの回数（上限）を指定するための第２選択ボックス１０２０が含まれている。管理者等は、第２選択ボックス１０２０を操作して、問い合わせ回数を自由に変更できる。さらに、設定画面には、第１選択ボックス１０１０で選択された問い合わせ方法による問い合わせの間隔を指定するための第３選択ボックス１０３０が含まれている。管理者等は、第３選択ボックス１０３０を操作して、問い合わせ間隔を自由に変更できる。さらに、設定画面には、第１選択ボックス１０１０で選択された問い合わせ方法で安否を確認できなかったユーザーに対し、最後に実施する問い合わせの方法を選択するための第４選択ボックス１０４０が含まれている。管理者等は、第４選択ボックス１０４０から、一の問い合わせ方法（アプリケーション、電子メール等）を選択できる。また、設定画面には、設定内容を確定するための設定ボタン１０５０、設定内容を破棄するためのキャンセルボタン１０６０等が含まれていてもよい。
【０２０７】
たとえば、図１８に示すように、最初の問い合わせ方法をアプリケーションとし、問い合わせ回数を６回、問い合わせ間隔を３０分、最後の問い合わせ方法を電子メールとして、安否確認サーバー１００に設定されたとする。この場合、安否確認サーバー１００は、アプリケーションによる問い合わせを最大５回、３０分間隔で行い、それでもユーザーから無事の連絡がない場合、最後に１回電子メールによる問い合わせを行う。
【０２０８】
また、上記実施形態では、第１携帯端末２００ａにおいて回答ボタン９１０をタッチすることによってユーザーの無事を安否確認サーバー１００へ通知しているが、これに限定されず、発話等に基づいてユーザーの無事を安否確認サーバー１００へ通知するようにしてもよい。
【０２０９】
以上の安否確認システム１０の構成は、上記の実施形態および変形例の特徴を説明するにあたって主要構成を説明したのであって、上記の構成に限られない。また、一般的な安否確認システム１０が備える構成を排除するものではない。
【０２１０】
また、上記した安否確認システム１０の各機能構成は、各機能構成を理解容易にするために、主な処理内容に応じて分類したものである。構成要素の分類の仕方や名称によって、本願発明が制限されることはない。各機能構成は、処理内容に応じて、さらに多くの構成要素に分類することもできる。また、一つの構成要素がさらに多くの処理を実行するように分類することもできる。
【０２１１】
また、安否確認システム１０を動作させるプログラムは、ＵＳＢメモリー、フレキシブルディスク、ＣＤ−ＲＯＭ等のコンピューター読み取り可能な記録媒体によって提供されてもよいし、インターネット等のネットワークを介してオンラインで提供されてもよい。この場合、コンピューター読み取り可能な記録媒体に記録されたプログラムは、通常、メモリーやストレージ等に転送され記憶される。また、このプログラムは、たとえば、単独のアプリケーションソフトとして提供されてもよいし、安否確認システム１０の一機能としてその各装置のソフトウェアに組み込んでもよい。
【符号の説明】
【０２１２】
１０  安否確認システム、
１００  安否確認サーバー、
１１０  制御部（安否確認サーバー）、
１２０  表示部（安否確認サーバー）、
１３０  入力部（安否確認サーバー）、
１４０  通信部（安否確認サーバー）、
２００  携帯端末、
２００ａ  第１携帯端末、
２１０ａ  制御部（第１携帯端末）、
２２５ａ  タッチパネル部（第１携帯端末）、
２４０ａ  通信部（第１携帯端末）、
２５０ａ  通話部（第１携帯端末）、
２６０ａ  ＧＰＳ受信部（第１携帯端末）、
２００ｂ  第２携帯端末、
２１０ｂ  制御部（第２携帯端末）、
２２０ｂ  表示部（第２携帯端末）、
２３０ｂ  入力部（第２携帯端末）、
２４０ｂ  通信部（第２携帯端末）、
２５０ｂ  通話部（第２携帯端末）、
２６０ｂ  ＧＰＳ受信部（第２携帯端末）、
２００ｃ  第３携帯端末、
２１０ｃ  制御部（第３携帯端末）、
２２０ｃ  表示部（第３携帯端末）、
２３０ｃ  入力部（第３携帯端末）、
２４０ｃ  通信部（第３携帯端末）、
３１０  第１問い合わせ部、
３２０  第１確認部、
３３０  第２問い合わせ部、
３４０  第２確認部、
４００  ユーザーデータ記憶部、
４１０  ユーザーデータ、
５００  安否確認データ記憶部、
５１０  安否確認データ、
６１０  アプリケーション部、
６２０  電子メール部（携帯用）、
６３０  電子メール部（ＰＣ用）。
【図１】
0005990607.tif 000002
【図２】
0005990607.tif 000003
【図３】
0005990607.tif 000004
【図４】
0005990607.tif 000005
【図５】
0005990607.tif 000006
【図６】
0005990607.tif 000007
【図７】
0005990607.tif 000008
【図８】
0005990607.tif 000009
【図９】
0005990607.tif 000010
【図１０】
0005990607.tif 000011
【図１１】
0005990607.tif 000012
【図１２】
0005990607.tif 000013
【図１３】
0005990607.tif 000014
【図１４】
0005990607.tif 000015
【図１５】
0005990607.tif 000016
【図１６】
0005990607.tif 000017
【図１７】
0005990607.tif 000018
【図１８】
0005990607.tif 000019