JPH06506074A - グループ旅行関連サービスの管理監視方法と装置 - Google Patents

Abstract

(57)【要約】本公報は電子出願前の出願データであるため要約のデータは記録されません。

Description

【発明の詳細な説明】 グループ旅行関連サービスの管理監視方法と装置。

本発明は、グループ情報によってマスター目録（ｉｎｖｅｎｔｏｒｙ）データと 顧客詳細情報の両方を相互索引し更新することができ、マスター目録又は顧客詳 細情報に対して行われるアクションによりグループ情報を更新することができる 、グループ旅行関連サービスに関するデータ処理方法と装置に関する。

今日の旅行環境においては、旅行者はグループ旅行の利点について意識を高めて きている。その結果、例えばグループのための交通、宿泊及び行動の予定設定や 予約等のグループの取扱い需要が増加している。

現在のところ、グループ旅行の設定・手配は、特定のグループ旅行サービスの記 録を手作業で維持するグループ卸売業者によって行われている。更に、例えば航 空会社等のホスト提供者側が、旅客氏名レコードのブロック化のサービスを提供 する場合がある。プロ・ツク化された旅客氏名レコードは、限られた数の卸売業 者に提供される。あるブロック内の一名の旅客氏名レコードがキャンセルされる と、そのレコードが表すスペースはブロック自体が既にキャンセルされていない 限り、そのブロックに戻され、スペースはマスター目録（マスター在庫目録：　 ｍａｓｔｅｒ　１ｎｖｅｎｔｏｒｙ）に戻る。

しかしながら、この種のブロック化された旅客氏名レコードは、旅行区分の併合 がホスト提供者側によって行われる必要があるため、取扱い時には卸売業者には リリースされない。従って卸売業者は、特定の旅客がどの旅行区分を希望してい るかをホスト提供者側に通知する以外は、この種のブロック化旅客氏名レコード については管理が殆どできないか又は全くできない。

更に、このため、あるグループ旅行の提供内容を構成するいくつかの旅行区分の 各々が、別個のブロック化された旅客氏名レコードに記憶されなければならない 。

これらの予めブロック化された旅客氏名レコードをホスト提供側が管理しなけれ ばならないため、グループ旅行関連の卸売業者に提供される柔軟性が大きく制限 されていた。

従って、グループ用のマスター目録と顧客詳細情報の両方にアクセスし、更新で きる手段を有している、グループ旅行関連サービスを取り扱うための柔軟性のあ るシステムが望まれる。

本発明は、上記の従来技術における欠点を避け、旅行関連各種サービスの卸売業 者及び小売業者がもつと容易にグループを追跡できるようにするものである。

本発明は、　「グループ管理レコードＪ　（Ｇｒｏｕｐ　ＣｏｎｔｒｏｌＲｅｃ ｏｒｄ：　ＧＣＲ）と呼ばれるひとつのレコード内の特定グループに関する全て の関連サービス目録情報を、ユーザーが収納できるブロック・サービス目録アプ リケーションを提供する。グループ・ブロック化された目録と関連情報は、グル ープ管理レコードに保存され、これに対し、グループ管理レコードによって参照 されるグループ関連「旅客氏名レコードＪ　（Ｐａｓｓｅｎｇｅｒ　ＮａｍｅＲ ｅｃｏｒｄ：　ＰＮＲ）は、個別の旅客の旅行日程及び情報用に使用される。本 発明によれば、卸売業者は、ホスト提供者側のサービス目録を−グループのグル ープ管理レコードにブロック化し、小売業者は、グループ管理レコードからの在 庫サービスを、各旅客用のグループ関連旅客氏名レコードに「販売」する。本発 明は、ホスト目録、グループ管理レコード及びグループ関連旅客氏名レコードの いずれかに変更が行われたとき、これらの要素の間の関係を維持する。

より具体的には、本発明を使用するとき、グループ関連サービスの卸売業者は、 グループ旅行を構成するに必要な全ての旅行区分のグループ・サービス目録を含 むグループ管理レコードを作成する。在庫グループ・サービスが販売されると、 グループ関連旅客氏名レコードが作成され、グループ管理レコード内に索引付け される。作成された各グループ関連旅客氏名レコードには、どのグループ管理レ コードからあるサービス内容を得たのかについての参照情報が含まれている。

これによって、マスター目録の変更は、関連グループ管理レコードにあるグルー プ・サービスの内容に自動的に反映され、影響を受けたグループ管理レコードの グループ関連旅客氏名レコードに自動的に反映させることができる。更に、グル ープ関連旅客氏名レコードが取り消されると、そのサービス商品は、関連グルー プ管理レコードのグループ・サービス目録に戻る。

ある指定期間の満了と同時に未使用のサービス商品をマスター目録に返還するた めのグループ最終日を設定することもできる。

本発明においては、グループ関連サービスに関連する空のデータ・フィールドを 含む［グループ作業レコードＪ　（Ｇｒｏｕｐ　Ｗｏｒｋ　Ｒｅｃｏｒｄ：　Ｇ ＷＲ）を使用することにより、旅行関連サービスの卸売業者によるグループ管理 レコードの作成が容易となる。卸売業者がグループ作業レコードを特定のグルー プサービス商品に関するデータで埋めた後、またデータをチェックした後、グル ープ作業レコードのデータ・フィールドは、グループ管理レコードの対応データ ・フィールドに保存される。

グループ管理レコードのデータ・フィールドへのこれ以上のアクセスは、その特 定の卸売業者のみに制限することができる。卸売業者と関係のあるその他の代理 店は、グループ管理レコードから目録を販売することができるが、グループ管理 レコードへのその他の変更はできない。

好適実施例についての以下の詳細説明と添付図面を参照することにより、本発明 の上記及びその他の特長と機能をより完全に理解することができる。

図１は、本発明によるハードウェア・システムの基本図である。

図２は、図３ａ−Ｃのステップのプロセス間のデータ／プロセス関係のブロック 図である。

図３ａ、３ｂ、３ｃは、本発明の総合動作を示すフローチャートである。

図４ａ、４ｂは、図３ａの開始グループ・プロセス・ステップをより詳細に示す フローチャートである。

図５は、図３ａのＧＷＲステップの目録調整をより詳細に示すフローチャートで ある。

図６は、図３ａのＧＷＲステップの非目録データ追加をより詳細に示すフローチ ャートである。

図７は、図３ａのＧＣＲステップとしての保存をより詳細に示すフローチャート である。

図８ａ、８ｂ、８ｃは、図７のＧＣＲ作成ステップをより詳細に示すフローチャ ートである。

図９は、図３ｂのアクセス可能なＧＣＲ目録ステップをより詳細に示すフローチ ャートである。

図１０は、図３ｂのＡＡＡステップにおける調整ＧＣＲ目録をより詳細に示すフ ローチャートである。

図１１は、図３ｂのＰＮＲ保存ステップをより詳細に示すフローチャートである 。

図１２は、図１１のＰＮＲ作成ステップをより詳細に示すフローチャートである 。

図１３は、図３０のマスター目録変更ステップをより詳細に示すフローチャート である。

図１４は、図３０の顧客目録／非目録変更ステップをより詳細に示すフローチャ ートである。

図１５ａ、１５ｂは、図１４のＰＮＲ保存ステップをより詳細に示すフローチャ ートである。

図１５　ｃ、１５　ｄ、１５　ｅは、図１５ｂのＧＣＲ更新及び保存ステップを より詳細に示すフローチャートである。

図１６は、図３０のグループ目録／非目録変更ステップをより詳細に示すフロー チャートである。

図１７　ａ、１７　ｂ、１７　ｃは、図１６のＧＣＲ保存ステップをより詳細に 示すフローチャートである。

図１８は、図３０のグループ追跡ステップをより詳細に示すフローチャートであ る。

図１９は、図１８のＧＣＲプロセス・ステップをより詳細に示すフローチャート である。

図２０は、図３０のレコード待機ステップをより詳細に示すフローチャートであ る。

図２１ａ、２１ｂ、２１ｃは、図３０のレコード維持ステップをより詳細に示す フローチャートである。

Ｋ−淀１ ＡＡＡ　：エージェント・アセンブリー・エリア。このレコードは、ＰＮＲの作 成と更新を含む、予約システムについてのエージェント活動を容易にするために ＡＡＡにパック解除される。本発明では、新しいフィールドは、ＡＡＡに加えら れる。ＧＷＲへの参照情報が、ＡＡＡに加えられ、エージェントが本発明のグル ープ関連サービスの使用を許可されたときは、フラッグが設定される。

エージェント；システムの全てのオペレータ。

ＤＸＡ＋据置取消しエリア（Ｄｅｆｅｒｒｅｄ　ＣａｎｃｅｌｌａｔｉｏｎＡｒ ｅａ）。ＤＸＡは、ＡＡＡに関連するレコードであり、ＡＡＡに含まれるＰＮＲ の更新された目録及び氏名データを含んでいる。この目録及び氏名データは、Ｐ ＮＲ取引が完了したとき、マスター目録とＰＮＲ履歴を維持するため使用される 。

ＧＣＲニゲループ管理レコード（Ｇｒｏｕｐ　Ｃｏｎｔｒｏｌ　Ｒｅｃｏｒｄ） 。ＧＣＲは、典型的に以下の情報フィールドを含ＧＩＤ　ＧＣＲの所有権　ＧＣ Ｒ所有者の卸売業者ＩＤＮ：　グループ名称　ＧＣＲのタイトルＲ：　受領済み 　ＧＣＲ作成者からの受領Ｗ−ａｄｄｒ　卸売業者　卸売業者アドレスアドレス Ｄ−ａｄｄｒ　納入アドレス　ＧＣＲエージェントの納入アドレス Ｌ：　レコード・　他の航空会社レコード・ロケロケータ　−タ Ｐ：　電話フィールドＧＣＲエージェントの電話番号・：３　５ＳＲ−特別　標 準ＳＳＲ規約に従うサービス依頼 ０　（在庫）目録情報マスター目録から得た目録項目 ＦＩＮＡＬ　目録最終返還日　未使用サービス在庫を提供者に返さなければなら ない目録 項目に含まれる日付 ＧＲＰＴ　目録り゛ルーフ°追跡現行在庫レベルの把握が望ま（へ°ｔルテ（− ）日　れる目録項目に含まれる日付ＱＭＤＲ待機管理　ＧＣＲを待機させるべき 日付ＯＣＲ履歴（ＧＣＲＨｉｓｔｏｒｙ）　：　Ｇ　ＣＲ情報に対して行われた 改変に関する監査後続情報を含むＧＣＲから引用されたレコード。

Ｇ　ＲＩ　Ｄ　（Ｇｒｏｕｐ　Ｄｅｔａｉｌ　Ｉｎｄｅｘ　Ｒｅｃｏｒｄ）　ニ ゲループ詳細索引レコード。ＧＲＩＤはホスト提供者のフライト及び日付により 関連付けられるＧＣＲへの参照情報を含んでいる。

Ｇ　ＲＩ　Ｘ　（Ｇｒｏｕｐ　Ｃｏｎｔｒｏｌ　（ｏｗｎｅｒ　５ｐｅｃｉｆｉ ｃ）　ＩｎｄｅｘＲｅｃｏｒｄ）　ニゲループ管理（オーナー特有）索引レコー ド。

ＧＲＩＸは、卸売業者が所有する全てのＧＣＲへの参照情報を含んでいる。

グループ・オペレータ：　ＧＣＲにより反映されるグループ旅行サービス商品の 所有者及び組織者で、例えば代理店、卸売業者又は航空会社。

ＧＲＰＴ／Ｆ　Ｉ　ＮＡＬ索引レコード：　ＧＣＲ目録項目に含まれる特定日付 について行動を必要とするＧＣＲへの参照情報を含む。

Ｇ　Ｗ　Ｒ（Ｇｒｏｕｐ　Ｗｏｒｋ　Ｒｅｃｏｒｄ）　ニゲループ作業レコード 。

ＧＷＲは、ＧＣＲと対照的な固定場所におけるＧＣＲと同じフィールドで、可変 場所におけるデータを保持するものを含む暫定レコードである。

Ｇ　Ｘ　Ａ　（Ｇｒｏｕｐ　Ｄｅｆｅｒｒｅｄ　Ｃａｎｃｅｌｌａｔｉｏｎ　Ａ ｒｅａ）　ニゲループ据置取消しエリア。ＧＸＡは、ＧＷＲに関連するレコード であり、ＧＷＲに含まれるＧＣＲの更新された目録及び氏名データを含んでいる 。この目録及び氏名データは、ＧＣＲ取引が完了したとき、ＧＣＲ目録とＧＣＲ 履歴を維持するため使用する。

ホスト提供者：マスター目録の保持者。

Ｐ　Ｎ　Ｉ　Ｄ　（Ｐａｓｓｅｎｇｅｒ　Ｎａ１ｖｅ　Ｉｎｄｅｘ　Ｄｅｔａｉ ｌ　Ｒｅｃｏｒｄ）　：旅客氏名索引詳細レコード。ＰＮＩＤは、ホスト提供者 フライト及び日付により関連付けられるＰＮＲへの参照情報を含んでいる。本発 明では、ＰＮＩＤは、このホスト提供者フライト及び日付に関連するＧＣＲ用の ＧＲＩＤへの参照情報を含んでいる。

Ｐ　Ｎ　Ｒ（Ｐａｓｓｅｎｇｅｒ　Ｎａｍｅ　Ｒｅｃｏｒｄ）　：旅客氏名レコ ード。

ＰＮＲは、典型的に以下の業界標準情報を含むがこれらに限定されない。すなわ ち、旅客氏名、エージェント名称、切符発行情報、電話番号フィールド及び在庫 目録情報である。更に、本発明で使用されるＰＮＲには、あるサービス商品がど のＧＣＲから得たちのがを明らかにする参照情報が含まれている。

Ｑ　ＣＲ（Ｑｕｅｕｅ　Ｃｏｎｔｒｏｌ　Ｒｅｃｏｒｄ）　：待機管理レコード 。

ＱＣＲによって特定卸売業者に対するＧＣＲの待機が可能になる。

待機プロンプト索引レコード（Ｑｕｅｕｅ　Ｐｒｏｍｐｔ　ＩｎｄｅｘＲｅｃｏ ｒｄ）　：　Ｇ　ＣＲのＱＭＤＲフィールドに含まれる特定日付について、待機 行列に置かれるＧＣＲへの参照情報を含んでいる。

サブＰＮＲ索引（ｓｕｂ−ＰＮＲ１ｎｄｅｘ）　：このレコードは、特定のＯＣ Ｒ目録から得られたサービス商品を含む各サブＰＮＲに対する参照情報を含んで いる。

サブＰＮＲ又は、グループ関連Ｐ　Ｎ　Ｒ（ｓｕｂ−ＰＮＲｏｒＧｒｏｕｐ　Ｒ ｅ１ａｔｅｄ　ＰＮＲ）：Ｇ　ＣＲから入手されたサービス商品を含んだＰ　Ｎ 　Ｒｏ Ｗ　Ｉ　Ｔ　（Ｗｈｏｌｅｓａｌｅｒ　Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ　Ｔａｂ ｌｅ）　：卸売業省議別表。ＷＩＴは、本発明内で機能することが認められてい る特定卸売業者（グループ・オペレータ）擬似都市への参照情報を含んでいる。

ＷＩＴは、卸売業者用に関して、ＧＲＩＸレコードも参照する。

影−１１ 図１を参照すると、本発明のグループ旅行関連サービス監視システムが開示され ている。一般にシステムには、旅行代理店等に典型的に設置され、遠隔予約シス テム・コンピュータ１０４にアクセスするよう接続される複数のコンピュータ端 末１００，１０１が含まれる。記憶装置１０７，１０８．　１０９に接続される 遠隔コンピュータ１０４は、旅行サービス、例えば飛行機、列車及び船舶のスケ ジュール等の交通サービス、宿泊設備、レンタカー、等々の目録を維持している 。

以上に列挙したちの以外の旅行関連サービスの目録も、本発明の範囲を逸脱する ことなく遠隔コンピュータ１０４によって維持できることに注意すべきである。

好適実施例においては、遠隔コンピュータ１０４は、コピア・パートナ−シップ 社（Ｃｏｖｉａ　Ｐａｒｔｎｅｒｓｈｉｐ）により保守・運用されているアポ口 ・コンピュータ式予約システムである。

遠隔コンピュータ１０４は、例えば市販のコンピュータのいずれかでも良いし、 又は、例えばＩＢＭモデル３０９０−４００Ｊ、３０９０−４００Ｅ、９１９０ −２００又は９０８１−に３２等のコンピュータの集まりとしても良い。記憶ユ ニット１０７，１０８゜１０９は、望ましいとされる高密度磁気ディスク記憶ユ ニットであるが、その他の型式の記憶装置、例えば光学ディスク、テープ又は半 導体メモリーを使用することができる。記憶ユニット１０７は、例えば利用可能 なフライトのマスター目録を記憶するために使用する。記憶ユニット１０８は、 本発明では、ＯＣＲとして定義される中間目録を記憶するために使用される。

記憶ユニット１０９は、ＰＮＲ及び関連索引を含む顧客詳細情報を記憶するため に使用される。

記憶ユニット１０７，１０８．　１０９は、個別ユニットとして示されているが 、これは図解目的のためだけであり、記憶ユニット１０７．　１０８．　１０９ に記憶される情報は、実際、単独ユニットの異なったエリアに維持されるか、又 はいくつかの物理的に異なる記憶ユニットに維持することができるものと理解す べきである。記憶ユニット１０７．　１０８．　１０９は、例えば、ＩＢＭモデ ル３３８ｏユニットを利用することができる。

遠隔コンピュータ１０４は、通信チャンネル、例えばモデム１０２と電話回線１ ０３とモデム１０６を通じて、コンピュータ端末１００，１０１に通信する。

電話通信以外の通信チャンネル、例えばラジオ、マイクロウェーブ、衛星又は光 学リンクを本発明から逸脱することなく使用できる。更に、一つのローカル・ネ ットワーク（コンピュータ１００，１０１、モデム１０２及び記憶ユニット１１ １）だけしか図示していないが、どのような数のローカル・ネットワークでも遠 隔コンピュータ１０４による各通信に使用できることが理解される。

コンピュタ一端末１００，１０１は、どのような型式のコンピュータでもよい。

例えばコンピュータ１００は、Ｉｎｃｏｔｅｒｍモデル１５０１又は１５０３等 のノンプログラマブル・コンピュータ、又は、いわゆる「ダム・ターミナル（ｄ ｕｍｂ　ｔｅｒｍｉｎａｌ）Ｊとすることができる。

一方、コンピュータ１０１は、例えばマイクロ・チャンネル・アーキテクチャを 持つＩＢＭモデルＰＳ／２５０、　６０．　６５．　７０又は８０等の完全なプ ログラマブル・コンピュータとすることができる。記憶ユニット１０７．　１０ ８．　１０９に類似の記憶ユニット１１１は、磁気ディスク記憶ユニットが望ま しいが、他の型式のデータ記憶装置でもよい。記憶ユニット１１１は、ＧＣＲに 含んでいる中間目録を記憶するために使用するが、以下に詳細説明するように、 本発明を実施するために、コンピュータ１０１と組み合わせて使用される。

ここで図２を参照すると、本発明に係るデータの相互作用及びデータに影響する プロセスの概念図が示されている。一般に、三種類の情報、即ちマスター目録デ ータ２００、グループ管理情報２０１及び顧客詳細情報２０２が、個別に記憶維 持されている。

点線の円２０３内に含まれるプロセス要素は、マスター目録データ２００．　グ ループ管理情報２０１（ＧＣＲを含む）及び顧客詳細情報２０２　（ＰＮＲを含 む）を含む全てのグループ情報を、更新又はアクセスするプロセスである。点線 の円２０３内のプロセスに含まれているのは、マスター目録変更１０（図１３を 参照して詳細に説明する）、顧客目録／非目録変更１１（図　１４．１５　ａ　 −ｅを参照して詳細に説明する）、及びグループ目録／非目録変更１２（図１６ ．１７ａ〜Ｃを参照して詳細に説明する）である。一方、点線の円２０４に含ま れるプロセス要素は、グループ管理情報２０１と顧客詳細情報２０２だけに影響 する。点線の円２０４内のプロセスに含まれるのは、レコード待機１４（図２０ を参照して詳細に説明する）及びレコード保守１５（図２１　ａ　−ｃを参照し て詳細に説明する）である。同様にグループ追跡１３（図１８．１９を参照して 詳細に説明する）は、グループ管理情報２０１及びマスター目録データ２００だ けに影響する。

マスター目録データ２００１　グループ管理情報２゜１及び顧客詳細情報２０２ を接続するデータ・フローの線は、全てのグループ情報（項目２００，２０１゜ ２０２）が他のグループ情報への変更によって影響される場合があることを示し ている。更に、本発明によれば全てのグループ情報は、他のグループ情報を参照 する事実も示されている。

ここで図３　ａ　−ｃを参照すると、本発明の作動がフローチャート形式で示さ れている。図３　ａ　−ｃのフローチャートに開示され、以降の図によって、よ り詳細に説明される機能を具体化するコンピュータ・プログラムは、本発明を達 成するよう図１に示すコンピュータに書き込み、ローディングできる。注意すべ きことは、遠隔コンピュータ１０４をノン・プログラマブル・コンピュータ１０ ０と組み合わせて使用する場合は、本発明のプロセスを具体化するコンピュータ ・プログラムは、遠隔コンピュータ１０４内に存置されることである。然しなか ら、遠隔コンピュータ１０４をプログラマブル・コンピュータ１０１と組み合わ せて使用する場合は、本発明のプロセスを具体化するコンピュータ・プログラム は、本発明から逸脱せずに、コンピュータ１０１又はコンピュータ１０４内に存 置でき、或はプログラムをコンピュータ１０１とコンピュータ１０４の間で共有 できる。

図３ａを参照すると、ＧＣＲを作成するために使用されるプロセスが図示されて いる。ステップ１では、「エージェント」　（オペレータ、販売員等）が一つの セツションを開始する。目録及び非目録データは、ステップ２及び３で、エージ ェントによりＧＷＲに加えられる。ＧＣＲは、必要データがステップ４でＧＷＲ に加えられれば、エージェントにより保存され、グループ・セツションは、ステ ップ５で終了する。

図３ａのグループ開始プロセス・ステップ１を、図４ａ、４ｂによって、より詳 細に説明する。図４ａを参照すると、ステップ１．１でエージェントは、キーボ ードなどを通じて、機能的エントリにより、グループ・オペレータに関するデー タを入力する。このデータには、都市情報、グループ・オペレータ識別情報及び 請求書発行情報が含まれる。ステップ１．２，１．３では、グループ・オペレー タに関するデータは、データベース索引レコードに配置される。これらの索引レ コードは、ＷＩＴ及びＱＣＲを含んでいる。グループ・オペレータ識別情報がＷ ＩＴレコードに加えられ、そのグループ・オペレータのＱＣＲが初期化される。

その他のプロセスにおいては、これらの索引は、グループ・オペレータ許可、待 機機能性、及びＧＣＲアクセスを規定する。図４ｂでは、グループ・セツション の確立が達成される。具体的には、ステップ１．４においてエージェントは、グ ループ・セツションを確立する試みとして機能的エントリを入力する。この行為 によって、ステップ１．５におけるこのエージェントの許可を確認するデータベ ースへのアクセスが生ずる。この許可は、データベース内のグループ・オペレー タ識別情報をサーチすることによって達成される。グループ・セツション許可は 、ステップ１．１〜１．３（図４ａ）で既に行われているデータベース更新結果 に応じて、拒否され或は認められる。グループ・セツションが拒否された場合は 、エージェントはステップ１．６で通知される。グループ・セツションがうまく 確立した場合は、エージェントはステップ１．７でＧＷＲを入手する。

再び図３ａを参照すると、ＧＷＲの目録調整（ステップ２）が図５によって、よ り詳細に説明されている。

図５を参照すると、ステップ２．１でエージェントは、例えば、都市ペアと日付 を入力情報として供給して、する。ステップ２．２，２．３で目録の取得が要求 されると、その商品目録は、マスター目録から外され、ＧＷＲに置かれる。一方 、ステップ２．２，２．３で商品目録を返還する要求が入力されると、商品目録 は、ＧＷＲから外され、再びマスター目録に設置される。エージェントは、ステ ップ２．４において、商品目録がうまく取得又は返還されたことを通知される。

ステップ３（非目録データをＧＷＲに加える）を、図６によって、より詳細に説 明する。図６を参照すると、ステップ３．１でエージェントは、入力要求におい て非目録関連情報を供給する。そのような非目録関連情報の例として含まれるも のには、例えばグループ・タイトル、電話番号、備考、納入先住所、グループ追 跡日付（ＧＲＰＴ）、最終日付（Ｆ　Ｉ　ＮＡＬ）及び待機（ＱＭＤＲ）情報が ある。

入力要求の処理時にフォーマット作成及び編集がうまくいった後、データはステ ップ３．２でＧＷＲに入れられる。ステップ３．３で、エージェントは、非目録 関連情報のＧＷＲへの追加がうまく行ったことを通知される。

再び図３ａを参照すると、ステップ４（ＧＣＲとして保存する）が図７を参照し てより詳細に説明されている。図７を参照すると、ステップ４．１でエージェン トは、ＧＣＲトランザクションを完了させるため、エントリを供給する。ステッ プ４．２で、現行トランザクション中に入力されたＧＷＲデータの内容が適切か 否かが確認され、検証される。次いで、ステップ４．３でＧＷＲデータは、ＧＣ Ｒを作成するため転送される。

図７のＧＣＲ作成ステップ４．３は、図８ａ、８ｂ、８Ｃによって、より詳細に 説明されている。

図８ａを参照すると、ステップ４．３．１，４．３．２において、ＧＷＲの情報 のＧＣＲへの転送は、最初の目録項目から始めて順次に行われる。各目録項目が ＧＣＲに移動すると、サブＰＮＲ索引が作成さ枳　目録項目に保存される（ステ ップ４．３．３　）。目録項目もステップ４．３．４で請求書発行レコードに記 録される。

目録項目がＧＣＲに転送されると、個別の目録項目内にグループ追跡又は最終日 付（ＧＲＰＴ又はＦＩＮＡＬ）が存在するか否かの照会がされる。グループ追跡 ／最終日付がステップ４．３．５によって決定されて、存在する場合、ステップ ４．３．６で適切なＧＲＰＴ／Ｆ　Ｉ　ＮＡＬ索引レコードにＧＣＲが置かれる 。追加の目録項目がＧＷＲ内に存在する場合には、制御は、ステップ４．３．７ によって、ステップ４．３１に再転送される。

目録項目のＧＷＲからＧＣＲへの転送の完了によって、非目録項目のＧＷＲから ＧＣＲへの転送が開始される。ステップ４．３．８，４．３．９で、各非目録項 目は、順次転送される。ステップ４．３．１０によって決定されるように、待機 プロンプト項目に遭遇すると、ステップ４．３．１１において、ＧＣＲは、適切 な待機プロンプト索引レコードに含められる。ステップ４．３１２により決定さ れるように、非目録項目がこのＧＷＲ内にさらに存在する場合、制御は、ステッ プ４．３゜８に戻され、このプロセスが繰り返される。ステップ４．３．１３で は、ＧＣＲがファイルされて、その作成を完了する。

ステップ４．３．１４において、適切なグループ詳細索引レコード（ＧＲＩ　Ｄ ）を作成又は位置確認するために必要なデータについて、ＧＷＲ内の目録項目が 再び照会される。ＧＲＩＤが作成される場合は、ＧＲＩＤに対する参照情報が適 切な旅客氏名索引詳細レコード（ＰＮ　Ｉ　Ｄ）に含められる。次いで、ステッ プ４，３゜１５によって、ＯＣＲがＧＲＩＤレコードに含められる。万一の非常 事態の場合のＯＣＲ回復に備えて、最低限必要なＯＣＲデータが、ステップ４． ３．１６において、目録項目ごとに記録ファイルに書き込まれる。

ステップ４．３．１７により決定されるように、目録項目がこのＧＷＲ内にさら に存在する場合は、制御は、ステップ４．３．１４に戻され、このプロセスが継 続される。

適切なグループ管理索引レコード（ＧＲＩ　Ｘ）を作成又は位置確認するために 、ＧＷＲ内の都市情報が使用される。ＧＲＩＸが作成される場合には、ＧＲＩＸ に対する参照情報が適切な卸売業省議別表（ＷＩＴ）に含められる。次いで、ス テップ４．３．１８によって、ＧＣＲがＧＲＩＸレコードの中に置かれる。ＧＣ Ｒ活動の履歴を含むレコードは、ステップ４．３．１９におけるＧＣＲ内の参照 情報によって、作成及び／又は保守される。次いで、エージェントがＧＣＲ作成 の成功の通知を受けるステップ４．４（図７）に、制御が戻される。ステップ５ （図３ａ）において、エージェントは、機能的エントリを入力して、グループ・ セツションを終了させる。

通常の予約活動において、ＰＮＲが作成又は保守される（図３ｂのステップ６〜 ９）。

図９によって、アクセスが可能なＧＣＲ目録（図３ｂのステップ７）をより詳細 に説明する。図９を参照すると、ステップ７．１において、エージェントは、Ｇ ＣＲに特有のコードを入力する。ＧＣＲの位置は、このコードから得られ、ステ ップ７．２でのＧＣＲの検索が可能になる。ＧＣＲに含まれるＧＣＲ所有都市デ ータは、ステップ７．３で検索を行っているエージェントの都市に比較される。

都市がマツチしない場合は、ＧＣＲへのアクセスは拒否され、適切なメツセージ がステップ７．４でエージェントに与えられる。ステップ７゜３で都市がマツチ すると判定された場合は、ＰＮＲプロセスにおいてＧＣＲが利用できるようにし て、ＧＣＲからの商品目録のディスプレーをフォーマットする（ステップ７．５ ）。ステップ７．６において、目録更新月に、将来のＧＣＲの検索に使用するた め、ＧＣＨに関する参照情報がＡＡＡに保存される。

図３ｂのステップ８　（ＡＡＡでのＧＣＲ目録調整）を、図１０によって、より 詳細に説明する。図１０を参照すると、ステップ８．１において、エージェント は、特定の目録項目をＯＣＲからＰＮＲに移動する要求を入力する。ＧＣＲ内の 各目録項目は、ＰＮＲに移動した分だけ減らされ、更新されたＧＣＲは、ステッ プ８゜２でファイルされる。ＧＣＲ特有のコードは、ステップ８．３において、 ＰＮＲ内の関連目録項目に保存される。最後に、ステップ８．４で、エージェン トは、ＡＡＡ（パック解除されたＰＮＲフィールド）調整の成功の通知を受ける 。

図３ｂのＰＮＲ保存ステップ９を、図１１によって、より詳細に説明する。図１ １を参照すると、ステップ９．１において、エージェントは、エントリを供給し て、ＰＮＲ）ランザクジョンを完了させる。このトランザクション中に入力され たＡＡＡデータは、ステップ９゜２において、内容が適切かどうかが確認され検 証される。ＡＡＡデータは、次いでステップ９．３において、ＰＮＲに転送され る。

図１１のＰＮＲ作成ステップ９．３を、図１２によって、より詳細に説明する。

図１２を参照すると、ステップ９．３．１において、ＡＡＡにある商品目録のＰ ＮＲへの転送は、最初の目録項目に始まって順次行われる。各目録項目がＰＮＲ に移動されると、ステップ９゜３．２において、ＯＣＲ特有コードについて、そ の項目が照会される。コードの存在が発見されると、適切なＧＣＲがステップ９ ．３．３において検索される。次いでＰＮＲは、ステップ９．３．４において、 適切なＧＣＲ目録項目に含まれるサブＰＮＲ索引に加えられる。

ステップ９．３．５により決定されるように、非目録項目がこのＡＡＡ内にさら に存在する場合、制御は、ステップ９．３．１に戻され、このプロセスが繰り返 される。エージェントは、ステップ９．４においてＰＮＲ作成の成功の通知を受 ける（図１１）。

図３０の“点線ブロック２０６に含まれるプロセス１０〜１５は、グループ情報 の監視と調整に関するプロセスである。プロセス１０〜１５は、どのような順序 でも又何時でも実施することができるので、図３０では、フローの線を接続せず に示しである。更に、図２を参照して上に述べたように、プロセス１０，１１゜ １２は、三種類の全てのデータ（マスター目録２００、グループ管理情報２０１ 、顧客詳細情報２０２）に影響する場合があり、プロセス１４．１５は、グルー プ管理情報２０１及び顧客詳細情報だけに影響するが、マスター目録２００には 影響せず、プロセス１３は、マスター目録２００とグループ管理情報２０１だけ に影響する。

業界では、スケジュール変更としても知られているマスター目録の変更（図３０ のステップ１０）を、図１３によって、より詳細に説明する。スケジュール変更 機能に含まれるものは、ホスト目録変更と、旅客氏名索引と目録レコードが更新 されるブロック予約と、新旧の目録を反映してＰＮＲが更新される再収容と、影 響を受けたＰＮＲの待機である。図１３を参照すると、現行のスケジュール更新 （ステップ１０．１）は、ＯＣＲに影響を与え、さらに、ＰＮＲにも影響を与え るマスター目録変更の原因となる。ＧＣＲとＰＮＲを同期状態に保つため、ステ ップ１０．２においてＧＣＲは、ＰＮＲの前に処理される。ＧＣＲ活動に含まれ るのは、ＧＣＲを移動し目録を更新するためＧＲＩＤにアクセスするブロック予 約と、ＧＣＲの目録を更新してＯＣＲを作動させるためＧＲＩＤにアクセスする 再収容であり、変更されたＧＣＲは、グループ・キューで待機させられる。次い でＰＮＲが処理される。

図３０のステップ１１の顧客目録／非目録変更を、図１４によって、より詳細に 説明する。これらの変更には、ＰＮＲ内の名称変更及びＧＣＲからＰＮＲに販売 される目録項目の販売、取消し又は削減が含まれる。

図１４を参照すると、ステップ１１．１で、ＰＮＲが通常の予約活動により検索 又は作成される。ステップ１１．２では、エージェントは、エントリを供給して 、ＰＮＲトランザクションを完了させる。

図１４のＰＮＲ保存ステップ１１．２を、非目録項目について図１６ａで、また 目録項目について図１５ｂ〜ｅで、より詳細に説明する。図１５ａを参照すると 、ステップ１１．２．１において、非目録項目の通常のＰＮＲ処理は、順次行わ れる。ステップ１１．２．２では、ＧＣＲ参照情報の存在について、ＡＡＡが照 会される。

ＧＣＲ参照情報が存在しない場合は、ＰＮＲ処理は、グループ情報を収容せずに 、通常のとおり継続する。

ＧＣＲ参照情報が存在する場合は、複数存在し得るＧＣＲ参照情報のうちの最初 のものがステップ１１．２゜３でアクセスされる。この参照情報は、ステップ１ １２．４で適切なＧＣＲを検索するために使用される。ＰＮＲ顧客氏名変更は、 ＤＸＡレコードにある。これらの項目は、ステップ１１．２．５で個別に処理さ れる。

顧客氏名及び目録情報は、ステップ１１．２．６において、ＧＣＲ履歴レコード に配置される。このプロセスは、ステップ１１．２．７で判定される如く、全て の氏名項目がなくなるまで継続される。ステップ１１２゜８では、追加のＧＣＲ 参照情報が存在していないかが判定される。存在する場合は、制御は、ステップ １１゜２．３に戻る。

目録項目の通常のＰＮＲ処理は、図１５ｂに示すように、増加又は削減経路を通 る場合がある。図１５ｂを参照すると、ステップ１１．２．９では、顧客目録増 加が必要な場合は、制御は、ステップ１１．２．１０に転送され、顧客目録増加 プロセスが、図１２に詳細に示すＰＮＲ作成ステップのものと同じステップを使 って実施される。

顧客目録削減プロセスは、ステップｊ１．２．１１において、ＤＸＡレコードの 複数の目録項目にアクセスすることにより開始する。ステップ１１．２．１２に おいて、目録項目がさらにないか、ＤＸＡ目録項目に照会する。ＧＣＲ参照情報 が存在する場合は、ステップ１１．２．１３で適切なＧＣＲを検索するために使 用される。顧客氏名及び目録情報は、ステップ１１．２．１４において、ＧＣＲ 履歴レコードに含められる。特定のＧＣＲ目録項目は、更新用に提供され、ＰＮ Ｒ参照情報は、ステップ１１．２．１５で、ＧＣＲ目録項目内のサブＰＮＲ索引 から除去される。ステップ１１．２゜１６では、最終日付け（Ｆ　Ｉ　ＮＡＬ） が存在し、それに達しているか否かを判定するため、ＧＣＲ目録項目がチェック される。最終日付けに達していない場合には、ステップ１１．２．２０で、マス ター目録に戻す替わりに、適切なＧＣＲ目録項目に商品目録を戻す。最終日付け に達している場合は、ＧＣＲ目録項目がホスト提供者から得られたものか否かを 判定するため、ステップ１１．２．１７で、ＯＣＲ目録項目をチェックする。目 録項目がホストから得られたものでない場合は、ステップ１１．２．１８におい て、ＧＣＲを適切な待機プロンプト索引レコードに含める。ホストから得られた ものである場合は、ステップ１１．２．１７．１において、ＧＣＲ目録をマスタ ー目録に戻された分だけ削減する。

ステップ４．３と１２．２のプロセスによく似ているＧＣＲ更新及び保存ステッ プ１１．２．１９を、図１５ｃ、１５ｄ、１５ｅによって、より詳細に説明する 。

図１５ｃを参照すると、ステップ１１．２．１９．１，１１．２．１９．２にお いて、ＧＷＲ中の情報のＧＣＲへの転送は、最初の目録項目から順次行われる。

各目録項目がＧＣＲに転送されると、サブＰＮＲ索引が新しい目録項目について 作成され、ステップ１１．２．１９．３において、目録項目内に記憶される。ス テップ１１．２゜１９．４において、目録項目変更も請求書発行レコードに記録 される。変更された目録項目がＧＣＲに転送されると、その個別の目録項目内で のグループ追跡／最終日付（ＧＲＰＴ／Ｆ　Ｉ　ＮＡＬ）の存在について、変更 された目録項目が照会される。ステップ１１．２．１９５において判定されるよ うに、グループ追跡／最終日付が存在する場合は、ステップ１１．２．１９．６ において、ＧＣＲが適切なＧＲＰＴ／Ｆ　Ｉ　ＮＡＬ索引レコードに含められる 。ステップ１１．２．１９．７で判定されるように、ＧＷＲ内にさらに目録項目 が存在する場合には、制御はステップ１１．２．１９．１に戻り、このプロセス が再び開始される。

ＧＷＲからＧＣＲへの目録項目の転送完了により、ＧＷＲからＧＣＲへの非目録 項目の転送が開始されるが、これを図１５ｄによって、より詳細に説明する。

ステップ１１．２．１９．８．１１．２．１９．９において、各非目録項目が順 次転送される。ステップ１１．２．１９．１０によって決定されるように、待機 プロンプト項目に遭遇すると、ステップ１１．２．１９．１１において、適切な 待機プロンプト索引レコードに、ＯＣＲが含められる。ステップ１１．２．１９ ．１２により決定されるように、非目録項目がこのＧＷＲ内にさらに存在する場 合には、制御はステップ１１．２．１９．８に戻され、このプロセスが繰り返さ れる。ステップ１１．２．１９゜１３において、ＧＣＲはファイルされて、その 作成を完了する。図１５ｅを参照すると、ステップ１１２゜１９．１４において 、適切な目録詳細索引レコードを作成又は位置確認するために必要なデータにつ いて、ＧＷＲ中の目録項目が再び照会される。名称変更又は目録更新が行われた ＧＣＲについては、ステップ１１．２゜１９１５において、目録詳細索引レコー ドにおいて、ＧＣＲ参照情報が更新される。ステップ１１．２．１９１５．１で ＧＣＲ目録が削減された場合には、ステップ１１．２．１９．１５．２において 、マスター目録が更新される。最低限必要なＧＣＲデータが、更新された目録項 目ごとに、記録ファイルに書き込まれる（ステップ１１．２．１９．１６）。ス テップ１１．２．１９．１７により決定されるように、目録項目がこのＧＷＲ内 にさらに存在する場合は、制御は、ステップ１１．２．１９１４に戻り、プロセ スが繰り返される。ステップ１１．２．１９．１８においては、適切なＧＲＩＸ レコードを作成又は位置確認するために、ＧＷＲ内の都市情報が使用される。Ｇ ＣＲ活動の履歴を含むレコードは、ステップ１１．２．１９．１９において、Ｇ ＣＲ内の参照情報によって、作成及び／又は保守される。

図１５ｂのステップ１１．２．２０において、最終日付に達していない場合は、 商品目録は、マスター目録に戻る代わりに、適切なＧＣＲ目録項目に戻される。

次いでステップ１１．２．２１において、目録項目がさらにないか、ＤＸＡが照 会される。ステップ１１２゜２１により決定されるように、ＤＸＡ項目がさらに 存在する場合は、制御は、ステップ１１．２．１１に戻り、このプロセスが繰り 返される。ＤＸＡ探索の完了により図１５ｂに示すプロセスが終了する。

図３０のステップ１２における、グループ目録／非目録変更を、図１６によって 、より詳細に説明する。

これらの変更は、ＧＣＲの定義で上に掲げたアクションの全てを含む。図１６を 参照すると、ステップ１２゜１において、エージェント・グループ活動を通じて 、ＧＣＲが検索される。エージェントは、ステップ１２゜２でＧＣＲトランザク ションを完了させるためエントリを供給する。

ＯＣＲ保存（図１６のステップ１２２）を、図１７ａ〜１７ｃによって、より詳 細に説明する。このプロセスは、図７（ステップ４．３）及び図１５ｂ（ステッ プ１１．２．１９）において詳述したものと同様である。

図１７ａを参照すると、ステップ１２．２．１．１２．２゜２において、ＧＷＲ 中の情報のＧＣＲへの転送は、最初の目録項目から順次行われる。各目録項目が ＧＣＲに移動すると、サブＰＮＲ索引が新たな目録項目について作成さ枳　ステ ップ１２．２．３において、目録項目に保存される。ステップ１２．２．４にお いて、請求書発行レコードに目録項目変更も記録される。変更された目録項目が ＧＣＲに転送されると、個別の目録項目内にグループ追跡／最終日付が存在する か否か、ステップ１２．２．５において、変更された目録項目が照会される。グ ループ追跡／最終日付が存在する場合には、ＧＣＲは、ステップ１２．２．６に おいて、適切なＧＲＰＴ／Ｆ　Ｉ　ＮＡＬ索引レコードに含められる。ステップ １２．２．７で決定されるように、目録項目がＧＷＲ内にさらに存在する場合に は、ステップ１２２゜１に制御が戻って、このプロセスが繰り返される。

目録項目のＧＷＲからＯＣＲへの転送の完了によって、非目録項目のＧＷＲから ＯＣＲへの転送が図１７ｂに詳細を示すように開始される。図１７ｂを参照する と、ステップ１２．２．８，１２，２．９において、各非目録項目が順次転送さ れる。ステップ１２．２．１０において、新たな待機プロンプト項目に遭遇する と、ＧＣＲは、ステップ１２．２．１１において適切な待機プロンプト索引レコ ードに含められる。ステップ１２゜２．１２により決定されるように、非目録項 目がＧＷＲ内にさらに存在する場合には、ステップ１２．２．８に制御が戻り、 このプロセスが繰り返される。ステップ１２．２．１３において、ＧＣＲがファ イルされて、その作成が完了する。

図１７ｃを参照すると、ステップ１２．２．１４において、適切なＧＲＩＤレコ ードを作成又は位置確認するために必要なデータについて、ＧＷＲ内の目録項目 が再び照会される。名称変更又は目録更新が行われたＧＣＲについては、ＧＣＲ 参照情報は、ステップ１２゜２．１５において、ＧＲＩＤレコードにおいて更新 される。ステップ１２．２．１５．１でＯＣＲ目録が削減された場合には、ステ ップ１２．２．１５．２において、マスター目録が更新される。最低限必要なＧ ＣＲデータが、ステップ１２．２．１６で更新された目録項目ごとに、記録ファ イルに書き込まれる。ステップ１２．２．１７により決定されるように、ＧＷＲ 内に目録項目がさらに存在する場合には、ステップ１２．２．１４に制御が戻り 、このプロセスが繰り返される。適切なＧＲＩＸレコードを作成又は位置確認す るためには、ＧＷＲ内の都市情報が使用される。名称変更又は目録更新が行われ たＯＣＲについては、ＧＣＲ参照情報は、ステップ１２．２．１８において、Ｇ ＲＩＸレコードにおいて更新される。ＧＣＲ活動の履歴を含むレコードは、ステ ップ１２．２．１９において、ＧＣＲ内の参照情報によって、作成及び／又は保 守される。

グループ追跡（図３０のステップ１３）を、図１８によって、より詳細に説明す る。グループ追跡は、時間開始関数表又はエージェント・エントリのどちらかを 介して起動されるユーティリティであり、グループ目録利用カウントを捕捉し、 マスター目録の返還の最終日付を処理するよう機能する。図１８を参照すると、 ステップ１３．１において、ＧＲＰＴ／Ｆ　Ｉ　ＮＡＬ索引レコードがユーティ リティ起動日付について検索される。索引レコードは、ステップ１３．２におい て、ＧＣＲ参照情報について順次サーチされる。各ＧＣＲは、ステップ１３３に おいて、検索され、処理される。

ＧＣＲ処理（ステップ１３．３）を、図１９によって、より詳細に説明する。図 １９を参照すると、ステップ１３３１において、ＧＣＲを見いだし、ＧＷＲに取 り込むため、ＧＲＰＴ／Ｆ　Ｉ　ＮＡＬＧＣＲ参照情報が使用される。ＧＣＲ目 録項目がサーチされ、ステップ１３．３．２で参照される。商品目録を適切に調 整するため、最終日付が存在するか否か、またそれに達しているかどうかを判定 するよう、ＧＣＲ目録項目がステップ１３．３．２．１においてチェックされる 。最終日付に達していない場合は、目録動作を行わず、制御はステップ１３．３ ．７に戻る。最終日付に達している場合には、ＧＣＲ目録項目がホスト提供者が ら得られたものであるか否かを判定するため、ステップ１３．３．３においてＧ ＣＲ目録項目をチェックする。ホストから得られたものである場合には、目録項 目は、マスター目録に戻される未使用目録の分だけ、削減される（ステップ１３ ．３．４）。目録項目がホストから得られたものでない場合には、ステップ１３ ．３．５．　１３．３゜６において、ＧＣＲが適切な待機プロンプト索引レコー ドに含められる。ＧＲＰＴ目付が存在するかどうか、そして、その日付けに達し ているか否かを判定するため、ステップ１３．３．７において、ＧＣＲ目録項目 もチェックされる。日付に達している場合には、現行目録在庫レベル・カウント が、ステップ１３．３．８において、ＧＣＲ目録項目に捕捉される。次いでＯＣ Ｒは、ステップ１３．３．９において、更新さヘ　ファイルされる。このプロセ スを、図１７ａ〜Ｃによって、より詳細に説明する。図１８に戻ると、ステップ １３．４においてＧＣＲ項目がＧＲＰＴ／Ｆ　ＩＮＡＬ索引レコード内にさらに 存在する場合には、このプロセスは、ステップ１３，２から繰り返される。レコ ードに対して全てのＧＣＲ項目が尽くされ、しかも、ステップ１３．５によって 判定されるように、他の索引レコードがさらに存在する場合には、ステップ１３ ．１に制御が戻り、次のＧＲＰＴ／Ｆ　Ｉ　ＮＡＬ索引レコードが検索される。

レコード待機（図３０のステップ１４）を、図２０によって、より詳細に説明す る。レコード待機は、時間開始関数表又はエージェント・エントリのどちらかを 介して起動されるユーティリティであり、ＱＭＤ　Ｒフィールドの日付から作成 される待機プロンプト索引レコードをベースとしてＧＣＲを待機させるよう機能 する。図２０を参照すると、ステップ１４．１において、都市待機プロンプト索 引レコードがユーティリティ起動日付について検索される。索引レコードは、ス テップ１４．２において、ＧＣＲ参照情報について順次サーチされ、各ＧＣＲ参 照情報は、ステップ１４．３で待機レコードに含められる。ステップ１４４によ り判定されるように、待機プロンプト索引レコード内にＯＣＲ項目がさらに存在 する場合は、このプロセスは、ステップ１４．２から繰り返される。レコードに 対して全てのＧＣＲ項目が尽くされ、しかもステップ１４．５によって判定され るように、その他の索引レコードが存在する場合には、次の待機プロンプト索引 レコードがステップ１４．１で検索され、本プロセスが繰り返される。

業界において夜間ファイル保守としても知られるレコード保守（図３０のステッ プ１５）を、図２１ａ〜Ｃによって、より詳細に説明する。レコード保守は、エ ージェント・エントリを介して起動されるユーティリティであり、期限切れ日付 ＧＣＲをパージし、そのレコードをシステムに戻し、パージされたＧＣＲのコピ ーをテープに書き込むよう機能する。

図２１　ａ　−ｃを参照すると、ステップ１５，１において、第一に卸売業者索 引レコード（ＷＩＴ）が検索され、最初のＷＩＴ項目がステップ１５．２におい てアドレスされる。ＧＲＩＸレコードアドレス項目がステップ１５．３に存在す るか否かを判定するため、ＷＩＴ項目が照会される。全てのＧＲＩＸレコードア ドレス項。

目が尽くされ、ステップ１５．４によって判定されるように、全てのＷＩＴレコ ードが処理されている場合は、このユーティリティは、終了する。全てのＷＩＴ レコードが検索されていない場合には、次のＷＩＴが検索され、最初の項目がス テップ１５．２において参照される。

ステップ１５．３で判定されるように、ＧＲＩｘレコードアドレス項目が存在す る場合には、ＧＲＩＸがステップ１５．５で検索され、レコードの中の最初のＧ ＣＲ項目がステップ１５．６でアドレスされる。次いで、ステップ１５．７にお いて、現行システム日付が調整済み目録日付とＧＣＲ項目のパージ日付の両方に 比較される。調整済み目録日付は、ＧＣＲに保持されているどれかの目録項目の 最初の出発日であり、パージ日付は、最後の出発日プラスＧＣＲに保持されてい るどれかの目録について前もって決められた日数（例えば７日）である。ステッ プ１５．８．　１５．９で判定されるとおり、調整済み目録日にも、或はパージ 日付にも達していない場合は、□ステップ１５１０において、ＧＣＲ項目がさら にないか、ＧＲＩＸがチェックされる。

それ以上の項目が存在しない場合は、全てのＷＩＴレコードが処理されたことを 確認するため、ステップ１５．３．　１５．４が繰り返される。ステップ１５． ９で判定されるように、パージ日付に達している場合は、ステップ１５．２０に おいて、ＧＣＲが検索され、ＧＣＲで参照された全てのレコードは、ステップ１ ５２１において、システムに戻される。ステップ１５．２２において、ＧＣＲレ コードが戻され、その参照情報は、ステップ１５．２３において、ＧＲＩＸレコ ードから除去される。

このオーナー特有索引について処理すべきこれ以上のＧＣＲ項目が残っているか 否かを判定するため、ステップ１５．１０における処理を継続する。ステップ１ ５．８によって判定されるように、調整済み目録日付に達している場合は、ＧＣ Ｒはステップ１５１１で検索され、最初のＧＣＲ目録項目がステップ１５．１２ でアドレスされる。次いでこの項目は、調整済み目録日とのマツチについて、ス テップ１５．１３でテストされる。

調整済み目録日とマツチしていれば、ＧＣＲは、マイクロフィッシュ処理用に、 ステップ１５．１５でテープに書き込まれる。ステップ１５．１６によって判定 されるように、サブＰＮＲ参照情報がＧＣＲ目録項目について存在している場合 は、ステップ１５１７でサブＰＮＲ氏名リストが作成され、これもマイクロフィ ッシュ処理用に、ステップ１５１８において、テープに書き込まれる。このＧＣ Ｒについてこれ以上のＧＣＲｎ録項目が存在しているか否かを判定するため、こ の時点で、ステップ１５．１４において、チェックが行われる。全てのＧＣＲ目 録項目がこのＧＣＲについて尽きるまで、ステップ１５１２〜１５．１８を通る 処理ループが構成される。ＧＣＲ目録項目の全てが見直されれば、ＧＲＩＸレコ ードの中のＧＣＲ項目は、新しい調整済み目録日を反映するよう、ステップ１５ ．１９において更新される。ステップ１５．１０において、全てのＧＣＲ項目が 処理されるまで、処理は継続され、そして、ステップ１５．３．　１５．４にお いて、全てのＷＩＴレコードが処理されるまで、これ以上のＧＲＩＸレコードア ドレス項目及び卸売業者索引項目があるかどうか、ＷＩＴレコードが照会され、 ユーティリティが完了する。

以上を要約すると、本発明によれば、グループ旅行の自動取扱いができる旅行関 連サービスのコンピュータ予約システムが示される。旅行関連サービスのマスタ ー目録に加えて、また、特定顧客と特定の予約済み旅行関連サービスとの間の関 係を含む複数の旅客氏名レコードに加えて、本発明は、提供されている旅行関連 サービスの特定グループの記録を取るために、グループ管理レコードを使用する 。グループ管理レコードは、その特定グループに提供されている旅行関連サ−ビ スのグループ目録、並びに、グループ目録中の予約済み項目を有する顧客のグル ープ関連旅客氏名レコード（サブＰＮＲ）のセットを維持する。グループ目録は 、マスター目録に相互索引され、サブＰＮＲは、グループに相互索引される。稼 働の際には、本発明によれば、マスター目録、ＧＣＲ又はＰＮＲのいずれかに変 更があったとき、これら項目の残りのものに適切な変更が自動的に行われる。例 えば、マスター目録に変更があった場合には、適切であるなら、ＧＣＲのグルー プ目録に変更が加えられ、また適切であるならば、ＯＣＲによって参照されるサ ブＰＮＲに変更が加えられる。同様に、ＧＣＲに対して加えられる変更は、マス ター目録とＰＮＨに加えられる自動的で適切な変更を生ずる。同じように、ＰＮ Ｒに対して加えられる変更は、ＧＣＲとマスター目録に対する適切な変更を生ず る。

本発明は、柔軟性を有するので、飛行機旅行以外のいくつかの異なる活動におい ても、大きな団体の動きを把握することができる。これらの活動に含まれるもの には、例えば、バス、鉄道、ツアー、クルーズ、会合、パーティ及び会議などが ある。

これらの項目の各々について、本発明の実際的な実施例によれば、卸売業者は、 最大９９９人を収容する項目を９９項目まで予約又は記録するため、ＧＣＲを使 用することができる。これにより、単一のＧＣＲによって、最大９８，９０１人 を動がすことができる。

各項目は、何らかの種類のサービスについて異なった提供者を反映することがで き、顧客が要求する異なった好みを反映するよう、サービス水準又は各項目をよ り専門化することができる。

以−１１」 本発明の特長のいくつかを例証するため、特定の実施例を掲示する。

１９９０年１月１日、認可卸売業者Ａ２３は、　「プリンセス」クルーズライン で２００人のグループにクルーズをアレンジする。クルーズは、１９９０年２月 １７日フォート・ローダ−ゾールを出発し、１９９０年２月２８に帰港する。卸 売業者の代理店は、デンバーとシカゴの二つの都市の各々から１００人の旅客が ユナイテッドとアメリカンの二つのエアラインでフォート・ローダ−ゾールに到 着、出発するものと予測する。この例では、ユナイテッド・エアラインがホスト 提供者となる。旅客は、各エアラインで二つのクラスのサービスを選択できる。

この情報をベースとして、ＳＷＳのイニシャルを持つ卸売業者のエージェントは 、以下の情報を含むＧＣＲを作成する。

このフィールドの内′Ｎニブリンセス このフィールドの内”：　ＤＥＮＢ／３０３１２３４５６７ユナイテツド１便、 ５０座席、Ｙクラス（エコノミークラス）、フォート・ローダ−ゾールに向はデ ンバーから２月１７日出発。

区分２ ユナイテッド１便、５０座席、Ｆクラス（ファーストクラス）、フォート・ロー ダ−ゾールに向はデンバーから２月１７日出発。

区分３ アメリカン２便、７０座席、Ｙクラス（エコノミークラス）、フォート・ローダ −ゾールに向はシカゴから２月１７日出発。

区分４ アメリカン２便、３０座席、Ｆクラス（ファーストクラス）、フォート・ローダ −ゾールに向はシカゴから２月１７日出発。

区分５ ユナイテッド３便、５０座席、Ｙクラス（エコノミークラス）、デンバーに向は フォート・ローダ−ゾールから２月２８日出発。

区分６ ユナイテツド３便、５０座席、Ｆクラス（ファーストクラス）、デンバーに向は フォート・ローダ−ゾールから２月２８日出発。

区分７ アメリカン４便、５０座席、Ｙクラス（エコノミークラス）、シカゴに向はフォ ート・ローダ−ゾールから２月２８日出発。

区分８ アメリカン４便、５０座席、Ｆクラス（ファーストクラス）、シカゴに向はフォ ート・ローダ−ゾールから２月２８日出発。

ＦＩＮＡＬ目録最終返還日　未使用目録が提供者に返還されねばならない目録項 目中の 日付 このフィールドの　′Ｎ： 区分１〜４についてはＦＩＮＡＬ日付は２月１日区分５〜８についてはＦＩＮＡ Ｌ日付は２月８日ＧＲＰＴ　目録グループ追跡　現行目録在庫レベルの捕捉（へ °ナルティ）日付　が希望される目録項目内に区分１〜４についてはＧＲＰＴ目 付は１月１５日、１月３０日 区分５〜８についてはＧＲＰＴ目付は１月１５日、１月３０日、２月７日 辿　待機マインダー　特定の待ち行列へとＧＣＲを入れるべき日付 このフィールドの　六二 １月３０日、待ち行列番号１５ ＧＣＲが完成したとき、各ユナイテツド区分のＰ−ＮＩＤは、ＧＲＩＤについて の参照情報を含むことになる。ＧＲＩＤは、各ユナイテツド区分についてＧＣＲ に対する参照情報を含む。ＧＲＩＸは、ＧＣＲに対する単一の参照情報を含む。

ＷＩＴは、ＧＲＩＸに対する単一の参照情報を含む。

以下のディスプレーは、ＧＣＲが上記のデータでどのようにディスプレーするか の一例である：個別の旅客がクルーズ用にその航空機スペースの予約を開始する と、ＯＣＲと関連のサブＰＮＲが更新される。例えば、旅客ＡとＢがデンバーか らのユナイテッド・フライトでファーストクラス往復を二座席予約する。エージ ェントがサブＰＮＲを作成するとき、以下が発生する： １、サブＰＮＲは、各区分に二座席を有するＧＣＲからの両方のユナイテッド区 分を含む。ＰＮＲの各区分は、ＧＣＨに対する参照情報を含む。

２、ＧＣＲのユナイテッド区分の使用可能（ＡＶＬ）カウントは、二座席分減分 される。予約済み（ＢＫＤ）カウントは、二座席分増分される。

３、旅客Ａ及びＢのためのサブＰＮＲに対する参照情報を含ませるため、各ＯＣ Ｒ区分のサブＰＮＲ索引が更新される。

ＰＮＲが完成すると旅程は、以下の例のようにディスプレーされる； その結果生まれるＧＣＲ区分は、次のようにディスプレーされる： 旅客Ａ及びＢが予約をキャンセルした場合は、エージェントは、サブＰＮＲ区分 を検索し、取り消す。サブＰＮＲ取消し作業が完了すると以下が発生する＝１、 サブＰＮＲ区分及びそのＧＣＲに対する参照情報がサブＰＮＲから除去される。

２、ＯＣＲのユナイテッド区分の利用可能（ＡＶＬ）。

カウントは、二座席分増分される。予約済み（ＢＫＤ）カウントは、二座席分減 分される。

３、各ＯＣＲ区分のサブＰＮＲ索引は、旅客Ａ及びＢのサブＰＮＲに対する参照 情報を消去するよう更新される。

最初のＧＲＰＴ目付けである１月１５日になると、ユナイテッド区分２及び６に ついて２０座席がサブＰＮＲに販売されたものと仮定して、ＧＣＲ目録区分は、 以下のように更新される： 座席がサブＰＮＲに販売されなかった他の全ての目録区分又は他の全ての目録活 動、例えば区分７は、以下のように示される： ＦＩＮＡＬ日付けである２月１日、２月８日（こなると、ユナイテッド区分２及 び６について２０座席がサブＰＮＲに販売されたものと仮定して、ＯＣＲ目録区 分は、以下のように更新される： １、ＦＩＮＡＬＢ付時点で使用されなかった３０座席は、キャンセルされたもの と解釈し、マスター目録に戻される。

２、各区分のＧＲＩＤ項目は、新たな現行ブロック化カウントにより更新される 。

３、ＧＣＲ目録区分の利用可能カウントは、ゼロに削減され、現行ブロック化カ ウントは、２０に削減される。

ＧＣＲの区分２及び６は、次いで以下の例のようにディスプレーされる： ＦＩＮＡＬＢ付になったとき、ホスト提供者（ＵＡ：ユナイテッド・エアライン ）区分について座席が販売されなかった場合は、全ての現行ブロック化座席は、 目録に戻さｔ５ＧｃＲ目録項目は、ＧＣＲから除去される。これによってＧＲＩ Ｄ及びＧＲＩＸレコードにおいてＧＣＲ参照情報の取消しが生ずる。非ホスト提 供者（ＡＡ：アメリカン・エアライン）については、目録は調整されず、マスタ ー目録の手動返還をプロンプトするようメツセージがキューされる。提供者両方 について最終日付に達したことを表示するため、目録項目が更新される。

ＯＣＲ目録区分に対して状態コード変更が行われた場合には、変更はＧＣＲ目録 区分によって参照されるサブＰＮＲ索引レコードに含まれる全てのサブＰＮＲに 拡大される。例えば、ＧＣＲの区分２の状態コードＨＫがＷＫに変更されたが旅 客のＰＮＲがそのＧＣＲ区分から販売された目録を依然含んでいる場合は、ＧＣ Ｒ変更がエージェントによって完了されたとき、以下が発生する： １、ＧＣＲから販売されたサブＰＮＲ目録項目が新しい状態コードで更新される 。

２、ＧＣＲ目録項目状態コードが新しい状態コードで更新される。

次いで、ＧＣＲ目録区分は、以下のようにディスプレーされる： サブＰＮＲ目録区分は、以下のようにディスプレー１　ＵＡ　ＩＦ　１７ＦＥＢ 　ＤＥＮＦＬＬ　ｍ　９４５Ａ　４０５Ｐ　ＴＨＧ３４３ＬＭ６本発明を単一の 好適実施例について説明してきたが、変更、追加及び削除を本発明の範囲から逸 脱せずに好適実施例に対して行えることが理解される。

「物。潰 特表千６−５０６０７４　（１６） 痢ｇＪ、　Ｃ口 国際調査報告 フロントページの続き （８１）指定国　ＥＰ（ＡＴ、ＢＥ、ＣＨ，ＤＥ。

ＤＫ、　ＥＳ、　ＦＲ，ＧＢ、　ＧＲ，ＩＴ、　ＬＵ、　ＮＬ、　ＳＥ）、０Ａ （ＢＦ、ＢＪ、ＣＦ、ＣＧ、ＣＩ、ＣＭ、ＧＡ、ＧＮ、ＭＬ、ＭＲ，ＳＮ、ＴＤ 、ＴＧ）、ＡＴ、ＡＵ、　ＢＢ、　ＢＧ、　ＢＲ，ＣＡ、　ＣＨ，Ｃ３，ＤＥ、 　ＤＫ。

ＥＳ、　ＦＩ、　ＧＢ、　ＨＵ、ＪＰ、　ＫＰ、　ＫＲ，ＬＫ、　ＬＵ、ＭＣ， ＭＧ、ＭＮ、ＭＷ、ＮＬ、Ｎｏ、ＰＬ、ＲＯ、ＳＤ、ＳＥ、５Ｕ （７２）発明者　マイヤー、マーク・ジェイアメリカ合衆国、８０１２６　コロ ラド、ハイランズ・ランチ、サウス・スプリング・ヒル・レイン　９８０７ （７２）発明者　ポスルズウェイト、リング・ニスアメリカ合衆国、８０１１１ 　コロラド、イングルウッド、イースト・ウィーヴアー・サークル　１０３７２ （７２）発明者　シュリンプ、スティーヴン・ダブリューアメリカ合衆国、８０ ２３５　コロラド、デンヴアー、サウス・ミラー・コート　３７１９

Claims (13)

【特許請求の範囲】
1. １．旅行関連サービスのマスター目録、および、該マスター目録から予約された 旅行関連サービスを個人に関連付ける複数のマスター旅客氏名レコードを含むコ ンピュータ予約システムにおいて、下記のステップからなる方法。 旅行関連サービスのグループ目録および複数のグループ関連旅客氏名レコードを 含む少なくとも一つのグループ管理レコードを作成するステップ。ここで、該グ ループ目録は、該マスター目録のサブセットであり、かつ、該グループ関連旅客 氏名レコードは、該マスター旅客氏名レコードのサブセットである。 該マスター目録と該グループ関連旅客氏名レコードと該少なくとも一つのグルー プ管理レコードとを、これら三つの少なくとも一つの変更に応答して、自動変更 するステップ。
2. ２．上記複数のグループ関連旅客氏名レコードの各々が、それぞれのグループ管 理レコードに対する参照情報を含む請求項１の方法。
3. ３．上記グループ管理レコードの各々が、関連した複数のグループ関連旅客氏名 レコードの各々に対する索引を含む請求項２の方法。
4. ４．上記グループ管理レコードの各々が、関連した複数のグループ関連旅客氏名 レコードの各々に対する索引を含む請求項１の方法。
5. ５．上記マスター目録の変更に応答して、上記自動修正ステップが、上記少なく とも一つのグループ管理レコードのグループ目録を修正するステップと、そして 、上記マスター目録の上記変更を反映するように上記少なくとも一つのグループ 管理レコードに対応する上記複数のグループ関連旅客氏名レコードの各々を修正 するステップとからなる請求項１の方法。
6. ６．上記作成ステップが、更に上記少なくとも一つのグループ管理レコードの各 々のグループ活動日の設定からなり、 それぞれのグループ活動日の発生とともに、上記マスター目録と、上記少なくと も一つのグループ管理レコードとを自動的に適切に修正するステップから更にな る請求項１の方法。。
7. ７．上記作成ステップが、上記少なくとも一つのグループ管理レコードの各々に ついて少なくとも一つの最終日を設定するステップを含み、 あるグループ管理レコードにおいて、上記少なくとも一つの最終日後、上記マス ター目録にグループ目録を自動的に戻すステップから更になる請求項１の方法。
8. ８．以後の処理のために上記少なくとも一つのグループ管理レコードを定期的に 待機させるステップからなる請求項１の方法。
9. ９．上記少なくとも一つのグループ管理レコードを定期的に待機させるステップ が、上記少なくとも一つのグループ管理レコードに対するアクションの条件の表 示を提供するステップから更になる請求項８の方法。
10. １０．アクションについての上記条件が、上記少なくとも一つのグループ管理レ コードにおける最終日の後、上記マスター目録へグループ目録を手動返還するこ とである請求項９の方法。
11. １１．上記少なくとも一つのグループ管理レコードに関連するそれぞれの最終旅 行日の満了後、上記少なくとも一つのグループ管理レコードの各々を、上記コン ピュータ予約システムから自動的にパージするステップから更になる請求項１の 方法。
12. １２．上記作成ステップが、更に、 あるグループ管理レコードに関連する空データ・フィールドを含む暫定的グルー プ作業レコードを作成するステップと、 特定のグループ旅行サービス商品に関連する情報を選定された空データ・フィー ルドに入れるステップと、上記グループ作業レコードフィールドを対応するグル ープ管理レコードフィールドに転送することによりグループ管理レコードを作成 するステップとからなる請求項１の方法。
13. １３．グループ旅行関連サービスのためのコンピュータ予約装置において、 旅行関連サービスのマスター目録を記憶する手段と、グループ関連旅客氏名レコ ードの少なくとも一つのサブセットを含む複数の旅客氏名レコードを記憶する手 段と、ここで、該グループ関連旅客氏名レコードの少なくとも一つのサブセット がそれぞれのグループ管理レコードに関する参照情報を含む、 複数のグループ管理レコードを記憶する手段と、ここで、各グループ管理レコー ドが旅行関連サービスのある特定のグループ目録を示すものであり、そして、各 グループ管理レコードが該グループ関連旅客氏名レコードのそれぞれのサブセッ トに関する参照情報を含む、 該マスター目録の変更に応答して該グループ関連旅客氏名レコードの該それぞれ のサブセットおよび該グループ管理レコードの各々を自動的に修正し、該複数の グループ管理レコードの各々の変更に応答して該マスター目録およびそれぞれの グループ管理レコードを自動修正し、該グループ関連旅客氏名レコードの該複数 のサブセットの変更に応答して該マスター目録およびそれぞれのグループ関連旅 客氏名レコードを目動的修正する手段と、 からなる上記コンピュータ予約装置。