(57)【要約】オンライン方式のバウチャー管理システムであって、このシステムは、旅行代理店、航空会社、並びにオンライン利用ユーザが、バウチャーの発行及びバウチャーによる支払充当を行うための、ユーザ・インターフェースを提供する。また、オンライン・ポータルを介して、ＰＮＲが格納されているＧＤＳにアクセスできるようにしてある。バウチャーの発行は、仮想航空旅程とそれに対応したチケット関連データとを含む規格化されたＰＮＲを生成することによって行われる。ユーザがユーザ・インターフェースを介してバウチャーの額面金額などの必要な情報を設定すると、それらの情報を含むＰＮＲがＧＤＳの中に生成される。こうして生成されたＰＮＲは、規格化された予約処理手順に従ってチケット化され、即ちバウチャーとして発券される。発券された後には、そのバウチャーによる支払充当の処理が、通常のＰＮＲ再発行の処理として管理される。【選択図】図１
2010500680.tif 000002
【特許請求の範囲】
【請求項１】
バウチャーの発行方法において、
グローバル・ディストリビューション・システムに複数の現実パッセンジャー・ネーム・レコードを格納し、該複数の現実パッセンジャー・ネーム・レコードは、その各々が少なくとも識別データと旅程に関するデータとを含んでおり、
仮想パッセンジャー・ネーム・レコードを生成し、該仮想パッセンジャー・ネーム・レコードは少なくとも識別データと、仮想旅程に関するデータと、額面金額とを含んでおり、
前記仮想パッセンジャー・ネーム・レコードを前記グローバル・ディストリビューション・システムに格納し、
費用金額が含まれた旅行計画情報を受取り、
前記仮想パッセンジャー・ネーム・レコードを現実パッセンジャー・ネーム・レコードに変換し、該変換が、前記費用金額の少なくとも一部に対して前記額面金額の少なくとも一部を充当することを少なくとも含み、
前記変換で得られた現実パッセンジャー・ネーム・レコードを前記グローバル・ディストリビューション・システムに格納する、
ことを含む方法。
【請求項２】
前記額面金額の前記少なくとも一部が前記費用金額の前記少なくとも一部より大きい場合に、前記変換を禁止する、
ことを更に含む請求項１記載の方法。
【請求項３】
仮想パッセンジャー・ネーム・レコードの前記生成が、
前記グローバル・ディストリビューション・システムから１つの現実パッセンジャー・ネーム・レコードを選択し、
前記選択した現実パッセンジャー・ネーム・レコードの内容に変更を加えて前記仮想パッセンジャー・ネーム・レコードに変更する、
ことを更に含む請求項１記載の方法。
【請求項４】
前記変換が、
前記選択した現実パッセンジャー・ネーム・レコードの全体のうち、前記選択した現実パッセンジャー・ネーム・レコードの旅程のうちの利用済旅程部分に対応した部分を抹消し、
前記選択した現実パッセンジャー・ネーム・レコードの旅程のうちの未利用旅程部分に基づいて前記額面金額を設定する、
ことを更に含む請求項３記載の方法。
【請求項５】
仮想パッセンジャー・ネーム・レコードの前記生成が、
前記グローバル・ディストリビューション・システムから１つの現実パッセンジャー・ネーム・レコードを選択し、
前記選択した現実パッセンジャー・ネーム・レコードに含まれる情報に少なくとも部分的に基づいて仮想パッセンジャー・ネームを生成する、
ことを更に含む請求項１記載の方法。
【請求項６】
前記額面金額を、ユーザが、ギフト券の総額を表すものとして設定する、
請求項１記載の方法。
【請求項７】
前記額面金額を、航空会社が、ユーザに支払う補償金の額を表すものとして設定する、
請求項１記載の方法。
【請求項８】
前記仮想パッセンジャー・ネーム・レコードと前記現実パッセンジャー・ネーム・レコードとは互いに同一のデータベース・フォーマットを有する、
請求項１記載の方法。
【請求項９】
前記変換により得られた前記現実パッセンジャー・ネーム・レコードに基づいてチケットを発券する、
ことを更に含む請求項１記載の方法。
【請求項１０】
バウチャーの発行方法において、
データベース・ネットワークに複数の現実トラベル・レコードを格納し、それらトラベル・レコードは、その各々に少なくとも識別データと旅程に関するデータとが関連付けられており、
仮想トラベル・レコードを生成し、該仮想トラベル・レコードには、少なくとも識別データと、仮想旅程に関するデータと、額面金額とが関連付けられており、
前記仮想トラベル・レコードを前記データベース・ネットワークに格納し、
費用金額が含まれた旅行計画情報を受取り、
仮想パッセンジャー・ネーム・レコードを現実トラベル・レコードに変換し、該変換が、前記費用金額の少なくとも一部に対して前記額面金額の少なくとも一部を充当することを少なくとも含み、
前記変換で得られた現実トラベル・レコードを前記共通データベースに格納し、
前記仮想トラベル・レコードと前記現実トラベル・レコードとは互いに同一のデータベース・フォーマットを有する、
ことを含む方法。
【請求項１１】
前記額面金額の前記少なくとも一部が前記費用金額の前記少なくとも一部より大きい場合に、前記変換を禁止する、
ことを更に含む請求項１０記載の方法。
【請求項１２】
仮想トラベル・レコードの前記生成が、
前記グローバル・ディストリビューション・システムから１つの現実パーソナル・トラベル・レコードを選択し、
前記選択した現実パーソナル・トラベル・レコードの内容に変更を加えて前記仮想パーソナル・トラベル・レコードとする、
ことを更に含む請求項１０記載の方法。
【請求項１３】
前記変換が、
前記選択した現実パーソナル・トラベル・レコードの全体のうち、前記選択した現実パーソナル・トラベル・レコードの旅程のうちの利用済旅程部分に対応した部分を抹消し、
前記選択した現実パーソナル・トラベル・レコードの旅程のうちの未利用旅程部分に基づいて前記額面金額を設定する、
ことを更に含む請求項１０記載の方法。
【請求項１４】
仮想トラベル・レコードの前記生成が、
前記グローバル・ディストリビューション・システムから１つの現実パーソナル・トラベル・レコードを選択し、
前記選択した現実パーソナル・トラベル・レコードに含まれる情報に少なくとも部分的に基づいて仮想パッセンジャー・ネーム・レコードを生成する、
ことを更に含む請求項１０記載の方法。
【請求項１５】
前記額面金額を、ユーザが、ギフト券の総額を表すものとして設定する、
請求項１０記載の方法。
【請求項１６】
前記額面金額を、航空会社が、ユーザに支払う補償金の額を表すものとして設定する、
ことを特徴とする請求項１０記載の方法。
【請求項１７】
前記仮想パーソナル・トラベル・レコードと前記現実トラベル・レコードとは互いに同一のオンライン・ポータルを介してアクセス可能である、
請求項１０記載の方法。
【請求項１８】
バウチャーの発行方法において、
グローバル・ディストリビューション・システムに複数の現実パッセンジャー・ネーム・レコードを格納し、該複数の現実パッセンジャー・ネーム・レコードは、その各々に、少なくとも識別データと旅程に関するデータとが関連付けられており、
仮想パッセンジャー・ネーム・レコードを生成し、該仮想パッセンジャー・ネーム・レコードには、少なくとも識別データと、仮想旅程に関するデータと、額面金額とが関連付けられており、
前記仮想パッセンジャー・ネーム・レコードを、支払充当可能な残高金額を表すレコードであるものと指定し、
前記仮想パッセンジャー・ネーム・レコードを、前記グローバル・ディストリビューション・システムに格納し、
前記仮想トラベル・レコードと前記現実トラベル・レコードとは互いに同一のデータベース・フォーマットを有する、
ことを含む方法。
【請求項１９】
仮想パッセンジャー・ネーム・レコードの前記生成が、
前記グローバル・ディストリビューション・システムから１つの現実パッセンジャー・ネーム・レコードを選択し、
前記選択した現実パッセンジャー・ネーム・レコードに含まれる情報に少なくとも部分的に基づいて前記仮想パッセンジャー・ネーム・レコードを生成する、
ことを更に含む請求項１８記載の方法。
【請求項２０】
前記額面金額を、ユーザが、ギフト券の総額を表すものとして設定する、
請求項１８記載の方法。
【請求項２１】
前記額面金額を、航空会社が、ユーザに支払う補償金の額を表すものとして設定する、
請求項１８記載の方法。
【請求項２２】
トラベル・バウチャーによる支払充当の処理方法において、
グローバル・ディストリビューション・システムから１つの仮想パッセンジャー・ネーム・レコードを読出し、該仮想パッセンジャー・ネーム・レコードには、少なくとも識別データと、仮想旅程に関するデータと、額面金額とが関連付けられており、
費用金額が含まれた旅行計画情報を受取り、
前記仮想パッセンジャー・ネーム・レコードを現実パッセンジャー・ネーム・レコードに変換し、該変換が、前記費用金額の少なくとも一部に対して前記額面金額の少なくとも一部を充当することを少なくとも含み、
前記変換で得られた現実パッセンジャー・ネーム・レコードを前記グローバル・ディストリビューション・システムに格納する、
ことを含む方法。
【請求項２３】
前記額面金額の前記少なくとも一部が前記費用金額の前記少なくとも一部より大きい場合に、前記変換を禁止する、
ことを更に含む請求項２２記載の方法。
【請求項２４】
仮想パッセンジャー・ネーム・レコードの前記生成が、
前記グローバル・ディストリビューション・システムから１つの現実パッセンジャー・ネーム・レコードを選択し、
前記選択した現実パッセンジャー・ネーム・レコードの内容に変更を加えて前記仮想パッセンジャー・ネーム・レコードに変更する、
ことを更に含む請求項２２記載の方法。
【請求項２５】
前記変換が、
前記選択した現実パッセンジャー・ネーム・レコードの全体のうち、前記選択した現実パッセンジャー・ネーム・レコードの旅程のうちの利用済旅程部分に対応した部分を抹消し、
前記選択した現実パッセンジャー・ネーム・レコードの旅程のうちの未利用旅程部分に基づいて前記額面金額を設定する、
ことを更に含む請求項２２記載の方法。
【請求項２６】
仮想パッセンジャー・ネーム・レコードの前記生成が、
前記グローバル・ディストリビューション・システムから１つの現実パッセンジャー・ネーム・レコードを選択し、
前記選択した現実パッセンジャー・ネーム・レコードに含まれる情報に少なくとも部分的に基づいて前記仮想パッセンジャー・ネーム・レコードを生成する、
ことを更に含む請求項２２記載の方法。
【請求項２７】
前記額面金額を、ユーザが、ギフト券の総額を表すものとして設定する、
請求項２２記載の方法。
【請求項２８】
前記額面金額を、航空会社が、ユーザに支払う補償金の額を表すものとして設定する、
請求項２２記載の方法。
【請求項２９】
前記仮想パッセンジャー・ネーム・レコードと前記現実パッセンジャー・ネーム・レコードとは互いに同一のデータベース・フォーマットを有する、
請求項２２記載の方法。
【請求項３０】
前記変換により得られた前記現実パッセンジャー・ネーム・レコードに基づいてチケットを発券する、
ことを更に含む請求項２２記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本件特許出願は、２００６年８月１５日付け出願の米国特許出願第11/504,047号に基づく優先権を主張するものである。尚、同米国特許出願の開示内容は、この言及をもってその全体が本件特許出願に組込まれたものとする。
【０００２】
本発明は、バウチャー（金券）を管理するための統合化システムに関する。より詳しくは、本発明は、航空会社が既に使用しているパッセンジャー・ネーム・レコード・システム（航空機乗客名簿記録システム，ＰＮＲシステム）の中に仮想ＰＮＲを生成することによってバウチャーの発行の処理を行い、また、通常のＰＮＲの再発行処理によってバウチャーでの支払充当の処理を行うようにした統合化システムに関する。
【背景技術】
【０００３】
現在使用されている典型的な旅行予約システムは、パッセンジャー・ネーム・レコード・システムとして構成されている。パッセンジャー・ネーム・レコード（ＰＮＲ）とは、グローバル・ディストリビューション・システム（ＧＤＳ）に格納されるファイルであって、その各々が、１つ１つの旅行予約に関する情報を含んでいるファイルである。また、ＧＤＳとは、コンピュータで構成された予約処理システムであって、通常は、幾つもの国の多数の航空会社によって共有されており、また、幾つもの国の多数の旅行関連業者のデータベースを包含するシステムとして構成されている。
【０００４】
航空会社はしばしば、利用者に対して、クレジット処理、チケット購入代金の返金、それに様々な補償金等の支払いを行わねばならないか、或いは、支払いを考慮する状況に直面する。このような状況としては、例えば、未使用チケット、欠航、荷物紛失、フライトの解約、オーバーブッキングを原因とする搭乗者の自主的解約、特別キャンペーンを実施する場合、それに、払戻可能チケットを所持しているユーザが単に搭乗を取りやめた場合などがあり、更にその他にも様々な状況がある。またそれらの状況において、ユーザに補償金等を支払う際の支払形態としては、現金による返金の他に、ユーザが他日の旅行費用などに支払充当するか、その他への費用支払いをすることのできるバウチャー（金券）を交付するという支払形態がある。現金で返金した場合には、ユーザがその現金を何に使うか分からないのに対して、バウチャーを費用の支払いに充当することは、通常、航空会社か指定代理店を通さなければできないため、補償金等を支払う側としては、現金で返金するよりも、バウチャーを交付する方が好都合である。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
バウチャーの管理のための処理には多大のコストを要する。一般的に、航空会社が使用している、代金決済、料金請求、予約処理、及び／または、情報管理のためのシステムには、バウチャーを発行するための処理機能は組込まれていない。また、バウチャーによる支払充当の処理は、販売チャネルを介して行うことができないため、大抵の場合、ＰＮＲを手作業で作成している業務委託会社に電話連絡をしてその処理を依頼しなければならない。バウチャーによる支払充当の処理は複雑であり、それが複雑であるのは、航空会社の側で新たな予約内容を参照して、そのバウチャーの額面の少なくとも一部が既に支払いに充当されたか否かを確認しなければならず、また、支払いに充当されていた場合には、その充当された金額と、その金額に含まれている税額とを確認しなければならないからである。更に航空会社は、あるバウチャーによる支払充当がそのバウチャーの額面の満額に達するまで反復して行われる場合には、その支払充当が行われる度に、それが行われたということを情報管理システムに反映させなければならない。これらのことから、バウチャーの発行及び管理のための処理の流れは、オンライン販売チャネルで取扱うことが困難となっている。また、それらの処理をオンライン販売チャネルで取扱おうとすれば、ユーザ情報漏洩ということが問題となり、更に、コスト管理上の問題も発生する。
【０００６】
航空会社のうちには、バウチャーの発行及びバウチャーでの支払充当の処理を、独立したデータベース・システムによって、オンライン方式で行うことを企図している航空会社もある。しかしながら、そうした場合には、決済処理が対外決済であることから、航空会社は、ある額面のバウチャーの発行という事象を識別するための何らかの情報管理機構を併せて保持しなければならない。また、バウチャーの発行の処理に関しては、バウチャーの発行対象者、バウチャーの総額、それにバウチャーの有効期限に関する全ての情報を保持するための特別のデータベースも必要となる。更に、理想を言うならば、それら情報を、そのデータベースにアクセスできないコール・センターの係員からも参照できるようにしておかねばならない。また、バウチャーが発行されたときにそのバウチャーの代金を請求するための機構も必要となる。一方、ユーザが新たな搭乗予約のためにバウチャーでの支払充当を行ったならば、その新たな搭乗予約に関する情報として、その支払充当に用いられたバウチャーを示す情報と、充当された金額を示す情報とを記録しておく必要がある。そのためにも、航空会社は、支払充当に用いられたバウチャーと新たな搭乗予約とを関連付けると共に、それに関する情報管理を行うための、また別の独立した機構を保持しなければならない。
【課題を解決するための手段】
【０００７】
本発明の様々な実施の形態は、バウチャーの管理のためのシステム及び方法に関するものであり、それらシステム及び方法によれば、バウチャーの発行及びバウチャーによる支払充当の処理の流れが、航空会社が使用している規格化されたＰＮＲ管理システムに統合される。また、それらシステム及び方法によれば、航空会社は、未使用チケットを回収する際に、返金を行うのではなく、既存のＰＮＲに変更を加えることでそのチケットをバウチャーに変換することができる。また、それらシステム及び方法によれば、航空機利用者から第三者へプレゼントされるギフト券としてのバウチャーを発行することもでき、航空会社が交付する補償金支払用のバウチャーを発行することもできる。
【０００８】
本発明の１つの実施の形態によれば、バウチャーの発行方法が提供され、この方法においては、グローバル・ディストリビューション・システムに複数の現実パッセンジャー・ネーム・レコードを格納し、それら現実パッセンジャー・ネーム・レコードは、その各々が少なくとも識別データと旅程に関するデータとを含んでいる。また、仮想パッセンジャー・ネーム・レコードを生成し、この仮想パッセンジャー・ネーム・レコードは少なくとも識別データと、仮想旅程に関するデータと、額面金額とを含んでいる。仮想パッセンジャー・ネーム・レコードを前記グローバル・ディストリビューション・システムに格納する。費用金額が含まれた旅行計画を受取る。仮想パッセンジャー・ネーム・レコードを現実パッセンジャー・ネーム・レコードに変換する。この変換に際して、前記費用金額の少なくとも一部に対して前記額面金額の少なくとも一部をクレジット処理することを少なくとも行う。そして、変換して得られた現実パッセンジャー・ネーム・レコードを前記グローバル・ディストリビューション・システムに格納する。
【０００９】
以上に記載した実施の形態には様々な特徴を付加することができる。前記額面金額の前記少なくとも一部が前記費用金額の前記少なくとも一部より大きい場合に、変換することを禁止するようにするのもよい。前記グローバル・ディストリビューション・システムから１つの現実パッセンジャー・ネーム・レコードを選択し、この選択した現実パッセンジャー・ネーム・レコードの内容に変更を加えて仮想パッセンジャー・ネーム・レコードとするようにするのもよい。選択した現実パッセンジャー・ネーム・レコードの全体のうち、この選択した現実パッセンジャー・ネーム・レコードの旅程のうちの利用済旅程部分に対応した部分を抹消し、この選択した現実パッセンジャー・ネーム・レコードの旅程のうちの未利用旅程部分に基づいて前記額面金額を設定するようにするのもよい。前記グローバル・ディストリビューション・システムから１つの現実パッセンジャー・ネーム・レコードを選択し、この選択した現実パッセンジャー・ネーム・レコードに含まれる情報に少なくとも部分的に基づいて仮想パッセンジャー・ネームを生成するようにするのもよい。前記額面金額を、ユーザが、ギフト券の金額を表すものとして設定するようにするのもよく、或いはまた、前記額面金額を、航空会社が、補償金の額を表すものとして設定するようにするのもよい。仮想パッセンジャー・ネーム・レコードと現実パッセンジャー・ネーム・レコードとは互いに同一のデータベース・フォーマットを有するようにするのもよい。変換して得られた新パッセンジャー・ネーム・レコードに基づいてチケットを発券するようにするのもよい。
【００１０】
本発明の別の１つの実施の形態によれば、バウチャーの発行方法が提供され、この方法においては、データベース・ネットワークに複数の現実トラベル・レコードを格納し、それら現実トラベル・レコードは、その各々に少なくとも識別データと旅程に関するデータとが関連付けられている。また、仮想トラベル・レコードを生成し、この仮想トラベル・レコードには、少なくとも識別データと、仮想旅程に関するデータと、額面金額とが関連付けられている。仮想トラベル・レコードを前記データベース・ネットワークに格納する。費用金額が含まれた旅行計画を受取る。仮想パッセンジャー・ネーム・レコードを現実トラベル・レコードに変換し、この変換に際して、前記費用金額の少なくとも一部に対して前記額面金額の少なくとも一部をクレジット処理することを少なくとも行う。変換して得られた現実トラベル・レコードを前記共通データベースに格納する。前記仮想トラベル・レコードと前記現実トラベル・レコードとは互いに同一のデータベース・フォーマットを有する。
【００１１】
以上に記載した実施の形態には様々な特徴を付加することができる。前記額面金額の前記少なくとも一部が前記費用金額の前記少なくとも一部より大きい場合に、変換することを禁止するようにするのもよい。前記グローバル・ディストリビューション・システムから１つの現実パーソナル・トラベル・レコードを選択し、この選択した現実パーソナル・トラベル・レコードの内容に変更を加えて仮想パーソナル・トラベル・レコードとするようにするのもよい。変換する際に、選択した現実パーソナル・トラベル・レコードの全体のうち、この選択した現実パーソナル・トラベル・レコードの旅程のうちの利用済旅程部分に対応した部分を抹消し、この選択した現実パーソナル・トラベル・レコードの旅程のうちの未利用旅程部分に基づいて前記額面金額を設定するようにするのもよい。仮想パーソナル・トラベル・レコードを生成する際に、前記グローバル・ディストリビューション・システムから１つの現実パーソナル・トラベル・レコードを選択し、この選択した現実パーソナル・トラベル・レコードに含まれる情報に少なくとも部分的に基づいて仮想パッセンジャー・ネームを生成するようにするのもよい。前記額面金額を、ユーザが、ギフト券の金額を表すものとして設定するようにするのもよく、或いはまた、前記額面金額を、航空会社が、補償金の額を表すものとして設定するようにするのもよい。仮想パーソナル・トラベル・レコードと現実パーソナル・トラベル・レコードとは互いに同一のオンライン・ポータルを介してアクセス可能であるようにするのもよい。変換して得られた新パッセンジャー・ネーム・レコードに基づいてチケットを発券するようにするのもよい。
【００１２】
本発明の更に別の１つの実施の形態によれば、バウチャーの発行方法が提供され、この方法においては、グローバル・ディストリビューション・システムに複数の現実パッセンジャー・ネーム・レコードを格納し、それら現実パッセンジャー・ネーム・レコードは、その各々が少なくとも識別データと旅程に関するデータとを含んでいる。また、仮想パッセンジャー・ネーム・レコードを生成し、この仮想パッセンジャー・ネーム・レコードは少なくとも識別データと、仮想旅程に関するデータと、額面金額とを含んでいる。前記仮想パッセンジャー・ネーム・レコードを、支払充当可能な残高金額を表すレコードであるものと指定する。前記仮想パッセンジャー・ネーム・レコードを、前記グローバル・ディストリビューション・システムに格納する。そして、前記仮想トラベル・レコードと前記現実トラベル・レコードとは互いに同一のデータベース・フォーマットを有する。
【００１３】
以上に記載した実施の形態には様々な特徴を付加することができる。仮想パッセンジャー・ネーム・レコードを生成する際に、前記グローバル・ディストリビューション・システムから１つの現実パッセンジャー・ネーム・レコードを選択し、この選択した現実パッセンジャー・ネーム・レコードに含まれる情報に少なくとも部分的に基づいて仮想パッセンジャー・ネーム・レコードを生成するようにするのもよい。前記額面金額を、ユーザが、ギフト券の金額を表すものとして設定するようにするのもよく、或いはまた、前記額面金額を、航空会社が、補償金の額を表すものとして設定するようにするのもよい。
【００１４】
本発明の更に別の１つの実施の形態によれば、トラベル・バウチャーによる支払充当の処理方法が提供され、この方法においては、グローバル・ディストリビューション・システムから１つの仮想パッセンジャー・ネーム・レコードを読出し、この仮想パッセンジャー・ネーム・レコードは少なくとも識別データと、仮想旅程に関するデータと、額面金額とを含んでいる。また、費用金額が含まれた旅行計画を受取る。また、仮想パッセンジャー・ネーム・レコードを現実パッセンジャー・ネーム・レコードに変換し、この変換に際して、前記費用金額の少なくとも一部に対して前記額面金額の少なくとも一部をクレジット処理することを少なくとも行う。そして、変換して得られた現実パッセンジャー・ネーム・レコードを前記グローバル・ディストリビューション・システムに格納する。
【００１５】
以上に記載した実施の形態には様々な特徴を付加することができる。前記額面金額の前記少なくとも一部が前記費用金額の前記少なくとも一部より大きい場合に、変換することを禁止するようにするのもよい。仮想パッセンジャー・ネーム・レコードを生成する際に、前記グローバル・ディストリビューション・システムから１つの現実パッセンジャー・ネーム・レコードを選択し、この選択した現実パッセンジャー・ネーム・レコードの内容に変更を加えて仮想パッセンジャー・ネーム・レコードとするようにするのもよい。変換する際に、選択した現実パッセンジャー・ネーム・レコードの全体のうち、この選択した現実パッセンジャー・ネーム・レコードの旅程のうちの利用済旅程部分に対応した部分を抹消し、この選択した現実パッセンジャー・ネーム・レコードの旅程のうちの未利用旅程部分に基づいて前記額面金額を設定するようにするのもよい。仮想パッセンジャー・ネーム・レコードを生成する際に、前記グローバル・ディストリビューション・システムから１つの現実パッセンジャー・ネーム・レコードを選択し、この選択した現実パッセンジャー・ネーム・レコードに含まれる情報に少なくとも部分的に基づいて仮想パッセンジャー・ネーム・レコードを生成するようにするのもよい。前記額面金額を、ユーザが、ギフト券の金額を表すものとして設定するようにするのもよく、或いはまた、前記額面金額を、航空会社が、補償金の額を表すものとして設定するようにするのもよい。仮想パッセンジャー・ネーム・レコードと現実パッセンジャー・ネーム・レコードとは互いに同一のデータベース・フォーマットを有するようにするのもよい。変換して得られた新パッセンジャー・ネーム・レコードに基づいてチケットを発券するようにするのもよい。
【００１６】
本発明の更にその他の実施の形態並びに利点については、以下の開示並びに添付図面を詳察することにより明瞭に理解することができる。
【００１７】
以下の詳細な説明では、添付図面を参照しつつ、本発明について更に詳しく説明する。添付図面に示した本発明の様々な実施の形態は、具体例を提示したものであり、本発明はそれら実施の形態のみに限定されない。また添付図面においては、同一ないし対応する構成要素には同一の参照符号を付してある。
【図面の簡単な説明】
【００１８】
【図１】本発明の１つの実施の形態に係る、ギフト券としてのバウチャーや補償金支払用のバウチャーを発行する処理の流れを示したフローチャートである。
【図２】バウチャーによる支払充当の処理の流れを示したフローチャートである。
【図３】未使用チケットをバウチャーに変換する処理の流れを示したフローチャートである。
【発明を実施するための形態】
【００１９】
以下に説明する詳細な構成は具体例を提示するものであり、その目的とするところは、本発明の実施の形態を具体的に詳述することにあり、また、本発明の基本原理並びに概念上の様々な局面を明らかにする上で、最も有用で、しかも理解が容易であると確信される説明を提供することを旨とした。かかる観点から、本発明の構成の細部については、本発明の基本概念を把握する上で必要とされる限度内で説明することとし、その限度を超えた詳細な説明は行わない。ただし当業者であれば、以下の説明を図面と共に参照することによって、本発明をいかなる形態で実施し得るかを明瞭に把握できるはずである。
【００２０】
以下の説明では簡潔を旨として、本発明を航空旅行業務の用途に適用した場合について詳述するが、ただし本発明は、任意の形態の旅行業務システム、及び／または、予約処理システムにも適用可能である。
【００２１】
本発明の１つの実施の形態は、オンライン方式のバウチャー管理システムに関するものであり、このシステムは、旅行代理店、航空会社、並びにオンライン利用ユーザが、バウチャーの発行及びバウチャーによる支払充当を行うための、ユーザ・インターフェースを提供する。また、オンライン・ポータルを介して、ＰＮＲが格納されているＧＤＳにアクセスできるようにしてある。バウチャーの発行は、仮想搭乗旅程とそれに対応したチケット関連データとを含む規格化されたＰＮＲを生成することによって行われる。ユーザがユーザ・インターフェースを介してバウチャーの総額などの必要な情報を設定すると、それらの情報を含むＰＮＲがＧＤＳの中に生成される。こうして生成されたＰＮＲは、規格化された予約処理手順に従ってチケット化され、即ちバウチャーとして発券される。発券された後には、そのバウチャーによる支払充当の処理が、通常のＰＮＲ再発行の処理として管理される。
【００２２】
図１に示したのは、ギフト券またはクレジット処理によりバウチャーを発行する処理の流れであり、図中、参照符号１００はこの処理の全体を指している。ステップＳ１０１では、ユーザが、バウチャーの発行を行うためのウェブ・ページにアクセスする。このアクセスは、標準的なインターネット・ブラウザなどを介して行われ、また、ポータル・サイトを介してアクセスするなどのその他の適宜のネットワーク・アクセス方式でも行われる。ステップＳ１０２では、データを入力するためのフィールドが表示され、このフィールドには、少なくともバウチャーの総額と、バウチャーの発行対象者の識別情報とが入力される。バウチャーの総額は、金額で表すようにしておくことが好ましいが、ただし、マイレージ（航空機の搭乗利用距離に応じて付与されるポイント）などの、航空会社が補償金として交付することのある交換可能ポイントで表すようにしてもよい。その場合のポイント数は、標準航空運賃算出処理によって算出される金額に対応した、またはその金額を反映したポイント数としてもよく、また、手作業で生成されるトランジショナル・ストアド・チケット（ＴＳＴ）の記録に対応した、またはその記録を反映したポイント数としてもよい。バウチャーの発行対象者の識別情報の好ましい具体例は、例えば氏名であるが、その他の形の識別情報としてもよく、例えば社会保障番号、その他のＩＤコード、及び／または、クレジットカード番号などとしてもよい。更にその他の情報を入力することが望まれる場合には、そのような情報を入力するための更なるフィールドを併せて表示するようにするのもよい。
【００２３】
必要なデータが入力されたならば、続いてこのシステムは、ステップＳ１０４において仮想ＰＮＲを生成する。この仮想ＰＮＲは、ＧＤＳに格納されている本来のＰＮＲ（本願開示においてはこれを「現実ＰＮＲ」と称する）と同一のデータ・フォーマットを有するものとすることが好ましく、そうすれば、規格化された予約処理システムによって、また規格化された予約処理手順に従って、現実ＰＮＲの処理及び操作と全く同じように、仮想ＰＮＲの処理及び操作を行うことができる。また、仮想ＰＮＲは、バウチャーの発行対象者の識別情報、バウチャーの作成者のクレジットカード番号、バウチャーの総額、それに航空会社によって予め定められている仮想搭乗旅程を、情報として含んでいるものとすることが好ましい。ここで仮想搭乗旅程とは、実際には存在しない旅行計画に対応した旅程であり、例えば、未来の適当な日付を搭乗予定日とした、適当な二都市間の存在しない航空便をもって、仮想搭乗旅程として定めるようにすればよい。バウチャーには有効期限を設定することができ、このバウチャーの有効期限は、規格化された予約処理手順により、仮想ＰＮＲに含まれている情報のうちの、仮想搭乗旅程を示している部分に反映される。また、チケットのステータス（例えば、払戻可能チケット、乗換え可能チケット、等々）を示すためのデータ・フィールドには、別のチケットないし購入製品の代金やサービスの料金に対して、バウチャーによる支払充当を行う際に、そのバウチャーの全額が充当可能か、それともその一部のみが充当可能かを示すデータが設定される。更に、手数料が加算されるなどして料金が変更された場合には、最初に設定したバウチャーの総額に対して変更が加えられるようにしておくのもよい。
【００２４】
バウチャーの総額を設定するには、規格化された航空運賃算出コマンドを起動して、仮想搭乗旅程に対応した航空運賃を算出させ、その航空運賃の金額を、バウチャーの総額として仮想ＰＮＲに反映させるという方法を用いることができる。これが可能であるのは、航空会社は大抵の場合、搭乗旅程に対応した航空運賃をファイルの形でＧＤＳの中に格納して用意しているからである。また、そのバウチャーの総額を情報として含み、更に、その航空運賃が課税対象である場合にはそれに税額をも情報として含むＴＳＴが、自動的に生成されるようにしておくのもよい。或いはまた、そのようなＴＳＴを手作業で生成することによって、そのバウチャーの総額を反映させるようにしてもよい。
【００２５】
バウチャーの発行のための処理の流れが、最後のステップＳ１０６まで進んできたときには、チケット化（バウチャーの発券）を実行するために必要な全ての情報を含んでいるＰＮＲの生成が完了している。ステップＳ１０６では、そのＰＮＲのチケット化を実行すると共に、バウチャーの作成者のクレジットカードに対する料金請求の処理を行う。ただしその料金請求は、通常は名目的請求金額によって行われる。この時点でバウチャーは、航空会社への将来の支払に充当できる状態となり、また、ユーザは、払戻可能チケットの払戻を受けるときと同様にして、そのバウチャーでの払戻を受けることもできる。
【００２６】
この実施の形態における、バウチャーでの支払充当によってチケットを再発行する処理の流れは、ＰＮＲを利用した再発行処理に従ったものであり、この再発行処理は、航空会社が、発行済チケットでの支払充当によって、予約変更した新たなチケットを発行する際に実行される処理である。図２に示したのは、バウチャーによる支払充当の処理の１つの具体例であり、図中、参照符号２００はこの処理の全体を指している。尚、本発明はこの実施の形態のみに限定されるものではない。バウチャーは、規格化されたＰＮＲとして生成され、ＧＤＳの中に格納されているため、ＰＮＲレコード・ロケータを用いて、ＧＤＳから直接的にＰＮＲを読出すようにすればよい。ステップＳ２０２では、ユーザがＰＮＲレコード・ロケータを用いて、処理対象のバウチャーに対応した仮想ＰＮＲ、及び／または、そのバウチャーに関連したデータを読出す。バウチャーに関連したデータとしては、バウチャー識別コードなどがあり、このバウチャー識別コードは、ユーザごとに固有の、及び／または、バウチャーごとに固有のコードである。ステップＳ２０４では、システムが、新たに発行するチケットの予約内容を調べて、処理対象のバウチャーの総額がそのチケットの価額以下かを判断する。もしバウチャーの総額がそのチケットの価額以下であったならば、ステップＳ２０６において、ユーザに対して、その差額をクレジットカードなどの適当な支払方法で支払うように求めるプロンプトを表示する。
【００２７】
一般的にＰＮＲ管理システムには、支払に充当可能な持高金額を表している支払充当ＰＮＲを、新たに予約された搭乗旅程に対応した新たなＰＮＲに変換するための、変換処理手順が組込まれている。その１つの具体例を挙げるならば、例えば、既に存在している支払充当ＰＮＲ（これは仮想ＰＮＲである）を、新たに発行するチケットに対応した再発行ＰＮＲに変換する処理手順として、その仮想ＰＮＲの該当するデータ・フィールドを書替えるという処理や、その仮想ＰＮＲから新たなる再発行ＰＮＲへデータをインポートすることによって、新たに予約される搭乗旅程を新たなる再発行ＰＮＲに反映させるという処理などが行われており、ただしその他の処理手順が採用されていることもある。本発明の１つの実施の形態は、このようなＰＮＲ変換手順を利用できるようにしたものであって、以上の処理手順と同一の処理手順によって、仮想ＰＮＲによる支払充当処理及び再発行処理を行うようにしている。この実施の形態によれば、バウチャーによる支払充当の処理をＰＮＲ管理システムにシームレスに統合することができる。
【００２８】
即ち、ステップＳ２０８では、処理対象のバウチャーに対応した仮想ＰＮＲを、新たなる再発行ＰＮＲ（これは現実ＰＮＲである）に変換しており、この変換は、ＰＮＲ管理システムがチケットの再発行に際して実行する処理手順に従って行われる。また、ステップＳ２１０では、その仮想ＰＮＲのヒストリカル・レコード（その仮想ＰＮＲの一部として含まれ、または、その仮想ＰＮＲに関連したレコード）を更新して、そのバウチャーによる支払充当が行われたことをヒストリカル・レコードに反映させている。尚、これら２つのステップＳ２０８とステップＳ２１０とは、それらの順序を入れ替えてもよく、或いはそれらを結合して１つのステップにしてもよい。続くステップＳ２１２では、新たに生成した現実ＰＮＲに基づいて新たなチケットを発行する。
【００２９】
バウチャーによる支払充当の処理の別の実施の形態として、当該バウチャーに対応した仮想ＰＮＲを抹消し、新たな搭乗旅程に対応した新たなＰＮＲを生成することによって、新たな予約内容を反映させるような実施の形態とすることも可能である。また、更に別の実施の形態として、既存のＰＮＲシステムに変更を加えて、バウチャーの操作及び処理を独立して行うようなシステムとすることも可能である。
【００３０】
もし、ステップＳ２０４におけるシステムの判断結果が、処理対象のバウチャーの総額が新たな予約内容の価額より大きかったならば、続いてステップＳ２１４において、システムは、そのバウチャーの総額からその差額を減額することによって、新たなバウチャーの総額を算出する。続いてステップＳ２１４では、新たな仮想ＰＮＲを生成する。この新たな仮想ＰＮＲの生成は、以前の仮想ＰＮＲのバウチャーの総額を書替えて新たなバウチャーの総額とすることによっても行うことができ、また、新たなバウチャーの総額が設定された新たな仮想ＰＮＲを生成し、以前の仮想ＰＮＲを抹消することによっても行うことができる。この後、制御の流れは、先に説明したステップＳ２１０へ進む。
【００３１】
更に別の実施の形態として、「額面以上限定方式」で支払充当の処理を行うような実施の形態とすることも可能である。この処理方式は、新たに予約される搭乗旅程のチケットの価額がバウチャーの総額以上である場合に限って、そのバウチャーによる支払充当を認めるというものである。この処理方式を採用した場合には、航空会社は、バウチャーの残金相当額を返金する必要もなく、また、その残金を総額とする新たな仮想ＰＮＲを発行する必要もない。この処理方式を採用した場合の処理の流れは、ステップＳ２１４を除いて図２の処理の流れと同一であり、ステップＳ２１４では、ユーザに対して、新たに予約しようとしている搭乗旅程のチケットの価額がバウチャーの価額に達しておらず不足していることが通知される。この後、処理の流れは、ステップＳ２０２へ戻って、新たなバウチャーの生成を行うようにしてもよく、或いは、サブルーチンを起動して、バウチャー総額に達する追加の予約、及び／または、追加購入を行うという選択肢をユーザに表示するようにしてもよい。この「額面以上限定方式」を採用することによって、航空会社は、余分なコストをかけることなく更なる売上発生源を確保することができる。なぜならば、この方式を採用していなかったときには返金により失われていた売上を、これによって航空会社は手放さずに済むようになるからである。
【００３２】
図３に示したのは、未使用のチケットをバウチャーに変換するために、新たにバウチャーを作成する処理の流れであり、図中、参照符号３００はこの処理の流れの全体を指している。ステップＳ３０２では、ユーザが、標準的なブラウザを介して、ＧＤＳに格納されている未使用のチケットに対応したＰＮＲにアクセスする。続くステップＳ３０４では、アクセスしたそのＰＮＲの搭乗旅程のうちに未搭乗部分（未利用旅程部分）が含まれていたならば、そのＰＮＲからその未搭乗部分を抹消して、搭乗済部分（利用済旅程部分）だけを維持する。続くステップＳ３０６では、仮想搭乗旅程に対応した仮想ＰＮＲを生成する。この仮想ＰＮＲの生成は、アクセスした現実ＰＮＲのデータを書替えることによって行うようにしてもよく、また、新たな仮想ＰＮＲを生成して、アクセスした現実ＰＮＲを抹消することによって行うようにしてもよい（新たな仮想ＰＮＲを生成するには、それを全く新たに生成するようにしてもよく、また、アクセスした現実ＰＮＲからデータをインポートして生成するようにしてもよい）。新たに生成する仮想ＰＮＲにおけるバウチャーの総額は、払戻される金額を表しており、その金額は、搭乗済部分の有無に応じて、アクセスした現実ＰＮＲの価額の全額であることもあれば、その一部に相当する金額であることもある。また、保持されていた税額に関する情報は全て、バウチャーに引き継ぐことが好ましく、そうすれば、そのバウチャーによる支払充当の処理として、再発行の処理を実行する際に、税額に関する計上がなされる。また、そのバウチャーによる支払充当の処理は、図２を参照して上で説明した処理手順に従って行うことができる。
【００３３】
以上に説明した様々な実施の形態は、従来のバウチャー管理システムと比較したとき、数多くの利点を提供するものである。航空会社は、ＰＮＲの管理並びにチケットの発行及び再発行の処理を行うための規格化された機構や、請求処理、情報管理のためのバックエンド・システムなどを備えている。以上に説明した様々な実施の形態は、そのような規格化された機構やバックエンド・システムを利用するものであるため、バウチャーの発行並びに経理処理を行うためのシステムを併設して維持する必要がなく、従ってそのための費用が不要である。また、ＧＤＳに仮想ＰＮＲを格納するようにしているため、航空会社は、バウチャーに関する記録を格納及び保持するための余分なコストを必要としない。更に、ＰＮＲのフォーマットを利用し、またＰＮＲの再発行のための処理手順を利用して、バウチャーに関する処理を実行するようにしているため、バウチャーに関する処理を独立したシステムによって実行する必要がなく、ひいては、そのようなシステムを運用するために係員を訓練する必要もない。そして、バウチャーに関する処理は、情報管理及び経理処理のための既存のシステムを用いて実行することができる。
【００３４】
更に、本発明に係るバウチャー管理システムによれば、航空会社は、自社が使用しているオンライン販売チャネルによって、バウチャーの発行及びバウチャーによる支払充当の処理を行うことができる。従って、搭乗予約処理のためのシステムなどを使用して、バウチャーの発行及びバウチャーによる支払充当の処理を行うことができる。
【００３５】
本発明に係るバウチャー管理システムは、適宜の設計とすることによって、オンライン方式の予約変更エンジンとしても機能するシステムとすることができる。例えば、バウチャーの発行の処理、及び／または、バウチャーによる支払充当の処理の流れを、航空会社だけが見ることができるようにして、エンド・ユーザに対しては隠すようにすれば、それによって、搭乗旅程を変更するための予約変更機構として機能し得るものとなる。
【００３６】
以上に説明した処理方式は、公知のプログラミング技法を用いて、ソフトウェアとして実現することができ、そうすることによって、ハードウェア及びソフトウェアで構成されたＰＮＲを利用する既存のネットワークに、この処理方式を容易に組込むことができる。
【００３７】
以上に提示した様々な具体例は、本発明を説明するためのものであって、本発明がそれら具体例に限定されると解釈すべきものではない。また、以上の説明では、本発明を具体的な実施の形態に即して詳述したが、以上の説明で使用した様々な用語は、あくまでも具体例を提示するためのものであって、本発明を限定するための用語ではない。出願当初の特許請求の範囲ないしは補正後の特許請求の範囲に記された権利範囲内において、本発明の範疇及び概念から逸脱することなく、本発明の様々な局面に関して、様々な変更を加えることが可能である。また、以上の本発明の説明においては、具体的な手段、材料、及び実施の形態に即して詳述したが、本発明は以上に開示した具体的な構成を有するものだけに限定されず、本発明は、以上に開示したものと機能的に同等のあらゆる構成、方法、ないしは用途を包含するものであって、それらは特許請求の範囲に記された権利範囲に含まれるものである。
【００３８】
その具体例として、例えば、図面に示し本明細書において詳述した方法ステップの順序は、あくまでも具体例を提示することを目的としたものである。当業者の技量をもってするならば、それら方法ステップの順序を変更し、ないしは、それら方法ステップに更に別の方法ステップを付加し、ないしは、それら方法ステップのうちのあるものを除去することによって、特許請求の範囲に記された様々な方法を実現することが可能である。
【００３９】
航空会社がＰＮＲを利用するために用いているアクセス手段には様々なものがあるが、そのようなアクセス手段のいずれを用いてもバウチャーにアクセスすることができるようにすると好都合である。例えば、バウチャーの発行元の航空会社が、通常業務においてインターネットを使用しているのであれば、インターネットを介してバウチャーにアクセスできるようにしておくと好都合であり、また、通常業務において何らかのネットワークを使用しているのであれば、そのネットワークを介してバウチャーにアクセスできるようにしておくと好都合である。また、航空機の利用者、旅行代理店、それにバウチャーの発行元以外のその他の航空会社も、インターネット、イントラネット、それに専用のシステムなどを介して、バウチャーにアクセスできるようにしておくとよい。本発明は、バウチャーにアクセスするためのシステムとして、特定のシステムを用いるものに限定されない。
【００４０】
以上の説明においてユーザとは、それが航空会社であるか、旅行代理店であるか、個人ユーザであるかにかかわらず、システムを利用する権限を有するあらゆる主体を意味している。また、そのユーザは、例えば顧客に代わって予約を取る旅行代理店や、ギフト券の購入代行業者などの、代理者または代行者であることもある。また、ＰＮＲには、例えばギフト券の受領者や旅行者などのような、バウチャーによる支払充当を行う者の型どおりの情報（例えば氏名など）を含むようにすることが好ましいが、代理者の識別情報を含むようにしてもよい。
【００４１】
以上に説明した様々な実施の形態は、本発明を「典型的な」用途に適用した場合を示したものであり、ここでいう「典型的な」用途とは、航空会社及びその他のユーザが、料金請求処理、及び／または、予約処理のために使用している様々なシステム、アプリケーション、またはそれらの一部分を意味している。ただしそれは、現在使用されている特定のアプリケーションないしシステムを意味するものではなく、現在使用されており、または過去において使用されたことがあり、または将来使用されることになる、ありとあらゆるその種のアプリケーションないしシステムを意味するものである。それゆえ本発明は、例えば、現在使用されているものであるか、将来使用されることになるものであるかを問わず、いかなる特定のＰＮＲ再発行処理方式にも限定されるものではない。
【００４２】
以上の説明では、様々な種類のデータ項目に言及し、また、それらデータ項目を格納する様々な格納場所にも言及したが、本発明は、それらデータ項目を使用するものだけに限定されず、また、それら格納場所にデータ項目を格納するものだけに限定されない。ただし、ある種のＰＮＲ構造においては、リジディティよりも、航空会社が使用している料金請求処理並びに情報管理処理のためのシステムに対してシームレスなコンパチビリティを備えることの方が優先される。それゆえ、例えば航空会社が使用しているシステムが、料金、費用、額面金額などのデータ項目を、ＰＮＲそれ自体の中に格納するのではなく、ＰＮＲに関連した何らかのファイル（例えばＴＳＴなどのチケット情報ファイルなど）の中に格納するようにしているのであれば、バウチャーの額面金額も、同様に、仮想ＰＮＲに関連したその種のファイルの中に保持するようにするのがよい。ただし、本発明はそのようにしたものだけに限定されるものではない。
【図１】
2010500680.tif 000003
【図２】
2010500680.tif 000004
【図３】
2010500680.tif 000005
【国際調査報告】
2010500680.tif 000006
2010500680.tif 000007