以下、添付図面を参照しながら本発明の実施形態を詳細に説明する。なお、図面の説明において同一又は同等の要素には同一の符号を付し、重複する説明を省略する。
図1は、本実施形態に係るレコメンドシステム1の機能的構成を示すブロック図である。本実施形態のレコメンドシステム1は、プランをユーザにレコメンドするシステムである。プランは、インターネットを介してユーザによる閲覧及び購入の対象となり得るものであって、少なくとも日付に関する情報が対応付けられており、さらに、場所に関する情報が対応付けられていてもよい。具体的には、プランは、例えば、ゴルフプラン及び旅行プラン等である。ゴルフプランには、プレー日が日付に関する情報として対応付けられており、ゴルフコースに関する情報が場所に関する情報として対応付けられている。また、旅行プランには、旅行の日程が日付に関する情報として対応付けられており、旅行の行き先に関する情報が場所に関する情報として対応付けられている。本実施形態は、ゴルフプランの例により説明する。
ゴルフのプランには、例えば、ゴルフ場の場所に関するコース情報及び日時の情報を含む。また、プランには、料金及びその他の条件等の情報が含まれる。インターネットを介してゴルフのプランの予約及び決済を行う従来の情報システムは、例えば、ユーザからゴルフ場を指定する入力を受け付け、指定されたゴルフ場に対応付けられたプランを提示する。
一方、インターネットを介して商品等を販売する情報システムには、協調フィルタリングによるレコメンデーションを行うものがある。このような情報システムでは、ユーザが購入した商品や閲覧した商品等の利用履歴を記憶しておき、利用履歴に基づいて、そのユーザの嗜好、傾向に合った商品等を抽出し、ユーザに提示する。従来のゴルフ等のプランを提示するシステムでは、このような協調フィルタリングによるレコメンデーションを適用することができる。例えば、ユーザが行ったことがあるゴルフ場に行ったことがある他のユーザが行ったことがあるゴルフ場を、ユーザに提示することができる。
しかしながら、ユーザに対してゴルフ場を提示し、ユーザからのゴルフ場の選択を受け付けても、そのゴルフ場に対応付けられたプランが多数存在して、ユーザの希望に合うプランを見つけることが困難である場合があった。また、選択されたゴルフ場に対応付けられたプランの中に、ユーザの希望に合うプランが存在しない場合には、ユーザはゴルフ場を選択する操作を再度行う必要があり、煩雑であった。
また、ゴルフ等のプランをレコメンドするために、協調フィルタリングによりレコメンドするプランを抽出することが考えられる。しかしながら、協調フィルタリングには、ユーザが購入及び閲覧等した複数の商品間に一定程度の相関関係が見出される必要があるところ、プランといった商品は、その商品の特性上、ユーザに対して販売される期間が短いため、プラン間の相関が形成されにくい。従って、協調フィルタリングにより適切なプランのレコメンドを行うことは困難である。
本実施形態のレコメンドシステム1は、かかる問題を解決して、ユーザの希望に合うプランをユーザに提示可能とするものである。
図1に示すように、本実施形態のレコメンドシステム1は、レコメンド装置10及び端末30を含む。端末30は、ユーザの端末であって、インターネット等のネットワークNを介してレコメンド装置10と通信可能である。レコメンド装置10は、プラン情報記憶部21及びユーザ情報記憶部22にアクセス可能である。
レコメンド装置10は、機能的には、取得部11、算出部12(抽出手段)及び送信部13(抽出手段)を含む。また、端末30は、ユーザID送信部31、プラン情報取得部32(抽出手段)、表示制御部33(表示制御手段)及び受付部34(受付手段)を含む。
プラン情報記憶部21は、プラン情報を記憶している記憶手段である。プラン情報記憶部21は、レコメンド装置10の一機能部として構成されることとしてもよい。また、プラン情報記憶部21は、レコメンド装置10とネットワークを介して通信可能なコンピュータ装置に構成されることとしてもよい。なお、プラン情報の詳細については後述する。
ユーザ情報記憶部22は、ユーザのプランの購入履歴をユーザ情報として記憶している記憶手段である。ユーザ情報記憶部22は、レコメンド装置10の一機能部として構成されることとしてもよい。また、ユーザ情報記憶部22は、レコメンド装置10とネットワークを介して通信可能なコンピュータ装置に構成されることとしてもよい。なお、プラン情報の詳細については後述する。なお、ユーザ情報としてのプランの購入履歴の詳細については後述する。
図2は、レコメンド装置10のハードウェア構成図である。レコメンド装置10は、物理的には、図2に示すように、プロセッサにより構成されるCPU101、RAM及びROMといったメモリにより構成される主記憶装置102、ハードディスク等で構成される補助記憶装置103、ネットワークカード等で構成される通信制御装置104、入力デバイスであるキーボード、マウス等の入力装置105、ディスプレイ等の出力装置106などを含むコンピュータシステムとして構成されている。なお、レコメンド装置10がサーバに構成される場合には、レコメンド装置10は、入力装置105,出力装置106を含まなくてもよい。
図1に示したレコメンド装置10の各機能は、図2に示すCPU101、主記憶装置102等のハードウェア上に所定のコンピュータソフトウェア(レコメンドプログラム)を読み込ませることにより、CPU101の制御のもとで通信制御装置104、入力装置105、出力装置106を動作させるとともに、主記憶装置102や補助記憶装置103におけるデータの読み出し及び書き込みを行うことで実現される。処理に必要なデータやデータベースは主記憶装置102や補助記憶装置103内に格納される。
また、端末30も、レコメンド装置10と同様のハードウェア構成を有するコンピュータシステムである。端末30は、例えば、パーソナルコンピュータ、スマートフォン等の装置として構成される。
続いて、レコメンド装置10の機能部を説明する。取得部11は、ユーザを特定するユーザIDを取得する部分である。具体的には、取得部11は、端末30から送信されたユーザIDを取得する。
算出部12は、ユーザIDにより特定されるユーザによるプランの選択の履歴に基づいて、プランごとにスコアを算出する部分である。ユーザは、プランの購入または閲覧のためにプランの選択を行う。従って、プランの選択の履歴は、プランの購入及び閲覧のうちの少なくともいずれか一方に関する履歴である。なお、スコアの算出の詳細については後述する。本実施形態では、算出部12は、ゴルフプランの購入履歴を参照してスコアを算出することとする。なお、プランの閲覧履歴は、購入履歴と同様にプラン情報を含むものであるので、購入履歴に基づくスコアの算出と同様に、閲覧履歴に基づいてプランごとのスコアの算出が行われることとしてもよい。
図3は、ユーザのゴルフプランの購入履歴のデータの例を示す図である。ユーザ情報記憶部22は、ユーザのゴルフプランの購入履歴を記憶しており、算出部12は、ユーザ情報記憶部22にアクセスすることにより、ユーザIDに基づきユーザの購入履歴を取得できる。図3に示すように、ユーザ情報記憶部22は、例えば、ユーザIDごとに、プランID、プレー日、コースID及びプラン料金等をユーザの購入履歴として記憶している。プランIDは、ゴルフプランを識別する識別情報である。プレー日は、当該ゴルフプランによるプレーが行われた日付の情報である。コースIDは、当該ゴルフプランに係るゴルフコースを識別する識別情報である。プラン料金は、当該ゴルフプランの料金である。
ゴルフプランの詳細な内容は、プラン情報記憶部21に記憶されている。図4は、プラン情報記憶部21に記憶されているプラン情報の項目の構成の例を示す図である。プラン情報は、プランIDに対応付けて、プランの内容を示す各種の情報を含む。コースIDは、ゴルフコースを識別する情報である。プラン名称は、当該プランの名称である。プラン料金は、当該プランを購入するための料金である。公開期間開始及び公開期間終了は、当該プランが実施される期間の開始日及び終了日を示す情報である。曜日区分及び対象曜日は、当該プランが適用される曜日を示す情報である。対象スタート時間帯は、当該プランのプレーを開始可能な時間帯を示す情報である。即ち、公開期間開始、公開期間終了、曜日区分、対象曜日及び対象スタート時間帯は、当該プランの日付に関する属性を示すデータに該当する。
プラン情報は、その他オプション等に関する情報をさらに含む。昼食は、プランに昼食が含まれるか否かを示す情報である。キャディフラグは、プランにキャディが含まれるか否かを示す情報である。カートコードは、プレーする際に使用するカートの種別を表す情報である。プレー人数(最小)及びプレー人数(最大)は、当該プランでプレーする際の1組の人数の下限及び上限を示す情報である。その他、プラン情報は、4サム割引、2サム保証、オプション1及びオプション2等に関する情報を含んでいる。
算出部12は、ユーザの購入履歴に含まれるプランIDをキーとしてプラン情報を参照することにより、ユーザが購入したゴルフプランの内容を取得できる。そして、算出部12は、ユーザの購入履歴及びプラン情報に基づいて、ユーザの購入履歴を示すユーザビヘイビアデータを生成することができる。図5は、ユーザビヘイビアデータの項目と値の例を示す図である。ユーザビヘイビアデータは、ユーザの購入履歴に関する情報処理を実施するために、ユーザの購入履歴を情報処理に適した形式でデータ化したものである。ユーザビヘイビアデータは、例えば種々の項目の値からなる多次元のベクトルデータとして生成されてもよい。具体的には、ユーザビヘイビアデータは、ユーザの購入履歴に含まれる各種の項目の値を取得し、その平均値及び標準偏差、またはそれらを正規化した値等により構成される。
図5に示す例では、MAX、COUNT、AVG及びSTDはそれぞれ、かっこ内の値の最大値、計数値、平均値及び標準偏差を示す。MAX(play_date)は、最近のプレー日を示す。COUNT(c_id)は、購入履歴に含まれるコースIDの数を示し、COUNT(DISTINCT c_id)は、購入履歴に含まれるコースIDの数から重複分を除いた数を示す。HOUR(start_time)は、プレーの開始時間を示す。lunch_flgは、昼食ありのフラグを示す。caddie_flagは、キャディありのフラグを示す。play_feeは、プランの料金を示す。play_memは、プレーする人数を示す。play_day_weekend_flgは、プラン情報における週末を示すフラグである。play_day_hol_flgは、プラン情報における休日を示すフラグである。golfCourceLatは、ゴルフコースの所在地の緯度を示す。golfCourceLonは、ゴルフコースの所在地の経度を示す。
ユーザの購入履歴に基づくユーザビヘイビアデータの生成は、周知技術によって実現可能である。また、ユーザビヘイビアデータは、算出部12により生成されてもよいし、他の機能部や他の装置により生成されてもよい。また、図5に示すユーザビヘイビアデータの例は、ユーザの購入履歴を表すものであるが、1つのプランの内容を、ユーザビヘイビアデータと同様の形式で表したデータを生成することができる。即ち、プランの内容を表すデータは、例えば、プランの内容を示す複数の項目とその項目の値を含むベクトルデータとして表すことができる。このようなデータも、周知技術により実現可能である。
このようなデータにより、プランの内容に関する種々の情報処理が容易となる。即ち、ユーザビヘイビアデータは、ユーザが好むプランの特徴を示すものということもできるので、プランの内容を示すデータと、ユーザビヘイビアデータとの対比や、両ベクトルデータ間の距離の算出等により、当該プランとユーザが好むプランとの類似性が判断できる。また、他のユーザのユーザビヘイビアデータとの対比や、ベクトルデータ間の距離の算出により、協調フィルタリングに際しての、ユーザ間の類似度を判断できる。
再び図1を参照して、送信部13は、算出部12によりスコアが算出されたプラン情報を、算出されたスコアと共に、端末30に送信する部分である。送信部13は、予め設定された所定数のプラン情報を端末30に送信することとしてもよい。
続いて、端末30の機能部について説明する。ユーザID送信部31は、ユーザIDをレコメンド装置10に送信する。ユーザID送信部31は、例えば、端末30におけるログイン処理において入力されたユーザIDをレコメンド装置10に送信する。
プラン情報取得部32は、レコメンド装置10から送信されたプラン情報を取得する部分である。具体的には、プラン情報取得部32は、レコメンド装置10の送信部13からの、各々スコアが対応付けられたプラン情報を取得する。
表示制御部33は、プラン情報取得部32により取得されたプラン情報を、端末30の表示手段に表示された第1の表示欄に時系列に日付ごとに表示させる部分である。表示制御部33によるプラン情報の表示制御の詳細については、後に詳述する。
受付部34は、表示制御部33により表示されたプラン情報に対するユーザからの選択入力を受け付ける部分である。プラン情報に対する選択入力の受け付けに関する処理については、後に詳述する。
次に、図6〜11を参照して、本実施形態のレコメンド処理、スコア算出処理、プラン情報の表示制御処理について詳細に説明する。
図6は、本実施形態のレコメンドシステム1におけるレコメンド処理を示すフローチャートである。
まず、端末30のユーザID送信部31は、ユーザIDをレコメンド装置10に送信する(S1)。続いて、レコメンド装置10の取得部11は、ステップS1において送信されたユーザIDを取得する(S2)。
次に、レコメンド装置10の算出部12は、ユーザIDにより特定されるゴルフプランの購入履歴に基づいて、プランごとのスコアを算出する(S3)。図7は、ステップS3におけるスコア算出処理の第1の例を示すフローチャートである。図7を参照してスコア算出処理を説明する。
算出部12は、ステップS2において取得したユーザIDに基づき、ユーザ情報記憶部22を参照して、ユーザの購入履歴を取得する(S11)。また、算出部12は、購入履歴に含まれるプランのプラン情報を取得するためにプラン情報記憶部21も併せて参照する。
続いて、算出部12は、購入履歴において、過去に購入された一のプラン情報のプランIDをリファレンスプラン(参照プラン情報)として取得する(S12)。算出部12は、例えば、購入履歴における最新のプラン情報をリファレンスプランとして取得してもよい。これにより、ユーザの希望に合う属性を有している蓋然性が高いプラン情報が、リファレンスプランとして取得される。また、算出部12は、現在の季節に対応する時期に購入されたプランのプラン情報をリファレンスプランとして取得してもよい。
次に、算出部12は、リファレンスプランとして取得したプランのプランIDに対応付けられたコースID(参照場所情報)を取得する(S13)。そして、算出部12は、リファレンスプランのコースIDに基づき、レコメンドするコースのコースID(場所情報候補)を取得する(S14)。算出部12は、ユーザの購入履歴等に基づいて、コースIDを取得するための複数の手法のうちの少なくとも一つの手法を決定し、決定された手法を用いてコースIDを取得する。取得されたコースIDに基づきプランが抽出されるので、コースIDの取得のための手法を決定することは、プランを抽出するための手法を決定することを意味する。コースIDの取得のための手法としては、例えば、ユーザの購入履歴に基づく手法、協調フィルタリングによる手法、ゴルフのコース及びユーザの地理的情報に基づく手法等がある。以下に、このコースID(場所情報)を取得するコースID取得処理を、図8を参照して説明する。
図8は、ステップS14におけるコースID取得処理の例を示すフローチャートである。算出部12は、ユーザの購入履歴に含まれるプランに対応付けられたコースのうち、所定の条件を満たすコースのコースIDをレコメンドするコースの情報として取得する(S21)。所定の条件は、例えば、ユーザの購入履歴において所定回数以上利用しているコースであること、である。これにより、ユーザの履歴が優先的に用いられてレコメンドするコースのコースIDが取得されるので、取得されたコースIDにユーザの履歴がより強く反映されることとなる。
すなわち、ユーザが実際に購入したプランのコースはユーザの嗜好に合っている可能性が高いため、そのコースのコースIDが優先的に用いられる。このため、コースIDの取得のための条件としての所定回数は1回であってもよい。ただし、ユーザがあるコースが対応付けられたプランを一度購入したとしても、その後にそのコースが対応付けられたプランが購入されなかった場合には、そのコースは、ユーザが一度は気になったものの、よく調べてみたらあまり条件に合わないコースであったり、実際にプレーしてみたらあまり気に入らなかったコースであったりする場合もある。これに対し、複数回購入されたコースは、ユーザがそのコースを気に入って利用している可能性が高い。そこで、コースIDの取得のための条件としての所定回数を2かそれ以上としてもよい。このようにすれば、複数回購入したコースのコースIDのみが取得される。
図8に示す処理の例では、ユーザにレコメンドするためのコースの候補の数が予め設定されている。そこで、算出部12は、ステップS21において取得されたコースIDの数が予め設定された所定数未満であるか否かを判定する(S22)。コースIDの数が所定数未満であると判定された場合には処理はステップS23に進められる。一方、コースIDの数が所定数未満であると判定されなかった場合にはコースID取得処理は終了する。
ステップS23において、算出部12は、ユーザの履歴に基づく協調フィルタリング及びユーザに対応付けられた地理的情報の内の少なくともいずれか一方に基づきコースIDを取得する(S23)。
具体的には、算出部12は、例えば、ユーザのゴルフプランの購入履歴(図3参照)を参照して、ユーザが購入したことがあるプランに対応付けられたコースと同じコースが対応付けられたプランを購入したことがある他のユーザを抽出する。そして、算出部12は、他のユーザの購入履歴におけるプランに対応付けられたコースのコースIDを取得する。また、算出部12は、図5を参照して説明したようなユーザビヘイビアデータを用いて、当該ユーザと他のユーザとの類似度を算出して、所定程度以上の類似度を有する他のユーザの購入履歴におけるプランに対応付けられたコースのコースIDを取得してもよい。
また、地理的情報に基づくコースIDの取得として、具体的には、算出部12は、リファレンスプランのコースと地理的に近い(例えば、所定の距離以内に所在する)コースのコースIDを取得する。また、算出部12は、ユーザの所在地と地理的に近い(例えば、所定の距離以内に所在する)コースのコースIDを取得してもよい。
ステップS23の処理は、取得したコースIDの数が所定数以上になるまで、繰り返される。このように、算出部12は、コースIDを取得するための手法として、複数の手法のうちのいずれかの手法を決定し、コースIDの取得処理を実施する。ここで、例えばステップS21の所定の条件における所定回数が2であり、ステップS22における所定数が40であったような場合、40のコースIDのうち、ユーザの履歴において2回以上利用しているコースのコースIDが全て抽出されるとともに、それ以外については、協調フィルタリングや地理的情報により抽出されたコースIDが含まれることになる。すなわち、2回以上利用しているコースが多ければ多いほど、40のコースIDのうちで履歴に基づいて抽出されたコースIDの割合が多くなる。このようにすれば、ユーザの利用状況に応じて、コースIDを抽出するための手法の割合を調整するように制御することができる。
また、算出部12は、ステップS21〜S23の処理に代えて、ユーザの購入履歴における購入されたプランの件数に応じてコースID取得処理を行うこととしてもよい。即ち、算出部12は、ユーザの購入履歴において、購入されたプランの件数が所定数以上である場合には、購入履歴に含まれるプランに対応付けられたコースのうち、所定の条件(ステップS21における所定の条件と同様)を満たすコースのコースIDをレコメンドするコースの情報として取得し、ユーザの購入履歴において、購入されたプランの件数が所定数未満である場合には、ユーザの履歴に基づく協調フィルタリング及びユーザに対応付けられた地理的情報の内の少なくともいずれか一方に基づきコースIDを取得する。このように、算出部12は、ユーザの購入履歴に基づく手法、協調フィルタリングによる手法、ゴルフのコース及びユーザの地理的情報に基づく手法等のいずれかの手法を用いて、コースIDの取得処理を実施する。
このようなコースID取得処理によれば、ユーザの購入履歴においてプランの件数が少ない場合には、その購入履歴がユーザの希望を適切に反映しにくい場合があるところ、購入履歴においてプランの件数が所定数以上である場合に、ユーザの購入履歴に含まれるプランに対応付けられた場所の情報に基づきコースIDが取得されるので、取得されたコースIDには適切にユーザの希望が反映されることとなる。一方、ユーザの購入履歴においてプランの件数が所定数未満である場合には、協調フィルタリングまたはユーザの地理的情報に基づきコースIDが取得されるので、ユーザの希望に合う蓋然性が高い場所情報候補が得られる。
また、算出部12は、複数の手法のそれぞれを用いて取得されたコースIDに基づき抽出されたプランと、ユーザの購入履歴等に含まれるプラン等との一致の程度に基づき、コースIDを取得するための手法を決定してもよい。即ち、算出部12は、複数の所定の手法のそれぞれによりコースIDを取得し、所定の手法ごとに、コースIDに対応付けられているプラン情報候補の取得、各プラン情報候補のスコアの算出、及び、算出されたスコアに基づくプラン情報候補の中からのプランの抽出、を実施し、抽出したプランの、履歴に含まれるプランに対する一致の程度が最も高い所定の手法を、ユーザにレコメンドするプランを抽出するための手法として決定することとしてもよい。なお、プランごとのスコアの算出及びスコアに基づくプランの抽出については後述する。
具体的には、算出部12は、例えば、ユーザの購入履歴に基づく手法、協調フィルタリングによる手法(パラメータや重みが異なる複数種類の協調フィルタリングでもよい)、ゴルフのコース及びユーザの地理的情報に基づく手法のそれぞれによりコースIDを取得する。次に、算出部12は、各手法により取得されたコースIDに対応付けられているプラン情報をプラン情報候補として取得し、取得したプラン情報候補のスコアを算出し、レコメンドするプランの候補となるプランをスコアに基づき抽出する。
そして、算出部12は、手法ごとに抽出されたプランと、ユーザの購入履歴に含まれるプランとの一致の程度を判定し、一致の程度が最も高い手法を、コースIDの取得に用いる手法として決定する。
このように、各手法を用いて抽出されたプランと、履歴に含まれるプランとの一致の程度に基づき、場所情報候補の取得のための最適な手法が選択される。これにより、ユーザの希望にあうプランが抽出される蓋然性が高い手法が、ユーザにレコメンドするプランを抽出するための手法として決定される。これにより、ユーザの希望に合うプランが抽出される蓋然性が高められる。
また、本実施形態のレコメンドシステム1では、以下のようにコースIDを取得するための手法を決定してもよい。
例えば、算出部12は、ユーザの購入履歴を参照して、購入されたプランに対応付けられたゴルフのコースのうち、複数回(例えば2回)の購入の履歴があるコースの数を取得する。そして、算出部12は、当該レコメンドシステム1において選択可能なコースの総数に対する複数回の購入の履歴があるコースの数の割合を算出し、算出した割合が所定値以上である場合に、ユーザの購入履歴に基づく手法を優先的に用いて、コースIDを取得する処理を実施する。
ユーザの購入履歴に基づく手法を優先的に用いた処理とは、コースIDを取得する処理としてユーザの購入履歴に基づく手法を選択することであってもよいし、複数の手法を用いる場合において、ユーザの購入履歴に基づく手法に対する重み付けを他の手法よりも重くすることであってもよい。一の手法を優先的に用いた処理の意味は、以下のコースIDを取得するための手法の決定の説明において、上記説明と同様である。
また、算出部12は、ユーザの購入履歴または閲覧履歴を参照して、購入または閲覧のために選択入力が行われたプランの総数に対しての、複数の手法のうちのある手法を用いてレコメンドされたプランに対して購入または閲覧のために選択入力が行われたプランの数の割合を算出し、算出された割合が所定値以上である場合に、当該手法を優先的に用いて、コースIDを取得する処理を実施することとしてもよい。
また、例えば、算出部12は、ユーザの端末30において現在表示されているページを取得する。そして、表示されているページがプランを検索するための検索画面である場合には、ユーザが自身の履歴には含まれていないプランやコースを希望している蓋然性が高いので、算出部12は、ユーザの購入履歴に基づく手法以外の手法を優先的に用いて、コースIDを取得する処理を実施することとしてもよい。一方、表示されているページがいわゆるマイページと呼ばれるような当該ユーザの履歴等に関する情報を表示するページである場合には、ユーザが自身の履歴には含まれているプランやコースを希望している蓋然性が高いので、算出部12は、ユーザの購入履歴に基づく手法を優先的に用いて、コースIDを取得する処理を実施することとしてもよい。
また、算出部12は、現在の日付に基づいて、現在がいわゆる繁忙期に該当するか、非繁忙期または閑散期に該当するか、を取得する。各日付と、繁忙期、非繁忙期及び閑散期との対応付けは予め設定されている。そして、繁忙期にはユーザが過去に利用したことのあるコースを利用する傾向があることに鑑みて、現在が繁忙期である場合には、算出部12は、ユーザの購入履歴に基づく手法を優先的に用いて、コースIDを取得する処理を実施することとしてもよい。一方、ユーザにおいて、過去に利用したことがないコースを利用する場合には繁忙期を避ける傾向があることに鑑みて、現在が非繁忙期または閑散期である場合には、算出部12は、ユーザの購入履歴に基づく手法以外の手法を優先的に用いて、コースIDを取得する処理を実施することとしてもよい。
再び図7を参照して、ステップS15において、算出部12は、ステップS14において取得したコースIDに対応付けられているプランID及びそのプラン情報を、ユーザにレコメンドするプラン情報候補として取得する(S15)。具体的には、算出部12は、プラン情報記憶部21を参照して、ステップS14において取得したコースIDに対応付けられているプランIDのうち、例えば、プレーが可能な日として現在の日付から1週間後〜3週間後の日付が対応付けられているプランID及びプラン情報を取得する。
次に、算出部12は、ステップS15において取得されたプラン情報候補ごとにスコアを算出する(S16)。具体的には、算出部12は、ユーザの購入履歴及びリファレンスプランのプラン情報のうちの少なくともいずれか一方及びプラン情報候補の属性に基づきスコアを算出する。
例えば、算出部12は、プラン情報候補の属性と、購入履歴またはリファレンスプランの属性との類似度に基づき、そのプラン情報候補のスコアを算出する。こうして算出されるスコアは、類似度が高いほど高い値を有する。以下に具体的に説明する。
算出部12は、例えば、以下に示すような式(1)によりプラン情報候補ごとにスコアを算出する。
式(1)における左辺は、プラン情報候補のスコアを表す。右辺の第1項は、プラン情報候補と、リファレンスプランまたはユーザのユーザビヘイビアデータとの料金の類似度を表す。w
pは所定の係数であって、設計的に設定される。右辺第1項の詳細は、例えば式(2)のように表すことができる。
式(2)における第1辺のS(price|price
ref,u)は、プラン情報候補の料金と、リファレンスプランまたはユーザのユーザビヘイビアデータの料金との類似度を表す。また、t,t
refは、類似度の算出において時期の類似度を考慮することを意味する。
式(2)の第2辺の分母における第2項は、第3辺に示されるように、プラン情報候補の料金と、リファレンスプランまたはユーザのユーザビヘイビアデータとの料金との距離(distance)を表す。SD(priceuser)は、ユーザビヘイビアデータとの料金の標準偏差を表す。AVG(price)t及びAVG(price)trefはそれぞれ、算出対象のプランの時期における、プラン情報候補のプランの料金の平均及びリファレンスプランの料金の平均を表す。weekendratioは、平日の料金と週末(土曜、日曜、祝日)の料金との差を補正するための係数であって、プラン情報候補のプランが週末を対象とするものであって、リファレンスプランが平日を対象とする者である場合には、1より大きい数(例えば1.4)が設定され、プラン情報候補のプランが平日を対象とするものであって、リファレンスプランが週末を対象とするものである場合には、1より小さい数(例えば1.4の逆数)が設定される。この係数は、設計的または経験的に設定される。また、プラン情報候補のプラン及びリファレンスプランが共に平日を対象とするものである場合、プラン情報候補のプラン及びリファレンスプランが共に週末を対象とするものである場合には、この係数は1に設定される。price及びpricerefはそれぞれ、プラン情報候補及びリファレンスプランの料金である。
式(1)の右辺の第2項は、プラン情報候補と、リファレンスプランまたはユーザのユーザビヘイビアデータとのオプションの類似度を表す。オプションは、ゴルフプランの内容における昼食、キャディ、割引等の有無のであって、optは、これらの有無をデータ化(例えばベクトルデータとして)したものである。wkは所定の係数であって、設計的に設定される。nは、オプションの項目の数である。
式(1)の右辺の第3項は、プラン情報候補と、リファレンスプランまたはユーザのユーザビヘイビアデータとのコースに関する属性の類似度を表す。courceは、プラン情報候補のコースに関する属性をデータ化(例えばベクトルデータとして)したものである。courcerefは、リファレンスプランまたはユーザのユーザビヘイビアデータにおけるコースに関する属性をデータ化(例えばベクトルデータとして)したものである。
以上のように、プラン情報候補と、リファレンスプランまたはユーザのユーザビヘイビアデータの属性をデータ化(例えばベクトルデータとして)し、その類似度(例えばベクトル間の距離)を算出することにより、プラン情報候補のスコアが算出される。式(1)及び式(2)に示すように、本実施形態では、料金、プランの各種属性、コース等の各種の要素ごとの類似度を算出し、それぞれ係数により重みを調整した上で算出された類似度を加算することにより、スコアが算出される。このようにスコアが算出されることにより、各種の要素がスコアに対して適切に反映されることとなるので、スコアに基づくプランのレコメンドは、ユーザの希望に合うものとなる可能性が高い。なお、式(1)及び式(2)によるスコア算出は、スコア算出の一例であって、スコア算出に用いられる類似度は、種々の周知技術により算出可能である。このようにスコアが算出されることにより、算出されたスコアには、プラン情報候補のユーザの希望に合う度合いが反映されることとなる。
すなわち、プランには、料金、プランの各種属性、コース等の各種の要素が含まれているが、従来のレコメンドシステムは、一要素であるコースに着目して他のコースであるゴルフ場をレコメンドすることにとどまるものであった。これは、上述したように、プランのような有効期間が限定されるものでは、協調フィルタリングが有効に機能しない場合があるためである。このため、従来は、長期的に存在し、かつユーザにとって重要な要素であると考えられるコースに着目し、コースによる協調フィルタリングを行っていた。しかしながら、コースはプランの一要素に過ぎず、実際には、ユーザはコース以外のプランの要素に着目してプランを選択していたり、複数の要素を総合的に判断してプランを選択していることがあると考えられる。そこで、本実施形態では、上述したように、プランを要素に分解し、それぞれの要素ごとにリファレンスプランとプラン情報候補との類似度を算出し、プランの総合的なスコアを算出するようにした。このようなスコアにより、さまざまな要素を柔軟に考慮してユーザの嗜好に合ったプランを抽出し、レコメンドすることが可能になる。
次に、図9を参照して、ステップS3におけるスコア算出処理の第2の例を説明する。まず、算出部12は、ステップS2において取得したユーザIDに基づき、ユーザ情報記憶部22を参照して、ユーザの購入履歴を取得する(S31)。また、算出部12は、購入履歴に含まれるプランのプラン情報を取得するためにプラン情報記憶部21も併せて参照する。
次に、算出部12は、ユーザの購入履歴に含まれる複数のプランにおいて、プランに対応付けられた場所、即ちゴルフのコースが所在する場所に関して、所定の傾向の有無を判定する(S32)。所定の傾向とは、例えば、ユーザがゴルフのコースまでの距離に応じて、コース及びプランを選択しているような傾向である。
算出部12は、例えば、購入履歴に含まれる複数のプランにおいて、ユーザの所在地からコースまでの距離とプレーの開始時間との間に所定の程度以上の相関がある場合には、場所に関する所定の傾向が有ると判定する。相関の有無は、周知の統計処理により判定可能である。また、算出部12は、例えば、購入履歴に含まれる複数のプランに対応付けられたコースにおいて、ユーザの所在地から一定の距離にあるコースの割合が所定の程度以上である場合に、場所に関する所定の傾向が有ると判定してもよい。また、算出部12は、例えば、当該ユーザのユーザビヘイビアデータにおける地理的パラメータの標準偏差が所定の値以下である場合に、場所に関する所定の傾向が有ると判定してもよい。
次に、算出部12は、ステップS32において判定された、場所に関する所定の傾向の有無に応じて、プラン情報ごとのスコアを算出する。(S33)。スコアの算出は、ステップS16と同様に式(1)及び式(2)を用いて行われることとしてもよい。スコアの算出において、算出部12は、場所に関する所定の傾向の有無に応じて、地理的なパラメータに対する重み付けを設定する。地理的なパラメータは、例えば、スコアの算出に用いられる種々のパラメータのうちの場所に関連するパラメータであって、例えば、コースの場所、ユーザの所在地等に関わるパラメータである。即ち、算出部12は、ステップS32において、場所に関する所定の傾向があると判定された場合には、所定の傾向があると判定されなかった場合より、スコアの算出において地理的なパラメータが用いられる場合にそれらのパラメータに対する重み付けを重くする。このようにスコアが算出されることにより、算出されるスコアに対してユーザのプランに対する希望がより適切に反映されることとなる。
次に、図10を参照して、ステップS3におけるスコア算出処理の第3の例を説明する。まず、算出部12は、ステップS2において取得したユーザIDに基づき、ユーザ情報記憶部22を参照して、ユーザの購入履歴を取得する(S41)。また、算出部12は、購入履歴に含まれるプランのプラン情報を取得するためにプラン情報記憶部21も併せて参照する。
これにより、例えば、ユーザが、ユーザの所在地からより遠くに所在するコースのプランを選択する場合において、より遅い時間のプランを選択しているような傾向がある場合には、そのような傾向に沿ったプランを提示したり、ユーザが土曜日及び日曜日にしかプランを購入していない場合でも、ユーザの住所や勤務地の近くに存在するコースでナイターのプランが存在すればそのプランを提示するといった制御を行うことができる。
続いて、算出部12は、購入履歴において、過去に購入された一のプラン情報のプランIDをリファレンスプラン(参照プラン情報)として取得する(S42)。ステップS42の処理は、ステップS12の処理と同様である。次に、算出部12は、ユーザの購入履歴に含まれる複数のプランにおいて、プランに対応付けられた場所、即ちゴルフのコースが所在する場所に関して、所定の傾向の有無を判定する(S43)。ステップS43の処理は、ステップS32の処理と同様である。
次に、算出部12は、リファレンスプランとして取得したプランのプランIDに対応付けられたコースID(参照場所情報)を取得する(S44)。ステップS44の処理は、ステップS13の処理と同様である。
続いて、算出部12は、リファレンスプランのコースIDに基づき、レコメンドするコースのコースID(場所情報候補)を取得する(S45)。ここで、算出部12は、ステップS43において場所に関する所定の傾向があると判定された場合には、地理的なパラメータに重み付けをしてコースIDの取得処理を実施する。具体的には、例えば、図8を参照して説明したステップS14の処理では、ユーザの購入履歴に基づきコースIDを取得した(S21)後に、取得したコースIDが所定数に満たなかった場合に地理的情報に基づきコースIDを取得することとしたが、ステップS45では、算出部12は、まず地理的情報に基づきコースIDを取得し、その後に、取得したコースIDの数が所定数に満たなかった場合に、ユーザの購入履歴または協調フィルタリングによりコースIDを取得することとしてもよい。
次に、算出部12は、ステップS45において取得したコースIDに対応付けられているプランID及びそのプラン情報を、ユーザにレコメンドするプラン情報候補として取得する(S46)。ステップS46の処理は、ステップS15の処理と同様である。
次に、算出部12は、ステップS43において判定された、場所に関する所定の傾向の有無に応じて、プラン情報ごとのスコアを算出する。(S47)。ステップS47の処理は、ステップS33の処理と同様である。
図9及び図10を参照して説明したように、コースの所在地等の地理的な条件を考慮してスコアの算出を行うことにより、よりユーザのニーズに合ったレコメンドを行うことが可能となる。さらに、地理的な条件を考慮したレコメンドには、以下のような例が挙げられる。
例えば、ユーザの購入履歴において、コースの所在地とプレーの開始時間の相関において、ユーザの所在地からコースの所在地までの距離が遠いほど、プレーの開始時間が遅いプランを選択しているような傾向があれば、算出部12は、スコアの算出において、地理的なパラメータに対する重み付けをより重くする。
また、ユーザの購入履歴において、ユーザの所在地からの距離が一定の距離以内にあるコースが対応付けられたプランを購入しているような傾向があれば、算出部12は、ユーザの所在地から一定距離以内にあるコースのスコアが高くなるように、スコアの算出に際して、コースの所在位置に対する重み付けを重くする。また、ユーザの所在地からコースの所在地までの所用時間が一定の時間以内であるコースのスコアが高くなるように、スコアの算出に際して、コースの所在地に対する重み付けを重くしてもよい。一方、算出部12は、ユーザの所在地から一定距離以内にないコースについては、プレーの開始時間が遅いプランや、所在地以外のコースの属性がユーザの購入履歴にあるコースの属性と類似しているプランがレコメンドされるように、そのようなプランのスコアを高くする。
また、ユーザの所在地や勤務地からの距離が一定の距離以内であって、プレーの開始時間が遅いプラン(例えば、18時以降)が存在する場合には、そのようなプランがユーザにレコメンドされるように、算出部12は、そのようなプランのスコアが高くなるように、コースの所在地及びプレーの開始時間に対する重み付けを重くしてスコアを算出する。
また、ユーザの購入履歴において、一定領域内(例えば、県内)の所在するコースのプランばかりを購入している場合には、その領域内のコースのプランがレコメンドされるように、算出部12は、コースの所在地に対する重み付けを重くする。
再び図6を参照する。ステップS4において、レコメンド装置10の送信部13は、ステップS3において算出されたスコアを含むプラン情報を端末30に送信する(S4)。なお、算出部12は、算出されたスコアに基づいてプラン情報を抽出し、抽出したプラン情報を送信部13に送信させることとしてもよい。例えば、算出部12は、算出されたスコアが高いプランを上位のものから所定数抽出し、抽出したプランのプラン情報を送信部13に送信させることとしてもよい。これに対して、端末30のプラン情報取得部32は、レコメンド装置10から送信されたプラン情報を取得する(S5)。端末30に送信されるプラン情報は、少なくともプレー日の日付、コース(コースID)の情報(場所の情報)及びスコアを含み、更に、図4に示すようなプランに関する種々の情報の一部または全部を含んでもよい。
次に、端末30の表示制御部33は、ステップS5において取得したプラン情報を、端末30の表示手段に表示させる(S6)。例えば、表示制御部33は、取得したプラン情報から、スコアが高い順に所定数のプラン情報を抽出し、抽出したプラン情報を表示手段に表示させることとしてもよい。
また、表示制御部33は、プラン情報取得部32により取得されたプラン情報を、端末30の表示手段に表示された表示欄に時系列に日付ごとに表示させることとしてもよい。この表示処理の例を、図11を参照して説明する。
表示制御部33は、ステップS5において受信したプラン情報から、日付ごとにプラン情報を抽出する(S51)。そして、表示制御部33は、日付ごとに抽出したプラン情報を、第1の表示欄に時系列に日付ごとに表示する。第1の表示欄は例えばカレンダー形式で構成されている。カレンダーは、日付を表形式で表したものである。図12は、ステップS52において表示されたプラン情報の表示例を示す図である。図12に示すように、プラン情報は、カレンダーの日付ごとに表示されている。なお、表示制御部33は、各日付に対応付けられたプラン情報が複数ある場合には、同じ日付に対応付けられた複数のプラン情報のうち、スコアが最も高いプラン情報をその日付に対応付けて表示させることとしてもよいし、同じ日付に対応付けられた複数のプラン情報からランダムに選択したプラン情報をその日付に対応付けて表示させることとしてもよい。
なお、表示制御部33は、プラン情報を各日付に対応付けて表示させる際に、第1の日付に対応付けて表示するプラン情報に対応付けられた属性と異なる属性を含むプラン情報を第2の日付に対応付けて表示するように制御してもよい。この制御を、図13を参照して説明する。図13は、プラン情報の表示制御の例を示す図である。具体的には、図13において、表示制御部33は、日付「1月14日」(第1の日付)に対応付けて、コース「AAAカントリー」のプラン情報を表示させている。このとき、表示制御部33は、コース「AAAカントリー」とは異なる場所に関する属性であるコース「BBBゴルフクラブ」のプラン情報を日付「1月15日」(第2の日付)に対応付けて表示させる。このように、第1の日付に対応付けて表示されたプラン情報とは異なる属性を有するプラン情報が第2の日付に対応付けて表示されるので、ユーザは多様なプラン情報を得ることができる。
次に、受付部34は、ユーザによるプランの選択入力を受け付けたか否かを判定する(S53)。プランの選択入力が受け付けられた場合には、処理はステップS54に進む。ステップS54において、表示制御部33は、選択されたプランと同じ日付が対応付けられた他のプラン情報を第1の表示欄とは異なる第2の表示欄に表示する(S54)。具体的には、表示制御部33は、選択されたプランと同じ日付が対応付けられた他のプラン情報をカレンダーの表示欄(第1の表示欄)とは異なる別の欄(第2の表示欄)に表示する。
図14は、別の欄に表示されたプラン情報の表示例を示す図である。図14に示すように、受付部34により、カレンダー欄Cにおける日付「1月15日」の欄に表示されたプラン情報に対する選択入力が受け付けられると、表示制御部33は、日付「1月15日」が対応付けられたプラン情報を別の欄Dに表示させる。
具体的には、表示制御部33は、日付「1月15日」が対応付けられたプラン情報であって、コース「AAAカントリー」,「BBBゴルフクラブ」,「EEEゴルフクラブ」,「FFFカントリー」,「GGGカントリー」が場所の属性としてそれぞれ対応付けられた5つのプラン情報を、別の欄Dに表示させる。このような表示制御により、ユーザにより選択されたプラン情報と同じ日付が対応付けられたプラン情報がユーザに提示される。これにより、ユーザは、自身が利用可能な日付が対応づけられたプラン情報を複数得ることができる。
次に、受付部34は、第2の表示欄である別の欄Dに表示されたプラン情報に対する、ユーザからの選択入力を受け付けたか否かを判定する(S55)。プランの選択入力が受け付けられた場合には、処理はステップS56に進む。ステップS56において、表示制御部33は、別の欄Dにおいてユーザに選択されたプラン情報と、同じ場所の属性であるコースが対応付けられたプラン情報を、第1の表示欄であるカレンダー欄Cに日付ごとに表示する。
図15は、カレンダー欄Cに表示されたプラン情報の表示例を示す図である。図15に示すように、受付部34により、別の欄Dにおけるコース「EEEゴルフクラブ」のプラン情報に対する選択入力が受け付けられると、表示制御部33は、場所に関する属性であるコース「EEEゴルフクラブ」が対応付けられており、且つカレンダー欄Cに表示された日付「1月13日」〜「1月17日」がそれぞれプレー日の属性として対応付けられているプラン情報を、レコメンド装置10から送信されたプラン情報から抽出し、それぞれの日付の欄に表示させる。このような表示制御により、ユーザにより選択されたプラン情報と同じ場所の属性を有し且つ他の日付が対応付けられたプラン情報が選択されたプラン情報と共にユーザに提示される。これにより、ユーザは、自身の希望に合った場所に関するプラン情報を、より多くの日程について得ることができる。
なお、表示制御部33は、ユーザの購入履歴に基づき、プラン情報の表示制御を実施することとしてもよい。図16は、ユーザの購入履歴に基づいて表示されたプラン情報の表示例を示す図である。具体的には、表示制御部33は、ユーザの購入履歴に含まれるプラン情報の日付について、特定の曜日に対する偏りの有無を判定する。偏りの有無の判定は、周知の統計的処理に基づき実現される。そして、特定の曜日に対する偏りがあると判定された場合に、表示制御部33は、偏りがあると判定された曜日のみからなるカレンダー形式の表示欄を表示手段に表示させ、それぞれの表示欄に対応する日付に対応付けられたプラン情報を、レコメンド装置10から送信されたプラン情報から抽出し、それぞれの日付の欄に表示させる。
図16に示すように、表示制御部33は、土曜日及び日曜日のみからなるカレンダー形式の表示欄を表示手段に表示させ、それぞれの表示欄に対応する日付「1月11日」、「1月12日」、「1月18日」、「1月19日」、「1月25日」、「1月26日」に対応づけられたプラン情報を、それぞれの欄に表示させる。このような表示制御により、ユーザが購入する可能性が高い日程のプラン情報を提示することができる。また、このような表示制御を行うことにより、表示させる日付を少なくすることができるので、レコメンドするプラン情報を表示するための画面のスペースが限られている場合であっても、そのスペースによりユーザの希望に合う可能性が高いプラン情報を表示できる。
以上のように、ステップS6におけるプラン情報の表示処理が終了する。
次に、図17を参照して、コンピュータをレコメンドシステム1として機能させるためのレコメンドプログラムを説明する。図17(a)は、コンピュータをレコメンド装置10として機能させるためのレコメンドプログラムP10を示す図である。レコメンドプログラムP10は、メインモジュールm10、取得モジュールm11、算出モジュールm12及び送信モジュールm13を備える。
メインモジュールm10は、レコメンド処理を統括的に制御する部分である。取得モジュールm11、算出モジュールm12及び送信モジュールm13を実行することにより実現される機能はそれぞれ、図1に示されるレコメンド装置10の取得部11、算出部12及び送信部13の機能と同様である。
図17(b)は、コンピュータを端末30として機能させるための端末用レコメンドプログラムP30を示す図である。端末用レコメンドプログラムP30は、メインモジュールm30、ユーザID送信モジュールm31、プラン情報取得モジュールm32、表示制御モジュールm33及び受付モジュールm34を備える。
メインモジュールm30は、端末30におけるレコメンド処理を統括的に制御する部分である。ユーザID送信モジュールm31、プラン情報取得モジュールm32、表示制御モジュールm33及び受付モジュールm34を実行することにより実現される機能はそれぞれ、図1に示される端末30のユーザID送信部31、プラン情報取得部32、表示制御部33及び受付部34の機能と同様である。
レコメンドプログラムP10及び端末用レコメンドプログラムP30は、例えば、CD−ROMやDVD−ROMまたは半導体メモリ等の記憶媒体D10,D30によって提供される。また、レコメンドプログラムP10及び端末用レコメンドプログラムP30は、搬送波に重畳されたコンピュータデータ信号として通信ネットワークを介して提供されてもよい。
以上説明した本実施形態のレコメンドシステム1、レコメンド方法及びレコメンドプログラムによれば、ユーザの履歴に基づいて抽出されたプランが日付ごとに表示されるので、ユーザに対して、日付ごとにプランが提示される。これにより、ユーザは、利用可能な日付が対応付けられたプランを閲覧できる。従って、ユーザは、有用なプラン情報を得ることができる。また、ユーザのプランの購入又は閲覧に関する履歴に基づいてプランごとのスコアが算出され、算出されたスコアに基づいてプラン情報がユーザに提示される。ユーザの履歴に基づき算出されるスコアは、ユーザの希望に合う度合いが反映されている蓋然性が高い。そのようなスコアに基づきプラン情報がユーザに提示されるので、ユーザは、自身の希望に合うプランのプラン情報を得ることができる。
以上、本発明をその実施形態に基づいて詳細に説明した。しかし、本発明は上記実施形態に限定されるものではない。本発明は、その要旨を逸脱しない範囲で様々な変形が可能である。
本実施形態では、表示制御部33が端末30に備えられることとしたが、表示制御部33がレコメンド装置10に備えられることとしてもよい。この場合には、レコメンド装置10における表示制御部の表示制御に基づき、端末30の表示手段に種々の態様でプラン情報が表示される。
本実施形態では、図7のフローチャートのステップS14、図10のフローチャートのステップS45において、コースIDを取得するための手法として、ユーザの購入履歴に基づく手法、協調フィルタリングによる手法、及びゴルフのコース及びユーザの地理的情報に基づく手法等を例示した。コースIDを取得するための手法として、以下のような手法が用いられることとしてもよい。
例えば、算出部12は、ゴルフのコース及びユーザの地理的情報に基づく手法のバリエーションとして、ユーザの購入履歴を参照して、購入されたプランに対応付けられたゴルフのコースの位置を取得し、取得した複数のコースの位置の平均位置を算出し、算出した平均位置に近い位置に所在するコースのコースIDを取得する。ここで、算出部12は、ユーザの所在地を更に取得し、算出した平均位置から見てよりユーザの所在地に近いコースに対して重み付けをしてコースIDを取得してもよい。また、算出部12は、算出した平均位置を、ユーザの所在地の方向に所定の距離だけ移動させる補正をし、補正された平均位置に基づきコースIDを取得してもよい。
また、算出部12は、いわゆるページランク(登録商標)のアルゴリズムの応用により、コースごとのスコアを算出して、スコアの高いコースのコースIDを取得する手法を用いてもよい。例えば、ページランクにおけるページをユーザとし、ページランクにおけるリンクを他ユーザが購入したプランへの参加として捉え、より多くのユーザが参加したプランを購入したユーザの重要度が高く、重要度の高いユーザが選択したプランのコースの重要度は高いと考えることができる。具体的には、あるユーザXが、コースAが対応付けられたプランの予約をし、3人の他のユーザ(それぞれ持ち点1を有する)がそのプランに参加したとすると、ユーザXに対して、参加した他のユーザの持ち点の合計である3点が与えられる。同様に、ユーザYが、コースBが対応付けられたプランの予約をし、ユーザXを含む他のユーザがそのプランに参加したとすると、ユーザYに対して、ユーザXが有する3点及びその他の参加ユーザの持ち点の合計点が与えられる。さらに、ユーザZが、コースAが対応付けられたプランの予約をし、他のユーザがそのプランに参加したとすると、同様に、ユーザZに対して、他のユーザの持ち点の合計が与えられる。このような場合において、算出部12は、コースAが対応付けられたプランの予約をしたユーザX、ユーザZ、・・・の持ち点の合計値をコースAのスコアとして算出する。算出部12は、このようにコースごとに算出されたスコアの順に基づき、上位の所定数のコースのコースIDを抽出及び取得することとしてもよい。また、算出部12は、このように取得されたコースに対して、さらにコース及びユーザの地理的情報に基づき抽出したコースのコースIDを取得することとしてもよい。
また、算出部12は、いわゆるコンテンツベースのフィルタリングによりコースIDを取得してもよい。具体的には、算出部12は、例えば、図7のフローチャートのステップS13に示したような処理により、リファレンスプランのコースIDを取得する。そして、算出部12は、各コースの特徴をそれぞれ属性として対応付けて記憶しているコース情報を参照して、取得したコースIDに対応付けられた各種の属性情報と類似する属性情報を有する他のコースを抽出する。コースの特徴の類似度は、周知の技術により算出可能であって、例えば、コースごとの属性情報をベクトルとして表し、ベクトル間の距離として算出することができる。そして、算出部12は、取得された他のコースのコースIDを取得する。
また、レコメンドシステム1が、ソーシャルネットワーキングサービス(SNS)のシステムと連携しており、SNSシステムから種々の情報を取得できる場合には、ユーザのネットワークを利用してコースIDを取得することもできる。例えば、具体的には、算出部12は、ユーザと関連がある他のユーザの情報をSNSシステムから取得し、他のユーザの購入履歴を参照して、他のユーザが購入または閲覧したプランに対応付けられたコースのコースIDを、ユーザにプランのレコメンドをするために用いるコースIDとして取得する。