Specification :(In Japanese)災害時情報管理システム、これに用いるサーバ装置及び端末装置

Country	(In Japanese)日本国特許庁(JP)
Gazette	(In Japanese)特許公報(B2)
Patent Number	P6811947
Publication number	P2017-079023A
Date of registration	Dec 18, 2020
Date of issue	Jan 13, 2021
Date of publication of application	Apr 27, 2017
Title of the invention, or title of the device	(In Japanese)災害時情報管理システム、これに用いるサーバ装置及び端末装置
IPC (International Patent Classification)	G06Q  50/26        (2012.01)
FI (File Index)	G06Q 50/26
Number of claims or invention	4
Total pages	18
Application Number	P2015-207660
Date of filing	Oct 22, 2015
Date of request for substantive examination	Oct 22, 2018
Patentee, or owner of utility model right	(In Japanese)【識別番号】506301140 【氏名又は名称】公立大学法人会津大学
Inventor, or creator of device	(In Japanese)【氏名】宮崎 敏明 【氏名】ペン リ 【氏名】ソン ゴオ
Representative	(In Japanese)【識別番号】100094525、【弁理士】、【氏名又は名称】土井 健二 【識別番号】100094514、【弁理士】、【氏名又は名称】林 恒徳
Examiner	(In Japanese)【審査官】梅岡 信幸
Document or reference	(In Japanese)特開2013－050894（JP，A） 特開2013－161316（JP，A） 特開2013－250913（JP，A） 特開2003－288443（JP，A） 特表2013－511222（JP，A） 特開2004－206247（JP，A） 特開平10－301911（JP，A） 特開2014－135060（JP，A） 小嶋 洋明，START法を用いたトリアージ作業支援のための情報提示システムの提案，情報処理学会論文誌 論文誌ジャーナル Vol．53 No．1 ［CD－ROM］，日本，一般社団法人情報処理学会，2012年 1月15日，第53巻，第450-459頁
Field of search	Ｇ０６Ｑ １０／００－９９／００
Scope of claims	(In Japanese)【請求項1】 公衆通信網が利用できない環境に於いて使用される災害時情報管理システムであって、 複数のサーバ装置と、 前記複数のサーバ装置のそれぞれに対応し、対応するサーバ装置と無線通信によりデータ通信が可能の複数の端末装置で構成され、一つのサーバ装置に対応する前記複数の端末装置間は、マルチホップ通信が可能であり、 前記複数のサーバ装置の各々は、 対応する前記複数の端末装置の各々から入力される登録者のプロフィール、物資及び傷病者の情報を一元管理し、救助者の登録者リスト、トリアージ及び位置情報を含む傷病者の傷病者リスト及び、在庫物資リストを格納するデータベースと、 地図情報を提供する地図サーバと、 送信手段を有し、 前記データベースに格納される前記在庫物資リストに基づいて、要求物資の有無を検索する検索手段として、 前記登録者のプロフィールと前記傷病者の情報を照らし合わせて、適切な登録者と傷病者のマッチングにより前記データベースに格納される前記登録者リストからチームメンバとなる人を選択して傷病者を救助するための救助チームを編成し、前記編成された救助チームに対して前記傷病者リストから選択して担当傷病者を割り振る手段として、 前記傷病者リストにおける位置情報をもとに救助者のいる位置を認識して前記地図サーバから取得する地図上に表示するとともに、前記救助チームが集合する集合地点及び、前記集合地点から径路をたどり救助経路を作成する手段として機能し、 前記検索手段により検索される要求物資の有無及び前記作成される救助経路を二次情報として前記送信手段により前記複数の端末装置に送信し、更に、 前記複数の端末装置は、前記複数のサーバ装置間で直接通信出来ない状況において、前記複数のサーバ装置間を行き交う際に、前記複数のサーバ装置のそれぞれに蓄積された情報を交換する交換手段を有する、 ことを特徴とする災害時情報管理システム。 【請求項2】 請求項1において、 前記複数の端末装置は、 物資の要求および供給の情報を入力する入力手段と前記入力手段により入力される前記情報を前記サーバ装置に送信する送信手段を有し、 前記サーバ装置は、前記検索手段の機能として、前記端末装置から収集した前記情報をもとに、前記データベースで一元管理される情報により物資の需要と供給の照合を行い、前記照合結果を、前記物資の要求または供給の情報に対応する前記二次情報として出力する、 ことを特徴とする災害時情報管理システム。 【請求項3】 請求項1において、 前記複数のサーバ装置を失った場合に、システムを構成する前記複数の端末装置同士で、Peer to Peer (P2P)通信ネットワークを構成し、前記複数のサーバ装置で本来管理すべき情報を持ち合う、 ことを特徴とする災害時情報管理システム。 【請求項4】 請求項1において、 前記複数のサーバ装置のそれぞれまたは前記複数のサーバ装置、及び前記複数の端末装置がVPN(Virtual Private Network、仮想プライベートネットワーク)を動的に構成し、 前記VPNを用いて、前記複数の端末装置間または前記複数のサーバ装置のそれぞれとの 間のデータ転送を行う、 ことを特徴とする災害時情報管理システム。
Detailed description of the invention	(In Japanese)【技術分野】 【0001】 本発明は、災害時情報管理システム、前記システムを構成するサーバ装置、及び前記サーバ装置と無線通信を行う端末装置に関する。特に、災害発生現場においてインターネットや携帯電話網などの商用情報通信網が使用できない環境下で、様々な情報を統一的に管理し、端末装置のユーザに提供する災害時情報管理システム、前記システムを構成するサーバ装置、及び前記サーバ装置と無線通信を行う端末装置に関する。 【背景技術】 【0002】 災害発生時において、被災者の救助や支援物資の補給などに必要な災害現場の情報の収集・共有は非常に重要である。従来、それらの情報の収集・共有は、紙に書いた後、避難所などに掲示するか、人づてに伝言するなどの方法を用いて行われていた。しかし、上記の様な方法では、多くの人に情報が伝搬するのに時間がかかる問題や、伝言による情報誤りが発生する等の問題があった。 【0003】 上記問題を解決するものとして、特許文献1では、支援物資及び人に識別情報を付与し、それらをデータベース（DB）で管理することで、支援物資を被災者に迅速に届ける仕組みと様々な生存支援サービスを支援するためのシステム構築法を開示している。しかし、当該システムは支援物資の分配法及びそれに伴う費用の精算等に主眼が置かれており、人命救助の初動期体制構築などの支援を目的としたものではない。また、複数の避難所等の間での情報共有は考慮されていない。 【先行技術文献】 【0004】 【特許文献1】特開2013－225259号公報 【0005】 【非特許文献1】“高度化するトリアージ,” JST News, Vol.6, No.9, December 2009.http://www.jst.go.jp/pr/jst-news/2009/2009-12/page08.html 【非特許文献2】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. 【発明の概要】 【発明が解決しようとする課題】 【0006】 上記従来技術におけるシステムでは、支援物資の分配法及びそれに伴う費用の精算等に主眼が置かれており、人命救助の初動期体制構築などの支援を目的としたものではない。また、複数の避難所等の間での情報共有は考慮されていない。 【0007】 従って、本発明の目的は、上記問題を解決するためのものであり、被災者間あるいは救助者間の情報共有を促進するだけでなく、インターネットや携帯電話等の情報通信網等が使用できない状況下において、孤立した複数のサーバ間の情報共有を、利用者の端末装置を媒介して行うことを可能とする災害時情報管理システムを提供することにある。 【課題を解決するための手段】 【0008】 上記課題を解決する本発明に従う災害情報管理システムは、一側面において、公衆通信網が一切使用できない環境に於いて使用される災害時情報管理システムであって、一つのサーバ装置と、前記サーバ装置と無線通信によりデータ通信が可能である複数の端末装置から構成され、前記サーバ装置は、演算処理装置として、前記複数の端末装置の各々から入力される所有者の個人情報及び災害時関連情報を一元管理する管理手段として機能し、 前記管理手段で一元管理される情報に基づいて、前記災害時関連情報に含まれる要求物資の有無を検索する検索手段として機能し、傷病者を救助するための救助チームの編成と担当傷病者の割り振り、救助のための危険箇所を避けた最適経路を探索する探索手段として機能し、更に、前記検索手段により検索される要求物資の有無及び前記探索手段により探索される最適経路を二次情報として前記各端末装置に送る送信手段として機能することを特徴とする。 【0009】 上記課題を解決する本発明に従う災害情報管理システムは、前記一側面において、第一の態様として、前記災害時関連情報として、少なくとも物資の要求・供給、危険箇所、傷病者のトリアージ情報を含むことを特徴とする。 【0010】 上記課題を解決する本発明に従う災害情報管理システムは、前記一側面において、第二の態様として、前記複数の端末装置は、物資の要求および供給情報を入力する入力手段を有し、前記サーバ装置の前記検索手段は、前記端末装置から収集した情報をもとに、物資の需要と供給の照合を行い、その照合結果を、前記物資の要求または供給する旨の情報に対応する前記二次情報として出力することを特徴とする。 【0011】 上記課題を解決する本発明に従う災害情報管理システムは、前記一側面において、第三の態様として、前記探索手段は、危険箇所や避難所、入力された物資の存在位置情報を地図上に表示し、被災者または救助者が、当該危険箇所を避け、最短で目的地まで到達できる経路情報を当該地図上に表示し、前記地図上に表示される物資の存在位置情報と経路情報を前記二次情報として出力することを特徴とする。 【0012】 上記課題を解決する本発明に従う災害情報管理システムは、前記一側面において、第四の態様として、前記サーバ装置を失った場合に、システムを構成する前記複数の端末装置同士で、Peer to Peer (P2P)通信ネットワークを構成し、前記サーバ装置で本来管理すべき情報を持ち合うことを特徴とする。 【0013】 上記課題を解決する本発明に従う災害情報管理システムは、第二の側面として、前記一側面の災害時情報管理システムを複数システム有し、前記複数の災害時情報管理システムのそれぞれにおける複数のサーバ装置間で直接通信出来ない状況において、前記サーバ装置に蓄積された情報を、前記サーバ装置間を行き交う携帯端末を媒介として、交換する手段を有することを特徴する。 【0014】 上記課題を解決する本発明に従う災害情報管理システムは、前記第一又は第二の側面において、前記一つのサーバ装置または前記複数のサーバ装置、及び前記複数の端末装置がVPN(Virtual Private Network、仮想プライベートネットワーク)を動的に構成し、前記VPNを用いて、前記複数の端末装置間または前記サーバ装置との間のデータ転送を行うことを特徴とする。 【0015】 上記課題を解決する本発明に従う災害情報管理システムに使用される前記第一又は第二の側面における前記一つのサーバ装置または前記複数のサーバ装置は、前記管理手段として情報を管理するデータベースと、前記検索手段による要求物資の有無の検索及び／又は、前記探索手段による最適経路の探索の際に使用する地図情報を処理する地図サーバと、前記地図情報を用いて前記二次情報を作成するためのユーザインタフェースとを有することを特徴とする。 【0016】 上記課題を解決する本発明に従う災害情報管理システムにおける前記第一の態様に使用される端末装置は、演算処理手段を有し、前記演算処理手段により処理される情報を画面表示する表示手段と、前記表示手段に順次表示される前記画面表示に従って必要事項を入力することにより傷病者のトリアージを実施することを特徴とする。 【発明の効果】 【0017】 本発明の構成を使用すれば、従来、掲示板と電話等を用いて行っていた災害現場での救助活動や物資の配給が、一元管理され、混乱を避けながら迅速に実施できるようになる。 【図面の簡単な説明】 【0018】 【図1】本発明に従う災害時情報管理システムの実施形態の一構成例を示す概念図である。 【図2】サーバ装置内のデータベースに蓄積された情報を用いて、救助チームを編成する過程を図示したものである。 【図3A】トリアージの手順フローを示す図である。 【図3B】傷病者の情報入力のための医師等が行うトリアージの入力画面を示す図である。 【図4】端末装置の情報出力機能の一例である。 【図5】端末装置の画面構成例である。 【図6】図5の「需要」ボタンを押下したときに現れる画面例である。 【図7】物資要求が端末装置から検索条件入力という形であった場合の、端末装置とサーバ装置間の処理フローを示す図である。 【図8】自分の保有する物資を提供する場合のメニュ画面例である。 【図9】物資供給が端末装置から成された場合の処理フローを示している。 【図10】サーバ装置間が直接通信できない場合に、端末装置を媒介してサーバ装置内に蓄積された情報を互いに共有する例を説明する図である。 【図11】サーバ装置が故障または電波の届かない位置にある場合の対応を示す図である。 【図12】サーバ装置、及び各端末装置に備えるべき機能を実装の面から整理した図である。 【発明を実施するための形態】 【0019】 以下に図面を参照して本発明に従う実施の形態を説明する。なお、かかる実施の形態は、本発明の理解のためのものであって、本発明の適用はこれに限定されない。本発明の技術的範囲は、特許請求の範囲の記載及びこれに類似の範囲も含まれる。 【0020】 図1は、本発明に従う災害時情報管理システムの実施形態の一構成例を示す概念図である。サーバ装置1と通信機能を有する複数の携帯可能な端末装置2（21～2n）を有する。 【0021】 なお、本実施の形態例で用いる携帯可能な端末装置2は、本発明を実行する専用端末として用意し、避難所等で、被災者や救助者に直接配布する形で準備する装置であってもよいし、日常人々が使用している携帯端末、スマートフォンやタブレット端末に、本発明を実行するソフトウエアをインストールする形で実現してもよい。したがって、本発明の説明において、携帯可能な端末装置は、以降単に端末装置と称する。 【0022】 それぞれの端末装置2とサーバ装置1は無線通信3により情報の授受が可能である。また、当該無線通信3は、マルチホップ通信をサポートする。例えば、図1中、端末装置23は、直接サーバ装置1と通信できない位置にあっても、端末装置22及び端末装置21を介して、サーバ装置1と通信することができる。 【0023】 かかる実施の形態構成において、本発明の実現のためにサーバ装置1は、演算処理装置であって、前記複数の端末装置の各々から入力される所有者の個人情報及び災害時関連情報を一元管理する管理手段として機能し、前記管理手段で一元管理される情報に基づいて、前記災害時関連情報に含まれる要求物資の有無を検索する検索手段として機能し、傷病者を救助するための救助チームの編成と担当傷病者の割り振り、救助のための危険箇所を避けた最適経路を探索する探索手段として機能し、更に、前記検索手段により検索される要求物資の有無及び前記探索手段により探索される最適経路を二次情報として前記各端末装置に送る送信手段として機能する。 【0024】 具体的には、サーバ装置1は、データベース10、地図サーバ11、データベース同期機構12、及びグラフィカルユーザインタフェース（GUI）13を備えて構成される。 【0025】 地図サーバ11は、端末装置2あるいはサーバ装置1内の図示しない管理プログラムからの求めに応じて地図情報を提供するものである。 【0026】 データベース10は、後述する様々な情報を格納するものであり、GUI13を通して、格納した情報を整理統合する機能も有する。 【0027】 データベース同期機構12は、複数のサーバ装置がある場合に、各サーバ装置1内のデータベース10に格納してある情報をサーバ装置間で同じになるように調整する（これを、同期と呼ぶ）ためのものである。GUI13は、データベース10に蓄積されたデータを操作する機能を有する。 【0028】 サーバ装置1は、本発明の適用においては基本的に避難所等に設置され、頻繁に移動することはない。一方、端末装置2は移動することを前提とする。複数の端末装置21～2n間または端末装置2とサーバ装置1間の無線通信3はIEEE802.11bなどの標準的な無線LANを用いてネットワーク構築可能であり、ルーティングプロトコルとして標準化されているAODV（Ad hoc On-Demand Distance Vector）プロトコルなどの動的ルーティング方式を採用すれば，上述したマルチホップ通信が実現できる。 【0029】 ここで、本発明を実行するソフトウエアをインストールする形で端末装置を実現する場合は、サーバ装置1に当該ソフトウエアを置き、無線通信3を用いて、端末装置2にダウンロードする仕組みを提供するようにしてもよい。また、インターネットなど公衆通信網が使える状況において、商用ソフトウエア配布サービスや、独自に設置したダウンロード専用機構に当該ソフトウエアを置き、公衆通信網を経由して、端末装置2側からダウンロードさせるようにしてもよい。 【0030】 なお、前記サーバ装置1からの信号を待たずに、ユーザ自らが直接当該アプリケーションソフトウエアを操作し、本発明の端末装置側の機能が発現する形にしてもよい。 【0031】 図2は、サーバ装置1内のデータベース10に蓄積された情報を用いて、救助チームを編成する過程を図示したものである。まず、登録者リスト100から、チームメンバとなる人を選択し、救助チーム101を編成する。図2では、救助チーム101として、第1の救助チーム101Aのメンバとして登録者1，3，4，7が、第2の救助チーム101Bのメンバとして登録者2，5，6が選択されている。次に、各々編成された救助チーム101A，101Bに対して、担当する傷病者を傷病者リスト102から選択し、担当リスト102として作成する。 【0032】 図2では、救助チーム101Aが担当する傷病者は担当リスト102Aの傷病者1傷病者3,及び傷病者5となる。同様に、救助チーム101Bが担当する傷病者は担当リスト102Bの傷病者2及び傷病者4となる。さらに、当該救助者のいる位置は、傷病者リスト102の位置情報をもとに認識され、図1の地図サーバ11から取得する地図上に、当該場所が表示されると共に、各救助チームメンバが集合する集合地点及び、その集合地点から経路をたどり、担当傷病者を救うための救助経路103A，103Bが救助チーム101A，101B毎に作成される。 【0033】 上記の準備が整った後、各救助チーム情報が、当該メンバの端末装置2に、無線通信を用いて送られる。図2では、救助チーム101Aのチーム情報は、そのメンバである登録者1，3，4，7へ送られる。同様に、救助チーム101Bのチーム情報は、そのメンバである登録者2，5，6へ送られる。 【0034】 上述した一連のデータベース操作は、GUI13を用いて行うことでもよいし、登録者のプロフィール、例えば、登録者が医師である場合、脳外科、整形外科など専門分野の情報と、傷病者の詳細情報から得た情報、例えば、頭部外傷、骨折などの症状と照らし合わせ、より適切な登録者と傷病者のマッチングを図り、データベース10により自動でチーム情報を作成する方法で行ってもよい。また、携行物資情報104A，104Bも、在庫物資リスト104に基づき、傷病者の症状に合わせて、自動で作成するようにしてもよい。 【0035】 さらに、チームメンバの追加削除、担当リストの変更、携行物資の追加なども、任意の時刻でできるものとし、変更された情報は、サーバ装置1側から強制的あるいは定期的に、チームメンバの端末装置2に送信される。また、かかる変更された情報は、端末装置2からのデータ交換要求に応じて、送られる様にしてもよい。 【0036】 一方、端末装置2側に具備する機能は、大きくは、2つにわかれ、一つは情報入力機能、他方は情報出力機能である。 【0037】 情報入力機能は、図2の登録者、物資、傷病者（トリアージ）に関する情報入力を可能とするGUIが用意されている。登録者のプロフィール、すなわち、氏名、性別、年齢、属性（医師、消防、看護師、救急、ボランティア、被災者、その他）、専門知識、性別などの個人情報は、入力画面を通して、最初に各端末装置2の使用者が入力する。 【0038】 物資情報に関しても、入力画面を用意し、物資名、数量、提供/要求の別、提供/要求の場所、その他補足事項などを入力できるものとする。また、非常時に必要となる毛布、食料などの物資は、予めメニュとして用意し、当該物資を選択する形にする入力画面を用意することにより、端末装置2における入力の簡便さを図ることとしてもよい。 【0039】 傷病者の情報入力は、医師等が行うトリアージの入力画面を提供することにより行う。図3A，図3Bはその一例である。図3Aに示したフローチャートは、START式と一般に呼ばれるトリアージ法の手順を示したものである。傷病者を、その様態により4段階（赤、黄、緑、黒）に色分けし、当該色のタグを傷病者の左腕等に付け、救助の優先度を付ける作業である。 【0040】 本発明では、従来、トリアージタグにペンで情報を書き込み、直接対象傷病者に付ける作業であった所を、端末装置2で必要情報を入力し、最終的にサーバ装置1のデータベースで全ての傷病者を一元管理しようとするものである。 【0041】 図3Bに、上記フローチャートの各判断箇所に相当する端末装置2の入力画面([1]～[7])に従って情報入力を行うと、4種類のどの色（救助の優先度）かが決定される。 図3Bにおける[番号]は、図3Aの手順に対応している。 【0042】 本実施の形態例では、傷病者の識別を行うために、トリアージタグに一意のバーコードを付与しておき、そのバーコードを端末装置2のバーコードリーダ機能を用いて読み込む。これにより、実際に傷病者に付けたトリアージタグと、入力情報をヒモ付け、データベース10に登録された情報がどの傷病者の情報か判別できるようにしている。 【0043】 図3Bの画面[8]～[11]の下側にある「IDスキャン」ボタン20を押下すると、端末装置のバーコードリーダ機能が起動する。さらに、端末装置2のGPS受信機能を用いて、傷病者の地理的位置も同時にデータベース10上に登録する。なお、バーコードではなく、トリアージタグに付された一意性を保証するID番号を手入力することもできる。ここで、IDを手入力する場合、トリアージタグに、その近傍で重ならない程度の比較的短い数字をIDとして印字しておき、それを手入力した後、端末装置2のID及び、その位置情報や日時を加味して、一意性を確保したIDを端末装置2またはサーバ装置1内で生成し、それを用いることでもよい。 【0044】 加えて、上述したトリアージ方法よらず、他の方法により、トリアージ情報を取得してもよい。例えば、非特許文献1では、センサと無線通信機能を備えた電子トリアージタグが提案されている。それを活用し、図1のサーバ装置に直接トリアージ情報をあげる方法でもよい。 【0045】 また、トリアージに於いて、傷病者の傷病箇所を簡便に入力出来るように、人体の絵を端末装置画面に表示し、当該画面にタッチするなどして当該傷病箇所を指示させ、指示と同時に、典型的な傷病名を列挙表示し、その中から該当傷病名を選択することで傷病者の状況を入力する様にしてもよい。例えば、画面の表示された人体の腕の部分をタッチすると、骨折、打撲、裂傷、といった傷病名が現れ、その中から当該項を選ぶ事で入力が完了するようにする。加えて、それら入力された傷病箇所の情報に基づいて、上述したトリアージが自動で行われるようにしてもよい。 【0046】 図4は、端末装置2の情報出力機能の一例である。地図上に、避難所30（31）及び端末装置2の現在位置32が表示される他、災害等で、現在通行できない地点も“×”で表示されている。また、ユーザが要求した物資（図4では、水33と食料34）が、どこにあるかも示している。 【0047】 さらに、水33を求め、避難所31に行く場合、安全かつ最短の誘導経路35も表示されている。通行不可の場所は、各端末装置2の保有者が、当該箇所の情報を入力し、サーバ装置1のデータベース10に登録されたものである。上記誘導経路35の探索は、図1のサーバ装置内の地図サーバ11が行い、その結果を端末装置2に送ることで実現する。本地図表示は、先に述べた救助チームが傷病者の救助に向かうときの経路表示としても活用する。 【0048】 各端末装置2に於いては、誘導経路35に従って、端末装置2の保有者を目的地まで、音声または画面表示を用いて、実際に経路誘導（ナビゲーション）する機能が使用できるようにし、不慣れな土地でも、迷わず目的地に到達するようにしてもよい。 【0049】 図5は端末装置2の画面構成例である。画面上の（ア）～（サ）はそれぞれ、ボタンであり、対応するボタンを押下することで、それに対応した操作ができる。ボタン（ア）の押下により図2で構成した救助チーム情報が表示される。ボタン（イ）は、設定メニュを表示するものであり、自分のプロフィールや端末表示形式等に関する情報を入力するときに用いる。ボタン（ウ）は、物資の要求（需要）を出すときに用いる。ボタン（エ）は、その逆に、自分の持っている物資を供給できる時に、当該情報を入力するときに用いる。ボタン（オ）は、様々な状況を把握・表示するときに用いる。表示される内容は、図4の地図情報や、救助チームに参加している場合は、チームに関する連絡事項などの表示にも用いる。ボタン（カ）は、通行不可の場所や危険情報などを入力する際に用いる。 【0050】 ボタン（キ）は、データ交換のためのボタンであり、当該ボタンが押されると端末装置2に保有しているデータをサーバ装置1に向けて送信するとともに、サーバ装置1からの新たな情報を受信する。このボタン（キ）を押さなくても、端末装置2は一定時間ごとにサーバ装置1とデータ交換のための通信を行うが、即座にデータ交換を行いたいときに用いる。 【0051】 ボタン（ク）は端末装置2の位置情報をサーバ装置1に送信する際に用いる。端末装置2の位置情報は、設定により、自動的かつ定期的にサーバ装置1に送るようにすることも別途設定によりできる。MENUボタン（ケ）が、押下されると、画面(e)が表示される。これは、端末装置2における本発明のシステムを用いる時の初期画面である。TRIAGEボタン(コ)はトリアージを行うときに用いるボタンであり、押下されると、図5(c)の画面に移行する。 【0052】 なお、実際のトリアージの際は、図5(c)の画面中央の”TRIAGE”と書かれた大きなボタンを押下すると、図3Aに示したフローチャートに従った画面が表示される。REPORTSボタン（サ）を押下すると、当該端末装置2で行ったトリアージの結果を表示する図5（d）のリポート画面が現れる。 【0053】 ここで、端末装置2で利用できるメニュは、医師、消防、ボランティア、被災者などのユーザの属性によって、制限することにより、不要な操作や混乱を避けるようにする。図5(a)は、救助チームに参加している医師の端末装置画面であり、ボタン（イ）（ウ）（エ）すなわち、「設定」及び物資の「需要」「供給」ボタンは押下できないようになる。これは、救助活動中は物資関連の入力は行う事はなく、また、任務に当たっているときは、個人のプロフィールなどの変更はできないようにするためである。 【0054】 一方、図5(b)の画面は、被災者の端末装置の画面であり、救助チームの「チーム情報」ボタン（ア）及び右下のトリアージボタン（コ）及びそのリポートボタン（サ）は不要であり、使用できない状態になっている。このように、端末装置保有者の属性（立場）によって、使用できるメニュ・ボタンに、自動的に制限をかけることにより、誤操作を防ぐ。 【0055】 端末装置2の保有者の属性は、例えば被災者の立場からボランティアの立場など、自ら状況に合わせ変更が可能であり、それに応じて使用できるメニュが変化する。また、救助チームの一員として救助活動に従事しているときは、サーバ装置1からの指令で、属性を個人で変更できないように制御できる。 【0056】 図6は、図5の「需要」ボタン（ウ）を押下したときに現れる画面例である。本画面を通して、必要な物資やその数量、必要な日時、受け取り方法、物資に対して対価を払えるか否か（有料・無料）の情報60を入力し、「検索する」ボタン61を押すと、ヒットした物資があればその一覧62が、ヒットしなければその旨63が表示される。 【0057】 また、物資の名前をキーワードとして手入力する代わりに、メニュ64から選択するようにしてもよい。場所の指定に関しても、地図を表示し、地図上の地点や範囲を指定することで、エリアを指定することでもよい。 【0058】 図7は、図5の「需要」ボタン（ウ）が押下された時、すなわち物資要求が端末装置2から検索条件入力という形であった場合の、端末装置2とサーバ装置1間の処理フローを示している。 【0059】 端末装置2から検索条件が入力されると（ステップS1）、入力情報はサーバ装置1に送信される（ステップS2）。サーバ装置1において、データベース10に登録された検索条件と一致する物資の情報があるかを判断し（ステップS3）、一致するものがあれば（ステップS3，あり）、検索結果を並べ換え（ステップS4）、「需要要求」を送信した端末装置2に送信する。 【0060】 端末装置2では、検索結果を選択し（ステップS5）、選択結果をサーバ装置1に送信する（ステップS6）。これにより、需要処理が成功（ステップS7）となる。 【0061】 一方、ステップS3で、検索条件に一致するものがない（ステップS3，なし）場合には、その旨が端末装置2に通知される。従って、先に送った需要要求項目をサーバ装置1に登録するか否かを該当の端末装置2において判断する。 【0062】 一致する供給物資を待つ場合には、そのままサーバ装置1に登録する場合は（ステップS8，はい）、一致した物資の供給を一定期間待つ（ステップS9）。一致した物資の供給可能がサーバ装置1で検索されると、サーバ装置1からその旨が該当の端末装置2に通知される（ステップS10）。以降の処理は、先の説明したステップS4－S7の処理に繋がる。 【0063】 ステップS8で、サーバ装置1に登録しない（ステップS8，いいえ）場合及び、一致した供給待ち（ステップS9）で所定期間を過ぎると時間切れとなり、先の需要要求は失敗したことになる。 【0064】 図8は、自分の保有する物資を提供する場合のメニュ画面例であり、図5の「供給」ボタン（エ）が押されたときに端末装置2に出現する画面である。供給できる物資の情報70を入力した後、「供給する」の登録ボタン71を押下すると当該物資情報が供給可能物資として、サーバ装置1のデータバース10に登録される。 【0065】 ここで、登録した物資への要求が、既に誰かからある場合は、即座に合致する要求がある旨の表示72が画面に現れ、「詳細」ボタン73を押すと、他者が、図6の「需要」画面で入力した物資要求情報の詳細74が表示される。合致する要求がない場合は、サーバ装置内のデータベース10に当該供給物資情報が登録され、端末装置2には、その旨の画面表示75がされる。 【0066】 図9は、図8の「供給」ボタン（エ）が押下された時、すなわち物資供給が端末装置2から成された場合の処理フローを示している。 【0067】 端末装置2から供給情報の入力が行われると（ステップS20）、その情報は、サーバ装置1に送られる（ステップS21）。サーバ装置1は、受信した供給情報をデータベース10に登録する（ステップS22）。 【0068】 先に図7の（ステップS9）で説明した供給待ちがあり、時間内であれば（ステップS23）、サーバ装置1から該当の端末装置2に通知される（ステップS24）。これを前記する端末装置2のユーザが確認する（ステップS25、図7のステップS4－S7参照））。 【0069】 ステップS23で需要待ちが時間切れ（図7、ステップS9参照）であれば、供給失敗（ステップS27）となる。但し、供給データは、データベース10に登録されているので、後の需要に対して物資を直ちに供給することが可能である。 【0070】 上記したように物資の需要・供給の要求管理は、サーバ装置1とそれが保有するデータベース10で行われる。なお、図7で示した物資の検索フロー、及び図9で示した物資の登録に際しての、要求（需要）の確認処理は、図6及び図8の画面で入力された情報に従って、サーバ装置1内で、一定時間毎に実行され、物資の需要・供給の照合が図られる。 【0071】 実際に照合した場合は、需要者端末装置及び供給者端末装置双方に、照合した旨の表示がなされる。なお、当該表示形式は、図6の「検索結果あり」の場合の画面62、及び図7の「合致要求あり」の場合の画面72に準じる。 【0072】 ここで、上記した実施の形態例は、サーバ装置1が一台の場合であったが、複数のサーバ装置を広域に展開する形で本発明システムを拡張使用することもできる。その場合、サーバ装置間が直接通信できない場合に、端末装置2を媒介してサーバ装置1内に蓄積された情報を互いに共有することができる。 【0073】 図10はかかる直接通信できないサーバ装置1間での情報共有の例を示している。今、3台のサーバ装置11,12,13がある場合を考える。端末装置2aは、サーバ装置11内に蓄積されたデータxをダウンロードし、移動経路aを通って、サーバ装置12に到着した時、預かったデータxをサーバ装置12にアップロードする。これにより、サーバ装置11のデータはサーバ装置12に移行できる。 【0074】 また、上記の動作と並行して、端末装置2bは、サーバ装置12に蓄積されたデータyをダウンロードし、移動経路bを通って、サーバ装置13に向かおうとしている状態を考える。そのとき、端末装置2bは、端末装置2aとすれ違いざまに通信ができる機構を備え、端末装置2aは、データxのコピーを端末装置2bに渡す。 【0075】 その状態で、端末装置2bがサーバ装置13に到達した場合、端末装置2bはデータyとデータxをもっているので、サーバ装置13は、サーバ装置11とサーバ装置12のデータを同時に受信できる。 【0076】 上述したデータ移行は、全ての端末装置2で行われ、多くの端末装置2がサーバ装置1間を行き交うことで、サーバ装置1間のデータ同期が可能となる。 【0077】 また、各端末装置2は、必ずしも決められた移動経路を通る必要はなく、上記の端末同士のすれ違いざまのデータ交換を繰り返すことで、効率的なサーバ装置1間のデータ同期を実現できる。 【0078】 かかる場合、端末装置の一形態として、定期的にサーバ装置1間を行き交う自律移動可能の移動端末22cを考えることもできる。移動端末22cは、サーバ装置1間（避難所に設置されている場合は、避難所間と等価）を定期的に行き交うボランティアや医療関係者が携行する無線端末や、計画運行をする車載無線端末やドローン（無人飛行機）などを利用して実現できる。その場合、移動経路cは、決められた経路となる。これにより、計画的にサーバ装置1間のデータ移行が可能となる。 【0079】 加えて、移動端末22cが、どのサーバ装置とも直接通信できない端末装置2dのデータを預かり、サーバ装置13に届けることもできる。このように、端末装置（あるいは移動端末）の導入により、直接通信が不可能なサーバ装置間のデータ同期を行うことができる。 【0080】 ここで、端末装置2のすれ違いざま通信は、具体的にはWiFiでもよいし、Bluetooth（登録商標）などの近傍無線通信機能を使用してもよい。 【0081】 上述した移動端末22cを含む端末装置2を媒介してデータを転送する技術は、DTN(Delay Tolerant Network)として良く知られており、最も一般的な方法は、各端末装置は他の端末装置とすれ違う度に、自分の保有する全てのデータを相互に交換するというものである。 【0082】 これは、すれ違った端末装置同士が、互いに相手の端末装置がどこに行くか知らない場合、確実に目的のサーバ装置にデータを届けるために有効な方法である。しかし、すれ違う度に、各端末が全てのデータを交換すると、多くの同一データの複製が各端末の存在することになり、各端末装置2に大容量記憶メモリを持つ必要が生じるばかりでなく、そのデータを交換するために、無線通信の衝突（ふくそう）が生じる可能性が高くなるという不具合が発生する。 【0083】 それを防ぐ第一の方法は、各端末装置2のユーザが、サーバ装置1間を移動する場合は、自分の端末装置2に、事前に、移動先サーバ装置名(ID)を入力することである。各端末装置2（移動端末22cを含む）は、すれ違いざまに、相互通信により、相手端末装置2がこれから向かうサーバ装置1が分かるので、その情報をもとに、相手に託すデータを選択的に送ることができる。 【0084】 例えば、すれ違った相手端末装置2がサーバ装置1cに行く端末であれば、サーバ装置1cへ送りたいデータを託すというものである。移動端末22cに関しては、計画的にサーバ装置1間を移動するため、基本的に第一の方法が適用できる。また、第二の方法として、各端末装置2に移動履歴を保持しておき、相手端末装置2が頻繁に訪れるサーバ装置1があれば、当該サーバ装置1に送りたいデータを託すという方法もある。例えば、頻繁にサーバ装置1cに行く端末とすれ違った場合は、サーバ装置1cへ送りたいデータを託すというものである。 【0085】 さらに、第三の方法として、すれ違った端末装置2の移動方向が、地理的に目的のサーバ装置1のある方向であれば、その端末装置2に当該サーバ装置1に向けたデータを託す方法もある。 【0086】 なお、サーバ装置1間で移行するデータ量が多い場合は、一度に全てのデータを端末装置2（あるいは移動端末22c）にダウンロードすることはできないため、適宜分割して送ることになる。 【0087】 そのための制御を行うのが、図1のサーバ装置1内に設けたデータベース同期機構12である。データベース同期機構12は、自分の保有するデータの内、どのデータを既に送信したか（端末に託したか）を管理する。他のサーバ装置1から受け取ったデータも同様に管理し、同じデータを複数受信することを避ける。 【0088】 送出したデータが、他のサーバ装置1で受けとられたか否かを確認したい場合は、当該データを受け取ったサーバ装置1が、当該データの受け取り通知(ACK)パケットを、端末装置2に託すことで実現する。ACKパケットは、送信元サーバ装置ID及びデータIDに加え、当該データを受け取ったサーバ装置1のID情報を含んでいる。当該ACKパケットが送信元のサーバ装置1に到達すれば、当該サーバ装置1は、どのサーバ装置が、自分が保有するどのデータを受け取ったかを認識でき、それ以降、当該データを繰り返し送出することを避けることができる。 【0089】 ここで、上記構成において、各サーバ装置1から端末装置2に託されるデータの行き先サーバ装置IDは、データ自身に添付するものとする。よって、端末装置2同士のすれ違いざま通信に於いて交換される各データの最終宛先サーバ装置IDは、当該宛先サーバ装置1に届くまで、各データ内に保持される。 【0090】 また、複数のサーバ装置1を配置する場合、互いに直接通信できない状態であっても、自分がデータ同期をとるべきサーバ装置IDは、事前に別途、各サーバ装置1に設定されるものとする。勿論、別途設定することなく、端末装置2に託すデータの宛先サーバ装置IDを任意ID、すなわち、ブロードキャストとすることを許し、当該データが届いたサーバ装置1からのACKパケットを受信し、そのACKパケットに保持されている受信したサーバ装置IDを参照することにより、自分の周囲に当該サーバ装置1が存在することを認識し、そのサーバ装置IDを、自分がデータ同期をとるべきサーバ装置IDの別途設定に代えて使用する方法を採用してもよい。 【0091】 図11はサーバ装置1が故障または電波の届かない位置にある場合の対応を示す図である。図11において、各端末装置21，23，24，27がP2P(Peer to Peer)通信ネットワークを用いて、データを持ち合いサーバ装置1がなくても、情報共有ができる仕組みを構成することもできる。 【0092】 例えば、図11に於いて、救助チーム101Aを構成する登録者1, 登録者3, 登録者4, 登録者7の端末装置2をそれぞれ端末装置21, 端末装置23, 端末装置24, 端末装置27とする。図11のように、救助チームAのチーム情報は、端末装置21, 端末装置23、 端末装置24に既に配布済みで、端末装置27のみ当該情報を受信していない状態であり、さらにサーバ装置1と通信できないとする。その場合、登録者1，登録者3, 登録者4, 登録者7の端末同士で構成されるP2P通信ネットワークを用いて、登録者1, 登録者3, 登録者4が持つ救助チーム101Aのチーム情報の全部あるいは一部を端末装置27に送る。これにより、端末装置27は、サーバ装置1から受けるべきチーム情報を得ることができる。 【0093】 なお、具体的なP2P通信ネットワークは非特許文献2の方法などにより実現できる。非特許文献2では、P2P通信ネットワークに参加している全ての端末装置2が保持しているデータを逐次全て調べなくても分散ハッシュテーブルという方式を用いて所望データがどの端末装置2に保持されているかを効率的に探すことができ、当該データを保有している端末装置2と直接通信することで、取得することができる。 【0094】 さらに、トリアージ情報や個人情報をサーバ装置1、端末装置2間でやり取りする場合、プライバシやセキュリティを考慮し、それぞれのデータを扱うもの同士で、VPN(Virtual Private Network)を構成し、関係者以外から通信データを傍受されないようにする構成も採れる。VPNを構成する具体的な方法としてSDN(Software Defined Network)という既存技術を適用するのが好適である。 【0095】 SDNは物理的には1つのネットワーク上に、複数の独立したネットワーク（仮想ネットワーク）が存在するように見せる技術であり、各仮想ネットワーク間は完全に独立しており、情報の授受は出来ないため、上記VPNを構成できる。仮想ネットワークのことをSDNではスライスと呼ぶ。スライスの割り当ては、SDNコントローラとよぶ機能が実現する。 【0096】 ここでは、そのSDNコントローラに、本システムのサーバ装置1または端末装置2から、当該データ通信を行うためのスライス（仮想ネットワーク）を作るようにSDNコントローラに命令を発するための通信経路をサーバ装置1が持ち、その通信経路を通して、サーバ装置1または端末装置2がサーバ装置1を介して、SDNコントローラにスライス作成命令を出せる構成とする。作成されたスライス（仮想ネットワーク）は不要になれば、サーバ装置1からスライス削除命令をSDNコントローラに送ることにより削除できる。 【0097】 図12は、これまでに述べてきた各動作実現するためにサーバ装置1、及び各端末装置2に備えるべき機能を実装の面から整理した図である。 【0098】 本発明は、通信管理、医療情報管理、物資情報管理、危険箇所と地図情管理という4つの管理機能が相互に連携して動作することにより、前述した各機能が実現される。かかる機能は、演算処理装置（CPU）をプログラムに従って、それぞれの機能に対応する機能手段として演算動作させることにより実現される。 【符号の説明】 【0099】 1 サーバ装置 10 データベース 11 地図サーバ 12 データベース同期機構 2 端末装置 22c 移動端末 3 無線通信 100 登録者リスト 101（101A，101B）救助チーム 102 傷病者リスト 104 在庫物資 104A，104B 携行物資 103A，103B 救助経路
Drawing	(In Japanese)【図1】 (In Japanese)【図2】 (In Japanese)【図3A】 (In Japanese)【図3B】 (In Japanese)【図4】 (In Japanese)【図5】 (In Japanese)【図6】 (In Japanese)【図7】 (In Japanese)【図8】 (In Japanese)【図9】 (In Japanese)【図10】 (In Japanese)【図11】 (In Japanese)【図12】