JP7306800B2 - 旅行計画システム、旅行計画方法、及びプログラム - Google Patents

Description

本発明は、旅行計画システム、旅行計画方法、及びプログラムに関する。

従来、ユーザの旅程に組み込むアイテムを検索する技術が知られている。例えば、特許文献１には、ユーザにより入力された時間及び場所等の検索条件に基づいて、アイテムの一例である宿泊施設を検索し、検索結果の中からユーザによる宿泊施設の選択を受け付けるシステムが記載されている。

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

ユーザは、１種類のアイテムだけではなく、複数種類のアイテムを旅程に組み込むことがある。例えば、ユーザは、宿泊施設だけではなく、往復の交通手段、アクティビティ、レンタカー、及びレストランといった複数種類のアイテムを旅程に組み込むことがある。

しかしながら、特許文献１のシステムでは、ユーザは、ホテルを検索した後に、航空券等の他の種類のアイテムを提供するウェブサイトにアクセスし、ホテルの検索時と同様の検索条件を再び入力して他の種類のアイテムを探す必要があるので、非常に手間がかかっていた。

本発明は上記課題に鑑みてなされたものであって、その目的は、複数種類のアイテムを含む旅程を作成する手間を軽減することが可能な旅行計画システム、旅行計画方法、及びプログラムを提供することである。

上記課題を解決するために、本発明に係る旅行計画システムは、ユーザにより入力された時間及び場所に基づいて、旅程に組み込むアイテムを検索する第１検索手段と、前記第１検索手段の検索結果の中から、前記ユーザによる選択を受け付ける受付手段と、前記ユーザにより選択されたアイテムの時間及び場所に基づいて、他の種類のアイテムを検索する第２検索手段と、前記第２検索手段により検索されたアイテムを、選択可能に提示する提示手段と、を含むことを特徴とする。

本発明に係る旅行計画方法は、ユーザにより入力された時間及び場所に基づいて、旅程に組み込むアイテムを検索する第１検索ステップと、前記第１検索ステップの検索結果の中から、前記ユーザによる選択を受け付ける受付ステップと、前記ユーザにより選択されたアイテムの時間及び場所に基づいて、他の種類のアイテムを検索する第２検索ステップと、前記第２検索ステップにより検索されたアイテムを、選択可能に提示する提示ステップと、を含むことを特徴とする。

本発明に係るプログラムは、ユーザにより入力された時間及び場所に基づいて、旅程に組み込むアイテムを検索する第１検索手段、前記第１検索手段の検索結果の中から、前記ユーザによる選択を受け付ける受付手段、前記ユーザにより選択されたアイテムの時間及び場所に基づいて、他の種類のアイテムを検索する第２検索手段、前記第２検索手段により検索されたアイテムを、選択可能に提示する提示手段、としてコンピュータを機能させる。

本発明の一態様によれば、前記旅行計画システムは、前記ユーザの出発地を取得する出発地取得手段と、他のユーザにより選択された、現地アイテムと、当該他のユーザの出発地と現地との間の交通手段アイテムと、を特定する特定手段と、を更に含み、前記第２検索手段は、前記ユーザにより現地アイテムが選択された場合に、出発地と、現地アイテムの場所と、が前記ユーザと対応する前記他のユーザにより選択された交通手段アイテムに基づいて、前記ユーザの出発地と現地との間の交通手段アイテムを検索する、ことを特徴とする。

本発明の一態様によれば、前記第２検索手段は、前記他のユーザにより選択された交通手段アイテムに対応する交通手段アイテムの在庫がない場合に、現地への到着時間が、前記他のユーザにより選択された交通手段アイテムよりも早い交通手段アイテムを検索する、ことを特徴とする。

本発明の一態様によれば、前記第２検索手段は、前記他のユーザにより選択された交通手段アイテムに対応する交通手段アイテムの在庫がない場合に、現地からの出発時間が、前記他のユーザにより選択された交通手段アイテムよりも遅い交通手段アイテムを検索する、ことを特徴とする。

本発明の一態様によれば、前記旅程は、複数の期間にまたがる旅程であり、前記第２検索手段は、前記期間ごとに、当該期間におけるアイテムの時間及び場所に基づいて検索を実行し、前記提示手段は、前記期間ごとに、前記第２検索手段により検索されたアイテムを提示する、ことを特徴とする。

本発明の一態様によれば、前記旅行計画システムは、前記ユーザにより登録されたユーザ登録情報、又は、前記ユーザの通信環境に基づいて、前記ユーザの出発地を取得する出発地取得手段を更に含み、前記第２検索手段は、前記出発地取得手段により取得された前記ユーザの出発地に基づいて検索を実行する、ことを特徴とする。

本発明の一態様によれば、前記第２検索手段は、前記ユーザにより選択されたアイテムの時間が経過したかを判定し、当該判定結果に基づいて検索を実行する、ことを特徴とする。

本発明の一態様によれば、前記第２検索手段は、前記ユーザにより新たな時間及び場所が入力されたかを判定し、当該判定結果に基づいて検索を実行する、ことを特徴とする。

本発明の一態様によれば、前記ユーザは、複数の旅程を作成可能であり、前記第２検索手段は、前記旅程ごとに、当該旅程に含まれるアイテムの時間及び場所に基づいて検索を実行し、前記提示手段は、前記旅程ごとに、前記第２検索手段により検索されたアイテムを提示する、ことを特徴とする。

本発明の一態様によれば、前記第２検索手段は、前記ユーザにより選択された複数の宿泊施設アイテムの各々の日付が連続している場合に、各宿泊施設アイテムが同じ旅程に含まれると判定する、ことを特徴とする。

本発明の一態様によれば、前記第２検索手段は、前記ユーザにより選択されたアイテムの時間に基づいて前記旅程の期間を特定し、当該期間に基づいて検索を実行する、ことを特徴とする。

本発明の一態様によれば、前記第２検索手段は、前記ユーザにより選択されたアイテムの時間及び場所に基づいて他の種類のアイテムの利用可能性を判定し、当該判定結果に基づいて検索を実行する、ことを特徴とする。

本発明によれば、複数種類のアイテムを含む旅程を作成する手間を軽減することが可能となる。

旅行計画システムの全体構成を示す図である。 トップ画面の一例を示す図である。 検索が実行される様子を示す図である。 旅行かご画面の一例を示す図である。 レコメンドされたアイテムが旅行かごに追加される様子を示す図である。 本実施形態の旅行計画システムＳで実現される機能の一例を示す機能ブロック図である。 アイテムデータベースのデータ格納例を示す図である。 ユーザデータベースのデータ格納例を示す図である。 レコメンドデータベースのデータ格納例を示す図である。 旅行計画システムにおいて実行される処理の一例を示すフロー図である。 旅行計画システムにおいて実行される処理の一例を示すフロー図である。 変形例の機能ブロック図である。 変形例（１）における旅行かご画面の一例を示す図である。 変形例（２）における旅行かご画面の一例を示す図である。 変形例（３）における旅行かご画面の一例を示す図である。 変形例（４）における旅行かご画面の一例を示す図である。 変形例（８）における旅行かご画面の一例を示す図である。

［１．旅行計画システムの全体構成］
以下、本発明に係る旅行計画システムの実施形態の例を説明する。図１は、旅行計画システムの全体構成を示す図である。図１に示すように、旅行計画システムＳは、ユーザ端末１０、ウェブサーバ２０、分析サーバ３０、及びデータベースサーバ４０を含み、これらは、インターネットなどのネットワークＮに接続可能である。

なお、図１ではユーザ端末１０、ウェブサーバ２０、分析サーバ３０、及びデータベースサーバ４０の各々を１台ずつ示しているが、これらは複数台あってもよい。更に、ウェブサーバ２０、分析サーバ３０、及びデータベースサーバ４０の３つのサーバコンピュータが旅行計画システムＳに含まれる場合を例に挙げるが、旅行計画システムＳには、１つのサーバコンピュータだけが含まれてもよいし、２つ又は４つ以上のサーバコンピュータが含まれてもよい。

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

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

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

ウェブサーバ２０は、サーバコンピュータである。ウェブサーバ２０は、ウェブサイトを管理する。例えば、ユーザ端末１０のウェブブラウザ上で画面が表示される場合には、ウェブサーバ２０は、ユーザ端末１０からＨＴＴＰリクエストを受け付けると、ユーザ端末１０に対し、ＨＴＴＰレスポンスを送信する。また例えば、ユーザ端末１０のアプリケーション上で画面が表示される場合には、ウェブサーバ２０は、ユーザ端末１０から、アプリケーションで利用される通信プロトコルで定められたリクエストを受け付けると、ユーザ端末１０に対し、当該通信プロトコルで定められたレスポンスを送信する。ウェブサーバ２０は、制御部２１、記憶部２２、及び通信部２３を含む。制御部２１、記憶部２２、及び通信部２３の物理的構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。

分析サーバ３０は、サーバコンピュータである。分析サーバ３０は、ユーザに対するレコメンドの分析を行う。分析サーバ３０は、制御部３１、記憶部３２、及び通信部３３を含む。制御部３１、記憶部３２、及び通信部３３の物理的構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。

データベースサーバ４０は、サーバコンピュータである。例えば、データベースサーバ４０は、後述する各種データベースを記憶する。データベースサーバ４０は、制御部４１、記憶部４２、及び通信部４３を含む。制御部４１、記憶部４２、及び通信部４３の物理的構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。

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

［２．旅行計画システムの概要］
旅行計画システムＳは、ユーザに旅行予約サービスを提供し、旅程の作成を支援する。旅程は、旅行の計画、行程、又は日程であり、少なくとも１つのアイテムから構成される。アイテムは、旅程の構成要素であり、旅行中の個々の予定である。別の言い方をすれば、アイテムは、予約又は購入の対象となる個々の旅行商品（例えば、施設、乗物、又はサービス）である。

旅程には、複数種類のアイテムを組み込むことができる。アイテムの種類は、宿泊施設、交通手段（移動手段）、レンタカー、アクティビティ（オプションツアー）、レストラン、又は観光施設といった任意の種類であってよい。宿泊施設は、ホテル、旅館、民宿、ペンション、又は民泊といった施設である。交通手段は、航空機、電車、バス、又は船舶といった手段である。観光施設は、水族館、動物園、テーマパーク、公園、寺、神社、又は競技場といった施設である。

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

図２は、トップ画面の一例を示す図である。図２に示すように、例えば、トップ画面Ｇ１には、アイテムの検索条件を入力するための入力フォームＦ１０～Ｆ１３と、検索を実行するためのボタンＢ１４と、が表示される。

検索条件は、検索で用いられるクエリであり、任意の条件を入力可能である。検索条件は、キーワードであってもよいし、予め定められた複数の数値の中から選択された数値であってもよいし、カテゴリのような属性情報であってもよい。数値は、時間、人数、又は予算といった条件の数値である。

なお、時間は、日付（年月日）だけを意味してもよいし、日付と時刻を含む日時を意味してもよい。更に、時間は、特定の時点を示してもよいし、大まかな期間を示してもよい。期間は、ある１日における時間帯を示してもよいし、複数の日にまたがる期間を示してもよい。例えば、アイテムが宿泊施設であれば、アイテムの時間は、チェックイン日、チェックイン時刻、チェックアウト日、及びチェックアウト時刻である。また例えば、アイテムが交通手段であれば、アイテムの時間は、出発日、出発時刻、到着日、及び到着時刻である。また例えば、アイテムがレンタカーであれば、アイテムの時間は、出発日、出発時刻、返却日、及び返却時刻である。また例えば、アイテムがアクティビティであれば、アイテムの時間は、利用日、集合時刻、及び解散時刻である。また例えば、アイテムがレストランであれば、アイテムの時間は、予約日と予約時刻である。また例えば、アイテムが観光施設であれば、アイテムの時間は、利用日と利用時刻である。

ユーザは、トップ画面Ｇ１から種々の検索条件を入力可能である。例えば、ホテルであれば、宿泊地、利用日（宿泊日）、利用人数、及び宿泊費といった検索条件が入力される。また例えば、航空券であれば、出発地、目的地、出発日、出発時刻、到着日、到着時刻、航空会社、及び運賃といった検索条件が入力される。また例えば、レンタカーであれば、出発場所、返却場所、利用日、利用時刻、車種、及びレンタル料といった検索条件が入力される。また例えば、バスであれば、出発地、目的地、出発日、出発時刻、到着日、到着時刻、バス会社、及び運賃といった検索条件が入力される。なお、検索条件として入力される時刻は、「１４時」のように特定の時点が入力されてもよいし、「１４時～１６時」といった時間帯（時間の幅）が入力されてもよい。

トップ画面Ｇ１では、ホテル、航空券、レンタカー、又はバスといったアイテムの種類ごとに、検索条件を入力可能となっている。なお、図２ではスペースの都合上省略しているが、トップ画面Ｇ１は、アクティビティ、レストラン、又は観光施設といった他の種類のアイテムの検索条件を入力可能であってもよい。

トップ画面Ｇ１では、旅行計画システムＳが取り扱う複数種類のアイテムのうち、検索対象のアイテムの種類を指定できるようになっている。本実施形態では、説明の簡略化のために、ユーザが１種類の検索対象を指定する場合を説明するが、「ホテル＋航空券」や「ホテル＋アクティビティ＋レストラン」のように複数種類のアイテムを一度に検索できるようにしてもよい。ここでは、ユーザが検索対象として「ホテル」を選択した場合の処理を説明する。

例えば、ユーザは、入力フォームＦ１０に、宿泊地などのキーワードを入力する。宿泊地は、キーワードで入力されなくてもよく、予め用意された地域リストの中から選択されるようにしてもよい。また例えば、入力フォームＦ１１には、チェックイン日が入力され、入力フォームＦ１２には、チェックアウト日が入力される。また例えば、入力フォームＦ１３には、利用人数が入力される。ユーザが、これらの検索条件を入力してボタンＢ１４を選択すると、検索が実行される。なお、ユーザは、入力フォームＦ１０～Ｆ１４の全てに検索条件を入力する必要はなく、一部の入力フォームに対してのみ検索条件を入力してもよい。

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

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

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

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

アイテム画面Ｇ３からホテルの予約をできるようにしてもよいが、本実施形態では、ユーザは、旅行かごにホテルを追加し、旅程を組み立てた後にまとめて予約するようになっている。旅行かごは、旅程に組み込まれたアイテムのリストであり、検討中のアイテムのリストである。別の言い方をすれば、旅行かごは、旅程を確定する前に（アイテムの予約を完了する前に）作成された仮の旅程である。旅行かごは、電子商取引におけるショッピングカートと似た概念である。ユーザは、複数種類のアイテムを旅行かごに追加して自分好みの旅程を計画し、これら複数種類のアイテムを予約する。

例えば、アイテム画面Ｇ３には、表示中のホテルを旅行かごに追加するためのボタンＢ３０が表示される。ユーザがボタンＢ３０を選択すると、アイテム画面Ｇ３に表示中の「ホテルＡ」が旅行かごに追加され、旅行かご画面が表示部１５に表示される。なお、ユーザは、検索条件で入力した時間を変更せずに、旅行かごにアイテムを追加してもよいし、検索条件で入力した時間を変更したうえで、旅行かごにアイテムを追加してもよい。即ち、ユーザは、検索時に入力した「ホテルＡ」の利用日を変更せずに旅行かごに追加してもよいし、利用日を変更したうえで旅行かごに追加してもよい。

図４は、旅行かご画面の一例を示す図である。図４に示すように、旅行かご画面Ｇ４の表示領域Ａ４０には、旅行かごの中身が表示される。旅行かごに複数のアイテムが追加された場合には、表示領域Ａ４０には、複数のアイテムが所定の順序で並べられる。アイテムの順序は、任意の条件で決定されるようにすればよく、例えば、旅行かごへの追加順であってもよいし、アイテムの利用時間の時系列順であってもよい。

図４の例では、旅行かごには、ユーザがアイテム画面Ｇ３から選択した「ホテルＡ」が追加されている。このため、表示領域Ａ４０には、「ホテルＡ」に関する情報（例えば、ホテル名、住所、電話番号等）、ユーザが指定した利用日（チェックイン日・チェックアウト日）、及びユーザが指定した人数が表示される。その他にも、ユーザが部屋のタイプやオプション等を指定した場合には、指定内容が表示領域Ａ４０に表示されてもよい。

ユーザがボタンＢ４００を選択した場合、旅行かごの中にあるアイテムを予約することができる。旅行かごの中に複数のアイテムがある場合、これら複数のアイテムの予約処理が一度にまとめて実行されてもよいし、個々のアイテムごとに個別に予約処理が実行されてもよい。なお、ユーザがボタンＢ４０１を選択した場合、旅行かごのアイテムを削除することができる。

本実施形態では、旅行かごの中にあるアイテムの時間及び場所に基づいて、他の種類のアイテムが検索され、旅行かご画面Ｇ４の表示領域Ａ４１Ａ～Ａ４１Ｃにレコメンドされる。以降では、表示領域Ａ４１Ａ～Ａ４１Ｃを特に区別する必要のないときは、単に表示領域Ａ４１と記載する。同様に、後述するボタンＡ４１０Ａ～Ａ４１０Ｃを特に区別する必要のないときは、単にボタンＡ４１０と記載する。

例えば、表示領域Ａ４１Ａに示すように、ユーザが旅行かごに入れた「ホテルＡ」の利用日及び場所に基づいて、「ホテルＡ」がある地域の空港までの往復航空券が検索され、当該往復航空券が表示領域Ａ４１にレコメンドされる。なお、出発地は、ユーザが予め入力してもよいし、ユーザの過去の予約履歴から取得されてもよい。他にも例えば、後述する変形例のように、ユーザ登録情報や通信環境等から出発地が取得されてもよい。ユーザは、表示領域Ａ４１Ａに表示されたボタンＡ４１０Ａを選択することで、レコメンドされた往復航空券を旅行かごに追加することができる。

また例えば、表示領域Ａ４１Ｂに示すように、ユーザが旅行かごに入れた「ホテルＡ」の利用日及び場所に基づいて、「ホテルＡ」がある地域のレンタカー会社が提供するレンタカーが検索され、当該レンタカーが表示領域Ａ４１Ｂにレコメンドされる。ユーザは、表示領域Ａ４１Ｂに表示されたボタンＡ４１０Ｂを選択することで、レコメンドされたレンタカーを旅行かごに追加することができる。

また例えば、表示領域Ａ４１Ｃに示すように、ユーザが旅行かごに入れた「ホテルＡ」の利用日及び場所に基づいて、「ホテルＡ」がある地域のアクティビティが検索され、当該アクティビティが表示領域Ａ４１Ｃに表示される。ユーザは、表示領域Ａ４１Ｃに表示されたボタンＡ４１０Ｃを選択することで、レコメンドされたレンタカーを旅行かごに追加することができる。

図５は、レコメンドされたアイテムが旅行かごに追加される様子を示す図である。なお、図５では、特に参照する必要のない符号は省略する。図５の旅行かご画面Ｇ４Ａにおいて、例えば、ユーザが表示領域Ａ４１ＡのボタンＡ４１０Ａを選択すると、旅行かご画面Ｇ４Ｂに示すように、レコメンドされた往復航空券が旅行かごに追加される。続いて、ユーザが表示領域Ａ４１ＢのボタンＡ４１０Ｂを選択すると、旅行かご画面Ｇ４Ｃに示すように、レコメンドされたレンタカーが旅行かごに追加される。

更に、ユーザが表示領域Ａ４１ＣのボタンＡ４１０Ｃを選択すると、旅行かご画面Ｇ４Ｄに示すように、レコメンドされたアクティビティが旅行かごに追加される。このように、ユーザは、表示領域Ａ４１においてレコメンドされたアイテムを次々と選択し、旅行かごに次々とアイテムを追加することができる。

なお、レコメンドされたアイテムが旅行かごに追加された場合、表示領域Ａ４１においては、元々レコメンドされていたアイテムが保持されてもよいし、最新の旅行かごの内容に基づいて、レコメンドされるアイテムが更新されてもよい。更に、元々レコメンドされていたアイテムが保持されつつ、新たなアイテムが追加でレコメンドされてもよい。

また、図４－図５では、複数種類のアイテムがレコメンドされる場合を説明したが、レコメンドされるアイテムは、１種類だけであってもよい。更に、同じ種類のアイテムが複数個レコメンドされてもよい。例えば、往復航空券とともに片道航空券がレコメンドされてもよいし、複数の時間帯の各々の航空券がレコメンドされてもよい。また例えば、「ホテルＡ」がある地域の複数のレンタカー会社がレコメンドされてもよい。また例えば、「ホテルＡ」がある地域における複数のアクティビティがレコメンドされてもよい。

また、図４－図５では、航空券、レンタカー、及びアクティビティがレコメンドされる場合を説明したが、任意の種類のアイテムをレコメンドしてよく、例えば、「ホテルＡ」の利用日及び場所に基づいて、「ホテルＡ」がある地域のレストランが検索され、当該レストランがレコメンドされてもよい。また例えば、「ホテルＡ」の利用日及び場所に基づいて、「ホテルＡ」がある地域の観光施設が検索され、当該観光施設がレコメンドされてもよい。

また、図４－図５では、ユーザが旅行かごにホテルを追加した場合のレコメンドについて説明したが、ユーザが旅行かごに航空券を追加した場合には、航空券の目的地と到着時間に基づいて、ホテル、レンタカー、及びアクティビティが検索されてレコメンドされてもよい。また例えば、ユーザが旅行かごにレンタカーを追加した場合には、レンタカー会社の地域と利用時間に基づいて、ホテル、航空券、及びアクティビティが検索されてレコメンドされてもよい。また例えば、ユーザが旅行かごにアクティビティを追加した場合には、アクティビティの地域と利用時間に基づいて、ホテル、航空券、及びレンタカーが検索されてレコメンドされてもよい。

また、図４－図５では、旅行かご画面Ｇ４においてレコメンドが行われる場合を説明したが、レコメンドは、任意の画面で行われるようにすればよく、例えば、トップ画面Ｇ１、検索結果画面Ｇ２、又はアイテム画面Ｇ３で行われてもよいし、その他の画面で行われてもよい。他にも例えば、レコメンドは、電子メール、メッセージアプリ、ＳＮＳ、又はプッシュ通知といった任意の手段で行われるようにしてもよい。

以上のように、本実施形態の旅行計画システムＳは、ユーザが旅行かごに追加したアイテムの時間及び場所に基づいて、他の種類のアイテムを検索し、旅行かご画面Ｇ４の表示領域Ａ４１にレコメンドする。そして、旅行計画システムＳは、表示領域Ａ４１のボタンＢ４１０が選択された場合に、レコメンドしたアイテムを旅行かごに追加し、ユーザによる旅程の作成を支援する。以降、この技術の詳細を説明する。

［３．旅行計画システムにおいて実現される機能］
図６は、本実施形態の旅行計画システムＳで実現される機能の一例を示す機能ブロック図である。

[３－１．データベースサーバで実現される機能]
図６に示すように、データベースサーバ４０では、データ記憶部４００が実現される。データ記憶部４００は、記憶手段の一例である。データ記憶部４００は、記憶部４２を主として実現される。データ記憶部４００は、検索やレコメンドに必要なデータを記憶する。ここでは、データ記憶部４００が記憶するデータの一例として、アイテムデータベースＤＢ１、ユーザデータベースＤＢ２、及びレコメンドデータベースＤＢ３を説明する。これら各データベースの内容は、ウェブサーバ２０又は分析サーバ３０からの要求に応じて適宜提供される。

図７は、アイテムデータベースＤＢ１のデータ格納例を示す図である。アイテムデータベースＤＢ１は、アイテムに関する各種情報が格納されたデータベースである。図７に示すように、例えば、アイテムデータベースＤＢ１には、アイテムを一意に識別するアイテムＩＤ、アイテムの種類、及びアイテムの基本情報が格納される。なお、図７では、アイテムの種類をテキストで示しているが、アイテムの種類を一意に識別する種類ＩＤが格納されてもよい。

基本情報は、アイテムの内容を示す情報が格納され、検索時のインデックスとして用いられる。例えば、アイテムが宿泊施設であれば、基本情報は、宿泊施設の名前、住所、チェックイン及びチェックアウトの時間、連絡先、宿泊施設の画像、部屋等の施設情報、及び宿泊料金等が格納される。また例えば、アイテムが交通手段であれば、基本情報は、交通手段の名前、出発地、目的地、出発時間、到着時間、座席情報、及び運賃等が格納される。また例えば、アイテムがレンタカーであれば、基本情報は、レンタカー会社名、住所、連絡先、レンタカーの画像、車種、及び利用金額等が格納される。

また例えば、アイテムがアクティビティであれば、基本情報は、ツアー会社名、アクティビティの場所、集合時間、解散時間、アクティビティの内容、及び利用料金が格納される。また例えば、アイテムがレストランであれば、基本情報は、レストラン名、住所、連絡先、レストランの画像、利用可能時間、座席情報、及び料金等が格納される。また例えば、アイテムが観光施設であれば、基本情報は、観光施設の場所、連絡先、施設の画像、施設情報、及び料金等が格納される。

なお、本実施形態では、説明の簡略化のために、全アイテムが１つのアイテムデータベースＤＢ１に集約されている場合を説明するが、複数のデータベースに分けられていてもよい。例えば、アイテムの種類ごとにデータベースが分けられていてもよい。また例えば、アイテムの提供者ごとに、データベースが分けられており、宿泊施設、交通手段、レンタカー、アクティビティ、レストラン、又は観光施設の運営会社が管理する外部コンピュータにデータベースが記憶されていてもよい。この場合、旅行計画システムＳは、当該外部コンピュータにデータベースの内容を問い合わせてもよい。

図８は、ユーザデータベースＤＢ２のデータ格納例を示す図である。ユーザデータベースＤＢ２は、ユーザに関する各種情報を格納するためのデータベースである。図８に示すように、例えば、ユーザデータベースＤＢ２には、ユーザを一意に識別するユーザＩＤ、ユーザ登録情報、旅行かご情報、及び予約情報が格納される。

ユーザ登録情報は、ユーザにより登録された基本情報であり、例えば、氏名、住所、及び連絡先といった個人情報が格納されてもよいし、ユーザアカウントやパスワードといった認証情報が格納されてもよい。他にも例えば、ユーザの好みの旅行先等の嗜好情報が格納されていてもよい。

旅行かご情報は、旅行かごの内容を示す情報であり、例えば、旅行かごに投入されたレコード（アイテムＩＤと指定内容のセット）を識別する旅行かごＩＤ、旅行かごに追加されたアイテムのアイテムＩＤ、及びユーザにより指定された指定内容が格納される。指定内容は、アイテムの利用条件であり、例えば、時間、人数、又はオプションの有無等が指定される。なお、本実施形態では、説明の簡略化のために、ユーザに旅行かごが１つだけ割り当てられる場合を説明するが、後述する変形例のように、ユーザに複数の旅行かごが割り当てられ、複数の旅程を並列して作成できるようにしてもよい。

予約情報は、予約済みのアイテムの予約内容を示す情報であり、予約の履歴を示す情報である。例えば、予約情報には、予約を一意に識別する予約ＩＤ、予約されたアイテムのアイテムＩＤ、及び予約内容が格納される。予約内容は、アイテムの予約条件であり、例えば、時間、人数、又はオプションの有無等である。

なお、ユーザデータベースＤＢ２に格納される情報は、上記の例に限られない。例えば、ユーザデータベースＤＢ２には、アイテムの検索履歴又は閲覧履歴が格納されてもよい。また例えば、ユーザデータベースＤＢ２には、ウェブサイトの検索履歴又は閲覧履歴が格納されていてもよい。また例えば、旅行計画システムＳが電子商取引システム等の他のシステムと提携する場合には、ユーザデータベースＤＢ２には、当該他のシステムの利用履歴が格納されてもよい。

図９は、レコメンドデータベースＤＢ３のデータ格納例を示す図である。レコメンドデータベースＤＢ３は、ユーザに対するレコメンド内容を格納するためのデータベースである。図９に示すように、レコメンドデータベースＤＢ３には、ユーザＩＤ及びレコメンド情報が格納される。

レコメンド情報は、ユーザに対するレコメンドの内容を示す情報であり、分析サーバ３０により決定された内容が格納される。例えば、レコメンド情報には、レコメンドすべきアイテムのアイテムＩＤとレコメンド内容とを含む。レコメンド内容は、レコメンドすべきアイテムの内容であり、例えば、時間、人数、又はオプションの有無等である。

なお、データ記憶部４００に記憶されるデータは、上記の例に限られない。例えば、データ記憶部４００は、図２－図４に示す各画面を表示させるための画像データを記憶してもよい。また例えば、データ記憶部４００は、各アイテムの在庫を示す在庫データベースを記憶してもよい。在庫データベースには、各アイテムの時間ごとの在庫が格納される。

[３－２．ウェブサーバで実現される機能]
図６に示すように、ウェブサーバ２０では、第１検索部２００及び受付部２０１が実現される。第１検索部２００及び受付部２０１は、それぞれ第１検索手段及び受付手段の一例である。

［第１検索部］
第１検索部２００は、制御部２１を主として実現される。第１検索部２００は、ユーザにより入力された時間及び場所に基づいて、旅程に組み込むアイテムを検索する。時間の意味は、先述した通りである。場所は、地域名、都市名、住所、郵便番号、又は緯度経度情報といった種々の情報を利用して入力されるようにすればよい。

第１検索部２００は、ユーザ端末１０からユーザにより入力された時間及び場所を取得し、当該時間及び場所をクエリとし、アイテムデータベースＤＢ１に格納された基本情報をインデックスとして、アイテムを検索する。検索方法自体は、種々の手法を適用可能であり、クエリとインデックスの一致判定が行われてもよいし、あいまい検索が利用されてもよい。

例えば、第１検索部２００は、ユーザにより入力された時間で予約を受け付けているアイテムを検索してもよい。また例えば、第１検索部２００は、ユーザにより入力された時間で在庫があるアイテムを検索してもよい。また例えば、第１検索部２００は、ユーザにより入力された場所と一致する場所のアイテムを検索してもよい。また例えば、第１検索部２００は、ユーザにより入力された場所と同じ地域のアイテムを検索してもよい。また例えば、第１検索部２００は、ユーザにより入力された場所との距離が閾値未満であるアイテムを検索してもよい。

第１検索部２００は、アイテムデータベースＤＢ１を参照し、検索でヒットしたアイテムの基本情報を取得する。第１検索部２００は、取得した基本情報に基づいて、検索結果画面Ｇ２のリストＬ２１の表示内容を決定し、検索結果画面Ｇ２の表示データをユーザ端末１０に送信する。ユーザ端末１０においては、当該表示データが受信されると、検索結果画面Ｇ２が表示部１５に表示される。

［受付部］
受付部２０１は、制御部２１を主として実現される。受付部２０１は、第１検索部２００の検索結果の中から、ユーザによる選択を受け付ける。受付部２０１は、検索結果画面Ｇ２の中からユーザによる選択を受け付ける。本実施形態では、受付部２０１がウェブサーバ２０において実現されるので、受付部２０１は、ユーザ端末１０から、ユーザにより選択されたアイテムのアイテムＩＤを受信することによって、ユーザによるアイテムの選択を受け付ける。

本実施形態では、ユーザにより選択されたアイテムは、旅行かごに追加されるので、受付部２０１は、ユーザにより選択されたアイテムのアイテムＩＤと、ユーザにより指定された指定内容と、をユーザデータベースＤＢ２に格納する。なお、一度に選択可能なアイテムの数は、任意であってよく、例えば、１つだけであってもよいし、２つ以上であってもよい。

[３－３．分析サーバで実現される機能]
図６に示すように、分析サーバ３０では、第２検索部３００及び提示部３０１が実現される。第２検索部３００及び提示部３０１は、それぞれ第２検索手段及び提示手段の一例である。

［第２検索部］
第２検索部３００は、制御部３１を主として実現される。第２検索部３００は、ユーザにより選択されたアイテムの時間及び場所に基づいて、他の種類のアイテムを検索する。ユーザにより選択されたアイテムとは、受付部２０１が選択を受け付けたアイテムであり、例えば、旅行かごに追加されたアイテムであってもよいし、予約が完了したアイテムであってもよい。本実施形態では、旅行かごに追加されたアイテムが、ユーザにより選択されたアイテムに相当する場合を説明する。

例えば、第２検索部３００は、ユーザデータベースＤＢ２の旅行かご情報を参照し、ユーザにより選択されたアイテムの時間及び場所を取得する。なお、予約が完了したアイテムが、ユーザにより選択されたアイテムに相当する場合には、第２検索部３００は、ユーザデータベースＤＢ２の予約情報を参照し、ユーザにより選択されたアイテムの時間及び場所を取得する。他にも例えば、ユーザデータベースＤＢ２にユーザの検索条件を保持しておき、第２検索部３００は、ユーザの検索条件を参照することで、ユーザにより選択されたアイテムの時間及び場所を取得してもよい。

第２検索部３００は、上記取得した時間及び場所をクエリとし、アイテムデータベースＤＢ１に格納された基本情報をインデックスとして、アイテムを検索する。ただし、第２検索部３００は、全ての種類のアイテムを検索対象とするのではなく、ユーザにより選択されたアイテムと同じ種類のアイテムは検索対象から除外し、他の種類のアイテムを検索対象とする。このため、第２検索部３００は、アイテムデータベースＤＢ１のうち、ユーザにより選択されたアイテムの種類以外のアイテム（ユーザにより選択されたアイテムとは異なる種類のアイテム）の基本情報をインデックスとして検索を実行する。なお、第２検索部３００は、アイテムデータベースＤＢ１から各アイテムの種類を取得すればよい。

例えば、第２検索部３００は、ユーザにより選択されたアイテムの時間で予約を受け付けているアイテムを検索してもよい。また例えば、第２検索部３００は、ユーザにより選択されたアイテムの時間で在庫があるアイテムを検索してもよい。また例えば、第２検索部３００は、ユーザにより選択されたアイテムの場所と一致する場所のアイテムを検索してもよい。また例えば、第２検索部３００は、ユーザにより選択されたアイテムの場所と同じ地域のアイテムを検索してもよい。また例えば、第２検索部３００は、ユーザにより選択されたアイテムの場所との距離が閾値未満であるアイテムを検索してもよい。

第２検索部３００は、アイテムデータベースＤＢ１を参照し、検索でヒットしたアイテムの基本情報を取得する。第２検索部３００は、検索でヒットしたアイテムのアイテムＩＤと、当該アイテムのレコメンド内容と、を含むレコメンド情報を、レコメンドデータベースＤＢ３に格納する。レコメンド内容は、クエリとした時間が格納されてもよいし、クエリとした場所が格納されてもよい。レコメンド情報は、所定のタイミングで参照され、旅行かご画面Ｇ４の表示領域Ａ４１において、第２検索部３００が検索したアイテムがレコメンドされる。

［提示部］
提示部３０１は、制御部３１を主として実現される。提示部３０１は、第２検索部３００により検索されたアイテムを、選択可能に提示する。選択可能に提示とは、アイテムを選択肢として提示することである。別の言い方をすれば、選択可能に提示とは、アイテムの選択を受け付け可能な状態で提示することである。提示とは、アイテムを選択するための情報（例えば、画像又はリンク）をユーザ端末１０に表示させること、又は、アイテムを選択するための情報をユーザ端末１０に送信することである。

本実施形態では、提示部３０１は、第２検索部３００により検索されたアイテムを、旅行かご画面Ｇ４において提示する場合を説明するが、アイテムの提示方法は、任意の方法を適用可能である。例えば、提示部３０１は、電子メール、メッセージアプリ、ＳＮＳ、又はプッシュ通知によって、第２検索部３００により検索されたアイテムを提示してもよい。なお、提示部３０１は、第２検索部３００により検索が実行されたことに応じてアイテムを提示してもよいし、ユーザ端末１０から所定の要求を受け付けた場合にアイテムを提示してもよい。

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

［データ記憶部］
データ記憶部１００は、記憶部１２を主として実現される。データ記憶部１００は、ウェブサーバ２０から受信したデータを記憶する。例えば、データ記憶部１００は、ウェブサーバ２０から受信したトップ画面Ｇ１、検索結果画面Ｇ２、アイテム画面Ｇ３、及び旅行かご画面Ｇ４の各々の表示データを記憶してもよい。また例えば、データ記憶部１００は、ユーザＩＤ、入力された検索条件、及び旅行かごの中身を記憶してもよい。

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

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

［４．本実施形態において実行される処理］
図１０－図１１は、旅行計画システムＳにおいて実行される処理の一例を示すフロー図である。図１０－図１１に示す処理は、制御部１１，２１，３１，４１が、それぞれ記憶部１２，２２，３２，４２に記憶されたプログラムに従って動作することによって実行される。下記に説明する処理は、図６に示す機能ブロックにより実行される処理の一例である。なお、ここでは、ユーザ端末１０のウェブブラウザ上で各種画面が表示され、その際の通信プロトコルとしてＨＴＴＰが利用される場合を説明する。

図１０に示すように、まず、ユーザ端末１０において、トップ画面Ｇ１のＵＲＬが選択された場合に、制御部１１は、ウェブサーバ２０に対し、トップ画面Ｇ１を表示させるためのＨＴＴＰリクエストを送信する（Ｓ１）。Ｓ１においては、制御部１１は、所定のパラメータを含むＨＴＴＰリクエストを送信する。当該ＨＴＴＰリクエストは、トップ画面Ｇ１の表示要求であり、パラメータには、ユーザＩＤが含まれるものとする。

ウェブサーバ２０においては、ＨＴＴＰリクエストを受信すると、制御部２１は、ユーザ端末１０に対し、トップ画面Ｇ１の表示データを含むＨＴＴＰレスポンスを送信する（Ｓ２）。表示データは、任意のデータ形式であってよく、ここでは、ＨＴＭＬデータとする。なお、本実施形態では、説明の簡略化のために、トップ画面Ｇ１ではレコメンドが行われない場合を説明するが、トップ画面Ｇ１でレコメンドが行われる場合には、Ｓ２の時点で後述するレコメンド処理（Ｓ１９の処理）が実行されてもよい。この点は、後述する検索結果画面Ｇ２又はアイテム画面Ｇ３を表示させる場合も同様であり、検索結果画面Ｇ２又はアイテム画面Ｇ３でレコメンドが行われる場合には、これらの画面を表示させる時点でレコメンド処理が実行されてもよい。

ユーザ端末１０においては、ＨＴＴＰレスポンスを受信すると、制御部１１は、トップ画面Ｇ１の表示データに基づいて、トップ画面Ｇ１を表示部１５に表示させる（Ｓ３）。制御部１１は、操作部１４の検出信号に基づいて、ユーザの操作を特定する（Ｓ４）。ここでは、入力フォームＦ１０～Ｆ１３に検索条件を入力する操作、又は、ボタンＢ１４を選択する操作が行われる場合を説明する。

入力フォームＦ１０～Ｆ１３に検索条件が入力された場合（Ｓ４；検索条件入力）、制御部１１は、ユーザが入力した時間及び場所等の検索条件を、入力フォームＦ１０～Ｆ１３に表示させる（Ｓ５）。ユーザが入力した検索条件は、記憶部１２に保持される。なお、ユーザがトップ画面Ｇ１から検索対象のアイテムの種類を指定した場合には、当該種類を識別する情報も記憶部１２に保持される。

一方、ボタンＢ１４が選択された場合（Ｓ４；検索実行）、制御部１１は、ウェブサーバ２０に対し、検索結果画面Ｇ２を表示させるためのＨＴＴＰリクエストを送信する（Ｓ６）。当該ＨＴＴＰリクエストは、検索の実行要求であり、パラメータには、ユーザＩＤ、検索対象となるアイテムの種類、及び入力フォームＦ１０～Ｆ１３に入力された検索条件を含む。

ウェブサーバ２０においては、ＨＴＴＰリクエストを受信すると、制御部２１は、データベースサーバ４０に記憶されたアイテムデータベースＤＢ１に基づいて、アイテムを検索する（Ｓ７）。Ｓ７においては、制御部２１は、アイテムデータベースＤＢ１のうち、検索対象となるアイテムの種類のレコードを参照し、検索条件をクエリとし、検索対象となるアイテムの種類のアイテムの基本情報をインデックスとして、検索を実行する。

制御部２１は、Ｓ７における検索結果に基づいて、ユーザ端末１０に対し、検索結果画面Ｇ２の表示データを含むＨＴＴＰレスポンスを送信する（Ｓ８）。Ｓ８においては、制御部２１は、アイテムデータベースＤＢ１を参照し、Ｓ７における検索でヒットしたアイテムの基本情報を取得し、検索結果画面Ｇ２の表示データを生成する。なお、当該表示データには、検索でヒットしたアイテムのアイテムＩＤが含まれているものとする。これにより、例えば、ユーザがリストＬ２１内のアイテムを選択した場合に、どのアイテムが選択されたかを特定可能となる。

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

トップ画面Ｇ１に戻る操作が行われた場合（Ｓ１０；戻る）、Ｓ３の処理に戻る。一方、リスト内Ｌ２１のアイテムを選択する操作が行われた場合（Ｓ１０；アイテム選択）、制御部１１は、ウェブサーバ２０に対し、アイテム画面Ｇ３を表示させるためのＨＴＴＰリクエストを送信する（Ｓ１１）。当該ＨＴＴＰリクエストは、アイテム画面Ｇ３の表示要求であり、パラメータには、ユーザＩＤと、ユーザが選択したアイテムのアイテムＩＤと、が含まれる。

ウェブサーバ２０においては、ＨＴＴＰリクエストを受信すると、制御部２１は、データベースサーバ４０に記憶されたアイテムデータベースＤＢ１に基づいて、ユーザ端末１０に対し、アイテム画面Ｇ３の表示データを含むＨＴＴＰレスポンスを送信する（Ｓ１２）。Ｓ１２においては、制御部２１は、アイテムデータベースＤＢ１のうち、ユーザが選択したアイテムのアイテムＩＤが格納されたレコードを参照し、アイテム画面Ｇ３の表示データを生成する。

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

検索結果画面Ｇ２に戻る操作が行われた場合（Ｓ１４；戻る）、Ｓ９の処理に戻る。一方、ボタンＢ３０を選択する操作が行われた場合（Ｓ１４；アイテム追加）、制御部１１は、ウェブサーバ２０に対し、旅行かご画面Ｇ４を表示させるためのＨＴＴＰリクエストを送信する（Ｓ１５）。当該ＨＴＴＰリクエストは、旅行かご画面Ｇ４の表示要求であり、旅行かごへのアイテムの追加要求である。当該ＨＴＴＰリクエストのパラメータには、ユーザＩＤ、旅行かごに投入されたレコード（アイテムＩＤと指定内容のセット）を特定する旅行かごＩＤ、ユーザが旅行かごに追加するアイテムのアイテムＩＤ、及び指定内容が含まれる。

ウェブサーバ２０においては、ＨＴＴＰリクエストを受信すると、制御部２１は、データベースサーバ４０に記憶されたユーザデータベースＤＢ２に基づいて、ユーザが選択したアイテムを旅行かごに追加する（Ｓ１６）。Ｓ１６においては、制御部２１は、追加要求をしたユーザのユーザＩＤが格納されたレコードの旅行かご情報に、ユーザが選択したアイテムのアイテムＩＤと指定内容とを格納する。

制御部２１は、アイテムデータベースＤＢ１に基づいて、ユーザ端末１０に対し、旅行かご画面Ｇ４の表示データを含むＨＴＴＰレスポンスを送信する（Ｓ１７）。Ｓ１７においては、制御部２１は、旅行かご画面Ｇ４の表示データを生成する。旅行かご画面Ｇ４の表示データには、レコメンドデータベースＤＢ３からレコメンド内容を取得する命令が記載されたＪａｖａスクリプト（登録商標）が含まれているものとする。ユーザ端末１０は、ＨＴＴＰレスポンスの受信後の任意のタイミングで、当該Ｊａｖａスクリプト（登録商標）を実行し、レコメンドデータベースＤＢ３を参照する。

図１１に移り、制御部２１は、分析サーバ３０とデータベースサーバ４０に対し、レコメンド処理を依頼する（Ｓ１８）。Ｓ１８においては、制御部２１は、ユーザ端末１０から受信したＨＴＴＰリクエストのパラメータを送信し、レコメンド処理の実行を依頼する。レコメンド処理は、レコメンドすべきアイテム及び内容を決定するための処理である。

分析サーバ３０及びデータベースサーバ４０の各々は、ウェブサーバ２０からレコメンド処理の依頼を受信すると、レコメンド処理を実行する（Ｓ１９）。Ｓ１９においては、分析サーバ３０とデータベースサーバ４０との間で、ユーザが旅行かごに追加したアイテムの時間及び場所に基づいて、他の種類のアイテムが検索される。分析サーバ３０の制御部３１は、アイテムデータベースＤＢ１のうち、旅行かごに追加されたアイテムの種類とは異なる種類のデータを参照し、旅行かごに追加されたアイテムの時間と場所をクエリにして検索を実行する。

分析サーバ３０においては、制御部３１は、レコメンド処理の実行結果に基づいて、レコメンドデータベースＤＢ３にレコメンド情報を格納する（Ｓ２０）。Ｓ２０においては、制御部３１は、ユーザＩＤに関連付けて、レコメンド処理で検索されたアイテムのアイテムＩＤとレコメンド内容を格納する。

ユーザ端末１０においては、ＨＴＴＰレスポンスを受信すると、制御部１１は、Ｊａｖａスクリプト（登録商標）に基づいて、レコメンド情報を取得する（Ｓ２１）。Ｓ２１においては、制御部１１は、分析サーバ３０又はデータベースサーバ４０に対し、レコメンド情報の取得要求を送信する。分析サーバ３０又はデータベースサーバ４０は、取得要求を受信すると、レコメンドデータベースＤＢ３を参照し、取得要求を送信したユーザのユーザＩＤが格納されたレコードのレコメンド情報を送信する。なお、レコメンド情報の取得は、Ｊａｖａスクリプト（登録商標）以外の任意のスクリプトが実行されることで実行されてもよい。

制御部１１は、Ｓ２１において取得したレコメンド情報に基づいて、旅行かご画面Ｇ４を表示部１５に表示させる（Ｓ２２）。Ｓ２２においては、制御部１１は、ウェブサーバ２０から受信したＨＴＴＰレスポンスに含まれる表示データに基づいて、旅行かご画面Ｇ４を表示部１５に表示させる。そして、制御部１１は、Ｓ２１において取得したレコメンド情報に基づいて、表示領域Ａ４１内にレコメンドされたアイテムを表示させる。

制御部１１は、操作部１４の検出信号に基づいて、ユーザの操作を特定する（Ｓ２３）。ここでは、アイテム画面Ｇ３に戻る操作、ボタンＢ４００を選択する操作、ボタンＢ４０１を選択する操作、又はボタンＢ４１０を選択する操作について説明する。

アイテム画面Ｇ３に戻る操作が行われた場合（Ｓ２３；戻る）、Ｓ１３の処理に戻る。一方、ボタンＢ４１０を選択する操作が行われた場合（Ｓ２３；アイテム追加）、制御部１１は、ウェブサーバ２０に対し、レコメンドされたアイテムを旅行かごに追加するためのＨＴＴＰリクエストを送信する（Ｓ２４）。Ｓ２４においては、制御部１１は、ユーザＩＤ、アイテムが追加される旅行かごの旅行かごＩＤ、及びユーザが旅行かごに追加するアイテムのアイテムＩＤを含むパラメータとともに、ＨＴＴＰリクエストを送信する。

ウェブサーバ２０においては、ＨＴＴＰリクエストを受信すると、制御部２１は、データベースサーバ４０に記憶されたユーザデータベースＤＢ２に基づいて、ユーザが選択したアイテムを旅行かごに追加し（Ｓ２５）、Ｓ１７の処理に移行する。Ｓ２４においては、制御部２１は、追加要求をしたユーザのユーザＩＤが格納されたレコードの旅行かご情報に、ユーザが選択したアイテムのアイテムＩＤと指定内容とを格納する。

一方、ボタンＢ４０１を選択する操作が行われた場合（Ｓ２３；アイテム削除）、制御部１１は、ウェブサーバ２０に対し、旅行かごの中にあるアイテムを削除するためのＨＴＴＰリクエストを送信する（Ｓ２６）。Ｓ２６においては、制御部１１は、ユーザＩＤ、アイテムが削除される旅行かごの旅行かごＩＤ、及びユーザが旅行かごから削除するアイテムのアイテムＩＤを含むパラメータとともに、ＨＴＴＰリクエストを送信する。

ウェブサーバ２０においては、ＨＴＴＰリクエストを受信すると、制御部２１は、データベースサーバ４０に記憶されたユーザデータベースＤＢ２に基づいて、ユーザが選択したアイテムを旅行かごから削除し（Ｓ２７）、Ｓ１７の処理に移行する。Ｓ２７においては、制御部２１は、削除要求をしたユーザのユーザＩＤが格納されたレコードの旅行かご情報から、ユーザが選択したアイテムのアイテムＩＤと指定内容とを削除する。

一方、ボタンＢ４００を選択する操作が行われた場合（Ｓ２３；予約）、制御部１１は、ウェブサーバ２０に対し、旅行かごに追加されたアイテムを予約するためのＨＴＴＰリクエストを送信する（Ｓ２８）。Ｓ２８においては、制御部１１は、ユーザＩＤと、予約する旅行かごの旅行かごＩＤと、を含むパラメータとともに、ＨＴＴＰリクエストを送信する。以降、ユーザ端末１０とウェブサーバ２０との間で予約処理が実行され、本処理は終了する。

旅行計画システムＳによれば、ユーザにより選択されたアイテムの時間及び場所に基づいて検索された他の種類のアイテムが、旅行かご画面Ｇ４の表示領域Ａ４１においてレコメンドされ、他の種類のアイテムをいちいち探す手間がなくなるので、複数種類のアイテムが組み込まれる旅程を作成する手間を軽減することができる。ユーザは、複数種類のアイテムを旅程に組み込む場合であっても、レコメンドされたアイテムを次々と選択することで容易に旅程を作成することができる。また、ユーザが他の種類のアイテムを探すために検索条件を入力して検索を実行し、アイテム画面Ｇ３を表示させて旅行かごに入れるといった余計な処理を省略することができ、旅行計画システムＳの処理負荷を軽減することもできる。

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

図１２は、変形例の機能ブロック図である。図１２に示すように、以降説明する変形例では、実施形態で説明した機能に加え、ウェブサーバ２０において、出発地取得部２０２が実現され、分析サーバ３０において、出発地取得部３０２と特定部３０３が実現される。ウェブサーバ２０の出発地取得部２０２は、制御部２１を主として実現され、分析サーバ３０の出発地取得部３０２と特定部３０３は、制御部３１を主として実現される。

（１）例えば、ユーザがホテルやアクティビティ等の現地アイテムを旅行かごに追加した場合、ユーザは、その後に、航空券等の交通手段を検索することが多い。この場合、ユーザは、ホテルのチェックイン時間やアクティビティの集合時間に間に合うような交通手段を検索する必要があるが、同じ地域の現地アイテムを予約した他のユーザが予約した交通手段をレコメンドすることで、ユーザの手間を省くようにしてもよい。

現地アイテムとは、現地で利用されるアイテムである。現地は、目的地、旅行先、又は行き先である。例えば、現地アイテムは、宿泊施設、レンタカー、アクティビティ、レストラン、又は観光施設である。別の言い方をすれば、現地アイテムは、交通手段以外のアイテムである。なお、本変形例では、航空券や乗車券等のように交通手段のアイテムを意味する場合には交通手段アイテムと記載する。

本変形例の旅行計画システムＳでは、出発地取得部３０２と特定部３０３が実現される。出発地取得部３０２は、ユーザの出発地を取得する。

出発地は、交通手段アイテムの出発地である。例えば、交通手段アイテムが航空券であれば、航空機が離陸する空港である。また例えば、交通手段アイテムが列車の乗車券であれば、乗車する駅である。また例えば、交通手段アイテムがバスの乗車券であれば、乗車する停留所である。また例えば、交通手段アイテムが乗船券であれば、乗船する港である。出発地は、ユーザの居住地であってもよいし、居住地とは異なる場所であってもよい。出発地が居住地とは異なる場所の場合、例えば、出発地は、ユーザの勤務先の場所であってもよいし、旅程における経由地であってもよい。

本変形例では、出発地取得部３０２は、ユーザ端末１０から出発地を取得する場合を説明するが、後述する変形例（５）のように、ユーザ登録情報等を利用して出発地を取得してもよい。例えば、出発地取得部３０２は、ユーザがユーザ端末１０の操作部１４から入力した出発地を取得する。また例えば、ユーザ端末１０の記憶部１２に予め出発地が記憶されている場合には、出発地取得部３０２は、記憶部１２に記憶された出発地を取得する。

特定部３０３は、他のユーザにより選択された、現地アイテムと、当該他のユーザの出発地と現地との間の交通手段アイテムと、を特定する。ここでは、レコメンドの対象となるユーザを単に「ユーザ」と記載し、それ以外のユーザを「他のユーザ」と記載する。

本変形例では、他のユーザにより選択されたアイテムは、ユーザデータベースＤＢ２に記録されているので、特定部３０３は、ユーザデータベースＤＢ２に基づいて、他のユーザにより選択された、現地アイテムと交通手段アイテムとを特定する。これら現地アイテムと交通手段アイテムは、同一ユーザの同一の旅程に組み込まれたアイテムである。

他のユーザにより選択されたアイテムは、他のユーザによる選択を受け付けたアイテムであり、例えば、旅行かごに追加されたアイテムであってもよいし、予約が完了したアイテムであってもよい。例えば、特定部３０３は、他のユーザの旅行かご情報を参照し、同一の旅行かごＩＤに関連付けられた現地アイテムと交通手段アイテムの組み合わせを特定する。また例えば、特定部３０３は、他のユーザの予約情報を参照し、同一の予約ＩＤに関連付けられた現地アイテムと交通手段アイテムの組み合わせを特定する。

第２検索部３００は、ユーザにより現地アイテムが選択された場合に、出発地と、現地アイテムの場所と、がユーザと対応する他のユーザにより選択された交通手段アイテムに基づいて、ユーザの出発地と現地との間の交通手段アイテムを検索する。

出発地が対応するとは、出発地が同じこと、出発地がある地域が同じこと、又は、距離が閾値未満であることである。場所が対応するとは、場所が同じこと、地域が同じこと、又は、距離が閾値未満であることである。

第２検索部３００は、出発地取得部３０２により取得されたユーザの出発地と、特定部３０３により特定された他のユーザの交通手段アイテムの出発地と、に基づいて、出発地がユーザと対応する他のユーザを特定する。また、第２検索部３００は、ユーザにより選択された現地アイテムの場所と、特定部３０３により特定された他のユーザの現地アイテムの場所と、に基づいて、現地アイテムの場所がユーザと対応する他のユーザを特定する。

第２検索部３００は、上記特定した他のユーザにより選択された交通手段アイテムに基づいて、ユーザにレコメンドすべき交通手段アイテムを検索する。例えば、第２検索部３００は、他のユーザにより選択された交通手段アイテムと同じ交通手段アイテムを検索する。また例えば、第２検索部３００は、他のユーザにより選択された交通手段アイテムの時間及び場所に基づいて、交通手段アイテムを検索してもよい。この場合、第２検索部３００は、他のユーザにより選択された交通手段アイテムの時間及び場所に対応する時間の交通手段アイテムを検索する。

即ち、第２検索部３００は、ユーザにより選択された現地アイテムの場所に対応する場所の現地アイテムを選択し、かつ、ユーザの出発地に対応する出発地で交通手段アイテムを選択した他のユーザが存在する場合に、当該他のユーザにより選択された交通手段アイテムに基づいて、ユーザの交通手段アイテムを検索する。なお、他のユーザは、同一の旅程内で、上記現地アイテムと上記交通手段アイテムとを選択しているものとする。また、出発地と現地アイテムの場所とがユーザと対応する他のユーザは、複数人いることがあるので、この場合は、第２検索部３００は、人気の高い交通手段アイテムに基づいて検索を実行してもよい。人気とは、選択数であり、例えば、旅行かごへの追加数であってもよいし、予約数であってもよい。人気が高いとは、選択数が多いことである。例えば、第２検索部３００は、人気が最も高い交通手段アイテムに基づいて検索を実行してもよいし、人気がｎ番目（ｎは２以上の整数。例えば、２～５程度の数値。）までの交通手段アイテムに基づいて検索を実行してもよい。

図１３は、変形例（１）における旅行かご画面Ｇ４の一例を示す図である。図１３の例では、表示領域Ａ４０Ａ，Ａ４０Ｂに示すように、ユーザが「ホテルＡ」と「アクティビティＺ」の２つの現地アイテムを旅行かごに追加している。「ホテルＡ」は、「２０１８年７月１日１５時」－「２０１８年７月５日１１時」の時間が指定されており、場所は「沖縄県」である。「アクティビティＺ」は、「２０１８年７月１日１３時－１５時」の時間が指定されており、場所は「沖縄県」である。なお、ユーザの出発地は「東京都」とする。

第２検索部３００は、出発地が「東京都」であり、かつ、「沖縄県」の現地アイテムを選択した他のユーザを検索する。ここでは、同様の時間に「沖縄県」の現地アイテムを選択した他のユーザが、「東京都」の空港の出発時間が「２０１８年７月１日８：００」であり、「沖縄県」の空港の到着時間が「２０１８年７月１日１０：３０」の「ＸＸＸ１２３便」の片道航空券を、交通手段アイテムとして選択していたものとする。

第２検索部３００は、上記他のユーザが選択した「ＸＸＸ１２３便」と同じ交通手段アイテムを検索し、図１３の表示領域Ａ４１に示すように、「ＸＸＸ１２３便」の片道航空券がレコメンドされる。なお、第２検索部３００は、同様の時間帯に「沖縄県」に到着する他の航空会社の航空券を検索してもよいし、同様の時間帯に「沖縄県」に到着する船舶の乗船券を検索してもよい。また、第２検索部３００は、他のユーザの人気の高い順に複数個の交通手段アイテムを検索してもよい。また、後述する変形例（２）－（３）のように、第２検索部３００は、他のユーザが選択した「ＸＸＸ１２３便」の前後の便を検索してもよい。

なお、第２検索部３００は、現地アイテムの場所だけでなく、時間も対応する他のユーザにより選択された交通手段アイテムに基づいて、ユーザの交通手段アイテムを検索してもよい。時間が対応するとは、時間が同じこと、時間差が閾値未満であること、又は、時間帯が重複していることである。第２検索部３００は、ユーザにより選択された現地アイテムの時間及び場所と、特定部により特定された他のユーザの現地アイテムの時間及び場所と、に基づいて、現地アイテムの時間及び場所がユーザと対応する他のユーザを特定してもよい。図１３の例であれば、「沖縄県」という現地アイテムの場所だけでなく、「２０１８年７月１日－７月５日」という期間も考慮したうえで、他のユーザが特定されてもよい。特定した他のユーザの交通手段アイテムに基づいてユーザの交通手段アイテムを検索する方法は、上記説明した通りである。更に、現地アイテムの場所と時間の両方を考慮すると、他のユーザのデータ数が不足する場合には、現地アイテムの場所だけを考慮するといったように、他のユーザのデータ数に応じて使い分けるようにしてもよい。

変形例（１）によれば、ユーザにより現地アイテムが選択された場合に、出発地と現地アイテムの場所がユーザと対応する他のユーザにより選択された交通手段アイテムに基づいて、ユーザの出発地から現地までの交通手段アイテムが検索されるので、レコメンドの精度を高めることができる。レコメンドの精度を高めることで、ユーザが交通手段アイテムを探す手間を効果的に軽減することができ、余計な処理が実行される蓋然性を低減することで旅行計画システムＳの処理負荷を効果的に軽減することもできる。即ち、他のユーザのデータ数（旅行かご情報や予約情報）が一定数以上蓄積された場合には、精度の高いリコメンドをすることができ、結果的に、リコメンドされた交通手段アイテムをユーザが選択する蓋然性が高まるので、ユーザが出発地と現地との間の経路検索等をすることなく、旅行計画システムＳの処理負荷を軽減することができる。処理負荷を軽減する点については、以降説明する変形例で「レコメンドの精度を高める」と記載した内容についても同様である。

（２）また例えば、変形例（１）において、ユーザが現地アイテムを到着日に利用する場合、現地アイテムの利用時間に間に合うためには、現地に早く到着するに越したことはない。このため、第２検索部３００は、他のユーザにより選択された交通手段アイテムに対応する交通手段アイテムの在庫がない場合に、現地への到着時間が、他のユーザにより選択された交通手段アイテムよりも早い交通手段アイテムを検索してもよい。

他のユーザにより選択された交通手段アイテムに対応する交通手段アイテムとは、時間と場所が対応する交通手段アイテムである。「時間が対応する」の意味と、「場所が対応する」の意味と、は、変形例（１）で説明した通りである。在庫とは、残席であり、予約可能数ということもできる。各交通手段アイテムの在庫数は、データ記憶部４００に記憶されており、交通手段アイテムが旅行かごに追加されたり予約されたりした場合に在庫数が変化する。第２検索部３００は、在庫数が閾値（例えば、１）以上であれば、在庫があると判定し、在庫数が閾値未満であれば、在庫がないと判定する。第２検索部３００は、他のユーザにより選択された交通手段アイテムの到着時間よりも早い時間をクエリにして、現地への交通手段アイテムを検索する。

図１４は、変形例（２）における旅行かご画面Ｇ４の一例を示す図である。ここでは、他のユーザにとって最も人気が高い往路の交通手段アイテムが、「東京都」の空港の出発時間が「２０１８年７月１日８：００」であり、「沖縄県」の空港の到着時間が「２０１８年７月１日１０：３０」の「ＸＸＸ１２３便」の片道航空券であったとする。

第２検索部３００は、他のユーザが選択した「ＸＸＸ１２３便」の在庫の有無を判定し、在庫がある場合は「ＸＸＸ１２３便」がリコメンドされる。一方、第２検索部３００は、「ＸＸＸ１２３便」の在庫がない場合は、到着時間である「２０１８年７月１日１０：３０」よりも早い到着時間の交通手段を検索する。例えば、第２検索部３００は、「２０１８年７月１日」の「８：００」～「１０：３０」の時間帯に現地に到着する交通手段を検索する。図１４の表示領域Ａ４１に示すように、「２０１８年７月１日９：３０」に現地に到着する「ＸＸＸ２３４便」の片道航空券が検索され、レコメンドされる。

なお、上記の例において、２番目に人気が高い交通手段アイテムが、「ＸＸＸ１２３便」よりも到着時間が遅い「ＡＡＡ９９９便」であり、３番目に人気が高い交通手段アイテムが、「ＸＸＸ１２３便」よりも到着時間が早い「ＸＸＸ２３４便」であった場合に、２番目に人気が高い「ＡＡＡ９９９便」ではなく、「ＸＸＸ２３４便」が検索されてリコメンドされる。このようにすることで、他のユーザの数が一定以上になれば、複雑な処理を要することなく、ユーザが現地で旅程をこなすのに十分な時間を確保可能な時刻までに到着可能な交通手段をリコメンドできる。

変形例（２）によれば、ユーザにより選択された現地アイテムが現地への到着日に利用され、他のユーザにより選択された交通手段の在庫がない場合に、早い到着時間の交通手段アイテムをレコメンドすることで、余裕のある旅程を立てさせることができる。余裕のある旅程であればユーザが選択する蓋然性が高まるので、レコメンドの精度を効果的に高めることができる。

（３）また例えば、変形例（１）において、ユーザが現地アイテムを最終日に利用する場合、帰りの交通手段に間に合うためには、遅めの交通手段を利用するに越したことはない。このため、第２検索部３００は、他のユーザにより選択された交通手段アイテムに対応する交通手段アイテムの在庫がない場合に、現地からの出発時間が、他のユーザにより選択された交通手段アイテムよりも遅い交通手段アイテムを検索してもよい。第２検索部３００は、他のユーザにより選択された交通手段アイテムの出発時間よりも遅い時間をクエリにして、現地からの交通手段アイテムを検索する。

図１５は、変形例（３）における旅行かご画面Ｇ４の一例を示す図である。ここでは、他のユーザにとって最も人気が高い復路の交通手段アイテムが、「沖縄県」の空港の出発時間が「２０１８年７月５日１７：００」であり、「東京都」の空港の到着時間が「２０１８年７月５日１９：１５」の「ＸＸＸ８７６便」の片道航空券であったものとする。

第２検索部３００は、他のユーザが選択した「ＸＸＸ８７６便」の在庫の有無を判定し、在庫がある場合は、「ＸＸＸ８７６便」がリコメンドされる。一方、第２検索部３００は、「ＸＸＸ８７６便」の在庫がない場合は、出発時間である「２０１８年７月５日１７：００」よりも遅い出発時間の交通手段を検索する。例えば、第２検索部３００は、「２０１８年７月５日」の「１７：００」～「１９：００」の時間帯に出発地に帰る交通手段を検索する。図１５の表示領域Ａ４１に示すように、「２０１８年７月５日１８：００」に現地から出発する「ＸＸＸ９８７便」の片道航空券がレコメンドされる。

なお、上記の例において、２番目に人気が高い交通手段アイテムが、「ＸＸＸ８７６便」よりも出発時間が早い「ＡＡＡ１１１便」であり、３番目に人気が高い交通手段アイテムが、「ＸＸＸ８７６便」よりも出発時間が遅い「ＸＸＸ９８７便」であった場合に、２番目に人気が高い「ＡＡＡ１１１便」ではなく、「ＸＸＸ９８７便」が検索されてリコメンドされる。このようにすることで、他のユーザの数が一定以上になれば、複雑な処理を要することなく、ユーザが現地で旅程をこなすのに十分な時間を確保可能な時刻の後に発着可能な交通手段をリコメンドできる。

変形例（３）によれば、ユーザにより選択された現地アイテムが現地からの出発日に利用され、他のユーザにより選択された交通手段の在庫がない場合に、遅い出発時間の交通手段アイテムをレコメンドすることで、余裕のある旅程を立てさせることができる。余裕のある旅程であればユーザが選択する蓋然性が高まるので、レコメンドの精度を効果的に高めることができる。

（４）また例えば、ユーザの旅程は、複数の期間にまたがることがある。期間は、ある時点から他の時点までの間、又は、一定の時間的な長さである。期間は、任意の長さであればよく、数時間単位、１日単位、数日単位、又は１週間単位であってもよい。期間は、時間で区切られてもよいし、滞在地で区切られてもよい。例えば、ユーザが、山口県、福岡県、及び長崎県を周遊する場合には、旅程は、山口県の期間、福岡県の期間、及び長崎県の期間の３つの期間を含むようにしてもよい。

旅程が複数の期間にまたがる場合に、第２検索部３００は、期間ごとに、当該期間におけるアイテムの時間及び場所に基づいて検索を実行してもよい。各期間における検索方法自体は、実施形態で説明した通りである。第２検索部３００は、期間ごとに、当該期間に含まれるアイテムの時間及び場所をクエリとし、アイテムデータベースＤＢ１に格納された基本情報をインデックスとして、他の種類のアイテムを検索する。第２検索部３００は、期間の数だけ検索を実行することになる。提示部３０１は、期間ごとに、第２検索部３００により検索されたアイテムを提示する。アイテムの提示方法自体は、実施形態で説明した通りである。

図１６は、変形例（４）における旅行かご画面Ｇ４の一例を示す図である。図１６の表示領域Ａ４０に示すように、ユーザが「ホテルＡ」を旅行かごに追加している。「ホテルＡ」は、「２０１８年７月１日１５時」－「２０１８年７月５日１１時」の時間が指定されており、ユーザの旅程は、５日間にまたがっていることが特定される。

図１６の例の場合、表示領域Ａ４１Ａ～Ａ４１Ｃに示すように、旅程に含まれる日ごとに、アイテムが検索されてレコメンドされるようにしてもよい。例えば、表示領域Ａ４１Ａには、１日目のアイテムがリコメンドされる。また例えば、表示領域Ａ４１Ｂには、２日目のアイテムがリコメンドされる。また例えば、表示領域Ａ４１Ｃには、３日目のアイテムがリコメンドされる。４日目以降のアイテムについても同様に、日ごとにアイテムがリコメンドされることになる。

変形例（４）によれば、旅程が複数の期間にまたがる場合に、期間ごとにアイテムを検索してレコメンドすることで、レコメンドの精度を効果的に高めることができる。

（５）また例えば、旅行計画システムＳでは、ユーザにより登録されたユーザ登録情報、又は、ユーザの通信環境に基づいて、ユーザの出発地を取得する出発地取得部２０２が実現され、第２検索部３００は、出発地取得部２０２により取得されたユーザの出発地に基づいて検索を実行してもよい。

例えば、出発地取得部２０２は、ユーザデータベースＤＢ２に格納されたユーザ登録情報を参照し、ユーザの出発地を取得する。ユーザ登録情報は、旅行予約サービス以外のサービスのユーザ登録情報であってもよく、旅行計画システムＳが電子商取引サービスと連携する場合には、電子商取引サービスのユーザ登録情報に基づいて、ユーザの出発地を取得してもよい。この場合、ユーザが会員登録時に入力した住所を出発地としてもよいし、商品の配送先の住所を出発地としてもよい。

また例えば、出発地取得部２０２は、ユーザ端末１０におけるユーザの通信環境に基づいて、ユーザの出発地を取得する。通信環境は、ユーザ端末１０の位置ということもでき、例えば、ユーザ端末１０のＩＰアドレス、ユーザ端末１０が通信する基地局、ユーザ端末１０が通信するアクセスポイント、又はＧＰＳ位置情報等である。データベースサーバ４０のデータ記憶部４００には、通信環境と場所との対応関係が記憶されており、出発地取得部２０２は、ユーザの通信環境に関連付けられた場所を、ユーザの出発地として取得する。

なお、第２検索部３００は、目的地は、検索条件から取得してもよいし、ユーザにより選択された現地アイテムの場所に基づいて取得してもよい。第２検索部３００は、出発地取得部２０２により取得されたユーザの出発地と、上記取得した目的地と、に基づいて交通手段アイテムを検索する。

変形例（５）によれば、ユーザの出発地をユーザ登録情報又は通信環境に基づいて取得することで、ユーザに出発地を入力させる手間を省くことができ、出発地を推定する精度を高めることでレコメンドの精度を高めることもできる。

（６）また例えば、ユーザが過去に予約したアイテムの利用時間が経過した場合には、このアイテムが組み込まれた旅程は既に終了しているので、当該アイテムに基づくレコメンドが実行されないようにしてもよい。即ち、アイテムの利用時間が経過していなければ、ユーザが旅程にアイテムを追加する可能性があるので、利用時間が経過していないアイテムに基づくリコメンドが実行されるようにしてもよい。

第２検索部３００は、ユーザにより選択されたアイテムの時間が経過したかを判定し、当該判定結果に基づいて検索を実行する。第２検索部３００は、リアルタイムクロック等を利用して現在時間を取得し、ユーザにより選択されたアイテムの時間が経過したかを判定する。旅程が複数の期間にまたがる場合には、何れか１つのアイテムの時間が経過した場合に、当該旅程の時間が経過したと判定されてもよいし、全てのアイテムの時間が経過した場合に、当該旅程の時間が経過したと判定されてもよい。

第２検索部３００は、時間が経過していないアイテムの時間及び場所に基づいて検索を実行し、時間が経過したアイテムの時間及び場所に基づいては検索を実行しない。別の言い方をすれば、第２検索部３００は、ユーザにより選択された全アイテムのうち、時間が経過していないアイテムの時間及び場所を検索のクエリとし、時間が経過したアイテムの時間及び場所は検索のクエリから除外する。検索方法自体は、実施形態で説明した通りである。

変形例（６）によれば、ユーザにより選択されたアイテムの時間が経過したかの判定結果に基づいて検索を実行することで、ユーザにとって不要なレコメンドがなされる蓋然性を低減し、レコメンドの精度を高めることができる。

（７）また例えば、ユーザが検索条件を変更した場合には、別の旅程を計画し始めた蓋然性が高い。このため、新しい検索条件でヒットしたアイテムに基づいてレコメンドが実行されてもよい。

第２検索部３００は、ユーザにより新たな時間及び場所が入力されたかを判定し、当該判定結果に基づいて検索を実行する。ここでは、ユーザの検索条件は、ユーザデータベースＤＢ２等に保持されているものとする。第２検索部３００は、ユーザ端末１０から受信した検索条件と、ユーザデータベースＤＢ２等に保持された検索条件と、を比較し、これらが一致するかを判定する。第２検索部３００は、これらが一致する場合には、ユーザにより新たな時間及び場所が入力されたとは判定せず、これらが一致した場合に、ユーザにより新たな時間及び場所が入力されたと判定する。

第２検索部３００は、ユーザにより新たな時間及び場所が入力されたと判定した場合に、当該新たな時間及び場所に基づいて検索されたアイテムの時間及び場所に基づいて、検索を実行する。検索方法自体は、実施形態で説明した通りである。なお、古い検索条件に基づいてレコメンドが実行されてもよいが、その場合には、古い検索条件に基づくレコメンドであることが識別可能なようにレコメンドされるものとする。

変形例（７）によれば、ユーザにより入力された時間及び場所が変更されたかの判定結果に基づいて検索を実行することで、ユーザにとって不要なレコメンドがなされる蓋然性を低減し、レコメンドの精度を高めることができる。

（８）また例えば、ユーザは、複数の旅程を作成可能であってもよい。即ち、１人のユーザに対して複数の旅行かごを割り当てて、ユーザが複数の旅程を同時に計画できるようにしてもよい。

例えば、ユーザは、アイテムを追加する場合に旅程を指定してもよいし、旅程を指定したうえでアイテムを追加してもよい。また例えば、ユーザにより選択されたアイテムの場所及び時間の少なくとも１つに基づいて、当該アイテムが属する旅程が自動的に判別されてもよい。例えば、ユーザにより選択されたアイテムが、当該アイテムの場所に対応する場所のアイテムが組み込まれた旅程に入れられる。また例えば、ユーザにより選択されたアイテムが、当該アイテムの時間に対応する時間のアイテムが組み込まれた旅程に入れられる。

第２検索部３００は、旅程ごとに、当該旅程に含まれるアイテムの時間及び場所に基づいて検索を実行する。各旅程における検索方法自体は、実施形態で説明した通りである。第２検索部３００は、旅程ごとに、当該旅程に含まれるアイテムの時間及び場所をクエリとし、アイテムデータベースＤＢ１に格納された基本情報をインデックスとして、他の種類のアイテムを検索する。第２検索部３００は、旅程の数だけ検索を実行することになる。提示部３０１は、旅程ごとに、第２検索部３００により検索されたアイテムを提示する。アイテムの提示方法自体は、実施形態で説明した通りである。

図１７は、変形例（８）における旅行かご画面Ｇ４の一例を示す図である。図１７の例では、表示領域Ａ４０Ａに示す「かご１」は、１つ目の旅行かごであり、１つ目の旅程を示す。一方、表示領域Ａ４０Ｂに示す「かご２」は、２つ目の旅行かごであり、２つ目の旅程を示す。旅行かごは、２つに限られず、３つ以上であってもよく、旅程ごとに旅行かごが用意されるようにすればよい。

図１７に示すように、「かご１」の旅程に組み込まれたアイテムの時間及び場所に基づいて、１つ目の旅程のレコメンドが行われ、表示領域Ａ４１Ａには、１つ目の旅程でレコメンドされたアイテムが表示される。ユーザがボタンＢ４１０Ａを選択した場合、当該アイテムを１つ目の旅程に追加することができる。

また、「かご２」の旅程に組み込まれたアイテムの時間及び場所に基づいて、２つ目の旅程のレコメンドが行われ、表示領域Ａ４１Ｂには、２つ目の旅程でレコメンドされたアイテムが表示される。ユーザがボタンＢ４１０Ｂを選択した場合、当該アイテムを２つ目の旅程に追加することができる。

変形例（８）によれば、ユーザが複数の旅程を作成する場合に、旅程ごとにアイテムを検索してレコメンドすることで、レコメンドの精度を効果的に高めることができる。

（９）また例えば、変形例（８）において、ユーザが複数の旅程を同時に作成する場合に、第２検索部３００は、ユーザにより選択された複数の宿泊施設アイテムの各々の日付が連続している場合に、各宿泊施設アイテムが同じ旅程に含まれると判定してもよい。第２検索部３００は、ユーザにより選択された複数の宿泊施設アイテムの日付を参照し、間が空くことなく日付が続いているかを判定する。第２検索部３００は、間が空くことなく日付が続いている場合、各宿泊施設アイテムを同じ旅程に含まれると判定し、各宿泊施設アイテムに対し、同じ旅行かごＩＤを付与する。

変形例（９）によれば、ユーザにより選択された複数の宿泊施設アイテムの日付が連続している場合に、これら複数の宿泊施設アイテムが同じ旅程に含まれると判定することで、旅程を区別する精度が高まるので、レコメンドの精度を効果的に高めることができる。

（１０）また例えば、第２検索部３００は、ユーザにより選択されたアイテムの時間に基づいて旅程の期間を特定し、当該期間に基づいて検索を実行してもよい。第２検索部３００は、ユーザにより選択されたアイテムの時間を参照し、最も早い時間に基づいて期間の開始時点を特定し、最も遅い時間に基づいて期間の終了時点を特定する。第２検索部３００は、開始時点から終了時点までの期間をクエリとし、検索を実行する。検索の実行方法自体は、実施形態で説明した通りである。

変形例（１０）によれば、ユーザにより選択されたアイテムの時間に基づいて特定された旅程の期間に基づいて検索を実行してレコメンドすることで、ユーザの旅程には関係のない期間のアイテムがレコメンドされることを防止し、レコメンドの精度を効果的に高めることができる。

（１１）また例えば、第２検索部３００は、ユーザにより選択されたアイテムの時間及び場所に基づいて他の種類のアイテムの利用可能性を判定し、当該判定結果に基づいて検索を実行してもよい。利用可能性とは、移動が間に合うか否かである。移動が間に合う場合は、利用可能性があり、移動が間に合わない場合は、利用可能性がない。

第２検索部３００は、ユーザにより選択されたアイテムの時間及び場所と、他の種類のアイテムの時間及び場所と、に基づいて、他の種類のアイテムの利用可能性を判定する。例えば、第２検索部３００は、ユーザにより選択されたアイテムの場所と、他の種類のアイテムの場所と、に基づいて、移動時間を計算する。第２検索部３００は、ユーザにより選択されたアイテムの時間に当該移動時間を加えた時間が、他の種類のアイテムの時間よりも前であれば、他の種類のアイテムを利用可能と判定し、後であれば、他の種類のアイテムを利用不可能と判定する。提示部３０１によるレコメンドは、利用可能なアイテムを対象とし、利用不可能なアイテムは対象外とする。

変形例（１１）によれば、他の種類のアイテムの利用可能性の判定結果に基づいて検索を実行してレコメンドすることで、利用不可能なアイテムがレコメンドされてしまうことを防止し、レコメンドの精度を効果的に高めることができる。

（１２）また例えば、上記説明した変形例を組み合わせてもよい。

また例えば、主な機能がウェブサーバ２０と分析サーバ３０との間で分担される場合を説明したが、各機能は、ウェブサーバ２０又は分析サーバ３０だけで実現されてもよい。例えば、ウェブサーバ２０において第２検索部３００が実現されてもよい。この場合、第２検索部３００は制御部２１を主として実現される。ウェブサーバ２０の第２検索部３００は、受付部２０１により選択を受け付けたアイテムの時間及び場所を特定し、他の種類のアイテムを検索する。また例えば、ウェブサーバ２０において提示部３０１が実現されてもよい。この場合、提示部３０１は制御部２１を主として実現される。ウェブサーバ２０の提示部３０１は、第２検索部３００の検索結果を取得し、検索されたアイテムを提示する。

また例えば、分析サーバ３０において、第１検索部２００が実現されてもよい。この場合、第１検索部２００は、制御部３１を主として実現される。分析サーバ３０の第１検索部２００は、ユーザ端末１０から検索条件を取得し、検索を実行する。また例えば、分析サーバ３０において、受付部２０１が実現されてもよい。この場合、受付部２０１は、制御部３１を主として実現される。分析サーバ３０の受付部２０１は、ユーザ端末１０からアイテムの選択結果を受信する。

また例えば、データ記憶部４００で記憶されるものとして説明したデータは、データベースサーバ４０とは異なるコンピュータによって記憶されてもよい。例えば、データ記憶部４００がウェブサーバ２０又は分析サーバ３０によって実現されてもよい。この場合、データ記憶部４００は、記憶部２２又は３２によって実現される。他にも例えば、データは、旅行計画システムＳの外部にあるデータベースサーバによって記憶されていてもよい。

Ｓ 旅行計画システム、Ｎ ネットワーク、１０ ユーザ端末、１１，２１，３１，４１ 制御部、１２，２２，３２，４２ 記憶部、１３，２３，３３，４３ 通信部、１４ 操作部、１５ 表示部、２０ ウェブサーバ、３０ 分析サーバ、４０ データベースサーバ、Ｇ１，Ｇ１Ａ，Ｇ１Ｂ トップ画面、Ｇ２ 検索結果画面、Ｇ３ アイテム画面、Ｇ４，Ｇ４Ａ，Ｇ４Ｂ，Ｇ４Ｃ，Ｇ４Ｄ 旅行かご画面、１００ データ記憶部、１０１ 受付部、１０２ 表示制御部、２０１ 受付部、２０２ 出発地取得部、３０１ 提示部、３０２ 出発地取得部、３０３ 特定部、４００ データ記憶部、Ａ４０，Ａ４１，Ａ４１Ａ，Ａ４１Ｂ，Ａ４１Ｃ 表示領域、Ｂ１４，Ｂ３０，Ａ４１０，Ａ４１０Ａ，Ａ４１０Ｂ，Ａ４１０Ｃ，Ｂ４００，Ｂ４０１，Ｂ４１０ ボタン、ＤＢ１ アイテムデータベース、ＤＢ２ ユーザデータベース、ＤＢ３ レコメンドデータベース、Ｆ１０，Ｆ１１，Ｆ１２，Ｆ１３，Ｆ２０ 入力フォーム、Ｌ２１ リスト。

Claims (15)

1. ユーザにより入力された時間及び場所に基づいて、旅程に組み込む宿泊施設、交通手段、レンタカー、アクティビティ、レストラン、又は観光施設の何れかの種類のサービスを利用する時間と場所が関連付けられたアイテムを検索する第１検索手段と、
   前記第１検索手段の検索結果の中から、前記ユーザによる選択を受け付ける受付手段と、
   前記ユーザにより選択されたアイテムの時間及び場所に基づき、且つ、前記ユーザにより選択されたアイテムの種類を除外した他の種類をクエリとして設定して、検索を実行する第２検索手段と、
   前記第２検索手段により前記クエリとして設定されて検索された他の種類のアイテムを、選択可能に提示する提示手段と、
   を含むことを特徴とする旅行計画システム。
2. 前記旅行計画システムは、前記第１検索手段の検索結果の中から前記ユーザにより選択されたアイテムを、前記旅程に組み込む組込手段を更に含み、
   前記組込手段は、前記提示手段により提示されたアイテムが前記ユーザにより選択された場合に、当該アイテムを前記旅程に組み込み、
   前記旅行計画システムは、前記ユーザにより所定の予約操作が行われた場合に、前記旅程に組み込まれた複数のアイテムをまとめて予約する予約処理を実行する予約手段を更に含む、
   ことを特徴とする請求項１に記載の旅行計画システム。
3. 前記旅行計画システムは、
   前記ユーザの出発地を取得する出発地取得手段と、
   他のユーザにより選択された、現地アイテムと、当該他のユーザの出発地と現地との間の交通手段アイテムと、を特定する特定手段と、
   を更に含み、
   前記第２検索手段は、前記ユーザにより現地アイテムが選択された場合に、出発地と、現地アイテムの場所と、が前記ユーザと対応する前記他のユーザにより選択された交通手段アイテムに基づいて、前記ユーザの出発地と現地との間の交通手段アイテムを検索する、
   ことを特徴とする請求項１又は２に記載の旅行計画システム。
4. 前記第２検索手段は、前記他のユーザにより選択された交通手段アイテムに対応する交通手段アイテムの在庫がない場合に、現地への到着時間が、前記他のユーザにより選択された交通手段アイテムよりも早い交通手段アイテムを検索する、
   ことを特徴とする請求項３に記載の旅行計画システム。
5. 前記第２検索手段は、前記他のユーザにより選択された交通手段アイテムに対応する交通手段アイテムの在庫がない場合に、現地からの出発時間が、前記他のユーザにより選択された交通手段アイテムよりも遅い交通手段アイテムを検索する、
   ことを特徴とする請求項３又は４に記載の旅行計画システム。
6. 前記旅程は、複数の期間にまたがる旅程であり、
   前記第２検索手段は、前記期間ごとに、当該期間におけるアイテムの時間及び場所に基づいて検索を実行し、
   前記提示手段は、前記期間ごとに、前記第２検索手段により検索されたアイテムを提示する、
   ことを特徴とする請求項１～５の何れかに記載の旅行計画システム。
7. 前記旅行計画システムは、前記ユーザにより登録されたユーザ登録情報、又は、前記ユーザの通信環境に基づいて、前記ユーザの出発地を取得する出発地取得手段を更に含み、
   前記第２検索手段は、前記出発地取得手段により取得された前記ユーザの出発地に基づいて検索を実行する、
   ことを特徴とする請求項１～６の何れかに記載の旅行計画システム。
8. 前記第２検索手段は、前記ユーザにより選択されたアイテムの時間が経過したかを判定し、当該判定結果に基づいて検索を実行する、
   ことを特徴とする請求項１～７の何れかに記載の旅行計画システム。
9. 前記第２検索手段は、前記ユーザにより新たな時間及び場所が入力されたかを判定し、当該判定結果に基づいて検索を実行する、
   ことを特徴とする請求項１～８の何れかに記載の旅行計画システム。
10. 前記ユーザは、複数の旅程を作成可能であり、
    前記第２検索手段は、前記旅程ごとに、当該旅程に含まれるアイテムの時間及び場所に基づいて検索を実行し、
    前記提示手段は、前記旅程ごとに、前記第２検索手段により検索されたアイテムを提示する、
    ことを特徴とする請求項１～９の何れかに記載の旅行計画システム。
11. 前記第２検索手段は、前記ユーザにより選択された複数の宿泊施設アイテムの各々の日付が連続している場合に、各宿泊施設アイテムが同じ旅程に含まれると判定する、
    ことを特徴とする請求項１０に記載の旅行計画システム。
12. 前記第２検索手段は、前記ユーザにより選択されたアイテムの時間に基づいて前記旅程の期間を特定し、当該期間に基づいて検索を実行する、
    ことを特徴とする請求項１～１１の何れかに記載の旅行計画システム。
13. 前記第２検索手段は、前記ユーザにより選択されたアイテムの時間及び場所に基づいて他の種類のアイテムの利用可能性を判定し、当該判定結果に基づいて検索を実行する、
    ことを特徴とする請求項１～１２の何れかに記載の旅行計画システム。
14. コンピュータが、
    ユーザにより入力された時間及び場所に基づいて、旅程に組み込む宿泊施設、交通手段、レンタカー、アクティビティ、レストラン、又は観光施設の何れかの種類のサービスを利用する時間と場所が関連付けられたアイテムを検索する第１検索ステップと、
    前記第１検索ステップの検索結果の中から、前記ユーザによる選択を受け付ける受付ステップと、
    前記ユーザにより選択されたアイテムの時間及び場所に基づき、且つ、前記ユーザにより選択されたアイテムの種類を除外した他の種類をクエリとして設定して検索を実行する第２検索ステップと、
    前記第２検索ステップにより前記クエリとして設定されて検索された他の種類のアイテムを、選択可能に提示する提示ステップと、
    を実行することを特徴とする旅行計画方法。
15. ユーザにより入力された時間及び場所に基づいて、旅程に組み込む宿泊施設、交通手段、レンタカー、アクティビティ、レストラン、又は観光施設の何れかの種類のサービスを利用する時間と場所が関連付けられたアイテムを検索する第１検索手段、
    前記第１検索手段の検索結果の中から、前記ユーザによる選択を受け付ける受付手段、
    前記ユーザにより選択されたアイテムの時間及び場所に基づき、且つ、前記ユーザにより選択されたアイテムの種類を除外した他の種類をクエリとして設定して検索を実行する第２検索手段、
    前記第２検索手段により前記クエリとして設定されて検索された他の種類のアイテムを、選択可能に提示する提示手段、
    としてコンピュータを機能させるためのプログラム。

Images