WO2020116337A1 - 決済業務支援システムおよび決済業務支援方法 - Google Patents

決済業務支援システムおよび決済業務支援方法 Download PDF

Info

Publication number
WO2020116337A1
WO2020116337A1 PCT/JP2019/046740 JP2019046740W WO2020116337A1 WO 2020116337 A1 WO2020116337 A1 WO 2020116337A1 JP 2019046740 W JP2019046740 W JP 2019046740W WO 2020116337 A1 WO2020116337 A1 WO 2020116337A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
status
distributed ledger
transaction
settlement
Prior art date
Application number
PCT/JP2019/046740
Other languages
English (en)
French (fr)
Inventor
敏基 谷口
達郎 坪根
挙 小林
昌幸 親松
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to US17/299,069 priority Critical patent/US20220058599A1/en
Priority to SG11202105870VA priority patent/SG11202105870VA/en
Publication of WO2020116337A1 publication Critical patent/WO2020116337A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/04—Billing or invoicing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
    • G06Q30/0635—Processing of requisition or of purchase orders
    • G06Q30/0637—Approvals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/03—Credit; Loans; Processing thereof
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography

Definitions

  • the present invention relates to a settlement business support system and a settlement business support method.
  • SaaS application services
  • a receivable information database that stores receivable information relating to receivables
  • a corporate center installed in each company
  • a financial institution center that manages account information
  • a payment acceptance system for requesting payment of accounts receivable from the financial institution center in response to a request from a user, wherein the enterprise center receives the payment request from the user.
  • the collation information is added to the accounts receivable information specified by the request, the collation information is transmitted to the payment acceptance device, and the payment acceptance device pays the payment from the user.
  • the collation information acquired from the company center in response to the input of the request is included in a fund transfer request message for requesting transfer of funds, and is transmitted to the financial institution center.
  • Deposit processing to a predetermined account is performed according to the received fund transfer request message, and deposit information including the collation information included in the fund transfer request message is generated, and the corporate center receives the deposit information from the financial institution center.
  • Is obtained and refers to the accounts receivable information database using the collation information included in the deposit information as a key, and performs a predetermined clearing process on the corresponding accounts receivable information (see Patent Document 1). ) Etc. have been proposed.
  • the billing statement data given for each billing statement is added up with the identification number assigning means for assigning the same transfer identification number for each payment deadline of each billing statement and the billing amount for the billing statement having the same transfer identification number.
  • the transfer data generation means for generating transfer data in which the transfer identification number is associated with the summed charge amount, the claim detail data or the transfer data to which the transfer identification number is given, and actually for each payment deadline.
  • a transaction support server that supports transactions between sellers and buyers, wherein the seller's delivery data includes product identification information, a product quantity, and a product unit price expressed in an expression format when the seller processes.
  • a transaction data storage unit that stores information for associating the buyer's delivery data including the product identification information, the product quantity, and the product unit price expressed in the expression format used by the buyer, and the transaction data storage unit.
  • a seller data receiving unit that receives the seller's delivery data generated from the seller's terminal, and a buyer data receiving unit to receive the buyer's delivery data generated due to the transaction from the buyer's terminal;
  • a matching unit that associates the seller's delivery data received by the seller data receiving unit with the buyer's delivery data received by the buyer data receiving unit using the transaction data storage unit, and the matching unit is associated with each other.
  • a transaction support server (see Patent Document 3) including an output unit that outputs at least one of the seller's delivery data and the buyer's delivery data to a terminal of at least one of the seller and the buyer. Is also proposed.
  • an object of the present invention is to provide a technology for efficiently managing the settlement business by managing the status of a predetermined event related to the settlement business efficiently between the parties without any omission and with appropriate immediacy.
  • the settlement operation support system of the present invention for solving the above-mentioned problems is a distributed ledger system including nodes of a plurality of organizations. At least a predetermined node among the nodes has a storage unit for storing the distributed ledger and a predetermined organization
  • the transaction of the settlement business accompanying the order placement and reception in the above, after having undergone a predetermined consensus in the distributed ledger system, the process of storing it in the distributed ledger, and the status of each process in the settlement business of the distributed ledger.
  • the settlement operation support method of the present invention is a distributed ledger system configured by nodes of a plurality of organizations, at least a predetermined node of the nodes includes a storage unit for storing a distributed ledger, and The transaction of the settlement business associated with the ordering and receiving of the transaction, the process of storing it in the distributed ledger after a predetermined consensus formation in the distributed ledger system, and the status of each process in the settlement business are described in the state of the distributed ledger. It is characterized in that it performs a process of managing as information and a process of executing a corresponding order receiving/ordering case clearing process when the status of the settlement price in the state information indicates that the payment is completed.
  • the status of a predetermined event related to the settlement business can be managed efficiently between the parties without any omission and with appropriate immediacy, and the efficiency of the settlement business can be improved.
  • transaction the transaction data (hereinafter, transaction) on the P2P network is subjected to a finalizing process in a work called a proof of work to calculate a specific hash value after a node called a miner judges the validity of the transaction data.
  • a proof of work a work called a proof of work to calculate a specific hash value after a node called a miner judges the validity of the transaction data.
  • the transactions confirmed here are grouped into one block and described in a distributed ledger called blockchain. It should be noted that a system configured by each node holding such a distributed ledger is called a distributed ledger system.
  • the transaction handled by the settlement operation support system 10 of the present embodiment is assumed to be associated with the settlement operation of the order placement/reception case that occurs between each of the supply chain participants (buyer companies and supplier companies). Therefore, a transaction is issued each time various procedures in the settlement business are executed in each node, and the transaction is stored in the distributed ledger after the appropriate consensus is formed between the nodes.
  • the main features of the blockchain are: (1) In transactions between participants on the distributed ledger system, the transactions are finalized by consensus building or approval by (optional or specific) participants rather than by a central authority. 2) Collect multiple transactions as a block, record them in a distributed ledger in a daisy chain, and make hash calculations on consecutive blocks to make tampering virtually impossible. (3) All participants are the same in the distributed ledger. By sharing the ledger's ledger data, it is possible to confirm the transaction by all participants.
  • the distributed ledger technology including such a blockchain has a structure for performing reliable data management/sharing and contract-based transaction execution/management as a mechanism for the financial field and IoT (Internet of Internet). Thing) is being studied for application in a wide range of fields.
  • Smart Contract is also called a digitalized (software programmed) contract, and is realized by programmatically describing processes such as input and output of ledger data.
  • Each node in the distributed ledger system executes such a smart contract while trying to form an agreement with each other, and updates each ledger data with the execution result and the like.
  • the distributed ledger is a distributed database characterized by securely sharing ledger data handled among a plurality of nodes (distributed ledger nodes) that constitute the distributed ledger system.
  • distributed ledger is also called a block chain.
  • a permission type also called a consortium type
  • Participants of the distributed ledger system in the present embodiment are companies such as buyer companies and supplier companies that make up the supply chain, and use the above-mentioned service platform (existing service platform that supports business collaboration centering on ordering and ordering business). This is because the user has completed the usage registration of.
  • service platform existing service platform that supports business collaboration centering on ordering and ordering business.
  • element technologies such as hash chains and consensus protocols are used for sharing the above-mentioned data.
  • RDB Relational DataBase
  • KVS Key-Value Store
  • the state information is managed by the above-described KVS data structure in which, for example, the ID of the bill in the ordering/ordering item is used as a key to associate the status of the settlement process at each stage in the item.
  • the nodes of the distributed ledger system can acquire the status of the settlement processing of the relevant item, for example, using the invoice ID of the order item as a key.
  • the nodes update this state information every time a transaction is issued/stored, in accordance with the processing according to the settlement operation support method of this embodiment.
  • the smart contract described above is a program that describes processing such as input and output of ledger data.
  • the smart contract is installed in a node (distributed ledger node) belonging to the distributed ledger system and executed at an appropriate timing.
  • the nodes that execute the smart contract are not necessarily all the nodes that belong to the distributed ledger system, but all the nodes that belong to the distributed ledger system update their ledger data according to the execution result of the smart contract.
  • a transaction is each process performed by each of the above-mentioned nodes executing a smart contract while interlocking based on a consensus protocol or the like. Examples of transactions include reference to ledger data and updating of ledger data.
  • arguments in the transaction.
  • the transaction argument include the key of the reference target data (that is, the bill ID, etc.), the key of the update target data, and the updated value (value).
  • FIG. 1 is a network configuration diagram including a settlement operation support system 10 of this embodiment.
  • the settlement operation support system 10 shown in FIG. 1 is a computer system that manages the status of a predetermined event related to the settlement operation efficiently between the parties without any omission and with appropriate immediacy to improve the efficiency of the settlement operation. ..
  • the users of the distributed ledger system 5 shown in FIG. 1, that is, the companies having the ordering/accepting projects are, for example, buyers and suppliers constituting the supply chain.
  • Each of these companies operates a node.
  • the node of the buyer company is the buyer terminal 20
  • the node of the supplier company is the supplier terminal 30.
  • the buyer terminal 20 and the supplier terminal 30 can communicate with each other via an appropriate network 1 such as the Internet.
  • the buyer terminal 20 and the supplier terminal 30 are terminals that can access the ordering/ordering system 2 (service infrastructure), which is the platform for performing the ordering/ordering operations described above, through a predetermined authentication process. That is, in the ordering/ordering system 2, the buyer company operates the buyer terminal 20 to order materials and the like to the supplier company, and the supplier company receives an order via the supplier terminal 30. After that, the supplier company delivers the ordered materials to the buyer company for inspection.
  • service infrastructure is the platform for performing the ordering/ordering operations described above
  • the settlement operation support system 10 of the present embodiment receives, for example, a notification from the ordering/ordering system 2 regarding an ordering/ordering case processed by the ordering/ordering system 2 for which the inspection by the buyer company has been completed, and this triggers And start the necessary processing.
  • the settlement business support system 10 has one aspect as a management system that leads the settlement business support method as described above, and is also one of the nodes (distributed ledger node) in the distributed ledger system 5.
  • the settlement operation support system 10 appropriately cooperates with the buyer terminal 20 and the supplier terminal 30 to execute a series of processes such as issuing a transaction triggered by its own processing, consensus building, and storing in a distributed ledger. It is possible.
  • the settlement operation support system 10 responds to an appropriate financial institution system such as the bank system 40 or the digital currency system 50 in response to a payment confirmation instruction from the user or according to the status of the payment procedure of the settlement price in the state information.
  • an appropriate financial institution system such as the bank system 40 or the digital currency system 50
  • the agreement is stored in the distributed ledger, and the status in the state information is updated to “payment completed”.
  • the settlement operation support system 10 receives a request for payment procedure (payment processing) of a predetermined amount addressed to a supplier company from a buyer terminal 20 with respect to a certain invoice, for example, and then the bank system 40 or the digital currency system described above.
  • An appropriate financial institution system such as 50 is instructed to perform the deposit process with the content indicated by the invoice.
  • the settlement operation support system 10 obtains the result of the deposit processing according to this instruction from the relevant financial institution system, and when the completion of the deposit processing is confirmed, issues a deposit completion transaction relating to the settlement operation of the relevant invoice, After the consensus is formed, it is stored in the distributed ledger, and the status in the state information is updated to "payment completed".
  • the operation of updating the status in the state information to "payment completed” corresponds to the clearing process of the order receiving/ordering case. In other words, it means that the necessary settlement operation has been completed through the registration of the bill of the relevant ordering/ordering item, the registration of the payment procedure, and the deposit process.
  • Hardware configuration ---
  • FIG. 2 is a diagram showing an example of the hardware configuration of the settlement operation support system 10 according to this embodiment.
  • the settlement operation support system 10 includes a storage unit 11 configured by an appropriate nonvolatile storage element such as SSD (Solid State Drive) and a hard disk drive, a memory 13 configured by a volatile storage element such as RAM, and a storage unit 11
  • the program 12 stored in the memory 13 is executed by reading the program 12 into the memory 13 to perform overall control of the device itself, and also performs various judgments, calculations, and control processes such as a CPU 14 and other devices connected to the network 1.
  • the communication unit 15 is responsible for communication processing with
  • the payment operation support system 10 may include an input unit that receives a key input and a voice input from a user, and an output unit such as a display that displays processed data, if necessary.
  • the distributed ledger 100 in addition to the program 12 for implementing the functions required as the settlement operation support system 10 of the present embodiment, the distributed ledger 100, the block chain 111, the state information 112, and the smart contract 113. Is at least remembered.
  • the hardware configuration of the settlement operation support system 10 is the same for the buyer terminal 20 and the supplier terminal 30. --- Execution example of settlement business support method ---
  • FIG. 3 is a diagram showing a flow example 1 of the settlement operation support method according to the present embodiment.
  • the settlement operation support system 10 has received a notification of “inspection completion” from the ordering/ordering system 2 or the buyer terminal 20 regarding a certain ordering/ordering case.
  • this notification includes identification information of the ordering item (eg, order number), item name/item name, order amount, estimated deposit amount, estimated deposit date, buyer company, supplier company, and payment unit content. It contains various information that can be included in the ordering contract.
  • the settlement operation support system 10 issues a transaction for the notification regarding the ordering/receiving case for which the above-mentioned “inspection completion” notification was received, and stores it in the distributed ledger 110 after consensus formation (s10). Further, the settlement operation support system 10 in s10 stores information regarding this transaction in the state information 112.
  • the information stored in the state information 112 is divided according to the value of a stakeholder such as a buyer company or a supplier company, and access control is performed, and the information is delivered to the node of the stakeholder, that is, the buyer terminal 20 or the supplier terminal 30. That is, the buyer company and the supplier company can only view the state information 112 regarding the ordering/ordering project in which the buyer company or the supplier company is involved.
  • the state of such browsing is as shown in the transaction item list screen 400 in FIG.
  • the list screen 400 has an interface configuration in which two sheets, “order” and “order”, can be selected by tabs.
  • each company that is a stakeholder has a structure corresponding to that it can be either a buyer company or a supplier company depending on the position of ordering.
  • Each sheet is composed of records including items such as date and time, order number, case/article name, estimated payment date, status, and final procedure person.
  • the person in charge of browsing this list screen 400 (the person in charge of the supplier company as a position) operates the supplier terminal 30 to click, for example, the relevant record, and then the inspection contents (FIG. 5: confirmation screen of the inspection contents) After confirming 500), the billing information registration button 501 is clicked. It is also possible to adopt a mode in which the supplier company collectively registers a plurality of inspection completion cases as one billing information.
  • the settlement operation support system 10 receives the click on the registration button 501 described above, for example, the bill number is generated according to a predetermined rule, and the bill number “A1”, the order number “0000001”, and the item name “ Brake caliper”, quantity "500”, bill amount " ⁇ 15,000”, billing company “XX company”, billing company “YY company”, transfer destination " ⁇ bank, ⁇ branch, ordinary account”
  • the billing information including each value such as " ⁇ ” and the deadline (payment deadline) "2018/08/31” is generated, and the above-mentioned supplier terminal is used as a billing information confirmation screen 600 (see FIG. 6). 30 (s11).
  • the above-mentioned person in charge clicks for example, the bill registration button 601 on the confirmation screen 600 described above.
  • the settlement operation support system 10 receives the click of the above-mentioned registration button 601, issues a transaction related to the registration/issuance of the invoice for the relevant ordering/ordering matter, and stores it in the distributed ledger 110 after consensus formation (s12). ).
  • the settlement operation support system 10 in s12 updates the status of the record of the state information 112 (the record of which the key is "A10000001") related to the ordering/accepting matter to "issue bill” or the like in accordance with the issuance of this transaction. ..
  • registration/issuance of billing information that is, billing registration is completed.
  • the corresponding record updated in the state information 112 is assumed to have a key such as “A10000001”, which is a merged bill number “A1” and order number “0000001”. Further, the settlement operation support system 10 transmits a bill issuance notification to the buyer terminal 20 of the trading partner “XX company” included in the above-mentioned billing information (s13).
  • the settlement operation support system 10 receives, for example, the processing of s12 described above, and, for example, the transaction item list screen 700 (see FIG. 7) displayed on the buyer terminal 20 of the customer “XX company”.
  • the corresponding record record of purchase order number "0000001”
  • highlighting control such as font size expansion, underlining, bolding, and change of character color is performed. Make it easier for the person in charge at the buyer company to recognize that the bill has been issued.
  • a message to the effect that a bill has been issued for the relevant ordering/ordering item may be displayed at a predetermined location on the list screen 700.
  • the list screen 700 has an interface configuration in which two sheets of “order” and “order” can be selected by tabs.
  • the list screen 700 is browsed from the standpoint of the buyer company, and the “order” sheet is displayed.
  • the person in charge of browsing this list screen 700 (the person in charge of the buyer company as a position) operates the buyer terminal 20 and, for example, clicks the corresponding record to display the contents of the bill (FIG. 8: bill contents). After confirming the confirmation screen 800), the payment procedure button 801 is clicked. In this case, the buyer terminal 20 notifies the settlement operation support system 10 of the click event.
  • the settlement operation support system 10 Upon receiving the notification, the settlement operation support system 10 instructs the system of the financial institution that can transfer to the “transfer destination” indicated by the invoice to perform the transfer process with the content indicated by the invoice (s14).
  • the bank system 40 and the digital currency system 50 correspond to the system of the financial institution in this case. Note that the above-described transfer process can be assumed to be the same as the case where the financial institutions are different between the transfer source (account of the buyer company) and the transfer destination (account of the supplier company).
  • the system of the financial institution that has received the transfer instruction moves a predetermined amount of funds managed for the buyer company to the designated account of the supplier company, etc., that is, executes the transfer process, according to the content of the instruction. Further, the result of this transfer process is notified to the above-mentioned settlement operation support system 10 (which may include the buyer terminal 20).
  • the settlement operation support system 10 issues a transaction related to registration of payment information at the amount indicated by the invoice, and stores it in the distributed ledger after consensus formation, in accordance with the above-mentioned transfer process (s15).
  • the settlement operation support system 10 updates the status related to the invoice in the state information 112 to, for example, “payment information registered” or “payment completed”.
  • the settlement operation support system 10 receives the notification of the result of the transfer processing from the system of the financial institution described above and confirms that the deposit processing at the amount indicated by the relevant invoice is completed, the settlement operation of the relevant invoice is completed. Is issued and stored in the distributed ledger after consensus formation (s16). It should be noted that it is possible to envisage a situation in which the series of processing relating to the deposit processing described above is performed (with appropriate cooperation with an EDI function such as the order receiving/ordering system 2) using identification information such as an order form number or an invoice number as a key. Such a configuration is similarly applicable to other processing.
  • the settlement operation support system 10 updates the status related to the invoice in the state information 112 to “payment completed”.
  • the operation of updating the status in the state information 112 to “payment completed” corresponds to an erasing process related to the settlement business of the order receiving/ordering case. In other words, it means that the necessary settlement operation has been completed through the registration of the bill of the relevant ordering/ordering item, the registration of the payment procedure, and the deposit process.
  • the buyer terminal 20 notifies the payment operation support system 10 of the click event, and the payment operation support system 10 executes the transfer processing instruction.
  • the supplier terminal 30 executes the payment confirmation process via the inquiry API or the like to the system of the financial institution that can transfer to the above-mentioned “transfer destination”, and sends it to the supplier company. It is also possible to obtain and output the payment history of and to confirm the transfer process with the contents indicated by the invoice by the person in charge of the supplier or the like. In this case, the supplier terminal 30 notifies the settlement operation support system 10 of the result of the payment confirmation by the person in charge or the like (the result of confirming the payment). On the other hand, the settlement operation support system 10 that has received this will perform processing such as issuing a payment completion transaction relating to the settlement operation of the invoice and storing it in the distributed ledger. In such a form, for example, the relevant financial institution does not open the API relating to the transfer process to the settlement operation support system 10, and the transfer process by the buyer company can be confirmed only by the inquiry from the supplier terminal 30. It is valid.
  • the person in charge of the buyer company clicks the corresponding record on the list screen 700 (FIG. 7) to display the contents of the bill ( FIG. 8: After confirming the confirmation screen 800 of the billing contents, a desired payment method may be designated, and then the payment procedure button 801 may be clicked.
  • the above-mentioned person in charge specifies the installment payment by a predetermined number of times as a desired payment method using the check box 901 (see FIG. 9) which is an interface on the list screen 700, and then clicks the button 801. Then, the buyer terminal 20 having received this notifies the settlement operation support system 10 of the value of the content specified by the interface 901.
  • the number of installment payments described above is specified in advance in a predetermined contract between the buyer company and the supplier company and when placing and receiving an order, and the operation designated by the person in charge is performed by the check box 901 described above. It corresponds to the desire for it.
  • a form in which the buyer company specifies the number of installment payments each time can be assumed.
  • the payment operation support system 10 pays the number of payments corresponding to the specified number of times by dividing the amount of the payment fee indicated by the target record (billing registration) by the specified number of times.
  • a transaction related to the procedure is issued, and after the consensus is formed, the transaction is stored in the distributed ledger 110 (s20).
  • the payment operation support system 10 updates the status related to the invoice in the state information 112 to “payment registration completed” (s21) along with s20, and ends this flow. Subsequent processing is similarly performed, such as displaying the corresponding record (the number of records divided into the specified number of times) on the “Order” sheet of the list screen 700 and the transfer processing in response to the click of the payment procedure button 801. To do.
  • the buyer terminal 20 to which the bill issuance notification is transmitted in s13 in the above-described processing it is possible to envisage a case where the payment method desired by the person in charge of the buyer company is lump sum payment instead of installment payment.
  • the above-mentioned person in charge specifies a lump sum payment in which a plurality of invoices are collected as a desired payment method, and then clicks the button 801. And Then, the buyer terminal 20 having received this notifies the settlement operation support system 10 of the value of the content specified by the interface 901.
  • the settlement operation support system 10 issues a transaction related to the payment procedure with the sum of the payment amounts indicated by each target record (billing registration) to form an agreement. After that, the transaction is stored in the distributed ledger 110 (s30).
  • the payment operation support system 10 updates the status of each invoice in the state information 112 to “payment registration completed” at s30 (s31), and ends this flow. Subsequent processing is processing of displaying the corresponding record (record in which the contents of a plurality of invoices are combined into one) on the “Order” sheet of the list screen 700, and the transfer processing in response to the click of the payment procedure button 801. And so on.
  • the settlement work triggered by the acceptance status is appropriately supported.
  • each status from bill to clear can be shared in real time between the parties. Since such a response is realized by the service provision form based on the distributed ledger technology (block chain), the authenticity and completeness of various data regarding the above-mentioned billing and payment are guaranteed, and the final clearing process The reliability is also favorable.
  • the system side responds appropriately to the creation and storage management of invoices that correspond to revisions of taxation and other legal systems (eg, the method of storing eligible invoices, etc.).
  • the introduction and application of the service will be easy.
  • the predetermined node receives a payment confirmation instruction from the user or a predetermined financial institution system according to the status of the payment procedure of the payment in the state information. If a process for acquiring information on a deposit event relating to an account and the information indicates deposit of the payment for the order placement/acceptance project, the transaction for deposit of the payment for settlement is issued, and after the agreement is formed, The processing of storing the transaction in the distributed ledger and the processing of updating the status of the payment amount to the payment completion in the state information may be executed.
  • the settlement operation support system side can check the payment status of the settlement price, appropriately judge the trigger of the clearing process according to the result, and can execute the corresponding process.
  • the status of a predetermined event related to the settlement business can be managed efficiently between the parties without any omission and with appropriate immediacy, and the settlement business can be made more efficient.
  • the predetermined node refers to the state information, and performs each processing of the settlement operation associated with the ordering/ordering case of a predetermined organization of a predetermined condition or an operation organization of the predetermined node.
  • the status of each process may be specified and the status of each process may be displayed on the output unit.
  • each organization such as a buyer and a supplier can reliably and easily check the status related to the settlement business of the order placement/reception project to which he/she is involved, and it is possible to appropriately perform each procedure necessary for carrying out the settlement business. ..
  • the status of a predetermined event related to the settlement business can be managed efficiently between the parties without any omission and with appropriate immediacy, and the settlement business can be made more efficient.
  • the predetermined node performs payment registration for each of the processes for displaying a status on the output unit, which is a process of billing registration and the status of which is completed.
  • a transaction relating to the payment procedure at the amount of the settlement price indicated by the claim registration is issued, and after the agreement is formed, the transaction is stored in the distributed ledger, and the payment procedure is executed. May be updated to the payment registration completion in the state information.
  • the predetermined node makes a payment with respect to each of the processes of which the status is displayed on the output unit, which is a billing registration process and the status indicates completion.
  • a transaction relating to a payment procedure of a number corresponding to the predetermined number of times is issued in an amount obtained by dividing the amount of the payment amount indicated by the bill registration by the predetermined number of times.
  • the transaction may be stored in the distributed ledger after the agreement has been formed, and the status of the payment procedure may be updated to payment registration completion in the state information.
  • the payment price indicated by the billing registration can be divided into payment targets, and the payment business can be performed according to the needs of each organization.
  • the status of a predetermined event related to the settlement business can be managed efficiently between the parties without any omission and with appropriate immediacy, and the settlement business can be made more efficient.
  • the predetermined node is a billing registration process out of the respective processes related to each ordering/accepting item whose status is displayed on the output unit, and the status indicates completion.
  • a transaction related to the payment procedure with the total amount of the settlement price of each ordering item forming the ordering item group is received.
  • the transaction may be issued, the transaction may be stored in the distributed ledger after the consensus is formed, and the status of the payment procedure may be updated to payment registration completion in the state information.
  • a predetermined specific node among the nodes of the distributed ledger system relates to the application process, a process of acquiring information on the deposit event, and payment of the settlement price. Issuing a transaction, executing the process of storing the transaction in the distributed ledger after the consensus formation, and the process of updating the status of the settlement price to payment completion in the state information, Good.
  • the node of each participating company distributed ledger node
  • the specific node (payment system) of the operating company of the distributed ledger system
  • specific processing such as clearing processing is performed.
  • the status of a predetermined event related to the settlement business can be managed efficiently between the parties without any omission and with appropriate immediacy, and the settlement business can be made more efficient.
  • the predetermined node receives a payment confirmation instruction from a user or a predetermined financial institution system in accordance with the status of the payment procedure of the payment in the state information. If a process for acquiring information on a deposit event relating to an account and the information indicates deposit of the payment for the order placement/acceptance project, the transaction for deposit of the payment for settlement is issued, and after the agreement is formed, A process of storing a transaction in the distributed ledger and a process of updating the status of the payment amount to the payment completion in the state information may be executed.
  • the predetermined node refers to the state information, and performs each processing of the settlement operation accompanying the ordering/ordering case of a predetermined organization under a predetermined condition or an operating organization of the predetermined node. May be specified, and the status of each process may be displayed on the output unit.
  • the settlement operation support method of the present embodiment among the processes in which the predetermined node displays the status on the output unit, payment registration is performed for a process of billing registration and the status indicates completion.
  • a transaction relating to the payment procedure at the amount of the settlement price indicated by the claim registration is issued, and after the agreement is formed, the transaction is stored in the distributed ledger, and the payment procedure is executed. May be updated to the payment registration completion in the state information.
  • the predetermined node makes a payment for a process of billing registration and a status of completion among the processes of which the status is displayed on the output unit.
  • a transaction relating to a payment procedure of a number corresponding to the predetermined number of times is issued in an amount obtained by dividing the amount of the payment amount indicated by the bill registration by the predetermined number of times.
  • the transaction may be stored in the distributed ledger after the agreement has been formed, and the status of the payment procedure may be updated to payment registration completed in the state information.
  • the predetermined node is a bill registration process out of the respective processes related to each order placement/acceptance item whose status is displayed on the output unit, and the status indicates completion.
  • a transaction related to the payment procedure with the total amount of the settlement price of each ordering item forming the ordering item group is received.
  • the transaction may be issued, the transaction may be stored in the distributed ledger after the consensus is formed, and the status of the payment procedure may be updated to payment registration completion in the state information.
  • a predetermined specific node among the nodes of the distributed ledger system relates to the application process, a process of acquiring information on the deposit event, and payment of the payment amount. It is also possible to execute a process of issuing a transaction, storing the transaction in the distributed ledger after the consensus formation, and a process of updating the status of the payment amount to the payment completion in the state information.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Finance (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Economics (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Technology Law (AREA)
  • Computer Security & Cryptography (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

複数の組織それぞれのノードで構成された分散台帳システム５において、ノードのうち少なくとも所定ノード１０が、分散台帳１１０を格納する記憶部１１と、所定組織間での受発注に伴う決済業務のトランザクションを受信し、分散台帳システム５における所定の合意形成を経た上で、分散台帳１１０に格納する処理と、決済業務における各処理のステータスを分散台帳１１０のステート情報１１２として管理する処理と、ステート情報１１２における決済代金のステータスが入金完了となる事に応じ、対応する受発注案件の消込処理を行う処理を実行する演算部１４を含む構成とする。

Description

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

Claims (14)

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

Priority Applications (2)

Application Number Priority Date Filing Date Title
US17/299,069 US20220058599A1 (en) 2018-12-06 2019-11-29 Settlement operation support system and settlement operation support method
SG11202105870VA SG11202105870VA (en) 2018-12-06 2019-11-29 Settlement operation support system and settlement operation support method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2018228913A JP7210251B2 (ja) 2018-12-06 2018-12-06 決済業務支援システムおよび決済業務支援方法
JP2018-228913 2018-12-06

Publications (1)

Publication Number Publication Date
WO2020116337A1 true WO2020116337A1 (ja) 2020-06-11

Family

ID=70975116

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/046740 WO2020116337A1 (ja) 2018-12-06 2019-11-29 決済業務支援システムおよび決済業務支援方法

Country Status (4)

Country Link
US (1) US20220058599A1 (ja)
JP (1) JP7210251B2 (ja)
SG (1) SG11202105870VA (ja)
WO (1) WO2020116337A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111861477A (zh) * 2020-08-06 2020-10-30 深圳壹账通智能科技有限公司 基于区块链的交易后数据处理方法、装置和计算机设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0129962B2 (ja) * 1982-07-15 1989-06-15 Hitachi Ltd
JP2002216039A (ja) * 2001-01-18 2002-08-02 Sakura Bank Ltd 決済管理システム、決済管理方法、決済管理プログラムを記録した記録媒体及び決済管理プログラム
JP2018139068A (ja) * 2017-02-24 2018-09-06 株式会社三井住友銀行 スマートコントラクトによるエスクロー決済方法およびシステム

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170221066A1 (en) * 2015-07-01 2017-08-03 The Clearing House Payments Company, L.L.C. Real-time payment system, method, apparatus, and computer program
US20190087893A1 (en) * 2016-05-06 2019-03-21 Othera Pty Ltd Methods and Systems for Blockchain Based Segmented Risk Based Securities
EP3510546A4 (en) * 2016-09-12 2020-05-06 Baton Systems, Inc. SYSTEMS AND METHODS FOR FINANCIAL MANAGEMENT
EP3593313A1 (en) * 2017-03-07 2020-01-15 Mastercard International Incorporated Method and system for recording point to point transaction processing
CA3056717A1 (en) * 2017-03-17 2018-09-20 Royal Bank Of Canada Systems and methods for hybrid blockchain platform
JP6429962B1 (ja) * 2017-09-04 2018-11-28 ヤフー株式会社 情報処理装置、情報処理方法、及び情報処理プログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0129962B2 (ja) * 1982-07-15 1989-06-15 Hitachi Ltd
JP2002216039A (ja) * 2001-01-18 2002-08-02 Sakura Bank Ltd 決済管理システム、決済管理方法、決済管理プログラムを記録した記録媒体及び決済管理プログラム
JP2018139068A (ja) * 2017-02-24 2018-09-06 株式会社三井住友銀行 スマートコントラクトによるエスクロー決済方法およびシステム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
MORIKI, TOSHIOMI: "Business innovation using blockchain", 13 November 2017 (2017-11-13), pages 4, 13, 15, Retrieved from the Internet <URL:https://www.jipdec.or.jp/sp/topics/event/u71kba000000an5u-att/12_hitachi_j_pdf> [retrieved on 20200214] *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111861477A (zh) * 2020-08-06 2020-10-30 深圳壹账通智能科技有限公司 基于区块链的交易后数据处理方法、装置和计算机设备

Also Published As

Publication number Publication date
JP2020091695A (ja) 2020-06-11
US20220058599A1 (en) 2022-02-24
SG11202105870VA (en) 2021-07-29
JP7210251B2 (ja) 2023-01-23

Similar Documents

Publication Publication Date Title
US8380553B2 (en) Architectural design for plan-driven procurement application software
US8396731B2 (en) Architectural design for service procurement application software
US8676617B2 (en) Architectural design for self-service procurement application software
US8447657B2 (en) Architectural design for service procurement application software
US8660904B2 (en) Architectural design for service request and order management application software
TWI522947B (zh) 結算業務支援系統及結算業務支援方法
JP6224283B1 (ja) スマートコントラクトによるエスクロー決済方法およびシステム
US8315900B2 (en) Architectural design for self-service procurement application software
US8321250B2 (en) Architectural design for sell from stock application software
US20060085302A1 (en) Flexible cost and revenue allocation for service orders
US20070156500A1 (en) Architectural design for sell from stock application software
US20180082319A1 (en) Systems and methods for providing credit to financial service accounts
WO2020116337A1 (ja) 決済業務支援システムおよび決済業務支援方法
JP4129959B2 (ja) 取引システムおよび取引方法
US20200160306A1 (en) Systems and Methods for Payment Transaction Coding and Management
KR100476236B1 (ko) 인터넷을 기반으로 한 신용카드의 매출전표 처리 방법
KR101520167B1 (ko) 하도급 통합 관리 시스템 및 이의 실행 방법
JP6351816B1 (ja) ポイントシステムを用いた３者型クラウドファンディングシステム
WO2021141083A1 (ja) 給与前払管理装置、給与前払管理方法およびプログラム
JP6625578B2 (ja) 会計処理システム及び会計処理方法
KR101500859B1 (ko) 온라인 마켓 제공 방법 및 이를 실행하는 서버
JP2024052660A (ja) 情報処理装置、情報処理方法及び情報処理プログラム
JP2002183630A (ja) 入金管理システム、入金管理装置、入金管理方法及び記憶媒体
JP2015035127A (ja) クレジットカード決済業務システム
JPWO2006064543A1 (ja) 取引システムおよび取引方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19893745

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19893745

Country of ref document: EP

Kind code of ref document: A1