JP2010528383A - サーチ技術における改良又はサーチ技術に関する改良 - Google Patents

Abstract

【課題】本発明は、真に柔軟なオンライン予約サーチ能力を提供する方法とシステムを与える。
【解決手段】サービス又は製品をオンラインサーチする方法であって、当該方法は、ユーザからの第１サーチ要求を得ることであって、前記第１サーチ要求は１つのサーチ基準を含むこと；所定場所で前記サーチ基準セットを記憶すること；前記サーチ基準セットに合致するサービス又は製品をサーチすること；ユーザに伝達するための前記サーチ基準セットに合致するサービス又は製品の第１推薦セットを創出すること；前記第１推薦セットを記憶すること；所定の方法で前記第１サーチ要求の１以上の前記サーチ基準セットの範囲を変えるために第２要求を創出すること；前記第２要求のための前記サーチ基準の基礎を形成するために、前記所定場所から前記サーチ基準セットを検索すること、を含む。
【選択図】図７

Description

本発明は、サーチ技術、特に限定されないが、インターネットサーチの領域で、サーチ技術における改良又はサーチ技術に関する改良を提供するための方法及び装置に関する。

ｅ−ｃｏｍｍｅｒｃｅ出現以来、ユーザはインターネットを通して製品及びサービスを買うようになってきている。この方法で購入される製品及びサービスは、制限がない。オンライン購入及びサーチが特に人気がある１つの特別な状況は、例えば、フライト、劇場等、又は他のいずれかのタイプの旅行関係サービスのチケット購入にある。

フライト予約の状況では、多くのオンライン予約サービスが、３つの主要コンポーネントを含むアーキテクチャに基づく。これらは、インターネットブラウザ、予約エンジン、及びいくつかの又は他の種類のバックエンドシステムである。インターネットブラウザはオンラインユーザが指定フライト又は他の予約を探すことを可能にするツールである。予約エンジンは、それがバックエンドに送られる前にユーザの要求に、そしてユーザに返送される前にバックエンドの応答に、商業論理を適用する中層コンポーネントである。バックエンドシステムは、典型的に世界的配置システム（ＧＤＳ）又はＣＲＳである。

典型的には、オンラインユーザはインターネットブラウザと接続し、ページフローを創出する。ページフローは、旅行の日付及び目的地により定義される、ユーザのためのフライトの利用可能性をチェックするための早期ステップを含む。これが生じるページは一般的にサーチページといわれる。一旦オンラインユーザがサーチページを完成させると、データが予約エンジンによりバックエンドに送られる。バックエンドは、その後、サーチ基準を満たす利用可能なフライトのリストを決定するために、そのデータベース内で１以上のモジュールに照会する。オンラインユーザによるサーチに応答して、多くの利用可能なモジュールが、利用可能な運賃及び日付の集合からなるフライトの解答を戻すよう設計されている。例えば、指定日の最も安いフライトの解答がユーザに表示され、これらは複数及び単数のルート等を含むことができる。加えて、ユーザによって指定された日、例えば、行き及び帰りフライトの両者の最大周辺日で利用可能なものが表示されることは現在では普通である。

特許文献１（Ｓａｂｒｅ Ｉｎｃ．）は、指定日又はある範囲の日付のための低価格のフライトを決定する方法及びシステムを開示する。その方法は、ユーザの要求に合致しない結果を除外するために、「プルーニング」（ｐｒｕｎｉｎｇ：剪定）プロセスを含む。これは、最も安い値をもつフライトの組合せの種類を決定するためのアルゴリズムによって達成される。そのシステムはその後、運賃テンプレートを含めることができるユーザに対するグリッド（碁盤目）又はマトリクスで全ての組合せを表示する。

特許文献２（発明者：Ｒａｚｚａら）は、ユーザが指定日又はある範囲の日付で要求されたフライト及び価格の組合せを発見するために、ユーザが複数の要求をすることを避ける方法及びシステムを開示している。そのシステムは、任意のサーチ基準を指定する広い要求と接続ページを開始可能にする、柔軟な日付ラジオボタンを含む。

特許文献３（Ｂｒｉｔｉｓｈ Ａｉｒｗａｙｓ）は、予約のためにユーザが複数の要求をするのを防ぐ方法とシステムを開示している。そのシステムは、ウェブサーバに全ての照会を送るかわりにブラウザレベルで複数の照会を処理するか、最初の照会がなされた後停止することができる。予約データベースのデータセットは、ユーザの端末にダウンロードされる。これはその後、ユーザが自分の要求を修正するのに用いられ、短い時間スケールで返答することができる。

これらの提案は、所定の基準を満たす予約のためのオンラインサーチに関するいくつかの問題を扱う一方で、それらはすべての課題を解決しない。

米国特許出願公開第２００５／０２７３３７３号明細書 米国特許出願公開第２００５／０８６０８７号明細書 米国特許出願公開第２００２／０６５６８８号明細書

本発明の１つの目的は、先行技術に関する少なくともいくつかの問題を克服し、真に柔軟なオンライン予約サーチ能力を提供する方法とシステムを与えることにある。

加えて、さらなる目的は、直感的でユーザフレンドリな方法でこれを提供し、ユーザによる意思決定を手助けし容易にするような方法でサーチにより得られる情報を提示することにある。

またさらなる目的は、ユーザ又は他の要求に基づくサーチ結果プロフィールを変更する手段を与えることにある。

サービス又は製品のためのオンラインサーチ方法であって、当該方法は、ユーザからのサーチ要求を得ることであって、前記サーチ要求は１つのサーチ基準セットを含むこと；所定場所に前記サーチ基準セットを記憶すること；前記サーチ基準セットに合致するサービス又は製品をサーチすること；ユーザに伝達するために、前記サーチ基準セットに合致するサービス又は製品の第１推奨セットを創出すること；前記第１推奨セットを記憶すること；所定の方法で前記第１サーチ要求の１以上の前記サーチ基準セットの範囲を変更するための第２要求を創出すること；前記第２要求のための前記サーチ基準の基礎を形成するために、前記所定場所から前記サーチ基準セットを検索すること；変更されたサーチ基準セットを形成するために、前記所定の方法で、前記サーチ基準セットの前記サーチ基準又は各々のサーチ基準を変更すること；前記変更されたサーチ基準セットに合致するサービス又は製品をサーチすること；ユーザに伝達するための前記変更されたサーチ基準に合致する、前記サービス又は製品の第２推奨セットを創出すること；第１推奨セットを第２推奨セットと統合して、所定の結果プロフィールをもつ統合された推奨セットを形成することであって、統合された推奨セットに重複が発生しないことを確実にするようにその統合がなされること、を含む。

本発明は多くの利点を有する。本発明は複数の要求をサポートし、単純な出力で結果を収集する。その要求は、連続する柔軟な要求を実行することにより、柔軟でない要求の結果を提示することができる。これらはそれぞれ、広い要求および深い要求と、本明細書中でいわれる。同様に本発明は、柔軟な要求の結果が、日付範囲を拡大することにより、連続する柔軟でない要求によって実行されることを可能にする。予約エンジンからＧＤＳへのいくつかの要求又は等価物があり、それらはユーザに透明性がある。各ケースの結果は、最初の段階で入力した以外の任意の追加データを入力するために、ユーザに要求せず、直感的で透明性のある様式で提示される。この方法における結果の収集の利点は、予約エンジンがＧＤＳにさらなる要求を送らないことを意味し、結果的にナビゲーション遅延においていくらか経済的になる。加えて、ユーザはいかなるナビゲーション遅延も経験することなく、イベント結果をブラウズすることができる。柔軟な及び柔軟でない要求の集合された結果は、２つの個別の要求の集合されない結果より、オンラインユーザに対してはるかに価値ある情報を含む。本発明の方法及びシステムは、収集の結果の正確さが最大限利用されるものである。添付した以下の図面が例として参照されるだろう。

図１は、本発明の一態様に係る、異なるタイプの要求を示すダイヤグラムである。 図２は、本発明の一態様に係る、戻り行程のための柔軟でない要求の画面表示である。 図３は、本発明の一態様に係る、深い要求が、広い要求に拡大され得る手段を示す画面表示である。 図４は、本発明の一態様に係る、簡単な要求がブラウザからＧＤＳに送られるとき生じる伝達を示すダイヤグラムである。 図５は、本発明の一態様に係る、ＡＰＩ要求の例である。 図６は、本発明の一態様に係る、図５のＡＰＩ要求に対する返答例である。 図７は、本発明の一態様に係る、簡単な要求がブラウザとＧＤＳとの間で拡大されるとき起こる伝達を示すダイヤグラムである。 図８は、本発明の一態様に係る、拡張期間のサーチのための結果プロフィールを示すダイヤグラムである。

簡便化のために、＋／−１日の中心日前後の日数の範囲が、本発明の説明を補助する一例として選択された。言い換えれば、３日の範囲が例として提供される。しかしながら、５日（＋／−２日）、７日（＋／−３日）又はいかなる他の日付範囲を用いてもよいことが理解されるであろう。ビジネス及び技術の観点から、用いられる日付範囲は、異なる用途のために最適化してもよい。

図１を参照して、本発明の実施形態がここで説明される。ユーザが、柔軟性のない日付（「深い要求」ともいう）１００に、所定の旅程のための最も安いフライトを探すよう要求する。出発日１０２が１月７日で戻り日１０４が１月１４日である要求がなされる。この要求の結果は、例えば２００個の推奨（例えばサーチ基準に合致する最も安い値の２００個の推奨）で応答される。結果を調査した後に、ユーザが、周辺日にさらにより安く便利なフライトがあるかどうか見出すことに興味があると決定するなら、本発明は、元のサーチ基準を再入力する必要なくこれをできるようにする。出発及び戻りの両日程で３日間の利用可能なフライトがテーブル１０６に示される。しかし、ユーザは第１データセット１００を失うことを望まないので、本発明は、２つの結果がテーブル１０８で共に提供されるようにする。これが起こる方法は、以下に、より詳細に説明される。テーブル１０６に示される３日間をカバーする要求は、ここで「広い要求」と言及され、出発日１月６、７及び８日、戻り日１月１３、１４及び１５日を含む。出発及び戻りの日付の各組合せの推奨数が示され、例えば１１０は出発１月６日で戻り１３日である。

いわゆる深い要求が広い要求に転換しうる方法が実際には２つあり、ユーザに提案される最終結果に異なる結果プロフィールを提供する。これらの２つの方法は、同時（ｃｏｎｃｕｒｒｅｎｔ）要求と連続（ｓｅｑｕｅｎｔｉａｌ）要求として言及される。同時要求は単一の要求で全ての結果を検索する。言い換えれば、同時要求はユーザからの入力を取得し、各旅行のための選択された日付について１セットの結果を要求し、同時に拡張期間に関するさらなるセットの結果を要求する。これにより、ユーザ指定日については２００のベストフライト、拡張期間についてはより少ない結果を含む返答を結果として出す。拡張期間の結果の実際の数は、ユーザに提供される要求された結果プロフィールに従って選択することができる。これは、以下に、より詳細に説明される。ユーザ指定日と拡張期間の両方に関する結果がキャッシュに記憶されうる。ユーザの要求、又はサーチと関係する他の設定に依存して、指定日又は拡張期間についての結果を、ユーザに提供することができる。同時要求処理に関するさらなる詳細が以下に提供される。

他方で、連続要求は、旅行の各部分の選定日について１セットの結果を要求し、図２に示されるように「代替日をチェックする」ラジオボタン２０２により、期間を拡張し柔軟な要求を創り出す能力を与える。

図２の画面表示は、出発地、行先地、旅行者数、日付、運賃タイプ等のような全ての期待される情報を示す。画面表示は、いくつかの利用可能なフライトのオプション２００を示すが、実際には、利用可能なフライトの解答数がかなり多く、典型的には約２００個の推奨がある。ユーザがより多くの推奨を見ることができる方法は、適切な手段により実現されうることが、当業者に理解されるであろう。画面表示は、「代替日をチェックする」ラジオボタン２０２も示す。深い要求から広い要求、又はその逆にサーチを変更するために、オンラインユーザが用いることができるのがこのボタン２０２である。

もしオンラインユーザが「代替日をチェックする」ボタンをクリックすると、本発明は、オンラインユーザがデータを再入力する必要なく、元のサーチと同じサーチ基準を用いながら、第２要求を実行する。その結果は、プラスマイナス１日以上とすることができ、行き及び帰り日周辺の柔軟性を探す。言い換えればサーチを拡大することである。時間範囲はオンラインユーザが指定することができるか、又は予約エンジン、インターネットブラウザ、もしくはいずれであっても標準設定でプログラムされ得る。

サーチが、時間、日付又はその他に関して、深い要求すなわち柔軟でない要求から、広い要求すなわち柔軟な要求に拡大されるとき、連続要求の方法で実行される。この結果の画像表示が、例えば、図３に示さされる形式でなされる。３×３のマトリクス３００は、行きの日の詳細３０２及び戻り日の詳細３０４を含む。３×３のマトリクスは、行き及び戻りの日の組合せに応じて１つの推奨セットを含む。与えられた日付の組合せについての各推奨セットのために「価格から」の表示が設けられる。このことから、マトリクス内で選択された組合せである日付ボックス３０６が、他の可能な日づけの組合せより高価な推奨を与えることが理解できる。例えば、ボックス３０８は旅行の同じ行きの日に対応するが、戻り旅程より１日早い日に対応する。マトリクスにおいてラジオボタンの１つをチェックすることにより、利用可能なフライトの詳細リストが直ちに現れる。フライトの解答はキャッシュに記憶され、情報は処理のこの時点でバックエンドと交換されない。第１要求の正確さが保たれるのは、元の行き及び戻り旅程（すなわち１月７日から１月１４日）の２００個以上の推奨がボックス３０６のラジオボタンをクリックすることによりアクセスすることができることを意味する。言い換えれば、ボックス３０６に約２００個の推奨、ボックス３０６の周りの各ボックスに約２５個の推奨がある。

製品又はサービスのオンラインサーチのために必要とされるサーチ要求、このケースではフライト照会を遂行するために、多くの要素が必要とされる。入力モジュールは、ユーザがサーチ要求を入力し、予約エンジンとインターフェースすることを可能にし、予約エンジンは順にＧＤＳシステムとインターフェースする。入力モジュールは、実行されるサーチとそれから生じるあらゆる結果の両方を記憶する手段を含みうる。サーチエンジンは、サーチを実行し、ユーザによりなされるサーチと合致する推奨を決定するために必要とされる。伝達モジュールは、ユーザにサーチ情報を表示し、さらに選択及び／又は購入しうるようにするために必要とされる。本発明の実施形態によれば、サーチに関する所定の基準を変更する条件があり、例えば、日付の範囲は指定された日又はいずれかを変える条件である。システムは、ユーザ又はシステムが開始したか否かにかかわらず、この変更を実行するモジュールを必要とする。一旦結果が受け取られ、もし適切に記憶されたなら、ユーザに第１及び第２推奨セットの所定の結果プロフィールを提供するために、所定の方法で結果を一緒にもたらすことがその後必要である。これは、ユーザの装置、又はその他で実行することができる。単一の要求のための、ブラウザ、予約エンジン及びＧＤＳの間の種々のやりとりが図４と関連して示される。垂直ラインはブラウザ４００、予約エンジン４０２、ＡＰＩ４０４及びＧＤＳ４０６にそれぞれ対応する。水平ライン又は矢印は、システムの一部から他まで、すなわち、例えばブラウザから予約エンジンまで、移動する情報を表す。オンラインユーザは、１セットのデータ４０８をブラウザ上の適切な手段に入力する。サーチデータが予約エンジン４１０に送られる。予約エンジンでは、サーチデータはＡＰＩ形式４１２に変換され、要求がＡＰＩ４１４に転送される。ＡＰＩはその後ＡＰＩ要求をＧＤＳ４１４に送る（これは、図５に関連してより詳細に説明される）。ＧＤＳはＡＰＩに対し返答４１８を創出する（これは、図６でより詳細に説明される）。ＡＰＩはその後、返答を予約エンジン４２０に送り返し、予約エンジンは、フライトと運賃の集合情報４２２から１セットの推奨を構築する。予約エンジンはその後、ビジネスルール４２４及び、必要とされるフィルタリング又はソーティング４２６のような後処理を適用しうる。予約エンジンはその後、オンラインユーザが見るブラウザに、元のサーチデータを満たす推奨４２８を送り返す。

ＡＰＩ要求構造の例が図５に示される。その構造は、多くの本質的パラメータを含む一般的な照会の形式である。これらは次のものを含む：旅行者数、希望する推奨数、出発地、目的地、出発日、戻り日、他のオプションパラメータ。

このデータの各要素のレイアウト及び位置は、特殊ＧＤＳ及び予約エンジンの組合せにより必要とされるものであるだろう。いくつかの又は全てのデータはオンラインユーザにより入力され、いくつかのデータは自動的に創出されることができる。

ＡＰＩ返答構造の典型例が、図６に示される。返答は「フライト提案」と呼ばれるセクション、及び「最も安い運賃推奨」と名付けられたセクションを特徴とする。伝達チャネルで送られるデータ量を最小限にするために、「最も安い運賃推奨」セクションは「フライト提案」セクションに含まれるフライトを参照する。各フライトは複数回参照できることに留意すべきである。ＡＰＩ返答構造は、サーチ要求の行きフライト、帰りフライト又は両方のためのフライト提案６００を含む。１つの最も安い運賃推奨セット６０２に加えて、６０４等も含まれる。最も安い運賃推奨を参照すると、これは例えば、利用可能な運賃番号１、６０６及び運賃製品詳細６０８に関して示される情報を含む。利用可能な運賃番号１は、利用可能なフライトの組合せを含み、示された例では、組合せ１及び組合せ２の２つがある。各組合せは、行きフライト提案及び帰りフライト提案、例えば６１０及び６１２を含む。使用可能な運賃番号１の行きフライト提案６１０及び帰りフライト提案６１２は、例に示すように推奨１を構成する。そのＡＰＩ返答は、推奨２、推奨３及び推奨４をも含む。ＡＰＩ返答のパラメータ、メモリ容量又は多くの他のファクターに依存していくつかの推奨がありうることが理解されるだろう。

ＡＰＩ返答が予約エンジンで受け取られるとき、推奨構築処理が行われる。これは、運賃製品詳細セクションに含まれる運賃の詳細を、それらが参照するフライトの組合せに結びつける構築オブジェクトを含む。この処理は当該分野の周知技術であり、本発明のプロセスのこの部分を説明することを要しない。

図７は、単純な要求が本発明に従って拡大されるときの、ブラウザ、予約エンジン、ＡＰＩ及びＧＤＳの間のやりとりを示している。再度、垂直ライン７００，７０２，７０４及び７０６がそれぞれブラウザ、予約エンジン、ＡＰＩ及びＧＤＳに関係する。オンラインユーザがサーチ基準７０８を入力すると、それはブラウザから予約エンジン７１０に伝達される。サーチデータはＡＰＩ形式に変換され、そのデータはビジネスルール設定及び後処理パラメータ７１２とともにセーブされる。これらは、エージェントのサービス料等の追加料金を含みうる。第１要求７１４はＡＰＩに送られ、その後、図５に示すようなＡＰＩ要求７１６を創出する。図６に示すＡＰＩ返答はその後ＡＰＩ７１８に戻され、第１返答７２０は予約エンジンに送り返される。予約エンジンはその後、フライト及び運賃情報の集合から推奨オブジェクトを構築し、その推奨をキャッシュ７２２にセーブする。これらの推奨は、その後メッセージ７２４を通してユーザが見られるようにブラウザに伝達される。もし必要なら、ビジネスルール設定７２６及び後処理パラメータ７２８が推奨に適用されうる。

所定の時間ポイントで、ユーザは、現在受け取られた推奨の変更を望むことを決定することができる。ユーザは、推奨７３２を変更する要求により７３０においてこれを活用する。予約エンジンはその後、サーチデータ７３４を再利用し、ＡＰＩに送られる第２要求７３６を創出する。第１要求からのデータはユーザにより創出することができるか、又はシステムの必須部分であるうるデータ範囲で向上される。代替的に、別のフィルタが、１つの詳細なサーチ基準をより広く又は狭くするよう、そのサーチ基準を変更するために適用されうる。ＡＰＩ要求及び返答がその後、ＡＰＩ及びＧＤＳ間に先に説明したように創出され、ＡＰＩは第２返答７３８を創出する。予約エンジンはその後、フライト及び運賃の集合からオブジェクトの推奨を構築し、その後、第１返答及び第２返答（７４０）からの２セットの推奨を統合する。

最大限の結果の精度を保証するために、両方の推奨セットに発生する重複を全て排除することが望まれる。これは、不要な計算及びメモリソースの浪費を最小限にすることを保証するためである。予約エンジンに記憶された第１要求の結果である推奨、及びその後予約エンジンにより受け取られた第２要求の結果は、予約エンジンが、第１要求の結果であったものではなく第２セットの推奨からの推奨のみを含むように、統合された推奨である。第１要求の結果の全属性を第２要求の結果の属性と比較すると、両者ともコンピュータ計算及び時間の点で非常にコストがかかりうる。本発明は、このコスト及び処理時間を十分削減する、重複排除エンジンを最大限活用することを特徴とする。

図６に示したＡＰＩ返答構造を参照すると、次のことがなされれば、２つの推奨が重複であるとみなされる：行き及び帰りのフライト提案、額及び税額（運賃製品詳細の一部）が等しい；それらのフライトが等しければ２つのフライト提案は同じと見なされる；並びに／又は日付、時間、フライト番号、会社、及び運賃ベースが等しければ２つのフライトは等しい。

重複排除エンジンは、第１要求から生じる推奨で初期化される。上述した同等基準はその後、比較のためにデータの最もユニークな要素を選択することにより第２要求の結果に適用される。例えば、最もコスト効果の高い基準が、要求される計算量を最小限にするために最初に適用される。例えば、運賃額の比較は、コンピュータ計算負荷が十分により少ないので、フライト提案の比較よりかなりコスト効果がある。他の状況では、最もコスト効果の高い基準は異なるかもしれない。このコスト効果の高い基準が選択される方法は、本発明が処理する環境の状況に依存するだろう。

再度、ビジネスルール設定７４２及び後処理パラメータ７４６を、拡大された推奨セットがユーザに戻されブラウザ７４８上に表示される前に、統合された推奨に適用することができる。

先に示したように、日付の柔軟性を異なるマトリクスのケースに変更することができるということが、注目されるべきである。所定プロフィールのサーチ結果について、１つの例が図８に示される。さらに、以下の表に、中心日及び周辺日の推奨数を示す。中心日は最初の段階でオンラインユーザにより入力された元データであり、周辺日は、行き及び戻り旅程の両方のための中心日の各サイドの日にち範囲内の元データである。

サーチ結果は、同時要求又は連続要求のいずれによっても、本発明の実施形態に従って統合される個別のサーチの選択である。各サーチについて、例えば最大２００個の推奨がある。サーチの「深い」要素については、全ての結果が、ユーザによって入力された指定日の組合せについてのものである。言い換えれば、８００で示されるように、ユーザにより選択された日付の組合せについて２００の推奨がある。プラス又はマイナス１の日付範囲の増加が、８０２で示される結果プロフィールで生じる。９個の日付の各々について、約２０から２５の推奨があり、全体で約２００の推奨になる。プラス又はマイナス２の日付範囲の増加により、８０４に示される結果プロフィールが生じる。ここでは、２５の可能な日付の組合せがあり、各々が、可能な日にち数（このケースでは２００割る２５）により分割され、合計すると最大数の推奨と等しくなる推奨を含む。これにより、各日付の組合せについて約８個の推奨が生じる。サーチの解答は、８０６で示される統合された結果プロフィールの中心から端に向けて減少する。推奨の数と結果プロフィールの形状は、問い合わせ中の申し込み条件と一致するよう変化されうる。結果プロフィールは矩形マトリクスに基づく必要はなく、もし一方向の拡大が他方向の拡大と異なるなら、別の形式に基づくこともできるだろう。

８０８で示される断面プロフィールは、少し異なる方法で結果プロフィールを表現する。その結果は、３つのブロック８１０、８１２及び８１４の各々における推奨の合計数がそれぞれ約２００の推奨を含むプロフィールを有し、図示されていないが、そのブロックは２次元であることが注目されるべきである。表示されたＣＤは中心日を意味し、Ｄ−２、Ｄ−１、Ｄ＋１及びＤ＋２は中心日からプラス又はマイナスの日である。

マトリクスの性質及び／又は要求された結果プロフィールに関係なく、個々の結果は、上述したように、同時要求又は連続要求のいずれかにより集められることができる。同時要求の場合は、３セットのサーチ結果８００、８０２及び８０４全てが同時に集められ、要求されるまでキャッシュに記憶されるだろう。連続要求では、最初に受け取られた指定日の組合せ８００の結果及びその後の他の結果は、任意の適切な処理によって、一緒に又は別々のいずれかで要求されうる。

上記の方法により、指定した日付の組合せの拡大を説明することが理解されるだろうが、これは逆に作用してもよいことが理解されるだろう。言い換えれば、日付範囲が入力され、指定日が後に同時要求及び／又は連続要求のいずれかを通じて選択される。

２つの要求の結果は、それらを共に見ることができるように、統合されなければならない。結果を管理するために、予約エンジンはキャッシュに第１要求の結果を記憶するだろう。第２要求をバックエンドに送る処理は、オンラインユーザに対して完全な透明性をもつ。これは、第１要求で入力されたサーチ範囲が永続性であり、そのセッションの任意の他の要求についても不変である、という事実による。これは本発明の重要な要素である。

同じ入力データに由来する２つの特定要求の結果を管理するための能力に加えて、本発明による予約システムは他の機能に関する要求への変化も許容するだろう。例えば、要求は、唯一のある好ましい航空会社、出発時間又はいかなる他の種類のフィルタも含むよう調整されることができる。本発明は、最初の段階で入力された全ての追加サーチのパラメータが、上述した本発明の透明性と操作性を保証するために、第１及び第２要求の間で継続していることを保証する。

本発明はフライト（又は他のいかなる旅行、娯楽、入場券）環境を参照して説明したが、他の任意のタイプのオンライン予約サービス又は製品購入の状況に適用してもよいことが理解されるだろう。重複排除エンジンが動作する方法は、本発明の重要な部分であり、上述したものとは異なる方法で実行されるであろう。

本発明の主要部は、ユーザにより入力された第１サーチ基準を拡大することと関連して主に説明されたことが理解されるだろう。さらに、上述したように、より広い範囲からより狭い範囲にサーチ基準の範囲を変更することが可能であるだろう。これは、柔軟な日付範囲が最初のサーチ基準で入力され、その後第２のサーチ基準の指定日に狭くされる場合に適合されるだろう。

示された例は単なる例示であり、種々の特徴についての多くの他の例が、本発明の範囲及び趣旨に含まれるとことが、さらに理解されるだろう。

Claims (15)

1. オンライン旅行予約に関するサービス又は製品のためのオンラインサーチ方法であって、当該方法は、
   入力モジュール（ブラウザ）を通してユーザからサーチ要求を得ることであって、当該サーチ要求は１つのサーチ基準セットを含むことと、
   予約エンジン（ＧＤＳ）に前記サーチ要求を伝達することと、
   所定場所で前記サーチ基準セットを記憶することと、
   前記サーチ基準セットに合致するサービス又は製品をサーチすることと、
   前記ユーザに伝達するための前記サーチ基準セットに合致するサービス又は製品の第１推奨セットを創出するために前記予約エンジンを用いることと、
   前記第１推奨セットを記憶することと、
   前記第１推奨セットを変更する要求を起動することと、
   所定の方法で第１サーチ要求の１以上の前記サーチ基準セットの範囲を変更するために、第２要求を創出するための前記予約エンジンを用いることと、
   前記第２要求のためのサーチ基準の基礎を形成するために、所定場所から前記サーチ基準セットを検索することと、
   変更された前記サーチ基準セットを形成するために、前記所定の方法で前記サーチ基準セットの前記サーチ基準又は各々のサーチ基準を変更することと、
   前記変更されたサーチ基準セットに合致するサービス又は製品をサーチすることと、
   前記ユーザに伝達するための前記変更されたサーチ基準に合致するサービス又は製品の第２推奨セットを創出することと、
   所定の結果プロフィールをもつ統合された推奨セットを形成するために、前記第１推奨セットを前記第２推奨セットと統合するために前記予約エンジンを使用することであって、前記所定の結果プロフィールは、前記第１及び前記第２推奨セットを一緒に表示するために、両セットを結合することにより達成されることと、を含む、方法。
2. 前記検索または各々の検索のステップが、所定数の推奨を受け取ることを含む、請求項１に記載の方法。
3. 前記推奨を統合するために前記予約エンジンを用いるステップが、前記統合された推奨セットから重複を排除するために、重複排除エンジンを動作させることを含む、請求項１に記載の方法。
4. 種々の値である前記サーチ基準セットの前記サーチ基準又は各々のサーチ基準を変更することをさらに含む、請求項１に記載の方法。
5. より特定の値である前記サーチ基準セットの前記サーチ基準又は各々のサーチ基準を変更することをさらに含む、請求項１に記載の方法。
6. ブラウザにより前記ユーザから前記サーチ要求又は各々のサーチ要求を受け取ることをさらに含む、請求項１に記載の方法。
7. 前記ブラウザから予約エンジンに前記要求又は各々の要求を伝達することをさらに含む、請求項６に記載の方法。
8. サービス又は製品をサーチするステップが、ＡＰＩインターフェースを用いて、予約エンジンから世界的配置システム（ＧＤＳ）に、前記サーチ基準セットに合致する推奨のための要求を送ることを含む、請求項１に記載の方法。
9. 予約エンジンのキャッシュに前記サーチ基準セット及び前記第１推奨セットを記憶することをさらに含む、請求項１に記載の方法。
10. 前記第１及び前記第２推奨セットを統合するステップが、
    前記第１及び前記第２推奨セットを比較するための手段として前記サーチ基準セットの１つを選択することと、
    前記選択されたサーチ基準が、前記第１推奨セットに関するものと前記第２推奨セットに関するものが同じである場合を除いて、前記第１推奨セットに前記第２推奨セットを追加することと、を含む、請求項１に記載の方法。
11. 前記選択するステップが、比較ステップにおいて最小処理量を必要とする前記サーチ基準を用いることを含む、請求項１０に記載の方法。
12. 旅行予約をサーチするための方法を使用することをさらに含む、請求項１〜１１のいずれかに記載の方法。
13. オンライン旅行予約に関する製品又はサービスのためのオンラインサーチシステムであって、当該システムは、
    ユーザからサーチ要求を得るための入力モジュールであって、前記サーチ要求が１つのサーチ基準セットを含み、前記サーチ基準が所定場所に記憶される、入力モジュールと、
    前記サーチ基準セットに合致する製品又はサービスをサーチし、前記サーチ基準セットに合致するサービス又は製品の第１推薦セットを作成するための予約エンジンと、
    前記第１推薦セットを伝達し記憶する伝達モジュールと、
    変更されたサーチ基準セットを実行するために１以上の前記サーチ基準セットの範囲で変更を創出するための予約エンジンであって、前記予約エンジンが、前記変更されたサーチ基準セットに合致するサービス又は製品の第２推薦セットを作成するための予約エンジンと、
    を含み、
    前記システムは、前記第１及び前記第２推薦セットを統合した推薦セットを形成し、前記第１及び第２推薦セットの所定の結果プロフィールを創出するジェネレータをさらに含み、前記所定の結果プロフィールが前記第１及び前記第２推薦セットを結合することにより達成され、両者を一緒に表示する、システム。
14. 前記統合した推薦セットから重複を排除するための重複排除エンジンをさらに含む、請求項１３に記載のシステム。
15. コンピュータプログラムがコンピュータシステム上で実行される場合、請求項１〜１２のいずれか１項に記載の方法のステップを実行するための指示を含むコンピュータプログラム。

Images