Method for transmitting electronic coin data records directly between a terminal and a payment system

Abstract

The invention relates to a method for direct transmission of electronic coin data records between a first terminal and a second terminal, wherein the second terminal performs the following steps: receiving electronic coin data records from the first terminal, wherein at least one electronic coin data record comprises a currency amount and a hidden amount; generating modified electronic coin data records using the received electronic coin data records; masking the modified electronic coin records by applying a homomorphic one-way function to the modified electronic coin records in order to obtain masked modified electronic coin records; sending a registration request for the masked modified electronic coin data records to a monitoring entity. The invention also relates to a currency system and a payment system comprising: a decentralized controlled database in which the masked electronic coin data records are stored; and a direct transaction layer comprising at least two terminals in which the method can be executed.

Description

Technical Field

[0001] This invention relates to a device for directly transmitting electronic coin data records between terminals. The invention also relates to a payment system between at least two terminals and a monitoring entity. Background Technology

[0002] The security of payment transactions and related payment transaction data means protecting the confidentiality of the exchanged data; protecting the integrity of the exchanged data; and protecting the availability of the exchanged data.

[0003] Conventional blockchain-based payment transactions represent a high degree of protection for integrity. However, when electronic coin data records (also known as "coins") change hands within a blockchain technology, much information is published. Therefore, such payment transactions (especially the data exchanged) are not entirely confidential. Furthermore, payment transactions are highly computationally intensive and therefore energy-intensive.

[0004] Therefore, instead of confidential data, only the hash value of the confidential data is conventionally stored in the blockchain ledger. The corresponding plaintext data must be managed outside the blockchain. This concept does not currently apply to electronic coin data records because they lack basic control functions, specifically: (1) identifying multiple spending methods, also known as double spending; and (2) identifying uncovered payments. In case (1), someone attempts to output the same coin data record multiple times, and in the second case, someone attempts to output a coin data record even though he or she has no credit (no longer has credit).

[0005] As can be seen from DE 10 2009 038 645 A1 and DE 10 2009 034 436 A1, systems for transmitting monetary amounts in the form of electronic data records are known, which prevent payments from being made with copies of the data records and provide a high degree of security against manipulation, while the exchange requires a complex structure and complex encryption and signature processes. These systems have proven to have little practical use.

[0006] WO 2016 / 200885 A1 describes a method for encrypting the amount of a transaction in a blockchain ledger, where the verifiability of the transaction is preserved. A hidden amount is added to the input values. An output value is then generated and encrypted. Both the input and output values ​​fall within a range where the sum of any two values ​​within that range does not exceed a threshold. The sum of the encrypted input and output values ​​can be zero. Range checks (so-called range proofs) are associated with each of the input and output values. These range checks prove that both the input and output values ​​fall within that range. Each public key can be ring-signed based on the public key of the recipient in the transaction. This process requires blockchain technology, which must be invoked to verify the coin data record after it has been received.

[0007] The object of this invention is to provide a method and system in which payment transactions are configured to be secure yet simple. Specifically, anonymous direct payments between terminals (such as tokens, smartphones, and machines) are provided. Coin data records should be available immediately upon receipt. It is intended that multiple coin data records can be combined and / or divided according to the user's needs to enable flexible exchange. The exchanged coin data records should be kept confidential from other system participants on the one hand, but on the other hand, allow each system participant to perform basic accounting checks, particularly allowing each system participant to identify multiple spending attempts and attempts to make payments with non-existent amounts. Summary of the Invention

[0008] The objective is achieved through the features of the independent claim. Further advantageous developments are described in the dependent claims.

[0009] Specifically, this objective is achieved through a method for directly transmitting electronic coin data records between a first terminal and a second terminal, wherein the second terminal performs the following steps: Receiving electronic coin data records from the first terminal, wherein at least one electronic coin data record includes a monetary amount and a hidden amount. Generating modified electronic coin data records using the received electronic coin data records. Masking the modified electronic coin data records by applying a homomorphic one-way function to the modified electronic coin data records to obtain masked modified electronic coin data records. Sending a registration request for the masked modified electronic coin data records to a monitoring entity.

[0010] The registration request preferably includes a masked modified electronic coin data record as a masked electronic coin data record to be registered, and a masked received electronic coin data record as a received electronic coin data record that has been registered.

[0011] In the generation process

[0012] -Based on the received electronic coin data record, a modified electronic coin data record to be switched can be generated, or

[0013] - The received electronic coin data record can be split into at least two modified electronic coin data records, or

[0014] - The received electronic coin data record can be merged as a first electronic coin data record and at least one second electronic coin data record to form a merged modified electronic coin data record.

[0015] Therefore, the masked modified electronic coin data record can be a masked electronic coin data record, which may be split, merged, or awaiting switching.

[0016] Accordingly, the registration request preferably includes:

[0017] - exactly one masked e-coin data record to be registered and exactly one masked e-coin data record already registered, or

[0018] - At least two masked, segmented, modified e-coin data records to be registered (and a masked received e-coin data record), or

[0019] - At least two registered masked e-coin records (one of which is a masked received e-coin record and a masked merged e-coin record).

[0020] Advantageously, the second terminal obtains the masked received electronic coin data record from the received electronic coin data record by applying a homomorphic one-way function.

[0021] In the generation process, it is particularly advantageous to perform the following steps for different modifications. The electronic coin data record to be switched can be generated from the received electronic coin data record, wherein...

[0022] o uses the received hidden amount from the received electronic coin data record to generate a hidden amount for the modified electronic coin data record, and

[0023] o The received currency amount in the received electronic coin data record is used as the currency amount in the modified electronic coin data record.

[0024] The received electronic coin data record can be divided into at least two electronic coin data records, wherein...

[0025] The amount of currency received corresponds to the sum of the amounts recorded in at least two electronic coin data records, and

[0026] Specifically, the sum of the hidden amounts in at least two electronic coin data records corresponds to the hidden amount in the received electronic coin data record.

[0027] The received electronic coin data record can be merged as a first electronic coin data record and at least one second electronic coin data record through the following steps to form a modified merged electronic coin data record.

[0028] The hidden amount in the modified electronic coin data record is calculated by summing the corresponding hidden amounts in the first and second electronic coin data records.

[0029] The monetary amount of the modified electronic coin data record is calculated by summing the corresponding monetary amounts of the first and second electronic coin data records.

[0030] After receiving the (transmitted) electronic coin data record in the second terminal, the coin data record is switched, split, or merged accordingly. The transmitted electronic coin data record is switched to another electronic coin data record, i.e., the electronic coin data record to be switched; or the transmitted electronic coin data record is split into another (second) electronic coin data record; or the transmitted electronic coin data record is merged with another electronic coin data record to form another electronic coin data record, i.e., the merged electronic coin data record. The other (or modified) electronic coin data record is masked. In embodiments, only switching or only splitting or merging may be used in the terminal, but the terminal preferably selects one of the three steps.

[0031] The terminal sends a registration request to a monitoring entity that stores valid, masked electronic coin data records. Terminals, such as a second terminal, may alternatively or additionally (e.g., before further use) check the validity of the electronic coin data records (particularly received records) by sending the masked electronic coin data records to the monitoring entity in a validity request. The monitoring entity responds to the validity request (positively or negatively) based on the stored valid, masked electronic coin data records.

[0032] The sending of the registration request (and thus the registration step with the monitoring entity) is preferably performed when the terminal connects to the monitoring entity. Alternatively, the described steps can initially be performed without performing the steps of sending the registration request (and registering with the monitoring entity). The steps of receiving the electronic coin record and sending the registration request are independent of each other. Specifically, the steps of receiving the electronic coin data record and sending the registration request can be performed independently of each other at different times (e.g., receiving now and registering later (tomorrow or the day after)).

[0033] When switching transmitted coin data records, in one embodiment, the currency amount of the electronic coin data record transmitted from the first terminal corresponds to the currency amount of the other electronic coin data record. When splitting transmitted electronic coin data records, in one embodiment, the currency amount of the transmitted electronic coin data record corresponds to the total currency amount of another electronic coin partial data record created from the transmitted electronic coin data record. When merging, in one embodiment, the total currency amount of the transmitted electronic coin data record and the second electronic coin data record corresponds to the currency amount of the merged electronic coin data record.

[0034] Electronic coin data records (especially electronic data records representing monetary value (= monetary amount)) are commonly referred to as "digital coins" or "electronic coins." In this method, the monetary amount is switched from one terminal to another. In the following text, the monetary amount is understood as a digital amount that can, for example, be credited to a financial institution's account or can be exchanged for another form of payment. Therefore, electronic coin data records represent cash in electronic form.

[0035] The terminal may have multiple electronic coin data records; for example, multiple coin data records may be stored in the terminal's data storage device. The data storage device represents, for example, an electronic wallet. The terminal will typically perform these steps entirely on its own, but it may invoke a terminal service (external server entity) to perform at least one (particularly exactly one, exactly two, or all three) of the terminal's generation, masking, and sending steps (preferably "generation and masking" or "masking and sending" or sending).

[0036] For example, a terminal can be a passive device (such as a token), a mobile device (such as a smartphone), a tablet computer, a computer, a server, or a machine.

[0037] A method according to the present invention in a monitoring entity, wherein the monitoring entity stores valid masked electronic coin data records, each record being formed by applying a homomorphic one-way function to the electronic coin data record, wherein the electronic coin data record includes a monetary amount and a hidden amount, the method specifically comprising the following steps:

[0038] - Receive a registration request, which includes at least one masked e-coin data record to be registered and at least one masked e-coin data record that has already been registered;

[0039] -Inspect the received registration request, where

[0040] ○ Check whether the registered masked e-coin data record of the registration request is stored as a valid masked e-coin data record for transmission in the monitoring entity, and

[0041] ○ Check whether the overall data record of the masked e-coin in the registration request is monetary amount neutral; and

[0042] - Store the masked e-coin data record to be registered as a valid masked e-coin data record, wherein the previously registered masked e-coin data record that was stored as a valid registration request is no longer valid.

[0043] Preferably, by forming the difference between the masked electronic coin data records, the currency amount neutrality of the registration request is checked without knowing the amount (this is possible due to the homomorphic one-way function used).

[0044] In a preferred method, the monitoring entity receives a creation and / or deactivation request from the issuing entity, the creation and / or deactivation request including at least one masked electronic coin data record to be created or deactivated, particularly for electronic coin data records newly issued by the issuing entity or electronic coin data records withdrawn by the issuing entity.

[0045] Requests to create and / or deactivate masked electronic coin data records may include the signature of the issuer of the masked electronic coin data record, wherein the signature of the newly created masked electronic coin data record is preferably stored in the monitoring entity.

[0046] By marking or deleting the corresponding masked electronic coin data record in the monitoring entity, the electronic coin data record may become invalid in the monitoring entity. Particularly preferably, the corresponding masked electronic coin data record or the corresponding electronic coin data record is also deactivated in the issuing entity.

[0047] In particular, the electronic coin data record is unique and unambiguous, thus differing from conventional data records. It is advantageously suited for security concepts, which may optionally include, for example, signatures or encryption. In principle, the electronic coin data record should contain all the data required by the receiving entity for verification and forwarding to other entities. Therefore, additional communication between terminals is essentially not necessary, but rather permissible, when exchanging electronic coin data records.

[0048] According to the present invention, an electronic coin data record for transmission between two terminals includes a monetary amount and a hidden amount. The monetary amount is data representing the monetary value of the electronic coin data record, and the hidden amount is, for example, a random number. Furthermore, the electronic coin data record may include additional metadata, such as which currency the monetary amount represents. The electronic coin data record is uniquely represented by these at least two pieces of data (the monetary amount and the hidden amount). Anyone who has access to both pieces of data of a valid coin data record can use the electronic coin data record for payments. Therefore, knowing these two values ​​(the monetary amount and the hidden amount) is equivalent to possessing digital money. The electronic coin data record is transmitted directly between the two terminals, i.e., at least between the first terminal and the second terminal. In one embodiment of the invention, the electronic coin data record consists of these two pieces of data, such that for the exchange of digital money, only the transparency of the monetary amount and the hidden amount is necessary.

[0049] The corresponding masked electronic coin data record is associated with each electronic coin data record. Knowing that the masked electronic coin data record does not allow anyone to discard the digital money represented by the electronic coin data record is essential. This represents the fundamental difference between masked and (unmasked) electronic coin data records and is an essential part of the invention. The masked electronic coin data record is unique and can be clearly associated with each electronic coin data record, i.e., in a one-to-one relationship. The electronic coin data record is preferably masked by a terminal computing unit within a terminal that also has at least one electronic coin data record. Alternatively, the masking can be performed by the computing unit of the terminal receiving the electronic coin data record.

[0050] The masked electronic coin data record is obtained by applying a homomorphic one-way function (especially a homomorphic cryptographic function). This function is a one-way function, meaning it is mathematically "easy" to compute from a complexity theory perspective but "hard" to reverse in practice. Here, a one-way function is also called a function for which it is known that it cannot be reversed in a reasonable amount of time with reasonable effort. Therefore, computed to obtain the masked electronic coin data record from the electronic coin data record is equivalent to generating a public key using an encryption method with a set of remaining classes. Preferably, a one-way function is used that operates on sets of discrete logarithms that are difficult to solve with the private key of the corresponding cryptographic method, such as elliptic curve cryptography (ECC). The inverse function (i.e., generating the electronic coin data record from the masked electronic coin data record) is very time-consuming—equivalent to generating a private key from the public key using an encryption method on the set of remaining classes. When sums, differences, or other mathematical operations are mentioned in this document, these should be understood mathematically as corresponding operations on the corresponding mathematical sets (e.g., a set of points on an elliptic curve).

[0051] One-way functions are homomorphic, meaning they are cryptographic methods with homomorphic properties. Therefore, mathematical operations can be performed on masked electronic coin data records, and also on (unmasked) electronic coin data records in parallel, thus reproducing them. With the help of homomorphic one-way functions, calculations involving masked electronic coin data records can be reproduced in a monitoring entity without needing to know the corresponding (unmasked) electronic coin data records there. Therefore, certain calculations involving electronic coin data records, such as calculations for processing (unmasked) electronic coin data records (e.g., splitting or merging), can also be verified in parallel with the associated masked electronic coin data records, for example, to verify or check the legitimacy of the corresponding electronic coin data records. The homomorphic property applies at least to addition and subtraction operations, allowing splitting or merging (= merging) electronic coin data records to also be recorded in the monitoring entity by correspondingly masked electronic coin data records, and to be reproduced by the requesting terminal device and / or by the monitoring entity without knowing the currency amount and the terminal performing the operation.

[0052] Therefore, the homomorphic property allows the monitoring entity to record valid and invalid electronic coin data records based on their masked electronic coin data records, even without knowing the records themselves, even if these records are processed (splittered, merged, switched). This ensures that no additional currency amounts are created, or the terminal's identity is recorded in the monitoring entity. Thus, masking allows for a high level of security without providing any insight into the currency amount or the terminal. This results in a two-tiered payment system. On one hand, there is a processing layer that checks the masked electronic data records; on the other hand, there is a direct transaction layer where at least two terminals transmit electronic coin data records.

[0053] When electronic coin data records are used for direct payments between two terminals, the masked coin data records are registered in the monitoring entity.

[0054] The steps for switching the transmitted electronic coin data record include the following sub-steps:

[0055] – Based on the transmitted coin data record, generate an electronic coin data record to be switched in the second terminal, wherein…

[0056] – Using the hidden amount transmitted in the transmitted electronic coin data record, generate the hidden amount of the electronic coin data record to be switched in the second terminal; and

[0057] – Use the transmitted currency amount of the transmitted electronic coin data record as the currency amount of the electronic coin data record to be switched.

[0058] When the electronic coin data record is transmitted from the first terminal to the second terminal, both terminals become aware of the electronic coin data record. To prevent the first terminal, which is currently making a payment, from also using the electronic coin data record for payment at another (third) terminal, the transmitted electronic coin data record is switched from the first terminal to the second terminal. Preferably, the switching can be performed automatically upon receiving the electronic coin data record. Alternatively, this can also be done upon request, such as according to commands from the first terminal and / or the second terminal.

[0059] In a preferred embodiment, generation includes creating a hidden amount for the electronic coin data record to be switched, preferably using a new hidden amount (e.g., a random number) combined with the hidden amount of the transmitted electronic coin data record. Preferably, the hidden amount of the electronic coin data record to be switched is obtained as the sum of the hidden amount of the transmitted electronic coin data record and the random number that serves as the new (i.e., additional) hidden amount. Furthermore, the currency amount of the transmitted electronic coin data record is preferably used as the currency amount of the electronic coin data record to be switched. Therefore, no additional money is generated, and the currency amounts of the two coin data records are the same.

[0060] The registration following the switching step invalidates the electronic coin data record sent by the first terminal, and is accordingly identified as invalid in the first terminal's second spending attempt. The (additional) coin data record generated by the second terminal becomes valid after successfully completing the check.

[0061] When a switch (also called an "exchange") occurs, the electronic coin data record received from the first terminal results in a new electronic coin data record, which preferably has the same monetary amount, i.e., the so-called electronic coin data record to be switched. The new electronic coin data record is generated by the second terminal, preferably by using the monetary amount of the received electronic coin data record as the monetary amount of the electronic coin data record to be switched. A new hidden amount is generated, such as a random number. After the switch, the received electronic coin data record and the electronic partial coin data record to be switched are preferably masked in the terminal by applying a homomorphic one-way function to the received electronic coin data record and the electronic partial coin data record to be switched, so as to obtain a masked received electronic coin data record and a masked electronic partial coin data record to be switched accordingly. Furthermore, the additional information required for registering the switch of the masked electronic coin data record in the remote monitoring entity is preferably calculated in the terminal. The additional information preferably includes a range proof of the masked electronic coin data record to be switched and a range proof of the masked received electronic coin record. A range proof is a proof that the monetary value of an electronic coin data record is not negative, that the electronic coin data record was validly created, and / or that the monetary value and hidden amount of the electronic coin data record are known to the creator of the range proof. Specifically, range proofs are used to provide said proof(s) without revealing the monetary value and / or hidden amount of the masked electronic coin data record. These range proofs are also known as “zero-knowledge range proofs.” Ring signatures are preferably used as range proofs. The switching of the masked electronic coin data record is then registered with a remote monitoring entity.

[0062] This switching is necessary to invalidate the electronic coin data record received from the first terminal, thereby preventing double spending. This is because, as long as the electronic coin data record has not been switched, the first terminal, knowing and therefore still possessing it, could pass the received electronic coin data record to a third device. For example, by adding a new hidden amount to the hidden amount in the received electronic coin data record, a hidden amount known only to the second terminal is obtained, making the switching secure. The newly created hidden amounts must have high entropy, as they are used as a dazzle factor for the corresponding masked electronic coin data record. Preferably, a random number generator on the terminal is used for this purpose. This protection can be tracked in a monitoring entity.

[0063] In the segmentation step, the electronic coin data record of the second terminal is segmented into a first electronic coin data record and a second electronic coin data record. Preferably, segmentation is performed on one hand by determining a portion of the monetary amount and a portion of the hidden amount (each between 0 and the received monetary amount or the hidden amount) of the first electronic coin data record, and on the other hand, segmentation is performed by calculating the monetary amount of the second electronic coin data record as the difference between the received monetary amount and the portion of the monetary amount of the first electronic coin data record, and calculating the hidden amount of the second electronic coin data record as the difference between the received hidden amount and the portion of the hidden amount of the first electronic coin data record. After segmentation, the electronic coin data record to be segmented, the first electronic coin data record, and the second electronic coin data record are masked in the second terminal by applying homomorphic one-way functions respectively, so as to obtain the masked electronic coin data record to be segmented, the masked first electronic coin data record, and the masked second electronic coin data record accordingly. In addition, the additional information required for registering the segmentation of the masked electronic coin data record in the remote monitoring entity is calculated in the terminal. The additional information preferably includes range proofs for the masked electronic coin data record to be segmented, range proofs for the first masked electronic coin data record, and range proofs for the second masked electronic coin data record. A range proof is a proof that the monetary value of the electronic coin data record is not negative, that the electronic coin data record has been validly created, and / or that the monetary value and hidden amount of the electronic coin data record are known to the creator of the range proof. Specifically, range proofs are used to provide said proofs(s) without revealing the monetary value and / or hidden amount of the masked electronic coin data record. These range proofs are also called “zero-knowledge range proofs.” Preferably, a ring signature is used as the range proof. The segmentation of the masked electronic coin data record is then registered in a remote monitoring entity. In this way, the amount of currency to be transferred can be adapted to corresponding needs. The terminal owner does not always have to transfer the entire amount of currency to another terminal.

[0064] The advantage of splitting and subsequently registering is that the owner of at least one electronic coin data record does not always have to transfer the entire monetary amount at once, but rather the corresponding partial amount. As long as all electronic partial coin data records have a positive monetary amount less than the monetary amount of the electronic coin data record from which the split occurs, and the sum of the electronic partial coin data records equals the electronic partial coin data record to be split, the monetary value can be split without constraint. Alternatively or additionally, a fixed denomination can be used. Alternatively, the hidden amount can be generated outside the terminal and obtained via a (secure) communication channel. Preferably, a random number generator on the terminal is used for this purpose. To track all checks, the monitoring entity can, for example, observe partial steps of the monitoring entity in appropriate places and also set markers (called flags) for this purpose to record intermediate stages. After the checks associated with the split command are successfully completed, that is, if the flags are properly completed, the (masked) first electronic partial coin data record and the (masked) second electronic partial coin data record are preferably marked as valid. The (masked) electronic coin data record to be split automatically becomes invalid. Preferably, the monitoring entity transmits the result of executing the split command to the "command" terminal, that is, which of the masked electronic coin data records involved after the execution of the split command are valid.

[0065] In the step of merging electronic coin data records, another electronic coin data record (the merged electronic coin data record) is determined from the first and second electronic coin data records. The hidden amount of the electronic coin data record to be merged is calculated by summing the corresponding hidden amounts of the first and second electronic coin data records. Furthermore, it is preferable to calculate the monetary amount of the connected electronic coin data record by summing the corresponding monetary amounts of the first and second electronic coin data records.

[0066] After merging, the first electronic coin data record, the second electronic coin data record, and the electronic coin data record to be merged are masked in the (first and / or second) terminals by applying a homomorphic one-way function to them, so as to obtain the masked first electronic coin data record, the masked second electronic coin data record, and the masked electronic coin data record to be merged accordingly. Furthermore, additional information required for merging the masked electronic coin data records in the remote monitoring entity is calculated in the terminal. Preferably, the additional information includes range proofs for the masked first electronic coin data record and range proofs for the masked second electronic coin data record. A range proof is proof that the monetary value of the electronic coin data record is not negative, that the electronic coin data record has been validly created, and / or that the monetary value and hidden amount of the electronic coin data record are known to the creator of the range proof. Specifically, range proofs are used to provide (multiple) of the aforementioned proofs without revealing the monetary value and / or hidden amount of the masked electronic coin data record. These range proofs are also referred to as "zero-knowledge range proofs." Preferably, the ring signature is used as a range proof. The merge of the two masked electronic coin data records is then registered in the remote monitoring entity.

[0067] The merge command or step can be used to combine two electronic coin data records. The monetary amount and hidden amount are added together. Similar to splitting, merging also validates the two original coin data records.

[0068] The key difference between this invention and known solutions lies in that the monitoring entity maintains only (i.e., exclusively) a record of the masked electronic coin data, and optionally maintains a list of operations or changes to the masked electronic coin data record. The actual payment transaction is not registered with the monitoring entity but occurs directly at the direct transaction layer between terminals.

[0069] According to the present invention, a two-layer payment system is provided, consisting of a direct payment transaction layer and a monitoring layer. The direct payment transaction layer is used for the direct exchange of (unmasked) electronic coin data records, while the monitoring layer can also be referred to as a "hidden electronic data record ledger." Payment transactions are not recorded in the monitoring entity of the inspection layer, but are only masked electronic coin data records and their operations for the purpose of verifying the validity of the (unmasked) electronic coin data records. This ensures the anonymity of the participants in the payment system. The monitoring entity provides information about valid and invalid electronic coin data records, for example, to avoid multiple expenditures of the same electronic coin data record or to verify the authenticity of the electronic coin data record as validly issued electronic money.

[0070] Therefore, the first terminal and / or the second terminal can transmit electronic coin data records to another terminal in the direct payment transaction layer without needing to connect to the inspection entity, especially when the terminal is offline.

[0071] Here, the first terminal and / or the second terminal may have a secure element in which the electronic coin data record is securely stored. The secure element is preferably a special computer program product, particularly in the form of a secure runtime environment (referred to as a Trusted Execution Environment (TEE)) within the terminal's operating system, stored on a data storage device (e.g., a mobile terminal, machine, preferably an ATM). Alternatively, the secure element may be formed, for example, as special hardware, particularly in the form of a secure hardware platform module called a Trusted Platform Module (TPM), or as an embedded secure module, eUICC, or eSIM. The secure element provides a trusted environment.

[0072] Communication between the two terminals can be wireless or wired, or, for example, optical, preferably via QR codes or barcodes, and can be configured as a secure channel. The optical method may include, for example, the steps of generating optical codes (particularly 2D codes, preferably QR codes) and reading them using the optical codes. Therefore, the exchange of electronic coin data records is secured, for example, by cryptographic keys, such as session keys or symmetric or asymmetric key pairs negotiated for the exchange of electronic coin data records.

[0073] Through communication between terminals (e.g., via their secure elements), the exchanged electronic coin data records are protected from theft or manipulation. Therefore, the secure element level complements the established security of blockchain technology.

[0074] Furthermore, an advantage is that electronic coin data records can be transmitted in any format. This means they can be transmitted (i.e., transferred) over any channel. They do not need to be stored in a specific format or through a specific program.

[0075] Specifically, a mobile telecommunications terminal (e.g., a smartphone) is considered a terminal. Alternatively or additionally, a terminal may also be a device such as a wearable device, smart card, automaton, tool, vending machine, or container or vehicle. Therefore, the terminal according to the invention is either fixed or mobile.

[0076] The terminal is preferably configured to use the Internet and / or other public or private networks. For this purpose, the terminal uses suitable connectivity technologies (e.g., Bluetooth, LoRa, NFC, and / or WiFi) and includes at least one corresponding interface. The terminal may also be configured to connect to the Internet and / or other networks via access to a cellular network.

[0077] In one embodiment, when multiple electronic coin data records are present or have been received, the first and / or second terminals in the illustrated method process the received electronic coin data records according to their monetary values. Therefore, it is anticipated that electronic coin data records with higher monetary values ​​will be processed before those with lower monetary values. In one embodiment, the first and / or second terminal devices may be configured, upon receiving an electronic coin data record, to merge it with an electronic coin data record already present in the second terminal device, depending on the attached information (e.g., currency or denomination), and perform a merging step accordingly. Furthermore, the second terminal may also be configured to automatically perform a switch after receiving an electronic coin data record from the first terminal.

[0078] In one embodiment, additional information (particularly metadata, such as currency) is transmitted from the first terminal to the second terminal during transmission. In one embodiment, this information may be included in the electronic coin data record.

[0079] In a preferred embodiment, the method further includes the steps of: masking the transmitted electronic coin data record in a second terminal by applying a homomorphic one-way function to the transmitted electronic coin data record; and sending the masked transmitted electronic coin data record to a remote monitoring entity for verification of its validity by the remote monitoring entity. In this case, for example, the entire monetary amount is transferred to the second terminal as part of the electronic coin data record. Before the recipient accepts the electronic coin data record, the recipient checks its validity (if applicable). For this purpose, the second terminal generates the masked transmitted electronic coin data record, sends it to the monitoring entity, and in doing so, queries the monitoring entity for the validity of the electronic coin data record. The monitoring entity then checks whether the masked transmitted electronic coin data record exists and whether it is still valid, i.e., not yet used by another terminal, in order to avoid double spending.

[0080] In one embodiment, a certificate is created in a second terminal. The certificate includes information regarding the correspondence between the currency amount in the transmitted electronic coin data record and the currency amount in the electronic coin data record to be switched. Preferably, the certificate includes only information about the correspondence and not information about the currency amount.

[0081] Preferably, during registration, the electronic coin data records of the first terminal and / or the second terminal are checked in the monitoring entity. The check is performed depending on the steps preceding the check, such as whether switching, merging, and / or splitting steps have occurred. Here, the monitoring entity can check, for example, the validity of the transmitted and / or split and / or first and second (masked) electronic coin data records. This allows it to determine whether the electronic coin record is being processed for the first time. If the (masked) electronic coin data records are invalid (i.e., especially if they are not present in the monitoring entity), registration cannot be successfully performed, for example because the terminal attempts to output the electronic coin data record several times.

[0082] In another preferred embodiment, after the switching step is performed in the terminal, a switching command prepared by the terminal is sent to the monitoring entity (as a registration request). The switching command preferably includes a masked received electronic coin data record, a masked electronic coin data record to be switched, and preferably includes additional information required for verification by the monitoring entity. The additional information serves to prove to the "commanding" terminal, preferably by means of a zero-knowledge proof, that the monetary amount and hidden amount of the received electronic coin data record are known without transmitting values. The verification entity verifies the verifiability of the zero-knowledge proof, the validity of the masked received electronic coin data record, and that the monetary amount of the received electronic coin data record is equal to the monetary amount of the electronic coin data record to be switched. To prove that only the new hidden amount is added to the hidden amount of the received electronic coin data record, but the monetary amount remains the same, the second terminal can preferably prove that the difference between the masked received coin data record and the masked electronic coin data record to be switched has a special representation, namely, a public key representation. This is accomplished by generating a signature for the masked electronic coin data record to be switched with the added hidden amount. The generated signature of the masked electronic coin data record to be switched can then be checked in the monitoring entity; this is considered proof that the second terminal knows about the added hidden amount. After successful completion of the checks associated with the switching command, i.e., if the marking is properly performed, the (masked) electronic coin data record to be switched is preferably marked as valid. Previously registered masked electronic coin data records automatically become invalid, if applicable. Alternatively, previously registered masked electronic coin data records are marked as invalid or deleted. The monitoring entity preferably transmits the execution result of the switching command to the "command" terminal, i.e., which of the masked electronic coin data records involved are valid after the switching command has been executed.

[0083] In another preferred embodiment, after the segmentation step is performed, a segmentation command prepared by the terminal is sent to a monitoring entity (as a registration request) for registration. It includes a masked record of the electronic coin to be segmented, a masked first electronic partial coin data record, a masked second electronic partial coin data record, and preferably includes additional information required for inspection by the monitoring entity. This additional information serves as proof from the "command" terminal, demonstrating that, without transmitting values, the monetary amount and hidden amount of the electronic coin data record to be segmented are known, preferably by means of a zero-knowledge proof. The inspection entity checks the verifiability of the zero-knowledge proof, the validity of the masked electronic coin data record to be segmented, and whether the sum of the monetary amounts of the first and second electronic coin data records equals the monetary amount of the electronic coin data record to be segmented (amount neutrality). This is preferably accomplished by the monitoring entity comparing the sum of the masked first and second electronic partial coin data records with the masked partial coin data record to be segmented.

[0084] In another preferred embodiment, after the merging step has been performed, a merging command prepared by the terminal is sent to a monitoring entity for registration (as a registration request). It includes a first masked electronic coin data record, a second masked electronic coin data record, and a masked partial coin data record to be merged, and preferably includes additional information required for inspection by the monitoring entity. This additional information serves as proof from the "command" terminal, proving that, without transmitting values, the monetary amounts and hidden amounts of the first and second electronic coin data records are known, preferably by means of zero-knowledge proofs. The inspection entity checks the verifiability of the zero-knowledge proofs, the validity of the masked first electronic coin data record, the validity of the masked second electronic coin data record, and that the sum of the monetary amounts of the first and second electronic coin data records equals the monetary amount of the electronic coin data record to be merged (amount neutrality). This is preferably accomplished by the monitoring entity comparing the sum of the masked first and second electronic coin data records with the masked partial coin data record to be merged. After the checks associated with the merge command have been successfully completed, i.e., after the marking has been properly performed, the (masked) electronic coin data records to be merged are preferably marked as valid. Here, the (masked) first electronic coin data record and the (masked) second electronic coin data record automatically become invalid. Alternatively, previously registered masked electronic coin data records are marked as invalid or deleted. The monitoring entity preferably transmits the execution result of the merge command to the "command" terminal, i.e., which of the masked electronic coin data records involved are valid after the merge command has been executed.

[0085] In one embodiment, the transmitted electronic coin data record is masked and its validity is checked before it is registered with the monitoring entity. First, the second terminal sends a validity request for the masked received electronic coin data record and only uses it if the received electronic coin data record is valid. Subsequently, for example, a registration request may be sent or the received (unmodified) electronic coin data record may be transmitted, particularly to another terminal or another system participant, such as a server entity of a commercial bank.

[0086] In a preferred embodiment, the monitoring entity is a remote entity. Therefore, for example, it is intended to establish a communication connection to the monitoring entity used for registering electronic coin data records.

[0087] The monitoring entity is configured as a higher-level entity. Therefore, the monitoring entity need not be deployed at the terminal level or terminal layer (direct transaction layer). The monitoring entity is preferably provided for managing and inspecting masked electronic coin data records. It is deployed in the issuance layer and / or a separate monitoring layer, in which the issuing entity is also deployed. It is conceivable that the monitoring entity also manages and inspects transactions between the first terminal and the second terminal.

[0088] The monitoring entity is preferably a decentralized controlled database, referred to as distributed ledger technology (DLT), in which masked electronic coin data records are registered along with their corresponding processing. In a preferred embodiment, the validity status of the (masked) electronic coin data records can be derived from this. The validity of the (masked) electronic coin data records is preferably recorded in and by the checking entity. Registration of processing or processing steps may also involve registering check results and intermediate check results related to the validity of the electronic coin data records. If the processing is final, this is indicated, for example, by appropriate flags or derived overall flags. The final processing then determines whether the electronic coin data record is valid or invalid.

[0089] Furthermore, this database is preferably a non-public database, but it can also be implemented as a public database. This database allows for a simple way to check the validity of coin data records and prevents "double-spending," i.e., multiple spending, without registering or recording the payment transaction itself. DLT describes a technology for networked computers that agrees on the order of certain transactions and the updating of data for these transactions. It corresponds to a decentralized management system or a decentralized database.

[0090] In a further embodiment, the database can also be configured as a public database.

[0091] Alternatively, the monitoring entity is a centrally managed database, for example, in the form of a publicly accessible data store or as a hybrid of a central and decentralized database.

[0092] The initial electronic coin data record is preferably created specifically by the issuing entity. Preferably, switched, split, or merged electronic coin data records (especially electronic partial coin data records) can also be generated by the terminal. The creation and selection of the currency amount preferably also includes selecting a hidden amount with high entropy.

[0093] The issuing entity is a computing system preferably located remotely from the first terminal and / or the second terminal. The issuing entity is particularly preferably associated with a central bank. After creating a new electronic coin data record, the new electronic coin data record is masked in the issuing entity by applying a homomorphic one-way function to obtain a masked new electronic coin data record accordingly. Furthermore, the issuing entity computes additional information required to register the creation of the masked new electronic coin data record in the remote monitoring entity. This additional information is preferably proof that the (masked) new electronic coin data record originates from the issuing entity, for example, by signing the masked new electronic coin data record. In one embodiment, it is intended that when the electronic coin data record is generated, the issuing entity can sign the masked electronic coin data record with its signature. The issuing entity's signature is preferably stored in the monitoring entity. In one embodiment, it is conceivable that the issuing entity also sends a range certificate with the generated electronic coin data record to prove ownership of the electronic coin data record.

[0094] The issuing entity can preferably disable the electronic coin data record it owns (i.e., it knows its currency amount and hidden amount) by masking the electronic coin data record to be disabled using a homomorphic one-way function and preparing a disable command or disable request for the monitoring entity. In addition to the masked electronic coin data record to be disabled, proof of the disable step initiated by the issuing entity (e.g., in the form of a signed masked electronic coin data record to be disabled) is preferably also part of the disable command. As additional information, the disable command may include proof of the range of the masked electronic coin data record to be disabled. The disable of the masked electronic coin data record is then registered with the remote monitoring entity. The disable step is triggered by the disable command.

[0095] In another preferred embodiment, the deactivation order (or deactivation request) is prepared in the issuing entity and sent to the monitoring entity. The deactivation order includes a masked electronic coin data record to be deactivated, and preferably, additional information required for verification by the monitoring entity. The additional information serves to prove that the deactivation order was initiated by the issuing entity, preferably by means of a signed masked electronic coin data record to be deactivated. The verification entity checks the validity of the signature, the masked electronic coin data record to be deactivated, and optionally, proof of the scope of the masked electronic coin data record to be deactivated. After successfully completing the checks associated with the deactivation order, i.e., particularly if the marking is properly performed, the (masked) electronic coin data record to be deactivated is preferably marked as invalid (or deleted). The monitoring entity preferably transmits the execution result of the deactivation order to the issuing entity, i.e., after the deactivation order has been executed, the (masked) electronic coin data record to be deactivated is invalid.

[0096] The creation and deactivation steps are preferably performed in a secure location, particularly not on a terminal. In a preferred embodiment, the creation and deactivation steps are performed or initiated solely by the issuing entity. These steps are preferably performed in a secure location, such as in a hardware and software architecture developed for processing sensitive data materials in an insecure network. Deactivating the corresponding masked electronic coin data record has the effect that the corresponding masked electronic coin data record is no longer available for further processing, particularly transactions, because it is already in the monitoring entity and marked as invalid by the monitoring entity. However, in one embodiment, it may be stipulated that the deactivated masked electronic coin data record is archived at the issuing entity. The fact that the deactivated masked electronic coin data record is no longer valid can be identified, for example, using a flag or some other encoding, or the deactivated masked electronic coin data record can be destroyed and / or deleted. Of course, the deactivated masked electronic coin data record can also be deleted.

[0097] The method according to the invention enables various processing operations on electronic coin data records and corresponding masked electronic coin data records. Each processing operation (particularly creation, deactivation, splitting, merging, and switching) is registered in a monitoring entity. Processing operations can be appended in an immutable form to a list of previous processing operations for each masked electronic coin data record. The processing operations “create” and “deactivate” (which involve the existence of the monetary amount itself, i.e., creating, deleting, or even destroying money) require additional approval from the issuing entity, for example, in the form of a signature, for registration in the monitoring entity. Other processing operations (splitting, merging, switching) do not require any authorization from the issuing entity or the requesting party / command initiator (= the payer, e.g., the first terminal).

[0098] Processing at the direct transaction layer affects only the ownership structure and / or the association between the coin data record and the terminal of the corresponding electronic coin data record. The corresponding processing results are registered in the monitoring entity. A database of valid masked coin data records is adapted accordingly, for example, by adding and deleting masked coin data records. However, preferably, it is implemented by means of corresponding list entries in a database, which includes multiple tags that must be set by the monitoring entity. One possible structure of the list entries includes, for example, columns(s) of the predecessor coin data record(s), columns(s) of the successor coin data record(s), a signature column of the issuing entity, and at least one tag column. Changes to tag states require approval from the monitoring entity and must be immutably preserved. A change is final if and only if the monitoring entity has verified the required tag, i.e., for example, if state “0” has been changed to state “1” after a corresponding check. If the check fails or takes too long, a change is made instead, for example, from state “-” to state “0”. It is conceivable that more state values ​​and / or the state values ​​mentioned herein are interchangeable. Preferably, the validity of the corresponding (masked) electronic coin data record is represented by summarizing the status values ​​of the markers in the columns of each masked electronic coin data record involved in the registration process.

[0099] In another exemplary embodiment, at least two, preferably three, or even all of the aforementioned markers can be replaced by a single marker set when all checks have been successfully completed. Furthermore, the two columns of predecessor and successor data records can each be combined into one column, with all coin data records listed together. In this way, each field entry can manage more than two electronic coin data records, and therefore, for example, it is possible to implement splitting into more than two coins.

[0100] The checks performed by the inspection entity to determine whether the inspection process is final have been described above, and in particular:

[0101] – Are masked electronic coin data records from (multiple) predecessors valid?

[0102] - Check if the correct check value was obtained?

[0103] – Does the range of data recorded by the masked electronic coin prove successful?

[0104] Is the signature on the masked electronic coin data record a valid signature of the issuing entity?

[0105] Preferably, the masked electronic coin data record is invalid when one of the following checks is triggered:

[0106] (1) The masked electronic coin data record was not registered in the monitoring entity;

[0107] (2) The final processing of the masked electronic coin data record indicates the existence of its predecessor coin data record, but this final processing is not final; or

[0108] (3) The final processing of the masked electronic coin data record indicates the existence of its subsequent coin data record, and the final processing is final;

[0109] (4) A masked electronic coin record is not a valid successor to a masked electronic record unless it is signed by the issuing entity.

[0110] The switching, splitting, or merging (registration modification) and creation and deactivation (initial registration and final deactivation) steps listed here are all triggered in the monitoring entity by the corresponding request (or command) (e.g., the corresponding create, switch, split, merge, or deactivation command).

[0111] In one aspect of the invention, a payment system for exchanging monetary amounts comprises: an accounting layer including a database (preferably a decentralized controlled database, distributed ledger technology (DLT)) storing masked electronic coin data records; a direct transaction layer including at least two terminals capable of performing the methods described above; and / or an issuing entity for initially generating or creating the electronic coin data records. Here, the issuing entity can prove that the masked generated electronic coin data records were generated by it, and the issuing entity can preferably identify itself by a signature, and the monitoring entity can check the signature of the issuing entity. In one embodiment, it is conceivable that the issuing entity also sends a proof of scope of the generated electronic coin data records to prove ownership of the electronic coin data records.

[0112] In a preferred embodiment, the payment system includes an issuing entity for generating electronic coin data records. Here, the issuing entity can prove that the masked generated electronic coin data records were generated by it, and the issuing entity can preferably identify itself by a signature, and the monitoring entity can check the issuing entity's signature. In one embodiment, it is conceivable that the issuing entity also sends a proof of scope of the generated electronic coin data records to prove ownership of the electronic coin data records.

[0113] The payment system is preferably configured to perform the above-described methods and / or at least one variant of the embodiments.

[0114] Another aspect of the invention relates to a currency system comprising an issuing entity, a monitoring entity, a first terminal, and a second terminal. The issuing entity is configured to create electronic coin data records. The masked electronic coin data is formatted such that it has been veribly created by the issuing entity. The monitoring entity is configured to perform one of the methods described above, namely, in particular, processing registration requests. Preferably, the terminals, i.e., at least the first and second terminals, are adapted to perform one of the methods described above for transmitting coin data records.

[0115] In a preferred embodiment of the currency system, only the issuing entity is authorized to initially create the electronic coin data record. Processing (e.g., merging, splitting, and / or switching steps) can and preferably is performed by the terminal. Preferably, the deactivation processing step can be performed only by the issuing entity. Therefore, only the issuing entity will be authorized to invalidate the electronic coin data record and / or the masked electronic coin data record.

[0116] The inspection entity and the issuer entity are preferably located in the server entity, or are available as computer program products on the server and / or computer.

[0117] Electronic coin data records can be provided in a wide variety of different forms and can therefore be exchanged via various communication channels (hereinafter also referred to as interfaces). This creates a very flexible exchange of electronic coin data records.

[0118] The currency system may include other coin-owning entities, particularly server or computer entities. Like terminals, coin-owning entities can transmit electronic coin data records, especially between or from each other, and send registration requests to monitoring entities for masked modifications of the electronic coin data records. For example, other coin-owning entities may be associated with commercial banks, online stores, or service providers.

[0119] This paper proposes a solution for issuing digital money in the form of electronic coin data records, similar to the use of conventional (analog) banknotes and / or coins. Digital money is represented by electronic coin data records. Like (analog) banknotes, these electronic coin data records can be used for all forms of payment, including peer-to-peer payments and / or POS payments. Knowing all components of a valid electronic coin data record (specifically the monetary amount and hidden amount) is equivalent to ownership of the digital money. Therefore, it is recommended that these valid electronic coin data records be kept confidential, for example, by storing them in a secure element / insurance module of a terminal and processing them therein. To determine the authenticity of the electronic coin data records and prevent double-spending, masked electronic coin data records are maintained in a monitoring entity as the sole public representation of the corresponding electronic coin data record. Knowing or possessing a masked electronic coin data record does not imply ownership of the money. Rather, it is equivalent to verifying the authenticity of an analog payment method.

[0120] The monitoring entity stores valid, masked electronic coin data records. Therefore, the recipient of the electronic coin data record will first generate a masked received electronic coin data record, which will have its validity confirmed by the monitoring entity. A significant advantage of this solution according to the invention is that digital money is distributed to terminals, retailers, banks, and other users of the system, but no digital money or other metadata is stored in the monitoring entity (i.e., the sharing entity). The monitoring entity may also preferably store the validity status of the masked electronic coin data records and / or flags containing executed and planned processes related to the masked electronic coin data records. The status of the corresponding masked electronic coin data record, indicating whether the corresponding (unmasked) electronic coin data record is valid, i.e., ready for payment, can be derived from the flags associated with the processing.

[0121] The proposed solution can be integrated into existing payment systems and infrastructure. Specifically, according to this solution, a combination of analog payment processes with banknotes and coins, as well as digital payment processes, is possible. Payment processes can be conducted using banknotes and / or coins, but change or tax refunds can be recorded as electronic coin data. For example, ATMs and / or mobile terminals with corresponding configurations (especially suitable communication interfaces) can be provided for transactions. The exchange of electronic coin data records for banknotes or coins is also conceivable. Attached Figure Description

[0122] The invention, along with other embodiments and advantages thereof, will now be explained in more detail with reference to the accompanying drawings, which illustrate exemplary embodiments of the invention only. The same components in the drawings have the same reference numerals. These figures should not be considered true scale; individual elements in the figures may be enlarged or simplified.

[0123] In the diagram:

[0124] Figure 1 An embodiment of the payment system according to the present invention is shown;

[0125] Figure 2 An example of a monitoring entity is shown;

[0126] Figure 3 An embodiment of a payment system for splitting and switching electronic coin data records according to the present invention is shown;

[0127] Figure 4 An embodiment of a payment system for merging electronic coin data records according to the present invention is shown;

[0128] Figure 5 An exemplary embodiment of the method according to the present invention and the corresponding coin data recording processing steps is shown;

[0129] Figure 6 An embodiment of the method according to the present invention and the corresponding processing steps for coin data recording are shown;

[0130] Figure 7 Another exemplary embodiment of the method flowchart according to the present invention is shown. Detailed Implementation

[0131] Figure 1 An embodiment of a payment system including terminals M1 and M2 according to the present invention is shown.

[0132] Here, the electronic coin data record C is generated in the issuing entity 1 (e.g., the central bank). i For electronic coin data records including hidden amounts C i Generate masked electronic coin data record Z i This data is then registered in a database that serves as the monitoring entity; this can be termed a "hidden electronic data record ledger." In the context of this invention, the ledger is understood as a list, a directory, and preferably a database structure. Electronic coin data record C i It is output to the first terminal M1.

[0133] For example, generate a real random number as the hidden amount r for this purpose. i The hidden amount r iWith monetary amount υ i Associated, and then the i-th electronic coin data record is formed according to the present invention:

[0134] C i = {υ i ; r i} (1)

[0135] A valid electronic coin data record can be used for payment. Therefore, the two values ​​υ i and r i The owner already possesses digital money because they can use it for payments. However, digital money in the system consists of valid electronic coin data records and corresponding masked electronic coin data records Z. i The pair is defined by equation (2). By applying the homomorphic one-way function f(C)... i Obtain the masked electronic coin data record Z i :

[0136] Z i = f (C i (2)

[0137] This function f(C) i The function f(C) is public, meaning that every system participant can call and use it. i Defined according to equation (3):

[0138] Z i = υ i · H + r i · G (3)

[0139] Here, H and G are generator points of a set G with generators G and H, where the discrete logarithm problem is difficult, and for G and H, the discrete logarithms of the corresponding other bases are unknown. For example, G and H are generator points of elliptic curve cryptography (ECC), i.e., the private keys of ECC. These generator points G and H must be chosen in a way that the relationship between G and H is not publicly known, such that:

[0140] G = n · H (4)

[0141] To prevent currency amounts from being used i The manipulated and effective Z i It can still be calculated, and the connection n must actually be impossible to find. Equation (3) is the "Peterson commitment for ECC", which ensures the monetary amount υ i It can be passed to monitoring entity 2 (i.e., "promised" to monitoring entity 2) without being leaked to monitoring entity 2. Therefore, only the masked coin data record Z iIt was sent (leaked) to public and remote monitoring entities 2.

[0142] Even though this example describes elliptic curve-based encryption, another encryption method based on discrete logarithms can be envisioned.

[0143] Due to the hidden amount r i The entropy, equation (3) allows even in monetary amounts υ i Even within a small range of values, a strong Z-value can be obtained in terms of cryptography. i This means that by simply estimating the monetary amount υ i A simple brute-force attack is practically impossible.

[0144] Equation (3) is a one-way function, which means that from C i Calculate Z i It is easy because there are efficient algorithms, and from Z... i Calculate C i It is very difficult because there is no algorithm that can solve it in polynomial time.

[0145] Furthermore, equation (3) is homomorphic for addition and subtraction, i.e., the following equation applies:

[0146] Z i + Z j = (υ i · H + r i · G)+ (υ j · H + r j · G) = (υ i + υ j )· H +(r i + r j )· G (5)

[0147] Therefore, addition and subtraction operations can be performed either in the direct transaction layer 3 or in parallel in the accounting layer 4, without the accounting layer 4 needing to know the electronic coin data record C. i The homomorphic property of equation (3) allows for data to be obtained solely from masked coin data records Z. i To illustrate valid and invalid electronic coin data records C i And ensure that no new currency amount υ is created. j .

[0148] Due to this homomorphic property, coin data record C i It can be divided into the following according to equation (1):

[0149] C i = C j + Ck = {υ j ; r j} + {υ k ; r k} (6)

[0150] in:

[0151] υ i =υ j +υ k (7)

[0152] r i =r j +r k (8)

[0153] The following applies to the corresponding masked coin data record:

[0154] Z i = Z j + Z k (9)

[0155] For example, using equation (9), one can easily check the following: Figure 3 The "segmentation" or "splitting" process of the coin data record, without requiring monitoring entity 2 to know C. i C j C k Specifically, examine the conditions of equation (9) to verify the split coin record C. j and C k And make the coin record C i invalid. Figure 3 The electronic coin data record C is shown. i This kind of division.

[0156] In the same way, the data records for electronic coins can also be put together (merged), see [link to documentation]. Figure 4 And its explanation.

[0157] In addition, it is necessary to check whether (disallowed) negative currency amounts have been registered. Electronic coin data record C i The owner must be able to prove to monitoring entity 2 all monetary amounts in the processing operation. i All values ​​are within the range of [0,...,n] without notifying the monitoring entity. 2. Currency amount υ i These range proofs are also called "range proofs". Ring signatures are preferably used as range proofs. For this exemplary embodiment, the monetary value and hidden amount of the electronic coin data record are parsed in bit representation, that is, for 0≤j≤n and a j "Element" {0; 1}, υ i =∑aj *2 j And for 0≤j≤n and b j "Element" {0; 1}, r i =∑b j *2 j Preferably, C is performed for each bit. ij =a j ·H+b j ·G and C ij -a j • Ring signature of H, wherein, in one embodiment, it is possible to perform a ring signature only on certain bits.

[0158] Figure 1 Not shown in the image and will be explained later, for example, the new electronic coin data record C i Preferably, the output is not directly sent to the terminal, but is initially sent to a commercial bank.

[0159] exist Figure 1 In the middle, the electronic coin data record C i Electronic coin data record Z generated by issuer entity 1 and masked. i The electronic coin data is calculated by the issuing entity 1 using equation (3) and registered in the monitoring entity 2. The first terminal M1 then records the electronic coin data C. i The data is then transmitted to the second terminal M2. Prior to this, the terminal may optionally perform one of the processing steps (switching, merging, splitting). For example, wireless transmission can be performed via WLAN, NFC, or Bluetooth. The transmission can also be protected by cryptographic encryption methods, such as negotiating a session key or using PKI infrastructure.

[0160] Transmitted electronic coin data record C i As C i *Received at the second terminal M2. When electronic coin data record C is received... i At that time, the second terminal M2 possesses data recorded by the electronic coin C. i The asterisk (*) represents digital currency. If the two terminals trust each other, no further steps are needed to conclude the process. However, terminal M2 is unaware of the electronic coin data record C. i *Whether it is actually effective. In addition, terminal M1 can also record electronic coin data C. i Transmitted to a third terminal (not shown). To prevent this, a further preferred step is provided in the method.

[0161] To examine the received electronic coin data record C i The validity of * is determined in the second terminal M2 using the common one-way function from equation (3) to calculate the masked transmission of the electronic coin data record Z. i*. Data record of the electronic coin transmitted via mask Z i *It is then transmitted to monitoring entity 2 and searched there. If it matches a registered and valid masked electronic coin data record, the received coin data record C is considered valid. i The validity of * is indicated to the second terminal M2, and the received electronic coin data record C is confirmed. i *Equals the registered electronic coin data record C i In one embodiment, using a validity check, the received electronic coin data record C can be determined. i *It remains valid, meaning it has not been used by another processing step or another exchange and / or has undergone another change.

[0162] Preferably, the obtained electronic coin data is recorded and then switched by a second terminal.

[0163] For the method according to the invention, it is important to know only the masked electronic coin data record Z. i It does not authorize the holder to spend digital money. However, only the electronic coin's data record C is known. i Authorized payment, that is, in order to successfully complete a transaction, especially in coin data record C i Under the condition that it is valid. In the electronic coin data record C i The corresponding masked electronic coin data record Z i There is a one-to-one relationship between them. The masked electronic coin data record Z i It is registered with monitoring entity 2 (e.g., a public decentralized database). This registration makes it possible to check the validity of data records, such as whether new monetary amounts have been (illegally) created.

[0164] The main distinguishing feature compared to conventional solutions is the masked electronic coin data record Z. i It is stored in monitoring layer 4, and the electronic coin data is recorded in Z. i All processing operations are registered there, while the actual transfer of digital money occurs in (secret, i.e., undisclosed) direct transaction layer 3.

[0165] To prevent multiple expenditures or ensure more flexible transfers, electronic coin data records can now be processed using the method according to the present invention. Table 1 below lists the various operations, wherein the specified commands also perform the corresponding processing steps:

[0166] Commands or steps Create a signature Create random numbers Create a mask Create range proof create 1 1 1 0 or 1 Discontinued 1 0 1 0 or 1 segmentation 0 1 3 0 or 1 merge 0 0 3 1 Switch 0 1 2 1

[0167] Table 1 - Number of operations to be performed per coin data record processed in the terminal or issuing entity; further operations not listed here are required; alternative implementations of other operations are implied instead of those listed.

[0168] Table 1 above shows that for each coin data record and each processing operation "Create", "Deactivate", "Split", "Merge", and "Switch", different operations can be provided: "Create Signature"; "Create Random Number"; "Create Mask"; "Range Proof". Each processing operation is registered in monitoring entity 2. It can be attached to the masked electronic coin data record Z in an immutable form. i The list of previous processing operations. The “create” and “deactivate” processing operations for electronic coin data records are performed only in a secure location and / or only by selected entities (e.g., issuer entity 1), while all other processing operations can be performed on terminals M1 to M3.

[0169] The number of operations used for each process is marked in Table 1 as “0”, “1”, or “2”. The number “0” indicates that the terminal or issuing entity 1 does not need to perform this operation for the electronic coin data recording process. The number “1” indicates that the terminal or issuing entity 1 must be able to perform this operation once for the electronic coin data recording process. The number “2” indicates that the terminal or issuing entity 1 must be able to perform this operation twice for the electronic coin data recording process.

[0170] In principle, in one embodiment, the scope proof may also be planned to be performed by issuer entity 1 during creation and / or deactivation.

[0171] The operations required by monitoring entity 2 for each processing operation are listed in Table 2 below:

[0172]

[0173] Table 2 - Number of operations to be performed for each coin data record processed in the monitoring entity; further operations not listed here are required; alternative implementations for other operations are implied instead of those listed.

[0174] All operations in Table 2 can be performed in monitoring entity 2, which, as a trusted entity (e.g., a distributed server, especially a distributed trusted server), ensures sufficient integrity of the electronic coin data records.

[0175] Table 3 shows the preferred requirements. Figure 1 Components installed by system participants in the payment system:

[0176]

[0177]

[0178] Table 3 – Preferred Units in System Components

[0179] Table 3 outlines the preferred components used in each system participant (i.e., issuer entity 1, terminal M1, and monitoring entity 2). Terminal M1 can be configured as a wallet for electronic coin data records, i.e., configured as an electronic wallet for data storage, where a large number of coin data records can be stored. Terminal M1 can be implemented, for example, as an application on a retailer's, commercial bank's, or another market participant's smartphone or IT system, and send or receive electronic coin data records. Therefore, the components in the terminal as shown in Table 3 are implemented as software. It is assumed that monitoring entity 2 is based on DLT and is operated by multiple trusted market participants.

[0180] Figure 2 Showing from Figure 1 An exemplary embodiment of monitoring entity 2. In Figure 2 The example database is shown in tabular form, in which masked electronic coin data records Z are registered. i And its possible processing (as shown here). On the other hand, in the simplest embodiment of the database, only the currently valid masked coin data record Z will be stored. i The monitoring entity 2 is preferably located locally, away from terminals M1 to M3, and is housed, for example, in a server architecture.

[0181] Each processing operation (create, deactivate, split, merge, and switch) is registered in monitoring entity 2 and appended in an immutable form to the masked electronic coin data record Z. i The list of previously processed operations is used. Each operation or its check results (i.e., intermediate results of processing) are recorded in monitoring entity 2.

[0182] The processing of "create" and "deactivate" (which involves monetary amounts υ) i The existence of the money itself (i.e., the creation and destruction of the money) requires additional approval from the issuing entity 1 in order to be registered (and recorded) in the monitoring entity 2. Other processing operations (splitting, merging, switching) do not require any authorization from the issuing entity 1 or the order initiator (= the payer, such as the first terminal M1).

[0183] For example, by means of Figure 2The corresponding list entries in the database implement the registration of the corresponding processing in monitoring entity 2. Each list entry has additional markers 25 to 28 indicating the intermediate results of the corresponding processing that must be performed by monitoring entity 2. Markers 25 to 28 are preferably used as auxiliary markers and are discarded by the checking entity after the command is completed. What remains are markers (not shown) regarding the validity of the (masked) electronic coin data records from columns 22a, 22b, 23a and / or 23b. When a processing command is received, the markers are, for example, in a "-" state, and are set to a "1" state after all checks are successfully completed, and are set to a "0" state if at least one check fails. Possible structures for the list entries of coin data records include, for example, two columns 22a and 22b of the predecessor coin data records (O1, O2), two columns 23a and 23b of the subsequent coin data records (S1, S2), a signature column 24 of (multiple) issuing entity 1, and four marker columns 25 to 28. Each entry in columns 25 through 28 has three optional states: "-", "1", or "0". Column 25 (O flag) indicates whether the validity check for the electronic coin data record in column 23a / b was successful. A state "1" means the validity check shows the electronic coin data record in column 23a / b is valid, a state "0" indicates the validity check shows the electronic coin data record in column 23a / b is invalid, and a state "-" indicates the validity check has not yet been completed. Column 26 (C flag) indicates whether a calculation to check the amount neutrality of the masked electronic coin data record was successful. A state "1" means the calculation was successful, a state "0" indicates the calculation was unsuccessful, and a state "-" indicates the calculation has not yet been completed.

[0184] For example, the calculation to be performed in column 26 is:

[0185] (Z O1 + Z O2 ) – (Z S1 + Z S2 ) == 0 (10)

[0186] Column 27 (R flag) indicates whether the validity check of (multiple) range proofs was successful, where a state "1" means the validity check shows that (multiple) range proofs are verifiable, a state "0" indicates that the validity check shows that (multiple) range proofs cannot be reproduced, and a state "-" indicates that the validity check has not yet been completed. Column 28 (S flag) indicates that the signature verification was successful. A state "1" means the validity check shows that the signature can be identified as the signature of the issuing entity, a state "0" indicates that the validity check can not be identified as the signature of the issuing entity, and a state "-" indicates that the validity check has not yet been completed.

[0187] A change in the state of one of the tags (also called a “flag”) requires approval from monitoring entity 2 and must then be stored in monitoring entity 2 in an immutable manner. Processing is final only if and only if the required tags 25 to 28 have been verified by monitoring entity 2 (i.e., changed from state “0” to state “1” or have a state of “1” after the corresponding check).

[0188] To determine whether the masked electronic coin data record Z is valid, monitoring entity 2 searches the current variant for the last change affecting the masked electronic coin data record. Importantly, the masked electronic coin data record Z is valid if and only if it is listed in one of subsequent columns 23a and 23b for its final processing and that final processing has corresponding final markers 25 to 28. Equally important, the masked electronic coin data record Z is valid if and only if it is listed in one of preceding columns 22a and 22b for its final processing and that final processing fails (i.e., at least one of the corresponding request states of markers 25 to 28 is set to "0").

[0189] Equally important, the masked electronic coin data record Z is invalid for all other cases, such as when the masked electronic coin data record Z is not found in monitoring entity 2; or when the last processing of the masked electronic coin data record Z is listed in one of the subsequent columns 23a and 23b but that last processing never becomes the final processing; or when the last processing of the masked electronic coin data record Z is in one of the preceding columns 22a and 22b and that last processing is the final processing.

[0190] The checks by monitoring entity 2 to determine whether the processing is final are shown in columns 25 to 28. The status in column 25 indicates, based on preceding columns 22a and 22b, whether the masked electronic coin data record is valid. The status in column 26 indicates, for example, whether the amount-neutral calculation according to equation (10) is correct. The status in column 27 indicates whether the range proof of the masked electronic coin data record Z can be successfully checked. The status in column 28 indicates whether the signature in column 24 of the masked electronic coin data record Z is a valid signature of issuing entity 1.

[0191] In columns 25-28, a status "0" indicates that the check failed. A status "1" indicates that the check succeeded. A status "-" in columns 25-28 indicates that the check has not been performed. Statuses can have different values, as long as it is clear whether a check was performed or not.

[0192] As an example, five different processing operations are defined, which will be explained in detail here. References Figure 2 The corresponding list item.

[0193] For example, one processing operation is to "create" an electronic coin data record C. i The creation of issuer entity 1 in direct transaction layer 3 includes selecting the currency amount υ. i and creating hidden amount r i As already described by equation (1). Figure 2 As shown, during the "Creation" process, no entries / tags are required in columns 22a, 22b, 23b, and 25 through 27. Masked electronic coin data record Z i It is registered in subsequent column 23a. This registration is preferably performed before transmission to terminals M1 to M3, and in particular, or has already been performed during the creation of issuer entity 1, wherein equation (3) must be performed in both cases. Masked electronic coin data record Z i It is signed by the issuing entity 1 when it is created; this signature is entered into column 24 to ensure the electronic coin data record C. i It is actually created by the issuing entity 1, although other methods can also be used for this purpose. If the received Z i If the signature matches the signature in column 24, a flag (from "0" to "1") is set in column 28. No state change is required based on the flags in columns 25 through 27, and these can be ignored. Range proof is not required because monitoring entity 2 trusts that issuing entity 1 does not issue any negative monetary amounts. However, in an alternative embodiment, it can be sent by issuing entity 1 in the creation command and checked by monitoring entity 2.

[0194] For example, the processing operation is "deactivation". Deactivation (i.e., the destruction of the coin) has a masked electronic coin data record Z after the issuing entity 1 successfully executes the deactivation command. i The effect of invalidation occurs. Therefore, the (masked) electronic coin data record to be deactivated cannot be processed further in accounting layer 4. To avoid confusion, the corresponding (unmasked) electronic coin data record C... i It should also be deactivated in direct transaction layer 3. When "deactivated", predecessor column 22a is written into the electronic coin data record Z. i However, subsequent columns 23a and 23b are not used. When deactivated, the masked electronic coin data record Z must be checked. i To check if the signature matches the signature according to column 24, in order to ensure that the electronic coin data record C i It was actually created by issuing entity 1, although other methods could also be used for this check. If the Z-signature sent along with the deactivation command... iIf the signature can be confirmed by issuing entity 1, then flag 28 (from "0" to "1") is set. Flags according to columns 26 and 27 do not require state changes and can be ignored. Flags according to columns 25 and 28 are set after appropriate checks.

[0195] For example, the processing operation is "splitting". Splitting (that is, splitting the electronic coin data record Z) i The data of the coin is recorded in two electronic parts, Z. j and Z k Initially executed in direct transaction layer 3, such as Figure 3 As shown, the generated currency amount υ j and hidden amount r j 。υ k and r k This is derived from equations (7) and (8). In monitoring entity 2, markers 25 to 27 are set, and the predecessor column 22a is written into the electronic coin data record Z. i The next column, 23a, is written into Z. j And the next column 23b is written to Z. k According to columns 25 to 27, the required state changes occur after the monitoring entity 2 performs the corresponding checks and records the results. The marker in column 28 is ignored.

[0196] For example, one processing operation is "merge". Merge (i.e., merge the data records Z of two electronic coins). i and Z j To form an electronic coin data record Z m Initially conducted in direct transaction layer 3, such as Figure 4 As shown, the monetary amount υ was calculated. m and hidden amount r m In monitoring entity 2, markers 25 to 27 are set, and the previous column 22a is written into the electronic coin data record Z. i The previous column 22b was written to Z. j And the next column 23b is written to Z. m The markers in columns 25 to 27 require a state change, and monitoring entity 2 must perform the corresponding check. A range proof must be provided to show that no new money was created. The marker in column 28 is ignored.

[0197] For example, one processing operation is "switching". Switching is necessary if the electronic coin data record has already been transferred to another terminal, and the update issuance of the transmitting terminal (here, M1) is excluded. During switching (also called "exchange"), the electronic coin data record C received from the first terminal M1... k Data record C was exchanged for a new electronic coin with the same monetary value. lNew electronic coin data record C l Generated by the second terminal M2. This switching is necessary so that the electronic coin data record C received from the first terminal M1 can be processed. k Invalid, thus preventing identical electronic coin data records C k It is output again. This is because as long as the electronic coin data record C... k Without being switched, the first terminal M1 can record the electronic coin data C. k The data is transmitted to the third terminal M3 because the first terminal M1 knows the electronic coin data record C. k For example, by inputting the obtained electronic coin data record C k Hidden amount r k Add new hidden amount r add To perform the switch, thereby obtaining the hidden amount r known only to the second terminal M2. l This can also be performed in monitoring entity 2. To demonstrate that only the new hidden amount r... add Added to the masked received electronic coin data record Z k Hidden amount r k However, the monetary amount remains the same, therefore equation (11) holds true:

[0198] υ k = υ l (11)

[0199] It is valid; the second terminal M2 must be able to prove Z. l -Z k It can be expressed as a scalar multiple of G, i.e., r add *G. This means that only the hidden amount r is generated. add And Z l The monetary amount equals Z k The monetary amount, i.e., Z l =Z k +r add *G. This is achieved using the public key Z. l -Z k =r add *G generates the signature to accomplish this.

[0200] exist Figure 3 The image shows an embodiment of a payment system according to the present invention for splitting and switching electronic coin data records. Figure 3 In the middle, the first terminal M1 has received the coin data record C. i And now we hope not to use the full amount of currency. i Instead, only a portion of v is used. k To conduct a payment transaction, coin data record C is used. iIt is to be divided. Therefore, the monetary amount is first divided:

[0201] υ i = υ j + υ k (12)

[0202] Here, the amount received is υ j υ k Each element in the set must be greater than 0, as negative monetary amounts are not allowed. Furthermore, a new hidden amount is derived:

[0203] r i =r j +r k (13)

[0204] Then, according to equation (3), record C from the coin data. j and C k Obtain the masked coin data record Z j and Z k And register it in monitoring entity 2. For the split, Z is recorded using coin data. i Describe the predecessor column 22a, using Z. j Describe the successor column 23a using Z. k Describe the subsequent column 23b. The markers in columns 25 to 27 require a state change, and monitoring entity 2 performs the corresponding check. The markers in column 28 are ignored.

[0205] Then, the coin data record (here, C) k The data is transmitted from the first terminal M1 to the second terminal M2. To prevent double spending, a switching operation is useful so that the electronic coin data received from the first terminal M1 is recorded as C. k Exchange for new electronic coins with the same monetary value. (Data record C) l New electronic coin data record C l Generated by the second terminal M2. Coin data record C l The monetary amount is adopted and remains unchanged, see equation (11). Then, according to equation (14), the new hidden amount r add Added to received electronic coin record C k Hidden amount r k ,

[0206] r l = r k + r add (14)

[0207] This yields the hidden amount r, known only to the second terminal M2. l To prove that only the new hidden amount radd Added to received electronic coin data record Z k Hidden amount r k However, the monetary amount remains the same (υ k =υ l The second terminal M2 must be able to prove Z. l -Z k It can be represented as a multiple of G. This is based on equation (15) using the public signature R. add To be completed:

[0208] R add = r add · G (15)

[0209] =Z l -Z k =(v l -v k )*H+(r k +r add -r k )*G

[0210] Where G is the generator point of ECC. Then, the coin data record to be switched is C. l By masking equation (3), the masked coin data record Z can be obtained. l Private signature r add This can then be used in monitoring entity 2 to, for example, record Z data of the masked electronic coin to be switched. l The signature, which serves as the second terminal M2, adds a hidden amount r only to the masked electronic coin data record. add And it has no added monetary value (i.e., v) l =v k The proof is valid.

[0211] The proof is as follows:

[0212] Z k = υ k · H + r k · G (16)

[0213] Z l =υ l ·H+r l ·G=υ k ·H+(r k +r add )·G

[0214] Z l –Z k =(r k +r add -rk )·G

[0215] =r add ·G

[0216] Figure 4 An exemplary embodiment of a payment system for merging electronic coin data records according to the present invention is shown. Two coin data records C i and C j Received in the second terminal M2. Similar to... Figure 3 The split, now done by recording the data of two coins in C i and C j The new coin data record Z is obtained by adding the monetary amount and the hidden amount. m Then, the received coin data record C is to be merged. m Perform masking, and record the masked coin data Z. m It is registered in the monitoring entity.

[0217] exist Figure 3 and Figure 4 The diagram again illustrates a variant of the database for monitoring entity 2, containing a list of processing operations for masked coin data records. Other variants of the database can also be used, such as masked coin data records with status or only valid masked coin data records, as already referenced. Figure 2 As stated above.

[0218] Figures 5 to 7 These are exemplary embodiments of the method flowchart of method 100 according to the present invention. They will be explained together below. Figure 5 and Figure 6 .

[0219] Steps 101 to 104 are optional for further methods and are described using the example of terminal M1. In optional steps 101 and 102, after the electronic coin data record is created, the issuing entity 1 requests and provides the coin data record—in this case, to the first terminal M1. In step 103, the signed, masked electronic coin data record is sent to monitoring entity 2. In step 103, the received electronic coin data record C... i According to equation (3), the mask is as follows: Figure 1 As explained in [the document]. Then, in step 104, the masked electronic coin data record Z... i Registered in monitoring entity 2. It is conceivable that the masked electronic coin data record is only valid in the monitoring entity when registered by the participating party (such as a terminal device or server). Alternatively, as per [the relevant regulations]... Figure 1 As explained, after step 102, the masked electronic coin data record Z iThe electronic coin data record may have already been registered as valid in monitoring entity 2, albeit masked. Optionally, terminal M1 may switch the received electronic coin data record in step 104, as will be described in more detail in step 108.

[0220] In step 105, coin data record C i The data is transmitted to the second terminal M2 in the direct transaction layer 3. In optional steps 106 and 107, a validity check is performed using the previous mask, wherein, if successful, monitoring entity 2 confirms the coin data record Z. i Or C i The effectiveness.

[0221] In step 108, the received coin data record C k Switched (received coin data record C) i (Of course, it can also be switched to a new coin data record C) l Thus, the coin data record C k The invalidation and double spending are prevented. For this purpose, the transmitted coin data record C... k Currency amount υ k Used as the “new” currency amount υ l Furthermore, as already explained using equations (14) to (17), the hidden amount r is created. l Additional hidden amount r add This is used to prove that the second terminal M2 did not generate new money (in the form of a higher currency amount). Then, in addition, the masked coin data record Z is used to switch the coins. l It was sent to monitoring entity 2, and from C k To C l The switching was indicated.

[0222] In step 108', the corresponding check is performed in monitoring entity 2. According to Figure 2 The table in Z k The coin data record Z, which is input into column 22a and is to be rewritten, is... l This is input into column 23b. Then, check the information about Z in monitoring entity 2. k Whether it is still valid, i.e., Z k Whether the final processing is input into one of column 23a / b (as Z) k (Proof that it has not been further divided, deactivated, or merged) and whether the final processing check failed. Additionally, Z l The data is input into column 23b, and the markers in columns 25, 26, and 27 are initially set to "0". Now, perform an operation on Z. lThe validity check can be performed using the checks according to equations (16) and (17). If successful, the flag in column 25 is set to "1", otherwise to "0". Now, the check is performed, and the calculation according to equation (10) shows Z. k and Z l It is valid, and the flag in column 26 is set accordingly. The range is also checked for consistency, and then the flag in column 27 is set. If all three checks are successful, and this is committed accordingly in monitoring entity 2, the coin data record is considered switched. This means that coin data record C... k No longer valid, and coin data record C l This is now effective. If the third terminal M3 queries the monitoring entity 2 for the validity of the (double-issued) coin data record, then double disbursement will no longer be possible.

[0223] Generally speaking - different Figure 5 The illustration in the image - the electronic coin data record created by the issuing entity C i The data is transmitted (issued) to an entity within a commercial bank (such as a server, computer, etc.). The commercial bank's (server) entity provides the electronic coin data record to the terminal. In steps 101 and 102, terminal M1 requests and receives the electronic coin data record from the commercial bank's entity. Specifically, when terminal M1 requests and receives the electronic coin data record C from the commercial bank's server... i At that time, it is useful to switch in step 104.

[0224] In step 109, the two coin data records C k and C i Merged to form a new coin data record C m The result is coin data record C k C i This renders the expenditure ineffective and prevents double spending. Therefore, the monetary amount υ m Composed of two monetary amounts υ k and υ i Formed. Therefore, the hidden amount r m Two hidden amounts r k and r i Formation. In addition, the masked coin data record to be merged is obtained by equation (3), and it (along with other information) is sent to monitoring entity 2, and merging is requested as processing.

[0225] In step 109', the corresponding check is performed in monitoring entity 2. In this case, according to Figure 2 In the table, enter Z in column 23b. m Then, monitoring entity 2 checks Z. kand Z i Whether it is still valid, i.e., Z k Or whether the final processing of Zi is input into one of column 23a / b (as Z) k and Z i (proof that it has not been further split, deactivated, or merged), and whether the final processing check failed. Furthermore, the markers in columns 25, 26, and 27 were initially set to "0". Now proceed with Z. m The validity check can be performed using equations (16) and (17). If successful, the flag in column 25 is set to "1", otherwise to "0". The check is now performed, and Z is calculated according to equation (10). i Add Z k Equal to Z m And accordingly set the marker in column 26. Also check if the ranges are consistent, and then set the marker in column 27.

[0226] In step 110, coin data record C i The data record of the coin is divided into two parts, C. k and C j Thus, the coin data record C i Invalid, and the data records for the two split portions of the coin will be valid. Therefore, the currency amount υ i Divided into two monetary amounts υ k and υ j Therefore, the amount r is hidden. i Divided into two hidden amounts r k and r j Furthermore, using equation (3), the masked partial coin data record Z is obtained. k and Z j They are then sent to monitoring entity 2 along with additional information (such as distance proof) and a request is made for splitting as processing.

[0227] In step 110', the corresponding check is performed in monitoring entity 2. According to the table in the figure, Z... j and Z k This is input into column 23a / b. Then, monitoring entity 2 checks Z. i Whether it is still valid, i.e., Z i Whether the final processing is input into one of column 23a / b (as Z) i (Proof that no further splitting, deactivation, or connection was performed), and a final processing check was performed to determine if it failed. Additionally, the markers in columns 25, 26, and 27 were initially set to "0". Now proceed with the discussion of Z. j and Z kThe validity check can be performed using equations (16) and (17). If successful, the marker in column 25 is set to "1". Now, the check is performed, and the calculation based on equation (10) shows Z. i Equal to Z k Add Z j And accordingly set the markers in column 26. Also check if the ranges are consistent, and then set the markers in column 27.

[0228] Figure 7 An overview of method steps 101-110' in a sequence is also shown. From the perspective of the second terminal M2, the electronic coin data record registered 104 by terminal M1 is received 105. Using this electronic coin data record, another (modified) electronic coin data record is generated and masked 108-110 for switching, merging, or splitting. The corresponding registration request is sent to the monitoring entity, which receives and processes it 108'-110'. These steps and the implementation of the steps shown in dashed lines have been fully described; these steps are optional in various variations.

[0229] Within the scope of this invention, all elements described and / or drawn and / or claimed may be combined with each other as needed.

[0230] List of reference numerals

[0231] 1. Issuing entity

[0232] 2 monitoring entities

[0233] 21 command entries

[0234] 22a,b Entries (predecessors) of the electronic coin data record to be modified.

[0235] Entries in the modified electronic coin data record (subsequent) 23a,b

[0236] 24 signature entries

[0237] 25. Markings for validity checks

[0238] 26. Calculate the marks for inspection.

[0239] 27. Scope of proof check markings

[0240] 28 Signature check mark

[0241] 3. Direct Trading Layer

[0242] 4. Accounting Level

[0243] M1 First Terminal, M2 Second Terminal, M3 Third Terminal, C i Electronic coin data record, net bill Cj C k Segmented electronic portion of coin data record, segmented net note C l Electronic coin data record C to be switched m Data record Z of electronic coins to be merged i Masked electronic coin data record, masked ticket Z j Z k The electronically segmented data record of the coin, divided into masked parts; the segmented masked note Z. l Data record Z of the electronic coin to be switched (masked) m Masked electronic coin data records to be merged i Currency Amount

[0244] υ j ,υ j Divided monetary amount υ l The monetary amount recorded in the electronic coin data. m The monetary amount r of merged or pending merged electronic coin data records i Hidden amount, random number r j ,r j Hidden amount r in the data record of the split electronic coin m Hidden amount C in merged or pending electronic coin data records i *Transmitted electronic coin data record, net note C j *,C k *Transmitted electronic portion of coin data record, divided net note Z i *Electronic coin data record transmitted via mask Z j *,Z k *The segmented electronic coin data record f(C) transmitted through a mask is a homomorphic one-way function [Z] i Sig I Signature of the issuing entity

[0245] 101-108 Method steps according to exemplary embodiments.

Claims

1. A method for directly transmitting electronic coin data records between a first terminal and a second terminal in a payment system, and for registering modified electronic coin data records with a monitoring entity by the second terminal, comprising the following steps performed by the second terminal: At the computing unit of the second terminal, an electronic coin data record is received from the first terminal. The electronic coin data record includes a monetary amount in the form of data representing the value of the electronic coin data record and a hidden amount in the form of data associated with the monetary amount. The computing unit of the second terminal generates a modified electronic coin data record using the received electronic coin data record, the modified electronic coin data record being based on the currency amount and a new hidden amount; The computing unit of the second terminal masks the modified electronic coin data record by applying a homomorphic one-way function to the modified electronic coin data record in order to obtain a masked modified electronic coin data record. as well as The computing unit of the second terminal sends a registration request for the masked modified electronic coin data record to the computing unit of the monitoring entity. The registration request includes the masked modified electronic coin data record to be registered, and a masked received electronic coin data record for verifying the registration request to the monitoring entity. The masked received electronic coin data record corresponds to the electronic coin data record received from the first terminal by applying the homomorphic one-way function, wherein the masked received electronic coin data record has been registered with the monitoring entity.

2. The method according to claim 1, wherein, The registration request is used to switch, split, or merge masked electronic coin data records.

3. The method according to claim 1 or 2, wherein, In the generation step: Based on the received electronic coin data record, generate the modified electronic coin data record to be switched, or The received electronic coin data record is divided into at least two modified electronic coin data records, or The received electronic coin data record is merged as a first electronic coin data record and at least one second electronic coin data record to form a merged modified electronic coin data record. as well as Accordingly, the registration request includes: A masked e-coin data record to be registered and a masked e-coin data record that has already been registered, or At least two masked, segmented, modified electronic coin data records to be registered, or At least two registered, masked electronic coin data records.

4. The method according to claim 1 or 2, wherein, In the generation step: Switch the received electronic coin data record to the modified electronic coin data record, wherein The hidden amount in the modified electronic coin data record is generated using the received hidden amount from the received electronic coin data record, and The received currency amount in the received electronic coin data record is used as the currency amount in the modified electronic coin data record; or The received electronic coin data record is divided into at least two electronic coin partial data records, wherein The received monetary amount corresponds to the sum of the monetary amounts recorded in the data of the at least two electronic coins, and The sum of the hidden amounts in the data records of the at least two electronic coins corresponds to the hidden amount in the data record of the received electronic coins; or The received electronic coin data record is merged as a first electronic coin data record and at least one second electronic coin data record through the following steps to form a modified merged electronic coin data record: The hidden amount in the modified electronic coin data record is calculated by summing the corresponding hidden amounts in the first and second electronic coin data records. The monetary amount of the modified electronic coin data record is calculated by summing the corresponding monetary amounts of the first and second electronic coin data records.

5. The method according to claim 1 or 2, comprising masking the received electronic coin data record by applying the homomorphic one-way function to the received electronic coin data record in order to obtain a masked received electronic coin data record.

6. The method according to claim 1 or 2, wherein, The monitoring entity stores valid, masked electronic coin data records, enabling the second terminal to check the validity of received electronic coin data records by sending the masked received electronic coin data records to the monitoring entity.

7. The method according to claim 1 or 2, further comprising the step of creating proof that the currency amount of the received electronic coin data record is equal to the currency amount of the electronic coin data record to be switched.

8. A method for monitoring an entity in a payment system, wherein, The monitoring entity stores valid masked electronic coin data records formed by applying a homomorphic one-way function to the electronic coin data records. The electronic coin data records include the monetary amount and the hidden amount. The method includes the following steps: At the computing unit of the monitoring entity, a registration request is received, the registration request including at least one masked electronic coin data record to be registered and at least one masked electronic coin data record that has already been registered; The received registration request is examined by the computing unit of the monitoring entity, wherein... The computing unit of the monitoring entity checks whether the registered masked electronic coin data record of the registration request is stored as a valid masked electronic coin data record in the monitoring entity, and The computing unit of the monitoring entity checks whether the masked electronic coin data record of the registration request is monetary amount neutral. The computing unit of the monitoring entity stores the masked electronic coin data record to be registered as a valid masked electronic coin data record. Previously registered masked electronic coin data records for the registration request that were previously stored as valid are no longer valid by the computing unit. The computing unit of the monitoring entity cannot determine the currency amount and hidden amount of at least one of the masked electronic coin data records to be registered and at least one of the registered masked electronic coin data records.

9. The method according to claim 8, wherein, By forming the difference between the masked electronic coin data records, a check is performed to ensure the monetary neutrality of the registration request due to the homomorphic one-way function used, without knowing the amount.

10. The method according to claim 8 or 9, wherein, The monitoring entity receives from the issuing entity requests for the creation and / or deactivation of data records for newly issued electronic coins and / or withdrawn electronic coins, respectively.

11. The method according to claim 10, wherein, Requests for the creation and / or deactivation of masked electronic coin data records include the issuer's signature on the masked electronic coin data record.

12. The method according to claim 11, wherein, The electronic coin data record becomes invalid by marking or deleting the corresponding masked electronic coin data record in the monitoring entity.

13. The method according to any one of claims 8, 9, and 11, wherein, The monitoring entity is a decentralized controlled database known as distributed ledger technology, wherein the masked electronic coin data record is registered with the corresponding processing information of the masked electronic coin data record.

14. A payment system for exchanging monetary amounts, wherein, The payment system, which performs the method according to any one of claims 1 to 13, comprises: The monitoring layer includes a database, and stores valid masked electronic coin data records of electronic coin data records in the database; and The direct transaction layer consists of at least two terminals that exchange electronic coin data records.

15. A monetary system comprising an issuing entity, a monitoring entity, a first terminal, and a second terminal, wherein the issuing entity is configured to create electronic coin data records, wherein, The monitoring entity is configured to perform the method according to any one of claims 8 to 13, and / or the first terminal and the second terminal are configured to perform the method according to any one of claims 1 to 7.

16. The monetary system according to claim 15, wherein, Only the issuing entity is authorized to create data records for the newly issued electronic coins.

17. The monetary system according to claim 15 or 16, wherein, The monitoring entity executes the issuing entity's requests to create and / or deactivate masked electronic coin data records, as well as registration requests for masked modified electronic coin data records of other entities.

18. The monetary system according to claim 15 or 16, wherein, The currency system includes additional server entities that transmit electronic coin data records between themselves or directly to / from terminals, and send registration requests to the monitoring entity for masked modified electronic coin data records.

19. The monetary system according to claim 15 or 16, wherein, The steps are performed by the second terminal through steps executed in the terminal, or by the terminal invoking a terminal service that performs the steps of generating, masking, and / or sending the terminal.

20. The monetary system according to claim 15 or 16, wherein, In the monitoring entity, when the masked e-coin data record or its predecessor originates from the issuing entity, the masked e-coin data record is identified as valid, wherein the issuing entity signature of the created masked e-coin data record is stored in the monitoring entity.

21. The monetary system according to claim 20, wherein, The inspection entity and the issuer entity are implemented as server entities.

22. The monetary system according to claim 15 or 16, wherein, The first terminal and / or the second terminal are configured as mobile terminals.

Images