JP2006107272A - 請求支払い支援システム、前記システムに使用または利用される請求側端末、前記システムに使用または利用される支払側端末、および、請求支払い支援のためのコンピュータプログラム - Google Patents

Abstract

【課題】 請求書の管理処理を効率的に実現すること。
【解決手段】 請求側端末１が、入力された請求書の内容に基づき請求書データを発行し、請求書データに請求書特定情報を付して請求書管理サーバ８に送信し、支払側端末２が、請求書管理サーバ８から、請求書データおよび請求書特定情報を受信し、受信した請求書データに基づいて銀行サーバ９に支払処理を実行し、銀行サーバ９に請求書特定情報を通知し、請求側端末１が、銀行サーバ９から請求書特定情報の通知を受信し、受信した請求書特定情報と、発行時の請求書特定情報とを照合し、合致した場合に、請求書ＤＢに登録された請求書特定情報に関連する請求書データを消去または支払い済を表す状態に変える処理を行うこと、を特徴とする。
【選択図】 図１

Description

本発明は、請求支払い支援システム、前記システムに使用または利用される請求側端末、前記システムに使用または利用される支払側端末、および、請求支払い支援のためのコンピュータプログラムに関する。

代金の決済を行う際には、請求側端末から支払側端末へ、請求書が発行される。なお、請求書は、正確には、コンピュータが処理可能な電子データであり、以下請求書データを単に請求書と省略する。そして、この請求書に関する請求及び支払いを効率よく行う技術が、提案されている（特許文献１など）。特許文献１には、「顧客から支払われた代金の入金の確認を効率良く行うことができる入金確認システム等を提供する。」と記載されている。これにより、銀行の決済処理と、請求書の管理処理とを連動させることで、入力ミスなどの人為的なミスを軽減することができる。
特開２００１−２５００７４号公報（段落［０００４］）

しかしながら、従来の技術においては、請求側端末から支払側端末へ、請求書が直接やりとりされていたため、非効率であった。例えば、端末が機械の故障などで保持しているデータにアクセスができなくなってしまったときには、請求書が紛失してしまい、請求書の管理処理が困難となってしまう。また、請求側端末と支払側端末とが直接通信する場合に、どちらかの端末が電源未投入などによりダウンしていた場合には、通信が困難となってしまうため、時間をおいて、再度接続する手間がかかってしまう。このように、従来の技術においては、請求及び支払い処理に関して、効率よく行う環境を提供していなかった。

そこで、本発明は、請求書の管理処理を効率的に実現することを主な目的とする。

前記課題を解決するため、本発明は、請求書データの発行を行う請求側端末と、前記請求書データに対する支払いを行う支払側端末と、前記請求書データを管理する請求書管理サーバと、前記請求書データをもとに入出金業務を支払側端末と実行する銀行サーバと、を含めて構成される請求支払い支援システムであって、前記請求側端末が、入力された請求書の内容に基づき請求書データを発行し、その請求書データを特定する請求書特定情報と関連づけて請求書ＤＢに登録し、前記請求書データに請求書特定情報を付して請求書管理サーバに送信し、前記請求書管理サーバが、前記送信された前記請求書データおよび前記請求書特定情報とを関連づけて記憶手段に記憶し、前記支払側端末が、前記請求書管理サーバから、前記請求書データおよび前記請求書特定情報を受信し、前記受信した前記請求書データに基づいて前記銀行サーバに支払処理を実行し、前記銀行サーバに前記請求書特定情報を通知し、前記請求側端末が、前記銀行サーバから前記請求書特定情報の通知を受信し、前記受信した前記請求書特定情報と、前記請求書ＤＢに登録された請求書特定情報とを照合し、合致した場合に、前記請求書ＤＢに登録された請求書特定情報に関連する前記請求書データを消去または支払い済を表す状態に変える処理を行うこと、を特徴とする。

これにより、請求書データは請求書管理サーバを介してやりとりされるので、請求書の管理処理を効率的に実現することができる。

本発明は、前記請求書管理サーバが、前記請求側端末が消去または支払い済を表す状態に変える処理を行った前記請求書データについて、前記請求側端末から通知を受けて、前記記憶手段から消去または支払い済を表す状態に変える処理を行うことを特徴とする。

これにより、請求書管理サーバは、自装置で管理する請求書データを、請求側端末の管理する請求書データの状態と同じにすることで、消去または支払い済を表す状態に変える処理が済んだ無駄な請求書データを格納する記憶領域を節約することができる。

本発明は、前記請求書特定情報が、請求側端末、支払側端末、ならびに、請求側端末および支払側端末の組ごとに異なるＩＤにより構成されること、を特徴とする。

これにより、請求側端末および支払側端末の組ごとに異なるＩＤを端末ごとに独立して決めればよいので、端末数の増加にかかわらず、請求側端末および支払側端末の組ごとに異なるＩＤの割り当て領域が枯渇するような心配をせずに済む。

本発明は、前記支払側端末が、前記銀行サーバに前記請求書特定情報を通知するときに、前記支払処理によって支払った金額を付して通知し、前記請求側端末が、前記銀行サーバから前記請求書特定情報の通知を受信するときに、前記支払った金額も併せて受信し、前記請求書ＤＢに登録された請求書特定情報に関連する前記請求書データの請求金額に、前記支払った金額が達した場合に、前記前記請求書データを消去または支払い済を表す状態に変える処理を行うこと、を特徴とする。

これにより、請求金額に対して一括で支払う方式に加え、分割で支払う方式にも対応ができる。

本発明は、前記銀行サーバが、複数の計算機が互いにネットワークで接続されて構成され、前記支払側端末が前記支払処理を行う第１の計算機と、前記請求側端末が前記請求書特定情報の通知を受信する第２の計算機とが異なるときには、前記請求書特定情報および前記支払った金額に関する情報が、前記第１の計算機から前記第２の計算機へ通知されることを特徴とする。

これにより、請求者と支払者が同じ銀行の口座を持つ必要がなくなり、利便性が向上する。

本発明は、前記請求支払い支援システムに利用されるまたは使用される前記請求側端末であって、前記請求書データを前記請求書特定情報と関連づけて格納する請求書ＤＢと、前記請求書ＤＢにアクセスする請求書登録部と、前記銀行サーバから受信した前記請求書特定情報と、前記請求書ＤＢの前記請求書特定情報とを照合し、合致した前記請求書ＤＢのレコードを消去または支払い済を表す状態に変える処理を行う請求書消込部と、を備えることを特徴とする。

これにより、請求書データは請求書管理サーバを介してやりとりされるので、請求書の管理処理を効率的に実現することができる。

本発明は、前記請求支払い支援システムに利用されるまたは使用される前記支払側端末であって、前記請求書データと前記請求書特定情報とを前記請求書管理サーバから受信し、前記請求書データに従って、前記前記銀行サーバに支払処理を実行する請求書支払部と、前記支払処理が実行された前記請求書データについて、関連する前記請求書特定情報を前記銀行サーバに通知する通信部と、を備えることを特徴とする。

これにより、請求書データは請求書管理サーバを介してやりとりされるので、請求書の管理処理を効率的に実現することができる。

本発明は、請求書データの発行を行う請求側端末と、前記請求書データに対する支払いを行う支払側端末と、前記請求書データを管理する請求書管理サーバと、前記請求書データをもとに入出金業務を支払側端末と実行する銀行サーバと、を含めて構成される請求支払い支援システムに使用される請求支払い支援のためのコンピュータプログラムであって、前記コンピュータプログラムが、前記請求支払い支援システムの各装置に読み取られて実行されることで、前記請求側端末に、入力された請求書の内容に基づき請求書データを発行する手順と、その請求書データを特定する請求書特定情報と関連づけて請求書ＤＢに登録する手順と、前記請求書データに請求書特定情報を付して請求書管理サーバに送信する手順と、前記請求書管理サーバに、前記送信された前記請求書データおよび前記請求書特定情報とを関連づけて記憶手段に記憶する手順と、前記支払側端末に、前記請求書管理サーバから、前記請求書データおよび前記請求書特定情報を受信する手順と、前記受信した前記請求書データに基づいて前記銀行サーバに支払処理を実行する手順と、前記銀行サーバに前記請求書特定情報を通知する手順と、前記請求側端末に、前記銀行サーバから前記請求書特定情報の通知を受信する手順と、前記受信した前記請求書特定情報と、前記請求書ＤＢに登録された請求書特定情報とを照合する手順と、合致した場合に、前記請求書ＤＢに登録された請求書特定情報に関連する前記請求書データを消去または支払い済を表す状態に変える処理を行う手順と、を実行させることを特徴とする。

これにより、請求書データは請求書管理サーバを介してやりとりされるので、請求書の管理処理を効率的に実現することができる。

本発明は、請求書データの発行を行う請求側端末と、前記請求書データを管理する請求書管理サーバと、前記請求書データをもとに入出金業務を実行する銀行サーバと、を含めて構成される請求支払い支援システムであって、前記請求側端末は、入力された請求書の内容に基づき請求書データを発行し、その請求書データを特定する請求書特定情報と関連づけて請求書ＤＢに登録し、前記請求書データに請求書特定情報を付して請求書管理サーバに送信し、前記請求書管理サーバは、前記送信された前記請求書データおよび前記請求書特定情報とを関連づけて記憶手段に記憶し、前記請求書データおよび前記請求書特定情報を前記請求書データに対する支払いを行うコンピュータに送信し、前記銀行サーバは、前記支払いを行うコンピュータに対して前記請求書データに基づいて支払処理を実行し、前記支払いを行うコンピュータから前記実行した支払処理に関する前記請求書特定情報を受信し、前記請求側端末は、前記銀行サーバから前記請求書特定情報の通知を受信し、前記受信した前記請求書特定情報と、前記請求書ＤＢに登録された請求書特定情報とを照合し、合致した場合に、前記請求書ＤＢに登録された請求書特定情報に関連する前記請求書データを消去または支払い済を表す状態に変える処理を行うこと、を特徴とする。

これにより、請求書データは請求書管理サーバを介してやりとりされるので、請求書の管理処理を効率的に実現することができる。

本発明により、請求書データは請求書管理サーバを介してやりとりされるので、請求書の管理処理を効率的に行うことができる。

以下に、本発明が適用される請求支払い支援システムの一実施形態について、図面を参照して詳細に説明する。まず、本実施形態の請求支払い支援システムの構成について、図１から図４を参照して説明する。

この請求支払い支援システムは、例えば、請求側のユーザによって、公衆回線を用いるシステム上の端末で請求先への請求処理を実施し、請求先の支払い状況に応じて、前記システム上の端末により支払の済んだデータの消去または支払い済を表す状態に変える処理を実施し、請求データを管理することを特徴とする。これにより、請求先と支払い側の整合を人手によらず実施でき、請求データの消去または支払い済を表す状態に変える処理が容易に行える。

図１は、請求支払い支援システムの構成を示す図である。請求支払い支援システムは、入出金情報を含めた請求書データを管理する請求書管理サーバ８と、入出金業務を行う銀行サーバ９と、請求書の発行を行うユーザが操作する請求側端末１と、請求書に対する支払いを行うユーザが操作する支払側端末２と、を含めて構成され、各装置がネットワークで接続されている。なお、支払側端末２は、必ずしも請求支払い支援システムに含める必要はなく、請求支払い支援システムとネットワークで接続されるコンピュータとして、構成してもよい。

まず、請求側端末１は、請求書を発行し、その請求書に対する支払いの通知を受けると、請求書の消去または支払い済を表す状態に変える処理を行う。一方、支払側端末２は、発行された請求書を受信し、その請求書の支払作業を行う。

ここで、請求書管理サーバ８は、請求書データを管理することにより、入出金情報を含めたクライアントのデータのバックアップを行うことを特徴とする。つまり、請求側端末１または支払側端末２が自装置に保存するデータと同じものを、請求書管理サーバ８の方でも予備として保存することにより、装置の故障などの事故に強いシステムとなる。

なお、請求側端末１と支払側端末２とは、請求書に関する通知メッセージを通信するために、公衆回線などにより接続されている。また公衆回線などにより構成されるインターネット７を介して接続されていても良い。このように、公衆回線を利用し、既存システムを活用することにより、導入コスト及びランニングコストを安くでき、中小企業、個人事業者向けに導入が容易である。

さらに、銀行サーバ９は、ＦＢ（ファームバンキング）回線などの公衆回線を介して、金銭処理を行う。つまり、支払に関する入金および請求に対する出金作業を金融機関（銀行サーバ９）で実施する。このＦＢ回線を使用するためには、銀行（銀行サーバ９のユーザ）と利用者（請求側端末１および支払側端末２のユーザ）との間で、ＦＢ契約が締結されていること、または、使用とともに同時契約することが前提となる。本利用契約は、本サービスを利用する旨の記名・押印とし、利用する口座情報等はＦＢ契約のものとするような、通常のＦＢ契約である。契約書はサポートセンターからの郵送、または営業店からの送付とし、受付は全てサポートセンターへの郵送とする。なお、銀行との情報がやり取りできる仕組みであればファームバンキング、独自のインターネットバンキング等そのシステム形態は問わない。

なお、請求支払い支援システムの各装置（請求書管理サーバ８、銀行サーバ９、請求側端末１、支払側端末２）は、演算処理を行う際に用いられる記憶手段としてのメモリと、前記演算処理を行う演算処理装置とを少なくとも備えるコンピュータとして構成される。なお、メモリは、ＲＡＭ（Random Access Memory）などにより構成される。演算処理は、ＣＰＵ（Central Processing Unit）によって構成される演算処理装置が、メモリ上のプログラムを実行することで、実現される。

図２は、請求支払い支援システムを構成する装置（請求書管理サーバ８、請求側端末１、支払側端末２）の基本構成を示す図である。各装置は、外部の装置と通信するためのインタフェースとして、請求側端末１の通信部２８Ａと、支払側端末２の通信部２８Ｂと、請求書管理サーバ８の通信部２８Ｃと、をそれぞれ有している。

なお、図２の操作端末（請求側端末１、支払側端末２）を実現するために実行されるソフトウェア（例えば、ＣＤ−ＲＯＭに格納されている）について、利用者がソフトの取得・設定等のすべてを行うようにもできる。これにより利用開始時の銀行側の作業負担を軽減する。例えばソフトの導入方法については、ソフトウェア（請求書付）のダウンロード支払期日が、インストール１ヵ月後（１ヶ月間は試行期間）とする。このソフトウェアの利用代金の支払い処理にも、本実施形態の請求支払い支援システムを利用するようにしてもよい。

そして、請求側端末１は、利用者に関する情報を処理するために、利用者に関するデータを格納する利用者ＤＢ１０Ａと、利用者に関するデータを利用者ＤＢ１０Ａに登録する利用者情報登録部１２Ａと、を含めて構成される。
支払側端末２は、利用者に関する情報を処理するために、利用者に関するデータを格納する利用者ＤＢ１０Ｂと、利用者に関するデータを利用者ＤＢ１０Ｂに登録する利用者情報登録部１２Ｂと、を含めて構成される。
請求書管理サーバ８は、利用者に関する情報を処理するために、利用者に関するデータを格納する利用者ＤＢ１０Ｃと、利用者に関するデータを利用者ＤＢ１０Ｃに登録する利用者情報登録部１２Ｃと、を含めて構成される。
ここで、利用者ＤＢ１０Ａ，１０Ｂのデータは、利用者コードが利用者のもののみとなる。つまり、各端末（請求側端末１、支払側端末２）は、通信相手となる相手の端末について利用者の情報を保持する必要がないので、各端末（請求側端末１、支払側端末２）の台数の増加が、負担とならずに済む。
また、利用者ＤＢ１０Ａ，１０Ｂ，１０Ｃは、利用者のＣＭ（コマーシャル）を格納してもよい。このＣＭは、各利用者が登録するたびに変更になる。登録した全利用者のＣＭを利用者が互いに参照する。

図３は、利用者ＤＢ１０Ａ，１０Ｂ，１０Ｃが保持するデータを示すものである。利用者ＤＢ１０Ａ，１０Ｂ，１０Ｃは、ＩＤをキーとして、利用者ごとのレコードを管理している。そして、テーブル２３Ａに示す各レコードは、ＩＤ、利用者コード、個人情報、更新日を含めて構成される。個人情報は、漢字利用者名、カナ利用者名、郵便番号、住所、連絡先電話番号、連絡先ＦＡＸ番号、Ｅメールアドレスを含めて構成される。さらに、テーブル２３Ｂに示す各レコードは、ＩＤ、利用者コード、ファームバンキング情報（店番、科目、口座番号、電話番号）、ＣＭ情報（文字ＣＭ、画像ＣＭ、更新日）を含めて構成される。

さらに、請求側端末１は、請求書に関するデータを格納する請求書ＤＢ２０Ａと、請求書に関するデータを請求書ＤＢ２０Ａに登録する請求書登録部２２Ａと、支払いが済んだ請求書ＤＢ２０Ａのレコードを消去または支払い済を表す状態に変える処理を行う請求書消込部２４Ａと、を含めて構成される。
支払側端末２は、請求書に関するデータを格納する請求書ＤＢ２０Ｂと、請求書に関するデータを請求書ＤＢ２０Ｂに登録する請求書登録部２２Ｂと、支払いが済んだ請求書ＤＢ２０Ｂのレコードを消去または支払い済を表す状態に変える処理を行う請求書消込部２４Ｂと、請求側端末１から通知された請求書に対する支払い処理を行う請求書支払部２６Ｂと、を含めて構成される。
請求書管理サーバ８は、請求書に関するデータを格納する請求書ＤＢ２０Ｃと、請求書に関するデータを請求書ＤＢ２０Ｃに登録する請求書登録部２２Ｃと、支払いが済んだ請求書ＤＢ２０のレコードを消去または支払い済を表す状態に変える処理を行う請求書消込部２４Ｃと、を含めて構成される。

図４は、請求書ＤＢ２０Ａ，２０Ｂ，２０Ｃが保持するデータを示すものである。請求書ＤＢ２０Ａ，２０Ｂ，２０Ｃは、請求書特定情報（請求元利用者コード、請求先利用者コード、請求書管理番号の３つ組）をキーとして、請求書ごとのレコードを管理している。テーブル２４Ａは、請求書の内容を含めない基本的なデータ構造を示し、テーブル２４Ｂは、請求書の内容を含めた応用的なデータ構造を示す。なお、請求側端末１または支払側端末２は、請求書特定情報のうち、片方の利用者コードが必ず自装置になることが期待されるので、自装置の利用者コードを請求書特定情報から省略することにより、記憶領域の節約が可能となる。

なお、利用者が操作する端末（請求側端末１、支払側端末２）は、所定の利用者が請求側と支払側との両方の立場になれるように、同じ構成としている。しかし、ある利用者がどちらか一方の用途だけで利用する場合も想定される。その場合には、片方の処理に必要な機能だけを備えるような専用端末として、構成してもよい。具体的には、請求側端末１として構成される場合には、支払い処理は不要なので、請求書支払部２６Ｂを有しないように構成してもよい。

次に、請求支払い支援システムの動作について、前記図１から図４を適宜参照しつつ、図５（利用者情報の登録処理）、図６（請求書の発行処理）、図７（請求書の支払い処理）、図８（請求書データの消去または支払い済を表す状態に変える処理）に示すフローチャートに沿って、説明する。なお、以下の各処理において、操作端末（請求側端末１、支払側端末２）のディスプレイには、トップ画面（図９、図１０）が表示されており、入力手段（キーボード、マウス）により、ボタンの押下および入力欄へのテキスト文字の入力が行われるものとする。

まず、図５は、利用者情報の登録処理を示すフローチャートである。請求側端末１および支払側端末２は、利用者ＤＢ１０Ａ，１０Ｂに、それぞれ利用者の登録を行う（Ｓ１０１）。具体的には、トップ画面から操作ボタン３２Ｄが押されると、図１１に示す画面３３Ａが表示される。そして、画面３３Ａの各項目の入力を受け付け、「利用者情報登録・変更」ボタンの押下により、画面３３Ｂによって確認処理を行い、画面３３Ｃによって登録を通知する。

次に、請求側端末１および支払側端末２は、請求書管理サーバ８と、通信を行うための接続を確立し（Ｓ１０２）、請求書管理サーバ８に、Ｓ１０１で登録された利用者の情報を送信する（Ｓ１０３）。そして、請求書管理サーバ８は、利用者ＤＢ１０Ｃに、受信した利用者の情報を登録し（Ｓ１０４）、請求側端末１および支払側端末２は、請求書管理サーバ８に対して、通信を行うための接続を切断する（Ｓ１０５）。

次に、図６は、請求書の発行処理を示すフローチャートである。請求側端末１は、請求書ＤＢ２０Ａに、請求書の作成を行う（Ｓ２０１）。具体的には、トップ画面から操作ボタン３２Ｃが押されると、図１２に示す画面４１Ａが表示される。次に、画面４１Ａのボタン４１Ｄが押されると、図１３に示す画面が表示される。図１３に示す画面から選択された請求先の対応する「ここに請求」ボタンが押されると、画面４１Ａに戻り、選択された請求先に関する情報が、画面４１Ａの入力欄に入力される。画面４１Ａで「請求書を保存」または「請求書を送信」ボタンが押されると、画面４１Ｂの確認画面で確認処理を行い、画面４１Ｃによって請求書の登録を通知する。請求側端末１は、「請求書を保存」が押された場合には、トップ画面に処理が戻るが、「請求書を送信」が押された場合には、以下に示す登録された請求書の送信処理を行う。なお、請求先の検索処理には、ユーザから入力された検索条件に適合するようなレコードを、請求書ＤＢ２０Ａから検索するようにしてもよい。作成された請求書は、請求金額を含む請求書の内容と、請求書特定情報（請求元利用者コード、請求先利用者コード、請求書管理番号の３つ組）とを関連づけて、請求書ＤＢ２０Ａに登録される。なお、請求元利用者コードは、省略してもよい。

請求側端末１は、請求書管理サーバ８と、通信を行うための接続を確立し（Ｓ２０２）、請求書管理サーバ８に、請求書および請求側のＣＭ情報を送信する（Ｓ２０３）。請求書管理サーバ８は、請求書ＤＢ２０Ｃに、請求書および請求側のＣＭ情報を登録する（Ｓ２０４）。ここで、請求書は、その内容と、請求書特定情報（請求元利用者コード、請求先利用者コード、請求書管理番号の３つ組）とを関連づけて、請求書ＤＢ２０Ｃに登録される。請求側端末１は、通信を行うための接続を切断し（Ｓ２０５）、インターネット７を介して、請求書の送信を行った旨の、請求書の発行通知メールを、請求先すなわち支払側端末２に対して送信する（Ｓ２０６）。なお、発行通知メールの送信処理は、相手側にメールアドレスがある場合のみ、実施される。

なお、発行通知メールの内容は、例えば次の通りである。
｜件名：佐藤建設様より請求書が送付されました
｜宛先：田中商会 様
｜内容：このメールはｘｘｘｘより送付しております。
｜お心当たりの無い場合は、お手数ですがｘｘｘｘｘｘｘ社
｜電話番号０ｘｘ−ｘｘｘ−ｘｘｘｘまでご連絡願います。
｜田中商会様に佐藤建設様より請求書が届いております。
｜パソコンソフトにて、請求書の受領をお願いいたします。

以上、図６に示すように、本実施形態は、請求書管理サーバ８を介して請求書のやりとりを行うことを特徴とする。これにより、請求書管理サーバ８がデータのバックアップの役割を行うので、端末側でのデータ紛失にも対処出来る。さらに、請求書管理サーバ８を介しての請求書のやりとりの回数に応じて、端末側に課金処理を行ってもよい。これにより、請求書管理サーバ８が課金処理を行うので、簡易的かつ安全な従量課金を実現することができる。

さらに、図７は、請求書の支払い処理を示すフローチャートである。まず、支払側端末２は、請求書の受信契機を検知する。請求書の受信契機は、インターネット７を介して、請求書の発行通知メールを受信した（Ｓ３０１）時でもよいし、定期的に受信してもよいし、トップ画面から操作ボタン３２Ａの押下を受け付けた時でもよい。すると、支払側端末２は、請求書の受信を試みるために、図１４に示す画面５１Ａを表示して、通信中であることを表示する。

支払側端末２は、請求書管理サーバ８と、通信を行うための接続を確立し（Ｓ３０２）、請求書管理サーバ８から、請求書およびＣＭ情報を受信する（Ｓ３０３）。請求書管理サーバ８に請求書がある場合には、画面５１Ｂが表示され、請求書管理サーバ８に請求書がない場合には、画面５１Ｃが表示される。なお、ここで受信するＣＭ情報は、トップ画面の表示欄「ＣＭ情報を表示」の箇所に表示されるものである。さらに、表示されるＣＭ情報は、フィルターをかけて、そのフィルターで指定された条件に合致するＣＭのみを表示するように、表示するＣＭを制限できる。また必要に応じて請求書の受信結果を履歴として請求書管理サーバ８に保管できる。さらに請求書を受信した旨を了解したという情報なども請求書管理サーバ８に登録し、保管することもできる。

次に、支払側端末２は、請求書ＤＢ２０Ｂに、受信した請求書を登録する（Ｓ３０４）。なお、登録された請求書は、トップ画面の３１Ｘの欄に表示される。そして、支払側端末２は、請求書管理サーバ８に対して、通信を行うための接続を切断する（Ｓ３０５）。

さらに、支払側端末２は、銀行サーバ９に、請求書に記載の請求に対する支払い処理を実行する（Ｓ３０６）。そして、銀行サーバ９は、支払処理が終了した後、請求書の請求書特定情報と、支払金額との情報を、支払側端末２から受信する。この受信するデータは、例えば、ＥＤＩ（Electronic Data Interchange）データとして受信する。この支払い処理は、例えば、トップ画面の操作ボタン３１Ａ（未払いの請求書をまとめて支払う場合）、操作ボタン３１Ｂ（未払いの請求書の一部を支払う場合）、または、操作ボタン３１Ｅ（指定された未払いの請求書を支払う場合）の押下により、起動される。

指定された未払いの請求書を処理する場合において、まず、操作ボタン３１Ｅ（指定された未払いの請求書のを支払う場合）が押下された場合には、図１５に示す画面５２Ａによる確認処理の後、請求書に対する支払のデータが銀行サーバに送信され、画面５２Ｂによる通知メッセージが表示される。一方、トップ画面から操作ボタン３１Ｆが押下された場合には、図１６の確認処理の後、請求書を破棄する。このように、破棄した請求書の一覧は、トップ画面から操作ボタン３２Ｈを押下すると表示される図１７の画面により、確認することができる。また破棄した請求書に関する情報は請求書管理サーバ８に自動的に登録し、保管することもできる。例えばテーブル２４ＡにＩＤを００５、種別を破棄などとし登録することもできる。

未払いの請求書をまとめて支払う場合において、トップ画面から操作ボタン３１Ａが押されると、図１８に示す確認ボタン付きの画面５５Ａ、および、未払いの請求書のリストを示す画面５５Ｂが、表示される。そして、画面５５Ａから「支払う」ボタンが押されると、画面５５Ｃの確認処理の後、未払いの請求書を一括で支払う処理を行う。なお、画面５５Ｂは、トップ画面の未払請求者のチェックがＯＮのデータが全て表示される。

未払いの請求書の一部を支払う場合において、トップ画面から操作ボタン３１Ｂが押されると、図１９に示す確認ボタン付きの画面５６Ａ、および、未払いの請求書のリストを示す画面５６Ｂが、表示される。そして、画面５６Ａから支払う金額の入力を受け付け、かつ、「支払う」ボタンが押されると、画面５６Ｃの確認処理の後、未払いの請求書を一括で支払う処理を行う。ここで、未払い金額（請求金額）よりも支払う金額のほうが少ない場合、例えば、請求金額の少ないレコードを優先して支払うような処理を行う。なお、画面５６Ｂは、請求元毎にデータがソートされて表示される。支払う金額は請求元単位に設定できる。また、この支払いに関する情報は請求書管理サーバ８に自動的に登録し保管することもできる。

以上の支払い処理の結果について、支払側端末２は、インターネット７を介して、支払通知メールを送信する（Ｓ３０７）。なお、支払通知メールの内容は、例えば次の通りである。
｜件名：田中商会様が請求金額をお支払いされました
｜宛先：佐藤建設 様
｜内容：このメールはｘｘｘｘより送付しております。
｜お心当たりの無い場合は、お手数ですがｘｘｘｘｘｘｘ社
｜電話番号 ０ｘｘ−ｘｘｘ−ｘｘｘｘまでご連絡願います。
｜佐藤建設様より田中商会様に送付された請求書について
｜本日、田中商会様が田中商会様のお取引銀行に支払いを
｜依頼されましたのでご連絡差し上げます。

なお、支払い処理の結果は、トップ画面から操作ボタン３２Ｅを押すと表示される図２０の一覧画面により、確認が可能である。そして、この確認画面のボタン「表示」（印刷プレビュー）、「印刷」、または、「ＣＳＶ出力」を押すと、それぞれ対応した形式で図２０の一覧画面の内容が、出力される。なお、請求元で請求書データの消去または支払い済を表す状態に変える処理を行うと、トップ画面の入金待ちの欄からは消えるが、入金済み情報は請求書ＤＢ２０Ａに保存される。この入金済み情報の保存期間を設定することもできる。またこの、入金済み情報は請求書管理サーバ８に自動的に登録し、保管することもできる。

そして、支払側端末２からの電子データではなく、他の方法（例えば、郵送による紙面）での請求書の支払の旨の確認がとれた場合の、請求書の消去または支払い済を表す状態に変える処理を行う操作を説明する。

請求側端末１は、トップ画面から操作ボタン３１Ｃの入力を受け付けると、操作ボタン３１Ｃに対応するレコードについて、図２１に示す画面４３Ａを表示して確認処理を行った後、画面４３Ｂによって請求書の消去または支払い済を表す状態に変える処理（請求書の入金済みの旨の表示）が行われたことをユーザに知らせる。または、請求側端末１は、トップ画面から操作ボタン３１Ｄの入力を受け付けると、操作ボタン３１Ｄに対応するレコードについて、図２２に示す画面４４Ａを表示して確認処理を行った後、画面４４Ｂによって請求書の破棄処理が行われたことをユーザに知らせる。

以上、この操作ボタン３１Ｃまたは操作ボタン３１Ｄによって起動される処理は、請求書ＤＢ２０Ａのレコードを直接編集する処理である。この処理は、例えば、現金書留等で入金された場合等に行う処理である。これにより、ＦＢ契約をしていないユーザに対しても、請求書の消去または支払い済を表す状態に変える処理を実現することができる。またこの、入金済み情報は請求書管理サーバ８に登録し、保管することもできる。

さらに、図８は、請求書の消去または支払い済を表す状態に変える処理を示すフローチャートである。以下、図８のフローチャートについて、説明する。この図８は、銀行サーバ９からの支払い通知の内容と、請求書の消去または支払い済を表す状態に変える処理とを連動させる処理となる。これにより、ユーザにとって、前記トップ画面から操作ボタン３１Ｃまたは操作ボタン３１Ｄの操作（手動による消去または支払い済を表す状態に変える処理）を請求書ごとに毎回行うような手間を省くことができる。

まず、請求側端末１は、インターネット７を介して、支払通知メールを受信する（Ｓ４０１）。または、請求側端末１は、トップ画面から操作ボタン３２Ｆを押すと表示される図２３を参照し送付済みの請求書を確認して、例えば請求日に近づいてきたら、トップ画面から操作ボタン３２Ｂを押す。

すると、図２４の画面４６Ａが表示され、銀行サーバ９と通信していることがわかる。そのとき、請求側端末１は、銀行サーバ９から、入金の通知を受信する（Ｓ４０２）。この入金の通知には、請求書特定情報と、支払金額とを含む。

そして、請求側端末１は、受信した入金の通知に、入金済みの請求書があるかどうか判定する（Ｓ４０３）。まず、入金済みの請求書がある場合には、画面４６Ｂが表示され、消しこみ処理が起動する。一方、入金済みの請求書がない場合には、画面４６Ｄが表示され、処理を終了する。なお、消しこみ処理が行われた請求書の一覧は、トップ画面から操作ボタン３２Ｇを押すと表示される、図２５の画面により、確認が可能である。

請求側端末１は、Ｓ４０３において入金済みの請求書がある場合、請求書ＤＢ２０Ａに、入金済みの請求書に関するレコードに対して、消去または支払い済を表す状態に変える処理を行う（Ｓ４０４）。つまり、入金の通知に含まれる請求書特定情報と、請求側端末１の請求書ＤＢ２０Ａに格納されている既に発行した請求書のレコードとを照合する。そして、一致したレコードについて、入金の通知に含まれる支払金額と、請求書ＤＢ２０Ａに格納されているレコードの請求金額とが一致する場合に、そのレコードを消去し、または、支払済みのフラグをたてる。この消去または支払い済を表す状態に変える処理が終了すると、画面４６Ｃが表示される。

さらに、請求側端末１は、消しこみ処理を自装置だけでなく、請求書管理サーバ８にも反映させる。具体的には、請求側端末１は、請求書管理サーバ８と、通信を行うための接続を確立し（Ｓ４０５）、請求書管理サーバ８に、消去または支払い済を表す状態に変える処理を行った請求書に関する情報（請求書特定情報、支払金額）を送信する（Ｓ４０６）。そして、請求書管理サーバ８は、請求書ＤＢ２０Ｂに、消去または支払い済を表す状態に変える処理を行った請求書に関する情報を登録（消しこみ処理）する（Ｓ４０７）。

以上説明した本実施形態により、請求書データは請求書管理サーバを介してやりとりされるので、請求書の管理処理を効率的に行うことができる。つまり、請求書を発行する側には請求データを請求先の支払い結果に応じて容易に管理することができる。支払側では請求に対する支払い業務の効率が向上し、また処理の信頼性が向上する。

例えば、請求側端末は公衆回線を用いるシステム上の端末で請求先への請求処理を実施し、請求先の支払い状況に応じて、前記装置により支払の済んだデータを消去または支払い済を表す状態に変える処理を行う作業を実施し、請求書データを管理することができるため、請求先と支払い側の整合を人手によらず実施でき、請求書データの消去または支払い済を表す状態に変える処理が容易に行える

さらに、例えば支払側端末は、公衆回線と請求及び支払関連情報を管理する装置により、請求に対する支払いを前記システムの端末装置上で実施でき、金融機関から請求先への送金結果を公衆回線を通じて参照できるためなどの理由から、本発明によれば支払い確認を端末上で容易に確認できる。

以上説明した本発明は、以下のようにその趣旨を逸脱しない範囲で広く変形実施することができる。

例えば、各端末（請求側端末１、支払側端末２）は、サーバ（請求書管理サーバ８、銀行サーバ９）と接続または切断する際に、サーバが他の処理で忙しいときには、リトライ処理を行ってもよい。このリトライ処理は、あるタイミングでサーバとの接続または切断に失敗した場合に、時間をおいて再びサーバとの接続または切断を試みる処理である。そして、所定の回数（例えば３回）連続して接続または切断に失敗した場合に、タイムアウトとして、ユーザに接続または切断の失敗を通知する。このとき、サーバと接続した後に行うタスク（例えば送信すべき請求書データ）は、未処理のタスクとして、各端末において、保存される。この未処理のタスクは、後日、再度接続を試みるときに、再度使用される。

また、各端末（請求側端末１、支払側端末２）と、サーバ（請求書管理サーバ８、銀行サーバ９）との通信処理において、請求書データや利用者のデータ（個人情報）などの機密性の高い情報がやりとりされる。そこで、セキュリティを高めるために、この通信を暗号化して通信したり、サーバに接続（ログイン）する際に、パスワード認証などの既存の認証手段を活用してもよい。

さらに、請求側端末１のユーザと、支払側端末２のユーザとで、普段口座を持ち、利用する銀行の種類が異なる場合も想定される。その場合には、図２６に示すように、複数の銀行サーバ９が互いに接続されているような構成としてもよい。例えば、図２６では、２つの銀行サーバ９があり、支払側端末２が送信したデータは、請求側端末１が受信するまで、銀行サーバ９の間（銀行サーバ９Ａ→銀行サーバ９Ｂ）を転送される。

本発明の一実施形態に関する請求支払い支援システムを示す構成図である。 本発明の一実施形態に関する請求支払い支援システムを構成する装置を示す構成図である。 本発明の一実施形態に関する利用者ＤＢを示す構成図である。 本発明の一実施形態に関する請求書ＤＢを示す構成図である。 本発明の一実施形態に関する利用者情報の登録処理を示すフローチャートである。 本発明の一実施形態に関する請求書の発行処理を示すフローチャートである。 本発明の一実施形態に関する請求書の支払い処理を示すフローチャートである。 本発明の一実施形態に関する請求書の消去または支払い済を表す状態に変える処理を示すフローチャートである。 本発明の一実施形態に関する請求書に関するトップ画面を示す画面図である。 本発明の一実施形態に関する操作ボタンに関するトップ画面を示す画面図である。 本発明の一実施形態に関する利用者の登録を示す画面図である。 本発明の一実施形態に関する請求書の新規作成または変更を示す画面図である。 本発明の一実施形態に関する請求書の検索結果を示す画面図である。 本発明の一実施形態に関する請求書の確認を示す画面図である。 本発明の一実施形態に関する請求書に対する支払を示す画面図である。 本発明の一実施形態に関する未払いの請求書に対する破棄を示す画面図である。 本発明の一実施形態に関する支払を取り消した請求書の一覧を示す画面図である。 本発明の一実施形態に関する請求書に対してまとめて支払う処理を示す画面図である。 本発明の一実施形態に関する請求書に対して一部支払う処理を示す画面図である。 本発明の一実施形態に関する支払い済み請求書の一覧を示す画面図である。 本発明の一実施形態に関する請求書の入金確認処理を示す画面図である。 本発明の一実施形態に関する請求書の破棄処理を示す画面図である。 本発明の一実施形態に関する送付済み請求書の一覧を示す画面図である。 本発明の一実施形態に関する請求書の入金状況の確認処理を示す画面図である。 本発明の一実施形態に関する入金済み請求書の一覧を示す画面図である。 本発明の一実施形態に関する複数の銀行サーバを経由する請求支払い支援システムを示す構成図である。

符号の説明

１ 請求側端末
２ 支払側端末
７ インターネット
８ 請求書管理サーバ
９ 銀行サーバ
１０Ａ，１０Ｂ，１０Ｃ 利用者ＤＢ
１２Ａ，１２Ｂ，１２Ｃ 利用者情報登録部
２０Ａ，２０Ｂ，２０Ｃ 請求書ＤＢ
２２Ａ，２２Ｂ，２２Ｃ 請求書登録部
２４Ａ，２４Ｂ，２４Ｃ 請求書消込部
２６Ｂ 請求書支払部
２８Ａ，２８Ｂ，２８Ｃ 通信部

Claims (9)

1. 請求書データの発行を行う請求側端末と、前記請求書データを管理する請求書管理サーバと、前記請求書データをもとに入出金業務を実行する銀行サーバと、を含めて構成される請求支払い支援システムであって、
   前記請求側端末は、入力された請求書の内容に基づき請求書データを発行し、その請求書データを特定する請求書特定情報と関連づけて請求書ＤＢに登録し、前記請求書データに請求書特定情報を付して請求書管理サーバに送信し、
   前記請求書管理サーバは、前記送信された前記請求書データおよび前記請求書特定情報とを関連づけて記憶手段に記憶し、前記請求書データおよび前記請求書特定情報を前記請求書データに対する支払いを行うコンピュータに送信し、
   前記銀行サーバは、前記支払いを行うコンピュータに対して前記請求書データに基づいて支払処理を実行し、前記支払いを行うコンピュータから前記実行した支払処理に関する前記請求書特定情報を受信し、
   前記請求側端末は、前記銀行サーバから前記請求書特定情報の通知を受信し、前記受信した前記請求書特定情報と、前記請求書ＤＢに登録された請求書特定情報とを照合し、合致した場合に、前記請求書ＤＢに登録された請求書特定情報に関連する前記請求書データを消去または支払い済を表す状態に変える処理を行うこと、
   を特徴とする請求支払い支援システム。
2. 請求書データの発行を行う請求側端末と、前記請求書データに対する支払いを行う支払側端末と、前記請求書データを管理する請求書管理サーバと、前記請求書データをもとに入出金業務を支払側端末と実行する銀行サーバと、を含めて構成される請求支払い支援システムであって、
   前記請求側端末は、入力された請求書の内容に基づき請求書データを発行し、その請求書データを特定する請求書特定情報と関連づけて請求書ＤＢに登録し、前記請求書データに請求書特定情報を付して請求書管理サーバに送信し、
   前記請求書管理サーバは、前記送信された前記請求書データおよび前記請求書特定情報とを関連づけて記憶手段に記憶し、
   前記支払側端末は、前記請求書管理サーバから、前記請求書データおよび前記請求書特定情報を受信し、前記受信した前記請求書データに基づいて前記銀行サーバに支払処理を実行し、前記銀行サーバに前記請求書特定情報を通知し、
   前記請求側端末は、前記銀行サーバから前記請求書特定情報の通知を受信し、前記受信した前記請求書特定情報と、前記請求書ＤＢに登録された請求書特定情報とを照合し、合致した場合に、前記請求書ＤＢに登録された請求書特定情報に関連する前記請求書データを消去または支払い済を表す状態に変える処理を行うこと、
   を特徴とする請求支払い支援システム。
3. 前記請求書管理サーバは、
   前記請求側端末が消去または支払い済を表す状態に変える処理を行った前記請求書データについて、前記請求側端末から通知を受けて、前記記憶手段から消去または支払い済を表す状態に変える処理を行うこと、
   を特徴とする請求項２に記載の請求支払い支援システム。
4. 前記請求書特定情報は、請求側端末、支払側端末、ならびに、請求側端末および支払側端末の組ごとに異なるＩＤにより構成されること、
   を特徴とする請求項２または請求項３に記載の請求支払い支援システム。
5. 前記支払側端末は、前記銀行サーバに前記請求書特定情報を通知するときに、前記支払処理によって支払った金額を付して通知し、
   前記請求側端末は、前記銀行サーバから前記請求書特定情報の通知を受信するときに、前記支払った金額も併せて受信し、前記請求書ＤＢに登録された請求書特定情報に関連する前記請求書データの請求金額に、前記支払った金額が達した場合に、前記前記請求書データを消去または支払い済を表す状態に変える処理を行うこと、
   を特徴とする請求項２ないし請求項４のいずれか１項に記載の請求支払い支援システム。
6. 前記銀行サーバは、複数の計算機が互いにネットワークで接続されて構成され、前記支払側端末が前記支払処理を行う第１の計算機と、前記請求側端末が前記請求書特定情報の通知を受信する第２の計算機とが異なるときには、前記請求書特定情報および前記支払った金額に関する情報が、前記第１の計算機から前記第２の計算機へ通知されること、
   を特徴とする請求項５に記載の請求支払い支援システム。
7. 請求項２ないし請求項６のいずれか１項に記載の請求支払い支援システムに利用されるまたは使用される請求側端末であって、
   前記請求書データを前記請求書特定情報と関連づけて格納する請求書ＤＢと、前記請求書ＤＢにアクセスする請求書登録部と、前記銀行サーバから受信した前記請求書特定情報と、前記請求書ＤＢの前記請求書特定情報とを照合し、合致した前記請求書ＤＢのレコードを消去または支払い済を表す状態に変える処理を行う請求書消込部と、
   を備えることを特徴とする請求側端末。
8. 請求項２ないし請求項６のいずれか１項に記載の請求支払い支援システムに利用されるまたは使用される前記支払側端末であって、
   前記請求書データと前記請求書特定情報とを前記請求書管理サーバから受信し、前記請求書データに従って、前記前記銀行サーバに支払処理を実行する請求書支払部と、前記支払処理が実行された前記請求書データについて、関連する前記請求書特定情報を前記銀行サーバに通知する通信部と、
   を備えることを特徴とする支払側端末。
9. 請求書データの発行を行う請求側端末と、前記請求書データに対する支払いを行う支払側端末と、前記請求書データを管理する請求書管理サーバと、前記請求書データをもとに入出金業務を支払側端末と実行する銀行サーバと、を含めて構成される請求支払い支援システムに使用される請求支払い支援のためのコンピュータプログラムであって、前記請求支払い支援プログラムは、前記請求支払い支援システムの各装置に読み取られて実行されることで、
   前記請求側端末に、入力された請求書の内容に基づき請求書データを発行する手順と、その請求書データを特定する請求書特定情報と関連づけて請求書ＤＢに登録する手順と、前記請求書データに請求書特定情報を付して請求書管理サーバに送信する手順と、
   前記請求書管理サーバに、前記送信された前記請求書データおよび前記請求書特定情報とを関連づけて記憶手段に記憶する手順と、
   前記支払側端末に、前記請求書管理サーバから、前記請求書データおよび前記請求書特定情報を受信する手順と、前記受信した前記請求書データに基づいて前記銀行サーバに支払処理を実行する手順と、前記銀行サーバに前記請求書特定情報を通知する手順と、
   前記請求側端末に、前記銀行サーバから前記請求書特定情報の通知を受信する手順と、前記受信した前記請求書特定情報と、前記請求書ＤＢに登録された請求書特定情報とを照合する手順と、合致した場合に、前記請求書ＤＢに登録された請求書特定情報に関連する前記請求書データを消去または支払い済を表す状態に変える処理を行う手順と、
   を実行させることを特徴とする請求支払い支援のためのコンピュータプログラム。

Images