[1.実施形態1]
以下、本発明に係る検索システムの実施形態の例を説明する。
[1−1.検索システムの全体構成]
図1は、検索システムの全体構成を示す図である。図1に示すように、検索システムSは、ユーザ端末10とサーバ20とを含み、これらは、インターネットなどのネットワークNに接続可能である。なお、図1ではユーザ端末10とサーバ20とを1台ずつ示しているが、これらは複数台あってよい。
ユーザ端末10は、ユーザが操作するコンピュータである。例えば、ユーザ端末10は、携帯電話機(スマートフォンを含む)、携帯情報端末(タブレット型コンピュータを含む)、又は、パーソナルコンピュータ等である。本実施形態では、ユーザ端末10は、制御部11、記憶部12、通信部13、操作部14、及び表示部15を含む。
制御部11は、少なくとも一つのマイクロプロセッサを含む。制御部11は、記憶部12に記憶されたプログラムやデータに従って処理を実行する。記憶部12は、主記憶部及び補助記憶部を含む。例えば、主記憶部はRAMなどの揮発性メモリであり、補助記憶部は、ROM、EEPROM、フラッシュメモリ、又はハードディスクなどの不揮発性メモリである。
通信部13は、有線通信又は無線通信用の通信インタフェースであり、ネットワークを介してデータ通信を行う。操作部14は、ユーザが操作を行うための入力デバイスであり、例えば、タッチパネルやマウス等のポインティングデバイス、キーボード、又はボタン等である。操作部14は、ユーザによる操作内容を制御部11に伝達する。表示部15は、例えば、液晶表示部又は有機EL表示部等である。表示部15は、制御部11の指示に従って画像を表示する。
サーバ20は、サーバコンピュータである。サーバ20は、制御部21、記憶部22、及び通信部23を含む。制御部21、記憶部22、及び通信部23の物理的構成は、それぞれ制御部11、記憶部12、及び通信部13と同様であってよい。
なお、記憶部12,22に記憶されるものとして説明するプログラム及びデータは、ネットワークNを介して供給されるようにしてもよい。また、上記説明した各コンピュータのハードウェア構成は、上記の例に限られず、種々のハードウェアを適用可能である。例えば、コンピュータ読み取り可能な情報記憶媒体を読み取る読取部(例えば、光ディスクドライブやメモリカードスロット)や外部機器とデータの入出力をするための入出力部(例えば、USBポート)が含まれていてもよい。例えば、情報記憶媒体に記憶されたプログラムやデータが読取部や入出力部を介して、各コンピュータに供給されるようにしてもよい。
[1−2.実施形態1の概要]
本実施形態では、検索システムSを旅行予約サービスに適用する場合を一例として説明する。旅行予約サービスは、ユーザの旅行予約を支援するサービスであり、本実施形態では、宿泊施設、航空券、レンタカー、及びバスといった予約を総合的に支援する旅行予約サービスを一例として説明する。
なお、本実施形態では、宿泊施設の一例としてホテルを説明するが、宿泊施設は、ホテルに限られず、旅館、民泊施設、又はゲストハウスであってもよい。また、旅行予約サービスの内容は、本実施形態の例に限られず、他にも例えば、列車、レストラン、又はオプションツアーといった予約を支援してもよいし、ホテルや航空券等がセットになったパッケージツアーの予約を支援してもよい。また、複数の予約を総合的に支援する場合に限られず、何れか1つだけの予約を支援するサービスであってもよい。例えば、ホテルの予約だけをしたり航空券の予約だけをしたりする場合にも、実施形態に係る処理を適用可能である。
また、検索システムSは、旅行予約以外の任意の場面に適用可能であり、例えば、電子商取引、チケット販売、又はイベント予約といった種々の場面にも適用可能である。他の場面での適用例については、後述する変形例で説明する。
例えば、ユーザがユーザ端末10を操作して、サーバ20にアクセスすると、旅行予約サービスのトップ画面が表示部15に表示される。なお、以降説明する画面は、ユーザ端末10に記憶された旅行予約のアプリケーションの画面として表示されてもよいし、ウェブブラウザの画面として示されてもよい。
図2は、トップ画面の一例を示す図である。図2に示すように、例えば、トップ画面G1には、検索条件を入力するための入力フォームF10〜F13と、検索を実行するためのボタンB14と、が表示される。また例えば、トップ画面G1は、ユーザが最近閲覧したホテル等を表示するための表示領域A15と、おすすめのホテル等を表示するための表示領域A16と、を含む。
図2に示すように、トップ画面G1は、ホテル予約、航空券予約、レンタカー予約、及びバス予約の各々の検索条件を入力可能となっている。検索条件は、検索で用いられるクエリであり、任意の条件を入力可能である。検索条件は、キーワードであってもよいし、予め定められた複数の数値(例えば、日付、時間、人数、予算等)の中から選択された数値であってもよいし、カテゴリのような属性情報であってもよい。
例えば、ホテル予約であれば、宿泊地、利用日(宿泊日)、利用人数、及び宿泊費といった検索条件が入力される。また例えば、航空券予約であれば、出発地、目的地、出発日、出発時間、到着日、到着時間、航空会社、及び運賃といった検索条件が入力される。また例えば、レンタカー予約であれば、出発場所、返却場所、利用日、利用時間、車種、及びレンタル料といった検索条件が入力される。また例えば、バス予約であれば、出発地、目的地、出発日、出発時間、到着日、到着時間、バス会社、及び運賃といった検索条件が入力される。
本実施形態では、説明の簡略化のために、ユーザがホテル予約をする場合の処理を説明する。例えば、ユーザは、入力フォームF10に、宿泊地などのキーワードを入力する。宿泊地は、キーワードで入力されなくてもよく、予め用意された地域リストの中から選択されるようにしてもよい。また例えば、入力フォームF11には、チェックイン日が入力され、入力フォームF12には、チェックアウト日が入力される。また例えば、入力フォームF13には、利用人数が入力される。ユーザが、これらの検索条件を入力してボタンB14を選択すると、検索が実行される。
図3は、検索が実行される様子を示す図である。図3のトップ画面G1A,G1Bに示すように、例えば、ユーザが、入力フォームF10〜F13に検索条件を入力し、ボタンB14を選択すると、検索条件を満たすホテルが検索される。図3のトップ画面G1Bの例であれば、入力フォームF10に入力された「東京」にあるホテルのうち、入力フォームF11,F12に入力された「2018年4月1日」〜「2018年4月3日」の利用日において、入力フォームF13に入力された「2人」用の部屋に空きがあるホテルが検索される。
図3に示すように、ホテルが検索されると、検索結果を示す検索結果画面G2が表示部15に表示される。例えば、検索結果画面G2の入力フォームF20には、検索で用いられた検索条件が表示される。ユーザは、所望のホテルが見つからなかった場合には、入力フォームF20から検索条件を変更し、再度検索を実行する。
また例えば、検索結果画面G2のリストL21には、検索でヒットしたホテルが表示される。リストL21では、検索でヒットしたホテルが選択可能に表示され、リストL21をスクロールしたり、所定のページ送り操作をしたりすることで、画面に表示しきれないホテルを表示させることもできる。例えば、リストL21には、検索でヒットしたホテルの名称、画像(図3では省略する)、ユーザの評価、及び価格帯といった情報が表示される。
図3に示すように、ユーザがリストL21に表示されたホテルを選択すると、当該ホテルの詳細を示すページであるホテル画面G3が表示部15に表示される。図3では、ユーザがリストL21内の「ホテルA」を選択し、「ホテルA」のページを示すホテル画面G3が表示部15に表示される場合を示している。例えば、ホテル画面G3には、「ホテルA」の名前、評価、画像、部屋の名前、料金、及び部屋を予約するためのボタンB30が表示される。
例えば、ユーザがボタンB30を選択した場合、当該ボタンB30に対応する部屋の予約画面に遷移し、その後、食事やエステなどのオプション情報が選択されたり、宿泊者情報が入力されたりした後に、予約が完了する。なお、利用日や利用人数は、検索条件で入力された値でそのまま予約が行われてもよいし、検索条件で入力された利用日や利用人数が変更されたうえで、予約が行われてもよい。
なお、図3のリストL21内の「ホテルB」又は「ホテルC」をユーザが選択した場合も同様に、選択された「ホテルB」又は「ホテルC」のページを示すホテル画面G3が表示部15に表示される。例えば、ユーザは、検索結果画面G2とホテル画面G3を行き来したり、検索結果画面G2から検索条件を変えて検索をやり直したりしながら、所望のホテルが見つかるまで検索を繰り返す。
本実施形態では、トップ画面G1の表示領域A15には、ユーザがホテル画面G3を表示させたホテルが閲覧履歴(最近見たページ)として表示される。例えば、図3のようにして、ユーザが複数のホテルを見比べた後にトップ画面G1に戻ると、これらのホテルが閲覧履歴として表示領域A15に表示される。
図4は、トップ画面G1に閲覧履歴が表示される様子を示す図である。図4の例は、ユーザが「ホテルA」、「ホテルB」、「ホテルC」、「ホテルD」、及び「ホテルE」の各々を順番に閲覧した場合を示している。なお、以降では、ユーザが閲覧したホテルを、閲覧済みホテルと記載する。
図4に示すように、表示領域A15には、これら閲覧済みホテルをそれぞれ示す画像G150A〜G150Eが閲覧順に並ぶようにして表示される。例えば、表示領域A15では、直近の閲覧済みホテルは左上に表示され、右方向又は下方向に向けて時系列順となるように、他の閲覧済みホテルが並ぶ。このため、図4の例では、直近で閲覧された「ホテルE」の画像G150Eが最も左上に配置され、「ホテルD」、「ホテルC」、「ホテルB」、及び「ホテルA」の画像G150D〜G150Aが順番に並ぶ。なお、以降では、画像G150A〜G150Eを特に区別する必要のないときは、単に画像G150と記載する。
例えば、画像G150は、ホテル名を含み、閲覧済みホテルの外観や内観の写真を含んでもよい。他にも例えば、画像G150には、閲覧済みホテルの場所、価格帯、ユーザの評価といった情報が表示されてもよい。ユーザが何れかの画像G150を選択すると、当該画像G150が示す閲覧済みホテルのホテル画面G3が表示部15に表示される。この場合、ユーザが選択した画像G150が示すホテルが、直近の閲覧済みホテルとなるので、その後にトップ画面G1に戻ると、画像G150の配置も更新される。なお、ユーザが直近で閲覧した「ホテルE」の画像G150Eを選択した場合には、各ホテルの閲覧順序は変わらないので、画像G150の配置も変わらない。
本実施形態では、閲覧済みホテルに対し、当該ホテルの検索で用いられた検索条件が関連付けられるようになっている。図3の検索例であれば、「ホテルA」、「ホテルB」、「ホテルC」、「ホテルD」、及び「ホテルE」の各々に対し、宿泊地が「東京」であり、利用日が「2018年4月1日」〜「2018年4月3日」であり、かつ、利用人数が「2人」といった検索条件(トップ画面G1Bで入力された検索条件)が関連付けられることになる。なお、閲覧済みホテルに関連付けられた検索条件は、画像G150に表示されてもよい。即ち、画像G150において、閲覧済みホテルが、どのような検索条件で検索したのかを特定できるようにしてもよい。
また、本実施形態では、表示領域A15において、閲覧済みホテルに関連付けられた検索条件での空き状況に関する情報が、当該ホテルとともに表示されるようになっている。図4の例であれば、利用日が「2018年4月1日」〜「2018年4月3日」であり、かつ、利用人数が「2人」である場合の残室の有無に関する情報が、表示領域A15において表示される
図5は、表示領域A15に空き状況が表示される様子を示す図である。図5のトップ画面G1Cに示すように、どの閲覧済みホテルも検索時の検索条件で空きがある場合には、表示領域A15には、各ホテルの画像G150がそのまま表示される。この状態から、例えば、「ホテルD」の残室がなくなったとすると、トップ画面G1Dに示すように、「ホテルD」の画像G150D上に、「SOLD OUT」といったメッセージM151Dが表示され、検索時の検索条件では空きがないことが通知される。なお、メッセージM151Dには、検索時の検索条件が表示されてもよく、例えば、検索時に入力された利用日や利用人数が表示されてもよい。
続いて、「ホテルA」の残室もなくなったとすると、トップ画面G1Eに示すように、「ホテルA」の画像G150A上に、「SOLD OUT」のメッセージM151Aが表示され、検索時の検索条件では空きがないことが通知される。その後、「ホテルD」にキャンセルが発生して空きが出ると、トップ画面G1Fに示すように、「ホテルD」の画像G150D上のメッセージM151Dが消去されて元の表示に戻り、検索時の検索条件で「ホテルD」に残室があることが通知される。
なお、以降では、メッセージM151A,B151Dを区別する必要のないときは、単にメッセージM151と記載する。また、「ホテルB」、「ホテルC」、及び「ホテルE」についても同様に、検索時の検索条件で空きがなくなるとメッセージM151が表示され、その後に空きが発生すると当該メッセージM151が消去される。閲覧済みホテルの在庫判定は、トップ画面G1が表示される場合にのみ実行されてもよいし、トップ画面G1の表示中に定期的に実行され、表示領域A15の表示が定期的に更新されるようにしてもよい。
以上のように、本実施形態の検索システムSでは、トップ画面G1の表示領域A15に、閲覧済みホテルの一覧を表示させ、検索時の検索条件で空きがない場合にメッセージM151を表示させることで、空きがないにも関わらず画像G150を選択するといったことを防止し、ユーザインタフェースの利便性を高めるようになっている。以降、この技術の詳細を説明する。
[1−3.実施形態1において実現される機能]
図6は、実施形態1の検索システムSで実現される機能の一例を示す機能ブロック図である。なお、本実施形態では、表示制御に関する主な機能がサーバ20で実現される場合を説明するが、後述する変形例のように、主な機能がユーザ端末10で実現されるようにしてもよいし、ユーザ端末10とサーバ20との間で機能が分担されてもよい。
[1−3−1.サーバで実現される機能]
図6に示すように、サーバ20では、データ記憶部200、検索部201、閲覧部202、関連付け部203、及び表示制御部204が実現される。データ記憶部200、検索部201、閲覧部202、関連付け部203、及び表示制御部204は、それぞれ記憶手段、検索手段、閲覧手段、関連付け手段、及び表示制御手段の一例である。
[データ記憶部]
データ記憶部200は、記憶部22を主として実現される。データ記憶部200は、検索や表示制御に必要なデータを記憶する。ここでは、データ記憶部200が記憶するデータの一例として、アイテムデータベースDB1、在庫データベースDB2、及び閲覧履歴データベースDB3を説明する。
図7は、アイテムデータベースDB1のデータ格納例を示す図である。アイテムデータベースDB1は、サブアイテムごとに在庫情報があるアイテムに関する各種情報を格納するデータベースである。
アイテムは、検索対象となる情報であり、例えば、ユーザが予約するサービスであってもよいし、ユーザが購入する商品であってもよい。別の言い方をすれば、アイテムは、データアイテムと呼ばれることもあり、検索対象となるデータベース内の個々のレコードということもできる。このため、アイテムは、ユーザが予約するサービスに関する情報、又は、ユーザが購入する商品に関する情報ということもできる。
例えば、ホテル予約であれば、アイテムは、ホテル又は部屋である。航空機予約であれば、アイテムは、航空機又は座席である。レンタカー予約であれば、アイテムは、レンタルする車である。バス予約であれば、アイテムは、バス又は座席である。列車予約であれば、アイテムは、列車又は座席である。レストラン予約であれば、アイテムは、レストラン、座席、又はテーブルである。オプションツアー予約であれば、アイテムは、オプションツアーである。
サブアイテムは、アイテムに関連付けられた情報であり、例えば、ユーザが予約するサービスの内容(条件)であってもよいし、ユーザが購入する商品の内容(条件)であってもよい。サブアイテムは、アイテム同様にデータアイテムと呼ばれることもあるが、アイテムの下位概念に相当するデータアイテムである。例えば、サブアイテムは、アイテムを検索するためのインデックスであり、検索条件(検索クエリ)と比較される情報である。例えば、各アイテムのサブアイテムは、当該アイテムに係る利用日であってもよく、この場合には、検索条件は、利用日に関する条件を含んでもよい。アイテムには、少なくとも1つのサブアイテムが関連付けられている。
例えば、ホテル予約であれば、サブアイテムは、ホテルの場所、利用日、又は利用人数である。航空機予約であれば、サブアイテムは、出発地、目的地、出発日、出発時間、到着日、又は到着時間である。レンタカー予約であれば、サブアイテムは、店舗の場所、利用日、利用時間、乗車可能人数、又は車種である。バス予約であれば、サブアイテムは、出発地、目的地、出発日、又は出発時間である。列車予約であれば、サブアイテムは、出発地、目的地、出発日、出発時間、到着日、又は到着時間である。レストラン予約であれば、サブアイテムは、レストランの場所、利用日、食事ジャンル、又はメニューである。オプションツアー予約であれば、サブアイテムは、ツアーが行われる場所、利用日、又はツアー内容である。
在庫情報は、サブアイテムの在庫数を示す情報である。在庫数は、アイテムの残数であり、利用可能数又は購入可能数ということもできる。例えば、在庫情報は、サブアイテムに関連付けられている。また例えば、サブアイテムごとに、在庫情報が存在する。なお、全てのサブアイテムに対し、在庫情報が関連付ける必要はなく、少なくとも1つのサブアイテムに在庫情報が関連付けられていればよい。
例えば、ホテル予約であれば、在庫情報は、ホテル内の部屋の残室数を示す。航空機予約であれば、在庫情報は、航空機内の座席の残席数を示す。レンタカー予約であれば、在庫情報は、車の残台数を示す。バス予約であれば、在庫情報は、バス内の座席の残席数を示す。列車予約であれば、在庫情報は、列車内の座席の残席数を示す。レストラン予約であれば、在庫情報は、レストラン内のテーブル又は座席の残数を示す。オプションツアー予約であれば、在庫情報は、予約可能な残り人数を示す。
本実施形態では、説明の簡略化のために、ホテルがアイテムに相当し、利用日がサブアイテムに相当する場合を一例として説明する。このため、本実施形態でホテルと記載した箇所は、アイテムと読み替えることができ、利用日と記載した箇所は、サブアイテムと読み替えることができる。在庫情報は、各部屋の利用日ごとの残室数を示すことになる。
図7に示すように、アイテムデータベースDB1には、ホテルに関するデータが格納され、例えば、ホテルを一意に識別するホテルID、ホテル情報、及び部屋情報が格納される。
ホテル情報は、ホテルの基本情報であり、例えば、ホテルの名前、住所、連絡先、建物の画像、敷地内の施設、設備、及び価格帯などが格納される。部屋情報は、ホテル内の各部屋の基本情報であり、例えば、部屋を一意に識別する部屋ID、部屋の名前、利用可能人数、部屋のタイプ、間取り、広さ、バス・トイレの有無、及び部屋の紹介文などが格納される。
ホテル情報と部屋情報は、検索時のインデックスとして用いられるようにしてよい。例えば、宿泊地の場所がクエリとして入力された場合には、ホテル情報の住所がインデックスとなる。また例えば、利用人数がクエリとして入力された場合には、部屋情報の利用可能人数がインデックスとなる。
なお、本実施形態では、ホテル検索を例に挙げるので、図7において、アイテムデータベースDB1に、ホテルに関するデータだけを図示したが、アイテムデータベースDB1には、航空券、レンタカー、又はバスに関するデータが格納されていてもよい。この場合、ホテル、航空券、レンタカー、又はバスといった各データの種類(各サービスの提供者)を識別するためのIDによって、個々のデータがどの種類のものであるかを識別可能としてもよい。
図8は、在庫データベースDB2のデータ格納例を示す図である。図8に示すように、在庫データベースDB2は、利用日ごとに在庫情報を格納するデータベースである。例えば、在庫データベースDB2には、ホテルID、部屋ID、利用日、及び在庫情報が格納される。例えば、ホテルの中には、複数のタイプの部屋が存在し、かつ、同じタイプの部屋が複数存在するので、在庫データベースDB2には、ホテルの部屋のタイプごとに、利用日と在庫情報との組み合わせが格納されている。在庫データベースDB2の利用日は、検索時のインデックスとして用いられる。例えば、検索条件に入力されたチェックイン日からチェックアウトの前日までの在庫情報が参照されるようにしてよい。
図9は、閲覧履歴データベースDB3のデータ格納例を示す図である。図9に示すように、閲覧履歴データベースDB3は、ユーザの閲覧履歴を格納するデータベースである。例えば、閲覧履歴データベースDB3には、ユーザを一意に識別するユーザID、閲覧順序、閲覧したホテルのホテルID、検索で用いられた検索条件、及び閲覧時間が格納される。閲覧履歴データベースDB3は、後述する関連付け部203によって更新される。
なお、データ記憶部200に記憶されるデータは、上記の例に限られない。例えば、データ記憶部200は、図2−図5に示す各画面を表示させるための画像データを記憶してもよい。また例えば、データ記憶部200は、各ユーザの基本情報を格納するデータベースを記憶してもよい。例えば、ユーザの居住地をデータベースに格納しておき、航空券予約などの出発地として利用してもよい。
[検索部]
検索部201は、制御部21を主として実現される。検索部201は、ユーザにより入力された検索条件に基づいて、ホテル検索を実行する。検索自体は、公知の種々の処理を適用可能であり、例えば、キーワード検索が実行される場合には、完全一致や部分一致が利用されてもよいし、あいまい検索が利用されてもよい。また例えば、数値検索が実行される場合には、検索条件で指定された数値範囲と一致する数値が検索される。
ホテル検索は、本発明に係るアイテム検索の一例である。アイテム検索は、アイテムを検索するための処理であればよく、検索条件をクエリとし、クエリと一致するインデックスを有するアイテムを検索する処理である。別の言い方をすれば、アイテム検索は、アイテムデータベースDB1の中から、検索条件にヒットするアイテムのレコードを検索する処理である。
検索部201は、ユーザ端末10から検索条件を受信し、当該受信した検索条件に基づいて、ホテル検索を実行する。本実施形態では、検索部201は、ユーザ端末10から、トップ画面G1の入力フォームF10〜F13に入力された検索条件を受信し、当該受信した検索条件に基づいて、ホテル検索を実行する。ここでは、入力フォームF10〜F13に対し、宿泊地、利用日、及び利用人数が入力されるので、検索部201は、これら宿泊地、利用日、及び利用人数をクエリとし、アイテムデータベースDB1に格納されたホテル情報及び部屋情報と、在庫データベースDB2に格納された利用日と、をインデックスとして、ホテル検索を実行する。
例えば、検索部201は、入力フォームF10に入力された宿泊地と、ホテル情報に格納された住所と、が一致するレコードを検索し、宿泊地に合致するホテルを特定する。そして、検索部201は、特定したホテルの中から、入力フォームF13に入力された人数と、部屋情報に格納された利用可能人数と、が一致するホテルの部屋を絞りこむ。更に、検索部201は、在庫データベースDB2を参照し、絞り込んだホテルの部屋の中から、入力フォームF11、F12に入力された利用日に残室がある部屋を絞り込む。検索部201は、最終的に絞り込んだ部屋があるホテルを検索結果として取得する。検索結果に含まれるホテルは、検索条件にヒットしたホテルといえる。
[閲覧部]
閲覧部202は、制御部21を主として実現される。閲覧部202は、検索部201の検索結果の中から、ユーザにより選択されたホテルを閲覧させる。検索結果は、検索部201の処理結果であり、例えば、検索でヒットしたホテルのホテルID、ホテル情報、部屋情報、及び在庫情報といった情報を含んでもよい。本実施形態では、検索結果は、検索結果画面G2内のリストL21に表示される。
閲覧とは、ホテルに関する情報を表示部15に表示させることである。例えば、ホテルに関する情報は、ホテル情報、部屋情報、及び在庫情報のうちの少なくとも1つである。閲覧部202は、ホテル画面G3を表示部15に表示させることによって、ユーザにホテルを閲覧させる。別の言い方をすれば、閲覧は、サーバ20からユーザ端末10に対し、ホテルに関する情報が送信されることである。閲覧部202は、ホテル画面G3の表示データをユーザ端末10に送信することによって、ユーザにホテルを閲覧させる。表示データは、画面を表示させるためのデータであればよく、例えば、HTMLデータ、画像データ、又はテキストデータ等である。
本実施形態では、閲覧部202がサーバ20によって実現されるので、閲覧部202は、リストL21の中からユーザにより選択されたホテルのホテルIDをユーザ端末10から受信し、当該受信したホテルIDが示すホテルを閲覧させる。例えば、閲覧部202は、アイテムデータベースDB1のうち、受信したホテルIDが格納されたレコードのホテル情報と部屋情報とに基づいて、ホテル画面G3の表示データを生成し、ユーザ端末10に対して送信することによって、ユーザにホテルの詳細を閲覧させる。また例えば、閲覧部202は、在庫データベースDB2のうち、受信したホテルIDが格納されたレコードの在庫情報をユーザ端末10に対して送信することによって、ユーザに在庫情報を閲覧させてもよい。
また例えば、閲覧部202は、表示制御部204により表示された閲覧済みホテルがユーザにより選択された場合に、当該閲覧済みホテルに関連付けられた検索条件に基づいて、当該閲覧済みホテルを閲覧させてもよい。即ち、閲覧部202は、表示領域A15に表示された閲覧済みホテルが選択された場合には、当該閲覧済みホテルの検索時の検索条件でホテル画面G3の表示データを生成し、ユーザ端末10に対して送信してもよい。閲覧部202は、閲覧履歴データベースDB3のうち、ユーザにより選択された閲覧済みホテルのホテルIDが格納されたレコードを参照し、検索条件を取得する。そして、閲覧部202は、アイテムデータベースDB1及び在庫データベースDB2のうち、当該ホテルIDが格納されたレコードを参照し、検索条件を満たす部屋を検索し、閲覧済みホテルを閲覧させる。
[関連付け部]
関連付け部203は、制御部21を主として実現される。関連付け部203は、閲覧済みホテルと、検索で用いられた検索条件と、を関連付けてデータ記憶部200に記録する。
閲覧済みホテルは、閲覧部202の制御により、ユーザが既に閲覧したホテルである。別の言い方をすれば、閲覧済みホテルは、閲覧部202によって、ホテル画面G3が表示部15に表示されたり、ホテル画面G3の表示データがユーザ端末10に送信されたりしたホテルである。
検索で用いられた検索条件とは、閲覧済みホテルの検索時に入力された検索条件である。別の言い方をすれば、検索で用いられた検索条件は、閲覧済みホテルの検索時にクエリとなった検索条件である。検索条件は、検索部201によって検索が実行された後、データ記憶部200に保持され、ホテルが閲覧された場合に閲覧履歴データベースDB3に格納されるものとする。なお、関連付けるとは、情報同士を紐付けることであり、複数の情報をデータベース上で互いに検索可能にすることである。
閲覧済みホテルと検索条件とは、データ記憶部200内の任意のデータベースにおいて関連付けられてよいが、本実施形態では、閲覧履歴データベースDB3において関連付けられるものとする。例えば、関連付け部203は、閲覧済みホテルのホテルIDと、検索で用いられた検索条件と、を閲覧履歴データベースDB3の同じレコードに格納する。
例えば、関連付け部203は、閲覧部202によってユーザにホテルが閲覧された場合に、閲覧済みの当該ホテルと、検索条件と、を関連付けて閲覧履歴データベースに格納する。別の言い方をすれば、関連付け部203は、閲覧部202によってユーザにホテルが閲覧されるたびに、閲覧済みの当該ホテルと、検索条件と、を関連付けて閲覧履歴データベースに格納する。
なお、検索条件は、そのまま格納されてもよいし、在庫情報に影響する検索条件だけが格納されてもよい。例えば、検索条件として入力された宿泊地は、在庫情報に影響しないので閲覧履歴データベースDB3に格納されず、利用日と利用人数だけが閲覧履歴データベースDB3に格納されてもよい。
また、閲覧済みホテルが再度閲覧された場合に、検索条件が変わっていれば、関連付け部203は、新たな検索条件と、閲覧済みホテルと、を閲覧履歴データベースDB3に関連付けて格納する。この場合、古い検索条件が格納されたレコードは、そのまま残してもよいし破棄してもよい。また例えば、古い検索条件が格納されたレコードの当該検索条件を、新たな検索条件に更新してもよい。この場合、閲覧履歴データベースDB3の閲覧日時は、最新の閲覧日時に更新してもよい。
[表示制御部]
表示制御部204は、制御部21を主として実現される。表示制御部204は、閲覧済みホテルに関連付けられた検索条件を満たす利用日の在庫情報に基づいて、閲覧済みホテルの表示を制御する。
検索条件を満たすとは、検索条件とインデックスが一致することである。別の言い方をすれば、検索条件を満たすとは、検索でヒットすることである。本実施形態では、利用日がサブアイテムに相当し、利用日に在庫情報が関連付けられているので、検索条件に含まれる利用日と、在庫データベースDB2に格納された利用日と、が一致することが、閲覧済みホテルに関連付けられた検索条件を満たすことに相当する。
表示制御の対象となる閲覧済みホテルは、1つだけであってもよいし、複数であってもよい。複数の閲覧済みホテルが表示制御の対象となる場合には、閲覧履歴データベースDB3に格納された全ての閲覧済みホテルであってもよいし、一部の閲覧済みホテルであってもよい。一部の閲覧済みホテルを表示制御の対象とする場合には、直近の所定個数の閲覧済みホテルとしてもよいし、ランダムに選出された閲覧済みホテルであってもよい。所定個数としては、表示領域A15に収まる程度(例えば、2個〜10個程度)であってもよいし、それ以上であってもよい。
例えば、表示制御部204は、ユーザ端末10から、閲覧履歴の表示要求を受信した場合に、閲覧履歴データベースDB3のうち、表示要求を送信したユーザのユーザIDが格納されたレコードを参照する。表示要求は、閲覧履歴を表示させるための所定形式の要求であればよく、本実施形態では、トップ画面G1を表示させるための要求である。ユーザIDは、予めユーザ端末10のデータ記憶部100に記憶させておけばよい。
表示制御部204は、上記参照したレコードのうち、直近の所定個数のレコードを参照する。例えば、図9に示すように、閲覧履歴データベースDB3に、閲覧時間が若い順にデータが格納されている場合には、表示制御部204は、所定個数だけ順番にレコードを参照する。そして、表示制御部204は、在庫データベースDB2に基づいて、参照した各レコードに格納された検索条件が示す利用日の在庫情報を取得し、当該取得した在庫情報に基づいて、閲覧済みホテルの表示を制御する。
例えば、表示制御部204は、閲覧済みホテルに関連付けられた検索条件を満たす利用日の在庫情報に基づいて在庫の有無を判定し、当該判定結果に基づいて表示制御を行ってもよい。例えば、表示制御部204は、在庫情報が示す数値が閾値以上であれば在庫があると判定し、閾値未満であれば在庫がないと判定する。本実施形態では、閾値を1とするが、2以上の数値(例えば、2〜5程度の数値)を設定し、在庫が残りわずかになった場合には、在庫がないとみなすようにしてもよい。
なお、在庫の有無を判定する処理は、利用日が経過しているか否かを判定する処理は特に含まないようにしてもよいし、利用日が経過しているか否かを判定する処理を含んでいてもよい。閲覧済みホテルの利用日が経過した場合には、当該利用日の在庫の有無を判定する必要がないので、表示制御部204は、利用日が経過した閲覧済みホテルについては、在庫の有無を判定しなくてよい。在庫の有無を判定する処理は、閲覧済みホテルの利用日が経過したか否かを判定する処理を含んでいてもよい。
また例えば、表示制御部204は、閲覧済みホテルに関連付けられた検索条件を満たす利用日の在庫の有無を示す情報を、閲覧済みホテルに関連付けて表示させてもよい。
在庫の有無を示す情報とは、在庫の有無を識別可能な情報であり、例えば、在庫があることを示す情報であってもよいし、在庫がないことを示す情報であってもよい。本実施形態では、メッセージM151が、在庫の有無を示す情報に相当する場合を説明するが、他の情報が表示されてもよく、例えば、在庫の有無を示すアイコン等が表示されてもよい。
関連付けて表示させるとは、例えば、在庫の有無を示す情報を閲覧済みホテルの上又はその付近に表示させること、在庫の有無を示す情報と閲覧済みホテルとを線などで結んで表示させること、又は、在庫の有無を示す情報を閲覧済みホテルに組み込んで表示させることである。
本実施形態では、メッセージM151を、閲覧済みホテルの画像G150上に表示させることが、関連付けて表示させることに相当する場合を説明する。このため、例えば、表示制御部204は、閲覧済みホテルに関連付けられた検索条件を満たす利用日の在庫のない場合に、その旨を示すメッセージM151を、当該閲覧済みホテルの画像G150上に表示させる。メッセージM151の画像データは、データ記憶部200に予め記憶させておけばよい。
なお、表示制御部204は、閲覧済みホテルに関連付けられた検索条件を満たす利用日の在庫のない場合に、在庫があることを示すメッセージやアイコン等を閲覧済みホテルの画像G150上に表示させてもよい。この場合、表示制御部204は、現在の在庫数を示すメッセージやアイコン等を表示させてもよい。
また、表示制御部204が実行する表示制御は、在庫の有無を示す情報の表示に限られない。例えば、表示制御部204は、在庫の有無に基づいて、閲覧済みホテルを示す画像G150の表示態様を変えてもよい。表示態様とは、例えば、画像のサイズ、色、輝度、透明度、形状、模様などである。
表示制御部204は、在庫がある場合は第1の表示態様(例えば、加工しない通常の色)で画像G150を表示させ、在庫が無い場合は第2の表示態様(例えば、グレーアウト)で画像G150を表示させてもよい。また例えば、表示制御部204は、在庫の有無を判定することなく、在庫情報が示す在庫数をそのまま表示させてもよい。
[1−3−2.ユーザ端末で実現される機能]
図6に示すように、ユーザ端末10では、データ記憶部100、受付部101、及び表示制御部102が実現される。データ記憶部100、受付部101、及び表示制御部102は、それぞれ記憶手段、受付手段、及び表示制御手段の一例である。
[データ記憶部]
データ記憶部100は、記憶部12を主として実現される。データ記憶部100は、サーバ20から受信したデータを記憶する。例えば、データ記憶部100は、トップ画面G1、検索結果画面G2、及びホテル画面G3の各々の表示データを記憶してもよい。また例えば、データ記憶部100は、ユーザIDを記憶してもよいし、リストL21に含まれるホテルのホテルIDを記憶してもよい。
[受付部]
受付部101は、制御部11を主として実現される。受付部101は、操作部14の検出信号に基づいて、ユーザの操作を受け付ける。受付部101がユーザの操作を受け付けると、ユーザ端末10は、当該操作の内容を示す情報をサーバ20に送信する。例えば、受付部101が操作を受け付けると、ユーザ端末10は、何れの操作が行われたかを識別する情報をサーバ20に送信する。
[表示制御部]
表示制御部102は、制御部11を主として実現される。表示制御部102は、サーバ20から受信した表示データに基づいて、各種画面を表示させる。例えば、表示制御部102は、トップ画面G1、検索結果画面G2、及びホテル画面G3の各々を表示させる。例えば、ウェブブラウザを利用して各画面を表示させる場合には、表示データは、HTMLデータであり、ユーザ端末10のプログラム(例えば、旅行予約アプリ)を利用して各画面を表示させる場合には、表示データは、フレームにはめ込む画像やテキスト情報であってもよい。
[1−4.本実施形態において実行される処理]
図10は、検索システムSにおいて実行される処理の一例を示すフロー図である。図10に示す処理は、制御部11,21が、それぞれ記憶部12,22に記憶されたプログラムに従って動作することによって実行される。下記に説明する処理は、図6に示す機能ブロックにより実行される処理の一例である。
図10に示すように、まず、ユーザ端末10において、制御部11は、操作部14から所定の操作が行われた場合に、サーバ20に対し、トップ画面G1の表示要求を送信する(S1)。例えば、所定の操作は、トップ画面G1のURLを選択する操作であってもよいし、旅行予約アプリを起動する操作であってもよい。トップ画面G1の表示要求は、所定形式のデータが送信されることで行われ、トップ画面G1を識別する情報(例えば、URLや画面ID)を含む。なお、ユーザ端末10からサーバ20に何らかのデータが送信される場合には、記憶部12に記憶されたユーザIDも送信されるものとする。
サーバ20においては、表示要求を受信すると、制御部21は、閲覧履歴データベースDB3に基づいて、トップ画面G1の表示内容を決定する(S2)。
図11は、S2の処理の詳細を示す図である。図11に示すように、制御部21は、閲覧履歴データベースDB3のうち、表示要求とともに受信したユーザIDが格納されたレコードを特定し、直近のn(nは自然数)個のレコードを参照する(S20)。S20においては、制御部11は、閲覧時間が新しい順にn個のレコードを参照してもよいし、レコード番号が若い順にn個のレコードを参照してもよい。
制御部21は、カウンタ変数kに1を代入する(S21)。制御部21は、S20で取得したn個のレコードのうち、k個目のレコードに格納されたホテルIDと検索条件を取得する(S22)。
制御部21は、アイテムデータベースDB1と在庫データベースDB2に基づいて、S22で取得した検索条件を満たす利用日の在庫情報を取得する(S23)。S23においては、制御部21は、アイテムデータベースDB1のうち、S22で取得したホテルIDが格納されたレコードを参照し、検索条件に含まれる利用人数を満たす部屋の部屋IDを特定する。そして、制御部21は、在庫データベースDB2のうち、当該ホテルIDと部屋IDが格納されたレコードを参照し、検索条件が示す利用日の在庫情報を取得する。
制御部21は、S23で取得した在庫情報に基づいて在庫の有無を判定する(S24)。S24においては、制御部21は、在庫情報が示す数値が1以上であるか否かを判定する。
在庫があると判定された場合(S24;Y)、制御部21は、「SOLD OUT」のメッセージM151を含まない画像G150を表示領域A15に配置する(S25)。なお、各ホテルの画像G150は、アイテムデータベースDB1等に予め格納しておけばよい。一方、在庫がないと判定された場合(S24;N)、制御部21は、「SOLD OUT」のメッセージM151を含む画像G150を表示領域A15に配置する(S26)。
制御部21は、カウンタ変数kをインクリメントする(S27)。制御部21は、カウンタ変数kがnよりも大きくなったか否かを判定する(S28)。S28においては、制御部21は、S20で取得したn個のレコード全てについて、S22〜S27の処理を実行したか否かを判定することになる。
カウンタ変数kがn以下であると判定された場合(S28;N)、S22の処理に戻り、次のレコードについて、S22〜S27の処理が実行される。一方、カウンタ変数kがnよりも大きくなったと判定された場合(S28;Y)、制御部11は、表示領域A16の表示内容を決定し(S29)、S2の処理を終えて、図10のS3に移行する。S29においては、制御部11は、閲覧履歴データベースDB3に基づいて、ユーザの嗜好を分析し、リコメンドするホテル等を決定すればよい。また例えば、ユーザがホテルを予約した場合には、ホテル以外の内容(航空券、レンタカー、又はバス)をリコメンドするといったように、予約済みアイテムの種類に応じたリコメンドが行われてもよい。
図10に戻り、制御部21は、S2の処理結果に基づいて、トップ画面G1の表示データを生成し、ユーザ端末10に対して表示データを送信する(S3)。なお、トップ画面G1の表示データには、表示領域A15,A16に表示されたホテル等の識別情報(例えば、ホテルID)が含まれているものとする。これにより、例えば、ユーザが画像G150を選択した場合に、どの閲覧済みホテルが選択されたかを特定可能となる。
ユーザ端末10においては、表示データを受信すると、制御部11は、当該表示データに基づいて、トップ画面G1を表示部15に表示させる(S4)。制御部11は、操作部14の検出信号に基づいて、ユーザの操作を特定する(S5)。ここでは、ボタンB14を選択する操作、又は、表示領域A15内の画像が選択される操作の何れかが行われる場合を説明する。なお、入力フォームF10〜F12に検索条件を入力する操作が行われた場合には、入力内容が、入力フォームF10〜F12に表示されるとともに、記憶部12に記録されるものとする。
ボタンB14が選択された場合(S5;B14)、制御部11は、検索の実行を要求するための検索要求を送信する(S6)。検索要求は、所定形式のデータが送信されることで行われるようにすればよく、入力フォームF10〜F13に入力された検索条件を含む。
サーバ20においては、検索要求を受信すると、制御部21は、アイテムデータベースDB1及び在庫データベースDB2に基づいて、検索要求に含まれる検索条件に基づいて、ホテル検索を実行する(S7)。S7においては、制御部21は、検索条件をクエリとし、アイテムデータベースDB1に格納されたホテル情報及び部屋情報と、在庫データベースDB2に格納された利用日と、をインデックスとして、検索を実行する。制御部21は、検索条件に合致する部屋を有し、かつ、当該部屋の在庫があるホテルを検索し、検索結果を取得する。
制御部21は、S7の実行結果に基づいて、検索結果画面G2の表示データを生成し、ユーザ端末10に対して送信する(S8)。なお、検索結果画面G2の表示データには、リストL21に含まれるホテルのホテルIDが含まれているものとする。これにより、例えば、ユーザがリストL21内のホテルを選択した場合に、どのホテルが選択されたかを特定可能となる。
ユーザ端末10においては、表示データを受信すると、制御部11は、検索結果画面G2を表示部15に表示させる(S9)。制御部11は、操作部14の検出信号に基づいて、ユーザの操作を特定する(S10)。ここでは、トップ画面G1に戻る操作、又は、リストL21内のホテルを選択する操作が行われる場合を説明する。
トップ画面G1に戻る操作が行われた場合(S10;トップ)、S1の処理に戻り、トップ画面G1の表示要求が送信される。一方、リスト内L21のホテルを選択する操作が行われた場合(S10;選択)、制御部11は、ホテル画面G3の表示要求を送信する(S11)。ホテル画面G3の表示要求には、リストL21の中から選択されたホテルのホテルIDが含まれるものとする。
サーバ20においては、表示要求を受信すると、制御部21は、アイテムデータベースDB1に基づいて、ホテル画面G3の表示データを生成し、ユーザ端末10に対して送信する(S12)。S12においては、制御部21は、アイテムデータベースDB1のうち、表示要求に含まれるホテルIDが格納されたレコードを参照し、ホテル情報と部屋情報に基づいて、ホテル画面G3の表示データを生成する。なお、S12においては、制御部21は、S7の検索時にヒットした部屋だけを表示させてもよいし、同じホテルの他の部屋について表示させてもよい。
制御部21は、表示要求に含まれるホテルIDと、S7で受信した検索条件と、を関連付けて閲覧履歴データベースDB3に格納する(S13)。S12においては、制御部21は、閲覧履歴データベースDB3に新たなレコードを作成し、表示要求とともに受信したユーザID、ホテルID、検索条件、及び閲覧時間を格納する。閲覧時間は、リアルタイムクロック等で取得した現在時間が格納されるようにすればよい。
ユーザ端末10においては、表示データを受信すると、制御部11は、ホテル画面G3を表示部15に表示させる(S14)。制御部11は、操作部14の検出信号に基づいて、ユーザの操作を特定する(S15)。ここでは、トップ画面G1に戻る操作、検索結果画面G2に戻る操作、又はボタンB30を選択する操作について説明する。
トップ画面G1に戻る操作が行われた場合(S15;トップ)、S1の処理に戻り、トップ画面G1の表示要求が送信される。一方、検索結果画面G2に戻る操作が行われた場合(S15;検索結果)、S9の処理に戻り、検索結果画面G2に戻る。
一方、ボタンB30を選択する操作が行われた場合(S15;B30)、ユーザ端末10とサーバ20との間でホテル予約処理が実行され(S16)、本処理は終了する。S16においては、ユーザ端末10において入力された宿泊者情報等がサーバ20に送信され、サーバ20は、宿泊者情報等を記憶部22に記録し、ユーザが予約したホテルの部屋の在庫が減るように、在庫データベースDB2を更新する。
なお、S5において、表示領域A15内の画像G150が選択される操作が行われた場合(S5;G150)、S11の処理に移行し、ユーザが選択した画像G150が示す閲覧済みホテルのホテル画面G3の表示要求が送信される。この場合、続くS12において、制御部11は、閲覧履歴データベースDB3のうち、表示要求に含まれるホテルIDが格納されたレコードを参照し、当該レコードに格納された検索条件に基づいて、ホテル画面G3の表示データを生成する。なお、この場合は、検索結果からホテルが選択されたわけではないので、S13の処理は実行されないものとする。
実施形態1の検索システムSによれば、閲覧済みホテルに関連付けられた検索条件を満たす利用日の在庫情報に基づいて、閲覧済みホテルの表示が制御され、閲覧済みホテルの表示から在庫に関する内容を把握できるので、ユーザインタフェースの利便性を高めることができる。例えば、在庫情報に関係なく閲覧済みホテルを表示させる場合には、残室がない閲覧済みホテルを選択してしまい、ホテル画面G3が表示されても予約することができず、いちいち元のページに戻ったり別のページに移動したりするといった手間が発生するところ、検索システムSでは、閲覧済みホテルの表示から在庫に関する内容を把握できるので、このような手間が発生することを防止し、ユーザにとって使い勝手のよいユーザインタフェースとすることができる。また、元のページに戻ったり別のページに移動したりしなくなることで、サーバ20がホテル画面G3の表示データを生成及び送信する処理回数を減らすことができ、サーバ20の処理負荷を減らすことができる。また、ネットワーク上に流れる表示データが減るので、通信負荷を減らすこともできる。
また、閲覧済みホテルに関連付けられた検索条件を満たす利用日の在庫情報に基づいて在庫の有無を判定し、当該判定結果に基づいて閲覧済みホテルの表示制御が行われることで、閲覧済みホテルの表示から在庫の有無を把握できるので、ユーザインタフェースの利便性を効果的に高めることができる。
また、閲覧済みホテルに関連付けられた検索条件を満たす利用日の在庫の有無を示すメッセージM151が、閲覧済みホテルを示す画像G150に関連付けて表示され、在庫の有無をより把握しやすくなるので、ユーザインタフェースの利便性を効果的に高めることができる。
また、表示領域A15において表示された閲覧済みホテルがユーザにより選択された場合に、当該閲覧済みホテルに関連付けられた検索条件に基づいて、当該閲覧済みホテルのホテル画面G3が表示され、検索条件を再入力するといった手間を省くことができるので、ユーザの操作負担を軽減することができる。
[2.実施形態2]
次に、検索システムSの別実施形態を説明する。実施形態1で説明したように、トップ画面G1の表示領域A15には、閲覧済みホテルが表示される。ユーザがホテルを予約した場合、予約済みのホテルと同じ検索条件で検索した他のホテルは、ユーザによって予約される蓋然性が低い。このため、このようなホテルまで、表示領域A15に表示させたままにしておくと、不要な情報が表示されることになる。そこで、実施形態2では、ユーザが閲覧したホテルのうち、予約済みのホテルと同じ検索条件で検索したホテルは、表示領域A15に表示させないようにしている。
なお、実施形態2では、実施形態1と同様、ホテルがアイテムに相当し、利用日がサブアイテムに相当する場合を説明する。また、実施形態2では、実施形態1と同様の構成については説明を省略し、実施形態1と異なる構成を説明する。また、実施形態1で説明したメッセージM151を表示させる処理は、実施形態2で実行されてもよいし、実施形態2では省略して特に実行されなくてもよい。即ち、実施形態2では、閲覧済みホテルの在庫がなくなっても、特にメッセージM151が表示されなくてもよい。
[2−1.実施形態2の概要]
図12は、実施形態2のトップ画面G1の一例を示す図である。図12に示すように、トップ画面G1のレイアウトは、実施形態1のトップ画面G1と同様であり、例えば、表示領域A15には、閲覧済みホテルを示す画像G150が閲覧順に並んで表示される。
例えば、画像G150F〜G150Hにそれぞれ示す「ホテルF」、「ホテルG」、及び「ホテルH」は、それぞれ同じ検索条件で検索されて閲覧されたホテルである。ここでは、これら3つのホテルの検索条件を、宿泊地が「東京」であり、利用日が「2018年4月1日」〜「2018年4月3日」であり、かつ、利用人数が「2人」といった条件とする。
一方、画像G150I〜G150Kにそれぞれ示す「ホテルI」、「ホテルJ」、及び「ホテルK」は、それぞれ同じ検索条件で検索されて閲覧されたホテルである。ただし、この検索条件は、「ホテルF」、「ホテルG」、及び「ホテルH」の検索条件とは異なり、宿泊地が「ニューヨーク」であり、利用日が「2018年5月15日」〜「2018年5月18日」であり、かつ、利用人数が「4人」といった条件とする。
例えば、ユーザがまだホテルの予約をしていない場合には、図12に示すように、画像G150F〜G150Kが表示領域A15に表示される。その後、ユーザが「ホテルF」を予約したとすると、表示領域A15から、「ホテルF」、「ホテルG」、及び「ホテルH」が消去され、表示領域A15に表示される閲覧済みホテルが変わる。
図13は、予約前後で表示領域A15に表示される閲覧済みホテルが変わる様子を示す図である。図13のトップ画面G1Gに示すように、例えば、ユーザが表示領域A15の画像G150Fを選択すると、画像G150Fが示す「ホテルF」のホテル画面G3が表示される。ユーザがボタンB30を選択した後に、利用日、利用人数、及び宿泊者情報といった予約に必要な情報を入力し、「ホテルF」の予約を完了させると、予約完了画面G4が表示部15に表示される。
その後、ユーザがボタンB40を選択してトップ画面G1に戻ると、トップ画面G1Hの表示領域A15に示すように、予約済みの「ホテルF」だけでなく、同じ検索条件で検索された「ホテルG」と「ホテルH」も消去される。ただし、「ホテルI」、「ホテルJ」、及び「ホテルK」は、違う検索条件で検索されたホテルなので、表示領域A15に表示されたままとなる。また、「ホテルF」、「ホテルG」、及び「ホテルH」が表示領域A15から消去されてスペースが空いたので、「ホテルK」よりも前に閲覧した「ホテルL」が、新たに表示領域A15に表示される。
以上のように、実施形態2の検索システムSは、閲覧済みホテルのうち、予約済みのホテルと同じ検索条件で検索したホテルは、表示領域A15から消去することで、不要な情報が残ったままになることを防止し、ユーザインタフェースの利便性を高めるようになっている。以降、この技術の詳細を説明する。
[2−2.実施形態2において実現される機能]
図14は、実施形態2の検索システムSで実現される機能の一例を示す機能ブロック図である。なお、本実施形態では、表示制御に関する主な機能がサーバ20で実現される場合を説明するが、後述する変形例のように、主な機能がユーザ端末10で実現されるようにしてもよいし、ユーザ端末10とサーバ20との間で機能が分担されてもよい。
図14に示すように、実施形態2では、実施形態1と同様、サーバ20において、データ記憶部200、検索部201、閲覧部202、関連付け部203、及び表示制御部204が実現される。ただし、一部の機能は、実施形態1と異なる。以降、実施形態1と異なる点について説明する。なお、ユーザ端末10の機能は、実施形態1と同様とする。
[データ記憶部]
例えば、データ記憶部200は、アイテムデータベースDB1、在庫データベースDB2、閲覧履歴データベースDB3、及び予約データベースDB4を記憶する。アイテムデータベースDB1と在庫データベースDB2は、実施形態1と同様であるが、実施形態2では、閲覧履歴データベースDB3の内容が実施形態1と異なる。
図15は、実施形態2の閲覧履歴データベースDB3のデータ格納例を示す図である。図15に示すように、実施形態2の閲覧履歴データベースDB3には、実施形態1で説明した情報に加え、非表示フラグが格納される。
非表示フラグは、閲覧済みホテルを示す画像G150を表示させるか否かを示す情報である。例えば、非表示フラグが第1の値(例えば、0)の場合には、閲覧済みホテルを表示させることを示し、非表示フラグが第2の値(例えば、1)の場合には、閲覧済みホテルを表示させないことを示す。以降、非表示フラグを第1の値から第2の値にすることを、非表示フラグをオンにすると記載し、非表示フラグを第2の値から第1の値にすることを、非表示フラグをオフにすると記載する。
本実施形態では、予約済みのホテルと、当該予約済みのホテルと検索条件が同じである閲覧済みホテルと、は表示領域A15に表示されないので、非表示フラグは、これらのホテルを識別するための情報ということもできる。非表示フラグは、ホテルの予約処理が実行され、後述する予約データベースDB4にレコードが追加された場合に更新される。例えば、予約済みのホテルと、当該予約済みのホテルと検索条件が同じである閲覧済みホテルと、の各々の非表示フラグをオンにする。なお、一定時間が経過した場合に、これらの非表示フラグがオフになってもよい。
図16は、予約データベースDB4のデータ格納例を示す図である。図16に示すように、予約データベースDB4は、ユーザが予約したホテルに関するデータベースである。例えば、予約データベースDB4には、ホテルを予約したユーザのユーザID、予約情報、及び予約完了日時が格納される。
予約情報は、予約内容を示す情報であり、例えば、ユーザが予約時に入力した内容である。例えば、予約情報には、ユーザが予約したホテルのホテルID、ユーザが予約した部屋の部屋ID、利用日、及び利用人数といった情報が格納される。なお、予約情報に含まれる内容は、これらに限られず、他にも例えば、宿泊者情報などの任意の内容が含まれていてもよい。
例えば、ホテル検索が実行された後、ユーザが利用日や利用人数を変更しなかった場合には、予約情報は、検索条件と同じ内容を含むことになるが、ユーザは、検索後に利用日や利用人数を変更して予約することができるので、この場合は、予約情報は、検索条件とは異なる内容を含むことになる。ホテルの予約処理が実行されると、予約データベースDB4に新たなレコードが追加され、ホテルを予約したユーザのユーザID、予約時に入力された予約情報、及び予約完了日時が当該レコードに格納される。予約完了日時は、リアルタイムクロック等で取得される現在日時を利用すればよい。
なお、ユーザは、ホテル画面G3を表示させることなく、電話や窓口によってホテルを予約し、その予約結果が予約データベースDB4に追加されるようにしてもよいが、本実施形態では、ユーザは、ホテル画面G3から予約の申し込みを行う場合を説明する。このため、ユーザにより予約されたホテルは、閲覧済みホテルの1つである。即ち、ユーザは、閲覧履歴データベースDB3に格納された少なくとも1つホテルのうちの何れかを予約する。
[検索部・閲覧部・関連付け部]
検索部201、閲覧部202、及び関連付け部203は、それぞれ実施形態1と同様である。
[表示制御部]
表示制御部204は、ユーザによりホテルが予約された場合に、予約内容に関する内容情報と、閲覧済みホテルに関連付けられた検索条件と、に基づいて、閲覧済みホテルの表示を制御する。
内容情報は、ユーザがホテルを予約する場合に指定したサブアイテムに関する情報である。ホテルを予約する場合とは、予約されたホテルに関するレコードが予約データベースDB4に追加される前であればよく、例えば、ユーザが検索条件を入力してから、予約が確定される前までの任意の時点であってよい。本実施形態では、利用日がサブアイテムに相当するので、内容情報は、ユーザが指定した利用日であり、例えば、検索条件に含まれる利用日であってもよいし、検索後にユーザが指定した利用日であってもよい。
例えば、検索条件は、宿泊地・利用日・利用人数といった複数のサブアイテムの各々に関する条件を含むので、内容情報は、複数のサブアイテムのうち、予約内容に関する少なくとも1つのサブアイテムに関する情報といえる。即ち、上記3つのサブアイテムうち、宿泊地は、検索で用いられるだけであり、ユーザが指定した予約内容には関係ないので、利用日と利用人数の2つが内容情報となる。
例えば、ホテル予約であれば、内容情報は、利用日又は利用人数である。航空機予約であれば、内容情報は、出発地、目的地、出発日、出発時間、到着日、又は到着時間である。レンタカー予約であれば、内容情報は、店舗の場所、利用日、利用時間、又は車種である。バス予約であれば、内容情報は、出発地、目的地、出発日、又は出発時間である。列車予約であれば、内容情報は、出発地、目的地、出発日、出発時間、到着日、又は到着時間である。レストラン予約であれば、内容情報は、利用日、利用人数、又はメニューである。オプションツアー予約であれば、内容情報は、利用日又は利用人数である。
なお、内容情報は、ユーザが予約した閲覧済みホテルの検索で用いられた検索条件(即ち、閲覧履歴データベースDB3において予約済みのホテルに関連付けられた検索条件)であってもよいし、予約データベースDB4に格納された、予約済みのホテルの予約情報であってもよい。
本実施形態では、ホテルの利用日がサブアイテムに相当するので、ユーザがホテルを予約する場合に指定した利用日が内容情報に相当する場合を説明する。このため、表示制御部204は、ユーザによりホテルが予約された場合に、当該ホテルの利用日と、閲覧済みホテルに関連付けられた検索条件が示す利用日と、に基づいて、閲覧済みホテルの表示を制御する。
例えば、表示制御部204は、ユーザにより予約されたホテルの利用日と、閲覧済みホテルに関連付けられた検索条件が示す利用日と、が一致するか否かを判定する。ここでの一致とは、完全一致でもよいし、部分一致であってもよい。部分一致とは、期間の一部が重複することを意味し、例えば、ホテルに連泊する場合に宿泊期間の一部が重複することである。なお、以降の説明で、利用日の一致といった記載をした場合には、ユーザにより予約されたホテルの利用日と、閲覧済みホテルに関連付けられた検索条件が示す利用日と、の一致を意味する。
表示制御部204は、利用日が一致するか否かの判定結果に基づいて、閲覧済みホテルの表示を制御する。例えば、表示制御部204は、利用日が一致する閲覧済みホテルは表示領域A15に表示させず、利用日が一致しない閲覧済みホテルは表示領域A15に表示させる。
本実施形態では、閲覧履歴データベースDB3の非表示フラグをオンにすることが、閲覧済みホテルを表示させないようにするための処理に相当し、非表示フラグをオフにする(又はオフのまま値を変えない)ことが、閲覧済みホテルを表示させるようにするための処理に相当する。このため、表示制御部204は、利用日が一致する閲覧済みホテルの非表示フラグをオンにし、利用日が一致しない閲覧済みホテルの非表示フラグをオフにする。
なお、特に非表示フラグを用意しない場合には、ユーザ端末10からトップ画面G1の表示要求を受信するたびに、表示制御部204が利用日の一致を判定し、閲覧済みホテルの表示を制御してもよい。他にも例えば、表示制御部204は、利用日が一致した閲覧済みホテルについては、閲覧履歴データベースDB3からレコードを削除したり、他のデータベースにレコードを退避したりすることによって、当該閲覧済みホテルが表示領域A15に表示されないようにしてもよい。
また例えば、本実施形態では、閲覧履歴データベースDB3に格納された検索条件が内容情報に相当するので、表示制御部204は、予約された閲覧済みホテルに関連付けられた検索条件と、他の閲覧済みホテルに関連付けられた検索条件と、に基づいて、当該他の閲覧済みホテルの表示を制御することになる。表示制御部204は、ユーザによって閲覧済みホテルが予約された場合に、閲覧履歴データベースDB3に格納された当該閲覧済みホテルの検索条件を取得し、他の閲覧済みホテルの検索条件と比較し、当該他の閲覧済みホテルの表示を制御する。
また例えば、本実施形態では、検索条件に複数のサブアイテムに関する条件が含まれるので、表示制御部204は、予約されたホテルの利用日と、閲覧済みホテルに関連付けられた検索条件に含まれる少なくとも1つのサブアイテムに関する条件と、に基づいて、表示制御を行うことになる。どのサブアイテムが利用されるかは、予め定めておけばよく、本実施形態では、利用日とするが、利用日だけでなく利用人数も利用してよい。他にも例えば、宿泊地は利用しないものとして説明しているが、宿泊地も考慮して、閲覧済みアイテムの表示制御が行われてもよい。
上記のように、本実施形態では、表示制御部204は、ユーザにより予約されたホテルとの関係で利用できない閲覧済みホテルを特定し、当該特定した閲覧済みホテルの表示制御を行うことになる。
利用できない閲覧済みホテルとは、検索システムSが予約申し込みを受け付けないという意味ではなく、物理的に利用できない閲覧済みホテルである。物理的に利用できないとは、ユーザの移動が間に合わないことである。例えば、予約済みのホテルの利用日と、閲覧済みホテルに関連付けられた検索条件に含まれる利用日と、が一致する場合は、当該閲覧済みホテルは利用できないことに相当する。
本実施形態では、検索条件は、ホテルに係る利用日に関する条件を含み、内容情報は、予約されたホテルの利用日を示すので、表示制御部204は、予約されたホテルの利用日と、閲覧済みホテルに関連付けられた検索条件が示す利用日と、に基づいて、利用できない閲覧済みホテルを特定することになる。例えば、表示制御部204は、これらの利用日が一致する場合に、閲覧済みホテルを利用できないと判定する。
また例えば、予約済みのホテルの利用日と、閲覧済みホテルに関連付けられた検索条件に含まれる利用日と、が一致しなかったとしても、これらのホテルの間を移動可能なほどの時間差がない場合は、当該閲覧済みホテルは利用できないことに相当する。
例えば、予約済みのホテルが「東京」にあり、予約日が「2018年4月1日」〜「2018年4月3日」であり、チェックアウトが「2018年4月3日」の11時だったとする。そして、閲覧済みホテルが「ニューヨーク」にあり、予約日が「2018年4月3日」〜「2018年4月8日」であり、チェックインが「2018年4月3日」の15時(日本時間)だったとする。この場合、東京−ニューヨーク間は、4時間では移動できないので、利用日が一致しなかったとしても、表示制御部204は、当該閲覧済みホテルを利用できないホテルとして判定する。
このように、利用日だけでなく、ホテルの場所(ホテル間の距離)や移動手段等も考慮して、利用可能性が判定されてもよい。例えば、表示制御部204は、アイテムデータベースDB1のホテル情報を参照し、予約済みホテルの場所と、閲覧済みホテルの場所と、を特定する。そして、表示制御部204は、これらの場所に基づいて、ホテル間の推定移動時間を取得する。表示制御部204は、予約済みホテルの利用日と、閲覧済みホテルに関連付けられた検索条件に含まれる利用日と、の時間差が上記推定移動時間よりも長い場合には、閲覧済みホテルを利用可能と判定し、時間差が推定移動時間よりも短い場合には、閲覧済みホテルを利用できないと判定する。
なお、推定移動時間の計算に必要なデータは、データ記憶部200に予め記憶させておけばよい。例えば、予約済みホテルの場所と閲覧済みホテルの場所の組み合わせと、推定移動時間と、の関係を、数式形式又はテーブル形式のデータで用意しておいてもよい。また例えば、アイテムデータベースDB1のホテル情報に、ホテルの緯度経度情報を格納しておき、予約済みホテルの緯度経度情報と閲覧済みホテルの緯度経度情報とに基づいて計算されるこれらの距離と、推定移動時間と、の関係を、数式形式又はテーブル形式のデータで用意しておいてもよい。
また例えば、検索システムSは、ユーザ端末10から、閲覧済みホテルの表示要求(例えば、トップ画面G1の表示要求)を受信するので、表示制御部204は、ユーザ端末10から表示要求が受信される前に、閲覧済みホテルの表示制御をするための準備処理を予め実行し、ユーザ端末10から表示要求が受信された場合に、当該準備処理の実行結果に基づいて、表示制御を行うようにしてもよい。
準備処理は、例えば、閲覧済みホテルを表示するか否かを決定する処理であり、本実施形態では、非表示フラグの設定処理である。表示制御部204は、サーバ20が閲覧済みホテルの表示要求する前に、予め非表示フラグの設定処理を実行しておくことになる。非表示フラグの設定処理は、先述した通りである。なお、非表示フラグ以外の情報によって、閲覧済みホテルを表示するか否かを識別させる場合には、準備処理は、当該情報を設定する処理となる。
上記のように、表示制御部204は、内容情報に対応する内容を含む検索条件が閲覧済みホテルに関連付けられている場合に、閲覧済みホテルの表示を制限することになる。内容情報に対応する内容とは、内容情報が示すサブアイテムの値と一致する検索条件を含むことである。本実施形態では、利用日がサブアイテムに相当するので、利用日が一致することが、内容情報に対応する内容を含むことに相当する。
閲覧済みホテルの表示を制限するとは、例えば、閲覧済みホテルを表示させないこと(即ち、表示を禁止すること)であってもよいし、閲覧済みホテルの表示優先度を低くする(順序を後にする)ことであってもよい。他にも例えば、閲覧済みホテルの画像G150のサイズを小さくすること、画像G150の輝度を低くすること、又は、画像G150をグレーアウトする等して色を変えることによって、閲覧済みホテルの表示が制限されてもよい。
[2−3.本実施形態において実行される処理]
実施形態2において実行される処理は、大まかには実施形態1と同様であり、図10の処理が実行される。ただし、S2の処理とS16の処理の詳細は、実施形態1とは異なる。
例えば、実施形態2では、S2の処理が開始されると、図11のS20において、制御部21は、閲覧履歴データベースDB3のうち、非表示フラグがオフのレコードの直近のn個のレコードを参照する。即ち、実施形態2では、非表示フラグがオンのレコードは、S2における取得対象とはならない。このため、非表示フラグがオンのレコードに対応するホテルは、表示領域A15に画像G150が表示されない。以降のS21〜S29の処理は、実施形態1と同様である。
図17は、実施形態2におけるS16の処理の詳細を示す図である。図17に示すように、ユーザ端末10においては、制御部11は、操作部14の検出信号に基づいて、サーバ20に対し、予約処理の実行要求を送信する(S160)。実行要求は、所定形式のデータが送信されることで行われるようにすればよく、例えば、利用日、利用人数、利用者の名前、及び連絡先といった予約データベースDB4に格納される予約情報を含む。これらの情報は、操作部14から入力されてもよいし、検索時に入力された検索条件が記憶部12に保持されることで取得されてもよい。
サーバ20においては、実行要求を受信すると、制御部21は、予約データベースDB4に基づいて、予約処理を実行する(S161)。S161においては、制御部21は、予約データベースDB4に新たなレコードを作成し、当該レコードに、実行要求をしたユーザのユーザID、実行要求に含まれる予約情報、及び予約完了時間を格納する。また、制御部21は、在庫データベースDB2を参照し、ユーザが予約したホテルの部屋の残室数を減少させる。
制御部21は、予約完了画面G4の表示データを生成し、ユーザ端末10に送信する(S162)。予約完了画面G4の表示データは、予約情報に基づいて生成されるようにすればよい。
制御部21は、閲覧履歴データベースDB3に基づいて、非表示フラグを設定する(S163)。S163においては、制御部21は、閲覧履歴データベースDB3のうち、ユーザが予約したホテルのホテルIDが格納されたレコードを特定し、当該レコードに含まれる検索条件を取得する。そして、制御部21は、閲覧履歴データベースDB3のうち、取得した検索条件と一致する検索条件が格納されたレコードを特定し、当該レコードの非表示フラグをオンにする。なお、非表示フラグの初期値はオフであり、他のレコードの非表示フラグはオフのままとなる。
ユーザ端末10においては、表示データを受信すると、制御部11は、予約完了画面G4を表示部15に表示させ(S164)、本処理は終了する。なお、ユーザがボタンB40を選択した場合には、S1の処理が再度実行され、トップ画面G1の表示要求が送信されることになる。ここでは、S163の処理(準備処理の一例)が予め実行されているので、その後に実行されるS2では、S16の処理で非表示フラグがオンになった閲覧済みホテルは、表示領域A15に表示されないようになる。
実施形態2の検索システムSによれば、ユーザによりホテルが予約された場合に、予約内容に関する内容情報と、閲覧済みホテルに関連付けられた検索条件と、に基づいて、閲覧済みホテルの表示が制御され、閲覧済みホテルの一覧をただ表示させるのではなく、内容情報と検索条件とが閲覧済みホテルの表示に影響するので、ユーザインタフェースの利便性を高めることができる。例えば、予約済みホテルの利用日と一致する利用日を検索条件に含む閲覧済みホテルについては、ユーザにとって不要な情報である蓋然性が高いので、このような不要な情報がユーザに提供されることを防止できる。また、不要な閲覧済みホテルの画像G150を表示させないようにする場合には、当該画像G150を表示領域A15に配置するといった不要な処理が実行されないので、サーバ20の処理負荷を減らすことができる。また、ネットワーク上に流れる表示データが減るので、通信負荷を減らすこともできる。
また、閲覧済みホテルが予約された場合に、予約済みの当該ホテルに関連付けられた検索条件と、閲覧済みホテルに関連付けられた検索条件と、に基づいて、閲覧済みアイテムの表示が制御され、検索条件の一部又は全部が共通する閲覧済みホテルが表示されることを防止でき、ユーザインタフェースの利便性を効果的に高めることができる。また、これらの検索条件は、別々のデータベースに格納されているのではなく、同じ閲覧履歴データベースDB3に格納されており、表示制御のために参照するデータベースの数を減らすことで、表示制御処理を高速化するとともに、サーバ20の処理負荷を減らすことができる。
また、検索条件に含まれる複数の条件のうち、利用日や利用人数といった特定の条件を表示制御で利用し、不要な情報をより正確に特定することができるので、ユーザインタフェースの利便性を効果的に高めることができる。また、複数の条件のうちの一部の条件を表示制御で利用する場合には、表示制御のために利用する条件の数を減らし、表示制御処理を高速化するとともに、サーバ20の処理負荷を減らすことができる。
また、予約済みホテルとの関係で利用できない閲覧済みホテルが特定され、当該特定された閲覧済みホテルの表示制御が行われることで、利用できない閲覧済みホテルが表示されることを防止でき、ユーザインタフェースの利便性を効果的に高めることができる。
また、予約済みホテルの利用日と、閲覧済みホテルの利用日と、に基づいて、利用できない閲覧済みホテルが特定されることで、時間的な関係で利用できない閲覧済みホテルが表示されることを防止でき、ユーザインタフェースの利便性を効果的に高めることができる。
また、ユーザ端末10からトップ画面G1の表示要求が受信される前に、非表示フラグの設定処理が予め実行され、ユーザ端末10から表示要求が受信された場合に、予め設定した非表示フラグに基づいて、閲覧済みホテルの表示制御が行われることで、表示制御処理を高速化するとともに、サーバ20の処理負荷を減らすことができる。例えば、表示要求が受信された後に、不要な閲覧済みホテルを特定する場合には、表示要求をしてからトップ画面G1を表示させるまでに時間がかかる。また例えば、多数のユーザからの表示要求が集中した場合には、サーバ20の処理負荷が高まる。この点、検索システムSは、予め非表示フラグの設定をしておくことで、表示要求を受信した後の処理を簡略化できるので、表示要求をしてからトップ画面G1を表示させるまでに時間を少なくし、サーバ20の処理負荷を減らすことができる。
また、予約済みホテルの予約内容に関する内容情報に対応する内容を含む検索条件が関連付けられた閲覧済みホテルの表示が制限され、不要な情報がユーザに提供されることを防止でき、ユーザインタフェースの利便性を効果的に高めることができる。
また、表示領域A15において表示された閲覧済みホテルがユーザにより選択された場合に、当該閲覧済みホテルに関連付けられた検索条件に基づいて、当該閲覧済みホテルのホテル画面G3が表示され、検索条件を再入力するといった手間を省くことができるので、ユーザの操作負担を軽減することができる。
[3.変形例]
なお、本発明は、以上に説明した実施の形態に限定されるものではない。本発明の趣旨を逸脱しない範囲で、適宜変更可能である。
[3−1.実施形態1に係る変形例]
まず、実施形態1に係る変形例を説明する。図18は、実施形態1に係る変形例の機能ブロック図である。図18に示すように、実施形態1に係る変形例では、実施形態1で説明した機能に加えて、経過判定部205、負荷判定部206、及び実行部207が実現される。経過判定部205、負荷判定部206、及び実行部207は、それぞれ経過判定手段、負荷判定手段、及び実行手段の一例である。
(1−1)例えば、実施形態1では、閲覧済みホテルの在庫がない場合に、画像G150上にメッセージM151を表示させる場合を説明したが、在庫がない閲覧済みホテルについては、画像G150自体を表示領域A15に表示させないようにしてもよい。別の言い方をすれば、表示領域A15には、在庫がある閲覧済みホテルの画像G150だけを表示させてもよい。
図19は、変形例(1−1)におけるトップ画面G1の変化の一例を示す図である。図19のトップ画面G1Iは、実施形態1における図5のトップ画面G1Cと同様である。この状態から、例えば、「ホテルB」の残室がなくなったとすると、トップ画面G1Jに示すように、「ホテルB」の画像G150Bが表示領域A15から消去される。なお、ここでの残室がなくなるとは、検索時の検索条件での残室がなくなることである。この点は、以降の説明でも同様である。
続いて、「ホテルE」の残室もなくなったとすると、トップ画面G1Kに示すように、「ホテルE」の画像G150Eが表示領域A15から消去される。その後、「ホテルB」にキャンセルが発生して残室が出ると、トップ画面G1Lに示すように、「ホテルB」の画像G150Bが再び表示領域A15に表示される。
本変形例の表示制御部204は、閲覧済みホテルに関連付けられた検索条件を満たす利用日の在庫がない場合は、閲覧済みホテルを表示させず、閲覧済みホテルに関連付けられた検索条件を満たす利用日の在庫がある場合に、閲覧済みホテルを表示させる。閲覧済みホテルを表示させないとは、閲覧済みホテルを示す画像G150を表示領域A15に表示させないこと、又は、閲覧済みホテルを示す画像G150をユーザ端末10に送信しないことである。
例えば、表示制御部204は、在庫がない閲覧済みホテルを示す画像G150は含まず、在庫がある閲覧済みホテルを示す画像G150を含むトップ画面G1を表示部15に表示させる。別の言い方をすれば、表示制御部204は、在庫がない閲覧済みホテルについては、表示領域A15における表示対象から除外し、在庫がある閲覧済みホテルを、表示領域A15における表示対象とする。
変形例(1−1)によれば、トップ画面G1の表示領域A15において、在庫がない閲覧済みホテルは表示させず、在庫がある閲覧済みホテルを表示させることで、表示領域A15における閲覧済みホテルの表示の有無によって、閲覧済みホテルの在庫の有無を把握できるので、ユーザインタフェースの利便性を効果的に高めることができる。また、在庫がない閲覧済みホテルが表示されないので、在庫がない閲覧済みホテルが表示領域A15から選択されてしまい、ホテル画面G3が表示されても予約ができないといったことをより効果的に防止することができる。
(1−2)また例えば、閲覧済みホテルの在庫がなくなった後に、当該閲覧済みホテルにキャンセルが発生し、検索時に入力した利用日で空きが発生した場合に、表示領域A15において、当該閲覧済みホテルが優先的に表示されるようにしてもよい。
図20は、変形例(1−2)におけるトップ画面G1の変化の一例を示す図である。図20のトップ画面G1Mは、図5のトップ画面G1C及び図19のトップ画面G1Iと同様である。この状態から、例えば、「ホテルA」の残室がなくなったとすると、トップ画面G1Nに示すように、「ホテルA」の画像G150A上に、「SOLD OUT」といったメッセージM151Aが表示され、残室がなくなったことが通知される。なお、メッセージM151Aを表示させるのではなく、変形例(1−1)のように、「ホテルA」の画像G150Aが表示領域A15から消去されるようにしてもよい。
続いて、「ホテルA」にキャンセルが発生し、検索時に入力した利用日に空きが発生すると、トップ画面G1Oに示すように、在庫がない状態からある状態になったことを示すメッセージM152Aが表示される。例えば、メッセージM152Aは、「ホテルA」の画像G150Aを指し示すようにして表示される。メッセージM152Aは、画像G150Aを優先的に表示するための画像であり、例えば、画像G150A上に表示されてもよいし、画像G150Aの一部として表示されてもよい。
本変形例の表示制御部204は、閲覧済みホテルに関連付けられた検索条件を満たす利用日の在庫がない状態から在庫がある状態になった場合に、閲覧済みホテルを優先表示させる。なお、ここでは、在庫の有無の判定結果を示す情報が閲覧履歴データベースDB3に格納されており、表示制御部204は、当該情報に基づいて、在庫がない状態から在庫がある状態になったか否かを判定できるものとする。
在庫がない状態から在庫がある状態になるとは、在庫が戻ること、在庫数が閾値未満の状態から閾値以上の状態に変化すること、又は、在庫がないと判定された後に在庫があると判定されることである。表示制御部204は、閲覧済みホテルの在庫が閾値(例えば、1)未満になった後に、当該在庫が閾値以上になった場合に、在庫がない状態から在庫がある状態になったと判定する。
優先表示とは、画像G150を優先的に表示させることである。別の言い方をすれば、優先表示は、強調表示ということもでき、画像G150を目立つようにすることである。例えば、画像G150に関連付けて別の画像(例えば、メッセージM152や所定のアイコン等)を表示させること、又は、表示態様若しくは表示位置を変えることは、優先表示の一例である。
例えば、表示制御部204は、画像G150に関連付けてメッセージM152を表示させることによって、画像G150を優先表示する。また例えば、表示制御部204は、画像G150のサイズを大きくすることによって、画像G150を優先表示する。また例えば、表示制御部204は、画像G150の色又は模様を変えることによって、画像G150を優先表示する。また例えば、表示制御部204は、画像G150の輝度を上げることによって、画像G150を優先表示する。また例えば、表示制御部204は、画像G150を表示領域A15の1番目(左上)に移動することによって、画像G150を優先表示する。
変形例(1−2)によれば、閲覧済みホテルの残室がない状態からある状態になった場合に、当該閲覧済みホテルを優先表示させることで、空きが発生した閲覧済みホテルを把握しやすくなり、ユーザインタフェースの利便性を効果的に向上させることができる。
(1−3)また例えば、閲覧済みホテルの検索で用いられた利用日が経過した場合には、在庫の有無を判定しないようにしてもよいし、当該閲覧済みホテルを示す画像G150は、表示領域A15に表示させないようにしてもよい。別の言い方をすれば、表示領域A15には、閲覧済みホテルの検索で用いられた利用日が経過していない閲覧済みホテルの画像G150だけを、在庫の有無の判定対象としてもよいし、画像G150の表示対象としてもよい。
図21は、変形例(1−3)におけるトップ画面G1の変化の一例を示す図である。図21のトップ画面G1Pでは、画像G150L,G150Mにそれぞれ示す「ホテルL」と「ホテルM」は、それぞれ同じ利用日を検索条件にして検索されたホテルである。ここでは、これら2つのホテルの検索で用いられた利用日を、「2018年4月1日」〜「2018年4月3日」とする。
一方、画像G150N〜G150Qにそれぞれ示す「ホテルN」、「ホテルO」、「ホテルP」、及び「ホテルQ」は、それぞれ同じ利用日を検索条件にして検索されたホテルである。ここでは、これら4つのホテルの検索条件で用いられた利用日を、「2018年5月15日」〜「2018年5月18日」とする。
例えば、上記2つの検索条件が示す利用日が何れも経過していない場合には、トップ画面G1Pに示すように、画像G150L〜G150Mが表示領域A15に表示される。その後、「ホテルL」と「ホテルM」の検索で用いられた利用日の最終日である「2018年4月3日」が経過すると、トップ画面G1Qに示すように、画像G150L,G150が消去される。
更に時間が経過し、「ホテルN」、「ホテルO」、「ホテルP」、及び「ホテルQ」の検索で用いられた利用日の最終日である「2018年5月18日」が経過すると、トップ画面G1Rに示すように、画像G150N〜G150Qが消去される。
なお、ここでは、利用日が複数日にまたがる場合に、最終日が経過したことを条件として、画像G150が消去される態様を説明したが、利用日の初日が経過した場合に画像G150が消去されるようにしてもよい。他にも例えば、初日から最終日までの間の何れかの日が経過した場合に、画像G150が消去されるようにしてもよい。
本変形例の検索システムSは、経過判定部205を含む。経過判定部205は、制御部21を主として実現される。経過判定部205は、閲覧済みホテルに関連付けられた検索条件が示す利用日が経過したか否かを判定する。経過判定部205は、リアルタイムクロック等から現在日時を取得し、現在日時と、閲覧済みアイテムに関連付けられた検索条件が示す利用日と、を比較することによって、利用日が経過したか否かを判定する。
利用日が経過するとは、現在日時が利用日よりも後になることである。先述したように、利用日が複数日にまたがる場合(利用日が1日ではなく、複数日である場合)には、経過判定部205は、現在日時が初日よりも後になった場合に、利用日が経過したと判定してもよいし。現在日時が最終日よりも後になった場合に、利用日が経過したと判定してもよい。他にも例えば、経過判定部205は、現在日時が、初日から最終日までの間の何れかの日よりも後になった場合に、利用日が経過したと判定してもよい。
表示制御部204は、閲覧済みホテルに関連付けられた検索条件を満たす利用日の在庫情報と、経過判定部205の判定結果と、に基づいて表示制御を行う。例えば、表示制御部204は、利用日が経過した閲覧済みホテルの表示を制限する。制限の意味は、実施形態2で説明した通りである。例えば、表示制御部204は、利用日が経過した閲覧済みホテルの表示を制限し、利用日が経過していない閲覧済みホテルは制限せずに表示させる。
また例えば、表示制御部204は、利用日が経過した閲覧済みホテルの表示を制限しないが、在庫情報に基づく表示制御の対象から除外してもよい。表示制御部204は、閲覧履歴データベースDB3に格納された閲覧済みホテルのうち、検索条件が示す利用日が経過していない閲覧済みホテルについては、在庫情報に基づく表示制御の対象とし、検索条件が示す利用日が経過した閲覧済みホテルについては、在庫情報に基づく表示制御の対象とする。
変形例(1−3)によれば、閲覧済みホテルの検索条件に含まれる利用日が経過したか否かの判定結果に基づいて、閲覧済みホテルの表示制御が行われ、利用日が経過した不要な情報がユーザに提供されることを防止し、ユーザインタフェースの利便性を効果的に高めることができる。また、利用日が経過した不要な閲覧済みホテルの在庫判定をしないようにすることで、表示制御処理を高速化しつつ、サーバ20の処理負荷を軽減することができる。
(1−4)また例えば、サーバ20の処理負荷が高い場合には、閲覧済みホテルの在庫の有無を知らせるための表示制御を待機し、サーバ20の処理負荷が低くなった場合に、当該表示制御が実行されるようにしてもよい。この場合、サーバ20は、ユーザ端末10からトップ画面G1の表示要求を受信した時点の処理負荷が高い場合には、閲覧済みホテルの画像G150だけを先に送信し、処理負荷が低くなった場合に在庫情報を参照し、閲覧済みホテルの在庫がなくなっていれば、メッセージM151を追加で送信してもよい。
本変形例の検索システムSは、負荷判定部206と実行部207を含む。負荷判定部206と実行部207は、それぞれ制御部21を主として実現される。負荷判定部206は、表示制御部204を含むコンピュータの処理負荷が閾値以上であるか否かを判定する。表示制御部204を含むコンピュータは、表示制御部204を実現するコンピュータであり、ここでは、サーバ20である。
負荷判定部206は、サーバ20の処理負荷を取得し、閾値以上であるか否かを判定する。処理負荷としては、コンピュータの負荷に関する情報であればよく、例えば、CPU使用率、メモリ使用率、又は単位時間当たりの通信量等である。これらの取得方法自体は、公知の種々の手法を適用可能であり、例えば、所定のコマンド(例えば、Linux(登録商標)におけるtopコマンド)を利用してCPU使用率やメモリ使用率が取得されてもよいし、単位時間当たりのデータ受信量が計測されることで通信量が取得されてもよい。
なお、閾値は、予め定められた数値であればよく、例えば、CPU使用率又はメモリ使用率であれば、50%〜100%の間の任意の数値を閾値として用いてもよいし、通信量であれば、1秒当たりのデータ受信量が数十メガバイト程度の数値を閾値として用いてもよい。
実行部207は、負荷判定部206により処理負荷が閾値未満であると判定された場合に、サーバ20の表示制御部204に、在庫情報に基づく表示制御を実行させる。例えば、実行部207は、負荷判定部206により処理負荷が閾値以上であると判定された場合は、表示制御部204に対し、在庫情報に基づく表示制御の実行を待機させ、負荷判定部206により処理負荷が閾値以上であると判定された場合に、表示制御部204に対し、在庫情報に基づく表示制御の実行を指示する。
変形例(1−4)によれば、サーバ20の処理負荷が閾値未満であると判定された場合に、在庫情報に基づく閲覧済みホテルの表示制御が実行されることで、サーバ20の処理負荷を効果的に軽減することができる。また、閲覧済みホテルの画像G150だけを先にユーザ端末10に送信しておき、在庫の有無を示すメッセージM151を後から送信する場合には、トップ画面G1をより早く表示させることができる。
(1−5)また例えば、閲覧済みホテルの検索で用いられた利用日で在庫がない場合には、検索条件に含まれる利用日と利用人数のうち、利用日だけを変更して在庫の有無を判定し、在庫がある別の利用日をユーザに提案してもよい。なお、別の利用日としては、検索条件に含まれる利用日付近(例えば、1日以内〜数週間以内)とした方が好ましいが、当該利用日付近で在庫がなければ、在庫の有無を判定する範囲を徐々に広げてもよい。
図22は、変形例(1−5)におけるトップ画面G1の変化の一例を示す図である。図22のトップ画面G1Sは、図5のトップ画面G1C、図19のトップ画面G1I、及び図19のトップ画面G1Mと同様である。ここでは、例えば、「ホテルA」〜「ホテルE」の検索で用いられた利用日を、「2018年4月1日」〜「2018年4月3日」とする。
この状態から、例えば、「ホテルA」の上記利用日での残室がなくなったとすると、トップ画面G1Tに示すように、「ホテルA」の画像G150A上に、「SOLD OUT」といったメッセージM151Aが表示される。一方、他の利用日で残室がある場合には、その旨を示すメッセージM153Aが表示される。例えば、「2018年4月3日」〜「2018年4月5日」に旅行プランを変更すれば「ホテルA」の残室がある場合に、メッセージM153Aが表示される。
表示制御部204は、閲覧済みホテルに関連付けられた検索条件を満たす利用日の在庫情報が示す在庫がない場合に、在庫がある他の利用日に基づいて表示制御を行う。例えば、表示制御部204は、閲覧済みホテルに関連付けられた検索条件を満たす利用日の在庫情報が示す在庫がない場合に、利用日を変更して在庫の有無を判定する。
変更後の利用日は、元々の利用日と異なる日であればよいが、ここでは、1日ずつずらして在庫の有無が判定されるものとする。表示制御部204は、在庫がある利用日を発見するまで、利用日の変更と在庫の有無の判定を繰り返してもよいし、所定個数の利用日について在庫の有無を判定しても、在庫がある利用日を発見できなかった場合には、利用日の変更と在庫の有無の判定を終了してもよい。
例えば、表示制御部204は、在庫がある他の利用日を発見した場合には、その旨を示すメッセージM153を表示させる。メッセージM153は、画像G150に関連付けて表示すればよく、図22のように、画像G150を指し示すようにして表示させてもよいし、画像G150上に表示させてもよい。また例えば、表示制御部204は、在庫がある他の利用日を発見した場合に、メッセージM153を表示させるのではなく、画像G150内にその旨を表示させてもよい。
変形例(1−5)によれば、閲覧済みホテルの残室がない場合に、残室がある他の利用日に基づいて表示制御が行われ、残室がある他の利用日をユーザに提案することができるので、ユーザインタフェースの利便性を効果的に高めることができる。また、ユーザが、残室がある他の利用日を自分で再検索するといった手間を省くことができる。サーバ20からしてみれば、ユーザによる再検索要求を何度も受け付けて、そのたびに検索処理を実行することがなくなるので、サーバ20の処理負荷を減らすとともに、ネットワーク上で送受信される検索要求や検索結果を減らすことができるので、通信負荷を減らすこともできる。
(1−6)また例えば、各ホテルは、ユーザによる予約が可能なので、実施形態2の処理を実施形態1に適用し、ユーザが予約したホテルと検索条件が同じ閲覧済みホテルについては、在庫の有無を判定する対象から除外してもよい。即ち、閲覧済みホテルのうち、予約済みのホテルと検索条件が異なる閲覧済みホテルについてだけ、在庫の有無が判定され、予約済みのホテルと検索条件が同じ閲覧済みホテルについては、在庫の有無を判定しないようにしてもよい。
本変形例では、表示制御部204は、ユーザにより予約されたホテルの予約内容に関する内容情報に更に基づいて、表示制御を行う。ここでは、実施形態2と同様に、予約済みホテルの検索で用いられた検索条件が内容情報に相当する場合を説明する。
例えば、表示制御部204は、閲覧履歴データベースDB3に基づいて、予約済みホテルに関連付けられた検索条件を取得し、当該検索条件と同じ検索条件の他の閲覧済みホテルについては、在庫情報に基づく表示制御の対象外とする。一方、表示制御部204は、予約済みホテルに関連付けられた検索条件と同じ検索条件の他の閲覧済みホテルについては、在庫情報に基づいて表示制御を行う。表示制御の内容自体は、実施形態1で説明した通りである。
変形例(1−6)によれば、予約済みホテルの予約内容に関する内容情報に基づいて、閲覧済みホテルの表示制御が行われることで、閲覧済みホテルの一覧をただ表示させるのではなく、内容情報と検索条件とが閲覧済みホテルの表示に影響するので、ユーザインタフェースの利便性を高めることができる。例えば、予約済みホテルの利用日と一致する利用日を検索条件に含む閲覧済みホテルについては、ユーザにとって不要な情報である蓋然性が高いので、このような不要な情報がユーザに提供されることを防止できる。また、予約済みホテルとの関係で不要な閲覧済みホテルの在庫判定が行われなくなり、在庫判定の対象となる閲覧済みホテルを絞ることができるので、表示制御処理を高速化しつつ、サーバ20の処理負荷を軽減することができる。
(1−7)また例えば、ホテル検索をしている間に、ユーザの予定が変わり、検索条件が変更されることがある。この場合、変更後の検索条件とは異なる検索条件(古い検索条件)の閲覧済みホテルについては、ユーザが興味を失っている可能性があるので、在庫の有無を判定しないようにしてもよい。即ち、ユーザが入力した最新の検索条件と異なる検索条件の閲覧済みホテルについては、在庫の有無を判定しないようにしてもよい。
本変形例では、データ記憶部200は、ユーザ端末10から受信した検索条件を記憶する。例えば、検索部201は、ホテル検索を実行した場合に、ユーザが入力した検索条件を、当該ユーザのユーザIDに関連付けてデータ記憶部200に記録する。データ記憶部200には、最新の検索条件だけが記録されてもよいし、ユーザが入力した検索条件が時系列的に記録されてもよい。
表示制御部204は、ユーザにより入力された検索条件が変更された場合に、変更後の検索条件に更に基づいて表示制御を行う。例えば、表示制御部204は、閲覧済みホテルのうち、最新の検索条件と同じ検索条件の閲覧済みホテルについては、在庫情報に基づいて表示制御を行い、最新の検索条件とは異なる検索条件の閲覧済みホテルについては、在庫情報に基づく表示制御の対象外とする。
変形例(1−7)によれば、検索条件が変更された場合に、変更後の検索条件に基づいて表示制御が行われ、変更後の検索条件との関係で、不要な在庫判定が行われなくなり、在庫判定の対象となる閲覧済みホテルを絞ることができるので、表示制御処理を高速化しつつ、サーバ20の処理負荷を軽減することができる。
[3−2.実施形態2に係る変形例]
次に、実施形態2に係る変形例を説明する。図23は、実施形態2に係る変形例の機能ブロック図である。図23に示すように、実施形態2に係る変形例では、実施形態2で説明した機能に加えて、経過判定部205が実現される。
(2−1)例えば、実施形態2では、ユーザが予約したホテルと同じ検索条件の閲覧済みホテルは、表示領域A15に表示させないようにしたが、表示領域A15には、航空券、レンタカー、又はバスの各々の閲覧履歴を表示させてもよく、これらについては、検索条件が同じであった場合の方が、ユーザが必要としている情報である蓋然性が高い。
例えば、ユーザが「東京」のホテルを、「2018年4月1日」〜「2018年4月3日」の利用日で予約した場合に、航空券、レンタカー、又はバスを合わせて予約する可能性がある。この利用日において、ユーザが、航空券、レンタカー、又はバスを検索して閲覧していた場合には、これらの閲覧履歴を優先表示させてもよい。優先表示の意味は、実施形態1の変形例で説明した通りである。
図24は、変形例(2−1)におけるトップ画面G1の変化の一例を示す図である。図24のトップ画面G1Uは、図13のトップ画面G1Gと同様である。この状態で、ユーザ「ホテルF」を予約すると、トップ画面G1Vに示すように、同じ検索条件の「ホテルG」と「ホテルH」が消去され、「ホテルF」と検索条件の利用日が一致する「東京−札幌 航空券」を示す画像G154が優先表示される。
例えば、画像G154が示す航空券は、ユーザが、出発日が「2018年4月1日」であり、出発地が「札幌」であり、かつ、到着地が「東京」といった検索条件を入力して検索し、航空券の詳細のページを閲覧したものである。また例えば、画像G154が示す航空券は、出発日が「2018年4月3日」であり、出発地が「東京」であり、かつ、到着地が「札幌」といった検索条件を入力して検索し、航空券の詳細のページを閲覧したものであってもよい。この航空券の出発日は、予約済みの「ホテルF」の利用日と一致し、かつ、ホテルとは異なる種類(即ち、提供者が異なるサービス)の利用日なので、本変形例では、積極的に表示される。
なお、ここでは、航空券を一例として説明したが、レンタカー又はバスについても、「ホテルF」の利用日と一致する利用日又は出発日を検索条件にして検索され、ユーザが閲覧していた場合には、これら閲覧済みのレンタカー又はバスの画像が表示領域A15に表示されるようにしてもよい。
本変形例の表示制御部204は、内容情報に対応する内容を含む検索条件が閲覧済みアイテムに関連付けられている場合に、閲覧済みアイテムを優先表示する。内容情報に対応する内容の意味は、実施形態2で説明した通りである。表示制御部204は、予約済みアイテムとは異なる種類の閲覧済みアイテム(即ち、予約済みアイテムとは提供者が異なる閲覧済みアイテム)について、内容情報に対応する内容を含む検索条件が関連付けられている場合に優先表示をする。
例えば、表示制御部204は、予約済みのホテルの利用日と一致する利用日を含む検索条件が、閲覧済みの航空券、レンタカー、又はバスに関連付けられている場合に、当該閲覧済みの航空券、レンタカー、又はバスを優先表示する。また例えば、表示制御部204は、予約済みの航空券の出発日又は到着日と一致する利用日を含む検索条件が、閲覧済みのホテル、レンタカー、又はバスに関連付けられている場合に、当該閲覧済みのホテル、レンタカー、又はバスを優先表示する。
また例えば、表示制御部204は、予約済みのレンタカーの出発日又は返却日と一致する利用日を含む検索条件が、閲覧済みのホテル、航空券、又はバスに関連付けられている場合に、当該閲覧済みのホテル、航空券、又はバスを優先表示する。また例えば、表示制御部204は、予約済みのバスの出発日又は到着日と一致する利用日を含む検索条件が、閲覧済みのホテル、航空券、又はレンタカーに関連付けられている場合に、当該閲覧済みのホテル、航空券、又はレンタカーを優先表示する。
変形例(2−1)によれば、予約済みホテルの予約内容に関する内容情報に対応する内容を含む検索条件が関連付けられた閲覧済み航空券等が優先表示され、ユーザにとって有益な情報を提供するとともに、当該航空券の予約をしやすくなるので、ユーザインタフェースの利便性を効果的に高めることができる。
(2−2)また例えば、実施形態2では、ユーザが予約したホテルに関連付けられた検索条件が内容情報に相当する場合を説明したが、内容情報は、ユーザによりアイテムが予約又は購入された場合に、ユーザにより指定された予約内容を格納するためのデータベースに格納された情報であってもよい。ここでは、当該データベースを予約データベースDB4とするが、他のデータベースであってもよい。
本変形例の表示制御部204は、予約データベースDB4に格納された内容情報と、閲覧済みアイテムに関連付けられた検索条件と、に基づいて、表示制御を行う。例えば、表示制御部204は、予約データベースDB4のうち、トップ画面G1の表示要求をしたユーザのユーザIDが格納されたレコードを特定し、当該レコードの予約情報を取得する。そして、表示制御部204は、当該予約情報に含まれる利用日や利用人数といった情報を、内容情報として取得する。内容情報が取得された以降の処理は、実施形態2で説明した通りである。
変形例(2−2)によれば、予約データベースDB4に格納された予約済みホテルの予約情報と、閲覧済みホテルの検索条件と、に基づいて、閲覧済みアイテムの表示が制御され、検索条件の入力後に予約内容が変更した場合であっても、実際の予約日に応じて不要な情報を提供しないようにすることができるので、ユーザインタフェースの利便性を効果的に高めることができる。
(2−3)また例えば、ユーザが予約したホテルの利用日が経過した場合には、利用日だけを変えて似たようなホテルをユーザが利用することがあるので、検索条件を同じとする閲覧済みホテルを再び表示領域A15に表示させてもよい。
図25は、変形例(2−3)におけるトップ画面G1の変化の一例を示す図である。図25のトップ画面G1Wは、図13のトップ画面G1G及び図24のトップ画面G1Uと同様である。この状態で、ユーザが「ホテルF」を予約すると、実施形態2と同様の処理により、トップ画面G1Xに示すように、同じ検索条件の「ホテルG」と「ホテルH」が消去される。その後、ユーザが「ホテルF」の利用日が経過すると、トップ画面G1Yに示すように、「ホテルF」、「ホテルG」、及び「ホテルH」の画像G150F〜G150Hが再び表示される。
本変形例の検索システムSは、経過判定部205を含む。経過判定部205は、実施形態1の変形例と同様の機能を有していてもよいが、ここでは、閲覧済みホテルに関連付けられた検索条件が示す利用日と、予約されたホテルの利用日と、の少なくとも一方が経過したか否かを判定する。経過の意味は、実施形態1の変形例で説明した通りである。例えば、経過判定部205は、リアルタイムクロック等から取得した現在日時に基づいて、閲覧済みホテルに関連付けられた検索条件が示す利用日が経過したか否かを判定したり、予約済みホテルの利用日が経過したか否かを判定したりする。
表示制御部204は、経過判定部205の判定結果に更に基づいて、表示制御を行う。例えば、表示制御部204は、経過判定部205により利用日が経過していないと判定された場合には、閲覧済みホテルの表示の制限を継続し、経過判定部205により利用日が経過していないと判定された場合には、閲覧済みホテルの表示の制限を解除し、当該閲覧済みホテルを表示させる。
変形例(2−3)によれば、予約済みホテルの利用日と、閲覧済みホテルの利用日と、の少なくとも一方が経過したか否かの判定結果に基づいて表示制御が行われ、利用日が経過した不要な情報がユーザに提供されることを防止し、ユーザインタフェースの利便性を効果的に高めることができる。また、利用日が経過した不要な閲覧済みホテルについてまで表示制御をしないようにすることで、表示制御処理を高速化しつつ、サーバ20の処理負荷を軽減することができる。
[3−3.その他変形例]
例えば、実施形態1と実施形態2を組み合わせてもよい。また例えば、実施形態1の変形例と、実施形態2の変形例と、を組み合わせてもよい。
また例えば、旅行予約サービスで取り扱われるホテルなどは、旅行商品と呼ばれることもあるので、ユーザがホテルなどを予約することは、商品を購入することに相当してもよい。この場合、実施形態1−2において「予約」と記載した箇所は、「購入」と読み替えることができる。検索システムSにおけるアイテムは、予約又は購入が可能なアイテムであればよい。
また例えば、主にホテル予約の場面で検索システムSが利用される場合を説明したが、航空券予約、レンタカー予約、バス予約、列車予約、レストラン予約、又はオプションツアー予約の場合にも同様の処理を適用可能である。例えば、表示領域A15には、ユーザが閲覧したホテル、航空機、レンタカー、及びバスが混在して表示されてもよいし、ユーザがホテル予約をする場合にはホテルの閲覧履歴だけが表示され、航空機予約をする場合には航空機の閲覧履歴だけが表示されるといったように、トップ画面G1から行われる予約の種類に応じた閲覧履歴が表示されるようにしてもよい。
また例えば、実施形態1の処理を航空券予約に適用した場合、閲覧済みの航空券に関連付けられた検索条件を満たす出発日の在庫情報に基づいて、閲覧済みの航空券の表示が制御される。また例えば、実施形態1の処理をレンタカー予約に適用した場合、閲覧済みのレンタカー会社に関連付けられた検索条件を満たす出発日の在庫情報に基づいて、閲覧済みのレンタカー会社の表示が制御される。また例えば、実施形態1の処理をバス予約に適用した場合、閲覧済みのバスに関連付けられた検索条件を満たす出発日の在庫情報に基づいて、閲覧済みのバスの表示が制御される。
また例えば、実施形態1の処理を列車予約に適用した場合、閲覧済みの列車に関連付けられた検索条件を満たす出発日の在庫情報に基づいて、閲覧済みの列車の表示が制御される。また例えば、実施形態1の処理をレストラン予約に適用した場合、閲覧済みのレストランに関連付けられた検索条件を満たす利用日の在庫情報に基づいて、閲覧済みのレストランの表示が制御される。また例えば、実施形態1の処理をオプションツアー予約に適用した場合、閲覧済みのオプションツアーに関連付けられた検索条件を満たす利用日の在庫情報に基づいて、閲覧済みのオプションツアーの表示が制御される。
また例えば、実施形態2の処理を航空券予約に適用した場合、予約済み航空券の利用日と、閲覧済み航空券の利用日と、に基づいて、閲覧済み航空券の表示が制御される。また例えば、実施形態2の処理をレンタカー予約に適用した場合、予約済みレンタカーの利用日と、予約済みレンタカーの利用日と、に基づいて、閲覧済みレンタカーの表示が制御される。また例えば、実施形態2の処理をバス予約に適用した場合、予約済みバスの利用日と、閲覧済みバスの利用日と、に基づいて、閲覧済みバスの表示が制御される。
また例えば、実施形態2の処理を列車予約に適用した場合、予約済み列車の利用日と、閲覧済み列車の利用日と、に基づいて、閲覧済み列車の表示が制御される。また例えば、実施形態2の処理をレストラン予約に適用した場合、予約済みレストランの利用日と、閲覧済みレストランの利用日と、に基づいて、閲覧済みレストランの表示が制御される。また例えば、実施形態2の処理をオプションツアー予約に適用した場合、予約済みツアーの利用日と、閲覧済みツアーの利用日と、に基づいて、閲覧済みツアーの表示が制御される。
また例えば、検索システムSを旅行予約サービスで利用する場面を説明したが、他の任意のサービスで利用されるようにしてもよい。
例えば、検索システムSを電子商取引で利用する場合には、商品がアイテムに相当し、商品のインデックスとなりうる情報がサブアイテムに相当する。例えば、サブアイテムは、商品のカテゴリ、サイズや色などの属性、商品タイトル、又は商品説明に含まれるキーワードといった情報となる。例えば、衣料品・家具・家電などの商品は、サイズや色などの属性ごとに在庫情報を有することがあるので、実施形態1の処理を電子商取引に適用した場合、閲覧済み商品に関連付けられた検索条件を満たす属性の在庫情報に基づいて、閲覧済み商品の表示が制御されるようにしてもよい。
また例えば、実施形態2の処理を電子商取引に適用した場合、内容情報は、購入内容に関する情報となる。例えば、購入された商品の属性、カテゴリ、商品タイトル、及び商品説明といった情報は、内容情報の一例である。この場合、表示制御部204は、ユーザにより商品が購入された場合に、購入内容に関する内容情報と、閲覧済み商品に関連付けられた検索条件と、に基づいて、閲覧済み商品の表示を制御することになる。
また例えば、ユーザにより購入された商品が閲覧済み商品の1つである場合には、内容情報は、購入された閲覧済み商品の検索で用いられた検索条件となる。また例えば、内容情報は、複数のサブアイテムのうち、購入内容に関する少なくとも1つのサブアイテムに関する情報となり、例えば、サイズや色といった属性である。サイズ違いの商品や色違いの商品があった場合に、内容情報は、どのサイズの商品が購入されたかを示したり、どの色の商品が購入されたかを示したりすることになる。
また例えば、表示制御部204は、ユーザにより購入された商品との関係で利用できない商品を特定し、当該特定した閲覧済み商品の表示制御が行われるようにしてもよい。また例えば、内容情報は、ユーザにより商品が購入された場合に、ユーザにより指定された購入内容を格納するためのデータベースに格納された情報であってもよい。
また例えば、検索システムSを、コンサートやイベントなどにおけるチケット販売で利用する場合には、チケットがアイテムに相当し、チケットのインデックスとなりうる公演日や席種といった情報がサブアイテムに相当する。例えば、実施形態1の処理をチケット販売に適用する場合には、閲覧済みチケット(閲覧済み公演)に関連付けられた検索条件を満たす公演日・席種の在庫情報に基づいて、閲覧済みチケットの表示が制御されるようにしてもよい。また例えば、実施形態2の処理をチケット販売に適用する場合には、ユーザによりチケットが購入された場合に、購入済みチケット(購入済み公演)の公演日と、閲覧済みチケットに関連付けられた公演日と、に基づいて、閲覧済みチケットの表示が制御されるようにしてもよい。
また例えば、検索システムSを、セミナーなどのイベント予約で利用する場合には、イベントがアイテムに相当し、イベントのインデックスとなりうる開催日といった情報がサブアイテムに相当する。例えば、実施形態1の処理をイベント予約に適用する場合には、閲覧済みイベントに関連付けられた検索条件を満たす開催日の在庫情報(残席情報)に基づいて、閲覧済みイベントの表示が制御されるようにしてもよい。また例えば、実施形態2の処理をイベント予約に適用する場合には、ユーザによりイベントが予約された場合に、予約済みイベントの開催日と、予約済みイベントに関連付けられた開催日と、に基づいて、予約済みイベントの表示が制御されるようにしてもよい。
また例えば、閲覧部202は、ユーザ端末10において実現されてもよい。この場合、閲覧部202は、制御部11を主として実現される。閲覧部202は、ユーザにより選択されたアイテムの表示データをサーバ20から受信し、当該表示データに基づいて、ユーザにより選択されたアイテムを閲覧させる。また例えば、表示制御部204が実行する処理は、ユーザ端末10の表示制御部102で実行されてもよい。即ち、表示制御に係る主な処理が、ユーザ端末10において実行されてもよい。例えば、実施形態1において、表示制御部102は、サーバ20から在庫情報を受信し、メッセージM151を表示させたり、画像G150を表示させるか否かを決定したりしてもよい。また例えば、実施形態2において、表示制御部102は、サーバ20から内容情報を受信し、閲覧済みアイテムの表示を制御してもよい。
また例えば、ユーザ端末10とサーバ20とで機能が分担されてもよい。例えば、ユーザ端末10で閲覧部202が実現され、他の機能がサーバ20で実現されてもよい。他にも例えば、ユーザ端末10で表示制御部204が実現され、他の機能がサーバ20で実現されてもよい。他にも例えば、データ記憶部200で記憶されるものとして説明したデータは、サーバ20とは異なるデータベースサーバによって記憶されてもよいし、検索システムSの外部にあるデータベースサーバによって記憶されていてもよい。