(57)【要約】【課題】被災現場など、輻輳した通信環境であっても重要度の高い現象だけは迅速に送信することのできる災害時通信支援装置、災害時通信支援方法及び災害時通信支援プログラムを提供する。【解決手段】災害時通信支援システム１００は、制御部１１１が、撮影された画像情報から災害状況を把握可能な重要度の高い画像特徴点を災害が発生している状況で抽出する画像特徴点抽出部１１１ａと、通信規制のない通常時モードと通信規制のある災害時モードとの切替を受付けるモード切替受付部１１１ｂと、を備える。制御部１１１は、通常時モードでは画像情報及び関連情報を送信し、災害時モードでは画像特徴点及び事象情報を送信する制御をする。制御部１１１は、災害時モードにおいて、関連付けて記憶された画像特徴点及び事象情報を読み出し、時間軸上で所定時間幅をかけて所定データ量で送信する制御をする。【選択図】図１２
2014192633.tif 000002
【特許請求の範囲】
【請求項１】
被写体を撮影する撮影部と、
撮影された画像情報から災害状況を把握可能な重要度の高い画像特徴点を災害が発生している状況で抽出する画像特徴点抽出部と、
画像保存領域にディレクトリを作成し、当該ディレクトリに前記画像情報を保存するとともに、当該ディレクトリ名を識別値として前記画像情報と抽出された画像特徴点を解釈した事象情報とを紐付けし、当該紐付けにより関連付けられた前記画像情報及び前記事象情報を記憶する記憶部と、
前記画像情報又は前記事象情報を識別ＩＤを付けてサーバ側に送信する通信部と、
通信規制のない通常時モードと通信規制のある災害時モードとの切替を受付けるモード切替受付部と、
前記通常時モードでは前記画像情報及び前記識別ＩＤを送信し、前記災害時モードでは前記事象情報及び前記識別ＩＤを送信する制御をする制御部と、
を備えることを特徴とする災害時通信支援装置。
【請求項２】
前記制御部は、前記災害時モードにおいて、前記関連付けて記憶された画像情報及び事象情報を前記紐付けを元に読み出し、前記読み出した画像情報及び事象情報を前記識別キーを付けてサーバ側に所定時間幅をかけて所定データ量で送信する制御をする
ことを特徴とする請求項１記載の災害時通信支援装置。
【請求項３】
前記サーバは、所定時間幅をかけて送信された画像特徴点及び事象情報に基づいて、前記画像情報の現象を特定する
ことを特徴とする請求項１記載の災害時通信支援装置。
【請求項４】
前記重要度の高い画像特徴点は、災害時に発生する自然現象の特徴量を含む
ことを特徴とする請求項１記載の災害時通信支援装置。
【請求項５】
前記画像特徴点抽出部は、切り出された複数の画像特徴点の情報を取得し、
前記制御部は、前記災害時モードでは前記抽出した複数の画像特徴点に基づく事象情報のうち、前記重要度の高い画像特徴点に基づく事象情報を優先的に送信する制御をする
ことを特徴とする請求項１記載の災害時通信支援装置。
【請求項６】
災害時通信支援装置は、
被写体を撮影するステップと、
撮影された画像情報から災害状況を把握可能な重要度の高い画像特徴点を災害が発生している状況で抽出するステップと、
画像保存領域にディレクトリを作成し、当該ディレクトリに前記画像情報を保存するとともに、当該ディレクトリ名を識別値として前記画像情報と抽出された画像特徴点を解釈した事象情報とを紐付けし、当該紐付けにより関連付けられた前記画像情報及び前記事象情報を記憶するステップと、
前記画像情報又は前記事象情報を識別ＩＤを付けてサーバ側に送信するステップと、
通信規制のない通常時モードと通信規制のある災害時モードとの切替を受付けるステップと、
前記通常時モードでは前記画像情報及び前記識別ＩＤを送信し、前記災害時モードでは前記事象情報及び前記識別ＩＤを送信する制御をするステップと、を実行することを特徴とする前記災害時通信支援装置を用いた災害時通信支援方法。
【請求項７】
災害時通信支援装置に対して、
被写体を撮影するステップと、
撮影された画像情報から災害状況を把握可能な重要度の高い画像特徴点を災害が発生している状況で抽出するステップと、
画像保存領域にディレクトリを作成し、当該ディレクトリに前記画像情報を保存するとともに、当該ディレクトリ名を識別値として前記画像情報と抽出された画像特徴点を解釈した事象情報とを紐付けし、当該紐付けにより関連付けられた前記画像情報及び前記事象情報を記憶するステップと、
前記画像情報又は前記事象情報を識別ＩＤを付けてサーバ側に送信するステップと、
通信規制のない通常時モードと通信規制のある災害時モードとの切替を受付けるステップと、
前記通常時モードでは前記画像情報及び前記識別ＩＤを送信し、前記災害時モードでは前記事象情報及び前記識別ＩＤを送信する制御をするステップと、を実行させることを特徴とする前記災害時通信支援装置を機能させるための災害時通信支援プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、災害時通信支援装置、災害時通信支援方法及び災害時通信支援プログラムに関する。
【背景技術】
【０００２】
大規模災害が発生すると、その直後から安否確認や、被災状況確認・避難指示等を目的とした重要通信の要求が急激に増大する。東日本大震災では、東北地域で通常時の約６０倍、東京２３区内でも約５０倍の通信要求が発生し、通信サービスを安定的に提供するためには大きな困難を伴った。そのような交換能力を大幅に超える通信要求に対処するため、最大で９５％の通信規制が課され、２０の発呼に対し、１呼の割合（５％）でしか交換処理が完了（疎通）しなかったというケースも報告されている。
携帯電話などの移動通信サービスは、重要な社会インフラの一部と認識されており、大規模災害時であっても同サービスを安定的に提供することが期待される。このような状況を鑑み、携帯電話事業者は、同等な規模の通信要求が生じても、４の発呼に対し１呼の割合で疎通を確保（すなわち処理能力を５倍に拡大）することを目標とている。そして、それを達成するシステムが動的な通信制御技術により構築・運用可能であることを示すことを目指して検討を進めている。
【０００３】
一方、災害情報や安否情報の共有には２つの大きな考え方がある。１つは行政機関や特定の組織がＢＣＰ（Business Continuity Plan）に基づいて情報を集約する仕組みを作り、組織員のそれぞれの役割に従って情報を集め、必要なところに伝達するという考え方である。この方法は、効率的に目的の情報を集められるという点では優れている。しかしながら、情報収集者が被災したり情報を集約するサーバや通信手段が毀損したりすると情報収集が滞るという問題と、情報収集者の収集能力以上の情報は集められないため大規模災害時には対応が不十分になるという問題とがある。もう１つの考え方はクラウドソーシングという考え方で、情報のユーザ自身が収集者の役割も担うというものである。特定の組織やサーバに依存することなくクラウド環境にデータを集める仕組みを作り、情報のユーザ自身が災害情報や安否情報を収集してクラウド環境にアップロードする。その情報は誰でも自由に参照できるという仕組みである。ツイッターやＳＮＳ（Social Networking Service）などのソーシャルメディア技術が普及したために可能となった。
【０００４】
ソーシャルメディアを使ったクラウドソース型の災害情報・安否情報共有は、東日本大震災後に着目され研究が進められるようになった。この考え方の利点は、多くの情報が大量にすばやく集まるということにある。しかし情報の質のばらつきや偏りが大きな欠点ともなっている。これを解決するため、特定の目的に沿った利用が可能となるような様々なクラウドソース型のサービス（システムやツール）が提案されている。例えば、被災・復旧状況把握の目的に「ＧＩＳ(Geographic Information System)を活用した被災状況・復旧状況の提供システム」や「財団法人地方自治情報センター（ＬＡＳＤＥＣ）の復旧・復興関連システム」などがあり、安否確認用途では「Google Person Finder」などが有名である。その他、要援護者対応、情報発信、避難所管理、支援物資管理、生活再建支援などの分野で、多くのクラウドソース型サービスが提案されている。
【０００５】
これらのクラウドソース型サービスは地図情報などを利用するため、リッチメディアのデータ送受を行うものが多い。最近提案され始めている避難誘導型のサービスも含めて、先に述べたような動的な通信制御が可能になると、重要通信である音声呼が優先されることになる。そのため、画像などのリッチメディアコンテンツを扱うサービスが逆に利用しにくくなる可能性がある。その場合、最近提案され始めている災害時に避難経路を探索したりするようなサービスは使えなくなることが指摘されている。
災害時には、端末ユーザの身を守るための情報、例えば最適な避難ルート、避難施設などの状況、各所の浸水や火災・倒壊などによる危険状況、交通機関の稼働状況、飲料水や食料などの入手可能性を逐次収集し、提供又は閲覧するための技術を有するサービスが必要となる。
【０００６】
東日本大震災時には、輻輳や設備の停止により携帯電話が利用できず、停電によりテレビやラジオも使えない状況となって避難に必要な情報の入手が困難であったケースが報告されている。また、渋滞や交通機関の遮断により適切な避難経路を確保できなくなったことで、都市部の特定の学校などに避難者が溢れ、津波からの避難が遅れて命を落とした方も多かった。こうした事態の発生を回避することを目的として被災者が確実に安全を確保することを支援する新たなツールが今後、普及すると予想される。
【０００７】
特許文献１には、外気温、湿度及び風速の測定情報を通信ネットワークを介して管理装置へ送信する携帯端末と、携帯端末から送信された検出情報及び活動状態を表す情報を前記通信ネットワークを介して受信する管理装置と、を備える行動支援システムが記載されている。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２０１２−１４２０００号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、特許文献１記載の行動支援システムでは、通常時の行動支援に過ぎず災害時などでネットワークに接続することは考慮されていない。特に、大規模災害時など、通信が輻輳して通信が困難な場合を想定していないので、災害発生現場の状況や場所等を伝達することができず、利用者の身の保全を図ることができない課題がある。
【００１０】
そこで、本発明は、前記した問題を解決するために、被災現場など、輻輳した通信環境であっても重要度の高い現象だけは迅速に送信することのできる災害時通信支援装置、災害時通信支援方法及び災害時通信支援プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
前記課題を解決するため、本発明による災害時通信支援装置は、被写体を撮影する撮影部と、撮影された画像情報から災害状況を把握可能な重要度の高い画像特徴点を災害が発生している状況で抽出する画像特徴点抽出部と、画像保存領域にディレクトリを作成し、当該ディレクトリに前記画像情報を保存するとともに、当該ディレクトリ名を識別値として前記画像情報と抽出された画像特徴点を解釈した事象情報とを紐付けし、当該紐付けにより関連付けられた前記画像情報及び前記事象情報を記憶する記憶部と、前記画像情報又は前記事象情報を識別ＩＤを付けてサーバ側に送信する通信部と、通信規制のない通常時モードと通信規制のある災害時モードとの切替を受付けるモード切替受付部と、前記通常時モードでは前記画像情報及び前記識別ＩＤを送信し、前記災害時モードでは前記事象情報及び前記識別ＩＤを送信する制御をする制御部と、を備えることを特徴とする。
【発明の効果】
【００１２】
本発明によれば、被災現場など、輻輳した通信環境であっても重要度の高い現象だけは迅速に送信することのできる災害時通信支援装置、災害時通信支援方法及び災害時通信支援プログラムを提供することができる。
【図面の簡単な説明】
【００１３】
【図１】動的通信制御技術によるネットワークリソースの柔軟な割当を説明する図である。
【図２】ＣＭＳによるコンテンツ内のデータ量と重要度の関係を説明する図である。
【図３】ＣＭＳによる画像の認識と情報の抽出を説明する図である。
【図４】通信環境の認識と情報伝達量制御の概要を説明する図である。
【図５】コンテンツデータを送受信する携帯端末装置の動作モードを示す図である。
【図６】各場面の背景トラフィック、動作モード、及びサービス利用を説明する図である。
【図７】伝搬路（輻輳状態）と時間差・データ量との関係を説明する図である。
【図８】クラウドソース型災害情報の可視化サービスを説明する図である。
【図９】画像特徴点を抽出による画像データ量の縮小化と画像特徴点を解釈した事象情報の送信を説明する図である。
【図１０】本発明の実施形態に係る災害時通信支援装置の構成図である。
【図１１】上記実施形態に係る災害時通信支援装置のハードウェア構成図である。
【図１２】上記実施形態に係る災害時通信支援装置の動作状態を説明する図である。
【図１３】上記実施形態に係る災害時通信支援装置の動作を示すフローチャートである。
【図１４】上記実施形態に係る災害時通信支援装置の特徴点データの登録フローシーケンス図である。
【図１５】上記実施形態に係る災害時通信支援装置の画像系テーブルの関連図である。
【図１６】上記実施形態に係る災害時通信支援装置の未送信の画像データをサーバに送信するフローシーケンス図である
【発明を実施するための形態】
【００１４】
以降、本発明を実施するための形態（「本実施形態」という）を、図などを参照しながら詳細に説明する。また、本実施形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。
【００１５】
（背景説明）
災害時には、端末利用者が自身の身を守るための情報を逐次収集できることが重要である。自身の身を守るための情報には、例えば最適な避難ルート、避難施設などの状況、各所の浸水や火災・倒壊などによる危険状況、交通機関の稼働状況、飲料水や食料などの入手可能性を位置情報や時刻の情報を伴った画像などがある。また、災害時には、当該情報を提供し又は閲覧するための技術を有するサービスが必要であると認識された。
【００１６】
本発明では、入力端末としてスマートホンなどを想定し、情報を画面から直接入力できるようにする。
さらに、情報のサーバへのアップロードにおいては通信混雑状況に鑑み、通信環境が輻輳などにより悪化している場合や、ネットワークリソースの動的制御により重要通信である音声通信が優先されてリッチメディアの通信が抑制されている場合がある。このような場合は、画像情報の中から画像が表す事象の特徴を抽出し数値化して先に送信し、通信環境が回復した時点で先に送信した画像特徴点情報の一つ一つに紐付いた画像を送信するという手段により、送信データ量を縮小化する。これにより、輻輳や通信制御の環境下においても有効な情報の収集を可能とする。
なお、送受信データ量を縮小化する技術としてＪＰＥＧなどの画像圧縮技術が利用されている。しかしながら、データの縮小率は１／１０〜１／２０程度であり、リッチメディア制限の通信規制が発生している場合には、この程度のデータ量削減では送受信することはできないと考えられる。
【００１７】
（コグニティブ・メディア共有技術）
災害時通信支援装置は、コグニティブ・メディア共有技術（Cognitive Media Sharing： 以下ＣＭＳと表記）を用いた情報通信装置に適用することができる。
画像などのリッチメディア（容量が大きいデータ）には人が利用する上で、重要な情報と相対的に重要でない情報とが含まれる。例えば、会社名や個人氏名などの意味を含む情報は重要情報である。一方、文字領域や顔の部分の画像領域は重要度が中程度となり、写真の背景領域のラスタデータはさほど重要ではない情報である。画像、映像、音声などのリッチメディアのコンテンツから含まれる意味に従って特徴を抽出（部分情報抽出、インデックス付与、ダイジェスト化など）し、構造的なメディア情報に変換することによって、利用価値を変えずにデータ量を圧倒的に小さくすることが可能となる。画像１ＭＢ程度から氏名や会社名などが含まれる部分画像を抽出することによって１／５０〜１／１０００に縮小することが可能となる。
【００１８】
ＣＭＳを情報通信装置に応用する際に重要となるのは、通信環境の認識と情報伝達量の制御である。日本国内で平常時には電話網などの通信環境は極めて安定しているが、大災害時や発展途上国などの通信環境は不安定であることがある。この状況を察知し、平常時には全コンテンツデータを送受信しサーバのデータベースなどへ格納する。一方、輻輳発生などにより通信環境が不安定の場合は構造化された重要データだけを送受信してデータベースに格納し、通信環境が回復した時点で改めて元の全コンテンツデータを送受信してデータベースなどに格納された重要データと紐付ける、という技術が重要である。つまりこの技術は通信環境によって送受するデータに優先度を付与し、全コンテンツデータの送受信は時間の幅を持って成し遂げる、という考え方に基づく。これによって、通信環境が不安定であっても重要情報だけは即時に共有できるということになる。
【００１９】
（動的通信制御技術によるネットワークリソースの柔軟な割当）
図１は、動的通信制御技術によるネットワークリソースの柔軟な割当を説明する図である。図１は、携帯電話事業者が実施する通常時から災害時へのネットワークリソースの柔軟な割当のイメージを示す。
図１に示すように、ネットワークにより通信される情報には、重要通信順に、音声通話、メール、音楽、画像、動画、等のファイルがある。音楽、画像、動画、及びファイルは、リッチメディア通信と総称することができる。このうち音声通話及びメール（特に音声通話）は、災害時には重要通信となることが認識された。
通常時、すなわち通信量平常時には、音声通話、メール、音楽、画像、動画、及びファイルは、固定・携帯電話事業者、インターネット等を用いるネットワーク、運搬等の搬送により通信及び頒布を行うことができる。
災害時には、通信網そのものの被害、輻輳の発生と輻輳制御により通信量は制限される。東日本大震災のような大規模災害時は、より深刻であり、ユーザから見ると通信できないか通信できてもすぐに不通になる。図１に示すように、災害時には、インターネット等による地図検索や画像検索などのリッチメディア通信サービスが利用できにくくなる。
【００２０】
そこで、通常時には、音楽や画像、動画などのリッチメディア通信に割り当てられていた帯域を、災害時には音声通話やメールなどの重要通信に割り当てる。これにより、災害時において音声通話などの重要通信は確保される反面、通常時には利用できたインターネット等による地図検索や画像検索などのリッチメディア通信サービスが災害時に利用できにくくなる。
災害時は、輻輳の発生と、輻輳制御によるリッチメディア通信割り当て帯域の縮小化により、リッチメディア通信のデータを多用する災害時向けのサービスの動作保障が課題となる。
【００２１】
（通信路の混雑状況に応じたアプリケーション側での送受データ量制御）
ＣＭＳを用いて、通信路の混雑状況に応じたアプリケーション側での送受信データ量制御を行う。なお、ＣＭＳを適用することは一例であり、通信路の混雑状況に応じた送受信データ量制御を行うものであれば、どのようなものでもよい。
ＣＭＳの構成要素として、下記が考えられる。
１．コンテンツの認識と構造化
２．通信環境の認識と情報伝達量制御
３．ユーザの認識とアクセスコントロール
【００２２】
<コンテンツの認識と構造化>
図２は、ＣＭＳによるコンテンツ内のデータ量と重要度の関係を説明する図である。
図２に示すように、データ量と重要度からコンテンツの構造化を決定する。重要度が高いデータほど、データ量を少なくするようにコンテンツの構造化を行う。
【００２３】
図３は、ＣＭＳによる画像の認識と情報の抽出を説明する図である。
画像などのリッチメディア（容量が大きいデータ）には人が利用する上で、重要な情報と相対的に重要でない情報とが含まれる。図３の例では、会社名や個人氏名などの意味を含む情報は重要情報（図３ａ「意味」：重要度高参照）である。一方、文字領域や顔の部分の画像領域は重要度が中程度（図３ｂ「部分画像」：重要度中参照）となり、写真の背景領域のラスタデータはさほど重要ではない情報（図３ｃ「背景領域」：重要度低参照）である。
【００２４】
画像、映像、音声などのリッチメディアコンテンツに含まれる意味情報に従って特徴を抽出し（部分情報抽出、インデックス付与、ダイジェスト化）し、構造的なメディア情報へと変換する。特徴抽出は、例えば部分情報抽出、インデックス付与、ダイジェスト化により実施される。
【００２５】
図３に示すように、会社名や個人氏名などの意味を含む情報は重要度高、文字領域や顔の部分の画像領域は重要度中、写真の背景領域のラスタデータは重要度低であるとすると、災害時の送信対象は、より重要度の高いものから優先的に送ることが好ましい。この例では、図３ａの会社名や個人氏名などを優先的に送信する。図３ａの部分画像（本実施形態では、画像特徴点）が送られていれば、災害時の場所又は個人が特定可能になるからである。その後、所定時間幅をかけて、重要度中乃至重要度低の部分画像を送るようにする。なお、人によっては重要度高のものはない、又は重要度の順位は異なることも考えられる。しかしながら、会社名・個人氏名は、災害時の場所又は個人を特定可能な意味を含む重要度の高い部分画像として、判断・条件を付けることなく取り出した方法が迅速に対応できる点で好ましい。
上記、構造的なメディア情報に変換することによって、利用価値を変えずにデータ量を圧倒的に小さくすることが可能となる。本実施形態では、１ＭＢ程度の画像から氏名や会社名を抽出することによって１００Ｂ程度まで、すなわち１／１００００に縮小する。
【００２６】
<通信環境の認識と情報伝達量制御の概要>
図４は、通信環境の認識と情報伝達量制御の概要を説明する図である。
図４（ａ）は、コンテンツデータ１０とこのコンテンツデータ１０を送受信する携帯端末装置２０を示している。携帯端末装置２０は、例えばスマートホンなどの携帯情報端末であり、各種アプリケーションを搭載している。なお、携帯端末装置２０の構成及び動作詳細については後記する。コンテンツデータ１０は、図３のコンテンツデータ１０を例に採る。
携帯端末装置２０は、このコンテンツデータ１０をネットワークに接続されたサーバと送受信する。
【００２７】
図４（ｂ）は、平常時におけるコンテンツデータの送受信とサーバのデータベース（ＤＢ）格納を示し、図４（ｃ）は、輻輳発生時におけるコンテンツデータの送受信とサーバのＤＢ格納を示す。
図４（ｂ）に示すように、平常時には、全コンテンツデータ１０が送受信され、サーバのＤＢ３０に格納される。
図４（ｃ）に示すように、輻輳発生時には、重要コンテンツデータ１１（ここでは、氏名、会社名、撮影日時）のみが送受信され、ＤＢ３０に格納される。また、通信環境回復時に、送信されなかったデータを送受信し、両者を結合してＤＢ３０に格納する。
【００２８】
日本国内で平常時には電話網などの通信環境は極めて安定しているが、大災害時や発展途上国などの通信環境は不安定であることがある。携帯端末装置２０のユーザは、この状況を察知し、平常時には全コンテンツデータを送受信しサーバのＤＢ３０などへ格納する一方、輻輳発生などにより通信環境が不安定の場合は構造化された重要データだけを送受信してＤＢ３０に格納する。そして、通信環境が回復した時点で改めて元の全コンテンツデータ（又は送信されなかったデータ）を送受信してＤＢ３０などに格納された重要データと紐付ける。すなわち、通信環境に応じて送受するデータに優先度を付与し、全コンテンツデータの送受信は時間の幅を持って成し遂げるものである。これによって、通信環境が不安定であっても重要情報だけは即時に共有できる。
【００２９】
図５は、コンテンツデータ１０を送受信する携帯端末装置２０の動作モードを示す図である。
図５に示すように、携帯端末装置２０は、通常時モードと災害時モードの２つのモードを実装する。通常時モードは、送受データ量が多く、リッチメディアコンテンツの全データを利用可能である。災害時モードは、送受データ量が少なく、ＣＭＳにより重要で必要最小限のデータを活用する。
【００３０】
図６は、各場面の背景トラフィック、動作モード、及びサービス利用を説明する図である。ここでサービス利用とは、コンテンツデータの送受信である。
図６に示すように、平常時には、背景トラフィックは小、動作モードは通常時モード（図５参照）、サービス利用は利用可である。輻輳発生時で、かつ動作モードが通常時モードでは、背景トラフィックは大、サービス利用は不安定である。但し、輻輳発生時で、かつ動作モードが災害時モードでは、背景トラフィックは大、サービス利用は利用可である。つまり、輻輳発生時で背景トラフィックは大であっても、携帯端末装置２０が災害時モードに移行すると、サービス利用は利用可となる。これによって、通信環境が不安定であっても重要情報だけは即時に共有できる。
【００３１】
<通常時モードと災害時モードの説明>
電気通信事業者は、災害などで過度の通信の輻輳を回避するため、当該地域（災害発生時の場合は被災地域）内の設備に対して、適切な通信規制（トラフィックコントロール）を行うことにより、設備を保護するとともに重要通信を確保する。ここで、通信規制は、通常の通信時に対して所定の通信量を超えた場合、また交換能力に対して所定の通信量を終えた場合にかかる規制である。また、輻輳は、発呼(発信)に対する呼(応答)が所定の値以下の場合に現象等で示される。
通信規制には、システムダウンを防止するため、自動規制とトラフィック量に応じて人為的に行う手動規制がある。地震などの災害時には複数の無線基地局にて発信が集中するとともに、安否確認の電話やメールが全国から被災地域に集中する。この場合、電気通信事業者は、輻輳状態に応じて下記の方法を組み合わせて通信規制をしている。
・基地局での発信規制（音声、パケット通信）
・交換設備での発着信規制（音声、パケット通信）
・Ｅメール新着通知などのＳＭＳ（Short Message Service）規制
【００３２】
また、電気通信事業者は、電気通信事業法の規定に基づき、災害時などにおいて重要通信を確保することが義務付けられている。しかしながら、電気通信事業者が、それぞれの通信に対して「救援などのために必要な事項を内容とする通信」であることを判断することは困難である。このため、あらかじめ、災害時優先電話を設定し、この災害時優先電話から発呼された通信を優先的に取り扱うことで重要通信の確保を図っている。
輻輳は、携帯端末と無線基地局との間の無線区間のみならず、インフラネットワーク部分で発生することもある。通信規制のうち、無線区間における通信規制は「発信規制」と呼ばれる。
なお、コンサートや花火大会などのイベント時においても、特定の狭いエリアに通信トラフィックが集中するため、無線基地局において発信規制を行うことができる。
【００３３】
以上のことから、輻輳とは、通信が１個所に集まり混み合う現象を示し、一般的には災害などが発生要因である。但し、上記イベント時等も発生要因としてあり得る。通信規制は、この輻輳に対する電気通信事業者側の対応措置であり、どのような場合に通信規制を発動するかは電気通信事業者側の判断による。したがって、輻輳時であっても通信規制がない場合もあれば、全域的な輻輳がないにも拘わらず通信規制（発信規制）を行うこともあり得る。まして、携帯電話等のユーザとっては、自己の通信環境が輻輳状態にあること、また発信規制が行われていることを正確に知ることは困難であることが考えられる。
【００３４】
そこで本明細書では、通信規制があるとユーザが判断してモード切替受付部１１１ｃの操作キーを操作した場合に「災害時モード」に移行することとする。また、携帯端末装置２０が「災害時モード」移行情報を取り入れるアプリケーションを搭載し、かつそれを実行している場合も、自動的に「災害時モード」に移行することとする。前者の場合、ユーザ判断に基づくため必ずしも輻輳の有無と程度を認識することなく「災害時モード」に移行することができる。このため、災害時は勿論のこと、災害時であると認識しない／できない場合であっても「災害時モード」移行することができる利点がある。
【００３５】
特許請求の範囲にいう「災害時モード」とは、ユーザ操作又は該当アプリケーション実行時に電気通信事業者側からの通知により通常時モードから移行するモードをいい、「通常時モード」とは、当該「災害時モード」でないモードをいうものとする。このため、各モードの切り替えに際し、輻輳状態であること、また通信規制（発信規制）の有無・程度は問わない。
特許請求の範囲にいう「災害時モード」「通常時モード」については上述した通りである。「通常時モード」は、通信規制がなく（全くないか一部ない場合を含む）かつ輻輳時でない場合を主に想定している。また、「災害時モード」は、輻輳時の時と通信規制のある時のどちらか又は両方で成立することを主に想定している。
【００３６】
図７は、伝搬路（輻輳状態）と時間差・データ量との関係を説明する図である。図７は、東日本大震災発生時の移動通信網の状況を例示している。
図７に示すように、東日本大震災では、震災発生後、６時間から１０時間程度は非常に強い輻輳状態が続いた。地震発生３／１１ １４：４６後、３／１１ １５：００−３／１２ １４：００と、３／１２ １８０：００−３／１３ ０１：００との２回、発信規制が行われた。地震直前の１３時と１５時の呼数比率と発信規制率から換算すると、発信で約６０倍、着信で約４０のトラヒックが発生したと推定される。交換能力を大幅に超える通信要求に対処するため、最大で９５％の通信規制が課され、２０の発呼に対し、１呼の割合（５％）でしか交換処理が完了（疎通）しなかったと推定される。
【００３７】
図８は、クラウドソース型災害情報の可視化サービスを説明する図である。
図８に示すように、クラウドソース型災害情報の可視化サービスでは、行政機関や公的なサービスを司るクラウド環境に置かれた災害情報サーバ４０に対して、携帯端末装置２０のユーザが自由に情報をアップロードしたり検索することができる。ユーザは、自分が体験した災害の事象を記録し、また写真を撮影して情報を登録する。
【００３８】
（原理説明）
通信混雑時には、ネットワークリソースの動的制御が行われ、音声などの重要通信が優先される場合は大きなデータ量の画像を送ることが難しくなる。
そこで、本発明は、画像の中の重要情報（例えば火災現場の炎など）が含まれる画像情報から画像特徴点を抽出し、数値データとしてデータ量を大幅に縮小して送信する。こうして集められた画像特徴点は、行政機関から提供されるハザードマップや避難所にいる被災者などの情報とともに公開され、ユーザ自身が身の安全を図ったり、家族などの大切な人を捜索したりするときの情報として利用される。
【００３９】
図９は、画像特徴点を抽出による画像データ量の縮小化と画像特徴点を解釈した事象情報の送信を説明する図である。
図９（ａ）に示すように、撮影した画像情報４０には火災が発生している。火災状況は重要な情報である。
図９（ｂ）に示すように、ユーザが撮影した画像情報４０は、輻輳が起こっていない平常時には全情報がクラウド上のサーバに送信され、このサーバのデータベース５０に格納される。
【００４０】
図９（ｃ）に示すように、大規模災害などによって輻輳やそれに対応する重要通信優先の制御が行われている場合は、携帯端末装置２０（図８参照）は画像情報４０の炎部分を認識し、各炎の座標（ｘ，ｙ）と大きさを画像特徴点の数値データ４１として抽出する。そして、図９（ｄ）に示すように、画像特徴点の数値データ４１をサーバに送信する。すなわち、画像情報４０から各炎の画像特徴点が抽出され、画像特徴点の数値データ４１だけがサーバに送信され、データベース５０に格納される。このとき、元画像との関係を示す関連情報も同時にサーバのデータベース５０に格納される。
図９（ｆ）に示すように、情報の参照者は、通信状況に応じて予め携帯端末装置２０内に格納しておいた地図情報に識別された情報４２（ここでは火事）と元の全画像情報４０を参照できる。
図９（ｇ）に示すように、サーバ側では、携帯端末装置２０側から異なる時間に送信された画像特徴点に基づいて、画像情報の現象（洪水、火事、倒壊、閉鎖など）を特定することができる。
【００４１】
（ハードウェア構成）
図１０は、上記基本的な考え方に基づく本発明の実施形態に係る災害時通信支援装置の構成図である。
図１０に示すように、災害時通信支援システム１００は、スマートホン等の携帯端末装置１１０（災害時通信支援装置）と、携帯端末装置１１０用の基地局１２０と、携帯電話独自のネットワークである携帯電話通信網１３０と、パーソナルコンピュータなどの入力装置１４０と、入力装置１４０からアクセス可能なインターネットからなるネットワーク１５０と、携帯電話通信網１３０及びネットワーク１５０両方からデータアップロード可能なアップロードサーバ１６０と、アップロードサーバ１６０に専用回線１５１を介して接続され、アップロードサーバ１６０で収集されたデータを基に身元確認処理を実行するアプリケーションサーバ１７０と、を備える。
【００４２】
携帯端末装置１１０は、例えばスマートホン等の高機能情報端末装置である。また、ＰＤＡ（Personal Digital Assistants）、カメラ付き携帯電話機／ＰＨＳ（Personal Handy-Phone System）の携帯通信端末を用いてもよい。
携帯端末装置１１０は、携帯電話機として機能する場合、通信電波の通信方式として、ＰＤＣ（Personal Digital Cellular）方式、ＧＳＭ（Global System for Mobile Communications）（登録商標）方式、ＣＤＭＡ（Code Division Multiple Access）を用いる。
携帯端末装置１１０は、基地局１２０及び携帯電話通信網１３０を経由してアップロードサーバ１６０，アプリケーションサーバ１７０にアクセスする。
【００４３】
基地局１２０は、複数の携帯端末装置１１０からの電波をアンテナを経由して送受信し、携帯電話通信網１３０及びキャリアサーバ（図示せず）を介してアップロードサーバ１６０，アプリケーションサーバ１７０に接続される。基地局１２０及び携帯電話通信網１３０は、携帯端末装置１１０の携帯電話機能において情報の送受信を行う際に、自端末と相手端末を接続する。
携帯電話通信網１３０は、移動体通信網、公衆電話網などから構成するネットワークである。
【００４４】
入力装置１４０は、ネットワーク１５０を経由してアップロードサーバ１６０及びアプリケーションサーバ１７０にアクセスする。
ネットワーク１５０は、ＬＡＮやインターネットなどから構成するネットワークであり、有線系又は無線系などネットワークの種類とプロトコルの種類は特に問わない。
アップロードサーバ１６０とアプリケーションサーバ１７０は、１つのサーバであってもよい。また、アップロードサーバ１６０とアプリケーションサーバ１７０は、専用回線１５１を使用せずにインターネットなどのネットワーク１５０を用いてもよい。
【００４５】
アップロードサーバ１６０は、サーバ全体の制御及び、携帯端末装置１１０及びインターネットからのアップロード機能を実現するコンピュータからなる制御部１６１と、制御プログラムや固定データ等を記憶するＲＯＭ（Read Only Memory）、ＣＰＵ（Central Processing Unit）の作業用記憶領域であるＲＡＭ（Random Access Memory）、ＥＥＰＲＯＭ（electrically erasable programmable ROM）などの不揮発性メモリやハードディスクなどからなりユーザ管理情報を含む各種データを格納するデータ格納部１６２と、携帯電話通信網１３０及びネットワーク１５０に接続して通信を行う通信部１６３と、を備える。なお、アップロードサーバ１６０は、キャリア又は顧客情報を管理する事業者の管理サーバに接続されるものでもよい。
【００４６】
アプリケーションサーバ１７０は、サーバ全体の制御及び情報配信機能、携帯端末装置１１０から送信された情報を処理するコンピュータからなる制御部１７１と、制御プログラムや固定データ等を記憶するＲＯＭ、ＣＰＵの作業用記憶領域であるＲＡＭ、ＥＥＰＲＯＭなどの不揮発性メモリやハードディスクなどからなりユーザ管理情報を含む各種データを格納するデータ格納部１７２と、アップロードサーバ１６０に接続して通信を行う通信部１７３と、を備える。制御部１７１は、携帯端末装置１１０側から異なる時間に送信された画像特徴点及び事象情報に基づいて、画像情報の現象（洪水、火事、倒壊、閉鎖など）を特定する特徴解釈部１７１ａを有する。
【００４７】
図１１は、携帯端末装置１１０のハードウェア構成図である。
図１１に示すように、携帯端末装置１１０は、制御部１１１、記憶部１１２、キー入力部１１３、ＬＣＤ（Liquid Crystal Display）表示部１１４、タッチパネル１１５、カメラ１１６、ライト１１６ａ、着信報知ＬＥＤ１１６ｂ、アンテナ１１７ａを有する無線部１１７、ＧＰＳ（Global Positioning System）１１８、及びレシーバ１１９を備えて構成される。
【００４８】
制御部１１１は、本装置全体を制御するマイクロコンピュータ等からなる。マイクロコンピュータは、ＲＯＭに記憶された制御プログラムを読み出してＲＡＭに展開し、ＣＰＵが各種処理を実行する。
【００４９】
制御部１１１は、撮影された画像情報から重要度の高い画像特徴点を災害が発生している状況で抽出する画像特徴点抽出部１１１ａと、通信規制のない通常時モードと、輻輳時を含む通信規制のある災害時モードとの切替を受付けるモード切替受付部１１１ｂと、を備える。ここで、重要度の高い画像特徴点を、実際に災害が発生している状況で抽出するようにすれば、災害時に発生する自然現象をより適切に取得することができる。
【００５０】
制御部１１１は、通常時モードでは画像情報及び関連情報を送信し、災害時モードでは画像特徴点及び事象情報を送信する制御をする。制御部１１１は、災害時モードにおいて、関連付けて記憶された画像特徴点及び事象情報を読み出し、時間軸上で所定時間幅をかけて所定データ量で送信する制御をする。
【００５１】
記憶部１１２は、各種処理のプログラムを収めたＲＯＭ、ＲＡＭ、電気的に書換可能な不揮発性メモリであるＥＥＰＲＯＭ等から構成される。記憶部１１２は、装置全体の制御を行うＣＰＵによりプログラム格納用、情報処理実行用として使用される。また、不揮発性メモリには、端末の番号や名前などの端末固有の端末情報が記憶されている。記憶部１１２は、ＳＤ（Secure Digital）カード、ＵＳＢ（Universal Serial Bus）メモリ、メモリスティック（Memory Stick）などの外部メモリを含む。
記憶部１１２は、抽出された画像特徴点を解釈した事象情報と元の全体画像とを関連情報により関連付けて記憶する。
【００５２】
キー入力部１１３は、ユーザからのキー操作情報を入力生成する。キー入力部１１３は、制御部１１１のモード切替受付部１１１ｂと共に、輻輳時を含む通信規制のある災害時モードとの切替を受付けるモード切替受付部としての機能を備える。
【００５３】
ＬＣＤ表示部１１４は、筐体の表面の略全面を覆う大型ディスプレイである。ＬＣＤ表示部１１４は、ＬＣＤディスプレイ又は有機ＥＬ（Organic Electro-Luminescence）ディスプレイ、白色ＬＥＤバックライト及び各ドライバ等で構成され、受信した情報の内容やコンテンツ等を表示する。
【００５４】
タッチパネル１１５は、表示部１１４の表示画面内で、任意の位置を指示するためのポインティングデバイスである。タッチパネル１１５は、ユーザが上面を指で押したり、スライドしたり、離したりすることにより各操作を検出する。
【００５５】
カメラ１１６は、例えばＣＣＤ（Charge Coupled Device）（エリア型固体撮像素子）カメラである。本実施形態では、カメラ１１６は、被写体を撮影する撮影部としての機能を有する。
【００５６】
ライト１１６ａは、暗い場所や画像情報読み取り時等にユーザ操作等により発光する。
着信報知ＬＥＤ１１６ｂは、着信を報知する。
無線部１１７は、アンテナ１１７ａを介して電波を送受信し、携帯電話通信網１３０との通信を行う。無線部１１７は、画像情報又は部分画像情報と関連情報をサーバ側に送信する通信部である。
【００５７】
ＧＰＳ１１８は、位置情報の電波をＧＰＳ衛星等から受信するＧＰＳアンテナを備え、ＧＰＳアンテナを介して受信した情報より、現在位置情報を、緯度／経度の２つのパラメータとして算出するＧＰＳ機能により位置情報を取得する。なお、ＧＰＳ１１８に代えて、基地局１２０及び携帯電話通信網１３０を介して携帯電話会社サーバと情報の送受信を行い、接近確認から自端末の現在位置情報を取得することも可能である。
レシーバ１１９は、音声信号を出力するスピーカ及びユーザから音声信号を入力するマイクから構成される。スピーカは、ハンズフリー通話用のラウドスピーカ配置を含み、耳に当てて使用するレシーバ用途には限定されない。
【００５８】
以下、上述のように構成された災害時通信支援システム１００の動作を説明する。
図１２は、災害時通信支援システム１００の動作状態を説明する図である。図１０及び図１１と同一構成部分には同一番号を付している。図１２は、動作説明のために記載されており、制御部１１１等は省略されている。
ステップＳ１；
携帯端末装置１１０のカメラ１１６（画像入力装置）により画像を撮影する。カメラ１１６で撮影された画像は、データ格納装置１１２ａを通してＧ１としてディレクトリに端末内の固有識別ＩＤで紐付けされて保存される。このとき、データ格納装置１１２ａに識別情報Ｋ１と画像のディレクトリ情報Ｇ１とを紐付けて保存する。
【００５９】
ステップＳ２；
部分画像抽出部１１１ａは、データ格納装置１１２ａに保存された画像から災害などの事象の特徴量を数値データを取り出す。
【００６０】
ステップＳ３；
部分画像抽出部１１１ａは、識別情報Ｋ１と特徴情報Ｃ１とを紐付けてデータ格納装置１１２ａに保存する。画像が複数撮影されたときは、Ｋ２，Ｇ２，Ｃ２・・・Ｋｘ，Ｇｘ，Ｃｘとして保存する。
【００６１】
ステップＳ４，Ｓ５；
操作者により、災害情報のアップロードの操作が行われた場合（ステップＳ４）は、携帯端末装置１１０内で通信規制の有無に拠って設定されたモードが災害時モードとなっている場合は、識別情報Ｋｘと特徴情報Ｃｘと画像撮影時間や位置情報などの付加情報Ｐｘとを組み合わせて、アプリケーションサーバ１７０（災害情報データベース）に送信する（ステップＳ５）。災害時モードは、特に災害を識別するわけではなく、通信規制などの移動体通信ネットワークの動的制御が行われていることを示すモードである。
ここで、携帯端末装置１１０ユーザが、他者がアップロードした災害情報を参照する場合は、サーバの情報を参照する操作によってアップロードされた全ての画像情報を閲覧可能とする。
【００６２】
ステップＳ６
サーバ側で受信されたデータのうち、特徴情報Ｃｘは特徴解釈部１７１ａにより事象情報Ｅｘに変換される。
【００６３】
ステップＳ７
変換された事象情報Ｅｘは、データ格納部１７２にＫｘ，Ｅｘ，Ｐｘを紐付けて格納される。
【００６４】
ステップＳ８；
アプリケーションサーバ１７０側で受信されたデータは、データ格納部１７２にＫｘ，Ｍｘ，Ｐｘを紐付けて格納する。
【００６５】
ステップＳ９；
携帯端末の利用者が、他者がアップロードした災害情報を参照する場合は、アプリケーションサーバ１７０の情報を参照する操作によってアップロードされた全ての画像情報を閲覧可能とし、その中から選択した事象情報と付加情報を識別情報Ｋｘの指定により読み出す。
ステップＳ１０
識別情報Ｋｘの指定により読み出した事象情報と付加情報を利用している端末で受信する。
【００６６】
ステップＳ１１；
識別情報Ｋｘの指定により読み出した事象情報と付加情報をＬＣＤ表示部１１４（画像出力装置）により表示する。
【００６７】
ステップＳ１２；
携帯端末装置１１０のモードが通信規制の行われていない通常モードになっているときに、携帯端末装置１１０ユーザからのサーバへの画像アップロード操作が行われた場合は、識別情報Ｋｘに元画像情報Ｇｘ（画像本体）と付加情報を紐付けてデータ格納装置１１２ａから読み出す。
【００６８】
ステップＳ１３；
携帯端末装置１１０は、データ格納装置１１２ａから読み出した識別情報Ｋｘに元画像情報Ｇｘ（画像本体）と付加情報を紐付けた情報をアプリケーションサーバ１７０に送信する。
【００６９】
ステップＳ９；
アプリケーションサーバ１７０は、識別情報Ｋｘを参照し、既にＫｘに紐付く事象情報ＥｘやＰｘが存在する場合は、それらに関連付けてアプリケーションサーバ１７０と画像格納用のディレクトリに格納する。紐付く部分画像情報が存在しない場合は、新たなデータレコードとして格納する。
【００７０】
ステップＳ１４；
通常時モードのときに、携帯端末装置１１０ユーザから画像及び災害情報の参照の要求が出た場合には、アプリケーションサーバ１７０は要求された画像の識別情報に合わせた画像と付加情報とを送信する。
【００７１】
ステップＳ１１；
携帯端末装置１１０は、受信した画像及び付加情報を画像出力する。
【００７２】
以上のように、同一事象の画像情報は元画像と画像特徴点とに分離されて携帯端末装置１１０側に保持され、それと合わせて元画像と事象情報とがアプリケーションサーバ１７０側で保持される。そして、それぞれの情報の伝送自体は災害時と通常時の２つのモードによって場合分けされ、最終的には通信環境が安定した状態（輻輳や通信規制が発生していない状態）となったときに結合されて同一の情報として利用される。このような仕組みによって時間の幅をもって画像特徴点と全体画像情報との共有を実現することができる。
【００７３】
図１３は、災害時通信支援システム１００の動作を示すフローチャートである。
まず、ステップＳ２１で携帯端末装置１１０は、カメラ１１６による画像入力操作で画像情報（図９参照）を入力する。
ステップＳ２２で携帯端末装置１１０の画像特徴点抽出部１１１ａは、撮影された画像情報（図９（ｄ）参照）から重要度の高い画像特徴点（図９（ｅ）参照）を切り出す。
ステップＳ２３で携帯端末装置１１０は、入力された画像情報・部分画像に対し内部ＩＤを取得してデータ格納部１１２ａに格納する。
ステップＳ２４で携帯端末装置１１０は、データをアプリケーションサーバ１７０側にアップロードする送信操作を受け付けると、ステップＳ２５でモード切替受付部１１１ｂは、通信モードが通常時か災害時かを判別する。ここで通信モードは、通常時アップロードの通常時送信ボタンと災害時アップロードの災害時（輻輳時）送信ボタンの押下により判別してもよい。
【００７４】
通信モードが通常時の場合、ステップＳ２６で携帯端末装置１１０は、識別ＩＤと全体画像情報をアプリケーションサーバ１７０に送信する。通信モードが災害時の場合、ステップＳ２７で携帯端末装置１１０は、識別ＩＤと画像特徴点をアプリケーションサーバ１７０に送信する。
以下、ステップＳ２８−Ｓ３０，Ｓ３４，Ｓ３５，Ｓ３７−Ｓ３９は、アプリケーションサーバ１７０側の処理ステップである。
ステップＳ２８でアプリケーションサーバ１７０は、通常時、携帯端末装置１１０から送信された識別ＩＤと全体画像情報を受信する。ステップＳ２９でアプリケーションサーバ１７０は、災害時、携帯端末装置１１０から送信された識別ＩＤと画像特徴点を受信する。
ステップＳ２９でアプリケーションサーバ１７０の特徴解釈部１７１ａは、識別ＩＤと画像特徴点に基づいて事象の解釈をする。
ステップＳ３１でアプリケーションサーバ１７０は、受信したデータをデータ格納部１７２（災害情報データベース）に格納する。そして、アプリケーションサーバ１７０は、データ格納部１７２に格納した情報（識別ＩＤと全体画像情報と部分画像）を携帯端末装置１１０に送信する。
【００７５】
ステップＳ３２で携帯端末装置１１０は、再送信操作を受け付けると、ステップＳ３３で通信モードが通常時か災害時かを判別する。
通信モードが通常時の場合、ステップＳ３４で携帯端末装置１１０は、識別ＩＤと全体画像情報をアプリケーションサーバ１７０に送信する。通信モードが災害時の場合、そのまま終了する。あるいは、通信モードが通常時になるまで所定時間待機する態様でもよい。
ステップＳ３５でアプリケーションサーバ１７０は、識別ＩＤと全体画像情報を受信し、ステップＳ３６でアプリケーションサーバ１７０は、識別ＩＤにより画像特徴点に連結してデータ格納部１７２（災害情報データベース）に格納する。そして、アプリケーションサーバ１７０は、データ格納部１７２に格納した情報（識別ＩＤにより既受信部分画像に連結した画像情報）を携帯端末装置１１０に送信する。
【００７６】
ステップＳ３７で携帯端末装置１１０は、キー入力部１１３又はタッチパネル１１５操作によりアプリケーションサーバ１７０に参照要求を発行する。
ステップＳ３８でアプリケーションサーバ１７０は、参照要求を受け付けると、通信モードが通常時か災害時かを判別する。
通信モードが通常時の場合、ステップＳ３９でアプリケーションサーバ１７０は、全体画像情報を携帯端末装置１１０に送信する。通信モードが災害時の場合、ステップＳ４０でアプリケーションサーバ１７０は、事象情報を携帯端末装置１１０に送信する。
ステップＳ４１で携帯端末装置１１０は、アプリケーションサーバ１７０から送信された全体画像情報を受信してステップＳ４２に進む。ステップＳ４２で携帯端末装置１１０は、アプリケーションサーバ１７０から送信された事象情報を受信してステップＳ４３に進む。
ステップＳ４３で携帯端末装置１１０のＬＣＤ表示部１１４は、受信した画像又は事象情報を表示して本フローを終了する。
【００７７】
<画像特徴点抽出の補足説明>
画像識別手法は１つの計算機（サーバ）で処理が完結するように実施されることが一般的である。これは、画像識別の計算量が大きいため多くの計算リソース（ＣＰＵやメモリ）を必要とするためである。
本実施形態では、災害時に特化することによって、携帯端末装置１１０側で画像の特徴量抽出処理を行い、その後の識別処理をアプリケーションサーバ１７０側で行う。これにより、携帯端末装置１１０のような計算リソースを潤沢に利用できない環境で動作するアプリケーションでも画像識別を利用することができる。また、ネットワークにデータ量の大きな画像そのものを流通されることのない、ネットワークに負荷をかけない画像識別を実現することができるという効果が得られる。
【００７８】
画像から抽出される特徴量は、画像の回転や拡大・縮小に影響を受けないようにするためのアルゴリズムで計算される。このアルゴリズムでは、あらゆる物体・事象を対象とするため、災害の事象に特化した特徴量を抽出できるわけではない。より精度高く災害の事象を識別させるためには、予め用意する必要のある災害の事象の特徴のモデル（識別器）を学習するためのデータ量を増やす必要がある。災害時の利用に特化することで、この学習データのバリエーションとデータ量の増大を回避することができる。
【００７９】
また、重要度の高い画像特徴点は、災害時に発生する自然現象の特徴量から抽出される。災害時に発生する自然現象は、火災だけに留まらず、洪水（津波）、倒壊、閉鎖などがある。例えば、火災の場合、火災の炎の輪郭を画像特徴点の一つとして抽出する。また、予めサーバ側に現象の特徴量を学習させておけば、どのような災害現象にも対応することができる。なお、ここでいう学習とは典型的な災害現象の画像を複数、パターン認識させることによって、その災害特有の特徴点のパターンをサーバ側で保持することをいう。
【００８０】
図１４は、特徴点データの登録フローシーケンス図である。図１４は、災害時モード時に画像を登録した場合（特徴点データをサーバに登録する）を示している。なお、実装アプリ「名称：絆」（画像伝言掲示板）と画像特徴点に当てはめ、サーバの動作モードが災害時モードの時に画像登録を行った場合を想定する。
また、図１５は、画像系テーブルの関連図である。図１５において、画像伝言テーブル２００、画像伝言関係テーブル２１０、画像格納テーブル２２０を示している。１
【００８１】
図１４に示すように、
（１）絆ＤＢに画像（特徴点）データの親となるデータ（画像伝言板）の登録を行う[図１４の特徴点登録フローの対応する処理番号：1, 1.1, 1.1.1以下同様]。（画像伝言テーブル２００参照）
（２）端末側で画像の特徴点データを作成する[1.2, 1.2.1]。
（３）上記（２）の特徴点データをサーバに送信し絆ＤＢに登録を行う[1.3, 1.3.1, 1.3.2, 1.3.3]。（画像伝言関係テーブル２１０参照）
（４）特徴点データの登録のみで、実際の画像データが未送信の情報（画像未送信情報）を端末側に保存する[1.4]。
【００８２】
図１６は、未送信の画像データをサーバに送信するフローシーケンス図である。図１６は、通信網の輻輳状態が解消され、サーバの動作モードが災害時モードから通常時モードに移行した後の端末側のアプリケーションを起動したタイミングで、未送信だった画像データを送信するフローを示す。特徴点情報を本来の画像データに置き換えるフローである。
【００８３】
図１６に示すように、
（１）端末アプリケーション起動時に、サーバと通信を行いサーバの動作モードを取得する[2, 2.1]。
（２）画像未送信情報から、特徴点データを登録した時に採番された画像キー、特徴点データに対応する画像データのファイル名、親となる画像伝言板の情報を取得する[2.2]。
（３）特徴点データが、サーバに登録されているか確認を行う。サーバ側にまだ対応する画像が送信されていないことを確認するためである[2.3, 2.3.1]。（画像格納テーブル２２０参照）
（４）画像データとして特徴点データを登録した画像伝言板に追加登録を行う[2.4, 2.4.1, 2.4.2]。（画像伝言関係テーブル２１０/画像格納テーブル２２０参照）
（５）画像データの登録が行えた場合、対応する特徴点データの削除を行う。本来の画像データが登録でき、特徴点データが不要となったためである[2.5, 2.5.1, 2.5.1.1, 2.5.1.2]。（画像伝言関係テーブル２１０/画像格納テーブル２２０参照）
【００８４】
以上説明したように、本実施形態に係る災害時通信支援システム１００は、制御部１１１、記憶部１１２、キー入力部１１３、ＬＣＤ表示部１１４、タッチパネル１１５、及びカメラ１１６を備え、制御部１１１は、撮影された画像情報から災害状況を把握可能な重要度の高い画像特徴点を災害が発生している状況で抽出する画像特徴点抽出部１１１ａと、通信規制のない通常時モードと通信規制のある災害時モードとの切替を受付けるモード切替受付部１１１ｂと、を備える。制御部１１１は、通常時モードでは画像情報及び関連情報を送信し、災害時モードでは画像特徴点及び事象情報を送信する制御をする。制御部１１１は、災害時モードにおいて、関連付けて記憶された画像特徴点及び事象情報を読み出し、時間軸上で所定時間幅をかけて所定データ量で送信する制御をする。このように通常時（平常時）と災害時（輻輳時）とでサービスを司る端末アプリケーションの動作が異なる、あるいは動作モードをシフトさせるようにしている。
【００８５】
この構成により、災害時などで被災現場の状況写真などを携帯端末（携帯端末装置１１０）で撮影し、リッチメディアの通信制限が懸かっている状態でも重要情報だけはクラウド上の災害情報サーバ（アプリケーションサーバ１７０）にアップロードすることが可能となる。すなわち、災害によって輻輳が発生している状況では、データ量の大きい画像の送信は困難になる。本実施形態では、画像情報のうち重要な部分だけを抽出してデータ量を縮小化し、必要最小限の情報共有を確保できる。また輻輳が終息した段階で元画像を送受信し全体を把握できる。
【００８６】
災害情報サーバ側では、災害時であっても少なくとも、意味を含む重要情報だけは閲覧することが可能になる。災害発生現場の状況や場所等が把握できるので、利用者の身の保全を図ることができる。また、画像特徴点は通信が安定した段階で元画像情報と紐付けして確認できることで、情報の曖昧性を排除することも可能となる。
【００８７】
また、本実施形態では、画像特徴点と元画像情報とを時間差をおいて送信、又は関連付けるので、大規模災害の発生による通信規制が行われている環境下において、クラウドソース型の災害情報の共有システムとしての利用が期待される。自治体や公的機関による住民向けサービスとしての利用が想定される。
【００８８】
本発明は上記の実施形態例に限定されるものではなく、特許請求の範囲に記載した本発明の要旨を逸脱しない限りにおいて、他の変形例、応用例を含む。
また、上記した実施形態例は本発明をわかりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施形態例の構成の一部を他の実施形態例の構成に置き換えることが可能であり、また、ある実施形態例の構成に他の実施形態例の構成を加えることも可能である。また、各実施形態例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
【００８９】
また、上記実施の形態では、災害時通信支援装置及び災害時通信支援方法という名称を用いたが、これは説明の便宜上であり、装置の名称は身元確認支援システム、また方法の名称は身元確認支援方法等であってもよい。
以上説明した災害時通信支援方法は、この災害時通信支援方法を機能させるためのプログラムでも実現される。このプログラムはコンピュータで読み取り可能な記録媒体に格納されている。
【００９０】
また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行するためのソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、又は、ＩＣ（Integrated Circuit）カード、ＳＤ（Secure Digital）カード、光ディスク等の記録媒体に保持することができる。また、本明細書において、時系列的な処理を記述する処理ステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）をも含むものである。
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしもすべての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
【符号の説明】
【００９１】
１００  災害時通信支援システム
１１０  携帯端末装置（災害時通信支援装置）
１１１  制御部
１１１ａ  部分画像抽出部
１１１ｂ  モード切替受付部
１１２  記憶部
１１２ａ  データ格納部
１１３  キー入力部
１１４  ＬＣＤ表示部
１１５  タッチパネル
１１６  カメラ
１１７  無線部（通信部）
１２０  基地局
１３０  携帯電話通信網
１４０  入力装置
１５０  ネットワーク
１６０  アップロードサーバ
１７０  アプリケーションサーバ
【図１】
2014192633.tif 000003
【図２】
2014192633.tif 000004
【図３】
2014192633.tif 000005
【図４】
2014192633.tif 000006
【図５】
2014192633.tif 000007
【図６】
2014192633.tif 000008
【図７】
2014192633.tif 000009
【図８】
2014192633.tif 000010
【図９】
2014192633.tif 000011
【図１０】
2014192633.tif 000012
【図１１】
2014192633.tif 000013
【図１２】
2014192633.tif 000014
【図１３】
2014192633.tif 000015
【図１４】
2014192633.tif 000016
【図１５】
2014192633.tif 000017
【図１６】
2014192633.tif 000018
【手続補正書】
【提出日】平成25年4月15日(2013.4.15)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】００２４
【補正方法】変更
【補正の内容】
【００２４】
画像、映像、音声などのリッチメディアコンテンツに含まれる意味情報に従って特徴を抽出（部分情報抽出、インデックス付与、ダイジェスト化）し、構造的なメディア情報へと変換する。特徴抽出は、例えば部分情報抽出、インデックス付与、ダイジェスト化により実施される。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】００３６
【補正方法】変更
【補正の内容】
【００３６】
図７は、伝搬路（輻輳状態）と時間差・データ量との関係を説明する図である。図７は、東日本大震災発生時の移動通信網の状況を例示している。
図７に示すように、東日本大震災では、震災発生後、６時間から１０時間程度は非常に強い輻輳状態が続いた。地震発生３／１１ １４：４６後、３／１１ １５：００−３／１２ １４：００と、３／１２ １８：００−３／１３ １：００との２回、発信規制が行われた。地震直前の１３時と１５時の呼数比率と発信規制率から換算すると、発信で約６０倍、着信で約４０のトラヒックが発生したと推定される。交換能力を大幅に超える通信要求に対処するため、最大で９５％の通信規制が課され、２０の発呼に対し、１呼の割合（５％）でしか交換処理が完了（疎通）しなかったと推定される。