JP6991385B2 - 最大利用可能性在庫 - Google Patents

Description

本発明は、一般に、コンピュータ化された在庫(inventories)に関し、詳細には、アイテムの在庫内のアイテムの利用可能性(availability)を最適化するための方法およびシステム、ならびに関連するコンピュータプログラム製品に関する。

本発明の実施形態は、在庫を管理する人またはシステムのあらゆるインスタンスが直面する問題に対処する。たとえば、以下の構成表に記載されているような、特定のタイプ(部屋タイプと呼ばれる)にそれぞれ適合する8つの部屋を有するホテルを経営しているホテル経営者を考え得る。ホテル経営者は、異なる基準を有する予約リクエストを受信し、それぞれの予約リクエストの基準をできるだけ多く含む部屋タイプに1つずつ割り振ることによって、最大数のリクエストを受け入れようとする。多数の予約が受け入れられ、部屋タイプに割り振られた後、演習は複雑になる。新しい予約が到着すると、それに合うように、ホテル経営者ができるだけ多くの基準を満たすために1つまたは複数の予約が再割振りされる必要がある場合があり、これは特に部屋タイプの数が増えると非常に複雑になる可能性がある。

従来のコンピュータ化された予約システムは、在庫の管理を最適化しようとした。ある人は、オーシャンビューの禁煙ルームを検索するために、ホテル予約システムのグラフィカルユーザインターフェースにアクセスし得る。例では、どの予約もまだ受け入れられていないと仮定し得る。したがって、部屋タイプの利用可能性は、構成表において定義されているように、部屋の完全な数に対応する。オーシャンビューの禁煙ルームの予約リクエストを受信すると、在庫システムは利用可能性をチェックする。上記の表によって説明される構成を考慮すると、2つの部屋タイプが「オーシャンビュー」+「禁煙」の基準を満たしている。部屋タイプがリストアップされ、人は1つを選択して予約を実行し得る。次いで、在庫システムは、その部屋タイプの利用可能性を1つ減少させる。上記の構成表によって説明される在庫には、「高層階」+「オーシャンビュー」+「禁煙」という特性を有する1つの部屋がある。この部屋は、7つの異なるリクエスト、すなわち、「高層階」のリクエスト、「オーシャンビュー」のリクエスト、「禁煙」のリクエスト、「高層階」+「オーシャンビュー」のリクエスト、「高層階」+「禁煙」のリクエスト、「オーシャンビュー」+「禁煙」のリクエスト、または「高層階」+「オーシャンビュー」+「禁煙」のリクエストを満たすことができる。システムが「低層階」+「オーシャンビュー」+「禁煙」の部屋を「オーシャンビュー」+「禁煙」の予約リクエストに割り振ると、今後の「低層階」+「オーシャンビュー」+「禁煙」のリクエストを満たすことはもはやできなくなる。

Boiesらによる特許出願第09/747,815号「Airline reservation system that supports guaranteed reservations for a preferred category of seating」では、航空券予約の分野における解決策が提示されている。座席の優先カテゴリのリクエストを受信することと、座席の優先カテゴリが利用可能かどうかを決定することと、座席の優先カテゴリを保証することと、保証された座席のカテゴリ内の座席に乗客を割り当てることとを行うための方法を説明する。追加の座席リクエストに対応するために、保証された座席のカテゴリ内の異なる座席に乗客を再度割り当てることができる。新しいリクエストに対応すると、カスケード効果が生じ、多くの再割当てが必要になる場合がある。これは飛行機のシートマップなどの比較的単純な在庫では問題にならないかもしれないが、より複雑な在庫システム(ホテルチェーンの何千もの部屋など)では、新しいリクエストに対応するには膨大な計算時間が必要になるため、実行可能ではない。さらに、予約の再割当てにはキャンセルトランザクションと再予約トランザクションが含まれるため、この手法はコストがかかる可能性がある。不透明な旅行商品の販売を考えると、さらに複雑になる。不透明な商品は、いくつかの知られていない、または隠された特性を有する商品である。不透明なフライトの場合、隠された特性は、たとえば、フライトを運航する航空会社、旅行日または目的地、あるいはこれらの特性の組合せであり得る。不透明な航空商品の例としては、6月15日にパリから南ヨーロッパの沿岸都市に行き、6月29日に帰国するエールフランス便がある。この商品を購入する旅行者は、出発時刻も正確な目的地も(日付にかなり近くなるまで)わからない。不透明な商品は、6月15日にパリの2つの空港から出発する4つの便に対応し得る。既存の在庫制御システムは、不透明な商品の予約に物理的なアイテムを割り当て、したがって標準に影響するため、不透明な商品の在庫を効果的に管理することができない。これにより、在庫リソースが最適に活用されない状況が発生する可能性がある。新しい予約が受信されたときに再割当てが可能であるが、前述のように、それはカスケード効果を含意し、多くのトランザクションを伴うため、処理の負荷が増大する。さらに、選択された各割振りは、航空会社の収益全体を最適化する航空会社収益管理システムに影響を与え、収益管理システムは暫定的な割振りによって歪められる可能性がある。

これらの例は、在庫を管理するための改善されたシステム、方法、およびコンピュータプログラム製品の必要性を示している。

Boiesらによる特許出願第09/747,815号「Airline reservation system that supports guaranteed reservations for a preferred category of seating」

https://en.wikipedia.org/wiki/Maximum_flow_problem L.R. Ford, JrおよびD.R. Fulkersonによる「Maximum Flow Through a Network」(Canadian Journal of Mathematics, vol. 8, pages 399-404, 1956)

本発明は、コンピュータ化された予約システムにおける在庫の仮想化を可能にすることによって、上述のシステムに固有の欠点を克服することを目的とする。重要な利点は、仮想層に関連するリソース管理の柔軟性が、在庫リソースを使用するより多くの異なる商品を作成することを可能にすることである。これは、ユーザが、従来の在庫よりも多数の特性に基づいてアイテムを選択し得ることを意味する。

より具体的には、本発明は、クライアントサーバ処理システムを介して、予約システム内のアイテムの在庫内のアイテムの利用可能性を最適化するための仮想化方法に関し、アイテムはアイテムタイプに分類され、本方法は、
(1)サーバが、アイテムのリストと、対応するアイテムタイプとを受信するステップと、
(2)サーバが、少なくとも1つの特性のリクエスト可能なセットとしてアイテムタイプを定義するステップと、
(3)サーバが、少なくとも1つの特性のセットの予約リクエストを受信するステップと、
(4)サーバが、リクエストされたセットの利用可能性を計算するステップと、
(5)リクエストされたセットが利用可能な場合、サーバが、予約リクエストを受け入れ、受け入れられた予約を考慮してリクエスト可能なセットの利用可能性を更新するステップと、
リクエストされたセットが利用可能ではない場合、サーバが、予約リクエストを拒否するステップと、
(6)サーバが、リクエスト可能なセットの後続の予約リクエストのためにステップ(3)から(5)を繰り返すステップとを含む。

在庫をリクエスト可能な特性のセットの集合と見なすことによって、リクエスト時にアイテムを予約に割り振る必要がなくなる。リクエスト可能な特性のセットについて、実際に予約を受信することができる。その結果、新しい予約に対応する必要がある場合、再割当ては必要ない。特性のセットの予約がリクエストされると、リクエストされたセットの利用可能性は、利用可能性が最大になるように計算される。これは、以前に受け入れられた予約の影響を最小限に抑えることによって行われる。したがって、在庫内のアイテムの利用可能性は、最新技術と比較して最大化される。一方、従来の予約システムでは、在庫が大きく、多くの予約が受け入れられたとき、新しい予約に対応する必要があるときに計算数が膨大になるが、本発明によるシステムにおいて、これはそのようではない。自由度の数は、受け入れられた予約の数に反比例すると考えることができる。受け入れられた予約が多いほど、新しい予約の対応が迅速になるか、拒否される。処理負荷が大幅に削減され、在庫内のアイテムの最適な利用可能性が確保される。

本発明の一実施形態によれば、リクエスト可能なセットは、アイテムタイプを定義する特性のセット、および他のあらかじめ定められた特性のセットを含む。在庫の責任者または管理者は、可能な特性のセットを定義し得、これにより、在庫の柔軟な管理が可能になる。

本発明の一実施形態によれば、あらかじめ定められた特性のセットは、アイテムタイプを定義する特性のセットのサブセットである。したがって、複数のアイテムタイプを参照するあらかじめ定められた特性のセットについて、予約が受信され得る。この方法で予約を定義することの利点は、後続の予約のためにより多くの特性のセットが利用可能なままであることである。

本発明の一実施形態によれば、本方法は、アイテムの在庫がそれを介して定義される構成システムとの通信を備え、本通信は、
- サーバが、少なくとも1つの定義された特性のセットのサブセットである少なくとも1つの特性のリクエスト可能なセットのあらかじめ定められたリストを受信するステップを備え、本方法は、
- サーバが、受信したリクエスト可能なセットの初期利用可能性を計算するステップを備える。

本発明の一実施形態によれば、本方法は、リクエスト可能なセットのリストから、アイテムタイプのすべてのリクエスト可能な特性よりも少ないリクエスト可能な特性を備えるリクエスト可能なサブセットを識別するステップを備え、リクエスト可能なセットcの利用可能性の計算は、
(1)N個のノードのグラフを構築するステップであって、N=2+アイテムタイプの数+リクエスト可能なサブセットの数であり、グラフは、ソースノードs、ターゲットノードt、アイテムタイプnごとのノード(n)、および特性mのリクエスト可能なサブセットごとのノード(m)で構成される、ステップと、
(2)- アイテムタイプnごとに、容量がアイテムタイプnの特性のセットの容量に等しい、ノード(n)からターゲットノードtへのアークを作成するステップと、
- リクエスト可能なサブセットmごとに、
- リクエスト可能なサブセットmを含むアイテムタイプkを列挙するステップと、
- アイテムタイプkごとに、容量がアイテムタイプkの特性のセットの容量に等しい、ノード(m)からノード(k)へのアークを作成するステップと、
によってグラフを初期化するステップと、
(3)予約リクエストが受け入れられた場合、リクエスト可能なセットzごとに、リクエスト可能なセットzの予約の数に等しい容量を有するソースノードsからノード(z)へのアークを作成することによって、受け入れられた予約でグラフを更新するステップと、
(4)ソースノードsからターゲットノードtへの最大フローアルゴリズムを実行し、逆フローをグラフに追加するステップと、
(5)ノード(c)からターゲットノードtへの反復最大フローを実行し、作成された増分フローを測定するステップであって、
- ノード(c)とターゲットノードtの間にパスがある間、パス上のフローjが増加するステップと、
- すべてのフローjを合計して、リクエスト可能セットcの利用可能性fをもたらすステップとを備えるステップとを含む。

グラフを使用したモデリングには、解決されるべき問題を視覚化することができるという第1の利点がある。さらに、主要な問題構造は、グラフの特性を活用した効率的なアルゴリズムを適用できるモデルによって反映される。グラフ上でアイテムの在庫を表し、最大フローアルゴリズムを使用してリクエスト可能な特性のセットの利用可能性を計算することによって、在庫の管理が軽量かつ高速になる。最大フローアルゴリズムは、複雑な在庫の利用可能性を計算するためにスケーラブルである。グラフの操作には、多くの処理能力は必要ない。このシステムでは利用可能性の計算が非常に簡単であるため、いつでも再計算することができ、コストとなる、後で使用するための記憶を行う必要がない。

本発明の一実施形態によれば、セットcについて人数pの予約リクエストを受け入れ、受け入れられた予約を考慮してリクエスト可能なセットの利用可能性を更新するステップは、
(1)リクエスト可能なセットcの予約データベース内の予約の数をpずつ増分するステップと、
(2)N個のノードのグラフを構築するステップであって、N=2+アイテムタイプの数+リクエスト可能なサブセットの数であり、グラフは、ソースノードs、ターゲットノードt、アイテムタイプnごとのノード(n)、および特性mのリクエスト可能なサブセットごとのノード(m)で構成される、ステップと、
(3)- アイテムタイプnごとに、容量がアイテムタイプnの特性のセットの容量に等しい、ノード(n)からターゲットノードtへのアークを作成するステップと、
- リクエスト可能なサブセットmごとに、
- リクエスト可能なサブセットmを含むアイテムタイプkを列挙するステップと、
- アイテムタイプkごとに、容量がアイテムタイプkの特性のセットの容量に等しい、ノード(m)からノード(k)へのアークを作成するステップと、
によってグラフを初期化するステップと、
(4)予約データベース125から予約を検索し、複数の予約qを有するリクエスト可能なセットjごとに、容量qを有するソースノードsからノード(j)へのアークを作成することによって、受け入れられた予約でグラフを更新するステップと、
(5)ソースノードsからターゲットノードtへの最大フローアルゴリズムを実行し、逆フローをグラフに追加するステップと、
(6)リクエスト可能なセットiごとに、
(i)ノード(i)からターゲットノードtへの反復最大フローを実行し、作成された増分フローを測定するステップであって、
- ノード(i)とターゲットノードtの間にパスがある間、パスのフローgを増加させるステップと、
- すべてのフローgを合計し、結果としてリクエスト可能なセットiの利用可能性fが得られるステップと、
を備える、ステップと、
(ii)iは利用可能性が計算されるべき最後のリクエスト可能なセットではない間、ターゲットノードtとノード(i)の間の利用可能性fによって制限された反復境界フローを実行するステップであって、ターゲットノードtからノード(i)までの少なくとも1つのパスのフローを利用可能性fまで増加させるステップを備える、ステップと、
を備える。

発明者らは、すべての利用可能性を計算するために同じグラフを操作できることを発見した。実際、リクエスト可能な特性のセットの利用可能性計算後に反復境界フローを実行することによって、グラフを別のリクエスト可能なセットの利用可能性の計算が可能な状態に戻すことができる。この操作は従来のものではなく、解決策の効率に寄与する。

本発明の一実施形態によれば、グラフは、アークを有するリクエスト可能なサブセットノードをリクエスト可能なサブセットノードに接続することによって、アークの数が最適化される。

本発明の一実施形態によれば、グラフは、アークの代わりにノードに、または両方に設定された容量を有する。

本発明の一実施形態によれば、グラフは容量マトリックスとしてメモリに記憶される。

本発明の一実施形態によれば、予約システムはホテル予約システムであり、アイテムタイプはホテルの部屋タイプまたは他の予約可能な商品である。ホテル予約システムの在庫は数百の部屋を備える場合があり、部屋は複数の特性によって定義され得る。この解決策は、新しい予約に再対応する必要があるときに既存の予約を再度割り当てる必要があるという複雑な問題を克服する。

本発明の一実施形態によれば、予約システムはフライト予約システムであり、アイテムタイプはフライトの予約可能な場所である。不透明な商品を含めることにより、在庫リソースは最適に活用され得る。物理的なアイテムが予約に割り振られていないため、新しい予約が受信されても再割当ては不要であり、航空会社の収益管理システムは影響を受けないままである。予約とキャンセルの繰り返しによって発生するノイズを回避することで、収益管理システムによって計算される需要予測の堅牢性が向上し、品質が向上する。

本発明はさらに、本発明の方法を実行するように構成されたコンピュータシステムに関する。

本発明はまた、コンピューティングデバイスまたはシステムによって実行されると、コンピューティングデバイスまたはシステムに本発明の方法を実行させる命令を有するコンピュータプログラムに関する。

本明細書に組み込まれ、その一部を構成する添付図面は、本発明の様々な例示的実施形態を示し、上記の本発明の一般的な説明、および以下に示す実施形態の詳細な説明とともに、本発明の実施形態を説明するために役立つ。

中央予約システム100を含む、旅行商品の予約を実行するための例示的な動作環境の概略図である。 中央予約システム100内の予約システム120の構成要素の概略図である。 従来のホテル予約システム内の利用可能性モジュール220、予約モジュール200、および構成システム130の概略図である。 本発明の実施形態によるホテル予約システム内の利用可能性モジュール220、予約モジュール200、および構成システム130の概略図である。 従来のフライト予約システム内の利用可能性モジュール220、予約モジュール200、および構成システム130の概略図である。 本発明の実施形態によるフライト予約システム内の利用可能性モジュール220、予約モジュール200、および構成システム130の概略図である。 本発明の実施形態によって開示される仮想化方法を示す流れ図である。 グラフを構築するステップを示す流れ図である。 例示的な初期化されたグラフおよびメモリ内の対応する容量マトリックスを示す図である。 受け入れられた予約でグラフを更新するステップを示す流れ図である。 受け入れられた予約およびメモリ内の対応する容量マトリックスで更新された図9の例示的なグラフを示す図である。 組合せの利用可能性を計算し、新しい利用可能性計算のためにグラフを再利用するためにフローを元に戻すためのステップを示す図である。 図11の例示的なグラフと、ノードsからノードtへの最大フローアルゴリズムを実行し、容量マトリックスに逆フローを記憶した後の対応する容量マトリックスを示す図である。グラフは現在、初期利用可能性と受け入れられた予約を考慮して、リクエスト可能な特性のセットの利用可能性の計算が可能な状態である。 リクエスト可能な特性OVのサブセットの利用可能性を計算するためにノードOVとノードtの間で反復最大フローアルゴリズムを実行し、容量マトリックスに逆フローを記憶した後の図13の例示的なグラフと対応する容量マトリックスを示す図である。 2つのオーシャンビュールームの予約が受け入れられた場合の、図11の例示的なグラフと対応する容量マトリックスを示す図である。 図15の例示的なグラフと、ノードsからノードtへの最大フローアルゴリズムを実行し、容量マトリックスに逆フローを記憶した後の対応する容量マトリックスを示す図である。グラフは現在、初期利用可能性と2つのオーシャンビュールームの新しい予約を含む受け入れられた予約を考慮して、リクエスト可能な特性のセットの利用可能性の計算が可能な状態である。 リクエスト可能な特性OVのサブセットの利用可能性を計算するためにノードOVからノードtへの反復最大フローアルゴリズムを実行し、容量マトリックスに逆フローを記憶した後の図16の例示的なグラフと対応する容量マトリックスを示す図である。 OVの利用可能性計算前の状態と同等の状態に戻された後の、図17の例示的なグラフと対応する容量マトリックスとを示す図である。 図6の構成データで初期化された例示的なグラフを示す図である。 図19aのグラフに対応する容量マトリックスを示す図である。 受け入れられた予約で更新された図19aの例示的なグラフを示す図である。 図20aのグラフに対応する容量マトリックスを示す図である。 ノードsからノードtへの最大フローアルゴリズムを実行し、容量マトリックスに逆フローを記憶した後の図20aの例示的なグラフを示す図である。グラフは現在、初期利用可能性と受け入れられた予約を考慮して、リクエスト可能な特性のセットの利用可能性の計算が可能な状態である。 図21aのグラフに対応する容量マトリックスを示す図である。 図22aは、リクエスト可能な特性Wのサブセットの利用可能性を計算するためにノードWからノードtへの反復最大フローアルゴリズムを実行し、容量マトリックスに逆フローを記憶した後の図21aの例示的なグラフおよび対応する容量マトリックスを示す図である。 図22aのグラフに対応する容量マトリックスを示す図である。 2×Wの予約が受け入れられた後の図19aの例示的なグラフを示す図である。 図23aのグラフに対応する容量マトリックスを示す図である。 ノードsからノードtへの最大フローアルゴリズムを実行し、容量マトリックスに逆フローを記憶した後の図23aの例示的なグラフを示す図である。グラフは現在、初期利用可能性と2×Wの新しい予約を含む受け入れられた予約を考慮して、リクエスト可能な特性のセットの利用可能性の計算が可能な状態である。 図24aのグラフに対応する容量マトリックスを示す図である。 リクエスト可能な特性Wのサブセットの利用可能性を計算するためにノードWからノードtへの反復最大フローアルゴリズムを実行し、容量マトリックスに逆フローを記憶した後の図24aの例示的なグラフを示す図である。 図25aのグラフに対応する容量マトリックスを示す図である。 Wの利用可能性計算前の状態と同等の状態に戻された後の図25aの例示的なグラフを示す図である。 図26aのグラフに対応する容量マトリックスを示す図である。 例示的なコンピュータシステムの概略図である。

次に図1を参照すると、本発明の一実施形態による動作環境は、旅行商品の予約を実行するための中央予約システム100(CRS)、管理ポータル110、およびネットワーク115を介して通信する1つまたは複数のクライアントシステム105を含む。クライアントシステム105は、資産管理システム、旅行代理店システム、グローバル配信システム、または別の中央予約システムであり得る。管理ポータル110は、CRS100を更新するための、たとえば、ホテルまたはフライトを追加または削除するためのインターフェースを提供する。CRS100は、予約システム120、構成システム130、および利用可能性キャッシュシステム140を含む。これら3つのシステムの各々は、データベースと通信し、ネットワーク115を通じて相互接続される。構成システム130は、たとえばホテルまたはフライトを設定するために、クライアントアプリケーションを通じてCRS100の管理者によって使用される。構成を可能にするパラメータは、構成データベース135に記憶される。たとえばホテルのCRS100に適用されると、構成システム130は、部屋およびそれらの部屋タイプ、部屋タイプごとの部屋の数、ならびに価格設定をリストアップするために使用され得る。航空会社のCRS100に適用されると、構成システム130は、特定のフライトのシートマップを作成するために、すなわち、予約クラスおよび認可レベルまたは予約クラスごとの座席数をリストアップするために使用され得る。旅行者は、CRS100にアクセスして旅行商品を検索するために、旅行代理店システムのウェブインターフェースなどのクライアントシステム105を使用し得る。ユーザに表示される旅行商品は、利用可能性キャッシュシステム140から検索される。利用可能性キャッシュシステム140は、すべての販売可能な商品の利用可能性をキャッシュメモリ145に記憶し、したがって、高速アクセスを可能にする。キャッシュのゾーンは、予約または予約リクエストが受信されて受け入れられ、販売可能な商品の利用可能性に影響を与えたときにリフレッシュされ得る。旅行者は旅行商品を選択し、それを予約することを決定し得る。予約リクエストは、予約システム120に送信される。予約システム120は、リクエストされた基準に対応する旅行商品が利用可能かどうかをチェッ
クし、可能であれば予約を確認し、予約データベース125に予約を記憶し、販売可能な商品の利用可能性を再計算し、更新された値を利用可能性キャッシュシステム140に送信する。本発明の実施形態を明確にするために、この説明では航空会社およびホテルの例をさらに詳述するが、本発明の実施形態は、フライトまたはホテルの部屋の中央予約システム100に限定されず、任意のコンピュータ化された在庫を含むことができる。

次に図2を参照すると、中央予約システム100内の予約システム120は、予約モジュール200、価格設定モジュール210、および利用可能性モジュール220を含み、予約データベース125と通信する。利用可能性モジュール220は、構成データベース130および予約データベース125に照会する。旅行商品の初期数および行われた予約に基づいて、利用可能性モジュールが利用可能性を計算する。価格設定モジュール210は、ユーザリクエストが受信されるとアドレス指定される。ユーザによって与えられた基準を満たす利用可能な商品が価格設定され、リストアップされる。

図3において、所与の日付のホテルH1について、従来のホテルのCRS100における予約システム120の動作が示されている。構成システム130は、部屋タイプのリスト、部屋タイプごとの特性、および部屋タイプごとの毎日の部屋の数を利用可能性モジュール220に提供する。行われた予約は、予約モジュール200によって提供される。この入力により、毎日の利用可能性が計算される。その後、それらは利用可能性キャッシュシステム140にプッシュされる。1室1泊に1つのアイテムタイプの予約を受け入れることは、予約の数を1つ増加させ(追加)、利用可能性を1つ減少させる(減算)ことを意味する。

3つの異なる部屋タイプP1、P2、およびP3にわたる100室の部屋の在庫に対応するホテルH1を考え得る。P1は、低層階およびシティビュー(LF&CV)の特性に対応する。P2は、高層階およびオーシャンビュー(HF&OV)の特性に対応する。P3は、低層階およびオーシャンビュー(LF&OV)の特性に対応する。所与の日付について、P1の利用可能性は5、P2の利用可能性は2、P3の利用可能性は2である。予約が受け入れられると、ユーザが指定した基準に基づいて部屋タイプが割り振られる。ユーザが所与の日付に特定のホテルにおける2つのオーシャンビュールームを検索すると仮定する。利用可能性キャッシュシステム140において、オーシャンビュー基準を備えたいくつかの部屋タイプが利用可能である。

第1のシナリオでは、ユーザにオプションがリストアップされる。
a) 2×(LF&OV)
b) 2×(HF&OV)
c) 1×(LF&OV)+1×(HF&OV)
ユーザは、2つの低層階のオーシャンビュールームを選択し得る(オプションa)。これにより、2×部屋タイプP3が割り振られる。P3の2つの予約は予約モジュール200に記憶される。P3の利用可能性は影響を受けて0になる。後に、たとえば車椅子のユーザによってこの部屋タイプがリクエストされても、オーシャンビュー、低層階の部屋の予約リクエストはこれ以上受け入れられない。スタッフは、車椅子の人にこれらの部屋を割り振るために既存の予約を再対応する必要があるが、これは複雑な場合があり、システムは役に立たないであろう。

第2のより柔軟なシナリオでは、利用可能性キャッシュシステム140は、ユーザにオプションをリストアップせず、代わりに、2つのオーシャンビュールームが利用可能であることをユーザに通知し、予約する可能性を与える。リクエストは2つの不透明な商品に関するものであり、知られている特徴はオーシャンビューのみであると考えることができる。しかしながら、舞台裏では、それにもかかわらず上記の3つのオプションのうちの1つが予約リクエストに割り振られる。2つの低層階のオーシャンビュールームが割り振られているものとする。P3の2つの予約は予約モジュール200に記憶される。P3の利用可能性は影響を受けて0になる。このシナリオでは、オーシャンビューの低層階の部屋の予約リクエストが受信された場合、予約に再対応できるが、カスケード効果を含意する場合がある。一般に、100室のホテルでは、99個の固有のリクエスト(リクエストされた特性のセットに関して固有)が受け入れられ、100番目の予約リクエストを受け入れるために99個の予約の各々に再対応する必要がある場合、チェックされるべき順列の最悪の場合の数は100(100!)の階乗であり、10^157に対応する。

要約すると、リクエスト時に特定のアイテムタイプをユーザに割り振ることによって、在庫の最適な使用が保証されなくなる。リクエストされ保証された基準は、実際に割り振られたアイテムの特性のサブセットのみを形成し得る。割り振られたアイテムのすべての特性を含む今後のリクエストはもはや満たされない可能性があり、在庫は最適な方法で満たされない。

次に図4を参照すると、本発明の実施形態によるホテルのCRS100内の予約システム120の動作が示されている。本発明の実施形態によるCRS100において、予約は(従来のシステムの場合のように)アイテムタイプではなく、リクエスト可能な特性のセットに割り振られる。アイテムタイプの利用可能性は、上記のように計算されないが、計算されるのは、ユーザがリクエストする可能性のある特性のセットの利用可能性である。図3に示されるように、予約が受け入れられるかどうかをチェックすることと利用可能性値を計算することは、従来のCRS100における単純な加算と減算が含まれるが、本発明の実施形態によるCRS100においては複雑になり、以下でさらに説明するように、いくつかの最大フローの問題を解決することを伴う。

図4に示されるように、特性によって定義された3つの異なる部屋タイプ(または、アイテムタイプ)にわたる100室の部屋の在庫を考える。この例では、ホテル管理者は、ユーザが正確な部屋タイプ(P1、P2、またはP3)、あるいは特性「オーシャンビュー」(OV)または特性「低層階」(LF)のいずれかに基づいて部屋をリクエストし得ると定義した。この場合、OVまたはLFなどのリクエスト可能な特性のサブセットは、不透明な商品と見なすことができる。不透明な商品OP1はOVに対応し、不透明な商品OP2はLFに対応する。利用可能性モジュール220は、構成システム130に構成データをリクエストする。ホテル管理者によって定義されたアイテムタイプおよびリクエスト可能な特性のサブセットまたは不透明な商品に基づいて、ユーザがリクエストし得る特性のセットが定義され、以下ではリクエスト可能な特性のセットと呼ばれる。これにより、LF&CV、HF&OV、LF&OV、OV、LFの5つのリクエスト可能な特性のセットが得られる。リクエスト可能な特性のセットごとに、初期利用可能性が計算される。アイテムタイプ(不透明な商品)のサブセットであるリクエスト可能な特性のセットの場合、初期利用可能性は、それが含まれるアイテムタイプごとのアイテムの数の追加である(初期利用可能性(OV)=アイテムの数(LF&OV)+アイテムの数(HF&OV))。図4に示されるように、特性LF&CV、HF&OV、LF&OVのリクエスト可能なセットに対していくつかの予約が予約モジュール200に登録されていることを考慮する。当業者は、従来のシステムで行われた予約が、セットアップの一部として本発明の実施形態によるシステムにインポートされ得ることを理解するであろう。この場合、元々アイテムタイプ用に記憶されていた予約は、リクエスト可能な特性のセットの予約に変換される。2つのオーシャンビュールームを探しているユーザは、オンライン旅行代理店などのクライアントシステム105を通じてホテル用のCRS100のグラフィカルユーザインターフェース(GUI)にアクセスし得る。ユーザは、GUI上のテキストボックスに基準「オーシャンビュー」(OV)を入力するか、対応するボックスにチェックを入れて、所与の日付セットに対してこのタイプの2つの部屋が必要であることを指定し得る(人数2の予約リクエスト)。この例では、リクエストは単一の日付に対して行われると仮定される。リクエストは、ホテルのCRS100のバックエンドシステムに送信される。利用可能性キャッシュシステム140は、利用可能性をチェックし、4つの利用可能な部屋を見つける。利用可能性キャッシュシステム140における利用可能性値は、最後に受け入れられた予約が処理された後に計算されている。これがどのように行われるかについては、以下でさらに説明する。ユーザは予約する可能性がある。予約リクエストは、予約モジュール200に送信される。予約リクエストを受信すると、リクエストされた特性のセットの利用可能性は、予約リクエストにおいて指定された日付ごとに計算され、すなわち、この例における単一の日付は、一方では、すべてのリクエスト可能な特性のセットの初期利用可能性を考慮し、他方では、受け入れられた(予約データベース125に記憶されている)予約を考慮している。これは、以下でさらに説明するように、2つの最大フローの問題を解決することによって実行することができる。その間に予約が受け入れられなかったとすると、利用可能性値は図4に示されるようになる。リクエスト可能な特性OVの利用可能性は4であるため、2つのオーシャンビュールームの予約リクエストを受け入れることができる。予約モジュール200は、リクエスト可能な特性OVに対する2つの予約を予約データベース125に記憶する。以下でさらに説明するように、すべての利用可能性値が再計算され、利用可能性キャッシュシステム140がリフレッシュされる。

前述の解決策とは異なり、特定の部屋タイプ(および、延長線上で考えると、特定の部屋)は予約に割り振られない。予約システム120は、リクエストされた特性のセットに対応する2つの部屋が利用可能であることを知っているが、予約はチェックイン時に特定の部屋タイプ(および、部屋)にのみ割り当てられる。これは、より多くの部屋タイプが利用可能なままであることを含意する。図4に示されるように、OVを2つ予約すると、OVの利用可能性のみが影響を受ける。リクエスト可能な特性のセット(HF&OV)および(LF&OV)の利用可能性は変更されないままであり、上記の例とは対照的に、オーシャンビュー、低層階の部屋に対するユーザリクエストは受け入れられる。

図5において、従来のフライトのCRS100における予約システム120の動作が示されている。たとえばニース-マドリッド(NCE-MAD)など、出発地と目的地は同じだがタイミングは異なる、2つの異なるフライトF1とF2を考える。F1の出発時間は午前7時であり、F2の出発時刻は午後4時である。どちらのフライトにもいくつかの客室コードがある。客室コードは、座席数とオーバーブッキングのマージンに対応する。客室コードの例は、ファーストクラス、ビジネス、プレミアムエコノミー、エコノミーである。F1とF2は両方とも、予約期間の開始時にビジネス(J)、プレミアムエコノミー(W)、エコノミー(M)の3つの異なる客室コードに広がる100席がある。8つの航空商品の構成を考える。8つのうち6つは標準商品と見なすことができ、フライト番号と客室クラスは知られている。8つのうち2つは不透明な商品であり、出発地、目的地、客室コードは知られているが、フライト番号(したがって、出発時刻)は隠されている。8つの航空商品が利用可能である。
- フライトF1客室コードプレミアムエコノミーW(F1W)、またはフライトF2客室コードプレミアムエコノミーW(F2W)のいずれか(F1W|F2W)にルーティングできる不透明な商品OP1
- フライトF1客室コードエコノミーM(F1M)、またはフライトF2客室コードエコノミーM(F2M)のいずれか(F1M|F2M)にルーティングできる不透明な商品OP2
- フライトF1および客室コードビジネスJ(F1J)に対応する標準商品P1
- フライトF1および客室コードプレミアムエコノミーW(F1W)に対応する標準商品P2
- フライトF1および客室コードエコノミーM(F1M)に対応する標準商品P3
- フライトF2および客室コードビジネスJ(F2J)に対応する標準商品P4
- フライトF2および客室コードプレミアムエコノミーW(F2W)に対応する標準商品P5
- フライトF2および客室コードエコノミーM(F2M)に対応する標準商品P6

予約モジュール200は、アイテムタイプごとの予約の数を記憶する。利用可能性を計算するために、利用可能性モジュール220は、構成データベース135に記憶されている構成データと、予約データベース125に記憶されている予約データを考慮する。不透明な商品の利用可能性は、不透明な商品が対応し得るアイテムタイプの利用可能性の合計に等しい。たとえば、F1WまたはF2W(F1W|F2W)に対応し得るOP1を例にとると、その利用可能性はF1Wの利用可能性にF2Wの利用可能性を足したもの(2+7=9)に等しい。ユーザが、所与の日付に、ニース-マドリッドのフライトの客席コードプレミアムエコノミー(人数2の予約リクエスト)2席を予約したいが、出発時間に柔軟性があると仮定する。ユーザはフライトのCRS100のGUI上でリクエストを入力し、商品P2、P5、およびおOP1から選択する。OP1はP2またはP5よりも安い場合があり、ユーザはOP1を選択し得る。OP1は、F1客室コードW(F1W)またはF2客席コードW(F2W)のいずれかに対応することができる。予約が受け入れられると、F1WまたはF2Wに割り振られる。不透明な商品OP1の人数2のリクエストがF1Wに割り振られていると仮定する。P2(F1W)の利用可能性はゼロになる。これは、F1Wの予約リクエストをこれ以上受け入れることができないことを意味する。

ここで図6を参照すると、本発明の実施形態によるフライトのCRS100における予約システム120の動作が示されている。前の例と同じ構成データを考慮する。多くの予約が受け入れられた。当業者は、従来のシステムで行われた予約が、セットアップの一部として本発明の実施形態によるシステムにインポートされ得ることを理解するであろう。この場合、元々アイテムタイプ用に記憶されていた予約は、リクエスト可能な特性のセットの予約に変換される。図示されるように、本発明の実施形態によるシステムでは、予約モジュール200および利用可能性モジュール220において、アイテムタイプおよび不透明な商品は、それらのリクエスト可能な特性に関して考慮される。標準商品はフライト番号と客室コードに対応し、不透明な商品OP1はリクエスト可能な特性Wに対応し、不透明な商品OP2は、リクエスト可能な特性Mに対応する。

特定の日付にプレミアムエコノミーでNCE-MADの2つのフライトを探しているユーザは、オンライン旅行代理店などのクライアントシステム105を通じてフライトのCRS100のグラフィカルユーザインターフェース(GUI)にアクセスし得る。ユーザは、GUI上で基準を入力し得る。リクエストは、フライトのCRS100のバックエンドシステムに送信される。利用可能性キャッシュシステム140は、ユーザリクエストに適合する3つのリクエスト可能な特性のセットを見つける。
1. F1W、利用可能性=2
2. F2W、利用可能性=7
3. W、利用可能性=9.
これらの利用可能性値は、最後に受け入れられた予約が処理された後に計算された。これがどのように行われるかは、以下でさらに説明される。

不透明な商品OP1に対応するオプション3は、最も安価なオプションであり得る。ユーザは、出発時間と予約オプション3について柔軟であり得る。予約リクエストは予約モジュール200に送信される。予約リクエストを受信すると、リクエストされた特性のセットの利用可能性は、一方では、すべてのリクエスト可能な特性のセットの初期利用可能性を考慮し、他方では、受信された(予約データベース125に記憶されている)予約を考慮して計算される。これは、以下でさらに説明するように、2つの最大フローの問題を解決することによって実行することができる。その間に予約が受け入れられなかったとすると、利用可能性値は図6に示されるようになる。リクエスト可能な特性Wの利用可能性は9であるため、2×W(不透明な商品OP1に対応する)の予約リクエストを受け入れることができる。予約モジュール200は、リクエスト可能な特性Wに対する2つの予約を予約データベース125に記憶する。以下でさらに説明するように、すべての利用可能性値が再計算され、利用可能性キャッシュシステム140がリフレッシュされる。

Wの利用可能性は2だけ減少するが、予約が特定の1つの特定の航空アイテムタイプに割り当てられていないため、F1WとF2Wの利用可能性は変更されないままである。前の例で説明したように、従来のCRS100においてはF1Wの後続の予約リクエストを受け入れることができなかったが、本発明の実施形態によるCRS100ではF1Wの予約リクエストを依然として受け入れることができる。

次に図7を参照すると、本発明の実施形態によって開示される仮想化方法がより詳細に説明される。このセットアップのさらなる利点は、直感に反して、Boiesらによる特許出願第09/747,815号「Airline reservation system that supports guaranteed reservations for a preferred category of seating」に開示されているシステムとは対照的に、受け入れられた予約の数が増えると、予約を受け入れることができるかどうかを決定するために行われるべき計算の数が減少することである。発明者は、リクエスト可能な特性の観点からアイテムの在庫を表すことによって、利用可能性の問題は最大フローの問題のバリエーションとして表すことができることを発見した(https://en.wikipedia.org/wiki/Maximum_flow_problem)。リクエスト可能な特性のセット、アイテムタイプ、およびアイテムタイプごとのアイテムの数がグラフ上で視覚化され、いくつかの最大フローの問題を解決することによって利用可能性の計算を行うことができる。発明者は、特性cのセットの利用可能性の計算を行い、cの利用可能性の計算の前にその状態と等しい状態にグラフを戻すこと(したがって、特性の別のセットの利用可能性の計算が可能になる)は、L.R. Ford, JrおよびD.R. Fulkersonによる「Maximum Flow Through a Network」(Canadian Journal of Mathematics, vol. 8, pages 399-404, 1956)などの最大フローアルゴリズムのバリエーションを適用することによって行うことができることを発見した。以下の例がこれをさらに示している。発明者らは、この実施形態において使用されるアルゴリズムを「反復境界最大フロー」と呼ぶ。

構成データAは、構成データベース135から読み取られ、アイテムタイプのリスト、アイテムタイプに対応する特性のセット、およびアイテムタイプごとのアイテムの数に変換される。ホテルについては、所与の夜の所与のホテルの部屋タイプ、または、航空便については、所与の日付のフライト番号と客席コードを組み合わせたものなどの「標準」アイテムタイプ以外に、このリストは不透明な商品、または、前の図面に示されるように、様々な「標準」アイテムタイプに対応するリクエスト可能な特性のサブセット(RSC)も備え得る。ステップS710において、構成データAは、リクエスト可能な特性のセットの列挙、およびそれらの数または初期利用可能性(B)に変換される。不透明な商品またはRSCの場合、その数(B)は、対応するアイテムタイプの数の合計に等しくなる。入力データBを用いて、図8を参照して以下で説明するように、グラフCが構築され初期化される(S720)。利用可能性が計算される(S730)。この段階で、予約がまだ受け入れられていない場合、リクエスト可能な特性Dのセットの利用可能性は初期利用可能性に対応し、構成データAから計算される。利用可能性Dは利用可能性キャッシュシステムに送信される(S740)。ユーザリクエストFが受信され得る。ユーザがCRS100のGUIを介して旅行商品のリクエストを送信すると、それは特性Gのセットに変換される(S760)。ユーザリクエストF(特性Gのセットに対応する)を満たすことができるかどうかをチェックするために、特性Gのセットが利用可能性モジュール220に送信される(S770)。図9(ホテル)および図19a(航空機)に示されるように、グラフCが構築され初期化される(S720)。その後、利用可能性モジュール220は、予約モジュール200に既存の予約をリクエストする。図10の流れ図を参照して以下で説明され、図11(ホテル)および図20a(航空機)に示されるように、グラフCが既存の予約Eで更新され、最大フローが実行され、図13および図16(ホテル)、ならびに図21aおよび図24a(航空機)に示すように、グラフに逆フローが追加される(破線で)。次に、特性Gのセットの利用可能性を、図14および図17(ホテル)、ならびに図22aおよび図25a(航空機)に示されるように、「反復最大フロー」アルゴリズムを実行することによって計算することができる(S780)。特性Gのセットが利用可能ではない場合、予約リクエストは拒否される(S790)。特性Gのセットが利用可能である場合、ユーザリクエストFを受け入れることができる。Gは、予約データベース125内の受け入れられた予約のリストEに追加され(S799)、ユーザは、予約が行われたことを通知される(S9)。グラフCは、構成データAを考慮して(再)計算され(S720)、図15(ホテル)および図23a(航空機)に示されるように、受け入れられた予約Eで更新され、最大フローアルゴリズムが実行され、図13および図16(ホテル)、ならびに図21aおよび図24a(航空機)に示されるように、逆フローが記憶される(S750)。リクエスト可能な特性Dのセットの利用可能性は、反復最大フローアルゴリズムを繰り返すこと(S730)によって再計算される(S3)。図18(ホテル)および図26a(航空機)に示されるように、別のリクエスト可能な特性の利用可能性の計算を可能にするために、フローは元に戻される。リクエスト可能な特性のセットの利用可能性は、利用可能性キャッシュシステム140に送信される(S750)。

図8は、グラフがどのように構築され、構成データで初期化され得るかを示している。グラフは、容量を表すノードと向アークで構成される。アークは、ノードから所与の容量を有する別のノードに向かっている。アイテムタイプは、特性のセットおよび関連付けられる数、すなわち容量である。1、2、3...、nが列挙されている。RSC(不透明な商品とも呼ばれる)は、それ自体はアイテムタイプではない、固有のリクエスト可能な特性のサブセットである。1、2、3...、mが列挙されている。リクエスト可能な特性のセットは、アイテムタイプまたはRSCのいずれかである。グラフを初期化するために、次の入力が必要である。
・すべてのアイテムタイプとそれらに関連付けられる番号、すなわち容量。ホテル予約システムでは、アイテムタイプは、所与のホテルにおける、および所与の日付の部屋タイプであり得、フライト予約システムでは、アイテムタイプは、所与の日付のフライト番号、区間(出発地と目的地によって特徴付けられる)、および客室コードの組合せであり得る。
・すべてのリクエスト可能な特性のサブセット(RSC)または不透明な商品。
サイズNのグラフは、N=2+固有のアイテムタイプの数+リクエスト可能なサブセットの数で構成される。グラフは、ソース、ターゲット、固有のアイテムタイプごとに1つのノード、リクエスト可能な特性のサブセット(RSC)ごとに1つのノードなどのノードで構成され、これらの各々には、0とN-1との間の固有の番号が割り当てられる。

第1に、ソースノードsが作成される(S810)。次いで、ターゲットノードtが作成される(S820)。その後、アイテムタイプ(n)ごとに、
- 「アイテムタイプn」に対応するノード(n)が作成される(S830)
- アイテムタイプnの特性のセットの容量に等しい容量を有するノード(n)からノードtへのアークが作成される(S840)。

その後、リクエスト可能な特性のサブセット(RSC)mごとにノードとアークが作成される。これは次のように行われる。RSC mごとに、
- RSC mに対応するノード(m)が作成される(S850)
- RSC mを含むすべてのアイテムタイプkが列挙される(S860)
- アイテムタイプkごとに、ノード(m)からノード(k)への、アイテムタイプkの特性のセットの容量に等しい容量を有するアークが作成される(S870)。

これで、グラフの構築と初期化が終了した(S880)。

日付と時間の間隔は、特性と見なされ得る。利用可能性モジュール220が日付時間間隔ごとに独立して動作する場合、最大フローアルゴリズムが各間隔で独立して適用され、日付時間隔が特性としてモデル化されている場合、最大フローアルゴリズムはすべてのデータに一度だけ適用される。

RSCをアイテムタイプの代わりに、またはアイテムタイプに接続するだけでなく、対応するRSCに接続することによって、グラフのアーク数を最適化することができる。容量は、アークではなくノードで、またはその両方で設定され得る。

当業者は、同等の問題をモデル化するためにグラフを異なる方法で構築され得ることを理解するであろう。たとえば、グラフには複数のソースとターゲットがあり得、ノードとアークは別の方法で作成され得る。

メモリでは、グラフは容量マトリックス(int[N][N])として記憶され得、各セルは容量を含む。ノードを作成することは、その列と行をマトリックスに追加することを意味する。マトリックスセルはデフォルトで0を含む。容量cを有するノードaからノードbへのアークを作成することは、マトリックス[a][b]=cを設定することを意味する。グラフを初期化すると、次の容量マトリックスが作成される。アイテムタイプnごとに、アーク「アイテムタイプnからターゲットt」の容量が、構成システム130において定義されるように、このアイテムタイプnの容量に設定される場合、値(容量マトリックス[n][TARGET])は、構成システム130において定義されるように、アイテムタイプnの容量に対応して設定される。リクエスト可能な特性mのサブセットごとに、可能な対応するアイテムタイプnにごとに、アーク「mからn」の容量が、構成システム130において定義されるようにnの容量に設定される場合、値(容量マトリックス[m][n])は、構成システム130において定義されるようにnの容量に対応して設定される。当業者は、メモリ内のグラフの他の表現が可能であることを理解し得る。

図9では、図8のステップにおいて説明したように、サイズ7のグラフが7=2+3(固有のアイテムタイプの数)+2(リクエスト可能なサブセットの数)で構成されている。

図9に示されるグラフおよびメモリ内の対応する容量マトリックスは、図4に示されるように、構成データで構築および初期化されている。
構成データ:

第1に、ソースとターゲットが作成される。次いで、アイテムタイプ(P1、P2、P3)ごとにノードが作成される。構成システム130において定義された容量(P1-t:50、P2-t:20、P3-t:30)を有する、各アイテムタイプからターゲットへのアークが作成される。続いて、リクエスト可能な特性のサブセットまたは不透明な商品(OV、LF)ごとにノードが作成される。リクエスト可能な特性の各サブセットから、対応するアイテムタイプ(OV-P2、OV-P3、LF-P1、LF-P3)へのアークが作成される。リクエスト可能な特性のセットの容量は、構成システム130において定義されたアイテムタイプの容量に等しい(OV-P2:20、OV-P3:30、LF-P1:50、LF-P3:30)。グラフは容量マトリックス(int[7][7])に対応する。アイテムタイプnごとに、ノード(n)とターゲットノードtの間のアークの容量が、構成システム130において定義されるようにこのアイテムタイプnの容量に設定される場合(P1-t:50、P2-t:20、P3-t:30)、値(容量マトリックス[n][t])はそれに対応して設定される。
容量マトリックス[P1][t]=50
容量マトリックス[P2][t]=20
容量マトリックス[P3][t]=30

リクエスト可能な特性mのサブセットごとに、可能な対応するアイテムタイプnごとに、ノード(m)とノード(n)との間のアークの容量が構成システム130において定義されたnの容量に設定される場合(OV-P2:20、OV-P3:30、LF-P1:50、LF-P3:30)、値(容量マトリックス[m][n])はそれに対応して設定される。
容量マトリックス[OV][P2]=20
容量マトリックス[OV][P3]=30
容量マトリックス[LF][P1]=50
容量マトリックス[LF][P3]=30

図10は、受け入れられた予約でグラフを更新するために行われるステップを示している。

まず、アイテムタイプとRSCおよびそれらの容量を使用して初期化されたグラフから開始する(S1010)。リクエスト可能なセットcごとに、予約リクエストが受け入れられた場合、リクエスト可能なセットの予約の数qと等しい容量を有するソースノードsからノード(c)(cに対応するノード)へのアークを作成することによって、グラフが受け入れた予約で更新される。(S1020)。

予約済みのすべてのリクエスト可能なセットが処理されると、プロセスは終了する(S1030)。

図11は、図4に示されるように予約データで更新された後の、図9の例示的なグラフと対応する容量マトリックスを示している。ノードsから始まるアークは予約リクエストを表し、それらのアークは、アークが終了するリクエスト可能な特性のセットの予約リクエストの数に等しい容量を有する。
予約データ:

予約は特性LF&CV、HF&OV、LF&OVに対応し、それぞれアイテムタイプP1、P2、P3に対応する。予約リクエストcごとに、cの予約の数に等しい容量を有するノードsからノード(c)へのアークが作成され、アーク(s-P1)は45の容量を有し、アーク(s-P2)は18の容量を有し、アーク(s-P3)は28の容量を有する。

図12は、リクエスト可能な特性cのセットの利用可能性を計算し、別の利用可能性計算のためにグラフを正しい状態にするステップを示している。リクエスト可能な特性cのセットは、任意のアイテムタイプまたは任意のRSCであってよい。
・第1に、図11で説明したように、アイテムタイプ、RSC、および受け入れられた予約リクエスト(S1)でグラフが構築される(S1200)。

利用可能性計算用のグラフを準備するために、ソースノードsとターゲットノードtとの間の最大フローが計算され、逆フローが容量マトリックスに記憶される(S1210)。2つのノードを接続するパスは、1つまたは複数の個別のアークで構成され得、各アークはゼロより大きい容量を有する。パスの容量は、そのパスを構成するすべてのアークの最小容量である。フローをパス上の値fだけ増加させることは、パスを構成する各アーク上の値fだけフローを増加させることを意味する。アーク上で増加したフローは、アークの容量を超えることはできない。接続されたノードa-b-c間のパス上のフローが値fだけ増加すると、アークa-bおよびb-c上の容量は値fだけ減少する。容量マトリックスでは、2つの接続されたノードaとbとの間で値fだけフローを増加させることは、値(matrix[a][b])を値「f」だけ減少させる、すなわち動作
matrix[a][b]=matrix[a][b]-f
を実行することを意味し、逆フローを追加することは、値(matrix[b][a])を値「f」だけ増分すること、すなわち動作
matrix[b][a]=matrix[b][a]+f
を実行することを意味する。

これは次のように行われる。ソースノードsからターゲットノードtへのパスがある場合、パス上のフローが増加し、逆フローがグラフに追加され(破線で)、容量マトリックスに記憶される。

逆フロー値は、最大フローアルゴリズムが実行されたときにフローが増加したパスを示す。アーク上で値fだけフローを増加させると、値fの対応する逆フローが逆アークの容量に追加される。逆フロー値は、アーク上で実際に増加したフローの量を示し、必要に応じてこのフローを元に戻すことができるように値が保持される。以下でさらに説明するように、2つのノード間の代替パスを見つけるための最大フローアルゴリズム内で、または次の利用可能性値を計算するためにグラフを正しい状態に戻して利用可能性値を計算した後のいずれかの2つの場合に、元に戻す必要があり得る。

図13および図16(ホテル)、ならびに図21aおよび図24a(航空機)は、S1210を示している。破線は逆フローを示している。
・cの利用可能性を計算するために、ノード(c)からターゲットノードtへの反復最大フローが実行され、作成された増分フローfが測定される(S1220)。これは次のように行われる。ノード(c)とターゲットノードtとの間にパスが存在する間、パス上のフローが増加される。ノード(c)からターゲットノードtに追加された増分フローが計算され、その結果、図14および図17(ホテル)、ならびに図22aおよび図25a(航空機)に示されるように、c:fが利用可能になる。
・計算する他の利用可能性がある場合、グラフをcの利用可能性を計算する前の状態と同等の状態に戻す必要がある。増分フローは、ターゲットノードtとノード(c)との間の反復境界フローを実行することによって元に戻る。増加したフローは、値fによって制限される。これは次のように行われる。fが0より大きい間、
- ターゲットノードtから容量xを有するノード(c)へのパスが取得され、値y=最小(f、x)を有するこのパス上のフローが増加される(S1230)
- fはyだけ減少する(S1235)。

図18(ホテル)と図26a(航空機)の例は、このプロセスを示している。

したがって、グラフは、リクエスト可能な特性cのセットの利用可能性計算の前の状態と同等の状態に戻り、ステップS1220を実行する、すなわち、別の特性のセットの利用可能性を計算する準備ができる。リクエスト可能なすべての特性のセットの利用可能性が計算されると、プロセスが終了し(S1240)、利用可能性値がショッピングキャッシュシステムに送信される。

図13は、ノードsからノードtへの最大フローアルゴリズムを実行し、逆フロー(グラフ上の破線によって示される)を容量マトリックスに記憶した(S1210)後の、図11の例示的なグラフおよび対応する容量マトリックスを示す。ソースノードsからターゲットノードtへのパスがあるが、フローはパスの容量までパス上で増加する。
- パスs-P1-tの場合:
容量アーク(s-P1)=45、容量アーク(P1、t)=50
→容量パス:最小(容量アーク(s-P1)、容量アーク(P1、t))=45
パス上のフローを増加させると、次の結果になる。
容量アーク(s-P1)=0、容量アーク(P1、t)=5。
アーク(s-P1)が消え、アーク(P1、t)の容量が5になる。容量マトリックスにおける対応する値が更新され、マトリックス[s][P1]=0、マトリックス[P1][t]=5である。
逆フローがグラフに破線で追加される。
容量(t-P1)=45、容量(P1-s)=45。
容量マトリックスにおける対応する値が更新され、マトリックス[t][P1]=45、マトリックス[P1][s]=45である。
- パスs-P2-tの場合:
容量アーク(s-P2)=18、容量アーク(P2、t)=20
→容量パス:最小(容量アーク(s-P2)、容量アーク(P2、t))=18。
パス上のフローを増加させると、次の結果になる。
容量アーク(s-P2)=0、容量アーク(P1、t)=2。
アーク(s-P2)が消え、アーク(P2、t)の容量が2になる。容量マトリックスにおける対応する値が更新され、マトリックス[s][P2]=0、マトリックス[P2][t]=2である。
逆フローがグラフに破線で追加される。
容量(t-P2)=18、容量(P2-s)=18。
容量マトリックスにおける対応する値が更新され、マトリックス[t][P2]=18、マトリックス[P2][s]=18である。
- パスs-P3-tの場合:
容量アーク(s-P3)=28、容量アーク(P3、t)=30
→容量パス:最小(容量アーク(s-P3)、容量アーク(P3、t))=28
パス上のフローを増加させると、次の結果になる。
容量アーク(s-P3)=0、容量アーク(P3、t)=2。
アーク(s-P3)が消え、アーク(P3、t)の容量が2になる。容量マトリックスにおける対応する値が更新され、マトリックス[s][P3]=、マトリックス[P3][t]=2である。
逆フローがグラフに破線で追加される。
容量(t-P3)=28、容量(P3-s)=28。
容量マトリックスにおける対応する値が更新され、マトリックス[t][P3]=28、マトリックス[P3][s]=28である。
受け入れられた予約の数に対応する最大フローは91である。現在、グラフと容量マトリックスは、初期利用可能性と受け入れられた予約を考慮して、リクエスト可能な特性c(OVまたはLF)のセットの利用可能性の計算を可能にする状態である。

図14は、図13の例示的なグラフと、リクエスト可能な特性OVのセットの利用可能性を計算した後の対応する容量マトリックスとを示している。OVの利用可能性を計算するために、ノードOVとノードtとの間の反復最大フローが実行される(図12のS1220)。OVとtの間に、すなわちP2とP3を介した2つのパスがある。
パスOV-P2-tの場合:
容量アーク(OV-P2)=20、容量アーク(P2、t)=2
→容量パス:最小(容量アーク(OV-P2)、容量アーク(P2、t))=2。
パス上のフローを増加させると、次の結果になる。
容量アーク(OV-P2)=20-2=18、容量アーク(P2、t)=2-2=0。
アークの容量(OV-P2)は18になり、アーク(P2、t)は消える。容量マトリックスにおける対応する値が更新され、マトリックス[OV][P2]=18、マトリックス[P2][t]=0。
パスOV-P3-tの場合:
容量アーク(OV-P3)=30、容量アーク(P3、t)=2
→容量パス:最小(容量アーク(OV-P3)、容量アーク(P3、t))=2。
パス上のフローを増加させると、次の結果になる。
容量アーク(OV-P3)=30-2=28、容量アーク(P3、t)=2-2=0。
アークの容量(OV-P3)は28になり、アーク(P3、t)は消える。容量マトリックスにおける対応する値が更新され、マトリックス[OV][P3]28、マトリックス[P3][t]=0である。
結果として得られるノード(OV)とターゲットノードtとの間の合計フローは、OVの利用可能性に対応し、4である。ターゲットノードtとノード(OV)との間の逆フローは、破線でグラフ上に表され、容量マトリックスに記憶される。
パスt-P2-OVの場合:
- マトリックス[t][P2]は2だけ増分される:18+2=20。
- マトリックス[P2][OV]は2だけ増分される:0+2=2。
OVの利用可能性の計算の前に、18個のP2の予約が受け入れられた。OVの予約リクエストは、P2によって提供されるサイズ2の残余容量を使用することができる。
パスt-P3-OVの場合:
- マトリックス[t][P3]は2だけ増分される:28+2=30。
- マトリックス[P3][OV]は2だけ増分される:0+2=2。
OVの利用可能性計算の前に、28個のP3の予約が受け入れられた。OVの予約リクエストは、P3によって提供されるサイズ2の残余容量を使用することができる。

図15は、図11の例示的なグラフと、2つのオーシャンビュールームの予約が受け入れられた後の対応する容量マトリックスを示している。リクエストされた人数に等しい容量2を有するソースノードsからノード(OV)へのアークが作成される。容量マトリックスが更新され、マトリックス[s][OV]=2である。

図16は、図15の例示的なグラフと、新しく受け入れられた予約リクエスト2OVを考慮して、容量マトリックスにおける逆フローを追加する、ソースノードsからターゲットノードtに最大フローアルゴリズム(図12のステップS1210)を実行した後の対応する容量マトリックスを示している。受け入れられた予約の数に対応する最大フローは93と等しい。グラフは現在、初期利用可能性と、2つのオーシャンビュールームの新しい予約を含む受け入れられた予約を考慮して、リクエスト可能な特性のセットの利用可能性の計算が可能な状態である。リクエスト可能な特性cのセットの利用可能性を計算するために、ノード(c)とターゲットノードtとの間の反復最大フローが計算される。その後、フローは元に戻され、グラフは利用可能性計算前の状態と同等の状態になる。この計算はすべてのノード(c)に対して行われ、このようにして得られた利用可能性は利用可能性キャッシュシステム140に送信される。プロセスは図13の例において詳細に説明される。当業者は、図13において説明したステップを図15のグラフおよび容量マトリックスに適用することによって、図16のグラフおよび容量マトリックスを容易に得ることができるであろう。

図17は、リクエスト可能な特性OVのサブセットの利用可能性を計算した後(図12のステップS1220)の、図16の例示的なグラフおよび対応する容量マトリックスを示している。OVの利用可能性を計算するために、ノード(OV)とターゲットノードtとの間の反復最大フローが実行される。図16におけるノード(OV)とターゲットノードtとの間には、容量2を有する、ノード(P3)を介する可能なパスが1つだけある。ノード(OV)とターゲットノードtとの間の最大フローは、OVの利用可能性を表し、2に等しい。逆フローが容量マトリックスに追加される。マトリックス[t][P3]は2:28+2=30だけ増分され、マトリックス[P3][OV]は2:0+2=30だけ増分される。このプロセスは図14の例において詳細に説明されており、必要な変更を加えて図17に適用する。

図18は、図17の例示的なグラフと、図12におけるステップS1230およびS1235のループが実行された後の対応する容量マトリックスを示し、グラフおよび容量マトリックスをOVの利用可能性計算前の状態と同等の状態に戻し、別の特性セットの利用可能性計算を可能にする。これは、OV(2)の利用可能性によって制限された反復最大フローアルゴリズムを実行することによって行われる。ターゲットノードtからノード(OV)への2つの可能なパスがあり、両方とも容量2である。ターゲットノードtからノード(P3)を介してノード(OV)へのパスのフローがパスの容量まで増加する場合、グラフは、図16とまったく同じ状態Aになる。
パスt-P3-OVの場合:
容量アーク(t-P3)=30、容量アーク(P3、OV)=2
→容量パス:最小(容量アーク(t-P3)、容量アーク(P3、OV))=2。
パス上のフローを増加させると、次の結果になる。
容量アーク(t-P3)=30-2=28、容量アーク(P3、OV)=2-2=0。
アークの容量(t-P3)は28になり、アーク(P3、OV)は消える。容量マトリックスにおける対応する値が更新され、マトリックス[t][P3]28、マトリックス[P3][OV]=0である。
一方、ターゲットノードtからノード(P2)を介してノード(OV)に至るパスの場合、図18に示されるように、グラフは図16とは少し異なる状態Bになる。
パスt-P2-OVの場合:
容量アーク(t-P2)=20、容量アーク(P2、OV)=2
→容量パス:最小(容量アーク(t-P2)、容量アーク(P2、OV))=2。
パス上のフローを増加させると、次の結果になる。
容量アーク(t-P2)=20-2=18、容量アーク(P2、OV)=2-2=0。
アークの容量(t-P2)は18になり、アーク(P2、OV)は消える。容量マトリックスにおける対応する値が更新され、マトリックス[t][P2]=18、マトリックス[P2][OV]=0である。
グラフと容量のマトリックスは、図16に示されているものとは異なるが、図16の状態Aと同等である。特性のセットの利用可能性計算では、グラフが状態AでもBでも同じ数になる。

図19aは、図6からの構成データで初期化された例示的なグラフを示している。
構成データ:

この例は、図9に示される例と同等であり、当業者は、図7において説明したステップに従うことによって、本明細書に示されるグラフと対応する容量マトリックス(図19b)を取得することができる。

図19bは、図19aのグラフに対応する容量マトリックスを示している。

図20aは、受け入れられた予約で更新された図19aの例示的なグラフを示している。
予約データ:

この例は、図11に示される例と同等であり、当業者は、図11において説明したステップに従うことによって、本明細書に示されるグラフと対応する容量マトリックス(図20b)を取得することができる。

図20bは、図20aのグラフに対応する容量マトリックスを示している。

図21aは、ソースノードsからターゲットノードtへの最大フローアルゴリズムを実行し、容量マトリックスに逆フローを記憶した後の図20aの例示的なグラフを示している。グラフは現在、初期利用可能性と受け入れられた予約を考慮して、リクエスト可能な特性のセットの利用可能性の計算が可能な状態である。このプロセスは、図13の例において詳細に説明される。当業者は、図13において説明したステップを図15のグラフおよび容量マトリックスに適用することによって、図16のグラフおよび容量マトリックスを容易に得ることができるであろう。

図21bは、図21aのグラフに対応する容量マトリックスを示している。

図22aは、出発時刻が不明の、所与の日付のプレミアムエコノミーにおけるフライトNCE-MADに対応する、リクエスト可能な特性Wのサブセットの利用可能性を計算した後の図21aの例示的なグラフを示している。ノード(W)とターゲットノードtとの間の反復最大フローは、Wの利用可能性を計算するために実行される。ノード(W)からノード(F1W)を介してターゲットノードtへのフローは2である。ノード(W)からノード(F2W)を介してターゲットノードtへのフローは7である。結果として得られるノード(W)とターゲットノードtとの間の合計フローは、Wの利用可能性に対応し、9である。容量マトリックスには、ターゲットノードtとノード(W)との間の逆フローが記憶される。パスt-F1W-Wの場合:マトリックス[t][F1W]は2(33+2=35)だけ増分され、マトリックス[F1W][W]は2(0+2=2)だけ増分される。パスt-F2W-Wの場合、マトリックス[t][F2W]は7(28+7=35)だけ増分され、マトリックス[F2W][W]は7(0+7=7)だけ増分される。このプロセスは図14の例において詳細に説明されており、必要な変更を加えて図22aに適用する。

図22bは、図22aのグラフに対応する容量マトリックスを示している。

図23aは、人数2のWの予約が受け入れられた後の図19aの例示的なグラフを示している。リクエストされた人数2に等しい容量を有するソースノードsからノード(W)へのアークが作成される。

図23bは、図23aのグラフに対応する容量マトリックスを示している。容量マトリックスが更新され、マトリックス[s][W]=2である。

図24aは、ソースノードsからターゲットノードtへの最大フローアルゴリズムを実行し、容量マトリックスに逆フローを記憶した後の図23aの例示的なグラフを示している。グラフは現在、初期利用可能性と2つのW(出発時刻は不明の、所与の日付のプレミアムエコノミーのNCE-MADを2便)の新しい予約を含む受け入れられた予約を考慮して、リクエスト可能な特性のセットの利用可能性の計算が可能な状態である。このプロセスは、図13の例において詳細に説明される。当業者は、図13において説明したステップを図23a のグラフおよび図23bの容量マトリックスに適用することによって、図24aのグラフおよび図24bの容量マトリックスを容易に得ることができるであろう。

図24bは、図24aのグラフに対応する容量マトリックスを示している。

図25aは、出発時刻が不明の、所与の日付のプレミアムエコノミーにおけるフライトNCE-MADに対応する、リクエスト可能な特性Wのサブセットの利用可能性を計算した後の図24aの例示的なグラフを示している。
ノード(W)とターゲットノードtとの間の反復最大フローは、Wの利用可能性を計算するために実行される。ノード(W)からターゲットノードtへ、すなわちノード(F2W)を解するパスは1つしかない。ノード(W)からノード(F2W)を介してターゲットノードtへのフローは7であり、Wの利用可能性に対応する。容量マトリックスでは、tとWとの間の逆フローが記憶され、マトリックス[t][F2W]が7(28+7=35)だけ増分され、マトリックス[F2W][W]は7(0+7=7)だけ増分される。このプロセスは図14の例において詳細に説明されており、必要な変更を加えて図25aに適用する。

図25bは、図25aのグラフに対応する容量マトリックスを示している。

図26aは、Wの利用可能性計算前の状態と同等の状態に戻された後の図25aの例示的なグラフを示している。これは、W(7)の利用可能性によって制限された反復最大フローアルゴリズムを実行することによって行われる。ターゲットノードtからノード(W)へは、すなわちノード(F1W)(容量2)とノード(F2W)(容量7)を介する2つの可能なパスがある。ノード(F2W)を介するパスのフローがパスの容量まで増加すると、グラフは図24aとまったく同じ状態Aになる。ノード(F1W)を介するパスのフローが第1に増加し(2)、その後ノード(F2W)を介するパスのフローが(部分的に)増加した場合(7-2=5を上限とする)、グラフは図24aとはわずかに異なる状態Bになるが、状態Aと同等である。特性のセットの利用可能性計算では、グラフが状態AでもBでも同じ数になる。このプロセスは図18の例において詳細に説明されており、必要な変更を加えて図26aに適用する。

図26bは、図26aのグラフに対応する容量マトリックスを示している。

次に図27を参照すると、本明細書で説明されるシステム、プラットフォーム、モジュール、ユニットなどは、例示的なコンピュータシステム26などの1つまたは複数のコンピューティングデバイスまたはシステム上で実装され得る。コンピュータシステム26は、プロセッサ28、メモリ30、大容量ストレージメモリデバイス32、入力/出力(I/O)インターフェース34、およびヒューマンマシンインターフェース(HMI)36を含み得る。コンピュータシステム26はまた、ネットワーク115またはI/Oインターフェース34を介して1つまたは複数の外部リソース38に動作可能に結合し得る。外部リソースは、これらに限定されないが、サーバ、データベース、大容量記憶デバイス、周辺デバイス、クラウドベースのネットワークサービス、またはコンピュータシステム26によって使用され得る任意の他の適切なコンピュータリソースを含み得る。

プロセッサ28は、マイクロプロセッサ、マイクロコントローラ、デジタル信号プロセッサ、マイクロコンピュータ、中央処理装置、フィールドプログラマブルゲートアレイ、プログラマブルロジックデバイス、ステートマシン、ロジック回路、アナログ回路、デジタル回路、またはメモリ30に記憶されている動作命令に基づいて信号(アナログまたはデジタル)を操作する任意の他のデバイスから選択された1つまたは複数のデバイスを含み得る。メモリ30は、これらに限定されないが、読取り専用メモリ(ROM)、ランダムアクセスメモリ(RAM)、揮発性メモリ、不揮発性メモリ、スタティックランダムアクセスメモリ(SRAM)、ダイナミックランダムアクセスメモリ(DRAM)、フラッシュメモリ、キャッシュメモリ、または情報を記憶できる任意の他のデバイスを含む、単一のメモリデバイスまたは複数のメモリデバイスを含み得る。大容量ストレージメモリデバイス32は、ハードドライブ、光学ドライブ、テープドライブ、不揮発性ソリッドステートデバイス、または情報を格納できる他のデバイスなどのデータストレージデバイスを含むことができる。

プロセッサ28は、メモリ30に常駐するオペレーティングシステム40の制御下で動作し得る。オペレーティングシステム40は、メモリ30に常駐するアプリケーション42などの1つまたは複数のコンピュータソフトウェアアプリケーションとして具現化されるコンピュータプログラムコードが、プロセッサ28によって実行される命令を有し得るようにコンピュータリソースを管理し得る。代替実施形態では、プロセッサ28は、アプリケーション42を直接実行し得、その場合、オペレーティングシステム40は省略され得る。1つまたは複数のデータ構造44もメモリ30に常駐し得、データを格納または操作するために、プロセッサ28、オペレーティングシステム40、またはアプリケーション42によって使用され得る。

I/Oインターフェース34は、プロセッサ28を、ネットワーク115または外部リソース38などの他のデバイスおよびシステムに動作可能に結合するマシンインターフェースを提供し得る。それによって、アプリケーション42は、本発明の実施形態を備える様々な特徴、機能、アプリケーション、プロセス、またはモジュールを提供するために、I/Oインターフェース34を介して通信することによってネットワーク115または外部リソース38と協働し得る。アプリケーション42はまた、1つまたは複数の外部リソース38によって実行されるプログラムコードを有してもよく、他のシステムまたはコンピュータシステム26の外部のネットワーク構成要素によって提供される機能または信号に依存してもよい。実際、ほぼ無限のハードウェアおよびソフトウェア構成が可能なことを考えると、当業者は、本発明の実施形態が、コンピュータシステム26の外部に配置されるか、複数のコンピュータまたは他の外部リソース38に分散されるか、クラウドコンピューティングサービスなどのネットワーク115を介してサービスとして提供されるコンピューティングリソース(ハードウェアおよびソフトウェア)によって提供されるアプリケーションを含み得ることを理解するであろう。

HMI36は、ユーザがコンピュータシステム26と直接対話することを可能にする、知られている方法でコンピュータシステム26のプロセッサ28に動作可能に結合され得る。HMI36は、ビデオまたは英数字ディスプレイ、タッチスクリーン、スピーカ、およびユーザにデータを提供することができる任意の他の適切な音声および視覚インジケータを含み得る。HMI36はまた、ユーザからのコマンドまたは入力を受け入れ、入力された入力をプロセッサ28に送信することができる、英数字キーボード、ポインティングデバイス、キーパッド、押しボタン、制御ノブ、マイクなどの入力デバイスおよび制御を含み得る。

データベース46は、大容量ストレージメモリデバイス32上に常駐し得、本明細書で説明する様々なシステムおよびモジュールによって使用されるデータを収集および編成するために使用され得る。データベース46は、データと、データを記憶および編成するサポートデータ構造とを含み得る。具体的には、データベース46は、これらに限定されないが、リレーショナルデータベース、階層データベース、ネットワークデータベース、またはそれらの組合せを含むが任意のデータベース編成または構造で配置されてもよい。クエリに応じてデータベース46の記録に記憶された情報またはデータにアクセスするために、プロセッサ28上の命令として実行するコンピュータソフトウェアアプリケーションの形態のデータベース管理システムが使用され得、クエリは、オペレーティングシステム40、他のアプリケーション42、あるいは1つまたは複数のモジュールによって、動的に決定および実行され得る。

一般に、本発明の実施形態を実装するために実行されるルーチンは、オペレーティングシステムまたは特定のアプリケーション、構成要素、プログラム、オブジェクト、モジュールまたは命令のシーケンス、あるいはそのサブセットの一部として実装されるかどうかにかかわらず、本明細書で「コンピュータプログラムコード」または単に「プログラムコード」と呼ばれ得る。プログラムコードは通常、コンピュータの様々なメモリおよびストレージデバイスに様々な時点で常駐し、コンピュータの1つまたは複数のプロセッサによって読み取られて実行されると、コンピュータに、本発明の実施形態の様々な態様を具体化する動作および/または要素を実行するために必要な動作を実行させるコンピュータ可読命令を備える。本発明の実施形態の動作を実行するためのコンピュータ可読プログラム命令は、たとえば、アセンブリ言語または1つまたは複数のプログラミング言語の任意の組合せで書かれたソースコードまたはオブジェクトコードのいずれかであり得る。

本明細書に記載された様々なプログラムコードは、本発明の特定の実施形態においてそれが実装されるアプリケーションに基づいて識別され得る。しかしながら、以下の任意の特定のプログラム命名法は単に便宜上使用されるものであり、したがって、本発明の実施形態は、そのような命名法によって識別および/または含意される任意の特定のアプリケーションのみにおける使用に限定されるべきではないことを理解されるべきである。さらに、コンピュータプログラムがルーチン、プロシージャ、メソッド、モジュール、オブジェクトなどに編成され得る一般に無数の方法、ならびにプログラムの機能が典型的なコンピュータ(たとえば、オペレーティングシステム、ライブラリ、API、アプリケーション、アプレットなど)内に常駐する様々なソフトウェアレイヤに割り振られ得る様々な方法を考えると、本発明の実施形態は、本明細書で説明するプログラム機能の特定の編成および割振りに限定されないことを理解されるべきである。

本明細書で説明するアプリケーション/モジュールのいずれかにおいて具体化されるプログラムコードは、様々な異なる形式のプログラム製品として個別にまたは集合的に配布することができる。具体的には、プログラムコードは、プロセッサに本発明の実施形態の態様を実行させるためのコンピュータ可読プログラム命令を有するコンピュータ可読ストレージ媒体を使用して配布され得る。

本質的に一時的ではないコンピュータ可読ストレージ媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータなどの情報を保存するための任意の方法または技術で実装された揮発性および不揮発性、リムーバブルおよび非リムーバブルの有形メディアを含み得る。コンピュータ可読ストレージ媒体は、ランダムアクセスメモリ(RAM)、読取り専用メモリ(ROM)、消去可能プログラマブル読取り専用メモリ(EPROM)、電気的消去可能プログラマブル読取り専用メモリ(EEPROM)、フラッシュメモリ、または他のソリッドステートメモリ技術、ポータブルコンパクトディスク読取り専用メモリ(CD-ROM)、あるいは他の光学ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気ストレージデバイス、あるいは目的の情報を記憶するために使用することができ、コンピュータによって読むことができる任意の他の媒体をさらに含み得る。コンピュータ可読ストレージ媒体は、一時的な信号自体(たとえば、電波または他の伝播電磁波、導波管などの伝送媒体を通じて伝播する電磁波、またはワイヤを通じて送信される電気信号)として解釈されるべきではない。コンピュータ可読プログラム命令は、コンピュータ可読ストレージ媒体からコンピュータ、別のタイプのプログラマブルデータ処理装置、または別のデバイスに、あるいはネットワークを介して外部コンピュータまたは外部ストレージデバイスにダウンロードされ得る。

コンピュータ可読媒体に記憶されたコンピュータ可読プログラム命令は、コンピュータ、他のタイプのプログラム可能なデータ処理装置、または他のデバイスを特定の方法で機能させるために使用され得、その結果、コンピュータ可読媒体に記憶された命令は、フローチャート、シーケンス図、および/またはブロック図において指定された機能、行為、および/または操動作を実装する命令を含む製品を生成する。コンピュータプログラム命令は、1つまたは複数のプロセッサを介して実行される命令により、フローチャート、シーケンス図、および/またはブロック図において指定された機能、行為、および/または動作を実装するための一連の計算が実行されるようなマシンを生成するために、汎用コンピュータ、専用コンピュータ、または他のプログラム可能なデータ処理装置の1つまたは複数のプロセッサに提供され得る。

特定の代替実施形態では、フローチャート、シーケンス図、および/またはブロック図において指定された機能、行為、および/または動作は、本発明の実施形態と一致して、再順序付け、連続処理、および/または同時に処理することができる。さらに、フローチャート、シーケンス図、および/またはブロック図のいずれも、本発明の実施形態と一致して示されているものよりも多数または少数のブロックを含み得る。

本明細書で使用される用語は、特定の実施形態のみを説明するためのものであり、本発明の実施形態を限定することを意図するものではない。本明細書で使用される単数形「a」、「an」、および「the」は、文脈がそうでないことを明確に示さない限り、複数形も含むことを意図している。本明細書で使用される場合、用語「備える(comprises)」および/または「備えている(comprising)」は、述べられた特徴、整数、ステップ、動作、要素、および/または構成要素の存在を指定するが、1つまたは複数の他の機能、整数、ステップ、動作、要素、構成要素、および/またはそれらのグループの存在または追加を排除しないことをさらに理解されよう。さらに、用語「含む(includes)」、「有している(having)」、「有する(has)」、「有する(with)」、「からなる(comprised of)」、またはそれらの変形が詳細な説明または特許請求の範囲において使用される限り、そのような用語は、「備えている(comprising)」という用語と同様の方法で包括的であることを意図する。

本発明は様々な実施形態の説明によって例示され、これらの実施形態はかなり詳細に説明されたが、添付の特許請求の範囲をそのような詳細に制限または何らかの方法で制限することは出願人の意図ではない。追加の利点および修正は、当業者には容易に明らかになるであろう。したがって、本発明は、そのより広い態様において、特定の詳細、代表的な装置および方法、ならびに示され説明された例示的な例に限定されない。したがって、出願人の一般的な発明概念の趣旨または範囲から逸脱することなしに、そのような詳細から逸脱することができる。

26 コンピュータシステム
28 プロセッサ
30 メモリ
32 大容量ストレージメモリデバイス
34 入力/出力(I/O)インターフェース
36 ヒューマンマシンインターフェース(HMI)
38 外部リソース
40 オペレーティングシステム
42 アプリケーション
44 データ構造
46 データベース
100 中央予約システム
105 クライアントシステム
110 管理ポータル
115 ネットワーク
120 予約システム
125 予約データベース
130 構成システム
135 構成データベース
140 利用可能性キャッシュシステム
145 キャッシュメモリ
200 予約モジュール
210 価格設定モジュール
220 利用可能性モジュール

Claims (15)

1. 複数のアイテムタイプに分類されるアイテムの在庫に対応する予約リクエストをハンドリングする方法であって、各アイテムは、前記複数のアイテムタイプの１つを備え、各アイテムタイプは、それぞれの特性のセットにより定義され、前記方法は、
   サーバにおいて、構成システムから、あらかじめ定められたリストを受信するステップであって、前記リストは、
   (i) 特性のセット、
   (ii) 特性の部分的なセット、
   (iii) 特性の各セットおよび特性の部分的な各セットに対応するアイテムのそれぞれの在庫数であって、前記特性の部分的な各セットは、特定のアイテムタイプを定義する所定の特性のセットよりも少ない特性を含み、前記特性の部分的な各セットは、前記複数のアイテムタイプの１つ以上に対応する、在庫数、
   を定める、受信するステップと、
   前記サーバにおいて、前記あらかじめ定められたリストに基づいて、初期利用可能性を生成するステップであって、前記初期利用可能性を生成するステップは、前記サーバにおいて、
   (i) ソースノード、
   (ii) ターゲットノード、
   (iii) 前記特性のセットのそれぞれに対応するそれぞれのアイテムタイプノード、
   (iv) 前記特性の部分的なセットのそれぞれに対応するそれぞれの部分的なセットノード、
   を含むグラフを構築するステップと、
   各アイテムタイプノードに対し、前記アイテムタイプノードから前記ターゲットノードへのアイテムタイプアークを作成し、前記アイテムタイプを定義する前記特性のセットに対応する在庫数に等しい前記アイテムタイプアークに関連する容量を格納するステップと、
   各部分的なセットノードに対し、前記特性の部分的なセットにより定義された前記複数のアイテムタイプの１つに対応する、前記部分的なセットノードから各アイテムタイプノードへの部分的なセットアークを生成し、前記特性の部分的なセットに対応する前記在庫数に合計される前記部分的なセットアークに関連するそれぞれの容量を格納するステップと、
   を含む、生成するステップと、
   前記初期利用可能性に基づいて、前記サーバのキャッシュメモリ内にデータ構造を構築するステップと、
   前記サーバにおいて、(i) 特性の各セット、および(ii) 特性の部分的な各セットに対する既存の予約の記録を取得するステップと、
   前記サーバにおいて、前記既存の予約の記録に基づいて、前記データ構造を更新して、(i) 特性の各セット、および(ii) 特性の部分的な各セットに対する更新された利用可能性を反映するステップと、
   前記サーバにおいて、クライアントコンピューティングデバイスから、選択された特性のサブセットを含む予約リクエストを受信するステップと、
   前記サーバにおいて、前記データ構造を使用して前記予約リクエストを収容できるかどうかを決定するステップと、
   前記予約リクエストに対応するために、前記複数のアイテムタイプのうち特定のアイテムタイプを前記予約リクエストに割り当てることなく、前記予約リクエストに従って前記既存の予約の記録を更新するステップと、
   を具備することを特徴とする方法。
2. 前記クライアントコンピューティングデバイスに関連して、前記予約リクエストを受理した後に、アイテム割り当てリクエストを受信するステップと、
   前記選択された特性のサブセットを満たす前記アイテムの１つを割り当てるステップと、
   をさらに具備することを特徴とする請求項１に記載の方法。
3. 前記特性の各セット、および前記特性の部分的な各セットは、前記クライアントコンピューティングデバイスで選択可能であることを特徴とする請求項１に記載の方法。
4. 前記既存の予約の記録は、前記特性のセット、前記特性の部分的なセットの少なくとも１つに対応する予約カウントを定義し、前記更新された利用可能性を生成するステップは、前記サーバにおいて、
   前記ソースノードから前記対応するアイテムタイプノードのそれぞれおよび予約カウントが存在する部分セットノードへの予約アークを作成し、前記予約カウントの対応する1つに等しい前記予約アークに関連する容量を、格納するステップと、
   前記ソースノードから前記ターゲットノードへの最大フロー動作を実行して、最大フローを生成するステップと、
   前記最大フローに対応する逆フローを前記グラフに追加するステップと、
   前記アイテムタイプノードの各々と前記部分的なセットノードの各々に対して、前記アイテムタイプノードおよび前記部分的なセットノードの現在のノードから前記ターゲットノードへの反復最大フロー動作を実行するステップであって、
   前記現在のノードと前記ターゲットノードの間に残っている各パスに対し、前記パス上のフローを増加させることと、
   前記パスのそれぞれに対応するフローを合計して、前記現在のノードの更新された利用可用性を生成すること
   により実行する、実行するステップと、
   を具備することを特徴とする請求項１に記載の方法。
5. 前記容量を格納するステップは、
   各容量を、対応するアークのパラメータとして格納するステップ、
   各容量を、対応するノードのパラメータとして格納するステップ、
   のいずれかを具備することを特徴とする請求項１に記載の方法。
6. 前記グラフを、前記サーバの前記キャッシュメモリ内に容量マトリックスとして格納するステップをさらに具備することを特徴とする請求項１に記載の方法。
7. 前記アイテムは、予約可能なホテルの部屋、予約可能なフライトの場所、の少なくとも1つを含むことを特徴とする請求項１に記載の方法。
8. 複数のアイテムタイプに分類されるアイテムの在庫に対応する予約リクエストをハンドリングするサーバであって、各アイテムは、前記複数のアイテムタイプの１つを備え、各アイテムタイプは、それぞれの特性のセットにより定義され、前記サーバは、
   メモリと、
   前記メモリに相互接続されたプロセッサと、
   を具備し、前記プロセッサは、
   あらかじめ定められたリストを受信し、前記リストは、
   (i) 特性のセット、
   (ii) 特性の部分的なセット、
   (iii) 特性の各セットおよび特性の部分的な各セットに対応するアイテムのそれぞれの在庫数であって、前記特性の部分的な各セットは、特定のアイテムタイプを定義する所定の特性のセットよりも少ない特性を含み、前記特性の部分的な各セットは、前記複数のアイテムタイプの１つ以上に対応する、在庫数、
   を定め、
   前記あらかじめ定められたリストに基づいて、初期利用可能性を生成し、前記初期利用可能性の生成は、前記サーバにおいて、
   (i) ソースノード、
   (ii) ターゲットノード、
   (iii) 前記特性のセットのそれぞれに対応するそれぞれのアイテムタイプノード、
   (iv) 前記特性の部分的なセットのそれぞれに対応するそれぞれの部分的なセットノード、
   を含むグラフを構築し、
   各アイテムタイプノードに対し、前記アイテムタイプノードから前記ターゲットノードへのアイテムタイプアークを作成し、前記アイテムタイプを定義する前記特性のセットに対応する在庫数に等しい前記アイテムタイプアークに関連する容量を格納し、
   各部分的なセットノードに対し、前記特性の部分的なセットにより定義された前記複数のアイテムタイプの１つに対応する、前記部分的なセットノードから各アイテムタイプノードへの部分的なセットアークを生成し、前記特性の部分的なセットに対応する前記在庫数に合計される前記部分的なセットアークに関連するそれぞれの容量を格納する、
   ことを含み、
   前記初期利用可能性に基づいて、前記サーバのキャッシュメモリ内にデータ構造を構築し、
   (i) 特性の各セット、および(ii) 特性の部分的な各セットに対する既存の予約の記録を取得し、
   前記既存の予約の記録に基づいて、前記データ構造を更新して、(i) 特性の各セット、および(ii) 特性の部分的な各セットに対する更新された利用可能性を反映させ、
   クライアントコンピューティングデバイスから、選択された特性のサブセットを含む予約リクエストを受信し、
   前記データ構造を使用して前記予約リクエストを収容できるかどうかを決定し、
   前記予約リクエストに対応するために、前記複数のアイテムタイプのうち特定のアイテムタイプを前記予約リクエストに割り当てることなく、前記予約リクエストに従って前記既存の予約の記録を更新する
   ように構成されていることを特徴とするサーバ。
9. 前記プロセッサは、
   前記クライアントコンピューティングデバイスに関連して、前記予約リクエストを受理した後に、アイテム割り当てリクエストを受信し、
   前記選択された特性のサブセットを満たす前記アイテムの１つを割り当てる
   ようにさらに構成されていることを特徴とする請求項８に記載のサーバ。
10. 前記特性の各セット、および前記特性の部分的な各セットは、前記クライアントコンピューティングデバイスで選択可能であることを特徴とする請求項８に記載のサーバ。
11. 前記既存の予約の記録は、前記特性のセット、前記特性の部分的なセットの少なくとも１つに対応する予約カウントを定義し、前記プロセッサは、
    前記ソースノードから前記対応するアイテムタイプノードのそれぞれおよび予約カウントが存在する部分セットノードへの予約アークを作成し、前記予約カウントの対応する1つに等しい前記予約アークに関連する容量を、格納することと、
    前記ソースノードから前記ターゲットノードへの最大フロー動作を実行して、最大フローを生成することと、
    前記最大フローに対応する逆フローを前記グラフに追加することと、
    前記アイテムタイプノードの各々と前記部分的なセットノードの各々に対して、前記アイテムタイプノードおよび前記部分的なセットノードの現在のノードから前記ターゲットノードへの反復最大フロー動作を実行することであって、
    前記現在のノードと前記ターゲットノードの間に残っている各パスに対し、前記パス上のフローを増加させ、
    前記パスのそれぞれに対応するフローを合計して、前記現在のノードの更新された利用可用性を生成する
    ことにより実行する、実行することと、
    により前記更新された利用可能性を生成するようにさらに構成されていることを特徴とする請求項８に記載のサーバ。
12. 各容量を、対応するアークのパラメータとして格納するステップ、
    各容量を、対応するノードのパラメータとして格納するステップ、
    のいずれかによって前記容量を格納するようにさらに構成されていることを特徴とする請求項８に記載のサーバ。
13. 前記グラフを、前記キャッシュメモリ内に容量マトリックスとして格納するようにさらに構成されていることを特徴とする請求項８に記載のサーバ。
14. 前記アイテムは、予約可能なホテルの部屋、予約可能なフライトの場所、の少なくとも1つを含むことを特徴とする請求項８に記載のサーバ。
15. 命令を格納する非一時的コンピュータ可読媒体であって、前記命令が複数のアイテムタイプに分類されるアイテムの在庫に対応する予約リクエストをハンドリングし、各アイテムは、前記複数のアイテムタイプの１つを備え、各アイテムタイプは、それぞれの特性のセットにより定義される、コンピューティングデバイスで実行されると
    前記コンピューティングデバイスに、
    あらかじめ定められたリストを受信することであって、前記リストは、
    (i) 特性のセット、
    (ii) 特性の部分的なセット、
    (iii) 特性の各セットおよび特性の部分的な各セットに対応するアイテムのそれぞれの在庫数であって、前記特性の部分的な各セットは、特定のアイテムタイプを定義する所定の特性のセットよりも少ない特性を含み、前記特性の部分的な各セットは、前記複数のアイテムタイプの１つ以上に対応する、在庫数、
    を定める、受信することと、
    前記あらかじめ定められたリストに基づいて、初期利用可能性を生成することであって、前記初期利用可能性を生成することは、前記サーバにおいて、
    (i) ソースノード、
    (ii) ターゲットノード、
    (iii) 前記特性のセットのそれぞれに対応するそれぞれのアイテムタイプノード、
    (iv) 前記特性の部分的なセットのそれぞれに対応するそれぞれの部分的なセットノード、
    を含むグラフを構築することと、
    各アイテムタイプノードに対し、前記アイテムタイプノードから前記ターゲットノードへのアイテムタイプアークを作成し、前記アイテムタイプを定義する前記特性のセットに対応する在庫数に等しい前記アイテムタイプアークに関連する容量を格納することと、
    各部分的なセットノードに対し、前記特性の部分的なセットにより定義された前記複数のアイテムタイプの１つに対応する、前記部分的なセットノードから各アイテムタイプノードへの部分的なセットアークを生成し、前記特性の部分的なセットに対応する前記在庫数に合計される前記部分的なセットアークに関連するそれぞれの容量を格納することと、
    を含む、生成することと、
    前記初期利用可能性に基づいて、前記コンピューティングデバイスのキャッシュメモリ内にデータ構造を構築することと、
    (i) 特性の各セット、および(ii) 特性の部分的な各セットに対する既存の予約の記録を取得することと、
    前記既存の予約の記録に基づいて、前記データ構造を更新して、(i) 特性の各セット、および(ii) 特性の部分的な各セットに対する更新された利用可能性を反映することと、
    クライアントコンピューティングデバイスから、選択された特性のサブセットを含む予約リクエストを受信することと、
    前記データ構造を使用して前記予約リクエストを収容できるかどうかを決定することと、
    前記予約リクエストに対応するために、前記複数のアイテムタイプのうち特定のアイテムタイプを前記予約リクエストに割り当てることなく、前記予約リクエストに従って前記既存の予約の記録を更新することと、
    を行わせることを特徴とする非一時的コンピュータ可読媒体。

Images