A payment system and method based on verifiable credentials.

Abstract

To provide a payment system and method based on verifiable credentials (VC) that enables fraud prevention, cardless payments, personal authentication schemes, privacy protection, and so on.SOLUTION: An issuer's VC management server determines whether to issue the holder's credentials as VC to a user terminal based on a request from a holder's user terminal. The data registry managing the VC based on the VC management server's instructions issues the VC to the user terminal based on the VC management server's determination result and the request from the user terminal. A merchant's payment terminal requests verification of the VC issued by the user terminal from a verifier's payment server. The payment server verifies the verifiable presentation (VP) based on the VC from the payment terminal and provides the VP verification result to the payment terminal. The payment terminal determines whether to request payment processing from the payment server based on the verification result from the payment server.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention relates to a payment service that realizes cashless payment based on the use of verifiable credentials (VCs). More specifically, the present invention relates to a payment system and method for supporting a cashless payment scenario among a holder, an issuer, and a verifier related to a VC based on the use of a verifiable presentation (VP) generated from the VC.

Background Art

[0002] In the payment area of commercial transactions across various industries, management of physical entities such as paper in the real world, for example, paper management of a driver's license, a My Number card, a credit card, a cash card, etc. is required. Therefore, if such physical paper or related voucher numbers or PINs are forged or stolen by fraudulent means, there is a risk of being misused by the thief as unauthorized use. Furthermore, in recent years, such fraudulent means have tended to become sophisticated and advanced, so especially in payment scenarios including electronic commerce (EC), there is an increasing concern about the increase in the above-mentioned risks.

[0003] On the other hand, a payment service that supports cashless payment has been developed in a cashless payment scenario without issuing a physical card to card members such as a credit card or a debit card. For example, Patent Document 1 discloses a technology for verifying a card member by presenting or inputting a "one-time debit number" presented from the issuer side to the service franchise side based on the management on the issuer side for validating and invalidating a time-limited payment approval number called a "one-time debit number". [Prior art documents] [Patent Documents]

[0004] [Patent Document 1] Japanese Patent Publication No. 2011-43983 [Overview of the project] [Problems that the invention aims to solve]

[0005] However, the payment service disclosed in Patent Document 1 has very limited usage patterns for verifying service users, making it difficult to utilize KYC (Know Your Customer) functions in a variety of payment scenarios. For example, from the perspective of personal authentication, there are concerns that it cannot accommodate diverse payment scenarios, such as expanding the scope of verification to include qualification information like a driver's license or My Number card, or limiting the disclosed information to only essential information such as age or address.

[0006] Therefore, in various cashless payment systems that are expected to develop in a multifaceted manner in the future, there was a problem in that it was not possible to provide service users with sufficient functionality, such as providing personal authentication to meet diverse requirements for various credentials, or protecting privacy through the selective disclosure of credentials, while maintaining fraud prevention in response to the cardless payment scenario.

[0007] The present invention was made to solve these problems and aims to provide a verifiable credential-based payment system and method that enables fraud prevention, cardless payment, personal authentication schemes, and privacy protection in merchants of cashless payment brands, in conjunction with cashless payment functions. [Means for solving the problem]

[0008] To solve the above problems, in one aspect of the present invention, a payment system is provided that enables settlement of a sales contract between a holder and a merchant based on the verification results by the verifier of the credentials provided by the holder, at a merchant that has a merchant agreement with the verifier, as a settlement scenario spanning between an issuer having a business contract with a payment brand, a holder who is a member of the payment brand, and a verifier having a transaction contract with the payment brand, and comprises the following components. That is, (1) A VC management server installed on the issuer's side, which determines the issuance of credentials to be provided to the user terminal as verifiable credentials (VC) based on a request from the user terminal used by the holder. (2) A data registry that manages VCs based on instructions from the VC management server and issues VCs to user terminals based on the judgment result of the VC management server and requests from user terminals. (3) A settlement server installed on the verifier side that verifies the verifiable presentation (VP) generated from the VC and then executes settlement processing for the sales contract, (4) A payment terminal installed at a merchant that, after requesting the payment server to verify the VC provided from the data registry via the user terminal, requests the payment server to process the payment based on the verification results for the VP.

[0009] In this system, the data registry is configured as a wallet management server installed on the issuer's side as a server-type wallet, or it is stored in a secure element built into the user's terminal as a client-type wallet.

[0010] Furthermore, the VP generated from the VC presents the verifier with the minimum necessary credentials regarding the holder required for VC verification, based on the Zero Knowledge Proof (ZKP) technique provided to the settlement server.

[0011] Furthermore, each individual piece of information (Claim) constituting the credentials in a VC is assigned a different digital signature and encrypted using a different encryption key. The digital signature is a digital signature based on public-key cryptography, and the VC is encrypted using the holder's private key and decrypted using the holder's public key. The private key is generated based on a distributed identifier (DID) produced by a function transformation of the holder's biometric information, and the public key is generated from the private key using elliptic curve cryptography. The DID is set to be different for each of the multiple payment services between the payment brand, issuer, and holder.

[0012] Furthermore, in order for the user terminal to access the data registry, authentication of the holder is performed by the payment service agent application installed on the user terminal. This authentication is performed to verify the holder's identity based on the FIDO authentication method applied to the holder's biometric information.

[0013] Furthermore, in one aspect of the present invention, in a settlement scenario spanning an issuer having a business contract with a payment brand, a holder who is a member of the payment brand, and a verifier having a transaction contract with the payment brand, a settlement system that handles a sales contract between a holder and a merchant having a merchant agreement with the verifier, based on the verification results by the verifier against the credentials provided by the holder, the method for verifying credentials before executing the settlement process for the sales contract comprises the following components: (1) A step in which a VC management server installed on the issuer's side determines whether to issue credentials to be provided to a user terminal as verifiable credentials (VC) based on a request from the user terminal used by the holder. (2) In a data registry that manages VCs based on instructions from the VC management server, the step of issuing a VC to a user terminal based on the determination result of the VC management server and a request from the user terminal, (3) A step in which the payment terminal installed at the merchant requests the payment server installed on the verifier side to verify the VC issued from the data registry via the user terminal, (4) The payment server verifies a verifiable presentation (VP) based on the VC provided from the payment terminal, and provides the verification result of the VP to the payment terminal, and (5) A step in which the payment terminal determines whether to request payment processing from the payment server based on the verification results provided by the payment server.

[0014] In this method, the data registry is configured as a wallet management server installed on the issuer's side as a server-type wallet system, or it is stored in a secure element built into the user's terminal as a client-type wallet system. [Effects of the Invention]

[0015] According to the present invention, in merchants affiliated with cashless payment brands, it is possible to provide service users with functionalities such as personal authentication to meet diverse requirements for various credentials, or privacy protection through selective disclosure of credentials, while maintaining the prevention of fraudulent use in cardless payment scenarios, in addition to supporting various cashless payment functions that are expected to develop in a wide range of applications in the future. [Brief explanation of the drawing]

[0016] A detailed understanding of the embodiments disclosed herein can be obtained from the following description illustrated in relation to the accompanying drawings. [Figure 1] This is a configuration diagram showing the connection configuration of a payment system according to an embodiment of the present invention. [Figure 2A] This figure shows the configuration of the basic model of the payment system shown in Figure 1. [Figure 2B] This table shows an example of the VC data structure when using a credit card as the payment method in the basic model shown in Figure 2A. [Figure 2C] This is a table showing an example of the configuration of VC data when using a debit card as a payment means in the basic model shown in FIG. 2A. [Figure 3A] This is a block diagram showing the internal configuration of the issuer-side VC management server in the payment system shown in FIG. 1. [Figure 3B] This is a table showing an example of the data configuration in the card-related data storage unit when the issuer is a credit company in the issuer-side VC management server shown in FIG. 3A. [Figure 3C] This is a table showing an example of the data configuration in the card-related data storage unit when the issuer is a bank in the issuer-side VC management server shown in FIG. 3A. [Figure 3D] This is a table showing an example of the data configuration in the card-related data storage unit when the issuer is a retail company in the issuer-side VC management server shown in FIG. 3A. [Figure 3E] This is a table showing an example of the data configuration in the card-related data storage unit when the issuer is a service company in the issuer-side VC management server shown in FIG. 3A. [Figure 4] This is a block diagram showing the internal configuration of the issuer-side wallet management server in the payment system shown in FIG. 1. [Figure 5] This is a block diagram showing the internal configuration of the holder-side user terminal in the payment system shown in FIG. 1. [Figure 6A] This is a block diagram showing the internal configuration of the verifier-side payment server in the payment system shown in FIG. 1. [Figure 6B] This is a table showing an example of the data configuration in the member-related data storage unit in the verifier-side payment server shown in FIG. 6A. [Figure 6C] This is a table showing an example of the data configuration in the payment data storage unit in the verifier-side payment server shown in FIG. 6A. [Figure 7] This is a block diagram showing the internal configuration of the merchant-side payment terminal in the payment system shown in FIG. 1. [Figure 8A] This is a flowchart showing the payment process in the payment system shown in FIG. 1. [Figure 8B] Figure 8A is a diagram illustrating the various data and operation / display flows across different systems included in the payment process. [Figure 9A] Figure 1 is a flowchart showing the identity verification (new registration) process in the payment system. [Figure 9B] Figure 9A is a diagram illustrating the various data and operation / display flows across different systems included in the identity verification (new registration) process. [Figure 10A] This is a flowchart showing the key pair registration process, which is included in the various processes shown in Figure 8A or 9A. [Figure 10B] Figure 10A is a diagram illustrating the various data and operation / display flows across different systems included in the key pair registration process. [Figure 11A] This flowchart shows the case where the settlement process shown in Figure 8A includes the generation of VC for settlement (offline). [Figure 11B] Figure 11A is a diagram illustrating the various data and operation / display flows across different systems included in the payment VC generation (offline) process. [Figure 12A] Figure 8A is a flowchart showing the case where the settlement process includes the generation of VC for settlement (online). [Figure 12B] Figure 12A is a diagram illustrating the various data and operation / display flows across different systems included in the online payment VC generation process. [Modes for carrying out the invention]

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

[0018] [Connection method of payment system] Figure 1 is a configuration diagram showing the connection configuration of a payment system according to one embodiment of the present invention. In Figure 1, a scenario is envisioned in which a holder (customer) 110, who is a member of a 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, at a merchant (e.g., a retail store) 160 that has a merchant agreement with a verifier (e.g., a payment processing company) that has a transaction agreement with at least one payment institution of various cashless payment brands.

[0019] In particular, in the pre-payment processing stage, when verifying the eligibility or identity of the holder 110, the certificate issued by the VC management server 130 and wallet management server 140 on the issuer's (e.g., financial institution) side, triggered by an operation on the user terminal 120 used by the holder 110, is provided by the holder 110 to the merchant's payment terminal 170 via the user terminal 120. Subsequently, in the payment processing stage, when the holder 110 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 payment server 150 is presented to the payment terminal 170.

[0020] Here, the user terminal 120 is wirelessly connected to the VC management server 130 and the wallet management server 140 via the communication line 100. The payment terminal 170 is wirelessly or wiredly connected to the payment server 150 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.

[0021] Furthermore, the user terminal 120 is a smartphone equipped with a security IC chip called a Secure Element (SE), and works in conjunction with application software installed as a payment service agent app to provide relatively high security features externally in payment scenarios. The user terminal 120 is also capable of sending and receiving various data necessary for payment processing in a contactless state while in close proximity to the payment terminal 170, based on communication functions such as Near Field Communication (NFC) standards. In addition, when the payment service agent app is launched, identity verification of the holder 110's biometric information is performed based on the FIDO (Fast Identity Online) authentication method as a passwordless authentication method.

[0022] Furthermore, the VC management server 130 is operated by a financial institution such as a bank or payment company that has a business contract with at least one cashless payment brand, and manages the credentials and encryption keys (for example, private keys based on public-key cryptography) of holders 110 who are members of the cashless payment brand. The VC management server 130 manages the items to be virtualized as the credentials of holder 110, and issues encrypted VCs to the wallet management server 140 in response to a request from holder 110.

[0023] Furthermore, the encryption key for holder 110 is based on a decentralized identifier (DID) generated by functionally transforming biometric information such as holder 110's fingerprint, iris, voiceprint, ear features, facial features, and vein pattern. The holder 110's DID is maintained differently for each payment service across cashless payment brands, issuers, and holders, thus avoiding the need for correlation between VCs (verifiable credentials) or VPs (verifiable presentations) across multiple payment services.

[0024] Furthermore, the wallet management server 140 is operated by the financial institution that manages the VC management server 130, and is equipped with relatively high external security features for information assets in order to store the holder's 110 encrypted VC and decryption key (for example, a public key based on public-key cryptography). The wallet management server 140 updates the encrypted VC according to the issuer's instructions, or updates the encrypted VC or decryption key according to the holder's request, and issues these to the user terminal 120 or payment server 150. The holder's 110 decryption key (public key) is generated from the encryption key (private key) based on, for example, elliptic curve cryptography.

[0025] Furthermore, the payment server 150 handles a portion of the payment flow related to the holder 110 and the payment institution (not shown) via the payment terminal 170 on the merchant side 160, based on the fact that the payment processing company has concluded a transaction agreement with a payment institution belonging to at least one of various cashless payment brands. Here, the payment server 150 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.

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

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

[0028] [Payment system model configuration] Figure 2A is a diagram showing the configuration of the basic model of the payment system shown in Figure 1. Figures 2B and 2C are tables showing example configurations of VC data when using credit cards and debit cards as payment methods, respectively, in the basic model shown in Figure 2A. As shown in Figure 2A, verifiable credentials (VC) are utilized by the relevant components in various scenarios such as signing, issuing, storing, presenting, and verifying.

[0029] Here, the Issuer is the company that issues credentials to the Holder, the Holder is the individual who manages the issued credentials and presents them to the Verifier, and the Verifier is the company that verifies the authenticity of the credentials. The credentials are structured as follows, for example: (1) information related to the identification of the person to whom the credentials are issued (e.g., the person's identification number), (2) information related to the issuing institution (e.g., the financial institution's identification number), (3) information related to the type of credentials (e.g., credit card, debit card), (4) information related to specific attributes or characteristics claimed by the issuing institution about the person to whom the credentials are issued (e.g., date of birth, address), (5) evidence regarding the method of deriving the credentials (e.g., My Number Card), and (6) information related to the restrictions on the credentials (e.g., validity period, terms of use).

[0030] More specifically, the verifiable data registry, which is the storage location for VCs issued from the issuer's VC management server 130 to the holder 110, can be configured as either a secure element within the user terminal 120 held by the holder 110, or a wallet management server 140 operated by the issuer. In this case, the issuer assigns a different digital signature (for example, a digital signature based on public-key cryptography) to each piece of information (Claim) contained within the credentials, and then configures an encrypted VC based on a different encryption key.

[0031] Furthermore, in a payment scenario, when the verifier's payment server 150 requests the holder's VC (Credential Proof), the encrypted VC is provided to the payment server 150 from the aforementioned data registry. At this time, the verifier uses the holder's 110 decryption key to verify the legitimacy of the Credential Proof against the provided VC. The verification process consists of, for example, the following: (1) confirming the issuer of the Proof, (2) confirming the owner of the Credential information which is the basis of the Proof, (3) confirming the individual claims contained within the Credential information, and (4) confirming that the Credential information has not expired (that the validity period of the Credential information has not expired).

[0032] In Figure 2A, we consider a payment scenario where a credit card is used by a cardholder, with the issuer being a credit company and the verifier being a credit merchant. In this case, as shown in Figure 2B, examples are given of the content of the VC data written to a data registry verifiable by the issuer, the content requested by the verifier, and the content read from the data registry as a result of this request. Here, the verification result shows that the card number is valid, the name and security code match, and the card expiration date, eligible age, and payment amount meet the required conditions. Furthermore, in order to present the verifier with only the minimum necessary credentials regarding the cardholder required for VC verification, that is, to generate the optimal VP from the available VC, techniques such as zero-knowledge proofs (ZKP) are applied.

[0033] Furthermore, Figure 2A assumes a payment scenario where a debit card is used by a cardholder, with the issuer being a bank and the verifier being a debit merchant. In this case, as shown in Figure 2C, examples are given of the data written to the verifiable data registry by the issuer, the content requested by the verifier, and the content read from the data registry as a result of this request. Here, the verification results show that the card number is valid, the name and bank code match, and the branch number, eligible age, and payment amount meet the required conditions. As mentioned above, techniques such as ZKP are applied to generate the optimal VP from the available VCs.

[0034] [Internal configuration of the publisher's VC management server] Figure 3A is a configuration diagram showing the internal configuration of the issuer-side VC management server 130 in the payment system shown in Figure 1. Figures 3B to 3E are tables showing examples of data configurations within the card-related data storage unit in the VC management server 130 shown in Figure 3A, where the issuer is a credit company, a bank, a retail company, and a service company, respectively.

[0035] As shown in Figure 3A, the VC management server 130 is configured similarly to a computer intended for general server use, and supports processing functions related to the task of managing the credentials of holders 10, and determines whether to issue those credentials to be provided to the user terminal 120 as a VC. More specifically, in the VC management server 130, the control unit 310, main memory unit 312, input unit 314, output unit 316, communication interface 318, and auxiliary storage unit 320 are connected to each other via the system bus 300 so that they can communicate with one another.

[0036] 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, a limit management unit 338, and a VC encryption unit 340. 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.

[0037] Furthermore, the auxiliary storage unit 320 includes a customer data storage unit 350, a card-related data storage unit 352, a VC management data storage unit 354, and a program storage unit 356. 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 to process various calculations that manage data and programs in file / database format.

[0038] The control unit 310 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 320 into the main memory unit 312 to perform various calculations. The main memory unit 312 functions as the main memory, storing various data and programs, as well as computer-executable instructions, input from the input unit 314, communication IF unit 318, and auxiliary storage unit 320 based on instructions from the control unit 310. It also stores the data processed by calculations on these internally and provides it externally via the output unit 316.

[0039] The input unit 314 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 316 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 318 provides an interface that functions when sending and receiving various data with the wallet management server 140 and the payment server 150, as well as with other internal systems and devices.

[0040] Here, each embodiment of the VC management server 130 as a server configuration only needs to function as a single system configuration. For example, the VC management server 130 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.

[0041] 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 120 or the wallet management server 140. 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 card-related data storage unit 352. The customer data management unit 336 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 350.

[0042] Furthermore, the credit limit management unit 338 manages the setting, updating, and cancellation of credit limits based on credit management for the holder 110, and stores the related information in the customer data storage unit 350. The VC encryption unit 340 uses the encryption key of the holder 110 stored in the customer data management unit 336 against the credentials of the holder 110 stored in the card-related data storage unit 352, and delivers the generated encrypted VC to the VC issuance unit 332. The program storage unit 356 stores programs for executing a series of processes to be performed as a transaction, or other individual processes, and receives calls to these programs from the control unit 310.

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

[0044] Furthermore, if the issuer is a credit company and the holder 110 uses a credit card, the card-related data storage unit 352 maintains a data configuration, for example, as shown in Figure 3B, and is particularly characterized by the setting of the available balance. Furthermore, if the issuer is a bank and the holder 110 uses a debit card, the card-related data storage unit 352 maintains a data configuration, for example, as shown in Figure 3C, and is particularly characterized by the setting of the account balance.

[0045] Furthermore, if the issuer is a retail company and the holder 110 uses a membership card, the card-related data storage unit 352 maintains a data configuration, for example, as shown in Figure 3D, and is particularly characterized by its setting of point balances. Furthermore, if the issuer is a service company such as an airline and the holder 110 uses a mileage card, the card-related data storage unit 352 maintains a data configuration, for example, as shown in Figure 3E, and is particularly characterized by its setting of mileage balances.

[0046] [Internal configuration of the issuer's wallet management server] Figure 4 is a configuration diagram showing the internal configuration of the issuer-side wallet management server 140 in the payment system shown in Figure 1. As shown in Figure 4, the wallet management server 140 has high external security performance in order to store the VC of holders 10 as a server-type wallet system and issue it as credentials, but internally it is configured in the same way as a general-purpose server computer.

[0047] More specifically, in the wallet management server 140, the control unit 410, main memory unit 412, input unit 414, output unit 416, communication IF 418, and auxiliary memory unit 420 are connected to each other via the system bus 400 so that they can communicate with one another. Since these components basically operate in the same way as the components of the VC management server 130, we will not explain them in detail again.

[0048] The auxiliary storage unit 420 contains a wallet address management unit 430, a wallet address issuance unit 432, a transaction management unit 434, a customer data management unit 436, and an encryption unit 438. 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.

[0049] Furthermore, the auxiliary storage unit 420 includes a customer data storage unit 440. When the data and programs stored in this component are loaded into the main storage unit 412 based on a call instruction from the control unit 410, the subsystem constructed by this load is used for processing various calculations that manage data and programs in file / database format.

[0050] More specifically, the wallet address management unit 430 manages the wallet address-assigned VCs of holder 110 generated by the VC management server 130 and stores the related information in the customer data storage unit 440. The wallet address issuance unit 332 issues wallet addresses for accessing the holder 110's VCs in response to requests from the user terminal 120 and the settlement server 150. The transaction management unit 434 manages the execution of a series of indivisible processes necessary for the management or issuance of wallet addresses and stores the processing results in the customer data storage unit 440.

[0051] Furthermore, the customer data management unit 436 performs updates, cancellations, and other management operations on the holder's VCs stored in the customer data storage unit 440 in response to requests from the VC management server 130, and stores the related information in the customer data storage unit 440. The encryption unit 438 uses the encryption key (private key) from the VC management server 130 based on a public key cryptography scheme to generate an encrypted VC from the holder's VCs to be stored in the customer data storage unit 440, assigns a wallet address to this encrypted VC, and stores it in the customer data storage unit 440. The customer data storage unit 350 stores, for example, the wallet address, qualification ID, customer ID, issuer ID, encrypted VC, digital signature, public key, change status, change date and time, and expiration date as the VC of the customer holder 110.

[0052] [Internal configuration of the user's device on the owner's side] Figure 5 is a configuration diagram showing the internal configuration of the holder-side user terminal 120 in the payment system shown in Figure 1. As shown in Figure 5, the user terminal 120 is configured as a general-purpose mobile computer, similar to a typical smartphone, and manages the biometric information of the holder 10. It also plays a part in providing VC and processing payments through the VC management server 130, wallet management server 140, and payment terminal 170. The user terminal 120 can also function as a client-type wallet system by using a secure element built into itself, instead of the wallet management server 140.

[0053] More specifically, in the user terminal 120, the control unit 510, main memory unit 512, input unit 514, display unit 516, output unit 518, communication IF 520, auxiliary memory unit 530, and secure element 550 are connected to each other via the system bus 500 so that they can communicate with one another. Except for the display unit 516 and secure element 550, these components basically operate in the same way as the components of the VC management server 130 or wallet management server 140, so we will not explain them in detail again.

[0054] The display unit 516 displays instructions received from the holder 110, or information requiring confirmation by the holder 110, on the screen. The secure element 550 has a storage area and an encryption application programming interface (API), and is configured to store the holder 110's encryption key (private key) and encrypted VC as a client-type wallet.

[0055] The auxiliary storage unit 530 includes a VC verification request receiving unit 540, a VC verification unit 542, a transaction management unit 544, and a verification VC selection unit 546. 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.

[0056] More specifically, when the VC verification request receiving unit 540 receives a request for a payment VC from the payment terminal 170, it receives it as a request for payment VC verification and returns the payment VP generated by the verification VC selection unit 546 to the payment terminal 170. The VC verification unit 542 generates a private key from the biometric information of the holder 110 that has been incorporated as biometric authentication, and verifies the legitimacy of the holder 110 by matching the public key further generated from this private key with the public key provided by the wallet management server 140 or the secure element 550. Furthermore, the VC verification unit 542 verifies the legitimacy of the digital signature corresponding to the encrypted VC provided by the wallet management server 140 or the secure element 550.

[0057] Furthermore, the transaction management unit 544 manages the execution of a series of indivisible processes required for VC verification and stores the processing results in the VC data storage unit 560 within the secure element 550. The verification VC selection unit 546 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 settlement terminal 170.

[0058] Furthermore, the secure element 550 includes a VC data storage unit 560. When the secure element 550 is not used as a wallet component based on a server-type wallet system, the VC data storage unit 560 stores, for example, the wallet address, eligibility ID, customer ID, issuer ID, encrypted VC, digital signature, and expiration date as temporary storage for the holder's VC (Virtual Key). On the other hand, when the secure element 550 is used as a wallet component based on a client-type wallet system, the VC data storage unit 560 stores, for example, the eligibility ID, customer ID, issuer ID, encrypted VC, digital signature, public key, modification status, modification date and time, and expiration date as the holder's VC.

[0059] [Internal configuration of the verifier's payment server] Figure 6A is a configuration diagram showing the internal configuration of the verifier-side payment server 150 in the payment system shown in Figure 1. Figures 6B and 6C are tables showing examples of data configurations in the member-related data storage unit 642 and the payment data storage unit 644, respectively, in the payment server 150 shown in Figure 6A. As shown in Figure 6A, the payment server 150 is configured similarly to a computer intended for general server use and supports processing functions related to the business of managing VC verification of holders 10 in payment scenarios and performing payment processing.

[0060] More specifically, in the payment server 150, the control unit 610, main memory unit 612, input unit 614, output unit 616, communication IF 618, and auxiliary memory unit 620 are connected to each other via the system bus 600 so that they can communicate with one another. Since these components basically operate in the same way as the components of the VC management server 130 or wallet management server 140, we will not explain them in detail again.

[0061] The auxiliary storage unit 620 includes a VC verification request issuance unit 630, a VC verification unit 632, a transaction management unit 634, a verified VC determination unit 636, and a settlement data calculation unit 638. 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 verification and settlement.

[0062] Furthermore, the auxiliary storage unit 620 includes a customer data storage unit 640, a member-related data storage unit 642, a payment data storage unit 644, and a program storage unit 646. 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 610, the subsystems constructed by this load are used to process various calculations that manage data and programs in file / database format.

[0063] More specifically, when the VC verification request issuing unit 630 receives a request from the payment terminal 170 to verify the payment VC, it issues a request for VC signature verification to the wallet management server 140 or the user terminal 120, and returns the verification result of the payment VC generated by the VC verification determination unit 636 to the payment terminal 170. The VC verification unit 632 uses the holder's public key obtained from the wallet management server 140 or the user terminal 120 to verify the digital signature corresponding to the holder's VC.

[0064] Furthermore, the transaction management unit 634 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 644. The VC verification determination unit 636 further verifies that the settlement VCs that have been verified as valid by the VC verification unit 632 meet the requirements necessary for settlement processing, and instructs the unit to proceed to settlement processing. When the settlement data calculation unit 638 receives an instruction from the VC verification determination unit 636, it stores the execution results of the settlement processing in the settlement data storage unit 644.

[0065] The customer data storage unit 640 stores registration information of the customer holder 110, such as customer ID, name, address, telephone number, email address, gender, and date of birth. The member-related data storage unit 642 stores the member card information of the holder 110, for example, maintaining the data configuration shown in Figure 6B. The payment data storage unit 644 stores the payment result information of the holder 110, for example, maintaining the data configuration shown in Figure 6C. The program storage unit 646 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 610.

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

[0067] More specifically, in the payment terminal 170, the control unit 710, main memory unit 712, input unit 714, display unit 716, printing unit 718, output unit 720, communication IF 722, and auxiliary storage unit 730 are interconnected via the system bus 700 so that they can communicate with each other. Except for the display unit 716 and printing unit 718, these components basically operate in the same way as the components of the VC management server 130, wallet management server 140, and payment server 150, so we will not explain them in detail again.

[0068] The display unit 716 displays instructions received from the holder 110 or the staff of the affiliated store 160, or information that requires confirmation by the holder 110 or the staff, on the screen. The printing unit 718 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.

[0069] The auxiliary storage unit 730 contains a settlement processing control unit 740, a VC verification control unit 742, a VC verification record management unit 744, an attribute information management unit 746, a membership card information management unit 748, and a transaction management unit 750. 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 verification and settlement.

[0070] Furthermore, the auxiliary storage unit 730 includes a VC verification record storage unit 760, an attribute information storage unit 762, and a membership card information storage unit 764. When the data and programs stored in these components are loaded into the main storage unit 712 based on a call instruction from the control unit 710, the subsystem constructed by this load is used to process various calculations that manage data and programs in file / database format.

[0071] More specifically, when the payment processing control unit 740 receives a payment request input by the holder 110 via various input interfaces, it transmits this payment request to the payment server 150, and then notifies the holder 110 and the staff of the merchant 160 of the payment result from the payment server 150 via each output interface. The VC verification control unit 742 generates a verification request for the payment VC of the holder 110, which is input by the user terminal 120 via each input interface, transmits the verification request to the payment server 150, and receives the verification result from the payment server 150. The VC verification record management unit 744 manages the verification results from the payment server 150 and stores only those VC verification records for which confirmation was accepted at the relevant merchant 160 in the VC verification storage unit 760.

[0072] Furthermore, the attribute information management unit 746 manages the personal attribute information of holder 110 received from the user terminal 120 and additional attribute information directly entered by the staff of the affiliated store 160, and stores this attribute information in the attribute information storage unit 762. The membership card information management unit 748 manages only the membership card information applied for at the affiliated store 160 when holder 110 becomes a user member of the affiliated store 160, and stores this in the membership card information storage unit 764. The transaction management unit 750 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 760 and the attribute information storage unit 762.

[0073] The VC verification storage unit 760 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 VC verification results for the holder 110. The attribute information storage unit 762 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 764 stores, as membership card information, the membership card number, customer ID, credit card number, registration method, and registration date.

[0074] [Offline Payment Process] Regarding the various processes in the payment system described above, firstly, the payment process when the issuer and holder are offline during payment between the holder and the verifier is described below. Figure 8A is a flowchart of the payment process in the payment system shown in Figure 1. Figure 8B is a linkage diagram showing the various data and operation / display flows across various systems included in the payment process shown in Figure 8A. Figure 10A is a flowchart of the key pair registration process included in the various processes shown in Figure 8A. Figure 10B is a linkage diagram showing the various data and operation / display flows across various systems included in the key pair registration process shown in Figure 10A. Figure 11A is a flowchart when the payment process shown in Figure 8A includes payment VC generation (offline). Figure 11B is a linkage diagram showing the various data and operation / display flows across various systems included in the payment VC generation (offline) process shown in Figure 11A.

[0075] (When registering a key pair) First, holder 110 must register their key pair, based on public-key cryptography, with the issuer. Specifically, as shown in Figures 10A and 10B, once holder 110 registers with the issuer, in step S1000, the issuer's VC management server 130 sends key pair request data 1050 to holder 110's user terminal 120. Subsequently, in step S1002, when user terminal 120 receives the key pair request data 1050 from VC management server 130, it notifies holder 110 of a biometric information request display 1052 via the running payment service agent application, and obtains biometric information from holder 110 (e.g., fingerprint, iris, voiceprint, auricle features, facial features, vein pattern, etc.) as biometric information input 1154 via each input interface.

[0076] Next, in step S1004, the user terminal 120 generates a private key from the holder's biometric information based on a public-key cryptography scheme, and then generates a public key from this private key, and sends the key pair data 1156 consisting of these private and public keys to the VC management server 130. Subsequently, in step S1006, the VC management server 130 stores the holder's private key from the key pair received from the user terminal 120 in the customer data storage unit 350 and sends the public key data 1158 to the wallet management server 140. Subsequently, in step S1008, the wallet management server 140 stores the holder's public key data 1158 received from the VC management server 130 in the customer data storage unit 440.

[0077] In step S1008, instead of storing the holder's 110 public key in the wallet management server 140 as a server-type wallet, it is also possible to store it in the VC data storage unit 560 within the secure element 550 of the user terminal 120 as a client-side wallet. In that case, in step S1004, the only item to be sent from the user terminal 120 to the VC management server 130 is the holder's 110 private key.

[0078] (During VC verification) Next, as a preliminary step to settlement where holder 110 enters into a purchase agreement for goods / services at the merchant 160, VC verification of holder 110 is performed. Specifically, as shown in Figures 8A and 8B, in step S800, when a staff member at the merchant 160 receives a settlement request from holder 110 and instructs the settlement terminal 170 to start settlement, the settlement terminal 170 requests holder 110 to issue a settlement VC via VC issuance request display 850. Subsequently, in step S802, when holder 110 instructs the user terminal 120 to issue a settlement VC via VC issuance request operation 852, the user terminal 120 sends VC issuance request data 854 to the VC management server 130.

[0079] Next, in step S804, when the VC management server 130 receives the VC issuance request data 854 from the user terminal 120, it performs identity verification of holder 110 based on, for example, the FIDO authentication method for holder 110's biometric information. Subsequently, in step S806, if the VC management server 130 approves the identity verification result of holder 110, it sends the encrypted VC data 856, encrypted using holder 110's private key, to the wallet management server 140 as encrypted VC data 856. Subsequently, in step S808, the wallet management server 140 stores the encrypted VC received from the VC management server 130 in the customer data storage unit 440. Note that in step S808, instead of storing holder 110's encrypted VC in the wallet management server 140 as a server-type wallet, it may be stored in the VC data storage unit 560 in the secure element 550 of the user terminal 120 as a client-side wallet.

[0080] Next, in step S810, when holder 110 instructs user terminal 120 to disclose a settlement VC by VC disclosure instruction operation 858, user terminal 120 instructs payment terminal 170 to send settlement VC data 860 from wallet management server 140 via user terminal 120, based on the result of holder 110's selection of a settlement VC. Subsequently, in step S812, payment terminal 170 stores the settlement VC received from user terminal 120 in VC verification storage unit 760. Subsequently, in step S814, payment terminal 170 sends settlement VC verification request data 862 to payment server 150. Subsequently, in step S816, payment server 150 stores the settlement VC verification request data 862 received from payment terminal 170 in payment data storage unit 644 and sends judgment information issuance request data 864 to payment terminal 170 as the start of settlement VC verification.

[0081] Next, in step S820, when the payment terminal 170 receives the judgment information issuance request data 864 from the payment server 150, it transmits the judgment information issuance request data 866 to the user terminal 120. Subsequently, in step S822, when the user terminal 120 receives the judgment information issuance request data 866 from the payment terminal 170, it issues judgment information data 868 to the payment terminal 170 as a payment VP generated from the payment VC. Subsequently, in step S824, when the payment terminal 170 receives the judgment information data 868 from the user terminal 120, it transmits the judgment information data 870 to the payment server 170. Subsequently, in step S826, the payment server 170 stores the judgment information data 870 received from the payment terminal 170 in the payment data storage unit 644 and transmits the verification result data 872 of the payment VC generated based on the judgment information data 870 to the payment terminal 170. Furthermore, in order to generate a payment-ready VP by minimizing the necessary qualification information for the decision-making process, techniques such as ZKP (Zero Key Proofing) are applied.

[0082] (During payment processing) Subsequently, as the settlement stage in which the holder 110 enters into a purchase agreement for goods / services at the merchant 160, settlement processing is carried out between the holder 110 and the merchant 160. Specifically, as shown in Figures 8A and 8B, in step S830, the settlement terminal 170 stores the verification result data 872 of the settlement VC received by the settlement terminal 170 in the VC verification storage unit 760. Next, in step S832, if the determination result of the verification result of the settlement VC received by the settlement terminal 170 is approved, the staff of the merchant 160 executes a product information reading operation 874 regarding the goods / services to be purchased by the holder 110 on the settlement terminal 170. After the settlement terminal 170 performs product information linkage processing with the POS system (not shown), it presents a settlement details display 876 to the holder 110. Next, in step S834, when the holder 110 performs a payment authorization operation 878 on the payment terminal 170, the payment terminal 170 sends payment authorization data 880 to the payment server 150.

[0083] Next, in step S840, when the settlement server 150 receives settlement information from the settlement terminal 170, it sends VC-converted settlement information data 882, which is generated by merging this settlement information with an existing settlement VC, to the VC management server 130. Subsequently, in step S842, the VC management server 130 stores the VC-converted settlement information data 882 received from the settlement server 150 in the VC management data storage unit 354 as a settlement result. Subsequently, in step S844, the VC management server 130 sends settlement reflection result data 884 to the settlement server 150 as a settlement result reflection completion notification. Subsequently, in step S846, when the settlement server 150 receives the settlement reflection result data 884 from the VC management server 130, it sends settlement completion notification data 886 to the settlement terminal 170. Next, in step S848, when the payment terminal 170 receives payment completion notification data 886 from the payment server 150, it discloses a payment completion display 890 to the holder 110, and then the staff of the merchant 160 receives confirmation of payment completion from the holder 110.

[0084] (When generating VC for settlement) The following describes in detail the case where the payment VC generation (offline) process is included in step S810. As shown in Figures 11A and 11B, in step S1100, the user terminal 120 sends payment VC issuance request data 1150 to the wallet management server 140 based on the instructions of the holder 110. In step S1110, when the wallet management server 140 receives the payment VC issuance request data 1150 from the user terminal 120, it sends electronic signature request data 1170 to the user terminal 120. Subsequently, in step S1112, when the user terminal 120 receives the electronic signature request data 1160 from the wallet management server 140, it notifies the holder 110 of a biometric information request display 1162 via the running payment service agent application, and obtains biometric information from the holder 110 (e.g., fingerprint, iris, voiceprint, auricle features, facial features, vein pattern, etc.) as biometric information input 1164 via each input interface.

[0085] Next, in step S1114, the user terminal 120 generates a private key from the holder's biometric information based on a public-key cryptography scheme. Subsequently, in step S1116, the user terminal 120 generates a digital signature from the holder's private key. Subsequently, in step S1120, the user terminal 120 sends the public key issuance request data 1166 to the wallet management server 140.

[0086] Next, in step S1122, when the wallet management server 140 receives the public key issuance request data 1166 from the user terminal 120, it issues the public key data 1168 to the user terminal 120 as the public key of holder 110. Subsequently, in step S1126, the user terminal 120 uses the public key data 1168 received from the wallet management server 140 to verify the digital signature of holder 110. Subsequently, in step S1128, the user terminal 120 sends the authentication result data 1170 to the wallet management server 140. Subsequently, in step S1130, the wallet management server 140 stores the authentication result data 1170 received from the user terminal 120 in the customer data storage unit 440.

[0087] Next, in step S1140, the user terminal 120 sends payment VC issuance request data 1172 to the wallet management server 140. Subsequently, in step S1142, the wallet management server 140 generates a payment VC corresponding to the payment VC issuance request data 1172 received from the user terminal 120. Subsequently, in step S1144, the wallet management server 140 sends payment VC data 1184 to the user terminal 120. Subsequently, in step S1146, the user terminal 120 stores the payment VC data 1174 received from the wallet management server 140 in the VC data storage unit 560 and notifies the holder 110 of the payment VC display 1176 via the payment service agent application.

[0088] Furthermore, from step S1100 onward, data exchange between the user terminal 120 and the wallet management server 140 is implemented as a server-type wallet system. However, this can be replaced with a client-side wallet system, where data exchange takes place between the payment service agent application and the secure element 550 within the user terminal 120.

[0089] [Online Payment Process] Secondly, regarding the various processes in the payment system described above, the payment process when the issuer and holder are online during settlement between the holder and the verifier is described below. In this case, the processes described above are the same as the online payment process, referring to Figures 8A, 8B, 10A, and 10B. However, the process related to the generation of payment VCs differs from the offline payment process, as will be described later with reference to Figures 12A and 12B. Therefore, in the following, we will not explain again what is common with the offline payment process, but only what differs from the offline payment process. Figure 12A is a flowchart showing the case where the payment process shown in Figure 8A includes the generation of payment VCs (online). Figure 12B is a linkage diagram showing the various data and operation / display flows across various systems included in the online payment VC generation process shown in Figure 12A.

[0090] (When generating VC for settlement) The following describes in detail the case where the payment VC generation (online) process is included in step S810. As shown in Figures 12A and 12B, the process from step S1100, in which the user terminal 120 requests the wallet management server 140 to issue a payment VC, to step S1130, in which the wallet management server 140 receives the authentication result from the user terminal 120, is the same as the payment VC generation (offline) process described above. Therefore, in the following, we will not explain again what is common with the payment (offline) process, and will only explain what differs from the payment (offline) process.

[0091] As shown in Figures 12A and 12B, in step S1200, the user terminal 120 sends payment VC issuance request data 1250 to the VC management server 130. Subsequently, upon receiving the payment VC issuance request data 1250 from the user terminal 120, the VC management server 130 sends payment VC issuance request data 1252 to the wallet management server 140. Subsequently, in step S1204, the wallet management server 140 generates a payment VC corresponding to the payment VC issuance request data 1252 received from the VC management server 130.

[0092] Next, in step S1206, the wallet management server 140 sends payment VC data 1254 to the VC management server 130. Subsequently, in step S1208, upon receiving payment VC data 1254 from the wallet management server 140, the VC management server 130 sends payment VC data 1256 to the payment server 150. Subsequently, in step S1210, the payment server 150 stores the payment VC data 1256 received from the VC management server 130 in the VC verification storage unit 760. Subsequently, in step S1212, the payment server 150 sends payment VC data 1258 corresponding to payment VC data 1256 to the payment terminal 170. Subsequently, upon receiving payment VC data 1258 from the payment server 150, the payment terminal 170 displays payment VC display 1260 on the screen as information requiring verification by the staff of the merchant 160 or the holder 110.

[0093] [Identity Verification (New Registration) Process] Regarding the various processes in the payment system described above, thirdly, the process of identity verification (new registration) between the holder and the verifier is described below. Figure 9A is a flowchart of the identity verification (new registration) process in the payment system shown in Figure 1. Figure 9B is a linkage diagram showing the various data and operation / display flows across various systems included in the identity verification (new registration) process shown in Figure 9A. Figure 10A is a flowchart of the key pair registration process included in the various processes shown in Figure 9A. Figure 10B is a linkage diagram showing the various data and operation / display flows across various systems included in the key pair registration process shown in Figure 10A.

[0094] First, the holder's key pair, based on public-key cryptography, must be registered with the issuer. Specifically, this is as described in the settlement process described above, referring to Figures 10A and 10B. Next, at the merchant 160, the holder 110 undergoes identity verification (new registration), and VC verification of the holder 110 is performed. As shown in Figures 9A and 9B, the process from step S800, when the settlement terminal 170 requests VC issuance from the holder 110, to step S808, when the wallet management server 140 receives encrypted VC from the VC management server 130, is the same as in the settlement process (offline / online) described above. Therefore, in the following, we will not explain again what is common with the settlement process (offline / online), and will only explain what differs from the settlement process (offline / online).

[0095] Specifically, as shown in Figures 9A and 9B, in step S900, when holder 110 instructs user terminal 120 to disclose VC by VC disclosure instruction operation 950, user terminal 120 instructs wallet management server 140 to send identity verification VC data 952 from user terminal 120 to payment terminal 170 based on the result of holder 110's selection of identity verification VC. Subsequently, in step S902, payment terminal 170 stores the identity verification VC received from user terminal 120 in VC verification storage unit 760. Subsequently, in step S904, payment terminal 170 sends identity verification VC verification request data 854 to payment server 150. Next, in step S906, the payment server 150 stores the identity verification VC verification request data 854 received from the payment terminal 170 in the customer data storage unit 640, and sends the determination information issuance request data 956 to the payment terminal 170 to start the verification of the identity verification VC.

[0096] Next, in step S910, when the payment terminal 170 receives the judgment information issuance request data 956 from the payment server 150, it transmits the judgment information issuance request data 958 to the user terminal 120. Subsequently, in step S912, when the user terminal 120 receives the judgment information issuance request data 958 from the payment terminal 170, it issues judgment information data 960 to the payment terminal 170 as an identity verification VP generated from the identity verification VC. Subsequently, in step S914, when the payment terminal 170 receives the judgment information data 960 from the user terminal 120, it transmits the judgment information data 962 to the payment server 170. Subsequently, in step S916, the payment server 170 stores the judgment information data 962 received from the payment terminal 170 in the customer data storage unit 640 and transmits the identity verification completion notification data 964 generated based on the judgment information to the payment terminal 170. Furthermore, in order to generate a VP for identity verification by minimizing the information necessary for judgment, techniques such as ZKP are applied.

[0097] [Effects of the Embodiment] Thus, according to embodiments of the present invention, in merchants affiliated with cashless payment brands, it is possible to provide service users with functionalities such as personal authentication to meet diverse requirements for various credentials, or privacy protection through selective disclosure of credentials, while maintaining the prevention of fraudulent use in response to various cashless payment scenarios, particularly in cardless payment scenarios.

[0098] More specifically, the effects enjoyed by holders, issuers, and verifiers according to the present invention are as follows. Firstly, as an effect enjoyed by holders, by utilizing it as a KYC function for age information in various card authentications, it is possible to provide holders with a completely cardless consumption experience. For example, this includes a seamless experience at an unmanned checkout, from age verification of the holder to payment via point card linkage. Furthermore, it is possible to provide a payment experience that combines VC regarding one attribute from one issuer with VC regarding the other attribute from another issuer. For example, this includes the purchase of alcoholic beverages by persons 20 years of age or older, discounted purchases limited to city residents, and the purchase of limited-quantity items online.

[0099] Furthermore, the benefits enjoyed by cardholders include reducing the entry barrier for initial member registration by digitizing and sharing KYC information based on the Act on Prevention of Transfer of Criminal Proceeds. It also provides protection against fraudulent use through a scheme that generates only secure transactions without requiring the card itself to be held. Additionally, it provides privacy protection through selective disclosure. For example, when purchasing alcohol at a convenience store, this includes preventing store staff from misusing unnecessary information such as address, name, and license number other than the required age, or preventing store staff from stealing card numbers during credit card payments.

[0100] Secondly, the benefits for issuers include reduced administrative and postage costs associated with issuing various cards. They can also reduce compensation costs by preventing fraudulent use of various cards. Furthermore, they can increase revenue by providing new payment experiences. For example, these new experiences could include seamless data integration with services from other issuers and user-friendly onboarding to new services.

[0101] Thirdly, as an effect enjoyed by participating merchants on the verification side (e.g., retail stores), it is possible to reduce store operating costs by guiding customers purchasing alcohol, tobacco, etc., to self-checkout registers. Furthermore, by utilizing a Software Development Kit (SDK) that includes the mechanisms or information necessary for implementing the present invention, it is possible to provide easy integration with the verification side's point programs. In addition, it is possible to reduce cash management costs through seamless integration leading to payment. Moreover, it is possible to reduce the risk of selling to minors through age verification that is more rigorous than visual inspection by store staff.

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

[0103] 100 communication lines 110 holders 120 user terminals 130 Publisher-side VC management server 140 Issuer-side wallet management server 150 Verifier-side payment server 160 member stores 170 Merchant-side payment terminals 300 System Bus 310 Control Unit 312 Main memory 314 Input section 316 Output section 318 Communication Interface Section 320 Auxiliary storage 330 VC Management Department 332 VC Publishing Department 334 Transaction Management Department 336 Customer Data Management Department 338 Limit Management Department 340 VC encryption section 350 Customer data storage unit 352 Card-related data storage unit 354 VC Management Data Storage Unit 356 Program Storage Unit 400 System Bus 410 Control Unit 412 Main memory 414 Input section 416 Output section 418 Communication Interface Section 420 Auxiliary storage 430 Wallet Address Management Department 432 Wallet Address Issuance Department 434 Transaction Management Department 436 Customer Data Management Department 438 Encryption section 440 Customer data storage unit 500 System Bus 510 Control Unit 512 Main memory 514 Input section 516 Display section 518 Output section 520 Communication Interface Section 530 Auxiliary storage unit 540 VC Verification Request Receiving Department 542 VC Verification Department 544 Transaction Management Department 546 Verification VC Selection Section 550 Secure Elements 560 VC data storage unit 600 System Bus 610 Control Unit 612 Main memory 614 Input section Output section of 616 618 Communication Interface Section 620 Auxiliary storage 630 VC Verification Output Unit 632 VC Verification Department 634 Transaction Management Department 636 Verification VC Judgment Unit 638 Payment Data Processing Department 640 Customer Data Storage Unit 642 Member-related data storage unit 644 Payment Data Storage Unit 646 Program Storage Unit 700 System Bus 710 Control Unit 712 Main memory 714 Input section 716 Display section 718 Printing Department 720 Output section 722 Communication IF section 730 Auxiliary storage unit 740 Payment Processing Control Unit 742 VC Verification Control Unit 744 VC Verification Record Management Department 746 Attribute information management department 748 Membership Information Management Department 750 Transaction Management Department 760 VC Verification Memory Unit 762 Attribute information storage unit 764 Membership Card Information Storage Unit

Claims

1. A settlement system that settles a sales contract between an issuer with a payment brand and a business contract, a holder who is a member of the payment brand, and a verifier with a transaction contract with the payment brand, at a merchant with a merchant agreement with the verifier, based on the verifier's verification results of the credentials provided by the holder, the merchant settles the sales contract between the holder and the merchant. A VC management server installed on the issuer's side, which responds to requests from a user terminal used by the holder and determines whether or not the verification result of the holder's identity is approved, to issue the credentials as verifiable credentials (VC) to the user terminal, A data registry that manages the VC based on instructions from the VC management server, and issues the VC to the user terminal based on the determination result of the VC management server and the request from the user terminal, A settlement server installed on the verifier's side performs verification of the verifiable presentation (VP) generated in accordance with the VC, based on judgment information provided from the user terminal that is the verification request recipient, and then performs settlement processing for the sales contract. A payment terminal installed at the aforementioned merchant, which requests the payment server to verify the VP issued from the data registry via the user terminal, and then requests the payment server to perform the payment processing based on the verification result of the VP, A payment system characterized by comprising the following features.

2. The payment system according to claim 1, characterized in that the data registry is configured as a wallet management server installed on the issuer side as a server-type wallet system, or stored in a secure element built into the user terminal as a client-type wallet system.

3. The payment system according to claim 1, characterized in that the VP generated from the VC presents the verifier with the minimum necessary credentials regarding the holder required for verification of the VC, based on zero-knowledge proof (ZKP) techniques provided to the payment server.

4. The payment system according to claim 1, characterized in that the VC is assigned a different digital signature to each individual piece of information (Claim) constituting the credentials and is encrypted based on a different encryption key.

5. The payment system according to claim 4, characterized in that the electronic signature is a digital signature based on a public-key cryptography scheme, and the VC is encrypted using the holder's private key and decrypted using the holder's public key based on a public-key cryptography scheme.

6. The payment system according to claim 5, characterized in that the private key is generated based on a distributed identifier (DID) produced by a function transformation of the holder's biometric information, the public key is generated from the private key based on an elliptic curve cryptography scheme, and the DID is set to be different for each of the multiple payment services between the payment brand, the issuer, and the holder.

7. The payment system according to claim 1, characterized in that, in order to access the data registry from the user terminal, authentication of the holder is performed by a payment service agent application installed on the user terminal.

8. The payment system according to claim 7, characterized in that the authentication of the holder is performed as identity verification of the holder based on the FIDO authentication method for the holder's biometric information.

9. A settlement scenario spanning between an issuer with a payment brand and a business contract, a holder who is a member of the payment brand, and a verifier with a transaction contract with the payment brand, wherein in a settlement system that handles a sales contract between the holder and the merchant, based on the verification results by the verifier against the credentials provided by the holder, a method for verifying the credentials before executing the settlement process for the sales contract, wherein The VC management server installed on the issuer's side, in response to a request from a user terminal used by the holder, determines whether or not the verification result of the holder's identity is approved, and determines whether to issue the credentials to be provided to the user terminal as verifiable credentials (VC), In a data registry that manages the VC based on instructions from the VC management server, the steps include issuing the VC to the user terminal based on the determination result of the VC management server and the request from the user terminal, The payment terminal installed at the merchant requests the payment server installed on the verifier's side to verify the verifiable presentation (VP) generated in response to the VC, which is issued from the data registry via the user terminal. The payment server installed on the verifier's side performs verification of the VP provided from the payment terminal based on the judgment information provided from the user terminal which is the verification request recipient, and provides the verification result of the VP to the payment terminal. The payment terminal includes the step of determining a request for payment processing to the payment server based on the verification result for the VP provided from the payment terminal. A method that includes [a certain feature].

10. The method according to claim 9, characterized in that the data registry is configured as a wallet management server installed on the issuer side as a server-type wallet system, or stored in a secure element built into the user terminal as a client-type wallet system.

Images