JP6811947B2 - 災害時情報管理システム、これに用いるサーバ装置及び端末装置 - Google Patents

Description

本発明は、災害時情報管理システム、前記システムを構成するサーバ装置、及び前記サーバ装置と無線通信を行う端末装置に関する。特に、災害発生現場においてインターネットや携帯電話網などの商用情報通信網が使用できない環境下で、様々な情報を統一的に管理し、端末装置のユーザに提供する災害時情報管理システム、前記システムを構成するサーバ装置、及び前記サーバ装置と無線通信を行う端末装置に関する。

災害発生時において、被災者の救助や支援物資の補給などに必要な災害現場の情報の収集・共有は非常に重要である。従来、それらの情報の収集・共有は、紙に書いた後、避難所などに掲示するか、人づてに伝言するなどの方法を用いて行われていた。しかし、上記の様な方法では、多くの人に情報が伝搬するのに時間がかかる問題や、伝言による情報誤りが発生する等の問題があった。

上記問題を解決するものとして、特許文献１では、支援物資及び人に識別情報を付与し、それらをデータベース（ＤＢ）で管理することで、支援物資を被災者に迅速に届ける仕組みと様々な生存支援サービスを支援するためのシステム構築法を開示している。しかし、当該システムは支援物資の分配法及びそれに伴う費用の精算等に主眼が置かれており、人命救助の初動期体制構築などの支援を目的としたものではない。また、複数の避難所等の間での情報共有は考慮されていない。

特開２０１３−２２５２５９号公報

"高度化するトリアージ," JST News, Vol.6, No.9, December 2009.http://www.jst.go.jp/pr/jst-news/2009/2009-12/page08.html Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, and Hari Balakrishnan, "Chord: A scalable peer-to-peer lookup service for Internet applications," SIGCOMM 2001, Aug. 2001.

上記従来技術におけるシステムでは、支援物資の分配法及びそれに伴う費用の精算等に主眼が置かれており、人命救助の初動期体制構築などの支援を目的としたものではない。また、複数の避難所等の間での情報共有は考慮されていない。

従って、本発明の目的は、上記問題を解決するためのものであり、被災者間あるいは救助者間の情報共有を促進するだけでなく、インターネットや携帯電話等の情報通信網等が使用できない状況下において、孤立した複数のサーバ間の情報共有を、利用者の端末装置を媒介して行うことを可能とする災害時情報管理システムを提供することにある。

上記課題を解決する本発明に従う災害情報管理システムは、一側面において、公衆通信網が一切使用できない環境に於いて使用される災害時情報管理システムであって、一つのサーバ装置と、前記サーバ装置と無線通信によりデータ通信が可能である複数の端末装置から構成され、前記サーバ装置は、演算処理装置として、前記複数の端末装置の各々から入力される所有者の個人情報及び災害時関連情報を一元管理する管理手段として機能し、
前記管理手段で一元管理される情報に基づいて、前記災害時関連情報に含まれる要求物資の有無を検索する検索手段として機能し、傷病者を救助するための救助チームの編成と担当傷病者の割り振り、救助のための危険箇所を避けた最適経路を探索する探索手段として機能し、更に、前記検索手段により検索される要求物資の有無及び前記探索手段により探索される最適経路を二次情報として前記各端末装置に送る送信手段として機能することを特徴とする。

上記課題を解決する本発明に従う災害情報管理システムは、前記一側面において、第一の態様として、前記災害時関連情報として、少なくとも物資の要求・供給、危険箇所、傷病者のトリアージ情報を含むことを特徴とする。

上記課題を解決する本発明に従う災害情報管理システムは、前記一側面において、第二の態様として、前記複数の端末装置は、物資の要求および供給情報を入力する入力手段を有し、前記サーバ装置の前記検索手段は、前記端末装置から収集した情報をもとに、物資の需要と供給の照合を行い、その照合結果を、前記物資の要求または供給する旨の情報に対応する前記二次情報として出力することを特徴とする。

上記課題を解決する本発明に従う災害情報管理システムは、前記一側面において、第三の態様として、前記探索手段は、危険箇所や避難所、入力された物資の存在位置情報を地図上に表示し、被災者または救助者が、当該危険箇所を避け、最短で目的地まで到達できる経路情報を当該地図上に表示し、前記地図上に表示される物資の存在位置情報と経路情報を前記二次情報として出力することを特徴とする。

上記課題を解決する本発明に従う災害情報管理システムは、前記一側面において、第四の態様として、前記サーバ装置を失った場合に、システムを構成する前記複数の端末装置同士で、Peer to Peer (P2P)通信ネットワークを構成し、前記サーバ装置で本来管理すべき情報を持ち合うことを特徴とする。

上記課題を解決する本発明に従う災害情報管理システムは、第二の側面として、前記一側面の災害時情報管理システムを複数システム有し、前記複数の災害時情報管理システムのそれぞれにおける複数のサーバ装置間で直接通信出来ない状況において、前記サーバ装置に蓄積された情報を、前記サーバ装置間を行き交う携帯端末を媒介として、交換する手段を有することを特徴する。

上記課題を解決する本発明に従う災害情報管理システムは、前記第一又は第二の側面において、前記一つのサーバ装置または前記複数のサーバ装置、及び前記複数の端末装置がVPN(Virtual Private Network、仮想プライベートネットワーク)を動的に構成し、前記VPNを用いて、前記複数の端末装置間または前記サーバ装置との間のデータ転送を行うことを特徴とする。

上記課題を解決する本発明に従う災害情報管理システムに使用される前記第一又は第二の側面における前記一つのサーバ装置または前記複数のサーバ装置は、前記管理手段として情報を管理するデータベースと、前記検索手段による要求物資の有無の検索及び／又は、前記探索手段による最適経路の探索の際に使用する地図情報を処理する地図サーバと、前記地図情報を用いて前記二次情報を作成するためのユーザインタフェースとを有することを特徴とする。

上記課題を解決する本発明に従う災害情報管理システムにおける前記第一の態様に使用される端末装置は、演算処理手段を有し、前記演算処理手段により処理される情報を画面表示する表示手段と、前記表示手段に順次表示される前記画面表示に従って必要事項を入力することにより傷病者のトリアージを実施することを特徴とする。

本発明の構成を使用すれば、従来、掲示板と電話等を用いて行っていた災害現場での救助活動や物資の配給が、一元管理され、混乱を避けながら迅速に実施できるようになる。

本発明に従う災害時情報管理システムの実施形態の一構成例を示す概念図である。 サーバ装置内のデータベースに蓄積された情報を用いて、救助チームを編成する過程を図示したものである。 トリアージの手順フローを示す図である。 傷病者の情報入力のための医師等が行うトリアージの入力画面を示す図である。 端末装置の情報出力機能の一例である。 端末装置の画面構成例である。 図５の「需要」ボタンを押下したときに現れる画面例である。 物資要求が端末装置から検索条件入力という形であった場合の、端末装置とサーバ装置間の処理フローを示す図である。 自分の保有する物資を提供する場合のメニュ画面例である。 物資供給が端末装置から成された場合の処理フローを示している。 サーバ装置間が直接通信できない場合に、端末装置を媒介してサーバ装置内に蓄積された情報を互いに共有する例を説明する図である。 サーバ装置が故障または電波の届かない位置にある場合の対応を示す図である。 サーバ装置、及び各端末装置に備えるべき機能を実装の面から整理した図である。

以下に図面を参照して本発明に従う実施の形態を説明する。なお、かかる実施の形態は、本発明の理解のためのものであって、本発明の適用はこれに限定されない。本発明の技術的範囲は、特許請求の範囲の記載及びこれに類似の範囲も含まれる。

図１は、本発明に従う災害時情報管理システムの実施形態の一構成例を示す概念図である。サーバ装置１と通信機能を有する複数の携帯可能な端末装置２（２_１〜２ｎ）を有する。

なお、本実施の形態例で用いる携帯可能な端末装置２は、本発明を実行する専用端末として用意し、避難所等で、被災者や救助者に直接配布する形で準備する装置であってもよいし、日常人々が使用している携帯端末、スマートフォンやタブレット端末に、本発明を実行するソフトウエアをインストールする形で実現してもよい。したがって、本発明の説明において、携帯可能な端末装置は、以降単に端末装置と称する。

それぞれの端末装置２とサーバ装置１は無線通信３により情報の授受が可能である。また、当該無線通信３は、マルチホップ通信をサポートする。例えば、図１中、端末装置２_３は、直接サーバ装置１と通信できない位置にあっても、端末装置２_２及び端末装置２_１を介して、サーバ装置１と通信することができる。

かかる実施の形態構成において、本発明の実現のためにサーバ装置１は、演算処理装置であって、前記複数の端末装置の各々から入力される所有者の個人情報及び災害時関連情報を一元管理する管理手段として機能し、前記管理手段で一元管理される情報に基づいて、前記災害時関連情報に含まれる要求物資の有無を検索する検索手段として機能し、傷病者を救助するための救助チームの編成と担当傷病者の割り振り、救助のための危険箇所を避けた最適経路を探索する探索手段として機能し、更に、前記検索手段により検索される要求物資の有無及び前記探索手段により探索される最適経路を二次情報として前記各端末装置に送る送信手段として機能する。

具体的には、サーバ装置１は、データベース１０、地図サーバ１１、データベース同期機構１２、及びグラフィカルユーザインタフェース（ＧＵＩ）１３を備えて構成される。

地図サーバ１１は、端末装置２あるいはサーバ装置１内の図示しない管理プログラムからの求めに応じて地図情報を提供するものである。

データベース１０は、後述する様々な情報を格納するものであり、ＧＵＩ１３を通して、格納した情報を整理統合する機能も有する。

データベース同期機構１２は、複数のサーバ装置がある場合に、各サーバ装置１内のデータベース１０に格納してある情報をサーバ装置間で同じになるように調整する（これを、同期と呼ぶ）ためのものである。ＧＵＩ１３は、データベース１０に蓄積されたデータを操作する機能を有する。

サーバ装置１は、本発明の適用においては基本的に避難所等に設置され、頻繁に移動することはない。一方、端末装置２は移動することを前提とする。複数の端末装置２_１〜２ｎ間または端末装置２とサーバ装置１間の無線通信３はIEEE802.11bなどの標準的な無線ＬＡＮを用いてネットワーク構築可能であり、ルーティングプロトコルとして標準化されているＡＯＤＶ（Ad hoc On-Demand Distance Vector）プロトコルなどの動的ルーティング方式を採用すれば，上述したマルチホップ通信が実現できる。

ここで、本発明を実行するソフトウエアをインストールする形で端末装置を実現する場合は、サーバ装置１に当該ソフトウエアを置き、無線通信３を用いて、端末装置２にダウンロードする仕組みを提供するようにしてもよい。また、インターネットなど公衆通信網が使える状況において、商用ソフトウエア配布サービスや、独自に設置したダウンロード専用機構に当該ソフトウエアを置き、公衆通信網を経由して、端末装置２側からダウンロードさせるようにしてもよい。

なお、前記サーバ装置１からの信号を待たずに、ユーザ自らが直接当該アプリケーションソフトウエアを操作し、本発明の端末装置側の機能が発現する形にしてもよい。

図２は、サーバ装置１内のデータベース１０に蓄積された情報を用いて、救助チームを編成する過程を図示したものである。まず、登録者リスト１００から、チームメンバとなる人を選択し、救助チーム１０１を編成する。図２では、救助チーム１０１として、第１の救助チーム１０１Ａのメンバとして登録者１，３，４，７が、第２の救助チーム１０１Ｂのメンバとして登録者２，５，６が選択されている。次に、各々編成された救助チーム１０１Ａ，１０１Ｂに対して、担当する傷病者を傷病者リスト１０２から選択し、担当リスト１０２として作成する。

図２では、救助チーム１０１Ａが担当する傷病者は担当リスト１０２Ａの傷病者１傷病者３,及び傷病者５となる。同様に、救助チーム１０１Ｂが担当する傷病者は担当リスト１０２Ｂの傷病者２及び傷病者４となる。さらに、当該救助者のいる位置は、傷病者リスト１０２の位置情報をもとに認識され、図１の地図サーバ１１から取得する地図上に、当該場所が表示されると共に、各救助チームメンバが集合する集合地点及び、その集合地点から経路をたどり、担当傷病者を救うための救助経路１０３Ａ，１０３Ｂが救助チーム１０１Ａ，１０１Ｂ毎に作成される。

上記の準備が整った後、各救助チーム情報が、当該メンバの端末装置２に、無線通信を用いて送られる。図２では、救助チーム１０１Ａのチーム情報は、そのメンバである登録者１，３，４，７へ送られる。同様に、救助チーム１０１Ｂのチーム情報は、そのメンバである登録者２，５，６へ送られる。

上述した一連のデータベース操作は、ＧＵＩ１３を用いて行うことでもよいし、登録者のプロフィール、例えば、登録者が医師である場合、脳外科、整形外科など専門分野の情報と、傷病者の詳細情報から得た情報、例えば、頭部外傷、骨折などの症状と照らし合わせ、より適切な登録者と傷病者のマッチングを図り、データベース１０により自動でチーム情報を作成する方法で行ってもよい。また、携行物資情報１０４Ａ，１０４Ｂも、在庫物資リスト１０４に基づき、傷病者の症状に合わせて、自動で作成するようにしてもよい。

さらに、チームメンバの追加削除、担当リストの変更、携行物資の追加なども、任意の時刻でできるものとし、変更された情報は、サーバ装置１側から強制的あるいは定期的に、チームメンバの端末装置２に送信される。また、かかる変更された情報は、端末装置２からのデータ交換要求に応じて、送られる様にしてもよい。

一方、端末装置２側に具備する機能は、大きくは、２つにわかれ、一つは情報入力機能、他方は情報出力機能である。

情報入力機能は、図２の登録者、物資、傷病者（トリアージ）に関する情報入力を可能とするＧＵＩが用意されている。登録者のプロフィール、すなわち、氏名、性別、年齢、属性（医師、消防、看護師、救急、ボランティア、被災者、その他）、専門知識、性別などの個人情報は、入力画面を通して、最初に各端末装置２の使用者が入力する。

物資情報に関しても、入力画面を用意し、物資名、数量、提供/要求の別、提供/要求の場所、その他補足事項などを入力できるものとする。また、非常時に必要となる毛布、食料などの物資は、予めメニュとして用意し、当該物資を選択する形にする入力画面を用意することにより、端末装置２における入力の簡便さを図ることとしてもよい。

傷病者の情報入力は、医師等が行うトリアージの入力画面を提供することにより行う。図３Ａ，図３Ｂはその一例である。図３Ａに示したフローチャートは、ＳＴＡＲＴ式と一般に呼ばれるトリアージ法の手順を示したものである。傷病者を、その様態により４段階（赤、黄、緑、黒）に色分けし、当該色のタグを傷病者の左腕等に付け、救助の優先度を付ける作業である。

本発明では、従来、トリアージタグにペンで情報を書き込み、直接対象傷病者に付ける作業であった所を、端末装置２で必要情報を入力し、最終的にサーバ装置１のデータベースで全ての傷病者を一元管理しようとするものである。

図３Ｂに、上記フローチャートの各判断箇所に相当する端末装置２の入力画面([1]〜[7])に従って情報入力を行うと、４種類のどの色（救助の優先度）かが決定される。
図３Ｂにおける[番号]は、図３Ａの手順に対応している。

本実施の形態例では、傷病者の識別を行うために、トリアージタグに一意のバーコードを付与しておき、そのバーコードを端末装置２のバーコードリーダ機能を用いて読み込む。これにより、実際に傷病者に付けたトリアージタグと、入力情報をヒモ付け、データベース１０に登録された情報がどの傷病者の情報か判別できるようにしている。

図３Ｂの画面[8]〜[11]の下側にある「ＩＤスキャン」ボタン２０を押下すると、端末装置のバーコードリーダ機能が起動する。さらに、端末装置２のＧＰＳ受信機能を用いて、傷病者の地理的位置も同時にデータベース１０上に登録する。なお、バーコードではなく、トリアージタグに付された一意性を保証するＩＤ番号を手入力することもできる。ここで、ＩＤを手入力する場合、トリアージタグに、その近傍で重ならない程度の比較的短い数字をＩＤとして印字しておき、それを手入力した後、端末装置２のＩＤ及び、その位置情報や日時を加味して、一意性を確保したＩＤを端末装置２またはサーバ装置１内で生成し、それを用いることでもよい。

加えて、上述したトリアージ方法よらず、他の方法により、トリアージ情報を取得してもよい。例えば、非特許文献１では、センサと無線通信機能を備えた電子トリアージタグが提案されている。それを活用し、図１のサーバ装置に直接トリアージ情報をあげる方法でもよい。

また、トリアージに於いて、傷病者の傷病箇所を簡便に入力出来るように、人体の絵を端末装置画面に表示し、当該画面にタッチするなどして当該傷病箇所を指示させ、指示と同時に、典型的な傷病名を列挙表示し、その中から該当傷病名を選択することで傷病者の状況を入力する様にしてもよい。例えば、画面の表示された人体の腕の部分をタッチすると、骨折、打撲、裂傷、といった傷病名が現れ、その中から当該項を選ぶ事で入力が完了するようにする。加えて、それら入力された傷病箇所の情報に基づいて、上述したトリアージが自動で行われるようにしてもよい。

図４は、端末装置２の情報出力機能の一例である。地図上に、避難所３０（３１）及び端末装置２の現在位置３２が表示される他、災害等で、現在通行できない地点も“×”で表示されている。また、ユーザが要求した物資（図４では、水３３と食料３４）が、どこにあるかも示している。

さらに、水３３を求め、避難所３１に行く場合、安全かつ最短の誘導経路３５も表示されている。通行不可の場所は、各端末装置２の保有者が、当該箇所の情報を入力し、サーバ装置１のデータベース１０に登録されたものである。上記誘導経路３５の探索は、図１のサーバ装置内の地図サーバ１１が行い、その結果を端末装置２に送ることで実現する。本地図表示は、先に述べた救助チームが傷病者の救助に向かうときの経路表示としても活用する。

各端末装置２に於いては、誘導経路３５に従って、端末装置２の保有者を目的地まで、音声または画面表示を用いて、実際に経路誘導（ナビゲーション）する機能が使用できるようにし、不慣れな土地でも、迷わず目的地に到達するようにしてもよい。

図５は端末装置２の画面構成例である。画面上の（ア）〜（サ）はそれぞれ、ボタンであり、対応するボタンを押下することで、それに対応した操作ができる。ボタン（ア）の押下により図２で構成した救助チーム情報が表示される。ボタン（イ）は、設定メニュを表示するものであり、自分のプロフィールや端末表示形式等に関する情報を入力するときに用いる。ボタン（ウ）は、物資の要求（需要）を出すときに用いる。ボタン（エ）は、その逆に、自分の持っている物資を供給できる時に、当該情報を入力するときに用いる。ボタン（オ）は、様々な状況を把握・表示するときに用いる。表示される内容は、図４の地図情報や、救助チームに参加している場合は、チームに関する連絡事項などの表示にも用いる。ボタン（カ）は、通行不可の場所や危険情報などを入力する際に用いる。

ボタン（キ）は、データ交換のためのボタンであり、当該ボタンが押されると端末装置２に保有しているデータをサーバ装置１に向けて送信するとともに、サーバ装置１からの新たな情報を受信する。このボタン（キ）を押さなくても、端末装置２は一定時間ごとにサーバ装置１とデータ交換のための通信を行うが、即座にデータ交換を行いたいときに用いる。

ボタン（ク）は端末装置２の位置情報をサーバ装置１に送信する際に用いる。端末装置２の位置情報は、設定により、自動的かつ定期的にサーバ装置１に送るようにすることも別途設定によりできる。ＭＥＮＵボタン（ケ）が、押下されると、画面(ｅ)が表示される。これは、端末装置２における本発明のシステムを用いる時の初期画面である。TRIAGEボタン(コ)はトリアージを行うときに用いるボタンであり、押下されると、図５(ｃ)の画面に移行する。

なお、実際のトリアージの際は、図５(ｃ)の画面中央の”TRIAGE”と書かれた大きなボタンを押下すると、図３Ａに示したフローチャートに従った画面が表示される。REPORTSボタン（サ）を押下すると、当該端末装置２で行ったトリアージの結果を表示する図５（ｄ）のリポート画面が現れる。

ここで、端末装置２で利用できるメニュは、医師、消防、ボランティア、被災者などのユーザの属性によって、制限することにより、不要な操作や混乱を避けるようにする。図５(ａ)は、救助チームに参加している医師の端末装置画面であり、ボタン（イ）（ウ）（エ）すなわち、「設定」及び物資の「需要」「供給」ボタンは押下できないようになる。これは、救助活動中は物資関連の入力は行う事はなく、また、任務に当たっているときは、個人のプロフィールなどの変更はできないようにするためである。

一方、図５(ｂ)の画面は、被災者の端末装置の画面であり、救助チームの「チーム情報」ボタン（ア）及び右下のトリアージボタン（コ）及びそのリポートボタン（サ）は不要であり、使用できない状態になっている。このように、端末装置保有者の属性（立場）によって、使用できるメニュ・ボタンに、自動的に制限をかけることにより、誤操作を防ぐ。

端末装置２の保有者の属性は、例えば被災者の立場からボランティアの立場など、自ら状況に合わせ変更が可能であり、それに応じて使用できるメニュが変化する。また、救助チームの一員として救助活動に従事しているときは、サーバ装置１からの指令で、属性を個人で変更できないように制御できる。

図６は、図５の「需要」ボタン（ウ）を押下したときに現れる画面例である。本画面を通して、必要な物資やその数量、必要な日時、受け取り方法、物資に対して対価を払えるか否か（有料・無料）の情報６０を入力し、「検索する」ボタン６１を押すと、ヒットした物資があればその一覧６２が、ヒットしなければその旨６３が表示される。

また、物資の名前をキーワードとして手入力する代わりに、メニュ６４から選択するようにしてもよい。場所の指定に関しても、地図を表示し、地図上の地点や範囲を指定することで、エリアを指定することでもよい。

図７は、図５の「需要」ボタン（ウ）が押下された時、すなわち物資要求が端末装置２から検索条件入力という形であった場合の、端末装置２とサーバ装置１間の処理フローを示している。

端末装置２から検索条件が入力されると（ステップＳ１）、入力情報はサーバ装置１に送信される（ステップＳ２）。サーバ装置１において、データベース１０に登録された検索条件と一致する物資の情報があるかを判断し（ステップＳ３）、一致するものがあれば（ステップＳ３，あり）、検索結果を並べ換え（ステップＳ４）、「需要要求」を送信した端末装置２に送信する。

端末装置２では、検索結果を選択し（ステップＳ５）、選択結果をサーバ装置１に送信する（ステップＳ６）。これにより、需要処理が成功（ステップＳ７）となる。

一方、ステップＳ３で、検索条件に一致するものがない（ステップＳ３，なし）場合には、その旨が端末装置２に通知される。従って、先に送った需要要求項目をサーバ装置１に登録するか否かを該当の端末装置２において判断する。

一致する供給物資を待つ場合には、そのままサーバ装置1に登録する場合は（ステップＳ８，はい）、一致した物資の供給を一定期間待つ（ステップＳ９）。一致した物資の供給可能がサーバ装置１で検索されると、サーバ装置１からその旨が該当の端末装置２に通知される（ステップＳ１０）。以降の処理は、先の説明したステップＳ４−Ｓ７の処理に繋がる。

ステップＳ８で、サーバ装置１に登録しない（ステップＳ８，いいえ）場合及び、一致した供給待ち（ステップＳ９）で所定期間を過ぎると時間切れとなり、先の需要要求は失敗したことになる。

図８は、自分の保有する物資を提供する場合のメニュ画面例であり、図５の「供給」ボタン（エ）が押されたときに端末装置２に出現する画面である。供給できる物資の情報７０を入力した後、「供給する」の登録ボタン７１を押下すると当該物資情報が供給可能物資として、サーバ装置１のデータバース１０に登録される。

ここで、登録した物資への要求が、既に誰かからある場合は、即座に合致する要求がある旨の表示７２が画面に現れ、「詳細」ボタン７３を押すと、他者が、図６の「需要」画面で入力した物資要求情報の詳細７４が表示される。合致する要求がない場合は、サーバ装置内のデータベース１０に当該供給物資情報が登録され、端末装置２には、その旨の画面表示７５がされる。

図９は、図８の「供給」ボタン（エ）が押下された時、すなわち物資供給が端末装置２から成された場合の処理フローを示している。

端末装置２から供給情報の入力が行われると（ステップＳ２０）、その情報は、サーバ装置１に送られる（ステップＳ２１）。サーバ装置１は、受信した供給情報をデータベース１０に登録する（ステップＳ２２）。

先に図７の（ステップＳ９）で説明した供給待ちがあり、時間内であれば（ステップＳ２３）、サーバ装置１から該当の端末装置２に通知される（ステップＳ２４）。これを前記する端末装置２のユーザが確認する（ステップＳ２５、図７のステップＳ４−Ｓ７参照））。

ステップＳ２３で需要待ちが時間切れ（図７、ステップＳ９参照）であれば、供給失敗（ステップＳ２７）となる。但し、供給データは、データベース１０に登録されているので、後の需要に対して物資を直ちに供給することが可能である。

上記したように物資の需要・供給の要求管理は、サーバ装置１とそれが保有するデータベース１０で行われる。なお、図７で示した物資の検索フロー、及び図９で示した物資の登録に際しての、要求（需要）の確認処理は、図６及び図８の画面で入力された情報に従って、サーバ装置１内で、一定時間毎に実行され、物資の需要・供給の照合が図られる。

実際に照合した場合は、需要者端末装置及び供給者端末装置双方に、照合した旨の表示がなされる。なお、当該表示形式は、図６の「検索結果あり」の場合の画面６２、及び図７の「合致要求あり」の場合の画面７２に準じる。

ここで、上記した実施の形態例は、サーバ装置１が一台の場合であったが、複数のサーバ装置を広域に展開する形で本発明システムを拡張使用することもできる。その場合、サーバ装置間が直接通信できない場合に、端末装置２を媒介してサーバ装置１内に蓄積された情報を互いに共有することができる。

図１０はかかる直接通信できないサーバ装置１間での情報共有の例を示している。今、３台のサーバ装置１_１,１_２,１_３がある場合を考える。端末装置２ａは、サーバ装置１_１内に蓄積されたデータｘをダウンロードし、移動経路aを通って、サーバ装置１_２に到着した時、預かったデータｘをサーバ装置１_２にアップロードする。これにより、サーバ装置１_１のデータはサーバ装置１_２に移行できる。

また、上記の動作と並行して、端末装置２ｂは、サーバ装置１_２に蓄積されたデータｙをダウンロードし、移動経路ｂを通って、サーバ装置１_３に向かおうとしている状態を考える。そのとき、端末装置２ｂは、端末装置２ａとすれ違いざまに通信ができる機構を備え、端末装置２ａは、データｘのコピーを端末装置２ｂに渡す。

その状態で、端末装置２ｂがサーバ装置１_３に到達した場合、端末装置２ｂはデータｙとデータｘをもっているので、サーバ装置１_３は、サーバ装置１_１とサーバ装置１_２のデータを同時に受信できる。

上述したデータ移行は、全ての端末装置２で行われ、多くの端末装置２がサーバ装置１間を行き交うことで、サーバ装置１間のデータ同期が可能となる。

また、各端末装置２は、必ずしも決められた移動経路を通る必要はなく、上記の端末同士のすれ違いざまのデータ交換を繰り返すことで、効率的なサーバ装置１間のデータ同期を実現できる。

かかる場合、端末装置の一形態として、定期的にサーバ装置１間を行き交う自律移動可能の移動端末２２ｃを考えることもできる。移動端末２２ｃは、サーバ装置１間（避難所に設置されている場合は、避難所間と等価）を定期的に行き交うボランティアや医療関係者が携行する無線端末や、計画運行をする車載無線端末やドローン（無人飛行機）などを利用して実現できる。その場合、移動経路ｃは、決められた経路となる。これにより、計画的にサーバ装置１間のデータ移行が可能となる。

加えて、移動端末２２ｃが、どのサーバ装置とも直接通信できない端末装置２ｄのデータを預かり、サーバ装置１_３に届けることもできる。このように、端末装置（あるいは移動端末）の導入により、直接通信が不可能なサーバ装置間のデータ同期を行うことができる。

ここで、端末装置２のすれ違いざま通信は、具体的にはWiFiでもよいし、Bluetooth（登録商標）などの近傍無線通信機能を使用してもよい。

上述した移動端末２２ｃを含む端末装置２を媒介してデータを転送する技術は、DTN(Delay Tolerant Network)として良く知られており、最も一般的な方法は、各端末装置は他の端末装置とすれ違う度に、自分の保有する全てのデータを相互に交換するというものである。

これは、すれ違った端末装置同士が、互いに相手の端末装置がどこに行くか知らない場合、確実に目的のサーバ装置にデータを届けるために有効な方法である。しかし、すれ違う度に、各端末が全てのデータを交換すると、多くの同一データの複製が各端末の存在することになり、各端末装置２に大容量記憶メモリを持つ必要が生じるばかりでなく、そのデータを交換するために、無線通信の衝突（ふくそう）が生じる可能性が高くなるという不具合が発生する。

それを防ぐ第一の方法は、各端末装置２のユーザが、サーバ装置１間を移動する場合は、自分の端末装置２に、事前に、移動先サーバ装置名(ID)を入力することである。各端末装置２（移動端末２２ｃを含む）は、すれ違いざまに、相互通信により、相手端末装置２がこれから向かうサーバ装置１が分かるので、その情報をもとに、相手に託すデータを選択的に送ることができる。

例えば、すれ違った相手端末装置２がサーバ装置１ｃに行く端末であれば、サーバ装置１ｃへ送りたいデータを託すというものである。移動端末２２ｃに関しては、計画的にサーバ装置１間を移動するため、基本的に第一の方法が適用できる。また、第二の方法として、各端末装置２に移動履歴を保持しておき、相手端末装置２が頻繁に訪れるサーバ装置１があれば、当該サーバ装置１に送りたいデータを託すという方法もある。例えば、頻繁にサーバ装置１ｃに行く端末とすれ違った場合は、サーバ装置１ｃへ送りたいデータを託すというものである。

さらに、第三の方法として、すれ違った端末装置２の移動方向が、地理的に目的のサーバ装置１のある方向であれば、その端末装置２に当該サーバ装置１に向けたデータを託す方法もある。

なお、サーバ装置１間で移行するデータ量が多い場合は、一度に全てのデータを端末装置２（あるいは移動端末２２ｃ）にダウンロードすることはできないため、適宜分割して送ることになる。

そのための制御を行うのが、図１のサーバ装置１内に設けたデータベース同期機構１２である。データベース同期機構１２は、自分の保有するデータの内、どのデータを既に送信したか（端末に託したか）を管理する。他のサーバ装置１から受け取ったデータも同様に管理し、同じデータを複数受信することを避ける。

送出したデータが、他のサーバ装置１で受けとられたか否かを確認したい場合は、当該データを受け取ったサーバ装置１が、当該データの受け取り通知(ACK)パケットを、端末装置２に託すことで実現する。ACKパケットは、送信元サーバ装置ID及びデータIDに加え、当該データを受け取ったサーバ装置１のID情報を含んでいる。当該ACKパケットが送信元のサーバ装置１に到達すれば、当該サーバ装置１は、どのサーバ装置が、自分が保有するどのデータを受け取ったかを認識でき、それ以降、当該データを繰り返し送出することを避けることができる。

ここで、上記構成において、各サーバ装置１から端末装置２に託されるデータの行き先サーバ装置IDは、データ自身に添付するものとする。よって、端末装置２同士のすれ違いざま通信に於いて交換される各データの最終宛先サーバ装置IDは、当該宛先サーバ装置１に届くまで、各データ内に保持される。

また、複数のサーバ装置１を配置する場合、互いに直接通信できない状態であっても、自分がデータ同期をとるべきサーバ装置IDは、事前に別途、各サーバ装置１に設定されるものとする。勿論、別途設定することなく、端末装置２に託すデータの宛先サーバ装置ＩＤを任意ID、すなわち、ブロードキャストとすることを許し、当該データが届いたサーバ装置１からのACKパケットを受信し、そのACKパケットに保持されている受信したサーバ装置IDを参照することにより、自分の周囲に当該サーバ装置１が存在することを認識し、そのサーバ装置IDを、自分がデータ同期をとるべきサーバ装置IDの別途設定に代えて使用する方法を採用してもよい。

図１１はサーバ装置１が故障または電波の届かない位置にある場合の対応を示す図である。図１１において、各端末装置２_１，２_３，２_４，２_７がP2P(Peer to Peer)通信ネットワークを用いて、データを持ち合いサーバ装置１がなくても、情報共有ができる仕組みを構成することもできる。

例えば、図１１に於いて、救助チーム１０１Ａを構成する登録者1, 登録者3, 登録者4, 登録者7の端末装置２をそれぞれ端末装置２_１, 端末装置２_３, 端末装置２_４, 端末装置２_７とする。図１１のように、救助チームＡのチーム情報は、端末装置２_１, 端末装置２_３、 端末装置２_４に既に配布済みで、端末装置２_７のみ当該情報を受信していない状態であり、さらにサーバ装置１と通信できないとする。その場合、登録者１，登録者３, 登録者４, 登録者７の端末同士で構成されるP2P通信ネットワークを用いて、登録者１, 登録者３, 登録者４が持つ救助チーム１０１Ａのチーム情報の全部あるいは一部を端末装置２_７に送る。これにより、端末装置２_７は、サーバ装置１から受けるべきチーム情報を得ることができる。

なお、具体的なP2P通信ネットワークは非特許文献２の方法などにより実現できる。非特許文献２では、P2P通信ネットワークに参加している全ての端末装置２が保持しているデータを逐次全て調べなくても分散ハッシュテーブルという方式を用いて所望データがどの端末装置２に保持されているかを効率的に探すことができ、当該データを保有している端末装置２と直接通信することで、取得することができる。

さらに、トリアージ情報や個人情報をサーバ装置１、端末装置２間でやり取りする場合、プライバシやセキュリティを考慮し、それぞれのデータを扱うもの同士で、VPN(Virtual Private Network)を構成し、関係者以外から通信データを傍受されないようにする構成も採れる。VPNを構成する具体的な方法としてSDN(Software Defined Network)という既存技術を適用するのが好適である。

SDNは物理的には１つのネットワーク上に、複数の独立したネットワーク（仮想ネットワーク）が存在するように見せる技術であり、各仮想ネットワーク間は完全に独立しており、情報の授受は出来ないため、上記ＶＰＮを構成できる。仮想ネットワークのことをＳＤＮではスライスと呼ぶ。スライスの割り当ては、ＳＤＮコントローラとよぶ機能が実現する。

ここでは、そのＳＤＮコントローラに、本システムのサーバ装置１または端末装置２から、当該データ通信を行うためのスライス（仮想ネットワーク）を作るようにＳＤＮコントローラに命令を発するための通信経路をサーバ装置１が持ち、その通信経路を通して、サーバ装置１または端末装置２がサーバ装置１を介して、ＳＤＮコントローラにスライス作成命令を出せる構成とする。作成されたスライス（仮想ネットワーク）は不要になれば、サーバ装置１からスライス削除命令をＳＤＮコントローラに送ることにより削除できる。

図１２は、これまでに述べてきた各動作実現するためにサーバ装置１、及び各端末装置２に備えるべき機能を実装の面から整理した図である。

本発明は、通信管理、医療情報管理、物資情報管理、危険箇所と地図情管理という４つの管理機能が相互に連携して動作することにより、前述した各機能が実現される。かかる機能は、演算処理装置（ＣＰＵ）をプログラムに従って、それぞれの機能に対応する機能手段として演算動作させることにより実現される。

１ サーバ装置
１０ データベース
１１ 地図サーバ
１２ データベース同期機構
２ 端末装置
２２ｃ 移動端末
３ 無線通信
１００ 登録者リスト
１０１（１０１Ａ，１０１Ｂ）救助チーム
１０２ 傷病者リスト
１０４ 在庫物資
１０４Ａ，１０４Ｂ 携行物資
１０３Ａ，１０３Ｂ 救助経路

Claims (4)

1. 公衆通信網が利用できない環境に於いて使用される災害時情報管理システムであって、
   複数のサーバ装置と、
   前記複数のサーバ装置のそれぞれに対応し、対応するサーバ装置と無線通信によりデータ通信が可能の複数の端末装置で構成され、一つのサーバ装置に対応する前記複数の端末装置間は、マルチホップ通信が可能であり、
   前記複数のサーバ装置の各々は、
   対応する前記複数の端末装置の各々から入力される登録者のプロフィール、物資及び傷病者の情報を一元管理し、救助者の登録者リスト、トリアージ及び位置情報を含む傷病者の傷病者リスト及び、在庫物資リストを格納するデータベースと、
   地図情報を提供する地図サーバと、
   送信手段を有し、
   前記データベースに格納される前記在庫物資リストに基づいて、要求物資の有無を検索する検索手段として、
   前記登録者のプロフィールと前記傷病者の情報を照らし合わせて、適切な登録者と傷病者のマッチングにより前記データベースに格納される前記登録者リストからチームメンバとなる人を選択して傷病者を救助するための救助チームを編成し、前記編成された救助チームに対して前記傷病者リストから選択して担当傷病者を割り振る手段として、
   前記傷病者リストにおける位置情報をもとに救助者のいる位置を認識して前記地図サーバから取得する地図上に表示するとともに、前記救助チームが集合する集合地点及び、前記集合地点から径路をたどり救助経路を作成する手段として機能し、
   前記検索手段により検索される要求物資の有無及び前記作成される救助経路を二次情報として前記送信手段により前記複数の端末装置に送信し、更に、
   前記複数の端末装置は、前記複数のサーバ装置間で直接通信出来ない状況において、前記複数のサーバ装置間を行き交う際に、前記複数のサーバ装置のそれぞれに蓄積された情報を交換する交換手段を有する、
   ことを特徴とする災害時情報管理システム。
2. 請求項１において、
   前記複数の端末装置は、
   物資の要求および供給の情報を入力する入力手段と前記入力手段により入力される前記情報を前記サーバ装置に送信する送信手段を有し、
   前記サーバ装置は、前記検索手段の機能として、前記端末装置から収集した前記情報をもとに、前記データベースで一元管理される情報により物資の需要と供給の照合を行い、前記照合結果を、前記物資の要求または供給の情報に対応する前記二次情報として出力する、
   ことを特徴とする災害時情報管理システム。
3. 請求項１において、
   前記複数のサーバ装置を失った場合に、システムを構成する前記複数の端末装置同士で、Peer to Peer (P2P)通信ネットワークを構成し、前記複数のサーバ装置で本来管理すべき情報を持ち合う、
   ことを特徴とする災害時情報管理システム。
4. 請求項１において、
   前記複数のサーバ装置のそれぞれまたは前記複数のサーバ装置、及び前記複数の端末装置がVPN(Virtual Private Network、仮想プライベートネットワーク)を動的に構成し、
   前記VPNを用いて、前記複数の端末装置間または前記複数のサーバ装置のそれぞれとの
   間のデータ転送を行う、
   ことを特徴とする災害時情報管理システム。