Payment systems and methods using VP-enhanced transaction statements and digital currency settlement infrastructure.

Abstract

The present invention provides a settlement system and method for issuing qualified invoices and qualified receipts, and for verifying the validity and effectiveness of payment and transaction information. [Solution] The first payment provider on the issuer side issues the holder's credentials as a VC to the user terminal. The digital ID wallet provider issues an encrypted VP generated from the VC. The payment terminal on the merchant side requests verification of the encrypted VP from the second payment provider on the verifier side. The second payment provider provides the payment terminal with the verification result of the encrypted VP. Based on the verification result of the encrypted VP, the payment terminal requests the second payment provider to process the payment. The second payment provider issues a payment request to execute the payment process. The digital currency wallet provider on the issuer side generates a payment transaction based on the payment request and sends the payment transaction to the digital currency payment infrastructure.

Description

Technical Field

[0001] The present invention relates to a payment service that utilizes a transaction detail (including information such as an invoice / receipt) as a verifiable presentation (VP) generated from a verifiable credential (VC). More specifically, the present invention relates to a payment system and method for storing a VP-converted transaction detail on a digital currency payment infrastructure in a cashless payment scenario among a holder, an issuer, and a verifier related to VC.

Background Art

[0002] With the development of the settlement area of various commercial transactions, the settlement methods have also rapidly changed and diversified. Regarding digital currency, which is a currency used for electronic settlement instead of paper money or coins, central bank digital currency (CBDC), tokenized deposits (TD), stablecoins (SC), etc., which utilize distributed ledger technology (DLT) represented by blockchain (BC), are being put into practical use. On such a payment infrastructure, intangible / tangible real assets or rights such as stocks, bonds, real estate, artworks, precious metals, carbon credits, etc. are represented on the blockchain as tokenized assets (TA).

[0003] In particular, stablecoins, which are fiat-backed digital currencies, are experiencing remarkable growth in issuance volume, expanding the scale and diversity of tokenized assets in circulation. As a result, a foundation is being built for direct circulation via digital currencies, i.e., decentralized finance, and the formation of new investment and currency ecosystems is progressing. In this way, as on-chain settlement and circulation become directly possible in initiatives where assets, content, rights, etc., are tokenized, it is expected that existing financial functions will become more efficient, or new use cases will be created through new financial functions.

[0004] In decentralized finance, the smart contract, a mechanism that automatically executes contracts without the need for intermediaries, offers advantages in terms of convenience and cost. However, it also increases the need to confirm predetermined conditions that must be met for smooth contract negotiation or verification. For example, Patent Document 1 discloses a settlement system for executing smart contracts on stablecoins, which are highly liquid crypto assets. [Prior art documents] [Patent Documents]

[0005] [Patent Document 1] Patent No. 7209984 [Overview of the Initiative] [Problems that the invention aims to solve]

[0006] However, several problems have been pointed out with payment systems like the one disclosed in Patent Document 1, highlighting the need for the following countermeasures. For example, in stablecoin payments, only "when, who, to whom, and how much was paid" is registered on the blockchain. From the perspective of regulatory authorities, in terms of anti-money laundering and countering the financing of terrorists (AML / CFT), it is desirable to be able to match and verify payment information with the transaction information associated with it.

[0007] Furthermore, from the perspective of businesses, it is desirable to prepare a platform that enables the issuance of qualified invoices or receipts under the existing invoice system, in addition to stablecoin payments. Moreover, from the perspective of users, it is desirable to implement household budget management that enables integration with tools such as household budgeting applications, even for stablecoin payments.

[0008] The present invention was made to solve these problems and aims to provide a payment system and method using VP-enhanced transaction details and a digital currency payment platform that enables on-chain DVP (Delivery Versus Payment) settlement, where invoices and receipts under the invoice system can be issued on a digital currency payment platform, the validity and effectiveness of payment information and transaction information can be verified, and settlement results can be linked to household budget management. [Means for solving the problem]

[0009] To solve the above problems, in one aspect of the present invention, a payment system is provided that enables settlement of a sales contract between a holder and a merchant based on the verification results by the verifier of the credentials provided by the holder, at a merchant that has a merchant agreement with the verifier, as a settlement scenario spanning between an issuer having a business contract with a payment brand, a holder who is a member of the payment brand, and a verifier having a transaction contract with the payment brand, and comprises the following components. That is, (1) A first payment provider installed on the issuer's side and configured to determine the issuance of credentials to provide them to the user terminal as verifiable credentials (VC) based on a request from the user terminal used by the holder, (2) A digital identity wallet provider configured to manage VCs issued by a first payment provider based on instructions from a user terminal, and to issue encrypted verifiable presentations (VPs) generated from VCs based on instructions from a user terminal, (3) A payment terminal installed at a merchant and configured to request settlement processing for a sales contract based on the verification results of an encrypted VP issued by a digital ID wallet provider. (4) A second payment provider installed on the verifier side, configured to verify the VP provided from the payment terminal and then issue a payment request to execute the payment processing requested by the payment terminal, and (5) A first digital currency wallet provider installed on the issuer's side and configured to generate settlement transactions based on settlement requests issued by a second settlement provider and to send settlement transactions to a digital currency settlement platform.

[0010] Here, a settlement transaction is a transaction configured to allow the transaction record of an encrypted sales contract for VP, along with the transaction information associated with the transaction record, to be registered with the digital currency settlement platform.

[0011] This system further comprises the following components: (6) A second digital currency wallet provider configured as part of an agent application for payment services installed on a user terminal, which verifies the authenticity of a payment transaction based on a signature request issued by a first digital currency wallet provider and approves the holder's user signature based on the verification result for the payment transaction.

[0012] Furthermore, in this system, the digital ID wallet provider is configured as part of the payment service agent application installed on the user terminal and manages VCs using a secure element built into the user terminal, or it is configured as a server installed on the issuer's side and manages VCs using a database on an external server separate from the server.

[0013] Furthermore, in this system, the first payment provider is configured as a group of servers installed on the issuer's side, and the group of servers includes a payment provider, an identity verification provider, and a points member provider, which are configured to issue credit card account VCs, identity verification VCs, and points member VCs for holders to the digital ID wallet provider, respectively. In addition, the first digital currency wallet provider is configured to issue wallet account VCs for holders' digital currency accounts issued from the digital currency payment infrastructure to the digital ID wallet provider.

[0014] Here, the digital ID wallet provider issues an electronic check as an encrypted VP via the user terminal to a second payment provider, and the electronic check includes a wallet account VC, identity verification VC, and points member VC related to the sales contract.

[0015] Furthermore, in this system, the second payment provider issues an electronic invoice to the digital ID wallet provider as an encrypted VP, and the electronic invoice includes the merchant identifier and signature, the settlement amount of the sales contract, the purchase data of the sales contract, the applicable tax rate and sales tax amount for the purchase data, and the invoice business number.

[0016] Furthermore, in this system, the second payment provider issues an electronic receipt as an encrypted VP to the digital ID wallet provider, and the electronic receipt includes the merchant identifier and signature, the settlement amount of the sales contract, the purchase data of the sales contract, the applicable tax rate and sales tax amount for the purchase data, and the qualified invoice business number.

[0017] Furthermore, in this system, the digital currency settlement platform is a settlement platform that maintains accurate financial transaction history based on distributed ledger technology using blockchain. Distributed ledger technology stores transaction history in units called blocks, linking them together as a single chain from the past to the present using cryptographic technology.

[0018] Furthermore, in this system, the digital currency settlement platform is a platform for using digital currencies for settlement, including stablecoins, central bank digital currencies, or tokenized deposits.

[0019] Furthermore, in one aspect of the present invention, in a settlement scenario spanning an issuer having a business contract with a payment brand, a holder who is a member of the payment brand, and a verifier having a transaction contract with the payment brand, a settlement system that handles a sales contract between a holder and a merchant having a merchant agreement with the verifier, based on the verification results by the verifier against the credentials provided by the holder, comprises the following components for executing the settlement process of a sales contract. That is, (1) In a first payment provider installed on the issuer side, a step of determining an issuance for providing, as verifiable credential information (VC), credential information that can be verified based on a request from a user terminal used by a holder to the user terminal; (2) In a digital ID wallet provider that manages the VC issued from the first payment provider based on an instruction from the user terminal, a step of issuing an encrypted verifiable presentation (VP) generated from the VC based on an instruction from the user terminal; (3) In a payment terminal installed at a franchise, a step of requesting verification of the encrypted VP issued from the digital ID wallet provider; (4) In a second payment provider installed on the verifier side, a step of verifying the VP provided from the payment terminal and providing the verification result of the VP to the payment terminal; (5) In the payment terminal, a step of requesting a payment process for a sales contract based on the verification result of the VP provided from the second payment provider; (6) In the second payment provider, a step of issuing a payment request to execute the payment process requested from the payment terminal, and (7) In a first digital currency wallet provider installed on the issuer side, a step of generating a payment transaction based on the payment request issued from the second payment provider and sending the payment transaction to a digital currency payment infrastructure.

[0020] Here, the payment transaction is a transaction configured to be able to register, with respect to the digital currency payment infrastructure, a transaction record of a sales contract regarding the encrypted VP and transaction information accompanying the transaction record.

Effect of the Invention

[0021] According to the present invention, in a digital currency infrastructure, by virtualizing transaction information (bills and receipts) and storing the transaction records of cryptographic assets as transactions and the accompanying transaction information on the same on-chain, it is possible to ensure the transparency of transaction content and improve the convenience of consumers, and provide on-chain DVP (Delivery Versus Payment) settlement to service users such as businesses, users, and regulatory authorities.

Brief Description of the Drawings

[0022] A detailed understanding of the embodiments disclosed in this specification can be obtained from the following description illustrated in connection with the accompanying drawings.

[0023] [Figure 1A] It is a configuration diagram showing the connection form of the settlement system according to an embodiment of the present invention. [Figure 1B] It is a diagram showing the configuration of the basic model related to the settlement system shown in FIG. 1A. [Figure 1C] It is a configuration diagram showing an alternative configuration of the settlement system shown in FIG. 1A. [Figure 2A] It is a configuration diagram showing the internal configuration of the settlement provider of the issuer-side server in the settlement system shown in FIG. 1A. [Figure 2B] It is a table showing a configuration example of credit card account VC data in the settlement provider shown in FIG. 2A. [Figure 3A] It is a configuration diagram showing the internal configuration of the identity verification provider of the issuer-side server in the settlement system shown in FIG. 1A. [Figure 3B] It is a table showing a configuration example of identity verification VC data in the settlement provider shown in FIG. 3A. [Figure 4A] It is a configuration diagram showing the internal configuration of the point membership provider of the issuer-side server in the settlement system shown in FIG. 1A. [Figure 4B] It is a table showing a configuration example of point membership VC data in the point membership provider shown in FIG. 4A. [Figure 5A]Figure 1A is a configuration diagram showing the internal configuration of the digital currency wallet provider on the issuer-side server in the payment system. [Figure 5B] Figure 5A shows an example of the configuration of wallet account VC data in a digital currency wallet provider. [Figure 6A] Figure 1A is a configuration diagram showing the internal configuration of the digital ID wallet provider function of the holder-side terminal in the payment system. [Figure 6B] Figure 6A shows an example of the configuration of wallet account VC data in a digital ID wallet provider. [Figure 7A] Figure 1B is a configuration diagram showing the internal structure of the digital ID wallet provider on the issuer's server in the payment system. [Figure 7B] Figure 7A shows an example of the configuration of wallet account VC data in a digital ID wallet provider. [Figure 8] Figure 1A is a configuration diagram showing the internal configuration of the digital currency wallet provider function of the holder-side terminal in the payment system. [Figure 9A] Figure 1A is a configuration diagram showing the internal configuration of the payment provider on the verifier server in the payment system. [Figure 9B] Figure 9A shows a table illustrating example configurations for wallet account VC data (payment input data) and electronic invoice / electronic receipt VC data (payment output data) in the payment provider shown. [Figure 10] Figure 1A is a configuration diagram showing the internal configuration of the merchant-side payment terminal in the payment system. [Figure 11A] This table shows an example of the configuration of a settlement VP as detailed data for a VP request (stablecoin settlement) in the settlement system shown in Figure 1A. [Figure 11B] Figure 1A shows a table illustrating an example of the configuration of a payment VP as detailed data for a VP request (credit card payment) in the payment system. [Figure 12]Figure 1A is a flowchart showing the payment process in the payment system. [Figure 13] Figure 12 is a diagram illustrating the various data flows across different systems included in the payment process. [Modes for carrying out the invention]

[0024] Embodiments of the present invention will be described in detail below with reference to the drawings. In addition, in multiple drawings, the same reference numerals represent the same components, and their descriptions will not be repeated. Furthermore, acronyms such as VC (verifiable credentials) and VP (verifiable presentation) will be mentioned below, but will not be explained again after their first appearance.

[0025] [Connection method of payment system] Figure 1A is a configuration diagram showing the connection configuration of a payment system according to one embodiment of the present invention. Figure 1B is a diagram showing the configuration of the basic model of the payment system shown in Figure 1A. Furthermore, Figure 1C is a configuration diagram showing an alternative configuration of the payment system shown in Figure 1A.

[0026] As shown in Figures 1A and 1C, a scenario is envisioned in which a verifier (e.g., a payment processing company) that has a transaction agreement with at least one payment institution of various cashless payment brands and a merchant (e.g., a retail store) that has a merchant agreement with the verifier, a holder (customer) who is a member of the said cashless payment brand, undergoes eligibility verification or identity verification through payment processing associated with or related to a sales contract for goods or services within the store.

[0027] In particular, in the pre-payment processing stage, when verifying the holder's qualifications or identity, the holder's operation on the user terminal 110 triggers a certificate of eligibility issued through the cooperation of the issuer's (e.g., financial institution, etc.) server 140 or 150, which is then provided by the holder to the merchant's payment terminal 170 via the user terminal 110. Subsequently, in the payment processing stage, when the holder performs a payment input operation on the payment terminal 170 with the support of the merchant's staff, the payment processing result from the verifier's server 160 is presented to the payment terminal 170.

[0028] Here, the holder's user terminal 110 is wirelessly connected to the issuer's servers 140 or 150 via the communication line 100. The merchant's payment terminal 170 is wirelessly or wiredly connected to the verifier's server 160 via the communication line 100. The communication line 100 may be, for example, a public network that enables telephone and data communication, or it may include a dedicated network that connects only specific systems to limited communication. In Figures 1A and 1C, the holder's user terminal 110 is a smartphone, but it differs in some aspects of its functional configuration.

[0029] On the other hand, the user terminal 110 in Figure 1A internally holds the functions of the digital ID wallet provider 115 and the digital currency wallet provider 120 in the form of applications. In particular, both functions store the holder's encryption VC, encryption key, and decryption key, as well as the holder's public and private keys for their digital currency account, within a security IC chip called a Secure Element (SE). This works in conjunction with application software installed as a payment service agent app to provide relatively high security externally in payment scenarios. Note that if a Public Biometric Infrastructure (PBI) is used for key management, the management of private keys using the Secure Element becomes unnecessary.

[0030] On the other hand, the user terminal 110 in Figure 1C internally holds the functions of a digital currency wallet provider 120 in the form of an application, but does not hold the functions of a digital ID wallet provider. Instead, it substitutes for the functions of a digital ID wallet provider by sending and receiving data related to the same functions with the digital ID wallet provider 130 in the external issuer server group, thereby providing the same functionality as the digital ID wallet provider 115 of the user terminal 110 in Figure 1A.

[0031] Here, the digital currency wallet provider 120 within the user terminal 110 in Figures 1A and 1C stores and updates the public key (wallet account number or trading account number, etc.) and private key (PIN (Personal Identification Number) or password for the wallet account or trading account, etc.) of the digital currency account according to the holder's instructions, and verifies the user's signing key according to the issuer's server's request, thus providing relatively high external security functions for information assets. Furthermore, the digital ID wallet 115 within the user terminal 110 in Figure 1A, and the digital ID wallet 130 on the issuer's server in Figure 1C, store and update the holder's encrypted VC and decryption key, and update the encrypted VC according to the holder's instructions or the issuer's server's request, thus providing relatively high external security functions for information assets. The holder's decryption key (public key) is generated from the encrypted key (private key) based on, for example, an elliptic curve cryptography scheme.

[0032] On the other hand, the digital currency wallet provider 150 on the issuer server in Figures 1A and 1C handles the balance on the blockchain network of the digital currency settlement platform 180 and sends settlement transactions to the digital currency settlement platform 180 in order to reflect the settlement results in the holder's wallet account according to the holder's instructions. Note that a transaction in online settlement refers to a unit that bundles together the processing necessary to carry out a single buy or sell transaction.

[0033] Furthermore, the user terminal 110 of the holder is able to send and receive various data necessary for payment processing in a contactless manner while in close proximity to the merchant's payment terminal 170, based on communication functions such as Near Field Communication (NFC) standards. In addition, when the agent application for the payment service is launched, identity verification of the holder's biometric information is performed as passwordless authentication based on the FIDO (Fast Identity Online) authentication method or the like.

[0034] Furthermore, each component 130 to 150 of the issuer-side server group is operated by financial institutions such as banks and payment companies that have business contracts with at least one cashless payment brand, and manages the credentials of holders who are members of the cashless payment brand. Regarding cryptocurrency wallets, if a custodial wallet is assumed, the issuer-side server group holds and manages the holder's encryption key, decryption key, etc. On the other hand, if a non-custodial wallet is assumed, the holder's encryption key is managed solely by the holder themselves and is therefore not held by the issuer-side server group.

[0035] Here, the payment provider 140, identity verification provider 142, points member provider 144, and digital currency wallet provider 150 within the issuer-side server group manage the following as credentials for holders and digital currency accounts: for example, credit account information, identity verification information, points member information, and wallet account information. In response to requests from the holder's user terminal 110, they issue each encrypted VC, namely the credit account VC, identity verification VC, points member VC, and wallet account VC, to the digital ID wallet 115 in the user terminal 110 or the issuer's digital ID wallet 130, respectively. Other examples of such VCs include student VCs, employee VCs, and parenting VCs, which are managed and issued in a similar manner.

[0036] Here, the holder's encryption key is based on a decentralized identifier (DID) generated by functionally transforming biometric information such as the holder's fingerprint, iris, voiceprint, ear features, facial features, and vein pattern. Furthermore, the holder's DID is maintained differently for each payment service across cashless payment brands, issuers, and holders, thus avoiding correlation between VC / VP across multiple payment services.

[0037] Furthermore, the payment provider 160 on the verifier server handles a portion of the payment flow related to the holder and the payment institution via the merchant payment terminal 170, based on the fact that the payment processing company has entered into a transaction agreement with a payment institution belonging to at least one of various cashless payment brands. Here, the payment provider 160 responds to the payment request received from the payment terminal 170 and transmits the result of the payment processing by the relevant payment institution to the payment terminal 170.

[0038] Furthermore, the merchant-side payment terminal 170 is installed in a merchant store that has a merchant agreement with the merchant management company, and supports various cashless payment processing methods during the accounting process of retail sales transactions conducted within that store, assisting customers (holders) in making payments for the purchase of goods or services. In particular, the customer-facing screen implemented as an operation panel function in the payment terminal 170 can display various information before and after payment, or various information before and after identity verification or qualification verification.

[0039] In particular, the types of cashless payments envisioned here include card payments, electronic money payments, code payments, and stablecoin payments. In card payments, the payment terminal 170 reads the card itself, or reads it via a smartphone or other device, based on a credit card, prepaid card, or debit card presented by the customer.

[0040] Furthermore, the tokens circulating on the Digital Currency Payment Platform 180 are stablecoins based on distributed ledger technology using blockchain. Here, distributed ledger technology using blockchain refers to a technology that attempts to maintain accurate financial transaction history by linking and storing transaction history from the past to the present in units called blocks using cryptographic technology, based on the management and sharing of the same ledger (database) by each participant (computer) on the network. Stablecoins are digital currencies (cryptocurrencies) whose price is designed to be pegged to fiat currency or commodities traded in the market (goods such as precious metals or industrial metals), and they have the characteristic of excellent price stability due to the existence of a central administrator. It should be noted that the Digital Currency Payment Platform 180 can also be applied to platforms that use other digital currencies for settlement, such as central bank digital currencies or tokenized deposits, in addition to stablecoins.

[0041] [Payment system model configuration] Figure 1B shows the configuration of the basic model of the payment system shown in Figure 1A. As shown in Figure 1B, verifiable credentials (VC) are utilized by the relevant components in various scenarios: signing, issuing, storing, presenting, and verifying. The issuer is the company that issues credentials to the holder, the holder is the individual or company that manages the issued credentials and presents them to the verifier, and the verifier is the company that verifies the authenticity of the credentials.

[0042] Here, the credential information is composed of, for example, the following: (1) information related to the identification of the subject of the credential information (e.g., the subject's identification number), (2) information related to the issuing authority (e.g., the financial institution's identification number), (3) information related to the type of credential information (e.g., credit card, electronic currency wallet), (4) information related to specific attributes or characteristics claimed by the issuing authority about the subject (e.g., date of birth, address), (5) evidence regarding the method of deriving the credential information (e.g., My Number card), and (6) information related to the restrictions on the credential information (e.g., validity period, terms of use).

[0043] More specifically, the VC issued to the holder by the issuer-side server's payment provider 140 and digital currency wallet provider 150 is stored in a secure element, which is a verifiable data registry, by the digital ID wallet provider 115 in the user terminal 110 held by the holder. Here, the issuer-side server assigns a different digital signature (e.g., a digital signature based on public-key cryptography) to each piece of information (Claim) contained within the credentials, and then constructs an encrypted VC based on a different encryption key.

[0044] In a payment scenario, when the payment provider 160 on the verifier server sends an electronic invoice to the user terminal 110 to request the holder's VP, the digital ID wallet provider 115 within the user terminal 110 sends an electronic check (including wallet account VC, identity verification VC, point member VC, etc.) to the payment provider 160 to verify credentials using an encrypted VP generated from an encrypted VC in the data registry. Regarding the credentials required for VC verification, techniques such as zero-knowledge proofs (ZKP) are applied to present only the minimum necessary credentials about the holder to the verifier, i.e., to generate the optimal VP from the available VCs.

[0045] At this point, the verifier uses the holder's decryption key to verify the legitimacy of the provided VC (Credential Proof). The verification process may consist of the following: (1) confirming the issuer of the Proof, (2) confirming the owner of the Credential information that forms the basis of the Proof, (3) confirming the individual claims contained within the Credential information, and (4) confirming that the Credential information has not expired (that the validity period of the Credential information has not expired).

[0046] Next, when the payment provider 160 on the verifier server sends a payment request to the issuer server, the digital currency wallet provider 150 on the issuer server generates a payment transaction and then sends a signature request for the payment transaction to the holder's user terminal 110. Subsequently, the digital currency wallet provider 120 in the user terminal 110 sends a signature approval to the digital currency wallet provider 150.

[0047] Next, when the digital currency wallet provider 150 on the issuer server sends the payment approval result to the verifier server, the payment provider 160 on the verifier server sends an electronic receipt (including a receipt VP, etc.) to the holder's user terminal 110 in order to complete the payment by encrypted VP. Meanwhile, when the digital currency wallet provider 150 on the issuer server sends the payment transaction to the digital currency payment infrastructure 180, the digital currency payment infrastructure 180 registers the payment information and the transaction information associated with it as a block on the blockchain as a payment transaction.

[0048] [Internal configuration of the payment provider on the issuer's server] Figure 2A is a configuration diagram showing the internal structure of the payment provider 140 on the issuer side server in the payment system shown in Figure 1A. Figure 2B is a table showing an example of the configuration of credit card account VC data stored in the card-related data storage unit 252 within the payment provider 140 shown in Figure 2A.

[0049] As shown in Figure 2A, the issuer-side server's payment provider 140 is configured similarly to a computer intended for general server use, and supports processing functions related to the task of managing payment information among the holder's credentials, and determines the issuance of that credentials to provide to the user terminal 110 as a VC. More specifically, in the payment provider 140, the control unit 210, main memory unit 212, input unit 214, output unit 216, communication interface 218, and auxiliary storage unit 220 are connected to each other via the system bus 200 so that they can communicate with one another.

[0050] The auxiliary storage unit 220 contains a VC management unit 230, a VC issuance unit 232, a transaction management unit 234, a customer data management unit 236, a limit management unit 238, and a VC encryption unit 240, respectively. When the programs held in these components are loaded into the main storage unit 212 based on a call instruction from the control unit 210, each application program constructed by this load executes various calculations that handle the processing of various data related to VC management and issuance.

[0051] Furthermore, the auxiliary storage unit 220 includes a customer data storage unit 250, a card-related data storage unit 252, a VC management data storage unit 254, and a program storage unit 256, respectively. When the data and programs stored in these components are loaded into the main storage unit 212 based on a call instruction from the control unit 210, the subsystems constructed by this load are used to process various calculations that manage data and programs in file / database format.

[0052] The control unit 210 functions as a Central Processing Unit (CPU), controlling the operation of individual system components and performing data calculations, particularly loading data and programs stored in the auxiliary storage unit 220 into the main memory unit 212 to perform various calculations. The main memory unit 212 functions as the main memory, storing various data and programs, as well as computer-executable instructions, input from the input unit 214, communication interface unit 218, and auxiliary storage unit 220, based on instructions from the control unit 210. It also stores the data processed by calculations on these internally and provides it externally via the output unit 216.

[0053] The input unit 214 provides an interface for receiving various commands and data (e.g., data from various masters and tables) input by the system operator. The output unit 216 provides an interface for generating output data for displaying various processed data to the operator, and output data for printing said data. The communication interface unit 218 provides an interface that functions when sending and receiving various data with the holder's user terminal 110, the digital currency wallet provider 150 on the issuer's server, the payment provider 160 on the verifier's server, and other internal systems and devices.

[0054] Here, each embodiment of the server configuration of the issuer-side server payment provider 140 only needs to function as a single system configuration. For example, the payment provider 140 may be located inside a single server computer, or it may be configured by distributing each system component in parallel as multiple sets of units, or it may be configured by combining multiple server computers to share data and programs.

[0055] More specifically, the VC management unit 230 manages the generation, updating, and cancellation of the holder's VC-enhanced credentials and stores the related information in the VC management data storage unit 254. The VC issuance unit 232 issues the holder's VC-enhanced credentials to the user terminal 110. The transaction management unit 234 manages the execution of a series of indivisible processes necessary for the VC management or VC issuance described above and stores the processing results in the card-related data storage unit 252. The customer data management unit 236 manages the holder's credentials and encryption keys (e.g., private keys based on public-key cryptography) and stores the related information in the customer data storage unit 250.

[0056] Furthermore, the credit limit management unit 238 manages the setting, updating, and cancellation of credit limits based on credit management for cardholders, and stores the related information in the customer data storage unit 250. The VC encryption unit 240 uses the cardholder's encryption key stored in the customer data storage unit 250 against the cardholder's credentials stored in the card-related data storage unit 252 to generate encrypted VCs and delivers them to the VC issuance unit 232. The program storage unit 256 stores programs for executing a series of processes performed as a transaction, or other individual processes, and receives calls to these programs from the control unit 210.

[0057] The customer data storage unit 350 stores registration information of the customer (holder), such as customer ID, name, address, telephone number, email address, gender, date of birth, withdrawal account, occupation, job title, annual income, and family structure. The VC management data storage unit stores change information of the holder's qualifications, such as qualification ID, customer ID, issuer ID, change status, change date and time, and expiration date.

[0058] In this case, if the issuer is a credit company and the holder uses a credit card, the card-related data storage unit 252 stores, for example, the issuer identifier, card number, holder identifier, expiration date, etc., as the data structure of the credit card account VC shown in Figure 2B.

[0059] [Internal configuration of the identity verification provider on the issuer's server] Figure 3A is a configuration diagram showing the internal structure of the identity verification provider 142 on the issuer side server in the payment system shown in Figure 1A. Figure 3B is a table showing an example of the configuration of identity verification VC data stored in the identity-related data storage unit 352 within the identity verification provider 142 shown in Figure 3A.

[0060] As shown in Figure 3A, the issuer-side server's identity verification provider 142 is configured similarly to a computer intended for general server use, supporting processing functions related to the task of managing identity verification information among the holder's credentials, and determining whether to issue the credentials to the user terminal 110 as a VC. More specifically, in the identity verification provider 142, the control unit 310, main memory unit 312, input unit 314, output unit 316, communication IF 318, and auxiliary memory unit 320 are connected to each other via the system bus 300 so that they can communicate with one another. Note that these components basically operate in the same way as the components of the payment provider 140, so further details will not be explained.

[0061] The auxiliary storage unit 320 contains a VC management unit 330, a VC issuance unit 332, a transaction management unit 334, a customer data management unit 336, and a VC encryption unit 338, respectively. When the programs held in these components are loaded into the main storage unit 312 based on a call instruction from the control unit 310, each application program constructed by this load executes various calculations that handle the processing of various data related to VC management and issuance.

[0062] Furthermore, the auxiliary storage unit 320 contains a customer data storage unit 350, a personal data storage unit 352, a VC management data storage unit 354, and a program storage unit 356, respectively. When the data and programs stored in these components are loaded into the main storage unit 312 based on a call instruction from the control unit 310, the subsystem constructed by this load is used for various calculations that manage data and programs in file / database format.

[0063] More specifically, the VC management unit 330 manages the generation, updating, and cancellation of the holder's VC-enabled credentials and stores the related information in the VC management data storage unit 354. The VC issuance unit 332 issues the holder's VC-enabled credentials to the user terminal 110. The transaction management unit 334 manages the execution of a series of indivisible processes necessary for the VC management or VC issuance described above and stores the processing results in the user-related data storage unit 352. The customer data management unit 336 manages the holder's credentials and stores the related information in the customer data storage unit 350.

[0064] Furthermore, the VC encryption unit 338 uses the holder's encryption key stored in the customer data storage unit 350 to obtain the holder's credentials stored in the personal information storage unit 352, and then delivers the generated encrypted VC to the VC issuance unit 332. The program storage unit 356 stores programs for executing a series of processes to be performed as a transaction, or other individual processes, and receives calls to these programs from the control unit 310.

[0065] Here, the personal information storage unit 352 stores, for example, the issuer identifier, basic four pieces of information (name, gender, date of birth, and address), holder identifier, issuance date and time, expiration date, etc., as the data structure of the personal verification VC shown in Figure 3B.

[0066] [Internal configuration of the points member provider on the issuer's server] Figure 4A is a diagram showing the internal configuration of the point member provider 144 on the issuer side server in the payment system shown in Figure 1A. Figure 4B is a table showing an example of the configuration of point member VC data stored in the member-related data storage unit 452 within the point member provider 144 shown in Figure 4A.

[0067] As shown in Figure 4A, the issuer-side server's point member provider 144 is configured similarly to a computer intended for general server use, supporting processing functions related to the task of managing point member information among the holder's credentials, and determining whether to issue that credentials to the user terminal 110 as a VC. More specifically, in the point member provider 144, the control unit 410, main memory unit 412, input unit 414, output unit 416, communication IF 418, and auxiliary memory unit 420 are connected to each other via the system bus 400 so that they can communicate with one another. Note that these components basically operate in the same way as the components of the payment provider 140, so further details will not be explained.

[0068] The auxiliary storage unit 420 contains a VC management unit 430, a VC issuance unit 432, a transaction management unit 434, a customer data management unit 436, and a VC encryption unit 438, respectively. When the programs held in these components are loaded into the main storage unit 412 based on a call instruction from the control unit 410, each application program constructed by this load executes various calculations that handle the processing of various data related to VC management and issuance.

[0069] Furthermore, the auxiliary storage unit 420 contains a customer data storage unit 450, a member-related data storage unit 452, a VC management data storage unit 454, and a program storage unit 456, respectively. When the data and programs stored in these components are loaded into the main storage unit 412 based on a call instruction from the control unit 410, the subsystems constructed by this load are used to process various calculations that manage data and programs in file / database format.

[0070] More specifically, the VC management unit 430 manages the generation, updating, and cancellation of the holder's VC-enabled credentials and stores the related information in the VC management data storage unit 454. The VC issuance unit 432 issues the holder's VC-enabled credentials to the user terminal 110. The transaction management unit 434 manages the execution of a series of indivisible processes necessary for the VC management or VC issuance described above and stores the processing results in the member-related data storage unit 452. The customer data management unit 436 manages the holder's credentials and stores the related information in the customer data storage unit 450.

[0071] Furthermore, the VC encryption unit 438 uses the holder's encryption key stored in the customer data storage unit 450 to obtain the holder's credentials stored in the member-related data storage unit 452, and then delivers the generated encrypted VC to the VC issuance unit 432. The program storage unit 456 stores programs for executing a series of processes that are performed as a transaction, or other individual processes, and receives calls to these programs from the control unit 410.

[0072] Here, the member-related data storage unit 452 stores, for example, the data structure of the points member VC shown in Figure 4B, including issuer identifier, password, name, issuance date and time, expiration date, mileage balance, etc.

[0073] [Internal configuration of the digital currency wallet provider on the issuer's server] Figure 5A is a configuration diagram showing the internal configuration of the digital currency wallet provider 150 on the issuer side server in the payment system shown in Figure 1A. Figure 5B is a table showing an example of the configuration of wallet account VC data stored in the wallet-related data storage unit 552 within the digital currency wallet provider 150 shown in Figure 5A.

[0074] As shown in Figure 5A, the issuer-side server's digital currency wallet provider 150 is configured similarly to a computer intended for general server use, supporting processing functions related to managing wallet account information among the holder's credentials, and determining the issuance of that credentials to provide to the user terminal 110 as a VC. More specifically, in the digital currency wallet provider 150, the control unit 510, main memory unit 512, input unit 514, output unit 516, communication IF 518, and auxiliary storage unit 520 are connected to each other via the system bus 500 so that they can communicate with one another. Note that these components basically operate in the same way as the components of the payment provider 140, so further details will not be explained.

[0075] The auxiliary storage unit 520 contains a VC management unit 530, a VC issuance unit 532, a transaction management unit 534, a customer data management unit 536, and a VC encryption unit 538, respectively. When the programs held in these components are loaded into the main storage unit 512 based on a call instruction from the control unit 510, each application program constructed by this load executes various calculations that handle the processing of various data related to VC management and issuance.

[0076] Furthermore, the auxiliary storage unit 520 includes a customer data storage unit 550, a wallet-related data storage unit 552, a VC management data storage unit 554, and a program storage unit 556, respectively. When the data and programs stored in these components are loaded into the main storage unit 512 based on a call instruction from the control unit 510, the subsystem constructed by this load is used to process various calculations that manage data and programs in file / database format.

[0077] More specifically, the VC management unit 530 manages the generation, updating, and cancellation of the holder's VC-enhanced credentials and stores the related information in the VC management data storage unit 554. The VC issuance unit 532 issues the holder's VC-enhanced credentials to the user terminal 110. The transaction management unit 534 manages the execution of a series of indivisible processes necessary for the VC management or VC issuance described above and stores the processing results in the wallet-related data storage unit 552. The customer data management unit 536 manages the holder's credentials and stores the related information in the customer data storage unit 550. Regarding the cryptocurrency wallet, assuming a managed delegation type wallet, the digital currency wallet provider 150 stores the holder's encryption key, decryption key, etc., in the customer data storage unit 550 and holds and manages them. On the other hand, assuming a self-managed type wallet, the holder's encryption key is managed solely by the holder and is not held by the digital currency wallet provider 150.

[0078] Furthermore, the VC encryption unit 538 uses the holder's encryption key on the holder's credentials stored in the member-related data storage unit 552 to deliver the generated encrypted VC to the VC issuance unit 532. The program storage unit 556 stores programs for executing a series of processes to be performed as a transaction, or other individual processes, and receives calls to these programs from the control unit 510. Note that, in the case of a managed-delegation type wallet, the generation of encrypted VC by the VC encryption unit 538 is performed using the holder's encryption key stored in the customer data storage unit 550, while in the case of a self-managed type wallet, it is performed using the holder's encryption key stored in the user terminal 110.

[0079] Here, the wallet-related data storage unit 552 stores, for example, the issuer identifier, issuer / issuing service name, payment request recipient, wallet address, expiration date, etc., as the data structure of the wallet account VC shown in Figure 5B.

[0080] [Internal configuration of the digital ID wallet provider function on the holder's user terminal] Figure 6A is a configuration diagram showing the internal configuration of the digital ID wallet provider 115 of the holder-side user terminal 110 in the payment system shown in Figure 1A. Figure 6B is a table showing an example of the configuration of wallet account VC data stored in the VC data storage unit 660 within the secure element 650 of the user terminal 110 shown in Figure 6A. Here, the digital ID wallet provider 115 and the digital currency wallet provider 120 are configured as applications installed on the user terminal 110.

[0081] As shown in Figure 6A, the user terminal 110 is configured as a general-purpose mobile computer, similar to a typical smartphone, and manages the owner's biometric information. It plays a part in providing VC and processing payments through the issuer-side server 140 or 150, the verifier-side server's payment provider 160, and the merchant-side payment terminal 170.

[0082] More specifically, in the user terminal 110, the control unit 610, main memory unit 612, input unit 614, display unit 616, output unit 618, communication IF 620, auxiliary memory unit 630, and secure element 650 are connected to each other via the system bus 600 so that they can communicate with one another. Except for the display unit 616 and the secure element 650, these components basically operate in the same way as the components of the issuer-side servers 140 or 150, so further details will not be explained.

[0083] The display unit 616 displays instructions received from the owner or information requiring confirmation by the owner on the screen. The secure element 650 has a storage area and an encryption application programming interface (API), and is configured to store or generate the owner's encryption key, decryption key, and encryption VC.

[0084] The auxiliary storage unit 630 contains a VC verification request receiving unit 640, a VC verification unit 642, a transaction management unit 644, a verified VC selection unit 646, and a verified VP output unit 648, respectively. When the programs held in these components are loaded into the main storage unit 612 based on a call instruction from the control unit 610, each application program constructed by this load executes various calculations that handle the processing of various data related to VC management and issuance.

[0085] More specifically, when the VC verification request receiving unit 640 receives a request for a settlement VC from the merchant-side settlement terminal 170, it receives it as a request for settlement VC verification and outputs the settlement VP generated by the verification VC selection unit 646 to the verification VP output unit 648. The verification VP output unit 648 outputs the settlement VP to the communication IF unit 620 in order to send the settlement VP to the settlement terminal 170. The VC verification unit 642 generates a private key from the holder's biometric information incorporated as biometric authentication, and verifies the holder's legitimacy by matching the public key further generated from this private key with the public key provided by the secure element 650. Furthermore, the VC verification unit 642 verifies the legitimacy of the electronic signature corresponding to the encrypted VC provided by the secure element 650.

[0086] Furthermore, the transaction management unit 644 manages the execution of a series of indivisible processes required for VC verification and stores the processing results in the VC data storage unit 660 within the secure element 650. The verification VC selection unit 646 generates a settlement VP by selecting a settlement VC that limits the credentials included in the settlement VC to the minimum necessary, in response to the settlement VC requested from the merchant settlement terminal 170.

[0087] Furthermore, the secure element 650 includes a VC data storage unit 660. The VC data storage unit 660 stores, for example, the holder's VC, including the qualification ID, customer ID, issuer ID, encrypted VC, digital signature, public key, modification status, modification date and time, and expiration date. Here, the VC data storage unit 660 holds, for example, the issuer identifier, issuer / issuing service name, payment request recipient, wallet address, expiration date, etc., as the data structure of the wallet account VC shown in Figure 6B.

[0088] [Internal configurations of the digital ID wallet provider on the holder's user terminal and the issuer's server] Figure 7A is a configuration diagram showing the internal configuration of the digital ID wallet provider 130 on the issuer-side server in the payment system shown in Figure 1C. Figure 7B is a table showing an example of the configuration of wallet account VC data stored in the VC data storage unit 760 within the external server 750 connected to the digital ID wallet provider 130 shown in Figure 7A. Here, the digital currency wallet provider 120 is configured as an application installed on the user terminal 110, while the digital ID wallet provider 130 is configured as a component of the issuer-side server and functions as a web browser configuration for the user terminal 110.

[0089] As shown in Figure 7A, the issuer-side server's digital ID wallet provider 130 is configured similarly to a computer intended for general server use and plays a part in providing VCs and processing payments through the issuer-side servers 140 or 150, the verifier-side server's payment provider 160, and the merchant-side payment terminal 170. More specifically, in the digital ID wallet provider 130, the control unit 710, main memory unit 712, input unit 714, output unit 716, communication IF 718, and auxiliary storage unit 720 are connected to each other via the system bus 700 so that they can communicate with one another. Note that these components basically operate in the same way as the components of the payment provider 140, so further details will not be explained.

[0090] The auxiliary storage unit 720 contains a VC verification request receiving unit 730, a VC verification unit 732, a transaction management unit 734, a verified VC selection unit 736, and a verified VP output unit 738, respectively. When the programs held in these components are loaded into the main storage unit 712 based on a call instruction from the control unit 710, each application program constructed by this load executes various calculations that handle the processing of various data related to VC management and issuance.

[0091] Furthermore, an external server 750 is connected via a communication IF 718 as a component separate from the digital ID wallet provider 130. The external server 750 has a VC data storage unit 760 built as a database, and the VC data storage unit 760 is configured to store the holder's encryption key, decryption key, and encrypted VC.

[0092] More specifically, when the VC verification request receiving unit 730 receives a request for a settlement VC from the merchant-side settlement terminal 170 via the user terminal 110, it receives it as a request for settlement VC verification and outputs the settlement VP generated by the verification VC selection unit 736 to the verification VP output unit 738. The verification VP output unit 738 outputs the settlement VP to the communication IF unit 720 in order to transmit the settlement VP to the settlement terminal 170 via the user terminal 110. The VC verification unit 732 verifies the legitimacy of the holder by matching the public key provided by the user terminal 110 with the public key provided by the external server 750. Furthermore, the VC verification unit 732 verifies the legitimacy of the digital signature corresponding to the encrypted VC provided by the external server 750 based on the holder's public key provided by the user terminal 110.

[0093] Furthermore, the transaction management unit 734 manages the execution of a series of indivisible processes required for VC verification and stores the processing results in the VC data storage unit 760 in the external server 750. The verification VC selection unit 736 generates a settlement VP by selecting a settlement VC that limits the credentials included in the settlement VC to the minimum necessary, in response to a settlement VC requested from the merchant-side settlement terminal 170 via the user terminal 110.

[0094] Furthermore, the VC data storage unit 760 within the external server 750 stores, for example, the holder's VC, including the qualification ID, customer ID, issuer ID, encrypted VC, digital signature, public key, modification status, modification date and time, and expiration date. Here, the VC data storage unit 760 holds, for example, the issuer identifier, issuer / issuing service name, payment request recipient, wallet address, expiration date, etc., as the data structure of the wallet account VC shown in Figure 7B.

[0095] [Internal configuration of the digital currency wallet provider function on the holder's user device] Figure 8 is a configuration diagram showing the internal configuration of the digital currency wallet provider 120 on the holder-side user terminal 110 in the payment system shown in Figure 1A. Here, the digital currency wallet provider 120 is configured as an application installed on the user terminal 110.

[0096] As shown in Figure 8, the user terminal 110 is configured as a general-purpose mobile computer, similar to a typical smartphone, and supports processing functions related to verifying user signatures for settlement transactions requested by the issuer server, and determining whether to approve or reject the signature. More specifically, in the user terminal 110, the control unit 810, main memory unit 812, input unit 814, display unit 816, output unit 818, communication IF 820, auxiliary storage unit 830, and secure element 850 are connected to each other via the system bus 800 so that they can communicate with one another. These components basically operate in the same way as the components of the user terminal 110 in Figure 6A, so further details will not be explained.

[0097] The auxiliary storage unit 830 contains a wallet address management unit 840 and a transaction management unit 842, respectively. When the programs held in these components are loaded into the main storage unit 812 based on a call instruction from the control unit 810, each application program constructed by this load executes various calculations that handle the processing of various data related to settlement transaction VC management and issuance.

[0098] More specifically, the wallet address management unit 840 manages wallet account VC data provided by the digital currency wallet provider 150 on the issuer server and stores the related information in the wallet-related data storage unit 860. The transaction management unit 842 manages the execution of a series of indivisible processes necessary for managing wallet addresses and stores the results of these processes in the wallet-related data storage unit 860.

[0099] Furthermore, the wallet address management unit 840, in response to requests from the digital currency wallet provider 150, performs management such as updating and canceling the holder's wallet account VC stored in the wallet-related data storage unit 860, and stores the related information in the wallet-related data storage unit 860. The wallet-related data storage unit 860 stores, for example, the wallet address, qualification ID, issuer ID, encrypted VC, digital signature, private key, public key, change status, change date and time, and expiration date as the holder's VC.

[0100] [Internal configuration of the payment provider on the verifier's server] Figure 9A is a configuration diagram showing the internal configuration of the payment provider 160 on the verifier server in the payment system shown in Figure 1A. Figure 9B is a table showing example configurations of the wallet account VC data (payment input data) and the electronic invoice / electronic receipt VC data (payment output data) in the payment provider 160 shown in Figure 9A.

[0101] As shown in Figure 9A, the verifier-side server's payment provider 160 is configured similarly to a computer intended for general server use and supports processing functions related to managing VC verification of holders 10 in a payment scenario and performing payment processing. More specifically, in the payment provider 160, the control unit 910, main memory unit 912, input unit 914, output unit 916, communication IF 918, and auxiliary memory unit 920 are connected to each other via the system bus 900 so that they can communicate with one another. These components operate essentially the same as the components of the issuer-side servers 140 or 150, so further details will not be explained.

[0102] The auxiliary storage unit 920 contains the following components: a VC verification request issuance unit 930, a VC verification unit 932, a transaction management unit 934, a verified VC determination unit 936, a settlement data calculation unit 938, an invoice / receipt issuance unit 940, a VC management unit 942, and a VC issuance unit 944. When the programs held in these components are loaded into the main storage unit 912 based on a call instruction from the control unit 910, each application program constructed by this load executes various calculations that handle the processing of various data related to VC verification and settlement.

[0103] Furthermore, the auxiliary storage unit 920 contains a customer data storage unit 950, a member-related data storage unit 952, a payment data storage unit 954, a merchant data storage unit 956, and a program storage unit 958, respectively. When the data and programs stored in these components are loaded into the main storage unit 912 based on a call instruction from the control unit 910, the subsystems constructed by this load are used to process various calculations that manage data and programs in file / database format.

[0104] More specifically, when the VC verification request issuing unit 930 receives a request for verification of a payment VC from the merchant-side payment terminal 170, it issues a request for VC signature verification to the user terminal 110 and transmits the verification result of the payment VC generated by the VC verification determination unit 932 to the payment terminal 170. The VC verification unit 932 uses the holder's public key obtained from the user terminal 110 to verify the electronic signature corresponding to the holder's VC.

[0105] Furthermore, the transaction management unit 934 manages the execution of a series of indivisible processes necessary for VC verification and settlement processing, and stores the processing results in the settlement data storage unit 954. The VC verification determination unit 936 further verifies that the settlement VCs that have been verified as valid by the VC verification unit 932 meet the requirements necessary for settlement processing, and instructs the unit to proceed to settlement processing. Upon receiving instructions from the VC verification determination unit 936, the settlement data calculation unit 938 stores the execution results of the settlement processing in the settlement data storage unit 954.

[0106] Furthermore, the invoice / receipt issuing unit 940 issues an electronic invoice based on the execution results of the settlement process stored in the settlement data storage unit 954 and transmits it to the holder's user terminal 110 via the merchant's settlement terminal 170. In addition, the invoice / receipt issuing unit 940 issues an electronic receipt based on the settlement results from the issuer's server and transmits it to the holder's user terminal 110 via the merchant's settlement terminal 170. The VC management unit 942 manages the holder's VC-enabled credentials, including verification, updating, and cancellation, and stores the related information in the customer data storage unit 950. The VC issuing unit 944 transmits the verification results of the holder's VC-enabled credentials to the holder's user terminal 110 via the merchant's settlement terminal 170.

[0107] Here, the customer data storage unit 950 stores the registration information of the customer holder, such as customer ID, name, address, telephone number, email address, gender, and date of birth. The member-related data storage unit 952 stores the holder's membership card information. The payment data storage unit 954 stores payment result information along with input / output data of the payment process. The merchant data storage unit 956 stores merchant information for which a merchant agreement has been concluded with the merchant management company. The program storage unit 958 stores programs for executing a series of processes to be performed as a transaction, or other individual processes, and receives calls to these programs from the control unit 910.

[0108] Furthermore, the settlement data storage unit 954 allows the following as input data for settlement processing, for example, as shown in the upper part of Figure 9B: type of payment method, issuer identifier, issuer / issuing service name, recipient of settlement request, wallet address, expiration date, issuer signature, etc. The settlement data storage unit 954 also stores the following as output data for settlement processing, for example, as shown in the lower part of Figure 9B: merchant identifier, issuer / issuing service name, qualified invoice provider number, issue date and time, settlement amount, detailed information of settlement amount, detailed purchase information, merchant signature, payer identifier (for inter-corporate settlements), payer name (for inter-corporate settlements), payment status (invoice / receipt), invoice number, etc.

[0109] [Internal configuration of merchant payment terminals] Figure 10 is a configuration diagram showing the internal configuration of the merchant-side payment terminal 170 in the payment system shown in Figure 1A. As shown in Figure 10, the payment terminal 170 is configured similarly to a computer for professional client use in order to support functions specialized for accounting processing of retail sales, and as a client of the verifier-side server payment provider 160, it plays a part in holder VC verification and payment processing in the payment scene.

[0110] More specifically, in the merchant-side payment terminal 170, the control unit 1010, main memory unit 1012, input unit 1014, display unit 1016, printing unit 1018, output unit 1020, communication interface 1022, and auxiliary storage unit 1030 are connected to each other via the system bus 1000 so that they can communicate with one another. Except for the display unit 1016 and printing unit 1018, these components basically operate in the same way as the components of the verifier-side server 160, so we will not explain the details again.

[0111] Here, the display unit 1016 displays instructions received from the cardholder or the merchant's staff, or information that requires confirmation by the cardholder or the staff, on the screen. The printing unit 1018 outputs the settlement result data to the built-in printer as the print target, and as a result, receipts showing accounting details or receipts showing settlement results are ejected from the printer output as separate sheets of paper for each transaction.

[0112] The auxiliary storage unit 1030 contains a settlement processing control unit 1040, a VC verification control unit 1042, a VC verification record management unit 1044, an attribute information management unit 1046, a membership card information management unit 1048, and a transaction management unit 1050, respectively. When the programs held in these components are loaded into the main storage unit 1012 based on a call instruction from the control unit 1010, each application program constructed by this load executes various calculations that handle the processing of various data related to VC verification and settlement.

[0113] Furthermore, the auxiliary storage unit 1030 contains a VC verification record storage unit 1060, an attribute information storage unit 1062, and a membership card information storage unit 1064, respectively. When the data and programs stored in these components are loaded into the main storage unit 1012 based on a call instruction from the control unit 1010, the subsystems constructed by this load are used for various calculations that manage data and programs in file / database format.

[0114] More specifically, when the payment processing control unit 1040 receives a payment request entered by the holder via various input interfaces, it sends this payment request to the payment provider 160 on the verifier server, and then notifies the holder and the merchant staff of the payment result from the payment provider 160 via each output interface. The VC verification control unit 1042 generates a verification request for the holder's payment VC entered by the user terminal 110 via each input interface, sends the verification request to the payment provider 160, and receives the verification result from the payment provider 160. The VC verification record management unit 1044 manages the verification results from the payment provider 16 and stores only those VC verification records for which confirmation was accepted at the relevant merchant in the VC verification storage unit 1060.

[0115] Furthermore, the attribute information management unit 1046 manages the holder's personal attribute information received from the user terminal 110 and additional attribute information directly entered by the merchant's staff, and stores this attribute information in the attribute information storage unit 1062. The membership card information management unit 1048 manages only the membership card information applied for at the relevant merchant when the holder becomes a member of the merchant, and stores this in the membership card information storage unit 1064. The transaction management unit 1050 manages the execution of a series of indivisible processes necessary for VC verification and settlement processing, and stores the processing results in the VC verification storage unit 1060 and the attribute information storage unit 1062.

[0116] Here, the VC verification storage unit 1060 stores, for example, the qualification ID, customer ID, issuer ID, encrypted VC, digital signature, public key, verification result, verification date and time, and expiration date as the holder's VC verification results. The attribute information storage unit 1062 stores, as personal attribute information and additional attribute information, the customer ID, name, date of birth, gender, address, membership card number, qualification number, registration method, and registration date. The membership card information storage unit 1064 stores, as membership card information, the membership card number, customer ID, credit card number, registration method, and registration date.

[0117] [Detailed Configuration of Payment VP] Figure 11A is a table showing an example of the configuration of a settlement VP in stablecoin settlement, as detailed data of the VP request in the settlement system shown in Figure 1A. The settlement VP shown in the upper part of Figure 11A is generated by the digital ID wallet provider 115 in the holder-side user terminal 110 and then sent to the settlement provider 160 on the verifier-side server via the merchant-side settlement terminal 170. Here, one settlement VP is configured to be able to link to multiple VC data, and is associated with the wallet VC and identity verification VC, respectively. The electronic invoice VC shown in the lower part of Figure 11A is generated by the settlement provider 160 on the verifier-side server and then sent to the holder-side user terminal 110 via the merchant-side settlement terminal 170. In the electronic invoice VC, the applicable tax rate and consumption tax amount are optimally applied.

[0118] Figure 11B is a table showing an example of the configuration of a payment VP in a credit card payment, as detailed data of the VP request in the payment system shown in Figure 1A. The payment VP shown in Figure 11B is generated by the digital ID wallet provider 115 in the holder-side user terminal 110 and then sent to the payment provider 160 on the verifier-side server via the merchant-side payment terminal 170. Here, a single payment VP is configured to be able to link to multiple VC data, and is associated with the credit card VC, payment amount VC, and identity verification VC, respectively.

[0119] [Various processes for online payment processing] Regarding the various processes in the payment system described above, the payment process is explained below assuming that the issuer, holder, and verifier are online during the payment processing. Figure 12 is a flowchart of the payment process in the payment system shown in Figure 1A. Figure 13 is a linkage diagram showing the various data flows across the different systems included in the payment process shown in Figure 12.

[0120] (During VC verification) As a preliminary step to payment when the holder enters into a purchase agreement for goods / services at a participating store, the holder's VC verification is performed. In step S1200, when the store staff receives a payment request from the holder and instructs the payment terminal 170 to start payment, the store-side payment terminal 170 requests the holder-side user terminal 1100 to issue a payment VC using VC issuance request data 1300. Subsequently, in step S1202, when the digital ID wallet provider 115 of the user terminal 110 receives the VC issuance request data 1300 from the payment terminal 170, it sends VC issuance request data 1302 to the various providers 140 or 150 on the issuer-side server.

[0121] Next, in step S1204, when the various providers 140, 142, and 144 of the issuer server receive the VC issuance request data 1302 from the user terminal 110, they perform identity verification of the holder, for example, based on the holder's public key. Subsequently, in step S1206, if the result of the holder's identity verification is approved, the various encrypted VC data 1304 using the holder's private key is sent to the user terminal 110 as encrypted VC data. Subsequently, in step S1208, if the result of the holder's identity verification is approved, the digital currency wallet provider 150 of the issuer server sends encrypted VC data 1306 relating to the holder's wallet account VC to the user terminal 110 as encrypted VC data.

[0122] Next, in step S1210, the digital ID wallet provider 115 of the user terminal 110 stores the encrypted VCs received from the digital currency wallet provider 150 of the issuer server in the VC data storage unit 660. Subsequently, in step S1212, the digital ID wallet provider 115 sends the settlement VP data 1308 to the merchant settlement terminal 170 based on the settlement VC selection result by the holder.

[0123] Next, in step S1214, the merchant-side payment terminal 170 stores the payment VP received from the user terminal 110 in the VC verification storage unit 1060. Subsequently, in step S1216, the payment terminal 170 sends the payment VP verification request data 1310 to the payment provider 160 on the verifier-side server. Subsequently, in step S1218, the payment provider 160 stores the payment VP verification request data 1310 received from the payment terminal 170 in the payment data storage unit 954.

[0124] (During payment processing) Subsequently, as the settlement stage in which the holder enters into a purchase agreement for goods / services at the merchant, settlement processing is carried out between the holder and the merchant. Specifically, as shown in Figures 12 and 13, in step S1220, if the settlement provider 160 on the verifier side server approves the verification result of the settlement VP received from the merchant side settlement terminal 170, it sends the electronic invoice data 1312 / 1314 to the settlement terminal 170 or the user terminal 110. Then, in step S1222, the settlement terminal 170 stores the electronic invoice data 1312 received from the settlement provider 160 in the VC verification storage unit 1060 and sends the electronic invoice data 1314 to the user terminal 110.

[0125] Next, in step S1224, the digital ID wallet provider 115 of the user terminal 110 stores the electronic invoice data 1314 received from the payment provider 160 of the verifier server or the merchant payment terminal 170 in the VC data storage unit 660. Subsequently, in step S1226, the digital ID wallet provider 115 sends the electronic check data 1316 / 1318 corresponding to the electronic invoice data 1314 to the payment provider 160 or the payment terminal 170.

[0126] Next, in step S1228, the merchant-side payment terminal 170 stores the electronic check data 1316 received from the user terminal 110 in the VC verification storage unit 1060 and transmits the electronic invoice data 1318 to the payment provider 160 on the verifier-side server. Subsequently, in step S1230, the payment provider 160 stores the electronic invoice data 1318 received from either the user terminal 110 or the payment terminal 170 in the payment data storage unit 954.

[0127] Next, in step S1232, the payment provider 160 on the validator server identifies the payment method (e.g., credit card payment, stablecoin payment, etc.) based on the electronic invoice data 1318, and then sends the payment request data 1320 to the digital currency wallet provider 150 on the issuer server. Subsequently, in step S1234, the digital currency wallet provider 150 checks the user balance in the holder's wallet account based on the payment request data 1320 received from the payment provider 160, and if the balance exceeds the payment amount, generates payment transaction data.

[0128] Next, in step S1236, the digital currency wallet provider 150 on the issuer server sends user signature request data 1332 for the newly generated settlement transaction data to the user terminal 110. Subsequently, in step S1238, the digital currency wallet provider 120 on the user terminal 110 verifies the authenticity of the user signature request data 1332 received from the digital currency wallet provider 150. If the verification of the user signature request data 1332 is approved, it sends user signature approval data 1324 to the digital currency wallet provider 150.

[0129] Next, in step S1240, the digital currency wallet provider 150 on the issuer server transmits settlement result data 1326 to the settlement provider 160 on the verifier server based on the user signature approval data 1324 received from the user terminal 110. Subsequently, in step S1242, the settlement provider 160 stores the settlement result data 1326 received from the digital currency wallet provider 150 in the settlement data storage unit 954 and transmits the electronic receipt data 1328 / 1330 to the merchant settlement terminal 170 or the user terminal 110.

[0130] Next, in step S1246, the merchant-side payment terminal 170 stores the electronic receipt data 1328 received from the payment provider 160 on the verifier-side server in the VC verification storage unit 1060, and also transmits the electronic receipt data 1330 to the user terminal 110. Subsequently, in step S1248, the user terminal 110 stores the electronic invoice data 1330 received from the payment provider 160 or the payment terminal 170 in the VC data storage unit 760.

[0131] Next, in step S1250, the issuer server's digital currency wallet provider 150 locks the user balance in the holder's wallet account (unlocking occurs after the transaction is registered to the blockchain network), The settlement transaction data 1332 is sent to the digital currency settlement infrastructure 180. Subsequently, in step S1252, the digital currency settlement infrastructure 180 stores the transaction record of the cryptocurrency as a transaction and the associated transaction information (invoice and receipt) on the same on-chain, based on the settlement transaction data 1332 received from the digital currency wallet provider 150.

[0132] [Effects of the Embodiment] Thus, according to embodiments of the present invention, in a digital currency settlement platform, transaction information (invoices and receipts) is converted into a Delivery Versus Payment (VP), and the transaction record of the cryptocurrency as a transaction, along with the associated transaction information, is stored on the same on-chain. This makes it possible to provide on-chain DVP settlements to service users such as businesses, users, and regulatory authorities, ensuring transparency of transaction details and improving consumer convenience.

[0133] While the principles of the present invention have been described above with reference to exemplary embodiments, those skilled in the art should understand that various embodiments can be realized with modifications in configuration and details without departing from the spirit and scope of the invention. That is, the present invention can take various forms, such as systems, apparatus, methods, programs, or storage media. [Explanation of symbols]

[0134] 100 communication lines 110 user terminals 115 Holder-side device: Digital ID wallet provider 120 Holder-side device: Digital currency wallet provider 130 Issuer-side server: Digital ID wallet provider 140 Issuer-side server: Payment provider 142 Issuer-side server: Identity verification provider 144 Issuer Server: Points Member Provider 150 Issuer-side server: Digital currency wallet provider 160 Verifier Server: Payment Provider 170 Merchant-side payment terminals 180 Digital Currency Payment Platform 200 System Bus 210 Control Unit 212 Main memory 214 Input section 216 Output section 218 Communication Interface Section 220 Auxiliary storage section 230 VC Management Department 232 VC Publishing Department 234 Transaction Management Department 236 Customer Data Management Department 238 Limit Management Department 240 VC encryption section 250 Customer data storage unit 252 Card-related data storage unit 254 VC Management Data Storage Unit 256 Program Storage Unit 300 System Bus 310 Control Unit 312 Main memory 314 Input section 316 Output section 318 Communication Interface Section 320 Auxiliary storage 330 VC Management Department 332 VC Publishing Department 334 Transaction Management Department 336 Customer Data Management Department 338 VC encryption section 350 Customer data storage unit 352 Personal Data Storage Unit 354 VC Management Data Storage Unit 356 Program Storage Unit 400 System Bus 410 Control Unit 412 Main memory 414 Input section 416 Output section 418 Communication Interface Section 420 Auxiliary storage 430 VC Management Department 432 VC Publishing Department 434 Transaction Management Department 436 Customer Data Management Department 438 VC encryption section 450 Customer Data Storage Unit 452 Member-related data storage unit 454 VC Management Data Storage Unit 456 Program Storage Unit 500 System Bus 510 Control Unit 512 Main memory 514 Input section 516 Output section 518 Communication Interface Section 520 Auxiliary storage 530 VC Management Department 532 VC Publishing Department 534 Transaction Management Department 536 Customer Data Management Department 538 VC encryption section 550 Customer Data Storage Unit 552 Wallet-related data storage unit 554 VC Management Data Storage Unit 556 Program Storage Unit 600 System Bus 610 Control Unit 612 Main memory 614 Input section 616 Display section 618 Output section 620 Communication Interface Section 630 Auxiliary storage 640 VC Management Department 642 VC Publishing Department 644 Transaction Management Department 646 Customer Data Management Department 648 Verification VP Output Section 650 Secure Elements 660 VC data storage unit 700 System Bus 710 Control Unit 712 Main memory 714 Input section 716 Output section 718 Communication Interface Section 720 Auxiliary storage 730 VC Verification Request Receiving Department 732 VC Verification Department 734 Transaction Management Department 736 Verification VC Selection Section 738 Verification VP Output Section 750 External Servers 760 VC data storage unit 800 System Bus 810 Control Unit 812 Main memory 814 Input section 816 Display section 818 Output section 820 Communication Interface Section 830 Auxiliary storage unit 840 Wallet Address Management Department 842 Transaction Management Department 850 Secure Element 860 Wallet-related data storage unit 900 System Bus 910 Control Unit 912 Main memory 914 Input section 916 Output section 918 Communication Interface Section 920 Auxiliary storage 930 VC Verification Output Unit 932 VC Verification Department 934 Transaction Management Department 936 Verification VC Judgment Unit 938 Payment Data Calculation Department 940 Invoice and Receipt Issuance Department 942 VC Management Department 944 VC Publishing Department 950 Customer Data Storage Unit 952 Member-related data storage unit 954 Payment Data Storage Unit 956 Merchant Data Storage Unit 958 Program Storage Unit 1000 System Bus 1010 Control Unit 1012 Main memory 1014 Input section 1016 Display section 1018 Printing Department 1020 Output section 1022 Communication Interface Section 1030 Auxiliary storage 1040 Payment Processing Control Unit 1042 VC Verification Control Unit 1044 VC Verification Record Management Department 1046 Attribute information management department 1048 Membership Information Management Department 1050 Transaction Management Department 1060 VC Verification Storage Unit 1062 Attribute information storage unit 1064 Membership Card Information Storage Unit

Claims

1. A settlement system that settles a sales contract between an issuer with a payment brand and a business contract, a holder who is a member of the payment brand, and a verifier with a transaction contract with the payment brand, at a merchant with a merchant agreement with the verifier, based on the verifier's verification results of the credentials provided by the holder, the merchant settles the sales contract between the holder and the merchant. A first payment provider, installed on the issuer's side and configured to determine the issuance of the credentials to provide them to the user terminal as verifiable credentials (VC) based on a request from the user terminal used by the holder, A digital ID wallet provider configured to manage the VC issued by the first payment provider based on instructions from the user terminal, and to issue encrypted verifiable presentations (VPs) generated from the VC based on instructions from the user terminal, A payment terminal installed at the aforementioned merchant and configured to request settlement processing for the sales contract based on the verification results for the encrypted VP issued by the digital ID wallet provider, A second payment provider is installed on the verifier side and configured to verify the VP provided from the payment terminal and then issue a payment request to execute the payment processing requested from the payment terminal, A first digital currency wallet provider is installed on the issuer side and configured to generate a settlement transaction based on the settlement request issued by the second settlement provider and to send the settlement transaction to the digital currency settlement platform. Equipped with, The settlement transaction is a transaction configured to allow the registration of the transaction record of the sales contract relating to the encrypted VP and the transaction information associated with the transaction record to the digital currency settlement platform. A payment system characterized by the following features.

2. The payment system according to claim 1, characterized in that the digital ID wallet provider is configured as part of a payment service agent application installed on the user terminal and manages the VC using a secure element built into the user terminal, or is configured as a server installed on the issuer side and manages the VC using a database in an external server separate from the server.

3. The first payment provider is configured as a group of servers installed on the issuer's side, and the group of servers is configured to issue credit card account VCs, identity verification VCs, and point member VCs related to the holder to the digital ID wallet provider, respectively, and includes a payment provider, an identity verification provider, and a point member provider. The first digital currency wallet provider is configured to issue a wallet account VC relating to the holder's digital currency account, issued from the digital currency settlement platform, to the digital ID wallet provider. The payment system according to claim 1, characterized in that...

4. The settlement system according to claim 3, characterized in that the digital ID wallet provider issues an electronic check to the second settlement provider as the encrypted VP via the user terminal, and the electronic check includes the wallet account VC relating to the sales contract, the identity verification VC, and the points member VC.

5. The payment system according to claim 1, wherein the second payment provider issues an electronic invoice to the digital ID wallet provider as an encrypted VP, and the electronic invoice includes the merchant identifier and signature, the payment amount of the sales contract, the purchase data of the sales contract, the applicable tax rate and consumption tax amount for the purchase data, and the qualified invoice business number.

6. The payment system according to claim 1, wherein the second payment provider issues an electronic receipt to the digital ID wallet provider as an encrypted VP, the electronic receipt includes the merchant identifier and signature, the payment amount of the sales contract, the purchase data of the sales contract, the applicable tax rate and consumption tax amount for the purchase data, and the qualified invoice business number.

7. A second digital currency wallet provider is configured as part of a payment service agent application installed on the user terminal, and is configured to verify the authenticity of the payment transaction based on a signature request issued by the first digital currency wallet provider, and to approve the holder's user signature based on the verification result for the payment transaction. The payment system according to claim 1, further comprising the following:

8. The digital currency settlement platform is a settlement platform for maintaining accurate financial transaction history based on distributed ledger technology using blockchain, and the distributed ledger technology is characterized in that it stores transaction history in units called blocks, linked together as a single chain from the past to the present using cryptographic technology, as described in claim 1.

9. The settlement system according to claim 1, characterized in that the digital currency settlement infrastructure is a platform for using digital currency for settlement, which includes any one of stablecoins, central bank digital currencies, or tokenized deposits.

10. A settlement method for executing the settlement process of a sales contract in a settlement system that handles a sales contract between a holder and a merchant, based on the verification results by the verifier against the credentials provided by the holder, in a settlement scenario spanning between an issuer with a payment brand and a business contract with the payment brand, a holder who is a member of the payment brand, and a verifier with a transaction contract with the payment brand, wherein the merchant has a merchant agreement with the verifier, and the merchant handles the sales contract between the holder and the merchant, the settlement method for executing the settlement process of the sales contract, A first payment provider installed on the issuer's side determines, based on a request from a user terminal used by the holder, whether to issue the credentials to provide them to the user terminal as verifiable credentials (VC), In a digital ID wallet provider that manages the VC issued by the first payment provider based on instructions from the user terminal, the steps include issuing an encrypted verifiable presentation (VP) generated from the VC based on instructions from the user terminal, The steps include: requesting verification of the encrypted VP issued by the digital ID wallet provider at the payment terminal installed in the merchant; The steps include: a second payment provider installed on the verifier's side verifies the VP provided from the payment terminal and provides the verification result of the VP to the payment terminal; The payment terminal includes the step of requesting payment processing for the sales contract based on the verification results of the VP provided by the second payment provider, The second payment provider includes the step of issuing a payment request in order to execute the payment processing requested from the payment terminal, The first digital currency wallet provider installed on the issuer's side generates a settlement transaction based on the settlement request issued by the second settlement provider and sends the settlement transaction to the digital currency settlement platform. Equipped with, The settlement transaction is a transaction configured to allow the registration of the transaction record of the sales contract relating to the encrypted VP and the transaction information associated with the transaction record to the digital currency settlement platform. A payment method characterized by the following features.

Images