(57)【特許請求の範囲】
【請求項１】
-少なくとも1つのルール属性を指定する運賃照会を受信するステップと、
-前記少なくとも1つのルール属性に適用可能なルールデータを決定するために第1検索を実行するステップと、
-前記ルールデータに適用可能な運賃リストを決定するために、前記ルールデータを使用して第2検索を実行するステップとを備え、
前記第2検索が、並列に実行されるN個の検索処理として実行され、前記決定された運賃リストが、それぞれの前記N個の検索処理から出力されたリストから取得された統合されたリストであり、
前記第2検索を実行するステップが、-残ったルールごとに、運賃データベースから運賃を取り出すために、複数の並列データ収集サブプロセスとしてデータ収集サブプロセスを実行して、複数の運賃リストを生成するステップと、-前記複数の運賃リストを最終的な運賃リストに統合して、前記最終的な運賃リストを前記受信した運賃照会への応答として出力するステップとを備え、
前記データ収集サブプロセスを実行するステップが、前記複数の並列データ収集サブプロセスごとに、-1つのルールカテゴリシーケンスから、対応する運賃キーのリストを取り出すステップと、-運賃キーごとに、運賃および関連付けられる運賃アプリケーションエンティティを取り出して、運賃レコードを形成するために一致するルールカテゴリシーケンスを統合するステップと、-それぞれの運賃レコードを、対応するルールカテゴリ、および前記少なくとも1つのルール属性に対応するルール規定データと照合するステップと、-それぞれの運賃レコードシーケンスを、前記ルールカテゴリシーケンスに対して照合して、前記第1検索の間に事前に識別されたそれらの運賃レコードを保持するステップと、-ルールカテゴリシーケンスデータに対応するルール規定データを取り出して、前記ルールカテゴリシーケンスデータを、前記運賃レコードおよびルール属性に対して照合して、一致が発生する運賃レコードだけを運賃リストに格納するステップとを備え、前記複数の並列データ収集サブプロセスが、冗長な動作の実行を回避するために非同一データドメイン上で動作する、ことを特徴とする、少なくとも1つの運賃を取り出すためのコンピュータ実装方法。
【請求項２】
Nの値が、前記第1検索の間に識別されたいくつかのルール、およびあらかじめ定められたしきい値のセットに基づいて決定され、Nが1と等しいか、または2以上の整数である、請求項１に記載の方法。
【請求項３】
前記第1検索を実行するステップが、-制限ルール属性によるルールを取り出すための編集サブプロセスを実行して、関連付けられるルールカテゴリおよびルール規定を取得するステップと、-適用できないルールを除去するためにそれぞれの取り出されたルールがフィルタリングされる、プリデータ収集サブプロセスを実行して、残ったルールを格納するステップとを備える、請求項１または２に記載の方法。
【請求項４】
前記複数の運賃リストを統合するステップが、重複する運賃レコードをソートして除去することによって、それぞれの前記複数の並列データ収集サブプロセスから出力された前記運賃リストを前記最終的な運賃リストに統合するステップを備える、請求項１に記載の方法。
【請求項５】
前記ルールデータを決定するために前記第1検索を実行するステップが、復号化されたルール指定データを表す機能インデックスの直接的照合を使用するステップを備え、ルール属性とルールとの間に直接関連を提供するためにデータスキャニングアクセラレータを使用して実行される、請求項１から４のいずれか一項に記載の方法。
【請求項６】
ソフトウェアプログラム命令を含む、非一時的コンピュータ可読媒体であって、少なくとも1つのデータプロセッサによって前記ソフトウェアプログラム命令の実行がされると、請求項１から５のいずれか一項に記載の方法の実施を備える動作が実行されることになる、非一時的コンピュータ可読媒体。
【請求項７】
-少なくとも1つのデータプロセッサと、
-前記データプロセッサに接続された、前記少なくとも1つのデータプロセッサによって実行可能なコンピュータソフトウェアを格納する少なくとも1つのメモリと、
-少なくとも1つの運賃を適用できる条件を確立する複数の運賃およびルールを格納する少なくとも1つのデータベースと、
-少なくとも1人のユーザから運賃照会を受信するように構成された、前記ユーザへのインターフェースとを備えるデータ処理システムであって、
-前記データプロセッサが、前記データ処理システムに、少なくとも1つのルール属性を含む運賃照会を受信させ、前記少なくとも1つのルール属性に適用可能なルールデータを決定するために第1検索を実行させ、前記ルールデータに適用可能な運賃リストを取り出すために前記ルールデータを使用して第2検索を実行させるための前記コンピュータソフトウェアで構成され、
-前記データプロセッサが、前記データ処理システムに前記第2検索を並列に実行されるN個の検索処理として実行させるための前記コンピュータソフトウェアでさらに構成され、前記決定された運賃リストが、それぞれの前記N個の検索処理から出力されたリストから取得された統合されたリストであり、
前記データプロセッサが、残ったルールごとに、運賃データベースから運賃を取り出すために、複数の並列データ収集サブプロセスとしてデータ収集サブプロセスを実行して、複数の運賃リストを生成するステップと、前記複数の運賃リストを最終的な運賃リストに統合して、前記最終的な運賃リストを前記受信した運賃照会への応答として出力するステップとによって、前記データ処理システムに前記第2検索を実行させるための前記コンピュータソフトウェアでさらに構成され、
前記データプロセッサが、前記複数の並列データ収集サブプロセスごとに、1つのルールカテゴリシーケンスから、対応する運賃キーのリストを取り出すステップと、運賃キーごとに、運賃および関連付けられる運賃アプリケーションエンティティを取り出して、運賃レコードを形成するために一致するルールカテゴリシーケンスを統合するステップと、それぞれの運賃レコードを、対応するルールカテゴリ、および前記少なくとも1つのルール属性に対応するルール規定データと照合するステップと、それぞれの運賃レコードシーケンスを、前記ルールカテゴリシーケンスに対して照合して、前記第1検索の間に事前に識別されたそれらの運賃レコードを保持するステップと、ルールカテゴリシーケンスデータに対応するルール規定データを取り出して、前記ルールカテゴリシーケンスデータを、前記運賃レコードおよびルール属性に対して照合して、一致が発生する運賃レコードだけを運賃リストに格納するステップとによって、前記データ処理システムに前記データ収集サブプロセスを実行させるための前記コンピュータソフトウェアでさらに構成され、前記複数の並列データ収集サブプロセスが、冗長な動作の実行を回避するために非同一データドメイン上で動作する、ことを特徴とする、データ処理システム。
【請求項８】
Nの値が、前記第1検索の間に識別されたいくつかのルール、およびあらかじめ定められたしきい値のセットに基づいて決定され、Nが1と等しいか、または2以上の整数である、請求項７に記載のデータ処理システム。
【請求項９】
前記データプロセッサが、制限ルール属性によるルールを取り出すための編集サブプロセスを実行して、関連付けられるルールカテゴリおよびルール規定を取得するステップと、適用できないルールを除去するためにそれぞれの取り出されたルールがフィルタリングされる、プリデータ収集サブプロセスを実行して、残ったルールを格納するステップとによって、前記データ処理システムに前記第1検索を実行させるための前記コンピュータソフトウェアでさらに構成される、請求項７または８に記載のデータ処理システム。
【請求項１０】
前記データプロセッサが、前記データ処理システムに、重複する運賃レコードをソートして除去することによって、それぞれの前記複数の並列データ収集サブプロセスから出力された前記運賃リストを前記最終的な運賃リストに統合するステップを備える前記複数の運賃リストの統合を実行させるための前記コンピュータソフトウェアでさらに構成される、請求項７に記載のデータ処理システム。
【請求項１１】
前記データプロセッサが、ルール属性とルールとの間に直接関連を提供するためにデータスキャニングアクセラレータを使用して、復号化されたルール指定データを表す機能インデックスの直接的照合を使用することによって、前記ルールデータを決定するために前記データ処理システムに前記第1検索を実行させるための前記コンピュータソフトウェアでさらに構成される、請求項７から１０のいずれか一項に記載のデータ処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の例示的実施形態は、一般に、航空券予約を行うために使用されるものなどのコンピュータ化された予約システムおよび方法に関し、より詳細には、運賃を検出して取り出すための技法に関する。
【背景技術】
【０００２】
次の略語は、以下のように定義される。
ATPCo  Airline Tariff Publishing Company
GDS  グローバル流通システム(Global Distribution System)
IATA  国際航空運送協会(International Airline Transport Association)
OLTA  オンライン旅行代理店(Online Travel Agencies)
PNR  乗客名レコード(Passenger Name Record)
【０００３】
次の用語は、以下のように定義される。
運賃  所与の起点の位置から終点の位置までの旅行の価格を与える情報のセット。運賃は、運賃エンティティとも呼ばれうる。
運賃キー  運賃のフィールドを識別する。
ルール  運賃を適用できる条件のセット。ルールは、ルールエンティティとも呼ばれうる。
レコード1  運賃アプリケーションエンティティ:運賃を補完して、運賃の利用基準(たとえば、運賃が有効な曜日または季節)を記述するデータのセット。所与のレコード1にm個の運賃が対応でき、それぞれの運賃はレコード1で定義された利用基準から継承する。
レコード2  ルールカテゴリ(季節性、最低滞在日数など)。
レコード3  ルール規定:ルールカテゴリによって使用されるデータ/値(たとえば、季節性ルールカテゴリでは、ルール規定は「夏」でありうる)。
FareRec1  追加のレコード1情報を備えた運賃
【０００４】
運賃見積もりの目的は、ある旅程についての料金表をユーザに提供することである。このような料金表は、上記で定義された運賃およびルールエンティティに基づいて計算される。
【０００５】
図1に示されるように、標準的な運賃見積もりは、入力データを使用して達成される有益なディスプレイコンテキストを提供する。これらの入力データは、次のように分類されうる。
【０００６】
運賃見積もりにおいて検索基準として使用され、処理を開始するための旅程入力データ(または旅程属性)(たとえば、起点、終点、旅行の日程など)、ならびに運賃見積もり処理においてフィルタリング基準として使用される制限入力データ(または制限属性)。制限属性は、旅行者(たとえば、年齢、企業等)、および/または要求を送信している販売地点とリンクされうる。
【０００７】
現在、航空業界では、運賃見積もり処理/システムは、運賃見積もりを実行するために、まず運賃を取り出して、次いでルールを適用する。ルールの適用によって、システムは取り出した運賃をフィルタリングできるようになる。ルールの適用は、3つの主なステップに分解されうる。
【０００８】
第1ステップは、運賃アプリケーションの検索と、運賃と対応する運賃アプリケーションとの間の統合動作の実行とを含む。運賃アプリケーション(レコード1とも呼ばれる)は、運賃を補完して、運賃の利用基準(たとえば、運賃が有効な曜日または季節)を記述するデータのセットである。所与のレコード1にm個の運賃が対応でき、それぞれの運賃はレコード1で定義された利用基準から継承する。したがって、レコード1は因数分解された（factorized）運賃データを含み、運賃はその対応するレコード1なしには存在できない。
【０００９】
第2ステップは、ルールカテゴリ(レコード2とも呼ばれる)の適用を含む。ルールカテゴリは、たとえば、季節性、最少滞在日数等でよい。
【００１０】
第3ステップは、ルール規定(レコード3とも呼ばれる)の適用を含む。ルール規定は、ルールカテゴリによって使用されるデータ/値である(たとえば、季節性ルールカテゴリでは、ルール規定は>夏=でよい)。
【００１１】
ルールカテゴリおよびルール規定は、価格設定コンテキストに依存する適用ルールであり、運賃アプリケーションはコンテキストにかかわらず有効である。例を挙げると、その運賃アプリケーションに従って運賃Yは全ての曜日で有効であると仮定する。この運賃の見積もりが夏の間に行われる場合、ルールカテゴリおよび関連するルール規定は、その運賃の使用を週末のみに制限する。
【００１２】
ある条件下で、運賃は、運賃アプリケーションの制限された領域に適用される。その結果、運賃アプリケーションとルールカテゴリ/規定との両方に、ある共通概念が現れる場合がある。
【００１３】
図2は、従来の運賃見積もりおよび運賃見積もりエンジンの主なステップ/要素を示している。運賃を取得するために、旅程属性から開始して運賃が取り出される。次いで運賃アプリケーションが取り出されて、取り出された運賃と統合される。次いで、ルール規定の適用の後に、ルールカテゴリが適用される(制限属性を考慮して)。最終的な結果は、所望の運賃の出力である。
【００１４】
現在、航空会社がルールあるいはルールの更新のファイリングに起因する価格設定への影響が見えない点に問題がある。例を挙げると、航空会社が、欧州内の全ての旅行に有効なプロモーションを提案したいと仮定する。航空会社はルール内に割引をファイリングするが、欧州内の全てのマーケットで割引が利用できることをチェックする方法がない。
【００１５】
さらに、OLTAは、所与のルール特性を有する運賃のグローバルビューを見る可能性がない。たとえば、ルールにおいて、ある運賃を販売する権限を与えられた販売業者を定義することが可能である。しかし、これらの権限付与の通知がない場合、販売業者はこれらの運賃の販売が許可されているという事実に気付くことができず、したがってこれを無視してしまう。
【発明の概要】
【発明が解決しようとする課題】
【００１６】
本発明の実施形態によって、上記および他の問題が克服され、他の利点が実現される。
【課題を解決するための手段】
【００１７】
本発明の第1の態様では、例示的実施形態は、少なくとも1つの運賃を取り出すための、コンピュータ実装方法を提供する。本方法は、少なくとも1つのルール属性を含む運賃照会を受信するステップと、少なくとも1つのルール属性に適用可能なルールデータを決定するために第1検索を実行するステップと、ルールデータに適用可能な運賃リストを取り出すために、ルールデータを使用して第2検索を実行するステップとを含む。
【００１８】
本発明の他の態様では、例示的実施形態は、少なくとも1つのデータプロセッサと、データプロセッサに接続された、少なくとも1つのデータプロセッサによって実行可能なコンピュータソフトウェアを格納する少なくとも1つのメモリと、運賃のうちの少なくとも1つを適用できる条件を確立する複数の運賃およびルールを格納する少なくとも1つのデータベースと、少なくとも1人のユーザから運賃照会を受信するように構成された、ユーザへのインターフェースとを備えるデータ処理システムを提供する。データプロセッサは、データ処理システムに、少なくとも1つのルール属性を含む運賃照会を受信させ、少なくとも1つのルール属性に適用可能なルールデータを決定するために第1検索を実行させ、ルールデータに適用可能な運賃リストを取り出すためにルールデータを使用して第2検索を実行させるためのコンピュータソフトウェアで構成されている。
【００１９】
本発明の実施形態の上記および他の態様は、添付の図面とともに読めば、以下の発明を実施するための形態においてより明らかになる。
【図面の簡単な説明】
【００２０】
【図１】標準的な運賃見積もりの入力および出力を示す図である。
【図２】運賃見積もりエンジンによって実行される、標準的な運賃見積もりの主なステップを示す図である。
【図３】ルール階層およびルールの構成を示す図である。
【図４】ルール属性からの運賃検出の入力および出力を示す図である。
【図５】本発明の例示的実施形態による、コンピュータによって実行される処理を示す論理フロー図である。
【図６】ルール属性からの運賃検出の技術的な実装の全体図である。
【図７】データスキャニングアクセラレータの原理を示す図である。
【図８】ルールカテゴリ35の例を示す図である。
【図９】ルールカテゴリ35に関するアクセラレータの例を示す図である。
【図１０】編集サブプロセスの起動を示す図である。
【図１１】プリデータ収集サブプロセスの起動を示す図である。
【図１２Ａ】しきい値の例を示す図である。
【図１２Ｂ】図12Aのしきい値がタスクマネージャへの入力として示されている、N個のデータ収集サブプロセスの起動を示す図である。
【図１３】別のデータドメインの例を示す図である。
【図１４】統合サブプロセスの起動を示す図である。
【図１５】本発明の例示的実施形態を実装するために適した様々な構成要素を示す、簡略化されたシステムレベルのブロック図である。
【発明を実施するための形態】
【００２１】
本発明の例示的実施形態は、旅程情報なしに、ルール属性から基本運賃を取り出して、それによって上述の問題を克服する機能を提供する。
【００２２】
導入として、図3はルールの例示的構成を示している。この図では、ルール階層が示されており、あるルールはある関連カテゴリを有する。カテゴリXの場合、関連ストリングを有するルールシーケンスがあってよく、次にシーケンスとして表示されうる規定を有する。
【００２３】
図1および2に示される従来の標準的な運賃見積もりとは反対に、本発明の実施形態はデータベース環境におけるPNR情報を有していないルール手法を使用する。
【００２４】
例示的実施形態を使用することによって、アプリケーション(コンピュータに実装されたアプリケーション)は、1つのルール属性(または複数のルール属性の組合せ)によって影響を受ける運賃の視覚化を提供できるようになる。したがって、例示的実施形態は、あらかじめ定められたルールおよび関連するルール属性に少なくとも部分的に基づいて、少なくとも1つの運賃の識別、および/または検出、および/または検索を可能にする、コンピュータに実装されたシステムおよび方法を提供する。
【００２５】
図4を参照すると、動作中に、アプリケーションのユーザが、ユーザが関心のあるルール属性10を指定する。ユーザは、取得されるべきビューを制限するために、1つまたは複数のさらなるフィルタ12も提供しうる。さらなるフィルタ12は、たとえば、ユーザが運賃を視覚化したいマーケット(デフォルトでは、全てのマーケットが考慮されうる)、運賃の発行航空会社(デフォルトでは、全ての航空会社からの運賃が考慮されうる)、考慮するべきデータのソース(たとえば、アマデウス（販売業者Amadeus）のみからのデータ)(デフォルトでは任意のソースからのデータが考慮される)、およびデータを取り出す際に考慮されるべき有効期間(デフォルトでは、有効期間は[無期限の、現在の日付B]でよい)であってよい。
【００２６】
ルール属性10(検索基準およびフィルタリング基準)およびさらなる(他の)フィルタ12が、ルール属性処理/エンジン14が提供する運賃検出に入力され、ルール属性処理/エンジン14が、返答として所望の運賃16を出力する。
【００２７】
本発明の例示的実施形態は、いくつかの技術的領域において有用性を有し、ファイリングの論理、およびマーケット上にデータが拡散される方法をチェックする機能を提供することによって、たとえば航空会社とOLTAの両方のための監査ツールとして使用されうる。
【００２８】
したがって、実施形態は、その一態様において、ファイリングを容易にして最適化するために使用される補完ファイリングツールを提供するものとして見なすことができる。例示的実施形態は、更に、OLTAについての所与のルール特性を有する運賃のカタログのために使用されうる。
【００２９】
本発明の例示的実施形態の使用によって識別される運賃16のリストは、いくつかの有益な特性を示す。これらの特性は、たとえば、標準的な運賃見積もりの応用論理が尊重されることによる価格一貫性と、結果として得られる基本運賃が指定されたルール属性によって無効化されないことを処理が保証することによる保証された有効性と、所与のルール属性に一致する基本運賃の包括的リストが提供されることによる包括性とを含む。さらに、運賃16のリストを、リソース使用に関して最適化されたコストで提供でき、以下で詳細に説明するように動的な並列処理を使用するので、制御可能な処理時間で提供できる。
【００３０】
例示的実施形態は、いくつかの複雑性に関連する問題を解決する。たとえば、処理されるべきデータが一般的に大量であるために、少なくとも処理時間およびリソース利用に関して、性能問題が生じうる。
【００３１】
たとえば、知られているタイプのある生産データベースは、データの中でも特に、2億個を超える運賃、3百万個のルールカテゴリ、および50個の異なるタイプの3億個のルール規定を含む。さらに、結果を価格的に一貫させるために、標準的な運賃見積もりの応用論理を考慮する必要がある。
【００３２】
これらの問題を解決するための他の手法は、運賃エンジンまたはデータウェアハウスの使用などによって試みられる。しかし、価格設定トランザクションの実行は、可能性の数のために、包括的であることを保証されない。また、全てのマーケットの知識を有することが重要である。わずかなサンプルしか取得できない場合は、結果の信頼性は低い。しかし、包括的であるために多くのサンプルが取得されると、かなりの処理が必要になり、時間と費用がかかる。少なくとも、適用されるべき標準的な運賃見積もりの応用論理のために、データウェアハウス手法は十分ではない。
【００３３】
例示的実施形態は、たとえば監査ツールとして使用されうる。たとえば、航空会社(キャリア)が、欧州内の全ての旅行に適用されるべきプロモーションをファイルすると仮定する。入力において以下の情報が提供される。ルール属性:プロモーション(割引)、ならびにさらなるフィルタ:地理=欧州、およびキャリア=航空会社名。本発明の使用により、出力において航空会社(キャリア)のリスト、プロモーションの恩恵を受ける欧州内の基本運賃が提供される。したがって、航空会社は欧州内の全てのマーケットにプロモーションが好適に提案されていることをチェックして確認でき、したがってファイリングを有効化できる。
【００３４】
別の例は、運賃のカタログを取得するための使用に関する。特定のOLTAオフィスが、彼らが世界的に販売する権限を与えられた全ての運賃を知りたいと仮定する。以下の情報が入力として提供されうる。ルール属性:販売業者=OLTAオフィス識別子、およびさらなるフィルタ:なし。この場合の出力は、OLTAオフィスが権限付与された世界的な基本運賃のリストである。このようにして、OLTAオフィスは、そのオフィスが世界的に販売する権限を与えられた運賃のカタログを取得する。次に、少なくとも図5〜14に関連して、例示的実施形態をさらに詳細に説明する。
【００３５】
図5は、本発明の例示的実施形態の実装の全体的な機能図を示している。2つの異なるレベル(マクロレベルおよびデータレベル)で、2つの主なステップにおいて処理が実行される。第1ステップ20は関連検索ステップである。関連検索ステップ20では、所与のルール属性10に一致するルール規定が取り出されて(符号22)、スキャンされる。処理は、運賃キーまで動作する。符号24で、さらなるフィルタ12に基づいてルールカテゴリが取り出されて、符号26で、処理はルールによって決定される運賃28を取り出す。第1ステップ(関連検索ステップ20)の目的は、適格な運賃28を取り出すことである。
【００３６】
第2ステップ30はデータレベル(データアプリケーション-フィルタリングステップ)にあり、標準的な運賃見積もりの応用論理が適用される。このステップでは、取り出された運賃アプリケーションが運賃28と統合され(符号32)、符号34で、取り出されたルールカテゴリ24が適用され、符号36で、ルール属性(フィルタ基準)10に従ってルール規定が適用されて、運賃16の最終的なリストを得る。この第2ステップ30の目的は、識別された適格な運賃28が、入力において与えられるルール属性10によって無効にされていないことをチェックすることである。ルール属性によって無効にされていないことを保証するために運賃を知る必要があるので、2つのステップ20および30において処理を実行することは有利である。
【００３７】
上述の機能原則は、運賃はルール内に配置される属性から識別されることを述べている。しかし、運賃に到達するためにルール属性から開始することは、アプリケーションによって取り扱われるべきデータの量に関する問題と、少なくとも処理時間とメモリ空間の使用に関する関連性能問題とを生じさせる。従来の運賃見積もりシステムでは、ルール属性はフィルタ基準として使用され、検索基準として使用されないので、これらの問題は生じない。
【００３８】
したがって、大量のデータを有するデータベースコンテキスト内のルール属性からの運賃検出に関連するこれらおよび他の問題に対処するために、例示的実施形態が提供される。
【００３９】
この例示的実装形態では、図6に示されるように、ルール属性処理からの運賃検出は4つのサブプロセス、具体的には編集サブプロセス40、プリデータ収集サブプロセス50、データ収集サブプロセス60、および統合サブプロセス70に分割される。次に、これらのサブプロセスを順に簡単に説明する。
【００４０】
編集40:このサブプロセスでは、全てのルールが選択された属性で収集されて、作業ファイル42に格納される。これは、複数のサブデータベース(または、単にデータストレージ)46A〜46Cのコンテンツ(それぞれ、レコード2-ルールカテゴリ、アクセラレータ、およびレコード3-ルール規定)に基づいて制限属性からルールを取り出すステップ(符号44)を含む。編集サブプロセス40は、ルールとデータとの間の相互参照表に基づいて、データスキャニングアクセラレータを使用する。
【００４１】
プリデータ収集50:作業ファイル42内の事前に識別されたルールごとに、入力データ(さらなるフィルタ12)に対してルールがフィルタリングされる(符号52)。その結果は、ルール統合データ表54である。
【００４２】
データ収集60:事前に識別されたルールごとに、運賃62を取り出す。標準的な運賃見積もりの応用論理が適用されるのは、この点においてである。このサブプロセスは、中間データ検索およびデータキャッシングとともに動的な並列処理を使用することが好ましい。データ収集サブプロセス60は、複数のサブデータベース(または、単にデータストレージ)64A〜64C(それぞれ、運賃、レコード1-運賃アプリケーションエンティティ、およびレコード3-ルール規定)を使用する。符号66に運賃とレコード1とを統合する動作があり、符号68Aに運賃をルール属性10およびレコード3(ルール規定)と照合する動作があり、符号68Bに運賃リスト68Cとして出力される運賃リストを構築する動作がある。
【００４３】
これらの処理は、複数の同時に実行されるデータ収集サブプロセス60によって並列に実行され、したがって複数の運賃リスト68Cがあり、実行しているデータ収集サブプロセス60のそれぞれから1つの運賃リストが出力される点に留意されたい。
【００４４】
統合70:このサブプロセスでは、符号72で複数の運賃リスト68Cが統合され、最終的な出力が運賃16になる(図4を参照)。
【００４５】
次に、上述の4つのサブプロセス40〜70をより詳細に説明する。
【００４６】
サブプロセス1-編集40。編集サブプロセスは全てのルールデータを収集して、それらを作業ファイル42に格納する。ルールデータの検索は、後述するデータスキャニングアクセラレータを使用して実行されうる。
【００４７】
ステップ1:制限属性10からルールを取り出す。この入力に基づいて、レコード2のシーケンスおよびデータと、レコード3のデータ(所与のルール属性に対応する)のリストとが取得される。複数のデータベースアクセスを回避するために、これらのデータはこのステップの間に取り出される。次いで、それらのデータは、以下のステップの間に使用される作業ファイル42に格納される。
【００４８】
サブプロセス2  プリデータ収集50:プリデータ収集サブプロセスは、1つの事前に識別されたルールについて、そのルールが入力データに対してフィルタリングされるように動作する。次いで、残りのルール(フィルタリング後)がデータベース54に格納される。したがって、サブプロセス2はステップ2を実行して、さらなるフィルタ12によってルールをフィルタリングして、適用可能ではないルールを除去する。
【００４９】
サブプロセス3  データ収集60:データ収集処理は、1つの事前に識別されたルールについて、運賃データベース64Aから運賃が取り出されるように動作する。このサブプロセスは、処理時間を最適化するために並列化されることが好ましい。このサブプロセスの間に使用される並列化、ならびに中間データ検索およびメモリキャッシングを、以下でさらに詳細に説明する。このサブプロセスは、以下のステップを(並列に)実行する。
【００５０】
ステップ3(ルールから運賃を取り出す)は、１つのレコード2のシーケンスから、対応する運賃キーのリストを取り出す。ここで、さらなるフィルタを適用することもできる。
【００５１】
ステップ4(運賃とレコード1とを統合する)は、残りの運賃キーごとに、運賃(データベース64A)および関連付けられるレコード1のデータ(データベース64B)を取り出して、一致するシーケンスを統合する。結果として得られるエンティティは、FareRec1と呼ばれる。
【００５２】
ステップ5(運賃マッチング)は、それぞれの統合されたFareRec1を取り、それをデータベース64C(所与のルール属性10に対応する)からのレコード2およびレコード3のデータと照合する。次いで、サブプロセスはレコード2のデータを取り出して、それぞれのFareRec1シーケンスをレコード2のシーケンスに対して照合する。第１の一致レコード2のシーケンスが、編集サブプロセス40およびプリデータ収集サブプロセス50の間に事前に識別されている場合、FareRec1が保持される。
【００５３】
次いで、サブプロセスが、レコード2に対応するレコード3のデータを取り出して、FareRec1および入力において与えられるルール属性に対してレコード3のデータを照合する。このデータが一致する場合、FareRec1が保持される。全ての制御が有効である場合、保持されたFareRec1が出力リストに格納される。
【００５４】
ステップ6(運賃リストの構築)が、処理によって有効化された運賃を含む運賃リスト68Cを構築する。
【００５５】
サブプロセス4  統合70:統合サブプロセスは、N個のデータ収集処理によって生成された全ての運賃リスト68Cを集めて、あらゆる重複をソートして除去することによって全ての提供された運賃リスト68Cを統合するステップ7(運賃リストの統合)を実行する。上記で言及した、処理されるべきデータ(制限属性からルール規定を取り出すためにスキャンされた)の量に関する性能問題が、データベース内でデータが統合されるときに動的に構築されるデータスキャニングアクセラレータを使用することによって対処および解決される。さらなる性能問題は、取り出されたルール規定に関連し、ルール規定は可変の(かつ予測不能な)サイズのデータ量を有する。さらに、1つの取り出されたルール規定が、運賃の量を変動させる(数個から、場合によっては数百万個までの運賃)場合がある。この問題は、それぞれのN個のデータ収集処理が別々のデータドメインに(同時に)作業するデータ収集サブプロセス60にある並列処理を使用することによって、ならびに中間データ検索およびデータキャッシュを使用することによって対処および解決される。すなわち、本発明の例示的実施形態のある態様は、N個のデータ収集処理が、同じデータに対する冗長な動作の実行を回避するために非同一データセット(ドメイン)上で動作することである。
【００５６】
処理時間および処理リソース使用は制御可能であり、両方の態様間でバランスをとることが可能である。したがって、取り扱うべきデータの量が、全体的な実行に与える影響は限られている。
【００５７】
次に、図7を参照して、データスキャニングアクセラレータの原理をさらに詳細に説明する。ルール(図3にみられるような)はツリー構造で構成される。本発明の範囲では、ツリーの葉は入力(すなわち、ルール属性)として提供され、葉から根(すなわち、ルール自体)へツリーを通り抜ける必要がある。この動作は、機能インデックス82およびルール84、ならびに機能インデックス82およびルール84との同期動作を含む更新86を取得するためにスキャンするステップ80、ならびに書込み動作を含む。
【００５８】
運賃見積もり処理の固有の複雑さ(ATPCOによって定義される)によって、応用論理(たとえば、いくつかの属性の組合せ)の導入のために、単純なインデックス付け技法(関連データベースインデックス等)を使用することができなくなる。本発明の例示的実施形態による手法によって、既存の運賃見積もりシステムの設計から逸脱することなしに、このような機能が可能になる。例示的実施形態は、ルール特有の属性セット上に構築されたさらなる洗練された機能インデックスの挿入を使用し、それによってシステムが容易にかつ効率的に関連ルールを取り出すことが可能になる。これらのインデックスは、プリチェックの機能を果たすあらかじめ計算された結果の一部を含む。たとえば、このようなインデックスを通じて属性から取り出されたルールは、次にデータ適用処理(図6におけるステップ2)を通過する潜在的なルールである。さらに、ステップ2のデータ適用処理を通過できないようにするために、このようなインデックスを通じて属性から取り出されていないルールを事前に知ることができる。
【００５９】
好ましい実施形態では、属性セットごとに1つのインデックスがある(機能インデックス82とも呼ばれる)。ルール規定はカテゴリによって構成されるので、本明細書に記載の処理における検索基準であり、かつ同じカテゴリに属する属性のセットが、新しいインデックスを生成するために考慮される。
【００６０】
この処理を使用することの利点の１つは、ルール階層ツリーの全ての葉をスキャンし、次いでルールルートまでツリーを通り抜ける代わりに、データスキャニングアクセラレータがルール属性とルールとの間に直接関連(図6内のルール相互参照表54によって表される)を提供することである。
【００６１】
たとえば、運賃はいくつかの特定の販売業者によってのみ販売されうる。このタイプの制限は、特定のルールカテゴリにおいて符号化される(「交渉された運賃」カテゴリ35(Cat35))。販売業者を検索基準と見なすと、このセキュリティを符号化する多方面にわたるフィールド上に構築されたインデックスによって、所与の販売業者からの迅速なルール検索が可能になる。
【００６２】
それらの識別子のタイプに基づいて、販売業者はいくつかの方法で分類されうる。販売業者の分類のいくつかの非限定的な例には、以下のようなものがある。
地理(販売地点の地理的位置に基づいたセキュリティ)による分類、
IATA識別子(IATAによって標準化された識別子に基づいたセキュリティ)による分類、
GDS専売(proprietary)識別子(GDSによって管理される識別子に基づいたセキュリティ)による分類。
【００６３】
この多様性の1つの結果として、所与の販売業者識別子をカテゴリに格納されたデータと照合するための復号化段階が複雑になる場合がある。
【００６４】
図8は、ルールカテゴリ35の例を示している。この非限定的な例では、ルールカテゴリ35「AF/528/DZ25」は3つのセキュリティ表を含む。
セキュリティ表#1では、IATA識別子が使用される(IATA番号08491275)。
セキュリティ表#2では、販売業者コード0AF100とともに、地理的パラメータ(都市パリ、C PAR)が使用される。これは、特定の専売販売業者識別子(この場合、販売業者Amadeus S.A.S.を表すオフィスID 1A 0FRPAR100)に対応する。
セキュリティ表#3では、2つの地理的パラメータが使用される(国  ベルギー  N BE、および都市  ニース  C NCE)。
【００６５】
理解されうるように、多くのフィールドがインデックス付けされる必要があり、したがって更新の間ストレージ領域を消費してオーバーヘッドを導入するので、標準的なデータベースインデックス付けメカニズムはこの場合はそれほど効率的ではない。
【００６６】
照合は直接的でなく複雑なので、例示的実施形態によるシステムは、所与の販売業者から全ての一致するデータを取り出そうとはしない。代わりに、実行されるべき所望の検索に適した復号化されたフォーマットを含むインデックスが構築される。これらのインデックスによって直接的照合が可能になり、したがってこれらのインデックスの方がはるかに効率的である。さらに、大量のデータを処理しなければならないことを回避するために、販売業者ごとに別々のインデックスを構築でき、単一の販売業者について検索が実行されると、関連するインデックスだけが使用されうる。
【００６７】
図9は、図8に示されるルールカテゴリ35に関するアクセラレータの非限定的な例である。インデックスエントリごとに(4つが示されている)、全ての必要なデータが格納される(ここでは、ルールの識別子)。
【００６８】
この手法を使用することの利点はいくつかある。たとえば、検索の間は復号化する必要がなく、代わりに、実行する必要があるのは直接的照合だけであること、標準的なデータベースインデックス付けメカニズムを使用することが可能であること、データの量をいくつかのインデックスに分解することが可能であること、それぞれのインデックスエントリに関連付けられる全ての必要なデータを格納することによって、さらなるナビゲーションが回避されること、である。
【００６９】
次に、図6に示されるデータ収集サブプロセス60の並列処理の背後にある原理を説明する。上記で説明したように、取り出されたルール規定(上述のデータスキャニングアクセラレータを使用して行われた)を表すデータの量を扱うことは、重要な考慮事項である。結果としては、合計処理時間はデータの量に直接依存する。データ量が少ない限り、処理時間は許容されうる(たとえば数分間)。しかし、データ量が増加すると、処理時間が数分間よりも長く延長される場合があり、これは通常は許容できない。これはいくつかの理由で真である。たとえば、処理は生産データに対して動作しており、生産データは、処理を実行している間に変化する可能性が高い。同じく例として、レポートを要求する場合、一般的にユーザはできるだけ早くレポートを受信したい。
【００７０】
処理時間を減らすために、一旦ルール規定が取り出されると並列化が生じる。これらのルール規定は論理表55(図11に示される)に格納され、論理表55はそれぞれのデータをその処理の進行を示す状況に関連付ける。したがって、並列に作業している全てのインスタンスは、同じデータに対して複数回は動作しない。代わりに、図12Aに示されるあるあらかじめ定められたしきい値55Aに応じて、入力として論理表55内のデータを用い、処理がN個の処理に分割される。
【００７１】
それぞれのデータを識別するためにルール規定キーが使用され、それぞれの運賃および運賃アプリケーションが唯一のルール規定キーに対応するので、これは並列化されたインスタンスが、ドメイン間に重複のない全く別のデータドメインに対して動作することを保証する。
【００７２】
次に、ルール属性としての販売業者(カテゴリ35(Cat35))、および図6の4つのサブプロセス40〜70に関連する例を提供する。
【００７３】
図10を参照すると、タスクマネージャ90が、異なるサブプロセス(編集40、プリデータ収集50、データ収集60、および統合70)の起動および依存性を取り扱う。
【００７４】
図10は、タスクマネージャ90によるサブプロセス1(編集40)の起動を示している。上記の例(図9)で提供されるルールカテゴリ35に関するアクセラレータに基づいて、全てのルール(レコード2 カテゴリ35(Cat35)のリスト)が取得されて、作業ファイルに格納される(ルール42)。次いで、タスクマネージャ90が編集サブプロセス40から制御を再び担う。
【００７５】
図11は、タスクマネージャ90によるサブプロセス2(プリデータ収集50)の起動を示している。作業ファイルに格納された(ルール42)レコード2 カテゴリ35(Cat35)のリストが処理されて第1の表(ルール統合データ表54)となる。このステップで、いくつかのさらなるフィルタ12を適用できる。ルール統合データ表54に挿入されるルールの数が、専用の論理表55に格納される。この例では、挿入されるルールの数NB_INSERTED_RULES=3751であると仮定する。次いで、タスクマネージャ90は、プリデータ収集サブプロセス40から制御を再び担う。
【００７６】
処理の次のステップは、並列に起動されるべきデータ収集処理の数の決定であり(すなわち、Nの値が決定される)、次いで、タスクマネージャ90によるデータ収集サブプロセス60のN個のデータ収集処理3の起動が行われる。
【００７７】
タスクマネージャ90は、論理表55に格納された情報を考慮して、挿入されたルールの数と、起動されるべきデータ収集サブプロセスの数を決定する、あるしきい値とを比較する。図12Aは、起動されるべきデータ収集処理の数(NB_DATA_COLLECTION)に対するしきい値(NB_INSERTED_RULES)の例を示している。たとえば、NB_INSERTED_RULES=1050の場合、Nの値は2に設定され、NB_INSERTED_RULES = 2500の場合、Nの値は3に設定される。これまで考えられた例では、NB_INSERTED_RULES = 3751であることを考慮すると、タスクマネージャ90は3つのデータ収集処理を起動する。
【００７８】
図12Bは、タスクマネージャ90によるサブプロセス3(データ収集60)の起動を示している。それぞれの起動されたデータ収集処理は、ルール統合データ表54からデータを取得して、処理するレコード2 カテゴリ35(Cat35)を留保する。そうすることによって、他のデータ収集処理はこれらのルールを考慮に入れず、したがって別のデータドメインに対して動作する。このようにして、レコード2を介して取り扱われるべきデータのドメインを決定することによって、図13に示されるように、それぞれのデータ収集処理が異なるレコード1、運賃などに動作することを保証できる。
【００７９】
それぞれのデータ収集サブプロセスは、そのプロセスによって有効化された運賃のリスト68Cとしてその出力を提供する。次いで、タスクマネージャ90はN個のデータ収集処理60から制御を再び担う。
【００８０】
図14は、タスクマネージャ90によるサブプロセス4(統合70)の起動を示している。N個のデータ収集処理によって生成されたN個の運賃リスト68Cが、最終的な運賃リスト16に統合される。この場合、3つの運賃リスト68Cが最終的な運賃リスト16に統合される。上述のように、統合サブプロセス70は重複をソートして除去するステップを含む。次いで、タスクマネージャ90は、統合サブプロセス70から制御を再び担い、最終的な運賃リスト16が格納および/またはユーザに送信されうる。
【００８１】
一般に、サブプロセス40〜70を実行する間に必要な全てのデータ(たとえば、運賃アプリケーション、運賃、地理的特性などの他のデータ等)は、必要な場合にのみ取り出されて、データキャッシュ内に置かれる。したがって、ルール規定キー、運賃キー、および運賃アプリケーションキーに適切なループを使用して、検索が因数分解されて再利用可能になる。データベースアクセスが処理時間に関してコストがかかるので、データベースへの呼出しの数を減らすことで処理の実行速度が向上する。さらに、不要なメモリ利用の原因となる場合がある複数の不要なデータ検索を回避できる。
【００８２】
上述のルール属性処理から運賃検出を使用することによって、大幅な性能の向上が実現されうる。性能におけるこの向上は、典型的な使用ケースの非限定的な例を使用することによって示されうる。
【００８３】
使用ケース:ある販売業者Aのオフィスが欧州/米国-カナダのマーケットで販売できる、全ての運賃を提供する。処理されるべきデータの最初のドメインについて、40,000,000個の運賃、400,000個のルール、および50,000,000個のルール規定があると仮定する。
【００８４】
上述のルール属性処理からの運賃検出を用いることによって、性能は、取り扱われるルールが2分間に1,500個、かつ処理される運賃が30分間に15,000個であると見られ、データ収集処理60のうちの4つ(N=4)が並列に実行されている。一方、この処理は、同じハードウェアプラットフォームを使用して全ての運賃が直接処理される場合、完了するまでに数日を要するであろう。
【００８５】
従来の運賃見積もり処理とは対照的に、ルール属性処理からの運賃検出は、運賃のリストを提供するために、ルール内に配置された属性から開始して実現され、リスト内の運賃が特定のルール属性によって無効化されないことを確実にする。ルール属性処理からの運賃検出は、大量のデータを扱うことができるデータベースコンテキスト内に価格志向の機能も提供する。しかし、大量のデータにもかかわらず、上述の特定の技術的スピードアップ手法を使用して(少なくとも処理時間およびメモリ利用に関して)性能問題が対処される。
【００８６】
例示的実施形態は、これに限定されないが、モニタリング、監査、および統計的評価を含む、いくつかの有益なアプリケーションおよびツールと連動できるとともに、それらの基礎を形成できる。
【００８７】
次に、本発明の例示的実施形態の実装に適した様々な構成要素の簡単なシステムレベルのブロック図を示す、図15を参照する。図15では、コンピュータシステム100はネットワーク104(たとえばインターネット)へのポータル(サーバ、ネットワークインターフェース)106を含み、それによってユーザ102はパーソナルコンピュータなどのそれぞれのユーザ端末を介して運賃照会を行うことができる。ポータル106には、データおよびソフトウェア(SW)112を格納する関連メモリ110を有する少なくとも1つのデータプロセッサ108が接続/結合されている。SW112は、データプロセッサ108によって実行されると、図5〜14に関して上述した方法および処理の実行をもたらす、プログラム命令を含む。上述の様々なデータキャッシュ、表、しきい値、一時記憶装置などが、メモリ110に実装されうる。少なくとも1つのデータプロセッサ108には、上述のように処理される運賃関連およびルール関連データを含む、運賃データベース114およびルールデータベース116も接続されている。データベース114、116のうちの1つまたは複数は、遠隔に配置されて、ネットワーク104を通じて、および/または1つまたは複数の他のネットワークを通じてアクセスされてよい点に留意されたい。いくつかの実装形態では、運賃データとルールデータとの両方を格納する1つのデータベースがあってよい点にも留意されたい。適切なデータベースマネージャは、データでデータベースを生成（populate）し、必要に応じてデータを修正し、データベースを検索するためにあると仮定される。
【００８８】
データプロセッサ108は、データ収集サブプロセス60を実行する間に並列実行できる複数の処理ユニットで実装されうる。これらの処理ユニットは、物理的処理ユニットとして、または仮想処理ユニット(仮想マシン)として実施されうる。処理ユニットは、タスクマネージャ90の制御下であると仮定され、タスクマネージャ90はSW112の1つまたは複数のモジュールによって実装されうる。
【００８９】
一般に、システム100は、1つまたは複数の適切なコンピュータハードウェア/ソフトウェアプラットフォームを使用して実装でき、また、1つまたは複数のデータプロセッサ、ならびにコンピュータソフトウェアおよびデータを格納する関連メモリを含むサーバとして実施されうる。システム100は、たとえば、旅行照会および旅客機の予約を取り扱う特定の組織(たとえばGDS)と関連付けられうる。ユーザ102は、たとえば、上述のように様々なOLTAの個々のオフィスとして表されうる。ユーザ102は、たとえば、様々な旅客機に関連付けられてもよい。
【００９０】
コンピュータシステム100の正確な実装形態の詳細および構築は、任意の数の適切な形式をとることができ、どのような点においても本発明の例示的実施形態の実装形態および実施を限定するものと見なされるべきではない。
【００９１】
上記の記述によって、例示および非限定的な例として、本発明の例示的実施形態を実装するための様々な方法、装置、およびコンピュータプログラムソフトウェアの完全かつ有益な説明を提供した。しかし、上記の記述を考慮して、添付の図面および添付の特許請求の範囲とともに読めば、当業者には様々な修正および適合が明らかになるであろう。
【００９２】
さらに、本発明の例示的実施形態の特徴のうちのいくつかは、他の特徴の対応する使用なしに有利に使用されうる。このように、上記の記述は本発明の原理、教示および実施形態のの単なる例示として見なされるべきであり、本発明を限定するものとして見なされるべきではない。
【符号の説明】
【００９３】
10  ルール属性
12  フィルタ
14  ルール属性処理/エンジン
16  運賃
20  関連検索ステップ
24  ルールカテゴリ
28  運賃
40  編集サブプロセス
42  作業ファイル
50  プリデータ収集サブプロセス
54  ルール統合データ表
55  論理表
60  データ収集サブプロセス
62  運賃
68C  運賃リスト
70  統合サブプロセス
82  機能インデックス
90  タスクマネージャ
100  コンピュータシステム
102  ユーザ
104  ネットワーク
106  ポータル
108  データプロセッサ
110  メモリ
112  ソフトウェア(SW)
114  運賃データベース
116  ルールデータベース
【図１】
0006054888.tif 000002
【図２】
0006054888.tif 000003
【図３】
0006054888.tif 000004
【図４】
0006054888.tif 000005
【図５】
0006054888.tif 000006
【図６】
0006054888.tif 000007
【図７】
0006054888.tif 000008
【図８】
0006054888.tif 000009
【図９】
0006054888.tif 000010
【図１０】
0006054888.tif 000011
【図１１】
0006054888.tif 000012
【図１２Ａ】
0006054888.tif 000013
【図１２Ｂ】
0006054888.tif 000014
【図１３】
0006054888.tif 000015
【図１４】
0006054888.tif 000016
【図１５】
0006054888.tif 000017