(57)【要約】【課題】決済業務に関係する所定事象のステータスを、当事者間で漏れなく効率的に又適宜な即時性をもって管理し、決済業務の効率化を図る。【解決手段】複数の組織それぞれのノードで構成された分散台帳システム５において、ノードのうち少なくとも所定ノード１０が、分散台帳１１０を格納する記憶部１１と、所定組織間での受発注に伴う決済業務のトランザクションを受信し、分散台帳システム５における所定の合意形成を経た上で、分散台帳１１０に格納する処理と、決済業務における各処理のステータスを分散台帳１１０のステート情報１１２として管理する処理と、ステート情報１１２における決済代金のステータスが入金完了となる事に応じ、対応する受発注案件の消込処理を行う処理を実行する演算部１４を含む構成とする。【選択図】図２
2020091695.tif 000002
【特許請求の範囲】
【請求項１】
複数の組織それぞれのノードで構成された分散台帳システムにおいて、前記ノードのうち少なくとも所定ノードが、
分散台帳を格納する記憶部と、
所定組織間での受発注に伴う決済業務のトランザクションを受信し、前記分散台帳システムにおける所定の合意形成を経た上で、前記分散台帳に格納する処理と、前記決済業務における各処理のステータスを前記分散台帳のステート情報として管理する処理と、前記ステート情報における決済代金のステータスが入金完了となる事に応じ、対応する受発注案件の消込処理を行う処理と、を実行する演算部と、
を備えることを特徴とする決済業務支援システム。
【請求項２】
前記所定ノードは、
ユーザによる入金確認指示を受けて、または前記ステート情報における決済代金の支払手続のステータスに応じて、所定の金融機関のシステムから所定口座に関する入金事象の情報を取得する処理と、当該情報が前記受発注案件の決済代金の入金を示すものであれば、前記決済代金の入金に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納する処理と、前記決済代金のステータスを前記ステート情報において入金完了に更新する処理を実行するものである、
ことを特徴とする請求項１に記載の決済業務支援システム。
【請求項３】
前記所定ノードは、
前記ステート情報を参照して、予め定めた条件の所定組織または前記所定ノードの運用組織の受発注案件に伴う決済業務の各処理のステータスを特定し、前記各処理のステータスを出力部に表示するものである、
ことを特徴とする請求項２に記載の決済業務支援システム。
【請求項４】
前記所定ノードは、
前記出力部にステータスを表示した前記各処理のうち、請求登録の処理であってステータスが完了を示しているものについて、支払登録を行う旨のユーザ指示を受けた場合、前記請求登録が示す決済代金の額での支払手続に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納し、前記支払手続のステータスを前記ステート情報において支払登録完了に更新するものである、
ことを特徴とする請求項３に記載の決済業務支援システム。
【請求項５】
前記所定ノードは、
前記出力部にステータスを表示した前記各処理のうち、請求登録の処理であってステータスが完了を示しているものについて、支払を所定回数に分割する旨のユーザ指示を受けた場合、前記請求登録が示す決済代金の額を前記所定回数で分割した額での、前記所定回数に応じた数の支払手続に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納し、前記支払手続のステータスを前記ステート情報において支払登録完了に更新するものである、
ことを特徴とする請求項４に記載の決済業務支援システム。
【請求項６】
前記所定ノードは、
前記出力部にステータスを表示した各受発注案件に関する前記各処理のうち、請求登録の処理であってステータスが完了を示しているものについて、所定の受発注案件群の支払をまとめて支払う旨のユーザ指示を受けた場合、当該受発注案件群を構成する各受発注案件の前記決済代金の合計額での支払手続に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納し、前記支払手続のステータス
を前記ステート情報において支払登録完了に更新するものである、
ことを特徴とする請求項４に記載の決済業務支援システム。
【請求項７】
前記分散台帳システムのノードのうち予め定めた特定ノードが、
前記消込処理と、前記入金事象の情報を取得する処理と、前記決済代金の入金に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納する処理と、前記決済代金のステータスを前記ステート情報において入金完了に更新する処理と、を実行するものである、
ことを特徴とする請求項２に記載の決済業務支援システム。
【請求項８】
複数の組織それぞれのノードで構成された分散台帳システムにおいて、前記ノードのうち少なくとも所定ノードが、
分散台帳を格納する記憶部を備えて、
所定組織間での受発注に伴う決済業務のトランザクションを受信し、前記分散台帳システムにおける所定の合意形成を経た上で、前記分散台帳に格納する処理と、
前記決済業務における各処理のステータスを前記分散台帳のステート情報として管理する処理と、
前記ステート情報における決済代金のステータスが入金完了となる事に応じ、対応する受発注案件の消込処理を行う処理と、
を実行することを特徴とする決済業務支援方法。
【請求項９】
前記所定ノードが、
ユーザによる入金確認指示を受けて、または前記ステート情報における決済代金の支払手続のステータスに応じて、所定の金融機関のシステムから所定口座に関する入金事象の情報を取得する処理と、
当該情報が前記受発注案件の決済代金の入金を示すものであれば、前記決済代金の入金に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納する処理と、
前記決済代金のステータスを前記ステート情報において入金完了に更新する処理と、
を実行することを特徴とする請求項８に記載の決済業務支援方法。
【請求項１０】
前記所定ノードが、
前記ステート情報を参照して、予め定めた条件の所定組織または前記所定ノードの運用組織の受発注案件に伴う決済業務の各処理のステータスを特定し、前記各処理のステータスを出力部に表示する、
ことを特徴とする請求項９に記載の決済業務支援方法。
【請求項１１】
前記所定ノードが、
前記出力部にステータスを表示した前記各処理のうち、請求登録の処理であってステータスが完了を示しているものについて、支払登録を行う旨のユーザ指示を受けた場合、前記請求登録が示す決済代金の額での支払手続に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納し、前記支払手続のステータスを前記ステート情報において支払登録完了に更新する、
ことを特徴とする請求項１０に記載の決済業務支援方法。
【請求項１２】
前記所定ノードが、
前記出力部にステータスを表示した前記各処理のうち、請求登録の処理であってステータスが完了を示しているものについて、支払を所定回数に分割する旨のユーザ指示を受けた場合、前記請求登録が示す決済代金の額を前記所定回数で分割した額での、前記所定回数に応じた数の支払手続に関するトランザクションを発行し、前記合意形成を経た上で当
該トランザクションを前記分散台帳に格納し、前記支払手続のステータスを前記ステート情報において支払登録完了に更新する、
ことを特徴とする請求項１１に記載の決済業務支援方法。
【請求項１３】
前記所定ノードが、
前記出力部にステータスを表示した各受発注案件に関する前記各処理のうち、請求登録の処理であってステータスが完了を示しているものについて、所定の受発注案件群の支払をまとめて支払う旨のユーザ指示を受けた場合、当該受発注案件群を構成する各受発注案件の前記決済代金の合計額での支払手続に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納し、前記支払手続のステータスを前記ステート情報において支払登録完了に更新する、
ことを特徴とする請求項１１に記載の決済業務支援方法。
【請求項１４】
前記分散台帳システムのノードのうち予め定めた特定ノードが、
前記消込処理と、前記入金事象の情報を取得する処理と、前記決済代金の入金に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納する処理と、前記決済代金のステータスを前記ステート情報において入金完了に更新する処理と、
を実行することを特徴とする請求項９に記載の決済業務支援方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、決済業務支援システムおよび決済業務支援方法に関する。
【背景技術】
【０００２】
サプライチェーンを構成するバイヤとサプライヤの間など、各企業の取引先や提携先の各間での、受発注業務を中心とした業務連携支援を行うサービス基盤が存在する。
【０００３】
こうしたサービス基盤では、インターネット上での企業取引の場として、業種や業務、役割などに応じた種々のアプリケーションサービス（ＳａａＳ）が提供され、例えば上述の受発注業務も、そのステータスを管理しつつ、効率的かつシームレスに遂行可能となっている。
【０００４】
一方、そうした受発注業務に伴う決済業務に関しては、上述のサービス基盤のスコープ外であった。したがって決済業務に関しては、従来どおり当事者間で直接連絡をとりあって処理を進める傾向にある。
【０００５】
そこで、決済業務の効率化等に関する従来技術として、例えば、売掛金に関する売掛金情報を記憶する売掛金情報データベースを有し、各企業に設置される企業センタと、口座情報を管理する金融機関センタと、利用者からの要求に応じて売掛金の支払を前記金融機関センタに依頼する支払受付装置と、を備える入金確認システムであって、前記企業センタは、利用者からの支払要求を受け付けた前記支払受付装置からの所定の要求に応答して、当該要求により指定された売掛金情報に対して照合情報を付与し、該照合情報を前記支払受付装置に送信し、前記支払受付装置は、利用者からの支払要求の入力に応じて前記企業センタから取得した前記照合情報を、資金移動を依頼するための資金移動依頼電文に含めて前記金融機関センタに送信し、前記金融機関センタは、前記支払受付装置から受信した資金移動依頼電文に応じて所定口座への入金処理を行い、前記資金移動依頼電文に含まれる前記照合情報を含む入金情報を生成し、前記企業センタは、前記金融機関センタから前記入金情報を取得し、当該入金情報に含まれる前記照合情報をキーとして前記売掛金情報データベースを参照し、該当する売掛金情報について所定の消込処理を行う、ことを特徴とする入金確認システム（特許文献１参照）などが提案されている。
【０００６】
また、各請求明細毎に与えられた請求明細データに、各請求明細の支払期限毎に同一の振込識別番号を付与する識別番号付与手段と、振込識別番号が同一の請求明細の請求金額を合算し、該合算された請求金額に前記振込識別番号を関連づけた振込データを生成する振込データ生成手段と、前記振込識別番号が付与された前記請求明細データ又は前記振込データと、実際に支払期限毎に入金がなされた入金情報を照合し、消込処理を行う消込処理手段とを具備してなることを特徴とする決済管理システム（特許文献２参照）なども提案されている。
【０００７】
また、売り手と買い手の間の取引を支援する取引支援サーバであって、前記売り手が処理する際の表現形式で表現された商品識別情報、商品数量、および商品単価を含む前記売り手の受渡データと、前記買い手が処理する際の表現形式で表現された商品識別情報、商品数量、および商品単価を含む前記買い手の受渡データとを対応付けるための情報を格納する取引データ格納部と、前記取引に起因して発生した前記売り手の受渡データを前記売り手の端末から受信する売り手データ受信部と、前記取引に起因して発生した前記買い手の受渡データを前記買い手の端末から受信する買い手データ受信部と、前記取引データ格納部を用いて、前記売り手データ受信部が受信した前記売り手の受渡データと、前記買い
手データ受信部が受信した前記買い手の受渡データとを対応付けるマッチング部と、前記マッチング部が対応付けた前記売り手の受渡データおよび前記買い手の受渡データの少なくとも一方を、前記売り手および前記買い手の少なくとも一方の端末に出力する出力部とを備えることを特徴とする取引支援サーバ（特許文献３参照）なども提案されている。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００１−２５００７４号公報
【特許文献２】特開２００２−２１６０３９号公報
【特許文献３】特開２００３−２３３７６５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
ところで、上述の如きサービス基盤を離れて行う決済業務において、各企業の担当者らは、膨大な数の受発注案件ごとに、その支払・入金の確認と消込（リコンサイル）の作業を行っている。その手間は、企業規模が大きいほど、また受発注案件の数が多いほど大きくなり、非常に煩雑な事務作業となる。
【００１０】
また、そうした支払・入金および消込の各作業は、該当作業の契機となる他作業等のステータスを確認した上で行うべきものであるが、この確認を効率的かつ確実に行える状況にない。担当者らは、取引相手の担当者と逐次連絡を取り合って確認を行うケースが多く、その作業効率や即時性、確認結果の正確性のいずれも好適とは言い難い。
また、ステータスに関する情報の管理体制が不十分であれば、改ざん等の不適切な事態が発生して、公正な取引環境が損なわれる可能性もある。
【００１１】
そこで本発明の目的は、決済業務に関係する所定事象のステータスを、当事者間で漏れなく効率的に又適宜な即時性をもって管理し、決済業務の効率化を図る技術を提供することにある。
【課題を解決するための手段】
【００１２】
上記課題を解決する本発明の決済業務支援システムは、複数の組織それぞれのノードで構成された分散台帳システムにおいて、前記ノードのうち少なくとも所定ノードが、分散台帳を格納する記憶部と、所定組織間での受発注に伴う決済業務のトランザクションを受信し、前記分散台帳システムにおける所定の合意形成を経た上で、前記分散台帳に格納する処理と、前記決済業務における各処理のステータスを前記分散台帳のステート情報として管理する処理と、前記ステート情報における決済代金のステータスが入金完了となる事に応じ、対応する受発注案件の消込処理を行う処理と、を実行する演算部と、を備えることを特徴とする。
【００１３】
また、本発明の決済業務支援方法は、複数の組織それぞれのノードで構成された分散台帳システムにおいて、前記ノードのうち少なくとも所定ノードが、分散台帳を格納する記憶部を備えて、所定組織間での受発注に伴う決済業務のトランザクションを受信し、前記分散台帳システムにおける所定の合意形成を経た上で、前記分散台帳に格納する処理と、前記決済業務における各処理のステータスを前記分散台帳のステート情報として管理する処理と、前記ステート情報における決済代金のステータスが入金完了となる事に応じ、対応する受発注案件の消込処理を行う処理と、を実行することを特徴とする。
【発明の効果】
【００１４】
本発明によれば、決済業務に関係する所定事象のステータスを、当事者間で漏れなく効率的に又適宜な即時性をもって管理し、決済業務の効率化を図ることができる。
【図面の簡単な説明】
【００１５】
【図１】本実施形態の決済業務支援システムを含むネットワーク構成図である。
【図２】本実施形態における決済業務支援システムのハードウェア構成例を示す図である。
【図３】本実施形態における決済業務支援方法のフロー例１を示す図である。
【図４】本実施形態における画面例１を示す図である。
【図５】本実施形態における画面例２を示す図である。
【図６】本実施形態における画面例３を示す図である。
【図７】本実施形態における画面例４を示す図である。
【図８】本実施形態における画面例５を示す図である。
【図９】本実施形態における画面例６を示す図である。
【図１０】本実施形態における決済業務支援方法のフロー例２を示す図である。
【図１１】本実施形態における画面例７を示す図である。
【図１２】本実施形態における決済業務支援方法のフロー例３を示す図である。
【発明を実施するための形態】
【００１６】
−−−分散台帳技術について−−−
【００１７】
従来行われてきた中央集権機関（例：金融機関や政府など）を経由した取引に代わる、利用者間のＰ２Ｐ（Ｐｅｅｒ  ｔｏ  Ｐｅｅｒ）による直接的な取引として、分散台帳技術が登場している。
【００１８】
そうした技術としては、例えば、仮想通貨を用いることで、銀行などの中央集権機関を必要とせずに決済取引を行う技術が存在する。この技術では、Ｐ２Ｐネットワーク上における取引データ（以下、トランザクション）に対し、マイナーと呼ばれるノードによる正当性判定を行った後、プルーフオブワークと呼ばれる特定のハッシュ値を算出する作業で確定処理を行っている。
【００１９】
ここで確定されたトランザクションは１つのブロックにまとめられ、ブロックチェーンと呼ばれる分散台帳に記載される。なお、こうした分散台帳を保持する各ノードによって構成されるシステムを分散台帳システムと称する。
【００２０】
なお、本実施形態の決済業務支援システム１０で取り扱うトランザクションは、サプライチェーンの参加者（バイヤ企業やサプライヤ企業）の各間で発生する受発注案件の決済業務に伴うものを想定する。よって、決済業務における種々の手続が各ノードで遂行されるごとにトランザクションが発行され、ノード間での適宜な合意形成を経て分散台帳に格納される。
【００２１】
ブロックチェーンの主な特徴としては、（１）分散台帳システム上の参加者間の取引において、中央集権機関ではなく（任意ないしは特定の）参加者による合意形成や承認によって取引を確定させること、（２）複数のトランザクションをブロックとしてまとめ、数珠つなぎに分散台帳に記録し、連続するブロックにハッシュ計算を施すことにより、改ざんを実質不可能にすること、（３）参加者全員が分散台帳において同一の台帳データを共有することにより、参加者全員での取引の確認を可能とすること、が挙げられる。
【００２２】
このようなブロックチェーンをはじめとした分散台帳技術は、以上のような特徴から、信頼できるデータの管理／共有や、契約に基づく取引の執行／管理を行う仕組みとして、金融分野やＩｏＴ（Ｉｎｔｅｒｎｅｔ  ｏｆ  Ｔｈｉｎｇ）等、幅広い分野での応用が検討されている。
【００２３】
その一つの例に、スマートコントラクト（Ｓｍａｒｔ  Ｃｏｎｔｒａｃｔ）の存在が挙げられる。スマートコントラクトは、デジタル化（ソフトウェアプログラム化）された契約とも言われ、台帳データの入力、出力などの処理をプログラム的に記述することで実現される。分散台帳システムにおける各ノードは、互いの合意形成を図りつつ、こうしたスマートコントラクトを実行し、その実行結果等でそれぞれの台帳データを更新する。
【００２４】
ここで、本実施形態の説明にあたり、以下のように用語を定義する。まず、分散台帳は、分散台帳システムを構成する複数のノード（分散台帳ノード）の間で取り扱う台帳データをセキュアに共有することを特徴とする分散データベースである。こうした分散台帳はブロックチェーンとも呼ばれる。
【００２５】
またここでは、上述の分散台帳システムの形態のうち、パーミッション型（コンソーシアム型とも呼ばれる）を想定している。本実施形態における分散台帳システムの参加者としては、サプライチェーンを構成するバイヤ企業、サプライヤ企業といった企業で、上述のサービス基盤（受発注業務を中心とした業務連携支援を行う既存のサービス基盤）での利用登録を経たユーザ、である故である。勿論、こうした想定はあくまでも一例であって、他の分散台帳システムの形態を適宜に採用してよい。また、分散台帳システムにおいては、上述したデータの共有のために、ハッシュチェーンやコンセンサスプロトコルなどの要素技術が用いられている。
【００２６】
また、上述の分散台帳で保持される台帳データは、そのデータ構造として、ＲＤＢ（Ｒｅｌａｔｉｏｎａｌ  ＤａｔａＢａｓｅ）やＫＶＳ（Ｋｅｙ−Ｖａｌｕｅ  Ｓｔｏｒｅ）などの各種データ構造を適宜に採用しうる。こうしたデータ構造は、分散台帳システムの利用者により規定することが可能である。
【００２７】
なお、ブロックチェーンを用いた分散台帳管理では、通常、（最新の）ステート（例えば決済業務の場合では、請求登録の内容や未済、支払手続や入金の内容や未済など）を取得するためには、ブロックチェーンを辿らなければならない。ところが、これでは処理効率が悪いため、ブロックチェーンとは別に、最新のステート情報をキャッシュしておく方法（例えば、"Ｈｙｐｅｒｌｅｄｇｅｒ  Ｆａｂｒｉｃ"，  ［ｏｎｌｉｎｅ］、［平成２９年３月３１日検索］、インターネット＜ＵＲＬ：ｈｔｔｐ：／／ｈｙｐｅｒｌｅｄｇｅｒ−ｆａｂｒｉｃ．ｒｅａｄｔｈｅｄｏｃｓ．ｉｏ／ｅｎ／ｌａｔｅｓｔ／＞）が存在する。
【００２８】
よって本実施例でも最新のステート情報を分散台帳上で管理することを想定する。ステート情報は、例えば、受発注案件における請求書のＩＤをキーに、当該案件における各段階の決済処理のステータスを紐付けるといった、上述のＫＶＳのデータ構造で管理される。
【００２９】
これにより、分散台帳システムのノードらは、例えば、受発注案件の請求書ＩＤをキーにして、該当案件の決済処理のステータスを取得することができる。ノードらは、本実施形態の決済業務支援方法に沿った処理に伴い、トランザクションを発行・格納する度にこのステート情報を更新する。
【００３０】
また、上述のスマートコントラクトは、台帳データの入力、出力などの処理を記述したプログラムであるとする。スマートコントラクトは、分散台帳システムに所属するノード（分散台帳ノード）にインストールされ、適宜のタイミングで実行される。
【００３１】
スマートコントラクトを実行するノードは、必ずしも分散台帳システムに所属する全ノ
ードとは限らないが、スマートコントラクトの実行結果にしたがって、分散台帳システムに所属する全ノードが各自の台帳データを更新する。
【００３２】
また、トランザクションは、上述のノード各々が、コンセンサスプロトコルなどに基づいて連動しながらスマートコントラクトを実行することで行う処理それぞれのことである。トランザクションの例には、台帳データの参照や、台帳データの更新などを含む。
【００３３】
トランザクションには引数（リクエストのパラメータ）を含む。トランザクション引数の例には、参照対象のデータのキー（すなわち請求書ＩＤなど）や、更新対象のデータのキーおよび更新後の値（ｖａｌｕｅ）を含む。
【００３４】
なお、上述の分散台帳技術に関する説明は、以降の説明で重ねて説明しない。よって、特に必要が無い限り、分散台帳技術に関する具体的な説明や図示は適宜省略するものとする。
−−−ネットワーク構成−−−
以下に本発明の実施形態について図面を用いて詳細に説明する。図１は、本実施形態の決済業務支援システム１０を含むネットワーク構成図である。
【００３５】
図１に示す決済業務支援システム１０は、決済業務に関係する所定事象のステータスを、当事者間で漏れなく効率的に又適宜な即時性をもって管理し、決済業務の効率化を図るコンピュータシステムである。
図１に示す分散台帳システム５の利用者、すなわち受発注案件を抱える企業は、例えば、サプライチェーンを構成するバイヤとサプライヤである。
【００３６】
こうした企業は、それぞれノードを運用している。このうち、バイヤ企業のノードをバイヤ端末２０、サプライヤ企業のノードをサプライヤ端末３０とする。また、これらバイヤ端末２０やサプライヤ端末３０らは、インターネットなど適宜なネットワーク１を介して、相互に通信可能である。
【００３７】
また、バイヤ端末２０やサプライヤ端末３０は、既に述べた受発注業務を行うプラットフォームたる受発注システム２（サービス基盤）に対し、所定の認証処理を経てアクセス可能な端末である。つまり、受発注システム２において、バイヤ企業はバイヤ端末２０を操作してサプライヤ企業に対して資材等を発注し、サプライヤ企業はサプライヤ端末３０を介して受注を行う。その後、サプライヤ企業は、受注した該当資材等をバイヤ企業に納品して検収を受けることとなる。
【００３８】
本実施形態の決済業務支援システム１０は、こうした受発注システム２で処理される受発注案件のうち、バイヤ企業による検収が完了したものについて、例えば、受発注システム２から通知を受け、これを契機として必要な処理を開始する。
【００３９】
こうした決済業務支援システム１０は、上述のように決済業務支援方法を主導する管理システムとしての側面を備える他、分散台帳システム５におけるノード（分散台帳ノード）の１つでもある。この場合の決済業務支援システム１０は、バイヤ端末２０やサプライヤ端末３０と適宜に協働し、自身での処理を契機としたトランザクションの発行、合意形成、分散台帳への格納といった一連の処理を遂行可能である。
【００４０】
また、決済業務支援システム１０は、ユーザによる入金確認指示を受けて、またはステート情報における決済代金の支払手続のステータスに応じて、銀行システム４０やデジタル通貨システム５０などの適宜な金融機関システムに対し、バイヤ企業からサプライヤ企業に宛てた所定額の入金（所定の請求書に関するもの）がなされたか問い合わせを行い、
当該入金が確認された場合、該当請求書の決済業務に関する入金完了のトランザクションを発行し、合意形成を経て分散台帳に格納し、また、ステート情報におけるステータスを「入金完了」に更新する。
【００４１】
或いは、決済業務支援システム１０は、例えば、或る請求書に関して、バイヤ端末２０からサプライヤ企業に宛てた所定額の支払手続（入金処理）の要求を受けて、上述の銀行システム４０やデジタル通貨システム５０などの適宜な金融機関システムに対し、上述の請求書が示す内容での入金処理を指示する。決済業務支援システム１０は、この指示に応じた入金処理の結果を該当金融機関システムから取得し、入金処理の完了が確認された場合、該当請求書の決済業務に関する入金完了のトランザクションを発行し、合意形成を経て分散台帳に格納し、また、ステート情報におけるステータスを「入金完了」に更新する。
【００４２】
上述のようにステート情報におけるステータスを「入金完了」と更新する動作は、該当受発注案件の消込処理に該当する。つまり、該当受発注案件の請求登録から支払手続の登録、および入金処理を経て、必要な決済業務が完了したことを意味する。
−−−ハードウェア構成−−−
【００４３】
また、決済業務支援システム１０のハードウェア構成は以下の如くとなる。図２は、本実施形態における決済業務支援システム１０のハードウェア構成例を示す図である。
【００４４】
この場合の決済業務支援システム１０は、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）やハードディスクドライブなど適宜な不揮発性記憶素子で構成される記憶部１１、ＲＡＭなど揮発性記憶素子で構成されるメモリ１３、記憶部１１に保持されるプログラム１２をメモリ１３に読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵなどの演算部１４、および、ネットワーク１と接続し他の装置との通信処理を担う通信部１５、を備える。
【００４５】
なお、決済業務支援システム１０は、ユーザからのキー入力や音声入力を受け付ける入力部や、処理データの表示を行うディスプレイ等の出力部を必要に応じて備えるとしてもよい。
【００４６】
なお、記憶部１１内には、本実施形態の決済業務支援システム１０として必要な機能を実装する為のプログラム１２に加えて、分散台帳１００、ブロックチェーン１１１、ステート情報１１２、および、スマートコントラクト１１３が少なくとも記憶されている。
こうした決済業務支援システム１０のハードウェア構成は、バイヤ端末２０やサプライヤ端末３０についても同様である。
−−−決済業務支援方法の実行例−−−
【００４７】
以下、本実施形態における決済業務支援方法の実際手順について図に基づき説明する。以下で説明する決済業務支援方法に対応する各種動作は、決済業務支援システム１０やバイヤ端末２０、サプライヤ端末３０などの各ノードが、メモリ等に読み出して実行するプログラムによって実現される。そして、このプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。
【００４８】
図３は、本実施形態における決済業務支援方法のフロー例１を示す図である。ここでは、フロー開始契機の一例として、決済業務支援システム１０が、或る受発注案件に関して、受発注システム２ないしバイヤ端末２０から「検収完了」の通知を受けたことを想定する。
【００４９】
勿論、この通知には受発注案件の識別情報（例：注文書番号）、案件名／品名、受注金額、入金予定額、入金予定日、バイヤ企業、サプライヤ企業、および支払単位の内容、といった、受発注契約が含みうる各種情報が含まれている。
【００５０】
そこで決済業務支援システム１０は、上述の「検収完了」の通知を受けた受発注案件に関して、当該通知に関してトランザクションを発行し、合意形成を経て分散台帳１１０に格納する（ｓ１０）。またｓ１０における決済業務支援システム１０は、このトランザクションに関する情報を、ステート情報１１２に格納する。
【００５１】
なお、ステート情報１１２に格納されている各情報は、バイヤ企業やサプライヤ企業といったステークホルダーのバリューごとに切り分けてアクセス制御され、当該ステークホルダーのノード、すなわちバイヤ端末２０やサプライヤ端末３０に配信される。つまり、バイヤ企業やサプライヤ企業は、自身が関与している受発注案件に関するステート情報１１２のみ閲覧可能である。
【００５２】
そうした閲覧の様子は、図４における取引案件の一覧画面４００に示すとおりである。この一覧画面４００は、「受注」と「発注」の２つのシートがタブで選択可能なインターフェイス構成となっている。つまり、ステークホルダーたる各企業は、受発注の立場によってバイヤ企業とサプライヤ企業のいずれにもなりうることに対応した構成である。
また、各シートは、日時、注文書番号、案件／品名、入金予定日、ステータス、および、最終手続者、といった項目を含むレコードから構成される。
【００５３】
上述の例の場合、「受注」シートにおける、日時「２０１８／８／２３」、注文書番号「００００００１」、案件／品名「Ａプロジェクト：ブレーキキャリパ」、入金予定日「２０１８／８／３１」、ステータス「検収完了」、および、最終手続者「ＸＸ社（Ｂｕｙ＿Ｂ）」のレコードが、「検収完了」の通知に応じてステート情報１１２に格納されたものに該当する。
【００５４】
そこでこの一覧画面４００を閲覧中の担当者（立場としてはサプライヤ企業の担当者）は、サプライヤ端末３０を操作して、例えば、該当レコードをクリックし、検収内容（図５：検収内容の確認画面５００）の確認を経て、請求情報の登録ボタン５０１をクリックする。なお、サプライヤ企業側で複数の検収完了案件をまとめて１件の請求情報として登録する形態も採用しうる。
【００５５】
一方、決済業務支援システム１０は、上述の登録ボタン５０１のクリックを受けて、例えば、請求書番号を所定ルールで生成するなどし、請求書番号「Ａ１」、注文書番号「００００００１」、品名「ブレーキキャリパ」、数量「５００台」、請求金額「￥１５、０００、０００」、請求先企業「ＸＸ社」、請求元企業「ＹＹ社」、振込先「○○銀行、○○支店、普通口座○○○○」、締日（払込期限）「２０１８／０８／３１」、といった各値を含む請求情報を生成し、これを請求情報の確認画面６００（図６参照）などとして上述のサプライヤ端末３０に配信する（ｓ１１）。
続いて上述の担当者は、上述の確認画面６００にて例えば請求書の登録ボタン６０１をクリックしたとする。
【００５６】
一方、決済業務支援システム１０は、上述の登録ボタン６０１のクリックを受け、該当受発注案件に関して、当該請求書の登録・発行に関するトランザクションを発行し、合意形成を経て分散台帳１１０に格納する（ｓ１２）。
【００５７】
またｓ１２における決済業務支援システム１０は、このトランザクションの発行に伴い、当該受発注案件に関するステート情報１１２のレコード（ｋｅｙが「Ａ１００００００
１」のレコード）において、そのステータスを「請求書発行」などと更新する。この処理にて、請求情報の登録・発行、すなわち請求登録が完了したこととなる。
【００５８】
なお、ここでステート情報１１２で更新される該当レコードは、そのｋｅｙとして、例えば、請求書番号「Ａ１」と注文書番号「００００００１」をマージした、「Ａ１００００００１」といった値を想定する。
また、決済業務支援システム１０は、上述の請求情報が含む取引先「ＸＸ社」のバイヤ端末２０に宛てて、請求書発行通知を送信する（ｓ１３）。
【００５９】
具体的には、決済業務支援システム１０は、例えば上述のｓ１２の処理を受けて、例えば、取引先「ＸＸ社」のバイヤ端末２０で表示中の、取引案件の一覧画面７００（図７参照）において、該当レコード（注文書番号「００００００１」のレコード）の表示形態が他のレコードと異なるよう、フォントサイズの拡大、下線付与、太字化、文字色変更、といった強調表示制御を行い、ステータスが「請求書発行」となった旨をバイヤ企業の担当者に認識されやすくする。或いは、より単純に、該当受発注案件（注文書番号「００００００１」の案件）に関して請求書が発行された旨のメッセージを、一覧画面７００の所定箇所に表示させるとしてもよい。
【００６０】
なお、この一覧画面７００は、図４の一覧画面４００と同様、「受注」と「発注」の２つのシートがタブで選択可能なインターフェイス構成となっている。ただし、上述の状況では、バイヤ企業としての立場で一覧画面７００が閲覧されており、「発注」シートが表示された状態となっている。
【００６１】
そこでこの一覧画面７００を閲覧中の担当者（立場としてはバイヤ企業の担当者）は、バイヤ端末２０を操作して、例えば、該当レコードをクリックし、請求書の内容（図８：請求内容の確認画面８００）の確認を経て、支払手続のボタン８０１をクリックする。
この場合、バイヤ端末２０は、そのクリック事象を決済業務支援システム１０に通知する。
【００６２】
通知を受けた決済業務支援システム１０は、当該請求書が示す「振込先」への振込可能な金融機関のシステムに対し、上述の請求書が示す内容での振込処理を指示する（ｓ１４）。この場合の金融機関のシステムとは、銀行システム４０やデジタル通貨システム５０が該当する。なお、上述の振込処理は、振込元（バイヤ企業の口座）と振込先（サプライヤ企業の口座）とで金融機関が異なるケースと同一であるケースのいずれも想定できる。
【００６３】
他方、振込指示を受けた金融機関のシステムは、その指示内容に応じて、バイヤ企業に関して管理している所定額の資金を、サプライヤ企業の指定口座等に移動させる、つまり振込処理を実行する。また、この振込処理の結果を、上述の決済業務支援システム１０（バイヤ端末２０も含めてよい）に通知する。
【００６４】
ただし、金融機関ごとの特性により、こうした振込処理のタイミング（早さ）は異なるため、デジタル通貨システム５０のように、振込処理の指示から即時性を持って振込処理とその結果の通知が行われるケースと、銀行システム４０のように、月次のバッチ処理等でまとめて処理を行うケースとが想定される。
【００６５】
続いて、決済業務支援システム１０は、上述の振込処理に伴い、該当請求書が示す金額での支払情報の登録に関するトランザクションを発行し、合意形成を経て分散台帳に格納する（ｓ１５）。この場合の決済業務支援システム１０は、ステート情報１１２における該当請求書に関するステータスを例えば「支払情報登録済」或いは「支払完了」などと更新する。
【００６６】
なお、上述のｓ１５に関する各処理は、振込処理の形態や、当該振込処理に関与する金融機関で採用している資金移動形態によって、後述するｓ１６と同時に実行されることになる。例えば、振込処理がバッチ処理の形態で月末締めなどで行われる場合、振込処理の指示から実際の資金移動まで十分な時間差が生じる状況が想定され、その場合、ｓ１５は単独で実行される。一方、振込処理の指示からほぼ即時に資金移動が実行される形態の場合、上述のような時間差が殆ど生じないため、ｓ１５とｓ１６は同時実行されることとなる。
【００６７】
決済業務支援システム１０は、上述の金融機関のシステムから振込処理の結果の通知を受け、該当請求書が示す金額での入金処理の完了を確認したならば、該当請求書の決済業務に関する入金完了のトランザクションを発行し、合意形成を経て分散台帳に格納する（ｓ１６）。なお、上述の一連の入金処理に関する処理は、注文書番号や請求書番号などの識別情報をキーに、（適宜に受発注システム２などのＥＤＩ機能と連携しつつ）行われる状況を想定できる。こうした構成は、他の処理に関しても同様に適用しうるものとする。
【００６８】
また、決済業務支援システム１０は、ステート情報１１２における該当請求書に関するステータスを「入金完了」に更新する。このようにステート情報１１２におけるステータスを「入金完了」と更新する動作は、該当受発注案件の決済業務に関する消込処理に該当する。つまり、該当受発注案件の請求登録から支払手続の登録、および入金処理を経て、必要な決済業務が完了したことを意味する。
【００６９】
なお、上述の例では、支払手続のボタン８０１のクリックに伴い、バイヤ端末２０がそのクリック事象を決済業務支援システム１０に通知し、振込処理の指示を決済業務支援システム１０が実行するとした。
【００７０】
しかし、そうした形態とは異なり、サプライヤ端末３０が、上述の「振込先」への振込可能な金融機関のシステムに対し、照会用のＡＰＩ等を介して入金確認処理を実行し、当該サプライヤ企業宛の入金履歴を取得・出力し、サプライヤの担当者等による当該請求書が示す内容での振込処理の確認を行わせるとしてもよい。この場合、サプライヤ端末３０は、上述の担当者等による入金確認の結果（入金が確認できた旨の結果）を決済業務支援システム１０に通知する。一方、これを受けた決済業務支援システム１０は、該当請求書の決済業務に関する入金完了のトランザクションの発行、分散台帳への格納といった処理を行うこととなる。こうした形態は、例えば、該当金融機関が決済業務支援システム１０に対して振込処理に関するＡＰＩを開放しておらず、バイヤ企業による振込処理を、サプライヤ端末３０による照会でしか確認できないといった状況に対して有効である。
【００７１】
なお、上述の処理のうちｓ１３にて請求書発行通知が送信されたバイヤ端末２０において、バイヤ企業の担当者が、一覧画面７００（図７）にて該当レコードをクリックし、請求書の内容（図８：請求内容の確認画面８００）の確認を経て、所望の支払方法を指定した上で支払手続のボタン８０１をクリックする形態も想定できる。
【００７２】
例えば、一覧画面７００におけるインターフェイスたるチェックボックス９０１（図９参照）で、上述の担当者が、所望の支払方法として所定回数での分割払いを指定した上で、ボタン８０１をクリックしたとする。すると、これを受けたバイヤ端末２０は、インターフェイス９０１での指定内容の値を決済業務支援システム１０に通知する。なお、上述の分割払いの回数については、バイヤ企業とサプライヤ企業との間での所定の契約や受発注に際して予め規定しておいたものであり、担当者の指定動作は、上述のチェックボックス９０１でそれを希望したことにあたる。ただし、この形態に限定せず、バイヤ企業が都度、分割払いの回数を指定する形態も想定できる。
【００７３】
この場合、図１０のフローで示すように、決済業務支援システム１０は、対象のレコード（請求登録）が示す決済代金の額を指定回数で分割した額での、指定回数に応じた数の支払手続に関するトランザクションを発行し、合意形成を経た上で当該トランザクションを分散台帳１１０に格納する（ｓ２０）。
【００７４】
また、決済業務支援システム１０は、ｓ２０に伴い、ステート情報１１２における該当請求書に関するステータスを「支払登録完了」に更新し（ｓ２１）、本フローを終了する。以降の処理は、一覧画面７００の「発注」シートにおける該当レコード（指定回数分に分割した数のレコード）の表示と、これに対する支払手続のボタン８０１のクリックを受けた振込処理など、同様に実行する。
【００７５】
また、上述の処理のうちｓ１３にて請求書発行通知が送信されたバイヤ端末２０において、バイヤ企業の担当者が指定する所望の支払方法として、分割払いではなくまとめ払いであるケースも想定できる。
【００７６】
例えば、一覧画面７００におけるインターフェイス１１０１（図１１における星形のオブジェクト参照）で、上述の担当者が、所望の支払方法として複数の請求書をまとめた一括払いを指定した上で、ボタン８０１をクリックしたとする。すると、これを受けたバイヤ端末２０は、インターフェイス９０１での指定内容の値を決済業務支援システム１０に通知する。
【００７７】
この場合、図１２のフローで示すように、決済業務支援システム１０は、対象の各レコード（請求登録）が示す決済代金の額を合算した額での支払手続に関するトランザクションを発行し、合意形成を経た上で当該トランザクションを分散台帳１１０に格納する（ｓ３０）。
【００７８】
また、決済業務支援システム１０は、ｓ３０に伴い、ステート情報１１２における該当請求書それぞれに関するステータスを「支払登録完了」に更新し（ｓ３１）、本フローを終了する。以降の処理は、一覧画面７００の「発注」シートにおける該当レコード（複数の請求書の内容をまとめて１つにしたレコード）の表示と、これに対する支払手続のボタン８０１のクリックを受けた振込処理など、同様に実行する。
【００７９】
以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。
【００８０】
こうした本実施形態によれば、既存のサービス基盤上での受発注業務に伴い、その検収ステータスを契機にした決済業務を適宜に支援する。例えば、請求の登録から当該請求に対する支払のオペレーションに際し、請求から消込までの各ステータスが当事者間でリアルタイム共有可能となる。こうした対応は、分散台帳技術（ブロックチェーン）を基盤としたサービス提供形態で実現されるため、上述の請求や支払等に関する各種データの真正性や網羅性が保証され、最終的な消込処理の信頼性も好適なものとなる。
【００８１】
また、税制など法制度（例：適格請求書等保存方式など）の改訂等に対応した請求書の作成・保存管理などについてシステム側で適宜に対応し、利用者側の負担を回避しつつ、当該サービスの導入・適用が容易となる。
【００８２】
したがって、決済業務に関係する所定事象のステータスを、当事者間で漏れなく効率的に又適宜な即時性をもって管理し、決済業務の効率化を図ることが可能となる。
【００８３】
本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態の決済業務支援システムにおいて、前記所定ノードは、ユーザによる入金確認指示を受けて、または前記ステート情報における決済代金の支払手続のステータスに応じて、所定の金融機関のシステムから所定口座に関する入金事象の情報を取得する処理と、当該情報が前記受発注案件の決済代金の入金を示すものであれば、前記決済代金の入金に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納する処理と、前記決済代金のステータスを前記ステート情報において入金完了に更新する処理を実行するものである、としてもよい。
【００８４】
これによれば、決済業務支援システム側で決済代金の入金状況をチェックし、この結果に応じて消込処理の契機を的確に判断し、該当処理を遂行可能となる。ひいては、決済業務に関係する所定事象のステータスを、当事者間で漏れなく効率的に又適宜な即時性をもって管理し、決済業務のさらなる効率化を図ることが可能となる。
【００８５】
また、本実施形態の決済業務支援システムにおいて、前記所定ノードは、前記ステート情報を参照して、予め定めた条件の所定組織または前記所定ノードの運用組織の受発注案件に伴う決済業務の各処理のステータスを特定し、前記各処理のステータスを出力部に表示するものである、としてもよい。
【００８６】
これによれば、バイヤやサプライヤなどの各組織で、自身が関わる受発注案件の決済業務に関するステータスを確実かつ簡便にチェック可能となり、決済業務の遂行に必要な各手続も的確に行えることにつながる。ひいては、決済業務に関係する所定事象のステータスを、当事者間で漏れなく効率的に又適宜な即時性をもって管理し、決済業務のさらなる効率化を図ることが可能となる。
【００８７】
また、本実施形態の決済業務支援システムにおいて、前記所定ノードは、前記出力部にステータスを表示した前記各処理のうち、請求登録の処理であってステータスが完了を示しているものについて、支払登録を行う旨のユーザ指示を受けた場合、前記請求登録が示す決済代金の額での支払手続に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納し、前記支払手続のステータスを前記ステート情報において支払登録完了に更新するものである、としてもよい。
【００８８】
これによれば、請求登録完了を認識したユーザによる支払手続の登録が漏れなく実行され、そのステータスも管理されることとなる。ひいては、決済業務に関係する所定事象のステータスを、当事者間で漏れなく効率的に又適宜な即時性をもって管理し、決済業務のさらなる効率化を図ることが可能となる。
【００８９】
また、本実施形態の決済業務支援システムにおいて、前記所定ノードは、前記出力部にステータスを表示した前記各処理のうち、請求登録の処理であってステータスが完了を示しているものについて、支払を所定回数に分割する旨のユーザ指示を受けた場合、前記請求登録が示す決済代金の額を前記所定回数で分割した額での、前記所定回数に応じた数の支払手続に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納し、前記支払手続のステータスを前記ステート情報において支払登録完了に更新するものである、としてもよい。
【００９０】
これによれば、請求登録が示す決済代金について分割での支払対象とすることが可能で、各組織のニーズに応じた決済業務の遂行が可能となる。ひいては、決済業務に関係する所定事象のステータスを、当事者間で漏れなく効率的に又適宜な即時性をもって管理し、決済業務のさらなる効率化を図ることが可能となる。
【００９１】
また、本実施形態の決済業務支援システムにおいて、前記所定ノードは、前記出力部にステータスを表示した各受発注案件に関する前記各処理のうち、請求登録の処理であってステータスが完了を示しているものについて、所定の受発注案件群の支払をまとめて支払う旨のユーザ指示を受けた場合、当該受発注案件群を構成する各受発注案件の前記決済代金の合計額での支払手続に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納し、前記支払手続のステータスを前記ステート情報において支払登録完了に更新するものである、としてもよい。
【００９２】
これによれば、複数の受発注案件に関する請求登録をまとめて支払対象とすることが可能で、各組織のニーズに応じた決済業務の遂行が可能となる。ひいては、決済業務に関係する所定事象のステータスを、当事者間で漏れなく効率的に又適宜な即時性をもって管理し、決済業務のさらなる効率化を図ることが可能となる。
【００９３】
また、本実施形態の決済業務支援システムにおいて、前記分散台帳システムのノードのうち予め定めた特定ノードが、前記消込処理と、前記入金事象の情報を取得する処理と、前記決済代金の入金に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納する処理と、前記決済代金のステータスを前記ステート情報において入金完了に更新する処理と、を実行するものである、としてもよい。
【００９４】
これによれば、分散台帳システムにおける、各参加企業のノード（分散台帳ノード）と、分散台帳システムの運用企業等の特定ノード（決済システム）とで適宜に役割分担し、消込処理など特定処理については特定ノードで行うといった構成で、決済業務支援方法を遂行可能となる。ひいては、決済業務に関係する所定事象のステータスを、当事者間で漏れなく効率的に又適宜な即時性をもって管理し、決済業務のさらなる効率化を図ることが可能となる。
【００９５】
また、本実施形態の決済業務支援方法において、前記所定ノードが、ユーザによる入金確認指示を受けて、または前記ステート情報における決済代金の支払手続のステータスに応じて、所定の金融機関のシステムから所定口座に関する入金事象の情報を取得する処理と、当該情報が前記受発注案件の決済代金の入金を示すものであれば、前記決済代金の入金に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納する処理と、前記決済代金のステータスを前記ステート情報において入金完了に更新する処理と、を実行するとしてもよい。
【００９６】
また、本実施形態の決済業務支援方法において、前記所定ノードが、前記ステート情報を参照して、予め定めた条件の所定組織または前記所定ノードの運用組織の受発注案件に伴う決済業務の各処理のステータスを特定し、前記各処理のステータスを出力部に表示する、としてもよい。
【００９７】
また、本実施形態の決済業務支援方法において、前記所定ノードが、前記出力部にステータスを表示した前記各処理のうち、請求登録の処理であってステータスが完了を示しているものについて、支払登録を行う旨のユーザ指示を受けた場合、前記請求登録が示す決済代金の額での支払手続に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納し、前記支払手続のステータスを前記ステート情報において支払登録完了に更新する、としてもよい。
【００９８】
また、本実施形態の決済業務支援方法において、前記所定ノードが、前記出力部にステータスを表示した前記各処理のうち、請求登録の処理であってステータスが完了を示しているものについて、支払を所定回数に分割する旨のユーザ指示を受けた場合、前記請求登録が示す決済代金の額を前記所定回数で分割した額での、前記所定回数に応じた数の支払
手続に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納し、前記支払手続のステータスを前記ステート情報において支払登録完了に更新する、としてもよい。
【００９９】
また、本実施形態の決済業務支援方法において、前記所定ノードが、前記出力部にステータスを表示した各受発注案件に関する前記各処理のうち、請求登録の処理であってステータスが完了を示しているものについて、所定の受発注案件群の支払をまとめて支払う旨のユーザ指示を受けた場合、当該受発注案件群を構成する各受発注案件の前記決済代金の合計額での支払手続に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納し、前記支払手続のステータスを前記ステート情報において支払登録完了に更新する、としてもよい。
【０１００】
また、本実施形態の決済業務支援方法において、前記分散台帳システムのノードのうち予め定めた特定ノードが、前記消込処理と、前記入金事象の情報を取得する処理と、前記決済代金の入金に関するトランザクションを発行し、前記合意形成を経た上で当該トランザクションを前記分散台帳に格納する処理と、前記決済代金のステータスを前記ステート情報において入金完了に更新する処理と、を実行するとしてもよい。
【符号の説明】
【０１０１】
１    ネットワーク
２    受発注システム（サービス基盤）
５    分散台帳システム
１０  決済業務支援システム
１１  記憶部
１２  プログラム
１３  メモリ
１４  演算部
１５  通信部
１１０  分散台帳
１１１  ブロックチェーン
１１２  ステート情報
１１３  スマートコントラクト
２０  バイヤ端末
３０  サプライヤ端末
４０  銀行システム
５０  デジタル通貨システム
【図１】
2020091695.tif 000003
【図２】
2020091695.tif 000004
【図３】
2020091695.tif 000005
【図４】
2020091695.tif 000006
【図５】
2020091695.tif 000007
【図６】
2020091695.tif 000008
【図７】
2020091695.tif 000009
【図８】
2020091695.tif 000010
【図９】
2020091695.tif 000011
【図１０】
2020091695.tif 000012
【図１１】
2020091695.tif 000013
【図１２】
2020091695.tif 000014