(57)【要約】【課題】ユーザ間の助け合いを支援することができる情報処理装置等を提供する。【解決手段】情報処理装置１は、被サポータから位置情報を含む支援依頼を受け付ける受付部と、複数のサポータ夫々の位置情報を取得する取得部と、前記被サポータ及びサポータの位置情報に基づき、前記被サポータに対する支援を依頼する前記サポータを検索する検索部と、検索した前記サポータ又は被サポータの携帯端末に、相手方に関する情報を用いて、前記サポータ又は被サポータを相手方へ誘導する誘導情報を出力する出力部とを備えることを特徴とする。【選択図】図１
2020021375.tif 000002
【特許請求の範囲】
【請求項１】
被サポータから位置情報を含む支援依頼を受け付ける受付部と、
複数のサポータ夫々の位置情報を取得する取得部と、
前記被サポータ及びサポータの位置情報に基づき、前記被サポータに対する支援を依頼する前記サポータを検索する検索部と、
検索した前記サポータ又は被サポータの携帯端末に、相手方に関する情報を用いて、前記サポータ又は被サポータを相手方へ誘導する誘導情報を出力する出力部と
を備えることを特徴とする情報処理装置。
【請求項２】
前記被サポータの属性情報と、前記サポータの属性情報とを記憶する記憶部を備え、
前記検索部は、前記位置情報及び属性情報に基づき前記サポータを検索する
ことを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記支援依頼に応じて、前記サポータの属性情報に基づくスコアを算出する算出部を備え、
前記出力部は、前記スコアに応じて前記サポータの携帯端末に前記誘導情報を出力する
ことを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記出力部は、
前記スコアが所定条件を充足するか否かに応じて前記サポータに対する前記誘導情報を出力し、
前記所定条件を充足する前記スコアに係る前記サポータが検索されなかった場合、前記所定条件を変更する
ことを特徴とする請求項３に記載の情報処理装置。
【請求項５】
前記出力部は、前記被サポータの属性情報に応じて、前記被サポータの携帯端末に出力する前記誘導情報の出力態様を変更する
ことを特徴とする請求項２〜４のいずれか１項に記載の情報処理装置。
【請求項６】
前記支援依頼の完了通知を前記被サポータ又はサポータの携帯端末から取得する第２取得部を備え、
前記誘導情報を出力後、前記完了通知を所定時間取得しない場合、前記検索部は前記サポータを再検索する
ことを特徴とする請求項１〜５のいずれか１項に記載の情報処理装置。
【請求項７】
前記検索部は、
前記被サポータ及びサポータ夫々が所定範囲内に位置するか否かに応じて検索を行い、
前記サポータを再検索する場合、前記所定範囲を拡大して検索を行う
ことを特徴とする請求項６に記載の情報処理装置。
【請求項８】
前記受付部は、前記サポータ又は被サポータの携帯端末から、前記支援依頼を応援する第２の前記サポータへの応援依頼を受け付け、
前記応援依頼を受け付けた場合、前記検索部は前記第２のサポータを検索し、
検索した前記第２のサポータの携帯端末に前記誘導情報を出力する
ことを特徴とする請求項１〜７のいずれか１項に記載の情報処理装置。
【請求項９】
前記検索部は、前記被サポータ及びサポータ夫々が所定範囲内に位置するか否かに応じて検索を行い、
前記所定範囲内に複数の前記サポータが位置する場合、前記出力部は、複数の前記サポータ夫々と前記被サポータとの距離に応じて前記誘導情報を出力する
ことを特徴とする請求項１〜８のいずれか１項に記載の情報処理装置。
【請求項１０】
前記サポータを検索後、前記取得部は前記被サポータ及びサポータ夫々の現在の位置情報を逐次取得し、
逐次取得する前記位置情報に基づき、前記被サポータ及びサポータの間の距離を逐次判定する判定部を備え、
前記出力部は、判定された距離に応じて前記誘導情報を出力する
ことを特徴とする請求項１〜９のいずれか１項に記載の情報処理装置。
【請求項１１】
前記位置情報に応じた待合せ場所を記憶する第２記憶部を備え、
前記出力部は、前記被サポータ又はサポータの少なくとも一方の前記位置情報に対応する前記待合せ場所に誘導する前記誘導情報を出力する
ことを特徴とする請求項１〜１０のいずれか１項に記載の情報処理装置。
【請求項１２】
前記支援依頼の完了後、前記被サポータ又はサポータに対する評価入力を受け付ける第２受付部と、
前記受付部が前記支援依頼を受け付けた場合、前記被サポータ又はサポータの携帯端末に、前記サポータ又は被サポータの評価を通知する通知部と
を備えることを特徴とする請求項１〜１１のいずれか１項に記載の情報処理装置。
【請求項１３】
前記支援依頼の履歴情報を記憶する第３記憶部を備え、
前記出力部は前記履歴情報を参照して、前記被サポータが過去に支援を受けた前記サポータ以外の前記サポータに対して前記誘導情報を出力する
ことを特徴とする請求項１〜１２のいずれか１項に記載の情報処理装置。
【請求項１４】
前記出力部は、
前記支援依頼の完了後、前記支援を受けたサポータに対する前記誘導情報の出力を一定期間禁止し、
前記一定期間が経過後、前記支援を受けたサポータに対する前記誘導情報の出力を許可する
ことを特徴とする請求項１３に記載の情報処理装置。
【請求項１５】
前記支援依頼の履歴情報を記憶する第３記憶部と、
前記履歴情報を参照して、前記支援依頼が発生する場所及び時間を推定する推定部と
を備えることを特徴とする請求項１〜１４のいずれか１項に記載の情報処理装置。
【請求項１６】
被サポータから位置情報を含む支援依頼を受け付け、
複数のサポータ夫々の位置情報を取得し、
前記被サポータ及びサポータの位置情報に基づき、前記被サポータに対する支援を依頼する前記サポータを検索し、
検索した前記サポータ又は被サポータの携帯端末に、相手方に関する情報を用いて、前記サポータ又は被サポータを相手方へ誘導する誘導情報を出力する
処理をコンピュータに実行させることを特徴とする情報処理方法。
【請求項１７】
被サポータの位置情報を含む支援依頼を出力し、
前記支援依頼に対し、前記被サポータから所定範囲内に位置するサポータが前記支援依頼を承諾した旨の応答情報を取得し、
前記サポータに関する情報を用いて前記被サポータを前記サポータへ誘導する誘導情報を取得して出力する
処理をコンピュータに実行させることを特徴とするプログラム。
【請求項１８】
サポータの位置情報を出力し、
前記サポータから所定範囲内に位置する被サポータからの支援要求を取得し、
該支援要求を承諾するか否かの操作入力を受け付け、
操作入力に応じて、前記支援要求を承諾する旨の応答情報を出力し、
前記被サポータに関する情報を用いて前記サポータを前記被サポータへ誘導する誘導情報を取得して出力する
処理をコンピュータに実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理方法及びプログラムに関する。
【背景技術】
【０００２】
街中、公共交通機関などの場において、手助けを求めている人に対して手助けできる人を紹介することで、困りごとの解決を支援する手法が提案されている。例えば特許文献１では、ユーザの端末装置から手助けを求める入力を受け付けて他のユーザの端末装置に依頼情報を発信し、他のユーザの端末装置から依頼を受託する旨の通知を取得した場合、手助けを求めたユーザの外見、あるいは合図とする動作等の情報を他のユーザの端末装置に送信し、手助けを求めているユーザを見つけやすいようにするマッチングシステム等が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０１８−９７３９２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、特許文献１に係る発明は待合せの目印とする情報を伝達するのみで、ユーザらを効率的に誘導するに至っていない。
【０００５】
一つの側面では、ユーザ間の助け合いを支援することができる情報処理装置等を提供することを目的とする。
【課題を解決するための手段】
【０００６】
一つの側面では、情報処理装置は、被サポータから位置情報を含む支援依頼を受け付ける受付部と、複数のサポータ夫々の位置情報を取得する取得部と、前記被サポータ及びサポータの位置情報に基づき、前記被サポータに対する支援を依頼する前記サポータを検索する検索部と、検索した前記サポータ又は被サポータの携帯端末に、相手方に関する情報を用いて、前記サポータ又は被サポータを相手方へ誘導する誘導情報を出力する出力部とを備えることを特徴とする。
【発明の効果】
【０００７】
一つの側面では、ユーザ間の助け合いを支援することができる。
【図面の簡単な説明】
【０００８】
【図１】サポータマッチングシステムの構成例を示す模式図である。
【図２】サーバ及び端末の構成例を示すブロック図である。
【図３】ユーザＤＢ及びエリアＤＢのレコードレイアウトの一例を示す説明図である。
【図４】マッチングの希望条件を設定する設定画面の一例を示す説明図である。
【図５】チャット画面の一例を示す説明図である。
【図６】チャット画面の一例を示す説明図である。
【図７】チャット画面の一例を示す説明図である。
【図８】チャット画面の一例を示す説明図である。
【図９】チャット画面の一例を示す説明図である。
【図１０】チャット画面の一例を示す説明図である。
【図１１】位置情報に基づく検索及び誘導処理について説明するための説明図である。
【図１２】サポータマッチングシステムが実行する処理手順の一例を示すフローチャートである。
【図１３】サポータマッチングシステムが実行する処理手順の一例を示すフローチャートである。
【図１４】サポータ検索のサブルーチンの処理手順を示すフローチャートである。
【図１５】サポータ検索のサブルーチンの処理手順を示すフローチャートである。
【図１６】実施の形態３に係るサーバが実行する処理手順の一例を示すフローチャートである。
【図１７】上述した形態のサーバの動作を示す機能ブロック図である。
【発明を実施するための形態】
【０００９】
以下、本発明をその実施の形態を示す図面に基づいて詳述する。
（実施の形態１）
図１は、サポータマッチングシステムの構成例を示す模式図である。本実施の形態では、困っている人（被サポータ）とサポータとのマッチングを行い、被サポータの「困りごと」の解決を図るサポータマッチングシステムについて説明する。サポータマッチングシステムは、情報処理装置１、端末２、２、２…及びビーコン３、３、３…を有する。各装置は、インターネット等のネットワークＮに接続されている。
【００１０】
情報処理装置１は、種々の情報処理、情報の送受信が可能な情報処理装置であり、例えばサーバ装置、パーソナルコンピュータ等である。本実施の形態では情報処理装置１がサーバ装置であるものとし、以下の説明では簡潔のためサーバ１と読み替える。サーバ１は、端末２を介して被サポータから支援依頼を受け付け、被サポータの付近に位置するサポータを検索し、検索されたサポータの端末２に支援要求を送信する。そしてサーバ１は、両者が対面できるよう誘導を行い、依頼解決を図る。詳しくは後述するように、サーバ１は対話形式（チャット形式）で種々の情報をユーザに案内し、相手方と対面できるようユーザを誘導する。
【００１１】
端末２は、本システムを利用するユーザが使用する端末装置であり、スマートフォン、タブレット端末等の携帯端末である。端末２には本システムに係るサービスを実現するためのアプリケーションプログラムがインストールされており、端末２はアプリケーションプログラムを実行することで後述の処理を行う。以下の説明では便宜上、符号Ａで表すユーザが支援を依頼する被サポータであり、符号Ｂ、Ｃ…で表すユーザが支援を行うサポータであるものとして、ユーザＡの端末２を被サポータ端末２Ａと称し、ユーザＢ、Ｃ…の端末２をサポータ端末２Ｂ、２Ｃ…と称する。
【００１２】
なお、上記のサポータ及び被サポータの区別は便宜的なものであり、被サポータがサポータとなる場合も想定される。すなわち、本システムはユーザ同士の助け合いを支援するものであり、ユーザはサポータ又は被サポータのどちらか一方のみに分類されるものではない。
【００１３】
ビーコン３は、公共の場の所定箇所に設置された近距離無線通信装置であり、例えばＢｌｕｅｔｏｏｔｈ（登録商標）等の通信規格により端末２と近距離無線通信を行うアクセスポイントである。なお、ビーコン３の通信規格はＷｉ−Ｆｉ（登録商標）等、その他の通信規格であってもよい。ビーコン３は、自装置周囲の所定範囲内にビーコン信号を発信し、ビーコン信号に対する応答信号を端末２から受信する。ビーコン３は、応答信号の通信強度等から端末２の位置情報を取得し、サーバ１に転送する。
【００１４】
本実施の形態では一例として、ビーコン３は、鉄道駅のように、一定の区画面積を有する公共の場に設置されているものとして説明を行う。具体的には、複数のビーコン３が鉄道駅の複数の地点にそれぞれ設置されている。各ビーコン３は、駅構内を区分した複数のエリアそれぞれに割り当てるように設置され、自装置のエリア内に位置する端末２からの信号を受信する。
【００１５】
なお、サーバ１は端末２の位置情報を取得可能であればよく、例えば端末２が受信したＧＰＳ（Global Positioning System）信号を取得することで、端末２の位置情報を特定するようにしてもよい。
【００１６】
図２は、サーバ１及び端末２の構成例を示すブロック図である。サーバ１は、制御部１１、主記憶部１２、通信部１３、補助記憶部１４を備える。
制御部１１は、一又は複数のＣＰＵ（Central Processing Unit）、ＭＰＵ（Micro-Processing Unit）、ＧＰＵ（Graphics Processing Unit）等の演算処理装置を有し、補助記憶部１４に記憶されたプログラムＰ１を読み出して実行することにより、サーバ１に係る種々の情報処理、制御処理等を行う。主記憶部１２は、ＳＲＡＭ（Static Random Access Memory）、ＤＲＡＭ（Dynamic Random Access Memory）、フラッシュメモリ等の一時記憶領域であり、制御部１１が演算処理を実行するために必要なデータを一時的に記憶する。通信部１３は、通信に関する処理を行うための処理回路等を含み、外部と情報の送受信を行う。
【００１７】
補助記憶部１４は大容量メモリ、ハードディスク等であり、制御部１１が処理を実行するために必要なプログラムＰ１、その他のデータを記憶している。また、補助記憶部１４は、ユーザＤＢ１４１及びエリアＤＢ１４２を記憶している。ユーザＤＢ１４１は、各ユーザの情報を格納するデータベースである。エリアＤＢ１４２は、各ビーコン３の情報と、各ビーコン３が割り当てられたエリアに関する情報とを格納するデータベースである。
【００１８】
なお、補助記憶部１４はサーバ１に接続された外部記憶装置であってもよい。また、サーバ１は複数のコンピュータからなるマルチコンピュータであってもよく、ソフトウェアによって仮想的に構築された仮想マシンであってもよい。
【００１９】
また、本実施の形態においてサーバ１は上記の構成に限られず、例えば可搬型記憶媒体に記憶された情報を読み取る読取部、操作入力を受け付ける入力部、画像を表示する表示部等を含んでもよい。
【００２０】
端末２は、制御部２１、主記憶部２２、通信部２３、表示部２４、入力部２５、補助記憶部２６を備える。
制御部２１は、一又は複数のＣＰＵ、ＭＰＵ等の演算処理装置を有し、補助記憶部２６に記憶されたプログラムＰ２を読み出して実行することにより、端末２に係る種々の情報処理、制御処理等を行う。主記憶部２２は、ＲＡＭ等の一時記憶領域であり、制御部２１が演算処理を実行するために必要なデータを一時的に記憶する。通信部２３は、通信を行うためのアンテナ、処理回路等を含み、外部と情報の送受信を行う。表示部２４は、液晶ディスプレイ、有機ＥＬ（Electro Luminescence）ディスプレイ等の表示装置であり、制御部２１から与えられた画像を表示する。入力部２５は、タッチパネル、メカニカルキー等の操作インターフェイスであり、操作内容を制御部２１に入力する。補助記憶部２６はＲＯＭ（Read Only Memory）等の不揮発性記憶領域であり、制御部２１が処理を実行するために必要なプログラムＰ２、その他のデータを記憶している。
【００２１】
図３は、ユーザＤＢ１４１及びエリアＤＢ１４２のレコードレイアウトの一例を示す説明図である。
ユーザＤＢ１４１は、ユーザＩＤ列、氏名列、ニックネーム列、性別列、年齢列、サポータ列、通知列、希望条件列、イラスト列、スキル列、制約列、位置情報列、履歴列を含む。ユーザＩＤ列は、各ユーザを識別するためのＩＤを記憶している。氏名列、ニックネーム列、性別列、及び年齢列はそれぞれ、ユーザＩＤと対応付けて、ユーザの氏名、本サービス上でのニックネーム、性別、及び年齢を記憶している。サポータ列は、ユーザＩＤ列と対応付けて、ユーザがサポータになるか否か、サポータ設定の有無を記憶している。通知列は、ユーザＩＤと対応付けて、本システム（サーバ１）からの通知を受信するか否か、通知受信設定の有無を記憶している。
【００２２】
希望条件列は、ユーザＩＤと対応付けて、サポータとして検索される相手方の希望条件を記憶している。イラスト列は、ユーザＩＤと対応付けて、ユーザのプロフィール用画像を記憶している。スキル列は、ユーザＩＤと対応付けて、ユーザが有するスキルを記憶している。スキル列には、ユーザが保有する資格とレベル（例えばサービス介助士２級）、話せる言語とレベル（例えば英会話レベル）、その他の特殊スキルとレベル（例えば趣味とその熟練度）など、ユーザが有する種々の技能に関する情報が記憶されている。
【００２３】
制約列は、ユーザＩＤと対応付けて、ユーザが生活を送る上で制約となり得る情報を記憶している。制約となり得る情報は、例えば障がい者であるか、高齢者であるか、妊婦であるか、外国人であるか、現地に詳しくない旅行者であるか等、種々の情報であり得る。制約列には、ユーザに困りごとが発生する主たる要因となる属性情報が格納されている。
【００２４】
位置情報列は、ユーザＩＤと対応付けて、ビーコン３等から取得したユーザの位置情報を記憶している。履歴列は、ユーザＩＤと対応付けて、ユーザによる本システムの利用履歴を記憶している。履歴列には、例えば困りごとが発生した場所（位置情報）、発生した時間、支援内容、ユーザによる支援回数などが記憶されている。
【００２５】
エリアＤＢ１４２は、ビーコンＩＤ列、設置区分列、設置エリア列、待合せ場所列、目印画像列を含む。ビーコンＩＤ列は、各ビーコン３を識別するためのＩＤを記憶している。設置区分列及び設置エリア列はそれぞれ、ビーコンＩＤと対応付けて、ビーコン３の設置場所の区分と、設置場所とを記憶している。待合せ場所列は、ビーコンＩＤと対応付けて、サポータ又は被サポータの少なくとも一方の位置情報に応じて指定される待合せ場所を記憶している。本実施の形態でサーバ１は、各ビーコン３に対応付けて待合せ場所を設定しており、被サポータの端末２を検知したビーコン３に対応する待合せ場所を指定して各ユーザに通知する。目印画像列は、ビーコン３と対応付けて、待合せ場所の目印となる画像を記憶している。
【００２６】
なお、本実施の形態では各ビーコン３に対して担当するエリアを割り当てるものとして説明するが、ＧＰＳ信号を位置情報として利用する場合、所定の座標範囲（端末２からの距離、緯度及び経度の数値範囲等）をエリアとして設定してもよい。
【００２７】
図４は、マッチングの希望条件を設定する設定画面の一例を示す説明図である。以下では、本実施の形態の概要について説明する。
まず被サポータ端末２Ａは、図４に示す設定画面において、ユーザ（被サポータ）が支援を依頼する際の、サポータに希望する希望条件の設定入力を受け付ける。被サポータが設定する希望条件は、例えばサポータの性別、年代等のほかに、言語レベルや保有資格などのサポータのスキル、過去のサポートの有無、後述する他の被サポータからの評価（図４では「やさしさレベル」）などを含む。被サポータ端末２Ａは、各種希望条件についてユーザによる指定入力を受け付ける。サーバ１は、ユーザＩＤと対応付けて、設定された希望条件をユーザＤＢ１４１に記憶する。
【００２８】
なお、上記の希望条件の設定は任意であり、ユーザは希望条件を設定せずとも良い。また、上記の希望条件は一例であって、その他の条件を設定してもよい。例えばサポータを検索する検索範囲、あるいは支援依頼を受け付ける時間等も希望条件に含まれ得る。また、ユーザが希望条件を設定しなくても、困りごとの入力や、ユーザの属性情報等から自動で希望条件が選択されても良い。また、希望条件はユーザの初期登録時、あるいは支援依頼時等の任意のタイミングで設定されてよい。
【００２９】
図５〜図１０は、チャット画面の一例を示す説明図である。続いて図５〜図１０を用いて、被サポータがサポータの支援を依頼して両者が合流するまでの流れを説明する。
本実施の形態においてサーバ１は、各端末２との間で対話形式による情報の入出力を行う。すなわちサーバ１は、図５〜図１０で例示するチャット画面上でユーザに対する質問、案内等を提示し、チャット画面上での入力操作に応じて新たに対話文、画像等を生成してチャット画面に出力する。このようにサーバ１は、ユーザとの間の情報のやり取りを対話形式で行うことで、スムーズなマッチングを行う。
【００３０】
なお、後述するようにサーバ１は、テキスト又は画像の表示ではなく、音声の入出力による対話を行ってもよい。
【００３１】
図５では、被サポータが支援依頼を発信する場合の被サポータ端末２Ａのチャット画面を図示している。困りごとが生じた場合、被サポータは被サポータ端末２Ａを操作し、サポータによる支援をサーバ１に依頼する。例えば図５に示すように、被サポータ端末２Ａはチャット画面上で依頼内容のメニュー５１を吹き出し中に表示し、ユーザからの操作入力に従って支援依頼を発信する。例えば被サポータ端末２Ａは、依頼内容と、被サポータのユーザＩＤとを含む情報をサーバ１に送信する。
【００３２】
なお、支援依頼の入力方法は対話形式での入力に限定されず、例えば所定の依頼フォームでユーザが依頼内容等を選択入力するようにしてもよく、あるいはユーザが依頼内容を自由入力する形であってもよい。
【００３３】
サーバ１は、被サポータ端末２Ａから支援依頼を取得する。この場合にサーバ１は、依頼内容、ユーザＩＤ等のほかに、被サポータ端末２Ａの位置情報を含む支援依頼を取得する。例えば被サポータ端末２Ａは、ビーコン３との間で無線通信を行い、ビーコン３経由で支援依頼をサーバ１に送信する。サーバ１は、支援依頼の取得元であるビーコン３の設置位置、ビーコン３が支援依頼を受信した際の通信強度等の情報を位置情報として取得する。
【００３４】
なお、上述の如く被サポータ端末２ＡがＧＰＳ信号を受信し、サーバ１は被サポータ端末２Ａにおいて受信したＧＰＳ信号を位置情報として取得してもよい。
【００３５】
被サポータ端末２Ａから支援依頼を受け付けた場合、サーバ１は、被サポータが依頼した支援に適したサポータをユーザＤＢ１４１から検索し、検索したサポータの端末２に支援要求を送信する。
【００３６】
例えばサーバ１はまず、サポータ（ユーザ）により任意に設定されているサポータ設定、通知設定等が「ＯＮ」になっているか否かを判定する。各設定が「ＯＮ」になっている場合、サーバ１は、被サポータ端末２Ａの位置情報と、サポータ端末２Ｂ、２Ｃ…の位置情報とに基づき、被サポータの付近に居るサポータを検索する。サポータ端末２Ｂ、２Ｃ…の位置情報は、被サポータ端末２Ａの位置情報と同様に、ビーコン３との無線通信により取得する。
【００３７】
例えばサーバ１は、被サポータ端末２Ａとサポータ端末２Ｂ、２Ｃ…とが、同じビーコン３のエリアに位置するか否かに応じて検索を行う。サーバ１は、被サポータ端末２Ａと同じエリアに位置するサポータ端末２Ｂ、２Ｃ…のユーザをサポータとして検索する。
なお、位置情報に基づくサポータの検索処理については、図１１を用いて詳述する。
【００３８】
続いてサーバ１は、被サポータの属性情報とサポータの属性情報とを比較し、サポータが被サポータの依頼を解決する上で適したユーザか否かを判定することにより検索を行う。
【００３９】
被サポータの属性情報は、例えば障がい者であるか、妊娠者であるか、高齢者であるか、外国人であるか等、生活を送る上での制約となり得る情報であって、困りごとが発生する主な要因となり得る情報である。被サポータ端末２Ａから支援依頼を受け付けた場合、サーバ１は、被サポータの属性情報をユーザＤＢ１４１から読み出し、当該情報を元に判定を行う。
【００４０】
サポータの属性情報は、例えばサポータが有するスキルに関する情報であり、例えば保有資格、言語能力、その他の能力などである。ユーザＤＢ１４１からサポータを検索する場合、サーバ１は各ユーザ（サポータ）の属性情報をユーザＤＢ１４１から読み出し、被サポータの属性情報とマッチングを行う。例えば被サポータが障がい者である場合、サーバ１は、介助士の資格を保有するユーザをサポータとして検索する。あるいは被サポータが外国人である場合、サーバ１は、被サポータの母国語のレベルが高いユーザをサポータとして検索する。
【００４１】
サーバ１は上述の位置情報、属性情報のほかに、例えば被サポータが任意に設定する希望条件と適合するか否かに応じてサポータを検索する。また、例えばサーバ１は、ユーザＤＢ１４１に格納された被サポータの利用履歴（履歴情報）を参照して、被サポータに対して同じ相手がマッチングされないよう、過去に支援を受けたことがあるユーザ以外のユーザをサポータとして検索すると好適である。これにより、同じユーザに依頼が偏って負担が増大するような事態を防止すると共に、本システムが単なる出会いを求めたマッチングアプリケーションとして利用されることを防止する。
【００４２】
また、支援を受けたことがあるユーザを、支援を受けてから一定期間は検索対象から除外し、一定期間経過後に再び検索対象とするようにしてもよい。すなわちサーバ１は、被サポータが過去に支援を受けたことがあるユーザに対し、支援依頼を依頼完了後から一定期間禁止し、一定期間経過後に再度の依頼を許可する。これにより、本システムの利用回数が多い被サポータがサポータとマッチングできなくなる事態を防止することができる。
【００４３】
サーバ１は、検索したサポータの端末２に対して、被サポータからの支援要求を送信する。以下の説明では便宜上、ユーザＢがサポータとして検索されたものとして、サポータ端末２Ｂに支援要求を送信する場合について説明する。
【００４４】
図６を用いて説明を続ける。図６では、支援要求を表示する場合のチャット画面を図示している。サーバ１から支援要求を取得した場合、サポータ端末２Ｂは、依頼内容と被サポータの属性情報（制約）とを含むテキストを吹き出しに表示する。サポータ端末２Ｂはユーザから、支援要求を承諾するか否かについて操作入力を受け付ける。例えばサポータ端末２Ｂは、吹き出し中のメニュー６１への操作入力を受け付ける。
【００４５】
支援要求を承諾した場合、サポータ端末２Ｂは依頼を承諾した旨の応答情報をサーバ１に送信する。応答情報を取得した場合、サーバ１は、被サポータ端末２Ａ及びサポータ端末２Ｂそれぞれに、相手方（サポータ又は被サポータ）の情報を用いて、ユーザを相手方に誘導する誘導情報を出力する。
【００４６】
図７及び図８では、被サポータ端末２Ａに表示されるチャット画面の一例を図示している。被サポータ端末２Ａはサーバ１から情報の配信を受け、図７及び図８に例示する各種情報をチャット画面上に表示する。例えば図７に示すように、被サポータ端末２Ａは、支援を依頼した被サポータのプロフィール情報を吹き出しに表示する。プロフィール情報は、被サポータのニックネーム、性別、年代等のほかに、言語レベル、保有資格など、マッチング（検索）時に参照した属性情報を含む。プロフィール情報を共有することで、被サポータはサポータがどのような人物かを予め確認することができる。
【００４７】
また、被サポータ端末２Ａはプロフィール情報として、サポータが過去の依頼で他のユーザから得た評価（図７では「やさしさレベル」）を併せて表示する。他のユーザからの評価については後述する。
【００４８】
また、被サポータ端末２Ａは、被サポータの現在位置を表示する。例えば図７に示すように、被サポータ端末２Ａは、ビーコン３が設置された駅構内の見取り図上に、サポータの現在位置をアイコンにより表示する。なお、この場合に被サポータ端末２Ａは、自装置のユーザである被サポータの現在位置も併せて表示してもよい。
【００４９】
図８に移って、被サポータ端末２Ａはさらに、被サポータとの待合せ場所をチャット画面上に表示する。待合せ場所は、支援を依頼する被サポータ、又は支援を依頼されたサポータの少なくともいずれか一方の位置情報に応じて指定される地点である。本実施の形態では、被サポータの位置を基準に待合せ場所が指定される。
【００５０】
具体的には、待合せ場所は駅構内のビーコン３毎に設定されている。サーバ１は、被サポータ端末２Ａからの応答信号を受信したビーコン３、つまり被サポータ端末２Ａの位置情報の取得元であるビーコン３に対応する待合せ場所を指定する。サーバ１は、該当するビーコン３のビーコンＩＤと対応付けられた待合せ場所、目印画像等の情報をエリアＤＢ１４２から読み出し、被サポータ端末２Ａに配信する。例えば被サポータ端末２Ａは、駅構内の見取り図上に待合せ場所をアイコンにより表示すると共に、目印となる画像を表示する。
【００５１】
上記ではチャット画面上でテキスト、画像等を表示することにより誘導を行ったが、被サポータ端末２Ａにプロフィール情報等を出力する場合、サーバ１は、被サポータの属性情報に応じて出力態様を変更すると好適である。例えばサーバ１は、待合せ場所を被サポータ端末２Ａに出力する場合において、被サポータが視覚障がい者である場合、テキスト、画像等ではなく音声により待合せ場所を案内する。例えばサーバ１は、属性情報に応じて待合せ場所に関するコンテンツを画像及び音声でエリアＤＢ１４２に格納しておき、支援を依頼した被サポータの属性情報に応じて、被サポータ端末２Ａに画像又は音声のいずれかを出力する。これにより、制約を有する被サポータを適切に誘導することができる。
【００５２】
サポータ端末２Ｂに対しても被サポータ端末２Ａと同様、サポータのプロフィール情報、現在位置、待合せ場所などが出力される。これにより被サポータ及びサポータは、互いに相手方に対面できるように誘導される。
【００５３】
さらに被サポータ端末２Ａは、被サポータによる操作入力に従い、被サポータの外見上の特徴を共有する。図９では、被サポータの外見上の特徴を共有する際のチャット画面を図示している。例えば図９Ａに示すように、被サポータ端末２Ａは、吹き出し中に表示される各メニュー９１への操作入力を受け付けることにより、被サポータの所持品、服装、装飾品等について情報の入力を受け付ける。被サポータ端末２Ａは、入力された各種情報をサーバ１に送信する。
【００５４】
サーバ１は、被サポータ端末２Ａから取得した情報を元に、被サポータの外見上の特徴に関する情報をサポータ端末２Ｂに送信して表示させる。例えば図９Ｂに示すように、サーバ１は被サポータ端末２Ａにおいて入力された各種情報をサポータ端末２Ｂにテキスト表示させるほか、各種情報を元に、被サポータの外見を表すイメージ画像を生成して表示させる。例えばサーバ１は、ユーザＤＢ１４１に登録されている被サポータのプロフィール用画像に対して、所持品、服装等のアイテムを合成してイメージ画像を生成する。サポータはイメージ画像を参考に、被サポータを容易に探すことができる。
【００５５】
なお、上記では被サポータの外見を共有する旨を説明したが、サポータの外見についても特徴を共有してもよいことは勿論である。
【００５６】
上述の如くサーバ１は被サポータ及びサポータが対面できるように誘導する。被サポータと対面した場合、サポータは被サポータの依頼を解決するべく支援を行う。この場合において、サポータ一人では依頼を解決できない場合、サポータ（又は被サポータ）が応援者（第２のサポータ）を要請して複数人で解決できるようにすると好適である。例えばサポータ端末２Ｂは、不図示のチャット画面での操作入力により、サーバ１へ応援依頼を送信する。サポータ端末２Ｂから応援依頼を取得した場合、サーバ１は上記と同様に位置情報、属性情報等に基づく検索を行い、被サポータからの依頼に適した応援者をユーザＤＢ１４１から検索する。サーバ１は応援者の端末２に応援依頼を送信し、被サポータのプロフィール情報、現在位置等を共有して誘導する。これにより、被サポータの依頼を効率的に解決することができる。
【００５７】
図１０は、支援依頼が完了した場合のチャット画面を図示している。図１０Ａでは被サポータ端末２Ａに表示されるチャット画面を、図１０Ｂではサポータ端末２Ｂに表示されるチャット画面を図示している。上述の処理の結果、被サポータとサポータとが無事に対面し、被サポータの困りごとが解決した場合、被サポータは依頼が完了した旨をサーバ１に報告する。例えば被サポータ端末２Ａは、図１０Ａにおける吹き出しで「サポータと対面した」と表示されるメニュー１０１への操作入力を受け付けた場合、支援依頼が完了した旨の完了通知をサーバ１に送信する。
【００５８】
完了通知をサーバ１に送信する場合、被サポータ端末２Ａは、被サポータからサポータへの評価入力を受け付け、入力されたサポータの評価を併せてサーバ１に通知する。例えば図１０Ａに示すように、被サポータ端末２Ａは、「とても安心できた」から「問題があった」までの複数段階で評価入力を受け付ける。被サポータ端末２Ａは、入力された評価を含む完了通知をサーバ１に送信する。
【００５９】
被サポータ端末２Ａから完了通知を取得した場合、サーバ１は依頼が完了した旨をサポータ端末２Ｂに送信し、御礼メッセージをサポータ端末２Ｂに表示させる。その後、サポータ端末２Ｂも被サポータ端末２Ａと同様に、サポータから被サポータへの評価入力を受け付け、サーバ１に送信する。このように、被サポータ及びサポータは依頼完了後、互いに相手方の評価を行う。
【００６０】
例えばサーバ１は、上述のマッチングを行って相手方のプロフィール情報を端末２に出力する場合、過去の依頼時に他のユーザが相手方に対して入力した評価をプロフィール情報として通知する。例えば図７で図示したように、サーバ１はチャット画面において、他のユーザからの評価を「やさしさレベル」として表示させる。これにより、相手方がどのような人物か、他のユーザから入力された客観的な評価を事前に知ることができる。
【００６１】
また、例えばサーバ１は、相手方の評価をプロフィール情報として共有するだけでなく、マッチング自体にユーザの評価を用いてもよい。例えば図４で述べたように、他の被サポータからの評価について希望条件が設定されている場合、サーバ１は、希望条件を満たす評価を有するユーザをサポータとして検索する。あるいはサーバ１は、上記とは逆に、他のサポータからの評価が一定以上である被サポータの支援依頼のみを受け付けることをサポータの希望条件として設定しておき、一定以上の評価を有する被サポータからの支援依頼についてのみ、当該サポータを対象者として検索するようにしてもよい。
【００６２】
なお、上記で端末２はサーバ１にのみ完了通知を行っているが、支援依頼の完了通知をＳＮＳ（Social Networking Service）上に出力し、本サービスにより行われた助け合いを一般ユーザに通知（拡散）してもよい。これにより、本サービスを広く一般に告知し、サポータの増加に資することができる。また、この場合にサーバ１は、上記で説明した相手方からの評価に加えて、あるいは相手方からの評価に代えて、一般ユーザからのＳＮＳ上での評価（所謂「いいね」など）をサポータ又は被サポータに対する評価としてもよい。これにより、当事者間だけでなく一般ユーザからのより客観的な評価を集めることができる。
【００６３】
図１１は、位置情報に基づく検索及び誘導処理について説明するための説明図である。図１１では、各ユーザの位置情報に応じてサポータが検索され、被サポータの下へ誘導される様子を概念的に図示している。
図１１Ａでは、被サポータの周囲に位置する複数のユーザからサポータが選択される様子を図示している。上述の如く、サーバ１は同じエリアに位置するユーザをサポータとして検索する。この場合に、同じエリアに複数のユーザが存在する場合があり得る。この場合、サーバ１は各ユーザと被サポータとの距離に応じてサポータを選択する。例えばサーバ１は、最も距離が近いユーザをサポータとして選択する。なお、ユーザ間（端末２間）の距離は、例えば複数のビーコン３を用いた三点測位等によって算出すればよい。図１１Ａの例では、ユーザＡ（被サポータ）に最も近いユーザＢがサポータとして選択され、サポータ端末２Ｂに支援要求が送信される。
【００６４】
図１１Ｂに移って、ユーザＢがサポータとして選択されたものの、両者が対面することができず、依頼が解決しない場合を考える。この場合、サーバ１はユーザＢへの支援要求をキャンセルして別のサポータを再検索し、支援要求を行う。例えばサーバ１は、支援要求をサポータ端末２Ｂに送信してプロフィール情報等を共有した後、支援依頼の完了通知を取得しないまま所定時間が経過したか否かを判定する。所定時間が経過したと判定した場合、サーバ１は依頼をキャンセルし、別のサポータを検索する。
【００６５】
再検索を行う場合、例えばサーバ１は、検索範囲（エリア）を１回目の検索時よりも拡大して検索を行う。図１１Ｂの例では、サーバ１は、一台のビーコン３に対応するエリアから三台のビーコン３を包含するエリアへと検索範囲を拡大し、拡大したエリア内の端末２を検索する。エリアを拡大しても端末２の検索に失敗した場合、サーバ１はさらにエリアを拡大して検索を行う。このように、サーバ１は検索する毎に検索範囲を段階的に拡大し、別の端末２を検索する。例えば図１１Ｂに示すように、拡大したエリアからユーザＣの所持するサポータ端末２Ｃが検索された場合、サーバ１は、検索したサポータ端末２Ｃに支援要求を改めて送信する。
【００６６】
サーバ１は、上記と同様にサポータ端末２ＣにユーザＡのプロフィール情報、現在位置等を共有し、待合せ場所へと誘導する。ここでサーバ１は、被サポータ端末２Ａ及びサポータ端末２Ｃから現在の位置情報を逐次取得して両者の距離を逐次判定し、判定した両者の距離に応じて誘導を行う。例えばサーバ１は、距離が一定以下になったと判定した場合、被サポータ端末２Ａとサポータ端末２Ｃとの間の通話を許可する通話許可を各端末２に送信する。これにより、ユーザＡ、Ｃは互いに通話を行い、容易に対面することができる。このように、サーバ１は各ユーザの位置情報に基づく検索、再検索、及び誘導を行うことで、スムーズなマッチングを可能とする。
【００６７】
なお、上記では被サポータ及びサポータの間の距離に応じて通話許可を出力するようにしたが、本実施の形態はこれに限定されるものではない。例えばサーバ１は、両者が一定以下の距離まで接近した場合に相手方が近くに居る旨のアラートを出力する、あるいは測定距離をそのまま表示させる等してもよい。つまりサーバ１は、両者の距離に応じて誘導を行うことができればよく、その処理内容は特に限定されない。
【００６８】
図１２及び図１３は、サポータマッチングシステムが実行する処理手順の一例を示すフローチャートである。図１２及び図１３に基づき、サポータマッチングシステムの処理内容について説明する。
被サポータ端末２Ａの制御部２１は、ユーザからの操作入力に従い、サポータの支援を依頼する支援依頼をサーバ１に送信する（ステップＳ１１）。支援依頼は、被サポータのユーザＩＤ、依頼内容、位置情報等を含む。被サポータ端末２Ａから支援依頼を取得した場合、サーバ１の制御部１１は、各サポータ端末２Ｂ、２Ｃ…の位置情報を取得する（ステップＳ１２）。制御部１１は、被サポータ端末２Ａの位置情報と、各サポータ端末２Ｂ、２Ｃ…の位置情報とに基づき、被サポータに対する支援を依頼するサポータを検索するサブルーチンを実行する（ステップＳ１３）。制御部１１は、検索したサポータ端末２Ｂに支援要求を送信する（ステップＳ１４）。
【００６９】
サーバ１から支援要求を取得した場合、サポータ端末２Ｂの制御部２１は、被サポータからの支援依頼の内容を出力（表示）する（ステップＳ１５）。制御部２１は、ユーザからの操作入力に従い、支援依頼を承諾するか否かを判定する（ステップＳ１６）。支援依頼を承諾しないと判定した場合（Ｓ１６：ＮＯ）、制御部２１は一連の処理を終了する。支援依頼を承諾すると判定した場合（Ｓ１６：ＹＥＳ）、制御部２１は、支援依頼を承諾する旨の応答情報をサーバ１に送信する（ステップＳ１７）。
【００７０】
サポータ端末２Ｂから支援依頼を承諾する旨の応答情報を取得した場合、サーバ１の制御部１１は、被サポータ端末２Ａ及びサポータ端末２Ｂにそれぞれ、相手方の情報を用いて、ユーザを相手方に誘導する誘導情報を送信する（ステップＳ１８）。誘導情報は、例えば相手方のプロフィール情報、現在位置、待合せ場所等や、それらに基づいた情報等である。また、例えば制御部１１は、被サポータ及びサポータの現在の位置情報を逐次取得して両者の距離を逐次判定し、両者の距離に応じて、被サポータ端末２Ａ及びサポータ端末２Ｂの間の通話を許可する通話許可を出力するようにしてもよい。また、例えば制御部１１は、被サポータの属性情報に応じて、被サポータ端末２Ａに出力する誘導情報の出力態様を変更してもよい。サポータ端末２Ｂの制御部２１は、サーバ１から受信した誘導情報を出力する（ステップＳ１９）。被サポータ端末２Ａの制御部２１も同様に誘導情報を出力する（ステップＳ２０）。
【００７１】
被サポータ端末２Ａの制御部２１は、ユーザからの操作入力に従い、ユーザの外見上の特徴を相手方と共有するか否かを判定する（ステップＳ２１）。特徴を共有すると判定した場合（Ｓ２１：ＹＥＳ）、制御部２１は外見上の特徴に関する情報の入力を受け付け、サーバ１に通知する（ステップＳ２２）。
【００７２】
外見上の特徴に関して被サポータ端末２Ａから通知を取得した場合、サーバ１の制御部１１は当該通知をサポータ端末２Ｂに送信する（ステップＳ２３）。サポータ端末２Ｂの制御部２１は、被サポータの外見上の特徴に関する通知をサーバ１から取得したか否かを判定する（ステップＳ２４）。外見上の特徴に関する通知を取得したと判定した場合（Ｓ２４：ＹＥＳ）、制御部２１は被サポータの外見上の特徴に関する情報を出力する（ステップＳ２５）。
【００７３】
図１３に移って、ステップＳ２５の処理を実行後、又はステップＳ２４でＮＯの場合、サポータ端末２Ｂの制御部２１は、ユーザからの操作入力に従い、承諾した支援依頼に関して応援者（第２のサポータ）による応援を依頼するか否かを判定する（ステップＳ２６）。応援を依頼すると判定した場合（Ｓ２６：ＹＥＳ）、制御部１１は、応援者を依頼する応援依頼をサーバ１に送信する（ステップＳ２７）。サポータ端末２Ｂから応援依頼を取得した場合、サーバ１の制御部１１は、位置情報、属性情報等に基づいて支援依頼に適した応援者をユーザＤＢ１４１から検索し、検索した応援者の端末２に応援依頼を送信する（ステップＳ２８）。
【００７４】
ステップＳ２２の処理を実行後、又はステップＳ２１でＮＯの場合、被サポータ端末２Ａの制御部２１は、ユーザからの操作入力に従い、支援依頼が完了したか否かを判定する（ステップＳ２９）。支援依頼が完了していないと判定した場合（Ｓ２９：ＮＯ）、制御部２１は処理をステップＳ２１に戻す。支援依頼が完了したと判定した場合（Ｓ２９：ＹＥＳ）、制御部２１は、相手方（被サポータ）に対する評価入力をユーザから受け付ける（ステップＳ３０）。制御部２１は、入力された評価を含む支援依頼の完了通知をサーバ１に送信する（ステップＳ３１）。
【００７５】
サーバ１の制御部１１は、ステップＳ１８で相手方のプロフィール等の情報を送信してから所定時間が経過したか否かを判定する（ステップＳ３２）。所定時間が経過したと判定した場合（Ｓ３２：ＹＥＳ）、制御部１１は処理をステップＳ１２に戻す。この場合、制御部１１はサポータの再検索を行い、別のサポータに支援を依頼して被サポータへと誘導する。所定時間が経過していないと判定した場合（Ｓ３２：ＮＯ）、制御部１１は、被サポータ端末２Ａから支援依頼の完了通知を取得したか否かを判定する（ステップＳ３３）。完了通知を取得していないと判定した場合（Ｓ３３：ＮＯ）、制御部１１は処理をステップＳ３２に戻す。
【００７６】
完了通知を取得したと判定した場合（Ｓ３３：ＹＥＳ）、制御部１１は、サポータへの御礼メッセージを含む支援依頼の完了通知をサポータ端末２Ｂに送信する（ステップＳ３４）。サポータ端末２Ｂの制御部２１は、サーバ１から完了通知を取得したか否かに応じて、支援依頼が完了したか否かを判定する（ステップＳ３５）。支援依頼が完了していないと判定した場合（Ｓ３５：ＮＯ）、制御部２１は処理をステップＳ２４に戻す。支援依頼が完了したと判定した場合（Ｓ３５：ＹＥＳ）、制御部２１は、相手方（被サポータ）に対する評価入力をユーザから受け付ける（ステップＳ３６）。制御部２１は、入力された評価をサーバ１に通知する（ステップＳ３７）。
【００７７】
サポータ端末２Ｂから評価に関する通知を取得した場合、サーバ１の制御部１１は、今回の支援依頼が発生した場所の位置情報、依頼内容、相手方からの評価等の情報を、各ユーザ（被サポータ及びサポータ）のユーザＩＤと対応付けて、利用履歴としてユーザＤＢ１４１に記憶する（ステップＳ３８）。制御部１１は一連の処理を終了する。
【００７８】
図１４は、サポータ検索のサブルーチンの処理手順を示すフローチャートである。図１４に基づき、ステップＳ１３のサブルーチンの処理内容を説明する
サーバ１の制御部１１は、支援依頼に含まれる被サポータのユーザＩＤに対応付けられた検索条件をユーザＤＢ１４１から読み出す（ステップＳ５１）。検索条件は、被サポータが任意に設定するサポータの希望条件のほかに、被サポータの属性情報を含む。属性情報は、例えば障がい者であるか、妊娠者であるか、高齢者であるか等、生活を送る上での制約となり得る情報であって、困りごとが発生する要因となり得る情報を含む。制御部１１は、ユーザＤＢ１４１に格納されている任意のユーザの情報を読み出し、被サポータに対する支援を依頼するサポータとして当該ユーザを選択するか否か判定する検索処理を開始する（ステップＳ５２）。
【００７９】
制御部１１はまず、ユーザＩＤと対応付けられたサポータ設定が「ＯＮ」になっているか否かを判定する（ステップＳ５３）。サポータ設定が「ＯＮ」になっていると判定した場合（Ｓ５３：ＹＥＳ）、制御部１１は、ユーザＩＤと対応付けられた通知設定が「ＯＮ」になっているか否かを判定する（ステップＳ５４）。
【００８０】
通知設定が「ＯＮ」になっていると判定した場合（Ｓ５４：ＹＥＳ）、制御部１１は、当該ユーザの情報をステップＳ５１で読み出した検索条件と比較し、検索条件と適合するか否かを判定する（ステップＳ５５）。例えば制御部１１は、被サポータが設定した希望条件との適合の有無を判定するほか、被サポータの属性情報をユーザ（サポータ）の属性情報と比較し、条件が適合するか否かを判定する。サポータの属性情報は、例えばサポータが有するスキルに関する情報であり、例えば保有資格、言語能力、その他の能力などである。制御部１１は、被サポータの制約に対して適合するスキルを有するユーザをサポータとして検索する。その他に制御部１１は、各ユーザが過去の依頼時に他の被サポータから受けた評価を元に、一定以上の評価（例えば被サポータが希望する評価）を有するユーザをサポータとして検索するようにしてもよい。また、例えば制御部１１は、ユーザＤＢ１４１において被サポータのユーザＩＤと対応付けられた利用履歴（履歴情報）を参照して、被サポータが過去に支援を受けたことがあるユーザ以外のユーザを検索するようにすると好適である。
【００８１】
検索条件に適合すると判定した場合（Ｓ５５：ＹＥＳ）、制御部１１は、被サポータ端末２Ａ及びサポータ端末２Ｂからそれぞれ取得した位置情報に基づき、被サポータ及びサポータが所定の同じエリア（所定範囲）内に位置するか否かを判定する（ステップＳ５６）。ステップＳ５６で判定基準とするエリアは、例えば各ビーコン３に対して割り当てられた所定の位置範囲である。制御部１１は、被サポータ端末２Ａとサポータ端末２Ｂが同じビーコン３のエリアに位置するか否かに応じて判定を行う。また、今回の検索処理が２回目以降である場合、すなわち再検索である場合、制御部１１は検索範囲を前回検索時のエリアから拡大して判定を行う。
【００８２】
被サポータ及びサポータが同じエリア内に位置すると判定した場合（Ｓ５６：ＹＥＳ）、又はステップＳ５３〜Ｓ５６でＮＯの場合、制御部１１は、ユーザＤＢ１４１に登録されている全てのユーザについてステップＳ５３〜Ｓ５６の処理が完了し、サポータの検索を終了するか否かを判定する（ステップＳ５７）。検索を終了しないと判定した場合（Ｓ５７：ＮＯ）、制御部１１は処理をステップＳ５３に戻す。
【００８３】
なお、ステップＳ５３〜Ｓ５６の処理は順不同であってもよいことは勿論である。
【００８４】
検索を終了すると判定した場合（Ｓ５７：ＹＥＳ）、制御部１１は、サポータが検索されたか否かを判定する（ステップＳ５８）。サポータが検索されたと判定した場合（Ｓ５８：ＹＥＳ）、制御部１１は、検索された複数のサポータと、支援を依頼した被サポータとの距離を算出し、算出した距離に応じて支援を依頼するサポータを選択する（ステップＳ５９）。例えば制御部１１は、最も距離が近いサポータを選択する。なお、サポータが一名のみしか検索されなかった場合、制御部１１はステップＳ５９をスキップする。サポータが検索されなかったと判定した場合（Ｓ５８：ＮＯ）、制御部１１は、サポータが検索されなかった旨のサポータ不在通知を被サポータ端末２Ａに送信する（ステップＳ６０）。ステップＳ５９又はＳ６０の処理を実行後、制御部１１は一連の処理を終了する。
【００８５】
なお、上記では、被サポータの属性情報として生活上の制約となり得る情報を用い、サポータの属性情報として保有スキルに関する情報を用いてマッチングを行ったが、本実施の形態はこれに限定されるものではない。例えばサーバ１は、事前に各ユーザの性格診断を行い、診断した性格を属性情報として用いてマッチングを行ってもよい。このように、サーバ１は被サポータ及びサポータそれぞれの属性情報に基づきマッチング可能であればよく、属性情報の内容は制約、スキル等に限定されない。
【００８６】
また、上記では依頼完了後、被サポータ及びサポータが互いの評価を入力したが、いずれか一方（例えば被サポータ）が他方（サポータ）を評価するのみであってもよい。
【００８７】
また、上記ではルールベースでの対話エンジンを用いてユーザとの対話（チャット）を行ったが、ＡＩ（Artificial Intelligence）機能を有するチャットボットを用いて一連の対話を行ってもよい。すなわち、サーバ１は機械学習を行って対話用の学習済みモデルを構築し、学習済みモデルに端末２から送られる入力文、位置情報等を入力して応答文を生成し、端末２に出力してユーザへの案内、誘導を行う。これによりサーバ１は、例えばユーザを待合せ場所に誘導する場合に、ユーザを道案内する会話文をリアルタイムで配信する等できる。このように、サーバ１に実装される対話エンジンはルールベースに限定されず、機械学習を用いた学習済みモデルであってもよい。
【００８８】
以上より、本実施の形態１によれば、被サポータ及びサポータの位置情報に基づいてマッチングを行い、両者が対面できるように誘導を行うことで、ユーザ間の助け合いを支援することができる。
【００８９】
また、本実施の形態１によれば、マッチング条件に被サポータ及びサポータそれぞれの属性条件を加えることで、より適切なマッチングを行うことができる。
【００９０】
また、本実施の形態１によれば、被サポータの属性情報に応じて誘導情報の出力態様を変更することで、より適切な案内を行うことができる。
【００９１】
また、本実施の形態１によれば、支援依頼が完了しないまま所定時間が経過した場合に別のサポータを再検索することで、迅速かつ効率的な依頼解決を図ることができる。
【００９２】
また、本実施の形態１によれば、再検索時に検索範囲を拡大してサポータを検索することで、マッチングの不成立を防ぎ、依頼解決を図ることができる。
【００９３】
また、本実施の形態１によれば、サポータ（又は被サポータ）からの応援依頼に応じて応援者（第２のサポータ）を検索することで、効率的な依頼解決を図ることができる。
【００９４】
また、本実施の形態１によれば、マッチング時に複数のユーザ（サポータ）が被サポータの近くに位置する場合、各ユーザとの距離に応じて、例えば最も近いユーザをサポータとして検索する。これにより、適切なサポータとマッチングすることができる。
【００９５】
また、本実施の形態１によれば、被サポータ及びサポータの現在の距離を逐次判定し、判定した距離に応じて通話許可等を出力することで、両者が対面できるよう適切な誘導を行うことができる。
【００９６】
また、本実施の形態１によれば、ユーザの位置情報の取得元であるビーコン３に対応する待合せ場所へ各ユーザを誘導することで、より適切な誘導を行うことができる。
【００９７】
また、本実施の形態１によれば、両者のうち被サポータの位置情報を基準に待合せ場所を指定することで、被サポータ近くへサポータを誘導することができ、適切な待合せを行うことができる。
【００９８】
また、本実施の形態１によれば、依頼完了後に各ユーザが他方の評価を行うことで、適切なプロフィールの共有、あるいはマッチングを行うことができる。
【００９９】
（実施の形態２）
本実施の形態では、サポータ検索時に、支援依頼に対するサポータの適合度合いを示すスコアをサポータの属性情報に基づいて算出し、算出したスコアに応じてサポータに支援要求を送信する形態について説明する。
端末２から支援依頼を受け付けてサポータを検索する場合、サーバ１は、支援依頼の内容に応じて、サポータとなり得るユーザＤＢ１４１上の各ユーザのスコアを算出する。具体的には、サーバ１は各ユーザの属性情報を依頼内容と比較し、スコアを算出する。
【０１００】
例えばサーバ１は、位置情報等に応じてユーザＤＢ１４１からサポータ（ユーザ）を検索した後、検索された各サポータの属性情報を、被サポータから送られた支援依頼の内容、あるいは被サポータの属性情報と比較してスコアを算出する。例えば「３０代外国人女性の道案内」の支援依頼を受け付けた場合、サーバ１は、サポータが被サポータの母国語について所定水準以上の言語レベルを有する場合は１０点、サポータが２０代の場合は５点、３０代の場合は１０点、男性の場合は５点、女性の場合は１０点…というように、各属性を比較して配点を行う。なお、サーバ１は被サポータ及びサポータの属性情報のみを用いてスコアを算出してもよい。例えばサーバ１は、被サポータが３０代である場合に、サポータが２０代の場合は５点、３０代の場合は１０点、４０代の場合は５点…というように、あるいは被サポータが女性である場合に、サポータが女性の場合は１０点、男性の場合は５点というように配点を行ってもよい。なお、配点に関してはユーザが設定しても良い。
【０１０１】
また、サーバ１は、被サポータが予め設定してある希望条件に応じてスコアを算出してもよい。例えば「英会話可能」が希望条件として設定されている場合、サーバ１は、サポータの英語の言語レベルに基づいてスコアを算出する。
【０１０２】
上述の如く、サーバ１は各サポータの属性情報に基づいてスコアを算出する。サーバ１は、算出したスコアが所定条件を充足するか否かに応じて、支援要求を送信して依頼を行うサポータを選択する。例えばサーバ１は、スコアが所定の閾値以上であるサポータを選択する。また、例えばサーバ１は、ユーザＤＢ１４１から検索されたサポータのうち、スコアが上位のサポータを選択するようにしてもよい。
【０１０３】
また、上記の条件を充足するスコアのサポータがいない場合、サーバ１は、条件を変更してサポータを抽出可能とする。例えばサーバ１は、上記の閾値を引き下げる、基準とするスコアの順位を引き下げる等して選択範囲を広げる。これにより、マッチングの不成立を防止する。
【０１０４】
サーバ１は、選択したサポータの端末２に支援要求を送信し、承諾する旨の応答情報を受信した場合は端末２に誘導情報を配信して、被サポータ及びサポータをマッチングする。上述の如く、サポータの属性情報に基づきスコアを算出することで、支援依頼に対するサポータの適合度合いを評価して適切なマッチングを行うことができる。
【０１０５】
図１５は、サポータ検索のサブルーチンの処理手順を示すフローチャートである。図１５に基づき、本実施の形態に係るステップＳ１３のサブルーチンの処理内容について説明する。
ステップＳ５８でＹＥＳの場合、サーバ１の制御部１１は以下の処理を実行する。制御部１１は、被サポータ端末２Ａから取得した支援依頼に応じて、サポータの属性情報に基づき、支援依頼に対するサポータの適合度合いを示すスコアを算出する（ステップＳ２０１）。例えば制御部１１は、検索対象であるサポータの属性情報と、被サポータから送られた依頼内容、サポータの属性情報、被サポータが任意に設定した希望条件などとを比較してスコアを算出する。
【０１０６】
制御部１１は、算出したスコアに応じて、支援要求を送信し、誘導を行うサポータを選択する（ステップＳ２０２）。例えば制御部１１は、スコアが所定の閾値以上であるか、検索されたサポータのうちスコアが上位のサポータであるか等、サポータのスコアが所定条件を充足するか否かに応じて選択する。条件を充足するスコアのサポータが検索されなかった場合、制御部１１は、閾値を引き下げる、基準とするサポータの順位を引き下げる等、条件を変更して再度サポータを選択する。制御部１１はサブルーチンをリターンする。
【０１０７】
以上より、本実施の形態２によれば、サポータの属性情報を元にスコアを算出することで、支援を依頼するサポータをより適切に選択することができる。
【０１０８】
また、本実施の形態２によれば、基準とする所定の条件を充足するスコアのサポータがいなかった場合、スコアの条件を変更することで、マッチングの不成立を防ぐことができる。
【０１０９】
（実施の形態３）
本実施の形態では、ユーザＤＢ１４１に蓄積される各ユーザの利用履歴（履歴情報）を元に、支援依頼が発生する場所及び時間を推定する形態について説明する。
実施の形態１に係るサポータマッチングシステムにより、被サポータが本システムを利用して支援依頼を行った場所（位置情報）、時間等の利用履歴（履歴情報）がユーザＤＢ１４１に蓄積される。本実施の形態に係るサーバ１は、ユーザＤＢ１４１に蓄積された利用履歴を用いて、困りごとが発生する場所及び時間帯（時間）を推定する。
【０１１０】
すなわちサーバ１は、ユーザＤＢ１４１に記憶されている各ユーザの利用履歴を読み出し、支援依頼が頻発する場所及び時間帯を推定する。なお、サーバ１は、支援依頼が発生する時間を時間帯ではなく、時刻で推定してもよいことは勿論である。推定手法は、例えばクラスタ分析、回帰分析、主成分分析などが想定され得るが、特に限定されない。サーバ１は、過去に実施された支援依頼について、支援依頼の送信元である被サポータ端末２Ａの位置情報を支援依頼の発生場所、支援依頼の送信時刻を支援依頼の発生時間としてユーザＤＢ１４１に記憶しておき、各情報から支援依頼の発生場所及び時間帯を推定する。
【０１１１】
なお、サーバ１は場所及び時間帯だけでなく、支援依頼の内容、依頼した被サポータの属性情報、依頼されたサポータの属性情報等も併せて参照し、どのような支援依頼が頻発するか、どのような属性の被サポータが依頼者に多いか、どのような属性のユーザがサポータとして適切かも含めて推定してもよい。すなわち、サーバ１は少なくとも支援依頼の発生場所及び時間帯を推定可能であればよく、支援依頼についてその他の情報も推定してもよい。
【０１１２】
例えばサーバ１は、推定結果をサポータ登録されている各ユーザの端末２に定期的に配信し、支援を要求する。また、例えばサーバ１は、各ユーザの端末２の現在の位置情報を逐次取得し、ユーザの現在位置及び現在時刻と、推定した支援依頼の発生場所及び時間帯とが重複した場合に、周辺で困りごとが頻発する旨を通知するようにしてもよい。以上より、サポータによる支援の効率化を図ることができる。
【０１１３】
図１６は、実施の形態３に係るサーバ１が実行する処理手順の一例を示すフローチャートである。
サーバ１の制御部１１は、ユーザＤＢ１４１から、過去に発生した支援依頼の場所、及び発声した時間を含む利用履歴（履歴情報）を読み出す（ステップＳ３０１）。利用履歴は、支援依頼の発生場所、発生する時間のほか、支援依頼の内容、依頼者である被サポータの属性情報、依頼を受けたサポータの属性情報等を含み得る。制御部１１は、読み出した利用履歴に基づき、支援依頼が発生する場所及び時間を推定する（ステップＳ３０２）。制御部１１は、推定結果を端末２に出力（配信）し（ステップＳ３０３）、一連の処理を終了する。
【０１１４】
（実施の形態４）
図１７は、上述した形態のサーバ１の動作を示す機能ブロック図である。制御部１１がプログラムＰ１を実行することにより、サーバ１は以下のように動作する。
受付部１７１は、被サポータから位置情報を含む支援依頼を受け付ける。取得部１７２は、複数のサポータ夫々の位置情報を取得する。検索部１７３は、前記被サポータ及びサポータの位置情報に基づき、前記被サポータに対する支援を依頼する前記サポータを検索する。出力部１７４は、検索した前記サポータ又は被サポータの携帯端末に、相手方に関する情報を用いて、前記サポータ又は被サポータを相手方へ誘導する誘導情報を出力する。
【０１１５】
本実施の形態４は以上の如きであり、その他は実施の形態１〜３と同様であるので、対応する部分には同一の符号を付してその詳細な説明を省略する。
【０１１６】
今回開示された実施の形態はすべての点で例示であって、制限的なものではないと考えられるべきである。本発明の範囲は、上記した意味ではなく、特許請求の範囲によって示され、特許請求の範囲と均等の意味及び範囲内でのすべての変更が含まれることが意図される。
【符号の説明】
【０１１７】
１  サーバ（情報処理装置）
１１  制御部
１２  主記憶部
１３  通信部
１４  補助記憶部
Ｐ１  プログラム
１４１  ユーザＤＢ
１４２  エリアＤＢ
２  端末
２１  制御部
２２  主記憶部
２３  通信部
２４  表示部
２５  入力部
２６  補助記憶部
Ｐ２  プログラム
【図１】
2020021375.tif 000003
【図２】
2020021375.tif 000004
【図３】
2020021375.tif 000005
【図４】
2020021375.tif 000006
【図５】
2020021375.tif 000007
【図６】
2020021375.tif 000008
【図７】
2020021375.tif 000009
【図８】
2020021375.tif 000010
【図９】
2020021375.tif 000011
【図１０】
2020021375.tif 000012
【図１１】
2020021375.tif 000013
【図１２】
2020021375.tif 000014
【図１３】
2020021375.tif 000015
【図１４】
2020021375.tif 000016
【図１５】
2020021375.tif 000017
【図１６】
2020021375.tif 000018
【図１７】
2020021375.tif 000019