Device, System, and Method for Electronic Cashless Payment
Patent Information
- Application Number
- JP2024562796
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2022-04-22
- Filing Date
- 2023-03-23
- Publication Date
- 2025-06-25
- Estimated Expiration
- 2043-03-23
AI Technical Summary
Existing cashless payment systems lack the ability to track the identities of payers and payees, especially when transactions exceed a certain threshold, compromising anonymity and traceability.
A system and method that utilize a trust service provider to verify the identity of the payer, store the identity with a transaction ID, digitally sign the transaction ID, and store the signed ID in a money ledger, allowing for anonymous transactions below a threshold while enabling traceability above it.
The solution maintains anonymity in transactions below a certain amount while ensuring traceability when necessary, enhancing security and compliance with regulatory requirements.
Smart Images

Figure 00000000_0000_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to a device, system, and method for electronic cashless payment.
Background Art
[0002] As digitization increases, cashless payment devices, especially those based on electronic payment processing methods, are becoming increasingly prominent. A cashless payment transaction includes the transfer of a means of payment without the transfer of cash. Cash payment involves the exchange of cash, i.e., banknotes or coins, between the payer and the payee, whereas cashless payment does not involve such an exchange of cash.
[0003] Cash has the advantage, for example, that it is available to everyone and can be used quickly anywhere. For example, a bank account is not required for cash-based payment processing. In addition, cash is often evaluated by its owner as a way to preserve value. On the other hand, cashless payment methods have the advantage of enabling efficient payment processing even when the payer and payee are in remote locations, such as in the case of a purchase via the Internet.
[0004] In a cash transaction, the anonymity of the parties involved is essentially maintained. Although cashless electronic payment methods can sometimes be executed anonymously, for example, due to legal regulations, when the amount exceeds a certain limit, it may be necessary to collect and make traceable the identities of the parties involved, i.e., the payer and the payee. In the case of a blockchain-based cashless electronic payment method such as Bitcoin, such traceability is usually not available.
Prior Art Documents
Patent Documents
[0005]
Patent Document 1
Patent Document 2
SUMMARY OF THE INVENTION
PROBLEMS TO BE SOLVED BY THE INVENTION
[0006] An object of the present invention is to generate a concept of electronic cashless payment that enables the tracking of the identities of relevant parties, namely the payer and the payee, when necessary.
MEANS FOR SOLVING THE PROBLEMS
[0007] This object is achieved by the features of the independent claims. Advantageous embodiments are the subject matter of the dependent patent claims, the specification and the drawings.
[0008] Embodiments of the present invention described herein are based on the idea that a trust service provider, particularly a trust center, verifies the identity of the payer, stores the identity of the payer in a database together with a transaction ID, digitally signs the transaction ID, and stores the signed transaction ID in a money ledger by a data communication device, such as a smartphone, in order to execute a cashless electronic transaction. According to one embodiment, when the transaction amount exceeds a threshold value, the trust center can execute the link of the transaction to the identity of the payer. In the case of a transaction with an amount below the threshold value, the data communication device can store the transaction without involving the trust center, that is, the transaction can be executed completely anonymously. By linking the transaction to the identity of the payer by the trust center, the anonymity of the transaction on the money ledger can be maintained, but it can be tracked if necessary.
[0009] According to a first aspect, a data communication device for performing an electronic payment transaction is provided. The data communication device includes at least one processor configured to execute a payment application and an ID application, and a communication interface configured to communicate with a trust center server device and a money ledger. The payment application is configured to send a transaction ID and a decentralized identity (DID) of a user of the data communication device to a payment agent of the trust center server device. The ID application is configured to send signed user authentication information of a user of the data communication device to an ID agent of the trust center server device in response to a request including the DID from the ID agent of the trust center server device. The payment application is further configured to receive a signature of the transaction ID from the payment agent of the trust center server device and send the signature of the transaction ID to the money ledger to register the electronic payment transaction with the signature of the transaction ID in the money ledger.
[0010] In one embodiment, to perform a further electronic payment transaction for an amount less than a threshold value, the payment application is configured to send a further transaction ID of the further electronic payment transaction to the money ledger without a signature of the further transaction ID to register the electronic payment transaction with the further transaction ID in the money ledger without a signature of the further transaction ID.
[0011] In one embodiment, the payment application is further configured to generate a transaction ID and / or receive a DID of a user of the data communication device from the ID application upon request.
[0012] In one embodiment, the ID application is further configured to send zero-knowledge proof data to an ID agent of the trust center server device in response to a request from the ID agent of the trust center server device to verify the signed user authentication information of a user of the data communication device.
[0013] In one embodiment, the payment application is further configured to send a further DID of a further user of a further data communication device, along with the transaction ID and the DID of the user of the data communication device, to the payment agent of the trust center server device. In one embodiment, the further user of the further data communication device is the payee.
[0014] In one embodiment, the data communication device is a mobile and portable data communication device, particularly a smartphone.
[0015] According to a second aspect, a method for operating a data communication device to perform an electronic payment transaction is provided, the data communication device comprising at least one processor configured to execute a payment application and an ID application, and a communication interface configured to communicate with a trust center server device and a money ledger. The method comprises the following steps, namely, sending, from the payment application, the transaction ID and the decentralized identity (DID) of the user of the data communication device to the payment agent of the trust center server device; responding to a request containing the DID from the ID agent of the trust center server device by sending, from the ID application, the signed user authentication information of the user of the data communication device to the ID agent of the trust center server device; receiving, by the payment application, the signature of the transaction ID from the payment agent of the trust center server device; sending, from the payment application, the signature of the transaction ID to the money ledger to register the electronic payment transaction in the money ledger together with the signature of the transaction ID; including.
[0016] According to a third aspect, a trust center server device is provided for the execution of an electronic payment transaction. The trust center server device includes at least one processor configured to execute a payment agent and an ID agent, a communication interface configured to communicate with a data communication device, and a memory for storing electronic data. The payment agent is configured to receive a transaction ID and a decentralized identity (DID) of a user of the data communication device from a payment application of the data communication device. The ID agent is configured to obtain signed user authentication information of a user of the data communication device from an ID application of the data communication device in response to a request from the payment agent including a DID for user authentication information of a user of the data communication device. The payment agent is further configured to obtain user authentication information of a user of the data communication device and store these together with the transaction ID in the memory. The payment agent is further configured to sign the transaction ID and transmit the signed transaction ID to the payment application of the data communication device to enable registering the electronic payment transaction with the transaction ID signature in a money ledger.
[0017] In one embodiment, the communication interface is further configured to communicate with an ID ledger, and the ID agent is further configured to receive zero-knowledge proof data from an ID application of the data communication device and verify the signed user authentication information of the user of the data communication device by the zero-knowledge proof data and the ID ledger.
[0018] According to a fourth aspect, a method for operating a trust center server device for executing an electronic payment transaction is provided, the trust center server device including at least one processor configured to execute a payment agent and an ID agent, a communication interface configured to communicate with a data communication device, and a memory for storing electronic data. The method includes the following steps, namely, A step of receiving, by a payment agent, a transaction ID and a decentralized identity (DID) of a user of the data communication device from a payment application of the data communication device; In response to a request from the payment agent including a DID for user authentication information of the user of the data communication device, a step of obtaining, by the ID agent, signed user authentication information of the user of the data communication device from an ID application of the data communication device; A step of obtaining, by the payment agent, user authentication information of the user of the data communication device; A step of storing, by the payment agent, user authentication information of the user of the data communication device together with the transaction ID in a memory; A step of transmitting, from the payment agent to the payment application of the data communication device, a signed transaction ID to enable registration of an electronic payment transaction in a ledger together with a signature of the transaction ID; including.
[0019] According to a fifth aspect, a system for executing an electronic payment transaction is provided, the system comprising a plurality of data communication devices according to the first aspect and a trust center server device according to the third aspect.
[0020] Different aspects of the present invention can be implemented in hardware and / or software.
[0021] With reference to the accompanying drawings, further embodiments are described in more detail.
Brief Description of the Drawings
[0022]
Figure 1
Figure 2
Figure 3
Figure 4
Embodiments for Carrying Out the Invention
[0023] Elements of the embodiments described in detail below that correspond to each other are identified by the same reference numerals.
[0024] Here, and hereinafter, "blockchain" is understood to be an ordered data structure including a number of data blocks linked together. In particular, in a blockchain, each block (except the first block) includes a check value, such as a hash value, of the previous block, so that it is an ordered data structure in which the validity of all previous blocks can be checked and, if necessary, each block can be used for verification. The concept of blockchain was described, for example, in 2008 in a white paper on Bitcoin under the pseudonym Satoshi Nakamoto, "Bitcoin: Peer-to-Peer Electronic Cash System" (https: / / bitcoin.org / bitcoin.pdf). The blockchain described herein consists of a series of data in which one or more entries or transactions are summarized and a checksum is provided in the form of a hash value. Additional blocks of the blockchain are generated, for example, by a computationally intensive process also known as mining. These additionally generated blocks are then added to the blockchain and distributed via the network to all participants or nodes of the network.
[0025] An embodiment can have the advantage that the blockchain provides a high degree of security against subsequent tampering by storing the cryptographic checksum, i.e., the hash value, of the previous block in the subsequent block. Next, the blockchain can be checked using these root hash values. Each block of the blockchain includes a hash of the entire header of the previous block in its header. This clearly defines the order of the blocks and generates a chain structure. By chaining the individual blocks in this way, it becomes necessary to recompute the hash values of all subsequent blocks in a short period of time, and thereafter it is practically impossible to change the previous block or an individual entry.
[0026] According to one embodiment, the blockchain is a blockchain in which only a selected group of participants has the right to add valid blocks. Such a right can be proven, for example, by a signature using a secret cryptographic key. The secret cryptographic key can belong to an asymmetric key pair that also includes a public cryptographic key that can verify the signature. For the asymmetric key pair, a certificate can also be assigned, for example, to prove the right to create valid blocks of the blockchain. This certificate can also be assigned to a PKI that proves the reliability of the certificate. According to another embodiment, the public key can be stored in the blockchain in the initialization entry of an additional participant who is added to the selected group. Using these public keys, it is possible to check the signature of a block and thus whether the corresponding block itself is valid. The public keys of the original participants in the selected group can be stored, for example, in the genesis block of the blockchain.
[0027] For example, a blockchain managed by a central bank is a public blockchain managed on the central bank's blockchain server. For example, new blocks are only input by these blockchain servers managed by the central bank. In this case, the computationally intensive process can be eliminated when adding additional blocks. For example, all that is required to add an additional block is only a signature with a signature key assigned to the central bank.
[0028] A trust center represents a trustworthy third party that can prove the identity of a communication partner in an electronic communication process. For example, in an electronic communication related to an electronic signature, the trust center can issue a certificate that can be used to prove the identity of the communication partner.
[0029] The "communication interface" or "plurality of communication interfaces" is here understood to be, for example, an interface through which data can be transmitted and received, and the communication interface can be configured as contact type or non-contact type.
[0030] Communication can be carried out, for example, via a network. The "network" is here understood to mean any transmission medium having a connection for communication, in particular a local connection or a local network, in particular a local area network (LAN), a private network, in particular an intranet, and a digital private network (virtual private network (VPN)). For example, a computer system can have a standard wireless interface for connection to a WLAN. This can also be a public network such as the Internet. Depending on the embodiment, this connection can also be established via a mobile network.
[0031] "Processor" is understood here and hereinafter to mean a logic circuit that performs the role of executing program instructions. The logic circuit can be implemented on one or more distributed components, particularly on a chip. A processor includes, for example, an arithmetic unit, a control unit, registers, and data lines for communication with other components. In particular, "processor" is understood to mean a microprocessor or a microprocessor system comprising several processor cores and / or several microprocessors. A processor is configured to execute program instructions stored, for example, in a memory, in order to execute the operations and methods described herein.
[0032] "Memory" is understood here to particularly mean non-volatile memory. "Non-volatile memory" is understood here to mean, for example, electronic memory for the permanent storage of data. Non-volatile memory can be configured as non-exchangeable memory, also called read-only memory (ROM), or as exchangeable memory, also called non-volatile memory (NVM). In particular, this can be EEPROM, for example flash EEPROM, abbreviated as flash. Non-volatile memory is characterized by the stored data being retained even after the power is switched off.
[0033] The "protected memory area" is here understood to be an area of electronic memory where access, i.e., read access or write access, is only possible via the processor of the security element. For example, external access to the protected memory area is not possible, i.e., data cannot be brought in from the outside nor output to the outside. For example, data can be read from the protected memory area via the processor. For example, data can be brought into the protected memory area from the outside via the processor. According to an embodiment, access from or via the processor coupled to the memory is only possible if the conditions necessary therefor are met. This can be, for example, cryptographic conditions, in particular successful authentication and / or successful authentication checks. Such checks can be based, for example, on an electronic signature using a signature key.
[0034] Asymmetric key pairs are used for a wide variety of cryptographic systems and also play an important role in the signing of electronic data. An asymmetric key pair consists of a public key that is used to encrypt and / or decrypt data and can be passed to a third party, and a private key that is used to encrypt and / or decrypt data and generally must be kept secret. The public key enables everyone to encrypt data for the owner of the private key and to verify digital signatures created using the private key. The private key enables the owner to decrypt data encrypted using the public key and to create digital signatures. Signatures created using the private key can be verified using the associated public key.
[0035] The creation of a digital signature, which is also simply called "signature" here, is an encryption process in which an additional data value called "signature" is calculated for any data. The signature can be, for example, the hash value of the source data encrypted using a secret cryptographic key.
[0036] Here, the security element is understood to be, for example, an electronic component including a processor and a memory where only specific predetermined access is permitted. For example, only specific data values stored in a specific area of the memory can be read. For example, data values stored in a protected memory area cannot be read. For example, a digital signature is required to write a data value to the memory of the security element, and its verification key is stored within the security element. For example, only the processor has write permission to write data into a protected memory area.
[0037] The security element further provides cryptographic core routines, for example, in the form of cryptographic program instructions using cryptographic algorithms for signature creation and / or verification, key generation, and / or random number generation, and can further serve as a secure storage for cryptographic keys.
[0038] For example, at least a part of the security element is signed. Before the security element is used, it is verified whether one signature or multiple signatures are valid. If one of the signatures is not valid, for example, the use of the security element is blocked.
[0039] For example, the security element has physically limited access options. In addition, the security element can have additional countermeasures against misuse, especially against unauthorized access to the data within the memory of the security element. For example, the means for protecting the security element against unauthorized tampering are, for example, intended to prevent the security element or its components from being opened, or, if an attempt is made to intervene in the security element, include mechanical means that render the security element inoperable, for example, by causing data loss. For example, at least a part of the security element may be encapsulated, molded, and / or laminated within a material, and attempts to remove this will inevitably destroy the corresponding part of the security element.
[0040] FIG. 1 shows a system 100 for a traceable execution of an electronic cashless payment between a first data communication device 110 of a paying user 110a and a second data communication device 120 of a payee. The first and / or second data communication devices 110, 120 can each be mobile and portable data communication devices 110, 120, particularly smartphones 110, 120. In the embodiments described below, the data communication devices 110, 120 are exemplary smartphones 110, 120.
[0041] In the embodiment shown in FIG. 1, the smartphone 110 of the paying user 110a and the smartphone 120 of the payee each include one or more processors 111, 121, communication interfaces 113, 123 for wireless and / or wired communication via a communication network, and memories 115, 125 for storing electronic data. The smartphones 110, 120 can each include a security element, such as a virtual or physical SIM card, configured to store security-critical data and / or execute security-critical operations, particularly encryption operations.
[0042] As shown in FIG. 1, the processors 111, 121 of the respective smartphones 110, 120 are configured to execute a payment application 111a, 121a and an ID application or identification application 111b, 121b, the functions of which and their interaction with each other and with other components of the system 100 will be described in more detail below with further reference to FIG. 2.
[0043] In addition to the smartphone 110 of the paying user 110a and the smartphone 120 of the payee, the system 100 includes a trust center server device 130, an ID ledger 140 for self-determined identities (self-sovereign identities (SSI), and thus also referred to as the "SSI ledger" 140 in FIG. 1), a money ledger 150, such as a blockchain 150, and a central bank or central bank server 160 for managing the money ledger 150. The trust center server device 130 can include one or more servers having one or more processors 131, a communication interface 133 for wireless and / or wired communication via a communication network, and a memory 135 for storing electronic data.
[0044] As shown in FIG. 1, at least one processor 131 of the trust center server device 130 is configured to execute a payment agent 131a (or payment service 131a) and an ID agent 131b (or ID service 131b), and its functions and interactions with each other and with other components of the system 100 will be described in detail below with further reference to FIG. 2.
[0045] The money ledger 150 can be implemented, for example, on one or more blockchain servers. In other words, the blockchain server can be part of the money ledger network 150 and thus can be a blockchain node of the money ledger 150. The blockchain server and / or the money ledger 150, i.e., the blockchain network 150, can be managed, for example, by the central bank 160. If the central bank 160 is a central bank to which several countries belong, the money ledger 150 can include, for example, one or more blockchain servers per country.
[0046] FIG. 2 shows the interactions of the components of the system 100 shown in FIG. 1 according to one embodiment.
[0047] Payment user 110a wishes to pay a specific amount to the payee via the payee's smartphone 120 using the payment user's smartphone 110. To do this, in step 201 of FIG. 2, user 110a starts a payment application 111a (referred to as "payment application" in FIG. 2) on his / her smartphone 110.
[0048] In the embodiment shown in FIG. 2, the payment application 111a implemented by the processor 111 first checks the amount to be paid. If this amount is higher than a threshold value (e.g., a legally defined threshold value), the smartphone 110 executes further steps shown in FIG. 2 (step 203 in FIG. 2). Otherwise, i.e., if the amount to be paid is below the threshold value, the payment transaction can be executed without the trust center 130 and registered on the money ledger 150 in an essentially known manner. However, according to the present invention, embodiments are also provided in which this check is omitted and the steps described below are executed regardless of the amount to be paid.
[0049] In the example shown in FIG. 2, since the amount to be paid exceeds the threshold value, the payment application 111a implemented by the processor 111 generates a request in step 205 of FIG. 2 and sends this via the communication interface 113 to the trust center 130, specifically to the payment agent 131a of the trust center 130 (identified as "TSE agent" 131a in FIG. 2), in order to receive a transaction ID digitally signed by the trust center 130. In response to the request in step 205, the payment agent 131a then sends a request to the payment application 111a in step 207 of FIG. 2 regarding the transaction ID and the distributed ID of the user 110a of the smartphone 110. In one embodiment, the transaction ID can be generated by the payment application 111a of the smartphone.
[0050] In step 209 of FIG. 2 executed within the smartphone 110, the payment application 111a first sends a request to the ID application 111b and, as a response, receives from the ID application 111b the decentralized ID (DID, also known as "Decentralized Identifier" in English) of the payment user 110a of the smartphone 110.
[0051] In step 210 of FIG. 2, the payment application 111a of the smartphone 110 sends the DID received from the ID application 111b and the transaction ID to the payment agent 131a of the trust center 130.
[0052] In step 211 of FIG. 2, the payment agent 131a of the trust center 130 sends a request for the "user authentication information" (or user information) of the user 110a to the ID agent 131b of the trust center 130. The request includes the DID received from the ID application 111b of the smartphone 110. The ID agent 131b essentially plays the role of automatically verifying the identity in the SSI ledger (or ID ledger) 140 based on the "decentralized ledger technology (DLT)".
[0053] In step 213 of FIG. 2, the ID agent 131b of the trust center 130 sends a request for user authentication information, that is, a request for user information to identify the identity of the user 110a of the smartphone 110 by the SSI ledger 140, to the ID application 111b of the smartphone 110. The request includes the DID first received from the ID application 111b.
[0054] In step 215 of FIG. 2, the ID application 111b of the smartphone 110 signs the user authentication information or user information using the private key of the smartphone 110. Such a private key can be stored, for example, in a secure memory area of a security element, such as a virtual or physical SIM card of the smartphone 110. As already explained above, in such a security element, security-critical encryption operations of the ID application 111b and / or the payment application 111a can be performed.
[0055] In step 217 of FIG. 2, the ID application 111b of the smartphone 110 proves the reliability of the certificate or user information transmitted in step 215 by means of a zero-knowledge proof (ZKP).
[0056] In step 219 of FIG. 2, the ID agent 131b of the trust center 130 obtains from the ID ledger 140 data for checking or verifying the ZKP of step 217 by downloading this data from the ID ledger 140 (step 221 of FIG. 2).
[0057] After the ZKP has been verified by the ID agent 131b of the trust center 130 (based on which the ID agent 131a can trust the user authentication information), the ID agent 131b of the trust center 130 transmits the user authentication information to the payment agent 131a in step 223 of FIG. 2. Next, the payment agent 131a stores the signed transaction ID, together with the user authentication information, in the database 135a implemented in the memory 135 (step 225 of FIG. 2). In one embodiment, the payment agent 131a can also assign an identification number therefor and link this to the transaction ID.
[0058] In step 227, the payment agent 131a of the trust center 130 transmits the signed transaction ID to the payment application 111a of the smartphone 110. Therefore, step 227 ultimately represents the response of the trust center 130 to the signed transaction ID requested in step 205.
[0059] In step 229 of FIG. 2, to complete the payment transaction, the payment application 111a transmits the transaction data, namely, in particular, the transaction ID and the amount, as well as the signature of the transaction ID, to the money ledger 150. Here, this data is registered or stored as required to be made available to the central bank server 160 for tracking. In this way, the payment process is completed. Optionally, the identity of the payment recipient, namely, the user of the further smartphone 120, can also be registered by the payment application 111a that obtains the DID of the user of the further smartphone 120. In this case, the identity agent 131b of the trust center 130 can establish two separate connections, namely, one connection to the smartphone 110 of the payment user 110a and the other connection to the smartphone of the payment recipient.
[0060] FIG. 3 shows a flowchart showing the steps of a method 300 for operating the data communication device 110 according to an embodiment. The method 300 includes the following steps, namely, Step 301 of transmitting the transaction ID and the decentralized identity (DID) of the user 110a of the data communication device 110 from the payment application 111a to the payment agent 131a of the trust center server device 130; Step 303 of transmitting the signed user authentication information of the user 110a of the data communication device 110 from the ID application 111b to the ID agent 131b of the trust center server device 130 in response to a request including the DID from the ID agent 131b of the trust center server device 130; Step 305 of receiving a signature of a transaction ID from the payment agent 131b of the trust center server device 130 by the payment application 111a; Step 307 of transmitting the signature of the transaction ID from the payment application 111a to the money ledger 150 in order to register the electronic payment transaction in the money ledger 150 together with the signature of the transaction ID; includes.
[0061] FIG. 4 shows a flowchart showing steps of a method 400 for operating the trust center server device 130 according to an embodiment. The method 400 includes the following steps, namely, Step 401 of receiving, by the payment agent 131a, a transaction ID and a decentralized identity (DID) of the user 110a of the data communication device 110 from the payment application 111a of the data communication device 110; In response to a request including a DID from the payment agent 131a regarding user authentication information of the user 110a of the data communication device 110, step 403 of obtaining, by the ID agent 131b, signed user authentication information of the user 110a of the data communication device 110 from the ID application 111b of the data communication device 110; Step 405 of obtaining, by the payment agent 131a, user authentication information of the user 110a of the data communication device 110; Step 407 of storing, by the payment agent 131a, user authentication information of the user 110a of the data communication device 110 together with the transaction ID in the memory 135; Step 409 of transmitting a signed transaction ID from the payment agent 131a to the payment application 111a of the data communication device 110 in order to enable registration of the electronic payment transaction in the money ledger 150 together with the signature of the transaction ID; includes.
Description of Reference Numerals
[0062] 100 Electronic payment system, 110 Data communication device of the payer, 110a Payer user, 111 Processor, 111a Payment application, 111b ID application, 113 Communication interface, 115 Memory, 120 Data communication device of the payee, 121 Processor, 121a Payment application, 121b ID application, 123 Communication interface, 125 Memory, 130 Trust center server device, 131 Processor, 131a Payment agent, 131b ID agent, 133 Communication interface, 135 Memory, 135a Database, 140 ID ledger, 150 Money ledger, 160 Central bank
Claims
1. A data communication device (110) for performing an electronic payment transaction, wherein the data communication device (110) comprises: at least one processor (111) configured to execute a payment application (111a) and an ID application (111b); a communication interface (113) configured to communicate with a trust center server device (130) and a money ledger (150); and the payment application (111a) is configured to send a transaction ID and a decentralized identity (DID) of a user (110a) of the data communication device (110) to a payment agent (131a) of the trust center server device (130); the ID application (111b) is configured to respond to a request including the DID from an ID agent (131b) of the trust center server device (130) and send signed user authentication information of the user (110a) of the data communication device (110) to the ID agent (131b) of the trust center server device (130); the payment application (111a) is further configured to receive a signature of the transaction ID from the payment agent (131a) of the trust center server device (130) and send the signature of the transaction ID to the money ledger (150) to register the electronic payment transaction with the signature of the transaction ID in the money ledger (150). A data communication device (110) characterized by the above.
2. The data communication device (110) according to claim 1, wherein, for performing a further electronic payment transaction with an amount less than a threshold value, the payment application is configured to send the further transaction ID of the further electronic payment transaction to the money ledger (150) without a signature of the further transaction ID to register the electronic payment transaction with the further transaction ID without a signature of the further transaction ID in the money ledger (150). A data communication device (110) characterized by the above.
3. The data communication device (110) according to claim 1 or 2, The payment application (111a) is further configured to generate the transaction ID and / or receive the DID of the user 110a of the data communication device (110) from the ID application (111b) upon request. A data communication device (110), characterized in that. **Claim 4** The data communication device (110) according to claim 1, wherein the ID application (111b) is further configured to transmit zero-knowledge proof data to the ID agent (131b) of the trust center server device (130) in response to the request of the ID agent (131b) of the trust center server device (130) for verifying the signed user authentication information of the user (110a) of the data communication device (110). A data communication device (110), characterized in that. **Claim 5** The data communication device (110) according to claim 1, wherein the payment application (111a) is further configured to transmit a further DID of a further user of a further data communication device (120) to the payment agent (131a) of the trust center server device (130) together with the transaction ID and the DID of the user (110a) of the data communication device (110). A data communication device (110), characterized in that. **Claim 6** The data communication device (110) according to claim 1, wherein the data communication device (110) is a mobile and portable data communication device (110), particularly a smartphone (110). A data communication device (110), characterized in that. **Claim 7** A method (300) for operating a data communication device (110) to perform an electronic payment transaction, wherein the data communication device (110) comprises at least one processor (111) configured to execute a payment application (111a) and an ID application (111b), and a communication interface (113) configured to communicate with a trust center server device (130) and a money ledger (150), and the method (300) Transmitting the transaction ID and the decentralized identity (DID) of the user (110a) of the data communication device (110) from the payment application (111a) to the payment agent (131a) of the trust center server device (130) (301); Responding to a request including the DID from the ID agent (131b) of the trust center server device (130), and transmitting the signed user authentication information of the user (110a) of the data communication device (110) from the ID application (111b) to the ID agent (131b) of the trust center server device (130) (303); Receiving, by the payment application (111a), the signature of the transaction ID from the payment agent (131a) of the trust center server device (130) (305); Transmitting the signature of the transaction ID from the payment application (111a) to the money ledger (150) to register the electronic payment transaction in the money ledger (150) together with the signature of the transaction ID (307); A method (300) characterized by including the above.
8. A trust center server device (130) for executing an electronic payment transaction, wherein the trust center server device (130) includes at least one processor (131) configured to execute a payment agent (131a) and an ID agent (131b); a communication interface (133) configured to communicate with a data communication device (110); a memory (135) for storing electronic data; and the payment agent (131a) is configured to receive a transaction ID and a decentralized identity (DID) of a user (110a) of the data communication device (110) from a payment application (111a) of the data communication device (110); the ID agent (131b) is configured to obtain the signed user authentication information of the user (110a) of the data communication device (110) from the ID application (111b) of the data communication device (110) in response to a request from the payment agent (131a) including the DID for the user authentication information of the user (110a) of the data communication device (110); The payment agent (131a) is further configured to obtain the user authentication information of the user (110a) of the data communication device (110) and store these together with the transaction ID in the memory (135). The payment agent (131a) signs the transaction ID and transmits the signed transaction ID to the payment application (111a) of the data communication device (110) in order to enable the registration of the electronic payment transaction in the money ledger (150) together with the signature of the transaction ID. A trust center server device (130), characterized in that.
9. The trust center server device (130) according to claim 8, The communication interface (133) is further configured to communicate with an ID ledger (140). The ID agent (131b) receives zero-knowledge proof data from the ID application (111b) of the data communication device (110) and is further configured to detect the signed user authentication information of the user (110a) of the data communication device (110) by the zero-knowledge proof data and the ID ledger (140). A trust center server device (130), characterized in that.
10. A method (400) for operating a trust center server device (130) for executing an electronic payment transaction, The trust center server device (130) At least one processor (131) configured to execute a payment agent (131a) and an ID agent (131b), A communication interface (133) configured to communicate with a data communication device (110), A memory (135) for storing electronic data, Comprising The method (400) Receiving, by the payment agent (131a), a transaction ID and a decentralized identity (DID) of a user (110a) of the data communication device (110) from a payment application (111a) of the data communication device (110) (401). In response to a request including the DID from the payment agent (131a) for the user authentication information of the user (110a) of the data communication device (110), the ID agent (131b) obtains the signed user authentication information of the user (110a) of the data communication device (110) from the ID application (111b) of the data communication device (110) (403); The payment agent (131a) obtains the user authentication information of the user (110a) of the data communication device (110) (405); The payment agent (131a) stores the user authentication information of the user (110a) of the data communication device (110) together with the transaction ID in the memory (135) (407); In order to enable registering the electronic payment transaction in the money ledger (150) together with the signature of the transaction ID, a signed transaction ID is transmitted from the payment agent (131a) to the payment application (111a) of the data communication device (110) (409); A method (400) characterized by including the above.
11. A system (100) for executing an electronic payment transaction, The system includes: A plurality of data communication devices (110) according to claim 1; A trust center server device (130) according to claim 8 or 9; A system (100) characterized by comprising the above.
12. A computer program having program code for executing the method (300) according to claim 7 and / or the method (400) according to claim 10 when the computer program is executed on a computer.