Settlement system employing VP transaction details and digital currency settlement platform, and method for same

Abstract

The present invention provides a settlement system and a method thereof so as to issue a qualified invoice and a qualified receipt and make validity and availability of payment information and transaction information verifiable. A first settlement provider on an issuer side issues a credential of a holder to a user terminal as a VC. A digital ID wallet provider issues an encrypted VP generated from the VC. A settlement terminal on a member shop side requests a second settlement provider on a verifier side to verify the encrypted VP. The second settlement provider provides a verification result of the encrypted VP to the settlement terminal. The settlement terminal requests the second settlement provider to perform settlement processing based on the verification result of the encrypted VP. The second settlement provider issues a settlement request so as to execute the settlement processing. A digital currency wallet provider on the issuer side generates a settlement transaction based on the settlement request and transmits the settlement transaction to a digital currency settlement infrastructure.

Description

Payment system and method using VP-converted transaction details and a digital currency settlement platform.

[0001] The present invention relates to a payment service that utilizes transaction details (including information such as invoices and receipts) as a verifiable presentation (VP) generated from verifiable credentials (VC). More specifically, the present invention relates to a payment system and method for storing VP-formatted transaction details on a digital currency payment platform in a cashless payment scenario between a holder, issuer, and verifier related to a VC.

[0002] With the development of various commercial transaction settlement areas, payment methods are also rapidly changing and diversifying. Regarding digital currencies, which are currencies used for electronic payments rather than banknotes or coins, central bank digital currencies (CBDCs), tokenized deposits (TDs), and stablecoins (SCs), utilizing distributed ledger technology (DLTs) such as blockchain (BCs), are being put into practical use. On such payment infrastructures, intangible and tangible real assets or rights, such as stocks, bonds, real estate, works of art, precious metals, and carbon credits, are represented on the blockchain as tokenized assets (TAs).

[0003] In particular, in the case of stablecoins, which are fiat-backed digital currencies, the issuance volume has been growing significantly, and the scale and diversity of tokenized assets targeted for circulation have been expanding. As a result, a foundation for realizing direct circulation via digital currency, that is, decentralized finance, has been established, and the formation of a new investment and currency ecosystem is progressing. Thus, in initiatives where assets, content, rights, etc. are tokenized, while on-chain settlement and circulation become directly possible, improvements in the efficiency of existing financial functions or the creation of use cases with new financial functions are expected.

[0004] In such decentralized finance, in the case of smart contracts, a mechanism in which contracts are automatically executed without an intermediary, while the advantages in terms of convenience or cost increase, there is also a situation where the need to confirm predetermined conditions to be satisfied for smooth negotiation or verification of the contract becomes higher. For example, Patent Document 1 discloses a settlement system for executing smart contracts for stablecoins as highly liquid cryptocurrency assets.

[0005] Japanese Patent No. 7209984

[0006] However, several problems have been pointed out in the settlement system disclosed in Patent Document 1, and the need for countermeasures as follows has emerged. For example, in stablecoin settlement, only "when, who, to whom, and how much was paid" will be registered on the blockchain. From the perspective of regulatory authorities, in terms of anti-money laundering and countering the financing of terrorism (AML / CFT), it is desirable that it be possible to match and verify payment information and 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.

[0009] To solve the above problems, in one aspect of the present invention, a payment system is provided as a payment 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. The system enables the settlement of 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, and comprises the following components. Specifically, (1) a first payment provider installed on the issuer side and configured to determine the issuance of credentials to provide the user terminal as verifiable credentials (VC) based on a request from the user terminal used by the holder; (2) 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 (VP) generated from the VC based on instructions from the user terminal; (3) a payment terminal installed at the merchant and configured to request settlement processing for a sales contract based on the verification results of the encrypted VP issued by the digital ID wallet provider; (4) a second payment provider installed on the verifier side and configured to issue a settlement request to execute the settlement processing requested by the payment terminal after verifying the VP provided by the payment terminal; and (5) a first digital currency wallet provider installed on the issuer side and configured to generate a settlement transaction based on a settlement request issued by the second payment provider and to send the settlement transaction to the digital currency settlement infrastructure.

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

[0011] The system further comprises the following components: (6) a second digital currency wallet provider configured as part of a payment service agent application 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 the VC using a secure element built into the user terminal, or it is configured as a server installed on the issuer's side and manages the VC 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, an identity verification VC, and a points member VC relating to the sales contract.

[0015] Furthermore, in this system, the second payment provider issues an electronic invoice as an encrypted VP to the digital ID wallet provider, 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 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, 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. Specifically, the steps are: (1) 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 credentials as verifiable credentials (VC) to the user terminal; (2) a digital ID wallet provider managing the VC issued by the first payment provider based on instructions from the user terminal issues an encrypted verifiable presentation (VP) generated from the VC based on instructions from the user terminal; (3) a payment terminal installed at the merchant requests verification of the encrypted VP issued by the digital ID wallet provider; (4) a second payment provider installed on the verifier's side verifies the VP provided by the payment terminal and provides the payment terminal with the verification result of the VP; (5) a payment terminal requests settlement processing for a sales contract based on the verification result of the VP provided by the second payment provider; (6) a second payment provider issues a settlement request in order to execute the settlement processing requested by the payment terminal; and (7) A first digital currency wallet provider installed on the issuer's side generates a settlement transaction based on a settlement request issued by a second settlement provider and sends the settlement transaction to the digital currency settlement platform.

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

[0021] According to the present invention, in a digital currency infrastructure, transaction information (invoices and receipts) is converted into VP (Virtual Value), and transaction records of crypto assets as transactions, along with the associated transaction information, are stored on the same on-chain. This makes it possible to provide on-chain Delivery Versus Payment (DVP) settlements to service users such as businesses, users, and regulatory authorities, ensuring transparency of transaction content and improving consumer convenience.

[0022] A detailed understanding of the embodiments disclosed herein can be obtained from the following description illustrated in relation to the accompanying drawings.

[0023] Figure 1A is a configuration diagram showing the connection configuration of a payment system according to an embodiment of the present invention. Figure 1B is a diagram showing the configuration of a basic model relating to the payment system shown in Figure 1A. Figure 1C is a configuration diagram showing an alternative configuration of the payment system shown in Figure 1A. Figure 2A is a configuration diagram showing the internal configuration of the payment provider 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 in the payment provider shown in Figure 2A. Figure 3A is a configuration diagram showing the internal configuration of the identity verification provider 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 in the payment provider shown in Figure 3A. Figure 4A is a configuration diagram showing the internal configuration of the points member provider 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 points member VC data in the points member provider shown in Figure 4A. Figure 5A is a configuration diagram showing the internal configuration of the digital currency wallet provider 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 in the digital currency wallet provider shown in Figure 5A. Figure 6A is a configuration diagram showing the internal configuration of the holder-side terminal's digital ID wallet provider function in the payment system shown in Figure 1A. Figure 6B is a table showing an example of the configuration of wallet account VC data in the digital ID wallet provider shown in Figure 6A. Figure 7A is a configuration diagram showing the internal configuration of the issuer-side server's digital ID wallet provider in the payment system shown in Figure 1B. Figure 7B is a table showing an example of the configuration of wallet account VC data in the digital ID wallet provider shown in Figure 7A. Figure 8 is a configuration diagram showing the internal configuration of the holder-side terminal's digital currency wallet provider function in the payment system shown in Figure 1A. Figure 9A is a configuration diagram showing the internal configuration of the verifier-side server's payment provider in the payment system shown in Figure 1A. Figure 9B is a table showing example configurations of wallet account VC data (payment input data) and electronic invoice / electronic receipt VC data (payment output data) in the payment provider shown in Figure 9A.Figure 10 is a configuration diagram showing the internal configuration of the merchant-side payment terminal in the payment system shown in Figure 1A. Figure 11A is a table showing an example configuration of a payment VP as detailed data for a VP request (stablecoin payment) in the payment system shown in Figure 1A. Figure 11B is a table showing an example configuration of a payment VP as detailed data for a VP request (credit card payment) in the payment system shown in Figure 1A. Figure 12 is a flowchart showing the payment process in the payment system shown in Figure 1A. Figure 13 is a linkage diagram showing the various data flows across different systems included in the payment process shown in Figure 12.

[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 unless they appear for the first time.

[0025] [Connection Configuration 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 relating to 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 to 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 enable 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 functions 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 security functions externally 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 security functions externally 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 concluded 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, thereby supporting payments for purchases of goods or services by the customer (holder). 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 cardholder as a customer.

[0040] Furthermore, the tokens circulating on the digital currency settlement 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 (virtual currencies) 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 settlement 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] [Model Configuration of the Payment System] Figure 1B is a diagram showing 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 corresponding 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 qualification information is configured as follows, for example. That is, (1) information related to the identification of the subject of the qualification information (e.g., the identification number of the subject, etc.), (2) information related to the issuing authority (e.g., the identification number of the financial institution, etc.), (3) information related to the type of the qualification information (e.g., credit card, digital currency wallet, etc.), (4) information related to the specific attributes or characteristics claimed by the issuing authority about the subject (e.g., date of birth, address, etc.), (5) evidence regarding the derivation method of the qualification information (e.g., My Number card, etc.), (6) information related to the restrictions of the qualification information (e.g., expiration date, usage conditions, etc.), and so on.

[0043] More specifically, the VC issued from the settlement provider 140 and the digital currency wallet provider 150 of the issuer side server to the holder side 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 different electronic signatures (e.g., digital signatures based on the public key cryptosystem, etc.) to each individual piece of information (claim) included in the qualification information (credential), and then constructs the encrypted VC based on different encryption keys.

[0044] In the settlement scenario, when the settlement provider 160 of the verifier side server sends an electronic invoice to the user terminal 110 to request the holder's VP, the digital ID wallet provider 115 in the user terminal 110 sends an electronic check (including wallet account VC, identity verification VC, point membership VC, etc.) to the settlement provider 160 to prove the qualification by the encrypted VP generated from the encrypted VC in the data registry. Note that in order to present only the minimum necessary qualification information about the holder to the verifier, which is the qualification information required for the verification of the VC, that is, to generate the optimal VP from the presentable VC, techniques such as zero-knowledge proof (ZKP) are applied.

[0045] At this time, the verifier side verifies the validity of the Credential Proof using the decryption key of the holder for the provided VC. The verification content is configured as follows, for example. That is, (1) to confirm the issuer of the Credential Proof, (2) to confirm the owner of the Credential which is the element of the Credential Proof, (3) to confirm each piece of information (Claim) included in the Credential, (4) to confirm that the Credential has not expired (the expiration date of the Credential is not due), etc.

[0046] Next, when the settlement provider 160 of the verifier side server sends a settlement request to the issuer side server, the digital currency wallet provider 150 of the issuer side server generates a settlement transaction and then sends a signature request for the settlement transaction to the user terminal 110 of the holder. After that, 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 of the issuer side server sends a settlement approval result to the verifier side server, the settlement provider 160 of the verifier side server sends an electronic receipt (including the receipt VP, etc.) to the user terminal 110 of the holder in order to complete the settlement by the encrypted VP. On the other hand, when the digital currency wallet provider 150 of the issuer side server sends the settlement transaction to the digital currency settlement infrastructure 180, the digital currency settlement infrastructure 180 registers the payment information and the associated transaction information as a settlement transaction as blocks on the blockchain.

[0048] [Internal Configuration of the Settlement Provider of the Issuer Side Server] FIG. 2A is a configuration diagram showing the internal configuration of the settlement provider 140 of the issuer side server in the settlement system shown in FIG. 1A. FIG. 2B is a table showing a configuration example of the credit card account VC data stored in the card-related data storage unit 252 in the settlement provider 140 shown in FIG. 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 IF (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 for 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, the communication IF unit 218, and the 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 between the holder's user terminal 110, the issuer's server's digital currency wallet provider 150, the verifier's server's payment provider 160, 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 an encrypted VC and delivers it 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 (owner), such as customer ID, name, address, telephone number, email address, gender, date of birth, withdrawal account, occupation, position, annual income, and family structure. The VC management data storage unit stores change information of the owner's qualification information, 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 Issuer-Side Server Identity Verification Provider] Figure 3A is a configuration diagram showing the internal configuration of the issuer-side server identity verification provider 142 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, and supports processing functions related to the task of managing identity verification information among the holder's credentials, and determines whether to issue a certificate to provide that credentials as a VC to the user terminal 110. 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 storage 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 includes 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-enhanced credentials and stores the related information in the VC management data storage unit 354. The VC issuance unit 332 issues the holder's VC-enhanced 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 against the holder's credentials stored in the personal information storage unit 352 to generate an encrypted VC and delivers it 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 Point Member Provider on the Issuer's Server] Figure 4A is a configuration diagram showing the internal configuration of the point member provider 144 on the issuer's server in the payment system shown in Figure 1A. Figure 4B is a table showing an example of the configuration of the 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, and supports processing functions related to the task of managing point member information among the holder's credentials, and determines whether to issue the credentials to be provided 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 so as to be able to communicate with each other via the system bus 400. 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 includes 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-enhanced credentials and stores the related information in the VC management data storage unit 454. The VC issuance unit 432 issues the holder's VC-enhanced credentials to the user terminal 110. The transaction management unit 434 manages the execution of the indivisible series of 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 to be 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's 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, and supports processing functions related to managing wallet account information among the holder's credentials, and determines whether to issue a VC to provide that credentials to the user terminal 110. 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 so as to be able to communicate with each other via the system bus 500. 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-out 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 generate an encrypted VC and delivers it 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 the generation of encrypted VCs by the VC encryption unit 538 is performed using the holder's encryption key stored in the customer data storage unit 550 when a managed wallet is assumed, but when a self-managed wallet is assumed, 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 of the Holder-Side User Terminal] Figure 6A is a configuration diagram showing the internal configuration of the functions 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 servers 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 storage 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 to 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 payment VC from the merchant-side payment terminal 170, it receives it as a request for payment VC verification and outputs the payment VP generated by the verification VC selection unit 646 to the verification VP output unit 648. The verification VP output unit 648 outputs the payment VP to the communication IF unit 620 in order to transmit the payment VP to the payment 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-side 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, such as 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's 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 in 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's 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 VC 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 memory 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 interface 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 payment VC from the merchant-side payment terminal 170 via the user terminal 110, it receives it as a request for payment VC verification and outputs the payment VP generated by the verification VC selection unit 736 to the verification VP output unit 738. The verification VP output unit 738 outputs the payment VP to the communication IF unit 720 in order to transmit the payment VP to the payment 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 payment VP by selecting a payment VC that limits the credentials included in the payment VC to the minimum necessary, in response to the payment VC requested from the merchant-side payment 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-Side User Terminal] Figure 8 is a configuration diagram showing the internal configuration of the digital currency wallet provider 120 function 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 determines 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 their details will not be explained again.

[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 processing results 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, encryption 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's 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 basically operate in the same way as the components of the issuer-side servers 140 to 150, so their details will not be explained again.

[0102] The auxiliary storage unit 920 contains 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, respectively. 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 includes 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 from the merchant-side payment terminal 170 to verify the payment VC, 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 Verified VC Determination Unit 936 further verifies that the settlement VC, which has been verified as valid by the VC Verification Unit 932, meets the requirements necessary for settlement processing, and instructs the unit to proceed to settlement processing. Upon receiving instructions from the Verified VC 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 can store, for example, as input data for settlement processing, the type of settlement method, issuer identifier, issuer / issuing service name, recipient of settlement request, wallet address, expiration date, issuer signature, etc., as shown in the upper part of Figure 9B. The settlement data storage unit 954 also stores, for example, as output data for settlement processing, the 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 (corporate settlement), payer name (corporate settlement), payment status (invoice / receipt), invoice number, etc., as shown in the lower part of Figure 9B.

[0109] [Internal Configuration of Merchant-Side Payment Terminal] 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 payment provider 160 on the verifier-side server, 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 IF 1022, and auxiliary storage unit 1030 are interconnected via the system bus 1000 so that they can communicate with each other. Except for the display unit 1016 and the 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 staff of the affiliated store, 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 data to be printed, and as a result, receipts showing accounting details or receipts showing settlement results are ejected from the printer output as sheets of paper separated 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 includes 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 transmits 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, transmits 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 payment VP in stablecoin payments, as detailed data of the VP request in the payment system shown in Figure 1A. The payment 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 transmitted to the payment provider 160 on the verifier-side server via the merchant-side payment terminal 170. Here, one payment 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 payment provider 160 on the verifier-side server and then transmitted to the holder-side user terminal 110 via the merchant-side payment 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 credit card payments, 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 transmitted 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 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 various systems included in the payment process shown in Figure 12.

[0120] (During VC verification) As a preliminary step to the settlement where the holder enters into a purchase contract for goods / services at the merchant, the holder's VC verification is performed. In step S1200, when the merchant staff receives a settlement request from the holder and instructs the settlement terminal 170 to start the settlement, the merchant-side settlement terminal 170 requests the holder-side user terminal 1100 to issue a settlement 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 settlement terminal 170, it sends VC issuance request data 1302 to the various providers 140 to 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 digital currency wallet provider 150 of the issuer server approves the holder's identity verification, it 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 transmits the payment VP data 1308 to the merchant payment terminal 170 based on the holder's selection of the payment VC.

[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 transmits 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 settlement processing) After this, settlement processing is carried out between the holder and the merchant as the settlement stage in which the holder enters into a purchase contract for goods / services at 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. Subsequently, 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 transmits 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 verifier 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 issuer server's digital currency wallet provider 150 transmits settlement result data 1326 to the verifier server's payment provider 160 based on the user signature approval data 1324 received from the user terminal 110. Subsequently, in step S1242, the payment provider 160 stores the settlement result data 1326 received from the digital currency wallet provider 150 in the payment data storage unit 954 and transmits the electronic receipt data 1328 / 1330 to the merchant payment 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-side 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), and then sends the settlement transaction data 1332 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, along with 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] As described above, according to the embodiment of the present invention, in a digital currency settlement platform, transaction information (invoices and receipts) is converted into VP, and the transaction record of the crypto asset as a transaction, along with the transaction information associated therewith, is stored on the same on-chain. This makes it possible to provide on-chain DVP (Delivery Versus Payment) settlements to service users such as businesses, users, and regulatory authorities, which ensure transparency of transaction content and improve 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.

[0134] 100 Communication line 110 User terminal 115 Holder-side terminal: Digital ID wallet provider 120 Holder-side terminal: 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-side server: Point member provider 150 Issuer-side server: Digital currency wallet provider 160 Verifier-side server: Payment provider 170 Merchant-side payment terminal 180 Digital currency payment infrastructure 200 System bus 210 Control unit 212 Main memory unit 214 Input unit 216 Output unit 218 Communication IF unit 220 Auxiliary memory unit 230 VC management unit 232 VC issuance unit 234 Transaction management unit 236 Customer data management unit 238 Limit management unit 240 VC encryption unit 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 unit 314 Input unit 316 Output unit 318 Communication IF unit 320 Auxiliary storage unit 330 VC management unit 332 VC issuance unit 334 Transaction management unit 336 Customer data management unit 338 VC encryption unit 350 Customer data storage unit 352 User-related data storage unit 354 VC management data storage unit 356 Program storage unit 400 System bus 410 Control unit 412 Main memory unit 414 Input unit 416 Output unit 418 Communication IF unit 420 Auxiliary storage unit 430 VC management unit 432 VC issuance unit 434 Transaction management unit 436 Customer Data Management Unit 438 VC Encryption Unit 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 Unit 514 Input Unit 516 Output Unit 518 Communication IF Unit 520 Auxiliary Storage Unit530 VC Management Unit 532 VC Issuance Unit 534 Transaction Management Unit 536 Customer Data Management Unit 538 VC Encryption Unit 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 Unit 614 Input Unit 616 Display Unit 618 Output Unit 620 Communication IF Unit 630 Auxiliary Storage Unit 640 VC Management Unit 642 VC Issuance Unit 644 Transaction Management Unit 646 Customer Data Management Unit 648 Verification VP Output Unit 650 Secure Element 660 VC Data Storage Unit 700 System Bus 710 Control Unit 712 Main Memory Unit 714 Input Unit 716 Output Unit 718 Communication IF Unit 720 730 Auxiliary Storage Unit 730 VC Verification Request Receiving Unit 732 VC Verification Unit 734 Transaction Management Unit 736 Verification VC Selection Unit 738 Verification VC Output Unit 750 External Server 760 VC Data Storage Unit 800 System Bus 810 Control Unit 812 Main Storage Unit 814 Input Unit 816 Display Unit 818 Output Unit 820 Communication IF Unit 830 Auxiliary Storage Unit 840 Wallet Address Management Unit 842 Transaction Management Unit 850 Secure Element 860 Wallet Related Data Storage Unit 900 System Bus 910 Control Unit 912 Main Storage Unit 914 Input Unit 916 Output Unit 918 Communication IF Unit 920 Auxiliary Storage Unit 930 VC Verification Issuance Unit 932 VC Verification Unit 934 Transaction Management Unit 936 Verification VC Judgment Unit 938 Settlement Data Calculation Unit 940 Invoice / Receipt Issuance Unit 942 VC Management Unit 944 VC Issuance Unit 950 Customer Data Storage Unit 952 Member-Related Data Storage Unit 954 Settlement Data Storage Unit 956 Merchant Data Storage Unit 958 Program Storage Unit 1000 System Bus 1010 Control Unit 1012 Main Memory Unit 1014 Input Unit 1016 Display Unit 1018 Printing Unit1020 Output Unit 1022 Communication IF Unit 1030 Auxiliary Storage Unit 1040 Settlement Processing Control Unit 1042 VC Verification Control Unit 1044 VC Verification Record Management Unit 1046 Attribute Information Management Unit 1048 Membership Card Information Management Unit 1050 Transaction Management Unit 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 a holder and a merchant at a merchant with a merchant agreement with the verifier, based on the verification results by the verifier of credentials provided by the holder, as a settlement scenario spanning between an issuer with a business contract with a payment brand, a holder who is a member of the payment brand, and a verifier with a transaction contract with the payment brand, comprising: a first settlement provider installed on the issuer side and configured to determine the issuance of credentials to provide the credentials 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 settlement provider based on instructions from the user terminal and to issue encrypted verifiable presentations (VP) generated from the VC based on instructions from the user terminal; and a settlement terminal installed at the merchant and configured to request settlement processing for the sales contract based on the verification results of the encrypted VP issued by the digital ID wallet provider. A settlement system comprising: a second settlement provider installed on the verifier side and configured to issue a settlement request in order to execute the settlement process requested by the settlement terminal after verifying the VP provided from the settlement terminal; and a first digital currency wallet provider installed on the issuer side and configured to generate a settlement transaction based on the settlement request issued by the second settlement provider and send the settlement transaction to a digital currency settlement platform, wherein the settlement transaction is a transaction configured to allow 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.

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 payment system according to claim 1, wherein the first payment provider is configured as a group of servers installed on the issuer side, and the group of servers includes a payment provider, an identity verification provider, and a points member provider, each configured to issue a credit card account VC, an identity verification VC, and a points member VC relating to the holder to the digital ID wallet provider, and 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 payment infrastructure to the digital ID wallet provider.

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, 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. The payment system according to claim 1, further comprising a second digital currency wallet provider configured as part of a payment service agent application installed on the user terminal, which 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.

8. The settlement system according to claim 1, wherein 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 linked together as a single chain from the past to the present in units called blocks using cryptographic technology.

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 settlement processing 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 of the credentials provided by the holder, in 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, the settlement method comprising: a first settlement provider installed on the issuer's side, which, based on a request from a user terminal used by the holder, determines whether to issue the credentials as verifiable credentials (VC) to the user terminal; a digital ID wallet provider that manages the VC issued by the first settlement provider based on instructions from the user terminal, which, based on instructions from the user terminal, issues an encrypted verifiable presentation (VP) generated from the VC; and a settlement terminal installed in the merchant, which requests verification of the encrypted VP issued by the digital ID wallet provider. A settlement method comprising: a second settlement provider installed on the verifier side verifying the VP provided from the settlement terminal and providing the verification result of the VP to the settlement terminal; a settlement terminal requesting settlement processing for the sales contract based on the verification result of the VP provided from the second settlement provider; a second settlement provider issuing a settlement request in order to execute the settlement processing requested from the settlement terminal; and a first digital currency wallet provider installed on the issuer side generating a settlement transaction based on the settlement request issued from the second settlement provider and sending the settlement transaction to a digital currency settlement platform, wherein the settlement transaction is a transaction configured to allow 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.