JP6229074B2 - レコメンドシステム、レコメンド方法及びレコメンドプログラム - Google Patents

Description

本発明の一側面は、レコメンドシステム、レコメンド方法及びレコメンドプログラムに関する。

ゴルフや旅行等のプランを、インターネットを介して予約及び決済を行う情報システムが知られている（例えば、特許文献１参照）。また、ゴルフ場等の予約サービスにおいて、事業者側のキャンペーンに沿ったプランを提示したり、広告として定められたプランを提示するものがある。

特開２０１０−１５４９３号公報

広告としてのプランの提示は、全てのユーザについて同じプランを提示するものであるため、ユーザにとって好適でない場合がある。そこで、より好適なプランをユーザに提示することが望ましい。

一方、ユーザにレコメンドするプランを抽出するために協調フィルタリングや地域フィルタリングなどの手法を用いることが考えられるが、どの手法を用いるとユーザに好適なプランが抽出されるのかはわからないため、これらの手法を用いて抽出したプランがユーザにとって好適でない場合がある。

そこで、本発明の一側面は、ユーザの希望に合う好適なプランをユーザに提示可能なシステムを提供することを目的とする。

上記課題を解決するために、本発明の一形態に係るレコメンドシステムは、プランをユーザにレコメンドするレコメンドシステムであって、ユーザを特定するユーザＩＤを取得する取得手段と、ユーザＩＤにより特定されるユーザによるプランの選択の履歴に基づいて、ユーザにレコメンドするプランを抽出する複数の手法のうちの少なくとも一つの手法を決定し、決定された手法を用いてプランを抽出する抽出手段と、抽出されたプランのプラン情報を表示させる表示制御手段と、を備える。

本発明の一形態に係るレコメンド方法は、プランをユーザにレコメンドするレコメンドシステムにおけるレコメンド方法であって、ユーザを特定するユーザＩＤを取得する取得ステップと、ユーザＩＤにより特定されるユーザによるプランの選択の履歴に基づいて、ユーザにレコメンドするプランを抽出する複数の手法のうちの少なくとも一つの手法を決定し、決定された手法を用いてプランを抽出する抽出ステップと、抽出されたプランのプラン情報を表示させる表示制御ステップと、を有する。

本発明の一形態に係るレコメンドプログラムは、コンピュータを、プランをユーザにレコメンドするレコメンドシステムとして機能させるためのレコメンドプログラムであって、コンピュータに、ユーザを特定するユーザＩＤを取得する取得機能と、ユーザＩＤにより特定されるユーザによるプランの選択の履歴に基づいて、ユーザにレコメンドするプランを抽出する複数の手法のうちの少なくとも一つの手法を決定し、決定された手法を用いてプランを抽出する抽出機能と、抽出されたプランのプラン情報を表示させる表示制御機能と、を実現させる。

上記側面によれば、ユーザのプランの選択の履歴に基づいて、ユーザにレコメンドするためのプランを抽出するための好適な手法が決定され、決定された手法を用いて抽出されたプランがユーザに対して提示される。従って、ユーザは、自身の希望に合うプランのプラン情報を得ることができる。

別の側面に係るレコメンドシステムでは、抽出手段は、ユーザの履歴に基づいて、プランごとにスコアを算出する算出手段を含み、算出手段により算出されたスコアに基づいてプランを抽出する。

上記側面によれば、ユーザのプランの選択に関する履歴に基づいてプランごとのスコアが算出され、算出されたスコアに基づいてプラン情報がユーザに提示される。ユーザの履歴に基づき算出されるスコアは、ユーザの希望に合う度合いが反映されている蓋然性が高い。そのようなスコアに基づきプラン情報がユーザに提示されるので、ユーザは、自身の希望に合うプランのプラン情報を得ることができる。

別の側面に係るレコメンドシステムでは、算出手段は、履歴において、過去に選択された一のプラン情報を参照プラン情報として取得し、参照プラン情報のプランに対応付けられた場所を特定する参照場所情報に基づいて、プラン情報を記憶しているプラン情報記憶手段を参照して、所定の手法により、ユーザにレコメンドする候補となる場所情報候補を取得し、取得した場所情報候補に対応付けられているプラン情報を、ユーザにレコメンドするプラン情報候補として取得し、取得したプラン情報候補ごとに、履歴及び参照プラン情報のうちの少なくともいずれか一方及びプラン情報候補の属性に基づき、スコアを算出することとしてもよい。

上記側面によれば、ユーザの履歴から取得された参照プラン情報により特定される場所情報に基づいて場所情報候補が取得されるので、ユーザの希望に合う蓋然性が高い場所情報候補が得られる。そして、場所情報候補に対応付けられたプラン情報候補ごとに、ユーザの履歴または参照プラン情報の属性と、プラン情報候補の属性とに基づいてスコアが算出されるので、ユーザの希望に合う度合いが反映されている蓋然性が高いスコアが得られる。そのようなスコアに基づきプラン情報がユーザに提示されることにより、ユーザは、自身の希望に合うプラン情報を得ることができる。

さらに別の側面に係るレコメンドシステムでは、算出手段は、履歴における最新の選択されたプランのプラン情報を参照プラン情報として取得することとしてもよい。

この側面によれば、ユーザの希望に合う属性を有している蓋然性が高いプラン情報が、参照プラン情報として取得される。そのような参照プラン情報に基づき取得された場所情報候補及び算出されたスコアは、ユーザの希望を適切に反映したものとなる。

さらに別の側面に係るレコメンドシステムでは、算出手段は、履歴に含まれるプランに対応付けられた場所のうち、所定の条件を満たす場所の場所情報を場所情報候補として取得し、履歴に基づき取得された場所情報候補の数が予め設定された所定数に満たない場合に、ユーザの履歴に基づく協調フィルタリング及びユーザに対応付けられた地理的情報の内の少なくともいずれか一方に基づき場所情報候補を取得することとしてもよい。

この側面によれば、ユーザの履歴を優先的に用いて場所情報候補が取得されるので、取得された場所情報候補にユーザの履歴がより強く反映されることとなる。従って、ユーザの希望に合う蓋然性が高い場所情報候補が得られる。

さらに別の側面に係るレコメンドシステムでは、算出手段は、ユーザの履歴において、選択されたプランの件数が所定数以上である場合には、履歴に含まれるプランに対応付けられた場所のうち、所定の条件を満たす場所の場所情報を場所情報候補として取得し、ユーザの履歴において、選択されたプランの件数が所定数未満である場合には、ユーザの履歴に基づく協調フィルタリング及びユーザに対応付けられた地理的情報の内の少なくともいずれか一方に基づき場所情報候補を取得することとしてもよい。

この側面によれば、ユーザの履歴においてプランの件数が少ない場合には、その履歴がユーザの希望を適切に反映しにくい場合があるところ、履歴においてプランの件数が所定数以上である場合に、ユーザの履歴に含まれるプランに対応付けられた場所の情報に基づき場所情報候補が取得されるので、取得された場所情報候補には適切にユーザの希望が反映されることとなる。一方、ユーザの履歴においてプランの件数が所定数未満である場合には、協調フィルタリングまたはユーザの地理的情報に基づき場所情報候補が取得されるので、ユーザの希望に合う蓋然性が高い場所情報候補が得られる。

さらに別の側面に係るレコメンドシステムでは、算出手段は、複数の所定の手法のそれぞれにより場所情報候補を取得し、所定の手法ごとに、場所情報候補に対応付けられているプラン情報候補の取得、及び、各プラン情報候補のスコアの算出、を実施し、抽出手段は、所定の手法ごとに、算出されたスコアに基づくプラン情報候補の中からのプランの抽出、を実施し、抽出したプランの、履歴に含まれるプランに対する一致の程度が最も高い所定の手法を、ユーザにレコメンドするプランを抽出するための手法として決定することとしてもよい。

各手法を用いて抽出されたプランと、履歴に含まれるプランとの一致の程度に基づき、場所情報候補の取得のための最適な手法が選択される。これにより、ユーザの希望にあうプランが抽出される蓋然性が高い手法が、ユーザにレコメンドするプランを抽出するための手法として決定される。これにより、ユーザの希望に合うプランが抽出される蓋然性が高められる。

さらに別の側面に係るレコメンドシステムでは、算出手段は、プラン情報候補の属性と、履歴または参照プラン情報の属性との類似度に基づき、該プラン情報候補のスコアを算出し、算出されるスコアは類似度が高いほど高いこととしてもよい。

この側面によれば、ユーザの履歴または参照プラン情報の属性と、プラン情報候補の属性との類似度に基づきスコアが算出されるので、算出されたスコアには、プラン情報候補のユーザの希望に合う度合いが反映される。そのようなスコアに基づいてプラン情報がユーザに提示されるので、ユーザの希望に合うプラン情報の提示が可能となる。

さらに別の側面に係るレコメンドシステムでは、算出手段は、ユーザの履歴に含まれるプランに対応付けられた場所についての所定の傾向の有無を判定し、所定の傾向があると判定された場合には、所定の傾向があると判定されなかった場合より、プランごとのスコアの算出において地理的なパラメータが用いられる場合に該パラメータに対する重み付けを重くすることとしてもよい。

この側面によれば、ユーザの履歴におけるプランに対応付けられた場所についての所定の傾向の有無に応じて、スコアの算出の際に地理的パラメータに対する重み付けが調整される。これにより、算出されるスコアに対してユーザの希望がより適切に反映される。

さらに別の側面に係るレコメンドシステムは、プラン情報は、ゴルフのプレーに関するプラン情報であって、場所に関する属性として、ゴルフコースの情報を含み、日付に関する属性として、プレーをする日時に関する情報を含むこととしてもよい。

この側面によれば、ユーザは、ゴルフのプレーに関するプラン情報を得ることが可能となる。

本発明の一側面によれば、ユーザの希望に合うプランをユーザに提示可能なシステムを提供することが可能となる。

本実施形態に係るレコメンドシステム１の機能的構成を示すブロック図である。 レコメンド装置のハードウェア構成を示す図である。 ユーザのゴルフプランの購入履歴のデータの例を示す図である。 プラン情報記憶部に記憶されているプラン情報の項目の構成の例を示す図である。 ユーザビヘイビアデータの項目と値の例を示す図である。 レコメンドシステムにおけるレコメンド処理を示すフローチャートである。 スコア算出処理の第１の例を示すフローチャートである。 コースＩＤ取得処理の例を示すフローチャートである。 スコア算出処理の第２の例を示すフローチャートである。 スコア算出処理の第３の例を示すフローチャートである。 プラン情報表示処理の例を示すフローチャートである。 プラン情報の表示例を示す図である。 プラン情報の表示制御の例を示す図である。 別の欄に表示されたプラン情報の表示例を示す図である。 カレンダー欄に表示されたプラン情報の表示例を示す図である。 ユーザの購入履歴に基づいて表示されたプラン情報の表示例を示す図である。 コンピュータをレコメンドシステムとして機能させるためのレコメンドプログラムを示す図である。

以下、添付図面を参照しながら本発明の実施形態を詳細に説明する。なお、図面の説明において同一又は同等の要素には同一の符号を付し、重複する説明を省略する。

図１は、本実施形態に係るレコメンドシステム１の機能的構成を示すブロック図である。本実施形態のレコメンドシステム１は、プランをユーザにレコメンドするシステムである。プランは、インターネットを介してユーザによる閲覧及び購入の対象となり得るものであって、少なくとも日付に関する情報が対応付けられており、さらに、場所に関する情報が対応付けられていてもよい。具体的には、プランは、例えば、ゴルフプラン及び旅行プラン等である。ゴルフプランには、プレー日が日付に関する情報として対応付けられており、ゴルフコースに関する情報が場所に関する情報として対応付けられている。また、旅行プランには、旅行の日程が日付に関する情報として対応付けられており、旅行の行き先に関する情報が場所に関する情報として対応付けられている。本実施形態は、ゴルフプランの例により説明する。

ゴルフのプランには、例えば、ゴルフ場の場所に関するコース情報及び日時の情報を含む。また、プランには、料金及びその他の条件等の情報が含まれる。インターネットを介してゴルフのプランの予約及び決済を行う従来の情報システムは、例えば、ユーザからゴルフ場を指定する入力を受け付け、指定されたゴルフ場に対応付けられたプランを提示する。

一方、インターネットを介して商品等を販売する情報システムには、協調フィルタリングによるレコメンデーションを行うものがある。このような情報システムでは、ユーザが購入した商品や閲覧した商品等の利用履歴を記憶しておき、利用履歴に基づいて、そのユーザの嗜好、傾向に合った商品等を抽出し、ユーザに提示する。従来のゴルフ等のプランを提示するシステムでは、このような協調フィルタリングによるレコメンデーションを適用することができる。例えば、ユーザが行ったことがあるゴルフ場に行ったことがある他のユーザが行ったことがあるゴルフ場を、ユーザに提示することができる。

しかしながら、ユーザに対してゴルフ場を提示し、ユーザからのゴルフ場の選択を受け付けても、そのゴルフ場に対応付けられたプランが多数存在して、ユーザの希望に合うプランを見つけることが困難である場合があった。また、選択されたゴルフ場に対応付けられたプランの中に、ユーザの希望に合うプランが存在しない場合には、ユーザはゴルフ場を選択する操作を再度行う必要があり、煩雑であった。

また、ゴルフ等のプランをレコメンドするために、協調フィルタリングによりレコメンドするプランを抽出することが考えられる。しかしながら、協調フィルタリングには、ユーザが購入及び閲覧等した複数の商品間に一定程度の相関関係が見出される必要があるところ、プランといった商品は、その商品の特性上、ユーザに対して販売される期間が短いため、プラン間の相関が形成されにくい。従って、協調フィルタリングにより適切なプランのレコメンドを行うことは困難である。

本実施形態のレコメンドシステム１は、かかる問題を解決して、ユーザの希望に合うプランをユーザに提示可能とするものである。

図１に示すように、本実施形態のレコメンドシステム１は、レコメンド装置１０及び端末３０を含む。端末３０は、ユーザの端末であって、インターネット等のネットワークＮを介してレコメンド装置１０と通信可能である。レコメンド装置１０は、プラン情報記憶部２１及びユーザ情報記憶部２２にアクセス可能である。

レコメンド装置１０は、機能的には、取得部１１（取得手段）、算出部１２（抽出手段、算出手段）及び送信部１３（表示制御手段）を含む。また、端末３０は、ユーザＩＤ送信部３１、プラン情報取得部３２（表示制御手段）、表示制御部３３（表示制御手段）及び受付部３４を含む。

プラン情報記憶部２１は、プラン情報を記憶している記憶手段である。プラン情報記憶部２１は、レコメンド装置１０の一機能部として構成されることとしてもよい。また、プラン情報記憶部２１は、レコメンド装置１０とネットワークを介して通信可能なコンピュータ装置に構成されることとしてもよい。なお、プラン情報の詳細については後述する。

ユーザ情報記憶部２２は、ユーザのプランの購入履歴をユーザ情報として記憶している記憶手段である。ユーザ情報記憶部２２は、レコメンド装置１０の一機能部として構成されることとしてもよい。また、ユーザ情報記憶部２２は、レコメンド装置１０とネットワークを介して通信可能なコンピュータ装置に構成されることとしてもよい。なお、プラン情報の詳細については後述する。なお、ユーザ情報としてのプランの購入履歴の詳細については後述する。

図２は、レコメンド装置１０のハードウェア構成図である。レコメンド装置１０は、物理的には、図２に示すように、プロセッサにより構成されるＣＰＵ１０１、ＲＡＭ及びＲＯＭといったメモリにより構成される主記憶装置１０２、ハードディスク等で構成される補助記憶装置１０３、ネットワークカード等で構成される通信制御装置１０４、入力デバイスであるキーボード、マウス等の入力装置１０５、ディスプレイ等の出力装置１０６などを含むコンピュータシステムとして構成されている。なお、レコメンド装置１０がサーバに構成される場合には、レコメンド装置１０は、入力装置１０５，出力装置１０６を含まなくてもよい。

図１に示したレコメンド装置１０の各機能は、図２に示すＣＰＵ１０１、主記憶装置１０２等のハードウェア上に所定のコンピュータソフトウェア（レコメンドプログラム）を読み込ませることにより、ＣＰＵ１０１の制御のもとで通信制御装置１０４、入力装置１０５、出力装置１０６を動作させるとともに、主記憶装置１０２や補助記憶装置１０３におけるデータの読み出し及び書き込みを行うことで実現される。処理に必要なデータやデータベースは主記憶装置１０２や補助記憶装置１０３内に格納される。

また、端末３０も、レコメンド装置１０と同様のハードウェア構成を有するコンピュータシステムである。端末３０は、例えば、パーソナルコンピュータ、スマートフォン等の装置として構成される。

続いて、レコメンド装置１０の機能部を説明する。取得部１１は、ユーザを特定するユーザＩＤを取得する部分である。具体的には、取得部１１は、端末３０から送信されたユーザＩＤを取得する。

算出部１２は、ユーザＩＤにより特定されるユーザによるプランの選択の履歴に基づいて、プランごとにスコアを算出する部分である。ユーザは、プランの購入または閲覧のためにプランの選択を行う。従って、プランの選択の履歴は、プランの購入及び閲覧のうちの少なくともいずれか一方に関する履歴である。なお、スコアの算出の詳細については後述する。本実施形態では、算出部１２は、ゴルフプランの購入履歴を参照してスコアを算出することとする。なお、プランの閲覧履歴は、購入履歴と同様にプラン情報を含むものであるので、購入履歴に基づくスコアの算出と同様に、閲覧履歴に基づいてプランごとのスコアの算出が行われることとしてもよい。

図３は、ユーザのゴルフプランの購入履歴のデータの例を示す図である。ユーザ情報記憶部２２は、ユーザのゴルフプランの購入履歴を記憶しており、算出部１２は、ユーザ情報記憶部２２にアクセスすることにより、ユーザＩＤに基づきユーザの購入履歴を取得できる。図３に示すように、ユーザ情報記憶部２２は、例えば、ユーザＩＤごとに、プランＩＤ、プレー日、コースＩＤ及びプラン料金等をユーザの購入履歴として記憶している。プランＩＤは、ゴルフプランを識別する識別情報である。プレー日は、当該ゴルフプランによるプレーが行われた日付の情報である。コースＩＤは、当該ゴルフプランに係るゴルフコースを識別する識別情報である。プラン料金は、当該ゴルフプランの料金である。

ゴルフプランの詳細な内容は、プラン情報記憶部２１に記憶されている。図４は、プラン情報記憶部２１に記憶されているプラン情報の項目の構成の例を示す図である。プラン情報は、プランＩＤに対応付けて、プランの内容を示す各種の情報を含む。コースＩＤは、ゴルフコースを識別する情報である。プラン名称は、当該プランの名称である。プラン料金は、当該プランを購入するための料金である。公開期間開始及び公開期間終了は、当該プランが実施される期間の開始日及び終了日を示す情報である。曜日区分及び対象曜日は、当該プランが適用される曜日を示す情報である。対象スタート時間帯は、当該プランのプレーを開始可能な時間帯を示す情報である。即ち、公開期間開始、公開期間終了、曜日区分、対象曜日及び対象スタート時間帯は、当該プランの日付に関する属性を示すデータに該当する。

プラン情報は、その他オプション等に関する情報をさらに含む。昼食は、プランに昼食が含まれるか否かを示す情報である。キャディフラグは、プランにキャディが含まれるか否かを示す情報である。カートコードは、プレーする際に使用するカートの種別を表す情報である。プレー人数（最小）及びプレー人数（最大）は、当該プランでプレーする際の１組の人数の下限及び上限を示す情報である。その他、プラン情報は、４サム割引、２サム保証、オプション１及びオプション２等に関する情報を含んでいる。

算出部１２は、ユーザの購入履歴に含まれるプランＩＤをキーとしてプラン情報を参照することにより、ユーザが購入したゴルフプランの内容を取得できる。そして、算出部１２は、ユーザの購入履歴及びプラン情報に基づいて、ユーザの購入履歴を示すユーザビヘイビアデータを生成することができる。図５は、ユーザビヘイビアデータの項目と値の例を示す図である。ユーザビヘイビアデータは、ユーザの購入履歴に関する情報処理を実施するために、ユーザの購入履歴を情報処理に適した形式でデータ化したものである。ユーザビヘイビアデータは、例えば種々の項目の値からなる多次元のベクトルデータとして生成されてもよい。具体的には、ユーザビヘイビアデータは、ユーザの購入履歴に含まれる各種の項目の値を取得し、その平均値及び標準偏差、またはそれらを正規化した値等により構成される。

図５に示す例では、ＭＡＸ、ＣＯＵＮＴ、ＡＶＧ及びＳＴＤはそれぞれ、かっこ内の値の最大値、計数値、平均値及び標準偏差を示す。ＭＡＸ（ｐｌａｙ＿ｄａｔｅ）は、最近のプレー日を示す。ＣＯＵＮＴ（ｃ＿ｉｄ）は、購入履歴に含まれるコースＩＤの数を示し、ＣＯＵＮＴ（ＤＩＳＴＩＮＣＴ ｃ＿ｉｄ）は、購入履歴に含まれるコースＩＤの数から重複分を除いた数を示す。ＨＯＵＲ（ｓｔａｒｔ＿ｔｉｍｅ）は、プレーの開始時間を示す。ｌｕｎｃｈ＿ｆｌｇは、昼食ありのフラグを示す。ｃａｄｄｉｅ＿ｆｌａｇは、キャディありのフラグを示す。ｐｌａｙ＿ｆｅｅは、プランの料金を示す。ｐｌａｙ＿ｍｅｍは、プレーする人数を示す。ｐｌａｙ＿ｄａｙ＿ｗｅｅｋｅｎｄ＿ｆｌｇは、プラン情報における週末を示すフラグである。ｐｌａｙ＿ｄａｙ＿ｈｏｌ＿ｆｌｇは、プラン情報における休日を示すフラグである。ｇｏｌｆＣｏｕｒｃｅＬａｔは、ゴルフコースの所在地の緯度を示す。ｇｏｌｆＣｏｕｒｃｅＬｏｎは、ゴルフコースの所在地の経度を示す。

ユーザの購入履歴に基づくユーザビヘイビアデータの生成は、周知技術によって実現可能である。また、ユーザビヘイビアデータは、算出部１２により生成されてもよいし、他の機能部や他の装置により生成されてもよい。また、図５に示すユーザビヘイビアデータの例は、ユーザの購入履歴を表すものであるが、１つのプランの内容を、ユーザビヘイビアデータと同様の形式で表したデータを生成することができる。即ち、プランの内容を表すデータは、例えば、プランの内容を示す複数の項目とその項目の値を含むベクトルデータとして表すことができる。このようなデータも、周知技術により実現可能である。

このようなデータにより、プランの内容に関する種々の情報処理が容易となる。即ち、ユーザビヘイビアデータは、ユーザが好むプランの特徴を示すものということもできるので、プランの内容を示すデータと、ユーザビヘイビアデータとの対比や、両ベクトルデータ間の距離の算出等により、当該プランとユーザが好むプランとの類似性が判断できる。また、他のユーザのユーザビヘイビアデータとの対比や、ベクトルデータ間の距離の算出により、協調フィルタリングに際しての、ユーザ間の類似度を判断できる。

再び図１を参照して、送信部１３は、算出部１２によりスコアが算出されたプラン情報を、算出されたスコアと共に、端末３０に送信する部分である。送信部１３は、予め設定された所定数のプラン情報を端末３０に送信することとしてもよい。

続いて、端末３０の機能部について説明する。ユーザＩＤ送信部３１は、ユーザＩＤをレコメンド装置１０に送信する。ユーザＩＤ送信部３１は、例えば、端末３０におけるログイン処理において入力されたユーザＩＤをレコメンド装置１０に送信する。

プラン情報取得部３２は、レコメンド装置１０から送信されたプラン情報を取得する部分である。具体的には、プラン情報取得部３２は、レコメンド装置１０の送信部１３からの、各々スコアが対応付けられたプラン情報を取得する。

表示制御部３３は、プラン情報取得部３２により取得されたプラン情報を、端末３０の表示手段に表示された第１の表示欄に時系列に日付ごとに表示させる部分である。表示制御部３３によるプラン情報の表示制御の詳細については、後に詳述する。

受付部３４は、表示制御部３３により表示されたプラン情報に対するユーザからの選択入力を受け付ける部分である。プラン情報に対する選択入力の受け付けに関する処理については、後に詳述する。

次に、図６〜１１を参照して、本実施形態のレコメンド処理、スコア算出処理、プラン情報の表示制御処理について詳細に説明する。

図６は、本実施形態のレコメンドシステム１におけるレコメンド処理を示すフローチャートである。

まず、端末３０のユーザＩＤ送信部３１は、ユーザＩＤをレコメンド装置１０に送信する（Ｓ１）。続いて、レコメンド装置１０の取得部１１は、ステップＳ１において送信されたユーザＩＤを取得する（Ｓ２）。

次に、レコメンド装置１０の算出部１２は、ユーザＩＤにより特定されるゴルフプランの購入履歴に基づいて、プランごとのスコアを算出する（Ｓ３）。図７は、ステップＳ３におけるスコア算出処理の第１の例を示すフローチャートである。図７を参照してスコア算出処理を説明する。

算出部１２は、ステップＳ２において取得したユーザＩＤに基づき、ユーザ情報記憶部２２を参照して、ユーザの購入履歴を取得する（Ｓ１１）。また、算出部１２は、購入履歴に含まれるプランのプラン情報を取得するためにプラン情報記憶部２１も併せて参照する。

続いて、算出部１２は、購入履歴において、過去に購入された一のプラン情報のプランＩＤをリファレンスプラン（参照プラン情報）として取得する（Ｓ１２）。算出部１２は、例えば、購入履歴における最新のプラン情報をリファレンスプランとして取得してもよい。これにより、ユーザの希望に合う属性を有している蓋然性が高いプラン情報が、リファレンスプランとして取得される。また、算出部１２は、現在の季節に対応する時期に購入されたプランのプラン情報をリファレンスプランとして取得してもよい。

次に、算出部１２は、リファレンスプランとして取得したプランのプランＩＤに対応付けられたコースＩＤ（参照場所情報）を取得する（Ｓ１３）。そして、算出部１２は、リファレンスプランのコースＩＤに基づき、レコメンドするコースのコースＩＤ（場所情報候補）を取得する（Ｓ１４）。算出部１２は、ユーザの購入履歴等に基づいて、コースＩＤを取得するための複数の手法のうちの少なくとも一つの手法を決定し、決定された手法を用いてコースＩＤを取得する。取得されたコースＩＤに基づきプランが抽出されるので、コースＩＤの取得のための手法を決定することは、プランを抽出するための手法を決定することを意味する。コースＩＤの取得のための手法としては、例えば、ユーザの購入履歴に基づく手法、協調フィルタリングによる手法、ゴルフのコース及びユーザの地理的情報に基づく手法等がある。以下に、このコースＩＤ（場所情報）を取得するコースＩＤ取得処理を、図８を参照して説明する。

図８は、ステップＳ１４におけるコースＩＤ取得処理の例を示すフローチャートである。算出部１２は、ユーザの購入履歴に含まれるプランに対応付けられたコースのうち、所定の条件を満たすコースのコースＩＤをレコメンドするコースの情報として取得する（Ｓ２１）。所定の条件は、例えば、ユーザの購入履歴において所定回数以上利用しているコースであること、である。これにより、ユーザの履歴が優先的に用いられてレコメンドするコースのコースＩＤが取得されるので、取得されたコースＩＤにユーザの履歴がより強く反映されることとなる。

すなわち、ユーザが実際に購入したプランのコースはユーザの嗜好に合っている可能性が高いため、そのコースのコースＩＤが優先的に用いられる。このため、コースＩＤの取得のための条件としての所定回数は１回であってもよい。ただし、ユーザがあるコースが対応付けられたプランを一度購入したとしても、その後にそのコースが対応付けられたプランが購入されなかった場合には、そのコースは、ユーザが一度は気になったものの、よく調べてみたらあまり条件に合わないコースであったり、実際にプレーしてみたらあまり気に入らなかったコースであったりする場合もある。これに対し、複数回購入されたコースは、ユーザがそのコースを気に入って利用している可能性が高い。そこで、コースＩＤの取得のための条件としての所定回数を２かそれ以上としてもよい。このようにすれば、複数回購入したコースのコースＩＤのみが取得される。

図８に示す処理の例では、ユーザにレコメンドするためのコースの候補の数が予め設定されている。そこで、算出部１２は、ステップＳ２１において取得されたコースＩＤの数が予め設定された所定数未満であるか否かを判定する（Ｓ２２）。コースＩＤの数が所定数未満であると判定された場合には処理はステップＳ２３に進められる。一方、コースＩＤの数が所定数未満であると判定されなかった場合にはコースＩＤ取得処理は終了する。

ステップＳ２３において、算出部１２は、ユーザの履歴に基づく協調フィルタリング及びユーザに対応付けられた地理的情報の内の少なくともいずれか一方に基づきコースＩＤを取得する（Ｓ２３）。

具体的には、算出部１２は、例えば、ユーザのゴルフプランの購入履歴（図３参照）を参照して、ユーザが購入したことがあるプランに対応付けられたコースと同じコースが対応付けられたプランを購入したことがある他のユーザを抽出する。そして、算出部１２は、他のユーザの購入履歴におけるプランに対応付けられたコースのコースＩＤを取得する。また、算出部１２は、図５を参照して説明したようなユーザビヘイビアデータを用いて、当該ユーザと他のユーザとの類似度を算出して、所定程度以上の類似度を有する他のユーザの購入履歴におけるプランに対応付けられたコースのコースＩＤを取得してもよい。

また、地理的情報に基づくコースＩＤの取得として、具体的には、算出部１２は、リファレンスプランのコースと地理的に近い（例えば、所定の距離以内に所在する）コースのコースＩＤを取得する。また、算出部１２は、ユーザの所在地と地理的に近い（例えば、所定の距離以内に所在する）コースのコースＩＤを取得してもよい。

ステップＳ２３の処理は、取得したコースＩＤの数が所定数以上になるまで、繰り返される。このように、算出部１２は、コースＩＤを取得するための手法として、複数の手法のうちのいずれかの手法を決定し、コースＩＤの取得処理を実施する。ここで、例えばステップＳ２１の所定の条件における所定回数が２であり、ステップＳ２２における所定数が４０であったような場合、４０のコースＩＤのうち、ユーザの履歴において２回以上利用しているコースのコースＩＤが全て抽出されるとともに、それ以外については、協調フィルタリングや地理的情報により抽出されたコースＩＤが含まれることになる。すなわち、２回以上利用しているコースが多ければ多いほど、４０のコースＩＤのうちで履歴に基づいて抽出されたコースＩＤの割合が多くなる。このようにすれば、ユーザの利用状況に応じて、コースＩＤを抽出するための手法の割合を調整するように制御することができる。

また、算出部１２は、ステップＳ２１〜Ｓ２３の処理に代えて、ユーザの購入履歴における購入されたプランの件数に応じてコースＩＤ取得処理を行うこととしてもよい。即ち、算出部１２は、ユーザの購入履歴において、購入されたプランの件数が所定数以上である場合には、購入履歴に含まれるプランに対応付けられたコースのうち、所定の条件（ステップＳ２１における所定の条件と同様）を満たすコースのコースＩＤをレコメンドするコースの情報として取得し、ユーザの購入履歴において、購入されたプランの件数が所定数未満である場合には、ユーザの履歴に基づく協調フィルタリング及びユーザに対応付けられた地理的情報の内の少なくともいずれか一方に基づきコースＩＤを取得する。このように、算出部１２は、ユーザの購入履歴に基づく手法、協調フィルタリングによる手法、ゴルフのコース及びユーザの地理的情報に基づく手法等のいずれかの手法を用いて、コースＩＤの取得処理を実施する。

このようなコースＩＤ取得処理によれば、ユーザの購入履歴においてプランの件数が少ない場合には、その購入履歴がユーザの希望を適切に反映しにくい場合があるところ、購入履歴においてプランの件数が所定数以上である場合に、ユーザの購入履歴に含まれるプランに対応付けられた場所の情報に基づきコースＩＤが取得されるので、取得されたコースＩＤには適切にユーザの希望が反映されることとなる。一方、ユーザの購入履歴においてプランの件数が所定数未満である場合には、協調フィルタリングまたはユーザの地理的情報に基づきコースＩＤが取得されるので、ユーザの希望に合う蓋然性が高い場所情報候補が得られる。

また、算出部１２は、複数の手法のそれぞれを用いて取得されたコースＩＤに基づき抽出されたプランと、ユーザの購入履歴等に含まれるプラン等との一致の程度に基づき、コースＩＤを取得するための手法を決定してもよい。即ち、算出部１２は、複数の所定の手法のそれぞれによりコースＩＤを取得し、所定の手法ごとに、コースＩＤに対応付けられているプラン情報候補の取得、各プラン情報候補のスコアの算出、及び、算出されたスコアに基づくプラン情報候補の中からのプランの抽出、を実施し、抽出したプランの、履歴に含まれるプランに対する一致の程度が最も高い所定の手法を、ユーザにレコメンドするプランを抽出するための手法として決定することとしてもよい。なお、プランごとのスコアの算出及びスコアに基づくプランの抽出については後述する。

具体的には、算出部１２は、例えば、ユーザの購入履歴に基づく手法、協調フィルタリングによる手法（パラメータや重みが異なる複数種類の協調フィルタリングでもよい）、ゴルフのコース及びユーザの地理的情報に基づく手法のそれぞれによりコースＩＤを取得する。次に、算出部１２は、各手法により取得されたコースＩＤに対応付けられているプラン情報をプラン情報候補として取得し、取得したプラン情報候補のスコアを算出し、レコメンドするプランの候補となるプランをスコアに基づき抽出する。

そして、算出部１２は、手法ごとに抽出されたプランと、ユーザの購入履歴に含まれるプランとの一致の程度を判定し、一致の程度が最も高い手法を、コースＩＤの取得に用いる手法として決定する。

このように、各手法を用いて抽出されたプランと、履歴に含まれるプランとの一致の程度に基づき、場所情報候補の取得のための最適な手法が選択される。これにより、ユーザの希望にあうプランが抽出される蓋然性が高い手法が、ユーザにレコメンドするプランを抽出するための手法として決定される。これにより、ユーザの希望に合うプランが抽出される蓋然性が高められる。

また、本実施形態のレコメンドシステム１では、以下のようにコースＩＤを取得するための手法を決定してもよい。

例えば、算出部１２は、ユーザの購入履歴を参照して、購入されたプランに対応付けられたゴルフのコースのうち、複数回（例えば２回）の購入の履歴があるコースの数を取得する。そして、算出部１２は、当該レコメンドシステム１において選択可能なコースの総数に対する複数回の購入の履歴があるコースの数の割合を算出し、算出した割合が所定値以上である場合に、ユーザの購入履歴に基づく手法を優先的に用いて、コースＩＤを取得する処理を実施する。

ユーザの購入履歴に基づく手法を優先的に用いた処理とは、コースＩＤを取得する処理としてユーザの購入履歴に基づく手法を選択することであってもよいし、複数の手法を用いる場合において、ユーザの購入履歴に基づく手法に対する重み付けを他の手法よりも重くすることであってもよい。一の手法を優先的に用いた処理の意味は、以下のコースＩＤを取得するための手法の決定の説明において、上記説明と同様である。

また、算出部１２は、ユーザの購入履歴または閲覧履歴を参照して、購入または閲覧のために選択入力が行われたプランの総数に対しての、複数の手法のうちのある手法を用いてレコメンドされたプランに対して購入または閲覧のために選択入力が行われたプランの数の割合を算出し、算出された割合が所定値以上である場合に、当該手法を優先的に用いて、コースＩＤを取得する処理を実施することとしてもよい。

また、例えば、算出部１２は、ユーザの端末３０において現在表示されているページを取得する。そして、表示されているページがプランを検索するための検索画面である場合には、ユーザが自身の履歴には含まれていないプランやコースを希望している蓋然性が高いので、算出部１２は、ユーザの購入履歴に基づく手法以外の手法を優先的に用いて、コースＩＤを取得する処理を実施することとしてもよい。一方、表示されているページがいわゆるマイページと呼ばれるような当該ユーザの履歴等に関する情報を表示するページである場合には、ユーザが自身の履歴には含まれているプランやコースを希望している蓋然性が高いので、算出部１２は、ユーザの購入履歴に基づく手法を優先的に用いて、コースＩＤを取得する処理を実施することとしてもよい。

また、算出部１２は、現在の日付に基づいて、現在がいわゆる繁忙期に該当するか、非繁忙期または閑散期に該当するか、を取得する。各日付と、繁忙期、非繁忙期及び閑散期との対応付けは予め設定されている。そして、繁忙期にはユーザが過去に利用したことのあるコースを利用する傾向があることに鑑みて、現在が繁忙期である場合には、算出部１２は、ユーザの購入履歴に基づく手法を優先的に用いて、コースＩＤを取得する処理を実施することとしてもよい。一方、ユーザにおいて、過去に利用したことがないコースを利用する場合には繁忙期を避ける傾向があることに鑑みて、現在が非繁忙期または閑散期である場合には、算出部１２は、ユーザの購入履歴に基づく手法以外の手法を優先的に用いて、コースＩＤを取得する処理を実施することとしてもよい。

再び図７を参照して、ステップＳ１５において、算出部１２は、ステップＳ１４において取得したコースＩＤに対応付けられているプランＩＤ及びそのプラン情報を、ユーザにレコメンドするプラン情報候補として取得する（Ｓ１５）。具体的には、算出部１２は、プラン情報記憶部２１を参照して、ステップＳ１４において取得したコースＩＤに対応付けられているプランＩＤのうち、例えば、プレーが可能な日として現在の日付から１週間後〜３週間後の日付が対応付けられているプランＩＤ及びプラン情報を取得する。

次に、算出部１２は、ステップＳ１５において取得されたプラン情報候補ごとにスコアを算出する（Ｓ１６）。具体的には、算出部１２は、ユーザの購入履歴及びリファレンスプランのプラン情報のうちの少なくともいずれか一方及びプラン情報候補の属性に基づきスコアを算出する。

例えば、算出部１２は、プラン情報候補の属性と、購入履歴またはリファレンスプランの属性との類似度に基づき、そのプラン情報候補のスコアを算出する。こうして算出されるスコアは、類似度が高いほど高い値を有する。以下に具体的に説明する。

算出部１２は、例えば、以下に示すような式（１）によりプラン情報候補ごとにスコアを算出する。

式（１）における左辺は、プラン情報候補のスコアを表す。右辺の第１項は、プラン情報候補と、リファレンスプランまたはユーザのユーザビヘイビアデータとの料金の類似度を表す。ｗ_ｐは所定の係数であって、設計的に設定される。右辺第１項の詳細は、例えば式（２）のように表すことができる。

式（２）における第１辺のＳ（ｐｒｉｃｅ｜ｐｒｉｃｅ_ｒｅｆ，ｕ）は、プラン情報候補の料金と、リファレンスプランまたはユーザのユーザビヘイビアデータの料金との類似度を表す。また、ｔ，ｔ_ｒｅｆは、類似度の算出において時期の類似度を考慮することを意味する。

式（２）の第２辺の分母における第２項は、第３辺に示されるように、プラン情報候補の料金と、リファレンスプランまたはユーザのユーザビヘイビアデータとの料金との距離（ｄｉｓｔａｎｃｅ）を表す。ＳＤ（ｐｒｉｃｅ_ｕｓｅｒ）は、ユーザビヘイビアデータとの料金の標準偏差を表す。ＡＶＧ（ｐｒｉｃｅ）_ｔ及びＡＶＧ（ｐｒｉｃｅ）_ｔｒｅｆはそれぞれ、算出対象のプランの時期における、プラン情報候補のプランの料金の平均及びリファレンスプランの料金の平均を表す。ｗｅｅｋｅｎｄ_{ｒａｔｉｏ}は、平日の料金と週末（土曜、日曜、祝日）の料金との差を補正するための係数であって、プラン情報候補のプランが週末を対象とするものであって、リファレンスプランが平日を対象とする者である場合には、１より大きい数（例えば１．４）が設定され、プラン情報候補のプランが平日を対象とするものであって、リファレンスプランが週末を対象とするものである場合には、１より小さい数（例えば１．４の逆数）が設定される。この係数は、設計的または経験的に設定される。また、プラン情報候補のプラン及びリファレンスプランが共に平日を対象とするものである場合、プラン情報候補のプラン及びリファレンスプランが共に週末を対象とするものである場合には、この係数は１に設定される。ｐｒｉｃｅ及びｐｒｉｃｅ_ｒｅｆはそれぞれ、プラン情報候補及びリファレンスプランの料金である。

式（１）の右辺の第２項は、プラン情報候補と、リファレンスプランまたはユーザのユーザビヘイビアデータとのオプションの類似度を表す。オプションは、ゴルフプランの内容における昼食、キャディ、割引等の有無のであって、ｏｐｔは、これらの有無をデータ化（例えばベクトルデータとして）したものである。ｗ_ｋは所定の係数であって、設計的に設定される。ｎは、オプションの項目の数である。

式（１）の右辺の第３項は、プラン情報候補と、リファレンスプランまたはユーザのユーザビヘイビアデータとのコースに関する属性の類似度を表す。ｃｏｕｒｃｅは、プラン情報候補のコースに関する属性をデータ化（例えばベクトルデータとして）したものである。ｃｏｕｒｃｅ_ｒｅｆは、リファレンスプランまたはユーザのユーザビヘイビアデータにおけるコースに関する属性をデータ化（例えばベクトルデータとして）したものである。

以上のように、プラン情報候補と、リファレンスプランまたはユーザのユーザビヘイビアデータの属性をデータ化（例えばベクトルデータとして）し、その類似度（例えばベクトル間の距離）を算出することにより、プラン情報候補のスコアが算出される。式（１）及び式（２）に示すように、本実施形態では、料金、プランの各種属性、コース等の各種の要素ごとの類似度を算出し、それぞれ係数により重みを調整した上で算出された類似度を加算することにより、スコアが算出される。このようにスコアが算出されることにより、各種の要素がスコアに対して適切に反映されることとなるので、スコアに基づくプランのレコメンドは、ユーザの希望に合うものとなる可能性が高い。なお、式（１）及び式（２）によるスコア算出は、スコア算出の一例であって、スコア算出に用いられる類似度は、種々の周知技術により算出可能である。このようにスコアが算出されることにより、算出されたスコアには、プラン情報候補のユーザの希望に合う度合いが反映されることとなる。

すなわち、プランには、料金、プランの各種属性、コース等の各種の要素が含まれているが、従来のレコメンドシステムは、一要素であるコースに着目して他のコースであるゴルフ場をレコメンドすることにとどまるものであった。これは、上述したように、プランのような有効期間が限定されるものでは、協調フィルタリングが有効に機能しない場合があるためである。このため、従来は、長期的に存在し、かつユーザにとって重要な要素であると考えられるコースに着目し、コースによる協調フィルタリングを行っていた。しかしながら、コースはプランの一要素に過ぎず、実際には、ユーザはコース以外のプランの要素に着目してプランを選択していたり、複数の要素を総合的に判断してプランを選択していることがあると考えられる。そこで、本実施形態では、上述したように、プランを要素に分解し、それぞれの要素ごとにリファレンスプランとプラン情報候補との類似度を算出し、プランの総合的なスコアを算出するようにした。このようなスコアにより、さまざまな要素を柔軟に考慮してユーザの嗜好に合ったプランを抽出し、レコメンドすることが可能になる。

次に、図９を参照して、ステップＳ３におけるスコア算出処理の第２の例を説明する。まず、算出部１２は、ステップＳ２において取得したユーザＩＤに基づき、ユーザ情報記憶部２２を参照して、ユーザの購入履歴を取得する（Ｓ３１）。また、算出部１２は、購入履歴に含まれるプランのプラン情報を取得するためにプラン情報記憶部２１も併せて参照する。

次に、算出部１２は、ユーザの購入履歴に含まれる複数のプランにおいて、プランに対応付けられた場所、即ちゴルフのコースが所在する場所に関して、所定の傾向の有無を判定する（Ｓ３２）。所定の傾向とは、例えば、ユーザがゴルフのコースまでの距離に応じて、コース及びプランを選択しているような傾向である。

算出部１２は、例えば、購入履歴に含まれる複数のプランにおいて、ユーザの所在地からコースまでの距離とプレーの開始時間との間に所定の程度以上の相関がある場合には、場所に関する所定の傾向が有ると判定する。相関の有無は、周知の統計処理により判定可能である。また、算出部１２は、例えば、購入履歴に含まれる複数のプランに対応付けられたコースにおいて、ユーザの所在地から一定の距離にあるコースの割合が所定の程度以上である場合に、場所に関する所定の傾向が有ると判定してもよい。また、算出部１２は、例えば、当該ユーザのユーザビヘイビアデータにおける地理的パラメータの標準偏差が所定の値以下である場合に、場所に関する所定の傾向が有ると判定してもよい。

次に、算出部１２は、ステップＳ３２において判定された、場所に関する所定の傾向の有無に応じて、プラン情報ごとのスコアを算出する。（Ｓ３３）。スコアの算出は、ステップＳ１６と同様に式（１）及び式（２）を用いて行われることとしてもよい。スコアの算出において、算出部１２は、場所に関する所定の傾向の有無に応じて、地理的なパラメータに対する重み付けを設定する。地理的なパラメータは、例えば、スコアの算出に用いられる種々のパラメータのうちの場所に関連するパラメータであって、例えば、コースの場所、ユーザの所在地等に関わるパラメータである。即ち、算出部１２は、ステップＳ３２において、場所に関する所定の傾向があると判定された場合には、所定の傾向があると判定されなかった場合より、スコアの算出において地理的なパラメータが用いられる場合にそれらのパラメータに対する重み付けを重くする。このようにスコアが算出されることにより、算出されるスコアに対してユーザのプランに対する希望がより適切に反映されることとなる。

次に、図１０を参照して、ステップＳ３におけるスコア算出処理の第３の例を説明する。まず、算出部１２は、ステップＳ２において取得したユーザＩＤに基づき、ユーザ情報記憶部２２を参照して、ユーザの購入履歴を取得する（Ｓ４１）。また、算出部１２は、購入履歴に含まれるプランのプラン情報を取得するためにプラン情報記憶部２１も併せて参照する。

これにより、例えば、ユーザが、ユーザの所在地からより遠くに所在するコースのプランを選択する場合において、より遅い時間のプランを選択しているような傾向がある場合には、そのような傾向に沿ったプランを提示したり、ユーザが土曜日及び日曜日にしかプランを購入していない場合でも、ユーザの住所や勤務地の近くに存在するコースでナイターのプランが存在すればそのプランを提示するといった制御を行うことができる。

続いて、算出部１２は、購入履歴において、過去に購入された一のプラン情報のプランＩＤをリファレンスプラン（参照プラン情報）として取得する（Ｓ４２）。ステップＳ４２の処理は、ステップＳ１２の処理と同様である。次に、算出部１２は、ユーザの購入履歴に含まれる複数のプランにおいて、プランに対応付けられた場所、即ちゴルフのコースが所在する場所に関して、所定の傾向の有無を判定する（Ｓ４３）。ステップＳ４３の処理は、ステップＳ３２の処理と同様である。

次に、算出部１２は、リファレンスプランとして取得したプランのプランＩＤに対応付けられたコースＩＤ（参照場所情報）を取得する（Ｓ４４）。ステップＳ４４の処理は、ステップＳ１３の処理と同様である。

続いて、算出部１２は、リファレンスプランのコースＩＤに基づき、レコメンドするコースのコースＩＤ（場所情報候補）を取得する（Ｓ４５）。ここで、算出部１２は、ステップＳ４３において場所に関する所定の傾向があると判定された場合には、地理的なパラメータに重み付けをしてコースＩＤの取得処理を実施する。具体的には、例えば、図８を参照して説明したステップＳ１４の処理では、ユーザの購入履歴に基づきコースＩＤを取得した（Ｓ２１）後に、取得したコースＩＤが所定数に満たなかった場合に地理的情報に基づきコースＩＤを取得することとしたが、ステップＳ４５では、算出部１２は、まず地理的情報に基づきコースＩＤを取得し、その後に、取得したコースＩＤの数が所定数に満たなかった場合に、ユーザの購入履歴または協調フィルタリングによりコースＩＤを取得することとしてもよい。

次に、算出部１２は、ステップＳ４５において取得したコースＩＤに対応付けられているプランＩＤ及びそのプラン情報を、ユーザにレコメンドするプラン情報候補として取得する（Ｓ４６）。ステップＳ４６の処理は、ステップＳ１５の処理と同様である。

次に、算出部１２は、ステップＳ４３において判定された、場所に関する所定の傾向の有無に応じて、プラン情報ごとのスコアを算出する。（Ｓ４７）。ステップＳ４７の処理は、ステップＳ３３の処理と同様である。

図９及び図１０を参照して説明したように、コースの所在地等の地理的な条件を考慮してスコアの算出を行うことにより、よりユーザのニーズに合ったレコメンドを行うことが可能となる。さらに、地理的な条件を考慮したレコメンドには、以下のような例が挙げられる。

例えば、ユーザの購入履歴において、コースの所在地とプレーの開始時間の相関において、ユーザの所在地からコースの所在地までの距離が遠いほど、プレーの開始時間が遅いプランを選択しているような傾向があれば、算出部１２は、スコアの算出において、地理的なパラメータに対する重み付けをより重くする。

また、ユーザの購入履歴において、ユーザの所在地からの距離が一定の距離以内にあるコースが対応付けられたプランを購入しているような傾向があれば、算出部１２は、ユーザの所在地から一定距離以内にあるコースのスコアが高くなるように、スコアの算出に際して、コースの所在位置に対する重み付けを重くする。また、ユーザの所在地からコースの所在地までの所用時間が一定の時間以内であるコースのスコアが高くなるように、スコアの算出に際して、コースの所在地に対する重み付けを重くしてもよい。一方、算出部１２は、ユーザの所在地から一定距離以内にないコースについては、プレーの開始時間が遅いプランや、所在地以外のコースの属性がユーザの購入履歴にあるコースの属性と類似しているプランがレコメンドされるように、そのようなプランのスコアを高くする。

また、ユーザの所在地や勤務地からの距離が一定の距離以内であって、プレーの開始時間が遅いプラン（例えば、１８時以降）が存在する場合には、そのようなプランがユーザにレコメンドされるように、算出部１２は、そのようなプランのスコアが高くなるように、コースの所在地及びプレーの開始時間に対する重み付けを重くしてスコアを算出する。

また、ユーザの購入履歴において、一定領域内（例えば、県内）の所在するコースのプランばかりを購入している場合には、その領域内のコースのプランがレコメンドされるように、算出部１２は、コースの所在地に対する重み付けを重くする。

再び図６を参照する。ステップＳ４において、レコメンド装置１０の送信部１３は、ステップＳ３において算出されたスコアを含むプラン情報を端末３０に送信する（Ｓ４）。なお、算出部１２は、算出されたスコアに基づいてプラン情報を抽出し、抽出したプラン情報を送信部１３に送信させることとしてもよい。例えば、算出部１２は、算出されたスコアが高いプランを上位のものから所定数抽出し、抽出したプランのプラン情報を送信部１３に送信させることとしてもよい。これに対して、端末３０のプラン情報取得部３２は、レコメンド装置１０から送信されたプラン情報を取得する（Ｓ５）。端末３０に送信されるプラン情報は、少なくともプレー日の日付、コース（コースＩＤ）の情報（場所の情報）及びスコアを含み、更に、図４に示すようなプランに関する種々の情報の一部または全部を含んでもよい。

次に、端末３０の表示制御部３３は、ステップＳ５において取得したプラン情報を、端末３０の表示手段に表示させる（Ｓ６）。例えば、表示制御部３３は、取得したプラン情報から、スコアが高い順に所定数のプラン情報を抽出し、抽出したプラン情報を表示手段に表示させることとしてもよい。

また、表示制御部３３は、プラン情報取得部３２により取得されたプラン情報を、端末３０の表示手段に表示された表示欄に時系列に日付ごとに表示させることとしてもよい。この表示処理の例を、図１１を参照して説明する。

表示制御部３３は、ステップＳ５において受信したプラン情報から、日付ごとにプラン情報を抽出する（Ｓ５１）。そして、表示制御部３３は、日付ごとに抽出したプラン情報を、第１の表示欄に時系列に日付ごとに表示する。第１の表示欄は例えばカレンダー形式で構成されている。カレンダーは、日付を表形式で表したものである。図１２は、ステップＳ５２において表示されたプラン情報の表示例を示す図である。図１２に示すように、プラン情報は、カレンダーの日付ごとに表示されている。なお、表示制御部３３は、各日付に対応付けられたプラン情報が複数ある場合には、同じ日付に対応付けられた複数のプラン情報のうち、スコアが最も高いプラン情報をその日付に対応付けて表示させることとしてもよいし、同じ日付に対応付けられた複数のプラン情報からランダムに選択したプラン情報をその日付に対応付けて表示させることとしてもよい。

なお、表示制御部３３は、プラン情報を各日付に対応付けて表示させる際に、第１の日付に対応付けて表示するプラン情報に対応付けられた属性と異なる属性を含むプラン情報を第２の日付に対応付けて表示するように制御してもよい。この制御を、図１３を参照して説明する。図１３は、プラン情報の表示制御の例を示す図である。具体的には、図１３において、表示制御部３３は、日付「１月１４日」（第１の日付）に対応付けて、コース「ＡＡＡカントリー」のプラン情報を表示させている。このとき、表示制御部３３は、コース「ＡＡＡカントリー」とは異なる場所に関する属性であるコース「ＢＢＢゴルフクラブ」のプラン情報を日付「１月１５日」（第２の日付）に対応付けて表示させる。このように、第１の日付に対応付けて表示されたプラン情報とは異なる属性を有するプラン情報が第２の日付に対応付けて表示されるので、ユーザは多様なプラン情報を得ることができる。

次に、受付部３４は、ユーザによるプランの選択入力を受け付けたか否かを判定する（Ｓ５３）。プランの選択入力が受け付けられた場合には、処理はステップＳ５４に進む。ステップＳ５４において、表示制御部３３は、選択されたプランと同じ日付が対応付けられた他のプラン情報を第１の表示欄とは異なる第２の表示欄に表示する（Ｓ５４）。具体的には、表示制御部３３は、選択されたプランと同じ日付が対応付けられた他のプラン情報をカレンダーの表示欄（第１の表示欄）とは異なる別の欄（第２の表示欄）に表示する。

図１４は、別の欄に表示されたプラン情報の表示例を示す図である。図１４に示すように、受付部３４により、カレンダー欄Ｃにおける日付「１月１５日」の欄に表示されたプラン情報に対する選択入力が受け付けられると、表示制御部３３は、日付「１月１５日」が対応付けられたプラン情報を別の欄Ｄに表示させる。

具体的には、表示制御部３３は、日付「１月１５日」が対応付けられたプラン情報であって、コース「ＡＡＡカントリー」，「ＢＢＢゴルフクラブ」，「ＥＥＥゴルフクラブ」，「ＦＦＦカントリー」，「ＧＧＧカントリー」が場所の属性としてそれぞれ対応付けられた５つのプラン情報を、別の欄Ｄに表示させる。このような表示制御により、ユーザにより選択されたプラン情報と同じ日付が対応付けられたプラン情報がユーザに提示される。これにより、ユーザは、自身が利用可能な日付が対応づけられたプラン情報を複数得ることができる。

次に、受付部３４は、第２の表示欄である別の欄Ｄに表示されたプラン情報に対する、ユーザからの選択入力を受け付けたか否かを判定する（Ｓ５５）。プランの選択入力が受け付けられた場合には、処理はステップＳ５６に進む。ステップＳ５６において、表示制御部３３は、別の欄Ｄにおいてユーザに選択されたプラン情報と、同じ場所の属性であるコースが対応付けられたプラン情報を、第１の表示欄であるカレンダー欄Ｃに日付ごとに表示する。

図１５は、カレンダー欄Ｃに表示されたプラン情報の表示例を示す図である。図１５に示すように、受付部３４により、別の欄Ｄにおけるコース「ＥＥＥゴルフクラブ」のプラン情報に対する選択入力が受け付けられると、表示制御部３３は、場所に関する属性であるコース「ＥＥＥゴルフクラブ」が対応付けられており、且つカレンダー欄Ｃに表示された日付「１月１３日」〜「１月１７日」がそれぞれプレー日の属性として対応付けられているプラン情報を、レコメンド装置１０から送信されたプラン情報から抽出し、それぞれの日付の欄に表示させる。このような表示制御により、ユーザにより選択されたプラン情報と同じ場所の属性を有し且つ他の日付が対応付けられたプラン情報が選択されたプラン情報と共にユーザに提示される。これにより、ユーザは、自身の希望に合った場所に関するプラン情報を、より多くの日程について得ることができる。

なお、表示制御部３３は、ユーザの購入履歴に基づき、プラン情報の表示制御を実施することとしてもよい。図１６は、ユーザの購入履歴に基づいて表示されたプラン情報の表示例を示す図である。具体的には、表示制御部３３は、ユーザの購入履歴に含まれるプラン情報の日付について、特定の曜日に対する偏りの有無を判定する。偏りの有無の判定は、周知の統計的処理に基づき実現される。そして、特定の曜日に対する偏りがあると判定された場合に、表示制御部３３は、偏りがあると判定された曜日のみからなるカレンダー形式の表示欄を表示手段に表示させ、それぞれの表示欄に対応する日付に対応付けられたプラン情報を、レコメンド装置１０から送信されたプラン情報から抽出し、それぞれの日付の欄に表示させる。

図１６に示すように、表示制御部３３は、土曜日及び日曜日のみからなるカレンダー形式の表示欄を表示手段に表示させ、それぞれの表示欄に対応する日付「１月１１日」、「１月１２日」、「１月１８日」、「１月１９日」、「１月２５日」、「１月２６日」に対応づけられたプラン情報を、それぞれの欄に表示させる。このような表示制御により、ユーザが購入する可能性が高い日程のプラン情報を提示することができる。また、このような表示制御を行うことにより、表示させる日付を少なくすることができるので、レコメンドするプラン情報を表示するための画面のスペースが限られている場合であっても、そのスペースによりユーザの希望に合う可能性が高いプラン情報を表示できる。

以上のように、ステップＳ６におけるプラン情報の表示処理が終了する。

次に、図１７を参照して、コンピュータをレコメンドシステム１として機能させるためのレコメンドプログラムを説明する。図１７（ａ）は、コンピュータをレコメンド装置１０として機能させるためのレコメンドプログラムＰ１０を示す図である。レコメンドプログラムＰ１０は、メインモジュールｍ１０、取得モジュールｍ１１、算出モジュールｍ１２及び送信モジュールｍ１３を備える。

メインモジュールｍ１０は、レコメンド処理を統括的に制御する部分である。取得モジュールｍ１１、算出モジュールｍ１２及び送信モジュールｍ１３を実行することにより実現される機能はそれぞれ、図１に示されるレコメンド装置１０の取得部１１、算出部１２及び送信部１３の機能と同様である。

図１７（ｂ）は、コンピュータを端末３０として機能させるための端末用レコメンドプログラムＰ３０を示す図である。端末用レコメンドプログラムＰ３０は、メインモジュールｍ３０、ユーザＩＤ送信モジュールｍ３１、プラン情報取得モジュールｍ３２、表示制御モジュールｍ３３及び受付モジュールｍ３４を備える。

メインモジュールｍ３０は、端末３０におけるレコメンド処理を統括的に制御する部分である。ユーザＩＤ送信モジュールｍ３１、プラン情報取得モジュールｍ３２、表示制御モジュールｍ３３及び受付モジュールｍ３４を実行することにより実現される機能はそれぞれ、図１に示される端末３０のユーザＩＤ送信部３１、プラン情報取得部３２、表示制御部３３及び受付部３４の機能と同様である。

レコメンドプログラムＰ１０及び端末用レコメンドプログラムＰ３０は、例えば、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭまたは半導体メモリ等の記憶媒体Ｄ１０，Ｄ３０によって提供される。また、レコメンドプログラムＰ１０及び端末用レコメンドプログラムＰ３０は、搬送波に重畳されたコンピュータデータ信号として通信ネットワークを介して提供されてもよい。

以上説明した本実施形態のレコメンドシステム１、レコメンド方法及びレコメンドプログラムによれば、ユーザの履歴に基づいて抽出されたプランが日付ごとに表示されるので、ユーザに対して、日付ごとにプランが提示される。これにより、ユーザは、利用可能な日付が対応付けられたプランを閲覧できる。従って、ユーザは、有用なプラン情報を得ることができる。また、ユーザのプランの購入又は閲覧に関する履歴に基づいてプランごとのスコアが算出され、算出されたスコアに基づいてプラン情報がユーザに提示される。ユーザの履歴に基づき算出されるスコアは、ユーザの希望に合う度合いが反映されている蓋然性が高い。そのようなスコアに基づきプラン情報がユーザに提示されるので、ユーザは、自身の希望に合うプランのプラン情報を得ることができる。

以上、本発明をその実施形態に基づいて詳細に説明した。しかし、本発明は上記実施形態に限定されるものではない。本発明は、その要旨を逸脱しない範囲で様々な変形が可能である。

本実施形態では、表示制御部３３が端末３０に備えられることとしたが、表示制御部３３がレコメンド装置１０に備えられることとしてもよい。この場合には、レコメンド装置１０における表示制御部の表示制御に基づき、端末３０の表示手段に種々の態様でプラン情報が表示される。

本実施形態では、図７のフローチャートのステップＳ１４、図１０のフローチャートのステップＳ４５において、コースＩＤを取得するための手法として、ユーザの購入履歴に基づく手法、協調フィルタリングによる手法、及びゴルフのコース及びユーザの地理的情報に基づく手法等を例示した。コースＩＤを取得するための手法として、以下のような手法が用いられることとしてもよい。

例えば、算出部１２は、ゴルフのコース及びユーザの地理的情報に基づく手法のバリエーションとして、ユーザの購入履歴を参照して、購入されたプランに対応付けられたゴルフのコースの位置を取得し、取得した複数のコースの位置の平均位置を算出し、算出した平均位置に近い位置に所在するコースのコースＩＤを取得する。ここで、算出部１２は、ユーザの所在地を更に取得し、算出した平均位置から見てよりユーザの所在地に近いコースに対して重み付けをしてコースＩＤを取得してもよい。また、算出部１２は、算出した平均位置を、ユーザの所在地の方向に所定の距離だけ移動させる補正をし、補正された平均位置に基づきコースＩＤを取得してもよい。

また、算出部１２は、いわゆるページランク（登録商標）のアルゴリズムの応用により、コースごとのスコアを算出して、スコアの高いコースのコースＩＤを取得する手法を用いてもよい。例えば、ページランクにおけるページをユーザとし、ページランクにおけるリンクを他ユーザが購入したプランへの参加として捉え、より多くのユーザが参加したプランを購入したユーザの重要度が高く、重要度の高いユーザが選択したプランのコースの重要度は高いと考えることができる。具体的には、あるユーザＸが、コースＡが対応付けられたプランの予約をし、３人の他のユーザ（それぞれ持ち点１を有する）がそのプランに参加したとすると、ユーザＸに対して、参加した他のユーザの持ち点の合計である３点が与えられる。同様に、ユーザＹが、コースＢが対応付けられたプランの予約をし、ユーザＸを含む他のユーザがそのプランに参加したとすると、ユーザＹに対して、ユーザＸが有する３点及びその他の参加ユーザの持ち点の合計点が与えられる。さらに、ユーザＺが、コースＡが対応付けられたプランの予約をし、他のユーザがそのプランに参加したとすると、同様に、ユーザＺに対して、他のユーザの持ち点の合計が与えられる。このような場合において、算出部１２は、コースＡが対応付けられたプランの予約をしたユーザＸ、ユーザＺ、・・・の持ち点の合計値をコースＡのスコアとして算出する。算出部１２は、このようにコースごとに算出されたスコアの順に基づき、上位の所定数のコースのコースＩＤを抽出及び取得することとしてもよい。また、算出部１２は、このように取得されたコースに対して、さらにコース及びユーザの地理的情報に基づき抽出したコースのコースＩＤを取得することとしてもよい。

また、算出部１２は、いわゆるコンテンツベースのフィルタリングによりコースＩＤを取得してもよい。具体的には、算出部１２は、例えば、図７のフローチャートのステップＳ１３に示したような処理により、リファレンスプランのコースＩＤを取得する。そして、算出部１２は、各コースの特徴をそれぞれ属性として対応付けて記憶しているコース情報を参照して、取得したコースＩＤに対応付けられた各種の属性情報と類似する属性情報を有する他のコースを抽出する。コースの特徴の類似度は、周知の技術により算出可能であって、例えば、コースごとの属性情報をベクトルとして表し、ベクトル間の距離として算出することができる。そして、算出部１２は、取得された他のコースのコースＩＤを取得する。

また、レコメンドシステム１が、ソーシャルネットワーキングサービス（ＳＮＳ）のシステムと連携しており、ＳＮＳシステムから種々の情報を取得できる場合には、ユーザのネットワークを利用してコースＩＤを取得することもできる。例えば、具体的には、算出部１２は、ユーザと関連がある他のユーザの情報をＳＮＳシステムから取得し、他のユーザの購入履歴を参照して、他のユーザが購入または閲覧したプランに対応付けられたコースのコースＩＤを、ユーザにプランのレコメンドをするために用いるコースＩＤとして取得する。

１…レコメンドシステム、１０…レコメンド装置、１１…取得部、１２…算出部、１３…送信部、２１…プラン情報記憶部、２２…ユーザ情報記憶部、３０…端末、３１…ユーザＩＤ送信部、３２…プラン情報取得部、３３…表示制御部、３４…受付部、Ｄ１０，Ｄ３０…記憶媒体、ｍ１０…メインモジュール、ｍ１１…取得モジュール、ｍ１２…算出モジュール、ｍ１３…送信モジュール、ｍ３０…メインモジュール、ｍ３１…ユーザＩＤ送信モジュール、ｍ３２…プラン情報取得モジュール、ｍ３３…表示制御モジュール、ｍ３４…受付モジュール、Ｎ…ネットワーク、Ｐ１０…レコメンドプログラム、Ｐ３０…端末用レコメンドプログラム。

Claims (10)

1. プランをユーザにレコメンドするレコメンドシステムであって、
   ユーザを特定するユーザＩＤを取得する取得手段と、
   前記ユーザＩＤにより特定されるユーザによるプランの選択の履歴に基づいて、ユーザにレコメンドするプランを抽出する複数の手法のうちの少なくとも一つの手法を決定し、決定された手法を用いてプランを抽出する抽出手段と、
   抽出されたプランのプラン情報を表示させる表示制御手段と、
   を備え、
   前記抽出手段は、前記複数の手法のそれぞれにより抽出したプランと、前記ユーザＩＤにより特定されるユーザによるプランの選択の履歴に含まれるプランとの一致の程度に基づいて、前記複数の手法のうちの少なくとも一つの手法を決定し、決定された手法を用いてプランを抽出する、
   レコメンドシステム。
2. 前記抽出手段は、前記複数の手法のそれぞれにより抽出したプランと、前記ユーザＩＤにより特定されるユーザによるプランの選択の履歴に含まれるプランとの一致の程度が最も高い手法を、プランを抽出する手法として決定する、
   請求項１に記載のレコメンドシステム。
3. 前記抽出手段は、
   ユーザの前記履歴に基づいて、プランごとにスコアを算出する算出手段を含み、
   前記算出手段により算出されたスコアに基づいてプランを抽出する、
   請求項１または２に記載のレコメンドシステム。
4. 前記算出手段は、
   前記履歴において、過去に選択された一のプラン情報を参照プラン情報として取得し、
   前記参照プラン情報のプランに対応付けられた場所を特定する参照場所情報に基づいて、プラン情報を記憶しているプラン情報記憶手段を参照して、所定の手法により、前記ユーザにレコメンドする候補となる場所情報候補を取得し、
   取得した場所情報候補に対応付けられているプラン情報を、前記ユーザにレコメンドするプラン情報候補として取得し、
   取得したプラン情報候補ごとに、前記履歴及び前記参照プラン情報のうちの少なくともいずれか一方及び前記プラン情報候補の属性に基づき、スコアを算出する、
   請求項３に記載のレコメンドシステム。
5. 前記算出手段は、前記履歴における最新の選択されたプランのプラン情報を前記参照プラン情報として取得する、
   請求項４に記載のレコメンドシステム。
6. 前記算出手段は、前記プラン情報候補の属性と、前記履歴または前記参照プラン情報の属性との類似度に基づき、該プラン情報候補のスコアを算出し、前記算出されるスコアは前記類似度が高いほど高い、
   請求項４〜５のいずれか一項に記載のレコメンドシステム。
7. 前記算出手段は、
   前記ユーザの前記履歴に含まれるプランに対応付けられた場所についての所定の傾向の有無を判定し、前記所定の傾向があると判定された場合には、前記所定の傾向があると判定されなかった場合より、プランごとのスコアの算出において地理的なパラメータが用いられる場合に該パラメータに対する重み付けを重くする、
   請求項３〜６のいずれか一項に記載のレコメンドシステム。
8. 前記プラン情報は、ゴルフのプレーに関するプラン情報であって、場所に関する属性として、ゴルフコースの情報を含み、日付に関する属性として、プレーをする日時に関する情報を含む、
   請求項１〜７のいずれか一項に記載のレコメンドシステム。
9. プランをユーザにレコメンドするレコメンドシステムにおけるレコメンド方法であって、
   ユーザを特定するユーザＩＤを取得する取得ステップと、
   前記ユーザＩＤにより特定されるユーザによるプランの選択の履歴に基づいて、ユーザにレコメンドするプランを抽出する複数の手法のうちの少なくとも一つの手法を決定し、決定された手法を用いてプランを抽出する抽出ステップと、
   抽出されたプランのプラン情報を表示させる表示制御ステップと、
   を有し、
   前記抽出ステップにおいて、前記複数の手法のそれぞれにより抽出したプランと、前記ユーザＩＤにより特定されるユーザによるプランの選択の履歴に含まれるプランとの一致の程度に基づいて、前記複数の手法のうちの少なくとも一つの手法を決定し、決定された手法を用いてプランを抽出する、
   レコメンド方法。
10. コンピュータを、プランをユーザにレコメンドするレコメンドシステムとして機能させるためのレコメンドプログラムであって、
    前記コンピュータに、
    ユーザを特定するユーザＩＤを取得する取得機能と、
    前記ユーザＩＤにより特定されるユーザによるプランの選択の履歴に基づいて、ユーザにレコメンドするプランを抽出する複数の手法のうちの少なくとも一つの手法を決定し、決定された手法を用いてプランを抽出する抽出機能と、
    抽出されたプランのプラン情報を表示させる表示制御機能と、
    を実現させ、
    前記抽出機能は、前記複数の手法のそれぞれにより抽出したプランと、前記ユーザＩＤにより特定されるユーザによるプランの選択の履歴に含まれるプランとの一致の程度に基づいて、前記複数の手法のうちの少なくとも一つの手法を決定し、決定された手法を用いてプランを抽出する、
    レコメンドプログラム。
    
    

Images