JP2020074128A - 検索システム、検索方法、及びプログラム - Google Patents

Abstract

【課題】ユーザインタフェースの利便性を高める。【解決手段】検索システム（Ｓ）は、予約又は購入が可能なアイテムの検索システムであり、検索手段（２０１）は、ユーザにより入力された検索条件に基づいて、アイテム検索を実行する。閲覧手段（２０２）は、検索手段（２０１）の検索結果の中から、ユーザにより選択されたアイテムを閲覧させる。関連付け手段（２０３）は、閲覧済みアイテムと、検索で用いられた検索条件と、を関連付けて記憶手段（２００）に記録する。表示制御手段（２０４）は、ユーザによりアイテムが予約又は購入された場合に、予約内容又は購入内容に関する内容情報と、閲覧済みアイテムに関連付けられた検索条件と、に基づいて、閲覧済みアイテムの表示を制御する。【選択図】図６

Description

本発明は、検索システム、検索方法、及びプログラムに関する。

従来、アイテムの検索をする技術が知られている。例えば、特許文献１には、アイテムの一例であるホテルの予約システムにおいて、ユーザにより入力された利用日・利用人数・宿泊地といった検索条件に基づいてホテルを検索し、ユーザが閲覧したホテルの履歴を閲覧履歴として記録することが記載されている。

特開第２０１６−１３９９３１号公報

特許文献１のような予約システムには、ユーザが閲覧したホテルの履歴を示す閲覧履歴リストを表示させるシステムも存在する。しかしながら、このようなシステムでは、ホテルの予約が完了しても、当該ホテルの検索時に比較した他のホテルが閲覧履歴リストに表示されたままとなる。これら他のホテルは、予約済みのホテルと同じ検索条件で検索したホテルであり、不要な情報であることが多い。特許文献１の閲覧履歴リストには、このような不要な情報が残るので、利便性の高いユーザインタフェースとはなっていなかった。

本発明は上記課題に鑑みてなされたものであって、その目的は、ユーザインタフェースの利便性を高めることが可能な検索システム、検索方法、及びプログラムを提供することである。

上記課題を解決するために、本発明に係る検索システムは、予約又は購入が可能なアイテムの検索システムであって、ユーザにより入力された検索条件に基づいて、アイテム検索を実行する検索手段と、前記検索手段の検索結果の中から、前記ユーザにより選択されたアイテムを閲覧させる閲覧手段と、閲覧済みアイテムと、検索で用いられた検索条件と、を関連付けて記憶手段に記録する関連付け手段と、前記ユーザによりアイテムが予約又は購入された場合に、予約内容又は購入内容に関する内容情報と、前記閲覧済みアイテムに関連付けられた検索条件と、に基づいて、前記閲覧済みアイテムの表示を制御する表示制御手段と、を含むことを特徴とする。

本発明に係る検索方法は、予約又は購入が可能なアイテムの検索方法であって、ユーザにより入力された検索条件に基づいて、アイテム検索を実行する検索ステップと、前記検索ステップの検索結果の中から、前記ユーザにより選択されたアイテムを閲覧させる閲覧ステップと、閲覧済みアイテムと、検索で用いられた検索条件と、を関連付けて記憶手段に記録する関連付けステップと、前記ユーザによりアイテムが予約又は購入された場合に、予約内容又は購入内容に関する内容情報と、前記閲覧済みアイテムに関連付けられた検索条件と、に基づいて、前記閲覧済みアイテムの表示を制御する表示制御ステップと、を含むことを特徴とする。

本発明に係るプログラムは、ユーザにより入力された検索条件に基づいて、アイテム検索を実行する検索手段、前記検索手段の検索結果の中から、前記ユーザにより選択されたアイテムを閲覧させる閲覧手段、閲覧済みアイテムと、検索で用いられた検索条件と、を関連付けて記憶手段に記録する関連付け手段、前記ユーザによりアイテムが予約又は購入された場合に、予約内容又は購入内容に関する内容情報と、前記閲覧済みアイテムに関連付けられた検索条件と、に基づいて、前記閲覧済みアイテムの表示を制御する表示制御手段、としてコンピュータを機能させる。

本発明の一態様では、前記ユーザにより予約又は購入されたアイテムは、閲覧済みアイテムの１つであり、前記内容情報は、前記予約又は購入された閲覧済みアイテムの検索で用いられた検索条件であり、前記表示制御手段は、前記予約又は購入された閲覧済みアイテムに関連付けられた検索条件と、他の閲覧済みアイテムに関連付けられた検索条件と、に基づいて、当該他の閲覧済みアイテムの表示を制御する、ことを特徴とする。

本発明の一態様では、前記検索条件は、複数のサブアイテムの各々に関する条件を含み、前記内容情報は、前記複数のサブアイテムのうち、予約内容又は購入内容に関する少なくとも１つのサブアイテムに関する情報であり、前記表示制御手段は、前記内容情報と、前記閲覧済みアイテムに関連付けられた検索条件に含まれる前記少なくとも１つのサブアイテムに関する条件と、に基づいて、表示制御を行う、ことを特徴とする。

本発明の一態様では、前記表示制御手段は、前記ユーザにより予約又は購入されたアイテムとの関係で利用できない閲覧済みアイテムを特定し、当該特定した閲覧済みアイテムの表示制御を行う、ことを特徴とする。

本発明の一態様では、前記検索条件は、アイテムに係る利用日に関する条件を含み、前記内容情報は、前記予約又は購入されたアイテムの利用日を示し、前記表示制御手段は、前記予約又は購入されたアイテムの利用日と、前記閲覧済みアイテムに関連付けられた検索条件が示す利用日と、に基づいて、前記利用できない閲覧済みアイテムを特定する、ことを特徴とする。

本発明の一態様では、前記検索システムは、ユーザ端末から、前記閲覧済みアイテムの表示要求を受信し、前記表示制御手段は、前記ユーザ端末から前記表示要求が受信される前に、前記閲覧済みアイテムの表示制御をするための準備処理を予め実行し、前記ユーザ端末から前記表示要求が受信された場合に、当該準備処理の実行結果に基づいて、表示制御を行う、ことを特徴とする。

本発明の一態様では、前記表示制御手段は、前記内容情報に対応する内容を含む検索条件が前記閲覧済みアイテムに関連付けられている場合に、前記閲覧済みアイテムの表示を制限する、ことを特徴とする。

本発明の一態様では、前記表示制御手段は、前記内容情報に対応する内容を含む検索条件が前記閲覧済みアイテムに関連付けられている場合に、前記閲覧済みアイテムを優先表示する、ことを特徴とする。

本発明の一態様では、前記内容情報は、前記ユーザによりアイテムが予約又は購入された場合に、前記ユーザにより指定された予約内容又は購入内容を格納するためのデータベースに格納された情報であり、前記表示制御手段は、前記データベースに格納された内容情報と、前記閲覧済みアイテムに関連付けられた検索条件と、に基づいて、表示制御を行う、ことを特徴とする。

本発明の一態様では、前記閲覧手段は、前記表示制御手段により表示された閲覧済みアイテムが前記ユーザにより選択された場合に、当該閲覧済みアイテムに関連付けられた検索条件に基づいて、当該閲覧済みアイテムを閲覧させる、ことを特徴とする。

本発明の一態様では、前記検索条件は、アイテムに係るサービスの利用日に関する条件を含み、前記内容情報は、前記予約又は購入されたアイテムの利用日を示し、前記検索システムは、前記閲覧済みアイテムに関連付けられた検索条件が示す利用日と、前記予約又は購入されたアイテムの利用日と、の少なくとも一方が経過したか否かを判定する経過判定手段を更に含み、前記表示制御手段は、前記経過判定手段の判定結果に更に基づいて、表示制御を行う、ことを特徴とする。

本発明によれば、ユーザインタフェースの利便性を高めることが可能になる。

検索システムの全体構成を示す図である。 トップ画面の一例を示す図である。 検索が実行される様子を示す図である。 トップ画面に閲覧履歴が表示される様子を示す図である。 表示領域に空き状況が表示される様子を示す図である。 実施形態１の検索システムで実現される機能の一例を示す機能ブロック図である。 アイテムデータベースのデータ格納例を示す図である。 在庫データベースのデータ格納例を示す図である。 閲覧履歴データベースのデータ格納例を示す図である。 検索システムにおいて実行される処理の一例を示すフロー図である。 Ｓ２の処理の詳細を示す図である。 実施形態２のトップ画面の一例を示す図である。 予約前後で表示領域に表示される閲覧済みホテルが変わる様子を示す図である。 実施形態２の検索システムで実現される機能の一例を示す機能ブロック図である。 実施形態２の閲覧履歴データベースのデータ格納例を示す図である。 予約データベースのデータ格納例を示す図である。 実施形態２におけるＳ１６の処理の詳細を示す図である。 実施形態１に係る変形例の機能ブロック図である。 変形例（１−１）におけるトップ画面の変化の一例を示す図である。 変形例（１−２）におけるトップ画面の変化の一例を示す図である。 変形例（１−３）におけるトップ画面の変化の一例を示す図である。 変形例（１−５）におけるトップ画面の変化の一例を示す図である。 実施形態２に係る変形例の機能ブロック図である。 変形例（２−１）におけるトップ画面の変化の一例を示す図である。 変形例（２−３）におけるトップ画面の変化の一例を示す図である。

［１．実施形態１］
以下、本発明に係る検索システムの実施形態の例を説明する。

［１−１．検索システムの全体構成］
図１は、検索システムの全体構成を示す図である。図１に示すように、検索システムＳは、ユーザ端末１０とサーバ２０とを含み、これらは、インターネットなどのネットワークＮに接続可能である。なお、図１ではユーザ端末１０とサーバ２０とを１台ずつ示しているが、これらは複数台あってよい。

ユーザ端末１０は、ユーザが操作するコンピュータである。例えば、ユーザ端末１０は、携帯電話機（スマートフォンを含む）、携帯情報端末（タブレット型コンピュータを含む）、又は、パーソナルコンピュータ等である。本実施形態では、ユーザ端末１０は、制御部１１、記憶部１２、通信部１３、操作部１４、及び表示部１５を含む。

制御部１１は、少なくとも一つのマイクロプロセッサを含む。制御部１１は、記憶部１２に記憶されたプログラムやデータに従って処理を実行する。記憶部１２は、主記憶部及び補助記憶部を含む。例えば、主記憶部はＲＡＭなどの揮発性メモリであり、補助記憶部は、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ、又はハードディスクなどの不揮発性メモリである。

通信部１３は、有線通信又は無線通信用の通信インタフェースであり、ネットワークを介してデータ通信を行う。操作部１４は、ユーザが操作を行うための入力デバイスであり、例えば、タッチパネルやマウス等のポインティングデバイス、キーボード、又はボタン等である。操作部１４は、ユーザによる操作内容を制御部１１に伝達する。表示部１５は、例えば、液晶表示部又は有機ＥＬ表示部等である。表示部１５は、制御部１１の指示に従って画像を表示する。

サーバ２０は、サーバコンピュータである。サーバ２０は、制御部２１、記憶部２２、及び通信部２３を含む。制御部２１、記憶部２２、及び通信部２３の物理的構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。

なお、記憶部１２，２２に記憶されるものとして説明するプログラム及びデータは、ネットワークＮを介して供給されるようにしてもよい。また、上記説明した各コンピュータのハードウェア構成は、上記の例に限られず、種々のハードウェアを適用可能である。例えば、コンピュータ読み取り可能な情報記憶媒体を読み取る読取部（例えば、光ディスクドライブやメモリカードスロット）や外部機器とデータの入出力をするための入出力部（例えば、ＵＳＢポート）が含まれていてもよい。例えば、情報記憶媒体に記憶されたプログラムやデータが読取部や入出力部を介して、各コンピュータに供給されるようにしてもよい。

［１−２．実施形態１の概要］
本実施形態では、検索システムＳを旅行予約サービスに適用する場合を一例として説明する。旅行予約サービスは、ユーザの旅行予約を支援するサービスであり、本実施形態では、宿泊施設、航空券、レンタカー、及びバスといった予約を総合的に支援する旅行予約サービスを一例として説明する。

なお、本実施形態では、宿泊施設の一例としてホテルを説明するが、宿泊施設は、ホテルに限られず、旅館、民泊施設、又はゲストハウスであってもよい。また、旅行予約サービスの内容は、本実施形態の例に限られず、他にも例えば、列車、レストラン、又はオプションツアーといった予約を支援してもよいし、ホテルや航空券等がセットになったパッケージツアーの予約を支援してもよい。また、複数の予約を総合的に支援する場合に限られず、何れか１つだけの予約を支援するサービスであってもよい。例えば、ホテルの予約だけをしたり航空券の予約だけをしたりする場合にも、実施形態に係る処理を適用可能である。

また、検索システムＳは、旅行予約以外の任意の場面に適用可能であり、例えば、電子商取引、チケット販売、又はイベント予約といった種々の場面にも適用可能である。他の場面での適用例については、後述する変形例で説明する。

例えば、ユーザがユーザ端末１０を操作して、サーバ２０にアクセスすると、旅行予約サービスのトップ画面が表示部１５に表示される。なお、以降説明する画面は、ユーザ端末１０に記憶された旅行予約のアプリケーションの画面として表示されてもよいし、ウェブブラウザの画面として示されてもよい。

図２は、トップ画面の一例を示す図である。図２に示すように、例えば、トップ画面Ｇ１には、検索条件を入力するための入力フォームＦ１０〜Ｆ１３と、検索を実行するためのボタンＢ１４と、が表示される。また例えば、トップ画面Ｇ１は、ユーザが最近閲覧したホテル等を表示するための表示領域Ａ１５と、おすすめのホテル等を表示するための表示領域Ａ１６と、を含む。

図２に示すように、トップ画面Ｇ１は、ホテル予約、航空券予約、レンタカー予約、及びバス予約の各々の検索条件を入力可能となっている。検索条件は、検索で用いられるクエリであり、任意の条件を入力可能である。検索条件は、キーワードであってもよいし、予め定められた複数の数値（例えば、日付、時間、人数、予算等）の中から選択された数値であってもよいし、カテゴリのような属性情報であってもよい。

例えば、ホテル予約であれば、宿泊地、利用日（宿泊日）、利用人数、及び宿泊費といった検索条件が入力される。また例えば、航空券予約であれば、出発地、目的地、出発日、出発時間、到着日、到着時間、航空会社、及び運賃といった検索条件が入力される。また例えば、レンタカー予約であれば、出発場所、返却場所、利用日、利用時間、車種、及びレンタル料といった検索条件が入力される。また例えば、バス予約であれば、出発地、目的地、出発日、出発時間、到着日、到着時間、バス会社、及び運賃といった検索条件が入力される。

本実施形態では、説明の簡略化のために、ユーザがホテル予約をする場合の処理を説明する。例えば、ユーザは、入力フォームＦ１０に、宿泊地などのキーワードを入力する。宿泊地は、キーワードで入力されなくてもよく、予め用意された地域リストの中から選択されるようにしてもよい。また例えば、入力フォームＦ１１には、チェックイン日が入力され、入力フォームＦ１２には、チェックアウト日が入力される。また例えば、入力フォームＦ１３には、利用人数が入力される。ユーザが、これらの検索条件を入力してボタンＢ１４を選択すると、検索が実行される。

図３は、検索が実行される様子を示す図である。図３のトップ画面Ｇ１Ａ，Ｇ１Ｂに示すように、例えば、ユーザが、入力フォームＦ１０〜Ｆ１３に検索条件を入力し、ボタンＢ１４を選択すると、検索条件を満たすホテルが検索される。図３のトップ画面Ｇ１Ｂの例であれば、入力フォームＦ１０に入力された「東京」にあるホテルのうち、入力フォームＦ１１，Ｆ１２に入力された「２０１８年４月１日」〜「２０１８年４月３日」の利用日において、入力フォームＦ１３に入力された「２人」用の部屋に空きがあるホテルが検索される。

図３に示すように、ホテルが検索されると、検索結果を示す検索結果画面Ｇ２が表示部１５に表示される。例えば、検索結果画面Ｇ２の入力フォームＦ２０には、検索で用いられた検索条件が表示される。ユーザは、所望のホテルが見つからなかった場合には、入力フォームＦ２０から検索条件を変更し、再度検索を実行する。

また例えば、検索結果画面Ｇ２のリストＬ２１には、検索でヒットしたホテルが表示される。リストＬ２１では、検索でヒットしたホテルが選択可能に表示され、リストＬ２１をスクロールしたり、所定のページ送り操作をしたりすることで、画面に表示しきれないホテルを表示させることもできる。例えば、リストＬ２１には、検索でヒットしたホテルの名称、画像（図３では省略する）、ユーザの評価、及び価格帯といった情報が表示される。

図３に示すように、ユーザがリストＬ２１に表示されたホテルを選択すると、当該ホテルの詳細を示すページであるホテル画面Ｇ３が表示部１５に表示される。図３では、ユーザがリストＬ２１内の「ホテルＡ」を選択し、「ホテルＡ」のページを示すホテル画面Ｇ３が表示部１５に表示される場合を示している。例えば、ホテル画面Ｇ３には、「ホテルＡ」の名前、評価、画像、部屋の名前、料金、及び部屋を予約するためのボタンＢ３０が表示される。

例えば、ユーザがボタンＢ３０を選択した場合、当該ボタンＢ３０に対応する部屋の予約画面に遷移し、その後、食事やエステなどのオプション情報が選択されたり、宿泊者情報が入力されたりした後に、予約が完了する。なお、利用日や利用人数は、検索条件で入力された値でそのまま予約が行われてもよいし、検索条件で入力された利用日や利用人数が変更されたうえで、予約が行われてもよい。

なお、図３のリストＬ２１内の「ホテルＢ」又は「ホテルＣ」をユーザが選択した場合も同様に、選択された「ホテルＢ」又は「ホテルＣ」のページを示すホテル画面Ｇ３が表示部１５に表示される。例えば、ユーザは、検索結果画面Ｇ２とホテル画面Ｇ３を行き来したり、検索結果画面Ｇ２から検索条件を変えて検索をやり直したりしながら、所望のホテルが見つかるまで検索を繰り返す。

本実施形態では、トップ画面Ｇ１の表示領域Ａ１５には、ユーザがホテル画面Ｇ３を表示させたホテルが閲覧履歴（最近見たページ）として表示される。例えば、図３のようにして、ユーザが複数のホテルを見比べた後にトップ画面Ｇ１に戻ると、これらのホテルが閲覧履歴として表示領域Ａ１５に表示される。

図４は、トップ画面Ｇ１に閲覧履歴が表示される様子を示す図である。図４の例は、ユーザが「ホテルＡ」、「ホテルＢ」、「ホテルＣ」、「ホテルＤ」、及び「ホテルＥ」の各々を順番に閲覧した場合を示している。なお、以降では、ユーザが閲覧したホテルを、閲覧済みホテルと記載する。

図４に示すように、表示領域Ａ１５には、これら閲覧済みホテルをそれぞれ示す画像Ｇ１５０Ａ〜Ｇ１５０Ｅが閲覧順に並ぶようにして表示される。例えば、表示領域Ａ１５では、直近の閲覧済みホテルは左上に表示され、右方向又は下方向に向けて時系列順となるように、他の閲覧済みホテルが並ぶ。このため、図４の例では、直近で閲覧された「ホテルＥ」の画像Ｇ１５０Ｅが最も左上に配置され、「ホテルＤ」、「ホテルＣ」、「ホテルＢ」、及び「ホテルＡ」の画像Ｇ１５０Ｄ〜Ｇ１５０Ａが順番に並ぶ。なお、以降では、画像Ｇ１５０Ａ〜Ｇ１５０Ｅを特に区別する必要のないときは、単に画像Ｇ１５０と記載する。

例えば、画像Ｇ１５０は、ホテル名を含み、閲覧済みホテルの外観や内観の写真を含んでもよい。他にも例えば、画像Ｇ１５０には、閲覧済みホテルの場所、価格帯、ユーザの評価といった情報が表示されてもよい。ユーザが何れかの画像Ｇ１５０を選択すると、当該画像Ｇ１５０が示す閲覧済みホテルのホテル画面Ｇ３が表示部１５に表示される。この場合、ユーザが選択した画像Ｇ１５０が示すホテルが、直近の閲覧済みホテルとなるので、その後にトップ画面Ｇ１に戻ると、画像Ｇ１５０の配置も更新される。なお、ユーザが直近で閲覧した「ホテルＥ」の画像Ｇ１５０Ｅを選択した場合には、各ホテルの閲覧順序は変わらないので、画像Ｇ１５０の配置も変わらない。

本実施形態では、閲覧済みホテルに対し、当該ホテルの検索で用いられた検索条件が関連付けられるようになっている。図３の検索例であれば、「ホテルＡ」、「ホテルＢ」、「ホテルＣ」、「ホテルＤ」、及び「ホテルＥ」の各々に対し、宿泊地が「東京」であり、利用日が「２０１８年４月１日」〜「２０１８年４月３日」であり、かつ、利用人数が「２人」といった検索条件（トップ画面Ｇ１Ｂで入力された検索条件）が関連付けられることになる。なお、閲覧済みホテルに関連付けられた検索条件は、画像Ｇ１５０に表示されてもよい。即ち、画像Ｇ１５０において、閲覧済みホテルが、どのような検索条件で検索したのかを特定できるようにしてもよい。

また、本実施形態では、表示領域Ａ１５において、閲覧済みホテルに関連付けられた検索条件での空き状況に関する情報が、当該ホテルとともに表示されるようになっている。図４の例であれば、利用日が「２０１８年４月１日」〜「２０１８年４月３日」であり、かつ、利用人数が「２人」である場合の残室の有無に関する情報が、表示領域Ａ１５において表示される

図５は、表示領域Ａ１５に空き状況が表示される様子を示す図である。図５のトップ画面Ｇ１Ｃに示すように、どの閲覧済みホテルも検索時の検索条件で空きがある場合には、表示領域Ａ１５には、各ホテルの画像Ｇ１５０がそのまま表示される。この状態から、例えば、「ホテルＤ」の残室がなくなったとすると、トップ画面Ｇ１Ｄに示すように、「ホテルＤ」の画像Ｇ１５０Ｄ上に、「ＳＯＬＤ ＯＵＴ」といったメッセージＭ１５１Ｄが表示され、検索時の検索条件では空きがないことが通知される。なお、メッセージＭ１５１Ｄには、検索時の検索条件が表示されてもよく、例えば、検索時に入力された利用日や利用人数が表示されてもよい。

続いて、「ホテルＡ」の残室もなくなったとすると、トップ画面Ｇ１Ｅに示すように、「ホテルＡ」の画像Ｇ１５０Ａ上に、「ＳＯＬＤ ＯＵＴ」のメッセージＭ１５１Ａが表示され、検索時の検索条件では空きがないことが通知される。その後、「ホテルＤ」にキャンセルが発生して空きが出ると、トップ画面Ｇ１Ｆに示すように、「ホテルＤ」の画像Ｇ１５０Ｄ上のメッセージＭ１５１Ｄが消去されて元の表示に戻り、検索時の検索条件で「ホテルＤ」に残室があることが通知される。

なお、以降では、メッセージＭ１５１Ａ，Ｂ１５１Ｄを区別する必要のないときは、単にメッセージＭ１５１と記載する。また、「ホテルＢ」、「ホテルＣ」、及び「ホテルＥ」についても同様に、検索時の検索条件で空きがなくなるとメッセージＭ１５１が表示され、その後に空きが発生すると当該メッセージＭ１５１が消去される。閲覧済みホテルの在庫判定は、トップ画面Ｇ１が表示される場合にのみ実行されてもよいし、トップ画面Ｇ１の表示中に定期的に実行され、表示領域Ａ１５の表示が定期的に更新されるようにしてもよい。

以上のように、本実施形態の検索システムＳでは、トップ画面Ｇ１の表示領域Ａ１５に、閲覧済みホテルの一覧を表示させ、検索時の検索条件で空きがない場合にメッセージＭ１５１を表示させることで、空きがないにも関わらず画像Ｇ１５０を選択するといったことを防止し、ユーザインタフェースの利便性を高めるようになっている。以降、この技術の詳細を説明する。

［１−３．実施形態１において実現される機能］
図６は、実施形態１の検索システムＳで実現される機能の一例を示す機能ブロック図である。なお、本実施形態では、表示制御に関する主な機能がサーバ２０で実現される場合を説明するが、後述する変形例のように、主な機能がユーザ端末１０で実現されるようにしてもよいし、ユーザ端末１０とサーバ２０との間で機能が分担されてもよい。

[１−３−１．サーバで実現される機能]
図６に示すように、サーバ２０では、データ記憶部２００、検索部２０１、閲覧部２０２、関連付け部２０３、及び表示制御部２０４が実現される。データ記憶部２００、検索部２０１、閲覧部２０２、関連付け部２０３、及び表示制御部２０４は、それぞれ記憶手段、検索手段、閲覧手段、関連付け手段、及び表示制御手段の一例である。

［データ記憶部］
データ記憶部２００は、記憶部２２を主として実現される。データ記憶部２００は、検索や表示制御に必要なデータを記憶する。ここでは、データ記憶部２００が記憶するデータの一例として、アイテムデータベースＤＢ１、在庫データベースＤＢ２、及び閲覧履歴データベースＤＢ３を説明する。

図７は、アイテムデータベースＤＢ１のデータ格納例を示す図である。アイテムデータベースＤＢ１は、サブアイテムごとに在庫情報があるアイテムに関する各種情報を格納するデータベースである。

アイテムは、検索対象となる情報であり、例えば、ユーザが予約するサービスであってもよいし、ユーザが購入する商品であってもよい。別の言い方をすれば、アイテムは、データアイテムと呼ばれることもあり、検索対象となるデータベース内の個々のレコードということもできる。このため、アイテムは、ユーザが予約するサービスに関する情報、又は、ユーザが購入する商品に関する情報ということもできる。

例えば、ホテル予約であれば、アイテムは、ホテル又は部屋である。航空機予約であれば、アイテムは、航空機又は座席である。レンタカー予約であれば、アイテムは、レンタルする車である。バス予約であれば、アイテムは、バス又は座席である。列車予約であれば、アイテムは、列車又は座席である。レストラン予約であれば、アイテムは、レストラン、座席、又はテーブルである。オプションツアー予約であれば、アイテムは、オプションツアーである。

サブアイテムは、アイテムに関連付けられた情報であり、例えば、ユーザが予約するサービスの内容（条件）であってもよいし、ユーザが購入する商品の内容（条件）であってもよい。サブアイテムは、アイテム同様にデータアイテムと呼ばれることもあるが、アイテムの下位概念に相当するデータアイテムである。例えば、サブアイテムは、アイテムを検索するためのインデックスであり、検索条件（検索クエリ）と比較される情報である。例えば、各アイテムのサブアイテムは、当該アイテムに係る利用日であってもよく、この場合には、検索条件は、利用日に関する条件を含んでもよい。アイテムには、少なくとも１つのサブアイテムが関連付けられている。

例えば、ホテル予約であれば、サブアイテムは、ホテルの場所、利用日、又は利用人数である。航空機予約であれば、サブアイテムは、出発地、目的地、出発日、出発時間、到着日、又は到着時間である。レンタカー予約であれば、サブアイテムは、店舗の場所、利用日、利用時間、乗車可能人数、又は車種である。バス予約であれば、サブアイテムは、出発地、目的地、出発日、又は出発時間である。列車予約であれば、サブアイテムは、出発地、目的地、出発日、出発時間、到着日、又は到着時間である。レストラン予約であれば、サブアイテムは、レストランの場所、利用日、食事ジャンル、又はメニューである。オプションツアー予約であれば、サブアイテムは、ツアーが行われる場所、利用日、又はツアー内容である。

在庫情報は、サブアイテムの在庫数を示す情報である。在庫数は、アイテムの残数であり、利用可能数又は購入可能数ということもできる。例えば、在庫情報は、サブアイテムに関連付けられている。また例えば、サブアイテムごとに、在庫情報が存在する。なお、全てのサブアイテムに対し、在庫情報が関連付ける必要はなく、少なくとも１つのサブアイテムに在庫情報が関連付けられていればよい。

例えば、ホテル予約であれば、在庫情報は、ホテル内の部屋の残室数を示す。航空機予約であれば、在庫情報は、航空機内の座席の残席数を示す。レンタカー予約であれば、在庫情報は、車の残台数を示す。バス予約であれば、在庫情報は、バス内の座席の残席数を示す。列車予約であれば、在庫情報は、列車内の座席の残席数を示す。レストラン予約であれば、在庫情報は、レストラン内のテーブル又は座席の残数を示す。オプションツアー予約であれば、在庫情報は、予約可能な残り人数を示す。

本実施形態では、説明の簡略化のために、ホテルがアイテムに相当し、利用日がサブアイテムに相当する場合を一例として説明する。このため、本実施形態でホテルと記載した箇所は、アイテムと読み替えることができ、利用日と記載した箇所は、サブアイテムと読み替えることができる。在庫情報は、各部屋の利用日ごとの残室数を示すことになる。

図７に示すように、アイテムデータベースＤＢ１には、ホテルに関するデータが格納され、例えば、ホテルを一意に識別するホテルＩＤ、ホテル情報、及び部屋情報が格納される。

ホテル情報は、ホテルの基本情報であり、例えば、ホテルの名前、住所、連絡先、建物の画像、敷地内の施設、設備、及び価格帯などが格納される。部屋情報は、ホテル内の各部屋の基本情報であり、例えば、部屋を一意に識別する部屋ＩＤ、部屋の名前、利用可能人数、部屋のタイプ、間取り、広さ、バス・トイレの有無、及び部屋の紹介文などが格納される。

ホテル情報と部屋情報は、検索時のインデックスとして用いられるようにしてよい。例えば、宿泊地の場所がクエリとして入力された場合には、ホテル情報の住所がインデックスとなる。また例えば、利用人数がクエリとして入力された場合には、部屋情報の利用可能人数がインデックスとなる。

なお、本実施形態では、ホテル検索を例に挙げるので、図７において、アイテムデータベースＤＢ１に、ホテルに関するデータだけを図示したが、アイテムデータベースＤＢ１には、航空券、レンタカー、又はバスに関するデータが格納されていてもよい。この場合、ホテル、航空券、レンタカー、又はバスといった各データの種類（各サービスの提供者）を識別するためのＩＤによって、個々のデータがどの種類のものであるかを識別可能としてもよい。

図８は、在庫データベースＤＢ２のデータ格納例を示す図である。図８に示すように、在庫データベースＤＢ２は、利用日ごとに在庫情報を格納するデータベースである。例えば、在庫データベースＤＢ２には、ホテルＩＤ、部屋ＩＤ、利用日、及び在庫情報が格納される。例えば、ホテルの中には、複数のタイプの部屋が存在し、かつ、同じタイプの部屋が複数存在するので、在庫データベースＤＢ２には、ホテルの部屋のタイプごとに、利用日と在庫情報との組み合わせが格納されている。在庫データベースＤＢ２の利用日は、検索時のインデックスとして用いられる。例えば、検索条件に入力されたチェックイン日からチェックアウトの前日までの在庫情報が参照されるようにしてよい。

図９は、閲覧履歴データベースＤＢ３のデータ格納例を示す図である。図９に示すように、閲覧履歴データベースＤＢ３は、ユーザの閲覧履歴を格納するデータベースである。例えば、閲覧履歴データベースＤＢ３には、ユーザを一意に識別するユーザＩＤ、閲覧順序、閲覧したホテルのホテルＩＤ、検索で用いられた検索条件、及び閲覧時間が格納される。閲覧履歴データベースＤＢ３は、後述する関連付け部２０３によって更新される。

なお、データ記憶部２００に記憶されるデータは、上記の例に限られない。例えば、データ記憶部２００は、図２−図５に示す各画面を表示させるための画像データを記憶してもよい。また例えば、データ記憶部２００は、各ユーザの基本情報を格納するデータベースを記憶してもよい。例えば、ユーザの居住地をデータベースに格納しておき、航空券予約などの出発地として利用してもよい。

［検索部］
検索部２０１は、制御部２１を主として実現される。検索部２０１は、ユーザにより入力された検索条件に基づいて、ホテル検索を実行する。検索自体は、公知の種々の処理を適用可能であり、例えば、キーワード検索が実行される場合には、完全一致や部分一致が利用されてもよいし、あいまい検索が利用されてもよい。また例えば、数値検索が実行される場合には、検索条件で指定された数値範囲と一致する数値が検索される。

ホテル検索は、本発明に係るアイテム検索の一例である。アイテム検索は、アイテムを検索するための処理であればよく、検索条件をクエリとし、クエリと一致するインデックスを有するアイテムを検索する処理である。別の言い方をすれば、アイテム検索は、アイテムデータベースＤＢ１の中から、検索条件にヒットするアイテムのレコードを検索する処理である。

検索部２０１は、ユーザ端末１０から検索条件を受信し、当該受信した検索条件に基づいて、ホテル検索を実行する。本実施形態では、検索部２０１は、ユーザ端末１０から、トップ画面Ｇ１の入力フォームＦ１０〜Ｆ１３に入力された検索条件を受信し、当該受信した検索条件に基づいて、ホテル検索を実行する。ここでは、入力フォームＦ１０〜Ｆ１３に対し、宿泊地、利用日、及び利用人数が入力されるので、検索部２０１は、これら宿泊地、利用日、及び利用人数をクエリとし、アイテムデータベースＤＢ１に格納されたホテル情報及び部屋情報と、在庫データベースＤＢ２に格納された利用日と、をインデックスとして、ホテル検索を実行する。

例えば、検索部２０１は、入力フォームＦ１０に入力された宿泊地と、ホテル情報に格納された住所と、が一致するレコードを検索し、宿泊地に合致するホテルを特定する。そして、検索部２０１は、特定したホテルの中から、入力フォームＦ１３に入力された人数と、部屋情報に格納された利用可能人数と、が一致するホテルの部屋を絞りこむ。更に、検索部２０１は、在庫データベースＤＢ２を参照し、絞り込んだホテルの部屋の中から、入力フォームＦ１１、Ｆ１２に入力された利用日に残室がある部屋を絞り込む。検索部２０１は、最終的に絞り込んだ部屋があるホテルを検索結果として取得する。検索結果に含まれるホテルは、検索条件にヒットしたホテルといえる。

［閲覧部］
閲覧部２０２は、制御部２１を主として実現される。閲覧部２０２は、検索部２０１の検索結果の中から、ユーザにより選択されたホテルを閲覧させる。検索結果は、検索部２０１の処理結果であり、例えば、検索でヒットしたホテルのホテルＩＤ、ホテル情報、部屋情報、及び在庫情報といった情報を含んでもよい。本実施形態では、検索結果は、検索結果画面Ｇ２内のリストＬ２１に表示される。

閲覧とは、ホテルに関する情報を表示部１５に表示させることである。例えば、ホテルに関する情報は、ホテル情報、部屋情報、及び在庫情報のうちの少なくとも１つである。閲覧部２０２は、ホテル画面Ｇ３を表示部１５に表示させることによって、ユーザにホテルを閲覧させる。別の言い方をすれば、閲覧は、サーバ２０からユーザ端末１０に対し、ホテルに関する情報が送信されることである。閲覧部２０２は、ホテル画面Ｇ３の表示データをユーザ端末１０に送信することによって、ユーザにホテルを閲覧させる。表示データは、画面を表示させるためのデータであればよく、例えば、ＨＴＭＬデータ、画像データ、又はテキストデータ等である。

本実施形態では、閲覧部２０２がサーバ２０によって実現されるので、閲覧部２０２は、リストＬ２１の中からユーザにより選択されたホテルのホテルＩＤをユーザ端末１０から受信し、当該受信したホテルＩＤが示すホテルを閲覧させる。例えば、閲覧部２０２は、アイテムデータベースＤＢ１のうち、受信したホテルＩＤが格納されたレコードのホテル情報と部屋情報とに基づいて、ホテル画面Ｇ３の表示データを生成し、ユーザ端末１０に対して送信することによって、ユーザにホテルの詳細を閲覧させる。また例えば、閲覧部２０２は、在庫データベースＤＢ２のうち、受信したホテルＩＤが格納されたレコードの在庫情報をユーザ端末１０に対して送信することによって、ユーザに在庫情報を閲覧させてもよい。

また例えば、閲覧部２０２は、表示制御部２０４により表示された閲覧済みホテルがユーザにより選択された場合に、当該閲覧済みホテルに関連付けられた検索条件に基づいて、当該閲覧済みホテルを閲覧させてもよい。即ち、閲覧部２０２は、表示領域Ａ１５に表示された閲覧済みホテルが選択された場合には、当該閲覧済みホテルの検索時の検索条件でホテル画面Ｇ３の表示データを生成し、ユーザ端末１０に対して送信してもよい。閲覧部２０２は、閲覧履歴データベースＤＢ３のうち、ユーザにより選択された閲覧済みホテルのホテルＩＤが格納されたレコードを参照し、検索条件を取得する。そして、閲覧部２０２は、アイテムデータベースＤＢ１及び在庫データベースＤＢ２のうち、当該ホテルＩＤが格納されたレコードを参照し、検索条件を満たす部屋を検索し、閲覧済みホテルを閲覧させる。

［関連付け部］
関連付け部２０３は、制御部２１を主として実現される。関連付け部２０３は、閲覧済みホテルと、検索で用いられた検索条件と、を関連付けてデータ記憶部２００に記録する。

閲覧済みホテルは、閲覧部２０２の制御により、ユーザが既に閲覧したホテルである。別の言い方をすれば、閲覧済みホテルは、閲覧部２０２によって、ホテル画面Ｇ３が表示部１５に表示されたり、ホテル画面Ｇ３の表示データがユーザ端末１０に送信されたりしたホテルである。

検索で用いられた検索条件とは、閲覧済みホテルの検索時に入力された検索条件である。別の言い方をすれば、検索で用いられた検索条件は、閲覧済みホテルの検索時にクエリとなった検索条件である。検索条件は、検索部２０１によって検索が実行された後、データ記憶部２００に保持され、ホテルが閲覧された場合に閲覧履歴データベースＤＢ３に格納されるものとする。なお、関連付けるとは、情報同士を紐付けることであり、複数の情報をデータベース上で互いに検索可能にすることである。

閲覧済みホテルと検索条件とは、データ記憶部２００内の任意のデータベースにおいて関連付けられてよいが、本実施形態では、閲覧履歴データベースＤＢ３において関連付けられるものとする。例えば、関連付け部２０３は、閲覧済みホテルのホテルＩＤと、検索で用いられた検索条件と、を閲覧履歴データベースＤＢ３の同じレコードに格納する。

例えば、関連付け部２０３は、閲覧部２０２によってユーザにホテルが閲覧された場合に、閲覧済みの当該ホテルと、検索条件と、を関連付けて閲覧履歴データベースに格納する。別の言い方をすれば、関連付け部２０３は、閲覧部２０２によってユーザにホテルが閲覧されるたびに、閲覧済みの当該ホテルと、検索条件と、を関連付けて閲覧履歴データベースに格納する。

なお、検索条件は、そのまま格納されてもよいし、在庫情報に影響する検索条件だけが格納されてもよい。例えば、検索条件として入力された宿泊地は、在庫情報に影響しないので閲覧履歴データベースＤＢ３に格納されず、利用日と利用人数だけが閲覧履歴データベースＤＢ３に格納されてもよい。

また、閲覧済みホテルが再度閲覧された場合に、検索条件が変わっていれば、関連付け部２０３は、新たな検索条件と、閲覧済みホテルと、を閲覧履歴データベースＤＢ３に関連付けて格納する。この場合、古い検索条件が格納されたレコードは、そのまま残してもよいし破棄してもよい。また例えば、古い検索条件が格納されたレコードの当該検索条件を、新たな検索条件に更新してもよい。この場合、閲覧履歴データベースＤＢ３の閲覧日時は、最新の閲覧日時に更新してもよい。

［表示制御部］
表示制御部２０４は、制御部２１を主として実現される。表示制御部２０４は、閲覧済みホテルに関連付けられた検索条件を満たす利用日の在庫情報に基づいて、閲覧済みホテルの表示を制御する。

検索条件を満たすとは、検索条件とインデックスが一致することである。別の言い方をすれば、検索条件を満たすとは、検索でヒットすることである。本実施形態では、利用日がサブアイテムに相当し、利用日に在庫情報が関連付けられているので、検索条件に含まれる利用日と、在庫データベースＤＢ２に格納された利用日と、が一致することが、閲覧済みホテルに関連付けられた検索条件を満たすことに相当する。

表示制御の対象となる閲覧済みホテルは、１つだけであってもよいし、複数であってもよい。複数の閲覧済みホテルが表示制御の対象となる場合には、閲覧履歴データベースＤＢ３に格納された全ての閲覧済みホテルであってもよいし、一部の閲覧済みホテルであってもよい。一部の閲覧済みホテルを表示制御の対象とする場合には、直近の所定個数の閲覧済みホテルとしてもよいし、ランダムに選出された閲覧済みホテルであってもよい。所定個数としては、表示領域Ａ１５に収まる程度（例えば、２個〜１０個程度）であってもよいし、それ以上であってもよい。

例えば、表示制御部２０４は、ユーザ端末１０から、閲覧履歴の表示要求を受信した場合に、閲覧履歴データベースＤＢ３のうち、表示要求を送信したユーザのユーザＩＤが格納されたレコードを参照する。表示要求は、閲覧履歴を表示させるための所定形式の要求であればよく、本実施形態では、トップ画面Ｇ１を表示させるための要求である。ユーザＩＤは、予めユーザ端末１０のデータ記憶部１００に記憶させておけばよい。

表示制御部２０４は、上記参照したレコードのうち、直近の所定個数のレコードを参照する。例えば、図９に示すように、閲覧履歴データベースＤＢ３に、閲覧時間が若い順にデータが格納されている場合には、表示制御部２０４は、所定個数だけ順番にレコードを参照する。そして、表示制御部２０４は、在庫データベースＤＢ２に基づいて、参照した各レコードに格納された検索条件が示す利用日の在庫情報を取得し、当該取得した在庫情報に基づいて、閲覧済みホテルの表示を制御する。

例えば、表示制御部２０４は、閲覧済みホテルに関連付けられた検索条件を満たす利用日の在庫情報に基づいて在庫の有無を判定し、当該判定結果に基づいて表示制御を行ってもよい。例えば、表示制御部２０４は、在庫情報が示す数値が閾値以上であれば在庫があると判定し、閾値未満であれば在庫がないと判定する。本実施形態では、閾値を１とするが、２以上の数値（例えば、２〜５程度の数値）を設定し、在庫が残りわずかになった場合には、在庫がないとみなすようにしてもよい。

なお、在庫の有無を判定する処理は、利用日が経過しているか否かを判定する処理は特に含まないようにしてもよいし、利用日が経過しているか否かを判定する処理を含んでいてもよい。閲覧済みホテルの利用日が経過した場合には、当該利用日の在庫の有無を判定する必要がないので、表示制御部２０４は、利用日が経過した閲覧済みホテルについては、在庫の有無を判定しなくてよい。在庫の有無を判定する処理は、閲覧済みホテルの利用日が経過したか否かを判定する処理を含んでいてもよい。

また例えば、表示制御部２０４は、閲覧済みホテルに関連付けられた検索条件を満たす利用日の在庫の有無を示す情報を、閲覧済みホテルに関連付けて表示させてもよい。

在庫の有無を示す情報とは、在庫の有無を識別可能な情報であり、例えば、在庫があることを示す情報であってもよいし、在庫がないことを示す情報であってもよい。本実施形態では、メッセージＭ１５１が、在庫の有無を示す情報に相当する場合を説明するが、他の情報が表示されてもよく、例えば、在庫の有無を示すアイコン等が表示されてもよい。

関連付けて表示させるとは、例えば、在庫の有無を示す情報を閲覧済みホテルの上又はその付近に表示させること、在庫の有無を示す情報と閲覧済みホテルとを線などで結んで表示させること、又は、在庫の有無を示す情報を閲覧済みホテルに組み込んで表示させることである。

本実施形態では、メッセージＭ１５１を、閲覧済みホテルの画像Ｇ１５０上に表示させることが、関連付けて表示させることに相当する場合を説明する。このため、例えば、表示制御部２０４は、閲覧済みホテルに関連付けられた検索条件を満たす利用日の在庫のない場合に、その旨を示すメッセージＭ１５１を、当該閲覧済みホテルの画像Ｇ１５０上に表示させる。メッセージＭ１５１の画像データは、データ記憶部２００に予め記憶させておけばよい。

なお、表示制御部２０４は、閲覧済みホテルに関連付けられた検索条件を満たす利用日の在庫のない場合に、在庫があることを示すメッセージやアイコン等を閲覧済みホテルの画像Ｇ１５０上に表示させてもよい。この場合、表示制御部２０４は、現在の在庫数を示すメッセージやアイコン等を表示させてもよい。

また、表示制御部２０４が実行する表示制御は、在庫の有無を示す情報の表示に限られない。例えば、表示制御部２０４は、在庫の有無に基づいて、閲覧済みホテルを示す画像Ｇ１５０の表示態様を変えてもよい。表示態様とは、例えば、画像のサイズ、色、輝度、透明度、形状、模様などである。

表示制御部２０４は、在庫がある場合は第１の表示態様（例えば、加工しない通常の色）で画像Ｇ１５０を表示させ、在庫が無い場合は第２の表示態様（例えば、グレーアウト）で画像Ｇ１５０を表示させてもよい。また例えば、表示制御部２０４は、在庫の有無を判定することなく、在庫情報が示す在庫数をそのまま表示させてもよい。

[１−３−２．ユーザ端末で実現される機能]
図６に示すように、ユーザ端末１０では、データ記憶部１００、受付部１０１、及び表示制御部１０２が実現される。データ記憶部１００、受付部１０１、及び表示制御部１０２は、それぞれ記憶手段、受付手段、及び表示制御手段の一例である。

［データ記憶部］
データ記憶部１００は、記憶部１２を主として実現される。データ記憶部１００は、サーバ２０から受信したデータを記憶する。例えば、データ記憶部１００は、トップ画面Ｇ１、検索結果画面Ｇ２、及びホテル画面Ｇ３の各々の表示データを記憶してもよい。また例えば、データ記憶部１００は、ユーザＩＤを記憶してもよいし、リストＬ２１に含まれるホテルのホテルＩＤを記憶してもよい。

［受付部］
受付部１０１は、制御部１１を主として実現される。受付部１０１は、操作部１４の検出信号に基づいて、ユーザの操作を受け付ける。受付部１０１がユーザの操作を受け付けると、ユーザ端末１０は、当該操作の内容を示す情報をサーバ２０に送信する。例えば、受付部１０１が操作を受け付けると、ユーザ端末１０は、何れの操作が行われたかを識別する情報をサーバ２０に送信する。

［表示制御部］
表示制御部１０２は、制御部１１を主として実現される。表示制御部１０２は、サーバ２０から受信した表示データに基づいて、各種画面を表示させる。例えば、表示制御部１０２は、トップ画面Ｇ１、検索結果画面Ｇ２、及びホテル画面Ｇ３の各々を表示させる。例えば、ウェブブラウザを利用して各画面を表示させる場合には、表示データは、ＨＴＭＬデータであり、ユーザ端末１０のプログラム（例えば、旅行予約アプリ）を利用して各画面を表示させる場合には、表示データは、フレームにはめ込む画像やテキスト情報であってもよい。

［１−４．本実施形態において実行される処理］
図１０は、検索システムＳにおいて実行される処理の一例を示すフロー図である。図１０に示す処理は、制御部１１，２１が、それぞれ記憶部１２，２２に記憶されたプログラムに従って動作することによって実行される。下記に説明する処理は、図６に示す機能ブロックにより実行される処理の一例である。

図１０に示すように、まず、ユーザ端末１０において、制御部１１は、操作部１４から所定の操作が行われた場合に、サーバ２０に対し、トップ画面Ｇ１の表示要求を送信する（Ｓ１）。例えば、所定の操作は、トップ画面Ｇ１のＵＲＬを選択する操作であってもよいし、旅行予約アプリを起動する操作であってもよい。トップ画面Ｇ１の表示要求は、所定形式のデータが送信されることで行われ、トップ画面Ｇ１を識別する情報（例えば、ＵＲＬや画面ＩＤ）を含む。なお、ユーザ端末１０からサーバ２０に何らかのデータが送信される場合には、記憶部１２に記憶されたユーザＩＤも送信されるものとする。

サーバ２０においては、表示要求を受信すると、制御部２１は、閲覧履歴データベースＤＢ３に基づいて、トップ画面Ｇ１の表示内容を決定する（Ｓ２）。

図１１は、Ｓ２の処理の詳細を示す図である。図１１に示すように、制御部２１は、閲覧履歴データベースＤＢ３のうち、表示要求とともに受信したユーザＩＤが格納されたレコードを特定し、直近のｎ（ｎは自然数）個のレコードを参照する（Ｓ２０）。Ｓ２０においては、制御部１１は、閲覧時間が新しい順にｎ個のレコードを参照してもよいし、レコード番号が若い順にｎ個のレコードを参照してもよい。

制御部２１は、カウンタ変数ｋに１を代入する（Ｓ２１）。制御部２１は、Ｓ２０で取得したｎ個のレコードのうち、ｋ個目のレコードに格納されたホテルＩＤと検索条件を取得する（Ｓ２２）。

制御部２１は、アイテムデータベースＤＢ１と在庫データベースＤＢ２に基づいて、Ｓ２２で取得した検索条件を満たす利用日の在庫情報を取得する（Ｓ２３）。Ｓ２３においては、制御部２１は、アイテムデータベースＤＢ１のうち、Ｓ２２で取得したホテルＩＤが格納されたレコードを参照し、検索条件に含まれる利用人数を満たす部屋の部屋ＩＤを特定する。そして、制御部２１は、在庫データベースＤＢ２のうち、当該ホテルＩＤと部屋ＩＤが格納されたレコードを参照し、検索条件が示す利用日の在庫情報を取得する。

制御部２１は、Ｓ２３で取得した在庫情報に基づいて在庫の有無を判定する（Ｓ２４）。Ｓ２４においては、制御部２１は、在庫情報が示す数値が１以上であるか否かを判定する。

在庫があると判定された場合（Ｓ２４；Ｙ）、制御部２１は、「ＳＯＬＤ ＯＵＴ」のメッセージＭ１５１を含まない画像Ｇ１５０を表示領域Ａ１５に配置する（Ｓ２５）。なお、各ホテルの画像Ｇ１５０は、アイテムデータベースＤＢ１等に予め格納しておけばよい。一方、在庫がないと判定された場合（Ｓ２４；Ｎ）、制御部２１は、「ＳＯＬＤ ＯＵＴ」のメッセージＭ１５１を含む画像Ｇ１５０を表示領域Ａ１５に配置する（Ｓ２６）。

制御部２１は、カウンタ変数ｋをインクリメントする（Ｓ２７）。制御部２１は、カウンタ変数ｋがｎよりも大きくなったか否かを判定する（Ｓ２８）。Ｓ２８においては、制御部２１は、Ｓ２０で取得したｎ個のレコード全てについて、Ｓ２２〜Ｓ２７の処理を実行したか否かを判定することになる。

カウンタ変数ｋがｎ以下であると判定された場合（Ｓ２８；Ｎ）、Ｓ２２の処理に戻り、次のレコードについて、Ｓ２２〜Ｓ２７の処理が実行される。一方、カウンタ変数ｋがｎよりも大きくなったと判定された場合（Ｓ２８；Ｙ）、制御部１１は、表示領域Ａ１６の表示内容を決定し（Ｓ２９）、Ｓ２の処理を終えて、図１０のＳ３に移行する。Ｓ２９においては、制御部１１は、閲覧履歴データベースＤＢ３に基づいて、ユーザの嗜好を分析し、リコメンドするホテル等を決定すればよい。また例えば、ユーザがホテルを予約した場合には、ホテル以外の内容（航空券、レンタカー、又はバス）をリコメンドするといったように、予約済みアイテムの種類に応じたリコメンドが行われてもよい。

図１０に戻り、制御部２１は、Ｓ２の処理結果に基づいて、トップ画面Ｇ１の表示データを生成し、ユーザ端末１０に対して表示データを送信する（Ｓ３）。なお、トップ画面Ｇ１の表示データには、表示領域Ａ１５，Ａ１６に表示されたホテル等の識別情報（例えば、ホテルＩＤ）が含まれているものとする。これにより、例えば、ユーザが画像Ｇ１５０を選択した場合に、どの閲覧済みホテルが選択されたかを特定可能となる。

ユーザ端末１０においては、表示データを受信すると、制御部１１は、当該表示データに基づいて、トップ画面Ｇ１を表示部１５に表示させる（Ｓ４）。制御部１１は、操作部１４の検出信号に基づいて、ユーザの操作を特定する（Ｓ５）。ここでは、ボタンＢ１４を選択する操作、又は、表示領域Ａ１５内の画像が選択される操作の何れかが行われる場合を説明する。なお、入力フォームＦ１０〜Ｆ１２に検索条件を入力する操作が行われた場合には、入力内容が、入力フォームＦ１０〜Ｆ１２に表示されるとともに、記憶部１２に記録されるものとする。

ボタンＢ１４が選択された場合（Ｓ５；Ｂ１４）、制御部１１は、検索の実行を要求するための検索要求を送信する（Ｓ６）。検索要求は、所定形式のデータが送信されることで行われるようにすればよく、入力フォームＦ１０〜Ｆ１３に入力された検索条件を含む。

サーバ２０においては、検索要求を受信すると、制御部２１は、アイテムデータベースＤＢ１及び在庫データベースＤＢ２に基づいて、検索要求に含まれる検索条件に基づいて、ホテル検索を実行する（Ｓ７）。Ｓ７においては、制御部２１は、検索条件をクエリとし、アイテムデータベースＤＢ１に格納されたホテル情報及び部屋情報と、在庫データベースＤＢ２に格納された利用日と、をインデックスとして、検索を実行する。制御部２１は、検索条件に合致する部屋を有し、かつ、当該部屋の在庫があるホテルを検索し、検索結果を取得する。

制御部２１は、Ｓ７の実行結果に基づいて、検索結果画面Ｇ２の表示データを生成し、ユーザ端末１０に対して送信する（Ｓ８）。なお、検索結果画面Ｇ２の表示データには、リストＬ２１に含まれるホテルのホテルＩＤが含まれているものとする。これにより、例えば、ユーザがリストＬ２１内のホテルを選択した場合に、どのホテルが選択されたかを特定可能となる。

ユーザ端末１０においては、表示データを受信すると、制御部１１は、検索結果画面Ｇ２を表示部１５に表示させる（Ｓ９）。制御部１１は、操作部１４の検出信号に基づいて、ユーザの操作を特定する（Ｓ１０）。ここでは、トップ画面Ｇ１に戻る操作、又は、リストＬ２１内のホテルを選択する操作が行われる場合を説明する。

トップ画面Ｇ１に戻る操作が行われた場合（Ｓ１０；トップ）、Ｓ１の処理に戻り、トップ画面Ｇ１の表示要求が送信される。一方、リスト内Ｌ２１のホテルを選択する操作が行われた場合（Ｓ１０；選択）、制御部１１は、ホテル画面Ｇ３の表示要求を送信する（Ｓ１１）。ホテル画面Ｇ３の表示要求には、リストＬ２１の中から選択されたホテルのホテルＩＤが含まれるものとする。

サーバ２０においては、表示要求を受信すると、制御部２１は、アイテムデータベースＤＢ１に基づいて、ホテル画面Ｇ３の表示データを生成し、ユーザ端末１０に対して送信する（Ｓ１２）。Ｓ１２においては、制御部２１は、アイテムデータベースＤＢ１のうち、表示要求に含まれるホテルＩＤが格納されたレコードを参照し、ホテル情報と部屋情報に基づいて、ホテル画面Ｇ３の表示データを生成する。なお、Ｓ１２においては、制御部２１は、Ｓ７の検索時にヒットした部屋だけを表示させてもよいし、同じホテルの他の部屋について表示させてもよい。

制御部２１は、表示要求に含まれるホテルＩＤと、Ｓ７で受信した検索条件と、を関連付けて閲覧履歴データベースＤＢ３に格納する（Ｓ１３）。Ｓ１２においては、制御部２１は、閲覧履歴データベースＤＢ３に新たなレコードを作成し、表示要求とともに受信したユーザＩＤ、ホテルＩＤ、検索条件、及び閲覧時間を格納する。閲覧時間は、リアルタイムクロック等で取得した現在時間が格納されるようにすればよい。

ユーザ端末１０においては、表示データを受信すると、制御部１１は、ホテル画面Ｇ３を表示部１５に表示させる（Ｓ１４）。制御部１１は、操作部１４の検出信号に基づいて、ユーザの操作を特定する（Ｓ１５）。ここでは、トップ画面Ｇ１に戻る操作、検索結果画面Ｇ２に戻る操作、又はボタンＢ３０を選択する操作について説明する。

トップ画面Ｇ１に戻る操作が行われた場合（Ｓ１５；トップ）、Ｓ１の処理に戻り、トップ画面Ｇ１の表示要求が送信される。一方、検索結果画面Ｇ２に戻る操作が行われた場合（Ｓ１５；検索結果）、Ｓ９の処理に戻り、検索結果画面Ｇ２に戻る。

一方、ボタンＢ３０を選択する操作が行われた場合（Ｓ１５；Ｂ３０）、ユーザ端末１０とサーバ２０との間でホテル予約処理が実行され（Ｓ１６）、本処理は終了する。Ｓ１６においては、ユーザ端末１０において入力された宿泊者情報等がサーバ２０に送信され、サーバ２０は、宿泊者情報等を記憶部２２に記録し、ユーザが予約したホテルの部屋の在庫が減るように、在庫データベースＤＢ２を更新する。

なお、Ｓ５において、表示領域Ａ１５内の画像Ｇ１５０が選択される操作が行われた場合（Ｓ５；Ｇ１５０）、Ｓ１１の処理に移行し、ユーザが選択した画像Ｇ１５０が示す閲覧済みホテルのホテル画面Ｇ３の表示要求が送信される。この場合、続くＳ１２において、制御部１１は、閲覧履歴データベースＤＢ３のうち、表示要求に含まれるホテルＩＤが格納されたレコードを参照し、当該レコードに格納された検索条件に基づいて、ホテル画面Ｇ３の表示データを生成する。なお、この場合は、検索結果からホテルが選択されたわけではないので、Ｓ１３の処理は実行されないものとする。

実施形態１の検索システムＳによれば、閲覧済みホテルに関連付けられた検索条件を満たす利用日の在庫情報に基づいて、閲覧済みホテルの表示が制御され、閲覧済みホテルの表示から在庫に関する内容を把握できるので、ユーザインタフェースの利便性を高めることができる。例えば、在庫情報に関係なく閲覧済みホテルを表示させる場合には、残室がない閲覧済みホテルを選択してしまい、ホテル画面Ｇ３が表示されても予約することができず、いちいち元のページに戻ったり別のページに移動したりするといった手間が発生するところ、検索システムＳでは、閲覧済みホテルの表示から在庫に関する内容を把握できるので、このような手間が発生することを防止し、ユーザにとって使い勝手のよいユーザインタフェースとすることができる。また、元のページに戻ったり別のページに移動したりしなくなることで、サーバ２０がホテル画面Ｇ３の表示データを生成及び送信する処理回数を減らすことができ、サーバ２０の処理負荷を減らすことができる。また、ネットワーク上に流れる表示データが減るので、通信負荷を減らすこともできる。

また、閲覧済みホテルに関連付けられた検索条件を満たす利用日の在庫情報に基づいて在庫の有無を判定し、当該判定結果に基づいて閲覧済みホテルの表示制御が行われることで、閲覧済みホテルの表示から在庫の有無を把握できるので、ユーザインタフェースの利便性を効果的に高めることができる。

また、閲覧済みホテルに関連付けられた検索条件を満たす利用日の在庫の有無を示すメッセージＭ１５１が、閲覧済みホテルを示す画像Ｇ１５０に関連付けて表示され、在庫の有無をより把握しやすくなるので、ユーザインタフェースの利便性を効果的に高めることができる。

また、表示領域Ａ１５において表示された閲覧済みホテルがユーザにより選択された場合に、当該閲覧済みホテルに関連付けられた検索条件に基づいて、当該閲覧済みホテルのホテル画面Ｇ３が表示され、検索条件を再入力するといった手間を省くことができるので、ユーザの操作負担を軽減することができる。

［２．実施形態２］
次に、検索システムＳの別実施形態を説明する。実施形態１で説明したように、トップ画面Ｇ１の表示領域Ａ１５には、閲覧済みホテルが表示される。ユーザがホテルを予約した場合、予約済みのホテルと同じ検索条件で検索した他のホテルは、ユーザによって予約される蓋然性が低い。このため、このようなホテルまで、表示領域Ａ１５に表示させたままにしておくと、不要な情報が表示されることになる。そこで、実施形態２では、ユーザが閲覧したホテルのうち、予約済みのホテルと同じ検索条件で検索したホテルは、表示領域Ａ１５に表示させないようにしている。

なお、実施形態２では、実施形態１と同様、ホテルがアイテムに相当し、利用日がサブアイテムに相当する場合を説明する。また、実施形態２では、実施形態１と同様の構成については説明を省略し、実施形態１と異なる構成を説明する。また、実施形態１で説明したメッセージＭ１５１を表示させる処理は、実施形態２で実行されてもよいし、実施形態２では省略して特に実行されなくてもよい。即ち、実施形態２では、閲覧済みホテルの在庫がなくなっても、特にメッセージＭ１５１が表示されなくてもよい。

［２−１．実施形態２の概要］
図１２は、実施形態２のトップ画面Ｇ１の一例を示す図である。図１２に示すように、トップ画面Ｇ１のレイアウトは、実施形態１のトップ画面Ｇ１と同様であり、例えば、表示領域Ａ１５には、閲覧済みホテルを示す画像Ｇ１５０が閲覧順に並んで表示される。

例えば、画像Ｇ１５０Ｆ〜Ｇ１５０Ｈにそれぞれ示す「ホテルＦ」、「ホテルＧ」、及び「ホテルＨ」は、それぞれ同じ検索条件で検索されて閲覧されたホテルである。ここでは、これら３つのホテルの検索条件を、宿泊地が「東京」であり、利用日が「２０１８年４月１日」〜「２０１８年４月３日」であり、かつ、利用人数が「２人」といった条件とする。

一方、画像Ｇ１５０Ｉ〜Ｇ１５０Ｋにそれぞれ示す「ホテルＩ」、「ホテルＪ」、及び「ホテルＫ」は、それぞれ同じ検索条件で検索されて閲覧されたホテルである。ただし、この検索条件は、「ホテルＦ」、「ホテルＧ」、及び「ホテルＨ」の検索条件とは異なり、宿泊地が「ニューヨーク」であり、利用日が「２０１８年５月１５日」〜「２０１８年５月１８日」であり、かつ、利用人数が「４人」といった条件とする。

例えば、ユーザがまだホテルの予約をしていない場合には、図１２に示すように、画像Ｇ１５０Ｆ〜Ｇ１５０Ｋが表示領域Ａ１５に表示される。その後、ユーザが「ホテルＦ」を予約したとすると、表示領域Ａ１５から、「ホテルＦ」、「ホテルＧ」、及び「ホテルＨ」が消去され、表示領域Ａ１５に表示される閲覧済みホテルが変わる。

図１３は、予約前後で表示領域Ａ１５に表示される閲覧済みホテルが変わる様子を示す図である。図１３のトップ画面Ｇ１Ｇに示すように、例えば、ユーザが表示領域Ａ１５の画像Ｇ１５０Ｆを選択すると、画像Ｇ１５０Ｆが示す「ホテルＦ」のホテル画面Ｇ３が表示される。ユーザがボタンＢ３０を選択した後に、利用日、利用人数、及び宿泊者情報といった予約に必要な情報を入力し、「ホテルＦ」の予約を完了させると、予約完了画面Ｇ４が表示部１５に表示される。

その後、ユーザがボタンＢ４０を選択してトップ画面Ｇ１に戻ると、トップ画面Ｇ１Ｈの表示領域Ａ１５に示すように、予約済みの「ホテルＦ」だけでなく、同じ検索条件で検索された「ホテルＧ」と「ホテルＨ」も消去される。ただし、「ホテルＩ」、「ホテルＪ」、及び「ホテルＫ」は、違う検索条件で検索されたホテルなので、表示領域Ａ１５に表示されたままとなる。また、「ホテルＦ」、「ホテルＧ」、及び「ホテルＨ」が表示領域Ａ１５から消去されてスペースが空いたので、「ホテルＫ」よりも前に閲覧した「ホテルＬ」が、新たに表示領域Ａ１５に表示される。

以上のように、実施形態２の検索システムＳは、閲覧済みホテルのうち、予約済みのホテルと同じ検索条件で検索したホテルは、表示領域Ａ１５から消去することで、不要な情報が残ったままになることを防止し、ユーザインタフェースの利便性を高めるようになっている。以降、この技術の詳細を説明する。

［２−２．実施形態２において実現される機能］
図１４は、実施形態２の検索システムＳで実現される機能の一例を示す機能ブロック図である。なお、本実施形態では、表示制御に関する主な機能がサーバ２０で実現される場合を説明するが、後述する変形例のように、主な機能がユーザ端末１０で実現されるようにしてもよいし、ユーザ端末１０とサーバ２０との間で機能が分担されてもよい。

図１４に示すように、実施形態２では、実施形態１と同様、サーバ２０において、データ記憶部２００、検索部２０１、閲覧部２０２、関連付け部２０３、及び表示制御部２０４が実現される。ただし、一部の機能は、実施形態１と異なる。以降、実施形態１と異なる点について説明する。なお、ユーザ端末１０の機能は、実施形態１と同様とする。

［データ記憶部］
例えば、データ記憶部２００は、アイテムデータベースＤＢ１、在庫データベースＤＢ２、閲覧履歴データベースＤＢ３、及び予約データベースＤＢ４を記憶する。アイテムデータベースＤＢ１と在庫データベースＤＢ２は、実施形態１と同様であるが、実施形態２では、閲覧履歴データベースＤＢ３の内容が実施形態１と異なる。

図１５は、実施形態２の閲覧履歴データベースＤＢ３のデータ格納例を示す図である。図１５に示すように、実施形態２の閲覧履歴データベースＤＢ３には、実施形態１で説明した情報に加え、非表示フラグが格納される。

非表示フラグは、閲覧済みホテルを示す画像Ｇ１５０を表示させるか否かを示す情報である。例えば、非表示フラグが第１の値（例えば、０）の場合には、閲覧済みホテルを表示させることを示し、非表示フラグが第２の値（例えば、１）の場合には、閲覧済みホテルを表示させないことを示す。以降、非表示フラグを第１の値から第２の値にすることを、非表示フラグをオンにすると記載し、非表示フラグを第２の値から第１の値にすることを、非表示フラグをオフにすると記載する。

本実施形態では、予約済みのホテルと、当該予約済みのホテルと検索条件が同じである閲覧済みホテルと、は表示領域Ａ１５に表示されないので、非表示フラグは、これらのホテルを識別するための情報ということもできる。非表示フラグは、ホテルの予約処理が実行され、後述する予約データベースＤＢ４にレコードが追加された場合に更新される。例えば、予約済みのホテルと、当該予約済みのホテルと検索条件が同じである閲覧済みホテルと、の各々の非表示フラグをオンにする。なお、一定時間が経過した場合に、これらの非表示フラグがオフになってもよい。

図１６は、予約データベースＤＢ４のデータ格納例を示す図である。図１６に示すように、予約データベースＤＢ４は、ユーザが予約したホテルに関するデータベースである。例えば、予約データベースＤＢ４には、ホテルを予約したユーザのユーザＩＤ、予約情報、及び予約完了日時が格納される。

予約情報は、予約内容を示す情報であり、例えば、ユーザが予約時に入力した内容である。例えば、予約情報には、ユーザが予約したホテルのホテルＩＤ、ユーザが予約した部屋の部屋ＩＤ、利用日、及び利用人数といった情報が格納される。なお、予約情報に含まれる内容は、これらに限られず、他にも例えば、宿泊者情報などの任意の内容が含まれていてもよい。

例えば、ホテル検索が実行された後、ユーザが利用日や利用人数を変更しなかった場合には、予約情報は、検索条件と同じ内容を含むことになるが、ユーザは、検索後に利用日や利用人数を変更して予約することができるので、この場合は、予約情報は、検索条件とは異なる内容を含むことになる。ホテルの予約処理が実行されると、予約データベースＤＢ４に新たなレコードが追加され、ホテルを予約したユーザのユーザＩＤ、予約時に入力された予約情報、及び予約完了日時が当該レコードに格納される。予約完了日時は、リアルタイムクロック等で取得される現在日時を利用すればよい。

なお、ユーザは、ホテル画面Ｇ３を表示させることなく、電話や窓口によってホテルを予約し、その予約結果が予約データベースＤＢ４に追加されるようにしてもよいが、本実施形態では、ユーザは、ホテル画面Ｇ３から予約の申し込みを行う場合を説明する。このため、ユーザにより予約されたホテルは、閲覧済みホテルの１つである。即ち、ユーザは、閲覧履歴データベースＤＢ３に格納された少なくとも１つホテルのうちの何れかを予約する。

［検索部・閲覧部・関連付け部］
検索部２０１、閲覧部２０２、及び関連付け部２０３は、それぞれ実施形態１と同様である。

［表示制御部］
表示制御部２０４は、ユーザによりホテルが予約された場合に、予約内容に関する内容情報と、閲覧済みホテルに関連付けられた検索条件と、に基づいて、閲覧済みホテルの表示を制御する。

内容情報は、ユーザがホテルを予約する場合に指定したサブアイテムに関する情報である。ホテルを予約する場合とは、予約されたホテルに関するレコードが予約データベースＤＢ４に追加される前であればよく、例えば、ユーザが検索条件を入力してから、予約が確定される前までの任意の時点であってよい。本実施形態では、利用日がサブアイテムに相当するので、内容情報は、ユーザが指定した利用日であり、例えば、検索条件に含まれる利用日であってもよいし、検索後にユーザが指定した利用日であってもよい。

例えば、検索条件は、宿泊地・利用日・利用人数といった複数のサブアイテムの各々に関する条件を含むので、内容情報は、複数のサブアイテムのうち、予約内容に関する少なくとも１つのサブアイテムに関する情報といえる。即ち、上記３つのサブアイテムうち、宿泊地は、検索で用いられるだけであり、ユーザが指定した予約内容には関係ないので、利用日と利用人数の２つが内容情報となる。

例えば、ホテル予約であれば、内容情報は、利用日又は利用人数である。航空機予約であれば、内容情報は、出発地、目的地、出発日、出発時間、到着日、又は到着時間である。レンタカー予約であれば、内容情報は、店舗の場所、利用日、利用時間、又は車種である。バス予約であれば、内容情報は、出発地、目的地、出発日、又は出発時間である。列車予約であれば、内容情報は、出発地、目的地、出発日、出発時間、到着日、又は到着時間である。レストラン予約であれば、内容情報は、利用日、利用人数、又はメニューである。オプションツアー予約であれば、内容情報は、利用日又は利用人数である。

なお、内容情報は、ユーザが予約した閲覧済みホテルの検索で用いられた検索条件（即ち、閲覧履歴データベースＤＢ３において予約済みのホテルに関連付けられた検索条件）であってもよいし、予約データベースＤＢ４に格納された、予約済みのホテルの予約情報であってもよい。

本実施形態では、ホテルの利用日がサブアイテムに相当するので、ユーザがホテルを予約する場合に指定した利用日が内容情報に相当する場合を説明する。このため、表示制御部２０４は、ユーザによりホテルが予約された場合に、当該ホテルの利用日と、閲覧済みホテルに関連付けられた検索条件が示す利用日と、に基づいて、閲覧済みホテルの表示を制御する。

例えば、表示制御部２０４は、ユーザにより予約されたホテルの利用日と、閲覧済みホテルに関連付けられた検索条件が示す利用日と、が一致するか否かを判定する。ここでの一致とは、完全一致でもよいし、部分一致であってもよい。部分一致とは、期間の一部が重複することを意味し、例えば、ホテルに連泊する場合に宿泊期間の一部が重複することである。なお、以降の説明で、利用日の一致といった記載をした場合には、ユーザにより予約されたホテルの利用日と、閲覧済みホテルに関連付けられた検索条件が示す利用日と、の一致を意味する。

表示制御部２０４は、利用日が一致するか否かの判定結果に基づいて、閲覧済みホテルの表示を制御する。例えば、表示制御部２０４は、利用日が一致する閲覧済みホテルは表示領域Ａ１５に表示させず、利用日が一致しない閲覧済みホテルは表示領域Ａ１５に表示させる。

本実施形態では、閲覧履歴データベースＤＢ３の非表示フラグをオンにすることが、閲覧済みホテルを表示させないようにするための処理に相当し、非表示フラグをオフにする（又はオフのまま値を変えない）ことが、閲覧済みホテルを表示させるようにするための処理に相当する。このため、表示制御部２０４は、利用日が一致する閲覧済みホテルの非表示フラグをオンにし、利用日が一致しない閲覧済みホテルの非表示フラグをオフにする。

なお、特に非表示フラグを用意しない場合には、ユーザ端末１０からトップ画面Ｇ１の表示要求を受信するたびに、表示制御部２０４が利用日の一致を判定し、閲覧済みホテルの表示を制御してもよい。他にも例えば、表示制御部２０４は、利用日が一致した閲覧済みホテルについては、閲覧履歴データベースＤＢ３からレコードを削除したり、他のデータベースにレコードを退避したりすることによって、当該閲覧済みホテルが表示領域Ａ１５に表示されないようにしてもよい。

また例えば、本実施形態では、閲覧履歴データベースＤＢ３に格納された検索条件が内容情報に相当するので、表示制御部２０４は、予約された閲覧済みホテルに関連付けられた検索条件と、他の閲覧済みホテルに関連付けられた検索条件と、に基づいて、当該他の閲覧済みホテルの表示を制御することになる。表示制御部２０４は、ユーザによって閲覧済みホテルが予約された場合に、閲覧履歴データベースＤＢ３に格納された当該閲覧済みホテルの検索条件を取得し、他の閲覧済みホテルの検索条件と比較し、当該他の閲覧済みホテルの表示を制御する。

また例えば、本実施形態では、検索条件に複数のサブアイテムに関する条件が含まれるので、表示制御部２０４は、予約されたホテルの利用日と、閲覧済みホテルに関連付けられた検索条件に含まれる少なくとも１つのサブアイテムに関する条件と、に基づいて、表示制御を行うことになる。どのサブアイテムが利用されるかは、予め定めておけばよく、本実施形態では、利用日とするが、利用日だけでなく利用人数も利用してよい。他にも例えば、宿泊地は利用しないものとして説明しているが、宿泊地も考慮して、閲覧済みアイテムの表示制御が行われてもよい。

上記のように、本実施形態では、表示制御部２０４は、ユーザにより予約されたホテルとの関係で利用できない閲覧済みホテルを特定し、当該特定した閲覧済みホテルの表示制御を行うことになる。

利用できない閲覧済みホテルとは、検索システムＳが予約申し込みを受け付けないという意味ではなく、物理的に利用できない閲覧済みホテルである。物理的に利用できないとは、ユーザの移動が間に合わないことである。例えば、予約済みのホテルの利用日と、閲覧済みホテルに関連付けられた検索条件に含まれる利用日と、が一致する場合は、当該閲覧済みホテルは利用できないことに相当する。

本実施形態では、検索条件は、ホテルに係る利用日に関する条件を含み、内容情報は、予約されたホテルの利用日を示すので、表示制御部２０４は、予約されたホテルの利用日と、閲覧済みホテルに関連付けられた検索条件が示す利用日と、に基づいて、利用できない閲覧済みホテルを特定することになる。例えば、表示制御部２０４は、これらの利用日が一致する場合に、閲覧済みホテルを利用できないと判定する。

また例えば、予約済みのホテルの利用日と、閲覧済みホテルに関連付けられた検索条件に含まれる利用日と、が一致しなかったとしても、これらのホテルの間を移動可能なほどの時間差がない場合は、当該閲覧済みホテルは利用できないことに相当する。

例えば、予約済みのホテルが「東京」にあり、予約日が「２０１８年４月１日」〜「２０１８年４月３日」であり、チェックアウトが「２０１８年４月３日」の１１時だったとする。そして、閲覧済みホテルが「ニューヨーク」にあり、予約日が「２０１８年４月３日」〜「２０１８年４月８日」であり、チェックインが「２０１８年４月３日」の１５時（日本時間）だったとする。この場合、東京−ニューヨーク間は、４時間では移動できないので、利用日が一致しなかったとしても、表示制御部２０４は、当該閲覧済みホテルを利用できないホテルとして判定する。

このように、利用日だけでなく、ホテルの場所（ホテル間の距離）や移動手段等も考慮して、利用可能性が判定されてもよい。例えば、表示制御部２０４は、アイテムデータベースＤＢ１のホテル情報を参照し、予約済みホテルの場所と、閲覧済みホテルの場所と、を特定する。そして、表示制御部２０４は、これらの場所に基づいて、ホテル間の推定移動時間を取得する。表示制御部２０４は、予約済みホテルの利用日と、閲覧済みホテルに関連付けられた検索条件に含まれる利用日と、の時間差が上記推定移動時間よりも長い場合には、閲覧済みホテルを利用可能と判定し、時間差が推定移動時間よりも短い場合には、閲覧済みホテルを利用できないと判定する。

なお、推定移動時間の計算に必要なデータは、データ記憶部２００に予め記憶させておけばよい。例えば、予約済みホテルの場所と閲覧済みホテルの場所の組み合わせと、推定移動時間と、の関係を、数式形式又はテーブル形式のデータで用意しておいてもよい。また例えば、アイテムデータベースＤＢ１のホテル情報に、ホテルの緯度経度情報を格納しておき、予約済みホテルの緯度経度情報と閲覧済みホテルの緯度経度情報とに基づいて計算されるこれらの距離と、推定移動時間と、の関係を、数式形式又はテーブル形式のデータで用意しておいてもよい。

また例えば、検索システムＳは、ユーザ端末１０から、閲覧済みホテルの表示要求（例えば、トップ画面Ｇ１の表示要求）を受信するので、表示制御部２０４は、ユーザ端末１０から表示要求が受信される前に、閲覧済みホテルの表示制御をするための準備処理を予め実行し、ユーザ端末１０から表示要求が受信された場合に、当該準備処理の実行結果に基づいて、表示制御を行うようにしてもよい。

準備処理は、例えば、閲覧済みホテルを表示するか否かを決定する処理であり、本実施形態では、非表示フラグの設定処理である。表示制御部２０４は、サーバ２０が閲覧済みホテルの表示要求する前に、予め非表示フラグの設定処理を実行しておくことになる。非表示フラグの設定処理は、先述した通りである。なお、非表示フラグ以外の情報によって、閲覧済みホテルを表示するか否かを識別させる場合には、準備処理は、当該情報を設定する処理となる。

上記のように、表示制御部２０４は、内容情報に対応する内容を含む検索条件が閲覧済みホテルに関連付けられている場合に、閲覧済みホテルの表示を制限することになる。内容情報に対応する内容とは、内容情報が示すサブアイテムの値と一致する検索条件を含むことである。本実施形態では、利用日がサブアイテムに相当するので、利用日が一致することが、内容情報に対応する内容を含むことに相当する。

閲覧済みホテルの表示を制限するとは、例えば、閲覧済みホテルを表示させないこと（即ち、表示を禁止すること）であってもよいし、閲覧済みホテルの表示優先度を低くする（順序を後にする）ことであってもよい。他にも例えば、閲覧済みホテルの画像Ｇ１５０のサイズを小さくすること、画像Ｇ１５０の輝度を低くすること、又は、画像Ｇ１５０をグレーアウトする等して色を変えることによって、閲覧済みホテルの表示が制限されてもよい。

［２−３．本実施形態において実行される処理］
実施形態２において実行される処理は、大まかには実施形態１と同様であり、図１０の処理が実行される。ただし、Ｓ２の処理とＳ１６の処理の詳細は、実施形態１とは異なる。

例えば、実施形態２では、Ｓ２の処理が開始されると、図１１のＳ２０において、制御部２１は、閲覧履歴データベースＤＢ３のうち、非表示フラグがオフのレコードの直近のｎ個のレコードを参照する。即ち、実施形態２では、非表示フラグがオンのレコードは、Ｓ２における取得対象とはならない。このため、非表示フラグがオンのレコードに対応するホテルは、表示領域Ａ１５に画像Ｇ１５０が表示されない。以降のＳ２１〜Ｓ２９の処理は、実施形態１と同様である。

図１７は、実施形態２におけるＳ１６の処理の詳細を示す図である。図１７に示すように、ユーザ端末１０においては、制御部１１は、操作部１４の検出信号に基づいて、サーバ２０に対し、予約処理の実行要求を送信する（Ｓ１６０）。実行要求は、所定形式のデータが送信されることで行われるようにすればよく、例えば、利用日、利用人数、利用者の名前、及び連絡先といった予約データベースＤＢ４に格納される予約情報を含む。これらの情報は、操作部１４から入力されてもよいし、検索時に入力された検索条件が記憶部１２に保持されることで取得されてもよい。

サーバ２０においては、実行要求を受信すると、制御部２１は、予約データベースＤＢ４に基づいて、予約処理を実行する（Ｓ１６１）。Ｓ１６１においては、制御部２１は、予約データベースＤＢ４に新たなレコードを作成し、当該レコードに、実行要求をしたユーザのユーザＩＤ、実行要求に含まれる予約情報、及び予約完了時間を格納する。また、制御部２１は、在庫データベースＤＢ２を参照し、ユーザが予約したホテルの部屋の残室数を減少させる。

制御部２１は、予約完了画面Ｇ４の表示データを生成し、ユーザ端末１０に送信する（Ｓ１６２）。予約完了画面Ｇ４の表示データは、予約情報に基づいて生成されるようにすればよい。

制御部２１は、閲覧履歴データベースＤＢ３に基づいて、非表示フラグを設定する（Ｓ１６３）。Ｓ１６３においては、制御部２１は、閲覧履歴データベースＤＢ３のうち、ユーザが予約したホテルのホテルＩＤが格納されたレコードを特定し、当該レコードに含まれる検索条件を取得する。そして、制御部２１は、閲覧履歴データベースＤＢ３のうち、取得した検索条件と一致する検索条件が格納されたレコードを特定し、当該レコードの非表示フラグをオンにする。なお、非表示フラグの初期値はオフであり、他のレコードの非表示フラグはオフのままとなる。

ユーザ端末１０においては、表示データを受信すると、制御部１１は、予約完了画面Ｇ４を表示部１５に表示させ（Ｓ１６４）、本処理は終了する。なお、ユーザがボタンＢ４０を選択した場合には、Ｓ１の処理が再度実行され、トップ画面Ｇ１の表示要求が送信されることになる。ここでは、Ｓ１６３の処理（準備処理の一例）が予め実行されているので、その後に実行されるＳ２では、Ｓ１６の処理で非表示フラグがオンになった閲覧済みホテルは、表示領域Ａ１５に表示されないようになる。

実施形態２の検索システムＳによれば、ユーザによりホテルが予約された場合に、予約内容に関する内容情報と、閲覧済みホテルに関連付けられた検索条件と、に基づいて、閲覧済みホテルの表示が制御され、閲覧済みホテルの一覧をただ表示させるのではなく、内容情報と検索条件とが閲覧済みホテルの表示に影響するので、ユーザインタフェースの利便性を高めることができる。例えば、予約済みホテルの利用日と一致する利用日を検索条件に含む閲覧済みホテルについては、ユーザにとって不要な情報である蓋然性が高いので、このような不要な情報がユーザに提供されることを防止できる。また、不要な閲覧済みホテルの画像Ｇ１５０を表示させないようにする場合には、当該画像Ｇ１５０を表示領域Ａ１５に配置するといった不要な処理が実行されないので、サーバ２０の処理負荷を減らすことができる。また、ネットワーク上に流れる表示データが減るので、通信負荷を減らすこともできる。

また、閲覧済みホテルが予約された場合に、予約済みの当該ホテルに関連付けられた検索条件と、閲覧済みホテルに関連付けられた検索条件と、に基づいて、閲覧済みアイテムの表示が制御され、検索条件の一部又は全部が共通する閲覧済みホテルが表示されることを防止でき、ユーザインタフェースの利便性を効果的に高めることができる。また、これらの検索条件は、別々のデータベースに格納されているのではなく、同じ閲覧履歴データベースＤＢ３に格納されており、表示制御のために参照するデータベースの数を減らすことで、表示制御処理を高速化するとともに、サーバ２０の処理負荷を減らすことができる。

また、検索条件に含まれる複数の条件のうち、利用日や利用人数といった特定の条件を表示制御で利用し、不要な情報をより正確に特定することができるので、ユーザインタフェースの利便性を効果的に高めることができる。また、複数の条件のうちの一部の条件を表示制御で利用する場合には、表示制御のために利用する条件の数を減らし、表示制御処理を高速化するとともに、サーバ２０の処理負荷を減らすことができる。

また、予約済みホテルとの関係で利用できない閲覧済みホテルが特定され、当該特定された閲覧済みホテルの表示制御が行われることで、利用できない閲覧済みホテルが表示されることを防止でき、ユーザインタフェースの利便性を効果的に高めることができる。

また、予約済みホテルの利用日と、閲覧済みホテルの利用日と、に基づいて、利用できない閲覧済みホテルが特定されることで、時間的な関係で利用できない閲覧済みホテルが表示されることを防止でき、ユーザインタフェースの利便性を効果的に高めることができる。

また、ユーザ端末１０からトップ画面Ｇ１の表示要求が受信される前に、非表示フラグの設定処理が予め実行され、ユーザ端末１０から表示要求が受信された場合に、予め設定した非表示フラグに基づいて、閲覧済みホテルの表示制御が行われることで、表示制御処理を高速化するとともに、サーバ２０の処理負荷を減らすことができる。例えば、表示要求が受信された後に、不要な閲覧済みホテルを特定する場合には、表示要求をしてからトップ画面Ｇ１を表示させるまでに時間がかかる。また例えば、多数のユーザからの表示要求が集中した場合には、サーバ２０の処理負荷が高まる。この点、検索システムＳは、予め非表示フラグの設定をしておくことで、表示要求を受信した後の処理を簡略化できるので、表示要求をしてからトップ画面Ｇ１を表示させるまでに時間を少なくし、サーバ２０の処理負荷を減らすことができる。

また、予約済みホテルの予約内容に関する内容情報に対応する内容を含む検索条件が関連付けられた閲覧済みホテルの表示が制限され、不要な情報がユーザに提供されることを防止でき、ユーザインタフェースの利便性を効果的に高めることができる。

また、表示領域Ａ１５において表示された閲覧済みホテルがユーザにより選択された場合に、当該閲覧済みホテルに関連付けられた検索条件に基づいて、当該閲覧済みホテルのホテル画面Ｇ３が表示され、検索条件を再入力するといった手間を省くことができるので、ユーザの操作負担を軽減することができる。

［３．変形例］
なお、本発明は、以上に説明した実施の形態に限定されるものではない。本発明の趣旨を逸脱しない範囲で、適宜変更可能である。

［３−１．実施形態１に係る変形例］
まず、実施形態１に係る変形例を説明する。図１８は、実施形態１に係る変形例の機能ブロック図である。図１８に示すように、実施形態１に係る変形例では、実施形態１で説明した機能に加えて、経過判定部２０５、負荷判定部２０６、及び実行部２０７が実現される。経過判定部２０５、負荷判定部２０６、及び実行部２０７は、それぞれ経過判定手段、負荷判定手段、及び実行手段の一例である。

（１−１）例えば、実施形態１では、閲覧済みホテルの在庫がない場合に、画像Ｇ１５０上にメッセージＭ１５１を表示させる場合を説明したが、在庫がない閲覧済みホテルについては、画像Ｇ１５０自体を表示領域Ａ１５に表示させないようにしてもよい。別の言い方をすれば、表示領域Ａ１５には、在庫がある閲覧済みホテルの画像Ｇ１５０だけを表示させてもよい。

図１９は、変形例（１−１）におけるトップ画面Ｇ１の変化の一例を示す図である。図１９のトップ画面Ｇ１Ｉは、実施形態１における図５のトップ画面Ｇ１Ｃと同様である。この状態から、例えば、「ホテルＢ」の残室がなくなったとすると、トップ画面Ｇ１Ｊに示すように、「ホテルＢ」の画像Ｇ１５０Ｂが表示領域Ａ１５から消去される。なお、ここでの残室がなくなるとは、検索時の検索条件での残室がなくなることである。この点は、以降の説明でも同様である。

続いて、「ホテルＥ」の残室もなくなったとすると、トップ画面Ｇ１Ｋに示すように、「ホテルＥ」の画像Ｇ１５０Ｅが表示領域Ａ１５から消去される。その後、「ホテルＢ」にキャンセルが発生して残室が出ると、トップ画面Ｇ１Ｌに示すように、「ホテルＢ」の画像Ｇ１５０Ｂが再び表示領域Ａ１５に表示される。

本変形例の表示制御部２０４は、閲覧済みホテルに関連付けられた検索条件を満たす利用日の在庫がない場合は、閲覧済みホテルを表示させず、閲覧済みホテルに関連付けられた検索条件を満たす利用日の在庫がある場合に、閲覧済みホテルを表示させる。閲覧済みホテルを表示させないとは、閲覧済みホテルを示す画像Ｇ１５０を表示領域Ａ１５に表示させないこと、又は、閲覧済みホテルを示す画像Ｇ１５０をユーザ端末１０に送信しないことである。

例えば、表示制御部２０４は、在庫がない閲覧済みホテルを示す画像Ｇ１５０は含まず、在庫がある閲覧済みホテルを示す画像Ｇ１５０を含むトップ画面Ｇ１を表示部１５に表示させる。別の言い方をすれば、表示制御部２０４は、在庫がない閲覧済みホテルについては、表示領域Ａ１５における表示対象から除外し、在庫がある閲覧済みホテルを、表示領域Ａ１５における表示対象とする。

変形例（１−１）によれば、トップ画面Ｇ１の表示領域Ａ１５において、在庫がない閲覧済みホテルは表示させず、在庫がある閲覧済みホテルを表示させることで、表示領域Ａ１５における閲覧済みホテルの表示の有無によって、閲覧済みホテルの在庫の有無を把握できるので、ユーザインタフェースの利便性を効果的に高めることができる。また、在庫がない閲覧済みホテルが表示されないので、在庫がない閲覧済みホテルが表示領域Ａ１５から選択されてしまい、ホテル画面Ｇ３が表示されても予約ができないといったことをより効果的に防止することができる。

（１−２）また例えば、閲覧済みホテルの在庫がなくなった後に、当該閲覧済みホテルにキャンセルが発生し、検索時に入力した利用日で空きが発生した場合に、表示領域Ａ１５において、当該閲覧済みホテルが優先的に表示されるようにしてもよい。

図２０は、変形例（１−２）におけるトップ画面Ｇ１の変化の一例を示す図である。図２０のトップ画面Ｇ１Ｍは、図５のトップ画面Ｇ１Ｃ及び図１９のトップ画面Ｇ１Ｉと同様である。この状態から、例えば、「ホテルＡ」の残室がなくなったとすると、トップ画面Ｇ１Ｎに示すように、「ホテルＡ」の画像Ｇ１５０Ａ上に、「ＳＯＬＤ ＯＵＴ」といったメッセージＭ１５１Ａが表示され、残室がなくなったことが通知される。なお、メッセージＭ１５１Ａを表示させるのではなく、変形例（１−１）のように、「ホテルＡ」の画像Ｇ１５０Ａが表示領域Ａ１５から消去されるようにしてもよい。

続いて、「ホテルＡ」にキャンセルが発生し、検索時に入力した利用日に空きが発生すると、トップ画面Ｇ１Ｏに示すように、在庫がない状態からある状態になったことを示すメッセージＭ１５２Ａが表示される。例えば、メッセージＭ１５２Ａは、「ホテルＡ」の画像Ｇ１５０Ａを指し示すようにして表示される。メッセージＭ１５２Ａは、画像Ｇ１５０Ａを優先的に表示するための画像であり、例えば、画像Ｇ１５０Ａ上に表示されてもよいし、画像Ｇ１５０Ａの一部として表示されてもよい。

本変形例の表示制御部２０４は、閲覧済みホテルに関連付けられた検索条件を満たす利用日の在庫がない状態から在庫がある状態になった場合に、閲覧済みホテルを優先表示させる。なお、ここでは、在庫の有無の判定結果を示す情報が閲覧履歴データベースＤＢ３に格納されており、表示制御部２０４は、当該情報に基づいて、在庫がない状態から在庫がある状態になったか否かを判定できるものとする。

在庫がない状態から在庫がある状態になるとは、在庫が戻ること、在庫数が閾値未満の状態から閾値以上の状態に変化すること、又は、在庫がないと判定された後に在庫があると判定されることである。表示制御部２０４は、閲覧済みホテルの在庫が閾値（例えば、１）未満になった後に、当該在庫が閾値以上になった場合に、在庫がない状態から在庫がある状態になったと判定する。

優先表示とは、画像Ｇ１５０を優先的に表示させることである。別の言い方をすれば、優先表示は、強調表示ということもでき、画像Ｇ１５０を目立つようにすることである。例えば、画像Ｇ１５０に関連付けて別の画像（例えば、メッセージＭ１５２や所定のアイコン等）を表示させること、又は、表示態様若しくは表示位置を変えることは、優先表示の一例である。

例えば、表示制御部２０４は、画像Ｇ１５０に関連付けてメッセージＭ１５２を表示させることによって、画像Ｇ１５０を優先表示する。また例えば、表示制御部２０４は、画像Ｇ１５０のサイズを大きくすることによって、画像Ｇ１５０を優先表示する。また例えば、表示制御部２０４は、画像Ｇ１５０の色又は模様を変えることによって、画像Ｇ１５０を優先表示する。また例えば、表示制御部２０４は、画像Ｇ１５０の輝度を上げることによって、画像Ｇ１５０を優先表示する。また例えば、表示制御部２０４は、画像Ｇ１５０を表示領域Ａ１５の１番目（左上）に移動することによって、画像Ｇ１５０を優先表示する。

変形例（１−２）によれば、閲覧済みホテルの残室がない状態からある状態になった場合に、当該閲覧済みホテルを優先表示させることで、空きが発生した閲覧済みホテルを把握しやすくなり、ユーザインタフェースの利便性を効果的に向上させることができる。

（１−３）また例えば、閲覧済みホテルの検索で用いられた利用日が経過した場合には、在庫の有無を判定しないようにしてもよいし、当該閲覧済みホテルを示す画像Ｇ１５０は、表示領域Ａ１５に表示させないようにしてもよい。別の言い方をすれば、表示領域Ａ１５には、閲覧済みホテルの検索で用いられた利用日が経過していない閲覧済みホテルの画像Ｇ１５０だけを、在庫の有無の判定対象としてもよいし、画像Ｇ１５０の表示対象としてもよい。

図２１は、変形例（１−３）におけるトップ画面Ｇ１の変化の一例を示す図である。図２１のトップ画面Ｇ１Ｐでは、画像Ｇ１５０Ｌ，Ｇ１５０Ｍにそれぞれ示す「ホテルＬ」と「ホテルＭ」は、それぞれ同じ利用日を検索条件にして検索されたホテルである。ここでは、これら２つのホテルの検索で用いられた利用日を、「２０１８年４月１日」〜「２０１８年４月３日」とする。

一方、画像Ｇ１５０Ｎ〜Ｇ１５０Ｑにそれぞれ示す「ホテルＮ」、「ホテルＯ」、「ホテルＰ」、及び「ホテルＱ」は、それぞれ同じ利用日を検索条件にして検索されたホテルである。ここでは、これら４つのホテルの検索条件で用いられた利用日を、「２０１８年５月１５日」〜「２０１８年５月１８日」とする。

例えば、上記２つの検索条件が示す利用日が何れも経過していない場合には、トップ画面Ｇ１Ｐに示すように、画像Ｇ１５０Ｌ〜Ｇ１５０Ｍが表示領域Ａ１５に表示される。その後、「ホテルＬ」と「ホテルＭ」の検索で用いられた利用日の最終日である「２０１８年４月３日」が経過すると、トップ画面Ｇ１Ｑに示すように、画像Ｇ１５０Ｌ，Ｇ１５０が消去される。

更に時間が経過し、「ホテルＮ」、「ホテルＯ」、「ホテルＰ」、及び「ホテルＱ」の検索で用いられた利用日の最終日である「２０１８年５月１８日」が経過すると、トップ画面Ｇ１Ｒに示すように、画像Ｇ１５０Ｎ〜Ｇ１５０Ｑが消去される。

なお、ここでは、利用日が複数日にまたがる場合に、最終日が経過したことを条件として、画像Ｇ１５０が消去される態様を説明したが、利用日の初日が経過した場合に画像Ｇ１５０が消去されるようにしてもよい。他にも例えば、初日から最終日までの間の何れかの日が経過した場合に、画像Ｇ１５０が消去されるようにしてもよい。

本変形例の検索システムＳは、経過判定部２０５を含む。経過判定部２０５は、制御部２１を主として実現される。経過判定部２０５は、閲覧済みホテルに関連付けられた検索条件が示す利用日が経過したか否かを判定する。経過判定部２０５は、リアルタイムクロック等から現在日時を取得し、現在日時と、閲覧済みアイテムに関連付けられた検索条件が示す利用日と、を比較することによって、利用日が経過したか否かを判定する。

利用日が経過するとは、現在日時が利用日よりも後になることである。先述したように、利用日が複数日にまたがる場合（利用日が１日ではなく、複数日である場合）には、経過判定部２０５は、現在日時が初日よりも後になった場合に、利用日が経過したと判定してもよいし。現在日時が最終日よりも後になった場合に、利用日が経過したと判定してもよい。他にも例えば、経過判定部２０５は、現在日時が、初日から最終日までの間の何れかの日よりも後になった場合に、利用日が経過したと判定してもよい。

表示制御部２０４は、閲覧済みホテルに関連付けられた検索条件を満たす利用日の在庫情報と、経過判定部２０５の判定結果と、に基づいて表示制御を行う。例えば、表示制御部２０４は、利用日が経過した閲覧済みホテルの表示を制限する。制限の意味は、実施形態２で説明した通りである。例えば、表示制御部２０４は、利用日が経過した閲覧済みホテルの表示を制限し、利用日が経過していない閲覧済みホテルは制限せずに表示させる。

また例えば、表示制御部２０４は、利用日が経過した閲覧済みホテルの表示を制限しないが、在庫情報に基づく表示制御の対象から除外してもよい。表示制御部２０４は、閲覧履歴データベースＤＢ３に格納された閲覧済みホテルのうち、検索条件が示す利用日が経過していない閲覧済みホテルについては、在庫情報に基づく表示制御の対象とし、検索条件が示す利用日が経過した閲覧済みホテルについては、在庫情報に基づく表示制御の対象とする。

変形例（１−３）によれば、閲覧済みホテルの検索条件に含まれる利用日が経過したか否かの判定結果に基づいて、閲覧済みホテルの表示制御が行われ、利用日が経過した不要な情報がユーザに提供されることを防止し、ユーザインタフェースの利便性を効果的に高めることができる。また、利用日が経過した不要な閲覧済みホテルの在庫判定をしないようにすることで、表示制御処理を高速化しつつ、サーバ２０の処理負荷を軽減することができる。

（１−４）また例えば、サーバ２０の処理負荷が高い場合には、閲覧済みホテルの在庫の有無を知らせるための表示制御を待機し、サーバ２０の処理負荷が低くなった場合に、当該表示制御が実行されるようにしてもよい。この場合、サーバ２０は、ユーザ端末１０からトップ画面Ｇ１の表示要求を受信した時点の処理負荷が高い場合には、閲覧済みホテルの画像Ｇ１５０だけを先に送信し、処理負荷が低くなった場合に在庫情報を参照し、閲覧済みホテルの在庫がなくなっていれば、メッセージＭ１５１を追加で送信してもよい。

本変形例の検索システムＳは、負荷判定部２０６と実行部２０７を含む。負荷判定部２０６と実行部２０７は、それぞれ制御部２１を主として実現される。負荷判定部２０６は、表示制御部２０４を含むコンピュータの処理負荷が閾値以上であるか否かを判定する。表示制御部２０４を含むコンピュータは、表示制御部２０４を実現するコンピュータであり、ここでは、サーバ２０である。

負荷判定部２０６は、サーバ２０の処理負荷を取得し、閾値以上であるか否かを判定する。処理負荷としては、コンピュータの負荷に関する情報であればよく、例えば、ＣＰＵ使用率、メモリ使用率、又は単位時間当たりの通信量等である。これらの取得方法自体は、公知の種々の手法を適用可能であり、例えば、所定のコマンド（例えば、Ｌｉｎｕｘ（登録商標）におけるｔｏｐコマンド）を利用してＣＰＵ使用率やメモリ使用率が取得されてもよいし、単位時間当たりのデータ受信量が計測されることで通信量が取得されてもよい。

なお、閾値は、予め定められた数値であればよく、例えば、ＣＰＵ使用率又はメモリ使用率であれば、５０％〜１００％の間の任意の数値を閾値として用いてもよいし、通信量であれば、１秒当たりのデータ受信量が数十メガバイト程度の数値を閾値として用いてもよい。

実行部２０７は、負荷判定部２０６により処理負荷が閾値未満であると判定された場合に、サーバ２０の表示制御部２０４に、在庫情報に基づく表示制御を実行させる。例えば、実行部２０７は、負荷判定部２０６により処理負荷が閾値以上であると判定された場合は、表示制御部２０４に対し、在庫情報に基づく表示制御の実行を待機させ、負荷判定部２０６により処理負荷が閾値以上であると判定された場合に、表示制御部２０４に対し、在庫情報に基づく表示制御の実行を指示する。

変形例（１−４）によれば、サーバ２０の処理負荷が閾値未満であると判定された場合に、在庫情報に基づく閲覧済みホテルの表示制御が実行されることで、サーバ２０の処理負荷を効果的に軽減することができる。また、閲覧済みホテルの画像Ｇ１５０だけを先にユーザ端末１０に送信しておき、在庫の有無を示すメッセージＭ１５１を後から送信する場合には、トップ画面Ｇ１をより早く表示させることができる。

（１−５）また例えば、閲覧済みホテルの検索で用いられた利用日で在庫がない場合には、検索条件に含まれる利用日と利用人数のうち、利用日だけを変更して在庫の有無を判定し、在庫がある別の利用日をユーザに提案してもよい。なお、別の利用日としては、検索条件に含まれる利用日付近（例えば、１日以内〜数週間以内）とした方が好ましいが、当該利用日付近で在庫がなければ、在庫の有無を判定する範囲を徐々に広げてもよい。

図２２は、変形例（１−５）におけるトップ画面Ｇ１の変化の一例を示す図である。図２２のトップ画面Ｇ１Ｓは、図５のトップ画面Ｇ１Ｃ、図１９のトップ画面Ｇ１Ｉ、及び図１９のトップ画面Ｇ１Ｍと同様である。ここでは、例えば、「ホテルＡ」〜「ホテルＥ」の検索で用いられた利用日を、「２０１８年４月１日」〜「２０１８年４月３日」とする。

この状態から、例えば、「ホテルＡ」の上記利用日での残室がなくなったとすると、トップ画面Ｇ１Ｔに示すように、「ホテルＡ」の画像Ｇ１５０Ａ上に、「ＳＯＬＤ ＯＵＴ」といったメッセージＭ１５１Ａが表示される。一方、他の利用日で残室がある場合には、その旨を示すメッセージＭ１５３Ａが表示される。例えば、「２０１８年４月３日」〜「２０１８年４月５日」に旅行プランを変更すれば「ホテルＡ」の残室がある場合に、メッセージＭ１５３Ａが表示される。

表示制御部２０４は、閲覧済みホテルに関連付けられた検索条件を満たす利用日の在庫情報が示す在庫がない場合に、在庫がある他の利用日に基づいて表示制御を行う。例えば、表示制御部２０４は、閲覧済みホテルに関連付けられた検索条件を満たす利用日の在庫情報が示す在庫がない場合に、利用日を変更して在庫の有無を判定する。

変更後の利用日は、元々の利用日と異なる日であればよいが、ここでは、１日ずつずらして在庫の有無が判定されるものとする。表示制御部２０４は、在庫がある利用日を発見するまで、利用日の変更と在庫の有無の判定を繰り返してもよいし、所定個数の利用日について在庫の有無を判定しても、在庫がある利用日を発見できなかった場合には、利用日の変更と在庫の有無の判定を終了してもよい。

例えば、表示制御部２０４は、在庫がある他の利用日を発見した場合には、その旨を示すメッセージＭ１５３を表示させる。メッセージＭ１５３は、画像Ｇ１５０に関連付けて表示すればよく、図２２のように、画像Ｇ１５０を指し示すようにして表示させてもよいし、画像Ｇ１５０上に表示させてもよい。また例えば、表示制御部２０４は、在庫がある他の利用日を発見した場合に、メッセージＭ１５３を表示させるのではなく、画像Ｇ１５０内にその旨を表示させてもよい。

変形例（１−５）によれば、閲覧済みホテルの残室がない場合に、残室がある他の利用日に基づいて表示制御が行われ、残室がある他の利用日をユーザに提案することができるので、ユーザインタフェースの利便性を効果的に高めることができる。また、ユーザが、残室がある他の利用日を自分で再検索するといった手間を省くことができる。サーバ２０からしてみれば、ユーザによる再検索要求を何度も受け付けて、そのたびに検索処理を実行することがなくなるので、サーバ２０の処理負荷を減らすとともに、ネットワーク上で送受信される検索要求や検索結果を減らすことができるので、通信負荷を減らすこともできる。

（１−６）また例えば、各ホテルは、ユーザによる予約が可能なので、実施形態２の処理を実施形態１に適用し、ユーザが予約したホテルと検索条件が同じ閲覧済みホテルについては、在庫の有無を判定する対象から除外してもよい。即ち、閲覧済みホテルのうち、予約済みのホテルと検索条件が異なる閲覧済みホテルについてだけ、在庫の有無が判定され、予約済みのホテルと検索条件が同じ閲覧済みホテルについては、在庫の有無を判定しないようにしてもよい。

本変形例では、表示制御部２０４は、ユーザにより予約されたホテルの予約内容に関する内容情報に更に基づいて、表示制御を行う。ここでは、実施形態２と同様に、予約済みホテルの検索で用いられた検索条件が内容情報に相当する場合を説明する。

例えば、表示制御部２０４は、閲覧履歴データベースＤＢ３に基づいて、予約済みホテルに関連付けられた検索条件を取得し、当該検索条件と同じ検索条件の他の閲覧済みホテルについては、在庫情報に基づく表示制御の対象外とする。一方、表示制御部２０４は、予約済みホテルに関連付けられた検索条件と同じ検索条件の他の閲覧済みホテルについては、在庫情報に基づいて表示制御を行う。表示制御の内容自体は、実施形態１で説明した通りである。

変形例（１−６）によれば、予約済みホテルの予約内容に関する内容情報に基づいて、閲覧済みホテルの表示制御が行われることで、閲覧済みホテルの一覧をただ表示させるのではなく、内容情報と検索条件とが閲覧済みホテルの表示に影響するので、ユーザインタフェースの利便性を高めることができる。例えば、予約済みホテルの利用日と一致する利用日を検索条件に含む閲覧済みホテルについては、ユーザにとって不要な情報である蓋然性が高いので、このような不要な情報がユーザに提供されることを防止できる。また、予約済みホテルとの関係で不要な閲覧済みホテルの在庫判定が行われなくなり、在庫判定の対象となる閲覧済みホテルを絞ることができるので、表示制御処理を高速化しつつ、サーバ２０の処理負荷を軽減することができる。

（１−７）また例えば、ホテル検索をしている間に、ユーザの予定が変わり、検索条件が変更されることがある。この場合、変更後の検索条件とは異なる検索条件（古い検索条件）の閲覧済みホテルについては、ユーザが興味を失っている可能性があるので、在庫の有無を判定しないようにしてもよい。即ち、ユーザが入力した最新の検索条件と異なる検索条件の閲覧済みホテルについては、在庫の有無を判定しないようにしてもよい。

本変形例では、データ記憶部２００は、ユーザ端末１０から受信した検索条件を記憶する。例えば、検索部２０１は、ホテル検索を実行した場合に、ユーザが入力した検索条件を、当該ユーザのユーザＩＤに関連付けてデータ記憶部２００に記録する。データ記憶部２００には、最新の検索条件だけが記録されてもよいし、ユーザが入力した検索条件が時系列的に記録されてもよい。

表示制御部２０４は、ユーザにより入力された検索条件が変更された場合に、変更後の検索条件に更に基づいて表示制御を行う。例えば、表示制御部２０４は、閲覧済みホテルのうち、最新の検索条件と同じ検索条件の閲覧済みホテルについては、在庫情報に基づいて表示制御を行い、最新の検索条件とは異なる検索条件の閲覧済みホテルについては、在庫情報に基づく表示制御の対象外とする。

変形例（１−７）によれば、検索条件が変更された場合に、変更後の検索条件に基づいて表示制御が行われ、変更後の検索条件との関係で、不要な在庫判定が行われなくなり、在庫判定の対象となる閲覧済みホテルを絞ることができるので、表示制御処理を高速化しつつ、サーバ２０の処理負荷を軽減することができる。

［３−２．実施形態２に係る変形例］
次に、実施形態２に係る変形例を説明する。図２３は、実施形態２に係る変形例の機能ブロック図である。図２３に示すように、実施形態２に係る変形例では、実施形態２で説明した機能に加えて、経過判定部２０５が実現される。

（２−１）例えば、実施形態２では、ユーザが予約したホテルと同じ検索条件の閲覧済みホテルは、表示領域Ａ１５に表示させないようにしたが、表示領域Ａ１５には、航空券、レンタカー、又はバスの各々の閲覧履歴を表示させてもよく、これらについては、検索条件が同じであった場合の方が、ユーザが必要としている情報である蓋然性が高い。

例えば、ユーザが「東京」のホテルを、「２０１８年４月１日」〜「２０１８年４月３日」の利用日で予約した場合に、航空券、レンタカー、又はバスを合わせて予約する可能性がある。この利用日において、ユーザが、航空券、レンタカー、又はバスを検索して閲覧していた場合には、これらの閲覧履歴を優先表示させてもよい。優先表示の意味は、実施形態１の変形例で説明した通りである。

図２４は、変形例（２−１）におけるトップ画面Ｇ１の変化の一例を示す図である。図２４のトップ画面Ｇ１Ｕは、図１３のトップ画面Ｇ１Ｇと同様である。この状態で、ユーザ「ホテルＦ」を予約すると、トップ画面Ｇ１Ｖに示すように、同じ検索条件の「ホテルＧ」と「ホテルＨ」が消去され、「ホテルＦ」と検索条件の利用日が一致する「東京−札幌 航空券」を示す画像Ｇ１５４が優先表示される。

例えば、画像Ｇ１５４が示す航空券は、ユーザが、出発日が「２０１８年４月１日」であり、出発地が「札幌」であり、かつ、到着地が「東京」といった検索条件を入力して検索し、航空券の詳細のページを閲覧したものである。また例えば、画像Ｇ１５４が示す航空券は、出発日が「２０１８年４月３日」であり、出発地が「東京」であり、かつ、到着地が「札幌」といった検索条件を入力して検索し、航空券の詳細のページを閲覧したものであってもよい。この航空券の出発日は、予約済みの「ホテルＦ」の利用日と一致し、かつ、ホテルとは異なる種類（即ち、提供者が異なるサービス）の利用日なので、本変形例では、積極的に表示される。

なお、ここでは、航空券を一例として説明したが、レンタカー又はバスについても、「ホテルＦ」の利用日と一致する利用日又は出発日を検索条件にして検索され、ユーザが閲覧していた場合には、これら閲覧済みのレンタカー又はバスの画像が表示領域Ａ１５に表示されるようにしてもよい。

本変形例の表示制御部２０４は、内容情報に対応する内容を含む検索条件が閲覧済みアイテムに関連付けられている場合に、閲覧済みアイテムを優先表示する。内容情報に対応する内容の意味は、実施形態２で説明した通りである。表示制御部２０４は、予約済みアイテムとは異なる種類の閲覧済みアイテム（即ち、予約済みアイテムとは提供者が異なる閲覧済みアイテム）について、内容情報に対応する内容を含む検索条件が関連付けられている場合に優先表示をする。

例えば、表示制御部２０４は、予約済みのホテルの利用日と一致する利用日を含む検索条件が、閲覧済みの航空券、レンタカー、又はバスに関連付けられている場合に、当該閲覧済みの航空券、レンタカー、又はバスを優先表示する。また例えば、表示制御部２０４は、予約済みの航空券の出発日又は到着日と一致する利用日を含む検索条件が、閲覧済みのホテル、レンタカー、又はバスに関連付けられている場合に、当該閲覧済みのホテル、レンタカー、又はバスを優先表示する。

また例えば、表示制御部２０４は、予約済みのレンタカーの出発日又は返却日と一致する利用日を含む検索条件が、閲覧済みのホテル、航空券、又はバスに関連付けられている場合に、当該閲覧済みのホテル、航空券、又はバスを優先表示する。また例えば、表示制御部２０４は、予約済みのバスの出発日又は到着日と一致する利用日を含む検索条件が、閲覧済みのホテル、航空券、又はレンタカーに関連付けられている場合に、当該閲覧済みのホテル、航空券、又はレンタカーを優先表示する。

変形例（２−１）によれば、予約済みホテルの予約内容に関する内容情報に対応する内容を含む検索条件が関連付けられた閲覧済み航空券等が優先表示され、ユーザにとって有益な情報を提供するとともに、当該航空券の予約をしやすくなるので、ユーザインタフェースの利便性を効果的に高めることができる。

（２−２）また例えば、実施形態２では、ユーザが予約したホテルに関連付けられた検索条件が内容情報に相当する場合を説明したが、内容情報は、ユーザによりアイテムが予約又は購入された場合に、ユーザにより指定された予約内容を格納するためのデータベースに格納された情報であってもよい。ここでは、当該データベースを予約データベースＤＢ４とするが、他のデータベースであってもよい。

本変形例の表示制御部２０４は、予約データベースＤＢ４に格納された内容情報と、閲覧済みアイテムに関連付けられた検索条件と、に基づいて、表示制御を行う。例えば、表示制御部２０４は、予約データベースＤＢ４のうち、トップ画面Ｇ１の表示要求をしたユーザのユーザＩＤが格納されたレコードを特定し、当該レコードの予約情報を取得する。そして、表示制御部２０４は、当該予約情報に含まれる利用日や利用人数といった情報を、内容情報として取得する。内容情報が取得された以降の処理は、実施形態２で説明した通りである。

変形例（２−２）によれば、予約データベースＤＢ４に格納された予約済みホテルの予約情報と、閲覧済みホテルの検索条件と、に基づいて、閲覧済みアイテムの表示が制御され、検索条件の入力後に予約内容が変更した場合であっても、実際の予約日に応じて不要な情報を提供しないようにすることができるので、ユーザインタフェースの利便性を効果的に高めることができる。

（２−３）また例えば、ユーザが予約したホテルの利用日が経過した場合には、利用日だけを変えて似たようなホテルをユーザが利用することがあるので、検索条件を同じとする閲覧済みホテルを再び表示領域Ａ１５に表示させてもよい。

図２５は、変形例（２−３）におけるトップ画面Ｇ１の変化の一例を示す図である。図２５のトップ画面Ｇ１Ｗは、図１３のトップ画面Ｇ１Ｇ及び図２４のトップ画面Ｇ１Ｕと同様である。この状態で、ユーザが「ホテルＦ」を予約すると、実施形態２と同様の処理により、トップ画面Ｇ１Ｘに示すように、同じ検索条件の「ホテルＧ」と「ホテルＨ」が消去される。その後、ユーザが「ホテルＦ」の利用日が経過すると、トップ画面Ｇ１Ｙに示すように、「ホテルＦ」、「ホテルＧ」、及び「ホテルＨ」の画像Ｇ１５０Ｆ〜Ｇ１５０Ｈが再び表示される。

本変形例の検索システムＳは、経過判定部２０５を含む。経過判定部２０５は、実施形態１の変形例と同様の機能を有していてもよいが、ここでは、閲覧済みホテルに関連付けられた検索条件が示す利用日と、予約されたホテルの利用日と、の少なくとも一方が経過したか否かを判定する。経過の意味は、実施形態１の変形例で説明した通りである。例えば、経過判定部２０５は、リアルタイムクロック等から取得した現在日時に基づいて、閲覧済みホテルに関連付けられた検索条件が示す利用日が経過したか否かを判定したり、予約済みホテルの利用日が経過したか否かを判定したりする。

表示制御部２０４は、経過判定部２０５の判定結果に更に基づいて、表示制御を行う。例えば、表示制御部２０４は、経過判定部２０５により利用日が経過していないと判定された場合には、閲覧済みホテルの表示の制限を継続し、経過判定部２０５により利用日が経過していないと判定された場合には、閲覧済みホテルの表示の制限を解除し、当該閲覧済みホテルを表示させる。

変形例（２−３）によれば、予約済みホテルの利用日と、閲覧済みホテルの利用日と、の少なくとも一方が経過したか否かの判定結果に基づいて表示制御が行われ、利用日が経過した不要な情報がユーザに提供されることを防止し、ユーザインタフェースの利便性を効果的に高めることができる。また、利用日が経過した不要な閲覧済みホテルについてまで表示制御をしないようにすることで、表示制御処理を高速化しつつ、サーバ２０の処理負荷を軽減することができる。

［３−３．その他変形例］
例えば、実施形態１と実施形態２を組み合わせてもよい。また例えば、実施形態１の変形例と、実施形態２の変形例と、を組み合わせてもよい。

また例えば、旅行予約サービスで取り扱われるホテルなどは、旅行商品と呼ばれることもあるので、ユーザがホテルなどを予約することは、商品を購入することに相当してもよい。この場合、実施形態１−２において「予約」と記載した箇所は、「購入」と読み替えることができる。検索システムＳにおけるアイテムは、予約又は購入が可能なアイテムであればよい。

また例えば、主にホテル予約の場面で検索システムＳが利用される場合を説明したが、航空券予約、レンタカー予約、バス予約、列車予約、レストラン予約、又はオプションツアー予約の場合にも同様の処理を適用可能である。例えば、表示領域Ａ１５には、ユーザが閲覧したホテル、航空機、レンタカー、及びバスが混在して表示されてもよいし、ユーザがホテル予約をする場合にはホテルの閲覧履歴だけが表示され、航空機予約をする場合には航空機の閲覧履歴だけが表示されるといったように、トップ画面Ｇ１から行われる予約の種類に応じた閲覧履歴が表示されるようにしてもよい。

また例えば、実施形態１の処理を航空券予約に適用した場合、閲覧済みの航空券に関連付けられた検索条件を満たす出発日の在庫情報に基づいて、閲覧済みの航空券の表示が制御される。また例えば、実施形態１の処理をレンタカー予約に適用した場合、閲覧済みのレンタカー会社に関連付けられた検索条件を満たす出発日の在庫情報に基づいて、閲覧済みのレンタカー会社の表示が制御される。また例えば、実施形態１の処理をバス予約に適用した場合、閲覧済みのバスに関連付けられた検索条件を満たす出発日の在庫情報に基づいて、閲覧済みのバスの表示が制御される。

また例えば、実施形態１の処理を列車予約に適用した場合、閲覧済みの列車に関連付けられた検索条件を満たす出発日の在庫情報に基づいて、閲覧済みの列車の表示が制御される。また例えば、実施形態１の処理をレストラン予約に適用した場合、閲覧済みのレストランに関連付けられた検索条件を満たす利用日の在庫情報に基づいて、閲覧済みのレストランの表示が制御される。また例えば、実施形態１の処理をオプションツアー予約に適用した場合、閲覧済みのオプションツアーに関連付けられた検索条件を満たす利用日の在庫情報に基づいて、閲覧済みのオプションツアーの表示が制御される。

また例えば、実施形態２の処理を航空券予約に適用した場合、予約済み航空券の利用日と、閲覧済み航空券の利用日と、に基づいて、閲覧済み航空券の表示が制御される。また例えば、実施形態２の処理をレンタカー予約に適用した場合、予約済みレンタカーの利用日と、予約済みレンタカーの利用日と、に基づいて、閲覧済みレンタカーの表示が制御される。また例えば、実施形態２の処理をバス予約に適用した場合、予約済みバスの利用日と、閲覧済みバスの利用日と、に基づいて、閲覧済みバスの表示が制御される。

また例えば、実施形態２の処理を列車予約に適用した場合、予約済み列車の利用日と、閲覧済み列車の利用日と、に基づいて、閲覧済み列車の表示が制御される。また例えば、実施形態２の処理をレストラン予約に適用した場合、予約済みレストランの利用日と、閲覧済みレストランの利用日と、に基づいて、閲覧済みレストランの表示が制御される。また例えば、実施形態２の処理をオプションツアー予約に適用した場合、予約済みツアーの利用日と、閲覧済みツアーの利用日と、に基づいて、閲覧済みツアーの表示が制御される。

また例えば、検索システムＳを旅行予約サービスで利用する場面を説明したが、他の任意のサービスで利用されるようにしてもよい。

例えば、検索システムＳを電子商取引で利用する場合には、商品がアイテムに相当し、商品のインデックスとなりうる情報がサブアイテムに相当する。例えば、サブアイテムは、商品のカテゴリ、サイズや色などの属性、商品タイトル、又は商品説明に含まれるキーワードといった情報となる。例えば、衣料品・家具・家電などの商品は、サイズや色などの属性ごとに在庫情報を有することがあるので、実施形態１の処理を電子商取引に適用した場合、閲覧済み商品に関連付けられた検索条件を満たす属性の在庫情報に基づいて、閲覧済み商品の表示が制御されるようにしてもよい。

また例えば、実施形態２の処理を電子商取引に適用した場合、内容情報は、購入内容に関する情報となる。例えば、購入された商品の属性、カテゴリ、商品タイトル、及び商品説明といった情報は、内容情報の一例である。この場合、表示制御部２０４は、ユーザにより商品が購入された場合に、購入内容に関する内容情報と、閲覧済み商品に関連付けられた検索条件と、に基づいて、閲覧済み商品の表示を制御することになる。

また例えば、ユーザにより購入された商品が閲覧済み商品の１つである場合には、内容情報は、購入された閲覧済み商品の検索で用いられた検索条件となる。また例えば、内容情報は、複数のサブアイテムのうち、購入内容に関する少なくとも１つのサブアイテムに関する情報となり、例えば、サイズや色といった属性である。サイズ違いの商品や色違いの商品があった場合に、内容情報は、どのサイズの商品が購入されたかを示したり、どの色の商品が購入されたかを示したりすることになる。

また例えば、表示制御部２０４は、ユーザにより購入された商品との関係で利用できない商品を特定し、当該特定した閲覧済み商品の表示制御が行われるようにしてもよい。また例えば、内容情報は、ユーザにより商品が購入された場合に、ユーザにより指定された購入内容を格納するためのデータベースに格納された情報であってもよい。

また例えば、検索システムＳを、コンサートやイベントなどにおけるチケット販売で利用する場合には、チケットがアイテムに相当し、チケットのインデックスとなりうる公演日や席種といった情報がサブアイテムに相当する。例えば、実施形態１の処理をチケット販売に適用する場合には、閲覧済みチケット（閲覧済み公演）に関連付けられた検索条件を満たす公演日・席種の在庫情報に基づいて、閲覧済みチケットの表示が制御されるようにしてもよい。また例えば、実施形態２の処理をチケット販売に適用する場合には、ユーザによりチケットが購入された場合に、購入済みチケット（購入済み公演）の公演日と、閲覧済みチケットに関連付けられた公演日と、に基づいて、閲覧済みチケットの表示が制御されるようにしてもよい。

また例えば、検索システムＳを、セミナーなどのイベント予約で利用する場合には、イベントがアイテムに相当し、イベントのインデックスとなりうる開催日といった情報がサブアイテムに相当する。例えば、実施形態１の処理をイベント予約に適用する場合には、閲覧済みイベントに関連付けられた検索条件を満たす開催日の在庫情報（残席情報）に基づいて、閲覧済みイベントの表示が制御されるようにしてもよい。また例えば、実施形態２の処理をイベント予約に適用する場合には、ユーザによりイベントが予約された場合に、予約済みイベントの開催日と、予約済みイベントに関連付けられた開催日と、に基づいて、予約済みイベントの表示が制御されるようにしてもよい。

また例えば、閲覧部２０２は、ユーザ端末１０において実現されてもよい。この場合、閲覧部２０２は、制御部１１を主として実現される。閲覧部２０２は、ユーザにより選択されたアイテムの表示データをサーバ２０から受信し、当該表示データに基づいて、ユーザにより選択されたアイテムを閲覧させる。また例えば、表示制御部２０４が実行する処理は、ユーザ端末１０の表示制御部１０２で実行されてもよい。即ち、表示制御に係る主な処理が、ユーザ端末１０において実行されてもよい。例えば、実施形態１において、表示制御部１０２は、サーバ２０から在庫情報を受信し、メッセージＭ１５１を表示させたり、画像Ｇ１５０を表示させるか否かを決定したりしてもよい。また例えば、実施形態２において、表示制御部１０２は、サーバ２０から内容情報を受信し、閲覧済みアイテムの表示を制御してもよい。

また例えば、ユーザ端末１０とサーバ２０とで機能が分担されてもよい。例えば、ユーザ端末１０で閲覧部２０２が実現され、他の機能がサーバ２０で実現されてもよい。他にも例えば、ユーザ端末１０で表示制御部２０４が実現され、他の機能がサーバ２０で実現されてもよい。他にも例えば、データ記憶部２００で記憶されるものとして説明したデータは、サーバ２０とは異なるデータベースサーバによって記憶されてもよいし、検索システムＳの外部にあるデータベースサーバによって記憶されていてもよい。

Claims (8)

1. 予約又は購入が可能なアイテムの検索システムであって、
   ユーザにより入力された検索条件に基づいて、アイテム検索を実行する検索手段と、
   前記検索手段の検索結果の中から、前記ユーザにより選択されたアイテムを閲覧させる閲覧手段と、
   閲覧済みアイテムと、検索で用いられた検索条件と、を関連付けて記憶手段に記録する関連付け手段と、
   前記ユーザによりアイテムが予約又は購入され、かつ、予約内容又は購入内容に関する内容情報に対応する内容を含む検索条件が前記閲覧済みアイテムに関連付けられている場合に、当該検索条件が関連付けられている前記閲覧済みアイテムを優先表示する表示制御手段と、
   を含むことを特徴とする検索システム。
2. 前記記憶手段に記録された検索条件は、複数のサブアイテムの各々に関する条件を含み、
   前記内容情報は、前記複数のサブアイテムのうち、予約内容又は購入内容に関する少な
   くとも１つのサブアイテムに関する情報であり、
   前記内容情報に対応する内容を含む検索条件は、前記内容情報が示すサブアイテムの値と一致する条件を含む、
   ことを特徴とする請求項１に記載の検索システム。
3. 前記サブアイテムは、利用日であり、
   前記内容情報に対応する内容を含む検索条件は、前記内容情報が示す利用日と一致する条件を含む、
   ことを特徴とする請求項２に記載の検索システム。
4. 前記表示制御手段は、前記内容情報に対応する内容を含む検索条件が関連付けられている前記閲覧済みアイテムに関連付けて別の画像を表示させることによって、優先表示をする、
   ことを特徴とする請求項１〜３の何れかに記載の検索システム。
5. 前記表示制御手段は、前記内容情報に対応する内容を含む検索条件が関連付けられている前記閲覧済みアイテムの表示態様又は表示位置を変えることによって、優先表示をする、
   ことを特徴とする請求項１〜４の何れかに記載の検索システム。
6. 前記ユーザにより予約又は購入されたアイテムは、旅行商品であり、
   前記内容情報に対応する内容を含む検索条件が関連付けられている前記閲覧済みアイテムは、前記旅行商品とは異なる閲覧済み旅行商品である、
   ことを特徴とする請求項１〜５の何れかに記載の検索システム。
7. 予約又は購入が可能なアイテムの検索方法であって、コンピュータに、
   ユーザにより入力された検索条件に基づいて、アイテム検索を実行する検索ステップと、
   前記検索ステップの検索結果の中から、前記ユーザにより選択されたアイテムを閲覧させる閲覧ステップと、
   閲覧済みアイテムと、検索で用いられた検索条件と、を関連付けて記憶手段に記録する関連付けステップと、
   前記ユーザによりアイテムが予約又は購入され、かつ、予約内容又は購入内容に関する内容情報に対応する内容を含む検索条件が前記閲覧済みアイテムに関連付けられている場合に、当該検索条件が関連付けられている前記閲覧済みアイテムを優先表示する表示制御ステップと、
   を含むことを特徴とする検索方法。
8. ユーザにより入力された検索条件に基づいて、アイテム検索を実行する検索手段、
   前記検索手段の検索結果の中から、前記ユーザにより選択されたアイテムを閲覧させる閲覧手段、
   閲覧済みアイテムと、検索で用いられた検索条件と、を関連付けて記憶手段に記録する関連付け手段、
   前記ユーザによりアイテムが予約又は購入され、かつ、予約内容又は購入内容に関する内容情報に対応する内容を含む検索条件が前記閲覧済みアイテムに関連付けられている場合に、当該検索条件が関連付けられている前記閲覧済みアイテムを優先表示する表示制御手段、
   としてコンピュータを機能させるためのプログラム。

Images