(57)【要約】企業対消費者および企業対企業の取引の両方において用いることのできる電子請求提示および支払い（ＥＢＰＰ）システムおよび方法である。このシステムは、システムのユーザーが消費者の請求書の支払いをするための好ましい金融機関とユーザーである消費者が取引する特定の請求書作成者の両方を指定できるようにして、両方が単一のウェブサイトにアクセスできるようにする。消費者の財力および特定の支払い請求会社要求からの消費者の購入品に関する情報は、金融機関と請求書作成会社の間で共有される必要がないので、セキュリティおよび消費者のプライバシーを高める。金融機関情報、支払い請求会社情報およびプレゼンタ情報の単一のページでの単一の提示のルック・アンド・フィールは、金融機関および請求書作成会社の両方のサーバーから取得したデータを取り込んでいる中央集中データベースから情報の提示をできるようにするフラッシュX技術をうまく用いることによって与えられる。
2007524887.tif 000002
【特許請求の範囲】
【請求項１】
電子請求提示および支払い（ＥＢＰＰ）システムであって、該システムは、ＥＢＰＰウェブサイトのためのウェブページを記憶するためのメモリ、およびメモリと連絡しているプロセッサを備え、前記プロセッサは、（i
）ＥＢＰＰユーザー・インタフェース（ＵＩ）をＥＢＰＰホスト計算機から受け、ＵＩは、ＵＩの第１の部分に金融機関の情報を表示するように構成され、ＵＩの第２部分に請求書作成会社の情報を表示するように構成され、そしてＵＩの第３の部分に請求データを表示するように構成されており、（ii）ＵＩの第１の部分に表示するための金融機関情報を受け、（iii）請求書作成会社の情報および請求データの要求を送り、（iv）ＵＩの第２部分に表示するための請求書作成会社の情報およびＵＩの第３の部分に表示するための一つ以上の請求書を識別する支払請求データを受け、（v）代金を払われる請求書作成会社の一つ以上の請求書を持つための指示をＥＢＰＰホスト計算機に送り、そして（vi）支払い情報を請求書作成会社に伝えるために働くことを特徴とする電子請求提示および支払いシステム。
【請求項２】
金融機関情報は、金融機関の製品／サービス促進情報から成る請求項１のシステム。
【請求項３】
請求書作成会社の情報は、製品／サービス促進情報、メッセージおよびリンクから成る請求項１のシステム。
【請求項４】
ＵＩのコンテンツは、マクロメディア・フラッシュ（Ｍａｃｒｏｍｅｄｉａ  Ｆｌａｓｈ）および他のマクロメディア製品ラインにある請求項１のシステム。
【請求項５】
ＥＢＰＰシステムは、企業対企業構成部分および企業対消費者構成部分を備える請求項1のシステム。
【請求項６】
プロセッサは、企業と消費者の両方のために働く請求項１のシステム。
【請求項７】
プロセッサは、金融機関情報、請求書作成者情報およびプレゼンタ情報を単一のウェブページ上に提示するために金融機関および支払請求会社の両方のサーバーから取得したデータを中央集中データベースから検索する請求項１のシステム。
【請求項８】
電子請求書提示および支払い（ＥＢＰＰ）システムを利用する方法であって、該方法は、ＥＢＰＰユーザー・インタフェース（ＵＩ）をＥＢＰＰホスト計算機から受けること、ＵＩの第１の部分に表示するための金融機関情報を受けること、請求書作成会社の情報および請求データに対する要求を伝えること、ＵＩの第２部分に表示するための請求書作成会社の情報およびＵＩの第３の部分に表示するための一つ以上の請求書を識別する支払請求データを受けること、代金を払われる請求書作成会社の一つ以上の請求書を持つための指示をＥＢＰＰホスト計算機に伝えること、および支払い情報を請求書作成会社または銀行に送り返すことからなり、前記ＵＩは、ＵＩの第１の部分に金融機関の情報を表示するように構成され、ＵＩの第２部分に請求書作成会社の情報を表示するように構成され、そしてＵＩの第３の部分に請求データを表示するように構成されていることを特徴とする電子請求書提示および支払いシステムを利用する方法。
【請求項９】
金融機関情報は、金融機関の識別および製品／サービス促進の情報である請求項８の方法。
【請求項１０】
請求している関係者情報は、製品／サービス・プロモーションの情報、メッセージおよびリンクである請求項８の方法。
【請求項１１】
ＵＩコンテンツは、マクロメディア・フラッシュおよび他のマクロメディア製品ラインを用いて作成される請求項８の方法。
【請求項１２】
金融機関は、金融機関情報のコンテンツを制御し、請求書作成会社は、請求書作成会社のコンテンツの情報を管理する請求項８の方法。
【請求項１３】
金融機関および請求書作成会社は、ユーザーによってあらかじめ選択される請求項８の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子請求書提示および支払いシステムに関し、さらに詳しく言えば、支払人が単一のウェブサイトを介して一つ以上の金融機関の情報および一つ以上の支払い請求会社の情報および支払い請求データをる電子請求書提示および支払いシステムに関する。
【背景技術】
【０００２】
電子請求書提示および支払い（ＥＢＰＰ）が激しい競争市場に戦略的差異化手段として出現した。請求情報へのアクセスを便利にする他に、顧客による電子決済が彼らに文房具および郵送料経費を節約させる。電子環境は、また、電子ワークフロー処理を容易に用いられるようにすることによって事業パートナーが紙の請求書および計算書の処理コストを低減できるようになる。さらに、電子請求書送付が組織間の商品およびサービスに対する支払いの速度および精度を高めることによってキャッシュフローを改善する。さらにまた、電子支払い請求情報およびデータを単一のウェブを介することによって、支払い請求会社および銀行がかれらの顧客との関係を改善し強化できるようになる。
【０００３】
現在、ＥＢＰＰを実現するための主要なモデルが四であるつある、すなわち、支払い請求会社、卓上コンソリデータモデル、シックコンソリデータ（ｔｈｉｃｋ  ｃｏｎｓｏｌｉｄａｔｏｒ）・モデルおよびシンコソリデータ（ｔｈｉｎ  ｃｏｎｓｏｌｉｄａｔｏｒ）・モデルモデルである。支払い請求会社直接モデルは、モデルが単一の支払い請求会社のＥＢＰＰ必要条件をサポートする。この方法は、処理全体の支払い請求会社の支配を多くし、支払い請求会社が消費者のためのウェブ経験をカスタマイズできるようにし、そして、マーケティング・メッセージについて完全な管理を行う。直接モデルの欠点は、ナビゲートするのが容易でなく、消費者が計算書を見て多数の支払い請求会社の勘定を払うための便利な機構を与えないことである。
【０００４】
卓上コンソリデータモデルは、顧客に対する請求書合併および複数の支払い請求会社のための消費者との対話の利点を組み合わせることを目的としている。このモデルは、ウェブ・ブラウザ、電子メールまたは専用のＰＣソフトウェアを介して実現できる。しかし、このモデルを消費者が受け入れるには、クライアントのコンピュータに追加のソフトウェアをインストールする必要があるために限界があった。
【０００５】
シックコンソリデータ・モデルを用いると、消費者が全ての計算書および支払い請求詳細を概要および詳細なフォーマットで受ける。提示は請求書支払い処理によって統合され、消費者関係はコンソリデータ・ウェブサイトで管理される。薄いコンソリデータモデルを用いることにより、消費者が多くの異なる支払い請求会社のための要約計算書および請求情報を受ける。このモデルは、支払いを正当と認めるために、請求支払い処理と統合されることができる。現在の厚いおよび薄いコンソリデータモデルの両方の欠点は、計算書または支払い請求詳細を調べるためには、消費者が発行元の支払い請求会社のウェブサイトへのリンクをクリックしなければならず、どちらも発行元の支払い請求会社のウェブサイトに再び向けられるか、または支払い請求の詳細は、「スクリーン・スクレープ」されて統合者のサイトへ戻されるか、または発行元の支払い請求会社の情報は、統合者のサイトに再掲載するために印刷されたものからスキャンされることである。
【０００６】
従来技術のシステムの限界のないＥＢＰＰシステムに対する要求がある。すなわち、請求書に対する支払いをするためまたは支払い請求明細を統合者サイトへ戻してスクリーン・スクレープするために支払人が支払い請求会社のウェブサイトとリンクする必要がない統合者モデルを支持するＥＢＰＰシステムに対する要求がある（これは、本発明の実施例において以下に開示される）。
【特許文献１】なし
【非特許文献１】なし
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明は、金融機関および支払い請求会社のサーバーから摘出、変換およびローディング（ＥＬＴ）技術を介して取得した情報を集中データベースに統合し、同時に、システムのユーザーがかれらの金融機関および支払い請求会社とユーザーの財源および特定の請求書作成者からのユーザーの購入品に関する情報がそのような金融機関と支払い請求会社との間で共有される必要のないような方法で連絡できる独特のＥＢＰＰシステムを提供することである。
【課題を解決するための手段】
【０００８】
本発明の実施例の一態様は、ユーザーである消費者のデータおよび改良された消費者所望のプライバシーと共に金融機関および支払い請求会社の両方の保護を高める。そのような分離能力は、金融機関および支払い請求会社にそれらの消費者との対話を増やし、それらの消費者との関係に関してより厳しい管理を維持しながらかれらの消費者へアクセスする能力を更に与える。
【０００９】
実施例の他の態様では、本発明のＥＢＰＰは、消費者が消費者への勘定を払うための好ましい金融機関を特定できるようにし、消費者が取引する特定の請求書作成者が両者に単一のウェブサイトにアクセスできるようにする。別の態様においては、本発明のＥＢＰＰシステムは、金融機関および支払い請求会社が所望の請求書支払い取引を完成するために必要なもの以外の目標製品および／又はまたはサービス促進資料を提供できるようにする。金融機関情報、請求書作成者情報およびプレゼンタ情報を１ページに単独提示するルック・アンド・フィールは、情報の金融機関および支払い請求会社の両方のサーバーから摘出、変換およびローディング（ＥＴＬ）技術を介し取得したデータのプロセッサの集中データベースから提示できるようにするフラッシュ（Ｆｌａｓｈ）ＭＸ技術を都合よく用いることによって与えられる。
【００１０】
より詳しくいえば、本発明の実施例は、電子請求書提示および支払い（ＥＢＰＰ）のシステムを含んでいる。本システムは、ＥＢＰＰウェブサイトのためのウェブページを記憶するためのメモリおよびメモリと連絡するプロセッサから成る。プロセッサは、ＥＢＰＰホスト計算機からＥＢＰＰユーザー・インタフェース（ＵＩ）を受けるように作動する。ＵＩは、ＵＩの第１の部分に金融機関情報、第２部分に支払い請求関係者情報、およびＵＩの第３の部分にある支払い請求データ情報を示すように構成されている。プロセッサは、ＵＩの第１の部分に示すための金融機関の情報を受けて、支払い請求関係者情報および支払い請求データに対する要求を伝える。プロセッサは、次に、ＵＩの第２の部分に表示するための支払い請求関係者情報およびＵＩの第３の部分に表示のするための一つ以上の請求書を識別する支払い請求データを受ける。システムは、支払い請求関係者の一つ以上の勘定を払うために命令をＥＢＰＰホスト計算機に伝えて、その後、支払い請求会社に支払い情報を伝える。
【００１１】
本発明のもう一つの実施例は、電子請求書提示および支払い（ＥＢＰＰ）システムを利用する方法を開示する。この方法は、ＥＢＰＰホスト計算機からＥＢＰＰユーザー・インタフェース（ＵＩ）を受けることを含んでいる。ＵＩは、  ＵＩの第１の部分にある金融機関情報、ＵＩの第２部分にある支払い請求関係者情報およびＵＩの第３の部分にある支払い請求データ情報を示すように構成される。このシステムは、ＵＩの第１の部分に表示するための金融機関情報を受けて、支払い請求関係者情報および支払い請求データ情報に対する要求を伝える。このシステムは、ＵＩの第２の部分に表示するための支払い請求関係者情報および第３の部分に表示するための一つ以上の請求書を識別する支払い請求データを受ける。このシステムは、次に、請求関係者の一つ以上の請求書の支払いをするための命令をＥＢＰＰホスト計算機に伝える。この方法は、更に、支払い請求会社または銀行へ支払い情報を伝えることを含む。
【発明の効果】
【００１２】
本発明は、従来のＥＢＰＰシステムに勝る著しい改良点を備えている。ユーザーが取引をする好ましい金融機関と支払い請求会社を指定して、彼らを単一のウェブサイトにアクセスできるようにする。さらに、金融機関がＩＤおよび目標製品／サービスの促進資料を提示できるようにし、支払い請求会社がＩＤおよび目標製品／サービスの促進資料請求データをウェブサイト上に提示できるようにする。
【発明を実施するための最良の形態】
【００１３】
本願明細書において言及され、または図に示された全ての製品、サービスまたは会社商品名は、本発明の好ましい実施例の説明を容易にするためだけに用いられて、彼らのそれぞれのオーナーの所有物であるである。商品名の使用は、本発明のどんなオーナーの支持をも表すつもりはない。
【００１４】
本発明者は、シームレスで、透過的で、総合的で、安全かつ使いやすい電子請求書提示および支払い（ＥＢＰＰ）のための解決法を与えるコンソリデータインタフェース技術を備えるシステムを開発した。開示されたＥＢＰＰシステムを用いる支払人は、彼らが彼らの電子的に示された請求書、伝票および計算書の全てを受けて分析することができる中央記憶場所を有し、支払い請求会社に支払人の好ましい金融機関経て支払いをすることができる。
【００１５】
本システムは、個々の金融機関が消費者に彼らが本システムを利用していることを知られることなく彼らの消費者関係に関する管理を維持できるようにする自分自身のコンソリデータ・アプリケ−ションを秘密に分類できるようにする。さらにまた、本システムは彼らの請求書および支払い処理に関して支払い請求会社にあたかもＥＢＰＰシステムが彼ら自身の命題で動作したかのように同じ制御を提供する。売買処理の両側をしっかり統合すると、本システムによって、支払い請求会社および支払人が望むだけの処理を彼らが管理できる。
【００１６】
ＥＢＰＰシステムは、企業対企業（Ｂ２Ｂ）構成部分および企業対消費者（Ｂ２Ｃ）構成部分を備えるが、本システムの一般的動作は、企業および消費者の両方に共通である。以下に本願明細書において更に詳細に開示されるように、本システムは、ユーザー（用語「支払人」は、用語「ユーザー」と交互に用いられる）が、企業であれ消費者であれ、システムにログオンするとき、自動的に構成される。
【００１７】
図１を参照すると、本発明を実現する例示システム１００の概観が示されている。システム１００は、サーバー１０５を備え、これは、ＥＢＰＰサービスを企業および消費者のシステム・ユーザーに与えるＥＢＰＰホスト計算機のサーバーであってよい。サーバー１０５は、金融機関データ１１２、支払い請求会社データ１１４、支払人データ１１６、ビジネス規則１１８およびＥＢＰＰウェブページ１２０を記憶できる記憶媒体１１０を備えている。サーバー１０５は、ネットワーク１３０（例えばイントラネットまたはインターネット）を経て、他のサーバー１４０〜１５０（一つ以上のサーバーを表している）と通信していてもよい。そのようなサーバー１４０〜１５０は、金融機関および支払い請求会社のものであってもよい。コンピュータシステム１００は、ネットワーク１３０を経てサーバー１０５と通信しているクライアント・コンピュータ１６０〜１７０（一つ以上のクライアント・コンピュータを表している）を更に含んでいる。当業者は、コンピュータおよびシステムが本発明の実施を容易にするために使用できる種々のタイプのコンピュータおよび機器構成を認めるであろう。
【００１８】
図２を参照すると、本発明の例示的な方法の一般的なフローチャート２００が示されている。例示的な方法のステップ２１０では、ユーザーは、本発明に従って構成されたＥＢＰＰウェブサイトにアクセスする（更に詳細には本願明細書において後述する）。一般に、ユーザーによって予め指定された金融機関、支払い請求会社および中央元帳領域の識別情報を含むスクリーンがユーザーに表示される。ステップ２２０では、ユーザーは、支払い請求会社リンクをクリックすることによって支払い請求会社を選択することができ、その時、未払い勘定が支払いのためのユーザーに提示される。ユーザーの観点から、彼が支払い請求会社のウェブサイトに勘定を払うためにアクセスしているように見える。ステップ２３０では、ユーザーは、選択された支払い請求会社との取引を、例えば、払うべき請求書を選択して支払い処理を確認することによって行う。種々の他の機能および属性を以下に本願明細書において更に詳細に述べるように、本発明によって与えることができる。
【００１９】
用語「金融機関」口座が本願明細書において用いられているが、任意の種類の口座が勘定を払うために支払人によって用いられてもよいことは明らかである。
【００２０】
図３を参照すると、本発明のシステムの動作を記載しているフローチャート３００が示されている。本発明をより良く理解するのを容易にするために図５〜１１に示されるスクリーン・ショットを参考にする。
【００２１】
ステップ３０１では、最初に、ユーザーがＥＢＰＰシステム・ウェブサイトのＵＲＬをそれらのウェブ・ブラウザに入れることによってサイトにアクセスすることができる。図５に示された歓迎画面５００のようなスクリーンが表示されて、ユーザーにＥＢＰＰサービスの契約をするように促す。歓迎スクリーン５００は、「契約しますか」ボタン５０２およびシステムにアクセスするためのログオン・ボタン５０４を備えることができる。ユーザーは、また、システムの提供事項のプレビューを得るために「ツァーを行う」５０６を選ぶことができる。歓迎スクリーン５００は、また、報酬「温度計」５０３を備えることができ、これは、一旦ユーザーがシステムにログオンして、ユーザーの口座情報が検索されると、ユーザーがシステムにおける種々の活動（例えば、勘定の支払い）を実行することによって蓄積された報酬の量を指示する。ユーザーの便宜のために、報酬「温度計」は、ユーザーによって調べられるあらゆるスクリーンに入れることができる。一旦ユーザーが「ログオン」ボタンをクリックすると、ユーザーに、図６に示された機密保護ログオン・ボックス５１０が提示される。
【００２２】
本システムは、例えば、ソフトウェア・パスワード要求（ミドルウェア・ゲート）、物理的なファイアウォール、データベース・レベルにおける記憶暗号化、オペレーティングシステム・ゲート（例えばタイムアウト）、ドラゴンおよび第三者ベンダー再調査／テスト（例えばリップ・テク（ＲｉｐＴｅｃｈ））を備えている複式セキュリティ・ゲートを使用できることが特徴である。
【００２３】
ユーザーが以前に契約していなかった場合、彼は「契約しますか」ボタン５０２をクリックしてパスワードを得るための命令に続くだろう。ユーザーはシステムに  ユーザがフルネーム、電子メール・アドレス、ユーザー名および預金口座プロファイル（例えば銀行アカウント名、種類、顧客番号）などのような情報を与える。その後で、ユーザーは、パスワードを識別する電子メールを受けるだろう。一旦ユーザーがパスワードを受けると、次に、ユーザーはログオン・ボタン５０４をクリックして、ユーザーのＩＤおよびパスワードを入れる。ステップ３０２では、システムは、ユーザーのＩＤおよびパスワードを認証する。
【００２４】
ユーザーが彼の金融機関（銀行など）を通して署名すれば、署名情報は銀行サイトに現れる。現実に、ユーザーは、ＥＰＢＢシステムアプリケーションを持ち出す銀行のアイココンをクリックすると，その結果ユーザーに銀行サイトそっくりのものとして完全にブランドをつけたページが現れる。
【００２５】
ステップ３０４では、図７に示されたメイン画面６００のようなメイン画面が表示される。ユーザーによって受けられるメイン画面６００およびそれに続くスクリーンは、システムに記録された特定のユーザーに合わせて調整されていることに注意すべきである。例えば、全てのセッション全体にわたって表示される金融機関および支払い請求会社は、ログオンした特定のユーザーによって以前に識別されたものである。さらにまた、金融機関による製品／サービス提供がユーザーの経済プロファイルに基づいてユーザーに合わせて調整でき、支払い請求会社による製品／サービス提供が全ての支払い請求会社および銀行取引全体のユーザーの従来の購買習慣に基づいてユーザーに合わせて調整できる。
【００２６】
メイン画面６００の上部６０２は、ユーザーの好ましい金融機関の識別証印（例えば、ブランド付き情報、マーケティング促進、リンク、メッセージ）を備えており、左の部分６０４は、スクロール可能な支払い請求会社のアイコンを備え、メイン画面の中央部分６０６は、種々のユーザー機能およびそれに関連し、「口座」６０８、「支払い請求書」６１０、「調査一覧表」６１２および「資金動向」６１４と名付けられたタブ・ボタンによって表題をつけられた情報を備えることができる。メイン画面６００は、また、ユーザーが彼の最後の取引をした時（例えば、１月３０日金曜日）を示し、何件の請求書が今週支払らわれる予定になっているかを識別し、ユーザーが取得したメンバー・ポイント数を表示する。メイン画面６００は、また、ユーザーが取得したメンバー・ポイント数を示す報酬「温度計」６１６を備えている。オンライン・ヘルプ・ボタン６１８は、常に利用できる。図７に示されたタブ・ボタンの各々のものは、ボタンをクリックすることによって対応するボタンのより多くの説明を見られるように拡張できる（総括的に数字６２０で図８に示されているように）。
【００２７】
ハイパー・テキスト・マークアップ言語（ＨＴＭＬ）ページは、ブラウザがサーバーにある新しいデータについて調べる度ごとに全部ロードし直さなければならないので、ウェブの要求および応答モデルが実時間データ更新には本質的に適さないことを当業者は認めるであろう。この固有の欠点を克服するために、本願発明者は、マクロメディア社（サンフランシスコ、ＣＡ）によるフラッシュ（Ｆｌａｓｈ）ＭＸ、インターネット・コンテンツおよび用途開発ツールを使用する。結果として、例えば、フラッシュＭＸおよび他のマクロメディア・プラットフォームについて、図１９に示されたユーザ・インタフェース１１００は、金融機関によって与えられて制御されるスクリーン１１０２（商標付けスキン領域）のウェブ・データの上部に統合され、支払い請求会社によって与えられて制御されるスクリーン１１０４のウェブ・データの左中央部分に統合されているシェル（例えば、クリックアンドペイ。・セントラル（ＣｌｉｃｋａｎｄＰａｙ  Ｃｅｎｔｒａｌ）スクリーン）を備えるように構成できる。ホストプロバイダ情報（例えば、クリックアンドペイ・セントラルの情報）は、デフォルト金融機関（例えばキー・バンク）を強調するために暗くされる。販売シート領域に関する全ての属性（後述する）は、スキン領域に適用できる。中心部または元帳領域は、全ての相互作用が起こるホット・ゾーンを備えている。例えば、ユーザーが処置または作業を遂行すべき場合、彼はボタン、フィールド、プルダウン・メニューおよびホット・ゾーンにおいて利用できるその他の能力を利用できる。
【００２８】
すなわち、スクリーンの各部分は、基本的に金融機関および支払い請求会社のスクリーン部分のスナップショットである。ユーザーには、ＵＩは、情報およびデータ記入点の単一の提示のルック・アンド・フィールを有する。しかし、フラッシュＭＸは、金融機関および支払い請求会社の両方のサーバーから抽出、変換およびロード（ＥＴＬ）技術を介して取得したデータを持つプロセッサの集中データベースからの情報の提示を容易にする。リアルタイムでまたはファイルの移転を介して必要に応じて２台のそれぞれのサーバーからデータを取得することは、それによってユーザーに認められるような取得の中断をかなり減らして、金融機関および支払い請求会社のサーバーによるタイムアウト中断をなくす。追加の利点は、ユーザーのデータのセキュリティの向上およびユーザーのプライバシーの保護の向上である。フラッシュＭＸの著しい強みは、最も多数のミドルウェアソリューション、データベースおよびウェブソリューションのための任意のミドルウェアのデータ・パイプラインと相互作用するそれの能力である。
【００２９】
プリント・ストリーム・ベンダーは、システムに利用できる遺産データを作るためにデータ・パイプラインを創ることを容易にするのに利用できる。ドリームウィーバー（Ｄｒｅａｍｗｅａｖｅｒ）ＭＸ（やはり、マクロメディア社製）をウェブサイトの管理のために使用できる。
【００３０】
ユーザーが払うべき請求書を調べているホット・ゾーンから支払い請求書のアクティブ・スクリーンに直接に行くことができることが容易に分かる（以下に本願明細書において更に詳細に記載される）。スクリーン（「販売シート」ともいう）の左の部分は、支払い請求会社が、例えば、重要な顧客の業務（例えば、アナウンス  サービスまたは料金変更）を処理し、製品／サービスについてのタイムリな情報（例えば、季節売り出し、既存製品／サービスの強化、新規サービス）を与え、特定のマーケティング戦略（およびまさに静的広告でない）に向けられている対話性（例えばクイズ、ゲーム、短いビデオ）を与える。上記の機能は、フラッシュＭＸを利用して可能にされて、標準のＨＴＭＬを用いて達成することができない。販売シートは、ユーザー消費者に支払い請求会社の「直接」サイトとして見えるものに拡張可能である。システムは、また、ユーザーが金融機関から又は消費者が一つのスクリーンから全ての利用可能な金融情報を受けて、それらと相互作用できるようにするこの全「金融ウォレット」によって与えられるその他のサービスから勘定を払うために容易に戻ることができるようにする。
【００３１】
「販売シート」の能力のこのほかの例には、回動広告，プッシュプル広告（例えば、請求書作成機が広告を押しやらなければならない場合、コンテンツを請求書作成機の端に記憶するか、あるいは、コンテンツをＥＳＰＰシステム・プロバイダの端に記憶できる）があり、請求書作成機は、スクロール・フォーマットでの大量の情報を含むスクロール広告（例えばテキスト、ビデオ、アートワーク）を与えることができる。
【００３２】
ステップ３０６では、ユーザーは、彼が彼の一つ以上の口座を調べたいと思っているかどうかについて促される。ユーザーが彼の一つ以上の口座を調べることを望む場合、彼は「口座」ボタン６０８を選択して、それによってステップ３０８へ進むことができる。ステップ３０８では、ユーザーは、各口座のプロファイルを調べることができる。ユーザーがステップ３０８で彼の口座をチェックした後で、ユーザーはステップ３１０へ進む。ステップ３０６でユーザーが彼の口座を調べることを望まない場合、ユーザーは、直接ステップ３１０へ進むことができる。
【００３３】
ステップ３１０では、ユーザーは、彼が彼の一つ以上の計算書を調べたいかどうかについて促される。ユーザーが彼の一つ以上の計算書を調べることを望めば、彼は、「計算書を調べる」ボタン６１２を選択して、それによってステップ３１２へ進む。ステップ３１２では、計算書スクリーン７００および７５０（それぞれ、図９および１０に示されている）のような計算書スクリーンが表示される。計算書スクリーン７００は、名前およびユーザーの口座番号を種々のプロバイダとともに含むことができる。プロバイダは、銀行、証券会社、旅行会社（例えば航空会社、ホテル、レンタカー会社）、その他を含むことができる。「銀行」７０２、「証券会社」７０４、「旅行／報酬」７０６、「クレジットカード」７０８または「請求書」７１０の計算書に別々にアクセスするためのボタンを設けることができる。計算書スクリーン７００では、「旅行／報酬」ボタン７０６は、全てのそのような旅行／報酬が示されるようにクリックされたものである。「銀行」の計算書検分７６０の例が図１１に示されており、図１２の画面７７０は、「証券会社」の計算書を示している。
【００３４】
プロバイダの名前またはアイコンをクリックすることによって、ユーザーは、その特定のプロバイダのための計算書を開くことができる。一旦ユーザーがプロバイダを選択すると、そのプロバイダからのユーザーの計算書を示して、ユーザーがいくつかの取引を実行できるスクリーン（図示せず）が表示される。例えば、ユーザーの銀行預金収支報告を示しているディスプレイのスクリーンにおいて、ユーザーは、資金を移転することができ、ユーザーの航空旅行報酬計算書を示しているディスプレイのスクリーンにおいて、ユーザーは、航空旅行報賞を航空券に適用でき、ユーザーの証券会社計算書を示しているディスプレイのスクリーンにおいて、ユーザーは、証券会社預金口座から特定の株への投資に資金を移転することができる。ユーザーがステップ３１２で彼の計算書を検分した後で、ユーザーはステップ３１４へ進む。ステップ３１０において、ユーザーが彼の計算書を検分することを望まない場合、ユーザーはステップ３１４へ直接に進むことができる。
【００３５】
ステップ３１４では、ユーザーは、彼が一つの口座からもう一つの口座へ資金を移転することを望むかどうかについて促される。ユーザーが資金を移転することを望む場合、彼は、「資金移転」ボタン６１４を選択して、それによってステップ３１６へ進むことができる。ステップ３１６では、例えば、図１３に示された資金移転スクリーン８００のような資金移転スクリーンが表示される。資金移転スクリーン８００がユーザーに彼の種々の口座の残高を確認して、資金をそのような口座の間で移転することができるようにする。ユーザーがステップ３１６で資金を移転した後に、ユーザーはステップ３１８へ進む。ステップ３１４で、ユーザーが資金移転を要求しない場合、ユーザーは、ステップ３１８へ進む。
【００３６】
ステップ３１８では、ユーザーは、彼が請求書を調べて払うことを望むかどうかについて促される。ユーザーが請求書を調べて払うことを望む場合、彼は「請求書支払い」ボタン６１０を選択して、それによって図４に示された流れ図４００のステップ４０２へ進むことができる。ステップ４０２では、図１４に示されたデフォルト画面９００のようなデフォルト画面が表示される。一般に  請求書を払うとき取るべき三つのステップがある。第１に、ユーザーは、支払われるべき支払い請求会社を選択する。第２に、ユーザーは、支払われるべき請求書を選択する。そして第３に、ユーザーは、選択された請求書を払う。本システムは、ユーザーが様々な方法で三つの一般的なステップを実行して、それによってユーザーに非常に大きな融通性を与える。
【００３７】
より詳しくは、例えば、ユーザーが請求書の計算書を調べて、支払いのための一つ以上の関連の請求書を選択してもよく、ユーザーが払われる請求書の状況を調べて支払いのための一つ以上の請求書を選択してもよく、ユーザーがをスクロール・アイコンから選択して、スクリーンの左部分にある支払い請求会社の販売シートを引き上げ、その後で、一つ以上の請求書をスクリーンの中心部（元帳領域）から選択してもよい。または、ユーザーが販売シートを開いて、全「支払い請求会社直接」アプリケーションを表にだすように選択して、消費者に提供されている支払い請求会社の種々の製品およびサービスの内の一つ以上を前記一つのスクリーンから選択できる。請求書支払い処理を始めるために用いられる方法に関係なく、請求書の販売シートは、スクリーンの左の部分に止まって、ユーザーによるワンクリックで全スクリーン・アプリケーションまで開くであろうことに注目すべきである。種々の請求書支払い開始方法に関する更に詳細が本願明細書に記載され、添付の図面に示されている。本発明の重要な面は、請求書支払いのために用いられるスクリーンの数が最小限あることである。従来の請求書支払いシステムは、請求書の支払いをするために最低５枚のスクリーンを用いることをユーザーに要求するが、本発明は、基本的に請求書の支払いのためには単一のスクリーンしか必要としない。本システムによる単一スクリーン支払いに対する例外は、ユーザーの口座に十分な資金がないときである。従って、これは、本願明細書において開示されたＥＢＰＰシステムを従来技術システムより相当に効率的で、ユーザーフレンドリーなものにしている。
【００３８】
デフォルト画面９００は、図１４に示されているような「全ての新しい未払い請求書」を直ちに表示することができ、そこにおいて、「新しい請求書」は、最後にユーザーがログオンしたとき以来、調べるために利用できるようになった請求書であり、「未払い請求書」はユーザーがすでに調べたが、まだ未払いの請求書である。デフォルト画面９００は、また、「新請求書」ボタン９０２、「スケジュール」ボタン９０４、「未払い」請求書ボタン９０６、「履歴」ボタン９０８および「支払い請求会社リスト」ボタン９１０（同じ図に示されている）を表示することができる。図１５は、全ての未払い請求書９１２を示す、もしあれば。「請求書支払い」の下に、請求書は、また示されることができる  支払済み請求書９１４、支払うべき請求書９１６および予定表９１８の現状をもまた図１６に示すように示すことができる。「新しい請求書」ボタン９０２をクリックすることによって、中央パネルは、全ての新しい請求書だけを示すことができる。「スケジュール」ボタン９０４をクリックすることによって、中央パネルは、支払いを予定されている全ての請求書を示すことができる。図１７は、ユーザーが「スケジュール」ボタン９０４をクリックしたあとに表示される例示的なスクリーン１０００を示している。「未払い」請求書ボタン９０６をクリックすることによって、中央パネルは、全ての未払い請求書だけを示すことができる。未払い請求書を払うための特定の口座にある資金が不十分な場合、エラー・ウインドウ１０１０が図１８に示すように現れる。適当な移転１０２０が請求書を払うために一つの口座からもう一つの口座（利用できる場合）へ行われてもよい。さもなければ、取引は、ボタン１０３０をクリックすることによってキャンセルすることができる（同じ図に示すように）。図１４にある「履歴」ボタン９０８をクリックすることによって、中央パネルは、支払済みの全ての過去の請求書を表示することができる。都合の良いことに、過去の請求書は、しばらくの間（例えば１年）システム内に保持されて、ユーザーがそのような機関にわたる請求書を比較できるようにする。「支払い請求会社リスト」ボタン９１０をクリックすることによって、下方パネルは、全ての支払い請求会社および彼らのデータを表示することができる。支払い請求会社を加えるため、支払い請求会社を削除するため、支払い請求会社情報を編集するためのオプションを設けることができる。デフォルト画面は、これに対して図１６に示すようなもので、そこでは、元帳のホット・ゾーンは、３つの領域（すなわち「支払済み」請求書、「支払請求書」および「予定表を作られた」請求書）に仕切られている。
【００３９】
ステップ４０４では、ユーザーは、支払われるべき支払い請求会社を選択する。上記のように、ユーザーが支払い請求会社を選択し、その後で支払われるべき請求書を選択する様々な方法がある。ユーザーが左側パネルにある支払い請求会社のアイコンを直接クリックしてもよい。スクロールバーをスクリーンの左の部分内に現れない支払い請求会社のアイコンにアクセスするためにもうけてもよい。ユーザーが支払い請求会社のアイコンをクリックすれば、スクリーンの左の部分は、選択された支払い請求会社のロゴ、マーケティング・メッセージ、リンク、メッセージおよびログオン・メッセージを表示する。図１９は、ユーザーがスクリーン９００の左側パネルにあるＡＴ＆Ｔのアイコンをクリックしたあとに表示される例示的なスクリーン１１００を示している。ユーザーは  彼がＡＴ＆Ｔのサーバーに直接連結されることを認めるが、ユーザーは実際にはＥＢＰＰシステムと連結し続けて、ＡＴ＆ＴのサーバーとＥＢＰＰシステムを通して通信していることが特徴である。
【００４０】
ユーザーは、次に、図１９に示された例示的なスクリーン１１００を表示できる。スクリーン１１００は、スクリーンの左の部分にあるＡＴ＆Ｔのロゴおよびマーケティング・メッセージおよびスクリーンの中心部にある未払いのＡＴ＆Ｔの請求書だけを備えている。都合のよいことに、そのようなロゴおよびマーケティング・メッセージ（例えば製品／サービス・プロモーションのメッセージ）は、支払い請求会社によって更新できる。支払い請求データは、実際の請求書に与えられたデータの概要であって、それによって請求書を払うために不可欠な情報だけが示されるので、ユーザーのための請求額支払い処理を著しく簡単にする。「新規請求書」ボタン１１０６、「予定」ボタン１１０８、「未払い請求書」ボタン１１１０、および「履歴」ボタン１１１２は、今や、新規請求書、予定、未払い請求書（図示の）およびＡＴ＆Ｔ支払い請求データのための履歴だけを示すために用いられることは留意すべきである。
【００４１】
ステップ４０８では、ユーザーは、請求書を選択する。上記の如く、ユーザーが支払い請求会社および支払われるべき請求書を選択できる方法が多数ある。スクリーン１１００は、ユーザーが一つ以上の請求書１１１４を支払うために直接選択できるようにする。例示的なスクリーンでは、ユーザーは、３００ドルのＡＴ＆Ｔの請求書だけを支払うように選択した。一旦一つ以上の請求書が選択されると、ユーザーは、以前デフォルト口座として確定された口座から払われた請求書を有することができるか、又はまたは、プルダウン・スクリーン１１１６を用いることによって、資金が選択された請求書の支払いをするために引き出されるべき特定の口座を選択する。例示的なスクリーン１１００において、「キーチェック」口座が選択された請求書の支払いをするために用いられるであろうデフォルト口座である。一旦ユーザーが払われるべき一つ以上の請求書を識別すると、システムは金融機関に一つ以上の請求書を払うように命じる。その後で、金融機関は、一つ以上の取引を実行する。都合のよいことに、開示されたＥＢＰＰシステムは、競争的システムが従わなければならない種々のオンライン・バンキング規則に従う必要をなくしている。
【００４２】
上記のように、払われるべき請求書は、代替の方法で支払うように選択できる。例えば、画面９００を参照すると、ユーザーが新規または未払い請求書として挙げられた請求書を直接クリックできる。さらなる例として、ユーザーが支払いの予定を立てられた請求書として挙げられた請求書を直接クリックできる。両方の例において、スクリーンの左の部分は、選択された支払い請求会社のロゴ、マーケティング・メッセージ、リンクおよびメッセージを表示できる。そのような点では、ユーザーは、請求書の支払いをするためにステップ４０６および引き続くステップに関して上述したように進む。
【００４３】
ステップ４１２では、一旦一つ以上の請求書が支払いのために選択されてしまえば、ユーザーは「支払い請求書」ボタン１１１８を選択できる。別の口座がユーザーによって選択されなかった場合、一つ以上の請求書はデフォルト口座から払われることになる。ステップ４１４では、不十分な資金が引き出されるべき口座に、資金が十分にない場合、ステップ４１６において、ユーザーは十分な資金のない口座に資金を移転するための代わりの口座を用意することを促される。プロンプトは、図１８に示すようなものであってよく、エラー（すなわち不十分な資金）があることを指摘して、次に進む前に資金の移転を完了するようにユーザーを促す。ステップ４１８では、ユーザーは、代わりの口座を与えることによってプロンプトに従うか、または資金が十分にない口座に資金を送る。その後で、ユーザーは、ステップ４１２へ進んで上記の通りに進む。ユーザーが代わりの口座の用意または資金の移転を望まないと決める場合、ユーザーはステップ３２０へ進んでログオフすることができる。もちろん、本システムの他の点おけるように、ユーザーが取ることができるように、例えばメイン・メニューに戻って他の請求書の支払いを試みるなどの他の動作をしてもよい。すなわち、本願明細書に書かれているステップは、本発明のまさに一実施例であって、システムの融通性を制限するつもりはない。
【００４４】
ステップ４１４で、資金が引き落とされるべきユーザーの口座に十分な資金があると分かった場合、システムはステップ４２０へ進むだろう。ステップ４２０において、ユーザーは、例えば、メイン・メニュー９００に戻って、「支払済み？」カラムが丁度今支払ったばかりの請求書に対応する線に「はい」のあることを確認するためにそのカラムをチェックすることによって支払済請求書の状況の変化をチェックすることができる。代りのスクリーン６００で「支払済（過去３０日）」ボックスをチェックすることによってユーザーが支払いの状況をチェックすることができる。
【００４５】
一つの承認されたものとして、ＥＢＰＰプロバイダは、金融機関に請求書の支払をするように指示することを認可されている。ユーザーから請求書の支払をする指令を受けると即座に、プロバイダは、支払いのための適当な金融機関とともに請求書を記帳する。その銀行は、いかなる数の標準化された方法（例えばＡＣＨ、参加している銀行間の相互協力協定を介して）でも請求書に対する支払をすることができる。
【００４６】
上記のように、ＥＢＰＰシステムは、ユーザーがログオンしたとき自動的にユーザーを認識する。従って、例えば、ユーザーが企業に対してログオンする場合、システムはそれに応じて構成される。ユーザーが企業または消費者であるかどうかに関係なく、機能の多くが全てのユーザーに与えられる。例えば、本システムは、支払い請紛争係争を調整するのに有用な紛争解決機能を与えることができる。そのような機能を利用して、あるユーザーが紛争を指摘する書式を与えられて、その書式を支払い請求会社に自動的に伝えることができる。
【００４７】
本システムは、自動係争解決方法論を利用する。ユーザーへ電子伝票の提示をすると、システムは、特定の支払い請求会社の伝票明細をユーザーの受取書および購入注文書と自動的に比較することができる。これによって、システムは、支払い請求会社が請求したものと支払人が注文および／または受領したものの間の全ての違いを自動的に決めて、それらの相違点を支払い請求会社に知らせるターンアラウンド文書を作ることができるようにする。例えば、支払い請求会社が１ユニットにつき２．００ドルの品物の１０ユニット分の請求書を送ったと仮定する。しかし、支払人の適用できる受取書と購入注文書は、支払人が１単位につき１．７５ドル支払うつもりで、９単位だけが受け取られたことを示している。システムは、価格と量の両方の差を自動的に決めて、伝票商品項目期日受渡し高を調節し、そして支払い請求会社がかれらの記録を支払人のものと一致させるように要求した情報を支払い請求会社に送る。さらなる例として、ユーザーが商品を１００個買うと彼が購買合意による１０％の値引きを受けたはずだった場合、システムは請求書を自動的に評価して値引きが不注意に含まれていなければ、請求書にフラグを付ける。本システムは、また、請求エラーがランダムかどうか、または支払い請求会社が故意に誤った請求をしているかどうかを決めるために分析されることができるこれらの取引の履歴ファイルを構築する。
【００４８】
本システムは、インチュート（Ｉｎｔｕｉｔ）社（マウンテンビュー、ＣＡ）によってターボ・タックス（ＴｕｒｂｏＴａｘ）のような税プログラムまたは第三者の税アドバイザーに請求／支払い情報を直接ＥＢＰＰシステムからインポートするインポート機能を与えることができる。
【００４９】
システムは、ＨＮＣソフトウェア（Ｓｏｆｔｗａｒｅ）社（サンディエゴ、ＣＡ）のイー・ファルコン（ｅＦａｌｃｏｎ）によって与えられるもののような不正検出機能および優れたリアルタイム支払い不正検出サービスを与えることができる。
【００５０】
ユーザーは、企業によって購入されたものの種類を調べて、企業が破産に向かって進んでいるかどうかを決めることができる。例えば、現金不足の会社は「回転の遅い製品」より「回転の速い製品」を多く購入する傾向がある。
【００５１】
本システムは、支払い請求会社または支払人の請求書／計算書／伝票／購入注文／受取り作成ソフトウェアを読み込むことができる人工知能ベース転換ソフトウェアを使用して支払い請求会社または支払人によって開発された印刷文書の構造を決めるビジネス規則を抽出する。支払い請求会社または支払人のデータは、抽出されたビジネス規則と無関係に標準化データベースに記憶される。ビジネス規則は、補助データベースに記憶される。この手順によって、システムが全てのユーザーのために同じデータベース構造を用いることができるようになる。それは、また、新しいユーザーに切り替えるに必要な時間とコストを著しく減らす。
【００５２】
必要に応じて、本システムは印刷又は電子提示のために、支払い請求会社／支払人の出力を複製できる。利点は、データに影響を及ぼすことなく簡単にビジネス規則を変える能力にある。以前に記憶されたデータに対してルールの変更を試験しなおして、異なる出力を互いに比較することによってルールの変化の影響を決定することも、また、可能である。また、均一なデータベースを使うことによって、本システムがその全データベース（全てのユーザーの中および間にある）全体にわたって改良データマイニング技術を使用できるようにする。
【００５３】
本システム・データベース内に記憶された支払い請求会社および支払人のデータの性質は、システムの請求書および伝票の提示および決済処理の結果として、支払い請求会社および支払人の両方に無数の分析的なサービスを可能にする。必要な解析の種類によって、支払い請求会社または支払人がいつか後で、インターネットを通じて届けられる報告をバッチ方式で行われるかまたはユーザーがまだオンラインで利用できるシステム要求と報告に支払い請求会社または支払人に入るいくつかの必要なデータをシステムの要求時にユーザーがまだオンラインである間に作成されて利用できる報告を会話的に行う種々の分析を要求できることに留意する必要がある。
【００５４】
システムは、表示信頼レベル以内で、どれだけの支払い請求会社の売掛金が規定対象期間にわたって集められる見込みがないかを決定できる。例えば、危険保険価格（ＶＡＲ）分析を完了したあと、以下のものに類似した計算書が作られる。我々は、売掛金ポートフォリオ収集パーセントが次の６ヵ月にわたって８２．７８％未満にならないと９５％確信している。２５００万ドルのポートフォリオ値に基づくと、ＶＡＲ＝（１００％−８２．７８％）ｘ２５，０００，０００ドル＝４，３０５，０００ドル）である。
【００５５】
本システムは、また、購買パターン分析を実行することができる。支払い請求会社がいくつかの在庫品の種別情報を与えれば、システムは、支払人（購入者）が彼らの購買パターンを著しく変えたかどうかを決めることができる。赤いフラグを立てられる変化は、動きの早い商品を得るだけに製品ライン全体にわたって購入するのを中止するためであろう。この性質の購入変化（一つの口座内で）
は、支払人がキャッシュフロー問題を持っていることを意味する可能性がある。特に、彼らがそのような購買パターンの変化を行った唯一の顧客である場合。さらに、購入パターン分析は、支払い請求会社に何らかのオンライン宣伝商品又は特価品を支払人に提供するための注文に関する案内を与えて、支払人が受け入れる、すなわち、促進をクリックする確率が最大になるようにする。
【００５６】
本システムは、また、顧客の支払い追跡分析を行うことができる。本システムは、彼らの顧客の時間の経過に伴う支払いの比較分析を与えて、それによって支払い請求会社がどんな特定の顧客とでも商売をする危険が将来いつかその顧客に関する信用問題が生ずる可能性を示すレートで変りつつあるかどうかを決めるのを助ける。
【００５７】
本システムは、また、クレジット部門の運営を評価することができる。データベースには、請求と支払いの両方のデータが入っている。従って、システムは、所定の伝票の最大ＤＣＦ対伝票の実現されたＤＣＦを決めるために現金割引法（ＤＣＦ）分析を利用することができる。各口座のセールスマンまたは責任のある信用アナリストに関する情報が与えられている場合、クレジット部門または販売部門の各個人を金の時間的価値を考慮に入れないＤＳＱまたは総売上高と比較して公平な方法を用いて彼らの業績に関してランク付けすることが可能である。
【００５８】
システムは、キャッシュフローの予測を行うことができる。データベース（所定の支払い請求会社のための）には、何か月もの請求書作成および顧客による支払い活動が入っている。本システムは、それの支払い請求会社のためにこのデータを分析して、過去の成績の統計的分析と指定された期間にわたる支払い請求会社の販売予測に基づく規定の計画対象期間の間のキャッシュフロー予側を行う。
【００５９】
システムは、不正検出を行うことができる。支払人の購買パターンを分析することの別の副産物は、不正検出である。特定の支払い請求会社との支払人の通常の購買パターンから著しい変動がある場合、システムは、支払人が注文しなかったか又は受取らなかった品目があるかもしれないことを支払人に警告する。
これは、システムとそれのベンダーをビジネス伝票電子提示システムを用いるように変える契約を結ばなかった支払人のためにある。
【００６０】
システムは、現金必要量分析を行うことができる。システムは、支払人の未払い請求書ファイルとそれの顕著な購入注文ファイルを分析し、支払人の過去の実績の分析に基づいて形成する指定された計画対象期間にわたって毎月の現金必要量の分析を高める。
【００６１】
上述の詳細な説明から、本発明が従来のＥＢＰＰシステムに勝る著しい改良品であることが当業者には容易に明らかなはずである。ユーザーが取引をする好ましい金融機関と支払い請求会社を指定して、彼らを単一のウェブサイトにアクセスできるようにすることができるＥＢＰＰシステム及び方法が開示されている。さらに、金融機関がＩＤおよび目標製品／サービスの促進資料を提示できるようにし、支払い請求会社がＩＤおよび目標製品／サービスの促進資料請求データをウェブサイト上に提示できるようにするシステム及び方法が開示されている。さらにまた、開示されたシステムと方法は、ユーザーの情報に対する安全とプライバシーを著しく高める。
【００６２】
本発明をいくつかの実施例と例に関して詳述したが、本発明の範囲内にある変形物と変更が存在する。
【産業上の利用可能性】
【００６３】
本発明は、電子請求提示および支払い（ＥＢＰＰ）システムおよび企業対消費者および企業対企業の取引の両方において利用可能性大である。
【図面の簡単な説明】
【００６４】
【図１】本発明を実現する例示システムの概観である．
【図２】本発明の例示的な方法の一般のフローチャートである。
【図３】本発明の例示的な方法の詳細なフローチャートである。
【図４】本発明の例示的な方法の図３から伸びている詳細なフローチャートである。
【図５】本発明のシステムにログオンする前ユーザーによって見られるスクリーンの例示的なスクリーン・ショットである。
【図６】本発明のシステムにログオンする前ユーザーによって見られるスクリーンのもう一つの例示的なスクリーン・ショットである。
【図７】本発明のシステムにログオンする前ユーザーによって見られるスクリーンの例示的なスクリーン・ショットである。
【図８】ユーザーによってロギングの後でシステム上へ調べられる起動画面のもう一つの例示的なスクリーン・ショットである；
【図９】「計算書調査」スクリーンの第１の例示的なスクリーン・ショットである。
【図１０】「計算書調査」スクリーンの第２の例示的なスクリーン・ショットである。
【図１１】「計算書調査」スクリーンの第３の例示的なスクリーン・ショットである。
【図１２】「計算書調査」スクリーンの第４の例示的なスクリーン・ショットである。
【図１３】「資金移転」スクリーンの例示的なスクリーン・ショットである
【図１４】ユーザーが全ての支払済請求書、未払い請求書および予定を調べることができる「請求書支払い」スクリーンの第１の例示的なスクリーン・ショットである。
【図１５】ユーザーが全ての支払済請求書、未払い請求書および予定を調べることができる「請求書支払い」スクリーンの第２の例示的なスクリーン・ショットである。
【図１６】ユーザーが全ての支払済請求書、未払い請求書および予定を調べることができる「請求書支払い」スクリーンの第３の例示的なスクリーン・ショットである。
【図１７】ユーザーが不十分な資金があると決められた口座に資金を振り込むことができる「請求書支払い」スクリーンの例示的なスクリーン・ショットである。
【図１８】ユーザーが不十分な資金があると決められた口座に資金を振り込むことができる「請求書支払い」スクリーンのもう一つの例示的なスクリーン・ショットである。
【図１９】ユーザーが特定の請求書作成会社のウェブサイトから情報と請求データにアクセスする「請求書支払い」スクリーンの例示的なスクリーン・ショットである。図において、「Ａ／４」および「Ｂ／３」などの参照符号は、読者に別の図面の頁に続く図を参照させるために用いられている。この参照符号は、２つの部分を備えている。  アルハベットの部分と数字の部分からなり、数字の部分は行くべき図またはどの図から来たかを示し、アルハベットは行き先または元の場所を示す。例を挙げると、図３の「Ａ／４」は、付随する矢印とあわせて、図４の「Ａ」に行くことを表し、「Ｂ／４」は図４の「Ｂ」から来たことを示す。
【符号の説明】
【００６５】
１０５              サーバー
１４０〜１５０      サーバー
１６０〜１７０      クライアント・コンピュータ
【図１】
2007524887.tif 000003
【図２】
2007524887.tif 000004
【図３】
2007524887.tif 000005
【図４】
2007524887.tif 000006
2007524887.tif 000007
2007524887.tif 000008
2007524887.tif 000009
2007524887.tif 000010
2007524887.tif 000011
2007524887.tif 000012
2007524887.tif 000013
2007524887.tif 000014
【図８】
2007524887.tif 000015
2007524887.tif 000016
2007524887.tif 000017
2007524887.tif 000018
2007524887.tif 000019
2007524887.tif 000020
【図１１】
2007524887.tif 000021