JP2016503924A - 紛失した荷物のための代償のためのシステム - Google Patents

Abstract

本開示は、荷物の中身に関わらず、乗客が、航空会社によって紛失された荷物または手荷物のための代償を受け取るための処理を提供する。この処理は、荷物の中身に関わらず、航空会社便の飛行区間について、予め定められた荷物の保障額を請求し、任意のタイプの電子媒体で、航空会社から情報を取得し、ある期間後容易に、かつ、さらなる証明無しで、保障されている人によって保障額が得られうるように、物理的なレシートを生成する。この方法は、航空会社が、荷物を紛失したことを宣言するための、第１の固定期間、待機することと、および、宣言された荷物紛失に対する請求を申告するために、第１の固定期間よりも長い第２の固定期間、待機することと、を含む。

Description

本開示は、荷物の紛失のための代償のための処理に関する。さらに詳しくは、本開示は、航空会社によって、荷物を紛失された乗客に対して、荷物の中身の価値を証明することなく支払いを行う、代償のための処理に関する。さらにより具体的には、本開示は、紛失した荷物の中身の価値の証明なしで、バッグは、指定された代償額について設定された料金が保証される処理に関する。

観光産業は、国内航空路線の乗客数が増加している成長産業である。米国運輸省の航空施行および審議局によってなされた月刊調査によると、２００５年において乗客１０００人毎に、平均して６．０４件の誤取扱荷物の報告があった。

米国の旅行保険業界は、乗客による購入が可能な、多くの異なるタイプの保証保険を提案している。現在の旅行保証保険は、非常に広い保障から非常に具体的な保障にまで及ぶ。いくつかの保険は、旅行中に生じうるあらゆる事象のための保証を乗客に提供する。その他の保険は、非常に明示的に、厳密に定義された状況のための保証保障を乗客に提供する。

現代の航空路線市場は、乗客が、旅行保証と荷物保証との両方を得なければならないということである。ほとんどの旅行保証は、異なるさまざまな保障額を、１つの保険に詰め込んでいる。これらの保険は、２０ドルほどの費用でありうる。しかしながら、ほとんどの状況において、プレミアムが、６０ドル以上になるであろう。これらの保険は、旅行キャンセル、医療保障、生命保証、およびレンタカー保証を含む非常に広いリスクをカバーする。さらに、これらの保険の詳細は、乗客を圧倒しうる。

その他のタイプの荷物保証は、一度の旅行を続けている旅行者のために設計されたパッケージ保険を含む。これらは、クルーズ、ツアー、航空便、家レンタル、およびその他のタイプの旅行のために使用されうる。これらの保険は、旅行キャンセル、荷物、医療、歯科、緊急避難、２４時間旅行者支援、荷物遅延、旅行遅延、および事故死保障のための保障を含む。いくつかの保険はまた、レンタカーの衝突／損害保障、（飛行中の間のみの事故死保障の形態の）航空便保証、および追加の緊急避難保証のためのオプションも含んでいる。いくつかのパッケージ保険は、追加費用無しで、子供のための保障を含んでいる。この保険の料金は、上記の保障額のうちの多くを含むこと無しで１９ドル乃至５６ドルに及び、そこから費用が増加する。

また、個人のビジネス旅行客と、旅行中の従業員がいる中小企業とのためにユニークに設計されたビジネス・パッケージ保険も存在する。これら保険はまた、喪失、盗難、および／または、破損したノートパソコン、セル電話、およびブース展示物の費用のみならず、展示会およびビジネス会議の費用をも含むビジネス財産および荷物のためにも備えている。あなたの会社が、年払いのための口座を有していると仮定すると、これらの保険は、旅行あたり平均して６９ドルの費用がかかる。

何人かの住宅所有者の保証保険は、保険契約者にこのオプションを提案する。保険契約者は、自分たちの荷物の価値を証明しなくてはならず、そのタイプの保険のために、はるかに高額なプレミアムを支払わねばならないであろう。

さらに、いくつかのクレジット・カード会社は、旅行中の乗客のために、彼らの荷物に対する追加の保障を提案している。前述したソリューションのすべては、乗客に対して、彼らの荷物の中身の価値を証明することを要求している。

本開示は、乗客が、荷物の中身に関わらず、航空会社によって紛失された荷物または手荷物のための代償を受け取る処理を提供する。

本開示はまた、荷物の紛失という航空会社の乗客のトラウマを低減するために、荷物紛失に関する代償を受け取る、単純かつ簡単な処理をも提供する。

本開示はさらに、限定される訳ではないが、従来の保証保険、サービス合意または契約の形態を含む保障が、チケット購入時において、または、航空便前の後日において保証されるような処理を提供する。

本開示はさらに、航空会社によってモニタされた乗客の荷物のため、航空会社便の飛行区間に、予め決定された保障額を請求するような処理を提供する。

本開示はまた、航空会社によってモニタされた乗客の荷物に対して、荷物の中身に関わらず、航空会社の航空便の飛行区間に、予め決定された保障額を請求し、航空会社から、任意のタイプの電子媒体のみならずその他のソースを介して、情報を取得し、保障されている人によって、保障額が、ある期間後に、容易に、かつさらなる証明無しで得られるように、物理的なレシートを生成する、処理をも提供する。

本開示はさらに、荷物をモニタし、荷物が紛失された場合に、代償を提供する方法を提供する。この方法は、航空会社の航空便において、荷物の１つまたは複数のピースをチェックすることと、航空便の出発前の任意の時間において、どの荷物の中身であるかに関わらず、固定料金で荷物の保障を購入することと、１つの荷物、または、荷物の１つまたは複数のピースが、紛失されていることを航空会社が宣言するために、第１の固定期間待機することと、宣言された紛失荷物のための請求を申告するために、第１の固定期間よりも長い第２の固定期間待機することと、を含む。

本開示はさらに、旅行の飛行区間の数を決定することと、第３の固定期間を超えた、この旅行の各飛行区間の時間の長さを決定することと、この決定に基づいて、１つよりも多くの保険、合意、または契約が必要とされるか否かをアドバイスすることと、を含むこのような方法を提供する。

図１は、本開示のシステムの概要である。 図２は、乗客購入処理の例示である。 図３は、旅行代理店購入処理の例示である。 図４は、誤取扱荷物レポートの電話処理による申告の例示である。 図５は、誤取扱荷物レポートのウェブサイト処理による申告の例示である。 図６は、誤取扱荷物レポート処理の処理の例示である。 図７は、誤取扱荷物レポート処理において紛失を宣言することの例示である。

図面、特に図１に示すように、参照番号１００によって一般に表わされている本開示にしたがうシステムが図示されている。システム１００は、航空会社のコンピュータ２０と、１つまたは複数のユーザ・インタフェース・デバイス３０，３４であって、そのうちユーザ・インタフェース・デバイス３０が、コンピュータ２０に動作可能に接続されている、１つまたは複数のユーザ・インタフェース・デバイス３０，３４と、ホストまたはテクノロジ所有者コンピュータ４０と、各コンピュータ２０を動作可能に接続する、例えばインターネットのようなネットワーク５０と、を含む。共通の番号は、図面間で繰り越されていることに注目されたい。

コンピュータ２０は、航空会社のための中央コンピュータである。コンピュータ２０は、プロセッサ２１およびメモリ２２を含む。メモリ２２は、プログラム・モジュール２５を有する。コンピュータ２０は、ユーザ・インタフェース３０，３４から離れて配置される。コンピュータ２０は、スタンド・アロン・デバイスとしてここに示されているが、そのようなデバイスに限定されない。コンピュータ２０は、分散処理システム内の他のデバイス（図示せず）に結合されうる。

プロセッサ２１は、命令に応答し、実行する論理回路で構成された電子デバイスである。

メモリ２２は、コンピュータ・プログラムでエンコードされた有形のコンピュータ読取可能な記憶媒体である。この点において、メモリ２２は、プロセッサ２１の動作を制御するために、プロセッサ２１によって読取および実行可能な、データおよび命令を記憶する。メモリ２２は、ランダム・アクセス・メモリ（ＲＡＭ）、ハード・ドライブ、読取専用メモリ（ＲＯＭ）、またはこれらの組み合わせ内に実装されうる。

プログラム・モジュール２５は、本明細書に記載された方法を実行するプロセッサ２１を制御するための命令を含む。本明細書で使用される「モジュール」という用語は、スタンド・アロンの構成要素として、または複数の下位構成要素の統合構成として具体化されうる機能的な動作を示す。したがって、プログラム・モジュール２５は、単一のモジュールとして、または互いに協調して動作する複数のモジュールとして実現されうる。さらに、プログラム・モジュール２５は、メモリ２２にインストールされ、よってソフトウェアで実現されるものとして本明細書において記載されている。しかしながら、プログラム・モジュール２５は、任意のハードウェア（例えば、電子回路）、ファームウェア、ソフトウェア、またはこれらの組み合わせで実現されうる。

プログラム・モジュール２５は、メモリ２２に既にロードされているように図示されているが、メモリ２２への後続するロードのために記憶デバイス２３上に構成されうる。記憶デバイス２３は、プログラム・モジュール２５を記憶する有形のコンピュータ読取可能な記憶媒体である。記憶デバイス２３の例は、コンパクト・ディスク、磁気テープ、読取専用メモリ、光学記憶媒体、ハード・ドライブ、または、複数のパラレル・ハード・ドライブからなるメモリ・ユニット、およびユニバーサル・シリアル・バス（ＵＳＢ）フラッシュ・ドライブを含む。あるいは、記憶デバイス２３は、ランダム・アクセス・メモリでありうるか、または、遠隔の記憶システムに配置され、ネットワーク５０を介してコンピュータに結合されたその他のタイプの電子記憶デバイスでありうる。

ユーザ・インタフェース３０は、空港内の航空会社ブースにおける端末、旅行代理店における端末、オンライン・チケット端末、またはその他任意のチケット提供デバイスでありうる。ユーザ・インタフェース３０は、ユーザ３１を有する。ユーザ・インタフェース３０は、例えば、空港におけるチケット・プロバイダ、旅行会社、または許可された販売員（以後、「チケット・プロバイダ３１」と呼ぶ）のようなユーザ３１が、チケットの購入、およびおそらくは荷物タグまたは手荷物タグのための情報およびコマンド選択を通信することを可能にするための、例えばキーボードまたはスキャナのような入力デバイスを有しうる。チケット・プロバイダ３１は、最新の乗客および航空便情報を、入力デバイスを介して入力するために、ユーザ・インタフェース・デバイス３０を用いる。このような情報は、コンピュータ２０に送信される。さらに、このような情報は、後述するように、乗客および荷物の情報を印刷するために、ユーザ・インタフェース・デバイス３０のメモリ３２内に少なくとも一時的に記憶されうる。

ユーザ・インタフェース３０はさらに、ディスプレイ（図示せず）および出力デバイス（図示せず）を含んでいる。出力デバイスは、例えば、チケットを印刷し、および／または、荷物タグまたは手荷物タグをも印刷するプリンタである。ユーザ・インタフェース・デバイス３０は、チケットおよび荷物タグ情報を含むすべての情報を受け取るために、インターネット以外の任意の電子手段によって、中央コンピュータ２０に接続されている。

例えば、航空会社端末におけるチェック・イン中に、航空会社、またはユーザ３１は、コンピュータ２０によって「タグ付けされた」荷物をモニタする方法を用いて、乗客の荷物を「タグ付けする」であろう。チェック・インされた荷物は、チェック・イン・カウンタにおいて航空会社係員によって「タグ付けされた」バッグである。現在、航空会社係員は、通常、チェック・イン・カウンタにおいて、乗客の荷物に、荷物タグを物理的に取り付けている。これらの手荷物「タグ」は、航空会社のコンピュータ・システムが、乗客の荷物を追跡することを可能にするシリアル番号およびバー・コードを含んでいる。乗客もまた、同じシリアル番号およびバー・コードが付されたレシートまたは荷物「タグ」部分を与えられる。この荷物「タグ」レシートは、しばしば、乗客がチェック・イン・カウンタにおいて受け取る搭乗券に物理的に付されている。実際の荷物タグ、荷物タグ・レシート、およびバー・コードは、異なる航空会社について異なって見えるだろう。乗客の荷物は、航空会社係員によって取得される。乗客は、通常、座席指定および搭乗券を受け取るのと同時に、荷物をチェック・インするであろう。したがって、荷物は、航空会社識別情報マーカを用いて「タグ付け」され、航空会社係員の監督下にあるのであれば、航空会社によってモニタされていると考えられる。

あるいは、乗客は、空港に到着する前に、自身で、荷物「タグ」を印刷するオプションを有する。何れの事例であっても、これら荷物タグ・レシートは、現在、バッグに付された荷物タグ上のバー・コードと一致するバー・コードを含んでいる。乗客は、モニタリング・システムが、荷物に割り当てた値の記録を、チケット控えを用いて受け取るであろう。

本明細書で使用されるようにバッグまたは荷物は、航空便に先立ってチェックされうる商品または物のみならず、従来のバッグを含んでいる。本開示のシステムの最適な動作のために、ユーザ・インタフェース３０は、ソフトウェア３３の一部にも動作可能に接続されうる。好適には、ソフトウェア３３は、メモリ３２内における契約プロバイダまたはチケット・プロバイダの位置が、航空会社端末におけるブース、旅行会社、または、許可されたチケット・プロバイダの位置であるかに関わらず、メモリ３２内における契約プロバイダまたはチケット・プロバイダの位置においてインストールされる。ソフトウェア３３はまた、プログラム・モジュール２５の一部でもありうる。ソフトウェア３３は、コンピュータ２０のプロセッサ２１に送られた情報から、チケット購入者および荷物タグに関するすべての関連情報を引き出す。

ソフトウェア３３は、ともに「許可されたプロバイダである」非インターネット・ベースのチケット・プロバイダまたは契約プロバイダのローカル・マシンに、または、インターネット・ベースのチケットまたは契約プロバイダのウェブサイトにインストールされうる。許可されたプロバイダのみが、一度に、すべての乗客情報をシステムに入力しなければならなくなるように、ソフトウェア３３は、データベース４３から情報を取得しうる。したがって、ソフトウェア３３は、ほとんど認識されることはなく、実際に、乗客を遅らせることはないであろう。

収集する必要である情報またはデータは、乗客の連絡情報と、実際の航空便に関する情報である。

インターネット・ベースの許可されたプロバイダの場合、ソフトウェア３３は、乗客の選択を示すチェック・ボックスを、ウェブサイトに追加するであろう。その選択がなされると、必要なすべての情報が、プログラム・モジュール２５に自動的に転送されるであろう。オンライン・チケット・ブローカ（すなわち、許可されたたプロバイダ）が、セキュリティまたはその他の理由で、自分の契約プロバイダ情報を提供することに問題があるのであれば、システムが確立され、許可されたプロバイダは、乗客が、紛失された荷物について請求するために、許可されたプロバイダにコンタクトした情報を、ケース・バイ・ケース・ベースで、契約プロバイダに提供するであろう。

コンピュータ２０と類似して、コンピュータ４０は、命令に応答し、命令を実行する論理回路から構成された電子デバイスであるプロセッサ４１を有している。

ホスト・コンピュータ４０における所有者の指定するデータベース４３が、指定されたホーム・サイトにおける専用マシンに配置される。本明細書において定義されるように、所有者または契約プロバイダは、本開示の技法に興味を持つ所有者を有するパーティであり、この定義は、所有者、すなわち許可されたプロバイダによって許可されたすべてのライセンシおよびサブライセンスを含む。

コンピュータ４０は、プロセッサ４１、プログラム・モジュール４５およびソフトウェア４４を備えたメモリ４２、およびコンピュータに動作可能に接続されたデータベース４３を含んでいる。

ソフトウェア４４の一部は、ユーザ・インタフェース３０，３４および航空会社コンピュータ２０から引き出され、データベース４３に記憶された情報に関する到来データを制御する。ホスト・コンピュータ４０は、本技法の所有者の制御または単独の監督下にあるように、コンピュータ２０から分離していなければならないが、１つまたは同一にもなりうる。プロセッサ４１は、請求目的のために、データをインポートしたり、データベース４３からエクスポートする。したがって、許可されたプロバイダでもありうる、この技法の所有者は、許可されたプロバイダに請求書を送付しうる。

コンピュータ４０は、スタンド・アロン・デバイスでありうるが、それに限定されない。代わりに、コンピュータ４０は、分散処理システムにおいて、ローカル・ネットワークまたはネットワークを介して、他のデバイスに結合または接続されうる。

メモリ４２は、有形のコンピュータ読取可能な記憶デバイスである。この点において、メモリ４２は、プロセッサ４１の動作を制御するためにプロセッサによって読取および実行可能であるデータおよび命令、すなわちプログラム・コードを記憶している。メモリ４２は、ランダム・アクセス・メモリ（ＲＡＭ）、ハード・ドライブ、読取専用メモリ（ＲＯＭ）、これらの組み合わせで実現されうる。メモリ４２の１つの構成要素は、プログラム・モジュール４５である。

プログラム・モジュール４５は、本明細書に記載された方法を実行するためにプロセッサ４１を制御するための命令を含んでいる。

「モジュール」という用語は、本明細書において、スタンド・アロンの構成要素として、または複数の従属する構成要素の統合構成として具体化されうる機能的な動作を示すために使用される。したがって、プログラム・モジュール４５は、単一のモジュール、または、互いに協調して動作する複数のモジュールとして実現されうる。さらに、プログラム・モジュール４５は、メモリ４２内にインストールされ、ソフトウェアで実現されるものとして記載されているが、ハードウェア（例えば、電子回路）、ファームウェア、ソフトウェア、またはこれらの任意の組み合わせのうちの何れかで実現されうる。

プログラム・モジュール４５は、メモリ４２にロードされたものとして例示されているが、メモリ４２への後続するロードのため、記憶デバイス４８上に構成されうる。記憶デバイス４８は、プログラム・モジュール４５を記憶している有形のコンピュータ読取可能な記憶媒体でありうるという点において、記憶デバイス２３と同じでありうる。記憶デバイス４８の例は、限定される訳ではないが、コンパクト・ディスク、磁気テープ、読取専用メモリ、光学記憶媒体、ハードディスク・ドライブ、ソリッド・ステート・ドライバ、または、複数の並列なハード・ドライブからなるメモリ・ユニット、およびユニバーサル・シリアル・バス（ＵＳＢ）フラッシュ・ドライブを含む。あるいは、記憶デバイス４８は、遠隔記憶システムに配置され、ネットワークを介してコンピュータに結合されている、ランダム・アクセス・メモリ、または、その他のタイプの電子記憶デバイスでありうる。

前述したように、システム１００は、コンピュータ４０に通信可能に結合された少なくとも１つのデータベース４３を含んでいる。本開示に記載されているように、複数の記憶デバイスにおける複数の個別のデータベースとして構成されうるデータベース４３は、データ４９を含んでいる。データベース４３は、必要なすべてのセキュリティ対策を有している。これらの対策は、外部の人、または、無許可の人が、データベース４３へハッキングすること、すなわち、個人情報の盗み取りまたはアクセスすることを阻止する。

ユーザ・デバイスおよびユーザ・インタフェース３４は、限定される訳ではないが、デスク・トップ・コンピュータまたはラップトップ・コンピュータ、移動通信デバイス、または、当該技術で知られているようなその他のデバイスを含む。システム・パラメータは、システム１００において管理され、システム１００は、単一のコンピュータでありうるか、コンピュータにリンクされた構造でありうる。これらのシステム・パラメータは、アイテムが、データベース・テーブルおよび管理セクションを生成することを正当化しない場合、特定の機能をパラメータ化するために使用されうる。管理者は、パラメータを追加、編集、または削除しうる。

システム１００内で、事業単位が管理されうる。これらの事業単位は、旅行代理店登録のために使用されうる。管理者は、事業単位を追加、編集、または削除しうる。

本開示のシステム１００では、システム機能に関連するスクリーンおよび処理にアクセスすることができる、指定された乗客または係員に利用可能なシステム機能を記載するユーザ・インタフェースを介して、システム機能スクリーンが提供される。

サービス合意購入スクリーンによって、顧客は、サービス合意を購入することが可能となる。

サービス合意購入スクリーンは、コンピュータ４０によってサービス提供されている許可されたプロバイダ・ホームページ（図示せず）から、または、電子メールによって提供されたダイレクト・リンクから開始されうる。フィールドは、サービスのレベル、航空会社確認番号、出発航空会社、出発便番号、乗客数、乗客情報、名、姓、および、電子メール・アドレスを含みうる。

サービス・スクリーンのサマリでは、ユーザが、サービスのレベルの値、および、乗客数のフィールドを変更すると、以下の情報が、自動計算し、サービス・レベルが、選択されたサービス・レベルを表示し、保障されている乗客が、選択された乗客数、最大の支払金、およびサービス・コストを表示するであろう。

動作において、乗客３５は、同じ旅行における１人または複数人の乗客のために購入するサービスのレベルを選択する。乗客３５は、保障のレベルを選択する。乗客３５は、航空会社確認番号、出発航空会社、および出発便を含む基本的な旅行情報を提供する。乗客３５は、旅行中の乗客数を選択する。乗客情報は、各乗客につき１行として表示する。乗客３５は、この旅行におけるサービス合意によって保障されている各乗客の氏名、および電子メール・アドレスを入力する。乗客３５は、支払い処理を開始するためにチェックアウトしうる。

支払い処理が正しくなされると、システム１００は、ＹＹＸＸＸＸＸＸＸＸの形態からなるＩｄを有する新たなサービス合意を、データベース４３内に作成するであろう。ＹＹは、チケット販売者を指定するであろう。チケット販売者の指定は、乗客によって直接的に購入されたサービス合意の場合、ＰＡでありうる。Ｉｄの残りの部分は、自動的にインクリメントされる数である。（スクリーン・レベルにおいてのみであって、データベース・レベルではない）可視化の目的のために、数値部分が、合計８桁を完成させるために、ＰＡ０００００００４のように、残りをゼロとして完成されるであろう。将来、数値部分が８桁を超えるのであれば、ＰＡ１２３４５６７８９のように、直接的に示されるであろう。

フィールドは、このサービス合意が、乗客３５によって直接的に購入されたことを示すサービス合意記録に存在するであろう。

図２に示すように、システム１００は、ショッピング・カート購入が正しくなされた後、この保障に含まれる乗客３５への電子メール確認２５５を生成する。支払い処理が失敗した場合、システム１００は、監査証跡セクションにおいて示されたようなその原因を記録し、サービス合意記録はデータベース４３に保存されないであろう。

本開示の乗客購入処理が、図２に図示され、一般に参照番号２００によって表わされる。処理２００は、システム１００を含んでいる。このシステム１００は、図１に図示されるように、データベース４３にリンクされたコンピュータ４０を含んでいる。図１に図示されるように、システム１００は、１つまたは複数のユーザ・デバイス３４を含んでおり、これらのおのおのは、例えばインターネットのようなネットワーク５０に通信可能に結合されており、ネットワーク５０を介して実行される通信は、電子信号または光信号による。システム１００の重要性は、それが、航空会社、および契約プロバイダ、または保障の所有者へ、リアル・タイム情報を提供することである。したがって、多くの航空会社から、旅行の異なる「飛行区間」とともに、乗客および荷物の情報を追跡することと、これら飛行区間とともに移動する荷物が保証されているか否かが、判定されうる。さらに、保障されている荷物が紛失し、荷物を運搬または搬送した航空会社によってそのように宣言されると、契約プロバイダまたは所有者に通知され、その後、紛失した荷物の所有者に対して支払いを行いうる。

乗客は、紛失された荷物の補償を受け取るために、支払いを受け取る前に、契約プロバイダに、与えられた荷物受取タグと、チケット控えのコピーとを提出しなくてはならない。これら書類が提示されると、契約プロバイダによる確認が、航空会社と直接的に行われる。確認は、電話、電子メール、または、その他任意の通信方法によってなされうる。あるいは、契約プロバイダは、この処理が、契約プロバイダによって自動的に行われることを可能にするであろう、データベースまたはその他いくつかの自動化システムを、航空会社と確立している。

契約プロバイダは、米国国内の航空便における荷物の紛失に関するサービス合意を提供する。このサービス合意によって、購入者は、本明細書においてプレミアムと定義されている異なる保障額を選択することが可能となる。サービス合意は、航空会社予約中における１つ、いくつか、またはすべての乗客を保障しうる。乗客３５は図２および図３に例示されるように、サービス合意を購入した顧客である。

サービス合意プレミアムは、事前に決定された額に設定される。例えば、この額は、５．００ドルのプレミアムの場合、１つのバッグ当たり１０００ドル、７．５０ドルのプレミアムの場合、１つのバッグ当たり１５００ドル、または１０．００ドルのプレミアムの場合、１つのバッグ当たり２０００ドルである。プレミアムは、乗客毎ベースであることが想定されているが、他のレート・ベースも適用されうる。旅行を形成または備えるセグメントの数は、プレミアムに影響を与えない。

一般的なサービス合意は、以下を含んでいると想定される。サービス合意は、空港到着時にチェック・イン・カウンタにおいて乗客によってチェックされたすべてのバッグを保障する。紛失が宣言されると、契約プロバイダは、サービス合意に基づいて、乗客毎に最大２つのバッグのような、予め決定された数のバッグのみを保障する。乗客３５は、図４に例示されるように、誤取扱荷物レポートを、契約プロバイダに申告するために、航空便到着の日付から４日のような、予め決定された期間を有する。誤取扱荷物レポートは、行方不明なバッグの場合、乗客３５またはスタッフ・メンバ４１０が申告するレポートである。誤取扱されたバッグは、乗客３５が目的地に到着した場合、回転台に届けられないバッグである。紛失したバッグは、４日のように、航空便到着後、予め決定された長さの時間内に乗客３５に戻らなかった、誤取扱されたバッグである。バッグが紛失したか否かの判定は、航空会社または空港によってなされ、契約プロバイダによってはなされない。

１つのプレミアムは、一時降機の数に関わらず、乗客３５のための往復チケットを保障する。図７に例示されるように、誤取扱されたバッグが、予め決定された時間内に戻らないのであれば、契約プロバイダは、紛失を宣言し、乗客３５に対して支払いを行う。バッグの中身の証明は、必要とされないであろう。誤取扱荷物レポートは、図４に例示されるように電話３０５によって、または、図５に例示されるように、ユーザ・インタフェースまたはユーザ・デバイス３４を介して、オンラインによって、乗客３５によって、単純かつ容易に提出されうる。

顧客は、サービス合意を購入すると決定すると、航空会社確認において、所望の保障のレベルと、乗客数とを選択する必要がある。このプレミアムは、契約プロバイダによって直接的に、また、準拠法にしたがって請求される。

乗客３５は、ウェブサイトから直接的に、または、旅行代理店３５０を通じて、サービス合意を購入しうる。旅行代理店３５０は、彼らの顧客のためにサービス合意を購入しうる代理人である。サービス合意番号は、サービス合意のためのユニークな識別子である。

図３を参照して、旅行代理店購入処理３００が例示される。図３を参照して、システム１００は、旅行代理店３５０への電子メール３５５と、ショッピング・カート購入が成功した後に保障に含まれる、乗客３５への電子メール３５６確認とを生成するであろう。支払い処理が正しくなされなかった場合、システム１００は、監査証跡セクションにおいて示されたようなその原因を記録し、サービス合意記録はデータベース４３に保存されないであろう。

旅行代理店３５０は、購入されたサービス合意に関する情報を編集／変更することはできないであろう。

旅行代理店３５０は、購入されたサービス合意に関するサービス合意詳細を閲覧できうる。例えば、サービス合意詳細は、ポップ・アップ・ボックス内に示されうる。

旅行代理店３５０は、購入された特定のサービス合意を探索することができうる。ユーザ・インタフェースによってこれがなされる１つの手法は、乗客の姓、および／または、名、および／または、サービス合意番号を入力することによる。マッチするサービス合意が示されるであろう。

支払い処理は、クレジット・カード情報のような乗客の機密情報を取り扱うすべての詳細を、専門化された信頼できる評判を持つサード・パーティ企業に委託するために、外部支払ゲートウェイ６０を用いて実施されうる。

システム１００は、いかなる機密情報をもローカルに記憶することはないであろう。このトランザクションによって必要とされるすべての情報は、支払いゲートウエイ・サイトへ安全に渡されるであろう。苦情がある場合、支払いトランザクションを特定するための情報のみが記憶されるであろう。これは、例えば、クレジット・カードの最初の２桁および最後の４桁、または、ＰＣＩコンプライアンスを準拠する形式における任意の基本情報を含みうる。

旅行代理店サービス合意購入および管理スクリーンによって、事前登録された旅行代理店３５０は、クライアントのためのサービス合意を購入できるようになる。さらに、旅行代理店３５０は、以前に購入したすべてのサービス合意を閲覧できうる。フィールドは、サービスのレベル、航空会社、確認番号、出発航空会社、出発航空便番号、乗客数、乗客の情報、名、姓、電子メール・アドレスおよび探索を含みうる。

動作では、旅行代理店３５０は、同じ旅行における１人または複数の乗客のための購入のために、サービスのレベルを選択する。旅行代理店３５０は、保障のレベルを選択する。旅行代理店３５０は、航空会社確認番号、出発航空会社、および出発航空便を含む基本的な旅行情報を提供しうる。旅行代理店３５０は、旅行における乗客数を選択する。乗客情報は、各乗客につき１行で表示される。旅行代理店３５０は、旅行に関するサービス合意によって保障される各乗客の名、性、および電子メール・アドレスを入力する。旅行代理人３５０は、チェックアウトし、支払処理を開始しうる。

支払い処理が正しくなされると、システム１００は、ＹＹＸＸＸＸＸＸＸＸの形態からなるＩｄを用いて、データベース４３内に新たなサービス合意を生成する。ＹＹは、チケット販売者を指定する。チケット販売者の指定は、例えば、トラベル・リーダーズ旅行代理店によって購入されたサービス合意の場合、ＴＬでありうる。Ｉｄの残りの部分は、自動的にインクリメントされる数である。（スクリーン・レベルにおいてのみであって、データベース・レベルではない）可視化の目的のために、数値部分が、合計８桁を完成させるために、ＴＬ０００００００４のように、残りをゼロとして完成されるであろう。将来、数値部分が８桁を超えるのであれば、ＴＬ１２３４５６７８９のように、直接的に示されるであろう。

フィールドは、このサービス合意が、乗客の代わりに旅行代理店によって購入されたことを示すサービス合意記録内に存在するであろう。

図３および図４に示すように、乗客が目的地に到着した場合に、１つまたは複数のバッグが、空港の荷物回転台に届けられていないのであれば、乗客は、コンピュータ４０によってサービス提供されているウェブサイト、または契約プロバイダ電話線３０５を用いて、誤取扱荷物レポートを申告する。乗客３５は、サービス合意番号、航空会社からの荷物受取所における各バッグのバッグ・タグ番号、および、航空会社に申告した請求からの参照番号、を提供する必要がある。タグ番号およびファイル参照番号は、航空会社に申告された紛失荷物請求の、航空会社が発行したユニークな識別子である。個人情報は、乗客３５が、航空会社に請求するために使用した個人情報と一致しなければならない。

誤取扱荷物レポートを電話によって申告するステップは、一般に番号４００によって示されるような、電話処理による誤取扱荷物レポートとして図４に例示されている。

誤取扱荷物レポートをウェブ・サイトによって申告するステップは、図５に例示されており、誤取扱荷物レポート処理のプロセスは、図６に図示されている。図５に示すように、ウェブサイトによる誤取扱荷物レポートは、一般に、番号５００によって参照される。

図６に図示されるように、誤取扱荷物レポートが申告されると、スタッフ・メンバ４１０が、航空会社オペレータ６５０にコンタクトし、申告処理中に提供された情報が有効であり、誤取扱荷物レポートが適切であることを確認する。スタッフ・メンバ４１０は、誤取扱荷物レポートの処理およびモニタリングを担当する契約プロバイダ係員である。誤取扱荷物レポートを処理するステップは、一般に、番号６００によって示され、図６に例示されている。

誤取扱荷物レポートが有効であれば、スタッフ・メンバ４１０は、荷物または手荷物が発見されたか否かを判定するために、日常の航空会社オペレータ６５０にコンタクトするであろう。荷物が、予め定められた期間内に発見されない場合、スタッフ・メンバ４１０は、誤取扱荷物レポートは、紛失と宣言されるべきであると判定する。誤取扱荷物レポート処理において、紛失を宣言するステップは、一般に、番号７００によって示され、図７に例示されている。

システム１００は、注目、管理、システム機能、バックグランド・タスク、レポート、およびダッシュボードからなるいくつかの主要なエリアを有する。管理エリアは、機能的な処理のための基礎を提供することが意図されたスクリーンである。これらのスクリーンは、日常のプロダクション用途以外のメンテナンス目的のために、より使用されることが意図されている。システム機能スクリーンは、ユーザ・コミュニティによる日常作業を支援する。バックグランド・タスクは自動的に実行される処理である。ダッシュボード・スクリーンは、スタッフ・マネジャ６１０およびスタッフ・メンバ４１０に、キー情報を提供する。図６に図示されるように、スタッフ・マネジャ６１０は、キー・ビジネス情報のみならず、管理システム１００にもアクセスできる契約プロバイダ係員である。

主な管理モジュールは、ユーザ管理、航空会社管理、旅行代理店管理、システム・パラメータ管理を含む。

主なシステム機能モジュールは、サービス合意購入、誤取扱荷物レポートの申告、および誤取扱荷物レポートの処理を含む。

主なダッシュボード・モジュールは、サービス合意および誤取扱荷物レポートの統計を含む。

本開示のシステム１００および方法は、現在、一般に認められている規格ベースの開発方法、ツール、およびソフトウェアを用いて開発されたコンピュータ・システムを使用する。適切な権利保護および／または許可が、アプリケーション・ソフトを維持する能力を保証する。

ウェブ・ベースのソリューションは、何十万ものユーザによって使用されるであろうから、企業レベルの、ミッション上重要な、非常に高いパフォーマンスのデータベース設計と、ｎ層システム・アーキテクチャとを必要とすることが想定される。重要な機能が、高いパフォーマンスを必要とする場合、記憶された手順に、ＳＱＬクエリが含まれうる。単純に設計されたアーキテクチャを念頭に置くことが望ましい。

１つの実施形態では、コンピュータ４０は、ＡＳＰ．ＮＥＴ／Ｃ＃ウェブ・ベースのシステムになりえる。また、ＳＱＬサーバは、データベース４３として使用されうる。ウェブ・ページへのアクセスは、ＨＴＴＰＳ（安全なプロトコル）でありうる。データベース４３は、トラザクション反復をサポートするための適切な参照保全性を有するべきである。

ユーザのアクションに関連するデータ４９は、データベース４３に記録され、以下のフィールドを含むべきである。生成された日付けおよび時間の記録、記録が生成された場合に埋められねばならない記録生成部の識別情報、最後に修正された日付けおよび時間の記録、記録が更新される毎に更新されねばならない記録修正部の識別情報。

パブリック・スクリーンは、一般に知られているウェブ・ブラウザおよび規格を用いて編集および表示をサポートすべきである。

データ・エントリは、データ・エントリに誤りがないことを保証する既知の検証方法を利用すべきである。例えば、電話番号は、最大２０のキャラクタを含み、郵便番号は、最大９のキャラクタを含み、電子メールは、ｘｘｘ＠ｘｘｘ．ｘｘｘのような適切なフォーマットである。

本開示のシステム１００は、規格および周知のセキュリティ対策を使用すべきである。乗客固有の情報を示すあらゆるスクリーンが、ＳＳＬ制御下になければならない。有効でユニークなユーザ名およびパスワードを入力したユーザだけが、システムの安全な領域にアクセスできうる。このアプリケーションは、最初にログインしなければ、誰も安全な領域にアクセスできないように設計および開発されねばならない。

システム１００に加えられた各ユーザは、ユーザ・タイプを割り当てられるであろうことが想定される。ユーザ・タイプは、特定のアプリケーション許可のグループを命名される。各ユーザ・タイプは、システム内のさまざまなスクリーンおよび処理にアクセスすることを許可または拒否されるであろう。ユーザに割り当てられたユーザ・タイプは、そのユーザのシステム１００内の権利および権限を決定する。ユーザが、システム１００内の各スクリーンを訪れることを試みると、アプリケーションは先ず、ユーザが、適切なアクセス権利を許可されたユーザ・タイプに属しているか否かをチェックする。

ログインするために、ユーザは、有効なユーザ名およびパスワードを入力する。システム１００によって有効化されると、システムは、そのユーザのための初回ではないのであれば、許可されたスクリーンを示す。初回のユーザである場合、ユーザは、新たなパスワードを提供することを要求される。ユーザのパスワードが、少なくとも１つのアルファベットと、１つの数値と、大文字のアルファベット・キャラクタのうちの少なくとも１つを備える１つの特別なキャラクタとを有する、少なくとも８つのキャラクタを含んでいることが想定される。

管理スクリーンは、新たなユーザの追加と、ユーザ・タイプの各ユーザへの割り当てとを行うための機能を含む、システムにおけるユーザの管理を可能にする。セキュリティ制限が、ユーザ・タイプに関連付けられる。ユーザがアクセスを有するスクリーンが、ユーザ・タイプによって制限され、そのユーザ・タイプ情報が、データベースに記憶されるであろう。ユーザは、予め定められたグループと、ユーザ・タイプに関連付けられた基準とに基づいて、探索を実行する能力を有する。

ユーザへ割り当てられうる１つのそのようなユーザ・タイプは、旅行代理店である。旅行代理店ユーザ・タイプに関連付けられた情報は、以下を含むべきである。旅行代理店名、旅行代理店コード、旅行代理店ｉｄ、および事業単位。

航空会社は、システム１００において管理されうる。管理者は、要求されたすべての航空会社情報をシステム１００に入力することによって、新たな航空会社を追加するか、または、既存の航空会社を編集しうる。航空会社情報は、図５および図６に関する誤取扱荷物レポートの申告および処理のために必要とされるであろう。

図１、図２、および図３を参照するように、支払ゲートウェイ６０は、既知の仮想荷主のうちの誰かでありうる。支払処理は、支払ゲートウェイ会社によって提供されるＡＰＩへ、安全なコールによって実行されるであろう。トランザクション処理は、乗客購入サービス合意スクリーンから開始されうる。請求額が、スクリーン上に図示されねばならない。

本開示のシステム１００において提供されているものは、誤取扱荷物レポート申告フォームである。このフォームは、ユーザ・インタフェースを介してアクセス可能であり、この処理は、図５に例示されている。このスクリーンは、航空便が到着した時に、荷物回転台において荷物が発見されない場合に、乗客３５に、誤取扱荷物レポートを申告する機能を提供する。乗客３５は、誤取扱荷物レポートを申告する前に、誤取扱荷物レポートを航空会社に申告することを要求される。誤取扱荷物レポートを申告するために、申告参照番号が要求される。

誤取扱荷物レポート申告フォーム・スクリーンは、契約プロバイダのホームページから、または、電子メールで提供されたダイレクト・リンクから開始されうる。フィールドは、到着航空便番号、航空会社、航空便到着日、航空便到着時刻、タイム・ゾーン、紛失したバッグ番号の申告参照番号、荷物タグ番号、サービス合意番号、名前、住所、都市、国、州、郵便番号、電話番号を含みうる。

動作において、乗客３５は、誤取扱荷物レポートを申告する。乗客３５は、以下を含む航空便情報を提供するであろう。到着航空便番号、航空会社、航空便到着日、時間、およびタイム・ゾーン。乗客３５は、申告参照番号を含む請求情報を提供する。乗客３５は、紛失したバッグの数、または、荷物タグ番号（少なくとも１つ）およびサービス合意番号を選択する。乗客３５は、名前、住所、市、州、国、郵便、電話、電子メール・アドレス、および電子メール・アドレス確認を含む個人情報を、紛失荷物請求に表示されるように正確に提供する。

乗客３５が、レポートを申告し、誤取扱荷物レポートを登録することを選択した後、確認ダイアログが、表示されねばならない。乗客３５が、第２のレポートの申告を望んでいるのであれば、別の誤取扱荷物レポートするための、新たなブランク・フォームが表示され、処理が反復する。そうではない場合、乗客３５は、契約プロバイダのホームページへリダイレクトされる。

誤取扱荷物レポートが申告された場合、システム１００は、形式ＭＢＲＸＸＸＸＸＸＸからなるＩｄを用いて、新たなレポートをデータベース４３内に生成する。ＭＢＲは、誤取扱荷物レポートを意味し、Ｉｄのリネーム部分は、自動的にインクリメントされる数と、新規として設定されたステータスであり、どのスタッフ・メンバ４１０にも割り当てられていないことを示すフィールドと、レポートが乗客３５によって直接的に申告されたことを示すフィールドである。（スクリーン・レベルのみにおいてであって、データベース・レベルにおいてではない）視覚化目的のために数値部分が、合計７桁、すなわちＭＢＲ００００００４を完成させるために、残りをゼロとして完了されるであろうことが想定される。将来において、数値部分は、７桁を超えるのであれば、すなわちＭＢＲ１２３４５６７８のように直接的に図示されるであろう。

システム１００は、乗客３５が、誤情報を修正するために、誤取扱荷物レポートを正しく再申告した場合、図６に図示されるように、スタッフ・マネジャ６１０への電子メール通知（および、スタッフ・メンバ４１０のその他の指定された電子メール・アドレス）を生成する。指定された電子メール・アドレスのリストは、前述されたシステム・パラメータ管理セクションにおいて設定されうる。

図４および図５に示すように、システム１００は、誤取扱荷物レポートが正しく提出された場合、誤取扱荷物レポートを申告した乗客３５への電子メール確認４５５を生成する。

システム１００は、乗客３５が、誤取扱荷物レポートを正しく入力した場合、スタッフ・マネジャ６１０への電子メール確認４５６（および、スタッフ・メンバ４１０のように、指定されたその他任意の電子メール・アドレス）を生成する。指定されたリスト。指定された電子メール・アドレスのリストは、システム・パラメータ管理セクション内に設定されうる。

ユーザ・インタフェースは、契約プロバイダ電話線３０５にコンタクトしたこれら乗客３５のための誤取扱荷物レポートを、スタッフ・メンバ４１０が申告するスクリーンを提供する。このスクリーンは、乗客３５が、誤取扱荷物レポートを申告する場合と類似しているべきである。

ユーザ・インタフェースはまた、誤取扱荷物レポート処理を取り扱うための補助スクリーンとして、誤取扱荷物レポートをリストする機能を、スタッフ・メンバ４１０およびスタッフ・マネジャ６１０に提供するスクリーンでもある。このスクリーンは、契約プロバイダ管理サイト・メニューから開始されうる。スタッフ・マネジャ６１０のための初期スクリーン状態は、スタッフ・メンバのための初期状態とは異なりうる。

電子メール・アドレスは、システム・パラメータ管理セクション内に設定されうる。

システム１００は、電算機処理監査記録を保存する。

本開示のシステム１００は、乗客３５に、申し出における誤りを通知するであろうことが想定される。乗客３５は、誤報通知を受信し、次に、いかなる誤り情報をも訂正できうる。誤りの例は、限定される訳ではないが、ファイル参照番号がブランクであること、荷物タグ番号がブランクであること、サービス合意番号がブランクであること、または、サービス合意番号が正しくないことを含む。

乗客３５が、誤取り扱い荷物レポートを誤って申告した場合、乗客は、いくつかの情報が航空会社請求情報に一致していないことを述べる電子メール通知６５５を受信するであろう。乗客３５は、正しい情報をスタッフ・メンバ４１０に提供するために、契約プロバイダ０８００番をコールするか、または、乗客は、情報を訂正するように依頼された場合、乗客をユーザ・インタフェース・スクリーンに導く、通知電子メールで提供された安全なリンクをクリックしうる。例えば、誤った情報は、赤で強調されうるであろう。誤った情報を持つフィールドのみが、編集可能となるであろうことが想定される。例えば、残りすべてのフィールドは、スタッフ・メンバ４１０によって航空会社に対してすでに検証されている情報を乗客３５が変更することを阻止するための情報を示す。これは、単なるラベルであろう。

乗客３５は、正しい情報を送信するために、レポートを再申告することを選択し、このレポート・ステータスを新規であると再び設定し、通知ダイアログが表れる。乗客３５は、契約プロバイダのホームページへとリダイレクトされる。確認電子メール５５０が、乗客３５へ送られる。

図４に示すように、スタッフ・メンバ４１０は、契約プロバイダ電話線３０５を介してコンタクトした乗客３５のための誤取扱荷物レポートを申告しうる。スタッフ・メンバ４１０は、到着航空便番号、航空会社、航空便到着日、時間、およびタイム・ゾーンを含む乗客の航空便情報を提供する。スタッフ・メンバ４１０は、ファイル参照番号、荷物タグ番号（少なくとも１つ）、およびサービス合意番号を含む乗客の請求情報を提供する。スタッフ・メンバ４１０は、名前、住所、市、国、州、郵便、電話、電子メール・アドレス、および電子メール・アドレス確認を含む乗客の個人情報を、航空会社とともに紛失荷物請求上に表されているように正確に提供する。

スタッフ・メンバ４１０は、誤取扱荷物レポートを登録するための申告レポートを選択し、確認ダイアログが表われる。スタッフ・メンバ４１０が望むのであれば、別の誤取扱荷物レポートを申告するための新たなブランク・フォームが表わされ、処理が反復する。そうではない場合、スタッフ・メンバ４１０は、スタッフ・メンバのホームページへリダイレクトされる。

誤取扱荷物レポートが申告された場合、システム１００は、形式ＭＢＲＸＸＸＸＸＸＸからなるＩｄを用いて、新たなレポートをデータベース４３内に生成する。ＭＢＲは、誤取扱荷物レポートを意味し、Ｉｄのリネーム部分は、自動的にインクリメントされる数と、新規として設定されたステータスであり、どのスタッフ・メンバ４１０にも割り当てられていないことを示すフィールドと、レポートがスタッフ・メンバによって直接的に申告されたことと、誰がそのスタッフ・メンバであったかとを示すフィールドである。（スクリーン・レベルのみにおいてであって、データベース・レベルにおいてではない）視覚化目的のために数値部分が、合計７桁、すなわちＭＢＲ００００００４を完成させるために、残りをゼロとして完了されるであろうことが想定される。将来において、数値部分は、７桁を超えるのであれば、すなわちＭＢＲ１２３４５６７８のように直接的に図示される。

動作において、スタッフ・メンバ４１０またはスタッフ・マネジャ６１０は、特定のフィルタリング基準を用いて、誤取扱荷物レポートを探索しうる。スタッフ・メンバ４１０またはスタッフ・マネジャ６１０は、基準を意のままに組み合わせることによって、探索フォームに情報を提供し、探索結果を見ることを選択しうる。スタッフ・メンバ４１０またはスタッフ・マネジャ６１０は、この結果を印刷するか、または、現在の基準および指示に関する探索結果の内容とともに、例えばＰＤＦファイルのようなファイルを生成し、開きうる。スタッフ・メンバ４１０またはスタッフ・マネジャ６１０は、探索結果における内容のＣＳＶファイルのようなファイルをエクスポートしうる。スタッフ・メンバ４１０またはスタッフ・マネジャ６１０が、ファイルを保存したい場所を選択するためのメッセージ・ウィンドウが表われるであろう。ファイルは、選択された場所へ保存されるであろう。スタッフ・メンバ４１０またはスタッフ・マネジャ６１０は、フォームをクリアし、探索ページを、初期状態にリセットしうる。

スタッフ・マネジャ６１０は、誤取扱荷物レポートを、単独で、またはバッチで、スタッフ・メンバ４１０へ割り当てうる。スタッフ・マネジャ６１０が、誤取扱荷物レポートを、特定のスタッフ・メンバ４１０へ割り当てたいと思っている場合、スタッフ・メンバは、割り当てるための誤取扱荷物レポートを選択するであろう。

誤取扱荷物レポート詳細スクリーンは、スタッフ・メンバ４１０およびスタッフ・マネジャ６１０に、誤取扱荷物レポートに関する情報および状況を観察および編集する機能を提供する。

誤取扱荷物レポート詳細スクリーンは、誤取扱荷物レポートが、誤取扱荷物レポート・ルックアップ・スクリーンにおいて選択された場合に開始されると想定される。誤取扱荷物レポート詳細は、選択された誤取扱荷物レポートのために知られているすべての情報で占められる。割り当てられたスタッフ・メンバ４１０をレポートが有しているのであれば、レポートがそのスタッフ・メンバに設定され、そうでない場合には、レポートは、未割当に設定される。現在のユーザが、スタッフ・メンバ４１０であるが、そのレポートに割り当てられたプロセッサではないのであれば、すべての制御がロックされ、ボタンが不能とされるであろう。有効化された制御とボタンのみが、プロセッサを割り当てるものとなるであろう。現在のユーザが、このレポートに割り当てられたスタッフ・メンバ４１０、または、スタッフ・マネジャ６１０であれば、さらなる制御およびボタンが有効とされるであろう。フィールドは、プロセッサ、サービス合意番号、誤取扱荷物レポート番号、航空会社、確認番号、航空会社、航空便番号、航空便到着日、航空便到着時刻、タイム・ゾーン、ファイル参照番号、紛失バッグ番号、荷物タグ番号（ｎ）、戻り（ｎ）、および乗客者氏名を含みうる。

スタッフ・メンバ４１０またはスタッフ・マネジャ６１０は、レポート詳細セクションにおける情報を修正できうる。スタッフ・メンバ４１０またはスタッフ・マネジャ６１０は、ユーザ・レコードに変更を加えることができうる。

保存する場合に、システム１００は、電算機処理監査記録をログするであろう。

スタッフ・メンバ４１０またはスタッフ・マネジャ６１０は、注釈を加えることができうる。スタッフ・メンバ４１０またはスタッフ・マネジャ６１０は、注釈テキスト領域に、注釈を入力できうる。注釈を保存する場合に、システム１００は、電算機処理監査記録をログするであろう。

スタッフ・メンバ４１０またはスタッフ・マネジャ６１０は、レポートを、自己へまたは別のプロセッサへ割り当てうる。この割り当てを保存する場合に、システム１００は、電算機処理監査記録をログするであろう。

レポート情報が正しいことを検証した後、スタッフ・メンバ４１０またはスタッフ・マネジャ６１０は、レポート・ステータスをオープンに変更しうる。ステータスを変更する場合に、システム１００は電算機処理監査記録をログするであろう。

レポート情報が正しくないことを検証した後、スタッフ・メンバ４１０またはスタッフ・マネジャ６１０は、レポート・ステータスを誤情報に変更しうる。スタッフ・メンバ４１０またはスタッフ・マネジャ６１０は、誤った情報に対応するステータス・フレームに図示されているすべてのチェックボックスをマークしうることが想定される。スタッフ・メンバ４１０またはスタッフ・マネジャ６１０は、誤った情報があることを示しうる。システム１００は、ステータス変更を保存し、レポートが、誤情報状態にある間、スクリーンがアクセスされるたびに、正しくないフィールドが、例えば赤で示されることによってフラグされるであろう。システム１００は、乗客へ電子メール５５５を送信し、誤った情報を訂正するように要求する。ステータスを変更する場合に、システム１００は電算機処理監査記録をログする。

バッグが制限日よりも前に見つけられたことを確認した後、スタッフ・メンバ４１０またはスタッフ・マネジャ６１０は、レポート・ステータスをクローズに変更しうる。

システム１００は、乗客３５に電子メール７５０を送信し、レポートがクローズされたことを示す。ステータスを変更する場合に、システムは電算機処理監査記録を再びログするであろう。

バッグが制限日よりも前に見つけられなかったことを確認した後、割り当てられたスタッフ・メンバ４１０またはスタッフ・マネジャ６１０は、レポート・ステータスを紛失に変更しうる。スタッフ・メンバ４１０またはスタッフ・マネジャ６１０は、例えば、ユーザ・インタフェースを介して紛失ボタンをクリックすることにより、そうすることができる。チェック・メカニズムとして、紛失ボタンがクリックされ、すべての荷物タグ番号が戻されたものとしてチェックされた場合、エラー・メッセージが示されるであろうことが想定される。１つまたは複数の荷物タグ番号が、チェックされていないリターン・チェックボックスを有しているのであれば、確認ダイアログ、「支払いに適するものとして、＜ｎ＞個のバッグを設定して下さい。処理を続けますか？（はい）（いいえ）」が表われることが想定される。＜ｎ＞値は、１つのバッグしか戻っていないとして設定された場合に１となり、２つ以上のバッグが戻っていないとして設定された場合、（システム・パラメータにしたがって）２となるであろう。システム１００は、乗客に電子メールに７５５を送り、レポートが支払いに適することを示す。システム１００は、契約プロバイダに電子メール７５６を送り、レポートが支払いに適することを示す。ステータスを変更する場合に、システム１００は、電算機処理監査記録を再びログする。

図３に示すように、旅行代理店３５０が契約プロバイダに登録することを可能にするスクリーンが、ユーザ・インタフェースを介して提供される。登録されると、旅行代理店は、自分たちのクライアントの代わりに、サービス合意を購入することができうる。

契約プロバイダは、イントラネット・サイトに配置されるためのリンクを、旅行代理店ビジネス・グループに提供しうる。旅行代理店は、このリンクから、契約プロバイダ登録フォームにアクセスしうる。このリンクは、すべての旅行代理店ビジネス・グループについて同じであるだろう。そして、旅行代理店は、登録処理の一部として、自分たちがどの事業単に属しているのかを選択するであろう。

旅行代理店３５０は、旅行代理店イントラネット・サイトにおいて提供されたリンクをクリックした後、登録フォームにアクセスすることが想定される。旅行代理店３５０は、必要とされるすべての情報と、条項および条件に対して合意することと、を提供する。その後、旅行代理店３５０は、保存を押さねばならない。システム１００は、旅行代理店タイプとしてユーザを作成し、登録が旅行代理店によって確認されるまで、それをペンディング状態にする。システム１００は、登録処理を確認するためのリンクを備えたウェルカム・メッセージを含む電子メールを旅行代理店３５０に送信する。旅行代理店３５０は、明確なパスワードを提供し、彼らのユーザをアクティブにするために、電子メールで提供された確認リンクにしたがわねばならない。それを行った後に、旅行代理店ユーザは、ペンディングの代わりにアクティブになり、システム１００にログインすることが可能になるであろう。この確認リンクは、例えば５日間のように、システム・パラメータとして設定された制限された期間の間、有効になるであろう。その期間の後、リンクをクリックし、明確なパスワードを提供することによって、旅行代理店が未だに登録を確認していないのであれば、ペンディング状態にあるユーザが、データベースから削除され、リンクが無効とされるであろう。

契約プロバイダの製品は、以下のように動作する。航空会社によってモニタされた航空会社の乗客の荷物に対し、予め定められれた保障額について、荷物毎に額が請求されるであろう。荷物が航空会社によって紛失されたと認められるのであれば、乗客は、予め定められた額を支払われるであろう。乗客は、荷物の項目または中身の価値を証明する必要はないであろう。すべての損失は、予め決定された同じ額を支払われるであろう。紛失荷物の請求は、バッグが本当に紛失し、紛失したと認められると航空会社が判定するのに十分な時間である第１の設定期間後に、乗客によって行われうる。好適には、この第１の期間は、１か月になるであろう。しかしながら、３週間のように若干短い期間、または、４５日乃至６０日（２か月）のようなより長い期間が選択されうる。この第１の期間が経過し、荷物が発見されていないと仮定された後、乗客は、請求するための第２の期間を有するであろう。この第２の期間は、第１の期間よりも長い。乗客が請求しなければならない期間に制限があるだろう。

請求の提出は、単に数分しかかからないであろう。乗客は、許可されたプロバイダが、チェックイン時に乗客に提示した荷物受取タグを用いて、契約プロバイダにコンタクトするであろう。契約プロバイダは、航空会社に瑕疵があることを、航空会社とは独立して確認するであろう。そのケースであれば、契約プロバイダは、乗客に、予め定められた額を支払うであろう。

契約プロバイダは、２つの方式のうちの１つで、乗客にそのプレミアムを請求するであろう。先ず、プレミアムは、チケット購入の間に、チケット・プロバイダによって請求される。あるいは、乗客は、契約プロバイダまたはブローカから、または、保障を販売することを許可された独立した販売員、したがって、許可されたすべてのプロバイダから、直接的に保障を購入しうる。乗客は、もしもそうすることを選ぶのであれば、この保険を購入することを断る選択権を有するであろう。

乗客は、チケット購入時、またはその後の何れかにおいて荷物保障を購入するであろうが、何れのケースにおいても、プレミアムは、乗客が、航空会社モニタリング・システムに自分の荷物を手渡す前に、認可されたプロバイダによって受け取られねばならない。この保障のプレミアムは、旅行キャンセルの場合でさえ、払い戻しできない。プレミアムは、乗客が、各方向における無制限の一時降機を伴う旅行の各飛行区間において、ともに移動する、モニタされた荷物を保障するであろう。現在、航空会社は、チェック・インされた荷物のみをモニタしている。

別の実施形態では、チケット購入時に、乗客は、航空会社がチェックするバッグの数を知ることはないであろう。ほとんどの航空会社は、乗客に対して、チェック・インされる２つのバッグとともに移動することしか許可しないであろうから、契約プロバイダは、２つのみのバッグが保障されるであろうことを指定し、好んで指定するであろう。航空会社がより多くのバッグを保障したいことを乗客が知っているのであれば、荷物が航空会社によってモニタされている限り、追加の荷物が、追加のプレミアムのために、保険に追加されうる。

第３の荷物がチェック・インされるイベントでは、第３の荷物は、航空会社が荷物のモニタリングを開始する場合に、航空会社によって、割り当てられる最も大きなシリアル番号、バー・コード、または、印を持つ荷物となるであろう。

今後、シリアル番号を使用することができないのであれば、航空会社が用いる荷物を特定するための別の手法がありうる。その状況では、航空会社のコンピュータ・システム４００によって、バッグを別のバッグと区別するために使用される別の識別「印」があるであろう。

契約プロバイダの保障が、同時に購入される複数のチケットの場合、割引料金が適用されうる。

本開示の別の態様は、荷物が、航空会社モニタリング・システム外で考慮されるという態様である。それは旅行の飛行区間をも含みうる。現在、複数の航空便は、航空便毎に数時間降機することが標準的である。単一の飛行区間と、複数の飛行区間とを区別するために、任意の時間において、荷物が航空会社のモニタリング・システムから外れると、個別のプレミアムがあるであろう。

乗客が、単一の航空会社での単一の航空便に搭乗しており、その航空便が、短期間止まるのであれば、荷物は、航空会社モニタリング・システムの制御下にあると考えられる。しかしながら、乗客が、１つの場所から別の場所への接続便が予約されているのであれば、それは、荷物を、ある期間、航空会社のモニタリング・システムから外しうる。

航空会社モニタリング制御システム内に残る荷物と、航空会社モニタリング制御システムを出る荷物とを有効にする中継地を区別するために、（１つは、中継地よりも前であり、他は、中継地よりも後である）２つの飛行区間が、例えば（到着から出発まで）５時間以上のような非常に長い時間によって分離されている何れの航空便も、航空会社が荷物のモニタを継続しているか否かに関わらず、航空会社モニタリング・システム外であると考慮されるであろう。したがって、５時間は、任意に選択されている。さらに、航空会社、または、１つの場所から別の場所への荷物の移動の変更がある状況がある。これは、航空会社モニタリング・システム外であると考えられうる。

例として、通常は、旅行の各飛行区間は、個別のプレミアムを請求されるだろう。典型的な航空便は、２つの飛行区間を有するであろう。２つ以上の飛行区間が存在するのであれば、追加のプレミアムが、同じ規則にしたがって請求されるであろう。

例示的な目的のための例として、
飛行区間１ − 乗客Ａは、ニューヨークからクリーブランドへ飛び、クリーブランドに一晩、すなわち５時間以上、滞在する。

飛行区間２ − その後、この乗客は、ロサンゼルスへ行く途中、シカゴへ飛び、２時間一時降機する。この一時降機の間、乗客は、自分の荷物を戻されない。

飛行区間３ − この乗客はロサンゼルスへの移動を続け、５時間を超える長期間、そこにとどまる。

飛行区間４ − 数日後、この乗客は、ニューヨークへ行く途中、ロサンゼルスからダラスへ移動する。ダラスでは、６時間の一時降機がある。その期間中、乗客の荷物は返されない。

飛行区間５ − 乗客は、ダラスを出発し、ニューヨークへ行く途中でニューオリンズへ飛ぶ。ニューオリンズでは、３時間半の一時降機があり、荷物が乗客に返される。

飛行区間６ − 乗客は、ニューオリンズからニューヨークへの移動を続ける。

この例の場合、契約プロバイダは、飛行区間毎にプレミアムの１ｘを請求するであろう。ここでは、乗客は、保険の５ｘを請求されるであろう。この旅行に、請求される５つの飛行区間がある。乗客の荷物が航空会社によってモニタされ、降機は５時間未満であったので、シカゴにおける一時降機は、追加の飛行区間として見なされない。荷物がその期間中、航空会社によってモニタされていなかったので、ニューオリンズにおける一時降機は、個別の飛行区間と見なされる。

乗客は、航空会社モニタリング・システムが荷物に割り当てた値の記録を、チケット控えとともに受け取る。乗客は、支払いを受け取る前に、航空会社によって提供された荷物受取タグの記録とチケット控えのコピーを契約プロバイダに提供しなくてはならない。

これらドキュメントが示されると、契約プロバイダによる航空会社との直接的な確認が生じるであろう。確認は、電話、電子メール、またはその他任意の通信方法によってなされうる。あるいは、契約プロバイダは、データベース、または、この処理が自動的に行われることを可能にする航空会社とのその他いくつかの自動化システムを確立するであろう。

不正な請求のリスクを減らすために、請求に対して支払われる前に、契約プロバイダは、航空会社とすべての請求を確認する。請求モニタリング・システムは、不正行為を検知するために開発されるであろう。例えば、乗客は、着陸後の指定された期間後にのみ、請求することができうる。航空会社は、乗客の荷物を紛失したか否かを判定するための十分な時間を必要とする。さらに、荷物を紛失したことを航空会社が確認または認めたことを乗客が知らされた後、長いが適度な期間内に、乗客は、請求する権利を失う。

保険付きの乗客手続きおよび保障特性は、以下を含むであろう。乗客は、チケット購入時または後日、契約プロバイダの保障を買うが、乗客は、航空便前に、保障を購入しなければならない。プレミアムは、乗客が、航空会社のモニタリング・システムの保護下にバッグを運ぶ前に、支払われねばならない。繰り返すが、紛失した荷物は、完全保障にしたがう完全な紛失である。契約プロバイダは、荷物の中身が何であれ、荷物を紛失された乗客に対して、すべての乗客荷物に対して同額である予め決定された固定額を支払う。この支払いは、荷物が、航空会社によって紛失されたと認識または宣言されているとの条件付きである。契約プロバイダは、航空会社とその事実を確認する。乗客は、着陸後の、指定された期間後に、請求を提出しうる。その請求が実際に正当なものである場合、乗客は、予め決定された額の小切手を郵送される。繰り返すが、乗客は、紛失された荷物の請求をする期間について、有効期限がありうる。航空会社の航空便の時間から１年が経過しているのであれば、この保険は、もはや有効ではない。

乗客は、契約プロバイダから、保障を購入する。購入された保障は、限定されないが、従来の保証保険、サービス合意、または契約の形態を含む少数のソースから由来しうる。契約プロバイダは、乗客の代わりに、独立した保証会社から、契約または保証保険を購入しうる。契約プロバイダは、設定された額の保障ビークルを購入し、この保障を転売することができる。保障ビークルは、契約、保険、または合意を意味する。例えば、契約プロバイダは、航空会社、空港、年季、および、必要であると考えられうるその他任意の要因に基づいて、異なるプレミアム額に関する各バッグの保証会社の保障を考慮する独立した保証会社とともに保障プランを確立する。この保障プランでは、保証会社は、紛失された乗客の荷物についてより大きなリスクを有する要因を決定する。その後、これらは、これらの要因に依存する変動料金を請求する。データが収集され、記録が利用可能になると、保証業者は、構築された別の保障プランを確立しうる。

あるいは、契約プロバイダは、（例えば、保険または契約による）保証業者でありうる。

何れの状況であれ、契約プロバイダは、乗客が航空会社から直接的に受け取る、回収可能な額に対する権利を受け取りうる。乗客が、契約プロバイダの保険を用いることを選択した場合、その乗客は、バッグの紛失について請求する権利を、航空会社から放棄することを要求されうる。

航空会社産業が、荷物取り扱い手順を改善することを促進するために、契約プロバイダは、回収可能な権利を有する各紛失荷物について、航空会社から金銭を回収することを試みるであろう。保障された乗客が、バッグの中身のレシートおよびドキュメントを示すのであれば、回収される額は、より高くなるであろう。もしもドキュメントの提供を助けるのであれば、契約プロバイダは、乗客に、回収のパーセンテージを提示できるであろう。契約プロバイダは、回収物を譲ることによって、保証会社から低いレートのクォートを受け取るのであれば、付加利益があるであろう。契約プロバイダは、航空会社に対して、追加費用無しで、荷物取り扱い手順の改善を続けさせるという目標を達成するであろう。そのうちに、契約プロバイダは、乗客毎に設定された総額を受け取り、もって、航空会社から請求をしない。これは、航空会社と契約プロバイダとの両方に利益をもたらすであろう。なぜなら、航空会社と契約プロバイダとは、ケースバイケースで対応する必要はないであろうからである。

その他のタイプの荷物紛失のための保障を含む荷物保証保険が、市場において利用可能である。これらの保険によってカバーされている荷物紛失は、荷物の紛失をもたらしたイベントに関わらないが、荷物の価値に基づく額における保障である。契約プロバイダの保障は、航空会社によって紛失された荷物しかカバーしないであろう。契約プロバイダの保険は、すべての荷物が、予め定められた同じ額に評価されると仮定する。したがって、乗客は、航空便の前または後の何れかにおいて、バッグまたはその中身の価値を証明する必要はない。契約プロバイダの保険は、典型的には、チケット購入と同じ契約ポイントにおいて販売されるであろう。したがって、乗客は、この保障を捜す必要がないであろう。

検証された請求が提出される毎に、契約プロバイダの保険は、乗客に、予め定めれた額を支払う。そのバッグが航空会社によって紛失された乗客は、荷物の中身に関わらず、その額の支払いを受け取るであろう。乗客は、単に、航空会社が彼らのバッグを紛失したことを証明するだけでよいであろう。

したがって、乗客は、いくつかの利点を得る。第１に、請求支払手順が、時間を節約する。第２に、乗客は、他の保険では、バッグの中身の価値を証明する必要がある。ここでは、そのような状況ではない。なぜなら、各荷物は、同じ額で評価されるであろうからである。第３の利点は、契約プロバイダの保障が、現在の提案よりも、購入することがより容易になるであろうことである。これは、ユーザ・フレンドリで、単純なガイドラインにしたがうソフトウェアによる。

さらに、認可されたプロバイダも、利点を得る。例えば、航空会社の乗客と直接的に取り引きする認可されたプロバイダは、自分たちのシステムにソフトウェア３３を組み込むために、自分たちのチケット予約処理に若干の修正を加えるだけでよいであろう。契約プロバイダの保障は、プレミアムを、許可されたプロバイダの既存のサービス料金に組み込む。許可されたプロバイダは、前述したガイドラインにしたがって、サービス料金が、航空会社バッグ紛失のための予め定められた保障額を含んでいることを乗客に通知するであろう。保険を断りたい乗客は、契約プロバイダのプレミアムの額によって低額されたサービス料金を支払うであろう。許可されたプロバイダは、契約プロバイダのプレミアムをサービス料金に組み込むことに興味を持っていないのであれば、自分自身で乗客に保障を売ることができうる。これは、許可されたプロバイダが行うであろう販売の全体数を減少させうる。

航空会社の乗客と直接的に会わない許可されたプロバイダは、この保険を利用可能にするために、ほんの最小の手法で、ウェブサイトまたは他のインタフェースを変更する必要しかないであろう。これら許可されたプロバイダは、直接的なセール許可プロバイダと同じオプションを有するであろう。例えば、オンライン・チケット代理店は、契約プロバイダの保障を、サービス料金と束ねることを躊躇しうる。なぜなら、サービス料金は、非常に少額であり、契約プロバイダのプレミアムは、それを劇的に増加させうるからである。しかしながら、これらの手数料は、彼らの利益をも劇的に増加させるであろう。プレミアムが手数料とともに束ねられた場合、乗客は、契約プロバイダのプレミアム額の割引のために、契約プロバイダの保険を外すオプションを与えられうる。

乗客が見るべき「契約条件」スクリーンがある場合がある。「契約条件」スクリーンは、リンクされうる。保障の購入によって、乗客３５は、「契約条件」に同意しているであろう。乗客３５が、非ウェブ・ベースのインタフェースによって保障を購入していれば、乗客はまだ、「契約条件」に同意しなければならないであろう。

さらに、契約プロバイダは、契約プロバイダに譲渡されるすべての紛失に請求する訳ではないことで、料金を返金するように、航空会社に要求できうる。その事象では、すべての保険が、航空会社産業から料金を収集し、その料金は、契約プロバイダが収集した譲渡される紛失の利用の必要性を緩和するであろう。

さらに、契約プロバイダは、その製品を記載し、乗客がオンラインで請求することを支援するウェブ・ページ（図示されていないが、コンピュータ４０によってサービス提供される）を提供しうる。それはまた、乗客に対して、電話でいくつかの質問をするか、請求することをアドバイスするであろう。ウェブ・サイトは、ファイル転送またはソフトウェア更新のためにも同様に使用されるであろう。もちろん、このサイトは定期的に更新され、維持されるであろう。

本明細書において記載された技術は典型的であって、本開示に対するいかなる特定の限定をも意味しているとは解釈されるべきでない。さまざまな代替、組み合わせ、および修正が、本開示から、当業者によって考案されうることが理解されるべきである。例えば、本明細書において記載された処理または方法に関連付けられたステップは、別に指定されていないか、または、これらステップ自身によって決定されていないのであれば、任意の順序で実行されうる。本開示は、添付された特許請求の範囲のスコープ内にあるこのようなすべての代替、修正、および変形を含むことが意図されている。

Claims (16)

1. 紛失されたバッグのための代償のための処理であって、
   １つまたは複数のバッグのための保障購入要求を乗客から受け取ることと、
   前記要求された保障を検証および準備することと、
   前記１つまたは複数のバッグのうち紛失された１つのバッグに関する誤取扱荷物請求を、前記乗客から受け取ることと、
   前記紛失されたバッグについて、前記誤取扱荷物請求を処理することと、
   前記紛失されたバッグの中身に関わらず、前記バッグに関して、前記乗客に対して代償することと、
   を備える処理。
2. 前記誤取扱荷物請求が受け取られたとの通知を前記乗客へ送信すること、をさらに備える請求項１に記載の処理。
3. 前記誤取扱荷物請求を処理することはさらに、前記誤取扱荷物請求の正確さを検証することを備える、請求項１に記載の処理。
4. 前記誤取扱荷物請求を処理することはさらに、前記紛失されたバッグの、前記航空会社とのステータスを判定することを備える、請求項１に記載の処理。
5. 前記バッグが紛失されたことを、前記ステータスが判定された後に乗客に通知すること、をさらに備える請求項４に記載の処理。
6. 前記紛失されたバッグが発見されたことを、前記ステータスが判定された後に乗客に通知すること、をさらに備える請求項４に記載の処理。
7. 前記保障購入要求は、航空会社の航空便の飛行区間毎に予め定められた補償額に関する、請求項１に記載の処理。
8. 旅行の飛行区間の数を決定することと、
   第３の固定期間を超えた、前記旅行の各飛行区間の時間の長さを決定することと、
   をさらに備える請求項１に記載の処理。
9. 前記飛行区間の数と、前記時間の長さとの決定に基づいて、１つよりも多くの契約が必要とされているか否かをアドバイスすること、をさらに備える請求項８に記載の処理。
10. 前記代償は、前記バッグの中身に関わらず、購入された契約に基づく固定額である、請求項１に記載の処理。
11. 保障を検証および準備することは、
    前記航空会社から情報を取得することと、
    保障されている乗客によって、ある期間後に、さらなる証明無しで保障額が収集されるように、物理的なレシートを生成することと
    を含む、請求項１に記載の処理。
12. 前記紛失されたバッグは商品である、請求項１に記載の処理。
13. １つまたは複数のバッグが紛失された場合における代償の方法であって、
    航空便の出発前の任意の時間において、１つまたは複数のバッグを、前記バッグの中身に関わらず固定料金で保証する保障を購入することと、
    前記航空便の航空会社において、前記保障された１つまたは複数のバッグをチェックすることと、
    前記保障されたバッグのうちの少なくとも１つが紛失されたとの誤取扱荷物請求を申告することと、
    前記保障されたバッグのうちの少なくとも１つが紛失されたとの宣言のために、第１の固定期間、待機することと、
    を備える方法。
14. 前記宣言された紛失されたバッグについて申告された請求を受け取るために、前記第１の固定期間よりも長い第２の固定期間、待機すること、をさらに備える請求項１３に記載の方法。
15. 前記代償は、前記宣言された紛失されたバッグの中身に関わらず、前記購入された保障に基づく固定額である、請求項１３に記載の方法。
16. 前記宣言された紛失されたバッグは、商品である、請求項１３に記載の方法。

Images