JP2009510545A - 実際の旅行料金を構築する方法およびシステム - Google Patents

Abstract

料金データベースからコンピュータ中で実際の旅行料金を構築する方法が開示される。旅行目的地を表すノードのグラフが構築され、このグラフは、ノードの対を接続するエッジを含む。各エッジは、最低旅行料金を参照する。また、各グラフ・エッジにつき料金ツリーが構築される。ツリーは、対応するグラフ・エッジの最低旅行料金を保持するルート・ノードを少なくとも含む。ツリーは、コンテキスト・キーと関連する旅行料金とを備えるより多くのノードを含む可能性がある。ツリーは、子ノードが親ノードの旅行料金以上の旅行料金を保持するように構成される。したがって、より安価な料金経路を効率的に抽出することができる。というのは、料金経路に含まれるグラフ・エッジは、関連する料金ツリーを参照し、それらの最低料金値の低い順に通過されるからである。学習エンティティを使用して、料金ツリーが構築され更新される。学習エンティティは、エンドユーザのための旅行ソリューションを構築することを目的とするプロセスから、そのデータを収集する。本発明による料金経路抽出方法を実施するためのシステムは、コンピュータ・トランザクションの経過時間中に多くの目的地を扱うことができるようにされ、したがって、旅の計画を開始するために特定の目的地を選択することが必要とされないエンドユーザに、テーマに基づく旅行オプションを提案することができる。

Description

本発明は一般に、コンピュータ化された旅行計画システムに関し、より詳細には、多数の予約可能な機会を顧客に提案できるように実際の旅行料金を効率的に抽出することを可能にする方法およびシステムに言及する。

旅、特に空の旅の計画は、一般に、出発地と目的地の町の空港を選択して、出発日と帰国日を設定することに基づいて行われる。これは、計画が旅行代理店によって行われるか顧客によって直接行われるかにかかわらず当てはまる。この場合、旅行代理店または顧客は、専用のウェブ・サイトのいずれかにアクセスするだけでよく、これらのウェブ・サイトは、多くのツアー・オペレータおよび航空会社が、どんな第三者の関与もなしにその旅行商品および休暇滞在を販売しようとして、これらを宣伝するためにインターネット上で編成したものである。実際、ほとんどの航空会社は今や、そのウェブ・サーバから航空チケットを予約および購入できるようにしている。この場合、チケットは「非物質化」されることが最も多い。というのは、現実のチケットが発行されることはなく、顧客はただ、例えばパスポートなどのＩＤを持って空港の航空カウンタにやって来て、その搭乗券を得るだけでよいからである。

旅または休暇を予約することがこんなにも簡単である場合に、それにもかかわらず顧客は、可能な最良のオファー、または自分の好みに最もよく適合したであろうオファーを得たことを確信することができない。商用で旅行するすべてとは言わないまでもほとんどの人々は、自分の仕事上の約束、会社のミーティング、会議、またはあらゆるセミナーのために厳密にいつどこにいなければならないかをしばしば十分に前もって把握した上で、正確な日付で到着および出発しようと尽力するとしても、旅行代理店の顧客の多くには、依然としてそのような制約はない。実際、旅行代理店の顧客の多くは、自分の旅の正確な日付を設定しなければならないことを不便と思い、また目的地もはっきりしていないことさえある。

この例として、旅行業者の顧客が、秋、すなわちいわゆるインディアン・サマーの間に、アメリカ大陸の東北部を訪ねたいと言ったとする。インディアン・サマーは、木の葉の色の変化すなわち紅葉で有名である。顧客がすぐにでも受諾できるフレキシブルな日付範囲で魅力的な価格の予約を旅行業者が取ることができる限り、このような顧客にとっては、ニューイングランドのボストン、ニューヨーク、さらにはケベック州モントリオールに到着するのも面白いかもしれない。

他の顧客は、さらに緩い要件を言い、自分の旅行目的地または休暇についてテーマのみを指定したいとする。例えば古代文明が好きな人は、エジプトおよびそのピラミッド、メキシコおよびコロンブス以前の文明、またはカンボジアのアンコールにある寺のように、異なる目的地を自分の要求において考慮したい場合がある。

このタイプの照会を扱うための部分的なソリューション（いくつかについては後で論じる）がすでに提案されているとしても、これは、旅行代理店に現在備わるソフトウェア製品では不可能である。これは、現在の製品がまさにサポートしない、日付および目的地を指定する際の多大なフレキシビリティを要求する。この時点で、旅を実際に予約することが目的であって、考慮した期間がすでに予約で一杯であるために、またはキャンセルされたために利用不可能だと後で明らかになるかもしれない潜在的な旅行機会を考慮することだけが目的ではないことが、はっきりと理解されなければならない。

クライアントが選択を行うのを補助するための製品が、すでに存在する。例えば、ＵＳＰＴＯ（米国特許商標庁）への米国特許出願公開番号２００２００９１５３５を参照することができるが、この出願には、目的地の選択を補助するための方法およびシステムが記載されており、この場合、最初に目的地を指定しなくてもよい。しかしこれは、顧客によって行われた目的地および滞在の選択が実際に予約可能であることの、どんな形の保証も提供しない。

複数の目的地への、ある日付範囲のフライトの実際の利用可能性に関する十分な情報を顧客が収集できるためには、考慮する目的地および日付が存在するだけ多くの異なる照会を予約システムに発行することが必要になる。返されたすべての情報を、手作業で比較するために注意深くログ記録しなければならない。あるレベルのフレキシビリティ、特に、要求された特定の日付に利用不可能な場合に、指定の日付に近い日付を自動的に提案する際のフレキシビリティを導入しているシステムもあるが、最良のソリューションを検索することは常に、時間を消費し、退屈で、旅行業者からの多大な献身を必要とする。また、この旅行業者のスキルは、顧客の要求を満たすことのできるすべてのソリューションを旅行業者が実際に見つけられることにはならない場合がある。

これらの困難を切り抜けるための強引な方法は、出発地と目的地の料金のすべての組合せを事前に計算することであろう。しかし、組合せの数のため、すべての可能性を列挙して記憶するには、現実的に実装できない膨大な量のリソースが必要になる。実際、航空会社の場合のみを考えても、世界には、少なくとも１つの空港および関連する商業フライトを有する町が約３６００ある。２００程度の航空会社が予約データベース中で参照される。出発地空港と目的地空港の対ごとに、少なくとも１０の関税制度が存在する。また、１０の乗客タイプを定義することができる（子供、大人、高齢者など）。したがって、何十億もの組合せを記録しなければならなくなる。これは、不可能な作業ではないとしても、経済的に現実的ではないであろう。

そこまで行きすぎることなく、しかし多数の組合せを計算しようとするシステムが提案された。これは例えば、米国特許第６３３６０９７号に記載のものであり、町、出発地、および目的地のグループ間で多数の旅行料金を構築する方法が教示されている。この計算方法は、関税行列、いくつかの多次元かつ複雑なデータ構造の使用に基づき、これらは、実施されるために、重要な計算力および対応するアクティブなメモリ・リソースを要求する。ピーク期間には、何千人とは言わないまでも何百人ものリモート・ユーザが同時に予約システムにアクセスしたいかもしれず、一般に十分に活用されないであろう膨大で高価なリソースを実装しない限り、その計算能力を崩壊するまで使い果たす危険性が高くなる。
米国特許出願公開番号２００２００９１５３５ 米国特許第６３３６０９７号 Ｒｏｂｅｒｔ Ｓｅｄｇｅｗｉｃｋによる書籍「Ａｌｇｏｒｉｔｈｍｓ」第２版、１９８８年、ＩＳＢＮ０−２０１−０６６７３−４、Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ編集、より具体的には２９章「Ｇｒａｐｈ Ａｌｇｏｒｉｔｈｍｓ」

したがって、本発明の広範な目的は、標準的な最新技術のコンピュータ上における、実際の、すなわち予約可能な旅行料金の構築を促進することである。

本発明の別の目的は、単一のエンドユーザ要求の経過時間中に多くの目的地を扱えるようにすることである。

本発明の別の目的は、エンドユーザが旅の計画を開始するために特定の目的地を選択しなくてもよいように、旅行計画システムがそのエンドユーザにテーマに基づく旅行オプションを提供できるようにすることである。

本発明の別の目的は、選択された料金経路が、可能な料金経路のセットのうちでより安価であるようにすることである。

本発明の他の目的、特徴、および利点は、添付の図面を参照しながら以下の記述を検討すれば、当業者には明らかになるであろう。どんな追加の利点も本明細書に組み込まれるものとする。

料金データベースからコンピュータ中で実際の旅行料金を構築することが開示される。ノードが旅行目的地であるグラフを形成する、第１のデータ構造が構築される。グラフ・エッジが、ノードの対を接続する。各エッジは、最低旅行料金を参照する。各グラフ・エッジに対して、第２のデータ構造、すなわち料金ツリーも構築される。ツリーは、対応するグラフ・エッジの最低旅行料金を保持するルート・ノードを少なくとも含む。より多くのノードが追加される可能性もあり、その場合、ノードは、コンテキスト・キーおよび関連する旅行料金を備える。ツリー中では、子ノードが、その親ノードの旅行料金以上の旅行料金を保持する。この２つのデータ構造から、より安価な料金経路を効率的に抽出することができる。というのは、料金経路に含まれるグラフ・エッジは、関連する料金ツリーを参照し、それらの最低料金値の低い順に通過されるからである。学習エンティティが、料金ツリーの構築および更新を任される。ツリーを構築および更新するためのデータは、エンドユーザのための旅行ソリューションを構築することを目的とするソフトウェア・プロセスからくる。コンピュータ・トランザクションの経過時間中に多くの目的地を扱うことができるので、本発明の方法を実施する旅行計画システムは、旅の計画を開始するために特定の目的地を選択しなくてもよいそのエンドユーザに、テーマに基づく旅行オプションを提案することができる。

本発明に関する以下の詳細な記述では、添付の図面を参照する。この記述は例示的な実施形態を含むが、他の実施形態も可能であり、本発明の趣旨および範囲を逸脱することなく、これらの実施形態に変更を加えることもできる。

図１に、本発明（１００）のコンポーネント、および本発明が動作する環境を示す。本発明の主要なコンポーネントは、「料金学習コンポーネント」（１１０）であり、これは、そのエンドユーザ（１４０）のための旅行ソリューションを構築するのに使用される「アフィニティ・ショッパ（ａｆｆｉｎｉｔｙ ｓｈｏｐｐｅｒ）エンジン」（１０５）と呼ばれる少なくとも１つのプロセスと通信する。このようなプロセスは、リモート・ユーザからの照会と同数だけ、同時にアクティブである。これらのリモート・ユーザは、本発明を実施する旅行予約システムへのアクセスを有する旅行代理店であることが最も多い。また、インターネットのような私設または公共ネットワーク（１３０）を介してオンライン予約を行うことが許可された個人である場合もある。プロセス（１０５）は、例えば航空会社予約システムをホストするデータ・センタのサーバおよびコンピュータを動作させるのにしばしば使用される「ＵＮＩＸ」や「ＬＩＮＵＸ」などのオペレーティング・システムの制御下で、プロセッサ上で同時に実行されるソフトウェア・タスクである。リモート・ユーザと通信するのを許可するソフトウェア・プログラムは、世界規模のネットワークであるインターネット上で、特に、その最も一般的な適用例すなわちウェブ上で、広く使用されているソフトウェア・プログラムである。したがって、クライアント側ではウェブ・ブラウザが使用される。最も利用されているものは、「Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ（ＩＥ）」の名で知られる。これは、周知の米国会社「Ｍｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎ」によって開発され、実際、大多数のパーソナル・コンピュータ（１５０）上で使用されるそのオペレーティング・システム「Ｗｉｎｄｏｗｓ」に組み込まれている。広く利用されていたが９０年代の終わりにその優位を失った「Ｎｅｔｓｃａｐｅ」のような、他のウェブ・ブラウザも使用されている。近年、新しいウェブ・ブラウザが、いくらかの人気を獲得している。とりわけ、「Ｆｉｒｅｆｏｘ」の名で知られるウェブ・ブラウザが、前述のオペレーティング・システム「ＬＩＮＵＸ」のように、フリーソフトウェアの世界からきている。すなわち、それらのプログラム・ソース・コードは、誰にでも自由に利用可能にされている。

本発明は実際の料金に対して機能するが、本発明では、料金学習コンポーネント（１１０）およびアフィニティ・ショッパ・エンジン（１０５）は、データベース（１２０）、特に、自己のフライトの料金および空席状況を提供する航空会社のデータベースへのアクセスを有するものとする。ここで、航空会社データベースから料金を取り出すことは、何らかの処理を必要としなければ行われない場合があることに留意されたい。実際、料金は一般に、基本料金プラス追加料金、およびそれらを構築するための規則の形で提供される。また、例えば乗客タイプ（子供、高齢者）によって提供される値引きもある。

したがって、料金および空席状況データベースは、旅行製品の開発および販売に特化した会社によって世界中の旅行代理店に利用可能にされるコンピュータ化された予約システムの、鍵となる部分である。これは、その本部およびほとんどのオフィスが欧州にあるＡＭＡＤＥＵＳや、その本部がテキサス州にある米国会社ＳＡＢＲＥのような企業の場合である。

本発明のデータベースおよびコンポーネントを同じコンピュータ中で実施することができる場合でも、これらは、異なるコンピュータ中でホストされることが最も多く、これらのコンピュータは、物理層からアプリケーション層までにわたる７層の通信プロトコルを定義するＯＳＩすなわち「Ｏｐｅｎ Ｓｙｓｔｅｍｓ Ｉｎｔｅｒｃｏｎｎｅｃｔｉｏｎ」アーキテクチャに準拠するものなど標準的なプロトコルおよびインターフェースを使用して、通信（１１５）できなければならない。実際には、ＴＣＰ／ＩＰプロトコル、すなわち「Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ ｏｖｅｒ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ」が広く使用される。

本発明を実施するのに必要なソフトウェア製品およびデータベースをホストするコンピュータ（１６０）は、一般に、内部ならびに外部の記憶手段を備えることになる。特に、データベースの内容は、大規模ディスク・ユニット（１７０）に収容されることが最も多い。

図２は、図１に示した本発明による「料金学習コンポーネント」の全体的な記述である。このコンポーネントは、２つのデータ構造に作用する「料金経路抽出エンジン」（２００）および「学習エンティティ」（２１０）で構成される。

これらの構造の１つは、「データ記憶構造」（２２０）と呼ばれる。これは典型的なグラフ構造であり、そのノードは、世界中の町の空港である。ここでは、空港はそのＩＡＴＡ（国際航空運送協会）の３文字コードで示され、例えば英国ロンドンの場合はＬＯＮ（２２１）である。グラフのノード間の接続、例えば（２２６）は、２つの町の空港間の、存在する料金接続である。明らかに、このようなグラフの１組のノード間すべての接続が存在するわけではない。すべての町の対がその間の公開料金を有する可能性は低いので、グラフは一般に完全ではない。使用されているグラフ語彙に従って、本発明の以下の記述では、ノード（頂点とも呼ばれる）間の接続をエッジと呼ぶ。したがって、グラフ（２２０）中の経路は、エッジによって接続されたノードのリストである。例として、フランスのニース（２２５）と英国のロンドン（２２１）との間に、フランスのパリ（２２３）を介した、２つのエッジ（２２２、２２４）からなる経路がある。ここで、グラフ構造の実装は多くの異なる方法で実施できることは、留意に値する。これに関しては、この主題に関する特に豊富な技術文献を参照することができる。本発明は、一般にどんな特定の実装形態をも想定せず、「料金経路抽出エンジン」（２００）によってノードおよびエッジを取り出すことができるように（２２０）などのグラフを表すことが可能なソフトウェア・データ構造を構築できることを想定するのみである。

しかし、本発明によりグラフ構造に課される単一の要件がある。それは、あるノードからのすべてのエッジは、それらに関連する値の低い順に読取り可能である（またはソートされる）ことである。これについては、エッジの値を考慮することに関して、かつ図３において、後でさらに論じる。

第２のデータ構造は、「コンテキスト・データ・ストレージ」（２３０）と呼ばれ、典型的なツリー構造である。各グラフ・エッジ、例えば（２４０）は、関連するツリー構造を有し、したがって、「コンテキスト・データ・ストレージ」は１組のコンテキスト・ツリーである。コンテキスト・ツリーのルートは、関連するエッジについて見つけることのできる最低料金、すなわち、それが接続する町の間の可能な最安値フライト接続を保持する。この例では、ＬＯＮ（２２１）とＮＣＥ（２２５）のノード間で見つかる最低料金は、料金データベース（２１８）によって使用される通貨で１００通貨単位（２３１）に値する。しかし、このツリーは一般に、より多くの料金を保持し、各料金にはコンテキスト・タイプが関連する。コンテキスト・タイプは、最低料金値を得るための精緻化基準である。例えばこれは、フライトを運営する航空会社、例えばＢＡ（２３２）（Ｂｒｉｔｉｓｈ Ａｉｒｗａｙｓを表す）だが、ＢＡ（２３２）の場合、最低料金は１５０通貨単位に値する。コンテキスト・タイプの別の例は日付範囲であり、ここでは６月から９月（２３４）である。この期間中は、この航空会社では特定の料金がより高い。乗客タイプ（図示せず）、すなわち大人、子供、高齢者などには、それ自体の関連料金が定義されているものとすることができる。明らかに、旅行クラスや座席タイプなど、他にも多くのコンテキスト・タイプが可能である。したがって、各ツリーは、最低料金がルートにあって、次いで、コンテキスト・タイプごとに下降していくと見積もり料金が等しい（２３６）かまたはより高くなるように、構成される。

この最低値、すなわちルート・ノードの値は、上ですでに論じたように昇順でノードのエッジを読み取るのに使用される対応するグラフ・エッジの関連値である。

ツリーの実装に関する限り、本発明では、ノードは最低料金値、例えば（２３２２）を保持しなければならず、コンテキスト・キー、例えば（２３２１）を有するものとする。ルート・ノードは、最低料金値（２３１）を保持し、空のコンテキスト・キーを有する。初期化時、その時のツリーの唯一のノードであるルート・ノードの値は、０に設定される。これは、この記述において後でさらに論じる「料金経路抽出エンジン」によって受け容れられる有効値である。あるノードのすべての子は、同じコンテキスト・タイプを共有する。あるノードの２つまたはそれ以上の子は、異なるコンテキスト・キーを有する。すでに上述したように、子ノードの値は、親ノードの値以上である。

上記の要件を別として、グラフ構造と同様、本発明は、コンテキスト・ツリーに関してどんな特定の実装形態をも想定しない。ツリーは、ルートから開始してコンテキスト・キーを取り出すことが可能であるように構成されなければならない。ツリーを下降したとき、検索されるコンテキスト・キーが見つからないかまたは合致しなくなればすぐに、取出しは停止する。次いで、返される値は、最後に成功した検索の値である。例として、航空会社としてＡＦ（すなわちエール・フランス）を指定し、１２月１日の日付を指定するコンテキスト・タイプについて検索が実施された場合、検索は、ノード（２３６）の値である値１００を返すことになる。というのは、下のノード（２３８）について日付を比較すると、３月から１０月の範囲に合致しないからである。また、コンテキスト・ツリーは、更新された値の挿入を可能にしなければならない。これは主に、ツリーを下降してコンテキスト・タイプを検索することにある。コンテキスト・タイプが見つかれば、値が更新される。しかし見つからない場合は、対応するノードを作成して値を更新しなければならない。

コンテキスト・ツリーを更新することを担うのは、学習エンティティ・コンポーネント（２１０）である。更新は、アフィニティ・ショッパ・エンジンから、これらのプロセスによってより多くの情報が収集されたときに受け取られる。したがってツリーは、初期化以後、アフィニティ・ショッパ・エンジン（２０５）を介してエンドユーザから実際に要求されたデータによって、漸進的に構築され更新される。これにより、ツリーを維持してツリーのサイズを管理可能な限度内に保つことができる。学習エンティティは、新しいコンテキスト値を挿入しなければならず、あるいは、古くなったまたは使用されなくなった既存の値を置き換えなければならない。また、料金データベースが更新されたときは、ツリーを最新に保つために、コンテキスト・ツリーの無効化（２１５）を実施しなければならない。

図３でさらに、図２で論じた２つのデータ構造間の関係について述べる。このグラフは、例えば正方形配列（３００）の形をとることができ、行と列は町の空港であり、したがって、行と列の交差点に無効な値（例えばヌル値）がある場合、この２つの空港間にはグラフ中で直行フライト接続が存在しない。図３の行列は図２の例示的なグラフを表すので、またこのグラフ中では例えばＮＹＣノードとＭＡＤノードの間にエッジがないので、この場合、対応する配列要素中にヌル値が配置される（３１０）。また、同じ空港への料金接続を有することは意味がないので、対角線はヌルになっている（３２０）。この配列は対称なので、対角線の下の下方三角形（３３０）のみを実装して、記憶空間を節約したい場合もあろう。しかしこれは、実用上の理由で、また実装に関して、不都合な場合がある。扱うべきノードの数に応じてグラフは大きい場合があるので、好都合な一実装形態は、０と１の２進数の配列を有することである。明らかに、１は、対応するノード間にエッジがあることを示し、０は接続が存在しないことを示す。

グラフの実装形態がいずれであるかにかかわらず、本発明では、ヌルでない各配列要素、例えば（３４０）およびそれと対称をなす他方（３４２）（もし存在すれば）は、エッジの最低値が素早く取り出せるように、一意の関連するコンテキスト・ツリーのルート（３５０）を明白に参照すること（３４４）を可能にするように存在するものとする。したがって、実装形態に応じて、図示（３４０）のように最低値を配列要素中に持ってくることもでき、あるいは、２進数の値１があるだけであって、実際の最低エッジ値は、参照されるルート・ノードから見つかる。配列要素とそのコンテキスト・ツリーとの間の参照は、配列の各要素と図２で論じた「コンテキスト・データ・ストレージ」構造の各ツリーとの間に一意の１対１対応があるように、暗黙的とすることができる。

すでに述べたように、また図４でさらに論じるように、本発明ではまた、グラフ構造の各ノードから、そのノードより生じるすべての存在するエッジを、それらの最低（ツリー・ルート）値の低い順に得るまたは読み取ることが可能であるものとする。本発明は、この目的を達成するためのどんな特定の方法または手段をも想定しない。例として、必要時に、標準的なソート済みリンク・リスト（３６０）を読み取ることができ、あるいは実行中に構築することができる。

また、グラフ配列が実際に構成される方法は、実装選択の問題であり、本発明の動作に影響しない。特に、ノードは、ここではそのＩＡＴＡ３文字コードのアルファベット順にリストされているが（３００）、特定の方法でソートする必要はない。

最後に、グラフは、まったく配列でなくてもよく、それでもなお本発明の要件に適合する。グラフを実装するための周知の構造の１つは、隣接構造（ａｄｊａｃｅｎｃｙ−ｓｔｒｕｃｔｕｒｅ）と呼ばれる。この構造、ならびにグラフおよびそのアルゴリズムについては、Ｒｏｂｅｒｔ Ｓｅｄｇｅｗｉｃｋによる書籍「Ａｌｇｏｒｉｔｈｍｓ」第２版、１９８８年、ＩＳＢＮ０−２０１−０６６７３−４、Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ編集、より具体的には２９章「Ｇｒａｐｈ Ａｌｇｏｒｉｔｈｍｓ」を参照されたい。したがって、例示的な代替グラフ構造の１つは、（３７０）に示すものとすることができる。このグラフ構造では、ノードは、それらを接続するすべてのエッジによってリストされ、したがって、これらのノードもまた、本発明を実施するための上記の要件に適合するように、その最低値の低い順にソートすることができる。

図４およびそれに続く図で、出発地と目的地リストとコンテンツ・タイプとが与えられた場合に最短料金経路のリストを返す「料金経路抽出エンジン」およびそのアルゴリズムについて、より詳細に述べる。

述べるアルゴリズムは、最大３つのエッジまたは接続を含む経路のみを返すように適合されている。大きいグラフ中では、４つ以上のフライトを組み合わせることによって、より安価な旅料金を抽出すること、または一般によりよいオファーを顧客に対して行うことも可能であろうが、あらゆる実際的な適用例で、１回の旅にわたって３つ以上の経由地を提案することは、受け容れられる可能性が低い。グラフ検索の性能は、発見すべき経路の数によって大きく条件付けられるので、これによって検索が促進され、受け容れられないとわかっているソリューションを計算しなければならないことが回避される。したがって、グラフから、出発地ノード、例えばＮＣＥ（４１０）と、目的地ノード、例えばＬＯＮ（４２０）との間に存在するかもしれない可能な単一エッジ（４００）を考慮することに加えて、図５にさらに述べるアルゴリズムは、１つの経由地（４３０）または２つの経由地（４４０）を含む料金経路のみを構築する。したがって、図５の全体的なアルゴリズム中の、新しい料金経路を構築するステップは、（４５０）に示すサブステップを含む。第１のステップ（４５２）は、図２および３で論じたコンテキスト・ツリーから、出発地（４１０）および目的地（４２０）ノードからのエッジについての値を得ることである。選択された２つのエッジが同じ宛先を有する場合は（４５４）、長さ２の新しい料金経路、すなわち２つのエッジを含む料金経路を構築することができる（４５８）。グラフ中では、これは、同じ宛先ノードＭＲＳ（４３０）を有するエッジ（４１１）および（４２１）を含む経路に対応する。しかし、選択された２つのエッジが同じ宛先を有さない場合は（４５６）、選択された２つのエッジのノード対の宛先についての値を、コンテキスト・ツリーから取り出さなければならない（４６０）。次いで、３つのエッジを含む長さ３の新しい料金経路を構築することができる（４６２）。グラフ中では、これは、２つの中間ノードＰＡＲおよびＬＹＳ（４４０）を有する、エッジ（４２２）、（４４２）、および（４１２）を含む経路に対応する。これにより、図５の全体的なアルゴリズムによって使用される長さ２または３の新しい料金経路を構築するステップが終了する（４６４）。

また、図５の本発明による抽出アルゴリズムは、料金経路ヒープ（４８０）と呼ばれる一時データ構造を構築し管理する必要がある。ヒープ（heap）は、２分木の形をとることが最も多いデータ構造であり、このデータ構造では、親ノード（４８２）のキーがその２つの子ノード（４８４）のキーよりも大きく、以下同様である。したがって、ルート（４８６）は常に、より大きいキー値を保持する。ヒープ、または優先待ち行列は、コンピュータ・プログラミングの当業者に知られている標準的なデータ構造であり、さらに説明する必要はない。特に、挿入および削除は、ヒープについて定義された周知の操作である。

図５に、前に述べたデータ構造から料金経路を抽出する方法のステップを示す。返すべき料金経路の数、すなわちｋは、出発地および目的地リストと共に、グラフ検索を実施するためのもう１つの入力パラメータである。前に論じたヒープ中にｋ個の料金経路が蓄積されて、試すべきそれ以上安価なエッジ組合せが残っていないとき、これにより検索プロセスは終了し、したがって、ｋ個の最低見積もり料金経路が、呼出しタスク、すなわち前に図１で述べた「アフィニティ・ショッパ・エンジン」に返される（５６０）。

料金経路の抽出は、ステップ（５００）で開始し、一時ヒープは、出発地ノードと目的地ノードの間の直接接続に相当する長さ１の第１経路で初期化される。このような長さ１の料金経路は、ヒープ中に１つしかない。これは、コンテキスト・タイプが関連していない限り、対応するコンテキスト・ツリーのルートであり、コンテキスト・タイプが関連している場合は、コンテキスト・ツリーを検索して、対応するコンテキスト・タイプに適合するノードが取り出されている。

次のステップ（５０５）は、出発地ノードから出発する第１の（最低料金）グラフ・エッジから開始する。すでに述べたように、グラフ・エッジは、その料金値の低い順にソートされているかまたは読み取ることができ、したがって、アルゴリズムによって最低料金のエッジを選ぶことができる。

同じことを目的地ノードからも行い（５１０）、それにより、図４で述べたＥｄｇｅ１およびＥｄｇｅ２パラメータを選択し、新しい料金経路を構築するステップ（５１５）を実施することができる。このステップの詳細は、図４ですでに論じており、（４５２）から（４６４）までにわたるサブステップで参照される（４５０）。

次いで、次のステップ（５２０）は、ｋ個の料金経路がすでにヒープに追加されたかどうかチェックすることにある。ｋ個よりも多い料金経路が蓄積されている場合は（５２１）、最も高価な料金経路をヒープから除去する（５２５）。しかし、ｋ個未満またはちょうどｋ個の経路がヒープ中にある場合は（５２２）、抽出アルゴリズムは直接に次のステップ（５３０）に進み、今度は、目的地ノードから出発する次のエッジを選択する。この場合もやはり、ノードから出発するエッジは、その値の低い順にソートされているかまたは読み取られる。これが終了すると、ヒープのサイズがｋ以上かどうか、かつ、Ｅｄｇｅ１の値と今選択した次のＥｄｇｅ２の値とを足した値が、ヒープの最高値（ルートの値）よりも大きいかどうかを検証するチェックを実施する（５４０）。そうでない場合は（５４２）、アルゴリズムはステップ（５１５）に戻り、すでに述べたように、新しい料金経路を構築してヒープに挿入することができる。しかし、チェックの答えが肯定である場合は（５４１）、ステップ（５４５）に進み、次のＥｄｇｅ１パラメータを選択する。

この時点で、今論じたステップ（５４０）と同様のチェックを実施するが（５５０）、ここでは、選択された新しいＥｄｇｅ１パラメータの値のみを、ヒープの最高値と比較するだけである。最高値よりも厳密に高くない場合は（５５１）、アルゴリズムはステップ（５１０）に戻って、次のＥｄｇｅ２を選択し、新しい料金経路の構築に進む（５１５）。しかし、最高値よりも高い場合は（５５２）、これにより、出発地ノードと目的地ノードの対についての、呼出しタスクから要求されたｋ個の料金経路の検索は終了する（５６０）。

したがって、本発明の方法により、各目的地につきｋ個の料金経路をデータ構造から抽出することができる。これらは、各出発地および目的地ごとの、グラフ中に存在するｋ個の最低見積もり料金経路であることが保証される。また、見積もり料金経路は、現実の機会であり、これらの機会は、すぐに予約できる旅行ソリューションを構築するために、図１に示した「アフィニティ・ショッパ・エンジン」（１０５）によって値付けされチェックされることになる。この「アフィニティ・ショッパ・エンジン」は、「料金学習コンポーネント」（１１０）の正確さを利用し、「料金学習コンポーネント」は、航空会社およびこのようなサービスの他のプロバイダによって継続的に更新される空席状況および料金のデータベースから構築され維持される本発明のデータ構造（グラフおよびコンテキスト・ツリー）から、非常に多くの目的地料金経路を効率的に処理することができる。

したがって、アルゴリズムの効率性のため、非常に多くの目的地を「アフィニティ・ショッパ・エンジン」中で同時に処理することができ、それにより、単一の照会で多くの目的地を考慮しながらもなお、他のこのような（しかし一度に複数の目的地を処理することのできない）ツールを使用して得られる回答に匹敵する全体的な回答を、ある時間内に得るという、元々の要件に適合することができる。

言い換えれば、「料金学習コンポーネント」によって提供される見積もり料金経路は、「アフィニティ・ショッパ・エンジン」によって処理される複雑な照会を促進することを可能にする。最終的に実際のソリューションを妥当性検査することを担うのは、依然として「アフィニティ・ショッパ・エンジン」のみである。特に、「アフィニティ・ショッパ・エンジン」は、フライトを料金経路に関連付け、空港税などを加算しなければならない。さらに、料金経路の有効性がチェックされて、それにより、必要時に「料金学習コンポーネント」のデータ構造が更新される。これは、データ構造が初期化されたばかりであってデフォルト値を更新する必要があるときは、より頻繁に行われる。この役割は、「料金学習コンポーネント」の一部である図２に示した「学習エンティティ」（２１０）が果たす。

図６に、「アフィニティ・ショッパ・エンジン」によって準備され、エンドユーザ、すなわち一般に旅行代理店の業者に向けられた、ウィンドウ（６００）の例を示す。すでに述べたように、通常のコンピュータ化されたトランザクションの経過時間中に多くの航空料金を計算することのできる本発明は、要求の発行を許可するために目的地を指定しなければならないことを必要としない。そうではなく、テーマに基づく様々な要求を発行することができる。例えば、ニース空港（６１０）から、顧客は、様々な旅行トピック（６１５）の中から欧州の首都に関するトピック（６２０）を選択することができる。本発明のこの実施例では、フレキシブルな出発日（６３０）、帰国日範囲（６３５）、および旅の予算限度（６４０）など、他のいくつかの入力もエンドユーザから予期される。

次いで、アフィニティ・ショッパ製品は、アフィニティ基準、最大予算、および日付に対応する、１組の目的地の町を構築する。選択された目的地への、料金の低い順にランク付けされた利用可能な最良のフライトを取り出した後、この情報を、表示する新しいウィンドウ（６５０）の形でエンドユーザに返すことができる。ここでもやはり、見積もり価格が、保証された予約可能な旅行ソリューションであることは、留意に値する。

次いでエンドユーザは、選択を行って、特定の目的地（６５５）をピックアップすることができる。この場合、エンドユーザには、次に返されるウィンドウ（６６０）から、より多くの選択の機会が与えられる。このウィンドウ（６６０）は、選択された目的地すなわちウィーンについてのカレンダ・ソリューションを表示する。この特定の例では、ニースからウィーンへの旅行ソリューションは、各セグメントごとに２つのフライト（６６５）からなる。航空会社料金は、ＮＡＰＦＴ６（６７０）で参照されるＡＦ（エール・フランス）であり、総額２７０．５６ユーロ（６７５）である。この時点で、エンドユーザは、続行し、この旅行ソリューションを予約して購入することができる。

本発明の全体的な環境およびコンポーネントを示す図である。 本発明を実施するのに必要な料金学習コンポーネントおよび２つのデータ構造を示す図である。 データ記憶構造、目的地ノードのグラフ、本発明のデータ構造の１つの、実装形態をより具体的に論じる図である。 料金経路を抽出するのに使用される一時データ構造である料金経路のヒープを記述し、抽出方法を論じる図である。 料金経路を抽出する方法をさらに述べる図である。 本発明を利用して旅行計画システムから送られ、テーマに基づく旅行オプションをそのエンドユーザに提案できるようにされた、グラフィック・インターフェース・ウィンドウを示す図である。

Claims (14)

1. 少なくとも１つの料金データベース（２１８）からコンピュータ（１６０）中で実際の旅行料金を構築する方法であって、
   ノードのグラフ（２２０）を構築するステップであって、前記ノード（２２１）は他の前記ノードからの旅行目的地を表し、前記グラフは前記ノードの対（２２１、２２５）を接続するエッジ（２２６）を含み、各前記エッジは前記ノードの対についての最低旅行料金（２３１）を参照する（２４０）ステップと、
   各前記グラフ・エッジにつき料金ツリー（２３０）を構築するステップであって、前記各ツリーは少なくともルート・ノード（２３１）を含み、前記ルートは前記グラフ・エッジについての前記最低旅行料金を保持し、前記ツリーは、コンテキスト・キー（２３２１）と関連する旅行料金（２３２２）とを備えるより多くのノード（２３２）を含む可能性があり、前記ツリーは、子ノード（２３４）が親ノード（２３２）中の前記旅行料金以上の前記旅行料金を保持するように構成されたステップと、
   前記ノードのグラフから料金経路を抽出する（２００）ステップとを含み、前記料金経路に含まれる前記グラフ・エッジ（２２２、２２４）は、関連する前記料金ツリーを参照して前記料金経路を構築することを特徴とする方法。
2. 学習エンティティ（２１０）を備え、前記学習エンティティは前記料金ツリー（２３０）の構築および更新を目的とすることを特徴とする請求項１に記載の方法。
3. 前記学習エンティティは、エンドユーザ（１４０）のための旅行ソリューションを構築することを目的とする複数のプロセス（１０５）へのエンドユーザ要求から、前記料金ツリーの構築および更新に使用されるデータを収集することを特徴とする請求項２に記載の方法。
4. 前記料金データベース（２１８）は航空会社によって提供および更新されることを特徴とする前記請求項のいずれか一項に記載の方法。
5. 出発地ノードから目的地ノードへの前記料金経路を抽出する前記ステップは、前記出発地ノードの前記エッジ（５０５、５４５）および前記目的地ノードの前記エッジ（５１０、５３０）を、それぞれの前記最低旅行料金（３５０）の低い順に（３６０）選択することを特徴とする請求項１に記載の方法。
6. 料金経路を抽出する前記ステップは、２分木として構成されて維持される一時料金ヒープ（４８０）を構築し、前記ヒープ中で、親ノード（４８２）は、２つの子ノード（４８４）の料金経路よりも高価な料金経路を保持し、ルート・ノード（４８６）は最も高価な料金経路を保持することを特徴とする請求項１に記載の方法。
7. 前記ヒープは長さ１の料金経路で初期化され（５００）、さらに長さ２（４５８）および３（４６２）の料金経路でポピュレートされる（５１５）ことを特徴とする請求項６に記載の方法。
8. 前記ヒープは、指定数ｋ個の料金経路を含むように制限され（５２０、５４０、５５０）、前記指定数を超えた場合は（５２１）、前記最も高価な料金経路が前記ヒープから除去される（５２５）ことを特徴とする請求項６または７に記載の方法。
9. 前記料金経路を抽出する前記ステップは、前記ヒープが前記指定数ｋ個の料金経路を含み、それ以上安価な料金経路を構築できる可能性がないときに（５５２）、終了する（５６０）ことを特徴とする請求項１に記載の方法。
10. 請求項１から９のいずれか一項に記載の方法の各ステップを実施するように適合された手段を含むことを特徴とするシステム、特に料金学習コンポーネント（１１０）。
11. コンピュータ可読記憶媒体に記憶されたコンピュータ・プログラム製品であって、請求項１から９のいずれか一項に記載の実際の旅行料金を構築する方法を少なくとも１つのコンピュータに操作させるためのコンピュータ可読コード手段を備えることを特徴とするコンピュータ・プログラム製品。
12. システム、特に旅行計画システム（１０５）であって、前記料金学習コンポーネント（１１０）を備え、前記旅行計画システムは、テーマに基づく旅行オプションを前記エンドユーザ（６００）に提案できるようにされたことを特徴とするシステム。
13. 前記旅行計画システムは複数の目的地についての旅行オプション（６５０）を返すことができることを特徴とする請求項１２に記載のシステム。
14. 前記旅行計画システムは、選択された目的地について複数の日付および料金を返すことを特徴とする請求項１２または１３に記載のシステム。

Images