WO2017199415A1 - 表示制御プログラム、表示制御装置及び表示制御方法 - Google Patents

Abstract

特定のユーザアカウントに対応づけた旅行プランの登録を受け付け、登録された前記旅行プランに対する評価の入力を受け付け、前記評価の入力に応じて、前記特定のユーザアカウントについて属性を特定し、特定した前記属性に応じて、前記特定のユーザアカウントについて提供する旅行プランの表示を制御する、処理をコンピュータに実行させる。

Description

表示制御プログラム、表示制御装置及び表示制御方法

　本発明は、表示制御プログラム、表示制御装置及び表示制御方法に関する。

　従来では、ユーザからの提示要求に応じて旅行プランを提示するシステムが知られている。また、従来では、ユーザの評価により、投稿されたデータに順位を付与し、付与された順位に基づき投稿されたデータを携帯端末等に表示させる技術が知られている。

特開２００８－０９０５６０号公報 特開２０１３－０７３５７７号公報

　従来技術のシステムでは、例えば、評価の高い順に投稿データを表示する。投稿データの有用性は、投稿データが示す情報に対するユーザの関心に影響されるものである。従来技術のシステムは、投稿データが示す情報に対する関心が高いユーザと、投稿データが示す情報に対する関心が低いユーザとに対して、一律な表示順で投稿データを表示するものである。つまり、従来技術のシステムは、ユーザの関心に応じて、投稿データの表示を制御することが困難であった。

　１つの側面では、ユーザの属性に応じた旅行プランを表示させることが可能な表示制御プログラム、表示制御装置及び表示制御方法を提供することを目的としている。

　１つの態様では、特定のユーザアカウントに対応づけた旅行プランの登録を受け付け、登録された前記旅行プランに対する評価の入力を受け付け、前記評価の入力に応じて、前記特定のユーザアカウントについて属性を特定し、特定した前記属性に応じて、前記特定のユーザアカウントについて提供する旅行プランの表示を制御する、処理をコンピュータに実行させる。

　上記各処理は、上記各処理を実現する機能部、上記各処理を手順としてコンピュータにより実行させる方法、プログラムを記憶したコンピュータが読み取り可能な記憶媒体とすることもできる。

　ユーザの属性に応じた旅行プランを表示させることができる。

表示制御システムの概要を説明する図である。 第一の実施形態の表示制御システムのシステム構成を説明する図である。 第一の実施形態の表示制御サーバのハードウェア構成を説明する図である。 第一の実施形態の旅行プランデータベースの一例を示す図である。 第一の実施形態の評価ポイントデータベースの一例を示す図である。 第一の実施形態のユーザ属性データベースの一例を示す図である。 第一の実施形態の属性データベースの一例を示す図である。 第一の実施形態の旅行プラン評価データベースの一例を示す図である。 第一の実施形態の重み付けデータベースの一例を示す図である。 第一の実施形態の表示制御サーバの機能構成を説明する図である。 第一の実施形態の登録制御部による登録制御部の処理を説明する第一のフローチャートである。 第一の実施形態の登録制御部による処理を説明する第二のフローチャートである。 第一の実施形態の表示制御部の処理を説明する第一のフローチャートである。 第一の実施形態の表示制御部の処理を説明する第二のフローチャートである。 端末装置に表示される画面の例を示す図である。 第二の実施形態の表示制御システムのシステム構成を説明する図である。 第二の実施形態の旅行プランデータベースの一例を示す図である。 第二の実施形態のユーザ属性データベースの一例を示す図である。 第二の実施形態の旅行プラン評価データベースの一例を示す図である。 第二の実施形態の表示制御サーバの機能構成を説明する図である。 第二の実施形態の登録制御部による登録制御部の処理を説明する第一のフローチャートである。 第二の実施形態の登録制御部による処理を説明する第二のフローチャートである。 第二の実施形態の表示制御部による処理を説明する第二のフローチャートである。 第三の実施形態の表示制御システムのシステム構成を説明する図である。 第三の実施形態の表示制御サーバの機能構成を説明する図である。 第三の実施形態の表示制御部の処理を説明するフローチャートである。 第三の実施形態において端末装置に表示される画面の例を示す図である。 閲覧ユーザの属性と登録ユーザの属性とに基づく旅行プランの表示の処理を説明するフローチャートである。

　（第一の実施形態）
　以下に、図面を参照して第一の実施形態について説明する。図１は、表示制御システムの概要を説明する図である。

　本実施形態の表示制御システムでは、旅行プランの提示要求を行ったユーザに対し、旅行プランを評価した評価者の属性及び旅行プランの評価結果と、提示要求を行ったユーザの属性とに基づき、提示する旅行プランの表示順を決定する。

　本実施形態の表示制御システムは、ユーザの端末装置において旅行プランの登録を受け付けると、旅行プランと、旅行プランを登録したユーザの情報とを対応付けて、旅行プランデータベース２１０に格納する。以下の説明では、旅行プランを登録したユーザを登録ユーザと呼び、登録ユーザの情報を登録ユーザ情報と呼ぶ。

　また、本実施形態の表示制御システムは、ユーザの端末装置において、旅行プランに対する評価が入力されると、登録ユーザ情報と、入力された評価内容に応じた評価ポイントから特定される属性とを対応付けて、ユーザ属性データベース２３０に格納する。評価内容と評価ポイントとは、予め評価ポイントデータベース２２０において予め対応付けられている。また、評価ポイントと登録ユーザ情報の属性とは、属性データベース２４０において予め対応付けられている。

　また、表示制御システムは、旅行プランに対する評価が入力されると、評価対象の旅行プランと、評価内容及び評価ポイントと、評価を行ったユーザの情報と、このユーザの属性とを対応付けて、旅行プラン評価データベース２５０へ格納する。以下の説明では、旅行プランの評価を行ったユーザを評価ユーザと呼び、評価ユーザの情報を評価ユーザ情報と呼ぶ。

　さらに、本実施形態の表示制御システムでは、ユーザの端末装置において、旅行プランの提示要求を受け付けると、ユーザ属性データベース２３０を参照し、提示要求を行ったユーザの属性を特定する。以下の説明では、旅行プランの提示要求を行ったユーザを、閲覧ユーザと呼び、閲覧ユーザの情報を閲覧ユーザ情報と呼ぶ。

　表示制御システムは、閲覧ユーザの属性を特定すると、旅行プラン評価データベース２５０を参照し、評価ユーザの属性と、閲覧ユーザの属性との比較結果に基づく重み付けを行う。属性の比較結果と重みとは、重み付けデータベース２６０において、予め対応付けられている。

　そして、表示制御システムは、重みに応じた順に、旅行プランの表示順を決定し、提示要求を受け付けた端末装置へ決められた表示順に旅行プランを表示させる。

　具体的には、表示制御システムは、閲覧ユーザの属性と、評価ユーザの属性とが近い旅行プランに付与する重みを大きくし、閲覧ユーザの属性と、評価ユーザの属性とが離れている旅行プランに付与する重みを小さくする。

　本実施形態では、以上のように、旅行プランの提示要求を受け付けると、旅行プラン毎に、提示要求を行った閲覧ユーザの属性と、旅行プランの評価を行った評価ユーザの属性との比較結果に応じた重みを付与する。そして、表示制御システムは、付与された重みにしたがって、旅行プランの表示順を決定し、閲覧ユーザの端末装置へ表示させる。

　よって、本実施形態によれば、旅行プランの提示要求を行ったユーザに対し、ユーザの属性に応じた、ユーザの嗜好に合わせた旅行プランから順に提示することができる。

　尚、本実施形態では、登録ユーザ、評価ユーザ、閲覧ユーザのそれぞれが異なるユーザであっても良いし、登録ユーザと閲覧ユーザが同一のユーザであっても良いし、評価ユーザと閲覧ユーザが同一のユーザであっても良い。

　つまり、本実施形態では、旅行プランを登録したユーザが、他のユーザが登録した旅行プランの評価を行うことも、旅行プランの提示要求を行うこともできる。また、旅行プランの評価を行ったユーザが、自身の考えた旅行プランを登録することもできるし、旅行プランの提示要求を行うこともできる。また、本実施形態では、閲覧ユーザが、自身が考えた旅行プランを登録することもできるし、他のユーザが登録した旅行プランの評価を行うこともできる。

　また、本実施形態では、例えば自身が旅行プランを登録していなくても、他のユーザが登録した旅行プランに対する評価や、旅行プランの提示要求を行うことができる。

　次に、図２を参照して、本実施形態の表示制御システムについて説明する。図２は、第一の実施形態の表示制御システムのシステム構成を説明する図である。

　本実施形態の表示制御システム１００は、表示制御サーバ２００と、端末装置３００－１、３００－２、３００－３、・・・、３００－Ｎを有する。

　本実施形態の表示制御システム１００において、端末装置３００－１、３００－２、３００－３、・・・、３００－Ｎは、表示制御サーバ２００に対する旅行プランの登録、表示制御サーバ２００に登録された旅行プランの評価、表示制御サーバ２００に対する旅行プランの提示要求等が行われる。

　以下の説明では、端末装置３００－１、３００－２、３００－３、・・・、３００－Ｎについて、それぞれを区別しない場合には、単に端末装置３００と呼ぶ。

　本実施形態の表示制御サーバ２００は、旅行プランデータベース２１０、評価ポイントデータベース２２０、ユーザ属性データベース２３０、属性データベース２４０、旅行プラン評価データベース２５０、重み付けデータベース２６０と、を有する。

　また、本実施形態の表示制御サーバ２００は、表示制御処理部２７０を有する。表示制御処理部２７０は、登録制御部２８０、表示制御部２９０を有する。

　登録制御部２８０は、旅行プランデータベース２１０に対する旅行プランの登録、ユーザ属性データベース２３０に対する登録ユーザの評価ポイント及び属性の登録、旅行プラン評価データベース２５０に対する旅行プランの評価の登録を行う。

　表示制御部２９０は、旅行プランの提示要求を受け付けて、旅行プランの表示順を決定し、端末装置へ表示させる。

　次に、図３を参照し、本実施形態の表示制御サーバ２００のハードウェア構成について説明する。

　図３は、第一の実施形態の表示制御サーバのハードウェア構成を説明する図である。

　以下に、本実施形態の表示制御サーバ２００について説明する。図２は、学習支援サーバのハードウェア構成の一例を示す図である。

　本実施形態の表示制御サーバ２００は、それぞれバスＢで相互に接続されている入力装置２１、出力装置２２、ドライブ装置２３、補助記憶装置２４、メモリ装置２５、演算処理装置２６及びインターフェース装置２７を含む。

　入力装置２１は、各種の情報を入力するためものであり、例えばキーボードやマウス等で実現される。出力装置２２は、各種の情報を出力するためのものであり、例えばディスプレイ等により実現される。インターフェース装置２７は、モデム、ＬＡＮカード等を含み、ネットワークに接続する為に用いられる。

　表示制御プログラムは、表示制御サーバ２００を制御する各種プログラムの少なくとも一部である。表示制御プログラムは例えば記憶媒体２８の配布やネットワークからのダウンロードなどによって提供される。表示制御プログラムを記録した記憶媒体２８は、ＣＤ－ＲＯＭ、フレキシブルディスク、光磁気ディスク等の様に情報を光学的、電気的或いは磁気的に記録する記憶媒体、ＲＯＭ、フラッシュメモリ等の様に情報を電気的に記録する半導体メモリ等、様々なタイプの記憶媒体を用いることができる。

　また、表示制御プログラムは、表示制御プログラムを記録した記憶媒体２８がドライブ装置２３にセットされるとは記憶媒体２８からドライブ装置２３を介して補助記憶装置２４にインストールされる。ネットワークからダウンロードされた表示制御プログラムは、インターフェース装置２７を介して補助記憶装置２４にインストールされる。

　補助記憶装置２４は、インストールされた表示制御プログラムを格納すると共に、必要なファイル、データ等を格納する。メモリ装置２５は、コンピュータの起動時に補助記憶装置２４から表示制御プログラムを読み出して格納する。そして、演算処理装置２６はメモリ装置２５に格納された表示制御プログラムに従って、後述するような各種処理を実現している。

　また、本実施形態の表示制御サーバ２００は、例えばタブレット型のコンピュータ等であっても良い。その場合、入力装置２１と出力装置２２の代わりに、表示機能を有するタッチパネル等の表示操作装置を有していても良い。また、本実施形態の端末装置３００は、一般のタブレット型のコンピュータやスマートフォン等であり、そのハードウェア構成は、図３に示す表示制御サーバ２００と同様であるから、説明を省略する。

　次に、図４乃至図９を参照し、表示制御サーバ２００の有する各データベースについて説明する。

　図４は、第一の実施形態の旅行プランデータベースの一例を示す図である。

　本実施形態の旅行プランデータベース２１０は、情報の項目として、旅行プラン名、登録ユーザ名、カテゴリ名、登録日を有する。項目「旅行プラン名」は、項目「登録ユーザ名」と、項目「カテゴリ名」と、項目「登録日」に対応付けられている。以下の説明では、項目「旅行プラン名」の値と、項目「登録ユーザ名」の値と、項目「カテゴリ名」の値と、項目「登録日」と、を含む情報を、旅行プラン情報と呼ぶ。

　項目「旅行プラン名」の値は、旅行プランの名称を示す。旅行プランの名称は、例え登録ユーザにより入力されても良いし、予め用意された選択肢から選択されても良い。

　項目「登録ユーザ名」の値は、対応する旅行プランを登録したユーザの名称を示す。項目「カテゴリ名」の値は、対応する旅行プラン名が含まれるカテゴリの名称を示す。

　尚、本実施形態では、旅行プランを登録したユーザを特定する登録ユーザ情報（ユーザアカウント）として、登録ユーザ名を旅行プラン名に対応付けるものとしたが、これに限定されない。旅行プランデータベース２１０では、登録ユーザ名の代わりに、ユーザＩＤ等が用いられても良い。

　項目「登録日」は、対応する旅行プラン名の旅行プランが登録された日付を示す。

　図４では、例えば、旅行プラン情報２１１では、旅行プラン名「道央渓流釣りツアー」という旅行プランが２０１６年４月１０日にユーザ名「ＡＡ」によって登録され、カテゴリ「渓流釣り」に分類されていることがわかる。

　図５は、第一の実施形態の評価ポイントデータベースの一例を示す図である。

　本実施形態の評価ポイントデータベース２２０は、予め表示制御システム１００の管理者等により設けられるものである。評価ポイントデータベース２２０は、情報の項目として、評価内容と、評価ポイントとを有する。項目「評価内容」と、項目「評価ポイント」とは、対応付けられている。

　項目「評価内容」の値は、評価の内容を示す。項目「評価ポイント」の値は、評価内容に対応した値を示す。本実施形態では、項目「評価ポイント」の値が大きいほど、評価が高いことを示すものとした。

　図５では、例えば評価内容「面白い」には、評価ポイント「１０」が対応付けられており、評価内容「役立った」には、評価ポイント「２０」が対応付けられており、評価内容「行ってみた」には、評価ポイント「５０」が対応付けられていることがわかる。

　図６は、第一の実施形態のユーザ属性データベースの一例を示す図である。

　本実施形態のユーザ属性データベース２３０は、情報の項目として、ユーザ名、カテゴリ名、属性、合計評価ポイントを有する。本実施形態のユーザ属性データベース２３０では、項目「ユーザ名」と、項目「カテゴリ名」、項目「属性」、項目「合計評価ポイント」とが対応付けられている。以下の説明では、項目「ユーザ名」の値と、その他の項目の値とを含む情報をユーザ属性情報と呼ぶ。

　項目「ユーザ名」の値は、属性が付与されているユーザの名称を示す。尚、ユーザ属性データベース２３０では、属性が付与されたユーザを特定する情報として、ユーザ名を用いているが、これに限定されない。ユーザ属性データベース２３０では、ユーザ名以外のユーザアカウントを用いても良い。

　項目「属性」の値は、項目「合計評価ポイント」の値に応じ、属性データベース２４０に基づき付与される。項目「合計評価ポイント」の値は、ユーザ名と一致する登録ユーザ名と対応付けられた旅行プランに対して、評価が入力される度に付与される評価ポイントの合計値である。

　図６では、例えば、ユーザ名「ＡＡ」は、カテゴリ名「渓流釣り」において、属性は「マニア」であり、合計評価ポイントは「１８０」であることがわかる。また、ユーザ名「ＡＡ」は、カテゴリ名「花見」において、属性は「ファン」であり、合計評価ポイントは「７０」であることがわかる。

　このように、本実施形態では、旅行プランのカテゴリ名毎に、属性が付与されている。したがって、本実施形態では、同一のユーザに対して、カテゴリ毎に複数の属性が付与される場合がある。

　図７は、第一の実施形態の属性データベースの一例を示す図である。本実施形態の属性データベース２４０は、予め表示制御システム１００の管理者等により設けられるものである。

　本実施形態の属性データベース２４０は、情報の項目として、属性と合計評価ポイントとを有する。
本実施形態では、合計評価ポイントが１５０以上のユーザの属性を「マニア」とし、合計評価ポイントが８０以上１４９以下のユーザの属性を「フリーク」とし、合計評価ポイントが１以上７９以下のユーザの属性を「ファン」としている。また、本実施形態では、合計評価ポイントが０のユーザの属性を「一般」としている。合計評価ポイントが０のユーザとは、例えば登録した旅行プランが誰からも評価されていないユーザや、又は旅行プランを登録していないユーザ等である。

　以上のように、本実施形態では、合計評価ポイントの値が大きいほど、評価対象に対する関心が高いことを示す属性が付与されることがわかる。本実施形態では、評価対象とは、旅行プランが属するカテゴリである。また、本実施形態では、合計評価ポイントに応じて、段階的に属性が付与されるように、属性データベース２４０を生成している。

　具体的には、例えば、最も旅行プランが属するカテゴリに関心が強いとされる属性は、「マニア」である。その次に旅行プランが属するカテゴリに関心が強いとされる属性は、「フリーク」である。この２つの属性には、１段階の差があると言える。

　また、最も旅行プランが属するカテゴリに対する関心が薄いとされる属性は、「一般」である。したがって、属性「マニア」と属性「一般」の間には、３段階の差があると言える。

　図８は、第一の実施形態の旅行プラン評価データベースの一例を示す図である。

　本実施形態の旅行プラン評価データベース２５０は、情報の項目として、旅行プラン名、評価ユーザ名、カテゴリ名、評価ユーザの属性、評価内容、評価ポイントを有する。旅行プラン評価データベースでは、項目「旅行プラン名」と、その他の項目とが対応付けられている。以下の説明では、項目「旅行プラン名」の値と、その他の項目の値とを含む情報を、旅行プラン評価情報と呼ぶ。

　項目「評価ユーザ名」の値は、評価内容を入力したユーザを特定するためのユーザの名称である。項目「評価ユーザの属性」の値は、評価ユーザ名と対応付けられた属性を示す。

　尚、旅行プラン評価データベース２５０でも、他のデータベースと同様に、評価ユーザ情報として、評価ユーザ名の代わりにユーザＩＤ等を用いても良い。

　図８では、例えば、旅行プラン評価情報２５１では、カテゴリ名「渓流釣り」、旅行プラン名「道央渓流釣りツアー」である旅行プランに、属性「フリーク」のユーザ名「ＥＥ」に、「役立った」と評価し、評価ポイント「２０」が付与されたことがわかる。

　本実施形態の旅行プラン評価データベース２５０は、登録制御部２８０が旅行プランに対する評価の入力を受け付けるたびに、入力された評価から生成される旅行プラン評価情報が追加されていく。

　図９は、第一の実施形態の重み付けデータベースの一例を示す図である。

　本実施形態の重み付けデータベース２６０は、情報の項目として、属性間の距離と、重みとを有する。属性間の距離と、重みとは、対応付けられている。

　項目「属性間の距離」は、比較される２つの属性間の段階の差を示している。項目「重み」の値は、属性間の距離に対応した重みを示す。

　図９では、属性間の距離「０」のとき重みは「５倍」であり、属性間の距離「１」のとき重みは「２倍」である。また、属性間の距離「３」のとき重みは「０倍」である。

　つまり、本実施形態では、属性間の距離が近いほど、付与される重みが大きくなり、属性間の距離が遠いほど、付与される重みは小さくなる。

　例えば、２つの属性が、両方とも「マニア」であった場合には、どちらの属性も同じ段階となる。しだかって、付与される重みは、最も大きい「５倍」となる。

　また、例えば、２つの属性が「ファン」と「一般」であった場合には、両者の間に２段階の差があると言える。したがって、２つの属性「ファン」と属性「一般」との距離は「２」であり、付与される重みは「１倍」となる。

　本実施形態の重みは、表示制御部２９０によるマッチング点数の算出の際に用いられる。マッチング点数とは、旅行プランに対する、旅行プランの提示要求を行った閲覧ユーザの関心の高さを示す指標値である。

　次に、図１０を参照し、本実施形態の表示制御サーバ２００の機能について説明する。図１０は、第一の実施形態の表示制御サーバの機能構成を説明する図である。

　本実施形態の表示制御サーバ２００は、表示制御処理部２７０を有する。本実施形態の表示制御処理部２７０は、表示制御サーバ２００の演算処理装置２６が、補助記憶装置２５等に格納された表示制御プログラムを読み出して実行することにより、実現される。

　本実施形態の表示制御処理部２７０は、登録制御部２８０と表示制御部２９０を有する。はじめに、登録制御部２８０について説明する。

　本実施形態の登録制御部２８０は、入力受付部２８１、カテゴリ付与部２８２、旅行プラン格納部２８３、データベース検索部２８４、評価ポイント加算部２８５、属性変更判定部２８６、評価情報生成部２８７、評価情報格納部２８８を有する。

　入力受付部２８１は、表示制御サーバ２００に対する入力を受け付ける。具体的には、入力受付部２８１は、旅行プランの入力と、旅行プランに対する評価の入力とを受け付ける。

　カテゴリ付与部２８２は、入力受付部２８１が受け付けた旅行プラン名を解析し、解析結果に応じて、旅行プラン名に、旅行プラン名が分類されるカテゴリを付与する。具体的には、カテゴリ付与部２８２は、単語と、カテゴリが対応付けられたテーブル等を有しており、旅行プラン名の形態素解析等を行った結果として得られた単語と対応付けられたカテゴリを、旅行プランが分類されるカテゴリとしても良い。

　旅行プラン格納部２８３は、入力受付部２８１が受け付けた登録ユーザ名と、旅行プラン名と、カテゴリ付与部２８２により付与されたカテゴリの名称と、旅行プランの入力を受け付けた日付とを対応付けて、旅行プランデータベース２１０に格納する。つまり、旅行プラン格納部２８３は、入力受付部２８１が受け付けた登録ユーザ名と、旅行プラン名と、カテゴリ付与部２８２により付与されたカテゴリの名称と、から旅行プラン情報を生成し、旅行プランデータベース２１０へ登録する。

　データベース検索部２８４は、各情報をキーとして、各データベースを検索する。具体的には、データベース検索部２８４は、旅行プラン名で旅行プランデータベース２１０を検索したり、ユーザ名でユーザ属性データベース２３０を検索したり、カテゴリ名で旅行プラン評価データベース２５０を検索したりする。

　評価ポイント加算部２８５は、入力受付部２８１が旅行プランに対する評価を受け付ける度に、評価内容と対応する評価ポイントを、ユーザ属性データベース２３０の該当するユーザ名と対応する合計評価ポイントに加算する。

　属性変更判定部２８６は、ユーザ属性データベース２３０において、評価ポイント加算部２８５による評価ポイントの加算を行った後に、属性データベース２４０を参照し、該当するユーザ名と対応する属性が変更されるか否かを判定する。

　つまり、評価ポイント加算部２８５と、属性変更判定部２８６は、ユーザ属性データベース２３０に対して情報の登録を行う。

　評価情報生成部２８７は、入力受付部２８１が受け付けた旅行プラン名と、評価ユーザ名と評価内容と、から、旅行プラン評価情報を生成する。旅行プラン評価情報の生成の詳細は、後述する。

　評価情報格納部２８８は、評価情報生成部２８７により生成した旅行プラン評価情報を旅行プラン評価データベース２５０へ格納する。

　次に、表示制御部２９０について説明する。本実施形態の表示制御部２９０は、入力受付部２９１、属性特定部２９２、評価情報抽出部２９３、マッチング点数算出部２９４、表示順決定部２９５、画面データ出力部２９６を有する。

　入力受付部２９１は、表示制御サーバ２００に対する入力を受け付ける。具体的には、入力受付部２９１は、端末装置３００からの旅行プランの提示要求の入力を受け付ける。旅行プランの提示要求は、旅行プランのカテゴリと、提示要求を行ったユーザの情報と共に入力される。提示要求を行ったユーザの情報とは、例えば閲覧ユーザ名である。

　属性特定部２９２は、ユーザ属性データベース２３０を参照し、入力受付部２９１が受け付けた閲覧ユーザ名と対応する属性を特定する。

　評価情報抽出部２９３は、旅行プラン評価データベース２５０を参照し、入力受付部２９１が受け付けた旅行プランのカテゴリとカテゴリ名が一致する旅行プラン評価情報を抽出する。

　マッチング点数算出部２９４は、重み付けデータベース２６０を参照し、閲覧ユーザの属性と、旅行プラン評価情報に含まれる評価ユーザの属性とを比較した結果に基づき、旅行プラン毎のマッチング点数を算出する。マッチング点数算出部２９４の詳細は後述する。

　表示順決定部２９５は、算出された旅行プラン毎のマッチング点数に基づき、評価情報抽出部２９３により抽出された旅行プラン評価情報に含まれる旅行プランの表示順を決定する。

　画面データ出力部２９６は、決定された表示順にしたがって旅行プランを表示させる画面の画面データを生成し、端末装置３００へ出力する。

　尚、本実施形態では、画面データを生成して出力するものとしたが、これに限定されない。表示制御部２９０は、例えば表示順決定部２９５により決定された表示順と、表示させる旅行プラン名とを端末装置３００に出力しても良い。この場合は、端末装置３００が、旅行プラン名を表示順にしたがって表示させる画面を端末装置３００に表示させる。

　次に、マッチング点数算出部２９４について説明する。本実施形態のマッチング点数算出部２９４は、重み付け部２９７、旅行プラン名抽出部２９８、点数合算部２９９を有する。

　重み付け部２９７は、閲覧ユーザの属性と、旅行プラン評価情報に含まれる評価ユーザの属性とを比較結果と、重み付けデータベース２６０とから、付与する重みを決定し、旅行プラン評価情報に含まれる評価ポイントに重み付けを行う。

　旅行プラン名抽出部２９８は、旅行プラン評価情報から、旅行プラン名を抽出する。より具体的には、旅行プラン名抽出部２９８は、評価情報抽出部２９３により抽出された旅行プラン評価情報の中から、ある旅行プラン名と、旅行プラン名が一致する旅行プラン評価情報を抽出する。

　点数合算部２９９は、旅行プラン評価情報において、旅行プラン名が一致するもの同士の重みが付与された評価ポイントを合算する。

　以下に、図１１乃至図１４を参照し、本実施形態の表示制御処理部２７０の処理を説明する。はじめに、図１１及び図１２を参照し、本実施形態の登録制御部２８０の処理について説明する。

　図１１は、第一の実施形態の登録制御部による登録制御部の処理を説明する第一のフローチャートである。図１１では、登録制御部２８０による、旅行プランの登録の処理を説明する。

　本実施形態の登録制御部２８０は、入力受付部２８１により、ユーザ名と、旅行プランの入力を受け付けた否かを判定する（ステップＳ１１０１）。

　尚、本実施形態の表示制御サーバ２００は、例えば端末装置３００から旅行プランの登録要求を受け付けると、旅行プランの登録画面を端末装置３００に表示させても良い。旅行プランの登録画面とは、例えば画面に地図や、地域毎の観光スポット等を表示させ、ユーザに、訪れたい地域や観光スポット等を選択させる画面であっても良い。また、旅行プランの登録画面には、ユーザが登録した旅行プランの名称（旅行プラン名）を入力させる入力欄が設けられるものとした。

　さらに、本実施形態では、旅行プランの登録画面を表示させる前に、端末装置３００にログイン画面を表示させ、ログイン画面において、ユーザ名を入力させても良い。

　ステップＳ１１０１において、ユーザ名と旅行プラン名の入力を受け付けない場合、登録制御部２８０は、入力を受け付けるまで待機する。

　ステップＳ１１０１において、ユーザ名と旅行プラン名の入力を受け付けると、登録制御部２８０は、カテゴリ付与部２８２により、入力された旅行プラン名のテキストデータを解析して解析結果に基づくカテゴリ名を取得し、旅行プラン名と対応付ける（ステップＳ１１０２）。

　続いて、登録制御部２８０は、旅行プラン格納部２８３により、入力を受け付けたユーザ名を旅行プラン名とカテゴリ名と対応付けた旅行プラン情報として、旅行プランデータベース２１０へ格納し（ステップＳ１１０３）、処理を終了する。

　図１２は、第一の実施形態の登録制御部による処理を説明する第二のフローチャートである。図１２では、ユーザ属性データベース２３０と旅行プラン評価データベース２５０を更新する処理について説明する。

　本実施形態の登録制御部２８０は、入力受付部２８１により、旅行プランの評価内容と、評価を行うユーザのユーザ名の入力を受け付けた否かを判定する（ステップＳ１２０１）。尚、本実施形態では、評価を行うユーザは、事前に表示制御システム１００にログインしているものした。したがって、評価要求は、評価要求を行った評価ユーザのユーザ名と共に入力される。

　ステップＳ１２０１において、評価内容の入力を受け付けていない場合、登録制御部２８０は、評価内容の入力を受け付けるまで待機する。

　ステップＳ１２０１において、評価内容の入力を受け付けると、登録制御部２８０は、データベース検索部２８４は、評価ポイントデータベース２２０を参照し、入力された評価内容と対応する評価ポイントを取得して保持する（ステップＳ１２０２）。

　続いて、登録制御部２８０は、データベース検索部２８４により、入力された評価ユーザ名でユーザ属性データベース２３０を検索し、評価ユーザの属性を取得して保持する（ステップＳ１２０３）。尚、本実施形態では、ユーザ属性データベース２３０において、評価ユーザ名が存在しない場合、つまり、評価ユーザの属性が特定されていない場合には、評価ユーザの属性を「一般」とする。

　続いて、登録制御部２８０は、データベース検索部２８４により、評価対象とされた旅行プラン名で旅行プランデータベース２１０を検索し、カテゴリ名と、評価対象の旅行プランを登録した登録ユーザ名とを取得する（ステップＳ１２０４）。

　続いて登録制御部２８０は、評価情報生成部２８７により、旅行プラン名、評価ユーザ名、カテゴリ名、評価ユーザの属性、評価内容、評価ポイントを対応付けた旅行プラン評価情報を生成する。そして、評価情報格納部２８８により、生成した旅行プラン評価情報を旅行プラン評価データベース２５０へ格納する（ステップＳ１２０５）。この処理により、旅行プラン評価データベース２５０の更新の処理が完了する。

　次に、登録制御部２８０は、データベース検索部２８４により、評価対象の旅行プランを登録した登録ユーザ名で、ユーザ属性データベース２３０を検索し、登録ユーザの合計評価ポイントを取得する。そして、登録制御部２８０は、評価ポイント加算部２８５により、登録ユーザ名の合計評価ポイントに、ステップＳ１２０８で取得した評価ポイントを加算する（ステップＳ１２０６）。

　続いて登録制御部２８０は、属性変更判定部２８６により、属性データベース２４０を参照し、登録ユーザの属性が、評価ポイントの加算後に変更するか否かを判定する（ステップＳ１２０７）。

　ステップＳ１２０７において、属性の変更がない場合には、登録制御部２８０は、ユーザ属性データベース２３０の更新の処理を終了する。ステップＳ１２０７において、属性の変更がある場合には、登録制御部２８０は、登録ユーザの属性を変更し（ステップＳ１２０８）、ユーザ属性データベース２３０の更新の処理を終了する。

　以上が、表示制御処理部２７０の有する登録制御部２８０の処理である。次に、図１３及び図１４を参照し、表示制御部２９０の処理について説明する。

　図１３は、第一の実施形態の表示制御部の処理を説明する第一のフローチャートである。図１３では、旅行プランの提示要求を受けた際の表示制御部２９０の処理を示している。

　本実施形態の表示制御部２９０は、入力受付部２９１により、カテゴリ名と、旅行プランの提示要求の入力を受け付けたか否かを判定する（ステップＳ１３０１）。具体的には、入力受付部２９１は、旅行プランの提示要求と共に、提示要求を行った閲覧ユーザのユーザ名の入力を受け付けたか否かを判定する。尚、提示要求を行った閲覧ユーザは、提示要求を行う前に、表示制御システム１００にログインしているものとし、提示要求を行った閲覧ユーザのユーザ名は、ログイン時に取得されていても良い。

　ステップＳ１３０１において、入力を受け付けない場合、表示制御部２９０は、入力を受け付けるまで待機する。

　ステップＳ１３０１において、入力を受け付けた場合、表示制御部２９０は、属性特定部２９２により、ユーザ属性データベース２３０に閲覧ユーザのユーザ名が存在するか否かを判定する（ステップＳ１３０２）。

　ステップＳ１３０２において、該当するユーザ名がユーザ属性データベース２３０に存在する場合、属性特定部２９２は、閲覧ユーザのユーザ名と対応する属性を取得し（ステップＳ１３０３）、後述するステップＳ１３０５へ進む。

　ステップＳ１３０２において、該当するユーザ名がユーザ属性データベース２３０に存在しない場合、属性特定部２９２は、閲覧ユーザの属性を「一般」とし（ステップＳ１３０４）、後述するステップＳ１３０５へ進む。

　表示制御部２９０は、評価情報抽出部２９３により、入力されたカテゴリ名で、旅行プラン評価データベース２５０を検索し、旅行プラン評価データベース２５０において、入力されたカテゴリ名と同一のカテゴリ名が含まれる旅行プラン評価情報を全て抽出する（ステップＳ１３０５）。

　続いて、表示制御部２９０は、マッチング点数算出部２９４により、抽出された旅行プ
旅行プラン評価情報に含まれる旅行プラン名毎に、マッチング点数を算出する（ステップＳ１３０６）。ステップＳ１３０６の詳細は後述する。

　続いて、表示制御部２９０は、表示順決定部２９５により、マッチング点数が高い旅行プランから順に、旅行プラン名の表示順を決定する（ステップＳ１３０７）。続いて、表示制御部２９０は、画面データ出力部２９６により、決定された表示順に旅行プラン名を表示させる画面データを生成し、旅行プランの提示要求を送信した端末装置３００へ、生成した画面データを出力し（ステップＳ１３０８）、処理を終了する。

　次に、図１４を参照して本実施形態のマッチング点数算出部２９４の処理について説明する。図１４は、第一の実施形態の表示制御部の処理を説明する第二のフローチャートである。図１４は、図１３のステップＳ１３０６におけるマッチング点数算出部２９４の処理を示している。

　本実施形態のマッチング点数算出部２９４は、重み付け部２９７により、評価情報抽出部２９３により抽出された旅行プラン評価情報のうち、先頭の旅行プラン評価情報に含まれる評価ユーザの属性と評価ポイントとを抽出する（ステップＳ１４０１）。

　次に、重み付け部２９７は、図１３のステップＳ１３０３又はステップＳ１３０４で取得した閲覧ユーザの属性と、旅行プラン評価情報に含まれる評価ユーザの属性とを比較する（ステップＳ１４０２）。続いて、重み付け部２９７は、重み付けデータベース２６０を参照し、属性の比較の結果に応じた重みを、旅行プラン評価情報から抽出された評価ポイントに乗算する（ステップＳ１４０３）。

　より具体的には、重み付け部２９７は、閲覧ユーザの属性と、評価ユーザの属性との距離を求め、重み付けデータベース２６０を参照し、２つの属性の距離に応じた重み（倍率）を旅行プラン評価情報から抽出した評価ポイントに乗算する。

　続いて、マッチング点数算出部２９４は、旅行プラン名抽出部２９８により、旅行プラン評価情報から旅行プラン名を抽出し、ステップＳ１４０３で求めた値と対応付けて保持する（ステップＳ１４０４）。

　続いて、マッチング点数算出部２９４は、抽出された旅行プラン評価情報全てについて、処理を行ったか否かを判定する（ステップＳ１４０５）。

　ステップＳ１４０５において、全ての旅行プラン評価情報に処理を行っていない場合、マッチング点数算出部２９４は、次の旅行プラン評価情報から評価ユーザの属性と評価ポイントとを抽出し（ステップＳ１４０６）、ステップＳ１４０２へ戻る。

　ステップＳ１４０５において、抽出された全ての旅行プラン評価情報に処理を行った場合、マッチング点数算出部２９４は、点数合算部２９９により、旅行プラン名毎に保持された点数を合算し、旅行プラン名毎のマッチング点数を算出し（ステップＳ１４０７）、処理を終了する。

　以下に、図４乃至図９を参照し、本実施形態の表示制御処理部２７０の処理について具体的に説明する。

　はじめに、登録制御部２８０の処理について説明する。

　ここでは、表示制御サーバ２００に、ユーザ名「ＡＡ」により「道央渓流釣りツアー」という旅行プランが入力された場合について説明する。

　登録制御部２８０は、ユーザ名「ＡＡ」のユーザにより、旅行プラン名「道央渓流釣りツアー」が入力されると、テキストデータ「道央渓流釣りツアー」を解析し、カテゴリを「渓流釣り」とする。そして、登録制御部２８０は、ユーザ名「ＡＡ」、旅行プラン名「道央渓流釣りツアー」、カテゴリ名「渓流釣り」を対応付けた旅行プラン情報２１１を旅行プランデータベース２１０へ格納する。

　次に、ユーザ名「ＡＡ」により登録された旅行プラン名「道央渓流釣りツアー」の旅行プランが、ユーザ名「ＤＤ」により評価された場合について説明する。ここではユーザ名「ＤＤ」のユーザは、ユーザ名「ＡＡ」により登録された旅行プラン名「道央渓流釣りツアー」の旅行プランに対して、「行ってみた」という評価内容を入力したこととする。

　この場合、登録制御部２８０は、評価ポイントデータベース２２０を参照し、評価内容「行ってみた」と対応する評価ポイント「５０」を取得する（図５参照）。そして、登録制御部２８０は、評価ユーザ名となるユーザ名「ＤＤ」の属性を特定する。ユーザ属性データベース２３０において、評価ユーザ名となるユーザ名「ＤＤ」は存在しないため、登録制御部２８０は、評価ユーザ名「ＤＤ」と対応する属性を「一般」とする（図６参照）。

　次に、登録制御部２８０は、評価対象の旅行プラン名「道央渓流釣りツアー」で、旅行プランデータベース２１０を検索し、登録ユーザ名「ＡＡ」と、カテゴリ名「渓流釣り」とを取得する（図４参照）。

　そして、登録制御部２８０は、旅行プラン名「道央渓流釣りツアー」、評価ユーザ名「ＤＤ」、カテゴリ名「渓流釣り」、評価ユーザ名の属性「一般」、評価内容「行ってみた」、評価ポイント「５０」を対応付けた旅行プラン評価情報２５２を生成し、旅行プラン評価データベース２５０へ格納する（図８参照）。

　次に、登録制御部２８０は、ユーザ属性データベース２３０を参照し、評価対象の旅行プラン名「道央渓流釣りツアー」の登録ユーザ名「ＡＡ」のカテゴリ名「渓流釣り」における合計評価ポイント「１８０」を取得する（図６参照）。そして、登録制御部２８０は、合計評価ポイント「１８０」に、今回評価ユーザ「ＤＤ」の評価により付与された評価ポイント「５０」を加算する。

　ここで、登録ユーザ名「ＡＡ」のカテゴリ名「渓流釣り」における合計評価ポイントは「２３０」となる。

　このとき、登録制御部２８０は、属性データベース２４０を参照し、登録ユーザの属性が変更されるか否かを判定する。ここでは、評価ポイントが１５０以上のユーザの属性は、全て「マニア」となるため、ユーザ名「ＡＡ」の属性は変更されないことがわかる（図７参照）。

　次に、表示制御部２９０の処理について説明する。

　ここでは、ユーザ名「ＥＥ」のユーザが、カテゴリ「渓流釣り」の旅行プランの提示要求を行ったものとして説明する。

　表示制御部２９０は、旅行プランの提示要求を受けて、ユーザ属性データベース２３０を参照し、ユーザ名「ＥＥ」の属性「フリーク」を特定する（図６参照）。

　次に表示制御部２９０は、旅行プラン評価データベース２５０から、カテゴリ名「渓流釣り」を含む旅行プラン評価情報２５１、２５２、２５３を抽出する。ここでは、カテゴリ名「渓流釣り」の旅行プラン名は、提示要求を行ったユーザへの提示候補となる旅行プラン名である。

　続いて、表示制御部２９０は、抽出した旅行プラン評価情報２５１、２５２、２５３のそれぞれについて、マッチング点数を算出する。

　マッチング点数とは、旅行プラン評価情報に含まれる旅行プラン名が示す旅行プランに対する、旅行プランの提示要求を行った閲覧ユーザの関心の高さを示す指標値である。

　表示制御部２９０は、旅行プラン評価情報２５１から評価ユーザの属性「フリーク」と評価ポイント「２０」を抽出する。そして、表示制御部２９０は、評価ユーザの属性「フリーク」と、提示要求を行った閲覧ユーザ「ＥＥ」の属性「フリーク」とを比較する。両者は一致しているため、表示制御部２９０は、重み付けデータベース２６０から重み「５」を取得し、旅行プラン評価情報２５１に含まれる評価ポイント「２０」に重み「５」を乗算する。そして、表示制御部２９０は、旅行プラン評価情報２５１に含まれる旅行プラン名「道央渓流釣りツアー」と、乗算結果であるマッチング点数「１００」とを対応付けて保持しておく。

　表示制御部２９０は、旅行プラン評価情報２５２、２５３に対しても同様の処理を行う。旅行プラン評価情報２５２では、評価ユーザの属性は「マニア」であるから、評価ポイント「２０」に乗算される重みは「２」である。よって、表示制御部２９０は、旅行プラン評価情報２５２から、旅行プラン名「カナダでフィッシングライフ」と、マッチング点数「４０」とを対応付けて保持する。

　旅行プラン評価情報２５３では、評価ユーザの属性は「一般」であるから、評価ポイント「５０」に乗算される重みは「１」である。よって、表示制御部２９０は、旅行プラン評価情報２５２から、旅行プラン名「道央渓流釣りツアー」と、マッチング点数「５０」とを対応付けて保持する。

　次に、表示制御部２９０は、旅行プラン名毎に、マッチング点数を合算する。旅行プラン名「道央渓流釣りツアー」と対応付けられているマッチング点数は、「１００」と「５０」である。よって、旅行プラン名「道央渓流釣りツアー」のマッチング点数は「１５０」となる。また、旅行プラン名「カナダでフィッシングライフ」に対応付けられているマッチング点数は「４０」である。

　したがって、旅行プラン名「道央渓流釣りツアー」の方が旅行プラン名「カナダでフィッシングライフ」よりもマッチング点数が高くなることがわかる。よって、表示制御部２９０は、旅行プラン名を「道央渓流釣りツアー」、「カナダでフィッシングライフ」の順に、提示要求を行った端末装置３００に表示させる。

　このように、本実施形態では、旅行プランの提示要求を受けたとき、提示候補となる旅行プラン毎に、旅行プランを評価したユーザの属性が提示要求を行ったユーザの属性に近いほど、大きい値となる指標値を算出する。そして、本実施形態では、この指標値が大きい旅行プラン名から順に端末装置３００に表示させる。

　したがって、本実施形態によれば、旅行プランの提示要求を行ったユーザの関心が高いと推察される旅行プラン名から順に提示要求を行ったユーザの端末装置３００に表示させることができ、ユーザの属性に応じた旅行プラン名を表示させることができる。

　以下に、表示制御サーバ２００により、端末装置３００に表示される画面の例について説明する。

　図１５は、端末装置に表示される画面の例を示す図である。図１５の画面１５１Ａは、旅行プランの評価内容の入力画面の例を示し、画面１５１Ｂは、提示要求を受けて旅行プランが表示された画面の例を示す。

　画面１５１Ａは、例えば端末装置３００のユーザが表示制御システム１００にログインし、表示制御処理部２７０による処理が開始されたときに、端末装置３００に表示されても良い。

　画面１５１Ａでは、カテゴリ選択欄１５２Ａ、検索ボタン１５３、旅行プラン表示欄１５４を有する。

　カテゴリ選択欄１５２Ａは、プルダウンボタン１５２ａを有する。画面１５１Ａでは、プルダウンボタン１５２ａが操作されると、カテゴリの選択肢が表示される。

　検索ボタン１５３は、表示させたい旅行プランの提示指示を行うためのボタンである。本実施形態では、画面１５１Ａにおいて、カテゴリ選択欄１５２Ａでカテゴリが選択され、検索ボタン１５３が操作されると、画面１５１Ａが画面１５１Ｂへ遷移する。

　旅行プラン表示欄１５４は、表示制御サーバ２００に登録された旅行プランのうち、新しい旅行プラン名から順に表示される。また、旅行プラン表示欄１５４では、旅行プラン毎に評価内容の入力欄１５５が表示される。

　例えば、旅行プラン名「福岡花見ツアー」と対応付けられる評価内容の入力欄１５５において、「面白い」が選択されると、旅行プラン「福岡花見ツアー」に対して、評価ユーザから「面白い」という評価内容がなされたことになる。

　画面１５１Ｂは、カテゴリ選択欄１５２Ａで、「渓流釣り」が選択された場合の、旅行プランの表示例であり、閲覧ユーザ「ＥＥ」により提示要求が行われた場合に、閲覧ユーザ「ＥＥ」の端末装置３００に表示される画面を示している。

　画面１５１Ｂは、旅行プラン表示欄１５６と、戻るボタン１５７とが表示されている。旅行プラン表示欄１５６では、画面１５１Ａの旅行プラン表示欄１５４に表示された旅行プランから、カテゴリ「渓流釣り」に含まれる旅行プランが抽出され、表示されている。さらに、旅行プラン表示欄１５６では、旅行プラン名毎にマッチング点数１５８が表示されている。

　画面１５１Ｂの例では、マッチング点数が高い旅行プラン名から順に表示されていることがわかる。

　以上のように、本実施形態によれば、旅行プランの提示要求（表示要求）を行った閲覧ユーザの属性と、旅行プランを評価した評価ユーザの属性とに基づき、閲覧ユーザの関心が高いと推察される旅行プランから順に表示させる。したがって、本実施形態によれば、ユーザの属性に応じた旅行プランを表示させることができる。

　（第二の実施形態）
　以下に図面を参照して、第二の実施形態について説明する。第二の実施形態では、旅行プランの提示要求を受けた際に、旅行プランデータベースに格納された全ての旅行プランが提示候補となる点が、第一の実施形態と相違する。したがって、以下の第二の実施形態の説明では、第一の実施形態との相違点についてのみ説明し、第一の実施形態と同様の機能構成を有するものには、第一の実施形態の説明で用いた符号と同様の符号を付与し、その説明を省略する。

　本実施形態では、旅行プランをカテゴリに分類せず、ユーザ毎に１つの属性を付与するものとした。したがって、本実施形態では、旅行プランの提示要求を受け付けると、旅行プラン評価データベース２５０Ａに格納されている全ての旅行プラン評価情報について、マッチング点数の算出を行う。

　図１６は、第二の実施形態の表示制御システムのシステム構成を説明する図である。

　本実施形態の表示制御システム１００Ａは、表示制御サーバ２００Ａと、端末装置３００を有する。

　本実施形態の表示制御サーバ２００Ａは、旅行プランデータベース２１０Ａ、ユーザ属性データベース２３０Ａ、旅行プラン評価データベース２５０Ａを有する。また、本実施形態の表示制御サーバ２００Ａは、本実施形態の表示制御処理部２７０Ａを有する。表示制御処理部２７０Ａは、登録制御部２８０Ａ、表示制御部２９０Ａを有する。

　以下に本実施形態の旅行プランデータベース２１０Ａ、ユーザ属性データベース２３０Ａ、旅行プラン評価データベース２５０Ａについて説明する。

　図１７は、第二の実施形態の旅行プランデータベースの一例を示す図である。本実施形態の旅行プランデータベース２１０Ａは、情報の項目として、旅行プラン名と登録ユーザ名とを有する。旅行プランデータベース２１０Ａは、項目「カテゴリ名」を有していない点以外は、第一の実施形態と同様であるから、説明を省略する。

　図１８は、第二の実施形態のユーザ属性データベースの一例を示す図である。本実施形態のユーザ属性データベース２３０Ａは、情報の項目として、ユーザ名、属性、合計評価ポイントを有する。本実施形態のユーザ属性データベース２３０Ａは、項目「カテゴリ名」を有していない点以外は、第一の実施形態と同様であるから、説明を省略する。

　図１９は、第二の実施形態の旅行プラン評価データベースの一例を示す図である。本実施形態の旅行プラン評価データベース２５０Ａは、情報の項目として、旅行プラン名、評価ユーザ名、評価ユーザの属性、費用か内容、評価ポイントを有する。本実施形態の旅行プラン評価データベース２５０Ａは、項目「カテゴリ名」を有していない点以外は、第一の実施形態と同様であるから、説明を省略する。

　次に、図２０を参照し、本実施形態の表示制御サーバ２００Ａの機能について説明する。図２０は、第二の実施形態の表示制御サーバの機能構成を説明する図である。

　本実施形態の表示制御サーバ２００Ａは、表示制御処理部２７０Ａを有する。本実施形態の表示制御処理部２７０Ａは、登録制御部２８０Ａと表示制御部２９０Ａを有する。はじめに、登録制御部２８０Ａについて説明する。

　本実施形態の登録制御部２８０Ａは、入力受付部２８１、旅行プラン格納部２８３Ａ、データベース検索部２８４、評価ポイント加算部２８５、属性変更判定部２８６、評価情報生成部２８７Ａ、評価情報格納部２８８を有する。

　旅行プラン格納部２８３Ａは、入力受付部２８１が受け付けた旅行プラン名と、登録ユーザ名とを対応付けて、旅行プランデータベース２１０Ａに格納する。

　評価情報生成部２８７Ａは、旅行プラン名、評価ユーザ名、評価ユーザの属性、評価内容、評価ポイントを対応付けた旅行プラン評価情報を生成する。

　本実施形態の表示制御部２９０Ａは、入力受付部２９１、属性特定部２９２、マッチング点数算出部２９４、表示順決定部２９５、画面データ出力部２９６を有する。表示制御部２９０Ａの有する各部は、第一の実施形態と同様である。

　次に、図２１乃至図２３を参照し、本実施形態の表示制御処理部２７０Ａの処理を説明する。はじめに、図２１及び図２２を参照し、本実施形態の登録制御部２８０Ａの処理について説明する。

　図２１は、第二の実施形態の登録制御部による登録制御部の処理を説明する第一のフローチャートである。図２１では、登録制御部２８０Ａによる、旅行プランの登録の処理を説明する。

　本実施形態の登録制御部２８０Ａは、入力受付部２８１により、ユーザ名と、旅行プランの入力を受け付けた否かを判定する（ステップＳ２１０１）。

　続いて、登録制御部２８０Ａは、旅行プラン格納部２８３Ａにより、入力を受け付けたユーザ名を旅行プランの名称（旅行プラン名）と対応付けて旅行プラン情報とし、旅行プランデータベース２１０Ａへ格納し（ステップＳ２１０２）、処理を終了する。

　図２２は、第二の実施形態の登録制御部による処理を説明する第二のフローチャートである。図２２では、ユーザ属性データベース２３０Ａと旅行プラン評価データベース２５０Ａを更新する処理について説明する。

　図２２のステップＳ２２０１からステップＳ２２０３の処理は、図１２のステップＳ１２０１からステップＳ１２０３までの処理と同様であるから、説明を省略する。

　ステップＳ２２０３に続いて、登録制御部２８０Ａは、データベース検索部２８４により、評価対象とされた旅行プラン名で旅行プランデータベース２１０Ａを検索し、評価対象の旅行プランを登録した登録ユーザ名とを取得する（ステップＳ２２０４）。

　続いて登録制御部２８０Ａは、評価情報生成部２８７Ａにより、旅行プラン名、評価ユーザ名、評価ユーザの属性、評価内容、評価ポイントを対応付けた旅行プラン評価情報を生成する。そして、評価情報格納部２８８により、生成した旅行プラン評価情報を旅行プラン評価データベース２５０Ａへ格納する（ステップＳ２２０５）。この処理により、旅行プラン評価データベース２５０Ａの更新の処理が完了する。

　図２２のステップＳ２２０６からステップＳ２２０８までの処理は、図１２のステップＳ１２０６からステップＳ１２０８までの処理と同様であるから、説明を省略する。

　次に、図２３を参照し、本実施形態の表示制御部２９０Ａの処理について説明する。図２３は、第二の実施形態の表示制御部による処理を説明する第二のフローチャートである。

　図２３のステップＳ２３０１からステップＳ２３０４までの処理は、図１３のステップＳ１３０１からステップＳ１３０４までの処理と同様であるから、説明を省略する。

　ステップＳ２３０３又はステップＳ２３０４に続いて、表示制御部２９０Ａは、マッチング点数算出部２９４により、旅行プラン毎のマッチング点数を算出する（ステップＳ２３０５）。ステップＳ２３０５とステップＳ２３０６の処理は、図１３のステップＳ１３０６とステップＳ１３０７の処理と同様であるから、説明を省略する。

　以上の処理により、本実施形態では、旅行プランのカテゴリに関係なく、提示要求を行ったユーザの関心が高そうな旅行プランを表示させることができる。

　（第三の実施形態）
　以下に図面を参照して第三の実施形態について説明する。第三の実施形態では、特定の属性のユーザに対し、ログイン後に外部のサーバから取得した旅行プラン名を表示させる点が、第一及び第二の実施形態と相違する。したがって、以下の第三の実施形態の説明では、第一及び第二の実施形態との相違点についてのみ説明し、第一及び第二の実施形態と同様の機能構成を有するものには、第一及び第二の実施形態の説明で用いた符号と同様の符号を付与し、その説明を省略する。

　図２４は、第三の実施形態の表示制御システムのシステム構成を説明する図である。

　本実施形態の表示制御システム１００Ｂは、表示制御サーバ２００Ｂと、端末装置３００を有する。また、本実施形態の表示制御サーバ２００Ｂは、外部のサーバ４００と通信を行う。

　本実施形態の表示制御サーバ２００Ｂは、第一の実施形態の表示制御サーバ２００の有する各データベースに加え、ユーザ属性データベース２３０Ａを有する。また、本実施形態の表示制御サーバ２００Ｂは、表示制御処理部２７０Ｂを有する。表示制御処理部２７０Ｂは、登録制御部２８０と、表示制御部２９０Ｂを有する。

　本実施形態において、サーバ４００は、例えば旅行会社等により提供される旅行プランに関する情報が格納されたサーバ等である。本実施形態では、旅行プランの提示要求を行ったユーザの属性が、例えば「マニア」や「フリーク」等、旅行に対する関心が高いことを示す属性であった場合、ログイン後の画面に、このユーザが特に関心を持っていると思われるカテゴリをサーバ４００へ通知する。そして、表示制御サーバ２００Ｂは、サーバ４００から、通知したカテゴリにおいて推奨される旅行プランを取得し、端末装置３００に表示させても良い。

　言い換えれば、本実施形態では、旅行が好きなユーザのユーザ名と、このユーザが関心を持っているカテゴリとを旅行会社のサーバ４００へ通知し、このカテゴリにおいて旅行会社が推奨する旅行プランを取得してユーザに提示する。

　以下に、図２５を参照し、本実施形態の表示制御サーバ２００Ｂの機能について説明する。図２５は、第三の実施形態の表示制御サーバの機能構成を説明する図である。

　本実施形態の表示制御サーバ２００Ｂは、表示制御処理部２７０Ｂを有する。本実施形態の表示制御処理部２７０Ｂは、表示制御部２９０Ｂを有する。

　本実施形態の表示制御部２９０Ｂは、第一の実施形態の表示制御部２９０の有する各部に加え、属性提供部３０１、旅行プラン取得部３０２を有する。

　本実施形態の属性提供部３０１は、ログインされたユーザの属性が特定の属性であった場合に、ユーザに関する情報をサーバ４００へ出力する。本実施形態において、サーバ４００に提供される、ユーザに関する情報とは、ユーザ名と、このユーザが関心を持っているカテゴリとを含む。

　旅行プラン取得部３０２は、サーバ４００から、端末装置３００に表示させる旅行プラン名を取得する。

　次に、図２６を参照して、本実施形態の表示制御部２９０Ｂの処理について説明する。図２６は、第三の実施形態の表示制御部の処理を説明するフローチャートである。図２６では、表示制御処理部２７０Ｂを実現する表示制御プログラムの起動要求を受けたときの表示制御部２９０Ｂの処理を示している。

　本実施形態の表示制御処理部２７０Ｂは、起動要求を受け付けたか否かを判定する（ステップＳ２６０１）。ステップＳ２６０１において、起動要求を受け付けない場合、表示制御処理部２７０Ｂは、起動要求を受け付けるまで待機する。

　ステップＳ２６０１において、起動要求を受け付けた場合、表示制御部２９０Ｂは、属性特定部２９２により、ログインしたユーザの属性を特定する（ステップＳ２６０２）。具体的には、属性特定部２９２は、ユーザ属性データベース２３０Ａを参照し、ログインしたユーザのユーザ名と対応付けられた属性を特定する。尚、ユーザ属性データベース２３０Ａに該当するユーザ名が存在しない場合、表示制御部２９０Ｂは、ログインしたユーザの属性を一般としてステップＳ２６０３へ進んでも良いし、ステップＳ２６０８に進んでも良い。

　続いて、表示制御部２９０Ｂは、属性提供部３０１により、特定した属性が「フリーク」以上であるか否かを判定する（ステップＳ２６０３）。ステップＳ２６０３において、特定した属性が「フリーク」未満である場合、表示制御部２９０Ｂは、後述するステップＳ２７０８へ進む。

　ステップＳ２６０３において、特定した属性が「フリーク」又は「マニア」であった場合、属性提供部３０１は、ユーザ属性データベース２３０において、このユーザと対応する属性のうち、「フリーク」以上のカテゴリを特定する（ステップＳ２６０４）。

　続いて、属性提供部３０１は、ログインしたユーザのユーザ名と、属性が「フリーク」以上のカテゴリの名称（カテゴリ名）と、このカテゴリの属性とをサーバ４００へ送信する（ステップＳ２６０５）。

　続いて、表示制御部２９０Ｂは、旅行プラン取得部３０２により、サーバ４００からカテゴリに対応した旅行プラン名を取得する（ステップＳ２６０６）。ここで取得される旅行プラン名は、サーバ４００において、旅行会社等により推奨される旅行プランの名称である。

　続いて、表示制御部２９０Ｂは、画面データ出力部２９６により、取得した旅行プラン名を端末装置３００に表示させ（ステップＳ２６０７）、処理を終了する。

　尚、ステップＳ２６０３において、特定した属性が「フリーク」未満の「ファン」又は「一般」である場合、表示制御部２９０Ｂは、旅行プランデータベース２１０を参照し、登録の日付が新しい順に旅行プランを取得して端末装置３００に表示させ、（ステップＳ２６０８）、処理を終了する。

　図２７は、第三の実施形態において端末装置に表示される画面の例を示す図である。図２７に示す画面２７１は、例えばユーザ名「ＡＡ」のユーザがログインした際に、端末装置３００に表示される画面の例を示している。

　画面２７１は、メッセージ表示欄２７２、カテゴリ表示欄２７３、旅行プラン表示欄２７４、検索画面ボタン２７５を有する。

　メッセージ表示欄２７２には、表示された旅行プランがユーザに対して推奨される旅行プランであることを示すメッセージが表示される。カテゴリ表示欄２７３は、表示された旅行プランのカテゴリ名が表示される。旅行プラン表示欄２７４には、サーバ４００から取得した旅行プラン名が表示される。

　ユーザ属性データベース２３０Ａにおいて、ユーザ名「ＡＡ」の属性は「マニア」であり、「フリーク」以上である（図１８参照）。

　したがって、表示制御部２９０Ｂは、ユーザ属性データベース２３０を参照し、ユーザ名「ＡＡ」と対応する属性が「フリーク」以上であるカテゴリ名を特定する。ユーザ属性データベース２３０において、ユーザ名「ＡＡ」と対応する属性には、「ファン」と「マニア」がある。よって、属性提供部３０１は、属性が「マニア」のカテゴリ名「渓流釣り」を特定し、ユーザ名「ＡＡ」と、カテゴリ名「渓流釣り」と、属性「マニア」と、をサーバ４００へ送信する。

　サーバ４００は、サーバ４００の有する旅行プランデータベースにおいて、カテゴリ名「渓流釣り」に分類された旅行プランの中から、属性「マニア」に対して推奨される旅行プランを抽出し、表示制御サーバ２００Ｂへ送信する。尚、属性「マニア」に対して推奨される旅行プランは、例えばサーバ４００において、予め用意されていても良い。

　表示制御サーバ２００Ｂは、旅行プラン取得部３０２により、サーバ４００から送信された旅行プランを取得し、端末装置３００に表示させる。

　したがって、画面２７１において、メッセージ表示欄２７２には、「「ＡＡ」さんにお勧めの旅行プラン」というメッセージが表示され、カテゴリ表示欄２７３には、カテゴリ名「渓流釣りツアー」が表示される。

　また、旅行プラン表示欄２７４には、サーバ４００から取得した旅行プラン「アウトドアフィッシング」、「解禁直後ツアー」等が表示される。

　また、画面２７１では、検索画面ボタン２７５が操作されると、通常のログイン後に表示される画面１５１Ａに遷移しても良い。

　以上のように、本実施形態によれば、表示制御システム１００Ｂにおいて付与されたユーザの属性と、ユーザのカテゴリ毎の属性とを外部のサーバ４００へ提供することで、旅行プランデータベース２１０に登録された旅行プラン以外の旅行プランの提示を受けることができる。

　また、本実施形態では、ユーザの属性と、ユーザのカテゴリ毎の属性とを外部のサーバ４００へ提供するものとしたが、これに限定されない。表示制御サーバ２００Ｂは、例えはユーザの属性のみをサーバ４００へ提供しても良い。つまり、表示制御サーバ２００Ｂは、ユーザの旅行に対する関心の高さを示す情報を外部のサーバ４００に提供しても良い。

　この場合、サーバ４００は、関心の高さに応じて旅行プランを表示制御サーバ２００Ｂに送信し、表示制御サーバ２００Ｂは、この旅行プランを端末装置３００に表示させても良い。

　（変形例）
　上述した各実施形態では、閲覧ユーザの属性と、提示候補の旅行プランを評価した評価ユーザの属性とに基づいて、閲覧ユーザの端末装置３００へ表示させる旅行プランの表示順を決定したが、以下の例では、閲覧ユーザの属性と、提示候補の旅行プランを登録した登録ユーザの属性とに基づいて、閲覧ユーザの端末装置３００へ旅行プランを表示させても良い。

　図２８は、閲覧ユーザの属性と登録ユーザの属性とに基づく旅行プランの表示の処理を説明するフローチャートである。

　図２８のステップＳ２８０１からステップＳ２８０５までの処理は、図１３のステップＳ１３０１からステップＳ１３０５までの処理と同様であるから、説明を省略する。

　ステップＳ２８０３又はステップＳ２８０４に続いて、表示制御部２９０は、抽出された旅行プラン評価情報に含まれる旅行プラン名のうち、閲覧ユーザと属性が一致する登録ユーザにより登録された旅行プランの旅行プラン名を特定する（ステップＳ２８０６）。

　具体的には、表示制御部２９０は、例えば、抽出された旅行プラン評価情報に含まれる旅行プラン名毎に、旅行プランデータベース２１０を検索し、対応付けられた登録ユーザ名を取得する。そして、表示制御部２９０は、取得したユーザ名で、ユーザ属性データベース２３０を検索すれば、旅行プラン名の登録ユーザの属性を特定することができる。よって、表示制御部２９０は、抽出された旅行プラン評価情報に含まれる旅行プラン名のうち、閲覧ユーザと属性が一致する登録ユーザにより登録された旅行プラン名を特定できる。

　続いて、表示制御部２９０は、ステップＳ２８０６で特定された旅行プラン名から順に、端末装置３００に表示させる旅行プラン名の表示順を決定する（ステップＳ２８０７）。

　具体的には、表示制御部２９０は、閲覧ユーザと属性が近い登録ユーザにより登録された旅行プラン名から順に表示させる。したがって、この場合には、ステップＳ２８０６で特定された旅行プラン名が最上位となる。次に、登録ユーザの属性が、閲覧ユーザの属性と１段階離れたている旅行プラン名が表示されることになる。

　続いて、表示制御部２９０は、ステップＳ２８０７で決定した表示順に旅行プラン名を表示させる画面データを生成して端末装置３００へ出力し（ステップＳ２８０８）、処理を終了する。

　この例では、閲覧ユーザの属性と、属性が一致するユーザにより登録された旅行プラン名から順に端末装置３００に表示させるため、ユーザの属性に応じた旅行プランを表示させることができる。

　本発明は、具体的に開示された実施形態に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。

　１００、１００Ａ、１００Ｂ　表示制御システム
　２００、２００Ａ、２００Ｂ　表示制御サーバ
　２１０、２１０Ａ　旅行プランデータベース
　２２０　評価ポイントデータベース
　２３０、２３０Ａ　ユーザ属性データベース
　２４０　属性データベース
　２５０、２５０Ａ　旅行プラン評価データベース
　２６０　重み付けデータベース
　２７０、２７０Ａ、２７０Ｂ　表示制御処理部
　２８０、２８０Ａ　登録制御部
　２８２　カテゴリ付与部
　２８３、２８３Ａ　旅行プラン格納部
　２８５　評価ポイント加算部
　２８７、２８７Ａ　評価情報生成部
　２８８　評価情報格納部
　２９０、２９０Ａ、２９０Ｂ　表示制御部
　２９２　属性特定部
　２９３　評価情報抽出部
　２９４　マッチング点数算出部
　２９５　表示順決定部
　２９６　画面データ出力部
　２９７　重み付け部
　２９９　点数合算部
　３００　端末装置
　３０１　属性提供部
　３０２　旅行プラン取得部
　４００　サーバ

Claims (10)

1. 　特定のユーザアカウントに対応づけた旅行プランの登録を受け付け、
   　登録された前記旅行プランに対する評価の入力を受け付け、
   　前記評価の入力に応じて、前記特定のユーザアカウントについて属性を特定し、
   　特定した前記属性に応じて、前記特定のユーザアカウントについて提供する旅行プランの表示を制御する、
   　処理をコンピュータに実行させることを特徴とする表示制御プログラム。
2. 　前記表示を制御する処理は、特定した前記属性に基づいて、登録された複数の前記旅行プランの表示順を決定し、表示させる、
   　ことを特徴とする請求項１記載の表示制御プログラム。
3. 　前記表示を制御する処理は、前記表示順において、前記特定のユーザアカウントの属性と同一の属性の他のユーザアカウントにより評価された旅行プランを上位にする、ことを特徴とする請求項２に記載の表示制御プログラム。
4. 　前記表示を制御する処理は、前記表示順において、前記特定のユーザアカウントの属性と同一の属性の他のユーザアカウントと対応づいた旅行プランを上位にする、ことを特徴とする請求項２又は３に記載の表示制御プログラム。
5. 　前記属性は、前記旅行プランに対する評価に応じた複数の段階を有し、
   　前記特定のユーザアカウントの属性と、前記他のユーザアカウントの属性との差が小さいほど、前記他のユーザアカウントにより入力された評価の重みを大きくし、
   　前記差が大きいほど、前記他のユーザアカウントにより入力された評価の重みを小さくする、ことを特徴とする請求項３又は４記載の表示制御プログラム。
6. 　前記表示を制御する処理は、ユーザアカウントと、前記旅行プランの分類を示すカテゴリ名との入力を受け付け、
   　前記カテゴリ名と対応付けられた旅行プランを抽出し、
   　前記旅行プラン毎に、旅行プランの評価と対応付いたユーザアカウントの属性と、入力された前記ユーザアカウントの属性との差に対応する重みから、前記ユーザアカウントについて、前記旅行プランに対する関心の高さを示す指標値を算出し、
   　前記指標値が大きい順に、提供する旅行プランを表示させる、ことを特徴とする請求項５記載の表示制御プログラム。
7. 　前記特定のユーザアカウントにより前記旅行プランの登録を受け付けていない場合、前記特定のユーザアカウントの属性を所定の属性とする、ことを特徴とする請求項１乃至６の何れか一項に記載の表示制御プログラム。
8. 　特定のユーザアカウントに対応づけた旅行プランの登録を受け付ける登録部と、
   　登録された前記旅行プランに対する評価の入力を受け付ける受付部と、
   　前記評価の入力に応じて、前記特定のユーザアカウントについて属性を特定する特定部と、
   　特定した前記属性に応じて、前記特定のユーザアカウントについて提供する旅行プランの表示を制御する表示制御部と、
   　を有することを特徴とする表示制御装置。
9. 　コンピュータによる表示制御方法であって、該コンピュータが、特定のユーザアカウントに対応づけた旅行プランの登録を受け付け、
   　登録された前記旅行プランに対する評価の入力を受け付け、
   　前記評価の入力に応じて、前記特定のユーザアカウントについて属性を特定し、
   　特定した前記属性に応じて、前記特定のユーザアカウントについて提供する旅行プランの表示を制御する、ことを特徴とする表示制御方法。
10. 　旅行プランの登録を受け付け、
    　登録された前記旅行プランに対する評価の入力を受け付け、
    　前記旅行プランの表示要求を受けて、前記表示要求と対応付いた第１のユーザアカウントの属性を特定し、
    　特定した前記属性と、前記評価と対応付いた第２のユーザアカウントの属性とに応じて、旅行プランの表示を制御する、
    　処理をコンピュータに実行させることを特徴とする表示制御プログラム。

Images