JP2021128649A - 役務マッチング支援サーバ及びプログラム - Google Patents

Abstract

【課題】雇用者の規模に関わらず、雇用者から求職者に対し、正当な報酬の確実な支払いを可能にし、また、架空のマッチングが行われるリスクを軽減することで、雇用者と求職者との双方がより安心して利用可能な役務マッチング支援サーバ及びプログラムを提供する。【解決手段】本発明の役務マッチング支援サーバ２は、役務の委託者端末３から委託者の身分証明情報を受信する委託者身分情報受信部２１１と、役務の受託者端末４から受託者の身分証明情報を受信する受託者身分情報受信部２１２と、委託者端末３に委託者向け本人認証情報を送信する第１認証情報送信部２１３と、受託者端末４に受託者向け本人認証情報を送信する第２認証情報送信部２１４と、委託者向け本人認証情報を有する委託者端末３、及び受託者向け本人認証情報を有する受託者端末４の間で、役務依頼に関する情報を相互に通信可能な情報通信部２１５と、を備える。【選択図】図１

Description

本発明は、役務マッチング支援サーバ及びプログラムに関する。

近年の労働形態の変化に伴い、隙間時間にサイドビジネスを行いたいという要望が高まっている。それに伴い、インターネットを介してこうしたサイドビジネスを行いたい求職者を募集する雇用者も増えている。こうした中で、特別な技能や資格等を必要としないサイドビジネスを求める傾向も強まっている。

その中でも近年はスマートフォンを用いたマッチングの要望が大きい。デスクトップコンピュータの代わりにスマートフォンを用いれば、外出先でも求人や求職を行えることから、スマートフォンを用いたマッチングは近年ますます注目されている。

近年、雇用者と求職者とをマッチングするマッチング支援サーバが提案されている（特許文献１参照）。このマッチング支援サーバでは、求職者が希望する勤務時間帯を少なくとも含む求職希望を受け付けることにより、求職者および雇用者間でのマッチングを容易に行うことができる。

特許６４７４０８９号公報

ところで、マッチング支援を受ける雇用者は、法人に限らず、個人であることもあり得る。雇用者側が個人である場合、求職者が一定以上の質でサービスを提供したとしても、求職者が正当な対価を受けられないリスクを伴う。

また、インターネットの匿名性から、実在しない雇用者が求人する、実在しない求職者が求人に応募する等といった架空のマッチングが行われることもあり得る。

こうしたことから、インターネットを介したマッチングにおいて、より安心して利用できる仕組みを提供することが求められる。

本発明は、このような考えに基づいてなされたものであり、雇用者の規模に関わらず、雇用者から求職者に対し、正当な報酬の確実な支払いを可能にし、また、架空のマッチングが行われるリスクを軽減することで、雇用者と求職者との双方がより安心して利用可能な役務マッチング支援サーバ及びプログラムを提供することを目的とする。

本発明者らは、上記課題を解決するために鋭意検討した結果、役務の委託者及び受託者の両方から身分証明情報を受信し、それぞれの端末に本人認証情報を送信し、本人認証情報を有する端末どうしにて役務依頼に関する情報のやりとりを可能にすることで、上記の目的を達成できることを見出し、本発明を完成させるに至った。具体的に、本発明は以下のものを提供する。

第１の特徴に係る発明は、役務の委託者端末から委託者の身分証明情報を受信する委託者身分情報受信部と、役務の受託者端末から受託者の身分証明情報を受信する受託者身分情報受信部と、前記委託者端末に委託者向け本人認証情報を送信する第１認証情報送信部と、前記受託者端末に受託者向け本人認証情報を送信する第２認証情報送信部と、前記委託者向け本人認証情報を有する前記委託者端末、及び前記受託者向け本人認証情報を有する前記受託者端末の間で、役務依頼に関する情報を相互に通信可能な情報通信部と、を備える、役務マッチング支援サーバである。

第１の特徴に係る発明によれば、サーバは、役務の委託者及び受託者の両方から身分証明情報を受信する。そして、サーバは、役務の委託者及び受託者それぞれの端末に本人認証情報を送信する。また、サーバの情報通信部は、本人認証情報を有するそれぞれの端末の間で、役務依頼に関する情報を相互に通信可能とする。

身分証明情報は、特に限定されるものでない。役務の委託者及び受託者が個人であれば、運転免許証、個人番号カード（マイナンバーカード）、保険証、パスポート等といった一般的に広く用いられる身分証明書を撮影した画像データのほか、電子証明書のデータ等が挙げられる。また、役務の委託者及び受託者が法人であれば、履歴事項全部証明書（登記簿謄本）を撮影した画像データのほか、電子証明書のデータ等が挙げられる。

役務依頼に関する情報もまた、特に限定されるものではない。役務依頼に関する情報として、例えば、役務の内容、役務の所要時間、役務を行う場所、役務を行う日時、役務に対する報酬の情報等が挙げられる。

第１の特徴に係る発明によれば、委託者と受託者は、互いに本人認証済である端末間で役務依頼に関するコミュニケーションをとることが可能である。サーバの管理者は、委託者と受託者それぞれの所在を確実に追うことができるため、委託者の規模の大小に関わらず、委託者から受託者に対して正当な報酬が確実に支払われる。また、架空のマッチングが行われるリスクを大幅に軽減できる。よって、第１の特徴に係る発明によれば、委託者と受託者との双方がより安心して利用可能なサーバを提供できる。

第２の特徴に係る発明は、第１の特徴に係る発明であって、前記委託者端末から決済情報を受信する決済情報受信部と、前記決済情報を受信した場合に、前記受託者端末に依頼成立情報を送信する依頼成立情報送信部と、前記委託者端末から、前記受託者による役務の質の評価を受信する第１評価情報受信部と、前記受託者端末から、前記委託者についての評価を受信する第２評価情報受信部と、前記第１評価情報受信部及び前記第２評価情報受信部により双方の評価が受信された場合に、前記受託者端末に報酬支払情報を送信する報酬支払情報送信部と、をさらに備える、役務マッチング支援サーバを提供する。

第２の特徴に係る発明によれば、依頼成立情報送信部は、委託者端末から決済情報が受信された場合に、受託者端末に依頼成立情報を送信する。これにより、委託者から受託者に支払われる報酬は、サーバの管理者に一時的に預けられた状態におかれ、その上で受託者が委託者に役務を提供することになる。したがって、委託者の規模の大小に関わらず、委託者から受託者への報酬の未払いを確実に抑えられる。

また、委託者は、受託者による役務の質の評価を行い、受託者は、委託者についての評価を行い、双方の評価をサーバが受信した場合に、サーバの報酬支払情報送信部は、受託者端末に報酬支払情報を送信する。役務提供後に相互評価するステップを踏まえることで、受託者による役務の質と、委託者の質との両方を高めることに繋がり得る。

よって、第２の特徴に係る発明によれば、委託者と受託者との双方がよりいっそう安心して利用可能なサーバを提供できる。

第３の特徴に係る発明は、第２の特徴に係る発明であって、前記受託者端末から所定情報を受信する所定情報受信部と、前記所定情報を受信した場合、前記受託者端末に報酬受取情報を送信する報酬受取情報送信部と、をさらに備える、役務マッチング支援サーバを提供する。

第３の特徴に係る発明によれば、サーバが受託者端末から所定情報を受信した場合に、サーバは、受託者端末に報酬受取に必要な報酬受取情報を送信する。

所定情報は特に限定されない。例えば、報酬の受け取り方法として、ＡＴＭからの現金引出を希望する旨の情報や、自ら保有する金融機関の口座への振り込みを希望する旨の情報、モバイル決済等に代表される電子決済システムへの入金を希望する旨の情報等が挙げられる。

報酬受取情報もまた、特に限定されない。例えば、現金自動預払機（Ａｕｔｏｍａｔｅｄ Ｔｅｌｌｅｒ Ｍａｃｈｉｎｅ，以下「ＡＴＭ」ともいう。）から現金を引き出すために必要な引き出し番号の情報、金融機関の口座への振込予定日及び振込予定額に関する情報、受託者が所有する電子決済システムへの入金予定日及び入金予定額に関する情報等が挙げられる。

第３の特徴に係る発明によれば、委託者から受託者への報酬の支払いを迅速かつ確実に行うことができるため、委託者と受託者との双方がよりいっそう安心して利用可能なサーバを提供できる。

第４の特徴に係る発明は、第１から第３のいずれかの特徴に係る発明であって、
前記委託者端末は、複数の委託者のそれぞれについて設けられ、前記複数の委託者端末から、前記受託者の人数に関する情報を受信する受託者数情報受信部と、前記複数の委託者端末のうち、前記委託者の属性情報が同一又は類似する委託者端末間において、一方の委託者側では受託者の人数が過剰であり、他方の委託者側では受託者の人数が不足である場合に、前記一方の委託者及び前記他方の委託者の委託者端末に、前記一方の委託者が委託する受託者の一部を前記一方の委託者から前記他方の委託者に派遣することを示す派遣情報を送信する派遣情報送信部と、をさらに備える、役務マッチング支援サーバを提供する。

第４の特徴に係る発明によれば、受託者数情報受信部は、複数の委託者端末から、受託者の人数に関する情報を受信し、遣情報送信部は、複数の委託者端末のうち、委託者の属性情報が同一又は類似する委託者端末間において、所定の場合に、一方の委託者が委託する受託者の一部を一方の委託者から他方の委託者に派遣することを示す派遣情報を送信する。属性情報の種類は特に限定されない。例えば、委託者が役務提供を受けることを希望する希望地に関する情報、委託者の業種に関する情報、店舗の系列に関する情報等が挙げられる。

第４の特徴に係る発明によると、委託者の属性情報が同一又は類似する委託者端末間において、受託者の人数が過剰である一方の委託者から、受託者の人数が不足である他方の委託者に向けて、一方の委託者が委託する受託者の一部を派遣することができる。例えば、同一市内にある同一業種の店舗間で、急な欠員が生じたＡ店舗に、余剰人員があるＢ店舗の人員をマッチングして派遣する、といったことを支援できる。委託者にとっては、適正な数の人員をできるだけ少ないコストで確保できる点で安心できる。受託者にとっても、急な休みや、急な役務提供といった事態を防ぐことができるため、報酬を確実に確保しつつ、自分の時間も確保でき、ワークライフバランスに優れるといった点で安心できる。

よって、第４の特徴に係る発明によれば、委託者と受託者との双方がよりいっそう安心して利用可能なサーバを提供できる。

第５の特徴に係る発明は、第４の特徴に係る発明であって、前記他方の委託者の委託者端末から特定決済情報を受信する特定決済情報受信部と、前記特定決済情報が受信された場合、前記一方の委託者の委託者端末、あるいは前記一方の委託者から前記他方の委託者に派遣された受託者の受託者端末に特定報酬支払情報を送信する特定報酬支払情報送信部と、をさらに備える、役務マッチング支援サーバを提供する。

第５の特徴に係る発明によると、報酬支払の遅滞リスクを軽減できる点で、委託者と受託者との双方がよりいっそう安心して利用可能なサーバを提供できる。

第６の特徴に係る発明は、第４又は第５の特徴に係る発明であって、前記属性情報は、店舗の系列情報を含み、前記派遣情報送信部は、前記複数の委託者端末のうち、前記委託者が所属する店舗の前記系列情報が同一の委託者端末間において、前記派遣情報の送信を行う、役務マッチング支援サーバを提供する。

第６の特徴に係る発明によれば、属性情報は、店舗の系列情報を含むため、複数の委託者端末について、委託者が所属する店舗の系列情報が同一であるかどうかを判別できる。そして、派遣情報送信部は、複数の委託者端末のうち、委託者が所属する店舗の系列情報が同一の委託者端末間において、派遣情報の送信を行う。これにより、委託者は、地域を絞って集中的に出店するドミナント戦略を構築でき、適正な数の人員をできるだけ少ないコストで確保し、同一商圏内で市場占有率を向上させて独占状態を目指すことが可能になる。

受託者にとっても、急な休みや、急な役務提供といった事態を防ぐことができるため、報酬を確実に確保しつつ、自分の時間も確保でき、ワークライフバランスに優れるといった点で安心できる。

よって、第６の特徴に係る発明によれば、委託者と受託者との双方がよりいっそう安心して利用可能なサーバを提供できる。

第７の特徴に係る発明は、第１から第６のいずれかの特徴に係る発明であって、前記委託者と前記受託者との間で依頼が成立した場合に、前記受託者端末に、前記受託者の居住地から前記受託者による役務提供場所までのアクセス情報を送信するアクセス情報送信部をさらに備える、役務マッチング支援サーバを提供する。

第７の特徴に係る発明によれば、受託者は、サーバから送信されたアクセス情報を利用して、受託者の居住地から受託者による役務提供場所まで迷わずに移動できる。委託者にとっては、受託者が遅刻するリスクを防ぐことができ、より適正な人員配置が可能になる点で安心できる。受託者にとっては、道に迷うことによって生じるストレスを軽減でき、また、遅刻等によって予定の報酬より少なくなってしまうリスクを軽減できる点で安心できる。

よって、第７の特徴に係る発明によれば、委託者と受託者との双方がよりいっそう安心して利用可能なサーバを提供できる。

第８の特徴に係る発明は、第１から第７のいずれかの特徴に係る発明であって、前記受託者端末から前記受託者による役務提供の開始時刻及び終了時刻を受信する時間情報受信部と、報酬が都度払いである場合、前記終了時刻を受信したことに応じて、前記委託者と前記受託者との間で交わされた報酬単価情報と前記開始時刻と前記終了時刻とに基づいて前記委託者から前記受託者への都度払い報酬を算出する都度払い報酬算出部と、をさらに備える役務マッチング支援サーバを提供する。

第８の特徴に係る発明によれば、委託者から受託者への報酬の支払いを、日払い等によって迅速かつ確実に行うことができるため、委託者と受託者との双方がよりいっそう安心して利用可能なサーバを提供できる。

第９の特徴に係る発明は、第８の特徴に係る発明であって、報酬が掛払いである場合、前記報酬単価情報と前記開始時刻と前記終了時刻とに基づき、前記掛払いの締め毎の掛払い報酬を算出する掛払い報酬算出部をさらに備えるマッチング支援サーバを提供する。

第９の特徴に係る発明によれば、週払いや月払い等の掛払いにおいても、委託者から受託者への報酬の支払いを確実に行うことができるため、委託者と受託者との双方がよりいっそう安心して利用可能なサーバを提供できる。

第１０の特徴に係る発明は、第１の特徴に係る発明のカテゴリー違いに相当する。

本発明によれば、役務の委託者と役務の受託者との双方がより安心して利用可能な役務マッチング支援サーバ及びプログラムを提供できる。

図１は、本実施形態における役務マッチング支援システム１のハードウェア構成とソフトウェア構成を示すブロック図である。 図２は、本実施形態における役務マッチング支援サーバ２を使用した役務マッチング支援の流れを示すメインフローチャートである。 図３は、本実施形態における役務マッチング支援サーバ２を使用した役務マッチング支援のユーザ情報登録処理の流れを示すフローチャートである。 図４は、本実施形態における本人認証情報テーブル２３１の一例を示す図である。 図５は、本実施形態における役務マッチング支援サーバ２を使用した役務マッチング支援の役務依頼処理の流れを示すフローチャートである。 図６は、本実施形態における役務情報テーブル２３２の一例を示す図である。 図７は、本実施形態における役務マッチング支援サーバ２を使用した役務マッチング支援の情報交換処理の流れを示すフローチャートである。 図８は、本実施形態における役務マッチング支援サーバ２を使用した役務マッチング支援の委託成立処理の流れを示すフローチャートである。 図９は、本実施形態における役務マッチング支援サーバ２を使用した役務マッチング支援の相互評価処理の流れを示すフローチャートである。 図１０は、本実施形態における役務マッチング支援サーバ２を使用した役務マッチング支援の報酬支払処理の流れを示すフローチャートである。 図１１は、本実施形態における受託者端末４の表示部４４の一例を示す図である。 図１２は、本実施形態における委託者端末３の表示部３４の一例を示す図である。 図１３は、変形例１における委託者情報テーブルの一例を示す図である。 図１４は、変形例３における役務情報テーブル２３２の一例を示す図である。

以下、本発明を実施するための好適な形態の一例について図を参照しながら説明する。なお、これはあくまでも一例であって、本発明の技術的範囲はこれに限られるものではない。

＜役務マッチング支援システム１＞
図１は、本実施形態における役務マッチング支援システム１の概略構成を示す模式図である。役務マッチング支援システム１は、役務マッチング支援サーバ２と、１つ又は複数の委託者端末３と、１つ又は複数の受託者端末４とを含んで構成される。以下、役務マッチング支援サーバ２は、単に「サーバ２」とも称し、１つ又は複数の委託者端末３は、単に「委託者端末３」とも称し、１つ又は複数の受託者端末４は、単に「受託者端末４」とも称する。そして、サーバ２と、委託者端末３と、受託者端末４とは、ネットワーク５を介して接続されている。

本実施形態において、「役務」の種類は、他人のために行う労務やサービスであれば特に限定されるものではない。中でも、役務の委託者及び受託者の両方が役務マッチング支援システム１を気軽に利用できる点で、「役務」の種類は、専門的なスキルを要しない内容、例えば、家具の組み立て、家事手伝い、場所取り、列への並び代行、配達、引越し手伝い、助っ人、娯楽等、比較的短い隙間時間で完結する作業であることが好ましい。

また、役務の委託者及び受託者は、個人であるか法人であるかを問わず、どちらでもよい。

〔サーバ２〕
サーバ２は、制御部２１と、記憶部２３、通信部２４と、を含んで構成される。

制御部２１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、及びＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）等を備える。

制御部２１は、所定のプログラムを読み込み、必要に応じて記憶部２３及び／又は通信部２４と協働することで、サーバ２におけるソフトウェア構成の要素である委託者身分情報受信部２１１、受託者身分情報受信部２１２、第１認証情報送信部２１３、第２認証情報送信部２１４、情報通信部２１５、決済情報受信部２１６、依頼成立情報送信部２１７、第１評価情報受信部２１８、第２評価情報受信部２１９、報酬支払情報送信部２２０、所定情報受信部２２１、報酬受取情報送信部２２２等を実現する。

記憶部２３は、データやファイルが記憶される装置であって、ハードディスクや半導体メモリ、記録媒体、メモリカード等による、データのストレージ部を有する。記憶部２３には、制御部２１のマイクロコンピューターで実行される制御プログラム等が記憶されている。

記憶部２３には、委託者向け本人認証情報及び／又は受託者向け本人認証情報を列挙した本人認証情報テーブル２３１、役務依頼に関する情報を格納した役務情報テーブル２３２等が記憶されている。

［通信部２４］
通信部２４は、役務マッチング支援サーバ２をその他の機器と通信可能にするためのデバイス、例えばイーサネット（登録商標）規格に対応したネットワークカード等を有する。

〔委託者端末３〕
委託者端末３は、役務を委託する委託者のそれぞれに割り当てられている。委託者端末３の種類は特に限定されず、デスクトップ型パーソナルコンピュータ、ノート型パーソナルコンピュータ、タブレット端末、スマートフォン、フィーチャーフォン等、ネットワーク５に接続可能な装置であればよい。中でも、役務の委託者が役務マッチング支援システム１をより気軽に利用できる点で、委託者端末３の種類は、タブレット端末又はスマートフォンであることが好ましい。

委託者端末３は、制御部３１と、記憶部３２と、通信部３３と、表示部３４と、を含んで構成される。

委託者端末３の制御部３１及び記憶部３２のハードウェア構成は、役務マッチング支援サーバ２の制御部２１及び記憶部２３のハードウェア構成とそれぞれ同様である。

記憶部３２には、委託者が所有する装置を委託者端末３として実行させるための委託者側アプリケーション（委託者側プログラム）が実装されている。委託者側アプリケーション（委託者側プログラム）の内容については、後に図２以降を参照しながら詳しく説明する。

通信部３３は、役務マッチング支援サーバ２その他の機器と通信可能にするためのデバイス、例えば携帯電話ネットワークに対応した無線装置、Ｗｉ−Ｆｉスポットとの接続に対応した無線装置、イーサネット（登録商標）規格に対応したネットワークカード等を有する。

表示部３４の種類は、特に限定されない。表示部３４として、例えば、モニタ、タッチパネル等を含む構成が挙げられる。

〔受託者端末４〕
受託者端末４は、役務を受託する受託者のそれぞれに割り当てられている。受託者端末４の種類は特に限定されず、デスクトップ型パーソナルコンピュータ、ノート型パーソナルコンピュータ、タブレット端末、スマートフォン、フィーチャーフォン等、ネットワーク５に接続可能な装置であればよい。中でも、役務の受託者が役務マッチング支援システム１をより気軽に利用できる点で、受託者端末４の種類は、タブレット端末又はスマートフォンであることが好ましい。

受託者端末４は、制御部４１と、記憶部４２と、通信部４３と、表示部４４と、を含んで構成される。

受託者端末４の制御部４１、記憶部４２、通信部４３及び表示部４４のハードウェア構成は、委託者端末３の制御部３１、記憶部３２、通信部３３及び表示部３４のハードウェア構成とそれぞれ同様である。

記憶部４２には、受託者が所有する装置を受託者端末４として実行させるための受託者側アプリケーション（受託者側プログラム）が実装されている。受託者側アプリケーションは、委託者端末３の記憶部３２に実装されている委託者側アプリケーションを含んでいてもよい。受託者側アプリケーションが委託者側アプリケーションを含むことにより、受託者端末４は、委託者端末３としても利用できる。受託者側アプリケーション（受託者側プログラム）の内容については、後に図２以降を参照しながら詳しく説明する。

〔ネットワーク５〕
ネットワーク５は、役務マッチング支援サーバ２と、委託者端末３と、受託者端末４とを接続する。ネットワーク５の種類は特に限定されず、インターネット、携帯電話ネットワーク、Ｗｉ−Ｆｉネットワーク等、あるいはこれらを含むネットワークを複数組み合わせたネットワーク等が挙げられる。

＜サーバ２を用いた役務マッチング支援の手順＞
以下、図２〜図１０を参照しながら、サーバ２を使用した役務マッチング支援の手順について説明する。

〔メインフローチャート〕
図２は、本実施形態における役務マッチング支援の手順を示すメインフローチャートの一例である。

［ステップＳ１：ユーザ情報登録処理］
まず、制御部２１は、後に図３を参照しながら説明するユーザ情報登録処理を行う（ステップＳ１）。ユーザ情報登録処理は、サーバ２の制御部２１が委託者端末３から委託者の身分証明情報を受信し、委託者の身分証明情報を記憶部２３に記憶するとともに、サーバ２の制御部２１が受託者端末４から受託者の身分証明情報を受信し、受託者の身分証明情報を記憶部２３に記憶する処理である。制御部２１は、ユーザ情報登録処理を行うと、処理をステップＳ２に移す。

［ステップＳ２：役務依頼処理］
続いて、制御部２１は、後に図５を参照しながら説明する役務依頼処理を行う（ステップＳ２）。役務依頼処理は、サーバ２の制御部２１が委託者端末３から役務の依頼に関する情報を受信し、制御部２１が、複数の受託者がそれぞれ所有する受託者端末４に対してその役務依頼に関する情報を表示させる処理である。制御部２１は、役務依頼処理を行うと、処理をステップＳ３に移す。

［ステップＳ３：情報交換処理］
続いて、制御部２１は、後に図７を参照しながら説明する情報交換処理を行う（ステップＳ３）。情報交換処理は、役務の依頼を行い、かつ、ステップＳ１にてユーザ情報が登録された委託者端末３と、役務依頼に関する情報の内容を閲覧し、その内容に興味をもった受託者の受託者端末４であって、かつ、ステップＳ１にてユーザ情報が登録された受託者端末４との間で、役務依頼に関する情報を相互に交換する処理である。制御部２１は、情報交換処理を行うと、処理をステップＳ４に移す。

［ステップＳ４：委託成立処理］
続いて、制御部２１は、後に図８を参照しながら説明する委託成立処理を行う（ステップＳ４）。委託成立処理は、ステップＳ３での情報交換の結果、委託者から受託者への業務委託が成立した場合に実行される処理である。制御部２１は、委託成立処理を行うと、処理をステップＳ５に移す。

［ステップＳ５：相互評価処理］
続いて、制御部２１は、後に図９を参照しながら説明する相互評価処理を行う（ステップＳ５）。相互評価処理は、委託者から受託者の評価と、受託者から委託者の評価とを互いに行うとともに、委託者から受託者への報酬の支払いを通知する処理である。制御部２１は、相互評価処理を行うと、処理をステップＳ６に移す。

［ステップＳ６：報酬支払処理］
続いて、制御部２１は、後に図１０を参照しながら説明する報酬支払処理を行う（ステップＳ６）。報酬支払処理は、委託者から受託者への報酬の支払いを行う処理である。制御部２１は、報酬支払処理を行うと、処理をステップＳ１に戻し、ステップＳ１〜Ｓ６を繰り返す。

〔ユーザ情報登録処理の流れ〕
図３は、ステップＳ１で行われるユーザ情報登録処理を行う手順の一例を示すフローチャートである。以下では、図３を参照しながら、ステップＳ１で行われるユーザ情報登録処理の好ましい手順についてより詳しく説明する。

［ステップＳ１１：委託者の身分情報を受信したか否かの判定］
まず、制御部２１は、通信部２４と協働して委託者身分情報受信部２１１を実行し、委託者端末３から委託者の身分証明情報を受信したか否かを判定する（ステップＳ１１）。制御部２１は、委託者端末３から委託者の身分証明情報を受信した場合、処理をステップＳ１２に移す。一方、制御部２１は、委託者端末３から委託者の身分証明情報を受信していない場合、処理をステップＳ１４に移す。

ステップＳ１１で受信する委託者の身分証明情報として、例えば、役務の委託者の氏名、住所、電話番号等が挙げられる。また、ステップＳ１１で受信する委託者の身分証明情報は、役務の委託者が個人であれば、運転免許証、個人番号カード（マイナンバーカード）、保険証、パスポート等といった一般的に広く用いられる身分証明書を撮影した画像データのほか、電子証明書のデータ等を含んでいてもよい。また、ステップＳ１１で受信する委託者の身分証明情報は、例えば、役務の委託者が法人であれば、履歴事項全部証明書（登記簿謄本）を撮影した画像データのほか、電子証明書のデータ等を含んでいてもよい。これらはステップＳ１１で受信する委託者の身分証明情報の一例であり、役務の委託者が個人である場合も法人である場合も、ステップＳ１１で受信する委託者の身分証明情報は、これらに限定されない。

［ステップＳ１２：委託者向け本人認証情報の登録］
続いて、制御部２１は、記憶部２３と協働して、本人認証情報テーブル２３１に、委託者が本人認証済であることを示す委託者向け本人認証情報を登録する（ステップＳ１２）。制御部２１は、委託者向け本人認証情報を登録すると、処理をステップＳ１３に移す。本人認証情報テーブル２３１の構成は、ステップＳ１５において説明する。

［ステップＳ１３：委託者端末に委託者向け本人認証情報を送信］
続いて、制御部２１は、通信部２４と協働して、第１認証情報送信部２１３を実行し、ステップＳ１１で受信した委託者の身分情報の送信元である委託者端末３に委託者向け本人認証情報を送信する（ステップＳ１３）。制御部２１は、委託者向け本人認証情報を委託者端末３に送信すると、処理をステップＳ１４に移す。

［ステップＳ１４：受託者の身分情報を受信したか否かの判定］
続いて、制御部２１は、通信部２４と協働して受託者身分情報受信部２１２を実行し、受託者端末４から受託者の身分証明情報を受信したか否かを判定する（ステップＳ１４）。制御部２１は、受託者端末４から受託者の身分証明情報を受信した場合、処理をステップＳ１５に移す。制御部２１は、受託者端末４から受託者の身分証明情報を受信していない場合、ユーザ情報登録処理を終了し、処理を図２のステップＳ２に移す。

ステップＳ１４で受信する受託者の身分証明情報は、ステップＳ１１で受信する委託者の身分証明情報と同様である。

［ステップＳ１５：受託者向け本人認証情報の登録］
続いて、制御部２１は、記憶部２３と協働して、本人認証情報テーブル２３１に受託者が本人認証済であることを示す受託者向け本人認証情報を登録する（ステップＳ１５）。制御部２１は、受託者向け本人認証情報を登録すると、処理をステップＳ１６に移す。

図４は、記憶部２３が記憶する本人認証情報テーブル２３１の一例である。図４に示すように、本人認証情報テーブル２３１は、本人認証情報を特定するＩＤと、委託者又は受託者のユーザ名と、後述する情報交換処理で用いられる表示名と、本人認証が済んでいるか否かを示す情報と、を含む情報を紐つけて記憶する。例えば、ＩＤ：１が示す行には、委託者であるユーザ名「山田太郎」が、情報交換処理で表示名「太郎」を用い、本人認証済であることが記憶されている。また、本人認証テーブル２３１は、さらに、委託者であるか受託者であるかを区別する分類を含んでいてもよい。

ＩＤが記憶されていることにより、制御部２１は、本人認証情報テーブル２３１に格納される多数の本人認証情報から特定の本人認証情報を特定し、取得できる。ユーザ名が記憶されていることにより、制御部２１は、ユーザ名による本人認証情報の特定と取得が可能となる。表示名が記憶されていることにより、制御部２１は、情報交換処理でユーザ名と異なる表示名を用いて情報交換することができる。本人認証が済んでいるか否かを示す情報が記憶されていることにより、記憶部２３は、本人認証が済んだ委託者又は受託者だけでなく、本人認証を進めている最中の委託者又は受託者、あるいは、本人認証が行えなかった委託者又は受託者を、本人認証情報テーブル２３１に記憶できる。分類が記憶されていることにより、記憶部２３は、委託者と受託者とを同一の本人認証情報テーブル２３１に記憶できる。

図４では、委託者と受託者とを同一の本人認証情報テーブル２３１に記憶しているが、本人認証情報テーブル２３１の構成はこれに限定されない。例えば、記憶部２３に、委託者の本人認証情報を記憶する委託者向け本人認証情報テーブルと、受託者の本人認証情報を記憶する受託者向け本人認証情報テーブルとをそれぞれ別のテーブルとして記憶するよう構成することも可能である。また、本人認証情報テーブル２３１は、委託者の身分証明情報と、受託者の身分証明情報とを含むこともまた好ましい。

［ステップＳ１６：受託者端末に受託者向け本人認証情報を送信］
図３に戻る。制御部２１は、通信部２４と協働して、第２認証情報送信部２１４を実行し、ステップＳ１１で受信した受託者の身分情報の送信元である受託者端末４に受託者向け本人認証情報を送信する（ステップＳ１６）。受託者向け本人認証情報を送信すると、制御部２１は、ユーザ情報登録処理を終了し、処理を図２のステップＳ２に移す。

〔役務依頼処理の流れ〕
図５は、ステップＳ２で行われる役務依頼処理を行う手順を示すフローチャートの一例である。以下では、図５を参照しながら、図２のステップＳ２で行われる役務依頼処理の好ましい手順についてより詳しく説明する。

［ステップＳ２１：役務依頼を受信したか否かの判定］
まず、制御部２１は、通信部２４と協働して情報通信部２１５を実行し、認証済み委託者端末３から役務依頼を受信したか否かを判定する（ステップＳ２１）。制御部２１は、認証済み委託者端末３から役務依頼を受信した場合、処理をステップＳ２２に移す。一方、制御部２１は、認証済み委託者端末３から役務依頼を受信していない場合、役務依頼処理を終了し、処理を図２のステップＳ３に移す。

認証済み委託者端末３は、上述のステップＳ１３で送信された委託者向け本人認証情報を受信した委託者端末３である。役務マッチング支援サーバ２において、ある委託者端末３が認証済み委託者端末３であるか否かを判定する手段は、特に限定されず、委託者端末３の委託者側アプリケーションから委託者向け本人認証情報を受信する方式でもよく、本人認証情報テーブル２３１に記録された委託者向け本人認証情報を取得する方式でもよい。

ステップＳ２１で受信する役務依頼に含まれる情報は、特に限定されない。役務依頼に含まれる情報として、例えば、委託者名、役務の内容、役務の所要時間、役務を行う場所、役務を行う日時、役務に対する報酬の情報等が挙げられる。

［ステップＳ２２：役務依頼情報の登録］
制御部２１は、記憶部２３と協働して、役務情報テーブル２３２に、役務依頼に関する情報を登録（格納）する。役務情報テーブル２３２に登録（格納）する役務依頼に関する情報は、ステップＳ２１で受信した役務依頼に関する情報を含むことが好ましいが、特に限定されない。役務情報テーブル２３２に、役務依頼に関する情報を格納すると、制御部２１は、処理をステップＳ２３に移す。

図６は、役務情報テーブル２３２の一例である。図６に示すように、役務情報テーブル２３２は、役務情報を特定するＩＤと、役務を委託する委託者と、委託者が本人認証済みであるか否かを示す委託者本人認証と、役務の内容を示す役務内容と、役務に対する報酬を示す役務報酬と、役務を行う受託者を示す受託者と、を紐つけて記憶する。また、図６の役務情報テーブル２３２には、委託者が行った受託者による役務の質の評価である第１評価、受託者が行った委託者についての評価である第２評価、報酬支払情報送信、報酬受取情報送信も記憶されているが、これらについては図９の相互評価処理において説明する。

ＩＤが記憶されていることにより、制御部２１は、役務情報テーブル２３２に格納される多数の役務情報から特定の役務情報を特定し、取得できる。委託者が記憶されていることにより、受託者は、委託者が誰であるかを確認できる。委託者本人認証の有無が記憶されていることにより、受託者は、委託者が本人認証済であるかどうかを確認できる。役務内容が記憶されていることにより、委託者及び受託者は、役務の内容を確認できる。役務報酬が記憶されていることにより、委託者及び受託者は、役務に対する報酬を確認できる。受託者が記憶されていることにより、委託者は、受託者が誰であるかを確認できる。受託者本人認証の有無が記憶されていることにより、委託者は、受託者が本人認証済であるかどうかを確認できる。

図６に示す役務情報テーブル２３２の一例において、ＩＤ：１が示す行には、委託者「佐藤花子」が、本人認証「済」であり、「家具組み立て」という役務内容を、役務報酬「３０００円」で依頼し、受託者「虎龍運歩」がこの役務を受託して、この受託者も本人認証「済」であることが記憶されている。図６において、空欄は、対応する登録処理が行われていないことを示す。例えば、ＩＤ：４の受託者の空欄は、委託者「鈴木三郎」が依頼した「花見」という役務内容を受託した受託者を登録する処理が行われていない、すなわち、役務を行う受託者がまだ決まっていないことを示している。

［ステップＳ２３：認証済み受託者端末に役務依頼情報を表示］
続いて、制御部２１は、通信部２４と協働して、認証済み受託者端末４の表示部４４に役務依頼情報を表示させる指令を送信する。認証済み受託者端末４の表示部４４に役務依頼情報を表示させる指令を送信すると、制御部２１は、役務依頼処理を終了し、処理を図２のステップＳ３に移す。

認証済み受託者端末４は、上述のステップＳ１６で送信された受託者向け本人認証情報を受信した受託者端末４である。役務マッチング支援サーバ２において、ある受託者端末４が認証済み受託者端末４であるか否かを判定する手段は、特に限定されず、受託者端末４の受託者側アプリケーションから受託者向け本人認証情報を受信する方式でもよく、本人認証情報テーブル２３１に記録された受託者向け本人認証情報を取得する方式でもよい。

認証済み受託者端末４の表示部４４に役務依頼情報を表示させる指令が送信されるため、認証済み受託者端末４は、役務依頼情報を表示できる。これにより、受託者は、表示された役務依頼情報から受託者を募集している役務依頼に関する情報を閲覧できる。そして、興味を持った役務依頼に応募できる。

〔情報交換処理〕
図７は、ステップＳ３で行われる情報交換処理を行う手順を示すフローチャートの一例である。以下では、図７を参照しながら、図２のステップＳ３で行われる情報交換処理の好ましい手順についてより詳しく説明する。

［ステップＳ３１：応募コマンドを受信したか否かの判定］
まず、制御部２１は、通信部２４と協働して情報通信部２１５を実行し、１つ又は複数の認証済み受託者端末４のうちいずれかの認証済み受託者端末４から受託者が役務依頼に応募する応募コマンドを受信したか否かを判定する（ステップＳ３１）。制御部２１は、いずれかの認証済み受託者端末４から応募コマンドを受信したならば、処理をステップＳ３２に移す。一方、制御部２１は、いずれの認証済み受託者端末４からも役務依頼を受信していないならば、情報交換処理を終了し、処理を図２のステップＳ４に移す。応募コマンドの受信の有無を判定することにより、制御部２１は、役務依頼に関する情報の内容を閲覧し、その内容に興味をもった受託者が認証済み受託者端末４を介して役務依頼に応募しているか否かを判定できる。

応募コマンドに含まれる情報は、特に限定されない。応募コマンドは、受託者が応募する役務依頼を特定する情報を含むことが好ましい。また、応募コマンドは、受託者を特定する情報を含むことが好ましい。

［ステップＳ３２：情報交換スレッドの開設］
続いて、制御部２１は、通信部２４と協働して情報通信部２１５を実行し、役務依頼情報を送信した認証済み委託者端末３と、応募コマンドを送信した認証済み受託者端末４との間でのメッセージ送受信を行う情報交換スレッドを開設する（ステップＳ３２）。制御部２１は、情報交換スレッドを開設したならば、処理をステップＳ３３に移す。

情報交換スレッドは、一方の端末から受信したメッセージを記憶し、この記憶したメッセージをいずれかの端末からの要求に応じて送信する情報交換スレッド、一方の端末から受信したメッセージを他方の端末に送信する情報交換スレッド、一方の端末から受信したメッセージを所定時間ごとにいずれかの端末に送信する情報交換スレッド、等の既知の情報交換スレッドを用いるが、これらに限定されない。

情報交換スレッドは、役務依頼情報を送信した認証済み委託者端末３が記憶する委託者向け本人認証情報に基づき、応募コマンドを送信した認証済み受託者端末４に委託者が本人認証済であることを通知することが好ましい。また、情報交換スレッドは、応募コマンドを送信した認証済み受託者端末４が記憶する受託者向け本人認証情報に基づき、役務依頼情報を送信した認証済み委託者端末３に受託者が本人認証済であることを通知することが好ましい。本人認証済であることを通知することにより、委託者及び受託者は、互いが本人認証済であることを確認できる。したがって、委託者と受託者は、情報交換スレッドが示す役務依頼について、架空のマッチングであるリスクが大幅に軽減されているとわかる。これにより、当該委託者と当該受託者との間の相互信頼が深まり、役務依頼に関するコミュニケーションが促進される。

情報交換スレッドを開設することにより、制御部２１は、役務依頼情報を送信した認証済み委託者端末３と、応募コマンドを送信した認証済み受託者端末４との間でのメッセージ送受信を行うことができる。

［ステップＳ３３：メッセージ送受信処理］
制御部２１は、通信部２４と協働して情報通信部２１５を実行し、ステップＳ３２において開設した情報交換スレッドを用いて端末間で役務依頼に関するメッセージ（情報）を交換するメッセージ送受信処理を実行する（ステップＳ３３）。制御部２１は、メッセージ送受信が終了したら、情報交換処理を終了し、処理を図２のステップＳ４に移す。

メッセージ送受信処理が端末間で交換する情報は、特に限定されない。メッセージ送受信処理が端末間で交換する情報として、例えば、役務の内容、役務の所要時間、役務を行う場所、役務を行う日時、役務に対する報酬が挙げられる。メッセージ送受信処理が端末間で交換する情報の種類は、特に限定されない。メッセージ送受信処理が端末間で交換する情報の種類として、例えば、テキストデータ、画像データが挙げられる。メッセージ送受信処理が端末間で情報を交換する手段は、特に限定されない。メッセージ送受信処理は、端末間を中継することにより端末間で情報を交換してもよく、端末間で直接情報を交換する指令を各端末に送信することにより端末間で情報を交換してもよい。

メッセージ送受信処理を実行することにより、役務依頼を行った委託者と、応募コマンドを送信した受託者とは、役務依頼に関する情報を相互に通信し、コミュニケーションをとることができる。これにより、委託者と受託者は、役務の内容、役務の所要時間、役務を行う場所、役務を行う日時、役務に対する報酬等に関するコミュニケーションを行い、双方の必要に応じてこれらを当初送信された役務依頼のものから変更することもできる。

〔委託成立処理〕
図８は、ステップＳ４で行われる委託成立処理を行う手順を示すフローチャートの一例である。以下では、図８を参照しながら、図２のステップＳ４で行われる委託成立処理の好ましい手順についてより詳しく説明する。

［ステップＳ４１：決済情報を受信したか否かの判定］
まず、制御部２１は、通信部２４と協働して決済情報受信部２１６を実行し、認証済み委託者端末３から役務の提供に対する報酬についての決済情報を受信したか否かを判定する（ステップＳ４１）。制御部２１は、認証済み委託者端末３から決済情報を受信したならば、処理をステップＳ４２に移す。一方、制御部２１は、認証済み委託者端末３から決済情報を受信していないならば、委託成立処理を終了し、処理を図２のステップＳ５に移す。

決済情報は、決済情報により決済される役務依頼に対応する依頼情報を特定する情報を含むことが好ましい。決済情報の受信の有無を判定することにより、決済情報受信部２１６は、委託者が役務依頼の報酬を決済したか否かを判定できる。決済情報が対応する依頼情報を特定する情報を含むことにより、制御部２１は、委託者が複数の役務依頼を並行して送信している場合であっても、それぞれの役務依頼に対応する決済を独立して行える。

［ステップＳ４２：認証済み受託者端末に採用通知情報を送信］
続いて、制御部２１は、通信部２４と協働して依頼成立情報送信部２１７を実行し、認証済み受託者端末４に受託者を採用することを通知する採用通知情報を送信する。認証済み受託者端末４に採用通知情報を送信すると、制御部２１は、委託成立処理を終了し、処理を図２のステップＳ５に移す。

採用通知情報に含まれる情報は、特に限定されない。採用通知情報は、受託者が受託する役務依頼に関する情報を含むことが好ましい。役務依頼に関する情報は、例えば、役務の内容、役務の所要時間、役務を行う場所、役務を行う日時、役務に対する報酬が挙げられる。

受託者端末４に採用通知情報が送信されることにより、受託者は、依頼が成立したことを確認できる。また、図８が示すように、この採用通知情報は、ステップＳ４１において決済情報を受信した場合にのみ送信される。このため、委託者から受託者に支払われる報酬は、役務マッチング支援サーバ２の管理者に一時的に預けられた状態におかれ、その上で受託者が委託者に役務を提供することになる。したがって、委託者の規模の大小に関わらず、委託者から受託者への報酬の未払いを確実に抑えられる。また、採用通知情報が、受託者が受託する役務依頼に関する、役務の内容、役務の所要時間、役務を行う場所、役務を行う日時、役務に対する報酬等を含むことにより、受託者の役務依頼に関する情報の把握が促され、役務提供の質の向上につながる。

〔相互評価処理〕
図９は、ステップＳ５で行われる相互評価処理を行う手順を示すフローチャートの一例である。以下では、図９を参照しながら、図２のステップＳ５で行われる相互評価処理の好ましい手順についてより詳しく説明する。

［ステップＳ５１：認証済み委託者端末から受託者による役務の質の評価を受信したか否かの判定］
まず、制御部２１は、通信部２４と協働して第１評価情報受信部２１８を実行し、認証済み委託者端末３から受託者による役務の質の評価を受信したか否かを判定する（ステップＳ５１）。制御部２１は、認証済み委託者端末３から受託者による役務の質の評価を受信したならば、処理をステップＳ５２に移す。一方、制御部２１は、認証済み委託者端末３から受託者による役務の質の評価を受信していないならば、処理をステップＳ５３に移す。

受託者による役務の質の評価に含まれる情報は、委託者が受託者による役務の質を評価するものであれば、特に限定されない。例えば、受託者による役務の質を５〜１の数字で評価するもの、受託者による役務の質を１０点満点の点数で評価するもの、受託者による役務の質を「優・良・可・不可」から選択して評価するもの、受託者による役務の質を「あいさつ」「スピード」「仕上げ」等の項目ごとに評価するもの、が挙げられる。

認証済み委託者端末３から受託者による役務の質の評価の受信の有無を判定することにより、制御部２１は、認証済み委託者端末３から受託者による役務の質の評価を受信した場合に、受託者による役務の質の評価を登録（記憶）できる。

［ステップＳ５２：受託者による役務の質の評価の登録］
制御部２１は、受信した受託者による役務の質の評価を記憶部２３に登録（記憶）する（ステップＳ５２）。受信した受託者による役務の質の評価を記憶部２３に登録（記憶）すると、制御部２１は、処理をステップＳ５５に移す。

受託者による役務の質の評価は、受託者による役務の質の評価を登録（記憶）する独立したテーブルに登録（記憶）してもよく、役務情報を記憶するテーブルに登録（記憶）してもよい。また、受託者による役務の質の評価は、図６のように受託者による委託者についての評価と同じテーブルに登録（記憶）してもよい。図６は、受託者による役務の質の評価を記憶可能に構成された役務情報テーブル２３２の一例である。第１評価が示す列に、受託者による役務の質の評価が、役務情報を区別するＩＤと紐付けられて記憶される。ＩＤ：１が示す行は、委託者「佐藤花子」が依頼した「家具組み立て」という内容の役務に対する、受託者「虎龍運歩」による役務の提供に対して、この委託者が「優」という受託者による役務の質の評価を行ったことを示している。

委託者が受託者による役務の質を評価するステップを行うことと、この評価を登録して参照可能とすることとは、受託者による役務の質を高めることに繋がりうる。また、役務情報テーブル２３２を受託者による役務の質の評価を登録（記憶）可能に構成することにより、制御部２１は、受託者による役務の質の評価を役務情報テーブル２３２に登録（記憶）できる。また、これにより、受託者による役務の質の評価を、役務情報と紐つけて参照することが容易となる。

［ステップＳ５３：認証済み受託者端末から委託者についての評価を受信したか否かの判定］
図９に戻る。制御部２１は、通信部２４と協働して第２評価情報受信部２１９を実行し、認証済み受託者端末４から受託者による委託者についての評価を受信したか否かを判定する（ステップＳ５３）。制御部２１は、認証済み受託者端末４から委託者についての評価を受信したならば、処理をステップＳ５４に移す。一方、制御部２１は、認証済み受託者端末４から委託者についての評価を受信していないならば、相互評価処理を終了し、処理を図２のステップＳ６に移す。

委託者についての評価に含まれる情報は、受託者が委託者について評価するものであれば、特に限定されない。例えば、委託者を５〜１の数字で評価するもの、委託者を１０点満点の点数で評価するもの、委託者を「優・良・可・不可」から選択して評価するもの、委託者を「仕事内容」「報酬」「人柄」等の項目ごとに評価するもの、が挙げられる。

認証済み受託者端末４から委託者についての評価の受信の有無を判定することにより、制御部２１は、認証済み受託者端末４から委託者についての評価を受信した場合に、委託者についての評価を登録できる。

［ステップＳ５４：委託者についての評価の登録］
制御部２１は、受信した委託者についての評価を記憶部２３に登録（記憶）する（ステップＳ５４）。受信した委託者についての評価を記憶部２３に登録（記憶）すると、制御部２１は、処理をステップＳ５５に移す。

委託者についての評価は、委託者についての評価を登録（記憶）する独立したテーブルに登録（記憶）してもよく、役務情報を記憶するテーブルに登録（記憶）してもよい。また、委託者による役務の質の評価と同じテーブルに登録（記憶）してもよい。図６は、委託者についての評価を登録（記憶）可能に構成された役務情報テーブル２３２の一例である。第２評価が示す列に、委託者についての評価が、役務情報を区別するＩＤと紐付けられて登録（記憶）される。ＩＤ：１が示す行は、委託者「佐藤花子」が依頼した「家具組み立て」という内容の、報酬「３０００円」の役務について、この受託者が「優」という委託者についての評価を行ったことを示している。

受託者が委託者についての評価するステップを行うことと、この評価を登録（記憶）して参照可能とすることとは、委託者の質を高めることに繋がりうる。また、役務情報テーブル２３２を委託者についての評価を登録（記憶）可能に構成することにより、制御部２１は、委託者についての評価を役務情報テーブル２３２に登録（記憶）できる。これにより、委託者についての評価を役務情報と紐つけて参照することが容易となる。

［ステップＳ５５：受託者による役務の質の評価、受託者についての評価のいずれもが登録されているか否かの判定］
図９に戻る。制御部２１は、通信部２４と協働して報酬支払情報送信部２２０を実行し、受託者による役務の質の評価、受託者についての評価のいずれもが登録されているか否かを判定する（ステップＳ５６）。制御部２１は、受託者による役務の質の評価、受託者についての評価のいずれもが登録されているならば、処理をステップＳ５６に移す。一方、制御部２１は、受託者による役務の質の評価、受託者についての評価のいずれかあるいは両方が登録されていないならば、相互評価処理を終了し、処理を図２のステップＳ６に移す。受託者による役務の質の評価、受託者についての評価のいずれもが登録されているか否かを判定することにより、制御部２１は、受託者による役務の質の評価、受託者についての評価のいずれもが登録されている場合に、報酬支払情報を送信できる。

［ステップＳ５６：認証済み受託者端末に報酬支払情報を送信］
制御部２１は、通信部２４と協働して報酬支払情報送信部２２０を実行し、認証済み受託者端末４に役務に対する報酬の支払についての報酬支払情報を送信する。報酬支払情報を送信すると、制御部２１は、相互評価処理を終了し、処理を図２のステップＳ６に移す。

報酬支払情報は、特に限定されない。報酬支払情報は、報酬の金額、報酬の受け取り方法の列挙を含むことが好ましい。また、報酬支払情報は、受託者が報酬の支払を希望することを伝える報酬希望コマンドの送信に必要な情報を含むことが好ましい。報酬希望コマンドの送信に必要な情報として、例えば、役務マッチング支援サーバ２に報酬希望コマンドを送信するＵＲＬ等が挙げられる。

報酬支払情報送信部２２０が認証済み受託者端末４に報酬支払情報を送信することにより、受託者は、相互評価が行われ、役務提供に対する報酬が支払われることを確認できる。

〔報酬支払処理〕
図１０は、ステップＳ６で行われる報酬支払処理を行う手順を示すフローチャートの一例である。以下では、図１０を参照しながら、図２のステップＳ６で行われる報酬支払処理の好ましい手順についてより詳しく説明する。

［ステップＳ６１：認証済み受託者端末から報酬希望コマンドを受信したか否かの判定］
制御部２１は、通信部２４と協働して所定情報受信部２２１を実行し、認証済み受託者端末４から受託者が報酬の支払を希望することを伝える報酬希望コマンドを受信したか否かを判定する（ステップＳ６１）。制御部２１は、認証済み受託者端末４から報酬希望コマンドを受信したならば、処理をステップＳ６２に移す。一方、制御部２１は、認証済み受託者端末４から報酬希望コマンドを受信していないならば、制御部２１は、報酬支払処理を終了し、処理をステップＳ１に戻し、ステップＳ１〜Ｓ６を繰り返す。

報酬希望コマンドに含まれる情報は、特に限定されない。例えば、報酬の受け取り方法として、ＡＴＭからの現金引出を希望する旨の情報や、自ら保有する金融機関の口座への振り込みを希望する旨の情報、モバイル決済等に代表される電子決済システムへの入金を希望する旨の情報等が挙げられる。

報酬希望コマンドの受信の有無を判定することにより、制御部２１は、認証済み受託者端末４から報酬希望コマンドを受信した場合に、報酬受取に必要な情報を送信するかどうかを判定できる。

［ステップＳ６２：認証済み受託者端末に報酬受取に必要な情報を送信］
制御部２１は、通信部２４と協働して報酬受取情報送信部２２２を実行し、認証済み受託者端末４に報酬受取情報を送信する（ステップＳ６２）。報酬受取情報は、特に限定されない。例えば、現金自動預払機（Ａｕｔｏｍａｔｅｄ Ｔｅｌｌｅｒ Ｍａｃｈｉｎｅ，以下「ＡＴＭ」ともいう。）から現金を引き出すために必要な引き出し番号の情報、金融機関の口座への振込予定日及び振込予定額に関する情報、受託者が所有する電子決済システムへの入金予定日及び入金予定額に関する情報等が挙げられる。報酬受取情報を送信すると、制御部２１は、報酬支払処理を終了し、処理をステップＳ１に戻し、ステップＳ１〜Ｓ６を繰り返す。

報酬希望コマンドの受信に対応して報酬受取情報を送信することにより、委託者から受託者への報酬の支払いを迅速かつ確実に行うことができる。このため、委託者と受託者との双方がよりいっそう安心して利用可能なサーバを提供できる。

＜役務マッチング支援サーバの使用例＞
続いて、必要に応じて図１１および図１２を参照しながら、本実施形態における役務マッチング支援サーバ２の使用例を説明する。

本実施形態によると、役務マッチング支援サーバ２は、ネットワーク５を介し、委託者端末３及び受託者端末４と接続可能に構成されている。

〔ユーザ情報登録〕
委託者は、役務マッチング支援サーバ２による役務マッチング支援を受ける際に、まず、ユーザ情報の登録を行う。委託者は、委託者端末３を介して役務マッチング支援サーバ２に委託者の身分証明情報を送信する。制御部２１は、委託者の身分証明情報を受信すると、委託者身分情報受信部２１１を実行し、委託者向け本人認証情報を本人認証情報テーブル２３１に記憶する。そして、制御部２１は、第１認証情報送信部２１３を実行し、委託者端末３に委託者向け本人認証情報を送信する。そして、委託者端末３は、委託者向け本人認証情報を送信された認証済み委託者端末３となる。委託者がユーザ情報を登録して委託者端末３が認証済み委託者端末３となることにより、委託者は、認証済み委託者端末３を介して、役務依頼を行う等の役務マッチング支援サーバ２を介した役務マッチング支援を受けられる。

受託者は、役務マッチング支援サーバ２による役務マッチング支援を受ける際に、まず、ユーザ情報の登録を行う。受託者は、受託者端末４を介して役務マッチング支援サーバ２に受託者の身分証明情報を送信する。制御部２１は、受託者身分情報受信部２１２を実行し、受託者向け本人認証情報を本人認証情報テーブル２３１に記憶する。そして、制御部２１は、第２認証情報送信部２１４を実行し、受託者端末４に受託者向け本人認証情報を送信する。そして、受託者端末４は、受託者向け本人認証情報を送信された認証済み受託者端末４となる。受託者がユーザ情報を登録して受託者端末４が認証済み受託者端末４となることにより、受託者は、認証済み受託者端末４を介して、役務依頼への応募を行う等の役務マッチング支援サーバ２を介した役務マッチング支援を受けられる。

〔委託者による役務依頼〕
役務依頼を行う委託者は、認証済み委託者端末３を介して役務マッチング支援サーバ２に役務依頼を送信する。制御部２１は、情報通信部２１５を実行し、役務依頼を受信し、役務依頼情報テーブル２３２に受信した役務依頼情報を登録する。そして、制御部２１は、通信部２４と協働して情報通信部２１５を実行し、認証済み受託者端末４に役務依頼情報を表示させる指令を送信する。

図１１は、上述の指令を受信した認証済み受託者端末４の表示部４４における、役務依頼情報の表示例である。表示部４４の上部の「依頼募集中」は、受託者を募集する役務依頼の表示であることを示す。「依頼募集中」の下には、「花見」「引っ越し手伝い」「犬散歩」「買い出し」「荷下ろし」「家具組み立て」で示される役務依頼が表示されている。受託者は、上述の役務依頼から興味をもった１つを選択する。図１１では、受託者は、「家具組み立て」に興味をもち、これを選択している（図１１では、網掛けで示している）。受託者は、表示部４４の下部に表示された「この依頼に応募する」を操作することで役務依頼に応募する応募コマンドを送信する。

図１１に示す役務依頼情報の表示例は、あくまで一例であり、役務依頼情報を表示する手段は、図１１に示す例に限定されない。認証済み受託者端末４に役務依頼情報が表示されることにより、受託者は、役務依頼に応募できる。表示部４４の上部に「依頼募集中」と表示されるため、受託者は、役務依頼を行う受託者が募集されていることがわかる。「依頼募集中」の下に役務依頼が表示されるため、受託者は、受託者を募集している役務依頼とその内容を知ることができる。表示部４４の下部に役務依頼に応募するための操作ボタンが「この依頼に応募する」と表示されるため、受託者は、直感的な操作で役務依頼に応募できる。

情報通信部２１５が、認証済み委託者端末３から役務依頼を受信し、認証済み受託者端末４に役務依頼情報を表示させる指令を送信することにより、受託者は、受託者を募集している役務依頼を閲覧することができる。そして、受託者は、受託者が興味を持った役務依頼を選択し、応募できる。

〔受託者による応募と委託の成立〕
役務依頼に応募する受託者は、認証済み受託者端末４を介して役務マッチング支援サーバ２に応募コマンドを送信する。制御部２１は、情報通信部２１５を実行し、応募コマンドを受信し、役務依頼情報を送信した認証済み委託者端末３と、応募コマンドを送信した認証済み受託者端末４との間での情報交換スレッドを開設し、メッセージ送受信処理を行う。

図１２は、このメッセージ送受信処理によって送受信されたメッセージの、認証済み委託者端末３の表示部３４における表示例である。表示部３４の上部には、委託者を示すアイコンが表示され、その右側の吹き出し内部に委託者が送信した役務依頼に関するメッセージ（図１２では横線に簡略化して示す）が委託者を示すアイコンに対応して表示されている。そのすぐ下には、受託者を示すアイコンが表示され、その左側の吹き出し内部に受託者が送信した役務依頼に関するメッセージ（図１２では横線に簡略化して示す）が受託者を示すアイコンに対応して表示されている。そして、これらがメッセージの送受信に対応して繰り返される。

情報交換スレッドを開設してメッセージ送受信処理を行うことにより、役務依頼を行った委託者と、応募コマンドを送信した受託者とは、認証済み委託者端末３および認証済み受託者端末４を介して役務依頼に関するメッセージ（情報）を相互に通信し、コミュニケーションを行うことができる。これにより、委託者と受託者は、役務の内容、役務の所要時間、役務を行う場所、役務を行う日時、役務に対する報酬等に関するコミュニケーションを行い、双方の必要に応じてこれらを当初送信された役務依頼のものから変更することもできる。委託者又は受託者を示すアイコンとメッセージとを対応づけて表示することにより、委託者及び受託者は、メッセージの送信者を区別することができる。アイコンを用いることにより、委託者及び受託者は、テキストのみでメッセージの送信者を示す場合と比べて、メッセージの送信者をより親しみやすいものとして感じることができる。メッセージを吹き出し内部に表示することにより、委託者及び受託者は、それぞれのメッセージの区切りを容易に判別できる。

上述のメッセージ送受信が終わると、委託者は、応募した受託者に役務依頼を委託するか否かを決定する。応募した受託者に役務依頼を委託する委託者は、役務に対する報酬を決済し、認証済み委託者端末３を介して役務マッチング支援サーバ２に決済情報を送信する。制御部２１は、決済情報受信部２１６を実行し、この決済情報を受信する。そして、制御部２１は、依頼成立情報送信部２１７を実行し、認証済み受託者端末４に依頼成立情報を送信する。

決済情報受信部２１６が認証済み委託者端末３から決済情報を受信し、受信依頼成立情報送信部２１７が認証済み受託者端末４に依頼成立情報を送信することにより、依頼成立前に、委託者から受託者に支払われる報酬は、役務マッチング支援サーバ２の管理者に一時的に預けられた状態におかれ、その上で受託者が委託者に役務を提供することになる。したがって、委託者の規模の大小に関わらず、委託者から受託者への報酬の未払いを確実に抑えられる。

〔役務の提供〕
依頼が成立すると、受託者は、上述の役務依頼及び委託者とのコミュニケーションに基づき、委託者に役務を提供する。
〔相互評価および報酬支払〕

役務の提供後に、委託者と受託者は、役務マッチング支援サーバ２を介した相互評価を行う。委託者は、認証済み委託者端末３を介して役務マッチング支援サーバ２に受託者による役務の質の評価を送信する。制御部２１は、第１評価情報受信部２１８を実行し、受託者による役務の質の評価を受信する。受託者は、認証済み受託者端末４を介して役務マッチング支援サーバ２に委託者についての評価を送信する。制御部２１は、第２評価情報受信部２１８を実行し、委託者についての評価を受信する。

委託者と受託者による相互評価が行われると、制御部２１は、報酬支払情報送信部２２０を実行し、認証済み受託者端末４に報酬支払について伝える報酬支払情報を送信する。報酬支払情報が送信された後に、受託者は、認証済み受託者端末４を介して役務マッチング支援サーバ２に報酬の支払を求める報酬希望コマンドを送信する。制御部２１は、所定情報受信部２２１を実行し、報酬希望コマンドを受信する。制御部２１は、報酬希望コマンドを受信すると、報酬受取情報送信部２２２を実行し、認証済み受託者端末４に、報酬受取情報を送信する。

このように、役務提供後に相互評価するステップを踏まえることで、受託者による役務の質と、委託者の質との両方を高めることに繋がり得る。また、役務マッチング支援サーバ２が報酬希望コマンドの受信に対応して報酬受取情報を送信することにより、委託者から受託者への報酬の支払いを迅速かつ確実に行うことができる。このため、委託者と受託者との双方がよりいっそう安心して利用可能なサーバを提供できる。

本実施形態に記載の役務マッチング支援サーバ２によると、委託者身分情報受信部２１１と受託者身分情報受信部２１２が身分証明情報を受信するため、役務マッチング支援サーバ２の管理者は、委託者と受託者それぞれの所在を確実に追うことができる。これにより、委託者の規模の大小に関わらず、委託者から受託者に対して正当な報酬が確実に支払われる。また、これにより、架空のマッチングが行われるリスクを大幅に軽減できる。そして、情報通信部２１５が情報交換スレッドを開設してメッセージ送受信処理を行うため、委託者と受託者は、互いに本人認証済である端末間で役務依頼に関するコミュニケーションをとることが可能である。よって、本実施形態に記載の役務マッチング支援サーバ２によれば、委託者と受託者との双方がより安心して利用可能なサーバを提供できる。

さらに、本実施形態に記載の役務マッチング支援サーバ２によれば、依頼成立情報送信部２１７は、認証済み委託者端末３から決済情報が受信された場合に、認証済み受託者端末４に依頼成立情報を送信する。これにより、委託者から受託者に支払われる報酬は、役務マッチング支援サーバ２の管理者に一時的に預けられた状態におかれ、その上で受託者が委託者に役務を提供することになる。したがって、委託者の規模の大小に関わらず、委託者から受託者への報酬の未払いを確実に抑えられる。

また、本実施形態に記載の役務マッチング支援サーバ２によれば、委託者は、受託者による役務の質の評価を行い、受託者は、委託者についての評価を行い、双方の評価を役務マッチング支援サーバ２が受信した場合に、役務マッチング支援サーバ２の報酬支払情報送信部２２０は、認証済み受託者端末４に報酬支払情報を送信する。役務提供後に相互評価するステップを踏まえることで、受託者による役務の質と、委託者の質との両方を高めることに繋がり得る。

また、本実施形態に記載の役務マッチング支援サーバ２によれば、所定情報受信部２２１は、報酬希望コマンドを受信する。そして、報酬受取送信部２２２は、認証済み受託者端末４に報酬受取情報を送信する。これにより、委託者から受託者への報酬の支払いを迅速かつ確実に行うことができるため、委託者と受託者との双方がよりいっそう安心して利用可能なサーバを提供できる。

よって、本実施形態に記載の役務マッチング支援サーバ２によれば、委託者と受託者との双方がよりいっそう安心して利用可能なサーバを提供できる。

＜変形例＞
以下、本実施形態に記載の発明における種々の変形例を例示する。

〔変形例１〕
本実施形態では、認証済み委託者端末３は、複数の委託者のそれぞれについて設けられる。そこで、役務マッチング支援サーバ２は、これら複数の認証済み委託者端末３から、受託者の人数に関する情報を受信する受託者数情報受信部と、これら複数の委託者端末３のうち、委託者の属性情報が同一又は類似する認証済み委託者端末３間において、一方の委託者側では受託者の人数が過剰であり、他方の委託者側では受託者の人数が不足である場合に、一方の委託者及び他方の委託者の認証済み委託者端末３に、一方の委託者が委託する受託者の一部を一方の委託者から前記他方の委託者に派遣することを示す派遣情報を送信する派遣情報送信部と、をさらに有していてもよい。

本変形例では、受託者の人数に関する情報は、委託者側で過剰である（派遣可能である）受託者の人数を含むことが好ましい。また、委託者の属性情報は、委託者の役務提供エリア、委託者の業種、等を含むことが好ましい。また、本変形例では、記憶部２３は、委託者の属性情報を記憶する委託者情報テーブルを有することが好ましい。図１３は、変形例１に係る委託者情報テーブルの一例である。図１３の委託者情報テーブルは、委託者情報を判別するＩＤと、委託者の名称を記憶する委託者名と、委託者の役務提供エリアを記憶するエリアと、委託者の業種を記憶する業種と、委託者側で過剰である（派遣可能である）受託者の人数と、を含む。例えば、ＩＤ：１が示す行には、「Ａ丼品川」という名称の委託者が、「品川エリア」で役務提供を行っており、その業種が「飲食店」であり、「１０」人の受託者が派遣可能であることが示されている。また、ＩＤ：２が示す行には、「Ｂステーキ品川」という名称の委託者が、「品川エリア」で役務提供を行っており、その業種が「飲食店」であり、「１５」人の受託者が派遣可能であることが示されている。

図１３の委託者情報テーブルを用いて、本変形例における派遣情報の送信の流れの一例を示す。ここでは、ＩＤ：１の「Ａ丼品川」という名称の委託者において、受託者が２人不足した場合の流れを示す。制御部２１は、受託者数情報受信部を実行して、「Ａ丼品川」の受託者が２人不足したという情報を受信する。そして、制御部２１は、派遣情報送信部を実行して、委託者の属性情報である「エリア」と「業種」を参照して、同一の属性情報である「品川エリア」と「飲食店」を有している、ＩＤ：２の「Ｂステーキ品川」と、ＩＤ：５の「Ａサンド品川」と、を選択する。そして、派遣情報送信部は、「Ｂステーキ品川」と「Ａサンド品川」との派遣可能な受託者の人数を参照し、いずれかの委託者側に派遣可能な受託者がいれば、派遣可能な受託者がいる委託者の認証済み委託者端末３から「Ａ丼品川」の認証済み委託者端末３へ、派遣情報を送信する。この例では「Ｂステーキ品川」の派遣可能な受託者の人数は「１５」、「Ａサンド品川」の派遣可能な受託者の人数は「８」である。したがって、「Ｂステーキ品川」と「Ａサンド品川」の双方に派遣可能な受託者がいるから、「Ｂステーキ品川」と「Ａサンド品川」のいずれか、あるいは両方の認証済み委託者端末３から、派遣情報を送信できる。派遣情報を送信する委託者を選択する手段は、特に限定されない。受託者の人数の過剰がより大きい方から派遣情報を送信してもよいし、なるだけ多くの受託者の人数の過剰である委託者から派遣情報が送信されるよう複数の委託者を選択して送信してもよい。

委託者情報テーブルは、さらに、特定報酬支払情報を送信する対象を示す特定決済情報を含んでいてもよい。特定決済情報は、派遣された受託者を管理する一方の認証済み委託者端末３に特定報酬支払情報を送信するか、派遣された受託者の認証済み受託者端末４に特定報酬支払情報を送信するか、を示す情報を含む。図１３のＩＤ：１の行では、派遣された受託者を管理する委託者「Ａ丼品川」が特定決済情報「直払い」によって、派遣された受託者の認証済み受託者端末４に特定報酬支払情報を送信するよう他方の委託者に求めることを示している。ＩＤ：２の行では、派遣された受託者を管理する委託者「Ｂステーキ品川」が特定決済情報「店払い」によって、「Ｂステーキ品川」が管理する認証済み委託者端末３に特定報酬支払情報を送信するよう他方の委託者に求めることを示している。

委託者情報テーブルは、さらに店舗の系列情報を含んでいてもよい。再び図１３の委託者情報テーブルを用いて、店舗の系列情報を利用する派遣情報の送信の流れの一例を示す。ここでは、先ほどと同様に、ＩＤ：１の「Ａ丼品川」という名称の委託者において、受託者が２人不足した場合の流れを示す。制御部２１は、派遣情報送信部を実行して、委託者の属性情報である「エリア」と「業種」に加えて「系列情報」も参照して、同一の属性情報である「品川エリア」と「飲食店」と「Ａグループ」を有している、ＩＤ：５の「Ａサンド品川」を選択する。先ほどの例で選択されたＩＤ：２の「Ｂステーキ品川」は、系列情報が「Ｂグループ」であり、「Ａ丼品川」の系列情報「Ａグループ」と一致しないため選択されない。そして、同一の属性情報を有し、受託者の人数が過剰である委託者「Ａサンド品川」の認証済み委託者端末３から、受託者の人数が不足する委託者「Ａ丼品川」の認証済み委託者端末３へ、派遣情報が送信される。

変形例１に係る役務マッチング支援サーバ２によると、受託者数情報受信部と、派遣情報送信部とを備えることにより、委託者の属性情報が同一又は類似する認証済み委託者端末３間において、受託者の人数が過剰である一方の委託者から、受託者の人数が不足である他方の委託者に向けて、一方の委託者が委託する受託者の一部を派遣することができる。上述の例では、同じ品川エリアで役務提供を行う飲食店の間で、過剰である受託者の一部を、受託者が不足している委託者「Ａ丼品川」へ派遣している。委託者にとっては、適正な数の人員をできるだけ少ないコストで確保できる点で安心できる。受託者にとっても、急な休みや、急な役務提供といった事態を防ぐことができるため、報酬を確実に確保しつつ、自分の時間も確保でき、ワークライフバランスに優れるといった点で安心できる。

また、受託者数情報受信部が受信する受託者の人数に関する情報が、委託者側で過剰である（派遣可能である）受託者の人数を含むことにより、受託者数情報受信部は、委託者側で過剰であり、派遣可能である受託者の人数を受信できる。

委託者情報テーブルにＩＤが記憶されていることにより、派遣情報送信部は、委託者情報テーブルに格納される多数の委託者情報から特定の委託者情報を特定し、取得できる。委託者情報テーブルに委託者名が記憶されていることにより、派遣情報送信部は、委託者名による委託者情報の特定と取得が可能となる。委託者情報テーブルにエリアが記憶されていることにより、派遣情報送信部は、委託者の属性情報として委託者の役務提供エリアを利用できる。委託者情報テーブルに業種が記憶されていることにより、派遣情報送信部は、委託者の属性情報として委託者の業種を利用できる。委託者情報テーブルに受託者の人数が記憶されていることにより、派遣情報送信部は、委託者側で過剰であり、すなわち、派遣可能である受託者の人数を利用できる。

委託者情報テーブルが特定決済情報を含むことにより、特定決済情報が特定報酬支払情報の送信先を示して、報酬支払の遅滞リスクを軽減できる。したがって、委託者と受託者との双方がよりいっそう安心して利用可能なサーバを提供できる。

委託者情報テーブルが店舗の系列情報を含むことにより、派遣情報送信部は、複数の認証済み委託者端末３について、委託者が所属する店舗の系列情報が同一であるかどうかを判別できる。そして、派遣情報送信部は、複数の認証済み委託者端末３のうち、委託者が所属する店舗の系列情報が同一の認証済み委託者端末３の間において、派遣情報の送信を行う。これにより、委託者は、地域を絞って集中的に出店するドミナント戦略を構築でき、適正な数の人員をできるだけ少ないコストで確保し、同一商圏内で市場占有率を向上させて独占状態を目指すことが可能になる。また、受託者にとっても、急な休みや、急な役務提供といった事態を防ぐことができるため、報酬を確実に確保しつつ、自分の時間も確保でき、ワークライフバランスに優れるといった点で安心できる。

よって、本変形例の役務マッチング支援サーバ２によれば、委託者と受託者との双方がよりいっそう安心して利用可能なサーバを提供できる。

〔変形例２〕
本変形例では、役務マッチング支援サーバ２は、委託者と受託者との間で依頼が成立した場合に、認証済み受託者端末４に、受託者の居住地から受託者による役務提供場所までのアクセス情報を送信するアクセス情報送信部をさらに備える。

アクセス情報送信部が送信するアクセス情報の種類は、特に限定されない。アクセス情報として、例えば、道案内の目印となるランドマークを用いて受託者の居住地から受託者による役務提供場所までの道案内を行うテキスト、受託者の居住地から受託者による役務提供場所までの道順が記載された地図、受託者の居住地の最寄り駅から受託者による役務提供場所の最寄り駅までの乗換案内、受託者端末４に地図アプリケーションを実行させ、受託者の居住地から受託者による役務提供場所までの道順を表示させる指令、等が挙げられる。

アクセス情報送信部を備えることにより、受託者は、サーバから送信されたアクセス情報を利用して、受託者の居住地から受託者による役務提供場所まで迷わずに移動できる。委託者にとっては、受託者が遅刻するリスクを防ぐことができ、より適正な人員配置が可能になる点で安心できる。受託者にとっては、道に迷うことによって生じるストレスを軽減でき、また、遅刻等によって予定の報酬より少なくなってしまうリスクを軽減できる点で安心できる。

よって、本変形例の役務マッチング支援サーバ２によれば、委託者と受託者との双方がよりいっそう安心して利用可能なサーバを提供できる。

〔変形例３〕
本変形例では、役務マッチング支援サーバ２は、認証済み受託者端末４から前記受託者による役務提供の開始時刻及び終了時刻を受信する時間情報受信部と、報酬が都度払いである場合、終了時刻を受信したことに応じて、委託者と受託者との間で交わされた報酬単価情報と開始時刻と終了時刻とに基づいて委託者から受託者への都度払い報酬を算出する都度払い報酬算出部と、をさらに備える。

本変形例における役務情報テーブル２３２は、報酬単価情報、開始時刻、終了時刻、支払方法、をさらに含むことが好ましい。図１４は、変形例３に係る役務情報テーブル２３２の一例である。図１４が示す役務情報テーブル２３２は、報酬単価情報を示す役務時給、支払方法、開始時刻、終了時刻を含んでいる。ＩＤ：１の行は、委託者「佐藤花子」が依頼した役務について、役務時給が「１２００円」であり、支払方法が都度払いのうちの「日払い」であり、受託者が「１０：０３」から「１１：０３」にかけて、役務を提供したことが記憶している。開始時刻および終了時刻が時刻に加えて日付も含むことも、好ましい。

図１４のＩＤ：１の行を用いて、本変形例における役務提供と報酬支払の流れの一例を示す。図２の「委託成立処理」で都度払いによる役務依頼の委託が成立すると、受託者「虎龍運歩」は、「１０：０３」に役務の提供を開始する。制御部２１は、時間情報受信部を実行し、受託者「虎龍運歩」の認証済み受託者端末４から「１０：０３」に役務提供を始めたという時間情報を受信する。そして、時間情報受信部は、図１４の役務情報テーブル２３２の「ＩＤ：１」の行に、開始時刻「１０：０３」を記憶する。受託者「虎龍運歩」は、「１１：０３」に役務の提供を終了する。制御部２１は、時間情報受信部を実行し、受託者「虎龍運歩」の認証済み受託者端末４から「１１：０３」に役務提供を終えたという時間情報を受信する。そして、時間情報受信部は、図１４の役務情報テーブル２３２の「ＩＤ：１」の行に、終了時刻「１１：０３」を記憶する。制御部２１は、都度払い報酬算出部を実行し、図１４の役務情報テーブル２３２から、ＩＤ：１の支払方法が都度払いのうちの「日払い」であることを読み取り、開始時刻「１０：０３」と終了時刻「１１：０３」から、役務提供が行われた時間が１時間であることを算出し、この時間と役務時給「１２００円」から受託者への日払い報酬が「１２００円」であると算出する。そして、図２に示す処理の流れにしたがって図９の相互評価と図１０の報酬支払処理とが実行され、受託者は、日払い報酬「１２００円」を受け取る。

本変形例によれば、時間情報受信部と都度払い報酬算出部とを備えるため、委託者から受託者への報酬の支払いを、日払い等によって迅速かつ確実に行うことができる。これにより、委託者と受託者との双方がよりいっそう安心して利用可能なサーバを提供できる。

さらに、本変形例の役務マッチング支援サーバ２は、報酬が掛払いである場合、報酬単価情報と開始時刻と終了時刻とに基づき、掛払いの締め毎の掛払い報酬を算出する掛払い報酬算出部をさらに備えるよう構成することもできる。

掛払い報酬算出部を備える場合、役務情報テーブル２３２は、支払方法が週払い、月払いなどの掛払いであることを示す情報を格納可能であり、さらに、開始時刻と終了時刻との組を複数記憶するよう構成されることが好ましい。これら複数の開始時刻および終了時刻が時刻に加えて日付も含むことは、大変好ましい。図１４のＩＤ：２およびＩＤ：３は、開始時刻と終了時刻との組を複数含む例である。ＩＤ：２は、支払方法が「週払い」である役務依頼について、受託者「家中総司」が、掛払い報酬の締日「日曜」までの期間において、「１３：５９」〜「１５：５９」と「１４：００」〜「１５：３０」に役務を提供したことを記憶している。掛払い報酬算出部は、図１４の役務情報テーブル２３２に記憶された上述の開始時刻と終了時刻との複数の組から、受託者「家中総司」による期間内の役務の提供時間が２時間３０分間であることを算出し、この時間と役務時給「１０００円」から受託者への週払い報酬が「２５００円」であると算出する。また、図１４の役務情報テーブル２３２のＩＤ：３は、支払方法が「月払い」である役務依頼について、受託者「田奈久美子」が、掛払い報酬の締日である月の「末日」までの期間において、「９：００」〜「１０：００」と「８：５５」〜「９：５５」に役務を提供したことを記憶している。掛払い報酬算出部は、上述の開始時刻と終了時刻との複数の組から、受託者「田奈久美子」による期間内の役務の提供時間が２時間であることを算出し、この時間と役務時給「１１００円」から受託者への月払い報酬が「２２００円」であると算出する。

掛払い報酬算出部をさらに備えることにより、週払いや月払い等の掛払いにおいても、委託者から受託者への報酬の支払いを確実に行うことができるため、委託者と受託者との双方がよりいっそう安心して利用可能なサーバを提供できる。

以上、本発明の実施形態及び各種変形例について説明したが、本発明は上述したこれらの実施形態及び各種変形例に限るものではない。また、本発明の実施形態及び各種変形例に記載された効果は、本発明から生じる最も好適な効果を列挙したものに過ぎず、本発明による効果は、本発明の実施形態及び各種変形例に記載されたものに限定されるものではない。

また、上述した実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施の形態の構成の一部を他の実施の形態の構成に置き換えることが可能であり、また、ある実施の形態の構成に他の実施の形態の構成を加えることも可能である。

１ 役務マッチング支援システム
２ 役務マッチング支援サーバ
２１ 制御部
２１１ 委託者身分情報受信部
２１２ 受託者身分情報受信部
２１３ 第１認証情報送信部
２１４ 第２認証情報送信部
２１５ 情報通信部
２１６ 決済情報受信部
２１７ 依頼成立情報送信部
２１８ 第１評価情報受信部
２１９ 第２評価情報受信部
２２０ 報酬支払情報送信部
２２１ 所定情報受信部
２２２ 報酬受取情報送信部
２３ 記憶部
２３１ 本人認証情報テーブル
２３２ 役務情報テーブル
２４ 通信部
３ 委託者端末
３１ 制御部
３２ 記憶部
３３ 通信部
３４ 表示部
４ 受託者端末
４１ 制御部
４２ 記憶部
４３ 通信部
４４ 表示部
５ ネットワーク

Claims (10)

1. 役務の委託者端末から委託者の身分証明情報を受信する委託者身分情報受信部と、
   役務の受託者端末から受託者の身分証明情報を受信する受託者身分情報受信部と、
   前記委託者端末に委託者向け本人認証情報を送信する第１認証情報送信部と、
   前記受託者端末に受託者向け本人認証情報を送信する第２認証情報送信部と、
   前記委託者向け本人認証情報を有する前記委託者端末、及び前記受託者向け本人認証情報を有する前記受託者端末の間で、役務依頼に関する情報を相互に通信可能な情報通信部と、
   を備える、役務マッチング支援サーバ。
2. 前記委託者端末から決済情報を受信する決済情報受信部と、
   前記決済情報を受信した場合に、前記受託者端末に依頼成立情報を送信する依頼成立情報送信部と、
   前記委託者端末から、前記受託者による役務の質の評価を受信する第１評価情報受信部と、
   前記受託者端末から、前記委託者についての評価を受信する第２評価情報受信部と、
   前記第１評価情報受信部及び前記第２評価情報受信部により双方の評価が受信された場合に、前記受託者端末に報酬支払情報を送信する報酬支払情報送信部と、
   をさらに備える、請求項１に記載の役務マッチング支援サーバ。
3. 前記受託者端末から所定情報を受信する所定情報受信部と、
   前記所定情報を受信した場合、前記受託者端末に報酬受取情報を送信する報酬受取情報送信部と、
   をさらに備える、請求項２に記載の役務マッチング支援サーバ。
4. 前記委託者端末は、複数の委託者のそれぞれについて設けられ、
   前記複数の委託者端末から、前記受託者の人数に関する情報を受信する受託者数情報受信部と、
   前記複数の委託者端末のうち、前記委託者の属性情報が同一又は類似する委託者端末間において、一方の委託者側では受託者の人数が過剰であり、他方の委託者側では受託者の人数が不足である場合に、前記一方の委託者及び前記他方の委託者の委託者端末に、前記一方の委託者が委託する受託者の一部を前記一方の委託者から前記他方の委託者に派遣することを示す派遣情報を送信する派遣情報送信部と、
   をさらに備える、請求項１から３のいずれかに記載の役務マッチング支援サーバ。
5. 前記他方の委託者の委託者端末から特定決済情報を受信する特定決済情報受信部と、
   前記特定決済情報が受信された場合、前記一方の委託者の委託者端末、あるいは前記一方の委託者から前記他方の委託者に派遣された受託者の受託者端末に特定報酬支払情報を送信する特定報酬支払情報送信部と、
   をさらに備える、請求項４に記載の役務マッチング支援サーバ。
6. 前記属性情報は、店舗の系列情報を含み、
   前記派遣情報送信部は、前記複数の委託者端末のうち、前記委託者が所属する店舗の前記系列情報が同一の委託者端末間において、前記派遣情報の送信を行う、請求項４又は５に記載の役務マッチング支援サーバ。
7. 前記委託者と前記受託者との間で依頼が成立した場合に、前記受託者端末に、前記受託者の居住地から前記受託者による役務提供場所までのアクセス情報を送信するアクセス情報送信部をさらに備える、請求項１から６のいずれかに記載の役務マッチング支援サーバ。
8. 前記受託者端末から前記受託者による役務提供の開始時刻及び終了時刻を受信する時間情報受信部と、
   報酬が都度払いである場合、前記終了時刻を受信したことに応じて、前記委託者と前記受託者との間で交わされた報酬単価情報と前記開始時刻と前記終了時刻とに基づいて前記委託者から前記受託者への都度払い報酬を算出する都度払い報酬算出部と、
   をさらに備える請求項１から７のいずれかに記載の役務マッチング支援サーバ。
9. 報酬が掛払いである場合、前記報酬単価情報と前記開始時刻と前記終了時刻とに基づき、前記掛払いの締め毎の掛払い報酬を算出する掛払い報酬算出部をさらに備える請求項８に記載のマッチング支援サーバ。
10. 役務の委託者端末に、
    委託者の身分証明情報をサーバに送信させるステップと、
    前記サーバから委託者向け本人認証情報を受信させるステップと、
    を実行させ、
    役務の受託者端末に、
    受託者の身分証明情報をサーバに送信させるステップと、
    前記サーバから受託者向け本人認証情報を受信させるステップと、
    を実行させ、
    前記委託者向け本人認証情報を有する前記委託者端末、及び前記受託者向け本人認証情報を有する前記受託者端末に、
    双方の前記端末の間で、役務依頼に関する情報を相互に通信可能にするステップと、
    を実行させるためのプログラム。
    
    

Images