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 a verifiable credential (VC). More specifically, the present invention relates to a payment system and method for supporting a cashless payment scenario between a holder, an issuer, and a verifier associated with a VC based on the use of a verifiable presentation (VP) generated from the VC. [Background technology]

[0002] In the payment area of ​​commercial transactions across various industries, there is a need for management of physical objects such as paper in the real world, such as driver's licenses, My Number cards, credit cards, and cash cards. Therefore, if such physical paper or its associated face number or personal identification number is fraudulently counterfeited or stolen, there is a risk that it may be misused by the thief for fraudulent purposes. Furthermore, as such fraudulent methods have become more sophisticated in recent years, the increase in the risks described above is becoming a growing concern, especially in payment situations involving electronic commerce (EC).

[0003] In response to this, payment services that support cashless payments without issuing physical cards such as credit cards or debit cards to cardholders, i.e., in cardless payment scenarios, are being developed. For example, Patent Document 1 discloses a technology for verifying cardholders by having a service member store present or input a "one-time debit number" presented to the cardholder by an issuer, based on the issuer's management of 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 Application Laid-Open No. 2011-43983 Summary of the Invention [Problem to be solved by the invention]

[0005] However, the payment service disclosed in Patent Document 1 is extremely limited in its usage patterns, making it difficult to utilize the KYC (Know Your Customer) function for verifying service users in a variety of payment scenarios. For example, from the perspective of personal authentication, there are concerns that the service will not be able to accommodate a variety of payment scenarios, such as by expanding the scope of verification to include eligibility information such as a driver's license or My Number card, or by limiting the information disclosed to only essential information such as age or address.

[0006] Therefore, in various cashless payment methods that are expected to develop into more versatile methods in the future, there has been a problem in that it is not possible to provide sufficient functionality to service users, such as providing personal authentication to meet various requirements for various credentials, or protecting privacy through selective disclosure of credentials, while maintaining the prevention of fraudulent use in cardless payment scenarios.

[0007] The present invention has been made to solve these problems, and aims to provide a payment system and method based on verifiable credentials that supports cashless payment functions at affiliated stores of cashless payment brands and enables fraud prevention, cardless payment, personal authentication schemes, and privacy protection. [Means for solving the problem]

[0008] In order to solve the above problems, as one aspect of the present invention, the payment system is a payment scenario spanning an issuer that has a business contract with a payment brand, a holder who is a member of the payment brand, and a verifier that has a transaction contract with the payment brand, and is intended to enable the settlement of a sales contract between the holder and the affiliated store that has an affiliated store contract with the verifier based on the verification results by the verifier of the qualification information provided by the holder, and comprises the following components: (1) a VC management server installed on the issuer side, which determines whether to issue a credential to provide to a user terminal as a verifiable credential (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 determination results of the VC management server and requests from the user terminals; (3) a payment server located on the verifier side that verifies the verifiable presentation (VP) generated from the VC and then executes the payment process for the sales contract; and (4) A payment terminal installed at a member store that requests the payment server to verify the VC provided by the data registry via the user terminal, and then requests the payment server to process the payment based on the verification results of the VP.

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

[0010] In addition, the VP generated from the VC presents the verifier with the minimum necessary credentials about the holder required to verify the VC, based on the Zero Knowledge Proof (ZKP) technique provided to the settlement server.

[0011] In addition, a different digital signature is assigned to each piece of information (Claim) that makes up the credentials, and the VC is 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 based on public key cryptography. The private key is generated based on a decentralized identifier (DID) generated by a function transformation of the holder's biometric information, and the public key is generated from the private key using elliptic curve cryptography, and the DID is set to be different for each of the multiple payment services across payment brands, issuers, and holders.

[0012] In order to access the data registry from a user device, the owner is authenticated by a payment service agent app installed on the user device. The owner is authenticated based on the FIDO authentication method for the owner's biometric information to verify the owner's identity.

[0013] Furthermore, as one aspect of the present invention, in a payment 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, in a payment system that handles a sales contract between a holder and a member store that has a member store contract with the verifier based on the verification result by the verifier of the qualification information provided by the holder, a method for verifying qualification information before executing payment processing of the sales contract comprises the following components: (1) in a VC management server installed on the issuer side, a step of determining whether to issue the credential information to be provided to the user terminal as a verifiable credential (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, a step of issuing a VC to a user terminal based on a determination result of the VC management server and a request from the user terminal; (3) A step of requesting a payment server installed on the verifier side to verify the VC issued from the data registry via the user terminal at the payment terminal installed at the affiliated store; (4) in the payment server, verifying a verifiable presentation (VP) based on the VC provided by the payment terminal, and providing a verification result of the VP to the payment terminal; and (5) In the payment terminal, a step of determining whether to request payment processing from the payment server based on the verification result provided by the payment server.

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

[0015] According to the present invention, it is possible to provide service users with functionality such as personal authentication to meet various requirements for various types of credential information, or privacy protection through selective disclosure of credential information, while maintaining the prevention of fraudulent use in cardless payment scenarios and accommodating various cashless payment functions that are expected to be developed in a versatile manner in the future at affiliated stores of cashless payment brands. [Brief explanation of the drawings]

[0016] A more detailed understanding of the embodiments disclosed herein can be had from the following description, taken in conjunction with the accompanying drawings, in which: [Figure 1] 1 is a configuration diagram showing a connection configuration of a payment system according to an embodiment of the present invention. [Figure 2A] FIG. 2 is a diagram showing the configuration of a basic model of the payment system shown in FIG. 1. [Figure 2B] 2B is a table showing an example of the configuration of VC data when a credit card is used as a payment method in the basic model shown in FIG. 2A. [Figure 2C] 2B is a table showing an example of the configuration of VC data when a debit card is used as a payment method in the basic model shown in FIG. 2A. [Figure 3A] 2 is a configuration diagram showing the internal configuration of an issuer-side VC management server in the payment system shown in FIG. 1. FIG. [Figure 3B] 3B is a table showing an example of a data configuration in a card-related data storage unit in the issuer-side VC management server shown in FIG. 3A when the issuer is a credit company. [Figure 3C] 3B is a table showing an example of a data configuration in a card-related data storage unit in the issuer-side VC management server shown in FIG. 3A when the issuer is a bank. [Figure 3D] 3B is a table showing an example of a data configuration in a card-related data storage unit in the issuer-side VC management server shown in FIG. 3A when the issuer is a retail company. [Figure 3E] 3B is a table showing an example of a data configuration in a card-related data storage unit in the issuer-side VC management server shown in FIG. 3A when the issuer is a service company. [Figure 4] FIG. 2 is a diagram showing the internal configuration of an issuer-side wallet management server in the payment system shown in FIG. [Figure 5] 2 is a block diagram showing the internal configuration of a holder-side user terminal in the payment system shown in FIG. 1. FIG. [Figure 6A] FIG. 2 is a configuration diagram showing the internal configuration of a verifier-side payment server in the payment system shown in FIG. [Figure 6B] 6B is a table showing an example of a data configuration in a member-related data storage unit in the verifier-side settlement server shown in FIG. 6A. [Figure 6C] 6B is a table showing an example of a data configuration in a payment data storage unit in the verifier-side payment server shown in FIG. 6A. [Figure 7] 2 is a block diagram showing the internal configuration of an affiliated store payment terminal in the payment system shown in FIG. 1. FIG. [Figure 8A] 2 is a flowchart showing a payment process in the payment system shown in FIG. 1. [Figure 8B] FIG. 8B is an interaction diagram illustrating the various data and operation / display flows between the various systems involved in the payment process shown in FIG. 8A. [Figure 9A] 2 is a flowchart showing the identity verification (new registration) process in the payment system shown in FIG. 1. [Figure 9B] FIG. 9B is a linkage diagram showing the flow of various data and operations / displays between various systems included in the identity verification (new registration) process shown in FIG. 9A. [Figure 10A] 8A or 9B is a flowchart illustrating a key pair registration process included in the various processes shown in FIG. 8A or 9A. [Figure 10B] FIG. 10B is an interaction diagram illustrating the various data and operation / display flows between the various systems involved in the key pair registration process shown in FIG. 10A. [Figure 11A] 8B is a flowchart showing a case where the settlement process shown in FIG. 8A includes settlement VC generation (offline). [Figure 11B] FIG. 11B is a linkage diagram showing the flow of various data and operations / displays between various systems included in the settlement VC generation (offline) process shown in FIG. 11A. [Figure 12A] 8B is a flowchart showing a case where the settlement process shown in FIG. 8A includes settlement VC generation (online). [Figure 12B] FIG. 12B is a linkage diagram showing the flow of various data and operations / displays between various systems included in the settlement VC generation (online) process shown in FIG. 12A. DETAILED DESCRIPTION OF THE INVENTION

[0017] Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings. Note that the same reference numerals in multiple drawings represent the same components, and the repeated description thereof will be omitted. Also, acronyms such as VC (Verifiable Credentials), VP (Verifiable Presentation), etc. will be used below, but will not be explained again unless they are first mentioned.

[0018] [Payment system connection type] Figure 1 is a block diagram showing the connection configuration of a payment system according to one embodiment of the present invention. Figure 1 illustrates a scenario in which a member store (e.g., retail store) 160, which has a merchant contract with a verifier (e.g., a payment agency) that has a transaction contract with at least one payment institution of various cashless payment brands, confirms eligibility or identity of a holder (customer) 110 who is a member of the cashless payment brand through a payment process accompanying or related to a sales contract for goods or services in the store.

[0019] In particular, in the preliminary stage of the payment process, when verifying the qualifications or identity of the holder 110, an operation on the user terminal 120 used by the holder 110 triggers a credential certificate issued by cooperation between the VC management server 130 and the wallet management server 140 on the issuer (e.g., financial institution) side to be provided by the holder 110 to the payment terminal 170 on the affiliated store 160 side via the user terminal 120. Thereafter, in the payment processing stage, when the holder 110 performs an input operation for payment on the payment terminal 170 with the support of the staff of the affiliated store 160, the result of the payment processing in the payment server 150 on the verifier side is presented to the payment terminal 170.

[0020] Here, the user terminal 120 is connected to the VC management server 130 and the wallet management server 140 via the communication line 100 so as to be able to communicate wirelessly. Also, the payment terminal 170 is connected to the payment server 150 via the communication line 100 so as to be able to communicate wirelessly or via wire. Note that the communication line 100 may be, for example, a public line type network that realizes telephone communication and data communication, or may include as part thereof a dedicated line type network that connects only specific systems so as to be able to communicate in a limited manner.

[0021] The user terminal 120 is a smartphone with a built-in security IC chip called a Secure Element (SE), and in conjunction with application software installed as a payment service agent app, provides relatively high external security functions in payment situations. The user terminal 120 uses communication functions such as the Near Field Communication (NFC) standard to transmit and receive various data necessary for payment processing in close proximity to the payment terminal 170 while in a contactless state. When the payment service agent app is launched, the identity of the holder 110 is verified using biometric information based on the FIDO (Fast Identity Online) authentication method as passwordless authentication.

[0022] The VC management server 130 is operated by a financial institution such as a bank or a payment company that has a business contract with at least one of the cashless payment brands, and manages the credential information and encryption keys (for example, private keys based on public key cryptography) of the holder 110 who is a member of the cashless payment brand. The VC management server 130 manages the objects to be converted into VC as the credential information of the holder 110, and issues encrypted VC to the wallet management server 140 in response to a request from the holder 110.

[0023] Furthermore, here, the encryption key of the holder 110 is based on a decentralized identifier (DID) generated by functionally transforming biometric information such as the fingerprint, iris, voiceprint, ear features, facial features, and vein pattern of the holder 110. The DID of the holder 110 is kept different for each of the various payment services across cashless payment brands, issuers, and holders, thereby avoiding correlation of VC (verifiable credentials) or VP (verifiable presentation) between multiple payment services.

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

[0025] Furthermore, the payment server 150 is responsible for part of the payment flow relating to the holder 110 and the payment institution (not shown) via the payment terminal 170 on the affiliated store 160 side, based on the fact that the payment agency has concluded a transaction contract with a payment institution belonging to at least one of various cashless payment brands. Here, in response to a payment request received from the payment terminal 170, the payment server 150 transmits the result of the payment processing by the relevant payment institution to the payment terminal 170.

[0026] Furthermore, payment terminal 170 is a payment terminal that is installed in member store 160 that has concluded a member store contract with the member store management company, and is compatible with various cashless payment processes when processing the accounting for retail sales transactions that take place in the store, and supports payments for purchase transactions of goods, services, etc. by customer holder 110. In particular, the customer screen implemented as an operation panel function in payment terminal 170 can display various information before and after payment, or various information before and after identity verification or qualification verification, etc.

[0027] In particular, types of cashless payments assumed here include card payments, electronic money payments, code payments, etc. In card payments, the card itself based on a credit card, prepaid card, debit card, etc. presented by the holder 110 as a customer is read on the payment terminal 170, or reading is performed via a smartphone, etc.

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

[0029] Here, an issuer is a company that issues credentials to a holder, a holder is an individual that manages the issued credentials and presents them to a verifier, and a verifier is a company that verifies the authenticity of the credentials. The credentials may be configured, for example, as follows: (1) information related to the identification of the subject of the credentials (e.g., the subject's identification number, etc.), (2) information related to the issuing institution (e.g., a financial institution's identification number, etc.), (3) information related to the type of credentials (e.g., credit card, debit card, etc.), (4) information related to specific attributes or characteristics asserted by the issuing institution about the subject (e.g., date of birth, address, etc.), (5) evidence regarding the method of deriving the credentials (e.g., My Number Card, etc.), and (6) information related to the constraints of the credentials (e.g., validity period, terms of use, etc.).

[0030] More specifically, the verfiable data registry, which is the storage location of the VC issued from the issuer's VC management server 130 to the holder 110, can be configured as a secure element in the user terminal 120 possessed by the holder 110, or as a wallet management server 140 operated by the issuer. At this time, the issuer assigns a different electronic signature (for example, a digital signature based on a public key cryptosystem) to each piece of information (Claim) included in the credential, and then configures the encrypted VC based on different encryption keys.

[0031] Furthermore, in a payment scenario, when the verifier's payment server 150 requests the holder 110's VC, the encrypted VC is provided to the payment server 150 from the data registry described above. At this time, the verifier verifies the validity of the credential proof by using the holder 110's decryption key for the provided VC. The verification contents are configured as follows, for example: (1) confirming the issuer of the credential proof, (2) confirming the owner of the credential information that is the basis of the credential, (3) confirming each piece of information (Claim) included in the credential information, (4) that the credential information has not expired (that the validity period of the credential information has not expired), etc.

[0032] In Figure 2A, the issuer is a credit card company, the verifier is a credit card merchant, and a payment scenario is assumed in which a credit card holder uses a credit card. In this case, Figure 2B illustrates an example of the VC data written by the issuer to a verifiable data registry, along with the request made by the verifier and the content read from the data registry in response to this request. The verification results presented here are that the card number is valid, the name and security code match, and the card expiration date, retail age, and payment amount meet the required conditions. Note that techniques such as zero-knowledge proofs (ZKPs) are used to present the verifier only with the minimum necessary credentials for the holder required for VC verification, i.e., to generate an optimal VP from the presentable VC.

[0033] Also, in Figure 2A, assume that the issuer is a bank and the verifier is a debit merchant, and assume a payment scenario in which the cardholder uses a debit card. In this case, as shown in Figure 2C, the data content written by the issuer to the verifiable data registry is exemplified, along with the content requested by the verifier and the content read from the data registry in response to this request. Here, the verification results are presented as follows: the card number is valid, the name and bank code match, and the branch number, sales age, and payment amount meet the required conditions. As mentioned above, techniques such as ZKP are applied to generate the optimal VP from the presentable VC.

[0034] [Internal configuration of issuer'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 in the card-related data storage unit in the VC management server 130 shown in Figure 3A when the issuers are a credit company, a bank, a retail company, and a service company, respectively.

[0035] 3A, the VC management server 130 is configured similarly to a computer for general server use, supports processing functions related to the task of managing the credential information of the holder 10, and determines whether to issue the credential information to provide it as a VC to the user terminal 120. More specifically, in the VC management server 130, a control unit 310, a main memory unit 312, an input unit 314, an output unit 316, a communication IF (Interface) 318, and an auxiliary memory unit 320 are connected to each other via a system bus 300 so as to be able to communicate with each other.

[0036] The auxiliary storage unit 320 contains a VC management unit 330, a VC issuing 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 loading executes various calculation processes that handle the processing of various data related to VC management and issuance.

[0037] Auxiliary storage unit 320 also 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 main storage unit 312 based on a call instruction from control unit 310, the subsystem constructed by this loading is used to process various operations that manage data, programs, etc. in the form of files / databases.

[0038] The control unit 310 functions as a central processing unit (CPU) to control the operation of individual system components and perform data calculations, and in particular loads data and programs stored in the auxiliary storage unit 320 into the main storage unit 312 to perform various calculations. The main storage unit 312 functions as a main memory, storing various data and programs, computer-executable instructions, and the like input from the input unit 314, communication IF unit 318, auxiliary storage unit 320, etc. based on instructions from the control unit 310, and stores the data after calculation processing on these internally and provides the data to the outside via the output unit 316.

[0039] The input unit 314 provides an interface for receiving various commands and data (e.g., various master and table data, etc.) input by a system operator. The output unit 316 provides an interface for generating output data for displaying various processed data to an operator and output data for printing the data. The communication IF unit 318 provides an interface that functions when sending and receiving various data between the wallet management server 140, the settlement server 150, and other internal systems and devices.

[0040] Here, each embodiment of the server configuration of the VC management server 130 may function as a single system configuration entity. Therefore, as an example of an embodiment, the VC management server 130 may be placed inside a single server computer, may be configured with each system component being configured as a plurality of sets of units in parallel and distributed, or may be configured to share data and programs by combining a plurality of server computers.

[0041] More specifically, the VC management unit 330 manages the generation, update, cancellation, etc. of the VC-encoded credential information of the cardholder 110, and stores the related information in the VC management data storage unit 354. The VC issuing unit 332 issues the VC-encoded credential information of the cardholder 110 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 required for the above-mentioned VC management or VC issuance, and stores the processing results in the card-related data storage unit 352. The customer data management unit 336 manages the credential information and encryption keys (e.g., private keys based on public key cryptography) of the cardholder 110, and stores the related information in the customer data storage unit 350.

[0042] Furthermore, the credit limit management unit 338 manages the setting, updating, cancellation, etc. of the credit limit based on the credit management for the cardholder 110, and stores the related information in the customer data storage unit 350. The VC encryption unit 340 uses the encryption key of the cardholder 110 stored in the customer data management unit 336 for the qualification information of the cardholder 110 stored in the card-related data storage unit 352, and delivers the generated encrypted VC to the VC issuing unit 332. The program storage unit 356 stores programs for executing a series of processes executed 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, as registration information of the customer holder 110, for example, a customer ID, name, address, telephone number, email address, gender, date of birth, debit account, occupation, job title, annual income, and family composition. The VC management data storage unit 354 stores, as transition information of the qualification information of the holder 110, a qualification ID, customer ID, issuer ID, private key, change status, change date and time, expiration date, and the like.

[0044] If the issuer is a credit company and the cardholder 110 uses a credit card, the card-related data storage unit 352 may have the data structure shown in Fig. 3B, for example, and may be characterized in particular by the setting of the available balance. If the issuer is a bank and the cardholder 110 uses a debit card, the card-related data storage unit 352 may have the data structure shown in Fig. 3C, for example, and may be characterized in particular by the setting of the account balance.

[0045] Furthermore, if the issuer is a retail company and the cardholder 110 uses a membership card, the card-related data storage unit 352 may hold, for example, the data configuration shown in Fig. 3D, and may be characterized in particular by the setting of the points balance. Furthermore, if the issuer is a service company such as an airline company and the cardholder 110 uses a mileage card, the card-related data storage unit 352 may hold, for example, the data configuration shown in Fig. 3E, and may be characterized in particular by the setting of the mileage balance.

[0046] [Internal configuration of the issuer's wallet management server] Figure 4 is a block 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 as a server-type wallet system that stores the VC of the holder 10 and issues it as a credential, but internally it is configured in the same way as a computer for general server use.

[0047] More specifically, in the wallet management server 140, a control unit 410, a main memory unit 412, an input unit 414, an output unit 416, a communication IF 418, and an auxiliary memory unit 420 are communicably connected to one another via a system bus 400. These components basically operate in the same way as the components of the VC management server 130, and therefore details will not be described again.

[0048] Auxiliary memory 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 main memory unit 412 based on a call instruction from control unit 410, each application program constructed by this loading executes various calculation processes that handle the processing of various data related to VC management and issuance.

[0049] Additionally, auxiliary storage unit 420 includes customer data storage unit 440. When the data and programs stored in this component are loaded into main storage unit 412 based on a call instruction from control unit 410, the subsystem constructed by this loading is used to process various operations that manage data, programs, etc. in the form of files / databases.

[0050] More specifically, the wallet address management unit 430 manages the VC with the wallet address assigned to the holder 110, which is 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 a wallet address for accessing the VC of the holder 110 in response to a request from the user terminal 120 and the settlement server 150. The transaction management unit 434 manages the execution of an indivisible series of processes required for managing or issuing wallet addresses, and stores the processing results in the customer data storage unit 440.

[0051] In addition, the customer data management unit 436 manages updates, cancellations, etc. of the VC of the holder 110 stored in the customer data storage unit 440 in response to a request from the VC management server 130, and stores the related information in the customer data storage unit 440. The encryption unit 438 uses an encryption key (private key) from the VC management server 130 based on a public key cryptosystem to generate an encrypted VC from the VC of the holder 110 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, a wallet address, a qualification ID, a customer ID, an issuer ID, the encrypted VC, an electronic signature, a public key, a change status, a change date and time, an expiration date, etc. as the VC of the customer holder 110.

[0052] [Internal configuration of the owner's user device] Figure 5 is a block 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, manages the biometric information of the holder 10, and is responsible for providing VC and part of the payment processing through the VC management server 130, wallet management server 140, and payment terminal 170. Note that the user terminal 120 can also function as a client-type wallet system by using a secure element built into it instead of the wallet management server 140.

[0053] More specifically, in the user terminal 120, a control unit 510, a main memory unit 512, an input unit 514, a display unit 516, an output unit 518, a communication IF 520, an auxiliary memory unit 530, and a secure element 550 are communicably connected to each other via a system bus 500. These components, except for the display unit 516 and the secure element 550, basically operate in the same way as the components of the VC management server 130 or the wallet management server 140, and therefore details will not be described again.

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

[0055] The auxiliary storage unit 530 contains 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 loading executes various calculation processes that handle the processing of various data related to VC management and issuance.

[0056] More specifically, when a payment VC is requested from the payment terminal 170, the VC verification request receiving unit 540 receives it as a request for payment VC verification and returns the payment VP generated by the verification VC selecting unit 546 to the payment terminal 170. The VC verification unit 542 generates a private key from the biometric information of the holder 110 captured as biometric authentication, and verifies the legitimacy of the holder 110 by matching a 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 electronic 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 in the secure element 550. The verification VC selection unit 546 generates a payment VP by selecting the qualification information included in the payment VC so as to limit it to the minimum necessary, according to the payment VC requested by the payment 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 the server-type wallet system, the VC data storage unit 560 stores, for example, a wallet address, a credential ID, a customer ID, an issuer ID, an encrypted VC, a digital signature, and an expiration date as temporary storage of the VC of the holder 110. On the other hand, when the secure element 550 is used as a wallet component based on the client-type wallet system, the VC data storage unit 560 stores, for example, a credential ID, a customer ID, an issuer ID, an encrypted VC, a digital signature, a public key, a change status, a change date and time, and an expiration date as the VC of the holder 110.

[0059] [Internal configuration of the verifier's payment server] Fig. 6A is a configuration diagram showing the internal configuration of the verifier-side payment server 150 in the payment system shown in Fig. 1. Figs. 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 Fig. 6A. As shown in Fig. 6A, the payment server 150 is configured similarly to a computer for general server use, and supports processing functions related to the business of managing VC verification of holders 10 in payment situations and performing payment processing.

[0060] More specifically, in the payment server 150, a control unit 610, a main memory unit 612, an input unit 614, an output unit 616, a communication IF 618, and an auxiliary memory unit 620 are communicably connected to each other via a system bus 600. These components basically operate in the same way as the components of the VC management server 130 or the wallet management server 140, and therefore details will not be described again.

[0061] The auxiliary storage unit 620 includes a VC verification request issuing unit 630, a VC verification unit 632, a transaction management unit 634, a verified VC determination unit 636, and a payment 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 loading executes various calculation processes that handle VC verification and processing of various payment-related data.

[0062] Additionally, auxiliary memory 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 main memory unit 312 based on a call instruction from control unit 610, the subsystem constructed by this loading is used to process various operations that manage data, programs, etc. in the form of files / databases.

[0063] More specifically, when requested by the payment terminal 170 to verify the payment VC, the VC verification request issuing unit 630 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 verification VC determination unit 636 to the payment terminal 170. The VC verification unit 632 verifies the electronic signature corresponding to the VC of the holder 110, using the public key of the holder 110 acquired from the wallet management server 140 or the user terminal 120.

[0064] Furthermore, the transaction management unit 634 manages the execution of a series of indivisible processes required for VC verification and settlement processing, and stores the processing results in the settlement data storage unit 644. The verification VC determination unit 636 further verifies that the settlement VC, whose legitimacy has been verified by the VC verification unit 632, meets the requirements necessary for settlement processing, and instructs it to proceed to settlement processing. Upon receiving an instruction from the verification VC determination unit 636, the settlement data calculation unit 638 stores the execution results of the settlement processing in the settlement data storage unit 644.

[0065] The customer data storage unit 640 stores, as registration information for the customer cardholder 110, for example, a customer ID, name, address, telephone number, email address, gender, and date of birth. The member-related data storage unit 642 holds, for example, the data configuration shown in FIG. 6B and stores membership card information for the cardholder 110. The payment data storage unit 644 holds, for example, the data configuration shown in FIG. 6C and stores payment result information for the cardholder 110. The program storage unit 646 stores programs for executing a series of processes executed as a transaction or other individual processes, and receives calls to these programs from the control unit 610.

[0066] [Internal configuration of merchant payment terminal] 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 specialized client use in order to support functions specialized in accounting processing for retail sales, and as a client of the payment server 150, it plays a part in verifying the VC of the holder 10 and processing the payment in the payment scene.

[0067] More specifically, in the payment terminal 170, a control unit 710, a main memory unit 712, an input unit 714, a display unit 716, a printing unit 718, an output unit 720, a communication IF 722, and an auxiliary memory unit 730 are communicably connected to one another via a system bus 700. These components, except for the display unit 716 and the printing unit 718, basically operate in the same way as the components of the VC management server 130, the wallet management server 140, and the payment server 150, and therefore details will not be described again.

[0068] The display unit 716 displays on the screen instructions received from the holder 110 or staff of the affiliated store 160, or information that requires confirmation by the holder 110 or the staff. The printing unit 718 outputs the payment result data to the built-in printer as the printing target, and as a result, receipts showing the accounting details or the payment result are ejected from the printer outlet as paper separated for each transaction.

[0069] The auxiliary memory unit 730 contains a payment 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 memory unit 712 based on a call instruction from the control unit 710, each application program constructed by this loading executes various calculation processes that handle the processing of various data related to VC verification and payment.

[0070] The auxiliary storage unit 730 also 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 loading is used to process various operations that manage data, programs, etc. in the form of files / databases.

[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 staff of the affiliated store 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 input via each input interface by the user terminal 120, 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 in the VC verification storage unit 760 only those VC verification implementation records for which confirmation acceptance has been carried out at the relevant affiliated store 160.

[0072] Furthermore, the attribute information management unit 746 manages the holder 110's personal attribute information received from the user terminal 120 and additional attribute information directly input by staff at the affiliated store 160, and stores this attribute information in the attribute information storage unit 762. When the holder 110 becomes a member of the affiliated store 160, the membership card information management unit 748 manages only the membership card information for which the application has been accepted at the affiliated store 160, and stores this in the membership card information storage unit 764. The transaction management unit 750 manages the execution of an indivisible series of processes required for VC verification and payment 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, a qualification ID, a customer ID, an issuer ID, an encrypted VC, an electronic signature, a public key, a verification result, a verification date and time, and an expiration date as the VC verification result of the holder 110. The attribute information storage unit 762 stores, as the personal attribute information and additional attribute information, a customer ID, a name, a date of birth, a gender, an address, a membership card number, a held qualification number, a registration method, and a registration date. The membership card information storage unit 764 stores, as the membership card information, a membership card number, a customer ID, a credit card number, a registration method, and a registration date.

[0074] [Payment (offline) process] Regarding the various processes in the payment system described above, first, the following will describe the payment process when the issuer and holder are offline at the time of payment between the holder and the verifier. FIG. 8A is a flowchart showing the payment process in the payment system shown in FIG. 1. FIG. 8B is an integration diagram showing the flows of various data and operations / displays between the various systems included in the payment process shown in FIG. 8A. FIG. 10A is a flowchart showing the key pair registration process included in the various processes shown in FIG. 8A. FIG. 10B is an integration diagram showing the flows of various data and operations / displays between the various systems included in the key pair registration process shown in FIG. 10A. FIG. 11A is a flowchart showing the case where payment VC generation (offline) is included in the payment process shown in FIG. 8A. FIG. 11B is an integration diagram showing the flows of various data and operations / displays between the various systems included in the payment VC generation (offline) process shown in FIG. 11A.

[0075] (When registering a key pair) First, it is necessary to register the key pair of the holder 110 based on a public key cryptosystem on the issuer side. Specifically, as shown in Figures 10A and 10B, when the holder 110 registers as a member on the issuer side, in step S1000, the VC management server 130 on the issuer side transmits key pair request data 1050 to the user terminal 120 of the holder 110. Next, in step S1002, when the user terminal 120 receives the key pair request data 1050 from the VC management server 130, it notifies the holder 110 of a biometric information request display 1052 by the activated agent application for the payment service, and acquires biometric information (e.g., fingerprint, iris, voiceprint, ear feature, facial feature, vein pattern, etc.) from the holder 110 as biometric information input 1154 via each input interface.

[0076] Next, in step S1004, the user terminal 120 generates a private key from the biometric information of the holder 110 based on a public key cryptosystem, further generates a public key from the private key, and transmits key pair data 1156 consisting of the private key and public key to the VC management server 130. Next, in step S1006, the VC management server 130 stores the private key of the holder 110 of the key pair received from the user terminal 120 in the customer data storage unit 350, and transmits public key data 1158 to the wallet management server 140. Next, in step S1008, the wallet management server 140 stores the public key data 1158 of the holder 110 received from the VC management server 130 in the customer data storage unit 440.

[0077] In step S1008, the public key of the holder 110 can be stored in the VC data storage unit 560 in the secure element 550 of the user terminal 120 as a client-side wallet method, instead of being stored in the wallet management server 140 as a server-type wallet method. In that case, in step S1004, only the private key of the holder 110 is to be transmitted from the user terminal 120 to the VC management server 130.

[0078] (VC verification) Next, VC verification of the holder 110 is carried out as a preliminary step to the settlement in which the holder 110 makes a purchase contract for a product / service at the affiliated store 160. Specifically, as shown in FIGS. 8A and 8B, in step S800, when the staff of the affiliated store 160 receives a payment application from the holder 110 and instructs the payment terminal 170 to start the payment, the payment terminal 170 requests the issuance of a payment VC to the holder 110 by a VC issuance request display 850. Next, in step S802, when the holder 110 instructs the user terminal 120 to issue a payment VC by a VC issuance request operation 852, the user terminal 120 transmits VC issuance request data 854 to the VC management server 130.

[0079] Next, in step S804, upon receiving the VC issuance request data 854 from the user terminal 120, the VC management server 130 performs identity verification of the holder 110, for example, based on the FIDO authentication method or the like for the biometric information of the holder 110. Next, in step S806, if the determination result of the identity verification of the holder 110 is approved, the VC management server 130 transmits the encrypted VC data 856 encrypted with the private key of the holder 110 to the wallet management server 140 as encrypted VC data 856. Next, 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, the encrypted VC of the holder 110 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 method, instead of storing it in the wallet management server 140 as a server-type wallet method.

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

[0081] Next, in step S820, when the payment terminal 170 receives determination information issuance request data 864 from the payment server 150, it links determination information issuance request data 866 to the user terminal 120. Next, in step S822, when the user terminal 120 receives determination information issuance request data 866 from the payment terminal 170, it issues determination information data 868 to the payment terminal 170 as a payment VP generated from the payment VC. Next, in step S824, when the payment terminal 170 receives the determination information data 868 from the user terminal 120, it links determination information data 870 to the payment server 170. Next, in step S826, the payment server 170 stores the determination information data 870 received from the payment terminal 170 in the payment data storage unit 644, and transmits verification result data 872 of the payment VC generated based on the determination information data 870 to the payment terminal 170. In addition, in order to generate a settlement VP by minimizing the qualification information required as judgment information, a technique such as ZKP is applied.

[0082] (during payment processing) Thereafter, a payment process is carried out between the holder 110 and the affiliated store 160 as a payment stage in which the holder 110 makes a purchase contract for a product / service at the affiliated store 160. Specifically, as shown in FIGS. 8A and 8B, in step S830, the payment terminal 170 stores verification result data 872 of the payment VC received by the payment terminal 170 in the VC verification storage unit 760. Next, in step S832, if the judgment result of the verification result of the payment VC received by the payment terminal 170 is approved, when a staff member of the affiliated store 160 executes a product information reading operation 874 on the product / service that the holder 110 is to purchase, the payment terminal 170 executes a product information linking process with a POS system (not shown) and then presents a payment details display 876 to the holder 110. Next, in step S834, when the holder 110 executes a payment approval operation 878 to the payment terminal 170, the payment terminal 170 transmits payment approval data 880 to the payment server 150.

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

[0084] (When generating VC for payment) 11A and 11B, in step S1100, user terminal 120 transmits payment VC issuance request data 1150 to wallet management server 140 based on instructions from holder 110. In step S1110, upon receiving payment VC issuance request data 1150 from user terminal 120, wallet management server 140 transmits digital signature request data 1170 to user terminal 120. Subsequently, in step S1112, upon receiving digital signature request data 1160 from wallet management server 140, user terminal 120 notifies holder 110 of biometric information request display 1162 by the activated payment service agent application, and acquires biometric information (e.g., fingerprint, iris, voiceprint, ear feature, facial feature, vein pattern, etc.) from holder 110 as biometric information input 1164 via each input interface.

[0085] Next, in step S1114, the user terminal 120 generates a private key from the biometric information of the holder 110 based on public key cryptography. Then, in step S1116, the user terminal 120 generates a digital signature from the private key of the holder 110. Then, in step S1120, the user terminal 120 transmits public key issuance request data 1166 to the wallet management server 140.

[0086] Next, in step S1122, upon receiving public key issuance request data 1166 from user terminal 120, wallet management server 140 issues public key data 1168 to user terminal 120 as the public key of holder 110. Next, in step S1126, user terminal 120 verifies the digital signature of holder 110 using public key data 1168 received from wallet management server 140. Next, in step S1128, user terminal 120 transmits authentication result data 1170 to wallet management server 140. Next, in step S1130, wallet management server 140 stores authentication result data 1170 received from user terminal 120 in customer data storage unit 440.

[0087] Next, in step S1140, the user terminal 120 transmits 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 transmits 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 a payment VC display 1176 by the agent application for payment service.

[0088] Note that from step S1100 onwards, data exchange between the user terminal 120 and the wallet management server 140 is implemented as a server-type wallet system, but this can alternatively be replaced with a client-side wallet system in which data is exchanged between the payment service agent app and the secure element 550 within the user terminal 120.

[0089] [Online Payment Process] Regarding the various processes in the payment system described above, the following secondly describes the payment process when the issuer and holder are online at the time of settlement between the holder and verifier. In this case, the processes described above with reference to Figures 8A, 8B, 10A, and 10B are common to the payment (online) process. However, as will be described later with reference to Figures 12A and 12B, the process related to payment VC generation differs from the payment (offline) process. Therefore, the following will not again explain the processes common to the payment (offline) process, but will only explain the processes that differ from the payment (offline) process. Figure 12A is a flowchart showing the case where payment VC generation (online) is included in the payment process shown in Figure 8A. Figure 12B is an integration diagram showing the flow of various data and operations / displays between various systems included in the payment VC generation (online) process shown in Figure 12A.

[0090] (When generating VC for payment) Below, a detailed description will be given of the case where a payment VC generation (online) process is included in step S810. As shown in Figures 12A and 12B, the process from step S1100, in which user terminal 120 requests wallet management server 140 to issue a payment VC, to step S1130, in which wallet management server 140 receives the authentication result from user terminal 120, is common to the case of the payment VC generation (offline) process described above, so below, only the process that is different from the payment (offline) process will be described without explaining again what is common to the payment (offline) process.

[0091] 12A and 12B, in step S1200, the user terminal 120 transmits 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 transmits 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 transmits the payment VC data 1254 to the VC management server 130. Subsequently, in step S1208, upon receiving the payment VC data 1254 from the wallet management server 140, the VC management server 130 transmits 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 transmits payment VC data 1258 corresponding to the payment VC data 1256 to the payment terminal 170. Subsequently, upon receiving the payment VC data 1258 from the payment server 150, the payment terminal 170 displays a payment VC display 1260 on the screen as information that requires confirmation by the staff of the affiliated store 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 will be described below. Fig. 9A is a flowchart showing the identity verification (new registration) process in the payment system shown in Fig. 1. Fig. 9B is an integration diagram showing the various data and operation / display flows between the various systems included in the identity verification (new registration) process shown in Fig. 9A. Fig. 10A is a flowchart showing the key pair registration process included in the various processes shown in Fig. 9A. Fig. 10B is an integration diagram showing the various data and operation / display flows between the various systems included in the key pair registration process shown in Fig. 10A.

[0094] First, it is necessary to register the key pair of the holder 110 based on the public key cryptography on the issuer side. Specifically, this is as explained in the payment process described above with reference to FIGS. 10A and 10B. Next, VC verification of the holder 110 is performed as a stage where the holder 110 undergoes identity verification (new registration) at the affiliated store 160. As shown in FIGS. 9A and 9B, the process from step S800, in which the payment terminal 170 requests the holder 110 to issue a VC, to step S808, in which the wallet management server 140 receives the encrypted VC from the VC management server 130, is common to the above-mentioned payment process (offline / online). Therefore, in the following, only the process that is different from the payment process (offline / online) will be explained without repeating the explanation of the common parts with the payment process (offline / online).

[0095] 9A and 9B, in step S900, when the holder 110 instructs the user terminal 120 to disclose VC by a VC disclosure instruction operation 950, the user terminal 120 instructs the payment terminal 170 to transmit personal identification VC data 952 from the wallet management server 140 via the user terminal 120 based on the selection result of the personal identification VC by the holder 110. Next, in step S902, the payment terminal 170 stores the personal identification VC received from the user terminal 120 in the VC verification storage unit 760. Next, in step S904, the payment terminal 170 transmits personal identification VC verification request data 854 to the payment server 150. Next, in step S906, the payment server 150 stores the personal identification VC verification request data 854 received from the payment terminal 170 in the customer data storage unit 640, and sends judgment information issuance request data 956 to the payment terminal 170 to start verification of the personal identification VC.

[0096] Next, in step S910, upon receiving determination information issuance request data 956 from the payment server 150, the payment terminal 170 links determination information issuance request data 958 to the user terminal 120. Next, in step S912, upon receiving the determination information issuance request data 958 from the payment terminal 170, the user terminal 120 issues determination information data 960 to the payment terminal 170 as a personal identification VP generated from the personal identification VC. Next, in step S914, upon receiving the determination information data 960 from the user terminal 120, the payment terminal 170 links determination information data 962 to the payment server 170. Next, in step S916, the payment server 170 stores the determination information data 962 received from the payment terminal 170 in the customer data storage unit 640, and transmits personal identification completion notification data 964 generated based on the determination information to the payment terminal 170. In order to generate a VP for personal authentication while minimizing the information required as judgment information, a technique such as ZKP is applied.

[0097] [Effects of the embodiment] In this way, according to an embodiment of the present invention, affiliated stores of cashless payment brands can accommodate various types of cashless payment that are expected to develop in a versatile manner in the future, and in particular, can provide service users with functionality such as providing personal authentication to meet various requirements for various credentials, or protecting privacy through selective disclosure of credentials, while maintaining prevention of fraudulent use in cardless payment scenarios.

[0098] More specifically, the effects enjoyed by the cardholder, issuer, and verifier according to the present invention are as follows. First, as an effect enjoyed by the cardholder, by utilizing it as a KYC function for age information in various card authentications, a completely cardless consumption experience can be provided to the cardholder. For example, this includes a seamless experience at an unmanned register, from verifying the cardholder's age to payment via point card integration. In addition, a payment experience can be provided that combines VC related to one attribute from one issuer with VC related to another attribute from another issuer. Examples include purchasing alcoholic beverages for those 20 years of age or older, discounted purchases exclusive to city residents, and limited-quantity online purchases.

[0099] Furthermore, the benefits enjoyed by cardholders include lowering the entry barrier for initial membership registration by converting KYC information into a VC and sharing it in accordance with the Criminal Proceeds Act (Act on Prevention of Transfer of Criminal Proceeds). It also provides fraud prevention through a scheme that allows only secure transactions without the card itself being held. It also ensures privacy through selective disclosure. For example, when purchasing alcohol at a convenience store, this prevents store staff from misusing unnecessary information such as address, name, license number, etc., other than the required age, or preventing store staff from stealing card numbers when making credit card payments.

[0100] Secondly, issuers can enjoy benefits such as reduced administrative work 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, new payment experiences include seamless data integration with other issuers' services and user-friendly onboarding to new services.

[0101] Third, as an effect enjoyed by the verifier's affiliated store (e.g., a retail store), it is possible to reduce store operating costs by guiding purchasers of alcohol, tobacco, etc. to unmanned registers. Furthermore, by utilizing a software development kit (SDK) containing the mechanisms or information necessary to implement the present invention, it is possible to provide easy integration with the verifier's point program. Furthermore, it is possible to reduce cash management costs through seamless integration leading up to payment. Furthermore, it is possible to reduce the risk of selling to minors by providing age verification that is more rigorous than visual verification by store staff.

[0102] Although the principles of the present invention have been described above with reference to exemplary embodiments, it should be understood by those skilled in the art that various modifications in configuration and detail can be made without departing from the spirit and scope of the present invention. That is, the present invention can be implemented in various forms, for example, as a system, an apparatus, a method, a program, or a storage medium. [Explanation of symbols]

[0103] 100 communication lines 110 holders 120 user terminals 130 Issuer VC Management Server 140 Issuer's Wallet Management Server 150 Verifier payment server 160 member stores 170 Merchant payment terminal 300 System Bus 310 Control Unit 312 Main memory 314 Input section 316 Output section 318 Communication IF Section 320 Auxiliary storage 330 VC Management Department 332 VC Publishing Department 334 Transaction Management Unit 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 Memory Unit 400 System Bus 410 Control Unit 412 Main memory 414 Input section 416 Output section 418 Communication IF Section 420 Auxiliary storage 430 Wallet Address Management Department 432 Wallet Address Issuance Department 434 Transaction Management Unit 436 Customer Data Management Department 438 Encryption section 440 Customer Data Storage Unit 500 System Bus 510 control section 512 Main memory 514 Input section 516 Display section 518 Output Section 520 Communication IF section 530 Auxiliary storage unit 540 VC Verification Request Receipt Department 542 VC Verification Department 544 Transaction Management Unit 546 Verification VC Selection Unit 550 Secure Element 560 VC data storage unit 600 System Bus 610 Control Unit 612 Main memory 614 Input section 616 Output section 618 Communication IF Section 620 Auxiliary storage 630 VC Verification and Issuance Department 632 VC Verification Department 634 Transaction Management Unit 636 Verification VC Judgment Unit 638 Payment Data Production Department 640 Customer Data Storage Unit 642 Member-related data storage unit 644 Payment data storage unit 646 Program Memory Unit 700 System Bus 710 Control Unit 712 Main memory 714 Input section 716 Display section 718 Printing Department 720 Output Unit 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 Card 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 payment system for settling a sales contract between a payment brand and an issuer that has a business contract with the payment brand, a holder who is a member of the payment brand, and a verifier that has a transaction contract with the payment brand, at a merchant that has a merchant contract with the verifier, based on the verification result by the verifier of qualification information provided by the holder, wherein: A VC management server is installed on the issuer side and determines whether to issue the credential information to be provided to the user terminal as verifiable credential information (VC) based on a request from the user terminal used by the holder; a data registry that manages the VC based on an instruction from the VC management server and issues the VC to the user terminal based on a determination result from the VC management server and a request from the user terminal; A payment server is installed on the verifier side, and after verifying the verifiable presentation (VP) generated from the VC, executes payment processing for the sales contract; a payment terminal installed at the affiliated store, which requests the payment server to verify the VC provided from the data registry via the user terminal, and then requests the payment server to perform the payment process based on the verification result of the VP; A payment system comprising:

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

3. The payment system of claim 1, characterized in that the VP generated from the VC presents the verifier with the minimum necessary credential information about the holder required to verify the VC based on a zero-knowledge proof (ZKP) technique provided to the payment server.

4. 2. The payment system according to claim 1, wherein the VC is assigned a different electronic signature for each piece of information (Claim) that constitutes the qualification information and is encrypted based on a different encryption key.

5. The payment system of claim 4, wherein the electronic signature is a digital signature based on a public key cryptosystem, and the VC is encrypted with the holder's private key and decrypted with the holder's public key based on the public key cryptosystem.

6. 6. The payment system of claim 5, wherein the private key is generated based on a decentralized identifier (DID) generated by a functional transformation of the holder's biometric information, the public key is generated from the private key based on elliptic curve cryptography, and the DID is set to be different for each of a plurality of payment services across the payment brand, the issuer, and the holder.

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

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

9. A payment system that handles a sales contract between a holder and a merchant that has a merchant contract with the verifier, based on a verification result by the verifier of the qualification information provided by the holder, in a payment scenario spanning between an issuer that has a business contract with a payment brand, a holder that is a member of the payment brand, and a verifier that has a transaction contract with the payment brand, the method comprising: In a VC management server installed on the issuer side, based on a request from a user terminal used by the holder, determining whether to issue the credential information to be provided to the user terminal as verifiable credential information (VC); a step of issuing the VC to the user terminal in a data registry that manages the VC based on an instruction from the VC management server, based on a determination result of the VC management server and a request from the user terminal; A step of requesting a payment server installed on the verifier side to verify the VC issued from the data registry via the user terminal at a payment terminal installed at the affiliated store; In the payment server, verifying a verifiable presentation (VP) based on the VC provided from the payment server, and providing a verification result of the VP to the payment terminal; a step of determining, in the payment terminal, whether to request the payment processing from the payment server based on the verification result provided from the payment terminal; A method comprising:

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

Images