技術 支援システム、支援装置、マッチング方法、及びプログラム

0001

本発明は、利用者に前記利用者を支援する支援者をマッチングするための支援システム、支援装置、マッチング方法、及びプログラムに関する。

0002

近年、利用登録された登録者間における互助活動をネットワークを通じて支援する支援サービスが運用されており、例えば、自動車の運転者にその自動車に相乗りする人を仲介したり、或いはその自動車に相乗りする人同士を引き合わせるライドシェアリングが知られている。

0003

従来、上述のライドシェアリングにおいては、当該サービスの利用を希望する利用者間に一定の信頼が存在している場合は、利用者は安心して当該サービスを受けることができる。しかしながら、利用者間に信頼が存在していない場合は、利用者は安心して当該サービスを受けることができないという問題がある。このような問題に関して、予め登録された利用者（ユーザ）から事前に取得したアドレス情報に基づいて当該利用者における他の利用者（他のユーザ）に対する信頼度を算出し、マッチング要求があった場合に、要求した利用者に対応する前記信頼度に基づいて他の利用者から選ばれたマッチンク候補を提示する信頼度算出装置が開示されている（特許文献１参照）。

0004

特開２０１４−２１５６７０号公報

0005

前掲した従来の信頼度算出装置は、利用者が使用する利用者端末に登録されたアドレス情報（電話番号やメールアドレスなど）を用いてユーザマップを生成し、マップ上の利用者間のパスに基づいて利用者間の信頼度を算出する。しかしながら、利用者端末に登録されているアドレス情報が、必ずしも信頼度の高い他の利用者のアドレス情報であるとは限らないため、実際の信頼関係が極めて低い利用者同士であっても、数値の高い前記信頼度が算出される場合があり、実際の信頼関係と大きく乖離した結果が算出されるという問題がある。また、利用者は、利用者端末に登録されたアドレス情報を変更することができるため、利用者が意図的にアドレス情報を変更することによって、前記信頼度の算出結果をコントロールすることができ、算出された信頼度に対する信頼性を担保することができない。

0006

ところで、地方都市においては、過疎化・高齢化が進み人口の減少に歯止めが利かないところもあり、人口減少に伴う経済・産業活動の縮小によって地方財政がますます厳しい状況になりつつある。従来、市町村などの地方自治体は、住民が日常生活を送るために必要な各種サービスを提供しており、例えば、鉄道や路線バスなどの交通サービス、病院などの医療サービス、介護サービス、障害福祉サービス、託児所などの託児サービス、学校教育、行政サービス、娯楽サービスなどを提供している。この種のサービスは、一定の人口規模のうえに成り立つものであるが、人口が減少して一定の人口規模を満たさなくなった場合は、地方自治体は、上述したサービスや事業を行うことが困難になる。地方自治体が提供できなくなったサービス、特に生活に密接に関連する生活関連サービスについては、地方自治体の助力を受けずに地域住民が互いに助け合い、住民それぞれが抱える生活課題を互いに解決し合う互助活動によって補う必要がある。前記生活関連サービスを住民の互助活動によって実現するにあたり、上述の信頼度算出装置を用いることによって、当該サービスの支援を要求したユーザ端末にマッチング候補を提示することが可能である。しかしながら、地方自治体が管轄する地域において、前記生活関連サービスを他の住民（支援者）から受ける被支援者にとっては、前記生活関連サービスの性質上、支援者が信頼のおける者であるか否かが極めて重要であり、前記信頼度算出装置によって算出された信頼度に対する信頼性を担保できなければ、被支援者は安心して支援者を選んで依頼することはできない。

0007

信頼度に関する上述した信頼性の問題は、上述したライドシェアリングに限られず、利用者と、当該利用者を支援する支援者とをマッチングするサービス全般に生じ得る問題である。

0008

本発明の目的は、利用者が信頼できる支援者候補を確実に選定して利用者に提示することができ、利用者が安心して当該支援者から支援を受けることを可能にする支援システム、支援装置、マッチング方法、及びプログラムを提供することにある。

0009

(1) 本発明の一の局面に係る支援システムは、予め登録された複数の地域コミュニティのいずれかに属する利用者に前記利用者を支援する支援者をマッチングして前記利用者と前記支援者との互助活動を支援するための支援システムである。前記支援システムにおいて、前記支援者は、前記複数の地域コミュニティのうち少なくとも一つの地域コミュニティに属しており、前記支援者が所属する地域コミュニティを管理する管理者によって予め承認された者である。
前記支援システムは、前記管理者により承認された複数の承認済み支援者それぞれに関する支援者情報を含む支援登録データを格納する支援登録データ格納部と、前記利用者からの支援依頼要求に適合する支援者候補を前記支援登録データに含まれる前記複数の承認済み支援者から選定する候補選定処理部と、を備える。

0010

このように構成されているため、管理者によって信頼の担保された承認済み支援者から支援者候補が選定されて、その支援者候補が利用者に提示される。これにより、支援依頼を要求した利用者は、提示された支援者候補に対して信頼することができるので、利用者は、安心して前記支援者候補から支援者を選ぶことができ、安心して支援者から支援を受けることができる。

0011

(2) 前記支援登録データは、前記承認済み支援者ごとに前記管理者によって定められた個別信頼度に関する情報を更に含む。この場合、前記候補選定処理部は、前記支援登録データに含まれる前記複数の承認済み支援者から前記個別信頼度が定められた前記支援者候補を優先して選定する。
これにより、前記個別信頼度が定められた承認済み支援者が優先して確実に選定されて、その支援者候補が利用者に提示される。これにより、利用者は、より安心して、支援者候補から支援者を選ぶことができ、より安心して支援者から支援を受けることができる。

0012

(3) また、前記候補選定処理部は、前記支援登録データに含まれる前記複数の承認済み支援者から前記個別信頼度の高い前記支援者候補を優先して選定してもよい。
この場合も、利用者が信頼できる支援者候補が確実に選定されて、その支援者候補が利用者に提示されるため、利用者は、より安心して支援者候補から支援者を選ぶことができ、より安心して支援者から支援を受けることができる。

0013

(4) また、前記支援依頼要求に支援を依頼する依頼役務が含まれている場合は、前記候補選定処理部は、前記個別信頼度が前記支援依頼要求に含まれる前記依頼役務に対応して定められた役務信頼度以上である前記支援者候補を選定してもよい。
この場合は、前記依頼役務に応じた個別信頼度を有する支援者候補が選定されて、利用者に提示される。そのため、利用者は、自身の希望に適合する信頼度を有する支援者を選ぶことができる。

0014

(5) また、前記支援依頼要求に前記個別信頼度に関して前記利用者が希望する希望信頼度が含まれている場合は、前記候補選定処理部は、前記個別信頼度が前記支援依頼要求に含まれる前記希望信頼度以上である前記支援者候補を選定してもよい。
この場合は、利用者の希望に適合する個別信頼度を有する支援者候補が選定されて、利用者に提示される。そのため、利用者は、自身の希望に適合する信頼度を有する支援者を選ぶことができる。

0015

(6) 前記候補選定処理部は、前記複数の地域コミュニティ間の関係性の有無及び前記関係性の程度を示す関係情報に基づいて、前記利用者が属する地域コミュニティと前記関係性を有する他の地域コミュニティ、或いは前記関係性の強い他の地域コミュニティに所属する前記承認済み支援者を優先して、前記支援者候補を選定する。
これにより、利用者が所属する地域コミュニティと関係性のある地域コミュニティ、或いは、前記関係性の強い地域コミュニティに属する支援者候補が提示されるため、利用者は、提示された支援者候補に対してより強く信頼することができる。そのため、利用者は、より安心して支援者候補から支援者を選ぶことができ、より安心して支援者から支援を受けることができる。

0016

(7) 本発明の支援システムは、前記候補選定処理部によって選定された前記支援者候補を前記利用者が使用する利用者端末に送信する送信処理部を更に備える。

0017

これにより、支援依頼を要求した利用者は、要求した依頼内容に適合し、且つ、十分に信頼することができる支援者の候補を取得することができる。その結果、利用者は、例えば、支援システムにおいて提供されるマッチングサービスを安心して利用することができ、また、利用者は、安心して当該支援者から支援を受けることができる。

0018

(8) 前記地域コミュニティは、所定の地域に属し当該地域において所定の活動を行うものである。

0019

前記地域コミュニティは、例えば、市町村などの地区単位で組織された自治会や町内会、当該地域に所在する学校の関係者（主に生徒の保護者と教職者）によって組織された教育関係団体（例えばＰＴＡ：Ｐａｒｅｎｔ−Ｔｅａｃｈｅｒ Ａｓｓｏｃｉａｔｉｏｎ）、当該地域に所在する商店の運営者の集合体である商店街組織（例えば、商店街振興組合）、共通の目的のために当該地域の住民によって構成されたスポーツクラブや自主防災組織（例えば、消防団）、子ども会、子育てサークル、老人クラブ、福祉ボランティア、ボーイスカウト、ガールスカウト、などが挙げられる。また、前記管理者は、これらの各コミュニティの代表者（リーダ）、或いはそれに準ずるものであり、例えば、前記自治会の会長、前記町内会の会長、ＰＴＡ会長、前記商店街振興組合の組合長、前記スポーツクラブの指導者（監督など）、前記消防団の団長、前記子ども会の会長、などが挙げられる。また、前記利用者は、前記所定の地域に居住する住民であって、且つ、前記地域コミュニティに所属する構成員がなり得る。また、前記支援者は、前記所定の地域に居住する住民であって、且つ、前記地域コミュニティに所属する構成員のうち前記管理者によって予め承認された者である。

0020

(9) 前記支援登録データは、前記承認済み支援者の個人情報、所属する地域コミュニティ、支援可能な役務、前記役務の経験値、前記役務に関連する技能又は資格の有無、支援可能な日時、のうちの少なくとも一つ以上を含む。

0021

(10) 本発明の他の局面に係る支援装置は、予め登録された複数の地域コミュニティのいずれかに属する利用者に前記利用者を支援する支援者をマッチングするための支援装置である。前記支援者は、前記複数の地域コミュニティのうち少なくとも一つの地域コミュニティに属しており、前記支援者が所属する地域コミュニティを管理する管理者によって所定の信頼度を有する者として予め承認されている。
前記支援装置は、前記管理者により承認された複数の承認済み支援者それぞれに関する支援者情報を含む支援登録データを参照して、前記利用者からの支援依頼要求に適合する支援者候補を前記支援登録データに含まれる前記複数の承認済み支援者から選定する候補選定処理部を備える。

0022

(11) 本発明の他の局面に係るマッチング方法は、予め登録された複数の地域コミュニティのいずれかに属する利用者に前記利用者を支援する支援者をマッチングするためのマッチング方法である。前記支援者は、前記複数の地域コミュニティのうち少なくとも一つの地域コミュニティに属しており、前記支援者が所属する地域コミュニティを管理する管理者によって所定の信頼度を有する者として予め承認されている。
前記マッチング方法は、前記管理者により承認された複数の承認済み支援者それぞれに関する支援者情報を含む支援登録データを参照して、前記利用者からの支援依頼要求に適合する支援者候補を前記支援登録データに含まれる前記複数の承認済み支援者から選定する候補選定ステップ、を有する。

0023

(12) なお、本発明は、予め登録された複数の地域コミュニティにおいて、コンピュータによって、前記地域コミュニティに属する利用者に前記利用者を支援する支援者をマッチングするためのプログラムであって、前記マッチング方法のステップを前記コンピュータに実行させるためのプログラム、又は、このようなプログラムを非一時的に記録したコンピュータ読み取り可能な記録媒体として捉えることもできる。

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

２ ：情報端末
１０ ：マッチング支援装置
１１ ：制御部
１２ ：記憶部
１３ ：通信部
２０ ：管理端末
１１１ ：候補選定処理部
１１３ ：送信処理部
１２１ ：依頼情報格納部
１２２ ：支援情報格納部
１２３ ：コミュニティ情報格納部
１２４ ：利用者情報格納部
１２５ ：マッチング実績格納部
Ａ，Ｂ，Ｃ：コミュニティ