JP6716820B1 - 災害ネットワークシステム - Google Patents

Abstract

【課題】詳細な災害状況を把握することが可能になる災害ネットワークシステムを提供する。【解決手段】災害ネットワークシステムにおいて、災害発生時に、被災者の端末の画面に被災状況の情報が入力された場合はその情報を被災者端末の識別情報及び位置情報とともにサーバーに送信する被災状況入力処理Ｓ３１１と、被災状況入力処理Ｓ３１１から受信した情報に対して、最優先カテゴリー／準優先カテゴリー／非優先カテゴリー／保留カテゴリーのいずれかのトリアージカテゴリーを設定し、トリアージカテゴリーを、対応する被災者端末の位置情報とともに救助員が操作する救助員端末に送信する状況整理処理Ｓ１１２と、救助員端末の表示部に地図を表示するとともに状況整理処理Ｓ１１２から受信した位置情報の場所にトリアージカテゴリーを表示するトリアージ処理Ｓ４１１とを実施する。【選択図】図２

Description

この発明は、災害ネットワークシステムに関する。

災害が発生した場合には、被災状況を迅速に把握することが重要である。そこで特許文献１では、ヘリコプターを使用することで、被災状況を把握するシステムを提案している。

国際公開第２０１３／０５１３００号パンフレット

しかしながら、前述した従来のシステムでは、被災地の建物などの状況をおおまかに把握することはできるものの、詳細に把握することは困難であって被災者の救助に役立つ情報を得ることは難しかった。

本発明は、このような従来の問題点に着目してなされた。本発明の目的は、詳細な被災状況を把握することが可能になる災害ネットワークシステムを提供することである。

本発明は以下のような解決手段によって前記課題を解決する。なお、理解を容易にするために本発明の実施形態に対応する符号を括弧書きするが、これに限定されるものではない。また符号を付して説明した構成は適宜代替しても改良してもよい。

第１の態様は、サーバー（１０）と携帯通信端末（３０，４０）とを含む災害ネットワークシステムであって、前記サーバー（１０）に組み込まれ、災害が発生した場合に被災エリアとして想定されるエリアにある携帯通信端末（以下「被災者端末」と称す）（３０）に対してエリアメールを送信するエリアメール送信部（Ｓ１１１）と、前記被災者端末（３０）に組み込まれ、前記エリアメールを受信してその被災者端末（３０）の表示部に被災状況の情報を入力する画面を表示する入力画面表示部（Ｓ３１１１，Ｓ３１１６１，Ｓ３１１７１）と、前記被災者端末（３０）に組み込まれ、前記画面に被災状況の情報が入力された場合には入力された被災状況の情報を被災者端末（３０）の識別情報及び位置情報とともに前記サーバー（１０）に送信し被災状況の情報が入力されない場合には被災者端末（３０）の識別情報及び位置情報を前記サーバー（１０）に送信する端末情報送信部（Ｓ３１１８）と、前記サーバー（１０）に組み込まれ、前記端末情報送信部（Ｓ３１１８）から受信した情報に対して、救助の優先度が最も高い最優先カテゴリー／救助の優先度が最優先カテゴリーの次に高い準優先カテゴリー／救助の優先度が最も低い非優先カテゴリー／救助の優先度を決めることを保留する保留カテゴリーのいずれかのトリアージカテゴリーを設定するトリアージカテゴリー設定部（Ｓ１１２２）と、前記サーバー（１０）に組み込まれ、前記トリアージカテゴリー設定部（Ｓ１１２２）で設定されたトリアージカテゴリーの情報を被災者端末（３０）の識別情報及び位置情報と対応させて保存するカテゴリー情報保存部（Ｓ１１２２９）と、前記サーバー（１０）に組み込まれ、前記端末情報送信部（Ｓ３１１８）から受信した情報に基づいて、回避すべきエリアを特定する回避エリア特定部（Ｓ１１２３１）と、前記サーバー（１０）に組み込まれ、前記カテゴリー情報保存部（Ｓ１１２２９）に保存されている各被災者のトリアージカテゴリー及び位置の情報並びにある場所における被災者の人数に基づいて各救助班の救出対象者を機械的に決めて各救助班が救助活動を行う場所を機械的に設定し、その救助活動を行う場所に各救助班が前記回避エリア特定部（Ｓ１１２３１）で特定された回避すべきエリアを避けて向かう救助ルートを機械的に設定する救助ルート設定部（Ｓ１１２５）と、前記サーバー（１０）に組み込まれ、前記カテゴリー情報保存部（Ｓ１１２２９）に保存されたトリアージカテゴリーを、対応する被災者端末（３０）の位置情報とともに救助員が操作する携帯通信端末（以下「救助員端末」と称す）（４０）に送信するとともに、前記回避エリア特定部（Ｓ１１２３１）で特定された回避すべきエリアの情報及び前記救助ルート設定部（Ｓ１１２５）で設定された救助ルートを前記救助員端末（４０）に送信する救助情報送信部（Ｓ１１２６）と、前記救助員端末（４０）に組み込まれ、その救助員端末（４０）の表示部に地図を表示するとともに前記救助情報送信部（Ｓ１１２６）から受信した位置情報の場所にトリアージカテゴリーを表示する救助情報表示部（Ｓ４１１１）と、を有する、災害ネットワークシステムである。

第２の態様は、第１の態様の災害ネットワークシステムにおいて、前記トリアージカテゴリー設定部（Ｓ１１２２）は、前記端末情報送信部（Ｓ３１１８）から受信した情報に被災状況の情報が含まれていない場合には、トリアージカテゴリーとして保留カテゴリーを設定する、災害ネットワークシステムである。

第３の態様は、第１又は第２の態様の災害ネットワークシステムにおいて、所有者の生体情報を検知し、その生体情報を、ペアリングされている被災者端末（３０）に送信する生体情報検知端末（５０）をさらに含み、前記端末情報送信部（Ｓ３１１８）は、被災状況の情報が入力されない場合には、前記生体情報検知端末（５０）から受信した生体情報を被災状況の情報として、被災者端末（３０）の識別情報及び位置情報とともに前記サーバー（１０）に送信する、災害ネットワークシステムである。

第４の態様は、第１から第３までのいずれかの態様の災害ネットワークシステムにおいて、前記入力画面表示部（Ｓ３１１１，Ｓ３１１６１，Ｓ３１１７１）は、前回、被災状況の情報を入力する画面を起動してから所定時間が経過した場合に被災状況の情報を入力する画面を再び表示し、前記端末情報送信部（Ｓ３１１８）は、前記再び表示された画面に被災状況の情報が入力された場合には入力された被災状況の情報を被災者端末（３０）の識別情報及び位置情報とともに前記サーバー（１０）に送信し被災状況の情報が入力されない場合には被災者端末（３０）の識別情報及び位置情報を前記サーバー（１０）に再び送信し、前記トリアージカテゴリー設定部（Ｓ１１２２）は、前記端末情報送信部（Ｓ３１１８）から再び受信した情報に基づいてトリアージカテゴリーを更新する、災害ネットワークシステムである。

第５の態様は、第４の態様の災害ネットワークシステムにおいて、前記トリアージカテゴリー設定部（Ｓ１１２２）は、現在保存されているトリアージカテゴリーが準優先カテゴリーであって、今回端末情報送信部（Ｓ３１１８）から受信した情報に被災状況の情報が含まれていない場合は、トリアージカテゴリーを最優先カテゴリーにする、災害ネットワークシステムである。

第６の態様は、第４又は第５の態様の災害ネットワークシステムにおいて、前記トリアージカテゴリー設定部（Ｓ１１２２）は、前記端末情報送信部（Ｓ３１１８）から受信した情報に被災状況の情報が含まれていないことが所定回数連続した場合は、トリアージカテゴリーを非優先カテゴリーにする、災害ネットワークシステムである。

第７の態様は、第１から第６までのいずれかの態様の災害ネットワークシステムにおいて、前記サーバー（１０）に組み込まれ、前記回避エリア特定部（Ｓ１１２３１）で特定された回避すべきエリアの情報を前記被災者端末（３０）に送信する回避エリア情報送信部（Ｓ１１２４）と、前記被災者端末（３０）に組み込まれ、前記回避エリア情報送信部（Ｓ１１２４）から受信した回避すべきエリアの情報に基づいて、回避すべきエリアを避けつつ、避難所に向かうための避難ルートを設定する避難ルート設定部（Ｓ３１２）と、を有する、災害ネットワークシステムである。

第８の態様は、第１から第７までのいずれかの態様の災害ネットワークシステムにおいて、前記サーバー（１０）に組み込まれ、家族が避難する場所の情報を家族の他のメンバーに通知する家族情報通知部（Ｓ１８３）を有する、災害ネットワークシステムである。

この態様によれば、詳細な災害状況を把握することが可能になる。

図１は、本発明に係る災害ネットワークシステムの第１実施形態の構成について説明する図である。 図２は、第１実施形態の災害発生時の処理を示すフローチャートである。 図３は、被災状況入力処理を示すフローチャートである。 図４は、救助要否画面の一例を示す図である。 図５は、個人状況入力処理を示すフローチャートである。 図６は、個人状況入力画面の一例を示す図である。 図７は、個人状況入力画面の別の例を示す図である。 図８は、周囲状況入力処理を示すフローチャートである。 図９は、周囲状況入力画面の一例を示す図である。 図１０は、周囲状況入力画面の別の例を示す図である。 図１１は、周囲状況入力画面のさらに別の例を示す図である。 図１２は、個人状況入力画面及び周囲状況入力画面に表示される質問の一例を列挙する図である。 図１３は、状況整理処理を示すフローチャートである。 図１４は、トリアージカテゴリー設定処理を示すフローチャートである。 図１５は、周囲状況整理処理を示すフローチャートである。 図１６は、トリアージ処理を示すフローチャートである。 図１７は、救助員端末の画面の表示例を示す図である。 図１８は、所有者情報の登録処理（初期登録）を示すフローチャートである。 図１９は、家族登録の処理を示すフローチャートである。 図２０は、子供登録の処理を示すフローチャートである。 図２１は、ペット登録の処理を示すフローチャートである。 図２２は、家族登録抹消の処理を示すフローチャートである。 図２３は、情報修正確認処理を示すフローチャートである。 図２４は、避難所情報処理を示すフローチャートである。 図２５は、本発明に係る災害ネットワークシステムの第３実施形態の構成について説明する図である。 図２６は、第３実施形態の被災状況入力処理を示すフローチャートである。 図２７は、第３実施形態の個人状況入力処理を示すフローチャートである。 図２８は、第３実施形態の周囲状況入力処理を示すフローチャートである。

以下、添付図面を参照しながら本発明の実施形態について説明する。

（第１実施形態）
図１は、本発明に係る災害ネットワークシステムの第１実施形態の構成について説明する図である。

図１に示すように、災害ネットワークシステム１は、サーバー１０と、被災者端末３０と、救助員端末４０とを含む。被災者端末３０及び救助員端末４０は、ネットワーク２０によってサーバー１０に接続され、通信プロトコル（たとえば、ＴＣＰ／ＩＰ）を介してデータを送受信可能になっている。なお、ネットワーク２０は、たとえば、インターネット、専用通信回線（たとえばＣＡＴＶ（Community Antenna Television）回線）、移動体通信網（基地局等を含む）、ゲートウェイ等によって構築されている。

サーバー１０は、高速処理可能な大型コンピューターであり、サーバー管理者が操作する操作部や表示部などが接続されている。

被災者端末３０は、被災エリアとして想定されるエリアにいるが特段の権限のない一般使用者によって各自所有されている端末であり、たとえばスマートフォンやタブレット端末などである。被災者は、被災者端末３０を操作して、種々の情報を入力したり取得する。

救助員端末４０は、消防隊員や自衛隊員などの特別権限を有する救助隊員が操作する機器である。救助員端末４０としては、たとえば、スマートフォンやタブレット端末などである。

続いて、災害ネットワークシステム１の具体的なロジックについて、フローチャートを参照して説明する。

図２は、第１実施形態の災害発生時の処理を示すフローチャートである。この処理は、災害の発生をトリガーとして開始される。

まずはじめに、ステップＳ１１１において、サーバー１０は、被災エリアとして想定されるエリアにある端末（被災者端末）３０に対して、災害エリアメールを送信する。この災害エリアメールは、緊急速報メールのように特定のエリアにある端末に対して通知するものである。

この通知を受けて、ステップＳ３１１において、被災者端末３０は、被災状況入力処理を実行する。ここで、図３を参照して被災状況入力処理の具体的な内容について説明する。なおこの被災状況入力処理は、サーバー１０から送信された災害エリアメールを受信したタイミングで実行されるが、他にも救助要否画面表示処理（ステップＳ３１１１）が実行されてから、所定時間ごとに繰り返し実行される。

ステップＳ３１１１において、被災者端末３０は、図４に例示されているような救助要否画面を表示する。図４では「救助が必要ですか？」という質問とともに、「はい」「いいえ」の回答ボタンが表示されている。なおアラームを鳴らしながら画面を起動すれば、端末使用者の注意を引くことができるので、好ましい。

ステップＳ３１１２において、被災者端末３０は、救助要否画面に表示されているボタンが押されたか否かを判定する。そして、被災者端末３０は、判定結果が否であればステップＳ３１１３へ処理を移行し、肯であればステップＳ３１１４へ処理を移行する。

ステップＳ３１１３において、被災者端末３０は、救助要否画面に表示されているボタンが押されないまま所定時間が経過したか否かを判定する。そして、被災者端末３０は、判定結果が否の間はステップＳ３１１２へ処理を戻し、肯になったらステップＳ３１１８へ処理を移行する。

ステップＳ３１１４において、被災者端末３０は、押されたボタンが救助不要ボタンか否かを判定する。そして、被災者端末３０は、判定結果が否であればステップＳ３１１５へ処理を移行し、肯であればステップＳ３１１７へ処理を移行する。

ステップＳ３１１５において、被災者端末３０は、前回押されたボタンが救助必要ボタンか否かを判定する。そして、被災者端末３０は、判定結果が否であればステップＳ３１１６へ処理を移行し、肯であればステップＳ３１１８へ処理を移行する。なお、初めての処理の場合は、前回処理が無い。この場合は、判定結果が否であるので、被災者端末３０はステップＳ３１１６へ処理を移行する。

ステップＳ３１１６において、被災者端末３０は、個人状況入力処理を実行する。ここで、図５を参照して個人状況入力処理の具体的な内容について説明する。

ステップＳ３１１６１において、被災者端末３０は、図６に例示されているような個人状況入力画面を表示する。図６では、「どのような状況ですか？」という質問とともに、「動けない」「出られない」「挟まれている」「閉じ込められている」の回答ボタンが表示される。なお、「どのような状況ですか？」に対する回答は、図１２に示されているように「動けない」「出られない」「挟まれている」「閉じ込められている」「出血している」「ひどい怪我をしている」「中程度の怪我をしている」「軽い怪我をしている」「水が迫っている」「水につかっている」などであるが、すべてを一画面に表示してしまうと、各ボタンが小さくなってしまう。そこで、図６のように、適宜な数の回答ボタンを表示することが好ましい。

ステップＳ３１１６２において、被災者端末３０は、個人状況入力画面に表示されているボタンが押されたか否かを判定する。そして、被災者端末３０は、判定結果が否であればステップＳ３１１６３へ処理を移行し、肯であればステップＳ３１１６４へ処理を移行する。

ステップＳ３１１６３において、被災者端末３０は、個人状況入力画面に表示されているボタンが押されないまま所定時間が経過したか否かを判定する。そして、被災者端末３０は、判定結果が否の間はステップＳ３１１６２へ処理を戻し、肯になったら処理を抜ける。

ステップＳ３１１６４において、被災者端末３０は、回答されていない個人状況入力画面があるか否かを判定する。なお、個人状況入力画面としては、図６に続いて、「出血している」「ひどい怪我をしている」「中程度の怪我をしている」「軽い怪我をしている」「水が迫っている」「水につかっている」などの回答画面がある。さらに、図７に例示されているように、「同じような人が周囲にいますか？」という質問とともに、「自分だけ」「自分の他に１人いる」「自分の他に２人いる」「自分の他に３人以上いる」という回答画面がある。

再び、図３に戻る。ステップＳ３１１７において、被災者端末３０は、周囲状況入力処理を実行する。ここで、図８を参照して周囲状況入力処理の具体的な内容について説明する。

ステップＳ３１１７１において、被災者端末３０は、図９に例示されているような周囲状況入力画面を表示する。図９では「周囲に救助が必要な人はいますか？」という質問とともに、「いる」「いない」の回答ボタンが表示される。なお「いる」が選択された場合には、さらに状況を確認するための質問画面になる。

ステップＳ３１１７２において、被災者端末３０は、周囲状況入力画面に表示されているボタンが押されたか否かを判定する。そして、被災者端末３０は、判定結果が否であればステップＳ３１１７３へ処理を移行し、肯であればステップＳ３１１７４へ処理を移行する。

ステップＳ３１１７３において、被災者端末３０は、周囲状況入力画面に表示されているボタンが押されないまま所定時間が経過したか否かを判定する。そして、被災者端末３０は、判定結果が否の間はステップＳ３１１７２へ処理を戻し、肯になったら処理を抜ける。

ステップＳ３１１７４において、被災者端末３０は、回答されていない周囲状況入力画面があるか否かを判定する。そして、被災者端末３０は、判定結果が肯の間はステップＳ３１１７１へ処理を戻し、否になったら処理を抜ける。なお、周囲状況入力画面としては、図９に続いて、図１２に示されているような「停電していますか？」「ガス漏れはありますか？」「水道の漏水はありますか？」「倒壊した建物はありますか？」「通れない道路はありますか？」「使えない橋はありますか？」などの回答画面がある。なお、図１０に示した「倒壊した建物はありますか？」という質問画面に対して、「ある」が選択された場合には、図１１に示されているように、「倒壊した建物を撮影してください」という画面になって、被災者端末３０の操作者に対して倒壊した建物の撮影を促す。シャッターボタンが押されて撮影された場合は、この撮影データが周囲状況情報として位置情報とともに送信される。このようにすることで、被災状況が把握されやすくなる。

再び、図３に戻る。ステップＳ３１１８において、被災者端末３０は、サーバー１０に情報を送信する。なおこの情報には、たとえば被災者端末３０の識別情報（電話番号），位置情報（ＧＰＳ情報），救助要否情報などが含まれ、さらに、救助が必要な場合は被災者端末３０に入力された個人状況情報が含まれ、救助が不要な場合は被災者端末３０に入力された周囲状況情報などが含まれる。

再び、図２に戻る。ステップＳ１１２において、サーバー１０は、被災者端末３０から受信した情報に基づいて状況整理処理を実行する。ここで、図１３を参照して状況整理処理の具体的な内容について説明する。

ステップＳ１１２１において、サーバー１０は、被災者端末３０から送信された情報に基づいて、救助が必要か否かを判定する。そして、サーバー１０は、判定結果が肯であればステップＳ１１２２へ処理を移行し、否であればステップＳ１１２３へ処理を移行する。

ステップＳ１１２２において、サーバー１０は、トリアージカテゴリー設定処理を実行する。ここで、図１４を参照してトリアージカテゴリー設定処理の具体的な内容について説明する。

ステップＳ１１２２１において、サーバー１０は、個人状況情報があるか否かを判定する。そして、サーバー１０は、判定結果が否であればステップＳ１１２２２へ処理を移行し、肯であればステップＳ１１２２３へ処理を移行する。

ステップＳ１１２２２において、サーバー１０は、トリアージカテゴリーの情報が無いか否かを判定する。そして、サーバー１０は、判定結果が肯であればステップＳ１１２２３へ処理を移行し、否であればステップＳ１１２２４へ処理を移行する。

ステップＳ１１２２３において、サーバー１０は、トリアージカテゴリーを設定する。具体的には、たとえば、「動けない」「出られない」等の状況毎にポイントが予め決められており、このポイントに応じて、救助の優先度が最も高い最優先カテゴリー／救助の優先度が最優先カテゴリーの次に高い準優先カテゴリー／救助の優先度が最も低い非優先カテゴリーを設定する。また、状況情報が無い場合は、救助の優先度を決めることを保留する保留カテゴリーにする。

ステップＳ１１２２４において、サーバー１０は、現在のトリアージカテゴリーが準優先カテゴリーであるか否かを判定する。そして、サーバー１０は、判定結果が肯であればステップＳ１１２２５へ処理を移行し、否であればステップＳ１１２２６へ処理を移行する。

ステップＳ１１２２５において、サーバー１０は、トリアージカテゴリーを最優先カテゴリーにする。すなわち、前回準優先カテゴリーであった場合に、今回個人状況情報が入力されていないときには、端末操作者が気を失っているなどの事態が想定される。そこでトリアージカテゴリーを最優先カテゴリーにする。

ステップＳ１１２２６において、サーバー１０は、状況情報無しの状態が所定回数続いたか否かを判定する。そして、サーバー１０は、判定結果が否であればステップＳ１１２２７へ処理を移行し、肯であればステップＳ１１２２８へ処理を移行する。

ステップＳ１１２２７において、サーバー１０は、現在のトリアージカテゴリーを継続する。

ステップＳ１１２２８において、サーバー１０は、トリアージカテゴリーを非優先カテゴリーにする。すなわち、状況情報無しの状態が所定回数（所定時間）続いた場合には、この端末操作者の救助よりも他の被災者の救助を優先すべく、トリアージカテゴリーを非優先カテゴリーにする。

ステップＳ１１２２９において、サーバー１０は、トリアージカテゴリーを、被災者端末３０の識別情報（電話番号）や位置情報（ＧＰＳ情報）と対応させて保存する。なおこの保存は、過去の内容（履歴）を消去してしまう上書き保存であっても、過去の内容（履歴）とともに今回の内容も保存する追記保存であってもよい。

再び、図１３に戻る。ステップＳ１１２３において、サーバー１０は、周囲状況整理処理を実行する。ここで、図１５を参照して周囲状況整理処理の具体的な内容について説明する。

ステップＳ１１２３１において、サーバー１０は、被災者端末３０から受信した周囲状況情報に基づいて回避すべきエリア（以下適宜「回避エリア」と称す）を特定する。ここで「回避すべきエリア（回避エリア）」とは、被災者や救助員が近寄ると危険であるので回避すべきエリアや、救急車・消防車などをはじめとする救助車両が走行するのに適していないので回避すべきエリアなどである。救助車両は、軽自動車サイズから大型車両サイズまで、異なるサイズのさまざまな車種がある。ある救助車両では通行できなくても、他の救助車両では通行可能な場合もある。そこで、救助車両ごとに車両サイズに応じた回避エリアを特定しておくことが一層好ましい。なおサーバー１０には、多くの被災者端末３０から情報が送られてくる。サーバー１０は、これらの情報に基づいて回避エリアを特定する。このように、多くの情報に基づいて回避エリアを特定するので、誤情報を排除でき、信頼性を高めることができる。

ステップＳ１１２３２において、サーバー１０は、回避エリアの情報を保存する。

再び、図１３に戻る。ステップＳ１１２４において、サーバー１０は、被災者端末３０に回避エリア情報を送信する。なお、このときに送信する回避エリア情報とは、被災者が近寄ると危険であるので回避すべきエリアに関する情報である。

再び、図２に戻る。ステップＳ３１２において、被災者端末３０は、サーバー１０から送信された回避エリア情報を受信する。被災者端末３０は、この情報に基づいて避難ルートを設定することで、回避エリアを避けて避難所までのナビゲーションを行うことができる。

再び、図１３に戻る。ステップＳ１１２５において、サーバー１０は、トリアージカテゴリーの情報及び回避エリアの情報に基づいて救助ルートを設定する。なお、このときの回避エリア情報とは、救助員が近寄ると危険であるので回避すべきエリアや、救助車両が走行するのに適していないので回避すべきエリアに関する情報である。救助車両は、軽自動車サイズから大型車両サイズまで、異なるサイズのさまざまな車種がある。ある救助車両では通行できなくても、他の救助車両では通行可能な場合もある。そこで、救助車両ごとに車両サイズに応じた回避エリアに基づいて救助ルートを設定することが好ましい。サーバー１０は、消防隊や自衛隊の各分隊（救助班）が、上述の回避エリアを避けて最優先カテゴリーに分類された被災者端末３０（被災者）が多いエリアに効率的に向かうことができるルートを設定する。

ステップＳ１１２６において、サーバー１０は、救助員端末４０に救助ルートの情報を送信する。

再び、図２に戻る。サーバー１０から送信された情報を受けて、ステップＳ４１１において、救助員端末４０は、トリアージ処理を実行する。ここで、図１６を参照してトリアージ処理の具体的な内容について説明する。

ステップＳ４１１１において、救助員端末４０は、画面上のマップにトリアージカテゴリーを表示する。この表示は、たとえば、最優先カテゴリーを赤丸／準優先カテゴリーを黄丸／非優先カテゴリーを黒丸／保留カテゴリーを白丸で表示する。

ステップＳ４１１２において、救助員端末４０は、画面上のマップに回避エリアを表示する。

ステップＳ４１１３において、救助員端末４０は、画面上のマップに救助へ向かうべきルートを表示するとともに現在地を表示することでナビゲーションを行う。

救助員端末４０の使用者（消防隊員や自衛隊員）は、救助員端末４０の画面に表示されたルートを進んで被災者の救助に向かう。

本実施形態によれば、災害が発生した場合に、被災者端末３０は、エリアメールをトリガーとして災害状況入力画面を起動する。そして、この災害状況入力画面に被災状況の情報が入力されたら、その情報をサーバー１０に送信し、サーバー１０で一括的に管理する。したがって、このサーバー１０にアクセスするための権限を有する者が、災害発生直後から迅速に被災状況を把握できることとなる。

被災状況の報告が、実際に災害発生地にいる者によって入力された被災状況の情報によるので、被災状況を詳細に把握することができる。

また、大量な情報を容易に集めることができ、誤情報を排除でき、情報の信頼性を高めることができる。

そして、この被災状況の情報が、消防署員や自衛隊員などの特別権限を有する者が操作する端末４０に送信されるので、消防署員や自衛隊員などの救助活動に役立つ。

たとえば、図１７に示されているように道が格子状に広がっており、「×」を付した道が危険であって通行できないとする。丸囲みの数字が最優先カテゴリーとされた被災者の人数である。本実施形態を使用するＡ救助班は、現在地からまっすぐに北上して、最優先カテゴリーの被災者が３２人いる場所で救助活動を行う。Ｂ救助班は、現在地から西進して最優先カテゴリーの被災者が２０人いる場所で救助活動を行い、その後、通行不可道路を避けて、最優先カテゴリーの被災者が１５人いる場所に向かう。

このように、本実施形態によれば、被災情報に基づいて、各救助班が救助へ向かうべきルートを一元管理しているので、複数の救助班が同一の場所に行ってしまうなどの無駄を省くことができ、限られた人的資源を効率よく配置することが可能になる。なお、各救助班が救助へ向かうルートは、最優先カテゴリーの被災者の人数だけに基づくのではなく、たとえば最優先カテゴリーについてはポイント５０／準優先カテゴリーについてはポイント１などのポイントを定めて、ポイントの総計に応じて優先すべき救助ルートを設定してもよい。この場合、最優先カテゴリーの被災者が１人だけいるところよりも、準優先カテゴリーの被災者が５１人以上いるところに優先して救助ルートを設定することとなる。また救助車両が通れない道を避けて救助ルートを設定するので、安全かつ効率的な救助ルートを設定することができ、一層効率的な救助活動を行うことが可能になる。

また、本実施形態では、どういう被災者たちをどういうルートで救助することによって、できるだけ多くの人命を救うことができるか、ということをサーバー１０が機械的に設定する。現在の救助現場ではトリアージができていない。そのことが救助現場での大きな問題である。救助員が、救出する被災者（救出対象者）について、現場で判断すると、被救助者の家族などから「助けてください」と泣きつかれてしまった場合に、その場を離れることができなくなってしまう。このような場合に、その１人を救助することと引き替えに、別の現場の多くの人を救助できなくなる、という事態が少なくない。

これに対して、本実施形態では、サーバー１０が被災者の場所・人数・傷病の程度などに基づいて機械的に救出対象者を決めて救助ルートを設定して、いわば、サーバー１０が救助員に命令して、救助員もその指示に従って行動すればよく、救助員の精神的な負担が軽減される。結果として、最大限の人命を救助することが可能になる。

サーバー１０は、被災状況の情報に基づいて回避エリアを特定し、その情報を被災者端末３０に送信する。被災者は、この情報（回避エリア情報）を利用することで、現在地から避難所までのルートを決める際に、この回避エリアを避けたルートを得ることができる。

たとえば、現在地から避難所までの最短ルートに回避エリアがある場合に、回避エリアの情報がなければ、回避エリアに向かって進んで行くこととなってしまう。たとえば、煙が多くて視界が悪いもののその先は安全なエリアが広がっていても、被災者は煙の多い方向には進むことなく、回避エリアに進んでしまうような事態が生じ得る。これに対して、本実施形態では、回避エリア情報を利用することで、回避エリアを避けたルートを得ることができ、被災者が安全に避難することができる。煙が多くても、その先に安全なエリアが広がっていることが分かっていれば、被災者は迷うことなく安全なエリアに避難することが可能である。

また道幅の狭い路地は、現時点では危険でなくても、避難ルートには適さない。そこで、このような路地も避難ルートに適さないとして避けてルートを示すことも可能である。

（第２実施形態）
この第２実施形態では、被災者端末３０の所有者情報を予め登録しておく。このようにすることで、家族を同一の避難所（二次避難所）に案内したり、妊婦や子連れあるいはペットを飼っているなどのような境遇が同じ人を同一の避難所（二次避難所）に案内することが可能になる。具体的な内容について、フローチャートを参照して説明する。

図１８は、所有者情報の登録処理（初期登録）を示すフローチャートである。この処理は、一般使用者がスマートフォン（被災者端末３０）にインストールされているアプリケーションプログラム（以下適宜「アプリ」と称す）を起動することで表示された所有者情報登録ボタンを押すことで開始される。基本的には災害が発生する前に一般使用者が自分の情報を登録するためにこの処理を実行しておくことが望ましい。

ステップＳ３２１において、端末３０は、所有者情報登録画面を表示する。端末３０の使用者が、携帯電話番号（端末番号）・氏名・生年月日・性別・住所・職業・持病・かかりつけ医・常用薬などを入力する。なお入力項目としては、これらに限られず、マイナンバー（個人番号）や現在受けている治療などを加えてもよい。

各項目の入力後に使用者が、画面に表示されている登録ボタンを押したら、ステップＳ３２２において、端末３０は、所有者情報が登録されたことを表示する。

図１９は、家族登録の処理を示すフローチャートである。この処理は、一般使用者がスマートフォン（端末３０）にインストールされているアプリを起動することで表示された家族登録ボタンを押すことで開始される。基本的には災害が発生する前に一般使用者が家族登録を行うためにこの処理を実行しておくことが望ましい。

ステップＳ３３１１において、端末３０−１は、「家族登録したい携帯電話番号を入力してください」というコメントを表示する。端末３０−１の使用者が、家族登録したい携帯電話番号を入力し、登録ボタンを押したら、端末３０−１は、その情報をサーバー１０に送信する。

この情報を受けて、ステップＳ１３１において、サーバー１０は、入力された携帯電話番号宛てに認証コードをＳＭＳ（Short Message Service）送信を行う。

この情報を受けて、ステップＳ３３２１において、端末３０−２は、受信した認証コードを表示する。

表示された認証コードを見た端末３０−１の使用者によって、その認証コードが入力されて登録ボタンが押されたら、端末３０−１は、その認証コード情報をサーバー１０に送信する（ステップＳ３３１２）。

この認証コード情報を受けて、ステップＳ１３２において、サーバー１０は、認証コード情報が正しいか否かを判定する。そして、サーバー１０は、判定結果が肯であればステップＳ１３３に処理を移行し、否であればステップＳ１３３をスキップする。

ステップＳ１３３において、サーバー１０は、端末３０−１及び端末３０−２に登録処理情報を送信する。

この情報を受けて、ステップＳ３３１３において、端末３０−１は、所有者情報に家族情報を追加登録するとともに、ステップＳ３３２２において、端末３０−２も、所有者情報に家族情報を追加登録する。

図２０は、子供登録の処理を示すフローチャートである。この処理は、一般使用者がスマートフォン（端末３０）にインストールされているアプリを起動することで表示された子供登録ボタンを押すことで開始される。

ステップＳ３４１において、端末３０は、子供登録画面を表示して、粉ミルクが必要か否かを尋ねるコメントを表示する。端末３０への入力情報が否であればステップＳ３４２に処理を移行し、肯であればステップＳ３４３に処理を移行する。

ステップＳ３４２において、端末３０は、画面に、紙オムツが必要か否かを尋ねるコメントを表示する。端末３０への入力情報が肯であればステップＳ３４４に処理を移行し、否であればステップＳ３４５に処理を移行する。

ステップＳ３４３〜ステップＳ３４５において、端末３０は、子供の名前及び生年月日の入力画面を表示する。端末３０の使用者が、子供の名前及び生年月日を入力し、画面に表示されている登録ボタンを押したら、端末３０は、ステップＳ３４６において、その情報（子供の名前及び生年月日並びに粉ミルク及び紙オムツの必要性）を、所有者情報に追加登録する。なお粉ミルクが必要な年齢であれば、紙オムツも必要であるので、ステップＳ３４１において粉ミルクが必要とされた場合は、紙オムツも必要とされている。

図２１は、ペット登録の処理を示すフローチャートである。この処理は、一般使用者がスマートフォン（端末３０）にインストールされているアプリを起動することで表示されたペット登録ボタンを押すことで開始される。

ステップＳ３５１において、端末３０は、ペット登録画面を表示して、ドッグフードが必要か否かを尋ねるコメントを表示する。端末３０への入力情報が否であればステップＳ３５２に処理を移行し、肯であればステップＳ３５３に処理を移行する。

ステップＳ３５２において、端末３０は、画面に、キャットフードが必要か否かを尋ねるコメントを表示する。端末３０への入力情報が肯であればステップＳ３５４に処理を移行し、否であればステップＳ３５５に処理を移行する。

ステップＳ３５３〜ステップＳ３５５において、端末３０は、ペットの名前の入力画面を表示する。端末３０の使用者が、ペットの名前を入力し、画面に表示されている登録ボタンを押したら、端末３０は、ステップＳ３５６において、その情報を、所有者情報に追加登録する。

図２２は、家族登録抹消の処理を示すフローチャートである。この処理は、一般使用者がスマートフォン（端末３０）にインストールされているアプリを起動することで表示された家族登録抹消ボタンを押すことで開始される。ここでは、図１９において家族登録した端末３０−２の使用者が、端末３０−１との家族登録を抹消したい場合を例示して説明する。

ステップＳ３６１において、端末３０−２は、「家族登録を抹消したい携帯電話番号を入力してください」というコメントを表示する。端末３０−２の使用者が、家族登録を抹消したい携帯電話番号（端末３０−１の携帯電話番号）を入力し、抹消ボタンを押したら、端末３０−２は、入力された携帯電話番号（端末３０−１の携帯電話番号）の家族登録を所有者情報から抹消する（ステップＳ３６２）。

図２３は、情報修正確認処理を示すフローチャートである。この処理は、災害の発生をトリガーとして開始される。

ステップＳ１１１において、サーバー１０は、災害エリアとして想定されるエリアの端末３０に対して、災害エリアメールを送信する。

この情報を受けて、ステップＳ３７１１において、端末３０−１は、登録してある所有者情報を表示する。

ステップＳ３７１２において、端末３０−１は、「登録情報の修正がありますか？」というコメントを表示する。端末３０−１の使用者が修正ありを入力したら、端末３０−１はステップＳ３７１３に処理を移行し、修正なしを入力したら、端末３０−１はステップＳ３７１３をスキップする。

ステップＳ３７１３において、端末３０−１は、修正された情報を登録する。なお端末３０−１の使用者が、端末３０−２の使用者との家族登録の抹消を希望する場合は、図２２に示された家族登録抹消の処理を実行する。

一方、ステップＳ１１１においてサーバー１０から送信された情報を受けた端末３０−２は、ステップＳ３７２１において、登録してある所有者情報を表示する。

ステップＳ３７２２において、端末３０−２は、「登録情報の修正がありますか？」というコメントを表示する。端末３０−２の使用者が修正ありを入力したら、端末３０−１はステップＳ３７２３に処理を移行し、修正なしを入力したら、端末３０−２はステップＳ３７２３をスキップする。

ステップＳ３７２３において、端末３０−２は、修正された情報を登録する。なお端末３０−２の使用者が、端末３０−１の使用者との家族登録の抹消を希望する場合は、図２２に示された家族登録抹消の処理を実行する。

災害が発生する前に一般使用者が自分の情報を登録しておけば、災害が発生していろいろと混乱している状況での登録作業を回避できるので便利である。しかしながら、情報を登録してから災害が発生するまでに長期間が経過していることも考えられる。この間に情報が変わっていることも十分想定されるので、災害が発生したタイミングで、この情報修正処理で登録情報の確認修正を行うのである。

なお予め情報登録されていない場合は、被災者が避難所（一次避難所又は二次避難所）に到着して初めて情報を登録する。この場合は、ステップＳ３７１１，ステップＳ３７２１で表示される情報がない。この場合、被災者が、ステップＳ３７１３，ステップＳ３７２３で最初から情報を入力する。

図２４は、避難所情報処理を示すフローチャートである。この処理は、図２３のアプリ起動処理が完了した後、実行される。

ステップＳ３８１１において、端末３０−１は、避難所情報が必要か否かを尋ねるコメントを表示する。端末３０−１への入力情報が肯であれば、端末３０−１は、ステップＳ３８１２に処理を移行してその情報をサーバー１０に送信する。一方、端末３０−１への入力情報が否であれば、端末３０−１は、ステップＳ３８１２以下をスキップする。

ステップＳ３８１２において送信された情報を受けて、ステップＳ１８１において、サーバー１０は、避難所に関する情報を端末３０−１に送信する。

この情報を受けて、ステップＳ３８１３において、端末３０−１は、避難所に関する情報を表示する。避難所に関する情報としては、たとえば現在地からの距離，収容規模，現在の収容人数（男女別／大人小人別），今後の避難予測人数，ペット受入の可不可などである。

端末３０−１の使用者がこれらの情報を確認して希望する避難所を選択すると、端末３０−１は、ステップＳ３８１４において、画面に回避エリア情報を反映した避難所までの経路を表示するとともに、ステップＳ３８１５において、端末３０−１の使用者が選択した避難所の情報を、端末３０−１に登録されている所有者情報ととともにサーバー１０に送信する。なお、送信に先立って、家族登録されているメンバーに情報が連絡されることが表示され、必要であれば家族登録を抹消しておくことの注意書きが表示される。

ステップＳ３８１５において送信された情報を受けて、ステップＳ１８２において、サーバー１０は、受信した情報を登録するとともに、上述の「今後の避難予測人数」を算出する。また、端末３０−１に登録されている家族の端末（端末３０−２）に情報を送信する。

ステップＳ１８２において送信された情報を受けて、ステップＳ３８２１において、端末３０−２は、家族登録された情報であるか否かを判定し、判定結果が肯であれば、端末３０−２は、ステップＳ３８２２に処理を移行してその情報をサーバー１０に送信する。一方、判定結果が否であれば、端末３０−２は、ステップＳ３８２２以下をスキップする。

ステップＳ３８２２において送信された情報を受けて、ステップＳ１８３において、サーバー１０は、端末３０−１から受信した「選択された避難所」の情報を、端末３０−２に送信する。

ステップＳ１８３において送信された情報を受けて、ステップＳ３８２３において、端末３０−２は、家族が選択した避難所を表示する。

以上説明した実施形態によれば、家族がどこの避難所を選択したのが分かるので、家族の他のメンバーもその避難所を目指して避難することができる。また、避難所に関する情報（現在の収容人数（男女別／大人小人別），ペット受入の可不可など）が表示されるので、妊婦や子連れあるいはペットを飼っているなどのような境遇が同じ人が同一の避難所に集まりやすくなる。また、そのような境遇が同じ人を同一の避難所に案内するようにルート表示してもよい。なおルートは、第１実施形態で説明した通り、回避エリアを避けて設定される。

過去に家族情報を登録してから災害が発生するまでに長期間が経過していることもあり得る。この間に情報が変わっていることも考えられ、このような場合に自分が向かう避難所の情報を知らせたくないことも想定される。災害が発生したタイミングで、家族情報などを修正するので、不必要な情報開示を回避することが可能になり、家族関係に変化があった場合のトラブルを防止することができる。

また、家族登録を要望する端末所有者の端末に入力された、家族登録したい端末番号の情報を受信した場合に、その端末番号に対して認証コードを送信する。そして、その認証コードが、家族登録を要望する端末所有者の端末に入力された場合に、家族登録が要望された端末を、家族登録を要望する端末所有者の端末に家族登録するようにした。このようにしたので、誤登録を防止することができる。

さらに、子供の情報の登録を要望する端末所有者からの情報を受信した場合に、その子供情報を、要望する端末所有者の所有者情報に追加して保存するようにした。このようにしたので、携帯通信端末を所有していない子供の情報であっても、登録することができる。

さらにまた、ペットの情報の登録を要望する端末所有者からの情報を受信した場合に、そのペット情報を、要望する端末所有者の所有者情報に追加して保存するようにした。このようにしたので、ペット情報であっても、登録することができ、避難所でのドッグフード・キャットフード等の物資管理が容易になる。

（第３実施形態）
図２５は、本発明に係る災害ネットワークシステムの第３実施形態の構成について説明する図である。

図２５に示すように、災害ネットワークシステム１は、図１に示されている第１実施形態の構成に加えて、さらにウェアラブル端末５０を含む。

ウェアラブル端末５０は、個人ごとに所有されて所有者の心拍数や血圧などの生体情報を検出する端末であり、腕時計型のスマートウォッチや、心拍数等を検出するセンサーが組み込まれているスマートシャツなどを例示することができる。ウェアラブル端末５０は、検出した生体情報を携帯通信端末３０に送信する。なお、被災者端末３０がたとえば腕時計型に構成されて、さらに所有者の心拍数や血圧などの生体情報を検出する機能が組み込まれることで、ウェアラブル端末５０が被災者端末３０によって兼用されるタイプであってもよい。

図２６は、第３実施形態の被災状況入力処理を示すフローチャートである。

基本的には、図３に示されている第１実施形態と同様であるが、第１実施形態の構成に加えて、さらにステップＳ３１１０１を含む。

ステップＳ３１１０１において、端末３０は、被災状況が入力されないまま所定時間が経過した場合に（ステップＳ３１１３でＹｅｓ）、所有者の心拍数や血圧などの生体情報（ウェアラブル端末の情報）を個人状況情報とする。なお、所定時間は、端末３０の所有者が意識を失っているなどして端末３０を操作することができないと推定される時間であり、たとえば３０分程度である。この所定時間が経過するまでは、一定時間ごとに端末３０やウェアラブル端末５０のアラームを鳴らしたり、バイブレーターを作動させることで被災状況の入力を促すことで、被災状況の入力忘れを防止できる。

図２７は、第３実施形態の個人状況入力処理を示すフローチャートである。

基本的には、図５に示されている第１実施形態と同様であるが、第１実施形態の構成に加えて、さらにステップＳ３１１６０１を含む。

ステップＳ３１１６０１において、端末３０は、被災状況が入力されないまま所定時間が経過した場合に（ステップＳ３１１６３でＹｅｓ）、所有者の心拍数や血圧などの生体情報を個人状況情報とする。なお、所定時間は、端末３０の所有者が意識を失っているなどして端末３０を操作することができないと推定される時間であり、たとえば３０分程度である。この所定時間が経過するまでは、一定時間ごとに端末３０やウェアラブル端末５０のアラームを鳴らしたり、バイブレーターを作動させることで被災状況の入力を促すことで、被災状況の入力忘れを防止できる。

図２８は、第３実施形態の周囲状況入力処理を示すフローチャートである。

基本的には、図８に示されている第１実施形態と同様であるが、第１実施形態の構成に加えて、さらにステップＳ３１１７０１を含む。

ステップＳ３１１７０１において、端末３０は、被災状況が入力されないまま所定時間が経過した場合に（ステップＳ３１１７３でＹｅｓ）、所有者の心拍数や血圧などの生体情報を個人状況情報とする。なお、所定時間は、端末３０の所有者が意識を失っているなどして端末３０を操作することができないと推定される時間であり、たとえば３０分程度である。この所定時間が経過するまでは、一定時間ごとに端末３０やウェアラブル端末５０のアラームを鳴らしたり、バイブレーターを作動させることで被災状況の入力を促すことで、被災状況の入力忘れを防止できる。

本実施形態によれば、端末３０の所有者が意識を失っているなどして端末３０を操作することができない場合に、心拍数や血圧などの生体情報から緊急性を要すると判断されるときに、救助を優先するというトリアージに役立てることができる。

以上、本発明の実施形態について説明したが、上記実施形態は本発明の適用例の一部を示したに過ぎず、本発明の技術的範囲を上記実施形態の具体的構成に限定する趣旨ではない。

たとえば、所有者情報として登録する内容は、上記に限られない。

上記実施形態は、適宜組み合わせ可能である。

一般使用者が操作する端末（たとえばスマホ）に、本システム用のアプリをデフォルトでインストールしておけば、端末使用者が情報を入力しやすいので好ましい。

なお特許請求の範囲における「被災状況の情報」とは、救助要否画面で入力される「救助要否の情報」，個人状況入力画面で入力される「個人状況の情報」，周囲状況入力画面で入力される「周囲状況の情報」などである。

１０ サーバー
３０ 被災者端末（携帯通信端末）
４０ 救助員端末（携帯通信端末）
５０ 生体情報検知端末
Ｓ１１１ エリアメール送信部
Ｓ１１２２ トリアージカテゴリー設定部
Ｓ１１２２９ カテゴリー情報保存部
Ｓ１１２３１ 回避エリア特定部
Ｓ１１２４ 回避エリア情報送信部
Ｓ１１２５ 救助ルート設定部
Ｓ１１２６ 救助情報送信部
Ｓ１８３ 家族情報通知部
Ｓ３１１１，Ｓ３１１６１，Ｓ３１１７１ 入力画面表示部
Ｓ３１１８ 端末情報送信部
Ｓ４１１１ 救助情報表示部

Claims (8)

1. サーバーと携帯通信端末とを含む災害ネットワークシステムであって、
   前記サーバーに組み込まれ、災害が発生した場合に被災エリアとして想定されるエリアにある携帯通信端末（以下「被災者端末」と称す）に対してエリアメールを送信するエリアメール送信部と、
   前記被災者端末に組み込まれ、前記エリアメールを受信してその被災者端末の表示部に被災状況の情報を入力する画面を表示する入力画面表示部と、
   前記被災者端末に組み込まれ、前記画面に被災状況の情報が入力された場合には入力された被災状況の情報を被災者端末の識別情報及び位置情報とともに前記サーバーに送信し被災状況の情報が入力されない場合には被災者端末の識別情報及び位置情報を前記サーバーに送信する端末情報送信部と、
   前記サーバーに組み込まれ、前記端末情報送信部から受信した情報に対して、救助の優先度が最も高い最優先カテゴリー／救助の優先度が最優先カテゴリーの次に高い準優先カテゴリー／救助の優先度が最も低い非優先カテゴリー／救助の優先度を決めることを保留する保留カテゴリーのいずれかのトリアージカテゴリーを設定するトリアージカテゴリー設定部と、
   前記サーバーに組み込まれ、前記トリアージカテゴリー設定部で設定されたトリアージカテゴリーの情報を被災者端末の識別情報及び位置情報と対応させて保存するカテゴリー情報保存部と、
   前記サーバーに組み込まれ、前記端末情報送信部から受信した情報に基づいて、回避すべきエリアを特定する回避エリア特定部と、
   前記サーバーに組み込まれ、前記カテゴリー情報保存部に保存されている各被災者のトリアージカテゴリー及び位置の情報並びにある場所における被災者の人数に基づいて各救助班の救出対象者を機械的に決めて各救助班が救助活動を行う場所を機械的に設定し、その救助活動を行う場所に各救助班が前記回避エリア特定部で特定された回避すべきエリアを避けて向かう救助ルートを機械的に設定する救助ルート設定部と、
   前記サーバーに組み込まれ、前記カテゴリー情報保存部に保存されたトリアージカテゴリーを、対応する被災者端末の位置情報とともに救助員が操作する携帯通信端末（以下「救助員端末」と称す）に送信するとともに、前記回避エリア特定部で特定された回避すべきエリアの情報及び前記救助ルート設定部で設定された救助ルートを前記救助員端末に送信する救助情報送信部と、
   前記救助員端末に組み込まれ、その救助員端末の表示部に地図を表示するとともに前記救助情報送信部から受信した情報を表示する救助情報表示部と、
   を有する、災害ネットワークシステム。
2. 請求項１に記載の災害ネットワークシステムにおいて、
   前記トリアージカテゴリー設定部は、前記端末情報送信部から受信した情報に被災状況の情報が含まれていない場合には、トリアージカテゴリーとして保留カテゴリーを設定する、
   災害ネットワークシステム。
3. 請求項１又は請求項２に記載の災害ネットワークシステムにおいて、
   所有者の生体情報を検知し、その生体情報を、ペアリングされている被災者端末に送信する生体情報検知端末をさらに含み、
   前記端末情報送信部は、被災状況の情報が入力されない場合には、前記生体情報検知端末から受信した生体情報を被災状況の情報として、被災者端末の識別情報及び位置情報とともに前記サーバーに送信する、
   災害ネットワークシステム。
4. 請求項１から請求項３までのいずれか１項に記載の災害ネットワークシステムにおいて、
   前記入力画面表示部は、前回、被災状況の情報を入力する画面を起動してから所定時間が経過した場合に被災状況の情報を入力する画面を再び表示し、
   前記端末情報送信部は、前記再び表示された画面に被災状況の情報が入力された場合には入力された被災状況の情報を被災者端末の識別情報及び位置情報とともに前記サーバーに送信し被災状況の情報が入力されない場合には被災者端末の識別情報及び位置情報を前記サーバーに再び送信し、
   前記トリアージカテゴリー設定部は、前記端末情報送信部から再び受信した情報に基づいてトリアージカテゴリーを更新する、
   災害ネットワークシステム。
5. 請求項４に記載の災害ネットワークシステムにおいて、
   前記トリアージカテゴリー設定部は、現在保存されているトリアージカテゴリーが準優先カテゴリーであって、今回端末情報送信部から受信した情報に被災状況の情報が含まれていない場合は、トリアージカテゴリーを最優先カテゴリーにする、
   災害ネットワークシステム。
6. 請求項４又は請求項５に記載の災害ネットワークシステムにおいて、
   前記トリアージカテゴリー設定部は、前記端末情報送信部から受信した情報に被災状況の情報が含まれていないことが所定回数連続した場合は、トリアージカテゴリーを非優先カテゴリーにする、
   災害ネットワークシステム。
7. 請求項１から請求項６までのいずれか１項に記載の災害ネットワークシステムにおいて、
   前記サーバーに組み込まれ、前記回避エリア特定部で特定された回避すべきエリアの情報を前記被災者端末に送信する回避エリア情報送信部と、
   前記被災者端末に組み込まれ、前記回避エリア情報送信部から受信した回避すべきエリアの情報に基づいて、回避すべきエリアを避けつつ、避難所に向かうための避難ルートを設定する避難ルート設定部と、
   を有する、災害ネットワークシステム。
8. 請求項１から請求項７までのいずれか１項に記載の災害ネットワークシステムにおいて、
   前記サーバーに組み込まれ、家族が避難する場所の情報を家族の他のメンバーに通知する家族情報通知部を有する、
   災害ネットワークシステム。

Images