JP6456348B2 - アイテムクエリの管理 - Google Patents

Description

情報の取得およびアイテム購入のために、利用者によってコンピューティングデバイスおよびコンピューティングネットワークが頻繁に用いられている。たとえば、利用者は自身のパーソナルコンピューティングデバイスを使って、ネットワークベースの情報サービスにより、関心のあるアイテムに関する情報をサーチ、レビューおよび共有することができる。別の例を挙げると、利用者は自身のパーソナルコンピューティングデバイスを使用して、ネットワークベースの小売店から、関心のあるアイテムを購入することができる。しかもネットワークベースのサービスによって、利用者は自宅または自身のオフィスに居ながらにして、自分のペースで都合のよいときに、これらのタスクを実行することができる。

場合によってはネットワークベースのサービスは、様々な情報源から提供される多種多様なアイテムに関する情報を用意しているケースもある。たとえばネットワークベースの旅行サービスによって、種々の航空会社、宿泊施設提供者、レンタル会社などによるフライト、宿泊施設（たとえばホテル、Ｂ＆Ｂ、ホステル、リゾート等）、地上移動手段（レンタカー、タクシー、タウンカー、列車、シャトル便等）、またはその他の旅行アイテムが提供されている場合もある。さらに各アイテムの在庫が著しく頻繁に書き換えられる可能性もあり、何らかの旅行アイテムを入手できる可能性（たとえば特定のフライトまたはホテルルーム）が、極めて短い期間のうちに変更される可能性もある。しかも、利用者の基準に合致した複数のアイテム（指定された行先までの複数のフライトまたはフライトの組み合わせ、指定された市内の複数のホテルルーム等）を利用できる可能性がある場合もある。しかしながら、ネットワークベースのサービスのサーチ能力によっても、可能なあらゆる基準の組み合わせが含まれるようにすることはできず、したがって１つの指定されたクエリに基づき関連のあるすべての結果を利用者に呈示できない場合もあり得る。さらに場合によっては、ネットワークベースのサービスにおけるアイテムを探し当てるための付加的なまたは代替となる基準に、利用者が気づかない可能性もある。

これまで述べてきた見地および付随する数多くの利点について、添付の図面を参照しながら以下の詳細な説明を読むことで理解が深まれば、それらの把握が容易になるはずである。

旅行サービスを稼動させて旅行者が希望する旅行プランの推定に基づき推奨旅行パッケージを提供可能である、ネットワーク環境について例示したブロック図 推奨旅行パッケージの生成に適用可能である、図１の旅行サービスに対応する利用内容情報生成について例示したブロック図 図１による旅行サービスに対する旅行アイテムクエリのサブミット、旅行アイテムクエリに基づく旅行者の希望旅行プランの推定、および希望する旅行プランに基づき生成された推奨旅行パッケージのリターンについて例示したブロック図 図１による旅行サービスへの旅行アイテムクエリのサブミット、および図１による旅行サービスからの推奨の提供を容易にするために適用可能なユーザインタフェースについて例示した図 図１による旅行サービスへの旅行アイテムクエリのサブミット、および図１による旅行サービスからの推奨の提供を容易にするために適用可能なユーザインタフェースについて例示した図 旅行者が希望する旅行プランの推定および希望する旅行プランに基づく旅行パッケージの生成のためのルーチンについて例示したフローチャート

一般的に述べると、ここで開示する本発明の見地は、ネットワークベースの旅行サービスを介して提供または供給される旅行アイテムに対するクエリの管理に関するものである。さらに詳しく述べると、本発明の見地は、目下のクエリに基づき推奨される旅行クエリの生成を容易にすること、ならびに推奨された旅行クエリに対応するアイテムを推奨すること、に関するものである。具体的には、ネットワークベースの旅行サービスによって、収集、購入または予約のために１つまたは複数の旅行アイテムを提供することができる。旅行アイテムとしては、フライト、ホテルまたは他の宿泊施設、地上移動手段、アクティビティなどのようなアイテムを挙げることができる。ネットワークベースの旅行サービスの利用者は、１つまたは複数の旅行アイテム（たとえば関連するフライト、ホテル、レンタカー等）を選択するための基準を含む１つまたは複数のクエリをサブミットすることができる。その後、サービスは、利用可能な関連する何らかの旅行アイテムをリターンすることができる。これらに加えサービスは、利用者にとって関心のある付加的な旅行クエリに対する推奨をリターンすることができるし、またはこのような付加的な旅行クエリの実行結果により得られたアイテムをリターンしてもよい。本発明の実施形態によれば、付加的な旅行クエリは、利用者が希望する旅行プランの推定に少なくとも部分的に基づき、生成可能である。たとえば旅行サービスは、利用者のクエリに基づいて、利用者が特定のロケーションで休暇を過ごすことに関心がある、と推定することができる。旅行サービスは、推定された旅行プランに対応する、利用者向けに提案されたクエリを生成することができる。たとえば旅行サービスは、フライトと宿泊施設と移動手段との組み合わせに対し提案されたクエリを生成することができる。提案されたクエリを実行すれば、利用者は各旅行アイテムごとに個別にサーチしなくてもよくなる。さらに、リターンされたすべてのアイテムが互いに両立するように（たとえば各アイテムの日時が対応し合うように）、提案されたクエリを生成することができる。したがって利用者は、自身が希望する旅行プランを満たす旅行アイテムの組み合わせ（たとえば旅行パッケージ）を、いっそう容易に見つけ出すことができる。

慣用的なインタラクションによれば、ネットワークベースの旅行サービス（たとえば１つまたは複数の旅行アイテム提供者から入手可能な旅行アイテムに関する情報を提供するサービス）の利用者は、所定の範囲内の日付においてある特定の地域での休暇を希望することができる。このため利用者は（たとえば最小コストの料金を探す目的で）、ある範囲にわたる日付でその地域内の様々な空港へ向かうフライトに対し、クエリをサブミットすることができる。利用者は、希望するフライトを探し当てて、そのフライトと両立する宿泊施設に対するクエリ（たとえばフライト目的地に近く、滞在開始はフライト到着日、滞在終了はフライト出発日）のサブミットを続けて行うことができる。しかしながら、フライトに相応しい日付の宿泊施設の値段が極端に高い、という結果に利用者が直面する可能性もある。したがって総コストを下げる目的で、利用者は別の日付または別の場所で宿泊施設を探す場合もある。とはいえ、宿泊施設が事前に選択したフライトとは両立不可能であるかもしれず、そのため利用者は、自身が希望する旅行プランを満たすフライトと宿泊施設との組み合わせ（たとえば特定の地域での休暇であり所定の範囲内の日付かつ低コスト）が選択されるまで、先行のフライトクエリを繰り返さなければならないことになる。利用者は、個々の旅行アイテムごとに単独に、しかも旅行アイテムの両立性を考慮せずにクエリを実施するので、希望する旅行プランに最適なソリューションを提供する１つのまとまった旅行アイテム群を利用者が見つけ出す可能性は低い。

複数の旅行アイテムの組み合わせをいっそう効果的に容易に探し出せるようにする目的で、生成されたまたは事前に設定された旅行アイテムの組み合わせを、利用者に呈示することができる。一例として、ある範囲内の日付で特定の地域に向かうフライトをサーチする利用者に対し、フライトオプションならびに両立性のある宿泊施設を呈示することができる。ただし、この種の旅行アイテムの組み合わせは一般に、事前設定されているかまたは（たとえば特定のフライトに対し）サブミットされたクエリに基づき生成されるので、それらの組み合わせは、利用者が希望する旅行プランに最適なソリューションにはならない可能性がある。たとえば利用者は、サブミットされたクエリに基づき生成された旅行アイテムの組み合わせには呈示されていない別の場所または別の日に、旅行を希望する可能性もある。さらに、特定の場所へ向かうフライトに対するクエリをサブミットした利用者が、実際にはその場所の宿泊施設を希望するのではなく、（たとえば代案となる旅行の仕方によって）その場所以外への旅行を希望する可能性もある。このような希望ゆえに、その場所に対応する旅行アイテムの組み合わせのオファが、利用者の役に立たない可能性がある。さらに、想定可能な旅行アイテムの組み合わせの個数が著しく多くなる場合もあり、それらが頻繁に変更される可能性もある。このような変動に起因して、希望する旅行プランに合致する旅行アイテムの組み合わせが利用者に呈示される可能性が低くなってしまう。

したがって本発明の見地によれば、推定利用者旅行プランに基づき旅行アイテムまたは旅行アイテムクエリの推奨が生成される。具体例を挙げると、推定旅行プランを、特定の場所へ旅行する要望、一連の日付でまたは所定の期間にわたって旅行する要望、希望する旅行目的（たとえばビジネス、レジャー）、旅行プランに伴って発生する移動時間を最小限に抑える要望、旅行プランのコストを最小限に抑える要望、旅行プラン内で特定のクラスのサービスを受ける要望、などとすることができる。具体的に言えば、ネットワークベースの旅行サービスは、利用者のクエリを監視することができ、この種のクエリに基づき、その利用者に対し推定旅行プランを生成することができる。たとえば、ある特定の都市へ向かうフライトならびにその都市内のホテルのサーチを実施している利用者は、その都市への旅行を希望している、と推定することができる。別の例を挙げると、ある特定の都市へ向かうフライトならびにその都市の近郊地域内のホテルのサーチを実施している利用者は、その都市自体ではなく近郊地域への旅行を希望している、と推定することができる。同様に、広範囲にわたる日付についてサーチを実施している利用者は、指定された日付のうちいずれかの時点で旅行することを希望している、と推定することができる一方、厳密に特定された日付について複数のサーチを実施している利用者は、それらの特定の日付においてのみ旅行することを希望している、と推定することができる。

さらに推定旅行プランを、プロフィルデータなど利用者に関する付加的な情報に基づくものとしてもよい。たとえば、ファーストクラスのフライトを頻繁に購入している利用者であれば、やはりデラックスな宿泊施設や地上移動手段の調達も希望する、と推定することができる。さらに別の例を挙げると、ビジネス目的で頻繁にフライトを利用する利用者は、以降のサーチに基づきビジネスの目的で旅行する、と推定することができる。このため、いくつかの実施形態によれば、利用者のプロフィルデータを用いて、推定旅行プランをさらに正確にすることができる。

利用者が希望する旅行プランの推定に続いて、希望する旅行プランを満たすことを意図した複数のサーチを生成することができる。たとえば、利用者が希望する旅行プランが、特定の都市の近郊に位置する地域への休暇であるならば、その都市へのフライトと、その近郊地域にある宿泊施設と、その都市とその近郊地域とを結ぶ地上移動手段の組み合わせを探すために、サーチを生成することができる。この種のサーチは、先行時点で利用者が実施したサーチにそのまま基づいて生成されるのではなく、利用者の推定旅行プランに基づき生成されるので、生成されたサーチには、利用者によっても決してじかに指示されることのない旅行アイテムが含まれる可能性がある。たとえば、利用者は特定の都市へ向かうフライトと近郊地域内の宿泊施設を先行時点でサーチしたが、地上移動手段については先行時点でサーチしていなかった場合がある。それにもかかわらず、（たとえば移動時間の短縮などによって）希望する旅行プランが促進されるような地上移動手段に対するクエリを、推奨されたサーチに含めることができる。さらに、推定旅行プランを満たすアイテムの組み合わせを探すためにサーチを生成できることから、利用者はアイテムを個々に探し当てることを強いられない。いくつかのケースでは、組み合わせの中にある個々の旅行アイテム自体が個々に最適であるか否かに関係なく、複数の旅行アイテムから成る１つの最適な組み合わせが探し当てられるように、サーチが作成される。

いくつかの実施形態によれば、多数の想定可能なサーチを生成することができ、それらのサーチは各々、希望する旅行プランを潜在的に満たす旅行アイテムの組み合わせを探し当てようというものである。たとえば、希望する旅行プランに相応しい種々の代替的な日付のセットを探すために、想定可能なサーチを生成することができる。さらに別の例を挙げると、希望する旅行プランに相応しい代替的な場所（別の到着空港、別の宿泊施設の所在地など）を探すために、想定可能なサーチを生成することができる。その後、想定可能なサーチが希望する旅行プランを満たす旅行アイテムの組み合わせをリターンするであろう見込みを求める目的で、想定可能なサーチ各々をランク付けることができ、あるいは別の言い方をすれば、順番に整列することができる。たとえば、サーチによってリターンされる組み合わせに従って予期される総移動時間に基づき、サーチをランク付けることができる。具体的には、特定の空港へ向かうフライトのサーチおよびその空港付近の宿泊施設を、その空港へ向かうフライトおよびその空港からかなり遠い宿泊施設よりも高く、ランク付けすることができる。さらに別の例を挙げると、サーチに従って得られた旅行アイテムの組み合わせに対して予期される料金を、ランキングに含めることができる。具体的には、予期される料金を、旅行サービスにおいて過去に実施された同様のサーチに基づいて決定することができ、または、サーチによってリターンされた最低料金の旅行アイテム組み合わせを求めるためのサーチを実行することによって、決定することができる。さらにサーチのランキングを、推定された旅行プランの特定の見地に基づくものとすることができる。たとえば、推定されたビジネス旅行プランのランキングを、レジャー旅行プランのランキングよりも料金に対する依存度が小さくなるようにすることができる。同様に、推定されたレジャー旅行プランのランキングを、ビジネス旅行プランのランキングよりも総移動時間に対する依存度が小さくなるようにすることができる。ランキングに関するさらに別の特定の例については、あとで詳しく説明することにする。

１つの実施形態によれば、生成されたサーチのランキングに続いて、この種のサーチを推奨サーチとして利用者にリターンすることができる。たとえば、利用者が特定の都市へ向かうフライトをサーチし、その都市で休暇したいと推定された場合、その都市に対する休暇パッケージのためのサーチ数を、利用者に呈示することができる。各サーチは、特定の日付または場所など、休暇パッケージの特定の見地に関して異なっている可能性がある。したがって利用者は、サーチに対応する旅行アイテムの組み合わせを閲覧するために、１つのサーチを選択することができる。このようにして利用者は、自身の旅行プランに対して可能性のある旅行ソリューションを、個々の旅行アイテムをサーチすることなく、見つけ出すことができる。いくつかの実施形態によれば、推奨サーチ各々に関して、付加的な情報を利用者に呈示することができる。たとえば、サーチの推奨理由を利用者に知らせることができる。この種の理由を、たとえば上述の１つまたは複数のランキング指標に対応させることができる。たとえば、特定のサーチを推奨した理由は、同様のサーチを実施した他の利用者によって安価な旅行アイテムの組み合わせであることが保証されているからである、と利用者に知らせることができる。さらに別の具体例として、特定のサーチを推奨した理由は、サーチに対応する組み合わせに付随して生じる平均的な移動が全般的に短いからである、と利用者に知らせることができる。

さらに別の実施形態によれば、生成されたサーチのランキングに続いて、１つまたは複数のこの種のサーチを実行し、推奨された旅行アイテムの組み合わせを見つけるために用いることができる。このようにすれば、この種の組み合わせのサーチではなく、実際のアイテムの組み合わせを利用者に呈示することができる。たとえば旅行サービスは、特定の空港へ向かうフライトおよび特定の地域内のホテルのサーチが、利用者の旅行プランを満たすようである、と判定することができる。それに応じて、旅行サービスはサーチを実行することができ、特定の空港へ向かうフライトおよび特定の地域内のホテルの１つまたは複数の組み合わせを、利用者に呈示することができる。したがって利用者は、組み合わせに関する付加的な情報を閲覧することができ、その組み合わせを予約もしくは入手することができる。このようにして、１つまたは複数の固有の旅行アイテムのサーチを実行した利用者は、自身が希望する旅行プランを満たす旅行アイテムの１つの組み合わせを購入することができる。

ここでは特定のタイプの旅行サービスに関して説明してきたが、本発明の実施形態を、以下に限定するものではないが、フライト、宿泊施設、他の移動手段、アクティビティ、ツアー、旅行保険、日帰り旅行、目的地サービス、またはこれらの組み合わせを含む任意の旅行アイテムに適用することができる。

図１は、動作環境を例示するブロック図である。この図によれば、ネットワークベースの旅行サービス１５０により顧客は、サードパーティの販売業者またはこの旅行サービス１５０のオペレータによって利用可能にされた旅行アイテムの閲覧、サーチおよび入手を行うことができる。図１に示されているように動作環境には、１つまたは複数の予約システム１２０と、ネットワーク１３０を介してネットワークベースの旅行サービス１５０と通信を行う１つまたは複数の旅行者コンピューティングデバイス１１０とが含まれている。サードパーティの販売業者は予約システム１２０を用いて、旅行アイテムまたは旅行アイテムに関する情報を、ネットワーク１３０を介して旅行サービス１５０で利用できるようにすることができる。ついで旅行サービス１５０は、その旅行アイテムならびに他の旅行アイテムを、旅行者コンピューティングデバイス１１０に対し入手可能にすることができる。これに応じて、想定される旅行者は、旅行者コンピューティングデバイス１１０を用いて、旅行サービス１５０から入手可能な旅行アイテムの閲覧、旅行アイテムのサーチ、１つまたは複数の希望する旅行アイテムの予約または申し込みを行うことができる。

旅行者コンピューティングデバイス１１０を任意のコンピューティングデバイスとすることができ、たとえばラップトップコンピュータまたはタブレットコンピュータ、パーソナルコンピュータ、サーバ、パーソナルディジタルアシスタント（ＰＤＡ）、ハイブリッド型のＰＤＡ／モバイルフォン、モバイルフォン、電子ブックリーダ、セットトップボックス、カメラ、ディジタルメディアプレイヤー等とすることができる。予約システム１２０および旅行者コンピューティングデバイス１１０は、ネットワーク１３０を介して旅行サービス１５０と通信することができる。当業者であれば理解できるように、ネットワーク１３０を任意の有線または無線のネットワークあるいはそれらの組み合わせとすることができる。さらにネットワーク１３０を、パーソナルエリアネットワーク、ローカルエリアネットワーク、ワイドエリアネットワーク、ケーブルネットワーク、サテライトネットワーク、セルラフォンネットワーク、またはこれらの組み合わせとすることができる。例示された実施形態の場合、ネットワーク１３０はインターネットである。インターネットを介した通信、または他の上述のタイプの通信ネットワークのいずれかを介した通信のためのプロトコルおよびコンポーネントは、コンピュータコミュニケーションの当業者には周知であり、したがってここではこれ以上詳しい説明は不要である。

予約システム１２０を、旅行アイテムの申し込み、予約または取得を行うように構成されている、またはそれらを実施することのできる、任意のシステムまたはデバイスに相当するものとすることができる。たとえば予約システム１２０を、集中型予約システム（ＣＲＳ）、グローバルディストリビューションシステム（ＧＤＳ）、または他の任意のシステムに相当するものとすることができ、この場合、複数の旅行アイテム販売業者たとえば航空会社、ホテル、レンタカー代理店、周遊船会社、バスサービス業者などによって、申し込み、予約および／または購入のために旅行アイテムを入手可能にすることができる。別の実施形態によれば、予約システム１２０を、個々の旅行アイテム販売業者（たとえば特定の航空会社、ホテルまたはホテルチェーン、レンタカー代理店、周遊船会社、バスサービス業者等）によって提供されるシステムに相当するものとすることができる。一般に、予約システムはそれぞれ、旅行アイテムのサーチのために、および旅行アイテムの申し込みまたは取得または予約のために、他のネットワークベースのデバイスたとえば旅行サービス１５０のデバイスに対し旅行アイテムに関する情報をリクエストすることができる。予約システムのオペレーションは当業者に周知であり、ここではこれ以上詳しくは説明しないことにする。

図示の実施形態の場合、旅行サービス１５０は、１つまたは複数のネットワークを使って相互に接続された複数のコンピュータシステムを含むコンピュータ環境として描かれている。詳しく述べると、旅行サービス１５０には、ユーザインタフェースモジュール１５６、予約システムインタフェースモジュール１５２、利用内容監視モジュール１５８、利用内容情報データストア１６４、パッケージ推奨モジュール１６０、ならびに旅行者プロフィルデータストア１６６を含めることができる。ただし当業者には自明であるとおり、図１に描かれているものよりも僅かなまたは多くのコンポーネントが、旅行サービス１５０に含まれるようにしてもよい。さらに旅行サービス１５０に、様々なウェブサービスおよび／またはピア・ツー・ピアのネットワークコンフィギュレーションが含まれるようにしてもよい。これらに加えていくつかの実施形態によれば、１つのホストコンピューティング環境内に実装された１つまたは複数のバーチャルマシンによって、旅行サービスをインプリメントすることができる。ホストコンピューティング環境に、高速にプロビジョニングおよびリリースされる１つまたは複数のリソースを含めることができ、さらにこれらのコンピュータリソースには、コンピューティングデバイス、ネットワーキングデバイス、および／またはストレージデバイスを含めることができる。ホストコンピューティング環境は、クラウドコンピューティング環境と呼ばれる場合もある。したがって図１の旅行サービス１５０の描写はあくまで例示であって、本願の開示内容を限定するものではない。

予約システムインタフェースモジュール１５２によって、予約システム１２０とのインタラクションを容易に行うことができるようになり、そのようなインタラクションには、関連旅行アイテムのサーチ、旅行アイテムに関する情報の検索、および旅行アイテムの入手が含まれる。いくつかの実施形態によれば、複数の予約システムインタフェースモジュール１５２を設けることができ、それらのモジュールは各々、１つまたは複数の予約システム１２０とインタラクションするように構成される。たとえば、第１の予約システムインタフェースモジュール１５２は、航空会社ベースの予約システム１２０とインタラクションを行うことができる一方、第２の予約システムインタフェースモジュールは、ホテルベースの予約システム１２０とインタラクションを行うことができる。予約システム１２０とのインタラクションのためのシステムおよび方法の実現形態については、米国特許第１２／４７０，４４２号明細書、出願日：２００９年５月２１日、発明の名称："OPTIMIZED SYSTEM AND METHOD FOR FINDING BEST FARE"に記載されており、この文献をここで参照したことにより、その開示内容全体が本願にすべて組み込まれたものとする。

ユーザインタフェースモジュール１５６により、旅行者コンピューティングデバイスを介して旅行者による旅行アイテムのサーチ、閲覧および（たとえば予約や申し込みなどによる）入手を、容易に行えるようにすることができる。いくつかの実施形態によれば、ユーザインタフェースモジュール１５６には、このようなサーチ、閲覧および入手を容易にするウェブページを生成するためのウェブサーバを含めることができる。ユーザインタフェースモジュール１５６により生成可能なユーザインタフェースの具体例については、図４Ａおよび図４Ｂを参照しながら、あとで詳しく説明する。

さらにユーザインタフェースモジュール１５６を、旅行者プロフィルデータストア１６６からの情報を記憶、保持および入手するように構成することができる。旅行者プロフィルデータストア１６６を、任意の永続的なデータストアまたは実質的に永続的なデータストアとすることができ、たとえば１つまたは複数のハードディスクドライブ（ＨＤＤ）、ソリッドステートドライブ（ＳＳＤ）、またはネットワークアタッチトストレージデバイス（ＮＡＳ）に相当するものとすることができる。旅行者プロフィルデータストア１６６は、利用者に関する情報を記憶することができ、たとえば利用者の名前、年齢、住所、誕生日、クレジットカード情報、購入履歴、旅行予約、頻繁なフライト利用者、またはメンバープログラム情報などを記憶することができる。

さらにユーザインタフェースモジュール１５６は、旅行サービス１５０に関する旅行者コンピューティングデバイス１１０の利用内容情報を記憶するために、利用内容監視モジュール１５８とインタラクションを行うことができる。たとえばユーザインタフェースモジュール１５６は、旅行者による旅行アイテムのサーチ、閲覧および入手に関する情報を、利用内容監視モジュール１５８へ伝送することができる。利用内容監視モジュール１５８は、利用内容情報データストア１６４などのようなデータストアに記憶させるために、情報を変換または他の手法によって処理することができる。例を挙げておくと、利用内容情報の変換を、利用内容情報の匿名処理（たとえば名前や住所など取り扱いに慎重を要する情報または個人情報の削除）、あるいは利用内容情報の圧縮とすることができる。図２を参照しながらあとで詳しく説明するように、いくつかの実施形態によれば、利用内容監視モジュール１５８をさらに、利用内容情報を関連する複数のカテゴリに分類するように構成することができる。たとえば利用内容情報の第１のサブセットを、「ビジネス」アクティビティとして分類することができる一方、利用内容情報の第２のサブセットを、「レジャー」アクティビティとして分類することができる。利用内容情報の処理後、利用内容情報を（対応する分類情報とともに）利用内容情報データストア１６４内に記憶させることができる。上述の旅行者プロフィルデータストア１６６と同様に、利用内容情報データストア１６４を、任意の永続的なデータストアまたは実質的に永続的なデータストアとすることができ、たとえば１つまたは複数のハードディスクドライブ（ＨＤＤ）、ソリッドステートドライブ（ＳＳＤ）、またはネットワークアタッチトストレージデバイス（ＮＡＳ）に相当するものとすることができる。

旅行サービス１５０にさらに、パッケージ推奨モジュール１６０を含めることができ、このモジュールは、旅行者の希望する旅行プランを決定し、そのような旅行プランを満たす旅行アイテムの組み合わせを特定するために、複数の推奨クエリを生成するように構成されている。あとで説明するように、旅行者の希望する旅行プランを、旅行サービス１５０において旅行者より行われた１つまたは複数のサーチに基づき推定することができる。希望する旅行プランをさらに、旅行者に該当する別の情報に基づき推定することができ、たとえば、旅行サービス１５０または他のサービスにおいて旅行者により行われたサーチの履歴、旅行者の収集履歴、旅行者の推定所在地、あるいは旅行者のプロフィルデータに基づき、推定することができる。希望する旅行プランを、旅行アイテムの組み合わせを選択するための基準セットに全般的に対応させることができる。たとえば、希望する旅行プランによって、旅行のタイプ（たとえばビジネス、レジャー、ファミリー等）、旅行地、旅行日、または旅行のクラス（たとえばデラックス、エコノミー等）を指定することができる。さらに希望旅行プランによって、旅行アイテムの選択に対する制約たとえばコストまたは移動時間を最小限に抑える要求などを指定することができる。推定された希望旅行プランに基づき旅行サービス１５０は、旅行プランを満たす旅行アイテムの組み合わせを探し出す見込みのある複数のサーチを生成することができる。たとえば、希望旅行プランが、指定された都市において低コストで休暇をとることであれば、旅行サービス１５０は、複数の日時におけるその都市へのフライトおよびその都市内の宿泊施設に対するサーチを生成することができる。さらに旅行サービス１５０は、生成されたサーチをランク付けることができ、たとえば低コストの旅行アイテムの組み合わせが結果として得られる見込みなどによって、ランク付けを行うことができる。その後、それらのサーチを推奨サーチとして利用者にリターンすることができ、その際、利用者が推奨サーチ実行のために推奨を選択できるようにする。別の選択肢として、推奨された旅行パッケージ（たとえば旅行アイテムの組み合わせ）を特定するために、旅行サービス１５０によりサーチを実行することができる。ついでそれらの旅行パッケージの推奨を、旅行者コンピューティングデバイス１１０にリターンすることができる。

次に図２を参照しながら、図１の旅行サービス１５０に対応する利用内容情報を生成するための例示的なインタラクションについて説明する。あとで詳しく説明するように、たとえば旅行者コンピューティングデバイス１１０のために旅行パッケージを推奨する際に、この種の利用内容情報を用いることができる。図２の（１）において、１つまたは複数の旅行者コンピューティングデバイス１１０は、ユーザインタフェースモジュール１５６に対し旅行クエリをサブミットすることができる。旅行クエリには、旅行者コンピューティングデバイス１１０により望まれる１つまたは複数の旅行アイテムを探し出すためのサーチ基準を含めることができる。たとえば旅行クエリを、フライト、ホテル、自動車、周遊船、旅行パッケージ、アクティビティに対するクエリに該当するものとすることができる。具体例としてユーザインタフェースモジュール１５６を、（たとえば予約システムインタフェースモジュール１５２および１つまたは複数の予約システム１２０とのインタラクションによって）１つまたは複数の旅行アイテムを探し出し、関連する旅行アイテムを旅行者コンピューティングデバイス１１０にリターンするように、構成することができる。旅行アイテムに対するクエリについては当業者に一般的に知られているので、関連する旅行アイテムをリターンするための特定のインタラクションについては、ここではこれ以上詳しくは説明しない。

旅行者コンピューティングデバイス１１０により、または旅行者コンピューティングデバイス１１０に応答して生成される利用内容情報を、（２）において利用内容監視モジュール１５８にサブミットすることができる。具体的には利用内容情報を、１つの旅行者クエリ内でサブミットされた特定のサーチ基準に該当するものとすることができる。さらに利用内容情報を、旅行者コンピューティングデバイス１１０の別のアクティビティたとえば旅行サービス１５０における旅行アイテムの入手（たとえば申し込みまたは予約）などに該当するものとすることができる。いくつかの実施形態によれば、旅行者コンピューティングデバイス１１０から受け取った情報たとえばサーチ基準や入手リクエストなどに基づき、ユーザインタフェースモジュール１５６により利用内容情報を生成することができる。別の実施形態によれば利用内容情報を、旅行者コンピューティングデバイス１１０から受け取った情報に少なくとも部分的に基づくものとすることができる。たとえば旅行者コンピューティングデバイス１１０を、実行されたサーチや入手などの利用内容情報をユーザインタフェースモジュール１５６へ伝送して、さらに利用内容監視モジュール１５８へ伝送するように、構成することができる。

利用内容監視モジュール１５８が利用内容情報を受け取った後、利用内容監視モジュール１５８は（３）において、利用内容情報データストア１６４内に格納するために、利用内容情報を処理することができる。いくつかの実施形態によれば処理として挙げられるのは、名前、特定の住所、支払い情報など、何らかの個人データまたは取り扱いに慎重を要するデータを削除することで、利用内容情報を匿名化することである。別の実施形態によれば、匿名化としてデータの一般化を挙げることができる。たとえば、旅行者の固有の住所を削除する一方で、旅行者の特定の住所を対応する都市、地域、郵便番号、地方等として一般化することができる。さらに多くの実施形態において、利用内容情報データストア１６４にあとで格納するために、利用内容情報を圧縮するか別の手法で変換することができる。

いくつかの実施形態によれば、さらに利用内容監視モジュール１５８を、利用内容情報を分類してから記憶するように構成してもよい。たとえば分類を、特定の旅行アイテムクエリ、リクエストを出した旅行者、または旅行者が行う他のアクションに基づくものとすることができる。たとえば、月曜早朝に出発し、水曜５時以降に帰着するフライトに対するクエリを、「ビジネス」旅行者によるクエリとして分類することができる。この場合、この特定の旅行者が旅行サービス１５０を介して旅行アイテムを頻繁に入手しているならば、このクエリを「エリートビジネス」旅行者により実行されたものとして分類することができる。これとは逆に、金曜に出発し日曜夕方に帰着するフライトに対するクエリを、「レジャー」旅行として分類することができる。任意の個数のカテゴリを用いることができ、以下に限定されるものではないが、ビジネス旅行者、レジャー旅行者、休暇旅行者、頻繁な旅行者、所定の距離の旅行者（たとえば短距離または長距離、マイルに基づく距離等）、国際旅行者または国内旅行者、あるいは所定の場所からの旅行者（たとえば所定の都市、州、地域、国からの、またはそこに在住する旅行者等）が、カテゴリとして挙げられる。これに加え、複数のカテゴリを組み合わせてもよい。たとえば、「アメリカ合衆国東海岸からのエリート国際レジャー旅行者」を、カテゴリに含めることができる。一般的に言えば、カテゴリが特殊になればなるほど、そのカテゴリに該当しそうな利用内容（たとえばサーチおよび申し込みなど）が少なくなる。

たとえば実施されたサーチや旅行アイテムの入手など利用内容情報の分類を、結果として利用内容が発生することになる特定のクエリ（たとえばサーチを容易にするクエリ、または最終的に旅行アイテムの入手に至るクエリ）に基づくものとすることができる。ある特定の利用内容の分類に適用可能なクエリの着目点として、以下に限定されるものではないが、サーチした旅行者数、旅行する大人または子供の人数、旅行の時間および日付、旅行の期間、リクエストされた販売業者またはブランド（たとえば航空会社、ホテル、チェーン等）、出発地または到着地、ならびに旅行のタイプ（たとえば片道、複数都市、往復、ノンストップ、ワンストップ、マルチストップ等）が挙げられる。たとえば単独旅行者は、連れ立って旅行する複数の人達よりも、ビジネス旅行者として分類される可能性が高い、とすることができる。さらに別の例として、週末を含む旅行は、ビジネス旅行よりもレジャー旅行または休暇旅行として分類される可能性が高い、とすることができる。同様に、ノンストップフライトは、ワンストップフライトまたはマルチストップフライトよりも、ビジネス旅行に該当する可能性が高い、とすることができる。さらに別のクエリとして、たとえば熱帯など特定の行先に対するクエリは、休暇旅行として分類される可能性が高い、とすることができる。

利用内容情報の分類をさらに、利用者のアクティビティまたは利用者のプロフィルデータに基づくものとすることができる。たとえば、何日間にもわたりかなり何回もサーチを最近実行した利用者は（たとえばお金の節約および旅行日程の柔軟性を望むことが最近のアクティビティからわかるならば）、レジャー旅行者または休暇旅行者として分類される可能性が高い、とすることができる。これとは逆に、単日でサーチしかつ比較的すぐに旅行アイテムを入手した旅行者は（たとえば旅行者のビジネスが旅行アイテムの費用を賄っているならば）、ビジネス旅行者として分類される可能性が高い、とすることができる。同様に、異なる多数の旅行サービスを最近訪れた旅行者は、ビジネス旅行者よりもレジャー旅行者または休暇旅行者である可能性が高い、とすることができる。いくつかの実施形態によれば、旅行者のプロフィルデータを使用して、旅行者によるアクティビティを分類することもできる。たとえば、収集履歴から同じ場所への、および同じ場所からのフライトが繰り返されていることがわかれば、その利用者のアクティビティはビジネスのアクティビティである可能性が高い、とすることができる。同様に、収集履歴から熱帯の様々な多数の場所へ頻繁に旅行していることがわかれば、旅行者のアクティビティは休暇旅行またはレジャー旅行と分類される可能性が高い、とすることができる。

したがって利用内容監視モジュール１５８を、（４）において利用内容情報の各項目（たとえばサブミットされた各サーチクエリまたは旅行アイテム入手）を、それら自身のアクティビティに基づき、たとえば結果として所定のサーチを発生させるようなサブミットされたクエリまたは旅行アイテム入手などに基づき、１つまたは複数のカテゴリに分類するように構成することができる。利用内容情報を１つまたは複数のカテゴリにまとめることによって、旅行サービス１５０は今後の旅行者に対し、それらの旅行者のニーズに特に的を絞った情報を提供できるようになる。たとえば、「ビジネス」カテゴリのクエリをサブミットした旅行者には、希望する「ビジネス」旅行プランを満たすことを意図した推奨旅行パッケージを呈示することができる。さらに、利用内容情報を１つまたは複数のカテゴリにまとめることによって、リターンされる利用内容データ量が低減されることで（たとえば推奨旅行パッケージの生成などのための）関連する利用内容情報の迅速な選択を容易に行わせることができるようになる。

利用内容情報を処理して分類した後、この種の利用内容情報を記憶させるために、（５）において利用内容情報データストア１６４に伝送することができる。あとで詳しく説明するように、旅行者コンピューティングデバイス１１０に呈示するための推奨旅行パッケージを生成する目的で、パッケージ推奨モジュール１６０などのような旅行サービス１５０の別の観点によって、この種の利用内容情報を用いることができる。

次に図３を参照しながら、旅行者コンピューティングデバイス１１０の利用者向けに希望する旅行プランを推定し、推定された旅行プランに基づき推奨旅行パッケージを生成するための、例示的なインタラクションについて説明する。詳しくは、（１）において旅行者コンピューティングデバイス１１０は、ユーザインタフェースモジュール１５６に対し旅行アイテムに対するクエリをサブミットすることができる。いくつかの事例において、サブミットされるクエリを明示的なものとすることができる。たとえば旅行者コンピューティングデバイス１１０は、所定の基準にマッチするアイテムに関する情報を具体的にリクエストすることができる。別の事例において、サブミットされたクエリを暗黙的なものとすることができ、あるいは別の言い方をするならば（たとえば旅行サービス１５０内の利用者アクティビティに少なくとも部分的に基づいて）推定されたものとすることができる。たとえば利用者は、複数の日付についてワシントン州シアトル行きのフライトに関する情報を閲覧するかもしれない。このような事例では、利用者はそれら複数の日付の期間中のワシントン州シアトルのホテルにも関心がある可能性がある。このためワシントン州シアトルのホテルに対するクエリを推定することができ、このクエリに応じて推定された旅行プランに基づき生成された推奨パッケージを、利用者に呈示することができる。したがってここでは、明示的なクエリを挙げながら実施形態について説明することになるけれども、明示的なクエリ、暗黙的なクエリまたは推定されたクエリに基づいて、推奨を呈示することができる。また、図３のインタラクションについては、単一のクエリを挙げながら説明するけれども、旅行者コンピューティングデバイス１１０の複数のクエリに関して、図３のインタラクションを行ってもよい。たとえば図３のインタラクションとして、旅行者コンピューティングデバイス１１０から短期間のうちにまたは同時にサブミットされた複数のクエリを分析することが挙げられる。さらにたとえば図３のインタラクションとして、旅行者コンピューティングデバイス１１０から長期間にわたってサブミットされた、たとえば旅行サービス１５０による複数のインタラクティブセッションにわたってサブミットされた、複数のクエリを分析することが挙げられる。たとえば、この種のクエリに基づき推定された希望旅行プランをさらに精密なものとする目的で、複数のクエリの分析が役立つかもしれない。

図１を参照しながら既に説明したように、ユーザインタフェースモジュール１５６を、受け取ったクエリまたはさもなくば求められたクエリを解析して、クエリに基づき複数の旅行アイテムを決定し、それらの旅行アイテムに関する情報を旅行者コンピューティングデバイス１１０にリターンするように構成することができる。クエリに基づく旅行アイテムの検索は当業者に一般に知られているので、図３を参照しながらこの種の検索については説明しない。なお、図３には示されていないけれども、図２を参照しながら既に説明したサブミットされたクエリに関する利用内容情報を生成するように、ユーザインタフェースモジュール１５６を構成することができる。利用内容情報の生成に関するインタラクションについては既に詳しく説明したので、これに関する説明は図３に関しては繰り返さない。

本発明の観点によれば、ユーザインタフェースモジュール１５６が（２）において、パッケージ推奨モジュール１６０に対し複数の推奨パッケージをリクエストすることができる。いくつかの実施形態によれば、ユーザインタフェースモジュール１５６を、旅行者コンピューティングデバイス１１０に関してパッケージ推奨モジュール１６０へ、付加的な情報を渡すように構成することができ、たとえば識別された旅行者コンピューティングデバイス１１０またはサブミットされたクエリの詳細を渡すように構成することができる。別の実施形態によれば、パッケージ推奨モジュール１６０を、旅行者コンピューティングデバイス１１０に関する情報を検索するように構成することができ、または利用内容情報データストア１６４のような択一的な情報源からサブミットされたクエリを検索するように構成することができる。これについては、あとで詳しく説明する。

推奨パッケージに対する要求を受け取った後、パッケージ推奨モジュール１６０は、推奨パッケージの生成に役立つ情報を検索することができる。具体的には（３′）においてパッケージ推奨モジュール１６０は、利用内容情報データストア１６４に対し利用内容情報をリクエストすることができる。他方、利用内容情報データストア１６４は、リクエストされた利用内容情報を（４′）においてリターンすることができる。１つの実施形態によれば利用内容情報に、旅行者コンピューティングデバイス１１０のインタラクションに関するデータを含めることができ、たとえばサブミットされたクエリに関するデータおよび／または以前にサブミットされた複数のクエリに関するデータを含めることができる。あとで述べるようにこれらのクエリを活用して、旅行者コンピューティングデバイス１１０の希望する旅行プランを推定することができる。さらに利用内容情報に、推定旅行プランに基づき推奨パッケージを生成するために用いられる付加的な情報を含めることができる。たとえば利用内容情報に、他の利用者により実行されたサーチに関するデータ、それらのサーチに付随するコストまたはタイミングの情報、旅行者コンピューティングデバイス１１０または他の利用者による旅行アイテムの入手記録等を含めてもよい。

これらに加え（３″）において、パッケージ推奨モジュール１６０は旅行者プロフィルデータストア１６６に対し、旅行者コンピューティングデバイス１１０に該当する旅行者プロフィルデータをリクエストすることができる。他方、旅行者プロフィルデータストア１６６は、リクエストされたプロフィルデータをパッケージ推奨モジュール１６０へ伝送することができる。あとで説明するように、利用者の希望する旅行プランまたはそのような希望旅行プランの観点を推定するために、旅行者プロフィルデータを少なくとも部分的に用いることができる。たとえば、旅行者プロフィルデータを用いて、旅行者コンピューティングデバイス１１０がある特定の目的（たとえばビジネス、レジャー、ファミリー等）で旅行するためのものであるらしいということを、または特定のクラスのサービス（デラックス、エコノミー等）を望んでいるらしいということを、判定することができる。

リクエストされた利用内容情報と旅行者プロフィルデータとを受け取った後、パッケージ推奨モジュール１６０は、利用内容情報と旅行者プロフィルデータを用いて、旅行者コンピューティングデバイス１１０の希望旅行プランを推定することができる。既述の通り希望旅行プランを、旅行者コンピューティングデバイス１１０によって望まれる旅行アイテムの組み合わせを求めるために用いられる任意の基準セットに相当するものとすることができる。具体的には希望旅行プランを、旅行を希望する日、旅行期間、旅行地、または特定の希望するアクティビティ（たとえば特定の地上サービス）から成るセットに相当するものとすることができる。さらに希望旅行プランに、１つまたは複数の旅行アイテムのセレクションに対する付加的な基準を含めることができ、たとえばコストまたは移動時間を最低限に抑える希望、特定のカテゴリ（たとえばデラックス、エコノミー、ファミリー、フレンドリー等）内で旅行アイテムを入手する希望などを含めることができる。

１つの実施形態によれば、希望旅行プランを、指定期間内に旅行者コンピューティングデバイス１１０によりサブミットされたすべての旅行クエリに対し、最も緩められた制約を求めることによって決定することができる。たとえば旅行者コンピューティングデバイス１１０が、２０１４年１月１日に出発し２０１４年１月７日に帰着するフロリダ州マイアミ行きフライトに対する最初のクエリをサブミットし、さらに２０１４年１月８日〜２０１４年１月１５日までのフロリダ州マイアミのホテルに対するクエリもサブミットしたものとする。サブミットされたこれらのクエリに基づきパッケージ推奨モジュール１６０は、旅行者コンピューティングデバイス１１０を使用している旅行者は、２０１４年１月１日〜２０１４年１月１５日までのいずれかの時点で、フロリダ州マイアミへの旅行を希望している、と判定できる。さらにパッケージ推奨モジュール１６０は、旅行者はフロリダ州マイアミで１週間過ごすことを望んでいる、と判定できる。さらに別の例を挙げると、旅行者コンピューティングデバイス１１０は、フロリダ州マイアミの指定距離内にある複数の空港へ向かうフライトに対するクエリをサブミットしたものとする。この場合、パッケージ推奨モジュール１６０は、旅行者は希望旅行プランを満たすために複数の空港への移動を望んでいる、と推定することができる。これとは逆に、旅行者コンピューティングデバイス１１０が、近距離内に選択肢となり得る複数の空港が存在しているにもかかわらず、ある１つの特定の空港に向けられた複数のクエリを行っているならば、パッケージ推奨モジュール１６０は、旅行者がその特定の空港への旅行を望んでいる、と推定する可能性がある。

別の実施形態によれば、希望旅行プランの観点を、複数のクエリから成るサブセットに基づき決定することができる。たとえば、旅行者コンピューティングデバイス１１０が第１の都市へ向かうフライトに対するクエリをサブミットし、かつその第１の都市の近郊にある第２の都市における宿泊施設に対するクエリをサブミットしたものとする。この事例では、パッケージ推奨モジュール１６０は、第１の都市へのフライトに対するクエリがサブミットされているにもかかわらず、旅行者は第２の都市への旅行を望んでいる、と推定する可能性がある。具体的には、パッケージ推奨モジュール１６０は、宿泊施設に対するサーチの方がフライトに対するサーチよりも希望旅行地をいっそう強く表している、と判定することができる。いくつかの実施形態によれば、パッケージ推奨モジュール１６０は、希望旅行プランの特定の観点を求めるために、各サーチの特徴を重み付けることができる。たとえば、希望旅行地の確率を、サブミットされた各クエリ内における場所の重み付け平均に基づくものとすることができる。重み付けを、たとえばサブミットされたクエリが正確な希望旅行地を表す見込みに基づくものとすることができる。

さらに多くの実施形態によれば、希望旅行プランの観点を、旅行者コンピューティングデバイス１１０に関する付加的な情報に基づき決定することができ、（たとえば受け取った利用内容情報および／または受け取った旅行者プロフィルデータにおいて反映されているような）旅行者コンピューティングデバイス１１０の過去の収集などに基づき決定することができる。たとえば、旅行者コンピューティングデバイス１１０がフロリダ州マイアミ行きのフライトに対するクエリをサブミットしたものとする。さらに、旅行者コンピューティングデバイス１１０に対応づけられた旅行者が、フロリダ州マイアミ行きの複数のフライトと、それに合わせてフロリダ州ノースマイアミビーチの宿泊施設を、以前に購入しているものとする。このような関連があるがゆえに、パッケージ推奨モジュール１６０は、旅行者が希望するのはフロリダ州ノースマイアミビーチまで行くことである、と想定する可能性が高い。あとで説明するように、このような希望目的地を、たとえばフロリダ州ノースマイアミビーチまで行くための代替となる空港たとえばフォートローダーデール空港を示唆するために用いることができる。さらにたとえば、希望旅行プランの観点を、旅行者の所在地など旅行者に関する別の情報に基づき決定することができる。たとえば、自身の目下の所在地と同じ都市内の宿泊施設に対してサーチを行っている旅行者は、おそらく宿泊施設に付随してフライトまたは地上移動手段を希望する可能性がない。旅行者の所在地を、たとえば旅行者コンピューティングデバイス１１０のアドレス（たとえばインターネットプロトコル（ＩＰ）アドレス）に基づくものとすることができる。

さらに、旅行者コンピューティングデバイス１１０に関する情報が、希望旅行プランの付加的な観点を表すことができ、たとえば旅行者がビジネスの目的で旅行するのかレジャーの目的で旅行するのかの傾向、あるいは単独で旅行するのか家族で旅行するのかの傾向などを表すことができる。一般的には、旅行者が上述のようなビジネス旅行の履歴を有していれば、パッケージ推奨モジュール１６０はビジネス目的で旅行すると想定する可能性が高い。さらに、旅行者コンピューティングデバイス１１０に関する情報が、購入したサービスのクラス（たとえばデラックス旅行アイテムであるのかエコノミー旅行アイテムであるのか）を反映している可能性がある。特定のクラスの旅行アイテムの購入履歴に基づき、パッケージ推奨モジュール１６０は、旅行者が希望するのはそのサービスクラスのアイテムであると、と推定することができる。

さらにいくつかの実施形態によれば、希望旅行プランの観点を、旅行者コンピューティングデバイス１１０によりサブミットされる１つまたは複数のクエリの分類に基づき、求めることができる。具体的には、旅行者が（たとえば週末滞在、熱帯の行先等に基づき）レジャー旅行として分類されたクエリをサブミットしたならば、パッケージ推奨モジュール１６０は、旅行者がレジャー旅行プランを希望している、と推定する可能性が高い。同様に、旅行者がビジネス旅行として分類されたクエリをサブミットしたならば、パッケージ推奨モジュール１６０は、旅行者がビジネス旅行プランを希望している、と推定する可能性が高い。クエリの分類については、図２を参照しながら詳しく説明したので、図３を参照しながら説明を繰り返さない。

当業者には自明のとおり、希望旅行プランによって上述の複数の観点のいずれかを組み合わせることができる。たとえば、希望旅行プランの日付を、旅行者がサブミットした１つまたは複数のクエリに基づき決定することができる一方、希望旅行プランの分類を、旅行者のプロフィルデータに基づくものとすることができる。希望旅行プランの所定の観点が、２つ以上のファクタ（たとえばサーチクエリの分類ならびに購入履歴）によって影響を受ける場合、希望旅行プランの観点を決定するために、各ファクタを重み付けることができる。したがって希望旅行プランを、上述の任意の固有の観点に基づいて、またはこの種の観点の任意の組み合わせに基づいて、推定することができる。さらに希望旅行プランを、付加的な基準または択一的な基準に基づき推定することができる。

希望の旅行が決定された後、パッケージ推奨モジュール１６０は（６）において、希望旅行プランに対応する推奨パッケージを生成することができる。１つの実施形態によれば、パッケージ推奨モジュール１６０は、旅行アイテムの組み合わせに対するクエリとして、推奨パッケージを生成することができる。たとえば推奨パッケージを、特定期間内のフライトと宿泊施設のサーチの推奨に対応させることができる。別の実施形態によれば、パッケージ推奨モジュール１６０は、旅行者コンピューティングデバイス１１０に呈示するために旅行アイテムの組み合わせを選択するための推奨クエリを利用することができる。たとえばパッケージ推奨モジュール１６０は、希望旅行プランを満たす旅行パッケージをリターンさせるように意図されたクエリを生成することができ、１つまたは複数の旅行パッケージをリターンさせるために、そのクエリを実行することができる。ついでそれらの旅行パッケージを、旅行者コンピューティングデバイス１１０にリターンすることができる。

１つの実施形態によれば、旅行パッケージのための推奨クエリの生成には、希望旅行プランに対応する複数の順列の生成を含めることができる。たとえば、旅行者が２０１４年１月１日から２０１４年１月７日までの間、３日から４日の旅行を希望しているならば、２０１４年１月１日から２０１４年１月７日の間の旅行日程の組み合わせごとに、想定可能なサーチを生成することができる。同様に、旅行者が複数の空港を利用できる場所への旅行を希望しているならば、パッケージ推奨モジュール１６０は、可能性のある各空港へのフライトおよび／またはそれらの空港からのフライトに対するサーチを生成することができる。さらに希望旅行プランに、可能性のある日付の範囲と可能性のある複数の場所の双方が含まれているならば、それら可能性のある日付と場所を満たすことのできる複数の組み合わせに対するサーチを生成することができる。

さらにいくつかの実施形態によれば、推奨クエリの生成に、希望旅行プランを満たすことのできる付加的な旅行アイテムの決定を含めることができる。たとえば、ある１つの特定の空港へのフライトと、その空港から遠いホテルに対するサーチを、旅行者がサブミットしたならば、パッケージ推奨モジュール１６０は、希望旅行プランを満たすためには地上輸送が必要となるであろう、ということを判定できる。この場合にはパッケージ推奨モジュールは、利用可能な地上輸送オプションを含むクエリを生成することができる。

さらに複数の実施形態によれば、付加的な推奨サーチを生成する目的で、希望旅行プランに付随する１つまたは複数の制約を緩和させることができる。たとえば、希望旅行プランに短い範囲の日付が含まれているならば、指定されたその期間をちょうど外れた日付に対して、推奨サーチを生成することができる。いくつかの実施形態によれば、たとえかなり長期の範囲にわたる日付を利用者が指定したとしても、基準のこの種の緩和を生じさせることができる。さらに基準の緩和は日付に限られるものではなく、場所、サービスクラス、旅行アイテムの評価、希望コストなど、どのような基準であっても含めることができる。いくつかの事例によれば、希望場所に物理的に近い代替の場所を選ぶことによって、地理的位置を緩和させることができる。別の事例によれば、距離にかかわらず希望場所と似ている選択的な代替場所によって、地理的位置を緩和させることができる。たとえば、旅行者が特定の熱帯の休暇先へ旅行することを希望しているのであれば、本来指定されている行先までの距離にかかわらず、代替となる熱帯の休暇先に対して付加的なサーチを生成することができる。

希望旅行プランに対応する１つまたは複数の基準を緩和させることによって、付加的なサーチを生成することができ、このようにすることで、希望旅行プランの別の基準（たとえば低価格など）を満たす旅行パッケージを探し当てる可能性が高まる。

さらに、あとで詳しく説明するようにパッケージ推奨モジュール１６０を、１つまたは複数の生成されたサーチをランク付けるように構成することができる。生成されたサーチのランキングとして挙げられるのはたとえば、サーチが希望旅行プランにどの程度密接に一致しているのかのランキング、（たとえばサーチ実行またはサーチ関連の履歴データに基づく）サーチに対応する旅行パッケージのコスト、サーチに対応する旅行パッケージの総移動時間、サーチに対応する旅行アイテムのクラス、または（たとえば旅行サービス１５０の他の利用者に基づく）サーチに対応する旅行アイテムのランク付けまたはレビュー、あるいはサーチ実行の人気または頻度、旅行サービス１５０の他の利用者における同様のサーチである。ランキングが役立つ可能性があるのはたとえば、多数のサーチが希望旅行プランを満たす可能性がある場合である。具体的には、可能性のあるすべての推奨サーチではなく、限度内の個数の高ランク推奨サーチだけを、旅行者コンピューティングデバイス１１０に呈示することができる。

１つの実施形態によれば、パッケージ推奨モジュール１６０によって生成された推奨サーチを、（７）においてユーザインタフェースモジュール１５６に推奨パッケージとしてリターンすることができる。他方、ユーザインタフェースモジュール１５６は、推奨パッケージを旅行者コンピューティングデバイス１１０へ送信することができる。このようにして旅行者コンピューティングデバイス１１０に対し、旅行者の希望する旅行プランを満たす旅行パッケージをリターンする見込みのあるサーチについて通知することができる。推奨サーチの表示に関する１つの例示的なインタフェースについては、あとで図４Ａを参照しながら説明する。

さらに別の実施形態によれば、パッケージ推奨モジュール１６０（または旅行サービス１５０の他のコンポーネント）は、旅行者コンピューティングデバイス１１０に推奨サーチを提供する代わりに、またはそれに加えて、推奨されたサーチに対応する１つまたは複数の旅行パッケージを探し出すための推奨サーチを利用することができる。ついでそれらの旅行パッケージを、旅行者コンピューティングデバイス１１０にリターンすることができる。このようにすれば旅行者コンピューティングデバイス１１０に対し、希望旅行プランを満たす見込みのある１つまたは複数の旅行パッケージを呈示することができる。推奨旅行アイテムの表示に関する１つの例示的なインタフェースについては、あとで図４Ｂを参照しながら説明する。

図４Ａおよび図４Ｂを参照するとこれらの図面には、旅行者コンピューティングデバイス１１０に対し推奨を渡すためのユーザインタフェースの具体例が描かれている。図４Ａおよび図４Ｂに示されているように、ユーザインタフェース４００および４５０によって旅行者コンピューティングデバイス１１０は、旅行クエリをサブミットできるようになり、サブミットされた旅行クエリに応じて入手可能な旅行アイテムを閲覧できるようになり、さらにサブミットされた旅行クエリに少なくとも部分的に基づき生成された推奨旅行パッケージを閲覧できるようになる。具体的にはユーザインタフェース４００および４５０を、ユーザインタフェースモジュール１５６によって生成することができ、プロバイダのコンピューティングデバイス１１０上でブラウザプリケーションなどのアプリケーションによって、旅行者コンピューティングデバイス１１０上に表示させることができる。ここでは２つの図面で示されているけれども、当業者であれば自明であるとおり、ユーザインタフェース４００および４５０が、単一のインタフェースにおける２つの可能な形態を表すものとすることができる。さらに当業者に自明であるとおり、旅行者コンピューティングデバイス１１０を、個々のインタフェースとの対話（たとえばインタフェース内の様々な入力の選択など）によって、各形態を閲覧できるようなものとすることができる。たとえば図４Ａに示されているユーザインタフェース４００によって、１番目の旅行クエリのサブミット後などのような第１の時点において、旅行者コンピューティングデバイス１１０に呈示される１つの可能なユーザインタフェースを表すことができる。同様に、ユーザインタフェース４５０によって、２番目の旅行クエリのサブミット後などのような第２の時点において、旅行者コンピューティングデバイス１１０に呈示される１つの可能なユーザインタフェースを表すことができる。

図４Ａを参照すると、図示されているユーザインタフェース４００によって旅行者は、旅行者コンピューティングデバイス１１０を介して、フライトなどのような第１のタイプの旅行アイテムに対するクエリをサブミットすることができる。図示のユーザインタフェース４００には、旅行サービス１５０を参照していることを表すタイトル表示４０２すなわち「旅行サービス」と、目下旅行サービス１５０を訪れている旅行者への挨拶４０４が含まれている。図示の例では、旅行者の身元は"Tom Traveler"であるとされている。ユーザインタフェース４００にはさらにナビゲーションパネル４０６が含まれており、このパネルは旅行者に対し、旅行サービス１５０によって提供されている他の様々なフィーチャを示すものである。具体的には、ナビゲーションパネル４０６内のテキスト構成部分を、対話型リンクに相当させることができ、これが選択されるとユーザインタフェースが変更され、または変化する。ここで挙げた例によれば、Tom Travelerはリンク４０８すなわち「フライト」を選択している。この選択に基づきユーザインタフェースモジュール１５６は、ユーザインタフェース４００のためのコンテンツをリターンしている。Tom Travelerは、ナビゲーションパネル４０６内の択一的なリンクを選択することにより、択一的なユーザインタフェースを閲覧可能な状態となる。たとえば、Tom Travelerは「ホテル」のリンク４５２を選択することにより、図４Ｂのユーザインタフェース４５０を閲覧することができる。これについてはあとで説明する。

ユーザインタフェース４００を利用することによって、旅行者コンピューティングデバイス１１０は旅行サービス１５０に対し、関連旅行アイテムを特定するための基準を含む旅行クエリをサブミットすることができる。具体的には、ユーザインタフェース４００のサーチ部分４１０を使って、この種のクエリをサブミットすることができる。図３に示されているように、サーチ部分４１０によって旅行者は、該当するフライト旅行アイテムに対する基準を指定することができ、たとえば出発地、出発日、到着地、到着日などを指定することができる。図３には、サーチ基準の限られたセットが示されているけれども、当業者であれば自明であるとおり、旅行者コンピューティングデバイス１１０によって付加的なまたは代替となる基準を指定することができ、以下に限定されるものではないが、出発時間または到着時間、フライト運行業者、移動のタイプ（たとえばノンストップ、ワンストップ、ノンストップなど）、価格などを指定することができる。つまり図４Ａに関連して挙げられている基準は、例示を意図したものであり、それらに限定されるものではない。

この例示的なユーザインタフェース４００において、サーチ部分４１０に表示されている基準は、旅行者コンピューティングデバイス１１０によってサブミットされた先行のサーチを表すものとすることができる。したがって結果部分４１２内には、旅行アイテムリスト４１６を含む複数の該当旅行アイテムが示されている。旅行アイテム４１６のリスト内における個々の旅行アイテムはそれぞれ、旅行者が収集のために利用可能な旅行アイテムに相当する。さらに個々の旅行アイテムはそれぞれ、サーチ基準部分４１１により表されているサブミットされたサーチ基準に基づき選択されたものである。ここに挙げられている例の場合、個々の旅行アイテム各々は、２０１４年１月１日水曜日に出発し、２０１４年１月７日火曜日に帰着するワシントン州シアトル−フロリダ州マイアミ間の往復フライトに該当する。

これらに加えユーザインタフェース４００には、推奨クエリ４２６を含む推奨表示部分４１４が含まれている。推奨クエリ４２６は、Tom Travelerが希望する旅行プランの推定に基づき、旅行サービス１５０によって生成された推奨を表すことができる。一例として旅行サービス１５０は、（たとえばサーチ判定部分４１１において表されている）サブミットされたクエリを利用し、たとえばTom Travelerの購入履歴やプロフィル情報など、さらに別の情報も加えて、Tom Travelerの希望旅行プランを推定することができる。いくつかの実施形態によれば、旅行サービス１５０は１つまたは複数の旅行プラン推定の理由４２２および４２４を表示させることができる。たとえば理由４２２は、目下実行されたサーチに部分的に基づいて希望旅行プランが決定されたことを表す一方、理由４２４は、目下の利用者の収集履歴に少なくとも部分的に基づいて希望旅行プランが決定されたことを表す。ここでは、理由を提供する例示的なインタフェースについて論じているが、理由のどのような組み合わせであっても、旅行者コンピューティングデバイス１１０へ提供することができる。たとえばユーザインタフェース４００（または代替となるユーザインタフェース）は、旅行サービス１５０において実施された最近のサーチの完全な履歴を（たとえば時系列で）表示することができる。理由４２２および４２４の各々は、旅行プラン推定のベースとなる理由を削除するなど、個々の理由に基づく希望旅行プランの推定を変更するために、利用者によって選択することができる。

さらに旅行サービス１５０は、希望旅行プランを満たす旅行パッケージをリターンする見込みのある複数の推奨サーチを生成することができる。これらのサーチのうち１つまたは複数を、推奨表示部分４１４を介してTom Travelerに呈示することができる。さらに推奨表示部分４１４は、推定された旅行プランに関する情報を提供することもできる。たとえば推奨表示部分４１４は、呈示された推奨が「ノースマイアミビーチ」と推定された行先４１８に基づくものである、ということを表すことができる。このように推定された行先を、たとえばTom Travelerによりサブミットされた以前のサーチに基づくものとしてもよいし、Tom Travelerの収集履歴に基づくものとしてもよい。さらに推奨表示部分４１４は、呈示された推奨が「ビジネス」旅行と推定された目的４２０に基づくものである、ということを表すことができる。推奨を変更するために、推定された行先４１８および推定された目的４２０の各々を、利用者が選択することができる。たとえばTom Travelerがビジネスのために旅行を計画しているのでなければ、推定された目的に対応するリンクを選択することによって、推定された目的４２０を変更することができる。

推奨表示部分４１４にはさらに、推奨サーチに対応するサーチ情報４２６が含まれている。詳しく述べるとサーチ情報４２６によって、旅行サービス１５０が（たとえばフロリダ州マイアミではなく）フロリダ州フォートローダーデール行きのフライトと、ノースマイアミビーチのホテルと、レンタカーとについて、サーチを推奨している、ということが表される。この種の推奨サーチを、推定旅行プランに基づき旅行サービス１５０によって生成することができる。たとえば、Tomはフロリダ州ノースマイアミビーチへビジネスの目的で旅行する、と旅行サービス１５０が推定しているので、空港とノースマイアミビーチとの間の移動時間が最小になるよう、推奨サーチが選択されるようにすることができる。さらに旅行サービス１５０は、ビジネス旅行者はフライトコストよりもフライトを入手できることを強く望んでいる、と想定することができので、フライト入手の可能性が最大限になるよう、推奨サーチを選択することができる。変更されたサーチの潜在的な利点を、旅行者にわかりやすく伝達できるようにする目的で、推奨サーチの呈示に対する１つまたは複数の理由４２７を、ユーザインタフェース４００内で推奨サーチ情報４２６のそばに呈示することができる。いくつかの実施形態によれば、この種の理由４２７を、推奨サーチの生成またはランク付けに用いられた指標に対応させることができる。

さらにユーザインタフェース４００は、Tom Travelerが推奨サーチを実行できるようにする推奨サーチ選択入力４２８を含むことができる。たとえば、入力４２８を選択することによって旅行者コンピューティングデバイス１１０に対し、フォートローダーデール行きのフライトとノースマイアミのホテルとレンタカーとを含む旅行パッケージに対するクエリをサブミットさせることができる。この種のサーチを実行することによりTom Travelerは、自身が希望する旅行プランを満たす旅行アイテムの組み合わせを特定することができる。

次に図４Ｂを参照しながら、たとえばホテルまたはロッジなど第２のタイプの旅行アイテムに対するクエリをサブミットするための、第２のユーザインタフェース４５０について説明する。既に述べたとおりユーザインターフェス４５０が、図４Ａのユーザインタフェース４００の変更されたバージョンを表すようにしてもよい。たとえばユーザインタフェース４５０を、図４Ａの「ホテル」リンク４５２の選択に応答して、旅行者コンピューティングデバイス１１０に呈示させることができる。図４Ｂの多くの表示要素は図４Ａの表示要素と同様であり、それらの要素の参照符号は図４Ａと図４Ｂとで同じものが用いられているため、図４Ｂを参照しながらそれらの要素について詳しくは説明しない。

１つの実施形態によれば、図４Ｂのユーザインタフェースを、たとえばホテルまたは他の宿泊施設に対するクエリなど、Tom Travelerによる第２のクエリのサブミットに応答して表示させることができる。具体的には、Tom Travelerは、図４Ａのユーザインタフェース４００内では自身の旅行プランを満たす旅行パッケージを特定できなかった可能性があり、したがってホテルまたは宿泊施設に対し第２のクエリをサブミットする可能性がある。このためユーザインタフェース４５０は、２０１４年１月１日から２０１４年１月７日までのフロリダ州キーラーゴの宿泊施設をTom Travelerがサーチしたことを示すサーチ基準４１１を表すことができる。ユーザインタフェース４５０はさらに、サーチ基準４１１に合致する複数の旅行アイテム４５４〜４５８を含むことができる。たとえば旅行アイテム４５４は、「ホテルＡ」が一泊２０９＄の料金で提供されていることを表すことができる。同様に、旅行アイテム４５６および４５８によって、「ホテルＢ」が一泊＄１８９の料金で、「ホテルＣ」が一泊＄２５５の料金で、それぞれ提供されていることを表すことができる。ユーザインタフェース４５０にはさらに、絞り込みサーチコントロール４１０などのような、旅行アイテムに関する情報との対話のための１つまたは複数のコントロールを含めることができる。たとえば、絞り込みサーチコントロール４１０の部分によって、ホテル名または星によるランク付けにより、提供されているホテルを利用者が絞り込むことができる。当業者に自明であるとおり、利用者が複数の付加的なコントロールを使えるようにすることができる。

これらに加えユーザインタフェース４５０には、推奨旅行パッケージ４６０を含む推奨表示部分４１４が含まれている。この旅行パッケージ４６０は、Tom Travelerが希望する旅行プランの推定に基づき、旅行サービス１５０によって生成された推奨を表すことができる。具体的には、旅行サービス１５０は、フロリダ州キーラーゴの宿泊施設に対しサブミットされたばかりのクエリ（たとえばサーチ基準部分４１１に表されているようなクエリ）を、フロリダ州マイアミ行きのフライトに対し先行してサブミットされたクエリと共に利用して、Tom Travelerがフロリダキーズでの休暇を望んでいる、ということを推定することができる。推定された旅行プランに関する情報をたとえば、推定された行先４１８および推定された目的４２０のところに表示させることができる。このことに加え、図４Ａを参照しながら説明したように、インタフェース４５０は、推定された旅行プランに関する１つまたは複数の理由を呈示することができる。たとえば、目下のユーザインタフェース４５０には、理由４６２と理由４６４とが表示されており、これらの理由は、現在の旅行プランは、フロリダ州キーラーゴのホテルに対する現在のサーチと、（図４Ａを参照しながら既に説明した）フロリダ州マイアミ行きのフライトに対する先行のサーチとに、少なくとも部分的に基づいた、ということを示すものである。

上述の推定に基づき、旅行サービス１５０は、希望旅行プランを満たす見込みのある複数の推奨旅行パッケージを生成することができる。たとえば旅行サービス１５０は、推奨情報４６０のところに表されているように、キーウェスト行きのフライトとレンタカーとイスラモラダの宿泊施設とによって、フロリダキーズへの休暇という条件を満たすことができる、と判定できる。表示された推奨を、推定旅行プランに相応する基準に基づき生成することができる。たとえば、Tomはフロリダキーズへレジャーの目的で旅行する、と旅行サービス１５０が推定しているので、すべての旅行アイテムの総コストが最小になるように、推奨サーチが選択されるようにすることができる。さらに旅行サービス１５０が想定できるのは、レジャーの旅行者は、旅行サービス１５０の他の利用者により高くランク付けられているようなアクティビティへ行くことを希望する、ということである。したがって、旅行サービス１５０により推奨される旅行アイテムの特定の組み合わせによって、コストを最小限に抑えながら、それらのアクティビティへ行くことができるように試みることができる。推奨された旅行パッケージの潜在的な利点を、旅行者にわかりやすく伝達できるようにする目的で、１つまたは複数の理由４２７を、ユーザインタフェース４５０内で推奨旅行パッケージ４６０のそばに呈示することができる。いくつかの実施形態によれば、この種の理由４２７を、複数の可能な旅行パッケージのうち推奨される旅行パッケージの生成またはランク付けに用いられた指標に対応させることができる。

さらにユーザインタフェース４５０に、推奨された旅行パッケージに関する詳細をTom Travelerが閲覧できるようにする推奨選択入力４６６が含まれるようにすることができる。入力４６６を選択することによりTom Travelerは、推奨された旅行パッケージに関する特有の情報を閲覧できるようになり、さらに場合によっては、自身が希望する旅行プランの基準を満たす推奨旅行パッケージを収集できるようになる。

これまで図４Ａおよび図４Ｂを参照しながら、例示的なユーザインタフェース４００および４５０について説明してきたが、任意の個数または任意のタイプのインタフェースを介して、利用者に推奨を呈示することができる。たとえば既述のように、クエリは暗黙的なものであってもよく、あるいは別の言い方をすれば、利用者のアクティビティ（たとえば旅行サービス１５０における以前のサービスなど）に基づき推定されたものであってもよい。このため、クエリを判定可能であるどのようなユーザインタフェース内にも、推奨を含めることができる。たとえば、ある特定の都市内のホテルについて情報を閲覧している旅行者は、その都市内での滞在またはその都市近郊での滞在を含む旅行プランに関心がある、と推定することができる。したがって、推定されたこのような旅行プランに少なくとも部分的に基づき推奨を生成し、ホテルに関する情報を含むユーザインタフェース内で呈示することができる。さらにいくつかの実施形態によれば、旅行パッケージの推奨を、別のインタフェースたとえばアプリケーション・プログラミング・インタフェース（ＡＰＩ）などを介して、提供することもできる。つまり、図４Ａおよび図４Ｂのユーザインタフェース４００および４５０はあくまで具体例として示したものであり、これらに限定されるものではない。

次に、推奨旅行パッケージの生成ならびに旅行者コンピューティングデバイス１１０へのそのような推奨の受け渡しについて、図５を参照しながら説明する。たとえば図１に示したパッケージ推奨モジュール１６０によって、図示のルーチン５００を実行することができる。ルーチン５００をブロック５０４から始めることができ、このブロックにおいてパッケージ推奨モジュール１６０は、旅行者コンピューティングデバイス（たとえば図１の旅行者コンピューティングデバイス１１０）により形成された１つまたは複数のクエリに対応する情報を受けることができる。オプションとしてブロック５０５において、パッケージ推奨モジュール１６０はさらに、旅行者プロフィル情報または収集履歴などのような付加的な旅行者情報を受けることができ、この情報を利用して旅行者の希望旅行プランを推定することができる。

旅行者のクエリ情報を受け取った後、パッケージ推奨モジュール１６０は、旅行者のクエリ情報と任意の利用可能な付加的な情報とに基づいて、旅行者の希望旅行プランを推定することができる。図２を参照しながら既に説明したとおり、旅行者の希望旅行プランを、単一の旅行アイテムを求めるための単一の基準セットではなく、旅行者が希望する複数の旅行アイテムの組み合わせを求めるために用いられる基準セットに相当するものとすることができる。一例として、旅行者の希望旅行プランを、２０１４年の６月に熱帯地方へ向かう低コストのレジャー旅行に相当するものとすることができる。さらに別の例を挙げると、旅行者の希望旅行プランを、指定された３つの日程のうち１つの日程による２週間の地中海豪華クルーズに相当するものとすることができる。旅行者がそれぞれサブミットしたクエリは、希望旅行プランに対する基準のサブセット（たとえば複数の可能な日程のうちの１つだけ、複数の希望旅行アイテムの１つだけ）にしか相当しない可能性があるので、旅行者の希望旅行プランを推定することにより、パッケージ推奨モジュール１６０が、旅行者の希望旅行プランを満たす付加的な推奨クエリを生成できるようになる。

図２を参照しながら既に説明したように、いくつかの実施形態によれば、旅行者の希望旅行プランに相当する基準セットのすべてまたは一部分を、旅行者がサブミットしたクエリセットに少なくとも部分的に基づいて求めることができる。たとえば、旅行者が複数の日付で旅行アイテムに対するクエリをサブミットしたならば、旅行者の希望旅行プラン内で許容できるように各日付を推定することができ、または複数の日付に基づき日付の範囲を生成することができる。さらに別の例を挙げると、旅行者が複数の場所へ向かうフライトをサーチした場合、旅行者が許容できるような場所をそれぞれ推定することができる。さらに旅行者の希望旅行プランを、たとえばプロフィル情報、旅行アイテム閲覧履歴、旅行アイテム収集履歴、または旅行者の所在情報など、旅行者に関する付加的な情報に基づき決定することができる。たとえば旅行者のプロフィル情報によって（たとえば頻繁に利用する旅行者のためのプログラムまたはメンバープログラムの会員であることを示している等から）、旅行アイテムの１つまたは複数のブランドに対する好みを表すことができる。さらに別の例を挙げると、旅行者の収集履歴によって、最近サーチしたものと類似した旅行アイテムを少なくとも１つ含む、以前に購入した旅行アイテムの組み合わせまたはパッケージを表すことができる。この種の類似性に基づき、旅行者が以前に購入したものと類似した旅行アイテムの組み合わせに関心がある、と推定することができる。さらに旅行者の収集履歴またはプロフィルデータによって、旅行アイテムの特定のタイプまたはクラスを表すことができる。

旅行者の希望旅行プランが決定された後、パッケージ推奨モジュール１６０は、希望旅行プランに基づき１つまたは複数のクエリを生成することができる。詳しくはパッケージ推奨モジュール１６０は、希望旅行プランに対応する基準セットにマッチするものであるが、旅行者コンピューティングデバイス１１０によってまだ実行されていいない、考えられるすべてのクエリ全部を、またはそれらのサブセットを、生成することができる。一例として、推定された旅行プランを、２０１４年１月初旬をフロリダキーズで過ごす休暇に相当するものとすることができる。旅行者コンピューティングデバイス１１０は、２０１４年１月１日出発、２０１年１月８日帰着のフロリダ州マイアミ行きフライトと、フロリダ州キーラーゴの宿泊施設を、以前にサーチしていたかもしれない。しかしパッケージ推奨モジュール１６０は、フロリダ州フォートローダーデール、フロリダ州キーウェスト、またはフロリダ州マイアミの任意の組み合わせへの往復フライトも、希望旅行プランを満たすことができる、と判定することができる。さらにパッケージ推奨モジュール１６０は、フロリダキーズの島々のいずれかの宿泊施設が希望旅行プランを満たすかもしれない、と判定することができる。このような判定をたとえば、可能性のある各旅行アイテムの地理情報（たとえば空港またはホテルの所在地）ならびに希望旅行プランの地理情報（たとえばフロリダキーズにおける休暇）に基づくものとすることができる。

いくつかの実施形態によれば、パッケージ推奨モジュール１６０をさらに、希望旅行プランを満たすのに必要なまたは満たすのに役立つ付加的な旅行アイテムを含むサーチを特定するように構成することができ、これはそのような旅行アイテムを旅行者がサーチしているか否かに関係なく行われる。一例を挙げると、生成されたクエリに、指定された空港行きのフライトのサーチと、その空港から許容限度よりも離れた宿泊施設のサーチとが含まれているならば、パッケージ推奨モジュール１６０は、地上輸送のサーチが含まれるようにクエリを変更することができる。このようにすることで、生成されたクエリごとに特定された旅行アイテムと他の旅行アイテムとの両立を保証することができる。

さらにいくつかの実施形態において、パッケージ推奨モジュール１６０を、希望旅行プランの基準に完全にはマッチしないが、そのような基準にほぼマッチする旅行アイテムに対するクエリを生成するように構成してもよい。たとえばパッケージ推奨モジュール１６０を、希望旅行プランに相応する基準セットに近いがその中にはない日付に対するクエリを生成するように構成してもよい。さらに別の実施形態によれば、パッケージ推奨モジュール１６０を、択一的な場所、サービスのクラス、旅行期間等に対するクエリを生成するように構成することができる。このようにすれば、旅行アイテムの組み合わせに対する旅行者の潜在的なオプションを増やすことができる。なお、この種の生成されたクエリは、１つの観点（たとえば希望する日付）においては希望旅行プランを厳密には満たすことができないけれども、別の観点（たとえば価格）においては希望旅行プランに対しいっそう最適なソリューションを成す可能性がある。

生成されるクエリの個数が多くなる可能性があるので、いくつかの実施形態によれば、クエリが旅行者の興味を惹く見込みの推定に従い、生成されたクエリをランク付けるのが有利になる可能性がある。たとえば、数百のクエリが旅行者の希望する旅行プランに基づき生成されたが、利用者に送信される表示ページ内では許容限度数のクエリしか含めることができない場合、パッケージ推奨モジュール１６０は、最上位にランク付けられた許容限度数のクエリだけを選択して表示させることができる。１つの実施形態によれば、クエリが希望旅行プランに対応づけられた基準セットにどれだけ近いのかに基づき、クエリのランキングを決定することができる。一例を挙げると、旅行プランの希望する日付と完全に一致するクエリを、希望する日付にそのまま一致してはいないクエリよりも高いランクにすることができる。別の実施形態によれば、クエリに対応づけられた旅行アイテムの組み合わせに少なくとも部分的に基づいて、クエリをランク付けることができる。たとえば、ある旅行プランが低コストの希望に関連するならば、低い平均コストの旅行アイテムの組み合わせをリターンするクエリを、高い平均コストをリターンするクエリよりも高くランク付けることができる。クエリに対応づけられるコストを、たとえばそのクエリまたは類似のクエリに対応づけられたコスト履歴情報（たとえば前日に申し込まれた最小コストの旅行パッケージ）を利用することによって、決定することができる。さらに別の例を挙げると、クエリに対応づけられるコストを、旅行サービス１５０においてクエリを実行することに少なくとも部分的に基づいて、決定することができる。具体的には、クエリの実行によって、旅行アイテムに対応づけられたリアルタイムのコストをいっそう正確に表示できるようになる。いくつかの実施形態によれば、旅行者が想定コストをいっそう正確に閲覧できるようにするために、旅行サービス１５０により、クエリに対応づけられたコスト情報を変更することができる。たとえば、旅行サービス１５０は、（たとえば提携、所在地、プロフィルデータ等に基づき）旅行者が利用可能な何らかのディスカウントまたは販売促進を反映させるために、想定コストを変更することができる。

さらにいくつかの実施形態によれば、クエリのランキングを、旅行サービス１５０の他の利用者のアクティビティに基づき生成される情報をベースとすることができる。たとえば、旅行サービス１５０の複数の利用者によって、ある１つの所定のクエリ（またはその所定のクエリに類似したクエリ）が何回も実行されるということは、そのクエリに対応する旅行アイテムに対する要求が高い、ということを表しているといえる。１つの実施形態によれば、頻繁に実施される（たとえば人気の高いクエリ）のランクを下げてもよい。その理由は、人気が高いということは、価格の上昇または利用できる可能性が下がることを表す場合もあるからである。別の実施形態によれば、頻繁に実施されるクエリのランクを高めてもよい。その理由は、人気が高いということは、そのクエリに対応する旅行アイテムが魅力的であることを表している可能性があるからである。

さらに複数の実施形態によれば、希望旅行プランに対応する基準各々を重み付けることができ、生成されたクエリ各々に対し、クエリの個々の観点が重み付けられた基準にどれだけ正確に準拠しているのか、に基づきスコアを割り当てることができる。一例として、希望旅行プランに、低コストの基準と希望する日付の基準が割り当てられている可能性があるが、この場合、低コストの基準を、希望する日付の基準よりも高く重み付けることができる。このように重み付けることで、希望する日付内にはない低コストの旅行アイテムに対応づけられたクエリを、希望する日付内の高コストの旅行アイテムに対応づけられたクエリよりも、いっそう高くランク付けすることができる。この種のランキングを使用することによって、パッケージ推奨モジュール１６０は、希望旅行プランに準拠する旅行アイテムをリターンする見込みが最も高いクエリを特定できるようになる。

生成されたクエリ各々のランキングが決定された後、パッケージ推奨モジュール１６０は、生成された推奨クエリであるか、または推奨クエリに対応する旅行アイテムの組み合わせをリターンするのかを、決定することができる。図４Ａおよび図４Ｂを参照しながら既に説明したように、１つの実施形態によれば、推奨クエリ自体を旅行者コンピューティングデバイス１１０に呈示することができ、推奨されたクエリを選択することにより、旅行サービス１５０においてそのクエリが実行されるようにすることができる。推奨クエリの受け渡しは、たとえば旅行者が特定の推奨サーチの基準を求めることができるようにするために、役立つ可能性がある。したがって、推奨クエリの受け渡しが望まれる場合には、ルーチン５００をブロック５１４において続けることができ、このブロックでは、許容限度数の高ランクのクエリを、（たとえば図４Ａのユーザインタフェース４００を介して）旅行者コンピューティングデバイス１１０にリターンすることができる。その後、ルーチン５００をブロック５２０のところで終了させることができる。

第２の実施形態によれば、推奨クエリに対応する旅行アイテムをリターンすることができる。たとえば旅行サービス１５０を、許容限度数の生成されたクエリを実行し、クエリの結果により得られた１つまたは複数の旅行アイテムを特定するように構成することができる。旅行アイテムの決定は、たとえば旅行者が自身の希望旅行プランを満たす推奨旅行アイテムを、（たとえば旅行者が付加的なクエリを実行する必要なく）じかに選択できるようにするために、役立つ可能性がある。したがって、推奨クエリに対応する旅行アイテムの受け渡しが望まれるならば、ルーチン５００をブロック５１６において続けることができ、そのブロックにおいて、許容限度数の高ランクのクエリを旅行サービス１５０において実行して、クエリに対応する旅行アイテムの組み合わせを特定することができる。ついで、特定されたこの種の旅行アイテムの組み合わせの１つまたは複数を、旅行者コンピューティングデバイス１１０に（たとえば図４Ｂのユーザインタフェース４５０を介して）リターンすることができる。その後、ルーチン５００をブロック５２０のところで終了させることができる。

本明細書で開示した実施形態を参照しながら説明した種々の例示的かつ論理的なブロック、モジュール、ルーチンおよびアルゴリズムのステップを、電子的なハードウェア、コンピュータソフトウェア、またはこれら双方の組み合わせによって実装することができる。ハードウェアとソフトウェアをこのように交換可能であることを明確に示すために、種々の例示的なコンポーネント、ブロック、モジュールおよびステップを、それらの機能に関して一般的に説明してきた。この種の機能をハードウェアとして実装するのかソフトウェアとして実装するのかは、特定の用途と、システム全体に課される設計上の制約とに左右される。既述の機能を、特定の用途ごとに異なる手法で実装してもよいが、そのようにして実装を決定したからといって、そのことにより本発明から逸脱してしまうというものではない。

ここで開示した実施形態に関連する方法、プロセス、ルーチンまたはアルゴリズムを、そのままハードウェアとして、またはプロセッサにより実行されるソフトウェアとして、あるいは両者の組み合わせとして、実現することができる。ソフトウェアモジュールを、ＲＡＭメモリ、フラッシュメモリ、ＲＯＭメモリ、ＥＰＲＯＭメモリ、ＥＥＰＲＯＭメモリ、レジスタ、ハードディスク、リムーバルディスク、ＣＤ−ＲＯＭ、または他の任意の形式の非一時的なコンピュータ読み取り可能な記録媒体に、格納しておくことができる。例示した何らかの記憶媒体をプロセッサに接続して、プロセッサがその記憶媒体から情報を読み出し、かつその記憶媒体に情報を書き込むようにすることができる。別の選択肢として、記憶媒体をプロセッサに組み込むこともできる。また、プロセッサと記憶媒体をASICに組み込み、さらにこのASICを利用者端末機器内に配置することができる。択一的な実施形態として、プロセッサと記憶媒体を、それぞれ別個のコンポーネントとして利用者端末機器に組み込んでもよい。

本明細書で用いた条件付きの語法たとえば「可能である」「可能かもしれない」「してもよい」「してよい」「たとえば」等を用いた意図は通常、特段の言及がないかぎり、あるいはさもなければ文脈で理解されるかぎり、いくつかの実施形態には特定の特徴、要素および／またはステップが含まれているが、他の実施形態にはそれらが含まれていない、ということを表そうというものである。したがってこのような条件付きの語法は、特徴、要素および／またはステップが、１つまたは複数の実施形態にとっていずれにせよ必須である、ということを示唆するものでもないし、あるいは、何らかの特定の実施形態にこれらの特徴、要素、および／またはステップが含まれるのか否か、または実行されるべきであるのか否か、についての判断材料が、書き手が情報を与えたり促したりしようがしまいが、１つまたは複数の実施形態には必ず含まれている、ということを示唆するものでもない。さらに用語「有する」、「含む」、「備える」等は同義であり、包括的に制約なく用いられるものであり、付加的な要素、特徴、行為、動作などを除外しようというものではない。さらに用語「または」は、（排他的な意味ではなく）包括的な意味で用いられており、したがってたとえば一連の要素をつなぐ目的で用いられる場合には、用語「または」は、それら一連の要素の１つ、いくつか、あるいはすべてを意味するものである。

「Ｘ，ＹまたはＺの少なくとも１つ」といった離接的な語法が一般に表すのは、特段の言及がないかぎり、さもなければ用いられている文脈で理解されるかぎり、ある項目や用語などをＸ，ＹまたはＺとすることができる、あるいはそれらの組み合わせ（たとえばＸ，Ｙおよび／またはＺ）とすることができる、ということである。したがってこのような離接的な語法は通常、特定の実施形態には、少なくとも１つのＸ、少なくとも１つのＹ、または少なくとも１つのＺの各々が必ず存在していなければならない、ということを意図するものではなく、示唆しようというものでもない。

以上、本発明の新規の特徴を、種々の実施形態に適用しながら図面に示し説明してきたけれども、図示の装置またはアルゴリズムの形態および詳細について、本発明の範囲を逸脱することなく、様々な省略、置き換え、ならびに変更を行えることは自明である。さらに自明であるように、これまで説明してきた本発明のいくつかの実施形態を、既述の特徴および利点のすべてをもたらすものではないかたちで実現することもでき、たとえばいくつかの特徴を、他の特徴とは別個に利用または実施することができる。ここに開示した本発明の特徴の範囲は、既述の説明ではなく、添付の特許請求の範囲によって表されるものである。また、特許請求の範囲と同等の意味および範囲の中でなされるいかなる変更も、本発明の範囲内に包含されるべきものである。

以下、本発明の様々な実施形態について、項目ごとに説明する：
項目１．旅行アイテムクエリに応答して推奨旅行アイテムを生成するための、コンピュータにより実施される方法において、
特定の実行可能な命令によってコンフィギュレーションされた１つまたは複数のコンピューティングデバイスによって実行されると、
少なくとも２つの異なるタイプの旅行アイテムに対するクエリを、利用者に割り当てられた利用者コンピューティングデバイスから受け取るステップと、
受け取ったクエリの少なくとも部分的に基づき、利用者の希望旅行プランを決定するステップであって、該希望旅行プランは、利用者が希望する少なくとも２つの異なるタイプの旅行アイテムの組み合わせを決定するための基準セットに対応し、該基準セットは、受け取ったクエリにおいて特定される基準よりも広い、ステップと、
前記希望旅行プランに対応する基準セットに少なくとも部分的に基づき、前記希望する旅行アイテムに対し複数の推奨クエリを生成するステップであって、該複数の推奨クエリの各々は、受け取った前記クエリとは異なるものである、ステップと、
前記複数の推奨クエリを前記利用者コンピューティングデバイスに伝送するステップと、
が実施される、
旅行アイテムクエリに応答して推奨旅行アイテムを生成するための、コンピュータにより実施される方法。

項目２．旅行アイテムのタイプは、フライト、宿泊施設、地上移動手段、アクティビティ、ツアー、旅行保険、日帰り旅行、現地サービスのうち、少なくとも１つのサービスを含む、項目１に記載のコンピュータにより実施される方法。

項目３．前記希望旅行プランに対応する基準セットは、希望旅行日、希望旅行期間、希望行先、希望行先タイプ、希望コスト、希望移動時間、旅行目的、希望旅行アイテムタイプ、希望旅行アイテムランク、または希望サービスクラスのうち、２つまたはそれ以上を含む、項目１に記載のコンピュータにより実施される方法。

項目４．前記基準セット内の各基準に、前記希望旅行プランにおける前記基準の相対的な望ましさを表す重み付けを割り当てる、項目１に記載のコンピュータにより実施される方法。

項目５．利用者の前記希望旅行プランを、該利用者のプロフィルデータに少なくとも部分的に基づいて決定する、項目１に記載のコンピュータにより実施される方法。

項目６．旅行アイテムクエリに応答して推奨旅行アイテムを生成するシステムであって、
１つまたは複数のプロセッサが設けられており、該プロセッサは少なくとも以下のように構成されている、すなわち、
利用者に割り当てられたコンピューティングデバイスから、アイテムに対するクエリを受け取り、
受け取ったクエリに少なくとも部分的に基づき、利用者の希望旅行プランを決定し、該希望旅行プランは、利用者が希望する少なくとも２つの異なるタイプのアイテムの組み合わせを決定するための基準セットに対応し、
該基準セットに少なくとも部分的に基づき、前記希望旅行プランに対する推奨クエリを生成し、複数の該推奨クエリの各々は、前記受け取ったクエリとは異なるものであり、
前記コンピューティングデバイスへ、
（１）前記推奨クエリ、または
（２）該推奨クエリに少なくとも部分的に基づき決定された旅行アイテム、
の少なくとも一方を送信する、
ように構成されている、
旅行アイテムクエリに応答して推奨旅行アイテムを生成するシステム。

項目７．前記１つまたは複数のプロセッサはさらに、以下のように構成されている、すなわち、
前記希望旅行プランに少なくとも部分的に基づき、可能性のある推奨クエリを決定し、
前記基準セットに少なくとも部分的に基づき、前記可能性のある推奨クエリをランク付け、
前記可能性のある推奨クエリのランキングに少なくとも部分的に基づき、前記推奨クエリを生成する、
ように構成されている、
項目６に記載のシステム。

項目８．前記基準セット内の各基準に、前記希望旅行プランにおける前記基準の相対的な望ましさを表す重み付けを割り当てる、項目７に記載のコンピュータにより実施される方法。

項目９．可能性のある推奨クエリのランクは、前記基準セットにおける各基準に割り当てられた重み付けに、少なくとも部分的に基づく、項目８に記載のコンピュータにより実施される方法。

項目１０．可能性のある推奨クエリのランクは、該可能性のある推奨クエリと類似したまたは同一の少なくとも１つのクエリに対応づけられた履歴データに、少なくとも部分的に基づく、項目８に記載のコンピュータにより実施される方法。

項目１１．前記履歴データは、前記可能性のある推奨クエリと類似したまたは同一の少なくとも１つのクエリに対応づけられた、最低価格の旅行アイテムの組み合わせを含む、項目１０に記載のコンピュータにより実施される方法。

項目１２．コンピュータにより実行可能な命令を含むコンピュータ読み取り可能な非一時的記憶媒体であって、前記命令が１つまたは複数のプロセッサにより実行されると、該プロセッサは少なくとも以下を実施する、すなわち、
利用者に割り当てられたコンピューティングデバイスから、旅行アイテムに対するクエリを受け取ると、受け取ったクエリに少なくとも部分的に基づき、利用者の希望旅行プランを決定し、該希望旅行プランは、利用者が希望する少なくとも２つの異なるタイプのアイテムの組み合わせを決定するための基準セットに対応し、
該基準セットに少なくとも部分的に基づき、前記希望旅行プランに対する推奨クエリを生成し、該推奨クエリは前記受け取ったクエリとは異なるものであり、
前記コンピューティングデバイスへ、
（１）前記推奨クエリ、または
（２）該推奨クエリに少なくとも部分的に基づき決定されたアイテムの組み合わせ、
の少なくとも一方を送信する、
コンピュータ読み取り可能な非一時的記憶媒体。

項目１３．利用者の前記希望旅行プランを、該利用者のプロフィルデータに少なくとも部分的に基づいて決定する、項目１２に記載のコンピュータ読み取り可能な非一時的記憶媒体。

項目１４．利用者の前記希望旅行プランを、該利用者の収集履歴に少なくとも部分的に基づいて決定する、項目１２に記載のコンピュータ読み取り可能な非一時的記憶媒体。

項目１５．利用者の前記希望旅行プランには、希望するアイテムのカテゴリに対する好みが含まれている、項目１２に記載のコンピュータ読み取り可能な非一時的記憶媒体。

項目１６．前記カテゴリは、ビジネス、レジャー、ファミリー、エリート、デラックス、またはエコノミーの少なくとも１つに対応する、項目１５に記載のコンピュータ読み取り可能な非一時的記憶媒体。

項目１７．前記コンピュータにより実行可能な命令により、前記１つまたは複数のプロセッサは以下を実行する、すなわち、
前記希望旅行プランに少なくとも部分的に基づき、可能性のある推奨クエリを決定し、
前記基準セットに少なくとも部分的に基づき、前記可能性のある推奨クエリをランク付け、
前記可能性のある推奨クエリのランキングに少なくとも部分的に基づき、前記推奨クエリを生成する、
項目１２に記載のコンピュータ読み取り可能な非一時的記憶媒体。

項目１８．クエリに応答して推奨旅行アイテムを生成するための、コンピュータにより実施される方法において、以下のステップを含む、すなわち、
利用者に割り当てられたコンピューティングデバイスから、旅行アイテムに対するクエリを受け取ると、受け取ったクエリに少なくとも部分的に基づき、利用者の希望旅行プランを決定するステップであって、該希望旅行プランは、利用者が希望する少なくとも２つの異なるタイプのアイテムの組み合わせを決定するための基準セットに対応する、ステップと、
該基準セットに少なくとも部分的に基づき、前記希望旅行プランに対する推奨クエリを生成するステップであって、該推奨クエリは前記受け取ったクエリとは異なるものである、ステップと、
前記コンピューティングデバイスへ、
（１）前記推奨クエリ、または
（２）該推奨クエリに少なくとも部分的に基づき決定されたアイテムの組み合わせ、
の少なくとも一方を送信するステップと、
を含む、
クエリに応答して推奨旅行アイテムを生成するための、コンピュータにより実施される方法。

項目１９．前記推奨クエリまたはアイテムの組み合わせの推奨理由を送信する、項目１８に記載のコンピュータにより実施される方法。

項目２０．前記希望旅行プランに少なくとも部分的に基づき、可能性のある推奨クエリを決定するステップと、
前記基準セットに少なくとも部分的に基づき、前記可能性のある推奨クエリをランク付けるステップと、
前記可能性のある推奨クエリのランキングに少なくとも部分的に基づき、前記推奨クエリを生成するステップと、
を含む、項目１９に記載のコンピュータにより実施される方法。

項目２１．前記可能性のある推奨クエリ各々のランクを、他の複数の利用者による前記可能性のある推奨クエリの過去の実行に少なくとも部分的に基づき決定する、項目２０に記載のコンピュータにより実施される方法。

項目２２．利用者の前記希望旅行プランを、該利用者のプロフィルデータに少なくとも部分的に基づいて決定する、項目１９に記載のコンピュータにより実施される方法。

項目２３．利用者の前記希望旅行プランを、該利用者の収集履歴に少なくとも部分的に基づいて決定する、項目１９に記載のコンピュータにより実施される方法。

項目２４．利用者の前記希望旅行プランを、該利用者のロケーションに少なくとも部分的に基づいて決定する、項目１９に記載のコンピュータにより実施される方法。

Claims (17)

1. 旅行アイテムクエリに応答して推奨旅行アイテムを生成するためのシステムにおいて、
   １つまたは複数のプロセッサが設けられており、前記１つまたは複数のプロセッサは、少なくとも以下のように構成されている、すなわち、
   利用者に関連付けられたコンピューティングデバイスから、アイテムに対するクエリを受け取り、
   前記受け取られたクエリに少なくとも部分的に基づき、前記利用者の希望旅行プランを決定し、前記希望旅行プランは、前記利用者が希望する少なくとも２つの異なるタイプのアイテムの組み合わせを決定するための基準セットに対応し、
   前記基準セットは、前記受け取られたクエリにおいて特定される基準よりも広く、
   前記希望旅行プランに少なくとも部分的に基づき、推定された旅行アイテムを決定し、前記推定された旅行アイテムは、前記受け取られたクエリに参照されるものではなく、
   前記基準セットに少なくとも部分的に基づき、前記希望旅行プランに対する推奨クエリを生成し、前記推奨クエリは、前記受け取られたクエリとは異なるものであり、少なくとも前記推定された旅行アイテムを備え、
   前記コンピューティングデバイスへ、
   （１）前記推奨クエリ、または
   （２）前記推奨クエリに少なくとも部分的に基づき決定された旅行アイテム、
   の少なくとも一方を送信する、
   ように構成されているシステム。
2. 前記１つまたは複数のプロセッサは、さらに以下のように構成されている、すなわち、
   前記希望旅行プランに少なくとも部分的に基づき、可能性のある推奨クエリを決定し、
   前記基準セットに少なくとも部分的に基づき、前記可能性のある推奨クエリをランク付け、
   前記可能性のある推奨クエリのランキングに少なくとも部分的に基づき、前記推奨クエリを生成する、
   ように構成されている、
   請求項１に記載のシステム。
3. 前記基準セット内の各基準は、前記希望旅行プランにおける前記基準の相対的な望ましさを表す重み付けに関連付けられている、
   請求項２に記載のシステム。
4. 可能性のある推奨クエリのランクは、前記基準セットにおける各基準に関連付けられた重み付けに、少なくとも部分的に基づく、
   請求項３に記載のシステム。
5. 可能性のある推奨クエリのランクは、前記可能性のある推奨クエリと類似したまたは同一の少なくとも１つのクエリに関連付けられた履歴データに、少なくとも部分的に基づく、
   請求項２に記載のシステム。
6. 前記履歴データには、前記可能性のある推奨クエリと類似したまたは同一の少なくとも１つのクエリに関連付けられた、最低価格の旅行アイテムの組み合わせが含まれている、
   請求項５に記載のシステム。
7. 前記希望旅行プランはさらに、前記利用者のプロフィルデータに少なくとも部分的に基づいて決定される、
   請求項１に記載のシステム。
8. 前記希望旅行プランには、希望するアイテムのカテゴリに対する好みが含まれている、
   請求項１に記載のシステム。
9. 前記カテゴリは、ビジネス、レジャー、ファミリー、エリート、デラックス、またはエコノミーの少なくとも１つに対応する、
   請求項８に記載のシステム。
10. クエリに応答して推奨旅行アイテムを生成するための、コンピュータにより実施される方法において、
    利用者に関連付けられたコンピューティングデバイスから、アイテムに対するクエリを受け取ると、前記受け取られたクエリに少なくとも部分的に基づき、前記利用者の希望旅行プランを決定するステップであって、前記希望旅行プランは、前記利用者が希望する少なくとも２つの異なるタイプのアイテムの組み合わせを決定するための基準セットに対応するステップであって、前記基準セットは、前記受け取られたクエリにおいて特定される基準よりも広い、ステップと、
    前記希望旅行プランに少なくとも部分的に基づき、推定された旅行アイテムを決定するステップであって、前記推定された旅行アイテムは、前記受け取られたクエリに参照されるものではない、ステップと、
    前記基準セットに少なくとも部分的に基づき、前記希望旅行プランに対する推奨クエリを生成するステップであって、前記推奨クエリは、前記受け取られたクエリとは異なるものであり、少なくとも前記推定された旅行アイテムを備える、ステップと、
    前記コンピューティングデバイスへ、
    （１）前記推奨クエリ、または
    （２）前記推奨クエリに少なくとも部分的に基づき決定されたアイテムの組み合わせ、
    の少なくとも一方を送信するステップと、
    を含む、
    コンピュータにより実施される方法。
11. 前記推奨クエリまたは旅行アイテムの組み合わせの推奨理由を送信するステップを含む、
    請求項１０に記載のコンピュータにより実施される方法。
12. 前記希望旅行プランに少なくとも部分的に基づき、可能性のある推奨クエリを決定するステップと、
    前記基準セットに少なくとも部分的に基づき、前記可能性のある推奨クエリをランク付けるステップと、
    前記可能性のある推奨クエリのランキングに少なくとも部分的に基づき、前記推奨クエリを生成するステップと、
    を含む、
    請求項１０に記載のコンピュータにより実施される方法。
13. 前記希望旅行プランを、前記利用者のロケーションに少なくとも部分的に基づいて決定する、
    請求項１０に記載のコンピュータにより実施される方法。
14. 旅行アイテムのタイプは、フライト、宿泊施設、地上移動手段、アクティビティ、ツアー、旅行保険、日帰り旅行、現地サービスのうち、少なくとも１つを含む、
    請求項１０に記載のコンピュータにより実施される方法。
15. 前記希望旅行プランに対応する前記基準セットは、希望旅行日、希望旅行期間、希望行先、希望行先タイプ、希望コスト、希望移動時間、旅行目的、希望旅行アイテムタイプ、希望旅行アイテムランク、または希望サービスクラスのうち、２つ以上を含む、
    請求項１０に記載のコンピュータにより実施される方法。
16. 前記希望旅行プランを、前記利用者の収集履歴に少なくとも部分的に基づいてさらに決定する、
    請求項１０に記載のコンピュータにより実施される方法。
17. 前記基準セット内の各基準は、前記希望旅行プランにおける前記基準の相対的な望ましさを表す重み付けに関連付けられている、
    請求項１０に記載のコンピュータにより実施される方法。

Images