WO2020179505A1 - 決済システム及び決済方法 - Google Patents

決済システム及び決済方法 Download PDF

Info

Publication number
WO2020179505A1
WO2020179505A1 PCT/JP2020/007098 JP2020007098W WO2020179505A1 WO 2020179505 A1 WO2020179505 A1 WO 2020179505A1 JP 2020007098 W JP2020007098 W JP 2020007098W WO 2020179505 A1 WO2020179505 A1 WO 2020179505A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
request
token
community
execution device
Prior art date
Application number
PCT/JP2020/007098
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 SG11202107512WA priority Critical patent/SG11202107512WA/en
Priority to US17/422,949 priority patent/US20220148079A1/en
Publication of WO2020179505A1 publication Critical patent/WO2020179505A1/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
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising
    • G06Q30/0207—Discounts or incentives, e.g. coupons or rebates
    • 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/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • 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
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • 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/02—Banking, e.g. interest calculation or account maintenance
    • 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 an electronic payment system.
  • the electronic claim management system manages the transfer of funds (money claims) such as transfer by recording electronic claims (electronic claims) in the record ledger managed by the electronic claim recorder, and recording the claims.
  • the paying company (debtor) delivers the electronic debt to the delivering company (creditor), and the electronic debt management system records the occurrence of the debt. Then, on the due date of the payment of the electronic bond, the financial institution participating in the electronic bond management system transfers the funds from the account of the paying company to the account of the delivering company.
  • the electronic credit management system allows the transfer and discount of credits to be carried out in the same way as conventional bills, ensuring the liquidity of funds.
  • the present invention has been made in view of the above problems, and realizes electronic payment after guaranteeing the value of the electronic payment medium even if there are users who do not participate in the existing payment system.
  • the purpose is.
  • the present invention is a payment system including a payment requesting device having a processor and a memory, a payment execution device having a processor and a memory, and an electronic bond management device for managing an electronic bond or debt.
  • the device issues a payment request by an electronic payment medium
  • the payment execution device receives the payment request by the payment medium
  • causes the electronic bond management device to record the occurrence of the debt due to the payment request, and the payment medium.
  • a payment medium for example, a token
  • a payment request device for example, a payment request device
  • a payment execution device to realize the distribution of a bond and to cooperate with an existing payment system (electronic bond management device).
  • an existing payment system electronic bond management device
  • Example 1 of this invention shows an example of the apparatus configuration of a payment system.
  • 1 is a diagram showing an example 1 of the present invention, showing an example of a relationship between a token community that uses a payment system, a company, and a financial institution.
  • It is a block diagram which shows Example 1 of this invention and shows an example of a community settlement requesting apparatus.
  • 1 is a block diagram showing a first embodiment of the present invention and showing an example of a community settlement execution device.
  • It is a flowchart which shows Example 1 of this invention and shows an example of the token payment request processing performed by the community settlement request apparatus.
  • Example 1 of this invention shows an example of the token payment acceptance processing performed by the community settlement execution apparatus. It is a flow chart which shows Example 1 of the present invention and shows an example of token cashing request processing performed by the community settlement requesting device. It is a flow chart which shows Example 1 of the present invention and shows an example of token exchange acceptance processing performed by the community settlement execution device. It is a figure which shows Example 1 of this invention and shows an example of an account management table. It is a figure which shows Example 1 of this invention and shows an example of a community management table. It is a figure which shows Example 1 of this invention and shows an example of the token balance management table. It is a figure which shows Example 1 of this invention and shows an example of the token distribution ledger.
  • Example 1 of this invention shows an example of the electronic bond management table.
  • Example 2 of this invention shows an example of the token distribution ledger.
  • Example 3 of this invention shows an example of the token distribution ledger.
  • Example 4 of this invention and shows an example of the enterprise node.
  • FIG. 1 shows a first embodiment of the present invention and is a block diagram showing an example of a device configuration of a payment system.
  • the payment system of the first embodiment setstles a commercial transaction in an electronic currency (token) in a community of a supply chain composed of manufacturers, suppliers, and the like.
  • the payment system includes a community payment requesting apparatus 100 for requesting issuance of tokens as an electronic payment medium, payment of tokens, and request for redemption of tokens, and a community for executing operations such as issuing of tokens, discounts, and redemption.
  • a settlement execution apparatus 200 an electronic debt management system 300 for managing electronic debts (monetary claims), a management terminal 400 for managing the community settlement request apparatus 100 and the community settlement execution apparatus 200, and a community settlement request as in the conventional example.
  • the device 100, the community payment execution device 200, the electronic credit management system 300, and the network 10 that interconnects the management terminal 400 are included.
  • a community settlement request device 100 is arranged in a company included in this community, and a token is used to settle a commercial transaction.
  • the community that makes payment by token is referred to as a token community.
  • some of the companies included in the token community are registered as users of the electronic bond management system 300. It should be noted that the token community can also include financial institutions that carry out transactions with companies in the token community.
  • a community settlement execution device 200 that issues tokens, discounts, or processes cash, etc. is arranged at a financial institution that conducts transactions with each company in the community. Each financial institution participates in the electronic bond management system 300.
  • FIG. 2 is a diagram showing an example of the relationship between the token community using the payment system of the present invention and a company and a financial institution.
  • the supply chain consists of company X as a payment company (maker), company Y as a delivery company (supplier) delivering parts to company X, and company Z as a delivery company (supplier) delivering parts to company Y. It is composed.
  • Company X deals with financial institution A
  • company Y deals with financial institution B
  • company Z deals with financial institution C.
  • Supply chain companies X to Z and financial institutions A to C form a token community that uses tokens.
  • tokens are managed by sharing the token distribution ledger 500 with each company and financial institution.
  • Companies XZ have community payment request devices 100-X-100-Z to use the tokens.
  • reference numeral 100 is used with the "-" and subsequent parts omitted. The same applies to the reference numerals of other components.
  • the community settlement execution device 200 manages the token distribution ledger 500, manages an account, and requests the electronic bond management system 300 to record (a proxy request). Further, the request to the electronic bond management system 300 executed by the community settlement execution device 200 is a record of the generation of bonds in the token community.
  • the community payment request device 100 and the community payment execution device 200 share and manage the token distribution ledger 500. Then, the community settlement execution device 200 of the financial institutions A to C links the token distribution ledger 500 and the debt (or credit) of the electronic bond management system 300.
  • supply chain company X opens a token community account as a representative of the supply chain.
  • the community settlement requesting device 100-X of the company X requests the community settlement executing device 200-A of the financial institution A to open an account (issue a token) (P1).
  • the community payment execution device 200 opens a token community account and grants a token issuance right to the community payment request device 100-X of the company X (P2).
  • company X pays company Y with a token as a consideration for the delivery.
  • the community payment request device 100-X of the company X notifies the community payment execution device 200 of the financial institution A of the payment request by the token.
  • the community settlement execution device 200-A of the financial institution A describes the token issue in the token distribution ledger 500 and issues the token.
  • the community settlement execution device 200-A sends the issued token to the community settlement requesting device 100-B of the company Y (P3).
  • the token includes the history of payment from company X, the amount, the due date, and the recipient. Further, as the content written by the community payment request device 100-X to the token distribution ledger 500, the transaction content for issuing the token is recorded. The token issued by the financial institution A may be transmitted from the community settlement requesting device 100-A of the company X to the company Y.
  • the community settlement execution device 200-A acquires the payment request by the token of the company X from the token distribution ledger 500, and the debt from the company X to the company Y to the electronic bond management system 300 ( Record the occurrence of financial debt (P4).
  • the electronic bond management system 300 receives the request from the community settlement execution device 200-A and records the content of the token in the electronic bond management table 310.
  • the value of the token is registered in the electronic bond management system 300 by having the community settlement execution device 200-A record the contents of the token issued by the payment request of the company X in the electronic bond management table 310 of the electronic bond management system 300. It will be secured by the value of the fiat currency that was set.
  • the token community which is an electronic payment medium in the token community, and the real-world legal tender are linked to make a payment between companies. Can be realized.
  • the electronic bond management system 300 notifies the community settlement execution device 200-B of the financial institution B of the occurrence of the bond of the company Y.
  • the community settlement execution device 200-B of the financial institution B managing the account of the company Y records the remittance notification in the token distribution ledger 500.
  • Company Y requests financial institution B to transfer (discount) the token before the token payment date.
  • the company Y wishes to settle (transfer) with a token for a transaction with the company Z that does not use the electronic bond management system 300, and transfers and discounts to the company Z to the financial institution B. Apply (P6).
  • Financial institution B has a contract with company Y to use the electronic credit management system 300, and the community payment execution device 200-B changes the record of tokens subject to discount to transfer from company Y to financial institution B. , Requests the electronic bond management system 300 to write (P7).
  • Financial institution B calculates the discount rate of the token based on company X's credit, issues the discounted amount to financial institution B's equity, and issues the discounted remaining amount (value) to company Z as a token. That is, the financial institution B guarantees the payment from the enterprise Y to the enterprise Z even if the payment from the enterprise X to the enterprise Y is delayed, and carries out the discount as the guarantee consideration (P8).
  • the community payment execution device 200-B transmits the token of the discounted value to the community payment request device 100-Y of the company Y (P9).
  • the company Y community settlement requesting device 100-Y sends the token to the company Z community settlement requesting device 100-Z to execute payment.
  • the payment of the token from the company Y to the company Z may be transmitted from the community settlement execution device 200-B of the financial institution B to the community settlement requesting device 100-Z of the company Z.
  • the company Z that has received the token requests the financial institution C to redeem the token after the payment date (P10).
  • the community settlement execution device 200-C of the financial institution C requests the community settlement execution device 200-A of the financial institution A, which is the token issuer, to redeem the token (P11).
  • the token issuer can be acquired by the community settlement execution device 200 referring to the history of the token distribution ledger 500.
  • the community settlement execution device 200-A receives the request for the token redemption, transfers the discounted amount of the token from the account of the company X to the account of the company Z of the financial institution C, and the discount amount to the financial institution C. (P11). Then, since the payment of the token is completed, the community settlement execution device 200-A requests the electronic bond management system 300 to erase the debt of the company X (financial institution A).
  • the token community and the existing payment system are linked by the token distributed ledger 500 to secure the value of the electronic payment medium, and the token. It is possible to make payment within the community. And even if some of the companies in the token community do not subscribe to the existing payment system, it is possible to make payment securely.
  • FIG. 3 is a block diagram showing an example of the community settlement requesting device 100.
  • the community payment request device 100 is a computer including a memory 101, an arithmetic device 102, an input device 103, an output device 104, a communication device 105, and a storage device 106.
  • the storage device 106 includes a token payment request program 110 that requests the financial institution to pay with tokens, a token exchange request program 120 that requests the financial institution to exchange the received tokens, and a token distribution that shares tokens within the token community.
  • a ledger 500, a token balance management table 600, and a community management table 700 are stored.
  • the input device 103 is composed of, for example, a keyboard, a mouse, or a touch panel.
  • the output device 104 includes, for example, a display.
  • the communication device 105 is connected to the network 10 and communicates with other computers.
  • the token payment request program 110 and the token cashing request program 120 are loaded into the memory 101 and executed by the arithmetic unit 102.
  • the arithmetic unit 102 operates as a functional unit that provides a predetermined function by executing processing according to a program of each functional unit.
  • the arithmetic device 102 functions as a token payment request unit by executing processing according to the token payment request program 110.
  • the arithmetic unit 102 also operates as a functional unit that provides each function of a plurality of processes executed by each program.
  • a computer and a computer system are devices and systems including these functional units.
  • the token distribution ledger 500 is a management ledger that is distributed and shared among the participants of the token community.
  • the community settlement requesting devices 100 of the companies X to Z and the community settlement executing devices 200 of the financial institutions A to C are respectively stored and share token information.
  • FIG. 13 is a diagram showing an example of the token distribution ledger 500.
  • the token distribution ledger 500 is updated by the community payment execution device 200 of financial institutions A to C or the community payment request device 100 of companies XY.
  • the token distribution ledger 500 includes a transaction ID 501, a transaction content 502, a payer 503, a payee 504, a transaction amount 505, a target transaction 506, a record ID 507, and a guarantor 508 in one entry.
  • the transaction ID 501 stores the identifier (ID) of the transaction generated in the processing of the token.
  • the transaction identifier is an identifier given by the community settlement execution device 200 or the community settlement requesting device 100, and is a unique value within the token community.
  • the transaction content 502 stores the processing content of the token and the processing content of the company or financial institution.
  • the name of the sender of the token is stored in the payer 503.
  • the payee of the token is stored in the payee 504.
  • the transaction amount 505 stores the amount (or value) of the token.
  • the target transaction 506 stores a transaction ID related to the transaction.
  • the record ID 507 is set with the identifier of the electronic bond management system 300 in which the information related to the transaction is stored.
  • the record ID 507 uses a value set by the electronic bond management system 300 and can store one or more identifiers.
  • the guarantor 508 stores the name of the person or institution that guarantees the transaction amount of the transaction.
  • FIG. 12 is a diagram showing an example of the token balance management table 600.
  • the token balance management table 600 is shared by the participants of the token community in a distributed manner, and updated by the community settlement execution devices 200 of the financial institutions A to C.
  • the token balance management table 600 includes a token name 601, a token balance 602, an expiration date 603, and an exchange start date 604 in one entry.
  • the token name 601 stores the name or identifier determined by the community settlement execution devices 200 of the financial institutions A to C.
  • the token name 601 is a unique value within the token community.
  • the token balance 602 stores the value (amount of money) of the token.
  • the expiration date 603 stores the last day of the period in which the token can be used.
  • the exchange start date 604 stores the date when the token can be exchanged for currency.
  • the latest token balance is stored in the token balance 602.
  • FIG. 11 is a diagram showing an example of the community management table 700.
  • the community management table 700 is shared by the participants of the token community in a distributed manner, and is set by the community settlement execution devices 200 of the financial institutions A to C.
  • the community management table 700 includes a token name 701, an issuance amount 702, a participant name 703, a representative flag 704, and a Densai contract presence/absence 705 in one entry.
  • the token name or identifier is stored in the token name 701.
  • the issuance amount 702 stores the value (amount) of tokens that can be issued.
  • the participant name 703 stores the names of the participants of the token community who can use the token.
  • “Y” is set to the representative flag of the token community in the representative flag 704.
  • the token payer company X
  • the representative determines the participant name 703, but the present invention is not limited to this.
  • “Densai contract presence/absence 705” is set to “Y” for the participants of the token community who have a contract for using the electronic bond management system 300.
  • the electronic bond management system 300 As a payment system in the real world is shown, but the present invention is not limited to this.
  • any payment system that can register debts or claims can be used.
  • FIG. 4 is a block diagram showing an example of the community settlement execution device 200.
  • the community settlement execution device 200 is a computer including a memory 201, a calculation device 202, an input device 203, an output device 204, a communication device 205, and a storage device 206.
  • the storage device 206 includes a token issuing program 210 for issuing a token, a token payment receiving program 220 for processing a token payment request, a token cashing receiving program 230 for processing token cashing, a token distributed ledger 500, and a token.
  • a balance management table 600, a community management table 700, an account management table 800, and a credit score table 900 are stored.
  • token distribution ledger 500 the token balance management table 600, and the community management table 700 are the same as those of the community settlement requesting device 100, and a description thereof will be omitted.
  • the input device 203 is composed of, for example, a keyboard, a mouse, or a touch panel.
  • the output device 204 is composed of, for example, a display.
  • the communication device 205 is connected to the network 10 and communicates with other computers.
  • the arithmetic unit 202 operates as a functional unit that provides a predetermined function by executing processing according to a program of each functional unit.
  • the arithmetic unit 202 functions as a token issuing unit by executing processing according to the token issuing program 210.
  • the arithmetic device 202 also operates as a functional unit that provides each function of a plurality of processes executed by each program.
  • a computer and a computer system are devices and systems including these functional units.
  • FIG. 10 is a diagram showing an example of the account management table 800.
  • the account management table 800 is managed by the community settlement execution devices 200 of the financial institutions A to C.
  • the account management table 800 includes the account number 801 and the user name 802 and the balance 803 in one entry.
  • a score indicating the degree of credit is set for each participant in the token community.
  • the community settlement execution device 200 of each financial institution A to C can determine the discount rate of tokens and the like by referring to the score of the credit score table 900.
  • the electronic credit management system 300 is a computer system or a computer that provides the patent document 1 and the well-known electronically recorded credit service.
  • FIG. 14 is a diagram showing an example of an electronic bond management table 310 managed by the electronic bond management system 300.
  • the electronic bond management table 310 includes a record ID 311, a debtor 312, a creditor 313, a bond amount 314, and a deletion flag 315 in one entry.
  • the record ID 311 is an identifier given by the electronic bond management system 300 and is a unique value, and corresponds to the record ID 507 of the token distribution ledger 500.
  • the corporate name or name is stored in the debtor 312 and the creditor 313.
  • the amount of credit is stored in the credit amount 314.
  • “D” is stored in the deleted entry.
  • the credit of the company Y having the credit amount 314 of “100” is discounted and divided by the financial institution B, and the bond of the company Y having the credit amount 314 of “80” and the credit amount 314 of “20”.
  • An example of being divided into the claims of financial institution A is shown.
  • the electronic bond management system 300 is used as an existing payment system for managing bonds, but a single computer such as an electronic bond management device may be used.
  • FIG. 5 is a flowchart showing an example of the token issuance process. This processing is started when the token issuing program 210 of the community settlement executing apparatus 200 of the financial institution receives the token issuance request from the community settlement requesting apparatus 100 of the company.
  • the community payment execution device 200 is described as the subject of the process, but the token issuing program 210 and the arithmetic device 202 may be the subject of the process.
  • the community payment execution device 200 receives a token payment request from the company community payment request device 100 (S1).
  • the community settlement execution device 200 refers to the account management table 800 to acquire the account balance of the user who requested the token payment, and determines that the balance is not insufficient for the payment amount (S2).
  • the community payment execution device 200 determines the name of the token, and registers information such as the payment amount and the participants included in the token payment request in the community management table 700 (S3).
  • the community settlement execution device 200 sets the decided token name in the token name 701 of the community management table 700, sets the issue amount 702, and registers the sender of the payment request as a representative in the participant name 703,
  • the representative flag 704 is set to “Y”, and the Densai contract presence/absence 705 is set according to the presence/absence of a contract to use the electronic bond management system 300.
  • the community settlement execution device 200 registers the new token determined as described above in the token distribution ledger 500 as a token held by the financial institution (S4).
  • S4 a token held by the financial institution
  • the community settlement execution device 200 adds an entry with a transaction ID 501 of “TX100” as a new token and registers it in the token distribution ledger 500 of FIG.
  • the community payment execution device 200 transfers the new token issued by the financial institution to the possession of the representative who requested the payment, and completes the issuance of the token (S5).
  • the community settlement execution device 200 adds an entry in which the transaction ID 501 is “TX200” and the transaction content 502 is “issue”.
  • the transfer from the financial institution A to the company X is registered in the token distribution ledger 500 with the content that the payer 503 is “financial institution A” and the payee 504 is “company X”.
  • a new token registered by the financial institution is issued to the token distribution ledger 500 as a token for payment of company X with transaction ID 501 of "TX200". Then, the token distribution ledger 500 notifies the participants of the token community of the issuance of the new token.
  • the account of the financial institution for issuing the token can be an existing account for settlement such as checking account, or a special account for token settlement may be used.
  • the token issuance amount may be designated by the issuance request, or the total amount of the balance may be set as the issuance amount without being designated.
  • a representative of the community may individually register the participants.
  • a participant other than the representative may apply for participation, and the representative may approve and register in the community management table 700.
  • a financial institution or other organization determines that company X, company Y, and company Z constitute the supply chain based on transaction history (not shown), and registers company X to company Z in the participant name 703. You may.
  • FIG. 6 is a flowchart showing an example of token payment request processing. This process is started when the token payment request program 110 of the community payment request device 100 of the company receives the token payment request from the user.
  • the community payment request device 100 receives a token payment request from the input device 103 or the like (S10).
  • the token payment request includes, for example, the payment amount, the payee, the payment date, and the like.
  • the community settlement requesting apparatus 100 refers to the community management table 700 and determines whether or not the payee has a contract for using the electronic bond management system 300. If the payee is a user of the electronic bond management system 300, the process proceeds to step S12, and if not, the process proceeds to step S13.
  • step S12 the community settlement requesting device 100 registers the payment of the token to the payee in the token distribution ledger 500 with the transaction content 502 as “payment”.
  • step S13 since the beneficiary does not use the electronic bond management system 300, the community settlement request device 100 sets the transaction content 502 as a “guaranteed payment” and tokenizes the beneficiary as a payment to the financial institution B.
  • An example of registering in the token distribution ledger 500 as
  • a payment transaction (TX300 or TX400) is registered in the token distribution ledger 500.
  • the community settlement execution device 200 of the financial institution can detect that a new payment request from the company X to the company Y (company Z) has occurred.
  • FIG. 7 is a flowchart showing an example of token payment acceptance processing. This process is started when the token payment acceptance program 220 of the community payment execution device 200 of the financial institution detects a new payment request in the token distribution ledger 500.
  • the community settlement execution device 200 detects a new payment request entry from the token distribution ledger 500, and reads the payer 503, the payee 504, and the transaction ID 501 (S21).
  • step S22 whether or not the community payment execution device 200 refers to the account management table 800 and makes the payment at its own financial institution (hereinafter referred to as its own bank) based on the presence or absence of the payer's account. Is determined. If the payment is made by the bank, the process proceeds to step S23, and if not, the process ends.
  • its own bank its own financial institution
  • step S23 the community settlement execution device 200 refers to the community management table 700 and determines whether or not the payer is a representative. If the payer is the representative, the process proceeds to step S24, and if not, the process proceeds to step S26.
  • step S24 the community settlement execution device 200 requests (proxy billing) the electronic debt management system 300 for a record (occurrence record) that the payer has a debt.
  • step S25 the community settlement execution device 200 receives a response to the proxy request from the electronic bond management system 300 and records the received content in the token distribution ledger 500.
  • the community settlement execution device 200 refers to the community management table 700 in step S26, and the payee 504 (the operator of the community settlement requesting device 100 that issued the payment request). Determines whether the user has a contract for using the electronic bond management system 300. If there is a usage contract, the process proceeds to step S27, and if not, the process proceeds to step S29.
  • step S27 the community settlement execution device 200 requests the electronic bond management system 300 for a record (transfer record) that a payer other than the representative incurred a debt (substitution request).
  • the processing in this case is to transfer the claim from the representative (or other participant) to the payee.
  • step S28 the community settlement execution device 200 receives a response to the proxy request from the electronic bond management system 300, and records the received content in the token distribution ledger 500.
  • the community payment execution device 200 receives the identifier of the transfer record as a response to the proxy request, generates a new transaction ID 501 related to the transaction ID 501 of the payment, and adds an entry to the token distribution ledger 500.
  • the community settlement execution device 200 stores the identifier assigned by the electronic bond management system 300 in the record ID 507 of the entry, stores the transaction ID 501 of the payment transaction in the target transaction 506, and ends the process.
  • step S29 the community payment execution device 200 determines whether or not the guarantee can be given to the payer.
  • the community settlement execution device 200 determines whether or not to give a guarantee, based on a payment date, a transaction history of a financial institution, a credit history, and a predetermined standard. If the guarantee is given, the process proceeds to step S30, and if not, the process proceeds to step S37.
  • step S30 in order to discount the token, the community settlement execution device 200 refers to the credit score table 900 and calculates a discount amount for the payment amount from the credit score of the payer.
  • step S31 the community settlement execution device 200 divides the token into the equity of the financial institution and the equity of the beneficiary, and requests the electronic credit management system 300 to register the details of the division (proxy request). To do.
  • the discount amount is the equity of the financial institution, and the balance after deducting the discount amount from the payment amount is the equity of the recipient.
  • the payee converts the token into cash before the due date of the token
  • the token is split between the financial institution and the payee, and the payee receives another token before the due date of the token.
  • the payment is divided between the financial institution and the recipient, and then the transfer is made from the recipient to another recipient.
  • step S32 the community settlement execution device 200 receives a response to the proxy request from the electronic bond management system 300, and records the received content in the token distribution ledger 500.
  • the community payment execution device 200 stores the identifiers "D20, D21, D22" assigned by the electronic bond management system 300 in the record ID 507 of the entry, and the transaction (transaction ID 501) "TX400" of the guarantee payment in the target transaction 506. To store.
  • step S33 it is determined whether or not the divided token includes the transfer to the recipient. If the recipient exists, it means the transfer, so the process proceeds to step S34. If not, the process proceeds to step S37.
  • step S34 in order to transfer the token, the community settlement execution device 200 requests the electronic credit management system 300 (proxy request) to register (transfer record) the content of the transfer addressed to the recipient.
  • step S35 the community settlement execution device 200 receives a response to the proxy request from the electronic bond management system 300, and records the received content in the token distribution ledger 500.
  • the community payment execution device 200 stores the identifier "D22" given by the electronic bond management system 300 in the record ID 507 of the entry, and stores the guaranteed payment transaction (transaction ID 501) "TX400" in the target transaction 506.
  • step S36 the community payment execution device 200 records the guaranteed payment from the payer (financial institution B) to the payee (company Z) in the token distribution ledger 500.
  • the community settlement execution device 200 generates “TX500” as the transaction ID 501 of the guaranteed payment, and adds the entry to the token distribution ledger 500.
  • the community payment execution device 200 stores "financial institution B" in the guarantor 508 of the entry, "financial institution B" in the payer 503, and "company Z" in the recipient 504.
  • step S33 if it is determined in step S33 that the payment is not a transfer, the payer's debt is erased. Therefore, in order to erase the token, the community settlement execution device 200 guarantees that the transaction ID 501 is "TX400". Request (proxy request) the electronic bond management system 300 to delete the attached payment.
  • step S38 the community settlement execution device 200 receives a response to the proxy request from the electronic bond management system 300, and records the received content in the token distribution ledger 500.
  • the community payment execution device 200 stores the identifier "D21" given by the electronic bond management system 300 in the record ID 507 of the entry, and stores the guaranteed payment transaction (transaction ID 501) "TX400" in the target transaction 506.
  • a discount is given at the financial institution that executes the payment.
  • the financial institution can act to secure the debt on behalf of the payer. This makes it possible to guarantee the value of the token to a recipient who does not have a contract for using the electronic bond management system 300, in the same manner as legal currency.
  • FIG. 8 is a flowchart showing an example of token cashing request processing. This process is started when the token cashing request program 120 of the company community settlement requesting device 100 receives a token cashing request from the user.
  • the community settlement requesting device 100 receives a token cashing request from the input device 103 (S41).
  • the community settlement requesting apparatus 100 acquires the transaction ID 501 (or token name), the amount of money, and the user name (participant name 703) from the cash exchange request.
  • the community settlement requesting apparatus 100 refers to the community management table 700 to determine whether the user requesting cash conversion has a contract for using the electronic bond management system 300 (S42).
  • the community settlement requesting device 100 proceeds to step S43 when there is a usage contract, and proceeds to step S44 when there is no usage contract.
  • step S43 the community settlement requesting device 100 adds the token delivery whose transaction content 502 is “cash” to the token distribution ledger 500.
  • the community settlement requesting device 100 adds to the token distribution ledger 500 the delivery of tokens whose transaction content 502 is “guaranteed cash exchange”.
  • the community settlement requesting device 100 stores the name (or identifier) of the financial institution in the guarantor 508 of the token distribution ledger 500.
  • FIG. 9 is a flowchart showing an example of token cashing acceptance processing.
  • This processing is started when the token cashing acceptance program 230 of the community settlement execution device 200 of the financial institution detects a new cashing request in the token distribution ledger 500.
  • the community payment execution device 200 detects a new redemption entry from the token distribution ledger 500, and reads the payer 503 and the payee 504 and the transaction ID 501 (or token name) of the token to be redeemed (S51).
  • the community settlement execution device 200 refers to the account management table 800 and determines whether or not the payee 504 has his or her own account (S52). If the payee 504 has his own account, the process proceeds to step S53, and if not, the process ends.
  • step S53 the community settlement execution device 200 refers to the community management table 700 to determine whether the payee 504 has a contract for using the electronic bond management system 300. If the payee 504 has a contract for using the electronic bond management system 300, the process proceeds to step S54, and if not, the process proceeds to step S59.
  • step S54 the community payment request device 100 refers to the token distribution ledger 500, identifies the financial institution that issued the token based on the record ID 507 of the token to be redeemed, and redeems the token to the financial institution. Apply.
  • the application for cash exchange is notified to the issuing financial institution by the community settlement execution device 200 by adding a new cash exchange (exchange) request to the token distribution ledger 500.
  • a new cash exchange (exchange) request For example, when the transaction ID 501 of FIG. 13 is "TX800", the transaction content 502 is "exchange”, the payer 503 is “financial institution B”, and the payee 504 is "financial institution A”.
  • step S55 the community settlement execution device 200 requests the electronic bond management system 300 to add (substitute request) a record (erasure record) in which the debt is deleted at the financial institution that received the cashing request.
  • step S56 the community settlement execution device 200 receives a response to the proxy request from the electronic bond management system 300, and records the received content in the token distribution ledger 500.
  • the community settlement execution device 200 stores the identifier "D22" given by the electronic bond management system 300 in the record ID 507 of the entry, and stores the payment transaction (transaction ID 501) "TX800" in the target transaction 506.
  • the community payment execution device 200 detects the payment from the financial institution that issued the token (S57), the payment is made to the account of the user who applied for the cash conversion request, and the processing is completed (S58).
  • step S53 if the applicant for the cashing request does not have a contract to use the electronic bond management system 300, the process proceeds to step S59, and the community settlement execution device 200 tells the token issuing financial institution. Apply for guaranteed cash.
  • the guarantee of the debt to the token is performed by the financial institution that operates the community settlement execution device 200 that has received the cash conversion request. Note that, as described above, the application for cash exchange is notified to the issuing financial institution by the community settlement execution device 200 by adding a new cash exchange request to the token distribution ledger 500.
  • the transaction ID 501 in FIG. 13 is "TX700”
  • the entry of the transaction content 502 is "exchange”
  • the payer 503 is “financial institution C”
  • the payee 504 is "financial institution A”
  • the electronic bond management system 300 is requested to perform the cancellation registration, and the deposit from the financial institution A is deposited into the applicant's account.
  • the payment system of the first embodiment even in a community where there are companies (operators) who do not participate in the electronic credit management system 300, payment is made after guaranteeing the value of the electronic payment medium (token). It can be realized.
  • the token is used as the electronic payment medium, but the present invention is not limited to this, and virtual currency, points, or the like can be used as the electronic payment medium.
  • the present invention is not limited to this, and the value of the token can be guaranteed with a precious metal such as gold, for example.
  • the token distributed ledger 500, the token balance management table 600, and the community management table 700 are shown as an example, but the information is not limited to the table, and the schemaless It may be stored as data of.
  • token distribution ledger 500 is shared by the participants of the token community has been shown, but information viewing may be restricted. For example, payment and cash information can be viewed by the parties of the payer and payee and the financial institution, but prohibited by other participants.
  • the token distribution ledger 500 can be set with a plurality of sub-communities having different sharing ranges, and the sub-communities can be selectively used according to the disclosure range of the transaction content.
  • the present invention is not limited to this.
  • the settlement system of the first embodiment can be applied to any community that needs to transfer funds.
  • the community settlement execution device 200 is arranged in a financial institution, but the present invention is not limited to this.
  • it may be a group or organization that can pay legal tokens to the token community and can request the electronic bond management system 300 from the generation to the extinction of bonds corresponding to the token, or a settlement service company.
  • FIG. 15 shows the second embodiment and is an example of the token distribution ledger 500.
  • a blockchain is adopted for the token distribution ledger 500, and one entry shown in FIG. 13 is regarded as one transaction, and blocks 511, 512, and 513 are configured by a plurality of transactions and hash values. Shown. Other configurations are similar to those of the first embodiment.
  • the hash value of the block is calculated from the contents of a plurality of transactions in the block and the hash value of the immediately preceding block, and the transaction contents and the hash value are held in each block 511 to 513, respectively. ..
  • the blockchain technology is a well-known technology, and is a decentralized ledger management system that combines a P2P network, a consensus algorithm, a smart contract, anti-counterfeiting and encryption technology.
  • decentralization means that a specific participant is prohibited from monopolizing the management of data, and each participant participating in the block chain can manage the data.
  • transparency indicates that the information generated by each participant is disclosed to all participants and shared by all participants. Participants participating in the token community can view all information and the integrity of the recorded information is guaranteed.
  • Tamper resistance is to prevent data tampering by generating transactions by each participant and connecting each transaction in a chain based on the electronic signature and hash value. In addition, by disclosing the information generated by each participant, it is possible to suppress the desire to falsify the data.
  • Fault tolerance means that each participant keeps the data or a copy of the data with the participants participating in the blockchain, so that even if some participants fail, the data will not be damaged or lost. Is.
  • a hash value of the transaction content and the transaction identifier may be stored in each block.
  • the hash value of the block may be calculated from the hash value of the immediately preceding block, the hash value of the transaction content, and the transaction identifier.
  • the contents of the transaction may be retained by each participant.
  • a device for storing the transaction contents of each participant may be provided.
  • the contents of each transaction can be kept private and the contents of the transaction between each participant can be provided to a limited participant.
  • FIG. 16 shows the third embodiment and shows an example in which the community settlement requesting apparatus 100 and the community settlement executing apparatus 200 are treated as nodes for managing the token distribution ledger 500.
  • the company X node 1000X corresponds to the community payment request device 100-X (see FIG. 2) of the first embodiment
  • the company Y node 1000Y corresponds to the community payment request device 100-Y of the first embodiment
  • the financial institution A node 2000-A corresponds to the community payment execution device 200-A (see FIG. 2) of the first embodiment
  • the financial institution B node 2000-B corresponds to the community payment execution device 200-B of the first embodiment (see FIG. 2). (See FIG. 2).
  • FIG. 17 is a block diagram showing an example of the company X node 1000X.
  • the company X node 1000-X holds a copy of the token distribution ledger 500, calculates the latest balance of each token from the token distribution ledger 500, and stores it in the token balance management table 600.
  • the token distribution ledger 500 is composed of the block chain shown in the second embodiment.
  • the master of the token distribution ledger 500 is the token distribution ledger 500 of the financial institution A, and the other nodes hold a copy.
  • the payment systems of Examples 1 to 3 can have the following configurations.
  • a payment request device (community payment request device 100) having a processor (calculation device 102) and a memory (101), and a payment execution device (community payment execution device 200) having a processor (calculation device 202) and a memory (201). )
  • an electronic bond management device (electronic bond management system 300) for managing electronic bonds or debts, wherein the payment requesting device (100) is an electronic payment medium (token).
  • the payment execution device (200) receives the payment request by the payment medium (token), records the occurrence of the debt due to the payment request in the electronic bond management device (300), and makes the payment. Send the media to the recipient (504).
  • the community payment execution device 200 sets the value of the token (electronic payment medium) to the electronic credit management system 300. It is possible to realize the settlement after guaranteeing with.
  • the payment execution device (200) causes the electronic credit management device (300) to record a debt having a value corresponding to the payment medium (token).
  • the value of the payment medium is guaranteed.
  • the community payment execution device 200 (payment execution device) links the generated token (payment medium) debt to the electronic credit management system 300, so that the token (payment medium) is associated with the legal currency and has a value. Can be guaranteed.
  • the payment execution device (200) is the payment execution device (200) when the recipient cannot use the electronic credit management device (300). ) The operator (financial institution) guarantee is given and the payment medium (token) is transmitted to the payee.
  • the token can be distributed by granting the guarantee of the financial institution (operator) that operates the community settlement execution device 200.
  • the payment execution device (200) includes the payment execution device (200) when the payee cannot use the electronic bond management device (300). ), the remainder of the discount is used as the value of the payment medium (token) to the payee.
  • the financial institution (operator) of the community payment execution device 200 (payment execution device) that receives the payment request gives a discount and pays.
  • the financial institution can receive the consideration for the risk by using the residue obtained by subtracting the discount amount from the amount as the token to the payee 504.
  • the payment request device (100) issues a cash request for the payment medium (token), and the payment execution device (200) issues the cash request.
  • the operator of the payment request device (100) who applied for the cash request determines whether or not the electronic credit management device (300) can be used, and if it cannot be used, the cash request is accepted.
  • the operator of the payment execution apparatus (200) is notified as a guarantor to the issuer of the payment medium (token).
  • the payment request device (100) and the payment execution device (200) are distributed ledgers (token distributed ledger 500) for recording the transfer of the payment medium (token).
  • the payment requesting device (100) notifies the payment requesting device (200) of the payment request by writing the payment request into the distributed ledger (500).
  • the present invention is not limited to the above-described embodiments, but includes various modifications.
  • the above-described embodiments are described in detail in order to explain the present invention in an easy-to-understand manner, and are not necessarily limited to those having all the configurations described.
  • a part of the configuration of one embodiment can be replaced with the configuration of another embodiment, and the configuration of another embodiment can be added to the configuration of one embodiment.
  • any addition, deletion, or replacement of other configurations can be applied alone or in combination.
  • each of the above-mentioned configurations, functions, processing units, processing means, and the like may be realized by hardware by designing a part or all of them with, for example, an integrated circuit.
  • each of the above-described configurations, functions, and the like may be realized by software by a processor interpreting and executing a program that realizes each function.
  • Information such as programs, tables, and files that realize each function can be placed in a memory, a hard disk, a recording device such as SSD (Solid State Drive), or a recording medium such as an IC card, an SD card, and a DVD.
  • control lines and information lines are shown to be necessary for explanation, and not all control lines and information lines are shown on the product. In reality, it may be considered that almost all the configurations are connected to each other.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Game Theory and Decision Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

プロセッサとメモリを有する決済要求装置と、プロセッサとメモリを有する決済実行装置と、電子的な債権または債務を管理する電子債権管理装置と、を有する決済システムであって、前記決済要求装置は、電子的な決済媒体による支払要求を発行し、前記決済実行装置は、前記決済媒体による支払要求を受け付けて、当該支払要求による債務の発生を電子債権管理装置へ記録させ、前記決済媒体を受取人へ送信する。

Description

決済システム及び決済方法 参照による取り込み
　本出願は、平成３１年（２０１９年）３月５日に出願された日本出願である特願２０１９－０３９６７６の優先権を主張し、その内容を参照することにより、本出願に取り込む。
　本発明は、電子的な決済システムに関する。
　金融や商取引の電子化が進展しており、企業が所有する手形等の債権を電子化して、債権の流動性を向上させる技術として電子債権管理システムが知られている（例えば、特許文献１）。
　電子債権管理システムでは、電子債権記録機関が管理する記録原簿へ電子的な債権（電子債権）の記録を行うことで債権の発生とし、譲渡等の資金（金銭債権）の移動を管理する。支払企業（債務者）は納入企業（債権者）に対して電子債権を受け渡し、電子債権管理システム側では債務の発生を記録しておく。そして、電子債権の支払期日には、電子債権管理システムに参加する金融機関が支払企業の口座から納入企業の口座に資金を移動する。
　また、電子債権管理システムでは、従来の手形と同様に債権の譲渡や割引を行うことができ、資金の流動性を確保している。
特開２０１３－１２１４４号公報
　しかしながら、上記従来例では、支払企業と納入企業の全員が電子債権管理システムに加入していることが前提であり、電子債権管理システムへ加入していない納入企業は電子債権を利用することはできない、という問題があった。
　また、サプライチェーン等のコミュニティでは、仮想通貨などの電子的な決済媒体による決済を行うことも可能ではあるが、仮想通貨は法定通貨との関連はないため価値の保証はなく、利用するのが難しいという問題があった。
　そこで本発明は、上記問題点に鑑みてなされたもので、既存の決済システムに参加しない利用者が存在する場合でも、電子的な決済媒体の価値を保証した上で電子的な決済を実現することを目的とする。
　本発明は、プロセッサとメモリを有する決済要求装置と、プロセッサとメモリを有する決済実行装置と、電子的な債権または債務を管理する電子債権管理装置と、を有する決済システムであって、前記決済要求装置は、電子的な決済媒体による支払要求を発行し、前記決済実行装置は、前記決済媒体による支払要求を受け付けて、当該支払要求による債務の発生を電子債権管理装置へ記録させ、前記決済媒体を受取人へ送信する。
　したがって、本発明は、決済要求装置と決済実行装置を含むコミュニティ内で決済媒体（例えば、トークン）を発行して債権の流通を実現し、既存の決済システム（電子債権管理装置）と連携することで、決済媒体の価値を担保することができる。そして、本発明では、既存の決済システムに参加しない企業（運用者）が存在するコミュニティでも、電子的な決済媒体（トークン）の価値を保証した上で決済を実現することができる。
　本明細書において開示される主題の、少なくとも一つの実施の詳細は、添付されている図面と以下の記述の中で述べられる。開示される主題のその他の特徴、態様、効果は、以下の開示、図面、請求項により明らかにされる。
本発明の実施例１を示し、決済システムの装置構成の一例を示すブロック図である。 本発明の実施例１を示し、決済システムを利用するトークンコミュニティと、企業及び金融機関の関係の一例を示す図である。 本発明の実施例１を示し、コミュニティ決済要求装置の一例を示すブロック図である。 本発明の実施例１を示し、コミュニティ決済実行装置の一例を示すブロック図である。 本発明の実施例１を示し、コミュニティ決済実行装置で行われるトークン発行処理の一例を示すフローチャートである。 本発明の実施例１を示し、コミュニティ決済要求装置で行われるトークン支払要求処理の一例を示すフローチャートである。 本発明の実施例１を示し、コミュニティ決済実行装置で行われるトークン支払受け付け処理の一例を示すフローチャートである。 本発明の実施例１を示し、コミュニティ決済要求装置で行われるトークン換金要求処理の一例を示すフローチャートである。 本発明の実施例１を示し、コミュニティ決済実行装置で行われるトークン換金受け付け処理の一例を示すフローチャートである。 本発明の実施例１を示し、口座管理テーブルの一例を示す図である。 本発明の実施例１を示し、コミュニティ管理テーブルの一例を示す図である。 本発明の実施例１を示し、トークン残高管理テーブルの一例を示す図である。 本発明の実施例１を示し、トークン分散台帳の一例を示す図である。 本発明の実施例１を示し、電子債権管理テーブルの一例を示す図である。 本発明の実施例２を示し、トークン分散台帳の一例を示す図である。 本発明の実施例３を示し、トークン分散台帳の一例を示す図である。 本発明の実施例４を示し、企業ノードの一例を示す図である。
　以下、本発明の実施形態を添付図面に基づいて説明する。
　図１は、本発明の実施例１を示し、決済システムの装置構成の一例を示すブロック図である。本実施例１の決済システムは、メーカやサプライヤ等で構成されるサプライチェーンのコミュニティの中で、電子的な通貨（トークン）で商取引の決済を行う。
　決済システムは、電子的な決済媒体としてのトークンの発行依頼や、トークンの支払や、トークンの換金要求を実行するコミュニティ決済要求装置１００と、トークンの発行や割引や換金等の業務を実行するコミュニティ決済実行装置２００と、前記従来例と同様に電子債権（金銭債権）を管理する電子債権管理システム３００と、コミュニティ決済要求装置１００及びコミュニティ決済実行装置２００を管理する管理端末４００と、コミュニティ決済要求装置１００とコミュニティ決済実行装置２００と電子債権管理システム３００及び管理端末４００を相互に接続するネットワーク１０と、を含む。
　サプライチェーンを構成するメーカやサプライヤ等の企業でひとつのコミュニティが形成される。このコミュニティに含まれる企業にはコミュニティ決済要求装置１００が配置され、トークンによって商取引の決済が行われる。以下、トークンによって決済を行うコミュニティをトークンコミュニティとする。また、トークンコミュニティに含まれる企業の一部は、電子債権管理システム３００の利用者として登録されている。なお、トークンコミュニティの企業と取引を行う金融機関もトークンコミュニティに含むことができる。
　コミュニティの各企業と取引を行う金融機関には、トークンの発行や割引又は換金等の処理を行うコミュニティ決済実行装置２００が配置される。各金融機関は、電子債権管理システム３００に参加する。
　図２は、本発明の決済システムを利用するトークンコミュニティと、企業及び金融機関の関係の一例を示す図である。サプライチェーンは、支払企業（メーカ）としての企業Ｘと、企業Ｘへ部品を納入する納入企業（サプライヤ）としての企業Ｙと、企業Ｙへ部品を納入する納入企業（サプライヤ）としての企業Ｚで構成される。
　企業Ｘは金融機関Ａと取引を行い、企業Ｙは金融機関Ｂと取引を行い、企業Ｚは金融機関Ｃと取引を行う。サプライチェーンの企業Ｘ～Ｚと金融機関Ａ～Ｃは、トークンを利用するトークンコミュニティを構成する。
　トークンコミュニティでは、各企業及び金融機関でトークン分散台帳５００を共有することで、トークンの管理が行われる。企業Ｘ～Ｚは、トークンを利用するためにコミュニティ決済要求装置１００－Ｘ～１００－Ｚを有する。なお、以下の説明では、コミュニティ決済要求装置を個々に特定しない場合には、「－」以降を省略した符号１００を用いる。他の構成要素の符号についても同様である。
　金融機関Ａ～Ｃは、トークンの利用と口座の管理のためにコミュニティ決済実行装置２００－Ａ～２００－Ｃを有する。コミュニティ決済実行装置２００は、トークン分散台帳５００の管理と、口座の管理と、電子債権管理システム３００に対する記録の依頼（代理要求）を実施する。また、コミュニティ決済実行装置２００が実施する電子債権管理システム３００への依頼は、トークンコミュニティにおける債権の発生等の記録である。
　トークンコミュニティ内では、コミュニティ決済要求装置１００とコミュニティ決済実行装置２００がトークン分散台帳５００を共有して管理する。そして、金融機関Ａ～Ｃのコミュニティ決済実行装置２００は、トークン分散台帳５００と電子債権管理システム３００の債務（または債権）を連携させる。
　なお、金融機関Ａ～Ｃは、電子債権管理システム３００に参加しており、企業Ｘと企業Ｙは、電子債権管理システム３００の利用者である。企業Ｚは、電子債権管理システム３００を利用していないため、電子債権を利用することはできない。
　＜概要＞
　以下に、トークンコミュニティで行われる決済の概要について説明する。
　まず、サプライチェーンの企業Ｘが、サプライチェーンの代表としてトークンコミュニティの口座を開設する。企業Ｘのコミュニティ決済要求装置１００－Ｘは、金融機関Ａのコミュニティ決済実行装置２００－Ａに対して、口座の開設（トークンの発行）を依頼する（Ｐ１）。コミュニティ決済実行装置２００は、トークンコミュニティの口座を開設して企業Ｘのコミュニティ決済要求装置１００－Ｘにトークン発行権を付与する（Ｐ２）。
　次に、企業Ｘは納品の対価として企業Ｙにトークンで支払を実施する。企業Ｘのコミュニティ決済要求装置１００－Ｘは、トークンによる支払要求を金融機関Ａのコミュニティ決済実行装置２００へ通知する。金融機関Ａのコミュニティ決済実行装置２００－Ａは、トークン分散台帳５００にトークンの発行を記載し、トークンを発行する。コミュニティ決済実行装置２００－Ａは、発行されたトークンを企業Ｙのコミュニティ決済要求装置１００－Ｂへ送信する（Ｐ３）。
　なお、トークンには、企業Ｘからの支払の履歴と、金額と、支払期日と、受取人が含まれる。また、コミュニティ決済要求装置１００－Ｘがトークン分散台帳５００へ書き込む内容は、トークンを発行したトランザクション内容が記録される。なお、金融機関Ａで発行されたトークンは、企業Ｘのコミュニティ決済要求装置１００－Ａから企業Ｙへ送信するようにしてもよい。
　企業Ｘの口座を管理する金融機関Ａでは、コミュニティ決済実行装置２００－Ａがトークン分散台帳５００から企業Ｘのトークンによる支払要求を取得し、電子債権管理システム３００へ企業Ｘから企業Ｙに対する債務（金銭債務）の発生を記録させる（Ｐ４）。電子債権管理システム３００は、コミュニティ決済実行装置２００－Ａの依頼を受け付けて、電子債権管理テーブル３１０にトークンの内容を記録する。
　コミュニティ決済実行装置２００－Ａが、企業Ｘの支払要求によって発行されたトークンの内容を電子債権管理システム３００の電子債権管理テーブル３１０へ記録させることによって、トークンの価値は電子債権管理システム３００に登録された法定通貨の価値で担保されることになる。これにより、本発明の決済システムでは、トークンコミュニティと実社会の決済システムを連携させることで、トークンコミュニティ内の電子的な決済媒体であるトークンと、実社会の法定通貨を連携させて、企業間の決済を実現することができる。
　電子債権管理システム３００は、企業Ｙの債権の発生を金融機関Ｂのコミュニティ決済実行装置２００－Ｂへ通知する。企業Ｙの口座を管理する金融機関Ｂのコミュニティ決済実行装置２００－Ｂは、送金の通知をトークン分散台帳５００へ記録する。
　次に、企業Ｙが、トークンの支払期日以前にトークンの譲渡（割引）を金融機関Ｂへ依頼する。ここで、企業Ｙは、電子債権管理システム３００を利用していない企業Ｚとの取引に対して、トークンでの決済（譲渡）を希望して、金融機関Ｂへ企業Ｚへの譲渡及び割引を申し込む（Ｐ６）。
　金融機関Ｂは、企業Ｙと電子債権管理システム３００の利用契約をしており、コミュニティ決済実行装置２００－Ｂは、割引対象のトークンの記録を、企業Ｙから金融機関Ｂへの譲渡に変更し、電子債権管理システム３００へ書き込みを依頼する（Ｐ７）。
　金融機関Ｂは、企業Ｘの信用に基づきトークンの割引率を算出し、割引分を金融機関Ｂの持分とし、割引いた残り金額（価値）を企業Ｚに支払うトークンとして発行する。すなわち、金融機関Ｂは、企業Ｘから企業Ｙへの支払いが滞っても、金融機関Ｂは企業Ｙから企業Ｚへの支払いを保証し、保証する対価として割引を実施する（Ｐ８）。
　コミュニティ決済実行装置２００－Ｂは、割引後の価値のトークンを企業Ｙのコミュニティ決済要求装置１００－Ｙへ送信する（Ｐ９）。企業Ｙのコミュニティ決済要求装置１００－Ｙは、トークンを企業Ｚのコミュニティ決済要求装置１００－Ｚへ送信して支払を実行する。なお、企業Ｙから企業Ｚへのトークンの支払は、金融機関Ｂのコミュニティ決済実行装置２００－Ｂが企業Ｚのコミュニティ決済要求装置１００－Ｚへ送信してもよい。
　次に、トークンを受け取った企業Ｚは、支払期日以降に金融機関Ｃに対してトークンの換金を依頼する（Ｐ１０）。金融機関Ｃのコミュニティ決済実行装置２００－Ｃは、トークンの発行元である金融機関Ａのコミュニティ決済実行装置２００－Ａに、トークンの換金を要求する（Ｐ１１）。トークンの発行元は、コミュニティ決済実行装置２００がトークン分散台帳５００の履歴を参照することで取得することができる。
　コミュニティ決済実行装置２００－Ａは、トークンの換金の要求を受け付けて、企業Ｘの口座からトークンの割引後の金額を金融機関Ｃの企業Ｚの口座へ送金し、割引額を金融機関Ｃへ送金する（Ｐ１１）。そして、コミュニティ決済実行装置２００－Ａは、トークンの支払が完了したので、企業Ｘ（金融機関Ａ）の債務の抹消を電子債権管理システム３００へ依頼する。
　なお、金融機関Ａ～Ｃ間の決済は、口座単位で行う必要はなく、一定の期日毎にまとめて差額分を決済するネッティングを用いることができる。
　以上のように、本発明の決済システムでは、トークンコミュニティと既存の決済システム（電子債権管理システム３００）をトークン分散台帳５００で連携させることで、電子的な決済媒体の価値を担保して、トークンコミュニティ内で決済を行うことが可能となる。そして、トークンコミュニティ内の企業の一部が既存の決済システムに加入していなくても、安全に決済を行うことができる。
　＜コミュニティ決済要求装置＞
　図３は、コミュニティ決済要求装置１００の一例を示すブロック図である。コミュニティ決済要求装置１００は、メモリ１０１と、演算装置１０２と、入力装置１０３と、出力装置１０４と、通信装置１０５と、ストレージ装置１０６を含む計算機である。
　ストレージ装置１０６には、トークンによる支払を金融機関に要求するトークン支払要求プログラム１１０と、受け付けたトークンの換金を金融機関に要求するトークン換金要求プログラム１２０と、トークンをトークンコミュニティ内で共有するトークン分散台帳５００と、トークン残高管理テーブル６００と、コミュニティ管理テーブル７００が格納される。
　入力装置１０３は、例えば、キーボードやマウスあるいはタッチパネルで構成される。出力装置１０４は、例えば、ディスプレイなどで構成される。通信装置１０５は、ネットワーク１０に接続されて、他の計算機と通信を行う。
　トークン支払要求プログラム１１０と、トークン換金要求プログラム１２０は、メモリ１０１にロードされて演算装置１０２によって実行される。
　演算装置１０２は、各機能部のプログラムに従って処理を実行することによって、所定の機能を提供する機能部として稼働する。例えば、演算装置１０２は、トークン支払要求プログラム１１０に従って処理を実行することでトークン支払要求部として機能する。他のプログラムについても同様である。さらに、演算装置１０２は、各プログラムが実行する複数の処理のそれぞれの機能を提供する機能部としても稼働する。計算機及び計算機システムは、これらの機能部を含む装置及びシステムである。
　トークン分散台帳５００は、トークンコミュニティの参加者で分散して共有される管理台帳である。本実施例１では、企業Ｘ～Ｚのコミュニティ決済要求装置１００と、金融機関Ａ～Ｃのコミュニティ決済実行装置２００にそれぞれ格納され、トークンの情報を共有する。図１３は、トークン分散台帳５００の一例を示す図である。
　トークン分散台帳５００は、金融機関Ａ～Ｃのコミュニティ決済実行装置２００または企業Ｘ～Ｙのコミュニティ決済要求装置１００によって更新される。トークン分散台帳５００は、取引ＩＤ５０１と、取引内容５０２と、支払人５０３と、受取人５０４と、取引額５０５と、対象取引５０６と、記録ＩＤ５０７と、保証人５０８とをひとつのエントリに含む。
　取引ＩＤ５０１は、トークンの処理で発生したトランザクションの識別子（ＩＤ）が格納される。トランザクションの識別子は、コミュニティ決済実行装置２００またはコミュニティ決済要求装置１００が付与した識別子で、トークンコミュニティ内でユニークな値である。
　取引内容５０２には、トークンの処理内容や、企業または金融機関における処理の内容が格納される。支払人５０３には、トークンの送金元の名称が格納される。受取人５０４には、トークンの受取人が格納される。取引額５０５には、トークンの金額（または価値）が格納される。
　対象取引５０６には、当該トランザクションに関連する取引ＩＤが格納される。記録ＩＤ５０７には、当該トランザクションに関連する情報が格納された電子債権管理システム３００の識別子が設定される。記録ＩＤ５０７は、電子債権管理システム３００が設定した値を用い、１以上の識別子を格納することができる。保証人５０８には、当該トランザクションの取引額を担保する人または機関の名称が格納される。
　図１２は、トークン残高管理テーブル６００の一例を示す図である。トークン残高管理テーブル６００は、トークンコミュニティの参加者で分散して共有され、金融機関Ａ～Ｃのコミュニティ決済実行装置２００によって更新される。
　トークン残高管理テーブル６００は、トークン名６０１と、トークン残高６０２と、有効期限６０３と、引換開始日６０４をひとつのエントリに含む。トークン名６０１は、金融機関Ａ～Ｃのコミュニティ決済実行装置２００が決定した名称または識別子が格納される。なお、トークン名６０１は、トークンコミュニティ内でユニークな値である。
　トークン残高６０２には、トークンの価値（金額）が格納される。有効期限６０３には、当該トークンを利用可能な期間の最終日が格納される。引換開始日６０４は、当該トークンを通貨に交換可能な日付が格納される。なお、トークン残高６０２には最新のトークンの残高が格納される。
　図１１は、コミュニティ管理テーブル７００の一例を示す図である。コミュニティ管理テーブル７００は、トークンコミュニティの参加者で分散して共有され、金融機関Ａ～Ｃのコミュニティ決済実行装置２００によって設定される。
　コミュニティ管理テーブル７００は、トークン名７０１と、発行額７０２と、参加者名７０３と、代表者フラグ７０４と、でんさい契約有無７０５をひとつのエントリに含む。
　トークン名７０１には、トークンの名称または識別子が格納される。発行額７０２には、発行可能なトークンの値（金額）が格納される。参加者名７０３には、当該トークンを利用可能なトークンコミュニティの参加者の名称が格納される。
　代表者フラグ７０４には、当該トークンコミュニティの代表者に「Ｙ」が設定される。なお、本実施例１では、トークンの支払人（企業Ｘ）が、代表者となり、代表者が参加者名７０３を決定する例を示すがこれに限定されるものではない。
　でんさい契約有無７０５には、トークンコミュニティの参加者のうち、電子債権管理システム３００の利用契約を締結している参加者には「Ｙ」が設定される。なお、本実施例１では、実社会の決済システムとして電子債権管理システム３００を利用する例を示したが、これに限定されるものではない。例えば、債務または債権を登録可能な決済システムであれば、利用することが可能である。
　また、本実施例１では、トークンコミュニティの代表者は、電子債権管理システム３００の利用契約を有するものとする。
　トークンコミュニティの参加者の追加や変更などの情報がトークン分散台帳５００に随時記録され、最新の状態がコミュニティ管理テーブル７００に反映される。
　＜コミュニティ決済実行装置＞
　図４は、コミュニティ決済実行装置２００の一例を示すブロック図である。コミュニティ決済実行装置２００は、メモリ２０１と、演算装置２０２と、入力装置２０３と、出力装置２０４と、通信装置２０５と、ストレージ装置２０６を含む計算機である。
　ストレージ装置２０６には、トークンを発行するトークン発行プログラム２１０と、トークンの支払要求を処理するトークン支払受付プログラム２２０と、トークンの換金を処理するトークン換金受付プログラム２３０と、トークン分散台帳５００と、トークン残高管理テーブル６００と、コミュニティ管理テーブル７００と、口座管理テーブル８００と、信用スコアテーブル９００が格納される。
　なお、トークン分散台帳５００と、トークン残高管理テーブル６００と、コミュニティ管理テーブル７００は、コミュニティ決済要求装置１００と同様であるので説明を省略する。
　入力装置２０３は、例えば、キーボードやマウスあるいはタッチパネルで構成される。出力装置２０４は、例えば、ディスプレイなどで構成される。通信装置２０５は、ネットワーク１０に接続されて、他の計算機と通信を行う。
　演算装置２０２は、各機能部のプログラムに従って処理を実行することによって、所定の機能を提供する機能部として稼働する。例えば、演算装置２０２は、トークン発行プログラム２１０に従って処理を実行することでトークン発行部として機能する。他のプログラムについても同様である。さらに、演算装置２０２は、各プログラムが実行する複数の処理のそれぞれの機能を提供する機能部としても稼働する。計算機及び計算機システムは、これらの機能部を含む装置及びシステムである。
　図１０は、口座管理テーブル８００一例を示す図である。口座管理テーブル８００は、金融機関Ａ～Ｃのコミュニティ決済実行装置２００によって管理される。口座管理テーブル８００は、口座番号８０１と、利用者名８０２と、残高８０３をひとつのエントリに含む。
　信用スコアテーブル９００は、図示はしないが、トークンコミュニティの参加者のそれぞれについて、信用の度合いを示すスコアが設定される。各金融機関Ａ～Ｃのコミュニティ決済実行装置２００は、信用スコアテーブル９００のスコアを参照して、トークンの割引率等を決定することができる。
　＜電子債権管理システム＞
　電子債権管理システム３００は、前記特許文献１や周知の電子記録債権サービスを提供する計算機システムまたは計算機である。図１４は、電子債権管理システム３００が管理する電子債権管理テーブル３１０の一例を示す図である。
　電子債権管理テーブル３１０は、記録ＩＤ３１１と、債務者３１２と、債権者３１３と、債権額３１４と、削除フラグ３１５をひとつのエントリに含む。記録ＩＤ３１１は、電子債権管理システム３００で付与された識別子でユニークな値で、トークン分散台帳５００の記録ＩＤ５０７に対応する。
　債務者３１２、債権者３１３には、法人名または氏名が格納される。債権額３１４には、金額が格納される。削除フラグ３１５には、抹消されたエントリに「Ｄ」が格納される。
　図示の例では、債権額３１４が「１００」の企業Ｙの債権が、金融機関Ｂで割引されて分割され、債権額３１４が「８０」の企業Ｙの債権と、債権額３１４が「２０」の金融機関Ａの債権に分割された例を示す。
　なお、上記実施例１では、債権の管理を行う既存の決済システムとして電子債権管理システム３００を用いる例を示したが、電子債権管理装置等の単一の計算機であってもよい。
　＜処理＞
　図５は、トークン発行処理の一例を示すフローチャートである。この処理は、金融機関のコミュニティ決済実行装置２００のトークン発行プログラム２１０が、企業のコミュニティ決済要求装置１００からトークン発行要求を受け付けると開始される。
　以下の説明では、コミュニティ決済実行装置２００を処理の主体として説明するが、トークン発行プログラム２１０や演算装置２０２を処理の主体としてもよい。
　コミュニティ決済実行装置２００は、企業のコミュニティ決済要求装置１００からトークン支払要求を受け付ける（Ｓ１）。コミュニティ決済実行装置２００は、口座管理テーブル８００を参照して、トークンの支払を要求した利用者の口座残高を取得し、支払額に対して残高の不足がないことを判定する（Ｓ２）。
　次に、コミュニティ決済実行装置２００は、トークンの名称を決定し、トークンの支払要求に含まれる支払額と参加者等の情報をコミュニティ管理テーブル７００に登録する（Ｓ３）。
　コミュニティ決済実行装置２００は、決定したトークンの名称をコミュニティ管理テーブル７００のトークン名７０１に設定し、発行額７０２を設定し、支払要求の送信元を代表者として、参加者名７０３に登録し、代表者フラグ７０４を「Ｙ」に設定し、電子債権管理システム３００の利用契約の有無に応じてでんさい契約有無７０５を設定する。
　また、コミュニティ決済実行装置２００は、支払要求に設定されたトークンコミュニティの参加者について、参加者名７０３、代表者フラグ７０４＝「Ｎ」及びでんさい契約有無７０５を設定する。
　コミュニティ決済実行装置２００は、当該金融機関が保有するトークンとして、上記のように決定した新たなトークンを、トークン分散台帳５００に登録する（Ｓ４）。本実施例１では、コミュニティ決済実行装置２００が、新たなトークンとして取引ＩＤ５０１が「ＴＸ１００」のエントリを追加し、図１３のトークン分散台帳５００に登録する例を示す。
　コミュニティ決済実行装置２００は、金融機関が発行した新たなトークンを、支払を要求した代表者の所有に移転して、トークンの発行を完了する（Ｓ５）。本実施例１では、コミュニティ決済実行装置２００が、取引ＩＤ５０１＝「ＴＸ２００」で、取引内容５０２が「発行」のエントリを追加する。図１３の例では、支払人５０３が「金融機関Ａ」、受取人５０４が「企業Ｘ」の内容で金融機関Ａから企業Ｘへの移転がトークン分散台帳５００に登録される。
　上記処理によって、トークン分散台帳５００には、金融機関によって登録された新たなトークンが、取引ＩＤ５０１の「ＴＸ２００」で企業Ｘの支払用のトークンとして発行される。そして、新たなトークンの発行は、トークン分散台帳５００によってトークンコミュニティの参加者に通知される。
　なお、トークンを発行するための金融機関の口座は、当座預金のような既存の決済用の口座を用いることができ、あるいは、トークン決済用の特別な口座を利用してもよい。また、トークンの発行額は、発行の要求で指定されてもよいし、指定せずに残高全額を発行額としてもよい。
　また、上記では、トークンの支払要求の際に、コミュニティの参加者を指定する例を示すが、これに限定されるものではない。例えば、コミュニティの代表が個別に参加者を登録してもよい。あるいは、代表以外の参加者が参加申請し、代表者が承認してコミュニティ管理テーブル７００に登録してもよい。
　金融機関またはその他の組織が、図示しない取引履歴などを元に、企業Ｘ、企業Ｙ、企業Ｚがサプライチェーンを構成していると判断し、参加者名７０３に企業Ｘ～企業Ｚを登録してもよい。
　図６は、トークン支払要求処理の一例を示すフローチャートである。この処理は、企業のコミュニティ決済要求装置１００のトークン支払要求プログラム１１０が、利用者からトークン支払要求を受け付けると開始される。
　コミュニティ決済要求装置１００は、入力装置１０３等からトークン支払要求を受け付ける（Ｓ１０）。トークン支払要求には、例えば、支払額、受取人、支払期日などが含まれる。コミュニティ決済要求装置１００は、コミュニティ管理テーブル７００を参照して、受取人が電子債権管理システム３００の利用契約を有しているか否かを判定する。受取人が電子債権管理システム３００の利用者であれば、ステップＳ１２へ進み、そうでない場合にはステップＳ１３へ進む。
　ステップＳ１２では、コミュニティ決済要求装置１００は、取引内容５０２を「支払」として、受取人へのトークンの支払をトークン分散台帳５００に登録する。本実施例１では、企業Ｘから企業Ｙへの支払として取引ＩＤ５０１＝「ＴＸ３００」のエントリをコミュニティ決済要求装置１００がトークン分散台帳５００に登録する例を示す。
　一方、ステップＳ１３では、受取人が電子債権管理システム３００を利用していないので、コミュニティ決済要求装置１００は、取引内容５０２を「保証付支払」として、受取人の金融機関Ｂへの支払としてトークン分散台帳５００に登録する。本実施例１では、図２で示したように、電子債権管理システム３００に未加入の企業Ｚへ企業Ｙがトークンで支払う際には、金融機関Ｂを受取人とし、取引ＩＤ５０１＝「ＴＸ４００」としてトークン分散台帳５００に登録する例を示す。
　取引ＩＤ５０１＝「ＴＸ４００」の「保証付支払」のトークンは、支払人５０３が「企業Ｘ」で、受取人５０４が「金融機関Ｂ」で、金融機関Ｂが企業Ｚへの支払を担保する例を示す。
　上記処理によって、トークン分散台帳５００には、支払のトランザクション（ＴＸ３００、またはＴＸ４００）が登録される。金融機関のコミュニティ決済実行装置２００は、トークン分散台帳５００を参照することで、企業Ｘから企業Ｙ（企業Ｚ）への支払要求が新たに発生したことを検出することができる。
　図７は、トークン支払受付処理の一例を示すフローチャートである。この処理は、金融機関のコミュニティ決済実行装置２００のトークン支払受付プログラム２２０が、トークン分散台帳５００に新たな支払要求を検出したときに開始される。
　コミュニティ決済実行装置２００は、トークン分散台帳５００から新たな支払要求のエントリを検出し、支払人５０３と受取人５０４及び取引ＩＤ５０１を読み込む（Ｓ２１）。
　ステップＳ２２では、コミュニティ決済実行装置２００が、口座管理テーブル８００を参照して支払人の口座の有無に基づいて、当該支払が自金融機関（以下、自行とする）行で行う処理であるか否かを判定する。当該支払を自行で行う場合は、ステップＳ２３へ進み、そうでない場合には処理を終了する。
　次に、ステップＳ２３では、コミュニティ決済実行装置２００が、コミュニティ管理テーブル７００を参照して、支払人が代表者であるか否かを判定する。支払人が代表者であればステップＳ２４へ進み、そうでない場合にはステップＳ２６へ進む。
　ステップＳ２４では、コミュニティ決済実行装置２００が、電子債権管理システム３００に対して、支払人に債務が発生した記録（発生記録）を依頼（代理請求）する。
　ステップＳ２５では、コミュニティ決済実行装置２００は、電子債権管理システム３００から代理請求に対する応答を受信し、受信した内容をトークン分散台帳５００へ記録する。コミュニティ決済実行装置２００は、代理請求の応答として、発生記録の識別子を受け付け、当該支払の取引ＩＤ５０１＝「ＴＸ３００」に関連する取引ＩＤ５０１として「ＴＸ３１０」を生成して、トークン分散台帳５００へエントリを追加する。
　そして、コミュニティ決済実行装置２００は、当該エントリの記録ＩＤ５０７に電子債権管理システム３００が付与した識別子「Ｄ１０」を格納し、対象取引５０６に支払のエントリの取引ＩＤ５０１＝「ＴＸ３００」を格納して処理を終了する。
　一方、ステップＳ２２で支払人が代表者でない場合には、ステップＳ２６でコミュニティ決済実行装置２００がコミュニティ管理テーブル７００を参照し、受取人５０４（支払要求を発行したコミュニティ決済要求装置１００の運用者）が電子債権管理システム３００の利用契約を有するか否かを判定する。利用契約がある場合にはステップＳ２７へ進み、ない場合にはステップＳ２９へ進む。
　ステップＳ２７では、コミュニティ決済実行装置２００が、電子債権管理システム３００に対して、代表者以外の支払人に債務が発生した記録（譲渡記録）を依頼（代理請求）する。この場合の処理は、代表者（または他の参加者）から当該受取人へ債権を譲渡することになる。
　ステップＳ２８では、コミュニティ決済実行装置２００は、電子債権管理システム３００から代理請求に対する応答を受信し、受信した内容をトークン分散台帳５００へ記録する。コミュニティ決済実行装置２００は、代理請求の応答として、譲渡記録の識別子を受け付け、当該支払の取引ＩＤ５０１に関連する新たな取引ＩＤ５０１を生成してトークン分散台帳５００へエントリを追加する。
　そして、コミュニティ決済実行装置２００は、当該エントリの記録ＩＤ５０７に電子債権管理システム３００が付与した識別子を格納し、対象取引５０６に支払のトランザクションの取引ＩＤ５０１を格納して処理を終了する。
　上記ステップＳ２６の判定で、受取人に電子債権管理システム３００の利用契約がない場合のステップＳ２９では、コミュニティ決済実行装置２００は、当該支払人へ保証を付与可能か否かを判定する。この処理は、支払期日や金融機関の取引履歴や与信の履歴と所定の基準に基づいて、コミュニティ決済実行装置２００が保証を付与するか否かを決定する。保証を付与する場合にはステップＳ３０へ進み、付与しない場合にはステップＳ３７へ進む。
　ステップＳ３０では、トークンの割引を行うために、コミュニティ決済実行装置２００が、信用スコアテーブル９００を参照して、当該支払人の信用のスコアから支払額に対する割引額を算出する。次に、ステップＳ３１では、コミュニティ決済実行装置２００が、当該トークンを金融機関の持分と、受取人の持分に分割し、分割の内容を登録するように電子債権管理システム３００へ依頼（代理請求）する。
　なお、トークンの価値は、割引額を金融機関の持分とし、支払額から割引額を差し引いた残余を受取人の持分とする。
　なお、トークンの分割は、受取人が当該トークンの支払期日前に換金する場合には、金融機関と受取人の２者で当該トークンが分割され、受取人が当該トークンの支払期日前に他の受取人へ送金する場合には、金融機関と受取人で分割されてから、受取人から他の受取人への譲渡が行われる。
　ステップＳ３２では、コミュニティ決済実行装置２００が、電子債権管理システム３００から代理請求に対する応答を受信し、受信した内容をトークン分散台帳５００へ記録する。コミュニティ決済実行装置２００は、代理請求の応答として、分割記録の識別子「Ｄ２０、Ｄ２１、Ｄ２２」を受け付け、当該保証支払の取引ＩＤ５０１＝「ＴＸ４００」に関連する取引ＩＤ５０１として「ＴＸ４１０」を生成し、トークン分散台帳５００へエントリを追加する。
　そして、コミュニティ決済実行装置２００は、当該エントリの記録ＩＤ５０７に電子債権管理システム３００が付与した識別子「Ｄ２０、Ｄ２１、Ｄ２２」を格納し、対象取引５０６に保証支払のトランザクション（取引ＩＤ５０１）「ＴＸ４００」を格納する。
　ステップＳ３３では、上記分割したトークンに受取人への譲渡が含まれるか否かを判定する。受取人が存在する場合には譲渡であるのでステップＳ３４へ進み、そうでない場合にはステップＳ３７へ進む。
　ステップＳ３４では、トークンの譲渡を行うために、コミュニティ決済実行装置２００が、受取人宛の譲渡の内容を登録（譲渡記録）するように電子債権管理システム３００へ依頼（代理請求）する。
　ステップＳ３５では、コミュニティ決済実行装置２００が、電子債権管理システム３００から代理請求に対する応答を受信し、受信した内容をトークン分散台帳５００へ記録する。コミュニティ決済実行装置２００は、代理請求の応答として、譲渡記録の識別子「Ｄ２２」を受け付け、当該支払の取引ＩＤ５０１＝「ＴＸ４００」に関連する取引ＩＤ５０１として「ＴＸ４２０」を生成し、トークン分散台帳５００へエントリを追加する。
　そして、コミュニティ決済実行装置２００は、当該エントリの記録ＩＤ５０７に電子債権管理システム３００が付与した識別子「Ｄ２２」を格納し、対象取引５０６に保証支払のトランザクション（取引ＩＤ５０１）「ＴＸ４００」を格納する。
　次に、ステップＳ３６では、コミュニティ決済実行装置２００が、支払人（金融機関Ｂ）から受取人（企業Ｚ）への保証付きの支払をトークン分散台帳５００へ記録する。コミュニティ決済実行装置２００は、当該保証付き支払の取引ＩＤ５０１として「ＴＸ５００」を生成し、トークン分散台帳５００へエントリを追加する。そして、コミュニティ決済実行装置２００は、当該エントリの保証人５０８に「金融機関Ｂ」を格納し、支払人５０３に「金融機関Ｂ」、受取人５０４に「企業Ｚ」を格納する。
　一方、ステップＳ３３の判定で、譲渡ではない場合のステップＳ３７では、支払人の債務が抹消されるので、トークンの抹消を行うために、コミュニティ決済実行装置２００が、取引ＩＤ５０１が「ＴＸ４００」の保証付き支払を抹消するように電子債権管理システム３００へ依頼（代理請求）する。
　ステップＳ３８では、コミュニティ決済実行装置２００が、電子債権管理システム３００から代理請求に対する応答を受信し、受信した内容をトークン分散台帳５００へ記録する。コミュニティ決済実行装置２００は、代理請求の応答として、抹消記録の識別子「Ｄ２１」を受け付け、当該支払の取引ＩＤ５０１＝「ＴＸ４００」に関連する取引ＩＤ５０１として「ＴＸ４３０」を生成し、トークン分散台帳５００へエントリを追加する。
　そして、コミュニティ決済実行装置２００は、当該エントリの記録ＩＤ５０７に電子債権管理システム３００が付与した識別子「Ｄ２１」を格納し、対象取引５０６に保証支払のトランザクション（取引ＩＤ５０１）「ＴＸ４００」を格納する。
　上記処理によって、トークンの支払、譲渡、分割、抹消がトークン分散台帳５００に記録され、債務（債権）の移動や変更が発生する度に電子債権管理システム３００に変更の内容が登録され、決済システムはトークンの価値を債務者及び債権者に保証することができる。
　また、上記の処理によって、支払者がトークンコミュニティの代表者ではなく、かつ、受取人５０４が電子債権管理システム３００の利用契約を有していない場合には、支払を実行する金融機関で割引を実行し、支払人に代わって当該金融機関が債務を担保することができる。これにより、電子債権管理システム３００の利用契約がない受取人に対してもトークンの価値を法定通貨と同様に保証することが可能となるのである。
　図８は、トークン換金要求処理の一例を示すフローチャートである。この処理は、企業のコミュニティ決済要求装置１００のトークン換金要求プログラム１２０が、利用者からトークン換金要求を受け付けると開始される。
　コミュニティ決済要求装置１００は、入力装置１０３からトークンの換金要求を受け付ける（Ｓ４１）。コミュニティ決済要求装置１００は、換金要求から取引ＩＤ５０１（またはトークン名）と金額と利用者名（参加者名７０３）を取得する。
　コミュニティ決済要求装置１００は、コミュニティ管理テーブル７００を参照して、換金要求の利用者が電子債権管理システム３００の利用契約の有無を判定する（Ｓ４２）。コミュニティ決済要求装置１００は、利用契約がある場合にはステップＳ４３へ進み、利用契約がない場合にはステップＳ４４へ進む。
　ステップＳ４３では、コミュニティ決済要求装置１００が、取引内容５０２を「換金」としたトークンの受け渡しをトークン分散台帳５００に追加する。一方、ステップＳ４３では、コミュニティ決済要求装置１００が、取引内容５０２を「保証付換金」としたトークンの受け渡しをトークン分散台帳５００に追加する。「保証付換金」の場合、コミュニティ決済要求装置１００は、トークン分散台帳５００の保証人５０８に金融機関の名称（または識別子）を格納する。
　図１３では、取引ＩＤ５０１＝「ＴＸ６００」に受取人５０４が「金融機関Ｃ」の保証付換金が登録され、保証人５０８が「金融機関Ｂ」であることを示している。
　図９は、トークン換金受付処理の一例を示すフローチャートである。
　この処理は、金融機関のコミュニティ決済実行装置２００のトークン換金受付プログラム２３０が、トークン分散台帳５００に新たな換金要求を検出したときに開始される。
　コミュニティ決済実行装置２００は、トークン分散台帳５００から新たな換金のエントリを検出し、換金対象のトークンの支払人５０３と受取人５０４及び取引ＩＤ５０１（またはトークン名）を読み込む（Ｓ５１）。
　そして、コミュニティ決済実行装置２００は、口座管理テーブル８００を参照して受取人５０４が自行の口座を保有しているか否かを判定する（Ｓ５２）。受取人５０４が自行の口座を保有している場合にはステップＳ５３へ進み、そうでない場合には処理を終了する。
　ステップＳ５３では、コミュニティ決済実行装置２００が、コミュニティ管理テーブル７００を参照して受取人５０４が電子債権管理システム３００の利用契約を有するか否かを判定する。受取人５０４が電子債権管理システム３００の利用契約を有する場合にはステップＳ５４へ進み、そうでない場合にはステップＳ５９へ進む。
　ステップＳ５４では、コミュニティ決済要求装置１００が、トークン分散台帳５００を参照して、換金対象のトークンの記録ＩＤ５０７に基づいて、当該トークンを発行した金融機関を特定し、当該金融機関へトークンの換金を申し込む。
　換金の申し込みは、コミュニティ決済実行装置２００が、トークン分散台帳５００へ新たな換金（交換）要求を追加することで、発行元の金融機関に通知する。例えば、図１３の取引ＩＤ５０１が「ＴＸ８００」では、取引内容５０２が「交換」で、支払人５０３が「金融機関Ｂ」で、受取人５０４が「金融機関Ａ」のトランザクションが追加される。
　そして、ステップＳ５５では、コミュニティ決済実行装置２００が、電子債権管理システム３００に対して、換金要求を受け付けた金融機関で債務が抹消した記録（抹消記録）の追加を依頼（代理請求）する。
　ステップＳ５６では、コミュニティ決済実行装置２００は、電子債権管理システム３００から代理請求に対する応答を受信し、受信した内容をトークン分散台帳５００へ記録する。
　コミュニティ決済実行装置２００は、代理請求の応答として、抹消記録の識別子「Ｄ２２」を受け付け、当該支払の取引ＩＤ５０１＝「ＴＸ８００」に関連する取引ＩＤ５０１として「ＴＸ８１０」を生成して、トークン分散台帳５００へエントリを追加する。
　そして、コミュニティ決済実行装置２００は、当該エントリの記録ＩＤ５０７に電子債権管理システム３００が付与した識別子「Ｄ２２」を格納し、対象取引５０６に支払のトランザクション（取引ＩＤ５０１）「ＴＸ８００」を格納する。
　次に、コミュニティ決済実行装置２００は、トークンを発行した金融機関からの入金を検知すると（Ｓ５７）、換金要求を申し込んだ利用者の口座へ入金し、処理を終了する（Ｓ５８）。
　上記ステップＳ５３の判定で、換金要求の申込者が電子債権管理システム３００の利用契約を有していない場合、ステップＳ５９へ進んで、コミュニティ決済実行装置２００が、トークンの発行元金融機関に対して保証付きの換金を申し込む。トークンに対する債務の保証は、当該換金要求を受け付けたコミュニティ決済実行装置２００を運用する金融機関が保証人となる。なお、換金の申し込みは、上述したように、コミュニティ決済実行装置２００が、トークン分散台帳５００へ新たな換金要求を追加することで、発行元の金融機関に通知する。
　例えば、図１３の取引ＩＤ５０１が「ＴＸ７００」では、取引内容５０２が「交換」で、支払人５０３が「金融機関Ｃ」で、受取人５０４が「金融機関Ａ」のエントリが追加される。このエントリでは、換金要求を受け付けた金融機関Ｂが債務を保証するので、保証人５０８に「金融機関Ｂ」が登録される。その後は、上記と同様に電子債権管理システム３００に抹消登録を依頼し、金融機関Ａからの入金を申込者の口座へ入金する。
　上記処理によって、電子債権管理システム３００の利用契約の有無にかかわらず、トークンを換金して申込者の口座へ入金することが可能となる。
　以上のように、本実施例１の決済システムでは、電子債権管理システム３００に参加しない企業（運用者）が存在するコミュニティでも、電子的な決済媒体（トークン）の価値を保証した上で決済を実現することができる。なお、上記実施例１では、電子的な決済媒体としてトークンを用いる例を示したが、これに限定されるものではなく、電子的な決済媒体として仮想通貨やポイントなどを用いることができる。
　また、本実施例１では、トークンの価値を法定通貨で保証する例を示したが、これに限定されるものではなく、例えば、金などの貴金属でトークンの価値を保証することができる。
　また、本実施例１では、トークン分散台帳５００や、トークン残高管理テーブル６００や、コミュニティ管理テーブル７００をテーブルとした例を示したが、これらの情報はテーブルに限定されるものではなく、スキーマレスのデータとして格納されてもよい。
　また、本実施例１では、トークン分散台帳５００をトークンコミュニティの参加者で共有する例を示したが、情報の閲覧に制限を設けてもよい。例えば、支払や換金の情報は、支払人と受取人の当事者及び金融機関に閲覧を許可し、他の参加者の閲覧を禁止することができる。
　なお、本実施例１では、トークンコミュニティを単一のコミュニティで構成する例を示したが、これに限定されるものではない。例えば、トークン分散台帳５００を共有範囲が異なる複数のサブコミュニティを設定し、取引内容の開示範囲に合わせてサブコミュニティを使い分けることができる。
　また、上記実施例１では、企業間のサプライチェーンに本発明を適用する例を示したが、これに限定されるものではない。資金の移動が必要なコミュニティであれば、本実施例１の決済システムを適用することができる。
　また、上記実施例１では、金融機関にコミュニティ決済実行装置２００を配置する例を示したが、これに限定されるものではない。例えば、トークンコミュニティへ法定通貨を支払い可能で、かつ、トークンに対応する債権の発生から消滅までを電子債権管理システム３００へ依頼可能な団体や組織あるいは決済サービス会社であればよい。
　図１５は、実施例２を示し、トークン分散台帳５００の一例を示す図である。本実施例２では、トークン分散台帳５００にブロックチェーンを採用し、図１３に示したひとつのエントリを、ひとつのトランザクションとして、複数のトランザクションとハッシュ値でブロック５１１、５１２、５１３を構成する例を示す。その他の構成については、前記実施例１と同様である。
　各ブロック５１１～５１３では、ブロック内の複数のトランザクションの内容と直前のブロックのハッシュ値から当該ブロックのハッシュ値が演算されて、トランザクションの内容とハッシュ値が各ブロック５１１～５１３でそれぞれ保持される。
　ブロックチェーンの技術については、周知の技術であり、Ｐ２Ｐネットワークと、コンセンサスアルゴリズムと、スマートコントラクトと、偽造防止及び暗号化技術を組み合わせた分散型の台帳管理システムである。
　本実施例２では、ブロックチェーンの特性のうち、非中央集権性と、透明性と、耐改竄性と、耐障害性と、自動実行（自動取引）を利用する例を示す。
　まず、非中央集権性は、特定の参加者がデータの管理を独占することを禁止して、ブロックチェーンに参加するそれぞれの参加者がデータの管理を可能にすることを示す。
　次に、透明性は、各参加者が生成した情報を、全ての参加者に公開し、全ての参加者で共有することを示す。トークンコミュニティに参加する参加者は、全ての情報を閲覧することができ、記録された情報の一貫性が保証されている。
　耐改竄性は、各参加者でトランザクションを生成し、各トランザクションを電子署名とハッシュ値に基づき鎖状に繋ぐことで、データの改竄を抑止する。また、各参加者が生成した情報を公開することにより、データの改竄に対する意欲を抑制することができる。
　耐障害性は、各参加者がデータまたはデータの複製をブロックチェーンに参加する参加者で保持することで、一部の参加者に障害が発生しても、データが毀損や消失を防止することである。
　自動実行（自動取引）については、複数の必要条件に関する判定結果が集約された後に取引や情報の発行を実行することを示す。あるいは、発行された情報についての合意を、効率的に行うことを示す。
　なお、上記実施例２では、トランザクションの内容と、直前のブロックのハッシュ値から当該ブロックのハッシュ値を算出する例を示したが、これに限定されるものではない。
　例えば、各ブロック内にはトランザクションの内容に代わって、トランザクションの内容のハッシュ値とトランザクションの識別子（取引ＩＤ５０１）を格納するようにしてもよい。この場合、直前のブロックのハッシュ値と、トランザクションの内容のハッシュ値とトランザクションの識別子から当該ブロックのハッシュ値を算出すればよい。
　そして、トランザクションの内容は、各参加者で保持すればよい。または、各参加者のトランザクションの内容を格納する装置を設けてもよい。この場合では、各トランザクションの内容を非公開とすることができ、各参加者間での取引の内容は限定された参加者に提供することができる。
　図１６は、実施例３を示し、コミュニティ決済要求装置１００及びコミュニティ決済実行装置２００を、トークン分散台帳５００を管理するノードとして扱う例を示す。
　企業Ｘノード１０００Ｘは、実施例１のコミュニティ決済要求装置１００－Ｘ（図２参照）に相当し、企業Ｙノード１０００Ｙは、実施例１のコミュニティ決済要求装置１００－Ｙに相当する。金融機関Ａノード２０００－Ａは、実施例１のコミュニティ決済実行装置２００－Ａ（図２参照）に相当し、金融機関Ｂノード２０００－Ｂは、実施例１のコミュニティ決済実行装置２００－Ｂ（図２参照）に相当する。
　各ノードの構成は同一であるので、以下では、企業Ｘノード１０００Ｘについて説明し、他のノードの説明を省略する。図１７は、企業Ｘノード１０００Ｘの一例を示すブロック図である。
　企業Ｘノード１０００－Ｘは、トークン分散台帳５００の複製を保持し、当該トークン分散台帳５００から各トークンの最新の残高を算出してトークン残高管理テーブル６００に格納する。そして、トークン分散台帳５００は、前記実施例２で示したブロックチェーンで構成される。なお、トークン分散台帳５００のマスタは、金融機関Ａのトークン分散台帳５００とし、他のノードは複製を保持する。
　上記の構成により、耐障害性と耐改竄性を備えた決済システムを提供することができる。
　＜まとめ＞
　以上のように、上記実施例１～３の決済システムは、以下の構成とすることができる。
　（１）プロセッサ（演算装置１０２）とメモリ（１０１）を有する決済要求装置（コミュニティ決済要求装置１００）と、プロセッサ（演算装置２０２）とメモリ（２０１）を有する決済実行装置（コミュニティ決済実行装置２００）と、電子的な債権または債務を管理する電子債権管理装置（電子債権管理システム３００）と、を有する決済システムであって、前記決済要求装置（１００）は、電子的な決済媒体（トークン）による支払要求を発行し、前記決済実行装置（２００）は、前記決済媒体（トークン）による支払要求を受け付けて、当該支払要求による債務の発生を電子債権管理装置（３００）へ記録させ、前記決済媒体を受取人（５０４）へ送信する。
　上記構成により、電子債権管理システム３００に参加しない企業（運用者）が存在するコミュニティでも、コミュニティ決済実行装置２００（決済実行装置）がトークン（電子的な決済媒体）の価値を電子債権管理システム３００で保証した上で決済を実現することができる。
　（２）上記（１）に記載の決済システムであって、前記決済実行装置（２００）は、前記決済媒体（トークン）に対応する価値の債務を前記電子債権管理装置（３００）へ記録させることで、前記決済媒体の価値を保証する。
　上記構成により、コミュニティ決済実行装置２００（決済実行装置）は、発生したトークン（決済媒体）の債務を電子債権管理システム３００へ連携させることで、トークン（決済媒体）を法定通貨に対応付けて価値を保証することができる。
　（３）上記（１）に記載の決済システムであって、前記決済実行装置（２００）は、前記受取人が前記電子債権管理装置（３００）を利用できない場合には、当該決済実行装置（２００）の運用者（金融機関）の保証を付与して前記受取人へ前記決済媒体（トークン）を送信する。
　上記構成により、トークンの受取人５０４が電子債権管理システム３００を利用できない場合でも、コミュニティ決済実行装置２００を運用する金融機関（運用者）の保証を付与することでトークンの流通が可能となる。
　（４）上記（３）に記載の決済システムであって、前記決済実行装置（２００）は、前記受取人が前記電子債権管理装置（３００）を利用できない場合には、当該決済実行装置（２００）で割引を行って、当該割引の残余を前記受取人への決済媒体（トークン）の価値とする。
　上記構成により、トークンの受取人５０４が電子債権管理システム３００を利用できない場合には、支払要求を受け付けたコミュニティ決済実行装置２００（決済実行装置）の金融機関（運用者）が割引を行い、支払額から割引額を差し引いた残余を受取人５０４へのトークンとすることで、金融機関はリスクの対価を受け取ることができる。
　（５）上記（１）に記載の決済システムであって、前記決済要求装置（１００）は、前記決済媒体（トークン）の換金要求を発行し、前記決済実行装置（２００）は、前記換金要求を受け付けて、前記換金要求を申し込んだ決済要求装置（１００）の運用者が前記電子債権管理装置（３００）を利用可能か否かを判定し、利用できない場合には、前記換金要求を受け付けた決済実行装置（２００）の運用者を保証人として、前記決済媒体（トークン）の発行元へ通知する。
　上記構成により、受取人５０４や支払人５０３の電子債権管理システム３００の利用契約の有無にかかわらず、トークンを換金して申込者の口座へ入金することが可能となる。
　（６）上記（１）に記載の決済システムであって、前記決済要求装置（１００）と決済実行装置（２００）は、前記決済媒体（トークン）の授受を記録する分散台帳（トークン分散台帳５００）を共有し、前記決済要求装置（１００）は、前記支払要求を前記分散台帳（５００）へ書き込むことで、前記支払要求を前記決済実行装置（２００）へ通知する。
　上記構成により、トークン分散台帳５００を介してトークン（決済媒体）の流通を電子債権管理システム３００へ反映させて、債務の発生、譲渡、分割、抹消を管理することが可能となる。
　なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に記載したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加、削除、又は置換のいずれもが、単独で、又は組み合わせても適用可能である。
　また、上記の各構成、機能、処理部、及び処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、及び機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ　Ｓｔａｔｅ　Ｄｒｉｖｅ）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。
　また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

Claims (12)

  1. 　プロセッサとメモリを有する決済要求装置と、
    　プロセッサとメモリを有する決済実行装置と、
    　電子的な債権または債務を管理する電子債権管理装置と、を有する決済システムであって、
    　前記決済要求装置は、
    　電子的な決済媒体による支払要求を発行し、
    　前記決済実行装置は、
    　前記決済媒体による支払要求を受け付けて、当該支払要求による債務の発生を電子債権管理装置へ記録させ、前記決済媒体を受取人へ送信することを特徴とする決済システム。
  2. 　請求項１に記載の決済システムであって、
    　前記決済実行装置は、
    　前記決済媒体に対応する価値の債務を前記電子債権管理装置へ記録させることで、前記決済媒体の価値を保証することを特徴とする決済システム。
  3. 　請求項１に記載の決済システムであって、
    　前記決済実行装置は、
    　前記受取人が前記電子債権管理装置を利用できない場合には、当該決済実行装置の運用者の保証を付与して前記受取人へ前記決済媒体を送信することを特徴とする決済システム。
  4. 　請求項３に記載の決済システムであって、
    　前記決済実行装置は、
    　前記受取人が前記電子債権管理装置を利用できない場合には、当該決済実行装置で割引を行って、当該割引の残余を前記受取人への決済媒体の価値とすることを特徴とする決済システム。
  5. 　請求項１に記載の決済システムであって、
    　前記決済要求装置は、
    　前記決済媒体の換金要求を発行し、
    　前記決済実行装置は、
    　前記換金要求を受け付けて、前記換金要求を申し込んだ決済要求装置の運用者が前記電子債権管理装置を利用可能か否かを判定し、利用できない場合には、前記換金要求を受け付けた決済実行装置の運用者を保証人として、前記決済媒体の発行元へ通知することを特徴とする決済システム。
  6. 　請求項１に記載の決済システムであって、
    　前記決済要求装置と決済実行装置は、前記決済媒体の授受を記録する分散台帳を共有し、前記決済要求装置は、前記支払要求を前記分散台帳へ書き込むことで、前記支払要求を前記決済実行装置へ通知することを特徴とする決済システム。
  7. 　プロセッサとメモリを有する決済要求装置と、プロセッサとメモリを有する決済実行装置と、電子的な債権または債務を管理する電子債権管理装置で、決済を実行する決済方法であって、
    　前記決済要求装置が、電子的な決済媒体による支払要求を発行する支払要求発行ステップと、
    　前記決済実行装置が、前記決済媒体による支払要求を受け付けて、当該支払要求による債務の発生を電子債権管理装置へ記録する債務記録ステップと、
    　前記決済実行装置が、前記決済媒体を前記支払要求に含まれる受取人へ送信する送信ステップと、
    を含むことを特徴とする決済方法。
  8. 　請求項７に記載の決済方法であって、
    　前記債務記録ステップでは、
    　前記決済媒体に対応する価値の債務を前記電子債権管理装置へ記録させることで、前記決済媒体の価値を保証することを特徴とする決済方法。
  9. 　請求項７に記載の決済方法であって、
    　前記送信ステップでは、
    　前記受取人が前記電子債権管理装置を利用できない場合には、当該決済実行装置の運用者の保証を付与して前記受取人へ前記決済媒体を送信することを特徴とする決済方法。
  10. 　請求項９に記載の決済方法であって、
    　前記送信ステップでは、
    　当該決済実行装置で割引を行って、当該割引の残余を前記受取人への決済媒体の価値とすることを特徴とする決済方法。
  11. 　請求項７に記載の決済方法であって、
    　前記決済要求装置が、前記決済媒体の換金要求を発行する換金要求発行ステップと、
    　前記決済実行装置が、前記換金要求を受け付けて、前記換金要求を申し込んだ決済要求装置の運用者が前記電子債権管理装置を利用可能か否かを判定し、利用できない場合には、前記換金要求を受け付けた決済実行装置の運用者を保証人として、前記決済媒体の発行元へ通知する換金要求受付ステップと、
    をさらに含むことを特徴とする決済方法。
  12. 　請求項７に記載の決済方法であって、
    　前記決済要求装置と決済実行装置は、前記決済媒体の授受を記録する分散台帳を共有し、
    　前記支払要求発行ステップでは、
    　前記決済要求装置が、前記支払要求を前記分散台帳へ書き込むことで、前記支払要求を前記決済実行装置へ通知することを特徴とする決済方法。
PCT/JP2020/007098 2019-03-05 2020-02-21 決済システム及び決済方法 WO2020179505A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
SG11202107512WA SG11202107512WA (en) 2019-03-05 2020-02-21 Settlement system and settlement method
US17/422,949 US20220148079A1 (en) 2019-03-05 2020-02-21 Settlement system and settlement method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2019039676A JP7093737B2 (ja) 2019-03-05 2019-03-05 決済システム及び決済方法
JP2019-039676 2019-03-05

Publications (1)

Publication Number Publication Date
WO2020179505A1 true WO2020179505A1 (ja) 2020-09-10

Family

ID=72337936

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2020/007098 WO2020179505A1 (ja) 2019-03-05 2020-02-21 決済システム及び決済方法

Country Status (4)

Country Link
US (1) US20220148079A1 (ja)
JP (1) JP7093737B2 (ja)
SG (1) SG11202107512WA (ja)
WO (1) WO2020179505A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7428622B2 (ja) * 2020-09-25 2024-02-06 株式会社日立製作所 トークン管理方法、エンドユーザ管理装置、およびトークン処理装置
JP7179254B1 (ja) 2021-11-17 2022-11-29 デジタル証券準備株式会社 情報処理装置及びプログラム

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003016368A (ja) * 2001-06-29 2003-01-17 Sumitomo Forestry Co Ltd 電子決済処理システム
JP2015204063A (ja) * 2014-04-16 2015-11-16 株式会社滋賀銀行 ファクタリングシステムおよびファクタリング方法
JP2018190156A (ja) * 2017-05-02 2018-11-29 株式会社 みずほ銀行 支払支援システム及び支払支援方法
JP2019095837A (ja) * 2017-11-17 2019-06-20 株式会社三井住友銀行 電子記録債権の割引料補充システム、方法およびプログラム
JP2019101657A (ja) * 2017-11-30 2019-06-24 株式会社エヌ・ティ・ティ・データ 電子記録債権処理装置、電子記録債権処理方法およびプログラム

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110276497A1 (en) * 2010-05-04 2011-11-10 William Patton System and method for debt settlement
US8738516B1 (en) * 2011-10-13 2014-05-27 Consumerinfo.Com, Inc. Debt services candidate locator
US20160125486A1 (en) * 2012-09-12 2016-05-05 Hitachi, Ltd. Settlement operations support system and settlement operations support method
JP5931836B2 (ja) * 2013-11-06 2016-06-08 株式会社三井住友銀行 金融サービスに関する電子記録債権の情報を管理するシステムおよび方法
JP5875636B2 (ja) * 2014-06-13 2016-03-02 株式会社三井住友銀行 電子記録債権の保証記録自動化システム、方法およびプログラム
JP6568547B2 (ja) * 2016-09-29 2019-08-28 株式会社三菱Ｕｆｊ銀行 情報処理装置、情報処理方法、及びプログラム
CN106952094B (zh) 2017-03-10 2018-09-04 腾讯科技（深圳）有限公司 电子票据管理方法及装置
US11410174B2 (en) * 2018-08-07 2022-08-09 International Business Machines Corporation Custom blockchain for IoT devices

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003016368A (ja) * 2001-06-29 2003-01-17 Sumitomo Forestry Co Ltd 電子決済処理システム
JP2015204063A (ja) * 2014-04-16 2015-11-16 株式会社滋賀銀行 ファクタリングシステムおよびファクタリング方法
JP2018190156A (ja) * 2017-05-02 2018-11-29 株式会社 みずほ銀行 支払支援システム及び支払支援方法
JP2019095837A (ja) * 2017-11-17 2019-06-20 株式会社三井住友銀行 電子記録債権の割引料補充システム、方法およびプログラム
JP2019101657A (ja) * 2017-11-30 2019-06-24 株式会社エヌ・ティ・ティ・データ 電子記録債権処理装置、電子記録債権処理方法およびプログラム

Also Published As

Publication number Publication date
US20220148079A1 (en) 2022-05-12
JP2020144526A (ja) 2020-09-10
JP7093737B2 (ja) 2022-06-30
SG11202107512WA (en) 2021-08-30

Similar Documents

Publication Publication Date Title
US10657595B2 (en) Method of tokenization of asset-backed digital assets
US20200302433A1 (en) Distributed ledger settlement transactions
JP2022547130A (ja) ブロックチェーンベースの記録プロセスを提供するシステムおよび方法
US8249987B2 (en) Methods and apparatus for funding transactions using debit cards issued by one institution and funds from accounts at other institutions
JP2021532523A (ja) デジタル通貨を使用して取引を円滑にするためのシステムおよび方法
AU2017212581A1 (en) Method, apparatus, and computer-readable medium for dividend yielding currency based on elastic securitization
KR20000005489A (ko) 인사이드 머니
JP7276495B2 (ja) 制御方法、制御プログラム、情報処理装置および制御システム
US11501368B2 (en) Computing systems for managing and administering dynamic letters of credit
KR101303300B1 (ko) 담보거래 서비스 방법
WO2020179505A1 (ja) 決済システム及び決済方法
EP4116908A1 (en) Method and apparatus for facilitating financial transactions backed by crypto assets
JP4461618B2 (ja) 決済装置及び方法
KR20210060982A (ko) 디폴트 저항성이 구비된 블록 체인을 이용한 가상화폐 유동성 대여 방법 및 그 시스템
US11475517B2 (en) Allocating dynamic documentary conditions for letters of credit amongst beneficiaries
KR20210021922A (ko) 매출채권보험의 관리 시스템 및 방법
KR20210061001A (ko) 블록 체인 기반 대출 금융 서비스 제공 장치
KR20210061053A (ko) 가상화폐 유동성 대여를 위한 정보처리 프로그램
JP3621911B2 (ja) 電子手形保証人システムおよびその電子手形保証方法
JP2024501883A (ja) デジタル通貨を使用して取引を円滑にするためのシステムおよび方法
JP2023043345A (ja) 銀行システム、銀行システムによって実行される電子記録債権を流動化する方法およびプログラム
KR20210060994A (ko) 디폴트 저항성이 구비된 블록 체인을 이용한 가상화폐 유동성 대여 시스템
KR20210061007A (ko) 디폴트 저항성이 구비된 블록 체인을 이용한 가상화폐 유동성 대여 시스템
CN111539814A (zh) 一种能实时交易的数字代币系统
KR20210061014A (ko) 블록 체인을 이용한 가상화폐 유동성 대여 장치

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: 20766372

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: 20766372

Country of ref document: EP

Kind code of ref document: A1