(58)【調査した分野】(Int.Cl.,DB名)
【背景技術】
【0002】
最新の予約システムは通常専用のグローバル分散システム(GDS)に基づいており、例えば航空券予約システムはフライト予約等のショッピングビジネスのためのフライト検索アプリケーションを提供している。「予約のためのショッピング」とも称されるこの活動は多大な計算を必要とし、若干の時間を要する。この遅れを最小にするために、ユーザに通常少ない自由度が与えられ、ユーザは旅行の出発都市及び目的都市、出国日及び帰国日を指定しなければならない。遅れをさらに最小にするには、ユーザは、もし正確なフライト要求があれば、例えば好きな航空会社や客室クラスを指定することができる。ユーザは、特定の旅行(都市ペア、出発日及び到着日)に対する最善価額を最終的な予約のために検索する。検索は通常いくつかの柔軟性を提供し、例えば要求された旅行に対して100の最安便の推奨を返送する、密接に関連する日に対してもっと安い便を返送する。必要とされる全計算(最安料金及びルートの組み合わせの検索、候補便の空席状況の検査・・・)は問い合わせ時に実行され、これは返送される推奨が予約に役立つことを保証する。従って、このような検索トランザクションはコストがかかり、完了まで数秒かかる。このコストが、それらが例えば来る2〜3ヶ月の間における最安便のようなよりオープンな検索要求に答えることを妨げることになる。これはシステム性能及び応答時間にとって有利であるが、パラメータ選択にもっと広い自由度を有するもっとユーザフレンドリーなインタラクションを確実に歓迎するユーザにとっては理想的ではい。
【0003】
航空旅行価額の検索業務に対する異なるアプローチはいわゆる「プレショッピング」である。この用語は、予約システムを通してデータベースの問い合わせを要求するが、必ずしも正式の予約をもたらさない活動を指す。この活動は航空会社や旅行会社にとって決定的に重要である。なぜなら、それらは直ちに収益をもたらさなくても、潜在的な顧客の将来の選択に影響を与え得るためである。多数の自由度があるユーザ問い合わせに対して遅れなしの応答を提供しうるツールが大いに喜ばれる。プレショッピングによって、ユーザは航空会社や旅行会社の航空旅行の全カタログを閲覧することができる。それらのユーザは、ショッピング前に10億を超える旅行の推奨を閲覧することによって決心をしたい。ショッピングに比較して、推奨の閲覧は検索に対して瞬時の応答(数十ミリ秒)を意味する。従って、プレショッピングシステムの典型的なアプローチは事前計算された旅行の推奨のキャッシュをユーザに閲覧させることにある。このようなアプローチでは、検索クエリーはさらにパワフルにすることができ、ユーザは多くのオープン基準、出発都市のみ、日にち範囲、価額範囲、・・・について検索することができる。例えば、
「次の12ヶ月以内における600ユーロ以下のパリから任意の目的地までの2〜3週間の旅行」
がある。
【0004】
このアプローチの欠点は、ユーザに返送される推奨はそれらの事前計算の時点で有効であることを保証するのみであることにある。特に、これらの推奨は検索の時点ですでに予約にふさわしくないかもしれない。他のキャッシュブラウザドメイン(例えば、WWWsearch)と異なり、航空旅行プレショッピングは航空旅行価額の変動性に極めてセンシブルであり、来る数週間におけるフライトの最良価額は毎日変化しやすい。この変動性はキャッシュの精度、即ちプレショッピングの価額とショッピングの価額との一貫性(一致)に大きな影響を与える。当業界の通常の精度は約20−30%である。高いキャッシュ精度を維持するには、多くの場合(旅行の全カタログを処理するために)膨大な再計算を必要とするとともに(フライト変動性を処理するために)頻繁な再計算も必要とする。これは多大なハードウェアリソースを必要とする。
【0005】
最新技術のプレショッピングルールはツールの効率を制限する幾つかの欠点を有する。例えば、トラベルテイメント プレショッピングプラットフォーム(「TTibe:TravelTainment Internet Booking Engine」http://www.traveltainment.fr/a-propos-de-traveltainment/qui-sommes-nous/)は事前計算旅行(主としてドイツの都市発のフライト)の自己データベースを閲覧する機能を提供する。航空旅行データは、例えばアマデウス社のエクストリームプライサ(マッシブコンピューティングプラットフォーム(MCP)の製品)により提供される。旅行データは、来年の毎日数千のドイツの都市ペアのフライトのうちで1日から23日の全ての滞在期間に関する最安便を表す。毎日、旅行の全主要素(数億の価額)がアマデウスにより再計算され、それらのプラットフォームへの統合のためにトラベルテイメントへ送られる。旅行分野は顧客の観点からむしろ網羅的であるが、このアプローチは2つの主な欠点がある。
・すべてのデータがアマデウスにより毎日再計算されており、運用コストがかかる。
・この多量のデータの統合はトラベルテイメントにとってコストがかかり、1日に1回しか実行できない。これは顧客が経験する価額の正確さに影響を与える。
【0006】
他の商業的に利用可能なプラットフォームには次のものがある。
カヤックエクスプロア:
(http://www.kayak.com/news/kayak-adds-map-based-search-tool-to-popular-ipad-app.pd.html)、
オポドエスケープマップ:
(http://promos.opodo.co.uk/airtool/escape/map.html)、
ルフトハンザトリップファイインダ:
(http://www.lufuthanza.com/online/portal/us/nanov/vocal?nodeid=3322341&l=en)、これはアマデウス技術により駆動される。
これらの3つのプレショッピングプラットフォームは、事前計算の解をそれらのキャッシュへ供給するのに、トラベルテイメントと異なる戦略を取っている。それらはすべてリアルショッピングを記録すること、即ちそれらのショッピングプラットフォームで実行された検索トランザクションの結果を記録することに依存している。このアプローチは、事前計算にほとんどノーコストがかからない利点を有する。しかしながら、これにはそれらのそれぞれの顧客に対して一連の不利益を伴う。即ち、
・記録済み航空交通量のために異例の目的地はプレショッピングを利用できないかもしれない;
・記録済み航空交通量中の欠落日のために価額領域に多数の「空白」がある;
・幾つかの不安定な価額推奨が何日も(何週間のこともある)更新されない。
【0007】
これらの欠点はすべて顧客が経験するプレショッピングの正確さをある程度損ない得る。
【発明を実施するための形態】
【0015】
本発明の好ましい実施形態による分散検索プラットフォームは事前計算された航空旅行価額を格納しようとするもので、幾つかの利点を提供する。
【0016】
本検索プラットフォームは航空旅行の全カタログを保持するように設計される。本検索プラットフォームは、1年のすべての日について例えば何千ものマーケットの中から滞在期間に応じて1日当たりの幾つかの可能な価額を最善価額として格納することができる。本発明の分散特性はマーケットの数がいくつであっても格納するようにスケーリングすることができる。
【0017】
本検索プラットフォームは航空旅行データの格納を最適化し、以下の利点を有する。
・旅行検索効率:検索トランザクションの達成可能な応答時間は、検索の複雑さ(目的地オープン、通年検索・・・)がどうであれ、数十ミリ秒である。
・旅行日更新効率:更新は全記憶に限られた影響を与えるのみで、連続的な更新を可能とし、新データの瞬時利用を可能にする。
・旅行データ格納効率:データは、多くのカタログに共通であれば、格納コストをさらに低減するためにファクタ化することができる。
【0018】
本システムは高品質のプレショッピング旅行の推奨を持続可能なコストで維持することができる。本システムは再計算を必要とする旅行価額を検出する様々なエンジンを有する。これにより再計算を部分的にしてハードウェアリソースを節約することができる。節約されたリソースはユーザの観点から見てより高いキャッシュ精度(80−90%の範囲内)を達成するために他の再計算に再使用することができる。
【0019】
本システムは顧客のニーズ及び旅行プロバイダに応じて異なるタイプの検索プロダクトを提供する。例えば、航空会社は自身のエアライン及びそのパートナーのエアラインに関する推奨を検索するための検索プロダクトを必要とする。これに反し、オンライン旅行業者は航空会社のフィルタリングなしで任意のタイプの航空旅行を検索するための検索プロダクトを必要とする。これらの2つのプロダクトは内部特異性を有し、それに応じて最適化することができる。
【0020】
図1は、本発明の好ましい実施形態による、航空旅行の推奨を格納及び検索する分散システム101を示す。格納されたカタログ又は航空旅行の推奨は分散システムを構成するすべてのマシンに分散される。すべてのマシン上で、グローバルデータの一部分は高速データアクセス用の高速アクセスメモリ域(例えばRAM)に格納される。
図1は本発明を実施するシステムのアーキテクチャの論理的構成図を示す。物理的に分散されているが、システムの論理的構成図は2つの主要グループに分けることができる。
【0021】
データベース103及び方形ボックス105及び107は分散検索システムの代表的部分を示す。データベース103は、すべての航空旅行の推奨が推奨のプールに論理的にグループ化され、異なるマシンに亘って物理的に格納されることを表している。
【0022】
方形ボックス105及び107はフィードエンジン及び検索エンジンを表す。
・フィードエンジン105は、事前計算された航空旅行の推奨のグループ(例えば同じ都市ペアのすべての旅行)にインデックスを付与し、それらを分散システム内のマシンの一つに格納する。
・検索エンジン107は、物理的マシンの間でデータのグループを位置決定し、ユーザからのクエリーに応答するためにインデックス検索機能を提供する。
【0023】
楕円ボックス109−115は一連のビジネス向け解析エンジンである。それらの目的はプラットフォームのハードウェアコスト(及び旅行プロバイダのコスト)を最適化することにあり、それらは毎日再計算する推奨の数とシステムに格納される事前計算価額の正確さとの間の最適な兼ね合いを達成することを目的としている。これらのエンジンはフィード及び検索処理を解析し、システムに格納されるデータの変動性及び品質に関するメトリクスを発生する。これらのエンジンのいくつかはGDS(本発明の一部分ではない)の他のショッピングサービスを利用することができる。特に、
・学習エンジン109は、毎日プラットフォームに格納される旅行の推奨を解析して1日毎及びマーケット毎の価額変動、即ちどのくらい長く同じ価額であるかに関する情報を抽出する。
・人気エンジン111は最も要求された又は最も返送された旅行の推奨(1日毎、マーケット毎、・・)を追跡してシステムに格納されている最も重要なデータに関するメトリクスを得る。
・精度エンジン113は、システムに格納されているキャッシュされた旅行の推奨と実際のショッピング価額との不一致、即ちもはや予約不能であるか価額が変更されてしまったフライトを検出しようと試みる。
・報告コーディネータ115は上記エンジンの結果を集約し、格納する。その役目は、全フライトデータのどの部分を再計算しなければならないかを所与の利用可能なリソースで上記エンジンの結果に基づいて決定することにある。このような決定はアルゴリズムに従って実行される。
本システムでは、すべての解析エンジンはフィード及び検索エンジンと並列に動作するため、それらの動作はユーザに何ら性能上の影響を与えることはない(応答時間の悪化はない)。
【0024】
図2を参照すると、完全検索プラットフォームが示されている。このようなプラットフォームは本発明の好ましい実施形態によるシステム201を一つの構成要素として含み、このシステムは旅行推奨計算システム203、例えば欧州特許出願EP11305518.0に記載されているシステム(以下においてこのシステムは大規模計算プラットフォーム又はMCPという)、によって入力される。両システムはGDS205により提供される他の内部サービスとインタラクトすることができる。
図2は検索プラットフォームに旅行の推奨の全カタログを格納するための高レベルのフローを示す。
【0025】
プラットフォームの顧客として、旅行プロバイダ(航空会社、旅行業者)は、それらの旅行ドメインのどの部分を検索プラットフォーム内に統合したいかを決定する。この点から、旅行プロバイダは旅行推奨計算システムに該システムに対する一連の計算命令であるいわゆるマッシブクエリーを送る。これらの命令は考慮すべきマーケット(例えば来る年のすべての日に対する全都市ペアのリスト)並びに発生すべき旅行の推奨(例えば1−20日の旅行に対する毎日の最善の推奨)を詳述する。このような命令は顧客がしばしば再評価することができ、またこれらの命令は反復計算のベースとして作用させることができる。
【0026】
旅行推奨計算システムは要求された推奨を計算するためにGDSの内部サービスを利用する。特に、推奨を生成するために、既存フライトのリストを読み出す旅行サービス、料金とフライトの最良の組み合わせを見つけるプライシングサービス及び予約のために利用可能な現在の利用可能席数を調査するアベイラビリティサービス、・・・を利用し得る。
【0027】
推奨が生成されると、計算システムはその結果を統合のために本発明の好ましい実施形態によるシステムに送る。受信した推奨結果は事前計算旅行推奨のグローバルキャッシュを得るために専用メモリ域に格納され、最終的なユーザの検索クエリーに対して利用可能になる。旅行の推奨が統合されると、いくつかのモニタリングタスクがバックグラウンドで生じ、キャッシュされた旅行の推奨のどれが対応するショッピング推奨との低い一貫性のために再計算しなければならないかを決定する。このモニタリングはGDSにより提供される内部サービスを使用することができる。
【0028】
一貫性のない推奨が検出されると、本発明の好ましい実施形態によるシステムは一連の計算命令(マッシブクエリー)を発生し、それらを計算システムに送る。計算システムは旅行キャッシュの一貫性を維持するのに役立つ最新の推奨を発生する。
【0029】
図3はフィードエンジン105(
図1参照)の構造及び機能を示す。フィードエンジンは、旅行推奨計算システム、例えばMCPにより返送される航空旅行の推奨のグループを受信する。例えば、パリからロンドン(マーケットPAR−LON)のすべての価額を受信する。これらのデータの統合はいくつかのステップで行われる。
【0030】
・旅行の推奨の発送
本発明の好ましい実施形態によるシステムでは、関連データは極めて速い検索応答時間を実現するために同じ物理的マシンで格納されることを目指す。例えば、同じ出発都市を有する2つのマーケット(PAR−LON及びPAR−NYC)は同じ物理的マシンに投入される。
【0031】
フィードエンジンは推奨のグループから情報(旅行プロバイダID、オフィスID、マーケット、グラフィックロケーション・・・)を抽出してどの物理的マシンがデータのホストになるかを決定する。このデータ平衡化メカニズムはラウンドロビン又はコンシステントハッシングなどの周知の分配技術を利用することができる。周知のデータ複製方法で見られるように、多くのマシンは信頼性、フォールトトレランス又はアクセスのしやすさを向上させるために推奨の同じグループをホストすることができる。
【0032】
・旅行の推奨の編成
フィードエンジンは旅行推奨計算システム、例えばMCP、からの旅行の推奨のバッチを受信する。入力するデータは本発明の好ましい実施形態によるシステムによりよく適合するようにデータセットというグループに分けられる。現在記載しているシステムにより提供される各検索プロダクトはその性能を最適化するためにユニークなデータ編成ストラテジを有する。例えば、特定のニーズのために、旅行推奨計算システム(例えばMCP)から到来するフライトのグループは、同じ都市ペアのグループに編成し、次いで2つのタイプのデータセット:1)同じ都市ペアで直行便及び2)同じ都市ペアで乗り継ぎ便:に割り振ることができる。
【0033】
・アクセレレータの構築
この編成に加えて、本発明の好ましい実施形態によるシステムは旅行の推奨に関するメタ情報のみを含む追加のデータセットを生成する。これらのデータは極めて高速の検索の達成に役立つ。例えば、メタ情報のデータセットは出発都市から到達可能な都市及び到達可能な都市毎の都市ペアに対する最安価額を収容することができる。最終的には、検索はこの情報のおかげで回答返送前の多すぎる旅行の推奨の調査を避けることができる。
【0034】
・インデックスの構築
データベースのように、本発明の好ましい実施形態によるシステムは、高速アクセス時間を提供するために、データセットに加えてインデックスを構築する。事前計算航空旅行推奨に対して、検索基準は極めてオープンであり、所定の日にちの範囲内で、所定の価額範囲で、任意の目的都市に対して価額を検索することができる。1検索基準毎に1つのインデックスを生成する代わりに、本発明の好ましい実施形態によるシステムは、どのような検索基準であろうと同等に有効なデータアクセスを維持しながら1データセット毎に単一のインデックスを構築するために、周知の多次元データ構造(K−D−Bツリー)を使用する。このアプローチは使用される記憶量を制限する。2つの旅行プロバイダが共通の旅行の推奨を共有し、料金が公開である場合(旅行プロバイダの交渉価額に反して、特定のオフィスIDにのみ適用可能)、それらの料金はスペースの獲得及びハードウェアコストの低減のためにシステムストレージで共有することができる。
【0035】
・一貫性マネージャ
新しい旅行の推奨データが旅行推奨計算システム(例えばMCP)から得られるとき、対応するデータセットが新しい又は低い旅行の推奨データで更新され、それらのインデックスが再構築される。同時に、影響を受けたデータセットが旅行の推奨に対して選択され得る。
【0036】
継続中の検索に対する(性能及び一貫性に関する)影響を阻止するために、フィードエンジンはデータセットの改定を管理する。検索がデータセットの改定nに対して実行されている間、フィードエンジンは改定n+1を構築する。改定されたデータセットが構築され、インデックスされると、そのデータセットは検索のための新しい基準データセットになる。前データセットはすぐ後で、データセットをホストする分散システム内の全ての物理的マシンの記憶メモリから除去される。これにより、これらのデータは継続中の検索が終了するまで、これらの検索に対して使用可能に維持され、よって一貫性の問題が防止される。
【0037】
図4は検索エンジン107(
図1参照)を示す。検索エンジンはユーザからの航空旅行要求を受信し、最善の推奨を返送するために全データを潜入調査する。このプロセスはいくつかのステップで行われる。
【0038】
・サーバアフィニチィ
入力する検索要求は本発明の好ましい実施形態によるシステムにより提供される特定の検索プロダクトによって処理されなければならない。この点から、この要求はこの要求に応答する必要があるデータを含む物理的マシンへ送られなければならない。航空旅行の推奨は、フィードエンジンによってそれらの推奨を目的としている検索プロダクトの特異性に基づいて物理的マシンへ発送される。検索エンジンは反対動作を実行し、応答のために検索クエリーを解析し、そのタイプに基づいて検索すべきデータ及びそれが位置する物理的マシンを決定する。
【0039】
・検索ドメインの決定
検索要求が関連する物理的マシンへ送られると、検索エンジンはデータセットを決定し、検索クエリーに関連するメタ情報を見つける。メタ情報は検索クエリーに対する可能な回答を含む航空旅行の推奨のすべてのデータセットを見つけ出すために使用される。
【0040】
・検索実行
すべての可能な航空旅行の推奨が見つけだされると。検索エンジンは、検索クエリーで表現されている基準、例えば価額範囲、日にち範囲、航空会社等、に基づいて最善の旅行の推奨を収集するために、すべての多次元インデックスを解析する。検索エンジンはすべての可能な旅行回答を検索する必要はないことを決定するために以前のメタ情報を活用することができる。例えば、特定の都市NCEからの出発便の最善価額を要求する検索クエリーを想定しよう。検索中に目的都市PARまでの旅行は100ユーロであることが解ったとしよう。メタ情報が都市NYCまでの最低価額は500ユーロであると明記している場合、検索エンジンはNCEからNYCまでの旅行の回答を検索しようとさえしない。これは検索トランザクションの応答時間をさらに低減する。
【0041】
・関連検索
何の旅行の推奨も返送しない検索実行ステップの場合には、ユーザクエリーは限定的すぎ、一致の欠落の理由が先に考慮された各都市ペアにつき解析される。例えば、フライトが指定の日にち範囲内にない、又はフライトはあるがクエリーに提示された価額上限より高い、などの理由があり得る。
【0042】
ユーザクエリーが限定的すぎる場合には、検索エンジンは、もとのクエリーに提示された制約に密接に関連する推奨を返送するために後退ストラテジを実行する。この後退ストラテジは制約を複数のパラメータについて緩め(より広い日にち範囲、より高い価額上限・・・)、検索実行ステップに戻るものである。このループは、いくつかの推奨が見つかったとき、設定再試行回数に達したとき又は再試行のための最大許可時間に達したときに終了する。
【0043】
後退ストラテジが何の推奨も返送しない場合には、適用可能な場合に別の後退ストラテジが実行される。要求された目的地が地理的意味(例えば、都市、国)を有する場合には、検索エンジンは、地理的に近い地域を決定するためにGDS(本発明の一部分ではない)により提供されるジオグラフィックサービスを利用し、上述したようにもとのクエリーの目的地制約を広げ、検索実行ステップに戻ることができる。両後退ストラテジとも推奨の検索に失敗した場合には、空の結果が返送される。
【0044】
・旅行回答の集約
検索クエリーに対するすべての回答が見つけ出されると、検索エンジンは異なるデータセットから返送されたかもしれない同一の結果の併合へ移動する。このケースは、例えば検索が最も安い直行便を含むデータセット及びすべての便(直行便及びストップオーバ付き)を含む別のデータセットを調査しなければならない場合に生じる。
【0045】
最後に、見つけ出された旅行回答は検索クエリーの要件に基づいて編成され:回答を目的地(都市)別、日にち別、上昇価額別、航空会社(直行便又は乗り継ぎ便)別にグループ化する。
【0046】
図5は、学習エンジン109(
図1参照)を示す。学習エンジンは学習及び統計データベースを含む。学習エンジンの目的は、価額が頻繁に変化しない、従って正確さを維持するために頻繁な再計算を必要としない航空旅行を検出することにある。
【0047】
学習エンジンは航空旅行フライトの一般的な特性(日々スケジュール化されるフライトの価額は極めて変わりやすいという特性)に関する論理的解析に基づき、即ち、同じフライト(同じ出発日)が1日後に再びプライシングされる場合、その価額は変えられやすい。これに反し、数ヶ月先までスケジュールされているフライトの価額は、1日後又は1週間後に再びプライシングされる場合、変えられそうもない。学習エンジンは上述した特性に基づいて変動モデルを各マーケットに関連付ける。学習エンジンは毎日受信する旅行の推奨に基づいて変動モデルを維持する(及び必要に応じそれを調整する)
【0048】
・旅行の推奨の価額の記録
入力旅行推奨が受信されると、それらは複製され、一つのコピーは学習エンジンへ送られる。旅行の推奨はマーケット別にグループ化され、即ち1つの都市ペア毎に、来年の日にち毎にグループ化される。システムは小さい日にち範囲内で変動しやすいフライトのみを再計算するように旅行推奨計算システム(例えばMCP)に命令することができるため、1年のすべての日が推奨を生じるわけではない点に注意されたい。
【0049】
学習エンジンは入力旅行推奨の価額を抽出し、それらをそれらの計算日時と一緒に専用の学習データベースに記録する。それらの価額は将来の航空旅行データ統合のために価額比較用の基準として作用する。
【0050】
・マーケットデータのロード及び変動モデルの調整
学習エンジンは入力マーケットに対してその専用データベースにすでに格納されているすべての価額をロードする。学習エンジンは保存価額を利用可能な入力価額と比較する。
【0051】
学習エンジンはマーケットに対する変動モデルを価額比較の結果に適応させる。2つの同一のフライトが異なる価額を有するとき、その差が学習データベースに統計データとして記憶される。その差が過度に頻繁に起こるとき、変動モデルは更新され、日にち範囲は高変動としてマークされる。変化頻度に関する統計データを記憶することは休暇シーズンなどの定期イベントによる価額変化の影響を緩和するのに役立つ。2つのフライトが変動モデルに基づいて予測される期間より長い期間に亘って同じ価額を有する場合には、変動モデルは更新され、日にち範囲は低変動としてマークされる。
【0052】
・変動率報告の生成
すべての入力旅行推奨の解析が完了すると、学習エンジンはここに記載する分散検索プラットフォームに丁度組み込まれたデータの改定変動率を含む報告を生成する。変動率報告は顧客ID(データのプロバイダ)毎に生成され、マーケット毎、出発日毎に編成される。
【0053】
生成された報告は報告コーディネータという別のエンジンに送られる。後者は、最終的にこの情報ソースを使用して、航空旅行の推奨のどのサブセットを旅行推奨計算システム(例えばMCP)上の利用可能なコンピューティングリソースに基づいて再計算すべきかを決定する。
【0054】
図6は人気エンジン111(
図1参照)を示す。人気エンジンは人気データベースを含む。検索要求の入力時に、人気エンジンはユーザトランザクションから検索トレンドを抽出するチャンスを得る。これはシステムに格納された旅行価額の人気に関する洞察を与えてくれる。その解析は以下のステップで実行される。
【0055】
・入力及び出力の解析
入力検索クエリーは検索エンジンに達する前に複製され、1つのコピーは人気エンジンに入る。対照的に、検索トランザクションの出力はユーザに返送される前に複製され、1つのコピーは人気エンジンに入る。
【0056】
人気エンジンはいくつかの人気メトリクスを得るためにトランザクションの入力及び出力の両方を解析する。この解析は入力検索クエリーの基準に応じて異なる情報を生成する。例えば、
検索クエリーが特定のマーケット(都市ペア)に対する旅行の推奨を要求する場合、エンジンはクエリーからマーケット毎に出発日の人気ランキングを抽出することができる。
検索クエリーが一つの出発都市から旅行の推奨を要求する場合、エンジンは回答から出発都市毎及び日にち範囲毎に好ましい目的都市のランキングを抽出することができる。
【0057】
・データベースへの統計データの格納
入力クエリー及び出力回答から抽出されたトレンドは専用の人気データベースに格納される。この格納データは種類毎に分散されるため、どの物理的マシン(人気エンジンが動作する場合)もシステムの他の物理的マシンで生成されるデータの恩恵を受けることができる。
【0058】
・記録の集約及び人気報告の生成
平行して、人気エンジンの反復ジョブが、分散されたデータベースからすでに計算された統計データを抽出し、いくつかの組織的な人気メトリクスを生成する。
【0059】
例えば、人気解析された検索クエリーの総数に基づいて、人気マーケットのランキング、即ち入力クエリーにより最もターゲットにされたマーケット、出力旅行回答で返送されたより安いマーケット・・・を抽出する。別の可能性として、1年を通して所定の日にち範囲に対して最も人気のあるマーケットに関する統計データを生成する、休暇シーズンのような特定のイベントに対するトレンドを抽出する、又は世界中の異なる地理的地域に対して最も人気のあるマーケットに関する統計データを生成する。この精緻化はより適切な人気測度(例えば国内便・・・に関して)を抽出するのに役立つ。生成された報告は人気メトリクスへのアクセスを与えるために報告コーディネータに送られる。
【0060】
図7は精度エンジン113(
図1参照)を示す。精度エンジンは価額精度データベースを含む。精度エンジンの目的は、事前計算された航空旅行の推奨を管理し、それらの価額が実際の(即ち現在の)ショッピング価額から過度に大きく外れるものを検出することにある。このエンジンの原理は、外部のアマデウスショッピングサービス(本発明の一部分ではない)を使用してトランザクションを実行し、返送された価額を旅行の推奨のキャッシュの価額と比較することにある。
【0061】
このエンジンはいくつかのステップで動作する。
【0062】
・調整パスを有する入力及び出力トランザクションの使用
人気エンジンと同様に、精度エンジンは複製した入力検索クエリー及び出力旅行回答のコピーを受信する。大きなハードウェアコスト及び応答時間を要する多すぎる実際のショッピングトランザクションの実行を避けるために、ここに記載される分散検索プラットフォームを通るナチュラルトラフィックのサブセットに調整パスが適用される。
【0063】
・料金検索トランザクションの生成
精度エンジンはシステムに格納されている旅行の推奨の代表的なサブセットを解析するのに十分な程度に多様化された検索トランザクションを生成しなければならない。そのために、この生成ストラテジは2つある。
【0064】
旅行人気度に基づく料金検索トランザクション:精度エンジンは人気データベース(先に提示)にアクセスし、出力回答の人気度を解析して、最も人気のある回答のみを更なる解析のために保持する。これによりユーザに経験されるキャッシュ価額対ショッピング価額に関する一貫性が最大になる。
【0065】
旅行の推奨のキャッシュの内容に基づくランダムトランザクションの生成:解析のための旅行のランダム選択は旅行の推奨の全キャッシュの最終精度を得るためである。これは、多くの場合ハードウェアコストの制限が少なくなるが、人気のないフライトの精度もモニタされるため、良い旅行の発見をユーザに確実にする。
【0066】
・データの集計
集計された精度メトリクスは専用の分散精度データベースに格納される。反復ジョブがすべての精度メトリクスをいくつかの報告(顧客別、マーケット別、出発日別、・・・の回答の精度)に整理併合し、それらを更なる利用のために報告コーディネータに送る。
【0067】
図8は報告コーディネータ115(
図1参照)を示す。報告コーディネータは本発明の好ましい実施形態によるシステムの最終ビジネス解析エンジンである。その役割は、プラットフォーム内のデータのどの部分を、上述のエンジンにより報告されたすべてのメトリクスに基づいて、旅行推奨計算システム(例えばMCP)上の利用可能な計算リソースに従って再計算すべきかを決定することにある。
【0068】
再計算の決定はいくつかのステップで実行される。
【0069】
報告の格納
入力変動性、人気度及び精度報告からのすべてのメトリクスは専用の報告データベースに局所的に格納される。この格納は、報告コーディネータが前メトリクスに基づいてその決定を行うために必要である。例えば、報告コーディネータは変動性の報告に基づいて旅行の推奨のキャッシュに格納されたデータの年齢を推測する。この情報は報告データベースに保存される。
【0070】
再計算の決定
報告コーディネータにより実行される決定は、キャッシュ対計算システム(例えばMCP)上の計算リソースのデータの精度をバランスさせるためにヒューリスティック探索に基づく。
【0071】
この基本アプローチは、最も低い精度のキャッシュされた旅行の推奨を計算システム(例えばMCP)上の所与の利用可能なリソースで再計算するものである。最も低い精度のデータのうちの最も人気のあるものが再計算命令の生成のために最初に考慮される。
【0072】
再計算の候補は、フライトドメイン(マーケット毎の近接データ範囲)内の隣接する旅行のグループを形成するために、報告コーディネータにより選択される。これにより、旅行推奨計算システムはいくつかの再計算を相互的にすることができ、そのリソース消費をさらに最適にすることができる。
【0073】
報告コーディネータは、MCP内のすべての残存データの予測精度を更新するために、各再計算命令の間に変動性モデル(報告データベースに格納されている)及び旅行の推奨の推定年齢を利用する。
【0074】
図9を参照すると、本システムの汎用コンピュータ(例えばコンピュータ、予約サーバ、データベース管理サブシステム、ルータ、ネットワークサーバ)が950で示されている。コンピュータ950は、システムバス953に並列に接続された幾つかの装置で構成される。詳細には、1つ以上のマイクロプロセッサ956がコンピュータ950の動作を制御し、RAM959がマイクロプロセッサ956により作業メモリとして直接使用され、ROM962がコンピュータ950のブートストラップ用基本コードを格納する。周辺装置はローカルバスの周囲に(それぞれのインターフェースを介して)集合的に接続される。特に、マスメモリはハードディスク968及びCD−ROM974を読み取るドライバ971からなる。さらに、コンピュータ950は入力装置977(例えば、キーボード及びマウス)、及び出力装置980(例えばモニタ及びプリンタ)を含む。ネットワークインターフェースカード983はコンピュータ950をネットワークに接続するために使用される。ブリッジ装置986はシステムバス953とローカルバス965とをインターフェースさせる。マイクロプロセッサ956及びブリッジ装置986の各々は情報を送信するためにシステムバス953へのアクセスを要求するマスタエージェントとして動作し得る。アービタ989はシステムバス953への相互排除アクセスの許可を管理する。システムが異なるトポロジを有する場合にも、他のネットワークに基づく場合にも、同様の考察が当てはまる。また、コンピュータは異なる構造を有するもの、同等の装置を含むもの、又は他のデータ処理エントリ(例えばPDA、モバイルフォンなど)からなるものとし得る。
【0075】
上述した方法は
図10に示す図でも示される。本方法はプレショッピングツール(即ち非拘束旅行クエリーによる定価付き旅行の推奨を生成するショッピングツール)であり、このツールは複数のパラメータに従って旅行アベイラビリティ及び料金に関する情報を含む複数の旅行データベースへアクセスする分散予約システム内で動作する。各旅行クエリーは一組の好みを含み、各好みは複数のパラメータから選択される1つのパラメータに関連する。分散予約システムは複数の高速アクセスメモリ域を含み、これらのメモリ域に選択された旅行の推奨が維持されるため、ユーザはそれらのクエリーに高速応答することができる。我々はこれらの高速アクセスメモリ域を「事前計算された旅行の推奨からなるキャッシュ」と言う(当業者がこの表現は、キャッシュとは対照的に、高速アクセスメモリに格納される内容が旅行カタログ全体を表し、カタログの最もアクセスされる旅行からなる部分のみを表すものでないため、技術的に完全には適切でないと認識するとしてもである)。言い換えれば、ここで言うキャッシュは「ショッピングトランザクションキャッシュ」に関連する。同様に、高速アクセスメモリ域に記憶される情報は「キャッシュ情報」(例えば、キャッシュされた旅行の推奨)と言う。事前計算された旅行の推奨のキャッシュに関連する問題は、推奨に含まれるデータをそれらの価額とショッピング中に見出される実際の価額との一貫性を維持するために更新しなければならないことにある。これは(時間的にもシステム性能的にも)極めて費用がかかる活動であり、情報の一貫性とシステムの性能との間でバランスを取らなければならない。本発明の主な特徴の1つは、様々な旅行の推奨が同時に、同じ頻度で更新されないで、「頻度」スコアが各旅行の推奨に指定され、それに従って更新がスケジュール化され、より変動しやすい情報はより頻繁にリフレッシュされる。
【0076】
本方法は黒丸1001で開始し、次にボックス1003に進み、ここでシステムは事前計算された旅行の推奨の選り抜きからなるキャッシュを複数の高速アクセスメモリ域に保持する。各旅行の推奨は特定の旅行に対する料金及びアベイラビリティに関する情報を含み、複数のパラメータの少なくとも1つで分類される。キャッシュされた旅行の推奨の分類及びインデックス付与は上述したように幾つかの方法で実行でき、これは正しい情報を可能な最短時間で識別するために重要である。次に、必要なリフレッシュ頻度を表すスコアがキャッシュされた旅行の推奨の各々に指定される(ステップ1005)。このスコアは、情報のリフレッシュを実行すべき時を決定するために使用される。本発明の好ましい実施形態によるリフレッシュ(ステップ1009)は上述したようにバッチ処理で実行され、本発明の好ましい実施形態では、マッシブクエリーが専用のサブシステム、例えば上述したマッシブ計算プラットフォームのような専用の旅行推奨計算システムによって開始される。このようなマッシブクエリーの送出(ステップ1007)は固定の時間で実行される、又はユーザにより実行されるようにでき、また特定のイベントによりトリガされるようにでき、例えばマッシブクエリーが所定の期間毎に(例えば毎日又は毎時間の終了時に)実行される、限界量のクエリーが受信された時又は最大容量に到達した時に自動的に実行される、システムの管理者またハードウェア旅行プロバイダにより要求されるようにすることもできる。ユーザクエリーが受信されると(ステップ1011)、システムは最初に高速アクセスメモリ域内の検索を試みる(ステップ1013)。何の回答も見つからない場合(ステップ1015)、オプションの後退処理が開始され得る(ステップ1017)。後退処理が提供されない場合には、ユーザへのメッセージが何の結果も得られないことを通知する。或いはまた、ユーザクエリーが限定的すぎることを考慮して、新たな検索を調整されたパラメータで開始することができ、こうして適合の欠落の理由が先に考慮された各都市ペアに対して解析される。例えば、理由としては、指定の日にち範囲内にフライトがない、又はフライトはあるがクエリーで指定された限界価額より高い、などがある。ユーザクエリーが限定的すぎる場合には、検索エンジンは、もとのクエリーで指定された制限に密接に関連する推奨を返送するために後退ストラテジを実行する。それは複数のパラメータの制限を(より広い日にち範囲、より高い価額制限・・・に)緩和し、検索実行ステップに戻る。このループは、幾つかの推奨が見つかったとき、指定の再試行回数に達したとき、又は再試行の最大許容時間に達したときに終了する。後退ストラテジがいかなる推奨も搬送しない場合には、適切な場合に別の後退ストラテジが実行される。要求された目的地が地理的意味を持つ場合(例えば、都市、国)には、検索エンジンは地理的に近い地域を決定するために、GDS(本発明の一部ではない)により提供されるジオグラフィックサービスを利用し、もとのクエリーの目的地制限を広げ、検索実行ステップに戻る。両後退ストラテジが推奨の検索に失敗した場合には、空の結果が返送される。さらに別の可能なソリューションは、要求された旅行の推奨を見つけ出し事前計算された旅行の推奨のキャッシュを豊富化させるために外部のデータベースに対するクエリーを送出することにある。結果が得られる場合には、事前計算された旅行の推奨のキャッシュがこの新しい情報で豊富化される。いかなる場合にも、応答がユーザに発行される(ステップ1019)。旅行の推奨のスコアも更新を必要とするかもしれない。ここに記載する実施形態では、プレショッピング情報、即ち、旅行アベイラビリティ、料金、時間又は必ずしも予約達成向けでない一般的情報を探すためにクエリーがユーザにより送信される。本発明の好ましい実施形態では、クエリーを受信し、ユーザクエリーを満足するデータベースの問い合わせを実行するシステムは実際の予約システムとは別個であるが、2つのシステム(プレショッピング及び予約)は1つに統合することができることは当業者に認識されよう。
【0077】
上述したシステムは開示の範囲から逸脱することなく多くの変更及び修正が可能であることが認識されよう。当然のことながら、当業者は、ローカル及び特定の要件を満足するために、多くの変更及び修正を上述したソリューションに加えることができる。特に、本開示は本発明の好ましい実施形態を参照してある程度の特殊性を記載しているが、形式及び細部の様々な省略、置換及び変更並びに他の実施形態が可能であることを理解すべきである。さらに、本発明の開示の実施形態と関連して記載された特定の要素及び/又は方法のステップは他の任意の実施形態に設計上の選択の一般的事項として組み込むことができることが明確に意図されている。
【0078】
プログラム(開示の各実施形態を実装するために使用できる)を種々の方法で構造化する場合又は追加のモジュール又は機能を設ける場合にも同様の考察が当てはまる。同様に、メモリ構造は他のタイプのものとする又は同等の個性要素(必ずしも物理的記憶媒体からなるものとは限らない)と置換することができる。さらに、提案のソリューションは対応する方法(同様の又は追加のステップを異なる順序でも有する)で実現するのに適している。いずれにせよ、プログラムはデータ処理システムで又はそれと関連して使用するのに適した任意の形態、例えば外部又は常駐ソフトウェア、ファームウェア又はマイクロコード(オブジェクトコード又はソースコード)の形態にすることができる。さらに、プラズマは任意のコンピュータ使用可能な媒体に設けることができ、この媒体はプログラムを含有、格納、通信、搬送又は転送するのに適した任意のよそとすることができる。このような媒体の例には、固定ディスク(この場合にはプログラムは予めロードすることができる)、リムーバブルディスク、テープ、カード、ファイバ、無線接続、ネットワーク、放送波等があり、例えば媒体としては電子、磁気、光、電磁気、赤外又は半導体の各タイプがある。
【0079】
いずれにせよ、本発明によるソリューションはハードウェア構造(例えば半導体材料のチップに集積されている)又はソフトウェアとハードウェアの組み合わせで実施するのに適している。