以下、図面を参照して、本発明の各実施形態について説明する。
(第1の実施形態)
図1は、本実施形態に係るマッチング装置を含むネットワークシステム(マッチングシステム)のハードウェア構成を示す図である。
図1に示すマッチングシステムは、主として、マッチング装置10及びユーザ端末21及び22を含む複数のユーザ端末を備える。
マッチング装置10は、例えばCPUのようなハードウェアプロセッサ10aを含むコンピュータ(サーバコンピュータ)及び当該プロセッサ10aによって利用され、当該プロセッサ10aと接続される記憶装置10bとを備える。この記憶装置10bは、例えばプロセッサ10aによって実行されるプログラムを格納する。
複数のユーザ端末の各々は、ユーザによって使用される、例えばスマートフォン及びタブレット端末等の携帯型端末機器を含む。複数のユーザ端末は、ネットワーク30を介してマッチング装置10と通信可能に接続される。
なお、以下の説明においては、ユーザ端末21を使用するユーザをユーザX(第1のユーザ)、ユーザ端末22を使用するユーザをユーザY(第2のユーザ)と称する。
本実施形態に係るマッチング装置10(を含むマッチングシステム)は、複数のユーザ端末の各々を使用する各ユーザを後述するイベントにおいてマッチングさせるために用いられる。
図2は、図1に示すマッチング装置10の主として機能構成を示すブロック図である。図2に示すように、マッチング装置10は、ユーザデータベース(DB)11、イベント生成部12、イベントデータベース13、マッチング処理部14、評価処理部15及び評価データベース(DB)16を含む。
本実施形態において、ユーザデータベース11、イベントデータベース13及び評価データベース16は、例えば上記した記憶装置10bに格納されている。また、本実施形態において、イベント生成部12、マッチング処理部14及び評価処理部15は、上記したプロセッサ10a(コンピュータ)がプログラムを実行すること(すなわち、ソフトウェア)によって実現されるものとする。なお、これらの各部12、14及び15は、ハードウェアによって実現されてもよいし、ハードウェアとソフトウェアとの組み合わせ構成によって実現されてもよい。
ユーザデータベース11には、マッチングシステムを利用する上記したユーザX及びユーザYを含む複数のユーザに関する情報(以下、ユーザ情報と表記)が格納される。なお、ユーザデータベース11に格納されるユーザ情報は、ユーザ毎に予め登録されている。
イベント生成部12は、例えばユーザ端末21に対するユーザXの操作に応じて、当該ユーザXによって企画されたイベント(を示す情報)を生成する。なお、イベント生成部12によって生成されるイベントは、ユーザX以外の他のユーザ(例えば、ユーザY)が参加する(つまり、ユーザX及びユーザYがマッチングされる)ことによって開催される。イベントとしては、上記したように複数のユーザをマッチングさせるものであればよく、例えば食事会マッチング、ネイリストマッチング及びゴルフコーチマッチング等が含まれる。
イベントデータベース(DB)13には、イベント生成部12によって生成されたイベントを示す情報(以下、イベント情報と表記)が格納される。
マッチング処理部14は、マッチングシステムを利用する複数のユーザ(例えば、ユーザX及びユーザY)をマッチングさせるための処理を実行する。マッチング処理部14は、ユーザデータベース11に格納されているユーザ情報及びイベントデータベース13に格納されているイベント情報に基づいて、例えばユーザXによって企画されたイベントをユーザYに対して通知することにより、当該ユーザX及びユーザYをマッチングさせる。この場合、ユーザYに対して通知されるイベント(例えば、ユーザXによって企画されたイベント)は、後述する評価データベース16に格納されている評価情報に基づいて特定される。なお、ユーザX及びユーザYがマッチングされるとは、例えばユーザXによって企画されたイベントにユーザYが参加する(つまり、ユーザX及びユーザYによって当該イベントが開催される)こと等を含む。
ここで、上記したように例えばユーザXによって企画されたイベントにユーザYが参加した場合、当該ユーザXは、ユーザ端末21を操作することによって、当該ユーザYに対する評価をすることができる。同様に、ユーザYは、ユーザ端末22を操作することによって、ユーザXに対する評価をすることができる。
評価処理部15は、例えばユーザXによるユーザYに対する評価を表す評価情報を評価データベース(DB)16に格納する。また、評価処理部15は、ユーザYによるユーザXに対する評価を示す評価情報を評価データベース16に格納する。なお、詳細については後述するが、評価データベース16に格納された評価情報は、上記したようにマッチング処理部14による処理に利用される。
なお、評価データベース16には、例えばユーザXと過去のイベントに参加した他のユーザによる当該ユーザXに対する評価を示す評価情報(第1の評価情報)及びユーザYと過去のイベントに参加した他のユーザによる当該ユーザYに対する評価を示す評価情報(第2の評価情報)が格納(蓄積)されている。評価データベース16には、ユーザX及びユーザY以外の他のユーザに対する評価を示す評価情報も格納されている。
図3は、図2に示すユーザデータベース11のデータ構造の一例を示す。ユーザデータベース11には、上記したようにマッチングシステムを利用するユーザ毎にユーザ情報が格納されている。
図3に示すように、ユーザ情報は、ユーザIDに対応づけてユーザ名、年齢、住所、カード情報及び条件等を含む。
ユーザIDは、ユーザを識別するための識別子である。ユーザ名は、対応づけられているユーザIDによって識別されるユーザのユーザ名(例えば、氏名等)を含む。
年齢は、対応づけられているユーザIDによって識別されるユーザの年齢を含む。住所は、対応づけられているユーザIDによって識別されるユーザの住所を含む。カード情報は、対応づけられているユーザIDによって識別されるユーザが所有するクレジットカードのカード番号及び有効期間等を含む。
条件は、対応づけられているユーザIDによって識別されるユーザによって指定された、マッチングに関する条件(タグ)を含む。条件には、例えばマッチングされるユーザの年齢及び住所等のユーザ情報に関する条件が含まれる。また、ユーザ情報に関する条件以外にも、条件には、例えばイベントが開催される場所及びその他の条件等が含まれていても構わない。
図3に示す例では、ユーザデータベース11には、ユーザ情報111〜113が格納されている。
ユーザ情報111は、ユーザID「11」に対応づけてユーザ名「ユーザX」、年齢「年齢1」、住所「住所1」、カード情報「カード情報1」及び条件「条件1」を含む。このユーザ情報111によれば、ユーザID「11」によって識別されるユーザのユーザ名が「ユーザX」であることが示されている。すなわち、上記したユーザ端末21を使用するユーザXを識別するためのユーザIDはユーザID「11」であり、ユーザ情報111は、ユーザXに関するユーザ情報である。ユーザ情報111によれば、ユーザXの年齢が「年齢1」であり、当該ユーザXの住所が「住所1」であり、当該ユーザXのカード情報が「カード情報1」であることが示されている。また、ユーザ情報111によれば、ユーザXによって指定されたマッチングに関する条件が「条件1」であることが示されている。
ユーザ情報112は、ユーザID「12」に対応づけてユーザ名「ユーザY」、年齢「年齢2」、住所「住所2」、カード情報「カード情報2」及び条件「条件2」を含む。このユーザ情報112によれば、ユーザID「12」によって識別されるユーザのユーザ名が「ユーザY」であることが示されている。すなわち、上記したユーザ端末22を使用するユーザYを識別するためのユーザIDはユーザID「12」であり、ユーザ情報112は、ユーザYに関するユーザ情報である。ユーザ情報112によれば、ユーザYの年齢が「年齢2」であり、当該ユーザYの住所が「住所2」であり、当該ユーザYのカード情報が「カード情報2」であることが示されている。また、ユーザ情報112によれば、ユーザYによって指定されたマッチングに関する条件が「条件2」であることが示されている。
ユーザ情報113は、ユーザID「13」に対応づけてユーザ名「ユーザZ」、年齢「年齢3」、住所「住所3」、カード情報「カード情報3」及び条件「条件3」を含む。このユーザ情報113によれば、ユーザID「13」によって識別されるユーザのユーザ名が「ユーザZ」であることが示されている。上記したユーザID「13」によって識別されるユーザをユーザZと称するものとすると、ユーザ情報113は、ユーザZに関するユーザ情報である。ユーザ情報113によれば、ユーザZの年齢が「年齢3」であり、当該ユーザZの住所が「住所3」であり、当該ユーザZのカード情報が「カード情報3」であることが示されている。また、ユーザ情報113によれば、ユーザZによって指定されたマッチングに関する条件が「条件3」であることが示されている。
ここでは、ユーザ情報111〜113についてのみ説明したが、他のユーザに関するユーザ情報についても同様である。
なお、図3に示す例ではユーザ情報がユーザID、ユーザ名、年齢、住所、カード情報及び条件を含むものとして説明したが、当該ユーザ情報は、例えば年収及び職業等の他の情報が含まれていても構わない。また、ユーザ情報は、例えばユーザの顔画像等を含んでいても構わない。
図4は、図2に示すイベントデータベース13のデータ構造の一例を示す。イベントデータベース13には、マッチングシステムを利用するユーザによって企画されたイベント毎に当該イベントを示す情報が格納されている。
図4に示すように、イベント情報は、イベントIDに対応づけて企画者、開催日時、マッチングポイント及び費用等を含む。
イベントIDは、イベントを識別するための識別子である。企画者は、対応づけられているイベントIDによって識別されるイベントを企画したユーザを識別するためのユーザIDを含む。
開催日時は、対応づけられているイベントIDによって識別されるイベントの開催日時を含む。マッチングポイントは、対応づけられているイベントIDによって識別されるイベントが開催される場所(位置を示す位置情報)を含む。
費用は、対応づけられているイベントIDによって識別されるイベントの開催に必要な費用を含む。なお、上記した費用には、当該費用を支払う支払者(例えば、企画者または参加者等)を指定する情報が含まれていても構わない。
図4に示す例では、イベントデータベース13には、イベント情報131〜133が格納されている。
イベント情報131は、イベントID「21」に対応づけて企画者「11」、開催日時「日時1」、マッチングポイント「マッチングポイント1」及び費用「費用1」を含む。このイベント情報131によれば、イベントID「21」によって識別されるイベントの企画者が、ユーザID「11」によって識別されるユーザXであることが示されている。また、イベント情報131によれば、イベントID「21」によって識別されるイベントの開催日時が「日時1」であり、当該イベントが開催されるマッチングポイントが「マッチングポイント1」であり、当該イベントの開催に必要な費用が「費用1」であることが示されている。
イベント情報132は、イベントID「22」に対応づけて企画者「12」、開催日時「日時2」、マッチングポイント「マッチングポイント2」及び費用「費用2」を含む。このイベント情報132によれば、イベントID「22」によって識別されるイベントの企画者が、ユーザID「12」によって識別されるユーザYであることが示されている。また、イベント情報132によれば、イベントID「22」によって識別されるイベントの開催日時が「日時2」であり、当該イベントが開催されるマッチングポイントが「マッチングポイント2」であり、当該イベントの開催に必要な費用が「費用2」であることが示されている。
イベント情報133は、イベントID「23」に対応づけて企画者「12」、開催日時「日時3」、マッチングポイント「マッチングポイント3」及び費用「費用3」を含む。このイベント情報133によれば、イベントID「23」によって識別されるイベントの企画者が、ユーザID「12」によって識別されるユーザYであることが示されている。また、イベント情報133によれば、イベントID「23」によって識別されるイベントの開催日時が「日時3」であり、当該イベントが開催されるマッチングポイントが「マッチングポイント3」であり、当該イベントの開催に必要な費用が「費用3」であることが示されている。
ここでは、イベント情報131〜133についてのみ説明したが、他のイベントを示すイベント情報についても同様である。
なお、図4に示すイベント情報は一例であり、当該イベント情報は、他の情報を含むものであっても構わない。
図5は、図2に示す評価データベース16のデータ構造の一例を示す。評価データベース16には、マッチングシステムを利用するユーザ毎に当該ユーザに対する評価を示す評価情報が格納される。ここでは、ユーザXに対する評価を示す評価情報について説明する。
図5に示すように、評価情報は、ランク及び評価ポイントを含む。ランクは、例えばユーザXに関するユーザ情報等に基づいて当該ユーザXに対して予め設定されており、例えばA〜Dランク等を含む。この場合、例えばAランクが最も高いランクであり、Dランクが最も低いランクであるものとする。ランクは、例えばユーザ情報に含まれる年齢等に応じて設定されてもよいし、上記した職業または年収等に応じて設定されてもよい。
なお、ランクはユーザ情報等に基づいて設定されるものとして説明したが、マッチングシステムの利用を開始する時点では、全てのユーザに対して同一のランクが設定されるような構成であっても構わない。つまり、後述するように、評価情報に含まれるランクは、マッチングシステムの利用に応じて変更され得る。
評価ポイントは、ユーザAと過去のイベントに参加した他のユーザによる当該ユーザXに対する評価を表すポイントである。上記したようにユーザYがユーザXとイベントに参加した場合、当該ユーザYは、当該ユーザXに対する評価をすることができる。この場合、ユーザYは、ユーザXを例えば5段階で評価する。具体的には、ユーザYは、ユーザXに対する例えば1〜5のポイントを指定する。なお、5ポイントが最高の評価であり、1ポイントが最低の評価である。評価情報に含まれる評価ポイントは、例えばこのようなユーザXと過去にイベントに参加した他のユーザによる当該ユーザXに対する評価ポイントの平均値である。なお、評価情報に含まれる評価ポイントは、他のユーザによるユーザXに対する評価ポイントに基づいて算出されるものであれば、他の手法により算出されるものであってもよい。
図5に示す例では、評価情報は、ランク「A」及び評価ポイント「3.6」を含む。この評価情報によれば、ユーザXに対して設定されているランクがAであり、他のユーザによる当該ユーザXに対する評価ポイント(の平均値)が3.6であることが示されている。なお、評価ポイントは、例えば小数点以下第2位が四捨五入されるものとする。
また、図5に示すように、評価情報には、上記したランク及び評価ポイント以外に、ライク(Like)イベント、ノットライク(not Like)イベント、イベント企画回数、イベント成立回数、参加要求回数、被承認回数、マッチング率、遅刻回数及びキャンセル回数等が含まれていてもよい。
ここで、例えばユーザXは、ユーザ端末21を操作することによって、他のユーザによって企画されたイベントを閲覧(検索)することができるものとする。この場合、ユーザXは、閲覧したイベントをライクイベントまたはノットライクイベントとして登録することができる。ライクイベントはユーザXの好みのイベントであり、ノットライクイベントはユーザXの好みではないイベントである。
評価情報において、ライクイベントは、ユーザXによってライクイベントとして登録されたイベントを識別するためのイベントIDを含む。評価情報に含まれるノットライクイベントは、ユーザXによってノットライクイベントとして登録されたイベントを識別するためのイベントIDを含む。
また、例えばユーザXがイベントを企画した場合において、当該イベントに対して参加者が存在する場合には当該イベントは開催される(つまり、マッチングが成立する)が、当該イベントに対して参加者が存在しない場合には当該イベントは開催されない(マッチングが成立しない)。
イベント企画回数は、過去にユーザXがイベントを企画した回数(つまり、ユーザXを識別するユーザIDを企画者として含むイベント情報の数)である。イベント開催回数は、過去にユーザXによって企画されたイベントが開催された回数である。
また、例えばユーザXが他のユーザによって企画されたイベントに参加する場合、当該ユーザXは、当該他のユーザに対してイベントへの参加を要求する。この場合、ユーザXは、イベントを企画している他のユーザによって当該イベントへの参加が承認された場合に当該イベントに参加することができる。
参加要求回数は、ユーザXが他のユーザによって企画されたイベントへの参加を要求した回数である。被承認回数は、他のユーザによって企画されたイベントへのユーザXによる参加の要求に対して当該他のユーザが承認した回数である。
マッチング率は、例えばユーザXが過去に企画したイベントのうち、他のユーザが参加することによって開催された(つまり、マッチングが成立した)イベントの数(の割合)を表す。具体的には、マッチング率は、例えば「イベント開催回数/イベント企画回数」等を含む。また、マッチング率は、例えば「(イベント開催回数+参加要求回数)/(イベント企画回数+被承認回数)」であってもよい。
遅刻回数は、過去に開催されたイベントにおいてユーザXが遅刻した回数を含む。また、キャンセル回数は、過去に開催されたイベントにおいてユーザXがキャンセルした回数を含む。
図5に示す例では、評価情報は、ライクイベント「23,…」、ノットライクイベント「22,…」、イベント企画回数「5」、イベント開催回数「2」、参加要求回数「1」、被承認回数「1」、マッチング率「0.5」、遅刻回数「0」及びキャンセル回数「0」を含む。
この評価情報によれば、ユーザXがライクイベントとしてイベントID「23」を含む複数のイベントIDによって識別されるイベントを登録していることが示されている。また、ユーザXがノットライクイベントとしてイベントID「22」を含む複数のイベントIDによって識別されるイベントを登録していることが示されている。
また、この評価情報に含まれるイベント企画回数「5」、イベント開催回数「2」、参加要求回数「1」及び被承認回数「1」によれば、ユーザXのマッチング率が0・5であることが示されている。なお、このマッチング率はイベント企画回数、イベント開催回数、参加要求回数及び被承認回数に基づいて算出されたものであるが、例えばイベント企画回数及びイベント開催回数に基づく場合、マッチング率は0.4となる。
更に、この評価情報によれば、ユーザXの遅刻回数及びキャンセル回数は0であることが示されている。
ここでは、ユーザXに対する評価を示す評価情報について説明したが、他のユーザ(例えば、ユーザY等)に対する評価を示す評価情報についても同様である。
なお、評価データベース16(に格納されている)評価情報の更新については後述する。
次に、図6を参照して、本実施形態に係るマッチングシステムの概要について説明する。
まず、ユーザXによってイベントが企画された場合を想定する。この場合、ユーザXによって企画されたイベントを示すイベント情報がイベントデータベース13に格納される。イベント情報には、上記したように企画者であるユーザXを識別するためのユーザID、イベントが開催される開催日時、当該イベントが開催される場所(マッチングポイント)及び費用等が含まれる。以下、ユーザXによって企画されたイベントを便宜的にユーザXのイベントと称する。
ここで、ユーザYがマッチングシステムによって提供されるマッチングサービスを利用する場合、当該ユーザYにマッチングさせるべきユーザ(によって企画されたイベント)が、所定のマッチングアルゴリズムにより検索(探索)される(ステップS1)。なお、このマッチングアルゴリズムでは評価データベース16(に格納されている評価情報)が利用されるが、その詳細については後述する。
これにより、例えばユーザX(のイベント)が検索された場合、当該イベントを示すイベント情報がユーザYに対して通知される(ステップS2)。
ユーザYがユーザXのイベントへの参加を希望する場合、当該ユーザYは、ユーザXに対して当該ユーザXへのイベントへの参加を要求する(ステップS3)。
この場合、ユーザXは、ユーザYからのイベントへの参加の要求に基づき、当該ユーザY(の参加)を承認することができる(ステップS4)。ユーザXによってユーザYが承認された場合、当該ユーザYは、ユーザXのイベントに参加することができる。
一方、ユーザXによってユーザYが承認されない(つまり、拒否された)場合、当該ユーザYは、ユーザXのイベントに参加することはできない。なお、ユーザXによって拒否されたことは、ユーザ端末22を介してユーザYに通知されるものとする。
すなわち、本実施形態に係るマッチングシステムにおいては、ユーザYがユーザXのイベントへの参加を要求し、当該要求に対してユーザXが承認することによる相互承認によりマッチングが成立する(つまり、イベントが開催される)仕組みを有する。
イベントが開催される場合、ユーザX(企画者)及びユーザY(参加者)は、当該イベントの開催日時にマッチングポイントに集合することによってチェックインすることができる(ステップS5)。
また、イベントが終了した場合、ユーザX及びユーザYは、マッチングポイントを離れることによってチェックアウトすることができる(ステップS6)。
ここで、本実施形態に係るマッチングシステムにおいては、イベントの終了後に相互評価を行うものとする。この場合、ユーザXはユーザYを評価するとともに、ユーザYはユーザXを評価する(ステップS7)。
このような評価の結果(評価情報)は、評価データベース16に格納される。上記したような流れでマッチングサービスが利用されることによって、評価データベース16には、過去のイベントに関する他のユーザによる評価がユーザ毎に蓄積されることになる。
本実施形態においては、このような評価データベース16に格納されている評価情報を利用することで、精度の高いマッチング(サービス)を実現することが可能となる。
以下、本実施形態に係るマッチングシステムの動作について具体的に説明する。以下においては、本実施形態に係るマッチングシステムにおいて実行されるイベント生成処理、マッチング処理及び評価処理の各々について説明する。
図7に示すシーケンスチャートを参照して、イベント生成処理の処理手順の一例について説明する。イベント生成処理は、ユーザがイベントを企画する際に実行される処理である。ここでは、ユーザXがイベントを企画する場合について説明する。
まず、ユーザXによって使用されるユーザ端末21には、マッチングシステムが提供するプラットフォーム上で動作する所定のアプリケーションプログラムがインストールされているものとする。なお、マッチングシステムを利用するユーザXを含む複数のユーザは、当該マッチングシステムに予め登録されているものとする。このようにマッチングシステムに登録された複数のユーザに関するユーザ情報は、ユーザデータベース11に格納されているものとする。
ユーザXがマッチングシステム(マッチングサービス)を利用する場合、当該ユーザXは、ユーザ端末21上で所定のアプリケーションプログラムを起動する(ステップS11)。これによれば、ユーザ端末21には、例えばトップページ画面等が表示される。
ここで、ユーザXがイベントを企画する場合、ユーザXは、ユーザ端末21に表示されたトップページ画面等に設けられている所定のボタン等を押下する操作をすることによって、当該イベントを企画することを指示することができる。これによれば、ユーザ端末21には、イベントを企画するための画面(以下、イベント企画画面と表記)が表示される(ステップS12)。
イベント企画画面において、ユーザXは、ユーザ端末21を操作することによってイベントの開催日時、当該イベントが開催される場所(マッチングポイント)及び当該イベントの開催に必要な費用等を指定する操作(以下、イベント指定操作と表記)を行うことができる。このようなイベント指定操作がユーザXによって行われた場合、ユーザ端末21は、当該イベント指定操作を受け付ける(ステップS13)。
ステップS13の処理が実行されると、ユーザ端末21は、イベント指定操作においてユーザによって指定された開催日時、マッチングポイント及び費用をマッチング装置10に送信する(ステップS14)。この場合、ユーザ端末21は、当該ユーザ端末21を使用するユーザXを識別するためのユーザIDを更に送信する。
マッチング装置10は、ユーザ端末21によって送信された開催日時、マッチングポイント及び費用と、ユーザIDとを受信する。マッチング装置10に含まれるイベント生成部12は、受信された開催日時、マッチングポイント及び費用をユーザID(つまり、企画者)に対応づけて含むイベント情報を生成する(ステップS15)。
イベント生成部12は、ステップS15において生成されたイベント情報をイベントデータベース13に格納(登録)する(ステップS16)。
このようにイベントデータベース13に格納されたイベント情報は、例えば他のユーザによって閲覧されることが可能となるとともに、後述するマッチング処理において他のユーザに対して通知されることが可能となる。
なお、上記したステップS16の処理が実行された場合、ユーザXによってイベントが企画されたことに応じて評価データベース16が更新される(ステップS17)。具体的には、ユーザXに対する評価を示す評価情報に含まれるイベント企画回数に対して1が加算される。
次に、図8に示すシーケンスチャートを参照して、マッチング処理の処理手順の一例について説明する。マッチング処理は、所定のユーザに対して、当該ユーザにマッチングさせるべき他のユーザ(によって企画されたイベント)を通知(推薦)する処理である。ここでは、ユーザYに対してイベントを通知する場合について説明する。この場合、ユーザYによって使用されるユーザ端末22上では、上記したアプリケーションプログラムが起動されているものとする。
まず、マッチング装置10に含まれるマッチング処理部14は、ユーザYにマッチングさせるべき他のユーザによって企画されたイベントを特定するための処理(以下、イベント特定処理と表記)を実行する(ステップS21)。このイベント特定処理においては、例えばユーザYに関するユーザ情報及び当該ユーザYに対する評価を示す評価情報に基づいて、イベントデータベース13に格納されているイベント情報によって示されるイベントの中からユーザYに対して通知するイベントを特定する。なお、イベント特定処理の詳細については後述する。
次に、マッチング処理部14は、ステップS21において特定されたイベントを示すイベント情報をイベントデータベース13から取得する(ステップS22)。以下、ステップS22においては、ユーザXによって企画されたイベントを示すイベント情報が取得されたものとして説明する。
マッチング処理部14は、ステップS22において取得されたイベント情報をユーザ端末22に送信する(ステップS23)。
ユーザ端末22は、マッチング装置10(マッチング処理部14)によって送信されたイベント情報を受信する。ユーザ端末22は、受信されたイベント情報を表示する(ステップS24)。
これにより、ステップS21のイベント特定処理によって特定されたイベント情報(つまり、ユーザYにマッチングさせるべきユーザXによって企画されたイベント)がユーザYに対して通知される。この場合、ユーザYは、ユーザ端末22に表示されたイベント情報に含まれる企画者、開催日時、マッチングポイント及び費用等を確認することによって、当該イベントへの参加を検討することができる。
イベントへの参加を望む場合、ユーザYは、ユーザ端末22に対して、当該イベントへの参加を要求する操作(以下、参加要求操作と表記)を行うことができる。このような参加要求操作がユーザYによって行われた場合、ユーザ端末22は、当該参加要求操作を受け付ける(ステップS25)。
ステップS25の処理が実行されると、ユーザ端末22は、参加要求操作に基づいて、ユーザYによるイベントへの参加を要求する参加要求をマッチング装置10に送信する(ステップS26)。なお、ステップS26において送信される参加要求には、ステップS24においてユーザ端末22に表示されたイベント情報に含まれるイベントID(つまり、ステップS21において特定されたイベントを識別するためのイベントID)及びユーザYを識別するためのユーザID等が含まれる。
マッチング装置10は、ユーザ端末22によって送信された参加要求を受信する。この場合、ユーザYがユーザXによって企画されたイベントへの参加が要求されたことに応じて評価データベース16が更新される(ステップS27)。具体的には、ユーザYに対する評価を示す評価情報に含まれる参加要求回数に対して1が加算される。
ここで、マッチング装置10において参加要求が受信された場合、当該マッチング装置10に含まれるマッチング処理部14は、当該参加要求に含まれるイベントIDによって識別されるイベントを企画したユーザX(当該イベントIDを含むイベント情報に含まれる企画者)によって使用されるユーザ端末21に対して、当該参加要求に含まれるユーザIDを含むユーザ情報(ここでは、ユーザYに関するユーザ情報)を送信する(ステップS28)。
ここでユーザYに関するユーザ情報が送信されたユーザ端末21を使用するユーザX(企画者)は、当該ユーザ端末21においてユーザ情報を確認することによって、ユーザYのイベントへの参加の承認を指示する操作(以下、承認指示操作と表記)を行うことができる。このような承認指示操作がユーザXによって行われた場合、ユーザ端末21は、当該承認指示操作を受け付ける(ステップS29)。
ステップS29の処理が実行されると、ユーザ端末21は、承認指示操作に基づいて、ユーザYのイベントへの参加を承認する参加承認をマッチング装置10に送信する(ステップS30)。
マッチング装置10は、ユーザ端末21によって送信された参加承認を受信する。これにより、ユーザXによって企画されたイベント(つまり、ユーザX及びユーザYのマッチング)が成立する。この場合、イベントの企画者であるユーザXと当該イベントの参加者であるユーザYとが当該イベントの開催までの間にコミュニケーションをとることができるように、マッチング装置10は、ユーザ端末21及びユーザ端末22を介してユーザX及びユーザY間でチャット等を行うことが可能な環境を提供するようにしてもよい。
上記したようにマッチングが成立した(つまり、イベントが開催される状態となった)場合、評価データベース16が更新される(ステップS31)。具体的には、ユーザXに対する評価を示す評価情報に含まれるイベント開催回数に対して1が加算される。また、ユーザYに対する評価を示す評価情報に含まれる被承認回数に対して1が加算される。
なお、図8においてはユーザXがユーザYのイベントへの参加を承認する場合について説明したが、当該ユーザXは、ユーザYのイベントへの参加を拒否することも可能である。この場合には、ユーザ端末21は、ユーザYのイベントへの参加を拒否する参加拒否をマッチング装置10に送信する。この場合、参加拒否がユーザYに通知され、ユーザYは、ユーザXによって企画されたイベントには参加することができない。
また、ここでは1人の参加者(ユーザY)の参加が承認されることによってマッチングが成立するものとして説明したが、イベントは、例えば企画者(ユーザX)によって指定された数のユーザが参加可能なものであってもよい。この場合には、企画者によって指定された数のユーザが参加するまで、マッチングは成立しないものとする。
なお、例えばユーザXによって企画されたイベントは、開催日時までにマッチングが成立しない(つまり、参加者がいない)場合にはキャンセルされるものとする。
上記したように評価情報に含まれるイベント企画回数、イベント開催回数、参加要求回数及び被承認回数が更新された場合、当該更新に応じてマッチング率も適宜更新されるものとする。
また、上記した例えばステップS24においてイベント情報がユーザ端末22に表示された場合、ユーザYは、当該イベント情報によって示されるイベントをライクイベントまたはノットライクイベントとして登録する操作を行うことができる。このような操作がユーザ端末22において行われた場合、マッチング装置10は、ユーザ端末22に表示されたイベント情報によって示されるイベントを識別するためのイベントIDを、ユーザYに対する評価を示す評価情報に含まれるライクイベントまたはノットライクイベントとして追加(登録)する。なお、ライクイベントまたはノットライクイベントとして登録する操作は、例えばユーザYが適宜設定した条件(例えば、開催日時、マッチングポイント、費用等)に基づいて検索されたイベントに対して行われても構わない。
また、本実施形態に係るマッチングシステムにおいては、イベントの開催に必要な費用は事前に決済されるものとする。具体的には、例えば企画者であるユーザXに関するユーザ情報に含まれるカード情報を用いて、事前にクレジットカード決済されるものとする。これによれば、イベントの開催時に費用の精算をする必要がなく、円滑にイベントを進めることができる。ここでは企画者が事前に決済するものとして説明したが、例えば参加者が決済するものであってもよい。決済者(支払者)は、イベントの企画時に企画者が設定可能としても構わない。
次に、図9のシーケンスチャートを参照して、評価処理の処理手順について説明する。評価処理は、ユーザによって企画されたイベントが開催される際(つまり、当該イベントの開催日)に実行される処理である。ここでは、ユーザXが企画者、ユーザYが参加者であるイベントが開催される場合について説明する。
まず、ユーザXによって使用されるユーザ端末21及びユーザYによって使用されるユーザ端末22においては、上述したアプリケーションプログラムが動作しているものとする。
この場合、ユーザ端末21は、当該ユーザ端末21(を使用するユーザX)の位置を示す位置情報を取得する(ステップS41)。なお、この位置情報は、ユーザ端末21が有するGPS(Global Positioning System)機能等により取得することができるものとする。
ここで、ユーザ端末21内の記憶装置(図示せず)には、ユーザXが企画したイベントを示すイベント情報が格納されているものとする。
この場合、ユーザ端末21は、ステップS41において取得された位置情報によって示される位置(以下、ユーザXの現在位置と表記)が、当該ユーザ端末21に格納されているイベント情報に含まれるマッチングポイント(の位置)から予め定められた範囲内にあるか否かを判定する。
ユーザXの現在位置がマッチングポイントから予め定められた範囲内にあると判定された場合、ユーザ端末21(を使用するユーザX)は、当該ユーザ端末21上で動作するアプリケーションプログラムにおいてマッチングポイントにチェックインすることができる(ステップS42)。なお、ステップS42においてユーザ端末21がマッチングポイントにチェックインするための予め定められた範囲内とは、例えば少なくともユーザXがマッチングポイントに到着していると推定される程度の範囲内であるものとする。
ユーザ端末21がマッチングポイントにチェックインした場合、当該ユーザ端末21は、当該マッチングポイントにチェックインしたことをマッチング装置10に通知する(ステップS43)。
同様に、ユーザ端末22は、当該ユーザ端末22(を使用するユーザY)の位置を示す位置情報を取得する(ステップS44)。なお、この位置情報は、上記したユーザ端末21と同様に、ユーザ端末22が有するGPS機能等により取得することができるものとする。
ここで、ユーザ端末22内の記憶装置(図示せず)には、ユーザXが企画したイベント(つまり、ユーザYが参加するイベント)を示すイベント情報が格納されているものとする。
この場合、ユーザ端末22は、ステップS44において取得された位置情報によって示される位置(以下、ユーザYの現在位置と表記)が、当該ユーザ端末21に格納されているイベント情報に含まれるマッチングポイント(の位置)から予め定められた範囲内にあるか否かを判定する。
ユーザYの現在位置がマッチングポイントから予め定められた範囲内にあると判定された場合、ユーザ端末22(を使用するユーザY)は、当該ユーザ端末22上で動作するアプリケーションプログラムにおいてマッチングポイントにチェックインすることができる(ステップS45)。なお、ステップS45の処理は、ステップS42の処理と同様の処理である。
ユーザ端末22がマッチングポイントにチェックインした場合、当該ユーザ端末22は、当該マッチングポイントにチェックインしたことをマッチング装置10に通知する(ステップS46)。
なお、ステップS41及びS44の処理は、イベント情報に含まれる開催日時から予め定められた時間前(例えば、30分前または1時間前等)から定期的に実行される。
上記したようにユーザ端末21及び22からマッチングポイントにチェックインしたことが通知された場合、イベント情報に含まれる開催日時と当該ユーザ端末21及び22がマッチングポイントにチェックインした日時(マッチングポイントにチェックインしたことが通知された日時)とに基づいて、マッチング装置10に含まれる評価処理部15は、評価データベース16を更新する(ステップS47)。
具体的には、評価処理部15は、ユーザ端末21がマッチングポイントにチェックインした日時(以下、チェックイン日時と表記)が開催日時を過ぎているか否かを判定する。ユーザ端末21のチェックイン日時が開催日時を過ぎている場合、評価処理部15は、ユーザXに対する評価を示す評価情報に含まれる遅刻回数に1を加算する。
同様に、ユーザ端末22のチェックイン日時が開催日時を過ぎている場合、評価処理部15は、ユーザYに対する評価を示す評価情報に含まれる遅刻回数に1を加算する。
なお、開催日時から予め定められた時間を経過してもユーザ端末21がマッチングポイントにチェックインしない(つまり、ユーザ端末21からチェックインが通知されない)場合には、ユーザXはイベントをキャンセルしたものとみなされる。この場合、評価処理部15は、ユーザXに対する評価を示す評価情報に含まれるキャンセル回数に1を加算する。また、ユーザXは、例えばユーザ端末21上で動作するアプリケーションプログラムを介して、一旦マッチングが成立したイベントを事前にキャンセルすることも可能であるが、当該キャンセルが例えば当日または前日等である場合には、同様に評価情報を更新する(つまり、キャンセル回数に1を加算する)ような構成であっても構わない。なお、ユーザYについても同様である。
ユーザ端末21(ユーザX)及びユーザ端末22(ユーザY)がチェックインし、イベントが開催された場合、ユーザ端末21は、定期的に当該ユーザ端末21の位置を示す位置情報を取得する(ステップS48)。
ステップS48において取得された位置情報によって示される位置(ユーザXの現在位置)が、イベント情報に含まれるマッチングポイントから予め定められた範囲内にあるか否かを判定する。
ユーザXの現在位置がマッチングポイントから予め定められた範囲内にないと判定された場合、ユーザ端末21(を使用するユーザX)は、当該マッチングポイントから離れたとみなされ、当該ユーザ端末21上で動作するアプリケーションプログラムにおいてマッチングポイントからチェックアウトする(ステップS49)。
ステップS49の処理が実行されると、ユーザXは、ユーザ端末21の画面上において、開催されたイベントにおけるユーザYに対する評価を指定する操作を行うことができる。この場合、ユーザXは、ユーザYを例えば1〜5の5段階のポイントで評価する。ユーザ端末21は、ユーザXの操作に基づいて、ユーザXによるユーザYに対する評価(を示す評価ポイント)を取得する(ステップS50)。
ユーザ端末21は、ステップS50において取得された評価ポイントをマッチング装置10に送信する(ステップS51)。
同様に、ユーザ端末21(ユーザX)及びユーザ端末22(ユーザY)がチェックインし、イベントが開催された場合、ユーザ端末22は、定期的に当該ユーザ端末22の位置を示す位置情報を取得する(ステップS52)。
ステップS52において取得された位置情報によって示される位置(ユーザYの現在位置)がマッチングポイントから予め定められた範囲内にないと判定された場合、ユーザ端末22(を使用するユーザY)は、当該マッチングポイントから離れたとみなされ、当該ユーザ端末22上で動作するアプリケーションプログラムにおいてマッチングポイントからチェックアウトする(ステップS53)。
ステップS53の処理が実行されると、ユーザYは、ユーザ端末22の画面上において、開催されたイベントにおけるユーザXに対する評価を指定することができる。この場合、ユーザYは、ユーザXを上記したように1〜5の5段階のポイントで評価する。ユーザ端末22は、ユーザYの操作に基づいて、ユーザYによるユーザXに対する評価(を示す評価ポイント)を取得する(ステップS54)。
ユーザ端末22は、ステップS54において取得された評価ポイントをマッチング装置10に送信する(ステップS55)、
次に、マッチング装置10に含まれる評価処理部15は、ステップS51及びS55において送信された評価ポイントに基づいて、評価データベース16を更新する(ステップS56)。
具体的には、評価処理部15は、ステップS51において送信された評価ポイントに基づいて、ユーザXに対する評価を示す評価情報に含まれる評価ポイントを更新する。なお、評価情報に含まれる評価ポイントがユーザXと過去にイベントに参加した他のユーザによる当該ユーザXに対する評価ポイントの平均値である場合には、例えば過去のユーザXに対する評価ポイントがマッチング装置10内で管理されているものとする。このような構成によれば、ステップS51において送信された評価ポイントと過去のユーザXに対する評価ポイントの平均値を算出することによって、評価情報を更新することができる。
ここでは、ユーザXに対する評価を示す評価情報(に含まれる評価ポイント)を更新する場合について説明したが、ユーザYに対する評価を示す評価情報(に含まれる評価ポイント)を更新する場合についても同様である。
なお、ここで説明した評価情報(評価ポイント)の更新処理は一例であり、当該評価情報は他の処理により更新されても構わない。
また、イベントの参加者が複数存在するような場合には、企画者は各参加者を評価し、各参加者は企画者及び他の参加者を評価する。また、企画者及び参加者は、イベントが開催されたマッチングポイントをも評価する構成であってもよい。
図9に示すような処理が実行されることによって、イベントが開催される度に各ユーザに対する評価を示す評価情報を更新(蓄積)することができる。
次に、図10に示すフローチャートを参照して、上述したイベント特定処理(図8に示すステップS21の処理)について詳細に説明する。イベント特定処理は、マッチング装置10に含まれるマッチング処理部14によって実行される。
ここでは、図8において説明したように、ユーザYにマッチングさせるべき他のユーザによって企画されたイベントを特定する場合について説明する。
まず、マッチング処理部14は、評価データベース16を参照して、ユーザYに対する評価を示す評価情報(以下、ユーザYの評価情報と表記)に含まれるランクを取得する(ステップS61)。
また、マッチング処理部14は、ユーザYの評価情報に含まれる評価ポイントを取得する(ステップS62)。
ここで、マッチング処理部14は、ステップS62において取得された評価ポイントを修正する(ステップS63)。
以下、ステップS63の処理について説明する。この場合、マッチング処理部14は、ユーザYの評価情報に含まれるマッチング率、遅刻回数及びキャンセル回数に基づいて評価ポイントを加点または減点することによって当該評価ポイントを修正する。
具体的には、評価ポイントは、マッチング率が高い場合には加点されるものとする。例えば、マッチング率が0.8以上である場合には、評価ポイントに0.5が加算される。一方、遅刻回数及びキャンセル回数が多いほど減点されるものとする。遅刻回数については、1回につき0.2が評価ポイントから減算される。また、キャンセル回数については、1回につき0.5が減算される。
すなわち、評価ポイント(過去の他のユーザによる評価ポイントの平均値)が3.3である場合であって、マッチング率が0.8以上であり、遅刻回数及びキャンセル回数が0である場合には、修正後の評価ポイントは3.8となる。
一方、評価ポイントが4.4である場合であって、マッチング率が0.8未満であり、遅刻回数が1回であり、キャンセル回数が3回である場合には、修正後の評価ポイントは2.7となる。
なお、ここではステップS63の処理が例えばマッチング率、遅刻回数及びキャンセル回数を用いて実行される場合について説明したが、当該ステップS63の処理は、マッチング率、遅刻回数及びキャンセル回数のうちの少なくとも1つを用いて実行されるものであってもよい。
上記したように本実施形態においては、過去に企画したイベントのうち他のユーザが参加することによって開催されたイベントの数を表すマッチング率、または遅刻やキャンセル等の予め定められた行為をした回数等に基づいて評価ポイントが修正される。
次に、マッチング処理部14は、ステップS61において取得されたランク及びステップS63において修正された評価ポイント(修正後の評価ポイント)に基づいてユーザYにマッチングさせるべきユーザ(以下、マッチングユーザと表記)を特定する(ステップS64)。
この場合、マッチング処理部14は、ランクがユーザYと同一であって、上記したように修正された評価ポイントの小数点以下第1位を四捨五入した値がユーザYと同一となるユーザをマッチングユーザとして特定する。
例えば、ユーザYのランクがAであり、ステップS63による修正後の評価ポイントが3.8であるものとする。この場合には、ランクがAであって、ステップS63と同様の処理が実行された後の修正後の評価ポイントが3.5〜4.4となるユーザがマッチングユーザとして特定される。マッチングユーザは、マッチングシステムを利用する複数のユーザの各々に対する評価を示す評価情報に基づいて特定することができる。
なお、図5に示すユーザXに対する評価を示す評価情報によれば、ユーザXのランクはAである。また、ユーザXの評価ポイントをマッチング率、遅刻回数及びキャンセル回数に基づいて修正した場合、当該修正後の評価ポイントは「3.6(つまり、加点及び減点はされない)」である。これによれば、ユーザXのランクはユーザYと同一であり、かつ、ユーザXの修正後の評価ポイントとユーザYの修正後の評価ポイントのそれぞれの小数点以下第1位を四捨五入した値は共に4である。この場合、ユーザXはマッチングユーザとして特定される。
なお、ランクがユーザYと同一であって、修正された評価ポイントの小数点以下第1位を四捨五入した値がユーザYと同一となるユーザが複数存在する場合には、当該複数のユーザがマッチングユーザとして特定されても構わない。
また、ここでは修正された評価ポイントの小数点以下第1位を四捨五入した値が同一となるユーザをマッチングユーザとして特定するものとして説明したが、これは一例であり、例えば修正された評価ポイントが予め定められた範囲内にあるユーザをマッチングユーザとして特定すればよい。
次に、マッチング処理部14は、イベントデータベース13を参照して、マッチングユーザ(として特定されたユーザ)によって企画されたイベントを示すイベント情報を、ユーザYに通知するイベント情報の候補(以下、候補イベント情報と表記)として取得する(ステップS65)。なお、候補イベント情報は、マッチングユーザを識別するためのユーザIDを企画者として含むイベント情報である。
ここで、ステップS65において複数の候補イベント情報が取得された場合を想定する。この場合、マッチング処理部14は、取得された複数の候補イベント情報の各々に対して優先度を算出する(ステップS66)。
この優先度の算出方法については様々なものがあるが、例えばユーザYに対する評価を示す評価情報に含まれるライクイベント及びノットライクイベントに基づいて優先度を算出してもよい。具体的には、ライクイベントとして登録されているイベントIDによって識別されるイベント(における企画者、マッチングポイント及び費用等)と類似するイベント(を示す候補イベント情報)については優先度を高く算出するものとする。一方、ノットライクイベントとして登録されているイベントIDによって識別されるイベントと類似するイベント(を示す候補イベント情報)については優先度を低く算出するものとする。
ここでは、評価情報に含まれるライクイベント及びノットライクイベントに基づいて優先度を算出する場合について説明したが、例えばユーザYがお気に入りとして登録しているユーザが企画者であるイベントの優先度を高くするようにしてもよいし、マッチングポイントがユーザYの住所から近いイベントの優先度を高くしてもよいし、費用が高いまたは低いイベントの優先度を高くしてもよい。
以下、ステップS65において取得された候補イベント情報の各々について、ステップS66において算出された優先度が高い順にステップS67以降の処理が実行される。以下、ステップS67以降の処理が実行される候補イベント情報を対象候補イベント情報と称する。
まず、マッチング処理部14は、対象候補イベント情報に基づいて、当該対象候補イベント情報によって示されるイベントにユーザYが参加可能であるか否かを判定する(ステップS67)。この場合、マッチング処理部14は、例えばユーザデータベース11に格納されているユーザYに関するユーザ情報に含まれる当該ユーザYの住所と、対象候補イベント情報に含まれる開催日時及びマッチングポイントに基づいて判定処理を実行する。
具体的には、対象候補イベント情報に含まれる開催日時が現在時刻から1時間後等である場合において、例えばユーザYの住所からマッチングポイントに移動したとしてもユーザYが開催日時までにマッチングポイントに到着することができないような場合には、ユーザYが参加可能ではないと判定される。このステップS67における判定処理においては、例えば天候及び交通情報等を考慮するようにしても構わない。
イベントにユーザYが参加可能であると判定された場合(ステップS67のYES)、マッチング処理部14は、対象候補イベント情報によって示されるイベントがユーザデータベース11に格納されているユーザYに関するユーザ情報に含まれる条件に合致するか否かを判定する(ステップS68)。なお、条件には、例えば企画者に関する条件、開催日時に関する条件、マッチングポイントに関する条件、費用に関する条件等が含まれる。
企画者に関する条件は、例えばユーザYによって指定されたユーザ(例えば、お気に入りのユーザ)が企画者であること等を含む。開催日時に関する条件は、例えばユーザYによって指定された期間内(または時間帯)であること等を含む。
また、マッチングポイントに関する条件は、例えばマッチングポイントがユーザYによって指定された地域にあること等を含む。また、上記したようにマッチングポイントがマッチングシステムを利用する各ユーザによって評価されているような場合には、マッチングポイントに関する条件として、当該評価結果(ポイント)が所定の値以上であること等が含まれていてもよい。
費用に関する条件は、例えば所定の金額以上または以下であること、及び自身(ユーザY)が支払者(決済者)でないこと等を含む。
イベントが条件に合致すると判定された場合(ステップS68のYES)、マッチング処理部14は、対象候補イベント情報をユーザYに対して通知するイベント(を示すイベント情報)として特定する(ステップS69)。
ステップS69の処理が実行されると、図8に示すステップS22以降の処理が実行される。
一方、イベントにユーザYが参加可能でないと判定された場合(ステップS67のNO)及びイベントが条件に合致しないと判定された場合(ステップS68のNO)、候補イベント情報の全てについてステップS67以降の処理が実行されたか否かが判定される(ステップS70)。
候補イベント情報の全てについて処理が実行されていないと判定された場合(ステップS70のNO)、ステップS67に戻って処理が繰り返される。この場合、処理が実行された対象候補イベント情報の次に優先度の高い候補イベント情報を対象候補イベント情報としてステップS67以降の処理が実行される。
候補イベント情報の全てについて処理が実行されたと判定された場合(ステップS70のYES)、イベント特定処理は終了される。この場合、ユーザYに通知するイベント(情報)がないため、イベント特定処理以降の図8に示す処理も実行されないものとする。
なお、図10に示すイベント特定処理は一例であり、適宜変更されても構わない。具体的には、図10においてはステップS63において修正された評価ポイントを用いてマッチングユーザを特定するものとして説明したが、当該ステップS63の処理を省略し、例えば評価情報に含まれる評価ポイントの小数点以下第1位を四捨五入した値がユーザYと同一となるユーザをマッチングユーザとして特定しても構わない。
また、図10に示す処理においてはユーザYに対して通知する1のイベントが特定されるものとして説明したが、当該ユーザYに対して通知されるイベントは複数であっても構わない。すなわち、例えばステップS65において取得された候補イベント情報によって示されるイベントのうち、ユーザYが参加可能であり、かつ、ユーザYの条件に合致するものであれば、全てのイベント(を示すイベント情報)がユーザYに通知される構成であっても構わない。
また、図10に示す処理において評価ポイントを修正するものとして説明したが、当該評価ポイントの修正処理は、イベント特定処理の実行前に予め実行されている構成であっても構わない。この場合、例えば各ユーザに対する評価を示す評価情報に含まれる評価ポイント、マッチング率、遅刻回数及びキャンセル回数が更新される度に評価ポイントの修正処理が実行されればよい。なお、修正処理が実行された後の評価ポイント(修正後の評価ポイント)は、例えば評価データベース16に格納しておけばよい。
以下、本実施形態に係るマッチングシステムの利用態様の具体例について説明する。ここでは、本実施形態に係るマッチングシステムが食事会のイベントにおいてユーザをマッチングさせる場合について説明する。
この場合、例えば男性ユーザXは、食事会の開催日時、場所(マッチングポイント)及び費用を指定することによってイベント(以下、食事会イベントと表記)を企画することができる。なお、食事会イベントにおける場所としては、例えば男性ユーザXが予約したレストラン(店舗)及び当該レストランで注文するコースメニューの種類等を指定することができる。また、食事会イベントにおける費用には、食事会において注文するコースメニューにかかる料金に加えて、例えば当該食事会に参加する女性ユーザが帰宅する際のタクシー代等が含まれてもよい。なお、男性ユーザXによって食事会イベントが企画された(つまり、食事会イベントを示すイベント情報がイベントデータベース13に格納された)場合、当該食事会イベントにおいて指定されたレストラン及びコースメニューが予約されるような構成であってもよい。
このように男性ユーザXによって企画された食事会イベントは、上記したマッチング処理が実行されることによってマッチングシステムを利用する例えば女性ユーザYに対して通知される。
これに対して、女性ユーザYは、食事会イベントの内容(例えば、レストラン、コースメニュー及びタクシー代等)を考慮して、当該食事会イベントへの参加を要求することができる。
女性ユーザYから食事会イベントへの参加が要求された場合、男性ユーザXは、当該女性ユーザYに関するユーザ情報等を考慮して、当該女性ユーザYの参加を承認することができる。
上記したように男性ユーザX及び女性ユーザYから相互承認が得られた場合、男性ユーザX及び女性ユーザYの食事会におけるマッチング(食事会マッチング)が成立し、男性ユーザXは、女性ユーザYと食事会を行うことができる(つまり、食事会イベントを開催することができる)。
なお、食事会イベントにおいて指定されている費用(レストランでのコースメニューの料金及びタクシー代等)は、男性ユーザXのクレジットカードにより事前に決済される。一方、タクシー代については、例えば食事会の事前または事後に女性ユーザYの口座に入金される等、女性ユーザYに対して支払われる。
上記した食事会が終了した場合、男性ユーザX及び女性ユーザYの互いの評価によって評価データベース16(に格納されている評価情報)が更新される。このように更新された評価情報は、次回のマッチング処理時に利用される。
上記したように本実施形態に係るマッチングシステムによれば、例えば男性ユーザ及び女性ユーザをマッチングさせる食事会マッチングを実現することが可能となる。
ここでは、男性ユーザXが食事会イベントを企画する場合について説明したが、例えば女性ユーザYが食事会イベントを企画することも可能である。この場合、女性ユーザYは、企画者である女性ユーザYではなく、イベントに参加する男性ユーザが事前に決済する食事会イベントを企画することができる。以下に説明する他のイベントについても同様に、参加者が費用を決済する(支払う)ようなイベントが企画されても構わない。
更に、本実施形態に係るマッチングシステムは、例えばネイルの施術を受けるイベントにおいてユーザをマッチングさせる場合に適用されても構わない。
具体的には、例えばネイルの施術を受けるユーザXは、ネイルの施術を受ける日時、場所(マッチングポイント)及び費用を指定することによってイベント(以下、ネイリストイベントと表記)を企画することができる。なお、ネイリストイベントにおける場所としては、例えばユーザXの自宅等を指定してもよいし、ユーザXが用意するネイルの施術を受けることが可能な場所等を指定してもよい。また、ネイリストイベントにおける費用には、例えばマッチングポイントまでの交通費及びネイルの施術に対する報酬等が含まれる。
このようにネイルの施術を受けるユーザXによって企画されたネイリストイベントは、上記したマッチング処理が実行されることによってマッチングシステムを利用するユーザYに対して通知される。なお、ユーザYは、ネイリストであるものとする。
これに対して、ネイリストであるユーザYは、ネイリストイベントの内容(例えば、場所、交通費の支給の有無及び報酬等)を考慮して、当該ネイリストイベントへの参加を要求することができる。
ネイリストであるユーザYからネイルイベントへの参加が要求された場合、ユーザXは、当該ユーザYに関するユーザ情報を考慮して、当該ユーザYの参加を承認することができる。なお、この場合におけるユーザYに関するユーザ情報には、例えばユーザYのネイリストとしての経験年数等が含まれていてもよい。
上記したようにネイルの施術を受けるユーザX及びネイリストであるユーザYから相互承認が得られた場合、ユーザX及びユーザYのネイルの施術におけるマッチング(ネイリストマッチング)が成立し、ユーザXは、ユーザYによるネイルの施術を受けることができる(つまり、ネイリストイベントを開催することができる)。
なお、ネイリストイベントにおいて指定されている費用(交通費及び報酬等)は、ユーザXのクレジットカードにより事前に決済されるとともに、ユーザYの口座に入金される等、ユーザYに対して支払われる。
上記したネイルの施術が終了した場合、ネイルの施術を受けたユーザX及びネイリストであるユーザYの互いの評価によって評価データベース16(に格納されている評価情報)が更新される。
上記したように本実施形態に係るマッチングシステムよれば、例えばネイルの施術を受けるユーザ及びネイリストであるユーザをマッチングさせるネイリストマッチングを実現することが可能となる。
更に、本実施形態に係るマッチングシステムは、例えばゴルフレッスンのイベントにおいてユーザをマッチングさせる場合に適用されても構わない。
具体的には、例えばゴルフのレッスンを受けるユーザXは、ゴルフのレッスンを受ける日時、場所(マッチングポイント)及び費用を指定することによってイベント(以下、ゴルフコーチイベントと表記)を企画することができる。なお、ゴルフコーチイベントにおける場所としては、例えばユーザXが予約したゴルフ場等を指定することができる。また、ゴルフコーチイベントにおける費用には、例えばマッチングポイントまでの交通費及びゴルフのレッスンに対する報酬等が含まれる。なお、ユーザXによってゴルフイベントが企画された(つまり、ゴルフコーチイベントを示すイベント情報がイベントデータベース13に格納された)場合、当該ゴルフコーチイベントにおいて指定されたゴルフ場が予約されるような構成であってもよい。
このようにゴルフのレッスンを受けるユーザXによって企画されたゴルフコーチイベントは、上記したマッチング処理が実行されることによってマッチングシステムを利用するユーザYに対して通知される。なお、ユーザYは、ゴルフのコーチであるものとする。
これに対して、ゴルフのコーチであるユーザYは、ゴルフイコーチベントの内容(例えば、場所、交通費の支給の有無及び報酬等)を考慮して、当該ゴルフコーチイベントへの参加を要求することができる。
ゴルフのコーチであるユーザYからゴルフイベントへの参加が要求された場合、ユーザXは、当該ユーザYに関するユーザ情報を考慮して、当該ユーザYの参加を承認することができる。なお、この場合におけるユーザYに関するユーザ情報には、例えばユーザYのゴルフ(のコーチとして)の経験年数等が含まれていてもよい。
上記したようにゴルフのレッスンを受けるユーザX及びゴルフのコーチであるユーザYから相互承認が得られた場合、ユーザX及びユーザYのゴルフのレッスンにおけるマッチング(ゴルフコーチマッチング)が成立し、ユーザXは、ユーザYによるゴルフのレッスンを受けることができる(ゴルフコーチイベントを開催することができる)。
なお、ゴルフコーチイベントにおいて指定されている費用(交通費及び報酬等)は、ユーザXのクレジットカードにより事前に決済されるとともに、ユーザYの口座に入金される等、ユーザYに対して支払われる。
上記したゴルフレッスンが終了した場合、当該レッスンを受けたユーザX及びゴルフのコーチであるユーザYの互いの評価によって評価データベース16(に格納されている評価情報)が更新される。
上記したように本実施形態に係るマッチングシステムによれば、例えばゴルフのレッスンを受けるユーザ及びゴルフのコーチであるユーザをマッチングさせるゴルフコーチマッチングを実現することが可能となる。
ここでは、一例として食事会マッチング、ネイリストマッチング及びゴルフコーチマッチングについて説明したが、本実施形態に係るマッチングシステムは、様々なマッチングに対して適用することが可能である。具体的には、例えばホテルを経営する企業によって企画されたイベントにおいて当該企業及びユーザ(客)をマッチングさせることによって、当該ユーザをホテルに宿泊させるようなマッチングに適用することも可能である。更に、タクシーの運転手によって企画されたイベントにおいて当該運転手及びユーザ(客)をマッチングさせることによって、当該ユーザに対して当該運転手が運転するタクシーを手配するようなマッチングに適用することも可能である。
上記したように本実施形態においては、ユーザX(第1のユーザ)と過去のイベントに参加した他のユーザによる当該ユーザXに対する評価を示す評価情報(第1の評価情報)及びユーザY(第2のユーザ)と過去のイベントに参加した他のユーザによる等がユーザYに対する評価を示す評価情報(第2の評価情報)に基づいて、ユーザXによって企画されたイベントをユーザYに通知することによって、当該ユーザX及びユーザYをマッチングさせる。なお、評価情報は、イベントが開催された後のユーザX及びユーザYによる互いの評価によって更新される。
本実施形態においては、このような構成により、例えば単にユーザの属性情報(ユーザ情報)等を用いてマッチングさせる場合と比較して、イベントの開催(マッチングシステムの利用)に応じて蓄積(更新)される評価情報を用いてユーザをマッチングさせるため、マッチング精度を向上させることが可能となる。
また、本実施形態においては、ユーザX及びユーザYの相互承認により当該ユーザX及びユーザYをマッチングさせる(つまり、イベントが開催される)構成により、ユーザの望まない相手(ユーザ)とマッチングされることを回避することができる。
更に、本実施形態においては、イベントの開催に必要な費用は当該イベントが開催される前にユーザX(またはユーザY)によってクレジットカード決済される構成により、例えばイベントの開催中等に費用の支払いをする必要がないため、円滑にイベントを進行することが可能となる。
また、本実施形態においては、ランクが同一であり、かつ、評価ポイントが予め定められた範囲内にあるユーザXがマッチングされる(つまり、当該ユーザXが企画したイベントが通知される)。この場合における評価ポイントは、上記したマッチングポイントまたは予め定められた行為(例えば、遅刻またはキャンセル等)に基づいて修正される。本実施形態においては、このような構成により、評価情報に基づいてより適切なユーザをマッチングさせることができ、より精度の高いマッチングを実現することが可能となる。
更に、本実施形態においては、例えばユーザYがイベントに参加可能であると判定された場合に当該イベントをユーザYに通知する構成により、ユーザYが参加することができないイベントを通知するような事態を回避することが可能となる。
また、本実施形態においては、ユーザYによって予め定められた条件を満たすイベントが当該ユーザYに通知される構成により、よりマッチング精度を向上させることが可能となる。
なお、本実施形態において、ユーザをマッチングさせる際に用いられるランク(評価情報に含まれるランク)は、当該ユーザに関するユーザ情報に基づいて予め設定されているものとして説明したが、上記したようにマッチングシステムの利用に応じて変更されても構わない。
具体的には、ユーザXのランク(ユーザXに対する評価を示す評価情報に含まれるランク)がBランクである場合を想定する。この場合において、ユーザXがマッチングシステムを利用してイベントの企画(開催)及びイベントへの参加を繰り返すことによって、当該ユーザXに対する評価を表す評価ポイントが予め定められた値(例えば、4.5)以上となったものとする。この場合には、ユーザXのランクはBランクからAランクに変更される。このように評価ポイントが向上した場合には、ユーザXのランクをランクアップさせることができるものとする。
一方、ユーザXに対する評価を表す評価ポイントが予め定められた値(例えば、1.5)以下となった場合には、ユーザXのランクはBランクからCランクに変更される。このように評価ポイントが低下した場合には、ユーザXのランクがランクダウンさせられる場合もある。なお、ランクが変更された場合には、評価ポイントはリセットされるものとする。
ここでは単に評価ポイントが向上した場合または低下した場合について説明したが、上記した修正後の評価ポイントが4.5以上となった場合にランクアップさせ、修正後の評価ポイントが1.5以下となった場合にランクダウンさせる構成であっても構わない。
(第2の実施形態)
次に、本発明の第2の実施形態について説明する。なお、本実施形態に係るマッチング装置を含むネットワークシステム(マッチングシステム)のハードウェア構成については、前述した第1の実施形態と同様であるため、適宜、図1を用いて説明する。
まず、図11を参照して、本実施形態に係るマッチングシステムの概要について説明する。前述した第1の実施形態においては例えば食事会マッチング、ネイリストマッチングまたはゴルフコーチマッチング等の1のマッチングサービスをユーザが利用する場合について説明したが、本実施形態に係るマッチング装置100は、ユーザが複数のマッチングサービスを利用可能とするためのサービスプラットフォーム100aを提供する点で、前述した第1の実施形態とは異なる。
以下の説明においては、サービスプラットフォーム100aにより、ユーザは、第1〜第3のマッチングサービスを利用可能であるものとして説明する。
ここで、例えばユーザが第1のマッチングサービスを利用する場合、当該ユーザによって使用されるユーザ端末では、第1のアプリケーション(プログラム)200aが起動されるものとする。
一方、例えばユーザが第2のマッチングサービスを利用する場合、当該ユーザによって使用されるユーザ端末では、第2のアプリケーション(プログラム)200bが起動されるものとする。
更に、例えばユーザが第3のマッチングサービスを利用する場合、当該ユーザによって使用されるユーザ端末では、第3のアプリケーション(プログラム)200cが起動されるものとする。
第1のアプリケーション200a、第2のアプリケーション200b及び第3のアプリケーション200cは、上記した第1〜第3のマッチングサービスそれぞれに特化した独自のアプリケーションプログラムであり、サービスプラットフォーム100a上で動作する。
また、本実施形態に係るマッチング装置100は、ユーザが利用可能な第1〜第3のマッチングサービスの各々について評価データベースを備える。
図11に示すように、マッチング装置100は、第1〜第3の評価データベース16a〜16cを備える。
第1の評価データベース16aは、例えば第1のマッチングサービスにおいて開催されたイベントに参加したユーザに対する評価を示す評価情報を格納する。
第2の評価データベース16bは、例えば第2のマッチングサービスにおいて開催されたイベントに参加したユーザに対する評価を示す評価情報を格納する。
第3の評価データベース16cは、例えば第3のマッチングサービスにおいて開催されたイベントに参加したユーザに対する評価を示す評価情報を格納する。
本実施形態に係るマッチングシステム(マッチング装置100)は、上記したような構成により、複数種類のアプリケーション(第1〜第3のアプリケーション200a〜200c)が動作する環境(サービスプラットフォーム100a)を提供することによって複数のマッチングサービス(第1〜第3のマッチングサービス)の各々におけるマッチングを実現することができる。
図12は、図11に示すマッチング装置100の主として機能構成を示すブロック図である。なお、図12の説明においては、前述した図2と同様の部分には同一参照符号を付してその詳しい説明を省略する。ここでは、図2と異なる部分について主に述べる。
図12に示すように、マッチング装置100は、マッチング履歴データベース101及び第2のマッチング処理部102を含む。
本実施形態において、マッチング履歴データベース101は、図1に示す記憶装置10bに格納される。また、本実施形態において、第2のマッチング処理部102は、図1に示すプロセッサ10aがプログラムを実行すること(すなわち、ソフトウェア)によって実現されるものとする。なお、第2のマッチング処理部102は、ハードウェアによって実現されてもよいし、ハードウェアとソフトウェアとの組み合わせ構成によって実現されてもよい。
図12に示す第1のマッチング処理部14は、前述した第1の実施形態におけるマッチング処理部14に相当する機能部であるが、上記した第1〜第3のマッチングサービスに応じたマッチング処理を実行する。
このため、図12においては省略されているが、イベントデータベース13は、第1〜第3のマッチングサービスの各々において企画されたイベントを示すイベント情報をそれぞれ格納する第1〜第3のイベントデータベースを含む。
また、図12に示す評価データベース16は、図11に示す第1〜第3の評価データベース16aを含む。
すなわち、例えば第1のアプリケーション200aが起動されたユーザ端末に対するユーザの操作に応じてイベントが企画された場合には、当該イベントを示すイベント情報は第1のイベントデータベースに格納される。この場合、第1のマッチング処理部14は、第1の評価データベース16aに格納されている評価情報に基づいて、第1のマッチングサービスに応じたマッチング処理を実行する。なお、第1の評価データベース16a(に格納されている評価情報)は、第1のマッチングサービスにおいて企画されたイベントにおける各ユーザに対する評価によって更新される。
また、例えば第2のアプリケーション200bが起動されたユーザ端末に対するユーザの操作に応じてイベントが企画された場合には、当該イベントを示すイベント情報は第2のイベントデータベースに格納される。この場合、第1のマッチング処理部14は、第2の評価データベース16bに格納されている評価情報に基づいて、第2のマッチングサービスに応じたマッチング処理を実行する。なお、第2の評価データベース16b(に格納されている評価情報)は、第2のマッチングサービスにおいて企画されたイベントにおける各ユーザに対する評価によって更新される。
また、例えば第3のアプリケーション200cが起動されたユーザ端末に対するユーザの操作に応じてイベントが企画された場合には、当該イベントを示すイベント情報は第3のイベントデータベースに格納される。この場合、第1のマッチング処理部14は、第3の評価データベース16cに格納されている評価情報に基づいて、第3のマッチングサービスに応じたマッチング処理を実行する。なお、第3の評価データベース16c(に格納されている評価情報)は、第3のマッチングサービスにおいて企画されたイベントにおける各ユーザに対する評価によって更新される。
マッチング履歴データベース101には、第1〜第3のマッチングサービスにおけるマッチング履歴(つまり、マッチングの成立)を示す情報(以下、マッチング履歴情報と表記)が格納される。
具体的には、マッチング履歴データベース101には、例えば第1のマッチンサービスにおいて企画されたイベント(第1のイベント)において例えばユーザX及びユーザYがマッチングされたことを示すマッチング履歴情報が格納される。また、マッチング履歴データベース101には、例えば第2のマッチングサービスにおいて企画されたイベントにおいて例えばユーザX及びユーザYがマッチングされたことを示すマッチング履歴情報が格納される。また、マッチング履歴データベース101には、例えば第3のマッチングサービスにおいて企画されたイベントにおいて例えばユーザX及びユーザYがマッチングされたことを示すマッチング履歴情報が格納される。
なお、ユーザX及びユーザYがマッチングされるとは、例えばユーザXによって企画されたイベントにユーザYが参加すること、ユーザYによって企画されたイベントにユーザXが参加すること、及び他のユーザによって企画されたイベントにユーザX及びユーザYが参加すること等を含む。
第2のマッチング処理部102は、マッチング履歴データベース101に格納されたマッチング履歴情報に基づいて、複数のユーザをマッチングさせるための処理を実行する。この場合、第2のマッチング処理部102は、例えば第1のマッチングサービスにおいて企画されたイベントにおいてユーザX及びユーザYがマッチングされたことを示すマッチング履歴情報に基づいて、当該第1のマッチングサービスに関連する第2のマッチングサービス(または第3のマッチングサービス)において企画されたイベントを例えばユーザXに通知することによって、当該イベントにおいてユーザX及び他のユーザ(第3のユーザ)をマッチングさせる。
図13は、図12に示すマッチング履歴データベース101のデータ構造の一例を示す。マッチング履歴データベース101には、上記したように第1〜第3のマッチングサービスにおけるマッチング履歴(マッチングの成立)を示すマッチング履歴情報が格納されている。
図13に示すように、マッチング履歴情報は、マッチングサービス名、企画者、参加者、開催日時及び場所等を含む。
マッチングサービスは、マッチングが成立したマッチングサービス(名)を示す。企画者は、対応づけられているマッチングサービスにおいてマッチングが成立したイベントを企画したユーザを識別するためのユーザIDを含む。参加者は、対応づけられているマッチングサービスにおいてマッチングが成立したイベントに参加するユーザを識別するためのユーザIDを含む。
開催日時は、対応づけられているマッチングサービスにおいてマッチングが成立したイベントの開催日時を含む。マッチングポイントは、対応づけられてるマッチングサービスにおいてマッチングが成立したイベントが開催される場所(位置を示す位置情報)を含む。
図13に示す例では、マッチング履歴データベース101には、マッチング履歴情報101a及び101bが格納されている。
マッチング履歴情報101aは、マッチングサービス「第1のマッチングサービス」、企画者「11」、参加者「12」、開催日時「日時1」及びマッチングポイント「マッチングポイント1」を含む。このマッチング履歴情報101aによれば、第1のマッチングサービスにおいてマッチングが成立したイベントの企画者がユーザID「11」によって識別されるユーザXであり、当該イベントの参加者がユーザID「12」によって識別されるユーザYであることが示されている。また、マッチング履歴情報101aによれば、第1のマッチングサービスにおいてマッチングが成立したイベントの開催日時が「日時1」であり、当該イベントが開催されるマッチングポイントが「マッチングポイント1」であることが示されている。
マッチング履歴情報101bは、マッチングサービス「第2のマッチングサービス」、企画者「12」、参加者「13」、開催日時「日時4」及びマッチングポイント「マッチングポイント4」を含む。このマッチング履歴情報101bによれば、第2のマッチングサービスにおいてマッチングが成立したイベントの企画者がユーザID「12」によって識別されるユーザYであり、当該イベントの参加者がユーザID「13」によって識別されるユーザ(ユーザZ)であることが示されている。また、マッチング履歴情報101bによれば、第2のマッチングサービスにおいてマッチングが成立したイベントの開催日時が「日時4」であり、当該イベントが開催されるマッチングポイントが「マッチングポイント4」であることが示されている。
図13においてはマッチング履歴情報101a及び101bについてのみ説明したが、マッチング履歴データベース101には、第1〜第3のマッチングサービスにおけるマッチングの成立毎にマッチング履歴情報が格納されている。
なお、図13に示すマッチング履歴情報は一例であり、当該マッチング履歴情報は、他の情報を含むものであっても構わない。
次に、本実施形態に係るマッチングシステムの動作について説明する。本実施形態に係るマッチングシステムは、前述した第1の実施形態において説明したイベント生成処理、マッチング処理(以下、第1のマッチング処理と表記)及び評価処理を実行する。なお、イベント生成処理、第1のマッチング処理及び評価処理(を含む一連の処理)は、第1〜第3のマッチングサービス毎に実行される。
ここで、本実施形態に係るマッチングシステムは、第1のマッチング処理によって複数のユーザがマッチングされた場合、上記したマッチング履歴データベース101に格納されているマッチング履歴情報を利用して第2のマッチング処理を実行する。
以下、図14に示すシーケンスチャートを参照して、第2のマッチング処理の処理手順の一例について説明する。
まず、第1のマッチング処理によって例えばユーザX及びユーザYがマッチングされた場合を想定する。ここでは、例えば第1のマッチングサービスにおいて企画されたイベントにおいてユーザX及びユーザYがマッチングされたものとする。
この場合、ユーザX及びユーザYがマッチングされたことを示すマッチング履歴情報がマッチング履歴データベース101に格納される(ステップS81)。ここでは、図13に示すマッチング履歴情報101aがマッチング履歴データベース101に格納されたものとする。
ステップS81の処理が実行された場合、第2のマッチング処理部102は、マッチング履歴データベース101に格納されたマッチング履歴情報101aを取得する。第2のマッチング処理部102は、取得されたマッチング履歴情報101aに含まれるマッチングサービス(ここでは、第1のマッチングサービス)に関連するマッチングサービスを決定する(ステップS82)。ここでは、第1のマッチングサービスに関連するマッチングサービスとして第2のマッチングサービスが決定されたものとする。
次に、第2のマッチング処理102は、取得されたマッチング履歴情報101aに含まれる例えば企画者であるユーザX(ユーザID「11」によって識別されるユーザ)にマッチングさせるべき他のユーザによって企画されたイベントを特定するための処理(イベント特定処理)を実行する(ステップS83)。ここで特定されるイベントは、ステップS82において決定されたマッチングサービスにおいて企画されたイベントである。
なお、ステップS83において実行されるイベント特定処理の詳細については前述した図10において説明した通りであるため、その詳しい説明を省略するが、当該イベント特定処理においては例えばマッチング履歴情報101aに含まれる開催日時及びマッチングポイント等が利用されても構わない。イベント特定処理においてマッチング履歴情報101aに含まれる開催日時及びマッチングポイントを利用する具体例については後述する。
ステップS83の処理が実行されると、第2のマッチング処理部102は、当該ステップS83において特定されたイベントを示すイベント情報をイベントデータベース13(に含まれる第2のイベントデータベース)から取得する(ステップS84)。
第2のマッチング処理部102は、ステップS84において取得されたイベント情報をユーザ端末21(ユーザXによって使用されるユーザ端末)に送信する(ステップS85)。
ユーザ端末21は、マッチング装置100(第2のマッチング処理部102)によって送信されたイベント情報を受信する。ユーザ端末21は、受信されたイベント情報を表示する(ステップS86)。
これにより、ステップS83のイベント特定処理によって特定されたイベント情報(つまり、ユーザXにマッチングさせるべき他のユーザによって企画されたイベント)がユーザXに対して通知される。この場合、ユーザXは、ユーザ端末21に表示されたイベント情報に含まれる企画者、開催日時、マッチングポイント及び費用等を確認することによって、当該イベントへの参加を検討することができる。
なお、図14においては省略されているが、ステップS86の処理が実行された後は、図8に示すステップS25以降の処理が実行されればよい。これにより、ユーザXは、第1のマッチングサービスにおいてマッチングが成立したことを示すマッチング履歴情報101aに基づいて通知された第2のマッチングサービスにおいて企画されたイベントに参加することができる。
ここでは、マッチング履歴情報101aに含まれる企画者(ユーザX)に対してイベントが通知されるものとして説明したが、当該マッチング履歴情報101aに含まれる参加者(ユーザY)に対してイベントが通知されても構わない。この場合、ステップS82においては、ユーザYにマッチングさせるべき他のユーザによって企画されたイベントが特定されればよい。
以下、本実施形態に係るマッチングシステムの利用態様の具体例について説明する。ここでは、本実施形態に係るマッチングシステムにおいてユーザが利用可能な第1〜第3のマッチングサービスが前述した第1の実施形態において説明した食事会マッチング、ネイリストマッチング及びゴルフコーチマッチングであるものとする。
まず、ユーザX及びユーザYが食事会マッチングにおいてマッチングされた(つまり、男性ユーザXによって企画された食事会イベントに女性ユーザYが参加する)場合を想定する。
この場合、例えば女性ユーザYは、食事会イベントの開催前にネイリストによるネイルの施術を受けたいと考える場合がある。このため、本実施形態に係るマッチングシステムにおいては、食事会マッチングに関連するマッチングサービスとしてネイリストマッチングが決定され、当該ネイリストマッチングにおいてネイリストである他のユーザによって企画されたネイリストイベント(つまり、ネイリストがネイルを施術するイベント)を女性ユーザYに通知するものとする。なお、各マッチングサービスに関連するマッチングサービスは予め設定されているものとする。
ここで、女性ユーザYに対して通知するネイリストイベントは、上記した図14に示すステップS83のイベント特定処理によって特定される。この場合、食事会イベントにおいて男性ユーザX及び女性ユーザYがマッチングされたことを示すマッチング履歴情報に含まれる開催日時及びマッチングポイント等を利用してネイリストイベントが特定されても構わない。
具体的には、例えば食事会イベントが開催される当日に開催されるネイリストイベントの場合には、当該食事会イベントの開催日時よりも予め定められた時間前(例えば、数時間前)に開催されるネイリストイベントであって、食事会イベントにおけるマッチングポイントに比較的近い場所(マッチングポイント)で開催されるネイリストイベントが特定されるものとする。一方、食事会イベントが開催される日よりも前に開催されるネイリストイベントであれば、例えば女性ユーザYの住所に近いマッチングポイントで開催されるネイリストイベントが特定されればよい。
本実施形態においては、このように食事会イベントにおいてマッチングされたことを示すマッチング履歴情報に基づいて、当該食事会イベントに関連づけてネイリストイベントを通知し、当該ネイリストイベントにおいても女性ユーザYを他のユーザ(ここでは、ネイリストであるユーザ)とマッチングさせることが可能となる。
ここでは、女性ユーザYに対してネイリストイベントが通知されるものとして説明したが、当該女性ユーザYに対して通知すべきネイリストイベントがないような場合には、当該女性ユーザYがネイルの施術を受けるためのネイリストイベントを企画するように促す構成としてもい。
次に、ユーザX及びユーザYがネイリストマッチングにおいてマッチングされた(つまり、ネイルの施術を受けるユーザXによって企画されたネイリストイベントにネイリストであるユーザYが参加する)場合を想定する。
この場合、例えばユーザXは、ネイリストイベントの終了後に食事会に参加したいと考える場合がある。このため、本実施形態に係るマッチングシステムにおいては、ネイリストマッチングに関連するマッチングサービスとして食事会マッチングが決定され、当該食事会マッチングにおいて他のユーザによって企画された食事会イベントをユーザXに通知するものとする。
ここで、ユーザXに対して通知する食事会イベントは、ネイリストイベントにおいてユーザX及びユーザYがマッチングされたことを示すマッチング履歴情報に含まれる開催日時及びマッチングポイント等を利用して特定されても構わない。
具体的には、例えばネイリストイベントの開催日時よりも予め定められた時間後(ネイルの施術が終了した後)に開催される食事会イベントであって、ネイリストイベントにおけるマッチングポイントに比較的近い場所(マッチングポイント)で開催される食事会イベントが特定されるものとする。
本実施形態においては、このようにネイリストイベントにおいてマッチングされたことを示すマッチング履歴情報に基づいて、当該ネイリストイベントに関連づけて食事会イベントを通知し、当該食事会イベントにおいてもユーザXを他のユーザとマッチングさせることが可能となる。
ここでは、ユーザXに対して食事会イベントが通知されるものとして説明したが、当該ユーザXに対して通知すべき食事会イベントがないような場合には、当該ユーザXが食事会イベントを企画するように促す構成としてもい。
次に、ユーザX及びユーザYがゴルフコーチマッチングにおいてマッチングされた(つまり、ゴルフのレッスンを受けるユーザXによって企画されたゴルフコーチイベントにゴルフのコーチであるユーザYが参加する)場合を想定する。
この場合、例えばゴルフのレッスンを受けるユーザXは、ゴルフのレッスンの終了後に食事をしたいと考える場合がある。このため、本実施形態に係るマッチングシステムにおいては、ゴルフコーチマッチングに関連するマッチングサービスとして食事会マッチングが決定され、当該食事会マッチングにおいて他のユーザによって企画された食事会イベントをユーザXに通知するものとする。
ここで、ユーザXに対して通知する食事会イベントは、ゴルフコーチイベントにおいてユーザX及びユーザYがマッチングされたことを示すマッチング履歴情報に含まれる開催日時及びマッチングポイント等を利用して特定されても構わない。
具体的には、例えばゴルフコーチイベントの開催日時よりも予め定められた時間後(例えば、ゴルフのレッスンが終了した後)に開催される食事会イベントであって、ゴルフコーチイベントにおけるマッチングポイントの近傍で開催される食事会イベントが特定されるものとする。
本実施形態においては、このようにゴルフコーチイベントにおいてマッチングされたことを示すマッチング履歴情報に基づいて、当該ゴルフコーチイベントに関連づけて食事会イベントを通知し、当該食事会イベントにおいてもユーザXを他のユーザとマッチングさせることが可能となる。
なお、ここで説明したマッチングシステムの利用態様は一例であり、前述した第1の実施形態において説明したように当該マッチングシステムが様々なマッチングサービスに適用可能であることを考慮すると、例えばホテルを経営する企業とユーザ(客)とがマッチングされた場合には、当該ホテルに宿泊する日時(つまり、イベントの開催日時)の前後に、タクシー(の運転手)及び当該ユーザをマッチングさせるようなことも可能である。
上記したように本実施形態においては、所定のマッチングサービス(第1のマッチングサービス)において企画されたイベント(第1のイベント)においてユーザX(第1のユーザ)及びユーザY(第2のユーザ)がマッチングされたことを示すマッチング履歴情報に基づいて、当該所定のマッチングサービスに関連する他のマッチングサービス(第2のマッチングサービス)において企画されたイベント(第2のイベント)をユーザXに通知することによって、当該イベントにおいてユーザX及び他のユーザ(第3のユーザ)をマッチングさせる。
すなわち、本実施形態においては、いずれかのマッチングサービスにおいてマッチングされたことを示すマッチング履歴情報を利用することによって、次にマッチングされるべきユーザ(候補者)によって企画されたイベントを通知することができる。
本実施形態においては、このような構成により、マッチングシステム(マッチング装置100)において提供されるサービスプラットフォーム100aにより利用可能となる複数のマッチングサービスにおけるマッチング効率を向上させることが可能となる。
また、本実施形態においては、上記したように所定のマッチングサービスにおいて企画されたイベントにおいてマッチングされたユーザXに対して、当該イベントに関連のある他のマッチングサービスにおいて企画されたイベントが通知されるため、当該ユーザXの利便性を向上させることが可能となる。
なお、上記した実施形態に記載した手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク(フロッピー(登録商標)ディスク、ハードディスクなど)、光ディスク(CD−ROM、DVDなど)光磁気ディスク(MO)、半導体メモリなどの記憶媒体に格納して頒布することもできる。
また、この記憶媒体としては、プログラムを記憶でき、かつコンピュータが読み取り可能な記憶媒体であれば、その記憶形式は何れの形態であってもよい。
また、記憶媒体からコンピュータにインストールされたプログラムの指示に基づきコンピュータ上で稼働しているOS(オペレーティングシステム)や、データベース管理ソフト、ネットワークソフト等のMW(ミドルウェア)等が本実施形態を実現するための各処理の一部を実行してもよい。
更に、本発明における記憶媒体は、コンピュータと独立した媒体に限らず、LANやインターネット等により伝送されたプログラムをダウンロードして記憶または一時記憶した記憶媒体も含まれる。
また、記憶媒体は1つに限らず、複数の媒体から本実施形態における処理が実行される場合も本発明における記憶媒体に含まれ、媒体構成は何れの構成であってもよい。
なお、本発明におけるコンピュータは、記憶媒体に記憶されたプログラムに基づき、本実施形態における各処理を実行するものであって、パソコン等の1つからなる装置、複数の装置がネットワーク接続されたシステム等の何れの構成であってもよい。
また、本発明におけるコンピュータとは、パソコンに限らず、情報処理機器に含まれる演算処理装置、マイコン等も含み、プログラムによって本発明の機能を実現することが可能な機器、装置を総称している。
なお、本願発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組合せてもよい。