JP2020017000A - サービス活動支援方法、サービス活動支援プログラム、及びシステム - Google Patents

Abstract

【課題】特定のエリア内でのサービス活動を支援するサービス活動支援方法を提供する。【解決手段】サービス活動支援方法は、仮想的に地図上に設定された特定のエリアの内側に位置する第１の端末装置から送信されたサービス活動の支援に関する要求を受信すると、前記特定のエリアの内側に位置する、前記第１の端末装置とは異なる、１以上の第２の端末装置を特定し、特定した前記１以上の第２の端末装置に対して、前記要求に関する情報を送信する、処理をコンピュータが実行する。【選択図】図１

Description

本件は、サービス活動支援方法、サービス活動支援プログラム、及びシステムに関する。

移動する端末が仮想的な柵（ジオフェンス）で範囲が規定された特定のエリア内に進入したことを検知すると、端末を保持するユーザにそのエリアへの進入を通知したり外部に発信したりするジオフェンシングと呼ばれる技術が知られている（例えば、特許文献１及び特許文献２参照）。

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

ここで、ボランティアといったサービス活動の分野では、ジオフェンスの技術を採用して、サービス活動を支援することが考えられる。

そこで、１つの側面では、特定のエリア内でのサービス活動を支援するサービス活動支援方法、サービス活動支援プログラム、及びシステムを提供することを目的とする。

１つの実施態様では、サービス活動支援方法は、仮想的に地図上に設定された特定のエリアの内側に位置する第１の端末装置から送信されたサービス活動の支援に関する要求を受信すると、前記特定のエリアの内側に位置する、前記第１の端末装置とは異なる、１以上の第２の端末装置を特定し、特定した前記１以上の第２の端末装置に対して、前記要求に関する情報を送信する、処理をコンピュータが実行する。

特定のエリア内でのサービス活動を支援することができる。

図１は実施形態１に係るサービス活動支援システムの一例である。 図２（ａ）は実施形態１に係る第１ユーザ端末の画面表示例である。図２（ｂ）及び（ｃ）は実施形態１に係る第２ユーザ端末の画面表示例である。 図３は第１ユーザ端末のハードウェア構成の一例である。 図４は管理サーバのハードウェア構成の一例である。 図５は実施形態１に係る第１ユーザ端末のブロック図の一例である。 図６は実施形態１に係るローカルエリア管理テーブルの一例である。 図７は実施形態１に係る管理サーバのブロック図の一例である。 図８（ａ）は実施形態１に係る静的エリア管理テーブルの一例である。図８（ｂ）は実施形態１に係るエリアサービス管理テーブルの一例である。図８（ｃ）は実施形態１に係るアプリデータ管理テーブルの一例である。図８（ｄ）は実施形態１に係る端末状態管理テーブルの一例である。 図９は実施形態１に係る第１ユーザ端末の動作の一例を示すフローチャートである。 図１０は実施形態１に係る管理サーバの動作の一例を示すフローチャートである。 図１１はサービスアプリ部の動作の一例を示すフローチャートである。 図１２は実施形態２に係るサービス活動支援システムの一例である。 図１３（ａ）乃至（ｄ）は実施形態２に係る第２ユーザ端末の画面表示例である。 図１４（ａ）乃至（ｃ）は実施形態２に係る第１ユーザ端末の画面表示例である。 図１５は実施形態２に係る第１ユーザ端末のブロック図の一例である。 図１６はローカルエリア管理テーブルの一例である。 図１７は実施形態２に係る管理サーバのブロック図の一例である。 図１８（ａ）は実施形態２に係る静的エリア管理テーブルの一例である。図１８（ｂ）は実施形態２に係るエリアサービス管理テーブルの一例である。図１８（ｃ）は実施形態２に係るアプリデータ管理テーブルの一例である。図１８（ｄ）は実施形態２に係る端末状態管理テーブルの一例である。 図１９は実施形態２に係る第１ユーザ端末の動作の一例を示すフローチャートである。 図２０は実施形態２に係る管理サーバの動作の一例を示すフローチャートである。 図２１は実施形態２に係るサービスアプリ部の動作の一例を示すフローチャートである。 図２２（ａ）は実施形態３に係る第１ユーザ端末の動作の一部を例示するフローチャートである。図２２（ｂ）及び（ｃ）は実施形態３に係る第１ユーザ端末及び第２ユーザ端末のそれぞれに表示される画面の一例である。 図２３（ａ）乃至（ｄ）は実施形態３に係る第１ユーザ端末及び第２ユーザ端末のそれぞれに表示される画面の他の一例である。 図２４は実施形態４に係る端末状態管理テーブルの一例である。 図２５（ａ）及び（ｂ）は実施形態４に係る第２ユーザ端末の画面表示例である。図２５（ｃ）及び（ｄ）は実施形態４に係る第１ユーザ端末の画面表示例である。 図２６は実施形態５に係る端末状態管理テーブルの一例である。 図２７（ａ）乃至（ｄ）は実施形態５に係る第１ユーザ端末の画面表示例である。 図２８は実施形態６に係るサービス活動支援システムの一例である。 図２９（ａ）及び（ｂ）は実施形態６に係る第１ユーザ端末の画面表示例である。 図３０は実施形態６に係る第１ユーザ端末のブロック図の一例である。 図３１は実施形態６に係るローカルエリア管理テーブルの一例である。 図３２は実施形態６に係る管理サーバのブロック図の一例である。 図３３（ａ）は実施形態６に係る端末状態管理テーブルの一例である。図３３（ｂ）は実施形態６に係る設定範囲管理テーブルの一例である。図３３（ｃ）は実施形態６に係る動的エリア管理テーブルの一例である。 図３４（ａ）は実施形態６に係る第１ユーザ端末の動作の一部を例示するフローチャートである。図３４（ｂ）は候補者検索処理の一例を示すフローチャートである。 図３５は実施形態６に係る管理サーバの動作の一部を例示するフローチャートである。

本明細書において、ボランティアを自発的な意志に基づき人や社会に有償又は無償で貢献するサービス活動と定義し、ボランティアを行う者を支援者、ボランティアを要請する者を要請者と定義する。以下、サービス活動を支援するサービス活動支援方法、サービス活動支援プログラム、及びシステムの一例であるサービス活動支援システムについて、複数の実施形態を説明する。

（実施形態１）
図１は実施形態１に係るサービス活動支援システムＳＴ１の一例である。図２（ａ）は実施形態１に係る第１ユーザ端末１００の画面表示例である。図２（ｂ）及び（ｃ）は実施形態１に係る第２ユーザ端末１５０，１６０の画面表示例である。サービス活動支援システムＳＴ１は管理サーバ２００を備えている。サービス活動支援システムＳＴ１の構成要素に１台の第１ユーザ端末１００と２台の第２ユーザ端末１５０，１６０を含む複数のユーザ端末を含めてもよい。図１では、第１ユーザ端末１００及び第２ユーザ端末１５０，１６０の一例として、スマートフォンが示されているが、タブレット端末やウェアラブルデバイスなどの端末装置であってもよい。一方、管理サーバ２００は様々なクラウドサービスを提供するデータセンターＤＣなどに設置されている。なお、管理サーバ２００をデータセンターＤＣに設置せず、観光資源の普及を目指す企業や団体の事務所などに設置してもよい。すなわち、管理サーバ２００はいわゆるオンプレミス型であってもよい。

第１ユーザ端末１００と第２ユーザ端末１５０，１６０と管理サーバ２００は、第１ユーザ端末１００及び第２ユーザ端末１５０，１６０が携帯基地局ＢＳの通信可能領域内に含まれていれば、いずれも無線通信ＷＬ及び通信ネットワークＮＷを介して互いに接続される。なお、無線通信ＷＬとしては、たとえばLong Term Evolution（ＬＴＥ）などが利用され、通信ネットワークＮＷとしては、たとえばインターネットが利用される。このように、第１ユーザ端末１００及び第２ユーザ端末１５０，１６０は無線通信ＷＬ及び通信ネットワークＮＷを利用して管理サーバ２００と接続することができる。したがって、第１ユーザ端末１００と第２ユーザ端末１５０，１６０は管理サーバ２００を介して互いに接続することができる。

ここで、図１に示すように、第１ユーザ端末１００はユーザＵＡによって携帯される。一方、第２ユーザ端末１５０はユーザＵＢによって携帯され、第２ユーザ端末１６０はユーザＵＣによって携帯される。第１ユーザ端末１００、第２ユーザ端末１５０，１６０には互いにメッセージを含む情報（以下、単にメッセージという）を送受信可能なアプリケーションソフトウェア（以下、単にアプリという）がインストールされている。本実施形態１にかかる管理サーバ２００は、第１ユーザ端末１００及び第２ユーザ端末１５０，１６０の現在の位置がいずれも同じサービスエリアＡＲ内に含まれる場合に、第１ユーザ端末１００、第２ユーザ端末１５０，１６０をグループ化し、互いにメッセージを送受信することを可能とする。したがって、例えば、ボランティアのように、あるユーザが何か困ったことがあった旨のメッセージを送ることで、同じサービスエリアＡＲ内に存在する別のユーザが支援を申し出ることができる。そして、別のユーザが、あるユーザにとって役立つ情報をメッセージで送るなどの、ボランティア支援サービスを実現することが可能となる。

例えば、図２（ａ）に示すように、ユーザＵＡが第１ユーザ端末１００に道案内の支援を要請するメッセージを入力すると、第１ユーザ端末１００は入力されたメッセージを送信する。第１ユーザ端末１００から送信されたメッセージは管理サーバ２００が受信し、管理サーバ２００は受信したメッセージを、同じサービスエリアＡＲに存在する第２ユーザ端末１５０，１６０に向けて送信する。第２ユーザ端末１５０，１６０はそれぞれメッセージを受信すると、受信したメッセージを表示する。

例えば、ユーザＵＣがメッセージを確認した場合、図２（ｂ）に示すように、ユーザＵＣは第２ユーザ端末１６０に道案内を支援するメッセージを入力する。また、ユーザＵＢがユーザＵＣの後にメッセージを確認すると、図２（ｃ）に示すように、ユーザＵＢは第２ユーザ端末１５０にユーザＵＡの行動に注意を促すメッセージを入力する。第２ユーザ端末１５０，１６０は入力されたメッセージをそれぞれ送信する。第２ユーザ端末１５０，１６０からそれぞれ送信されたメッセージは管理サーバ２００が受信し、管理サーバ２００は受信したメッセージを第１ユーザ端末１００に向けて送信する。このように、支援の要請者であるユーザＵＡと支援者であるユーザＵＢ及びユーザＵＣがサービスエリアＡＲ内でグルーピングされ、ユーザＵＡとユーザＵＢとユーザＵＣとの間でメッセージが交換されて共有される。なお、実施形態１では、道案内に関するメッセージの提供といったサービス活動を説明している。

以下、サービス活動支援システムＳＴ１の詳細について説明する。

図３は第１ユーザ端末１００のハードウェア構成の一例である。なお、第２ユーザ端末１５０，１６０については第１ユーザ端末１００と同様のハードウェア構成であるため、説明を省略する。図３に示すように、第１ユーザ端末１００は、ハードウェアプロセッサとしてのCentral Processing Unit（ＣＰＵ）１００Ａ、Random Access Memory（ＲＡＭ）１００Ｂ、Read Only Memory（ＲＯＭ）１００Ｃ、Non-Volatile Memory（ＮＶＭ）１００Ｄ及びRadio Frequency（ＲＦ）回路１００Ｅを含んでいる。ＲＦ回路１００Ｅにはアンテナ１００Ｅ´が接続されている。ＲＦ回路１００Ｅに代えて通信機能を実現するＣＰＵが利用されてもよい。

また、第１ユーザ端末１００は、ＧＰＳセンサ１００Ｆ、カメラ１００Ｇ、タッチパネル１００Ｈ、ディスプレイ１００Ｉ、及びスピーカ１００Ｊを含んでいる。ＣＰＵ１００Ａからスピーカ１００Ｊまでは、内部バス１００Ｋによって互いに接続されている。なお、ＣＰＵ１００Ａに代えてMicro Processing Unit（ＭＰＵ）をハードウェアプロセッサとして利用してもよい。

上述したＲＡＭ１００Ｂには、ＲＯＭ１００ＣやＮＶＭ１００Ｄに記憶されたプログラムがＣＰＵ１００Ａによって一時的に格納される。格納されたプログラムをＣＰＵ１００Ａが実行することにより、ＣＰＵ１００Ａは後述する各種の機能を実現し、また、後述する各種の処理を実行する。なお、プログラムは後述するフローチャートに応じたものとすればよい。

図４は管理サーバ２００のハードウェア構成の一例である。図４に示すように、管理サーバ２００は、少なくともハードウェアプロセッサとしてのＣＰＵ２００Ａ、ＲＡＭ２００Ｂ、ＲＯＭ２００Ｃ及びネットワークＩ／Ｆ（インタフェース）２００Ｄを含んでいる。ＣＰＵ２００Ａに代えてＭＰＵをハードウェアプロセッサとして利用してもよい。管理サーバ２００は、必要に応じて、Hard Disk Drive（ＨＤＤ）２００Ｅ、入力Ｉ／Ｆ２００Ｆ、出力Ｉ／Ｆ２００Ｇ、入出力Ｉ／Ｆ２００Ｈ、ドライブ装置２００Ｉの少なくとも１つを含んでいてもよい。ＣＰＵ２００Ａからドライブ装置２００Ｉまでは、内部バス２００Ｊによって互いに接続されている。すなわち、管理サーバ２００はコンピュータによって実現することができる。

入力Ｉ／Ｆ２００Ｆには、入力装置７１０が接続される。入力装置７１０としては、例えばキーボードやマウスなどがある。出力Ｉ／Ｆ２００Ｇには、表示装置７２０が接続される。表示装置７２０としては、例えば液晶ディスプレイがある。入出力Ｉ／Ｆ２００Ｈには、半導体メモリ７３０が接続される。半導体メモリ７３０としては、例えばUniversal Serial Bus（ＵＳＢ）メモリやフラッシュメモリなどがある。入出力Ｉ／Ｆ２００Ｈは、半導体メモリ７３０に記憶されたプログラムやデータを読み取る。入力Ｉ／Ｆ２００Ｆ及び入出力Ｉ／Ｆ２００Ｈは、例えばＵＳＢポートを備えている。出力Ｉ／Ｆ２００Ｇは、例えばディスプレイポートを備えている。

ドライブ装置２００Ｉには、可搬型記録媒体７４０が挿入される。可搬型記録媒体７４０としては、例えばCompact Disc（ＣＤ）−ＲＯＭ、Digital Versatile Disc（ＤＶＤ）といったリムーバブルディスクがある。ドライブ装置２００Ｉは、可搬型記録媒体７４０に記録されたプログラムやデータを読み込む。ネットワークＩ／Ｆ２００Ｄは、例えばＬＡＮポートや通信回路、ネットワークＩ／Ｆカードなどを備えている。ネットワークＩ／Ｆ２００Ｄは上述した通信ネットワークＮＷと接続される。

上述したＲＡＭ２００Ｂには、ＲＯＭ２００ＣやＨＤＤ２００Ｅに記憶されたプログラムがＣＰＵ２００Ａによって一時的に格納される。ＲＡＭ２００Ｂには、可搬型記録媒体７４０に記録されたプログラムがＣＰＵ２００Ａによって一時的に格納される。格納されたプログラムをＣＰＵ２００Ａが実行することにより、ＣＰＵ２００Ａは後述する各種の機能を実現し、また、後述する各種の処理を実行する。なお、プログラムは後述するフローチャートに応じたものとすればよい。

続いて、実施形態１に係る第１ユーザ端末１００の機能について説明する。

図５は実施形態１に係る第１ユーザ端末１００のブロック図の一例である。図６は実施形態１に係るローカルエリア管理テーブルＴ１の一例である。なお、第２ユーザ端末１５０，１６０については第１ユーザ端末１００と同様の機能構成であるため、説明を省略する。図５に示すように、第１ユーザ端末１００は基本アプリ部１１０とサービスアプリ部１２０を備えている。

基本アプリ部１１０は基本アプリをＣＰＵ１００ＡがＲＡＭ１００ＢやＮＶＭ１００Ｄと協働して実行することによって実現される。基本アプリはクラウドサービスを実現する個々のアプリ（以下、サービスアプリという）を利用できる状態に制御するアプリである。一方、サービスアプリ部１２０はサービスアプリをＣＰＵ１００ＡがＲＡＭ１００ＢやＮＶＭ１００Ｄと協働して実行することによって実現される。基本アプリとサービスアプリは親子関係を有し、親としての基本アプリが第１ユーザ端末１００にインストールされていない場合、ＣＰＵ１００Ａは子としてのサービスアプリを実行することができない。第１ユーザ端末１００はサービスアプリを利用する前に管理サーバ２００などから基本アプリを取得して、自身へのインストールを完了させておく必要がある。

基本アプリ部１１０は、図５に示すように、エリア設定部１１１、エリア情報記憶部１１２、エリア検知部１１３、端末ＩＤ管理部１１４、送信部としての検知結果送信部１１５、及びアプリデータ受信部１１６を備えている。エリア設定部１１１は管理サーバ２００からサービスエリアＡＲの範囲を定義する静的エリア情報を取得して、エリア情報記憶部１１２に保存する。これにより、図６に示すように、エリア情報記憶部１１２はサービスエリアＡＲを識別するエリア識別子「Ｘ」とサービスエリアＡＲの範囲を緯度、経度、及び半径により特定するエリア定義座標「ｘｘ，ｙｙ，ｒｒ」とを関連付けて記憶する。この結果、第１ユーザ端末１００に仮想的なサービスエリアＡＲがローカルエリア情報として設定される。

エリア検知部１１３は第１ユーザ端末１００のサービスエリアＡＲへの出入りを検知する。より詳しくは、エリア検知部１１３はＧＰＳセンサ１００Ｆが検出した第１ユーザ端末１００の位置情報がサービスエリアＡＲの外側から内側に通過すると、エリア検知部１１３はサービスエリアＡＲへの進入を表すエリアインを含むイン／アウト情報をエリア識別子「Ｘ」を含む検知エリア情報と共に出力する。逆に、エリア検知部１１３はＧＰＳセンサ１００Ｆが検出した第１ユーザ端末１００の位置情報がサービスエリアＡＲの内側から外側に通過すると、エリア検知部１１３はサービスエリアＡＲからの退出を表すエリアアウトを含むイン／アウト情報をエリア識別子「Ｘ」を含む検知エリア情報と共に出力する。なお、このようなＧＰＳセンサ１００Ｆを利用した位置情報の測位以外にも、管理サーバ２００に予め設置位置を登録したビーコン端末が発信する電波やＷｉ−Ｆｉ（登録商標）のアクセスポイントなどの電波を利用して位置情報を測位するようにしてもよいし、Near Field Communication（ＮＦＣ）により位置情報を測位するようにしてもよい。

端末ＩＤ管理部１１４は第１ユーザ端末１００を識別する端末ＩＤ（例えば端末ＩＤ「Ｔ−Ａ」など）を管理する。端末ＩＤにユーザＵＡの名前を関連付けてもよいし、端末ＩＤがその一部にユーザＵＡの名前（例えば名前「Ａさん」）を含んでいてもよい。名前は実名であってもよいし匿名であってもよい。検知結果送信部１１５はエリア検知部１１３からイン／アウト情報と検知エリア情報が出力されると、端末ＩＤ管理部１１４から端末ＩＤを取得し、端末ＩＤ、イン／アウト情報、及び検知エリア情報を含む検知結果を管理サーバ２００に向けて送信する。アプリデータ受信部１１６は検知結果を受信した管理サーバ２００から送信されたアプリデータを受信して、サービスアプリ部１２０に出力する。なお、アプリデータの詳細については後述する。

サービスアプリ部１２０はアプリデータ受信部１１６から出力されたアプリデータを受け付けると、受け付けたアプリデータを解凍して、アプリデータが情報交換に関するデータである場合には、メッセージ交換部１２１に展開する。メッセージ交換部１２１は、メッセージ入力部１２２、メッセージ送信部１２３、メッセージ受信部１２４、及びメッセージ表示部１２５を含んでいる。

メッセージ入力部１２２はユーザＵＡがタッチパネル１００Ｈを操作して入力したメッセージを受け付けて、メッセージ送信部１２３に出力する。メッセージ送信部１２３はメッセージ入力部１２２から出力されたメッセージを管理サーバ２００に向けて送信する。メッセージ受信部１２４は例えばユーザＵＢがタッチパネル１００Ｈを操作して入力したメッセージを管理サーバ２００から受信して、メッセージ表示部１２５に出力する。メッセージ表示部１２５はメッセージ受信部１２４から出力されたメッセージをディスプレイ１００Ｉに表示する。

続いて、実施形態１に係る管理サーバ２００の機能について説明する。

図７は実施形態１に係る管理サーバ２００のブロック図の一例である。図８（ａ）は実施形態１に係る静的エリア管理テーブルＴ２の一例である。図８（ｂ）は実施形態１に係るエリアサービス管理テーブルＴ３の一例である。図８（ｃ）は実施形態１に係るアプリデータ管理テーブルＴ４の一例である。図８（ｄ）は実施形態１に係る端末状態管理テーブルＴ５の一例である。

図７に示すように、管理サーバ２００は静的エリア記憶部２０１、エリアサービス記憶部２０２、アプリデータ記憶部２０３、及び端末状態記憶部２０４を構成要素として備えている。また、管理サーバ２００は検知結果受信部２０５、アプリ名取得部２０６、端末状態管理部２０７、アプリデータ取得部２０８、アプリデータ送信部２０９、及び管理部としての情報管理部２１０を構成要素として備えている。なお、管理サーバ２００が備えるこれらの構成要素の少なくとも１つを管理サーバ２００と異なる装置に設定し、構成要素同士を連携させるようにしてもよい。

ここで、静的エリア記憶部２０１、エリアサービス記憶部２０２、アプリデータ記憶部２０３、及び端末状態記憶部２０４は上述したＨＤＤ２００Ｅによって実現することができる。アプリ名取得部２０６、端末状態管理部２０７、及びアプリデータ取得部２０８は上述したＣＰＵ２００Ａによって実現することができる。検知結果受信部２０５及びアプリデータ送信部２０９は上述したネットワークＩ／Ｆ２００Ｄによって実現することができる。なお、情報管理部２１０のハードウェア要素については後述する。

静的エリア記憶部２０１は静的エリア情報を記憶する。静的エリア情報は、図８（ａ）に示すように、エリア識別子「Ｘ」とエリア定義座標「ｘｘ，ｙｙ，ｒｒ」とを含み、静的エリア管理テーブルＴ２によって管理される。したがって、上述した第１ユーザ端末１００のエリア設定部１１１は静的エリア記憶部２０１から静的エリア情報を取得することができる。

エリアサービス記憶部２０２はサービスエリアＡＲで提供されるサービスを含むサービス情報を記憶する。サービス情報は、図８（ｂ）に示すように、エリア識別子「Ｘ」と提供サービス「情報交換サービス」と提供サービスを実現するアプリのアプリ名「情報交換アプリ」とを含み、エリアサービス管理テーブルＴ３によって管理される。なお、エリアサービス記憶部２０２にて管理されるアプリ名に対応するアプリは、サービスアプリである。これにより、サービスエリアＡＲを識別するエリア識別子「Ｘ」が特定されると、特定されたエリア識別子「Ｘ」に対応付けられたアプリ名を抽出することができる。エリアサービス記憶部２０２は、情報交換サービスに限らず、様々なサービス情報を予め記憶している。

アプリデータ記憶部２０３はサービスアプリに関するアプリ情報を記憶する。アプリ情報は、図８（ｃ）に示すように、アプリ名「情報交換アプリ」とアプリを圧縮したアプリデータファイル（以下、アプリデータという）「情報交換．ｚｉｐ」を含み、アプリデータ管理テーブルＴ４によって管理される。これにより、アプリ名に応じたアプリデータを抽出することができる。アプリデータ記憶部２０３はアプリ名が異なる様々なアプリデータを予め記憶している。なお、情報交換．ｚｉｐは例えばチャット機能を実現するアプリを圧縮したアプリデータである。

端末状態記憶部２０４は端末状態情報を記憶する。端末状態情報は第１ユーザ端末１００や第２ユーザ端末１５０，１６０の現在の状態を表す情報である。現在の状態とは、具体的には、第１ユーザ端末１００や第２ユーザ端末１５０，１６０が現時点で所属するサービスエリアＡＲである。端末状態情報は、図８（ｄ）に示すように、端末ＩＤ「Ｔ−Ａ」とユーザ名「Ａさん」とエリア識別子「Ｘ」とを含み、端末状態管理テーブルＴ５によって管理される。本実施形態１では、図８（ｄ）に示すように、端末ＩＤ「Ｔ−Ａ」によって識別される第１ユーザ端末１００、端末ＩＤ「Ｔ−Ｂ」によって識別される第２ユーザ端末１５０、及び端末ＩＤ「Ｔ−Ｃ」によって識別される第２ユーザ端末１６０はいずれもエリア識別子「Ｘ」で識別されるサービスエリアＡＲに所属している。例えば、端末ＩＤ「Ｔ−Ｒ」によって識別されるユーザ端末（不図示）はエリア識別子「Ｙ」で識別される別のサービスエリア（不図示）に位置している。このように、端末状態記憶部２０４は端末ＩＤとユーザ名とエリア識別子とを対応付けて記憶している。

検知結果受信部２０５は第１ユーザ端末１００から送信された検知結果を受信する。上述したように、検知結果は端末ＩＤ、イン／アウト情報、及び検知エリア情報を含んでいる。検知結果受信部２０５は検知結果に含まれる端末ＩＤをアプリ名取得部２０６に出力せずに、検知結果に含まれるイン／アウト情報と検知エリア情報をアプリ名取得部２０６に出力する。検知結果受信部２０５は検知結果に含まれる端末ＩＤとイン／アウト情報と検知エリア情報のすべてを端末状態管理部２０７に出力する。

アプリ名取得部２０６は、検知結果受信部２０５から出力されたイン／アウト情報にエリアインが含まれると判断した場合、検知結果受信部２０５から出力された検知エリア情報に基づいて、エリアサービス記憶部２０２から検知エリア情報に応じたアプリ名を抽出する。したがって、アプリ名取得部２０６が検知エリア情報「Ｘ」を受け付けた場合、アプリ名「情報交換アプリ」を抽出する（図８（ｂ）参照）。アプリ名取得部２０６は、アプリ名を抽出すると、抽出したアプリ名をアプリデータ取得部２０８に出力する。

端末状態管理部２０７は、検知結果受信部２０５から端末ＩＤ、イン／アウト情報、及び検知エリア情報が出力されると、端末状態記憶部２０４が記憶する端末状態情報を更新する。例えば、端末状態管理部２０７は、イン／アウト情報にエリアインが含まれている場合、端末ＩＤとユーザ名と検知エリア情報とを関連付けた端末状態情報を端末状態記憶部２０４に保存する（図８（ｄ）参照）。逆に、端末状態管理部２０７は、イン／アウト情報にエリアアウトが含まれている場合、端末ＩＤとユーザ名と検知エリア情報とを含む端末状態情報を端末状態記憶部２０４から削除する。

アプリデータ取得部２０８は、検知結果受信部２０５から出力されたアプリ名に基づいて、アプリデータ記憶部２０３からアプリ名に応じたアプリデータを抽出する。アプリデータ取得部２０８は、アプリデータを抽出すると、抽出したアプリデータをアプリデータ送信部２０９に出力する。アプリデータ送信部２０９はアプリデータ取得部２０８から出力されたアプリデータを第１ユーザ端末１０００に向けて送信する。これにより、第１ユーザ端末１００のアプリデータ受信部１１６はアプリデータを受信することができる。

情報管理部２１０は端末状態管理部２０７と連携し、端末状態管理部２０７を介して、同じサービスエリアＡＲに位置する端末状態情報を確認して管理する。特に、情報管理部２１０は、メッセージ統合部２１１、メッセージ受信部２１０Ａ、メッセージ送信部２１０Ｂ、及び端末特定部２１０Ｃを構成要素として備えている。情報管理部２１０が備えるこれらの構成要素の少なくとも１つを情報管理部２１０以外の装置に設定し、構成要素同士を連携させるようにしてもよい。メッセージ統合部２１１及び端末特定部２１０Ｃは上述したＣＰＵ２００Ａによって実現することができる。メッセージ受信部２１０Ａ及びメッセージ送信部２１０Ｂは上述したネットワークＩ／Ｆ２００Ｄによって実現することができる。

メッセージ受信部２１０Ａは、第２ユーザ端末１６０から送信されたメッセージを受信する。端末特定部２１０Ｃは、メッセージ受信部２１０Ａが第２ユーザ端末１６０から送信されたメッセージを受信すると、受信したメッセージに基づいて端末状態管理部２０７と連携し、端末状態管理部２０７を介して、同じサービスエリアＡＲに位置する端末を特定する。メッセージ統合部２１１は、メッセージ受信部２１０Ａが第２ユーザ端末１６０から送信されたメッセージを受信すると、メッセージ受信部２１０Ａが受信したメッセージと第１ユーザ端末１００から送信されたメッセージとを統合する。なお、メッセージ統合部２１１は、第２ユーザ端末１６０から送信されたメッセージが、どのメッセージに対する返信なのかを識別し、対象のメッセージ（第１ユーザ端末１００から送信されたメッセージ）と結合する。メッセージ送信部２１０Ｂはメッセージ統合部２１１が２つのメッセージを統合した統合後のメッセージを、同じサービスエリアＡＲに位置する第１ユーザ端末１００及び第２ユーザ端末１５０，１６０に送信する。これにより、第１ユーザ端末１００及び第２ユーザ端末１５０，１６０はそれぞれ統合後のメッセージを含む画面を表示する（図２（ｂ）参照）。

続いて、図９及び図１０を参照して、サービス活動支援システムＳＴ１の動作を説明する。

図９は実施形態１に係る第１ユーザ端末１００の動作の一例を示すフローチャートである。特に、図９に示すフローチャートは基本アプリ部１１０によって実行される。上述したように、基本アプリ部１１０を実現する基本アプリは第１ユーザ端末１００に事前にインストールされている。図１０は実施形態１に係る管理サーバ２００の動作の一例を示すフローチャートである。なお、第２ユーザ端末１５０，１６０の動作については基本的に第１ユーザ端末１００の動作と同様であるため、説明を省略する。

まず、第１ユーザ端末１００に基本アプリがインストールされると、図９に示すように、エリア設定部１１１は静的エリア情報を取得する（ステップＳ１０１）。より詳しくは、エリア設定部１１１は、静的エリア記憶部２０１に対し静的エリア情報の第１ユーザ端末１００への送信を要求することにより、静的エリア情報を取得する。エリア設定部１１１は静的エリア情報を取得すると、エリア情報記憶部１１２に保存する。これにより、第１ユーザ端末１００にサービスエリアＡＲが設定される。

ステップＳ１０１の処理が完了すると、エリア検知部１１３はサービスエリアＡＲへの出入りを検知するまで後続の処理を待機する（ステップＳ１０２：ＮＯ）。エリア検知部１１３はサービスエリアＡＲへの出入りを検知すると（ステップＳ１０２：ＹＥＳ）、検知結果送信部１１５にイン／アウト情報を出力する（ステップＳ１０３）。例えば、エリア検知部１１３はサービスエリアＡＲへの進入を検知すると、エリアインを含むイン／アウト情報を検知エリア情報と共に出力する。エリア検知部１１３はサービスエリアＡＲからの退出を検知すると、エリアアウトを含むイン／アウト情報を検知エリア情報と共に出力する。

ステップＳ１０３の処理が完了すると、検知結果送信部１１５は検知結果を管理サーバ２００に向けて送信する（ステップＳ１０４）。より詳しくは、検知結果送信部１１５はエリア検知部１１３から出力されたイン／アウト情報を受け付けると、端末ＩＤ管理部１１４から端末ＩＤを取得する。検知結果送信部１１５は取得した端末ＩＤと、イン／アウト情報と、検知エリア情報とを含む検知結果を管理サーバ２００に向けて送信する。ステップＳ１０４の処理が完了すると、エリア検知部１１３は、ステップＳ１０２の処理で検知したサービスエリアＡＲへの出入りが、サービスエリアＡＲへの進入であったかを判断する（ステップＳ１０５）。

ここで、図１０に示すように、管理サーバ２００では、検知結果受信部２０５が検知結果を受信するか、情報管理部２１０がメッセージを受信するまで待機する（ステップＳ２０１：ＮＯ、ステップＳ２０７：ＮＯ）。仮に、検知結果受信部２０５が第１ユーザ端末１００から送信された検知結果を受信した場合（ステップＳ２０１：ＹＥＳ）、検知結果を、アプリ名取得部２０６および端末状態管理部２０７に出力する（ステップＳ２０２）。より詳しくは、検知結果受信部２０５は検知結果に含まれる端末ＩＤを除き、検知結果に含まれるイン／アウト情報と検知エリア情報をアプリ名取得部２０６に出力する。また、検知結果受信部２０５は検知結果に含まれる端末ＩＤ、イン／アウト情報、及び検知エリア情報のすべてを端末状態管理部２０７に出力する。

ステップＳ２０２の処理が完了すると、次いで、端末状態管理部２０７は端末状態情報を更新する（ステップＳ２０３）。より詳しくは、端末状態管理部２０７は検知結果受信部２０５から出力された端末ＩＤ、イン／アウト情報、及び検知エリア情報を受け付けると、イン／アウト情報を確認する。そして、イン／アウト情報にサービスエリアインが含まれている場合、端末状態管理部２０７は端末ＩＤと検知エリア情報とを対応付けて端末状態記憶部２０４に保存する。これにより、端末状態記憶部２０４は端末状態情報を記憶する（図８（ｄ）参照）。なお、イン／アウト情報にサービスエリアアウトが含まれている場合、端末状態管理部２０７は受け付けた端末ＩＤと検知エリア情報の組み合わせに応じた端末状態情報を端末状態記憶部２０４から削除する。

ステップＳ２０３の処理が完了すると、次いで、アプリ名取得部２０６はアプリ名を取得して出力する（ステップＳ２０４）。より詳しくは、アプリ名取得部２０６は検知結果受信部２０５から出力されたイン／アウト情報と検知エリア情報を受け付ける。アプリ名取得部２０６は受け付けたイン／アウト情報にエリアインが含まれると判断した場合、エリアサービス記憶部２０２にアクセスし、受け付けた検知エリア情報に応じたアプリ名を取得する。アプリ名取得部２０６はアプリ名を取得すると、取得したアプリ名をアプリデータ取得部２０８に出力する。

ステップＳ２０４の処理が完了すると、次いで、アプリデータ取得部２０８はアプリデータを取得して出力する（ステップＳ２０５）。より詳しくは、アプリデータ取得部２０８はアプリ名取得部２０６から出力されたアプリ名を受け付けると、アプリデータ記憶部２０３にアクセスし、受け付けたアプリ名に応じたアプリデータを取得する。本実施形態１では、アプリデータ取得部２０８はアプリデータ「情報交換．ｚｉｐ」を取得する（図８（ｃ）参照）。アプリデータ取得部２０８はアプリデータを取得すると、取得したアプリデータをアプリデータ送信部２０９に出力する。ステップＳ２０５の処理が完了すると、次いで、アプリデータ送信部２０９はアプリデータを、検知結果を送信した第１ユーザ端末１００に向けて送信する（ステップＳ２０６）。ステップＳ２０６の処理が完了すると、再び、検知結果受信部２０５が検知結果を受信するか、メッセージ受信部２１０Ａがメッセージを受信するまで待機する。なお、ステップＳ２０３の処理とステップＳ２０４乃至Ｓ２０６の処理は処理の順序が逆であってもよいし、並行して実行されてもよい。

図９に戻り、第１ユーザ端末１００では、ステップＳ１０５の処理において、エリア検知部１１３がサービスエリアＡＲへの進入を検知した場合（ステップＳ１０５：ＹＥＳ）、管理サーバ２００からアプリデータが動的に送信されるため、アプリデータ受信部１０６はアプリデータの受信が完了するまで待機する（ステップＳ１０６：ＮＯ）。そして、アプリデータ受信部１０６はアプリデータの受信が完了すると（ステップＳ１０６：ＹＥＳ）、サービスアプリ部１２０にアプリを実行させる（ステップＳ１０７）。これにより、サービスアプリ部１２０はアプリを実行する。より詳しくは、アプリデータ受信部１０６はアプリデータの受信が完了すると、受信したアプリデータをサービスアプリ部１２０に出力する。

サービスアプリ部１２０はアプリデータを受け付けると、受け付けたアプリデータを解凍して展開する。本実施形態１では、サービスアプリ部１２０はアプリデータ「情報交換．ｚｉｐ」を受け付けるため、アプリデータを解凍して展開して、実行することで、メッセージ交換部１２１を生成する。これにより、第２ユーザ端末１５０，１６０が第１ユーザ端末１００と同じサービスエリアＡＲに存在する場合に同様に実現される、第２ユーザ端末１５０，１６０のメッセージ交換部と、第１ユーザ端末１００のメッセージ交換部１２１とは、メッセージを交換することができる。

具体的には、第１ユーザ端末１００がサービスエリアＡＲの外側から内側に進入した場合、第１ユーザ端末１００は第１ユーザ端末１００のサービスエリアＡＲへの進入を検知した管理サーバ２００から動的に送信されたアプリデータを受信する。同様に、第２ユーザ端末１５０，１６０についても、サービスエリアＡＲの外側から内側に進入した場合、第２ユーザ端末１５０，１６０は第２ユーザ端末１５０，１６０のサービスエリアＡＲへの進入を検知した管理サーバ２００から動的に送信されたアプリデータを受信する。そして、詳細は後述するが、管理サーバ２００によって、メッセージの配信が制御されることにより、同じサービスエリアＡＲ内に存在する第１ユーザ端末１００と第２ユーザ端末１５０，１６０は、受信したアプリデータを解凍して展開したアプリを使って、メッセージを交換することができる。

なお、ステップＳ１０５の処理において、エリア検知部１１３がサービスエリアＡＲからの退出を検知した場合（ステップＳ１０５：ＮＯ）、サービスアプリ部１２０にアプリの動作を終了させる（ステップＳ１０８）。これにより、アプリが動作中であれば、サービスアプリ部１２０はアプリの動作を終了する。すなわち、第１ユーザ端末１００がサービスエリアＡＲの内側から外側に通過した場合、メッセージ交換部１２１によるメッセージの交換が中止されて終了する。

さらに、図１１を図１０と共に参照して、上述したステップＳ１０７の詳細について説明する。

図１１はサービスアプリ部１２０の動作の一例を示すフローチャートである。図１１に示すように、サービスアプリ部１２０がメッセージ交換部１２１を生成すると、メッセージ入力部１２２はメッセージが入力されたか否かを判断する（ステップＳ１１１）。メッセージ入力部１２２はメッセージが入力されたと判断した場合（ステップＳ１１１：ＹＥＳ）、メッセージ送信部１２３は入力されたメッセージを管理サーバ２００に向けて送信する（ステップＳ１１２）。より詳しくは、メッセージ送信部１２３は端末ＩＤ管理部１１４から端末ＩＤを取得し、取得した端末ＩＤと共にメッセージを送信する。一方、メッセージ入力部１２２はメッセージが入力されていないと判断した場合（ステップＳ１１１：ＮＯ）、ステップＳ１１２の処理をスキップする。

管理サーバ２００では、図１０に示すように、メッセージ受信部２１０Ａがメッセージを受信すると（ステップＳ２０７：ＹＥＳ）、端末特定部２１０Ｃが端末状態情報を確認する（ステップＳ２０８）。より詳しくは、端末特定部２１０Ｃは端末状態管理部２０７に情報確認依頼を出力する。情報確認依頼は、端末状態管理部２０７に端末状態情報の確認を依頼する情報であって、第１ユーザ端末１００から送信された端末ＩＤを含んでいる。端末状態管理部２０７は情報確認依頼を受け付けると、情報確認依頼に含まれる端末ＩＤとエリア識別子が共通する他の端末ＩＤを取得する。例えば、情報確認依頼に端末ＩＤ「Ｔ−Ａ」が含まれている場合、端末状態情報において端末ＩＤ「Ｔ−Ａ」にはエリア識別子「Ｘ」が対応付けられているため（図８（ｄ）参照）、このエリア識別子「Ｘ」と共通するエリア識別子「Ｘ」と対応付けられた端末ＩＤ「Ｔ−Ｂ」及び端末ＩＤ「Ｔ−Ｃ」を取得する。端末状態管理部２０７は端末ＩＤを取得すると、取得した端末ＩＤを端末特定部２１０Ｃに出力する。これにより、端末特定部２１０Ｃは第１ユーザ端末１００が所属するサービスエリアＡＲと同じサービスエリアＡＲに所属する第２ユーザ端末１５０,１６０を特定することができる。

ステップＳ２０８の処理が完了すると、メッセージ統合部２１１はメッセージを統合する（ステップＳ２０９）。より詳しくは、メッセージ統合部２１１はメッセージ受信部２１０Ａが受信したメッセージと、所属するサービスエリアＡＲが共通し、かつ、メッセージ受信部２１０Ａが受信したメッセージに連続する過去のメッセージとを統合する。なお、過去のメッセージが存在しない場合、メッセージ統合部２１１はステップＳ２０９の処理をスキップする。ステップＳ２０９の処理が完了すると、メッセージ送信部２１０Ｂは統合したメッセージを送信する（ステップＳ２１０）。

つまり、管理サーバ２００は、第１ユーザ端末１００からのメッセージを受けて、当該第１ユーザ端末１００のメッセージを配信する、第２ユーザ端末１５０，１６０を特定することができる。なお、あるユーザ端末のメッセージを配信する際に、配信対象のユーザ端末を限定することを、グルーピングと称する。さらに、第１ユーザ端末１００と第２ユーザ端末１５０，１６０には、各々、サービスエリアＡＲへの進入を契機に、アプリ名「情報交換アプリ」のアプリがインストールされているため、当該アプリを使って、グルーピングされた範囲で、メッセージのやり取りを行うことができる。言い換えると、グルーピングされたユーザ端末のユーザは、互いの個人情報（電話番号、電子メールアドレス等）を、互いに明かすことなく、管理サーバ２００により配信されたアプリデータのアプリを使って、ボランティアなどのサービス活動にかかるメッセージをやり取りすることができる。

より詳しくは、メッセージ送信部２１０Ｂは所属するサービスエリアＡＲが共通する第１ユーザ端末１００及び第２ユーザ端末１５０，１６０のそれぞれに統合したメッセージを送信する。なお、メッセージ受信部２１０Ａは第１ユーザ端末１００から送信された端末ＩＤを受信している。また、端末特定部２１０Ｃは端末状態管理部２０７が取得して出力した端末ＩＤを受け付けている。このため、メッセージ受信部２１０Ａが受信した端末ＩＤと、端末特定部２１０Ｃが受けつけた端末ＩＤとによって、端末特定部２１０Ｃは第１ユーザ端末１００及び第２ユーザ端末１５０，１６０を特定することができる。この結果、メッセージ送信部２１０Ｂは端末特定部２１０Ｃが特定した第１ユーザ端末１００及び第２ユーザ端末１５０，１６０に統合後のメッセージを送信することができる。ステップＳ２１０の処理が完了すると、再び、検知結果受信部２０５が検知結果を受信するか、メッセージ受信部２１０Ａがメッセージを受信するまで待機する。

一方、図１１に示すステップＳ１１１又はＳ１１２の処理が完了した場合、第１ユーザ端末１００では、メッセージ受信部１２４がメッセージを受信したか否かを判断する（ステップＳ１１３）。このメッセージは統合後のメッセージであるが、上述したように、過去のメッセージが存在しない場合には、統合されていないメッセージの場合もある。メッセージ受信部１２４はメッセージを受信したと判断した場合（ステップＳ１１３：ＹＥＳ）、受信したメッセージをメッセージ表示部１２５に出力する（ステップＳ１１４）。メッセージ表示部１２５はメッセージ受信部１２４から出力されたメッセージを受け付けると、受け付けたメッセージを表示する（ステップＳ１１５）。これにより、第１ユーザ端末１００は統合後のメッセージを含む画面を表示する。また、第２ユーザ端末１５０，１６０も第１ユーザ端末１００と同様に統合後のメッセージを含む画面を表示する。逆に、統合されていないメッセージをメッセージ受信部１２４が受信した場合、第１ユーザ端末１００は統合されていないメッセージを含む画面を表示する。このような画面を第２ユーザ端末１５０，１６０も同様に表示する。なお、メッセージ受信部１２４はメッセージを受信していないと判断した場合（ステップＳ１１３：ＮＯ）、後続のステップＳ１１４，Ｓ１１５の処理は実行されずに、スキップされて終了する。

以上、図１から図１１を参照して、実施形態１を説明した。本実施形態１によって、ボランティアであれば、範囲を規定できるジオフェンスを利用して仮想的に地図上に設定されたあるエリア内で複数のユーザを繋げ、一時的にメッセージ等をやり取りするようなシーンへ応用することができる。また、上述したように、本実施形態１においては、あるエリアに存在する複数のユーザは、互いの個人情報（電話番号、電子メールアドレス等）を、互いに明かすことなく、管理サーバ２００により配信されたアプリ名「情報交換アプリ」を有するアプリデータに応じたアプリを使って、ボランティアなどのサービス活動にかかるメッセージをやり取りすることができる。

実施形態１を運用するにあたっては、さらに、以下について、技術的に検討しうる。

（１）属性
支援者によっては、ある対象について協力を要請する要請者がいる場合に、そのボランティア対象に対応できる場合もあれば、対応できない場合もある。なお、ボランティア対象とは、ボランティアなどのサービス活動にて、提供される行為、または提供される物品を示す。

このため、要請者がボランティアを要請しても、支援者の属性によっては要請者の要請に支援者が協力できない場合がある。例えば、要請者が実施形態１の技術を利用して支援者に道案内を要請するメッセージを送信しても、支援者が地理の知識に乏しく支援に自信がなければ、支援者は要請者の要請を断りたいこともある。仮に、支援者は要請者の要請を断らない場合、支援者は要請者に誤った道を案内するおそれがあり、この結果、要請者と支援者との間で無用なトラブルが発生する可能性がある。このように、属性の１つとして地理の知識を挙げたが、機械（例えばカメラなど）の操作能力や撮影技術、非母国語の言語能力、年齢や性別に応じた体力なども、支援者の属性として挙げられる。なお、属性については協力姿勢と言い換えてもよい。

（２）コンディション（状況）
上述した属性を考慮しても、偶発的に支援者が要請者の要請に対応できない状況におかれている場合もある。このような状況としては、例えば支援者が別の要請者の要請に応じている場合などがある。偶発的に支援者が要請者の要請に対応できない状況を無視して、要請者からの支援の要請が配信された場合に、支援者にとって煩わしいことがある。

（３）スキル（技能レベル）
上述した属性を考慮しても、支援者のスキルにはバラツキがあり、支援者の信頼度やボランティアの質を保つことが難しい。例えば、要請者が高度の撮影技術を有する支援者を求めていても、支援者の撮影技術を客観的に判断する情報がないため、撮影技術が低い支援者が誤って要請者の要請に応じると、要請者と支援者との間でトラブルが生じるおそれがある。

（４）距離
ボランティアといっても、ボランティアを要請する対象によっては要請者と支援者との距離が問題になる場合がある。例えば、至急を要する写真の撮影であれば、同じサービスエリアＡＲに存在するとしても、要請者に対して、所定距離内に存在する支援者であることが望ましい。しかしながら、距離に応じて要請者と支援者とを精度良く適合（マッチング）させることは難しい。

以上説明した事項について検討した、複数の実施形態について図面を参照して説明する。

（実施形態２）
図１２は実施形態２に係るサービス活動支援システムＳＴ２の一例である。図１３（ａ）乃至（ｄ）は実施形態２に係る第２ユーザ端末１６０の画面表示例である。図１４（ａ）乃至（ｃ）は実施形態２に係る第１ユーザ端末１００の画面表示例である。サービス活動支援システムＳＴ２は管理サーバ２００を備えている。サービス活動支援システムＳＴ２の構成要素に１台の第１ユーザ端末１００と５台の第２ユーザ端末１５０，１６０，１７０，１８０，１９０とを含む複数のユーザ端末を含めてもよい。第２ユーザ端末１７０，１８０，１９０と管理サーバ２００は、第２ユーザ端末１７０，１８０，１９０が携帯基地局ＢＳの通信可能領域内に含まれていれば、第２ユーザ端末１５０，１６０と同様に、いずれも無線通信ＷＬ及び通信ネットワークＮＷを介して互いに接続される。このように、第２ユーザ端末１７０，１８０，１９０も、第１ユーザ端末１００及び第２ユーザ端末１５０，１６０と同様に、無線通信ＷＬ及び通信ネットワークＮＷを利用して管理サーバ２００と接続することができる。

ここで、図１２に示すように、第２ユーザ端末１７０はユーザＵＤによって携帯される。第２ユーザ端末１８０はユーザＵＥによって携帯される。第２ユーザ端末１９０はユーザＵＦによって携帯される。第１ユーザ端末１００、第２ユーザ端末１５０，１６０，１７０，１８０，１９０はいずれもサービスエリアＡＲ内に位置するため、第１ユーザ端末１００、第２ユーザ端末１５０，１６０，１７０，１８０，１９０には互いにメッセージを送受信可能な機能を含むボランティアを支援する特定のアプリ（以下、ボランティアアプリという）がインストールされている。なお、ボランティアアプリは、サービスアプリの一例である。管理サーバ２００の制御の下、同じサービスエリアＡＲ内において第１ユーザ端末１００は、ボランティアの要請を第２ユーザ端末１５０，１６０，１７０，１８０，１９０に対して送信することができる。また、第２ユーザ端末１５０，１６０，１７０，１８０，１９０はいずれも当該要請に応じた支援に関する情報を送信することができる。

ボランティアアプリにより、例えば図１３（ａ）及び（ｂ）に示すように、ユーザＵＣは第２ユーザ端末１６０にユーザＵＣ自身が支援できるボランティア対象の種別（なお、以下、ボランティア可能種別と称する）を管理サーバ２００に登録することができる。具体的には、まず、ユーザＵＣが第２ユーザ端末１６０に表示されたボランティアアプリのスタート画面１０においてボランティア可能種別を登録する操作ボタンＢＴ１を押下する操作を行う。第２ユーザ端末１６０は当該操作を検出すると、ボランティア種別登録画面２０を表示する。ユーザＵＣが第２ユーザ端末１６０に表示されたボランティア種別登録画面２０において、例えばボランティア可能種別として情報提供を選択するチェックボックスＢＸ１を押下する操作を行う。第２ユーザ端末１６０は当該操作を検出すると、選択されたボランティア可能種別が端末ＩＤと共に管理サーバ２００に登録される。このような操作をユーザＵＢも第２ユーザ端末１５０に対して同様に行い、ユーザＵＤも第２ユーザ端末１７０に対して同様に行う。

一方、ボランティアアプリにより、例えば図１４（ａ）及び（ｂ）に示すように、ユーザＵＡは第１ユーザ端末１００に要請を望むボランティアの種別に応じた支援者を選定することができる。具体的には、まず、ユーザＵＡが第１ユーザ端末１００に表示されたスタート画面１０においてボランティアの種別として情報提供を選択する操作ボタンＢＴ２を押下する操作を行う。第１ユーザ端末１００は当該操作を検出すると、マッチング画面３０を表示する。マッチング画面３０には、ユーザＵＡと同じサービスエリアＡＲに存在し、かつ、管理サーバ２００にボランティア可能種別として情報提供を登録した支援者について、名前とその支援者に連絡するための複数の操作ボタンＢＴ３が、含まれている。ユーザＵＡが第１ユーザ端末１００に表示されたマッチング画面３０において、例えばユーザＵＣに連絡する操作ボタンＢＴ３を押下する操作を行う。第１ユーザ端末１００は当該操作を検出すると、図１４（ｃ）に示すように、情報交換画面４０を表示する。これにより、要請者であるユーザＵＡは情報提供のボランティアを支援者であるユーザＵＣに要請することができる。

ここで、ユーザＵＡが操作ボタンＢＴ３を押下する操作を行うと、管理サーバ２００の処理に基づいて、図１３（ｃ）に示すように、第２ユーザ端末１６０はマッチング画面３０と異なる別のマッチング画面３１を表示する。例えば、ユーザＵＣが第２ユーザ端末１６０に表示されたマッチング画面３１においてユーザＵＡの要請を引き受ける操作ボタンＢＴ４を押下する操作を行う。第２ユーザ端末１６０は当該操作を検出すると、図１３（ｄ）に示すように、情報交換画面４０を表示する。これにより、支援者であるユーザＵＣは要請者であるユーザＵＡの要請に応じた情報を提供してユーザＵＡを支援することができる。

続いて、実施形態２に係る第１ユーザ端末１００の機能について説明する。

図１５は実施形態２に係る第１ユーザ端末１００のブロック図の一例である。図１６はローカルエリア管理テーブルＴ１１の一例である。なお、第２ユーザ端末１５０，１６０，１７０，１８０，１９０については第１ユーザ端末１００と同様の機能構成であるため、説明を省略する。また、第１ユーザ端末１００及び第２ユーザ端末１５０，１６０，１７０，１８０，１９０のハードウェア構成については、図３を参照して説明したハードウェア構成と同様であるため、説明を省略する。図１５に示すように、第１ユーザ端末１００は基本アプリ部１１０とサービスアプリ部１２０を備えている。

基本アプリ部１１０は、エリア設定部１１１、エリア情報記憶部１１２、エリア検知部１１３、端末ＩＤ管理部１１４、検知結果送信部１１５、及びアプリデータ受信部１１６を備えている。エリア設定部１１１は管理サーバ２００から静的エリア情報を取得して、エリア情報記憶部１１２に保存する。これにより、図１６に示すように、エリア情報記憶部１１２はエリア識別子「Ｘ」とエリア定義座標「ｘｘ，ｙｙ，ｒｒ」とを関連付けて記憶する。この結果、第１ユーザ端末１００に仮想的なサービスエリアＡＲがローカルエリア情報として設定される。

エリア検知部１１３は第１ユーザ端末１００のサービスエリアＡＲへの出入りを検知する。端末ＩＤ管理部１１４は第１ユーザ端末１００を識別する端末ＩＤ（例えば端末ＩＤ「Ｔ−Ａ」など）を管理する。端末ＩＤにユーザＵＡの名前を関連付けてもよいし、端末ＩＤがその一部にユーザＵＡの名前（例えば名前「Ａさん」）を含んでいてもよい。検知結果送信部１１５は検知結果を管理サーバ２００に向けて送信する。アプリデータ受信部１１６は管理サーバ２００から送信されたアプリデータを受信して、サービスアプリ部１２０に出力する。なお、実施形態２に係るアプリデータの詳細については後述する。

サービスアプリ部１２０はアプリデータ受信部１１６から出力されたアプリデータを受け付けると、受け付けたアプリデータを解凍して、メッセージ交換部１２１、ボランティア種別登録部１２６、希望種別選択部１２７、候補者取得部１２８、及びマッチング画面表示部１２９に展開する。なお、メッセージ交換部１２１は、実施形態１で説明したように、図５における、メッセージ入力部１２２、メッセージ送信部１２３、メッセージ受信部１２４、及びメッセージ表示部１２５（図１５ではいずれも不図示）を含んでいる。

ボランティア種別登録部１２６は、支援者であるユーザＵＣなどの操作に基づいて、ボランティア可能種別を管理サーバ２００に登録する。より詳しくは、図１３（ｂ）を参照して説明したように、ボランティア種別登録部１２６はボランティア可能種別を登録する操作を検出した場合、端末ＩＤ管理部１１４が管理する端末ＩＤを取得し、取得した端末ＩＤとチェックボックスＢＸ１で指定された可能種別とを対応付けて管理サーバ２００に向けて送信する。

希望種別選択部１２７は、要請者であるユーザＵＡの操作に基づいて、ボランティアの希望種別を管理サーバ２００に送信する。より詳しくは、図１４（ａ）を参照して説明したように、希望種別選択部１２７はボランティアの希望種別を選択する操作を検出した場合、選択された希望種別を候補者取得部１２８に出力する。候補者取得部１２８は希望種別選択部１２７から出力された希望種別を受け付けると、端末ＩＤ管理部１１４から端末ＩＤを取得し、取得した端末ＩＤと受け付けた希望種別を管理サーバ２００に送信する。候補者取得部１２８は端末ＩＤと希望種別を送信すると、管理サーバ２００から、第１ユーザ端末１００と同じサービスエリアＡＲに存在し、かつ、希望種別に応じた支援者の情報を候補者情報として取得する。候補者取得部１２８は取得した候補者情報をマッチング画面表示部１２９に出力する。

マッチング画面表示部１２９は候補者取得部１２８から出力された候補者情報を表示する。より詳しくは、図１４（ｂ）を参照して説明したように、マッチング画面表示部１２９は候補者情報を含むマッチング画面３０を表示する。これにより、ユーザＵＡといったボランティアの要請者はユーザＵＣといったボランティアの支援者を選択することができる。マッチング画面表示部１２９はマッチング画面３０において特定の候補者情報が選択されたことを検出すると、選択された候補者情報をメッセージ交換部１２１に通知する。これにより、メッセージ交換部１２１は、ボランティアアプリを介して、選択された候補者情報が示す支援者とのメッセージ交換を開始する。

一方、マッチング画面表示部１２９は管理サーバ２００から支援者として特定されたことを示す通知を受信すると、要請者に関する情報を表示する。より詳しくは、図１３（ｃ）を参照して説明したように、マッチング画面表示部１２９は要請者の情報を含む別のマッチング画面３１を表示する。これにより、ユーザＵＣといったボランティアの支援者はユーザＵＡといったボランティアの要請者の要請を引き受けるか否かを判断することができる。マッチング画面表示部１２９はボランティアの要請者の要請を引き受ける旨を示す操作を検出した場合、その旨をメッセージ交換部１２１に通知する。これにより、メッセージ交換部１２１は、ボランティアアプリを介して、要請者とのメッセージ交換を開始する。

続いて、実施形態２に係る管理サーバ２００の機能について説明する。

図１７は実施形態２に係る管理サーバ２００のブロック図の一例である。図１８（ａ）は実施形態２に係る静的エリア管理テーブルＴ１２の一例である。図１８（ｂ）は実施形態２に係るエリアサービス管理テーブルＴ１３の一例である。図１８（ｃ）は実施形態２に係るアプリデータ管理テーブルＴ１４の一例である。図１８（ｄ）は実施形態２に係る端末状態管理テーブルＴ１５の一例である。

図１７に示すように、実施形態２に係る管理サーバ２００は静的エリア記憶部２０１、エリアサービス記憶部２０２、アプリデータ記憶部２０３、及び端末状態記憶部２０４を構成要素として備えている。また、管理サーバ２００は検知結果受信部２０５、アプリ名取得部２０６、端末状態管理部２０７、アプリデータ取得部２０８、アプリデータ送信部２０９、及び管理部としての情報管理部２１０を構成要素として備えている。すなわち、実施形態２に係る管理サーバ２００の構成要素は実施形態１に係る管理サーバ２００と同様である。したがって、管理サーバ２００が備えるこれらの構成要素の少なくとも１つを管理サーバ２００と異なる装置に設定し、構成要素同士を連携させるようにしてもよい。

静的エリア記憶部２０１は静的エリア情報を記憶する。静的エリア情報は、図１８（ａ）に示すように、エリア識別子「Ｘ」とエリア定義座標「ｘｘ，ｙｙ，ｒｒ」とを含み、静的エリア管理テーブルＴ１２によって管理される。したがって、上述した第１ユーザ端末１００のエリア設定部１１１は静的エリア記憶部２０１から静的エリア情報を取得する。

エリアサービス記憶部２０２はサービスエリアＡＲに対して提供するサービスなどを含むサービス情報を記憶する。サービス情報は、図１８（ｂ）に示すように、エリア識別子「Ｘ」と提供サービス「ボランティアサービス」と提供サービスを実現するアプリのアプリ名「ボランティアアプリ」とを含み、エリアサービス管理テーブルＴ１３によって管理される。これにより、サービスエリアＡＲを識別するエリア識別子「Ｘ」が特定されると、特定されたエリア識別子「Ｘ」に対応付けられたアプリ名を抽出することができる。エリアサービス記憶部２０２は様々なサービス情報を予め記憶している。なお、ボランティアアプリは、チャット機能を含み、ボランティアの要請者と支援者との円滑なマッチングを支援するアプリである。

アプリデータ記憶部２０３はアプリに関するアプリ情報を記憶する。アプリ情報は、図１８（ｃ）に示すように、アプリ名「ボランティアアプリ」とアプリを圧縮したアプリデータ「ボランティア．ｚｉｐ」を含み、アプリデータ管理テーブルＴ１４によって管理される。これにより、アプリ名に応じたアプリデータを抽出することができる。アプリデータ記憶部２０３はアプリ名が異なる様々なアプリデータを予め記憶している。

端末状態記憶部２０４は端末状態情報を記憶する。端末状態情報は第１ユーザ端末１００や第２ユーザ端末１５０，１６０，１７０，１８０，１９０などの現在の状態を表す情報である。現在の状態とは、具体的には、第１ユーザ端末１００や第２ユーザ端末１５０，１６０，１７０，１８０，１９０などが現時点で所属するサービスエリアＡＲである。端末状態情報は、図１８（ｄ）に示すように、例えば端末ＩＤ「Ｔ−Ｂ」とユーザ名「Ｂさん」とエリア識別子「Ｘ」とボランティア可能種別「情報提供」を含み、端末状態管理テーブルＴ１５によって管理される。すなわち、実施形態１と異なり、実施形態２に係る端末状態管理テーブルＴ１５はボランティア可能種別を有している。実施形態２では、図１８（ｄ）に示すように、端末ＩＤ「Ｔ−Ａ」によって識別される第１ユーザ端末１００、及び端末ＩＤ「Ｔ−Ｂ」によって識別される第２ユーザ端末１５０、・・・、端末ＩＤ「Ｔ−Ｆ」によって識別される第２ユーザ端末１９０の全てがいずれもエリア識別子「Ｘ」で識別されるサービスエリアＡＲ内に位置している。このように、端末状態記憶部２０４は端末ＩＤとユーザ名とエリア識別子とボランティア可能種別とを対応付けて記憶している。

検知結果受信部２０５は第１ユーザ端末１００から送信された検知結果を受信する。実施形態１で説明したように、検知結果は端末ＩＤ、イン／アウト情報、及び検知エリア情報を含んでいる。検知結果受信部２０５は検知結果に含まれる端末ＩＤをアプリ名取得部２０６に出力せずに、検知結果に含まれるイン／アウト情報と検知エリア情報をアプリ名取得部２０６に出力する。一方、検知結果受信部２０５は検知結果に含まれる端末ＩＤとイン／アウト情報と検知エリア情報のすべてを端末状態管理部２０７に出力する。

アプリ名取得部２０６は、検知結果受信部２０５から出力されたイン／アウト情報にエリアインが含まれると判断した場合、検知結果受信部２０５から出力された検知エリア情報に基づいて、エリアサービス記憶部２０２から検知エリア情報に応じたアプリ名を抽出する。したがって、アプリ名取得部２０６が検知エリア情報「Ｘ」を受け付けた場合、アプリ名「ボランティアアプリ」を抽出する（図１８（ｂ）参照）。アプリ名取得部２０６は、アプリ名を抽出すると、抽出したアプリ名をアプリデータ取得部２０８に出力する。

端末状態管理部２０７は、検知結果受信部２０５から端末ＩＤ、イン／アウト情報、及び検知エリア情報が出力されると、端末状態記憶部２０４が記憶する端末状態情報を更新する。例えば、端末状態管理部２０７は、イン／アウト情報にエリアインが含まれていると判断した場合、ユーザ名と関連付けられた端末ＩＤと検知エリア情報を端末状態情報として端末状態記憶部２０４に保存する。なお、端末状態管理部２０７は、イン／アウト情報にエリアアウトが含まれている場合、端末ＩＤと検知エリア情報とを含む端末状態情報を端末状態記憶部２０４から削除する。

また、端末状態管理部２０７は、例えば第２ユーザ端末１６０からボランティア可能種別が端末ＩＤと共に送信された場合、ボランティア可能種別と端末ＩＤを受信し、端末状態記憶部２０４に登録する。特に、受信した端末ＩＤと共通する端末状態情報の端末ＩＤに、受信した可能種別を関連付けて登録する。これにより、端末状態記憶部２０４は端末ＩＤとユーザ名とエリア識別子とボランティア可能種別が互いに関連付いた端末状態情報を記憶する（図１８（ｄ）参照）。

一方、例えば第１ユーザ端末１００から、端末ＩＤと、ボランティアの支援要請として希望種別とが送信された場合、端末状態管理部２０７は端末ＩＤと希望種別を受信する。その後、端末状態管理部２０７は端末状態記憶部２０４にアクセスして、受信した端末ＩＤと関連付けられたエリア識別子を特定する。端末状態管理部２０７は特定したエリア識別子と共通し、かつ、ボランティアの希望種別と一致（マッチ）するボランティア可能種別を特定し、特定したボランティア可能種別と関連付いたユーザ名を第１ユーザ端末１００に向けて送信する。したがって、例えば端末状態管理部２０７が端末ＩＤ「Ｔ−Ａ」と希望種別「情報提供」の組み合わせを受信した場合、まず、端末ＩＤ「Ｔ−Ａ」と関連付けられたエリア識別子「Ｘ」を特定し、特定したエリア識別子「Ｘ」と共通し、かつ、希望種別「情報提供」と一致する可能種別「情報提供」と関連付いたユーザ名「Ｂさん」、「Ｃさん」、「Ｄさん」を支援者の情報として第１ユーザ端末１００に送信する。これにより、第１ユーザ端末１００はこれら支援者の情報を含むマッチング画面３０を表示することができる。なお、端末状態管理部２０７は、第１ユーザ端末１００でマッチング画面において選択された候補者の候補者情報を受け付けると、受け付けた候補者情報に支援要請に関する情報を送信する。

アプリデータ取得部２０８は、検知結果受信部２０５から出力されたアプリ名に基づいて、アプリデータ記憶部２０３からアプリ名に応じたアプリデータを抽出する。アプリデータ取得部２０８は、アプリデータを抽出すると、抽出したアプリデータをアプリデータ送信部２０９に出力する。アプリデータ送信部２０９はアプリデータ取得部２０８から出力されたアプリデータを第１ユーザ端末１０００に向けて送信する。これにより、第１ユーザ端末１００のアプリデータ受信部１１６はアプリデータを受信することができる。なお、第２ユーザ端末１５０，１６０，１７０，１８０，１９０についても、特定のサービスエリアＡＲへの進入を契機に、管理サーバ２００から、進入したサービスエリアＡＲに対応するアプリデータを受信することとなる。

情報管理部２１０は端末状態管理部２０７と連携し、端末状態管理部２０７を介して、同じサービスエリアＡＲに位置する端末状態情報を確認して管理する。実施形態１で説明したように、情報管理部２１０は、図７における、メッセージ統合部２１１、メッセージ受信部２１０Ａ、メッセージ送信部２１０Ｂ、及び端末特定部２１０Ｃ（図１７ではいずれも不図示）を備えている。したがって、端末特定部２１０Ｃは、メッセージ受信部２１０Ａが第２ユーザ端末１６０から送信されたメッセージを受信すると、受信したメッセージに基づいて端末状態管理部２０７と連携し、端末状態管理部２０７を介して、同じサービスエリアＡＲに位置する端末を特定する。メッセージ統合部２１１は、メッセージ受信部２１０Ａが第２ユーザ端末１６０から送信されたメッセージを受信すると、メッセージ受信部２１０Ａが受信したメッセージと第１ユーザ端末１００から送信されたメッセージとを統合する。メッセージ送信部２１０Ｂは２つのメッセージを統合した統合後のメッセージを第１ユーザ端末１００及び第２ユーザ端末１６０に送信する。これにより、第１ユーザ端末１００及び第２ユーザ端末１６０はそれぞれ統合後のメッセージを含む画面を表示することができる。このように、ユーザＵＡとユーザＵＣはメッセージを交換することができる。

図１９は実施形態２に係る第１ユーザ端末１００の動作の一例を示すフローチャートである。特に、図１９に示すフローチャートは基本アプリ部１１０によって実行される。上述したように、基本アプリ部１１０を実現する基本アプリは第１ユーザ端末１００に事前にインストールされている。図２０は実施形態２に係る管理サーバ２００の動作の一例を示すフローチャートである。なお、第２ユーザ端末１５０，１６０，１７０，１８０，１９０の動作についてはいずれも第１ユーザ端末１００の動作と同様であるため、説明を省略する。

まず、第１ユーザ端末１００に基本アプリがインストールされると、図１９に示すように、エリア設定部１１１は静的エリア情報を取得する（ステップＳ３０１）。より詳しくは、エリア設定部１１１は、静的エリア記憶部２０１に対し静的エリア情報の第１ユーザ端末１００への送信を要求することにより、静的エリア情報を取得する。エリア設定部１１１は静的エリア情報を取得すると、エリア情報記憶部１１２に保存する。これにより、第１ユーザ端末１００にサービスエリアＡＲが設定される。

ステップＳ３０１の処理が完了すると、エリア検知部１１３はサービスエリアＡＲへの出入りを検知するまで後続の処理を待機する（ステップＳ３０２：ＮＯ）。エリア検知部１１３はサービスエリアＡＲへの出入りを検知すると（ステップＳ３０２：ＹＥＳ）、検知結果送信部１１５にイン／アウト情報を出力する（ステップＳ３０３）。例えば、エリア検知部１１３はサービスエリアＡＲへの進入を検知すると、エリアインを含むイン／アウト情報を検知エリア情報と共に出力する。エリア検知部１１３はサービスエリアＡＲからの退出を検知すると、エリアアウトを含むイン／アウト情報を検知エリア情報と共に出力する。

ステップＳ３０３の処理が完了すると、検知結果送信部１１５は検知結果を管理サーバ２００に向けて送信する（ステップＳ３０４）。より詳しくは、検知結果送信部１１５はエリア検知部１１３から出力されたイン／アウト情報を受け付けると、端末ＩＤ管理部１１４から端末ＩＤを取得する。検知結果送信部１１５は取得した端末ＩＤと、イン／アウト情報と、検知エリア情報とを含む検知結果を管理サーバ２００に向けて送信する。ステップＳ３０４の処理が完了すると、エリア検知部１１３は、ステップＳ３０２の処理で検知したサービスエリアＡＲへの出入りが、サービスエリアＡＲへの進入であったかを判断する（ステップＳ３０５）。

ここで、図２０に示すように、管理サーバ２００では、検知結果受信部２０５が検知結果を受信するか、端末状態管理部２０７がボランティア可能種別を受信するか、端末状態管理部２０７がボランティアの希望種別を受信まで待機する（ステップＳ４０１：ＮＯ、ステップＳ４０７：ＮＯ、ステップＳ４０９：ＮＯ）。検知結果受信部２０５は第１ユーザ端末１００から送信された検知結果を受信した場合（ステップＳ４０１：ＹＥＳ）、検知結果を、アプリ名取得部２０６および端末状態管理部２０７に出力する（ステップＳ４０２）。より詳しくは、検知結果受信部２０５は検知結果に含まれるイン／アウト情報と検知エリア情報をアプリ名取得部２０６に出力する。また、検知結果受信部２０５は検知結果に含まれる端末ＩＤ、イン／アウト情報、及び検知エリア情報のすべてを端末状態管理部２０７に出力する。

ステップＳ４０２の処理が完了すると、次いで、端末状態管理部２０７は端末状態情報を更新する（ステップＳ４０３）。より詳しくは、端末状態管理部２０７は検知結果受信部２０５から出力された端末ＩＤ、イン／アウト情報、及び検知エリア情報を受け付けると、イン／アウト情報を確認する。そして、イン／アウト情報にエリアインが含まれていると判断した場合、端末状態管理部２０７は端末ＩＤと検知エリア情報とを対応付けて端末状態記憶部２０４に保存する。これにより、端末状態記憶部２０４は端末状態情報を記憶する。なお、イン／アウト情報にエリアアウトが含まれている場合、端末状態管理部２０７は受け付けた端末ＩＤと検知エリア情報の組み合わせに応じた端末状態情報を端末状態記憶部２０４から削除する。

ステップＳ４０３の処理が完了すると、次いで、アプリ名取得部２０６はアプリ名を取得して出力する（ステップＳ４０４）。より詳しくは、アプリ名取得部２０６は検知結果受信部２０５から出力されたイン／アウト情報と検知エリア情報を受け付ける。アプリ名取得部２０６は受け付けたイン／アウト情報にエリアインが含まれていると判断した場合、エリアサービス記憶部２０２にアクセスし、受け付けた検知エリア情報に応じたアプリ名を取得する。アプリ名取得部２０６はアプリ名を取得すると、取得したアプリ名をアプリデータ取得部２０８に出力する。

ステップＳ４０４の処理が完了すると、次いで、アプリデータ取得部２０８はアプリデータを取得して出力する（ステップＳ４０５）。より詳しくは、アプリデータ取得部２０８はアプリ名取得部２０６から出力されたアプリ名を受け付けると、アプリデータ記憶部２０３にアクセスし、受け付けたアプリ名に応じたアプリデータを取得する。実施形態２では、アプリデータ取得部２０８はアプリデータ「ボランティア．ｚｉｐ」を取得する（図１８（ｃ）参照）。アプリデータ取得部２０８はアプリデータを取得すると、取得したアプリデータをアプリデータ送信部２０９に出力する。ステップＳ４０５の処理が完了すると、次いで、アプリデータ送信部２０９はアプリデータを、検知結果を送信した第１ユーザ端末１００に向けて送信する（ステップＳ４０６）。ステップＳ４０６の処理が完了すると、再び、検知結果受信部２０５が検知結果を受信するか、端末状態管理部２０７がボランティア可能種別を受信するか、端末状態管理部２０７がボランティアの希望種別を受信まで待機する。なお、ステップＳ４０３の処理とステップＳ４０４乃至Ｓ４０６の処理は処理の順序が逆であってもよいし、並行して実行されてもよい。

図１９に戻り、第１ユーザ端末１００では、ステップＳ３０５の処理において、エリア検知部１１３がサービスエリアＡＲへの進入を検知した場合（ステップＳ３０５：ＹＥＳ）、アプリデータ受信部１０６は管理サーバ２００から送信されたアプリデータの受信が完了するまで待機する（ステップＳ３０６：ＮＯ）。そして、アプリデータ受信部１０６はアプリデータの受信が完了すると（ステップＳ３０６：ＹＥＳ）、サービスアプリ部１２０にアプリを実行させる（ステップＳ３０７）。これにより、サービスアプリ部１２０はアプリを実行する。より詳しくは、アプリデータ受信部１０６はアプリデータの受信が完了すると、受信したアプリデータをサービスアプリ部１２０に出力する。サービスアプリ部１２０はアプリデータを受け付けると、受け付けたアプリデータを解凍して展開する。実施形態２では、サービスアプリ部１２０はアプリデータ「ボランティア．ｚｉｐ」を受け付けるため、アプリデータを解凍して展開して、実行することで、メッセージ交換部１２１、ボランティア種別登録部１２６、希望種別選択部１２７、候補者取得部１２８、及びマッチング画面表示部１２９を生成する。これにより、メッセージ交換部１２１、ボランティア種別登録部１２６、希望種別選択部１２７、候補者取得部１２８、及びマッチング画面表示部１２９はそれぞれ自身の機能を発揮することができる。

したがって、第２ユーザ端末１６０であれば、ボランティア可能種別を管理サーバ２００に登録することができる。第１ユーザ端末１００であれば、ボランティアの希望種別を選択すれば、第１ユーザ端末１００とエリア識別子が共通し、選択した希望種別に応じたボランティア可能種別を登録した支援者の情報を含むマッチング画面３０を表示することができる。

なお、ステップＳ３０５の処理において、エリア検知部１１３がサービスエリアＡＲからの退出を検知した場合（ステップＳ３０５：ＮＯ）、サービスアプリ部１２０にアプリの動作を終了させる（ステップＳ３０８）。これにより、アプリが動作中であれば、サービスアプリ部１２０はアプリの動作を終了する。すなわち、第１ユーザ端末１００がサービスエリアＡＲの内側から外側に通過した場合、メッセージ交換部１２１によるメッセージの交換ができなくなる。

さらに、図２１を図２０と共に参照して、上述したステップＳ３０７の詳細について説明する。

図２１は実施形態２に係るサービスアプリ部１２０の動作の一例を示すフローチャートである。図２１に示すように、サービスアプリ部１２０がメッセージ交換部１２１、ボランティア種別登録部１２６、希望種別選択部１２７、候補者取得部１２８、及びマッチング画面表示部１２９を生成すると、ボランティア種別登録部１２６はボランティア可能種別が登録されたか否かを判断する（ステップＳ３１１）。ボランティア種別登録部１２６は可能種別が登録されたと判断した場合（ステップＳ３１１：ＹＥＳ）、可能種別を管理サーバ２００に向けて送信する（ステップＳ３１２）。より詳しくは、ボランティア種別登録部１２６は端末ＩＤ管理部１１４から端末ＩＤを取得し、取得した端末ＩＤと共に可能種別を送信する。一方、ボランティア種別登録部１２６は可能種別が登録されていないと判断した場合（ステップＳ３１１：ＮＯ）、ステップＳ３１２の処理をスキップする。

管理サーバ２００では、図２０に示すように、端末状態管理部２０７が可能種別を受信すると（ステップＳ４０７：ＹＥＳ）、可能種別を登録する（ステップＳ４０８）。より詳しくは、端末状態管理部２０７は可能種別と端末ＩＤを受信すると、受信した端末ＩＤと可能種別の組み合わせを端末状態情報として端末状態記憶部２０４に登録する。例えば、端末状態管理部２０７が可能種別「情報提供」及び端末ＩＤ「Ｔ−Ｃ」を受信すると、端末状態情報において端末ＩＤ「Ｔ−Ｃ」がエリア識別子「Ｘ」及びユーザ名「Ｃさん」と関連付けられて登録されているため、端末状態管理部２０７は受信した端末ＩＤ「Ｔ−Ｃ」を含む端末状態情報に、受信した可能種別「情報提供」を関連付けて登録する（図１８（ｄ）参照）。ステップＳ４０８の処理が完了すると、ステップＳ４０１の処理に戻る。

一方、図２１に示すステップＳ３１１又はＳ３１２の処理が完了した場合、希望種別選択部１２７が操作に基づいて希望種別を選択したか否かを判断する（ステップＳ３１３）。希望種別選択部１２７が希望種別を選択したと判断した場合（ステップＳ３１３：ＹＥＳ）、希望種別選択部１２７は候補者取得部１２８に希望種別を出力する（ステップＳ３１４）。候補者取得部１２８は希望種別を受け付けると、受け付けた希望種別を管理サーバ２００に向けて送信する（ステップＳ３１５）。より詳しくは、候補者取得部１２８は端末ＩＤ管理部１１４から端末ＩＤを取得し、取得した端末ＩＤと共に希望種別を送信する。

管理サーバ２００では、図２０に示すように、端末状態管理部２０７が希望種別を受信すると（ステップＳ４０９：ＹＥＳ）、第２ユーザ端末１５０，・・・，１９０の少なくとも１台を特定し（ステップＳ４１０）、特定した第２ユーザ端末１５０を携帯するユーザＵＢの氏名や特定した第２ユーザ端末１６０を携帯するユーザＵＣの氏名などを含む候補者情報を第１ユーザ端末１００に向けて送信する（ステップＳ４１１）。より詳しくは、端末状態管理部２０７は希望種別と共に受信した端末ＩＤに基づいて、まず、第１ユーザ端末１００のエリア識別子を特定する。その後、端末状態管理部２０７は特定したエリア識別子が共通し、受信した希望種別と対応（具体的には一致）するボランティア可能種別を検出すると、検出したボランティア可能種別と対応付けられた端末ＩＤを有する第２ユーザ端末１５０，・・・，１９０の少なくとも１台を特定する。また、端末状態管理部２０７は特定したエリア識別子が共通し、受信した希望種別と対応（具体的には一致）するボランティア可能種別と対応付けられたユーザ名を特定し、特定したユーザ名を含む候補者情報を第１ユーザ端末１００に送信する。ステップＳ４１１の処理が完了すると、端末状態管理部２０７はユーザ名を受信するまで待機する（ステップＳ４１２：ＮＯ）。

第１ユーザ端末１００では、図２１に示すように、候補者取得部１２８が管理サーバ２００から送信された候補者情報を取得する（ステップＳ３１６）。ステップＳ３１６の処理が完了すると、マッチング画面表示部１２９は候補者情報に含まれる一又は複数のユーザ名を表示する（ステップＳ３１７）。より詳しくは、マッチング画面表示部１２９は候補者情報に含まれる一又は複数のユーザ名とユーザ名のそれぞれに対応する操作ボタンＢＴ３を含むマッチング画面３０（図１４（ｂ）参照）を表示する。マッチング画面表示部１２９は指示に基づいていずれかのユーザ名を選択して管理サーバ２００に送信する（ステップＳ３１８）。例えば、マッチング画面表示部１２９はユーザＵＡの指示に基づいてユーザ名「Ｃさん」を選択すると、選択したユーザ名「Ｃさん」を管理サーバ２００に向けて送信する。

管理サーバ２００では、図２０に示すように、端末状態管理部２０７がユーザ名を受信すると（ステップＳ４１２：ＹＥＳ）、支援要請の情報を送信し（ステップＳ４１３）、ステップＳ４０１の処理に戻る。例えば、端末状態管理部２０７がステップＳ４１０の処理で３台の第２ユーザ端末１５０，１６０，１７０を特定した場合、まず、端末状態管理部２０７は特定した３台の第２ユーザ端末１５０，１６０，１７０の中から、受信したユーザ名「Ｃさん」と対応付けられた端末ＩＤ「Ｔ−Ｃ」を特定する。そして、端末状態管理部２０７は特定した端末ＩＤ「Ｔ−Ｃ」の第２ユーザ端末１６０に支援要請の情報を送信する。

これにより、第２ユーザ端末１６０では、第２ユーザ端末１６０のマッチング画面表示部が別のマッチング画面３１を表示する（図１３（ｃ）参照）。第２ユーザ端末１６０のマッチング画面表示部は要請を引き受ける旨の操作を検出すると、その旨を管理サーバ２００に通知する。

管理サーバ２００の情報管理部２１０は第２ユーザ端末１６０から要請を引き受ける旨が通知されると、その旨を第１ユーザ端末１００に通知する。これにより、図２１に示すように、第１ユーザ端末１００のメッセージ交換部１２１は第２ユーザ端末１６０とメッセージを交換する（ステップＳ３１９）。

したがって、ユーザＵＡが第１ユーザ端末１００に表示されたユーザＵＢ、ユーザＵＣ、ユーザＵＤの各氏名の中からユーザＵＣに連絡する旨の指示を行うと（図１４（ｂ）参照）、メッセージ交換部１２１は管理サーバ２００を経由した第２ユーザ端末１６０とメッセージを交換する。なお、希望種別選択部１２７が希望種別を選択しなかったと判断した場合（ステップＳ３１３：ＮＯ）、希望種別選択部１２７は後続のステップＳ３１４からステップＳ３１９までの処理をスキップする。

以上、実施形態２によれば、管理サーバ２００は端末状態管理部２０７を備えている。端末状態管理部２０７はサービスエリアＡＲの内側に位置する第１ユーザ端末１００からボランティアの支援要請として送信された希望種別「情報提供」を受信すると、受信した希望種別「情報提供」に応じて、例えばサービスエリアＡＲの内側に位置する第２ユーザ端末１５０,１６０，１７０を特定する。第２ユーザ端末１５０,１６０，１７０のいずれか１台しかボランティア可能種別「情報提供」を登録していない場合には、端末状態管理部２０７はその１台を特定する。端末状態管理部２０７は第２ユーザ端末１５０,１６０，１７０を特定すると、特定した第２ユーザ端末１５０,１６０，１７０のいずれかに対し、支援要請に関する情報を送信する。端末状態管理部２０７が情報を送信する送信先は第１ユーザ端末１００に対して行われた第２ユーザ端末１５０,１６０，１７０の保持者の選択に応じて決定される。

これにより、サービスエリアＡＲ内でのボランティアを支援することができる。本実施形態２によれば、管理サーバ２００が、支援者となりうるユーザにより登録されたボランティア可能種別を管理する。したがって、本実施形態２は、要請者がボランティアを要請しても、支援者の属性（ボランティア可能種別）によっては要請者の要請に支援者が協力できないという状況を開示することができる。

（実施形態３）
続いて、図２２及び図２３を参照して、本件の実施形態３について説明する。図２２（ａ）は実施形態３に係る第１ユーザ端末１００の動作の一部を例示するフローチャートである。特に、図２２（ａ）に示すフローチャートは基本アプリ部１１０によって実行される。図２２（ｂ）及び（ｃ）は実施形態３に係る第１ユーザ端末１００及び第２ユーザ端末１５０，１６０，１７０，１８０，１９０のそれぞれに表示される画面の一例である。図２３（ａ）乃至（ｄ）は実施形態３に係る第１ユーザ端末１００及び第２ユーザ端末１５０，１６０，１７０，１８０，１９０のそれぞれに表示される画面の他の一例である。

図２２（ａ）に示すように、実施形態２で説明したステップＳ３０８の処理の後にアプリを消去する処理を表すステップＳ３０９を実行してから、ステップＳ３０１の処理に戻ってもよい。これにより、第１ユーザ端末１００及び第２ユーザ端末１５０，１６０，１７０，１８０，１９０のどれもがサービスエリアＡＲの内側から外側に通過すると、サービスアプリ（ボランティアアプリ）が消去される。これにより、例えば第１ユーザ端末１００がサービスエリアＡＲから退出すると、第１ユーザ端末１００にインストールされたサービスアプリが占有していた記憶領域が動的に開放され、記憶領域が増大する。また、ユーザＵＢやユーザＵＣなどの支援者の個人情報を含む履歴情報なども動的に消去され、履歴情報が占有していた記憶領域が動的に開放され、記憶領域が増大する。さらに、履歴情報が消去されることにより履歴情報の情報漏洩の危険性が回避されるため、さらに、セキュリティが向上する。結果的に、メッセージを交換していた要請者や支援者のプライバシーが確保される。メッセージのやり取りの中で、個人を特定する情報がやり取りされた場合に、サービスアプリ上に個人情報が残ってしまう危険性がある。例えば、写真撮影など、要請者と支援者が直接会って、支援を行う場合には、待ち合わせなどの目的で、氏名や服装などの個人情報をメッセージでやり取りすることが考えられる。本実施形態３は、サービスエリアＡＲを退出したタイミングで、これらの個人情報を削除することで、個人情報が互いの端末に残ることを防ぐ。

より詳しく説明すると、図１９を参照して説明したステップＳ３０５の処理において、エリア検知部１１３がサービスエリアＡＲからの退出を検知した場合、エリア検知部１１３はサービスアプリ部１２０にサービスアプリの動作を終了させ、その後、そのサービスアプリを消去する（ステップＳ３０９）。例えば、第１ユーザ端末１００がサービスエリアＡＲから退出すると、エリア検知部１１３は、図２２（ｂ）に示すように、サービスエリアＡＲからの退出とサービスアプリの消去を通知する通知画面を表示する。そして、エリア検知部１１３は、サービスアプリの消去が完了すると、図２２（ｃ）に示すように、サービスアプリの消去完了を通知する通知画面を表示する。

なお、図２３（ａ）に示すように、エリア検知部１１３は、消去対象の選択に応じて、サービスアプリの消去を実行せずに、履歴情報を消去するようにしてもよいし、サービスアプリの消去と履歴情報を消去のいずれも実行しないようにしてもよい。例えば、図２３（ａ）に示すように、サービスアプリの消去を実行せずに、履歴情報を消去する選択が行われた場合、エリア検知部１１３はサービスアプリを残存させつつ、履歴情報を消去して、図２３（ｂ）に示すように、その旨を通知する通知画面を表示する。

また、図２３（ｃ）に示すように、エリア検知部１１３は、消去対象の選択に応じて、サービスアプリの消去を実行せずに、属性情報を消去するようにしてもよいし、サービスアプリの消去と属性情報を消去のいずれも実行しないようにしてもよい。属性情報は管理サーバ２００に登録されたボランティア可能種別を表している。例えば、図２３（ｃ）に示すように、サービスアプリの消去を実行せずに、属性情報を残す選択が行われた場合、エリア検知部１１３はサービスアプリを残存させつつ、属性情報の維持を管理サーバ２００に通知し、図２３（ｄ）に示すように、その旨を通知する通知画面を表示する。この場合、管理サーバ２００の端末状態管理部２０７はボランティア可能種別を消去せずに保持する。これにより、ユーザＵＢやユーザＵＣといった支援者はボランティア可能種別の再登録を行わないで済み、継続してサービスを利用することができる。

（実施形態４）
続いて、図２４及び図２５を参照して、本件の実施形態４について説明する。図２４は実施形態４に係る端末状態管理テーブルＴ１６の一例である。図２５（ａ）及び（ｂ）は実施形態４に係る第２ユーザ端末１６０の画面表示例である。図２５（ｃ）及び（ｄ）は実施形態４に係る第１ユーザ端末１００の画面表示例である。

実施形態２では、端末状態管理テーブルＴ１５（図１８（ｄ）参照）を説明したが、図２４に示すように、端末状態管理テーブルＴ１５にコンディションを含めた端末状態管理テーブルＴ１６を採用してもよい。コンディションはユーザＵＢやユーザＵＣの現在の状況を表している。

例えば、図２５（ａ）及び（ｂ）に示すように、実施形態４では、ボランティア可能種別「情報提供」が第２ユーザ端末１５０，１６０，１７０のそれぞれから登録され、さらに、第２ユーザ端末１６０から現在のコンディションが取込中である旨が登録される。例えば、ユーザＵＣがボランティアを要請するユーザＵＡと異なる別の要請者（不図示）に対応していたり、私用などで現時点では対応できなかったりする場合、ユーザＵＣは第２ユーザ端末１６０を操作して取込中である旨を第２ユーザ端末１６０に入力する。これにより、図２４に示すように、ボランティア種別登録部１２６は取込中である旨を第２ユーザ端末１６０の端末ＩＤと共に管理サーバ２００に向けて送信し、端末状態管理部２０７は受信した端末ＩＤを含む端末状態情報のコンディションをＯＫから取込中に書き換える。これにより、図２４に示すように、端末状態管理テーブルＴ１６におけるユーザＵＣのコンディションが取込中に変更される。

この状態で、例えば図２５（ｃ）及び（ｄ）に示すように、ユーザＵＡは第１ユーザ端末１００に要請を望むボランティアの種別に応じた支援者を選定することができる。具体的には、まず、ユーザＵＡが第１ユーザ端末１００に表示されたスタート画面１０においてボランティアの種別として情報提供を選択する操作ボタンＢＴ２を押下する操作を行う。第１ユーザ端末１００は当該操作を検出すると、マッチング画面３０を表示する。マッチング画面３０には、管理サーバ２００にボランティア可能種別として情報提供を登録した支援者の名前とその支援者に連絡するための複数の操作ボタンＢＴ３が管理サーバ２００の処理により含まれている。特に、管理サーバ２００にコンディションとして取込中を登録した支援者については操作ボタンＢＴ３に取込中である旨が表示され、操作ボタンＢＴ３を押下する操作が行えないように制御されている。これにより、ユーザＵＡは第１ユーザ端末１００に表示されたマッチング画面３０において、ユーザＵＣへの連絡を回避し、ユーザＵＢ又はユーザＵＤに連絡する操作ボタンＢＴ３を押下する操作を行う。

このように、実施形態４によれば、偶発的に支援者が要請者の要請に対応できない状況におかれている場合には、要請者にその旨が伝わり、要請者の要請に対応できない状況におかれている支援者には無駄な要請が送信されないで済む。

（実施形態５）
続いて、図２６及び図２７を参照して、本件の実施形態５について説明する。図２６は実施形態５に係る端末状態管理テーブルＴ１７の一例である。図２７（ａ）乃至（ｄ）は実施形態５に係る第１ユーザ端末１００の画面表示例である。

実施形態２では、端末状態管理テーブルＴ１５（図１８（ｄ）参照）を説明したが、図２６に示すように、端末状態管理テーブルＴ１５にスキルを含めた端末状態管理テーブルＴ１７を採用してもよい。スキルはユーザＵＢやユーザＵＣといった支援者が有する技能レベルを表している。スキルにおいて、星印の数が多いほど高い評価を表している。例えば情報提供であれば支援者の地理の知識の質や量などが該当し、例えば写真撮影であれば支援者の撮影技術の質などが該当する。同様に、通訳であれば非母国語の言語能力の質などが該当し、荷物持ちであれば、荷物の搬送時の取り扱いに関する質などが該当する。

例えば、図２７（ａ）に示すように、第１ユーザ端末１００において希望種別「写真撮影」が選択されて管理サーバ２００に送信されると、管理サーバ２００（具体的には端末状態管理部２０７）は第１ユーザ端末１００が所属するサービスエリアＡＲのエリア識別子「Ｘ」と共通し、かつ、希望種別「写真撮影」と一致（マッチ）するボランティア可能種別「写真撮影」が登録されたユーザＵＥ及びユーザＵＦを候補者情報として特定する。特に、管理サーバ２００は候補者情報を特定するとともに、特定した候補者情報のスキルも特定する。管理サーバ２００は候補者情報とスキルを特定すると、特定した候補者情報とスキルを第１ユーザ端末１００に送信する。これにより、図２７（ｂ）に示すように、第１ユーザ端末１００は特定した候補者情報としてのユーザＵＥ及びユーザＵＦ並びにこれら候補者情報のスキルを含むマッチング画面３０を表示する。

例えば、図２７（ｂ）に示すように、ユーザＵＡがユーザＵＦより評価が高いユーザＵＥとの連絡を行うための操作ボタンＢＴ３を押下する指示を行うと、第１ユーザ端末１００は指示に応じた候補者情報を選択し、選択した候補者情報を管理サーバ２００に向けて送信する。管理サーバ２００は候補者情報を受信すると、受信した候補者情報に基づいてその候補者情報に対応する支援者が保持する第２ユーザ端末１８０に向けて、支援要請に関する情報を送信する。これにより、第２ユーザ端末１８０が別のマッチング画面を表示するため、ユーザＵＥはユーザＵＡの要請を引き受けるか否か判断することができる。ユーザＵＥはユーザＵＡの要請を引き受けた場合、第２ユーザ端末１８０は要請を引き受けた旨の情報を管理サーバ２００に送信する。これにより、図２７（ｃ）に示すように、ユーザＵＡとユーザＵＥは写真撮影のボランティアに関するメッセージを交換することができる。

そして、ユーザＵＥがユーザＵＡに対する支援を終えると、第１ユーザ端末１００は、図２７（ｄ）に示すように、評価登録画面を表示する。ユーザＵＡがユーザＵＥに対する評価を登録すると、希望種別選択部１２７はユーザＵＥの情報（例えば氏名など）と共に管理サーバ２００に向けて評価を送信する。端末状態管理部２０７はユーザＵＥの情報と評価を受信すると、端末状態記憶部２０４にアクセスし、受信した情報を含む端末状態情報のスキルを、受信した評価に基づいて更新する。

このように、実施形態５によれば、要請者が高度の撮影技術を有する支援者を要請する場合には、支援者の評価に基づいて、支援者を選択することができ、要請者と支援者との間でトラブルが発生しないで済む。

（実施形態６）
続いて、図２８乃至図３５を参照して、本件の実施形態６について説明する。まず、図２８を参照して、実施形態６の概要について説明する。図２８は実施形態６に係るサービス活動支援システムＳＴ３の一例である。図２９（ａ）及び（ｂ）は実施形態６に係る第１ユーザ端末１００の画面表示例である。サービス活動支援システムＳＴ３は、実施形態２に係るサービス活動支援システムＳＴ２と同様に、１台の第１ユーザ端末１００及び５台の第２ユーザ端末１５０，１６０，１７０，１８０，１９０を含む複数のユーザ端末と、処理装置としての管理サーバ２００とを備えている。一方で、実施形態６では、実施形態２と異なり、サービスエリアＡＲより小さなサブエリアＡＲ−ＳがサービスエリアＡＲと共に第１ユーザ端末１００の位置に基づき、設定される。サブエリアＡＲ−Ｓの範囲はユーザＵＡを中心に、ユーザＵＡが要請するボランティアの希望種別に応じて決定される。なお、図２８では示さないが、第２ユーザ端末１５０，１６０，１７０，１８０，１９０にも同様にユーザＵＡを中心とするサブエリアＡＲ−Ｓが設定される。

詳細は後述するが、管理サーバ２００はサービスエリアＡＲに所属し、かつ、サブエリアＡＲ−Ｓにも所属する支援者の中から、希望種別に応じたボランティア可能種別を登録した支援者を候補者情報として特定する。例えばユーザＵＥとユーザＵＦがどちらもボランティア可能種別として写真撮影を登録していても、図２８に示すように、ユーザＵＦがサブエリアＡＲ−Ｓに所属していなければ、図２９（ａ）及び（ｂ）に示すように、ユーザＵＦは候補者情報として特定することができない。したがって、この場合、サービスエリアＡＲとサブエリアＡＲ−Ｓの両方に所属するユーザＵＥが候補者情報として特定される。すなわち、ユーザＵＡを中心に、ユーザＵＡが要請するボランティアの希望種別に応じて決定される範囲の外に位置するユーザＵＦが候補者情報の特定対象から除外される。そして、ユーザＵＡを中心に、ユーザＵＡが要請するボランティアの希望種別に応じて決定される一定の範囲の内に位置するユーザＵＥが候補者情報として特定される。したがって、ユーザＵＥはユーザＵＡの至急の要請に対して迅速に対応することができる。

以下、実施形態６の詳細について説明する。

図３０は実施形態６に係る第１ユーザ端末１００のブロック図の一例である。図３１は実施形態６に係るローカルエリア管理テーブルＴ１８の一例である。なお、第２ユーザ端末１５０，１６０，１７０，１８０，１９０については第１ユーザ端末１００と同様の機能構成であるため、説明を省略する。また、第１ユーザ端末１００及び第２ユーザ端末１５０，１６０，１７０，１８０，１９０のハードウェア構成については、図３を参照して説明したハードウェア構成と同様であるため、説明を省略する。さらに、図１５に示される構成と同様の構成には基本的に同一符号を付し、その説明を省略する。図３０に示すように、実施形態６に係る第１ユーザ端末１００は候補者取得部１２８が位置情報送信部１２８Ａを有する点を除き実施形態２に係る第１ユーザ端末１００と同様である。

ここで、実施形態６に係るエリア設定部１１７は管理サーバ２００から静的エリア情報を取得して、エリア情報記憶部１１２に保存する。これにより、図３１に示すように、エリア情報記憶部１１２はエリア識別子「Ｘ」とエリア定義座標「ｘｘ，ｙｙ，ｒｒ」とを関連付けて記憶する。この結果、第１ユーザ端末１００に仮想的なサービスエリアＡＲがローカルエリア情報として設定される。また、エリア設定部１１７は管理サーバ２００から後述する動的エリア情報を取得して、エリア情報記憶部１１２に保存する。これにより、図３１に示すように、エリア情報記憶部１１２はエリア識別子「Ａ１」とエリア定義座標「ｘ−ａ１，ｙ−ａ１，ｒ−ａ１」とを関連付けて記憶する。この結果、第１ユーザ端末１００に仮想的なサブエリアＡＲ−Ｓがローカルエリア情報として設定される。

一方、位置情報送信部１２８Ａは、第１ユーザ端末１００がサービスエリアＡＲに進入すると、端末ＩＤ管理部１１４から端末ＩＤを取得し、サブエリアＡＲ−Ｓに対して付与するエリア識別子を新たに生成する。位置情報送信部１２８Ａは新たなエリア識別子を生成せずに、予め定められたエリア識別子を利用してもよい。位置情報送信部１２８Ａは、エリア識別子を新たに生成すると、緯度と経度によって特定される第１ユーザ端末１００の現在の位置座標と新たなエリア識別子とを含む位置情報を、取得した端末ＩＤと共に、管理サーバ２００に向けて送信する。なお、位置情報送信部１２８Ａが位置情報と端末ＩＤを送信した後、候補者取得部１２８が希望種別選択部１２７から希望種別を受け付けると、候補者取得部１２８は受け付けた希望種別と新たなエリア識別子とを管理サーバ２００に向けて送信する。

図３２は実施形態６に係る管理サーバ２００のブロック図の一例である。図３３（ａ）は実施形態６に係る端末状態管理テーブルＴ１９の一例である。図３３（ｂ）は実施形態６に係る設定範囲管理テーブルＴ２０の一例である。図３３（ｃ）は実施形態６に係る動的エリア管理テーブルＴ２１の一例である。

なお、図１７に示される構成と同様の構成には基本的に同一符号を付し、その説明を省略する。図３２に示すように、実施形態６に係る管理サーバ２００は設定範囲記憶部２１３、動的エリア記憶部２１４、及び動的エリア設定部２１５をさらに有する点を除き、基本的に実施形態２に係る管理サーバ２００と同様である。なお、設定範囲記憶部２１３及び動的エリア記憶部２１４は上述したＨＤＤ２００Ｅによって実現することができる。動的エリア設定部２１５は上述したＣＰＵ２００Ａによって実現することができる。

ここで、実施形態６に係る端末状態記憶部２０４は端末状態情報を記憶する。端末状態情報は第１ユーザ端末１００や第２ユーザ端末１５０，１６０，１７０，１８０，１９０などの現在の状態を表す情報である。実施形態６に係る現在の状態とは、具体的には、第１ユーザ端末１００や第２ユーザ端末１５０，１６０，１７０，１８０，１９０などが現時点で所属するサービスエリアＡＲやサブエリアＡＲ−Ｓである。端末状態情報は、図３３（ａ）に示すように、例えば端末ＩＤ「Ｔ−Ｂ」とユーザ名「Ｂさん」とエリア識別子「Ｘ」及び「Ａ１」とボランティア可能種別「情報提供」を含み、端末状態管理テーブルＴ１９によって管理される。実施形態６では、図３３（ａ）に示すように、端末ＩＤ「Ｔ−Ａ」によって識別される第１ユーザ端末１００、及び端末ＩＤ「Ｔ−Ｂ」によって識別される第２ユーザ端末１５０、・・・、端末ＩＤ「Ｔ−Ｆ」によって識別される第２ユーザ端末１９０の全てがいずれもエリア識別子「Ｘ」で識別されるサービスエリアＡＲ内に位置している。一方で、第１ユーザ端末１００、及び第２ユーザ端末１５０，１８０はいずれもエリア識別子「Ａ１」で識別されるサブエリアＡＲ−Ｓ内に位置しているが、第２ユーザ端末１６０，１７０，１９０は端末状態管理テーブルＴ１９にエリア識別子「Ａ１」が登録されていないため、第２ユーザ端末１６０，１７０，１９０はサブエリアＡＲ−Ｓ外に位置している。このように、端末状態記憶部２０４は端末ＩＤとユーザ名とエリア識別子とボランティア可能種別とを対応付けて記憶している。

設定範囲記憶部２１３はサブエリアＡＲ−Ｓの半径を設定範囲として表す設定範囲情報を記憶する。設定範囲情報は、図３３（ｂ）に示すように、例えばボランティア種別「写真撮影」とそのボランティア種別に応じた設定範囲「８０ｍ」を対応付けて含む。設定範囲情報は設定範囲管理テーブルＴ２０によって管理される。これにより、ボランティア種別に応じた設定範囲を抽出することができる。

動的エリア記憶部２１４は動的エリア情報を記憶する。動的エリア情報は、図３３（ｃ）に示すように、サブエリアＡＲ−Ｓを識別するエリア識別子「Ａ１」とサブエリアＡＲ−Ｓの範囲を定義するエリア定義座標「ｘ−ａ１，ｙ−ａ１，ｒ−ａ１」とを含む。動的エリア情報は動的エリア管理テーブルＴ２１によって端末ＩＤ毎に管理される。このように、動的エリア情報によってサブエリアＡＲ−Ｓが定義される。上述した第１ユーザ端末１００のエリア設定部１１１は動的エリア記憶部２１４から動的エリア情報を取得する。

動的エリア設定部２１５は第１ユーザ端末１００から送信された端末ＩＤ、及び位置情報を受信する。動的エリア設定部２１５は端末ＩＤ、及び位置情報を受信すると、動的エリア記憶部２１４にアクセスし、受信した位置情報に含まれる新たなエリア識別子と緯度及び経度によって特定される位置座標とを対応付けて、動的エリア情報の一部として動的エリア記憶部２１４に登録する。そして、動的エリア設定部２１５は第１ユーザ端末１００から送信された希望種別を受信すると、設定範囲記憶部２１３にアクセスし、受信した希望種別に応じた設定範囲を取得する。動的エリア設定部２１５は設定範囲を取得すると、動的エリア記憶部２１４にアクセスし、取得した設定範囲を動的エリア記憶部２１４が記憶する動的エリア情報の一部に関連付けて登録する。これにより、希望種別に応じた範囲を定義する動的エリア情報が完成する（図３３（ｃ）参照）。

動的エリア設定部２１５は設定範囲を登録すると、登録した動的エリア情報を第１ユーザ端末１００及び第２ユーザ端末１５０，・・・，１９０の全てに向けて送信する。これにより、第１ユーザ端末１００及び第２ユーザ端末１５０，・・・，１９０のそれぞれにユーザＵＡを中心とするサブエリアＡＲ−Ｓが設定される。これにより、エリア検知部１１３は第１ユーザ端末１００がサブエリアＡＲ−Ｓに所属していれば、検知エリア情報「Ａ１」を管理サーバ２００に向けて送信することができる。第２ユーザ端末１５０，・・・，１９０のそれぞれのエリア検知部（不図示）も同様に検知エリア情報「Ａ１」を管理サーバ２００に向けて送信することができる。この結果、管理サーバ２００の端末状態管理部２０７は端末状態記憶部２０４にサブエリアＡＲ−Ｓのエリア識別子「Ａ１」を登録することができる。

続いて、実施形態６に係るサービス活動支援システムＳＴ３の動作について説明する。

図３４（ａ）は実施形態６に係る第１ユーザ端末１００の動作の一部を例示するフローチャートである。特に、図３４（ａ）に示すフローチャートは基本アプリ部１１０とサービスアプリ部１２０によって実行される。図３４（ｂ）は候補者検索処理の一例を示すフローチャートである。図３５は実施形態６に係る管理サーバ２００の動作の一部を例示するフローチャートである。なお、基本アプリ部１１０の動作については、図１９を参照して説明した実施形態２の動作と同様である。

図３４（ａ）に示すように、実施形態２で説明したステップＳ３１４の処理とステップＳ３１６の処理の間に実行されるステップＳ３１５の処理を、実施形態６では、候補者検索処理を表すステップＳ３２０に変更する。これにより、第１ユーザ端末１００から希望種別が送信された場合、第１ユーザ端末１００を中心に希望種別に応じた設定範囲によって定義されるサブエリアＡＲ−Ｓ内に位置する支援者が候補者情報として第１ユーザ端末１００に表示される。

より詳しく説明すると、図２１を参照して説明したステップＳ３１４の処理において、希望種別選択部１２７が希望種別を出力すると、基本アプリ部１１０とサービスアプリ部１２０が協働して候補者検索処理を実行する（ステップＳ３２０）。候補者検索処理が開始すると、図３４（ｂ）に示すように、まず、位置情報送信部１２８Ａは端末ＩＤと位置情報を管理サーバ２００に向けて送信する（ステップＳ３２１）。上述したように、位置情報は、第１ユーザ端末１００の位置座標と新たなエリア識別子を含んでいる。その後、候補者取得部１２８は希望種別を管理サーバ２００に向けて送信する（ステップＳ３２２）。

ここで、図３５に示すように、管理サーバ２００では、図２０を参照して説明したように、検知結果受信部２０５が検知結果を受信するか、端末状態管理部２０７がボランティア可能種別を受信するかだけでなく、動的エリア設定部２１５が位置情報と端末ＩＤを受信するまで待機する（ステップＳ４０１：ＮＯ、ステップＳ４０７：ＮＯ、ステップＳ５０１：ＮＯ）。

動的エリア設定部２１５は第１ユーザ端末１００から送信された位置情報と端末ＩＤを受信した場合（ステップＳ５０１：ＹＥＳ）、位置情報と端末ＩＤを登録し（ステップＳ５０２）、希望種別を受信するまで待機する（ステップＳ５０３：ＮＯ）。より詳しくは、動的エリア設定部２１５は位置情報に含まれる新たなエリア識別子と位置座標とを対応付けて端末ＩＤ毎に動的エリア情報の一部として動的エリア記憶部２１４に登録し、希望種別を受信するまで待機する。

そして、動的エリア設定部２１５は第１ユーザ端末１００から送信された希望種別を受信した場合（ステップＳ５０３：ＹＥＳ）、設定範囲を抽出して（ステップＳ５０４）、抽出した設定範囲を動的エリア記憶部２１４に登録する（ステップＳ５０５）。これにより、動的エリア情報が完成する（図３３（ｃ）参照）。すなわち、希望種別が写真撮影である場合、設定範囲として８０メートルが抽出され、エリア定義座標の半径であるｒ−ａ１が８０メートルとなる。動的エリア設定部２１５は動的エリア情報が完成すると、動的エリア情報を第１ユーザ端末１００及び第２ユーザ端末１５０，・・・，１９０の全てに送信する（ステップＳ５０６）。動的エリア設定部２１５が動的エリア情報を送信した後、端末状態管理部２０７は新たなエリア識別子を受信するまで待機する（ステップＳ５０７：ＮＯ）。

一方、図３４（ｂ）に示すように、第１ユーザ端末１００では、エリア設定部１１１が管理サーバ２００から送信された動的エリア情報を取得すると（ステップＳ３２３）、ローカルエリア情報を更新する（ステップＳ３２４）。これにより、第１ユーザ端末１００にサブエリアＡＲ−Ｓが設定される。なお、第２ユーザ端末１５０，・・・，１９０も第１ユーザ端末１００と同様にサブエリアＡＲ−Ｓが設定される。

この結果、例えば第２ユーザ端末１８０がサブエリアＡＲ−Ｓに進入すると、第２ユーザ端末１８０のエリア検知部は第２ユーザ端末１８０のサブエリアＡＲ−Ｓへの進入を検知し、サブエリアＡＲ−Ｓへのエリアインを含むイン／アウト情報を検知エリア情報と共に出力する（ステップＳ３２５）。この場合、検知エリア情報は新たなエリア識別子「Ａ１」を表している。第１ユーザ端末１００及び第２ユーザ端末１５０についても第２ユーザ端末１８０と同様である。

第２ユーザ端末１８０の検知結果送信部はイン／アウト情報を受け付けると、イン／アウト情報を管理サーバ２００に向けて送信する（ステップＳ３２６）。より詳しくは、第２ユーザ端末１８０の検知結果送信部はイン／アウト情報を検知エリア情報と共に受け付けると、端末ＩＤ管理部１１４から端末ＩＤを取得する。第２ユーザ端末１８０の検知結果送信部は、取得した端末ＩＤとイン／アウト情報と検知エリア情報とを管理サーバ２００に向けて送信する。これにより、管理サーバ２００では、端末状態管理部２０７が検知エリア情報を端末状態記憶部２０４に登録することができる。すなわち、新たなエリア識別子「Ａ１」が端末状態管理テーブルＴ１９に登録される（図３３（ａ）参照）。

ステップＳ３２６の処理が完了すると、次いで、候補者取得部１２８は希望種別と新たなエリア識別子を管理サーバ２００に向けて送信する（ステップＳ３２７）。これにより、図３５に示すように、管理サーバ２００では、端末状態管理部２０７が新たなエリア識別子を受信する（ステップＳ５０７：ＹＥＳ）。端末状態管理部２０７が新たなエリア識別子を受信すると、新たなエリア識別子と希望種別と第１ユーザ端末１００が所属するサービスエリアＡＲのエリア識別子とに基づいて、対応する支援者を候補者情報として抽出する。端末状態管理部２０７は候補者情報を抽出すると、抽出した候補者情報を第１ユーザ端末１００に向けて送信する（ステップＳ５０８）。第１ユーザ端末１００では、図３４（ｂ）に示すように、候補者取得部１２８は管理サーバ２００から送信された候補者情報を取得する（ステップＳ３２８）。これにより、第１ユーザ端末１００はユーザＵＡから離れたユーザＵＦを除外して、候補者情報としてユーザＵＥを表示する（図２９（ｂ）参照）。このように、実施形態６によれば、要請者と支援者との距離に応じて要請者と支援者とを精度良く適合させることができる。

以上、本発明の好ましい実施形態について詳述したが、本発明に係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。例えば、サービスエリアＡＲもサブエリアＡＲ−Ｓも円に限定されず、楕円や矩形を含む多角形などであってもよい。また、実施形態２から実施形態６を適宜組み合わせてもよい。

なお、以上の説明に関して更に以下の付記を開示する。
（付記１）仮想的に地図上に設定された特定のエリアの内側に位置する第１の端末装置から送信されたサービス活動の支援に関する要求を受信すると、前記特定のエリアの内側に位置する、前記第１の端末装置とは異なる、１以上の第２の端末装置を特定し、特定した前記１以上の第２の端末装置に対して、前記要求に関する情報を送信する、処理をコンピュータが実行するサービス活動支援方法。
（付記２）前記コンピュータは、前記１以上の第２の端末装置から事前に登録された、サービス活動を特定する種別を、前記１以上の第２の端末装置毎に対応付けて管理し、前記要求に含まれる前記サービス活動の種別に対応付けられた前記１以上の第２の端末装置を特定する、ことを特徴とする付記１に記載のサービス活動支援方法。
（付記３）前記コンピュータは、前記１以上の第２の端末装置から事前に登録された、サービス活動を特定する種別と、前記１以上の第２の端末装置それぞれのユーザの状況を、前記１以上の第２の端末装置毎に対応付けて管理し、特定した前記１以上の第２の端末装置のうち、前記状況に基づき、少なくとも一つの第２の端末装置を特定する、ことを特徴とする付記１又は２に記載のサービス活動支援方法。
（付記４）前記コンピュータは、前記１以上の第２の端末装置から事前に登録された、サービス活動を特定する種別と、前記１以上の第２の端末装置のユーザの前記サービス活動に対する技能レベルとを、前記１以上の第２の端末装置毎に対応付けて管理し、前記第１の端末装置に対して、特定した前記１以上の第２の端末装置の情報とともに、前記技能レベルに関する情報を送信し、前記第１の端末装置により、選択された第２の端末装置に対して、前記要求に関する情報を送信する、ことを特徴とする付記１から３のいずれか１項に記載のサービス活動支援方法。
（付記５）前記コンピュータは、前記サービス活動を特定する種別と、エリアに関する範囲情報とを対応づけて管理し、前記要求で指定されたサービス活動の種別に対応する範囲情報で規定されるエリア内に存在する、前記１以上の第２の端末装置を特定する、ことを特徴とする付記１から４のいずれか１項に記載のサービス活動支援方法。
（付記６）仮想的に地図上に設定された特定のエリアの内側に位置する第１の端末装置から送信されたサービス活動の支援に関する要求を受信すると、前記特定のエリアの内側に位置する、前記第１の端末装置とは異なる、１以上の第２の端末装置を特定し、特定した前記１以上の第２の端末装置に対して、前記要求に関する情報を送信する、処理をコンピュータに実行させるサービス活動支援プログラム。
（付記７）複数の端末装置と通信可能なシステムであって、位置情報と仮想的に地図上に設定されたエリアにかかるエリア情報とに基づき、自装置が属するエリアにかかる第１のエリア情報を送信する送信部をそれぞれ有する複数の端末装置から、前記第１のエリア情報を受信し、前記複数の端末装置のうちの第１の端末装置から、サービス活動の支援に関する要求を受信した場合、前記第１の端末装置にかかる前記第１のエリア情報に基づき、前記第１の端末装置が属するエリアの内側に位置する１以上の第２の端末装置を特定し、特定した前記１以上の第２の端末装置に対して、前記要求に関する情報を送信する管理部を有することを特徴とするシステム。
（付記８）前記第１の端末装置は、前記第１の端末装置が属するエリアの外側に位置することを検知した場合、前記要求を送信するアプリケーションソフトウェアを消去し、前記１以上の第２の端末装置は、前記１以上の第２の端末装置が属するエリアの外側に位置することを検知した場合、前記要求に関する情報を受信するアプリケーションソフトウェアを消去する、ことを特徴とする付記７に記載のシステム。

ＳＴ１，ＳＴ２，ＳＴ３ サービス活動支援システム
１００ 第１ユーザ端末
１１０ 基本アプリ部
１２０ サービスアプリ部
１５０，１６０，１７０，１８０，１９０ 第２ユーザ端末
２００ 管理サーバ
２０１ 静的エリア記憶部
２０２ エリアサービス記憶部
２０３ アプリデータ記憶部
２０４ 端末状態記憶部
２０５ 検知結果受信部
２０６ アプリ名取得部
２０７ 端末状態管理部
２０８ アプリデータ取得部
２０９ アプリデータ送信部
２１０ 情報管理部
２１０Ａ メッセージ受信部
２１０Ｂ メッセージ送信部
２１０Ｃ 端末特定部
２１１ メッセージ統合部
２１３ 設定範囲記憶部
２１４ 動的エリア記憶部
２１５ 動的エリア設定部

Claims (8)

1. 仮想的に地図上に設定された特定のエリアの内側に位置する第１の端末装置から送信されたサービス活動の支援に関する要求を受信すると、前記特定のエリアの内側に位置する、前記第１の端末装置とは異なる、１以上の第２の端末装置を特定し、
   特定した前記１以上の第２の端末装置に対して、前記要求に関する情報を送信する、
   処理をコンピュータが実行するサービス活動支援方法。
2. 前記コンピュータは、
   前記１以上の第２の端末装置から事前に登録された、サービス活動を特定する種別を、前記１以上の第２の端末装置毎に対応付けて管理し、
   前記要求に含まれる前記サービス活動の種別に対応付けられた前記１以上の第２の端末装置を特定する、
   ことを特徴とする請求項１に記載のサービス活動支援方法。
3. 前記コンピュータは、
   前記１以上の第２の端末装置から事前に登録された、サービス活動を特定する種別と、前記１以上の第２の端末装置それぞれのユーザの状況を、前記１以上の第２の端末装置毎に対応付けて管理し、
   特定した前記１以上の第２の端末装置のうち、前記状況に基づき、少なくとも一つの第２の端末装置を特定する、
   ことを特徴とする請求項１又は２に記載のサービス活動支援方法。
4. 前記コンピュータは、
   前記１以上の第２の端末装置から事前に登録された、サービス活動を特定する種別と、前記１以上の第２の端末装置のユーザの前記サービス活動に対する技能レベルとを、前記１以上の第２の端末装置毎に対応付けて管理し、
   前記第１の端末装置に対して、特定した前記１以上の第２の端末装置の情報とともに、前記技能レベルに関する情報を送信し、前記第１の端末装置により、選択された第２の端末装置に対して、前記要求に関する情報を送信する、
   ことを特徴とする請求項１から３のいずれか１項に記載のサービス活動支援方法。
5. 前記コンピュータは、
   前記サービス活動を特定する種別と、エリアに関する範囲情報とを対応づけて管理し、
   前記要求で指定されたサービス活動の種別に対応する範囲情報で規定されるエリア内に存在する、前記１以上の第２の端末装置を特定する、
   ことを特徴とする請求項１から４のいずれか１項に記載のサービス活動支援方法。
6. 仮想的に地図上に設定された特定のエリアの内側に位置する第１の端末装置から送信されたサービス活動の支援に関する要求を受信すると、前記特定のエリアの内側に位置する、前記第１の端末装置とは異なる、１以上の第２の端末装置を特定し、
   特定した前記１以上の第２の端末装置に対して、前記要求に関する情報を送信する、
   処理をコンピュータに実行させるサービス活動支援プログラム。
7. 複数の端末装置と通信可能なシステムであって、
   位置情報と仮想的に地図上に設定されたエリアにかかるエリア情報とに基づき、自装置が属するエリアにかかる第１のエリア情報を送信する送信部をそれぞれ有する複数の端末装置から、前記第１のエリア情報を受信し、前記複数の端末装置のうちの第１の端末装置から、サービス活動の支援に関する要求を受信した場合、前記第１の端末装置にかかる前記第１のエリア情報に基づき、前記第１の端末装置が属するエリアの内側に位置する１以上の第２の端末装置を特定し、特定した前記１以上の第２の端末装置に対して、前記要求に関する情報を送信する管理部を有する、
   ことを特徴とするシステム。
8. 前記第１の端末装置は、前記第１の端末装置が属するエリアの外側に位置することを検知した場合、前記要求を送信するアプリケーションソフトウェアを消去し、
   前記１以上の第２の端末装置は、前記１以上の第２の端末装置が属するエリアの外側に位置することを検知した場合、前記要求に関する情報を受信するアプリケーションソフトウェアを消去する、
   ことを特徴とする請求項７に記載のシステム。

Images