(第一の実施形態)
以下に、図面を参照して第一の実施形態について説明する。図1は、表示制御システムの概要を説明する図である。
本実施形態の表示制御システムでは、旅行プランの提示要求を行ったユーザに対し、旅行プランを評価した評価者の属性及び旅行プランの評価結果と、提示要求を行ったユーザの属性とに基づき、提示する旅行プランの表示順を決定する。
本実施形態の表示制御システムは、ユーザの端末装置において旅行プランの登録を受け付けると、旅行プランと、旅行プランを登録したユーザの情報とを対応付けて、旅行プランデータベース210に格納する。以下の説明では、旅行プランを登録したユーザを登録ユーザと呼び、登録ユーザの情報を登録ユーザ情報と呼ぶ。
また、本実施形態の表示制御システムは、ユーザの端末装置において、旅行プランに対する評価が入力されると、登録ユーザ情報と、入力された評価内容に応じた評価ポイントから特定される属性とを対応付けて、ユーザ属性データベース230に格納する。評価内容と評価ポイントとは、予め評価ポイントデータベース220において予め対応付けられている。また、評価ポイントと登録ユーザ情報の属性とは、属性データベース240において予め対応付けられている。
また、表示制御システムは、旅行プランに対する評価が入力されると、評価対象の旅行プランと、評価内容及び評価ポイントと、評価を行ったユーザの情報と、このユーザの属性とを対応付けて、旅行プラン評価データベース250へ格納する。以下の説明では、旅行プランの評価を行ったユーザを評価ユーザと呼び、評価ユーザの情報を評価ユーザ情報と呼ぶ。
さらに、本実施形態の表示制御システムでは、ユーザの端末装置において、旅行プランの提示要求を受け付けると、ユーザ属性データベース230を参照し、提示要求を行ったユーザの属性を特定する。以下の説明では、旅行プランの提示要求を行ったユーザを、閲覧ユーザと呼び、閲覧ユーザの情報を閲覧ユーザ情報と呼ぶ。
表示制御システムは、閲覧ユーザの属性を特定すると、旅行プラン評価データベース250を参照し、評価ユーザの属性と、閲覧ユーザの属性との比較結果に基づく重み付けを行う。属性の比較結果と重みとは、重み付けデータベース260において、予め対応付けられている。
そして、表示制御システムは、重みに応じた順に、旅行プランの表示順を決定し、提示要求を受け付けた端末装置へ決められた表示順に旅行プランを表示させる。
具体的には、表示制御システムは、閲覧ユーザの属性と、評価ユーザの属性とが近い旅行プランに付与する重みを大きくし、閲覧ユーザの属性と、評価ユーザの属性とが離れている旅行プランに付与する重みを小さくする。
本実施形態では、以上のように、旅行プランの提示要求を受け付けると、旅行プラン毎に、提示要求を行った閲覧ユーザの属性と、旅行プランの評価を行った評価ユーザの属性との比較結果に応じた重みを付与する。そして、表示制御システムは、付与された重みにしたがって、旅行プランの表示順を決定し、閲覧ユーザの端末装置へ表示させる。
よって、本実施形態によれば、旅行プランの提示要求を行ったユーザに対し、ユーザの属性に応じた、ユーザの嗜好に合わせた旅行プランから順に提示することができる。
尚、本実施形態では、登録ユーザ、評価ユーザ、閲覧ユーザのそれぞれが異なるユーザであっても良いし、登録ユーザと閲覧ユーザが同一のユーザであっても良いし、評価ユーザと閲覧ユーザが同一のユーザであっても良い。
つまり、本実施形態では、旅行プランを登録したユーザが、他のユーザが登録した旅行プランの評価を行うことも、旅行プランの提示要求を行うこともできる。また、旅行プランの評価を行ったユーザが、自身の考えた旅行プランを登録することもできるし、旅行プランの提示要求を行うこともできる。また、本実施形態では、閲覧ユーザが、自身が考えた旅行プランを登録することもできるし、他のユーザが登録した旅行プランの評価を行うこともできる。
また、本実施形態では、例えば自身が旅行プランを登録していなくても、他のユーザが登録した旅行プランに対する評価や、旅行プランの提示要求を行うことができる。
次に、図2を参照して、本実施形態の表示制御システムについて説明する。図2は、第一の実施形態の表示制御システムのシステム構成を説明する図である。
本実施形態の表示制御システム100は、表示制御サーバ200と、端末装置300−1、300−2、300−3、・・・、300−Nを有する。
本実施形態の表示制御システム100において、端末装置300−1、300−2、300−3、・・・、300−Nは、表示制御サーバ200に対する旅行プランの登録、表示制御サーバ200に登録された旅行プランの評価、表示制御サーバ200に対する旅行プランの提示要求等が行われる。
以下の説明では、端末装置300−1、300−2、300−3、・・・、300−Nについて、それぞれを区別しない場合には、単に端末装置300と呼ぶ。
本実施形態の表示制御サーバ200は、旅行プランデータベース210、評価ポイントデータベース220、ユーザ属性データベース230、属性データベース240、旅行プラン評価データベース250、重み付けデータベース260と、を有する。
また、本実施形態の表示制御サーバ200は、表示制御処理部270を有する。表示制御処理部270は、登録制御部280、表示制御部290を有する。
登録制御部280は、旅行プランデータベース210に対する旅行プランの登録、ユーザ属性データベース230に対する登録ユーザの評価ポイント及び属性の登録、旅行プラン評価データベース250に対する旅行プランの評価の登録を行う。
表示制御部290は、旅行プランの提示要求を受け付けて、旅行プランの表示順を決定し、端末装置へ表示させる。
次に、図3を参照し、本実施形態の表示制御サーバ200のハードウェア構成について説明する。
図3は、第一の実施形態の表示制御サーバのハードウェア構成を説明する図である。
以下に、本実施形態の表示制御サーバ200について説明する。図2は、学習支援サーバのハードウェア構成の一例を示す図である。
本実施形態の表示制御サーバ200は、それぞれバスBで相互に接続されている入力装置21、出力装置22、ドライブ装置23、補助記憶装置24、メモリ装置25、演算処理装置26及びインターフェース装置27を含む。
入力装置21は、各種の情報を入力するためものであり、例えばキーボードやマウス等で実現される。出力装置22は、各種の情報を出力するためのものであり、例えばディスプレイ等により実現される。インターフェース装置27は、モデム、LANカード等を含み、ネットワークに接続する為に用いられる。
表示制御プログラムは、表示制御サーバ200を制御する各種プログラムの少なくとも一部である。表示制御プログラムは例えば記憶媒体28の配布やネットワークからのダウンロードなどによって提供される。表示制御プログラムを記録した記憶媒体28は、CD−ROM、フレキシブルディスク、光磁気ディスク等の様に情報を光学的、電気的或いは磁気的に記録する記憶媒体、ROM、フラッシュメモリ等の様に情報を電気的に記録する半導体メモリ等、様々なタイプの記憶媒体を用いることができる。
また、表示制御プログラムは、表示制御プログラムを記録した記憶媒体28がドライブ装置23にセットされるとは記憶媒体28からドライブ装置23を介して補助記憶装置24にインストールされる。ネットワークからダウンロードされた表示制御プログラムは、インターフェース装置27を介して補助記憶装置24にインストールされる。
補助記憶装置24は、インストールされた表示制御プログラムを格納すると共に、必要なファイル、データ等を格納する。メモリ装置25は、コンピュータの起動時に補助記憶装置24から表示制御プログラムを読み出して格納する。そして、演算処理装置26はメモリ装置25に格納された表示制御プログラムに従って、後述するような各種処理を実現している。
また、本実施形態の表示制御サーバ200は、例えばタブレット型のコンピュータ等であっても良い。その場合、入力装置21と出力装置22の代わりに、表示機能を有するタッチパネル等の表示操作装置を有していても良い。また、本実施形態の端末装置300は、一般のタブレット型のコンピュータやスマートフォン等であり、そのハードウェア構成は、図3に示す表示制御サーバ200と同様であるから、説明を省略する。
次に、図4乃至図9を参照し、表示制御サーバ200の有する各データベースについて説明する。
図4は、第一の実施形態の旅行プランデータベースの一例を示す図である。
本実施形態の旅行プランデータベース210は、情報の項目として、旅行プラン名、登録ユーザ名、カテゴリ名、登録日を有する。項目「旅行プラン名」は、項目「登録ユーザ名」と、項目「カテゴリ名」と、項目「登録日」に対応付けられている。以下の説明では、項目「旅行プラン名」の値と、項目「登録ユーザ名」の値と、項目「カテゴリ名」の値と、項目「登録日」と、を含む情報を、旅行プラン情報と呼ぶ。
項目「旅行プラン名」の値は、旅行プランの名称を示す。旅行プランの名称は、例え登録ユーザにより入力されても良いし、予め用意された選択肢から選択されても良い。
項目「登録ユーザ名」の値は、対応する旅行プランを登録したユーザの名称を示す。項目「カテゴリ名」の値は、対応する旅行プラン名が含まれるカテゴリの名称を示す。
尚、本実施形態では、旅行プランを登録したユーザを特定する登録ユーザ情報(ユーザアカウント)として、登録ユーザ名を旅行プラン名に対応付けるものとしたが、これに限定されない。旅行プランデータベース210では、登録ユーザ名の代わりに、ユーザID等が用いられても良い。
項目「登録日」は、対応する旅行プラン名の旅行プランが登録された日付を示す。
図4では、例えば、旅行プラン情報211では、旅行プラン名「道央渓流釣りツアー」という旅行プランが2016年4月10日にユーザ名「AA」によって登録され、カテゴリ「渓流釣り」に分類されていることがわかる。
図5は、第一の実施形態の評価ポイントデータベースの一例を示す図である。
本実施形態の評価ポイントデータベース220は、予め表示制御システム100の管理者等により設けられるものである。評価ポイントデータベース220は、情報の項目として、評価内容と、評価ポイントとを有する。項目「評価内容」と、項目「評価ポイント」とは、対応付けられている。
項目「評価内容」の値は、評価の内容を示す。項目「評価ポイント」の値は、評価内容に対応した値を示す。本実施形態では、項目「評価ポイント」の値が大きいほど、評価が高いことを示すものとした。
図5では、例えば評価内容「面白い」には、評価ポイント「10」が対応付けられており、評価内容「役立った」には、評価ポイント「20」が対応付けられており、評価内容「行ってみた」には、評価ポイント「50」が対応付けられていることがわかる。
図6は、第一の実施形態のユーザ属性データベースの一例を示す図である。
本実施形態のユーザ属性データベース230は、情報の項目として、ユーザ名、カテゴリ名、属性、合計評価ポイントを有する。本実施形態のユーザ属性データベース230では、項目「ユーザ名」と、項目「カテゴリ名」、項目「属性」、項目「合計評価ポイント」とが対応付けられている。以下の説明では、項目「ユーザ名」の値と、その他の項目の値とを含む情報をユーザ属性情報と呼ぶ。
項目「ユーザ名」の値は、属性が付与されているユーザの名称を示す。尚、ユーザ属性データベース230では、属性が付与されたユーザを特定する情報として、ユーザ名を用いているが、これに限定されない。ユーザ属性データベース230では、ユーザ名以外のユーザアカウントを用いても良い。
項目「属性」の値は、項目「合計評価ポイント」の値に応じ、属性データベース240に基づき付与される。項目「合計評価ポイント」の値は、ユーザ名と一致する登録ユーザ名と対応付けられた旅行プランに対して、評価が入力される度に付与される評価ポイントの合計値である。
図6では、例えば、ユーザ名「AA」は、カテゴリ名「渓流釣り」において、属性は「マニア」であり、合計評価ポイントは「180」であることがわかる。また、ユーザ名「AA」は、カテゴリ名「花見」において、属性は「ファン」であり、合計評価ポイントは「70」であることがわかる。
このように、本実施形態では、旅行プランのカテゴリ名毎に、属性が付与されている。したがって、本実施形態では、同一のユーザに対して、カテゴリ毎に複数の属性が付与される場合がある。
図7は、第一の実施形態の属性データベースの一例を示す図である。本実施形態の属性データベース240は、予め表示制御システム100の管理者等により設けられるものである。
本実施形態の属性データベース240は、情報の項目として、属性と合計評価ポイントとを有する。
本実施形態では、合計評価ポイントが150以上のユーザの属性を「マニア」とし、合計評価ポイントが80以上149以下のユーザの属性を「フリーク」とし、合計評価ポイントが1以上79以下のユーザの属性を「ファン」としている。また、本実施形態では、合計評価ポイントが0のユーザの属性を「一般」としている。合計評価ポイントが0のユーザとは、例えば登録した旅行プランが誰からも評価されていないユーザや、又は旅行プランを登録していないユーザ等である。
以上のように、本実施形態では、合計評価ポイントの値が大きいほど、評価対象に対する関心が高いことを示す属性が付与されることがわかる。本実施形態では、評価対象とは、旅行プランが属するカテゴリである。また、本実施形態では、合計評価ポイントに応じて、段階的に属性が付与されるように、属性データベース240を生成している。
具体的には、例えば、最も旅行プランが属するカテゴリに関心が強いとされる属性は、「マニア」である。その次に旅行プランが属するカテゴリに関心が強いとされる属性は、「フリーク」である。この2つの属性には、1段階の差があると言える。
また、最も旅行プランが属するカテゴリに対する関心が薄いとされる属性は、「一般」である。したがって、属性「マニア」と属性「一般」の間には、3段階の差があると言える。
図8は、第一の実施形態の旅行プラン評価データベースの一例を示す図である。
本実施形態の旅行プラン評価データベース250は、情報の項目として、旅行プラン名、評価ユーザ名、カテゴリ名、評価ユーザの属性、評価内容、評価ポイントを有する。旅行プラン評価データベースでは、項目「旅行プラン名」と、その他の項目とが対応付けられている。以下の説明では、項目「旅行プラン名」の値と、その他の項目の値とを含む情報を、旅行プラン評価情報と呼ぶ。
項目「評価ユーザ名」の値は、評価内容を入力したユーザを特定するためのユーザの名称である。項目「評価ユーザの属性」の値は、評価ユーザ名と対応付けられた属性を示す。
尚、旅行プラン評価データベース250でも、他のデータベースと同様に、評価ユーザ情報として、評価ユーザ名の代わりにユーザID等を用いても良い。
図8では、例えば、旅行プラン評価情報251では、カテゴリ名「渓流釣り」、旅行プラン名「道央渓流釣りツアー」である旅行プランに、属性「フリーク」のユーザ名「EE」に、「役立った」と評価し、評価ポイント「20」が付与されたことがわかる。
本実施形態の旅行プラン評価データベース250は、登録制御部280が旅行プランに対する評価の入力を受け付けるたびに、入力された評価から生成される旅行プラン評価情報が追加されていく。
図9は、第一の実施形態の重み付けデータベースの一例を示す図である。
本実施形態の重み付けデータベース260は、情報の項目として、属性間の距離と、重みとを有する。属性間の距離と、重みとは、対応付けられている。
項目「属性間の距離」は、比較される2つの属性間の段階の差を示している。項目「重み」の値は、属性間の距離に対応した重みを示す。
図9では、属性間の距離「0」のとき重みは「5倍」であり、属性間の距離「1」のとき重みは「2倍」である。また、属性間の距離「3」のとき重みは「0倍」である。
つまり、本実施形態では、属性間の距離が近いほど、付与される重みが大きくなり、属性間の距離が遠いほど、付与される重みは小さくなる。
例えば、2つの属性が、両方とも「マニア」であった場合には、どちらの属性も同じ段階となる。しだかって、付与される重みは、最も大きい「5倍」となる。
また、例えば、2つの属性が「ファン」と「一般」であった場合には、両者の間に2段階の差があると言える。したがって、2つの属性「ファン」と属性「一般」との距離は「2」であり、付与される重みは「1倍」となる。
本実施形態の重みは、表示制御部290によるマッチング点数の算出の際に用いられる。マッチング点数とは、旅行プランに対する、旅行プランの提示要求を行った閲覧ユーザの関心の高さを示す指標値である。
次に、図10を参照し、本実施形態の表示制御サーバ200の機能について説明する。図10は、第一の実施形態の表示制御サーバの機能構成を説明する図である。
本実施形態の表示制御サーバ200は、表示制御処理部270を有する。本実施形態の表示制御処理部270は、表示制御サーバ200の演算処理装置26が、補助記憶装置25等に格納された表示制御プログラムを読み出して実行することにより、実現される。
本実施形態の表示制御処理部270は、登録制御部280と表示制御部290を有する。はじめに、登録制御部280について説明する。
本実施形態の登録制御部280は、入力受付部281、カテゴリ付与部282、旅行プラン格納部283、データベース検索部284、評価ポイント加算部285、属性変更判定部286、評価情報生成部287、評価情報格納部288を有する。
入力受付部281は、表示制御サーバ200に対する入力を受け付ける。具体的には、入力受付部281は、旅行プランの入力と、旅行プランに対する評価の入力とを受け付ける。
カテゴリ付与部282は、入力受付部281が受け付けた旅行プラン名を解析し、解析結果に応じて、旅行プラン名に、旅行プラン名が分類されるカテゴリを付与する。具体的には、カテゴリ付与部282は、単語と、カテゴリが対応付けられたテーブル等を有しており、旅行プラン名の形態素解析等を行った結果として得られた単語と対応付けられたカテゴリを、旅行プランが分類されるカテゴリとしても良い。
旅行プラン格納部283は、入力受付部281が受け付けた登録ユーザ名と、旅行プラン名と、カテゴリ付与部282により付与されたカテゴリの名称と、旅行プランの入力を受け付けた日付とを対応付けて、旅行プランデータベース210に格納する。つまり、旅行プラン格納部283は、入力受付部281が受け付けた登録ユーザ名と、旅行プラン名と、カテゴリ付与部282により付与されたカテゴリの名称と、から旅行プラン情報を生成し、旅行プランデータベース210へ登録する。
データベース検索部284は、各情報をキーとして、各データベースを検索する。具体的には、データベース検索部284は、旅行プラン名で旅行プランデータベース210を検索したり、ユーザ名でユーザ属性データベース230を検索したり、カテゴリ名で旅行プラン評価データベース250を検索したりする。
評価ポイント加算部285は、入力受付部281が旅行プランに対する評価を受け付ける度に、評価内容と対応する評価ポイントを、ユーザ属性データベース230の該当するユーザ名と対応する合計評価ポイントに加算する。
属性変更判定部286は、ユーザ属性データベース230において、評価ポイント加算部285による評価ポイントの加算を行った後に、属性データベース240を参照し、該当するユーザ名と対応する属性が変更されるか否かを判定する。
つまり、評価ポイント加算部285と、属性変更判定部286は、ユーザ属性データベース230に対して情報の登録を行う。
評価情報生成部287は、入力受付部281が受け付けた旅行プラン名と、評価ユーザ名と評価内容と、から、旅行プラン評価情報を生成する。旅行プラン評価情報の生成の詳細は、後述する。
評価情報格納部288は、評価情報生成部287により生成した旅行プラン評価情報を旅行プラン評価データベース250へ格納する。
次に、表示制御部290について説明する。本実施形態の表示制御部290は、入力受付部291、属性特定部292、評価情報抽出部293、マッチング点数算出部294、表示順決定部295、画面データ出力部296を有する。
入力受付部291は、表示制御サーバ200に対する入力を受け付ける。具体的には、入力受付部291は、端末装置300からの旅行プランの提示要求の入力を受け付ける。旅行プランの提示要求は、旅行プランのカテゴリと、提示要求を行ったユーザの情報と共に入力される。提示要求を行ったユーザの情報とは、例えば閲覧ユーザ名である。
属性特定部292は、ユーザ属性データベース230を参照し、入力受付部291が受け付けた閲覧ユーザ名と対応する属性を特定する。
評価情報抽出部293は、旅行プラン評価データベース250を参照し、入力受付部291が受け付けた旅行プランのカテゴリとカテゴリ名が一致する旅行プラン評価情報を抽出する。
マッチング点数算出部294は、重み付けデータベース260を参照し、閲覧ユーザの属性と、旅行プラン評価情報に含まれる評価ユーザの属性とを比較した結果に基づき、旅行プラン毎のマッチング点数を算出する。マッチング点数算出部294の詳細は後述する。
表示順決定部295は、算出された旅行プラン毎のマッチング点数に基づき、評価情報抽出部293により抽出された旅行プラン評価情報に含まれる旅行プランの表示順を決定する。
画面データ出力部296は、決定された表示順にしたがって旅行プランを表示させる画面の画面データを生成し、端末装置300へ出力する。
尚、本実施形態では、画面データを生成して出力するものとしたが、これに限定されない。表示制御部290は、例えば表示順決定部295により決定された表示順と、表示させる旅行プラン名とを端末装置300に出力しても良い。この場合は、端末装置300が、旅行プラン名を表示順にしたがって表示させる画面を端末装置300に表示させる。
次に、マッチング点数算出部294について説明する。本実施形態のマッチング点数算出部294は、重み付け部297、旅行プラン名抽出部298、点数合算部299を有する。
重み付け部297は、閲覧ユーザの属性と、旅行プラン評価情報に含まれる評価ユーザの属性とを比較結果と、重み付けデータベース260とから、付与する重みを決定し、旅行プラン評価情報に含まれる評価ポイントに重み付けを行う。
旅行プラン名抽出部298は、旅行プラン評価情報から、旅行プラン名を抽出する。より具体的には、旅行プラン名抽出部298は、評価情報抽出部293により抽出された旅行プラン評価情報の中から、ある旅行プラン名と、旅行プラン名が一致する旅行プラン評価情報を抽出する。
点数合算部299は、旅行プラン評価情報において、旅行プラン名が一致するもの同士の重みが付与された評価ポイントを合算する。
以下に、図11乃至図14を参照し、本実施形態の表示制御処理部270の処理を説明する。はじめに、図11及び図12を参照し、本実施形態の登録制御部280の処理について説明する。
図11は、第一の実施形態の登録制御部による登録制御部の処理を説明する第一のフローチャートである。図11では、登録制御部280による、旅行プランの登録の処理を説明する。
本実施形態の登録制御部280は、入力受付部281により、ユーザ名と、旅行プランの入力を受け付けた否かを判定する(ステップS1101)。
尚、本実施形態の表示制御サーバ200は、例えば端末装置300から旅行プランの登録要求を受け付けると、旅行プランの登録画面を端末装置300に表示させても良い。旅行プランの登録画面とは、例えば画面に地図や、地域毎の観光スポット等を表示させ、ユーザに、訪れたい地域や観光スポット等を選択させる画面であっても良い。また、旅行プランの登録画面には、ユーザが登録した旅行プランの名称(旅行プラン名)を入力させる入力欄が設けられるものとした。
さらに、本実施形態では、旅行プランの登録画面を表示させる前に、端末装置300にログイン画面を表示させ、ログイン画面において、ユーザ名を入力させても良い。
ステップS1101において、ユーザ名と旅行プラン名の入力を受け付けない場合、登録制御部280は、入力を受け付けるまで待機する。
ステップS1101において、ユーザ名と旅行プラン名の入力を受け付けると、登録制御部280は、カテゴリ付与部282により、入力された旅行プラン名のテキストデータを解析して解析結果に基づくカテゴリ名を取得し、旅行プラン名と対応付ける(ステップS1102)。
続いて、登録制御部280は、旅行プラン格納部283により、入力を受け付けたユーザ名を旅行プラン名とカテゴリ名と対応付けた旅行プラン情報として、旅行プランデータベース210へ格納し(ステップS1103)、処理を終了する。
図12は、第一の実施形態の登録制御部による処理を説明する第二のフローチャートである。図12では、ユーザ属性データベース230と旅行プラン評価データベース250を更新する処理について説明する。
本実施形態の登録制御部280は、入力受付部281により、旅行プランの評価内容と、評価を行うユーザのユーザ名の入力を受け付けた否かを判定する(ステップS1201)。尚、本実施形態では、評価を行うユーザは、事前に表示制御システム100にログインしているものした。したがって、評価要求は、評価要求を行った評価ユーザのユーザ名と共に入力される。
ステップS1201において、評価内容の入力を受け付けていない場合、登録制御部280は、評価内容の入力を受け付けるまで待機する。
ステップS1201において、評価内容の入力を受け付けると、登録制御部280は、データベース検索部284は、評価ポイントデータベース220を参照し、入力された評価内容と対応する評価ポイントを取得して保持する(ステップS1202)。
続いて、登録制御部280は、データベース検索部284により、入力された評価ユーザ名でユーザ属性データベース230を検索し、評価ユーザの属性を取得して保持する(ステップS1203)。尚、本実施形態では、ユーザ属性データベース230において、評価ユーザ名が存在しない場合、つまり、評価ユーザの属性が特定されていない場合には、評価ユーザの属性を「一般」とする。
続いて、登録制御部280は、データベース検索部284により、評価対象とされた旅行プラン名で旅行プランデータベース210を検索し、カテゴリ名と、評価対象の旅行プランを登録した登録ユーザ名とを取得する(ステップS1204)。
続いて登録制御部280は、評価情報生成部287により、旅行プラン名、評価ユーザ名、カテゴリ名、評価ユーザの属性、評価内容、評価ポイントを対応付けた旅行プラン評価情報を生成する。そして、評価情報格納部288により、生成した旅行プラン評価情報を旅行プラン評価データベース250へ格納する(ステップS1205)。この処理により、旅行プラン評価データベース250の更新の処理が完了する。
次に、登録制御部280は、データベース検索部284により、評価対象の旅行プランを登録した登録ユーザ名で、ユーザ属性データベース230を検索し、登録ユーザの合計評価ポイントを取得する。そして、登録制御部280は、評価ポイント加算部285により、登録ユーザ名の合計評価ポイントに、ステップS1208で取得した評価ポイントを加算する(ステップS1206)。
続いて登録制御部280は、属性変更判定部286により、属性データベース240を参照し、登録ユーザの属性が、評価ポイントの加算後に変更するか否かを判定する(ステップS1207)。
ステップS1207において、属性の変更がない場合には、登録制御部280は、ユーザ属性データベース230の更新の処理を終了する。ステップS1207において、属性の変更がある場合には、登録制御部280は、登録ユーザの属性を変更し(ステップS1208)、ユーザ属性データベース230の更新の処理を終了する。
以上が、表示制御処理部270の有する登録制御部280の処理である。次に、図13及び図14を参照し、表示制御部290の処理について説明する。
図13は、第一の実施形態の表示制御部の処理を説明する第一のフローチャートである。図13では、旅行プランの提示要求を受けた際の表示制御部290の処理を示している。
本実施形態の表示制御部290は、入力受付部291により、カテゴリ名と、旅行プランの提示要求の入力を受け付けたか否かを判定する(ステップS1301)。具体的には、入力受付部291は、旅行プランの提示要求と共に、提示要求を行った閲覧ユーザのユーザ名の入力を受け付けたか否かを判定する。尚、提示要求を行った閲覧ユーザは、提示要求を行う前に、表示制御システム100にログインしているものとし、提示要求を行った閲覧ユーザのユーザ名は、ログイン時に取得されていても良い。
ステップS1301において、入力を受け付けない場合、表示制御部290は、入力を受け付けるまで待機する。
ステップS1301において、入力を受け付けた場合、表示制御部290は、属性特定部292により、ユーザ属性データベース230に閲覧ユーザのユーザ名が存在するか否かを判定する(ステップS1302)。
ステップS1302において、該当するユーザ名がユーザ属性データベース230に存在する場合、属性特定部292は、閲覧ユーザのユーザ名と対応する属性を取得し(ステップS1303)、後述するステップS1305へ進む。
ステップS1302において、該当するユーザ名がユーザ属性データベース230に存在しない場合、属性特定部292は、閲覧ユーザの属性を「一般」とし(ステップS1304)、後述するステップS1305へ進む。
表示制御部290は、評価情報抽出部293により、入力されたカテゴリ名で、旅行プラン評価データベース250を検索し、旅行プラン評価データベース250において、入力されたカテゴリ名と同一のカテゴリ名が含まれる旅行プラン評価情報を全て抽出する(ステップS1305)。
続いて、表示制御部290は、マッチング点数算出部294により、抽出された旅行プ
旅行プラン評価情報に含まれる旅行プラン名毎に、マッチング点数を算出する(ステップS1306)。ステップS1306の詳細は後述する。
続いて、表示制御部290は、表示順決定部295により、マッチング点数が高い旅行プランから順に、旅行プラン名の表示順を決定する(ステップS1307)。続いて、表示制御部290は、画面データ出力部296により、決定された表示順に旅行プラン名を表示させる画面データを生成し、旅行プランの提示要求を送信した端末装置300へ、生成した画面データを出力し(ステップS1308)、処理を終了する。
次に、図14を参照して本実施形態のマッチング点数算出部294の処理について説明する。図14は、第一の実施形態の表示制御部の処理を説明する第二のフローチャートである。図14は、図13のステップS1306におけるマッチング点数算出部294の処理を示している。
本実施形態のマッチング点数算出部294は、重み付け部297により、評価情報抽出部293により抽出された旅行プラン評価情報のうち、先頭の旅行プラン評価情報に含まれる評価ユーザの属性と評価ポイントとを抽出する(ステップS1401)。
次に、重み付け部297は、図13のステップS1303又はステップS1304で取得した閲覧ユーザの属性と、旅行プラン評価情報に含まれる評価ユーザの属性とを比較する(ステップS1402)。続いて、重み付け部297は、重み付けデータベース260を参照し、属性の比較の結果に応じた重みを、旅行プラン評価情報から抽出された評価ポイントに乗算する(ステップS1403)。
より具体的には、重み付け部297は、閲覧ユーザの属性と、評価ユーザの属性との距離を求め、重み付けデータベース260を参照し、2つの属性の距離に応じた重み(倍率)を旅行プラン評価情報から抽出した評価ポイントに乗算する。
続いて、マッチング点数算出部294は、旅行プラン名抽出部298により、旅行プラン評価情報から旅行プラン名を抽出し、ステップS1403で求めた値と対応付けて保持する(ステップS1404)。
続いて、マッチング点数算出部294は、抽出された旅行プラン評価情報全てについて、処理を行ったか否かを判定する(ステップS1405)。
ステップS1405において、全ての旅行プラン評価情報に処理を行っていない場合、マッチング点数算出部294は、次の旅行プラン評価情報から評価ユーザの属性と評価ポイントとを抽出し(ステップS1406)、ステップS1402へ戻る。
ステップS1405において、抽出された全ての旅行プラン評価情報に処理を行った場合、マッチング点数算出部294は、点数合算部299により、旅行プラン名毎に保持された点数を合算し、旅行プラン名毎のマッチング点数を算出し(ステップS1407)、処理を終了する。
以下に、図4乃至図9を参照し、本実施形態の表示制御処理部270の処理について具体的に説明する。
はじめに、登録制御部280の処理について説明する。
ここでは、表示制御サーバ200に、ユーザ名「AA」により「道央渓流釣りツアー」という旅行プランが入力された場合について説明する。
登録制御部280は、ユーザ名「AA」のユーザにより、旅行プラン名「道央渓流釣りツアー」が入力されると、テキストデータ「道央渓流釣りツアー」を解析し、カテゴリを「渓流釣り」とする。そして、登録制御部280は、ユーザ名「AA」、旅行プラン名「道央渓流釣りツアー」、カテゴリ名「渓流釣り」を対応付けた旅行プラン情報211を旅行プランデータベース210へ格納する。
次に、ユーザ名「AA」により登録された旅行プラン名「道央渓流釣りツアー」の旅行プランが、ユーザ名「DD」により評価された場合について説明する。ここではユーザ名「DD」のユーザは、ユーザ名「AA」により登録された旅行プラン名「道央渓流釣りツアー」の旅行プランに対して、「行ってみた」という評価内容を入力したこととする。
この場合、登録制御部280は、評価ポイントデータベース220を参照し、評価内容「行ってみた」と対応する評価ポイント「50」を取得する(図5参照)。そして、登録制御部280は、評価ユーザ名となるユーザ名「DD」の属性を特定する。ユーザ属性データベース230において、評価ユーザ名となるユーザ名「DD」は存在しないため、登録制御部280は、評価ユーザ名「DD」と対応する属性を「一般」とする(図6参照)。
次に、登録制御部280は、評価対象の旅行プラン名「道央渓流釣りツアー」で、旅行プランデータベース210を検索し、登録ユーザ名「AA」と、カテゴリ名「渓流釣り」とを取得する(図4参照)。
そして、登録制御部280は、旅行プラン名「道央渓流釣りツアー」、評価ユーザ名「DD」、カテゴリ名「渓流釣り」、評価ユーザ名の属性「一般」、評価内容「行ってみた」、評価ポイント「50」を対応付けた旅行プラン評価情報252を生成し、旅行プラン評価データベース250へ格納する(図8参照)。
次に、登録制御部280は、ユーザ属性データベース230を参照し、評価対象の旅行プラン名「道央渓流釣りツアー」の登録ユーザ名「AA」のカテゴリ名「渓流釣り」における合計評価ポイント「180」を取得する(図6参照)。そして、登録制御部280は、合計評価ポイント「180」に、今回評価ユーザ「DD」の評価により付与された評価ポイント「50」を加算する。
ここで、登録ユーザ名「AA」のカテゴリ名「渓流釣り」における合計評価ポイントは「230」となる。
このとき、登録制御部280は、属性データベース240を参照し、登録ユーザの属性が変更されるか否かを判定する。ここでは、評価ポイントが150以上のユーザの属性は、全て「マニア」となるため、ユーザ名「AA」の属性は変更されないことがわかる(図7参照)。
次に、表示制御部290の処理について説明する。
ここでは、ユーザ名「EE」のユーザが、カテゴリ「渓流釣り」の旅行プランの提示要求を行ったものとして説明する。
表示制御部290は、旅行プランの提示要求を受けて、ユーザ属性データベース230を参照し、ユーザ名「EE」の属性「フリーク」を特定する(図6参照)。
次に表示制御部290は、旅行プラン評価データベース250から、カテゴリ名「渓流釣り」を含む旅行プラン評価情報251、252、253を抽出する。ここでは、カテゴリ名「渓流釣り」の旅行プラン名は、提示要求を行ったユーザへの提示候補となる旅行プラン名である。
続いて、表示制御部290は、抽出した旅行プラン評価情報251、252、253のそれぞれについて、マッチング点数を算出する。
マッチング点数とは、旅行プラン評価情報に含まれる旅行プラン名が示す旅行プランに対する、旅行プランの提示要求を行った閲覧ユーザの関心の高さを示す指標値である。
表示制御部290は、旅行プラン評価情報251から評価ユーザの属性「フリーク」と評価ポイント「20」を抽出する。そして、表示制御部290は、評価ユーザの属性「フリーク」と、提示要求を行った閲覧ユーザ「EE」の属性「フリーク」とを比較する。両者は一致しているため、表示制御部290は、重み付けデータベース260から重み「5」を取得し、旅行プラン評価情報251に含まれる評価ポイント「20」に重み「5」を乗算する。そして、表示制御部290は、旅行プラン評価情報251に含まれる旅行プラン名「道央渓流釣りツアー」と、乗算結果であるマッチング点数「100」とを対応付けて保持しておく。
表示制御部290は、旅行プラン評価情報252、253に対しても同様の処理を行う。旅行プラン評価情報252では、評価ユーザの属性は「マニア」であるから、評価ポイント「20」に乗算される重みは「2」である。よって、表示制御部290は、旅行プラン評価情報252から、旅行プラン名「カナダでフィッシングライフ」と、マッチング点数「40」とを対応付けて保持する。
旅行プラン評価情報253では、評価ユーザの属性は「一般」であるから、評価ポイント「50」に乗算される重みは「1」である。よって、表示制御部290は、旅行プラン評価情報252から、旅行プラン名「道央渓流釣りツアー」と、マッチング点数「50」とを対応付けて保持する。
次に、表示制御部290は、旅行プラン名毎に、マッチング点数を合算する。旅行プラン名「道央渓流釣りツアー」と対応付けられているマッチング点数は、「100」と「50」である。よって、旅行プラン名「道央渓流釣りツアー」のマッチング点数は「150」となる。また、旅行プラン名「カナダでフィッシングライフ」に対応付けられているマッチング点数は「40」である。
したがって、旅行プラン名「道央渓流釣りツアー」の方が旅行プラン名「カナダでフィッシングライフ」よりもマッチング点数が高くなることがわかる。よって、表示制御部290は、旅行プラン名を「道央渓流釣りツアー」、「カナダでフィッシングライフ」の順に、提示要求を行った端末装置300に表示させる。
このように、本実施形態では、旅行プランの提示要求を受けたとき、提示候補となる旅行プラン毎に、旅行プランを評価したユーザの属性が提示要求を行ったユーザの属性に近いほど、大きい値となる指標値を算出する。そして、本実施形態では、この指標値が大きい旅行プラン名から順に端末装置300に表示させる。
したがって、本実施形態によれば、旅行プランの提示要求を行ったユーザの関心が高いと推察される旅行プラン名から順に提示要求を行ったユーザの端末装置300に表示させることができ、ユーザの属性に応じた旅行プラン名を表示させることができる。
以下に、表示制御サーバ200により、端末装置300に表示される画面の例について説明する。
図15は、端末装置に表示される画面の例を示す図である。図15の画面151Aは、旅行プランの評価内容の入力画面の例を示し、画面151Bは、提示要求を受けて旅行プランが表示された画面の例を示す。
画面151Aは、例えば端末装置300のユーザが表示制御システム100にログインし、表示制御処理部270による処理が開始されたときに、端末装置300に表示されても良い。
画面151Aでは、カテゴリ選択欄152A、検索ボタン153、旅行プラン表示欄154を有する。
カテゴリ選択欄152Aは、プルダウンボタン152aを有する。画面151Aでは、プルダウンボタン152aが操作されると、カテゴリの選択肢が表示される。
検索ボタン153は、表示させたい旅行プランの提示指示を行うためのボタンである。本実施形態では、画面151Aにおいて、カテゴリ選択欄152Aでカテゴリが選択され、検索ボタン153が操作されると、画面151Aが画面151Bへ遷移する。
旅行プラン表示欄154は、表示制御サーバ200に登録された旅行プランのうち、新しい旅行プラン名から順に表示される。また、旅行プラン表示欄154では、旅行プラン毎に評価内容の入力欄155が表示される。
例えば、旅行プラン名「福岡花見ツアー」と対応付けられる評価内容の入力欄155において、「面白い」が選択されると、旅行プラン「福岡花見ツアー」に対して、評価ユーザから「面白い」という評価内容がなされたことになる。
画面151Bは、カテゴリ選択欄152Aで、「渓流釣り」が選択された場合の、旅行プランの表示例であり、閲覧ユーザ「EE」により提示要求が行われた場合に、閲覧ユーザ「EE」の端末装置300に表示される画面を示している。
画面151Bは、旅行プラン表示欄156と、戻るボタン157とが表示されている。旅行プラン表示欄156では、画面151Aの旅行プラン表示欄154に表示された旅行プランから、カテゴリ「渓流釣り」に含まれる旅行プランが抽出され、表示されている。さらに、旅行プラン表示欄156では、旅行プラン名毎にマッチング点数158が表示されている。
画面151Bの例では、マッチング点数が高い旅行プラン名から順に表示されていることがわかる。
以上のように、本実施形態によれば、旅行プランの提示要求(表示要求)を行った閲覧ユーザの属性と、旅行プランを評価した評価ユーザの属性とに基づき、閲覧ユーザの関心が高いと推察される旅行プランから順に表示させる。したがって、本実施形態によれば、ユーザの属性に応じた旅行プランを表示させることができる。
(第二の実施形態)
以下に図面を参照して、第二の実施形態について説明する。第二の実施形態では、旅行プランの提示要求を受けた際に、旅行プランデータベースに格納された全ての旅行プランが提示候補となる点が、第一の実施形態と相違する。したがって、以下の第二の実施形態の説明では、第一の実施形態との相違点についてのみ説明し、第一の実施形態と同様の機能構成を有するものには、第一の実施形態の説明で用いた符号と同様の符号を付与し、その説明を省略する。
本実施形態では、旅行プランをカテゴリに分類せず、ユーザ毎に1つの属性を付与するものとした。したがって、本実施形態では、旅行プランの提示要求を受け付けると、旅行プラン評価データベース250Aに格納されている全ての旅行プラン評価情報について、マッチング点数の算出を行う。
図16は、第二の実施形態の表示制御システムのシステム構成を説明する図である。
本実施形態の表示制御システム100Aは、表示制御サーバ200Aと、端末装置300を有する。
本実施形態の表示制御サーバ200Aは、旅行プランデータベース210A、ユーザ属性データベース230A、旅行プラン評価データベース250Aを有する。また、本実施形態の表示制御サーバ200Aは、本実施形態の表示制御処理部270Aを有する。表示制御処理部270Aは、登録制御部280A、表示制御部290Aを有する。
以下に本実施形態の旅行プランデータベース210A、ユーザ属性データベース230A、旅行プラン評価データベース250Aについて説明する。
図17は、第二の実施形態の旅行プランデータベースの一例を示す図である。本実施形態の旅行プランデータベース210Aは、情報の項目として、旅行プラン名と登録ユーザ名とを有する。旅行プランデータベース210Aは、項目「カテゴリ名」を有していない点以外は、第一の実施形態と同様であるから、説明を省略する。
図18は、第二の実施形態のユーザ属性データベースの一例を示す図である。本実施形態のユーザ属性データベース230Aは、情報の項目として、ユーザ名、属性、合計評価ポイントを有する。本実施形態のユーザ属性データベース230Aは、項目「カテゴリ名」を有していない点以外は、第一の実施形態と同様であるから、説明を省略する。
図19は、第二の実施形態の旅行プラン評価データベースの一例を示す図である。本実施形態の旅行プラン評価データベース250Aは、情報の項目として、旅行プラン名、評価ユーザ名、評価ユーザの属性、費用か内容、評価ポイントを有する。本実施形態の旅行プラン評価データベース250Aは、項目「カテゴリ名」を有していない点以外は、第一の実施形態と同様であるから、説明を省略する。
次に、図20を参照し、本実施形態の表示制御サーバ200Aの機能について説明する。図20は、第二の実施形態の表示制御サーバの機能構成を説明する図である。
本実施形態の表示制御サーバ200Aは、表示制御処理部270Aを有する。本実施形態の表示制御処理部270Aは、登録制御部280Aと表示制御部290Aを有する。はじめに、登録制御部280Aについて説明する。
本実施形態の登録制御部280Aは、入力受付部281、旅行プラン格納部283A、データベース検索部284、評価ポイント加算部285、属性変更判定部286、評価情報生成部287A、評価情報格納部288を有する。
旅行プラン格納部283Aは、入力受付部281が受け付けた旅行プラン名と、登録ユーザ名とを対応付けて、旅行プランデータベース210Aに格納する。
評価情報生成部287Aは、旅行プラン名、評価ユーザ名、評価ユーザの属性、評価内容、評価ポイントを対応付けた旅行プラン評価情報を生成する。
本実施形態の表示制御部290Aは、入力受付部291、属性特定部292、マッチング点数算出部294、表示順決定部295、画面データ出力部296を有する。表示制御部290Aの有する各部は、第一の実施形態と同様である。
次に、図21乃至図23を参照し、本実施形態の表示制御処理部270Aの処理を説明する。はじめに、図21及び図22を参照し、本実施形態の登録制御部280Aの処理について説明する。
図21は、第二の実施形態の登録制御部による登録制御部の処理を説明する第一のフローチャートである。図21では、登録制御部280Aによる、旅行プランの登録の処理を説明する。
本実施形態の登録制御部280Aは、入力受付部281により、ユーザ名と、旅行プランの入力を受け付けた否かを判定する(ステップS2101)。
続いて、登録制御部280Aは、旅行プラン格納部283Aにより、入力を受け付けたユーザ名を旅行プランの名称(旅行プラン名)と対応付けて旅行プラン情報とし、旅行プランデータベース210Aへ格納し(ステップS2102)、処理を終了する。
図22は、第二の実施形態の登録制御部による処理を説明する第二のフローチャートである。図22では、ユーザ属性データベース230Aと旅行プラン評価データベース250Aを更新する処理について説明する。
図22のステップS2201からステップS2203の処理は、図12のステップS1201からステップS1203までの処理と同様であるから、説明を省略する。
ステップS2203に続いて、登録制御部280Aは、データベース検索部284により、評価対象とされた旅行プラン名で旅行プランデータベース210Aを検索し、評価対象の旅行プランを登録した登録ユーザ名とを取得する(ステップS2204)。
続いて登録制御部280Aは、評価情報生成部287Aにより、旅行プラン名、評価ユーザ名、評価ユーザの属性、評価内容、評価ポイントを対応付けた旅行プラン評価情報を生成する。そして、評価情報格納部288により、生成した旅行プラン評価情報を旅行プラン評価データベース250Aへ格納する(ステップS2205)。この処理により、旅行プラン評価データベース250Aの更新の処理が完了する。
図22のステップS2206からステップS2208までの処理は、図12のステップS1206からステップS1208までの処理と同様であるから、説明を省略する。
次に、図23を参照し、本実施形態の表示制御部290Aの処理について説明する。図23は、第二の実施形態の表示制御部による処理を説明する第二のフローチャートである。
図23のステップS2301からステップS2304までの処理は、図13のステップS1301からステップS1304までの処理と同様であるから、説明を省略する。
ステップS2303又はステップS2304に続いて、表示制御部290Aは、マッチング点数算出部294により、旅行プラン毎のマッチング点数を算出する(ステップS2305)。ステップS2305とステップS2306の処理は、図13のステップS1306とステップS1307の処理と同様であるから、説明を省略する。
以上の処理により、本実施形態では、旅行プランのカテゴリに関係なく、提示要求を行ったユーザの関心が高そうな旅行プランを表示させることができる。
(第三の実施形態)
以下に図面を参照して第三の実施形態について説明する。第三の実施形態では、特定の属性のユーザに対し、ログイン後に外部のサーバから取得した旅行プラン名を表示させる点が、第一及び第二の実施形態と相違する。したがって、以下の第三の実施形態の説明では、第一及び第二の実施形態との相違点についてのみ説明し、第一及び第二の実施形態と同様の機能構成を有するものには、第一及び第二の実施形態の説明で用いた符号と同様の符号を付与し、その説明を省略する。
図24は、第三の実施形態の表示制御システムのシステム構成を説明する図である。
本実施形態の表示制御システム100Bは、表示制御サーバ200Bと、端末装置300を有する。また、本実施形態の表示制御サーバ200Bは、外部のサーバ400と通信を行う。
本実施形態の表示制御サーバ200Bは、第一の実施形態の表示制御サーバ200の有する各データベースに加え、ユーザ属性データベース230Aを有する。また、本実施形態の表示制御サーバ200Bは、表示制御処理部270Bを有する。表示制御処理部270Bは、登録制御部280と、表示制御部290Bを有する。
本実施形態において、サーバ400は、例えば旅行会社等により提供される旅行プランに関する情報が格納されたサーバ等である。本実施形態では、旅行プランの提示要求を行ったユーザの属性が、例えば「マニア」や「フリーク」等、旅行に対する関心が高いことを示す属性であった場合、ログイン後の画面に、このユーザが特に関心を持っていると思われるカテゴリをサーバ400へ通知する。そして、表示制御サーバ200Bは、サーバ400から、通知したカテゴリにおいて推奨される旅行プランを取得し、端末装置300に表示させても良い。
言い換えれば、本実施形態では、旅行が好きなユーザのユーザ名と、このユーザが関心を持っているカテゴリとを旅行会社のサーバ400へ通知し、このカテゴリにおいて旅行会社が推奨する旅行プランを取得してユーザに提示する。
以下に、図25を参照し、本実施形態の表示制御サーバ200Bの機能について説明する。図25は、第三の実施形態の表示制御サーバの機能構成を説明する図である。
本実施形態の表示制御サーバ200Bは、表示制御処理部270Bを有する。本実施形態の表示制御処理部270Bは、表示制御部290Bを有する。
本実施形態の表示制御部290Bは、第一の実施形態の表示制御部290の有する各部に加え、属性提供部301、旅行プラン取得部302を有する。
本実施形態の属性提供部301は、ログインされたユーザの属性が特定の属性であった場合に、ユーザに関する情報をサーバ400へ出力する。本実施形態において、サーバ400に提供される、ユーザに関する情報とは、ユーザ名と、このユーザが関心を持っているカテゴリとを含む。
旅行プラン取得部302は、サーバ400から、端末装置300に表示させる旅行プラン名を取得する。
次に、図26を参照して、本実施形態の表示制御部290Bの処理について説明する。図26は、第三の実施形態の表示制御部の処理を説明するフローチャートである。図26では、表示制御処理部270Bを実現する表示制御プログラムの起動要求を受けたときの表示制御部290Bの処理を示している。
本実施形態の表示制御処理部270Bは、起動要求を受け付けたか否かを判定する(ステップS2601)。ステップS2601において、起動要求を受け付けない場合、表示制御処理部270Bは、起動要求を受け付けるまで待機する。
ステップS2601において、起動要求を受け付けた場合、表示制御部290Bは、属性特定部292により、ログインしたユーザの属性を特定する(ステップS2602)。具体的には、属性特定部292は、ユーザ属性データベース230Aを参照し、ログインしたユーザのユーザ名と対応付けられた属性を特定する。尚、ユーザ属性データベース230Aに該当するユーザ名が存在しない場合、表示制御部290Bは、ログインしたユーザの属性を一般としてステップS2603へ進んでも良いし、ステップS2608に進んでも良い。
続いて、表示制御部290Bは、属性提供部301により、特定した属性が「フリーク」以上であるか否かを判定する(ステップS2603)。ステップS2603において、特定した属性が「フリーク」未満である場合、表示制御部290Bは、後述するステップS2708へ進む。
ステップS2603において、特定した属性が「フリーク」又は「マニア」であった場合、属性提供部301は、ユーザ属性データベース230において、このユーザと対応する属性のうち、「フリーク」以上のカテゴリを特定する(ステップS2604)。
続いて、属性提供部301は、ログインしたユーザのユーザ名と、属性が「フリーク」以上のカテゴリの名称(カテゴリ名)と、このカテゴリの属性とをサーバ400へ送信する(ステップS2605)。
続いて、表示制御部290Bは、旅行プラン取得部302により、サーバ400からカテゴリに対応した旅行プラン名を取得する(ステップS2606)。ここで取得される旅行プラン名は、サーバ400において、旅行会社等により推奨される旅行プランの名称である。
続いて、表示制御部290Bは、画面データ出力部296により、取得した旅行プラン名を端末装置300に表示させ(ステップS2607)、処理を終了する。
尚、ステップS2603において、特定した属性が「フリーク」未満の「ファン」又は「一般」である場合、表示制御部290Bは、旅行プランデータベース210を参照し、登録の日付が新しい順に旅行プランを取得して端末装置300に表示させ、(ステップS2608)、処理を終了する。
図27は、第三の実施形態において端末装置に表示される画面の例を示す図である。図27に示す画面271は、例えばユーザ名「AA」のユーザがログインした際に、端末装置300に表示される画面の例を示している。
画面271は、メッセージ表示欄272、カテゴリ表示欄273、旅行プラン表示欄274、検索画面ボタン275を有する。
メッセージ表示欄272には、表示された旅行プランがユーザに対して推奨される旅行プランであることを示すメッセージが表示される。カテゴリ表示欄273は、表示された旅行プランのカテゴリ名が表示される。旅行プラン表示欄274には、サーバ400から取得した旅行プラン名が表示される。
ユーザ属性データベース230Aにおいて、ユーザ名「AA」の属性は「マニア」であり、「フリーク」以上である(図18参照)。
したがって、表示制御部290Bは、ユーザ属性データベース230を参照し、ユーザ名「AA」と対応する属性が「フリーク」以上であるカテゴリ名を特定する。ユーザ属性データベース230において、ユーザ名「AA」と対応する属性には、「ファン」と「マニア」がある。よって、属性提供部301は、属性が「マニア」のカテゴリ名「渓流釣り」を特定し、ユーザ名「AA」と、カテゴリ名「渓流釣り」と、属性「マニア」と、をサーバ400へ送信する。
サーバ400は、サーバ400の有する旅行プランデータベースにおいて、カテゴリ名「渓流釣り」に分類された旅行プランの中から、属性「マニア」に対して推奨される旅行プランを抽出し、表示制御サーバ200Bへ送信する。尚、属性「マニア」に対して推奨される旅行プランは、例えばサーバ400において、予め用意されていても良い。
表示制御サーバ200Bは、旅行プラン取得部302により、サーバ400から送信された旅行プランを取得し、端末装置300に表示させる。
したがって、画面271において、メッセージ表示欄272には、「「AA」さんにお勧めの旅行プラン」というメッセージが表示され、カテゴリ表示欄273には、カテゴリ名「渓流釣りツアー」が表示される。
また、旅行プラン表示欄274には、サーバ400から取得した旅行プラン「アウトドアフィッシング」、「解禁直後ツアー」等が表示される。
また、画面271では、検索画面ボタン275が操作されると、通常のログイン後に表示される画面151Aに遷移しても良い。
以上のように、本実施形態によれば、表示制御システム100Bにおいて付与されたユーザの属性と、ユーザのカテゴリ毎の属性とを外部のサーバ400へ提供することで、旅行プランデータベース210に登録された旅行プラン以外の旅行プランの提示を受けることができる。
また、本実施形態では、ユーザの属性と、ユーザのカテゴリ毎の属性とを外部のサーバ400へ提供するものとしたが、これに限定されない。表示制御サーバ200Bは、例えはユーザの属性のみをサーバ400へ提供しても良い。つまり、表示制御サーバ200Bは、ユーザの旅行に対する関心の高さを示す情報を外部のサーバ400に提供しても良い。
この場合、サーバ400は、関心の高さに応じて旅行プランを表示制御サーバ200Bに送信し、表示制御サーバ200Bは、この旅行プランを端末装置300に表示させても良い。
(変形例)
上述した各実施形態では、閲覧ユーザの属性と、提示候補の旅行プランを評価した評価ユーザの属性とに基づいて、閲覧ユーザの端末装置300へ表示させる旅行プランの表示順を決定したが、以下の例では、閲覧ユーザの属性と、提示候補の旅行プランを登録した登録ユーザの属性とに基づいて、閲覧ユーザの端末装置300へ旅行プランを表示させても良い。
図28は、閲覧ユーザの属性と登録ユーザの属性とに基づく旅行プランの表示の処理を説明するフローチャートである。
図28のステップS2801からステップS2805までの処理は、図13のステップS1301からステップS1305までの処理と同様であるから、説明を省略する。
ステップS2803又はステップS2804に続いて、表示制御部290は、抽出された旅行プラン評価情報に含まれる旅行プラン名のうち、閲覧ユーザと属性が一致する登録ユーザにより登録された旅行プランの旅行プラン名を特定する(ステップS2806)。
具体的には、表示制御部290は、例えば、抽出された旅行プラン評価情報に含まれる旅行プラン名毎に、旅行プランデータベース210を検索し、対応付けられた登録ユーザ名を取得する。そして、表示制御部290は、取得したユーザ名で、ユーザ属性データベース230を検索すれば、旅行プラン名の登録ユーザの属性を特定することができる。よって、表示制御部290は、抽出された旅行プラン評価情報に含まれる旅行プラン名のうち、閲覧ユーザと属性が一致する登録ユーザにより登録された旅行プラン名を特定できる。
続いて、表示制御部290は、ステップS2806で特定された旅行プラン名から順に、端末装置300に表示させる旅行プラン名の表示順を決定する(ステップS2807)。
具体的には、表示制御部290は、閲覧ユーザと属性が近い登録ユーザにより登録された旅行プラン名から順に表示させる。したがって、この場合には、ステップS2806で特定された旅行プラン名が最上位となる。次に、登録ユーザの属性が、閲覧ユーザの属性と1段階離れたている旅行プラン名が表示されることになる。
続いて、表示制御部290は、ステップS2807で決定した表示順に旅行プラン名を表示させる画面データを生成して端末装置300へ出力し(ステップS2808)、処理を終了する。
この例では、閲覧ユーザの属性と、属性が一致するユーザにより登録された旅行プラン名から順に端末装置300に表示させるため、ユーザの属性に応じた旅行プランを表示させることができる。
本発明は、具体的に開示された実施形態に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。