(57)【要約】【課題】安心感を担保しながら、労力を提供できるユーザと、労力の提供を受けることを要望するユーザとを結び付けるシステムを提供する。【解決手段】システムは、限られたコミュニティ内にて、有閑ユーザによる労力を提供できる旨の有閑情報を取得し、当該有閑情報を記憶する有閑情報記憶手段と、前記コミュニティ内にて、要望ユーザが欲する労力に関する要望情報を取得する要望情報取得手段と、前記要望情報に基づき、前記有閑情報記憶手段に記憶されている有閑情報の中から条件に合う有閑情報を検索し、検索結果を前記要望ユーザに提供する提供手段と、を有する。【選択図】図２
2020004110.tif 000002
【特許請求の範囲】
【請求項１】
限られたコミュニティ内にて、有閑ユーザによる労力を提供できる旨の有閑情報を取得し、当該有閑情報を記憶する有閑情報記憶手段と、
前記コミュニティ内にて、要望ユーザが欲する労力に関する要望情報を取得する要望情報取得手段と、
前記要望情報に基づき、前記有閑情報記憶手段に記憶されている有閑情報の中から条件に合う有閑情報を検索し、検索結果を前記要望ユーザに提供する提供手段と、
を有するシステム。
【請求項２】
前記提供手段は、前記要望ユーザが所属するコミュニティを識別する識別情報に基づいて、当該識別情報に合うコミュニティの有閑情報を当該要望ユーザに提供する請求項１に記載のシステム。
【請求項３】
前記要望情報は、前記要望ユーザが前記有閑ユーザに付与するポイントに関するポイント情報を含む請求項１または２に記載のシステム。
【請求項４】
前記条件は、前記有閑ユーザに関するユーザ条件を含む請求項１または２に記載のシステム。
【請求項５】
前記ユーザ条件は、前記有閑ユーザの属性に関するユーザ属性情報を含む請求項４に記載のシステム。
【請求項６】
前記ユーザ条件は、前記有閑ユーザが提供可能な労力の内容に関する労力内容情報を含む請求項４に記載のシステム。
【請求項７】
前記有閑ユーザが労力の提供を行う場所の設定を行う設定手段を備える請求項１または２に記載のシステム。
【請求項８】
前記設定手段は、前記要望ユーザの住戸の解錠に関する解錠設定を行う請求項７に記載のシステム。
【請求項９】
前記設定手段は、前記コミュニティ内の共用施設の予約に関する予約設定を行う請求項７に記載のシステム。
【請求項１０】
前記提供手段は、前記要望情報に対する前記有閑情報の適合度合いに基づいて特定した有閑情報を前記要望ユーザに提供する請求項１または２に記載のシステム。
【請求項１１】
限られたコミュニティ内にて、要望ユーザが欲する労力に関する要望情報を取得し、当該要望情報を記憶する要望情報記憶手段と、
前記コミュニティ内にて、有閑ユーザによる労力を提供できる旨の有閑情報を取得する有閑情報取得手段と、
前記有閑情報に基づき、前記要望情報記憶手段に記憶されている要望情報の中から条件に合う要望情報を検索し、検索結果を前記有閑ユーザに提供する提供手段と、
を有するシステム。
【請求項１２】
前記提供手段は、前記有閑ユーザによる住戸の鍵の操作に伴って、前記検索結果を当該有閑ユーザに提供する請求項１１に記載のシステム。
【請求項１３】
前記提供手段は、前記有閑ユーザに対して前記要望ユーザに関する要望ユーザ情報を提供する請求項１１に記載のシステム。
【請求項１４】
ユーザが所持するユーザ端末装置として機能するコンピュータに、
限られたコミュニティ内における要望ユーザが欲する労力に関する要望情報の入力を受け付ける機能と、
前記コミュニティ内における有閑ユーザによる労力を提供できる旨の有閑情報の中から前記要望情報に基づいて特定された有閑情報を前記ユーザ端末装置の画面に表示させる機能と、
を実現させるプログラム。
【請求項１５】
ユーザが所持するユーザ端末装置として機能するコンピュータに、
限られたコミュニティ内における有閑ユーザによる労力を提供できる旨の有閑情報の入力を受け付ける機能と、
前記コミュニティ内における要望ユーザが欲する労力に関する要望情報の中から前記有閑情報に基づいて特定された要望情報を前記ユーザ端末装置の画面に表示させる機能と、
を実現させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、システムおよびプログラムに関する。
【背景技術】
【０００２】
例えば特許文献１には、情報提供用データベース部には情報提供者に係るベーシックな基本情報を格納すると共に、相手方に求める可変的な条件情報を格納し、検索情報一時保管領域には情報検索者に係るベーシックな基本情報を格納すると共に、相手方に求める可変的な条件情報を格納し、データ照合部を介して式が成立するクロスマッチング検索を行い、情報提供者と情報検索者とが互いの検索条件を満たす検索結果をリストアップする技術が開示されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００１−２７３３３０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、時間に余裕があって労力を提供できるユーザと、労力の提供を受けることを要望するユーザとが存在する場合に、両ユーザを結び付けることができれば相互のニーズを満たすことができる。一方で、不特定多数のユーザ同士を結び付けてしまうと、ユーザが不安に感じる可能性が高い。
本発明は、安心感を担保しながら、労力を提供できるユーザと、労力の提供を受けることを要望するユーザとを結び付けるシステムを提供することを目的とする。
【課題を解決するための手段】
【０００５】
かかる目的のもと、本発明は、限られたコミュニティ内にて、有閑ユーザによる労力を提供できる旨の有閑情報を取得し、当該有閑情報を記憶する有閑情報記憶手段と、前記コミュニティ内にて、要望ユーザが欲する労力に関する要望情報を取得する要望情報取得手段と、前記要望情報に基づき、前記有閑情報記憶手段に記憶されている有閑情報の中から条件に合う有閑情報を検索し、検索結果を前記要望ユーザに提供する提供手段と、を有するシステムである。
ここで、前記提供手段は、前記要望ユーザが所属するコミュニティを識別する識別情報に基づいて、当該識別情報に合うコミュニティの有閑情報を当該要望ユーザに提供することを特徴とすることができる。
さらに、前記要望情報は、前記要望ユーザが前記有閑ユーザに付与するポイントに関するポイント情報を含むことを特徴とすることができる。
また、前記条件は、前記有閑ユーザに関するユーザ条件を含むことを特徴とすることができる。
そして、前記ユーザ条件は、前記有閑ユーザの属性に関するユーザ属性情報を含むことを特徴とすることができる。
さらに、前記ユーザ条件は、前記有閑ユーザが提供可能な労力の内容に関する労力内容情報を含むことを特徴とすることができる。
また、前記有閑ユーザが労力の提供を行う場所の設定を行う設定手段を備えることを特徴とすることができる。
そして、前記設定手段は、前記要望ユーザの住戸の解錠に関する解錠設定を行うことを特徴とすることができる。
さらに、前記設定手段は、前記コミュニティ内の共用施設の予約に関する予約設定を行うことを特徴とすることができる。
また、前記提供手段は、前記要望情報に対する前記有閑情報の適合度合いに基づいて特定した有閑情報を前記要望ユーザに提供することを特徴とすることができる。
また、かかる目的のもと、本発明は、限られたコミュニティ内にて、要望ユーザが欲する労力に関する要望情報を取得し、当該要望情報を記憶する要望情報記憶手段と、前記コミュニティ内にて、有閑ユーザによる労力を提供できる旨の有閑情報を取得する有閑情報取得手段と、前記有閑情報に基づき、前記要望情報記憶手段に記憶されている要望情報の中から条件に合う要望情報を検索し、検索結果を前記有閑ユーザに提供する提供手段と、を有するシステムである。
ここで、前記提供手段は、前記有閑ユーザによる住戸の鍵の操作に伴って、前記検索結果を当該有閑ユーザに提供することを特徴とすることができる。
そして、前記提供手段は、前記有閑ユーザに対して前記要望ユーザに関する要望ユーザ情報を提供することを特徴とすることができる。
また、かかる目的のもと、本発明は、ユーザが所持するユーザ端末装置として機能するコンピュータに、限られたコミュニティ内における要望ユーザが欲する労力に関する要望情報の入力を受け付ける機能と、前記コミュニティ内における有閑ユーザによる労力を提供できる旨の有閑情報の中から前記要望情報に基づいて特定された有閑情報を前記ユーザ端末装置の画面に表示させる機能と、を実現させるプログラムである。
また、かかる目的のもと、本発明は、ユーザが所持するユーザ端末装置として機能するコンピュータに、限られたコミュニティ内における有閑ユーザによる労力を提供できる旨の有閑情報の入力を受け付ける機能と、前記コミュニティ内における要望ユーザが欲する労力に関する要望情報の中から前記有閑情報に基づいて特定された要望情報を前記ユーザ端末装置の画面に表示させる機能と、を実現させるプログラムである。
【発明の効果】
【０００６】
本発明によれば、安心感を担保しながら、労力を提供できるユーザと、労力の提供を受けることを要望するユーザとを結び付けるシステムを提供することができる。
【図面の簡単な説明】
【０００７】
【図１】本実施形態のマッチングシステムの一例の全体図である。
【図２】本実施形態のサーバ装置の機能構成を示す図である。
【図３】本実施形態のユーザ管理データの一例である。
【図４】本実施形態の有閑管理データの一例である。
【図５】本実施形態の要望管理データの一例である。
【図６】要望ユーザによる検索態様におけるマッチングシステムの動作フロー図である。
【図７】（Ａ）および（Ｂ）は、要望ユーザによる検索態様における画像の表示例である。
【図８】（Ａ）および（Ｂ）は、要望ユーザによる検索態様における画像の表示例である。
【図９】（Ａ）および（Ｂ）は、要望ユーザによる検索態様における画像の表示例である。
【図１０】有閑ユーザによる検索態様におけるマッチングシステムの動作フロー図である。
【図１１】（Ａ）および（Ｂ）は、有閑ユーザによる検索態様における画像の表示例である。
【図１２】有閑ユーザによる検索態様における画像の表示例である。
【図１３】要望ユーザによる掲示態様における画像の表示例である。
【図１４】有閑ユーザによる掲示態様における画像の表示例である。
【図１５】本実施形態における提供場所設定画像の一例の図である。
【発明を実施するための形態】
【０００８】
以下、添付図面を参照して、本発明を実施するための形態について説明する。
図１は、本実施形態のマッチングシステム１の一例の全体図である。
【０００９】
［マッチングシステム１］
図１に示すように、本実施形態のマッチングシステム１は、複数の機器と通信接続するサーバ装置２０と、ユーザが操作可能な端末装置１０と、を備えている。なお、本実施形態のマッチングシステム１では、複数の端末装置１０の間で情報通信が行われる。図１では、複数の端末装置１０として３台の端末装置１０を例示しているが、４台以上の端末装置１０が接続していても良い。
そして、サーバ装置２０および複数の端末装置１０は、ネットワークを介して相互に情報通信が可能になっている。
【００１０】
なお、ネットワークは、各装置の間のデータ通信に用いられる通信ネットワークであれば特に限定されず、例えばＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、インターネット等として良い。データ通信に用いられる通信回線は、有線か無線かを問わず、これらを併用しても良い。また、各装置は、ゲートウェイ装置やルータ等の中継装置を用い、複数のネットワークや通信回線を介して接続されても良い。
【００１１】
また、図１に示す例では、一つのサーバ装置２０が示されているが、サーバ装置２０は、単体のサーバマシンに限定されない。サーバ装置２０は、ネットワーク上に設けられた複数のサーバマシンに分散させてサーバ装置２０の機能を実現しても良い（いわゆるクラウド環境等）。
【００１２】
そして、本実施形態のマッチングシステム１では、サーバ装置２０は、例えば同一マンションなどの限られたコミュニティ内にて、時間に余裕のあるユーザ（以下、有閑ユーザ）による労力を提供できる旨の有閑情報を取得し、その有閑情報を記憶する。また、サーバ装置２０は、そのコミュニティ内にて、労力の提供を受けることを要望するユーザ（以下、要望ユーザ）が欲する労力に関する要望情報を取得し、取得した要望情報に基づいて、サーバ装置２０に記憶されている有閑情報の中から条件に合う有閑情報を検索し、端末装置１０を介して検索結果を要望ユーザに提供する。
以下、本実施形態のマッチングシステム１について詳細に説明する。
【００１３】
〔端末装置１０〕
端末装置１０には、スマートフォンなどの携帯電話、タブレット型端末などの携帯端末機器など、ユーザが持ち歩くことが可能な装置を用いることができる。本実施形態の端末装置１０は、タッチパネルが設けられており、画面をユーザがタッチすることで画面に表示される画像に対する操作および指示を行う。
なお、端末装置１０は、デスクトップＰＣなどの設置型の固定端末機器であっても良い。
【００１４】
〔サーバ装置２０〕
図２は、本実施形態のサーバ装置２０の機能構成を示す図である。
図２に示すように、サーバ装置２０は、本システムを利用するユーザに関する情報（以下、ユーザ情報）を管理するユーザ情報管理部２１と、有閑ユーザに関する有閑情報を管理する有閑情報管理部２２（有閑情報記憶手段の一例）とを備える。また、サーバ装置２０は、要望ユーザに関する要望情報を管理する要望情報管理部２３（要望情報記憶手段の一例）と、有閑ユーザと要望ユーザとを結び付けるマッチング部２４（要望情報取得手段、有閑情報取得手段、提供手段の一例）とを備える。
【００１５】
（ユーザ情報管理部２１）
図３は、本実施形態のユーザ管理データ１００の一例である。
【００１６】
ユーザ情報管理部２１は、ユーザからユーザ情報の登録を受け付ける。なお、ユーザ情報の受け付けは、端末装置１０を介してユーザによってユーザ情報が入力されることで行われる。そして、ユーザ情報管理部２１は、ユーザ情報をユーザごとにまとめてユーザ管理データ１００として記憶する。
そして、ユーザ情報管理部２１は、有閑情報管理部２２、要望情報管理部２３およびマッチング部２４からの要求に応じてユーザ情報を送信する。
【００１７】
そして、図３に示すように、ユーザ管理データ１００は、コミュニティを一意に特定可能な「コミュニティ識別番号」と、ユーザを一意に特定可能な「ユーザＩＤ」と、コミュニティ内におけるユーザの住戸を特定可能な「住戸番号」との項目を備える。さらに、ユーザ管理データ１００は、ユーザの氏名である「氏名」と、家族内におけるユーザの位置づけを示す「家族属性」と、ユーザの性別を示す「性別」との項目を備える。また、ユーザ管理データ１００は、ユーザの世代を示す「世代」と、コミュニティにおけるユーザの居住年数を示す「居住年数」と、ユーザの職業等の情報を示す「職業」との項目を備える。さらに、ユーザ管理データ１００は、他の項目に分類されないユーザが任意な内容を入力する「特記事項」と、本システムを利用した手伝いの経験レベルを示す「経験値」と、ユーザが保有するポイントを示す「保持ポイント」の項目を備えている。
【００１８】
コミュニティ識別番号は、コミュニティ単位ごとにそれぞれ個別に設定される符号（コード）情報である。本実施形態において、コミュニティとは、例えば、１つのマンションや、町内会や自治会など市町村内における一定の地域の住民で構成された組織など、顔見知りのユーザ同士で構成される地域共同体を例示できる。
【００１９】
ユーザＩＤは、ユーザ１人１人を一意に特定可能な情報である。例えば、マンションの同じ部屋（区分）に複数人が居住している場合であっても、ユーザＩＤは、人ごとに設定される。
【００２０】
家族属性は、ユーザの家族の中での呼称を示すものであり、父、母、祖父、祖母などの具体的な呼称が登録される。また、家族属性は、独身の場合には、独身と登録される。
【００２１】
職業は、ユーザが従事する職業の具体的な名称が登録される。なお、本実施形態の職業には、学生や主婦なども含まれる。また、職業は、既に退職しているユーザについては退職と登録される。
【００２２】
特記事項は、ユーザが提供可能な労力の内容に関する情報である。本実施形態において、特記事項は、ユーザが任意に記載できる項目となっている。特記事項としては、例えば、子育て経験の有無、介護経験の有無、体力に関する情報、特技や趣味に関する情報、資格に関する情報などが含まれる。
【００２３】
なお、特記事項には、ユーザが提供できない労力の内容が登録されていても良い。例えば、特記事項として、高所作業は苦手である旨や細かい作業が苦手であるなど、ユーザが不得意であったり、行いたくなかったりする内容を登録しても良い。このようなユーザが提供できない労力の内容に関する特記事項は、後述するように、有閑ユーザ等の絞込を行う際に、検索対象から外す際の要素に用いることができる。
【００２４】
経験値は、本システムを利用してユーザが有閑ユーザとして労力を提供したことに関する経験の度合いを示すものである。経験値は、有閑ユーザとして労力の提供回数が多いほど、値が高くなるようになっている。
【００２５】
保持ポイントは、ユーザが保持しているポイント（特典）を示している。本実施形態において、ポイントは、有閑ユーザが労力を提供した見返りとして、要望ユーザから提供されるものである。例えば、有閑ユーザとして獲得したポイントを、逆に、要望ユーザの立場で利用することができる。さらに、ポイントは、本システム内に限定されるものではなく、本システム外において一般に流通しているポイントを用いることもできる。
【００２６】
そして、本実施形態において、家族属性、性別、世代、居住年数、職業および経験値の情報は、ユーザの属性を示す情報であるユーザ属性である。また、職業および特記事項の情報は、ユーザが提供可能な労力の内容を示す情報である提供労力内容である。
【００２７】
（有閑情報管理部２２）
図４は、本実施形態の有閑管理データ２００の一例である。
【００２８】
有閑情報管理部２２は、コミュニティ内において有閑ユーザによる労力を提供できる旨の有閑情報を取得し、その有閑情報を記憶する。本実施形態において、有閑情報は、有閑ユーザが労力を提供可能な時間である提供可能時間によって特定される。提供可能時間は、有閑ユーザにとって空いた時間であって、コミュニティ内の他のユーザ（要望ユーザ）に対して労力を提供しても良いと考える時間である。
なお、有閑情報の受け付けは、端末装置１０を介して有閑ユーザによって入力されることで行われる。そして、有閑情報管理部２２は、有閑情報をユーザごとにまとめた有閑管理データ２００として管理する。
そして、有閑情報管理部２２は、要求に応じて有閑情報をマッチング部２４に送信する。
【００２９】
そして、図４に示すように、有閑管理データ２００は、ユーザＩＤと、ユーザごとの有閑情報としての提供可能時間を示す「時間情報」とを備えている。
図４に示す時間情報は、あるコミュニティのある１日の情報を示している。時間情報は、この例では、１時間の単位で、有閑ユーザとして労力の提供が可能な時間帯を明示する。有閑管理データ２００では、有閑ユーザが労力の提供可能な時間帯に「〇」が設定される。一方で、有閑管理データ２００では、ユーザが労力を提供できない時間帯や、労力を提供する意思がないユーザについては「×」が表示される。
【００３０】
（要望情報管理部２３）
図５は、本実施形態の要望管理データ３００の一例である。
【００３１】
要望情報管理部２３は、コミュニティ内において要望ユーザが欲する労力に関する要望情報を取得し、その要望情報を記憶する。本実施形態の要望情報には、労力の提供を受けたい要望ユーザが要望する時間である要望時間と、要望ユーザが要望する有閑ユーザのユーザ属性である要望ユーザ属性と、要望ユーザが要望する労力の内容である要望労力内容とが含まれる。
なお、要望情報の受け付けは、端末装置１０を介して要望ユーザによって入力されることで行われる。そして、要望情報管理部２３は、要望情報をユーザごとにまとめた要望管理データ３００として管理する。
そして、要望情報管理部２３は、要求に応じて要望情報をマッチング部２４に送信する。
【００３２】
そして、図５に示すように、要望管理データ３００は、要望ユーザの「ユーザＩＤ」と、要望ユーザが有閑ユーザから労力の提供を受ける日付を示す「要望日」と、要望ユーザが有閑ユーザから労力の提供を受ける時間を示す「要望時刻」との項目を備えている。本実施形態において、要望日および要望時刻は、要望時間情報として用いられる。
【００３３】
また、要望管理データ３００は、有閑ユーザによる労力の提供の場所を示す「提供場所」と、要望ユーザが要望する労力の具体的な内容を示す「要望内容」との項目を含む。さらに、要望管理データ３００は、ユーザ条件を指定する「指定事項」と、有閑ユーザに対して付与するポイントを示す「付与ポイント」との項目を含む。
【００３４】
提供場所には、例えば要望ユーザの住戸である要望ユーザ宅、有閑ユーザの住戸である有閑ユーザ宅、コミュニティ内のメンバーが共用可能な施設である共用施設を例示できる。特に、共用施設は、マンションであればマンション内に設定されたキッズルームや会議室などのマンション共用施設を例示できる。また、共用施設は、町内会等であれば集会所等を例示できる。
【００３５】
要望内容には、例えば、子供の送り迎え、子守の依頼であるベビーシッター、家具の移動、パソコン設定など具体的な労力の内容を示す。本実施形態において、要望内容は、要望労力内容情報として用いられる。
指定事項は、要望ユーザが有閑ユーザに対して要望するユーザ属性を具体的に指定する情報である。指定事項には、例えば、家族属性、性別、世代（年齢）、居住年数、職業、特記事項および経験値など、ユーザ管理データ１００で扱われる情報を登録することができる。本実施形態において、指定事項は、要望ユーザ属性情報として用いられる。
【００３６】
（マッチング部２４）
マッチング部２４は、有閑ユーザと要望ユーザとのニーズを結び付ける。本実施形態のマッチング部２４は、要望ユーザが要望する要望情報を画面に表示したり、有閑ユーザが提供可能な労力に関する有閑情報を画面に表示したりする。
【００３７】
そして、マッチング部２４は、要望情報（要望ユーザ）と有閑情報（有閑ユーザ）とで条件の合うものを特定する。本実施形態のマッチング部２４は、ユーザ管理データ１００、有閑管理データ２００および要望管理データ３００から得られる情報に基づいて条件に合致するか否かを判断する。
条件には、時間に関する時間条件と、ユーザ属性に関するユーザ属性条件と、労力の内容に関する労力内容条件とが含まれる。なお、本実施形態のマッチング部２４は、時間条件、ユーザ属性条件および労力内容条件の全てを条件として用いても良く、いずれか１つだけの条件を用いても良い。
【００３８】
時間条件を用いた条件の合致の判断は、要望ユーザの要望時間と、有閑ユーザの提供可能時間との比較に基づいて行われる。
ユーザ属性条件を用いた条件の合致の判断は、要望ユーザの要望ユーザ属性（例えば、「女性希望」など）と、有閑ユーザのユーザ属性（性別「女性」）との比較に基づいて行われる。
労力内容条件を用いた条件の合致の判断は、要望ユーザの要望労力内容（例えば、「家具の移動」など）と、有閑ユーザの提供労力内容（例えば、「力仕事自信有り」など）との比較に基づいて行われる。
なお、本実施形態において、ユーザ属性条件としての有閑ユーザのユーザ属性と、労力内容条件としての有閑ユーザの提供労力内容とを、有閑ユーザに関するユーザ条件と呼ぶ。
【００３９】
さらに、マッチング部２４は、条件に合う有閑情報の有閑ユーザと、要望情報の要望ユーザとの間で合意を行うために画像を各々の端末装置１０に表示する。そして、マッチング部２４は、システムのログイン画面や、相互のメッセージ送受信や、両者の合意の確認までの表示を行う。
【００４０】
そして、本実施形態のマッチングシステム１では、以下の複数の態様に応じた、要望ユーザと有閑ユーザとの結び付けを行う。
本実施形態のマッチングシステム１は、（１）要望ユーザが有閑ユーザを検索する態様（以下、要望ユーザによる検索態様）と、（２）有閑ユーザが要望ユーザを検索する態様（以下、有閑ユーザによる検索態様）とを行う場合がある。また、本実施形態のマッチングシステム１は、（３）要望ユーザが掲示板等に呼びかけを行い、有閑ユーザが呼びかけに応じる態様（以下、要望ユーザによる掲示態様）と、（４）有閑ユーザが掲示板等に呼びかけを行い、要望ユーザが呼びかけに応じる態様（以下、有閑ユーザによる掲示態様）とを行う場合がある。
【００４１】
次に、本実施形態のマッチングシステム１の動作について具体的に説明する。
〔（１）要望ユーザによる検索態様〕
図６は、要望ユーザによる検索態様におけるマッチングシステム１の動作フロー図である。
サーバ装置２０のユーザ情報管理部２１は、ユーザからのマッチングシステム１に対するログインを受け付ける（ステップ（以下、Ｓと表示）１０１）。本実施形態では、ユーザ管理データ１００に登録されるユーザＩＤと、予め登録されているパスワードとを用いてログイン認証が行われる。なお、本実施形態では、要望ユーザおよび有閑ユーザによって、それぞれログインが行われる。
【００４２】
そして、サーバ装置２０の有閑情報管理部２２は、有閑ユーザから、有閑ユーザが労力を提供できる旨の有閑情報の入力を受け付ける（Ｓ１０２）。本実施形態では、有閑情報として有閑ユーザが労力を提供することが可能な日時に関する提供可能時間の入力が行われる。
さらに、有閑情報管理部２２は、有閑ユーザから受け付けた有閑情報を、有閑管理データ２００（図４参照）として記憶する（Ｓ１０３）。
【００４３】
その後、サーバ装置２０のマッチング部２４は、要望ユーザから、要望ユーザが欲する労力に関する要望情報の入力を受け付ける（Ｓ１０４）。本実施形態では、要望情報として要望ユーザが要望する要望時間、要望ユーザ条件、および要望内容の入力が行われる。
【００４４】
そして、サーバ装置２０のマッチング部２４は、取得した要望情報に基づいて、複数の有閑ユーザの有閑情報のうち条件に合う有閑情報の検索を実行する（Ｓ１０５）。
さらに、マッチング部２４は、有閑情報の検索の結果を、要望ユーザの端末装置１０の画面１０ｄ（後述）に表示する（Ｓ１０６）。
その後、本実施形態では、マッチング部２４は、要望ユーザと有閑ユーザとが相互に合意が得られるように所定の画像を要望ユーザと有閑ユーザとの端末装置１０の画面１０ｄに表示する。なお、この所定の画像の内容については後に詳述する。
【００４５】
そして、要望ユーザに対して有閑ユーザが労力の提供を完了すると、サーバ装置２０は、要望ユーザから有閑ユーザに対するポイント付与の実行を要望ユーザから受け付ける（Ｓ１０７）。
なお、サーバ装置２０では、要望ユーザから、労力を提供してくれた有閑ユーザに対するコメントや評価などを収集するようにしても良い。そして、次回以降に要望ユーザが有閑ユーザを検索する際の条件として、有閑ユーザについてのコメントや評価などを用いても良い。
【００４６】
続いて、（１）要望ユーザによる検索態様に関して、要望ユーザの端末装置１０の画面１０ｄに表示される表示内容について詳細に説明する。
図７、図８および図９は、要望ユーザによる検索態様における画像の表示例である。
【００４７】
図７（Ａ）に示すように、要望ユーザは、本実施形態のマッチングシステム１を実現するアプリケーション・プログラムがインストールされた端末装置１０のログイン画像を画面１０ｄに表示させる。ログイン画像には、本システムのサービス名５１と、ユーザＩＤ入力欄５２１と、パスワード入力欄５２２とが表示される。そして、要望ユーザは、ユーザＩＤおよびパスワードを入力し、ログインを行う。
図７（Ａ）に示す例では、ユーザＩＤ「１０１１５０４」の氏名「Ｆ」がログインを行うことを表示している。
【００４８】
そして、ログインが行われると、図７（Ｂ）に示すように、画面１０ｄには、ユーザ管理データ１００（図３参照）に基づいて、ユーザＩＤによって特定されたコミュニティ識別番号に対応するコミュニティ名５３と、氏名に対応するユーザ名５４とが表示される。図７（Ｂ）の例では、コミュニティ名５３として「〇〇〇〇レジデンス」、ユーザ名５４として「Ｆ様」がそれぞれ表示される。
【００４９】
本実施形態では、ログインを行うことで、要望ユーザが所属するコミュニティを識別するコミュニティ識別番号に基づいて、そのコミュニティ識別番号と合致するコミュニティの有閑情報が提供される。すなわち、本実施形態のマッチングシステム１では、限定されたコミュニティ内でのマッチングが行われ、ユーザが所属していないコミュニティではマッチングが行われないようになっている。
【００５０】
さらに、図７（Ｂ）に示すように、画面１０ｄには、ユーザに対して、労力の提供を受けることを要望するユーザの操作を受け付ける要望ボタン５６１と、労力を提供する意思があるユーザの操作を受け付ける志願ボタン５６２とが表示される。
図７（Ｂ）の例では、要望ボタン５６１には、「お手伝いを要望する方」のテキストメッセージが表示される。一方、志願ボタン５６２には、「お手伝いを志願する方」のテキストメッセージが表示される。
この例では、要望ユーザがログインを行っているため、ユーザによって要望ボタン５６１が選択操作される。
【００５１】
そして、要望ボタン５６１が操作されることで、図８（Ａ）に表示するように、要望情報を受け付ける要望受付画像５０が表示される。要望受付画像５０には、要望日を入力する日付入力欄５８１と、要望時刻を入力する時刻入力欄５８２と、要望内容を入力する要望内容入力欄５８３と、指定事項を入力する指定事項入力欄５８４と、有閑ユーザに付与するポイントを入力するポイント入力欄５８５と、がそれぞれ表示される。
【００５２】
このうち、要望内容入力欄５８３は、要望ユーザが要望する要望内容が入力される。要望内容は、予め準備された複数候補から選択したり、テキストを打ち込んだりすることで入力される。
指定事項入力欄５８４は、要望ユーザが要望する要望ユーザ条件が入力される。指定事項入力欄５８４におけるユーザ条件の入力は、予め準備された複数候補から選択を受け付けたり、テキストの打ち込みを受け付けたりすることで行われる。
【００５３】
図８（Ａ）に示す例では、日付入力欄５８１には「１０月１０日」、時刻入力欄５８２には「１０：００〜１１：００」、要望内容入力欄５８３には「家具の移動」、指定事項入力欄５８４には「力仕事可能」、ポイント入力欄５８５には「１０００」がそれぞれ入力される。
【００５４】
そして、要望情報の入力が完了し、検索ボタン５９が選択操作されることで、条件を満たす有閑ユーザの検索が行われる。
この例において、「１０月１０日」および「１０：００〜１１：００」という時間条件と、「力仕事可能」というユーザ条件とを満たす有閑情報（有閑ユーザ）が、ユーザ管理データ１００（図３参照）および有閑管理データ２００（図４参照）に基づいて検索される。
【００５５】
その後、図８（Ｂ）に示すように、画面１０ｄには、検索結果が得られたことを示す結果メッセージ６１と、有閑情報の検索結果として２名の有閑ユーザの検索結果ボタン６２が表示される。
図８（Ｂ）に示す例では、画面１０ｄには、「２０１０号室のＢさん」と「１００８号室のＩさん」との２つの検索結果ボタン６２が表示される。
さらに、画面１０ｄには、検索結果ボタン６２を選択操作することで、有閑ユーザごとの詳細情報の表示、および、有閑ユーザと連絡を行うことができる旨を示す説明メッセージ６３が表示される。
【００５６】
そして、図８（Ｂ）に示す「１００８号室のＩさん」の検索結果ボタン６２が選択操作されると、図９（Ａ）に示すように、画面１０ｄには、有閑ユーザの詳細な情報を示すユーザ詳細情報６４と、有閑ユーザとメッセージトークを行うためのトークメッセージ画面６５とが表示される。
そして、トークメッセージ画面６５では、要望ユーザである「Ｆさん」と有閑ユーザである「Ｉさん」との間でトークセッションが構成され、詳細な条件の話し合いを行うことができる。詳細な条件の話し合いとして、要望ユーザが要望していた要望内容のうち、作業等の内容、詳しい時刻に関する内容、付与ポイントについての交渉などを行うことができる。
【００５７】
そして、有閑ユーザが同意することで有閑ユーザの端末装置１０からサーバ装置２０に同意する旨の情報が送信され、図９（Ｂ）に示すように、最終的な合意を行うための画像が表示される。この例では、画面１０ｄには、合意を得られたことを示す合意メッセージ６６と、有閑ユーザおよび条件等を示す合意内容表示６７と、合意を確定する操作を指示する確定指示メッセージ６８と、合意を確定させる合意確定ボタン６９とが表示される。
【００５８】
以上のように、要望ユーザの端末装置１０に表示される各種画像によって、要望ユーザによる有閑ユーザの検索と、要望ユーザと有閑ユーザとの合意までが行われる。
【００５９】
上述したとおり、要望ユーザによる検索態様において、本実施形態のマッチングシステム１では、要望ユーザが労力の提供を要望する場合に、複数の有閑ユーザの中から条件に合う有閑ユーザが特定される。このように、本実施形態のマッチングシステム１では、労力を提供できるユーザと、労力の提供を受けることを要望するユーザとを結び付けることができるようになっている。また、例えばマンションなどの同じコミュニティ内という顔見知りのユーザ同士がマッチングされるため、ユーザ同士で安心感が担保された状態で労力の提供および享受を行うことができる。
【００６０】
〔（２）有閑ユーザによる検索態様〕
図１０は、有閑ユーザによる検索態様におけるマッチングシステム１の動作フロー図である。
サーバ装置２０のユーザ情報管理部２１は、ユーザからのマッチングシステム１に対するログインを受け付ける（Ｓ２０１）。なお、ここでは、要望ユーザおよび有閑ユーザによって、それぞれログインが行われる。
【００６１】
そして、サーバ装置２０の要望情報管理部２３は、要望ユーザから、要望ユーザが欲する労力に関する要望情報の入力を受け付ける（Ｓ２０２）。
さらに、要望情報管理部２３は、要望ユーザから受け付けた要望情報を、要望管理データ３００（図５参照）として記憶する（Ｓ２０３）。
【００６２】
その後、サーバ装置２０のマッチング部２４は、有閑ユーザから、有閑ユーザが労力を提供することができる旨の有閑情報の入力を受け付ける（Ｓ２０４）。
そして、マッチング部２４は、取得した有閑情報に基づいて、複数の要望ユーザの要望情報のうち条件に合う要望情報の検索を実行する（Ｓ２０５）。
さらに、マッチング部２４は、要望情報の検索の結果を、有閑ユーザの端末装置１０の画面１０ｄに表示する（Ｓ２０６）。
【００６３】
そして、有閑ユーザが要望ユーザに対する労力の提供を完了すると、サーバ装置２０は、要望ユーザから有閑ユーザに対するポイント付与の実行を要望ユーザから受け付ける（Ｓ２０７）。
【００６４】
以上のようにして、本実施形態のマッチングシステム１では、有閑ユーザが労力を提供する意思がある場合に、複数の要望ユーザの中から条件に合う要望ユーザが特定される。このように、本実施形態のマッチングシステム１では、労力を提供できるユーザと、労力の提供を受けることを要望するユーザとを結び付けることができるようになっている。
【００６５】
続いて、（２）有閑ユーザによる検索態様に関して、有閑ユーザの端末装置１０の画面１０ｄに表示される表示内容について詳細に説明する。
図１１および図１２は、有閑ユーザによる検索態様における画像の表示例である。
【００６６】
要望ユーザによる検索態様の説明と同様に、有閑ユーザ検索態様においても、ログイン画像（図７（Ａ）参照）およびログイン後に所定の画像（図７（Ｂ）参照）が表示される。ここでは、ユーザＩＤ「１０１０１０１」の氏名「Ａ」がログインを行う例を用いる。
【００６７】
そして、有閑ユーザによって志願ボタン５６２（図７（Ｂ）参照）が選択操作されることで、図１１（Ａ）に表示するように、要望情報を受け付ける有閑受付画像７０が表示される。有閑受付画像７０には、労力を提供可能な日付を入力する日付入力欄７０１と、労力を提供可能な時刻（時間帯）入力する時刻入力欄７０２と、がそれぞれ表示される。
【００６８】
その後、有閑情報の入力が完了し、検索ボタン７０３が選択操作されることで、条件を満たす要望ユーザの検索が行われる。
この例では、「１０月１０日」および「１５：００〜１９：００」という時間条件と、ユーザ管理データ１００に基づくユーザ条件とに基づいて、要望情報（要望ユーザ）の検索が行われる。
【００６９】
そして、図１１（Ｂ）に表示するように、画面１０ｄには、検索結果が得られたことを示す結果メッセージ７１と、要望情報の検索結果として３件の要望ユーザの検索結果ボタン７２が表示される。
さらに、画面１０ｄには、検索結果ボタン７２を選択操作することで、要望ユーザごとの詳細情報が表示される旨を示す説明メッセージ７３が表示される。
【００７０】
また、各々の検索結果ボタン７２には、要望情報のうち要望時間情報を示す日時表示７２１と、要望内容を示す要望内容表示７２２と、要望ユーザ条件を示すユーザ条件表示７２３と、付与ポイントを示すポイント表示７２４とが含まれる。
【００７１】
そして、図１１（Ｂ）に示す「１０月１０日  １５：００〜１７：００」の検索結果ボタン７２が選択操作されると、図１２に示すように、画面１０ｄには、要望情報に関する要望ユーザの詳細な情報を示す要望ユーザ詳細表示７４が表示される。
要望ユーザ詳細表示７４は、ユーザ管理データ１００に基づいて、住戸番号や氏名などの各種のユーザ情報を含む。
【００７２】
さらに、画面１０ｄには、要望ユーザから有閑ユーザに対するコメントを示すコメント表示７５と、要望ユーザとメッセージトークを開始するためのメッセージトーク開始ボタン７６と、要望ユーザに対する労力の提供の意思を伝える志願ボタン７７とが表示される。
また、画面１０ｄには、メッセージトーク開始ボタン７６を選択操作することでメッセージトークが開始されること、志願ボタン７７を選択操作することで要望ユーザに対して労力の提供の意思を伝えられることをそれぞれ説明する説明メッセージ７８が表示される。
【００７３】
そして、有閑ユーザによる検索態様においても、有閑ユーザの端末装置１０に表示される各種画像によって、有閑ユーザによる要望ユーザの検索と、有閑ユーザと要望ユーザとの合意までが行われる。
特に、有閑ユーザは、要望ユーザ詳細表示７４から要望ユーザの情報を得ることができるため、労力を提供する相手のことを事前に確認することができる。
【００７４】
〔（３）要望ユーザによる掲示態様〕
図１３は、要望ユーザによる掲示態様における画像の表示例である。
要望ユーザによる掲示態様では、図１３に示すように、掲示板として用いられる画像表示装置３０の画面３０ｄに要望ユーザの要望情報が表示される。画像表示装置３０は、例えばマンションの共用エントランスの内側に設置されているなど、コミュニティ内で情報が閲覧されることを想定している。
また、この例において、共用エントランスのドアは、ユーザを一意に特定可能なＩＣチップが実装されたキーや、ユーザを特定可能なパスワードの入力によって開くようになっている。従って、ユーザが共用エントランスのドアを開けて共用エントランス内に入った際に、そのユーザを特定することが可能になっている。
さらに、この例においては、有閑ユーザによる有閑情報の登録は完了している。
【００７５】
例えば、ユーザＩＤ「１０１０１０１」であって氏名「Ａ」であるユーザがマンションに帰宅した際、ユーザである「Ａ」は、キーを用いて共用エントランスのドアを開ける。
そして、要望ユーザによる掲示態様において、サーバ装置２０のマッチング部２４は、ユーザである「Ａ」の有閑情報に基づいて、複数の要望ユーザの要望情報のうち条件に合う要望情報の検索を実行する。
【００７６】
この例では、ユーザである氏名「Ａ」のユーザＩＤ「１０１０１０１」から、有閑管理データ２００に基づいて「７：００〜１１：００」および「１５：００〜１９：００」に時間に余裕があるという時間条件が特定される。さらに、この例では、ユーザ管理データ１００に基づいて「女性」で「子育て経験有り」というユーザ条件が特定される。そして、マッチング部２４は、特定された時間条件およびユーザ条件を用いて、要望情報の検索を行う。
【００７７】
その後、図１３に示すように、マッチング部２４は、要望情報の検索の結果を、画像表示装置３０の画面３０ｄに表示する。
画面３０ｄには、操作の説明メッセージ８１が表示される。操作の説明メッセージ８１は、労力の提供を志願する場合に、画面をタッチする操作を行う、あるいは、二次元コードを読み取る操作を行うことを説明する。さらに、画面３０ｄには、複数の要望情報に対応して複数の要望掲示ボタン８２が表示される。
【００７８】
また、要望掲示ボタン８２には、要望情報のうち要望時間情報を示す日時表示８２１と、要望内容を示す要望内容表示８２２と、要望ユーザ条件を示すユーザ条件表示８２３と、付与ポイントを示すポイント表示８２４とが含まれる。
さらに、要望掲示ボタン８２には、要望掲示ボタン８２ごとに、二次元コード８２５が含まれる。二次元コード８２５は、要望情報をそれぞれ特定する特定情報と、有閑ユーザに関する情報が紐付けられた特定情報を送信するための送信先情報とが埋め込まれている。
【００７９】
そして、要望ユーザによる掲示態様では、画像表示装置３０における要望情報の掲示を見た有閑ユーザが、画面３０ｄをタッチしたり、所持する端末装置１０から二次元コード８２５を送信したりすることで、労力の提供の意思をサーバ装置２０に送信する。
さらに、サーバ装置２０では、二次元コード８２５に基づいて送信された有閑ユーザの情報を、要望ユーザの端末装置１０の表示画面に表示させる。この場合の要望ユーザの端末装置１０における表示は、例えば図８（Ｂ）に示す画像と同様に行うことができる。
なお、その後の有閑ユーザと要望ユーザとの合意までは、上述した実施形態と同様に行うことができる。
【００８０】
なお、上述した例では、有閑ユーザによる有閑情報の登録が予め完了していることを前提としているが、有閑情報が予め登録されていなくても良い。例えば、ユーザが共用エントランスのドアを解錠するキーの操作が行われた際に、キーの操作が行われた時間以降を提供可能時間とみなす。そして、ユーザ（有閑ユーザ）の提供可能時間に基づいて、要望情報の中から条件に合う要望情報を検索し、画像表示装置３０の画面に表示するようにしても良い。
【００８１】
以上のように、要望ユーザによる掲示態様では、ユーザが積極的に要望情報の検索を行わなくても、予め登録しておいた有閑情報に基づいて検索された要望情報が、画像表示装置３０に掲示されるようになっている。このように、要望ユーザによる掲示態様においても、マッチングシステム１では、労力を提供できるユーザと、労力の提供を受けることを要望するユーザとを結び付けることができるようになっている。
【００８２】
〔（４）有閑ユーザによる掲示態様〕
図１４は、有閑ユーザによる掲示態様における画像の表示例である。
有閑ユーザによる掲示態様では、図１４に示すように、掲示板として用いられる画像表示装置３０の画面３０ｄに有閑ユーザの有閑情報が表示される。画像表示装置３０は、例えばマンションの玄関の内側に設置されているなど、コミュニティ内で有閑情報が閲覧されることを想定している。
この例においては、氏名「Ｄ」は、有閑ユーザに提供して欲しい労力の内容（例えば、パソコン設定、家具の移動など）を要望情報として予め登録しておく。なお、この例では、要望情報には、要望時間情報は含まれていない。
【００８３】
例えば、ユーザＩＤ「１０１０６０９」であって氏名「Ｄ」であるユーザがマンションに帰宅した際、氏名「Ｄ」は、キーを用いて共用エントランスのドアを開ける。
そして、有閑ユーザによる掲示態様において、サーバ装置２０のマッチング部２４は、氏名「Ｄ」の要望情報に基づいて、複数の有閑ユーザの有閑情報のうち条件に合う有閑情報の検索を実行する。
この例では、氏名「Ｄ」が要望する労力である「パソコン設定」および「家具の移動」というユーザ条件に基づいて、有閑情報の検索が行われる。
【００８４】
その後、図１４に示すように、マッチング部２４は、有閑情報の検索の結果を、画像表示装置３０の画面３０ｄに表示する。
画面３０ｄには、操作の説明メッセージ９１が表示される。操作の説明メッセージ９１は、労力の提供を要望する場合に、画面をタッチする操作を行う、あるいは、二次元コードを読み取る操作を行うことを説明する。さらに、画面３０ｄには、複数の有閑情報に対応して複数の有閑掲示ボタン９２が表示される。
【００８５】
そして、有閑掲示ボタン９２には、有閑情報のうち労力を提供可能な提供日および提供時間を示す日時表示９２１と、得意な労力に関する得意情報表示９２２と、有閑ユーザのユーザ情報を示す有閑ユーザ情報９２３と、希望するポイントを示すポイント表示９２４とが含まれる。
さらに、有閑掲示ボタン９２には、有閑掲示ボタン９２ごとに、二次元コード９２５が含まれる。二次元コード９２５は、有閑情報をそれぞれ特定する特定情報と、要望ユーザに関する情報が紐付けられた特定情報を送信するための送信先情報とが埋め込まれている。
【００８６】
そして、有閑ユーザによる掲示態様では、画像表示装置３０における有閑情報の掲示を見た要望ユーザが、二次元コード９２５に基づいて、労力の提供を受けることの要望をサーバ装置２０に送信するようになっている。
さらに、サーバ装置２０では、二次元コード９２５に基づいて送信された要望ユーザの情報を、有閑ユーザの端末装置１０の表示画面に表示させる。
なお、その後の有閑ユーザと要望ユーザとの合意までは、上述した実施形態と同様に行うことができる。
【００８７】
以上のように、有閑ユーザによる掲示態様では、ユーザが積極的に有閑情報の検索を行わなくても、予め登録しておいた要望情報に基づいて検索された有閑情報が、画像表示装置３０に掲示されるようになっている。このように、有閑ユーザによる掲示態様においても、マッチングシステム１では、労力を提供できるユーザと、労力の提供を受けることを要望するユーザとを結び付けることができるようになっている。
【００８８】
〔変形例〕
上述した実施形態において、有閑情報に基づいて要望情報を検索したり、要望情報に基づいて有閑情報を検索したりしているが、これらの態様に限定されない。例えば、一のユーザの有閑情報に基づいて、他のユーザの有閑情報を検索し、一のユーザに対して有閑情報の提供を行っても良い。
【００８９】
例えば、氏名「Ｄ」のユーザＩＤ「１０１０６０９」から、有閑管理データ２００（図４参照）に基づいて「７：００〜１８：００」に時間に余裕が無いという多忙時間情報が特定される。そこで、氏名「Ｄ」のユーザに対して、多忙時間情報により特定される時間帯に、労力を提供可能な有閑ユーザの有閑情報を提供する。すなわち、氏名「Ｄ」が忙しいと予想される多忙時間に対応する有閑情報を提供することで、多忙な氏名「Ｄ」の手助けの提案を行うようにしている。
【００９０】
この変形例においても、ユーザが積極的に有閑情報の検索を行わなくても、予め登録しておいて有閑情報に基づいて検索された有閑情報が、ユーザに提供されるようになっている。このように、変形例においても、マッチングシステム１では、労力を提供できるユーザと、労力の提供を受けることを要望するユーザとを結び付けることができるようになっている。
【００９１】
次に、労力の提供場所の設定ついて説明する。
図１５は、本実施形態における提供場所設定画像４０の一例の図である。
本実施形態では、限られたコミュニティにおける労力の提供場所として、要望管理データ３００の「提供場所」に関して説明したとおり、要望ユーザ宅、有閑ユーザ宅および共用施設を例示できる。
そして、本実施形態の端末装置１０では、例えば要望ユーザが要望情報の登録を行う際に、画面１０ｄに、労力の提供場所の設定を受け付ける提供場所設定画像４０を表示する。
【００９２】
提供場所設定画像４０には、要望ユーザ宅に設定する要望ユーザ宅ボタン４１と、有閑ユーザ宅に設定する有閑ユーザ宅ボタン４２と、マンション等の共用施設を設定する共用施設ボタン４３とが表示される。
サーバ装置２０の要望情報管理部２３（設定手段の一例）は、要望ユーザ宅ボタン４１、有閑ユーザ宅ボタン４２および共用施設ボタン４３のいずれかが選択操作されることで、要望管理データ３００の提供場所の登録を行う。
【００９３】
また、本実施形態では、要望ユーザ宅ボタン４１が選択された際に、要望ユーザが要望ユーザの住戸を不在にする状態であっても、有閑ユーザが要望ユーザの住戸の解錠を可能にする不在時解除設定を行うようになっている。
このケースは、例えば要望ユーザの要望内容が、不在時における植物の水やり、不在時おけるペットのケアなどを行うことであって、要望ユーザが要望ユーザ宅に居ない状況でも、有閑ユーザが要望ユーザ宅に入って労力を提供することを想定したものである。
【００９４】
そして、不在時解除設定は、例えば住戸の玄関扉がパスワードで解錠できる住宅環境の場合、パスワードの設定および有閑ユーザへの通知となる。また、不在時解除設定は、例えばマンション管理人が住戸の鍵を管理している場合、マンション管理人による解除の手配となる。
【００９５】
また、本実施形態では、共用施設ボタン４３が選択された際に、共用施設の予約設定を行うようになっている。予約設定は、マンションの予約システムに対して共用施設の予約処理の実行となる。
このように、本実施形態のマッチングシステム１では、共用施設にて有閑ユーザから労力の提供を受ける際に、別の予約システムを利用したり、対面での予約作業を行ったりすることなく、同じマッチングシステム１において共用施設の予約を行うことができる。
【００９６】
以上のように、本実施形態のマッチングシステム１では、有閑ユーザと要望ユーザとのマッチングのみならず、労力の提供場所の設定までも一括して行えるようになっている。
【００９７】
なお、提供ユーザは、住民個人に限定されない。例えば、提供ユーザは、マンション等の理事会やマンションの管理組合等であっても良い。この場合、コミュニティ内で生じた課題を解決するに際して、コミュニティ内のユーザから有志を募ることが考えられる。例えば、大雪が降ってコミュニティ内の敷地の除雪に人手が必要である場合、理事会等が要望ユーザとなり、有閑ユーザを募ることができる。
【００９８】
また、本実施形態のマッチングシステム１において、有閑情報と要望情報との結び付け（マッチング）に関して、有閑ユーザの提供可能時間、ユーザ属性、および提供労力内容の各々の条件に重み付けをし、重み付けされた条件に基づいてマッチングを行っても良い。そして、マッチングにおいて、複数の検索の結果が得られた場合には、重み（マッチング度合い）に応じて複数の検索の結果に順位付けを行う。そして、順位（重み）がより高い検索の結果を優先的に利用するようにしても良い。
【００９９】
まず、提供可能時間とユーザ属性と提供労力内容との間で、各々の条件に重み付けを行うことを例示できる。例えば、提供可能時間に対する重み付けを最も高く設定し、次に、提供労力内容の重み付けを高くし、ユーザ属性の重み付けを比較的低く設定しても良い。
【０１００】
さらに、各々の条件を構成する情報の中において、各情報の重み付けを行っても良い。
提供可能時間の場合、要望時間に対する提供可能時間の適合度（一致度）を特定し、適合度が高い有閑情報に対しては重み付けを高くする。
ユーザ属性の場合、要望ユーザのユーザ属性に対する、有閑ユーザのユーザ属性の適合度を特定し、適合度がより高い有閑情報に対しては重み付けを高くする。具体的には、要望ユーザの世代に対して有閑ユーザの世代が近いほど、その有閑ユーザの有閑情報の重み付けを高くする。この場合、例えば、近い世代間のコミュニケーション作りを促すことができる。
提供労力内容の場合、要望労力内容に対する提供労力内容の適合度を特定し、適合度が高い有閑情報に対しては重み付けを高くする。具体的には、要望労力内容が「家具の移動」である場合、職業が引越業である有閑ユーザを、特記事項が力仕事に自信有りという有閑ユーザよりも重み付けを高くする。
【０１０１】
そして、例えば要望ユーザに対して有閑情報を提供する際に、重みが高い有閑情報ほど表示順位を上位にするなど、有閑情報の優先表示順を重みに応じて異ならせても良い。
【０１０２】
ここで、本実施形態の端末装置１０およびサーバ装置２０のハードウェア構成について説明する。
端末装置１０およびサーバ装置２０は、それぞれ、演算手段であるＣＰＵ（Central Processing Unit）、主記憶手段であるメモリ、磁気ディスク装置（ＨＤＤ：Hard Disk Drive）、ネットワークインターフェイス、ディスプレイ装置を含む表示機構、音声機構、および、キーボードやマウス等の入力デバイス等を備える。
そして、磁気ディスク装置には、ＯＳのプログラムやアプリケーション・プログラムが格納されている。そして、これらのプログラムがメモリに読み込まれてＣＰＵに実行されることにより、本実施形態の端末装置１０およびサーバ装置２０の各々における各機能部の機能が実現される。
さらに、本実施形態のマッチングシステム１における一連の動作を端末装置１０およびサーバ装置２０にてそれぞれ実現させるプログラムは、例えば通信手段により提供することはもちろん、各種の記録媒体に格納して提供しても良い。
【０１０３】
なお、本実施形態のマッチングシステム１において行われる一連の機能を実現するための構成は、上述した例に限定されない。例えば、上述した実施形態においてサーバ装置２０が実現する機能は、全てサーバ装置２０によって実現される必要はなく、例えば端末装置１０が一部の機能を実現しても良い。
【符号の説明】
【０１０４】
１…マッチングシステム、１０…端末装置、２０…サーバ装置、２１…ユーザ情報管理部、２２…有閑情報管理部、２３…要望情報管理部、２４…マッチング部、１００…ユーザ管理データ、２００…有閑管理データ、３００…要望管理データ
【図１】
2020004110.tif 000003
【図２】
2020004110.tif 000004
【図３】
2020004110.tif 000005
【図４】
2020004110.tif 000006
【図５】
2020004110.tif 000007
【図６】
2020004110.tif 000008
【図７】
2020004110.tif 000009
【図８】
2020004110.tif 000010
【図９】
2020004110.tif 000011
【図１０】
2020004110.tif 000012
【図１１】
2020004110.tif 000013
【図１２】
2020004110.tif 000014
【図１３】
2020004110.tif 000015
【図１４】
2020004110.tif 000016
【図１５】
2020004110.tif 000017