Processing

Please wait...

Settings

Settings

Goto Application

1. WO2020116337 - SETTLEMENT OPERATION SUPPORT SYSTEM AND SETTLEMENT OPERATION SUPPORT METHOD

Document

明 細 書

発明の名称 決済業務支援システムおよび決済業務支援方法

技術分野

0001  

背景技術

0002   0003   0004   0005   0006   0007  

先行技術文献

特許文献

0008  

発明の概要

発明が解決しようとする課題

0009   0010   0011  

課題を解決するための手段

0012   0013  

発明の効果

0014  

図面の簡単な説明

0015  

発明を実施するための形態

0016   0017   0018   0019   0020   0021   0022   0023   0024   0025   0026   0027   0028   0029   0030   0031   0032   0033   0034   0035   0036   0037   0038   0039   0040   0041   0042   0043   0044   0045   0046   0047   0048   0049   0050   0051   0052   0053   0054   0055   0056   0057   0058   0059   0060   0061   0062   0063   0064   0065   0066   0067   0068   0069   0070   0071   0072   0073   0074   0075   0076   0077   0078   0079   0080   0081   0082   0083   0084   0085   0086   0087   0088   0089   0090   0091   0092   0093   0094   0095   0096   0097   0098   0099   0100  

符号の説明

0101  

請求の範囲

1   2   3   4   5   6   7   8   9   10   11   12   13   14  

図面

1   2   3   4   5   6   7   8   9   10   11   12  

明 細 書

発明の名称 : 決済業務支援システムおよび決済業務支援方法

技術分野

[0001]
 本発明は、決済業務支援システムおよび決済業務支援方法に関する。

背景技術

[0002]
 サプライチェーンを構成するバイヤとサプライヤの間など、各企業の取引先や提携先の各間での、受発注業務を中心とした業務連携支援を行うサービス基盤が存在する。
[0003]
 こうしたサービス基盤では、インターネット上での企業取引の場として、業種や業務、役割などに応じた種々のアプリケーションサービス(SaaS)が提供され、例えば上述の受発注業務も、そのステータスを管理しつつ、効率的かつシームレスに遂行可能となっている。
[0004]
 一方、そうした受発注業務に伴う決済業務に関しては、上述のサービス基盤のスコープ外であった。したがって決済業務に関しては、従来どおり当事者間で直接連絡をとりあって処理を進める傾向にある。
[0005]
 そこで、決済業務の効率化等に関する従来技術として、例えば、売掛金に関する売掛金情報を記憶する売掛金情報データベースを有し、各企業に設置される企業センタと、口座情報を管理する金融機関センタと、利用者からの要求に応じて売掛金の支払を前記金融機関センタに依頼する支払受付装置と、を備える入金確認システムであって、前記企業センタは、利用者からの支払要求を受け付けた前記支払受付装置からの所定の要求に応答して、当該要求により指定された売掛金情報に対して照合情報を付与し、該照合情報を前記支払受付装置に送信し、前記支払受付装置は、利用者からの支払要求の入力に応じて前記企業センタから取得した前記照合情報を、資金移動を依頼するための資金移動依頼電文に含めて前記金融機関センタに送信し、前記金融機関センタは、前記支払受付装置から受信した資金移動依頼電文に応じて所定口座への入金処理を行い、前記資金移動依頼電文に含まれる前記照合情報を含む入金情報を生成し、前記企業センタは、前記金融機関センタから前記入金情報を取得し、当該入金情報に含まれる前記照合情報をキーとして前記売掛金情報データベースを参照し、該当する売掛金情報について所定の消込処理を行う、ことを特徴とする入金確認システム(特許文献1参照)などが提案されている。
[0006]
 また、各請求明細毎に与えられた請求明細データに、各請求明細の支払期限毎に同一の振込識別番号を付与する識別番号付与手段と、振込識別番号が同一の請求明細の請求金額を合算し、該合算された請求金額に前記振込識別番号を関連づけた振込データを生成する振込データ生成手段と、前記振込識別番号が付与された前記請求明細データ又は前記振込データと、実際に支払期限毎に入金がなされた入金情報を照合し、消込処理を行う消込処理手段とを具備してなることを特徴とする決済管理システム(特許文献2参照)なども提案されている。
[0007]
 また、売り手と買い手の間の取引を支援する取引支援サーバであって、前記売り手が処理する際の表現形式で表現された商品識別情報、商品数量、および商品単価を含む前記売り手の受渡データと、前記買い手が処理する際の表現形式で表現された商品識別情報、商品数量、および商品単価を含む前記買い手の受渡データとを対応付けるための情報を格納する取引データ格納部と、前記取引に起因して発生した前記売り手の受渡データを前記売り手の端末から受信する売り手データ受信部と、前記取引に起因して発生した前記買い手の受渡データを前記買い手の端末から受信する買い手データ受信部と、前記取引データ格納部を用いて、前記売り手データ受信部が受信した前記売り手の受渡データと、前記買い手データ受信部が受信した前記買い手の受渡データとを対応付けるマッチング部と、前記マッチング部が対応付けた前記売り手の受渡データおよび前記買い手の受渡データの少なくとも一方を、前記売り手および前記買い手の少なくとも一方の端末に出力する出力部とを備えることを特徴とする取引支援サーバ(特許文献3参照)なども提案されている。

先行技術文献

特許文献

[0008]
特許文献1 : 特開2001-250074号公報
特許文献2 : 特開2002-216039号公報
特許文献3 : 特開2003-233765号公報

発明の概要

発明が解決しようとする課題

[0009]
 ところで、上述の如きサービス基盤を離れて行う決済業務において、各企業の担当者らは、膨大な数の受発注案件ごとに、その支払・入金の確認と消込(リコンサイル)の作業を行っている。その手間は、企業規模が大きいほど、また受発注案件の数が多いほど大きくなり、非常に煩雑な事務作業となる。
[0010]
 また、そうした支払・入金および消込の各作業は、該当作業の契機となる他作業等のステータスを確認した上で行うべきものであるが、この確認を効率的かつ確実に行える状況にない。担当者らは、取引相手の担当者と逐次連絡を取り合って確認を行うケースが多く、その作業効率や即時性、確認結果の正確性のいずれも好適とは言い難い。
 また、ステータスに関する情報の管理体制が不十分であれば、改ざん等の不適切な事態が発生して、公正な取引環境が損なわれる可能性もある。
[0011]
 そこで本発明の目的は、決済業務に関係する所定事象のステータスを、当事者間で漏れなく効率的に又適宜な即時性をもって管理し、決済業務の効率化を図る技術を提供することにある。

課題を解決するための手段

[0012]
 上記課題を解決する本発明の決済業務支援システムは、複数の組織それぞれのノードで構成された分散台帳システムにおいて、前記ノードのうち少なくとも所定ノードが、分散台帳を格納する記憶部と、所定組織間での受発注に伴う決済業務のトランザクションを受信し、前記分散台帳システムにおける所定の合意形成を経た上で、前記分散台帳に格納する処理と、前記決済業務における各処理のステータスを前記分散台帳のステート情報として管理する処理と、前記ステート情報における決済代金のステータスが入金完了となる事に応じ、対応する受発注案件の消込処理を行う処理と、を実行する演算部と、を備えることを特徴とする。
[0013]
 また、本発明の決済業務支援方法は、複数の組織それぞれのノードで構成された分散台帳システムにおいて、前記ノードのうち少なくとも所定ノードが、分散台帳を格納する記憶部を備えて、所定組織間での受発注に伴う決済業務のトランザクションを受信し、前記分散台帳システムにおける所定の合意形成を経た上で、前記分散台帳に格納する処理と、前記決済業務における各処理のステータスを前記分散台帳のステート情報として管理する処理と、前記ステート情報における決済代金のステータスが入金完了となる事に応じ、対応する受発注案件の消込処理を行う処理と、を実行することを特徴とする。

発明の効果

[0014]
 本発明によれば、決済業務に関係する所定事象のステータスを、当事者間で漏れなく効率的に又適宜な即時性をもって管理し、決済業務の効率化を図ることができる。

図面の簡単な説明

[0015]
[図1] 本実施形態の決済業務支援システムを含むネットワーク構成図である。
[図2] 本実施形態における決済業務支援システムのハードウェア構成例を示す図である。
[図3] 本実施形態における決済業務支援方法のフロー例1を示す図である。
[図4] 本実施形態における画面例1を示す図である。
[図5] 本実施形態における画面例2を示す図である。
[図6] 本実施形態における画面例3を示す図である。
[図7] 本実施形態における画面例4を示す図である。
[図8] 本実施形態における画面例5を示す図である。
[図9] 本実施形態における画面例6を示す図である。
[図10] 本実施形態における決済業務支援方法のフロー例2を示す図である。
[図11] 本実施形態における画面例7を示す図である。
[図12] 本実施形態における決済業務支援方法のフロー例3を示す図である。

発明を実施するための形態

[0016]
---分散台帳技術について---
[0017]
 従来行われてきた中央集権機関(例:金融機関や政府など)を経由した取引に代わる、利用者間のP2P(Peer to Peer)による直接的な取引として、分散台帳技術が登場している。
[0018]
 そうした技術としては、例えば、仮想通貨を用いることで、銀行などの中央集権機関を必要とせずに決済取引を行う技術が存在する。この技術では、P2Pネットワーク上における取引データ(以下、トランザクション)に対し、マイナーと呼ばれるノードによる正当性判定を行った後、プルーフオブワークと呼ばれる特定のハッシュ値を算出する作業で確定処理を行っている。
[0019]
 ここで確定されたトランザクションは1つのブロックにまとめられ、ブロックチェーンと呼ばれる分散台帳に記載される。なお、こうした分散台帳を保持する各ノードによって構成されるシステムを分散台帳システムと称する。
[0020]
 なお、本実施形態の決済業務支援システム10で取り扱うトランザクションは、サプライチェーンの参加者(バイヤ企業やサプライヤ企業)の各間で発生する受発注案件の決済業務に伴うものを想定する。よって、決済業務における種々の手続が各ノードで遂行されるごとにトランザクションが発行され、ノード間での適宜な合意形成を経て分散台帳に格納される。
[0021]
 ブロックチェーンの主な特徴としては、(1)分散台帳システム上の参加者間の取引において、中央集権機関ではなく(任意ないしは特定の)参加者による合意形成や承認によって取引を確定させること、(2)複数のトランザクションをブロックとしてまとめ、数珠つなぎに分散台帳に記録し、連続するブロックにハッシュ計算を施すことにより、改ざんを実質不可能にすること、(3)参加者全員が分散台帳において同一の台帳データを共有することにより、参加者全員での取引の確認を可能とすること、が挙げられる。
[0022]
 このようなブロックチェーンをはじめとした分散台帳技術は、以上のような特徴から、信頼できるデータの管理/共有や、契約に基づく取引の執行/管理を行う仕組みとして、金融分野やIoT(Internet of Thing)等、幅広い分野での応用が検討されている。
[0023]
 その一つの例に、スマートコントラクト(Smart Contract)の存在が挙げられる。スマートコントラクトは、デジタル化(ソフトウェアプログラム化)された契約とも言われ、台帳データの入力、出力などの処理をプログラム的に記述することで実現される。分散台帳システムにおける各ノードは、互いの合意形成を図りつつ、こうしたスマートコントラクトを実行し、その実行結果等でそれぞれの台帳データを更新する。
[0024]
 ここで、本実施形態の説明にあたり、以下のように用語を定義する。まず、分散台帳は、分散台帳システムを構成する複数のノード(分散台帳ノード)の間で取り扱う台帳データをセキュアに共有することを特徴とする分散データベースである。こうした分散台帳はブロックチェーンとも呼ばれる。
[0025]
 またここでは、上述の分散台帳システムの形態のうち、パーミッション型(コンソーシアム型とも呼ばれる)を想定している。本実施形態における分散台帳システムの参加者としては、サプライチェーンを構成するバイヤ企業、サプライヤ企業といった企業で、上述のサービス基盤(受発注業務を中心とした業務連携支援を行う既存のサービス基盤)での利用登録を経たユーザ、である故である。勿論、こうした想定はあくまでも一例であって、他の分散台帳システムの形態を適宜に採用してよい。また、分散台帳システムにおいては、上述したデータの共有のために、ハッシュチェーンやコンセンサスプロトコルなどの要素技術が用いられている。
[0026]
 また、上述の分散台帳で保持される台帳データは、そのデータ構造として、RDB(Relational DataBase)やKVS(Key-Value Store)などの各種データ構造を適宜に採用しうる。こうしたデータ構造は、分散台帳システムの利用者により規定することが可能である。
[0027]
 なお、ブロックチェーンを用いた分散台帳管理では、通常、(最新の)ステート(例えば決済業務の場合では、請求登録の内容や未済、支払手続や入金の内容や未済など)を取得するためには、ブロックチェーンを辿らなければならない。ところが、これでは処理効率が悪いため、ブロックチェーンとは別に、最新のステート情報をキャッシュしておく方法(例えば、"Hyperledger Fabric", [online]、[平成29年3月31日検索]、インターネット<URL:http://hyperledger-fabric.readthedocs.io/en/latest/>)が存在する。
[0028]
 よって本実施例でも最新のステート情報を分散台帳上で管理することを想定する。ステート情報は、例えば、受発注案件における請求書のIDをキーに、当該案件における各段階の決済処理のステータスを紐付けるといった、上述のKVSのデータ構造で管理される。
[0029]
 これにより、分散台帳システムのノードらは、例えば、受発注案件の請求書IDをキーにして、該当案件の決済処理のステータスを取得することができる。ノードらは、本実施形態の決済業務支援方法に沿った処理に伴い、トランザクションを発行・格納する度にこのステート情報を更新する。
[0030]
 また、上述のスマートコントラクトは、台帳データの入力、出力などの処理を記述したプログラムであるとする。スマートコントラクトは、分散台帳システムに所属するノード(分散台帳ノード)にインストールされ、適宜のタイミングで実行される。
[0031]
 スマートコントラクトを実行するノードは、必ずしも分散台帳システムに所属する全ノードとは限らないが、スマートコントラクトの実行結果にしたがって、分散台帳システムに所属する全ノードが各自の台帳データを更新する。
[0032]
 また、トランザクションは、上述のノード各々が、コンセンサスプロトコルなどに基づいて連動しながらスマートコントラクトを実行することで行う処理それぞれのことである。トランザクションの例には、台帳データの参照や、台帳データの更新などを含む。
[0033]
 トランザクションには引数(リクエストのパラメータ)を含む。トランザクション引数の例には、参照対象のデータのキー(すなわち請求書IDなど)や、更新対象のデータのキーおよび更新後の値(value)を含む。
[0034]
 なお、上述の分散台帳技術に関する説明は、以降の説明で重ねて説明しない。よって、特に必要が無い限り、分散台帳技術に関する具体的な説明や図示は適宜省略するものとする。
---ネットワーク構成---
 以下に本発明の実施形態について図面を用いて詳細に説明する。図1は、本実施形態の決済業務支援システム10を含むネットワーク構成図である。
[0035]
 図1に示す決済業務支援システム10は、決済業務に関係する所定事象のステータスを、当事者間で漏れなく効率的に又適宜な即時性をもって管理し、決済業務の効率化を図るコンピュータシステムである。
 図1に示す分散台帳システム5の利用者、すなわち受発注案件を抱える企業は、例えば、サプライチェーンを構成するバイヤとサプライヤである。
[0036]
 こうした企業は、それぞれノードを運用している。このうち、バイヤ企業のノードをバイヤ端末20、サプライヤ企業のノードをサプライヤ端末30とする。また、これらバイヤ端末20やサプライヤ端末30らは、インターネットなど適宜なネットワーク1を介して、相互に通信可能である。
[0037]
 また、バイヤ端末20やサプライヤ端末30は、既に述べた受発注業務を行うプラットフォームたる受発注システム2(サービス基盤)に対し、所定の認証処理を経てアクセス可能な端末である。つまり、受発注システム2において、バイヤ企業はバイヤ端末20を操作してサプライヤ企業に対して資材等を発注し、サプライヤ企業はサプライヤ端末30を介して受注を行う。その後、サプライヤ企業は、受注した該当資材等をバイヤ企業に納品して検収を受けることとなる。
[0038]
 本実施形態の決済業務支援システム10は、こうした受発注システム2で処理される受発注案件のうち、バイヤ企業による検収が完了したものについて、例えば、受発注システム2から通知を受け、これを契機として必要な処理を開始する。
[0039]
 こうした決済業務支援システム10は、上述のように決済業務支援方法を主導する管理システムとしての側面を備える他、分散台帳システム5におけるノード(分散台帳ノード)の1つでもある。この場合の決済業務支援システム10は、バイヤ端末20やサプライヤ端末30と適宜に協働し、自身での処理を契機としたトランザクションの発行、合意形成、分散台帳への格納といった一連の処理を遂行可能である。
[0040]
 また、決済業務支援システム10は、ユーザによる入金確認指示を受けて、またはステート情報における決済代金の支払手続のステータスに応じて、銀行システム40やデジタル通貨システム50などの適宜な金融機関システムに対し、バイヤ企業からサプライヤ企業に宛てた所定額の入金(所定の請求書に関するもの)がなされたか問い合わせを行い、当該入金が確認された場合、該当請求書の決済業務に関する入金完了のトランザクションを発行し、合意形成を経て分散台帳に格納し、また、ステート情報におけるステータスを「入金完了」に更新する。
[0041]
 或いは、決済業務支援システム10は、例えば、或る請求書に関して、バイヤ端末20からサプライヤ企業に宛てた所定額の支払手続(入金処理)の要求を受けて、上述の銀行システム40やデジタル通貨システム50などの適宜な金融機関システムに対し、上述の請求書が示す内容での入金処理を指示する。決済業務支援システム10は、この指示に応じた入金処理の結果を該当金融機関システムから取得し、入金処理の完了が確認された場合、該当請求書の決済業務に関する入金完了のトランザクションを発行し、合意形成を経て分散台帳に格納し、また、ステート情報におけるステータスを「入金完了」に更新する。
[0042]
 上述のようにステート情報におけるステータスを「入金完了」と更新する動作は、該当受発注案件の消込処理に該当する。つまり、該当受発注案件の請求登録から支払手続の登録、および入金処理を経て、必要な決済業務が完了したことを意味する。
---ハードウェア構成---
[0043]
 また、決済業務支援システム10のハードウェア構成は以下の如くとなる。図2は、本実施形態における決済業務支援システム10のハードウェア構成例を示す図である。
[0044]
 この場合の決済業務支援システム10は、SSD(Solid State Drive)やハードディスクドライブなど適宜な不揮発性記憶素子で構成される記憶部11、RAMなど揮発性記憶素子で構成されるメモリ13、記憶部11に保持されるプログラム12をメモリ13に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうCPUなどの演算部14、および、ネットワーク1と接続し他の装置との通信処理を担う通信部15、を備える。
[0045]
 なお、決済業務支援システム10は、ユーザからのキー入力や音声入力を受け付ける入力部や、処理データの表示を行うディスプレイ等の出力部を必要に応じて備えるとしてもよい。
[0046]
 なお、記憶部11内には、本実施形態の決済業務支援システム10として必要な機能を実装する為のプログラム12に加えて、分散台帳100、ブロックチェーン111、ステート情報112、および、スマートコントラクト113が少なくとも記憶されている。
 こうした決済業務支援システム10のハードウェア構成は、バイヤ端末20やサプライヤ端末30についても同様である。
---決済業務支援方法の実行例---
[0047]
 以下、本実施形態における決済業務支援方法の実際手順について図に基づき説明する。以下で説明する決済業務支援方法に対応する各種動作は、決済業務支援システム10やバイヤ端末20、サプライヤ端末30などの各ノードが、メモリ等に読み出して実行するプログラムによって実現される。そして、このプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。
[0048]
 図3は、本実施形態における決済業務支援方法のフロー例1を示す図である。ここでは、フロー開始契機の一例として、決済業務支援システム10が、或る受発注案件に関して、受発注システム2ないしバイヤ端末20から「検収完了」の通知を受けたことを想定する。
[0049]
 勿論、この通知には受発注案件の識別情報(例:注文書番号)、案件名/品名、受注金額、入金予定額、入金予定日、バイヤ企業、サプライヤ企業、および支払単位の内容、といった、受発注契約が含みうる各種情報が含まれている。
[0050]
 そこで決済業務支援システム10は、上述の「検収完了」の通知を受けた受発注案件に関して、当該通知に関してトランザクションを発行し、合意形成を経て分散台帳110に格納する(s10)。またs10における決済業務支援システム10は、このトランザクションに関する情報を、ステート情報112に格納する。
[0051]
 なお、ステート情報112に格納されている各情報は、バイヤ企業やサプライヤ企業といったステークホルダーのバリューごとに切り分けてアクセス制御され、当該ステークホルダーのノード、すなわちバイヤ端末20やサプライヤ端末30に配信される。つまり、バイヤ企業やサプライヤ企業は、自身が関与している受発注案件に関するステート情報112のみ閲覧可能である。
[0052]
 そうした閲覧の様子は、図4における取引案件の一覧画面400に示すとおりである。この一覧画面400は、「受注」と「発注」の2つのシートがタブで選択可能なインターフェイス構成となっている。つまり、ステークホルダーたる各企業は、受発注の立場によってバイヤ企業とサプライヤ企業のいずれにもなりうることに対応した構成である。
 また、各シートは、日時、注文書番号、案件/品名、入金予定日、ステータス、および、最終手続者、といった項目を含むレコードから構成される。
[0053]
 上述の例の場合、「受注」シートにおける、日時「2018/8/23」、注文書番号「0000001」、案件/品名「Aプロジェクト:ブレーキキャリパ」、入金予定日「2018/8/31」、ステータス「検収完了」、および、最終手続者「XX社(Buy_B)」のレコードが、「検収完了」の通知に応じてステート情報112に格納されたものに該当する。
[0054]
 そこでこの一覧画面400を閲覧中の担当者(立場としてはサプライヤ企業の担当者)は、サプライヤ端末30を操作して、例えば、該当レコードをクリックし、検収内容(図5:検収内容の確認画面500)の確認を経て、請求情報の登録ボタン501をクリックする。なお、サプライヤ企業側で複数の検収完了案件をまとめて1件の請求情報として登録する形態も採用しうる。
[0055]
 一方、決済業務支援システム10は、上述の登録ボタン501のクリックを受けて、例えば、請求書番号を所定ルールで生成するなどし、請求書番号「A1」、注文書番号「0000001」、品名「ブレーキキャリパ」、数量「500台」、請求金額「¥15、000、000」、請求先企業「XX社」、請求元企業「YY社」、振込先「○○銀行、○○支店、普通口座○○○○」、締日(払込期限)「2018/08/31」、といった各値を含む請求情報を生成し、これを請求情報の確認画面600(図6参照)などとして上述のサプライヤ端末30に配信する(s11)。
 続いて上述の担当者は、上述の確認画面600にて例えば請求書の登録ボタン601をクリックしたとする。
[0056]
 一方、決済業務支援システム10は、上述の登録ボタン601のクリックを受け、該当受発注案件に関して、当該請求書の登録・発行に関するトランザクションを発行し、合意形成を経て分散台帳110に格納する(s12)。
[0057]
 またs12における決済業務支援システム10は、このトランザクションの発行に伴い、当該受発注案件に関するステート情報112のレコード(keyが「A10000001」のレコード)において、そのステータスを「請求書発行」などと更新する。この処理にて、請求情報の登録・発行、すなわち請求登録が完了したこととなる。
[0058]
 なお、ここでステート情報112で更新される該当レコードは、そのkeyとして、例えば、請求書番号「A1」と注文書番号「0000001」をマージした、「A10000001」といった値を想定する。
 また、決済業務支援システム10は、上述の請求情報が含む取引先「XX社」のバイヤ端末20に宛てて、請求書発行通知を送信する(s13)。
[0059]
 具体的には、決済業務支援システム10は、例えば上述のs12の処理を受けて、例えば、取引先「XX社」のバイヤ端末20で表示中の、取引案件の一覧画面700(図7参照)において、該当レコード(注文書番号「0000001」のレコード)の表示形態が他のレコードと異なるよう、フォントサイズの拡大、下線付与、太字化、文字色変更、といった強調表示制御を行い、ステータスが「請求書発行」となった旨をバイヤ企業の担当者に認識されやすくする。或いは、より単純に、該当受発注案件(注文書番号「0000001」の案件)に関して請求書が発行された旨のメッセージを、一覧画面700の所定箇所に表示させるとしてもよい。
[0060]
 なお、この一覧画面700は、図4の一覧画面400と同様、「受注」と「発注」の2つのシートがタブで選択可能なインターフェイス構成となっている。ただし、上述の状況では、バイヤ企業としての立場で一覧画面700が閲覧されており、「発注」シートが表示された状態となっている。
[0061]
 そこでこの一覧画面700を閲覧中の担当者(立場としてはバイヤ企業の担当者)は、バイヤ端末20を操作して、例えば、該当レコードをクリックし、請求書の内容(図8:請求内容の確認画面800)の確認を経て、支払手続のボタン801をクリックする。
 この場合、バイヤ端末20は、そのクリック事象を決済業務支援システム10に通知する。
[0062]
 通知を受けた決済業務支援システム10は、当該請求書が示す「振込先」への振込可能な金融機関のシステムに対し、上述の請求書が示す内容での振込処理を指示する(s14)。この場合の金融機関のシステムとは、銀行システム40やデジタル通貨システム50が該当する。なお、上述の振込処理は、振込元(バイヤ企業の口座)と振込先(サプライヤ企業の口座)とで金融機関が異なるケースと同一であるケースのいずれも想定できる。
[0063]
 他方、振込指示を受けた金融機関のシステムは、その指示内容に応じて、バイヤ企業に関して管理している所定額の資金を、サプライヤ企業の指定口座等に移動させる、つまり振込処理を実行する。また、この振込処理の結果を、上述の決済業務支援システム10(バイヤ端末20も含めてよい)に通知する。
[0064]
 ただし、金融機関ごとの特性により、こうした振込処理のタイミング(早さ)は異なるため、デジタル通貨システム50のように、振込処理の指示から即時性を持って振込処理とその結果の通知が行われるケースと、銀行システム40のように、月次のバッチ処理等でまとめて処理を行うケースとが想定される。
[0065]
 続いて、決済業務支援システム10は、上述の振込処理に伴い、該当請求書が示す金額での支払情報の登録に関するトランザクションを発行し、合意形成を経て分散台帳に格納する(s15)。この場合の決済業務支援システム10は、ステート情報112における該当請求書に関するステータスを例えば「支払情報登録済」或いは「支払完了」などと更新する。
[0066]
 なお、上述のs15に関する各処理は、振込処理の形態や、当該振込処理に関与する金融機関で採用している資金移動形態によって、後述するs16と同時に実行されることになる。例えば、振込処理がバッチ処理の形態で月末締めなどで行われる場合、振込処理の指示から実際の資金移動まで十分な時間差が生じる状況が想定され、その場合、s15は単独で実行される。一方、振込処理の指示からほぼ即時に資金移動が実行される形態の場合、上述のような時間差が殆ど生じないため、s15とs16は同時実行されることとなる。
[0067]
 決済業務支援システム10は、上述の金融機関のシステムから振込処理の結果の通知を受け、該当請求書が示す金額での入金処理の完了を確認したならば、該当請求書の決済業務に関する入金完了のトランザクションを発行し、合意形成を経て分散台帳に格納する(s16)。なお、上述の一連の入金処理に関する処理は、注文書番号や請求書番号などの識別情報をキーに、(適宜に受発注システム2などのEDI機能と連携しつつ)行われる状況を想定できる。こうした構成は、他の処理に関しても同様に適用しうるものとする。
[0068]
 また、決済業務支援システム10は、ステート情報112における該当請求書に関するステータスを「入金完了」に更新する。このようにステート情報112におけるステータスを「入金完了」と更新する動作は、該当受発注案件の決済業務に関する消込処理に該当する。つまり、該当受発注案件の請求登録から支払手続の登録、および入金処理を経て、必要な決済業務が完了したことを意味する。
[0069]
 なお、上述の例では、支払手続のボタン801のクリックに伴い、バイヤ端末20がそのクリック事象を決済業務支援システム10に通知し、振込処理の指示を決済業務支援システム10が実行するとした。
[0070]
 しかし、そうした形態とは異なり、サプライヤ端末30が、上述の「振込先」への振込可能な金融機関のシステムに対し、照会用のAPI等を介して入金確認処理を実行し、当該サプライヤ企業宛の入金履歴を取得・出力し、サプライヤの担当者等による当該請求書が示す内容での振込処理の確認を行わせるとしてもよい。この場合、サプライヤ端末30は、上述の担当者等による入金確認の結果(入金が確認できた旨の結果)を決済業務支援システム10に通知する。一方、これを受けた決済業務支援システム10は、該当請求書の決済業務に関する入金完了のトランザクションの発行、分散台帳への格納といった処理を行うこととなる。こうした形態は、例えば、該当金融機関が決済業務支援システム10に対して振込処理に関するAPIを開放しておらず、バイヤ企業による振込処理を、サプライヤ端末30による照会でしか確認できないといった状況に対して有効である。
[0071]
 なお、上述の処理のうちs13にて請求書発行通知が送信されたバイヤ端末20において、バイヤ企業の担当者が、一覧画面700(図7)にて該当レコードをクリックし、請求書の内容(図8:請求内容の確認画面800)の確認を経て、所望の支払方法を指定した上で支払手続のボタン801をクリックする形態も想定できる。
[0072]
 例えば、一覧画面700におけるインターフェイスたるチェックボックス901(図9参照)で、上述の担当者が、所望の支払方法として所定回数での分割払いを指定した上で、ボタン801をクリックしたとする。すると、これを受けたバイヤ端末20は、インターフェイス901での指定内容の値を決済業務支援システム10に通知する。なお、上述の分割払いの回数については、バイヤ企業とサプライヤ企業との間での所定の契約や受発注に際して予め規定しておいたものであり、担当者の指定動作は、上述のチェックボックス901でそれを希望したことにあたる。ただし、この形態に限定せず、バイヤ企業が都度、分割払いの回数を指定する形態も想定できる。
[0073]
 この場合、図10のフローで示すように、決済業務支援システム10は、対象のレコード(請求登録)が示す決済代金の額を指定回数で分割した額での、指定回数に応じた数の支払手続に関するトランザクションを発行し、合意形成を経た上で当該トランザクションを分散台帳110に格納する(s20)。
[0074]
 また、決済業務支援システム10は、s20に伴い、ステート情報112における該当請求書に関するステータスを「支払登録完了」に更新し(s21)、本フローを終了する。以降の処理は、一覧画面700の「発注」シートにおける該当レコード(指定回数分に分割した数のレコード)の表示と、これに対する支払手続のボタン801のクリックを受けた振込処理など、同様に実行する。
[0075]
 また、上述の処理のうちs13にて請求書発行通知が送信されたバイヤ端末20において、バイヤ企業の担当者が指定する所望の支払方法として、分割払いではなくまとめ払いであるケースも想定できる。
[0076]
 例えば、一覧画面700におけるインターフェイス1101(図11における星形のオブジェクト参照)で、上述の担当者が、所望の支払方法として複数の請求書をまとめた一括払いを指定した上で、ボタン801をクリックしたとする。すると、これを受けたバイヤ端末20は、インターフェイス901での指定内容の値を決済業務支援システム10に通知する。
[0077]
 この場合、図12のフローで示すように、決済業務支援システム10は、対象の各レコード(請求登録)が示す決済代金の額を合算した額での支払手続に関するトランザクションを発行し、合意形成を経た上で当該トランザクションを分散台帳110に格納する(s30)。
[0078]
 また、決済業務支援システム10は、s30に伴い、ステート情報112における該当請求書それぞれに関するステータスを「支払登録完了」に更新し(s31)、本フローを終了する。以降の処理は、一覧画面700の「発注」シートにおける該当レコード(複数の請求書の内容をまとめて1つにしたレコード)の表示と、これに対する支払手続のボタン801のクリックを受けた振込処理など、同様に実行する。
[0079]
 以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。
[0080]
 こうした本実施形態によれば、既存のサービス基盤上での受発注業務に伴い、その検収ステータスを契機にした決済業務を適宜に支援する。例えば、請求の登録から当該請求に対する支払のオペレーションに際し、請求から消込までの各ステータスが当事者間でリアルタイム共有可能となる。こうした対応は、分散台帳技術(ブロックチェーン)を基盤としたサービス提供形態で実現されるため、上述の請求や支払等に関する各種データの真正性や網羅性が保証され、最終的な消込処理の信頼性も好適なものとなる。
[0081]
 また、税制など法制度(例:適格請求書等保存方式など)の改訂等に対応した請求書の作成・保存管理などについてシステム側で適宜に対応し、利用者側の負担を回避しつつ、当該サービスの導入・適用が容易となる。
[0082]
 したがって、決済業務に関係する所定事象のステータスを、当事者間で漏れなく効率的に又適宜な即時性をもって管理し、決済業務の効率化を図ることが可能となる。
[0083]
 本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態の決済業務支援システムにおいて、前記所定ノードは、ユーザによる入金確認指示を受けて、または前記ステート情報における決済代金の支払手続のステータスに応じて、所定の金融機関のシステムから所定口座に関する入金事象の情報を取得する処理と、当該情報が前記受発注案件の決済代金の入金を示すものであれば、前記決済代金の入金に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納する処理と、前記決済代金のステータスを前記ステート情報において入金完了に更新する処理を実行するものである、としてもよい。
[0084]
 これによれば、決済業務支援システム側で決済代金の入金状況をチェックし、この結果に応じて消込処理の契機を的確に判断し、該当処理を遂行可能となる。ひいては、決済業務に関係する所定事象のステータスを、当事者間で漏れなく効率的に又適宜な即時性をもって管理し、決済業務のさらなる効率化を図ることが可能となる。
[0085]
 また、本実施形態の決済業務支援システムにおいて、前記所定ノードは、前記ステート情報を参照して、予め定めた条件の所定組織または前記所定ノードの運用組織の受発注案件に伴う決済業務の各処理のステータスを特定し、前記各処理のステータスを出力部に表示するものである、としてもよい。
[0086]
 これによれば、バイヤやサプライヤなどの各組織で、自身が関わる受発注案件の決済業務に関するステータスを確実かつ簡便にチェック可能となり、決済業務の遂行に必要な各手続も的確に行えることにつながる。ひいては、決済業務に関係する所定事象のステータスを、当事者間で漏れなく効率的に又適宜な即時性をもって管理し、決済業務のさらなる効率化を図ることが可能となる。
[0087]
 また、本実施形態の決済業務支援システムにおいて、前記所定ノードは、前記出力部にステータスを表示した前記各処理のうち、請求登録の処理であってステータスが完了を示しているものについて、支払登録を行う旨のユーザ指示を受けた場合、前記請求登録が示す決済代金の額での支払手続に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納し、前記支払手続のステータスを前記ステート情報において支払登録完了に更新するものである、としてもよい。
[0088]
 これによれば、請求登録完了を認識したユーザによる支払手続の登録が漏れなく実行され、そのステータスも管理されることとなる。ひいては、決済業務に関係する所定事象のステータスを、当事者間で漏れなく効率的に又適宜な即時性をもって管理し、決済業務のさらなる効率化を図ることが可能となる。
[0089]
 また、本実施形態の決済業務支援システムにおいて、前記所定ノードは、前記出力部にステータスを表示した前記各処理のうち、請求登録の処理であってステータスが完了を示しているものについて、支払を所定回数に分割する旨のユーザ指示を受けた場合、前記請求登録が示す決済代金の額を前記所定回数で分割した額での、前記所定回数に応じた数の支払手続に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納し、前記支払手続のステータスを前記ステート情報において支払登録完了に更新するものである、としてもよい。
[0090]
 これによれば、請求登録が示す決済代金について分割での支払対象とすることが可能で、各組織のニーズに応じた決済業務の遂行が可能となる。ひいては、決済業務に関係する所定事象のステータスを、当事者間で漏れなく効率的に又適宜な即時性をもって管理し、決済業務のさらなる効率化を図ることが可能となる。
[0091]
 また、本実施形態の決済業務支援システムにおいて、前記所定ノードは、前記出力部にステータスを表示した各受発注案件に関する前記各処理のうち、請求登録の処理であってステータスが完了を示しているものについて、所定の受発注案件群の支払をまとめて支払う旨のユーザ指示を受けた場合、当該受発注案件群を構成する各受発注案件の前記決済代金の合計額での支払手続に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納し、前記支払手続のステータスを前記ステート情報において支払登録完了に更新するものである、としてもよい。
[0092]
 これによれば、複数の受発注案件に関する請求登録をまとめて支払対象とすることが可能で、各組織のニーズに応じた決済業務の遂行が可能となる。ひいては、決済業務に関係する所定事象のステータスを、当事者間で漏れなく効率的に又適宜な即時性をもって管理し、決済業務のさらなる効率化を図ることが可能となる。
[0093]
 また、本実施形態の決済業務支援システムにおいて、前記分散台帳システムのノードのうち予め定めた特定ノードが、前記消込処理と、前記入金事象の情報を取得する処理と、前記決済代金の入金に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納する処理と、前記決済代金のステータスを前記ステート情報において入金完了に更新する処理と、を実行するものである、としてもよい。
[0094]
 これによれば、分散台帳システムにおける、各参加企業のノード(分散台帳ノード)と、分散台帳システムの運用企業等の特定ノード(決済システム)とで適宜に役割分担し、消込処理など特定処理については特定ノードで行うといった構成で、決済業務支援方法を遂行可能となる。ひいては、決済業務に関係する所定事象のステータスを、当事者間で漏れなく効率的に又適宜な即時性をもって管理し、決済業務のさらなる効率化を図ることが可能となる。
[0095]
 また、本実施形態の決済業務支援方法において、前記所定ノードが、ユーザによる入金確認指示を受けて、または前記ステート情報における決済代金の支払手続のステータスに応じて、所定の金融機関のシステムから所定口座に関する入金事象の情報を取得する処理と、当該情報が前記受発注案件の決済代金の入金を示すものであれば、前記決済代金の入金に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納する処理と、前記決済代金のステータスを前記ステート情報において入金完了に更新する処理と、を実行するとしてもよい。
[0096]
 また、本実施形態の決済業務支援方法において、前記所定ノードが、前記ステート情報を参照して、予め定めた条件の所定組織または前記所定ノードの運用組織の受発注案件に伴う決済業務の各処理のステータスを特定し、前記各処理のステータスを出力部に表示する、としてもよい。
[0097]
 また、本実施形態の決済業務支援方法において、前記所定ノードが、前記出力部にステータスを表示した前記各処理のうち、請求登録の処理であってステータスが完了を示しているものについて、支払登録を行う旨のユーザ指示を受けた場合、前記請求登録が示す決済代金の額での支払手続に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納し、前記支払手続のステータスを前記ステート情報において支払登録完了に更新する、としてもよい。
[0098]
 また、本実施形態の決済業務支援方法において、前記所定ノードが、前記出力部にステータスを表示した前記各処理のうち、請求登録の処理であってステータスが完了を示しているものについて、支払を所定回数に分割する旨のユーザ指示を受けた場合、前記請求登録が示す決済代金の額を前記所定回数で分割した額での、前記所定回数に応じた数の支払手続に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納し、前記支払手続のステータスを前記ステート情報において支払登録完了に更新する、としてもよい。
[0099]
 また、本実施形態の決済業務支援方法において、前記所定ノードが、前記出力部にステータスを表示した各受発注案件に関する前記各処理のうち、請求登録の処理であってステータスが完了を示しているものについて、所定の受発注案件群の支払をまとめて支払う旨のユーザ指示を受けた場合、当該受発注案件群を構成する各受発注案件の前記決済代金の合計額での支払手続に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納し、前記支払手続のステータスを前記ステート情報において支払登録完了に更新する、としてもよい。
[0100]
 また、本実施形態の決済業務支援方法において、前記分散台帳システムのノードのうち予め定めた特定ノードが、前記消込処理と、前記入金事象の情報を取得する処理と、前記決済代金の入金に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納する処理と、前記決済代金のステータスを前記ステート情報において入金完了に更新する処理と、を実行するとしてもよい。

符号の説明

[0101]
1  ネットワーク
2  受発注システム(サービス基盤)
5  分散台帳システム
10 決済業務支援システム
11 記憶部
12 プログラム
13 メモリ
14 演算部
15 通信部
110 分散台帳
111 ブロックチェーン
112 ステート情報
113 スマートコントラクト
20 バイヤ端末
30 サプライヤ端末
40 銀行システム
50 デジタル通貨システム

請求の範囲

[請求項1]
 複数の組織それぞれのノードで構成された分散台帳システムにおいて、前記ノードのうち少なくとも所定ノードが、
 分散台帳を格納する記憶部と、
 所定組織間での受発注に伴う決済業務のトランザクションを受信し、前記分散台帳システムにおける所定の合意形成を経た上で、前記分散台帳に格納する処理と、前記決済業務における各処理のステータスを前記分散台帳のステート情報として管理する処理と、前記ステート情報における決済代金のステータスが入金完了となる事に応じ、対応する受発注案件の消込処理を行う処理と、を実行する演算部と、
 を備えることを特徴とする決済業務支援システム。
[請求項2]
 前記所定ノードは、
 ユーザによる入金確認指示を受けて、または前記ステート情報における決済代金の支払手続のステータスに応じて、所定の金融機関のシステムから所定口座に関する入金事象の情報を取得する処理と、当該情報が前記受発注案件の決済代金の入金を示すものであれば、前記決済代金の入金に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納する処理と、前記決済代金のステータスを前記ステート情報において入金完了に更新する処理を実行するものである、
 ことを特徴とする請求項1に記載の決済業務支援システム。
[請求項3]
 前記所定ノードは、
 前記ステート情報を参照して、予め定めた条件の所定組織または前記所定ノードの運用組織の受発注案件に伴う決済業務の各処理のステータスを特定し、前記各処理のステータスを出力部に表示するものである、
 ことを特徴とする請求項2に記載の決済業務支援システム。
[請求項4]
 前記所定ノードは、
 前記出力部にステータスを表示した前記各処理のうち、請求登録の処理であってステータスが完了を示しているものについて、支払登録を行う旨のユーザ指示を受けた場合、前記請求登録が示す決済代金の額での支払手続に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納し、前記支払手続のステータスを前記ステート情報において支払登録完了に更新するものである、
 ことを特徴とする請求項3に記載の決済業務支援システム。
[請求項5]
 前記所定ノードは、
 前記出力部にステータスを表示した前記各処理のうち、請求登録の処理であってステータスが完了を示しているものについて、支払を所定回数に分割する旨のユーザ指示を受けた場合、前記請求登録が示す決済代金の額を前記所定回数で分割した額での、前記所定回数に応じた数の支払手続に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納し、前記支払手続のステータスを前記ステート情報において支払登録完了に更新するものである、
 ことを特徴とする請求項4に記載の決済業務支援システム。
[請求項6]
 前記所定ノードは、
 前記出力部にステータスを表示した各受発注案件に関する前記各処理のうち、請求登録の処理であってステータスが完了を示しているものについて、所定の受発注案件群の支払をまとめて支払う旨のユーザ指示を受けた場合、当該受発注案件群を構成する各受発注案件の前記決済代金の合計額での支払手続に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納し、前記支払手続のステータスを前記ステート情報において支払登録完了に更新するものである、
 ことを特徴とする請求項4に記載の決済業務支援システム。
[請求項7]
 前記分散台帳システムのノードのうち予め定めた特定ノードが、
 前記消込処理と、前記入金事象の情報を取得する処理と、前記決済代金の入金に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納する処理と、前記決済代金のステータスを前記ステート情報において入金完了に更新する処理と、を実行するものである、
 ことを特徴とする請求項2に記載の決済業務支援システム。
[請求項8]
 複数の組織それぞれのノードで構成された分散台帳システムにおいて、前記ノードのうち少なくとも所定ノードが、
 分散台帳を格納する記憶部を備えて、
 所定組織間での受発注に伴う決済業務のトランザクションを受信し、前記分散台帳システムにおける所定の合意形成を経た上で、前記分散台帳に格納する処理と、
 前記決済業務における各処理のステータスを前記分散台帳のステート情報として管理する処理と、
 前記ステート情報における決済代金のステータスが入金完了となる事に応じ、対応する受発注案件の消込処理を行う処理と、
 を実行することを特徴とする決済業務支援方法。
[請求項9]
 前記所定ノードが、
 ユーザによる入金確認指示を受けて、または前記ステート情報における決済代金の支払手続のステータスに応じて、所定の金融機関のシステムから所定口座に関する入金事象の情報を取得する処理と、
 当該情報が前記受発注案件の決済代金の入金を示すものであれば、前記決済代金の入金に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納する処理と、
 前記決済代金のステータスを前記ステート情報において入金完了に更新する処理と、
 を実行することを特徴とする請求項8に記載の決済業務支援方法。
[請求項10]
 前記所定ノードが、
 前記ステート情報を参照して、予め定めた条件の所定組織または前記所定ノードの運用組織の受発注案件に伴う決済業務の各処理のステータスを特定し、前記各処理のステータスを出力部に表示する、
 ことを特徴とする請求項9に記載の決済業務支援方法。
[請求項11]
 前記所定ノードが、
 前記出力部にステータスを表示した前記各処理のうち、請求登録の処理であってステータスが完了を示しているものについて、支払登録を行う旨のユーザ指示を受けた場合、前記請求登録が示す決済代金の額での支払手続に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納し、前記支払手続のステータスを前記ステート情報において支払登録完了に更新する、
 ことを特徴とする請求項10に記載の決済業務支援方法。
[請求項12]
 前記所定ノードが、
 前記出力部にステータスを表示した前記各処理のうち、請求登録の処理であってステータスが完了を示しているものについて、支払を所定回数に分割する旨のユーザ指示を受けた場合、前記請求登録が示す決済代金の額を前記所定回数で分割した額での、前記所定回数に応じた数の支払手続に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納し、前記支払手続のステータスを前記ステート情報において支払登録完了に更新する、
 ことを特徴とする請求項11に記載の決済業務支援方法。
[請求項13]
 前記所定ノードが、
 前記出力部にステータスを表示した各受発注案件に関する前記各処理のうち、請求登録の処理であってステータスが完了を示しているものについて、所定の受発注案件群の支払をまとめて支払う旨のユーザ指示を受けた場合、当該受発注案件群を構成する各受発注案件の前記決済代金の合計額での支払手続に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納し、前記支払手続のステータスを前記ステート情報において支払登録完了に更新する、
 ことを特徴とする請求項11に記載の決済業務支援方法。
[請求項14]
 前記分散台帳システムのノードのうち予め定めた特定ノードが、
 前記消込処理と、前記入金事象の情報を取得する処理と、前記決済代金の入金に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納する処理と、前記決済代金のステータスを前記ステート情報において入金完了に更新する処理と、
 を実行することを特徴とする請求項9に記載の決済業務支援方法。

図面

[ 図 1]

[ 図 2]

[ 図 3]

[ 図 4]

[ 図 5]

[ 図 6]

[ 図 7]

[ 図 8]

[ 図 9]

[ 図 10]

[ 図 11]

[ 図 12]