IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社FINNOWの特許一覧

特開2023-70082電子決済代行業務システムおよび電子決済業務システムの決済代行処理方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2023070082
(43)【公開日】2023-05-18
(54)【発明の名称】電子決済代行業務システムおよび電子決済業務システムの決済代行処理方法
(51)【国際特許分類】
   G06Q 20/10 20120101AFI20230511BHJP
【FI】
G06Q20/10
【審査請求】未請求
【請求項の数】9
【出願形態】OL
(21)【出願番号】P 2022165073
(22)【出願日】2022-10-13
(31)【優先権主張番号】P 2021181815
(32)【優先日】2021-11-08
(33)【優先権主張国・地域又は機関】JP
(71)【出願人】
【識別番号】520282797
【氏名又は名称】株式会社FINNOW
(74)【代理人】
【識別番号】100134072
【弁理士】
【氏名又は名称】白浜 秀二
(72)【発明者】
【氏名】阿部 悠紀
【テーマコード(参考)】
5L055
【Fターム(参考)】
5L055AA22
(57)【要約】
【課題】 決済代行システムを利用する法人にとって付加価値の高い決済サービスを提供すること。
【解決手段】 支払い元の経理処理を行う複数の支払い元PC1-1~1-Nと、支払い先の経理処理を行う複数の支払い先PC7-1~7-Nと、支払い処理を実行する代行銀行5と、各法人間の請求と支払いの業務を実行する代理処理サーバ4とが通信して支払い代行サービスを行う電子決済代行業務システムにおいて、代理処理サーバ4が算出した支払い計算書データを支払い元のいずれかの支払い元PCに送信し、該支払い計算書データに対する支払い認証を支払い元のいずれかの支払い元PCから受領することに応じて、支払い元PC1-1~1-Nから登録された支払い先情報に従う支払い銀行口座に対して代行銀行システム5を介して代行支払いを実行する構成を特徴とする。
【選択図】 図1

【特許請求の範囲】
【請求項1】
支払い元の経理処理を行う複数の第1データ端末と、支払い先の経理処理を行う複数の第2データ端末と、支払い処理を実行する銀行システムと、各法人間の請求と支払いの業務を実行する代理処理サーバとが通信して支払い代行サービスを行う電子決済代行業務システムであって、
前記代理処理サーバは、
支払い元のいずれかの第1データ端末からアップロードされる複数の請求書データを解析して支払い総額を算出する算出手段と、
前記算出手段が算出した支払い計算書データを支払い元のいずれかの第1データ端末に送信する送信手段と、
前記支払い計算書データに対する支払い認証を支払い元のいずれかの第1データ端末から受領することに応じて、支払い元のデータ端末から登録された支払い先情報に従う支払い銀行口座に対して前記銀行システムを介して代理支払いを実行する代理支払い手段と、
前記代理支払い手段が実行した代理支払い額データに基づく支払い完了をいずれかの第1データ端末に通知する通知手段と、
を備えることを特徴とする電子決済代行業務システム。
【請求項2】
前記代理処理サーバは、前記代理支払い手段が実行した代理支払いに対する手数料を計算する計算手段と、
前記計算手段が計算した手数料を前記支払い元となる第1データ端末または前記支払い先に対応する第2データ端末に対して分担請求を通知する第1の手数料通知手段と、
を備えることを特徴とする請求項1に記載の電子決済代行業務システム。
【請求項3】
前記代理処理サーバは、前記代理支払い手段が実行した代理支払いに対する手数料を計算する計算手段と、
前記計算手段が計算した手数料の請求を前記支払い元となる第1データ端末に対して通知する第2の手数料通知手段と、
を備えることを特徴とする請求項1に記載の電子決済代行業務システム。
【請求項4】
前記計算手段は、あらかじめ設定された分担比率に基づいて分担請求する前記支払い元となる第1データ端末または前記支払い先に対応する第2データ端末に対する手数料を計算することを特徴とする請求項2に記載の電子決済代行業務システム。
【請求項5】
前記代理処理サーバは、
ビジネスマイル数を記憶するビジネスマイル記憶手段と、
前記第1データ端末の支払い額に応じたビジネスマイルを支払元となる法人宛に発行するマイル発行処理手段と、
前記第1データ端末からの指示に従い、所要の支払いに充当するビジネスマイル数と交換するマイル交換処理手段と、を備えるビジネスマイル管理サーバと、と通信することを特徴とする請求項1に記載の電子決済代行業務システム。
【請求項6】
支払い元の経理処理を行う複数の第1データ端末と、支払い先の経理処理を行う複数の第2データ端末と、支払い処理を実行する銀行システムと、各法人間の請求と支払いの業務を実行する代理処理サーバとが通信して支払い代行サービスを行う電子決済代行業務システムであって、
前記代理処理サーバは、
支払い元のいずれかの第1データ端末からアップロードされる複数の請求書データを解析して支払い総額を所定の月締めタイミングで算出する算出手段と、
前記算出手段が算出した支払い総額に対する支払いの承認を求める指示を支払い元のいずれかの第1データ端末に1回送信する送信手段と、
前記支払い元のいずれかの第1データ端末から前記支払いの承認を受け取ることに応じて、登録された支払い先情報に従う支払い銀行口座に対して前記銀行システムを介して代理支払いを実行する代理支払い手段と、
前記代理支払い手段が実行した代理支払い額データに基づく支払い完了をいずれかの第1データ端末に通知する通知手段と、
を備えることを特徴とする電子決済代行業務システム。
【請求項7】
前記第1データ端末は、前記送信手段による承認を求める指示を承認する1タップ承認画面を表示する承認画面表示手段を備えることを特徴とする請求項6に記載の電子決済代行業務システム。
【請求項8】
支払い元の経理処理を行う複数の第1データ端末と、支払い先の経理処理を行う複数の第2データ端末と、支払い処理を実行する銀行システムと、各法人間の請求と支払いの業務を実行する代理処理サーバとが通信して支払い代行サービスを行う電子決済代行業務システムの決済代行処理方法であって、
前記代理処理サーバは、
支払い元のいずれかの第1データ端末からアップロードされる複数の請求書データを解析して支払い総額を算出する算出ステップと、
前記算出ステップが算出した支払い計算書データを支払い元のいずれかの第1データ端末に送信する送信ステップと、
前記支払い計算書データに対する支払い認証を支払い元のいずれかの第1データ端末から受領することに応じて、支払い元のデータ端末から登録された支払い先情報に従う支払い銀行口座に対して前記銀行システムを介して代理支払いを実行する代理支払いステップと、
前記代理支払いステップが実行した代理支払い額データに基づく支払い完了をいずれかの第1データ端末に通知する通知ステップと、
を備えることを特徴とする電子決済代行業務システムの決済代行処理方法。
【請求項9】
支払い元の経理処理を行う複数の第1データ端末と、支払い先の経理処理を行う複数の第2データ端末と、支払い処理を実行する銀行システムと、各法人間の請求と支払いの業務を実行する代理処理サーバとが通信して支払い代行サービスを行う電子決済代行業務システムであって、
前記代理処理サーバは、
支払い元のいずれかの第1データ端末からアップロードされる複数の請求書データを解析して支払い総額を所定の月締めタイミングで算出する算出手段と、
前記算出手段が算出した支払い総額に対する支払いの承認を求める指示を支払い元のいずれかの第1データ端末に1回送信する送信ステップと、
前記支払い元のいずれかの第1データ端末から前記支払いの承認を受け取ることに応じて、登録された支払い先情報に従う支払い銀行口座に対して前記銀行システムを介して代理支払いを実行する代理支払いステップと、
前記代理支払いステップで実行した代理支払い額データに基づく支払い完了をいずれかの第1データ端末に通知する通知ステップと、
を備えることを特徴とする電子決済代行業務システム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、電子決済業務システムおよび電子決済業務システムの決済代行処理方法に関するものである。
【背景技術】
【0002】
近年、電子決済業務システムが進化し、企業の決済方法も電子化が進み、気軽にクレジット決済を利用して決済業務を軽減化する動きが顕著である。
【0003】
また、各企業間の取引、すなわちBtoB(Business to Business)に対する決済も代行システムを利用する企業も増加している。ここで、代行システムとして、現在ネット上では、Paid、BizPay、NP掛け払い(各サービス名)が契約可能な代行システムとして参照可能になっている。
【0004】
これらの代行システムは、それぞれ独特の代行処理システムが構築され、契約企業にとって業務決済に関して利便性を担保し、企業間の決済処理をより効率化するサービスを提供している。これにより、売り手側の入金業務や買い手側の与信審査や入金確認、代金督促といった煩雑な業務の軽減が図られている。
【先行技術文献】
【特許文献】
【0005】
【特許文献1】特開2021-33939号公報
【発明の概要】
【発明が解決しようとする課題】
【0006】
しかしながら、これらの決済代行システムを利用する対価は、業務経費の節減が中心で、その利用価値は一元的でいずれの決済代行システムを採用してもそれほど明確な差異があるとは認められない。
【0007】
本発明は、上記の課題を解決するためになされたもので、本発明の目的は、決済代行システムを利用する企業にとって付加価値の高い決済サービスを提供できる電子決済業務システムおよび電子決済業務システムの決済代行処理方法を提供することである。
【課題を解決するための手段】
【0008】
上記目的を達成する本発明の電子決済業務システムは以下に示す構成を備える。
支払い元の経理処理を行う複数の第1データ端末と、支払い先の経理処理を行う複数の第2データ端末と、支払い処理を実行する銀行システムと、各法人間の請求と支払いの業務を実行する代理処理サーバとが通信して支払い代行サービスを行う電子決済代行業務システムであって、前記代理処理サーバは、支払い元のいずれかの第1データ端末からアップロードされる複数の請求書データを解析して支払い総額を算出する算出手段と、前記算出手段が算出した支払い計算書データを支払い元のいずれかの第1データ端末に送信する送信手段と、前記支払い計算書データに対する支払い認証を支払い元のいずれかの第1データ端末から受領することに応じて、支払い元のデータ端末から登録された支払い先情報に従う支払い銀行口座に対して前記銀行システムを介して代理支払いを実行する代理支払い手段と、前記代理支払い手段が実行した代理支払い額データに基づく支払い完了をいずれかの第1データ端末に通知する通知手段と、を備えることを特徴とする。
【発明の効果】
【0009】
本発明に係る電子決済業務システムの一つ以上の実施態様によれば、決済代行システムを利用する法人にとって付加価値の高い行決済サービスを提供することができる。
【図面の簡単な説明】
【0010】
図面は、本発明の特定の実施の形態を示し、発明の不可欠な構成ばかりでなく、選択的及び好ましい実施の形態を含む。
図1】本実施形態を示す電子決済代行業務システムの構成を説明するブロック図である。
図2図1に示した代理処理サーバの導入処理部のデータ処理の流れを説明するチャート図である。
図3図1に示した代理処理サーバのBMアクワイアラ登録部のデータ処理の流れを説明するチャート図である。
図4図1に示した支払い元PCによる支払い先登録処理の流れを説明するチャート図である。
図5図1に示した支払い元PCによる請求書アップロード処理の流れを説明するチャート図である。
図6図1に示した代理処理サーバの支払い先への代理支払い部による処理の流れを説明するチャート図である。
図7図1に示した代理処理サーバの支払い元への請求部による処理の流れを説明するチャート図である。
図8図1に示した代理処理サーバのマイル発行処理部による処理の流れを説明するチャート図である。
図9図1に示した代理処理サーバのマイル交換処理部による処理の流れを説明するチャート図である。
図10】本実施形態を示す電子決済代行業務システムにおける手数料支払い処理を説明するフローチャートである。
図11】本実施形態を示す電子決済代行業務システムにおける手数料支払い処理を説明するフローチャートである。
図12】本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。
図13】本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。
図14】本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。
図15】本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。
図16】本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。
図17】本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。
図18】本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。
図19】本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。
図20】本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。
図21】本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。
図22】本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。
図23】本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。
図24】本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。
図25】本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。
図26】本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。
図27】本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。
図28】本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。
図29】本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。
図30】本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。
図31】本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。
図32】本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。
図33】本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。
図34】本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。
図35】本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。
図36】本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。
図37】本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。
図38】本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。
図39】本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。
図40】本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。
図41】本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。
図42】本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。
図43】本実施形態を示す電子決済代行業務システムにおけるユーザーインタフェースの一例を示す図である。
図44図1に示した代理処理サーバによるワンタップ処理の流れを説明するチャート図である。
図45図1に示した代理処理サーバによるワンタップ処理の流れを説明するチャート図である。
【発明を実施するための形態】
【0011】
次に本発明を実施するための最良の形態について図面を参照して説明する。
下記の実施の形態は、図1図11に示す電子決済代行業務システムに関し、発明の不可欠な構成ばかりでなく、選択的及び好ましい実施の形態を含む。
<システム構成の説明>
〔第1実施形態〕
次に本発明を実施するための最良の形態について図面を参照して説明する。
【0012】
図1は、本実施形態を示す電子決済代行業務システムの構成を説明するブロック図である。本システムでは、支払い元法人側のデータ端末と、支払い先側のデータ端末と、後述する決済サービス(TobePay(サービス名))プログラムが運用されるサーバ装置とがネットワークを介して通信可能なシステム例を示す。
より具体的には、本実施形態に示す電子決済代行業務システムでは、支払い元の経理処理を行う複数の第1データ端末(支払い元PC1-1~1-N)と、支払い先の経理処理を行う複数の第2データ端末(支払い先PC7-1~7-N)と、支払い処理を実行する銀行システム(代行BK5)と、各法人間の請求と支払いの業務を実行する代理処理サーバ4とが通信して支払い代行サービスを行う。
【0013】
なお、TobePayシステムは、アーキテクチャ、データソースにはそれぞれグローバルメガクラウドのDBを採用し、一般的な脆弱性を混入しにくい環境でのサービス構築を実現している。
【0014】
また、AppsyncとGraphQLで表現できないロジックの実装は、AppsyncのリゾルバとしてLambdaを採用し、揮発性的なプロセスによる使い捨て稼働をさせているため、ウイルスやマルウエアの混入は根本的に回避できる構成としている。
【0015】
つまり、TobePayシステムは、全てのクライアントが、安心、安全に取引を継続できるためのセキュリティ基盤を備えていることを特徴とする。
【0016】
図1において、1-1~1-Nは支払い元PCで、所定のオペレーティングシステムの下、各種のユーザアプリが起動され、さらに、本サービスシステムが提供する決済サービスアプリも起動可能に構成されている。なお、決済サービスアプは、代理処理サーバ4からダウンロードされてインストールされる。
ここで、支払い元PC1-1~1-Nは、各種の法人(例えば歯科医院さん)が管理するPCであるものとする。なお、PC自体は、通常のハードウエア資源を備え、CPUがハードディスク等のメモリ資源からオペレーティングシステムをRAM上にロードし、OSが管理する各種のアプリケーションを実行することで各種のデータ処理、ネットワーク通信処理、表示処理、印刷処理等の業務処理を実行可能に構成されている。
本実施形態において、TobePayシステムは、OSに管理される決済代行処理プログラムとして機能する。ここで、TobePayシステムは、支払い元PCおよび支払い先PCに対して、ログイン作業、請求書入力作業、月極めの請求額の確認等の代行処理を受け付けたり、確認したりするためのユーザーインタフェースを提供する。
これにより、支払い元PCおよび支払い先PCの経理担当者は、TobePayシステムが提供するWEB画面を閲覧しながら、共通化された操作性の高い画面を介して必要な情報を入力したり、承認作業をしたりすることを視認性よく行うことができる。
【0017】
4は代理処理サーバで、インターネット網Iを介して支払い元PC1-1~1-N、支払先PC7-1~7-N、代行銀行システム(図中では、代行BKと記す)5と相互に通信可能に接続される。代行銀行システム5は、全国、および世界の銀行システムを含む支払い指定された銀行システム51-1~51-Nと接続されている。
【0018】
代理処理サーバ4は、本サービスを導入するための導入処理部41、BMアクワイアラ登録部42、支払先登録部43、請求書アップロード部44、支払い先への代理支払部45、支払い元への請求処理部46等からなる各種のアプリが図示しない記憶部に記憶され、各種のプロセッサからなる主制御部が通信処理を制御して各種サービスのためのデータ処理を実行する。
【0019】
なお、各導入処理部41、BMアクワイアラ登録部42、支払先登録部43、請求書アップロード部44、支払い先への代理支払部45、支払い元への請求処理部46の一例については、後述する図面を参照して詳述する。
【0020】
BM管理サーバ8は、マイル発行処理部81、マイル交換処理部82を含んで構成され、図示しない記憶部を用いてToBPayシステムによる支払い額に応じたビジネスマイルの発行とビジネスマイルの残高を管理する。なお、ToBPayシステムによるマイル管理処理およびマイルの交換処理等については後述する。
【0021】
本実施形態では、BM管理サーバ8は、ビジネスマイル数を記憶するビジネスマイル記憶手段を備え、マイル発行処理部81が第1データ端末としての支払い元PCの支払い額に応じたビジネスマイルを支払元となる法人宛に発行する処理を行う。また、マイル交換処理部82が第1データ端末からの指示に従い、所要の支払いに充当するビジネスマイル数と交換する処理を行う。ここで、BM管理サーバ8はインターネット網Iを介して代理処理サーバ4、支払い元PCと通信可能に接続される。
【0022】
また、本実施形態では、ToBPayシステムとして、BM管理サーバ8と代理処理サーバ4とが連携してBM処理を分担処理する構成として説明するが、代理処理サーバ4がBM管理サーバ8の機能処理を代行する構成としてもよい。
さらに、代理処理サーバ4が実行する導入処理部41、BMアクワイアラ登録部42、支払先登録部43、請求書アップロード部44、支払い先への代理支払部45、支払い元への請求処理部46の各機能処理を1つのアプリケーションとして構成し、支払い元PC1-1~1-N、支払先PC7-1~7-Nが操作する支払い処理画面を介して支払い処理業務サービスを提供する構成としてもよい。
【0023】
また、代理処理サーバ4は、CPU、ROM、RAM等を備えるコントローラ部と、インターネット網Iを介して支払い元PC1-1~1-Nや支払い先PC7-1~7-Nと通信する通信部を備え、暗号化処理を施してセキュリティを担保するやり取りを可能としている。
【0024】
また、代理処理サーバ4から直接メール等で支払い先PCや支払い元PCのアカウント宛に指示を送付する際には、電子証明書を添付して、フィッシング詐欺やハッキングによる顧客のデータが流出してしまう被害を防止する機能を備えているものとする。
【0025】
なお、支払い元PC1-1~1-N、支払先PC7-1~7-N、代行銀行システム5、銀行システム51-1~51-N、クレジット会社端末6-1~6-N、代理処理サーバ4には、それぞれインターネット網Iと通信する通信処理部を備えて暗号化処理された通信を行う環境が整備されているものとする。
【0026】
また、本システムでは、アーキテクチャ、データソースにはそれぞれグローバルメガクラウドのDBを採用し、一般的な脆弱性は混入しにくい環境でのサービスを提供するシステムを構築している。
【0027】
これにより、ウイルスやマルウエアの混入されることを回避するとともに、全てのクライアントが、安心、安全に取引を継続できるようにシステム設計がなされている。
【0028】
このように構成された電子決済代行業務システムにおいて、代理処理サーバ4の支払先への代理支払部45の演算機能により、支払い元のいずれかの支払い元PC1-1~1-Nからアップロードされる複数の請求書データを解析して支払い総額を算出する。
【0029】
さらに、代理処理サーバ4の通信機能により、支払先への代理支払部45が算出した支払い計算書データを支払い元のいずれかの第1データ端末に送信する。また、支払先への代理支払部45は、支払い計算書データに対する支払い認証を支払い元のいずれかの支払い元PC1-1~1-Nから受領することに応じて、支払い元元PC1-1~1-Nから登録された支払い先情報に従う支払い銀行口座に対して代行BK5を介して代理支払いを実行する。
【0030】
さらに、代理処理サーバ4の通信機能により、支払先への代理支払部45が実行した代理支払い額データに基づく支払い完了をいずれかの第1データ端末に通知する通知する。
【0031】
以下、図2図9を参照して、図1に示した代理処理サーバ4の各処理部の特定の処理を順次説明する。以下、ToBPayシステムとして機能する代理処理サーバ4による各機能処理について、図13図35に一例を示すユーザーインタフェースを参照しながら詳述する。
〔導入処理部41のデータ処理〕
【0032】
図2は、図1に示した代理処理サーバ4の導入処理部41のデータ処理の流れを説明するチャート図である。なお、支払い元PC1-1~PC1-Nには、当該支払い元PC1-1~PC1-Nを操作する支払い元ユーザが法人側の担当者とする。なお、本明細書において、代理処理サーバ4が提供する上記決済サービス名をToBPayと呼ぶ。
【0033】
まず、ToBPayシステムの導入のため、決済サービス管理会社のToBPay担当者がインターネット網Iを介して、あるいは営業を行い、支払い元ユーザ(法人の経理担当者)にToBPay導入を提案する。
【0034】
ここで支払い元ユーザとToBPay担当者と、そのメリットについて検討して、支払い元ユーザが当該ToBPayを導入することに合意する。次に、支払い元ユーザが支払い元法人の役職者と協議を行い、正式導入を決定し申し込みフォーム(例えばPDFファイルとして提供される)に必要事項(規約)を入力する。
【0035】
この際、規約が記載された書面(デジタル署名書面を含む)に対して、支払い元法人のサインが入力されると、当該書面(PDFファイル)がToBPayシステムにインターネット網Iを介して通知される。これを受けて、ToBPayシステムは、支払い元法人をToBPayシステムで受け付ける受任処理を行う。具体的には、導入処理部41は、図12に示す新規登録を行うためのメールアドレス入力のためのUI画面を支払元PC1-1の表示装置に表示する。本画面(SIGN UP)では、メールアドレスを入力する。これに応じて、導入処理部41は、メールアドレスに登録メールを送付してメール確認を行い(図13に示す新規登録を行うためのUI画面)、さらに、図14に示す新規登録を行うためのUI画面に対して、パスワード、パスワード再入力、氏名、電話番号、登録アカウント企業情報として、会社名(法人名)、職種、電話番号等の必要事項を入力する。ここで、図15に示すUI画面のように、新規登録における本登録前に、入力した事項を修正し直して、登録ボタンがクリックされることで、図16に示すUI画面を支払元PC1-1の表示装置に表示して、新規登録処理を完了する。
【0036】
次に、ToBPayシステムのオペレータが管理画面を受信した支払い元法人に対して整理番号(管理番号)発行すると、受任した支払い元法人の正式な管理画面発行処理が実行される。具体的には、正確には、図17に示すUI画面に一例を示す管理画面のURLが支払い元法人の登録アドレスに送付され、その管理画面に対して、支払い元ユーザー(経理担当者)からID/PASS登録をしてもらう。
次に、ToBPayシステムは、支払い元法人の支払い元ユーザに管理画面導入案内を、インターネット網Iを介して送付する。
これにより、支払い元法人はToBPayシステムによる支払い代行サービスの運用が認められる。
〔BMアクワイアラ登録処理〕
【0037】
図3は、図1に示した代理処理サーバ4のBMアクワイアラ登録部42のデータ処理の流れを説明するチャート図である。ここで、アクワイアラとは、加盟店登録を意味する。以下、図18図23に示すUI画面を参照して、BMアクワイアラ登録部42によるBMアクワイアラ登録処理を説明する。
【0038】
まず、ToBPayシステムは、BM(ビジネスマイル)アクワイアラ案内を、インターネット網Iを介して支払い元法人宛に通知する。支払い元法人がToBPayシステムから通知されたBMアクワイアラ案内の通知(例えば電子メール)を受信したら、支払い元法人の代表者または担当者がBM申し込みフォーム(PDFファイル)に必要事項を入力し、インターネット網Iを介してBM管理会社の管理サーバに送信する。
【0039】
これを受けて、BM管理会社の管理サーバ(BM管理サーバ8)は、ToBPayシステムを導入した支払い元法人の申し込みを受け付け処理する。ここで、BM管理サーバ8のマイル発行処理部81は、BM運用者画面において、新規ユーザアカウントを発行し、ToBPayシステムを導入した支払い元法人が表示するBMユーザ(アクワイアラ画面)に対して支払い元企業ユーザアカウントを発行すると、ToBPayシステムを導入した支払い元法人に対するBMアカウント処理が完了する。
具体的には、BMアクワイヤラ登録部42が図18に示すUI画面を支払元PC1-1の表示装置に表示する。ここで、支払元PC1-1の操作者(クライアント)は、ログインボタン、または新規登録ボタンをクリックして、新規登録、ログイン処理へ進む。
ここで、既にBM登録を完了しているクライアントは、図19に示すUI画面に対して登録されたメールアドレスを入力して承認ボタンをクリックすると、図20に示すUI画面が支払元PC1-1の操作者(クライアント)の表示装置に表示される。すると、BMアクワイヤラ登録部42は、図20に示すUI画面を支払元PC1-1に提示する。ここで、支払元PC1-1の操作者(クライアント)が画面に表示されるメッセージに従い、認証メールを受信したことを確認したら、ログイン処理が完了する。なお、認証メールを受信していない場合は、認証メールを再送してもらう再送ボタンをクリックして、同様の処理を繰り返す。
一方、図18に示すUI画面にて、クライアントが新規登録ボタンをクリックした場合、BMアクワイヤラ登録部42は、図21に示すUI画面を支払元PC1-1に提示する。図21に示すUI画面に表示された新規登録フォーマットは、一例であって、本画面以外の項目が含まれていてもよい。
クライアントは、当該UI画面に対して氏名、住所、法人情報を入力し終えたら、会員登録完了ボタンをクリックする。
そして、BMアクワイヤラ登録部42は、図22に示すUI画面を支払元PC1-1に提示する。ここで、ToBPayシステムが提供するビジネスマイルに概要とそのサービス内容(マイルの獲得、マイルのシェア、マイルを使う)をクライアントに提示する。ここで、次へボタンがクリックされると、BMアクワイヤラ登録部42は、図23に示すUI画面(ビジネスマイル・マイページ画面)を支払元PC1-1に提示する。クライアントは当該画面により、マイル残高、シェア可能なマイル残高、ニュース、デジタルマイルカードの内容の確認を行うことができる。
また、図23に示すUI画面の下部側に配置される確認ボタン、使うボタン、貯めるボタン、シェアボタンが配置されている。
【0040】
〔支払い先登録処理〕
図4は、図1に示した支払い元PC1-1~Nによる支払い先登録処理の流れを説明するチャート図である。以下、図24図25に示すUI画面を参照して、支払い先登録処理を詳述する。
代理処理サーバ4の支払先登録部43は、支払い元PC1-1~Nに対して支払先登録の依頼メールを送信する。
【0041】
ここで、支払い元PC1-1~Nは、WEBブラウザをhttps:登録画面を表示させ、1件ずつ支払先のアドレスや連絡先、そして自身のBMアカウント(アクワイヤラ登録No.等)を入力する。
【0042】
これにより、支払先法人依頼フォームが完成するので、該支払先法人導入依頼フォーム(図25に示すUI画面)を代理処理サーバ4へ送信する。図24に示すUI画面にて、支払い先7-1~7-Nは、ToBPayシステムへのログインまたは新規登録を催促する。ここで、登録ボタンがクリックされた場合、支払い先7-1~7-Nの表示装置には、図25に示すUI画面が表示されて、簡単な操作でカンパニーに参加することができる。
【0043】
次に、代理処理サーバ4の支払先登録部43は、支払い元PC1-1~Nから支払先法人導入依頼フォーム(PDFファイル)を受信すると、支払先登録部43は、支払先登録フォームを発行して、該発行した支払先登録フォームを支払先法人の支払先PC7-1~PC-Nに送信する。
【0044】
これを受けて、支払先法人の支払先PC7-1~PC-Nの責任者は、ToBPayシステムが提案する支払いを受けるかどうかを検討し、支払先法人の支払先の責任者が提案に合意した場合、ToBPayシステムが提供する申し込みフォーム(PDFファイル)に必要事項(支払いのための銀行名、支店名、口座の種類、口座番号等を含む)を入力し、該必要事項が入力された申し込みフォームを、ToBPayシステムを構成する代理処理サーバ4にインターネット網Iを介して送信する。
【0045】
これを受けて、代理処理サーバ4の支払先登録部43は、受信した申し込みフォームを受け付け、代理処理サーバ4が提供する管理画面を発行し、TP支払い先法人画面上にURLが登録アドレスに送付される。
【0046】
これにより、ToBPayシステムは、発行された管理画面の導入案内を支払先PC7-1~7-Nのユーザに通知する。
【0047】
一方、代理処理サーバ4の支払先登録部43は、受信した申し込みフォームを受け付けた際、BM管理サーバ8は、代理処理サーバ4の支払先登録部43より支払先登録受理の通知を受けて、BM管理サーバ8が提供するアクワイアラ画面上で、支払い元に対して、支払い先の登録が完了した旨を示す登録完了通知を行い、該発行された支払い先の登録が完了した旨を示す登録完了通知を、インターネット網Iを介して、支払い元PC1-1~1-Nのいずれかにメールで通知する。
【0048】
支払い元PC1-1~1-Nのいずれかが、当該支払い先の登録が完了した旨を示す登録完了通知をBM管理サーバ8のマイル発行処理部81から受信したら、支払先の登録処理が完了する。
【0049】
〔第1の請求書アップロード処理〕
図5は、図1に示した支払い先PC7-1~7-Nによる請求書アップロード処理の流れを説明するチャート図である。以下、図26図31に示すUI画面を参照しながら、請求書アップロード処理を詳述する。
【0050】
代理処理サーバ4の請求書アップロード部44は、支払い先PC7-1~7-Nの経理担当者が、ToBPayシステムが提供するWEB画面に対して、あらかじめ設定された締め日に従い、支払い元の法人に当月支払っていただく請求書に従う請求データを受け付けて処理する。
【0051】
具体的には、支払い先PC7-1~7-Nを操作する支払先ユーザが支払い元に対する請求書の発行を行う際、ToBPayシステムが提供するWEBページ(アップロードページ)に必要な請求項目(請求元を指定するコード、請求明細、請求総額を含む)を入力して、支払い先PC7-1~7-Nの表示装置に、例えば図26に示すUI画面を表示する。+ボタンをクリックすると、請求カテゴリ情報入力画面として、支払い先PC7-1~7-Nの表示装置に、例えば図27に示すUI画面を表示する。ここで、取引先に付与された編集ボタンをクリックすると、支払い先PC7-1~7-Nの表示装置に、例えば図28に示す請求書情報を入力するためのUI画面を表示する。ここで、支払い先PC7-1~7-Nの担当者は、図28に示すUI画面に対して、請求日、支払い期限、発注社名、取引先名、取引き担当者名、件名、請求金額(税抜)、備考等に必要な情報を入力することができる。
次に、支払い先PC7-1~7-Nの担当者は、図27に示すUI画面に戻り、取引先の追加ボタンをクリックすると、支払い先PC7-1~7-Nの表示装置に、図29に示すUI画面を表示する。ここで、保存ボタンを指示すると、請求書アップロード部44は、支払い先ユーザが入力した指定される請求元に対する請求項目が記載された請求書データ(PDFファイル)を受領する。
【0052】
これを受けて、請求書アップロード部44は、支払先ユーザからアップロードされた請求書を受領した旨をTP支払い元法人画面およびTP運用者画面に通知する。
【0053】
一方、別のアップロードによる場合、支払い先PC7-1~7-Nの支払い先ユーザは、インターネット網Iを介して支払い元PC1-1~1-Nのいずれかの支払い元ユーザに請求書データを発行する。
【0054】
これを支払い元PC1-1~1-Nのいずれかの支払い元ユーザが受け取ると、請求書データ(PDFファイル)を承認して、インターネット網Iを介して代理処理サーバ4の請求書アップロード部44に対してアップロードする。
【0055】
これにより、代理処理サーバ4の請求書アップロード部44は、支払先PC7-1~7-NのTP支払い先法人画面に請求書の登録した旨を通知するとともに、TP運用者画面に請求書の登録を通知するとともに、TP支払い先法人画面に請求書の登録通知を行う。
【0056】
これを受けて、支払い先PC7-1~7-Nのいずれかの支払い先ユーザに対して、TP支払い先法人画面を介して請求書確認を依頼し、その内容についての承認指示を待つ。なお、TP支払い先法人画面上には、アップロードされた請求書を承認するための承認ボタンが用意されている。ここで、承認ボタンは、承認者が複数存在する場合に適応するため、上長に対応する支払先ユーザが最終承認を行う場合がある。
なお、図30に示すUI画面では、支払い元のPCにおいて、請求書情報の詳細画面を表示した状態を示した。また、図31に示すUI画面では、登録された請求書であって、1つのプロジェクトに毎に、タブが割り当てられて、現在TBP初期開発に係る請求書の一覧を表示した状態に対応する。また、図32図33に示すUI画面では、決済状態と、決済完了を確認できるように構成されている。
また、図34図35に示すUI画面では、登録された「〇〇〇〇プロジェクト」に関する請求書であって、支払い状態、振込状態を確認できるように構成されている。
【0057】
〔支払先への代理支払い処理〕
図6は、図1に示した代理処理サーバ4の支払い先への代理支払部45による処理の流れを説明するチャート図である。
【0058】
図5に示した請求書アップロード処理において、支払い先ユーザが請求書確認および承認が完了した旨の通知を代理処理サーバ4の支払い先への代理支払部45が受信したら、請求書に記載された支払い情報を受け付けて、受け付けた支払い情報に基づいて、TP運用者画面上に支払い情報を更新して表示する。
【0059】
次に、TP運用者画面上で更新された支払い情報に基づいて、支払先に請求額を支払う。ここで、支払い情報に基づく支払いとは、ToBPayシステムが契約している代行銀行5を介して、支払先が指定する銀行51-1~51-Nのいずれかに振り込む処理を意味する。
【0060】
このようにして、支払い先への代理支払部45が支払い先に支払いを完了したら、振込確定通知をTP運用者画面上に送信すると、TP運用者画面に振り込み完了を表示させるとともに、TP運用者画面の内容を更新して、その内容をTP支払い先法人画面に反映する。
【0061】
これにより、支払い先PC7-1~7-Nが振り込み完了を受信すると、支払い先PC7-1~7-Nが備える表示装置が表示するTP支払い先法人画面上に振り込み完了を表示する。ここで、支払い先PC7-1~7-Nを操作する支払い先ユーザは、上記TP支払い先法人画面を介して、ToBPayシステムによる代行振込が完了したことを確認し、表示された画面の情報を更新する指示を行う。
これを受けて、代理処理サーバ4の表示装置に表示するTP支払い先法人画面に1つの請求に対する支払い代行が完了した旨を示すように情報を更新する。
【0062】
これにより、代理処理サーバ4の表示装置は、TP支払い先法人画面上で1つの請求の情報を支払完了に更新する。同様に、支払い先PC7-1~7-Nが備える表示装置に表示するTP支払い先法人画面上の情報を支払完了に更新する。
【0063】
〔支払い元への請求処理〕
図7は、図1に示した代理処理サーバ4の支払い元への請求処理部46による処理の流れを説明するチャート図である。
図6に示した支払い先への代理支払部45が支払い情報更新を行うと、ToBPayシステムの支払い元への請求処理部46による処理を開始する。
【0064】
まず、支払い元への請求処理部46は支払い完了通知を受けて、代行して振り込んだ金額の支払いを支払元PC1-1~1-Nのいずれかに請求処理を行う。これにより、代理処理サーバ4の表示装置が表示するTP支払い元法人画面に請求情報を通知する。
【0065】
このようにし、支払元PC1-1~1-Nの支払元ユーザが支払い元への請求処理部46による請求を受領すると、ToBPayシステムが指定する代行銀行5に指定される口座に請求額を振込により支払う。ToBPayシステムが支払元PC1-1~1-Nの支払元ユーザによる振り込みを確認したら、支払い元への請求処理部46は、TP運用者画面の支払い元法人に対応する支払い経過を示す情報を入金確認に更新し、TP支払い元法人画面の支払い状態を示す情報を取引完了に更新する。
【0066】
〔マイル発行処理〕
図8は、図1に示した代理処理サーバ4のマイル発行処理部81による処理の流れを説明するチャート図である。
【0067】
図7に示した支払元ユーザが支払い元への請求処理部46がTP支払い元法人画面を取引完了に更新したら、BM管理サーバ8のマイル発行処理部81が処理を開始する。
【0068】
マイル発行処理部81は、図示しないマイル管理テーブルを参照して、支払いが完了した支払い元の法人に設定したマイル付与情報を連系情報に基づいて読み出し、今回の支払いに対するマイル数を確認して、BM運用者画面上で付与するマイル数を承認する指示を行う。
【0069】
これにより、マイル発行処理部81は、BMユーザのアクワイアラ画面に上記承認したマイル数を現在のマイル数に付加付与する。
これに従い、支払い元法人の支払い元ユーザは、法人ログイン画面を介して今回の支払いで付与されたマイル数を受信したことを確認できる。
【0070】
〔マイル発行処理〕
図9は、図1に示した代理処理サーバ4のマイル交換処理部82による処理の流れを説明するチャート図である。以下、図36図37に示すUI画面を参照してマイル発行処理について説明する。
【0071】
支払い元法人の支払い元ユーザは、管理画面からBM管理サーバ8にログインすると、マイル数確認画面を表示する。ここで、支払い元法人の支払い元ユーザは、現在のマイル数を確認することができる。
そして、マイル数が適切な交換ポイント数に到達していると判断した場合、現在のマイル数を商品購入等への交換指示を入力することができる。
【0072】
そして、BM管理サーバ8のマイル交換処理部82は、交換指示されたポイントに基づいて、直前の総ポイント数から交換指示されたポイントを差し引いて交換処理を完了する。
【0073】
次に、BM管理サーバ8のマイル交換処理部82は、直前の総ポイント数から交換指示されたポイントを差し引いたポイント残高(図37に示すUI画面参照)を、インターネット網Iを介して支払い元PC1-1~1-Nのいずれかの法人の支払い元ユーザに交換指示の内容と、ポイント残高を通知して処理(図36に示すUI画面参照)を終了する。
【0074】
〔第1実施形態の効果〕
第1実施形態によれば、ToBPayシステムを利用する支払い元の法人は、代行支払い額に適応したビジネスマイル(ポイント)を受け取ることができ、加算されるビジネスマイルを活用して、商品購入の資金、旅行代金の資金当に充当することができる。
【0075】
なお、ビジネスマイルは、後述するToBPayシステムを利用した際に支払う手数料に充当することもできる。
【0076】
〔第2実施形態〕
図10は、本実施形態を示す電子決済代行業務システムにおける手数料支払い処理を説明するフローチャートである。なお、(1)~(19)は各ステップを示す。なお、本処理は、ToBPayシステムの契約担当者と、支払い元(法人)との支払い代行契約が成立した後に開始される処理である。
【0077】
また、各ステップは、代理処理サーバ4のコントローラ部のCPUがメモリ部に記憶されたToBPayシステムプログラムを読み出して実行することにより実現される。また、ToBPayシステムプログラムは、規約改定や税率の改定等に備えて随時バージョンが更新される構成を採用している。
【0078】
まず、ToBPayシステムを構成する代理処理サーバ4が支払い元PC1-1~1-Nのいずれかから登録要求を受け付けたら(1)、当該支払い元PC1-1~1-Nの経理担当者が毎月支払う取引方となるいずれかの支払い先PC7-1~7-Nから、ToBPayシステムによる支払い先からの承認を受けると(2)、すべての登録(K=N)が完了したかどうかを判断する(3)。
【0079】
ここで、すべての登録が完了していると判断した場合、例えば支払い元PC1-1を操作する法人様Aの経理担当者から締め日に合わせて請求されている請求書情報をToBPayシステムにアップロードする(4)。
【0080】
次に、本日が処理中の法人様Aの支払い締め日に該当するかどうかを判断する(5)。ここで、本日が支払い締め日でないと判断した場合は、ステップ(3)へ戻り、本日が支払い締め日であると判断した場合は、ToBPayシステムがまとめた支払い確認書を支払元に対応する支払い元PC1-1~1-Nのいずれかに通知し、その法人様の経理担当者からの承認を受領したかどうかを判断する(6)。
【0081】
次に、ToBPayシステムは、支払い契約条件を参照して、支払い元との代行支払い条件が条件1(代行支払いに対する手数料を支払い元と、支払い先でシェアする場合)であるかどうかを判断する(7)。
【0082】
ここで、ToBPayシステムが支払い元との代行支払い条件が条件1であると判断した場合、ステップ(8)へ進み、ToBPayシステムは、支払い元PC1-1~1-Nのいずれかから支払い確認書に対する承認指示を受信するのを待ち、支払い元PC1-1~1-Nのいずれかから支払い確認書に対する承認指示を受信したら、ToBPayシステムは、支払い確認書と、ToBPayシステムとの契約時に登録された支払い先と照合して、支払い先が指定するそれぞれの銀行口座宛に振り込みを行う。
【0083】
次に、ToBPayシステムは、支払い確認書に基づく代行支払いが完了した旨を支払元PC1-1~1-Nのいずれかに通知する(9)。
これにより、契約者である法人様毎に月単位での代行支払いが完了するため、法人様の経理担当者による振り込み処理負担が大幅に軽減できる。
【0084】
一方、ステップ(7)において、支払い元との代行支払い条件が条件2(代行支払いに対する手数料を支払い元が負担する場合)であると判断した場合は、ステップ(10)へ進む。
【0085】
ステップ(10)で、ToBPayシステムがまとめた支払い確認書を支払元に対応する支払い元PC1-1~1-Nのいずれかに通知し、その法人様の経理担当者からの承認を受領したかどうかを判断する。
【0086】
ここで、支払い元PC1-1~1-Nのいずれかから支払い確認書に対する承認指示を受信したら、ToBPayシステムは、支払い確認書と、ToBPayシステムとの契約時に登録された支払い先と照合して、支払い先が指定するそれぞれの銀行口座宛に振り込みを行う(11)。
【0087】
次に、ToBPayシステムは、今回の支払いに伴う手数料の請求条件をメモリ部から読み出し(12)、支払い元と、支払い先との手数料の負担率が100%:0%であるかどうかを判断する(13)。
【0088】
ここで、ToBPayシステムは、支払い元と、支払い先との手数料の負担率が100%:0%であると判断した場合、ToBPayシステムは、今回の代行支払いに対する手数料を算出して、支払い元PC1-1~1-Nのいずれかに請求書を送付する(14)。そして、支払い元PC1-1~1-Nのいずれかから手数料納付の確認がとれたら(19)、本処理を終了する。
【0089】
一方、ステップ(13)で、ToBPayシステムは、支払い先との手数料の負担率が100%:0%でないと判断した場合、さらに、ToBPayシステムは、支払い元と、支払い先との手数料の負担率が50%:50%であるかどうかを判断する(15)。
【0090】
ここで、支払い元と、支払い先との手数料の負担率が50%:50%であると判断した場合、今回の支払い総額に対する手数料を算出し、支払い元と、支払い先とのそれぞれに請求する手数料を算出して、支払い請求書を送付する(18)。次に、ステップ(19)へ進む。
【0091】
一方、ステップ(15)で、ToBPayシステムは、支払い元と、支払い先との手数料の負担率が50%:50%でないと判断した場合、メモリ部に登録された手数料の負担割合を読み出し、支払い先とのそれぞれに請求する手数料を算出して(16)、支払い元と、支払い先とに割合に従う手数料の支払い請求書を送付する(17)。そして、ステップ(19)へ進む。
【0092】
これにより、ToBPayシステムを利用する支払い元と、支払い先とが代行手数料をシェアすることで、ToBPayシステムが提供するマイルを支払い元と、支払い先との双方に付与することができる。これにより、ToBPayシステムを利用する法人が増えることで、法人の経理担当者の規模を縮小して、法人自体の支出を削減できる。
また、支払い先との双方は、ToBPayシステムを活用することで、それぞれマイルが付与されて積算されて行く。
【0093】
なお、マイルについて、ToBPayシステムと契約する法人は、契約時にマイル付与に代えて、または適時組み合わせて、マイル還元よりも法人に対するキャッシュバックを優先させて処理する構成としてもよい。
【0094】
また、代行支払いに伴う手数料は、ToBPayシステムが指定する条件(指定業者の商談を受けるとか、指定業者のサービスを導入する等)を満たす場合には、個別的に手数料を通常よりも下げるようにシステムを構成してもよい。
【0095】
本実施形態においては、代理処理サーバ4が代理支払いを実行した際、ToBPayシステムを利用した代理支払いに対する手数料を計算するステップを実行する(16)。
【0096】
その際、代理処理サーバ4が計算した手数料を前記支払い元となる第1データ端末または支払い先に対応する第2データ端末に対して分担請求を通知する(17)。
【0097】
これに対して、代理処理サーバ4は、代理支払いに対する手数料を支払い元にすべて負担させるように計算する場合もある。
【0098】
その場合には、代理処理サーバ4が計算した手数料の請求を第1データ端末に対して通知する。
【0099】
また、本実施形態では、代理処理サーバ4があらかじめ設定された分担比率(図10に示すステップ(13)~(15)参照)に基づいて分担請求する支払い元となる第1データ端末または支払い先に対応する第2データ端末に対する手数料を計算する場合にも柔軟に適用可能に構成されている。
【0100】
〔第2実施形態の効果〕
第2実施形態によれば、ToBPayシステムに対して支払う代行支払い手数料の負担を支払元としたり、支払い元と、支払い先とでシェアしたりする支払い環境を構築し、ToBPayシステムを利用する支払い元と、支払い先の利便性を高めることができる。
【0101】
〔第3実施形態〕
図11は、本実施形態を示す電子決済代行業務システムにおける手数料支払い処理を説明するフローチャートである。なお、(21)~は各ステップを示す。なお、本処理は、ToBPayシステムの契約担当者と、支払い元(法人)との支払い代行契約が成立した後に開始される処理である。また、各ステップは、代理処理サーバ4のコントローラ部のCPUがメモリ部に記憶されたToBPayシステムプログラムを読み出して実行することにより実現される。
【0102】
まず、ToBPayシステムは支払い元との契約に基づき、月単位の締め日に合わせて、支払い元からアップロードされた請求書を分析して、支払い元が支払い先に支払う額の総額を算出する(21)。
【0103】
次に、代理処理サーバ4にインストールされたToBPayシステムは、代行支払いに関する支払い元と、ToBPayシステムとの契約条件が代行支払い条件1(支払い元からToBPayシステムへの代行支払い額の振込前に、ToBPayシステムが支払い元からの入金を待たずに、支払い先に先行して支払いを行う立替支払いとする条件)であるかどうかを判断する(22)。
【0104】
ここで、ToBPayシステムが代行支払い条件1であると判断した場合、ToBPayシステムが代行支払い計算書を支払い元となる支払い元PC1-1~1-Nのいずれかにインターネット網Iを介して送付する(23)。
【0105】
次に、ToBPayシステムは、支払い元が送付した代行支払い計算書を承認する指示を待ち(24)、支払い元が送付した代行支払い計算書を承認する指示を受けたら、ToBPayシステムが管理する代行銀行5から登録された支払い先が指定する銀行の指定口座宛に立替送金(先払い送金)を行う(25)。
【0106】
次に、ToBPayシステムは、立替支払いを実行した支払い元に対して、立替総額の支払い請求を通知して(26)、当該支払い元が、ToBPayシステムが指定する代行銀行5の指定口座への入金を確認したら(27)、ToBPayシステムは、メモリ部で管理する支払い元台帳に、今回の支払いの詳細を記帳して、支払い元情報を更新して(28)、たら、本処理を終了する。
【0107】
一方、ステップ(22)で、ToBPayシステムが代行支払い条件1でないと判断した場合、ToBPayシステムが代行支払い計算書を支払い元となる支払い元PC1-1~1-Nのいずれかにインターネット網Iを介して送付する(29)。支払い元よりToBPayシステムが指定する代行銀行5に計算書に記載した支払額の総額が振り込まれるのを確認したら(30)、ステップ(26)へ進む。
【0108】
これにより、支払い元法人の経理担当者は、ToBPayシステムの利用実績に応じて、通常、ステップ(29)により代行支払い額の総額をToBPayシステムの代行銀行5に先払いする先払い方式と、ステップ(25)により代行支払い額の総額をToBPayシステムが立て替えて支払う立替払い方式のいずれかを選択することができる。
【0109】
このように電子決済代行業務システムは、ToBPayシステムと契約する支払い元ユーザ(法人)と、支払い先ユーザ(法人)との間における決済業務において、支払い元には個別的で厄介な支払い業務から解放し、1回のおまとめ支払いで決済を完了できる。
【0110】
一方、支払い先は、上述したように、ToBPayシステムを利用する手数料を支払い元と分担することで、ビジネスマイルとしてのポイントを取得することができる。
【0111】
〔第3実施形態の効果〕
第3実施形態によれば、従来の電子決済業務とは革新的な手法で法人支払いを行うことができ、支払い元における人件費の大幅な削減が期待できる。
【0112】
〔第4実施形態〕
上記実施形態では、法人間(BtoB)の支払い業務について詳細に説明したが、ToBPayシステムにファクタリング機能(売掛債権買取業務機能)を付加してシステムを拡張してもよい。
【0113】
〔第5実施形態〕
図38図43は、本実施形態を示す電子決済代行業務システムにおけるBM処理のUI画面の一例を示す図である。なお、各BMUI画面は、支払い元、支払い先のいずれでも表示可能である。
【0114】
図8に示したマイル発行処理において、支払い元PC、支払い先PCにおいてBM登録された利用者は、BM管理サーバ8からオンデマンドあるいは定期的にお知らせの通知(図38図43に示すUI画面表示)を受信する。
【0115】
本実施形態では、マイページ、確認、使う、貯める、シェアの各タブが設定されているため、いずれかのタブを選択することでマイル発行処理部81と、マイル交換処理部82とが協働してBM処理を行う。
【0116】
ここで、支払い元PCまたは支払い先PCの各利用者がマイルを使うタブが選択されると、図39に示すUI画面が支払い元PCまたは支払い先PCの表示装置に表示される。本例は、支払い元PCまたは支払い先PCの各利用者が貯め込んだマイルを、ショッピングサイト、例えばamazon(登録商標)で利用できるギフト券に交換する操作例である。
【0117】
この画面表示の内容で、次へ進むボタンをクリックすると、マイル交換処理部82は、支払い元PCまたは支払い先PCの表示装置のUI画面の内容が図40に示すUI画面に切り替わるように制御する。
【0118】
ここで、上記ギフト券を発行することにより、現在のマイル状況が更新されることを確認することができる。さらに、次へ進むボタンをクリックすると、マイル交換処理部82は、支払い元PCまたは支払い先PCの表示装置のUI画面の内容が図41に示すUI画面に切り替わるように制御する。
【0119】
ここで、支払い元PCまたは支払い先PCの各利用者が表示された交換契約を承認するため、申し込むボタンをクリックすると、マイル交換処理部82は、支払い元PCまたは支払い先PCの表示装置のUI画面の内容が図42に示すUI画面に切り替わるように制御する。
【0120】
〔第6実施形態〕
上記第1実施形態では、代理処理サーバ4が支払元PCと、支払先PCとの請求処理を代行処理する際に、図5に示す請求書アップロード処理、図6に示す支払い先への代理支払い処理、図7に示す支払い元への請求処理を時系列で処理する場合、支払元PCの担当者(経理担当者)は、例えば月締めの特定日までに請求書アップロード処理を繰り替えした場合、その都度、図5に示した請求書確認とその承認処理を繰り返す操作が発生していたため、支払先への代行支払い指示を1回の承認で処理できないという課題が指摘されていた。
【0121】
そこで、支払元PCにおける支払い承認回数を毎月1回の承認で支払い先へ代行支払いが完了するように構成してもよい。
【0122】
〔第2の請求書アップロード処理〕
図44図45は、1に示した代理処理サーバによるワンタップ処理の流れを説明するチャート図である。なお、本システムにおいて、請求書を登録する方法には、(1)請求書情報の登録、(2)請求書のアップロードによるOCR(画像認識による自動登録)、(3)専用アドレスに請求書PDF送付によって、自動で請求情報の読み取りによる登録のいずれにも対応可能に構成されている。また、請求書データが複数ある場合は、(1)それぞれ個別に「承認」、「否認」をシステムに設定することができる。また、(2)個別は面倒となる場合に備えて、まとめて「承認」、「否認」をシステムに設定することもできる。
上記(1)、(2)のいずれの場合も、指定する方法(LINE(登録商標)等のチャットまたはメール)で通知が届き、そこで「承認」を1タップするだけで、銀行の自動引き落としを行う構成が第2の請求書アップロード処理の特徴である。
図1に示した支払い先PC7-1~7-Nによる請求書アップロード処理の流の発行を行う際、ToBPayシステムが提供するWEBページ(アップロードページ)に必要な請求項目(請求元を指定するコード、請求明細、請求総額を含む)を入力して、支払い先PC7-1~7-Nの表示装置に、例えば図26に示すUI画面を表示する。+ボタンをクリックすると、請求カテゴリ情報入力画面として、支払い先PC7-1~7-Nの表示装置に、例えば図27に示すUI画面を表示する。ここで、取引先に付与された編集ボタンをクリックすると、支払い先PC7-1~7-Nの表示装置に、例えば図28に示す請求書情報を入力するためのUI画面を表示する。
【0123】
ここで、支払い先PC7-1~7-Nの担当者は、図28に示すUI画面に対して、請求日、支払い期限、発注社名、取引先名、取引き担当者名、件名、請求金額(税抜)、備考等に必要な情報を入力することができる。
【0124】
次に、支払い先PC7-1~7-Nの担当者は、図27に示すUI画面に戻り、取引先の追加ボタンをクリックすると、支払い先PC7-1~7-Nの表示装置に、図29に示すUI画面を表示する。ここで、保存ボタンを指示すると、請求書アップロード部44は、支払い先ユーザが入力した指定される請求元に対する請求項目が記載された請求書データ(PDFファイル)を受領する。
【0125】
この作業を月締め予定日まで繰り返し、請求書アップロード部44は、支払先ユーザからアップロードされたすべての請求書を受領した旨をTP支払い元法人画面およびTP運用者画面に1回通知する。
【0126】
同様に、別のアップロードによる場合、支払い先PC7-1~7-Nの支払い先ユーザは、インターネット網Iを介して支払い元PC1-1~1-Nのいずれかの支払い元ユーザに請求書データを発行する。
【0127】
これらの各支払い先からの個別的な請求をすべて集計した後、その集計額に対する承認を求める請求書データを支払い元PC1-1~1-Nのいずれかの支払い元ユーザが受け取ると、1つの請求書データ(PDFファイル)を1タップ処理で承認すると、図44に示した支払い先への代理支払いが指示され、これを代理処理サーバ4が受領すると、図45に示すように、代理処理サーバ4が1タップ承認された支払い情報に基づき支払いが上述した代行BK5を介して実行される。
【0128】
以後、第1実施形態とは請求書の流れが逆転し、支払先に対する代行支払いが完了した後、図44に示すように、支払先が通知されている各請求書の情報をネットワークIを介して支払い元PCに対して送付する処理が実行される。これにより、事後承認的に、月締めされた各支払い先からアップロードされた支払先毎の請求書の詳細を受け取ることができる。
【0129】
ここで、第2の請求書アップロード処理におけるデータ処理の一連の流れについて一例を示して詳述する。
支払先によって、メールまたはアップロードまたは情報入力により、請求書データがシステムに登録される(1)。
次に、ToBPay側が支払先によって登録された請求書データをまとめ請求情報化する(2)。次に、支払元のユーザに対して、ステップ(2)に請求情報を主にLINE(登録商標)またはメールで通知を行う(3)。これにより、支払元のユーザは、詳細の請求書情報も確認することができる。
次に、支払元ユーザは、LINE(登録商標)またはメールで通知された請求情報を承認するか否認するかを決定する操作指示を行う(4)。ここで、支払元ユーザが承認することを決定する操作指示を行った場合、自動引き落とし申請がかかる。
次に、ToBPayによる支払先への代理支払が行われ、そして支払元からToBPayへの自動引き落としが完了する(5)。取引終了後、支払元・支払先双方は、システムに接続することで、利用明細にて、どの会社にいくら支払われたのか(支払があったのか)を画面上で確認する(6)。
このように第2の請求書アップロード処理によるToBPayによる支払によれば、支払元ユーザのPC操作だけでなく、スマートフォン操作(通知をワンタップするだけでOK)で支払い指示が完了できる。よって、支払元のユーザは、PCによって支払い操作を行うこともできるとともに、出先においては、スマートフォン操作にて支払い指示を完了することができ、操作性が格段に向上する。
さらに、ToBPay利用ユーザの作業軽減としては、(1)請求書の取りまとめ、(2)請求書から振込データ作成、(3)振込作業、(4)消込、(5)仕訳、(6)(2)~(5)の確認などが不要になり、大幅に業務工数削減となる。
また、支払先も、これまで郵送だった支払い業務そのものが電子化されることで大幅に工数削減となる。
【0130】
〔第6実施形態の効果〕
第6実施形態により、支払元PCにおける支払い承認回数を毎月1回の承認で支払い先へ代行支払いが完了することができ、支払元PCを操作する担当者の各支払い先からアップロードされた請求書に対する承認作業を大幅に軽減することができる。
【0131】
本発明の各工程は、ネットワーク又は各種記憶媒体を介して取得したソフトウエア(プログラム)をパソコン(コンピュータ)等の処理装置(CPU、プロセッサ)にて実行することでも実現できる。
【0132】
本発明は上記実施形態に限定されるものではなく、本発明の趣旨に基づき種々の変形(各実施形態の有機的な組合せを含む)が可能であり、それらを本発明の範囲から除外するものではない。
【産業上の利用可能性】
【0133】
例えば医療機関において、ToBPayシステムを導入すると、治療のための医薬品購入費、医療設備の購入費、消耗品費等の細かい支出に際し、毎月末や指定日に取引先登録や請求業務、支払い業務がすべてなくなり、大幅な工数ダウンが期待できる。
【0134】
さらに、介護・福祉事業者において、ToBPayシステムを導入すると、施設で提供する給食費、備品購入のための介護用品費、設備導入費、事務業務で発生する印刷費等の支出に際し、請求・支払い金額の合計額や、個別の出費構成比が一目で理解できる環境を整備できる。
【0135】
以上の記載した本発明に関する開示は、少なくとも下記事項に要約することができる。
(1)支払い元の経理処理を行う複数の第1データ端末と、支払い先の経理処理を行う複数の第2データ端末と、支払い処理を実行する銀行システムと、各法人間の請求と支払いの業務を実行する代理処理サーバとが通信して支払い代行サービスを行う電子決済代行業務システムであって、前記代理処理サーバは、支払い元のいずれかの第1データ端末からアップロードされる複数の請求書データを解析して支払い総額を算出する算出手段と、前記算出手段が算出した支払い計算書データを支払い元のいずれかの第1データ端末に送信する送信手段と、前記支払い計算書データに対する支払い認証を支払い元のいずれかの第1データ端末から受領することに応じて、支払い元のデータ端末から登録された支払い先情報に従う支払い銀行口座に対して前記銀行システムを介して代理支払いを実行する代理支払い手段と、前記代理支払い手段が実行した代理支払い額データに基づく支払い完了をいずれかの第1データ端末に通知する通知手段と、を備えることを特徴とする。
【0136】
(2)前記代理処理サーバは、前記代理支払い手段が実行した代理支払いに対する手数料を計算する計算手段と、前記計算手段が計算した手数料を前記支払い元となる第1データ端末または前記支払い先に対応する第2データ端末に対して分担請求を通知する第1の手数料通知手段と、を備えることを特徴とする。
【0137】
(3)前記代理処理サーバは、前記代理支払い手段が実行した代理支払いに対する手数料を計算する計算手段と、前記計算手段が計算した手数料の請求を前記支払い元となる第1データ端末に対して通知する第2の手数料通知手段と、を備えることを特徴とする。
【0138】
(4)前記計算手段は、あらかじめ設定された分担比率に基づいて分担請求する前記支払い元となる第1データ端末または前記支払い先に対応する第2データ端末に対する手数料を計算することを特徴とする。
【0139】
(5)前記代理処理サーバは、ビジネスマイル数を記憶するビジネスマイル記憶手段と、前記第1データ端末の支払い額に応じたビジネスマイルを支払元となる法人宛に発行するマイル発行処理手段と、前記第1データ端末からの指示に従い、所要の支払いに充当するビジネスマイル数と交換するマイル交換処理手段と、を備えるビジネスマイル管理サーバと、と通信することを特徴とする。
【0140】
(6)支払い元の経理処理を行う複数の第1データ端末と、支払い先の経理処理を行う複数の第2データ端末と、支払い処理を実行する銀行システムと、各法人間の請求と支払いの業務を実行する代理処理サーバとが通信して支払い代行サービスを行う電子決済代行業務システムであって、前記代理処理サーバは、支払い元のいずれかの第1データ端末からアップロードされる複数の請求書データを解析して支払い総額を所定の月締めタイミングで算出する算出手段と、前記算出手段が算出した支払い総額に対する支払いの承認を求める指示を支払い元のいずれかの第1データ端末に1回送信する送信手段と、前記支払い元のいずれかの第1データ端末から前記支払いの承認を受け取ることに応じて、登録された支払い先情報に従う支払い銀行口座に対して前記銀行システムを介して代理支払いを実行する代理支払い手段と、前記代理支払い手段が実行した代理支払い額データに基づく支払い完了をいずれかの第1データ端末に通知する通知手段と、を備えることを特徴とする。
【0141】
(7)前記第1データ端末は、前記送信手段による承認を求める指示を承認する1タップ承認画面を表示する承認画面表示手段を備えることを特徴とする。
【0142】
(8)支払い元の経理処理を行う複数の第1データ端末と、支払い先の経理処理を行う複数の第2データ端末と、支払い処理を実行する銀行システムと、各法人間の請求と支払いの業務を実行する代理処理サーバとが通信して支払い代行サービスを行う電子決済代行業務システムの決済代行処理方法であって、前記代理処理サーバは、支払い元のいずれかの第1データ端末からアップロードされる複数の請求書データを解析して支払い総額を算出する算出ステップと、前記算出ステップが算出した支払い計算書データを支払い元のいずれかの第1データ端末に送信する送信ステップと、前記支払い計算書データに対する支払い認証を支払い元のいずれかの第1データ端末から受領することに応じて、支払い元のデータ端末から登録された支払い先情報に従う支払い銀行口座に対して前記銀行システムを介して代理支払いを実行する代理支払いステップと、前記代理支払いステップが実行した代理支払い額データに基づく支払い完了をいずれかの第1データ端末に通知する通知ステップと、を備えることを特徴とする。
【0143】
(9)支払い元の経理処理を行う複数の第1データ端末と、支払い先の経理処理を行う複数の第2データ端末と、支払い処理を実行する銀行システムと、各法人間の請求と支払いの業務を実行する代理処理サーバとが通信して支払い代行サービスを行う電子決済代行業務システムであって、前記代理処理サーバは、支払い元のいずれかの第1データ端末からアップロードされる複数の請求書データを解析して支払い総額を所定の月締めタイミングで算出する算出手段と、前記算出手段が算出した支払い総額に対する支払いの承認を求める指示を支払い元のいずれかの第1データ端末に1回送信する送信ステップと、前記支払い元のいずれかの第1データ端末から前記支払いの承認を受け取ることに応じて、登録された支払い先情報に従う支払い銀行口座に対して前記銀行システムを介して代理支払いを実行する代理支払いステップと、前記代理支払いステップで実行した代理支払い額データに基づく支払い完了をいずれかの第1データ端末に通知する通知ステップと、を備えることを特徴とする。
なお、この発明の明細書および特許請求の範囲において、用語「第1」および「第2」は、同称の要素、位置等を単に区別するために用いられている。
【符号の説明】
【0144】
1-1~1-N 支払い元PC
4 代理処理サーバ
5 代行銀行
7-1~7-N 支払い先PC
8 BM管理サーバ
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22
図23
図24
図25
図26
図27
図28
図29
図30
図31
図32
図33
図34
図35
図36
図37
図38
図39
図40
図41
図42
図43
図44
図45