(57)【特許請求の範囲】
【請求項１】
インターフェースモジュールを含む多チャンネル予約システムにおける旅行事前予約問い合わせの効率を向上させる方法であって、前記インターフェースモジュールは複数の旅行チャンネルによりアクセス可能であり、各旅行チャンネルは旅行予約サービスをユーザに提供し、前記多チャンネル予約システムは複数の旅行サーバへのアクセスを有し、各旅行サーバは少なくとも１つの旅行リソースに関する在庫情報を提供し、前記方法は、
前記多チャンネル予約システムが、前記旅行チャンネルの１つから、前記インターフェースモジュールを介して、PNRデータ記録と少なくとも１つの旅行在庫問い合わせを含むユーザ要求を受信するステップと、
前記多チャンネル予約システムが、前記PNRデータ記録の構造を複製することによりクローンPNRデータ記録を作成するステップと、
オファーを前記クローンPNRデータ記録内の新たなPNRエレメントとして定義することにより、前記クローンPNRデータ記録を、前記旅行在庫問い合わせに基づいて前記複数の旅行サーバの少なくとも１つより取得した情報で、充実させるステップと、
ユーザ入力に応答して、前記PNRデータ記録の情報を、前記クローンPNRデータ記録における対応するフィールドに従って変更するステップと、
前記インターフェースモジュールを介して、前記ユーザにより要求された前記少なくとも１つの旅行在庫問い合わせに関連付けられた応答を返送するステップと
を含む、方法。
【請求項２】
前記充実されたデータ構造は、前記複数の旅行チャンネル間で共有されて、将来の問い合わせのために再利用されることができる、請求項１に記載の方法。
【請求項３】
前記在庫情報は価格についての情報を含む、請求項１〜２のいずれか１項に記載の方法。
【請求項４】
前記クローンPNRデータ記録は、前記PNRデータ記録の情報を前記クローンPNRデータ記録における対応するフィールドに従って変更するステップが、もはや実行不可能となる時間閾値を示す有効期限の指標を含む、請求項１〜３のいずれか１項に記載の方法。
【請求項５】
前記インターフェースモジュールはシングルアクセスインターフェースモジュールである、請求項１〜４のいずれか１項に記載の方法。
【請求項６】
前記インターフェースモジュールは、エンタープライズサービスバス（ESB）又はエンタープライズアプリケーションインテグレーションバス（EAI）を含む、請求項１〜５のいずれか１項に記載の方法。
【請求項７】
前記多チャンネル予約システム内での通信、並びに、前記インターフェースモジュール及び前記旅行サーバを介しての前記多チャンネル予約システムと前記旅行チャンネル間での通信は、サービス指向アーキテクチャ（SOA）によるメッセージにより行われる、請求項１〜６のいずれか１項に記載の方法。
【請求項８】
請求項１〜７のいずれか１項に記載の方法を含む予約方法であって、前記ユーザにより要求された前記少なくとも１つの旅行在庫問い合わせに関連付けられた応答を旅行予約に変換するオプションを提供する、予約方法。
【請求項９】
コンピュータ上で実行された際に、請求項１〜８のいずれか１項に記載の方法のステップを実行するための命令を備えるコンピュータプログラム。
【請求項１０】
インターフェースモジュールを含む多チャンネル予約システムにおける旅行事前予約問い合わせの効率を向上させる予約データ処理システムであって、前記インターフェースモジュールは複数の旅行チャンネルによりアクセス可能であり、各旅行チャンネルは旅行予約サービスをユーザに提供し、前記多チャンネル予約システムは複数の旅行サーバへのアクセスを有し、各旅行サーバは少なくとも１つの旅行リソースに関する在庫情報を提供し、前記予約データ処理システムは、請求項１〜８のいずれか１項に記載の方法を実行するように適合された１以上のコンポーネントを備える、予約データ処理システム。
【請求項１１】
前記複数の旅行チャンネルは互いに通信し、前記充実されたデータ構造は前記複数の旅行チャンネル間で共有されて将来の問い合わせのために再利用されることができる、請求項１０に記載の予約データ処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、旅行予約システムの分野に関するものであり、特にPNR基本構造を変更せずに事前予約エレメント（クオート、quote）を管理する方法及びシステムに関する。
【背景技術】
【０００２】
旅行予約システムは、通常、顧客に対して、複数のオプションを閲覧し、異なるコンポーネント（例えば、フライト予約並びにレンタカー予約及びホテル予約）を組み合わせることにより旅行の手配をシミュレートする可能性を提供する。多くの場合、複数のオプションが総額、旅行手配の利便性及び他の多くのファクターの観点から比較された後に予約の決定が行われる。これらの事前予約活動は、旅行代理業者の日々の業務量の約半分を構成する。しかし、予約プロセスにおけるこの複雑な局面を、生産性の観点から最適化し、更なるビジネス分析のために事前予約データに永続性を与えるための適切なツールがない。
【０００３】
事前予約活動の主要な側面としては、クロスチャンネルコンテキストにおいて、旅行者に対して提案及び共有すべき「クオート」の管理がある。これらの「クオート」が、旅行者による意思決定のための純粋な情報用資料であるか、対案を作成するための手段であるか、又は言葉により表現された願望を単に捕捉するためであるかを問わず、今日においては、これらを支援するための適切な機能性が明らかに欠けている。
【０００４】
その上、特定の市場では、法人代理業者は、作成された予約についての代替案を提示するよう契約上で義務付けられており、これらの代替案を格納し、共有し、フォローアップするための自動化された手段を必要としており、これらの要求に対応するものとしては、扱いにくい、スクリプト型の又は全くのワークフロー統合型のワークアラウンドだけが利用可能となっており、これらは、更なるビジネスインテリジェンスのために事前予約データを捕捉及び使用する統合手段を有していない。
【０００５】
また、あり得る予算制約への配慮により、厳格なオペレーション管理が課されるのである：すなわち、厳格な基準を、事前予約活動トレーサビリティー、パフォーマンス測定及びリソース最適化について提案しておかなければならない。
【０００６】
収集された情報は、旅サプライヤ及び旅行代理業者による事前予約情報についてのビジネスインテリジェンスを支援するため、統計及び使用状況報告のために利用可能とされることも意図されている。
【０００７】
主たる複雑性の１つは、旅行業者と顧客がどこからでも事前予約情報を共有できるようにするため、クロスチャンネル対応とする必要性から派生する。ソリューションは好適にはセントラルであるべきだが、保存された旅行手配は既販売の旅行手配と同じ手法で格納されることはできない。価格についても同様であり、システムは、チケットをもたらした現実の価格と同じ手法でこれを保存することはできない。この問題を解決するには、完全に新しいソリューションを創造しなければならない。
【０００８】
他にあり得る課題としては、エンドユーザと同じフローで、エアーセグメントだけでなく、様々な種類の旅行手配を処理する必要があるということがある。現在、グローバルなディストリビューションシステムにおいては、ブッキング及びレザベーションは、パッセンジャーネームレコード（Passenger Name Record）に格納されている。もっとも、このPNRたるものは、クオート等の確定的に予約されていない旅行手配の部分の格納を許さない。結果として、全ての事前予約データ統合及び顧客への送付は、通常、オープンされたPNRセッションの持続期間中有効とされ、または、煩雑なフリーフロー備考欄の使用を特に介して、手動的にPNR内に追加される。この間隙を埋めるために、最先端のリモートシステムは、各々独自のソリューションを開発しており、これらは依然「ローカル」なものに留まり、ミッドオフィスシステムやデータウェアハウス等の主要エンティティに統合されておらず、統合されたフォローアップを可能としない。最後に、このようなクオート情報を格納することについての困難性により、これらを確定的な予約に変換するプロセスは単純な変換ではなく、通常は自動化を伴わない、完全に手動のプロセスに依存する。
【０００９】
特許文献１には、複数のコンピュータ予約システム（computer reservation system, CRS）に対して、同時に、アクセスを提供する方法が開示されている。この結果、旅行代理業者及びオンライン旅サービスプロバイダは全てのCRSを同時にエンドユーザに接続して、エアーセグメント、車両セグメント、ホテルセグメント等の旅アイテムセグメントのうちより適切なものを選択することができる。エンドユーザが少なくとも１つの旅アイテムセグメントを予約したい場合には、スーパーパッセンジャーネームレコードが該旅アイテムセグメントに関連付けられたデータを、エンドユーザにより予約済みとして、格納する。エンドユーザはスーパーパッセンジャーネームレコードにアクセスして、格納した旅アイテムセグメントを変更できる。
【００１０】
特許文献２には、エンドユーザのための予約の効率を向上させるための旅ネットワークを提供するための方法及びシステムが開示されている。ポイントオフサービス（Point Of Service, POS）端末又はウェブベースドユーザインターフェースを有するアプリケーションシステムもネットワークに接続されて、エンドユーザのためのグローバルディストリビューションシステム（Global Distribution System, GDS）へのアクセスが提供される。各POS端末又はアプリケーションは、以前に予約された旅行の全てを参照する履歴データ等の旅行予約情報を格納するスーパーパッセンジャーネームレコードへのアクセスを少なくとも提供する。
【００１１】
上述した２つの先行技術文献は、多チャンネル予約を単一の「スーパーPNR」に結合する改良されたPNRを説明するが、同様の構造化されたプロセスにてオファー（即ち、未確定の予約）を処理することについての問題を解決していない。一方、他の既存のシステムでは、顧客による旅行手配の選定を支援するために旅オファーの管理が行われるが、PNRと旅オファーとの間での統合がない。例えば、特許文献３には、旅オファーを処理して、旅行者、旅行代理業者及び旅サプライヤとの間での旅費の管理を向上させる方法及びシステムが開示されている。まず、旅行者は、旅の提案を作成して、かつ、それに対応する予算を提示する必要がある。このようなデータを特定のデータベースに格納する。旅行代理業者は、このデータベースにローカルでアクセスし、格納されている対応する旅の提案の予約を遂行することができる。
【００１２】
したがって、クオートを確定的な予約に変換することができ、また、ビジネスインテリジェンス及び分析のための自動化されたリポートを実現するような予約システムと統合され得る、「クオート」又は「対案」を格納及び伝達するための、セントラルでありクロスチャンネルな設備を用いてこれらの間隙を埋めることのできるソリューションが高度に望まれる。
【先行技術文献】
【特許文献】
【００１３】
【特許文献１】米国特許出願第2002/0152100号
【特許文献２】米国特許出願第2003/0144867号
【特許文献３】国際公開公報第WO2008/090530号
【発明の概要】
【発明が解決しようとする課題】
【００１４】
本発明は、先行技術のシステムに関連付けられている問題の少なくとも一部を軽減することを目的とする。
【００１５】
本発明の１つの側面によれば、インターフェースモジュールを含む多チャンネル予約システムにおける旅行事前予約問い合わせの効率を向上させる方法であって、前記インターフェースモジュールは複数の旅行チャンネルによりアクセス可能であり、各チャンネルは旅行予約サービスをユーザに提供し、前記予約システムは複数の旅行サーバへのアクセスを有し、各サーバは少なくとも１つの旅行リソースに関する在庫情報を提供し、前記方法は、前記予約システムが、前記旅行チャンネルの１つから、前記インターフェースモジュールを介して、PNRデータ記録と少なくとも１つの旅行在庫問い合わせを含むユーザ要求を受信するステップと、前記予約システムが、前記PNRデータ記録の同じフィールドを含むクローンPNRデータ記録を作成するステップと、前記クローンPNRデータ記録を、前記旅行在庫問い合わせに基づいて前記複数の旅行サーバの少なくとも１つより取得した情報で、充実させるステップと、ユーザ入力に応答して、前記PNRデータ記録の情報を、前記クローンPNRデータ記録における対応するフィールドに従って変更するステップと、前記インターフェースモジュールを介して、前記ユーザにより要求された前記少なくとも１つの旅行在庫問い合わせに関連付けられた応答を返送するステップとを含む、方法が提供される。
【００１６】
本発明の好適な実施形態による方法は、「オファー」（offer）と称される保存クオートのリストを、PNRと一緒に保管し、かつ提案することを可能とする。これらオファーは、一旦作成されると、旅行者がこれをアクセスして、提案側の旅行業者とのクロスチャンネルで双方向の対話にて自己の選択を下せるように、旅行者に伝達されることができる。
【００１７】
エンドユーザに対してはPNRの様相を呈したまま、確定的な予約に加えてクオテーション（quotation）／オファーに適応できるように標準的PNRが改良され、予約以外のなにものもネイティブには許容しないPNRの構造上の制約を解除している。ユーザの検索の試みを永続的かつ再利用可能とすることに加えて、PNRへのクオテーションの加入は、全てのディストリビューションチャンネルを介してこれらをアクセス可能にし、本発明に完全なるクロスチャンネルな側面を付与する。
【００１８】
この新たな機能性は旅行代理業ワークフローにとって莫大な改良となる。なぜならば、全ての事前予約活動の保存は自動化されて旅行業者自身により（フォローアップ及びコンファメーション目的のために）追跡可能であり、かつ、一般的に使用されるミッドオフィス及びリポーティングシステムへの送信にふさわしいからである。
【００１９】
本発明の他の有利な特徴としては、クオテーションのマルチプロダクト側面がある。実際、PNRは車両、ホテル、保険、鉄道及び空路等の異なるプロダクトタイプについての予約を格納することができるため、同様にこれら全てのプロダクトについてクオテーションを作成及び格納することができる。したがって、クオテーションが置かれるべき技術的なコンテナは、クオート間の共通データ及び全てのプロダクトの特異性の双方に適合する必要がある。GDSによって直接的に分配されていないプロダクトを、予約レファレンス又はクオートとして、PNR内に統合することすらできる。事前予約／予約時のフローの複数のステップは、どの旅行チャンネルからでも開始することができ、他のチャンネルで継続され、初期のチャンネル又は他のチャンネルで確定することができる。
【００２０】
また興味深いといえるものが、同じレコード（即ち、PNR）内で予約及びクオテーションを共有する場合に構築することのできる集合体である。実際に、本発明のおかげで、ディストリビューションシステムは、ユーザが予約及びオファーのセットを構築できるようにする。
【００２１】
本発明の第２の側面によれば、上述した方法を実行するように適合させた１以上のコンポーネントを備えるシステムが提供される。
【００２２】
本発明の更なる実施形態によれば、上述した方法をコンピュータ上での実行時に実行するための命令を備えるコンピュータプログラムが提供される。
【図面の簡単な説明】
【００２３】
添付の図面について、例示的に、以下参照する。
【図１】本発明の１実施形態による、予約システムを示す図である。
【図２】本発明の好適な実施形態の方法を支援するように適合させた汎用コンピュータシステムを示す図である。
【図３】本発明の好適な実施形態を実装するシステムのソフトウェア構成要素を示す図である。
【図４】本発明の好適な実施形態による方法で使用されるクローンPNRを示す図である。
【図５】本発明の１実施形態によるプロセスの方法ステップのフローチャートを示す図である。
【発明を実施するための形態】
【００２４】
図１は、本発明の好適な実施形態による方法及びシステムを実装するのに適した予約システムを示す。中央の旅行予約サーバ１０１は、ネットワークを通じて、複数のクライアントモジュール１０３（チャンネルとも称す）によりアクセス可能であり、これらのモジュールにより旅行代理業者及び／又はエンド顧客は、予約システムへアクセスすることができる。予約サーバ１０１は、ネットワーク（例えば、インターネット）を通じて、様々な旅行手配についての情報を検索して顧客のためにオファー及び／又は予約を構築できるようにする複数のプロバイダ在庫データベース１０５へのアクセスを有している。プロバイダ在庫データベース１０５は、あり得る複数の旅行手配の種類を含む：例えば、フライト、ホテル、列車、レンタカー等。予約は、通常、予約システムにとっての標準として普遍的に受け入れられている乗客名記録（PNR）と呼ばれるデータ記録によって処理される。各プロバイダ在庫データベース１０５は、旅行情報を検索すること及び旅行予約活動を行うことに適した少なくとも１つのサーバを、含む。本発明の１つの利点は、未確定予約（即ち、オファー）についての追加的な情報が、既存のPNRを変更せずに、外部ユーザにとって透過的な方法で処理されることである。他方、本発明の好適な実施形態によるシステムのユーザは、予約及びオファーの情報を、クローンPNRと呼ぶものを通じて、１つの単一オブジェクトとして見ることができる。これにより、中央のシステムへオファーを容易にプラグインし、及び、オファーをクローン内の新たなPNRエレメントとして定義できるようになる。そして、中央のシステムは、PNRとPNRにそっくりなもの（クローン）とを含むことになる。図１に示される好適な実施形態によるシステムは、全てのチャンネルプロダクト１０３についてのビジネスロジック及びカスタマイゼーションの管理を担当しかつクライアントモジュール１０３と中央の予約サーバ１０１との間でのやりとりのためのページフロー及び必要なデータ変換及びマッピングを処理するフロントエンドフレームワーク（或いはサーバ）１０７も含む。また、幾つかの外部サーバ１０９をフロントエンドサーバ１０７はアクセスすることができ、これら外部サーバ１０９はプロバイダ在庫データベース１０５を通じて予約サーバ１０１がアクセスすることのできない追加的なコンテンツを提供することができる。本発明の好適な実施形態では、サービスインテグレータ１１１も提供される。サービスインテグレータ１１１は、例えば、全てのサーバ間通信をルーティングし、セッションコンテキストを維持し、及び通信プロトコルについて独立性を許容するエンタープライズアプリケーションインテグレーション（EAI）バス（例えば、Amadeus SAにより開発されたそれ）又はエンタープライズサービスバス（ESB）とすることができる。これは、フロントエンドサーバ１０７のリクエスト又は外部サーバ（例えば、クライアント１０３）のリクエストを、ウェブサービスを通じて、サービスをホスティングしているバックエンドサーバへ、及び、中央の予約サーバ１０１からプロバイダ在庫データベース１０５へ、ルーティングする。
【００２５】
PNRクローンは、オファーに固有の問題を簡単に解決する手段である：
―  元の部分（PNR）によりトリガーされるのでありさえすれば、PNRとオファーとを区別するために既存のアプリケーション（フィード、ビリング等）を変更する必要はない。
―  あらゆるタイプの旅程及び価格に対し、コストを伴わずにして、価格及び旅程並びにそれらの相互関係のデータ構造が利用可能となる。
【００２６】
この特徴は、全くの新たなインフラストラクチャを構築する必要なくして、オファーの、又はPNRデータを再利用する任意の新たなコンテナの、シームレスな統合を可能とする。本発明の好適な実施形態において、エレメントをキャンセルすること及びエレメントをコミットすることについて、現行のアーキテクチャから恩恵を受けるためには、クローン間でスワップを行う機能を追加することができる。これは、ユーザ（例えば、旅行代理業者）の視点から完全に隠されることができる。レガシーPNRとクローンのために各々１つの異なるディスプレイを構築することができるものの、旅行業者は単一の機能的エンティティとして、クローンのセットを見ることになる。スワップ機能及びアクティブなクローンのインジケータが設けられていることのおかげで、エレメントのキャンセル等のコマンドはジェネリックなままとされる。これにより、ジェネリックなキャンセルコマンドを受信するエンティティが、コンテキストのどのサブパートでエレメントがキャンセルされるべきかを知り得る。
【００２７】
これからは、事前予約情報は、完全に統合された態様で格納及びフォローアップされることができる：オファーは、将来の潜在的な予約の「プレビュー」として格納されるPNR統合型エレメントであり、価格及びアベイラビリティについての保証なくしてアベイラビリティ及び価格情報を捕捉するものであり：旅行者、旅行業者又はプロバイダからの約束を伴わない。
【００２８】
この完全な統合は、処理及び旅行の他のパーツ、即ち同じPNRの部分に既になっている予約及びオファー、のアグレゲーションについて高度な柔軟性を実現する。
【００２９】
Amadeus PNRに統合されているということは、PNRデータについて利用可能な既存のサービスに対しての利点をもたらし、また、旅程生成、電子メール送信、PNR履歴、既存のアカウンティングメッセージを介したデータエクスポート等のPNRに固有の機能に統合することもできる。
【００３０】
Amadeus IT Group SAの予約システムは、本発明の好適な実施形態による方法を実装することのできる予約システムプラットフォームの例である。本発明の好適な実施形態による予約システムはクライアント／サーバアーキテクチャによって編成されており、前記予約サーバは複数のクライアントモジュールによるリクエストを受信し、各クライアントモジュールは異なる旅コンテントプロバイダの１つのために作動する。システム内での通信及び外部システムへ向けての通信は、ネットワークを通じてシステム間で情報を交換するため及びサービス（例えば、ウェブサービス）をアクセスするための周知なプロトコルであるサービス指向アーキテクチャ（SOA）標準に準拠して行われる。
【００３１】
本発明の好適な実施形態による方法の主要な側面の１つは、複数のチャンネル及び複数の異なるプロバイダに対応することができるという点である。これは、サービス間の通信を支援する下支え機構であるSOAの柔軟性により保証される。オファーは、旅行業者と顧客との間での対話的な旅精緻化を伴う主要なクロスチャンネルシナリオに対処できるように設計されており：例えばAmadeus E-Travel Managementのようなオンラインアプリケーションは、旅行業者によりなされたオファーをユーザが閲覧及び承認若しくは棄却できるようにする。
【００３２】
事前予約プロセスの任意の段階で利用可能なセントラルサービスとして、オファーを統合的に管理することにより、任意のフォローアップアクション（アベイラビリティの再チェック、コンファメーション、クレーム申し入れ等）を任意のチャンネルにより処理できるようになる。例えば、コンファメーションは、自己のウェブベースドツールを介して旅行者により行われことができ、或いはメールかSMSか単なる通話を介してその旨の指示を受けた旅行代理業者により行われることができる。
【００３３】
Amadeus内にオファーを格納することにより、事前予約情報を選択したデータウェアハウス、レポジトリ及びミッドオフィスシステムに送信できるようになり、リポーティング並びに事前予約の行動及び活動についての更なるビジネス分析が可能となる。
【００３４】
Amadeusのオファーに関するソリューションの範疇には、自己の従業員の事前予約活動を追跡及び分析することについての、中規模の旅行業者のニーズに仕えるための標準的リポートの生成も含まれる。
【００３５】
図２を参照するに、システム（例えば、コンピュータ、アライアンスモジュールサーバ、データベース管理サブシステム、ルータ、ネットウォッチャーサーバ）の汎用コンピュータが符号２５０を付して表示されている。コンピュータ２５０は、システムバス２５３に並列で接続された複数のユニットにより形成されている。詳しくは、１以上のマイクロプロセッサ２５６がコンピュータ２５０の動作を制御し；マイクロプロセッサ２５６によりRAM２５９がワーキングメモリとして直接的に使用され、ROM２６２がコンピュータ２５０をブートストラップするための基本的コードを格納する。周辺ユニットは、ローカルバス２６５の周りに（各々のインターフェースによって）クラスタされる。特に、マスメモリ（mass memory）は、ハードディスク２６８及びCD-ROM２７４を読み込むためのドライブ２７１からなる。さらに、コンピュータ２５０は、入力装置２７７（例えば、キーボード及びマウス）及び出力装置２８０（例えば、モニタ及びプリンタ）を含む。コンピュータ２５０をネットワークに接続するのにネットワークインターフェースカード２８３が用いられる。ブリッジユニット２８６が、システムバス２５３をローカルバス２６５に結合する。各マイクロプロセッサ２５６及びブリッジユニット２８６は、情報を伝送するためのシステムバス２５３へのアクセスを要求するマスターエージェントとして作動することができる。アービタ２８９が、相互排他性を伴うシステムバス２５３へのアクセスの許可を管理する。システムが異なるトポロジを有する場合又は他のネットワークに基づいている場合にも、類似の考察が妥当する。別の場合には、コンピュータは異なる構造を有するか、等価なユニットを含むか、又は他のデータ処理エンティティ（PDAや携帯電話等）を備える。
【００３６】
図３には、本発明の方法を実装するアーキテクチャのソフトウェア構成要素が示される。本発明の好適な実施形態によれば、サービスインテグレータ３０１が予約システム（例えば、Amadeus予約インフラストラクチャ）のエントリーポイントである。到来してきた予約クエリは、エージェントセッション中の予約コンテキストの保持を担当するPNRコンテキストサーバ３０３により受信される。このエンティティは、伝統的なPNRコンテンツ（確定的な予約）及びクオートコンテンツの双方を認識している。到来してきたクエリがクオートに関する場合、それはオファーサーバ３０５へと転送され、予約コンテキストがオファーサーバ３０５に提供される。本発明の好適な実施形態によれば、オファーサーバ３０５は、必要とされる全てのサービスの統合及び純粋なクオートデータ（クオートの状態、有効性、セキュリティーチェック等）の管理を担当している。オファーサーバ３０５は、受信されたクエリ内で指定されたユーザのニーズに従って、リクエストを適切なサーバへ仕向ける。本発明の好適な実施形態によれば、オファーサーバ３０５と通信し、サービスを提供するサーバは、例えばレガシーシステムTPF３０７、価格サーバ３０９、（説明される実施形態においては価格サーバ３０９を通じてアクセス可能な）アベイラビリティサーバ３１１及びセグメント販売サーバ３１３である。例えば、多くの自動化されたユーザクエリ（即ち、オファーをコンファームして予約に変換すること）の最中では、オファーサーバ３０５は特定のオーダー内のコールを実行する。まずオファーサーバ３０５は、価格サーバ３０９による価格チェック及びアベイラビリティサーバ３１１によるアベイラビリティ再チェックを、リクエストする。そして、価格が変わっておらず、座席（又は部屋又は他の任意の予約エレメント）がまだ利用可能である場合、オファーサーバ３０５は、セグメント販売サーバ３１３に予約をリクエストし、これによりTPFレガシーシステム３０７上のPNRに記録される予約作成及びクローン更新がもたらされる。そして、オファーサーバ３０５は、再び価格サーバ３０９と通信して、新たに作成された予約に対して、オファーと同じ価格コンテキストパラメータを伴う価格付けを行う。最後にオファーサーバ３０５はクローン状態を更新して、PNRコンテキストサーバ３０３及びサービスインテグレータ３０１を通じて、エンドユーザに動作の成功をコンファームする。
【００３７】
図４では、本発明の好適な実施形態による予約ファイルの構造を説明する。
【００３８】
図４に示すように、クローンPNR内のオファーセクションは下記を含むことができる：
―状態（即ち、アクティブ、アベイラブルでない等）
―有効日付（及び必要ならば時刻）
【００３９】
同じデータコンテナを用いて、フライト及び価格情報がレガシーPNR内に格納され、オファーセクションのエレメントとリンクされる。
【００４０】
オファーの目的は、PNRフルチェック制約を受けずに、予約から、信頼性のあるクオテーション提供へ、できる限り近づくことである。オファーは、事前予約にエンドユーザに対して示されるアイテムに関しての提案であり；即ち、アベイラビリティ及びクオテーションであり、価格及びアベイラビリティに関して保証を伴わない。これは、顧客の観点からは、特定の時点における旅行代理業者の提案のスナップショットであると理解することができる。
【００４１】
オファーは、下記によって、クローンPNRのエレメントとして具体化される：
―  合計価格を伴うオファーヘッダー
―  標準的なホテル若しくは車両セグメント又はより少ないデータを伴う（コンファメーション番号を欠く等する）エアー若しくは鉄道についてのセグメントのセットに過ぎないプロダクト詳細
―  例えば、暫定格納チケットのようにバックグラウンドで格納される価格レコード。
【００４２】
一旦オファーが作成されると、いつでも下記を行うことができる：
―  検索及び表示
―  再バリデート  ―アベイラビリティ及び価格がチェックされる
―  コンファーム  ―エンドユーザがオファーを確定的な予約に変換したい場合
―  棄却
―  キャンセル。
【００４３】
そして、どのプロダクトに基づいていようとも、全てのオファーはクローンPNR内にて格納される。オファー及び予約は、同じ基本的データ構造内に格納されかつ同質であるため、（予約又はオファーとして格納される）プロダクトのセットを作成することができる。そして、エンドユーザは複数の組合せを構築して、これらを比較等することができる。機能的には、オファーはクローンPNR内のエレメントであり、予約ファイルとも呼ばれる。予約ファイルは、オファーだけを含み予約を含まないことさえもできる。
【００４４】
オファーは、中央のシステムに格納される予約及び予約ファイルの永続的なエレメントに類似した、完全なエレメントとして実装されている。
【００４５】
オファーのセントラリゼーションはユニークなプロセスを持つことを可能にし、全てのディストリビューションチャンネルからこれらをアクセスすることができるようにするのであり；理想的には、完全なるクロスチャンネル性を実現すべく全てのウェブショッピング制約に順応するように、PNRを強化すべきである。すなわち、暗文として作成されたオファーを、ウェブサービスフローの中で検索及び変更できることを意味する。この新たな機能性は、旅行代理業ワークフローにとって莫大な改良となる。なぜならば、全ての事前予約活動の保存が自動化されて再利用可能となるからである。
【００４６】
即ち、どのチャンネルであれ、旅行代理業者又は旅行者自身がワンクリックで以下のことをできることを意味する：
―  オファーを検索して表示すること
―  オファーのアベイラビリティ及び価格を自動的にチェックすること
―  オファーを予約に変換すること
―  オファーを削除すること。
【００４７】
オファーの永続性及びセントラリゼーションは、全てのチャンネルでの処理についてのハーモニゼーションと一貫性をもたらす。アベイラビリティ及び価格の自動的チェック又はオファーのコンファメーションは、チャンネルがなんであれ、同じ手法により行われる。さらに、PNR内にオファーを組み込むことにより、確定的な予約及びオファーを混在させる機能を提供することが可能となる。旅行者に、予約の全貌を提供することができる。旅行者のために生成される電子メールは、確定的な予約及びオファーの全て双方についての要約として集積する。さらに、ディストリビューション側及びプロバイダ側の双方の業界は、ショッパーの行動を理解すること及び顧客の期待により近づくことを支援する上でとても有用なリポーティングデータに、簡単にアクセスできる。
【００４８】
本発明の好適な実施形態による方法及びシステムの利点の１つは、ショッピングエクスピリエンスの全段階に亘って、即ち事前予約活動中に加えて確定的な予約についても、並びに航空プロダクトに加えて車両、ホテルその他の任意のプロダクト若しくは付随役務について、顧客を支援することができることである。本ソリューションは、異なる予約フロー内でのオファー作成を円滑に統合する。
【００４９】
例示的ケースとして、ホテル予約と車両予約を、同じPNRに組み合わせた場合を想定してみよう。価格は、アベイラビリティトランザクションに埋め込まれている。これを、運賃サーチトランザクション（例えば、Master Pricer Expert）内のAIRセグメントについても検索することさえできる。実際に、車両／ホテルのアベイラビリティ又はMPEトランザクションの出力は、プロダクトアベイラビリティのリストにクオテーションを組み合わせたものとして構成される。したがって、それらのレコメンデーションをオファー内に直接に格納するために、後続のトランザクションとして、新たな「オファー作成」のトランザクションが導入される。
【００５０】
他方、鉄道又は標準の航空予約フローについては、エンドユーザは、通常は、適切な価格を探す前に、旅程構築及びフライト若しくはセグメント選択のステップを経る。一旦これら２ステップが実行されると、同じ「オファー作成」トランザクションのおかげで、エンドユーザは、予約プロセスを継続するか、又は、その旅程及び関連付けられた価格を格納するかの選択肢を有することになる。
【００５１】
プロダクトが何であるかに関わらずに同じエントリ及びインターフェースを実装して、オファーを作成することは、異なる全てのプロダクト間でのオファー作成フローの同質化を誘発する。その狙いは、旅行代理業者又は顧客に楽をさせることである。
【００５２】
本発明の好適な実施形態によるクロスチャンネル性の側面は、下記の双方を容易に許容できるオファー構造により実現される：
―  オファー状態、合計価格及び価格詳細までをも格納する共通エレメント
―  各プロダクトタイプ固有事項を伴うプロダクト説明。
【００５３】
プロダクト説明が具体的なままである場合、それは標準的な予約を同様によく近似したままとなり、ユーザは取得するのに慣れている有用な情報の全てを検索することができる。何らかの汎用的なクオテーションデータのための共通フォーマットを共有することにより、オファー相互間での比較等の異なる操作が可能となり、これは意思決定支援においては大きな進歩となる。これら共通データのさらなる潜在的用途としては、オファーでセットを構成することがあり、これをプロポーザルと呼ぶ。これらプロポーザルは、ユーザが自己の全旅程の全貌を把握して自己のリクエストのグローバルコストを把握できるようにするために、オファー又は全旅程を構成する確定的な予約をユーザが収集できるようにする。その後、ユーザは、所与のプロポーザルに含まれる全てのオファーをコンファーム、キャンセル又は再チェックすることにより、単一のプロポーザル内にバンドルされたオファーを操作することもできる。
【００５４】
上述した本発明の１つの実施形態による方法は、図５においても示されている。方法は、多チャンネル予約システムにおける旅行事前予約問い合わせの効率を向上させることを意図しており、前記予約システムはシングルアクセスインターフェースモジュール及び複数の旅行チャンネルへのアクセスを有するオファーサーバを含み、各チャンネルは少なくとも１つの旅行リソースに関する在庫情報を提供するのであり；方法は黒丸５０１で始まり、前記シングルアクセスモジュール、例えば図３において説明されたサービスインテグレータ３０１、を通じて前記システムによってユーザ要求が受信されるボックス５０３へと進む。そして、システムは、上述されたようにクローンPNRを作成する（ステップ５０５）。クローンPNRは、場合によっては、例えば上述した状態フィールド及び有効日付フィールド等の追加のフィールドを伴って、「本物の」PNRの構造を複製する。ユーザ要求が完全に充足されるまで（ステップ５０９）、複数のチャンネルから取得された情報でクローンPNRが充実される（ステップ５０７）。ユーザは、収集された事前予約情報を本物の予約に変換させるオプションを有している（ステップ５１１及び５１３）。本フローチャートでは、このユーザの選択権は全ての事前予約問い合わせステップの後に来るものとして示されているが、上述したようにこれはいつでも行われることができる。この事前予約情報が本物の予約をもたらす必要はなく、その場合にはクローンPNRはユーザに戻されて、ユーザは情報を後の段階で利用することができる。
【００５５】
本開示の範囲から逸脱せずに、上記に対して修正及び変更を加えることができるものと理解される。ローカルな及び具体的な要求を充足するため、当然に、当業者は、上述のソリューションに対して、多数の変更及び修正を加えることができる。本開示では好適な実施形態を参照して一定程度の具体性をもって説明したが、殊に、形式及び詳細についての様々な省略、置換及び変更並びに他の実施形態が可能であり、また、本開示で開示される実施形態との関係で説明される具体的な要素及び／又は方法のステップを他の任意の実施形態に組み込めると、デザイン選択の一般的事項として、明示的に意図されている。
【００５６】
同様の考察は、（本開示の各実施形態を実装するのに用いることができる）プログラムが異なる手法で構築された場合又は追加のモジュール又は機能が提供された場合にも妥当し；同様に、メモリ構造は他のタイプであることができ、又は（必ずしも物理的格納媒体ではない）等価なエンティティと置換されることもできる。さらに、提示されるソリューションは（類似の又は追加のステップを含み、順序を異にさえする）等価な方法により実装されることにも適している。いずれの場合であれ、プログラムは、外部若しくは常駐ソフトウェア、ファームウェア又はマイクロコード（オブジェクトコード又はソースコード）等のデータ処理システムによって又はそれと関連して使用されることについて適している。さらに、プログラムは任意のコンピュータ使用可能媒体上で提供されることができ、媒体はプログラムを含む、格納する、伝達する、伝播させる又は移転させるために適した任意の要素であることができる。このような媒体の例としては、（プログラムを予めロードしておける）固定ディスク、脱着可能ディスク、テープ、カード、ワイヤ、ファイバ、ワイヤレス接続、ネットワーク、放送波等があり；例えば媒体は電子的、磁気的、光学的、電磁気的、赤外線又は半導体のタイプのものであることができる。
【００５７】
いずれの場合であれ、本開示によるソリューションは、ハードウェア構造（例えば、チップ又は半導体材料に統合されたもの）又はソフトウェアとハードウェアの組合せによる実行に適している。
【図１】
0005863072.tif 000002
【図２】
0005863072.tif 000003
【図３】
0005863072.tif 000004
【図４】
0005863072.tif 000005
【図５】
0005863072.tif 000006