JP2014517382A - 繰り返されるサーチリクエストを最適化する改良された予約システムのための方法及びシステム - Google Patents

Abstract

本発明の好適な実施形態による方法は、グローバルディストリビューションシステム（GDS）に対して旅行についての提案をリクエストするエンドユーザに、改良された旅行リクエストサービスを提供する。これは、従来技術における従来の旅行リクエストよりも、各サーチパラメータについて、より広範囲に及ぶ新規な旅行リクエストを用いる。新規な旅行リクエストは同じ旅行リクエスト中に多岐に亘る範囲のパラメータを含むのに対して従来の旅行リクエストは各サーチパラメータに対して各異なるリクエスト値を繰り返させる必要がある。本発明の好適な実施形態による方法は、改良された旅行リクエストサービスを実行するために、マスターモジュールとワーカーモジュールとの２つのモジュールの組合せを提供する。

Description

本発明は予約システムの分野に関するものであり、特に繰り返されるサーチリクエストを最適化するマッシブ計算プラットフォームのための方法及びシステムに関する。

最先端の予約システムは、通常、専用のグローバルディストリビューションシステム（GDS）に基づいており、例としては、フライト予約等のショッピングビジネスのためのフライトサーチアプリケーションを提供する航空会社の予約システムがある。クライアントから来るフライトサーチリクエストには、GDSデータの網羅的サーチを必要とする。これは膨大な量の計算を必要とし、ある程度の時間がかかる。この遅延を最小化するのに、通常クライアントはほとんどの自由度を有していない。即ち、彼らはリクエストする旅行についての出発地及び目的地の都市名、出発及び帰還の日付、営業航空会社、キャビン等級を指定する必要がある。これはシステムパフォーマンス及びレスポンスタイムのためには有利ではあるが、これはパラメータ選択においてより広範囲な自由度を伴うよりユーザフレンドリな対話を明らかに好むであろう顧客にとっては最適ではない。

改良されたユーザリクエストの管理が重宝される、航空会社及び旅行代理業者により開拓された他のビジネスドメインとしては、所謂プレショッピングというものがある。これは、予約システムを通じてデータベースに問い合わせる必要があるも、必ずしも正規の予約をもたらさない活動を意味する。これらの活動は航空会社又は旅行業者にとって極めて重要である。なぜならば、即座にこれらが収益につながらなくとも、潜在的な顧客の将来における選択に影響を与え得るからである。高い自由度を伴うクライアントの問い合わせに対して遅延ゼロの応答を提供することのできるツールは高く重宝されるであろう。例えば、クライアントが、６月から９月の間で、２週間の期間で、日照の良い地へ向かう、パリから出発するフライトの情報をリクエストしていると仮定してみよう。通常のフライトサーチアプリケーションの場合、クライアントは正確な行き先を指定して、希望する行き先及び可能な日付の組合せの数だけのリクエストを行う必要がある。

別の可能なアプリケーションとしては、単にフライト予約を増加させるのではなく、収益性を増加させることを狙った収益管理プロセスを伴う予約システムとすることができる。例：航空会社は、自社の計画中のフライトに係る包括的な価格（例えば、全期間に亘る全都市についてのフライト）の価格に依拠し、並びに予約予測に基づくコンピュータモデルに基づいて自社の価格を適応させることを希望する場合がある。従来のシステムでは、このような取り組みはとても複雑となり、多大なリソース及びオペレータ労力を要することになる。

さらなる他の可能なアプリケーションとしては、静的な目的のための料金分析がある。即ち、GDSに申請された最新情報に基づいて自己のチケット価格の変遷を追跡調査するということである。例：提供された料金及びルールから算定された旅行価格の比較、類似のアイテムについての現在価格と以前の価格との比較、自己の費用見積との比較を通じて申請された価格を評価すること。

上記アプリケーション例に共通の特徴は、該当するフライトレコメンデーションを極めて多量に必要とすることである。例えば、プレショッピングアプリケーションはクライアントに魅力的な結果を提供するために多岐に亘るソリューションを要し、収益管理アプリケーションはそのダイナミックな価格付けポリシーがこのモデルに依存するが故に網羅的なフライトレコメンデーションリストを要し、料金分析アプリケーションは価格変遷を効率的に追跡するために網羅的なフライトレコメンデーションリストを要する。

ショッピングというビジネスドメインとは対照的に、これらのアプリケーションの目的は予約ではない。このため、フライトレコメンデーションを生成するために必要な計算は各クライアントの問い合わせについて行う必要はなく、応答時間の犠牲の上で応答の正確性を求めることができる。フライトレコメンデーションは各クライアント問い合わせについて再計算する必要はないため、GDSによるこれらの事前計算は数時間の期間に広げることができる。また、これらのアプリケーションは事前計算されたフライトレコメンデーションに依存するため、GDSは、そのシステムに入力するのに必要なデータ処理を、数時間の期間に亘って広げることができる。

上記アプリケーションを実施する既知の方法としては所謂トランザクショナルエクスターナルシューター（transactional external shooter）というものがある。プレショッピングシステム又は収益管理システムに対して網羅的にフィードをするために、顧客は一連のトランザクションを、GDSにより提供されるショッピングアプリケーションへシュート（shoot）することができる。シュートすべきトランザクションは、希望される全ての出発日、希望される全てのマーケット等の組合せを包含する必要がある。このような方法は、明白な欠点を有する。例えば、問い合わせの微増が大規模な組合せ論的複雑性の増大をもたらし、顧客がシュートしなければならないトランザクション数が増大する。グローバルリクエストに対応するシュートされたトランザクションは、各トランザクションの計算のために必要な共通パーツを収集する：即ち、重複チェック、重複データアクセス及び重複処理が行われる。計算されるデータがよりハイボリュームであればあるほど、これら重複的な操作の（リソース消費量の観点からの）コストが高くなる。シュートされたアプリケーションが拡張カレンダー又は複数選択肢型選択を提供する場合であっても、シュートすべきトランザクションの全てについてのグローバルな認識が欠けるが故に、最適化の機会は未だ部分的である。顧客にとっては、結果を計算するのにより多くの処理時間が必要となる。GDSにとっては、重複部分の計算について不要なリソース消費が誘発される。さらに、シューターはGDSに対して外部に配置されるので、リソース消費は管理下にない。また、プレショッピング、収益管理又は料金分析のために必要なデータは膨大なので、予期しない大量のトラフィックは他の顧客とのサービスレベルアグリーメント違背の危険をもたらす。

他に知られるプレショッピングシステムを実施する手法としては、ショッピングトラフィックをキャプチャしてシステムを更新するものがある。予約目的のためにクライアントからリクエストされた任意のトランザクションについては、それがプレショッピングシステムの要求を満たす場合、その結果がクライアント及びプレショッピングサーバ双方に返される。この従来技術の欠点は、顧客が計算に使われるデータについて何ら支配を有さないことにある。したがって、結果が網羅的であるとの保証がないため、収益管理システムにフィードすることはできない。さらに、トラフィックをキャプチャすることは静的なアプローチであり、特定的な制約には適用不能である。プレショッピング及び収益管理システムは、既存のプロダクツの特性を利用できるのみである。

強負荷なオペレータ作業及び許容できないリソース消費を必要としないで、上述した高ボリュームデータの実効的な処理を保証するためには、無益な問い合わせの重複を回避しつつマッシブなサーチを行い得る改良された予約システムが必要となろう。

米国特許第5,495,606号は、データベース内でのサーチプロセスを改良する方法を開示する。このシステムは、既存のシステムの処理時間を改善するために従来技術中の既存のシステムに付加することができる。米国特許第5,495,606号は、並列して稼働できる複数の問い合わせ処理モジュールを備えるシステムを開示する。各問い合わせ処理モジュールは、マスター問い合わせプロセッサ及びスレーブプロセッサを備える。マスター問い合わせプロセッサは、問い合わせを受信し、エンドユーザへ応答を送り戻す。マスター問い合わせプロセッサは、問い合わせを複数の既分割問い合わせに分割するための問い合わせスプリッタを有する。また、マスター問い合わせプロセッサは、既分割問い合わせを適切なスレーブプロセッサ上で処理できるようにするためのスケジューラも有する。そして、各スレーブ問い合わせプロセッサは、各既分割問い合わせを特定のデータベース管理モジュールへと送信してデータベースにリードオンリー構成でアクセスする。結果として、全ての既分割問い合わせは、各問い合わせ処理モジュールによって並列に処理されることができ、処理時間は最適化される。データベースはリードオンリー構成にされているため、既分割問い合わせの処理中ではデータベースの更新は行われない；このことにより既分割問い合わせの処理時間が向上する。米国特許第5,495,606号で開示される方法は、複数のプロセッサを有する極めて強力なデータ処理システムを必要とし、サーチリクエストが重複している可能性の問題については解決をもたらさないのであり、システムによって行われるリクエストの最適化を伴わないが故、同じ問い合わせが複数回繰り返される可能性がある。

米国特許第5,495,606号

本発明の１つの目的は、従来技術のシステムに関連付けられている問題の少なくとも一部を軽減することである。

本発明の１つの側面によれば、予約システムにおいて非拘束の旅行問い合わせに応じて価格付けされた旅行ソリューションを生成する方法であって、前記予約システムは、複数のパラメータに応じて旅行の可用性及び料金に関する情報を含んでいる複数の旅行データベースへのアクセスを有し、各旅行問い合わせは選好情報のセットを含み、前記各選好情報は前記複数のパラメータのうちから選択されたパラメータに関連し、前記方法は、各旅行問い合わせがユーザに関連付けられている複数の旅行問い合わせを受信するステップと、前記複数の旅行問い合わせを前処理するステップであって、各問い合わせから少なくとも１つの単純なリクエスト要素を抽出するステップと、少なくとも１つのパラメータに応じて前記複数のリクエスト要素をソートするステップと、同じ前記少なくとも１つのパラメータに対して同じ選好情報を含んでいるリクエスト要素が１つより多くある場合に、重複しているリクエスト要素を削除するステップと、前記複数のリクエスト要素を、所定の基準に従ってサブセットに、分割するステップとを含む、前処理するステップと、リクエスト要素の各サブセットを、前記複数のデータベースに問い合わせる前記リクエスト要素を実行する処理モジュールへ、転送するステップと、前記処理モジュールからの結果を収集して、各旅行問い合わせについてユーザへ応答を発するステップとを含む、方法が提供される。

本発明の２つめの側面によれば、上述の方法を行うために適合させた１以上の構成要素を備えるシステムが提供される。

本発明のさらなる実施形態によれば、コンピュータ上で実行した際に上述の方法を実行するための命令を含んでいるコンピュータプログラムが提供される。

本発明の好適な実施形態による方法は、グローバルディストリビューションシステム（GDS）に対して旅行についての提案をリクエストするエンドユーザに、改良された旅行リクエストサービスを提供する。これは、従来技術における従来の旅行リクエストよりも、各サーチパラメータについて、より広範囲に及ぶ新規な旅行リクエストを用いる。新規な旅行リクエストは同じ旅行リクエスト中に多岐に亘る範囲のパラメータを含むのに対して従来の旅行リクエストは各サーチパラメータに対して各異なるリクエスト値を繰り返させる必要がある。

本発明の好適な実施形態による方法は、改良された旅行リクエストサービスを実行するために、マスターモジュールとワーカーモジュールとの２つのモジュールの組合せを提供する。マスターモジュールは、全てのユーザから旅行リクエストを抽出する。マスターモジュールは、旅行問い合わせを単一リクエストに分割し、重複する旅行リクエストを排除して最適化された旅行リクエストを取得する。そして、マスターモジュールは、最適化された旅行リクエストをワーカーモジュールへと転送する。最適化された旅行リクエストの内容に応じて、ワーカーモジュールは、旅行処理モジュール、可用性処理モジュール、料金エンジン処理モジュール等の対応する処理モジュールを、要求されている計算について直接的に実行する。結果として、ワーカーモジュールは最適化された旅行リクエストに基づいてサーチ結果を提供することになる。そして、ワーカーモジュールは最適化された旅行リクエストの結果をマスターモジュールへと送る。そして、マスターモジュールは結果をエンドユーザに表示する。

本発明の好適な実施形態による方法は、ユーザからの広範な旅行問い合わせを処理するためのマスターモジュール及びワーカーモジュールからなる2モジュールの実装に基づいている。マスターモジュールは、全てのユーザからの全ての旅行問い合わせを分析して最適化された旅行リクエストを提供する。ワーカーモジュールは、最適化された旅行リクエストを処理して特定の処理モジュールへと送信する。

プレショッピング、収益管理及び料金分析へのフィード目的のためのデータ計算方法は、既にショッピングビジネスで使用されている他のGDSサブシステム（旅行ソリューションプロセス、可用性チェッキングプロセス、料金プロセス等）と相互作用する。
本方法の好適な実施形態により得ることのできる幾つかの有利な点としては、次ぎを挙げることができる：
― プラットフォームにより提供されるプロダクツが、網羅性及び一貫性を伴うプレショッピング及び収益管理システムへのフィーディングを可能とする。

ビジネスロジックを実施するビジネスルール及び適用可能なプラグインのおかげで、本発明は顧客に短い納期をもたらす。GDSにとっては、フライト及び価格算定についての新たなタイプのアプリケーションを大規模に支えるのは簡単なことである。
― GDSにとっては、データ計算の最適化のおかげで、リソース消費は合理化され、それによりコストが低減される。
― さらに、リソースは管理下に置かれる。システムの限界に達せずに、処理すべきボリューム及び遵守すべき時的制限に従ってリソースを動的に割り当てることができる。

添付の図面について、例示的に、以下参照する。
本発明の１つの実施形態による予約システムのためのマッシブ計算プラットフォームを示す図である。 本発明の好適な実施形態の方法をサポートするように適合された汎用コンピュータシステムを示す図である。 本発明の好適な実施形態を実施するシステムのソフトウェアコンポーネントを示す図であり、本発明の好適な実施形態による方法の全てのステップについての全体図である。 本発明による方法の様々なステップを概略的に示す図である。 本発明による方法の様々なステップを概略的に示す図である。 本発明による方法の様々なステップを概略的に示す図である。 本発明による方法の様々なステップを概略的に示す図である。 本発明による方法の様々なステップを概略的に示す図である。 本発明による方法の様々なステップを概略的に示す図である。 本発明の１つの実施形態によるプロセスの方法ステップについてのフローチャートである。

図１は、本発明の好適な実施形態による、フライト及び価格の大規模計算に特化したサブシステム１０１を示す。データ処理は、予約に特化しているショッピングトラフィックから分離されている。

このサブシステムは、予約アプリケーションに用いられるトランザクションの代わりに高い自由度をもって問い合わせを管理する。この自由度は次のものに適用される：例えば、日付組合せ（ある年度の全日についての出発日とその出発日から数週間後までの全ての帰還日）、出発地及び目的地の地理的ゾーン、リクエストされた営業航空会社（リクエストされた都市ペアに対してあり得る航空会社の内１つ、複数又は全て）、利用可能な全ての予約コード、あらゆる旅客タイプ等。

このようなデータ計算にとって低レイテンシーは必須ではないので、タイムフレームはリアルタイムとは異なってもよい。したがって、処理及びリソース消費をより長いタイムフレームに亘って広げることができる。また、結果の返戻もタイムフレームに亘って広げられる。

本発明の好適な実施形態においては、サブシステムは、リソースを動的にインスタンス化して大量のデータに対処できるバッチモデルに従って編成される。サブシステムは、グローバル問い合わせ分析に基づいてデータ処理の最適化を行う。また、サブシステムは汎用的であり拡張可能でもある。サブシステムに、異なるビジネスロジックを簡単にプラグインして、種々の顧客要件（プレショッピング、収益管理、料金分析）を満足させることができる。

本発明の好適な実施形態においては、サブシステム１０１は、１以上のマッシブマスター（Massive Master）１０３及び複数のマッシブワーカー（Massive Worker）１０５を有する。マッシブマスター１０３は問い合わせをグローバルに分析してから、最適化されたリクエストに分解する。そして、これらのリクエストは１以上のマッシブワーカーにより処理され、その結果が送信元のマッシブマスターにフィードバックされ、このマッシブマスターはマッシブワーカーからの結果を旅行ソリューションプラス価格にアセンブルする。

図２を参照するに、システム（例えば、コンピュータ、予約サーバ、マッシブマスターサーバ、マッシブワーカーサーバー、データベース管理サブシステム、ルータ、ネットワークサーバ）の汎用コンピュータが符号２５０で示されている。コンピュータ２５０は、システムバス２５３に並列で接続された複数のユニットにより形成されている。詳しくは、１以上のマイクロプロセッサ２５６がコンピュータ２５０の動作を制御し；RAM２５９がマイクロプロセッサ２５６によりワーキングメモリとして直接的に使用され、ROM２６２がコンピュータ２５０のブートストラップ用の基本コードを格納する。周辺ユニットは、ローカルバス２６５の周りに（各々のインターフェースによって）クラスタされる。特に、マスメモリは、ハードディスク２６８とCD-ROM２７４を読み込むためのドライブ２７１とからなる。さらに、コンピュータ２５０は、入力装置２７７（例えば、キーボード及びマウス）及び出力装置２８０（例えば、モニタ及びプリンタ）を含む。コンピュータ２５０をネットワークに接続するのにネットワークインターフェースカード２８３が用いられる。ブリッジユニット２８６が、システムバス２５３とローカルバス２６５とのインターフェースをとる。各マイクロプロセッサ２５６及びブリッジユニット２８６は、情報伝送用のシステムバス２５３へのアクセスを要求するマスターエージェントとして作動することができる。アービタ２８９が、相互排他性を伴うシステムバス２５３へのアクセスの許可を管理する。システムが異なるトポロジを有する場合又は他のネットワークに基づいている場合にも、同様なことが言える。別の場合には、コンピュータは異なる構造を有するか、等価なユニットを含むか、又は他のデータ処理エンティティ（PDAや携帯電話等）で構成することもできる。

本発明の好適な実施形態においては、サブシステムは、問い合わせの関連する冗語（redundancies）を特定して無益な再処理を回避することを目的とする、グローバル分析を行う。処理において、冗長な問い合わせ部分をマージングすることは、リソース消費の点で及び処理中のデータへのアクセスの観点から効率的でなければならない。サブシステムは、同時に機能的要件及び技術的要件を満たす必要がある：即ち、顧客との間に確立したサービスレベルアグリーメントを遵守しなければならない一方（時間的制約、品質）、運用上の要件（リスティング管理、他のコンポーネントへの波及効果）も他方で遵守しなければならない。本発明の好適な実施形態のサブシステムは、以下２種類のサーバを含む。

即ち、入力及び出力を最適に管理するために必要とされるグローバルインテリジェンスをホスティングするマッシブマスター。
マッシブ計算プラットフォームにプラグインされた各プロダクトのビジネスロジックを実装するマッシブワーカー。

図３は、本発明の好適な実施形態によるプロセスのフローを示す。このグローバルフローは、並列に実行しうる次の６つのステップ／作業に分けることができる：
― 分割（SPLIT）：ここでは、マッシブマスターが顧客問い合わせからの全ての単一リクエストを抽出する。
― 最適化（OPTIMIZATION）：ここでは、リクエストをスマートにマージするために、マッシブマスターがグローバルに分析を行う。
― 割り当て（ASSIGNATION）：ここでは、マッシブマスターがマッシブワーカーへリクエストをスマートに送る。
― 計算（COMPUTATION）：ここでは、マッシブワーカーが最適化されたリクエストを処理する。
― ストリーミング（STREAMING）：ここでは、マッシブワーカーが結果ボリュームを管理する。
― アグレゲーション（AGGREGATION）：ここでは、マッシブマスターが顧客問い合わせに応じて結果をグループ分けする。

各ステップは以下の段落で詳説する。

図４は、分割操作、即ち顧客により受信された問い合わせから単一リクエストを抽出する操作を概略的に示している。分割操作は、問い合わせを単一リクエストに変換することからなる。単一リクエストは、自由度を有さないトランザクションに論理的に等価なものである：日付、地理、旅客、航空会社毎についての情報が設定されている状態。

入力管理モジュール４０１は顧客がポストした問い合わせのセットを検出する。ある時点で問い合わせが受信されなくなったら、以前に処理した一連の問い合わせを処理すると決定することもできる。これにより、顧客は所定の期間内（例えば、毎日）で問い合わせのセットをポストすることを強制されなくなる。入力管理ステップでは、各問い合わせの処理の頻度を決定することもできる：例えば、一日に一回又は一日に複数回。入力管理モジュール４０１は、入力ボリュームを処理するためにタスクのインスタンス化も決定する。次のステップのために必要とされるリソースは問い合わせ数及び顧客との間に確立されたタイムフレームに応じて評価される。これにより、制約された遅延の範囲で大規模なデータを計算できることが保証される。

入力チェックモジュール４０３は、構文的観点及び意味論的観点の双方から入力をチェックする。このステップはプロダクトに依存するため、異なるタイプの入力を管理するために異なるプラグインが追加される。新たなプロダクト又は新たなプロダクトバージョンのためには、新たなプラグインを追加する。

抽出モジュール４０５は、顧客が問い合わせの中で提供した意味論的情報から単一リクエストを抽出する。この抽出はプロダクトと顧客により提供された入力との双方に依存する。したがって、このステップはプラグ可能である。さらに、顧客の幾つかの機能的な制約に対してビジネスルールを適用することができる。

この文脈で適用されるビジネスルールの例：国内市場向け旅行のよりよい品質の可用性（例えば、航空会社へ可用性をポールすること）をリクエストすること。

図５は、最適化操作、即ち顧客のリクエストに対してグローバル分析を行うことを概略的に示している。一旦単一リクエストが生成されると、別の段階で、計算の最適化目的のために冗長部分のマージを行う。この操作は、下記に説明する複数のステップからなる。

グローバル分析モジュール５０１は、単一リクエスト内の冗語を特定する。効率的な最適化のため、このステップは、グループ分けすべき最も関連性のある冗語を、各プロダクトごとに規定するプラグインに基づいている。

マージングモジュール５０３は、冗長処理を回避するために、単一リクエストをグループ分けする。複数のスマートマージングが可能である。グループ分けは、プロダクト特有のプラグイン最適化ルール及び顧客の機能的制約に適合するビジネスルールの双方に基づく。

ビジネスルールの例：リクエストのグループ分けは顧客の望む処理タイムフレームに基づく。国内市場のリクエストは、執務終了時間の後、即ち最後に可能な手動更新の後、に処理されなければならない。他方、他市場のリクエストは直ちに処理されることができる。

定期的に処理される問い合わせについては、生成される結果の主要部分は各プロセスにおいて同じものとなる。ヒューリスティックモデル５０５は、以前のプロセスで顧客に返されたものと同じ結果を生成するであろうリクエストを統計的に特定する。これらのリクエストは処理されない。このようにして不要な価格計算が削減される。このモジュールはリソース消費を節約する。もっとも、グローバル結果については高い水準の正確性が保証される。

図６は、割り当て操作、即ちリクエスト処理を駆動するものを概略的に示している。一旦第１のマージされたリクエストが生成されると、それは処理される。割り当て操作は、前述のステップと並行的に実行されながら、リクエストのマッシブワーカーへの配分をリソースに応じて駆動していく。この操作は、異なるモジュールにより実現される以下に説明する複数のステップからなる。リクエストプロバイダモジュール６０１は、マッシブワーカーへ送るべきリクエストを、リクエストを生成した問い合わせに応じて選択する。このモジュールの目的は、顧客に問い合わせの結果を順次に返すことを可能とするためである。問い合わせのグローバル結果を計算するために、リクエストが選択される。一旦問い合わせの結果が計算されると、別の問い合わせに相対的なリクエストが選択される。他の選択基準としては、各マージされたリクエストについて承認されている処理タイムフレームがある。例えば、一部のリクエスト処理は、執務時間終了後は遅延される。これにより、結果計算に用いられたデータに対しての最後の手動更新も参照される。

ペーシング及び優先順位モジュール６０３は、過負荷状態を回避することにより利用可能リソースに応じてマッシブワーカーの活性を制御する。またそれは、処理されるべきリクエスト間での優先順位も管理する。例えば、問い合わせのセットがファストトラック（Fast Track）モードでリクエストされた場合、それは標準的な問い合わせのセットより高い優先順位で処理される必要がある。このような問い合わせの計算のために、より多くのリソースが専属的に割り当てられる。

マッシブワーカーターゲッター（targeter）モジュール６０５は、リクエストが処理されるべきマッシブワーカーファーム（farm）を選択する。この選択は、技術的な観点（マッシブワーカーのリソース利用可能状況）及び機能的な観点（一部の市場・プロダクト・顧客に特化しているマッシブワーカーファームがあること）の双方に基づく。

図７は料金計算操作、即ちビジネスロジックを概略的に示している。マッシブワーカーは、本発明の好適な実施形態による方法により、全てのプロダクトのビジネスロジックを実装する。

リクエスト解読モジュール７０１がマッシブマスターにより提供された最適化されたリクエストを解読する。この処理は、GDS中に既に存在している異なるモジュールをコールすることにより駆動される。コールされるモジュールとコールを行う順序はプロダクトに依存する。各コールされたモジュールは、各プロダクトに特有の適用可能プラグインに基づいている。

旅行処理モジュール７０３は、リクエストのフライトソリューションの計算を実施する。同モジュールは、リクエスト内で提供される日付、地理及びオプション情報から旅行の組合せを特定することを担当している。旅行処理は、最新の更新データに依存している。

可用性処理モジュール７０５は旅行ソリューションの可用性をチェックすることを実施する。より良い品質水準を得るために、リクエストを直接航空会社に処理させてより最新のデータに依拠することができる。

料金エンジン処理モジュール７０７は、リクエストに対してあり得るソリューションの価格計算を、リクエスト内で与えられる情報及びオプションに従って、実施する。よりよいソリューションのみがリクエストされている場合、同モジュールは価格比較を行い、最善のもののみを保持する。

図８は、ストリーミング操作、即ち生の結果を管理することを概略的に示している。計算により生成された膨大なボリュームを管理するためには、操作は、マッシブマスターとの通信及び結果の格納の双方についての最適化を要する。下記に説明するマッシブマスター上の複数のモジュールがこの最適化を可能とする。

圧縮モジュール８０１は、結果のサイズを減少させ、それによりマッシブワーカーとマッシブマスター間の通信ボリュームを減少させる。また、格納されるデータのボリュームも減少する。この操作は処理リソースを消費するため、通信及び格納資源についての利得が有意である場合のみに同操作は適用される。

分割／バッファリングモジュール８０３もリソース消費量の最適化を可能とする。

生成結果の結果ボリュームが大きすぎる場合、それは複数のバンドルに分割される。このようにしてマッシブマスターとデータストレージ間の通信が同時的に行われる。

結果のボリュームが少なすぎる場合、マッシブマスターによる管理にふさわしいものとなるまでバッファされる。通信はより効率的になる。なぜならば、ある程度のボリュームを処理する格納モジュールが若干数のみ必要であるにすぎないからである。

マッシブマスターターゲッター８０５はマッシブマスターを選択する。この選択は、技術的な観点（マッシブマスターにおけるリソース可用性）及び機能的な観点（一部の市場・プロダクト・顧客に特化しているマッシブワーカーファームがあること）の双方に基づく。

図９は、アグレゲーション操作、即ち顧客入力を管理することを概略的に示している。
問い合わせの結果が生成され次第、それらはアグレゲートされて顧客に適切なフォーマットで送り返される必要がある。

結果をアグレゲートモジュール９０１は、マッシブワーカーからの生の結果を価格オリエンテッドな結果に変換する。結果は、顧客の問い合わせに応じてアグレゲートされる：顧客は自己の質問への回答を得るのであって、混沌とした結果を得るのではない。例えば、顧客が特定の市場についての、幾つかの選択肢を伴う、一年を通しての出発日についての、ソリューションを問い合わせの中でリクエストしていた場合、回答においては、問い合わせに含まれた全ての選択肢及び全ての出発日に対応する全てのソリューションがアグレゲートされる。各プロダクト及び各顧客について、プラグインが期待されるフォーマットを定義する。

Diffモジュール９０３は、前回の処理時以降に変化のあった結果を選択する諸価格パッケージングオプションである。新たな、更新された又は減額された結果のみが顧客に送り返される。製品に応じた差別化基準がプラグインにより定義される。このオプションにより、GDSと顧客間で効率的なネットワークトランスファーが可能となる。また、より少ないボリュームを管理するだけで良いので、顧客システムの負荷が低下する。

圧縮及び暗号化モジュール９０５は、送り返されるボリュームを削減して結果のコンフィデンシャリティーを保証することによって、効率的かつセキュアなネットワークトランスファーを可能とする。

トリクリング（trickling）リターンモジュール９０７は、処理された問い合わせのグローバル結果をグルーピングすることによって定期的にトランスファーを行う。これにより、リターンは長時間に亘って広げられる。

結果のボリュームがマッシブであるため、プレショッピング又は収益管理システムに結果を統合することについて、顧客は処理の終了を待つことはできない。したがって、処理の開始から数分後から、初期の結果が生成されて送り返される。トランスファーは処理時間に亘って広げられる。これにより、結果は徐々に顧客のプレショッピング又は収益管理システムに統合されていくことができる。

使用例

例１：プレショッピングシステムのためのプロダクト
プレショッピングシステムへの入力に特化したプロダクトを考えてみよう。そのようなものは、指定された都市ペア及び航空会社をマッチする各フライトソリューションについて、全ての出発日及び滞在期間についての最低価格を計算する。計算は、中間タリフパブリシャーにより自動的にGDSへ申請された全データに基づく。フライトに残席がある場合にのみ、レコメンデーションが返送される。席の残存数を確認するのには多くのリソースが消費されるため、この操作は、顧客のパートナーが航空会社の場合の問い合わせに限定される。

単一リクエストを作成することにより、分割モジュールは、ビジネスルールのおかげで、リクエストについてのパートナーを特定できるようになり、それらのリクエストをフラグしておいて座席残存チェックを可能とすることができる。

最適化モジュールは、旅行リクエストをマージして、日付組合せによる冗長性を防止する。マージ操作では、プロダクトに固有な料金エンジンの処理についての最適化を考慮するプラグインを用いる。

例２：収益管理システムのためのプロダクト
収益管理システムへの入力に特化したプロダクトを考えてみよう。そのようなものは、指定された市場をマッチする各フライトソリューションについて、全ての出発日、滞在期間、早期購入条件及び予約ブッキングコード（Reservation Booking Code、以下RBDという。）についての最低価格を計算する。RBDは、旅行の全行程において同じものが使われなければならない。計算は、中間タリフパブリシャーにより自動的にGDSへ申請された全データに基づく。出発日が４５日後以内であるリクエストの計算は、営業時間中に顧客により手動でGDSに申請されたデータ全てに基づく。

最適化モジュールは、日付の組合せと早期購入とをバンドル化して、旅行ソリューションの計算を最適化する。マージを行う時点において、同モジュールは、ビジネスルールを適用して、４５日後以内の出発日を持つリクエストを分離する。これらについての処理は、GDSに申請された手動更新を取り込むために、営業時間後まで遅延される。料金計算モジュールは、特化した旅行処理プラグインを使用して、フライトソリューションに正しいRBDを返送する。プロダクトはショッピング又はプレショッピングに限定されていないので、可用性処理プラグインは使われない。

このプロダクトは、最適化されたリクエストとして、（日付、早期予約、RBDの組合せに起因する）数千の結果を返送するため、ストリーミングモジュールは、マッシブワーカー上で生の結果の分割を行う。

上述した方法は、図１０でも説明される。方法は黒丸１００１において開始され、ボックス１００３へと進み、旅行問い合わせがシステムにより受信される。このような問い合わせは、旅行可用性、料金、時刻又は予約の完了に必要ではない一般的な事柄等についての情報、即ちプレショッピング情報を求めているユーザにより発せられる。本発明の好適な実施形態においては、問い合わせを受信する及びユーザーからの問い合わせを満足させるためのデータベースへの問い合わせを行う、システムは、実際の予約システムとは別個のものであるが、当業者ならこの２つのシステム（プレショッピング及び予約）は統合され得るものであることを理解するであろう。一旦旅行問い合わせが受信されると、制御はボックス１００５へと戻り、問い合わせの前処理が行われる。前処理をコールする時点又は前処理の開始をトリガーするイベントは、複数のファクターに基づくことができ、システムアドミニストレータ又は個々のユーザ達によってカスタマイズ可能でさえある。例えば、前処理は所定の時間間隔毎（例えば、毎日又は毎時の終了時）に行われることができる、または、臨界件数となる問い合わせを受信した際若しくは最大キャパシティに達した場合に自動的に行うことができる、または、アドミニストレータ又はユーザによりリクエストされることができる。本発明の好適な実施形態によれば旅行問い合わせの前処理は、問い合わせを単純なリクエスト要素（図３では単一リクエストともいう。）に分解するグローバル分析を伴い、これによりデータベースへの問い合わせが最適化される。本発明の好適な実施形態では、各問い合わせはマッシブマスター（前処理モジュール）により分析されて、１以上の単純なリクエスト要素が抽出される。その後、これらの単純なリクエスト要素は冗長を回避するために、図５に関して述べたように複数のファクター及びビジネスルールを考慮した所定の基準に従って、再整理され、サブセット（図３では最適化されたリクエストともいう。）に整理（分割）される。この前処理は、全ての旅行問い合わせが前処理されるまで続行される（ステップ１７００）。一旦リクエストが最適化されると、マッシブマスターは各サブセットを適切なマッシブワーカーに割り当てて、リクエストを正しいマッシブワーカーに転送する（ステップ１００９）。その後、各マッシブワーカーは、ユーザのリクエストを満たすために、例えば旅行料金、旅行可用性等について、データベースに対して問い合わせを行う。問い合わせについての結果が収集され、マッシブマスターに返送されて、返答を発することにより、結果が旅行問い合わせを提出したユーザに提供される（ステップ１０１１）。本発明の好適な実施形態では、結果は、ユーザにこれが提供される前に、上述したようにマッシブマスターによりアグレゲートされる。その後、処理は、ステップ１０１３で終了する。図１０を参照して説明した上記例においては、方法を行うシステムは、１つのマッシブマスターと複数のマッシブワーカーを有しているが、他の態様も可能である。例えば、並列に機能する１より多いマッシブマスターの場合や１つのマッシブワーカーが複数のサブセットを処理する場合等。また、マッシブワーカー及びマッシブマスターは異なる物理マシンに必ずしも対応する必要はなく、同一のシステム上で機能しているアプリケーションであってもよい。

本開示の範囲から逸脱せずに、上記に対して修正及び変更を加えることができるものと理解される。ローカルな及び具体的な要求を充足するため、当然に、当業者は、上述のソリューションに対して、多数の変更及び修正を加えることができる。本開示では好適な実施形態を参照して一定程度の具体性をもって説明したが、殊に、形式及び詳細についての様々な省略、置換及び変更並びに他の実施形態が可能であり、また、本開示で開示される実施形態との関係で説明される具体的な要素及び／又は方法のステップを他の任意の実施形態に組み込めると、デザイン選択の一般的事項として、明示的に意図されている。

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

いずれの場合であれ、本開示によるソリューションは、ハードウェア構造（例えば、チップ又は半導体材料に統合されたもの）又はソフトウェアとハードウェアの組合せによる実行に適している。

Claims (14)

1. 予約システムにおいて非拘束の旅行問い合わせに応じて価格付けされた旅行ソリューションを生成する方法であって、前記予約システムは、複数のパラメータに応じて旅行の可用性及び料金に関する情報を含んでいる複数の旅行データベースへのアクセスを有し、各旅行問い合わせは選好情報のセットを含み、前記各選好情報は前記複数のパラメータのうちから選択されたパラメータに関連し、前記方法は、
   各旅行問い合わせがユーザに関連付けられている複数の旅行問い合わせを受信するステップと、
   前記複数の旅行問い合わせを前処理するステップであって、
   各問い合わせから少なくとも１つの単純なリクエスト要素を抽出するステップと、
   少なくとも１つのパラメータに応じて前記複数のリクエスト要素をソートするステップと、
   同じ前記少なくとも１つのパラメータに対して同じ選好情報を含んでいるリクエスト要素が１つより多くある場合に、重複しているリクエスト要素を削除するステップと、
   前記複数のリクエスト要素を、所定の基準に従ってサブセットに、分割するステップと
   を含む、前処理するステップと、
   リクエスト要素の各サブセットを、前記複数のデータベースに問い合わせる前記リクエスト要素を実行する処理モジュールへ、転送するステップと、
   前記処理モジュールからの結果を収集して、各旅行問い合わせについてユーザへ応答を発するステップと
   を含む、方法。
2. 前記処理モジュールから収集した結果は、前記応答をユーザへ発する前にアグレゲートされる、請求項１に記載の方法。
3. 前記リクエスト要素の各サブセットのリクエスト要素を実行する前記ステップは、複数の処理モジュールによって並列に実行される、請求項１〜２のいずれか１項に記載の方法。
4. 前記複数のリクエスト要素を分割する前記ステップは、各サブセットを所定の基準に従って前記複数の処理モジュールの１つに割り当てることを含む、請求項３に記載の方法。
5. 前記複数の旅行問い合わせを前処理する前記ステップは、複数の前処理モジュールによって並列に実行される、請求項１〜４のいずれか１項に記載の方法。
6. 各リクエスト要素の結果に対して、前記処理モジュールは、複数の前処理モジュールのうち１つを、アグレゲーション及び前記ユーザへの前記応答の発信のために前記結果を転送すべきものとして選択するステップ
   をさらに含む、請求項５に記載の方法。
7. 前記複数のパラメータは、日付及び地理的な位置を含む、請求項１〜６のいずれか１項に記載の方法。
8. コンピュータ上で実行した際に、請求項１〜７のいずれか１項に記載の方法のステップを実行するための命令を含んでいるコンピュータプログラム。
9. 請求項８に記載のコンピュータプログラムを具体化するコンピュータ可読手段を含むコンピュータプログラム製品。
10. 請求項１〜７のいずれか１項に記載の方法を含むプレショッピングシステムを入力することに特化したソフトウェアツール。
11. 請求項１〜７のいずれか１項に記載の方法を含む収益管理システムを入力することに特化したソフトウェアツール。
12. 請求項１〜７のいずれか１項に記載の方法を含む料金分析システムを入力することに特化したソフトウェアツール。
13. プレショッピング旅行問い合わせを管理するためのデータ処理システムであって、該データ処理システムは複数のパラメータに応じて旅行の可用性及び料金に関する情報を含んでいる複数の旅行データベースへのアクセスを有し、各旅行問い合わせは選好情報のセットを含み、各選好情報は前記複数のパラメータのうちから選択されたパラメータに関連付けられており、前記システムは請求項１〜７のいずれか１項に記載の方法を実行するように適合された１以上のコンポーネントを備える、システム。
14. 請求項１〜７のいずれか１項に記載の方法を実施するためのデータ処理システム内に配備されるサービス。

Images