"顧客と企業との間の取引を処理するシステムであって、再保険者である前記企業により利用され、保険加入者である前記顧客によりアクセス可能なサーバと、前記サーバに格納され、前記サーバ上の顧客口座に関する前記再保険者の内部記録へのアクセスを有する顧客口座と、を有し、前記サーバは、前記サーバにより実行されると、前記再保険者から前記保険加入者への1以上の支払金を相殺するため、前記顧客がコンピュータグラフィカルユーザインタフェースを使用することを可能にする自動化された命令を有し、前記自動化された命令は、前記顧客による閲覧及び利用のために前記コンピュータグラフィカルユーザインタフェース上に、前記再保険者から前記保険加入者への支払を示す借方と前記保険加入者から前記再保険者への支払を示す貸方とのリストを提示するよう構成され、前記借方と前記貸方とは、前記保険加入者と前記再保険者との間の複数の保険ポリシーに関連付けされ、前記サーバのプロセッサは、前記借方と前記貸方とのリストを利用して、前記保険ポリシーのため、前記保険加入者から前記再保険者への支払金を前記再保険者から前記保険加入者への支払金により相殺するシステム。前記再保険者から前記保険加入者への支払金は、保険請求に対するものである、請求項1記載のシステム。前記サーバと通信するコンピュータをさらに有し、前記顧客は、前記コンピュータを介し前記サーバにアクセスする、請求項1記載のシステム。前記コンピュータから前記サーバへのアクセスは、インターネットの利用を含む、請求項3記載のシステム。前記コンピュータから前記サーバへのアクセスは、遠隔的である、請求項3記載のシステム。前記顧客は、前記リスト上の借方と貸方とを選択することによって今度の支払を通知し、前記自動化された命令は、選択されたすべての借方と貸方との合計が前記企業に対するネットの支払を実行させることを確認するよう構成される、請求項1記載のシステム。前記顧客は、前記リスト上の借方と貸方とを選択することによって支払を要求し、前記自動化された命令は、選択されたすべての借方と貸方との合計が前記顧客に対するネットの支払を実行させることを確認するよう構成される、請求項1記載のシステム。顧客と企業との間の取引を処理するシステムであって、再保険者である前記企業により利用され、保険加入者である前記顧客によりアクセス可能なサーバと、前記サーバに格納され、前記サーバにより実行可能な少なくとも1つの関連する処理を有する顧客口座に関する個々の記録へのアクセスを許可するよう構成される顧客口座と、を有し、前記サーバは、前記顧客による閲覧及び利用のためにコンピュータグラフィカルユーザインタフェース上に、前記再保険者から前記保険加入者への支払を示す借方と前記保険加入者から前記再保険者への支払を示す貸方とのリストを提示するよう構成される自動化された命令を有し、前記借方と前記貸方とは、前記保険加入者と前記再保険者との間の複数の保険ポリシーに関連付けされ、前記サーバのプロセッサは、前記借方と前記貸方とのリストを利用して、前記保険加入者から前記再保険者への支払金を前記再保険者から前記保険加入者への支払金により相殺するシステム。前記再保険者から前記保険加入者への支払金は、保険請求のためのものである、請求項8記載のシステム。前記サーバと通信するコンピュータをさらに有し、前記顧客は、前記コンピュータを介し前記サーバにアクセスする、請求項8記載のシステム。前記コンピュータから前記サーバへのアクセスは、インターネットの利用を含む、請求項10記載のシステム。前記コンピュータから前記サーバへのアクセスは、遠隔的である、請求項10記載のシステム。顧客と企業との間の取引を処理する方法であって、再保険者である前記企業により利用されるサーバを介し、前記企業の内部記録を含む、保険加入者である前記顧客の既存の顧客口座にアクセスするステップと、前記サーバを介し、前記再保険者から前記保険加入者への支払を示す借方と前記保険加入者から前記再保険者への支払を示す貸方とのリストを表示するコンピュータグラフィカルユーザインタフェースにアクセスするステップと、前記借方と前記貸方とは複数の保険ポリシーに関連付けされ、前記サーバに通信接続されたコンピュータを介し、前記借方と前記貸方とのリストを利用して、前記保険加入者から前記再保険者への支払金を前記再保険者から前記保険加入者への支払金により相殺するよう指示するステップと、を有する方法。前記再保険者から前記保険加入者への支払金は、保険請求のためのものである、請求項13記載の方法。前記顧客口座にアクセスするステップは、インターネットの利用を伴う、請求項13記載の方法。前記顧客口座は、遠隔的にアクセスされる、請求項13記載の方法。本発明の課題は、従来技術の問題点を有しない顧客と企業との間の事業を処理するコンピュータベースシステム及びコンピュータプログラムプロダクトを提供することである。特に、本発明の課題は、データ及び金融取引を実行及び請求するための技術インフラに関する要求を抑えながら、システムが顧客との取引を処理する効率を向上させる顧客と企業との間の事業を処理するコンピュータベースシステム及びコンピュータプログラムプロダクトを提供することである。本発明によると、上記課題は、特に独立クレームの特徴を通じて実現される。さらに、さらなる効果的な実施例が、従属クレーム及び記載から導かれる。顧客と企業との間の事業を処理するコンピュータベースシステムは、企業により用いられるサーバを有する。当該サーバは、例えば、端末を利用することにより、通信ネットワークを介し顧客によりアクセス可能である。顧客に関する口座記帳を含む顧客口座が、サーバに収容される。本発明によると、上記課題は、システムが顧客が通信ネットワークを介し顧客に関する口座記帳のリストからオープンアイテムを選択することを可能にするものであって、当該システムにより自動処理される機能を通信ネットワークを介し顧客が選択する手段を有することにより特に実現される。さらに、本発明のシステムは、口座記帳のそれぞれに関する顧客に支払われる借方又は前記企業に支払われる貸方の状態を考慮して、口座記帳リストから選択されたアイテムに対するバランスを計算する手段を有する。本発明のシステムはまた、バランスを所定の金額と比較し、バランスが所定の金額以下であるとき、支払をすることなく口座記帳リストから選択されたアイテムを相殺する手段を有する。一方では、顧客が顧客の口座にリモートアクセスし、口座記帳のリストからオープンアイテムを選択する、すなわち、顧客の口座記帳を選択的にグループ化し、システムにより自動処理される機能を選択する、すなわち、指定された口座記帳グループに適用される財務処理を選択することを可能にするため、顧客との取引を処理するシステム内の効率性及びフレキシビリティを向上する。顧客口座の構成と顧客口座記帳の割当てが顧客により制御される。顧客は、登録について完全な透過性を有し、企業のスタッフに関与することなく顧客口座を調整することが可能となる。他方、貸方/借方のバランスポジションに応じて、顧客が財務処理をやりとりし、トリガーすることが可能となるため、データ及び財務処理を実行及び請求する技術インフラに対する要求が低減される。例えば、選択された支払通知機能又は支払要求機能が少額に関するものであるとき、支払取引を回避することができる。特に、顧客への支払及び当該支払に関するすべてのデータ通信は、支払要求に関する貸方及び借方が小さなバランスとなるよう選択されるときには実行される必要がない。同様に、顧客からの支払発注及び当該支払発注に関するすべてのデータ通信は、支払要求に関する貸方及び借方が小さなバランスとなるよう選択されるときには実行される必要がない。従って、財務処理の実行回数は低減され、請求を解消又は少なくとも大きく減少させることができる。この結果、データ及び財務処理を実行し、請求するための技術インフラに対する要求を低減することができる。なぜなら、通信ネットワークの帯域幅と財務処理を実行するのに要するプロセッサ及びメモリリソースが低減され、保険料を請求するのに必要な郵便物の量を減らすことができるためである。好ましくは、本システムはさらに、選択された機能として支払通知を継続する前に、バランスが当該システムに許容されるか確認する手段を有する。さらに好ましくは、本システムは、選択された機能として支払通知を継続する前に、バランスが顧客に許容されるか確認する手段を有する。各口座記帳グループのバランスに応じて、口座記帳の財務処理及び決済の実行を禁止することは、不要な取引及びデータ通信が回避されるという効果を有する。従って、データ及び財務処理を実行する技術インフラに対する要求をさらに低減することができる。好適な実施例では、本システムはさらに、バランスがゼロであるとき、提出支払通知ボタンを顧客に利用不可とする手段を有する。ユーザからボタンを視覚的に隠すことによって、支払通知処理を実行すべきか否かに対する制御が、顧客から削除される。このことは、システムが、バランスがゼロであるときに支払通知を実行することなく、選択された各口座記帳グループを相殺することを可能にする。従って、システムを利用する企業がそれの貸方の少額の残余バランス控除することを所望する場合、財務処理及び当該財務処理に関するデータ通信を回避することが可能となる。好適な実施例では、本システムはさらに、選択された機能として支払通知に関する一意的な参照番号を生成し、通信ネットワークを介し顧客に通信する手段を有する。さらに、本システムは、通信ネットワークを介し電子支払発注を受付け、該電子支払発注に含まれる一意的な参照番号に基づき、口座記帳リストから選択されたアイテムと電子支払発注をペアリングする手段を有する。請求書及び関連する請求書番号を発行する必要なく、システムが顧客から受け付けた支払発注と口座記帳をマッチングすることを可能にする。この結果、口座記帳と支払発注をマッチングする効果を維持しながら、請求書を生成し、顧客に送信する処理パワー及びエネルギーを節約することができる。好適な実施例では、本システムはさらに、顧客からの支払を表す口座記帳を未決済の口座記帳に通信ネットワークを介し顧客が割り当てる手段を有する。さらに、本システムは、支払を表す口座記帳と割り当てられた未決済の口座記帳との差を計算し、該差が所定の金額以下であるとき、差を控除する手段を有する。顧客からの支払は、未決済の口座記帳と顧客により直接マッチングすることができる。システムが顧客に請求書を作成及び送信する必要はなく、また、顧客に通信され、以降において顧客によりシステムに通知されねばならない参照番号も必要でない。さらに、システムが貸方の少額の残余バランスを控除することを所望する場合、残余バランスの請求を回避することができる。顧客と企業との間の事業を処理するコンピュータベースシステムに加えて、本発明はまた、コンピュータの1以上のプロセッサを制御するコンピュータプログラムコード手段を有するコンピュータプログラムプロダクト、特に当該コンピュータプログラムコード手段を有するコンピュータ可読媒体を有するコンピュータプログラムプロダクトに関する。当該コンピュータプログラムコード手段は、コンピュータが顧客と企業との間の事業を処理する上述のコンピュータベースシステムのすべての機能を実行するように、コンピュータのプロセッサを制御するよう構成される。好ましくは、コンピュータプログラムコード手段は、コンピュータが顧客と企業との間の事業を処理する上述のコンピュータベースシステムのすべての機能を実行するサーバを実現するように、コンピュータのプロセッサを制御するよう構成される。具体的には、コンピュータプログラムプロダクトにより制御されると、コンピュータは、顧客に関する口座記帳リストから通信ネットワークを介しオープンアイテムを顧客が選択することを可能にするものであって、コンピュータにより自動処理される機能を選択する命令を、顧客から通信ネットワークを介し受け付ける。コンピュータは、口座記帳のそれぞれに関する顧客に支払われる借方又は企業に支払われる貸方の状態を考慮して、口座記帳リストから選択されたアイテムに対するバランスを計算する。コンピュータは、バランスを所定の金額と比較し、バランスが所定の金額以下であるとき、支払をすることなく口座記帳グループを相殺する。好ましくは、コンピュータプログラムプロダクトにより制御されると、コンピュータは、選択された機能として支払通知を継続する前に、バランスがシステムに許容されるか確認し、選択された機能として支払通知を継続する前に、バランスが顧客に許容されるか確認する。好適な実施例では、コンピュータプログラムプロダクトにより制御されると、コンピュータは、バランスがゼロであるとき、提出支払通知ボタンを顧客に利用不可とする。好適な実施例では、コンピュータプログラムプロダクトにより制御されると、コンピュータは、選択された機能として支払通知に関する一意的な参照番号を生成し、通信ネットワークを介し顧客に通信する。コンピュータは、通信ネットワークを介し電子支払発注を受付け、該電子支払発注に含まれる一意的な参照番号に基づき、口座記帳リストから選択されたアイテムと電子支払発注をペアリングする。好適な実施例では、コンピュータプログラムプロダクトにより制御されると、コンピュータは、顧客からの支払を表す口座記帳を未決済の口座記帳に割り当てる命令を顧客から通信ネットワークを介し受付ける。コンピュータは、支払を表す口座記帳と割り当てられた未決済の口座記帳との差を計算し、該差が所定の金額以下であるとき、差を控除する。ここで与えられた実施例に記載されるように、本発明は、2以上の主体間において事業に典型的に生じる効率性及び不正確さの問題点を解消する。このような主体は、個人、企業、機関又は政府を含むかもしれない。本開示を通じて提供される具体例は、再保険会社とそれの顧客である保険会社との間のやりとりに関するものである。しかしながら、これらの具体例は、簡単化のため単に与えられたものであり、本発明を限定するものではない。本発明によると、従来技術の問題点を有しない顧客と企業との間の事業を処理するコンピュータベースシステム及びコンピュータプログラムプロダクトを提供することができる。特に、本発明によると、データ及び金融取引を実行及び請求するための技術インフラに関する要求を抑えながら、システムが顧客との取引を処理する効率を向上させる顧客と企業との間の事業を処理するコンピュータベースシステム及びコンピュータプログラムプロダクトを提供することができる。本発明による一例となるシステム及び方法は、顧客と企業との間の取引を容易にするため、顧客と企業との間の汎用的インタフェースを利用するものである。ここで与えられる一例となるシステム及び方法は、従来の請求処理ルーチンに係る時間と労力を低減し、上記主体間の取引のコストを減少させ、効率を向上させる。ここで開示される実施例は、具体例として再保険会社を参照するが、本発明は当該タイプの業種に限定されるものではない。他のタイプの業種もここで開示されたシステム及び方法から恩恵を受けることができる。例えば、保険会社、政府機関、ファンド又はライセンスを配布する他の主体、又は他の同様の企業又は機関もまた、特定の構成に従った当業者に明らかな想定される変更を行うことにより、ここで開示されたシステム及び方法から恩恵を受けることができる。上述のように、例えば、再保険会社は再保険会社とその顧客保険会社との間の比較的高いレベルの信頼性により特徴付けされている。さらに、典型的には、各顧客と再保険会社との間には大量の取引がある。すなわち、一見の顧客はまれである。再保険会社の上記特徴は、取引処理を向上させる機会を創出する。再保険会社とその顧客保険会社との間の比較的高いレベルの信頼性のため、顧客が内部の会計記録にアクセスすることを許可することが実際的である。このように、顧客は記録を閲覧し、精度及び効率性を向上させるため、入力支払通知又は支払要求などを与えることができる。もちろん、このような顧客とのやりとりを容易にするユーザインタフェースが存在する必要がある。さらに、各顧客と再保険会社との間には典型的には大量の取引が存在するため、貸借を対にして、相殺することにより取引処理を向上させることができる。保険会社と再保険会社に関して、図1において、顧客請求を受付及び処理するプロセスが示される。システム100は、フロントオフィス部分111とバックオフィス部分112とを有する。ある機能を有するフロントオフィス部分111とバックオフィス部分112が示されているが、このような機能は、各オフィス部分111又は112が図1に示されるものより多い又は少ない機能を有するようにシフトされてもよい。フロントオフィス部分111は、主にプレースメント機能130に関するものである。一般に、プレースメント130は、リスクを分散するため顧客保険会社などと企業再保険会社などとの間の交渉に関するものである。交渉の最終結果は、典型的には、契約や約束又は既存の契約又は約束に対する変更である。複数の契約群131と133は、このフロントオフィス部分111の機能において取得される。各契約群131と133は、1以上の特徴を共有するものであってもよい。このような引受131及び133は、例えば、同一系列の契約、通貨、再保険のタイプ、再保険済みなどを含むものであってもよい。各契約群は、1つの契約から数千の契約を含むものであってもよい。他のタイプ又は構成の契約群もまた可能である。プレースメント130の後、本プロセスは、技術的会計処理コンポーネント140と財務会計コンポーネント150を含むバックオフィス部分112の機能系列に移行する。技術的会計処理コンポーネント140では、引受131及び133は、2つの請求ボルドbordereaux141及び143と、保険料ボルド142及び144をそれぞれ導く。一般に、ボルドとは、指定された契約群の一定の会計処理機関のすべての保険料又は請求の動きのリストである。合計は、当座勘定を含む財務会計処理コンポーネント150に示される。すべての詳細な動きが、擬似的会計処理コンポーネント140に示される。このとき、2つのボルドはそれぞれ、合意した会計処理期間ごとの口座151又は153の1つの明細書に対する基礎となる。このような期間は、例えば、月単位、四半期単位、又は他の確定可能な期間とすることができる。このとき、口座151と153の1以上の明細書により、当座勘定を含む財務会計処理機能150が導かれる。当座勘定は、顧客が支払要求161、支払通知162又はペアリングアドバイス163などの1以上の財務取引を実行することを可能にする。各取引が以下においてより詳細に説明される。他の財務取引もまた可能である。さらに、当座勘定から、すでに提出された支払要求を閲覧し、支払通知を閲覧及び/又は削除し、支払を閲覧し、ペアリング情報を閲覧することが可能である。図1に示されるシステム及び方法の機能面を参照するに、当座勘定又は財務会計処理機能150は、顧客が閲覧可能な再保険価値連鎖の最後のステップである。さらに典型的には、顧客ごとに1つの当座勘定が存在し、技術的再保険記帳口座151又は153の明細書など、現金要求関連記帳、支払記帳及びマッチング/ペアリング状態に関する情報のすべてのバランスを含む。現金要求は、保険会社が大きな請求決済の場合に再保険者から要求する前受金である。その金額は、次の通常の口座明細書において借方記入される。図2は、本発明の一例となるシステムを示す概略図である。本発明のシステム200は、サーバ240と口座処理エンジン250とを有する。サーバ240は、1つのサーバ又はサーバネットワークから構成することができる。サーバ240は、企業230に関連付けされる。例えば、サーバ240は、企業230により、又はその代わりに、所有、運営又は維持することができる。サーバ240は、口座処理エンジン250に関連付けされる。口座処理エンジン250は、ここで開示されるような本発明によるプロセス及び方法を実行するよう構成されたプロセッサに関連付けされる。例えば、アプリケーション処理エンジン250は、当座勘定により呼び出される各種プロセスを実行するようにしてもよい。サーバ240は、ネットワーク220を開始1以上の顧客210にアクセス可能である。サーバ240のファイアウォール242が、サーバ240への未認証のアクセスを防ぐよう設けられる。ファイアウォール242を使用することは周知であり、ここでは詳細には説明されない。顧客210及び企業230は、ネットワーク220を介し互いに通信可能である。ネットワーク220は、任意の既知の通信ネットワークとすることができる。好ましくは、ネットワーク220はインターネットである。再保険産業に関して、顧客210は、被保険者に保険契約を販売する保険会社である。企業230は、顧客210の保険契約に係る再保険サービスを提供するため顧客210を処理する再保険会社である。例えば、顧客210保険会社などが入力データを含む支払通知を企業230に与えると、この入力データはサーバ240に係るアプリケーションモジュールに送られる。便宜上、アプリケーションモジュールに係るプロセスは、移行において当座勘定プロセスと呼ぶ。顧客210により与えられる入力データが最低限のデータ品質要求に適合することを技術的に保証するため、当該要求がまず検証される。このデータ品質要求は、例えば、正確なシンタックスを有することが可能であり、入力データの各値は所定の内容依存性の低い範囲内であり、当該要求の各値間の基本的関係が正しい例えば、DATE1がDATE2より前である、などである。次に、サーバ240に係るモジュール/ファンクションは、当座勘定内の複数のプロセスに対する企業検証規則に集中することができる。例えば、当該プロセスは、支払通知、支払要求及びペアリング通知を含むものであってもよい。企業検証規則は、顧客の自由を所望のデータ範囲に制限することができ、当該プロセスを標準化するのに利用される。フィルタ規則又は企業チェックがまた、企業による人手の介入を必要とするか移行において決定するのに提供されてもよい。本発明のシステム及び方法は、企業が当該システム及び/又は方法を利用することによって、最小限の人手の介入により顧客に容易にアクセス可能かつユーザフレンドリなものとなるよう構成される。従って、本発明のシステム及び/又は方法へのアクセスを提供する非限定的手段は、インターネットを介するものである。顧客は、インターネットアクセスを可能にする状況において、何時でも何処でもインターネットを介し顧客口座に容易にアクセスできる。このようなアクセスは、有線手段を介し又は遠隔的に提供されてもよい。すなわち、ネットワーク220はまた、モバイル無線ネットワークやワイヤレスローカルエリアネットワークWLANなどの無線ネットワークを含むものであってもよい。このような口座アクセスに対する時間及び場所に関する制約の欠如及びフレキシビリティの増大は、顧客に大きな恩恵を提供する。同様に、顧客に提供されるこのようなフレキシビリティは、このようなフレキシビリティに魅力を感じる人々の顧客基盤の増大を当該企業に提供する。顧客は、例えば、顧客口座へのアクセスを可能にする特定のインターネットアドレスをタイプすることによって、本発明によるシステムにアクセスするようにしてもよい。典型的には、ログインページを用いて、顧客口座へのセキュアなアクセスを保証し、顧客口座の未認証又は不正使用を禁止するようにしてもよい。顧客が顧客口座に適切にログインすると、図3の一例となる画面表示300に示されるような各種選択肢ページを有するメニュー起動ホームページが提供されるようにしてもよい。特定の機能及び特徴を有する画面表示300が示されるが、図5に示される画面表示500や図6に示される画面表示600などの他の画面表示は、本発明の範囲内に属し、図3に示される画面表示に限定されるものではない。多数のメニューアイテム310を有する一例となる画面表示300が示される。各メニューアイテムは、顧客に対する機能及び選択肢の独立した画面を有する。図3に示される一例となるメニューアイテムは、当座勘定313である。他のメニュー選択肢には、以下に限定されるものではないが、制約311、プレースメント312、ユーザ管理314、アドレスブック315及び統計316が含まれる。契約311は、契約限度の詳細を閲覧し、保険料/請求ボルドにアクセスするためのものである。プレースメント312は、保険及び再保険企業が申し込み、反対申し込み、受付又は拒絶を提出する交渉の場である。ユーザ管理314では、保険会社は、それの顧客口座すなわち、ユーザパスワード、ユーザアクセス権限、企業アドレス及び企業銀行口座を管理することができる。アドレスブック315は、クライアントが他の再保険会社への申し込みの転送を所望する場合、他の競合する再保険会社の電子メールアカウントを登録するのに利用されるかもしれない。統計316により、保険会社は、営業記録及び再保険会社との取引に関するオンラインレポートを生成及び閲覧することができる。当座勘定313が一例として図3に示されるが、それは本発明を限定するものではなく、各種画面表示が利用可能である。図3に示される当座勘定313内には、顧客のアクセス及び機能を容易にするさらにいくつかの選択肢が、顧客に提供される。ヘッダセクション320は、顧客が顧客口座の一部又はすべてにアクセスするのに変更可能な容易にアクセス可能なパラメータを提供する。ヘッダセクションにおいて変更可能な選択肢の一部には、以下に限定されるものではないが、分析に対するエントリ日付、取引通貨及び各種口座登録の状態が含まれる。ヘッダセクション320はまた、グループ企業情報、登録日付、予約状態及び通貨により当座勘定をフィルタリングすることができる。複数の再保険会社がアプリケーションに関連付けされている場合、再保険会社によるフィルタリングなどの他の選択肢が可能である。当座勘定313の画面表示300の他のセクションは、特定の顧客口座及び各セクション内に適用可能なアイテムが存在するかに依存して、任意的に利用可能である。例えば、上部セクション330には、以下に限定されるものではないが、顧客によりシステムに入力された特定アイテムが含まれるかもしれない。このようなアイテムは、事件の説明、該当日付及び値を含むことが可能である。上部セクション330はさらに、選択された記帳のすべてを含む。これらの記帳は、以下に限定されるものではないが、確認された口座151又は153の明細書及びそれらの訂正のバランス、支払入金又は出金、及び現金要求/規則を含むことが可能である。すべての記帳の合計が、貸方再保険会社の利益又は借方顧客の利益の何れかである差引額に示される。詳細な表示が、記帳のテキスト上でのポイント指定及びクリックによりハイパーリンクを介し提供されてもよい。中間セクション340は、未達又は承認プロセスの支払を含む。これらの記帳と差引額との和が、バランスプレビューを構成する。下部セクション350は、近い将来に期限となる又は支払可能とみなされる事件を含む。このような将来期限記帳は記録である現金要求契約エントリなど最後に、フッタセクション360は、顧客が財務取引をトリガーすることを可能にするボタン選択肢群を含む。このような機能キーは、顧客が人手による干渉なしに自動的に処理されるシステムからの特定の機能を要求することを可能にする。このような機能は、以下に限定されるものではないが、以下に詳細に説明される支払通知362、支払要求364又はペアリング通知363を含む。例えば、顧客が自分の当座勘定と表示された登録内容とのオンラインの照合を行い、各登録にコメントを記録し、以降のアクションに対する警告をスケジューリングなどの他の任意的機能もまた可能である。本発明によるシステム及びプロセスは、典型的に時間のかかる非効率な人手による処理を必要とする会計処理プロセスを自動化する。さらに、それらはまた、他の取引領域の効率性も向上させる。このような他の領域は、以下に限定するものではないが、顧客と企業再保険者などとの間のデータ交換、検証及び真偽性のチェック、取引状態に関する確認及び状態変更を含む。他の領域もまた、本発明から恩恵を受けるかもしれない。顧客の当座勘定へのアクセスは、以下に限定されるものではないが、顧客によるシステム内のすべての記帳のオンライン任意の時点に任意の場所でによる閲覧及びフィルタリングを可能にすることを含む各種機能を提供する。顧客はまた、貸借のバランス位置に応じて、財務取引をやりとりし、トリガーすることができる。アクセスは、顧客の記帳の完全な透過性を許可し、顧客が企業のスタッフを伴うことなく、自らの口座を照合することを可能にする。他の機能もまた、当業者には明らかである。図4は、閲覧及び取引プロセスに関する一例となるマップ400を示す。マップ400は、閲覧及び取引処理の単なる一例であり、本発明は、この具体例に限定されるものではない。同様に機能し、同様の機能を有する他の具体例及び処理は、本発明の範囲内に属する。マップ400は、図示される一例となるシステムの機能の一部を説明する複数の垂直方向の列と、システムを介する各種段階におけるデータを説明する複数の水平方向の行を含む。顧客は、システムインタフェース401にログインすることにより、企業のサーバを介し情報とやりとりする。システムインタフェースは、インターネット上の企業により維持されるウェブページを介したものであってもよい。企業は、例えば、ユーザネーム及びパスワードを用いて顧客がシステムにログインすることを要求することによって、セキュアなアクセスを提供する。顧客は、システムにオンラインにアクセスしながら、任意の時点において記帳を閲覧することができる。このような閲覧は、一般には利用可能なすべての記帳及びバラ員スを閲覧することによるものであってもよく、より詳細には、ハイパーリンクにより各記帳を詳細に閲覧することによるものであってもよい。図5及び6は、それぞれ画面表示500及び600を示す。図5は、指定された期間に対するすべての記帳及びバランスを示す当座勘定の一例となる画面表示500である。この期間は、表示を介し拡張する必要はなく、顧客は利用可能な任意の期間に対する自らの口座の状況を閲覧することができる。図6は、指定された日付及び残りのすべてのバランスのオープニングバランスを示すよう画面がフィルタリングされた当座勘定の一例となる画面表示600である。顧客が図4に示される当座勘定402の閲覧の際に支払通知選択肢を選択すると例えば、画面表示300から支払通知362を選択するなど、システムは、顧客が企業に1又は以前のイベントによりペアリング可能な次回の支払を通知する支払通知列420を移行する。顧客は、以前のイベントと次回の支払を相殺する必要はない。支払通知選択肢のデータエントリ部分450において、支払通知部分421が開始される。この段階において、システムは、図7の一例となる画面表示700に示されるようなすべてオープンな例えば、未決済の当座勘定記帳のリストを提示する。その後、顧客は、支払を行うことにより顧客が決済することを所望するオープンアイテムを選択する。一例となる画面表示700では、顧客は、合計バランス11,500ドルについて500ドルの貸方と11,000ドルの貸方のオープンアイテムを選択している。システムは、選択されたすべての登録の合計がシステムに容認され、通知された決済日が継続前に所定の制限の範囲内にあることを検証する。例えば、図8の画面表示800に示されるように、顧客は500ドルの借方の合計バランスに対して、500ドルの貸方と1,000ドルの借方の2つのオープンアイテムを選択したが、それはシステムに容認されない。このような状況が発生すると、システムは、支払要求の提出又は選択の変更を示唆する。しかしながら、金額がシステムに容認される場合、顧客は想定される決済日を入力することを求める。例えば、画面表示900に示されるように、顧客は2001年8月27日の想定決済日を入力している。理想的な状況ではすなわち、当該合計が企業に容認される、その合計は貸方であり、システムはデータ提出画面部分460において計算支払通知プロセス423に移行する。システムが計算支払通知プロセス423に移行すると、システムは、例えば、支払通貨及び顧客の国などに応じて、好ましい企業銀行口座を提示する。さらに、支払発注において顧客が引用することが求められる一意的な参照番号が生成される。図10は、想定される決済日、銀行口座番号及び一意的な参照番号を表示する画面表示1000である。この参照番号は、実際の支払を認識し、技術的記帳により自動的にそれをペアリングするのに以降において用いられる。その後、顧客は、提出支払通知ボタンをクリックすることにより支払通知情報を提出する。比較的少額しかない場合例えば、所定の金額以下、顧客は、支払なしに相殺するかもしれない。図11は、支払なしの相殺の選択肢を示す画面表示1100である。この一例となるシナリオでは、1.00ドルの合計支払がある。コストを最小限にするため、企業は支払なしの相殺の申し出をするかもしれないすなわち、支払の先送り。企業は、この金額を20.00ドルなどの特定の金額に設定してもよい。顧客は常に支払を行うことを選択することも可能である。従って、画面表示1100は、想定決済日、銀行口座番号及び一意的な参照番号に関する同じ情報を提供する。合計金額がゼロに等しい場合、企業は選択された貸方と借方のアイテムをマッチングするよう申し出るようにしてもよい。図12は、合計支払がゼロとなる画面表示1200を示す。この状況では、提出支払通知ボタンは、必要な物理的支払又は銀行設定がないため利用可能ではない。従って、一例となる画面表示では、顧客は、承認のサインとして支払なしの相殺を選択するよう指示されるかもしれない。計算支払通知プロセス423からの提出が適切なものである場合、システムは確認画面部分470において支払通知確認プロセス425に移行する。ここで、顧客は、支払通知又はペアリング要求の記帳成功を確認するメッセージを受信する。図13に示される一例となる画面表示1300は、支払通知の記帳成功を確認する具体例であり、図14に示される一例となる画面表示1400は、支払なしの相殺を確認する具体例である。支払通知確認プロセス425が完了し、顧客がそれを承認すると、システムは、当座勘定402に戻る。当座勘定402に戻った後、顧客は、ちょうど実現された支払通知の効果を自動的に確認するようにしてもよい。しかしながら、計算支払通知プロセス423を完了しようとする間、技術的問題によるエラーが発生する場合、システムはエラー取引確認プロセス480に移行する。図15に示される一例となる画面表示1500は、当該取引がエラーとなり、顧客が以降に再度試行するよう要求するよう顧客に通知する。この問題が生じ続ける場合、顧客は企業に照会するよう勧められる。顧客がこの画面を承認した後、システムは、顧客が他の何れかのタスクを実行する当座勘定402に戻る。顧客が当座勘定402において要求支払選択肢を選択すると例えば、画面表示300から要求支払364を選択する、システムは、顧客が前のイベントに対して企業から支払を要求する要求支払列430に移行する。要求支払選択肢のデータ入力部分450において、支払通知プロセス431が開始される。企業は、図16の一例となる画面表示1600に示されるように、顧客にすべてのオープンな未決済などの当座勘定のリストを提示する。顧客は、企業からの支払を要求することにより、オープンアイテムの何れが決済されるべきか選択する。画面表示1600において、顧客は10,500ドルの合計バランスに対して、500ドルの借方、11,000ドルの借方及び1000.00ドルの貸方のオープンアイテムを選択している。その後、システムは、選択されたすべての登録の合計が継続前に顧客に許容されることを検証する。例えば、図17の画面表示1700に示されるように、顧客は、1,000ドルの貸方のみを選択肢、借方の金額については選択していない。図18の画面表示1800に示される他の例では、500ドルの貸方の合計バランスに対して、1,000ドルの貸方と500ドルの借方は顧客には容認されない。このような状況が起こると、システムは、支払通知の提出又は選択の変更を示唆する。画面表示1900に示されるさらなる他の例では、他のエラーが発生している。理想的なシナリオではすなわち、合計が顧客に認容される、合計が借方であり、システムは、提出画面部分460において計算支払要求プロセス433に移行する。システムが計算支払要求プロセス433に継続すると、企業はそれにより知られているような支払通貨により顧客の銀行口座の一部又はすべてを列挙する。その後、顧客は支払が送金されるべき銀行口座を選択する。さらに、顧客は、顧客により指定された宛先に当該金額が転送されると、顧客が容易に認識できるような参照テキストを入力することができる。図20は、顧客の銀行口座のリスト、顧客が参照テキストを入力する場所及び複数のボタンを表示する一例となる画面表示2000である。この画面から、顧客は、支払要求を提出し、又は支払なしに相殺することを選択することができる。企業が顧客に支払義務を負うものが比較的少額しかない場合例えば、所定の金額未満など、顧客は、支払なしの相殺に同意するよう求められるようにしてもよいすなわち、支払の先送り。その後、システムは、すべてのデータ入力が正確に入力されたことを確認し、次のプロセスに移行する、計算支払要求プロセス433からの提出が適切である場合、システムは、確認画面部分470において支払要求確認プロセス435に移行する。ここで、顧客は、支払要求又はペアリング要求の登録が成功したことを確認するメッセージを受信する。図21に示される一例となる画面表示2100は、支払要求の登録の成功を確認する例であり、図22に示される一例となる画面表示2200は、支払なしの相殺を確認する例である。支払要求確認プロセス435が完了し、顧客がそれを承認すると、システムは当座勘定402に戻る。当座勘定402に戻った後、顧客はちょうど実現された支払要求の効果を自動確認するようにしてもよい。その後、支払要求は、実際の支払が承認されるまで、1以上の権限のある第三者例えば、企業の会計士などによりさらに審査されてもよい。このような支払は、ローカルオペレーショナルデータストアへの支払発注などを開始、そこから電子ネットワークを介し顧客の銀行に処理されるようにしてもよい。しかしながら、計算支払要求プロセス433の完了の試行中に、技術的問題によるエラーが発生した場合、システムはエラー取引確認プロセス480に移行し、図15に示されるような画面表示1500が表示される。顧客が図4に示される当座勘定402を閲覧しながら、ペアリング通知選択肢を選択した場合例えば、画面表示300からペアリング通知を選択するなど、システムは、顧客が特定の支払を特定の技術的登録に割り当てるペアリング通知列440に移行する。ペアリング通知選択肢のデータ入力部分450において、ペアリング通知プロセス441が開始される。顧客はペアリング通知-技術的登録情報を提示するよう要求される。企業が当座勘定登録をオープンするため、顧客の支払をペアリングすることができない場合支払通知機能の未使用によるなど、顧客は、ペアリング通知プロセスを用いて手動によりこれを行うことができる。以下に限定されるものではないが、図23の一例となる画面表示2300に示されるように、未ペアリング支払登録、未決済期限又は期限経過など技術的当座勘定登録例えば、主として口座の明細書などなどを含むリストなどの情報の1以上のリストが提示されてもよい。他のタイプの情報もまた、リストとして提示されてもよい。その後、顧客は、オープンアイテムのうちでマッチングされるべきものを割り当てることによって、どのオープンアイテムが特定の支払と相殺されるべきか選択する。その後まず、システムは、許容される相殺額と選択されたすべての技術的登録の合計が、処理前に未ペアリングの支払登録の合計以下であることを確認する。システムがデータ入力画面部分450内の計算ペアリング通知プロセス442に移行する場合、ペアリング通知-支払登録に関する情報が要求される。システムは、以下に限定されるものではないが、図24の一例となる画面表示2400に示されるように、マッチングのため顧客により選択されるような技術的当座勘定登録前の画面など、当座勘定に含まれるすべての未ペアリング支払などを含む複数のリストを提示する。他のリストもまた可能である。さらに、システムは、FIFOFirst-InFirst-Out原理などを用いてオープン支払登録をペアリング又は割当てする方法を提案する。一例となる画面表示2400では、システムは、350ドルの借方と310ドルの借方とを500ドルの貸方とマッチングすることを提案している。その後、顧客は、どのオープンな支払のうちのどれだけが、完全又は部分的に相殺されるべきか指示するようにしてもよい。システムは、部分的な選択のみを許可するよう構成されてもよい。技術的登録と支払登録との間にわずかな所定の金額など誤差しかない場合、システムは、企業又は顧客により相殺誤差の控除を提案する、図25の一例となる画面表示2500は、企業が相殺誤差を控除することを所望するシナリオを示している。顧客が完全支払のみを選択肢、技術的登録と支払登録との間にわずかな誤差しか存在しない場合、システムは、顧客に図26の一例となる画面表示2600又は図27の一例となる画面表示2700の何れかを提示する。より詳細には、画面表示2600は、チェックされた完全な支払がオープンアイテムの合計よりわずかに少ないため、企業が誤差を控除したいシナリオを示している。画面表示2700は、チェックされた完全な支払がオープンアイテムの合計よりわずかに多いため、その誤差を控除することを所望するか企業が顧客に尋ねるシナリオを示す。顧客が相殺を認めない場合、顧客は戻って、異なる選択をすることができる。計算ペアリング通知プロセス442からの提出が適切である場合、システムは、提出画面部分460においてペアリング通知提出プロセス443に移行する。当該プロセスにおいて、企業は顧客に検討のため前の2つのプロセスの結果を提示する。図28の一例となる画面表示2800は、提案されたペアリングを概略する画面を示す。その後、顧客は、データ送信前に、情報の最終的確認を行うことができる。データが提出されている場合、システムは、ペアリング通知を処理し、当座勘定402に戻り、ちょうど実行されたペアリング指示の結果に即座にアクセスする。処理エラー技術的なものなどが存在する場合、システムは、エラー取引確認プロセス480に移行し、図15に示されるように、画面表示1500が表示される。支払の通知、支払の要求又は当座勘定からの支払の実行に加えて、画面から選択することにより既存の支払通知、支払要求又はペアリングの詳細を確認することができる。例えば、画面表示300を介して顧客は、支払通知についての詳細を確認するため、YourPaymentAdviceを選択することができる。顧客が図4に示される当座勘定402の閲覧時に支払要求を閲覧することを選ぶと例えば、既存の支払要求を選択するなど、システムは、当座勘定取引詳細部分490において閲覧支払通知プロセス491に移行する。顧客には、支払要求の詳細が提示される。図29の一例となる画面表示2900は、支払要求に関する情報を示す。本実施例では、問うが勘定に戻すためのさらなるアクションは、この画面から可能である。顧客が図4に示される当座勘定402の閲覧時に、支払通知を閲覧することを選択すると既存の支払通知を選択するなど、システムは、当座勘定取引詳細部分490に支払通知閲覧プロセス493に移行する。顧客には、支払通知を削除する選択肢と共に支払通知の詳細が提示される。一例となる画面表示3000は、支払通知に関する情報を示す。本実施例では、顧客は、支払通知を削除する選択肢を有する。顧客が支払通知を削除することを選択する場合、システムはまず、図1の画面表示3100に示されるように確認を要求する。顧客が支払通知の削除を確認した場合、システムは、当座勘定取引詳細部分490において支払通知プロセス495を削除するよう移行する。システムは、支払通知を削除し、支払が削除されたという確認を提示する。図32の一例となる画面表示3200は、支払通知が削除されたことを顧客に通知する。顧客が図4に示される当座勘定402を閲覧しながら、ペアリング情報を閲覧することを選択すると、システムは、当座勘定取引詳細部分490において閲覧ペアリング情報プロセス499に移行する。顧客には、図35の画面表示3500のペアリングの詳細が提示される。画面表示3500は、ペアリングプロセスに関する詳細を表示し、顧客はペアリングされたアイテムの1つをクリックすることによって、口座の各明細から詳細を閲覧することができる。図36の画面表示3600は、2つの口座明細が修正された修正情報を示す。ペアリングにより部分的ペアリングが生ずる場合、当該情報はペアリング部分と非ペアリング部分に分割される。顧客が図4に示されるような当座勘定402を閲覧しながら支払を閲覧することを選択すると、システムは、当座勘定取引詳細部分490において閲覧支払プロセス497に移行する。顧客には、図33の画面表示3300に示されるように、再保険会社への顧客により行われる支払、又は図34の画面表示3400に示されるように、顧客への再保険会社による行われる支払の詳細が提示される。支払画面は、支払の入出の交換レートを表示することができる。支払が画面表示3300に示されるように部分的にペアリングされる場合、顧客には、対応するボタンをクリックすることによりペアリングを閲覧する機会が与えられる。上述の当座勘定システム及びプロセスは、バックオフィスにおいて利用可能である。バックオフィスに関しては、図37が、PNPAPreparation-Negotiation-Performance-Acceptanceモデルにおいて支払通知が企業により処理される一例となるプロセス3700を示す。顧客が企業によりサポートされているインタフェースを介し当座勘定にアクセスし、支払通知を選択すると、システムは、PNPAモデルのPreparation部分に移行する。システムは、金額、想定される決済日及びD:RegisterPaymentAdviceにおいて支払又は相殺すべきアイテムに関する顧客により与えられる情報を取得する、システムは、V:Validatepaymentadviceにおいて支払通知を検証し、それが検証された場合、システムは、C:ConfirmPayment/Set-offadviceにおいてウェブ確認を求める。検証されなかった場合、システムは、顧客にエラーの種類を示し、訂正を待機する。顧客が相殺の支払を確認すると、システムは、P:PackageInformation-PayAdv.又はP:PackageInformation-Setoffに移行する。P:PackageInformation-PayAdv.は、通知されたアイテム、決済日、合計金額、参照番号及び企業銀行口座詳細などの情報を含む。P:PackageInformation-Setoffは、通知されたアイテムや控除額存在する場合などの情報を含む。PNPAモデルのNegotiation部分においては、システムは、D:GetPackagedInformation-PayAdv.又はD:Getpackagedinformation-Setoffにおいてパッケージ情報を受け取る。当該情報は、任意的に、F:BusinesscheckPaymentAdvice又はF:BusinesscheckSetoffにおける複数のチェックを通過するようにしてもよい。支払通知のチェックは、最小のデポジットのための遅れた支払を含むものであってもよい。相殺のチェックは、顧客が破産していないことを判断することを含むものであってもよい。これらのチェックは単なる一例であり、チェックが与えられない場合、システムは、PNPAモデルのPerformance部分に当該情報をわたす。Performanceにおいて、システムは、A:MakebookingPayment又はA:MakebookingSetoffにわたす。A:MakebookingPaymentは、システムに当座勘定への予備的エントリを表示させ、選択されたオープンアイテムの状態をpaymentintransitに変更する。A:MakebookingSet-offは、システムにDIFF登録及び合致する支払を表示させる。支払通知が支払を生じさせると、システムは、処理された支払通知を示す。支払通知が相殺を生じさせる場合、システムは、A:ExportPairingInformationtoLODSに移行する、そこから、システムは処理された相殺通知を示す。バックオフィスに関して、図38は、支払要求がPNPAモデルにおいて企業により処理される一例となるプロセス3800を示す。顧客が企業によりサポートされるインタフェースを介し当座勘定にアクセスし、支払要求を選択すると、システムは、PNPAモデルのPreparation部分に移行する。システムは、クライアントの登録をクライアントから取得し、それらが期限超過、金額、通貨、口座参照の明細、クライアントの銀行口座一意的な識別子であって、D:RequestPaymentにおいてクライアントにより入力される場合、企業の登録を含むものであってもよい。システムは、V:ValidatePaymentRequestにおいて支払要求を確認し、それが確認された場合、システムはP:Packageinformation-PayReq又はP:PackageInformation-Setoffに移行する。P:Packageinformation-PayReqは、通知されたアイテム、合計金額、参照番号、顧客銀行口座詳細などの情報を含む。P:PackageInformation-Setoffは、通知されたアイテムや控除額存在する場合などの情報を含む。PNPAモデルのNegotiation部分において、システムは、D:Getpackagedinformation-PayReq.又はD:Getpackagedinformation-Setoffにおいてパッケージ情報を受信する。当該情報は、任意的には、F:BusinesscheckPaymentrequest又はF:Businesschecks-Setoffにおいて複数のチェックを介し通過するようにしてもよい。支払通知のチェックは、最小のデポジットの遅れた支払いを含むものであってもよい。相殺のチェックは、顧客が破産しないことを判断することを含むものであってもよい。これらのチェックは、単なる一例であり、チェックが与えられない場合、システムは、PNPAモデルのPerformance部分に当該情報をわたす。Performanceにおいて、システムは、A:Makepreliminarybookingpayreq又はA:Makepreliminarybookingsetoffに移行する。A:Makepreliminarybookingpayreqは、システムに当座勘定への予備的入力を表示させ、選択されたオープンアイテムの状態をpaymentintransitに変更させる。それはまた、例えば、3日間などの将来の支払期日を決定する。A:Makepreliminarybookingsetoffは、システムに予備的登録を行わせる。予備的登録を行った後、システムは、C:ConfirmSetoffrequest又はC:ConfirmPaymentrequestintheAcceptanceportionofthePNPAmodelにおいて顧客からの確認を求める。顧客が確認すると、システムは、PaymentSetOffprocessed又はPaymentRequestProcessedを示す。バックオフィスに関して、図39は、PNPAモデルにおいて企業によりペアリング通知が処理される一例となるプロセス3900を示す。顧客が企業によりサポートされるインタフェースを介し当座勘定にアクセスし、支払要求を選択すると、システムは、PNPAモデルのPreparation部分に移行する。システムは、D:Selectopen/overdueitemsforpairingにおいて、ペアリングのための選択されたオープン又は期限切れアイテムに関する顧客により提供される情報を取得する。システムは、V:ValidatePairingにおいてペアリングを確認する。確認されない場合、システムは、D:Selectopen/overdueitemsforpairingに戻る。確認された場合、システムは、D:Allocateunpairedpaymentsにおけるペアリングのため選択されたオープン/期限切れアイテムに非ペアリング支払を完全又は部分的に顧客に割り当てるよう要求する。システムは、V:ValidateAllocationにおいて当該割当てを確認する。確認されない場合、システムは、D:Allocateunpairedpaymentsに戻る。確認された場合、システムは、P:Packageinformation-Pairingに移行する。P:Packageinformation-Pairingは、選択された支払及び選択されたオープン/期限切れアイテムなどの情報を含む。PNPAモデルのNegotiation部分において、システムは、D:Getpackagedinformation-Pairingにおいてパッケージ情報を受信する。当該情報は、任意的には、F:BusinesscheckPairingAdviceにおいて複数のチェックを通過するようにしてもよい。これらのチェックは、単なる一例であり、チェックが与えられない場合、システムは、PNPAモデルのPerformance部分に情報をわたす。Performanceにおいて、システムは、A:Makebookingintocurrentaccountに移行する。A:MakebookingPaymentは、システムに支払がペアリングされ、オープン/期限切れアイテムが決済されることを当座勘定において表示させる。登録を当座勘定に行った後、システムは、PNPAモデルにおいてAcceptance部分のC:Confirmpairingadviceにおいて顧客から確認を求める。顧客が確認すると、システムは、Pairingadviceprocessedを示す。図37~39のそれぞれは、各ステップにおいて行われる処理の性質を示すキーを提供する。他の処理手段が本発明の範囲から逸脱することなく利用可能であるということは理解されるであろう。本発明による上述の一例となるシステム及び方法は、多数の効果を有する。そのような1つの効果は、顧客と企業との間のやりとりが自動化されるということである。この自動化は、対人による通信などの非自動化プロセスに関するコスト及びエラーを低減させる。さらに、すべての取引は電子的に記録され、これにより、ライブの主体間の通信ミスの可能性を低減させることができる。本システムの他の効果は、顧客のバランスが一日単位で変動しうるということである。ある日には、顧客は企業に借りをつくり、次の日には、支払の権利を得る。本システムは、顧客が一日の価値を確認し、それを利用して口座を調整することができるため、クライアントに対する完全な透過性を提供する。上述のシステムを通じて、顧客は自分の口座の完全なコントロールを有するため、支払をすること、又は支払を要求することが最善であるときを選択することができる。これは企業にとって効果的である。なぜなら、企業は顧客の入力に依存し、人手による入力の必要性を解消し、顧客からの支払がされたとき、又は顧客への支払が必要なときの処理量を最小限にすることができるためである。本発明によるシステム及び方法の他のユニークな効果は、迅速な拡張が可能であるということである。本発明には再保険会社で最も普通に遭遇する処理の具体例が与えられたが、本発明はこのタイプの企業に限定されるものではない。企業とそれの顧客との間の取引を自動化することから恩恵を受けうる任意の企業が、本発明を利用することから恩恵を受ける。図面の実施例に示されるパラメータ、選択肢及びパスは、他の何れかの企業の一意的な企業選択肢及び具体的要求を説明するようプログラムされる。本発明の各実施例を説明するのに、本明細書は、特定のステップシーケンスとして本発明の方法及び/又はプロセスを提供した。しかしながら、本方法又はプロセスがここで与えられる各ステップの特定順序に依存しない程度で、本方法又はプロセスは上述のステップシーケンスに限定されるべきではない。従って、明細書において与えられる各ステップの特定の順序は、請求項に対する限定として解釈されるべきではない。さらに、本発明の方法及び/又はプロセスに関する請求項は、記載された順序における各ステップの実行に限定されるものではなく、本発明の趣旨及び範囲内に属する限り上記ステップは変更されてもよいし、あるいは維持されてもよいということは当業者には容易に理解されるであろう。本発明の実施例の上記開示は、例示及び説明のために与えられたものである。それは、本発明を開示された形態のみに限定することを意図したものではない。ここで説明された実施例の多数の変形及び改良は、上記開示に基づき当業者に明らかであろう。本発明の範囲は、添付された請求項及びその均等物によってのみ規定されるべきである。"