Devices, systems, and methods for electronic cashless payments
The system verifies and stores payer identities in a ledger for traceable cashless transactions, addressing the lack of identity tracing in existing blockchain-based methods, ensuring compliance and anonymity.
Patent Information
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- BUNDESDRUCKEREI GMBH
- Filing Date
- 2023-03-23
- Publication Date
- 2026-06-23
AI Technical Summary
Existing cashless payment methods, particularly those based on blockchain like Bitcoin, lack the ability to trace the identities of the payer and payee when necessary, due to legal regulations requiring traceability for transactions above certain limits.
A trust service provider verifies the identity of the payer, stores the identity in a database along with the transaction ID, and digitally signs the transaction ID, linking it to the payer's identity in a ledger when the transaction exceeds a threshold, while allowing anonymous transactions below the threshold.
Enables tracking of identities in cashless transactions when needed, maintaining anonymity when necessary, and ensuring compliance with legal regulations.
Smart Images

Figure 0007879265000001 
Figure 0007879265000002 
Figure 0007879265000003
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. Cashless payment transactions involve 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 that, for example, 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 located remotely, such as in the case of purchases via the Internet.
[0004] In cash transactions, the anonymity of the parties involved is essentially maintained. Although cashless electronic payment methods may also be executed anonymously, in some cases, 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 cashless electronic payment methods based on blockchain such as Bitcoin, such traceability is usually not available.
Prior Art Documents
Patent Documents
[0005]
Patent Document 1
Patent Document 2
[0006] The objective of the present invention is to generate a concept of electronic cashless payment that enables the tracking of the identities of the parties involved, namely the payer and the recipient, when necessary. [Means for solving the problem]
[0007] This objective is achieved by the features of the independent claims. Advantageous embodiments are the subject matter of the dependent claims, specification, and drawings.
[0008] Embodiments of the present invention described herein are based on the idea that, in order to perform cashless electronic transactions using a data communication device, such as a smartphone, a trust service provider, particularly a trust center, verifies the identity of the payer, stores the payer's identity in a database along with the transaction ID, digitally signs the transaction ID, and stores the signed transaction ID in the ledger by the data communication device. According to one embodiment, if the transaction amount exceeds a threshold, the trust center can link the transaction to the payer's identity. For transactions below the threshold, the data communication device can store the transaction without involving the trust center, i.e., the transaction can be performed completely anonymously. By linking the transaction to the payer's identity by the trust center, the anonymity of the transaction in the ledger can be maintained, but it can be tracked if necessary.
[0009] According to a first embodiment, a data communication device is provided for executing electronic payment transactions. The data communication device comprises at least one processor configured to run a payment application and an ID application, and a communication interface configured to communicate with a trust center server device and a cash ledger. The payment application is configured to send a transaction ID and the distributed identity (DID) of the user of the data communication device to the payment agent of the trust center server device. The ID application is configured to send signed user authentication information of the user of the data communication device to the ID agent of the trust center server device in response to a request from the ID agent of the trust center server device that includes the DID. 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 cash ledger in order to register the electronic payment transaction in the cash ledger along with the signature of the transaction ID.
[0010] In one embodiment, in order to execute further electronic payment transactions of an amount below a threshold, the payment application is configured to send the further transaction IDs of the further electronic payment transactions to the ledger without the further transaction IDs being signed, in order to register the electronic payment transactions in the ledger, along with the further transaction IDs of the further transaction IDs.
[0011] In one embodiment, the payment application is further configured to generate a transaction ID and / or receive the user's DID 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 the ID agent of the Trust Center Server in response to a request from the ID agent of the Trust Center Server in order to verify the signed user authentication information of the user of the data communication device.
[0013] In one embodiment, the payment application is further configured to transmit the 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 payment recipient.
[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 is provided for operating a data communication device to perform an electronic payment transaction, the data communication device comprising at least one processor configured to run a payment application and an ID application, and a communication interface configured to communicate with a trust center server device and a cash ledger. The method comprises the following steps, namely: The steps include sending the transaction ID and the distributed identity (DID) of the user of the data communication device from the payment application to the payment agent on the trust center server device, The steps include: sending signed user authentication information of the user of the data communication device from the ID application to the ID agent of the Trust Center server device in response to a request including DID from the ID agent of the Trust Center server device; The payment application includes the step of receiving a transaction ID signature from the payment agent of the trust center server device, To register an electronic payment transaction in the cash ledger along with the transaction ID signature, the process involves sending the transaction ID signature from the payment application to the cash ledger, and Includes.
[0016] According to a third aspect, a trust center server device is provided for executing electronic payment transactions. The trust center server device comprises at least one processor configured to run a payment agent and an ID agent, a communication interface configured to communicate with a data communication device, and memory for storing electronic data. The payment agent is configured to receive a transaction ID and a distributed identity (DID) of the user of the data communication device from the payment application of the data communication device. The ID agent is configured to obtain signed user credentials of the user of the data communication device from the ID application of the data communication device in response to a request from the payment agent, which includes a DID for the user credentials of the user of the data communication device. The payment agent is further configured to obtain the user credentials of the user of the data communication device and store them in memory together with the transaction ID. The payment agent is further configured to sign the transaction ID and send the signed transaction ID to the payment application of the data communication device in order to enable the electronic payment transaction to be registered in the ledger together with the signature of the transaction ID.
[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 the ID application of the data communication device and to verify the signed user authentication information of the user of the data communication device using the zero-knowledge proof data and the ID ledger.
[0018] According to a fourth aspect, a method is provided for operating a trust center server device for executing electronic payment transactions, the trust center server device comprising 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 comprises the following steps, namely: A step of receiving, by a payment agent, a transaction ID and a decentralized identity (DID) of a user of a data communication device from a payment application of the data communication device; A step of obtaining, by an ID agent, signed user authentication information of a user of a 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 the user of the data communication device; A step of obtaining, by the payment agent, user authentication information of a user of the data communication device; A step of storing, by the payment agent, user authentication information of a user of the data communication device together with a transaction ID in a memory; A step of transmitting, from the payment agent to a payment application of the data communication device, a signed transaction ID to enable registration of an electronic payment transaction with a signature of the transaction ID in a ledger; 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] Further embodiments are described in more detail with reference to the accompanying drawings.
Brief Description of Drawings
[0022] [Figure 1] It is a schematic diagram of a system for electronic payment according to an embodiment, a trust center server device according to an embodiment, and a data communication device according to an embodiment. [Figure 2] It is a signaling diagram showing the interaction of components of the system of FIG. 1 according to an embodiment. [Figure 3]This flowchart shows the steps of a method for operating a data communication device according to one embodiment. [Figure 4] This flowchart shows the steps of a method for operating a trust center server according to one embodiment. [Modes for carrying out the invention]
[0023] The corresponding elements of the embodiments described in detail below are identified by the same reference numerals.
[0024] Here and below, “blockchain” is understood to be an ordered data structure containing a number of linked data blocks. In particular, a blockchain is understood to be an ordered data structure in which each block (except the first block) contains a check value, such as a hash value, of the previous block, and thus the validity of all previous blocks can be checked and, if necessary, verified using each block. The concept of blockchain was described, for example, in 2008 in a white paper on Bitcoin ("Bitcoin: Peer-to-Peer Electronic Cash System" (https: / / bitcoin.org / bitcoin.pdf)) under the pseudonym Satoshi Nakamoto. The blockchain described there consists of a series of data in which one or more entries or transactions are summarized and provided with a checksum in the form of a hash value. Additional blocks to the blockchain are generated, for example, in a computationally intensive process also known as mining. These additionally generated blocks are then added to the blockchain and distributed across the network to all participants or nodes in the network.
[0025] The embodiment can have the advantage of providing a high level of security against subsequent tampering by having the blockchain store the cryptographic checksum, or hash value, of the previous block in the subsequent block. The blockchain can then be checked using these root hash values. Each block in the blockchain contains the 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 practically impossible to modify the previous block or individual entries afterward, as it is necessary to recalculate the hash values of all subsequent blocks in short intervals.
[0026] According to one embodiment, the blockchain is one in which only a selected group of participants has the authority to add valid blocks. Such authority can be proven, for example, by signing using a private cryptographic key. The private cryptographic key may belong to an asymmetric key pair, which also includes a public cryptographic key that can verify the signature. An asymmetric key pair may also be assigned, for example, a certificate that proves the authority to create valid blocks on the blockchain. This certificate may also be assigned to a PKI that proves the authenticity of the certificate. According to another embodiment, public keys can be stored on the blockchain in the initialization entry of an additional participant who is added to the selected group. These public keys can be used to check whether a block is signed and, for this reason, whether the corresponding block itself is valid. The public keys of the original participants in the selected group may be stored, for example, in the genesis block of the blockchain.
[0027] For example, a central bank-managed blockchain is a public blockchain managed on the central bank's blockchain server. For instance, new blocks are entered only by these central bank-managed blockchain servers. In this case, computationally intensive processes can be eliminated when adding additional blocks. For example, all that is needed to add an additional block is a signature with a signing key assigned to the central bank.
[0028] A trust center represents a trusted third party that can verify the identity of a communication partner in an electronic communication process. For example, in electronic communications related to digital signatures, a trust center can issue a certificate that can be used to verify the identity of the communication partner.
[0029] "Communication interface" or "multiple communication interfaces" is understood here to mean, for example, an interface through which data can be sent and received, and a communication interface can be configured as a contact type or a contactless type.
[0030] Communication can be carried out, for example, via a network. “Network” is understood here to mean any transmission medium having a connection for communication, in particular a local connection or local network, especially a local area network (LAN), a private network, especially an intranet, and a digital private network (Virtual Private Network (VPN)). For example, a computer system may have a standard wireless interface for connecting to a WLAN. This can also be a public network such as the Internet. Depending on the embodiment, this connection may also be established via a mobile network.
[0031] "Processor" is understood here and below to mean a logic circuit that plays a role in executing program instructions. A logic circuit can be implemented on one or more distributed components, in particular 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, for example, stored in memory, in order to perform the operations and methods described herein.
[0032] "Memory" here is understood to mean non-volatile memory in particular. "Non-volatile memory" here is understood to mean, for example, electronic memory for the persistent storage of data. Non-volatile memory can be configured as non-replaceable memory, also called read-only memory (ROM), or replaceable 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 stored data that is retained even after the power has been switched off.
[0033] A “protected memory area” is understood here to be an area of electronic memory where access, i.e., read access or write access, is only possible through the processor of the security element. For example, external access to the protected memory area is not possible; that is, data cannot be brought in from or 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 the embodiment, access from or through the processor coupled to the memory is only possible if the necessary conditions for this are met. These can be, for example, cryptographic conditions, in particular the success of authentication and / or the success of authentication checks. Such checks can be based, for example, on an electronic signature using a signing key.
[0034] Asymmetric key pairs are used in a wide range of cryptographic systems and play a crucial role in digital data signatures. An asymmetric key pair consists of a public key, which is used to encrypt and / or decrypt data and can be shared with third parties, and a private key, which is also used to encrypt and / or decrypt data and must generally be kept secret. The public key allows anyone to encrypt data for the owner of the private key and verify digital signatures created using the private key. The private key allows the owner to decrypt data encrypted using the public key and create digital signatures. Signatures created using the private key can be verified using the associated public key.
[0035] Creating a digital signature, also simply called a "signature," is an encryption process in which an additional data value called a "signature" is calculated for arbitrary data. A signature can, for example, be the hash value of source data encrypted using a secret encryption key.
[0036] Here, a security element is understood to be an electronic component, including a processor and memory, to which only specific, predetermined access is permitted. For example, only specific data values stored in a particular area of 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 data values to the security element's memory, and the verification key is stored within the security element. For example, only the processor has write permission to write data to a protected memory area.
[0037] The security elements can further provide cryptographic core routines 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 also serve as secure storage for cryptographic keys.
[0038] For example, at least part of a security element is signed. Before a security element is used, one or more signatures are verified to be valid. If one of the signatures is invalid, for example, the use of the security element is blocked.
[0039] For example, a security element has physically limited access options. In addition, a security element may have further measures against misuse, particularly against unauthorized access to data in the memory of the security element. For example, means to protect a security element from unauthorized tampering include, for example, mechanical means intended to prevent the security element or its components from being opened, or to render the security element unusable, for example, by causing data loss, if an attempt is made to intervene in the security element. For example, at least a portion of a security element may be encapsulated, molded, and / or laminated within a material, and an attempt to remove this will inevitably destroy the corresponding portion of the security element.
[0040] Figure 1 shows a system 100 for traceable execution of an electronic cashless payment between a first data communication device 110 of a payment user 110a and a second data communication device 120 of a payment recipient. The first and / or second data communication devices 110, 120 can each be a mobile and portable data communication device 110, 120, in particular a smartphone 110, 120. In the embodiments described below, the data communication devices 110, 120 are exemplary smartphones 110, 120.
[0041] In the embodiment shown in Figure 1, the payment user 110a's smartphone 110 and the payment recipient's smartphone 120 each include one or more processors 111, 121, communication interfaces 113, 123 for wireless and / or wired communication over a communication network, and memories 115, 125 for storing electronic data. Each of the smartphones 110, 120 may include security elements, such as virtual or physical SIM cards, configured to store security-sensitive data and / or perform security-sensitive operations, particularly encryption operations.
[0042] As shown in Figure 1, the processors 111 and 121 of each smartphone 110 and 120 are configured to run payment applications 111a and 121a and ID or identification applications 111b and 121b, and their functions and interactions with each other and with other components of the system 100 will be described in more detail below with further reference to Figure 2.
[0043] In addition to the payment user 110a's smartphone 110 and the payment recipient's smartphone 120, the system 100 includes a trust center server device 130, an ID ledger 140 for self-determined identity (self-sovereign identity (SSI), thus also called the "SSI ledger" 140 in Figure 1), a money ledger 150, for example, a blockchain 150, and a central bank or central bank server 160 for managing the money ledger 150. The trust center server device 130 may include one or more servers having one or more processors 131, a communication interface 133 for wireless and / or wired communication over a communication network, and a memory 135 for storing electronic data.
[0044] As shown in Figure 1, at least one processor 131 of the trust center server device 130 is configured to run a payment agent 131a (or payment service 131a) and an ID agent 131b (or ID service 131b), the functions of which and their interactions with each other and with other components of the system 100 will be described in more detail below with further reference to Figure 2.
[0045] The ledger 150 can be implemented, for example, on one or more blockchain servers. In other words, a blockchain server can be part of the ledger network 150 and therefore can be a blockchain node of the ledger 150. The blockchain servers and / or the ledger 150, i.e., the blockchain network 150, can be managed, for example, by a central bank 160. If the central bank 160 is a central bank to which several countries belong, the ledger 150 can include, for example, one or more blockchain servers for each country.
[0046] Figure 2 shows the interaction of the components of the system 100 shown in Figure 1 according to one embodiment.
[0047] The payment user 110a wishes to pay a specific amount to the payment recipient via the recipient's smartphone 120 using the payment user's smartphone 110. To do this, in step 201 of Figure 2, user 110a starts the payment application 111a (referred to as the "payment application" in Figure 2) on their smartphone 110.
[0048] In the embodiment shown in Figure 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 (e.g., a legally defined threshold), the smartphone 110 performs a further step shown in Figure 2 (step 203 in Figure 2). Otherwise, i.e., if the amount to be paid is below the threshold, the payment transaction can be executed without the trust center 130 and recorded on the ledger 150 in essentially known terms. However, the present invention also provides embodiments in which this check is omitted and the steps described below are performed independently of the amount to be paid.
[0049] In the example shown in Figure 2, since the amount to be paid exceeds a threshold, the payment application 111a, implemented by the processor 111, generates a request in step 205 of Figure 2 and sends it to the trust center 130, specifically to the payment agent 131a of the trust center 130 (identified as "TSE agent" 131a in Figure 2), via the communication interface 113 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 Figure 2 for 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 on the smartphone.
[0050] In step 209 of Figure 2, which is performed within the smartphone 110, the payment application 111a first sends a request to the ID application 111b and, in response, receives the decentralized ID (DID, also known as "Decentralized Identifier" in English) of the payment user 110a of the smartphone 110 from the ID application 111b.
[0051] In step 210 of Figure 2, the payment application 111a of the smartphone 110 transmits the DID and transaction ID received from the ID application 111b to the payment agent 131a of the trust center 130.
[0052] In step 211 of Figure 2, the payment agent 131a of the trust center 130 sends a request for user authentication information (or user information) of user 110a to the ID agent 131b of the trust center 130, the request including the DID received from the ID application 111b on 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 distributed ledger technology (DLT).
[0053] In step 213 of Figure 2, the ID agent 131b of the trust center 130 sends a request for user authentication information to the ID application 111b of the smartphone 110, i.e., a request for user information to identify the identity of user 110a of the smartphone 110 by the SSI ledger 140. The request includes the DID initially received from the ID application 111b.
[0054] In step 215 of Figure 2, the ID application 111b of the smartphone 110 signs 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 the virtual or physical SIM card of the smartphone 110. As already described above, security-critical cryptographic operations of the ID application 111b and / or payment application 111a can be performed in such a security element.
[0055] In step 217 of Figure 2, the ID application 111b of the smartphone 110 proves the authenticity of the certificate or user information transmitted in step 215 using a zero-knowledge proof (ZKP).
[0056] In step 219 of Figure 2, the ID agent 131b of the trust center 130 obtains data for verifying or confirming the ZKP in step 217 from the ID ledger 140 by downloading this data (step 221 of Figure 2).
[0057] After the ZKP is verified by the ID agent 131b of the trust center 130 (which allows the ID agent 131a to 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 Figure 2. The payment agent 131a then stores the signed transaction ID, along with the user authentication information, in the database 135a implemented in memory 135 (step 225 of Figure 2). In one embodiment, the payment agent 131a may also assign an identification number for this purpose and link it to the transaction ID.
[0058] In step 227, the payment agent 131a of the trust center 130 sends the signed transaction ID to the payment application 111a on the smartphone 110. Thus, step 227 ultimately represents the trust center 130's response to the signed transaction ID requested in step 205.
[0059] In step 229 of Figure 2, to complete the payment transaction, the payment application 111a sends the transaction data, namely the transaction ID and amount, and the signature of the transaction ID, to the ledger 150. Here, this data is registered or stored to be made available to the central bank server 160 for tracking, if necessary. Thus, the payment process is completed. Optionally, the payment application 111a may also register the identity of the payment recipient, namely the user of another smartphone 120, and the DID of the user of another smartphone 120. In this case, the identity agent 131b of the trust center 130 can establish two separate connections, namely one connection to the payment user 110a's smartphone 110 and the other connection to the payment recipient's smartphone.
[0060] Figure 3 shows a flowchart illustrating the steps of a method 300 for operating a data communication device 110 according to one embodiment. Method 300 consists of the following steps: Step 301 involves sending the transaction ID and the distributed identity (DID) of 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 involves sending signed user authentication information of user 110a from the data communication device 110 to the ID agent 131b of the Trust Center Server Device 130 in response to a request including DID from the ID agent 131b of the Trust Center Server Device 130, Step 305 involves the payment application 111a receiving a signature for the transaction ID from the payment agent 131b of the trust center server device 130, Step 307 involves sending the transaction ID signature from the payment application 111a to the ledger 150 in order to register the electronic payment transaction with the transaction ID signature in the ledger 150, Includes.
[0061] Figure 4 shows a flowchart illustrating the steps of a method 400 for operating a trust center server device 130 according to one embodiment. Method 400 consists of the following steps, namely: Step 401 involves the payment agent 131a receiving the transaction ID and the distributed identity (DID) of the user 110a of the data communication device 110 from the payment application 111a of the data communication device 110, Step 403: In response to a request from payment agent 131a including DID regarding user authentication information of user 110a of data communication device 110, ID agent 131b obtains signed user authentication information of user 110a of data communication device 110 from ID application 111b of data communication device 110. Step 405 involves obtaining user authentication information of user 110a of data communication device 110 by payment agent 131a, Step 407 involves the payment agent 131a storing the user authentication information of user 110a of the data communication device 110 in memory 135 along with the transaction ID. Step 409 involves sending a signed transaction ID from the payment agent 131a to the payment application 111a of the data communication device 110, in order to enable the electronic payment transaction to be registered in the cash ledger 150 along with the signature of the transaction ID, Includes. [Explanation of Symbols]
[0062] 100 Electronic payment system, 110 Payer's data communication device, 110a Payer user, 111 Processor, 111a Payment application, 111b ID application, 113 Communication interface, 115 Memory, 120 Recipient's data communication device, 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 Cash ledger, 160 Central bank
Claims
1. A data communication device (110) for executing electronic payment transactions, The aforementioned data communication device (110) is A processor (111) configured to run a payment application (111a) and an ID application (111b), A communication interface (113) configured to communicate with the trust center server device (130) and the cash ledger (150), Equipped with, The payment application (111a) is configured to transmit the transaction ID and the distributed identity (DID) of the user (110a) of the data communication device (110) to the payment agent (131a) of the trust center server device (130). The ID application (111b) is configured to send the 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) in response to a request including the DID from the ID agent (131b) of the trust center server device (130). The payment application (111a) is further configured to receive the signature of the transaction ID from the payment agent (131a) of the trust center server device (130) and to transmit the signature of the transaction ID to the cash ledger (150) in order to register the electronic payment transaction in the cash ledger (150) together with the signature of the transaction ID. A data communication device (110) characterized by the following features.
2. A data communication device (110) according to claim 1, To execute further electronic payment transactions of an amount below a threshold, the payment application is configured to transmit the further transaction ID of the further electronic payment transaction to the cash ledger (150) without the signature of the further transaction ID, in order to register the electronic payment transaction in the cash ledger (150) along with the further transaction ID, without the signature of the further transaction ID. A data communication device (110) characterized by the following features.
3. A 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) when requested. A data communication device (110) characterized by the following features.
4. A data communication device (110) according to claim 1, 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 from the ID agent (131b) of the trust center server device (130) in order to verify the signed user authentication information of the user (110a) of the data communication device (110). A data communication device (110) characterized by the following features.
5. A data communication device (110) according to claim 1, The payment application (111a) is further configured to transmit the further DID of a further user of a further data communication device (120), together with the transaction ID and the DID of the user (110a) of the data communication device (110), to the payment agent (131a) of the trust center server device (130). A data communication device (110) characterized by the following features.
6. A data communication device (110) according to claim 1, The data communication device (110) is a mobile and portable data communication device (110), in particular a smartphone (110). A data communication device (110) characterized by the following features.
7. A method (300) for operating a data communication device (110) to execute an electronic payment transaction, The aforementioned data communication device (110) is A processor (111) configured to run a payment application (111a) and an ID application (111b), A communication interface (113) configured to communicate with the trust center server device (130) and the cash ledger (150), Equipped with, The above method (300) is, The transaction ID and the distributed identity (DID) of the user (110a) of the data communication device (110) are transmitted from the payment application (111a) to the payment agent (131a) of the trust center server device (130) (301), In response to a request including the DID from the ID agent (131b) of the Trust Center Server Device (130), the ID application (111b) transmits the 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) (303), The payment application (111a) receives the signature of the transaction ID from the payment agent (131a) of the trust center server device (130) (305), In order to register the electronic payment transaction in the cash ledger (150) along with the signature of the transaction ID, the signature of the transaction ID is transmitted from the payment application (111a) to the cash ledger (150) (307), A method (300) characterized by including the following.
8. A trust center server device (130) for executing electronic payment transactions, The Trust Center Server Device (130) is A processor (131) configured to run 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, Equipped with, The payment agent (131a) is configured to receive a transaction ID and the distributed identity (DID) of the user (110a) of the data communication device (110) from the payment application (111a) of the data communication device (110). The ID agent (131b) is configured to obtain signed user authentication information for 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 user authentication information for the user (110a) of the data communication device (110), The payment agent (131a) is further configured to acquire the user authentication information of the user (110a) of the data communication device (110) and store it in the memory (135) together with the transaction ID. The payment agent (131a) is further configured to sign the transaction ID and transmit the signed transaction ID to the payment application (111a) of the data communication device (110) in order to enable the electronic payment transaction to be registered in the ledger (150) along with the signature of the transaction ID. A trust center server device (130) characterized by the following.
9. A trust center server device (130) according to claim 8, The communication interface (133) is further configured to communicate with the ID ledger (140), The ID agent (131b) is further configured to receive zero-knowledge proof data from the ID application (111b) of the data communication device (110), and to detect the signed user authentication information of the user (110a) of the data communication device (110) using the zero-knowledge proof data and the ID ledger (140). A trust center server device (130) characterized by the following.
10. A method (400) for operating a trust center server device (130) for executing electronic payment transactions, The Trust Center Server Device (130) is A processor (131) configured to run 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, Equipped with, The above method (400) is, The payment agent (131a) receives the transaction ID and the distributed identity (DID) of the user (110a) of the data communication device (110) from the payment application (111a) of the data communication device (110) (401), In response to a request from the payment agent (131a) including the DID for 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), To enable the registration of the electronic payment transaction in the cash ledger (150) along with the signature of the transaction ID, the 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 following.
11. A system (100) for executing electronic payment transactions, The aforementioned system, A plurality of data communication devices (110) as described in 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 characterized in that, when the computer program is executed on a computer, it has program code for executing the method according to claim 7 (300) and / or the method according to claim 10 (400).