"ホテルの部屋の空き室状況を検索する方法であって、複数の滞在日数に関する、ホテルの部屋に関連付けられたリアルタイム空き室状況の属性を含む事前算出データベースを生成するステップと、ある日付範囲に対する、少なくとも1つのホテルに対するクエリを受信するステップであって、前記日付範囲は、開始日および終了日を有する、ステップと、前記クエリに従いビジネス要件を適用することによって、複数の滞在日数に関する前記日付範囲内の各日の空き室状況を計算するステップと、前記事前算出データベースからの前記空き室状況と前記クエリの属性とを組み合わせることによって、前記複数の滞在日数に関する前記日付範囲内の各日に対して、最終空き室状況を作成するステップと、前記複数の滞在日数に関する前記日付範囲内の各日に対して、前記少なくとも1つのホテルのための前記ホテルの部屋の最終空き室状況をフォーマットするステップとを含む、方法。前記滞在日数は、ビットマップによって表され、各ビットは、前記滞在日数内の日を表す、請求項1に記載の方法。前記クエリは、旅行ウェブサイトから受信される、請求項1に記載の方法。前記クエリは、クライアントから受信される、請求項1に記載の方法。前記計算するステップは、フェンスルールによって行われる、請求項1に記載の方法。前記計算するステップは、制限ルールによって行われる、請求項1に記載の方法。前記ホテルの部屋の最終空き室状況を旅行ウェブサイトに伝送するステップをさらに含む、請求項1に記載の方法。前記ホテルの部屋の最終空き室状況をクライアントに伝送するステップをさらに含む、請求項1に記載の方法。ホテルの部屋の空き室状況を検索するためのシステムであって、複数の滞在日数に関する、ホテルの部屋に関連付けられたリアルタイム空き室状況の属性を含む事前算出データベースを生成する手段と、ある日付範囲に対する、少なくとも1つのホテルに対するクエリを受信する手段であって、前記日付範囲は、開始日および終了日を有する、手段と、前記クエリに従いビジネス要件を適用することによって、複数の滞在日数に関する前記日付範囲内の各日の空き室状況を計算する手段と、前記事前算出データベースからの前記空き室状況と前記クエリの属性とを組み合わせることによって、前記複数の滞在日数に関する前記日付範囲内の各日に対して、最終空き室状況を作成する手段と、前記複数の滞在日数に関する前記日付範囲内の各日に対して、前記少なくとも1つのホテルのための前記ホテルの部屋の最終空き室状況をフォーマットする手段とを含む、システム。前記滞在日数は、ビットマップによって表され、各ビットは、前記滞在日数内の日を表す、請求項1に記載のシステム。前記クエリ手段は、旅行ウェブサイトから、前記クエリを受信する、請求項1に記載のシステム。前記クエリ手段は、クライアントから、前記クエリを受信する、請求項1に記載のシステム。前記計算する手段は、フェンスルールによって、前記計算を行う、請求項1に記載のシステム。前記計算する手段は、制限ルールによって、前記計算を行う、請求項1に記載のシステム。前記ホテルの部屋の最終空き室状況を旅行ウェブサイトに伝送する手段をさらに含む、請求項1に記載のシステム。前記ホテルの部屋の最終空き室状況をクライアントに伝送する手段をさらに含む、請求項1に記載のシステム。コンピュータ可読プログラムコードを内蔵しているコンピュータ使用可能媒体を含むコンピュータプログラム製品であって、前記コンピュータ可読プログラムコードは、ホテルの部屋の空き室状況を検索する方法を実装するために実行されるように適合されており、前記方法は、複数の滞在日数に関する、ホテルの部屋に関連付けられたリアルタイム空き室状況の属性を含む事前算出データベースを生成することと、ある日付範囲に対する、少なくとも1つのホテルに対するクエリを受信することであって、前記日付範囲は、開始日および終了日を有する、ことと、前記クエリに従いビジネス要件を適用することによって、複数の滞在日数に関する前記日付範囲内の各日の空き室状況を計算することと、前記事前算出データベースからの前記空き室状況と前記クエリの属性とを組み合わせることによって、前記複数の滞在日数に関する前記日付範囲内の各日に対して、最終空き室状況を作成することと、前記複数の滞在日数に関する前記日付範囲内の各日に対して、前記少なくとも1つのホテルのための前記ホテルの部屋の最終空き室状況をフォーマットすることとを含む、コンピュータプログラム製品。本方法およびシステムは、本明細書に含まれる好ましい実施形態および実施例の以下の発明を実施するための形態と、図ならびにその前述および後述の説明を参照することによって、より容易に理解されるであろう。本発明は、改良されたホテルの部屋の空き室状況トランザクションシステムを提供する。本明細書に組み込まれ、その一部を構成する、付随の図面は、実施形態を例証し、説明とともに、方法およびシステムの原理を説明する役割を果たす。本方法およびシステムが、開示および説明される前に、本明細書で使用される専門用語は、特定の実施形態を説明する目的のためだけにすぎず、限定を意図するものではないことを理解されたい。明細書および添付の請求項において使用されるように、単数形a、an、およびtheは、文脈において、別様に明示的に示されない限り、複数参照を含む。範囲は、本明細書では、約ある特定の値から、および/または約別の特定の値までとして、表現され得る。そのような範囲が表現される場合、実施形態は、例えば、ある特定の値から、および/または他の特定の値までのみを含み得る。同様に、値が、先行の約の使用によって、近似値として表現される場合、特定の値が、別の実施形態を形成することを理解されるであろう。さらに、範囲のそれぞれの端点は、他の端点に関連して、かつ他の端点から独立しての両方において、有意であることを理解されたい。随意のまたは随意にとは、続いて説明されるイベントまたは状況が、生じてもよく、またはそうでなくてもよく、説明が、イベントまたは状況が生じる事例およびそうではない事例を含むことを意味する。本明細書の説明および請求項を通して、用語comprise含むならびにcomprisingおよびcomprises等の用語の変化形は、あるものを含むが、それらに限定されないことを意味し、例えば、他の添加、コンポーネント、整数、またはステップを排除することを意図するものではない。例示的とは、あるものの実施例を意味し、好ましいまたは理想的実施形態の現れを伝えることを意図するものではない。Suchas等は、限定的意味で使用されるのではなく、説明目的のために使用される。開示されるのは、開示される方法およびシステムを行うために使用することができる、コンポーネントである。これらおよび他のコンポーネントが、本明細書に開示されるが、これらのコンポーネントの組み合わせ、サブセット、相互作用、グループ等が、開示される場合、これらの各種々の個々および集合的組み合わせならびに順列の特定の参照は、明示的に開示されない場合があるが、それぞれ、あらゆる方法およびシステムのために、具体的に企図され、本明細書に説明されることを理解されたい。これは、開示される方法におけるステップを含むが、それに限定されない、本願のあらゆる側面に適用される。したがって、行うことができる種々の付加的ステップが存在する場合、これらの付加的ステップはそれぞれ、開示される方法の任意の特定の実施形態または実施形態の組み合わせによって、行うことができることを理解されたい。図1Aは、最新のホテル予約システム、すなわち、その世界的ホテルチェーンのために、SixContinentsHotels,Inc.によって運営される、HOLBDEXHDXシステムのアーキテクチャを描写する。本発明は、本システムまたは市場で利用可能な任意の他の好適なホテル予約システムと併用され得る。図1Aの予約システムでは、HDXサーバ101は、ホテルの部屋に関する日付、料金、ならびに他の詳細情報によって現在の空き室状況を記憶する。種々のクライアント102a、102b、102c、および102dは、HDXサーバ101に要求を提出し得る。例えば、クライアント102aは、例えば、HDXサーバ101と通信するために、OTAまたはXMLプロトコルを使用して、中間データセンタ103を通して、HDXサーバ101に連結される、旅行ウェブサイトを備え得る。クライアント102bは、Sabre、Galileo、WorldSpan、Amadeus、またはTravelWeb等のグローバルディストリビューションシステムGDSを備え、例えば、HDXサーバ101と通信するために、Pegasusプロトコルを使用し得る。ホテルブランドの企業所有者は、例えば、3270またはXMLプロトコルを介して、クライアント102cを経由して、HDXサーバと通信し得る。最後に、個々のホテル102dは、例えば、XMLおよび/またはHMIプロトコルを使用して、HDXサーバ101と通信し得る。クライアント102a、102b、102c、および/または102dによってHDXサーバ101に提出された空き室状況検索要求は、最小限として、ホテルコード、チェックイン日、およびチェックアウト日を含み得る。複数のホテル、複数のデータ範囲等の検索は、通常、HDXサーバ101において、複数の検索の必要性をもたらし得るため、本発明は、さらに後述されるように、検索を行うための改良された方法を提供する。あらゆる主要データセンタ内の今日の環境すなわち、ハードウェアおよびネットワークにおける最大の課題は、毎年、60もの空き室状況トラフィックの驚異的な成長である。最も効率的検索プロセスは、事前算出データと現状データとの間の微妙なバランスである。数百万の検索要求が、毎日、予約システムにヒットする場合、空き室状況データの一部をすでに算出しておくことを節約することは、高性能空き室状況トランザクションシステムにつながる。HDXサーバ101上で、最も効率的に検索を行う方法を決定するために、空き室状況プロセスは、種々の基準に基づいて、各ステップをカテゴリ化するようにトークン化される。カテゴリ化は、多くの形態をとり得るが、一実施形態では、表Aの以下の基準が、使用され得る。図1Bに描写されるように、本発明は、事前計算空き室状況データベース151、ならびに空き室状況ルール計算機エンジン152を含む。一実施形態では、事前計算空き室状況データベース151は、2つの主要特性を有する、関連データベースを備え得る。各行は、1日の最低可能販売可能単位製品アイテムを表す。1日あたりの一式の製品アイテムを見つけるための発見プロセスは、必要とされない。1日あたりの各製品アイテムは、クラスおよび日付範囲空き室状況によって、関連付けられる部屋タイプの料金コード定義を使用する高レベル料金カテゴリから導出され得る。表のサイズは、管理可能であるべきである。表は、高速で更新され、そこから読み取られる。各製品アイテムのための要素の数は、各行において事前計算するための最小数の要素を維持するために、非常に選択的である。データベース一次キーは、ホテルコード、日付、部屋タイプ、および料金カテゴリによって、形成され得る。各行の他のキーデータは、一実施形態では、以下であり得る。物理的滞在日数LOS。本文字列値は、最大、例えば、14日の滞在任意の他の最大LOSも、同様に、選択され得るの各晩に対するビットマスクを表す。部屋タイプの物理的空き室状況は、割当、総部屋数、および部屋指定なしの部屋タイプの概念を使用し得る。これらのルールは、LOSマスクの各晩に対して、反復して適用され得る。料金。料金は、製品アイテムの料金カテゴリに関連付けられた料金コードから、導出され得る。金額は、均一金額または値であり得る。同時に、金額は、料金コードレベルまたは別のベースの料金コードから見つけられ得る。収益LOS。この文字列値は、最大、例えば、14日の滞在または、任意の他の最大LOSの各晩に対するビットマスクを表す。収率管理コンポーネントは、LOSに基づいて、純収益計算を使用し得る。プラスの収益は、オープン1で表されてもよく、マイナスの収益は、クローズ0で表され得る。他の料金または手数料に基づいて、別の値を使用するために示し得る、いくつかの収率選択肢が存在し得る。これらのルールは、LOSマスクの各晩に反復して適用され得る。料金コード。等価概念は、全料金コード間の関係のレベルを維持するための料金コードを使用し得る。本関連データベースのレイアウトは、製品アイテムをフェッチするための非常に高速な方法をもたらす。本初期段階において、フィルタを実装するために、事前算出空き室状況データベース151を属性テーブルと結合可能である。ベッドタイプ、ベッド数、および/または最大占有率等の属性のいくつかは、一実施形態では、製品アイテムの事前選択を支援し得る。これは、非適格製品アイテムにおける余剰処理サイクルにつながる、空き室状況プロセスの終了時に、フィルタを適用する、現在の技術と異なる。LOSによってもたらされる値は、ビットマスク表現を使用し得る。各ビットは、夜を表し、値は、オープン1またはクローズ0であり得る。LOSが表され得る長さに制限はない。適正な値は、適正な対象ユーザまたはホテルブランドに対応し得る。例えば、一実施形態では、長期滞在型ブランドは、最大28日以上のLOSを事前に計算させ得る。図2に示されるように、一実施形態では、空き室状況ルール計算機エンジン151および事前計算空き室状況データベース152は、WebSphereMQ202からのメッセージを実行し、メッセージを処理し、Oracleデータベース203を必要とされるデータで更新する、J2EEアプリケーション201を含む、事前計算フレームワークを備え得る。フレームワークは、コアJava登録商標アプリケーション204を含み得る、J2EEアプリケーション201を備え得る。図2は、本発明の一実施形態による、アプリケーションのそれぞれ内の主要コンポーネントを伴う、全体的フレームワークを描写する。他の好適なフレームワークも、同様に、使用され得る。図3は、図1Bおよび2の事前計算エンジン内のメッセージ処理の一般的フローを描写する、概略シーケンス図である。本シーケンス図は、メッセージが、順に到着し、直ちに処理される時のシナリオを示す。図4は、一実施形態における、本発明の全体的フローを描写する、フレームワークアーキテクチャフロー図である。図2-4のアーキテクチャコンポーネントは、さらに詳細に後述される。事前計算MDビーン211-事前計算MDビーン211は、HOLIDEX101からメッセージを受信する、MQシリーズ202キュー411をリッスンする、メッセージ駆動型ビーンである。HOLIDEX101から受信したXMLメッセージによって、メッセージマネージャ214を呼び出す。ステートレスセッションビーン212:後続のステートレスセッションビーン212が使用され得る。ブートストラップビーン:アプリケーションを初期化するために使用される。Log4jおよび他のタイマタスク指向ビーンは、アプリケーションがスタートアップするときに、ここで、初期化される。メッセージマネージャビーン:本EJBは、あらゆるソースおよびクライアントのためのメッセージを処理するために使用される。基本的に、メッセージマネージャ214を呼び出すか、またはそれを拡張することができる。また、本ビーンは、MDB211によって呼び出すことができる。タイマビーン231-本EJBは、タイマサービスを使用する。本EJBは、係属のメッセージテーブル内で係属中のメッセージを処理するために使用される。本EJBは、所定の時間で稼働し、メッセージマネージャを呼び出し、係属中のメッセージを有する任意のホテルをロックし、メッセージを処理する。Holidexからのイベントを連続的に処理することが重要である。クラスタ環境すなわち、異なるノードが、同時に、同一ホテルに対して更新することができるの実装は、本更新処理の方法を必要とする。メトリクスマネージャ232-本ステートレスセッションビーンは、タイマサービスを使用して、所定の時間例えば、1時間毎にメトリクスを収集するために使用される。時限オブジェクトを実装する。本EJBは、ブートストラップビーンによって初期化され、タイマが、作成されるであろう。データクライアント233-データクライアントコンポーネントは、事前計算エンジンの内側にある、単一コンポーネントである。その役割は、2つから成る。1つ目は、プッシュクライアントの代わりに、製品アイテムが構築される方法に関する特定の情報を提供することである。2つ目は、それらのプッシュクライアントに変更が行われると、それを通知する手段を提供することである。ロギング234-Log4Jは、アプリケーションのためのロギング機構として使用されるであろう。ロギングされたメッセージは、アプリケーションサーバが稼働しているサーバ上のファイルに向けられるであろう。Log4jのための構成は、ブートストラップEJBを使用して、またはAppサーバ内のスタートアップクラスを使用して、ロードされるべきである。Debug、Info、Warn、およびErrorの異なるレベルのロギングが存在する。メッセージマネージャ214-メッセージマネージャ214は、主に、2つの動作を行い得る。第1に、XMLメッセージをJava登録商標オブジェクトに変換し、次いで、メッセージタイプに基づいて、特定の事前計算マネージャ216を呼び出し得る。また、ホテルコードおよびメッセージシーケンス番号に基づいて、メッセージの連続処理を管理する。メッセージが、順にではない場合、メッセージは、後の処理のために別個のテーブルに記憶されるであろう。マネージャファクトリ218-マネージャファクトリ218クラスは、メッセージタイプに基づいて、事前計算マネージャ216を動的に作成する。マネージャを作成すると、後の使用のために、キャッシュし得る。XMLスキーマJava登録商標クラス-これらのXMLスキーマJava登録商標クラスは、メッセージマネージャ214の一部であり、HOLIDEX101から受信したXMLメッセージに基づいて、生成され得る。これらのクラスは、その方法におけるXML要素および属性の値を保持する。これらのXMLビーンクラスは、データキャリアとして使用され、したがって、各メッセージのための別個の転送オブジェクトを回避する。事前計算マネージャ216-一実施形態では、各メッセージタイプまたはメッセージタイプの組み合わせのための別個の事前計算マネージャ216が存在するであろう。その基礎機能性は、いくつかのビジネスロジックおよび事前計算ユーティリティクラスを使用して、受信したJava登録商標オブジェクトを所望のデータベース関連フィールドに変換することである。ビジネス処理の大部分は、ここおよびユーティリティクラスにおいて発生する。ホテルロックユーティリティ220-本クラスは、ハウスメッセージテーブル内にホテルデータをロックするために使用される。メッセージは、記録がロックされると、そのホテルに対して処理される。メッセージを番号順に処理し、同一ホテルに対する他のメッセージとの競合条件を防止するために、ホテルをロックする必要がある。メッセージが、順番から外れて記録される場合、完全なデータベースを無効にするであろう。保留メッセージユーティリティ-本クラスは、係属メッセージテーブル内のメッセージの記憶、読み出し、および削除のために使用される。メッセージが、クラスタ環境を使用して、MQキューから読み取られると、メッセージを順に処理することが必要である。各ホテルメッセージは、順番の処理を維持するための連続番号を持っている。検証クラス222-一実施形態では、各メッセージに対して、別個の検証クラスが存在する。これらの検証クラスは、メッセージを検証し、エラーが見つけられる場合、事前計算例外を投入する。データアクセスオブジェクトDAO226-データアクセスオブジェクト226は、Oracleデータベース203に関連する通信およびCRUD動作を抽象化する。事前計算マネージャ216は、適切なDAO226を呼び出し、テーブルを更新する。DAO226は、単一テーブルに基づいて、または関連テーブルに基づき得る。基本的に、本DAO226は、DBコネクタクラス228からデータベース接続を取得し、データベースへのSQL呼び出しに備え、CRUD動作を行う。これらの動作が行われると、データベース203への接続を解除する。DBコネクタ228-DBコネクタ228は、データベース203のための接続機構を抽象化する、Java登録商標クラスである。一実施形態では、データソースオブジェクトを呼び出すことによって、データベース203への接続を取得するであろう。本クラスは、接続解除、トランザクションのロールバック等、種々の方法を有するであろう。事前計算ユーティリティコンポーネント-アプリケーションのために必要とされる全共通機能性は、アプリケーションによって必要とされるような日付検証または特定的なデータの変換等、ユーティリティクラスとして、開発され得る。メッセージタイプに特定のいくつかのユーティリティクラスが存在し得る。空き室状況ルール計算機エンジン152は、2つのカテゴリにグループ化されるロジックを含み得る。検索要求のチェックイン日値に基づき、したがって、事前に計算することができない、ビジネスロジック。そのようなロジックの実施例は、前払い購入制限であろう。処理時間において、低に等級分けされ表Aに関連して前述の基準に基づく、空き室状況の明確に定義された要素に関連付けられた、ビジネスロジック。全体的目標は、事前計算空き室状況データベース151と空き室状況ルール計算機エンジン152ロジックとの間の良好なバランスを開発することである。本バランスは、高性能を維持するように、動的に調節され得る。その場合、新しいロジックは、空き室状況モデルに追加され、これは、空き室状況の要素のいくつかにおけるスコアリングを修正し得、事前計算空き室状況データベース151と空き室状況ルール計算機エンジン152ロジックとの間に、新しいバランスすなわち、スイートスポットをもたらすであろう。空き室状況ルール計算機152は、空き室状況プロセスの現状ロジックを取り扱う。ビジネスルールは、異なるコンポーネントすなわち、空き室状況計算機に分離されてもよく、したがって、独立して実装することができる。各要求とリアルタイムで適用されることができる、いくつかのフェンスおよび制限が存在し得る。例えば、これらは、ホテルが、空き室状況を制御するために設定することができる、属性を表し得る。例えば、料金前払、宿泊数、最短/最長滞在日数、特殊要件である。他のフェンスおよび制限は、ホテルレベル、料金カテゴリレベル、および料金コードレベルにおいてのみ、見出され得る。ビジネスルールが適用される順序は、処理時間サイクルに直接影響を及ぼし得る。空き室状況ルール計算機エンジン152は、2つの主要コンポーネントを有し得る。製品アイテムコレクタ。空き室状況プロセスのオーケストレータ。適用されるであろう、ルールおよびルールの順序を指定するための収集選択肢を使用する。空き室状況ルール計算機。各計算機図5に関連して、さらに後述されるは、マスク計算機507インターフェースを実装し、コレクタが読み出すであろうgetMaskメソッドを提供しなければならない。返されたマスクは、ルールを適用するために、現在の製品アイテムLOSマスクに対して、他のマスクとともに論理積演算される。また、getReasonCodeを実行することによって、理由コードを供給しなければならない。一実施形態では、空き室状況ルール計算機エンジン152は、さらに詳細に後述されるように、構築および動作され得る。クラスモデル内部において、コレクタ502は、それぞれ、滞在日数LOSルールの特定のクラス専用のいくつかの計算機コンポーネント図6の507および601-606、さらに後述されると協働する。一般に、各計算機は、製品アイテムLOSマスクと論理積演算され、全体的LOSマスクを導出する、ビットマスクを返す。収集コンテキスト収集コンテキストオブジェクト503は、収集サイクルに関する大域状態を保持するために使用される。呼び出し元が、コレクタ502にcollectを起動すると製品アイテムコレクタインターフェース504を介して、コレクタ502は、収集コンテキストオブジェクト503を作成するであろう。収集コンテキスト503は、以下のプロパティを有し得る。ホテルコード料金カテゴリコード日付データベースオブジェクト収集選択肢キャッシュされたファクト収集コンテキスト503は、各計算機のためのコンストラクタにパスされる。コンストラクタは、各計算機の環境を初期化するが、それは、そのクラスのソフトウェアコンポーネントである。計算機は、収集コンテキスト503を使用して、データベース203を取得し、CRSテーブルにクエリする。また、コンテキストオブジェクトを通して、相互に、ファクトを共有するためにも使用する。例えば、ホテルが、HIROHotelであることが発見される場合、そのファクトは、2つ以上の計算機に重要となり得る。計算機計算機601-606は、PACEエンジンのためのキービジネスロジックコンポーネントである。収集ストラテジ505は、収集選択肢506に指定されたものに基づいて、どの計算機を使用するかを決定する。各計算機は、マスク計算機507インターフェースを実装し、コレクタ502が読み出すであろう、getMaskメソッドを提供することができる。返されたマスクは、ルールを適用するために、現在の製品アイテムLOSマスクに対して、他のマスクとともに、論理積演算される。理由コードはまた、例えば、getReasonCodeを実装することによって、供給され得る。マスク計算機507のためのサンプルインターフェースは、以下であり得る。publicinterfaceMaskCalculator{intgetMaskProductItempithrowsServiceException;intgetReasonCode;}任意の数のマスク計算機507が存在し得る。図6は、現在のセットに対する例示的UMLを描写する。一実施形態では、計算機は、例えば、以下等のIHG空き室状況モデルの非常に特定的なフェンスルールまたは制限ルールを持つ。到着計算機601-要求のチェックイン日を使用して、除外日または到着不許可が、ホテルまたは料金カテゴリレベルに設定されているかどうか検証する。最短最長計算機602-チェックイン日およびチェックアウト日を使用して、LOSを導出する。LOS値は、該当する場合、最短および最長滞在日数制限を満たすべきである。収益計算機603-特定の料金に対するLOSが、プラスの収益をもたらすことを検証する。部屋SS計算機604-特定の部屋タイプが、ホテルの部屋の販売ストラテジに関連付けられていることを検証する。ホテルの部屋の販売ストラテジは、販売が確認できる部屋タイプを識別する。宿泊日数計算機605-チェックイン日およびチェックアウト日を使用して、LOSを導出する。LOS値は、宿泊を必要とする曜日を満たすべきである。アクティブ日数計算機606-チェックイン日およびチェックアウト日を使用して、LOSを導出する。LOS値は、アクティブとフラグが付けられている曜日を満たすべきである。ホテルルールキャッシュPACEエンジンを可能な限り効率的にすることが有利である。図5および6を参照すると、CRSデータベース内にエンコードされたホテルルールを含むので、このほとんどが、マスク計算機507の実装に依存し得る。PACEエンジンが、新しいマスク計算機507を構築する度に、計算機507は、データベース203から1回だけ、必要とするデータを事前にフェッチし、次いで、そのgetMaskメソッドの各起動に対して、反復してそれを使用することによって、自己最適化することができる。たとえそうであっても、計算機のすべてに、変更が稀であるルールに関して、データベースにクエリさせることは、性能に有意な打撃を及ぼし、回避されるべきである。これに対処するために、収集コンテキストオブジェクト503図5は、マスク計算機507の代わりに、ルールをキャッシュするためのサポートを含み得る。マスク計算機507が、データベース203から、そのルールを構築すると、それらを収集コンテキスト503上にキャッシュすることができる。これは、ひいては、すべてのマスク計算機507が、最初に、データベース203をヒットする前に、必要とするルールが、依然として、存在するかどうか確認し、ルールを再構成することができることを意味する。本モデルは、性能の向上に寄与し、したがって、可能である場合、常時、使用することができる。以下は、ルールをキャッシュするためのメソッドがどのようなものであるかを示す。publicclassCollectionContext{publicObjectgetHotelRulesMaskCalculatorc;publicvoidputHotelRulesMaskCalculatorc,Objectrules;}マスク計算機507が、ルールをキャッシュすると、ルールは、以下のイベントのうちの1つが生じるまで、メモリ内に残留し得る。データベース203内のホテルルール変更LRUキャッシュが、リソース管理のために、ホテルルールをパージするアプリケーションが再開される一実施形態では、マスク計算機507は、キャッシュメソッドを使用し、信頼性があることを仮定するためのあらゆる努力をし得る。キャッシュ変更管理のための好適なソリューションが利用可能ではない場合、PACEエンジンは、キャッシュがアクティブ化されないよう確実にし得る。依然として、マスク計算機507は、常時、キャッシュがアクティブと仮定し得る。収集ストラテジPACEエンジンは、異なる目的のために利用することができるので、あらゆる場合に対する単一の検索アルゴリズムは、適切ではない。例えば、プルアプリケーションからの空き室状況要求は、最初に、より高いレベルの制限を、最後に、製品アイテムを検討し得る一方、プッシュアプリケーションは、製品アイテムを最初に検討し、可能な最も効率的順序でルールを適用することを所望し得る。これに対処するために、PACEエンジンは、収集ストラテジ505インターフェースを使用して、収集が実際に行われる方法を表し得る。これは、基本的には、当業者に周知の抽象アルゴリズム設計パターンの実装である。ストラテジの選択は、収集選択肢506内の設定に基づき得る。収集ストラテジ505のためのサンプルインターフェースは、以下に提供される。publicinterfaceCollectionStrategy{voidcollectCollectionContetctx,ProductItemConsumerconsumerthrowsServiceException;}一実施形態では、サポートされる収集ストラテジ505は、以下を含み得る。クエリPACEエンジンが起動されると、最終的には、製品アイテムテーブルから製品アイテムを読み取り、マスク計算機507を適用し、最終LOSを導出し得る。製品アイテムを選択するために使用されるクエリは、いくつかの要因を考慮し得る。これらとして、以下が挙げられる。選択基準LOS履歴販売除外以下のセクションは、クエリのためのこれらの側面をより詳細に説明する。基礎クエリLOS履歴販売除外1基礎クエリ基礎クエリは、製品アイテムを選択する、SQLの最も単純な形態を表す。実際、これは、使用される実際のSQLではなくてもよい。しかしながら、他の完全形成クエリのための基線としての役割を果たし得るため、説明される。言い換えると、完全クエリを理解するために、基礎クエリの理解が重要である。基礎クエリのための基準は、以下を含む。ホテルコード日付範囲料金カテゴリコード有効ステータス変更トークン随意除外部屋コード随意製品アイテムID随意有効ステータスは、単に、無効製品アイテム行をスキップすることを意味する。変更トークンは、指定値以上のトークン値を伴う行を選択するために使用される。除外される部屋タイプは、場外された部屋を除くために使用される。最後に、製品アイテムIDのリストは、製品アイテムのより精密な選択のために、変更トークンの代わりに、含むことができる。トークン値および製品アイテムIDは、実際には、事前計算によって修正されている、それらの製品アイテムのみ通すことを支援するために使用される。製品アイテムが、事前計算のために、変化する時および理由を最良に示すために使用することができる、種々の方法が存在するが、トークン番号製品アイテムIDが、一実施形態では、使用され得る。製品アイテムが、製品アイテムコンシューマに送達される順序は、2つの理由から重要である。1つ目は、コンテキスト切替に関して、計算機507を効率的にさせるからである。2つ目は、製品アイテムコンシューマが、構築している結果を容易に編成可能であるからである。この目的を達成するために、結果は、以下のように順序付けられ得る。日付料金カテゴリコード部屋コード前述の教示に基づき、図7を参照すると、一実施形態では、本発明は、したがって、以下のステップを行い得る。複数の滞在日数に関する、ホテルの部屋に関連付けられたリアルタイム空き室状況の属性を含む事前算出データベースを生成するステップステップ701と、ある日付範囲に対する、少なくとも1つのホテルに対するクエリを受信するステップであって、日付範囲は、開始日および終了日を有する、ステップステップ702と、クエリに従いビジネス要件を適用することによって、複数の滞在日数に関する日付範囲内の各日の空き室状況を計算するステップステップ703と、事前算出データベースからの空き室状況とクエリの属性とを組み合わせることによって、複数の滞在日数に関しする日付範囲内の各日に対して、最終空き室状況を作成するステップステップ704と、複数の滞在日数に関する日付範囲内の各日に対して、少なくとも1つのホテルのためのホテルの部屋の最終空き室状況をフォーマットするステップステップ705。方法およびシステムが、好ましい実施形態および特定の実施例と併せて説明されたが、その範囲が、記載の特定の実施形態に限定されることを意図するものではなく、本明細書の実施形態は、あらゆる観点において、制限ではなく、例証であることが意図される。別様に明示的に記載されない限り、本明細書に記載の任意の方法は、そのステップが、特定の順序で行われることを必要とするものと解釈されるように意図されない。故に、方法請求項が、実際には、そのステップによって追随される順序を列挙していない、またはステップが特定の順序に限定されることが、請求項または説明に別様に特定的に記載されていない場合、いかなる観点においても、ある順序が暗示されることをいかようにも意図されない。これは、ステップまたは動作フローの配列に関するロジックの問題、文法構成または句読法から導出される単純な意味、明細書に説明される実施形態の数またはタイプを含む、いかなる可能性のある解釈のための黙示原則にも該当する。本発明の範囲または精神から逸脱することなく、種々の修正および変形を行うことができることは、当業者に明白である。他の実施形態は、明細書および本明細書に開示される実践を検討することによって、当業者に明白となるであろう。明細書および実施例は、単なる例示として見なされ、真の範囲および精神は、以下の請求項によって示されることが意図される。"