JP5084261B2 - 取引処理のためのコンピュータベースシステム - Google Patents

Description

発明の詳細な説明

［発明の技術分野］
本発明は、取引処理のためのコンピュータベースシステム及びこれに適したコンピュータプログラムプロダクトに関する。より詳細には、本発明は、個々の口座の会計処理を維持しながら、発注を受付け、支払を処理するコンピュータベースシステムに関する。具体的には、本発明は、顧客と企業との取引のためのものであって、企業に利用され、通信ネットワークを介し顧客にアクセス可能なサーバと、当該サーバ上に収容され、顧客に係る会計記帳を含む顧客口座とを有するコンピュータベースシステムに関する。

［発明の背景］
顧客注文のファイリング、顧客請求書の発行及び顧客支払処理は、最も一般的な取引処理である。しかしながら、これらシンプルなやりとりは、エラー、非効率性及び顧客の不満のソースのままである。従って、これらは、取引処理の精度と効率を向上させ、顧客企業間の通信を向上させ、コストを低減し、エラーを最小化する必要を維持する。適切な取引処理アプローチは、顧客企業間取引の性質にかなり大きく依存する。

多数の顧客要求を処理する一般的取引は、保険産業である。このような分野は、多数の顧客要求を受付け、このため、多数の取引を迅速かつ効率的に処理する必要がある。しかしながら、事故に対する顧客の請求と、当該請求を決済する保険会社の最終的支払との間のやりとりには、多くのエラーが発生する。保険会社が正確かつ確実に顧客の請求を精査する者と個別に各請求を処理するには多大な負担が必要とされる。従って、各顧客の請求が顧客への支払前に保険会社の代表者により個別に検討される必要があるとき、保険会社は負担コストに関する大きなコストを被ることとなる。

同様に、再保険会社は、保険会社が再保険会社との間で有する各種契約に関連し、各保険会社により所有される保険料支払を記録する保険会社による多数の請求を考慮する必要があるかもしれない。再保険会社と保険会社とのやりとりは信頼に基づくものであるが、それは保険料と支払の処理のためかなりの労力を要するものとなる。他方、顧客と保険会社とのやりとりは、少なくとも保険料は固定され、請求は自動的に送付可能であるため、それほど人手のかかるものではない。

例えば、保険会社が再保険会社に請求をすると、再保険会社は、しばしば請求の有効性及び信頼性の詳細を検討する面倒な作業をすることなく、当該請求を決済するため支払を型通り準備する。これにより、再保険会社は、保険会社が当該２つの企業との間の合意に従い、再保険会社に不当又は不合理な影響を与えない請求を提示していると「信頼」している。さらに、保険会社の請求を決済するための上記支払は、典型的には、請求処理並びに支払準備及び移転に係る通常の遅延により遅れている。同様に、保険会社から再保険会社への保険料の支払いを処理することに関する「信頼」問題が存在する。

最後に、再保険会社は、典型的には、一般にその顧客（保険会社）レベルでは個別契約への支払、請求又は保険料の配分は存在しないという点で、保険会社が提示した請求の適切な会計処理していない。従って、保険会社に対する信頼以外に、請求がこれら２つの企業間の契約の境界内のものであり、契約制限を超えるものでないということの信頼性はほとんどない。

従って、顧客と保険会社との取引を処理する再保険会社のルーチンには非効率さが存在する。このような非効率さは、逸失収入及び不正確又は遅延した会計処理を潜在的に招く。

典型的には、保険料を自動請求するよう構成された取引処理のためのコンピュータベースシステムは、システムと顧客との間の大量のデータ処理をもたらす。さらに、顧客と金融機関及び金融機関とシステムとの間の対応する数の財務処理が、請求した保険料の支払いに必要とされる。同様に、請求の支払は、システムと金融機関との間の大量の財務処理に依存する。通信ネットワークを介し電子的にデータ及び財務処理を実行することは、かなりの通信ネットワークの帯域幅を必要とすると共に、財務処理を実行及び記録するのにプロセッサ及びメモリリソースを必要とする。典型的には、保険料の請求はまた、システムが顧客に物理的送信される必要がある大量の郵便物を生成することを要する。
ＷＯ０２／３７７８６において、選択した口座からを請求の支払をするため資金を移転するシステムが記載されている。ＷＯ０２／３７７８６によるシステムは、効率的な取引を選択するルールベース最適化装置を有する。具体的には、ＷＯ０２／３７７８６によるシステムは、請求の支払及びかようなソース資金から選択された受取口座への他の支払を管理するインタフェースを支払イニシエータに提供する。ルールベース最適化装置は、ユーザが選択した支払に利用可能な最も効率的な移転機構を用いて、ソース資金から受取口座への取引を自動的に駆動する。例えば、ＷＯ０２／３７７８６によるシステムは、最適な利用可能な移転を行うため、資金の移転のコスト及び送信スケジュールを解析する。他の最適化要因として、口座最少額や支払閾値が含まれるかもしれない。当該システムはまた、例えば、１ヶ月間の１つの銀行への１つの支払イニシエータの支払のすべてを合計するなど、効率を向上させるため複数の支払取引を集計する。

［発明の概要］
本発明の課題は、従来技術の問題点を有しない顧客と企業との間の事業を処理するコンピュータベースシステム及びコンピュータプログラムプロダクトを提供することである。特に、本発明の課題は、データ及び金融取引を実行及び請求するための技術インフラに関する要求を抑えながら、システムが顧客との取引を処理する効率を向上させる顧客と企業との間の事業を処理するコンピュータベースシステム及びコンピュータプログラムプロダクトを提供することである。

本発明によると、上記課題は、特に独立クレームの特徴を通じて実現される。さらに、さらなる効果的な実施例が、従属クレーム及び記載から導かれる。

顧客と企業との間の事業を処理するコンピュータベースシステムは、企業により用いられるサーバを有する。当該サーバは、例えば、端末を利用することにより、通信ネットワークを介し顧客によりアクセス可能である。顧客に関する口座記帳を含む顧客口座が、サーバに収容される。

本発明によると、上記課題は、システムが顧客が通信ネットワークを介し顧客に関する口座記帳のリストからオープンアイテムを選択することを可能にするものであって、当該システムにより自動処理される機能を通信ネットワークを介し顧客が選択する手段を有することにより特に実現される。さらに、本発明のシステムは、口座記帳のそれぞれに関する顧客に支払われる借方又は前記企業に支払われる貸方の状態を考慮して、口座記帳リストから選択されたアイテムに対するバランスを計算する手段を有する。本発明のシステムはまた、バランスを所定の金額と比較し、バランスが所定の金額以下であるとき、支払をすることなく口座記帳リストから選択されたアイテムを相殺する手段を有する。一方では、顧客が顧客の口座にリモートアクセスし、口座記帳のリストからオープンアイテムを選択する、すなわち、顧客の口座記帳を選択的にグループ化し、システムにより自動処理される機能を選択する、すなわち、指定された口座記帳グループに適用される財務処理を選択することを可能にするため、顧客との取引を処理するシステム内の効率性及びフレキシビリティを向上する。顧客口座の構成と顧客口座記帳の割当てが顧客により制御される。顧客は、登録について完全な透過性を有し、企業のスタッフに関与することなく顧客口座を調整することが可能となる。他方、貸方／借方のバランスポジションに応じて、顧客が財務処理をやりとりし、トリガーすることが可能となるため、データ及び財務処理を実行及び請求する技術インフラに対する要求が低減される。例えば、選択された支払通知機能又は支払要求機能が少額に関するものであるとき、支払取引を回避することができる。特に、顧客への支払及び当該支払に関するすべてのデータ通信は、支払要求に関する貸方及び借方が小さなバランスとなるよう選択されるときには実行される必要がない。同様に、顧客からの支払発注及び当該支払発注に関するすべてのデータ通信は、支払要求に関する貸方及び借方が小さなバランスとなるよう選択されるときには実行される必要がない。従って、財務処理の実行回数は低減され、請求を解消又は少なくとも大きく減少させることができる。この結果、データ及び財務処理を実行し、請求するための技術インフラに対する要求を低減することができる。なぜなら、通信ネットワークの帯域幅と財務処理を実行するのに要するプロセッサ及びメモリリソースが低減され、保険料を請求するのに必要な郵便物の量を減らすことができるためである。

好ましくは、本システムはさらに、選択された機能として支払通知を継続する前に、バランスが当該システムに許容されるか確認する手段を有する。さらに好ましくは、本システムは、選択された機能として支払通知を継続する前に、バランスが顧客に許容されるか確認する手段を有する。各口座記帳グループのバランスに応じて、口座記帳の財務処理及び決済の実行を禁止することは、不要な取引及びデータ通信が回避されるという効果を有する。従って、データ及び財務処理を実行する技術インフラに対する要求をさらに低減することができる。

好適な実施例では、本システムはさらに、バランスがゼロであるとき、提出支払通知ボタンを顧客に利用不可とする手段を有する。ユーザからボタンを視覚的に隠すことによって、支払通知処理を実行すべきか否かに対する制御が、顧客から削除される。このことは、システムが、バランスがゼロであるときに支払通知を実行することなく、選択された各口座記帳グループを相殺することを可能にする。従って、システムを利用する企業がそれの貸方の少額の残余バランス控除することを所望する場合、財務処理及び当該財務処理に関するデータ通信を回避することが可能となる。

好適な実施例では、本システムはさらに、選択された機能として支払通知に関する一意的な参照番号を生成し、通信ネットワークを介し顧客に通信する手段を有する。さらに、本システムは、通信ネットワークを介し電子支払発注を受付け、該電子支払発注に含まれる一意的な参照番号に基づき、口座記帳リストから選択されたアイテムと電子支払発注をペアリングする手段を有する。請求書及び関連する請求書番号を発行する必要なく、システムが顧客から受け付けた支払発注と口座記帳をマッチングすることを可能にする。この結果、口座記帳と支払発注をマッチングする効果を維持しながら、請求書を生成し、顧客に送信する処理パワー及びエネルギーを節約することができる。

好適な実施例では、本システムはさらに、顧客からの支払を表す口座記帳を未決済の口座記帳に通信ネットワークを介し顧客が割り当てる手段を有する。さらに、本システムは、支払を表す口座記帳と割り当てられた未決済の口座記帳との差を計算し、該差が所定の金額以下であるとき、差を控除する手段を有する。顧客からの支払は、未決済の口座記帳と顧客により直接マッチングすることができる。システムが顧客に請求書を作成及び送信する必要はなく、また、顧客に通信され、以降において顧客によりシステムに通知されねばならない参照番号も必要でない。さらに、システムが貸方の少額の残余バランスを控除することを所望する場合、残余バランスの請求を回避することができる。

顧客と企業との間の事業を処理するコンピュータベースシステムに加えて、本発明はまた、コンピュータの１以上のプロセッサを制御するコンピュータプログラムコード手段を有するコンピュータプログラムプロダクト、特に当該コンピュータプログラムコード手段を有するコンピュータ可読媒体を有するコンピュータプログラムプロダクトに関する。当該コンピュータプログラムコード手段は、コンピュータが顧客と企業との間の事業を処理する上述のコンピュータベースシステムのすべての機能を実行するように、コンピュータのプロセッサを制御するよう構成される。好ましくは、コンピュータプログラムコード手段は、コンピュータが顧客と企業との間の事業を処理する上述のコンピュータベースシステムのすべての機能を実行するサーバを実現するように、コンピュータのプロセッサを制御するよう構成される。具体的には、コンピュータプログラムプロダクトにより制御されると、コンピュータは、顧客に関する口座記帳リストから通信ネットワークを介しオープンアイテムを顧客が選択することを可能にするものであって、コンピュータにより自動処理される機能を選択する命令を、顧客から通信ネットワークを介し受け付ける。コンピュータは、口座記帳のそれぞれに関する顧客に支払われる借方又は企業に支払われる貸方の状態を考慮して、口座記帳リストから選択されたアイテムに対するバランスを計算する。コンピュータは、バランスを所定の金額と比較し、バランスが所定の金額以下であるとき、支払をすることなく口座記帳グループを相殺する。

好ましくは、コンピュータプログラムプロダクトにより制御されると、コンピュータは、選択された機能として支払通知を継続する前に、バランスがシステムに許容されるか確認し、選択された機能として支払通知を継続する前に、バランスが顧客に許容されるか確認する。

好適な実施例では、コンピュータプログラムプロダクトにより制御されると、コンピュータは、バランスがゼロであるとき、提出支払通知ボタンを顧客に利用不可とする。

好適な実施例では、コンピュータプログラムプロダクトにより制御されると、コンピュータは、選択された機能として支払通知に関する一意的な参照番号を生成し、通信ネットワークを介し顧客に通信する。コンピュータは、通信ネットワークを介し電子支払発注を受付け、該電子支払発注に含まれる一意的な参照番号に基づき、口座記帳リストから選択されたアイテムと電子支払発注をペアリングする。

好適な実施例では、コンピュータプログラムプロダクトにより制御されると、コンピュータは、顧客からの支払を表す口座記帳を未決済の口座記帳に割り当てる命令を顧客から通信ネットワークを介し受付ける。コンピュータは、支払を表す口座記帳と割り当てられた未決済の口座記帳との差を計算し、該差が所定の金額以下であるとき、差を控除する。

ここで与えられた実施例に記載されるように、本発明は、２以上の主体間において事業に典型的に生じる効率性及び不正確さの問題点を解消する。このような主体は、個人、企業、機関又は政府を含むかもしれない。本開示を通じて提供される具体例は、再保険会社とそれの顧客である保険会社との間のやりとりに関するものである。しかしながら、これらの具体例は、簡単化のため単に与えられたものであり、本発明を限定するものではない。

［好適実施例の詳細な説明］
本発明による一例となるシステム及び方法は、顧客と企業との間の取引を容易にするため、顧客と企業との間の汎用的インタフェースを利用するものである。ここで与えられる一例となるシステム及び方法は、従来の請求処理ルーチンに係る時間と労力を低減し、上記主体間の取引のコストを減少させ、効率を向上させる。ここで開示される実施例は、具体例として再保険会社を参照するが、本発明は当該タイプの業種に限定されるものではない。他のタイプの業種もここで開示されたシステム及び方法から恩恵を受けることができる。例えば、保険会社、政府機関、ファンド又はライセンスを配布する他の主体、又は他の同様の企業又は機関もまた、特定の構成に従った当業者に明らかな想定される変更を行うことにより、ここで開示されたシステム及び方法から恩恵を受けることができる。

上述のように、例えば、再保険会社は再保険会社とその顧客（保険会社）との間の比較的高いレベルの信頼性により特徴付けされている。さらに、典型的には、各顧客と再保険会社との間には大量の取引がある。すなわち、一見の顧客はまれである。再保険会社の上記特徴は、取引処理を向上させる機会を創出する。

再保険会社とその顧客（保険会社）との間の比較的高いレベルの信頼性のため、顧客が内部の会計記録にアクセスすることを許可することが実際的である。このように、顧客は記録を閲覧し、精度及び効率性を向上させるため、入力（支払通知又は支払要求など）を与えることができる。もちろん、このような顧客とのやりとりを容易にするユーザインタフェースが存在する必要がある。さらに、各顧客と再保険会社との間には典型的には大量の取引が存在するため、貸借を対にして、相殺することにより取引処理を向上させることができる。

保険会社と再保険会社に関して、図１において、顧客請求を受付及び処理するプロセスが示される。システム１００は、フロントオフィス部分１１１とバックオフィス部分１１２とを有する。ある機能を有するフロントオフィス部分１１１とバックオフィス部分１１２が示されているが、このような機能は、各オフィス部分１１１又は１１２が図１に示されるものより多い又は少ない機能を有するようにシフトされてもよい。

フロントオフィス部分１１１は、主にプレースメント機能１３０に関するものである。一般に、プレースメント１３０は、リスクを分散するため顧客（保険会社など）と企業（再保険会社など）との間の交渉に関するものである。交渉の最終結果は、典型的には、契約や約束又は既存の契約又は約束に対する変更である。複数の契約群１３１と１３３は、このフロントオフィス部分１１１の機能において取得される。各契約群１３１と１３３は、１以上の特徴を共有するものであってもよい。このような引受１３１及び１３３は、例えば、同一系列の契約、通貨、再保険のタイプ、再保険済みなどを含むものであってもよい。各契約群は、１つの契約から数千の契約を含むものであってもよい。他のタイプ又は構成の契約群もまた可能である。

プレースメント１３０の後、本プロセスは、技術的会計処理コンポーネント１４０と財務会計コンポーネント１５０を含むバックオフィス部分１１２の機能系列に移行する。技術的会計処理コンポーネント１４０では、引受１３１及び１３３は、２つの請求ボルド（ｂｏｒｄｅｒｅａｕｘ）１４１及び１４３と、保険料ボルド１４２及び１４４をそれぞれ導く。一般に、ボルドとは、指定された契約群の一定の会計処理機関のすべての保険料又は請求の動きのリストである。合計は、当座勘定を含む財務会計処理コンポーネント１５０に示される。すべての詳細な動きが、擬似的会計処理コンポーネント１４０に示される。このとき、２つのボルドはそれぞれ、合意した会計処理期間ごとの口座１５１又は１５３の１つの明細書に対する基礎となる。このような期間は、例えば、月単位、四半期単位、又は他の確定可能な期間とすることができる。このとき、口座１５１と１５３の１以上の明細書により、当座勘定を含む財務会計処理機能１５０が導かれる。当座勘定は、顧客が支払要求１６１、支払通知１６２又はペアリングアドバイス１６３などの１以上の財務取引を実行することを可能にする。各取引が以下においてより詳細に説明される。他の財務取引もまた可能である。さらに、当座勘定から、すでに提出された支払要求を閲覧し、支払通知を閲覧及び／又は削除し、支払を閲覧し、ペアリング情報を閲覧することが可能である。

図１に示されるシステム及び方法の機能面を参照するに、当座勘定又は財務会計処理機能１５０は、顧客が閲覧可能な再保険価値連鎖の最後のステップである。さらに典型的には、顧客ごとに１つの当座勘定が存在し、技術的再保険記帳（口座１５１又は１５３の明細書など）、現金要求関連記帳、支払記帳及びマッチング／ペアリング状態に関する情報のすべてのバランスを含む。現金要求は、保険会社が大きな請求決済の場合に再保険者から要求する前受金である。その金額は、次の通常の口座明細書において借方記入される。

図２は、本発明の一例となるシステムを示す概略図である。本発明のシステム２００は、サーバ２４０と口座処理エンジン２５０とを有する。サーバ２４０は、１つのサーバ又はサーバネットワークから構成することができる。サーバ２４０は、企業２３０に関連付けされる。例えば、サーバ２４０は、企業２３０により、又はその代わりに、所有、運営又は維持することができる。サーバ２４０は、口座処理エンジン２５０に関連付けされる。口座処理エンジン２５０は、ここで開示されるような本発明によるプロセス及び方法を実行するよう構成されたプロセッサに関連付けされる。例えば、アプリケーション処理エンジン２５０は、当座勘定により呼び出される各種プロセスを実行するようにしてもよい。

サーバ２４０は、ネットワーク２２０を開始１以上の顧客２１０にアクセス可能である。サーバ２４０のファイアウォール２４２が、サーバ２４０への未認証のアクセスを防ぐよう設けられる。ファイアウォール２４２を使用することは周知であり、ここでは詳細には説明されない。

顧客２１０及び企業２３０は、ネットワーク２２０を介し互いに通信可能である。ネットワーク２２０は、任意の既知の通信ネットワークとすることができる。好ましくは、ネットワーク２２０はインターネットである。再保険産業に関して、顧客２１０は、被保険者に保険契約を販売する保険会社である。企業２３０は、顧客２１０の保険契約に係る再保険サービスを提供するため顧客２１０を処理する再保険会社である。

例えば、顧客２１０（保険会社など）が入力データを含む支払通知を企業２３０に与えると、この入力データはサーバ２４０に係るアプリケーションモジュールに送られる。便宜上、アプリケーションモジュールに係るプロセスは、移行において「当座勘定」プロセスと呼ぶ。

顧客２１０により与えられる入力データが最低限のデータ品質要求に適合することを技術的に保証するため、当該要求がまず検証される。このデータ品質要求は、例えば、正確なシンタックスを有することが可能であり、入力データの各値は所定の（内容依存性の低い）範囲内であり、当該要求の各値間の基本的関係が正しい（例えば、ＤＡＴＥ１がＤＡＴＥ２より前である）、などである。

次に、サーバ２４０に係るモジュール／ファンクションは、当座勘定内の複数のプロセスに対する企業検証規則に集中することができる。例えば、当該プロセスは、支払通知、支払要求及びペアリング通知を含むものであってもよい。企業検証規則は、顧客の自由を所望のデータ範囲に制限することができ、当該プロセスを標準化するのに利用される。フィルタ規則又は「企業チェック」がまた、企業による人手の介入を必要とするか移行において決定するのに提供されてもよい。

本発明のシステム及び方法は、企業が当該システム及び／又は方法を利用することによって、最小限の人手の介入により顧客に容易にアクセス可能かつユーザフレンドリなものとなるよう構成される。従って、本発明のシステム及び／又は方法へのアクセスを提供する非限定的手段は、インターネットを介するものである。顧客は、インターネットアクセスを可能にする状況において、何時でも何処でもインターネットを介し顧客口座に容易にアクセスできる。このようなアクセスは、有線手段を介し又は遠隔的に提供されてもよい。すなわち、ネットワーク２２０はまた、モバイル無線ネットワークやワイヤレスローカルエリアネットワーク（ＷＬＡＮ）などの無線ネットワークを含むものであってもよい。このような口座アクセスに対する時間及び場所に関する制約の欠如及びフレキシビリティの増大は、顧客に大きな恩恵を提供する。同様に、顧客に提供されるこのようなフレキシビリティは、このようなフレキシビリティに魅力を感じる人々の顧客基盤の増大を当該企業に提供する。

顧客は、例えば、顧客口座へのアクセスを可能にする特定のインターネットアドレスをタイプすることによって、本発明によるシステムにアクセスするようにしてもよい。典型的には、ログインページを用いて、顧客口座へのセキュアなアクセスを保証し、顧客口座の未認証又は不正使用を禁止するようにしてもよい。顧客が顧客口座に適切にログインすると、図３の一例となる画面表示３００に示されるような各種選択肢ページを有するメニュー起動ホームページが提供されるようにしてもよい。特定の機能及び特徴を有する画面表示３００が示されるが、図５に示される画面表示５００や図６に示される画面表示６００などの他の画面表示は、本発明の範囲内に属し、図３に示される画面表示に限定されるものではない。

多数のメニューアイテム３１０を有する一例となる画面表示３００が示される。各メニューアイテムは、顧客に対する機能及び選択肢の独立した画面を有する。図３に示される一例となるメニューアイテムは、当座勘定３１３である。他のメニュー選択肢には、以下に限定されるものではないが、制約３１１、プレースメント３１２、ユーザ管理３１４、アドレスブック３１５及び統計３１６が含まれる。契約３１１は、契約限度の詳細を閲覧し、保険料／請求ボルドにアクセスするためのものである。プレースメント３１２は、保険及び再保険企業が申し込み、反対申し込み、受付又は拒絶を提出する交渉の場である。ユーザ管理３１４では、保険会社は、それの顧客口座（すなわち、ユーザパスワード、ユーザアクセス権限、企業アドレス及び企業銀行口座）を管理することができる。アドレスブック３１５は、クライアントが他の再保険会社への申し込みの転送を所望する場合、他の（競合する）再保険会社の電子メールアカウントを登録するのに利用されるかもしれない。統計３１６により、保険会社は、営業記録及び再保険会社との取引に関するオンラインレポートを生成及び閲覧することができる。当座勘定３１３が一例として図３に示されるが、それは本発明を限定するものではなく、各種画面表示が利用可能である。

図３に示される当座勘定３１３内には、顧客のアクセス及び機能を容易にするさらにいくつかの選択肢が、顧客に提供される。ヘッダセクション３２０は、顧客が顧客口座の一部又はすべてにアクセスするのに変更可能な容易にアクセス可能なパラメータを提供する。ヘッダセクションにおいて変更可能な選択肢の一部には、以下に限定されるものではないが、分析に対するエントリ日付、取引通貨及び各種口座登録の状態が含まれる。ヘッダセクション３２０はまた、グループ企業情報、登録日付、予約状態及び通貨により当座勘定をフィルタリングすることができる。複数の再保険会社がアプリケーションに関連付けされている場合、再保険会社によるフィルタリングなどの他の選択肢が可能である。

当座勘定３１３の画面表示３００の他のセクションは、特定の顧客口座及び各セクション内に適用可能なアイテムが存在するかに依存して、任意的に利用可能である。例えば、上部セクション３３０には、以下に限定されるものではないが、顧客によりシステムに入力された特定アイテムが含まれるかもしれない。このようなアイテムは、事件の説明、該当日付及び値を含むことが可能である。上部セクション３３０はさらに、選択された記帳のすべてを含む。これらの記帳は、以下に限定されるものではないが、確認された口座１５１又は１５３の明細書及びそれらの訂正のバランス、支払（入金又は出金）、及び現金要求／規則を含むことが可能である。すべての記帳の合計が、貸方（再保険会社の利益）又は借方（顧客の利益）の何れかである「差引額」に示される。詳細な表示が、記帳のテキスト上でのポイント指定及びクリックによりハイパーリンクを介し提供されてもよい。

中間セクション３４０は、未達又は承認プロセスの支払を含む。これらの記帳と差引額との和が、バランスプレビューを構成する。

下部セクション３５０は、近い将来に期限となる又は支払可能とみなされる事件を含む。このような「将来期限」記帳は記録である（現金要求契約エントリなど）
最後に、フッタセクション３６０は、顧客が財務取引をトリガーすることを可能にするボタン選択肢群を含む。このような機能キーは、顧客が人手による干渉なしに自動的に処理されるシステムからの特定の機能を要求することを可能にする。このような機能は、以下に限定されるものではないが、以下に詳細に説明される支払通知３６２、支払要求３６４又はペアリング通知３６３を含む。例えば、顧客が自分の当座勘定と表示された登録内容とのオンラインの照合を行い、各登録にコメントを記録し、以降のアクションに対する警告をスケジューリングなどの他の任意的機能もまた可能である。

本発明によるシステム及びプロセスは、典型的に時間のかかる非効率な人手による処理を必要とする会計処理プロセスを自動化する。さらに、それらはまた、他の取引領域の効率性も向上させる。このような他の領域は、以下に限定するものではないが、顧客と企業（再保険者など）との間のデータ交換、検証及び真偽性のチェック、取引状態に関する確認及び状態変更を含む。他の領域もまた、本発明から恩恵を受けるかもしれない。

顧客の当座勘定へのアクセスは、以下に限定されるものではないが、顧客によるシステム内のすべての記帳のオンライン（任意の時点に任意の場所で）による閲覧及びフィルタリングを可能にすることを含む各種機能を提供する。顧客はまた、貸借のバランス位置に応じて、財務取引をやりとりし、トリガーすることができる。アクセスは、顧客の記帳の完全な透過性を許可し、顧客が企業のスタッフを伴うことなく、自らの口座を照合することを可能にする。他の機能もまた、当業者には明らかである。

図４は、閲覧及び取引プロセスに関する一例となるマップ４００を示す。マップ４００は、閲覧及び取引処理の単なる一例であり、本発明は、この具体例に限定されるものではない。同様に機能し、同様の機能を有する他の具体例及び処理は、本発明の範囲内に属する。マップ４００は、図示される一例となるシステムの機能の一部を説明する複数の垂直方向の列と、システムを介する各種段階におけるデータを説明する複数の水平方向の行を含む。

顧客は、システムインタフェース４０１にログインすることにより、企業のサーバを介し情報とやりとりする。システムインタフェースは、インターネット上の企業により維持されるウェブページを介したものであってもよい。企業は、例えば、ユーザネーム及びパスワードを用いて顧客がシステムにログインすることを要求することによって、セキュアなアクセスを提供する。

顧客は、システムにオンラインにアクセスしながら、任意の時点において記帳を閲覧することができる。このような閲覧は、一般には利用可能なすべての記帳及びバラ員スを閲覧することによるものであってもよく、より詳細には、ハイパーリンクにより各記帳を詳細に閲覧することによるものであってもよい。図５及び６は、それぞれ画面表示５００及び６００を示す。図５は、指定された期間に対するすべての記帳及びバランスを示す当座勘定の一例となる画面表示５００である。この期間は、表示を介し拡張する必要はなく、顧客は利用可能な任意の期間に対する自らの口座の状況を閲覧することができる。図６は、指定された日付及び残りのすべてのバランスのオープニングバランスを示すよう画面がフィルタリングされた当座勘定の一例となる画面表示６００である。

顧客が図４に示される当座勘定４０２の閲覧の際に支払通知選択肢を選択すると（例えば、画面表示３００から支払通知３６２を選択するなど）、システムは、顧客が企業に１又は以前のイベントによりペアリング可能な次回の支払を通知する支払通知列４２０を移行する。顧客は、以前のイベントと次回の支払を相殺する必要はない。支払通知選択肢のデータエントリ部分４５０において、支払通知部分４２１が開始される。この段階において、システムは、図７の一例となる画面表示７００に示されるようなすべてオープンな（例えば、未決済の）当座勘定記帳のリストを提示する。その後、顧客は、支払を行うことにより顧客が決済することを所望するオープンアイテムを選択する。一例となる画面表示７００では、顧客は、合計バランス１１，５００ドルについて５００ドルの貸方と１１，０００ドルの貸方のオープンアイテムを選択している。

システムは、選択されたすべての登録の合計がシステムに容認され、通知された決済日が継続前に所定の制限の範囲内にあることを検証する。例えば、図８の画面表示８００に示されるように、顧客は５００ドルの借方の合計バランスに対して、５００ドルの貸方と１，０００ドルの借方の２つのオープンアイテムを選択したが、それはシステムに容認されない。このような状況が発生すると、システムは、支払要求の提出又は選択の変更を示唆する。しかしながら、金額がシステムに容認される場合、顧客は想定される決済日を入力することを求める。例えば、画面表示９００に示されるように、顧客は２００１年８月２７日の想定決済日を入力している。理想的な状況では（すなわち、当該合計が企業に容認される）、その合計は貸方であり、システムはデータ提出画面部分４６０において計算支払通知プロセス４２３に移行する。

システムが計算支払通知プロセス４２３に移行すると、システムは、例えば、支払通貨及び顧客の国などに応じて、好ましい企業銀行口座を提示する。さらに、支払発注において顧客が引用することが求められる一意的な参照番号が生成される。図１０は、想定される決済日、銀行口座番号及び一意的な参照番号を表示する画面表示１０００である。この参照番号は、実際の支払を認識し、技術的記帳により自動的にそれをペアリングするのに以降において用いられる。その後、顧客は、提出支払通知ボタンをクリックすることにより支払通知情報を提出する。比較的少額しかない場合（例えば、所定の金額以下）、顧客は、支払なしに相殺するかもしれない。

図１１は、支払なしの相殺の選択肢を示す画面表示１１００である。この一例となるシナリオでは、１．００ドルの合計支払がある。コストを最小限にするため、企業は支払なしの相殺の申し出をするかもしれない（すなわち、支払の先送り）。企業は、この金額を２０．００ドルなどの特定の金額に設定してもよい。顧客は常に支払を行うことを選択することも可能である。従って、画面表示１１００は、想定決済日、銀行口座番号及び一意的な参照番号に関する同じ情報を提供する。

合計金額がゼロに等しい場合、企業は選択された貸方と借方のアイテムをマッチングするよう申し出るようにしてもよい。図１２は、合計支払がゼロとなる画面表示１２００を示す。この状況では、提出支払通知ボタンは、必要な物理的支払又は銀行設定がないため利用可能ではない。従って、一例となる画面表示では、顧客は、承認のサインとして支払なしの相殺を選択するよう指示されるかもしれない。

計算支払通知プロセス４２３からの提出が適切なものである場合、システムは確認画面部分４７０において支払通知確認プロセス４２５に移行する。ここで、顧客は、支払通知又はペアリング要求の記帳成功を確認するメッセージを受信する。図１３に示される一例となる画面表示１３００は、支払通知の記帳成功を確認する具体例であり、図１４に示される一例となる画面表示１４００は、支払なしの相殺を確認する具体例である。支払通知確認プロセス４２５が完了し、顧客がそれを承認すると、システムは、当座勘定４０２に戻る。当座勘定４０２に戻った後、顧客は、ちょうど実現された支払通知の効果を自動的に確認するようにしてもよい。

しかしながら、計算支払通知プロセス４２３を完了しようとする間、技術的問題によるエラーが発生する場合、システムはエラー取引確認プロセス４８０に移行する。図１５に示される一例となる画面表示１５００は、当該取引がエラーとなり、顧客が以降に再度試行するよう要求するよう顧客に通知する。この問題が生じ続ける場合、顧客は企業に照会するよう勧められる。顧客がこの画面を承認した後、システムは、顧客が他の何れかのタスクを実行する当座勘定４０２に戻る。

顧客が当座勘定４０２において要求支払選択肢を選択すると（例えば、画面表示３００から要求支払３６４を選択する）、システムは、顧客が前のイベントに対して企業から支払を要求する要求支払列４３０に移行する。要求支払選択肢のデータ入力部分４５０において、支払通知プロセス４３１が開始される。企業は、図１６の一例となる画面表示１６００に示されるように、顧客にすべてのオープンな（未決済などの）当座勘定のリストを提示する。顧客は、企業からの支払を要求することにより、オープンアイテムの何れが決済されるべきか選択する。画面表示１６００において、顧客は１０，５００ドルの合計バランスに対して、５００ドルの借方、１１，０００ドルの借方及び１０００．００ドルの貸方のオープンアイテムを選択している。

その後、システムは、選択されたすべての登録の合計が継続前に顧客に許容されることを検証する。例えば、図１７の画面表示１７００に示されるように、顧客は、１，０００ドルの貸方のみを選択肢、借方の金額については選択していない。図１８の画面表示１８００に示される他の例では、５００ドルの貸方の合計バランスに対して、１，０００ドルの貸方と５００ドルの借方は顧客には容認されない。このような状況が起こると、システムは、支払通知の提出又は選択の変更を示唆する。画面表示１９００に示されるさらなる他の例では、他のエラーが発生している。理想的なシナリオでは（すなわち、合計が顧客に認容される）、合計が借方であり、システムは、提出画面部分４６０において計算支払要求プロセス４３３に移行する。

システムが計算支払要求プロセス４３３に継続すると、企業はそれにより知られているような支払通貨により顧客の銀行口座の一部又はすべてを列挙する。その後、顧客は支払が送金されるべき銀行口座を選択する。さらに、顧客は、顧客により指定された宛先に当該金額が転送されると、顧客が容易に認識できるような参照テキストを入力することができる。図２０は、顧客の銀行口座のリスト、顧客が参照テキストを入力する場所及び複数のボタンを表示する一例となる画面表示２０００である。この画面から、顧客は、支払要求を提出し、又は支払なしに相殺することを選択することができる。企業が顧客に支払義務を負うものが比較的少額しかない場合（例えば、所定の金額未満など）、顧客は、支払なしの相殺に同意するよう求められるようにしてもよい（すなわち、支払の先送り）。その後、システムは、すべてのデータ入力が正確に入力されたことを確認し、次のプロセスに移行する、
計算支払要求プロセス４３３からの提出が適切である場合、システムは、確認画面部分４７０において支払要求確認プロセス４３５に移行する。ここで、顧客は、支払要求又はペアリング要求の登録が成功したことを確認するメッセージを受信する。図２１に示される一例となる画面表示２１００は、支払要求の登録の成功を確認する例であり、図２２に示される一例となる画面表示２２００は、支払なしの相殺を確認する例である。支払要求確認プロセス４３５が完了し、顧客がそれを承認すると、システムは当座勘定４０２に戻る。当座勘定４０２に戻った後、顧客はちょうど実現された支払要求の効果を自動確認するようにしてもよい。その後、支払要求は、実際の支払が承認されるまで、１以上の権限のある第三者（例えば、企業の会計士など）によりさらに審査されてもよい。このような支払は、ローカルオペレーショナルデータストアへの支払発注などを開始、そこから電子ネットワークを介し顧客の銀行に処理されるようにしてもよい。

しかしながら、計算支払要求プロセス４３３の完了の試行中に、技術的問題によるエラーが発生した場合、システムはエラー取引確認プロセス４８０に移行し、図１５に示されるような画面表示１５００が表示される。

顧客が図４に示される当座勘定４０２を閲覧しながら、ペアリング通知選択肢を選択した場合（例えば、画面表示３００からペアリング通知を選択するなど）、システムは、顧客が特定の支払を特定の技術的登録に割り当てるペアリング通知列４４０に移行する。ペアリング通知選択肢のデータ入力部分４５０において、ペアリング通知プロセス４４１が開始される。顧客はペアリング通知−技術的登録情報を提示するよう要求される。企業が当座勘定登録をオープンするため、顧客の支払をペアリングすることができない場合（支払通知機能の未使用によるなど）、顧客は、ペアリング通知プロセスを用いて手動によりこれを行うことができる。以下に限定されるものではないが、図２３の一例となる画面表示２３００に示されるように、未ペアリング支払登録、未決済（期限又は期限経過など）技術的当座勘定登録（例えば、主として口座の明細書など）などを含むリストなどの情報の１以上のリストが提示されてもよい。他のタイプの情報もまた、リストとして提示されてもよい。その後、顧客は、オープンアイテムのうちでマッチングされるべきものを割り当てることによって、どのオープンアイテムが特定の支払と相殺されるべきか選択する。その後まず、システムは、許容される相殺額と選択されたすべての技術的登録の合計が、処理前に未ペアリングの支払登録の合計以下であることを確認する。

システムがデータ入力画面部分４５０内の計算ペアリング通知プロセス４４２に移行する場合、ペアリング通知−支払登録に関する情報が要求される。システムは、以下に限定されるものではないが、図２４の一例となる画面表示２４００に示されるように、マッチングのため顧客により選択されるような技術的当座勘定登録（前の画面など）、当座勘定に含まれるすべての未ペアリング支払などを含む複数のリストを提示する。他のリストもまた可能である。さらに、システムは、ＦＩＦＯ（Ｆｉｒｓｔ−Ｉｎ Ｆｉｒｓｔ−Ｏｕｔ）原理などを用いてオープン支払登録をペアリング又は割当てする方法を提案する。一例となる画面表示２４００では、システムは、３５０ドルの借方と３１０ドルの借方とを５００ドルの貸方とマッチングすることを提案している。その後、顧客は、どのオープンな支払のうちのどれだけが、完全又は部分的に相殺されるべきか指示するようにしてもよい。システムは、部分的な選択のみを許可するよう構成されてもよい。技術的登録と支払登録との間にわずかな（所定の金額など）誤差しかない場合、システムは、企業又は顧客により相殺誤差の控除を提案する、図２５の一例となる画面表示２５００は、企業が相殺誤差を控除することを所望するシナリオを示している。

顧客が完全支払のみを選択肢、技術的登録と支払登録との間にわずかな誤差しか存在しない場合、システムは、顧客に図２６の一例となる画面表示２６００又は図２７の一例となる画面表示２７００の何れかを提示する。より詳細には、画面表示２６００は、チェックされた完全な支払がオープンアイテムの合計よりわずかに少ないため、企業が誤差を控除したいシナリオを示している。画面表示２７００は、チェックされた完全な支払がオープンアイテムの合計よりわずかに多いため、その誤差を控除することを所望するか企業が顧客に尋ねるシナリオを示す。顧客が相殺を認めない場合、顧客は戻って、異なる選択をすることができる。

計算ペアリング通知プロセス４４２からの提出が適切である場合、システムは、提出画面部分４６０においてペアリング通知提出プロセス４４３に移行する。当該プロセスにおいて、企業は顧客に検討のため前の２つのプロセスの結果を提示する。図２８の一例となる画面表示２８００は、提案されたペアリングを概略する画面を示す。その後、顧客は、データ送信前に、情報の最終的確認を行うことができる。

データが提出されている場合、システムは、ペアリング通知を処理し、当座勘定４０２に戻り、ちょうど実行されたペアリング指示の結果に即座にアクセスする。処理エラー（技術的なものなど）が存在する場合、システムは、エラー取引確認プロセス４８０に移行し、図１５に示されるように、画面表示１５００が表示される。

支払の通知、支払の要求又は当座勘定からの支払の実行に加えて、画面から選択することにより既存の支払通知、支払要求又はペアリングの詳細を確認することができる。例えば、画面表示３００を介して顧客は、支払通知についての詳細を確認するため、「Ｙｏｕｒ Ｐａｙｍｅｎｔ Ａｄｖｉｃｅ」を選択することができる。

顧客が図４に示される当座勘定４０２の閲覧時に支払要求を閲覧することを選ぶと（例えば、既存の支払要求を選択するなど）、システムは、当座勘定取引詳細部分４９０において閲覧支払通知プロセス４９１に移行する。
顧客には、支払要求の詳細が提示される。図２９の一例となる画面表示２９００は、支払要求に関する情報を示す。本実施例では、問うが勘定に戻すためのさらなるアクションは、この画面から可能である。顧客が図４に示される当座勘定４０２の閲覧時に、支払通知を閲覧することを選択すると（既存の支払通知を選択するなど）、システムは、当座勘定取引詳細部分４９０に支払通知閲覧プロセス４９３に移行する。顧客には、支払通知を削除する選択肢と共に支払通知の詳細が提示される。一例となる画面表示３０００は、支払通知に関する情報を示す。本実施例では、顧客は、支払通知を削除する選択肢を有する。顧客が支払通知を削除することを選択する場合、システムはまず、図１の画面表示３１００に示されるように確認を要求する。

顧客が支払通知の削除を確認した場合、システムは、当座勘定取引詳細部分４９０において支払通知プロセス４９５を削除するよう移行する。システムは、支払通知を削除し、支払が削除されたという確認を提示する。図３２の一例となる画面表示３２００は、支払通知が削除されたことを顧客に通知する。

顧客が図４に示される当座勘定４０２を閲覧しながら、ペアリング情報を閲覧することを選択すると、システムは、当座勘定取引詳細部分４９０において閲覧ペアリング情報プロセス４９９に移行する。顧客には、図３５の画面表示３５００のペアリングの詳細が提示される。画面表示３５００は、ペアリングプロセスに関する詳細を表示し、顧客はペアリングされたアイテムの１つをクリックすることによって、口座の各明細から詳細を閲覧することができる。図３６の画面表示３６００は、２つの口座明細が修正された修正情報を示す。ペアリングにより部分的ペアリングが生ずる場合、当該情報は「ペアリング」部分と「非ペアリング部分」に分割される。

顧客が図４に示されるような当座勘定４０２を閲覧しながら支払を閲覧することを選択すると、システムは、当座勘定取引詳細部分４９０において閲覧支払プロセス４９７に移行する。顧客には、図３３の画面表示３３００に示されるように、再保険会社への顧客により行われる支払、又は図３４の画面表示３４００に示されるように、顧客への再保険会社による行われる支払の詳細が提示される。支払画面は、支払の入出の交換レートを表示することができる。支払が画面表示３３００に示されるように部分的にペアリングされる場合、顧客には、対応するボタンをクリックすることによりペアリングを閲覧する機会が与えられる。

上述の当座勘定システム及びプロセスは、バックオフィスにおいて利用可能である。

バックオフィスに関しては、図３７が、ＰＮＰＡ（Ｐｒｅｐａｒａｔｉｏｎ−Ｎｅｇｏｔｉａｔｉｏｎ−Ｐｅｒｆｏｒｍａｎｃｅ−Ａｃｃｅｐｔａｎｃｅ）モデルにおいて支払通知が企業により処理される一例となるプロセス３７００を示す。

顧客が企業によりサポートされているインタフェースを介し当座勘定にアクセスし、支払通知を選択すると、システムは、ＰＮＰＡモデルの「Ｐｒｅｐａｒａｔｉｏｎ」部分に移行する。システムは、金額、想定される決済日及び「Ｄ：Ｒｅｇｉｓｔｅｒ Ｐａｙｍｅｎｔ Ａｄｖｉｃｅ」において支払又は相殺すべきアイテムに関する顧客により与えられる情報を取得する、システムは、「Ｖ：Ｖａｌｉｄａｔｅ ｐａｙｍｅｎｔ ａｄｖｉｃｅ」において支払通知を検証し、それが検証された場合、システムは、「Ｃ：Ｃｏｎｆｉｒｍ Ｐａｙｍｅｎｔ／Ｓｅｔ−ｏｆｆ ａｄｖｉｃｅ」においてウェブ確認を求める。検証されなかった場合、システムは、顧客にエラーの種類を示し、訂正を待機する。顧客が相殺の支払を確認すると、システムは、「Ｐ：Ｐａｃｋａｇｅ Ｉｎｆｏｒｍａｔｉｏｎ−Ｐａｙ Ａｄｖ．」又は「Ｐ：Ｐａｃｋａｇｅ Ｉｎｆｏｒｍａｔｉｏｎ−Ｓｅｔ ｏｆｆ」に移行する。「Ｐ：Ｐａｃｋａｇｅ Ｉｎｆｏｒｍａｔｉｏｎ−Ｐａｙ Ａｄｖ．」は、通知されたアイテム、決済日、合計金額、参照番号及び企業銀行口座詳細などの情報を含む。「Ｐ：Ｐａｃｋａｇｅ Ｉｎｆｏｒｍａｔｉｏｎ−Ｓｅｔ ｏｆｆ」は、通知されたアイテムや控除額（存在する場合）などの情報を含む。

ＰＮＰＡモデルの「Ｎｅｇｏｔｉａｔｉｏｎ」部分においては、システムは、「Ｄ：Ｇｅｔ Ｐａｃｋａｇｅｄ Ｉｎｆｏｒｍａｔｉｏｎ−Ｐａｙ Ａｄｖ．」又は「Ｄ：Ｇｅｔ ｐａｃｋａｇｅｄ ｉｎｆｏｒｍａｔｉｏｎ−Ｓｅｔ ｏｆｆ」においてパッケージ情報を受け取る。当該情報は、任意的に、「Ｆ：Ｂｕｓｉｎｅｓｓ ｃｈｅｃｋ Ｐａｙｍｅｎｔ Ａｄｖｉｃｅ」又は「Ｆ：Ｂｕｓｉｎｅｓｓ ｃｈｅｃｋ Ｓｅｔ ｏｆｆ」における複数のチェックを通過するようにしてもよい。支払通知のチェックは、最小のデポジットのための遅れた支払を含むものであってもよい。相殺のチェックは、顧客が破産していないことを判断することを含むものであってもよい。これらのチェックは単なる一例であり、チェックが与えられない場合、システムは、ＰＮＰＡモデルの「Ｐｅｒｆｏｒｍａｎｃｅ」部分に当該情報をわたす。

「Ｐｅｒｆｏｒｍａｎｃｅ」において、システムは、「Ａ：Ｍａｋｅ ｂｏｏｋｉｎｇ（Ｐａｙｍｅｎｔ）」又は「Ａ：Ｍａｋｅ ｂｏｏｋｉｎｇ（Ｓｅｔ ｏｆｆ）」にわたす。「Ａ：Ｍａｋｅ ｂｏｏｋｉｎｇ（Ｐａｙｍｅｎｔ）」は、システムに当座勘定への予備的エントリを表示させ、選択されたオープンアイテムの状態を「ｐａｙｍｅｎｔ ｉｎ ｔｒａｎｓｉｔ」に変更する。「Ａ：Ｍａｋｅ ｂｏｏｋｉｎｇ（Ｓｅｔ−ｏｆｆ）」は、システムにＤＩＦＦ登録及び合致する支払を表示させる。

支払通知が支払を生じさせると、システムは、処理された支払通知を示す。支払通知が相殺を生じさせる場合、システムは、「Ａ：Ｅｘｐｏｒｔ Ｐａｉｒｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ ｔｏ ＬＯＤＳ」に移行する、そこから、システムは処理された相殺通知を示す。

バックオフィスに関して、図３８は、支払要求がＰＮＰＡモデルにおいて企業により処理される一例となるプロセス３８００を示す。

顧客が企業によりサポートされるインタフェースを介し当座勘定にアクセスし、支払要求を選択すると、システムは、ＰＮＰＡモデルの「Ｐｒｅｐａｒａｔｉｏｎ」部分に移行する。システムは、クライアントの登録をクライアントから取得し、それらが期限超過、金額、通貨、口座参照の明細、クライアントの銀行口座一意的な識別子であって、「Ｄ：Ｒｅｑｕｅｓｔ Ｐａｙｍｅｎｔ」においてクライアントにより入力される場合、企業の登録を含むものであってもよい。システムは、「Ｖ：Ｖａｌｉｄａｔｅ Ｐａｙｍｅｎｔ Ｒｅｑｕｅｓｔ」において支払要求を確認し、それが確認された場合、システムは「Ｐ：Ｐａｃｋａｇｅ ｉｎｆｏｒｍａｔｉｏｎ−Ｐａｙ Ｒｅｑ」又は「Ｐ：Ｐａｃｋａｇｅ Ｉｎｆｏｒｍａｔｉｏｎ−Ｓｅｔ ｏｆｆ」に移行する。「Ｐ：Ｐａｃｋａｇｅ ｉｎｆｏｒｍａｔｉｏｎ−Ｐａｙ Ｒｅｑ」は、通知されたアイテム、合計金額、参照番号、顧客銀行口座詳細などの情報を含む。「Ｐ：Ｐａｃｋａｇｅ Ｉｎｆｏｒｍａｔｉｏｎ−Ｓｅｔ ｏｆｆ」は、通知されたアイテムや控除額（存在する場合）などの情報を含む。

ＰＮＰＡモデルの「Ｎｅｇｏｔｉａｔｉｏｎ」部分において、システムは、「Ｄ：Ｇｅｔ ｐａｃｋａｇｅｄ ｉｎｆｏｒｍａｔｉｏｎ−Ｐａｙ Ｒｅｑ．」又は「Ｄ：Ｇｅｔ ｐａｃｋａｇｅｄ ｉｎｆｏｒｍａｔｉｏｎ−Ｓｅｔ ｏｆｆ」においてパッケージ情報を受信する。当該情報は、任意的には、「Ｆ：Ｂｕｓｉｎｅｓｓ ｃｈｅｃｋ Ｐａｙｍｅｎｔ ｒｅｑｕｅｓｔ」又は「Ｆ：Ｂｕｓｉｎｅｓｓ ｃｈｅｃｋｓ−Ｓｅｔ ｏｆｆ」において複数のチェックを介し通過するようにしてもよい。支払通知のチェックは、最小のデポジットの遅れた支払いを含むものであってもよい。相殺のチェックは、顧客が破産しないことを判断することを含むものであってもよい。これらのチェックは、単なる一例であり、チェックが与えられない場合、システムは、ＰＮＰＡモデルの「Ｐｅｒｆｏｒｍａｎｃｅ」部分に当該情報をわたす。

「Ｐｅｒｆｏｒｍａｎｃｅ」において、システムは、「Ａ：Ｍａｋｅ ｐｒｅｌｉｍｉｎａｒｙ ｂｏｏｋｉｎｇ（ｐａｙ ｒｅｑ）」又は「Ａ：Ｍａｋｅ ｐｒｅｌｉｍｉｎａｒｙ ｂｏｏｋｉｎｇ（ｓｅｔ ｏｆｆ）」に移行する。「Ａ：Ｍａｋｅ ｐｒｅｌｉｍｉｎａｒｙ ｂｏｏｋｉｎｇ（ｐａｙ ｒｅｑ）」は、システムに当座勘定への予備的入力を表示させ、選択されたオープンアイテムの状態を「ｐａｙｍｅｎｔ ｉｎ ｔｒａｎｓｉｔ」に変更させる。それはまた、例えば、３日間などの将来の支払期日を決定する。「Ａ：Ｍａｋｅ ｐｒｅｌｉｍｉｎａｒｙ ｂｏｏｋｉｎｇ（ｓｅｔ ｏｆｆ）」は、システムに予備的登録を行わせる。

予備的登録を行った後、システムは、「Ｃ：Ｃｏｎｆｉｒｍ Ｓｅｔ ｏｆｆ ｒｅｑｕｅｓｔ」又は「Ｃ：Ｃｏｎｆｉｒｍ Ｐａｙｍｅｎｔ ｒｅｑｕｅｓｔ ｉｎ ｔｈｅ “Ａｃｃｅｐｔａｎｃｅ”ｐｏｒｔｉｏｎ ｏｆ ｔｈｅ ＰＮＰＡ ｍｏｄｅｌ」において顧客からの確認を求める。顧客が確認すると、システムは、「Ｐａｙｍｅｎｔ Ｓｅｔ Ｏｆｆ ｐｒｏｃｅｓｓｅｄ」又は「Ｐａｙｍｅｎｔ Ｒｅｑｕｅｓｔ Ｐｒｏｃｅｓｓｅｄ」を示す。

バックオフィスに関して、図３９は、ＰＮＰＡモデルにおいて企業によりペアリング通知が処理される一例となるプロセス３９００を示す。

顧客が企業によりサポートされるインタフェースを介し当座勘定にアクセスし、支払要求を選択すると、システムは、ＰＮＰＡモデルの「Ｐｒｅｐａｒａｔｉｏｎ」部分に移行する。システムは、「Ｄ：Ｓｅｌｅｃｔ ｏｐｅｎ／ｏｖｅｒｄｕｅ ｉｔｅｍｓ ｆｏｒ ｐａｉｒｉｎｇ」において、ペアリングのための選択されたオープン又は期限切れアイテムに関する顧客により提供される情報を取得する。システムは、「Ｖ：Ｖａｌｉｄａｔｅ Ｐａｉｒｉｎｇ」においてペアリングを確認する。確認されない場合、システムは、「Ｄ：Ｓｅｌｅｃｔ ｏｐｅｎ／ｏｖｅｒｄｕｅ ｉｔｅｍｓ ｆｏｒ ｐａｉｒｉｎｇ」に戻る。確認された場合、システムは、「Ｄ：Ａｌｌｏｃａｔｅ ｕｎｐａｉｒｅｄ ｐａｙｍｅｎｔｓ」におけるペアリングのため選択されたオープン／期限切れアイテムに非ペアリング支払を完全又は部分的に顧客に割り当てるよう要求する。システムは、「Ｖ：Ｖａｌｉｄａｔｅ Ａｌｌｏｃａｔｉｏｎ」において当該割当てを確認する。確認されない場合、システムは、「Ｄ：Ａｌｌｏｃａｔｅ ｕｎｐａｉｒｅｄ ｐａｙｍｅｎｔｓ」に戻る。確認された場合、システムは、「Ｐ：Ｐａｃｋａｇｅ ｉｎｆｏｒｍａｔｉｏｎ−Ｐａｉｒｉｎｇ」に移行する。「Ｐ：Ｐａｃｋａｇｅ ｉｎｆｏｒｍａｔｉｏｎ−Ｐａｉｒｉｎｇ」は、選択された支払及び選択されたオープン／期限切れアイテムなどの情報を含む。ＰＮＰＡモデルの「Ｎｅｇｏｔｉａｔｉｏｎ」部分において、システムは、「Ｄ：Ｇｅｔ ｐａｃｋａｇｅｄ ｉｎｆｏｒｍａｔｉｏｎ−Ｐａｉｒｉｎｇ」においてパッケージ情報を受信する。当該情報は、任意的には、「Ｆ：Ｂｕｓｉｎｅｓｓ ｃｈｅｃｋ Ｐａｉｒｉｎｇ Ａｄｖｉｃｅ」において複数のチェックを通過するようにしてもよい。これらのチェックは、単なる一例であり、チェックが与えられない場合、システムは、ＰＮＰＡモデルの「Ｐｅｒｆｏｒｍａｎｃｅ」部分に情報をわたす。

「Ｐｅｒｆｏｒｍａｎｃｅ」において、システムは、「Ａ：Ｍａｋｅ ｂｏｏｋｉｎｇ ｉｎｔｏ ｃｕｒｒｅｎｔ ａｃｃｏｕｎｔ」に移行する。「Ａ：Ｍａｋｅ ｂｏｏｋｉｎｇ（Ｐａｙｍｅｎｔ）」は、システムに支払がペアリングされ、オープン／期限切れアイテムが決済されることを当座勘定において表示させる。

登録を当座勘定に行った後、システムは、ＰＮＰＡモデルにおいて「Ａｃｃｅｐｔａｎｃｅ」部分の「Ｃ：Ｃｏｎｆｉｒｍ ｐａｉｒｉｎｇ ａｄｖｉｃｅ」において顧客から確認を求める。顧客が確認すると、システムは、「Ｐａｉｒｉｎｇ ａｄｖｉｃｅ ｐｒｏｃｅｓｓｅｄ」を示す。

図３７〜３９のそれぞれは、各ステップにおいて行われる処理の性質を示すキーを提供する。他の処理手段が本発明の範囲から逸脱することなく利用可能であるということは理解されるであろう。

本発明による上述の一例となるシステム及び方法は、多数の効果を有する。そのような１つの効果は、顧客と企業との間のやりとりが自動化されるということである。この自動化は、対人による通信などの非自動化プロセスに関するコスト及びエラーを低減させる。さらに、すべての取引は電子的に記録され、これにより、ライブの主体間の通信ミスの可能性を低減させることができる。本システムの他の効果は、顧客のバランスが一日単位で変動しうるということである。ある日には、顧客は企業に借りをつくり、次の日には、支払の権利を得る。本システムは、顧客が一日の価値を確認し、それを利用して口座を調整することができるため、クライアントに対する完全な透過性を提供する。上述のシステムを通じて、顧客は自分の口座の完全なコントロールを有するため、支払をすること、又は支払を要求することが最善であるときを選択することができる。これは企業にとって効果的である。なぜなら、企業は顧客の入力に依存し、人手による入力の必要性を解消し、顧客からの支払がされたとき、又は顧客への支払が必要なときの処理量を最小限にすることができるためである。

本発明によるシステム及び方法の他のユニークな効果は、迅速な拡張が可能であるということである。本発明には再保険会社で最も普通に遭遇する処理の具体例が与えられたが、本発明はこのタイプの企業に限定されるものではない。企業とそれの顧客との間の取引を自動化することから恩恵を受けうる任意の企業が、本発明を利用することから恩恵を受ける。図面の実施例に示されるパラメータ、選択肢及びパスは、他の何れかの企業の一意的な企業選択肢及び具体的要求を説明するようプログラムされる。

本発明の各実施例を説明するのに、本明細書は、特定のステップシーケンスとして本発明の方法及び／又はプロセスを提供した。しかしながら、本方法又はプロセスがここで与えられる各ステップの特定順序に依存しない程度で、本方法又はプロセスは上述のステップシーケンスに限定されるべきではない。従って、明細書において与えられる各ステップの特定の順序は、請求項に対する限定として解釈されるべきではない。さらに、本発明の方法及び／又はプロセスに関する請求項は、記載された順序における各ステップの実行に限定されるものではなく、本発明の趣旨及び範囲内に属する限り上記ステップは変更されてもよいし、あるいは維持されてもよいということは当業者には容易に理解されるであろう。

本発明の実施例の上記開示は、例示及び説明のために与えられたものである。それは、本発明を開示された形態のみに限定することを意図したものではない。ここで説明された実施例の多数の変形及び改良は、上記開示に基づき当業者に明らかであろう。本発明の範囲は、添付された請求項及びその均等物によってのみ規定されるべきである。

図１は、再保険企業内の請求の受付及びファンドの分配を行う本発明の実施例の一例となるプロセスの概略を示す。 図２は、本発明の一例となるシステムを示す概略図である。 図３は、本発明の実施例によるモデル当座勘定サマリを示す画面表示である。 図４は、顧客が再保険会社とやりとりする際に、自動化された支払及び口座情報を受信するのを可能にするイベントシーケンスを示す本発明の実施例を示すブロック図である。 図５は、上述の図１〜４に記載された一例となるプロセス及びシステムに利用可能な一例となる画面表示である。 図６は、上述の図１〜４に記載された一例となるプロセス及びシステムに利用可能な一例となる画面表示である。 図７は、上述の図１〜４に記載された一例となるプロセス及びシステムに利用可能な一例となる画面表示である。 図８は、上述の図１〜４に記載された一例となるプロセス及びシステムに利用可能な一例となる画面表示である。 図９は、上述の図１〜４に記載された一例となるプロセス及びシステムに利用可能な一例となる画面表示である。 図１０は、上述の図１〜４に記載された一例となるプロセス及びシステムに利用可能な一例となる画面表示である。 図１１は、上述の図１〜４に記載された一例となるプロセス及びシステムに利用可能な一例となる画面表示である。 図１２は、上述の図１〜４に記載された一例となるプロセス及びシステムに利用可能な一例となる画面表示である。 図１３は、上述の図１〜４に記載された一例となるプロセス及びシステムに利用可能な一例となる画面表示である。 図１４は、上述の図１〜４に記載された一例となるプロセス及びシステムに利用可能な一例となる画面表示である。 図１５は、上述の図１〜４に記載された一例となるプロセス及びシステムに利用可能な一例となる画面表示である。 図１６は、上述の図１〜４に記載された一例となるプロセス及びシステムに利用可能な一例となる画面表示である。 図１７は、上述の図１〜４に記載された一例となるプロセス及びシステムに利用可能な一例となる画面表示である。 図１８は、上述の図１〜４に記載された一例となるプロセス及びシステムに利用可能な一例となる画面表示である。 図１９は、上述の図１〜４に記載された一例となるプロセス及びシステムに利用可能な一例となる画面表示である。 図２０は、上述の図１〜４に記載された一例となるプロセス及びシステムに利用可能な一例となる画面表示である。 図２１は、上述の図１〜４に記載された一例となるプロセス及びシステムに利用可能な一例となる画面表示である。 図２２は、上述の図１〜４に記載された一例となるプロセス及びシステムに利用可能な一例となる画面表示である。 図２３は、上述の図１〜４に記載された一例となるプロセス及びシステムに利用可能な一例となる画面表示である。 図２４は、上述の図１〜４に記載された一例となるプロセス及びシステムに利用可能な一例となる画面表示である。 図２５は、上述の図１〜４に記載された一例となるプロセス及びシステムに利用可能な一例となる画面表示である。 図２６は、上述の図１〜４に記載された一例となるプロセス及びシステムに利用可能な一例となる画面表示である。 図２７は、上述の図１〜４に記載された一例となるプロセス及びシステムに利用可能な一例となる画面表示である。 図２８は、上述の図１〜４に記載された一例となるプロセス及びシステムに利用可能な一例となる画面表示である。 図２９は、上述の図１〜４に記載された一例となるプロセス及びシステムに利用可能な一例となる画面表示である。 図３０は、上述の図１〜４に記載された一例となるプロセス及びシステムに利用可能な一例となる画面表示である。 図３１は、上述の図１〜４に記載された一例となるプロセス及びシステムに利用可能な一例となる画面表示である。 図３２は、上述の図１〜４に記載された一例となるプロセス及びシステムに利用可能な一例となる画面表示である。 図３３は、上述の図１〜４に記載された一例となるプロセス及びシステムに利用可能な一例となる画面表示である。 図３４は、上述の図１〜４に記載された一例となるプロセス及びシステムに利用可能な一例となる画面表示である。 図３５は、上述の図１〜４に記載された一例となるプロセス及びシステムに利用可能な一例となる画面表示である。 図３６は、上述の図１〜４に記載された一例となるプロセス及びシステムに利用可能な一例となる画面表示である。 図３７は、顧客が支払通知を企業に行う一例となるプロセスを示す。 図３８は、顧客がペアリング通知を企業に行う一例となるプロセスを示す。 図３９は、顧客が支払要求を企業に行う一例となるプロセスを示す。

Claims (2)

1. 顧客と企業との間の事業を処理するためのコンピュータベースシステムであって、
   前記企業により利用され、通信ネットワークを介し顧客端末によりアクセス可能なサーバと、
   前記サーバに収容され、前記顧客に関する口座記帳を含む顧客口座と、
   前記顧客端末が前記通信ネットワークを介し前記顧客に関する口座記帳のリストから、未処理のアイテムを選択することを可能にする機能であって、当該システムにより自動処理される機能を前記通信ネットワークを介し前記顧客が選択する手段と、
   前記口座記帳のそれぞれに関する借方状態又は貸方状態を考慮して、前記口座記帳のリストから選択された未処理のアイテムの差分を計算する手段と、
   前記差分を所定の金額と比較し、前記差分が前記所定の金額以下であるとき、支払をすることなく前記口座記帳のリストから選択された前記未処理のアイテムを相殺する手段と、
   を有し、
   借方は前記顧客側のものであり、貸方は前記企業側のものであり、
   前記顧客からの支払を表す口座記帳は未決済の貸方の口座記帳に割り当てられ、前記企業からの支払を表す口座記帳は未決済の借方の口座記帳に割り当てられ、
   前記計算する手段は、前記通信ネットワークを介した前記顧客からの選択に応答して、選択されたアイテムの未決済の貸方の口座記帳の合計と、選択されたアイテムの未決済の借方の口座記帳の合計との差分を計算し、前記相殺する手段は、該差分が所定の金額以下であるとき、前記差分を控除する、ことを特徴とするシステム。
2. 請求項１記載のシステムであって、さらに、
   前記差分がゼロであるとき、支払通知情報を提出するための提出支払通知ボタンを前記顧客に利用不可とする手段を有することを特徴とするシステム。

Images