特許 7666731 サーバ装置、サーバ装置の制御方法及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2025-04-14

(45)【発行日】2025-04-22

(54)【発明の名称】サーバ装置、サーバ装置の制御方法及びプログラム

(51)【国際特許分類】

   G06Q 50/26 20240101AFI20250415BHJP

【ＦＩ】

G06Q50/26

【請求項の数】 9

(21)【出願番号】P 2024507207

(86)(22)【出願日】2022-03-14

(86)【国際出願番号】 JP2022011294

(87)【国際公開番号】W WO2023175667

(87)【国際公開日】2023-09-21

【審査請求日】2024-07-02

(73)【特許権者】

【識別番号】000004237

【氏名又は名称】日本電気株式会社

(74)【代理人】

【識別番号】100168310

【弁理士】

【氏名又は名称】▲高▼橋 幹夫

(72)【発明者】

【氏名】米丸 浩一郎

(72)【発明者】

【氏名】田代 統

(72)【発明者】

【氏名】川崎 晃

(72)【発明者】

【氏名】小林 航生

(72)【発明者】

【氏名】吉川 英希

(72)【発明者】

【氏名】落合 敏功

【審査官】塩田 徳彦

(56)【参考文献】

【文献】特開２００９－１３４４９０（ＪＰ，Ａ）

【文献】特開２００３－０３６３３３（ＪＰ，Ａ）

【文献】行政のＢＣＰは業務の選択が難しい！ 先進県・兵庫県の防災システム 災害本部の意思決定まで支援するスグ，リスク対策．ｃｏｍ Ｖｏｌ．５，新建新聞社，2008年01月25日，P. 28-31

【文献】深田 秀実 HIDEMI FUKADA 他，地盤応答震度推定法を組み込んだ地震災害時初動活動支援システムの提案 A Proposal of Support System for，情報処理学会論文誌 第４８巻 第３号 IPSJ Journal，社団法人情報処理学会 Information Processing Socie，2007年03月15日，P. 1020-1037，ISSN：0387-5806

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００－９９／００

(57)【特許請求の範囲】

【請求項1】

第１の自治体の管轄地域で発生したイベントを検出する、検出部と、
前記発生したイベントの影響範囲を特定する、特定部と、
前記特定された影響範囲に基づいて、支援を要請する第２の自治体を選択する、選択部と、
前記選択された第２の自治体のサーバ装置に、支援内容を含む支援協力要請を送信する、支援要請部と、
を備え、
前記検出部は、前記管轄地域に滞在する利用者の端末から送信された情報提供要求を前記イベントとして検出し、
前記選択部は、前記影響範囲と重複する管轄地域を持つ自治体を、前記支援を要請する第２の自治体として選択し、
前記情報提供要求には施設の案内を要求することが記載され、
前記支援要請部は、前記施設の案内に関する情報提供を前記支援内容とする前記支援協力要請を生成し、
前記端末から送信された情報提供要求に応じて、前記第１の自治体の管轄地域に存在する施設に関する第１の情報を生成すると共に、前記第２の自治体のサーバ装置により生成された前記第２の自治体の管轄地域に存在する施設に関する第２の情報と、前記生成された第１の情報と、を前記端末に送信する、情報提供処理部をさらに備える、サーバ装置。

【請求項2】

前記支援要請部は、イベントの種類に応じた前記支援内容を定める要望条件に基づき、前記支援協力要請を生成する、請求項１に記載のサーバ装置。

【請求項3】

前記検出部は、前記第１の自治体の管轄地域で発生した災害を前記イベントとして検出し、
前記選択部は、前記影響範囲と重複しない管轄地域を持つ自治体を、前記支援を要請する第２の自治体として選択する、請求項１又は２に記載のサーバ装置。

【請求項4】

前記選択部は、前記影響範囲と重複しない管轄地域を持つ複数の自治体それぞれの属性情報に基づいて、前記支援を要請する第２の自治体を選択する、請求項３に記載のサーバ装置。

【請求項5】

前記支援要請部は、避難所で用いられる物品の提供を前記支援内容として含む前記支援協力要請を生成する、請求項３又は４に記載のサーバ装置。

【請求項6】

前記第１の自治体の管轄領域内の前記影響範囲に住む住民の数に基づいて、前記第２の自治体へ支援を要請するか否か判定する、判定部をさらに備える、請求項３乃至５のいずれか一項に記載のサーバ装置。

【請求項7】

前記施設は、観光施設である、請求項１乃至６のいずれか一項に記載のサーバ装置。

【請求項8】

サーバ装置において、
第１の自治体の管轄地域で発生したイベントを検出し、
前記発生したイベントの影響範囲を特定し、
前記特定された影響範囲に基づいて、支援を要請する第２の自治体を選択し、
前記選択された第２の自治体のサーバ装置に、支援内容を含む支援協力要請を送信する、サーバ装置の制御方法であって、
前記管轄地域に滞在する利用者の端末から送信された情報提供要求を前記イベントとして検出し、
前記影響範囲と重複する管轄地域を持つ自治体を、前記支援を要請する第２の自治体として選択し、
前記情報提供要求には施設の案内を要求することが記載され、
前記施設の案内に関する情報提供を前記支援内容とする前記支援協力要請を生成し、
前記端末から送信された情報提供要求に応じて、前記第１の自治体の管轄地域に存在する施設に関する第１の情報を生成すると共に、前記第２の自治体のサーバ装置により生成された前記第２の自治体の管轄地域に存在する施設に関する第２の情報と、前記生成された第１の情報と、を前記端末に送信する、サーバ装置の制御方法。

【請求項9】

サーバ装置に搭載されたコンピュータに、
第１の自治体の管轄地域で発生したイベントを検出する処理と、
前記発生したイベントの影響範囲を特定する処理と、
前記特定された影響範囲に基づいて、支援を要請する第２の自治体を選択する処理と、
前記選択された第２の自治体のサーバ装置に、支援内容を含む支援協力要請を送信する処理と、
を実行させるためのプログラムであって、
前記イベントを検出する処理は、前記管轄地域に滞在する利用者の端末から送信された情報提供要求を前記イベントとして検出し、
前記第２の自治体を選択する処理は、前記影響範囲と重複する管轄地域を持つ自治体を、前記支援を要請する第２の自治体として選択し、
前記情報提供要求には施設の案内を要求することが記載され、
前記コンピュータに、
前記施設の案内に関する情報提供を前記支援内容とする前記支援協力要請を生成する処理と、
前記端末から送信された情報提供要求に応じて、前記第１の自治体の管轄地域に存在する施設に関する第１の情報を生成すると共に、前記第２の自治体のサーバ装置により生成された前記第２の自治体の管轄地域に存在する施設に関する第２の情報と、前記生成された第１の情報と、を前記端末に送信する処理と、
をさらに実行させるプログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、サーバ装置、サーバ装置の制御方法及び記憶媒体に関する。

【背景技術】

【0002】

災害発生時等に、自治体間で連携を図る技術が存在する。

【0003】

例えば、特許文献１には、避難所間や自治体などの間での情報共有や情報連携を図り、有効な災害支援情報を提供できる災害情報処理システムを実現する、と記載されている。特許文献１の災害情報処理システムは、避難所に設置される情報端末と、ネットワークと、データベースと、サーバとを備えた構成である。ネットワークは、情報端末から出力される災害情報を配信する。データベースは、ネットワークを介して配信される災害情報を蓄積する。サーバは、データベースに蓄積された災害情報の照合処理を含む情報処理を実行し、安否確認情報、救援状況情報または資産確認情報を含む災害支援情報を生成する。

【先行技術文献】

【特許文献】

【0004】

【文献】特開２０１３－０５８０７１号公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

上述のように、自治体間で連携が行われているが、連携先の自治体を正しく選択しなければ、各自治体は自治体間の連携から利益を得ることが難しい。

【0006】

本発明は、自治体等の連携をより効果的にすることに寄与する、サーバ装置、サーバ装置の制御方法及び記憶媒体を提供することを主たる目的とする。

【課題を解決するための手段】

【0007】

本発明の第１の視点によれば、第１の自治体の管轄地域で発生したイベントを検出する、検出部と、前記発生したイベントの影響範囲を特定する、特定部と、前記特定された影響範囲に基づいて、支援を要請する第２の自治体を選択する、選択部と、前記選択された第２の自治体のサーバ装置に、支援内容を含む支援協力要請を送信する、支援要請部と、を備える、サーバ装置が提供される。

【0008】

本発明の第２の視点によれば、サーバ装置において、第１の自治体の管轄地域で発生したイベントを検出し、前記発生したイベントの影響範囲を特定し、前記特定された影響範囲に基づいて、支援を要請する第２の自治体を選択し、前記選択された第２の自治体のサーバ装置に、支援内容を含む支援協力要請を送信する、サーバ装置の制御方法が提供される。

【0009】

本発明の第３の視点によれば、サーバ装置に搭載されたコンピュータに、第１の自治体の管轄地域で発生したイベントを検出する処理と、前記発生したイベントの影響範囲を特定する処理と、前記特定された影響範囲に基づいて、支援を要請する第２の自治体を選択する処理と、前記選択された第２の自治体のサーバ装置に、支援内容を含む支援協力要請を送信する処理と、を実行させるためのプログラムを記憶する、コンピュータ読取可能な記憶媒体が提供される。

【発明の効果】

【0010】

本発明の各視点によれば、自治体等の連携をより効果的にすることに寄与する、サーバ装置、サーバ装置の制御方法及び記憶媒体が提供される。なお、本発明の効果は上記に限定されない。本発明により、当該効果の代わりに、又は当該効果と共に、他の効果が奏されてもよい。

【図面の簡単な説明】

【0011】

【図1】図１は、一実施形態の概要を説明するための図である。

【図2】図２は、一実施形態の概略動作を説明するためのフローチャートである。

【図3】図３は、第１の実施形態に係る情報処理システムの概略構成の一例を示す図である。

【図4】図４は、第１の実施形態に係る情報処理システムの動作を説明するための図である。

【図5】図５は、第１の実施形態に係るサーバ装置の処理構成の一例を示す図である。

【図6】図６は、第１の実施形態に係る影響範囲特定部の動作を説明するための図である。

【図7】図７は、第１の実施形態に係る提携先管理データベースの一例を示す図である。

【図8】図８は、第１の実施形態に係る要望条件管理データベースの一例を示す図である。

【図9】図９は、第１の実施形態に係る自治体の職員等が使用する端末の表示の一例を示す図である。

【図10】図１０は、第１の実施形態に係るサーバ装置の動作の一例を示すフローチャートである。

【図11】図１１は、第２の実施形態に係る情報処理システムの動作を説明するための図である。

【図12】図１２は、第２の実施形態に係る端末の処理構成の一例を示す図である。

【図13】図１３は、第２の実施形態に係る端末の表示の一例を示す図である。

【図14】図１４は、第２の実施形態に係る端末の表示の一例を示す図である。

【図15】図１５は、第２の実施形態に係るサーバ装置の処理構成の一例を示す図である。

【図16】図１６は、第２の実施形態に係る要望条件管理データベースの一例を示す図である。

【図17】図１７は、本願開示に係るサーバ装置のハードウェア構成の一例を示す図である。

【図18】図１８は、本願開示の変形例に係る端末の表示の一例を示す図である。

【図19】図１９は、本願開示の変形例に係る自治体の職員等が使用する端末の表示の一例を示す図である。

【図20】図２０は、本願開示の変形例に係る要望条件管理データベースの一例を示す図である。

【図21】図２１は、本願開示の変形例に係る情報処理システムの動作を説明するための図である。

【図22】図２２は、本願開示の変形例に係る要望条件管理データベースの一例を示す図である。

【発明を実施するための形態】

【0012】

はじめに、一実施形態の概要について説明する。なお、この概要に付記した図面参照符号は、理解を助けるための一例として各要素に便宜上付記したものであり、この概要の記載はなんらの限定を意図するものではない。また、特段の釈明がない場合には、各図面に記載されたブロックはハードウェア単位の構成ではなく、機能単位の構成を表す。各図におけるブロック間の接続線は、双方向及び単方向の双方を含む。一方向矢印については、主たる信号（データ）の流れを模式的に示すものであり、双方向性を排除するものではない。なお、本明細書及び図面において、同様に説明されることが可能な要素については、同一の符号を付することにより重複説明が省略され得る。

【0013】

一実施形態に係るサーバ装置１００は、検出部１０１と、特定部１０２と、選択部１０３と、支援要請部１０４と、を備える（図１参照）。検出部１０１は、第１の自治体の管轄地域で発生したイベントを検出する（図２のステップＳ１）。特定部１０２は、発生したイベントの影響範囲を特定する（ステップＳ２）。選択部１０３は、特定された影響範囲に基づいて、支援を要請する第２の自治体を選択する（ステップＳ３）。支援要請部１０４は、選択された第２の自治体のサーバ装置に、支援内容を含む支援協力要請を送信する（ステップＳ４）。

【0014】

サーバ装置１００は、自装置の管轄地域（サーバ装置１００を管理、運営する自治体の管轄地域）にイベントが発生すると、その影響範囲を特定する。サーバ装置１００は、特定した影響範囲に基づいて、支援を要請する自治体を選択する。例えば、管轄地域で災害が発生した場合には、サーバ装置１００は、隣接する自治体には他の自治体を支援する余裕がないと判断し、災害発生場所から離れた自治体に支援を要請する。また、管轄地域で観光地の施設に関する情報提供が求められた場合、サーバ装置１００は、隣接する自治体は自身の管轄地域の施設に関するよりよい情報を所持していると判断し、情報提供が求められた場所に隣接する自治体に支援（情報提供）を要請する。このように、サーバ装置１００は、発生イベントの影響範囲をはじめとした種々の情報、条件に基づいて連携する自治体を選択することで、各自治体は、より確実な支援や有益な情報を得ることができる。サーバ装置１００は、自治体等の連携をより効果的にすることが可能である。

【0015】

以下に具体的な実施形態について、図面を参照してさらに詳しく説明する。

【0016】

［第１の実施形態］
第１の実施形態について、図面を用いてより詳細に説明する。

【0017】

［システム構成］
図３は、第１の実施形態に係る情報処理システムの概略構成の一例を示す図である。図３に示すように、情報処理システムは、複数の自治体Ａ～Ｄが含まれる。情報処理システムに含まれる各自治体は互いに提携をしている。例えば、図３の例では、自治体Ａは、自治体Ｂ～Ｄと提携している。

【0018】

各自治体Ａ～Ｄは、サーバ装置１０－１～１０－４を備える。以降の説明において、サーバ装置１０－１～１０－４を区別する特段の理由がない場合には、単に「サーバ装置１０」と表記する。

【0019】

サーバ装置１０は、各自治体の建物（例えば、市役所）内に設置されていてもよいし、クラウド（ネットワーク）上に設置されていてもよい。

【0020】

サーバ装置１０は、上記自治体間の連携（都市間の連携）を実現するサーバである。例えば、サーバ装置１０は、地域（各自治体が管理する地域）の防災や観光に関する自治体間の連携を実現する。

【0021】

図３に示す各サーバ装置１０はネットワークを介して相互に接続されている。具体的には、各サーバ装置１０は、有線又は無線の通信手段により接続され、相互に通信が可能となるように構成されている。

【0022】

図３に示す構成は例示であって、本願開示の情報処理システムの構成等を限定する趣旨ではない。例えば、各自治体には２台以上のサーバ装置１０が含まれていてもよい。また、情報処理システムに含まれる自治体の数を「４」に限定する趣旨ではないことは勿論である。

【0023】

［システムの動作概略］
続いて、第１の実施形態に係る情報処理システムの動作概略について説明する。第１の実施形態では、防災分野において実現される自治体間の連携（都市間の連携）について説明する。

【0024】

ここでは、図４に示すように、自治体Ａと自治体Ｂの境界付近で災害（例えば、地震、洪水等の災害）が発生した場合を想定し説明を行う。

【0025】

各自治体のサーバ装置１０は、管轄する地域でイベント（例えば、災害）が発生すると、当該イベントの発生を検出する。図４の例では、自治体Ａの管轄地域で災害が発生しているので、サーバ装置１０－１が当該災害の発生を検出する。

【0026】

例えば、サーバ装置１０は、外部サーバからの通知、地域住民からの連絡、ＳＮＳ（Social Networking Service）からの情報、河川等に設置されたセンサ等の情報に基づき災害の発生を検出する。

【0027】

その後、サーバ装置１０は、検出したイベントの情報（以下、発生イベント情報と表記する）を生成する。具体的には、サーバ装置１０は、発生したイベントの種類、イベントの発生場所、イベントの発生日時、イベントの影響範囲等の情報を含む「発生イベント情報」を生成する。

【0028】

イベントの影響範囲に関し、例えば、地震の発生が検出された場合、サーバ装置１０は、地震の規模を示す情報（マグニチュード、震度）から被害が予想される地域を「影響範囲」として扱う。あるいは、洪水の発生が検出された場合、サーバ装置１０は、当該洪水発生地域の地形等から予想される浸水地域を「影響範囲」として扱う。

【0029】

サーバ装置１０は、生成した発生イベント情報（イベントの種類、発生場所、発生日時、影響範囲等）に基づき、他の自治体に対する支援要請を行うか否か決定する。具体的には、災害の発生により住民が避難所に避難をするが、避難所に蓄えられた物品が不足すると想定される場合に、サーバ装置１０は、他の自治体に支援を要請する。

【0030】

例えば、地震が発生したとしても、震源地が山間部等であれば、当該地震の発生により避難が必要な住民の数は少ないので、サーバ装置１０は、他の自治体への支援要請は不要と判定する。

【0031】

対して、同じ規模の地震が都市部で発生した場合、当該地震の発生により避難が必要な住民の数が多いので、サーバ装置１０は、他の自治体への支援要請が必要と判定する。

【0032】

他の自治体に支援要請が必要と判定されると、サーバ装置１０は、発生イベント情報と他の自治体の情報を使って支援要請を行う自治体を選択する。具体的には、サーバ装置１０は、発生イベント情報の影響範囲に含まれる自治体は除外し、支援要請を行う自治体を選択する。

【0033】

例えば、図４の例では、災害が自治体Ａと自治体Ｂの境界で発生しているため、自治体Ｂの管轄地域も当該災害の影響範囲に含まれる。この場合、自治体Ａのサーバ装置１０－１は、自治体Ｂには他の自治体を支援する余力はないと判断し、当該自治体Ｂを支援要請の対象から除外する。

【0034】

サーバ装置１０は、自治体Ｂ以外の自治体Ｃ又は自治体Ｄを支援要請の対象に選択する。例えば、サーバ装置１０は、災害の発生場所からより離れている自治体Ｄを支援要請の対象とする。

【0035】

支援を要請する自治体が選択されると、サーバ装置１０は、具体的な支援の内容を含む「支援協力要請」を生成し、当該生成した支援協力要請を支援要請先の自治体が管理するサーバ装置１０に送信する。図４の例では、自治体Ｄのサーバ装置１０－４に支援協力要請が送信される。

【0036】

ここで、支援協力要請は、自治体間で予め定められた都市間連携の要望条件に基づき生成される。例えば、要望条件には、イベントの種類（地震発生、洪水発生）や支援の具体的内容（例えば、支援物資の提供）等が記載されている。

【0037】

例えば、「イベントの種類：地震発生」、「支援内容：生活必需品の提供」といった内容が要望条件に記載されている。

【0038】

サーバ装置１０は、選択した自治体のサーバ装置１０に支援協力要請を送信することで、発生したイベントに対処するための支援を他の自治体に要望する。

【0039】

続いて、第１の実施形態に係る情報処理システムに含まれる各装置の詳細について説明する。

【0040】

［サーバ装置］
図５は、第１の実施形態に係るサーバ装置１０の処理構成（処理モジュール）の一例を示す図である。図５を参照すると、サーバ装置１０は、通信制御部２０１と、イベント検出部２０２と、影響範囲特定部２０３と、支援要否判定部２０４と、支援要請先選択部２０５と、支援要請部２０６と、支援要請処理部２０７と、記憶部２０８と、を備える。

【0041】

通信制御部２０１は、他の装置との間の通信を制御する手段である。例えば、通信制御部２０１は、他のサーバ装置１０からデータ（パケット）を受信する。また、通信制御部２０１は、他のサーバ装置１０に向けてデータを送信する。通信制御部２０１は、他の装置から受信したデータを他の処理モジュールに引き渡す。通信制御部２０１は、他の処理モジュールから取得したデータを他の装置に向けて送信する。このように、他の処理モジュールは、通信制御部２０１を介して他の装置とデータの送受信を行う。通信制御部２０１は、他の装置からデータを受信する受信部としての機能と、他の装置に向けてデータを送信する送信部としての機能と、を備える。

【0042】

イベント検出部２０２は、自治体（第１の自治体）の管轄地域で発生したイベントを検出する手段である。例えば、イベント検出部２０２は、気象庁や国土交通省等が管理する外部サーバから情報を取得することで、地震や洪水の発生を検出する。例えば、イベント検出部２０２は、震源地、マグニチュード、各地の震度等の情報を外部サーバから取得することで、地震発生のイベントを検出する。

【0043】

あるいは、イベント検出部２０２は、インターネット上に投稿されているＳＮＳデータを解析することで、イベントの発生を検出してもよい。例えば、イベント検出部２０２は、機械学習により得られた学習モデルにインターネットに投稿されたメッセージを入力することで、イベント発生を検出してもよい。

【0044】

あるいは、イベント検出部２０２は、自治体の職員等がサーバ装置１０に入力する情報に基づいてイベントの発生を検出してもよい。例えば、自治体の職員等が、テレビ放送や地元住民からの電話連絡等から得た情報（地震の発生、洪水の発生等）をサーバ装置１０に入力することで、イベント検出部２０２は、イベントの発生を検出してもよい。

【0045】

イベント検出部２０２は、検出したイベントの情報を影響範囲特定部２０３に引き渡す。具体的には、イベント検出部２０２は、検出したイベントの種類（例えば、地震発生、洪水発生）、イベントの発生場所（例えば、震源地、堤防の決壊地点）、イベント発生日時等の情報を影響範囲特定部２０３に引き渡す。

【0046】

その際、イベント検出部２０２は、必要に応じて、発生したイベントに特有な情報も併せて影響範囲特定部２０３に引き渡す。例えば、イベント検出部２０２は、発生した地震の規模を示す情報（震度、マグニチュード）等の情報を影響範囲特定部２０３に引き渡す。

【0047】

影響範囲特定部２０３は、発生したイベントの影響範囲を特定する手段である。例えば、影響範囲特定部２０３は、発生したイベントの影響範囲に関する情報をイベント検出部２０２から取得し、当該取得した情報に基づいてイベントの影響範囲を特定する。例えば、「地震」が発生した場合、影響範囲特定部２０３は、イベント検出部２０２から取得した震源地とマグニチュードから、地域住民の避難が必要な地域（領域）を計算する。

【0048】

例えば、影響範囲特定部２０３は、マグニチュードと、震源地を中心として避難が必要な領域の半径と、の関係を記憶するテーブル情報を参照して、上記地震による影響範囲を特定する。例えば、上述の例のように、自治体Ａと自治体Ｂの境界で地震が発生した場合には、図６に示す灰色の領域が影響範囲として特定される。

【0049】

また、イベントとして「洪水」が発生した場合、影響範囲特定部２０３は、堤防が決壊した地点と当該地点の周囲の地形情報を用いて、浸水が予想される地域を影響範囲として特定する。

【0050】

影響範囲特定部２０３は、特定した影響範囲、イベント検出部２０２から取得した情報を用いて、発生イベント情報を生成する。影響範囲特定部２０３は、発生したイベントの種類、イベントの発生場所、イベントの発生日時、イベントの影響範囲等の情報を含む「発生イベント情報」を生成する。影響範囲特定部２０３は、生成したイベント情報を支援要否判定部２０４に引き渡す。

【0051】

支援要否判定部２０４は、他の自治体に対して支援を要請するか否かを判定する手段である。支援要否判定部２０４は、影響範囲特定部２０３から取得した発生イベント情報に基づいて支援要請の要否を判定する。

【0052】

支援要否判定部２０４は、発生したイベントが「地震」であれば、自組織が管理する管轄地域であってイベントの影響範囲に住んでいる住民の数を算出する。具体的には、支援要否判定部２０４は、住民の住所等を記憶しているデータベースを参照し、上記地域（管轄地域且つ影響範囲内の地域）の住民数を計算する。なお、以降の説明において、自組織が管轄する地域のうち影響範囲に相当する領域を「管轄内影響範囲」と表記する。

【0053】

また、支援要否判定部２０４は、管轄内影響範囲に開設される避難所の備品等に関する情報（予め職員等がサーバ装置１０に入力済の情報）を参照し、避難所に住民が避難するのに十分な備品が蓄えられているか否か判定する。十分な備品が蓄えられている場合、支援要否判定部２０４は、他の自治体への支援要請は不要と判定する。十分な備品が蓄えられていない場合、支援要否判定部２０４は、他の自治体への支援要請が必要と判定する。

【0054】

例えば、山間部で地震が発生し、管轄内影響範囲にほとんど住民が住んでおらず、避難所の備品が十分な場合、他の自治体への支援要請は不要と判定される。対して、都市部で地震が発生し、管轄内影響範囲に多くの住民が住んでおり、避難所の備品が不足すると推定される場合、他の自治体への支援要請は必要と判定される。

【0055】

支援要否判定部２０４は、他の自治体への支援要請が必要と判定された場合、発生イベント情報を支援要請先選択部２０５に引き渡す。

【0056】

支援要請先選択部２０５は、支援要請を行う自治体を選択する手段である。支援要請先選択部２０５は、影響範囲特定部２０３により特定された影響範囲に基づいて、支援を要請する第２の自治体を選択する。より具体的には、支援要請先選択部２０５は、発生イベント情報に含まれる影響範囲に基づいて連携する自治体を選択する。

【0057】

支援要請先選択部２０５は、提携している自治体に関する情報を記憶する提携先管理データベースを参照し、支援要請の候補となる自治体の情報を取得する（図７参照）。図７は、自治体Ａのサーバ装置１０－１に構築された提携先管理データベースの一例を示す図である。

【0058】

図７に示すように、提携先管理データベースは、自治体名、市庁等所在地、各自治体が管轄している地域の範囲、各自治体に住んでいる住民数等を対応付けて記憶する。なお、図７に示す提携先管理データベースは例示であって、記憶する項目等を限定する趣旨ではない。

【0059】

支援要請先選択部２０５は、提携先管理データベースに記憶された自治体のうち、発生イベント情報の影響範囲と各自治体の管轄地域が重複しない自治体を抽出する。例えば、上記図４の例では、自治体Ｂの管轄地域と影響範囲が重複するので、自治体Ｃ及び自治体Ｄが抽出される。

【0060】

支援要請先選択部２０５は、影響範囲と管轄地域が重複しない自治体のなかから支援要請を行う自治体を選択する。上記の例では、支援要請先選択部２０５は、自治体Ｃ又は自治体Ｄを支援要請先候補の自治体として選択する。

【0061】

支援要請先選択部２０５は、予め定めた基準等に従い、支援要請先候補のなかから支援を要請する自治体を選択する。例えば、支援要請先選択部２０５は、イベントが発生した場所から最も離れている自治体を支援要請先として選択してもよい。あるいは、住民数が多い自治体は備品等の蓄えが十分と考えられるので、支援要請先選択部２０５は、最も住民数の多い自治体を支援要請先として選択してもよい。あるいは、各自治体の職員が円滑に連携できるように、支援要請先選択部２０５は、市庁等の所在地が最も近い自治体を支援要請先に選択してもよい。

【0062】

このように、支援要請先選択部２０５は、各自治体の属性情報（管轄地域、住民数、市庁等の所在地等）に基づいて支援要請先の自治体を選択してもよい。即ち、支援要請先選択部２０５は、影響範囲と重複しない管轄地域を持つ複数の自治体それぞれの属性情報に基づいて、支援を要請する自治体を選択してもよい。

【0063】

支援要請先選択部２０５は、選択した自治体の情報（例えば、自治体名）と発生イベント情報を支援要請部２０６に引き渡す。

【0064】

支援要請部２０６は、他の自治体に支援（協力）を要請する手段である。支援要請部２０６は、選択された自治体のサーバ装置１０に、支援内容を含む支援協力要請を送信する。より具体的には、支援要請部２０６は、発生イベント情報に基づいて、具体的な支援の内容が記載された「支援協力要請」を生成する。

【0065】

支援協力要請は、自治体間で予め定められた都市間連携の要望条件に基づき生成される。要望条件は、イベントの種類に応じた具体的な支援内容を定める。要望条件は、要望条件管理データベースにより管理される（図８参照）。なお、図８に示す要望条件管理データベースは例示であって、記憶する項目等を限定する趣旨ではない。

【0066】

支援要請部２０６は、要望条件管理データベースを参照し、発生イベント情報に含まれるイベントの種類に合致する支援の内容を取得する。支援要請部２０６は、取得した支援内容を含む支援協力要請を生成する。

【0067】

その際、支援要請部２０６は、支援内容と当該支援内容に付随する付随情報を含む支援協力要請を生成してもよい。例えば、「生活必需品の提供」といった支援内容であれば、当該生活必需品の提供先の住所（例えば、支援要請元の自治体の市役所や避難所の住所）が支援内容に付随する情報として例示される。

【0068】

支援要請部２０６は、生成した支援協力要請を支援要請先選択部２０５が選択した自治体のサーバ装置１０に送信する。

【0069】

支援要請処理部２０７は、他の自治体のサーバ装置１０から受信する「支援協力要請」を処理する手段である。例えば、支援要請処理部２０７は、支援協力要請に含まれる支援内容及びその付随情報を自治体職員等に通知する。

【0070】

例えば、支援要請処理部２０７は、自治体職員が使用する端末に図９に示すような表示を行う。あるいは、支援要請処理部２０７は、図９に示す内容のメールを自治体職員が使用する端末に送信する。

【0071】

なお、支援要請処理部２０７は、図９に示す画面において詳細情報を表示するためのボタン（インターフェイス）を設けてもよい。例えば、自治体職員等が「詳細表示」ボタンを押下すると、支援要請処理部２０７は、詳細表示画面に遷移し、当該詳細表示画面において影響範囲が重畳表示された地図を表示してもよい。あるいは、支援要請処理部２０７は、詳細表示画面において、提供先を強調して表示したり、災害規模の詳細や支援内容の詳細を表示したりしてもよい。このように、支援要請処理部２０７は、詳細表示画面において、他の自治体から要請された支援の内容を自治体職員が確認可能としてもよい。

【0072】

記憶部２０８は、サーバ装置１０の動作に必要な情報を記憶する。

【0073】

［動作の説明］
続いて、第１の実施形態に係るサーバ装置１０の動作について説明する。

【0074】

図１０は、第１の実施形態に係るサーバ装置１０の動作の一例を示すシーケンス図である。図１０を参照し、イベントの発生を検出した際のサーバ装置１０の動作を説明する。

【0075】

サーバ装置１０は、自組織の管轄地域で発生するイベントを検出する（ステップＳ１０１）。

【0076】

サーバ装置１０は、発生したイベントの影響範囲を特定し、発生イベント情報を生成する（ステップＳ１０２）。

【0077】

サーバ装置１０は、他の自治体に支援要請を行うか否か判定する（ステップＳ１０３）。例えば、サーバ装置１０は、管轄領域内の影響範囲に住む住民の数に基づいて、他の自治体へ支援を要請するか否か判定する。

【0078】

支援要請が不要な場合（ステップＳ１０３、Ｎｏ分岐）、サーバ装置１０は、発生したイベントに関する処理を終了する。

【0079】

支援要請が必要な場合（ステップＳ１０３、Ｙｅｓ分岐）、サーバ装置１０は、支援要請を行う自治体を選択する（支援要請先を選択；ステップＳ１０４）。例えば、管轄地域で発生した災害がイベントとして検出された場合、サーバ装置１０は、影響範囲と重複しない管轄地域を持つ自治体を、支援を要請する自治体として選択する。

【0080】

サーバ装置１０は、都市間連携の要望条件に基づき、支援要請先の自治体に送信する「支援協力要請」を生成する（ステップＳ１０５）。例えば、サーバ装置１０は、避難所で用いられる物品（例えば、生活必需品等の物品）の提供を支援内容として含む支援協力要請を生成する。

【0081】

サーバ装置１０は、生成した支援協力要請を選択された自治体のサーバ装置１０に送信する（支援協力要請を送信；ステップＳ１０６）。

【0082】

以上のように、第１の実施形態に係るサーバ装置１０は、管轄地域内でイベントが発生すると、その影響範囲を特定する。サーバ装置１０は、特定した影響範囲に基づき、支援に適する自治体を選択する。例えば、管轄地域で災害が発生した場合、隣接する自治体には他の自治体を支援する余裕がないことを考慮し、サーバ装置１０は、災害発生場所から離れた自治体に支援を要請する。このように、サーバ装置１０は、発生イベントの影響範囲をはじめとした種々の情報、条件に基づいて連携する自治体を選択することで、都市間連携の価値を高める。

【0083】

［第２の実施形態］
続いて、第２の実施形態について図面を参照して詳細に説明する。

【0084】

第１の実施形態では、自治体の管轄地域で自然災害がイベントとして発生する場合について説明した。第２の実施形態では、自治体の管轄地域を移動する利用者（観光客）が、情報提供に関するイベントを起こす場合について説明する。

【0085】

なお、第２の実施形態に係る情報処理システムの構成は第１の実施形態と同一とすることができるので図３に相当する説明を省略する。

【0086】

以下、第１の実施形態と第２の実施形態の相違点を中心に説明する。

【0087】

図１１に示すように、利用者は、端末２０を所持する。利用者は、各自治体の管轄地域を移動する際、種々の情報提供を自治体に要求できる。例えば、利用者は、端末２０を操作して、近くの観光施設に関する情報提供や宿泊施設に関する情報提供を自治体のサーバ装置１０に要求する。

【0088】

［端末］
図１２は、第２の実施形態に係る端末２０の処理構成（処理モジュール）の一例を示す図である。図１２を参照すると、端末２０は、通信制御部３０１と、位置情報生成部３０２と、情報提供要求部３０３と、情報提供部３０４と、記憶部３０５と、を備える。

【0089】

通信制御部３０１は、他の装置との間の通信を制御する手段である。例えば、通信制御部３０１は、サーバ装置１０からデータ（パケット）を受信する。また、通信制御部３０１は、サーバ装置１０に向けてデータを送信する。通信制御部３０１は、他の装置から受信したデータを他の処理モジュールに引き渡す。通信制御部３０１は、他の処理モジュールから取得したデータを他の装置に向けて送信する。このように、他の処理モジュールは、通信制御部３０１を介して他の装置とデータの送受信を行う。通信制御部３０１は、他の装置からデータを受信する受信部としての機能と、他の装置に向けてデータを送信する送信部としての機能と、を備える。

【0090】

位置情報生成部３０２は、自装置の位置情報（現在位置）を生成する手段である。位置情報生成部３０２は、ＧＰＳ（Global Positioning System）衛星からのＧＰＳ信号を受信して測位を実行し、自装置の緯度及び経度を含む位置情報を生成する。あるいは、位置情報生成部３０２は、無線アクセスポイントと通信し、当該無線アクセスポイントの位置を自装置の位置として扱っても良い。あるいは、位置情報生成部３０２は、無線アクセスポイントから受信する電波の強度に基づき位置情報を生成してもよい。

【0091】

情報提供要求部３０３は、自治体のサーバ装置１０に情報提供を要求する手段である。情報提供要求部３０３は、利用者の操作に応じて、自治体に要求する情報の種類等を取得するためのＧＵＩ（Graphical User Interface）を表示する。

【0092】

例えば、情報提供要求部３０３は、図１３に示すようなＧＵＩを表示し、自治体に要求する情報を取得する。利用者が要求する情報を取得すると、情報提供要求部３０３は、自装置の現在位置（緯度、経度）及び利用者が提供を希望する情報の種類を含む「情報提供要求」を、現在地を管轄する自治体のサーバ装置１０に送信する。

【0093】

その際、情報提供要求部３０３は、各自治体の管轄地域の範囲（座標情報）とサーバ装置１０のアドレス（情報提供要求の送信先）を対応付けて記憶するテーブル情報を参照し、情報提供要求の送信先を取得する。

【0094】

情報提供部３０４は、自治体のサーバ装置１０から取得する情報（情報提供要求に対する応答）を利用者に提供する手段である。例えば、情報提供部３０４は、サーバ装置１０から受信する情報に基づいて、図１４に示すような表示を行う。

【0095】

記憶部３０５は、端末２０の動作に必要な情報を記憶する。

【0096】

［サーバ装置］
図１５は、第２の実施形態に係るサーバ装置１０の処理構成（処理モジュール）の一例を示す図である。図１５を参照すると、第１の実施形態に係るサーバ装置１０の構成に情報提供処理部２０９が追加されている。

【0097】

上述のように、端末２０は、自装置（利用者）の現在位置を管轄する自治体のサーバ装置１０に情報提供の要求を行う。図１１の例では、利用者は、自治体Ａの管轄地域に滞在しているので、端末２０は、サーバ装置１０－１に「情報提供要求」を送信する。

【0098】

サーバ装置１０－１のイベント検出部２０２は「情報提供要求の受信」というイベントを検出する。即ち、イベント検出部２０２は、管轄地域に滞在する利用者の端末２０から送信された「情報提供要求」をイベントとして検出する。

【0099】

端末２０が送信する情報提供要求には、施設（例えば、観光施設、宿泊施設）の案内を要求することが記載されている。さらに、情報提供要求には、端末２０の現在位置が含まれる。

【0100】

情報提供要求の受信というイベントを検出すると、影響範囲特定部２０３は、検出したイベントの影響範囲を特定する。例えば、観光施設の案内が要求された場合、影響範囲特定部２０３は、利用者の現在位置を中心とした所定範囲を影響範囲として特定する。

【0101】

例えば、影響範囲特定部２０３は、利用者がバス、電車等の交通手段を利用して所定時間内（例えば、３０分、１時間）で移動可能な範囲を影響範囲として算出（特定）する。

【0102】

影響範囲を算出すると、影響範囲特定部２０３は、発生イベント情報を生成する。具体的には、影響範囲特定部２０３は、「イベントの種類：観光施設案内」、「イベント発生場所：利用者の現在位置」等の情報を含む発生イベント情報を生成する。

【0103】

支援要否判定部２０４は、発生イベント情報に基づいて他の自治体に支援要請を行うか否か判定する。例えば、支援要否判定部２０４は、算出した影響範囲が自組織の管轄地域内であれば、他の自治体への支援要請は行わない。対して、算出した影響範囲が他の自治体の管轄地域に跨がる場合には、支援要否判定部２０４は、他の自治体に支援要請を行う。

【0104】

支援要否判定部２０４は、他の自治体への支援要請を行わない場合には、利用者の端末２０から取得した情報提供要求を情報提供処理部２０９に引き渡す。

【0105】

支援要請を行う場合、支援要請先選択部２０５は、支援要請を行う自治体を選択する。具体的には、支援要請先選択部２０５は、管轄地域が影響範囲と重複している上記他の自治体（影響範囲と重複する管轄地域を持つ自治体）を支援要請先として選択する。図１１の例では、支援要請先選択部２０５は、利用者の現在位置に近接する自治体Ｂを支援要請先に選択する。

【0106】

支援要請部２０６は、都市間連携の要望条件に基づき、支援要請先の自治体に送信する「支援協力要請」を生成する。例えば、支援要請部２０６は、施設（観光施設、宿泊施設）の案内に関する情報提供を支援内容とする支援協力要請を生成する。

【0107】

より具体的には、支援要請部２０６は、図１６に示すような要望条件管理データベースを参照し、発生イベント情報に含まれるイベントの種類に合致する支援内容を取得する。支援要請部２０６は、取得した支援内容を含む支援協力要請を生成する。

【0108】

その際、支援要請部２０６は、支援内容と当該支援内容に付随する付随情報を含む支援協力要請を生成する。例えば、「観光施設に関する情報提供」といった支援内容であれば、利用者の現在位置が支援内容に付随する情報として例示される。

【0109】

支援要請部２０６は、生成した支援協力要請を支援要請先選択部２０５が選択した自治体のサーバ装置１０に送信する。

【0110】

支援要請部２０６は、他の自治体のサーバ装置１０から支援協力要請に対する応答を受信する。支援要請部２０６は、利用者の端末２０から取得した情報提供要求と、他の自治体のサーバ装置１０から取得した支援協力要請に対する応答と、を情報提供処理部２０９に引き渡す。

【0111】

情報提供処理部２０９は、利用者の端末２０から取得した情報提供要求を処理する手段である。情報提供処理部２０９は、利用者の要求に添った情報を生成する。例えば、利用者が観光施設案内を要求している場合、情報提供処理部２０９は、自組織の管轄内影響範囲に含まれる観光施設（観光スポット）の情報を生成する。

【0112】

例えば、情報提供処理部２０９は、各観光施設の名称、所在地（緯度、経度）等を対応付けて記憶するデータベースを参照し、管轄内影響範囲に存在する観光施設を抽出する。

【0113】

支援要否判定部２０４から情報提供要求を取得した場合（他の自治体に支援が要請されなかった場合）、情報提供処理部２０９は、上記抽出した観光施設に関する情報を端末２０に送信する。即ち、情報提供処理部２０９は、観光施設の名称、所在地等を含む情報を端末２０から受信した情報提供要求に対する応答として端末２０に送信する。

【0114】

支援要請部２０６から情報提供要求を取得した場合（他の自治体に支援が要請された場合）、情報提供処理部２０９は、上記抽出した観光施設に関する情報と他の自治体から取得した応答（観光施設に関する情報）を統合する。情報提供処理部２０９は、自装置で生成した観光施設に関する情報と、他のサーバ装置１０が生成した観光施設に関する情報と、を統合（マージ）して、利用者の現在位置を中心とした所定範囲（影響範囲）に存在する観光施設の情報を生成する。

【0115】

情報提供処理部２０９は、生成した情報を端末２０に送信する。即ち、情報提供処理部２０９は、影響範囲に含まれる観光施設の名称、所在地等を含む情報を端末２０から受信した情報提供要求に対する応答として端末２０に送信する。

【0116】

その際、情報提供処理部２０９は、端末２０が図１４に示すような表示が可能なように、利用者の現在位置と観光施設の場所が反映された地図画像を端末２０に送信してもよい。なお、図１４において、川（灰色の領域）を境に自治体の管轄地域が異なる。例えば、川の右側に表示された美術館は自治体Ｂから提供された情報であり、川の左側に表示された博物館は自治体Ａから提供された情報である。

【0117】

このように、情報提供処理部２０９は、端末２０から送信された情報提供要求に応じて、自組織（第１の自治体）の管轄地域に存在する施設に関する第１の情報を生成する。さらに、情報提供処理部２０９は、他の自治体（第２の自治体）のサーバ装置１０により生成された第２の自治体の管轄地域に存在する施設に関する第２の情報と、上記生成された第１の情報と、を端末２０に送信する。

【0118】

支援要請処理部２０７は、他の自治体のサーバ装置１０から「支援協力要請」を受信し、当該受信した支援協力要請を処理する。例えば、支援内容が「観光施設に関する情報提供」であれば、支援要請処理部２０７は、利用者の現在地に近い観光施設（利用者から所定範囲に存在する観光施設）を選択し、当該選択した観光施設に関する情報を支援要請元のサーバ装置１０に送信する。

【0119】

以上のように、第２の実施形態に係るサーバ装置１０は、自身の管轄地域に関する情報だけでなく、隣接する他の自治体からも情報を収集し、利用者に有益な情報を提供する。即ち、サーバ装置１０は、情報提供を依頼する利用者（観光客）の位置を把握し、当該利用者の位置が他の自治体が管轄する地域に近い場合には、当該自治体に対して観光客に提供する情報の提供を依頼する。このように、サーバ装置１０は、管轄地域で観光地の施設に関する情報提供が求められた場合、隣接する自治体が自身の管轄地域の施設に関するよりよい情報を所持していると判断し、他の自治体に支援（情報提供）を要請する。その結果、利用者には、１つの自治体が情報提供するよりも有益な情報が提供され、利用者の利便性が向上する。換言すれば、都市間連携により、複数の自治体が有する情報が統合されることで、都市間連携の価値や意義が増大する。

【0120】

続いて、情報処理システムを構成する各装置のハードウェアについて説明する。図１７は、サーバ装置１０のハードウェア構成の一例を示す図である。

【0121】

サーバ装置１０は、情報処理装置（所謂、コンピュータ）により構成可能であり、図１７に例示する構成を備える。例えば、サーバ装置１０は、プロセッサ３１１、メモリ３１２、入出力インターフェイス３１３及び通信インターフェイス３１４等を備える。上記プロセッサ３１１等の構成要素は内部バス等により接続され、相互に通信可能に構成されている。

【0122】

但し、図１７に示す構成は、サーバ装置１０のハードウェア構成を限定する趣旨ではない。サーバ装置１０は、図示しないハードウェアを含んでもよいし、必要に応じて入出力インターフェイス３１３を備えていなくともよい。また、サーバ装置１０に含まれるプロセッサ３１１等の数も図１７の例示に限定する趣旨ではなく、例えば、複数のプロセッサ３１１がサーバ装置１０に含まれていてもよい。

【0123】

プロセッサ３１１は、例えば、ＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro Processing Unit）、ＤＳＰ（Digital Signal Processor）等のプログラマブルなデバイスである。あるいは、プロセッサ３１１は、ＦＰＧＡ（Field Programmable Gate Array）、ＡＳＩＣ（Application Specific Integrated Circuit）等のデバイスであってもよい。プロセッサ３１１は、オペレーティングシステム（ＯＳ；Operating System）を含む各種プログラムを実行する。

【0124】

メモリ３１２は、ＲＡＭ（Random Access Memory）、ＲＯＭ（Read Only Memory）、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）等である。メモリ３１２は、ＯＳプログラム、アプリケーションプログラム、各種データを格納する。

【0125】

入出力インターフェイス３１３は、図示しない表示装置や入力装置のインターフェイスである。表示装置は、例えば、液晶ディスプレイ等である。入力装置は、例えば、キーボードやマウス等のユーザ操作を受け付ける装置である。

【0126】

通信インターフェイス３１４は、他の装置と通信を行う回路、モジュール等である。例えば、通信インターフェイス３１４は、ＮＩＣ（Network Interface Card）等を備える。

【0127】

サーバ装置１０の機能は、各種処理モジュールにより実現される。当該処理モジュールは、例えば、メモリ３１２に格納されたプログラムをプロセッサ３１１が実行することで実現される。また、当該プログラムは、コンピュータが読み取り可能な記憶媒体に記録することができる。記憶媒体は、半導体メモリ、ハードディスク、磁気記録媒体、光記録媒体等の非トランジェント（non-transitory）なものとすることができる。即ち、本発明は、コンピュータプログラム製品として具現することも可能である。また、上記プログラムは、ネットワークを介してダウンロードするか、あるいは、プログラムを記憶した記憶媒体を用いて、更新することができる。さらに、上記処理モジュールは、半導体チップにより実現されてもよい。

【0128】

なお、端末２０等もサーバ装置１０と同様に情報処理装置により構成可能であり、その基本的なハードウェア構成はサーバ装置１０と相違する点はないので説明を省略する。

【0129】

情報処理装置であるサーバ装置１０は、コンピュータを搭載し、当該コンピュータにプログラムを実行させることでサーバ装置１０の機能が実現できる。また、サーバ装置１０は、当該プログラムによりサーバ装置１０の制御方法を実行する。

【0130】

［変形例］
なお、上記実施形態にて説明した情報処理システムの構成、動作等は例示であって、システムの構成等を限定する趣旨ではない。

【0131】

上記実施形態で説明した発生イベントは例示であって、他のイベントの発生を契機に自治体間の連携が行われてもよいことは勿論である。例えば、交通事故や道路工事等の情報共有を目的として自治体間の連携が行われてもよい。例えば、車両を運転している利用者の端末又は車両は、自治体のサーバ装置１０に対し、交通情報に関する情報提供要求を送信する。当該情報提供要求には、現在地、目的地等の情報が含まれる。サーバ装置１０は、目的地が他の自治外の管轄地域であれば、当該他の自治体のサーバ装置に支援要請を行う。他の自治体のサーバ装置１０は、自組織で把握している事故情報、工事情報を利用者の端末や車両に送信する。利用者の端末や車両は、図１８に示すような表示を行う。利用者は、図１８に示される事故情報、工事情報を参照し、目的地へ向かう。

【0132】

上記第２の実施形態では、端末２０は、図１３に示すＧＵＩにより取得した情報を元に情報提供要求をサーバ装置１０に送信することを説明した。しかし、端末２０は、利用者の現在位置を取得したタイミング等において、情報提供要求をサーバ装置１０に送信してもよい。即ち、端末２０は、管轄地域内で利用者（観光客）の位置情報を取得した場合、図１３に示すＧＵＩを介さずに位置情報を含む情報提供要求を自動的に送信してもよい。換言すれば、サーバ装置１０－１のイベント検出部２０２は、管轄地域内で観光客の位置情報を取得したことをイベントとして検知してもよい。

【0133】

上記第２の実施形態では、利用者が自治体に対して情報提供を要求する場合について説明した。しかし、情報提供を要求する主体は、自治体（サーバ装置１０）であってもよい。例えば、自治体は、他の自治体の避難所に関する情報提供を要求してもよい。具体的には、サーバ装置１０は、「避難所情報の情報提供要求」を隣接する自治体のサーバ装置１０に送信する。避難所情報の情報提供要求を受信したサーバ装置１０は、避難所として開設が予定されている施設の情報（例えば、場所や状態）を情報提供要求元のサーバ装置１０に送信する。サーバ装置１０は、取得した情報を使って自組織（自治体）の管轄地域内の避難所に関する情報だけでなく、隣接する地域の避難所の情報を含む地図情報等を自治体職員等に提示する。例えば、サーバ装置１０は、図１９に示すような表示（ダッシュボード表示）を自治体の職員等が使用する端末に表示する。

【0134】

上記第２の実施形態において、サーバ装置１０の影響範囲特定部２０３は、利用者の現在位置を中心とした所定範囲を影響範囲として特定することを説明した。その際、提供範囲特定部２０３は、利用者の属性情報や嗜好情報に基づいて影響範囲を特定してもよい。例えば、端末２０は、図１３に類似するＧＵＩを用いて利用者の属性情報（性別、年齢等）や嗜好情報（関心事等）を取得する。端末２０は、取得した属性情報、嗜好情報を含む情報提供要求をサーバ装置１０に送信する。影響範囲特定部２０３は、年齢に応じて所定時間内（例えば、３０分）に徒歩で移動可能な範囲を影響範囲として特定したり、関心事に適合する地域を影響範囲として特定したりしてもよい。

【0135】

あるいは、利用者の住所がある自治体のサーバ装置１０に利用者の属性情報や嗜好情報が予め登録されており、当該予め登録された属性情報等が活用されてもよい。例えば、図１１において、利用者の住所は自治体Ａの管轄地域に含まれるものとする。この場合、サーバ装置１０－１が利用者の属性情報等を記憶する。利用者が自治体Ｂの管轄地域に移動し観光を行うと、利用者の端末２０は、当該利用者の住所が登録されている自治体Ａのサーバ装置１０－１に現在位置を含む情報提供要求を送信する。自治体Ａのサーバ装置１０－１は、情報提供要求を受信し、現在位置から利用者の位置を特定する。サーバ装置１０は、利用者の現在位置から当該利用者は自治体Ｂの管轄地域に存在すると判断すると、利用者の現在位置や属性情報等を含む情報提供要求を自治体Ｂのサーバ装置１０－２に送信する。自治体Ｂのサーバ装置１０－２は、利用者の現在位置、属性情報等に基づいて利用者に自治体Ｂに関する情報（例えば、観光地等の情報）を提供する。

【0136】

あるいは、各自治体では、複数の自治体に跨がって流れている河川の水位情報等の情報を共有してもよい。この場合にも、自治体のサーバ装置１０は、他の自治体のサーバ装置１０に「水位情報の情報提供要求」を送信すればよい。

【0137】

上記実施形態では、自治体（県、市、町等の自治体）を１つの単位（独自の情報を保持する組織の単位）としたが、組織の単位は自治体よりも細かい単位であってもよい。例えば、自治会のような組織が単位であってもよい。即ち、管轄地域が定まっている組織であれば、本願開示の対象とすることができる。

【0138】

上記実施形態では、サーバ装置１０は、複数の自治体のなかから１つの自治体を選択し、支援協力要請を送信することを説明した。しかし、サーバ装置１０は、複数の自治体を対象として支援協力要請を送信してもよい。例えば、図４の例では、サーバ装置１０は、自治体Ｃ及び自治体Ｄに支援を要請してもよい。

【0139】

あるいは、複数の自治体に支援を要請する場合には、サーバ装置１０は、各自治体に対して異なる支援を要請してもよい。上記の例では、サーバ装置１０は、自治体Ｃに対しては「仮設住宅の建設」の支援を要請し、自治体Ｄに対しては「生活必需品等の提供」を要請してもよい。換言すれば、このような支援内容が要望条件に記載されていてもよい。即ち、１つのイベント発生について、複数の支援内容が要望条件に記載されていてもよい。さらに、複数の支援内容に優先順位（優先度）が付与されていてもよい。例えば、上記の例では、「仮設住宅の建設」が「生活必需品等の提供」よりも優先された要望条件が策定されてもよい。

【0140】

図８等に示す要望条件管理データベースの内容は例示である。要望条件管理データベースには、イベントの種類に加え他の情報に応じた支援内容が記憶されていてもよい。例えば、「地震発生」のイベントに関し、地震の規模（震度、マグニチュード）ごとの支援の内容が要望条件管理データベースに登録されていてもよい（図２０参照）。

【0141】

第２の実施形態において、利用者の端末２０は、現在位置を管轄する自治体のサーバ装置１０に情報提供要求を送信することを説明した。しかし、利用者の端末２０は、予め定めたサーバ（図３等に図示せず）に情報提供要求を送信してもよい。当該予め定めたサーバは、情報提供要求に含まれる利用者の現在位置に応じて、当該情報提供要求を処理するサーバ装置１０を特定し、当該特定したサーバ装置１０に情報提供要求を転送すればよい。なお、上記予め定めたサーバは、各利用者に共通なサーバであってもよいし、各利用者の住所が登録されている地域のサーバ（サーバ装置１０）であってもよい。例えば、図１１の例において、利用者の住所が自治体Ｄの管轄地域内であれば、端末２０は、サーバ装置１０－４に情報提供要求を送信する。サーバ装置１０－４は、受信した情報提供要求を自治体Ａのサーバ装置１０－１に転送する（図２１参照）。サーバ装置１０－１は、サーバ装置１０－４を介して受信した情報提供要求を処理し、観光施設情報等を含む応答を端末２０に送信する。

【0142】

第２の実施形態において、観光施設等に関する情報提供を要求する際、利用者の端末２０は、移動手段（徒歩、車、電車）等に関する情報を含む情報提供要求をサーバ装置１０に送信してもよい。サーバ装置１０は、当該移動手段を考慮して影響範囲を特定してもよい。例えば、サーバ装置１０は、利用者の移動手段が徒歩であれば影響範囲を狭く設定し、利用者の移動手段が車であれば影響範囲を広く設定する。その結果、サーバ装置１０は、利用者が無理なく移動できる範囲で有益な情報提供を行うことができる。

【0143】

第２の実施形態において、利用者の端末２０は、要求する情報の種類（例えば、観光施設の案内、宿泊施設の案内）を含まない情報提供要求をサーバ装置１０に送信する。サーバ装置１０は、利用者の現在位置や情報提供要求を受信した日時等に応じて、当該利用者に適した情報を選択して送信してもよい。例えば、サーバ装置１０（情報提供処理部２０９）は、昼間に情報提供要求を受信した場合には、観光施設に関する情報提供を行い、夜間に情報提供要求を受信した場合には、宿泊施設に関する情報提供を行ってもよい。この場合、サーバ装置１０は、図２２に示すような要望条件管理データベースに従い、上記提供要求を処理すればよい。なお、図２２において、自治体に要求する具体的な内容を含まない情報提供要求の発生イベントの種類は「情報提供要求」と表記されている。

【0144】

各自治体は、発生するイベントの種類ごとに連携先の自治体を予め決めておいてもよい。さらに、イベントの種類ごとの連携先となる自治体は要望条件（要望条件管理データベース）により管理されていてもよい。例えば、災害が発生した際に支援を要請する複数の自治体が定められ、サーバ装置１０は、当該複数の自治体のなかから支援を要請する自治体を選択してもよい。また、情報提供を要望された際にも、サーバ装置１０は、予め定められた自治体のなかから支援を要請する自治体を選択してもよい。

【0145】

上記実施形態では、隣接する４つの自治体を例にとり自治体間の連携について説明した。しかし、連携の対象となる自治体は隣接しておらず、地理的に離れた自治体であってもよい。地震等の災害が発生した際、地理的に離れた自治体であれば当該発生した地震の影響は少ないと考えられ、連携先の自治体から十分な支援を受けられる可能性がある。しかし、地理的に離れた自治体から物資を運搬するのにコスト（時間、費用）が必要である。各自治体は、想定されるイベントの内容に応じてメリット、デメリットを考慮し、連携先の自治体を決定すればよい。

【0146】

各装置（サーバ装置１０、端末２０等）間のデータ送受信の形態は特に限定されないが、これら装置間で送受信されるデータは暗号化されていてもよい。これらの装置間では、利用者の現在位置等が送受信され、これらの情報を適切に保護するためには、暗号化されたデータが送受信されることが望ましい。

【0147】

上記説明で用いた流れ図（フローチャート、シーケンス図）では、複数の工程（処理）が順番に記載されているが、実施形態で実行される工程の実行順序は、その記載の順番に制限されない。実施形態では、例えば各処理を並行して実行する等、図示される工程の順番を内容的に支障のない範囲で変更することができる。

【0148】

上記の実施形態は本願開示の理解を容易にするために詳細に説明したものであり、上記説明したすべての構成が必要であることを意図したものではない。また、複数の実施形態について説明した場合には、各実施形態は単独で用いてもよいし、組み合わせて用いてもよい。例えば、実施形態の構成の一部を他の実施形態の構成に置き換えることや、実施形態の構成に他の実施形態の構成を加えることも可能である。さらに、実施形態の構成の一部について他の構成の追加、削除、置換が可能である。

【0149】

上記の説明により、本発明の産業上の利用可能性は明らかであるが、本発明は、複数の都市（自治体）が連携する情報処理システムなどに好適に適用可能である。

【0150】

上記の実施形態の一部又は全部は、以下の付記のようにも記載され得るが、以下には限られない。
［付記１］
第１の自治体の管轄地域で発生したイベントを検出する、検出部と、
前記発生したイベントの影響範囲を特定する、特定部と、
前記特定された影響範囲に基づいて、支援を要請する第２の自治体を選択する、選択部と、
前記選択された第２の自治体のサーバ装置に、支援内容を含む支援協力要請を送信する、支援要請部と、
を備える、サーバ装置。
［付記２］
前記支援要請部は、イベントの種類に応じた前記支援内容を定める要望条件に基づき、前記支援協力要請を生成する、付記１に記載のサーバ装置。
［付記３］
前記検出部は、前記第１の自治体の管轄地域で発生した災害を前記イベントとして検出し、
前記選択部は、前記影響範囲と重複しない管轄地域を持つ自治体を、前記支援を要請する第２の自治体として選択する、付記１又は２に記載のサーバ装置。
［付記４］
前記選択部は、前記影響範囲と重複しない管轄地域を持つ複数の自治体それぞれの属性情報に基づいて、前記支援を要請する第２の自治体を選択する、付記３に記載のサーバ装置。
［付記５］
前記支援要請部は、避難所で用いられる物品の提供を前記支援内容として含む前記支援協力要請を生成する、付記３又は４に記載のサーバ装置。
［付記６］
前記第１の自治体の管轄領域内の前記影響範囲に住む住民の数に基づいて、前記第２の自治体へ支援を要請するか否か判定する、判定部をさらに備える、付記３乃至５のいずれか一項に記載のサーバ装置。
［付記７］
前記検出部は、前記管轄地域に滞在する利用者の端末から送信された情報提供要求を前記イベントとして検出し、
前記選択部は、前記影響範囲と重複する管轄地域を持つ自治体を、前記支援を要請する第２の自治体として選択する、付記１又は２に記載のサーバ装置。
［付記８］
前記情報提供要求には施設の案内を要求することが記載され、
前記支援要請部は、前記施設の案内に関する情報提供を前記支援内容とする前記支援協力要請を生成する、付記７に記載のサーバ装置。
［付記９］
前記端末から送信された情報提供要求に応じて、前記第１の自治体の管轄地域に存在する施設に関する第１の情報を生成すると共に、前記第２の自治体のサーバ装置により生成された前記第２の自治体の管轄地域に存在する施設に関する第２の情報と、前記生成された第１の情報と、を前記端末に送信する、情報提供処理部をさらに含む、付記８に記載のサーバ装置。
［付記１０］
前記情報提供要求に記載された施設は、観光施設又は宿泊施設である、付記８又は９に記載のサーバ装置。
［付記１１］
サーバ装置において、
第１の自治体の管轄地域で発生したイベントを検出し、
前記発生したイベントの影響範囲を特定し、
前記特定された影響範囲に基づいて、支援を要請する第２の自治体を選択し、
前記選択された第２の自治体のサーバ装置に、支援内容を含む支援協力要請を送信する、サーバ装置の制御方法。
［付記１２］
サーバ装置に搭載されたコンピュータに、
第１の自治体の管轄地域で発生したイベントを検出する処理と、
前記発生したイベントの影響範囲を特定する処理と、
前記特定された影響範囲に基づいて、支援を要請する第２の自治体を選択する処理と、
前記選択された第２の自治体のサーバ装置に、支援内容を含む支援協力要請を送信する処理と、
を実行させるためのプログラムを記憶する、コンピュータ読取可能な記憶媒体。

【0151】

なお、引用した上記の先行技術文献の各開示は、本書に引用をもって繰り込むものとする。以上、本発明の実施形態を説明したが、本発明はこれらの実施形態に限定されるものではない。これらの実施形態は例示にすぎないということ、及び、本発明のスコープ及び精神から逸脱することなく様々な変形が可能であるということは、当業者に理解されるであろう。即ち、本発明は、請求の範囲を含む全開示、技術的思想にしたがって当業者であればなし得る各種変形、修正を含むことは勿論である。

【符号の説明】

【0152】

１０ サーバ装置
１０－１ サーバ装置
１０－２ サーバ装置
１０－３ サーバ装置
１０－４ サーバ装置
２０ 端末
１００ サーバ装置
１０１ 検出部
１０２ 特定部
１０３ 選択部
１０４ 支援要請部
２０１ 通信制御部
２０２ イベント検出部
２０３ 影響範囲特定部
２０４ 支援要否判定部
２０５ 支援要請先選択部
２０６ 支援要請部
２０７ 支援要請処理部
２０８ 記憶部
２０９ 情報提供処理部
３０１ 通信制御部
３０２ 位置情報生成部
３０３ 情報提供要求部
３０４ 情報提供部
３０５ 記憶部
３１１ プロセッサ
３１２ メモリ
３１３ 入出力インターフェイス
３１４ 通信インターフェイス

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】