(57)【要約】本発明は、請求書を電子的に処理するための方法に関する。ここでは、請求書をカスタマに対し、請求者からの請求情報およびマスタデータとカスタマからのマスタデータとを使用して作成する。本発明では、  ａ）請求情報を請求者から、第１の処理モジュールによって受信するステップと、  ｂ）請求書を第１の処理モジュールによって、請求者の請求情報およびマスタデータを使用して生成するステップと、  ｃ）カスタマのデータを第２の処理モジュールから、第１の処理モジュールによって要求するステップと、  ｄ）生成された請求書のフォーマットがカスタマのマスタデータで指定されたフォーマットでない場合、該請求書を第１の処理モジュールによって、カスタマのマスタデータで指定されたフォーマットに変換するステップと、  ｅ）生成または変換された請求書を第２の処理モジュールへ、第１の処理モジュールによって伝送するステップとが含まれる。ここでは、第１の処理モジュールは請求者のマスタデータにアクセス可能であり、第２の処理モジュールはカスタマのマスタデータにアクセス可能である。【特許請求の範囲】
【請求項１】
請求書を電子的に処理する方法であって、
請求書をカスタマに対し、請求者からの請求情報およびマスタデータとカスタマからのマスタデータとを使用することによって作成する形式の方法において、
ａ）請求情報を請求者から、第１の処理モジュールを使用して受信するステップと、
ｂ）請求書を該第１の処理モジュールによって、請求者の請求情報およびマスタデータを使用することによって生成するステップと、
ｃ）カスタマのデータを第２の処理モジュールから、該第１の処理モジュールによって要求するステップと、
ｄ）生成された前記請求書のフォーマットが、カスタマのマスタデータで指定されたフォーマットでない場合、該請求書を該第１の処理モジュールによって、カスタマのマスタデータで指定されたフォーマットに変換するステップと、
ｅ）生成または変換された前記請求書を、該第１の処理モジュールによって該第２の処理モジュールへ伝送するステップとを有し、
該第１の処理モジュールは請求者のマスタデータにアクセス可能であり、該第２の処理モジュールはカスタマのマスタデータにアクセス可能であることを特徴とする方法。
【請求項２】
ｆ）変換された請求書を該第２の処理モジュールによって、第３の処理モジュールにアクセス可能であるように形成するステップを有する、請求項１記載の方法。
【請求項３】
ｇ）変換された請求書を、カスタマに対してアクセス可能であるように形成するステップを有する、請求項１または２記載の方法。
【請求項４】
ｈ）変換された請求書をカスタマに対して提示または送付するステップを有する、請求項１から３までのいずれか１項記載の方法。
【請求項５】
請求書を該第１の処理モジュールによってデジタル署名する、請求項１から４までのいずれか１項記載の方法。
【請求項６】
カスタマのアクセスのため、変換された請求書に、該変換された請求書または該請求書の詳細の記憶位置に対するリンクを設ける、請求項１から５までのいずれか１項記載の方法。
【請求項７】
請求書または変換された請求書を、印刷サービスへ送信する、請求項１から６までのいずれか１項記載の方法。
【請求項８】
請求書および／または変換された請求書を、該第１の処理モジュールおよび／または第２の処理モジュールによって暗号化する、請求項１から７までのいずれか１項記載の方法。
【請求項９】
請求書および／または変換された請求書を、該第１の処理モジュールおよび／または第２の処理モジュールによってアーカイブする、請求項１から８までのいずれか１項記載の方法。
【請求項１０】
該第３の処理モジュールは、カスタマ請求書の概略を提示するための手段を提供する、請求項１から９までのいずれか１項記載の方法。
【請求項１１】
該第３の処理モジュールは、請求書を検証するための手段を提供する、請求項１から１０までのいずれか１項記載の方法。
【請求項１２】
該第３の処理モジュールは、ワークフロー支援または請求書の異議申し立てのための手段を有する、請求項１から１１までのいずれか１項記載の方法。
【請求項１３】
該第２の処理モジュールは、国固有の請求書提示および／または支払いのための手段を提供する、請求項１から１２までのいずれか１項記載の方法。
【請求項１４】
該第２の処理モジュールは、１つまたは複数の別の第２の処理モジュールとデータを交換するための手段を提供する、請求項１から１３までのいずれか１項記載の方法。
【請求項１５】
該第２の処理モジュールは、支払いオーダをカスタマから受信する、請求項１から１４までのいずれか１項記載の方法。
【請求項１６】
該第２の処理モジュールは、支払いオーダまたは変換された支払いオーダを、支払いサービス提供者へ転送する、請求項１から１５までのいずれか１項記載の方法。
【請求項１７】
請求情報は、請求者および／またはカスタマおよび／または支払いサービス提供者のアドレス情報、支払い情報、ＶＡＴ情報、購入オーダに関連する項目化された請求位置、および／または会計情報を含む、請求項１から１６までのいずれか１項記載の方法。
【請求項１８】
請求者のマスタデータは、アドレス情報、および／またはデータフォーマット情報、および／または通信アドレスに関する情報、および／または銀行情報および／または銀行口座情報、および／またはユーザ認証情報、および／またはユーザ許可情報、および／またはアーカイブサービスのための任意選択に関する情報、および／または印刷サービスのための任意選択に関する情報、および／または通知のための任意選択に関する情報を含む、請求項１から１７までのいずれか１項記載の方法。
【請求項１９】
カスタマのマスタデータは、アドレス情報、および／またはデータフォーマット情報、および／または通信アドレス、および／または銀行情報および銀行口座情報、および／またはユーザ認証情報、および／またはユーザ許可、および／またはアーカイブサービスのための任意選択および／または通知のための任意選択に関する情報を含む、請求項１から１８までのいずれか１項記載の方法。
【請求項２０】
該第２の処理モジュールは、１つまたは複数の別の第１の処理モジュールとデータを交換するための手段を有する、請求項１から１９までのいずれか１項記載の方法。
【請求項２１】
該第２の処理モジュールは、１つまたは複数の別の第３の処理モジュールとデータを交換するための手段を有する、請求項１から２０までのいずれか１項記載の方法。
【請求項２２】
該第２の処理モジュールまたは第１の処理モジュールは、特定のカスタマに対する請求者のＩＤを、特定の請求者に対するカスタマのＩＤにマッピングするための手段を有する、請求項１から２１までのいずれか１項記載の方法。
【請求項２３】
請求書を、請求者によって使用されるフォーマットから、カスタマのマスタデータで指定されたのと同じフォーマットに、中間フォーマットを使用せずに直接変換する、請求項１から２２までのいずれか１項記載の方法。
【請求項２４】
エンタープライズリソースプランニングソフトウェアにおいて使用するための、請求項１から２３までのいずれか１項記載の方法。
【請求項２５】
請求書を電子的に処理するためのコンピュータシステムであって、
カスタマに対して請求書が、請求者からの請求情報およびマスタデータとカスタマからのマスタデータとを使用して作成される形式のものにおいて、
・プログラム命令を有するメモリと、
・データを受信および入力するための入力手段と、
・データを送信および提示するための出力手段と、
・データを記憶するための記憶手段と、
・前記プログラム命令に対して応答するプロセッサとが設けられており、
該プログラム命令は、
ａ）請求情報を請求者から、第１の処理モジュールによって受信するための命令と、
ｂ）請求書を該第１の処理モジュールによって、請求者の請求情報およびマスタデータを使用して生成するための命令と、
ｃ）カスタマのデータを第２の処理モジュールから、該第１の処理モジュールによって要求するための命令と、
ｄ）生成された前記請求書のフォーマットが、カスタマのマスタデータで指定されたフォーマットでない場合、該請求書を、カスタマのマスタデータで指定されたフォーマットに、該第１の処理モジュールによって変換するための命令と、
ｅ）生成または変換された請求書を該第２の処理モジュールへ、該第１の処理モジュールによって伝送するための命令であり、
該第１の処理モジュールは請求者のマスタデータにアクセス可能であり、該第２の処理モジュールはカスタマのマスタデータにアクセス可能であることを特徴とするコンピュータシステム。
【請求項２６】
ｆ）該第２の処理モジュールによって、第３の処理モジュールに対してアクセス可能であるように、変換された請求書が形成される、請求項２５記載のコンピュータシステム。
【請求項２７】
ｇ）カスタマに対してアクセス可能であるように、変換された請求書が形成される、請求項２５または２６記載のコンピュータシステム。
【請求項２８】
ｈ）変換された請求書は、カスタマに対して提示または送付される、請求項２５から２７までのいずれか１項記載のコンピュータシステム。
【請求項２９】
請求書は該第１の処理モジュールによってデジタル署名される、請求項２５から２８までのいずれか１項記載のコンピュータシステム。
【請求項３０】
カスタマのアクセスのため、変換された請求書に、該変換された請求書の記憶位置に対するリンクを設けるか、または該請求書の詳細の記憶位置に対するリンクを設ける、請求項２５から２８までのいずれか１項記載のコンピュータシステム。
【請求項３１】
請求書または変換された請求書は、印刷サービスへ送信される、請求項２５から３０までのいずれか１項記載のコンピュータシステム。
【請求項３２】
請求書および／または変換された請求書は、該第１の処理モジュールおよび／または第２の処理モジュールによって暗号化される、請求項２５から３１までのいずれか１項記載のコンピュータシステム。
【請求項３３】
請求書および／または変換された請求書は、該第１の処理モジュールおよび／または第２の処理モジュールによってアーカイブされる、請求項２５から３２までのいずれか１項記載のコンピュータシステム。
【請求項３４】
該第３の処理モジュールは、カスタマの請求書の概略を提示するための手段を提供する、請求項２５から３３までのいずれか１項記載のコンピュータシステム。
【請求項３５】
該第３の処理モジュールは、請求書を検証するための手段を提供する、請求項２５から３４までのいずれか１項記載のコンピュータシステム。
【請求項３６】
該第３の処理モジュールは、ワークフロー支援または請求書の異議申し立てのための手段を提供する、請求項２５から３５までのいずれか１項記載のコンピュータシステム。
【請求項３７】
該第２の処理モジュールは、国固有の請求書提示および／または支払いのための手段を提供する、請求項２５から３６までのいずれか１項記載のコンピュータシステム。
【請求項３８】
該第２の処理モジュールは、１つまたは複数の別の第２の処理モジュールとデータを交換するための手段を提供する、請求項２５から３６までのいずれか１項記載のコンピュータシステム。
【請求項３９】
該第２の処理モジュールは、支払いオーダをカスタマから受信する、請求項２５から３８までのいずれか１項記載のコンピュータシステム。
【請求項４０】
該第２の処理モジュールは、支払いオーダまたは変換された支払いオーダを、支払いサービス提供者へ転送する、請求項２５から３９までのいずれか１項記載のコンピュータシステム。
【請求項４１】
請求情報は、請求者および／またはカスタマおよび／または支払いサービス提供者のアドレス情報、および／または支払い情報、および／またはＶＡＴ情報、および／または購入オーダに関連する項目化された請求位置、および／または会計情報を含む、請求項２５から４０までのいずれか１項記載のコンピュータシステム。
【請求項４２】
請求者のマスタデータは、アドレス情報、および／またはデータフォーマット情報、および／または通信アドレスに関する情報、および／または銀行情報および銀行口座情報、および／またはユーザ認証情報、および／またはユーザ許可情報、および／またはアーカイブサービスのための任意選択に関する情報、および／または印刷サービスのための任意選択に関する情報、および／または通知のための任意選択に関する情報を含む、請求項２５から４１までのいずれか１項記載のコンピュータシステム。
【請求項４３】
カスタマのマスタデータは、アドレス情報、および／またはデータフォーマット情報、および／または通信アドレス、および／または銀行情報および銀行口座情報、および／またはユーザ認証情報、および／またはユーザ許可、および／またはアーカイブサービスのための任意選択に関する情報、および／または通知のための任意選択に関する情報を含む、請求項２５から４２までのいずれか１項記載のコンピュータシステム。
【請求項４４】
該第２の処理モジュールは、１つまたは複数の別の第１の処理モジュールとデータを交換するための手段を有する、請求項２５から４３までのいずれか１項記載のコンピュータシステム。
【請求項４５】
該第２の処理モジュールは、１つまたは複数の別の第３の処理モジュールとデータを交換するための手段を有する、請求項２５から４４までのいずれか１項記載のコンピュータシステム。
【請求項４６】
該第２の処理モジュールまたは第１の処理モジュールは、特定のカスタマに対する請求者のＩＤを、特定の請求者に対するカスタマのＩＤにマッピングするための手段を有する、請求項２５から４５までのいずれか１項記載のコンピュータシステム。
【請求項４７】
請求書は、請求者によって使用されたフォーマットから、カスタマのマスタデータで指定されたのと同じフォーマットに、中間フォーマットを使用せずに直接変換される、請求項２５から４６までのいずれか１項記載のコンピュータシステム。
【請求項４８】
エンタープライズリソースプランニングソフトウェアで使用するための、請求項２５から４７までのいずれか１項記載のコンピュータシステム。
【請求項４９】
コンピュータ読み出し可能な媒体であって、
請求書を電子的に処理するための命令を有し、
請求書がカスタマに対して、請求者からの請求情報およびマスタデータとカスタマからのマスタデータとを使用して作成される形式のものにおいて、
前記命令は、
ａ）請求者からの請求情報を、第１の処理モジュールによって受信するための命令と、
ｂ）請求書を該第１の処理モジュールによって、請求者の請求情報およびマスタデータを使用して生成するための命令と、
ｃ）カスタマのデータを第２の処理モジュールから、該第１の処理モジュールによって要求するための命令と、
ｄ）生成された前記請求書のフォーマットが、カスタマのマスタデータで指定されたフォーマットでない場合、該請求書を該第１の処理モジュールによって、カスタマのマスタデータで指定されたフォーマットに変換するための命令と、
ｅ）生成または変換された請求書を該第２の処理モジュールへ、該第１の処理モジュールによって伝送するための命令であり、
該第１の処理モジュールは請求者のマスタデータにアクセス可能であり、該第２の処理モジュールはカスタマのマスタデータにアクセス可能であることを特徴とするコンピュータ読み出し可能な媒体。
【請求項５０】
ｆ）該第２の処理モジュールによって、第３の処理モジュールにアクセス可能であるように変換された請求書が形成される、請求項４９記載のコンピュータ読み出し可能な媒体。
【請求項５１】
ｇ）カスタマに対してアクセス可能であるように、変換された請求書が形成される、請求項４９または５０記載のコンピュータ読み出し可能な媒体。
【請求項５２】
ｈ）変換された請求書は、カスタマに対して提示または送付される、請求項４９から５１までのいずれか１項記載のコンピュータ読み出し可能な媒体。
【請求項５３】
請求書は該第１の処理モジュールによってデジタル署名される、請求項４９から５２までのいずれか１項記載のコンピュータ読み出し可能な媒体。
【請求項５４】
カスタマのアクセスのために、変換された請求書に、該変換された請求書の記憶位置に対するリンクを設けるか、または該請求書の詳細の記憶位置に対するリンクを設ける、請求項４９から５３までのいずれか１項記載のコンピュータ読み出し可能な媒体。
【請求項５５】
請求書または変換された請求書は、印刷サービスへ送信される、請求項４９から５４までのいずれか１項記載のコンピュータ読み出し可能な媒体。
【請求項５６】
請求書および／または変換された請求書は、該第１の処理モジュールおよび／または第２の処理モジュールによって暗号化される、請求項４９から５５までのいずれか１項記載のコンピュータ読み出し可能な媒体。
【請求項５７】
請求書および／または変換された請求書は、該第１の処理モジュールおよび／または第２の処理モジュールによってアーカイブされる、請求項４９から５６までのいずれか１項記載のコンピュータ読み出し可能な媒体。
【請求項５８】
該第３の処理モジュールは、カスタマの請求書の概略を提示するための手段を提供する、請求項４９から５７までのいずれか１項記載のコンピュータ読み出し可能な媒体。
【請求項５９】
該第３の処理モジュールは、請求書を検証するための手段を提供する、請求項４９から５８までのいずれか１項記載のコンピュータ読み出し可能な媒体。
【請求項６０】
該第３の処理モジュールは、ワークフロー支援または請求書の異議申し立てのための手段を提供する、請求項４９から５９までのいずれか１項記載のコンピュータ読み出し可能な媒体。
【請求項６１】
該第２の処理モジュールは、国固有の請求書提示および／または支払いのための手段を提供する、請求項４９から６０までのいずれか１項記載のコンピュータ読み出し可能な媒体。
【請求項６２】
該第２の処理モジュールは、１つまたは複数の別の第２の処理モジュールとデータを交換するための手段を提供する、請求項４９から６０までのいずれか１項記載のコンピュータ読み出し可能な媒体。
【請求項６３】
該第２の処理モジュールは、支払いオーダをカスタマから受信する、請求項４９から６２までのいずれか１項記載のコンピュータ読み出し可能な媒体。
【請求項６４】
該第２の処理モジュールは、支払いオーダまたは変換された支払いオーダを支払いサービス提供者へ転送する、請求項４９から６３までのいずれか１項記載のコンピュータ読み出し可能な媒体。
【請求項６５】
請求情報は、請求者および／またはカスタマおよび／または支払いサービス提供者のアドレス情報、および／または支払い情報、および／またはＶＡＴ情報、および／または購入オーダに関連する項目化された請求位置、および／または会計情報を含む、請求項４９から６４までのいずれか１項記載のコンピュータ読み出し可能な媒体。
【請求項６６】
請求者のマスタデータは、アドレス情報、および／またはデータフォーマット情報、および／または通信アドレスに関する情報、および／または銀行情報および銀行口座情報、および／またはユーザ認証情報、および／またはユーザ許可情報、および／またはアーカイブサービスのための任意選択に関する情報、および／または印刷サービスのための任意選択に関する情報、および／または通知のための任意選択に関する情報を含む、請求項４９から６５までのいずれか１項記載のコンピュータ読み出し可能な媒体。
【請求項６７】
カスタマのマスタデータは、アドレス情報、および／またはデータフォーマット情報、および／または通信アドレス、および／または銀行情報および銀行口座情報、および／またはユーザ認証情報、および／またはユーザ許可、および／またはアーカイブサービスのための任意選択に関する情報、および／または通知のための任意選択に関する情報を含む、請求項４９から６６までのいずれか１項記載のコンピュータ読み出し可能な媒体。
【請求項６８】
該第２の処理モジュールは、１つまたは複数の第１の処理モジュールとデータを交換するための手段を有する、請求項４９から６７までのいずれか１項記載のコンピュータ読み出し可能な媒体。
【請求項６９】
該第２の処理モジュールは、１つまたは複数の第３の処理モジュールとデータを交換するための手段を有する、請求項４９から６８までのいずれか１項記載のコンピュータ読み出し可能な媒体。
【請求項７０】
該第２の処理モジュールまたは第１の処理モジュールは、特定のカスタマに対する請求者のＩＤを、特定の請求者に対するカスタマのＩＤにマッピングするための手段を有する、請求項４９から６９までのいずれか１項記載のコンピュータ読み出し可能な媒体。
【請求項７１】
請求書は、請求者によって使用されたフォーマットから、カスタマのマスタデータで指定されたのと同じフォーマットに、中間フォーマットを使用せずに直接変換される、請求項４９から７０までのいずれか１項記載のコンピュータ読み出し可能な媒体。
【請求項７２】
エンタープライズリソースプランニングソフトウェアで使用するための、請求項４９から７１までのいずれか１項記載のコンピュータ読み出し可能な媒体。
【請求項７３】
搬送波で実現されるコンピュータデータ信号であって、
請求書を電子的に処理するためのコードを有しており、
請求書がカスタマに対して、請求者からの請求情報およびマスタデータとカスタマからのマスタデータとを使用して作成される形式のものにおいて、
該コードは、
ａ）請求情報を請求者から、第１の処理モジュールによって受信するための命令と、
ｂ）請求書を該第１の処理モジュールによって、請求者の請求情報およびマスタデータを使用することによって生成するための命令と、
ｃ）カスタマのデータを第２の処理モジュールから、該第１の処理モジュールによって要求するための命令と、
ｄ）生成された前記請求書のフォーマットが、カスタマのマスタデータで指定されたフォーマットでない場合、該請求書を該第１の処理モジュールによって、カスタマのマスタデータで指定されたフォーマットに変換するための命令と、
ｅ）生成または変換された請求書を該第２の処理モジュールへ、該第１の処理モジュールによって伝送するための命令であり、
該第１の処理モジュールは請求者のマスタデータにアクセス可能であり、該第２の処理モジュールはカスタマのマスタデータにアクセス可能であることを特徴とするコンピュータデータ信号。
【請求項７４】
コンピュータプログラムにおいて、
請求項１から２４までのいずれか１項記載の方法を実施するためのプログラム命令が、コンピュータシステム上で実行される場合、該プログラム命令を含んでいることを特徴とするコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の背景
本発明の技術分野
本発明の技術分野は、電子データ処理の分野である。より詳細には本発明は、自動的な請求システムのための方法、コンピュータプログラム、コンピュータプログラム製品およびシステムに関する。さらに詳細には、遠隔の確認および支払いのためにカスタマへ送付される電子的な明細請求書の処理、生成および呈示のための方法、コンピュータプログラム、コンピュータプログラム製品およびシステムに関する。
【０００２】
関連分野の説明
ここで使用されているような用語「提示（presentment）」は、通常はコマーシャルペーパーに関連する特別な定義を含んでいないことを理解されたい。すなわち、名宛人に対する譲渡可能な文書に基づく提示という定義を含んでいないことを理解されたい。むしろこの用語は、電子的手段を介して情報を提供すること、とりわけ、少なくとも同一のカスタマ請求データを含む「明細請求書」を提供することを指している。この少なくとも同一のカスタマ請求データは、典型的には紙の明細請求書に記載されているカスタマ請求データである。電子的な提示は、インターネットウェブサイトまたはイントラネットウェブサイトを使用することによって行うか、またはｅメールまたはＳＭＳを使用することによって行うのが有利であり、たとえば１つまたは複数の人に対してアクセス可能であるウェブサイトを形成することによって行うが、これらに限定されない。電子的提示はさらに、コンピュータ読み出し可能な記憶媒体を、たとえば標準的な郵便を介して送付することによって行うこともできる。このコンピュータ読み出し可能な記憶媒体は、ディスク、ＺＩＰディスク、磁気光学ディスク、ＣＤ‐ＲＯＭ、ＣＤＲＷ‐ＲＯＭ、ＤＶＤ‐ＲＯＭ等である。
【０００３】
エンタープライズリソースプランニングソフトウェア（ＥＲＰ）の環境における電子請求書提示支払いサービス（ＥＢＰＰ）のための方法およびシステムが、従来技術から公知である。ＵＳ６０４４３６２において、自動的な電子的明細請求書生成および支払いのためのシステムが開示されている。このシステムによって遠隔のカスタマが、明細請求書の請求者からの自動請求を確認することができる。このシステムは明細請求書提示電子装置を有しており、この明細請求書提示電子装置には制御システムおよび第１の電子通信装置が設けられている。このシステムは、カスタマインタフェースを備えている少なくとも１つの遠隔認証端末も有しており、この遠隔端末システムには第２の電子通信装置が設けられている。この第２の電子通信装置は、第１の電子通信装置と機能的に有効に通信するように適合されている。明細請求書提示電子装置の制御システムは、自動請求のために予備認証されたカスタマ明細請求書を考慮して、第２の電子通信装置へ伝送するための第１の電子通信装置へ請求データを供給するように適合されている。遠隔の認証端末のカスタマインタフェースは、請求データをカスタマに対して提示し、請求データに関連する応答をカスタマから受信するように適合されている。この応答は、自動請求のための請求データの承諾を示すか、または自動請求を変更するための請求データの変更のうち１つを示す。承諾は、カスタマからの能動的な応答であるか、または受動的な応答である。受動的な応答はたとえば、事前設定された限度までの自動的な承諾である。
【０００４】
ＵＳ５４６５２０６において、事前設定された規則にしたがって動作する支払いネットワークを介して、参加カスタマが請求額を参加請求者に対して支払う請求書支払いシステムが開示されている。参加カスタマは参加請求者から、金額および一意の請求者識別番号を示す請求書（紙／郵便の請求書、ｅメール通知の請求書、自動的借入のための暗黙的な請求書）を受け取る。送金額を認証するためには、カスタマは銀行（参加銀行）へ請求額支払いオーダを送信する。この請求額支払いオーダは、支払い日、支払い額、請求者によるカスタマの口座番号、資金源および請求者の請求者識別番号を、直接または静的データに対する参照によって示しており、データ要素を含んでいる。銀行Ｃは支払いメッセージを支払いネットワークへ送信し、請求者参照番号を割り当てる該支払いネットワークは、支払いメッセージを請求者の銀行へ転送する。その結果として、カスタマの銀行はカスタマの口座に借方記入し、支払いネットワークとともに正味持ち高に対して支払い義務を負う。また、請求者の銀行はネットワーク位置を支払いネットワークから受信し、請求者の銀行口座に貸方記入する。カスタマの銀行が、撤回不可の支払いメッセージを送信することに同意した場合、資金不足の場合に該カスタマの銀行が損失のリスクを負うことを承諾しなくても資金が十分になるまで、保証された支払いネットワークの場合、該カスタマの銀行はトランザクションを送信しない。請求者の銀行は、支払いメッセージの受信に応じて資金を請求者に解放し、請求者Ｂが指示した形態でＡ／Ｒデータを請求者へ供給する。この形態は、請求者に対して例外項目として処理する必要がない形態である。トランザクションが支払いネットワークの事前設定された規則に準ずる可逆的なトランザクションでない場合、請求者の銀行は該支払いネットワークによって支払いを確認する。特別な構成では、カスタマは請求額支払いオーダを手動で、ＡＴＭで紙を介して開始するか、ＰＣを介して開始するか、または電話機のダイヤルを介して開始する。
【０００５】
別のシステムが、ウェブサイトwww://ofx.net.から公知である。オープンフィナンシャルエクスチェンジ（ｏｆｘ）は、金融上のデータおよび命令をカスタマと金融機関との間で交換するための、広い支持基盤を有するフレームワークである。これによって、機関は媒介者を必要とせずに、カスタマと直接接続することができる。オープンフィナンシャルエクスチェンジは、誰もが具現化できるオープンな仕様である。すなわち、すべての金融機関、トランザクションプロセッサ、ソフトウェア開発者または他のパーティが具現化できるオープンな仕様である。ここでは、データフォーマット（ＸＭＬ等）、接続（ＴＣＰ／ＩＰおよびＨＴＴＰ）およびセキュリティ（ＳＳＬ）の、広く受け入れられているオープンな標準方式が使用される。オープンフィナンシャルエクスチェンジは、各金融サービスかつ共通のフレームワークおよびインフラストラクチャによって使用される要求メッセージおよび応答メッセージを定義することにより、これらのメッセージの通信を支援する。請求者およびカスタマのデータは、同一のシステムにて保持される。
【０００６】
しかし、請求者とカスタマとの間で直接的なコンタクトを使用するシステムは、異なる請求者の請求書を１つのカスタマに提示するというビジネスシナリオを技術的に具現化するのが困難であるという欠点を有する。さらに、このようなシステムを請求者およびカスタマのＩＴ（情報技術）システムに統合および維持するのは、とりわけ大きな請求所要量を処理しなければならない場合に困難である。
【０００７】
したがって、上記の問題の少なくとも一部を、より効率的に解決するための方法および／またはソフトウェアアプリケーションおよび／またはデータ処理システムが必要とされる。とりわけ、請求書処理をより効率的にするためのメカニズムを有するソフトウェアアプリケーションを提供するのが望ましい。
【０００８】
本発明の要約
本発明によれば、ここに実施例として記載され概略的に記載されているように、本発明の基本的思想によって構成された方法およびシステムによって、請求書を電子的に処理する次のような方法が提供される。すなわち、請求書をカスタマに対し、請求者からの請求情報およびマスタデータとカスタマからのマスタデータとを使用して作成し、
ａ）第１の処理モジュールを使用して、請求情報を請求者から受信するステップと、
ｂ）該第１の処理モジュールによって、請求情報と請求者のマスタデータとを使用して請求書を生成するステップと、
ｃ）カスタマのデータを第２の処理モジュールから、該第１の処理モジュールによって要求するステップと、
ｄ）生成された前記請求書のフォーマットが、カスタマのマスタデータで指定されたフォーマットでない場合、該第１の処理モジュールによって該請求書を、カスタマのマスタデータで指定されたフォーマットに変換するステップと、
ｅ）生成または変換された前記請求書を該第２の処理モジュールへ、該第１の処理モジュールによって伝送するステップとを有する方法が提供される。ここでは、該第１の処理モジュールは請求者のマスタデータにアクセス可能であり、該第２の処理モジュールはカスタマのマスタデータにアクセス可能である。
【０００９】
本発明の別の側面は、請求書を電子的に処理するための次のようなコンピュータシステムを提供することである。すなわち、請求書がカスタマに対し、請求者からの請求情報およびマスタデータとカスタマからのマスタデータとを使用して生成され、
・プログラム命令を有するメモリと、
・データを受信および入力するための入力手段と、
・データを送信および提示するための出力手段と、
・データを記憶するための記憶手段と、
・プログラム命令に対して応答するプロセッサとが設けられており、該プログラム命令は、
ａ）請求情報を請求者から、第１の処理モジュールを使用して受信するための命令と、
ｂ）請求書を該第１の処理モジュールによって、請求情報と請求者のマスタデータとを使用して生成するための命令と、
ｃ）カスタマのデータを第２の処理モジュールから、該第１の処理モジュールによって要求するための命令と、
ｄ）生成された前記請求書のフォーマットが、カスタマのマスタデータで指定されたフォーマットでない場合、該第１の処理モジュールによって前記請求書を、カスタマのマスタデータで指定されたフォーマットに変換するための命令と、
ｅ）生成または変換された前記請求書を該第２の処理モジュールへ、該第１の処理モジュールによって伝送するための命令であるコンピュータシステムを提供することである。ここでは、該第１の処理モジュールは請求者のマスタデータにアクセス可能であり、該第２の処理モジュールはカスタマのマスタデータにアクセス可能である。
【００１０】
方法およびシステムは、大量の請求書を効率的に、指定されたカスタマへ提供するという前記課題の解決に技術的に寄与する。複数の請求者が、請求情報を第１のモジュールへ供給することができる。請求情報は最後に、各カスタマによって指定されたフォーマットの請求書に変換される。
【００１１】
本発明はさらに、コンピュータシステムと、コンピュータプログラムと、コンピュータ読み出し可能な媒体と、搬送信号とを対象としている。これらはそれぞれ、本発明の方法にしたがい本発明の実施形態において請求書を処理するためのプログラムコードまたは命令を有する。
【００１２】
第１の処理モジュールおよび第２の処理モジュールはコンピュータプログラムとして、異なるハードウェアシステム（コンピュータまたはコンピュータシステム）にインストールすることができ、相互に別個に独立して動作させることができる。この異なるシステムは、相互に通信できるようにネットワークの形態で接続することができる。
【００１３】
本発明および本発明の実施形態の付加的な対象および利点が部分的に、詳細な説明に記載されているか、または実際に実施することによって習得することができる。本発明の対象および利点は、とりわけ従属請求項に記載された個々の要素および組み合わせによって実現および達成される。本発明の実施形態は、詳細な説明の部分および従属請求項において開示されている。
【００１４】
以下の全般的な説明および以下の詳細な説明は、双方とも単なる挙例および詳解のために記載されたものであり、請求項に記載されているように、本発明を限定するものではない。
【００１５】
図面の簡単な説明
本明細書に組み込まれており本明細書の一部を構成する添付図面によって、本発明の実施形態を図解し、詳細な説明とともに本発明の基本的思想を詳述する。
【００１６】
図面
図１  コンピュータシステムで本発明の方法の実施を概略的に示すブロック図である。
図２  本発明の方法の一例のブロック図である。
図３  本発明の電子的な請求書提示支払いシステムの一例の概観図である。
図４  第１の処理モジュールおよび第２の処理モジュールの接続の一例のブロック図である。
図５  本発明の請求プロセスの一例のフローチャートである。
図６  本発明の請求書提示プロセスの一例のフローチャートである。
図７  本発明の電子的請求プロセスにおいてカスタマを登録するためのプロセスの一例のフローチャートである。
図８  カスタマの登録を請求者によってアクティベートするためのプロセスの一例を示すフローチャートである。
図９  カスタマに対する請求者のＩＤを、請求者に対するカスタマのＩＤにマッピングするためのテーブルの一例を示すブロック図である。
図１０  本発明の電子的な請求書提示支払いシステムにｅバンキングを組み込む一例のブロック図である。
図１１  カスタマによる請求書の確認を開始および実行するためのプロセスの一例を示すフローチャートである。
図１２  図１１に示されたフローチャートの続きを示している。
図１３  請求者またはカスタマのデータのためのアーカイブプロセスの一例を示すブロック図である。
【００１７】
詳細な説明
コンピュータシステムとプログラムとは密接に関連している。以下で使用されているように、「コンピュータは供給する」および「プログラムは特定の動作を供給または実行する」、「ユーザは特定の動作を実行する」等のフレーズは、プログラムによって制御されるコンピュータシステムによる動作を表現するための便宜上の短縮表現であるか、または、コンピュータシステムが特定の動作を実行できるようにプログラムまたはプログラムモジュールが設計されていること、または、ユーザが特定の動作をコンピュータシステムによって実行できるようにプログラムまたはプログラムモジュールが設計されていることを表現するための便宜上の短縮表現である。
【００１８】
本発明の構想においてこれらの用語は、異なって定義されない限り、データ処理の分野のコンテクストにおいて通常の意味を有するものとする。コンピュータシステムは、ＰＣまたはラップトップ等の独立したコンピュータであるか、または会社内のネットワーク等のネットワークとして接続された複数のコンピュータであるか、またはインターネットを介して接続された複数のコンピュータである。
【００１９】
要約の部分に記載された本発明の方法の第１の実施形態は、ｆ）変換された請求書を第２の処理モジュールによって、第３の処理モジュールに対してアクセス可能であるように形成するステップを有することを特徴とする。
【００２０】
本発明の方法の第２の実施形態は、ｇ）変換された請求書を、カスタマに対してアクセス可能であるように形成するステップを有することを特徴とする。
【００２１】
第３の実施形態は、ｈ）変換された請求書をカスタマに対して提示または供給するステップを有することを特徴とする。
【００２２】
第４の実施形態は、請求書を第１の処理モジュールによってデジタル署名することを含んでいる。
【００２３】
第５の実施形態は、カスタマのアクセスのために、変換された請求書に、該変換された請求書の記憶位置に対するリンクまたは該請求書の詳細の記憶位置に対するリンクを設けることを特徴とする。
【００２４】
第６の実施形態は、請求書または変換された請求書を、印刷サービスへ送信することを特徴とする。
【００２５】
本発明の第７の実施形態では、請求書および／または変換された請求書を、第１の処理モジュールおよび／または第２の処理モジュールによって暗号化することが含まれている。
【００２６】
第８の実施形態は、請求書および／または変換された請求書を、第１の処理モジュールおよび／または第２の処理モジュールによってアーカイブすることを含んでいる。
【００２７】
別の実施形態は、カスタマの請求書の概略を提示するための手段を提供する第３の処理モジュールを特徴とする。有利には該第３の処理モジュールは、請求書を検証するための手段を提供する。本発明による方法の別の実施形態では、該第３の処理モジュールはワークフロー支援または請求書の異議申し立てのための手段を提供する。
【００２８】
別の実施形態は、第２の処理モジュールは国固有の請求書の提示および／または支払いのための手段を提供することを特徴とする。別の実施形態の特徴は、該第２の処理モジュールは、データを１つまたは複数の別の第２の処理モジュールと交換するための手段を提供することである。別の実施形態の特徴は、第２の処理モジュールが支払いオーダをカスタマから受信することである。別の実施形態は、第２の処理モジュールが支払いオーダまたは変換された支払いオーダを、支払いサービス提供者へ転送することを特徴とする。
【００２９】
本発明による方法の別の実施形態の特徴は、請求情報が、請求者および／またはカスタマおよび／または支払いサービス提供者のアドレス情報、支払い情報、ＶＡＴ情報と、購入オーダに関連する項目化された請求位置、および／または会計情報を有することである。別の実施形態では請求者のマスタデータは、アドレス情報、および／またはデータフォーマット情報、および／または通信アドレスに関する情報、および／または銀行情報および銀行口座情報、および／またはユーザ認証情報、および／またはユーザ許可情報、および／またはアーカイブサービスのための任意選択および／または印刷サービスのための任意選択および／または通知のための任意選択に関する情報を有する。別の実施形態ではカスタマのマスタデータは、アドレス情報、および／またはデータフォーマット情報、および／または通信アドレス、および／または銀行情報および銀行口座情報、および／またはユーザ認証情報、および／またはユーザ許可、および／またはアーカイブサービスのための任意選択に関する情報および／または通知のための任意選択に関する情報を含んでいる。
【００３０】
別の実施形態は、第２の処理モジュールが、１つまたは複数の別の第１の処理モジュールとデータを交換するための手段を有することを特徴とする。別の実施形態の特徴は、第２の処理モジュールが、１つまたは複数の別の第３の処理モジュールとデータを交換する手段を有することである。
【００３１】
別の実施形態では第２の処理モジュールまたは第１の処理モジュールは、特定のカスタマに対する請求者のＩＤを、特定の請求者に対するカスタマのＩＤにマッピングする手段を有する。
【００３２】
別の実施形態は、請求書を、請求者によって使用されたフォーマットからカスタマのマスタデータで指定されたのと同じフォーマットに、中間のフォーマットを使用せずに直接変換することを含んでいる。
【００３３】
第３の処理モジュールをコンピュータプログラムとして、第１の処理モジュールおよび第２の処理モジュールと同一のハードウェアシステムにインストールするか、または異なるハードウェアシステムにインストールして、他の２つのモジュールから別個に独立して実行することができる。第３の処理モジュールを、第２の処理モジュールの一部とすることもできる（第２の処理モジュールに組み込むことができる）。
【００３４】
コンピュータプログラムを実行するのに適したプロセッサはたとえば、汎用マイクロプロセッサおよび専用プロセッサ双方と、すべての種類のデジタルコンピュータのうち１つまたは複数のプロセッサとを有する。一般的には、プロセッサは命令およびデータを読み出し専用メモリまたはランダムアクセスメモリから受け取るか、または双方から受け取る。コンピュータの重要な要素は、命令を実行するためのプロセッサと、命令およびデータを記憶するための１つまたは複数の記憶装置である。一般的にはコンピュータは、データを記憶するための１つまたは複数の大容量記憶装置（記憶手段）も有しているか、または該大容量記憶装置からデータを受け取るかまたは該大容量記憶装置へデータを伝送するかまたは双方を行うために該大容量記憶装置と動作上有効に結合されている。前記大容量記憶装置はたとえば、磁気ディスク、磁気光学ディスク、または光学ディスクである。コンピュータプログラム命令およびデータを具現化するのに適した情報担体には、すべての形式の不揮発性メモリが含まれている。ここに含まれるのはたとえば、ＥＰＲＯＭ、ＥＥＰＲＯＭおよびフラッシュメモリデバイス等の半導体記憶装置、内部ハードディスクおよびリムーバブルディスク等の磁気ディスク、磁気光学ディスク、ＣＤ‐ＲＯＭディスクおよびＤＶＤ‐ＲＯＭディスクである。プロセッサおよびメモリは、ＡＳＩＣ（特定用途集積回路）によって補足するか、またはＡＳＩＣに包括することができる。
【００３５】
ユーザとのインタラクションを可能にするため、本発明を、ＣＲＴ（陰極線管）モニタまたはＬＣＤ（液晶ディスプレイ）モニタ等の表示装置と、キーボードと、マウスまたはトラックボール等のポインティング装置を備えたコンピュータ上で実施することができる。これによって、情報がユーザに対して表示され、ユーザがコンピュータに入力を行うことができる。別の種類の装置を使用して、ユーザとのインタラクションを可能にすることもできる。たとえば、ユーザに供給されるフィードバックは、視覚フィードバックまたは聴覚フィードバックまたは触覚フィードバック等のどの形式の感覚フィードバックでもよい。さらにユーザからの入力を、どの形式で受け取ってもよい。この形式には、音響入力、音声入力または触覚入力が含まれる。
【００３６】
ここで、データ処理プロセスに基づいて本発明を説明することにより、本発明の原理を詳述する。これらデータ処理プロセスの実施例は添付の図面に示されている。ここに挙げられた実施例は、本発明を説明するためのものであり、本発明をどのような意味でも制限しようとするものでない。
【００３７】
以下、第１処理モジュールを「請求者サービス提供者」（"biller service provider" ＢＳＰ）と称し、第２処理モジュールをコンソリデータ（"consolidator"  整理統合ユニット）と称し、また第３処理モジュールをカスタマーサービス提供者（"customer service provider" ＣＳＰ）と称する。ＣＳＰがコンソリデータに統合される場合、得られる組合せを「統合化されたＣＳＰ」（ｉＣＳＰ）と称する。
【００３８】
図１は、本発明の１実施形態の実施例を示している。ここでは本発明の方法を実施するプログラムモジュールを有するコンピュータシステムが示されている。図１にはＣＰＵ１０５を有するコンピュータ１０３と、ＣＰＵ１０５によって処理されるソフトウェアアプリケーションが記憶されている作業記憶装置１１２（メモリ）とからなるコンピュータシステム１０１が示されている。このソフトウェアアプリケーションには、本発明の方法にしたがい、第１処理モジュール、第２処理モジュールおよび第３処理モジュールをそれぞれ実行するプログラムモジュール１０６，１０９，１１０が含まれている。さらにコンピュータシステム１０１は、例えばプログラムモジュールをスタートさせるためおよび／またはデータ入力のためにユーザとのインタラクションするための入力手段１１７、出力手段１１２、ならびにデータを送受信するためのネットワーク接続部１１４を含む一般的な入／出力手段１０４を有している。ここでこのデータは、例えば、請求情報、請求書、支払いオーダ、カスタマおよび請求者のマスタデータなどである。複数のコンピュータシステム１０１を、ネットワーク１１３の形態でネットワーク接続部１１４を介して接続することができる。このような場合、各モジュール１０６，１０９，１１０は、別個および互いに無関係に各コンピュータ１１３において実装および実行することができる。この場合、ネットワークコンピュータ１１３は、さらなる記憶場所としての使用を含めて、さらなる入／出力手段として使用することができる。コンピュータシステム１０３はさらに、カスタマのマスタデータが記憶されている第１記憶手段１０７と、請求者のマスタデータが記憶されている第２記憶手段１０８とを含む。本発明の方法によれば、第１処理モジュール１１０（ＢＳＰ）は、記憶手段１０８に記憶されている請求者のマスタデータにアクセスでき、また第２処理モジュール１０６（コンソリデータ）は、記憶手段１０７に記憶されているカスタマのマスタデータにアクセスできる。請求者１１１およびカスタマ１１５は、入／出力手段１０４を介してコンピュータシステム１０３に常時接続されているか、またはオンデマンドベースで接続される。支払いサービス１１６に対して別のコネクションを確立することができる。請求者１１１およびカスタマ１１５と、付随するプログラムモジュール１１０，１０９とのインタラクションは、それぞれ破線の矢印で示されている。ＢＳＰおよびコンソリデータと、記憶手段１０８，１０７とのそれぞれの関係も同様である。
【００３９】
図２はいくつかのプログラムモジュール、すなわち、ＢＳＰ２０１ａ，２０１ｂ，コンソリデータ２０２ａ，２０２ｂ，２０２ｃ、およびＣＳＰ２０３のネットワークコネクションの例を示している。これらのモジュールはそれぞれ、別個のコンピュータシステム２０４ａ，ｂ，２０５ａ，ｂ，ｃおよび２０８に実装されている。それぞれのコンピュータシステムは適用事例の要求に依存して、同一でも互いに異なっていてもよい。コンピュータシステムは、世界中の別個の国々に設置することができる。一つまたはそれ以上の請求者がウェブブラウザ２０７ａ，ｂを使用し、コンピュータシステム２０６ａ，ｂを介してこのネットワークにアクセスすることができる。これらのコンピュータシステム２０６ａ，ｂは、各ＢＳＰ２０４ａ，ｂに接続可能である。カスタマは、ウェブブラウザ２１１を有するコンピュータシステム２１０を介してこのネットワークにアクセスすることができる。請求書に関連する支払いを実行するために、ｅバンキングアプリケーションを有する支払いサービス提供者のコンピュータシステム２０９を、１つまたはそれ以上のコンソリデータシステム２０５ａ，ｂ，ｃに接続することができる。
【００４０】
請求者マスタデータと、カスタママスタデータとを分ける本発明のコンセプトによれば、ＢＳＰを必要なだけ１つのコンソリデータに接続することができる。これによって、不必要なデータの移動が回避される。それは、請求書を処理するモジュールにカスタママスタデータを移動またはコピーする必要がないからである。これは従来技術の方法によれば必要である。このコンセプトによれば、例えば、１ヶ月当たりに数百万を上回る請求書量を、１つのコンソリデータに接続されているいくつかのＢＳＰで処理することができる。カスタママスタデータを更新しなければならない場合、本発明のシステムではこれは極めて簡単である。それは、コンソリデータのデータベースだけを変更すればよいからである。このような更新によってＢＳＰデータベースが影響を受けることはない。さらなる効果は、マスタデータに対するメンテナンスコストが低減されることである。
【００４１】
図３には、請求者とＢＳＰとの間、ＢＳＰとコンソリデータとの間、コンソリデータとＣＳＰとの間、およびＣＳＰとカスタマ（支払い者）との間でデータ交換することができるフォーマットおよびインタフェースの概要が示されている。請求者側は、３つのケースに分かれている。すなわち、ＳＡＰ  ＥＲＰシステム（ＳＡＰ  ＡＧ，D-69190 Walldorf, Germany）を使用する大規模の請求者と、ＳＡＰ  ＥＲＰシステムでないシステムを使用する大規模の請求者と、小規模の請求者とに分かれている。ここで「大規模」および「小規模」とは、それぞれの会社または各人員の取引高のことであり、説明のためだけの任意の尺度である。カスタマ側にも同じことが相応に当てはまる。この例においてＣＳＰは、大規模支払い者の場合にはｉＣＳＰとしてコンソリデータに組み込まれており、また小規模支払い者の場合には、択一的な２つの実装、すなわちＳＡＰポータルＣＳＰおよびオンラインバンキングＣＳＰを有する別個のプログラムモジュールである。この例においてＢＳＰは、請求情報に対して４つのフォーマットをサポートしている。すなわちＩＤＯＣ，FLATFILEおよびEDIFACTフォーマットおよびあらかじめ定義可能なＢＳＰであり、請求者およびＢＳＰのシステムをそれぞれのソフトウェアの実装中にこれらに適合化しなければならない。請求者側のシステムは、ＨＴＭＬ，ＨＴＴＰＳ，ＸＭＬ‐ＩＤＯＣ（ＳＳＬ），ＦＬＡＴ（ＳＳＬ），ＥＤＩ（ＳＳＬ）に基づいてＢＳＰと通信することができる。ＢＳＰおよびコンソリデータ、またコンソリデータおよびＣＳＰも、ＸＭＬを介して通信することができる。ＣＳＰおよび／またはｉＣＳＰは、ＨＴＭＬ（ＨＴＴＰＳ），ＸＭＬ‐ＩＤＯＣ（ＳＳＬ），ＥＤＩ（ＳＳＬ）およびＸＭＬに基づいてカスタマのシステムと通信することができる。
【００４２】
図４は、ＢＳＰおよび／またはＣＳＰおよび／またはｉＣＳＰが有し得るインタフェース（ＩＦ）の例を示している。すなわち請求者またはカスタマのＥＤＩ／ファイルＩＦ，ウェブＧＵＩ（graphical user interface），ＢＣＸ，フラットファイル（Flat File）変換，プリントＩＦ，アーカイブＩＦ，請求エンジンとのコネクションに対するコストイベントＩＦ，支払いサービス（金融機関）とのコネクションに対するＩＦ，またはインターネットサービスプロバイダ（ＩＳＰ）とのコネクションに対するＣＣＸ  ＩＦが示されている。これらの請求者は、その請求書要約のリストを見るため、請求者はＢＳＰに接続することができ、カスタマは好みに応じて、ＣＳＰ／ｉＣＳＰに直接接続するか、または金融機関またはＩＳＰへのコネクションを介して間接的に接続することができる。項目化された請求書および登録に対して、カスタマはＢＳＰに接続することができる。ＢＳＰは、請求者に関連するすべてのデータをパートナデータベースに記憶する。請求者のマスタデータは、アドレス、識別キー、権限付与、請求者統合化レベル（インタフェース能力および実装された処理）、ロゴ、請求書におけるロゴの位置、個人別の販売促進に対する宣伝フォーム、クレジットに対するフォーマット、ディジタル署名などを含む。請求情報、生成および／または変換された請求書、ウェブ提示に対する請求書の詳細は、ＢＳＰによってビジネスオブジェクトデータベースに記憶することができる。この意味でのビジネスオブジェクトは、特定の請求書の発生原因としてのビジネストランザクションに属するデータ全体のことである。典型的な請求情報は、品物、品物のタイプ、番号、ポジション、ＩＤ、品物の説明、価格、税情報、住所（例えば配送用）、参照（詳細に対するＵＲＬ）、日付（例えば、請求日）などである。コンソリデータ／ｉＣＳＰは、カスタマおよび金融機関に関連するすべてのデータをパートナデータベースに記憶する。すなわち、カスタマのアドレス、カスタマの組織内およびカスタマと請求者との間の通信用のアドレス、請求書を提示すべきフォーマット、ステータス情報または異議申し立てまたは調査管理を供給するためのアドレス、識別キー、権限付与、ディジタル署名などを含むカスタマのマスタデータを記憶する。カスタマに提示すべき請求書サマリまたは整理統合または総計された請求書は、コンソリデータ／ｉＣＳＰによってコンソリデータのビジネスオブジェクトデータベースに記憶される。このようにして、請求書量を処理するために必要な数のＢＳＰを１コンソリデータ／ｉＣＳＰに接続することができる。
【００４３】
プログラムモジュール１０６，１０９，１１０が図１のＣＰＵ１０５によって処理されて本発明の方法が実施される場合、以下に説明するステップが上記のようにコンピュータシステム１０１またはネットワークのシステムによって実行される。
【００４４】
図５は、本発明の方法の例示的な実施の流れ図を示している。このタイプの流れ図の時間軸は、上から下に経過する。請求者は（そのＥＲＰコンピュータシステムによって）、この請求者がＢＳＰ登録時に合意したフォーマットで請求情報をＢＳＰに送信する。ＢＳＰは、この請求情報および請求者マスタデータに基づいて請求書を作成し、ステータス「新しい」をこのオブジェクトに割り当てる。次にこのＢＳＰは、カスタマについての情報の要求（CustomerInfoRequest）をコンソリデータ／ｉＣＳに送信する。コンソリデータ／ｉＣＳＰはこの要求に応答して、問い合わされたカスタマに対するカスタママスタデータベースから、使用可能なデータをこのＢＳＰに返す（CustomerInfoResponse）。上で示した情報に加えて、上記の応答は、カスタマが、ウェブ提示のための請求書データを要求したか（疎な整理統合化、「疎である」のは主要な情報だけがカスタマに提示されるからである）、またはＥＲＰシステムにおける処理のための請求書データを要求したか（密な整理統合化、「密である」のはこの請求書が、請求書の詳細を含めてカスタマに電子的に送信されるからである）、または適用可能な税または別の法的な規定にしたがってディジタル署名フォーマットで行うか、または提示する請求書を暗号化するか否かについての情報を含むことができる。さらに付加的に上記の応答は、各ＥＲＰシステムにおける各ＩＤに関する、請求者とカスタマとの関係についての情報（ＢＣＲ  biller to customer relation）を含むことができる。さらに付加的に上記の応答は、項目化された請求書にアクセスするためまたは暗号化（ディジタルＩＤのリスト、識別名（distinguished name）、証明シリアル番号など、Ｘ．５０９証明書を参照する）に対する認証情報を含むことができる。次にＢＳＰは、CustomerInfoResponse（カスタマ情報応答）で受信したフォーマットに請求書を変換する。
【００４５】
データは、ソースフォーマットからターゲットフォーマットにできるだけ直接的に、ソースのできる限り近くで変換すべきであり、また可能であれば、変換は回避すべきである。それはデータ損失のリスクを孕んでいるからである。ターゲットフォーマットを内部で形成できない場合には、ＢＳＰは外部の変換サービスを使用することができる。理由は、ＢＳＰにおいて請求書を直接的にカスタマのフォーマットに変換することにより、ＶＡＴ控除に対する政府の規定に適合する請求書をディジタル署名することができるからである。カスタマは直接、処理して、明細請求書をアーカイブすることができ、これによって簡単な統合化プロセスが得られ、アプリケーションコンテンツを比較的簡単に保存することができるようになる。サポートされるフォーマットの総数を少なくすること（標準化）によって変換作業およびコストが低減され、ＰＳＰ（支払いフォーマット）固有の適合化は、コンソリデータ／ｉＣＳＰにおいて処理することができる。
【００４６】
従来技術によるＥＢＰＰシステムのコンテキストでは変換は、中間（社内"in-house"）フォーマットを使用することによって間接的に行われ、ソースデータはまずこの社内フォーマットに変換され、つぎにターゲットフォーマットに変換される。この技術の利点は、変換の回数が、フォーマットの数（ｎ）に対して、直接変換の場合のｎ(ｎ−１)と比較して線形（２ｎ）になることである。しかしながら中間フォーマットというものがＢＳＰの提示時における変換にも使用できる事実とは関係なく、カスタマフォーマットへの変換は提示プロセスにおいてできる限り早く行うべきである。ＢＳＰにおいてエンドユーザフォーマットに明細請求書を変換することの利点は、ＢＳＰにおいてこの請求書に署名できることである。請求者は、その請求書作成プロセスをＢＳＰに外注するので、ＢＳＰに署名を委任することが可能である。コンソリデータにおいてＰＳＰフォーマットを請求者およびカスタマのフォーマットに変換することの利点は、コンソリデータだけがＰＳＰ（例えば国）固有拡張を含むことである。ＢＳＰおよびＣＳＰはＰＳＰフォーマットには無関係のままである。
【００４７】
ＢＳＰは第３者のハードウェアシステムに実装されている場合、法的には請求者の外注パートナとして扱われる。同じことがＣＳＰおよびコンソリデータ／ｉＣＳＰにも相応に適用される。この点においてＢＳＰは、電子的な請求書を請求者に代わって作成し、またオプションとして紙の請求書も作成するのである。法人としての請求者は、ＢＳＰを運営する法人に請求書にディジタル署名する権利を委任するのである。ＢＳＰは、カスタマによって承諾され、可読であり、処理可能であり、かつＶＡＴ控除において有効なフォーマットで、ディジタル署名された明細請求書メッセージを作成しなければならない。これは上述の変換プロセスを使用することによって達成される。カスタマは、上記の委任をオンラインでチェックすることができる。請求者のリスト（電子請求書に対するカスタマ登録を参照されたい）は、ＢＳＰにありかつ請求者によってディジタル署名された委任文書へのハイパーリンクを含んでいる。
【００４８】
多くの欧州の国々では、最近まで、購入した品物に対するＶＡＴ（Value Added Tax）の払い戻しのために、明確に規定された最小セットの情報を有する紙の明細請求書を管轄官庁に提示しなければならなかった。また請求明細の文書は、請求者が印刷しなければならなかった。電子的に伝送され、カスタマによって印刷された請求書は認められなかったのである。欧州連合および他の国々（例えばスイス）では新たな法律および規則により、請求者によってディジタル署名された請求書であれば、電子的に伝送された請求書に基づくＶＡＴ控除が認められる。署名に使用される証明および手続きは規制されている。
【００４９】
要求されるフォーマットを生成するためにＢＳＰは、外部の変換サービス、例えばウェブサービスにアクセスすることができる。考えられ得るカスタマのアクセスに対する請求書の提示には準備がなされる。選別：カスタマと電子的に連絡を取れない場合、例えばCustomerInfoResponse（カスタマ情報応答）が「不明」を返す場合、ＢＳＰは紙の請求書を生成し、および／または請求者に相応に通知することができる。
【００５０】
請求情報に含まれている明細請求書送付日付に達したら、ＢＳＰは、変換した請求書をコンソリデータ／ｉＣＳＰに送付する（InvoiceDeliveryRequest 明細請求書送付要求）。付加的にＢＳＰは、コンソリデータ／ｉＣＳＰに、請求者の統合化状況についての情報を提示する（BillerPreference 請求者好み設定）。これらの情報は、コンソリデータ／ｉＣＳＰが、受信した変換済み請求書を操作するのに有益である。これらの操作は、利用可能なクレジットの通知またはクレジット通知フォーマット、請求者に対するその時点のビジネストランザクションのステータス（例えば、請求書送付済、または請求額支払い済、等）、サポートされている処理（例えば、異議申し立て、送金通知拒絶など）に対する要求である。コンソリデータ／ｉＣＳＰは、変換した請求書が、カスタマがアクセスするために使用できることを、ＢＳＰへのｏｋ応答によって確認する（InvoiceDeliveryResponse 明細請求書送付応答）。ＢＳＰは、請求書のステータスを「送付済み」に設定し、コンソリデータ／ｉＣＳＰは、受信した変換済み請求書のステータスを「オープン」に設定する。
【００５１】
次の処理ステップは、カスタマがウェブカスタマであるか、またはＥＲＰカスタマであるかに依存するか、または支払いの好みが、特定のカスタマに対して適用可能であるか否かに依存するか、または請求者およびカスタマの支払いサービス提供者（ＰＳＰ）の接続状況に依存する。いくつかのオプションを挙げると、バンキングポータルを使用したウェブ提示および支払い（ＣＣＸ ＩＦ）、ＩＳＰ（例えばyahoo）およびＰＳＰを使用するウェブ提示および支払い、支払いチャンネル（payment channel）を使用するＥＲＰ接続および支払い、ＳＡＰ ＥＢＰＰシステムを使用したＥＲＰ接続および支払いがある。カスタマは、変換された自分の請求書をコンソリデータ／ｉＣＳＰから受け取るか、またはウェブポータルを介して、コンソリデータおよび／またはｉＣＳＰデータベースにある、変換された請求書にアクセスする（請求書送付）。オプションのステップを、明細請求書検査、資料管理とのクロスチェック、支払い処理のための作業フローに基づいて行うことができる。次に（オプションでディジタル署名された）支払いオーダがコンソリデータ／ｉＣＳＰに送信される。次にコンソリデータ／ｉＣＳＰは、支払いオーダによって構成された支払いスケジュール情報をＢＳＰに伝える（SetEBPPStatusRequest）。次にＢＳＰは、（オプションではスケジュールされた）支払いを請求者に通知する。直ちにまたは要求された支払い日に、コンソリデータ／ｉＣＳＰは、ＰＳＰによって要求されたフォーマットで支払いオーダを生成し、この支払いオーダをＰＳＰに送信する。この支払いオーダは、暗号化法で認証され、ＰＳＰは支払いを処理する。その際に要求があれば、銀行間支払い処理が使用される。カスタマのＰＳＰは、コンソリデータ／ｉＣＳＰに要求して、口座引き落とし通知（debit advice）をカスタマに送信させる。コンソリデータ／ｉＣＳＰは、カスタマが要求したフォーマットで口座引き落とし通知を生成し、メッセージをカスタマに送信させる（口座引き落とし通知）。変換された請求書のコンソリデータ／ｉＣＳＰにおけるステータスは、「支払い済」に設定される。請求者のＰＳＰは、コンソリデータ／ｉＣＳＰに要求して、この請求者にクレジット通知を送信させる。コンソリデータ／ｉＣＳＰは、請求者によって要求されたフォーマットでクレジット通知を生成して、ステータス変更要求と一緒にそのメッセージをＢＳＰに送信する（SetEBPPStatusRequest）。ＢＳＰは、このクレジット通知メッセージを請求者に送信して、請求書のステータスを「支払い済」に変更する。
【００５２】
図６には請求書提示プロセスの例示的なフローチャートが示されている。
【００５３】
カスタマまたはユーザは、ＣＳＰ／ｉＣＳＰにログインする（標準的なプロシージャ：ディジタルＩＤ（X.509），ＳＳＬクライアント認証）。このＤＮ（distinguished name 識別名）がｉＣＳＰ／コンソリデータへウェブアクセスするのを許可しなければならない。このユーザは次にクライアント（カスタマ）を選択するか、またはこのユーザがクライアントを有しない場合、該ユーザがすでにログインしているカスタマの整理統合された請求書のリストを直接選択することができる（GetListOfBills）。このリストの各請求書毎に、典型的には以下のデータを提示する。すなわち、明細請求書参照、請求者名、請求者銀行預金口座、支払期日、通貨による金額、ビジネストランザクション（請求書）ステータス（オープン、（または催促）、満期、予定、支払済み、異なる金額による支払い）、請求書に対する付加的な情報用のハイパーリンク（ルーペシンボルまたは下線付きの明細請求書参照）を提示することができる。カスタマは、ハイパーリンクを選択して、請求書に対する付加的な情報を得ることができる。この（ＳＳＬ）ハイパーリンクは、請求者の情報ページをポイントしており、これは、通常、ＢＳＰがホストをしている（択一的な例としてはこのページは請求者のウェブサーバに存在することも可能である）。ＢＳＰは、トークン（請求書の詳細が準備される時点で生成され、請求書サマリの一部として渡される）に基づいてカスタマを認証する。このトークンは、ハイパーリンクと一緒にＢＳＰに戻される。カスタマが強力な認証を要求する場合、認証がCustomerInfoReference（カスタマ情報参照。前の図を参照されたい）で指定された証明書のうちの１つと一致する場合にだけ請求書が提示される。ＢＳＰは複数のＨＴＭＬテンプレートを保持しており、参照されたビジネストランザクション（請求書）に基づいて適切なテンプレートを選択する。このテンプレートは、書き込むべきビジネストランザクションデータを参照することができる（例えば、個人別の広告に有効である）。カスタマアドレスに基づき、また請求者との合意により、ローカルな第３者の広告を付加することができる。生成したＨＴＭＬページは、項目化された請求書へのハイパーリンクを含む。カスタマは、この項目化された請求書へのハイパーリンクを選択して、（認証の後）ＰＤＦフォーマットで請求書を受信する。
【００５４】
図７には、電子請求書に対するカスタマの登録プロセスの例示的なフローチャートが示されている。
【００５５】
カスタマまたはユーザは、ＣＳＰ／ｉＣＳＰにログインする（標準的なプロシージャ：ディジタルＩＤ（X.509），ＳＳＬクライアント認証）。このＤＮ（distinguished name 識別名）がｉＣＳＰ／コンソリデータのマスタデータへのウェブアクセスするのを許可しなければならない。ユーザは次にクライアント（カスタマ）を選択するか、またはこのユーザがクライアントを有しない場合、請求者のリストを直接、選択することができる。コンソリデータは、電子的な請求者への情報を含む（通常は管理保持された）ＨＴＭＬテンプレートを保有している。このリストには、ロゴおよびＢＳＰからの請求者データを補足することができる。ここでこれはハイパーリンクを使用して行われる（択一的にはこのデータをコンソリデータにおいてローカルに保持することも可能である）。また提示されるリストは、各請求者ごとにカスタマ登録ステータス（イナクティブ、アクティブ、登録要求、登録拒絶）も含んでいる。この登録ステータスは、コンソリデータのＢＣＲ（Biller Customer Relation 請求者カスタマ関係）テーブルに記憶される。カスタマは、請求者を選択する。登録フォームに対するＵＲＬは、ＢＳＰ（または請求者のウェブサーバ）をポイントする。ＢＳＰは、カスタマＰＩＤ（Partner Identification Number パートナ識別番号）をこのＵＲＬから受信する。またこのカスタマを認証できない場合、ＢＳＰは、コンソリデータから受信したＰＩＤに一致するカスタママスタデータを受け取る。請求者固有のＨＴＭＬテンプレートに基づいて登録フォームが提示される。これはカスタマのマスタデータ（編集不可）と、少なくとも登録または登録を取り消すためのボタンを含む。付加的に請求者は、ＢＣＮ（Biller's Customer Number請求者側のカスタマ番号または債権者番号）を要求することができる。カスタマがこの請求書をＥＲＰシステムで処理する場合、この登録フォームは、ＣＢＮ（Customer's Biller Number カスタマ側の請求者番号 ＝ 債務者番号）を記入するために１フィールド分拡張される。カスタマは、この登録フォームを記入完了し、これをＢＳＰに返送する。ＢＳＰは、コンソリデータにおいて「登録要求（registration＿requested）」のステータスを有するＢＣＲエントリを作成する。ＢＳＰは、新たな登録について請求者に（例えばＥメールで）通知することできる（オプション）。
【００５６】
図８は、カスタマの登録に対する請求者の動作の例示的なフローチャートを示している。
【００５７】
請求者または（請求者の）ユーザは、ＢＳＰにログインする（標準的なプロシージャ：ディジタルＩＤ（X.509），ＳＳＬクライアント認証）。ＢＳＰのマスタデータへのウェブアクセスに対してＤＮ（distinguished name 識別名）を許可しなければならない。ユーザは次にクライアント（請求者）を選択するか、またはこのユーザがクライアントを有しない場合、フィルタリング検索条件（例えば、すべてのregistration＿requested 登録要求）を直接定めて、カスタマのリストにアクセスすることができる。ＢＳＰは、この要求をコンソリデータ／ｉＣＳＰに送信して、コンソリデータ／ｉＣＳＰの応答を処理し、請求者にカスタマのリストを提示する。請求者は、提供された登録情報を詳細に調べて（ＢＣＮおよびカスタマ名における不整合は回避すべきである）、登録データが正しい場合にはＢＣＲステータスを「アクティブ」にする。ＢＳＰは、SetBCRState（ＢＣＲ状態設定）要求を使用して、コンソリデータ／ｉＣＳＰにＢＣＲ状態を設定する。ＢＣＲテーブルにおいて適切な状態を設定した後、コンソリデータ／ｉＣＳＰは、（例えばＥメールによって）カスタマに通知することができる。
【００５８】
図９には請求者カスタマ関係テーブルのコンセプトが示されている。
【００５９】
請求者カスタマ関係コンセプトは、請求者またはカスタマＥＳＰシステムの統合化を最適にサポートするために設計されている。
【００６０】
ＢＣＮ（Billers Customer Number 請求者側カスタマ番号）：ＢＣＮまたは債務者番号は、コンソリデータ／ｉＣＳＰシステムに記憶することができる。これによって請求者は、ＢＳＰに送信される請求データに存在するカスタマ識別子を使用することができる。コストのかかるマッピングを回避することができる。カスタマ登録プロセスにおいて取得された情報に基づいて、コンソリデータ／ｉＣＳＰは、ＢＣＮを一意的なカスタマ識別子（例えば、ＣＰＩＤ，Customer Partner Identification カスタマのパートナ識別子）にマッピングすることができる。
【００６１】
ＣＢＮ（Customers Biller Number カスタマの請求者番号）：カスタマＥＲＰシステムにおいて請求者を識別するために使用される債権者番号も、カスタマ登録プロセス中にコンソリデータ／ｉＣＳＰに記憶される。これによってＢＳＰは、ＢＳＰにおける変換中にＢＰＩＤ（Biller Partner Identification 請求者のパートナ識別子）を、カスタマＥＲＰシステムに既知である請求者ＩＤに直接マッピングすることができる。したがってカスタマは、面倒でコストのかかるＩＤのマッピングを実装する必要はないのである。
【００６２】
図１０にはＣＣＸ ＩＦを使用したｅバンキング統合化が示されている。ＣＣＸ（Consolidator CSP Exchange コンソリデータＣＳＰ交換）インタフェースを使用すれば、ｅバンキングソリューションにより、請求書提示を統合化することができる。カスタマは、複数のＣＳＰ（マルチバンキング）を使用することができる。すなわち、ＣＳＰは、提示のために、コンソリデータ／ｉＣＳＰにおける請求書のその時点のリストを取り出すことができる。請求書はＣＳＰによって単純にルーティングされるのではない。これによりカスタマは、相異なる複数のＣＳＰ（例えば銀行）からの自分の請求書を見て、支払うことができるという独特の手段が得られる。
【００６３】
図１１および１２には、請求書を確認するための作業フローの例示的なフローチャートが示されている。
【００６４】
ここではディスパッチャと称することにするカスタマの１従業員は、コンソリデータ／ｉＣＳＰにログインして請求書のリストを選択する（ウェブ請求書提示を参照されたい）。確認作業フローのための準備がまだ整っていない請求書の場合、ディスパッチャは、SetUpReviewWorkflow（確認作業フローのセットアップ）を選択することができる。フォームが提示されると、ディスパッチャは、確認者のリストを決めることができる。これは確認者のＥメールアドレス（またエイリアス）を入力することによって行われる。ディスパッチャは、またテキスト（質問、請求書項目の割り当てその他）を入力することもできる。これと並行してディスパッチャは、項目化された請求書を提示させることができる（ウェブ請求書提示を参照されたい）。ディスパッチャは、このフォームをコンソリデータ／ｉＣＳＰに返送する（PostReviewForm）。ｉＣＳＰ／コンソリデータは、Ｅメールを確認者に送信する（可能であれば、暗号化またはプライベート（社内）ネットワークを使用する）。このＥメールは作業項目、確認請求書および（カスタマイズ可能な）短い説明へのハイパーリンク（ＵＲＬ）を含むことができる。オプションで、このＥメールは認証トークンを含むことが可能である。ビジネストランザクションのステータスは、「請求書確認」に変更される。このＥメールの受信者は、このＥメールにリストアップされていたｉＣＳＰ／コンソリデータのＵＲＬに接続する。ｉＣＳＰは有利にはＳＳＬクライアント認証を使用し、受信した証明書と、マスタデータ内の認可された証明書とを比較するか、またはＵＲＬのトークンに基づいてユーザを許可するか、ユーザｉｄ／パスワードメカニズムに基づいてユーザを認証する（認証／許可方式はシステムにおいてカスタマイズ可能である）。ｉＣＳＰ／コンソリデータは、これまで付加したすべてのデータと一緒に現在の確認フォームを返送する。この確認フォームも付加的な請求情報へのハイパーリンクを含むことができる（ウェブ請求書提示を参照されたい）。ユーザは、請求書の内容についてコメントおよび会計情報を付加することができる（例えば、ポジション３は受信していない、ポジション１および４はｏｋ、内部明細番号XYZに変更その他）。記入済みのフォームはｉＣＳＰ／コンソリデータに返送される（PostReviewForm）。別の確認者も、自分の作業フローの項目を同様に処理することができる。ディスパッチャまたは権限を有する別の任意のユーザは、任意の時点に請求書のリストを介して確認フォームにアクセスすることができる。すべての確認者が確認フォームを送り、ビジネストランザクションの状態が期限日に依存して「オープン」または「期限日」に設定されると、システムはあらかじめ定めたアドレスにメッセージを送信する。確認者は、別の請求書または請求書のリストにアクセスする必要はない。認証／許可だけをｉＣＳＰ／コンソリデータに記憶するだけでよい（例えば、ディジタルｉｄを有する確認者に対し、そのＤＮだけを請求書確認のための権限と結び付けて記憶するだけでよい）。
【００６５】
図１３には例示的なアーカイブ作成プロシージャが説明されている。アーカイブ作成は、適用可能な規則（ＶＡＴ）の要求を満たさなければならない。請求者は、ＢＳＰとのすべてのビジネストランザクション（請求書）を含むＣＤまたはＤＶＤ ＲＯＭまたは別の読み取り専用の装置の形態でアーカイブを受け取る。カスタマも請求者と同じ形態で、ｉＣＳＰ／コンソリデータとのすべてのビジネストランザクションを含むアーカイブを受け取ることができる。ＰＳＰおよびサポート組織もそれ自体のデータを含むアーカイブを受け取ることができる。アーカイブは以下のものを含むことができる：
ＢＳＰ、ｉＣＳＰ／コンソリデータによってそれぞれディジタル署名されたインデックス。ここでこのインデックスは、アーカイブにあるすべてのビジネストランザクションの請求書サマリを含む。このインデックスにはディジタル署名することができ、これによって各ビジネストランザクション（提示された請求書）毎にアーカイブ内容の証明ができるようにする（ビジネストランザクションは除去できない）。
【００６６】
請求書サマリと、すべてのビジネストランザクションイベントの履歴と、オリジナルメッセージへのハイパーリンクとを含むビジネストランザクションリポート。
【００６７】
交換されたすべてのメッセージ。例えば、構造化されたメッセージ（ＸＭＬ ＩＤＯＣまたはEDIFACTなど）としてのディジタル署名された明細請求書、同様にディジタル署名されたＰＤＦファイルとしての明細請求書、など。
【００６８】
オプションでは暗号化メカニズムが適用されて、アーカイブのいかなる内容変更も回避される。このアーカイブは、請求者またはカスタマの要求にしたがって定期的に作成することができる。アーカイブを請求者またはカスタマに送付することができる。受け取り側は、受け取ったアーカイブが読み取れることを確認することができ、これは「アーカイブ受け入れ」メッセージを送信することによって、またはこの受け入れをインタラクション的に確認することによって行われる。 所要の受入メッセージをすべて受信した後、また設定可能な営業日数（典型的には９０日）の後、ビジネストランザクションは、ＢＳＰおよびｉＣＳＰ／コンソリデータからそれぞれ除去することできる。
【００６９】
上に示した本発明の方法およびシステムにより、ＥＢＰＰシステムにおける次のような要求が満たされる。すなわち、請求者ＩＴシステムとカスタマＩＴシステムとを簡単に統合化すること、１つのカスタマに対して、異なる請求者の請求書を整理統合すること、支払いに対して複数の金融機関を許容すること、請求書の詳細のプライバシーおよびアクセスセキュリティ、政府のＶＡＴ規定の遵守、請求書量についての高いスケーラビリティ、クロスボーダーのＥＢＰＰを許容すること、および請求書確認作業フローなどの要求が解決される。
【００７０】
ここに示した実施例および本明細書の考察から当業者には本発明の変更および適合化が明らかであろう。本発明の実施について上で述べたことは、例解および説明を目的として示しただけである。ここに記載されたものだけがすべてではなく、また開示した内容と正確に同じ形態に本発明を制限するものではない。上で教示した内容を考え合わせれば変更および変形が可能であり、また本発明の実施例から変更および変形を得ることもできる。例えば、上で説明した実現はソフトウェアを含むが、本発明に見合ったシステムおよび方法をハードウェアおよびソフトウェアの組合せとして、またはハードウェア単独で実現することができる。さらに、メモリに記憶することに関して本発明の種々の側面を説明したが、当業者には、これらの側面は、別のタイプのコンピュータ読み取り可能な媒体、例えばハードディスク、フロッピィディスク、またはＣＤ−ＲＯＭ等の２次記憶装置、インターネットまたは別の伝搬媒体、またはＲＡＭまたはＲＯＭの別の形態にも記憶することができることがわかるであろう。明細書および実施例は例示だけのものとみなされることを意図しており、本発明の真の範囲および思想は添付の特許請求の範囲に示されている。
【００７１】
言葉による説明およびフローチャートに基づくコンピュータプログラムは、経験を積んだ開発者の技量の範囲内にあるものである。当業者に公知の任意のテクニックを駆使して種々のプログラムまたはプログラムモジュールを作成することができ、または既存のソフトウェアと結びつけて設計することができる。例えば、プログラムまたはプログラムモジュールは、Ｊａｖａ(Ｒ)，Ｃ＋＋，ＨＴＭＬ，ＸＭＬまたはＪａｖａアプレットが組み込まれたＨＴＭＬで、またはこれらを用いて設計することができ、またはＳＡＰ Ｒ／３またはＡＢＡＰで設計することできる。１つまたはそれ以上のこのようなモジュールを既存のＥメールまたはブラウザソフトウェアに組み込むことができる。
【図面の簡単な説明】
【００７２】
【図１】コンピュータシステムで本発明の方法の実施を概略的に示すブロック図である。
【図２】本発明の方法の一例のブロック図である。
【図３】本発明の電子的な請求書提示支払いシステムの一例の概観図である。
【図４】第１の処理モジュールおよび第２の処理モジュールの接続の一例のブロック図である。
【図５】本発明の請求プロセスの一例のフローチャートである。
【図６】本発明の請求書提示プロセスの一例のフローチャートである。
【図７】本発明の電子的請求システムにおいてカスタマを登録するためのプロセスの一例のフローチャートである。
【図８】カスタマの登録を請求者によってアクティベートするためのプロセスの一例を示すフローチャートである。
【図９】カスタマに対する請求者のＩＤを、請求者に対するカスタマのＩＤにマッピングするためのテーブルの一例を示すブロック図である。
【図１０】本発明の電子的な請求書提示支払いシステムにｅバンキングを組み込む一例のブロック図である。
【図１１】カスタマによる請求書の確認を開始および実行するためのプロセスの一例を示すフローチャートである。
【図１２】図１１に示されたフローチャートの続きを示している。
【図１３】請求者またはカスタマのデータのためのアーカイブ作成プロセスの一例を示すブロック図である。
【図１】
2005537589.tif 000002
【図２】
2005537589.tif 000003
【図３】
2005537589.tif 000004
【図４】
2005537589.tif 000005
【図５】
2005537589.tif 000006
【図６】
2005537589.tif 000007
【図７】
2005537589.tif 000008
【図８】
2005537589.tif 000009
【図９】
2005537589.tif 000010
【図１０】
2005537589.tif 000011
【図１１】
2005537589.tif 000012
【図１２】
2005537589.tif 000013
【図１３】
2005537589.tif 000014