JP2015111444A - ボトムアップ最適化検索システムおよび方法 - Google Patents

Abstract

【課題】ボトムアップ最適化検索システム及び方法を提供する。
【解決手段】ホテルの部屋を検索するためのシステム及び方法であって、複数の滞在日数に関する、ホテルの部屋に関連付けられたリアルタイム空き室状況の属性を含む事前算出データベースが生成され、日付範囲に対する、少なくとも１つのホテルに対するクエリが受信される。複数の滞在日数に関する日付範囲内の各日の空き室状況は、クエリに従いビジネス要件を適用することによって、計算される。最終空き室状況は、事前算出データベースからの空き室状況とクエリの属性とを組み合わせることによって、複数の滞在日数に関する日付範囲内の各日に対して作成される。ホテルの部屋の最終空き室状況は、複数の滞在日数に関する日付範囲内の各日に対して、少なくとも１つのホテルのためにフォーマットされる。
【選択図】図１Ａ

Description

既存のホテルおよび旅行用コンピュータ化予約システムは、トップダウン式検索アプローチを使用し、検索要求から発見されるのに伴って、単一空き室状況セルを作成する。例えば、そのようなシステムによって、ユーザは、ホテルの識別、チェックイン日、およびチェックアウト日等、検索基準を入力し、選択された宿泊日数（すなわち、単一滞在日数）に対して、利用可能なホテルの部屋を発見することが可能となる。製品アイテム（すなわち、ホテルの部屋）が見つかった後のみ、ビジネスロジックが、特定の一式の製品アイテムに対する料金および空き室状況を見出すように適用される。

本従来技術アプローチは、いくつかの不利点を有する。本アプローチのトップダウン式性質のため、製品アイテム（例えば、販売可能な部屋）は、各要求に対して、検察および発見される必要がある。さらに、検索要求は、最小限として、ホテル名／コード、チェックイン日、およびチェックアウト日を有していなければならない。空き室状況要求は、これらの最小要素が、要求内に存在しない場合、拒否されるであろう。

さらに、従来技術アプローチのコアサービスは、１度に１つのホテルのみ確認可能であって、チェックインおよびチェックアウト日が、検索内で使用されていることを前提として、料金および空き室状況応答が、特定の宿泊日数のみを反映する。基礎検索は、代替日付の使用を許さず、したがって、代替料金は発見されない。

都市検索が行われる場合（すなわち、ある都市に焦点を当てる検索）、本要求は、単一ホテルに対する複数の検索に分割され、各そのようなコアホテル検索が、１度に１つずつ行われる。コア検索サービスは、複数のホテル間の関係を認識しない。各コア要求は、１度に１つのホテルずつ行われるので、各要求は、料金および空き室状況を見つけるために行われる、複雑なビジネスルールを必要とするＣＰＵ時間およびリソースのコストが、高い。加えて、各要求のＣＰＵおよびリソース集約的性質を前提として、応答時間は、比較的に遅くなり得る。各要求に対して、料金および空き室状況ルールを発見および算出する必要性は、時間がかかる。

また、従来技術システムでは、要求は、非常にユーザ特定的であって、トランザクションシステムが異なる部屋タイプ等、代替タイプの製品を発見するのを支援するのを許容しない。

恐らく、既存の技術の最大の不利点は、単一空き室状況セルである。単一空き室状況セルは、検索要求内に明確に定義された滞在日数（ＬＯＳ）から導出される。ＬＯＳは、検索要求内の開始日および終了日から導入される。検索要求内のＬＯＳから導出することができる、複数の可能性のある組み合わせに対して、可視性は存在しない。例えば、要求者が、ＬＯＳに関して、異なる選択肢も評価することを所望する場合、各ＬＯＳ選択肢に対して、いくつかの別個の検索要求を必要とするであろう。従来技術は、代替日付または製品アイテムの柔軟性を提供しない。完全なる柔軟性を伴う返信を構築するために必要とされるコストおよび時間は、現時点では、コスト効果的ではない。例えば、顧客が、５月の第１週目に対する空き室状況を確認することを所望する場合、４９個の別個の空き室状況の呼び出しが、必要とされるであろう。１週間の各日付に対して、７個の空き室状況を呼び出す（すなわち、７日×日付あたり７個のＬＯＳ値）。本トランザクションは、４８倍分（すなわち、１個の呼び出しと４９個の呼び出しの差）、コストを増加させ、非常に長い応答時間（すなわち、不快なユーザ経験）を顧客にもたらすであろう。

したがって、当技術分野において、さらに詳細に後述されるように、旅行およびホテルトランザクションシステムへの改良の必要性が存在する。

本方法およびシステムは、本明細書に含まれる好ましい実施形態および実施例の以下の発明を実施するための形態と、図ならびにその前述および後述の説明を参照することによって、より容易に理解されるであろう。

本発明は、改良されたホテルの部屋の空き室状況トランザクションシステムを提供する。
本発明は、例えば、以下を提供する。
（項目１）
ホテルの部屋の空き室状況を検索する方法であって、
複数の滞在日数に関する、ホテルの部屋に関連付けられたリアルタイム空き室状況の属性を含む事前算出データベースを生成するステップと、
ある日付範囲に対する、少なくとも１つのホテルに対するクエリを受信するステップであって、前記日付範囲は、開始日および終了日を有する、ステップと、
前記クエリに従いビジネス要件を適用することによって、複数の滞在日数に関する前記日付範囲内の各日の空き室状況を計算するステップと、
前記事前算出データベースからの前記空き室状況と前記クエリの属性とを組み合わせることによって、前記複数の滞在日数に関する前記日付範囲内の各日に対して、最終空き室状況を作成するステップと、
前記複数の滞在日数に関する前記日付範囲内の各日に対して、前記少なくとも１つのホテルのための前記ホテルの部屋の最終空き室状況をフォーマットするステップと
を含む、方法。
（項目２）
前記滞在日数は、ビットマップによって表され、各ビットは、前記滞在日数内の日を表す、項目１に記載の方法。
（項目３）
前記クエリは、旅行ウェブサイトから受信される、項目１に記載の方法。
（項目４）
前記クエリは、クライアントから受信される、項目１に記載の方法。
（項目５）
前記計算するステップは、フェンスルールによって行われる、項目１に記載の方法。
（項目６）
前記計算するステップは、制限ルールによって行われる、項目１に記載の方法。
（項目７）
前記ホテルの部屋の最終空き室状況を旅行ウェブサイトに伝送するステップをさらに含む、項目１に記載の方法。
（項目８）
前記ホテルの部屋の最終空き室状況をクライアントに伝送するステップをさらに含む、項目１に記載の方法。
（項目９）
ホテルの部屋の空き室状況を検索するためのシステムであって、
複数の滞在日数に関する、ホテルの部屋に関連付けられたリアルタイム空き室状況の属性を含む事前算出データベースを生成する手段と、
ある日付範囲に対する、少なくとも１つのホテルに対するクエリを受信する手段であって、前記日付範囲は、開始日および終了日を有する、手段と、
前記クエリに従いビジネス要件を適用することによって、複数の滞在日数に関する前記日付範囲内の各日の空き室状況を計算する手段と、
前記事前算出データベースからの前記空き室状況と前記クエリの属性とを組み合わせることによって、前記複数の滞在日数に関する前記日付範囲内の各日に対して、最終空き室状況を作成する手段と、
前記複数の滞在日数に関する前記日付範囲内の各日に対して、前記少なくとも１つのホテルのための前記ホテルの部屋の最終空き室状況をフォーマットする手段と
を含む、システム。
（項目１０）
前記滞在日数は、ビットマップによって表され、各ビットは、前記滞在日数内の日を表す、項目１に記載のシステム。
（項目１１）
前記クエリ手段は、旅行ウェブサイトから、前記クエリを受信する、項目１に記載のシステム。
（項目１２）
前記クエリ手段は、クライアントから、前記クエリを受信する、項目１に記載のシステム。
（項目１３）
前記計算する手段は、フェンスルールによって、前記計算を行う、項目１に記載のシステム。
（項目１４）
前記計算する手段は、制限ルールによって、前記計算を行う、項目１に記載のシステム。
（項目１５）
前記ホテルの部屋の最終空き室状況を旅行ウェブサイトに伝送する手段をさらに含む、項目１に記載のシステム。
（項目１６）
前記ホテルの部屋の最終空き室状況をクライアントに伝送する手段をさらに含む、項目１に記載のシステム。
（項目１７）
コンピュータ可読プログラムコードを内蔵しているコンピュータ使用可能媒体を含むコンピュータプログラム製品であって、前記コンピュータ可読プログラムコードは、ホテルの部屋の空き室状況を検索する方法を実装するために実行されるように適合されており、
前記方法は、
複数の滞在日数に関する、ホテルの部屋に関連付けられたリアルタイム空き室状況の属性を含む事前算出データベースを生成することと、
ある日付範囲に対する、少なくとも１つのホテルに対するクエリを受信することであって、前記日付範囲は、開始日および終了日を有する、ことと、
前記クエリに従いビジネス要件を適用することによって、複数の滞在日数に関する前記日付範囲内の各日の空き室状況を計算することと、
前記事前算出データベースからの前記空き室状況と前記クエリの属性とを組み合わせることによって、前記複数の滞在日数に関する前記日付範囲内の各日に対して、最終空き室状況を作成することと、
前記複数の滞在日数に関する前記日付範囲内の各日に対して、前記少なくとも１つのホテルのための前記ホテルの部屋の最終空き室状況をフォーマットすることと
を含む、
コンピュータプログラム製品。

本明細書に組み込まれ、その一部を構成する、付随の図面は、実施形態を例証し、説明とともに、方法およびシステムの原理を説明する役割を果たす。

図１Ａは、ホテル予約システムのアーキテクチャを描写する。 図１Ｂは、一実施形態における、本発明の基礎構築ブロックのアーキテクチャを描写する。 図２は、さらに別の実施形態における、本発明のアーキテクチャを描写する。 図３は、本発明、一実施形態における、本発明を描写する概略シーケンス図を描写する。 図４は、一実施形態における、本発明による使用のためのフレームワークアーキテクチャフロー図である。 図５は、一実施形態における、本発明によって使用され得る種々の計算機を描写する、略図である。 図６は、マスク計算機に対して使用され得るサンプルＵＭＬである。 図７は、本発明、一実施形態における、本発明によって行われ得るステップを描写する。

本方法およびシステムが、開示および説明される前に、本明細書で使用される専門用語は、特定の実施形態を説明する目的のためだけにすぎず、限定を意図するものではないことを理解されたい。

明細書および添付の請求項において使用されるように、単数形「ａ」、「ａｎ」、および「ｔｈｅ」は、文脈において、別様に明示的に示されない限り、複数参照を含む。範囲は、本明細書では、「約」ある特定の値から、および／または「約」別の特定の値までとして、表現され得る。そのような範囲が表現される場合、実施形態は、例えば、ある特定の値から、および／または他の特定の値までのみを含み得る。同様に、値が、先行の「約」の使用によって、近似値として表現される場合、特定の値が、別の実施形態を形成することを理解されるであろう。さらに、範囲のそれぞれの端点は、他の端点に関連して、かつ他の端点から独立しての両方において、有意であることを理解されたい。

「随意の」または「随意に」とは、続いて説明されるイベントまたは状況が、生じてもよく、またはそうでなくてもよく、説明が、イベントまたは状況が生じる事例およびそうではない事例を含むことを意味する。

本明細書の説明および請求項を通して、用語「ｃｏｍｐｒｉｓｅ（含む）」ならびに「ｃｏｍｐｒｉｓｉｎｇ」および「ｃｏｍｐｒｉｓｅｓ」等の用語の変化形は、「あるものを含むが、それらに限定されない」ことを意味し、例えば、他の添加、コンポーネント、整数、またはステップを排除することを意図するものではない。「例示的」とは、「あるものの実施例」を意味し、好ましいまたは理想的実施形態の現れを伝えることを意図するものではない。「Ｓｕｃｈ ａｓ（等）」は、限定的意味で使用されるのではなく、説明目的のために使用される。

開示されるのは、開示される方法およびシステムを行うために使用することができる、コンポーネントである。これらおよび他のコンポーネントが、本明細書に開示されるが、これらのコンポーネントの組み合わせ、サブセット、相互作用、グループ等が、開示される場合、これらの各種々の個々および集合的組み合わせならびに順列の特定の参照は、明示的に開示されない場合があるが、それぞれ、あらゆる方法およびシステムのために、具体的に企図され、本明細書に説明されることを理解されたい。これは、開示される方法におけるステップを含むが、それに限定されない、本願のあらゆる側面に適用される。したがって、行うことができる種々の付加的ステップが存在する場合、これらの付加的ステップはそれぞれ、開示される方法の任意の特定の実施形態または実施形態の組み合わせによって、行うことができることを理解されたい。

図１Ａは、最新のホテル予約システム、すなわち、その世界的ホテルチェーンのために、Ｓｉｘ Ｃｏｎｔｉｎｅｎｔｓ Ｈｏｔｅｌｓ， Ｉｎｃ．によって運営される、ＨＯＬＢＤＥＸ（ＨＤＸ）システムのアーキテクチャを描写する。本発明は、本システムまたは市場で利用可能な任意の他の好適なホテル予約システムと併用され得る。

図１Ａの予約システムでは、ＨＤＸサーバ１０１は、ホテルの部屋に関する日付、料金、ならびに他の詳細情報によって現在の空き室状況を記憶する。種々のクライアント１０２ａ、１０２ｂ、１０２ｃ、および１０２ｄは、ＨＤＸサーバ１０１に要求を提出し得る。例えば、クライアント１０２ａは、例えば、ＨＤＸサーバ１０１と通信するために、ＯＴＡまたはＸＭＬプロトコルを使用して、中間データセンタ１０３を通して、ＨＤＸサーバ１０１に連結される、旅行ウェブサイトを備え得る。クライアント１０２ｂは、Ｓａｂｒｅ、Ｇａｌｉｌｅｏ、ＷｏｒｌｄＳｐａｎ、Ａｍａｄｅｕｓ、またはＴｒａｖｅｌＷｅｂ等のグローバルディストリビューションシステム（ＧＤＳ）を備え、例えば、ＨＤＸサーバ１０１と通信するために、Ｐｅｇａｓｕｓプロトコルを使用し得る。ホテルブランドの企業所有者は、例えば、３２７０またはＸＭＬプロトコルを介して、クライアント１０２ｃを経由して、ＨＤＸサーバと通信し得る。最後に、個々のホテル１０２ｄは、例えば、ＸＭＬおよび／またはＨＭＩプロトコルを使用して、ＨＤＸサーバ１０１と通信し得る。

クライアント（１０２ａ、１０２ｂ、１０２ｃ、および／または１０２ｄ）によってＨＤＸサーバ１０１に提出された空き室状況検索要求は、最小限として、ホテルコード、チェックイン日、およびチェックアウト日を含み得る。複数のホテル、複数のデータ範囲等の検索は、通常、ＨＤＸサーバ１０１において、複数の検索の必要性をもたらし得るため、本発明は、さらに後述されるように、検索を行うための改良された方法を提供する。あらゆる主要データセンタ内の今日の環境（すなわち、ハードウェアおよびネットワーク）における最大の課題は、毎年、６０％もの空き室状況トラフィックの驚異的な成長である。最も効率的検索プロセスは、事前算出データと現状データとの間の微妙なバランスである。数百万の検索要求が、毎日、予約システムにヒットする場合、空き室状況データの一部をすでに算出しておくことを節約することは、高性能空き室状況トランザクションシステムにつながる。ＨＤＸサーバ１０１上で、最も効率的に検索を行う方法を決定するために、空き室状況プロセスは、種々の基準に基づいて、各ステップをカテゴリ化するようにトークン化される。カテゴリ化は、多くの形態をとり得るが、一実施形態では、表Ａの以下の基準が、使用され得る。

図１Ｂに描写されるように、本発明は、事前計算空き室状況データベース１５１、ならびに空き室状況ルール計算機エンジン１５２を含む。一実施形態では、事前計算空き室状況データベース１５１は、２つの主要特性を有する、関連データベースを備え得る。
・各行は、１日の最低可能販売可能単位（製品アイテム）を表す。１日あたりの一式の製品アイテムを見つけるための発見プロセスは、必要とされない。１日あたりの各製品アイテムは、クラスおよび日付範囲空き室状況によって、関連付けられる部屋タイプの料金コード定義を使用する高レベル料金カテゴリから導出され得る。
・表のサイズは、管理可能であるべきである。表は、高速で更新され、そこから読み取られる。各製品アイテムのための要素の数は、各行において事前計算するための最小数の要素を維持するために、非常に選択的である。

データベース一次キーは、ホテルコード、日付、部屋タイプ、および料金カテゴリによって、形成され得る。各行の他のキーデータは、一実施形態では、以下であり得る。
・物理的滞在日数（ＬＯＳ）。本文字列値は、最大、例えば、１４日の滞在（任意の他の最大ＬＯＳも、同様に、選択され得る）の各晩に対するビットマスクを表す。部屋タイプの物理的空き室状況は、割当、総部屋数、および部屋指定なしの部屋タイプの概念を使用し得る。これらのルールは、ＬＯＳマスクの各晩に対して、反復して適用され得る。
・料金。料金は、製品アイテムの料金カテゴリに関連付けられた料金コードから、導出され得る。金額は、均一金額または％値であり得る。同時に、金額は、料金コードレベルまたは別のベースの料金コードから見つけられ得る。
・収益ＬＯＳ。この文字列値は、最大、例えば、１４日の滞在（または、任意の他の最大ＬＯＳ）の各晩に対するビットマスクを表す。収率管理コンポーネントは、ＬＯＳに基づいて、純収益計算を使用し得る。プラスの収益は、オープン（１）で表されてもよく、マイナスの収益は、クローズ（０）で表され得る。他の料金または手数料に基づいて、別の値を使用するために示し得る、いくつかの収率選択肢が存在し得る。これらのルールは、ＬＯＳマスクの各晩に反復して適用され得る。
・料金コード。等価概念は、全料金コード間の関係のレベルを維持するための料金コードを使用し得る。

本関連データベースのレイアウトは、製品アイテムをフェッチするための非常に高速な方法をもたらす。本初期段階において、フィルタを実装するために、事前算出空き室状況データベース１５１を属性テーブルと結合可能である。ベッドタイプ、ベッド数、および／または最大占有率等の属性のいくつかは、一実施形態では、製品アイテムの事前選択を支援し得る。これは、非適格製品アイテムにおける余剰処理サイクルにつながる、空き室状況プロセスの終了時に、フィルタを適用する、現在の技術と異なる。

ＬＯＳによってもたらされる値は、ビットマスク表現を使用し得る。各ビットは、夜を表し、値は、オープン（１）またはクローズ（０）であり得る。ＬＯＳが表され得る長さに制限はない。適正な値は、適正な対象ユーザまたはホテルブランドに対応し得る。例えば、一実施形態では、長期滞在型ブランドは、最大２８日以上のＬＯＳを事前に計算させ得る。

図２に示されるように、一実施形態では、空き室状況ルール計算機エンジン１５１および事前計算空き室状況データベース１５２は、ＷｅｂＳｐｈｅｒｅＭＱ２０２からのメッセージを実行し、メッセージを処理し、Ｏｒａｃｌｅデータベース２０３を必要とされるデータで更新する、Ｊ２ＥＥアプリケーション２０１を含む、事前計算フレームワークを備え得る。フレームワークは、コアＪａｖａ（登録商標）アプリケーション２０４を含み得る、Ｊ２ＥＥアプリケーション２０１を備え得る。図２は、本発明の一実施形態による、アプリケーションのそれぞれ内の主要コンポーネントを伴う、全体的フレームワークを描写する。他の好適なフレームワークも、同様に、使用され得る。

図３は、図１Ｂおよび２の事前計算エンジン内のメッセージ処理の一般的フローを描写する、概略シーケンス図である。本シーケンス図は、メッセージが、順に到着し、直ちに処理される時のシナリオを示す。図４は、一実施形態における、本発明の全体的フローを描写する、フレームワークアーキテクチャフロー図である。

図２−４のアーキテクチャコンポーネントは、さらに詳細に後述される。
・事前計算ＭＤビーン２１１−事前計算ＭＤビーン２１１は、ＨＯＬＩＤＥＸ１０１からメッセージを受信する、ＭＱシリーズ２０２キュー４１１をリッスンする、メッセージ駆動型ビーンである。ＨＯＬＩＤＥＸ１０１から受信したＸＭＬメッセージによって、メッセージマネージャ２１４を呼び出す。
・ステートレスセッションビーン２１２：後続のステートレスセッションビーン２１２が使用され得る。
・ブートストラップビーン：アプリケーションを初期化するために使用される。Ｌｏｇ４ｊおよび他のタイマタスク指向ビーンは、アプリケーションがスタートアップするときに、ここで、初期化される。
・メッセージマネージャビーン：本ＥＪＢは、あらゆるソースおよびクライアントのためのメッセージを処理するために使用される。基本的に、メッセージマネージャ２１４を呼び出すか、またはそれを拡張することができる。また、本ビーンは、ＭＤＢ２１１によって呼び出すことができる。
・タイマビーン２３１−本ＥＪＢは、タイマサービスを使用する。本ＥＪＢは、係属のメッセージテーブル内で係属中のメッセージを処理するために使用される。本ＥＪＢは、所定の時間で稼働し、メッセージマネージャを呼び出し、係属中のメッセージを有する任意のホテルをロックし、メッセージを処理する。Ｈｏｌｉｄｅｘからのイベントを連続的に処理することが重要である。クラスタ環境（すなわち、異なるノードが、同時に、同一ホテルに対して更新することができる）の実装は、本更新処理の方法を必要とする。
・メトリクスマネージャ２３２−本ステートレスセッションビーンは、タイマサービスを使用して、所定の時間（例えば、１時間毎）にメトリクスを収集するために使用される。時限オブジェクトを実装する。本ＥＪＢは、ブートストラップビーンによって初期化され、タイマが、作成されるであろう。
・データクライアント２３３−データクライアントコンポーネントは、事前計算エンジンの内側にある、単一コンポーネントである。その役割は、２つから成る。１つ目は、プッシュクライアントの代わりに、製品アイテムが構築される方法に関する特定の情報を提供することである。２つ目は、それらのプッシュクライアントに変更が行われると、それを通知する手段を提供することである。
・ロギング２３４−Ｌｏｇ４Ｊは、アプリケーションのためのロギング機構として使用されるであろう。ロギングされたメッセージは、アプリケーションサーバが稼働しているサーバ上のファイルに向けられるであろう。Ｌｏｇ４ｊのための構成は、ブートストラップＥＪＢを使用して、またはＡｐｐサーバ内のスタートアップクラスを使用して、ロードされるべきである。Ｄｅｂｕｇ、Ｉｎｆｏ、Ｗａｒｎ、およびＥｒｒｏｒの異なるレベルのロギングが存在する。
・メッセージマネージャ２１４−メッセージマネージャ２１４は、主に、２つの動作を行い得る。第１に、ＸＭＬメッセージをＪａｖａ（登録商標）オブジェクトに変換し、次いで、メッセージタイプに基づいて、特定の事前計算マネージャ２１６を呼び出し得る。また、ホテルコードおよびメッセージシーケンス番号に基づいて、メッセージの連続処理を管理する。メッセージが、順にではない場合、メッセージは、後の処理のために別個のテーブルに記憶されるであろう。
・マネージャファクトリ２１８−マネージャファクトリ２１８クラスは、メッセージタイプに基づいて、事前計算マネージャ２１６を動的に作成する。マネージャを作成すると、後の使用のために、キャッシュし得る。
・ＸＭＬスキーマＪａｖａ（登録商標）クラス−これらのＸＭＬスキーマＪａｖａ（登録商標）クラスは、メッセージマネージャ２１４の一部であり、ＨＯＬＩＤＥＸ１０１から受信したＸＭＬメッセージに基づいて、生成され得る。これらのクラスは、その方法におけるＸＭＬ要素および属性の値を保持する。これらのＸＭＬビーンクラスは、データキャリアとして使用され、したがって、各メッセージのための別個の転送オブジェクトを回避する。
・事前計算マネージャ２１６−一実施形態では、各メッセージタイプまたはメッセージタイプの組み合わせのための別個の事前計算マネージャ２１６が存在するであろう。その基礎機能性は、いくつかのビジネスロジックおよび事前計算ユーティリティクラスを使用して、受信したＪａｖａ（登録商標）オブジェクトを所望のデータベース関連フィールドに変換することである。ビジネス処理の大部分は、ここおよびユーティリティクラスにおいて発生する。
・ホテルロックユーティリティ２２０−本クラスは、ハウスメッセージテーブル内にホテルデータをロックするために使用される。メッセージは、記録がロックされると、そのホテルに対して処理される。メッセージを番号順に処理し、同一ホテルに対する他のメッセージとの競合条件を防止するために、ホテルをロックする必要がある。メッセージが、順番から外れて記録される場合、完全なデータベースを無効にするであろう。
・保留メッセージユーティリティ−本クラスは、係属メッセージテーブル内のメッセージの記憶、読み出し、および削除のために使用される。メッセージが、クラスタ環境を使用して、ＭＱキューから読み取られると、メッセージを順に処理することが必要である。各ホテルメッセージは、順番の処理を維持するための連続番号を持っている。
・検証クラス２２２−一実施形態では、各メッセージに対して、別個の検証クラスが存在する。これらの検証クラスは、メッセージを検証し、エラーが見つけられる場合、事前計算例外を投入する。
・データアクセスオブジェクト（ＤＡＯ）２２６−データアクセスオブジェクト２２６は、Ｏｒａｃｌｅデータベース２０３に関連する通信およびＣＲＵＤ動作を抽象化する。事前計算マネージャ２１６は、適切なＤＡＯ２２６を呼び出し、テーブルを更新する。ＤＡＯ２２６は、単一テーブルに基づいて、または関連テーブルに基づき得る。基本的に、本ＤＡＯ２２６は、ＤＢコネクタクラス２２８からデータベース接続を取得し、データベースへのＳＱＬ呼び出しに備え、ＣＲＵＤ動作を行う。これらの動作が行われると、データベース２０３への接続を解除する。
・ＤＢコネクタ２２８−ＤＢコネクタ２２８は、データベース２０３のための接続機構を抽象化する、Ｊａｖａ（登録商標）クラスである。一実施形態では、データソースオブジェクトを呼び出すことによって、データベース２０３への接続を取得するであろう。本クラスは、接続解除、トランザクションのロールバック等、種々の方法を有するであろう。・事前計算ユーティリティコンポーネント−アプリケーションのために必要とされる全共通機能性は、アプリケーションによって必要とされるような日付検証または特定的なデータの変換等、ユーティリティクラスとして、開発され得る。メッセージタイプに特定のいくつかのユーティリティクラスが存在し得る。

空き室状況ルール計算機エンジン１５２は、２つのカテゴリにグループ化されるロジックを含み得る。
・検索要求のチェックイン日値に基づき、したがって、事前に計算することができない、ビジネスロジック。そのようなロジックの実施例は、前払い購入制限であろう。
・処理時間において、低に等級分けされ（表Ａに関連して前述の基準に基づく）、空き室状況の明確に定義された要素に関連付けられた、ビジネスロジック。

全体的目標は、事前計算空き室状況データベース１５１と空き室状況ルール計算機エンジン１５２ロジックとの間の良好なバランスを開発することである。本バランスは、高性能を維持するように、動的に調節され得る。その場合、新しいロジックは、空き室状況モデルに追加され、これは、空き室状況の要素のいくつかにおけるスコアリングを修正し得、事前計算空き室状況データベース１５１と空き室状況ルール計算機エンジン１５２ロジックとの間に、新しいバランス（すなわち、スイートスポット）をもたらすであろう。

空き室状況ルール計算機１５２は、空き室状況プロセスの「現状」ロジックを取り扱う。ビジネスルールは、異なるコンポーネント（すなわち、空き室状況計算機）に分離されてもよく、したがって、独立して実装することができる。各要求とリアルタイムで適用されることができる、いくつかのフェンスおよび制限が存在し得る。例えば、これらは、ホテルが、空き室状況を制御するために設定することができる、属性を表し得る。例えば、料金前払、宿泊数、最短／最長滞在日数、特殊要件である。他のフェンスおよび制限は、ホテルレベル、料金カテゴリレベル、および料金コードレベルにおいてのみ、見出され得る。ビジネスルールが適用される順序は、処理時間サイクルに直接影響を及ぼし得る。

空き室状況ルール計算機エンジン１５２は、２つの主要コンポーネントを有し得る。
・製品アイテムコレクタ。空き室状況プロセスのオーケストレータ。適用されるであろう、ルールおよびルールの順序を指定するための収集選択肢を使用する。
・空き室状況ルール計算機。各計算機（図５に関連して、さらに後述される）は、マスク計算機５０７インターフェースを実装し、コレクタが読み出すであろうｇｅｔＭａｓｋ（）メソッドを提供しなければならない。返されたマスクは、ルールを適用するために、現在の製品アイテムＬＯＳマスクに対して、他のマスクとともに論理積演算される。また、ｇｅｔＲｅａｓｏｎＣｏｄｅ（）を実行することによって、理由コードを供給しなければならない。

一実施形態では、空き室状況ルール計算機エンジン１５２は、さらに詳細に後述されるように、構築および動作され得る。

（クラスモデル）
内部において、コレクタ５０２は、それぞれ、滞在日数（ＬＯＳ）ルールの特定のクラス専用のいくつかの「計算機」コンポーネント（図６の５０７および６０１−６０６、さらに後述される）と協働する。一般に、各計算機は、製品アイテムＬＯＳマスクと論理積演算され、全体的ＬＯＳマスクを導出する、ビットマスクを返す。

（収集コンテキスト）
収集コンテキストオブジェクト５０３は、収集サイクルに関する大域状態を保持するために使用される。呼び出し元が、コレクタ５０２にｃｏｌｌｅｃｔ（）を起動すると（製品アイテムコレクタインターフェース５０４を介して）、コレクタ５０２は、収集コンテキストオブジェクト５０３を作成するであろう。収集コンテキスト５０３は、以下のプロパティを有し得る。
・ホテルコード
・料金カテゴリコード
・日付
・データベースオブジェクト
・収集選択肢
・キャッシュされたファクト
収集コンテキスト５０３は、各計算機のためのコンストラクタにパスされる。コンストラクタは、各計算機の環境を初期化するが、それは、そのクラスのソフトウェアコンポーネントである。計算機は、収集コンテキスト５０３を使用して、データベース２０３を取得し、ＣＲＳテーブルにクエリする。また、コンテキストオブジェクトを通して、相互に、ファクトを共有するためにも使用する。例えば、ホテルが、ＨＩＲＯ Ｈｏｔｅｌであることが発見される場合、そのファクトは、２つ以上の計算機に重要となり得る。

（計算機）
計算機（６０１−６０６）は、ＰＡＣＥエンジンのためのキービジネスロジックコンポーネントである。収集ストラテジ５０５は、収集選択肢５０６に指定されたものに基づいて、どの計算機を使用するかを決定する。各計算機は、マスク計算機５０７インターフェースを実装し、コレクタ５０２が読み出すであろう、ｇｅｔＭａｓｋ（）メソッドを提供することができる。返されたマスクは、ルールを適用するために、現在の製品アイテムＬＯＳマスクに対して、他のマスクとともに、論理積演算される。理由コードはまた、例えば、ｇｅｔＲｅａｓｏｎＣｏｄｅ（）を実装することによって、供給され得る。

マスク計算機５０７のためのサンプルインターフェースは、以下であり得る。
ｐｕｂｌｉｃ ｉｎｔｅｒｆａｃｅ ＭａｓｋＣａｌｃｕｌａｔｏｒ ｛
ｉｎｔ ｇｅｔＭａｓｋ（ＰｒｏｄｕｃｔＩｔｅｍ ｐｉ） ｔｈｒｏｗｓ ＳｅｒｖｉｃｅＥｘｃｅｐｔｉｏｎ；
ｉｎｔ ｇｅｔＲｅａｓｏｎＣｏｄｅ（）；
｝
任意の数のマスク計算機５０７が存在し得る。図６は、現在のセットに対する例示的ＵＭＬを描写する。一実施形態では、計算機は、例えば、以下等のＩＨＧ空き室状況モデルの非常に特定的なフェンスルールまたは制限ルールを持つ。
・到着計算機６０１−要求のチェックイン日を使用して、除外日または到着不許可が、ホテルまたは料金カテゴリレベルに設定されているかどうか検証する。
・最短最長計算機６０２−チェックイン日およびチェックアウト日を使用して、ＬＯＳを導出する。ＬＯＳ値は、該当する場合、最短および最長滞在日数制限を満たすべきである。
・収益計算機６０３−特定の料金に対するＬＯＳが、プラスの収益をもたらすことを検証する。
・部屋ＳＳ計算機６０４−特定の部屋タイプが、ホテルの部屋の販売ストラテジに関連付けられていることを検証する。ホテルの部屋の販売ストラテジは、販売が確認できる部屋タイプを識別する。
・宿泊日数計算機６０５−チェックイン日およびチェックアウト日を使用して、ＬＯＳを導出する。ＬＯＳ値は、宿泊を必要とする曜日を満たすべきである。
・アクティブ日数計算機６０６−チェックイン日およびチェックアウト日を使用して、ＬＯＳを導出する。ＬＯＳ値は、アクティブとフラグが付けられている曜日を満たすべきである。

（ホテルルールキャッシュ）
ＰＡＣＥエンジンを可能な限り効率的にすることが有利である。図５および６を参照すると、ＣＲＳデータベース内にエンコードされたホテルルールを含むので、このほとんどが、マスク計算機５０７の実装に依存し得る。ＰＡＣＥエンジンが、新しいマスク計算機５０７を構築する度に、計算機５０７は、データベース２０３から１回だけ、必要とするデータを事前にフェッチし、次いで、そのｇｅｔＭａｓｋ（）メソッドの各起動に対して、反復してそれを使用することによって、自己最適化することができる。たとえそうであっても、計算機のすべてに、変更が稀であるルールに関して、データベースにクエリさせることは、性能に有意な打撃を及ぼし、回避されるべきである。

これに対処するために、収集コンテキストオブジェクト５０３（図５）は、マスク計算機５０７の代わりに、ルールをキャッシュするためのサポートを含み得る。マスク計算機５０７が、データベース２０３から、そのルールを構築すると、それらを収集コンテキスト５０３上にキャッシュすることができる。これは、ひいては、すべてのマスク計算機５０７が、最初に、データベース２０３をヒットする前に、必要とするルールが、依然として、存在するかどうか確認し、ルールを再構成することができることを意味する。本モデルは、性能の向上に寄与し、したがって、可能である場合、常時、使用することができる。

以下は、ルールをキャッシュするためのメソッドがどのようなものであるかを示す。
ｐｕｂｌｉｃ ｃｌａｓｓ ＣｏｌｌｅｃｔｉｏｎＣｏｎｔｅｘｔ ｛
ｐｕｂｌｉｃ Ｏｂｊｅｃｔ ｇｅｔＨｏｔｅｌＲｕｌｅｓ（ＭａｓｋＣａｌｃｕｌａｔｏｒ ｃ）；
ｐｕｂｌｉｃ ｖｏｉｄ ｐｕｔＨｏｔｅｌＲｕｌｅｓ（ＭａｓｋＣａｌｃｕｌａｔｏｒ ｃ， Ｏｂｊｅｃｔ ｒｕｌｅｓ）；
｝
マスク計算機５０７が、ルールをキャッシュすると、ルールは、以下のイベントのうちの１つが生じるまで、メモリ内に残留し得る。
・データベース２０３内のホテルルール変更
・ＬＲＵキャッシュが、リソース管理のために、ホテルルールをパージする
・アプリケーションが再開される
一実施形態では、マスク計算機５０７は、キャッシュメソッドを使用し、信頼性があることを仮定するためのあらゆる努力をし得る。キャッシュ変更管理のための好適なソリューションが利用可能ではない場合、ＰＡＣＥエンジンは、キャッシュがアクティブ化されないよう確実にし得る。依然として、マスク計算機５０７は、常時、キャッシュがアクティブと仮定し得る。
・収集ストラテジ
ＰＡＣＥエンジンは、異なる目的のために利用することができるので、あらゆる場合に対する単一の検索アルゴリズムは、適切ではない。例えば、プルアプリケーションからの空き室状況要求は、最初に、より高いレベルの制限を、最後に、製品アイテムを検討し得る一方、プッシュアプリケーションは、製品アイテムを最初に検討し、可能な最も効率的順序でルールを適用することを所望し得る。

これに対処するために、ＰＡＣＥエンジンは、収集ストラテジ５０５インターフェースを使用して、収集が実際に行われる方法を表し得る。これは、基本的には、当業者に周知の抽象アルゴリズム設計パターンの実装である。ストラテジの選択は、収集選択肢５０６内の設定に基づき得る。

収集ストラテジ５０５のためのサンプルインターフェースは、以下に提供される。
ｐｕｂｌｉｃ ｉｎｔｅｒｆａｃｅ ＣｏｌｌｅｃｔｉｏｎＳｔｒａｔｅｇｙ｛
ｖｏｉｄ ｃｏｌｌｅｃｔ（ＣｏｌｌｅｃｔｉｏｎＣｏｎｔｅｔ ｃｔｘ，
Ｐｒｏｄｕｃｔ ＩｔｅｍＣｏｎｓｕｍｅｒ ｃｏｎｓｕｍｅｒ） ｔｈｒｏｗｓ ＳｅｒｖｉｃｅＥｘｃｅｐｔｉｏｎ；
｝
一実施形態では、サポートされる収集ストラテジ５０５は、以下を含み得る。

・クエリ
ＰＡＣＥエンジンが起動されると、最終的には、製品アイテムテーブルから製品アイテムを読み取り、マスク計算機５０７を適用し、最終ＬＯＳを導出し得る。製品アイテムを選択するために使用されるクエリは、いくつかの要因を考慮し得る。これらとして、以下が挙げられる。
・選択基準
・ＬＯＳ履歴
・販売除外
以下のセクションは、クエリのためのこれらの側面をより詳細に説明する。
・基礎クエリ
・ＬＯＳ履歴
・販売除外
（１）基礎クエリ
基礎クエリは、製品アイテムを選択する、ＳＱＬの最も単純な形態を表す。実際、これは、使用される実際のＳＱＬではなくてもよい。しかしながら、他の完全形成クエリのための基線としての役割を果たし得るため、説明される。言い換えると、完全クエリを理解するために、基礎クエリの理解が重要である。

基礎クエリのための基準は、以下を含む。
・ホテルコード
・日付範囲
・料金カテゴリコード
・有効ステータス
・変更トークン（随意）
・除外部屋コード（随意）
・製品アイテムＩＤ（随意）
「有効ステータス」は、単に、無効製品アイテム行をスキップすることを意味する。変更トークンは、指定値以上のトークン値を伴う行を選択するために使用される。除外される部屋タイプは、場外された部屋を除くために使用される。最後に、製品アイテムＩＤのリストは、製品アイテムのより精密な選択のために、変更トークンの代わりに、含むことができる。

トークン値および製品アイテムＩＤは、実際には、事前計算によって修正されている、それらの製品アイテムのみ通すことを支援するために使用される。製品アイテムが、事前計算のために、変化する時および理由を最良に示すために使用することができる、種々の方法が存在するが、トークン番号＋製品アイテムＩＤが、一実施形態では、使用され得る。

製品アイテムが、製品アイテムコンシューマに送達される順序は、２つの理由から重要である。１つ目は、コンテキスト切替に関して、計算機５０７を効率的にさせるからである。２つ目は、製品アイテムコンシューマが、構築している結果を容易に編成可能であるからである。

この目的を達成するために、結果は、以下のように順序付けられ得る。
・日付
・料金カテゴリコード
・部屋コード
前述の教示に基づき、図７を参照すると、一実施形態では、本発明は、したがって、以下のステップを行い得る。
・複数の滞在日数に関する、ホテルの部屋に関連付けられたリアルタイム空き室状況の属性を含む事前算出データベースを生成するステップ（ステップ７０１）と、
・ある日付範囲に対する、少なくとも１つのホテルに対するクエリを受信するステップであって、日付範囲は、開始日および終了日を有する、ステップ（ステップ７０２）と、
・クエリに従いビジネス要件を適用することによって、複数の滞在日数に関する日付範囲内の各日の空き室状況を計算するステップ（ステップ７０３）と、
・事前算出データベースからの空き室状況とクエリの属性とを組み合わせることによって、複数の滞在日数に関しする日付範囲内の各日に対して、最終空き室状況を作成するステップ（ステップ７０４）と、
・複数の滞在日数に関する日付範囲内の各日に対して、少なくとも１つのホテルのためのホテルの部屋の最終空き室状況をフォーマットするステップ（ステップ７０５）。

方法およびシステムが、好ましい実施形態および特定の実施例と併せて説明されたが、その範囲が、記載の特定の実施形態に限定されることを意図するものではなく、本明細書の実施形態は、あらゆる観点において、制限ではなく、例証であることが意図される。

別様に明示的に記載されない限り、本明細書に記載の任意の方法は、そのステップが、特定の順序で行われることを必要とするものと解釈されるように意図されない。故に、方法請求項が、実際には、そのステップによって追随される順序を列挙していない、またはステップが特定の順序に限定されることが、請求項または説明に別様に特定的に記載されていない場合、いかなる観点においても、ある順序が暗示されることをいかようにも意図されない。これは、ステップまたは動作フローの配列に関するロジックの問題、文法構成または句読法から導出される単純な意味、明細書に説明される実施形態の数またはタイプを含む、いかなる可能性のある解釈のための黙示原則にも該当する。

本発明の範囲または精神から逸脱することなく、種々の修正および変形を行うことができることは、当業者に明白である。他の実施形態は、明細書および本明細書に開示される実践を検討することによって、当業者に明白となるであろう。明細書および実施例は、単なる例示として見なされ、真の範囲および精神は、以下の請求項によって示されることが意図される。

Claims (15)

1. ホテルの部屋の空き室状況のためのデータベースを検索するコンピュータ実装方法であって、
   複数の滞在日数に関する、ホテルの部屋に関連付けられたリアルタイム空き室状況の属性を含む事前算出空き室状況関連データベースをコンピュータシステムにより生成するステップと、
   ある日付範囲に対する、少なくとも１つのホテルに対するクエリを前記コンピュータシステムにより受信するステップであって、前記日付範囲は、開始日および終了日を有する、ステップと、
   前記事前算出データベースから、前記複数の滞在日数のうちの少なくとも１日に関連付けられたホテルの部屋の空き室状況を前記コンピュータシステムにより決定するステップと、
   前記ホテルの部屋の前記空き室状況にビジネスロジックを前記コンピュータシステムの空き室状況ルール計算機エンジンにより適用するステップであって、前記ビジネスロジックを適用することは、ビジネスルールを適用することを含み、前記ビジネスルールは、空き室状況を制御するためにホテルが設定することが可能な複数の属性を含み、前記ビジネスルールが適用される順序は、処理時間サイクルにおいて直接影響を有する、ステップと、
   前記空き室状況ルール計算機エンジンの前記ビジネスロジックを適用することに基づいて前記事前算出データベースからの前記空き室状況を制限することによって、前記複数の滞在日数に関する前記日付範囲内の各日に対して、最終的な空き室状況を前記コンピュータシステムにより作成するステップと、
   前記複数の滞在日数に関する前記日付範囲内の各日に対して、前記少なくとも１つのホテルのための前記ホテルの部屋の最終的な空き室状況を前記コンピュータシステムによりフォーマットするステップと
   を含む、方法。
2. 前記滞在日数は、ビットマップによって表され、各ビットは、前記滞在日数内の日を表す、請求項１に記載のコンピュータ実装方法。
3. 前記クエリは、旅行ウェブサイトから受信される、請求項１に記載のコンピュータ実装方法。
4. 前記クエリは、クライアントから受信される、請求項１に記載のコンピュータ実装方法。
5. 前記空き室状況を制御するために前記ホテルによって設定される複数の属性は、料金前払、宿泊数、最短/最長滞在日数、特殊要件を含む、請求項１に記載のコンピュータ実装方法。
6. 前記ホテルの部屋の最終的な空き室状況を旅行ウェブサイトに伝送するステップをさらに含む、請求項１に記載のコンピュータ実装方法。
7. 前記ホテルの部屋の最終的な空き室状況をクライアントに伝送するステップをさらに含む、請求項１に記載のコンピュータ実装方法。
8. ホテルの部屋の空き室状況のためのデータベースを検索するためのシステムであって、
   複数の滞在日数に関する、ホテルの部屋に関連付けられたリアルタイム空き室状況の属性を含む事前算出空き室状況関連データベースをコンピュータシステムにより生成する手段と、
   ある日付範囲に対する、少なくとも１つのホテルに対するクエリを前記コンピュータシステムにより受信する手段であって、前記日付範囲は、開始日および終了日を有する、手段と、
   前記事前算出データベースから、前記複数の滞在日数のうちの少なくとも１日に関連付けられたホテルの部屋の空き室状況を前記コンピュータシステムにより決定する手段と、
   前記ホテルの部屋の前記空き室状況にビジネスロジックを前記コンピュータシステムの空き室状況ルール計算機エンジンにより適用する手段であって、前記ビジネスロジックを適用することは、ビジネスルールを適用することを含み、前記ビジネスルールは、空き室状況を制御するためにホテルが設定することが可能な複数の属性を含み、前記ビジネスルールが適用される順序は、処理時間サイクルにおいて直接影響を有する、手段と、
   前記空き室状況ルール計算機エンジンの前記ビジネスロジックを適用することに基づいて前記事前算出データベースからの前記空き室状況を制限することによって、前記複数の滞在日数に関する前記日付範囲内の各日に対して、最終的な空き室状況を前記コンピュータシステムにより作成する手段と、
   前記複数の滞在日数に関する前記日付範囲内の各日に対して、前記少なくとも１つのホテルのための前記ホテルの部屋の最終的な空き室状況を前記コンピュータシステムによりフォーマットする手段と
   を含む、システム。
9. 前記滞在日数は、ビットマップによって表され、各ビットは、前記滞在日数内の日を表す、請求項８に記載のシステム。
10. 前記クエリを受信する手段は、旅行ウェブサイトから前記クエリを受信する、請求項８に記載のシステム。
11. 前記クエリを受信する手段は、クライアントから前記クエリを受信する、請求項８に記載のシステム。
12. 前記空き室状況を制御するために前記ホテルによって設定される複数の属性は、料金前払、宿泊数、最短/最長滞在日数、特殊要件を含む、請求項８に記載のシステム。
13. 前記ホテルの部屋の最終的な空き室状況を旅行ウェブサイトに伝送する手段をさらに含む、請求項８に記載のシステム。
14. 前記ホテルの部屋の最終的な空き室状況をクライアントに伝送する手段をさらに含む、請求項８に記載のシステム。
15. コンピュータ読み取り可能なプログラムコードを記録しているコンピュータ読み取り可能な記録媒体であって、前記コンピュータ読み取り可能なプログラムコードは、ホテルの部屋の空き室状況のためのデータベースを検索する方法を実行することをコンピュータに行わせるように実行されるように適合されており、
    前記方法は、
    複数の滞在日数に関する、ホテルの部屋に関連付けられたリアルタイム空き室状況の属性を含む事前算出空き室状況関連データベースをコンピュータシステムにより生成することと、
    ある日付範囲に対する、少なくとも１つのホテルに対するクエリを前記コンピュータシステムにより受信することであって、前記日付範囲は、開始日および終了日を有する、ことと、
    前記事前算出データベースから、前記複数の滞在日数のうちの少なくとも１日に関連付けられたホテルの部屋の空き室状況を前記コンピュータシステムにより決定することと、
    前記ホテルの部屋の前記空き室状況にビジネスロジックを前記コンピュータシステムの空き室状況ルール計算機エンジンにより適用することであって、前記ビジネスロジックを適用することは、ビジネスルールを適用することを含み、前記ビジネスルールは、空き室状況を制御するためにホテルが設定することが可能な複数の属性を含み、前記ビジネスルールが適用される順序は、処理時間サイクルにおいて直接影響を有する、ことと、
    前記空き室状況ルール計算機エンジンの前記ビジネスロジックを適用することに基づいて前記事前算出データベースからの前記空き室状況を制限することによって、前記複数の滞在日数に関する前記日付範囲内の各日に対して、最終的な空き室状況を前記コンピュータシステムにより作成することと、
    前記複数の滞在日数に関する前記日付範囲内の各日に対して、前記少なくとも１つのホテルのための前記ホテルの部屋の最終的な空き室状況を前記コンピュータシステムによりフォーマットすることと
    を含む、コンピュータ読み取り可能な記録媒体。