JP7804263B2 - 電子決済代行業務システムおよび電子決済業務システムの決済代行処理方法 - Google Patents

Description

本発明は、電子決済業務システムおよび電子決済業務システムの決済代行処理方法に関するものである。

近年、電子決済業務システムが進化し、企業の決済方法も電子化が進み、気軽にクレジット決済を利用して決済業務を軽減化する動きが顕著である。

また、各企業間の取引、すなわちＢｔｏＢ（Ｂｕｓｉｎｅｓｓ ｔｏ Ｂｕｓｉｎｅｓｓ）に対する決済も代行システムを利用する企業も増加している。ここで、代行システムとして、現在ネット上では、Ｐａｉｄ、ＢｉｚＰａｙ、ＮＰ掛け払い（各サービス名）が契約可能な代行システムとして参照可能になっている。

これらの代行システムは、それぞれ独特の代行処理システムが構築され、契約企業にとって業務決済に関して利便性を担保し、企業間の決済処理をより効率化するサービスを提供している。これにより、売り手側の入金業務や買い手側の与信審査や入金確認、代金督促といった煩雑な業務の軽減が図られている。

特開２０２１－３３９３９号公報

しかしながら、これらの決済代行システムを利用する対価は、業務経費の節減が中心で、その利用価値は一元的でいずれの決済代行システムを採用してもそれほど明確な差異があるとは認められない。

本発明は、上記の課題を解決するためになされたもので、本発明の目的は、決済代行システムを利用する企業にとって付加価値の高い決済サービスを提供できる電子決済業務システムおよび電子決済業務システムの決済代行処理方法を提供することである。

上記目的を達成する本発明の電子決済業務システムは以下に示す構成を備える。
支払い元の経理処理を行う複数の第１データ端末と、支払い先の経理処理を行う複数の第２データ端末と、支払い処理を実行する銀行システムと、各法人間の請求と支払いの業務を実行する代理処理サーバとが通信して支払い代行サービスを行う電子決済代行業務システムであって、前記代理処理サーバは、支払い元のいずれかの第１データ端末からアップロードされる複数の請求書データを解析して支払い総額を算出する算出手段と、前記算出手段が算出した支払い計算書データを支払い元のいずれかの第１データ端末に送信する送信手段と、前記支払い計算書データに対する支払い認証を支払い元のいずれかの第１データ端末から受領することに応じて、支払い元のデータ端末から登録された支払い先情報に従う支払い銀行口座に対して前記銀行システムを介して代理支払いを実行する代理支払い手段と、前記代理支払い手段が実行した代理支払い額データに基づく支払い完了をいずれかの第１データ端末に通知する通知手段と、を備えることを特徴とする。

本発明に係る電子決済業務システムの一つ以上の実施態様によれば、決済代行システムを利用する法人にとって付加価値の高い行決済サービスを提供することができる。

図面は、本発明の特定の実施の形態を示し、発明の不可欠な構成ばかりでなく、選択的及び好ましい実施の形態を含む。
本実施形態を示す電子決済代行業務システムの構成を説明するブロック図である。 図１に示した代理処理サーバの導入処理部のデータ処理の流れを説明するチャート図である。 図１に示した代理処理サーバのＢＭアクワイアラ登録部のデータ処理の流れを説明するチャート図である。 図１に示した支払い元ＰＣによる支払い先登録処理の流れを説明するチャート図である。 図１に示した支払い元ＰＣによる請求書アップロード処理の流れを説明するチャート図である。 図１に示した代理処理サーバの支払い先への代理支払い部による処理の流れを説明するチャート図である。 図１に示した代理処理サーバの支払い元への請求部による処理の流れを説明するチャート図である。 図１に示した代理処理サーバのマイル発行処理部による処理の流れを説明するチャート図である。 図１に示した代理処理サーバのマイル交換処理部による処理の流れを説明するチャート図である。 本実施形態を示す電子決済代行業務システムにおける手数料支払い処理を説明するフローチャートである。 本実施形態を示す電子決済代行業務システムにおける手数料支払い処理を説明するフローチャートである。 本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。 本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。 本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。 本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。 本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。 本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。 本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。 本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。 本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。 本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。 本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。 本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。 本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。 本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。 本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。 本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。 本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。 本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。 本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。 本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。 本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。 本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。 本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。 本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。 本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。 本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。 本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。 本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。 本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。 本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。 本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。 本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。 図１に示した代理処理サーバによるワンタップ処理の流れを説明するチャート図である。 図１に示した代理処理サーバによるワンタップ処理の流れを説明するチャート図である。

次に本発明を実施するための最良の形態について図面を参照して説明する。
下記の実施の形態は、図１～図１１に示す電子決済代行業務システムに関し、発明の不可欠な構成ばかりでなく、選択的及び好ましい実施の形態を含む。
＜システム構成の説明＞
〔第１実施形態〕
次に本発明を実施するための最良の形態について図面を参照して説明する。

図１は、本実施形態を示す電子決済代行業務システムの構成を説明するブロック図である。本システムでは、支払い元法人側のデータ端末と、支払い先側のデータ端末と、後述する決済サービス（ＴｏｂｅＰａｙ（サービス名））プログラムが運用されるサーバ装置とがネットワークを介して通信可能なシステム例を示す。
より具体的には、本実施形態に示す電子決済代行業務システムでは、支払い元の経理処理を行う複数の第１データ端末（支払い元ＰＣ１－１～１－Ｎ）と、支払い先の経理処理を行う複数の第２データ端末（支払い先ＰＣ７－１～７－Ｎ）と、支払い処理を実行する銀行システム（代行ＢＫ５）と、各法人間の請求と支払いの業務を実行する代理処理サーバ４とが通信して支払い代行サービスを行う。

なお、ＴｏｂｅＰａｙシステムは、アーキテクチャ、データソースにはそれぞれグローバルメガクラウドのＤＢを採用し、一般的な脆弱性を混入しにくい環境でのサービス構築を実現している。

また、ＡｐｐｓｙｎｃとＧｒａｐｈＱＬで表現できないロジックの実装は、ＡｐｐｓｙｎｃのリゾルバとしてＬａｍｂｄａを採用し、揮発性的なプロセスによる使い捨て稼働をさせているため、ウイルスやマルウエアの混入は根本的に回避できる構成としている。

つまり、ＴｏｂｅＰａｙシステムは、全てのクライアントが、安心、安全に取引を継続できるためのセキュリティ基盤を備えていることを特徴とする。

図１において、１－１～１－Ｎは支払い元ＰＣで、所定のオペレーティングシステムの下、各種のユーザアプリが起動され、さらに、本サービスシステムが提供する決済サービスアプリも起動可能に構成されている。なお、決済サービスアプは、代理処理サーバ４からダウンロードされてインストールされる。
ここで、支払い元ＰＣ１－１～１－Ｎは、各種の法人（例えば歯科医院さん）が管理するＰＣであるものとする。なお、ＰＣ自体は、通常のハードウエア資源を備え、ＣＰＵがハードディスク等のメモリ資源からオペレーティングシステムをＲＡＭ上にロードし、ＯＳが管理する各種のアプリケーションを実行することで各種のデータ処理、ネットワーク通信処理、表示処理、印刷処理等の業務処理を実行可能に構成されている。
本実施形態において、ＴｏｂｅＰａｙシステムは、ＯＳに管理される決済代行処理プログラムとして機能する。ここで、ＴｏｂｅＰａｙシステムは、支払い元ＰＣおよび支払い先ＰＣに対して、ログイン作業、請求書入力作業、月極めの請求額の確認等の代行処理を受け付けたり、確認したりするためのユーザーインタフェースを提供する。
これにより、支払い元ＰＣおよび支払い先ＰＣの経理担当者は、ＴｏｂｅＰａｙシステムが提供するＷＥＢ画面を閲覧しながら、共通化された操作性の高い画面を介して必要な情報を入力したり、承認作業をしたりすることを視認性よく行うことができる。

４は代理処理サーバで、インターネット網Ｉを介して支払い元ＰＣ１－１～１－Ｎ、支払先ＰＣ７－１～７－Ｎ、代行銀行システム（図中では、代行ＢＫと記す）５と相互に通信可能に接続される。代行銀行システム５は、全国、および世界の銀行システムを含む支払い指定された銀行システム５１－１～５１－Ｎと接続されている。

代理処理サーバ４は、本サービスを導入するための導入処理部４１、ＢＭアクワイアラ登録部４２、支払先登録部４３、請求書アップロード部４４、支払い先への代理支払部４５、支払い元への請求処理部４６等からなる各種のアプリが図示しない記憶部に記憶され、各種のプロセッサからなる主制御部が通信処理を制御して各種サービスのためのデータ処理を実行する。

なお、各導入処理部４１、ＢＭアクワイアラ登録部４２、支払先登録部４３、請求書アップロード部４４、支払い先への代理支払部４５、支払い元への請求処理部４６の一例については、後述する図面を参照して詳述する。

ＢＭ管理サーバ８は、マイル発行処理部８１、マイル交換処理部８２を含んで構成され、図示しない記憶部を用いてＴｏＢＰａｙシステムによる支払い額に応じたビジネスマイルの発行とビジネスマイルの残高を管理する。なお、ＴｏＢＰａｙシステムによるマイル管理処理およびマイルの交換処理等については後述する。

本実施形態では、ＢＭ管理サーバ８は、ビジネスマイル数を記憶するビジネスマイル記憶手段を備え、マイル発行処理部８１が第１データ端末としての支払い元ＰＣの支払い額に応じたビジネスマイルを支払元となる法人宛に発行する処理を行う。また、マイル交換処理部８２が第１データ端末からの指示に従い、所要の支払いに充当するビジネスマイル数と交換する処理を行う。ここで、ＢＭ管理サーバ８はインターネット網Ｉを介して代理処理サーバ４、支払い元ＰＣと通信可能に接続される。

また、本実施形態では、ＴｏＢＰａｙシステムとして、ＢＭ管理サーバ８と代理処理サーバ４とが連携してＢＭ処理を分担処理する構成として説明するが、代理処理サーバ４がＢＭ管理サーバ８の機能処理を代行する構成としてもよい。
さらに、代理処理サーバ４が実行する導入処理部４１、ＢＭアクワイアラ登録部４２、支払先登録部４３、請求書アップロード部４４、支払い先への代理支払部４５、支払い元への請求処理部４６の各機能処理を１つのアプリケーションとして構成し、支払い元ＰＣ１－１～１－Ｎ、支払先ＰＣ７－１～７－Ｎが操作する支払い処理画面を介して支払い処理業務サービスを提供する構成としてもよい。

また、代理処理サーバ４は、ＣＰＵ、ＲＯＭ、ＲＡＭ等を備えるコントローラ部と、インターネット網Ｉを介して支払い元ＰＣ１－１～１－Ｎや支払い先ＰＣ７－１～７－Ｎと通信する通信部を備え、暗号化処理を施してセキュリティを担保するやり取りを可能としている。

また、代理処理サーバ４から直接メール等で支払い先ＰＣや支払い元ＰＣのアカウント宛に指示を送付する際には、電子証明書を添付して、フィッシング詐欺やハッキングによる顧客のデータが流出してしまう被害を防止する機能を備えているものとする。

なお、支払い元ＰＣ１－１～１－Ｎ、支払先ＰＣ７－１～７－Ｎ、代行銀行システム５、銀行システム５１－１～５１－Ｎ、クレジット会社端末６－１～６－Ｎ、代理処理サーバ４には、それぞれインターネット網Ｉと通信する通信処理部を備えて暗号化処理された通信を行う環境が整備されているものとする。

また、本システムでは、アーキテクチャ、データソースにはそれぞれグローバルメガクラウドのＤＢを採用し、一般的な脆弱性は混入しにくい環境でのサービスを提供するシステムを構築している。

これにより、ウイルスやマルウエアの混入されることを回避するとともに、全てのクライアントが、安心、安全に取引を継続できるようにシステム設計がなされている。

このように構成された電子決済代行業務システムにおいて、代理処理サーバ４の支払先への代理支払部４５の演算機能により、支払い元のいずれかの支払い元ＰＣ１－１～１－Ｎからアップロードされる複数の請求書データを解析して支払い総額を算出する。

さらに、代理処理サーバ４の通信機能により、支払先への代理支払部４５が算出した支払い計算書データを支払い元のいずれかの第１データ端末に送信する。また、支払先への代理支払部４５は、支払い計算書データに対する支払い認証を支払い元のいずれかの支払い元ＰＣ１－１～１－Ｎから受領することに応じて、支払い元元ＰＣ１－１～１－Ｎから登録された支払い先情報に従う支払い銀行口座に対して代行ＢＫ５を介して代理支払いを実行する。

さらに、代理処理サーバ４の通信機能により、支払先への代理支払部４５が実行した代理支払い額データに基づく支払い完了をいずれかの第１データ端末に通知する通知する。

以下、図２～図９を参照して、図１に示した代理処理サーバ４の各処理部の特定の処理を順次説明する。以下、ＴｏＢＰａｙシステムとして機能する代理処理サーバ４による各機能処理について、図１３～図３５に一例を示すユーザーインタフェースを参照しながら詳述する。
〔導入処理部４１のデータ処理〕

図２は、図１に示した代理処理サーバ４の導入処理部４１のデータ処理の流れを説明するチャート図である。なお、支払い元ＰＣ１－１～ＰＣ１－Ｎには、当該支払い元ＰＣ１－１～ＰＣ１－Ｎを操作する支払い元ユーザが法人側の担当者とする。なお、本明細書において、代理処理サーバ４が提供する上記決済サービス名をＴｏＢＰａｙと呼ぶ。

まず、ＴｏＢＰａｙシステムの導入のため、決済サービス管理会社のＴｏＢＰａｙ担当者がインターネット網Ｉを介して、あるいは営業を行い、支払い元ユーザ（法人の経理担当者）にＴｏＢＰａｙ導入を提案する。

ここで支払い元ユーザとＴｏＢＰａｙ担当者と、そのメリットについて検討して、支払い元ユーザが当該ＴｏＢＰａｙを導入することに合意する。次に、支払い元ユーザが支払い元法人の役職者と協議を行い、正式導入を決定し申し込みフォーム（例えばＰＤＦファイルとして提供される）に必要事項（規約）を入力する。

この際、規約が記載された書面（デジタル署名書面を含む）に対して、支払い元法人のサインが入力されると、当該書面（ＰＤＦファイル）がＴｏＢＰａｙシステムにインターネット網Ｉを介して通知される。これを受けて、ＴｏＢＰａｙシステムは、支払い元法人をＴｏＢＰａｙシステムで受け付ける受任処理を行う。具体的には、導入処理部４１は、図１２に示す新規登録を行うためのメールアドレス入力のためのＵＩ画面を支払元ＰＣ１－１の表示装置に表示する。本画面（ＳＩＧＮ ＵＰ）では、メールアドレスを入力する。これに応じて、導入処理部４１は、メールアドレスに登録メールを送付してメール確認を行い（図１３に示す新規登録を行うためのＵＩ画面）、さらに、図１４に示す新規登録を行うためのＵＩ画面に対して、パスワード、パスワード再入力、氏名、電話番号、登録アカウント企業情報として、会社名（法人名）、職種、電話番号等の必要事項を入力する。ここで、図１５に示すＵＩ画面のように、新規登録における本登録前に、入力した事項を修正し直して、登録ボタンがクリックされることで、図１６に示すＵＩ画面を支払元ＰＣ１－１の表示装置に表示して、新規登録処理を完了する。

次に、ＴｏＢＰａｙシステムのオペレータが管理画面を受信した支払い元法人に対して整理番号（管理番号）発行すると、受任した支払い元法人の正式な管理画面発行処理が実行される。具体的には、正確には、図１７に示すＵＩ画面に一例を示す管理画面のＵＲＬが支払い元法人の登録アドレスに送付され、その管理画面に対して、支払い元ユーザー（経理担当者）からＩＤ／ＰＡＳＳ登録をしてもらう。
次に、ＴｏＢＰａｙシステムは、支払い元法人の支払い元ユーザに管理画面導入案内を、インターネット網Ｉを介して送付する。
これにより、支払い元法人はＴｏＢＰａｙシステムによる支払い代行サービスの運用が認められる。
〔ＢＭアクワイアラ登録処理〕

図３は、図１に示した代理処理サーバ４のＢＭアクワイアラ登録部４２のデータ処理の流れを説明するチャート図である。ここで、アクワイアラとは、加盟店登録を意味する。以下、図１８～図２３に示すＵＩ画面を参照して、ＢＭアクワイアラ登録部４２によるＢＭアクワイアラ登録処理を説明する。

まず、ＴｏＢＰａｙシステムは、ＢＭ（ビジネスマイル）アクワイアラ案内を、インターネット網Ｉを介して支払い元法人宛に通知する。支払い元法人がＴｏＢＰａｙシステムから通知されたＢＭアクワイアラ案内の通知（例えば電子メール）を受信したら、支払い元法人の代表者または担当者がＢＭ申し込みフォーム（ＰＤＦファイル）に必要事項を入力し、インターネット網Ｉを介してＢＭ管理会社の管理サーバに送信する。

これを受けて、ＢＭ管理会社の管理サーバ（ＢＭ管理サーバ８）は、ＴｏＢＰａｙシステムを導入した支払い元法人の申し込みを受け付け処理する。ここで、ＢＭ管理サーバ８のマイル発行処理部８１は、ＢＭ運用者画面において、新規ユーザアカウントを発行し、ＴｏＢＰａｙシステムを導入した支払い元法人が表示するＢＭユーザ（アクワイアラ画面）に対して支払い元企業ユーザアカウントを発行すると、ＴｏＢＰａｙシステムを導入した支払い元法人に対するＢＭアカウント処理が完了する。
具体的には、ＢＭアクワイヤラ登録部４２が図１８に示すＵＩ画面を支払元ＰＣ１－１の表示装置に表示する。ここで、支払元ＰＣ１－１の操作者（クライアント）は、ログインボタン、または新規登録ボタンをクリックして、新規登録、ログイン処理へ進む。
ここで、既にＢＭ登録を完了しているクライアントは、図１９に示すＵＩ画面に対して登録されたメールアドレスを入力して承認ボタンをクリックすると、図２０に示すＵＩ画面が支払元ＰＣ１－１の操作者（クライアント）の表示装置に表示される。すると、ＢＭアクワイヤラ登録部４２は、図２０に示すＵＩ画面を支払元ＰＣ１－１に提示する。ここで、支払元ＰＣ１－１の操作者（クライアント）が画面に表示されるメッセージに従い、認証メールを受信したことを確認したら、ログイン処理が完了する。なお、認証メールを受信していない場合は、認証メールを再送してもらう再送ボタンをクリックして、同様の処理を繰り返す。
一方、図１８に示すＵＩ画面にて、クライアントが新規登録ボタンをクリックした場合、ＢＭアクワイヤラ登録部４２は、図２１に示すＵＩ画面を支払元ＰＣ１－１に提示する。図２１に示すＵＩ画面に表示された新規登録フォーマットは、一例であって、本画面以外の項目が含まれていてもよい。
クライアントは、当該ＵＩ画面に対して氏名、住所、法人情報を入力し終えたら、会員登録完了ボタンをクリックする。
そして、ＢＭアクワイヤラ登録部４２は、図２２に示すＵＩ画面を支払元ＰＣ１－１に提示する。ここで、ＴｏＢＰａｙシステムが提供するビジネスマイルに概要とそのサービス内容（マイルの獲得、マイルのシェア、マイルを使う）をクライアントに提示する。ここで、次へボタンがクリックされると、ＢＭアクワイヤラ登録部４２は、図２３に示すＵＩ画面（ビジネスマイル・マイページ画面）を支払元ＰＣ１－１に提示する。クライアントは当該画面により、マイル残高、シェア可能なマイル残高、ニュース、デジタルマイルカードの内容の確認を行うことができる。
また、図２３に示すＵＩ画面の下部側に配置される確認ボタン、使うボタン、貯めるボタン、シェアボタンが配置されている。

〔支払い先登録処理〕
図４は、図１に示した支払い元ＰＣ１－１～Ｎによる支払い先登録処理の流れを説明するチャート図である。以下、図２４、図２５に示すＵＩ画面を参照して、支払い先登録処理を詳述する。
代理処理サーバ４の支払先登録部４３は、支払い元ＰＣ１－１～Ｎに対して支払先登録の依頼メールを送信する。

ここで、支払い元ＰＣ１－１～Ｎは、ＷＥＢブラウザをｈｔｔｐｓ：登録画面を表示させ、１件ずつ支払先のアドレスや連絡先、そして自身のＢＭアカウント（アクワイヤラ登録Ｎｏ．等）を入力する。

これにより、支払先法人依頼フォームが完成するので、該支払先法人導入依頼フォーム（図２５に示すＵＩ画面）を代理処理サーバ４へ送信する。図２４に示すＵＩ画面にて、支払い先７－１～７－Ｎは、ＴｏＢＰａｙシステムへのログインまたは新規登録を催促する。ここで、登録ボタンがクリックされた場合、支払い先７－１～７－Ｎの表示装置には、図２５に示すＵＩ画面が表示されて、簡単な操作でカンパニーに参加することができる。

次に、代理処理サーバ４の支払先登録部４３は、支払い元ＰＣ１－１～Ｎから支払先法人導入依頼フォーム（ＰＤＦファイル）を受信すると、支払先登録部４３は、支払先登録フォームを発行して、該発行した支払先登録フォームを支払先法人の支払先ＰＣ７－１～ＰＣ－Ｎに送信する。

これを受けて、支払先法人の支払先ＰＣ７－１～ＰＣ－Ｎの責任者は、ＴｏＢＰａｙシステムが提案する支払いを受けるかどうかを検討し、支払先法人の支払先の責任者が提案に合意した場合、ＴｏＢＰａｙシステムが提供する申し込みフォーム（ＰＤＦファイル）に必要事項（支払いのための銀行名、支店名、口座の種類、口座番号等を含む）を入力し、該必要事項が入力された申し込みフォームを、ＴｏＢＰａｙシステムを構成する代理処理サーバ４にインターネット網Ｉを介して送信する。

これを受けて、代理処理サーバ４の支払先登録部４３は、受信した申し込みフォームを受け付け、代理処理サーバ４が提供する管理画面を発行し、ＴＰ支払い先法人画面上にＵＲＬが登録アドレスに送付される。

これにより、ＴｏＢＰａｙシステムは、発行された管理画面の導入案内を支払先ＰＣ７－１～７－Ｎのユーザに通知する。

一方、代理処理サーバ４の支払先登録部４３は、受信した申し込みフォームを受け付けた際、ＢＭ管理サーバ８は、代理処理サーバ４の支払先登録部４３より支払先登録受理の通知を受けて、ＢＭ管理サーバ８が提供するアクワイアラ画面上で、支払い元に対して、支払い先の登録が完了した旨を示す登録完了通知を行い、該発行された支払い先の登録が完了した旨を示す登録完了通知を、インターネット網Ｉを介して、支払い元ＰＣ１－１～１－Ｎのいずれかにメールで通知する。

支払い元ＰＣ１－１～１－Ｎのいずれかが、当該支払い先の登録が完了した旨を示す登録完了通知をＢＭ管理サーバ８のマイル発行処理部８１から受信したら、支払先の登録処理が完了する。

〔第１の請求書アップロード処理〕
図５は、図１に示した支払い先ＰＣ７－１～７－Ｎによる請求書アップロード処理の流れを説明するチャート図である。以下、図２６～図３１に示すＵＩ画面を参照しながら、請求書アップロード処理を詳述する。

代理処理サーバ４の請求書アップロード部４４は、支払い先ＰＣ７－１～７－Ｎの経理担当者が、ＴｏＢＰａｙシステムが提供するＷＥＢ画面に対して、あらかじめ設定された締め日に従い、支払い元の法人に当月支払っていただく請求書に従う請求データを受け付けて処理する。

具体的には、支払い先ＰＣ７－１～７－Ｎを操作する支払先ユーザが支払い元に対する請求書の発行を行う際、ＴｏＢＰａｙシステムが提供するＷＥＢページ（アップロードページ）に必要な請求項目（請求元を指定するコード、請求明細、請求総額を含む）を入力して、支払い先ＰＣ７－１～７－Ｎの表示装置に、例えば図２６に示すＵＩ画面を表示する。＋ボタンをクリックすると、請求カテゴリ情報入力画面として、支払い先ＰＣ７－１～７－Ｎの表示装置に、例えば図２７に示すＵＩ画面を表示する。ここで、取引先に付与された編集ボタンをクリックすると、支払い先ＰＣ７－１～７－Ｎの表示装置に、例えば図２８に示す請求書情報を入力するためのＵＩ画面を表示する。ここで、支払い先ＰＣ７－１～７－Ｎの担当者は、図２８に示すＵＩ画面に対して、請求日、支払い期限、発注社名、取引先名、取引き担当者名、件名、請求金額（税抜）、備考等に必要な情報を入力することができる。
次に、支払い先ＰＣ７－１～７－Ｎの担当者は、図２７に示すＵＩ画面に戻り、取引先の追加ボタンをクリックすると、支払い先ＰＣ７－１～７－Ｎの表示装置に、図２９に示すＵＩ画面を表示する。ここで、保存ボタンを指示すると、請求書アップロード部４４は、支払い先ユーザが入力した指定される請求元に対する請求項目が記載された請求書データ（ＰＤＦファイル）を受領する。

これを受けて、請求書アップロード部４４は、支払先ユーザからアップロードされた請求書を受領した旨をＴＰ支払い元法人画面およびＴＰ運用者画面に通知する。

一方、別のアップロードによる場合、支払い先ＰＣ７－１～７－Ｎの支払い先ユーザは、インターネット網Ｉを介して支払い元ＰＣ１－１～１－Ｎのいずれかの支払い元ユーザに請求書データを発行する。

これを支払い元ＰＣ１－１～１－Ｎのいずれかの支払い元ユーザが受け取ると、請求書データ（ＰＤＦファイル）を承認して、インターネット網Ｉを介して代理処理サーバ４の請求書アップロード部４４に対してアップロードする。

これにより、代理処理サーバ４の請求書アップロード部４４は、支払先ＰＣ７－１～７－ＮのＴＰ支払い先法人画面に請求書の登録した旨を通知するとともに、ＴＰ運用者画面に請求書の登録を通知するとともに、ＴＰ支払い先法人画面に請求書の登録通知を行う。

これを受けて、支払い先ＰＣ７－１～７－Ｎのいずれかの支払い先ユーザに対して、ＴＰ支払い先法人画面を介して請求書確認を依頼し、その内容についての承認指示を待つ。なお、ＴＰ支払い先法人画面上には、アップロードされた請求書を承認するための承認ボタンが用意されている。ここで、承認ボタンは、承認者が複数存在する場合に適応するため、上長に対応する支払先ユーザが最終承認を行う場合がある。
なお、図３０に示すＵＩ画面では、支払い元のＰＣにおいて、請求書情報の詳細画面を表示した状態を示した。また、図３１に示すＵＩ画面では、登録された請求書であって、１つのプロジェクトに毎に、タブが割り当てられて、現在ＴＢＰ初期開発に係る請求書の一覧を表示した状態に対応する。また、図３２、図３３に示すＵＩ画面では、決済状態と、決済完了を確認できるように構成されている。
また、図３４、図３５に示すＵＩ画面では、登録された「〇〇〇〇プロジェクト」に関する請求書であって、支払い状態、振込状態を確認できるように構成されている。

〔支払先への代理支払い処理〕
図６は、図１に示した代理処理サーバ４の支払い先への代理支払部４５による処理の流れを説明するチャート図である。

図５に示した請求書アップロード処理において、支払い先ユーザが請求書確認および承認が完了した旨の通知を代理処理サーバ４の支払い先への代理支払部４５が受信したら、請求書に記載された支払い情報を受け付けて、受け付けた支払い情報に基づいて、ＴＰ運用者画面上に支払い情報を更新して表示する。

次に、ＴＰ運用者画面上で更新された支払い情報に基づいて、支払先に請求額を支払う。ここで、支払い情報に基づく支払いとは、ＴｏＢＰａｙシステムが契約している代行銀行５を介して、支払先が指定する銀行５１－１～５１－Ｎのいずれかに振り込む処理を意味する。

このようにして、支払い先への代理支払部４５が支払い先に支払いを完了したら、振込確定通知をＴＰ運用者画面上に送信すると、ＴＰ運用者画面に振り込み完了を表示させるとともに、ＴＰ運用者画面の内容を更新して、その内容をＴＰ支払い先法人画面に反映する。

これにより、支払い先ＰＣ７－１～７－Ｎが振り込み完了を受信すると、支払い先ＰＣ７－１～７－Ｎが備える表示装置が表示するＴＰ支払い先法人画面上に振り込み完了を表示する。ここで、支払い先ＰＣ７－１～７－Ｎを操作する支払い先ユーザは、上記ＴＰ支払い先法人画面を介して、ＴｏＢＰａｙシステムによる代行振込が完了したことを確認し、表示された画面の情報を更新する指示を行う。
これを受けて、代理処理サーバ４の表示装置に表示するＴＰ支払い先法人画面に１つの請求に対する支払い代行が完了した旨を示すように情報を更新する。

これにより、代理処理サーバ４の表示装置は、ＴＰ支払い先法人画面上で１つの請求の情報を支払完了に更新する。同様に、支払い先ＰＣ７－１～７－Ｎが備える表示装置に表示するＴＰ支払い先法人画面上の情報を支払完了に更新する。

〔支払い元への請求処理〕
図７は、図１に示した代理処理サーバ４の支払い元への請求処理部４６による処理の流れを説明するチャート図である。
図６に示した支払い先への代理支払部４５が支払い情報更新を行うと、ＴｏＢＰａｙシステムの支払い元への請求処理部４６による処理を開始する。

まず、支払い元への請求処理部４６は支払い完了通知を受けて、代行して振り込んだ金額の支払いを支払元ＰＣ１－１～１－Ｎのいずれかに請求処理を行う。これにより、代理処理サーバ４の表示装置が表示するＴＰ支払い元法人画面に請求情報を通知する。

このようにし、支払元ＰＣ１－１～１－Ｎの支払元ユーザが支払い元への請求処理部４６による請求を受領すると、ＴｏＢＰａｙシステムが指定する代行銀行５に指定される口座に請求額を振込により支払う。ＴｏＢＰａｙシステムが支払元ＰＣ１－１～１－Ｎの支払元ユーザによる振り込みを確認したら、支払い元への請求処理部４６は、ＴＰ運用者画面の支払い元法人に対応する支払い経過を示す情報を入金確認に更新し、ＴＰ支払い元法人画面の支払い状態を示す情報を取引完了に更新する。

〔マイル発行処理〕
図８は、図１に示した代理処理サーバ４のマイル発行処理部８１による処理の流れを説明するチャート図である。

図７に示した支払元ユーザが支払い元への請求処理部４６がＴＰ支払い元法人画面を取引完了に更新したら、ＢＭ管理サーバ８のマイル発行処理部８１が処理を開始する。

マイル発行処理部８１は、図示しないマイル管理テーブルを参照して、支払いが完了した支払い元の法人に設定したマイル付与情報を連系情報に基づいて読み出し、今回の支払いに対するマイル数を確認して、ＢＭ運用者画面上で付与するマイル数を承認する指示を行う。

これにより、マイル発行処理部８１は、ＢＭユーザのアクワイアラ画面に上記承認したマイル数を現在のマイル数に付加付与する。
これに従い、支払い元法人の支払い元ユーザは、法人ログイン画面を介して今回の支払いで付与されたマイル数を受信したことを確認できる。

〔マイル発行処理〕
図９は、図１に示した代理処理サーバ４のマイル交換処理部８２による処理の流れを説明するチャート図である。以下、図３６、図３７に示すＵＩ画面を参照してマイル発行処理について説明する。

支払い元法人の支払い元ユーザは、管理画面からＢＭ管理サーバ８にログインすると、マイル数確認画面を表示する。ここで、支払い元法人の支払い元ユーザは、現在のマイル数を確認することができる。
そして、マイル数が適切な交換ポイント数に到達していると判断した場合、現在のマイル数を商品購入等への交換指示を入力することができる。

そして、ＢＭ管理サーバ８のマイル交換処理部８２は、交換指示されたポイントに基づいて、直前の総ポイント数から交換指示されたポイントを差し引いて交換処理を完了する。

次に、ＢＭ管理サーバ８のマイル交換処理部８２は、直前の総ポイント数から交換指示されたポイントを差し引いたポイント残高（図３７に示すＵＩ画面参照）を、インターネット網Ｉを介して支払い元ＰＣ１－１～１－Ｎのいずれかの法人の支払い元ユーザに交換指示の内容と、ポイント残高を通知して処理（図３６に示すUI画面参照）を終了する。

〔第１実施形態の効果〕
第１実施形態によれば、ＴｏＢＰａｙシステムを利用する支払い元の法人は、代行支払い額に適応したビジネスマイル（ポイント）を受け取ることができ、加算されるビジネスマイルを活用して、商品購入の資金、旅行代金の資金当に充当することができる。

なお、ビジネスマイルは、後述するＴｏＢＰａｙシステムを利用した際に支払う手数料に充当することもできる。

〔第２実施形態〕
図１０は、本実施形態を示す電子決済代行業務システムにおける手数料支払い処理を説明するフローチャートである。なお、（１）～（１９）は各ステップを示す。なお、本処理は、ＴｏＢＰａｙシステムの契約担当者と、支払い元（法人）との支払い代行契約が成立した後に開始される処理である。

また、各ステップは、代理処理サーバ４のコントローラ部のＣＰＵがメモリ部に記憶されたＴｏＢＰａｙシステムプログラムを読み出して実行することにより実現される。また、ＴｏＢＰａｙシステムプログラムは、規約改定や税率の改定等に備えて随時バージョンが更新される構成を採用している。

まず、ＴｏＢＰａｙシステムを構成する代理処理サーバ４が支払い元ＰＣ１－１～１－Ｎのいずれかから登録要求を受け付けたら（１）、当該支払い元ＰＣ１－１～１－Ｎの経理担当者が毎月支払う取引方となるいずれかの支払い先ＰＣ７－１～７－Ｎから、ＴｏＢＰａｙシステムによる支払い先からの承認を受けると（２）、すべての登録（Ｋ＝Ｎ）が完了したかどうかを判断する（３）。

ここで、すべての登録が完了していると判断した場合、例えば支払い元ＰＣ１－１を操作する法人様Ａの経理担当者から締め日に合わせて請求されている請求書情報をＴｏＢＰａｙシステムにアップロードする（４）。

次に、本日が処理中の法人様Ａの支払い締め日に該当するかどうかを判断する（５）。ここで、本日が支払い締め日でないと判断した場合は、ステップ（３）へ戻り、本日が支払い締め日であると判断した場合は、ＴｏＢＰａｙシステムがまとめた支払い確認書を支払元に対応する支払い元ＰＣ１－１～１－Ｎのいずれかに通知し、その法人様の経理担当者からの承認を受領したかどうかを判断する（６）。

次に、ＴｏＢＰａｙシステムは、支払い契約条件を参照して、支払い元との代行支払い条件が条件１（代行支払いに対する手数料を支払い元と、支払い先でシェアする場合）であるかどうかを判断する（７）。

ここで、ＴｏＢＰａｙシステムが支払い元との代行支払い条件が条件１であると判断した場合、ステップ（８）へ進み、ＴｏＢＰａｙシステムは、支払い元ＰＣ１－１～１－Ｎのいずれかから支払い確認書に対する承認指示を受信するのを待ち、支払い元ＰＣ１－１～１－Ｎのいずれかから支払い確認書に対する承認指示を受信したら、ＴｏＢＰａｙシステムは、支払い確認書と、ＴｏＢＰａｙシステムとの契約時に登録された支払い先と照合して、支払い先が指定するそれぞれの銀行口座宛に振り込みを行う。

次に、ＴｏＢＰａｙシステムは、支払い確認書に基づく代行支払いが完了した旨を支払元ＰＣ１－１～１－Ｎのいずれかに通知する（９）。
これにより、契約者である法人様毎に月単位での代行支払いが完了するため、法人様の経理担当者による振り込み処理負担が大幅に軽減できる。

一方、ステップ（７）において、支払い元との代行支払い条件が条件２（代行支払いに対する手数料を支払い元が負担する場合）であると判断した場合は、ステップ（１０）へ進む。

ステップ（１０）で、ＴｏＢＰａｙシステムがまとめた支払い確認書を支払元に対応する支払い元ＰＣ１－１～１－Ｎのいずれかに通知し、その法人様の経理担当者からの承認を受領したかどうかを判断する。

ここで、支払い元ＰＣ１－１～１－Ｎのいずれかから支払い確認書に対する承認指示を受信したら、ＴｏＢＰａｙシステムは、支払い確認書と、ＴｏＢＰａｙシステムとの契約時に登録された支払い先と照合して、支払い先が指定するそれぞれの銀行口座宛に振り込みを行う（１１）。

次に、ＴｏＢＰａｙシステムは、今回の支払いに伴う手数料の請求条件をメモリ部から読み出し（１２）、支払い元と、支払い先との手数料の負担率が１００％：０％であるかどうかを判断する（１３）。

ここで、ＴｏＢＰａｙシステムは、支払い元と、支払い先との手数料の負担率が１００％：０％であると判断した場合、ＴｏＢＰａｙシステムは、今回の代行支払いに対する手数料を算出して、支払い元ＰＣ１－１～１－Ｎのいずれかに請求書を送付する（１４）。そして、支払い元ＰＣ１－１～１－Ｎのいずれかから手数料納付の確認がとれたら（１９）、本処理を終了する。

一方、ステップ（１３）で、ＴｏＢＰａｙシステムは、支払い先との手数料の負担率が１００％：０％でないと判断した場合、さらに、ＴｏＢＰａｙシステムは、支払い元と、支払い先との手数料の負担率が５０％：５０％であるかどうかを判断する（１５）。

ここで、支払い元と、支払い先との手数料の負担率が５０％：５０％であると判断した場合、今回の支払い総額に対する手数料を算出し、支払い元と、支払い先とのそれぞれに請求する手数料を算出して、支払い請求書を送付する（１８）。次に、ステップ（１９）へ進む。

一方、ステップ（１５）で、ＴｏＢＰａｙシステムは、支払い元と、支払い先との手数料の負担率が５０％：５０％でないと判断した場合、メモリ部に登録された手数料の負担割合を読み出し、支払い先とのそれぞれに請求する手数料を算出して（１６）、支払い元と、支払い先とに割合に従う手数料の支払い請求書を送付する（１７）。そして、ステップ（１９）へ進む。

これにより、ＴｏＢＰａｙシステムを利用する支払い元と、支払い先とが代行手数料をシェアすることで、ＴｏＢＰａｙシステムが提供するマイルを支払い元と、支払い先との双方に付与することができる。これにより、ＴｏＢＰａｙシステムを利用する法人が増えることで、法人の経理担当者の規模を縮小して、法人自体の支出を削減できる。
また、支払い先との双方は、ＴｏＢＰａｙシステムを活用することで、それぞれマイルが付与されて積算されて行く。

なお、マイルについて、ＴｏＢＰａｙシステムと契約する法人は、契約時にマイル付与に代えて、または適時組み合わせて、マイル還元よりも法人に対するキャッシュバックを優先させて処理する構成としてもよい。

また、代行支払いに伴う手数料は、ＴｏＢＰａｙシステムが指定する条件（指定業者の商談を受けるとか、指定業者のサービスを導入する等）を満たす場合には、個別的に手数料を通常よりも下げるようにシステムを構成してもよい。

本実施形態においては、代理処理サーバ４が代理支払いを実行した際、ＴｏＢＰａｙシステムを利用した代理支払いに対する手数料を計算するステップを実行する（１６）。

その際、代理処理サーバ４が計算した手数料を前記支払い元となる第１データ端末または支払い先に対応する第２データ端末に対して分担請求を通知する（１７）。

これに対して、代理処理サーバ４は、代理支払いに対する手数料を支払い元にすべて負担させるように計算する場合もある。

その場合には、代理処理サーバ４が計算した手数料の請求を第１データ端末に対して通知する。

また、本実施形態では、代理処理サーバ４があらかじめ設定された分担比率（図１０に示すステップ（１３）～（１５）参照）に基づいて分担請求する支払い元となる第１データ端末または支払い先に対応する第２データ端末に対する手数料を計算する場合にも柔軟に適用可能に構成されている。

〔第２実施形態の効果〕
第２実施形態によれば、ＴｏＢＰａｙシステムに対して支払う代行支払い手数料の負担を支払元としたり、支払い元と、支払い先とでシェアしたりする支払い環境を構築し、ＴｏＢＰａｙシステムを利用する支払い元と、支払い先の利便性を高めることができる。

〔第３実施形態〕
図１１は、本実施形態を示す電子決済代行業務システムにおける手数料支払い処理を説明するフローチャートである。なお、（２１）～は各ステップを示す。なお、本処理は、ＴｏＢＰａｙシステムの契約担当者と、支払い元（法人）との支払い代行契約が成立した後に開始される処理である。また、各ステップは、代理処理サーバ４のコントローラ部のＣＰＵがメモリ部に記憶されたＴｏＢＰａｙシステムプログラムを読み出して実行することにより実現される。

まず、ＴｏＢＰａｙシステムは支払い元との契約に基づき、月単位の締め日に合わせて、支払い元からアップロードされた請求書を分析して、支払い元が支払い先に支払う額の総額を算出する（２１）。

次に、代理処理サーバ４にインストールされたＴｏＢＰａｙシステムは、代行支払いに関する支払い元と、ＴｏＢＰａｙシステムとの契約条件が代行支払い条件１（支払い元からＴｏＢＰａｙシステムへの代行支払い額の振込前に、ＴｏＢＰａｙシステムが支払い元からの入金を待たずに、支払い先に先行して支払いを行う立替支払いとする条件）であるかどうかを判断する（２２）。

ここで、ＴｏＢＰａｙシステムが代行支払い条件１であると判断した場合、ＴｏＢＰａｙシステムが代行支払い計算書を支払い元となる支払い元ＰＣ１－１～１－Ｎのいずれかにインターネット網Ｉを介して送付する（２３）。

次に、ＴｏＢＰａｙシステムは、支払い元が送付した代行支払い計算書を承認する指示を待ち（２４）、支払い元が送付した代行支払い計算書を承認する指示を受けたら、ＴｏＢＰａｙシステムが管理する代行銀行５から登録された支払い先が指定する銀行の指定口座宛に立替送金（先払い送金）を行う（２５）。

次に、ＴｏＢＰａｙシステムは、立替支払いを実行した支払い元に対して、立替総額の支払い請求を通知して（２６）、当該支払い元が、ＴｏＢＰａｙシステムが指定する代行銀行５の指定口座への入金を確認したら（２７）、ＴｏＢＰａｙシステムは、メモリ部で管理する支払い元台帳に、今回の支払いの詳細を記帳して、支払い元情報を更新して（２８）、たら、本処理を終了する。

一方、ステップ（２２）で、ＴｏＢＰａｙシステムが代行支払い条件１でないと判断した場合、ＴｏＢＰａｙシステムが代行支払い計算書を支払い元となる支払い元ＰＣ１－１～１－Ｎのいずれかにインターネット網Ｉを介して送付する（２９）。支払い元よりＴｏＢＰａｙシステムが指定する代行銀行５に計算書に記載した支払額の総額が振り込まれるのを確認したら（３０）、ステップ（２６）へ進む。

これにより、支払い元法人の経理担当者は、ＴｏＢＰａｙシステムの利用実績に応じて、通常、ステップ（２９）により代行支払い額の総額をＴｏＢＰａｙシステムの代行銀行５に先払いする先払い方式と、ステップ（２５）により代行支払い額の総額をＴｏＢＰａｙシステムが立て替えて支払う立替払い方式のいずれかを選択することができる。

このように電子決済代行業務システムは、ＴｏＢＰａｙシステムと契約する支払い元ユーザ（法人）と、支払い先ユーザ（法人）との間における決済業務において、支払い元には個別的で厄介な支払い業務から解放し、１回のおまとめ支払いで決済を完了できる。

一方、支払い先は、上述したように、ＴｏＢＰａｙシステムを利用する手数料を支払い元と分担することで、ビジネスマイルとしてのポイントを取得することができる。

〔第３実施形態の効果〕
第３実施形態によれば、従来の電子決済業務とは革新的な手法で法人支払いを行うことができ、支払い元における人件費の大幅な削減が期待できる。

〔第４実施形態〕
上記実施形態では、法人間（ＢｔｏＢ）の支払い業務について詳細に説明したが、ＴｏＢＰａｙシステムにファクタリング機能（売掛債権買取業務機能）を付加してシステムを拡張してもよい。

〔第５実施形態〕
図３８～図４３は、本実施形態を示す電子決済代行業務システムにおけるＢＭ処理のＵＩ画面の一例を示す図である。なお、各ＢＭＵＩ画面は、支払い元、支払い先のいずれでも表示可能である。

図８に示したマイル発行処理において、支払い元ＰＣ、支払い先ＰＣにおいてＢＭ登録された利用者は、ＢＭ管理サーバ８からオンデマンドあるいは定期的にお知らせの通知（図３８、図４３に示すＵＩ画面表示）を受信する。

本実施形態では、マイページ、確認、使う、貯める、シェアの各タブが設定されているため、いずれかのタブを選択することでマイル発行処理部８１と、マイル交換処理部８２とが協働してＢＭ処理を行う。

ここで、支払い元ＰＣまたは支払い先ＰＣの各利用者がマイルを使うタブが選択されると、図３９に示すＵＩ画面が支払い元ＰＣまたは支払い先ＰＣの表示装置に表示される。本例は、支払い元ＰＣまたは支払い先ＰＣの各利用者が貯め込んだマイルを、ショッピングサイト、例えばａｍａｚｏｎ（登録商標）で利用できるギフト券に交換する操作例である。

この画面表示の内容で、次へ進むボタンをクリックすると、マイル交換処理部８２は、支払い元ＰＣまたは支払い先ＰＣの表示装置のＵＩ画面の内容が図４０に示すＵＩ画面に切り替わるように制御する。

ここで、上記ギフト券を発行することにより、現在のマイル状況が更新されることを確認することができる。さらに、次へ進むボタンをクリックすると、マイル交換処理部８２は、支払い元ＰＣまたは支払い先ＰＣの表示装置のＵＩ画面の内容が図４１に示すＵＩ画面に切り替わるように制御する。

ここで、支払い元ＰＣまたは支払い先ＰＣの各利用者が表示された交換契約を承認するため、申し込むボタンをクリックすると、マイル交換処理部８２は、支払い元ＰＣまたは支払い先ＰＣの表示装置のＵＩ画面の内容が図４２に示すＵＩ画面に切り替わるように制御する。

〔第６実施形態〕
上記第１実施形態では、代理処理サーバ４が支払元ＰＣと、支払先ＰＣとの請求処理を代行処理する際に、図５に示す請求書アップロード処理、図６に示す支払い先への代理支払い処理、図７に示す支払い元への請求処理を時系列で処理する場合、支払元ＰＣの担当者（経理担当者）は、例えば月締めの特定日までに請求書アップロード処理を繰り替えした場合、その都度、図５に示した請求書確認とその承認処理を繰り返す操作が発生していたため、支払先への代行支払い指示を１回の承認で処理できないという課題が指摘されていた。

そこで、支払元ＰＣにおける支払い承認回数を毎月１回の承認で支払い先へ代行支払いが完了するように構成してもよい。

〔第２の請求書アップロード処理〕
図４４、図４５は、１に示した代理処理サーバによるワンタップ処理の流れを説明するチャート図である。なお、本システムにおいて、請求書を登録する方法には、（１）請求書情報の登録、（２）請求書のアップロードによるＯＣＲ（画像認識による自動登録）、（３）専用アドレスに請求書ＰＤＦ送付によって、自動で請求情報の読み取りによる登録のいずれにも対応可能に構成されている。また、請求書データが複数ある場合は、（１）それぞれ個別に「承認」、「否認」をシステムに設定することができる。また、（２）個別は面倒となる場合に備えて、まとめて「承認」、「否認」をシステムに設定することもできる。
上記（１）、（２）のいずれの場合も、指定する方法（ＬＩＮＥ（登録商標）等のチャットまたはメール）で通知が届き、そこで「承認」を１タップするだけで、銀行の自動引き落としを行う構成が第２の請求書アップロード処理の特徴である。
図１に示した支払い先ＰＣ７－１～７－Ｎによる請求書アップロード処理の流の発行を行う際、ＴｏＢＰａｙシステムが提供するＷＥＢページ（アップロードページ）に必要な請求項目（請求元を指定するコード、請求明細、請求総額を含む）を入力して、支払い先ＰＣ７－１～７－Ｎの表示装置に、例えば図２６に示すＵＩ画面を表示する。＋ボタンをクリックすると、請求カテゴリ情報入力画面として、支払い先ＰＣ７－１～７－Ｎの表示装置に、例えば図２７に示すＵＩ画面を表示する。ここで、取引先に付与された編集ボタンをクリックすると、支払い先ＰＣ７－１～７－Ｎの表示装置に、例えば図２８に示す請求書情報を入力するためのＵＩ画面を表示する。

ここで、支払い先ＰＣ７－１～７－Ｎの担当者は、図２８に示すＵＩ画面に対して、請求日、支払い期限、発注社名、取引先名、取引き担当者名、件名、請求金額（税抜）、備考等に必要な情報を入力することができる。

次に、支払い先ＰＣ７－１～７－Ｎの担当者は、図２７に示すＵＩ画面に戻り、取引先の追加ボタンをクリックすると、支払い先ＰＣ７－１～７－Ｎの表示装置に、図２９に示すＵＩ画面を表示する。ここで、保存ボタンを指示すると、請求書アップロード部４４は、支払い先ユーザが入力した指定される請求元に対する請求項目が記載された請求書データ（ＰＤＦファイル）を受領する。

この作業を月締め予定日まで繰り返し、請求書アップロード部４４は、支払先ユーザからアップロードされたすべての請求書を受領した旨をＴＰ支払い元法人画面およびＴＰ運用者画面に１回通知する。

同様に、別のアップロードによる場合、支払い先ＰＣ７－１～７－Ｎの支払い先ユーザは、インターネット網Ｉを介して支払い元ＰＣ１－１～１－Ｎのいずれかの支払い元ユーザに請求書データを発行する。

これらの各支払い先からの個別的な請求をすべて集計した後、その集計額に対する承認を求める請求書データを支払い元ＰＣ１－１～１－Ｎのいずれかの支払い元ユーザが受け取ると、１つの請求書データ（ＰＤＦファイル）を１タップ処理で承認すると、図４４に示した支払い先への代理支払いが指示され、これを代理処理サーバ４が受領すると、図４５に示すように、代理処理サーバ４が１タップ承認された支払い情報に基づき支払いが上述した代行ＢＫ５を介して実行される。

以後、第１実施形態とは請求書の流れが逆転し、支払先に対する代行支払いが完了した後、図４４に示すように、支払先が通知されている各請求書の情報をネットワークＩを介して支払い元ＰＣに対して送付する処理が実行される。これにより、事後承認的に、月締めされた各支払い先からアップロードされた支払先毎の請求書の詳細を受け取ることができる。

ここで、第２の請求書アップロード処理におけるデータ処理の一連の流れについて一例を示して詳述する。
支払先によって、メールまたはアップロードまたは情報入力により、請求書データがシステムに登録される（１）。
次に、ＴｏＢＰａｙ側が支払先によって登録された請求書データをまとめ請求情報化する（２）。次に、支払元のユーザに対して、ステップ（２）に請求情報を主にＬＩＮＥ（登録商標）またはメールで通知を行う（３）。これにより、支払元のユーザは、詳細の請求書情報も確認することができる。
次に、支払元ユーザは、ＬＩＮＥ（登録商標）またはメールで通知された請求情報を承認するか否認するかを決定する操作指示を行う（４）。ここで、支払元ユーザが承認することを決定する操作指示を行った場合、自動引き落とし申請がかかる。
次に、ＴｏＢＰａｙによる支払先への代理支払が行われ、そして支払元からＴｏＢＰａｙへの自動引き落としが完了する（５）。取引終了後、支払元・支払先双方は、システムに接続することで、利用明細にて、どの会社にいくら支払われたのか（支払があったのか）を画面上で確認する（６）。
このように第２の請求書アップロード処理によるＴｏＢＰａｙによる支払によれば、支払元ユーザのＰＣ操作だけでなく、スマートフォン操作（通知をワンタップするだけでＯＫ）で支払い指示が完了できる。よって、支払元のユーザは、ＰＣによって支払い操作を行うこともできるとともに、出先においては、スマートフォン操作にて支払い指示を完了することができ、操作性が格段に向上する。
さらに、ＴｏＢＰａｙ利用ユーザの作業軽減としては、（１）請求書の取りまとめ、（２）請求書から振込データ作成、（３）振込作業、（４）消込、（５）仕訳、（６）（２）～（５）の確認などが不要になり、大幅に業務工数削減となる。
また、支払先も、これまで郵送だった支払い業務そのものが電子化されることで大幅に工数削減となる。

〔第６実施形態の効果〕
第６実施形態により、支払元ＰＣにおける支払い承認回数を毎月１回の承認で支払い先へ代行支払いが完了することができ、支払元ＰＣを操作する担当者の各支払い先からアップロードされた請求書に対する承認作業を大幅に軽減することができる。

本発明の各工程は、ネットワーク又は各種記憶媒体を介して取得したソフトウエア（プログラム）をパソコン（コンピュータ）等の処理装置（ＣＰＵ、プロセッサ）にて実行することでも実現できる。

本発明は上記実施形態に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施形態の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。

例えば医療機関において、ＴｏＢＰａｙシステムを導入すると、治療のための医薬品購入費、医療設備の購入費、消耗品費等の細かい支出に際し、毎月末や指定日に取引先登録や請求業務、支払い業務がすべてなくなり、大幅な工数ダウンが期待できる。

さらに、介護・福祉事業者において、ＴｏＢＰａｙシステムを導入すると、施設で提供する給食費、備品購入のための介護用品費、設備導入費、事務業務で発生する印刷費等の支出に際し、請求・支払い金額の合計額や、個別の出費構成比が一目で理解できる環境を整備できる。

以上の記載した本発明に関する開示は、少なくとも下記事項に要約することができる。
（１）支払い元の経理処理を行う複数の第１データ端末と、支払い先の経理処理を行う複数の第２データ端末と、支払い処理を実行する銀行システムと、各法人間の請求と支払いの業務を実行する代理処理サーバとが通信して支払い代行サービスを行う電子決済代行業務システムであって、前記代理処理サーバは、支払い元のいずれかの第１データ端末からアップロードされる支払先が同一となる複数の請求書データを解析して支払い総額を支払先ごとに算出する算出手段と、前記算出手段が支払先ごとに算出した支払い計算書データをまとめた支払い計算書データを支払い元のいずれかの第１データ端末に送信する送信手段と、前記支払い計算書データに対する支払い認証を支払い元のいずれかの第１データ端末から受領することに応じて、支払い元のデータ端末から登録された支払い先情報に従う支払い銀行口座に対して前記銀行システムを介して代理支払いを実行する代理支払い手段と、前記代理支払い手段が実行した代理支払い額データに基づく支払い完了をいずれかの第１データ端末に通知する通知手段と、を備え、前記第１データ端末は、前記送信手段が提示する異なる支払先が混在するまとめた支払い計算書データを一括して支払うための１タップ承認画面を表示する承認画面表示手段を備え、前記第１データ端末から前記１タップ承認画面に対する１タップ承認指示を受けた後、前記代理支払い手段は、支払い元のデータ端末から登録された支払い先情報に従うそれぞれ異なる支払い銀行口座に対して前記銀行システムを介して代理支払いを実行することを特徴とする。

（２）前記代理処理サーバは、前記代理支払い手段が実行した代理支払いに対する手数料を計算する計算手段と、前記計算手段が計算した手数料を前記支払い元となる第１データ端末または前記支払い先に対応する第２データ端末に対して分担請求を通知する第１の手数料通知手段と、を備えることを特徴とする。

（３）前記代理処理サーバは、前記代理支払い手段が実行した代理支払いに対する手数料を計算する計算手段と、前記計算手段が計算した手数料の請求を前記支払い元となる第１データ端末に対して通知する第２の手数料通知手段と、を備えることを特徴とする。

（４）前記計算手段は、あらかじめ設定された分担比率に基づいて分担請求する前記支払い元となる第１データ端末または前記支払い先に対応する第２データ端末に対する手数料を計算することを特徴とする。

（５）前記代理処理サーバは、ビジネスマイル数を記憶するビジネスマイル記憶手段と、前記第１データ端末の支払い額に応じたビジネスマイルを支払元となる法人宛に発行するマイル発行処理手段と、前記第１データ端末からの指示に従い、所要の支払いに充当するビジネスマイル数と交換するマイル交換処理手段と、を備えるビジネスマイル管理サーバと、と通信することを特徴とする。

（６）前記第１データ端末は、前記送信手段が提示する異なる支払先が混在するまとめた支払い計算書データを一括して支払うか、同一の支払先ごとに個別に支払うかをあらかじめ前記代理支払い手段に設定可能とすることを特徴とする。

（７）支払い元の経理処理を行う複数の第１データ端末と、支払い先の経理処理を行う複数の第２データ端末と、支払い処理を実行する銀行システムと、各法人間の請求と支払いの業務を実行する代理処理サーバとが通信して支払い代行サービスを行う電子決済代行業務システムの決済代行処理方法であって、前記代理処理サーバは、支払い元のいずれかの第１データ端末からアップロードされる支払先が同一となる複数の請求書データを解析して支払い総額を支払先ごとに算出する算出ステップと、前記算出ステップが支払先ごとに算出した支払い計算書データをまとめた支払い計算書データを支払い元のいずれかの第１データ端末に送信する送信ステップと、前記支払い計算書データに対する支払い認証を支払い元のいずれかの第１データ端末から受領することに応じて、支払い元のデータ端末から登録された支払い先情報に従う支払い銀行口座に対して前記銀行システムを介して代理支払いを実行する代理支払いステップと、前記代理支払いステップが実行した代理支払い額データに基づく支払い完了をいずれかの第１データ端末に通知する通知ステップと、を備え、前記第１データ端末は、前記送信ステップが提示する異なる支払先が混在するまとめた支払い計算書データを一括して支払うための１タップ承認画面を表示する承認画面表示ステップを備え、前記第１データ端末から前記１タップ承認画面に対する１タップ承認指示を受けた後、前記代理支払いステップは、支払い元のデータ端末から登録された支払い先情報に従うそれぞれ異なる支払い銀行口座に対して前記銀行システムを介して代理支払いを実行することを特徴とする。

１－１～１－Ｎ 支払い元ＰＣ
４ 代理処理サーバ
５ 代行銀行
７－１～７－Ｎ 支払い先ＰＣ
８ ＢＭ管理サーバ

Claims (7)

1. 支払い元の経理処理を行う複数の第１データ端末と、支払い先の経理処理を行う複数の第２データ端末と、支払い処理を実行する銀行システムと、各法人間の請求と支払いの業務を実行する代理処理サーバとが通信して支払い代行サービスを行う電子決済代行業務システムであって、
   前記代理処理サーバは、
   支払い元のいずれかの第１データ端末からアップロードされる支払先が同一となる複数の請求書データを解析して支払い総額を支払先ごとに算出する算出手段と、
   前記算出手段が支払先ごとに算出した支払い計算書データをまとめた支払い計算書データを支払い元のいずれかの第１データ端末に送信する送信手段と、
   前記支払い計算書データに対する支払い認証を支払い元のいずれかの第１データ端末から受領することに応じて、支払い元のデータ端末から登録された支払い先情報に従う支払い銀行口座に対して前記銀行システムを介して代理支払いを実行する代理支払い手段と、
   前記代理支払い手段が実行した代理支払い額データに基づく支払い完了をいずれかの第１データ端末に通知する通知手段と、を備え、
   前記第１データ端末は、前記送信手段が提示する異なる支払先が混在するまとめた支払い計算書データを一括して支払うための１タップ承認画面を表示する承認画面表示手段を備え、前記第１データ端末から前記１タップ承認画面に対する１タップ承認指示を受けた後、前記代理支払い手段は、支払い元のデータ端末から登録された支払い先情報に従うそれぞれ異なる支払い銀行口座に対して前記銀行システムを介して代理支払いを実行することを特徴とする電子決済代行業務システム。
2. 前記代理処理サーバは、前記代理支払い手段が実行した代理支払いに対する手数料を計算する計算手段と、
   前記計算手段が計算した手数料を前記支払い元となる第１データ端末または前記支払い先に対応する第２データ端末に対して分担請求を通知する第１の手数料通知手段と、
   を備えることを特徴とする請求項１に記載の電子決済代行業務システム。
3. 前記代理処理サーバは、前記代理支払い手段が実行した代理支払いに対する手数料を計算する計算手段と、
   前記計算手段が計算した手数料の請求を前記支払い元となる第１データ端末に対して通知する第２の手数料通知手段と、
   を備えることを特徴とする請求項１に記載の電子決済代行業務システム。
4. 前記計算手段は、あらかじめ設定された分担比率に基づいて分担請求する前記支払い元となる第１データ端末または前記支払い先に対応する第２データ端末に対する手数料を計算することを特徴とする請求項２に記載の電子決済代行業務システム。
5. 前記代理処理サーバは、
   ビジネスマイル数を記憶するビジネスマイル記憶手段と、
   前記第１データ端末の支払い額に応じたビジネスマイルを支払元となる法人宛に発行するマイル発行処理手段と、
   前記第１データ端末からの指示に従い、所要の支払いに充当するビジネスマイル数と交換するマイル交換処理手段と、を備えるビジネスマイル管理サーバと、と通信することを特徴とする請求項１に記載の電子決済代行業務システム。
6. 前記第１データ端末は、前記送信手段が提示する異なる支払先が混在するまとめた支払い計算書データを一括して支払うか、同一の支払先ごとに個別に支払うかをあらかじめ前記代理支払い手段に設定可能とすることを特徴とする請求項１に記載の電子決済代行業務システム。
7. 支払い元の経理処理を行う複数の第１データ端末と、支払い先の経理処理を行う複数の第２データ端末と、支払い処理を実行する銀行システムと、各法人間の請求と支払いの業務を実行する代理処理サーバとが通信して支払い代行サービスを行う電子決済代行業務システムの決済代行処理方法であって、
   前記代理処理サーバは、
   支払い元のいずれかの第１データ端末からアップロードされる支払先が同一となる複数の請求書データを解析して支払い総額を支払先ごとに算出する算出ステップと、
   前記算出ステップが支払先ごとに算出した支払い計算書データをまとめた支払い計算書データを支払い元のいずれかの第１データ端末に送信する送信ステップと、
   前記支払い計算書データに対する支払い認証を支払い元のいずれかの第１データ端末から受領することに応じて、支払い元のデータ端末から登録された支払い先情報に従う支払い銀行口座に対して前記銀行システムを介して代理支払いを実行する代理支払いステップと、
   前記代理支払いステップが実行した代理支払い額データに基づく支払い完了をいずれかの第１データ端末に通知する通知ステップと、を備え、
   前記第１データ端末は、前記送信ステップが提示する異なる支払先が混在するまとめた支払い計算書データを一括して支払うための１タップ承認画面を表示する承認画面表示ステップを備え、前記第１データ端末から前記１タップ承認画面に対する１タップ承認指示を受けた後、前記代理支払いステップは、支払い元のデータ端末から登録された支払い先情報に従うそれぞれ異なる支払い銀行口座に対して前記銀行システムを介して代理支払いを実行することを特徴とする電子決済代行業務システムの決済代行処理方法。