(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-07-03
(45)【発行日】2023-07-11
(54)【発明の名称】旅行計画システム、旅行計画方法、及びプログラム
(51)【国際特許分類】
G06Q 50/14 20120101AFI20230704BHJP
【FI】
G06Q50/14
(21)【出願番号】P 2018124821
(22)【出願日】2018-06-29
【審査請求日】2021-01-18
【審判番号】
【審判請求日】2022-10-12
(73)【特許権者】
【識別番号】399037405
【氏名又は名称】楽天グループ株式会社
(74)【代理人】
【識別番号】110000154
【氏名又は名称】弁理士法人はるか国際特許事務所
(72)【発明者】
【氏名】黒澤 隆由
【合議体】
【審判長】佐藤 智康
【審判官】中野 浩昌
【審判官】松尾 俊介
(56)【参考文献】
【文献】特開2014-115778(JP,A)
【文献】特開2010-73184(JP,A)
【文献】特開平3-252792(JP,A)
【文献】特開2005-18369(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q10/00-99/00
(57)【特許請求の範囲】
【請求項1】
ユーザにより入力された時間及び場所に基づいて、旅程に組み込む宿泊施設、交通手段、レンタカー、アクティビティ、レストラン、又は観光施設の何れかの種類のサービスを利用する時間と場所が関連付けられたアイテムを検索する第1検索手段と、
前記第1検索手段の検索結果の中から、前記ユーザによる選択を受け付ける受付手段と、
前記ユーザにより選択されたアイテムの時間及び場所に基づ
き、且つ、前記ユーザにより選択されたアイテムの種類を除外した他の種類
をクエリとして設定して、検索
を実行する第2検索手段と、
前記第2検索手段により
前記クエリとして設定されて検索された
他の種類のアイテムを、選択可能に提示する提示手段と、
を含むことを特徴とする旅行計画システム。
【請求項2】
前記旅行計画システムは、前記第1検索手段の検索結果の中から前記ユーザにより選択されたアイテムを、前記旅程に組み込む組込手段を更に含み、
前記組込手段は、前記提示手段により提示されたアイテムが前記ユーザにより選択された場合に、当該アイテムを前記旅程に組み込み、
前記旅行計画システムは、前記ユーザにより所定の予約操作が行われた場合に、前記旅程に組み込まれた複数のアイテムをまとめて予約する予約処理を実行する予約手段を更に含む、
ことを特徴とする請求項1に記載の旅行計画システム。
【請求項3】
前記旅行計画システムは、
前記ユーザの出発地を取得する出発地取得手段と、
他のユーザにより選択された、現地アイテムと、当該他のユーザの出発地と現地との間の交通手段アイテムと、を特定する特定手段と、
を更に含み、
前記第2検索手段は、前記ユーザにより現地アイテムが選択された場合に、出発地と、現地アイテムの場所と、が前記ユーザと対応する前記他のユーザにより選択された交通手段アイテムに基づいて、前記ユーザの出発地と現地との間の交通手段アイテムを検索する、
ことを特徴とする請求項1又は2に記載の旅行計画システム。
【請求項4】
前記第2検索手段は、前記他のユーザにより選択された交通手段アイテムに対応する交通手段アイテムの在庫がない場合に、現地への到着時間が、前記他のユーザにより選択された交通手段アイテムよりも早い交通手段アイテムを検索する、
ことを特徴とする請求項3に記載の旅行計画システム。
【請求項5】
前記第2検索手段は、前記他のユーザにより選択された交通手段アイテムに対応する交通手段アイテムの在庫がない場合に、現地からの出発時間が、前記他のユーザにより選択された交通手段アイテムよりも遅い交通手段アイテムを検索する、
ことを特徴とする請求項3又は4に記載の旅行計画システム。
【請求項6】
前記旅程は、複数の期間にまたがる旅程であり、
前記第2検索手段は、前記期間ごとに、当該期間におけるアイテムの時間及び場所に基づいて検索を実行し、
前記提示手段は、前記期間ごとに、前記第2検索手段により検索されたアイテムを提示する、
ことを特徴とする請求項1~5の何れかに記載の旅行計画システム。
【請求項7】
前記旅行計画システムは、前記ユーザにより登録されたユーザ登録情報、又は、前記ユーザの通信環境に基づいて、前記ユーザの出発地を取得する出発地取得手段を更に含み、
前記第2検索手段は、前記出発地取得手段により取得された前記ユーザの出発地に基づいて検索を実行する、
ことを特徴とする請求項1~6の何れかに記載の旅行計画システム。
【請求項8】
前記第2検索手段は、前記ユーザにより選択されたアイテムの時間が経過したかを判定し、当該判定結果に基づいて検索を実行する、
ことを特徴とする請求項1~7の何れかに記載の旅行計画システム。
【請求項9】
前記第2検索手段は、前記ユーザにより新たな時間及び場所が入力されたかを判定し、当該判定結果に基づいて検索を実行する、
ことを特徴とする請求項1~8の何れかに記載の旅行計画システム。
【請求項10】
前記ユーザは、複数の旅程を作成可能であり、
前記第2検索手段は、前記旅程ごとに、当該旅程に含まれるアイテムの時間及び場所に基づいて検索を実行し、
前記提示手段は、前記旅程ごとに、前記第2検索手段により検索されたアイテムを提示する、
ことを特徴とする請求項1~9の何れかに記載の旅行計画システム。
【請求項11】
前記第2検索手段は、前記ユーザにより選択された複数の宿泊施設アイテムの各々の日付が連続している場合に、各宿泊施設アイテムが同じ旅程に含まれると判定する、
ことを特徴とする請求項10に記載の旅行計画システム。
【請求項12】
前記第2検索手段は、前記ユーザにより選択されたアイテムの時間に基づいて前記旅程の期間を特定し、当該期間に基づいて検索を実行する、
ことを特徴とする請求項1~11の何れかに記載の旅行計画システム。
【請求項13】
前記第2検索手段は、前記ユーザにより選択されたアイテムの時間及び場所に基づいて他の種類のアイテムの利用可能性を判定し、当該判定結果に基づいて検索を実行する、
ことを特徴とする請求項1~12の何れかに記載の旅行計画システム。
【請求項14】
コンピュータが、
ユーザにより入力された時間及び場所に基づいて、旅程に組み込む宿泊施設、交通手段、レンタカー、アクティビティ、レストラン、又は観光施設の何れかの種類のサービスを利用する時間と場所が関連付けられたアイテムを検索する第1検索ステップと、
前記第1検索ステップの検索結果の中から、前記ユーザによる選択を受け付ける受付ステップと、
前記ユーザにより選択されたアイテムの時間及び場所に基づ
き、且つ、
前記ユーザにより選択されたアイテムの種類を除外した他の種類
をクエリとして設定して検索
を実行する第2検索ステップと、
前記第2検索ステップにより
前記クエリとして設定されて検索された
他の種類のアイテムを、選択可能に提示する提示ステップと、
を実行することを特徴とする旅行計画方法。
【請求項15】
ユーザにより入力された時間及び場所に基づいて、旅程に組み込む宿泊施設、交通手段、レンタカー、アクティビティ、レストラン、又は観光施設の何れかの種類のサービスを利用する時間と場所が関連付けられたアイテムを検索する第1検索手段、
前記第1検索手段の検索結果の中から、前記ユーザによる選択を受け付ける受付手段、
前記ユーザにより選択されたアイテムの時間及び場所に基づ
き、且つ、
前記ユーザにより選択されたアイテムの種類を除外した他の種類
をクエリとして設定して検索
を実行する第2検索手段、
前記第2検索手段により
前記クエリとして設定されて検索された
他の種類のアイテムを、選択可能に提示する提示手段、
としてコンピュータを機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、旅行計画システム、旅行計画方法、及びプログラムに関する。
【背景技術】
【0002】
従来、ユーザの旅程に組み込むアイテムを検索する技術が知られている。例えば、特許文献1には、ユーザにより入力された時間及び場所等の検索条件に基づいて、アイテムの一例である宿泊施設を検索し、検索結果の中からユーザによる宿泊施設の選択を受け付けるシステムが記載されている。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
ユーザは、1種類のアイテムだけではなく、複数種類のアイテムを旅程に組み込むことがある。例えば、ユーザは、宿泊施設だけではなく、往復の交通手段、アクティビティ、レンタカー、及びレストランといった複数種類のアイテムを旅程に組み込むことがある。
【0005】
しかしながら、特許文献1のシステムでは、ユーザは、ホテルを検索した後に、航空券等の他の種類のアイテムを提供するウェブサイトにアクセスし、ホテルの検索時と同様の検索条件を再び入力して他の種類のアイテムを探す必要があるので、非常に手間がかかっていた。
【0006】
本発明は上記課題に鑑みてなされたものであって、その目的は、複数種類のアイテムを含む旅程を作成する手間を軽減することが可能な旅行計画システム、旅行計画方法、及びプログラムを提供することである。
【課題を解決するための手段】
【0007】
上記課題を解決するために、本発明に係る旅行計画システムは、ユーザにより入力された時間及び場所に基づいて、旅程に組み込むアイテムを検索する第1検索手段と、前記第1検索手段の検索結果の中から、前記ユーザによる選択を受け付ける受付手段と、前記ユーザにより選択されたアイテムの時間及び場所に基づいて、他の種類のアイテムを検索する第2検索手段と、前記第2検索手段により検索されたアイテムを、選択可能に提示する提示手段と、を含むことを特徴とする。
【0008】
本発明に係る旅行計画方法は、ユーザにより入力された時間及び場所に基づいて、旅程に組み込むアイテムを検索する第1検索ステップと、前記第1検索ステップの検索結果の中から、前記ユーザによる選択を受け付ける受付ステップと、前記ユーザにより選択されたアイテムの時間及び場所に基づいて、他の種類のアイテムを検索する第2検索ステップと、前記第2検索ステップにより検索されたアイテムを、選択可能に提示する提示ステップと、を含むことを特徴とする。
【0009】
本発明に係るプログラムは、ユーザにより入力された時間及び場所に基づいて、旅程に組み込むアイテムを検索する第1検索手段、前記第1検索手段の検索結果の中から、前記ユーザによる選択を受け付ける受付手段、前記ユーザにより選択されたアイテムの時間及び場所に基づいて、他の種類のアイテムを検索する第2検索手段、前記第2検索手段により検索されたアイテムを、選択可能に提示する提示手段、としてコンピュータを機能させる。
【0010】
本発明の一態様によれば、前記旅行計画システムは、前記ユーザの出発地を取得する出発地取得手段と、他のユーザにより選択された、現地アイテムと、当該他のユーザの出発地と現地との間の交通手段アイテムと、を特定する特定手段と、を更に含み、前記第2検索手段は、前記ユーザにより現地アイテムが選択された場合に、出発地と、現地アイテムの場所と、が前記ユーザと対応する前記他のユーザにより選択された交通手段アイテムに基づいて、前記ユーザの出発地と現地との間の交通手段アイテムを検索する、ことを特徴とする。
【0011】
本発明の一態様によれば、前記第2検索手段は、前記他のユーザにより選択された交通手段アイテムに対応する交通手段アイテムの在庫がない場合に、現地への到着時間が、前記他のユーザにより選択された交通手段アイテムよりも早い交通手段アイテムを検索する、ことを特徴とする。
【0012】
本発明の一態様によれば、前記第2検索手段は、前記他のユーザにより選択された交通手段アイテムに対応する交通手段アイテムの在庫がない場合に、現地からの出発時間が、前記他のユーザにより選択された交通手段アイテムよりも遅い交通手段アイテムを検索する、ことを特徴とする。
【0013】
本発明の一態様によれば、前記旅程は、複数の期間にまたがる旅程であり、前記第2検索手段は、前記期間ごとに、当該期間におけるアイテムの時間及び場所に基づいて検索を実行し、前記提示手段は、前記期間ごとに、前記第2検索手段により検索されたアイテムを提示する、ことを特徴とする。
【0014】
本発明の一態様によれば、前記旅行計画システムは、前記ユーザにより登録されたユーザ登録情報、又は、前記ユーザの通信環境に基づいて、前記ユーザの出発地を取得する出発地取得手段を更に含み、前記第2検索手段は、前記出発地取得手段により取得された前記ユーザの出発地に基づいて検索を実行する、ことを特徴とする。
【0015】
本発明の一態様によれば、前記第2検索手段は、前記ユーザにより選択されたアイテムの時間が経過したかを判定し、当該判定結果に基づいて検索を実行する、ことを特徴とする。
【0016】
本発明の一態様によれば、前記第2検索手段は、前記ユーザにより新たな時間及び場所が入力されたかを判定し、当該判定結果に基づいて検索を実行する、ことを特徴とする。
【0017】
本発明の一態様によれば、前記ユーザは、複数の旅程を作成可能であり、前記第2検索手段は、前記旅程ごとに、当該旅程に含まれるアイテムの時間及び場所に基づいて検索を実行し、前記提示手段は、前記旅程ごとに、前記第2検索手段により検索されたアイテムを提示する、ことを特徴とする。
【0018】
本発明の一態様によれば、前記第2検索手段は、前記ユーザにより選択された複数の宿泊施設アイテムの各々の日付が連続している場合に、各宿泊施設アイテムが同じ旅程に含まれると判定する、ことを特徴とする。
【0019】
本発明の一態様によれば、前記第2検索手段は、前記ユーザにより選択されたアイテムの時間に基づいて前記旅程の期間を特定し、当該期間に基づいて検索を実行する、ことを特徴とする。
【0020】
本発明の一態様によれば、前記第2検索手段は、前記ユーザにより選択されたアイテムの時間及び場所に基づいて他の種類のアイテムの利用可能性を判定し、当該判定結果に基づいて検索を実行する、ことを特徴とする。
【発明の効果】
【0021】
本発明によれば、複数種類のアイテムを含む旅程を作成する手間を軽減することが可能となる。
【図面の簡単な説明】
【0022】
【
図1】旅行計画システムの全体構成を示す図である。
【
図5】レコメンドされたアイテムが旅行かごに追加される様子を示す図である。
【
図6】本実施形態の旅行計画システムSで実現される機能の一例を示す機能ブロック図である。
【
図7】アイテムデータベースのデータ格納例を示す図である。
【
図8】ユーザデータベースのデータ格納例を示す図である。
【
図9】レコメンドデータベースのデータ格納例を示す図である。
【
図10】旅行計画システムにおいて実行される処理の一例を示すフロー図である。
【
図11】旅行計画システムにおいて実行される処理の一例を示すフロー図である。
【
図13】変形例(1)における旅行かご画面の一例を示す図である。
【
図14】変形例(2)における旅行かご画面の一例を示す図である。
【
図15】変形例(3)における旅行かご画面の一例を示す図である。
【
図16】変形例(4)における旅行かご画面の一例を示す図である。
【
図17】変形例(8)における旅行かご画面の一例を示す図である。
【発明を実施するための形態】
【0023】
[1.旅行計画システムの全体構成]
以下、本発明に係る旅行計画システムの実施形態の例を説明する。
図1は、旅行計画システムの全体構成を示す図である。
図1に示すように、旅行計画システムSは、ユーザ端末10、ウェブサーバ20、分析サーバ30、及びデータベースサーバ40を含み、これらは、インターネットなどのネットワークNに接続可能である。
【0024】
なお、
図1ではユーザ端末10、ウェブサーバ20、分析サーバ30、及びデータベースサーバ40の各々を1台ずつ示しているが、これらは複数台あってもよい。更に、ウェブサーバ20、分析サーバ30、及びデータベースサーバ40の3つのサーバコンピュータが旅行計画システムSに含まれる場合を例に挙げるが、旅行計画システムSには、1つのサーバコンピュータだけが含まれてもよいし、2つ又は4つ以上のサーバコンピュータが含まれてもよい。
【0025】
ユーザ端末10は、ユーザが操作するコンピュータである。例えば、ユーザ端末10は、携帯電話機(スマートフォンを含む)、携帯情報端末(タブレット型コンピュータを含む)、又は、パーソナルコンピュータ等である。本実施形態では、ユーザ端末10は、制御部11、記憶部12、通信部13、操作部14、及び表示部15を含む。
【0026】
制御部11は、少なくとも一つのマイクロプロセッサを含む。制御部11は、記憶部12に記憶されたプログラムやデータに従って処理を実行する。記憶部12は、主記憶部及び補助記憶部を含む。例えば、主記憶部はRAMなどの揮発性メモリであり、補助記憶部は、ROM、EEPROM、フラッシュメモリ、又はハードディスクなどの不揮発性メモリである。
【0027】
通信部13は、有線通信又は無線通信用の通信インタフェースであり、ネットワークを介してデータ通信を行う。操作部14は、ユーザが操作を行うための入力デバイスであり、例えば、タッチパネルやマウス等のポインティングデバイス、キーボード、又はボタン等である。操作部14は、ユーザによる操作内容を制御部11に伝達する。表示部15は、例えば、液晶表示部又は有機EL表示部等である。表示部15は、制御部11の指示に従って画像を表示する。
【0028】
ウェブサーバ20は、サーバコンピュータである。ウェブサーバ20は、ウェブサイトを管理する。例えば、ユーザ端末10のウェブブラウザ上で画面が表示される場合には、ウェブサーバ20は、ユーザ端末10からHTTPリクエストを受け付けると、ユーザ端末10に対し、HTTPレスポンスを送信する。また例えば、ユーザ端末10のアプリケーション上で画面が表示される場合には、ウェブサーバ20は、ユーザ端末10から、アプリケーションで利用される通信プロトコルで定められたリクエストを受け付けると、ユーザ端末10に対し、当該通信プロトコルで定められたレスポンスを送信する。ウェブサーバ20は、制御部21、記憶部22、及び通信部23を含む。制御部21、記憶部22、及び通信部23の物理的構成は、それぞれ制御部11、記憶部12、及び通信部13と同様であってよい。
【0029】
分析サーバ30は、サーバコンピュータである。分析サーバ30は、ユーザに対するレコメンドの分析を行う。分析サーバ30は、制御部31、記憶部32、及び通信部33を含む。制御部31、記憶部32、及び通信部33の物理的構成は、それぞれ制御部11、記憶部12、及び通信部13と同様であってよい。
【0030】
データベースサーバ40は、サーバコンピュータである。例えば、データベースサーバ40は、後述する各種データベースを記憶する。データベースサーバ40は、制御部41、記憶部42、及び通信部43を含む。制御部41、記憶部42、及び通信部43の物理的構成は、それぞれ制御部11、記憶部12、及び通信部13と同様であってよい。
【0031】
なお、記憶部12,22,32,42に記憶されるものとして説明するプログラム及びデータは、ネットワークNを介して供給されるようにしてもよい。また、上記説明した各コンピュータのハードウェア構成は、上記の例に限られず、種々のハードウェアを適用可能である。例えば、コンピュータ読み取り可能な情報記憶媒体を読み取る読取部(例えば、光ディスクドライブやメモリカードスロット)や外部機器とデータの入出力をするための入出力部(例えば、USBポート)が含まれていてもよい。例えば、情報記憶媒体に記憶されたプログラムやデータが読取部や入出力部を介して、各コンピュータに供給されるようにしてもよい。
【0032】
[2.旅行計画システムの概要]
旅行計画システムSは、ユーザに旅行予約サービスを提供し、旅程の作成を支援する。旅程は、旅行の計画、行程、又は日程であり、少なくとも1つのアイテムから構成される。アイテムは、旅程の構成要素であり、旅行中の個々の予定である。別の言い方をすれば、アイテムは、予約又は購入の対象となる個々の旅行商品(例えば、施設、乗物、又はサービス)である。
【0033】
旅程には、複数種類のアイテムを組み込むことができる。アイテムの種類は、宿泊施設、交通手段(移動手段)、レンタカー、アクティビティ(オプションツアー)、レストラン、又は観光施設といった任意の種類であってよい。宿泊施設は、ホテル、旅館、民宿、ペンション、又は民泊といった施設である。交通手段は、航空機、電車、バス、又は船舶といった手段である。観光施設は、水族館、動物園、テーマパーク、公園、寺、神社、又は競技場といった施設である。
【0034】
例えば、ユーザがユーザ端末10を操作して、ウェブサーバ20にアクセスすると、旅行予約サービスのトップ画面が表示部15に表示される。本実施形態では、以降説明する画面がウェブブラウザ上で表示される場合を説明するが、旅行予約サービスのアプリケーション上で表示されてもよい。
【0035】
図2は、トップ画面の一例を示す図である。
図2に示すように、例えば、トップ画面G1には、アイテムの検索条件を入力するための入力フォームF10~F13と、検索を実行するためのボタンB14と、が表示される。
【0036】
検索条件は、検索で用いられるクエリであり、任意の条件を入力可能である。検索条件は、キーワードであってもよいし、予め定められた複数の数値の中から選択された数値であってもよいし、カテゴリのような属性情報であってもよい。数値は、時間、人数、又は予算といった条件の数値である。
【0037】
なお、時間は、日付(年月日)だけを意味してもよいし、日付と時刻を含む日時を意味してもよい。更に、時間は、特定の時点を示してもよいし、大まかな期間を示してもよい。期間は、ある1日における時間帯を示してもよいし、複数の日にまたがる期間を示してもよい。例えば、アイテムが宿泊施設であれば、アイテムの時間は、チェックイン日、チェックイン時刻、チェックアウト日、及びチェックアウト時刻である。また例えば、アイテムが交通手段であれば、アイテムの時間は、出発日、出発時刻、到着日、及び到着時刻である。また例えば、アイテムがレンタカーであれば、アイテムの時間は、出発日、出発時刻、返却日、及び返却時刻である。また例えば、アイテムがアクティビティであれば、アイテムの時間は、利用日、集合時刻、及び解散時刻である。また例えば、アイテムがレストランであれば、アイテムの時間は、予約日と予約時刻である。また例えば、アイテムが観光施設であれば、アイテムの時間は、利用日と利用時刻である。
【0038】
ユーザは、トップ画面G1から種々の検索条件を入力可能である。例えば、ホテルであれば、宿泊地、利用日(宿泊日)、利用人数、及び宿泊費といった検索条件が入力される。また例えば、航空券であれば、出発地、目的地、出発日、出発時刻、到着日、到着時刻、航空会社、及び運賃といった検索条件が入力される。また例えば、レンタカーであれば、出発場所、返却場所、利用日、利用時刻、車種、及びレンタル料といった検索条件が入力される。また例えば、バスであれば、出発地、目的地、出発日、出発時刻、到着日、到着時刻、バス会社、及び運賃といった検索条件が入力される。なお、検索条件として入力される時刻は、「14時」のように特定の時点が入力されてもよいし、「14時~16時」といった時間帯(時間の幅)が入力されてもよい。
【0039】
トップ画面G1では、ホテル、航空券、レンタカー、又はバスといったアイテムの種類ごとに、検索条件を入力可能となっている。なお、
図2ではスペースの都合上省略しているが、トップ画面G1は、アクティビティ、レストラン、又は観光施設といった他の種類のアイテムの検索条件を入力可能であってもよい。
【0040】
トップ画面G1では、旅行計画システムSが取り扱う複数種類のアイテムのうち、検索対象のアイテムの種類を指定できるようになっている。本実施形態では、説明の簡略化のために、ユーザが1種類の検索対象を指定する場合を説明するが、「ホテル+航空券」や「ホテル+アクティビティ+レストラン」のように複数種類のアイテムを一度に検索できるようにしてもよい。ここでは、ユーザが検索対象として「ホテル」を選択した場合の処理を説明する。
【0041】
例えば、ユーザは、入力フォームF10に、宿泊地などのキーワードを入力する。宿泊地は、キーワードで入力されなくてもよく、予め用意された地域リストの中から選択されるようにしてもよい。また例えば、入力フォームF11には、チェックイン日が入力され、入力フォームF12には、チェックアウト日が入力される。また例えば、入力フォームF13には、利用人数が入力される。ユーザが、これらの検索条件を入力してボタンB14を選択すると、検索が実行される。なお、ユーザは、入力フォームF10~F14の全てに検索条件を入力する必要はなく、一部の入力フォームに対してのみ検索条件を入力してもよい。
【0042】
図3は、検索が実行される様子を示す図である。
図3のトップ画面G1A,G1Bに示すように、例えば、ユーザが、入力フォームF10~F13に検索条件を入力し、ボタンB14を選択すると、検索条件を満たすホテルが検索される。
図3のトップ画面G1Bの例であれば、入力フォームF10に入力された「沖縄」にあるホテルのうち、入力フォームF11,F12に入力された「2018年7月1日」~「2018年7月5日」の利用日において、入力フォームF13に入力された「2人」用の部屋に空きがあるホテルが検索される。なお、検索時において、在庫の有無は特に判定されなくてもよい。
【0043】
図3に示すように、ホテルが検索されると、検索結果を示す検索結果画面G2が表示部15に表示される。例えば、検索結果画面G2の入力フォームF20には、検索で用いられた検索条件が表示される。ユーザは、所望のホテルが見つからなかった場合には、入力フォームF20から検索条件を変更し、再度検索を実行する。
【0044】
また例えば、検索結果画面G2のリストL21には、検索でヒットしたホテルが表示される。リストL21では、検索でヒットしたホテルが選択可能に表示され、リストL21をスクロールしたり、所定のページ送り操作をしたりすることで、画面に表示しきれないホテルを表示させることもできる。例えば、リストL21には、検索でヒットしたホテルの名称、画像(
図3では省略する)、ユーザの評価、及び価格帯といった情報が表示される。
【0045】
図3に示すように、ユーザがリストL21に表示されたホテルを選択すると、当該ホテルの詳細を示すページであるアイテム画面G3が表示部15に表示される。
図3では、ユーザがリストL21内の「ホテルA」を選択し、「ホテルA」のページを示すアイテム画面G3が表示部15に表示される場合を示している。例えば、アイテム画面G3には、「ホテルA」の名前、評価、画像、部屋の名前、及び料金が表示される。
【0046】
アイテム画面G3からホテルの予約をできるようにしてもよいが、本実施形態では、ユーザは、旅行かごにホテルを追加し、旅程を組み立てた後にまとめて予約するようになっている。旅行かごは、旅程に組み込まれたアイテムのリストであり、検討中のアイテムのリストである。別の言い方をすれば、旅行かごは、旅程を確定する前に(アイテムの予約を完了する前に)作成された仮の旅程である。旅行かごは、電子商取引におけるショッピングカートと似た概念である。ユーザは、複数種類のアイテムを旅行かごに追加して自分好みの旅程を計画し、これら複数種類のアイテムを予約する。
【0047】
例えば、アイテム画面G3には、表示中のホテルを旅行かごに追加するためのボタンB30が表示される。ユーザがボタンB30を選択すると、アイテム画面G3に表示中の「ホテルA」が旅行かごに追加され、旅行かご画面が表示部15に表示される。なお、ユーザは、検索条件で入力した時間を変更せずに、旅行かごにアイテムを追加してもよいし、検索条件で入力した時間を変更したうえで、旅行かごにアイテムを追加してもよい。即ち、ユーザは、検索時に入力した「ホテルA」の利用日を変更せずに旅行かごに追加してもよいし、利用日を変更したうえで旅行かごに追加してもよい。
【0048】
図4は、旅行かご画面の一例を示す図である。
図4に示すように、旅行かご画面G4の表示領域A40には、旅行かごの中身が表示される。旅行かごに複数のアイテムが追加された場合には、表示領域A40には、複数のアイテムが所定の順序で並べられる。アイテムの順序は、任意の条件で決定されるようにすればよく、例えば、旅行かごへの追加順であってもよいし、アイテムの利用時間の時系列順であってもよい。
【0049】
図4の例では、旅行かごには、ユーザがアイテム画面G3から選択した「ホテルA」が追加されている。このため、表示領域A40には、「ホテルA」に関する情報(例えば、ホテル名、住所、電話番号等)、ユーザが指定した利用日(チェックイン日・チェックアウト日)、及びユーザが指定した人数が表示される。その他にも、ユーザが部屋のタイプやオプション等を指定した場合には、指定内容が表示領域A40に表示されてもよい。
【0050】
ユーザがボタンB400を選択した場合、旅行かごの中にあるアイテムを予約することができる。旅行かごの中に複数のアイテムがある場合、これら複数のアイテムの予約処理が一度にまとめて実行されてもよいし、個々のアイテムごとに個別に予約処理が実行されてもよい。なお、ユーザがボタンB401を選択した場合、旅行かごのアイテムを削除することができる。
【0051】
本実施形態では、旅行かごの中にあるアイテムの時間及び場所に基づいて、他の種類のアイテムが検索され、旅行かご画面G4の表示領域A41A~A41Cにレコメンドされる。以降では、表示領域A41A~A41Cを特に区別する必要のないときは、単に表示領域A41と記載する。同様に、後述するボタンA410A~A410Cを特に区別する必要のないときは、単にボタンA410と記載する。
【0052】
例えば、表示領域A41Aに示すように、ユーザが旅行かごに入れた「ホテルA」の利用日及び場所に基づいて、「ホテルA」がある地域の空港までの往復航空券が検索され、当該往復航空券が表示領域A41にレコメンドされる。なお、出発地は、ユーザが予め入力してもよいし、ユーザの過去の予約履歴から取得されてもよい。他にも例えば、後述する変形例のように、ユーザ登録情報や通信環境等から出発地が取得されてもよい。ユーザは、表示領域A41Aに表示されたボタンA410Aを選択することで、レコメンドされた往復航空券を旅行かごに追加することができる。
【0053】
また例えば、表示領域A41Bに示すように、ユーザが旅行かごに入れた「ホテルA」の利用日及び場所に基づいて、「ホテルA」がある地域のレンタカー会社が提供するレンタカーが検索され、当該レンタカーが表示領域A41Bにレコメンドされる。ユーザは、表示領域A41Bに表示されたボタンA410Bを選択することで、レコメンドされたレンタカーを旅行かごに追加することができる。
【0054】
また例えば、表示領域A41Cに示すように、ユーザが旅行かごに入れた「ホテルA」の利用日及び場所に基づいて、「ホテルA」がある地域のアクティビティが検索され、当該アクティビティが表示領域A41Cに表示される。ユーザは、表示領域A41Cに表示されたボタンA410Cを選択することで、レコメンドされたレンタカーを旅行かごに追加することができる。
【0055】
図5は、レコメンドされたアイテムが旅行かごに追加される様子を示す図である。なお、
図5では、特に参照する必要のない符号は省略する。
図5の旅行かご画面G4Aにおいて、例えば、ユーザが表示領域A41AのボタンA410Aを選択すると、旅行かご画面G4Bに示すように、レコメンドされた往復航空券が旅行かごに追加される。続いて、ユーザが表示領域A41BのボタンA410Bを選択すると、旅行かご画面G4Cに示すように、レコメンドされたレンタカーが旅行かごに追加される。
【0056】
更に、ユーザが表示領域A41CのボタンA410Cを選択すると、旅行かご画面G4Dに示すように、レコメンドされたアクティビティが旅行かごに追加される。このように、ユーザは、表示領域A41においてレコメンドされたアイテムを次々と選択し、旅行かごに次々とアイテムを追加することができる。
【0057】
なお、レコメンドされたアイテムが旅行かごに追加された場合、表示領域A41においては、元々レコメンドされていたアイテムが保持されてもよいし、最新の旅行かごの内容に基づいて、レコメンドされるアイテムが更新されてもよい。更に、元々レコメンドされていたアイテムが保持されつつ、新たなアイテムが追加でレコメンドされてもよい。
【0058】
また、
図4-
図5では、複数種類のアイテムがレコメンドされる場合を説明したが、レコメンドされるアイテムは、1種類だけであってもよい。更に、同じ種類のアイテムが複数個レコメンドされてもよい。例えば、往復航空券とともに片道航空券がレコメンドされてもよいし、複数の時間帯の各々の航空券がレコメンドされてもよい。また例えば、「ホテルA」がある地域の複数のレンタカー会社がレコメンドされてもよい。また例えば、「ホテルA」がある地域における複数のアクティビティがレコメンドされてもよい。
【0059】
また、
図4-
図5では、航空券、レンタカー、及びアクティビティがレコメンドされる場合を説明したが、任意の種類のアイテムをレコメンドしてよく、例えば、「ホテルA」の利用日及び場所に基づいて、「ホテルA」がある地域のレストランが検索され、当該レストランがレコメンドされてもよい。また例えば、「ホテルA」の利用日及び場所に基づいて、「ホテルA」がある地域の観光施設が検索され、当該観光施設がレコメンドされてもよい。
【0060】
また、
図4-
図5では、ユーザが旅行かごにホテルを追加した場合のレコメンドについて説明したが、ユーザが旅行かごに航空券を追加した場合には、航空券の目的地と到着時間に基づいて、ホテル、レンタカー、及びアクティビティが検索されてレコメンドされてもよい。また例えば、ユーザが旅行かごにレンタカーを追加した場合には、レンタカー会社の地域と利用時間に基づいて、ホテル、航空券、及びアクティビティが検索されてレコメンドされてもよい。また例えば、ユーザが旅行かごにアクティビティを追加した場合には、アクティビティの地域と利用時間に基づいて、ホテル、航空券、及びレンタカーが検索されてレコメンドされてもよい。
【0061】
また、
図4-
図5では、旅行かご画面G4においてレコメンドが行われる場合を説明したが、レコメンドは、任意の画面で行われるようにすればよく、例えば、トップ画面G1、検索結果画面G2、又はアイテム画面G3で行われてもよいし、その他の画面で行われてもよい。他にも例えば、レコメンドは、電子メール、メッセージアプリ、SNS、又はプッシュ通知といった任意の手段で行われるようにしてもよい。
【0062】
以上のように、本実施形態の旅行計画システムSは、ユーザが旅行かごに追加したアイテムの時間及び場所に基づいて、他の種類のアイテムを検索し、旅行かご画面G4の表示領域A41にレコメンドする。そして、旅行計画システムSは、表示領域A41のボタンB410が選択された場合に、レコメンドしたアイテムを旅行かごに追加し、ユーザによる旅程の作成を支援する。以降、この技術の詳細を説明する。
【0063】
[3.旅行計画システムにおいて実現される機能]
図6は、本実施形態の旅行計画システムSで実現される機能の一例を示す機能ブロック図である。
【0064】
[3-1.データベースサーバで実現される機能]
図6に示すように、データベースサーバ40では、データ記憶部400が実現される。データ記憶部400は、記憶手段の一例である。データ記憶部400は、記憶部42を主として実現される。データ記憶部400は、検索やレコメンドに必要なデータを記憶する。ここでは、データ記憶部400が記憶するデータの一例として、アイテムデータベースDB1、ユーザデータベースDB2、及びレコメンドデータベースDB3を説明する。これら各データベースの内容は、ウェブサーバ20又は分析サーバ30からの要求に応じて適宜提供される。
【0065】
図7は、アイテムデータベースDB1のデータ格納例を示す図である。アイテムデータベースDB1は、アイテムに関する各種情報が格納されたデータベースである。
図7に示すように、例えば、アイテムデータベースDB1には、アイテムを一意に識別するアイテムID、アイテムの種類、及びアイテムの基本情報が格納される。なお、
図7では、アイテムの種類をテキストで示しているが、アイテムの種類を一意に識別する種類IDが格納されてもよい。
【0066】
基本情報は、アイテムの内容を示す情報が格納され、検索時のインデックスとして用いられる。例えば、アイテムが宿泊施設であれば、基本情報は、宿泊施設の名前、住所、チェックイン及びチェックアウトの時間、連絡先、宿泊施設の画像、部屋等の施設情報、及び宿泊料金等が格納される。また例えば、アイテムが交通手段であれば、基本情報は、交通手段の名前、出発地、目的地、出発時間、到着時間、座席情報、及び運賃等が格納される。また例えば、アイテムがレンタカーであれば、基本情報は、レンタカー会社名、住所、連絡先、レンタカーの画像、車種、及び利用金額等が格納される。
【0067】
また例えば、アイテムがアクティビティであれば、基本情報は、ツアー会社名、アクティビティの場所、集合時間、解散時間、アクティビティの内容、及び利用料金が格納される。また例えば、アイテムがレストランであれば、基本情報は、レストラン名、住所、連絡先、レストランの画像、利用可能時間、座席情報、及び料金等が格納される。また例えば、アイテムが観光施設であれば、基本情報は、観光施設の場所、連絡先、施設の画像、施設情報、及び料金等が格納される。
【0068】
なお、本実施形態では、説明の簡略化のために、全アイテムが1つのアイテムデータベースDB1に集約されている場合を説明するが、複数のデータベースに分けられていてもよい。例えば、アイテムの種類ごとにデータベースが分けられていてもよい。また例えば、アイテムの提供者ごとに、データベースが分けられており、宿泊施設、交通手段、レンタカー、アクティビティ、レストラン、又は観光施設の運営会社が管理する外部コンピュータにデータベースが記憶されていてもよい。この場合、旅行計画システムSは、当該外部コンピュータにデータベースの内容を問い合わせてもよい。
【0069】
図8は、ユーザデータベースDB2のデータ格納例を示す図である。ユーザデータベースDB2は、ユーザに関する各種情報を格納するためのデータベースである。
図8に示すように、例えば、ユーザデータベースDB2には、ユーザを一意に識別するユーザID、ユーザ登録情報、旅行かご情報、及び予約情報が格納される。
【0070】
ユーザ登録情報は、ユーザにより登録された基本情報であり、例えば、氏名、住所、及び連絡先といった個人情報が格納されてもよいし、ユーザアカウントやパスワードといった認証情報が格納されてもよい。他にも例えば、ユーザの好みの旅行先等の嗜好情報が格納されていてもよい。
【0071】
旅行かご情報は、旅行かごの内容を示す情報であり、例えば、旅行かごに投入されたレコード(アイテムIDと指定内容のセット)を識別する旅行かごID、旅行かごに追加されたアイテムのアイテムID、及びユーザにより指定された指定内容が格納される。指定内容は、アイテムの利用条件であり、例えば、時間、人数、又はオプションの有無等が指定される。なお、本実施形態では、説明の簡略化のために、ユーザに旅行かごが1つだけ割り当てられる場合を説明するが、後述する変形例のように、ユーザに複数の旅行かごが割り当てられ、複数の旅程を並列して作成できるようにしてもよい。
【0072】
予約情報は、予約済みのアイテムの予約内容を示す情報であり、予約の履歴を示す情報である。例えば、予約情報には、予約を一意に識別する予約ID、予約されたアイテムのアイテムID、及び予約内容が格納される。予約内容は、アイテムの予約条件であり、例えば、時間、人数、又はオプションの有無等である。
【0073】
なお、ユーザデータベースDB2に格納される情報は、上記の例に限られない。例えば、ユーザデータベースDB2には、アイテムの検索履歴又は閲覧履歴が格納されてもよい。また例えば、ユーザデータベースDB2には、ウェブサイトの検索履歴又は閲覧履歴が格納されていてもよい。また例えば、旅行計画システムSが電子商取引システム等の他のシステムと提携する場合には、ユーザデータベースDB2には、当該他のシステムの利用履歴が格納されてもよい。
【0074】
図9は、レコメンドデータベースDB3のデータ格納例を示す図である。レコメンドデータベースDB3は、ユーザに対するレコメンド内容を格納するためのデータベースである。
図9に示すように、レコメンドデータベースDB3には、ユーザID及びレコメンド情報が格納される。
【0075】
レコメンド情報は、ユーザに対するレコメンドの内容を示す情報であり、分析サーバ30により決定された内容が格納される。例えば、レコメンド情報には、レコメンドすべきアイテムのアイテムIDとレコメンド内容とを含む。レコメンド内容は、レコメンドすべきアイテムの内容であり、例えば、時間、人数、又はオプションの有無等である。
【0076】
なお、データ記憶部400に記憶されるデータは、上記の例に限られない。例えば、データ記憶部400は、
図2-
図4に示す各画面を表示させるための画像データを記憶してもよい。また例えば、データ記憶部400は、各アイテムの在庫を示す在庫データベースを記憶してもよい。在庫データベースには、各アイテムの時間ごとの在庫が格納される。
【0077】
[3-2.ウェブサーバで実現される機能]
図6に示すように、ウェブサーバ20では、第1検索部200及び受付部201が実現される。第1検索部200及び受付部201は、それぞれ第1検索手段及び受付手段の一例である。
【0078】
[第1検索部]
第1検索部200は、制御部21を主として実現される。第1検索部200は、ユーザにより入力された時間及び場所に基づいて、旅程に組み込むアイテムを検索する。時間の意味は、先述した通りである。場所は、地域名、都市名、住所、郵便番号、又は緯度経度情報といった種々の情報を利用して入力されるようにすればよい。
【0079】
第1検索部200は、ユーザ端末10からユーザにより入力された時間及び場所を取得し、当該時間及び場所をクエリとし、アイテムデータベースDB1に格納された基本情報をインデックスとして、アイテムを検索する。検索方法自体は、種々の手法を適用可能であり、クエリとインデックスの一致判定が行われてもよいし、あいまい検索が利用されてもよい。
【0080】
例えば、第1検索部200は、ユーザにより入力された時間で予約を受け付けているアイテムを検索してもよい。また例えば、第1検索部200は、ユーザにより入力された時間で在庫があるアイテムを検索してもよい。また例えば、第1検索部200は、ユーザにより入力された場所と一致する場所のアイテムを検索してもよい。また例えば、第1検索部200は、ユーザにより入力された場所と同じ地域のアイテムを検索してもよい。また例えば、第1検索部200は、ユーザにより入力された場所との距離が閾値未満であるアイテムを検索してもよい。
【0081】
第1検索部200は、アイテムデータベースDB1を参照し、検索でヒットしたアイテムの基本情報を取得する。第1検索部200は、取得した基本情報に基づいて、検索結果画面G2のリストL21の表示内容を決定し、検索結果画面G2の表示データをユーザ端末10に送信する。ユーザ端末10においては、当該表示データが受信されると、検索結果画面G2が表示部15に表示される。
【0082】
[受付部]
受付部201は、制御部21を主として実現される。受付部201は、第1検索部200の検索結果の中から、ユーザによる選択を受け付ける。受付部201は、検索結果画面G2の中からユーザによる選択を受け付ける。本実施形態では、受付部201がウェブサーバ20において実現されるので、受付部201は、ユーザ端末10から、ユーザにより選択されたアイテムのアイテムIDを受信することによって、ユーザによるアイテムの選択を受け付ける。
【0083】
本実施形態では、ユーザにより選択されたアイテムは、旅行かごに追加されるので、受付部201は、ユーザにより選択されたアイテムのアイテムIDと、ユーザにより指定された指定内容と、をユーザデータベースDB2に格納する。なお、一度に選択可能なアイテムの数は、任意であってよく、例えば、1つだけであってもよいし、2つ以上であってもよい。
【0084】
[3-3.分析サーバで実現される機能]
図6に示すように、分析サーバ30では、第2検索部300及び提示部301が実現される。第2検索部300及び提示部301は、それぞれ第2検索手段及び提示手段の一例である。
【0085】
[第2検索部]
第2検索部300は、制御部31を主として実現される。第2検索部300は、ユーザにより選択されたアイテムの時間及び場所に基づいて、他の種類のアイテムを検索する。ユーザにより選択されたアイテムとは、受付部201が選択を受け付けたアイテムであり、例えば、旅行かごに追加されたアイテムであってもよいし、予約が完了したアイテムであってもよい。本実施形態では、旅行かごに追加されたアイテムが、ユーザにより選択されたアイテムに相当する場合を説明する。
【0086】
例えば、第2検索部300は、ユーザデータベースDB2の旅行かご情報を参照し、ユーザにより選択されたアイテムの時間及び場所を取得する。なお、予約が完了したアイテムが、ユーザにより選択されたアイテムに相当する場合には、第2検索部300は、ユーザデータベースDB2の予約情報を参照し、ユーザにより選択されたアイテムの時間及び場所を取得する。他にも例えば、ユーザデータベースDB2にユーザの検索条件を保持しておき、第2検索部300は、ユーザの検索条件を参照することで、ユーザにより選択されたアイテムの時間及び場所を取得してもよい。
【0087】
第2検索部300は、上記取得した時間及び場所をクエリとし、アイテムデータベースDB1に格納された基本情報をインデックスとして、アイテムを検索する。ただし、第2検索部300は、全ての種類のアイテムを検索対象とするのではなく、ユーザにより選択されたアイテムと同じ種類のアイテムは検索対象から除外し、他の種類のアイテムを検索対象とする。このため、第2検索部300は、アイテムデータベースDB1のうち、ユーザにより選択されたアイテムの種類以外のアイテム(ユーザにより選択されたアイテムとは異なる種類のアイテム)の基本情報をインデックスとして検索を実行する。なお、第2検索部300は、アイテムデータベースDB1から各アイテムの種類を取得すればよい。
【0088】
例えば、第2検索部300は、ユーザにより選択されたアイテムの時間で予約を受け付けているアイテムを検索してもよい。また例えば、第2検索部300は、ユーザにより選択されたアイテムの時間で在庫があるアイテムを検索してもよい。また例えば、第2検索部300は、ユーザにより選択されたアイテムの場所と一致する場所のアイテムを検索してもよい。また例えば、第2検索部300は、ユーザにより選択されたアイテムの場所と同じ地域のアイテムを検索してもよい。また例えば、第2検索部300は、ユーザにより選択されたアイテムの場所との距離が閾値未満であるアイテムを検索してもよい。
【0089】
第2検索部300は、アイテムデータベースDB1を参照し、検索でヒットしたアイテムの基本情報を取得する。第2検索部300は、検索でヒットしたアイテムのアイテムIDと、当該アイテムのレコメンド内容と、を含むレコメンド情報を、レコメンドデータベースDB3に格納する。レコメンド内容は、クエリとした時間が格納されてもよいし、クエリとした場所が格納されてもよい。レコメンド情報は、所定のタイミングで参照され、旅行かご画面G4の表示領域A41において、第2検索部300が検索したアイテムがレコメンドされる。
【0090】
[提示部]
提示部301は、制御部31を主として実現される。提示部301は、第2検索部300により検索されたアイテムを、選択可能に提示する。選択可能に提示とは、アイテムを選択肢として提示することである。別の言い方をすれば、選択可能に提示とは、アイテムの選択を受け付け可能な状態で提示することである。提示とは、アイテムを選択するための情報(例えば、画像又はリンク)をユーザ端末10に表示させること、又は、アイテムを選択するための情報をユーザ端末10に送信することである。
【0091】
本実施形態では、提示部301は、第2検索部300により検索されたアイテムを、旅行かご画面G4において提示する場合を説明するが、アイテムの提示方法は、任意の方法を適用可能である。例えば、提示部301は、電子メール、メッセージアプリ、SNS、又はプッシュ通知によって、第2検索部300により検索されたアイテムを提示してもよい。なお、提示部301は、第2検索部300により検索が実行されたことに応じてアイテムを提示してもよいし、ユーザ端末10から所定の要求を受け付けた場合にアイテムを提示してもよい。
【0092】
[3-4.ユーザ端末で実現される機能]
図6に示すように、ユーザ端末10では、データ記憶部100、受付部101、及び表示制御部102が実現される。データ記憶部100、受付部101、及び表示制御部102は、それぞれ記憶手段、受付手段、及び表示制御手段の一例である。
【0093】
[データ記憶部]
データ記憶部100は、記憶部12を主として実現される。データ記憶部100は、ウェブサーバ20から受信したデータを記憶する。例えば、データ記憶部100は、ウェブサーバ20から受信したトップ画面G1、検索結果画面G2、アイテム画面G3、及び旅行かご画面G4の各々の表示データを記憶してもよい。また例えば、データ記憶部100は、ユーザID、入力された検索条件、及び旅行かごの中身を記憶してもよい。
【0094】
[受付部]
受付部101は、制御部11を主として実現される。受付部101は、操作部14の検出信号に基づいて、ユーザの操作を受け付ける。受付部101がユーザの操作を受け付けると、ユーザ端末10は、当該操作の内容を示す情報をウェブサーバ20に送信する。例えば、受付部101が操作を受け付けると、ユーザ端末10は、何れの操作が行われたかを識別する情報をウェブサーバ20に送信する。
【0095】
[表示制御部]
表示制御部102は、制御部11を主として実現される。表示制御部102は、ウェブサーバ20から受信した表示データに基づいて、各種画面を表示させる。例えば、表示制御部102は、トップ画面G1、検索結果画面G2、アイテム画面G3、及び旅行かご画面G4の各々を表示させる。例えば、ウェブブラウザを利用して各画面を表示させる場合には、表示データは、HTMLデータであり、ユーザ端末10のプログラム(例えば、旅行予約アプリ)を利用して各画面を表示させる場合には、表示データは、フレームにはめ込む画像やテキスト情報であってもよい。
【0096】
[4.本実施形態において実行される処理]
図10-
図11は、旅行計画システムSにおいて実行される処理の一例を示すフロー図である。
図10-
図11に示す処理は、制御部11,21,31,41が、それぞれ記憶部12,22,32,42に記憶されたプログラムに従って動作することによって実行される。下記に説明する処理は、
図6に示す機能ブロックにより実行される処理の一例である。なお、ここでは、ユーザ端末10のウェブブラウザ上で各種画面が表示され、その際の通信プロトコルとしてHTTPが利用される場合を説明する。
【0097】
図10に示すように、まず、ユーザ端末10において、トップ画面G1のURLが選択された場合に、制御部11は、ウェブサーバ20に対し、トップ画面G1を表示させるためのHTTPリクエストを送信する(S1)。S1においては、制御部11は、所定のパラメータを含むHTTPリクエストを送信する。当該HTTPリクエストは、トップ画面G1の表示要求であり、パラメータには、ユーザIDが含まれるものとする。
【0098】
ウェブサーバ20においては、HTTPリクエストを受信すると、制御部21は、ユーザ端末10に対し、トップ画面G1の表示データを含むHTTPレスポンスを送信する(S2)。表示データは、任意のデータ形式であってよく、ここでは、HTMLデータとする。なお、本実施形態では、説明の簡略化のために、トップ画面G1ではレコメンドが行われない場合を説明するが、トップ画面G1でレコメンドが行われる場合には、S2の時点で後述するレコメンド処理(S19の処理)が実行されてもよい。この点は、後述する検索結果画面G2又はアイテム画面G3を表示させる場合も同様であり、検索結果画面G2又はアイテム画面G3でレコメンドが行われる場合には、これらの画面を表示させる時点でレコメンド処理が実行されてもよい。
【0099】
ユーザ端末10においては、HTTPレスポンスを受信すると、制御部11は、トップ画面G1の表示データに基づいて、トップ画面G1を表示部15に表示させる(S3)。制御部11は、操作部14の検出信号に基づいて、ユーザの操作を特定する(S4)。ここでは、入力フォームF10~F13に検索条件を入力する操作、又は、ボタンB14を選択する操作が行われる場合を説明する。
【0100】
入力フォームF10~F13に検索条件が入力された場合(S4;検索条件入力)、制御部11は、ユーザが入力した時間及び場所等の検索条件を、入力フォームF10~F13に表示させる(S5)。ユーザが入力した検索条件は、記憶部12に保持される。なお、ユーザがトップ画面G1から検索対象のアイテムの種類を指定した場合には、当該種類を識別する情報も記憶部12に保持される。
【0101】
一方、ボタンB14が選択された場合(S4;検索実行)、制御部11は、ウェブサーバ20に対し、検索結果画面G2を表示させるためのHTTPリクエストを送信する(S6)。当該HTTPリクエストは、検索の実行要求であり、パラメータには、ユーザID、検索対象となるアイテムの種類、及び入力フォームF10~F13に入力された検索条件を含む。
【0102】
ウェブサーバ20においては、HTTPリクエストを受信すると、制御部21は、データベースサーバ40に記憶されたアイテムデータベースDB1に基づいて、アイテムを検索する(S7)。S7においては、制御部21は、アイテムデータベースDB1のうち、検索対象となるアイテムの種類のレコードを参照し、検索条件をクエリとし、検索対象となるアイテムの種類のアイテムの基本情報をインデックスとして、検索を実行する。
【0103】
制御部21は、S7における検索結果に基づいて、ユーザ端末10に対し、検索結果画面G2の表示データを含むHTTPレスポンスを送信する(S8)。S8においては、制御部21は、アイテムデータベースDB1を参照し、S7における検索でヒットしたアイテムの基本情報を取得し、検索結果画面G2の表示データを生成する。なお、当該表示データには、検索でヒットしたアイテムのアイテムIDが含まれているものとする。これにより、例えば、ユーザがリストL21内のアイテムを選択した場合に、どのアイテムが選択されたかを特定可能となる。
【0104】
ユーザ端末10においては、HTTPレスポンスを受信すると、制御部11は、検索結果画面G2の表示データに基づいて、検索結果画面G2を表示部15に表示させる(S9)。制御部11は、操作部14の検出信号に基づいて、ユーザの操作を特定する(S10)。ここでは、トップ画面G1に戻る操作、又は、リストL21内のアイテムを選択する操作が行われる場合を説明する。
【0105】
トップ画面G1に戻る操作が行われた場合(S10;戻る)、S3の処理に戻る。一方、リスト内L21のアイテムを選択する操作が行われた場合(S10;アイテム選択)、制御部11は、ウェブサーバ20に対し、アイテム画面G3を表示させるためのHTTPリクエストを送信する(S11)。当該HTTPリクエストは、アイテム画面G3の表示要求であり、パラメータには、ユーザIDと、ユーザが選択したアイテムのアイテムIDと、が含まれる。
【0106】
ウェブサーバ20においては、HTTPリクエストを受信すると、制御部21は、データベースサーバ40に記憶されたアイテムデータベースDB1に基づいて、ユーザ端末10に対し、アイテム画面G3の表示データを含むHTTPレスポンスを送信する(S12)。S12においては、制御部21は、アイテムデータベースDB1のうち、ユーザが選択したアイテムのアイテムIDが格納されたレコードを参照し、アイテム画面G3の表示データを生成する。
【0107】
ユーザ端末10においては、HTTPレスポンスを受信すると、制御部11は、アイテム画面G3を表示部15に表示させる(S13)。制御部11は、操作部14の検出信号に基づいて、ユーザの操作を特定する(S14)。ここでは、検索結果画面G2に戻る操作、又は、ボタンB30を選択する操作について説明する。
【0108】
検索結果画面G2に戻る操作が行われた場合(S14;戻る)、S9の処理に戻る。一方、ボタンB30を選択する操作が行われた場合(S14;アイテム追加)、制御部11は、ウェブサーバ20に対し、旅行かご画面G4を表示させるためのHTTPリクエストを送信する(S15)。当該HTTPリクエストは、旅行かご画面G4の表示要求であり、旅行かごへのアイテムの追加要求である。当該HTTPリクエストのパラメータには、ユーザID、旅行かごに投入されたレコード(アイテムIDと指定内容のセット)を特定する旅行かごID、ユーザが旅行かごに追加するアイテムのアイテムID、及び指定内容が含まれる。
【0109】
ウェブサーバ20においては、HTTPリクエストを受信すると、制御部21は、データベースサーバ40に記憶されたユーザデータベースDB2に基づいて、ユーザが選択したアイテムを旅行かごに追加する(S16)。S16においては、制御部21は、追加要求をしたユーザのユーザIDが格納されたレコードの旅行かご情報に、ユーザが選択したアイテムのアイテムIDと指定内容とを格納する。
【0110】
制御部21は、アイテムデータベースDB1に基づいて、ユーザ端末10に対し、旅行かご画面G4の表示データを含むHTTPレスポンスを送信する(S17)。S17においては、制御部21は、旅行かご画面G4の表示データを生成する。旅行かご画面G4の表示データには、レコメンドデータベースDB3からレコメンド内容を取得する命令が記載されたJavaスクリプト(登録商標)が含まれているものとする。ユーザ端末10は、HTTPレスポンスの受信後の任意のタイミングで、当該Javaスクリプト(登録商標)を実行し、レコメンドデータベースDB3を参照する。
【0111】
図11に移り、制御部21は、分析サーバ30とデータベースサーバ40に対し、レコメンド処理を依頼する(S18)。S18においては、制御部21は、ユーザ端末10から受信したHTTPリクエストのパラメータを送信し、レコメンド処理の実行を依頼する。レコメンド処理は、レコメンドすべきアイテム及び内容を決定するための処理である。
【0112】
分析サーバ30及びデータベースサーバ40の各々は、ウェブサーバ20からレコメンド処理の依頼を受信すると、レコメンド処理を実行する(S19)。S19においては、分析サーバ30とデータベースサーバ40との間で、ユーザが旅行かごに追加したアイテムの時間及び場所に基づいて、他の種類のアイテムが検索される。分析サーバ30の制御部31は、アイテムデータベースDB1のうち、旅行かごに追加されたアイテムの種類とは異なる種類のデータを参照し、旅行かごに追加されたアイテムの時間と場所をクエリにして検索を実行する。
【0113】
分析サーバ30においては、制御部31は、レコメンド処理の実行結果に基づいて、レコメンドデータベースDB3にレコメンド情報を格納する(S20)。S20においては、制御部31は、ユーザIDに関連付けて、レコメンド処理で検索されたアイテムのアイテムIDとレコメンド内容を格納する。
【0114】
ユーザ端末10においては、HTTPレスポンスを受信すると、制御部11は、Javaスクリプト(登録商標)に基づいて、レコメンド情報を取得する(S21)。S21においては、制御部11は、分析サーバ30又はデータベースサーバ40に対し、レコメンド情報の取得要求を送信する。分析サーバ30又はデータベースサーバ40は、取得要求を受信すると、レコメンドデータベースDB3を参照し、取得要求を送信したユーザのユーザIDが格納されたレコードのレコメンド情報を送信する。なお、レコメンド情報の取得は、Javaスクリプト(登録商標)以外の任意のスクリプトが実行されることで実行されてもよい。
【0115】
制御部11は、S21において取得したレコメンド情報に基づいて、旅行かご画面G4を表示部15に表示させる(S22)。S22においては、制御部11は、ウェブサーバ20から受信したHTTPレスポンスに含まれる表示データに基づいて、旅行かご画面G4を表示部15に表示させる。そして、制御部11は、S21において取得したレコメンド情報に基づいて、表示領域A41内にレコメンドされたアイテムを表示させる。
【0116】
制御部11は、操作部14の検出信号に基づいて、ユーザの操作を特定する(S23)。ここでは、アイテム画面G3に戻る操作、ボタンB400を選択する操作、ボタンB401を選択する操作、又はボタンB410を選択する操作について説明する。
【0117】
アイテム画面G3に戻る操作が行われた場合(S23;戻る)、S13の処理に戻る。一方、ボタンB410を選択する操作が行われた場合(S23;アイテム追加)、制御部11は、ウェブサーバ20に対し、レコメンドされたアイテムを旅行かごに追加するためのHTTPリクエストを送信する(S24)。S24においては、制御部11は、ユーザID、アイテムが追加される旅行かごの旅行かごID、及びユーザが旅行かごに追加するアイテムのアイテムIDを含むパラメータとともに、HTTPリクエストを送信する。
【0118】
ウェブサーバ20においては、HTTPリクエストを受信すると、制御部21は、データベースサーバ40に記憶されたユーザデータベースDB2に基づいて、ユーザが選択したアイテムを旅行かごに追加し(S25)、S17の処理に移行する。S24においては、制御部21は、追加要求をしたユーザのユーザIDが格納されたレコードの旅行かご情報に、ユーザが選択したアイテムのアイテムIDと指定内容とを格納する。
【0119】
一方、ボタンB401を選択する操作が行われた場合(S23;アイテム削除)、制御部11は、ウェブサーバ20に対し、旅行かごの中にあるアイテムを削除するためのHTTPリクエストを送信する(S26)。S26においては、制御部11は、ユーザID、アイテムが削除される旅行かごの旅行かごID、及びユーザが旅行かごから削除するアイテムのアイテムIDを含むパラメータとともに、HTTPリクエストを送信する。
【0120】
ウェブサーバ20においては、HTTPリクエストを受信すると、制御部21は、データベースサーバ40に記憶されたユーザデータベースDB2に基づいて、ユーザが選択したアイテムを旅行かごから削除し(S27)、S17の処理に移行する。S27においては、制御部21は、削除要求をしたユーザのユーザIDが格納されたレコードの旅行かご情報から、ユーザが選択したアイテムのアイテムIDと指定内容とを削除する。
【0121】
一方、ボタンB400を選択する操作が行われた場合(S23;予約)、制御部11は、ウェブサーバ20に対し、旅行かごに追加されたアイテムを予約するためのHTTPリクエストを送信する(S28)。S28においては、制御部11は、ユーザIDと、予約する旅行かごの旅行かごIDと、を含むパラメータとともに、HTTPリクエストを送信する。以降、ユーザ端末10とウェブサーバ20との間で予約処理が実行され、本処理は終了する。
【0122】
旅行計画システムSによれば、ユーザにより選択されたアイテムの時間及び場所に基づいて検索された他の種類のアイテムが、旅行かご画面G4の表示領域A41においてレコメンドされ、他の種類のアイテムをいちいち探す手間がなくなるので、複数種類のアイテムが組み込まれる旅程を作成する手間を軽減することができる。ユーザは、複数種類のアイテムを旅程に組み込む場合であっても、レコメンドされたアイテムを次々と選択することで容易に旅程を作成することができる。また、ユーザが他の種類のアイテムを探すために検索条件を入力して検索を実行し、アイテム画面G3を表示させて旅行かごに入れるといった余計な処理を省略することができ、旅行計画システムSの処理負荷を軽減することもできる。
【0123】
[5.変形例]
なお、本発明は、以上に説明した実施の形態に限定されるものではない。本発明の趣旨を逸脱しない範囲で、適宜変更可能である。
【0124】
図12は、変形例の機能ブロック図である。
図12に示すように、以降説明する変形例では、実施形態で説明した機能に加え、ウェブサーバ20において、出発地取得部202が実現され、分析サーバ30において、出発地取得部302と特定部303が実現される。ウェブサーバ20の出発地取得部202は、制御部21を主として実現され、分析サーバ30の出発地取得部302と特定部303は、制御部31を主として実現される。
【0125】
(1)例えば、ユーザがホテルやアクティビティ等の現地アイテムを旅行かごに追加した場合、ユーザは、その後に、航空券等の交通手段を検索することが多い。この場合、ユーザは、ホテルのチェックイン時間やアクティビティの集合時間に間に合うような交通手段を検索する必要があるが、同じ地域の現地アイテムを予約した他のユーザが予約した交通手段をレコメンドすることで、ユーザの手間を省くようにしてもよい。
【0126】
現地アイテムとは、現地で利用されるアイテムである。現地は、目的地、旅行先、又は行き先である。例えば、現地アイテムは、宿泊施設、レンタカー、アクティビティ、レストラン、又は観光施設である。別の言い方をすれば、現地アイテムは、交通手段以外のアイテムである。なお、本変形例では、航空券や乗車券等のように交通手段のアイテムを意味する場合には交通手段アイテムと記載する。
【0127】
本変形例の旅行計画システムSでは、出発地取得部302と特定部303が実現される。出発地取得部302は、ユーザの出発地を取得する。
【0128】
出発地は、交通手段アイテムの出発地である。例えば、交通手段アイテムが航空券であれば、航空機が離陸する空港である。また例えば、交通手段アイテムが列車の乗車券であれば、乗車する駅である。また例えば、交通手段アイテムがバスの乗車券であれば、乗車する停留所である。また例えば、交通手段アイテムが乗船券であれば、乗船する港である。出発地は、ユーザの居住地であってもよいし、居住地とは異なる場所であってもよい。出発地が居住地とは異なる場所の場合、例えば、出発地は、ユーザの勤務先の場所であってもよいし、旅程における経由地であってもよい。
【0129】
本変形例では、出発地取得部302は、ユーザ端末10から出発地を取得する場合を説明するが、後述する変形例(5)のように、ユーザ登録情報等を利用して出発地を取得してもよい。例えば、出発地取得部302は、ユーザがユーザ端末10の操作部14から入力した出発地を取得する。また例えば、ユーザ端末10の記憶部12に予め出発地が記憶されている場合には、出発地取得部302は、記憶部12に記憶された出発地を取得する。
【0130】
特定部303は、他のユーザにより選択された、現地アイテムと、当該他のユーザの出発地と現地との間の交通手段アイテムと、を特定する。ここでは、レコメンドの対象となるユーザを単に「ユーザ」と記載し、それ以外のユーザを「他のユーザ」と記載する。
【0131】
本変形例では、他のユーザにより選択されたアイテムは、ユーザデータベースDB2に記録されているので、特定部303は、ユーザデータベースDB2に基づいて、他のユーザにより選択された、現地アイテムと交通手段アイテムとを特定する。これら現地アイテムと交通手段アイテムは、同一ユーザの同一の旅程に組み込まれたアイテムである。
【0132】
他のユーザにより選択されたアイテムは、他のユーザによる選択を受け付けたアイテムであり、例えば、旅行かごに追加されたアイテムであってもよいし、予約が完了したアイテムであってもよい。例えば、特定部303は、他のユーザの旅行かご情報を参照し、同一の旅行かごIDに関連付けられた現地アイテムと交通手段アイテムの組み合わせを特定する。また例えば、特定部303は、他のユーザの予約情報を参照し、同一の予約IDに関連付けられた現地アイテムと交通手段アイテムの組み合わせを特定する。
【0133】
第2検索部300は、ユーザにより現地アイテムが選択された場合に、出発地と、現地アイテムの場所と、がユーザと対応する他のユーザにより選択された交通手段アイテムに基づいて、ユーザの出発地と現地との間の交通手段アイテムを検索する。
【0134】
出発地が対応するとは、出発地が同じこと、出発地がある地域が同じこと、又は、距離が閾値未満であることである。場所が対応するとは、場所が同じこと、地域が同じこと、又は、距離が閾値未満であることである。
【0135】
第2検索部300は、出発地取得部302により取得されたユーザの出発地と、特定部303により特定された他のユーザの交通手段アイテムの出発地と、に基づいて、出発地がユーザと対応する他のユーザを特定する。また、第2検索部300は、ユーザにより選択された現地アイテムの場所と、特定部303により特定された他のユーザの現地アイテムの場所と、に基づいて、現地アイテムの場所がユーザと対応する他のユーザを特定する。
【0136】
第2検索部300は、上記特定した他のユーザにより選択された交通手段アイテムに基づいて、ユーザにレコメンドすべき交通手段アイテムを検索する。例えば、第2検索部300は、他のユーザにより選択された交通手段アイテムと同じ交通手段アイテムを検索する。また例えば、第2検索部300は、他のユーザにより選択された交通手段アイテムの時間及び場所に基づいて、交通手段アイテムを検索してもよい。この場合、第2検索部300は、他のユーザにより選択された交通手段アイテムの時間及び場所に対応する時間の交通手段アイテムを検索する。
【0137】
即ち、第2検索部300は、ユーザにより選択された現地アイテムの場所に対応する場所の現地アイテムを選択し、かつ、ユーザの出発地に対応する出発地で交通手段アイテムを選択した他のユーザが存在する場合に、当該他のユーザにより選択された交通手段アイテムに基づいて、ユーザの交通手段アイテムを検索する。なお、他のユーザは、同一の旅程内で、上記現地アイテムと上記交通手段アイテムとを選択しているものとする。また、出発地と現地アイテムの場所とがユーザと対応する他のユーザは、複数人いることがあるので、この場合は、第2検索部300は、人気の高い交通手段アイテムに基づいて検索を実行してもよい。人気とは、選択数であり、例えば、旅行かごへの追加数であってもよいし、予約数であってもよい。人気が高いとは、選択数が多いことである。例えば、第2検索部300は、人気が最も高い交通手段アイテムに基づいて検索を実行してもよいし、人気がn番目(nは2以上の整数。例えば、2~5程度の数値。)までの交通手段アイテムに基づいて検索を実行してもよい。
【0138】
図13は、変形例(1)における旅行かご画面G4の一例を示す図である。
図13の例では、表示領域A40A,A40Bに示すように、ユーザが「ホテルA」と「アクティビティZ」の2つの現地アイテムを旅行かごに追加している。「ホテルA」は、「2018年7月1日15時」-「2018年7月5日11時」の時間が指定されており、場所は「沖縄県」である。「アクティビティZ」は、「2018年7月1日13時-15時」の時間が指定されており、場所は「沖縄県」である。なお、ユーザの出発地は「東京都」とする。
【0139】
第2検索部300は、出発地が「東京都」であり、かつ、「沖縄県」の現地アイテムを選択した他のユーザを検索する。ここでは、同様の時間に「沖縄県」の現地アイテムを選択した他のユーザが、「東京都」の空港の出発時間が「2018年7月1日8:00」であり、「沖縄県」の空港の到着時間が「2018年7月1日10:30」の「XXX123便」の片道航空券を、交通手段アイテムとして選択していたものとする。
【0140】
第2検索部300は、上記他のユーザが選択した「XXX123便」と同じ交通手段アイテムを検索し、
図13の表示領域A41に示すように、「XXX123便」の片道航空券がレコメンドされる。なお、第2検索部300は、同様の時間帯に「沖縄県」に到着する他の航空会社の航空券を検索してもよいし、同様の時間帯に「沖縄県」に到着する船舶の乗船券を検索してもよい。また、第2検索部300は、他のユーザの人気の高い順に複数個の交通手段アイテムを検索してもよい。また、後述する変形例(2)-(3)のように、第2検索部300は、他のユーザが選択した「XXX123便」の前後の便を検索してもよい。
【0141】
なお、第2検索部300は、現地アイテムの場所だけでなく、時間も対応する他のユーザにより選択された交通手段アイテムに基づいて、ユーザの交通手段アイテムを検索してもよい。時間が対応するとは、時間が同じこと、時間差が閾値未満であること、又は、時間帯が重複していることである。第2検索部300は、ユーザにより選択された現地アイテムの時間及び場所と、特定部により特定された他のユーザの現地アイテムの時間及び場所と、に基づいて、現地アイテムの時間及び場所がユーザと対応する他のユーザを特定してもよい。
図13の例であれば、「沖縄県」という現地アイテムの場所だけでなく、「2018年7月1日-7月5日」という期間も考慮したうえで、他のユーザが特定されてもよい。特定した他のユーザの交通手段アイテムに基づいてユーザの交通手段アイテムを検索する方法は、上記説明した通りである。更に、現地アイテムの場所と時間の両方を考慮すると、他のユーザのデータ数が不足する場合には、現地アイテムの場所だけを考慮するといったように、他のユーザのデータ数に応じて使い分けるようにしてもよい。
【0142】
変形例(1)によれば、ユーザにより現地アイテムが選択された場合に、出発地と現地アイテムの場所がユーザと対応する他のユーザにより選択された交通手段アイテムに基づいて、ユーザの出発地から現地までの交通手段アイテムが検索されるので、レコメンドの精度を高めることができる。レコメンドの精度を高めることで、ユーザが交通手段アイテムを探す手間を効果的に軽減することができ、余計な処理が実行される蓋然性を低減することで旅行計画システムSの処理負荷を効果的に軽減することもできる。即ち、他のユーザのデータ数(旅行かご情報や予約情報)が一定数以上蓄積された場合には、精度の高いリコメンドをすることができ、結果的に、リコメンドされた交通手段アイテムをユーザが選択する蓋然性が高まるので、ユーザが出発地と現地との間の経路検索等をすることなく、旅行計画システムSの処理負荷を軽減することができる。処理負荷を軽減する点については、以降説明する変形例で「レコメンドの精度を高める」と記載した内容についても同様である。
【0143】
(2)また例えば、変形例(1)において、ユーザが現地アイテムを到着日に利用する場合、現地アイテムの利用時間に間に合うためには、現地に早く到着するに越したことはない。このため、第2検索部300は、他のユーザにより選択された交通手段アイテムに対応する交通手段アイテムの在庫がない場合に、現地への到着時間が、他のユーザにより選択された交通手段アイテムよりも早い交通手段アイテムを検索してもよい。
【0144】
他のユーザにより選択された交通手段アイテムに対応する交通手段アイテムとは、時間と場所が対応する交通手段アイテムである。「時間が対応する」の意味と、「場所が対応する」の意味と、は、変形例(1)で説明した通りである。在庫とは、残席であり、予約可能数ということもできる。各交通手段アイテムの在庫数は、データ記憶部400に記憶されており、交通手段アイテムが旅行かごに追加されたり予約されたりした場合に在庫数が変化する。第2検索部300は、在庫数が閾値(例えば、1)以上であれば、在庫があると判定し、在庫数が閾値未満であれば、在庫がないと判定する。第2検索部300は、他のユーザにより選択された交通手段アイテムの到着時間よりも早い時間をクエリにして、現地への交通手段アイテムを検索する。
【0145】
図14は、変形例(2)における旅行かご画面G4の一例を示す図である。ここでは、他のユーザにとって最も人気が高い往路の交通手段アイテムが、「東京都」の空港の出発時間が「2018年7月1日8:00」であり、「沖縄県」の空港の到着時間が「2018年7月1日10:30」の「XXX123便」の片道航空券であったとする。
【0146】
第2検索部300は、他のユーザが選択した「XXX123便」の在庫の有無を判定し、在庫がある場合は「XXX123便」がリコメンドされる。一方、第2検索部300は、「XXX123便」の在庫がない場合は、到着時間である「2018年7月1日10:30」よりも早い到着時間の交通手段を検索する。例えば、第2検索部300は、「2018年7月1日」の「8:00」~「10:30」の時間帯に現地に到着する交通手段を検索する。
図14の表示領域A41に示すように、「2018年7月1日9:30」に現地に到着する「XXX234便」の片道航空券が検索され、レコメンドされる。
【0147】
なお、上記の例において、2番目に人気が高い交通手段アイテムが、「XXX123便」よりも到着時間が遅い「AAA999便」であり、3番目に人気が高い交通手段アイテムが、「XXX123便」よりも到着時間が早い「XXX234便」であった場合に、2番目に人気が高い「AAA999便」ではなく、「XXX234便」が検索されてリコメンドされる。このようにすることで、他のユーザの数が一定以上になれば、複雑な処理を要することなく、ユーザが現地で旅程をこなすのに十分な時間を確保可能な時刻までに到着可能な交通手段をリコメンドできる。
【0148】
変形例(2)によれば、ユーザにより選択された現地アイテムが現地への到着日に利用され、他のユーザにより選択された交通手段の在庫がない場合に、早い到着時間の交通手段アイテムをレコメンドすることで、余裕のある旅程を立てさせることができる。余裕のある旅程であればユーザが選択する蓋然性が高まるので、レコメンドの精度を効果的に高めることができる。
【0149】
(3)また例えば、変形例(1)において、ユーザが現地アイテムを最終日に利用する場合、帰りの交通手段に間に合うためには、遅めの交通手段を利用するに越したことはない。このため、第2検索部300は、他のユーザにより選択された交通手段アイテムに対応する交通手段アイテムの在庫がない場合に、現地からの出発時間が、他のユーザにより選択された交通手段アイテムよりも遅い交通手段アイテムを検索してもよい。第2検索部300は、他のユーザにより選択された交通手段アイテムの出発時間よりも遅い時間をクエリにして、現地からの交通手段アイテムを検索する。
【0150】
図15は、変形例(3)における旅行かご画面G4の一例を示す図である。ここでは、他のユーザにとって最も人気が高い復路の交通手段アイテムが、「沖縄県」の空港の出発時間が「2018年7月5日17:00」であり、「東京都」の空港の到着時間が「2018年7月5日19:15」の「XXX876便」の片道航空券であったものとする。
【0151】
第2検索部300は、他のユーザが選択した「XXX876便」の在庫の有無を判定し、在庫がある場合は、「XXX876便」がリコメンドされる。一方、第2検索部300は、「XXX876便」の在庫がない場合は、出発時間である「2018年7月5日17:00」よりも遅い出発時間の交通手段を検索する。例えば、第2検索部300は、「2018年7月5日」の「17:00」~「19:00」の時間帯に出発地に帰る交通手段を検索する。
図15の表示領域A41に示すように、「2018年7月5日18:00」に現地から出発する「XXX987便」の片道航空券がレコメンドされる。
【0152】
なお、上記の例において、2番目に人気が高い交通手段アイテムが、「XXX876便」よりも出発時間が早い「AAA111便」であり、3番目に人気が高い交通手段アイテムが、「XXX876便」よりも出発時間が遅い「XXX987便」であった場合に、2番目に人気が高い「AAA111便」ではなく、「XXX987便」が検索されてリコメンドされる。このようにすることで、他のユーザの数が一定以上になれば、複雑な処理を要することなく、ユーザが現地で旅程をこなすのに十分な時間を確保可能な時刻の後に発着可能な交通手段をリコメンドできる。
【0153】
変形例(3)によれば、ユーザにより選択された現地アイテムが現地からの出発日に利用され、他のユーザにより選択された交通手段の在庫がない場合に、遅い出発時間の交通手段アイテムをレコメンドすることで、余裕のある旅程を立てさせることができる。余裕のある旅程であればユーザが選択する蓋然性が高まるので、レコメンドの精度を効果的に高めることができる。
【0154】
(4)また例えば、ユーザの旅程は、複数の期間にまたがることがある。期間は、ある時点から他の時点までの間、又は、一定の時間的な長さである。期間は、任意の長さであればよく、数時間単位、1日単位、数日単位、又は1週間単位であってもよい。期間は、時間で区切られてもよいし、滞在地で区切られてもよい。例えば、ユーザが、山口県、福岡県、及び長崎県を周遊する場合には、旅程は、山口県の期間、福岡県の期間、及び長崎県の期間の3つの期間を含むようにしてもよい。
【0155】
旅程が複数の期間にまたがる場合に、第2検索部300は、期間ごとに、当該期間におけるアイテムの時間及び場所に基づいて検索を実行してもよい。各期間における検索方法自体は、実施形態で説明した通りである。第2検索部300は、期間ごとに、当該期間に含まれるアイテムの時間及び場所をクエリとし、アイテムデータベースDB1に格納された基本情報をインデックスとして、他の種類のアイテムを検索する。第2検索部300は、期間の数だけ検索を実行することになる。提示部301は、期間ごとに、第2検索部300により検索されたアイテムを提示する。アイテムの提示方法自体は、実施形態で説明した通りである。
【0156】
図16は、変形例(4)における旅行かご画面G4の一例を示す図である。
図16の表示領域A40に示すように、ユーザが「ホテルA」を旅行かごに追加している。「ホテルA」は、「2018年7月1日15時」-「2018年7月5日11時」の時間が指定されており、ユーザの旅程は、5日間にまたがっていることが特定される。
【0157】
図16の例の場合、表示領域A41A~A41Cに示すように、旅程に含まれる日ごとに、アイテムが検索されてレコメンドされるようにしてもよい。例えば、表示領域A41Aには、1日目のアイテムがリコメンドされる。また例えば、表示領域A41Bには、2日目のアイテムがリコメンドされる。また例えば、表示領域A41Cには、3日目のアイテムがリコメンドされる。4日目以降のアイテムについても同様に、日ごとにアイテムがリコメンドされることになる。
【0158】
変形例(4)によれば、旅程が複数の期間にまたがる場合に、期間ごとにアイテムを検索してレコメンドすることで、レコメンドの精度を効果的に高めることができる。
【0159】
(5)また例えば、旅行計画システムSでは、ユーザにより登録されたユーザ登録情報、又は、ユーザの通信環境に基づいて、ユーザの出発地を取得する出発地取得部202が実現され、第2検索部300は、出発地取得部202により取得されたユーザの出発地に基づいて検索を実行してもよい。
【0160】
例えば、出発地取得部202は、ユーザデータベースDB2に格納されたユーザ登録情報を参照し、ユーザの出発地を取得する。ユーザ登録情報は、旅行予約サービス以外のサービスのユーザ登録情報であってもよく、旅行計画システムSが電子商取引サービスと連携する場合には、電子商取引サービスのユーザ登録情報に基づいて、ユーザの出発地を取得してもよい。この場合、ユーザが会員登録時に入力した住所を出発地としてもよいし、商品の配送先の住所を出発地としてもよい。
【0161】
また例えば、出発地取得部202は、ユーザ端末10におけるユーザの通信環境に基づいて、ユーザの出発地を取得する。通信環境は、ユーザ端末10の位置ということもでき、例えば、ユーザ端末10のIPアドレス、ユーザ端末10が通信する基地局、ユーザ端末10が通信するアクセスポイント、又はGPS位置情報等である。データベースサーバ40のデータ記憶部400には、通信環境と場所との対応関係が記憶されており、出発地取得部202は、ユーザの通信環境に関連付けられた場所を、ユーザの出発地として取得する。
【0162】
なお、第2検索部300は、目的地は、検索条件から取得してもよいし、ユーザにより選択された現地アイテムの場所に基づいて取得してもよい。第2検索部300は、出発地取得部202により取得されたユーザの出発地と、上記取得した目的地と、に基づいて交通手段アイテムを検索する。
【0163】
変形例(5)によれば、ユーザの出発地をユーザ登録情報又は通信環境に基づいて取得することで、ユーザに出発地を入力させる手間を省くことができ、出発地を推定する精度を高めることでレコメンドの精度を高めることもできる。
【0164】
(6)また例えば、ユーザが過去に予約したアイテムの利用時間が経過した場合には、このアイテムが組み込まれた旅程は既に終了しているので、当該アイテムに基づくレコメンドが実行されないようにしてもよい。即ち、アイテムの利用時間が経過していなければ、ユーザが旅程にアイテムを追加する可能性があるので、利用時間が経過していないアイテムに基づくリコメンドが実行されるようにしてもよい。
【0165】
第2検索部300は、ユーザにより選択されたアイテムの時間が経過したかを判定し、当該判定結果に基づいて検索を実行する。第2検索部300は、リアルタイムクロック等を利用して現在時間を取得し、ユーザにより選択されたアイテムの時間が経過したかを判定する。旅程が複数の期間にまたがる場合には、何れか1つのアイテムの時間が経過した場合に、当該旅程の時間が経過したと判定されてもよいし、全てのアイテムの時間が経過した場合に、当該旅程の時間が経過したと判定されてもよい。
【0166】
第2検索部300は、時間が経過していないアイテムの時間及び場所に基づいて検索を実行し、時間が経過したアイテムの時間及び場所に基づいては検索を実行しない。別の言い方をすれば、第2検索部300は、ユーザにより選択された全アイテムのうち、時間が経過していないアイテムの時間及び場所を検索のクエリとし、時間が経過したアイテムの時間及び場所は検索のクエリから除外する。検索方法自体は、実施形態で説明した通りである。
【0167】
変形例(6)によれば、ユーザにより選択されたアイテムの時間が経過したかの判定結果に基づいて検索を実行することで、ユーザにとって不要なレコメンドがなされる蓋然性を低減し、レコメンドの精度を高めることができる。
【0168】
(7)また例えば、ユーザが検索条件を変更した場合には、別の旅程を計画し始めた蓋然性が高い。このため、新しい検索条件でヒットしたアイテムに基づいてレコメンドが実行されてもよい。
【0169】
第2検索部300は、ユーザにより新たな時間及び場所が入力されたかを判定し、当該判定結果に基づいて検索を実行する。ここでは、ユーザの検索条件は、ユーザデータベースDB2等に保持されているものとする。第2検索部300は、ユーザ端末10から受信した検索条件と、ユーザデータベースDB2等に保持された検索条件と、を比較し、これらが一致するかを判定する。第2検索部300は、これらが一致する場合には、ユーザにより新たな時間及び場所が入力されたとは判定せず、これらが一致した場合に、ユーザにより新たな時間及び場所が入力されたと判定する。
【0170】
第2検索部300は、ユーザにより新たな時間及び場所が入力されたと判定した場合に、当該新たな時間及び場所に基づいて検索されたアイテムの時間及び場所に基づいて、検索を実行する。検索方法自体は、実施形態で説明した通りである。なお、古い検索条件に基づいてレコメンドが実行されてもよいが、その場合には、古い検索条件に基づくレコメンドであることが識別可能なようにレコメンドされるものとする。
【0171】
変形例(7)によれば、ユーザにより入力された時間及び場所が変更されたかの判定結果に基づいて検索を実行することで、ユーザにとって不要なレコメンドがなされる蓋然性を低減し、レコメンドの精度を高めることができる。
【0172】
(8)また例えば、ユーザは、複数の旅程を作成可能であってもよい。即ち、1人のユーザに対して複数の旅行かごを割り当てて、ユーザが複数の旅程を同時に計画できるようにしてもよい。
【0173】
例えば、ユーザは、アイテムを追加する場合に旅程を指定してもよいし、旅程を指定したうえでアイテムを追加してもよい。また例えば、ユーザにより選択されたアイテムの場所及び時間の少なくとも1つに基づいて、当該アイテムが属する旅程が自動的に判別されてもよい。例えば、ユーザにより選択されたアイテムが、当該アイテムの場所に対応する場所のアイテムが組み込まれた旅程に入れられる。また例えば、ユーザにより選択されたアイテムが、当該アイテムの時間に対応する時間のアイテムが組み込まれた旅程に入れられる。
【0174】
第2検索部300は、旅程ごとに、当該旅程に含まれるアイテムの時間及び場所に基づいて検索を実行する。各旅程における検索方法自体は、実施形態で説明した通りである。第2検索部300は、旅程ごとに、当該旅程に含まれるアイテムの時間及び場所をクエリとし、アイテムデータベースDB1に格納された基本情報をインデックスとして、他の種類のアイテムを検索する。第2検索部300は、旅程の数だけ検索を実行することになる。提示部301は、旅程ごとに、第2検索部300により検索されたアイテムを提示する。アイテムの提示方法自体は、実施形態で説明した通りである。
【0175】
図17は、変形例(8)における旅行かご画面G4の一例を示す図である。
図17の例では、表示領域A40Aに示す「かご1」は、1つ目の旅行かごであり、1つ目の旅程を示す。一方、表示領域A40Bに示す「かご2」は、2つ目の旅行かごであり、2つ目の旅程を示す。旅行かごは、2つに限られず、3つ以上であってもよく、旅程ごとに旅行かごが用意されるようにすればよい。
【0176】
図17に示すように、「かご1」の旅程に組み込まれたアイテムの時間及び場所に基づいて、1つ目の旅程のレコメンドが行われ、表示領域A41Aには、1つ目の旅程でレコメンドされたアイテムが表示される。ユーザがボタンB410Aを選択した場合、当該アイテムを1つ目の旅程に追加することができる。
【0177】
また、「かご2」の旅程に組み込まれたアイテムの時間及び場所に基づいて、2つ目の旅程のレコメンドが行われ、表示領域A41Bには、2つ目の旅程でレコメンドされたアイテムが表示される。ユーザがボタンB410Bを選択した場合、当該アイテムを2つ目の旅程に追加することができる。
【0178】
変形例(8)によれば、ユーザが複数の旅程を作成する場合に、旅程ごとにアイテムを検索してレコメンドすることで、レコメンドの精度を効果的に高めることができる。
【0179】
(9)また例えば、変形例(8)において、ユーザが複数の旅程を同時に作成する場合に、第2検索部300は、ユーザにより選択された複数の宿泊施設アイテムの各々の日付が連続している場合に、各宿泊施設アイテムが同じ旅程に含まれると判定してもよい。第2検索部300は、ユーザにより選択された複数の宿泊施設アイテムの日付を参照し、間が空くことなく日付が続いているかを判定する。第2検索部300は、間が空くことなく日付が続いている場合、各宿泊施設アイテムを同じ旅程に含まれると判定し、各宿泊施設アイテムに対し、同じ旅行かごIDを付与する。
【0180】
変形例(9)によれば、ユーザにより選択された複数の宿泊施設アイテムの日付が連続している場合に、これら複数の宿泊施設アイテムが同じ旅程に含まれると判定することで、旅程を区別する精度が高まるので、レコメンドの精度を効果的に高めることができる。
【0181】
(10)また例えば、第2検索部300は、ユーザにより選択されたアイテムの時間に基づいて旅程の期間を特定し、当該期間に基づいて検索を実行してもよい。第2検索部300は、ユーザにより選択されたアイテムの時間を参照し、最も早い時間に基づいて期間の開始時点を特定し、最も遅い時間に基づいて期間の終了時点を特定する。第2検索部300は、開始時点から終了時点までの期間をクエリとし、検索を実行する。検索の実行方法自体は、実施形態で説明した通りである。
【0182】
変形例(10)によれば、ユーザにより選択されたアイテムの時間に基づいて特定された旅程の期間に基づいて検索を実行してレコメンドすることで、ユーザの旅程には関係のない期間のアイテムがレコメンドされることを防止し、レコメンドの精度を効果的に高めることができる。
【0183】
(11)また例えば、第2検索部300は、ユーザにより選択されたアイテムの時間及び場所に基づいて他の種類のアイテムの利用可能性を判定し、当該判定結果に基づいて検索を実行してもよい。利用可能性とは、移動が間に合うか否かである。移動が間に合う場合は、利用可能性があり、移動が間に合わない場合は、利用可能性がない。
【0184】
第2検索部300は、ユーザにより選択されたアイテムの時間及び場所と、他の種類のアイテムの時間及び場所と、に基づいて、他の種類のアイテムの利用可能性を判定する。例えば、第2検索部300は、ユーザにより選択されたアイテムの場所と、他の種類のアイテムの場所と、に基づいて、移動時間を計算する。第2検索部300は、ユーザにより選択されたアイテムの時間に当該移動時間を加えた時間が、他の種類のアイテムの時間よりも前であれば、他の種類のアイテムを利用可能と判定し、後であれば、他の種類のアイテムを利用不可能と判定する。提示部301によるレコメンドは、利用可能なアイテムを対象とし、利用不可能なアイテムは対象外とする。
【0185】
変形例(11)によれば、他の種類のアイテムの利用可能性の判定結果に基づいて検索を実行してレコメンドすることで、利用不可能なアイテムがレコメンドされてしまうことを防止し、レコメンドの精度を効果的に高めることができる。
【0186】
(12)また例えば、上記説明した変形例を組み合わせてもよい。
【0187】
また例えば、主な機能がウェブサーバ20と分析サーバ30との間で分担される場合を説明したが、各機能は、ウェブサーバ20又は分析サーバ30だけで実現されてもよい。例えば、ウェブサーバ20において第2検索部300が実現されてもよい。この場合、第2検索部300は制御部21を主として実現される。ウェブサーバ20の第2検索部300は、受付部201により選択を受け付けたアイテムの時間及び場所を特定し、他の種類のアイテムを検索する。また例えば、ウェブサーバ20において提示部301が実現されてもよい。この場合、提示部301は制御部21を主として実現される。ウェブサーバ20の提示部301は、第2検索部300の検索結果を取得し、検索されたアイテムを提示する。
【0188】
また例えば、分析サーバ30において、第1検索部200が実現されてもよい。この場合、第1検索部200は、制御部31を主として実現される。分析サーバ30の第1検索部200は、ユーザ端末10から検索条件を取得し、検索を実行する。また例えば、分析サーバ30において、受付部201が実現されてもよい。この場合、受付部201は、制御部31を主として実現される。分析サーバ30の受付部201は、ユーザ端末10からアイテムの選択結果を受信する。
【0189】
また例えば、データ記憶部400で記憶されるものとして説明したデータは、データベースサーバ40とは異なるコンピュータによって記憶されてもよい。例えば、データ記憶部400がウェブサーバ20又は分析サーバ30によって実現されてもよい。この場合、データ記憶部400は、記憶部22又は32によって実現される。他にも例えば、データは、旅行計画システムSの外部にあるデータベースサーバによって記憶されていてもよい。
【符号の説明】
【0190】
S 旅行計画システム、N ネットワーク、10 ユーザ端末、11,21,31,41 制御部、12,22,32,42 記憶部、13,23,33,43 通信部、14 操作部、15 表示部、20 ウェブサーバ、30 分析サーバ、40 データベースサーバ、G1,G1A,G1B トップ画面、G2 検索結果画面、G3 アイテム画面、G4,G4A,G4B,G4C,G4D 旅行かご画面、100 データ記憶部、101 受付部、102 表示制御部、201 受付部、202 出発地取得部、301 提示部、302 出発地取得部、303 特定部、400 データ記憶部、A40,A41,A41A,A41B,A41C 表示領域、B14,B30,A410,A410A,A410B,A410C,B400,B401,B410 ボタン、DB1 アイテムデータベース、DB2 ユーザデータベース、DB3 レコメンドデータベース、F10,F11,F12,F13,F20 入力フォーム、L21 リスト。