JP6138915B2 - バッチ指向型の計算を用いるデータベースシステム - Google Patents

Description

本発明は、データベース技術の分野に関する。より具体的には、データベースクエリ結果を事前計算して、事前計算済みデータベースクエリ結果をメモリに保存し、そのメモリを管理して最新状態に維持し、事前計算済みデータをクライアントが利用できるようにするための複合システムに関するものである。

データベース技術における共通の課題は、大量データの処理を要するデータベースクエリに対して短い応答時間を保証することである。例えば、そのような計算パワーを消費する処理は、ごくわずかな入力情報のみを含む（例えば、１０余りの可能なパラメータのうち１つまたは２つのパラメータのみが指定されているか、さらに／またはパラメータの指定された値の範囲が広い）ことで一般に結果が多数になる所謂「オープンクエリ」への応答の際に実行されなければならない。ハードウェア性能を向上させることによりデータ処理を迅速化できる可能性は限られている。このため、大量データ処理の基礎となるメカニズムを改良することが注目されている。

クエリ処理性能を向上させるための１つのアプローチは並列処理である。可能であれば、入来データベースクエリを、いくつかのサブクエリに分割して、サブクエリを並列に処理する複数のデータベースクライアントに分散させる。このようなシステムの一例は、特許文献１に記載されている。これは、スプリッタおよびスケジューラを有するマスタ・プロセッサと、複数の並列に動作するスレーブ・クエリプロセッサモジュールと、を備えるデータベースシステムを開示している。マスタ・クエリプロセッサは、クエリを受け取って、応答をエンドユーザに送り返す。スプリッタは、クエリを、複数の分割クエリに分割する。スケジューラは、分割クエリを、それらを並列に処理する適切なスレーブ・クエリプロセッサに割り当てる。スレーブ・クエリプロセッサの処理結果は、スプリッタによって再編成され、そしてマスタ・プロセッサは、クエリ全体に対する応答を送り返す。

同様のシステムが、特許文献２および特許文献３に記載されている。

クエリ時間を短縮するための別のアプローチは、予想されるクエリについて事前計算を実行して、対応するクエリ結果をメモリシステム内に保持することである。この場合、クエリは、データベースクエリが生じた時に膨大なデータに基づいて実際に処理されることなく、メモリシステムに送られる。このようにして、基礎となるデータドメインでの処理は、実際にクエリに対処することから切り離される。入来クエリに応答する際には、代わりに、事前計算済みクエリ結果のメモリを検索することが必要となる。

そのようなメモリシステムは、例えば、特許文献４に記載されている。これは、顧客の旅行クエリで照会される、旅行価格およびアベイラビリティ・データのメモリについて開示している。メモリは、１つ以上の旅行商品予約システムへのリンクによって、該メモリの更新を担うマネージャを有する。メモリに保持されているデータの更新は、予約システム（複数の場合もある）へのポーリングによって実行され、また、キャッシュに向けられる顧客クエリの処理の過程で個々のメモリデータがベンチマーク日付と比較して古い場合に実施されるか、あるいはそのような顧客クエリとは無関係に、データが失効した場合またはそれ以外に「古い」もしくは「期限切れ」とみなされる場合に実施されるか、どちらかである。

このようなメモリシステムの他の例は、特許文献５に記載されている。この場合、メモリプラットフォームは、基礎データの１つまたは複数のサプライヤに接続されている。メモリは、サプライヤ・データベースにクエリを適用して、メモリに保持されている価格およびアベイラビリティ・データを更新するプリフェッチャを備える。プリフェッチャは、ネットワーク帯域幅および計算パワーが利用できるときに、例えば夜間に、作動させることができる。それは、定期的に、または手動で起動することができる。

同様のメモリシステムは、さらに、特許文献６、特許文献７、特許文献８、および特許文献９で開示されている。

このような事前計算アプローチに伴う課題は、事前計算済み結果で応答されるクエリで、対応する大量基礎データのステータスが正しく反映されることを保証するために、いかにして事前計算済みクエリ結果を最新状態に維持するかということである。基礎となるデータが変更された場合には、事前計算済みクエリ結果は古くなって、メモリシステムは誤った結果を返すことになる。このため、いかにしてメモリシステムを最新状態に維持することができるか、戦略が必要となる。

例えば、データドメイン全体について頻繁に再計算を実行する、手動で再計算スケジュールを立てて維持する、データが古くなり過ぎたときに再計算を実行するなど、いくつかの比較的単純な更新戦略が、従来技術で知られている。このような戦略は、例えば、特許文献５に記載されている。

例えば、特許文献１０および特許文献１１に記載されているように、これより若干高度な更新戦略が開発されている。

特許文献１０は、旅行プランニング・システムで用いられるアベイラビリティ・システムに関するものである。このシステムは、航空機座席に関するアベイラビリティ情報のエントリを含むメモリを備える。メモリ内の情報をできる限り正確に、最新に、完全に、またはそれ以外に有効に維持するために、マネージャがメモリ内のエントリ情報を管理する。メモリに向けられたクエリに応答する際に、マネージャは、保存した応答が失効しているかどうか判断し、そうである場合には、アベイラビリティ情報のソースに対してアベイラビリティ・クエリを送る。修正すべきメモリエントリは、外部システムからの非同期通知によって得られ、決定論的モデル、予測モデル、または統計モデルによって決定される。

同様に、特許文献１１は、情報ソースから受け取った情報について、後のクライアント要求の場合など、後の使用に備えて、事前計算を実行する情報検索システムに関するものである。メモリにポピュレートするため、および／または現在の事前計算済み情報を更新するために、プロアクティブ・クエリを生成することができる。航空会社の情報システムでは、出発時刻の近さ、事前計算済みデータの古さ、航空機の残席数、休日もしくは特別な行事、または機種、などの統計もしくは予測指標に基づいて、プロアクティブ・クエリが発行される。また、更新は、ＡＶＳメッセージなど、航空会社からの外部通知で受け取られる。

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

頻繁なオペレータ作業および許容できないリソース使用量を要することなく、大量データの効果的な処理を確保するために、クエリの無駄な重複を回避しつつ大規模な検索を実行することが可能な改良された予約システムが必要となる。

本発明により、複合データベースシステムを提供する。データベースシステムは、いくつかの構成要素、すなわち、計算プラットフォームと１つまたは複数の検索プラットフォームとで構築される。オプションとして、さらに再計算トリガ・プラットフォームを有する。

計算プラットフォームは、検索プラットフォームから、さらにオプションとして再計算トリガ・プラットフォームから、バッチ再計算命令を受け取るように構成されている。各バッチ再計算命令は、複数のデータベースクエリ結果の計算を、計算プラットフォームに指示するものである。計算プラットフォームは、さらに、バッチ再計算命令で指示されたデータベースクエリ結果を所与の時間枠内でバッチ処理スケジュールに従って計算することにより、バッチ再計算命令を処理し、バッチ再計算命令の結果として得られる再計算済みデータベースクエリ結果を、少なくとも検索プラットフォームに返すように構成されている。

上記少なくとも１つの検索プラットフォームは、事前計算済みデータベースクエリ結果をメモリに保存し、事前計算済みデータベースクエリ結果を、検索プラットフォームに接続されたクライアントが利用できるようにし、さらに、バッチ再計算命令を計算プラットフォームに伝送するように構成されている。

オプションとして、再計算トリガ・プラットフォームを備え、これは、計算プラットフォームで計算された事前計算済みデータベースクエリ結果のミラーを保持し、ミラーリングされた事前計算済みデータベースクエリ結果が失効している確率を決定し、さらに、他の事前計算済みデータベースクエリ結果よりも失効している確率が高い事前計算済みデータベースクエリ結果の部分についてのバッチ再計算命令を、計算プラットフォームに対して発行するように構成されている。

他の態様として、データベース検索結果を処理および表示するためのシステムを提示する。このシステムによれば、データベース検索結果は、まず所定のカテゴリによって分類され、次に第２のステップとして、それらのカテゴリ内でランク付けされる。このようにして、体系的かつユーザに有用な方法で、データベースクエリ結果をクライアントにおいて提示することができる。

以下、添付の図面を例として参照する。

図１は、分散データベースシステムの例示的概要を示している。 図２は、計算プラットフォームの一例を示す図である。 図３は、本発明の一例を実施するシステムのソフトウェアコンポーネント、ならびに本発明の一例による方法の全ステップの全体図を示している。 図４は、計算プラットフォームで実行される計算方法の各種部分の模式的一例を示している。 図５は、計算プラットフォームで実行される計算方法の各種部分の模式的一例を示している。 図６は、計算プラットフォームで実行される計算方法の各種部分の模式的一例を示している。 図７は、計算プラットフォームで実行される計算方法の各種部分の模式的一例を示している。 図８は、計算プラットフォームで実行される計算方法の各種部分の模式的一例を示している。 図９は、計算プラットフォームで実行される計算方法の各種部分の模式的一例を示している。 図１０は、本発明の一実施形態によるプロセスの方法ステップのフローチャートである。 図１１は、本発明の一実施形態による、プレショッピング予約システム用の大規模検索プラットフォームの図である。 図１２は、本発明の大規模検索プラットフォームを実装する可能性のある予約システムを示している。 図１３は、本発明の一実施形態による、プレショッピング予約システム用の大規模検索プラットフォームの個々のモジュールコンポーネントの詳細を示している。 図１４は、本発明の一実施形態による、プレショッピング予約システム用の大規模検索プラットフォームの個々のモジュールコンポーネントの詳細を示している。 図１５は、本発明の一実施形態による、プレショッピング予約システム用の大規模検索プラットフォームの個々のモジュールコンポーネントの詳細を示している。 図１６は、本発明の一実施形態による、プレショッピング予約システム用の大規模検索プラットフォームの個々のモジュールコンポーネントの詳細を示している。 図１７は、本発明の一実施形態による、プレショッピング予約システム用の大規模検索プラットフォームの個々のモジュールコンポーネントの詳細を示している。 図１８は、本発明の一実施形態による、プレショッピング予約システム用の大規模検索プラットフォームの個々のモジュールコンポーネントの詳細を示している。 図１９は、本発明の一実施形態によるプロセスの方法ステップのフローチャートである。 図２０は、再計算トリガ・プラットフォームに関して、データベースシステムの一例の、より詳細な図を示している。 図２１は、再計算トリガ・プラットフォームの一例のコンポーネントを示している。 図２２は、再計算をトリガする例示的方法のフロー図を示している。 図２３は、再計算を実行するための計算プラットフォームにおけるリソース空き状況の一例を示している。 図２４は、旅行オプション検索結果選択システムの運用環境を示すブロック図である。 図２５は、旅行オプション検索結果選択システムの一例の上位機能図である。 図２６は、旅行オプション検索結果選択システムで実行され得るお薦め結果選択アルゴリズムのフローチャートである。 図２７は、図３の選択アルゴリズムにより提供されるお薦め結果のウェブページ表示の図示である。 図２８は、計算プラットフォーム、検索プラットフォーム、および再計算トリガ・プラットフォームをそれぞれ実現するコンピュータの例示的概略図を示している。

［概要説明］
本発明は、広くは、大量のデータセットを、エンドユーザ・コンピュータなどのクライアント、顧客が、例えばウェブポータル、または他の照会エンティティで利用できるようにするために構成された情報処理システムに関する。基礎となる大量データに基づく計算を要するデータベースクエリに対処できるように、一般に、予想されるクエリに対応するデータベースクエリ結果が事前計算されて、事前計算済みデータベースクエリ結果への高速アクセスを可能とするメモリに保存される。実際に発生したクエリへの応答では、事前計算済み結果が、照会エンティティに返される。

本発明の情報処理／データベースシステム１の概略アーキテクチャを、図１で示している。検索プラットフォーム３に接続された計算プラットフォーム２に、基礎データが保持される。図１では、１つのみの検索プラットフォームを示しているが、実際には、複数の検索プラットフォーム３を有し得る。検索プラットフォーム３は、事前計算済みデータベースクエリ結果のメモリを保持しており、データベースクエリを検索プラットフォーム３に送るクライアントに接続されている。検索プラットフォーム３は、保存された事前計算済みデータに基づいて、それらのクエリを処理して、それぞれのクエリ結果をクライアントに返すように構成されている。データベースクエリ結果の事前計算は、事前計算要求に応えて、計算プラットフォーム２により実行される。そのような事前計算要求は、検索プラットフォーム自身で生成されるか、または本システム１の他のオプション要素である再計算トリガ・プラットフォーム４で生成されるか、いずれかである。後者は、同じく計算プラットフォーム２に接続されている。図１では、再計算トリガ・プラットフォーム４を、物理的に別個のエンティティとして示しているが、計算プラットフォーム２または検索プラットフォーム３のどちらかに組み込むこともできる。

以下で、「クエリ」という用語は、トランザクション情報検索を指す用語として用いられる。そのようなトランザクション・クエリは、クエリの発生と同期的に、データベースシステムで直ちに処理される。対応する結果は、できる限り高速で、照会エンティティに返される。トランザクション指向型データベースシステムは、広く普及している。例えば、特許文献１は、トランザクション・クエリをサブクエリ要素に分解することが可能なトランザクション計算システムについて記載しており、クエリの処理は、サブクエリ要素レベルで実行される。

別のタイプの情報検索処理は、バッチ処理である。この方式によれば、照会の処理は、非同期的に、すなわち後に、実行される。従って、処理エンティティは、対応する結果を、直ちにではなく、やはり後にしか、照会エンティティに返さない。つまり、照会の発生と、その処理および対応する応答とは、切り離されている。バッチ指向型処理では、例えば、いつ、どのようにして、何によって、照会を処理するのかを定める処理「計画」を作成することができる。このようにして、処理エンティティで利用できる計算リソースを考慮することが可能である。バッチ指向クエリを、以下では、「バッチ計算要求」または「バッチ再計算命令」と呼ぶ。

一般に、図１に示すような本データベースシステム１は、次のように機能する。計算プラットフォーム２は、大量の基礎データを保持するとともに、バッチ計算要求に応えて、データベースクエリ結果を事前計算する。さらなる詳細は後述する一例では、計算プラットフォーム２で保持される基礎データは、都市ペア、運航日、空席、航空運賃などを含む航空便データのような旅行関連のデータである。この旅行関連データに基づいて、計算プラットフォーム２は、特定の価格の具体的な旅行オファーを計算する。本例では、そのような価格付き旅行オファーが、事前計算済みデータベースクエリ結果を構成し、それらは、計算プラットフォーム２によって検索プラットフォーム３に供給されて、そこで保存される。検索プラットフォーム３は、保存された事前計算済みデータベースクエリ結果を、クライアントが利用できるようにする。計算プラットフォーム２に接続された再計算トリガ・プラットフォーム４は、できる限りメモリ内容を最新状態に維持するために、検索プラットフォーム（複数の場合もある）３に保持される保存された事前計算済みデータベースクエリ結果の再計算のトリガを担うものである。基本的な更新機構は、検索プラットフォーム（複数の場合もある）３に既に備えているものの、再計算トリガ・プラットフォーム４は、検索プラットフォーム（複数の場合もある）３で保存されている事前計算済みデータベースクエリ結果が失効しているかどうかの確率を判定することによって、より高度なメモリ更新戦略を提供する。このような判定を行うために、再計算トリガ・プラットフォーム４は、計算プラットフォーム２で事前計算された事前計算済みデータベースクエリ結果をミラーリングしている（さらに、その他に、追加の管理データおよびメタデータも保持することがある）。これについてのさらなる詳細は後述する。

本システム１によれば、計算プラットフォーム２による事前計算済みデータベースクエリ結果の計算は、検索プラットフォーム３または再計算トリガ・プラットフォーム４のどちらかによって生成される再計算命令により、トリガされる。再計算命令および計算自体は、バッチ指向のプロセスに従う。これは、検索プラットフォーム３または再計算トリガ・プラットフォーム４で発する再計算命令が、検索プラットフォーム３に保持されている、または投入される予定の事前計算済みデータベースクエリ結果の全体すなわち全範囲を、事前計算または再計算する対象として指示することを意味する。オプションとして、再計算命令は、再計算命令を処理するための時間枠を指示し、その時間枠内で計算が実行されなければならず、また、その間は、計算結果が待たれる。あるいは、計算プラットフォーム２が自身で自律的に個々の時間枠を決定するか、または、再計算命令とは別に、計算プラットフォーム２と検索プラットフォーム３／再計算トリガ・プラットフォーム４とのネゴシエーションによって時間枠が決定される。それは、この場合、再計算命令は、命令の実行および結果を返すための時間枠を指示しないことを意味する。計算プラットフォーム２は、バッチ再計算命令を受け取った後に、それをバッチ処理スケジュールに従って処理する。バッチ処理スケジュールは、再計算命令を解析した後に、計算プラットフォーム２で利用できる計算リソースを考慮して、設定することができる。

バッチ再計算命令が処理された後に、個々の計算済みデータベースクエリ結果は、検索プラットフォーム（複数の場合もある）３と、（オプションの再計算トリガ・プラットフォーム４を実際に有して実装されているものと仮定して）再計算トリガ・プラットフォーム４と、その両方に返される。従って、再計算命令が検索プラットフォーム３により発せられた場合、結果は、検索プラットフォーム３に対してのみではなく、再計算トリガ・プラットフォーム４にも返される。一方、再計算命令が再計算トリガ・プラットフォーム４により発せられた場合、結果は、再計算トリガ・プラットフォーム４に対してのみではなく、個々の事前計算済みデータベースクエリ結果を保持する検索プラットフォーム（複数の場合もある）３にも返される。具体的には、複数の検索プラットフォーム３を備える場合に、計算プラットフォーム２は、実際に個々の事前計算済みデータベースクエリ結果を保持しているすべての検索プラットフォーム３に対して、再計算済みデータベースクエリ結果を伝送する。特定の検索プラットフォーム３が再計算済みデータベースクエリ結果の一部のみを保持する場合には、計算プラットフォーム２により、その個別の部分のみが、その検索プラットフォーム３に伝送される。特定の検索プラットフォーム３が、再計算済みデータベースクエリ結果を全く保持しない場合には、その検索プラットフォームには、再計算済みデータベースクエリ結果は全く伝送されない。このようにして、再計算トリガ・プラットフォーム４は、計算プラットフォーム２で計算されて検索プラットフォーム（複数の場合もある）３に保存されたデータベースクエリ結果の整合性のある写しを、常に保持している。

計算プラットフォーム２で実行される計算は、一般に２つの目的を果たすものである。基本的には、それは、新たに検索プラットフォーム３がセットアップされたときか、または計算プラットフォーム２で保持される基礎となるデータドメインが拡張されて、追加のデータベースクエリ結果が得られるようになったときか、いずれかの場合に、事前計算済みデータベースクエリ結果を検索プラットフォーム（複数の場合もある）３に最初に供給するものである。第２に、本発明のシステムに関連性がより高いこととして、それは、検索プラットフォーム（複数の場合もある）で既に保持されている事前計算済みデータベースクエリ結果の更新または再計算を促すものである。これが必要となるのは、事前計算済みクエリ結果をキャッシュして、事前計算済みデータを処理することによってのみ入来クエリに応答する本アプローチは、基礎となるデータドメインのデータが時間の経過とともに変化し得ることで事前計算済みクエリ結果が古くなるという一般的な問題につながるからである。以下で、最新状態のままである事前計算済みクエリ結果、すなわち対応するリアルタイム計算による同等物（利用できるキャッシュされた事前計算済み結果を有することなく、実際にオンデマンドで計算される結果）と一致する事前計算済みクエリ結果は、保存された「正確な」事前計算済み結果と呼ばれる。従って、メモリが、事前計算済みクエリ結果の基礎となるデータドメインの現在の状態を正しく表しているときには、事前計算済み結果のメモリは、全体として正確である。

一般に、事前計算済みデータベースクエリ結果に基づいて正しい結果を返すためには、データベースクエリへの応答の際に照会エンティティに提供される事前計算済みデータベースクエリ結果と、それらのリアルタイム計算による同等物との間に、高い相関を維持することが望ましい。同時に、一方で、再計算によって生じる計算リソース消費を最小限に抑えること、すなわち、まだ正確である事前計算済みクエリ結果の再計算など、不要な再計算を避けることが、望ましい。計算リソースは限られており、一般的には、保存されたすべての事前計算済みクエリ結果を再計算するのに十分な計算リソースが常にあるわけではない。このため、メモリにおけるデータベースクエリ結果の正確な表示と、利用できる計算パワーの使用率と、の間のトレードオフを見つけることが必要となる。すなわち、いつ、どのような再計算要求を生成し、計算プラットフォーム２に送るべきであるかについて、高度なアプローチが必要とされる。

既に冒頭で簡単に述べたような、事前計算済みクエリ結果のメモリを最新状態に維持する単純なアプローチには、いくつかの欠点がある。

データ量および利用可能な計算リソースに応じて例えば１日１回など頻繁にデータドメイン全体を再計算することで、メモリの正確度とリアルタイム応答との妥当なバランスが確保され得る。しかしながら、このアプローチは、ほとんどスケーラブルではないとともに、ハードウェアリソース消費の観点から非効率的である。特に、対応する基礎データが変更されていないため、まだ有効であるクエリ結果も、再計算される。

どのクエリ結果をいつ再計算するべきかを定める再計算スケジュールを人間の管理者が手動で作成することは、特定の目的では効率的であると認められ得るが、融通が利かず、柔軟性に欠ける。スケジュールの基礎となる前提および条件が変わると、もう一度、スケジュールを再作成する必要がある。また、基礎となるデータドメインにおいて大規模な変更があった場合に生じ得る、保存された事前計算済み結果の正確度の急激な低下を、動的に追跡することができない。そのようなスケジュールを手動で設計することは、例えば客観的品質基準がないことからも難しく、また、それを維持することは、人的コストの観点から難しい。

さらに別のアプローチは、データが古くなり過ぎたときに、それらを再計算することである。ところが、基礎となるデータおよび事前計算されるクエリ結果の性質に応じて、「古さ」の良好な閾値を評価することは難しい場合がある。再計算をより効率的にするためには、再計算がどれほど「不要」であるかを評価するためのメトリクスが定義されなければならない。例えば、計算済みクエリ結果の半分未満が古くなる場合に、大規模な事前計算の全体を毎日、再実行するのは無駄である。一方、特定の類のクエリ結果が頻繁に変わることが分かっている場合には、それらを１日に数回、再計算することが、正確度のために有効となり得る。従って、再計算に伴う正確度の向上とコストの両方を考慮して、クエリ結果の正確度を評価または推定する効果的な方法が必要とされる。

本システムでは、様々なタイプの、より高度な更新戦略を採用することができる。基本的な戦略は、検索プラットフォーム３によって実施することができ、その場合、検索プラットフォーム３自身で、バッチ再計算要求を計算プラットフォーム２に送ることができる。オプションとして、もう１つの更新戦略を再計算トリガ・プラットフォーム４によって採用することができる。再計算トリガ・プラットフォーム４で実現されるメカニズムは、検索プラットフォーム３で見込まれるメカニズムよりも高度なものとすることができる。

さらなる詳細は後述する一例によれば、検索プラットフォーム３は、各クエリ結果に更新頻度を割り当てることにより、保存された事前計算済みデータベースクエリ結果を更新する必要度を管理する。更新頻度は、個々の基礎となるデータの変更度を過去の統計データに基づいてモデル化した確率モデルによって決定される。一方、さらなる詳細は同じく後述する一例によれば、再計算トリガ・プラットフォーム４で採用する更新戦略では、加えて、検索プラットフォーム３で保持されている事前計算済みデータベースクエリ結果のある範囲または全範囲が失効する確率を高め得るリアルタイムイベントを考慮に入れる。

再計算トリガ・プラットフォーム４で実施される更新戦略によると、データベースクエリ結果の再計算は、事前計算済みデータベースクエリ結果が失効している確率に基づいて、すなわち、もう一度再計算することにより得られる結果とは異なる可能性がある確率に基づいて、決定される。不正確である確率が少なくともある特定の所与の確率である事前計算済みクエリ結果のみが再計算され、一方、基礎となるデータを未だ正確に反映している可能性が高い他のキャッシュされたクエリ結果、すなわち、失効している確率が低いクエリ結果は、再計算されない。

こうして、検索プラットフォーム（複数の場合もある）３および再計算トリガ・プラットフォーム４で実施される特定のモデルおよびキャッシュ更新戦略に応じて、両エンティティは、バッチ再計算命令を計算プラットフォームに発して、様々に異なる事前計算済みデータベースクエリ結果の再計算を様々に異なるタイミングで起動させることができる。

計算プラットフォーム２に与えられるバッチ再計算命令の一例は、最大２４時間以内に約百万件のデータベースクエリ結果を再計算する命令である（当然のことながら、計算プラットフォームが、一般に、その結果を約定時間枠よりも早く伝送することは自由である）。ところが、実際のシステム、データ量（すなわち、計算プラットフォーム２における基礎となるデータドメインの量と、検索プラットフォーム３で保持される事前計算済みデータベースクエリ結果の件数と、その両方）、採用されるハードウェアおよびソフトウェアによっては、再計算の制約は、さらにかなり厳しくなり得る。よって、バッチ再計算命令の他の例は、わずか２時間以内で約１億件の事前計算済みデータベースクエリ結果を再計算することである場合がある。現在利用できるハードウェアおよびソフトウェアシステムでは、２４時間以内で最大１千億件までの事前計算済みデータベースクエリ結果の再計算が、実際に可能である。計算リソースが拡充されれば、さらに大量のバッチ再計算が可能であると、想定することができる。

オプションとして、計算プラットフォーム２は、さらに、バッチ再計算命令を解析して、複数のデータベースクエリ結果からのサブセットに関する、より小さな計算パッケージに分解するように構成されている。このような分解は、処理されるデータおよび量、計算が実行されなければならない時間枠、利用できる計算リソースを考慮して、バッチ再計算命令を大域的に解析することにより、実施される。これにより、バッチ計算要求全体の、より小さな部分の並列処理が可能となる。その場合、計算プラットフォーム２は、分解の結果として得られる計算パッケージを、それらの計算パッケージの計算を実行するための処理モジュールに割り当てる。こうして、実際の計算は、バッチ再計算命令の全体ではなく、より小さな計算パッケージのレベルで実行される。処理モジュールは、ローカルエリアネットワーク内の他のホストなど、計算プラットフォーム２に疎結合でのみ結合されたスレーブ計算ステーション、または例えば計算プラットフォーム２で実行されるプロセスインスタンスの形で計算プラットフォーム自体に組み込まれた部分とすることができる。後者の場合、計算プラットフォーム２は、マルチコアコンピュータのように複数の処理ユニットを備えると、効果的である。

その後、それらの処理モジュールは、割り当てられた計算パッケージの計算を、略並列に実行して、計算結果を、計算プラットフォーム２に返す。計算プラットフォームは、それらの計算パッケージの計算結果を再編成して、バッチ再計算命令に対する全体的な応答を構成する。最後に、計算プラットフォームは、再編成した結果を、検索プラットフォーム３および再計算トリガ・モジュール４に返す。

例示的な一実施形態では、計算プラットフォームは、２階層のモジュールによって、すなわちマスタモジュールと１つまたは複数のワーカモジュールとで、構成される。本実施例では、マスタモジュールは、バッチ再計算命令を受け取って、グローバル解析を実行し、分解して得られた計算パッケージをワーカ（複数の場合もある）に割り当てることを、担当する。ワーカ（複数の場合もある）は、計算パッケージの実際の計算を実行し、計算結果をマスタに返すことを、担当する。マスタは、さらに、ワーカによる結果を再編成し、再編成した結果を検索プラットフォーム３および再計算トリガ・プラットフォーム４に返すことを、担当する。

オプションとして、バッチ再計算命令を解析して、より小さな計算パッケージに分解するための計算プラットフォーム２の構成には、バッチ再計算命令をアトミック計算トランザクションに分割するための構成が含まれる。これらのアトミック計算トランザクションは、ＳＱＬ文などの通常のトランザクションデータベースクエリに相当し得る。これらのトランザクション・クエリは、その後、そのまま処理ユニットに割り当てられて伝送され、バッチ計算ではなく、トランザクション方式で処理されることができる。このように、バッチ再計算命令は、バッチ処理モデルに従って個々のデータベースクエリ結果を再計算することを計算プラットフォーム２に指示するものであるにもかかわらず、細分された計算パッケージのレベルでの実際の計算は、トランザクション指向で実施される。オプションとして、バッチ再計算命令を分割することによりアトミック計算トランザクションを構成する過程で、冗長アトミック計算トランザクションの解析が実行される。こうして確認された冗長アトミック計算トランザクションは、その後、破棄される。このようにして、複数の同一クエリの不要な計算が回避され、計算リソースがより効率的に利用される。オプションとして、（アトミック計算トランザクションをそのまま処理モジュールに伝送するのではなく）アトミック計算トランザクションの、より大きな計算パッケージへのグループ化が実行される。このとき、計算パッケージは、一般に、複数のアトミック計算トランザクションで構成されるが、ただし、バッチ再計算命令の全体よりは一般に小さい。この場合、処理モジュールによる、それらの再グループ化パッケージの処理は、バッチ計算によるか（すなわち、計算プラットフォーム２は、処理モジュールに対して、分解後のこの下位レベルでの一種のバッチ命令によって、計算パッケージをバッチ処理方式で計算するように指示する）、またはトランザクション方式か（すなわち、計算プラットフォーム２は、クエリを処理モジュールに送り、それらが直ちに計算パッケージを処理して、個々の結果を直ちに返す）、いずれかで実行される。オプションとして、計算プラットフォームは、バッチ処理スケジュールに従って、計算パッケージを処理モジュールに割り当てるように構成されており、バッチ処理スケジュールは、所与の時間枠内で利用できる計算モジュールの計算リソースを考慮することにより負荷分散を提供するものである。

一実施例によれば、検索プラットフォーム（複数の場合もある）３は、以下のように機能する基本的な更新機構を備える。検索プラットフォーム３は、自身が保存している事前計算済みデータベースクエリ結果のそれぞれに、リフレッシュ頻度を表すパラメータ値を割り当てる。このリフレッシュ頻度スコアは、基本的に、そして最初に、保存された事前計算済みデータベースクエリ結果の変更度に関する過去の経験に基づいて設定される。これらの経験は、例えば、予測モデルおよび／または統計データによってモデル化することができる。リフレッシュ頻度スコアは、計算プラットフォーム２にバッチ再計算命令を送ることにより、事前計算済みデータベースクエリ結果の一部の更新をトリガするものである。事前計算済みデータベースクエリ結果の上記一部、すなわち更新されるべき特定の事前計算済みデータベースクエリ結果は、割り当てられたスコアに応じて決定される。つまり、事前計算済みデータベースクエリ結果は、リフレッシュ頻度スコア値で示される頻度で、検索プラットフォーム３によるバッチ再計算命令に含まれる。

検索プラットフォーム３は、その本分に従って、クライアントから受け取ったクエリに応答する際に、そのメモリ内でデータベース検索を実行する。データベース検索によって、クライアントのクエリに含まれるプリファレンスを満たす事前計算済みデータベースクエリ結果を明らかにする。クエリを処理して、対応する結果を見つけた後に、検索プラットフォーム３は、照会クライアントに対して応答を発行する。一方、同時に、検索プラットフォーム３は、クライアントに返された事前計算済みデータベースクエリ結果に割り当てられたスコアパラメータを更新するように構成することができる。例えば、検索プラットフォーム３により保持される特定の事前計算済みデータベースクエリ結果のリフレッシュ頻度スコアは、それが、データベースクエリに応答してクライアントに返されるたびごとに、増加させることができる。このようにして、リフレッシュ頻度スコアを、さらに、クライアントによる実際の関心および要求に適応させる。より多くのクライアントクエリの対象となる事前計算済みデータベースクエリ結果は、一般に、クライアントが示す関心がより少なくてクライアントにより照会されてクライアントに返されることが稀にしかない事前計算済みデータベースクエリ結果と比較して、より頻繁に更新される。

既に上記で指摘したように、再計算トリガ・プラットフォーム４で採用される更新戦略は、検索プラットフォーム（複数の場合もある）３で実施されるものとは異なり得る。オプションとして、事前計算済み結果を再計算トリガ・プラットフォーム４により更新する戦略は、第１の側面として、事前計算済みデータベースクエリ結果のメモリ全体の正確度を予測モデルに基づいて推定する手段に依拠する。第２の側面として、さらに、そのような推定が概ね現実に即しているかどうかチェックし、例えば、保存された事前計算済みクエリ結果の基礎となるデータのかなりの部分が変更され、さらに対応する保存された事前計算済みクエリ結果も、それらの変更によって失効したことを示し得る実際のリアルタイム（かつ現実の）イベントが発生した場合に、モデルベースの再計算戦略が未だ有効であることを検証する。

オプションとして、事前計算済み結果の正確度の推定が全体として依拠する予測モデルは、事前計算済みクエリ結果と、推定される実際のデータベースクエリ結果との間の不一致をモデル化しており、すなわち、それは、キャッシュされたクエリ結果の正確度または不正確度を概算するものである。そのモデルは、例えば、時間経過による事前計算済み結果の推定変更度をモデル化している。事前計算済み結果の変更度についての推定は、個々のデータドメインの対象事項に関する過去の実世界経験から結論付けおよび推定される。

さらなる詳細は後述する具体的な一実施例によれば、基礎となるデータは、航空旅行ドメインのものとすることができ、出発空港および到着空港、航空会社、出発日および帰路日、運賃、予約クラスなどのフライトに関する情報を含むことができる。この航空旅行関連データは、計算プラットフォーム２に保持される。基礎的なフライトデータに基づいて価格を計算することは、リソースおよび時間を要する。このため、実際の価格は、事前計算されて、検索プラットフォーム（複数の場合もある）３に保存される。この場合、フライトのアベイラビリティおよび価格についての知識を得るための顧客による旅行クエリは、計算プラットフォーム２にではなく、検索プラットフォーム（複数の場合もある）３に送られる。上述のように、再計算トリガ・プラットフォーム４は、（検索プラットフォーム（複数の場合もある）３自体の基本的な更新機構に追加的に）検索プラットフォーム（複数の場合もある）３のメモリ（複数の場合もある）の更新を担うものである。

本例では、再計算トリガ・プラットフォーム４で利用される確率モデルは、時間経過による航空価格の変更度をモデル化している。そのようなモデルを構築するために必要な知識は、出発日前の航空価格の動きおよび動向についての実世界経験から得ることができる。例えば、航空価格は、それぞれの出発日の１か月前より前の期間では比較的安定しているが、出発日前の１か月間は、より変更度が高くなることが、認められることがある。従って、確率モデルは、翌月に航行となるフライトについて保存された事前計算済み価格は、それより後のフライトに関連した事前計算済み価格と比較して、より頻繁に再計算されるべきであることを、指示する。確率モデルを用いて事前計算済みクエリ結果の正確度をモデル化することに加えて、リアルタイムイベントに対処することにより、正確度が急激に低下することを防止する。事前計算済みクエリ結果の正確度に影響し得る所定のリアルタイムイベントを受け取ると、再計算の決定は修正される。リアルタイムイベントは非同期的であり、すなわち、それらが発生する時点は所与ではなく、いつでも発生し得る。入来リアルタイムイベントを受け取って処理することを可能とするために、再計算トリガ・プラットフォーム４は、適宜、関連情報を再計算トリガ・プラットフォーム４に通知する通信源への外部インタフェースを備える。

そのようなリアルタイムイベントは、再計算トリガ・プラットフォーム４の予測モデルでは考慮されていない特別な状況に関するものであり得る。例えば、事前計算済み価格の一部は、販売促進による影響を受けることがあり、一方、他の価格は、年間の特定の時期（休暇シーズン、クリスマスなど）に、より変更度が高くなり得る。また、見本市、スポーツイベントなどのような「例外的な」状況、ストライキまたは自然災害のような偶発的な出来事によっても、「通常の」モデルの因果律の基礎となる仮定は変わり得る。このような例外的な状況を表す個々のリアルタイムイベントに応じて、このような特別な影響を、保存された事前計算済みクエリ結果が失効している確率を決定する際に考慮することができる。あるいは、見本市、休暇シーズン、スポーツイベントなどのように予定が決まっているイベントの影響は、イベント当日より前の適時に、確率モデルに取り込むことができる。

注目すべき重要なことは、オプションとして、再計算トリガ・プラットフォーム４の更新戦略は、「不確実」なイベント、すなわち、１つ以上の事前計算済みクエリ結果を無効にすることが確実ではないが、事前計算済みデータベースクエリ結果が失効する確率が高くなり得ることのみ示しているようなイベントを、考慮に入れることが可能であるということである。つまり、このようなイベントは、事前計算済みデータベースクエリ結果の正確度に関して非決定論的であり、検索プラットフォーム（複数の場合もある）３に保持されている事前計算済みデータベースクエリ結果と、計算プラットフォーム２で仮に再計算した結果として推定される実際のデータベースクエリ結果との間の不一致に対して、確率的影響を及ぼすにすぎない。これは、ＡＶＳメッセージで、例えば特定のフライトがキャンセルになったことを示す特許文献１０および特許文献１１に記載の提案とは異なる。結果的に、そのようなＡＶＳメッセージを受け取ると、もはや個々の航空機座席を利用できないことは確実に分かっている。

例えば、上述のような旅行関連データ・ストレージのシナリオでは、事前計算済みクエリ結果の正確度に影響を及ぼす可能性があるにすぎないリアルタイムイベントは、運賃の更新であり得る。運賃は、出発都市および到着都市、予約クラス、フライトタイプ（片道または往復）、金額、および運賃を実際に適用するために満たされるべき制限事項を規定する規則などのパラメータを含むデータのセットである。従って、運賃は、特定のフライトの価格計算のための基礎データを表すものであり、計算プラットフォーム２で保持される。特定の出発／到着都市ペアの運賃が航空会社によって更新された場合、この都市ペアに関して、１つ以上の検索プラットフォーム３に保存されている事前計算済み航空価格は、もはや正確ではない可能性が高くなり得る。ところが、これは、再計算トリガ・プラットフォーム４からすると、保存されている価格の事前計算の際に計算プラットフォーム２で実際に適用された運賃は再計算トリガ・プラットフォーム４には不明であるため、確かではない。例えば、計算プラットフォームによる前回の事前計算に適用された運賃は、実際には変更されていないことがあり、運賃変更イベントで示される運賃の変更によって、前回の該当する運賃が依然として適用されることに変わりはなく、この場合、以前に計算された価格は未だに有効である。あるいは、前回適用された運賃は実際には変更されているが、この変更があったことで、今度の新たな運賃を、当該の航空価格の計算に適用すれば、結果的に、事前計算済み価格は、実際には有効なままとなる。

従って、そのようなリアルタイムイベントが観測された際に、再計算トリガ・プラットフォーム４は、いくつかの事前計算済みデータベースクエリ結果がもはや失効しており、検索プラットフォーム３のメモリを正確に維持するためには、それらを再計算することが効果的であろうということを、非決定論的な可能性で推測できるにすぎない。ただし、これは確かな事実ではなく、個々の事前計算済みクエリ結果は、それらが失効している確率は高まったものの、実際には依然として正確であって、結果的に再計算する必要がないことがあり得る。

オプションとして、事前計算済みデータベースクエリ結果が失効している確率の決定は、再計算トリガ・プラットフォーム４によって、２段階の論理ステップで実行される。第１の論理段階では、おおよそで、確率的予測モデルを用いて、確率が決定される。続いて、第２の論理段階では、これらの決定された確率を、入来リアルタイムイベントに応じて修正することができる。

このようにして決定された確率に基づいて、再計算トリガ・プラットフォーム４は、バッチ再計算命令を自動的に生成して、計算プラットフォーム２に対して、両エンティティ間の適切なネットワークインタフェースを介して発する（上記図１を参照）。一般に、バッチ再計算命令は、失効している確率がより低い他の事前計算済みデータベースクエリ結果と比較して、失効している確率がより高い事前計算済みデータベースクエリ結果について生成される。

この一般的な経験則は、オプションとして、再計算トリガ・プラットフォーム４で、確率の閾値を用いることにより実現される。検索プラットフォーム３に保存されている事前計算済みクエリ結果で、決定された失効している確率がそのような閾値を超えるものは、再計算される必要がある。そこで、個々のバッチ再計算命令が、計算プラットフォーム２に送られる。決定された失効している確率がそのような閾値以下である事前計算済みクエリ結果は、依然として正確である可能性が高いとみなされ、このため、再計算される必要がない。従って、それらは、計算プラットフォーム２に対して発せられる次回のバッチ再計算命令には含まれない。

オプションとして、特定の時間に計算プラットフォームで利用できる計算能力について、再計算トリガ・プラットフォーム４によって、バッチ再計算命令を送る前に、予め考慮される。利用できるリソースを考慮することを可能とするために、再計算トリガ・プラットフォーム４は、計算プラットフォーム２の能力の使用率および／または使用スケジュールと空き計算リソースのそれぞれに関する知識を有する。この関連情報は、両プラットフォーム間の通信リンクを介して投入される。

オプションとして、再計算トリガ・プラットフォーム４は、特定のリアルタイムイベントに応じて再計算の決定を修正もしくはオーバライドするか否かを決定する前に、確率モデルと、発生しているリアルタイムイベントとの関係を考慮するように構成される。基本的に、リアルタイムイベントは、確率モデルに既に含まれているのかどうか、また、どの程度含まれているのかについて、解析される。モデルで十分に表現されているイベントについては、確率モデルに基づいて個々の事前計算済みデータベースクエリ結果の確率を決定する際に、それらの発生が既に考慮されているので、修正は全く必要ない。一方、確率モデルによって全く予測されていない、すなわちモデルに含まれていないリアルタイムイベントの場合には、それは直ちに考慮されて、個々の事前計算済みデータベースクエリ結果に関する確率および再計算命令は、できる限り迅速に修正される。

オプションとして、再計算トリガ・プラットフォーム４は、動向を評価するために、確率モデルに含まれたリアルタイムイベントの発生を、ある程度蓄積するように構成される。確率モデルで概ねモデル化された実際に発生するリアルタイムイベントの蓄積が、その程度がモデルで考慮されているものを超えるバーストを示している場合には、確率が修正され、また、（該当する場合）再計算命令が、適宜オーバライドされる。

オプションとして、再計算トリガ・プラットフォームは、さらに、検索プラットフォーム（複数の場合もある）３で保存されている事前計算済みデータベースクエリ結果のうち失効する件数があまりにも少ない可能性があるイベント、関係ないとみなされ得るイベントを除外するためにも、イベントを蓄積して、グループで解析するように構成されている。また、このような理由で、時間の経過に従ってイベントをログ記録し、収集し、まとめて処理する。このようにして、影響の少ないイベントに対処して、あまりにも広範にバッチ再計算命令が生成されることを防止し、これにより、計算プラットフォーム２における計算リソースコストの過度の増加を回避する。

要するに、事前計算済みデータベースクエリ結果の正確度に対して、所定の程度を少なくとも超えて影響を及ぼす可能性のあるリアルタイムイベントを、再計算トリガ・プラットフォーム４によって考慮することにより、検索プラットフォーム３側での事前計算済みデータベースクエリの正確度の低下への、対処を向上させる。

既に簡単に上述し、さらなる具体的詳細は後述する具体的実施例によれば、本データベースシステム１は、旅行情報管理／予約システムである。本データベースシステムの個々の構成要素、すなわち、計算プラットフォーム２、検索プラットフォーム３、再計算プラットフォーム４については、より詳細に、そのような実施例を参照して後述する。本例では、計算プラットフォーム２は、フライト関連データ、すなわち、出発空港および到着空港、運航日、座席クラスおよびアベイラビリティ・データ、航空運賃のような旅行情報を保持している。このような基礎データによって、計算プラットフォーム２は、価格付き旅行オプションを事前計算する。検索プラットフォーム３は、プレショッピング・プラットフォームとすることができる。実際に旅行を予約する前に、旅行産業のエンドユーザは、通常、実際にフライトの予約を取ることなく、利用できるフライトに関する現行の航空価格を含む情報を得ることを希望する。予約前情報を求めるそのような非契約的要求は、オープンで広範なデータベースクエリの形をとることが極めて多く、それらは、クエリの発生時においてのみ計算されると、膨大な量の計算リソースを要することになる。また、顧客は、自身のクエリに対する応答で、要求した情報が略瞬時に届くことを期待する。従って、価格付き航空旅行リコメンデーションのようなプレショッピング・クエリ結果は、適切に事前計算されて、高速アクセスメモリに保存される。

事前計算済みデータベースクエリ結果、すなわち計算プラットフォーム２で生成される価格付き旅行リコメンデーションは、プレショッピング検索プラットフォーム３に送られるだけではなく、更新解析のために、複製されて再計算トリガ・プラットフォーム４にも保存される。再計算の決定は、プレショッピング検索プラットフォーム３で行うことができるが、しかし特別に、他のアマデウス（Ａｍａｄｅｕｓ）サービスから取得された統計データに基づいて構成され得る確率モデルに基づいて、再計算トリガ・プラットフォーム４によって行うことができる。加えて、航空運賃変更、航空機座席アベイラビリティ変更、予約クラス失効、クライアント航空チケット要求、ユーザ品質フィードバック・イベント、フライトキャンセルおよび／または同様のものなど、リアルタイムイベントが考慮される。

他の態様によれば、本システムは、データベース検索結果を特別な方法で処理および表示するための構成を備える。より具体的には、データベース検索結果は、まず第１に、所定のカテゴリによって分類され、次に第２のステップで、それらのカテゴリ内でランク付けされる。このようにして、体系的かつユーザに有用な方法で、データベースクエリ結果をクライアントにおいて提示することができる。これを、図１において、「お薦め結果」と称するクラウドで表示している。「お薦め結果」をクライアントに提供するための個々のメカニズムは、検索プラットフォーム３で実施することができ、さらにオプションとして追加的に、計算プラットフォーム２で実施することができる。

さらなる詳細は、サブチャプタ「検索結果処理／表示サブシステム」において後述する。

［詳細説明］
計算プラットフォーム
図２は、計算プラットフォーム２の実施例を示しており、これは、本発明の計算プラットフォームの一例による、フライトと価格についての大規模な計算に専用のものである。そのデータ処理は、予約専用のショッピング・トラフィックから切り離されている。

本計算プラットフォーム２は、予約アプリケーションで用いられるトランザクションとは異なり、高い自由度でクエリを管理する。そのような自由度は、例えば、期日の組み合わせ（年間のすべての往航日、往航日から数週間までのすべての帰航日）、出発地および目的地の地理的ゾーン、希望の運航航空会社（希望の都市ペアについて、１つ、複数、または可能なすべての航空会社）、利用できるすべての予約コード、可能なすべての搭乗者タイプ、に当てはまる。

このようなデータ計算では、低レイテンシは必須ではないので、時間枠はリアルタイムでなくてもよい。従って、処理ならびにリソース消費を、２時間、４時間、８時間、１２時間、２４時間、またはさらに長い時間枠など、より長い時間枠にわたって分散させることができる。その結果を返送することは、それに応じた時間枠に分散される。

本計算プラットフォーム２は、バッチモデルに従って編成され、そのリソースは、大量のデータに対処するために動的にインスタンス化することができる。それは、グローバル解析に基づいて、データ処理を最適化する。また、それは、汎用で、拡張可能である。様々に異なる顧客の要求を満たすために、計算が実行される基礎となるデータの性質に応じて、様々に異なるビジネスロジックを、計算プラットフォーム２に容易に組み込むことが可能である（旅行ドメインのプレショッピング、収益管理、運賃分析、または他のドメインの完全に異なるロジックなど）。

一例では、本計算プラットフォーム２は、１つまたは複数の大規模マスタ２０と、複数の大規模ワーカ２２と、を備える。大規模マスタ２０は、入来バッチ再計算命令を大域的に解析し、そしてそれを最適化された要求に分解する。それらの要求は、その後、大規模ワーカ２２のうちの１つ以上によって処理され、その結果が元の大規模マスタ２０に返されて、そこで結果は価格付き旅行ソリューションに編成される。

一例では、本計算プラットフォーム２は、バッチ再計算命令をアトミッククエリに分解して、無駄な再処理を避けるために、アトミッククエリ間の関連する冗長を識別することを目的とするグローバル解析を実行する。冗長クエリ部分のマージは、リソース消費の面と、処理におけるデータアクセスの面で、効率的でなければならない。計算プラットフォーム２は、機能要件と技術要件を同時に満たす必要がある。一方で、検索プラットフォーム３との間で確立されるサービスレベルアグリーメント（時間的制約、品質）を順守する必要があり、他方で、運用要件（リソース制御、他の構成要素に対する影響）を守らなければならない。図２に示す例の計算プラットフォーム２は、以下の２種類のサーバ／エンティティを備える。
入力と出力を最適に管理するために必要なグローバル情報収集のホストとなる大規模マスタ２０。
計算プラットフォーム２に組み込まれた各プロダクトのビジネスロジックを実施する大規模ワーカ２２。

図３は、本計算プラットフォーム２の一例によるプロセスの流れを示している。全体の流れを、並列に実行可能な以下の６つのステップ／オペレーションに分割することができる。
− 分割：大規模マスタ２０によって、顧客クエリから、すべてのユニタリ要求を抽出する。
− 最適化：大規模マスタ２０によって、スマートな要求マージのためのグローバル解析を実行する。
− 割り当て：大規模マスタ２０によって、スマートに、要求を大規模ワーカに振り向ける。
− 計算：最適化された要求を、大規模ワーカ２２によって処理する。
− ストリーミング：大規模ワーカ２２によって、結果ボリュームを管理する。
− 集約：大規模マスタ２０によって、結果を顧客クエリに従ってグループ化する。

それぞれのステップについて、以下のパラグラフで詳細に説明する。

図４は、分割オペレーション、すなわち顧客から受け取ったクエリからのユニタリ要求の抽出の、模式図を示している。分割オペレーションは、クエリをユニタリ要求に変換することである。ユニタリ要求は、期日情報、地理情報、搭乗者情報、航空会社情報がすべて設定された自由度を持たないトランザクションと、論理的に等価なものである。

入力管理モジュール２００は、顧客から送られたクエリのセットを検出する。ある時点で、クエリを全く受け取っていない場合は、以前に処理されたクエリのセットを処理するという決定をすることもできる。この機能によって、顧客が、一定の期間内に（例えば、毎日）クエリのセットを送ることを余儀なくされることはなくなる。入力管理ステップでは、さらに、例えば１日に１回または数回など、各クエリの処理の頻度を決定する。入力管理モジュール２００は、さらに、入力ボリュームを処理するためのタスクのインスタンス化を決定する。以降のステップで必要なリソースを、クエリ数ならびに顧客との間で設定された処理時間枠に応じて評価する。これによって、制限された遅延で、大規模データの計算が実行されることが保証される。

入力チェックモジュール２０１は、入力を構文的にも意味的にもチェックする。このステップはプロダクトに依存するので、様々に異なる入力タイプを管理するために、様々に異なるプラグインが追加される。新たなプロダクトまたは新たなプロダクトバージョンの場合は、新たなプラグインが追加される。

抽出モジュール２０２は、クエリで顧客から得た意味情報から、ユニタリ要求を生成する。この抽出は、プロダクトと、顧客から得た入力と、その両方に依存する。従って、このステップは、プラグインが可能である。また、いくつかの顧客機能制限に、ビジネスルールを適用することができる。

そのような文脈で適用されるビジネスルールの一例は、国内市場について、より高いアベイラビリティ品質を要求する（例えば、アベイラビリティを航空会社にポーリングする）ことであり得る。

図５は、最適化オペレーション、すなわち顧客要求のグローバル解析の、模式図を示している。ユニタリ要求が生成されたら、次のフェーズでは、計算最適化を目的として、冗長部分のマージ処理を行う。このオペレーションは、以下で詳述するいくつかのステップで構成されている。グローバル解析モジュール２０３は、ユニタリ要求の冗長を識別する。効率的な最適化のために、本ステップは、各プロダクトでグループ化されるべき最も関連性の高い冗長を定義するプラグインに基づいている。

マージモジュール２０４は、冗長処理を避けるために、ユニタリ要求をグループ化する。いくつかのスマートマージが可能である。その場合、グループ化の選択は、プロダクトに固有の最適ルールを定義するプラグインと、顧客機能制限に応じたビジネスルールと、その両方に基づいている。

ビジネスルールの例：要求のグループ化は、顧客が希望する時間枠での処理に基づく。国内市場の要求は、オフィス閉鎖時間後に、すなわち可能性のある最後の手動更新の後に、処理されなければならず、一方、他の市場の要求は、直ちに処理され得る。

定期的に処理されるクエリの場合、それぞれのプロセスで生成される結果の重要な部分は、同じとなる。ヒューリスティックモジュール２０５は、前回のプロセスで顧客に返されたものと同じ結果を生成するはずの要求を統計的に識別する。それらの要求は処理されない。このようにして、不要な価格計算を削減する。本モジュールによって、リソース消費が節約される。それでも、グローバル結果の良好な正確度が保証される。

図６は、割り当てオペレーション、すなわち要求処理を駆動することの、模式図を示している。第１のマージされた要求が生成されると、それは処理される。前述のステップと並列に実行される割り当てステップでは、要求を、リソースに応じて大規模ワーカ２２に帰属させる。このオペレーションは、以下で説明するようないくつかの異なるモジュールで実現されるいくつかのステップで構成される。要求プロバイダモジュール２０６は、大規模ワーカ２２に送られる要求を、それらがどのクエリから生成されたのかに応じて選択する。本モジュールの目的は、システムが、顧客に対して、そのクエリの結果を漸進的に返すことを可能にすることである。要求は、あるクエリのグローバル結果を計算するように選択される。そのクエリの結果が計算されると、別のクエリに関する要求が選択される。他の選択基準は、マージされた要求それぞれの認可された処理時間枠である。例えば、一部の要求処理は、航空会社のオフィス閉鎖時間後に遅延される。こうして、結果の計算に使用されるデータの最後の手動更新が考慮される。

ペーシング／プライオリティモジュール２０７は、利用できるリソースに応じて、オーバロードを回避することにより、大規模ワーカ２２のアクティビティを調整する。また、さらに、処理される要求間の優先順位を管理する。例えば、ファストトラック・モードで要求されたクエリセットは、このため、標準のクエリセットよりも高い優先度で処理されなければならない。より多くのリソースが、そのようなクエリの計算に専用とされる。

大規模ワーカターゲッタモジュール２０８は、要求が処理されるべき大規模ワーカのファームを選択する。この選択は、技術的配慮（大規模ワーカ２２のリソース空き状況）と、機能的配慮（大規模ワーカファームは、一部の市場、プロダクト、または顧客に専用である）と、その両方に基づく。

図７は、運賃計算オペレーション、すなわちビジネスロジックの、模式図を示している。大規模ワーカ２２は、本計算プラットフォームの一例による方法で提供されるすべてのプロダクトのビジネスロジックを実施する。要求復号化モジュール２２０は、大規模マスタ２０により供給される最適化された要求を復号する。プロセスは、その後、ＧＤＳ内に既にある様々なモジュールを呼び出すことにより駆動される。呼び出されるモジュールならびに呼び出し手順は、プロダクトによって異なる。呼び出されるモジュールのそれぞれは、各プロダクトに固有の応用プラグインに基づくものである。旅行処理モジュール２２１は、要求のフライトソリューションの計算を実施する。これは、要求の中で指定された期日情報、地理情報、オプション情報から、旅行組み合わせを同定することを担当する。旅行処理は、最新データに依拠する。アベイラビリティ処理モジュール２２２は、旅行ソリューションのアベイラビリティのチェックを実施する。より高い品質レベルを求めて、より最新のデータに依拠するように、航空会社に対して直接、要求を行うことができる。運賃エンジン処理モジュール２２３は、要求の中で指定された情報およびオプションに従って、要求に対する可能なソリューションの価格計算を実施する。より良いソリューションのみが要求される場合には、さらに価格を比較することで、最良のもののみを保持する。

図８は、ストリーミングオペレーション、すなわち生の結果の管理の、模式図を示している。バッチ再計算命令および関連の計算により生成される膨大なボリュームを管理するために、大規模マスタ２０との通信、および結果の記憶の両方を最適化するオペレーションが必要である。以下で詳述する大規模ワーカ２２のいくつかのモジュールによって、この最適化が可能となる。圧縮モジュール２２４は、結果のサイズを縮小し、これにより、大規模ワーカ２２と大規模マスタ２０との間の通信量が減少する。また、記憶されるデータ量も減少する。本オペレーションは、処理リソースを消費するので、通信およびストレージのリソース消費の利得が適切である場合にのみ適用される。また、分割／バッファリングモジュール２２５も、リソース消費の最適化を可能にする。生成された結果の結果ボリュームがあまりにも大きい場合には、それはいくつかの束に分割される。この場合、大規模マスタ２０との通信と、データ記憶とは、並行して実行される。結果ボリュームが小さすぎる場合には、それは、大規模マスタ２０によって管理されるのに適切となるまでバッファリングされる。適切なボリュームを処理する少数の記憶モジュールのみ必要であるので、通信は、より効率的である。大規模マスタターゲッタ２２６は、大規模マスタ２０を選択する。この選択は、技術的配慮（大規模マスタ２０のリソース空き状況）と、機能的配慮（大規模マスタファームは、一部の市場、プロダクト、または顧客に専用である）と、その両方に基づく。

図９は、集約オペレーション、すなわち顧客への出力の管理の、模式図を示している。あるクエリのすべての結果が生成されたら直ちに、それらは集約されて、適切なフォーマットで顧客に返される必要がある。結果集約モジュール２０９は、大規模ワーカ２２からの生の結果を、価格指向の結果に変換する。結果は、顧客クエリに従って集約される。顧客は、その質問に対する回答を受け取るのであって、無秩序に結果を受け取るのではない。例えば、顧客が、いくつかのオプションによって特定の市場のソリューションを年間のすべての往航日についてクエリで要求した場合、クエリのすべてのオプションおよびすべての往航日に対応するすべてのソリューションが、返答に集約される。プラグインによって、各プロダクトおよび各顧客について、期待される結果フォーマットが定義される。差分モジュール２１０は、前回の処理から変更された結果を選択する価格パッケージングオプションである。古くなった結果の新しく更新されたもののみが、顧客に返される。プラグインによって、プロダクトに応じた差異の基準が定義される。このオプションによって、ＧＤＳと顧客との間で、効率的なネットワーク転送が可能となる。また、顧客システム上でのアクティビティは、管理しなければならないボリュームがより少ないので、減少する。圧縮／暗号化モジュール２１１によって、返送されるボリュームを減少させるとともに、結果の機密性を確保することで、効率的かつ安全なネットワーク転送が可能となる。トリックリング返送モジュール２１２は、処理されたクエリのグローバル結果をグループ化することにより、定期的に転送する。これにより、返送は、より長い時間スケールに分散される。結果のボリュームは大規模であるため（例えば、百万件を超える再計算済み価格付き旅行リコメンデーション）、検索プラットフォームは、結果の統合まで処理の終了を待ちたくはない。このため、処理の開始後わずかな時間で、最初の結果が生成されて返される。転送は、処理時間枠にわたって分散される。このようにして、結果を、顧客プレショッピング／収益管理システムに漸進的に統合することができる。

オプションとして、計算プラットフォーム２は、計算プラットフォーム２で再計算されたデータベースクエリ結果／価格付き旅行リコメンデーションがバッファリングされるキャッシュ（図２では示していない）を備える。検索プラットフォーム（複数の場合もある）３および／または再計算トリガ・プラットフォーム４から届くバッチ再計算命令は、計算プラットフォーム２のこのキャッシュから直接提供され得る。計算プラットフォーム２のキャッシュは、詳細は図２５に関連して後述されるキャッシュマネージャを備えることができる。

計算プラットフォームのより具体的な使用例：
例１：プレショッピングシステム用のプロダクト。
以下、プレショッピングシステムを提供する専用のプロダクトについて考える。これは、指定された都市ペアおよび航空会社と一致するフライトソリューションのそれぞれについて、往航日と滞在期間のすべての組み合わせに関して最安の適用価格を計算するものである。その計算は、運賃表発行機関を介してＧＤＳに自動的に提出されるすべてのデータに依拠する。リコメンデーションは、そのフライトに空席がある場合にのみ、返される。空席状況をチェックすることは、大量のリソースを消費するため、このオペレーションは、航空会社としてパートナを含む顧客のクエリに対してのみ実行される。ユニタリ要求を生成することにより、分割モジュールは、ビジネスルールによって要求の中のパートナを識別することが可能であり、それらの要求に対して、「空席状況チェック」を有効にするためのフラグを設定する。最適化モジュールによって、期日の組み合わせによる冗長を防ぐように、旅行要求をマージする。マージオペレーションでは、本プロダクトに固有の運賃エンジンプロセスの最適化を考慮したプラグインを使用する。

例２：収益管理システム用のプロダクト
以下、収益管理を提供する専用のプロダクトについて考える。これは、指定された市場と一致するフライトソリューションのそれぞれについて、往航日、滞在期間、事前購入条件、および予約コード（以下、ＲＢＤ）のすべての組み合わせに関して最安の適用価格を計算するものである。旅行全体に、同じＲＢＤが使用されなければならない。その計算は、運賃表発行機関を介してＧＤＳに自動的に提出されるすべてのデータに依拠する。今から４５日以内の往航日の要求の計算は、１日のオフィス営業時間中に顧客によってＧＤＳに手動で提出されるすべてのデータに依拠する必要がある。最適化モジュールは、期日の組み合わせおよび事前購入を束ねることで、旅行ソリューションの計算を最適化する。マージする際に、今から４５日以内の往航日の要求を分離するためのビジネスルールを適用する。それらの処理は、ＧＤＳに提出される手動更新を考慮して、顧客のオフィス閉鎖後に遅延される。運賃計算モジュールは、フライトソリューションのＲＢＤを返す専用の旅行処理プラグインを使用する。プロダクトがショッピングまたはプレショッピング・ビジネスに専用のものではないため、アベイラビリティ処理プラグインは使用されない。本プロダクトは、（期日、事前購入、およびＲＢＤの組み合わせにより）最適化された要求ごとに数千件の結果を生成するので、ストリーミングモジュールは、大規模ワーカにおいて生の結果の分割を実行する。

本計算プラットフォーム２の一例を実現する上述の方法を、さらに図１０に示すダイアグラムにも示している。この方法は、黒丸２３で開始し、次にボックス２４に進み、そこで計算プラットフォーム２によりバッチ再計算要求を受け取る。そのような再計算要求は、本例では、検索プラットフォーム３または再計算トリガ・プラットフォーム４のどちらかにより送られた旅行クエリの集まりを含むものである。本データベースシステムの一例では、バッチ計算要求を受け取って、検索プラットフォーム３の要求を満たすための計算を実行する計算プラットフォーム２は、実際の検索プラットフォーム３自体とは別個のものであるが、これら２つのプラットフォーム（計算プラットフォーム２と検索プラットフォーム３）を１つに統合することもできることは、当業者であれば理解できるであろう。また、本データベースシステム１は、複数の検索プラットフォーム３が計算プラットフォーム２に接続された構成を含む。一例では、利用できるフライトおよび旅行についての予約前情報をユーザに提供するプレショッピング・プラットフォームと、プレショッピングの後の実際の予約の実行を担う予約プラットフォームと、この２つの検索プラットフォーム３を有する。バッチ再計算要求を受け取ると、制御はボックス２５に進み、そこでバッチ再計算要求の前処理が実行される。前処理が起動される時点、または前処理の開始をトリガするイベントは、いくつかの因子によって決まり得るものであり、さらに、システム管理者もしくは個々のユーザによってカスタマイズすることもできる。例えば、所定の期間ごとに（例えば、１日の終わりに、または１時間ごとに）前処理を実行することができ、限界量のクエリを受け取った時もしくは最大許容量に達した時に自動的に実行することができ、または同じく管理者もしくはユーザがそれを要求することができる。本発明の一例によれば、バッチ再計算要求の前処理には、複数の旅行クエリを含むバッチ再計算要求のグローバル解析が含まれ、それは、データベース照会アクティビティを最適化するために、（図３では「ユニタリ要求」とも呼ばれる）単純な要求要素に分解される。本計算プラットフォームの一例では、各クエリは、大規模マスタ２０（前処理モジュール）によって解析されて、これにより、１つ以上の単純な要求要素が抽出される。これらの単純な要求要素は、次に、重複を避けるために再編成されて、いくつかの因子を考慮した所定の基準に従って、さらには図５を参照して上述したようなビジネスルールに従って、（図３では「最適化された要求」とも呼ばれる）サブセットに編成（分割）される。この前処理は、すべての旅行クエリが前処理されるまで継続する（ボックス２６）。要求が最適化されたら、大規模マスタ２０は、各サブセットを適切な大規模ワーカ（複数の場合もある）２２に割り当てて、選択された適切な大規模ワーカにその要求サブセットを転送する（ボックス２７）。その後、それぞれの大規模ワーカ２２は、単なるいくつかの例として、例えば、旅行運賃、旅行アベイラビリティなど、ユーザの要求を満たすように、データベースで照会を実行する。次に、それらの照会の結果は収集され、大規模マスタ２０に送り返されて、応答を発行することにより、旅行クエリを提示した検索プラットフォーム３または再計算トリガ・プラットフォーム４に提供される（ボックス２８）。本計算プラットフォームの一例では、結果は、上述のように、他のプラットフォームに返される前に、大規模マスタ２０によって集約される。その後、プロセスは、ステップ２９で終了する。図１０を参照して上述した例では、本方法を実行する計算プラットフォーム２は、１つの大規模マスタ２０と、複数の大規模ワーカ２２と、を備えるが、ただし、例えば、並列に動作する複数の大規模マスタ２０、あるいは複数のサブセットを処理する１つのみの大規模ワーカ２２など、他の実施形態も可能である。また、大規模ワーカ２２と大規模マスタ２０は、必ずしも異なる物理マシンに対応する必要はなく、単に同じコンピュータシステム上で動作するアプリケーションとすることも可能である。

要するに、本明細書で提示する計算プラットフォーム２は、以下の点を特徴とすることができる。

１．予約システムにおいて、非契約的な旅行クエリに応じて価格付き旅行ソリューションを生成する方法であって、予約システムは、複数のパラメータに応じた旅行のアベイラビリティおよび運賃に関する情報を含む複数の旅行データベースにアクセスでき、それぞれの旅行クエリはプリファレンスのセットを含み、各プリファレンスは、上記複数のパラメータから選択されたパラメータに関するものであり、本方法は、
− 複数の旅行クエリを受け取ることであって、各旅行クエリは、あるユーザに関連付けられる、複数の旅行クエリを受け取ることと、
− 複数の旅行クエリを前処理することであって、前処理は、
− 各クエリから少なくとも１つの単純な要求要素を抽出することと、
− 少なくとも１つのパラメータに従って、複数の要求要素をソートすることと、
− 少なくとも１つの同じパラメータについて、複数の要求要素が同じプリファレンスを含む場合に、重複する要求要素を削除することと、
− 所定の基準に従って、複数の要求要素をサブセットに分割することと、を含む、前処理を実行することと、
− 複数のデータベースに問い合わせする要求要素を実行する処理モジュールに、要求要素の各サブセットを伝送することと、
− 処理モジュールから結果を収集して、それぞれの旅行クエリへの応答をユーザに対して発行することと、を含む。

２．特徴点１の方法において、処理モジュールから収集された結果は、ユーザに対して応答を発行するに当たって、集約される。

３．先行するいずれかの特徴点の方法において、要求要素の各サブセットの要求要素を実行するステップは、複数の処理モジュールで並列に実行される。

４．特徴点３の方法において、複数の要求要素を分割するステップは、所定の基準に従って、各サブセットを複数の処理モジュールのうちの１つに割り当てることを含む。

５．先行するいずれかの特徴点の方法において、複数の旅行クエリを前処理するステップは、複数の前処理モジュールにより並列に実行される。

６．特徴点５の方法は、さらに、
− それぞれの要求要素の結果について、それを集約して、ユーザへの応答を発行するために、処理モジュールは、複数の前処理モジュールのうちの１つを選択して、それに対して、その結果を伝送すること、を含む。

７．先行するいずれかの特徴点の方法において、複数のパラメータには、期日および地理的位置が含まれる。

８．コンピュータプログラムであって、該コンピュータプログラムがコンピュータ上で実行されることで、先行するいずれかの特徴点による方法のステップを実行するための命令を含むコンピュータプログラム。

９．特徴点８のコンピュータプログラムを具現化するコンピュータ可読手段を含むコンピュータプログラムプロダクト。

１０．特徴点１〜７のいずれかの方法を含むプレショッピングシステムを提供する専用のソフトウェアツール。

１１．特徴点１〜７のいずれかの方法を含む収益管理システムを提供する専用のソフトウェアツール。

１２．特徴点１〜７のいずれかの方法を含む運賃分析システムを提供する専用のソフトウェアツール。

１３．プレショッピング旅行クエリを管理するためのデータ処理システムであって、データ処理システムは、複数のパラメータに応じた旅行のアベイラビリティおよび運賃に関する情報を含む複数の旅行データベースにアクセスでき、それぞれの旅行クエリはプリファレンスのセットを含み、各プリファレンスは、上記複数のパラメータから選択されたパラメータに関するものであり、本システムは、特徴点１〜７のいずれかの方法を実行するように構成された１つまたは複数のコンポーネントを含む。

１４．特徴点１〜７のいずれかの方法を実施するためのデータ処理システムにおいて展開されるサービス。

検索プラットフォーム
一実施例では、本検索プラットフォーム３は、事前計算済み航空旅行価格を保存することを目的とし、いくつかの利点を提供する。しかしながら、他の種類のアプリケーション、およびユーザによる利用が可能にされるべきデータも想定される。留意すべきことは、本明細書に記載の検索プラットフォームの技術的特徴は、検索プラットフォームで保持されるデータの種類およびその内容によって左右もしくは限定されるものではないということである。

以下で記載する例によれば、検索プラットフォーム３は、航空旅行のカタログ全体を保持するように設計されている。それは、例えば、今後の年間のすべての期日、旅行者の滞在期間に応じた１日あたりの可能ないくつかの価格についての、何千もの市場の最良の価格を保存することができる。検索プラットフォーム３は、保存される市場の数がいくつであっても、それに合わせてスケーリングされる分散タイプのものとすることができる。これは、次のような効果によって、航空旅行データのストレージを最適化する。
− 旅行検索効率：検索トランザクションの達成可能な応答時間は、その複雑さにかかわらず（無指定の目的地、年間全体の検索、など）、数十ミリ秒である。
− 旅行データ更新効率：更新によるストレージ全体に対する影響は限定されており、これにより、新規データを即座に利用可能とする継続的な更新が可能となる。
− 旅行データ保存効率：データは、多くのカタログで共通している場合に、ファクタライズすることが可能であり、これにより、ストレージコストがさらに削減される。
これによって、耐え得るコストで、高品質のプレショッピング旅行リコメンデーションを維持することが可能である。検索プラットフォーム３は、再計算が必要な旅行価格を検出するための各種エンジンを有する。これにより、ハードウェアリソースを節約するように、部分的な再計算を駆動することが可能である。節約されたリソースは、他の再計算に再投入することができ、これによって、ユーザの観点から、事前計算済みデータベースクエリ結果の（８０〜９０％の範囲の）より高い正確度が達成される。

本例による検索プラットフォーム３は、その顧客および旅行プロバイダのニーズに応じて、様々に異なる種類の検索プロダクトを提供する。例として、航空会社は、その航空会社ならびにそのパートナについてのリコメンデーションを取得するための検索プロダクトが必要となる。一方、オンライン旅行代理店は、航空会社を選別することなく、あらゆるタイプの航空旅行を取得するための検索プロダクトが必要となる。これら２つのプロダクトは、内部特異性を有することができ、適宜、最適化することができる。

図１１は、本発明の検索プラットフォームの一例により、航空旅行リコメンデーションを保存および検索するための検索プラットフォーム３を示している。保存されたカタログまたは航空旅行リコメンデーションは、分散システムを構成するすべてのマシンに分散される。それぞれのマシンでは、グローバルデータのサブパートが、高速データアクセスのために、高速アクセスメモリ位置（例えば、ＲＡＭ）に保存される。図１１は、本検索プラットフォーム３の例示的なアーキテクチャの論理ビューを提示している。これは、物理的に分散されていても、またはそうでなくてもよいが、本システムの論理ビューは、以下の２つの主なグループに分割することができる。

データベース３０１および方形ボックス３０２、３０３は、検索プラットフォーム３の典型的な部分を表している。データベース３０１は、リコメンデーションのプールに論理的にグループ分けされたすべての航空旅行リコメンデーションを表現しており、それらは、物理的にいくつかの異なるマシンにわたって保存されている。方形ボックス３０２、３０３は、フィードエンジンと検索エンジンを表している。
− フィードエンジン３０２は、事前計算済み航空旅行リコメンデーションのグループ（例えば、同じ都市ペアのすべての旅行）にインデックス付けして、それらを、分散システムのマシンのうちの１つに保存する。
− 検索エンジン３０３は、それらの物理マシンにわたってデータグループを検索し、ユーザからのクエリに応答するためのインデックス検索機能を提供する。

楕円アイテム６、８、３０４、３０５は、一連の解析エンジンを表している。これらの目的は、データベースシステムのハードウェアコストを最適化することである。これらは、毎日、再計算されるデータベースクエリ結果の件数と、検索プラットフォーム３に保存された事前計算済み価格の正確度（最新性）との間の、良好な妥協点に達することを図るものである。これらのエンジンは、フィードオペレーションおよび検索オペレーションを解析して、検索プラットフォーム３に保存されているデータの変更度および品質に関するメトリクスを生成する。これらのエンジンのうち一部のものは、グローバルディストリビューションシステム（本発明の一部ではない）で利用できるサービスなど、アクセス可能であり得る他のサービスを利用する。これらのエンジンは、具体的には以下の通りである。
− 学習エンジン３０４は、毎日、プラットフォームに保存されている旅行リコメンデーションを解析することで、いくつかの期日および市場に及ぶ価格の変更度に関する、すなわち価格に変化がない状態がどれほど長く続くのかに関する情報を抽出する。
− 人気度エンジン６は、最も多く要求された、または最も多く返送された旅行リコメンデーション（期日ごとに、市場ごとに、など）を追跡することで、システムに保存される最も適切なデータに関するメトリクスを得る。
− 正確度エンジン８は、システムに保存されている旅行リコメンデーションと実際の購買価格との間の不一致を、すなわち、もはや予約できないフライト、または価格が変更されたフライトを、検出することを試みる。
− レポートコーディネータ３０５は、上流のエンジンの結果を集約して保存する。その役割は、利用できるリソースを前提として、先行するエンジンの結果に基づき、フライトデータ全体のどの部分を再計算する必要があるか判断することである。このような判断は、アルゴリズムに従って行われる。
本例の検索プラットフォーム３では、これらすべての解析エンジンは、フィードエンジンおよび検索エンジン（３０２，３０３）と並列に動作し、このため、クライアントにとって、それらの動作による性能へのマイナスの影響はない（応答時間の低下はない）。

図１２を参照すると、検索プラットフォーム３と計算プラットフォーム２との間の結合の一例を示している。このようなシステムは、サブチャプタ「計算プラットフォーム」において上述したもののような計算プラットフォーム２による供給を受ける検索プラットフォーム３を備える。両プラットフォームは、さらに、例えばグローバルディストリビューションシステム（ＧＤＳ）により提供されるものなど、他のサービス５とも対話することができる。図１２は、検索プラットフォームにおいて旅行リコメンデーションのカタログ全体を保存するために辿る高レベルフローを示している。

このプラットフォームの顧客として、旅行プロバイダ（航空会社、旅行代理店、など）は、自身の旅行ドメインのどの部分を検索プラットフォームに統合したいのかについて、決定する。この点で、これらは、旅行リコメンデーション計算システムへの一連の再計算命令であるいわゆる大規模クエリを、旅行リコメンデーション計算システムに送る。これらの命令は、考慮すべき市場（例えば、今後の年間のすべての期日についての都市ペアのリスト）ならびに生成すべき旅行リコメンデーション（例えば、それぞれの期日について、１〜２０日間の旅行の最良のリコメンデーション）を詳細に示すものである。このような命令は、顧客によって頻繁に見直されることができ、または、それらを、繰り返し計算するためのベースとすることができる。

旅行リコメンデーション計算システムは、要求されたリコメンデーションを計算するために、ＧＤＳの内部サービスを利用する。数あるサービスの中でも特に、現在あるフライトのリストを取得する旅行サービス、運賃とフライトの最良の組み合わせを見つけるプライシング・サービス、現在予約できる空席を調べるアベイラビリティ・サービスなどを、リコメンデーションを生成するために利用することができる。

リコメンデーションが生成されると、計算プラットフォーム２は、それらの結果を、統合のために検索プラットフォーム３に送る。受け取られたリコメンデーションは、事前計算済み旅行リコメンデーションのグローバルメモリにポピュレートするための専用のメモリ位置に保存されて、その後の顧客の検索クエリに利用できるようになる。旅行リコメンデーションが統合されたら、いくつかの監視タスクがバックグラウンドで実行され、これにより、同等なショッピングリコメンデーションとの整合性が低いために再計算されるべき事前計算済み旅行リコメンデーションを検出する。この監視では、ＧＤＳが提供する内部サービス５を利用することができる。

不整合のリコメンデーションが検出されたら、検索プラットフォーム３は、一連のバッチ再計算命令（「大規模クエリ」とも呼ばれる）を生成して、それらを計算プラットフォーム２に送る。後者は、更新されたリコメンデーションを生成し、これによって、（再計算の結果と照合した場合の）事前計算済み旅行リコメンデーションの良好な整合性が維持される。

図１３は、フィードエンジン３０２（図１１を参照）の構造および機能を表している。フィードエンジン３０２は、計算プラットフォーム２から返される再計算済み航空旅行リコメンデーション群である例えばある特定の期間内のパリからロンドンへのすべてのフライトについてのすべての価格（「ＰＡＲ−ＬＯＮ市場」とも呼ばれる）を、受け取る。それらの再計算済みデータベースクエリ結果の統合は、以下のいくつかのステップからなる。

− 再計算済み旅行リコメンデーションをディスパッチする。
検索プラットフォーム３では、極めて高速の検索応答時間を実現するため、関連するデータは、同じ物理マシンに保存されるように図られる。例えば、出発都市が同じである２つの市場（ＰＡＲ−ＬＯＮと、ＰＡＲ−ＮＹＣ）は、同じ物理マシン上に置かれる。フィードエンジン３０２は、リコメンデーション群から情報（旅行プロバイダＩＤ、オフィスＩＤ、市場、地理的位置、など）を抽出し、これにより、そのデータのホストなる物理マシン（複数の場合もある）を決定する。このデータバランシング機構は、ラウンドロビンまたはコンシステントハッシュなど、周知の分散技術を利用する。周知のデータ複製方式で見られるように、信頼性、フォールトトレラント性、またはアクセス可能性を向上させるため、多数のマシンが、同じリコメンデーション群のホストとなることができる。

− 再計算済み旅行リコメンデーションを編成する。
フィードエンジン３０２は、計算プラットフォーム２から、再計算済み旅行リコメンデーション群を受け取る。その入来データは、次に、検索プラットフォーム３により良く適合する方法で、データセットと呼ばれるグループに分けられる。本例の検索プラットフォーム３により提供される各検索プロダクトは、その性能を最適化するための特有のデータ編成戦略を有する。例として、特定のニーズのために、計算プラットフォーム２からのフライト群を、同じ都市ペアのグループに編成した後に、１）同じ都市ペアかつ直行便のみ、２）同じ都市ペアかつ乗継便、という２つのタイプのデータセットに割り振ることができる。

− アクセラレータを構築する。
その編成の最上位に、検索プラットフォーム３は、事前計算済み旅行リコメンデーションに関するメタ情報のみを含む追加のデータセットを生成する。これらのデータは、極めて高速の検索を実現するのに役立つ。例えば、メタ情報のデータセットは、ある出発都市から到達可能な都市と、それぞれの到達可能都市との都市ペアの最安価格と、を提供することができる。その後、クライアントからの入来検索要求に対して、ソリューションを返すに当たって、あまりにも多数の旅行リコメンデーションを調べることを回避するために、この情報を利用できる。

− インデックスを構築する。
データベースと同様に、検索プラットフォーム３は、データセットの最上位に、アクセス時間を高速とするためのインデックスを構築する。事前計算済み航空旅行リコメンデーションの場合、その検索基準は極めてオープンであり、例えば、指定した期日範囲で、指定した価格範囲で、任意の到着都市についてなどの、価格の検索が可能である。検索プラットフォーム３は、検索基準ごとに１つのインデックスを作成するのではなく、（ＫＤＢ‐ｔｒｅｅなどの）多次元データ構造を用いることで、検索基準にかかわらず同様にデータへの効率的なアクセスを維持しつつ、データセットごとに１つのインデックスを構築する。このアプローチによって、使用されるストレージ量が制限される。２つの旅行プロバイダが、共通の旅行リコメンデーションを共有しており、その運賃が（特定のオフィスＩＤにのみ適用される、旅行プロバイダの協議運賃ではなく）公開されている場合、それらをシステムストレージにおいて共有することができ、これにより、空間が増えて、ハードウェアコストが削減される。

− 整合性マネージャ
新たな事前計算済み旅行リコメンデーションが計算プラットフォームから得られる場合には、対応するデータセットは、新規または略新規の事前計算済み旅行リコメンデーションで更新され、それらのインデックスは再構築される。これと同時に、影響を受けたデータセットで、旅行リコメンデーションを検索することができる。実行中の検索に（性能と整合性の両面で）影響を与えることがないように、フィードエンジン３０２は、データセットのリビジョンを管理する。検索が、データセットのリビジョンｎにおいて実行されている間に、フィードエンジンは、リビジョンｎ＋１を構築する。改訂されたデータセットが構築されて、インデックス付けされると、それは、検索用の新たな参照データセットとなる。以前のデータセットは、程なく、データセットのホストである分散システムにおけるすべての物理マシンのストレージメモリから削除される。これによって、実行中の検索では、その終了までデータが利用できるように維持されることが保証され、このようにして整合性の問題が回避される。

図１４は、検索エンジン３０３（図１１を参照）を表している。検索エンジン３０３は、接続されたクライアントから航空旅行検索要求を受け取って、最良の事前計算済みリコメンデーションを返すために、すべてのデータをクロールする。このプロセスは、以下のいくつかのステップからなる。

− サーバ・アフィニティ
入来検索要求は、検索プラットフォーム３で提供される特定の検索プロダクトによって処理されなければならない。この点で、それは、（検索プラットフォーム３の分散性を仮定して）その要求に応答するために必要なデータを含む物理マシンに送られる。上述のように、事前計算済み航空旅行リコメンデーションは、予め、それらのリコメンデーションを対象とする検索プロダクトの特異性に基づいて、フィードエンジン３０２によって物理マシンにディスパッチされたものである。このため、検索エンジン３０３は、招待オペレーションを実行する。すなわち、応答すべき検索クエリを解析し、そのタイプに基づいて、検索すべきデータならびにそれらが配置されている物理マシン（複数の場合もある）を決定する。

− 検索ドメインを決定する。
検索要求が適切な物理マシンに転送されると、検索エンジンは、検索クエリに関連するメタ情報が得られるデータセットを特定する。メタ情報は、検索クエリに対するソリューションを含む可能性がある航空旅行リコメンデーションのすべてのデータセットを探し出すために用いられる。

− 検索の実行
すべての可能性のある事前計算済み航空旅行リコメンデーションを探し出したら、検索エンジン３０３は、すべての多次元インデックスを解析することで、例えば、価格範囲、期日範囲、航空会社など、検索クエリで示された基準に基づく最良の事前計算済み旅行リコメンデーションを収集する。検索エンジン３０３は、先のメタ情報を利用することで、可能性のある事前計算済み旅行ソリューションのすべてまでは検索しないことを決定することができる。例として、検索クエリで、特定の都市ＮＣＥから出発する最良の価格が要求されたとする。検索で、到着都市ＰＡＲへの旅行が１００ユーロで見つかったとする。到着都市ＮＹＣの最安価格が５００ユーロであることをメタ情報が示している場合は、検索エンジン３は、ＮＣＥ発ＮＹＣ着のソリューションをさらに検索することはしない。これによって、検索トランザクションの応答時間はさらに短縮される。

− 関連検索
検索実行ステップによって事前計算済み旅行リコメンデーションが全く返されなかった場合は、ユーザのクエリによる制限が多すぎる可能性があり、このため、先に考慮したそれぞれの都市ペアについて、マッチするものがない理由を分析する。一例として、理由は、指定された期日範囲にあるフライトが全くないこと、またはフライトはあるものの、クエリで示された制限よりも高価格であること、が考えられる。ユーザのクエリによる制限が多すぎる場合、検索エンジン３０３は、元のクエリで示された制限と密接に関連するリコメンデーションを返すためのフォールバック戦略を実施する。それは、複数のパラメータに関する制限を緩和して（より広い期日範囲、より高い価格制限、など）、検索実行ステップにループバックするものである。ループは、いくつかのリコメンデーションが見つかったときか、設定されたリトライ回数に達したときか、またはリトライの最大許容時間に達したときときか、いずれかに終了する。フォールバック戦略によって返されるリコメンデーションがない場合には、別のフォールバック戦略があれば、それが実施される。要求された目的地が地理的意味を持つ場合（例えば、都市、国）には、検索エンジン３０３は、ＧＤＳ（本発明の一部ではない）により提供される地理的サービスを利用することで、近い地理的領域を特定し、これにより、上述のようにして、元のクエリの目的地の制限を広げて、検索実行ステップにループバックする。両方のフォールバック戦略で、リコメンデーションを取得できない場合には、空の結果が返される。

− 旅行ソリューションの集約
検索クエリに対するすべての事前計算済みソリューションが見つかったら、検索エンジン３０３は、異なるデータセットから返された可能性がある同一の結果をマージするパスを実行する。このようなケースは、例えば、検索によって、ある都市ペアの最安の直行便を含むデータセットと、すべてのフライト（直行便および経由便）を含む別のデータセットとを調べる必要がある場合に生じ得る。

最後に、見つかった事前計算済み旅行ソリューションは、検索クエリの要求に基づいて編成され、すなわち、ソリューションは、到着都市で、期日で、価格の昇順で、航空会社（直行便または乗継便のいずれか）で、グループ分けされる。結果は、その後、クライアントに返される。

図１５は、学習エンジン３０４（図１１を参照）を示している。学習エンジン３０４は、学習／統計データベースを備える。学習エンジン３０４の目的は、その価格が頻繁に変更されない事前計算済み航空旅行を検出することであり、従って、それらは、正確に維持する（すなわち、検索プラットフォーム３に保存されている事前計算済みデータベースクエリ結果が、計算プラットフォーム２で仮に再計算した場合の結果と一致する）ために、計算プラットフォーム２による頻繁な再計算を必要としないものである。

学習エンジン３０４は、航空旅行フライトの一般的性質についての、その論理分析に基づくものである。今から数日中に予定されているフライトの価格は変更度が極めて高く、すなわち、同じフライト（同じ出発日）の価格を１日後に再び問い合わせた場合に、その価格は変更されている可能性が高い。一方、数ヶ月後に予定されているフライトの価格は、１日後または１週間後に再び価格を問い合わせた場合に、変更されている可能性は低い。学習エンジン３０４は、上記で詳述した性質に基づいて、それぞれの市場に変更度モデルを関連付ける。それは、毎日、受け取る事前計算済み旅行リコメンデーションに基づいて、変更度モデル７（図２１を参照）を保守（および必要に応じてそれを修正）する。同様の配慮を、別の例の検索プラットフォーム３により保持される他の種類のデータに適用することができ、その場合、データ変更度の具体的なモデルは、データの性質および内容に依存する。

− 旅行リコメンデーションの価格を記録する。
入来する再計算済み旅行リコメンデーションが受け取られると、それらは複製されて、１つのコピーは、学習エンジン３０４に移される。事前計算済み旅行リコメンデーションは、市場でグループ分けされ、すなわち、今後の年間の期日について、ある都市ペアの旅行のリコメンデーションにグループ分けされる。システムは、わずかな期日範囲にわたる変更度の高いフライトのみ再計算するように計算プラットフォーム２に指示し得るため、年間のすべての期日のリコメンデーションが生成されるわけではないことに留意すべきである。学習エンジン３０４は、入来する旅行リコメンデーションから価格を抽出して、それらを、それらの計算日付と共に、専用の学習／統計データベースに記録する。これらの価格は、その後の航空旅行データ統合のための価格比較の基礎となる。

− 市場データをロードして、変更度モデルを修正する。
入来市場について、学習エンジン３０４は、その専用データベースに以前に保存されたすべての事前計算済み価格付き旅行リコメンデーションをロードする。それは、保存されている価格を、利用できる入来価格と比較する。学習エンジン３０４は、価格比較の結果に応じて、その市場の変更度モデルを適応させる。２つの同一のフライトの価格が異なる場合、その差が、統計データとして学習／統計データベースに保存される。差があまりにも頻繁に生じる場合は、変更度モデルが更新され、すなわち、その期日期間範囲は、より変更度が高いとマークされる。変更頻度に関する統計データを保存すると、休暇シーズンのように定期的に発生するイベントによる価格変更の影響を軽減するのに役立つ。２つの同一のフライトが、モデルに基づいて予想されるのよりも長い期間、同じ価格である場合には、モデルも更新され、すなわち、その期日期間範囲は、より変更度が低いとマークされる。

− 変更度レポートを作成する。
入来するすべての事前計算済み旅行リコメンデーションの分析を終了したら、学習エンジン３０４は、本明細書に記載の分散型検索プラットフォームに、たった今、統合されたデータの、修正された変更度を含むレポートを作成する。変更度レポートは、顧客ＩＤ（データのプロバイダ）ごとに作成されて、市場ごと、出発日ごとに編成される。

作成されたレポートは、レポートコーディネータ３０５と呼ばれる別のエンジンに送られる。後者は、その後、計算プラットフォーム２で利用できる計算リソースに応じて、再計算されなければならない事前計算済み航空旅行リコメンデーションのサブセットを決定するために、この情報ソースを利用する。

図１６は、人気度エンジン６（図１を参照）を示している。人気度エンジン６は、人気度データベースを備える。クライアントからの入来検索要求について、人気度エンジン６は、ユーザトランザクションから検索傾向を抽出する機会を得る。これは、検索プラットフォーム３に保存されている旅行価格の人気度についての洞察を与えるものである。この分析は、以下のステップで実行される。

− 入力と出力の解析
入力検索クエリは、検索エンジン３０３に到達する前に複製されて、１つのコピーが人気度エンジン６に送られる。これと対称に、検索トランザクションの出力は、ユーザに送り返される前に複製されて、１つのコピーが人気度エンジン６に送られる。人気度エンジン６は、何らかの人気度メトリクスならびに統計を得るために、トランザクションの入力と出力の両方を解析する。この解析によって、入力検索クエリの基準に応じた様々な情報を生成する。例えば、検索クエリによって、特定の市場（都市ペア）についての旅行リコメンデーションが要求された場合、エンジンは、市場ごとの人気の出発日についてのランキングを、クエリから抽出することができる。検索クエリによって、ある１つの出発都市からの旅行リコメンデーションが要求された場合、エンジンは、出発都市ごと、および価格ごと、期日範囲ごとなどの好まれる到着都市（または到着国）についてのランキングを、ソリューションから抽出することができる。

− 統計データをデータベースに保存する。
入力クエリおよび出力ソリューションから抽出された傾向は、専用の人気度データベースに保存される。このストレージは、（人気度エンジン６が動作する）任意の物理マシンが、システムの他の物理マシンで生成されたデータを利用できるように、分散させることができる。

− 記録を集約して、人気度レポートを作成する。
並行して、人気度エンジン６の繰り返しジョブにより、既に計算済みの統計データを分散データベースから抽出し、何らかの体系的人気度メトリクスを構築する。例えば、人気度のために解析された検索クエリの総数に基づいて、人気の市場について、すなわち入力クエリで最も多く対象とされた市場、出力旅行ソリューションで返送されたより安価な市場などについての、ランキングを抽出する。別の可能性としては、年間の特定の期日範囲で最も人気のある市場についての統計を生成すること、休暇シーズンのような特別なイベントについての傾向を抽出すること、または、世界の様々な地理ゾーンで最も人気のある市場について統計を生成すること、がある。このような絞り込みは、（例えば、国内便について、など）より適切な人気測度を抽出する助けとなる。作成されたレポートは、その後、人気度メトリクスへのアクセスを提供するために、レポートコーディネータ３０５に送られる。

図１７は、正確度エンジン８（図１１を参照）を示している。正確度エンジン８は、価格正確度データベースを備える。正確度エンジン８の目的は、事前計算済み航空旅行リコメンデーションを制御して、その価格が、実際の（すなわち現在の）購買価格とあまりにも異なるものを検出することである。このエンジンの原理は、ショッピングトランザクションを送り出すための外部のショッピングサービス（本発明の一部ではない）を利用し、返された価格を、事前計算済み旅行リコメンデーションのメモリのそれと比較することである。

正確度エンジン８は、以下のいくつかのステップで動作する。

− 入力および出力トランザクションを絞り込んで利用する。
人気度エンジン６の場合と同様に、正確度エンジン８は、入力検索クエリと、要求元クライアントに対して検索プラットフォーム３から返された出力旅行ソリューションの、複製されたコピーを受け取る。あまりにも多くの実際のショッピングトランザクションが送り込まれると、ハードウェアコストおよび応答時間における負担が大きいので、これを回避するために、本明細書に記載の検索プラットフォーム３を通過する元のトラフィックのサブセットに作用する絞り込みパスを適用する。

− 運賃検索トランザクションを生成する。
正確度エンジン８は、システムに保存されている旅行リコメンデーションを代表するサブセットを解析するのに十分に多様な運賃検索トランザクションを生成する必要がある。そのための生成戦略は、以下の２つがある。
旅行の人気度に基づいて運賃検索トランザクションを生成する。すなわち、正確度エンジン８は、（先に提示した）人気度データベース６にアクセスすることで、出力ソリューションの人気度を分析し、最も人気のあるもののみ、さらなる解析のために保持する。これにより、実際のショッピング価格と比較した、保存された事前計算済み価格に関して、ユーザが経験する整合性を最大限に高める。
事前計算済み旅行リコメンデーションのメモリの内容に基づいて、ランダムなトランザクションを生成する。解析のために旅行をランダムに選択することは、事前計算済み旅行リコメンデーションのメモリ全体の最終的な正確さを提供することを目的としている。これは、ユーザにとっての良好な旅行ファインダビリティを保証するものであり、すなわち、ハードウェアコストを抑えるために頻度はより少ないものの、不人気のフライトの正確度も監視する。

− データを集約する。
収集された正確度メトリクスは、専用の分散型正確度データベースに保存される。繰り返しジョブにより、すべての正確度メトリクスを、いくつかのレポート（顧客ごと、市場ごと、出発日ごとなどの、ソリューションの正確度）に統合して、それらを、さらなる利用のためにレポートコーディネータ３０５に送る。

図１８は、レポートコーディネータ３０５（図１１を参照）を示している。レポートコーディネータ３０５は、本例による検索プラットフォーム３の最後の解析エンジンである。その役割は、先のエンジンにより報告されたすべてのメトリクスに基づいて、さらには計算プラットフォーム２で利用できる計算リソースに応じて、検索プラットフォーム３内のデータのどの部分が再計算されるべきであるかを決定し、計算プラットフォーム２に向けた再計算命令を生成および発行することである。

再計算の決定は、以下のいくつかのステップで実行される。

レポートを保存する。
入来する変更度、人気度、正確度レポートからのすべてのメトリクスは、専用のレポートデータベースにローカルに保存される。このように保存されるのは、レポートコーディネータ３０５による決定が、先のメトリクスに基づいて行われるからである。例えば、レポートコーディネータ３０５は、変更度レポートに基づいて、事前計算済み旅行リコメンデーションのメモリに保存されたデータの古さを推測する。この情報は、その後、レポートデータベースに保持される。

再計算の決定
レポートコーディネータ３０５により行われる決定は、メモリのデータ正確度と、計算プラットフォーム２の計算リソースとのバランスをとるためのヒューリスティクスに基づいている。その基本的アプローチは、計算プラットフォーム２で利用できるリソースを前提として、最も正確度の低い事前計算済み旅行リコメンデーション（すなわち、検索プラットフォーム３に保持されている事前計算済み旅行リコメンデーションで、計算プラットフォーム２により仮に再計算された場合の結果と未だ一致している可能性が最も低いもの）を再計算することである。正確度が最も低いデータの中で、最も人気度が高いものについて、再計算命令の生成が最初に考慮される。再計算の候補は、フライトドメインにおいて近い（各市場で期日範囲が近い）旅行でグループを形成するように、レポートコーディネータ３０５により選択される。これにより、計算プラットフォーム２は、一部の再計算を相補化して、そのリソース消費をさらに最適化することが可能となる。

各再計算命令の合間で、レポートコーディネータ３０５は、（レポートデータベースに保存された）変更度モデル７と、事前計算済み旅行リコメンデーションの推定された古さと、を利用することで、検索プラットフォーム３内の残りすべてのデータの予想正確度を更新する。

検索プラットフォーム３の一例を実施する上述の方法を、さらに図１９に示すダイアグラムにも示している。この方法は、複数のパラメータに応じた旅行のアベイラビリティおよび運賃に関する情報を含む複数の旅行データベースにアクセスできる分散型予約システムで動作するプレショッピング（すなわち、非契約的な旅行クエリに応えて価格付き旅行リコメンデーションを生成するための）ツールの一例であり、それぞれの旅行クエリはプリファレンスのセットを含み、各プリファレンスは、上記複数のパラメータから選択されたパラメータに関するものである。分散型予約システムは、旅行リコメンデーションからのセレクションが保持される複数の高速アクセスメモリ位置を有し、これにより、ユーザは、自身のクエリに対して高速応答を得ることができる。以下では、これらの高速アクセスメモリを、「事前計算済み旅行リコメンデーションで構成されるキャッシュ」という用語で呼ぶが、ただし、この高速アクセスメモリは、キャッシュとは異なり、保存されている内容は、事前計算済み価格付き旅行データセットの旅行カタログ全体を表しており、カタログの中の最もアクセスの多い旅行からなるサブセットのみではないので、この用語が技術的に適切とは言い切れないことは、当業者であれば理解できるであろう。換言すれば、このキャッシュという用語は、「ショッピングトランザクション・キャッシュ」に関連している。同様に、これらの高速アクセスメモリに保存された情報は、「事前計算済み情報」（例えば、「事前計算済み旅行リコメンデーション」）と呼ばれる。事前計算済み旅行リコメンデーションのメモリに伴う問題は、それらの価格と、購入の際に示される実際の価格との整合性を保つために、リコメンデーションに含まれるデータが更新される必要があるということである。これは、（時間とシステム性能の面で）極めてコストがかかるアクティビティであり、情報の整合性とシステム性能との間でバランスを見つけなければならない。本検索プラットフォーム３の（さらには、特に、詳細は後述する、より一層高度なアプローチを含む本発明の再計算トリガ・プラットフォーム４の）特徴の１つは、異なる旅行リコメンデーションは同時に同じ頻度では更新されないということである。代わりに、各旅行リコメンデーションに「頻度」スコアが割り当てられて、これに従って更新がスケジュールされ、より変更度が高い可能性のある情報は、より頻繁にリフレッシュされる。この方法は、黒丸３０で開始し、次にボックス３１に進み、そこで検索プラットフォーム３によって、複数の高速アクセスメモリ位置に、事前計算済み旅行リコメンデーションで構成されるメモリを維持し、このとき、各旅行リコメンデーションは、特定の旅行のアベイラビリティおよび価格に関する情報を含み、上記複数のパラメータのうちの少なくとも１つによってソートされる。メモリ内の事前計算済み旅行リコメンデーションのソートおよびインデックス付けは、上述のようないくつかの方法で行うことができ、これは、できる限り短時間で適切な情報を見つけるために重要である。次に、必要なリフレッシュ頻度を示すスコアが、事前計算済み旅行リコメンデーションのそれぞれに割り当てられる（ボックス３２）。このスコアは、情報のリフレッシュをいつ実施するべきかを決定するために用いられる。本検索プラットフォーム３の一例によるリフレッシュ（ボックス３３）は、上述のようにバッチ処理で行われる。本検索プラットフォーム３の一例では、バッチ再計算命令は、例えば上記で詳述したような計算プラットフォーム２の例である専用のサブシステムによって実行される。そのようなバッチ再計算命令の実行は、定時に行う（ボックス３４）か、またはユーザによって起動するか、または特定のイベントによってトリガすることができる。例えば、大規模クエリは、所定の期間ごとに（例えば、１日の終わりに、または１時間ごとに）実行することができ、限界量のクエリを受け取った時もしくは最大許容量に達した時に自動的に実行することができ、または同じくシステムの管理者もしくは旅行プロバイダがそれを要求することができる。ユーザクエリを受け取ると（ボックス３５）、システムは、最初に高速アクセスメモリ位置の範囲内で検索を試みる（ボックス３６）。ソリューションが見つからない場合は（ボックス３７）、オプションのフォールバック・アクションを実行することができる（ステップ３８）。フォールバック・アクションが提供されていない場合には、ユーザへのメッセージによって、検索プラットフォーム３で得られる結果がないことを通知する。あるいは、ユーザのクエリによる制限が多すぎる可能性があることを考慮して、調整したパラメータで、新たな検索を実行することができ、その場合、先に考慮したそれぞれの都市ペアについて、マッチするものがない理由を分析する。一例として、理由は、指定された期日範囲にあるフライトが全くないこと、またはフライトはあるものの、クエリで示された制限よりも高価格であること、が考えられる。

ユーザのクエリによる制限が多すぎる場合、検索エンジン３０３は、元のクエリで示された制限と密接に関連するリコメンデーションを返すためのフォールバック戦略を実施する。それは、複数のパラメータに関する制限を緩和して（より広い期日範囲、より高い価格制限、など）、検索実行ステップにループバックするものである。ループは、いくつかのリコメンデーションが見つかったときか、設定されたリトライ回数に達したときか、またはリトライの最大許容時間に達したときときか、いずれかに終了する。フォールバック戦略によって返されるリコメンデーションがない場合には、別のフォールバック戦略があれば、それが実施される。要求された目的地が地理的意味を持つ場合（例えば、都市、国）には、検索エンジン３０３は、ＧＤＳにより提供される地理的サービスを利用することで、近い地理的領域を特定し、これにより、上述のようにして、元のクエリの目的地の制限を広げて、検索実行ステップにループバックする。両方のフォールバック戦略で、リコメンデーションを取得できない場合には、空の結果が返される。さらに別の可能なソリューションは、要求された旅行リコメンデーションを見つけるため、および検索プラットフォーム３に保持された事前計算済み旅行リコメンデーションのキャッシュを充実させるために、外部データベースへのクエリを実行することである。結果が得られた場合、事前計算済み旅行リコメンデーションのメモリを、新たな情報によって充実させる。いずれの場合も、ユーザに対して応答が発行される（ステップ３９）。旅行リコメンデーションのスコアも同様に更新が必要となる場合がある。本例では、クエリは、必ずしも予約を完了することを目的としないクライアントによって、例えば旅行のアベイラビリティ、価格、時間に関する情報、または一般情報などのプレショッピング情報を求めて、送られる。本データベースシステム１の一例では、クエリを受け取って、ユーザクエリを満たすためのデータベース照会を実行する検索プラットフォーム３は、実際の予約システムとは別個であるが、２つの検索プラットフォーム３（１つはプレショッピング用、もう１つは予約用）は、既に上記で簡単に概説したように、１つに統合することができることは、当業者であれば理解できるであろう。

要するに、本明細書で提示する検索プラットフォーム３は、以下の点を特徴とすることができる。

１．分散型予約システムにおいて、非契約的な旅行クエリに応じて価格付き旅行ソリューションを生成する方法であって、分散型予約システムは、複数のパラメータに応じた旅行のアベイラビリティおよび運賃に関する情報を含む複数の旅行データベースにアクセスでき、それぞれの旅行クエリはプリファレンスのセットを含み、各プリファレンスは、上記複数のパラメータから選択されたパラメータに関するものであり、本方法は、
− 事前計算済み旅行リコメンデーションからのセレクションを含む複数の高速アクセスメモリ位置を維持することであって、各旅行リコメンデーションは、特定の旅行の運賃および／またはアベイラビリティに関する情報を含み、上記複数のパラメータの少なくとも１つによってソートされており、
− 必要なリフレッシュ頻度を示すスコアを、事前計算済み旅行リコメンデーションのそれぞれに割り当てることと、
− 旅行リコメンデーションのうちの少なくとも一部に含まれた情報をリフレッシュするために、複数のデータベースにおいて大規模クエリを実行することにより、事前計算済み旅行リコメンデーションからのセレクションを更新することであって、このとき、各旅行リコメンデーションのリフレッシュの頻度は、割り当てられたスコアに依存し、
− システムで受け取った旅行クエリに応えて、その旅行クエリに含まれたプリファレンスを満たす旅行リコメンデーションを見つけるために、複数の高速アクセスメモリ位置を検索することと、
− 旅行クエリへの応答をユーザに対して発行することと、旅行リコメンデーションのセレクションのスコアを更新することと、を含む。

２．特徴点１の方法において、必要なリフレッシュ頻度を示すスコアは、旅行リコメンデーションのアベイラビリティおよび／または運賃に関する情報の変更度を示す値を含む。

３．先行するいずれかの特徴点の方法において、必要なリフレッシュ頻度を示すスコアは、旅行リコメンデーションの人気度を示す値を含む。

４．先行するいずれかの特徴点の方法において、複数の旅行データベースへのアクセス、および事前計算済み旅行リコメンデーションのセレクションを充実させるステップは、専用のサブシステムによって実行される。

５．先行するいずれかの特徴点の方法は、さらに、
− 事前計算済み旅行リコメンデーションのセレクションを複数の同種グループに分割することであって、同種グループ内の各旅行リコメンデーションは、少なくとも所定の個数のパラメータが同じ値である、複数の同種グループに分割することと、各グループを高速アクセスメモリ位置の１つに保存することと、を含む。

６．先行するいずれかの特徴点の方法において、大規模クエリを実行するステップは、所定の時間間隔で行われる。

７．先行するいずれかの特徴点の方法において、大規模クエリは、バッチ処理で行われる。

８．先行するいずれかの特徴点の方法において、複数の高速アクセスメモリ位置に保存された旅行リコメンデーションは、多次元データ構造に従ってインデックス付けされる。

９．先行するいずれかの特徴点の方法は、さらに、
− 複数の高速アクセスメモリ位置を検索することにより結果が得られないことに応えて、情報提供として、近い結果を返すことを目的として、複数のパラメータに関する制限を緩和して、密接に関連する一連のクエリを実行することを含む。

１０．特徴点１〜８のいずれかの方法は、さらに、
− 複数の高速アクセスメモリ位置を検索することにより結果が得られないことに応えて、ユーザに警告メッセージを発することを含む。

１１．コンピュータプログラムであって、該コンピュータプログラムがコンピュータ上で実行されることで、先行するいずれかの特徴点による方法のステップを実行するための命令を含むコンピュータプログラム。

１２．請求項１０のコンピュータプログラムを具現化するコンピュータ可読手段を含むコンピュータプログラムプロダクト。

１３．特徴点１〜１０のいずれかの方法を含むプレショッピングシステム用のソフトウェアツール。

１４．プレショッピング旅行クエリを管理するための分散データ処理システムであって、分散データ処理システムは、複数のパラメータに応じた旅行のアベイラビリティおよび運賃に関する情報を含む複数の旅行データベースにアクセスでき、それぞれの旅行クエリはプリファレンスのセットを含み、各プリファレンスは、上記複数のパラメータから選択されたパラメータに関するものであり、本システムは、特徴点１〜１０のいずれかの方法を実行するように構成された１つまたは複数のコンポーネントを含む。

１５．特徴点１〜１０のいずれかの方法を実施するためのデータ処理システムにおいて展開されるサービス。

再計算トリガ・プラットフォーム
図２０は、分散データベースシステム１の別の例の概観を示している。以下で説明する例は、同じく旅行産業におけるデータベースに関するものである。具体的には、計算プラットフォーム２が、航空旅行オファーに関するデータを保持し、再計算トリガ・プラットフォーム４が、それらの航空旅行オファーに関連した価格を保存する一例を提示しており、それらの価格は、計算プラットフォーム２が、計算ルールに基づいて、特に航空運賃およびそれらに関連する計算ルールに基づいて、算出するものであり、従って、上記で詳述した計算プラットフォーム２および検索プラットフォーム３の例に適合する例である。ただし、留意すべきことは、これは、再計算の本戦略をより詳細に説明するための例にすぎないということである。本明細書で提示する再計算戦略は、データおよびキャッシュされた結果の構造および／または意味に関わりなく、任意の種類のデータおよびデータベースクエリ結果に適用することができる。

上述のように、データベースシステム１の主なエンティティのうちの２つは、再計算トリガ・プラットフォーム４と計算プラットフォーム２である。図２０の例では、計算プラットフォーム２は、サブチャプタ「計算プラットフォーム」において上述したような計算プラットフォーム２の例に相当する。再計算トリガ・プラットフォーム４と計算プラットフォーム２は、少なくとも１つの通信リンクを介して接続されており、これを利用して、再計算トリガ・プラットフォーム４から計算プラットフォーム２に再計算命令を伝送し、また、これに応答して、計算プラットフォーム２から、再計算トリガ・プラットフォーム４および検索プラットフォーム（複数の場合もある）３に、事前計算済み価格付き旅行リコメンデーション（本明細書では簡単に「価格」とも呼ばれる）を返送する。

再計算トリガ・プラットフォーム４は、ミラーリングされた事前計算済みデータベースクエリ結果の正確確率を決定するために用いるデータを取り込むための、追加の通信インタフェースを備える。これらのインタフェースには、例えば、確率モデルの基礎となる統計データを取り込むための通信リンク、さらには、航空会社からポピュレートされる運賃変更およびフライトアベイラビリティのアナウンス、または顧客販売促進キャンペーンなど、非同期リアルタイムイベントを受け取るための通信リンクが含まれる。

また、データベースシステム１は、エンドユーザまたは旅行代理店などの外部の顧客が照会することができるデータを編成および維持する少なくとも１つの検索プラットフォーム３を備える。検索プラットフォーム３は、計算プラットフォーム２と検索プラットフォーム３との間の通信リンクをそれぞれ介して、計算プラットフォーム２によるポピュレートおよび更新を受ける。このようなポピュレートおよび更新は、検索プラットフォーム３自身により制御され得る一方、オプションとして、上記で詳述したような更新頻度スコアに基づく更新機構を備える。従って、検索プラットフォーム３自身で、計算プラットフォーム２に対してバッチ再計算命令を発行することが可能である。また、ポピュレートおよび更新は、再計算トリガ・プラットフォーム４により計算プラットフォーム２に対して発行される再計算命令よってトリガされることがある。

上記で概説され、以下でより具体的に説明されるように、再計算トリガ・プラットフォーム４から受け取った再計算命令に応えて、計算プラットフォーム２は、旅行リコメンデーションの価格を再計算して、それらを再計算トリガ・プラットフォーム４に返す。一方、同時に、計算プラットフォーム２は、再計算済み価格付き旅行リコメンデーションを、（図２０に「旅行リコメンデーション統合」で示すように）検索プラットフォーム３にも伝送し、これによっても、それらが保存される。こうして、再計算トリガ・プラットフォーム４により実行される再計算／更新戦略に基づいて、アプリケーション・プラットフォーム３においても、ユーザにより照会される事前計算済み価格付き旅行リコメンデーションが保存される。このように、再計算／更新の本戦略は、（サブチャプタ「検索プラットフォーム」において上記で詳述したように、検索プラットフォーム３自身によって既に実行され得る更新／再計算方法に追加して）適用され、これによって、例えば、オープンクエリに対する即時応答の形で、ユーザにメリットを提供する。このような構成では、再計算トリガ・プラットフォーム４は、検索プラットフォーム３のメモリの更新を制御およびトリガするように構成された制御プラットフォームとして機能する。従って、この場合、再計算トリガ・プラットフォーム４に保存されているミラーリングされた事前計算済みデータベースクエリ結果は、実際に、ユーザもしくは顧客によるアクセスまたは照会を受けるものではなく、単に、これに基づいて再計算戦略が実行される制御データをなすものである。

一方、他の構成では、再計算トリガ・プラットフォーム４は、ユーザもしくは顧客による照会を直接受けることもあり、すなわち換言すれば、再計算／更新の本戦略は、別個の制御エンティティではなく、１つ以上の検索プラットフォーム３において直接実行されることができる。従って、このような構成では、再計算トリガ・プラットフォーム４は、１つまたは（複数ある場合は）複数の検索プラットフォーム３に統合される。この場合、再計算トリガ・プラットフォーム４は、（再計算の決定を行うためにデータのコピーを独自に維持するのではなく）検索プラットフォーム３の高速アクセスメモリに保存されている事前計算済みデータベースクエリ結果／価格付き旅行リコメンデーションにおいて直接演算を実行することができる。再計算トリガ・プラットフォーム４の再計算／更新戦略の実行に用いられる追加の管理データ、制御データ、もしくはメタデータを、再計算トリガ・プラットフォーム４に専用の別個のメモリか、または事前計算済み価格付き旅行を保存するために用いられる検索プラットフォーム３の高速アクセスメモリか、または統合された検索／再計算トリガ・プラットフォーム３、４の他の適切なメモリか、いずれかに保持することができる。

検索プラットフォーム３は、例えば、プレショッピングアプリケーション・プラットフォームと、運賃分析アプリケーション・プラットフォームと、その他のプラットフォームと、を備える。プレショッピングアプリケーション・プラットフォームは、フライトのアベイラビリティおよび価格に関する情報を探し出すことを希望するエンドユーザによって照会される。例えば、エンドユーザは、５００ユーロ未満でニース（Ｎｉｃｅ）から出発する休暇シーズン中の旅行オファーの価格の概観を得るために、プレショッピングアプリケーションにクエリを送ることができる。再計算／更新の本戦略に沿って更新されるプレショッピング検索プラットフォーム３に保存された事前計算済み価格付き旅行リコメンデーションがあることによって、クエリの発生時には、個々のフライトの価格を計算する必要はない。代わりに、プレショッピングアプリケーション・プラットフォームにキャッシュされた価格付き旅行リコメンデーションに基づいて、このようなかなり限定の少ない条件を満たす旅行オファーのリストを、極めて高速で返すことができる。その後、ユーザは、返されたリストから、自身にとって最適な旅行を選択することができ、そして次に、その旅行を実際に予約するためのさらなる要求を発行することができる。第２の要求は、その後、予約エンジン（図示せず）によって処理され、これにより、現在の実際の価格を計算して、ユーザに対して契約的オファーを提示する。

次に、図２１に示す再計算トリガ・プラットフォーム４の構造を詳しく見てみると、再計算トリガ・プラットフォーム４は、３つのモジュールで構成されている。
− 入力マネージャ４０は、計算プラットフォーム２からの事前計算済みデータベースクエリ結果、非同期リアルタイムイベント、および確率モデルに入力して更新するための統計データなどの他の情報といった入力を受け取ることを担当する。
− アナライザ４１は、確率モデルを利用し、これに基づいて、キャッシュされたクエリ結果の更新されるべき候補を決定するように構成されている。
− 最後に、コンソリデータ４２は、アナライザ４１で決定された確率を修正し、さらに、必要であれば、観測されたリアルタイムイベントに基づいて、確率モデルも修正する（後者の場合は図２１に示していない）。

加えて、再計算トリガ・プラットフォーム４は、キャッシュされた価格付き旅行リコメンデーションデータを保持する内部データベース４３を備える。その表現では、失効した確率を判定して再計算の決定を下すことに関連する価格情報の属性のみを保持しており、それは例えば、都市ペア、出発日、滞在期間、最終計算日であり、それらはすべて、計算プラットフォーム２から返された計算出力である。運賃など、計算プラットフォーム２によってその計算を実行するために利用される他のデータは、再計算／更新戦略を実行するためには必要ないので、それらは再計算トリガ・プラットフォーム４にミラーリングされない。しかし一方で、再計算トリガ・プラットフォーム４は、初期推定正確度（計算プラットフォーム２で再計算されたばかりの価格が、予約の場合の計算とは異なる可能性）、変更度（その最後の計算以降に、価格が、予約の場合の計算と異なる確率の指標）、人気度（どのくらいの頻度で、そのフライトが検索され予約されているか）など、（計算プラットフォーム２から返されるデータセットの一部ではない）メタデータ属性によって、そのデータを充実させる。これらの属性を設定するために必要なデータは、変更度データベース１０、初期正確度データベース１１、および統計サーバ９など、外部のデータベースに保持される。メタデータ属性は、確率モデルを表しており、これに基づいて、アナライザ４１は、（より詳細は後述するように）キャッシュされた価格が失効しているかもしれない確率を決定する。変更度データベース１０は、検索プラットフォーム３に関連して上述したような学習エンジン３０４と接続されて、これと対話することができる（図１１および１５を参照）。統計サーバ９は、検索プラットフォーム３に関連して上述したような人気度エンジン６に対応するもの、またはさらにそれと同一のもの、またはそれによる提供を受けるもの、とすることができる（図１１および１６を参照）。初期正確度データベース１１は、検索プラットフォーム３に関連して上述したような正確度エンジン８に対応するもの、またはさらにそれと同一のもの、とすることができる（図１１および１７を参照）。

入力マネージャ４０は、すべての異種情報ソースを、計算プラットフォーム２から返された価格のローカル表現データベース４３に変換および統合するように構成される。それは、モデル化された価格に影響を及ぼす可能性があるイベントおよびアクションを記録する。そのようなイベントには、顧客販売促進および顧客の不一致フィードバックが含まれる。また、フライトキャンセルのようなフライトアベイラビリティ・イベントは、その欠航便に直接基づくキャッシュされた旅行リコメンデーションを無効にするだけではなく、その欠航便と同じ時間に予定されている同じ都市ペアのフライトなど、並列に保存されたデータにも影響を及ぼし得る。これらのリアルタイムイベントは、次にコンソリデータ４２に転送されて、これにより、それらをさらに処理することで、失効の確率および再計算の決定を修正する。

価格付き旅行リコメンデーションのキャッシングに関わる情報量によれば、符号化技術を採用することが有効である。これによって、再計算トリガ・プラットフォーム４にキャッシュされた価格付きデータは、ストレージリソースのコストを大幅に削減しつつ、計算プラットフォーム２に保持される基礎となるデータドメインにグローバルにマッピングされる。確率的符号化は、例えば、ブルームフィルタを用いて実現される。そのような符号化の効果は２つある。第１に、ブルームフィルタは、保守的である。それらは、いずれの場合も、例えば、運賃変更を示すリアルタイムイベントによる影響を受ける可能性がある価格のポジティブな追跡が少なくとも可能であり、一方、その逆のものについては誤りがなく、影響を受けないとみなされる価格は、実際に影響を受けない。従って、そのような運賃変更イベントの影響を受ける可能性がある価格を認識し損なう恐れがない。第２に、誤検出を示す量は、ブルームフィルタの割当てサイズに厳密に依存するため、必要に応じて、その発生を制限することができる。

第２のモジュールであるアナライザ４１は、キャッシュされた価格付き旅行リコメンデーションが失効している確率の決定を、再計算トリガ・プラットフォーム４に保持されている事前計算済み価格の正確度の確率的低下のモデルに基づいて、第１の一般的レベルで実行する。それは、上述のように、入力マネージャ４０によって価格に追加されたメタデータを調査および評価する。このメタデータにより表される確率モデルは、この場合、変更度データベース１０に含まれる価格変更度、初期正確度データベース１１から取り込まれる価格の初期正確度、および統計サーバ９から人気度レポートで返されるフライト・リコメンデーションの人気度、に関するメトリクス含む。それは、静的な確率的情報のみに基づいて（つまり、イベントは考慮することなく）、キャッシュされた価格に関する確率および優先度情報を、すなわち、どの価格が優先的に再計算される必要があるのかについての指標を、コンソリデータ４２に出力する。

再計算すべき価格の優先順位、および次に再計算すべき価格を決定するために、確率モデルの情報を利用するいくつかの方法がある。アナライザ４１は、状況に応じて（例えば、計算プラットフォーム２において基礎となる旅行データを所有する顧客との取り決めに従って、データ量に応じて、利用できる計算リソースに応じて、キャッシュが最適化されるべき目的に応じて）、そのような戦略または混合戦略を適用するように構成可能である。以下の戦略を適用することができる。
・ 価格の正確度：これは、データドメインの全体的な正確度を最大限に高めることを目的としている。不正確と推定される価格を、最初に再計算する。
・ 人気度で重み付けした価格の正確度：不正確である可能性が高い価格の中で、より人気度が高い価格を、より人気度が低い価格よりも高い優先度で、再計算する。
・ 人気度およびそれらの古さで重み付けした価格の正確度：先の戦略と類似しているが、ただし、最後の再計算がいつであったのかを、さらに考慮する。この戦略によって、特に、通常、再計算されるべきである価格の量と比較して再計算リソースが限られている状況において、極めて変更度の高い価格に起因して生じる再計算の不足が、回避される。
・ 人気度の高い都市ペアを、それらの地理的位置および再計算時間帯に基づいて調整する：この戦略では、どの都市ペアのフライトが1日のうちの特定の時間帯に、より頻繁に照会されるのかについての統計を、さらに考慮に入れる。効果として、（キャッシュされた不正確なデータは、それぞれのクエリが実際には略発生しないのであれば、害を及ぼすことはないので）特定の都市ペアのフライトにアクセスされることが稀である時間帯における頻繁な再計算が回避される。

副次的効果として、アナライザ４１は、計算プラットフォーム２から受け取られて再計算トリガ・プラットフォーム４に取り込まれる最近再計算された価格の値に基づいて、変更度モデル・データベース１０を更新する。アナライザは、再計算を繰り返すことによって、キャッシュされた価格の実際の変更度を追跡することができるので、そのような統計情報を変更度モデル・データベース１０にフィードバックすることができる。変更度モデルを更新するために、アナライザ４１は、新たに計算された価格結果と、前回受け取った価格値とが異なる回数をカウントする。これらの差によって、分析された価格のそれぞれの部分の変更度パラメータを更新する。

さらに、アナライザ４１は、同様にして初期正確度データベース１１を更新することができる。それは、例えば、新たな都市ペアの価格が再計算トリガ・プラットフォーム４に初めて統合された場合に、他の人気度レポートを求めることができる。価格の変更度、正確度、または人気度のそれぞれについて、履歴および統計データがない場合には、アナライザ４１は、その処理を、できる限り保守的であるように、デフォルトパラメータで実行する。

次に、第３のモジュールであるコンソリデータ４２は、入来リアルタイムイベントを考慮することにより、第２のレベルの確率決定を実行する。さらに、これは、再計算命令を生成して、それらを計算プラットフォーム２に発するエンティティである。これは、アナライザ４１の出力を、その決定のための基礎として取得する。それらは、データドメインのすべての価格について、再計算優先度の第１の推定値を提供するものである。そこで、様々なソースから収集されたリアルタイムイベントのすべての情報をオーバレイすることで、再計算優先度を修正する。これによって、改善された再計算優先度を得る。

オプションとして、再計算トリガ・プラットフォーム４は、例えば、「毎週少なくとも１回、すべての価格が再計算されることを保証する」など、顧客サービスレベルアグリーメントを考慮することができ、それに応じて優先度を修正することができる。それは、内部価格データ表現４３において最も優先度の高いエントリを最初に選択して、それらを再計算のためにマークする。コンソリデータは、好ましくは、計算プラットフォーム２で利用できる計算リソースについての知識を有するので、キャッシュされた価格を、特定の期間に、計算プラットフォーム２による再計算が可能な範囲で、できる限り多く割り当てることが可能である。そして、それは、結果的に得られた再計算命令を、計算プラットフォーム２に送る。

リアルタイムイベントからの情報は、キャッシュされたデータの正確度を、厳密な統計的モデリングによって向上させる手段である。それらは、予想されたことだけではなく、実際に起こっていることを追跡するために用いることができる。それは、統計モデルの予測を制御し、予測が誤りまたは不適切であることが判明した場合に、それら／それを修正するための手段である。本例に関して、以下のリアルタイムイベントのいくつかのクラスを想定することができる。

アクタのイベントは、一般に選択的に（すなわち時々）発生するが、再計算の決定に多大な影響を及ぼすことがある。外部の顧客は、自身のプラットフォームで経験しているキャッシュとショッピングとの不一致について、フィードバックを提供することができる。このフィードバックは、統計モデルによって予測された正確度を修正するために用いることができ、これにより、必要なときに、より迅速に再計算を実行させることができる。計算プラットフォーム２に保存されているデータのプロバイダ（例えば、旅行を提供する旅行プロバイダ）が、特定の都市ペアのフライトを宣伝する販売促進キャンペーンを実施するときには、これらの価格は、より変更度が高く、失効することがより多いと想定することができる。従って、販売促進キャンペーン中のこれらの価格の再計算頻度を増やすことが必要となり得る。他の例として、計算プラットフォーム２の保守作業が必要になることが時々あり、または運用上の問題がシステム１内で認められることがある。このような場合、それぞれ、保守が終了するまで、および問題が解消するまで、再計算トリガ・プラットフォーム４は、再計算命令の生成を少なくするか、または全く生成しないように操作され得る。

アベイラビリティ・イベントは、キャッシュされたフライトの正確度に関するリアルタイムステータスを示すものである。イベントのステートメントによって、計算プラットフォーム２における基礎となるデータドメインの特定の価格が変更されたこと、および、これによって、再計算トリガ・プラットフォーム４でキャッシュされたその価格が無効になったことが、確実に分かることがある。一方、他の価格も影響を受けることがあり、その場合の影響は不確実であるが、これによって、そのような価格が失効する確率は高くなり得る。例えば、「クラス・クローズド」イベントは、特定のフライトで、特定の予約クラスが満席になったことを示している。このフライトのこのクラスの座席は、もはや予約できなくなり、従って、再計算トリガ・プラットフォーム４でキャッシュされたそれぞれの価格は、確実に無効となった。一方、これは、同じフライトの他のクラス、および／またはそのフライトの前後の出発が近い他のフライトの同じクラスの座席の、変更度がより高くなった可能性を示すものと考えることができる。従って、それらの失効した確率が高まった可能性があり、それらの価格を再計算することが効果的となり得る。他の例として、低価格航空会社では、フライト・オキュパンシに応じて、その座席の価格が設定されることがある。オキュパンシ変更の通知の際に、それぞれのキャッシュされた価格を迅速に再計算することができ、これにより、キャッシュ正確度を向上／回復させる。

運賃変更イベントの影響を推定することは難しい。簡単に言えば、運賃は、情報と、特定のフライトの価格を計算するために用いられるルールなどのロジックと、を含む。従って、特定のフライトの実際の価格を計算する際には、運賃のセットにアクセスして、どの運賃が該当し、実際に適用されるべきであるか決定されて、最終的に価格が計算される。このように、関係「フライト→運賃（複数の場合もある）」がある（ただし、これは、特定のフライトにどの運賃を適用するかの制約が変わり得ることで、時間の経過とともに変わることもある）。一方、逆方向の関係「運賃→フライト」は一般に追跡されず、つまり、どの運賃がどのフライトに適用されるのかは、明らかではない。また、運賃の変更は、基礎となるデータドメインから算出された膨大な量の価格に影響を及ぼす可能性がある。

運賃イベントの影響を明らかにするために、計算プラットフォーム２と再計算トリガ・プラットフォーム４との間の通信を利用して、計算プラットフォーム２で価格を計算するために適用された運賃へのマッピングを再計算トリガ・プラットフォーム４に提供することができる。再計算命令に応えて価格を計算する際に、計算プラットフォーム２は、要求された価格を計算するためにアクセスしたすべての運賃を記録する。この情報は、その後、運賃→フライトのマッピングで、グローバルに保存されて、それぞれの計算の際に計算プラットフォーム２により維持される。運賃変更イベントを受け取ったときに、入力マネージャ４０は、このグローバルマッピングを検索して、これにより、その運賃変更イベントの影響を受けるフライトを特定し、それらを「更新」とマークする。留意すべきことは、上記で簡単に説明したように、運賃の変更は、旅行リコメンデーションの価格変更を必ずしも意味するものではないということである。

コンソリデータ４２は、イベントと基本的な確率モデルとの関係を考慮しないまま、キャッシュされた旅行リコメンデーションの再計算を起動するのではなく、まず最初に、リアルタイムイベントが、キャッシュされた価格に及ぼし得る影響を評価する。そのようなイベントは、最初に、確率モデルにおけるそれらの表現に関して分析される。予測可能ではないため確率モデルには全く含まれていない、例えば、販売促進キャンペーンまたは保守イベントのようなイベントの場合、これらのイベントは、できる限り迅速に処理される。一方、少なくとも、ある程度は確率モデルで表現されている、運賃またはアベイラビリティの変更のようなイベントは、蓄積されて、それらの発生が、確率モデルの予測と比較される。イベントのピークが、モデルと局所的に一致しない場合、すなわち、イベントのバーストが、確率モデルの基礎となる統計から著しく外れている場合には、影響を受ける価格は、失効している可能性があるものとして、できる限り迅速にそれらを再計算するように、マークする。これによって、既に確率モデルに含まれていることで、予めアナライザ４１で行われる決定で既に考慮されたイベントに起因する「ノイズ」が、除去される。

オプションとして、最適化のために、コンソリデータ４２は、内部データ表現４３のグリッドビューにおいて動作し、すなわち、その価格セットで単独に動作するのではなく、そのアルゴリズムにおいて、隣接する価格群を併せて考慮する。このアプローチにおいて、隣接する価格データセットは、集約された特性値を持つ個々のデータセットと考えられる。集約されたデータセットにおいて動作することで、疎な再計算命令の生成を制限し、こうして、計算プラットフォーム２での相補化および最適化の機会を高める。これにより、計算コストが削減される。

図２２は、上記の詳細説明を要約したものであり、本明細書で提示するキャッシュ更新方法の概観を示している。

事前計算済みデータベースクエリ結果のキャッシュを最新状態に維持するプロセスは、キャッシュされたクエリ結果が不正確である確率の決定４４から始まる。この決定は、２つの論理レベルにある２つのアクティビティで構成される。第１には、おおよそで、統計的確率データに基づく予測モデルを採用して、これにより、特定のキャッシュされたクエリ結果が、（仮に）再計算された場合のクエリ結果に一致していない可能性を推定する。第２には、より具体的に、キャッシュされたクエリ結果が失効している確率にそれぞれ影響を及ぼして、その確率を高める可能性のあるリアルタイムイベントを、考慮に入れる。これらのリアルタイムイベントは、それらが、一般に、個々のキャッシュされたクエリ結果が不正確であることを確実に示すものではないことによって特徴付けられ、この点で、非決定論的である。従って、それらが発生したときには、正確であることと、不正確であること、それぞれの可能性についての確率的結論を得ることができるのみである。

ミラーリングされた事前計算済みデータベースクエリ結果の失効について決定された確率に基づいて、再計算トリガ・プラットフォーム４により、バッチ再計算命令が自動的に発行される４５。これらの命令は、計算プラットフォーム２により受け取られて、これにより、個々の結果が再計算され、それらは、再計算トリガ・プラットフォーム４に返される４６。計算プラットフォーム２は、さらに、これに応じて検索プラットフォーム（複数の場合もある）３のメモリを更新する。次に、再計算トリガ・プラットフォーム４は、結果を受け取って、それらをローカル表現４３で保存する４７。これで、更新の１サイクルが終了し、次のサイクルを、確率の決定４４から再度繰り返す。

次に、図２３に関連して、キャッシュ更新の本戦略の手順のタイミングに関する具体例について説明する。本例では、再計算トリガ・プラットフォーム４は、２０分毎にバッチ再計算命令を生成するように構成されており、すなわち、キャッシュされたデータが失効しているかどうかの確率を決定して、再計算命令を生成および発行する１ラウンドもしくは１サイクルは、２０分を要する。計算プラットフォーム２におけるリソースは、丸１日についてアプリオリに分かっており、再計算トリガ・プラットフォーム４は、計算プラットフォーム２で利用できる計算リソースを認識しているので、再計算量を、計算プラットフォーム２で利用できるリソースと同期させることが可能である。

再計算サイクルの最初に、再計算トリガ・プラットフォーム４は、ミラーリングされた事前計算済みデータベースクエリ結果の、すなわち、内部データベース４３に保存されている価格付き旅行リコメンデーションの、現在の正確度を分析する。１ラウンドで、再計算命令のセットが生成され、これは、２０分ラウンドの終わりに、計算プラットフォーム２で処理される。一方、計算プラットフォーム側では、直前のサイクルからの命令が計算されているところであり、新たな価格リコメンデーションが生成されて、再計算トリガ・プラットフォームに返送され、そこで保存されて、次のサイクルにおいて、繰り返される情報の分析および更新のために利用できる。

図２３は、計算プラットフォーム２には、午前４時００分〜午前５時００分の時間帯に、利用できるリソースがかなりあることを示しており、従って、この時間帯に多くの再計算を実行することができる。ところが、その後、午前９時００分までは利用できるリソースがないため、この時間帯には再計算を実行できない。その後、日中の午前９時００分から午後７時００分までは、若干のリソースが、計算プラットフォーム２で利用できる。

午前４時２０分に開始するサイクルにおいて、アナライザ４１は、キャッシュ正確度を分析し、一方、コンソリデータ４２は、それに応じて再計算命令を生成する。それらの命令は、午前４時４０分に、計算プラットフォーム２で実行される。アナライザ４１は、そのラウンドの最初に受け取ったＭＣＰ価格リコメンデーションに着目する。それは、受け取った価格と、内部リポジトリにその値が保存されている前回の価格との相違をカウントする。この相違に基づいて、それは、繰り返し情報ソースの「変更度」を修正する。入力マネージャ４０は、受け取ったＭＣＰ価格を、さらなる調査のために保存する。午前４時４０分〜午前５時００分のサイクルにおいて、計算プラットフォーム２は、午前４時２０分〜午前４時４０分の時間帯に再計算トリガ・プラットフォーム４から受け取った再計算命令を処理する。再計算トリガ・プラットフォーム４は、次（午前５時００分）のタイムスライスとその後も午前９時００分までは、再計算命令を生成できないことを認識している。それでも、それは、依然としてデータモデルの分析を継続することで、すべてのキャッシュされた価格付き旅行リコメンデーションの現在の正確度を更新する。その後の午前８時４０分までの各サイクルで、同じことを行う。

午前８時４０分に、アナライザ４１は、キャッシュの正確度が、再計算なしのこれまで４時間の間に低下したことを確認する。従って、それは、続くサイクルにわたって再計算命令を生成するが、ただし、午前９時００分〜午後７時００分までは、計算プラットフォーム２で利用できるリソースの量が限られているので、より少ない程度のみとする。その場合、計算プラットフォーム２は、午前９時００分に、前の期間（すなわち、午前８時４０分〜午前９時００分）に受け取った新たな再計算命令の処理を開始し、午後６時４０分から午後７時００分まで続くラウンドの終了後に停止する。

その後、夜間を通して、計算プラットフォーム２で利用できるリソースはもうない。従って、再計算トリガ・プラットフォーム４は、それ以上、再計算命令を生成しないが、ただし、確率モデル、および可能性のある入来リアルタイムイベントに基づいて、キャッシュ正確度の分析は継続する。

再計算／更新の本戦略は、キャッシュ再計算の決定を自動的に生成する手段を提供するものである。これは、キャッシュされたどのクエリ結果を再計算すべきかを決定し、さらに時間的にも、計算プラットフォームで利用できる計算リソースを考慮することで、再計算を制御する。その場合、おおよそで、キャッシュされたクエリ結果の正確度は、時間経過による最新性および失効性をそれぞれモデル化した確率モデルによって推定される。この失効分析によって、ミラーリングされた事前計算済みデータベースクエリ結果の再計算の基礎となるデータセットの、１時間あたり数十億件の処理が許可される。

要するに、本明細書で提示する再計算トリガ・プラットフォームは、以下の点を特徴とすることができる。

１．分散データベースシステムにおいて、ミラーリングされた事前計算済みデータベースクエリ結果を更新する方法であって、分散データベースシステムは、事前計算済みデータベースクエリ結果を保持する再計算トリガ・プラットフォームと、計算プラットフォームであって、ミラーリングされた事前計算済みデータベースクエリ結果を、該計算プラットフォームに保持されたデータに基づいて計算するための計算プラットフォームと、を備え、本方法は、
− ミラーリングされた事前計算済みデータベースクエリ結果が失効している確率を、データキャッシュ・プラットフォームにより決定することであって、
− その決定は、確率モデルと、非同期リアルタイムイベントの発生と、に依存し、
− 確率モデルは、再計算トリガ・プラットフォームに保持されているミラーリングされた事前計算済みデータベースクエリ結果と、推定される実際のデータベースクエリ結果と、の間の不一致をモデル化しており、
− リアルタイムイベントは、ミラーリングされた事前計算済みデータベースクエリ結果の失効に関して非決定論的であって、再計算トリガ・プラットフォームに保持されているミラーリングされた事前計算済みデータベースクエリ結果と、推定される実際のデータベースクエリ結果と、の間の不一致に対して、確率的な影響を及ぼすのみであり、
− 確率は、全般的には確率モデルに基づいて決定され、さらに非同期リアルタイムイベントの発生時に修正される可能性がある、確率を決定することと、
− 事前計算済みデータベースクエリ結果の失効について決定された確率に基づいて、ミラーリングされた事前計算済みデータベースクエリ結果を更新するための再計算命令であって、失効している確率が他のものよりも高いミラーリングされた事前計算済みデータベースクエリ結果を再計算することを命じる再計算命令を、データキャッシュ・プラットフォームにより、計算プラットフォームに対して自動的に発行することと、
− 再計算命令の結果として更新された事前計算済みデータベースクエリ結果を、データキャッシュ・プラットフォームで受け取ることと、を含む。

２．特徴点１の方法において、確率モデルは、計算プラットフォームに保持されるデータの変更度を、統計的履歴データに基づいてモデル化している。

３．特徴点１または特徴点２の方法は、さらに、
− データキャッシュ・プラットフォームにおいて、入来する非同期リアルタイムイベントが確率モデルで表現されているかどうか分析することと、
− 確率モデルで表現されていないリアルタイムイベントの場合に、個々の特定のミラーリングされた事前計算済みデータベースクエリ結果についての再計算命令を、できる限り迅速に発行することと、
− 確率モデルで表現されているリアルタイムイベントの場合に、そのようなリアルタイムイベントをある期間にわたって蓄積して、実際に発生した蓄積リアルタイムイベントを、確率モデルにおけるそれらの表現と比較し、実際に発生した蓄積リアルタイムイベントが、所定の程度まで、確率モデルにおけるそれらの表現から逸脱している場合に、影響を受ける可能性があるミラーリングされた事前計算済みデータベースクエリ結果についての再計算命令を、できる限り迅速に発行することと、を含む。

４．先行するいずれかの特徴点の方法において、データキャッシュ・プラットフォームは、ミラーリングされた事前計算済みデータベースクエリ結果が失効している確率を決定して再計算を発行する際に、計算プラットフォームに保持されているデータの隣接するセットのグループに対応する、ミラーリングされた事前計算済みデータベースクエリのグリッドについて考慮する。

５．先行するいずれかの特徴点の方法において、再計算トリガ・プラットフォームは、計算プラットフォームで利用できる計算リソースの量に基づいて、再計算命令を発行する。

６．先行するいずれかの特徴点の方法において、分散データベースシステムは、旅行予約システムであり、この場合、計算プラットフォームは、旅行のアベイラビリティおよび運賃に関する情報を保持しており、再計算トリガ・プラットフォームは、旅行アベイラビリティ情報および運賃から計算された価格付き旅行リコメンデーションを保持している。

７．特徴点６の方法において、リアルタイムイベントは、航空運賃変更、航空機座席アベイラビリティ変更、クライアント航空チケット要求、および／またはフライトキャンセルを含む。

８．先行するいずれかの特徴点の方法において、分散データベースシステムは、計算プラットフォームに接続された少なくとも１つのアプリケーション・プラットフォームを備え、少なくとも１つのアプリケーション・プラットフォームは、事前計算済みデータベースクエリ結果を維持および編成し、少なくとも１つのアプリケーション・プラットフォームに保存されているデータベースクエリ結果は、データキャッシュ・プラットフォームで発行された再計算命令の結果として、計算プラットフォームによるポピュレートおよび／または更新を受ける。

９．計算プラットフォームに保持されたデータに基づいて計算プラットフォームで計算された事前計算済みデータベースクエリ結果を保持する再計算トリガ・プラットフォームであって、再計算トリガ・プラットフォームは、
− ミラーリングされた事前計算済みデータベースクエリ結果が失効している確率を決定し、このとき、
− その決定は、確率モデルと、非同期リアルタイムイベントの発生と、に依存し、
− 確率モデルは、再計算トリガ・プラットフォームに保持されているミラーリングされた事前計算済みデータベースクエリ結果と、推定される実際のデータベースクエリ結果と、の間の不一致をモデル化しており、
− リアルタイムイベントは、ミラーリングされた事前計算済みデータベースクエリ結果の失効に関して非決定論的であって、再計算トリガ・プラットフォームに保持されているミラーリングされた事前計算済みデータベースクエリ結果と、推定される実際のデータベースクエリ結果と、の間の不一致に対して、確率的な影響を及ぼすのみであり、
− 確率は、全般的には確率モデルに基づいて決定され、さらに非同期リアルタイムイベントの発生時に修正される可能性があり、
− 事前計算済みデータベースクエリ結果の失効について決定された確率に基づいて、ミラーリングされた事前計算済みデータベースクエリ結果を更新するための再計算命令であって、失効している確率が他のものよりも高いミラーリングされた事前計算済みデータベースクエリ結果を再計算することを命じる再計算命令を、計算プラットフォーム（３）に対して自動的に発行し、
− 再計算命令の結果として更新された事前計算済みデータベースクエリ結果を受け取る、ように構成されている。

１０．特徴点９による再計算トリガ・プラットフォームは、さらに、
− 入来する非同期リアルタイムイベントが確率モデルで表現されているかどうか分析し、
− 確率モデルで表現されていないリアルタイムイベントの場合に、個々の特定のミラーリングされた事前計算済みデータベースクエリ結果についての再計算命令を、できる限り迅速に発行し、
− 確率モデルで表現されているリアルタイムイベントの場合に、そのようなリアルタイムイベントをある期間にわたって蓄積して、実際に発生した蓄積リアルタイムイベントを、確率モデルにおけるそれらの表現と比較し、実際に発生した蓄積リアルタイムイベントが、所定の程度まで、確率モデルにおけるそれらの表現から逸脱している場合に、影響を受ける可能性があるミラーリングされた事前計算済みデータベースクエリ結果についての再計算命令を、できる限り迅速に発行する、ように構成されている。

１１．非一時的なコンピュータ可読記憶媒体であって、その中にコンピュータプログラム命令が格納されており、それらがコンピュータシステム上で実行されることで、コンピュータシステムは、
− ミラーリングされた事前計算済みデータベースクエリ結果が失効している確率を決定し、このとき、
− その決定は、確率モデルと、非同期リアルタイムイベントの発生と、に依存し、
− 確率モデルは、コンピュータシステムに保持されているミラーリングされた事前計算済みデータベースクエリ結果と、推定される実際のデータベースクエリ結果と、の間の不一致をモデル化しており、
− リアルタイムイベントは、ミラーリングされた事前計算済みデータベースクエリ結果の失効に関して非決定論的であって、コンピュータシステムに保持されているミラーリングされた事前計算済みデータベースクエリ結果と、推定される実際のデータベースクエリ結果と、の間の不一致に対して、確率的な影響を及ぼすのみであり、
− 確率は、全般的には確率モデルに基づいて決定され、さらに非同期リアルタイムイベントの発生時に修正される可能性があり、
− 事前計算済みデータベースクエリ結果の失効について決定された確率に基づいて、ミラーリングされた事前計算済みデータベースクエリ結果を更新するための再計算命令であって、失効している確率が他のものよりも高いミラーリングされた事前計算済みデータベースクエリ結果を再計算することを命じる再計算命令を、自動的に発行し、
− 再計算命令の結果として更新された事前計算済みデータベースクエリ結果を受け取る。

１１．特徴点１〜８のいずれかの方法を実行するようにコンピュータに指示するためのコンピュータプログラム。

検索結果処理／表示サブシステム
他の態様により、クライアントによる要求を処理および表示する方法が、検索プラットフォーム（複数の場合もある）において提供される。この処理によって、クライアントのデータベースクエリで示された基準を満たす事前計算済みデータベースクエリ結果を返送し、体系化された方法で表示することが可能である。

このアプローチは、ユーザにとって特定の意味をそれぞれに持つ、データベースクエリ結果の１つ以上のカテゴリがあるという考えに、概ね基づいている。例えば、１つのカテゴリは、「更新が最も新しいクエリ結果」とすることができる。他のカテゴリは、「クライアントに返される頻度が最も高いクエリ結果」とすることができる。本アプローチによれば、第１のレベルで、クライアント要求により指定された基準を満たすデータベースクエリ結果は、そのようなカテゴリに分類される。第２のレベルで、それぞれのカテゴリ内の結果は、ソートまたはランク付けされる。カテゴリ分けおよびランク付けされた結果は、その後、クライアントに返されて、これにより、各カテゴリで少なくとも最上位またはいくつかの上位（例えば、上位３位まで、もしくは上位５位まで）の結果を、特有の方法で表示することができる。これらの「カテゴリ最上位のもの」または「カテゴリ上位のもの」は、例えばハイライト表示することができ、これにより、ユーザは、最新の結果はどれであるのか、および、クライアントの要求の頻度が最も高いものはどれであるのか、認識することが可能である。

後に提示されるクライアントクエリ結果を処理および表示する本アプローチの例は、コンピュータ化された旅行予約システム（ＣＲＳ）により実施される。ただし、留意すべきことは、本アプローチは、一般に、データベースクエリ要求の基礎となるデータの特定の性質および内容にかかわりなく、適用可能であるということである。当然のことながら、具体的なカテゴリは、データの内容に応じて定められる。しかしながら、全体的にいくつかのカテゴリを設けて、これらのカテゴリ内で結果をランク付けするという本アプローチは、あらゆる種類のデータに採用することが可能である。

ＣＲＳは、情報を保存および取得し、さらには、旅行サービスプロバイダにアクセスする顧客主導による航空旅行チケットのオンライン購入など、物品およびサービスに関連したオンライン・トランザクションを実行するために用いることができる。航空旅行の文脈では、ＣＲＳは、旅行サービスプロバイダからの旅程クエリに対して、指定された旅程を満たす特定のフライトを見つけることにより応答するように、さらには予約を取るか、または確定するように、構成される。ＣＲＳは、グローバルディストリビューションシステム（ＧＤＳ）において具現化することができ、それは、複数の航空会社の航空旅行チケットを予約および販売するタイプのＣＲＳである。クライアントクエリ結果を表示処理および表示するアプローチの本例によって、多数の可能な旅行オプションの中から１つ以上の特定の旅行オプションを選択すること、および、旅程クエリを発した顧客に対して、旅行サービスプロバイダを介して特定の旅行オプションを提示することが、容易となる。

旅行代理業者および代理店などの旅行サービスプロバイダは、ＣＲＳと対話することで、見込み顧客からのクエリに応えて旅行オプションを検索する。検索要求で具体化された照会に応じて、ＣＲＳは、要求の検索条件を満たす旅行オプションを含む検索結果を、１つ以上のデータベースから取得する。その後、ＣＲＳは、検索結果に含まれる旅行オプションを、１つ以上のカテゴリに属するように分類する。例えば、検索で返された航空旅程を表す旅行オプションは、低価格フライト・カテゴリおよび最速旅行オプション・カテゴリに属すると分類され得る。次に、各カテゴリから１つ以上の旅行オプションが、ランキングに基づく選別により選択されて、そのカテゴリの最適旅行オプション・サブセットに含められる。

従って、このようなサブセットの中の旅行オプションは、そのサブセットのそれぞれの旅行オプション・カテゴリ内で最適もしくは最良の旅行オプションを表すと考えられる。各サブセットは、これにより、より大きな旅行オプション群の範囲内で、その見込み顧客にとって、より望ましいと考えられる１つ以上の旅行オプションを提供する。これらの選択された旅行オプションは、その後、見込み顧客に対してお薦め結果として表示するために、旅行サービスプロバイダに伝達される。従って、１つ以上の最良または最適なオプションのサブセットは、カテゴリで分類された旅行オプションのより大きなセットのサブセットであり、そしてそれらは、検索基準を満たすすべての可能な旅行オプションのさらに大きなセットのサブセットである。このような最適オプション・サブセットを構成する旅行オプションは、旅行オプションをカテゴリで分類した後にカテゴリ内の上位Ｎ位までの旅行オプションを提示するためにカテゴリ内で旅行オプションをランク付けするためのロジックを適用することにより、選択される。顧客に表示される選択肢を、すべての可能な旅行オプションからのサブセットに限定することにより、クライアントに対して、より価値の高い改善された表示が実現される。

このために、クライアントクエリ結果の表示処理および表示のアプローチの例は、旅行サービスプロバイダの顧客があまりにも多くの選択肢に圧倒されることがないように、データベース検索エンジンにより返された旅行オプションのより大きなセットから、お薦め結果としてサブセットを選択することを目指すものである。それらのお薦め結果は、その後、旅行サービスプロバイダによって、その顧客に対して、ディスプレイ上で閲覧できるウェブページにおいて、特定の選択を行うための案内と共に提示されることができる。検索結果の処理によって、より関連性の低い結果またはオプションを取り除くための適切なロジックに基づいて、それほど望ましくない旅行オプションが除去される。１つのアプローチは、検索結果を処理するために、チケット価格、移動時間、出発時刻、または到着時刻などの単一のパラメータを用いることである。しかしながら、これらのような単純なパラメータによる動作は、顧客にとって、あまりにも明白であり、十分な知覚価値を提供できないことがある。顧客に提示するための旅行オプションを分類することと、ランク付けすることの組み合わせを用いることによって、検索結果選択の式またはアルゴリズムの動作は、それほど明白ではないようにできる。さらに、後の検索結果での選択アルゴリズムの性能は、システムによりアクセスできるデータベースに保存された過去の顧客行動に関連する各種データに基づく「自動学習」によって、向上させることができる。提示された旅行オプションに対する顧客の信頼をさらに高めるために、実施形態によって、信頼性の明確な根拠を顧客に対して提供し得る「信頼性スタンプ」を、それぞれの提案に与えることもできる。

検索結果処理／表示システムの例は、旅行オプション検索結果の適切性をスコア付けまたはランク付けする際に過去の顧客の選択を考慮する検索エンジンを、ＣＲＳに備えることができる。航空旅行という特定の文脈では、フライト検索結果は、公式および非公式の協議による運賃のデータベースから得ることができ、その後、以前の販売データ、予約データ、発券データ、および同様のフライトの要求データに少なくとも部分的に基づいて、ランク付けされることができる。例えば、特定の出発地と目的地のペアのフライトを検索した顧客または旅行代理店は、フライトを予約しようとしている現在のシステムユーザにとって関心があり適切である可能性が最も高いのはどのフライトであるのかについての洞察を提供する選択パターンを示されることがある。同様の検索パラメータのセットで検索を要求する顧客により選択される可能性がより高い（すなわち、確率が比較的高い）のはどのフライトであるのかについてのこの履歴は、これによって、現在のフライト検索結果を選別し、顧客に提示されるべきセレクションの数を絞り込むために用いることができる。視覚的混乱を軽減し、より扱いやすい旅行オプション選択肢のセットをお薦め結果として顧客に提供するために、過去の履歴から顧客に選択される可能性が低い（すなわち、確率が比較的低い）フライトは、表示される結果から除外することができる。

ＣＲＳの検索結果選択システムによって、どの旅行オプションを旅行サービスプロバイダにより顧客に対して提示すべきかを決定する際に、他のパラメータを利用することもできる。例として、指定された出発地、目的地、および旅行期日について、検索結果選択システムは、表示するためのお薦め結果を、旅行オプションの１つ以上のカテゴリから選択することができる。これらは、お薦め結果として、最も人気度の高い航空旅程（複数の場合もある）を、お薦め結果として、全体的に最速もしくは最短期間の航空旅程（複数の場合もある）を、お薦め結果として、旅行サービスプロバイダが１つ以上の選択された航空会社と交渉した限定オファーの一部である航空旅程（複数の場合もある）を、お薦め結果として、全体的に最安の購入可能フライト（複数の場合もある）もしくは旅行ソリューション（複数の場合もある）を、お薦め結果として、要求された旅行期日、出発地、および目的地について、すべての代理店で最後もしくは直近に予約された航空旅程（複数の場合もある）を、および／または、お薦め結果として、旅行サービスプロバイダによる特別なリコメンデーションを表すスポンサード航空旅程（複数の場合もある）を、表示することを含み得る。

別の例では、顧客に対して、その意思決定を支援するものとして表示するために、認定フラグまたは緊迫インジケータが、ＣＲＳから旅行サービスプロバイダに伝達される。緊迫インジケータは、お薦め結果の航空旅程のうち１つ以上について人気度を表している。例えば、ＣＲＳは、特定の航空旅程を予約した人数の表示を、緊迫インジケータとして、顧客に対して表示させるために旅行サービスプロバイダに伝達する。あるいは、ＣＲＳは、あるフライトもしくは同様のフライトが直近でいつ予約されたのかを示すタイムスタンプを、緊迫インジケータとして、顧客に対して表示させるために旅行サービスプロバイダに伝達する。あるいは、ＣＲＳは、ある航空旅程の現在の空席数についての警告表示を、緊迫インジケータとして、顧客に対して表示させるために旅行サービスプロバイダに伝達する。また、ＣＲＳは、顧客に対して表示させるために、複数の緊迫インジケータを同時に返すこともできる。

図２４を参照して、本発明の一実施形態によれば、図１のデータベースシステム１に相当し得る検索結果選択システムの例示的な運用環境には、ＣＲＳ１２の形態の旅行オプション検索システム・プラットフォーム、ユーザ・プラットフォーム１４、および少なくとも１つのデータベース・プラットフォーム１６が含まれる。ハードウェア・プラットフォーム１２、１４、１６は、ネットワーク１８を介して相互に作用的通信を行う。ハードウェア・プラットフォーム１２は、プロセッサ６１と、メモリ９１と、マスストレージデバイス７７と、ネットワークインタフェース６９と、ヒューマンマシンインタフェース（ＨＭＩ）５０と、を含むことができる。ハードウェア・プラットフォーム１４は、プロセッサ６３と、メモリ８９と、マスストレージデバイス８３と、ネットワークインタフェース７１と、ＨＭＩ ５１と、を含むことができる。ハードウェア・プラットフォーム１６は、プロセッサ６７と、メモリ９３と、マスストレージデバイス８１と、ネットワークインタフェース７３と、ＨＭＩ ５２と、を含むことができる。

プロセッサ６１、６３、６７のそれぞれは、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ、マイクロコンピュータ、中央処理装置、フィールドプログラマブルゲートアレイ、プログラマブルロジックデバイス、ステートマシン、論理回路、アナログ回路、デジタル回路、および／または関連付けられたプラットフォームのメモリ８９、９１、９３に格納された演算命令に基づいて（アナログおよび／またはデジタル）信号を操作する他のデバイス、から選択された１つ以上の処理回路を含むことができる。メモリ８９、９１、９３のそれぞれは、単一のメモリデバイスまたは複数のメモリデバイスを有することができ、それには、リードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、揮発性メモリ、不揮発性メモリ、スタティック・ランダムアクセスメモリ（ＳＲＡＭ）、ダイナミック・ランダムアクセスメモリ（ＤＲＡＭ）、フラッシュメモリ、キャッシュメモリ、および／またはデジタル情報を記憶することが可能な他のデバイスが含まれるが、ただし、これらに限定されない。マスストレージデバイス７７、８１、８３のそれぞれは、単一のマスストレージデバイスまたは複数のマスストレージデバイスを有することができ、それには、ハードドライブ、光学ドライブ、テープドライブ、不揮発性固体デバイス、および／またはデータベース構造８５、８７のようなデータを記憶することが可能な他のデバイスが含まれるが、ただし、これらに限定されない。

ネットワークインタフェース６９、７１、７３は、ユーザデータグラムプロトコル／インターネットプロトコル（ＵＤＰ／ＩＰ）、および／または伝送制御プロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）など、ネットワーク１８を介して通信するための１つまたは複数の適切な通信プロトコルを採用することができる。ネットワークインタフェース６９、７１、７３は、ＩＥＥＥ８０２．３（イーサネット（登録商標））リンクのような有線リンク、８０２．１１（Ｗｉ−Ｆｉ）リンクなどの無線ネットワークプロトコルを用いる無線リンク、またはハードウェア・プラットフォーム１２、１４、１６がネットワーク１８とインタフェースすることを可能にする他の適切なリンクを介して、ネットワーク１８に接続することができる。ネットワーク１８は、１つ以上のローカルアクセスネットワーク（ＬＡＮ）、ワイドアクセスネットワーク（ＷＡＮ）、および／またはインターネットのような公衆ネットワークなど、複数の相互接続されたネットワークを含むことができる。インターネットは、相互接続されたコンピュータネットワークのグローバルシステムである。ワールドワイドウェブは、インターネットを介してアクセスされる、相互リンクされたハイパーテキスト文書のシステムであり、より具体的には、通常はウェブサーバからウェブブラウザでアクセスされる、ハイパーリンクおよびユニフォームリソースロケータ（ＵＲＬ）でリンクされたテキスト文書および他のリソースの集まりである。ウェブブラウザで、ユーザ／顧客は、ハードウェア・プラットフォーム１４をホストとするアプリケーションであり得るＣＲＳによって生成されるウェブページを閲覧することができ、それは、テキスト、画像、ビデオ、および他のマルチメディアを含むことができ、また、それらの間でハイパーリンクによりナビゲートすることができる。

プロセッサ６１、６３、６７のそれぞれは、各々のプラットフォーム１４、１６、１８の対応するメモリ８９、９１、９３に常駐し得るそれぞれのオペレーティングシステム８８、９７、９９の制御の下で動作することができる。オペレーティングシステム８８、９７、９９は、それぞれのプラットフォーム１４、１６、１８のコンピュータリソースを管理することができ、これにより、メモリ８９、９１、９３に常駐する１つ以上のコンピュータソフトウェアアプリケーション５４〜５７として具現化されるコンピュータプログラムコードの命令は、プロセッサ６１、６３、６７により実行されることができる。ＨＭＩ５０〜５２は、周知の方法で、各々のハードウェア・プラットフォーム１２、１４、１６のプロセッサ６１、６３、６７に、作用的に接続され得る。ＨＭＩ５０〜５２は、英数字表示装置、タッチスクリーン、および他の視覚インジケータなどの出力装置と、英数字キーボード、ポインティングデバイス、キーパッド、プッシュボタン、コントロールノブなど、オペレータからコマンドまたは入力を受け取って、入力された入力をプロセッサ６１、６３、６７に伝送することが可能な入力装置およびコントロールと、を含むことができる。

図２５を参照して、ＣＲＳ１４の旅行オプション検索システム（ＴＯＳＳ）６０は、検索プラットフォーム３（大規模検索プラットフォーム、ＭＳＰ）のインスタンスと、計算プラットフォーム２のインスタンス（大規模計算プラットフォーム、ＭＣＰ）と、を含む。ＴＯＳＳ ６０を構成する図２５に示す機能は、ＴＯＳＳプラットフォーム１２をホストとする１つ以上の検索アプリケーション５４、５５によって提供することができ、さらに／またはネットワークもしくは他の通信媒体を介して接続された別々のハードウェア・プラットフォームで実行されるアプリケーションによって提供することができる。計算プラットフォーム２は、キャッシュマネージャ・モジュール６８と、プライシングエンジン・プラグイン６５と、運賃検索エンジン・プラグイン６６と、を含む。キャッシュマネージャ・モジュール６８は、検索プラットフォーム３およびプラグイン６５、６６から入来する再計算命令を管理して、計算済みデータベースクエリ結果を検索プラットフォーム３に返す。

計算プラットフォーム２に関連して上記で詳述したように、計算プラットフォームの主な機能は、所定の時間枠内で多数の価格を計算し、それらの計算結果を検索プラットフォーム３に供給することである。図２５の例では、プラグイン６５、６６は、これらの目的を果たすように構成されており、また、上記で詳述した機能を実現するように構成されている。簡単にするため、図２５では、大規模マスタ２０および大規模ワーカ２２を示していない。計算プラットフォーム２は、これによって、検索プラットフォーム３が、任意に大量のデータにアクセスし、さらに／または任意に多数の価格計算を実行することを可能にする、完全なスケーラビリティを提供するものである。運賃検索エンジン・プラグイン６６は継続的に作動することができ、これにより、最安運賃旅行オプションは、計算プラットフォーム２によって絶えず更新され、また、検索プラットフォーム３でリフレッシュされる。追加的または代替的に、再計算トリガ・プラットフォーム４の事前計算済みデータベースクエリ結果を更新するためのスマートなアプローチを採用することができる（簡単にするため、図２５では示していない）。検索プラットフォーム３内の旅行オプションデータは、これにより、リアルタイムまたは略リアルタイムの運賃価格設定を反映することができる。事前計算されたことが全くないデータ、または最低運賃旅行オプションの中で最近更新されたデータ、を必要とする特殊な旅程を含む検索要求の場合、プライシングエンジン・プラグイン６５は、キャッシュマネージャ６８の内部要求に応じて、特殊な旅程についての特殊な価格を計算することができる。特殊な価格の旅程は、その後、キャッシュマネージャ・モジュール６８によって検索プラットフォーム３に供給することができる。

プライシングエンジン・プラグイン６５と運賃検索エンジン・プラグイン６６はどちらも、旅行代理店発信委託（ＴＡＯＣ）手数料データベース７０、航空運賃データベース７２、フライトスケジュール・データベース７４、およびフライトアベイラビリティ・データベース７５など、航空便に関するデータを含む１つ以上のデータベースと作用的通信を行うことができる。ＴＡＯＣ手数料データベース７０は、ＴＯＳＳオペレータと以前から関係があるオンライン旅行代理店によって加えられる付帯的サービスに関する情報を含むことができる。運賃データベース７２は、公示運賃と協議運賃とを含むことができ、例えば、航空会社の公示運賃と旅行代理店の協議による運賃とを含むことができる。同様に、スケジュール・データベース７４は、航空会社のフライトスケジュールを含むことができ、フライトアベイラビリティ・データベースは、フライトのアベイラビリティおよび／またはフライトの空席に関する情報を含むことができる。データベース７０、７２、７４、７５のそれぞれは、ＴＯＳＳ ６０内ではアクセス可能であるが、システム６０の外部からはアクセスできない独自のデータを含むデータベースを有し得る。データベース７０、７２、７４、７５のそれぞれは、さらに、公的にアクセス可能なデータベースから入手できるデータを含むこともできる。スケジュール・データベース７４とフライトアベイラビリティ・データベース７５など、データベース７０、７２、７４、７５のうち２つ以上を、単一のデータベースに統合してもよい。

旅行オプションデータを取得するために、運賃検索エンジン・プラグイン６６（一般に、多数の旅程を一度に処理する）および／またはプライシングエンジン６５（一般に、１つの旅程を一度に処理する）のうち１つ以上が、データベース７０、７２、７４、７５に照会して、低運賃検索プロセスを実行し、検索結果を伝送する。それらの結果は、次に、検索プラットフォーム３に送られる。検索結果処理／表示サブシステムの一例では、計算プラットフォーム２のプラグイン６５、６６が、検索要求の検索条件にマッチするフライトの価格、アベイラビリティ、およびスケジュールのデータを含む結果を返送する。典型的な検索条件は、様々に異なる旅程（例えば、出発／目的地、および旅行の期日）を含み得る。

旅行オプションの人気度の決定、直近予約日、および／または直近タイムスタンプのインデキシング機能を促すため、キャッシュマネージャ６８は、最終予約日／タイムスタンプ（ＬＢＤＴ）データベース８０と作用的通信を行うことができる。ＬＢＤＴデータベース８０は、システムユーザにより予約された旅行オプションに関する履歴データを含む１つ以上の独自のデータベースを維持すること、および／またはそれにアクセスすることができる。図２５に示す例では、ＬＢＤＴデータベース８０は、予約情報データベース８２と、独自の発券データベース８４と、市場情報データベース８６と、を含む。予約情報データベース８２は、ＴＯＳＳ ６０を介してユーザにより実行された旅行予約についての、すべての乗客名レコード（ＰＮＲ）データを含み得る。独自の発券情報データベース８４は、旅行予約システムにより販売されたすべてのチケットに関するデータを含み得る。独自の予約情報データベース８２および発券情報データベース８４の中のデータは、チケットが予約されるときにＴＯＳＳ ６０によって収集されるデータとすることができる。従って、このデータは、ＴＯＳＳ ６０の外部のシステムからは直接利用できないデータであり得る。市場情報データベース８６は、例えば、旅行代理店、航空会社、および／または他の旅行予約システムにより操作することができるグローバルにアクセス可能なすべてのＰＮＲデータベースのインベントリを含むことができる。

図２５の例では、検索プラットフォーム３は、データベース７０、７２、７４、７５、８０から得られた検索結果を、１つ以上の式、アルゴリズム、ルール、および／または基準に従って、インデックス付けおよび／またはカテゴリ分けする旅行ソリューション・スマートインデックス（ＴＳＳＩ）７６を有する。ＴＳＳＩは、図１１に関連して上述したような検索プラットフォーム３のインメモリ・ストレージ３０１に相当し得る。検索結果は、上記で詳述したように、キャッシュマネージャ６８によって、ＴＳＳＩ ７６に供給することができる。キャッシュマネージャ６８は、プライシングエンジン・プラグイン６５および運賃検索エンジン・プラグイン６６により返されたデータベースクエリ結果を管理する。キャッシュマネージャ６８は、予約、発券、および市場情報データが更新されたときに、ＴＳＳＩ ７６内のデータが、リアルタイムまたは略リアルタイムで最新の状態に保たれるように、検索プラットフォーム３内のデータを、ＬＢＤＴデータベース８０から定期的にリフレッシュする。カテゴリ分けされた検索結果は、さらに、表示される結果を扱いやすい件数に制限することを容易とするため、１つ以上のデータベースまたはサブデータベースから取得される旅行予約履歴データなど、ランキングを用いて、ＴＳＳＩ ７６により、ソートまたはランク付けすることができる。例えば、ＴＳＳＩ ７６は、特定の検索について、選択されたランク付けパラメータに基づいて、結果をソートすることができる。お薦め結果トランザクション７９は、このインデキシングまたはランキングを用いて、１つ以上のカテゴリのそれぞれで選択された１つ以上の結果を表示することができ、それらの選択された結果は、ある特定の一次検索カテゴリで得られる「最適な」選択肢を表している。入手できる最新の予約データおよび発券データに従って、検索結果がランク付けされるように、ランキングは、定期的に再計算および／またはリフレッシュされ得る。検索結果データをホスティングおよびインデックス付けするＴＯＳＳ ６０内に、例えばインメモリ・ストレージ３０１の形態でローカルデータベースを設けることによって、ＴＳＳＩ ７６は、検索要求に対する、より高速の応答時間を、エンドユーザに提供することができる。これにより、システムユーザによって検索要求が発行されるたびごとに外部のデータベースから旅行オプション情報を取得しなければならないシステムと比較して、知覚されるシステム性能を向上させることができる。

旅行サービスプロバイダは、顧客からの照会に応じて、旅行オプションを検索するために、ウェブサイトを通してＴＳＳＩ ７６と対話することができる。一般的に、ウェブサイトは、通常は共通のサーバ上にあって相互接続されたウェブページの集まりであって、情報の集まりとして整備および維持されているものである。旅行サービスプロバイダからのクエリに応答する際に、お薦め結果トランザクションを表示機能７８に提供することができ、そしてこれにより、お薦め結果が、ディスプレイ上で読み取り可能な形式で、要求元エンティティに対して提示される。要求元エンティティは、旅行代理店のウェブサイト、旅行オプション予約アプリケーション５６、またはシステムユーザもしくは顧客によって旅行オプションの検索および予約のために使用され得る他のアプリケーション、とすることができる。また、表示機能７８は、アプリケーションプログラミングインタフェース（ＡＰＩ）を提供することもでき、これは、旅行オプション予約アプリケーション５６、ウェブサーバ・アプリケーション（図示せず）、または他の適切なアプリケーションなど、外部のリソースまたはアプリケーションによって、ＴＯＳＳ ６０へのインタフェースとして用いられる。

検索結果の選択、インデキシング、および／またはランク付けを定式化する際には、あらゆる可能性のあるデータのソースおよびタイプを、旅行オプション選択履歴データの予備的分析において考慮することができる。この分析に基づき、旅行オプション特性を、顧客の選択へのそれらの影響または相関に基づいて、選択することができる。分析される旅行オプションデータには、いくつかのパラメータの例を挙げると、チケット価格、移動時間、航空会社、およびその旅行オプションが予約された回数、を含むことができるが、ただし、これらに限定されない。例として、旅行オプションが過去に予約された回数は、旅行オプションの分類の、あるカテゴリを定義するために用いることができ、さらには、そのカテゴリ内または別の異なるカテゴリ内で検索結果をランク付けするために用いることができる。その場合、システムは、予約されたオプションを、予約されなかった他の代替旅行オプションまたは予約された選択率がより低かった他の代替旅行オプションと、区別できるあらゆる可能な基準を定義することができる。例えば、フライト予約率は、飛行時間、出発時刻、帰路時刻、乗り継ぎ回数、総価格、航空会社、出発空港、到着空港、出発曜日、帰路曜日、出発日、帰路日などに相関させることができる。これらの旅行オプション特性のそれぞれを組み合わせることで、対応する旅行オプションが選択される頻度に相関する複合値を求めることができる。そして、この値は、旅行オプション検索のお薦め結果を選択するために用いられるいくつかのうちの１つとなり得る。

予約された旅行オプションを区別するために用いられるカテゴリは、上記で列挙したいずれかのものに限定されることなく、旅行オプションを特徴付ける任意の基準を含むことができる。システムは、データセットを分析し、その分析に基づいて、適切なカテゴリを選択することができる。この分析では、データセットの様々に異なる次元を考慮に入れて、各データ点で得られるデータの量に応じて、評価のバランスをとることができる。ある特定のデータ点のデータが十分でない場合には、このプロセスで、変数が相当量のデータで表されるまで、変数を抽象化または補間することができる。選択されたカテゴリは、お薦め結果としてシステムユーザにどの結果を提示するかを決定するために、検索結果に適用することができる。また、影響を及ぼすカテゴリの組み合わせをグループ化することで、システムユーザに対して提示される旅行オプション・セレクションに多様性を持たせることもできる。

この目的で、計算プラットフォーム２により（事前）計算されたデータベースクエリ結果を分類するために、ＴＳＳＩ ７６によって用いられるカテゴリには、限定するものではないが、以下のカテゴリを含むことができる。

最速 − ＴＳＳＩ ７６は、計算プラットフォーム２からの計算済みデータベースクエリ結果を処理することで、要求された期日で、出発地から最終目的地までの所要時間が最短である旅行オプションのうち、指定された限定数の旅行オプションを、お薦め結果トランザクション７９に含めるべきお薦め結果のセットとして特定することができる。あるいは、ＴＳＳＩ ７６は、要求された期日で、出発地から最終目的地までの所要時間が最短である旅行オプションを特定することができ、これを単一のお薦め結果として表示することができる。数値例として、お薦め結果のセットに含まれる指定された限定数の旅行オプションは、１０件の最速旅行オプションとすることができる。所要時間には、旅程の飛行時間と、旅程における乗り継ぎの間の地上時間と、その両方を含むことができる。お薦め結果のセットは、表示のために、このカテゴリの格付け通りに（すなわち、最速の旅行オプションから最遅の旅行オプションまで）、ソートすることができる。あるいは、旅行オプション価格などによるランク付けを用いて、お薦め結果を、表示のために、最安から最高価格までソートすることができる。例えば、お薦め結果のセットの中の１０件の最速旅行オプションを、表示のために、最安の旅行オプションから最高価格の旅行オプションまでランク付けすることができる。

高人気 − ＴＳＳＩ ７６は、計算プラットフォーム２からの計算済みデータベースクエリ結果を処理することで、例として、予約される頻度が最も高い、または発券される頻度が最も高い、すなわち最も人気度の高い旅行オプションのうち、指定された限定数の旅行オプションを、お薦め結果トランザクション７９に含めるべきお薦め結果のセットとして特定することができる。あるいは、ＴＳＳＩ ７６は、予約される頻度が最も高い、または発券される頻度が最も高い旅行オプションを１つのみ特定することができ、これを単一のお薦め結果として表示することができる。このカテゴリでは、世界中で予約または発券されたチケット、ある所定の市場で予約または発券されたチケットのみ、またはある売場で予約または発券されたチケットのみ、など、編集される予約および発券データにおいて様々に異なるレベルの粒度を採用することができる。また、人気度におけるこれらのサブカテゴリを組み合わせて、複合人気度を生成することもできる。お薦め結果のセットは、表示のために、このカテゴリによる格付け通りに（すなわち、最も人気度の高い旅行オプションから最も人気度の低い旅行オプションまで）ソートするか、または、旅行者が希望する路線、航空会社、スケジュール、および／もしく費用など、他のパラメータとの組み合わせによって、表示のためのお薦め結果を限定することができる。

独占 − ＴＳＳＩ ７６は、計算プラットフォーム２からの計算済みデータベースクエリ結果を処理することで、提携旅行代理店による１社以上の航空会社との協定による付帯的サービスを含む旅行オプションのうち、指定された限定数の旅行オプションを、お薦め結果トランザクション７９に含めるべきお薦め結果のセットとして特定することができる。あるいは、ＴＳＳＩ ７６は、協定による付帯的サービスを含む旅行オプションを１つのみ特定することができ、これを単一のお薦め結果として表示することができる。典型的な付帯的サービスとして、例えば、無料ラウンジの利用、食事のアップグレード、および／または座席のアップグレードなど、その旅行者に限定のあらゆる付加的サービスを含むことができる。提携旅行代理店は、ＴＯＳＳ ６０にアクセスできる１つ以上の選択された旅行代理店であり得る。このカテゴリのお薦め結果は、表示のために、このような付帯的サービスに付けられた航空会社の運賃にマッチする最安価格のリコメンデーションに基づいて、すなわち、旅行オプションの総費用および／または関連する航空運賃のみの費用に基づいて、順序付けすることができる。

最安 − ＴＳＳＩ ７６は、計算プラットフォームからの計算済みデータベースクエリ結果を処理することで、公示運賃、および１社以上の航空会社と参加旅行代理店との協議による非公示運賃の中で、お薦め結果トランザクション７９に含めるべき指定された限定数の最安旅行オプション（例えば、１０件の最安旅行オプション）を特定することができる。あるいは、お薦め結果トランザクション７９には、最安旅行オプションを１つのみ含めることができ、これを単一のお薦め結果としてユーザに表示することができる。複数の運賃が同じ価格である場合には、それらのオプションを、上記の「高人気」カテゴリに関して説明したような人気度に基づいて、表示のために順序付けすることができる。

最近の予約 − ＴＳＳＩ ７６は、計算プラットフォーム２からの計算済みデータベースクエリ結果を処理することで、すべての代理店で直近に予約された旅行オプションのうち、お薦め結果トランザクション７９に含める指定された限定数の旅行オプション（例えば、１０件の直近に予約された旅行オプション）を特定することができる。あるいは、ＴＳＳＩ ７６は、直近に予約された旅行オプションを１つ（例えば、最も直近のもの）のみ特定することができ、これを単一のお薦め結果として表示することができる。その特定の顧客が、例えば出発地および目的地が同じものなど同一または類似の特徴の旅行を過去に予約したことがある場合には、「最近の予約」があったオプションでは、その特定の顧客によって直近に選択されたフライトオプションを表示するか、またはその特定の顧客の過去の同一または類似の予約によって優先を与えることもできる。

スポンサード − ＴＳＳＩ ７６は、計算プラットフォーム２からの計算済みデータベースクエリ結果を処理することで、旅行代理店などのスポンサー団体により選択された旅行オプションのうち、お薦め結果トランザクション７９に含めるべき指定された限定数の旅行オプション（例えば、１０件の旅行オプション）を特定することができる。あるいは、ＴＳＳＩ ７６は、スポンサード旅行オプションを１つのみ特定することができ、これを単一のお薦め結果として表示することができる。このような旅行オプションは、特定の路線、航空会社、または運賃を含み得るものであり、また、例えば、より高い手数料が航空会社から旅行代理店に支払われるなど、スポンサー団体と旅行オプションプロバイダとの協議による取り決めに基づくものであり得る。

検索結果の処理／表示サブシステムの一例では、検索結果の各カテゴリは、人気順位によりランク付けすることができる。すなわち、カテゴリ内のランク上位の特定の件数Ｎの結果など、検索カテゴリからのサブセットが、人気度などの順位によってソートされる。その後、このランク付けされたサブセットから、最上位の結果または上位いくつかの結果を、お薦め結果として顧客に表示することができる。このようにして、顧客に提示される選択肢の数を、扱いやすい件数に制限することができる。このような制限によって、圧倒する数の選択肢により引き起こされる顧客の不安を軽減することができ、これによって、意思決定を、より迅速に、より少ないストレスで進めることができる。ＬＢＤＴデータベース８０は、ある特定のフライトを過去に予約した顧客数の他に、さらに、ある特定の旅程のチケットが最後に予約された時刻、ある特定の発券オプションの残席数に関する情報、および、ある特定の期日、時刻、価格、目的地などについて、チケットを予約した、または発券を受けた旅行者数など、特定の基準による人気度に関する情報を含むこともできる。お薦め結果は、最も人気度の高い目的地を、年間の時期によって（例えば、人々は３月にどこへのフライトを予約しているか）、出発地によって（例えば、人々はシカゴから空路でどこへ行っているか）、価格によって（最安の目的地はどこか）、または他の旅行パラメータによって、示すマップとして表示することができる。

次に、図２６を参照すると、フローチャート９０は、本発明の一実施形態による、お薦め結果選択アルゴリズムを示している。ブロック９２で、ＴＯＳＳ ６０は、検索クエリを受け取る。検索クエリは、典型的には、ユーザ・プラットフォーム１４をホストとする予約アプリケーション５６などのアプリケーションから発せられる。しかしながら、検索クエリは、旅行オプション検索システム・プラットフォーム１２をホストとするウェブサーバ・アプリケーション（図示せず）などのアプリケーションから、またはＴＯＳＳ ６０へのアクセスが提供されている他の適切なプラットフォーム上のサードパーティのチケット予約システムなどのアプリケーションから、発せられるものであってもよい。例えば、検索クエリは、旅行代理店のウェブサーバで実行されるアプリケーションまたは旅行オプション予約システムによって、顧客が要求する希望の旅行日の出発地と目的地の間の旅行オプションに応じて、発行されることができる。

ブロック９４で、ＴＯＳＳ ６０は、ＴＳＳＩ ７６データベースから検索結果を取得する。検索クエリに含まれる条件が、ＴＳＳＩ ７６でインデックス付けされた旅行オプションとマッチしない場合、ＴＯＳＳ ６０は、計算プラットフォーム２を介して追加のデータベース７０、７２、７４、７５、８０を検索することができ、また、更新されたデータをＴＳＳＩ ７６に提供することができる。これらの検索結果は、検索パラメータを満たす全ての旅行オプションを含むことができ、何千件にもなることがある。検索結果は、ＴＳＳＩ ７６によって、上述のようなカテゴリに分けてインデックス付けすることができる。

ブロック９６で、ＴＯＳＳ ６０は、第１のカテゴリをロードする。第１のカテゴリは、所要時間が最小、高人気、限定オファーがある、費用、最近の予約があった、さらに／またはスポンサーを持つ旅行オプションなど、上述のカテゴリのいずれかによって分類することができる。ブロック９８で、ＴＯＳＳ ６０は、ロードされたカテゴリにマッチする検索結果を選択して、ブロック１００に進む。選択された検索結果は、ブロック１００で、ランキングによって、カテゴリ内でランク付けまたはソートされる。ランキングは、例えば、予め選択された検索結果の人気度に基づき得るものであり、前述のようにＴＳＳＩ ７６によって決定することができる。また、ランキングは、旅行オプションのパラメータと、対応する旅行オプションが過去に予約または発券された頻度と、の間の相関に基づくものであってもよい。相関性のある組み合わせは、予約率と旅行オプション・パラメータとの相関に厳密に基づき得る。お薦め結果のセットを提供するために、カテゴリ内で上位にランク付けされた所定の件数Ｎの結果が、検索クエリ要求元に提示するものとして選択される。この所定の件数は、一般的にカテゴリ内の結果の総数よりも少なく、最上位の１つの結果とすることができる。

ブロック１０２で、ＴＯＳＳ ６０は、検索結果のすべてのカテゴリを閲覧したかどうか判断する。そうでない場合は（判断ブロック１０２の「ＮＯ」分岐）、ＴＯＳＳ ６０は、ブロック１０４に進み、検索結果の次のカテゴリをロードする。次に、ＴＯＳＳ ６０は、ブロック９８に戻って、新たにロードされたカテゴリを用いて、お薦め結果の選択プロセスを繰り返す。お薦め結果を求めて、すべての検索結果カテゴリを閲覧したら（判断ブロック１０２の「ＹＥＳ」分岐）、ＴＯＳＳ ６０は、ブロック１０６に進む。ブロック１０６では、要求元に提示するために選択された旅行オプションを取り出して、カテゴリ内の各お薦め結果または結果のグループについて、緊迫インジケータを計算する。次に、ＴＯＳＳ ６０は、ブロック１０８に進み、そこで表示機能７８によって、お薦め結果を要求元に提示する。

検索結果選択プロセスは、これにより、所与の検索要求に１つまたは複数の式を適用することができ、この場合、各式は個々のカテゴリに対応しており、検索パラメータを各式のデータセット次元にマッチさせることにより、式を適用する。検索結果選択プロセスは、次に、各式により生成された結果のリストをランク付けして、カテゴリで上位Ｎ件の結果を決定することができる。各式は、認定カテゴリに対応し得るものであり、これによって、提案されるそれぞれの結果を認定することができる。

各カテゴリは、結果とともに返すことが可能な認定フラグと関連付けることができる。他に緊迫フラグが、各お薦め結果とともに返されることもある。結果式は、定性的フラグと定量的フラグの両方を有し得る。定性的な式の場合には、式に関連付けられる具体的な定性基準を特定するように、認定フラグを決定することができる。例えば、フラグは、その式のカテゴリを、得られる最安または最速の旅行オプションであるものと特定することができる。定量的な式の場合には、認定フラグは、数値パラメータを含むことができる。例えば、認定フラグは、直近の予約時刻に基づいて、その旅行オプションがＸ分前に直近で予約されたというように、お薦め結果の旅行オプションの１つ以上に関連付けられた緊迫度とすることができる。他の例として、認定フラグは、お薦め結果の各旅行オプションが過去に予約された頻度に基づいて、お薦め結果に緊迫度として与えられることができる。さらに別の例として、認定フラグは、お薦め結果に与えられる緊迫度として、お薦め結果の各旅行オプションについて、インベントリにおける残席数を示すことができる。また、ある所与の結果が、複数のカテゴリに属することもある。例えば、ある特定のフライトは、希望の出発地と目的地のペアについて、最安かつ最速の旅行オプションである場合があり、その場合、そのフライトは、両方のカテゴリに属するものとしてインデックス付けされることになる。検索結果認定プロセスでは、各結果にフラグを設定し、定量的結果の場合は数値をルックアップすることができ、そして応答には、個々に認定フラグを含む結果のセレクションを含むことができる。

図２７を参照して、ブラウザアプリケーションなどによって表示され得る例示的なお薦め結果ページ１１０により、旅行オプション検索結果カテゴリ・ウィンドウ１１２ａ〜１１２ｆで、お薦め結果を提示する。図２７に示すような検索結果ページ１１０は、６つの検索結果カテゴリ・ウィンドウ１１２ａ〜１１２ｆを含んでいるが、本発明の実施形態では、任意の数のカテゴリ・ウィンドウを含むことができ、本発明は、特定の数のカテゴリ・ウィンドウに限定されない。また、各カテゴリで表示されるお薦め結果の数も、特定の数に限定されることなく、例えば、１つのお薦め結果とすることができる。お薦め結果の表示方法の別の例として、ユーザが特定のカテゴリ上で選択またはホバリングしたことに応えて、システムは、そのカテゴリの追加のお薦め結果を表示するために、カテゴリ・ウィンドウ１１２ａ〜１１２ｆを拡大することができる。従って、図２７に示すお薦め結果ページは、単にお薦め結果の表示方法の一例を示すものにすぎず、本発明の実施形態は、図示の表示構成に限定されないことは、当業者であれば理解できるであろう。

それぞれのカテゴリ・ウィンドウ１１２ａ〜１１２ｆは、検索結果の分類を識別するカテゴリ識別フラグ１１４ａ〜１１４ｆと、１つ以上のお薦め旅行オプション・セグメントウィンドウ１１６ａ〜１１６ｆ、１１８ａ〜１１８ｆと、価格／アベイラビリティ情報ウィンドウ１２０ａ〜１２０ｆと、を含むことができる。図２７に示すように、カテゴリ・ウィンドウ１１２ａ〜１１２ｆには、出発セグメント１１６ａ〜１１６ｆと帰路セグメントセグメント１１８ａ〜１１８ｆとを含む旅行オプションが入っているが、ただし、カテゴリ・ウィンドウ１１２ａ〜１１２ｆ内には、他の数の旅行オプションおよび／またはセグメントを表示することもできる。例えば、本発明の実施形態では、１つ以上のセグメントを有する片道の旅行オプション、または１つ以上のセグメントをそれぞれ有する複数の旅行オプション、を表示することができる。

お薦め旅行オプション・セグメントウィンドウ１１６ａ〜１１６ｆ、１１８ａ〜１１８ｆには、航空会社１２４、出発地１２６、到着地１２８、飛行時間１３０、運賃タイプ１３２、予定乗り継ぎ地１３４など、対応する旅行オプションに関する情報が入る。

それぞれの価格／アベイラビリティ情報ウィンドウ１２０ａ〜１２０ｆには、旅行オプション価格１３６ａ〜１３６ｆと、その旅行オプションに関する顧客フィードバックに基づく星格付け１３８ａ〜１３８ｆと、１つ以上の緊迫度と、を含むことができる。緊迫度には、空席数を示すフラグ１４０ａ〜１４０ｆ、直近に座席が予約された時刻を示すフラグ１４２ａ〜１４２ｆ、および／またはその旅行オプションを予約した人数を示すフラグ１４４ａ〜１４４ｆ、を含むことができる。操作では、フライトの検索および／または予約を希望する顧客が、周知の方法でウェブブラウザを利用して旅行代理店のウェブサイトにログインするができる。旅行代理店のウェブサイトは、予約アプリケーション５６および／またはウェブサーバ・アプリケーション（図示せず）など、１つ以上のアプリケーションを含み得るユーザ・プラットフォーム１４をホストとすることができる。顧客は、希望の出発地および目的地と移動時間を、ウェブブラウザを介して入力することができる。予約アプリケーション５６は、入力された情報を受け取って、それに基づく検索要求をＴＯＳＳ ６０に対して発行することができる。本発明の別の実施形態では、顧客は、ＴＯＳＳプラットフォーム１２またはＴＯＳＳ ６０のオペレータが所有する別のプラットフォームをホストとするウェブサーバ・アプリケーションもしくは予約アプリケーションにログインすることができる。ＴＯＳＳ ６０は、旅行オプション検索パラメータを受け取ると、これに応えて、入力された情報とマッチする旅行オプションを求めてデータベースを検索することができる。その後、検索結果は、図２５および２６に関して前述したようにランク付けされ得る。ＴＯＳＳ ６０は、次に、１つ以上の一次検索ランク付けカテゴリに分けたお薦め結果を、要求元アプリケーションに提供することができる。その後、要求元アプリケーションによって、それらの結果を、図２７に関して説明したようなお薦め結果ページとして表示することができる。

要するに、事前計算済みデータベースクエリ結果を処理、返送、および表示する方法は、以下の点を特徴とすることができる。

１．方法は、
検索クエリの検索条件に基づいて、旅行オプション・データベースから複数の旅行オプションを取得することと、
旅行オプションを、少なくとも１つのカテゴリによって分類することと、
各カテゴリの旅行オプションをランク付けすることと、
各カテゴリごとに、ランク付けされた旅行オプションのうち少なくとも１つを、顧客に表示するために提供することと、を含む。

２．特徴点１の方法は、さらに、
上記少なくとも１つの旅行オプションについて、緊迫インジケータを決定することと、
緊迫インジケータを、ランク付けされた旅行オプションのうちの上記少なくとも１つに関連付けて表示するために提供することと、を含む。

３．特徴点２の方法において、緊迫インジケータは、定性的フラグを有する。

４．特徴点２の方法において、緊迫インジケータは、数値を含む定量的フラグを有する。

５．特徴点１の方法において、カテゴリは、旅行オプションの各々の所要時間、旅行オプションの各々の人気度、旅行オプションの各々に関連する限定オファーがあること、旅行オプションの各々の費用、旅行オプションの各々が直近に予約された時刻、または旅行オプションの各々に関連するスポンサーシップ、である。

６．特徴点１の方法において、旅行オプションの各々の所要時間、旅行オプションの各々の人気度、旅行オプションの各々の費用、または旅行オプションの各々が直近に予約された時刻に基づいて、旅行オプションは、ランク付けされる。

７．コンピュータプログラムプロダクトは、
非一時的なコンピュータ可読記憶媒体と、
そのコンピュータ可読記憶媒体に格納されたプログラム命令であって、プロセッサで実行されることで、特徴点１の方法をプロセッサに実行させるプログラム命令と、を備える。

８．コンピュータデバイスは、
プロセッサと、
プロセッサで実行されることで、特徴点１の方法を当該コンピュータデバイスに実行させる命令を含むメモリと、を備える。

９．本明細書で概ね記載および図示するようなシステム、方法、およびコンピュータプログラムプロダクト。

最後に、図２８は、図１で示すような計算プラットフォーム２、検索プラットフォーム３、および／または再計算トリガ・プラットフォーム４、またはそれらの（例えば、大規模マスタ２０もしくは大規模ワーカ２２のような）モジュールの少なくとも一部、またはシステム全体（すべてのプラットフォームが１つのアーキテクチャ・エンティティに統合される場合）の機能を提供するコンピュータシステムの概略図である。コンピュータシステム内において、コンピュータシステムに本明細書で解説した方法のいずれかを実施させるための命令のセットを、実行することができる。コンピュータシステムは、プロセッサ１８１と、メインメモリ１８２と、ネットワークインタフェース装置１８３と、を備え、これらは、バス１８４を介して相互に通信する。オプションとして、さらに、スタティックメモリ１８５、およびディスクドライブユニット１８６を備えることができる。ビデオディスプレイ１８７、英数字入力装置１８８、およびカーソル制御装置１８９によって、配信リスト・ナビゲータのユーザインタフェースを構成することができる。ネットワークインタフェース装置１８３は、例えば、再計算トリガ・プラットフォーム４を計算プラットフォーム２に、または検索プラットフォーム３を計算プラットフォーム２に、（それらのプラットフォームが異なるホストで実現されている場合に）接続するなどし、予測モデルに代入するために必要な統計データのソースである統計サーバ９など、変更度データベース１０、および初期正確度データベース１１、リアルタイムイベントのソース、インターネットおよび／または他の任意のネットワークに接続する。上述の方法の一部またはすべてを具現化する命令のセット（すなわち、ソフトウェア）１９０は、完全に、または少なくとも部分的に、例えばメインメモリ１８２および／またはプロセッサ１８１である機械可読媒体上に常駐する。また、ソフトウェア１９０が常駐する機械可読媒体は、ディスクドライブユニット１８６の一部である（例えば、固定型磁気ハードディスク、またはリムーバブルな光もしくは磁気ディスクなどの）不揮発性データ記憶媒体１９１とすることもできる。ソフトウェア１９０は、さらに、ネットワークインタフェース装置１８３を通して、インターネットを介して伝搬される信号１９２として送信または受信され得る。

本開示の範囲から逸脱することなく、上記に対して変更および変形を実施することができることは、理解されるであろう。言うまでもなく、ローカルかつ具体的な要件を満たすために、当業者は、数多くの変形および変更を上記ソリューションに適用することができる。特に、本開示は、その例を参照して、ある程度詳細に説明されたが、理解されるべきことは、形態および細部における様々な省略、置換、および変更が可能であり、さらには他の実施形態が可能であるということである。また、特に、本開示のいずれかの開示された実施形態に関連して記載された個々の要素および／または方法ステップは、一般的な設計選択事項として他の実施形態に組み込むことができるものとする。

同様の考え方が、（本開示の各実施形態を実現するために用いることができる）プログラムを異なる方法で構築する場合、または追加のモジュールもしくは機能を提供する場合に、適用される。同様に、メモリ構造は、他のタイプのものであってもよく、または等価なエンティティ（必ずしも物理記憶媒体で構成されるとは限らない）で置き換えることもできる。また、提案されたソリューションは、（異なる順序であっても、類似または追加のステップを有する）同等の方法で実現されるのに適する。いずれの場合も、プログラムは、外部もしくは常駐のソフトウェア、ファームウェア、またはマイクロコード（オブジェクトコードまたはソースコードのいずれか）など、データ処理システムによって用いるのに適した、またはデータ処理システムに関連して用いるのに適した、任意の形態をとることができる。また、プログラムは、コンピュータによる利用が可能な媒体上に提供することができ、その媒体は、プログラムを格納、記憶、伝達、伝搬、または転送するのに適した任意の要素とすることができる。そのような媒体の例は、（プログラムを予め組み込むことができる）固定ディスク、リムーバブルディスク、テープ、カード、ワイヤ、ファイバ、無線接続、ネットワーク、放送波などであり、例えば、媒体は、電子タイプ、磁気タイプ、光学タイプ、電磁タイプ、赤外線タイプ、または半導体タイプのものとすることができる。

いずれの場合も、本開示に係るソリューションは、（例えば、半導体材料のチップに組み込まれた）ハードウェア構造によって、またはソフトウェアとハードウェアの組み合わせによって、実施されるのに適する。

Claims (15)

1. 計算プラットフォーム（２）と検索プラットフォーム（３）とを備えるデータベースシステム（１）であって、再計算トリガ・プラットフォーム（４）をさらに備え、
   前記計算プラットフォーム（２）は、
   前記再計算トリガ・プラットフォーム（４）からバッチ再計算命令を受け取り、このとき、各バッチ再計算命令は、複数の事前計算済みデータベースクエリ結果の一部を再計算することを前記計算プラットフォーム（２）に指示するものであり、
   所与の時間枠内で、バッチ処理スケジュールに従って前記複数の事前計算済みデータベースクエリ結果の一部を再計算することにより、バッチ再計算命令を処理し、このとき、前記時間枠は、前記バッチ再計算命令において指示され、または前記計算プラットフォーム（２）によって自律的に決定され、または前記計算プラットフォーム（２）と前記再計算トリガ・プラットフォーム（４）との間でネゴシエーションされ、このとき、前記バッチ処理スケジュールは、前記バッチ再計算命令を解析した後、前記計算プラットフォーム（２）において利用できる計算リソースを考慮することによって、前記計算プラットフォーム（２）によって設定され、
   前記バッチ再計算命令の結果として得られた前記事前計算済みデータベースクエリ結果を、前記検索プラットフォーム（３）および前記再計算トリガ・プラットフォーム（４）の両方に返す、ように構成されており、
   前記検索プラットフォーム（３）は、
   前記複数の事前計算済みデータベースクエリ結果をメモリ（３０１）内に保持し、
   前記複数の事前計算済みデータベースクエリ結果を、前記検索プラットフォーム（３）に接続されたクライアントが利用できるようにする、ように構成されており、
   前記再計算トリガ・プラットフォーム（４）は、
   前記計算プラットフォーム（２）において利用できる計算リソースの情報を受信し、
   前記事前計算済みデータベースクエリ結果が失効している確率を決定するために、前記複数の事前計算済みデータベースクエリ結果の属性を含む制御データを保持し、
   他の複数の事前計算済みデータベースクエリ結果よりも失効している確率が高い複数の事前計算済みデータベースクエリ結果の一部についてのバッチ再計算命令を、前記計算プラットフォーム（２）に対して発行し、このとき、前記複数の事前計算済みデータベースクエリ結果の一部は、前記計算プラットフォーム（２）において利用できる計算リソースによって制限される、ように構成されている、データベースシステム（１）。
2. 前記バッチ再計算命令は、最大２４時間以内で少なくとも百万件のデータベースクエリ結果を計算することを、前記計算プラットフォーム（２）に指示する、請求項１に記載のデータベースシステム（１）。
3. 前記計算プラットフォーム（２）は、さらに、
   前記バッチ再計算命令を解析して、前記複数の事前計算済みデータベースクエリ結果の一部のうちのサブセットに関連する、より小さな計算パッケージに分解し、
   前記計算パッケージの計算を実行するために、前記計算パッケージを処理モジュールに割り当て、
   前記処理モジュールにより実行された前記計算パッケージの計算の結果を、再編成し、 前記再編成された結果を、前記検索プラットフォーム（３）および前記再計算トリガ・プラットフォーム（４）に返す、ように構成されている、請求項１または請求項２に記載のデータベースシステム（１）。
4. 前記バッチ再計算命令を解析および分解するための前記計算プラットフォーム（２）の構成は、
   前記バッチ再計算命令を、アトミック計算トランザクションに分割し、
   冗長アトミック計算トランザクションを識別して、それらを破棄し、
   残りの非冗長アトミック計算トランザクションをグループ化することで、前記計算パッケージを形成する、ための構成を含む、請求項３に記載のデータベースシステム（１）。
5. 前記計算プラットフォーム（２）は、前記バッチ処理スケジュールに従って、前記計算パッケージを前記処理モジュールに割り当てるように構成されており、このとき、前記バッチ処理スケジュールは、前記所与の時間枠内で利用できる前記処理モジュールの計算リソースを考慮することにより負荷分散を提供する、請求項３または請求項４に記載のデータベースシステム（１）。
6. 前記計算プラットフォーム（２）に接続された複数の検索プラットフォーム（３）を備え、前記再計算トリガ・プラットフォーム（４）は、前記計算プラットフォーム（２）に接続された前記複数の検索プラットフォーム（３）のいずれかにポピュレートする事前計算済みデータベースクエリ結果の再計算をトリガする、ように構成されている、請求項１から５のいずれか１つに記載のデータベースシステム（１）。
7. 前記再計算トリガ・プラットフォーム（４）は、さらに、前記事前計算済みデータベースクエリ結果が失効している確率を、確率モデルに基づくとともに非同期リアルタイムイベントの発生に応じて決定するように構成されており、前記確率モデルは、前記検索プラットフォーム（３）に保持されている前記事前計算済みデータベースクエリ結果と、推定される実際のデータベースクエリ結果と、の間の不一致をモデル化している、請求項１から６のいずれか１つに記載のデータベースシステム（１）。
8. 前記再計算トリガ・プラットフォーム（４）は、さらに、
   入来する非同期リアルタイムイベントが、確率モデルにおいて表現されているかどうか分析し、
   確率モデルで表現されていないリアルタイムイベントの場合に、前記複数の事前計算済みデータベースクエリ結果の一部についてのバッチ再計算命令を、できる限り迅速に発行し、
   確率モデルで表現されているリアルタイムイベントの場合に、そのようなリアルタイムイベントをある期間にわたって蓄積して、実際に発生した蓄積リアルタイムイベントを、確率モデルにおけるそれらの表現と比較し、実際に発生した蓄積リアルタイムイベントが、所定の程度まで、確率モデルにおけるそれらの表現から逸脱している場合に、前記複数の事前計算済みデータベースクエリ結果の一部についての前記バッチ再計算命令を、できる限り迅速に発行する、ように構成されている、請求項７に記載のデータベースシステム（１）。
9. 事前計算済みデータベースクエリ結果を再計算する方法であって、
   再計算トリガ・プラットフォーム（４）により、計算プラットフォーム（２）において利用できる計算リソースの情報を受信し、前記事前計算済みデータベースクエリ結果が失効している確率を決定するために、検索プラットフォーム（３）に保持されている複数の事前計算済みデータベースクエリ結果の属性を含む制御データを保持することと、
   前記再計算トリガ・プラットフォーム（４）により、他の複数の事前計算済みデータベースクエリ結果よりも失効している確率が高い複数の事前計算済みデータベースクエリ結果の一部についてのバッチ再計算命令を、前記計算プラットフォーム（２）に対して発行することであって、前記複数の事前計算済みデータベースクエリ結果の一部は、前記計算プラットフォーム（２）において利用できる計算リソースによって制限されることと、
   前記計算プラットフォーム（２）により、前記再計算トリガ・プラットフォーム（４）から前記バッチ再計算命令を受け取ることであって、前記バッチ再計算命令は、前記複数の事前計算済みデータベースクエリ結果の一部を計算することを前記計算プラットフォーム（２）に指示することと、
   前記計算プラットフォーム（２）によって、所与の時間枠内でバッチ処理スケジュールに従って前記複数の事前計算済みデータベースクエリ結果の一部を計算することにより、前記バッチ再計算命令を処理することであって、前記時間枠は、前記バッチ再計算命令において指示され、または計算プラットフォーム（２）によって自律的に決定され、または前記計算プラットフォーム（２）と前記再計算トリガ・プラットフォーム（４）との間でネゴシエーションされ、このとき、前記バッチ処理スケジュールは、前記バッチ再計算命令を解析した後、前記計算プラットフォーム（２）において利用できる計算リソースを考慮することによって、前記計算プラットフォーム（２）によって設定されることと、
   前記計算プラットフォーム（２）によって、前記バッチ再計算命令の結果として得られた事前計算済みデータベースクエリ結果を、前記検索プラットフォーム（３）および前記再計算トリガ・プラットフォーム（４）の両方に返すことと、
   前記検索プラットフォーム（３）によって、前記計算プラットフォーム（２）から受け取った前記事前計算済みデータベースクエリ結果をメモリ（３０１）内に保持することと、
   前記検索プラットフォーム（３）によって、前記事前計算済みデータベースクエリ結果を、前記検索プラットフォーム（３）に接続されたクライアントが利用できるようにすることと、を含む、方法。
10. 前記計算プラットフォーム（２）により、さらに、
    前記バッチ再計算命令を解析して、前記複数の事前計算済みデータベースクエリ結果のうちのサブセットに関連する、より小さな計算パッケージに分解することと、
    前記計算パッケージの計算を実行するために、前記計算パッケージを処理モジュールに割り当てることと、
    前記処理モジュールにより実行された前記計算パッケージの計算の結果を、再編成することと、
    前記再編成された結果を、前記検索プラットフォーム（３）および前記再計算トリガ・プラットフォーム（４）に返すことと、を含む、請求項９に記載の方法。
11. 前記計算プラットフォーム（２）により、前記バッチ再計算命令を解析および分解することは、さらに、
    前記バッチ再計算命令を、アトミック計算トランザクションに分割することと、
    冗長アトミック計算トランザクションを識別して、それらを破棄することと、
    残りの非冗長アトミック計算トランザクションをグループ化することで、前記計算パッケージを形成することと、を含む、請求項１０に記載の方法。
12. 前記計算プラットフォーム（２）は、さらに、前記バッチ処理スケジュールに従って、前記計算パッケージを前記処理モジュールに割り当て、このとき、前記バッチ処理スケジュールは、前記所与の時間枠内で利用できる前記処理モジュールの計算リソースを考慮することにより負荷分散を提供する、請求項１０または請求項１１に記載の方法。
13. 前記再計算トリガ・プラットフォーム（４）は、さらに、前記事前計算済みデータベースクエリ結果が失効している確率を、確率モデルに基づくとともに非同期リアルタイムイベントの発生に応じて決定し、前記確率モデルは、前記検索プラットフォーム（３）に保持されている前記事前計算済みデータベースクエリ結果と、推定される実際のデータベースクエリ結果と、の間の不一致をモデル化している、請求項９から１２のいずれか１つに記載の方法。
14. 前記再計算トリガ・プラットフォーム（４）により、さらに、
    入来する非同期リアルタイムイベントが、確率モデルにおいて表現されているかどうか分析することと、
    確率モデルで表現されていないリアルタイムイベントの場合に、前記複数の事前計算済みデータベースクエリ結果の一部についての再計算命令を、できる限り迅速に発行することと、
    確率モデルで表現されているリアルタイムイベントの場合に、そのようなリアルタイムイベントをある期間にわたって蓄積して、実際に発生した蓄積リアルタイムイベントを、確率モデルにおけるそれらの表現と比較し、実際に発生した蓄積リアルタイムイベントが、所定の程度まで、確率モデルにおけるそれらの表現から逸脱している場合に、前記複数の事前計算済みデータベースクエリ結果の一部についてのバッチ再計算命令を、できる限り迅速に発行することと、を含む、請求項１３に記載の方法。
15. 非一時的なコンピュータ可読記憶媒体であって、その中にコンピュータプログラム命令が格納されており、それがコンピュータシステム上で実行されることで、請求項１から８のいずれか１つに記載の計算プラットフォーム（２）、検索プラットフォーム（３）、および再計算トリガ・プラットフォーム（４）の構成を実現する、非一時的なコンピュータ可読記憶媒体。

Images