JP2006073031A - アカウント調停ためのシステムと方法 - Google Patents

Abstract

【課題】中央に請求されたアカウントの調停において（より詳細には旅行産業において中央に請求書が作成されたアカウント（１０７）の調停において）特定の実用性を有するアカウント調停システムが提供される（１１６）。
【解決手段】本発明のシステムおよび方法が従来の一致／不一致技術に拡張され、クライアントのアカウント（１０２）上の各アイテムについて完全な取引管理を提供する。別の意味では、調停は、取引の調停状態（すなわち、一致された（１１１）、未決済の（１１５）、保留中の等）にもかかわらず、アカウント上の各取引および全ての取引を含むように再規定され、本発明は、アカウント収支（１２１）に対するクライアント収支を調停する。
【選択図】図１ｂ

Description

（発明の分野）
本発明は、一般に、アカウント調停に関し、特に旅行の「中央勘定」のアカウント調停に関する。より詳細には、本発明は、中央で勘定される旅行アカウントにおける取引を識別し、このアカウント収支への調停を行うシステムおよび方法に関する。

（発明の背景）
中央勘定は、大従業員ベースの会社でよく用いられる共通のアカウント実務である。一般には、カードベンダーは、認可されたアイテムの料金用に、多数の従業員あるいは認証された者によって用いられ得る共通のアカウント勘定番号を割り当てる場合に、中央勘定が典型的に生じる。その会社は常に、すべての従業員の料金に対して、支払請求サイクルの終わりに１枚の勘定書を受け取る。

旅行業界では、中央勘定は特に流行し、多くのカードベンダーによって提供されるサービスである。例えば、Ａ会社は、料金カード会社にＡ会社の料金航空チケットのすべてまたは他の旅行関連料金のすべてに用いられる会社アカウント番号を割り付けるように要求できる。このように、会社Ａの任命された人が会社Ａの旅行代理店からチケットを要求する場合、この料金は個人のアカウントの代わりにその会社のアカウントに自動的にのせられる。特定の支払請求サイクル中の料金、例えば、毎月の料金が、多数の従業員およびチケットによってその会社のアカウント番号の上に増える。支払請求サイクルの終わりに、会社のアカウント番号を用いて、支払形式として作られたすべての料金用として、１枚の勘定書が常に、その会社に支払用として送られる。多くの会社は、それらの旅行者に送られた実質的に数百の個人の勘定書きを有する代わりに、各支払請求サイクルの終わりにおいて、１枚の支払勘定書を受けることの簡単さを喜ぶ。

しかしながら、中央勘定は、アカウント調停の分野で多数の問題を生じさせる。多くの場合、勘定書受取人、例えば、会社Ａは、旅行ベンダーとの契約において、中央で勘定されるアカウントに対し、そのカードベンダーにより発行された毎月の請求書を調停する重要な条件を含む。すなわち、会社Ａは、各アカウントの料金およびクレジットを識別し、訂正されかつ支払われる準備がなされていることが決定されている料金の全額を計算し、そして適切な手数料および費用を正確に申請する。さらに、中央勘定調停プロセスは、たびたび各アカウント増加における個々のアイテムのボリュームに従って上昇する。

中央で勘定されるアカウントの伝統的なアカウント調停プロセスは「一致／不一致」アプローチである。上述の例に続くと、旅行代理店は通常、サイクル間で勘定されたすべての旅行取引（料金とクレジット）のリストのカード請求書の電子コピーを受ける。この旅行代理店は、会社Ａの料金および通常、チケット番号に基づいた会社Ａの旅行記録に対する１回の一致処理を行い、一致アイテムのリストおよび不一致アイテムのリストを作成する。一致アイテムは、続いて、会社に報告書として送られ、この報告書は、旅行認可番号、従業員ＩＤ、プロジェクトコード、または従業員独自の旅行記録でキャプチャされた類似のものなどの識別するアカウント情報を含む。

不一致アイテム、これらは対応する旅行記録を有しない任意の料金記録を含み、例えば、発行日の後に取り消されたチケット、空港でなされたチケットの変更、およびデータ入力エラー（例えば、スペルの誤り）が識別されないままで残っている。通常、会社は不一致アイテムに対して支払を拒否する。なぜならば、多くの場合、会社は料金の適切な説明、例えば、どの従業員が旅行チケットを請求したかを確立できないからである。勘定書き調停者は後に、支払のための料金の説明および再転送のために、各不一致アイテムを調査しなければならない。旅行／チケット業界などの金額の多い業界では、この調査プロセスは厄介で非常に時間がかかる。さらに、航空会社が不完全なデータを提供する場合、調停者がこのアイテムを簡単に識別できないというケースがたびたび起こる。このような場合、この不一致アイテムは未支払のまま残り、そして結局のところ、これはカードベンダーでは帳簿から消去されることになる。

大抵のクレジットカード会社は、たびたび中央勘定アカウント調整をさらに複雑にする電子クレジットカード処理に移っている。例えば、会社Ａから任命された従業員が、中央で勘定されるカードアカウントを用いて、月曜日に旅行代理店から旅行チケットを購入する場合、このカード料金はカード会社によって電子的にかつほぼ直ぐに処理される。そこで、火曜日に、会社Ａの旅行会社は発行されたチケットの記録を示し、その料金カード会社は料金記録の領収書を示す。各週末に、旅行代理店は、Ａｉｒｌｉｎｅ Ｒｅｐｏｒｔｉｎｇ Ｃｏｒｐｏｒａｔｉｏｎ（ＡＲＣ）を介して、チケット販売の報告書を航空会社に送る。ＡＲＣは、発行されたチケットの数と支払われたドルの計算を含め、すべての航空会社および料金カードベンダーに対する調停処理を監視する。各週の金曜日までに、旅行代理店は、会社ＡのＡＲＣ報告書からの旅行記録／チケットが存在しない場合に、それを無効にする機会を有する。しかしながら、それは、会社の中央勘定アカウントでの取引を同じようには無効にできない。例えば、旅行代理店が木曜日に会社Ａのチケットを無効にした場合、会社のクレジットカードアカウント上の料金（既に処理されている）は残ったままである。旅行代理店がその販売報告をＡＲＣに送る週末に、ＡＲＣはチケットが無効にされたことを知り、そして無効になったチケットに対して、訂正しているクレジットを会社の中央勘定アカウントに作成する。これらの取引が会社のアカウント上に現われると、それらは不一致アイテムとなる。言い換えると、会社Ａの料金記録は１週目に発行されたチケットのチケットレコードに一致しているとして表され、しかしこれはもう存在しない。無効にされたチケットのクレジット（ＡＲＣで２週目に発行されたもの）もまた、不一致料金記録として表される。これらの取引が会社Ａの確立する支払請求サイクル内で起こる場合、これらの借方（ｄｅｂｉｔ）および貸方（ｃｒｅｄｉｔ）取引が同月の中央勘定アカウント上に共に現われる機会が存在する。しかしながら、このようなケースの少なくとも約２５％の場合において、借方および貸方が同月の報告には現われなく、従ってさらにその調停プロセスを複雑にする。

さらに、Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ（Ｒ）およびＤｉｎｅｒｓ Ｃｌｕｂ（Ｒ）のような多数のクレジットカードベンダーは「繰越（ｃａｒｒｙ−ｏｖｅｒ）」残額を許可しないし、そして支払請求サイクル間のすべての料金は勘定領収書の期限になる。この意味において、その会社は、それらのアカウントにおけるすべての取引を、調停一致が各点においてなされてもなされなくとも、支払うように依頼される。このようにして、借方おとび貸方が同じサイクルに現われない場合、会社は、無効にされるか、戻されるかまたはそうでなければ受け取られてないアイテムに対して請求され得る。多くの場合、この「払い過ぎ（ｏｖｅｒｂｉｌｌｉｎｇ）」が結果として料金紛争を起こす。このように、伝統的な調停は一般的に、アイテムの高比率で一致させているが、このアポローチはなお不充分である。たとえ不一致アイテムの小さな比率でも、これは調査および訂正されなければならない不一致アイテムおよび未解決入力の大きな数字と等しくなり得る。

追跡調査のように、一致したアイテムを識別および解決する伝統的な一致技術、そして不一致アイテムを識別かつ解決する調査および訂正技術を含むアカウント調停のシステムおよび方法が必要とされる。さらに、一致また不一致のすべてのアカウント上のアイテムを含め、アカウント収支の保留の取引を識別し、追跡調査を行い、そして調停するアカウント調停のシステムおよび方法が必要とされる。

（発明の要旨）
本発明は、伝統的な一致技術の上に、拡張かつ構築するアカウント調停の改善されたシステムおよび方法を提供する。特に、本発明は、アイテムが一致または不一致の入力に関係なく、アカウント上の各入力を調停するアカウント調停システムおよび技術を提供する。

このシステムは、通信チャネルを持ったクライアントサイドおよびサーバサイドを含み、この通信チャネルは両サイドを共に繋ぎ、そしてあるアカウントに関するデータを受け取りかつ格納できるアカウントのデータベースを含む。受け取ったデータを自動的に一致させ、そして一致データおよび残った不一致データを自動的に編集するプログラミングを含むソフトウエアプログラムもまた含まれ得る。ユーザは不一致データを閲覧し、システムにデータベースの検索指示を行い、そして一致を容認するように指示することを許可されている。ユーザはまた、不一致データを編集することを許されている。このシステムは、アカウントがアカウント収支に調停されていることの証明書からなる調停報告書を生成するプログラミングを含む。

（例示的な実施形態の詳細な説明）
本発明のこれらと他の特長、局面および長所は、添付する図面との組み合わせでの次の説明を参照すると非常に良く理解され得、この図面において同じ数字は同じ要素を表す。

本発明は、中心的に勘定されたアカウントの調停において特定の有用性を有するアカウント調停のための改良されたシステムおよびその方法を提供する。本明細書中に開示された本発明のシステムおよび方法は、様々な用途において中心的に勘定されたアカウントの調停に適切であり得るが、本発明は、旅行産業を参考にして説明されることに都合が良く、さらに詳細には、旅行記録および料金記録のアカウント調停を参考にして説明されることに都合が良い。さらに、旅行チケット産業全体にわたって参考される；しかし、本発明が旅行代理店のドメイン内の様々な他の産業（宿泊およびレンタルカーのアカウント調停等）、および、旅行代理店のドメイン外の様々な他の産業（中心的に勘定されたアカウントに統一され得るコンピュータアクセスおよび／または費用等）に等しく適用されることが認識される。

全体として、本発明はアカウント調停のために従来の一致／不一致技術を拡張する。言い換えれば、従来のアプローチの借方を貸方に単に一致させることにより、アカウントの商品（ｉｔｅｍ）の大部分を日常的に調停し、従来のアプローチが本発明の初期のステップにおいて維持されている。次いで、本発明は、一致された商品および一致されていない商品の単なる識別を超えており、アカウントの全ての商品の完全な管理を提供する。別の意味で、本発明は、調停請求書に関わらず、アカウントの個々の商品の管理によって調停アカウント全体の収支を調停する。

本発明は、クライアントが「一致」のクライアント自身の定義によって支払うことを一般に認識することにより、商品が支払のために準備される時点を判別することの従来のアプローチを再定義する。従来のアプローチは、一致を判別するために用いられるデータの質を一般に十分に考えない。一致するように見えるものが、クライアントによって送信されたより厳密な調停要件セットを満たさないことが多い。本発明は、それぞれのクライアントの基準（例えば、会計基準）によって調停プロセスの柔軟性を可能にする。クライアントはまた、クライアントの調停要件が満たされている時点を示し、クライアントが喜んで支払を行うことを示すためにガイドラインを設定し得る。言い換えれば、１クライアントは、別のクライアントによって確立された条件からかなり異なる所定の条件の下に商品が支払の準備されることに満足し得る。

本発明のシステムおよび方法は、エンティティを支払行為から妨げる問題を最も識別し、十分に決済される（ｒｅｓｏｌｖｅｄ）、すなわち、勘定収支を調停するまでそれぞれのエンティティの支払行為を追跡することにより、問題を訂正する解決策および機会を提供する。この技術は、不一致である商品が従来の技術のように忘れ去られるのではなく、それぞれの商品が顕著な勘定収支から除去されるまで追跡されるので、最終的には、アカウント商品の全ての決済が行われる。クライアント中心に勘定されたカードアカウントのそれぞれの商品を追跡し、管理することにより、調停者およびクライアントが、最終的にアカウントの全ての商品が決済されていることを確実にされる。勘定収支に対する調停（すなわち、アカウントの全ての開いた商品の追跡）により、調停されていない勘定収支の未払いによる償却が減ることになり、不一致である取引の検索および訂正により、議論のためのマージンを減らしてより単純な勘定調停プロセスがなされる。当業者は、「全て」のアカウント商品の決済がシステムによって実施される一致した商品および／またはクライアントによって要求される一致した商品の決済または所定の数または一致した商品のレベルのための様々な許容レベルを含むことを理解する。

（アカウント調停システム）
例示的なシステムは、本発明およびそのベストモードの理解を容易にするために以下に提供される。様々な他のコンポーネントが意図されるように本発明の精神を逸脱することなく用いられ得ることが認識される。簡潔さのために、信号処理、データ取引、シグナリングおよびネットワーク制御およびシステムの他の機能的な局面（およびシステムの個々の動作コンポーネントの内のコンポーネント）の従来の技術は本明細書中に詳細に説明され得ない。さらに、本明細書中に含まれる様々な図面に示されたコネクトライン（ｃｏｎｎｅｃｔｉｎｇ ｌｉｎｅ）は、様々な要素の間の例示的な機能的な関係および／または物理的な結合を表すことが意図されている。多くの代替的なまたはさらなる機能的な関係または物理的な接続が実用的なネットワーク通信システムに存在し得る。

図１ａは、本発明により、アカウント調停システムを実施するために用いられ得る例示的なコンピュータベースのアーキテクチャ１０を示す簡単化された模式図である。アカウント調停システムがクライアント側１２、１３およびサーバ側１７を有するありふれたクライアント／サーバアーキテクチャにて実施され得る。クライアント側１２、１３は、通常、１実施形態において、ディスプレイおよびキーボード、マウス、キオスク（ｋｉｏｓｋ）、パーソナルデジタルアシスタント（ｐｅｒｓｏｎａｌ ｄｉｇｉｔａｌ ａｓｓｉｓｔａｎｔ）、ハンドヘルドコンピュータ、携帯型コンピュータおよび／または携帯電話等の入力手段コンピュータデバイスを含む。本実施例に示されるように、クライアント１２は、携帯型コンピュータであり、クライアント１３がパーソナルコンピュータである。２つのクライントが例示的な目的のためにのみ示され、任意の数のクライアントがアーキテクチャに含まれ得ることが認識されている。クライアントは、通常、オペレーティングシステム（例えば、Ｗｉｎｄｏｗｓ（登録商標）のバージョン（Ｗｉｎｄｏｗｓ（登録商標） ＮＴ、Ｗｉｎｄｏｗｓ（登録商標）９８／２０００／Ｍｉｌｌｅｎｉｕｍ））および様々な従来の支援ソフトウェアならびにコンピュータ、コンピュータデバイス等に一般に関連するドライバを含む。例えば、クライアント側は、ネットワークへのアクセスを容易にするために一般にモデム（例えば、５６Ｋｂａｕｄ）１４、１５を含む。

サーバ側１７は、電子的に共にリンクされているサーバ１８、システムアドミニストレータ１９およびモデムプール２０を広く含み得る。モデムプール２０は、電気信号をサーバ１８に送信し、クライアントモデム１４、１５から電気信号を受け取るように用いられる。モデムプール２０は、モデム性能を最適化し、ハンドオフリトレイン（ｈａｎｄｏｆｆ ｒｅｔｒａｉｎ）をなくし、送信レベルの正確な設定を提供するために、いくつかのプロトコル変換を提供し得る。サーバ側１７は、デジタルデータを処理するプロセッサと、デジタルデータを格納するプロセッサに接続されたメモリと、デジタルデータを入力するプロセッサに接続された入力デジタイザとプロセッサに格納された応用プログラムとを有する一般にコンピュータデバイスを含む。サーバ１８は、例示的な実施形態において、テーブル、オブジェクト、トリガおよび格納された手順を含む任意の適切な処理サーバとして実施される。例えば、Ｍｉｃｒｏｓｏｆｔ（Ｒ）ＳＱＬ６．５サーバデータベースはサーバ１８として首尾よく利用されてきた。

理解されるように、システムアドミニストレータ１９は、ディスプレイと、キーボード、マウス、キオスク、パーソナルデジタルアシスタント、ハンドヘルドコンピュータ、携帯型コンピュータおよび／またはサーバ１８との通信を容易にする携帯電話等の入力手段とを好適に含むコンピュータデバイスを含む。システムアドミニストレータ１９は、内部に格納された適切なオペレーティングシステム（例えば、Ｍｉｃｒｏｓｏｆｔ（Ｒ）ＮＴ Ｗｏｒｋｓｔａｔｉｏｎ）をさらに含む。システムアドミニストレータ１９は、サーバ１７の一つ以上のデータベースにロードされるデータを適切に受信する。例えば、旅行産業に関連する一つの特定の用途について、旅行データ２１、カードデータ２２および第３者データ２３はサーバ１７に電器子的に格納されている。第３者データ２３は、システムに含まれ得るか、含まれ得ず、旅行データ２１およびカードデータ２２に関連しないベンダーから旅行データおよびカードデータを一般に含み得るか、含み得ない。例えば、一つの特定の実施形態において、Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ（Ｒ）旅行データ、Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ（Ｒ）カードデータおよび非Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ（第３者）カードおよび旅行データが電子的に受信され得、サーバに格納され得る。

図１ｂは、本発明によるアカウント調停システムが機能し得、動作し得る環境を示すトップレベルブロック図である。アカウント調停システム（以下では「システム」という）１１０がフロントエンド（クライアント）１０２およびバックエンド（サーバ）１０７を含む。当業者が理解するように、フロントエンド１０２は、コンピュータ、コンピュータデバイス等を一般に含む。バックエンド１０７は、ホストサーバまたは他のコンピュータシステムおよび複数のデータベース等のサーバを含む。

例示的な実施形態において、システム１１０がデータストレージ媒体に常駐する一つ以上の関連データベースを含む。旅行または商業データ１１２および金融（カード）データ１１４は、それぞれのクライントの関連データベースに含まれる。当業者は、安全性という理由から、任意のデータベースシステムまたは本発明のコンポーネントがデータベースまたは単一の位置または複数の位置にあるコンポーネントの任意の組合せからなることを理解する。それぞれのデータベースまたはシステムは、任意の様々な適切な安全性の特徴（例えば、ファイヤーウォール、アクセスコード、暗号化、復号化、圧縮、解凍および／または同等物）を含む。データベースを実施するために用いられ得る共通のデータベースプロダクトは、ＩＢＭによる（Ｗｈｉｔｅ Ｐｌａｉｎｓ、ＮＹ）ＤＢ２、Ｏｒａｃｌｅ
Ｃｏｒｐｏｒａｔｉｏｎ（Ｒｅｄｗｏｏｄ Ｓｈｏｒｅｓ、ＣＡ）から市販されている任意のデータベースプロダクト、Ｍｉｃｒｏｓｏｆｔ ＣｏｒｐｏｒａｔｉｏｎによるＭｉｃｒｏｓｏｆｔ Ａｃｃｅｓｓまたは任意の他のデータベースプロダクトを含む。データベースは、データテーブルまたはルックアップテーブルを含む任意の適切な態様で編成され得る。所定のデータの関連は、公知の業界で行われている任意のデータ関連技術によって達成され得る。例えば、関連は、手動または自動のいずれかで達成され得る。自動関連技術は、例えば、データベース検索、データベースマージ（ｍｅｒｇｅ）、ＧＲＥＰ、ＡＧＲＥＰ、ＳＱＬおよび／または同等物を含み得る。関連ステップは、データベースマージ機能によって（例えば、製造者およびリテーラ（ｒｅｔａｉｌｅｒ）データテーブルのそれぞれの「キーフィールド」）を用いて）達成され得る。「キーフィールド」はキーフィールドによって規定されるオブジェクトのハイレベルクラスに応じてデータベースを区分する。例えば、所定のクラスは、第１のデータテーブルおよび第２のデータテーブルの両方にてキーフィールドとして指定され得、次いで、２つのデータテーブルは、キーフィールドのクラスデータを基礎にしてマージされ得る。この実施形態において、マージされたデータテーブルのそれぞれ内のキーフィールドに対応するデータは好適には同一である。しかし、キーフィールドにおいて、類似であるが、同一ではないデータを有するデータテーブルはまた、例えばＡＧＲＥＰを用いてマージされ得る。

フロントエンドとバックエンドの間の通信は、データ交換またはビジネスの取引のための任意の適切な通信ネットワーク（電話回線、イントラネット、インターネット、エクストラネット、ＷＡＮ、ＬＡＮ、衛星放送、相互作用デバイスのポイント（ｐｏｉｎｔ ｏｆ ｉｎｔｅｒａｃｔｉｏｎ ｄｅｖｉｃｅ）、オンライン通信、オフライン通信、無線通信等）１０５によって達成される。

一つの特定の用途において、システムは、フロントエンド、エンドエンド、ウェブブラウザおよびウェブページを有するインターネットベースのアプリケーションとして実施される。コンピュータは、ユーザによってアクセス可能な適切なウェブサイトまたは他のインターネットベースのグラフィカルユーザインターフェースを提供し得る。一実施形態において、インターネット情報サーバ、Ｍｉｃｒｏｓｏｆｔ取引サーバおよびＭｉｃｒｏｓｏｆｔＳＱＬサーバがＭｉｃｒｏｓｏｆｔオペレーティングシステム、ＭｉｃｒｏｓｏｆｔＮＴサーバソフトウェア、ＭｉｃｒｏｓｏｆｔＳＱＬデータベースシステムおよびＭｉｃｒｏｓｏｆｔ商業サーバと関連して用いられる。さらに、Ａｃｃｅｓｓ Ｓｅｑｕｅｌ Ｓｅｒｖｅｅｒ、Ｏｒａｃｌｅ、ＭｙＳＱＬ、Ｉｎｔｅｒｖａｓｅ等のコンポーネントがＡＤＯコンプライアントデータベース管理システムを提供するように用いられ得る。ウェブページそのものとして本明細書中に用いられている用語「ウェブページ」は、ユーザと相互作用するように用いられ得るドキュメントおよび用途のタイプを限定するように意図されていない。例えば、通常のウェブサイトが、標準的なＨＴＭＬドキュメントに加えて、様々なフォーム、Ｊａｖａ（登録商標）アプレット、Ｊａｖａ（登録商標）スクリプト、アクティブサーバページ（ＡＳＰ）、共通のゲートウェイインターフェーススクリプト（ＣＧＩ）、拡張可能マークアップ言語（ＸＭＬ）、ダイナミックＨＴＭＬ、カスケーディングスタイルシート（ｃａｓｃａｄｉｎｇ ｓｔｙｌｅ ｓｈｅｅｔｓ）（ＣＳＳ）、ヘルパーアプリケーション、プラグイン等を含む。

上述したように、本発明は、旅行代理店産業に対して特定のアプリケーションを有する。一般に、コンピュータ予約システム（ＣＲＳ）１１８またはグローバル配信システム（ＧＤＳ）（例えば、旅行代理店において）が旅行予約の旅行データおよび料金データを取り込む。ＣＲＳは、旅行チケットを発行し、旅行記録１１６を適切なストレージまたはアカウティングシステムに転送する。類似した態様で、ＣＲＳは、旅行購入が旅行者クレジットカードにて行われることを料金カードベンダー１２０に通知する。ＣＲＳまたは旅行代理店は、ＡＲＣ１２２に発行されたチケットおよび課金されたドルの週間レポートを提出する。

クライアントカードベンダー１２０は、勘定期間（ｂｉｌｌｉｎｇ ｐｅｒｉｏｄ）の間にクライアントの料金アカウントに課される料金の全てを含むサイクル的なカードステートメントをクライアントに発行する。本システムは、クライアントの料金アカウントステートメントに関連して作動し、このステートメント（旅行データに関連する）のそれぞれの商品の識別または会計を提供するように構成される。この意味で、クライアントの旅行およびカード取引は、システム１１０の会計データベースにロードされる。本システムは、格納された旅行記録１１６からの旅行関連データ（会社の旅行または商業的なベンダーによって旅行データベース内に適切に格納される）の受信および料金カードベンダー１２０からの料金関連データ（料金カードベンダーの費用データベースに適切に格納される）の受信を含む。いくつかの時点において、旅行およびカードベンダーのデータベースは、旅行ベンダーおよびカードベンダーが同一の企業のエンティティ内にあり、バンクオフィス会計または勘定システム（Ａｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ（Ｒ）カードサービスおよびＡｍｅｒｉｃａｎ Ｅｘｐｒｅｓｓ（Ｒ）旅行関連サービス）に格納されるときに、システム１１０の会計データベースにネットワークが形成され得る。しかし、たいていの環境下で、旅行およびカードデータベースからのデータは、電子フォーマットの通信チャネルを介する等によって遠隔的に受信される。

本発明のシステムおよび方法は、勘定収支にクライアントのアカウントを調停する様々な機能を含む。それぞれの機能は、会計データベース１１０またはクライアントワークステーション１０２上に格納されたコンピュータプログラムに格納された適切なコンピュータプログラム内の論理ルーチンである。本発明のシステムおよび方法の以下の簡単な説明は単に例示的なルーチンを表すものとしてのみ提供されており、したがって、以下の機能および機能の対応するブロック表示のいくつかまたは全てが存在し、特定の用途に必要とされるように組み合され得るか、変更され得る。

図１ｂを続いて参照すると、本発明は料金記録と旅行記録を一致させる従来の技術の上に構築している。本システムは、クライアントカードステートメントのそれぞれの取引を考慮し、対応する旅行取引のデータベースを検索する。一致するチケット番号が旅行データ内で見つけられる場合、本システムは残りの基本的な一致基準が満たされ、一致が確認されることを証明する。任意の第２の証明はまた、任意のさらなるクライアント規定の会計データ要素の存在をクライアントによって要求されるように確認するために実行され得る。基準全てを満たす取引が支払のためにすぐに処理され、「承認された商品」リスト１１１に移動される。本明細書中で用いられる「リスト」は、処理されるデータのグループを処理し、収集し、ソーティングし、格納し、取り出す等ための任意の適切な手段を含み得る。

自動調停の間に任意の基本的な一致基準に失敗する（以下で詳細に説明されるようにウォッシュアウトされた（ｗａｓｈｅｄ ｏｕｔ）取引が「未決済の取引」リスト１１５に移される。「移される」は一つのリストまたはデータテーブルから別のリストまたはデータベースへのデータの電子的な移動をいうか、データリンクの維持または確立をいう。未決済の取引リストにおいて、リストのそれぞれの商品が追跡され、訂正される（ｔｒａｃｋｅｄ ｔｈｒｏｕｇｈ ｔｏ ｃｏｒｒｅｃｔｉｏｎ）。本システムは、例示的な実施形態において、保留リストのリサーチおよび訂正を容易にするリサーチツールを含む。リサーチツールは、カード取引の全ての詳細を（データベースから）表示し、基準（この基準によって（データベースにおいても）一致している取引を検索する）をユーザが特定することを可能にする。一致している（または非常に関連のある）取引が配置されるときに、ツールがカード取引の訂正を容易にし、完了すると、訂正された取引が「承認の準備」リスト１１３に移される。

承認の準備リスト１１３は、承認認可局でユーザに制限され得る。それぞれの取引の前後のピクチャはユーザに表示され得、この結果、取引に為される任意の編集がレビューされ得る。取引が承認されると、本システムが商品を承認の準備リスト１１３から承認された商品リスト１１１に移す。承認されていない取引は、未決済の取引リスト１１５に戻される。

勘定された取引レポート１１７は、すぐに支払処理がされる全ての料金から作成され、承認された商品リスト１１１の取引全てを含む。概要調停レポート１２１はカード勘定収支にアカウント活動を自動的に調停する。本システムは、カードステートメントから最初の収支額を読み出し、現在の月間活動（月間の勘定ステートメント毎の借方を減算した貸方）を加え、受信された支払を引いて、予測される支払（すなわち、保留している勘定された取引レポートからの合計）を引く。差異は、未決済の取引の額である。調停を証明するために、未決済の取引リスト１１５の取引合計が取り出され、レポート１２１に表示される。この２つの額（カードステートメントと未決済の取引リストからの差異）が一致するとき、アカウントが収支している。

さらに、本システムが同一の旅行チケットに対して相殺する借方および貸方を自動調停の間に識別する場合、または、本システムが未決済の取引リストに保留している借方を相殺する貸方を見つけた場合、本システムはこの取引を「ウォッシュアウト（ｗａｓｈ ｏｕｔ）」。相殺する借方および貸方は「ウォッシュアウトされる」リスト１１９に移される。この特徴により、不一致の借方（例えば、無効にされたチケット）を相殺する不一致の貸方を識別することによってリサーチを必要とする不一致の取引の数を減らす。さらに、支払を処理する取引の数は勘定された取引レポートの不必要なエントリを排除することによって低減される。

本システムは、返済モジュール１２３をさらに含む。チケットが返済のために旅行オフィスに返されるので、チケット情報がモジュールに入れられる。本システムは、旅行者の受信を印刷し、次いで、チケットを返済ログに加える。返済ログは、返済プロセスを容易にするために用いられ得る。例えば、返済ログは、返済処理のために、会社の旅行ベンダーに転送されるチケットの送信されたログを印刷し得る。返済が次の勘定ステートメントに現われるとき、本システムは、返済ログを更新する。例えば、貸方のデータ、貸方の金額およびそれぞれの貸方のステータス（勘定された取引レポート；ウォッシュアウトされたリスト；または未決済の取引リストに含まれる）が受信される。

さらに、本システムは、例えば旅行ベンダーによって課金された取引費用を調停する能力を含む。飛行機会社によって旅行ベンダーに支払われた手数料がクライアントに割戻される。本システムは、それぞれのチケットに対してクライアントのための割戻し額を計算し、クライアントの勘定された取引レポートから割戻し額を差し引く。次いで、この金額は、旅行ベンダーによってカード会社に直接に支払われる。このように、クライアントが割戻し支払を個々に調停し、処理することは必要ではない。

簡単に説明してきたように、本発明のシステムおよび方法は、商品がクライアントによって支払われるか、「ウォッシュアウトされる」まで、調停プロセスにわたってアカウントの開いた商品全てを追跡することによって勘定収支に調停する。さらに、本システムが、不一致の取引のリサーチおよび訂正を容易にし、保留している返済を追跡し、取引費用を調停する。上述の簡単に説明された特徴に加えて、以下の説明および参照されるフローチャートから明らかな本発明の様々な他の特徴およびオプションがある。

（アカウント調停の例示のフローチャート）
本発明の様々な処理が、本発明および本発明の最良の形態の理解をさらに容易にするために議論される。示され記載される特定の実施が、本発明の実施形態（本発明の最良の形態を含む）の例示を示し、決して本発明の範囲を制限することに意図されない。

図２は、本発明による所与のサイクル（例えば、月ごと）に関するアカウント調停の例示の実施形態を記載するフローチャート２００である。理解を容易にするために、フローチャート２００（および任意の関連のフローチャート）は、特定の産業（すなわち、旅行代理店産業）に関係して都合良く示され、記載される。従って、旅行に関連したトピック、モジュール、ルーチンおよびそのようなものに関して本明細書中に参考とされる。

旅行産業に共通であるように、旅行計画は、頻繁に変更され、および/または結局キャンセルされる。旅行チケットは、無効にされるか、返却されるか、または言い換えると使用され得ない。本発明は、取り消された商品または未使用の商品を含む、アカウントに関する全ての商品の管理を含む。この様態において、返済ログは、システムの返済モジュールにうまく格納されるが、返済するために返却されたチケットに関する情報がシステム的に更新される。返済モジュールは、以下の図３により詳細に記載される。

前述されたように、本システムは、他の機能の間に、各特有のアカウントに対して旅行関連データおよびカード関連データ（すなわち、料金）を受信し、格納するように構成されたアカウントデータベースを含む（ステップ２０２）。旅行およびカードデータは、システム内の様々なデータベースから、または多くの場合、システムの外部から受信され得る。

調停プロセスは、一般に自動調停プロセスで始まり、それによりアカウントでリストされた各料金取引のため、システムは、対応して一致する旅行関連データを検索する（ステップ２０４）。本発明の一実施形態において、いくつかの個々のステップを経て、一致するプロセスが生じる。いくつかの個々のステップは、以下の図４により詳細に記載される。一致した商品（一致評価基準によって規定されるように）は、承認した商品リストに自動的に移動される（ステップ２０５）。システムが、アカウント請求書および/または報告書を作成するまで、承認した商品リストは、全ての承認した取引を保留（格納）する。アカウントデータベースは、多くの異なる機能およびモジュールを共に引き付けて、データベース内の様々なデータテーブルへのアクセスを有するので、自動調停中に、オフセットが、合計がゼロに一致することを借方に記入し、貸方に記入することは、よくある状況である。これらの「ウォッシュアウトされる」取引（すなわち、ゼロに加える）は、支払期限または返金期限がないので、請求書または報告書をクライアントに送り得ない。どちらかと言えば、ウォッシュアウトされた取引は、ウォッシュアウトされるリストに移動され得る（ステップ２０６）。ウォッシュアウトされるリストは、図５で以下により詳細に記載される。

確立された一致する評価基準に合わず、「ウォッシュアウト」しない旅行およびカード取引は、未決済の取引リストに移動される（ステップ２１０）。この様態において、未決済の商品が調停されるまで（すなわち、認識し、訂正されるまで）、不一致または未決済の商品は、追跡され、調査される（ステップ２１２）。多くの場合、小さいデータ入力エラーまたはミススペルは、未決済の商品（例えば、カード請求書における不正なチケット番号）の原因になる。一実施形態において、認可されたユーザは、エラーデータを編集して、不一致商品を訂正し得る。訂正された商品（すなわち、旅行入力）は、対応する料金入力に一致し得る。この特定の実施形態において、訂正された商品は、例示の実施形態において、承認準備リストに移動され、同様または別の認可されたユーザによって承認される（ステップ２１４）。未決済取引リストおよび承認準備リストの特定の特徴は、図６ａおよび図６ｂにおいて以下により詳細に記載される。

概して、本システムの残りのステップは、生成を報告し、図７において以下により詳細に記載される。本発明システムは、全額の料金のための請求された取引報告書（「ＢＴＲ」）を作成する。全額の料金は、承認された商品リストからの支払を処理するために準備をする（ステップ２１６）。支払調停モジュールは、全てのＢＴＲを更新され、すなわち、言い換えると、支払額は、クライアントから予想される（ステップ２１８）。システムは、概要調停報告書を最適に作成する。概要調停報告書は、アカウント収支に調停を急送する（ステップ２２０）。前述のようなアカウント収支は、例えば、優先請求（ｐｒｉｏｒ ｂｉｌｌｉｎｇ）サイクルの収支といったアカウントの全ての取り組み、現在のサイクルの取り組み受けた支払、予想された支払（ＢＴＲの総額）、および未決済取引リストの取引の総額を含む。最後に、支払をクライアントから受けるとき、支払調停モジュールは更新され、予想された支払（ＢＴＲの総額）は、受けた額で調停される（ステップ２２２）。

（返済モジュールの典型的なフローチャート）
図３は、本発明に従った典型的な返済モジュールを実施する一実施形態を説明するフローチャート３００である（すなわち、ステップ２０１）。図３および添付の説明は、例えば、システムが、完全な返済管理システムとして動作し得ることをさらに示す。旅行者が、返済を目的として未使用のクーポンおよび／またはチケットを返却する場合、旅行チケット等の返済を目的として返却された各アイテムに固有のデータは、手動で入力されてもよいし、または、返済モジュールに電子的にダウンロードされてもよい(ステップ３０２)。特定の一実施形態において、システムは、顧客／旅行者のために、返却されるチケットの詳細を完全に記したレシートを生成する。システムは、各アイテムの詳細を記した返済ログを更新し、返却されたチケットのリストを保持する（ステップ３０４）。この様態では、ログは、いつでも閲覧され、返却された保留のアイテムの状態をチェックし得る。また、この技術は、返却されたアイテムが長い間忘れ去られないことを保証するためにも役立つ。実際、典型的な実施形態では、埋め合わせのクレジットを受け取るまで、または、認定されたユーザがアイテムの移転を承認するまで、返却された保留のアイテムはログに残る。

特定の実施形態において、システムは、返済処理のために返却されたアイテムを転送する際に使用することを目的として伝送ログおよび／またはレターを生成する(ステップ３０６)。例えば、伝送ログは定期的に生成されて、新規に受け取り返済されたアイテム、または、保留のアイテムの変更された状態等を示す。さらに別の実施形態において、システムは、返済処理を目的として特定の航空会社等に対して返却されるべきチケットを示すための適切なレターを生成し得る。チケットが、ある航空会社に返却される場合、または、レターが郵送される場合、返済ログは、例えば、どこで、いつ、誰にチケットおよび／またはレターが送られたのかを反映するように自動的に更新される(ステップ３０８)。

返却されたアイテムに対する返済は、航空会社から直接受け取り得る、および、顧客のカードデータにクレジットとして現れる。いくつかの例において、自動調停が、クレジットに関して受け取った情報（例えば、チケット番号）を識別し、埋め合わせのクレジットを保留の返却されたアイテムで自動的に一致させる。(様態にかかわらず)一度一致されると、返済ログは、クレジットの特別の情報(データ、および、受け取ったクレジットの総額)、および、各クレジットの状態（すなわち、未決済の取引リストにある保留のクレジットでウォッシュアウトされたクレジット、未決済の取引リストへ移動されたクレジット、請求された取引報告書に含まれたクレジット）で自動的に更新される(ステップ、３１０)。特定の一実施形態において、ユーザは、保留の返済の期間（すなわち、３０日間）を指定し、システムは、まだ受け取っていない任意の返済の状態をチェックするために、航空会社（単数または複数）への追調査レター（単数または複数）、または、催促状（単数または複数）を生成させる（ステップ３１２）。最後に、返済モジュールは、返済処理を監視する、および、監視する活動報告書を生成する報告機能を含み得る（ステップ３１４）。

（典型的なフローチャートとの一致）
図４は、本発明に従った典型的な一致処理を実施する一実施形態を説明するフローチャート４００である（すなわち、ステップ２０４）。一致するかどうかを判定する一つ以上のファクタを含む「一致基準」が本明細書で用いられることに留意されたい。この様態において、システムは、アイテムが「近い一致」と推測することはなく、むしろ、システムは、自動調停の間に、全てのファクタが満たされるかを考慮して、満たされる場合、一致される。一致基準は、例えば、高レベルの一致を判定する「基本的な」一致基準、および、一致されたアイテムが支払の準備が整ったかどうかをさらに判定する「特定の」データ捕捉基準を含み得る。例えば、基本的な一致基準は、顧客による譲渡は不可能であり得、一方で、特定の一致基準は、特定の顧客に対して特定の顧客のファクタ、および、顧客によって規定される顧客のファクタを含み得る。この様態において、顧客は、顧客が支払の準備が整ったアイテムを知覚する時を規定するユーザのためのパラメータを設定することが可能である。さらなる基準は、料金の争い、および、顧客の不満を低減することに役立つ。さらに、全ての一致基準、および、（もしあれば）データ捕捉基準が満たされ、次いで、ユーザおよび顧客に対して高められた信頼を提供した後にのみ、アイテムを承認されたアイテムリストへ信頼して移動する。

特定の一実施形態において、一致基準は、一致の許容値を含み得る。例えば、システムが、ある典型的な実施形態において、正確かつ絶対的な一致を提供するように構成されるために、しばしば、旅行取引と料金取引との間の＄０．０１の差のような小さなエラーが一致を妨げる。このように、システムは、システムが厳しい一致基準を乗り越え、かつ、一致可能にするドル一致許容値を含む。上記の例において、顧客は、＄０．９９ドル許容値の特定の一致基準を承認し得る。あるいは、ユーザ（例えば、旅行代理店）は、一致および支払処理を容易にするために、小さな差を自動的に調節かつ切り捨てるドル許容値を含み得る。たとえ一致の許容値が含まれるとしても、システムは、典型的な実施形態において、所定の一致基準を遵守することに留意されたい。本実施例において、一致基準によって、システムは、正確なドル一致のない取引間で一致させることができる。

特定の一実施形態において、システムは、各料金取引または各カード取引を考慮し、一つ以上の高いレベルの基本的な一致基準を特定して、一致を見出す（ステップ４０２）。第一の基本的な一致基準の一致を特定することによって一致取引を見出すために旅行関連のデータの検索が実行される（ステップ４０４）。一致基準を満たす記録が旅行データに見出されるとき（ステップ４０６）、次いで、一致が確認される（ステップ４０８）。確認は、残っている基本的な一致基準が満たされることを確認することによって一致が妥当であることをさらに保証する。一致が見出されない場合（ステップ４０７）、または、一致の確認が不可能である場合（ステップ４０９）、取引は、未決済の取引リストに移動される。

一実施形態において、基本的な一致基準は、四つのファクタ（すなわち、旅客名、チケット番号、カード番号、および、ドル総額）を含む。システムは、一致チケット番号を検索し、次いで、他の三つの基準が一致することを検証する。例えば、旅客者名、チケット番号、および、カード番号は一致するが、ドル総額が異なる場合、システムによってカード取引および旅行取引が一致しない。たとえチケットがリストに挙げられた旅客者によって用いられていても、旅客者は空港において旅行チケットの一部または全てを返済してもよく、ドル総額は一致しない。

一致が最初に確認されると（全ての基本的な一致基準が満たされると）、システムは、特定のデータ基準が存在する場合、その特定のデータ基準の存在を検証することによって自動確認処理を続ける（ステップ４１０）。特定のデータ基準は、顧客が規定したデータである。基本的な一致基準が満たされると、システムによって、個々の顧客は、ユーザが追跡するパラメータを発展させることが可能である。顧客のパラメータまたはファクタは、基本的な基準よりは幾分厳しくてもよいが、基本的な基準が調節されない、または、放棄されないことが好ましい。顧客に特定のデータの例は、従業員ＩＤ、プロジェクトコード、部所コード、または、旅行認証番号を含む。しかし、この基準が顧客によって規定され得、従って、アプリケーション毎に変化し得ることが認識される。いくつかの例において、または、いくつかの顧客には、任意の特定の顧客が規定したデータはなくてもよい。これらの場合において、取引は、支払処理に関して承認されたアイテムリストへ自動的に移動される（ステップ４１４）。

システムは、特定の顧客が規定した全てのデータの存在を確認する場合（ステップ４１２）、および、典型的な実施形態において、基本的な一致基準が既に確認される場合、取引は支払処理が準備されており、そして、承認されたアイテムリストへ自動的に移動される（ステップ４１４）。任意の一致基準を満たさない取引は、未決済の取引リストへ移動され、その結果、取引は調査され、かつ、修正され得る（ステップ４１３）。

（ウォッシュアウトの典型的なフローチャート）
図５は、本発明に従った典型的なウォッシュアウト処理を実行する一実施形態を説明するフローチャート５００である（すなわち、ステップ２０６）。本明細書では、「ウォッシュアウト」とは、相殺するクレジット、および、自動的に一致されたクレジットとする自動調停の間の処理を含む。言い換えると、システムが、総計がゼロとなる同じ旅行取引に対するクレジットおよびクレジットを特定する場合、システムは、これらの二つのアイテムが一致することを認識し、これらのアイテムをウォッシュアウトリストへ移動し得る。ウォッシュアウトカードか旅行取引のいずれかをさらに処理する、または、調停する必要なない。なぜなら、一時は旅行に対するクレジットの料金があり得るが、取引を明らかにするために、相殺するクレジットが受け取られる。

以前に述べたように、カードデータおよび旅行データは共に、経理データベース内へ入り、同じ旅行取引に対するクレジットおよびクレジットは、時折、同じ処理サイクル間に現れる。自動調停の間、システムは、カード取引を検索する。このカード取引は、クレジットおよびクレジットが同じチケット番号として受け取った場合、取引のためのアカウントデータベース内へロードされる（しかし、請求された取引報告書にまだ含まれていない）（ステップ５０２）。一実施形態において、ウォッシュアウトの資格を与えるために、クレジットおよびクレジットは、完全に相殺する（合計はゼロである）。従って、システムは、このことが起こるかどうかを疑う（ステップ５０４）。クレジットおよびクレジットが合計してゼロにならない場合、一致されず、クレジットおよびクレジットの取引は、調査および修正のために未決済の取引リストへ移動される（ステップ５０８）。

システムは、クレジットおよびクレジットが単独のチケット番号（または、他の識別ファクタ）で互いに完全に相殺することを検証すると、システムは、クレジットおよびクレジット取引をウォッシュアウトされたリストへ自動的に移動し得る（ステップ５０６）。特別な一実施形態において、顧客は、ウォッシュアウトされた機能を用いないことを選択してもよく、従って、この状況において、取引は、ウォッシュアウトされたリストへ移動しないが、承認されたアイテムのリストへ移動することに留意されたい。システム内の一致処理と同様に、ウォッシュアウト処理は、推測、または、「近い一致」とすることはない。ウォッシュアウトされたリストは、一実施形態において、もう処理を必要としない取引を含む。従って、取引の場所または格納場所は、ここで明確であるべきである。

ウォッシュアウト処理の別の例は、クレジットおよびクレジットが同じサイクル内で現れないときに起きる。例えば、経理データベースは、料金に関連したデータを受け取るとき、無効にされたチケットに相当する料金が存在し得る。自動調停処理は、相当する旅行取引の料金に一致不可能である。なぜなら、チケットは、無効にされ、従って、経理データベース内にロードされた今までの旅行取引の記録は存在しないからである。従って、料金の入力は、一致されないアイテムであり、未決済の取引リストへ移動される。その後、無効にされたチケットの料金に対する相殺するクレジットは、経理データベース内へロードされ得、次の自動調停処理の間に、システムは、クレジットが未決済のアイテムリスト上のアイテムに相当することを認識する（ステップ５１０）。以前の説明のように、システムは、クレジットおよびクレジットが合計してゼロになるかどうかを疑い（ステップ５０４）、合計してゼロになる場合、システムは、取引をウォッシュアウトされたリストへ移動し得る（ステップ５０６）。合計がゼロではない場合、クレジットの取引は、また、未決済の取引へ移動される（ステップ５０８）。

（未決済の取引の典型的なフローチャート）
図６ａおよび図６ｂは、本発明に従った典型的な未決済の取引処理を実行する一実施形態を説明するフローチャート６００である（すなわち、ステップ２１０−２１４）。未決済の取引リストは、システムがアカウント残高全体を調停する管理ツールであることをさらに例示する。その意味では、一致していない、そうでなければ、未決済の取引は、調査される、または、修正されるために未決済の取引リストへ移動される。

ウォッシュアウトしない、および、自動調停基準の一つ以上を満たさないアイテムは、未決済の取引リストに移動される。リスト上の各アイテムは、システムの認証されたユーザによって監視、調査、および、修正される。以前に説明されたように、システムは、典型的な実施形態において、データの質に対して「近い一致」で処理するか、または、推測するように構成されない。むしろ、システムは、典型的な実施形態において、絶対的な一致を特定し、ユーザおよび顧客は、自動的に承認された取引の正確さに疑問を持つ余地がほとんどないか、または、全くない。

たとえ小さなデータ入力エラーがある場合でも、システムの整合性を保持するために、典型的な実施形態において、システムによって、カードおよび旅行取引は承認不可能である。例えば、旅客者の名前が請求書に誤って綴られることによって、システムが関連する旅行の記録に一致しない取引を承認することを妨げ得る。特定の一実施形態において、システムは、認可されたユーザが未決済の取引を閲覧可能にする（ステップ６０２）。認可されたユーザ（ステップ６０４）は、未決済の取引（ステップ６０６）への編集（ステップ６０９）を許可され得、修正された取引を承認リストのための準備に転送する（ステップ６０９）。

別の実施形態において、ユーザは、作成された調査ツールにアクセスし、保留の未決済のアイテムの修正を容易にする（ステップ６０８）。このツールは、保留のアイテム（例えば、カード取引）の全ての詳細を表示させ、ユーザは、一致取引（例えば、旅行取引）を検索する基準を特定することを可能にする（ステップ６１０）。ツールは、提案された検索基準、または、初期基準値を提供し得る。この特定の実施形態において、ユーザは、システムによって設定された厳しい一致基準を無効にし得、従って、システムは、正確な、または、ほぼ正確な、相当する一致取引を検索可能である（ステップ６１２）（すなわち、近い一致）。システムツールは、位置付けられた取引を表示し、ユーザが、正確な一致を選択することが可能になる（ステップ６１４）。一致、および／または、修正が完了するとき（ステップ６１６）、システムは、アイテムを承認準備リストへ移動する（ステップ６０９）。

別の実施形態において、ユーザは、部分的に一致するアイテムを調査することを許可される。例えば、チケットが発行されて、相当する料金は、＄４２０．００であることを想定する。空港で、旅客者は、（例えば、悪天候により）次のフライトがキャンセルされ、航空会社は、総額＄１２０．００の部分的なクレジットを発行することを知らされる。旅行者は戻ってきて、旅行者が旅行しなかったことを会社Ａに知らせる。次いで、会社Ａは、総額＄４２０．００の元のチケットの料金を払うことを断る。＄４２０．００の料金は、未決済のアイテムリストに移動される。＄１２０．００のクレジットを受け取ると、ドル総額が一致しないので、システムは、クレジットと＄４２０．００のクレジットとを一致しない。＄１２０．００のクレジットは、また、未決済の取引リストに移動される。未決済の取引リストを閲覧する認可されたユーザは、同じチケット番号に対する複数のカード取引（クレジットおよびクレジット）が存在することを容易に認識し得、部分的なクレジットを受け取ることを推論し得る。ユーザは、クレジットに対してクレジットを加えることを許可され、残っている残高と旅行の取引とを一致することを許可される。再び、取引は、承認準備リストに移動され、保留の承認および支払処理が実行される（ステップ６０９）。この処理は、一致されなかった取引が忘れ去られず、または、部分的な一致が不適切にＢＴＲに捕捉されないことよりはむしろ、顧客が、正確な総計（例えば、上記の例において、顧客は、＄３００．００（受け取るクレジットより少ない元のクレジット）を請求される）に対して適切に請求されることを保証する。

承認準備リストは、処理の整合性をさらに保持する安全対策を提供する。一つの特定の実施形態において、承認された認可のいくつかの段階が、アクセスの妥当なレベルを許可するように設置され得る。一つのレベルにおいて、認可されたユーザは、チケット番号、旅客者名およびドルの総計を編集するためのアクセスについては承諾され得るが、取引を承認し、承認されたアイテムリストへ移動するためのアクセスについては制限されている。さらなるエラーの生成は、ユーザによる任意の変化に関係がある。この意味において、より高いレベルの認可を有するユーザによって最終的に承認されることが、好まれ得る。

承認のために選択された取引は、認可されたユーザに対して、承認準備リスト上に表示される（ステップ６１８）。システムは、ユーザの認可レベルを疑い得、必要とされる認可レベルが満たされない場合、アクセスを制限し得る（ステップ６２０）。一実施形態において、システムは、認可された承認ユーザに対する修正された取引「前後の」写真を表示させる（ステップ６２２）。言い換えると、閲覧者は、プレ修正またはプレ一致取引、および、ポスト修正またはポスト一致取引を見てもよい。承認者は、修正を閲覧し得、必要ならば変化の正確さを検証し得る。いくつかの場合において、取引に対する修正があり得るが、旅行インボイス総額とは異なる請求総額が、認可されたユーザによって受け取られる。承認者が、一致または変化に同意する場合（ステップ６２４）、取引は、承認されたアイテムリストに移動される（ステップ６２６）。しかし、承認者が取引を承認しない場合、承認者は、さらなる調査および修正に対する未決済の取引リストへ取引を戻し得る（ステップ６２５）。

（報告書生成の例示的なフローチャート）
図７は、本発明による例示的な報告書作成プロセス（すなわち、ステップ２１６〜２２２）を実現するための一実施形態を示すフローチャート７００である。様々なアイテムが所望の報告書に要約され、作成されることが理解される。本明細書中に与えられた報告書の記載が例として与えられ、任意の態様に限定されないことが意図される。

一実施形態では、承認されたアイテムのリストは、自動調停の間に基準に適合する全ての取引、および承認されたユーザ（すなわち、図６ａ〜図６ｂ）によって最終的に認定された全ての取引を保持する。承認されたアイテムのリストから、システムは、支払のために処理される態勢が整っている取引の全てを自動的に取り込み（ステップ７０２）、請求された取引報告書（「ＢＴＲ」）を生成する（ステップ７０４）。各取引が所定の一致基準を満たすかまたは最終的に承認されたため、典型的には、さらなる承認は要求されない。一般的に、請求された取引報告書は請求書ではなく、クライアントがカード計算書（すなわち、クレジットカード会社から受け取った）の料金のそれぞれを特定するための調停手段として使用される。言い換えれば、典型的には、クライアントは、所与の請求書作成サイクル（ｂｉｌｌｉｎｇ ｃｙｃｌｅ）の間、クレジットカード会社から、料金請求される取引に対する請求書を受け取る。請求された取引報告書（および概して本発明）は、クライアントが特定し、支払期限が来ているクライアントの請求書の全ての請求額の識別（すなわち、アカウント収支（ａｃｃｏｕｎｔ ｂａｌａｎｃｅ）に調停すること）を提供することによってクライアントの現在の請求書作成および支払方法を完全にするように設計される。

ある特定の実施形態では、システムは、クライアントの検討のための所与のサイクルの間、請求された取引報告書のコピーを印刷する。あるいは、請求された取引報告書が、電子フォーマットでクライアントに提供され得る（例えば、適切な通信ネットワークを介して）。クライアント側が適切なソフトウェアを含み、請求された報告書が、クライアント自身のアカウントシステムに転送されることを可能にする。

ある特定の実施形態では、クライアントについての支払調停モジュールが、現在の請求された取引報告書（ステップ７０６）の全体の額を反映するように更新される。支払調停モジュールは、請求された取引報告書をアカウントすることである。例えば、支払調停モジュールは、請求書が作成された取引報告書全体についてのエントリおよび「継続中の（ｏｐｅｎ）」残りの額のエントリを含み得る。支払がアカウントで受け取られた場合（ステップ７０７）、継続中の残りの額が支払額によって低減される。理想的には、クライアントは、請求された取引報告書の全体に等しい支払を提示するが、これは常にこの支払を提示するとは限らないかもしれない。例えば、クライアントは、この請求書の料金（および請求書された取引報告書の料金でさえも）、およびこの料金に対して提示されていない支払について異議を唱え得る。支払調停モジュールは、クライアントから受け取った支払の額をトラッキングし、請求書された取引報告書に関する任意の残りの収支（継続中の額）を識別する（ステップ７０８）。次いで、ユーザは、請求された取引報告書に関する特定の取引を有する残りの収支に一致させ得、どのアイテムがクライアントによって未払いであったかを判定し得る（ステップ７１０）。次いで、この取引は、報告書が作成された取引報告リストから取り除かれ、その取引が支払われていなかった理由に関するさらなる調査のための未決済の取引リストに掲載され得る（ステップ７１１）。

別の特定の実施形態では、クライアントのアカウントのための概要調停報告書が、アカウント収支に対するクライアントのアカウントの活況（ａｃｔｉｖｉｔｙ）を自動的に調停する（ステップ７１２）。この操作は以下により詳細に説明される。図８は、ユーザ（クライアント側）が見た概要調停報告書画面８００の例を示す。このスクリーン８００は、アカウント（ドル金額で表示されている）が、アカウント収支に調停されるユーザアカウントを示す。適切な記憶装置からの取り出し、処理、およびフォーマットのような種々のシステム操作が、その報告書のエントリのそれぞれについて十分に説明されていないことが理解され得るが、所望の表示を実行するために、これらの種々の動作および他の動作が必要であり得ることは、当業者に理解される。このシステムは、クライアントのカード計算書８０１からの以前の請求書作成サイクルの終了収支から開始し、これを表示する。次いで現在のサイクルの活況（新しい料金およびクレジット）８０４が、クライアントが負担すべき任意の新しい料金８０６と共に表示され、終了収支に追加される。もしあったとしても、アカウント８０８で受け取られた支払のドル金額が、収支から差し引かれる。

予測または保留中の支払８１０は、スクリーン８００上に表示される。この予測された支払は、ＢＴＲからの全金額（より詳細には、支払調停モジュールからの全金額）を含む。例えば、以前に説明したように、支払調停モジュールは、ＢＴＲをトラッキングし、アカウントで受け取られる任意の支払が、未払いのＢＴＲ収支に対して適用される。画面８００上に示されるように、例示的なアカウントに残っている２つの未払いのＢＴＲ（５月の請求額８０７および４月の請求額８０９）がある。ＢＴＲ８１１に適用される任意の支払が表示され、残りのＢＴＲ合計８１０が予測された支払である。ＢＴＲが、認定されたアイテムリストに関する取引のみを含むため、このシステムは、ＢＴＲの合計が支払の時期が来た（従って調停された）アイテムであると考えられる。この意味では、ＢＴＲの合計８１０は、収支から差し引かれる（この時点では、収支は８０２＋８０４＋８０６−８０８）。

次いで、決済データベース８１２において、全ての取引の全ドル金額が表示される。これらの取引はクライアントのカードの請求書からデータベースにロードされるが、自動調停を受けない。従って、このドル金額は、残りの請求収支を説明し（なおも保留中にもかかわらず）、残りの請求収支から差し引かれる。次いで、承認準備中のリスト８１４および承認されたアイテムリスト８１６の全体が残りの収支から差し引かれる。全ての追加および差し引きの後の終了収支８１８は、最終的な残りの収支である。

アカウントを識別することは、クライアントのアカウントの収支を調停し、未決済の取引リスト８２０上で保留中の取引の全体が表示される。終了収支８１８および未決済のアイテム８２０の金額が一致する場合、アカウントは釣り合いが取れる。

本発明は例示的な実施形態を参照して説明されてきたが、この開示を読む当業者は、変更および改変が、本発明の範囲から逸脱することなく実施形態に対して為されることを理解する。例えば、旅行産業（特に旅行代理産業）に関連して簡便に説明されるが、本発明は限定されない。むしろ、調停をアカウントするために、自動化された効率的かつコスト節減アプローチを望む種々の産業は、上掲の特許請求の範囲に表現されたものとして本発明のシステムおよび方法から利益を受ける。

図１ａは、本発明のアカウント調停システムを実現するのに用いられ得るコンピュータベースのアーキテクチャの例示図である。 図１ｂは、アカウント調停システムが本発明の１つの実施形態に従って機能して動作し得る環境を示すトップレベルの例示図である。 図２は、本発明に従うアカウント調停の１つの実施形態を記述する例示のフローチャートである。 図３は、返済管理のための本発明の１つの実施形態を記述する例示のフローチャートである。 図４は、取引を一致させるための本発明の１つの実施形態を記述する例示のフローチャートである。 図５は、取引を消去するための本発明の１つの実施形態を記述する例示のフローチャートである。 図６ａは、未解決の取引管理のための本発明の１つの実施形態を記述する例示のフローチャートである。 図６ｂは、未解決の取引管理のための本発明の１つの実施形態を記述する例示のフローチャートである。 図７は、報告書作成のための本発明の１つの実施形態を記述する例示のフローチャートである。 図８は、本発明のシステムおよび方法に従って、ユーザに利用される調停報告書の要旨の例示のスクリーン画面である。

Claims (1)

1. アカウントのためのアカウント調停を提供する方法であって、
   ａ．複数の商取引および複数の料金取引を計算デバイスにおいて受け取るステップと、
   ｂ．該計算デバイスのデータベース内の保留中のリスト上に該商取引および該料金取引を格納するステップと、
   ｃ．該商取引のうちの少なくとも１つおよび該料金取引のうちの少なくとも１つを含む該保留リストからの一致を識別するステップであって、該一致は、該取引の間で共有された共通性によって決定される、ステップと、
   ｄ．該データベース内の承認されたアイテム上の該一致を格納するステップと、
   ｅ．ステップｃ〜ｄを繰り返して、他の一致を識別するステップと、
   ｆ．該データベース内の未決済の取引リスト上の該保留リストから、もしあれば、不一致商取引および該料金取引を格納するステップと、
   ｇ．該商取引のうちの１つおよび該料金取引のうちの１つを含む該データベースを近似一致のために検索するステップと、
   ｈ．該近似一致の承認通知を受け取るステップと、
   ｉ．該承認されたアイテムリスト上の該近似一致を格納するステップと、
   ｊ．ステップｇ〜ｊを繰り返して、他の近似一致を承認するステップと
   を包含する、方法。

Images