ホーム > 特許ランキング > 旭化成ホームズ株式会社
知財求人 - 知財ポータルサイト「IP Force」
特開2024-17599災害情報処理システム、モード切替装置および優先度判定装置
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024017599
(43)【公開日】2024-02-08
(54)【発明の名称】災害情報処理システム、モード切替装置および優先度判定装置
(51)【国際特許分類】
G06Q 50/26 20240101AFI20240201BHJP
G06Q 30/0601 20230101ALI20240201BHJP
【ＦＩ】
G06Q50/26
G06Q30/06 300
【審査請求】未請求
【請求項の数】12
【出願形態】ＯＬ
(21)【出願番号】P 2022120345
(22)【出願日】2022-07-28
(71)【出願人】
【識別番号】303046244
【氏名又は名称】旭化成ホームズ株式会社
(74)【代理人】
【識別番号】100149548
【弁理士】
【氏名又は名称】松沼 泰史
(74)【代理人】
【識別番号】100188558
【弁理士】
【氏名又は名称】飯田 雅人
(74)【代理人】
【識別番号】100165179
【弁理士】
【氏名又は名称】田▲崎▼ 聡
(74)【代理人】
【識別番号】100189337
【弁理士】
【氏名又は名称】宮本 龍
(72)【発明者】
【氏名】新谷 伸高
(72)【発明者】
【氏名】難波 稔
(72)【発明者】
【氏名】福本 博文
【テーマコード（参考）】
5L049
【Ｆターム（参考）】
5L049BB22
5L049CC35
(57)【要約】
【課題】災害時に被災者が必要とする商品または役務の支援を効率よく行うことができる災害情報処理システムを提供する。
【解決手段】第１Ａユーザーの第１Ａ端末装置を含む複数の端末装置と、管理装置と、を有する災害情報処理システムであって、前記管理装置は、複数の前記端末装置に取引サービスを提供する取引サービス提供部を備え、前記取引サービス提供部は、平常時に前記第１Ａユーザーが第２Ａユーザーと商取引することを可能とする第１Ａ画面表示を前記第１Ａ端末装置に提供する平常時モードと、災害時に被災者となった前記第１Ａユーザーが支援者となり得る前記第２Ａユーザーまたは第３Ａユーザーからの支援を成立させることを可能とする第２Ａ画面表示を前記第１Ａ端末装置に提供する災害時モードと、を切り替えるモード切替部を備える、災害情報処理システム。
【選択図】図１
【解決手段】第１Ａユーザーの第１Ａ端末装置を含む複数の端末装置と、管理装置と、を有する災害情報処理システムであって、前記管理装置は、複数の前記端末装置に取引サービスを提供する取引サービス提供部を備え、前記取引サービス提供部は、平常時に前記第１Ａユーザーが第２Ａユーザーと商取引することを可能とする第１Ａ画面表示を前記第１Ａ端末装置に提供する平常時モードと、災害時に被災者となった前記第１Ａユーザーが支援者となり得る前記第２Ａユーザーまたは第３Ａユーザーからの支援を成立させることを可能とする第２Ａ画面表示を前記第１Ａ端末装置に提供する災害時モードと、を切り替えるモード切替部を備える、災害情報処理システム。
【選択図】図１
【特許請求の範囲】
【請求項1】
第１Ａユーザーの第１Ａ端末装置を含む複数の端末装置と、管理装置と、を有する災害情報処理システムであって、
前記管理装置は、複数の前記端末装置に取引サービスを提供する取引サービス提供部を備え、
前記取引サービス提供部は、平常時に前記第１Ａユーザーが第２Ａユーザーと商取引することを可能とする第１Ａ画面表示を前記第１Ａ端末装置に提供する平常時モードと、災害時に被災者となった前記第１Ａユーザーが支援者となり得る前記第２Ａユーザーまたは第３Ａユーザーからの支援を成立させることを可能とする第２Ａ画面表示を前記第１Ａ端末装置に提供する災害時モードと、を切り替えるモード切替部を備える、
災害情報処理システム。
前記管理装置は、複数の前記端末装置に取引サービスを提供する取引サービス提供部を備え、
前記取引サービス提供部は、平常時に前記第１Ａユーザーが第２Ａユーザーと商取引することを可能とする第１Ａ画面表示を前記第１Ａ端末装置に提供する平常時モードと、災害時に被災者となった前記第１Ａユーザーが支援者となり得る前記第２Ａユーザーまたは第３Ａユーザーからの支援を成立させることを可能とする第２Ａ画面表示を前記第１Ａ端末装置に提供する災害時モードと、を切り替えるモード切替部を備える、
災害情報処理システム。
【請求項2】
前記モード切替部は、前記災害時に、少なくとも所定の期間が経過したという条件が満たされた場合に、前記平常時モードの前記第１Ａ画面表示から前記災害時モードの前記第２Ａ画面表示へ切り替える、
請求項１に記載の災害情報処理システム。
請求項１に記載の災害情報処理システム。
【請求項3】
前記モード切替部は、前記災害時に、少なくとも前記第１Ａ端末装置から所定の指示を受けたという条件が満たされた場合に、前記平常時モードの前記第１Ａ画面表示から前記災害時モードの前記第２Ａ画面表示へ切り替える、
請求項１に記載の災害情報処理システム。
請求項１に記載の災害情報処理システム。
【請求項4】
前記モード切替部は、前記災害時に、少なくとも前記第１Ａ端末装置の位置に基づいて、前記平常時モードの前記第１Ａ画面表示から前記災害時モードの前記第２Ａ画面表示へ切り替えるタイミングを制御する、
請求項１に記載の災害情報処理システム。
請求項１に記載の災害情報処理システム。
【請求項5】
前記管理装置は、さらに、
前記被災者となった前記第１Ａユーザーについて、前記被災者として支援を受ける際のの優先度を判定する優先度判定部を備える、
請求項１に記載の災害情報処理システム。
前記被災者となった前記第１Ａユーザーについて、前記被災者として支援を受ける際のの優先度を判定する優先度判定部を備える、
請求項１に記載の災害情報処理システム。
【請求項6】
第１Ｂユーザーの第１Ｂ端末装置を含む複数の端末装置と、管理装置と、を有する災害情報処理システムであって、
前記管理装置は、災害時に被災者となった前記第１Ｂユーザーが支援者となり得る第２Ｂユーザーからの支援を成立させることを可能とする第１Ｂ画面表示を前記第１Ｂ端末装置に提供する取引サービス提供部と、
前記被災者となった前記第１Ｂユーザーについて、前記被災者として支援を受ける際の優先度を判定する優先度判定部と、
を備える、災害情報処理システム。
前記管理装置は、災害時に被災者となった前記第１Ｂユーザーが支援者となり得る第２Ｂユーザーからの支援を成立させることを可能とする第１Ｂ画面表示を前記第１Ｂ端末装置に提供する取引サービス提供部と、
前記被災者となった前記第１Ｂユーザーについて、前記被災者として支援を受ける際の優先度を判定する優先度判定部と、
を備える、災害情報処理システム。
【請求項7】
前記取引サービス提供部は、前記優先度が高い前記第１Ｂユーザーの前記第１Ｂ端末装置に前記第２Ｂユーザーに関する情報を提供し、前記優先度が低い第３Ｂユーザーの第３Ｂ端末装置に前記第２Ｂユーザーに関する情報を提供しない第１状態とする、
請求項６に記載の災害情報処理システム。
請求項６に記載の災害情報処理システム。
【請求項8】
前記取引サービス提供部は、前記第１状態の後、少なくとも所定の期間が経過したという条件が満たされた場合に、前記第３Ｂ端末装置に前記第２Ｂユーザーに関する情報を提供する第２状態とする、
請求項７に記載の災害情報処理システム。
請求項７に記載の災害情報処理システム。
【請求項9】
前記優先度は、前記災害の発生前に取得された前記第１Ｂユーザーに関する情報、前記災害の発生後に取得された前記第１Ｂユーザーに関する情報、および、前記支援の需要と供給とのバランスのうちの１以上に基づく、
請求項６に記載の災害情報処理システム。
請求項６に記載の災害情報処理システム。
【請求項10】
前記取引サービス提供部は、平常時に前記第１Ｂユーザーが前記第２Ｂユーザーまたは第４Ｂユーザーと商取引することを可能とする第２Ｂ画面表示を前記第１Ｂ端末装置に提供する平常時モードと、災害時に前記被災者となった前記第１Ｂユーザーが支援者となり得る前記第２Ｂユーザーからの支援を成立させることを可能とする前記第１Ｂ画面表示を前記第１Ｂ端末装置に提供する災害時モードと、を切り替えるモード切替部を備える、
請求項６に記載の災害情報処理システム。
請求項６に記載の災害情報処理システム。
【請求項11】
平常時に第１Ａユーザーが第２Ａユーザーと商取引することを可能とする第１Ａ画面表示が前記第１Ａユーザーの第１Ａ端末装置に提供される平常時モードと、災害時に被災者となった前記第１Ａユーザーが支援者となり得る前記第２Ａユーザーまたは第３Ａユーザーからの支援を成立させることを可能とする第２Ａ画面表示が前記第１Ａ端末装置に提供される災害時モードと、を切り替える、
モード切替装置。
モード切替装置。
【請求項12】
災害時に被災者となった第１Ｂユーザーが支援者となり得る第２Ｂユーザーからの支援を成立させることを可能とする第１Ｂ画面表示が前記第１Ｂユーザーの第１Ｂ端末装置に提供される場合に、前記被災者となった前記第１Ｂユーザーについて、前記被災者として支援を受ける際の優先度を判定する、
優先度判定装置。
優先度判定装置。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、災害情報処理システム、モード切替装置および優先度判定装置に関する。
【背景技術】
【0002】
災害の発生時に被災者の支援を行うことは重要であり、災害時のための様々な情報処理システムが開発されている。
【0003】
例えば、特許文献１には、公衆通信網が利用できない環境において使用され、複数のサーバー装置間の情報共有を利用者の端末装置を媒介して行うことを可能とする災害時情報管理システムが記載されている。当該災害時情報管理システムでは、登録者のプロフィールと傷病者の情報を照らし合わせて、適切な登録者と傷病者のマッチングにより登録者リストからチームメンバーとなる人を選択して傷病者を救助するための救助チームを編成し、編成された救助チームに対して傷病者リストから選択して担当傷病者を割り振ることが行われている（特許文献１参照。）。
【先行技術文献】
【特許文献】
【0004】
【特許文献1】特開２０１７－７９０２３号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかしながら、従来の技術では、災害時に被災者が必要とする商品または役務の支援を効率よく行う点で、未だに不十分な点もあり、開発の余地があった。
【0006】
本開示は、このような事情を考慮してなされたもので、災害時に被災者が必要とする商品または役務の支援を効率よく行うことができる災害情報処理システム、モード切替装置および優先度判定装置を提供することを課題とする。
【課題を解決するための手段】
【0007】
本開示の一態様は、第１Ａユーザーの第１Ａ端末装置を含む複数の端末装置と、管理装置と、を有する災害情報処理システムであって、前記管理装置は、複数の前記端末装置に取引サービスを提供する取引サービス提供部を備え、前記取引サービス提供部は、平常時に前記第１Ａユーザーが第２Ａユーザーと商取引することを可能とする第１Ａ画面表示を前記第１Ａ端末装置に提供する平常時モードと、災害時に被災者となった前記第１Ａユーザーが支援者となり得る前記第２Ａユーザーまたは第３Ａユーザーからの支援を成立させることを可能とする第２Ａ画面表示を前記第１Ａ端末装置に提供する災害時モードと、を切り替えるモード切替部を備える、災害情報処理システムである。
【0008】
本開示の一態様は、第１Ｂユーザーの第１Ｂ端末装置を含む複数の端末装置と、管理装置と、を有する災害情報処理システムであって、前記管理装置は、災害時に被災者となった前記第１Ｂユーザーが支援者となり得る第２Ｂユーザーからの支援を成立させることを可能とする第１Ｂ画面表示を前記第１Ｂ端末装置に提供する取引サービス提供部と、前記被災者となった前記第１Ｂユーザーについて、前記被災者として支援を受ける際の優先度を判定する優先度判定部と、を備える、災害情報処理システムである。
【0009】
本開示の一態様は、平常時に第１Ａユーザーが第２Ａユーザーと商取引することを可能とする第１Ａ画面表示が前記第１Ａユーザーの第１Ａ端末装置に提供される平常時モードと、災害時に被災者となった前記第１Ａユーザーが支援者となり得る前記第２Ａユーザーまたは第３Ａユーザーからの支援を成立させることを可能とする第２Ａ画面表示が前記第１Ａ端末装置に提供される災害時モードと、を切り替える、モード切替装置である。
【0010】
本開示の一態様は、災害時に被災者となった第１Ｂユーザーが支援者となり得る第２Ｂユーザーからの支援を成立させることを可能とする第１Ｂ画面表示が前記第１Ｂユーザーの第１Ｂ端末装置に提供される場合に、前記被災者となった前記第１Ｂユーザーについて、前記被災者として支援を受ける際の優先度を判定する、優先度判定装置である。
【発明の効果】
【0011】
本開示に係る災害情報処理システム、モード切替装置および優先度判定装置によれば、災害時に被災者が必要とする商品または役務の支援を効率よく行うことができる。
【図面の簡単な説明】
【0012】
【図1】実施形態に係る災害情報処理システムの構成の一例を示す図である。
【図2】実施形態に係る需要側端末装置の機能ブロックの一例を示す図である。
【図3】実施形態に係る提供側端末装置の機能ブロックの一例を示す図である。
【図4】実施形態に係る管理装置の機能ブロックの一例を示す図である。
【図5】実施形態に係る平常時モードにおける表示の一例を示す図である。
【図6】実施形態に係る災害時モードにおける表示の一例を示す図である。
【図7】実施形態に係る災害時モードにおける表示の他の一例を示す図である。
【図8】実施形態に係る災害時モードにおける表示の他の一例を示す図である。
【図9】実施形態に係る需要側テーブルの構成の一例を示す図である。
【図10】実施形態に係る提供側テーブルの構成の一例を示す図である。
【図11】実施形態に係る優先度スコアの算出ロジックの例を示す図である。
【図12】実施形態に係る優先度スコアが高い被災者に対するマッチング候補表示の一例を示す図である。
【図13】実施形態に係る優先度スコアが低い被災者に対するマッチング候補表示の一例を示す図である。
【図14】実施形態に係るマッチング成立後の流れの一例を示す図である。
【図15】実施形態に係る被災マップの一例を示す図である。
【図16】実施形態に係る需要側の利用の流れの処理の手順の一例を示す図である。
【図17】実施形態に係る提供側の利用の流れの処理の手順の一例を示す図である。
【図18】実施形態に係る管理装置におけるマッチングの処理の手順の一例を示す図である。
【図19】実施形態に係る災害情報処理システムにおける処理の手順の一例を示す図である。
【発明を実施するための形態】
【0013】
以下、図面を参照し、本開示の実施形態について説明する。
【0014】
［災害情報処理システム］
図１は、実施形態に係る災害情報処理システム１の構成の一例を示す図である。
本実施形態では、災害情報処理システム１は、災害時に対応した情報処理を行う機能を有しているとともに、平常時に対応した情報処理を行う機能も有している。
図１は、実施形態に係る災害情報処理システム１の構成の一例を示す図である。
本実施形態では、災害情報処理システム１は、災害時に対応した情報処理を行う機能を有しているとともに、平常時に対応した情報処理を行う機能も有している。
【0015】
＜実施形態における災害時と平常時＞
ここで、本実施形態では、災害時とは、所定の災害が発生したときを表す。
当該所定の災害としては、例えば、当該所定の災害が発生するよりも前にあらかじめ定められた条件を満たす事象（本実施形態で言う災害）であってもよく、あるいは、ある事象（本実施形態で言う災害）が発生した後に、所定の人または所定の機関などによって当該所定の災害とみなすと判断された事象（本実施形態で言う災害）であってもよい。
当該所定の条件は、ある事象（本実施形態で言う災害）の程度が所定の閾値以上である（または、所定の閾値を超える）という条件であってもよい。
当該程度は、例えば、強度の程度であってもよく、地理的な広さの程度であってもよく、時間の長さの程度であってもよく、または、他の任意の程度であってもよく、あるいは、これらのような任意の２以上の組み合わせの程度であってもよい。
ここで、本実施形態では、災害時とは、所定の災害が発生したときを表す。
当該所定の災害としては、例えば、当該所定の災害が発生するよりも前にあらかじめ定められた条件を満たす事象（本実施形態で言う災害）であってもよく、あるいは、ある事象（本実施形態で言う災害）が発生した後に、所定の人または所定の機関などによって当該所定の災害とみなすと判断された事象（本実施形態で言う災害）であってもよい。
当該所定の条件は、ある事象（本実施形態で言う災害）の程度が所定の閾値以上である（または、所定の閾値を超える）という条件であってもよい。
当該程度は、例えば、強度の程度であってもよく、地理的な広さの程度であってもよく、時間の長さの程度であってもよく、または、他の任意の程度であってもよく、あるいは、これらのような任意の２以上の組み合わせの程度であってもよい。
【0016】
具体例として、災害が地震である場合について例示する。
一例として、ある地震が発生したとき、当該地震があらかじめ定められた条件を満たす場合に、本実施形態における災害時となる。当該条件は、例えば、当該地震の強度が所定の閾値以上である（または、所定の閾値を超える）という条件、当該地震の地理的な広さが所定の閾値以上である（または、所定の閾値を超える）という条件、当該地震による影響が続くと予想される時間が所定の閾値以上である（または、所定の閾値を超える）という条件などのうちの１以上が用いられてもよい。
他の例として、ある地震が発生したとき、その後に、所定の人または所定の機関などによって当該地震が本実施形態における災害時に該当するか否かが判断されてもよい。この判断の基準としては、任意の基準が用いられてもよい。
一例として、ある地震が発生したとき、当該地震があらかじめ定められた条件を満たす場合に、本実施形態における災害時となる。当該条件は、例えば、当該地震の強度が所定の閾値以上である（または、所定の閾値を超える）という条件、当該地震の地理的な広さが所定の閾値以上である（または、所定の閾値を超える）という条件、当該地震による影響が続くと予想される時間が所定の閾値以上である（または、所定の閾値を超える）という条件などのうちの１以上が用いられてもよい。
他の例として、ある地震が発生したとき、その後に、所定の人または所定の機関などによって当該地震が本実施形態における災害時に該当するか否かが判断されてもよい。この判断の基準としては、任意の基準が用いられてもよい。
【0017】
このように、本実施形態では、同じ種類の事象（例えば、地震）であっても、影響が大きいと予想される事象については本実施形態における災害時とし、他の事象については本実施形態における災害時とはしない。
一例として、災害が地震である場合、震度が所定の閾値以上の地震については本実施形態における災害時とし、他の地震については本実施形態における災害時とはしない、といった態様が可能である。
他の例として、災害が地震である場合、政府などの所定機関が当該地震が特定の災害であると判断したときには本実施形態における災害時とし、他の地震については本実施形態における災害時とはしない、といった態様が可能である。
一例として、災害が地震である場合、震度が所定の閾値以上の地震については本実施形態における災害時とし、他の地震については本実施形態における災害時とはしない、といった態様が可能である。
他の例として、災害が地震である場合、政府などの所定機関が当該地震が特定の災害であると判断したときには本実施形態における災害時とし、他の地震については本実施形態における災害時とはしない、といった態様が可能である。
【0018】
ここでは、災害が地震である場合を例として説明したが、災害の種類としては、特に限定はなく、地震以外に、台風、洪水、津波、噴火、火災、感染症などであってもよい。
また、例えば、地震の発生に付随して津波が発生し得るような場合に、地震と津波とがまとめて１つの災害として扱われてもよい。
また、例えば、地震の発生に付随して津波が発生し得るような場合に、地震と津波とがまとめて１つの災害として扱われてもよい。
【0019】
なお、本実施形態における災害時であるか否かの判定は、任意の手法によって行われてもよい。
また、他の例として、何らかの災害が発生した場合には、常に、本実施形態における災害時であると判定する態様が用いられてもよい。
また、他の例として、何らかの災害が発生した場合には、常に、本実施形態における災害時であると判定する態様が用いられてもよい。
【0020】
本実施形態では、災害時ではないときを平常時とする。
つまり、本実施形態では、平常時と災害時という２種類の期間があると想定する。
なお、本実施形態では、説明を簡易化するために、平常時と災害時という２種類の期間があると想定するが、他の例として、平常時と災害時とを含む３種類以上の期間がある態様が用いられてもよい。
つまり、本実施形態では、平常時と災害時という２種類の期間があると想定する。
なお、本実施形態では、説明を簡易化するために、平常時と災害時という２種類の期間があると想定するが、他の例として、平常時と災害時とを含む３種類以上の期間がある態様が用いられてもよい。
【0021】
＜災害時における災害情報処理システムの状況＞
図１の例では、災害時における災害情報処理システム１の状況を示してある。
災害情報処理システム１は、複数であるｎ個の需要側の端末装置（需要側端末装置１１－１～１１－ｎ）と、複数であるｍ個の提供側の端末装置（提供側端末装置１２－１～１２－ｍ）と、１個の管理装置１３と、を備える。
図１の例では、災害時における災害情報処理システム１の状況を示してある。
災害情報処理システム１は、複数であるｎ個の需要側の端末装置（需要側端末装置１１－１～１１－ｎ）と、複数であるｍ個の提供側の端末装置（提供側端末装置１２－１～１２－ｍ）と、１個の管理装置１３と、を備える。
【0022】
ｎ個の需要側端末装置１１－１～１１－ｎのそれぞれは、ｎ人の需要側ユーザー２１－１～２１－ｎのそれぞれによって所有されていて操作される。
ｍ個の提供側端末装置１２－１～１２－ｍのそれぞれは、ｍ人の提供側ユーザー２２－１～２２－ｍのそれぞれによって所有されていて操作される。
ｍ個の提供側端末装置１２－１～１２－ｍのそれぞれは、ｍ人の提供側ユーザー２２－１～２２－ｍのそれぞれによって所有されていて操作される。
【0023】
ここで、本実施形態では、説明を簡易化するために、需要側ユーザー２１－１～２１－ｎと需要側端末装置１１－１～１１－ｎとが１対１である場合を示すが、他の例として、１人の需要側ユーザーが２個以上の需要側端末装置を所有して操作してもよく、あるいは、２人以上の需要側ユーザーが１個の需要側端末装置を共有して操作してもよい。
例えば、家族などの集団の代表者（例えば、親）が所有している１個の需要側端末装置を用いて、当該集団に属する全員または一部のために、災害時の支援を求めることが行われてもよい。
なお、需要側ユーザー２１－１～２１－ｎは、需要側端末装置１１－１～１１－ｎを所有する代わりに、需要側端末装置１１－１～１１－ｎを貸与等されていてもよい。
例えば、家族などの集団の代表者（例えば、親）が所有している１個の需要側端末装置を用いて、当該集団に属する全員または一部のために、災害時の支援を求めることが行われてもよい。
なお、需要側ユーザー２１－１～２１－ｎは、需要側端末装置１１－１～１１－ｎを所有する代わりに、需要側端末装置１１－１～１１－ｎを貸与等されていてもよい。
【0024】
同様に、本実施形態では、説明を簡易化するために、提供側ユーザー２２－１～２２－ｍと提供側端末装置１２－１～１２－ｍとが１対１である場合を示すが、他の例として、１人の提供側ユーザーが２個以上の提供側端末装置を所有して操作してもよく、あるいは、２人以上の提供側ユーザーが１個の提供側端末装置を共有して操作してもよい。
例えば、行政施設などの集団の代表者が所有している１個の提供側端末装置を用いて、当該集団に属する全員または一部によって、災害時の支援を提供することが行われてもよい。
なお、提供側ユーザー２２－１～２２－ｍは、提供側端末装置１２－１～１２－ｍを所有する代わりに、提供側端末装置１２－１～１２－ｍを貸与等されていてもよい。
例えば、行政施設などの集団の代表者が所有している１個の提供側端末装置を用いて、当該集団に属する全員または一部によって、災害時の支援を提供することが行われてもよい。
なお、提供側ユーザー２２－１～２２－ｍは、提供側端末装置１２－１～１２－ｍを所有する代わりに、提供側端末装置１２－１～１２－ｍを貸与等されていてもよい。
【0025】
図１の例では、説明を簡易化するために、需要側ユーザー２１－１～２１－ｎは災害の被災者である人（ユーザー）であるとし、提供側ユーザー２２－１～２２－ｍは当該災害の被災者ではない人（ユーザー）であるとする。
そして、災害時には、需要側ユーザー２１－１～２１－ｎは支援の需要がある人であるとし、提供側ユーザー２２－１～２２－ｍは支援の提供をし得る人であるとする。
そして、災害時には、需要側ユーザー２１－１～２１－ｎは支援の需要がある人であるとし、提供側ユーザー２２－１～２２－ｍは支援の提供をし得る人であるとする。
【0026】
ここで、本実施形態では、説明を簡易化するために、需要側ユーザー２１－１～２１－ｎと提供側ユーザー２２－１～２２－ｍとを区別して説明するが、他の例として、同一の被災者が需要側ユーザーと提供側ユーザーとの両方になる場合があってもよい。
つまり、同一の被災者が、需要側ユーザーとして他の人（提供側ユーザー）から支援を受けるとともに、提供側ユーザーとして別の他の人（需要側ユーザー）に支援を提供してもよい。
具体例として、被災者のなかには、水については支援を受けたいが、食料については支援を提供することが可能であるような被災者もあり得る。
つまり、同一の被災者が、需要側ユーザーとして他の人（提供側ユーザー）から支援を受けるとともに、提供側ユーザーとして別の他の人（需要側ユーザー）に支援を提供してもよい。
具体例として、被災者のなかには、水については支援を受けたいが、食料については支援を提供することが可能であるような被災者もあり得る。
【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】
本実施形態では、図１の例において、候補者は、ｎ人の需要側ユーザー２１－１～２１－ｎのうちの１人以上の者である。
なお、いずれの需要側ユーザー２１－１～２１－ｎも候補者となり得ない場合があってもよく、この場合、本実施形態では、候補者は０人となる。
なお、本実施形態では、提供側ユーザー２２－１が、提供の相手となる需要者（被支援者であり、本実施形態では、被災者）となり得る候補者のリストを見て、希望の需要者を選択することが可能な構成を示すが、このような構成は必ずしも用いられなくてもよい。
なお、いずれの需要側ユーザー２１－１～２１－ｎも候補者となり得ない場合があってもよく、この場合、本実施形態では、候補者は０人となる。
なお、本実施形態では、提供側ユーザー２２－１が、提供の相手となる需要者（被支援者であり、本実施形態では、被災者）となり得る候補者のリストを見て、希望の需要者を選択することが可能な構成を示すが、このような構成は必ずしも用いられなくてもよい。
【0091】
制御部２１５は、ＧＰＳ部２３３によって取得された位置の情報を通信部２１３により管理装置１３に送信する。
ここで、当該位置の情報は、他の情報とは別に管理装置１３に送信されてもよく、あるいは、他の情報とともに管理装置１３に送信されてもよい。
例えば、提供側属性情報取得部２５１が、提供側の属性情報とともに当該位置の情報を管理装置１３に送信してもよく、あるいは、提供情報取得部２５２が、提供情報とともに当該位置の情報を管理装置１３に送信してもよい。
なお、属性情報と提供情報と位置の情報がまとめて管理装置１３に送信されてもよい。
ここで、当該位置の情報は、他の情報とは別に管理装置１３に送信されてもよく、あるいは、他の情報とともに管理装置１３に送信されてもよい。
例えば、提供側属性情報取得部２５１が、提供側の属性情報とともに当該位置の情報を管理装置１３に送信してもよく、あるいは、提供情報取得部２５２が、提供情報とともに当該位置の情報を管理装置１３に送信してもよい。
なお、属性情報と提供情報と位置の情報がまとめて管理装置１３に送信されてもよい。
【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】
ここで、マッチング部３３５および候補者リスト生成部３３６は、ある被災者とある支援者とのマッチングによる支援が成立して、当該被災者に対する支援の需要および当該支援者による支援の提供可能性の一方または両方が変化した（例えば、無くなった）場合には、それに基づいて、それぞれの被災者に提供される候補者リストおよびそれぞれの支援者に提供される候補者リストの一方または両方を変更してもよい。
このような変更は、例えば、被災者の優先度スコアを再計算すること、被災者の優先付けを再度行うこと、被災者と支援者とのマッチングの処理を再度行うこと、あるいは、候補者リストを再度生成すること、のうちの１以上によって実現されてもよい。
このような変更は、例えば、被災者の優先度スコアを再計算すること、被災者の優先付けを再度行うこと、被災者と支援者とのマッチングの処理を再度行うこと、あるいは、候補者リストを再度生成すること、のうちの１以上によって実現されてもよい。
【0124】
需給状況解析部３３８は、需要と供給の状況の解析を行う。
本実施形態では、需給状況解析部３３８は、例えば、被災者（需要側ユーザー２１－１～２１－ｎ）によって希望される支援（需要）と、支援者（提供側ユーザー２２－１～２２－ｍ）によって提供可能な支援（供給）と、の状況に関する解析を行う。
一例として、需給状況解析部３３８は、このような需要と供給との関係に関する解析を行ってもよく、支援が実現された割合などに関する解析を行ってもよい。
ここで、このような解析の手法としては、特に限定はなく、任意の手法が用いられてもよい。
本実施形態では、需給状況解析部３３８は、例えば、被災者（需要側ユーザー２１－１～２１－ｎ）によって希望される支援（需要）と、支援者（提供側ユーザー２２－１～２２－ｍ）によって提供可能な支援（供給）と、の状況に関する解析を行う。
一例として、需給状況解析部３３８は、このような需要と供給との関係に関する解析を行ってもよく、支援が実現された割合などに関する解析を行ってもよい。
ここで、このような解析の手法としては、特に限定はなく、任意の手法が用いられてもよい。
【0125】
ここで、本実施形態では、管理装置１３は、それぞれの需要側ユーザー２１－１～２１－ｎに通知する提供側ユーザー２２－１～２２－ｍの候補者リストと、それぞれの提供側ユーザー２２－１～２２－ｍに通知する需要側ユーザー２１－１～２１－ｎの候補者リストと、を生成する場合を示すが、他の例として、これらのうちの一方の候補者リストを生成しない構成が用いられてもよい。
例えば、管理装置１３は、必ずしも、それぞれの提供側ユーザー２２－１～２２－ｍに通知する需要側ユーザー２１－１～２１－ｎの候補者リストを生成しなくてもよい。
なお、生成されない候補者リストについては、例えば、管理装置１３における候補者抽出部３７３の該当する機能、管理装置１３における候補者リスト生成部３３６の該当する機能、端末装置における候補者リスト取得部の機能（例えば、需要側端末装置１１－１における候補者リスト取得部１５３、または、提供側端末装置１２－１における候補者リスト取得部２５３）は備えられなくてもよい。
例えば、管理装置１３は、必ずしも、それぞれの提供側ユーザー２２－１～２２－ｍに通知する需要側ユーザー２１－１～２１－ｎの候補者リストを生成しなくてもよい。
なお、生成されない候補者リストについては、例えば、管理装置１３における候補者抽出部３７３の該当する機能、管理装置１３における候補者リスト生成部３３６の該当する機能、端末装置における候補者リスト取得部の機能（例えば、需要側端末装置１１－１における候補者リスト取得部１５３、または、提供側端末装置１２－１における候補者リスト取得部２５３）は備えられなくてもよい。
【0126】
【0127】
＜候補者の情報提供の形式＞
図２～図４の例では、候補者の情報を候補者リストの形式で提供する場合について示しているが、候補者の情報は、他の任意の形式で提供されてもよく、例えば、マップを用いた形式などで提供されてもよい。
図２に示される候補者リスト取得部１５３、図３に示される候補者リスト取得部１５３、および、図４に示される候補者リスト生成部３３６は、それぞれ、リスト形式以外のマップを用いた形式などに対応していてもよい。
なお、このような場合、図２に示される候補者リスト取得部１５３、図３に示される候補者リスト取得部１５３、および、図４に示される候補者リスト生成部３３６は、それぞれ、他の任意の名称で呼ばれてもよく、例えば、（需要側端末装置の）候補者情報取得部、（提供側端末装置の）候補者情報取得部、（管理装置の）候補者情報生成部、などと呼ばれてもよい。
図２～図４の例では、候補者の情報を候補者リストの形式で提供する場合について示しているが、候補者の情報は、他の任意の形式で提供されてもよく、例えば、マップを用いた形式などで提供されてもよい。
図２に示される候補者リスト取得部１５３、図３に示される候補者リスト取得部１５３、および、図４に示される候補者リスト生成部３３６は、それぞれ、リスト形式以外のマップを用いた形式などに対応していてもよい。
なお、このような場合、図２に示される候補者リスト取得部１５３、図３に示される候補者リスト取得部１５３、および、図４に示される候補者リスト生成部３３６は、それぞれ、他の任意の名称で呼ばれてもよく、例えば、（需要側端末装置の）候補者情報取得部、（提供側端末装置の）候補者情報取得部、（管理装置の）候補者情報生成部、などと呼ばれてもよい。
【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】
概略的には、図８に示される画面１３１１の表示は、図５に示されるような平常時モードの画面表示から図６に示されるような災害時モードの画面表示へ移行するための表示である。
画面１３１１には、平常時内容領域１３３１と、表示切替指示領域１３５１と、が設けられている。
画面１３１１には、平常時内容領域１３３１と、表示切替指示領域１３５１と、が設けられている。
【0153】
平常時内容領域１３３１は、図５に示されるような平常時モードの表示の内容と同様な内容を表示するための領域である。図８の例では、平常時内容領域１３３１の表示内容は、図５に示される画面１０１１の表示内容と同様である。
【0154】
表示切替指示領域１３５１は、表示の切り替えを行う指示を受け付ける領域である。
図８の例では、表示切替指示領域１３５１には、災害時モード表示に切り替える旨が表示されているとともに、所定期間（例えば、３０分など）が経過した後にその切り替えが可能となる旨が表示されている。
なお、表示切替指示領域１３５１または他の領域には、例えば、発生した災害の緊急速報などに関する情報が含まれてもよい。
図８の例では、表示切替指示領域１３５１には、災害時モード表示に切り替える旨が表示されているとともに、所定期間（例えば、３０分など）が経過した後にその切り替えが可能となる旨が表示されている。
なお、表示切替指示領域１３５１または他の領域には、例えば、発生した災害の緊急速報などに関する情報が含まれてもよい。
【0155】
本実施形態では、図８に示される画面１３１１が表示されてから所定期間（例えば、３０分など）以上が経過し、図８に示される画面１３１１が表示された需要側端末装置１１－１～１１－ｎの需要側ユーザー２１－１～２１－ｎが、需要側端末装置１１－１～１１－ｎの操作部（図２の例では、操作部１３１）を操作して、表示切替指示領域１３５１を操作すると、その旨が通信部１１３により管理装置１３に送信されて通知される。
これに応じて、管理装置１３では、取引サービス提供部３３１が、需要側端末装置１１－１～１１－ｎに表示させる画面を、図６に示される画面１１１１に切り替える処理を行う。
これに応じて、管理装置１３では、取引サービス提供部３３１が、需要側端末装置１１－１～１１－ｎに表示させる画面を、図６に示される画面１１１１に切り替える処理を行う。
【0156】
ここで、所定期間の経過の開始時間としては、任意な態様が用いられてもよい。
一例として、所定期間の経過の開始時間として、災害の発生後に、需要側ユーザー２１－１～２１－ｎが需要側端末装置１１－１～１１－ｎの操作部（図２の例では、操作部１３１）を操作して、需要側端末装置１１－１～１１－ｎに所定の処理を行わせた時間が用いられてもよい。当該所定の処理としては、特に限定はなく、例えば、需要情報を管理装置１３に送信する処理であってもよい。
他の例として、所定期間の経過の開始時間として、災害が発生した時間が用いられてもよい。
一例として、所定期間の経過の開始時間として、災害の発生後に、需要側ユーザー２１－１～２１－ｎが需要側端末装置１１－１～１１－ｎの操作部（図２の例では、操作部１３１）を操作して、需要側端末装置１１－１～１１－ｎに所定の処理を行わせた時間が用いられてもよい。当該所定の処理としては、特に限定はなく、例えば、需要情報を管理装置１３に送信する処理であってもよい。
他の例として、所定期間の経過の開始時間として、災害が発生した時間が用いられてもよい。
【0157】
本実施形態では、管理装置１３では、取引サービス提供部３３１が、所定期間の経過の計時を行う。
また、本例の構成が複数の需要側ユーザー２１－１～２１－ｎ（複数の需要側端末装置１１－１～１１－ｎ）に適用される場合、例えば、所定期間として、それぞれの需要側ユーザー２１－１～２１－ｎごと（それぞれの需要側端末装置１１－１～１１－ｎごと）に、任意の期間が設定され得る構成が用いられてもよい。
また、本例の構成が複数の需要側ユーザー２１－１～２１－ｎ（複数の需要側端末装置１１－１～１１－ｎ）に適用される場合、例えば、所定期間として、それぞれの需要側ユーザー２１－１～２１－ｎごと（それぞれの需要側端末装置１１－１～１１－ｎごと）に、任意の期間が設定され得る構成が用いられてもよい。
【0158】
当該期間としては、例えば、支援を受ける緊急度が高いこと、被害の状況が大きいこと、あるいは、基本属性として所定の事由（例えば、高齢であるなどの事由）があること、などに応じて、短い期間が設定されてもよい。
また、当該期間としては、例えば、被災者の優先度スコアに応じて設定されてもよく、優先度スコアが高い方が短い期間が設定されてもよい。
なお、当該期間が０である場合があってもよく、この場合、図８に示される画面１３１１の表示の代わりに、図７に示される画面１２１１の表示が用いられてもよい。
また、当該期間としては、例えば、被災者の優先度スコアに応じて設定されてもよく、優先度スコアが高い方が短い期間が設定されてもよい。
なお、当該期間が０である場合があってもよく、この場合、図８に示される画面１３１１の表示の代わりに、図７に示される画面１２１１の表示が用いられてもよい。
【0159】
図８に示される画面１３１１が用いられる場合、例えば、需要側ユーザー２１－１～２１－ｎは、図６に示されるような災害時モードの画面表示を希望するときに、自分に設定された期間が経過した後に所定の操作を行うことで、図６に示されるような災害時モードの画面表示を閲覧して、支援を求めることが可能である。
なお、ここでは、図８に示される画面１３１１の表示から図６に示されるような災害時モードの画面表示への切り替えについて説明したが、例えば、図６に示されるような災害時モードの画面に所定の領域を設けて、需要側ユーザー２１－１～２１－ｎが当該領域の操作を行ったことに応じて、図７に示される画面１２１１の表示（または、図８に示される画面１３１１の表示でもよい。）へ移行することが可能な構成が用いられてもよい。
なお、ここでは、図８に示される画面１３１１の表示から図６に示されるような災害時モードの画面表示への切り替えについて説明したが、例えば、図６に示されるような災害時モードの画面に所定の領域を設けて、需要側ユーザー２１－１～２１－ｎが当該領域の操作を行ったことに応じて、図７に示される画面１２１１の表示（または、図８に示される画面１３１１の表示でもよい。）へ移行することが可能な構成が用いられてもよい。
【0160】
＜災害時モードにおける表示の変形例＞
図８の例では、所定期間が経過した後に、需要側ユーザー２１－１～２１－ｎが所定の操作を行った場合に、管理装置１３が該当する需要側ユーザー２１－１～２１－ｎの需要側端末装置１１－１～１１－ｎの表示を図６に示されるような災害時モード表示に切り替える構成例を示したが、他の例として、所定期間が経過したときに、自動的に、管理装置１３が該当する需要側ユーザー２１－１～２１－ｎの需要側端末装置１１－１～１１－ｎの表示を図６に示されるような災害時モード表示に切り替える構成が用いられてもよい。
図８の例では、所定期間が経過した後に、需要側ユーザー２１－１～２１－ｎが所定の操作を行った場合に、管理装置１３が該当する需要側ユーザー２１－１～２１－ｎの需要側端末装置１１－１～１１－ｎの表示を図６に示されるような災害時モード表示に切り替える構成例を示したが、他の例として、所定期間が経過したときに、自動的に、管理装置１３が該当する需要側ユーザー２１－１～２１－ｎの需要側端末装置１１－１～１１－ｎの表示を図６に示されるような災害時モード表示に切り替える構成が用いられてもよい。
【0161】
＜災害時モードにおける表示の例：被災者の候補者リスト＞
図６～図８を参照して、需要側ユーザー２１－１～２１－ｎ（需要側端末装置１１－１～１１－ｎ）の災害時モードにおける表示の例を説明したが、提供側ユーザー２２－１～２２－ｍ（提供側端末装置１２－１～１２－ｍ）の災害時モードにおける表示についても、同様な構成が適用されてもよい。
図６～図８を参照して、需要側ユーザー２１－１～２１－ｎ（需要側端末装置１１－１～１１－ｎ）の災害時モードにおける表示の例を説明したが、提供側ユーザー２２－１～２２－ｍ（提供側端末装置１２－１～１２－ｍ）の災害時モードにおける表示についても、同様な構成が適用されてもよい。
【0162】
例えば、図６の例と同様な画面が提供側ユーザー２２－１～２２－ｍ（提供側端末装置１２－１～１２－ｍ）に適用されてもよい。
ここで、提供側ユーザー２２－１の提供側端末装置１２－１に図６の例と同様な画面が適用される場合、例えば、画面の支援内容領域には、提供側ユーザー２２－１～２２－ｍに対して管理装置１３の候補者リスト生成部３３６によって生成された需要側ユーザー２１－１～２１－ｎの候補者リストに含まれる候補者が希望する支援内容が表示される。
ここで、提供側ユーザー２２－１の提供側端末装置１２－１に図６の例と同様な画面が適用される場合、例えば、画面の支援内容領域には、提供側ユーザー２２－１～２２－ｍに対して管理装置１３の候補者リスト生成部３３６によって生成された需要側ユーザー２１－１～２１－ｎの候補者リストに含まれる候補者が希望する支援内容が表示される。
【0163】
また、図７の例と同様な画面が提供側ユーザー２２－１～２２－ｍ（提供側端末装置１２－１～１２－ｍ）に適用されてもよい。
【0164】
また、図８の例と同様な画面が提供側ユーザー２２－１～２２－ｍ（提供側端末装置１２－１～１２－ｍ）に適用されてもよい。
この場合、所定期間の経過の開始時間として、例えば、災害の発生後に、提供側ユーザー２２－１～２２－ｍが提供側端末装置１２－１～１２－ｍの操作部（図３の例では、操作部２３１）を操作して、提供側端末装置１２－１～１２－ｍに所定の処理を行わせた時間が用いられてもよい。当該所定の処理としては、特に限定はなく、例えば、提供情報を管理装置１３に送信する処理であってもよい。
他の例として、所定期間の経過の開始時間として、災害が発生した時間が用いられてもよい。
この場合、所定期間の経過の開始時間として、例えば、災害の発生後に、提供側ユーザー２２－１～２２－ｍが提供側端末装置１２－１～１２－ｍの操作部（図３の例では、操作部２３１）を操作して、提供側端末装置１２－１～１２－ｍに所定の処理を行わせた時間が用いられてもよい。当該所定の処理としては、特に限定はなく、例えば、提供情報を管理装置１３に送信する処理であってもよい。
他の例として、所定期間の経過の開始時間として、災害が発生した時間が用いられてもよい。
【0165】
また、図８の変形例と同様な構成が、提供側ユーザー２２－１～２２－ｍ（提供側端末装置１２－１～１２－ｍ）に適用されてもよい。
【0166】
＜平常時モードおよび災害時モードにおける支援者と被災者との切り替え＞
図１の例では、説明を簡易化するために、被災者（需要側ユーザー２１－１～２１－ｎ）と支援者（提供側ユーザー２２－１～２２－ｍ）とを区別して示しているが、例えば、平常時モードおよび災害時モードにおいて、それぞれのユーザーは需要者（落札者または被災者）として利用することと提供者（出品者または支援者）として利用することとを任意に選択することが可能である。例えば、ユーザーが端末装置の操作部を操作することで、これらを選択する指示が当該端末装置から管理装置１３に送信され、これにより、管理装置１３の取引サービス提供部３３１が当該ユーザーに提供する画面内容を切り替えてもよい。
図１の例では、説明を簡易化するために、被災者（需要側ユーザー２１－１～２１－ｎ）と支援者（提供側ユーザー２２－１～２２－ｍ）とを区別して示しているが、例えば、平常時モードおよび災害時モードにおいて、それぞれのユーザーは需要者（落札者または被災者）として利用することと提供者（出品者または支援者）として利用することとを任意に選択することが可能である。例えば、ユーザーが端末装置の操作部を操作することで、これらを選択する指示が当該端末装置から管理装置１３に送信され、これにより、管理装置１３の取引サービス提供部３３１が当該ユーザーに提供する画面内容を切り替えてもよい。
【0167】
＜需要側テーブル＞
図９は、実施形態に係る需要側テーブル２０１１の構成の一例を示す図である。
需要側テーブル２０１１は、管理装置１３において、記憶部３１４に記憶されて管理される。
需要側テーブル２０１１は、例えば、需要側ユーザー２１－１～２１－ｎに関して、属性情報、需要情報、および位置の情報などの情報を格納する。
図９は、実施形態に係る需要側テーブル２０１１の構成の一例を示す図である。
需要側テーブル２０１１は、管理装置１３において、記憶部３１４に記憶されて管理される。
需要側テーブル２０１１は、例えば、需要側ユーザー２１－１～２１－ｎに関して、属性情報、需要情報、および位置の情報などの情報を格納する。
【0168】
図９の例では、需要側テーブル２０１１は、それぞれの需要側ユーザー２１－１～２１－ｎごとに、氏名と、優先度スコアと、商品／役務と、現在地と、を対応付けて格納している。
【0169】
氏名は、それぞれの需要側ユーザー２１－１～２１－ｎの氏名を表す。なお、氏名とともに、または、氏名の代わりに、それぞれの需要側ユーザー２１－１～２１－ｎを識別する識別情報が需要側テーブル２０１１に格納されてもよい。
ここで、氏名の情報および識別情報は、例えば、属性情報の一例である。
ここで、氏名の情報および識別情報は、例えば、属性情報の一例である。
【0170】
優先度スコアは、それぞれの需要側ユーザー２１－１～２１－ｎについて、需要者スコア算出部３７１によって算出された優先度スコアを表す。
本実施形態では、優先度スコアとして、点数を表す値が用いられている。
なお、本実施形態では、それぞれの需要側ユーザー２１－１～２１－ｎには自己の優先度スコアが知らされない構成となっており、例えば、それぞれの需要側ユーザー２１－１～２１－ｎの需要側端末装置１１－１～１１－ｎにはそれぞれの需要側ユーザー２１－１～２１－ｎの優先度スコアが管理装置１３から通知されない構成、あるいは、それぞれの需要側ユーザー２１－１～２１－ｎの需要側端末装置１１－１～１１－ｎにそれぞれの需要側ユーザー２１－１～２１－ｎの優先度スコアが管理装置１３から通知されても出力（表示など）されない構成となっている。
ただし、他の構成例として、それぞれの需要側ユーザー２１－１～２１－ｎが自己の優先度スコアを知り得る構成が用いられてもよく、例えば、それぞれの需要側ユーザー２１－１～２１－ｎの需要側端末装置１１－１～１１－ｎにそれぞれの需要側ユーザー２１－１～２１－ｎの優先度スコアが管理装置１３から通知されて出力（表示など）される構成が用いられてもよい。
本実施形態では、優先度スコアとして、点数を表す値が用いられている。
なお、本実施形態では、それぞれの需要側ユーザー２１－１～２１－ｎには自己の優先度スコアが知らされない構成となっており、例えば、それぞれの需要側ユーザー２１－１～２１－ｎの需要側端末装置１１－１～１１－ｎにはそれぞれの需要側ユーザー２１－１～２１－ｎの優先度スコアが管理装置１３から通知されない構成、あるいは、それぞれの需要側ユーザー２１－１～２１－ｎの需要側端末装置１１－１～１１－ｎにそれぞれの需要側ユーザー２１－１～２１－ｎの優先度スコアが管理装置１３から通知されても出力（表示など）されない構成となっている。
ただし、他の構成例として、それぞれの需要側ユーザー２１－１～２１－ｎが自己の優先度スコアを知り得る構成が用いられてもよく、例えば、それぞれの需要側ユーザー２１－１～２１－ｎの需要側端末装置１１－１～１１－ｎにそれぞれの需要側ユーザー２１－１～２１－ｎの優先度スコアが管理装置１３から通知されて出力（表示など）される構成が用いられてもよい。
【0171】
商品／役務は、それぞれの需要側ユーザー２１－１～２１－ｎが支援を希望している内容として、商品と役務との一方または両方を表す。
なお、例えば、商品の情報に、商品の量の情報が含まれていてもよい。
また、例えば、役務の情報に、役務の時間の情報が含まれていてもよい。
ここで、希望する支援の内容の情報は、例えば、需要情報の一例である。
なお、例えば、商品の情報に、商品の量の情報が含まれていてもよい。
また、例えば、役務の情報に、役務の時間の情報が含まれていてもよい。
ここで、希望する支援の内容の情報は、例えば、需要情報の一例である。
【0172】
現在地は、それぞれの需要側ユーザー２１－１～２１－ｎの現在の位置（それぞれの需要側端末装置１１－１～１１－ｎの現在の位置）を表す。
ここで、現在地は、必ずしも厳密な現在地でなくてもよく、例えば、過去のなかで最も最新に取得された位置であってもよい。なお、例えば、過去のなかで最も最新に取得された位置の取得時間から所定の期間が経過している場合には、現在地は不明であるとみなされてもよい。
ここで、現在地は、必ずしも厳密な現在地でなくてもよく、例えば、過去のなかで最も最新に取得された位置であってもよい。なお、例えば、過去のなかで最も最新に取得された位置の取得時間から所定の期間が経過している場合には、現在地は不明であるとみなされてもよい。
【0173】
なお、図９の例では、需要側テーブル２０１１に格納される情報について概略的な例を示してあり、需要側テーブル２０１１に格納される情報としては様々な情報が用いられてもよい。
【0174】
＜提供側テーブル＞
図１０は、実施形態に係る提供側テーブル２０３１の構成の一例を示す図である。
提供側テーブル２０３１は、管理装置１３において、記憶部３１４に記憶されて管理される。
提供側テーブル２０３１は、例えば、提供側ユーザー２２－１～２２－ｍに関して、属性情報、提供情報、および位置の情報などの情報を格納する。
図１０は、実施形態に係る提供側テーブル２０３１の構成の一例を示す図である。
提供側テーブル２０３１は、管理装置１３において、記憶部３１４に記憶されて管理される。
提供側テーブル２０３１は、例えば、提供側ユーザー２２－１～２２－ｍに関して、属性情報、提供情報、および位置の情報などの情報を格納する。
【0175】
図１０の例では、提供側テーブル２０３１は、それぞれの提供側ユーザー２２－１～２２－ｍごとに、氏名と、商品／役務と、行動範囲と、現在地と、を対応付けて格納している。
【0176】
氏名は、それぞれの提供側ユーザー２２－１～２２－ｍの氏名を表す。なお、氏名とともに、または、氏名の代わりに、それぞれの提供側ユーザー２２－１～２２－ｍを識別する識別情報が提供側テーブル２０３１に格納されてもよい。
ここで、氏名の情報および識別情報は、例えば、属性情報の一例である。
ここで、氏名の情報および識別情報は、例えば、属性情報の一例である。
【0177】
商品／役務は、それぞれの提供側ユーザー２２－１～２２－ｍが提供することが可能な支援の内容として、商品と役務との一方または両方を表す。
なお、例えば、商品の情報に、商品の量の情報が含まれていてもよい。
また、例えば、役務の情報に、役務の時間の情報が含まれていてもよい。
ここで、提供することが可能な支援の内容の情報は、例えば、提供情報の一例である。
なお、例えば、商品の情報に、商品の量の情報が含まれていてもよい。
また、例えば、役務の情報に、役務の時間の情報が含まれていてもよい。
ここで、提供することが可能な支援の内容の情報は、例えば、提供情報の一例である。
【0178】
行動範囲は、それぞれの提供側ユーザー２２－１～２２－ｍが支援の内容を提供する際に行動することが可能な範囲を表す。
ここで、支援の内容を提供する際に行動することが可能な範囲の情報は、例えば、提供情報の一例である。
ここで、支援の内容を提供する際に行動することが可能な範囲の情報は、例えば、提供情報の一例である。
【0179】
現在地は、それぞれの提供側ユーザー２２－１～２２－ｍの現在の位置（それぞれの提供側端末装置１２－１～１２－ｍの現在の位置）を表す。
ここで、現在地は、必ずしも厳密な現在地でなくてもよく、例えば、過去のなかで最も最新に取得された位置であってもよい。なお、例えば、過去のなかで最も最新に取得された位置の取得時間から所定の期間が経過している場合には、現在地は不明であるとみなされてもよい。
ここで、現在地は、必ずしも厳密な現在地でなくてもよく、例えば、過去のなかで最も最新に取得された位置であってもよい。なお、例えば、過去のなかで最も最新に取得された位置の取得時間から所定の期間が経過している場合には、現在地は不明であるとみなされてもよい。
【0180】
なお、図１０の例では、提供側テーブル２０３１に格納される情報について概略的な例を示してあり、提供側テーブル２０３１に格納される情報としては様々な情報が用いられてもよい。
【0181】
＜被災者の優先度スコアの算出＞
図１１は、実施形態に係る優先度スコアの算出ロジックの例を示す図である。
図１１には、被災者（需要側ユーザー２１－１～２１－ｎ）の優先度スコアの算出ロジックの例を表すテーブル（算出ロジックテーブル２１１１）を示してある。
本実施形態では、管理装置１３のマッチング部３３５（需要者スコア算出部３７１）が、算出ロジックを使用して、優先度スコアを算出する。
図１１は、実施形態に係る優先度スコアの算出ロジックの例を示す図である。
図１１には、被災者（需要側ユーザー２１－１～２１－ｎ）の優先度スコアの算出ロジックの例を表すテーブル（算出ロジックテーブル２１１１）を示してある。
本実施形態では、管理装置１３のマッチング部３３５（需要者スコア算出部３７１）が、算出ロジックを使用して、優先度スコアを算出する。
【0182】
算出ロジックテーブル２１１１には、評価軸と、評価指標と、スコアが低い場合と、スコアが中程度である場合と、スコアが高い場合と、の対応を示してある。
なお、同じ評価指標であっても、支援（需要）の内容によって、優先度スコアの算出ロジックが異なる場合があり得る。
なお、同じ評価指標であっても、支援（需要）の内容によって、優先度スコアの算出ロジックが異なる場合があり得る。
【0183】
（１）評価軸である「登録時の属性」について説明する。
本実施形態では、「登録時の属性」の情報は、需要側ユーザー２１－１～２１－ｎの属性情報として登録される。
本実施形態では、「登録時の属性」の情報は、需要側ユーザー２１－１～２１－ｎの属性情報として登録される。
【0184】
評価指標である「家族構成」では、例えば、家族人数が少ないよりも、家族人数が多い方が、優先度スコアを高くする算出ロジック、または、家族人数が多いよりも、家族人数が少ない方が、優先度スコアを高くする算出ロジックが用いられる。
具体例として、支援の内容が食料である場合、家族人数が少ない方が消費が少なくなるため、家族人数が少ないよりも、家族人数が多い方が、優先度スコアを高くする算出ロジックが用いられてもよい。
一方、支援の内容が土砂災害時の土砂のかき出しである場合、家族人数が少ない方が対応困難であるため、家族人数が多いよりも、家族人数が少ない方が、優先度スコアを高くする算出ロジックが用いられてもよい。
具体例として、支援の内容が食料である場合、家族人数が少ない方が消費が少なくなるため、家族人数が少ないよりも、家族人数が多い方が、優先度スコアを高くする算出ロジックが用いられてもよい。
一方、支援の内容が土砂災害時の土砂のかき出しである場合、家族人数が少ない方が対応困難であるため、家族人数が多いよりも、家族人数が少ない方が、優先度スコアを高くする算出ロジックが用いられてもよい。
【0185】
評価指標である「年齢・性別」では、例えば、成人男性である場合、乳幼児がいる場合、高齢者である場合の順に、優先度スコアを低くする、優先度スコアを中程度とする、優先度スコアを高くする、という算出ロジックが用いられる。
なお、これらの場合について、他の優先度スコアの算出ロジックが用いられてもよい。
なお、これらの場合について、他の優先度スコアの算出ロジックが用いられてもよい。
【0186】
評価指標である「防災状況」では、例えば、備蓄有りおよび自家発電可の場合と、これらが中程度である場合と、防災対応無しの場合の順に、優先度スコアを低くする、優先度スコアを中程度とする、優先度スコアを高くする、という算出ロジックが用いられてもよい。
なお、これらの場合について、他の優先度スコアの算出ロジックが用いられてもよい。
なお、これらの場合について、他の優先度スコアの算出ロジックが用いられてもよい。
【0187】
（２）評価軸である「被害状況」について説明する。
本実施形態では、「被害状況」の情報は、需要側ユーザー２１－１～２１－ｎの需要情報として登録される。
本実施形態では、「被害状況」の情報は、需要側ユーザー２１－１～２１－ｎの需要情報として登録される。
【0188】
評価指標である「怪我」では、例えば、軽傷である場合、中傷がいる場合、重症である場合の順に、優先度スコアを低くする、優先度スコアを中程度とする、優先度スコアを高くする、という算出ロジックが用いられる。
なお、これらの場合について、他の優先度スコアの算出ロジックが用いられてもよい。
なお、これらの場合について、他の優先度スコアの算出ロジックが用いられてもよい。
【0189】
評価指標である「周辺状況」では、例えば、倒木しそうである場合、倒木により玄関があかない場合、倒木により道路分断の場合の順に、優先度スコアを低くする、優先度スコアを中程度とする、優先度スコアを高くする、という算出ロジックが用いられる。
なお、これらの場合について、他の優先度スコアの算出ロジックが用いられてもよい。
なお、これらの場合について、他の優先度スコアの算出ロジックが用いられてもよい。
【0190】
評価指標である「インフラ被害状況」では、例えば、計画停電の場合、一部世帯で断水・停電の場合、地域一帯で断水・停電の場合の順に、優先度スコアを低くする、優先度スコアを中程度とする、優先度スコアを高くする、という算出ロジックが用いられる。
なお、これらの場合について、他の優先度スコアの算出ロジックが用いられてもよい。
なお、これらの場合について、他の優先度スコアの算出ロジックが用いられてもよい。
【0191】
（３）評価軸である「行動範囲」について説明する。
本実施形態では、「行動範囲」の情報は、需要側ユーザー２１－１～２１－ｎの需要情報として登録される。
本実施形態では、「行動範囲」の情報は、需要側ユーザー２１－１～２１－ｎの需要情報として登録される。
【0192】
評価指標である「被災状況による移動可能度合い」では、例えば、遠方への移動が可能よりも、被災により移動不可の方が、優先度スコアを高くする算出ロジックが用いられる。
なお、これらの場合について、他の優先度スコアの算出ロジックが用いられてもよい。
なお、これらの場合について、他の優先度スコアの算出ロジックが用いられてもよい。
【0193】
（４）評価軸である「需要と供給のバランス」について説明する。
本実施形態では、「需要と供給のバランス」の情報は、管理装置１３のマッチング部３３５により、需要側ユーザー２１－１～２１－ｎの情報および提供側ユーザー２２－１～２２－ｍの情報に基づいて決定（例えば、判定）される。
本実施形態では、「需要と供給のバランス」の情報は、管理装置１３のマッチング部３３５により、需要側ユーザー２１－１～２１－ｎの情報および提供側ユーザー２２－１～２２－ｍの情報に基づいて決定（例えば、判定）される。
【0194】
評価指標である「需要内容の希少性」では、例えば、供給が多い状態（つまり、提供者が多い状態）よりも、供給が少ない状態（つまり、提供者が少ない状態）の方が、優先度スコアを高くする算出ロジックが用いられる。
なお、これらの場合について、他の優先度スコアの算出ロジックが用いられてもよい。
ここで、提供者（該当する提供側ユーザー）が多いか少ないかを判定する手法としては、特に限定はなく、例えば、提供者の数が所定の閾値以上である（または、所定の閾値を超える）場合に提供者が多いと判定し、他の場合には提供者が少ないと判定する手法が用いられてもよい。
なお、これらの場合について、他の優先度スコアの算出ロジックが用いられてもよい。
ここで、提供者（該当する提供側ユーザー）が多いか少ないかを判定する手法としては、特に限定はなく、例えば、提供者の数が所定の閾値以上である（または、所定の閾値を超える）場合に提供者が多いと判定し、他の場合には提供者が少ないと判定する手法が用いられてもよい。
【0195】
評価指標である「地域復興における同じ需要ニーズの量」では、例えば、需要が少ない状態（つまり、需要者が少ない状態）よりも、需要が多い状態（つまり、需要者が多い状態）の方が、優先度スコアを高くする算出ロジックが用いられる。
なお、これらの場合について、他の優先度スコアの算出ロジックが用いられてもよい。
ここで、需要者（該当する需要側ユーザー）が多いか少ないかを判定する手法としては、特に限定はなく、例えば、需要者の数が所定の閾値以上である（または、所定の閾値を超える）場合に需要者が多いと判定し、他の場合には需要者が少ないと判定する手法が用いられてもよい。
なお、これらの場合について、他の優先度スコアの算出ロジックが用いられてもよい。
ここで、需要者（該当する需要側ユーザー）が多いか少ないかを判定する手法としては、特に限定はなく、例えば、需要者の数が所定の閾値以上である（または、所定の閾値を超える）場合に需要者が多いと判定し、他の場合には需要者が少ないと判定する手法が用いられてもよい。
【0196】
（５）評価軸である「被災エリア」について説明する。
本実施形態では、「被災エリア」の情報は、管理装置１３のマッチング部３３５により、需要側ユーザー２１－１～２１－ｎの情報に基づいて決定（例えば、判定）される。
本実施形態では、「被災エリア」の情報は、管理装置１３のマッチング部３３５により、需要側ユーザー２１－１～２１－ｎの情報に基づいて決定（例えば、判定）される。
【0197】
評価指標である「被災地に近い人（需要者）」では、例えば、需要者（被災者）が被災地から遠い状態よりも、需要者（被災者）が被災地に近い状態の方が、優先度スコアを高くする算出ロジックが用いられる。
なお、これらの場合について、他の優先度スコアの算出ロジックが用いられてもよい。
なお、これらの場合について、他の優先度スコアの算出ロジックが用いられてもよい。
【0198】
ここで、需要者（需要側ユーザー２１－１～２１－ｎ）が被災地に近いか遠いかを判定する手法としては、特に限定はなく、例えば、当該需要者の位置と被災地との距離が所定の閾値以上である（または、所定の閾値を超える）場合に被災地から遠いと判定し、他の場合には被災地から近いと判定する手法が用いられてもよい。
被災地の情報は、任意の手法により取得されてもよく、例えば、所定機関によって提供される災害情報に基づいて取得されてもよい。本実施形態では、管理装置１３のマッチング部３３５が、被災地の情報を取得する。
被災地の情報は、任意の手法により取得されてもよく、例えば、所定機関によって提供される災害情報に基づいて取得されてもよい。本実施形態では、管理装置１３のマッチング部３３５が、被災地の情報を取得する。
【0199】
需要者の位置と被災地との距離としては、例えば、直線距離が用いられてもよく、移動可能なルート（例えば、道）に沿った距離が用いられてもよく、あるいは、他の距離が用いられてもよい。
例えば、平常時には移動可能なルートであっても、災害時において、一部が移動不可能なルートになった場合には、移動可能な他のルートが用いられる。
例えば、平常時には移動可能なルートであっても、災害時において、一部が移動不可能なルートになった場合には、移動可能な他のルートが用いられる。
【0200】
ここで、本実施形態では、優先度スコアを算出するための算出ロジックは、あらかじめ設定されており、管理装置１３（例えば、記憶部３１４など）に記憶されている。
なお、図１１に示される算出ロジックテーブル２１１１に示される優先度スコアの算出ロジックは例示であり、他の算出ロジックが使用されてもよい。
なお、図１１に示される算出ロジックテーブル２１１１に示される優先度スコアの算出ロジックは例示であり、他の算出ロジックが使用されてもよい。
【0201】
例えば、評価軸である「登録時の属性」における評価指標として「オンラインのコミュニティ」あるいは「リアルなコミュニティ」が用いられてもよい。
「オンラインのコミュニティ」としては、例えば、自治体および町内会などの地域、職場、または学校などのオンラインのコミュニティが用いられてもよく、あるいは、ソーシャルネットワークでのコミュニティが用いられてもよい。
「リアルなコミュニティ」としては、例えば、自治体および町内会などの地域、職場、または学校などの現実のコミュニティが用いられてもよい。
「オンラインのコミュニティ」としては、例えば、自治体および町内会などの地域、職場、または学校などのオンラインのコミュニティが用いられてもよく、あるいは、ソーシャルネットワークでのコミュニティが用いられてもよい。
「リアルなコミュニティ」としては、例えば、自治体および町内会などの地域、職場、または学校などの現実のコミュニティが用いられてもよい。
【0202】
例えば、支援の内容に応じて、優先度スコアを調整する態様が用いられてもよい。
具体例として、支援の内容（物資）が食料あるいは飲料である場合に、支援の内容（物資）が雑貨である場合と比べて、優先度スコアを高くするような算出ロジックが用いられてもよい。
また、具体例として、支援の内容（役務）が救助である場合に、支援の内容（役務）が掃除である場合と比べて、優先度スコアを高くするような算出ロジックが用いられてもよい。
また、支援の内容（物資）と支援の内容（役務）との間でも、優先度スコアを異ならせる算出ロジックが用いられてもよい。
このように、支援の内容について緊急度が高いと考えらえる場合の方が優先度スコアを高くするような態様が用いられてもよい。
具体例として、支援の内容（物資）が食料あるいは飲料である場合に、支援の内容（物資）が雑貨である場合と比べて、優先度スコアを高くするような算出ロジックが用いられてもよい。
また、具体例として、支援の内容（役務）が救助である場合に、支援の内容（役務）が掃除である場合と比べて、優先度スコアを高くするような算出ロジックが用いられてもよい。
また、支援の内容（物資）と支援の内容（役務）との間でも、優先度スコアを異ならせる算出ロジックが用いられてもよい。
このように、支援の内容について緊急度が高いと考えらえる場合の方が優先度スコアを高くするような態様が用いられてもよい。
【0203】
また、例えば、被災者の端末装置の画面表示が平常時モードの画面表示から災害時モードの画面表示（例えば、図６に示されるような画面表示など）へ切り替わった時間の情報が、優先度スコアの算出ロジックに用いられてもよい。
例えば、平常時モードの画面表示から災害時モードの画面表示（例えば、図６に示されるような画面表示など）へ切り替わった時間が早い方が優先度スコアを高くするような算出ロジックが使用されてもよい。
例えば、平常時モードの画面表示から災害時モードの画面表示（例えば、図６に示されるような画面表示など）へ切り替わった時間が早い方が優先度スコアを高くするような算出ロジックが使用されてもよい。
【0204】
ここで、管理装置１３のマッチング部３３５（需要者スコア算出部３７１）は、例えば、２以上の算出ロジックを組み合わせて、優先度スコアを算出してもよい。
２以上の算出ロジックが組み合わされた場合の算出ロジック（全体的な算出ロジック）としては、様々な態様が用いられてもよく、例えば、２以上の算出ロジックのそれぞれで算出される優先度スコアについて所定の演算（例えば、乗算）を行った結果を最終的な優先度スコアとする態様が用いられてもよい。
２以上の算出ロジックが組み合わされた場合の算出ロジック（全体的な算出ロジック）としては、様々な態様が用いられてもよく、例えば、２以上の算出ロジックのそれぞれで算出される優先度スコアについて所定の演算（例えば、乗算）を行った結果を最終的な優先度スコアとする態様が用いられてもよい。
【0205】
なお、図１１に示されるような情報の一部または全部が、図９に示される需要側テーブル２０１１に格納されていてもよい。
同様に、図１０に示される提供側テーブル２０３１においても、図１１に示されるような情報の一部または全部と同様な情報が格納されてもよい。
同様に、図１０に示される提供側テーブル２０３１においても、図１１に示されるような情報の一部または全部と同様な情報が格納されてもよい。
【0206】
＜優先度スコアの算出の具体例＞
例えば、被災者について、図１１に示される各評価軸における評価指標の項目に関し、属性および被災状況に基づくランク分けを行い、これにより得られた複数のランクの値を掛け合わせた結果をスコア（優先度スコア）として取得することが行われてもよい。
ランクとしては、例えば、低い、中程度、高いなどのように離散的な値が用いられてもよく、あるいは、連続的に可変な値が用いられてもよい。
例えば、被災者について、図１１に示される各評価軸における評価指標の項目に関し、属性および被災状況に基づくランク分けを行い、これにより得られた複数のランクの値を掛け合わせた結果をスコア（優先度スコア）として取得することが行われてもよい。
ランクとしては、例えば、低い、中程度、高いなどのように離散的な値が用いられてもよく、あるいは、連続的に可変な値が用いられてもよい。
【0207】
優先度スコアの算出の具体例を（シナリオ１）～（シナリオ３）として示す。
それぞれのシナリオは、それぞれに対応した算出ロジックに基づいて優先度スコアを算出するシナリオである。
それぞれのシナリオは、それぞれに対応した算出ロジックに基づいて優先度スコアを算出するシナリオである。
【0208】
（シナリオ１）
需要者の家族構成および年齢・性別に関し、夫婦２人、子供２人である。本例では、１個の端末装置（需要側端末装置１１－１）によって、これら４人について、まとめて支援の要求があった場合を想定する。
被害状況に関し、発災当日である。
被害状況に関し、地震時に、家具の転倒により、夫と長男が怪我をしている。なお、生死に関わる怪我ではない。
防災状況に関し、食料備蓄は３日分程度しかしていない。このため、家での在宅避難は可能であるが、食料備蓄が無くなりそうである。
行動範囲に関し、生死に関わる怪我ではないが、避難所まで物資を取りに行く余裕はない。
需要者の家族構成および年齢・性別に関し、夫婦２人、子供２人である。本例では、１個の端末装置（需要側端末装置１１－１）によって、これら４人について、まとめて支援の要求があった場合を想定する。
被害状況に関し、発災当日である。
被害状況に関し、地震時に、家具の転倒により、夫と長男が怪我をしている。なお、生死に関わる怪我ではない。
防災状況に関し、食料備蓄は３日分程度しかしていない。このため、家での在宅避難は可能であるが、食料備蓄が無くなりそうである。
行動範囲に関し、生死に関わる怪我ではないが、避難所まで物資を取りに行く余裕はない。
【0209】
ここで、需要者は、食料（物資）の支援を希望している。
本例では、需要者が家族の分の食料の支援を希望しているとする。
管理装置１３のマッチング部３３５（需要者スコア算出部３７１）は、例えば、登録時の属性に関する算出ロジックによる優先度スコアＱ１と、被害状況に関する算出ロジックによる優先度スコアＱ２と、行動範囲に関する算出ロジックによる優先度スコアＱ３と、需要と供給のバランスに関する算出ロジックによる優先度スコアＱ４と、災害エリアに関する算出ロジックによる優先度スコアＱ５と、をすべて乗算することで、その演算結果（Ｑ１×Ｑ２×Ｑ３×Ｑ４×Ｑ５）を最終的な優先度スコアとする。
本例では、需要者が家族の分の食料の支援を希望しているとする。
管理装置１３のマッチング部３３５（需要者スコア算出部３７１）は、例えば、登録時の属性に関する算出ロジックによる優先度スコアＱ１と、被害状況に関する算出ロジックによる優先度スコアＱ２と、行動範囲に関する算出ロジックによる優先度スコアＱ３と、需要と供給のバランスに関する算出ロジックによる優先度スコアＱ４と、災害エリアに関する算出ロジックによる優先度スコアＱ５と、をすべて乗算することで、その演算結果（Ｑ１×Ｑ２×Ｑ３×Ｑ４×Ｑ５）を最終的な優先度スコアとする。
【0210】
本例では、最終的な優先度スコアには、家族の属性により食料の消費は１人暮らしに比べて多いこと、家族内に怪我人がおり行動制限がかかっていること、が反映される。
また、本例では、最終的な優先度スコアには、例えば、食料供給の応募が多いことが反映される。
これらのことから、比較的、最終的な優先度スコアは高くなり、例えば、最終的な優先度スコアに応じたマッチング候補（提供側の候補者）の選択および表示が行われる。
また、本例では、最終的な優先度スコアには、例えば、食料供給の応募が多いことが反映される。
これらのことから、比較的、最終的な優先度スコアは高くなり、例えば、最終的な優先度スコアに応じたマッチング候補（提供側の候補者）の選択および表示が行われる。
【0211】
（シナリオ２）
需要者の家族構成および年齢・性別に関し、夫婦２人（７０代）である。本例では、１個の端末装置（需要側端末装置１１－１）によって、これら２人について、まとめて支援の要求があった場合を想定する。
防災状況に関し、期たる災害に備えて、食料備蓄はたくさんしていた。このため、在宅避難はできると思っていた。
被害状況に関し、発災から２日後である。
被害状況に関し、予想以上に家内が散乱し、生活がままならない。
被害状況に関し、ある程度は片付けたが、冷蔵庫およびタンスなどについて、二人で作業することが難しい。
需要者の家族構成および年齢・性別に関し、夫婦２人（７０代）である。本例では、１個の端末装置（需要側端末装置１１－１）によって、これら２人について、まとめて支援の要求があった場合を想定する。
防災状況に関し、期たる災害に備えて、食料備蓄はたくさんしていた。このため、在宅避難はできると思っていた。
被害状況に関し、発災から２日後である。
被害状況に関し、予想以上に家内が散乱し、生活がままならない。
被害状況に関し、ある程度は片付けたが、冷蔵庫およびタンスなどについて、二人で作業することが難しい。
【0212】
ここで、需要者は、家具および家電の移動（役務）の支援を希望している。
管理装置１３のマッチング部３３５（需要者スコア算出部３７１）は、例えば、登録時の属性に関する算出ロジックによる優先度スコアＱ１１と、需要と供給のバランスに関する算出ロジックによる優先度スコアＱ１４と、災害エリアに関する算出ロジックによる優先度スコアＱ１５と、をすべて乗算することで、その演算結果（Ｑ１１×Ｑ１４×Ｑ１５）を最終的な優先度スコアとする。
管理装置１３のマッチング部３３５（需要者スコア算出部３７１）は、例えば、登録時の属性に関する算出ロジックによる優先度スコアＱ１１と、需要と供給のバランスに関する算出ロジックによる優先度スコアＱ１４と、災害エリアに関する算出ロジックによる優先度スコアＱ１５と、をすべて乗算することで、その演算結果（Ｑ１１×Ｑ１４×Ｑ１５）を最終的な優先度スコアとする。
【0213】
本例では、最終的な優先度スコアには、年齢の属性により高齢であること（例えば、若年層に比べて行動制限がかかっていること）が反映される。
また、本例では、最終的な優先度スコアには、例えば、災害時には物資以外の役務の提供者（ボランティアなど）も多いことが反映される。
また、本例では、最終的な優先度スコアには、例えば、震源地から近いこと、建物の内部の被害も大きいこと、が反映される。
これらのことから、比較的、最終的な優先度スコアは高くなり、例えば、最終的な優先度スコアに応じたマッチング候補（提供側の候補者）の選択および表示が行われる。
また、本例では、最終的な優先度スコアには、例えば、災害時には物資以外の役務の提供者（ボランティアなど）も多いことが反映される。
また、本例では、最終的な優先度スコアには、例えば、震源地から近いこと、建物の内部の被害も大きいこと、が反映される。
これらのことから、比較的、最終的な優先度スコアは高くなり、例えば、最終的な優先度スコアに応じたマッチング候補（提供側の候補者）の選択および表示が行われる。
【0214】
（シナリオ３）
被害状況に関し、発災から１週間後である。
地域復興における同じ需要ニーズの量に関し、被災地の同じエリア内で、倒木の処理の依頼（需要）が多い。
被害状況に関し、地域のメイン通りで、緊急車両の通行に影響をきたしている状況である。
被害状況に関し、発災から１週間後である。
地域復興における同じ需要ニーズの量に関し、被災地の同じエリア内で、倒木の処理の依頼（需要）が多い。
被害状況に関し、地域のメイン通りで、緊急車両の通行に影響をきたしている状況である。
【0215】
ここで、需要者は、地域復興（役務）の支援を希望している。
管理装置１３のマッチング部３３５（需要者スコア算出部３７１）は、例えば、被害状況に関する算出ロジックによる優先度スコアＱ２２と、行動範囲に関する算出ロジックによる優先度スコアＱ２３と、需要と供給のバランスに関する算出ロジックによる優先度スコアＱ２４と、災害エリアに関する算出ロジックによる優先度スコアＱ２５と、をすべて乗算することで、その演算結果（Ｑ２２×Ｑ２３×Ｑ２４×Ｑ２５）を最終的な優先度スコアとする。
管理装置１３のマッチング部３３５（需要者スコア算出部３７１）は、例えば、被害状況に関する算出ロジックによる優先度スコアＱ２２と、行動範囲に関する算出ロジックによる優先度スコアＱ２３と、需要と供給のバランスに関する算出ロジックによる優先度スコアＱ２４と、災害エリアに関する算出ロジックによる優先度スコアＱ２５と、をすべて乗算することで、その演算結果（Ｑ２２×Ｑ２３×Ｑ２４×Ｑ２５）を最終的な優先度スコアとする。
【0216】
本例では、最終的な優先度スコアには、依頼内容の解決によって緊急車両の通行改善および近隣との共助促進につながるという判断結果が反映される。このような判断は、例えば、管理装置１３のマッチング部３３５（需要者スコア算出部３７１）によって行われる。
これらのことから、比較的、最終的な優先度スコアは高くなり、例えば、最終的な優先度スコアに応じたマッチング候補（提供側の候補者）の選択および表示が行われる。
これらのことから、比較的、最終的な優先度スコアは高くなり、例えば、最終的な優先度スコアに応じたマッチング候補（提供側の候補者）の選択および表示が行われる。
【0217】
なお、（シナリオ１）～（シナリオ３）の内容は、説明のための例示であり、様々なシナリオの内容が用いられてもよい。
また、使用され得るシナリオの内容に応じて、当該シナリオで必要となる情報が図９に示される需要側テーブル２０１１（さらに、図１０に示される提供側テーブル２０３１が使用されてもよい。）に格納されてもよい。
また、使用され得るシナリオの内容に応じて、当該シナリオで必要となる情報が図９に示される需要側テーブル２０１１（さらに、図１０に示される提供側テーブル２０３１が使用されてもよい。）に格納されてもよい。
【0218】
＜被災者に対するマッチング候補表示の例＞
図１２は、実施形態に係る優先度スコアが高い被災者に対するマッチング候補表示の一例を示す図である。
図１２には、支援優先度（優先度スコア）が高い被災者に対するマッチング候補（提供側の候補者）の表示の一例を示してある。
図１２には、被災者Ａ１（本例では、家族である４人をまとめた被災者）の情報と、被災者Ａ１の端末装置（需要側端末装置）の画面Ｃ１と、第１の支援者（支援者Ｂ１）の情報と、第２の支援者（支援者Ｂ２）の情報と、第３の支援者（支援者Ｂ３）の情報を示してある。
図１２は、実施形態に係る優先度スコアが高い被災者に対するマッチング候補表示の一例を示す図である。
図１２には、支援優先度（優先度スコア）が高い被災者に対するマッチング候補（提供側の候補者）の表示の一例を示してある。
図１２には、被災者Ａ１（本例では、家族である４人をまとめた被災者）の情報と、被災者Ａ１の端末装置（需要側端末装置）の画面Ｃ１と、第１の支援者（支援者Ｂ１）の情報と、第２の支援者（支援者Ｂ２）の情報と、第３の支援者（支援者Ｂ３）の情報を示してある。
【0219】
なお、図１２の例は模式的な例であり、それぞれの支援者Ｂ１～Ｂ３の情報は画面Ｃ１に表示される。
本実施形態では、このような情報の表示が行われる状態が実現されるように、管理装置１３の取引サービス提供部３３１による制御が行われている。
本実施形態では、このような情報の表示が行われる状態が実現されるように、管理装置１３の取引サービス提供部３３１による制御が行われている。
【0220】
図１２の例では、被災者Ａ１の優先度スコアは９０点（０～１００点中）であり、優先度スコアが高いと判定されている。
被災者Ａ１は、数量４の水を希望しており、Ａ市に在住し、物資（ここでは、水）を取りに行くことができず、１日以内を希望している。
被災者Ａ１は、数量４の水を希望しており、Ａ市に在住し、物資（ここでは、水）を取りに行くことができず、１日以内を希望している。
【0221】
支援者Ｂ１は、数量４の水を提供することができ、Ａ市に在住し、物資（ここでは、水）を届けることが可能であり、１日以内の対応が可能である。
支援者Ｂ２は、数量３の水を提供することができ、Ａ市に在住し、物資（ここでは、水）の発送までの対応が可能であり、５日以内の対応が可能である。
支援者Ｂ３は、数量２の水を提供することができ、Ｂ市に在住し、物資（ここでは、水）の発送までの対応が可能であり、２日以内の対応が可能である。
支援者Ｂ２は、数量３の水を提供することができ、Ａ市に在住し、物資（ここでは、水）の発送までの対応が可能であり、５日以内の対応が可能である。
支援者Ｂ３は、数量２の水を提供することができ、Ｂ市に在住し、物資（ここでは、水）の発送までの対応が可能であり、２日以内の対応が可能である。
【0222】
図１２の例では、被災者Ａ１にとって、支援者Ｂ１とのマッチング度が最も高い。
また、被災者Ａ１にとって、支援者Ｂ２とのマッチング度および支援者Ｂ３とのマッチング度も比較的高いが、これらは支援者Ｂ１とのマッチング度よりは低い。
なお、本例では、これらのマッチング度は、例えば、被災者と支援者との距離および支援の内容の一致度（需要と供給との一致度）に基づいており、被災者Ａ１の優先度スコアまたはその判定結果が考慮されていないマッチング度であるが、他の態様が用いられてもよい。
また、被災者Ａ１にとって、支援者Ｂ２とのマッチング度および支援者Ｂ３とのマッチング度も比較的高いが、これらは支援者Ｂ１とのマッチング度よりは低い。
なお、本例では、これらのマッチング度は、例えば、被災者と支援者との距離および支援の内容の一致度（需要と供給との一致度）に基づいており、被災者Ａ１の優先度スコアまたはその判定結果が考慮されていないマッチング度であるが、他の態様が用いられてもよい。
【0223】
図１３は、実施形態に係る優先度スコアが低い被災者に対するマッチング候補表示の一例を示す図である。
図１３には、支援優先度（優先度スコア）が低い被災者に対するマッチング候補（提供側の候補者）の表示の一例を示してある。
図１３には、被災者Ａ２（本例では、家族である２人をまとめた被災者）の情報と、被災者Ａ２の端末装置（需要側端末装置）の画面Ｃ２と、第２の支援者（支援者Ｂ２）の情報と、第３の支援者（支援者Ｂ３）の情報を示してある。
図１３には、支援優先度（優先度スコア）が低い被災者に対するマッチング候補（提供側の候補者）の表示の一例を示してある。
図１３には、被災者Ａ２（本例では、家族である２人をまとめた被災者）の情報と、被災者Ａ２の端末装置（需要側端末装置）の画面Ｃ２と、第２の支援者（支援者Ｂ２）の情報と、第３の支援者（支援者Ｂ３）の情報を示してある。
【0224】
なお、図１３の例は模式的な例であり、それぞれの支援者Ｂ２～Ｂ３の情報は画面Ｃ２に表示される。
本実施形態では、このような情報の表示が行われる状態が実現されるように、管理装置１３の取引サービス提供部３３１による制御が行われている。
支援者Ｂ２および支援者Ｂ３は、例えば、図１２の例の場合と同様である。
本実施形態では、このような情報の表示が行われる状態が実現されるように、管理装置１３の取引サービス提供部３３１による制御が行われている。
支援者Ｂ２および支援者Ｂ３は、例えば、図１２の例の場合と同様である。
【0225】
図１３の例では、被災者Ａ２の優先度スコアは３０点（０～１００点中）であり、優先度スコアが低いと判定されている。
被災者Ａ２は、数量２の水を希望しており、Ａ市に在住し、物資（ここでは、水）を取りに行くことができ、３日以内を希望している。
被災者Ａ２は、数量２の水を希望しており、Ａ市に在住し、物資（ここでは、水）を取りに行くことができ、３日以内を希望している。
【0226】
図１３の例では、被災者Ａ２にとって、支援者Ｂ３とのマッチング度が最も高い。
また、被災者Ａ２にとって、支援者Ｂ２とのマッチング度も比較的高いが、これは支援者Ｂ３とのマッチング度よりは低い。
なお、本例では、これらのマッチング度は、例えば、被災者と支援者との距離および支援の内容の一致度（需要と供給との一致度）に基づいており、被災者Ａ２の優先度スコアまたはその判定結果が考慮されていないマッチング度であるが、他の態様が用いられてもよい。
また、被災者Ａ２にとって、支援者Ｂ２とのマッチング度も比較的高いが、これは支援者Ｂ３とのマッチング度よりは低い。
なお、本例では、これらのマッチング度は、例えば、被災者と支援者との距離および支援の内容の一致度（需要と供給との一致度）に基づいており、被災者Ａ２の優先度スコアまたはその判定結果が考慮されていないマッチング度であるが、他の態様が用いられてもよい。
【0227】
ここで、図１２の例では、マッチング候補優先表示方式が用いられている。
マッチング候補優先表示方式では、マッチング度が高い候補者を優先的に表示する方式である。これにより、被災者Ａ１の要望（需要）に近い支援を行うことが可能な支援者Ｂ１～Ｂ３の候補が表示され、被災者Ａ１によって任意の支援者Ｂ１～Ｂ３を選択することが可能である。
マッチング候補優先表示方式では、例えば、マッチング度が所定の閾値以上である（または、所定の閾値を超える）支援者の候補を表示する一方、他の支援者の候補を表示しないような画面表示が行われる。
マッチング候補優先表示方式では、マッチング度が高い候補者を優先的に表示する方式である。これにより、被災者Ａ１の要望（需要）に近い支援を行うことが可能な支援者Ｂ１～Ｂ３の候補が表示され、被災者Ａ１によって任意の支援者Ｂ１～Ｂ３を選択することが可能である。
マッチング候補優先表示方式では、例えば、マッチング度が所定の閾値以上である（または、所定の閾値を超える）支援者の候補を表示する一方、他の支援者の候補を表示しないような画面表示が行われる。
【0228】
また、図１３の例においても、マッチング候補優先表示方式が用いられている。
ただし、図１２および図１３の例では、さらに、経過時間優先表示方式が用いられている。
経過時間優先表示方式では、所定の経過時間が経過するまでは、優先度スコアが高い被災者（需要側端末装置）に対して、当該被災者とのマッチング度が高い支援者の情報を表示するが、優先度スコアが比較的低い被災者（需要側端末装置）に対しては、当該支援者の情報を表示しない。
ただし、図１２および図１３の例では、さらに、経過時間優先表示方式が用いられている。
経過時間優先表示方式では、所定の経過時間が経過するまでは、優先度スコアが高い被災者（需要側端末装置）に対して、当該被災者とのマッチング度が高い支援者の情報を表示するが、優先度スコアが比較的低い被災者（需要側端末装置）に対しては、当該支援者の情報を表示しない。
【0229】
図１２および図１３の例では、図１２に示される優先度スコアが高い被災者Ａ１に対してはマッチング度が高い（例えば、最も高い）支援者Ｂ１の情報が表示されるが、所定の経過時間が経過するまでは、図１３に示される優先度スコアが比較的低い被災者Ａ２に対しては支援者Ｂ１の情報は表示されない。
所定の経過時間が経過すると、図１３に示される優先度スコアが比較的低い被災者Ａ２に対しても、支援者Ｂ１の情報が表示される。
これにより、例えば、優先度スコアが高い被災者Ａ１は、所定の経過時間が経過するまでは、被災者Ａ１にとってマッチング度が高い（例えば、最も高い）支援者Ｂ１を指定する権限を独占的に有する。
所定の経過時間が経過すると、図１３に示される優先度スコアが比較的低い被災者Ａ２に対しても、支援者Ｂ１の情報が表示される。
これにより、例えば、優先度スコアが高い被災者Ａ１は、所定の経過時間が経過するまでは、被災者Ａ１にとってマッチング度が高い（例えば、最も高い）支援者Ｂ１を指定する権限を独占的に有する。
【0230】
ここで、経過時間優先表示方式における経過時間の開始時間としては、特に限定はなく、例えば、優先度スコアが高い被災者Ａ１の需要側端末装置が需要情報を管理装置１３に送信した時間が用いられてもよく、または、優先度スコアが高い被災者Ａ１の需要側端末装置が災害時モードの画面表示（例えば、図６に示されるような画面表示など）になった時間が用いられてもよく、あるいは、災害が発生した時間が用いられてもよい。
所定の経過時間としては、任意の期間が用いられてもよく、例えば、３０分あるいは１時間などが設定されてもよい。
所定の経過時間としては、任意の期間が用いられてもよく、例えば、３０分あるいは１時間などが設定されてもよい。
【0231】
なお、他の例として、経過時間として、優先度スコアが比較的低い被災者Ａ２に関する経過時間が用いられてもよい。
【0232】
また、図１２および図１３の例において、優先度スコアが高いか低いかは、例えば、ある被災者の優先度スコアと他の被災者の優先度スコアとの大小関係に基づいて決定（例えば、判定）されてもよく、あるいは、優先度スコアが所定の閾値以上である（または、所定の閾値を超える）か否かに基づいて決定（例えば、判定）されてもよい。
【0233】
ここで、本実施形態では、マッチング候補優先表示方式は常に使用される一方、経過時間優先表示方式は使用される場合と使用されない場合がある態様を示すが、これに限られず、他の態様が用いられてもよい。
【0234】
本実施形態では、経過時間優先表示方式が使用されるか否かは、例えば、被災者の数あるいは被害の程度などに基づいて決定されてもよく、被災者の数が所定の閾値以上である（または、所定の閾値を超える）とき、あるいは、被害の程度が所定の閾値以上である（または、所定の閾値を超える）ときに経過時間優先表示方式を使用する一方、他のときには経過時間優先表示方式を使用しないような態様が用いられてもよい。
なお、被災者の数の代わりに、支援者の数に対する被災者の数の割合（または、差分などでもよい。）が用いられてもよい。つまり、支援者の数と比べて被害者の数が所定の条件を満たすほど多いと判定される場合に経過時間優先表示方式を使用する態様が用いられてもよい。
なお、被災者の数の代わりに、支援者の数に対する被災者の数の割合（または、差分などでもよい。）が用いられてもよい。つまり、支援者の数と比べて被害者の数が所定の条件を満たすほど多いと判定される場合に経過時間優先表示方式を使用する態様が用いられてもよい。
【0235】
他の例として、本実施形態では、管理装置１３（例えば、マッチング部３３５など）は、被災者の優先度スコアが高いほど、支援を申し出たタイミングが早い支援者の情報を災害時モードの画面表示（例えば、図６に示されるような画面表示など）に含めるような制御を行ってもよい。
このような制御が行われる場合には、例えば、優先度スコアが高い被災者ほど、支援の申し出時期が早い支援者にアクセスすることが可能となる。
ここで、支援者が支援を申し出たタイミングとしては、例えば、当該支援者が当該支援の内容を端末装置（提供側端末装置１２－１～１２－ｍ）から管理装置１３に通知したタイミング（または、それに基づくタイミング）が用いられてもよい。
このような制御が行われる場合には、例えば、優先度スコアが高い被災者ほど、支援の申し出時期が早い支援者にアクセスすることが可能となる。
ここで、支援者が支援を申し出たタイミングとしては、例えば、当該支援者が当該支援の内容を端末装置（提供側端末装置１２－１～１２－ｍ）から管理装置１３に通知したタイミング（または、それに基づくタイミング）が用いられてもよい。
【0236】
＜マッチング成立後の流れの例＞
図１４は、実施形態に係るマッチング成立後の流れの一例を示す図である。
本実施形態では、ある被災者（需要側ユーザー２１－１～２１－ｎ）と他の支援者（提供側ユーザー２２－１～２２－ｍ）とのマッチングによる支援が成立した場合には、当該被害者の端末装置と当該支援者の端末装置とで通信することが可能である。
この通信は、例えば、管理装置１３により中継されて行われてもよく、あるいは、直接行われてもよい。
ここで、本実施形態では、最終的には、被災者（需要側ユーザー２１－１～２１－ｎ）が希望の支援者（提供側ユーザー２２－１～２２－ｍ）を指定することで、マッチングによる支援が成立する。
図１４は、実施形態に係るマッチング成立後の流れの一例を示す図である。
本実施形態では、ある被災者（需要側ユーザー２１－１～２１－ｎ）と他の支援者（提供側ユーザー２２－１～２２－ｍ）とのマッチングによる支援が成立した場合には、当該被害者の端末装置と当該支援者の端末装置とで通信することが可能である。
この通信は、例えば、管理装置１３により中継されて行われてもよく、あるいは、直接行われてもよい。
ここで、本実施形態では、最終的には、被災者（需要側ユーザー２１－１～２１－ｎ）が希望の支援者（提供側ユーザー２２－１～２２－ｍ）を指定することで、マッチングによる支援が成立する。
【0237】
図１４の例では、被災者Ａ１と支援者Ｂ１とのマッチングによる支援が成立した場合に、被災者Ａ１の端末装置（需要側端末装置）と支援者Ｂ１の端末装置（提供側端末装置）との間でチャットが行われている様子の一例を模式的に示してある。
具体的には、被災者Ａ１は「支援ありがとうございます！」というメッセージを送り、支援者Ｂ１は「大変でしたね。すぐにお水を届けますが、ご自宅で良いですか？」というメッセージを送り、被災者Ａ１は「はい、宜しくお願い致します。近所に建物が倒壊している場所もあるので、被災マップでルートを確認してみてください。」というメッセージを送り、支援者Ｂ１は「確かに危険な場所がありそうですね。ルート確認しながら明日の１３時頃に届けますね。」というメッセージを送っている。
具体的には、被災者Ａ１は「支援ありがとうございます！」というメッセージを送り、支援者Ｂ１は「大変でしたね。すぐにお水を届けますが、ご自宅で良いですか？」というメッセージを送り、被災者Ａ１は「はい、宜しくお願い致します。近所に建物が倒壊している場所もあるので、被災マップでルートを確認してみてください。」というメッセージを送り、支援者Ｂ１は「確かに危険な場所がありそうですね。ルート確認しながら明日の１３時頃に届けますね。」というメッセージを送っている。
【0238】
このように、マッチングの支援が成立したときに、被災者Ａ１と支援者Ｂ１とがコミュニケーションを取ることができることで、より詳細に支援の内容を決めることなどが可能である。
図１４の例では、このようなコミュニケーションの手法として、チャットが用いられている。このチャットとしては、例えば、平常時モードにおける取引連絡用のチャットと同様なものが用いられてもよい。
図１４の例では、このようなコミュニケーションの手法として、チャットが用いられている。このチャットとしては、例えば、平常時モードにおける取引連絡用のチャットと同様なものが用いられてもよい。
【0239】
＜被災マップの例＞
図１５は、実施形態に係る被災マップ３０１１の一例を示す図である。
本実施形態では、災害時モードでは、需要側端末装置１１－１～１１－ｎおよび提供側端末装置１２－１～１２－ｍは、被災マップ３０１１を表示することが可能である。
被災マップ３０１１の情報は、例えば、管理装置１３のマッチング部３３５によって需要側端末装置１１－１～１１－ｎおよび提供側端末装置１２－１～１２－ｍに提供されてもよい。
図１５は、実施形態に係る被災マップ３０１１の一例を示す図である。
本実施形態では、災害時モードでは、需要側端末装置１１－１～１１－ｎおよび提供側端末装置１２－１～１２－ｍは、被災マップ３０１１を表示することが可能である。
被災マップ３０１１の情報は、例えば、管理装置１３のマッチング部３３５によって需要側端末装置１１－１～１１－ｎおよび提供側端末装置１２－１～１２－ｍに提供されてもよい。
【0240】
なお、管理装置１３は、例えば、外部の所定システムから提供される情報を利用して防災マップの生成などをしてもよい。
当該所定システムとしては、任意のシステムが用いられてもよく、例えば、ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）防災情報システムなどのような、被害推定システムが用いられてもよい。
当該所定システムとしては、任意のシステムが用いられてもよく、例えば、ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）防災情報システムなどのような、被害推定システムが用いられてもよい。
【0241】
図１５の例における被災マップ３０１１では、地図情報に重畳して、被災者の位置（被災者位置Ｄ１）と、支援者となり得る候補者の位置（支援候補者位置Ｅ１～Ｅ３）と、災害が発生した位置（災害発生位置Ｆ１～Ｆ６）と、が示されている。
【0242】
図１５の例では、被災者位置Ｄ１の被災者と支援候補者位置Ｅ１の支援者とのマッチングが成立した場合を示してある。被災マップ３０１１では、当該支援者の行動可能な範囲（行動範囲３１１１）と、当該支援者の位置と当該被災者の位置とを結ぶルート３２１１と、を示してある。
【0243】
本実施形態では、管理装置１３のマッチング部３３５によって需要側ユーザー２１－１～２１－ｎ（需要側端末装置１１－１～１１－ｎ）に、提供側ユーザー２２－１～２２－ｍの候補者リストと、該当する需要側ユーザー２１－１～２１－ｎの位置を含む被災マップ（例えば、被災マップ３０１１のようなもの）と、の一方または両方を提供することが可能である。
需要側ユーザー２１－１～２１－ｎは、需要側端末装置１１－１～１１－ｎの操作部（図２の例では、操作部１３１）を操作することで、管理装置１３に対して、当該候補者リストと当該被災マップとの一方または両方を指定する要求を送信してもよい。この場合、管理装置１３のマッチング部３３５は、需要側端末装置１１－１～１１－ｎからの要求に応じた情報（当該候補者リストと当該被災マップとの一方または両方）を、要求元の需要側端末装置１１－１～１１－ｎに送信する。
需要側ユーザー２１－１～２１－ｎは、需要側端末装置１１－１～１１－ｎの操作部（図２の例では、操作部１３１）を操作することで、管理装置１３に対して、当該候補者リストと当該被災マップとの一方または両方を指定する要求を送信してもよい。この場合、管理装置１３のマッチング部３３５は、需要側端末装置１１－１～１１－ｎからの要求に応じた情報（当該候補者リストと当該被災マップとの一方または両方）を、要求元の需要側端末装置１１－１～１１－ｎに送信する。
【0244】
これにより、需要側ユーザー２１－１～２１－ｎは、需要側端末装置１１－１～１１－ｎにより表示される情報（候補者リストと被災マップとの一方または両方）に基づいて、候補者のなかからマッチングを成立させる相手（支援者）を決定することが可能である。
需要側ユーザー２１－１～２１－ｎは、例えば、被災マップを参照することで、被害の状況、支援者の位置およびルートなどを視覚的に把握し易い。
需要側ユーザー２１－１～２１－ｎは、例えば、被災マップを用いて、ルート検索などを行うことも可能である。
需要側ユーザー２１－１～２１－ｎは、例えば、被災マップを参照することで、被害の状況、支援者の位置およびルートなどを視覚的に把握し易い。
需要側ユーザー２１－１～２１－ｎは、例えば、被災マップを用いて、ルート検索などを行うことも可能である。
【0245】
同様に、本実施形態では、管理装置１３のマッチング部３３５によって提供側ユーザー２２－１～２２－ｍ（提供側端末装置１２－１～１２－ｍ）に、需要側ユーザー２１－１～２１－ｎの候補者リストと、該当する提供側ユーザー２２－１～２２－ｍの位置を含む被災マップ（例えば、被災マップ３０１１のようなもの）と、の一方または両方を提供することが可能である。
提供側ユーザー２２－１～２２－ｍは、提供側端末装置１２－１～１２－ｍの操作部（図３の例では、操作部２３１）を操作することで、管理装置１３に対して、当該候補者リストと当該被災マップとの一方または両方を指定する要求を送信してもよい。この場合、管理装置１３のマッチング部３３５は、提供側端末装置１２－１～１２－ｍからの要求に応じた情報（当該候補者リストと当該被災マップとの一方または両方）を、要求元の提供側端末装置１２－１～１２－ｍに送信する。
提供側ユーザー２２－１～２２－ｍは、提供側端末装置１２－１～１２－ｍの操作部（図３の例では、操作部２３１）を操作することで、管理装置１３に対して、当該候補者リストと当該被災マップとの一方または両方を指定する要求を送信してもよい。この場合、管理装置１３のマッチング部３３５は、提供側端末装置１２－１～１２－ｍからの要求に応じた情報（当該候補者リストと当該被災マップとの一方または両方）を、要求元の提供側端末装置１２－１～１２－ｍに送信する。
【0246】
これにより、提供側ユーザー２２－１～２２－ｍは、提供側端末装置１２－１～１２－ｍにより表示される情報（候補者リストと被災マップとの一方または両方）に基づいて、自己（支援候補者）と被災者との位置関係、被害の状況およびルートなどを把握することが可能である。
提供側ユーザー２２－１～２２－ｍは、例えば、被災マップを参照することで、被害の状況、被災者の位置およびルートなどを視覚的に把握し易い。
提供側ユーザー２２－１～２２－ｍは、例えば、被災マップを用いて、ルート検索などを行うことも可能である。
提供側ユーザー２２－１～２２－ｍは、例えば、被災マップを参照することで、被害の状況、被災者の位置およびルートなどを視覚的に把握し易い。
提供側ユーザー２２－１～２２－ｍは、例えば、被災マップを用いて、ルート検索などを行うことも可能である。
【0247】
ここで、管理装置１３は、各種の情報を、例えば、文字等の形式で端末装置（需要側端末装置１１－１～１１－ｎ、提供側端末装置１２－１～１２－ｍ）に提供してもよく、あるいは、被災マップの形式で端末装置に提供してもよい。
それぞれの端末装置（需要側端末装置１１－１～１１－ｎ、提供側端末装置１２－１～１２－ｍ）では、それぞれのユーザー（需要側ユーザー２１－１～２１－ｎ、提供側ユーザー２２－１～２２－ｍ）によって行われる操作に基づいて、希望する形式（例えば、文字等の形式、被災マップの形式など）の指示を管理装置１３に送信してもよい。これにより、管理装置１３では、取引サービス提供部３３１により、当該端末装置から指示された形式で、当該端末装置に情報を提供してもよい。
それぞれの端末装置（需要側端末装置１１－１～１１－ｎ、提供側端末装置１２－１～１２－ｍ）では、それぞれのユーザー（需要側ユーザー２１－１～２１－ｎ、提供側ユーザー２２－１～２２－ｍ）によって行われる操作に基づいて、希望する形式（例えば、文字等の形式、被災マップの形式など）の指示を管理装置１３に送信してもよい。これにより、管理装置１３では、取引サービス提供部３３１により、当該端末装置から指示された形式で、当該端末装置に情報を提供してもよい。
【0248】
なお、被災マップの形式で提供される情報としては、特に限定はなく、例えば、支援者について、属性、提供可能な支援の内容（物品、役務）、対応可能時期、行動範囲などの情報が用いられてもよい。
同様に、被災マップの形式で提供される情報として、例えば、被災者について、属性、希望する支援の内容（物品、役務）、希望対応時期、行動範囲などの情報が用いられてもよい。
同様に、被災マップの形式で提供される情報として、例えば、被災者について、属性、希望する支援の内容（物品、役務）、希望対応時期、行動範囲などの情報が用いられてもよい。
【0249】
また、被災マップの形式で提供される情報として、例えば、被災者と支援者との位置関係、被災者と支援者とをつなぐ安全なルート、支援者から被災者への安全な受け渡し場所などの情報が用いられてもよい。
安全なルート、あるいは、安全な受け渡し場所などの情報は、例えば、外部の被害推定システムによって行われる被害推定結果に基づいて、管理装置１３（例えば、取引サービス提供部３３１）により決定されてもよい。
また、安全なルート、あるいは、安全な受け渡し場所などの情報としては、例えば、複数の候補が表示されてもよい。
安全なルート、あるいは、安全な受け渡し場所などの情報は、例えば、外部の被害推定システムによって行われる被害推定結果に基づいて、管理装置１３（例えば、取引サービス提供部３３１）により決定されてもよい。
また、安全なルート、あるいは、安全な受け渡し場所などの情報としては、例えば、複数の候補が表示されてもよい。
【0250】
被災者は、例えば、支援者の候補者リストから希望の支援者を選択する手法の代わりに、または、当該手法とともに、被災マップに表示されている情報から自分の希望（条件）に合った支援者を見つける手法を使用することが可能である。
【0251】
＜需要側の利用の流れの例＞
図１６は、実施形態に係る需要側の利用の流れの処理の手順の一例を示す図である。
ここでは、説明の便宜上、１個の需要側端末装置１１－１において行われる処理を例として説明するが、本実施形態では、すべての需要側端末装置１１－１～１１－ｎにおいて行われる処理は同様である。
図１６は、実施形態に係る需要側の利用の流れの処理の手順の一例を示す図である。
ここでは、説明の便宜上、１個の需要側端末装置１１－１において行われる処理を例として説明するが、本実施形態では、すべての需要側端末装置１１－１～１１－ｎにおいて行われる処理は同様である。
【0252】
【0253】
ここで、利用者登録の処理では、例えば、利用者（需要側ユーザー２１－１）に関して、利用者情報の登録が行われる。
利用者情報としては、例えば、住所、家族構成、障害・持病の有無、行動制限の有無などがあり得る。
利用者情報としては、例えば、住所、家族構成、障害・持病の有無、行動制限の有無などがあり得る。
【0254】
需要側端末装置１１－１は、任意のタイミングで、登録された利用者情報を管理装置１３に送信する。
このとき、利用者の身分証明が併せて行われてもよい。
管理装置１３では、需要者スコア算出部３７１により、基本属性（本例では、利用者情報）に応じて優先度スコアを算出しておいてもよい。これにより、例えば、災害弱者の優先度スコアを上げておいてもよい。
なお、このような優先度スコアは、例えば、後に、需要者スコア算出部３７１により、他の情報に基づいて再計算されてもよい。
このとき、利用者の身分証明が併せて行われてもよい。
管理装置１３では、需要者スコア算出部３７１により、基本属性（本例では、利用者情報）に応じて優先度スコアを算出しておいてもよい。これにより、例えば、災害弱者の優先度スコアを上げておいてもよい。
なお、このような優先度スコアは、例えば、後に、需要者スコア算出部３７１により、他の情報に基づいて再計算されてもよい。
【0255】
（ステップＳ２）
需要側端末装置１１－１は、操作部（図２の例では、操作部１３１）が需要側ユーザー２１－１によって操作されることで、要望および条件の入力の処理を行う。
そして、ステップＳ３の処理へ移行する。
需要側端末装置１１－１は、操作部（図２の例では、操作部１３１）が需要側ユーザー２１－１によって操作されることで、要望および条件の入力の処理を行う。
そして、ステップＳ３の処理へ移行する。
【0256】
ここで、要望および条件の入力の処理では、例えば、利用者（需要側ユーザー２１－１）に関して、要望および条件の入力が行われる。
要望および条件の情報としては、例えば、物品、役務（救済事）、緊急度、行動範囲（例えば、取りに行くことができる、または、来てもらう）などがあり得る。
なお、要望および条件が詳細であるほど、マッチング関連度が上がる傾向がある。
需要側端末装置１１－１は、任意のタイミングで、入力された要望および条件の情報を管理装置１３に送信する。
要望および条件の情報としては、例えば、物品、役務（救済事）、緊急度、行動範囲（例えば、取りに行くことができる、または、来てもらう）などがあり得る。
なお、要望および条件が詳細であるほど、マッチング関連度が上がる傾向がある。
需要側端末装置１１－１は、任意のタイミングで、入力された要望および条件の情報を管理装置１３に送信する。
【0257】
（ステップＳ３）
需要側端末装置１１－１は、現在位置の提供の処理を行う。
そして、本フローの処理が終了する。
需要側端末装置１１－１は、現在位置の提供の処理を行う。
そして、本フローの処理が終了する。
【0258】
ここで、現在位置の提供の処理では、需要側端末装置１１－１は、ＧＰＳ部１３３によって取得された位置の情報を管理装置１３に送信する。
なお、ＧＰＳによる位置情報の提供の可否が設定されてもよい。
なお、ＧＰＳによる位置情報の提供の可否が設定されてもよい。
【0259】
【0260】
＜提供側の利用の流れの例＞
図１７は、実施形態に係る提供側の利用の流れの処理の手順の一例を示す図である。
ここでは、説明の便宜上、１個の提供側端末装置１２－１において行われる処理を例として説明するが、本実施形態では、すべての提供側端末装置１２－１～１２－ｍにおいて行われる処理は同様である。
図１７は、実施形態に係る提供側の利用の流れの処理の手順の一例を示す図である。
ここでは、説明の便宜上、１個の提供側端末装置１２－１において行われる処理を例として説明するが、本実施形態では、すべての提供側端末装置１２－１～１２－ｍにおいて行われる処理は同様である。
【0261】
【0262】
ここで、利用者登録の処理では、例えば、利用者（提供側ユーザー２２－１）に関して、利用者情報の登録が行われる。
利用者情報としては、例えば、支援できる役務、行動範囲などがあり得る。
利用者情報としては、例えば、支援できる役務、行動範囲などがあり得る。
【0263】
提供側端末装置１２－１は、任意のタイミングで、登録された利用者情報を管理装置１３に送信する。
このとき、利用者の身分証明が併せて行われてもよい。
管理装置１３では、例えば、基本属性として、支援できる役務、行動範囲を登録しておくことで、当該基本属性が災害時に被災者などに通知されるように制御してもよい。
このとき、利用者の身分証明が併せて行われてもよい。
管理装置１３では、例えば、基本属性として、支援できる役務、行動範囲を登録しておくことで、当該基本属性が災害時に被災者などに通知されるように制御してもよい。
【0264】
（ステップＳ１２）
提供側端末装置１２－１は、操作部（図３の例では、操作部２３１）が提供側ユーザー２２－１によって操作されることで、支援および条件の入力の処理を行う。
そして、ステップＳ１３の処理へ移行する。
提供側端末装置１２－１は、操作部（図３の例では、操作部２３１）が提供側ユーザー２２－１によって操作されることで、支援および条件の入力の処理を行う。
そして、ステップＳ１３の処理へ移行する。
【0265】
ここで、支援および条件の入力の処理では、例えば、利用者（提供側ユーザー２２－１）に関して、支援および条件の入力が行われる。
支援および条件の情報としては、例えば、物品、対応可能な時期、行動範囲（例えば、現地に行くことができる、または、来てもらう）などがあり得る。例えば、物品の支援が可能な場合には、支援内容の入力が可能である。
支援および条件の情報としては、例えば、物品、対応可能な時期、行動範囲（例えば、現地に行くことができる、または、来てもらう）などがあり得る。例えば、物品の支援が可能な場合には、支援内容の入力が可能である。
【0266】
提供側端末装置１２－１は、任意のタイミングで、入力された支援および条件の情報を管理装置１３に送信する。
なお、本例では、利用者登録の処理において役務と行動範囲の登録が行われる場合を示しているが、他の例として、支援および条件の入力において、役務の登録と、行動範囲の登録と、の一方または両方が行われてもよい。
なお、本例では、利用者登録の処理において役務と行動範囲の登録が行われる場合を示しているが、他の例として、支援および条件の入力において、役務の登録と、行動範囲の登録と、の一方または両方が行われてもよい。
【0267】
（ステップＳ１３）
提供側端末装置１２－１は、現在位置の提供の処理を行う。
そして、本フローの処理が終了する。
提供側端末装置１２－１は、現在位置の提供の処理を行う。
そして、本フローの処理が終了する。
【0268】
ここで、現在位置の提供の処理では、提供側端末装置１２－１は、ＧＰＳ部２３３によって取得された位置の情報を管理装置１３に送信する。
なお、ＧＰＳによる位置情報の提供の可否が設定されてもよい。
なお、ＧＰＳによる位置情報の提供の可否が設定されてもよい。
【0269】
【0270】
＜管理装置におけるマッチングの処理＞
図１８は、実施形態に係る管理装置１３におけるマッチングの処理の手順の一例を示す図である。
本例では、災害が発生して、需要側ユーザー２１－１～２１－ｎが被災者となっており、提供側ユーザー２２－１～２２－ｍが支援者となり得る（つまり、支援候補者である）場合を想定して、説明する。
図１８は、実施形態に係る管理装置１３におけるマッチングの処理の手順の一例を示す図である。
本例では、災害が発生して、需要側ユーザー２１－１～２１－ｎが被災者となっており、提供側ユーザー２２－１～２２－ｍが支援者となり得る（つまり、支援候補者である）場合を想定して、説明する。
【0271】
（ステップＳ２１）
管理装置１３では、属性情報取得部３３２、需要情報取得部３３３および提供情報取得部３３４により、優先付けのために必要な情報を取得する。なお、それぞれの情報の取得は、任意のタイミングで行われてもよい。
そして、ステップＳ２２の処理へ移行する。
管理装置１３では、属性情報取得部３３２、需要情報取得部３３３および提供情報取得部３３４により、優先付けのために必要な情報を取得する。なお、それぞれの情報の取得は、任意のタイミングで行われてもよい。
そして、ステップＳ２２の処理へ移行する。
【0272】
（ステップＳ２２）
管理装置１３では、取得された情報に基づいて需要者スコア算出部３７１により被災者の優先度スコアを算出し、算出された優先度スコアに基づいて優先度判定部３７２により被災者の優先度（例えば、順位など）を判定する。
そして、ステップＳ２３の処理へ移行する。
管理装置１３では、取得された情報に基づいて需要者スコア算出部３７１により被災者の優先度スコアを算出し、算出された優先度スコアに基づいて優先度判定部３７２により被災者の優先度（例えば、順位など）を判定する。
そして、ステップＳ２３の処理へ移行する。
【0273】
（ステップＳ２３）
管理装置１３では、候補者抽出部３７３により、被災者と支援者との距離、および、支援の需給に関する情報（需給情報）を取得する。
そして、ステップＳ２４の処理へ移行する。
管理装置１３では、候補者抽出部３７３により、被災者と支援者との距離、および、支援の需給に関する情報（需給情報）を取得する。
そして、ステップＳ２４の処理へ移行する。
【0274】
（ステップＳ２４）
管理装置１３では、取得された情報に基づいて候補者抽出部３７３により被災者と支援者とのマッチングの処理を行い、当該マッチングの処理の結果に基づいて候補者（組み合わせ可能な被災者の候補者および支援者の候補者）を抽出する。
そして、ステップＳ２５の処理へ移行する。
管理装置１３では、取得された情報に基づいて候補者抽出部３７３により被災者と支援者とのマッチングの処理を行い、当該マッチングの処理の結果に基づいて候補者（組み合わせ可能な被災者の候補者および支援者の候補者）を抽出する。
そして、ステップＳ２５の処理へ移行する。
【0275】
（ステップＳ２５）
管理装置１３では、候補者抽出部３７３により、抽出された候補者の情報（マッチング候補の情報）を提示する。
そして、本フローの処理を終了する。
管理装置１３では、候補者抽出部３７３により、抽出された候補者の情報（マッチング候補の情報）を提示する。
そして、本フローの処理を終了する。
【0276】
ここで、本例では、候補者抽出部３７３は、少なくとも各被災者（各需要側ユーザー２１－１～２１－ｎ）に対して、各需要側端末装置１１－１～１１－ｎを介して、支援者の候補者（例えば、支援者リスト）を提示する。
また、候補者抽出部３７３は、各支援者（各提供側ユーザー２２－１～２２－ｍ）に対して、各提供側端末装置１２－１～１２－ｍを介して、被災者の候補者（例えば、被災者リスト）を提示してもよい。
また、候補者抽出部３７３は、各支援者（各提供側ユーザー２２－１～２２－ｍ）に対して、各提供側端末装置１２－１～１２－ｍを介して、被災者の候補者（例えば、被災者リスト）を提示してもよい。
【0277】
このように、管理装置１３におけるマッチングの処理では、被災者の登録内容および支援者の登録内容に基づいて、所定の条件にしたがって、候補者を決定する。
当該所定の条件としては、例えば、優先度付けの条件、被災者と支援者との距離の条件、および、需給合致度の条件があり得る。
優先度付けの条件が用いられることにより、例えば、緊急度が高い被災者に優先的に支援者を提供すること、および、被害が大きい被災者に優先的に支援者を提供すること、などが可能である。
需給合致度の条件が用いられることにより、例えば、物資（物品）および役務に関して、需要と供給が合致するように調整することが可能である。
当該所定の条件としては、例えば、優先度付けの条件、被災者と支援者との距離の条件、および、需給合致度の条件があり得る。
優先度付けの条件が用いられることにより、例えば、緊急度が高い被災者に優先的に支援者を提供すること、および、被害が大きい被災者に優先的に支援者を提供すること、などが可能である。
需給合致度の条件が用いられることにより、例えば、物資（物品）および役務に関して、需要と供給が合致するように調整することが可能である。
【0278】
なお、被災者の優先度に基づく処理は、例えば、マッチングの処理に含まれると捉えられてもよく、あるいは、マッチングの処理とは別の処理であると捉えられてもよい。
つまり、マッチングの処理において、被災者の優先度も考慮されたマッチングの結果が得られると捉えられてもよく、あるいは、マッチングの処理では被災者の優先度が考慮されていないマッチングの結果が得られるが、その後、当該マッチングの結果と被災者の優先度とに基づいて、被災者の優先度も考慮されたマッチングの結果が得られると捉えられてもよい。
つまり、マッチングの処理において、被災者の優先度も考慮されたマッチングの結果が得られると捉えられてもよく、あるいは、マッチングの処理では被災者の優先度が考慮されていないマッチングの結果が得られるが、その後、当該マッチングの結果と被災者の優先度とに基づいて、被災者の優先度も考慮されたマッチングの結果が得られると捉えられてもよい。
【0279】
＜災害情報処理システムにおける処理＞
図１９は、実施形態に係る災害情報処理システム１における処理の手順の一例を示す図である。
本例では、説明の便宜上、１個の需要側端末装置１１－１および１個の提供側端末装置１２－１を例として説明するが、本実施形態では、すべての需要側端末装置１１－１～１１－ｎおよびすべての提供側端末装置１２－１～１２－ｍについて同様な処理が行われる。
図１９は、実施形態に係る災害情報処理システム１における処理の手順の一例を示す図である。
本例では、説明の便宜上、１個の需要側端末装置１１－１および１個の提供側端末装置１２－１を例として説明するが、本実施形態では、すべての需要側端末装置１１－１～１１－ｎおよびすべての提供側端末装置１２－１～１２－ｍについて同様な処理が行われる。
【0280】
図１９には、需要側端末装置１１－１、提供側端末装置１２－１、および管理装置１３を示してある。
本例では、説明の便宜上、提供側端末装置１２－１において行われる処理を処理Ｔ１～処理Ｔ３と表しており、需要側端末装置１１－１において行われる処理を処理Ｔ１１～処理Ｔ１４と表しており、管理装置１３において行われる処理を処理Ｔ２１～処理Ｔ２８および処理Ｔ２１１～処理Ｔ２１３と表しており、提供側端末装置１２－１または需要側端末装置１１－１と管理装置１３との間で行われる処理を処理Ｔ１１１～処理Ｔ１１７と表している。
本例では、説明の便宜上、提供側端末装置１２－１において行われる処理を処理Ｔ１～処理Ｔ３と表しており、需要側端末装置１１－１において行われる処理を処理Ｔ１１～処理Ｔ１４と表しており、管理装置１３において行われる処理を処理Ｔ２１～処理Ｔ２８および処理Ｔ２１１～処理Ｔ２１３と表しており、提供側端末装置１２－１または需要側端末装置１１－１と管理装置１３との間で行われる処理を処理Ｔ１１１～処理Ｔ１１７と表している。
【0281】
なお、図１９に示される処理のシーケンスは、説明のための一例であり、災害情報処理システム１における処理のシーケンスとしては、任意のシーケンスが用いられてもよい。
例えば、各処理の順序は、入れ替え可能なものについては、任意に入れ替えられてもよい。
また、例えば、提供側端末装置１２－１により行われる処理と、需要側端末装置１１－１により行われる処理は、例えば、並列的なタイミングで、それぞれ独立に行われてもよい。
例えば、各処理の順序は、入れ替え可能なものについては、任意に入れ替えられてもよい。
また、例えば、提供側端末装置１２－１により行われる処理と、需要側端末装置１１－１により行われる処理は、例えば、並列的なタイミングで、それぞれ独立に行われてもよい。
【0282】
（処理Ｔ１）
提供側端末装置１２－１では、提供側ユーザー２２－１によって行われる操作などに基づいて、提供側ユーザー２２－１（本実施形態では、支援者）に関する属性情報を入力する。
提供側端末装置１２－１では、提供側ユーザー２２－１によって行われる操作などに基づいて、提供側ユーザー２２－１（本実施形態では、支援者）に関する属性情報を入力する。
【0283】
（処理Ｔ１１１）
提供側端末装置１２－１では、入力された属性情報を管理装置１３に送信する。
なお、この送信の処理は、任意のタイミングで行われてもよい。
提供側端末装置１２－１では、入力された属性情報を管理装置１３に送信する。
なお、この送信の処理は、任意のタイミングで行われてもよい。
【0284】
（処理Ｔ１１）
需要側端末装置１１－１では、需要側ユーザー２１－１によって行われる操作などに基づいて、需要側ユーザー２１－１（本実施形態では、被災者）に関する属性情報を入力する。
需要側端末装置１１－１では、需要側ユーザー２１－１によって行われる操作などに基づいて、需要側ユーザー２１－１（本実施形態では、被災者）に関する属性情報を入力する。
【0285】
（処理Ｔ１１２）
需要側端末装置１１－１では、入力された属性情報を管理装置１３に送信する。
なお、この送信の処理は、任意のタイミングで行われてもよい。
需要側端末装置１１－１では、入力された属性情報を管理装置１３に送信する。
なお、この送信の処理は、任意のタイミングで行われてもよい。
【0286】
（処理Ｔ２１）
管理装置１３では、提供側端末装置１２－１から送信される属性情報を受信して取得し、また、需要側端末装置１１－１から送信される属性情報を受信して取得する。
管理装置１３では、提供側端末装置１２－１から送信される属性情報を受信して取得し、また、需要側端末装置１１－１から送信される属性情報を受信して取得する。
【0287】
（処理Ｔ２）
提供側端末装置１２－１では、災害が発生したときなどに、提供側ユーザー２２－１によって行われる操作などに基づいて、提供側ユーザー２２－１（本実施形態では、支援者）に関する提供情報を入力する。
提供側端末装置１２－１では、災害が発生したときなどに、提供側ユーザー２２－１によって行われる操作などに基づいて、提供側ユーザー２２－１（本実施形態では、支援者）に関する提供情報を入力する。
【0288】
（処理Ｔ１１３）
提供側端末装置１２－１では、入力された提供情報を管理装置１３に送信する。
なお、この送信の処理は、任意のタイミングで行われてもよい。
また、本例では、提供側端末装置１２－１では、位置の情報についても管理装置１３に送信する。
提供側端末装置１２－１では、入力された提供情報を管理装置１３に送信する。
なお、この送信の処理は、任意のタイミングで行われてもよい。
また、本例では、提供側端末装置１２－１では、位置の情報についても管理装置１３に送信する。
【0289】
（処理Ｔ２２）
管理装置１３では、提供側端末装置１２－１から送信される提供情報を受信して取得する。
管理装置１３では、提供側端末装置１２－１から送信される提供情報を受信して取得する。
【0290】
（処理Ｔ１２）
需要側端末装置１１－１では、災害が発生したときなどに、需要側ユーザー２１－１によって行われる操作などに基づいて、需要側ユーザー２１－１（本実施形態では、被災者）に関する需要情報を入力する。
需要側端末装置１１－１では、災害が発生したときなどに、需要側ユーザー２１－１によって行われる操作などに基づいて、需要側ユーザー２１－１（本実施形態では、被災者）に関する需要情報を入力する。
【0291】
（処理Ｔ１１４）
需要側端末装置１１－１では、入力された需要情報を管理装置１３に送信する。
なお、この送信の処理は、任意のタイミングで行われてもよい。
また、本例では、需要側端末装置１１－１では、位置の情報についても管理装置１３に送信する。
需要側端末装置１１－１では、入力された需要情報を管理装置１３に送信する。
なお、この送信の処理は、任意のタイミングで行われてもよい。
また、本例では、需要側端末装置１１－１では、位置の情報についても管理装置１３に送信する。
【0292】
（処理Ｔ２３）
管理装置１３では、需要側端末装置１１－１から送信される需要情報を受信して取得する。
管理装置１３では、需要側端末装置１１－１から送信される需要情報を受信して取得する。
【0293】
（処理Ｔ２４）
管理装置１３では、マッチングの処理として、所定の処理（本例では、処理Ｔ２１１～処理Ｔ２１３）を行う。
管理装置１３では、マッチングの処理として、所定の処理（本例では、処理Ｔ２１１～処理Ｔ２１３）を行う。
【0294】
（処理Ｔ２１１）
管理装置１３では、需要側ユーザー２１－１に関するスコア（優先度スコア）を算出する。
管理装置１３では、需要側ユーザー２１－１に関するスコア（優先度スコア）を算出する。
【0295】
（処理Ｔ２１２）
管理装置１３では、算出された優先度スコアに基づいて、需要側ユーザー２１－１の優先度（支援の優先度）を判定する。
管理装置１３では、算出された優先度スコアに基づいて、需要側ユーザー２１－１の優先度（支援の優先度）を判定する。
【0296】
（処理Ｔ２１３）
管理装置１３では、支援者と被災者とのマッチングにおける候補者（本例では、支援者に提供するための被災者の候補者、および、被災者に提供するための支援者の候補者）を抽出する。
管理装置１３では、支援者と被災者とのマッチングにおける候補者（本例では、支援者に提供するための被災者の候補者、および、被災者に提供するための支援者の候補者）を抽出する。
【0297】
（処理Ｔ２５）
管理装置１３では、候補者の抽出結果に基づいて、候補者リスト（本例では、支援者に提供するための被災者の候補者リスト、および、被災者に提供するための支援者の候補者リスト）を生成する。
管理装置１３では、候補者の抽出結果に基づいて、候補者リスト（本例では、支援者に提供するための被災者の候補者リスト、および、被災者に提供するための支援者の候補者リスト）を生成する。
【0298】
（処理Ｔ２６）
管理装置１３では、生成された候補者リストを送信する処理（処理Ｔ１１５、処理Ｔ１１６）を行う。
管理装置１３では、生成された候補者リストを送信する処理（処理Ｔ１１５、処理Ｔ１１６）を行う。
【0299】
（処理Ｔ１１５）
管理装置１３では、生成された被災者の候補者リストを提供側端末装置１２－１に送信する。
なお、この送信の処理は、任意のタイミングで行われてもよい。
管理装置１３では、生成された被災者の候補者リストを提供側端末装置１２－１に送信する。
なお、この送信の処理は、任意のタイミングで行われてもよい。
【0300】
（処理Ｔ１１６）
管理装置１３では、生成された支援者の候補者リストを需要側端末装置１１－１に送信する。
なお、この送信の処理は、任意のタイミングで行われてもよい。
管理装置１３では、生成された支援者の候補者リストを需要側端末装置１１－１に送信する。
なお、この送信の処理は、任意のタイミングで行われてもよい。
【0301】
（処理Ｔ３）
提供側端末装置１２－１では、管理装置１３から送信された被災者の候補者リストを受信して取得する。
これにより、提供側ユーザー２２－１は、自己（支援者）とマッチング度が高い被災者の候補者リストを閲覧することが可能である。
提供側端末装置１２－１では、管理装置１３から送信された被災者の候補者リストを受信して取得する。
これにより、提供側ユーザー２２－１は、自己（支援者）とマッチング度が高い被災者の候補者リストを閲覧することが可能である。
【0302】
（処理Ｔ１３）
需要側端末装置１１－１では、管理装置１３から送信された支援者の候補者リストを受信して取得する。
これにより、需要側ユーザー２１－１は、自己（被災者）とマッチング度が高い支援者の候補者リストを閲覧することが可能である。
需要側端末装置１１－１では、管理装置１３から送信された支援者の候補者リストを受信して取得する。
これにより、需要側ユーザー２１－１は、自己（被災者）とマッチング度が高い支援者の候補者リストを閲覧することが可能である。
【0303】
ここで、本例では、被災者には、属性および被害の状況などに基づいて、優先度付けがされている。そして、優先度が高い被災者に対して、マッチング度が高い支援者を優先的に選択することが可能な状況が実現されている。
本例では、被災者が、支援者のリストを閲覧して、支援を受けることを希望する支援者を指定することが可能であり、このような指定によってマッチングによる支援が成立する。
本例では、被災者が、支援者のリストを閲覧して、支援を受けることを希望する支援者を指定することが可能であり、このような指定によってマッチングによる支援が成立する。
【0304】
（処理Ｔ１４）
需要側端末装置１１－１では、需要側ユーザー２１－１によって行われる操作に応じて、支援者とのマッチングによる支援が成立した場合には、その旨を表す情報（成立情報）を生成する。
需要側端末装置１１－１では、需要側ユーザー２１－１によって行われる操作に応じて、支援者とのマッチングによる支援が成立した場合には、その旨を表す情報（成立情報）を生成する。
【0305】
（処理Ｔ１１７）
需要側端末装置１１－１では、成立情報を管理装置１３に送信する。
需要側端末装置１１－１では、成立情報を管理装置１３に送信する。
【0306】
（処理Ｔ２７）
管理装置１３では、需要側ユーザー２１－１から送信された成立情報を受信する。
管理装置１３では、需要側ユーザー２１－１から送信された成立情報を受信する。
【0307】
ここで、管理装置１３では、例えば、ある被災者に対して支援することが成立した支援者について、他の被災者への支援の可能性が無くなったときには、他の被災者に対する候補者リストから除外する制御を行う。
あるいは、管理装置１３では、例えば、ある被災者に対して支援することが成立した支援者について、他の被災者への支援の程度（例えば、物資の量、あるいは、役務の時間など）が減少したときには、必要に応じて、他の被災者に対する候補者リストを変更する制御を行う。
あるいは、管理装置１３では、例えば、ある被災者に対して支援することが成立した支援者について、他の被災者への支援の程度（例えば、物資の量、あるいは、役務の時間など）が減少したときには、必要に応じて、他の被災者に対する候補者リストを変更する制御を行う。
【0308】
同様に、管理装置１３では、例えば、ある支援者から支援を受けることが成立した被災者について、他の支援者からの支援の需要が無くなったときには、他の支援者に対する候補者リストから除外する制御を行う。
あるいは、管理装置１３では、例えば、ある支援者から支援を受けることが成立した被災者について、他の支援者からの支援の需要の程度（例えば、物資の量、あるいは、役務の時間など）が減少したときには、必要に応じて、他の支援者に対する候補者リストを変更する制御を行う。
あるいは、管理装置１３では、例えば、ある支援者から支援を受けることが成立した被災者について、他の支援者からの支援の需要の程度（例えば、物資の量、あるいは、役務の時間など）が減少したときには、必要に応じて、他の支援者に対する候補者リストを変更する制御を行う。
【0309】
（処理Ｔ２８）
管理装置１３では、被災者と支援者に関して、物資あるいは役務について需給の状況の解析を行う。
管理装置１３では、被災者と支援者に関して、物資あるいは役務について需給の状況の解析を行う。
【0310】
［実施形態について］
以上のように、本実施形態に係る災害情報処理システム１では、災害時に被災者が必要とする商品または役務の支援を効率よく行うことができる。
本実施形態に係る災害情報処理システム１では、災害時に、被災者が支援者からの支援を効率的に受けることを補助することが可能である。
以上のように、本実施形態に係る災害情報処理システム１では、災害時に被災者が必要とする商品または役務の支援を効率よく行うことができる。
本実施形態に係る災害情報処理システム１では、災害時に、被災者が支援者からの支援を効率的に受けることを補助することが可能である。
【0311】
本実施形態に係る災害情報処理システム１では、災害時に、例えば、それぞれの被災者に１または複数の支援者の情報を提示し、それぞれの被災者が希望する１以上の支援者から支援を受けることを選択的に指定して、支援を成立させることができる。このように、本実施形態では、被災者の側に支援者を選択する権限を持たせており、被災者に対する支援が適切に行われることを確保している。
【0312】
本実施形態に係る災害情報処理システム１では、災害時に災害時モードの画面表示（例えば、図６に示されるような画面表示）によって、被災者は自分のニーズに合った欲する物資あるいは役務を検索することが可能であり、支援者は提供可能な物資あるいは役務を登録することが可能である。
【0313】
本実施形態に係る災害情報処理システム１では、平常時モードと災害時モードとを切り替えることが可能である。これにより、本実施形態では、例えば、被災した人（被災者）とみなされる全員に自動的に災害時モードの画面表示（例えば、図６に示されるような画面表示など）を提供すること、優先度スコアが高い一部の被災者に対して優先的に災害時モードの画面表示（例えば、図６に示されるような画面表示など）を提供すること、災害時モードの画面表示を要求した被災者に対して災害時モードの画面表示（例えば、図６に示されるような画面表示など）を提供すること、などが可能である。
本実施形態に係る災害情報処理システム１では、例えば、平常時モードの画面表示に似た配置等の形式で災害時モードの画面表示（例えば、図６に示されるような画面表示）を提供することで、被災者にとって見慣れた形式で支援者の情報などを提供することができ、支援の効率性を向上させることができる。
本実施形態に係る災害情報処理システム１では、例えば、平常時モードの画面表示に似た配置等の形式で災害時モードの画面表示（例えば、図６に示されるような画面表示）を提供することで、被災者にとって見慣れた形式で支援者の情報などを提供することができ、支援の効率性を向上させることができる。
【0314】
本実施形態に係る災害情報処理システム１では、被災者の属性と被災状況に基づいて、支援の優先度を表すスコア（優先度スコア）を算出し、これにより、例えば、優先度スコアが高い被災者が優先的に支援を受けることができる状況を実現することができる。
本実施形態に係る災害情報処理システム１では、例えば、優先度スコアが高い被災者に対して優先的に、災害時モードの画面表示（例えば、図６に示されるような画面表示）を提供すること、あるいは、マッチング度が高い支援者（支援候補者）を選択可能とすること、などが可能である。
本実施形態に係る災害情報処理システム１では、例えば、優先度スコアが高い被災者に対して優先的に、災害時モードの画面表示（例えば、図６に示されるような画面表示）を提供すること、あるいは、マッチング度が高い支援者（支援候補者）を選択可能とすること、などが可能である。
【0315】
本実施形態に係る災害情報処理システム１では、例えば、被災者と支援者との距離に関する値と、被災者と支援者との需給の合致度を表す値と、を掛け合わせ、その結果に基づいて、マッチング可能なレコメンドされる候補者のリストを被災者に表示することができる。
【0316】
本実施形態に係る災害情報処理システム１では、例えば、被災者の位置の情報および支援者の位置の情報に基づいて、被災者にとって、自分が存在する場所の状況に合わせた支援を検索することが可能である。
【0317】
本実施形態に係る災害情報処理システム１では、例えば、被災マップの形式で支援者などの情報を閲覧することが可能であり、これにより、安全なルート、および、受け渡し場所などを把握し易くなる。
本実施形態に係る災害情報処理システム１では、例えば、被災者が、支援者（候補者）を表示する被災マップを見ることで、自己の周囲に存在する支援者（候補者）を把握して、そこからマッチングを成立させることも可能である。つまり、本実施形態では、被災者が被災マップが表示される画面において所定の操作を行うことで、支援者（候補者）の選択などの各種の指示等を行うことが可能である。
本実施形態に係る災害情報処理システム１では、例えば、被災者が、支援者（候補者）を表示する被災マップを見ることで、自己の周囲に存在する支援者（候補者）を把握して、そこからマッチングを成立させることも可能である。つまり、本実施形態では、被災者が被災マップが表示される画面において所定の操作を行うことで、支援者（候補者）の選択などの各種の指示等を行うことが可能である。
【0318】
なお、以上に説明した任意の装置における任意の構成部の機能を実現するためのプログラムを、コンピューター読み取り可能な記録媒体に記録し、そのプログラムをコンピューターシステムに読み込ませて実行するようにしてもよい。なお、ここでいう「コンピューターシステム」とは、オペレーティングシステムあるいは周辺機器等のハードウェアを含むものとする。また、「コンピューター読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ）－ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）等の可搬媒体、コンピューターシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピューター読み取り可能な記録媒体」とは、インターネット等のネットワークあるいは電話回線等の通信回線を介してプログラムが送信された場合のサーバーあるいはクライアントとなるコンピューターシステム内部の揮発性メモリーのように、一定時間プログラムを保持しているものも含むものとする。当該揮発性メモリーは、例えば、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）であってもよい。記録媒体は、例えば、非一時的記録媒体であってもよい。
【0319】
また、上記のプログラムは、このプログラムを記憶装置等に格納したコンピューターシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピューターシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワークあるいは電話回線等の通信回線のように情報を伝送する機能を有する媒体のことをいう。
また、上記のプログラムは、前述した機能の一部を実現するためのものであってもよい。さらに、上記のプログラムは、前述した機能をコンピューターシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイルであってもよい。差分ファイルは、差分プログラムと呼ばれてもよい。
また、上記のプログラムは、前述した機能の一部を実現するためのものであってもよい。さらに、上記のプログラムは、前述した機能をコンピューターシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイルであってもよい。差分ファイルは、差分プログラムと呼ばれてもよい。
【0320】
また、以上に説明した任意の装置における任意の構成部の機能は、プロセッサーにより実現されてもよい。例えば、実施形態における各処理は、プログラム等の情報に基づき動作するプロセッサーと、プログラム等の情報を記憶するコンピューター読み取り可能な記録媒体により実現されてもよい。ここで、プロセッサーは、例えば、各部の機能が個別のハードウェアで実現されてもよく、あるいは、各部の機能が一体のハードウェアで実現されてもよい。例えば、プロセッサーはハードウェアを含み、当該ハードウェアは、デジタル信号を処理する回路およびアナログ信号を処理する回路のうちの少なくとも一方を含んでもよい。例えば、プロセッサーは、回路基板に実装された１または複数の回路装置、あるいは、１または複数の回路素子のうちの一方または両方を用いて、構成されてもよい。回路装置としてはＩＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）などが用いられてもよく、回路素子としては抵抗あるいはキャパシターなどが用いられてもよい。
【0321】
ここで、プロセッサーは、例えば、ＣＰＵであってもよい。ただし、プロセッサーは、ＣＰＵに限定されるものではなく、例えば、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、あるいは、ＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）等のような、各種のプロセッサーが用いられてもよい。また、プロセッサーは、例えば、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）によるハードウェア回路であってもよい。また、プロセッサーは、例えば、複数のＣＰＵにより構成されていてもよく、あるいは、複数のＡＳＩＣによるハードウェア回路により構成されていてもよい。また、プロセッサーは、例えば、複数のＣＰＵと、複数のＡＳＩＣによるハードウェア回路と、の組み合わせにより構成されていてもよい。また、プロセッサーは、例えば、アナログ信号を処理するアンプ回路あるいはフィルター回路等のうちの１以上を含んでもよい。
【0322】
［変形例］
本実施形態に係る災害情報処理システム１では、管理装置１３は、平常時モードと災害時モードとを切り替える機能部（モード切替部３５１）と、被災者の優先度スコアの判定を行う機能部（需要者スコア算出部３７１、優先度判定部３７２）と、の両方を備える構成例を示したが、これらのうちの任意の一方の機能部を備えて他方の機能部を備えない構成が用いられてもよい。
本実施形態に係る災害情報処理システム１では、管理装置１３は、平常時モードと災害時モードとを切り替える機能部（モード切替部３５１）と、被災者の優先度スコアの判定を行う機能部（需要者スコア算出部３７１、優先度判定部３７２）と、の両方を備える構成例を示したが、これらのうちの任意の一方の機能部を備えて他方の機能部を備えない構成が用いられてもよい。
【0323】
一例として、管理装置１３は、平常時モードと災害時モードとを切り替える機能部（モード切替部３５１）を備えるが、被災者の優先度スコアに関する機能部（需要者スコア算出部３７１、優先度判定部３７２）を備えない構成が用いられてもよい。この構成では、管理装置１３は、平常時モードと災害時モードとの切り替えを行うことが可能であるが、被災者の優先度スコアの算出および優先度スコアに基づく処理を行わない。
【0324】
他の一例として、管理装置１３は、被災者の優先度スコアに関する機能部（需要者スコア算出部３７１、優先度判定部３７２）を備えるが、平常時モードと災害時モードとの切り替えに関する機能部（モード切替部３５１）を備えない構成が用いられてもよい。この構成では、例えば、管理装置１３は、災害が発生した場合に、災害時に専用な取引サービスを提供し、当該取引サービスにおいて被災者の優先度スコアの算出および優先度スコアに基づく処理を行う。
【0325】
［以上の実施形態について］
以上、この開示の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この開示の要旨を逸脱しない範囲の設計等も含まれる。
以上、この開示の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この開示の要旨を逸脱しない範囲の設計等も含まれる。
【0326】
なお、以上の実施形態では、例えば、各装置において、あらかじめ設定された情報（例えば、規則または演算式など）に基づいて、あらかじめ設定された態様で、各種の処理が行われる場合を示したが、将来的に、ＡＩ（Ａｒｔｉｆｉｃｉａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ）の機能が用いられてもよい。
例えば、以上の実施形態では、管理装置１３において、あらかじめ設定された情報（例えば、規則または演算式など）に基づいて、あらかじめ設定された態様で、平常時モードと災害時モードとを切り替える処理が行われる場合を示したが、将来的に、ＡＩの機能を用いて、平常時モードと災害時モードとを切り替える処理の一部または全部が行われる構成が用いられてもよい。なお、ＡＩの機能が、このような処理の微調整に利用されてもよい。
例えば、以上の実施形態では、管理装置１３において、あらかじめ設定された情報（例えば、規則または演算式など）に基づいて、あらかじめ設定された態様で、被災者の優先度スコアを算出する処理および優先度を判定する処理が行われる場合を示したが、将来的に、ＡＩの機能を用いて、被災者の優先度スコアを算出する処理および優先度を判定する処理の一部または全部が行われる構成が用いられてもよい。なお、ＡＩの機能が、このような処理の微調整に利用されてもよい。
例えば、以上の実施形態では、管理装置１３において、あらかじめ設定された情報（例えば、規則または演算式など）に基づいて、あらかじめ設定された態様で、平常時モードと災害時モードとを切り替える処理が行われる場合を示したが、将来的に、ＡＩの機能を用いて、平常時モードと災害時モードとを切り替える処理の一部または全部が行われる構成が用いられてもよい。なお、ＡＩの機能が、このような処理の微調整に利用されてもよい。
例えば、以上の実施形態では、管理装置１３において、あらかじめ設定された情報（例えば、規則または演算式など）に基づいて、あらかじめ設定された態様で、被災者の優先度スコアを算出する処理および優先度を判定する処理が行われる場合を示したが、将来的に、ＡＩの機能を用いて、被災者の優先度スコアを算出する処理および優先度を判定する処理の一部または全部が行われる構成が用いられてもよい。なお、ＡＩの機能が、このような処理の微調整に利用されてもよい。
【0327】
［付記］
（構成例１）～（構成例５）を示す。
（構成例１）～（構成例５）を示す。
【0328】
（構成例１）
第１Ａユーザーの第１Ａ端末装置を含む複数の端末装置と、管理装置と、を有する災害情報処理システムであって、
前記管理装置は、複数の前記端末装置に取引サービスを提供する取引サービス提供部を備え、
前記取引サービス提供部は、平常時に前記第１Ａユーザーが第２Ａユーザーと商取引することを可能とする第１Ａ画面表示を前記第１Ａ端末装置に提供する平常時モードと、災害時に被災者となった前記第１Ａユーザーが支援者となり得る前記第２Ａユーザーまたは第３Ａユーザーからの支援を成立させることを可能とする第２Ａ画面表示を前記第１Ａ端末装置に提供する災害時モードと、を切り替えるモード切替部を備える、
災害情報処理システム。
第１Ａユーザーの第１Ａ端末装置を含む複数の端末装置と、管理装置と、を有する災害情報処理システムであって、
前記管理装置は、複数の前記端末装置に取引サービスを提供する取引サービス提供部を備え、
前記取引サービス提供部は、平常時に前記第１Ａユーザーが第２Ａユーザーと商取引することを可能とする第１Ａ画面表示を前記第１Ａ端末装置に提供する平常時モードと、災害時に被災者となった前記第１Ａユーザーが支援者となり得る前記第２Ａユーザーまたは第３Ａユーザーからの支援を成立させることを可能とする第２Ａ画面表示を前記第１Ａ端末装置に提供する災害時モードと、を切り替えるモード切替部を備える、
災害情報処理システム。
【0329】
このような構成により、災害情報処理システムでは、平常時モードと災害時モードとの切り替えが行われる。これにより、災害情報処理システムでは、災害時に被災者が必要とする商品または役務の支援を効率よく行うことができる。
【0330】
ここで、図１の例では、需要側端末装置１１－１～１１－ｎおよび提供側端末装置１２－１～１２－ｍが、複数の端末装置の例である。
また、図１の例では、需要側ユーザー２１－１および需要側端末装置１１－１が、第１Ａユーザーおよび第１Ａ端末装置の例である。
また、第１Ａ画面表示は、平常時モードでの画面表示（例えば、図５に示されるような画面表示）である。
また、第２Ａ画面表示は、災害時モードでの画面表示（例えば、図６に示されるような画面表示）である。
また、図１の例では、提供側ユーザー２２－１が第２Ａユーザーの例であり、他の提供側ユーザー２２－２～２２－ｍが第３Ａユーザーの例である。
また、図１の例では、需要側ユーザー２１－１および需要側端末装置１１－１が、第１Ａユーザーおよび第１Ａ端末装置の例である。
また、第１Ａ画面表示は、平常時モードでの画面表示（例えば、図５に示されるような画面表示）である。
また、第２Ａ画面表示は、災害時モードでの画面表示（例えば、図６に示されるような画面表示）である。
また、図１の例では、提供側ユーザー２２－１が第２Ａユーザーの例であり、他の提供側ユーザー２２－２～２２－ｍが第３Ａユーザーの例である。
【0331】
（構成例２）
前記モード切替部は、前記災害時に、少なくとも所定の期間が経過したという条件が満たされた場合に、前記平常時モードの前記第１Ａ画面表示から前記災害時モードの前記第２Ａ画面表示へ切り替える、
（構成例１）に記載の災害情報処理システム。
前記モード切替部は、前記災害時に、少なくとも所定の期間が経過したという条件が満たされた場合に、前記平常時モードの前記第１Ａ画面表示から前記災害時モードの前記第２Ａ画面表示へ切り替える、
（構成例１）に記載の災害情報処理システム。
【0332】
このように、災害情報処理システムでは、平常時モードの画面表示から災害時モードの画面表示への切り替えの契機として、所定の期間の経過が用いられてもよい。これにより、災害情報処理システムでは、所定の期間の経過の有無に応じて、災害時モードの画面表示への切り替えの有無を制御することができる。
【0333】
（構成例３）
前記モード切替部は、前記災害時に、少なくとも前記第１Ａ端末装置から所定の指示を受けたという条件が満たされた場合に、前記平常時モードの前記第１Ａ画面表示から前記災害時モードの前記第２Ａ画面表示へ切り替える、
（構成例１）または（構成例２）に記載の災害情報処理システム。
前記モード切替部は、前記災害時に、少なくとも前記第１Ａ端末装置から所定の指示を受けたという条件が満たされた場合に、前記平常時モードの前記第１Ａ画面表示から前記災害時モードの前記第２Ａ画面表示へ切り替える、
（構成例１）または（構成例２）に記載の災害情報処理システム。
【0334】
このように、災害情報処理システムでは、平常時モードの画面表示から災害時モードの画面表示への切り替えの契機として、ユーザーなどの指示が用いられてもよい。これにより、災害情報処理システムでは、ユーザーなどの指示の有無に応じて、災害時モードの画面表示への切り替えの有無を制御することができる。
【0335】
（構成例４）
前記モード切替部は、前記災害時に、少なくとも前記第１Ａ端末装置の位置に基づいて、前記平常時モードの前記第１Ａ画面表示から前記災害時モードの前記第２Ａ画面表示へ切り替えるタイミングを制御する、
（構成例１）から（構成例３）のいずれか１つに記載の災害情報処理システム。
前記モード切替部は、前記災害時に、少なくとも前記第１Ａ端末装置の位置に基づいて、前記平常時モードの前記第１Ａ画面表示から前記災害時モードの前記第２Ａ画面表示へ切り替えるタイミングを制御する、
（構成例１）から（構成例３）のいずれか１つに記載の災害情報処理システム。
【0336】
このように、災害情報処理システムでは、平常時モードの画面表示から災害時モードの画面表示への切り替えの契機として、端末装置の位置が用いられてもよい。これにより、災害情報処理システムでは、端末装置の位置に応じて、災害時モードの画面表示への切り替えのタイミングを制御することができる。
【0337】
（構成例５）
前記管理装置は、さらに、
前記被災者となった前記第１Ａユーザーについて、前記被災者として支援を受ける際のの優先度を判定する優先度判定部を備える、
（構成例１）から（構成例４）のいずれか１つに記載の災害情報処理システム。
前記管理装置は、さらに、
前記被災者となった前記第１Ａユーザーについて、前記被災者として支援を受ける際のの優先度を判定する優先度判定部を備える、
（構成例１）から（構成例４）のいずれか１つに記載の災害情報処理システム。
【0338】
このような構成により、災害情報処理システムでは、被災者の優先度を利用することが可能である。
【0339】
（構成例６）～（構成例１０）を示す。
【0340】
（構成例６）
第１Ｂユーザーの第１Ｂ端末装置を含む複数の端末装置と、管理装置と、を有する災害情報処理システムであって、
前記管理装置は、災害時に被災者となった前記第１Ｂユーザーが支援者となり得る第２Ｂユーザーからの支援を成立させることを可能とする第１Ｂ画面表示を前記第１Ｂ端末装置に提供する取引サービス提供部と、
前記被災者となった前記第１Ｂユーザーについて、前記被災者として支援を受ける際の優先度を判定する優先度判定部と、
を備える、災害情報処理システム。
第１Ｂユーザーの第１Ｂ端末装置を含む複数の端末装置と、管理装置と、を有する災害情報処理システムであって、
前記管理装置は、災害時に被災者となった前記第１Ｂユーザーが支援者となり得る第２Ｂユーザーからの支援を成立させることを可能とする第１Ｂ画面表示を前記第１Ｂ端末装置に提供する取引サービス提供部と、
前記被災者となった前記第１Ｂユーザーについて、前記被災者として支援を受ける際の優先度を判定する優先度判定部と、
を備える、災害情報処理システム。
【0341】
このような構成により、災害情報処理システムでは、災害時に、被災者の優先度を利用することが可能である。これにより、災害情報処理システムでは、災害時に被災者が必要とする商品または役務の支援を効率よく行うことができる。
【0342】
ここで、図１の例では、需要側端末装置１１－１～１１－ｎおよび提供側端末装置１２－１～１２－ｍが、複数の端末装置の例である。
また、図１の例では、需要側ユーザー２１－１および需要側端末装置１１－１が、第１Ｂユーザーおよび第１Ｂ端末装置の例である。
また、第１Ｂ画面表示は、災害時モードでの画面表示（例えば、図６に示されるような画面表示）である。
また、図１の例では、提供側ユーザー２２－１が第２Ｂユーザーの例である。
また、図１の例では、需要側ユーザー２１－１および需要側端末装置１１－１が、第１Ｂユーザーおよび第１Ｂ端末装置の例である。
また、第１Ｂ画面表示は、災害時モードでの画面表示（例えば、図６に示されるような画面表示）である。
また、図１の例では、提供側ユーザー２２－１が第２Ｂユーザーの例である。
【0343】
（構成例７）
前記取引サービス提供部は、前記優先度が高い前記第１Ｂユーザーの前記第１Ｂ端末装置に前記第２Ｂユーザーに関する情報を提供し、前記優先度が低い第３Ｂユーザーの第３Ｂ端末装置に前記第２Ｂユーザーに関する情報を提供しない第１状態とする、
（構成例６）に記載の災害情報処理システム。
前記取引サービス提供部は、前記優先度が高い前記第１Ｂユーザーの前記第１Ｂ端末装置に前記第２Ｂユーザーに関する情報を提供し、前記優先度が低い第３Ｂユーザーの第３Ｂ端末装置に前記第２Ｂユーザーに関する情報を提供しない第１状態とする、
（構成例６）に記載の災害情報処理システム。
【0344】
このように、災害情報処理システムでは、被災者の優先度に応じて、支援者に関する情報提示の有無を制御することが可能である。
ここで、図１の例では、需要側ユーザー２１－２～２１－ｎおよび需要側端末装置１１－２～１１－ｎが、第３Ｂユーザーおよび第３Ｂ端末装置の例である。
ここで、図１の例では、需要側ユーザー２１－２～２１－ｎおよび需要側端末装置１１－２～１１－ｎが、第３Ｂユーザーおよび第３Ｂ端末装置の例である。
【0345】
（構成例８）
前記取引サービス提供部は、前記第１状態の後、少なくとも所定の期間が経過したという条件が満たされた場合に、前記第３Ｂ端末装置に前記第２Ｂユーザーに関する情報を提供する第２状態とする、
（構成例７）に記載の災害情報処理システム。
前記取引サービス提供部は、前記第１状態の後、少なくとも所定の期間が経過したという条件が満たされた場合に、前記第３Ｂ端末装置に前記第２Ｂユーザーに関する情報を提供する第２状態とする、
（構成例７）に記載の災害情報処理システム。
【0346】
このように、災害情報処理システムでは、被災者の優先度に応じて支援者に関する情報提示の有無を制御した後に、当該支援者に関する情報提示が無かった被災者（すべての被災者でもよい。）に対して当該支援者に関する情報提示を許可することができる。
【0347】
（構成例９）
前記優先度は、前記災害の発生前に取得された前記第１Ｂユーザーに関する情報、前記災害の発生後に取得された前記第１Ｂユーザーに関する情報、および、前記支援の需要と供給とのバランスのうちの１以上に基づく、
（構成例６）から（構成例８）のいずれか１つに記載の災害情報処理システム。
前記優先度は、前記災害の発生前に取得された前記第１Ｂユーザーに関する情報、前記災害の発生後に取得された前記第１Ｂユーザーに関する情報、および、前記支援の需要と供給とのバランスのうちの１以上に基づく、
（構成例６）から（構成例８）のいずれか１つに記載の災害情報処理システム。
【0348】
このように、災害情報処理システムでは、例えば、被災者に関する情報および支援の需給バランスに基づいて適度な優先度を求めることが可能である。
【0349】
（構成例１０）
前記取引サービス提供部は、平常時に前記第１Ｂユーザーが前記第２Ｂユーザーまたは第４Ｂユーザーと商取引することを可能とする第２Ｂ画面表示を前記第１Ｂ端末装置に提供する平常時モードと、災害時に前記被災者となった前記第１Ｂユーザーが支援者となり得る前記第２Ｂユーザーからの支援を成立させることを可能とする前記第１Ｂ画面表示を前記第１Ｂ端末装置に提供する災害時モードと、を切り替えるモード切替部を備える、
（構成例６）から（構成例９）のいずれか１つに記載の災害情報処理システム。
前記取引サービス提供部は、平常時に前記第１Ｂユーザーが前記第２Ｂユーザーまたは第４Ｂユーザーと商取引することを可能とする第２Ｂ画面表示を前記第１Ｂ端末装置に提供する平常時モードと、災害時に前記被災者となった前記第１Ｂユーザーが支援者となり得る前記第２Ｂユーザーからの支援を成立させることを可能とする前記第１Ｂ画面表示を前記第１Ｂ端末装置に提供する災害時モードと、を切り替えるモード切替部を備える、
（構成例６）から（構成例９）のいずれか１つに記載の災害情報処理システム。
【0350】
このように、災害情報処理システムでは、平常時モードと災害時モードとの切り替えが可能である。
ここで、図１の例では、提供側ユーザー２２－２～２２－ｍが、第４Ｂユーザーの例である。
また、第２Ｂ画面表示は、平常時モードでの画面表示（例えば、図５に示されるような画面表示）である。
ここで、図１の例では、提供側ユーザー２２－２～２２－ｍが、第４Ｂユーザーの例である。
また、第２Ｂ画面表示は、平常時モードでの画面表示（例えば、図５に示されるような画面表示）である。
【0351】
（構成例１１）～（構成例１２）を示す。
【0352】
（構成例１１）
平常時に第１Ａユーザーが第２Ａユーザーと商取引することを可能とする第１Ａ画面表示が前記第１Ａユーザーの第１Ａ端末装置に提供される平常時モードと、災害時に被災者となった前記第１Ａユーザーが支援者となり得る前記第２Ａユーザーまたは第３Ａユーザーからの支援を成立させることを可能とする第２Ａ画面表示が前記第１Ａ端末装置に提供される災害時モードと、を切り替える、
モード切替装置。
平常時に第１Ａユーザーが第２Ａユーザーと商取引することを可能とする第１Ａ画面表示が前記第１Ａユーザーの第１Ａ端末装置に提供される平常時モードと、災害時に被災者となった前記第１Ａユーザーが支援者となり得る前記第２Ａユーザーまたは第３Ａユーザーからの支援を成立させることを可能とする第２Ａ画面表示が前記第１Ａ端末装置に提供される災害時モードと、を切り替える、
モード切替装置。
【0353】
ここで、モード切替装置は、例えば、図４に示されるモード切替部３５１の機能を有する。
例えば、図１および図４に示される管理装置１３の機能が複数の装置に分散されて備えられてもよく、この場合に、モード切替装置は、少なくとも、モードを切り替える機能を有する。
なお、これら複数の装置は、例えば、同一の主体によって実施されてもよく、あるいは、２以上の異なる主体によって実施されてもよい。
例えば、図１および図４に示される管理装置１３の機能が複数の装置に分散されて備えられてもよく、この場合に、モード切替装置は、少なくとも、モードを切り替える機能を有する。
なお、これら複数の装置は、例えば、同一の主体によって実施されてもよく、あるいは、２以上の異なる主体によって実施されてもよい。
【0354】
（構成例１２）
災害時に被災者となった第１Ｂユーザーが支援者となり得る第２Ｂユーザーからの支援を成立させることを可能とする第１Ｂ画面表示が前記第１Ｂユーザーの第１Ｂ端末装置に提供される場合に、前記被災者となった前記第１Ｂユーザーについて、前記被災者として支援を受ける際の優先度を判定する、
優先度判定装置。
災害時に被災者となった第１Ｂユーザーが支援者となり得る第２Ｂユーザーからの支援を成立させることを可能とする第１Ｂ画面表示が前記第１Ｂユーザーの第１Ｂ端末装置に提供される場合に、前記被災者となった前記第１Ｂユーザーについて、前記被災者として支援を受ける際の優先度を判定する、
優先度判定装置。
【0355】
ここで、優先度判定装置は、例えば、図４に示される優先度判定部３７２の機能を有する。
例えば、図１および図４に示される管理装置１３の機能が複数の装置に分散されて備えられてもよく、この場合に、優先度判定装置は、少なくとも、優先度を判定する機能を有する。
なお、これら複数の装置は、例えば、同一の主体によって実施されてもよく、あるいは、２以上の異なる主体によって実施されてもよい。
例えば、図１および図４に示される管理装置１３の機能が複数の装置に分散されて備えられてもよく、この場合に、優先度判定装置は、少なくとも、優先度を判定する機能を有する。
なお、これら複数の装置は、例えば、同一の主体によって実施されてもよく、あるいは、２以上の異なる主体によって実施されてもよい。
【符号の説明】
【0356】
１…災害情報処理システム、１１－１～１１－ｎ…需要側端末装置、１２－１～１２－ｍ…提供側端末装置、１３…管理装置、２１－１～２１－ｎ…需要側ユーザー、２２－１～２２－ｍ…提供側ユーザー、１１１、２１１、３１１…入力部、１１２、２１２、３１２…出力部、１１３、２１３、３１３…通信部、１１４、２１４、３１４…記憶部、１１５、２１５、３１５…制御部、１３１、２３１…操作部、１３２、２３２…表示部、１３３、２３３…ＧＰＳ部、１５１…需要側属性情報取得部、１５２、３３３…需要情報取得部、１５３、２５３…候補者リスト取得部、１５４…成立通知部、２５１…提供側属性情報取得部、２５２、３３４…提供情報取得部、３３１…取引サービス提供部、３３２…属性情報取得部、３３５…マッチング部、３３６…候補者リスト生成部、３３７…成立通知受領部、３３８…需給状況解析部、３５１…モード切替部、３７１…需要者スコア算出部、３７２…優先度判定部、３７３…候補者抽出部、１０１１、１１１１、１２１１、１３１１…画面、１０３１、１０３２…出品内容領域、１１３１、１１３２…支援内容領域、１１５１…表示状態説明領域、１２３１、１３３１…平常時内容領域、１２５１、１３５１…表示切替指示領域、２０１１…需要側テーブル、２０３１…提供側テーブル、２１１１…算出ロジックテーブル、３０１１…被災マップ、３１１１…行動範囲、３２１１…ルート、Ａ１、Ａ２…被災者、Ｂ１～Ｂ３…支援者、Ｃ１、Ｃ２…画面、Ｄ１…被災者位置、Ｅ１～Ｅ３…支援者位置、Ｆ１～Ｆ６…災害発生位置
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】